Varför ett kluster med två noder är det sämsta valet: majoritetsfrågan

Du köpte den andra servern och byggde ett kluster. Du känner dig tryggare: nu finns två maskiner, och faller den ena fortsätter den andra.

Det gör den inte. Ett kluster med två noder är skörare än en ensam nod, och den dag du lär dig det är oftast en dålig dag.

Varför

Klusterbeslut fattas med majoritet. Står två av tre noder uppe finns majoritet och klustret fortsätter arbeta. Faller den ena av två noder är den kvarvarande enda noden ingen majoritet, så klustret låser sig självt: maskinerna fortsätter köra, men inställningarna går inte att ändra, ingen ny maskin startar och det mesta av förvaltningsarbetet stannar.

Detta är ingen brist utan en medveten konstruktion. Alternativet är långt värre: när två noder inte längre ser varandra säger båda "jag är uppe, den andra föll" och startar samma virtuella maskin på två ställen. Samma disk skrivs från båda håll och data skadas utan återvändo.

Klustret skyddar dig alltså genom att låsa ute dig. Men med två noder slår det skyddet till vid hälften av alla fel.

Rätt antal är tre

I ett kluster med tre noder återstår två om en faller, majoriteten håller och livet går vidare. Därför dyker siffran tre upp överallt i klusterdokumentationen.

Den tredje maskinen behöver inte vara kraftfull. Den avger bara en röst, den behöver inte köra något arbete. En liten maskin, till och med en gammal dator, duger.

Vill du verkligen inte ha en tredje maskin går det i stället att sätta upp en liten vittnesnod som bara finns för att rösta. Den är ingen fullvärdig nod och du kan inte köra maskiner på den, men den fyller ut majoritetsräkningen till tre. Stannar du på två noder, sätt åtminstone upp den.

Stannar du på två noder, vet detta

När en nod tas ur för underhåll blir även den kvarvarande enda noden ohanterlig. Alltså lämnar även en planerad uppdatering dig utelåst.

Det går att för hand säga "låt även en ensam nod besluta", men det öppnar precis den dubbelstartsrisk som beskrivs ovan. Det görs tillfälligt, medvetet och kort; någon varaktig lösning är det inte.

Att bygga ett kluster är inte att ta säkerhetskopior

Detta är de två saker som oftast blandas ihop. Ett kluster är till för tillgänglighet: för att arbetet ska fortsätta när en maskin faller. En säkerhetskopia är till för återställning: för att komma tillbaka efter att data skadats eller raderats av misstag.

Ett kluster hämtar inte tillbaka en virtuell maskin du raderade av misstag. Raderingen sprids omedelbart till alla noder, för ett kluster finns just för att de ska se samma sak. Även med kluster kommer du att behöva säkerhetskopior.

Vad Atlas gör

Atlas behandlar klustret inte som ett begrepp utan som ett tillstånd: hur många noder som finns, hur många som röstar, om majoriteten håller just nu.

Där det hjälper mest är vid uppdatering. Innan en nod uppdateras tittar Atlas på hur många av maskinerna på den som kan flytta till en annan nod och föreslår dig en ordning. Förslaget förblir ett förslag: flyttkommandot körs inte av sig självt, du trycker på knappen.

En detalj väger särskilt tungt här och träffar precis den här artikelns ämne. Kommandot som frågar efter klustrets tillstånd misslyckas på samma sätt i två olika lägen: att verkligen vara en fristående maskin, och att vara medlem i ett kluster vars klusterlager har rasat. Skiljs dessa två inte åt säger produkten "inget kluster, majoritet i sin ordning" i exakt det ögonblick klustret har rasat. Den formulerar alltså den mest lugnande meningen i det farligaste ögonblicket.

Atlas skiljer dem åt genom att se om inställningsfilen finns: den filen skrivs tillsammans med medlemskapet och ligger kvar även när klusterlagret rasar. Skillnaden bor på ett enda ställe, för tidigare var den skriven separat på tre olika ställen och alla tre hade samma fel.