Konfigurationen blev skrivskyddad: varför platsen den bor på är annorlunda

Du försöker redigera en fil och behörigheten nekas. Du är root. Det finns plats på disken. Ändå kan du inte skriva.

Ingenting är trasigt här. Platsen du tittar på är ingen vanlig katalog, och den vägrar skrivning med avsikt.

Platsen där konfigurationen bor är ingen katalog

Proxmox förvarar maskinkonfigurationer, lagringsdefinitioner, brandväggsregler och säkerhetskopieringsjobb på ett ställe. Det ser ut som ett filsystem, det har mappar och filer, men bakom sitter en liten databas, och den databasen replikeras till varje nod i klustret.

Skälet är enkelt: alla servrar i ett kluster måste se samma maskindefinition. Ska du flytta en maskin från en server till en annan måste motparten redan veta hur den maskinen är definierad. Vore konfigurationen en vanlig fil på en servers disk skulle de andra inte känna till den.

Den här konstruktionen har tre följder, och alla tre dyker upp i vardagen.

Följd ett: utan majoritet nekas skrivning

Ser en server inte majoriteten av klustret stängs skrivningen av. Läsning fortsätter fungera, skrivning upphör.

Det är inget fel, det är ett beslut. Om nätet delades i två och båda halvorna kunde skriva skulle samma maskin få två olika definitioner. När nätet kom tillbaka kunde ingen säga vilken som var rätt, och det skulle inte finnas något sätt att slå ihop dem. I stället väljer systemet detta: den sida som hamnat i minoritet slutar skriva.

Hur en majoritet räknas i ett kluster, och varför uppsättningar med två servrar är besvärliga, står i en egen artikel. Det enda att tillägga här är att det är precis så den majoritetsregeln känns i praktiken: att plötsligt inte kunna skriva.

Följd två: samma struktur körs även på en ensam server

Även utan kluster är den här strukturen igång. En ensam server är i sig själv en majoritet, så normalt går inget snett.

Men om tjänsten som tillhandahåller strukturen inte är frisk ser du samma symptom även på en ensam server. Så "jag har inget kluster, det här kan inte hända mig" stämmer inte.

Det finns också en mindre känd väg: databasen bakom den här strukturen ligger på den lokala disken. När den lokala disken fylls misslyckas skrivningar, och för dig ser det ut som att du inte kan ändra inställningar. Symptomet finns på konfigurationssidan, orsaken på lagringssidan.

Följd tre: allt du skriver där går till alla

Alternativet "jag ändrar det bara på den här maskinen" finns inte. Det som skrivs där når varje nod i klustret.

Det klassiska misstaget, gjort utan att veta detta, är att göra en provändring på en nod och anta att den inte påverkar de andra.

En sak till: den platsen konstruerades för konfiguration, inte för data. Små textfiler hör hemma där; skript, arkiv och säkerhetskopior gör det inte. Skaffa dig inte vanan att lämna filer där.

Kan du inte skriva, kontrollera i ordning

Kontrollera först majoriteten: ser servern resten av klustret? Om inte ligger det verkliga problemet i nätet och konfigurationsfilen är oskyldig.

Kontrollera sedan tjänsten: körs tjänsten som tillhandahåller den här strukturen?

Kontrollera sedan den lokala disken: är den full är vägen ovan i spel.

Och den sista, den som oftast hoppas över: en nod kan ha lämnat klustret. Ett nätavbrott, en avstängd granne, en felkonfigurerad brandväggsregel. Symptomet ser alltid likadant ut, orsaken finns någon annanstans varje gång.

Vad Atlas gör

Atlas läser den här strukturen direkt som filer, i stället för att köra systemets frågeverktyg varje gång.

Vi mätte varför. Varje anrop till det verktyget kostar mellan hundra och tvåhundra millisekunder processortid och runt hundra megabyte tillfälligt minne. Med panelen öppen sker en uppdatering var tionde sekund, och varje uppdatering kräver åtta till tio anrop. Med andra ord: övervakningen skapade en ständig svängning på just den server den övervakade.

Att läsa samma information ur en fil tar mikrosekunder. Skillnaden är tusenfaldig, och den skillnaden syns på användarens maskin som lugn.

Den andra detaljen är elegantare: inuti den strukturen finns en ändringsräknare som ökar så snart konfigurationen ändras. Atlas bevakar den. I samma stund som en inställning ändras från panelen uppdateras alltså mellanlagret av sig självt; att fråga sällan och aldrig visa gammal information blir möjligt samtidigt.

Det här är en annan sida av en princip som står på annat håll i den här wikin: det som tittar ska inte vara det som kostar. Det lättaste misstaget ett övervakningsverktyg kan göra är att bromsa systemet det tittar på, och därmed förvanska just den siffra det mäter.