Konfiguration ist schreibgeschützt: warum ihr Aufbewahrungsort anders ist

Sie versuchen, eine Datei zu bearbeiten, und die Berechtigung wird verweigert. Sie sind root. Auf der Platte ist Platz. Trotzdem können Sie nicht schreiben.

Hier ist nichts kaputt. Der Ort, den Sie ansehen, ist kein normales Verzeichnis, und er verweigert das Schreiben mit Absicht.

Der Ort, an dem die Konfiguration lebt, ist kein Verzeichnis

Proxmox bewahrt Maschinenkonfigurationen, Speicherdefinitionen, Firewallregeln und Sicherungsaufträge an einem Ort auf. Er sieht aus wie ein Dateisystem, hat Ordner und Dateien, aber dahinter sitzt eine kleine Datenbank, und diese Datenbank wird auf jeden Knoten im Cluster repliziert.

Der Grund ist einfach: jeder Server in einem Cluster muss dieselbe Maschinendefinition sehen. Wenn Sie eine Maschine von einem Server auf einen anderen verschieben wollen, muss die Gegenseite bereits wissen, wie diese Maschine definiert ist. Wäre die Konfiguration eine gewöhnliche Datei auf der Platte eines Servers, wüssten die anderen nichts davon.

Dieses Design hat drei Folgen, und alle drei begegnen Ihnen im Alltag.

Folge eins: ohne Mehrheit wird das Schreiben verweigert

Sieht ein Server die Mehrheit des Clusters nicht, wird das Schreiben abgeschaltet. Lesen funktioniert weiter, Schreiben hört auf.

Das ist kein Fehler, das ist eine Entscheidung. Würde sich das Netz in zwei Teile spalten und könnten beide Hälften schreiben, entstünden von derselben Maschine zwei verschiedene Definitionen. Käme das Netz zurück, könnte niemand sagen, welche richtig ist, und es gäbe keinen Weg zusammenzuführen. Stattdessen entscheidet das System so: die Seite in der Minderheit hört auf zu schreiben.

Wie eine Mehrheit im Cluster gezählt wird und warum Aufbauten mit zwei Servern heikel sind, steht in einem eigenen Artikel. Hier ist nur hinzuzufügen: genau so fühlt sich diese Mehrheitsregel in der Praxis an, nämlich plötzlich nicht mehr schreiben zu können.

Folge zwei: dieselbe Struktur läuft auch auf einem einzelnen Server

Auch ohne Cluster läuft diese Struktur. Ein einzelner Server ist für sich schon eine Mehrheit, also geht normalerweise nichts schief.

Ist aber der Dienst, der diese Struktur bereitstellt, nicht gesund, sehen Sie dasselbe Symptom auch auf einem einzelnen Server. "Ich habe keinen Cluster, das kann mir nicht passieren" stimmt also nicht.

Es gibt noch einen weniger bekannten Weg: die Datenbank hinter dieser Struktur liegt auf der lokalen Platte. Läuft die lokale Platte voll, scheitern Schreibvorgänge, und für Sie sieht es so aus, als könnten Sie keine Einstellungen ändern. Das Symptom liegt auf der Konfigurationsseite, die Ursache auf der Speicherseite.

Folge drei: was Sie dort schreiben, geht an alle

Die Option "ich ändere es nur auf dieser Maschine" gibt es nicht. Was dort geschrieben wird, erreicht jeden Knoten im Cluster.

Der klassische Fehler ohne dieses Wissen ist, auf einem Knoten eine Änderung zum Ausprobieren vorzunehmen und anzunehmen, sie betreffe die anderen nicht.

Noch ein Punkt: dieser Ort wurde für Konfiguration entworfen, nicht für Daten. Kleine Textdateien gehören dorthin; Skripte, Archive und Sicherungen nicht. Gewöhnen Sie sich nicht an, dort Dateien liegen zu lassen.

Wenn Sie nicht schreiben können, prüfen Sie der Reihe nach

Prüfen Sie zuerst die Mehrheit: sieht der Server den Rest des Clusters? Wenn nicht, liegt das eigentliche Problem im Netz und die Konfigurationsdatei ist unschuldig.

Dann prüfen Sie den Dienst: läuft der Dienst, der diese Struktur bereitstellt?

Dann prüfen Sie die lokale Platte: ist sie voll, greift der oben beschriebene Weg.

Und zuletzt das, was am häufigsten übersprungen wird: ein Knoten kann den Cluster verlassen haben. Ein Netzausfall, ein abgeschalteter Nachbar, eine falsch konfigurierte Firewallregel. Das Symptom sieht immer gleich aus, die Ursache liegt jedes Mal woanders.

Was Atlas macht

Atlas liest diese Struktur direkt als Dateien, statt jedes Mal das Abfragewerkzeug des Systems zu starten.

Wir haben gemessen, warum. Jeder Aufruf dieses Werkzeugs kostet zwischen hundert und zweihundert Millisekunden Prozessorzeit und rund hundert Megabyte flüchtigen Speicher. Bei geöffnetem Panel gibt es alle zehn Sekunden eine Aktualisierung, und jede Aktualisierung braucht acht bis zehn Aufrufe. Mit anderen Worten: die Überwachung erzeugte ein dauerndes Schwanken auf genau dem Server, den sie überwachte.

Dieselbe Information aus einer Datei zu lesen dauert Mikrosekunden. Der Abstand beträgt das Tausendfache, und dieser Abstand zeigt sich auf der Maschine des Benutzers als Ruhe.

Das zweite Detail ist eleganter: in dieser Struktur gibt es einen Änderungszähler, der hochzählt, sobald sich die Konfiguration ändert. Atlas beobachtet ihn. Sobald also im Panel eine Einstellung geändert wird, frischt sich der Zwischenspeicher von selbst auf; selten fragen und nie veraltete Information zeigen wird gleichzeitig möglich.

Das ist eine weitere Seite eines Prinzips, das anderswo in diesem Wiki steht: das Beobachtende soll nicht das Kostende sein. Der leichteste Fehler eines Überwachungswerkzeugs ist, das beobachtete System zu bremsen und damit genau die Zahl zu verfälschen, die es misst.