Redundans - när inget får gå fel

Tråden skapades och har fått 49 svar. Det senaste inlägget skrevs .

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

Trevlig läsning! Desto mindre trevlig är den bistra verkligheten om att "om saker kan gå fel så blir det fel", om än en något bister sanning med viss besserwisser attityd så det tyvärr så. (jag försöker inte klandra någon här utan bara konstaterar).

En sak jag kanske vill tillägga är om man verkligen kör "mission critical" saker är att sprida ut sina risker på mer än en datahall, både vad gäller servrar och DNS mm, om det blir strömavbrott i datahallen, eller någon stackars kommunarbetare gräver över alla fiber kabler (som faktiskt har hänt) så sitter man i smeten, oavsett nivån av säkerhet och redundans internt i datahallen.

Vilket tyvärr är, som Martin, långt ifrån billigt! Något som man inte får för 500 spänn per år på "det billigaste" webhotellet..
Visst, "Koffes hemsida om katter" behöver ju inte det, men det finns tyvärr företag som har miljoner satsat på något som kan gå sönder mer eller mindre närsomhelst, som i exemplet björnström gav...

Intressant läsning! Det är mycket som ligger bakom allting och som man kanske inte alltid tänker på.

/Kristofer

OpenBSD 3.5 kommer med en funktion som kallas CARP (Common Address Redundancy Protocol), vilket tillåter två OpenBSD-burkar att "vara samma" brandvägg/server eller liknande. Verkar skitgulligt.

Edit: Länk, http://www.openbsd.org/cgi-bin/man.cgi?query=carp

Tur att du/ni inte var i Texas eller långt borta denna gång.

Lite läskigt hur sårbart samhället är.

Skall maila din text till vår bredbandsleverantör. Teleservice i Sjöbo . Vi var utan bredband ett antal dagar för ett tag sedan. Inte bra om man har en deadline med text och bilder. Kan bli väldigt stressigt när man sitter i obygden och har blivit beroende av distanskommunikation.

  • Oregistrerad
  • 2004-04-17 20:47

Intressant läsning!

Ibland hjälper det inte hur noga man försöker vara.
Den bifogade bilden visar en installation jag såg hos ett företag. Installationen var trot eller ej gjort av ett företag i branschen. Företagets växel, ADSL, switchar mm allt 'snyggt' monterat på ett mobilt rack. Notera också hur enkelt stömbackupen är arrangerad, byt bara kabelvinda och saken är biff! Kolla även vilken fin överblick man har på allt kablage, inget dolt här inte.

Går nått åt skogen, behöver man ju bara köra in en backup pall! Kan det bli enklare?

Ursprungligen av FrejaII:

Intressant läsning!

Ibland hjälper det inte hur noga man försöker vara.
Den bifogade bilden visar en installation jag såg hos ett företag. Installationen var trot eller ej gjort av ett företag i branschen. Företagets växel, ADSL, switchar mm allt 'snyggt' monterat på ett mobilt rack. Notera också hur enkelt stömbackupen är arrangerad, byt bara kabelvinda och saken är biff! Kolla även vilken fin överblick man har på allt kablage, inget dolt här inte.

jäklar!! Den borde ju nästan vara i samma liga som dessa

Citat:

Går nått åt skogen, behöver man ju bara köra in en backup pall! Kan det bli enklare?

Jag garvade rejält åt den, tack!

Ursprungligen av FrejaII:

Intressant läsning!

Den bifogade bilden visar en installation jag såg hos ett företag.

Jag tjuter av skratt här!

  • Oregistrerad
  • 2004-04-17 20:45
Citat:

Klockan är 01.32 natten mot lördagen när ett SMS varnar för att vår serverfarm har tappat kontakten med internet.

Hur fungerar det som? Har du en annan anslutning som kontrollerar var 30:e sekund eller så om den andra anslutningen är uppe, och som vid fel skickar ett sms?

Jag har varit intresserad av en sådan lösning själv, behövs det någon hårdvara/mobilabonnemang eller är det mjukvara som skickar via nån internetsida som skickar ut det som sms?

  • Medlem
  • Stockholm
  • 2004-04-20 12:40
Ursprungligen av Krokodilen:

