Was macht der Controller?
Der Controller koordiniert deine SimpleCloud-Infrastruktur. Er verfolgt, welche Server laufen sollten, entscheidet basierend auf Scaling-Regeln wann Server gestartet oder gestoppt werden, und sendet Anweisungen an Serverhosts via NATS-Messaging.Wann ist das wichtig?
Das Verständnis des Controllers hilft bei:- Debugging von Server-Startproblemen - Warum startet mein Server nicht? Ist er in der Warteschlange? Läuft der Reconciler?
- Einrichtung von Hochverfügbarkeit - Mehrere Controller erfordern Verständnis der Leader Election
- Verstehen des Scaling-Verhaltens - Warum wurde ein Server gestartet oder gestoppt? Wie entscheidet die Reconciliation Loop?
Zustandsverwaltung
Der Controller verwaltet den autoritativen Zustand deines Netzwerks:| Entität | Beschreibung |
|---|---|
| Networks | Registrierte Minecraft-Netzwerke mit Credentials |
| Blueprints | Server-Konfigurationsvorlagen |
| Groups | Skalierbare Server-Sammlungen mit Auto-Scaling-Regeln |
| Servers | Laufende Server-Instanzen und deren Status |
| Persistent Servers | Langlebige dedizierte Server |
| Serverhosts | Verbundene Ausführungsagenten |
| Plugins | Plugin-Definitionen und Zuweisungen |
Reconciliation Loop
Alle 5 Sekunden führt der Controller folgende Schritte aus:- Vergleicht gewünschten Zustand (deine Konfiguration) mit aktuellem Zustand (laufende Server)
- Bestimmt, welche Server gestartet oder gestoppt werden müssen
- Wählt Serverhosts basierend auf Kapazität und Präferenzen
- Sendet Start/Stop-Befehle via NATS
Auto-Scaling
Slot-basierte Skalierung
Skalierung basierend auf verfügbaren Spieler-Slots:Server-basierte Skalierung
Feste Anzahl von Servern beibehalten:Hochverfügbarkeit
Für Produktionsumgebungen kannst du mehrere Controller-Instanzen betreiben:- Leader Election nutzt datenbankgestützte Konsensbildung mit 30-Sekunden-Lease
- Nur der Leader führt Netzwerkzuweisungen und Reconciliation durch
- Alle Instanzen können API-Anfragen bedienen
- Automatisches Failover bei Ausfall des Leaders
Infrastruktur-Anforderungen
| Komponente | Zweck | Erforderlich |
|---|---|---|
| PostgreSQL | Zustandspersistenz | Ja |
| NATS | Serverhost-Messaging | Ja |
| Valkey/Redis | Metriken-Caching | Optional |
| ClickHouse | Log-Speicherung | Optional |
Fehlerbehebung
Controller startet nicht
Controller startet nicht
Symptom: Controller-Prozess beendet sich sofort oder kann Port nicht binden.Lösung:
- PostgreSQL prüfen:
systemctl status postgresql - NATS erreichbar:
nc -zv localhost 4222 - Logs prüfen:
sc logs controller - Port 1337 frei:
lsof -i :1337
Server bleiben in QUEUED
Server bleiben in QUEUED
Symptom: Server bleiben im QUEUED-Status und starten nie.Ursache: Kein Serverhost verfügbar oder hat Kapazität.Lösung:
- Serverhost-Status prüfen:
sc status serverhost - Verfügbaren Speicher der Hosts prüfen
- Deployment-Einstellungen prüfen
- Logs prüfen:
sc logs controller
Scaling funktioniert nicht
Scaling funktioniert nicht
Symptom: Server skalieren nicht hoch wenn Spieler beitreten oder runter wenn leer.Ursache: Reconciliation triggert nicht oder Metriken fehlen.Lösung:
- Controller ist Leader: “became leader” in Logs suchen
- Gruppen-Scaling-Config prüfen (min/max Server, Schwellenwert)
- Server melden Spielerzahlen
- Reconciliation-Logs auf Fehler prüfen
API gibt 401/403 zurück
API gibt 401/403 zurück
Symptom: API-Aufrufe schlagen mit Authentifizierungsfehlern fehl.Lösung:
X-Network-IDHeader prüfenX-Network-SecretHeader prüfen- Credentials im
secrets/Verzeichnis prüfen
API gibt 500 zurück
API gibt 500 zurück
Symptom: API-Aufrufe schlagen mit internem Serverfehler fehl.Lösung:
- Controller-Logs auf Stack-Traces prüfen
- PostgreSQL-Verbindung prüfen
- Festplattenspeicher und RAM prüfen
CLI-Zugriff
Der Controller muss laufen, damit neue Server starten können. Bestehende Server
laufen weiter, wenn der Controller temporär offline ist.
Verwandte Themen
- Developer API - Vollständige API-Dokumentation
- Server - Server-Lebenszyklus und Zustände
- Architektur-Übersicht - System-Architekturdiagramm