[bjornstrom]

Klockan är 01.32 natten mot lördagen när ett SMS varnar för att vår serverfarm har tappat kontakten med internet. Någon minut senare försöker jag logga in på servrar, testar olika IP-nummer och försöker nå vårt säkerhetsystem. Alla försök misslyckas - en svag länk i kedjan har brutits och våra internettjänster är otillgängliga.

Vad som saknades var Redundans - vi har skrivit en kort guide till vad man skall tänka på och våra egna erfarenheter.

För den som planerar driftskritiska system - exempelvis hemsidor, mailservrar eller andra internettjänster med många besökare som är beroende av att tjänsterna är tillgängliga är det viktigt att redan i planeringsstadiet fundera över redundans.

Jag har personligen haft egna webbservrar i drift sedan sommaren 2000 och har lärt mig en hel del sedan dess. Målet har alltid varit 100% tillgänglighet men det har visat sig vara knepigt att genomföra i praktiken.

Praktiska problem med serverdrift:

- Är det någon som minns dom enorma strömavbrott som Kista och andra delar av västra Stockholm råkade ut för? Minst två av dessa avbrott varade i mer än två dagar utan några möjligheter att själv påverka situationen - vi hade våra servrar hos en internetleverantör med webhall i Akalla och fick glatt vänta på att strömmen skulle komma tillbaka.

- Efter att ha bytt internetoperatör råkade vi ut för minst tre kabelbrott i samband med att bygget av södra länken fortskred strax utanför Stockholm. Oftast fick man kontakt med internet efter 2-12 timmar men det skapade stor irritation.

- Vi har också råkat ut för att vi utnyttjar för mycket bandbredd. Under en period hade vi 2Mbit tillgängligt vilket oftast räcker långt men periodvis har vi behövt betydligt mer och då har exempelvis varit väldigt långsamt eller helt enkelt otillgängligt.

- Intresset för Mac är väldigt cykliskt. När Steve Jobs går upp på scenen och presenterar nya produkter är intresset större än någonsin och Macsajterna översvämmas av besökare. Ibland kan det också vara så att nyheter sprids internationellt - begreppet "Slashdottad" uppkom när webbservrar kraschar pga för många besökare.

- Under utvecklingsarbetet med mac.se tjänsterna fick vi känna på ett annat problem: diskkrasch. En riktig mardröm som tar tid att reda ut - särskilt om ordentliga backuprutiner saknas. För oss var det en riktig tankeställare som gjorde att vi tog några fasta beslut som vi inte viker ifrån: alltid, alltid RAID-5 och helst SCSI-diskar sitter i "ryggraden" nuförtiden. Vi har hot-spare disk i två maskiner: en disk står stilla och väntar på att ersätta en systerdisk som går sönder. Bytet sker automatiskt.

- Riktiga servrar har god redundans inbyggd. Nätaggregat och fläktar som går att byta under drift, god kylning, RAID och övervakning av beståndsdelarna är väldigt trevligt. Läs gärna vår granskning av Xserve G5 som vi skrev nyligen.

- Driftstopp pga kraschade operativsystem har jag faktiskt aldrig råkat ut för (peppar, peppar) trots att vi kört Windows 2000 Server under lång tid.

- Felkonfigurering av tjänster kan leda till kortvariga driftstopp. Att leka med inställningar eller uppgraderingar under pågående drift kan alltid göra att någonting stannar tillfälligt och skapar problem. Vi har varit ganska förskonade ifrån dessa problem som tur är. Använd helst inte produktionsmiljö för testning - det kan skapa rejält med extrajobb.

- Intrång och attacker är också något som man måste vara beredd på. Det finns fler ondskefulla internetanvändare än jag trodde - vi råkade ju ut för att en 99mac-användare hittade på sätt att ladda ner medlemsregistret vilket senare användes för spamutskick och troligen såldes vidare. Även hackerattacker och arga människor som vill förstöra för oss kräver goda rutiner och loggning av trafik.

- Problem med DNS:er eller felkonfigurering skapar mycket oreda. Vi har valt att använda webhotellets dubblerade DNS:er för att minska den typen av problem.