Hur fungerar det som? Har du en annan anslutning som kontrollerar var 30:e sekund eller så om den andra anslutningen är uppe, och som vid fel skickar ett sms?

Jag har varit intresserad av en sådan lösning själv, behövs det någon hårdvara/mobilabonnemang eller är det mjukvara som skickar via nån internetsida som skickar ut det som sms?

Kolla in Nagios (http://www.nagios.org/) för att sätta upp övervakning. Sen rekommenderar jag att hänga en GSM-mobil på en server i serverhallen så att du kan få SMS även (speciellt) när kontakten med internet gått ner. Jag har inga länkar till GSM-modem eller mjukvara men det ska nog inte vara några problem att sätta upp (i värsta fall får man väl skriva ett skript som skickar AT-kommandona själv).

Var det nere i natt igen eller var det fel hos mig?

nej det var nere imorse också.

  • Medlem
  • 2004-04-18 12:41

De senaste dagarnas problem får mig känna att jag har tagit rätt beslut när jag lagt ut mail och webb på "riktiga" webbhotell åt kunder. Det är enklare och billigare i längden att låta ett företag stå för driften än att själv hålla på med sånt när man har användare på systemen dygnet runt.

Detta ska inte tas som nån kritik, bara som ett enkelt konstaterande att det är mycket som kan gå fel och det är lättare att köpa service och support än att själv rycka in mitt i natten.

Ursprungligen av lime:

De senaste dagarnas problem får mig känna att jag har tagit rätt beslut när jag lagt ut mail och webb på "riktiga" webbhotell åt kunder. Det är enklare och billigare i längden att låta ett företag stå för driften än att själv hålla på med sånt när man har användare på systemen dygnet runt.

Detta ska inte tas som nån kritik, bara som ett enkelt konstaterande att det är mycket som kan gå fel och det är lättare att köpa service och support än att själv rycka in mitt i natten.

Det är ett vettigt beslut - vi gör likadant med shopsystemen som MantaRay levererar åt kunder: dom placeras på Levonline:s webbkluster som i stort sett aldrig är nere.

Tyvärr innebär det också begränsningar i valmöjligheterna så det är alltid en avvägning.

I vårt fall arbetar brandvägg och mailserver tätt ihop (mac.se) så vi måste ha en egen brandväggslösning. Forumen drar så mycket CPU att vi inte är välkomna i vanliga driftsmiljöer - vår MySQL burk har hälften så många SQL-anrop som hela Levonline:s klustermiljö med tiotusen hostingavtal (!).

När redundans går fel

Ursprungligen av Björnström:

Det är ett vettigt beslut - vi gör likadant med shopsystemen som MantaRay levererar åt kunder: dom placeras på Levonline:s webbkluster som i stort sett aldrig är nere.

Tyvärr innebär det också begränsningar i valmöjligheterna så det är alltid en avvägning.

I vårt fall arbetar brandvägg och mailserver tätt ihop (mac.se) så vi måste ha en egen brandväggslösning. Forumen drar så mycket CPU att vi inte är välkomna i vanliga driftsmiljöer - vår MySQL burk har hälften så många SQL-anrop som hela Levonline:s klustermiljö med tiotusen hostingavtal (!).

Dessvärre är det inte alltid som redundans är till nytta. Hos nämnda webbhotell har jag två gånger råkat ut för nedtid just på grund av redundans. En gång var det ett par timmar då deras brandväggar tydligen inte kunde enas om vilken av dem som för tillfället hade hand om trafiken. Tyvärr detekterade inte larmsystemet tillståndet så felet upptäcktes först efter några timmar.

En annan gång drabbades webbklustrets gemensamma filserver av kernel-panic när en av de redundanta och påstått hotswapable hårddiskarna skulle bytas. Nertid drygt en timme. Sedermera byttes filservern ut och sen dess har vi inte sett till det felet igen.

Min poäng är att redundans långt ifrån bara är en lösning på problem utan också en källa till dem! Därför måste man fråga sig hur livsviktig tillgängligheten är och vad detta är värt i pengar. Utan att på något sätt förringa värdet av online-forum måste jag ändå säga att så länge inte människor dör eller skadas till följd av driftavbrott är de av en sådan art att de kan hanteras. Sedan finns det den typen av system som är affärskritiska, men där finns det ju också naturliga ekonomiska incitament att investera för att minimera avbrott.

Vi har höjt nivån på vårt serviceavtal ifrån 08-18 till 24/7/365 så att jourtekniker finns tillgängliga dygnet runt. Om något händer nattetid finns det möjlighet att kalla på hjälp så att vi inte behöver vänta till normal kontortstid.

  • Medlem
  • 2004-04-18 20:16

jaså ... det var det som var felet. tråkigt ...

  • Oregistrerad
  • 2004-04-18 20:45

Ok, jag vill fortfarande ha svar på min post ovan!

vore trevligt iaf...

  • Oregistrerad
  • 2004-04-18 20:55
Ursprungligen av Krokodilen:

Ok, jag vill fortfarande ha svar på min post ovan!

vore trevligt iaf...

Finns ju massa små burkar för maskinövervakning som pollar plc:n med jämna intervall och som skickar ett sms om svar uteblir…
Borde väl få att funka med en dator tycker man, räkna med runt femtonhundra pix.

  • Oregistrerad
  • 2004-04-18 21:39

har du nån länk?

  • Oregistrerad
  • 2004-04-18 21:49

Nä, men ser dom i tidningar titt som tätt…
Kommer jag ihåg'et så skall jag kleta in en länk.

[Finns något firma i Alingsås som håller på mycket med såntdär, men det var någon oskarshamn eller liknande hade en jäkligt flexibel och käck modell… Minns inte mer än att jag köpte lite radiorör av gube jobbade där :-)]

  • Medlem
  • Uppsala
  • 2004-04-18 23:25

