Vår sajt klarar sig inte längre på en webserver och vi måste nu skaffa ytterligare en och eventuellt behövs det snart fler än så. I dagsläget har vi en webserver Windows 2003 och IIS 6. Sajten är en ASP.NET-lösning. Databasen (MySQL) ligger på på linuxburkar.

Frågan är då vilka lösningar vi bör välja och hur vi ska hantera webserverbiten. Det är framförallt ett par saker som ger oss lite huvudbry.

1. Sessionsvariablerna
Vi använder oss av sessionsvariabler. Det är inte i någon större omfattning men vi kan inte vara utan det. Dels använder vi oss av FormsAuthentication som är inbyggt i ASP.Net för att hålla reda på om man är inloggad eller inte och dels använder vi oss av sessionsvariabler för att hålla reda på subinloggningar av användaren. Detta funkar ju bra så länge vi bara har en webserver, men om vi ska ha fler webservrar så ställer det ju till lite problem. :/

Som jag ser det så finns det 2 alternativ. Där det ena är att köra med roundrobin och sedan ha en www1 och en www2 och så får användaren hållas på den ena eller den andra servern och då blir det ju inte några problem med sessionerna eftersom använder håller till på en och samma server. Det andra alternativet är att köra med NLB och lastbalansera så att man får svar från den server som är under minst belastning. NLB vore ju det bästa alternativet om det nu inte vore för att vi använder sessionsvariabler. Med .Net kan man ju dock i web.config sätta SessionState till "StateServer" i stället för "InProc" och låta alla sessioner sparas på en specifik server istället för lokalt på den server man för tillfället är på. Nu är jag inte helt insatt i hur det skulle fungera, men det borde ju innebära att man skulle kunna köra med NLB trots sessionsvariablerna. Dock skulle det ju göra att man förlorar den stora fördelen med NLB som är att allt kan flyta på även om en server går ner. För skulle den server gå ner som håller sessionerna så är det ju stenkört likförbannat.

Så frågan är om man ska satsa på NLB eller round-robin med www1 osv. Eller finns det nån annan smart och smidig lösning?


2. Grafiken
Grafiken på sajten ställer också till med lite av ett problem. Framförallt pga att använderen kan ladda upp egen grafik som vi lägger i en speciell mapp som måste vara åtkomlig från samtliga servrar. Frågan är om man bara kan göra så att man skapar en virtuell folder som pekar på en viss mapp på en specifik server. Problemet med detta är ju dock flera. Dels kommer det ju bilderna cachas för varje www1, www2 osv om vi nu kör på den varianten och inte NLB. Om allt ligger enbart i en mapp som vi sedan har virtuella folders som pekar på så är ju också frågan om det överhuvudtaget går att ladda upp filer i en virtuell folder som som pekar på en annan server. Eller kan man replikera mappar på något smidigt sätt? Eller ska man skapa en img.doman.com som tillhandahåller alla bilder till applikationen för att se till att bilderna cachas och bara behöver hämtas en gång. Replikering vore ju bra då man inte skulle vara så beroende av att just den servern är uppe som tillhandahåller bilderna. Frågan är hur man lämpligast hanterar grafiken om man har ett webkluster med flera webservrar. Hur brukar man lösa detta?


Det vore väldigt intressant om ni har lite synpunkter på hur man bör bygga upp ett webkluster på bästa sätt. Och hur har ni själva löst det om ni har webkluster? Är det nåt annat som man bör tänka på när man ska ha ett webkluster? Bör man tänka annorlunda om man eventuellt behöver ett kluster med 20 webservrar jämfört med om man bara behöver några enstaka webservrar?

Om det är nån som har några bra länkar till artiklar i ämnet så är det också intressant.

Kort och koncist:

Det finns en lastbalanserare i windows (server edition), den klarar av att hantera sessionvariabler mellan servrarna om jag inte minns fel.

Jag rekommenderar att spara bilderna på en specifik server och hårdlänka dit (med hostname). Ni kan alltid duplicera dom i efterhand och då köra round-robin på dom.

Räkna med en hel del testning för att få det att funka med sessions dock, det är ingen lek :/