- Ren klumpighet, otur och dålig planering kan också leda till driftstopp. Att installera servrar utan att skruva fast alla rackfästen, lösa strömkablar, dåliga ethernetsladdar, dåligt placerade switchar och backupenheter kan skapa problem. Jag har sett riktiga mardrömsexempel där en kund placerat en tornserver på en hylla där en liten, liten putt skulle göra att den faller 1.5 meter ner i ett betonggolv. Server var fylld av kritiska data som skulle orsaka driftstopp med kostnader i miljonklassen. Självklart saknade dom backup.

- Rätt kvalitet på utrustningen är naturligtvis jätteviktigt. En billig switch som hänger sig varannan vecka, billiga ethernetkablar som tidvis ger konstiga nätverksfel, dåliga diskar, dåliga nätverkskort eller allmänt instabila datorer som inte är byggda för serverdrift kan orsaka mycket huvudvärk.

- Vad händer den dag då grejerna stannar eller helt enkelt går sönder? Att skicka servern på service i fyra veckor är inte ett alternativ, därför måste man teckna serviceavtal för varje del i kedjan. Alla stora serverleverantörer erbjuder 24/7/365/4h support - 4 timmars inställelsetid dygnet runt, året runt. Kom ihåg att alla vitala delar måste omfattas - även routers, switchar och brandvägg måste kunna fixas omedelbart eller ersättas.


Jag har säkert missat flera punkter i ovanstående, kom gärna med kommentarer och egna erfarenheter. Att planera ett helt redundant system är knepigt och det kan vara väldigt dyrt att dubblera alla system.

Planeringen av mac.se

Under planeringsarbetet för mac.se - ett typiskt kritiskt system med betalande användare som alltid måste vara tillgängligt - har vi använt vår erfarenhet för att bygga upp en god driftsmiljö. Vi har placerat våra servrar hos Internet5/Telenor i centrala Stockholm som har en väldigt avancerad serverhall. Förutom att lokalen är ytterst stöldskyddad och allmänt svårtillgänglig finns brandskydd, rejäla 42U rack i mängder och god kylning. Dubbla redundanta 100Mbit internetförbindelser gör att man nått minst 99.99% tillgänglighet mot internet. Strömförsörjningen är skyddad genom UPS:er (batteribackup) i 2 minuter innan stora dieselaggregat tar över. Strömmen i rackskåpen är dubblerat i separata A och B kanaler - man ansluter serverns dubbla nätaggregat till varsin strömkälla.

Plötsligt stannar allt

Det är dyrt att bygga välplanerat och våra svaga punkter är brandväggen och switchen som utgör våra SPOF - Single Point Of Failure. Om brandväggen eller switchen dör stannar allt. Och det var precis vad som hände inatt. Klockan 01.32 tappar vi kontakten med serverfarmen och några minuter senare meddelar jag jourhavande tekniker på webhotellet vad som hänt. Tyvärr är det fredag natt och vi tvingas vänta till 08.00 innan vårt serviceavtal gäller. Vid 09-tiden får vi rapporten: brandväggen startar inte om trots omstart.

Vi är hyggligt förberedda nuförtiden men det här hade vi hoppats slippa vara med om. En halvtimme senare väljer vi att använda serviceavtalet på brandväggen och kallar in jourhavande tekniker (á 9000kr!) som kommer med ersättningsmaskin vid 13.30. Vår system tar ögonblicksbackup av brandväggsinställningar varje dag som mailas och sparas i min Powerbook. När nya brandväggen är uppe klickar vi i några rutor och laddar upp inställningarna - en minut senare är vi online igen.

Jakten på 100%

För att öka redundansen i vårt system tvingas vi omkonfigurera vårt brandväggssystem till "high availability" vilket innebär att man har dubbla brandväggar mot internet, dubbla switchar och alla servrar är kopplade till båda switcharna. Då är vi online även om en brandvägg eller en switch stannar. Beräknad merkostnad: ca 22.000kr plus 600kr/mån för rackytan.

För att öka redundansen för mac.se (som är prioriterat) till nästa nivå måste vi använda en klusterlösning där två eller flera servrar delar på trafiken och gör tjänsten maskinoberoende. Stannar en server påverkas ingenting. Tyvärr är kostnaderna enormt höga - cirka $40.000 eller 300.000kr utan att vi ens räknat med hårdvara/servrar. Det får vänta ett tag till med andra ord.

Meningen med denna artikel är att belysa några av dom problem som förknippas med 100% tillgänglighet och vilka svårigheter och kostnader man får räkna med. Troligen finns det gott om kompetens hos 99mac:s medlemmar - skriv gärna en kommentar och berätta om era egna problem och lösningar!

