Konfigurasjonen ble skrivebeskyttet: hvorfor stedet den bor er annerledes

Du prøver å redigere en fil og tillatelsen nektes. Du er root. Det er plass på disken. Likevel kan du ikke skrive.

Ingenting er ødelagt her. Stedet du ser på er ikke en vanlig mappe, og det nekter skriving med vilje.

Stedet der konfigurasjonen bor er ikke en mappe

Proxmox oppbevarer maskinkonfigurasjoner, lagringsdefinisjoner, brannmurregler og sikkerhetskopijobber på ett sted. Det ser ut som et filsystem, det har mapper og filer, men bak sitter en liten database, og den databasen kopieres til hver node i klyngen.

Grunnen er enkel: alle tjenere i en klynge må se den samme maskindefinisjonen. Skal du flytte en maskin fra én tjener til en annen, må motparten allerede vite hvordan den maskinen er definert. Var konfigurasjonen en vanlig fil på én tjeners disk, ville de andre ikke vite om den.

Denne utformingen har tre følger, og alle tre dukker opp i hverdagen.

Følge én: uten flertall nektes skriving

Ser en tjener ikke flertallet av klyngen, stenges skrivingen. Lesing fortsetter å virke, skriving stopper.

Dette er ikke en feil, det er en beslutning. Om nettet delte seg i to og begge halvdeler kunne skrive, ville den samme maskinen få to ulike definisjoner. Når nettet kom tilbake kunne ingen si hvilken som var riktig, og det ville ikke finnes noen måte å slå dem sammen på. I stedet velger systemet dette: siden som blir i mindretall slutter å skrive.

Hvordan et flertall telles i en klynge, og hvorfor oppsett med to tjenere er brysomme, står i en egen artikkel. Det eneste å legge til her er at det er nettopp slik den flertallsregelen føles i praksis: plutselig ikke å kunne skrive.

Følge to: den samme strukturen kjører også på en enkelt tjener

Selv uten klynge er denne strukturen i drift. En enkelt tjener er i seg selv et flertall, så normalt går ingenting galt.

Men er tjenesten som leverer den strukturen ikke frisk, ser du det samme symptomet også på en enkelt tjener. Så "jeg har ingen klynge, dette kan ikke skje meg" stemmer ikke.

Det finnes også en mindre kjent vei: databasen bak denne strukturen ligger på den lokale disken. Når den lokale disken fylles opp, mislykkes skrivinger, og for deg ser det ut som at du ikke får endre innstillinger. Symptomet er på konfigurasjonssiden, årsaken på lagringssiden.

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

Valget "jeg endrer det bare på denne maskinen" finnes ikke. Det som skrives der når hver node i klyngen.

Den klassiske feilen, gjort uten å vite dette, er å gjøre en prøveendring på én node og anta at den ikke berører de andre.

Ett punkt til: det stedet ble laget for konfigurasjon, ikke for data. Små tekstfiler hører hjemme der; skript, arkiver og sikkerhetskopier gjør det ikke. Ikke få for vane å legge igjen filer der.

Får du ikke skrevet, sjekk i rekkefølge

Sjekk først flertallet: ser tjeneren resten av klyngen? Gjør den ikke det, ligger det virkelige problemet i nettet og konfigurasjonsfilen er uskyldig.

Sjekk så tjenesten: kjører tjenesten som leverer denne strukturen?

Sjekk så den lokale disken: er den full, er veien over i spill.

Og den siste, den som oftest hoppes over: en node kan ha forlatt klyngen. Et nettbrudd, en avslått nabo, en feilkonfigurert brannmurregel. Symptomet ser alltid likt ut, årsaken er et annet sted hver gang.

Hva Atlas gjør

Atlas leser denne strukturen direkte som filer, i stedet for å kjøre systemets spørreverktøy hver gang.

Vi målte hvorfor. Hvert kall til det verktøyet koster mellom hundre og to hundre millisekunder prosessortid og rundt hundre megabyte midlertidig minne. Med panelet åpent skjer en oppdatering hvert tiende sekund, og hver oppdatering krever åtte til ti kall. Med andre ord: overvåkingen skapte en stadig svingning på nettopp den tjeneren den overvåket.

Å lese den samme informasjonen fra en fil tar mikrosekunder. Forskjellen er tusenfoldig, og den forskjellen viser seg på brukerens maskin som ro.

Den andre detaljen er mer elegant: inne i den strukturen finnes en endringsteller som øker så snart konfigurasjonen endres. Atlas følger med på den. I det øyeblikket en innstilling endres fra panelet, oppdaterer altså mellomlageret seg selv; å spørre sjelden og aldri vise gammel informasjon blir mulig samtidig.

Dette er en annen side av et prinsipp som står andre steder i denne wikien: det som ser skal ikke være det som koster. Den enkleste feilen et overvåkingsverktøy kan gjøre, er å bremse systemet det ser på, og dermed forvrenge nettopp tallet det måler.