Är det ett alternativ att göra en egen session-hanterare som använder samma mysqld som resten av sajten? Ärligt talat så förstår jag inte varför det är så vanligt att använda en färdig hanterare. Gör man en egen får man den ju precis som man vill ha den. Många möjligheter öppnas och det blir mer flexibelt.

Saknar helt och hållet erfarenhet av .NET och Windows.

När det gäller sessionsvariablerna så finns 3 olika sätt att hantera det hela med ASP.Net.

1) InProc
Sessionen sparar lokalt "in process". Detta funkar ju om man nu skulle köra RoundRobinDNS och låta användaren köra enbart på en webserver. Misstänker dock att det vore bättre att köra med riktig lastbalansering.

2) StateServer
Sessionen sparas på en central StateServer. Dvs att den hålls i minnet på en specifik server som webservrarna får kalla på för att få tag på sessionen. Vad jag förstår så är det en av ASP.Nets bättre features och ska vara snabbare än att lagra sessionerna i databas. Det är väl detta alternativ som vi lutar åt just nu i kompination med lastbalansering enligt NLB.

3) SQLServer
Lagra sessionerna i databas. Detta alternativ är väl tämligen likvärdigt med StateServer. Känns dock som att det är lite jobbigare att implementera och jag är lite osäker på om vi vill tynga ner vår databasserver med att hålla reda på sessionsvariablerna. Men det kanske belastar speciellt mycket och då skulle det kanske kunna vara ett alternativ.

Att göra en egen sessionshanterare känns lite over-kill. Förvisso kan man ju få det precis som man vill men vi vill ju inte lägga ner mer tid än nödvändigt på det hela. Våra resurser är ju tämligen begränsade både när det gäller tid och pengar. Det känns hur som helst att de befintliga alternativ som finns att tillgå borde fungera tillfredställande och innebära mindre implementationstid. Frågan är ju bara vilket alternativ som är bäst.

När det gäller grafiken och att hårdkoda sökvägarna så känns det instinktivt som ett vanskligt steg. Dels så klingar hårdkodning lite falskt i mina öron och dels så känns det inte helt enkelt att lägga in hårdkodning överallt. Men det är hur som helst mycket möjligt att du har rätt i att det är bästa alternativet trots allt. Och det borde nog kunna gå rätt snabbt att bara köra Replace All på alla imagesökvägar i hela projektet. Och du har nog en bra poäng i att kunna köra en round robin på grafiken. Efter vad jag har sett så verkar det som att de flesta sajter där man kan ladda upp bilder sparar dom på en specifik server typ img.doman.com

Men om man nu skulle köra NLB så blir ju sökvägarna de samma i alla fall om man låter grafikmapparna ligga som virtuella folders. Så då blir det inga problem med cachning utan att bilderna cachas bara en gång oavsett vilken webserver som servar. Men jag är ju då lite osäker på om det går att ladda upp filer till en virtuell folder. Det borde ju dock funka om bara sätta skrivrättighet på den virtuella foldern. Jag har dock för mig att vi testat detta någon gång tidigare och att det inte fungerade :/

När det gäller lastbalansering så kan man ju antingen välja att välja NLB (Network Load Balancing service) som är inbyggt i Windows 2003 och kan hantera ett kluster på upp till 32 webservrar vilket borde vara fullt tillräckligt :) ...Men man ska ju tydligen kunna välja att använda nån hårdvarubalansering vilket jag har noll koll på vad det egentligen innebär. Det är något som vår ISP föreslog. Om det nu är bättre eller inte har jag ingen aning då jag inte vet vad det innebär riktigt. Vet dock att det innebär en extra kostnad på 5-8000 kr. Med tanke på det så känns det som att det vore bättre att använda sig av NLB då jag förstått att det redan finns inbyggt, även om man inte vill vara dumsnål. Det tredje alternativet är ju att RoundRobinDNS, men det känns som ett sämre alternativ.

Kan tillägga att jag inte är nån nätverkstekniker så jag vet knappt vad jag pratar om :P ...Men jag försöker snappa upp så mycket jag kan så man inte gör nåt dumt :)

Bra länk om Network Load Balancing på Windows 2003 Server:
http://www.west-wind.com/presentatio...indows2003.asp

