GCP Failover

GCP-Failover

← Home · Zurück: Docker-Betrieb

Notfall-Konzept des Repos: eine bei Google Cloud standardmäßig gestoppte Ersatz-Instanz, die im Ernstfall mit einem Befehl startet, sich selbst aus dem neuesten Backup versorgt und den Server im Docker-Pfad mit reduzierter Kapazität hochzieht. Diese Seite erweitert docs/06-failover-gcp.md und gcp/README.md um die 1:1-Details der drei GCP-Skripte.

Konzept

• Maschine: e2-standard-4 — 4 vCPU / 16 GB RAM, Debian 12, 50 GB Boot-Disk (alle drei Werte 1:1 aus gcp/create-instance.sh = Repo-Default; Maschinentyp-Klassifizierung: Community-Quelle GCP-Katalog).
• Zustand normal: gestoppt. Eine gestoppte Compute-Engine-Instanz verursacht keine Compute-Kosten, sondern nur Persistent-Disk-Kosten — laut gcp/README.md „wenige USD/Monat" für die 50-GB-Disk (Angabe der Repo-Doku; Community-Quelle: GCP-Preismodell, Näherung).
• Zustand Notfall: laufend. ~0,13 USD/h laut gcp/README.md für e2-standard-4 (Community-Quelle: GCP-Preisliste — als Näherung gelabelt, regional abhängig, Stand der Repo-Doku).
• Reduziertes Profil: Das Startup-Skript exportiert hartkodiert SLOTS=3 und XMX=8G (1:1 aus gcp/startup-script.sh; Repo-Default — Notfallserver für maximal 3 Spieler, passend zu FAILOVER_SLOTS=3 und FAILOVER_XMX=8G in .env.example).
• Datenfluss: Hauptserver → nächtliches Backup (04:00, systemd-Timer) → sync-backups.sh spiegelt in den GCS-Bucket → Failover zieht beim Start das neueste daily-*.tar.gz aus dem Bucket.

Anmerkung zum reduzierten Profil (Repo-Stand, 1:1 aus docker/docker-compose.yml): Die Compose-Datei konsumiert SLOTS NICHT — sie setzt nur SERVER_NAME, MAX_PLAYERS (Fallback 8) und XMX als Container-env. Im Failover-Container greift damit MAX_PLAYERS (Fallback 8 bzw. der Wert aus der docker/.env), nicht 3 Slots: „maximal 3 Spieler" ist die Repo-Intention (FAILOVER_SLOTS=3 in .env.example), vom Compose-File aber nicht erzwungen.

Die .env-Gruppe dafür (Repo-Default aus .env.example): GCP_PROJECT, GCP_ZONE=europe-west3-a, GCP_INSTANCE=pz-failover, GCP_BUCKET=pz-backups-CHANGE_ME, FAILOVER_SLOTS=3, FAILOVER_XMX=8G — siehe ENV-Variablen.

Einrichtung (einmalig)

Voraussetzungen

• Installiertes gcloud und gsutil (beide werden von den Skripten per need_cmd erfordert, 1:1).
• Authentifiziertes Projekt: gcloud auth login und gcloud config set project <PROJECT_ID> (gcloud-Standardvoraussetzung; Heuristik: für reine storage-rw-Scopes reicht ein User-Account mit Compute/Storage-Rechten).
• Gefüllte GCP-*-Werte in .env (Skripte sterben ohne .env per need_env).
• Wichtig vor dem Anlegen: gcp/startup-script.sh enthält zwei Platzhalter, die laut Kommentar im Skript „vor create-instance.sh ersetzen oder via metadata" gesetzt werden müssen (1:1): BUCKET="__GCP_BUCKET__" und REPO_URL="__REPO_URL__" (z. B. https://<token>@github.com/<user>/ProjectZomboiD.git). Das create-Skript übergibt die Datei ungefiltert per --metadata-from-file=startup-script=... — ohne vorherige Ersetzung läuft der Start ins Leere (Repo-Stand; ehrlich gesagt: die Ersetzung ist ein manueller Schritt, den kein Skript abnimmt).

