Välja riktigt snabb Apache server

Ta en titt på Suns maskinpark. De har en del bra just för enorma mängder sessioner.

Sun eller HP, etablerade och bra serverhårdvara.

Efter lite diskussion på irc med folk inom serverbranchen bland annat var det övervägande åsikterna att lastbalanserade med sticky sessions och flera maskiner en billigare och bättre lösning, samt att det erbjuder redudans.

En maskin som ska ta denna mängd trafik kommer kräva rätt mycket, en annan lösning är ju att stoppa in nyare servrar eftersom, kanske köpa 1 server från sun för 20-30k med solaris och köra apache i den och ha detta i racket, tillsammans med de andra. Och eftersom byta ut de andra om man vill det.

RAIS! Redundant Array of Independent Servers.

Jag tror mer på flera mindre burkar, än en fet.

Hur många ägg vill du ha i samma korg?

Med en gemensam filserver skulle detta inte behövas.

Suns niagara baserade maskiner skall ju vara ena riktiga monster, T1 / T2

Men problemet med att filer måste ändras 5 gånger är lätt att lösa, antingen med en separat filserver (även om det är overkill för forum kod endast). lättare är ju att ha en testmaskin, denna kör commit mot cvs/svn som produktionsmaskinerna sedan kör auto-checkout mot varje natt, ger en förutbestämd och kontrollerbar produktions utrullning.

Problemet med en maskin är ju det att även om du köper ett riktigt monster så har den bara X mängd I/O bandbredd etc, du får mer sidor per sekund med flera lite billigare maskiner än ett monster..

I slutändan handlar det ju endå mer om vad som ni är vana med.. clusterlösningar är dock rätt lätta att hantera om man bara tänker till innan man sätter upp allt, skulle tro att det vore lättare att flytta sidan till en centraliserad utveckling och distrubierad användingsmodel än att handla nytt om det nu är utvecklingen av sidan som det hänger på

Klurade lite på hur jag skulle lösa det, blev en rätt standard lösning

http://www.dnz.se/img/99.se.png

sql.99.se & dispatcher.99.se: är precis som det låter, SQL server respektive lastbalanserare.

dev.99.se: All utveckling av sidan görs på denna, som nodeX (1,2,3,4 etc) synkar mot på beställning, eller om man vill göra det ännu smidigare, så kan noderna i klustret nätboota mot dev.99.se, så även eventuella uppdateringar till OS och programvara bara behöver uppdateras på ett ställe (sql & lastbalanserare lär vara specialeriserade).

Vid nätboot, så är det trivialt egentligen att addera mer noder för att växa med ökande belastning, stoppa den i racket och PXE boota den nya noden

CVS/SVN, har själv använt det vid flertalet tillfällen för confer och framförallt av zone filer till bind, ändra på ett ställe och resten av noderna synkar upp, så att om du ändrar eller arbetar på forumkoden så hanteras denna på en central plats.

Att sedan synka upp noderna är enkelt, antingen använder man cron om man vill att de skall synka upp exempelvis varje natt eller så, eller så ssh med public key auth (min favorit) där man enkelt skapar ett script på dev som går ut till noderna och startar en synkning.

Lastbalansering har inget med tillgänglighet att göra, om det är det som du är ute efter så är det redundans som du måste planera för..

Att gå över till en maskin för webb delen och en för SQL ger dig varken lastbalansering eller HA (redundans) oavset vad som det står i reklamen om maskinen som du kollar på

Satsa på en vettig synk mot dina frontends. (vi kan titta på det vid tillfälle om du vill)

Sen är xserve intel med leopard sjukligt snabbt om du jämför med xserve g5 med tiger.

yepp, kallas opensolaris.

Jo, jag vet men inte den jag tænker på

http://www.sun.com/software/solaris/get.jsp

jepp media för att installera och "licens" så att säga får du gratis, det har det iofs varit länge, men om du skall ha solaris riktigt gratis med "comunity support" som de kallar det etc är det opensolaris som gäller..

har det även för att man inte får de senaste uppdateringarna eller så till solaris om man inte har support avtal som kostar pengar (eller kör opensolaris) men det kanske de har slutat med nu, inte kollat.

Min poäng var som det att om man inte satsar på riktig redundans så är inte tillgänglighet att tala om egentligen, det är som inte så att man kan skapa en lösning som är till hälften tillgänglig, antingen ar sakerna redundanta eller inte

Dock det som jag mest har emot singel servern lösningen är att då (inte om) sidan växer ur servern krävs det en ny 100k+ investering, iställer för en investering i en klart billigare extra nod i clustret..

Kør du en kritisk driftmiljø så brukar ju dem pengarna vara en piss i sjøn gentemot stillestånd, fast nu børjar vi glida OT.

kan tänka mig att det förkommit avrundningsfel större än den kostnaden där jag jobbar nu

Måste hålla med övriga att en lastbalanserad och redundant miljö är klart bättre än en feting maskin.

I ett tidigare liv satsade vi på feta maskiner som funkade jättebra tills lasten ökade och vi behövde bygga ut. Att komplettera med ytterligare hårdvara var ju extremt dyrt. Ett problem är ju att man köper något som är bra för det mesta men inte specialiserad. Olika applikationer kräver ju olika typer av konfigurationer.

Den dyraste delen för websystem är normalt disksystemen och då speciellt för databaserna. Om du tycker att replikering ala ntitys rekommendentationer är dåligt kan du ju satsa på någon enklare form av san lösning. Ärligt talat så kör ni ju ingen jättestor lösning

Jag skulle satsa enligt nuvarande modell, som ntity har skissat upp. Eventuellt även slänga in en eller ett par generella standby maskiner. Dels för att ha emergency failover för databasen men även som extra vid behov.

Mitt område är ju inte hårdvara så utifrån mitt perspektiv skulle jag även gå över arkitekturen på hela lösningen. Nu vet jag inte vad som är flaskhalsen men du kan ju även överväga att sprida ut databasen på flera maskiner. Då får du ju redundans och failover lite gratis samt att du kan ha billigare maskiner som kan dela på lasten. Själva siten känns tung att ladda hem. Där kanske man kan se över arkitekturen och få sidorna att rendera snabbare och cacha mer av db och php bearbetningarna.