Läs om Redundans på susning.nu

[Decibel]

Tycker du hittat dom flesta aspekterna man skall tänka på, jag ser allt för ofta personer som anser att redundans är endast 2st internetlinor, sen har dom inte någon lastbalansering eller någon teknik för att kunna skilja linorna åt så är man tillbaka på noll igen (det förstår dom inte förrän dom upplever ett sött driftstopp).

Har också servrar på Internet5 , kan bara hålla med om att deras hall verkligen håller måtten och ger vad dom lovar, sedan jag flyttade in där 2002 har jag inte upplevt några störningar att tala om.

Personligen har jag börjat labba med hall-spegling. D.v.s. två servrar i olika hallar som hela tiden håller varandra up-to-date, materialet är max 15 minuter gammalt om en server brakar, med DNS i 5 olika hallar och 5 olika ISP;s (port80, internet5, gblx.net, savvis.net och gyron.net) så tror jag just denna lösning kommer bli riktigt stabil, TTL på 60 sek gör att om en maskin dör så landar man på den andra inom en minut.

Hårdvaran i servrarna missar många, spegling av hårddiskar och allrahelst hotswap, om en spegel går sönder så klarar den sig till man kommer dit och sätter i en ny, med servern igång. (försök göra detta på en webcows-server, som exempel )

Det med brandvägg som hänger sig inträffar tyvärr för ofta, jag löste det med två oberoende servrar, när båda är aktiva agerar den ena IDS (loggar lite bara) och den andra filtrerar, dom är inte beroende av varandra och kan överta varandras tjänster om den andre inte svarar.

Det med switch tror jag inte man kan komma ifrån på ett billigt sätt, har försökt och labba här hemma utan några större framgångar, mest nätverkskrockar och annat frustrerande

[bjornstrom]

Vi kommer troligen uppgradera till redundanta brandväggar där den ena sitter som "Hot Standby" hela tiden.

Jag siktar på 2st HP Proliant DL140 med dual 2.4GHz Xeon och 1GB RAM som brandväggar, extrautrustar dom med 2x10/100 kort bara.

[Thomas]

Underbar läsning!

Tack för att du delar med dej!

WN

[Tobbe]

Utomordentlig krönika!

Tummen upp!

[Peter]

Jag har själv gått och funderat på att låta servrar på två skilda platser dela på trafiken och undrar därför lite nyfiket, vad är det du har räknat in i de 300.000kr det skulle kosta?

Måste även instämma med Cellsynt och WN, tack för ett mycket bra inlägg!
//Peter

[Marcus]

Originally posted by bjornstrom@Apr 17 2004, 14:51
Meningen med denna artikel är att belysa några av dom problem som förknippas med 100% tillgänglighet och vilka svårigheter och kostnader man får räkna med. Troligen finns det gott om kompetens hos 99mac:s medlemmar - skriv gärna en kommentar och berätta om era egna problem och lösningar!

Intressant läsning, även om det kanske hade räckt med att du hänvisat till ursprungliga källan direkt via en länk?

[gabriel]

Ursprungligen postat av marcuss

Intressant läsning, även om det kanske hade räckt med att du hänvisat till ursprungliga källan direkt via en länk?

man får ju inte posta länkar hur som helst?

e väl skönt att inte behöva klicka massa också =)

[gabriel]

Är det planerat avbrott eller fick ni problem i natt/morse med? Sidan fungera ju inte nu heller...

[Tommy]

Just det där med switchar är ju lite intressant. Jag praktiserade på ett företag. Där var nätet väldigt viktigt eftersom att PLCerna altså maskinernas styrenhetr var beroende utav servrarna hela tiden. Och om det hela dör så förloras det 135tusen på 10minuter. Så att det dog var inget alternativ. Så jag var med och byggde ut en del av deras nät och fick reda på hur allt vart uppyggt. Ett exempel på deras lösning var. 4 switchar och det går 2 kablar mellan varje switch. så 3 switchar kan dö och allt funkar. och 5 kablar. kunde gå sönder.
Dock måste det ju vara rätt dyra switchar så dom kan klara av detta. Men cisco klarar ju det men även 3Com´s switchar fixar det. Men där hyrde dom en kille som konfade dessa switchar och det är ju inte billigt.

Själv förstår jag inte varför inte folk använder Magnetbad till backup.