Konfigurationen blev skrivebeskyttet: derfor er stedet, den bor, anderledes

Du prøver at redigere en fil, og tilladelsen nægtes. Du er root. Der er plads på disken. Alligevel kan du ikke skrive.

Der er ikke noget i stykker her. Stedet, du kigger på, er ikke en almindelig mappe, og det afviser skrivning med vilje.

Stedet, hvor konfigurationen bor, er ikke en mappe

Proxmox opbevarer maskinkonfigurationer, lagerdefinitioner, firewallregler og sikkerhedskopijobs ét sted. Det ligner et filsystem, det har mapper og filer, men bagved sidder en lille database, og den database kopieres til hver node i klyngen.

Grunden er enkel: alle servere i en klynge skal se den samme maskindefinition. Skal du flytte en maskine fra én server til en anden, skal modparten allerede vide, hvordan den maskine er defineret. Var konfigurationen en almindelig fil på én servers disk, ville de andre ikke vide af den.

Denne opbygning har tre følger, og alle tre dukker op i hverdagen.

Følge et: uden flertal afvises skrivning

Ser en server ikke flertallet af klyngen, lukkes skrivningen. Læsning bliver ved med at virke, skrivning holder op.

Det er ikke en fejl, det er en beslutning. Hvis nettet delte sig i to, og begge halvdele kunne skrive, ville den samme maskine ende med to forskellige definitioner. Når nettet kom tilbage, kunne ingen sige, hvilken der var rigtig, og der ville ikke være nogen måde at samle dem på. I stedet vælger systemet dette: den side, der bliver i mindretal, holder op med at skrive.

Hvordan et flertal tælles i en klynge, og hvorfor opstillinger med to servere er besværlige, står i en egen artikel. Det eneste at tilføje her er, at det er præcis sådan, den flertalsregel føles i praksis: pludselig ikke at kunne skrive.

Følge to: den samme struktur kører også på en enkelt server

Selv uden klynge er denne struktur i drift. En enkelt server er i sig selv et flertal, så normalt går intet galt.

Men er tjenesten, der leverer den struktur, ikke rask, ser du det samme symptom også på en enkelt server. Så "jeg har ingen klynge, det kan ikke ske for mig" passer ikke.

Der er også en mindre kendt vej: databasen bag denne struktur ligger på den lokale disk. Når den lokale disk fyldes, mislykkes skrivninger, og for dig ser det ud, som om du ikke kan ændre indstillinger. Symptomet er på konfigurationssiden, årsagen på lagersiden.

Følge tre: alt, hvad du skriver der, går til alle

Muligheden "jeg ændrer det kun på denne maskine" findes ikke. Det, der skrives der, når hver node i klyngen.

Den klassiske fejl, begået uden at vide dette, er at lave en prøveændring på én node og antage, at den ikke rammer de andre.

Endnu et punkt: det sted blev lavet til konfiguration, ikke til data. Små tekstfiler hører til der; scripts, arkiver og sikkerhedskopier gør ikke. Vænn dig ikke til at efterlade filer der.

Kan du ikke skrive, så tjek i rækkefølge

Tjek først flertallet: ser serveren resten af klyngen? Gør den ikke det, ligger det virkelige problem i nettet, og konfigurationsfilen er uskyldig.

Tjek så tjenesten: kører tjenesten, der leverer denne struktur?

Tjek så den lokale disk: er den fuld, er vejen ovenfor i spil.

Og den sidste, den der oftest springes over: en node kan have forladt klyngen. Et netværksudfald, en slukket nabo, en forkert opsat firewallregel. Symptomet ser altid ens ud, årsagen er et andet sted hver gang.

Hvad Atlas gør

Atlas læser denne struktur direkte som filer i stedet for at køre systemets forespørgselsværktøj hver gang.

Vi målte hvorfor. Hvert kald til det værktøj koster mellem hundrede og to hundrede millisekunder processortid og omkring hundrede megabyte midlertidig hukommelse. Med panelet åbent sker der en opdatering hvert tiende sekund, og hver opdatering kræver otte til ti kald. Med andre ord: overvågningen skabte en vedvarende svingning på netop den server, den overvågede.

At læse den samme information fra en fil tager mikrosekunder. Forskellen er tusindfold, og den forskel viser sig på brugerens maskine som ro.

Den anden detalje er mere elegant: inde i den struktur findes en ændringstæller, der tæller op, så snart konfigurationen ændres. Atlas holder øje med den. I det øjeblik en indstilling ændres fra panelet, opdaterer mellemlageret altså sig selv; at spørge sjældent og aldrig vise forældet information bliver muligt på samme tid.

Det er en anden side af et princip, der står andre steder i denne wiki: det, der kigger, må ikke være det, der koster. Den nemmeste fejl, et overvågningsværktøj kan begå, er at bremse det system, det kigger på, og dermed forvrænge netop det tal, det måler.