Nachtschicht: Sicherungen, JVM-Grenzen und ein Hilfe-Menü

Manche Abende sind Aufräumabende. Dieser hier hatte drei Themen, die nichts miteinander zu tun haben und die alle offen waren.

Erstens: Sicherungen für die Spielserver

Meine Webdienste werden seit Jahren gesichert. Die Minecraft-Server, die im Sommer dazugekommen sind, nicht — sie waren neu, und ich hatte es aufgeschoben.

Das ist ein Zustand, den ich nach 2019 eigentlich nie wieder haben wollte.

Der Aufbau ist unspektakulär und folgt genau dem, was ich vor sieben Jahren gelernt habe:

Dem Server sagen, dass er alles schreiben und danach nichts mehr anfassen soll.
Archiv erzeugen, mit Zeitstempel im Namen.
Schreiben wieder erlauben.
Alte Stände nach einer Frist entfernen.
Prüfen: Ist das Archiv entstanden, und ist es plausibel groß?

Der letzte Punkt ist der, der aus einer Sicherung eine Sicherung macht. Bei mir vergleicht die Prüfung die Größe mit dem Vortag und meldet, wenn sie deutlich abweicht — in beide Richtungen. Deutlich kleiner heißt oft: leeres Archiv. Deutlich größer heißt manchmal: Jemand hat etwas ins falsche Verzeichnis gelegt.

Dazu ein Punkt, der bei Containern neu ist: Das Panel bringt eine eigene Sicherungsfunktion mit. Ich benutze beides — die des Panels für den bequemen Rückweg, mein eigenes Archiv für den Fall, dass das Panel selbst das Problem ist.

Zweitens: Speichergrenzen für Java in Containern

Ein Minecraft-Server ist ein Java-Prozess, und Java-Prozesse haben eine Eigenheit: Sie nehmen sich so viel Speicher, wie man ihnen erlaubt, und geben ihn ungern zurück.

In Containern kommt eine zweite Grenze dazu — die des Containers. Und wenn die Java-Grenze über der Container-Grenze liegt, passiert etwas Unangenehmes: Der Prozess versucht, sich Speicher zu nehmen, den er laut Java haben darf, und wird vom System abgeschossen. Ohne Java-Fehler, ohne aussagekräftige Meldung im Serverprotokoll. Der Server ist einfach weg.

Die Regel, die ich mir aufgeschrieben habe:

Die Java-Obergrenze liegt unter der Containergrenze, mit spürbarem Abstand — Java braucht neben dem verwalteten Speicher noch einiges für sich selbst.

Bei mir sind das grob fünfzehn bis zwanzig Prozent Abstand. Wer eine Grenze von acht Gigabyte setzt, gibt Java sechseinhalb.

Warnung

Ein voller Container sieht in den Protokollen des Spielservers aus wie ein Absturz ohne Ursache. Der Beleg steht nicht dort, sondern in den Systemmeldungen des Wirtssystems: eine Zeile, dass ein Prozess wegen Speichermangels beendet wurde. Wer die nicht kennt, sucht ewig im Spielserver. Ich habe mir deshalb angewöhnt, bei jedem unerklärlichen Verschwinden zuerst dort nachzusehen.

Drittens: ein Hilfe-Menü

Mein eigenes Plugin hatte inzwischen genug Befehle, dass niemand mehr alle kannte. Also ein Menü, das sie zeigt.

Zwei Entscheidungen dabei, die für Crossplay wichtig sind:

Es ist eine Truhenoberfläche, kein Chat-Text. Der Grund ist die Bedrock-Seite: Anklickbare Chat-Verweise und Hover-Texte werden nicht zuverlässig übersetzt. Gegenstände in einem Fenster mit Beschreibung dagegen schon. Wer für gemischte Server baut, muss solche Unterschiede kennen, sonst baut man Funktionen, die für die Hälfte der Leute unsichtbar sind.

Die Einträge kommen aus der Konfiguration. Jedes Ziel, das dort eingetragen ist, erscheint automatisch im Menü und ist automatisch als Befehl verfügbar. Ein neuer Server bedeutet damit einen Konfigurationseintrag, keine Codeänderung.

Die Sicherungsstrategie im Detail

