Hvorfor en klynge med to noder er det dårligste valget: flertallsspørsmålet

Du kjøpte tjener nummer to og bygde en klynge. Du føler deg tryggere: nå står det to maskiner der, og faller den ene, fortsetter den andre.

Det gjør den ikke. En klynge med to noder er skjørere enn én enkelt node, og dagen du lærer det, er som regel en dårlig dag.

Hvorfor

Klyngebeslutninger tas med flertall. Står to av tre noder oppe, finnes det flertall og klyngen arbeider videre. Faller den ene av to noder, er den gjenværende ene noden ikke et flertall, så klyngen låser seg selv: maskinene fortsetter å kjøre, men oppsettet kan ikke endres, ingen ny maskin starter, og det meste av forvaltningsarbeidet stopper.

Dette er ingen mangel, men en villet utforming. Alternativet er langt verre: når to noder ikke lenger ser hverandre, sier begge "jeg er oppe, den andre falt" og starter den samme virtuelle maskinen to steder. Den samme disken skrives fra begge sider, og dataene ødelegges uten vei tilbake.

Klyngen beskytter deg altså ved å låse deg ute. Men med to noder slår den beskyttelsen inn ved halvparten av alle feil.

Riktig tall er tre

I en klynge med tre noder er det to igjen om én faller, flertallet holder og livet går videre. Derfor dukker tallet tre opp overalt i klyngedokumentasjonen.

Den tredje maskinen trenger ikke være kraftig. Den avgir bare en stemme, den trenger ikke kjøre arbeid. En liten maskin, til og med en gammel datamaskin, klarer jobben.

Vil du virkelig ikke ha en tredje maskin, kan du i stedet sette opp en liten vitnenode som bare finnes for å stemme. Den er ingen fullverdig node, og du kan ikke kjøre maskiner på den, men den fyller flertallsregnestykket opp til tre. Blir du stående på to noder, sett i det minste opp denne.

Blir du stående på to noder, vit dette

Når én node tas ut til vedlikehold, blir også den gjenværende enkeltnoden umulig å styre. Altså etterlater selv en planlagt oppdatering deg utelåst.

Det går an å si for hånd "la også én enkelt node bestemme", men det åpner nøyaktig den dobbeltstartrisikoen som er beskrevet over. Det gjøres midlertidig, bevisst og kort; noen varig løsning er det ikke.

Å bygge en klynge er ikke å ta sikkerhetskopi

Dette er de to tingene som oftest blandes sammen. En klynge er til for tilgjengelighet: for at arbeidet skal fortsette når en maskin faller. En sikkerhetskopi er til for gjenoppretting: for å komme tilbake etter at data ble ødelagt eller slettet ved et uhell.

En klynge henter ikke tilbake en virtuell maskin du slettet ved et uhell. Slettingen sprer seg til alle noder med det samme, for en klynge finnes nettopp for at de skal se det samme. Selv med klynge kommer du til å trenge sikkerhetskopier.

Hva Atlas gjør

Atlas behandler klyngen ikke som et begrep, men som en tilstand: hvor mange noder som finnes, hvor mange som stemmer, om flertallet holder akkurat nå.

Der dette hjelper mest, er ved oppdatering. Før en node oppdateres, ser Atlas på hvor mange av maskinene på den som kan flytte til en annen node, og foreslår deg en rekkefølge. Forslaget forblir et forslag: flyttekommandoen kjører ikke av seg selv, du trykker på knappen.

Én detalj veier særlig tungt her, og treffer nøyaktig emnet for denne artikkelen. Kommandoen som spør om klyngens tilstand, mislykkes på samme måte i to forskjellige situasjoner: virkelig å være en frittstående maskin, og å være medlem av en klynge der klyngelaget har brutt sammen. Skilles ikke disse to, sier produktet "ingen klynge, flertall i orden" nettopp i det øyeblikket klyngen har brutt sammen. Det former altså den mest beroligende setningen i det farligste øyeblikket.

Atlas skiller dem ved å se om oppsettsfilen finnes: den filen skrives sammen med medlemskapet og blir liggende også når klyngelaget bryter sammen. Skillet bor på ett eneste sted, for tidligere var det skrevet hver for seg tre ulike steder, og alle tre hadde den samme feilen.