Hvorfor en klynge med to knuder er det dårligste valg: flertalsspørgsmålet

Du købte server nummer to og byggede en klynge. Du føler dig tryggere: nu står der to maskiner, og falder den ene, fortsætter den anden.

Det gør den ikke. En klynge med to knuder er skrøbeligere end en enkelt knude, og den dag, du lærer det, er som regel en dårlig dag.

Hvorfor

Klyngebeslutninger træffes ved flertal. Står to af tre knuder oppe, er der flertal, og klyngen arbejder videre. Falder den ene af to knuder, er den tilbageværende ene knude ikke et flertal, så klyngen låser sig selv: maskinerne kører videre, men opsætningen kan ikke ændres, ingen ny maskine starter, og det meste af administrationsarbejdet går i stå.

Det er ikke en mangel, men et bevidst design. Alternativet er langt værre: når to knuder ikke længere kan se hinanden, siger begge "jeg er oppe, den anden faldt" og starter den samme virtuelle maskine to steder. Der skrives til den samme disk fra begge sider, og dataene ødelægges uden vej tilbage.

Klyngen beskytter dig altså ved at lukke dig ude. Men med to knuder slår den beskyttelse til ved halvdelen af alle fejl.

Det rigtige tal er tre

I en klynge med tre knuder er der to tilbage, hvis én falder, flertallet holder, og livet går videre. Derfor dukker tallet tre op overalt i klyngedokumentationen.

Den tredje maskine behøver ikke være kraftig. Den afgiver kun en stemme, den behøver ikke køre arbejde. En lille maskine, endda en gammel computer, klarer opgaven.

Vil du virkelig ikke have en tredje maskine, kan du i stedet sætte en lille vidneknude op, som kun findes for at stemme. Den er ikke en fuldgyldig knude, og du kan ikke køre maskiner på den, men den fylder flertalsregnskabet op til tre. Bliver du på to knuder, så sæt i det mindste den op.

Bliver du på to knuder, så vid dette

Når en knude tages ud til vedligeholdelse, bliver også den tilbageværende enkelte knude umulig at styre. Selv en planlagt opdatering efterlader dig altså låst ude.

Det er muligt i hånden at sige "lad også en enkelt knude beslutte", men det åbner præcis den dobbeltstartsrisiko, der er beskrevet ovenfor. Det gøres midlertidigt, bevidst og kortvarigt; en varig løsning er det ikke.

At bygge en klynge er ikke at tage sikkerhedskopi

Det er de to ting, der oftest forveksles. En klynge er til tilgængelighed: for at arbejdet fortsætter, når en maskine falder. En sikkerhedskopi er til gendannelse: for at komme tilbage, efter at data er blevet ødelagt eller slettet ved en fejl.

En klynge henter ikke en virtuel maskine tilbage, som du slettede ved et uheld. Sletningen breder sig til alle knuder med det samme, for en klynge findes netop for, at de ser det samme. Selv med klynge får du brug for sikkerhedskopier.

Hvad Atlas gør

Atlas behandler klyngen ikke som et begreb, men som en tilstand: hvor mange knuder der er, hvor mange der stemmer, om flertallet holder lige nu.

Der, hvor det hjælper mest, er ved opdatering. Før en knude opdateres, ser Atlas på, hvor mange af maskinerne på den der kan flytte til en anden knude, og foreslår dig en rækkefølge. Forslaget forbliver et forslag: flyttekommandoen kører ikke af sig selv, du trykker på knappen.

En detalje vejer særligt tungt her og rammer præcis denne artikels emne. Kommandoen, der spørger om klyngens tilstand, fejler på samme måde i to forskellige situationer: virkelig at være en fritstående maskine, og at være medlem af en klynge, hvis klyngelag er brudt sammen. Skelnes der ikke mellem de to, siger produktet "ingen klynge, flertal i orden" netop i det øjeblik, klyngen er brudt sammen. Det former altså den mest beroligende sætning i det farligste øjeblik.

Atlas skelner dem ved at se, om opsætningsfilen findes: den fil skrives sammen med medlemskabet og bliver liggende, også når klyngelaget bryder sammen. Skellet bor ét eneste sted, for før var det skrevet hver for sig tre forskellige steder, og alle tre havde den samme fejl.