High availability – vad är det?

Med anledning av de senaste dagarnas datastrul vid hälsocentralerna i Pargas tänkte jag skriva några ord om high availability (HA, ”hög tillgänglighet” på svenska). Ett HA-system är ett datasystem som måste vara tillgängligt dygnet runt och som helst aldrig får sluta fungera utom vid planerade avbrott.

Olika system kan ha olika krav på HA. Kritiska system som t.ex. flygledarsystem eller nödcentralernas datasystem kan ha väldigt höga HA-krav (systemet får vara utslaget högst några minuter på årsnivå), medan mindre kritiska system kan tillåta avbrott på t.ex. några timmar. Kostnaderna för utveckling och underhåll stiger då HA-kraven stiger och därför är det viktigt att se till att HA-kraven hålls på en realistisk och kostnadseffektiv nivå.

Principerna för att uppfylla HA-kraven är egentligen rätt enkla:

  1. Identifiera alla enskilda komponenter som kan dra ner systemet om de går sönder. På engelska talar man om Single Points of Failure (SPOF).
  2. Avlägsna så många SPOFs som möjligt. Detta sker vanligtvis genom någon form av redundans, vilket betyder att om en komponent går sönder så finns det en annan likadan som kan ta över. Ett annat sätt är att bygga resten av systemet på ett sådant sätt att det kan kringgå eller kompensera för den söndriga komponenten tills den har ersatts eller reparerats (kallas resilience på engelska).
  3. Gör upp en plan för hur systemet kan köras igång på nytt om allting skulle gå på tok och öva planen regelbundet.

I praktiken är detta mycket lättare sagt än gjort, men jag ska ändå försöka beskriva principerna i praktiken med några exempel.

Till att börja med måste vi fundera på vad som kan gå sönder och det är inte lite det (emellanåt förundras jag över att systemen överhuvudtaget fungerar så bra som de gör, med tanke på hur mycket som kan gå på tok). Hårdskivor kan gå sönder, strömenheter kan brinna upp, nätverkskablar kan gå av, nätverksväxlar och routers kan sluta fungera, osv. I princip allt kan gå sönder och alla komponenter som det bara finns ett exemplar av är därför ett potentiellt hot mot driftssäkerheten.

När vi nu känner till systemets svaga punkter är det dags att förstärka dem. Om vi börjar med den enskilda servern (huvuddatorn) så kan man t.ex. ha dubbla strömkällor, två eller flera hårdskivor som speglar varandra (s.k. RAID), två nätverkskort, osv. Det här är en bra början, men inte tillräckligt. Det är fortfarande fullt möjligt för t.ex. två hårdskivor att gå sönder samtidigt (de kanske har tillverkats samtidigt och slitits lika mycket).

Följande steg är då att ha flera servers som alla kör samma program och innehåller samma information. Om den ena servern går sönder, kan den andra ta över. Det här kan man göra på olika sätt, beroende på hur höga HA-krav systemet har:

  • En ”kall standby” är en reservserver som installeras, konfigureras och startas först då huvudservern går sönder. Informationen återställs manuellt från senaste säkerhetskopian. Har man en kall standby kan man räkna med att det tar några timmar att få igång systemet igen. Information som ändrats efter senaste säkerhetskopian går förlorad.
  • En ”varm standby” är en reservserver som är installerad på samma sätt som huvudservern, är igång hela tiden och automatiskt får säkerhetskopior från huvudservern med jämna mellanrum (t.ex. några gånger i timmen). Då huvudservern går sönder kan reservservern köra igång programmen och ta över. Har man en varm standby kan man räkna med att det tar några minuter att få igång systemet igen. Information som ändrats efter senaste säkerhetskopian går förlorad.
  • En ”het standby” är en identisk kopia av huvudservern som i realtid synkroniserar sin information. Då huvudservern går sönder kan reservservern ta över omedelbart, t.o.m. så att användarna inte märker någonting. Har man en het standby kan man räkna med att det tar några sekunder att få igång systemet igen och endast den information som höll på att ändras just då huvudservern kraschade går förlorad (om allt går som det ska).

Utöver ett system med standbyservers behöver man även olika stödkomponenter. Det behövs t.ex. ett system som följer upp hur de olika maskinerna mår och som kan skrida till åtgärder (helst utan mänskligt ingripande) om någonting går på tok. Här är ett exempel:

HA

Systemet i fråga består av två servers, en huvudserver och en het standby. All användartrafik går via en s.k. load balancer (”belastningsutjämnare” på svenska), som styr trafiken till rätt server.

Både huvudservern och standbyservern skickar med jämna mellanrum hjärtslagssignaler (heartbeats) till load balancern. Om huvudserverns signal upphör tolkar load balancern situationen som att det är något fel på huvudservern, och all trafik börjar automatiskt styras över till standbyservern i stället.

Den uppmärksamme läsaren frågar nu vad som händer om load balancern går sönder? Det är en bra fråga, för i bilden ovan är load balancern faktiskt en Single Point of Failure. I praktiken finns det dock system som gör det möjligt att dubblera också denna komponent, om man anser att det är nödvändigt.

Vill man måla fan på väggen så är förstås följande fråga vad som händer om det t.ex. börjar brinna i maskinrummet och både huvudservern och reserven slås ut? Då kan man ha reservmaskinrum som kanske t.o.m. är placerade i olika städer eller rentav på olika kontinenter (jo, sådant förekommer).

Slutligen är det viktigt att man trots alla reservsystem och reservreservsystem tar regelbundna säkerhetskopior och förvarar dem omsorgsfullt. Då kan man bygga upp systemet på nytt från grunden ifall precis allting skulle gå på tok. Det är alltid bra att ha Murphys lagar i tankarna då man håller på med IT:

  • Om någonting kan gå fel, så kommer det förr eller senare att göra det.
  • Om någonting inte kan gå fel, så kommer det att göra det ändå.
  • Vetskap om Murphys lagar gör det inte möjligt att kringgå dem.

Foto: http://www.stockphotosforfree.com/free-stock-photos/p-54869-flaming-desktop-computer.html

Sova. Det är svårt, det.

Vår yngsta son hade kolik under sina första levnadsmånader. Det var en mycket tung period och jag minns inte speciellt mycket av den. Har visst skrivit någonting om det i denna blogg också. Oberoende så gick det ju till sist över och sonen kunde börja sova ordentligt igen. Ända tills för någon månad sedan.

Det är få kvällar och nätter numera då han inte skriker, ibland tills han nästan storknar, då han skall sova. Antingen skriker han före han somnar, eller så somnar han lugnt och vaknar efter en stund och skriker. Det enda som brukar hjälpa är att mata i honom mjölkflaska efter mjölkflaska, utom då det inte hjälper (han har aldrig använt tutt och avskyr den). Ibland får han dessutom hård mage av all mjölk och då skriker han ännu mera (ibland har man fått hälla i honom över 6 dl mjölk under en natt).

Jag begriper inte vad det är som är fel. Han skriker och vänder och vrider sig som om han skulle ha jätteont, men dom gånger vi gett burana åt honom brukar han lugna sig långt före medicinen har hunnit ha effekt. Ibland har han luftbesvär eller hård mage och då kan jag förstå att det kanske inte är så lätt att sova. På dagarna är han en pigg och glad pojke som äter och växer och utvecklas utan några problem. På nätterna förhandlas han till något annat.

Jag går bara och väntar på att också den här perioden skall ta slut och att han ska kunna börja sova lugnt igen. Han har det knappast speciellt lätt själv heller, vilket jag borde försöka komma ihåg varje gång jag blir irriterad över skrikandet (vilket tyvärr händer rätt ofta).