Det är inga problem för oss att köra med enbart en webserver i dagsläget. Men i dagsläget är sajten enbart tillgänglig på svenska och vi har nu även stöd för engelsk som dock inte är gjort tillgängligt ännu. Men när vi gör det så misstänker vi att belastningen kommer att öka så pass mycket att vi inte längre klarar av att hantera allt med en webserver. Vi måste hur som helst se till att förbereda oss på det värsta(bästa) så att vi inte står där med skägget i brevlådan om det skulle bli en fördubbling av antalet användare eller ännu värre(bättre) ganska snabbt.

Men tills dess att vi gör den engelska versionen tillgänglig så klarar vi oss på en webserver. CPU-användningen ligger och snittar på ca 40% i normala fall. Men ibland kan den gå upp mot 70% under vissa tider.

Har inte hunnit kolla på pound så mycket. Ska kolla på det lite mer. Men sajten är inte så bildintensiv att det är det som är det är orsaken till problemet. Det är framförallt att vi helt enkelt kan få en markant ökning av användare inom kort.

Mycket av belastningen på CPU beror nog på att vi kör med HTTP Compression. Men det gör en himla skillnad på bandbredden och gör sajten mycket snabbare. Dessutom har vi ett konsolprogram på servern som ligger och kör uppdateringar mot databasen en gång i halvtimmen. Detta gör att CPU användningen går upp något då den kör.

När det gäller multipla trådar så tycker jag inte det vara vara så farligt. Det skiljer inte speciellt mycket från antalet connections. Nu vet jag dock inte riktigt vad det är man ska kolla, men om antalet current connections är ca 400 så ligger antalet trådar på ca 500 och det är väl ganska rimligt?

Vår sajt innehåller för övrigt väldigt få statiska sidor.

Tänk om man byggt sajten i JSP istället och på en unix-maskin :P Finns en anledning till att Hotmail kördes på linuxmaskiner... Dock har dom nu övergått till win-servrar... och se hur det går :P

Iallafall, skaffa ett 1000 mbit nic och koppla ihop dom... Kör en mediaserver (bilder etc), en server som hanterar alla ASP.net sidor, en tredje som kör typ thttpd (tiny/turbo/whatsoever-httpd) som hanterar alla statiska sidor som inte behöver kompileras och en sista som sköter databasen.

Pröva HT proccessorer eller duals...

Jag håller med förra talare, enklast är att dela upp grafik på separat webbserver och dynamisk data på en.
Dessutom - ska du splitta sessioner så går det utmärkt med en hårdvarulastbalanserare (t.ex. från Radware som är min personliga favorit). Den är smart nog att känna igen en session själv och sen låsa all trafik från den klienten till den ena webservern. Om det bara är för lastbalansering du ska ha den så är det helt dugligt i dom flesta fall.
Ska du ha failover (dvs, en webbserver går sönder så tar den andra/tredje/fjärde/osv över) så räcker ju inte det helt till kanske - man blir åtminstone av med sin session och sen kan man logga in, vilket kan vara tillräckligt iofs, men för många är det otroligt irriterande.
Då behöver du lägga dina sessions på en delad maskin - t.ex. sql-baserade sessioner, vilket oftast fungerar väldigt fint då det ändå hamnar i cache).

Annars så är jag en stor stor fan av att faktiskt se över hur ens maskin fungerar.
Jag har varit inblandad i ganska många stora webbsiter och jag kan nämna mångdubbling av fart med ganska lite jobb. Sådana saker som att placera rätt data på rätt ställe är ju nåt man ofta gör om ett par gånger under en sites utveckling, man behöver ofta omplanera lite på den befintliga datan.

Kryptiskt inlägg märkte jag, kanske dags att sova :-)

Behöver du konsulthjälp så kan du höra av dig i PM!

Vad du kan göra med bilderna är att lagra dem i MySQL som blob, ifall de inte är gigantiskt stora. MySQL replikerar du tämligen lätt.

Sessionsvariabler kan du spara på klientsidan mha-kakor ifall du krypterar dem. Då borde även det fungera tämligen bra.

/Zoran