Murphy´s lag säger ju såklart att om man har supportavtal vardagar 8-18 så inträffar naturligtvis felet fredag natt.....typiskt.

Nåja, vill skjuta in här att det faktiskt finns standard (ISO 17799) som bla. innehåller kontinuitetspalnering. Värt att att se över för att vara hyfsat säker på att man täckt det mesta. Oftast inser man inte hur sårbar den egna verksamheten är innan det verkligen inträffar något oväntat allvarligt med långt stopp som följd.

  • Medlem
  • 2004-04-19 09:25

hade ni problem med servern i natt i gen vid 03:00?

Jag hade lite problem att komma in nu på morgonen också.

  • Medlem
  • 2004-04-19 09:48

provade pinga deras ip i nat men fick ingen kontakt med servern als. troligen wall som krånglar kan jag gissa

Vi analyserar vad som går fel - det finns en hel del loggar att gå igenom.

Vi har över 3000st portscan mellan 03:00 och 03:02 inatt, ska försöka reda ut om det har något med saken att göra. Den dör nämligen innan 03:03 (brandväggens systemtid).

Ursprungligen av Björnström:

Vi analyserar vad som går fel - det finns en hel del loggar att gå igenom.

Vi har över 3000st portscan mellan 03:00 och 03:02 inatt, ska försöka reda ut om det har något med saken att göra. Den dör nämligen innan 03:03 (brandväggens systemtid).

Borde inte brandväggen klara av det?

Ursprungligen av ohennig:

Borde inte brandväggen klara av det?

Jo, verkligen.

Men som sagt - vi försöker reda ut vad som har hänt och det här kan vara en ledtråd.
Jag vill påminna om att vi hade 100% uptime sedan 1:a Oktober och att vi inte haft problem som dessa tidigare. Därför är det intressant att samma sak händer tre nätter i rad.

Vi vågar inte chansa på ett till driftstopp så vi har köpt in fetare grejer under morgonen som vi installerar senare idag. Då får vi 1GB RAM i brandväggen och dubbelt så snabb hårdvara.

  • Medlem
  • 2004-04-19 09:58

mm det stemer att den gick ner då för jag sat och läste atikeln du skrev om HårdvaraKrönika: Redundans - när inget får gå fel och sen när jag skule backa till backa till siden prik 03:07 så gick det inte fick ej kåntakt med servern. skelv tyckte jag det va eroniskt föst läsa atikeln och sen ska man till backa till sidan så äe server nere

  • Medlem
  • 2004-04-19 11:03

Björnström alvarligt hur mycket pengar har ni att läga ut på era servrar och servis?

Bevaka tråden