Weil Sicherungen bei Spielservern eigene Anforderungen haben, hier der Aufbau, bei dem ich gelandet bin.

Zwei Ebenen. Die Sicherungsfunktion des Panels für den bequemen Rückweg — sie kennt den Dienst und stellt ihn vollständig wieder her. Und ein eigenes Archiv außerhalb, für den Fall, dass das Panel selbst das Problem ist.

Unterschiedliche Häufigkeit nach Wert. Die Welt, in der gespielt wird: täglich. Der Testserver: wöchentlich. Konfigurationen: bei jeder Änderung, über die Versionsverwaltung.

Aufbewahrung gestaffelt. Die letzten sieben Tage vollständig, danach eine pro Woche für einen Monat, danach eine pro Monat. Damit bleibt der Platzbedarf begrenzt und man kann trotzdem weit zurück.

Die Prüfung gehört dazu. Größe im Vergleich zum Vortag, Alter der neuesten Sicherung, und einmal im Quartal ein tatsächlicher Rückspielversuch in eine Testumgebung.

Der letzte Punkt ist der, den ich am längsten aufgeschoben habe — und der beim ersten Durchführen einen Fehler gezeigt hat: Ein Archiv enthielt die Welt, aber nicht die Plugin-Konfigurationen, weil ein Ausschlussmuster zu weit gefasst war.

Warum Spielserver eigene Regeln brauchen

Ein Spielserver unterscheidet sich in einem Punkt von jedem Webdienst: Der Datenverlust ist emotional, nicht nur wirtschaftlich.

Wenn eine Bestellung verlorengeht, ist das ärgerlich und ersetzbar. Wenn jemand vier Wochenenden an einem Bauwerk gearbeitet hat und es verschwindet, ist es weg — es gibt keinen Weg, das zu ersetzen.

Deshalb sind bei Spielservern zwei Dinge wichtiger als anderswo:

Kurze Abstände. Ein Tag Verlust bedeutet einen verlorenen Spielabend für alle, die drauf waren.

Ein schneller Rückweg für Teilbereiche. Meistens braucht man nicht die ganze Welt zurück, sondern einen Bereich, in dem etwas kaputtgegangen ist. Dafür ist ein Archiv, aus dem man einzelne Regionsdateien entnehmen kann, deutlich nützlicher als ein Verfahren, das nur alles auf einmal kann.

Was ich beim Prüfen der Sicherungen gefunden habe

Beim ersten tatsächlichen Rückspielversuch — Wochen nach dem Einrichten — kam ein Fehler heraus, den ich sonst erst im Ernstfall gefunden hätte.

Das Archiv enthielt die Welt, aber nicht die Plugin-Konfigurationen. Die Ursache war ein Ausschlussmuster, das ich für Zwischenspeicher gedacht hatte und das ohne führende Pfadangabe überall im Baum griff — auch in Verzeichnissen, in denen es nichts zu suchen hatte.

Zwei Lehren daraus:

Ausschlussmuster gehören verankert. Ein Muster ohne Pfadangabe passt an jeder Stelle des Verzeichnisbaums.

Der Inhalt einer Sicherung gehört geprüft, nicht nur ihre Existenz. Größe und Alter sagen nichts darüber, ob das Richtige darin ist. Bei mir prüft die Kontrolle inzwischen zusätzlich, ob bestimmte Pfade im Archiv vorhanden sind.

Diese zweite Prüfung ist zehn Zeilen lang und beantwortet die Frage, die eine Sicherung eigentlich beantworten soll: Ist das drin, was ich brauche?

Was diese Nacht gezeigt hat

Alle drei Themen waren aufgeschoben, keines war dringend, und alle drei hätten mich später mehr gekostet.

Die Sicherungen sind der klarste Fall: Der Zeitpunkt, an dem man sie braucht, ist nie angekündigt. Die Speichergrenzen wären beim nächsten Ausfall eine stundenlange Fehlersuche geworden. Und das Hilfe-Menü — das ist der Punkt, an dem ich mich selbst überrascht habe: Es hat sofort dazu geführt, dass Befehle benutzt wurden, die es seit Wochen gab.

Das ist derselbe Effekt, den ich vor Jahren beim Dashboard hatte. Sichtbarkeit schlägt Funktionalität, und zwar zuverlässig.