create-instance.sh Schritt für Schritt (1:1)

# 1. Bucket anlegen, falls nicht vorhanden (Region europe-west3, 1:1):
gsutil ls "gs://${GCP_BUCKET}" >/dev/null 2>&1 || gsutil mb -l europe-west3 "gs://${GCP_BUCKET}"

# 2. Instanz anlegen:
gcloud compute instances create "$GCP_INSTANCE" \
  --project="$GCP_PROJECT" --zone="$GCP_ZONE" \
  --machine-type=e2-standard-4 \
  --image-family=debian-12 --image-project=debian-cloud \
  --boot-disk-size=50GB \
  --scopes=storage-rw \
  --metadata-from-file=startup-script="${REPO_ROOT}/gcp/startup-script.sh" \
  --tags=pz-failover

# 3. Firewall: Spiel-Ports nur fuer diese Instanz (target-tags):
gcloud compute firewall-rules create pz-failover-udp --project="$GCP_PROJECT" \
  --allow=udp:16261,udp:16262 --target-tags=pz-failover 2>/dev/null || true

# 4. Und sofort wieder stoppen (Kosten!):
gcloud compute instances stop "$GCP_INSTANCE" --zone="$GCP_ZONE" --quiet

Anmerkungen: storage-rw erlaubt der Instanz den Bucket-Zugriff ohne weitere Auth-Kopplung. Die Firewall-Regel öffnet udp:16261 und udp:16262 — RCON (27015/tcp) bleibt bewusst zu; Remote-Admin im Notfall würde einen SSH-Tunnel oder eine zusätzliche Regel brauchen (Heuristik). Die Region europe-west3 ist im Bucket-Festland hart codiert (1:1), die Zone der Instanz kommt aus GCP_ZONE (Default europe-west3-a).

Danach die initiale Spiegelung:

bash gcp/sync-backups.sh

Backup-Sync (laufend)

gcp/sync-backups.sh (1:1):

gsutil -m rsync -r "$BACKUP_DIR" "gs://${GCP_BUCKET}"

• -m = parallele Übertragung; -r = rekursiv über alle tar.gz.
• Alternativ als make-Target: make failover-sync.
• Einrichtung laut gcp/README.md: täglich per Cron auf dem Hauptserver, „z. B. 04:30, nach dem naechtlichen Backup" — die Uhrzeit ist als Beispiel zu lesen, der einzige harte Anker ist: NACH dem 04:00-Backup-Timer (Repo-Doku; Cron-Einrichtung selbst ist Handarbeit, siehe Wartung-und-Automatik).

Notfall-Aktivierung

Wenn der Hauptserver ausgefallen ist:

gcloud compute instances start pz-failover --zone=europe-west3-a

Das GCE-Startup-Skript (gcp/startup-script.sh) läuft bei JEDEM Start und macht dann selbst (1:1):

1. apt-get install docker.io docker-compose-v2 git
2. Repo nach /opt/pz/ProjectZomboiD klonen (git clone per REPO_URL, falls nicht vorhanden) und git pull --ff-only.
3. Neuestes Backup ermitteln: gsutil ls gs://${BUCKET}/daily-*.tar.gz | sort | tail -n1 → nach /tmp/restore.tar.gz laden → in /data/Zomboid entpacken.
4. export SLOTS=3 XMX=8G und docker compose -f docker/docker-compose.yml up -d — derselbe Container wie in Docker-Betrieb, nur mit Notfall-Profil.

Vorbereitungs-Hinweis (Repo-Lücke, ehrlich): Der frisch geklonte Ordner enthält kein docker/.env — die Compose-Datei lädt mit env_file: .env aber genau diese Datei. Hat vor der Aktivierung niemand docker/.env.docker.example zu docker/.env kopiert und Werte gesetzt, scheitert docker compose up im Startup-Skript. Wer den Failover vorbereitet, sollte das Kopieren/Anpassen fest einplanen — das Startup-Skript erledigt es nicht.

