De configuratie werd alleen-lezen: waarom de plek waar zij woont anders is

U probeert een bestand te bewerken en de toestemming wordt geweigerd. U bent root. Er is ruimte op de schijf. Toch kunt u niet schrijven.

Hier is niets stuk. De plek waar u naar kijkt is geen gewone map, en die weigert schrijven met opzet.

De plek waar de configuratie woont is geen map

Proxmox bewaart machineconfiguraties, opslagdefinities, firewallregels en back-uptaken op één plek. Het lijkt op een bestandssysteem, het heeft mappen en bestanden, maar erachter zit een kleine database, en die database wordt naar elke node in het cluster gekopieerd.

De reden is eenvoudig: alle servers in een cluster moeten dezelfde machinedefinitie zien. Wilt u een machine van de ene server naar de andere verplaatsen, dan moet de andere kant al weten hoe die machine gedefinieerd is. Was de configuratie een gewoon bestand op de schijf van één server, dan wisten de anderen er niets van.

Dit ontwerp heeft drie gevolgen, en alle drie komt u in het dagelijks werk tegen.

Gevolg één: zonder meerderheid wordt schrijven geweigerd

Ziet een server de meerderheid van het cluster niet, dan gaat schrijven op slot. Lezen blijft werken, schrijven stopt.

Dat is geen storing, dat is een besluit. Zou het netwerk in tweeën breken en konden beide helften schrijven, dan kreeg dezelfde machine twee verschillende definities. Kwam het netwerk terug, dan kon niemand zeggen welke juist is, en samenvoegen zou onmogelijk zijn. In plaats daarvan kiest het systeem dit: de kant die in de minderheid blijft, stopt met schrijven.

Hoe een meerderheid in een cluster geteld wordt, en waarom opstellingen met twee servers lastig zijn, staat in een apart artikel. Hier valt alleen toe te voegen: zo voelt die meerderheidsregel in de praktijk, plotseling niet meer kunnen schrijven.

Gevolg twee: dezelfde structuur draait ook op één server

Ook zonder cluster draait deze structuur. Eén server is in zijn eentje al een meerderheid, dus normaal gaat er niets mis.

Maar is de dienst die die structuur levert niet gezond, dan ziet u hetzelfde verschijnsel ook op één server. "Ik heb geen cluster, dit kan mij niet overkomen" klopt dus niet.

Er is ook een minder bekende weg: de database achter deze structuur staat op de lokale schijf. Loopt de lokale schijf vol, dan mislukken schrijfacties en lijkt het voor u alsof u geen instellingen kunt wijzigen. Het verschijnsel zit aan de configuratiekant, de oorzaak aan de opslagkant.

Gevolg drie: alles wat u daar schrijft gaat naar iedereen

De optie "ik wijzig het alleen op deze machine" bestaat niet. Wat daar geschreven wordt, bereikt elke node in het cluster.

De klassieke fout, gemaakt zonder dit te weten, is op één node een proefwijziging doen en aannemen dat die de andere niet raakt.

Nog een punt: die plek is ontworpen voor configuratie, niet voor gegevens. Kleine tekstbestanden horen er thuis; scripts, archieven en back-ups niet. Maak er geen gewoonte van daar bestanden achter te laten.

Kunt u niet schrijven, controleer dan op volgorde

Controleer eerst de meerderheid: ziet de server de rest van het cluster? Zo niet, dan zit het echte probleem in het netwerk en is het configuratiebestand onschuldig.

Controleer dan de dienst: draait de dienst die deze structuur levert?

Controleer dan de lokale schijf: is die vol, dan speelt de weg hierboven.

En de laatste, die het vaakst wordt overgeslagen: een node kan het cluster hebben verlaten. Een netwerkstoring, een uitgeschakelde buur, een verkeerd ingestelde firewallregel. Het verschijnsel ziet er altijd hetzelfde uit, de oorzaak zit elke keer ergens anders.

Wat Atlas doet

Atlas leest deze structuur rechtstreeks als bestanden, in plaats van elke keer het bevraagwerktuig van het systeem te starten.

We hebben gemeten waarom. Elke aanroep van dat werktuig kost tussen de honderd en tweehonderd milliseconden processortijd en ongeveer honderd megabyte tijdelijk geheugen. Met het paneel open is er elke tien seconden een verversing, en elke verversing vraagt acht tot tien aanroepen. Met andere woorden: de bewaking veroorzaakte een voortdurende schommeling op juist de server die zij bewaakte.

Dezelfde informatie uit een bestand lezen duurt microseconden. Het verschil is duizenden malen, en dat verschil is op de machine van de gebruiker te zien als rust.

Het tweede detail is eleganter: in die structuur zit een wijzigingsteller die oploopt zodra de configuratie verandert. Atlas houdt die in de gaten. Zodra er dus vanuit het paneel een instelling wordt gewijzigd, ververst de cache zichzelf; weinig vragen en nooit verouderde informatie tonen worden tegelijk mogelijk.

Dit is een andere kant van een beginsel dat elders in deze wiki staat: wat kijkt mag niet zijn wat kost. De makkelijkste fout van een bewakingswerktuig is het systeem dat het bekijkt af te remmen, en daarmee juist het getal te bederven dat het meet.