Skulle nog aldrig rekommendera nån att använda blobbar om man absolut inte måste. Speciellt inte i ett högtillgänglighetssystem där prestanda är ett krav.

Och sessioner hade jag ogärna sparat på klientsidan även om man krypterade dom - kakor är inte alltid gott.

Vad krångligt att ha filer i databas. Filsystem är ju den smidigaste sortens databas att ha filer i... :D

Om man replikerar en MySQL-databas som du beskriver så kommer alla bilder ligga på alla MySQL-servrar. Onödigt slöseri med hårddisk och prestanda. NFS (eller SMB för Windows) är ju gjort för delning av filer över nätverk :D

Visst kan man lägga en del icke-kritiska sessionvariabler krypterat på klientsidan, men man vill ändå inte lägga all sessiondata där (såsom vilken användare man är inloggad som)? Isf är det ju ingen mening att lägga en del hos klienten.

Bör väl gå rätt bra att använda någon form av nätverkslagring för bilder och framförallt att ha dem på en egen server.

Vore kul att höra hur ni löser det på sikt. Det finns ju också relativt enkla lösningar som att uppgradera servern med flera processorer och liknande...

Det tycker jag är "fel" ställe att börja på, i längden kostar det bara mer än att använda det otrevliga uttrycket "gör om, gör rätt".
Kasta hårdvara på problemen skjuter bara upp dom till imorgon :-)
Dessutom är det ju så otroligt roligt att optimera saker! (Tycker jag på riktigt) :)

Hårddiskutrymme? Alltså så här ÄR det: Om du vill eliminera din "one single point of failure" måste du lagra datat redundant.

Ett sätt är det att göra som jag sa, replikerat över MySQL-servrar. Annat sätt är att utnyttja någon form av distribuerat filsystem från en filserver. Ett tredje sätt är att haka på flera servrar på samma diskarray (fast där är det HA vi pratar om och inte LB eftersom bara EN server kan komma åt filerna åt gången).

Prestandamessigt är det ju naturligtvis MySQL-lösningen som har störst överhead. Men ifall man pratar om små datamängder kan den överheaden vara försumbar med tanke på att priset blir annorlunda.

Vad jag kan tänka mig är att den här lösningen inte är värst skalbar.


Vad bertäffar sessionsdata, så visst, om jag hade en internetbank skulle jag väl inte förlita mig på det. Däremot tror jag bestämt att du kan få tillräckligt god säkerhet ifall du ska driva ett community eller liknande.

Om du sparar username i kakan, samt på serversidan ser till att du genererar en checksumma från username + någothemligt-innehåll + IP + whatsoever (för varje användare olika), och sen lagrar checksumman som kaka, så har du kommit en bit på väg. (se till bara att använda ssl).

/Zoran

Standardlösningen man bygger i ett sånt här läge är ju en enklare form av lastbalansering. Det är bäst i form av pris och prestanda.

* N antal webservrar som står i ett lastbalans-"cluster", antingen bakom en riktig lastbalanserare eller bakom t.ex. en maskin som kör gnu balance.

* En filserver (eller fler beroende på hur stabilt man ska ha det) som kör t.ex. NFS och delar ut alla webfiler.
Evt kan man även rsynca över filerna till varje webserver.
* En databas-server. Vill du ha det mer redundant får du replikera den också.

Billig-varianten här är att köra filserver & databas-server på samma maskin - har du inte nån vidare last på databasen så går det oftast alldeles utmärkt, och eftersom du ändå har SPOF (single point of failure) på en replikerad databas i.o.m. att den inte står i ett riktigt cluster, så behöver du inte ha en extra maskin i onödan om prestandan inte är problemet.

Men att lagra bilder i BLOB'ar och göra selects, det är förkastligt. Och att lagra användardata på klientmaskinen, det skulle jag av säkerhetsskäl aldrig göra - det är nog att nån öppnar sin session efter dom har fattat hur du krypterat din nyckel och byter sitt användarid t.ex.
Tänk om Lunarstorm hade lagrat allt hos dig, den hade varit knäckt för länge sen och massvis av människor hade varit inne på olika personers konton. Nej, det är _inte_ en bra lösning.