Externe IP abfragen und den Spielern durchgeben (1:1 aus docs/06):

gcloud compute instances describe pz-failover --zone=europe-west3-a \
  --format='get(networkInterfaces[0].accessConfigs[0].natIP)'

Laut docs/06 ist der Server „~2-3 Minuten spaeter" erreichbar (Schätzung der Repo-Doku — Heuristik; das erste Boot inklusive Paketinstallation und Backup-Download kann je nach Backup-Größe länger dauern). Spieler verbinden sich auf die GCP-IP wie gewohnt (Ports: Ports-und-Netzwerk).

Grenzen des Notfallprofils (Repo-Stand): 3 Slots, 8G Heap — es ist ein Übergangsserver, kein vollwertiger Ersatz (siehe Performance-Guide zur Einordnung von 8 GB Heap). Watchdog/Discord-Automatik des systemd-Pfads läuft hier nicht (Docker-Pfad, siehe Docker-Betrieb).

Rückkehr zum Hauptserver

Ablauf aus docs/06 (1:1):

1. Auf dem Failover: Backup erstellen, in den Bucket laden. Wie genau, ist im Repo nicht vorgefertigt — Heuristik: im laufenden Container ein tar.gz aus /data/Zomboid (Saves + Server) erzeugen (z. B. docker exec) und per gsutil cp unter einem neuen Namen (etwa failover-<ts>.tar.gz) in den Bucket legen, damit der daily-Bestand unangetastet bleibt.
2. Lokal: make restore mit dem Failover-Backup (interaktiver Restore, siehe Backup-und-Restore).
3. Instanz stoppen:

gcloud compute instances stop pz-failover --zone=europe-west3-a

Was dabei unklar bleibt (ehrlich, Heuristik-Labels): das Startup-Skript zieht beim nächsten Start wieder das alphabetisch/zeitlich letzte daily-*.tar.gz — ein im Bucket abgelegtes failover-*.tar.gz würde von diesem Muster NICHT automatisch eingesammelt. Vor einer erneuten Failover-Aktivierung also prüfen, welcher Stand im Bucket der aktuellste nutzbare ist.

Kostenkontrolle

Zustand der Instanz	Kostenbild	Quelle/Label
Gestoppt (Normalzustand)	Nur Persistent-Disk-Kosten, „wenige USD/Monat"	Repo-Doku gcp/README.md; Community-Quelle GCP-Preismodell (Näherung)
Laufend (Notfall)	~0,13 USD/h + Disk	Repo-Doku gcp/README.md; Community-Quelle GCP-Preisliste (Näherung, regional abhängig)
Bucket	Speicherkosten für Backup-Archiv, wächst mit Retention	Community-Quelle GCP-Preismodell (Näherung)

Die wichtigste Regel: Nach dem Notfall die Instanz stoppen. Ein vergessener laufender Failover läuft mit ~0,13 USD/h weiter — das sind rund 94 USD/Monat (Rechnung: 0,13 × 24 × 30 = 93,6, aus dem Stundensatz der Repo-Doku abgeleitet; Näherung). Die Rückkehr-Schritte oben enden deshalb explizit mit instances stop.

Empfehlung (Heuristik, aus docs/06 übernommen): einen GCP-Budget-Alarm einrichten — docs/06 nennt als Beispiel 10 EUR/Monat. Damit nagelt eine Mail an, falls die Instanz versehentlich laufen bleibt.

Verwandte Seiten

• Backup-und-Restore — Ursprung der daily-Backups und manueller Restore
• Docker-Betrieb — das Compose-File, das der Failover fährt
• Wartung-und-Automatik — Timer/Cron-Geflecht auf dem Hauptserver
• Troubleshooting — wenn der Failover selbst nicht startet

Vertieft in Repo: docs/06-failover-gcp.md, gcp/README.md, gcp/create-instance.sh, gcp/startup-script.sh, gcp/sync-backups.sh.

---

Weiter: Backup-und-Restore · Troubleshooting