När strömmen går

När strömmen går i ett fabriksdatacenter händer två saker samtidigt. UPS:en tar över, och en klocka börjar ticka. Hur lång tid som finns beror på batterierna, lasten och hur gamla batterierna är. Vad som händer under den tiden beror helt på hur väl man har förberett sig.

En UPS köper minuter, inte säkerhet. Om servrarna fortfarande är igång när batterierna tar slut stängs allt av hårt, samtidigt, mitt i skrivningar. Det är så man förlorar data, får korrupta databaser och ett kluster som inte vill starta igen.

Vet hur mycket tid du faktiskt har

Den angivna drifttiden på en UPS gäller en viss last och nya batterier. Verkligheten är en annan last och batterier som har åldrats. Därför behöver man:

• mäta den faktiska lasten, inte räkna på typskyltarnas maxvärden,
• räkna med marginal för batteriernas åldrande,
• ta med allt som måste vara igång för att nedstängningen ska fungera: nätverksswitchar, brandvägg och hanteringsservrar.

Om nätverket dör före servrarna kan nedstängningskommandona inte nå fram. Det är ett vanligt misstag att bara räkna på servrarna.

Styrd nedstängning i rätt ordning

Poängen med styrd nedstängning är att programvara, inte batteriet, avgör när och hur saker stängs av. En agent eller hanteringsprogramvara pratar med UPS:en och kör en plan när strömmen har varit borta en viss tid eller när batterinivån når en gräns.

I en virtualiserad miljö är ordningen viktig:

1. Applikationernas virtuella maskiner stängs ner först, i en ordning som respekterar beroenden. Applikationsservrar före databaser.
2. Infrastrukturtjänster som katalogtjänst och hantering stängs sist bland de virtuella maskinerna.
3. Klustret förbereds, så att lagringen är i ett konsistent läge.
4. Värdarna stängs av.

Ordningen ska vara nedskriven och testad, inte något man hoppas att programvaran gör rätt.

Kluster över flera platser kräver flera scenarier

I ett kluster där noderna står på två olika platser, kanske i två olika byggnader inom samma fabrik med en tredje punkt som vittne, är strömavbrott inte ett enda scenario. Det kan vara:

• den ena platsen som tappar ström,
• den andra platsen som tappar ström,
• båda samtidigt.

Om bara en plats förlorar strömmen vill man oftast inte stänga av allt. Klustret är byggt för att den andra platsen ska ta över. Nedstängningen måste alltså förstå feldomänerna och bara stänga av det som verkligen är hotat. Det är där en enkel "stäng av allt vid 50 procent batteri" blir fel.

Den logiken tar tid att ta fram, och den behöver göras tillsammans med de som känner både strömförsörjningen och applikationerna. Men det är skillnaden mellan ett kluster som rider ut ett lokalt avbrott och ett som stänger ner sig själv i onödan.

Uppstarten är halva jobbet

När strömmen kommer tillbaka ska allt upp i omvänd ordning, och det är lätt att glömma. Startar värdarna automatiskt? Väntar de tills nätverket är uppe? Startar de virtuella maskinerna i rätt ordning, eller försöker applikationerna nå en databas som inte finns än? Skriv en uppstartsplan och kontrollera den, inte bara nedstängningen.

Testa – med produktionens tillstånd

Den enda gången man på riktigt vet att planen fungerar är när man har testat den. Det kräver ett planerat fönster och produktionens godkännande, och det är värt det. Ett test avslöjar nästan alltid något: ett nätverkskort som inte hanteras av UPS:en, ett lösenord som har ändrats, en virtuell maskin som inte stängs av inom tidsgränsen.