Betrieb

Eine Cloud einzurichten dauert einen Nachmittag. Sie ein Jahr lang zu betreiben ist eine andere Aufgabe, und um die geht es auf dieser Seite.

AutostartLink zum Abschnitt kopieren

Der Installer legt mutecloud.service neben die Programmdatei. Richte sie einmal ein, dann ist die Cloud nach einem Neustart des Servers und nach einem Absturz von selbst wieder da:

sudo cp ~/mutecloud/mutecloud.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now mutecloud

Die Unit startet die Cloud zehn Sekunden nach einem unerwarteten Ende neu und gibt ihr zwei Minuten, um sauber herunterzufahren. Das reicht, damit laufende Spielserver ihre Welten speichern können. Eine Cloud, die du von Hand in einer Shell startest, übersteht weder einen Neustart noch eine geschlossene Sitzung, und das Netzwerk bleibt dann aus, bis es jemand bemerkt.

Was von selbst läuftLink zum Abschnitt kopieren

Alle zwei Sekunden vergleicht die Cloud den Sollzustand aus groups/ mit der Wirklichkeit und gleicht den Unterschied aus. Das gilt in beide Richtungen: Fehlende Server werden gestartet, und Server, die nicht mehr gebraucht werden, lässt sie leerlaufen und entfernt sie. Das passiert einzeln, der mit der höchsten Nummer zuerst, nie unter scale.min und nie bei einem Server, auf dem noch Spieler sind. Einen Server, der jünger als drei Minuten ist, lässt die Cloud in Ruhe, damit eine kurze Spitze nicht zu ständigem Starten und Stoppen führt. Persistente Gruppen werden nie automatisch verkleinert, weil ihre Welt in ihrem Verzeichnis liegt.

Stürzt ein Server ab, bemerkt die Cloud das sofort, schreibt seine letzte Ausgabe nach dumps/, und innerhalb von Sekunden läuft ein Ersatz.

Auch ein hängender Server fällt auf. Die Bridge meldet alle zehn Sekunden, wie lange der letzte Tick des Hauptthreads zurückliegt. Überschreitet dieser Stillstand oder das Schweigen der Bridge selbst die Grenze, löst die Cloud service-hanging aus und ersetzt den Server. Ohne das hält ein eingefrorener Server seinen Port offen, und der Proxy schickt weiter Spieler hinein.

[watchdog]
enabled = true
hang_seconds = 90
restart = true

Mit restart = false wirst du nur benachrichtigt, ohne dass die Cloud eingreift.

Arbeitsspeicher ist ein Budget, kein WunschLink zum Abschnitt kopieren

Eine Node startet Server nur, solange ihr Budget es zulässt:

[resources]
memory = 4096
reserve = 1024

Mit diesen Standardwerten stehen 3072 MB für Server zur Verfügung. Eine Gruppe, die 64 MB pro Server verlangt, bekommt also 48 davon, und der nächste Start wird mit einer Warnung abgelehnt, statt den Server in den Swap zu treiben. Setz memory auf das, was der Server wirklich hat, abzüglich dessen, was das Betriebssystem und deine Datenbanken brauchen, und lass reserve unverändert.

BackupsLink zum Abschnitt kopieren

groups <name> backup            jetzt eins schreiben
groups <name> backup list       was vorhanden ist
groups <name> backup restore <file>   eins zurückspielen, siehe Backups

Backups landen unter backups/. Probier die Wiederherstellung einmal aus, solange nichts brennt, und kopiere das Verzeichnis auf einen anderen Rechner. Ein Backup auf derselben Platte ist eine Bequemlichkeit, kein Sicherheitsnetz.

AktualisierenLink zum Abschnitt kopieren

update            nach einer neueren Version suchen
update install    sie holen und die Cloud neu starten
update rollback   zur vorherigen Programmdatei zurückkehren

Die Server laufen weiter, während die Cloud neu startet. Sie sind eigene Prozesse und verbinden sich danach wieder mit der Bridge. Im Verbund aktualisierst du zuerst den Leiter und gleich danach die Worker, und lässt sie nicht länger auf unterschiedlichen Versionen laufen, als das Update dauert.

Im Blick behaltenLink zum Abschnitt kopieren

GET /api/health antwortet ohne Token und ist das richtige Ziel für einen Uptime-Check. GET /metrics liefert Prometheus-Text mit Servern, Spielern, Arbeitsspeicher und dem Zustand der Nodes. Warnungen gehen über die Kanäle in [alerts] raus. service-crashed, service-hanging, node-lost und backup-failed sind die vier, für die es sich lohnt, aufzuwachen.

Logs rotieren unter logs/, Absturzberichte sammeln sich unter dumps/, und die Aufräumroutine entfernt beides nach der Aufbewahrungszeit aus [logs]. Plane Speicherplatz für Vorlagen, Backups und Welten ein. Die Cloud selbst braucht im Leerlauf etwa 30 MB RAM und keine messbare CPU.

ZahlenLink zum Abschnitt kopieren

Gemessen mit MuteCloud 0.3.7 auf einem Laptop (Apple M4, 24 GB) mit einer Gruppe einfacher, selbst gebauter Server. Die Werte zeigen also, was die Cloud kostet, nicht was ein Minecraft-Server kostet: