Inhalt dieses Guides
ASA CrossARK-Cluster verstehen: gleiche clusterid, gemeinsamer ClusterDirOverride, mehrere Maps, eindeutige Ports, Backups und sichere Transfers.
Server-Arbeitsmodus
Arbeite den Guide kontrolliert ab und ändere immer nur eine Variable. Dein Fortschritt bleibt nur in diesem Browser gespeichert.
Wo hängt dein Server gerade?
Netzwerkdiagnose bringt nichts, solange der Server lokal nicht sauber startet oder lauscht.
Wenn localhost/LAN funktioniert, liegt der nächste Prüfbereich bei Host-Firewall, Router, öffentlicher Adresse und NAT.
Bei Lag, Abstürzen oder Update-Problemen sind Logs, Ressourcen, Mods und ein sauberer Rollbackpfad wichtiger als weitere Portregeln.
Ein ARK-Cluster verbindet mehrere Server beziehungsweise Maps, damit Spieler Transfers innerhalb derselben Servergruppe durchführen können. Technisch reicht es nicht, zwei Server nur gleich zu benennen. Sie müssen dieselbe Cluster-ID und einen konsistent erreichbaren Cluster-Datenbereich verwenden.
Gleiche clusterid verwenden
Die Serverkonfiguration unterstützt -clusterid=<NAME>. Verwende einen eindeutigen Namen, der nicht zufällig mit fremden Installationen kollidiert. Die offizielle Wiki warnt davor, zu generische IDs zu verwenden.
ClusterDirOverride gemeinsam bereitstellen
Mit -ClusterDirOverride=<PATH> wird das Cross-Server-Speicherverzeichnis festgelegt. Mehrere Instanzen müssen auf dieselben Clusterdateien zugreifen können. Auf verteilten Hosts erfordert das eine verlässliche, konsistente Storage-Lösung.
Ports pro Instanz eindeutig machen
Jede Map auf demselben Host benötigt ein eigenes Game-/Peer-Port-Paar, einen eigenen Query-Port und bei RCON einen eigenen TCP-Port. Dokumentiere die Zuordnung pro Map, damit Firewall und Monitoring nachvollziehbar bleiben.
Transfers bewusst erlauben
Upload- und Downloadregeln steuern, welche Survivors, Items und Dinos übertragen werden dürfen. Definiere diese Regeln clusterweit konsistent. Unterschiedliche Einstellungen können zu überraschendem Verhalten führen.
Backups koordiniert erstellen
Ein Cluster ist ein verteiltes System. Sichere nicht nur einzelne Map-Saves, sondern auch Cluster-Daten. Für einen konsistenten Snapshot sollten beteiligte Instanzen kontrolliert gespeichert und möglichst koordiniert gestoppt werden.
Updates nicht gleichzeitig blind starten
Wenn mehrere Instanzen denselben Host teilen, erzeugen parallele SteamCMD-, Save- und Startvorgänge Lastspitzen. Sequenziere Wartung und prüfe nach jeder Instanz Version, Ports und Login.
Migration vorher testen
Beim Wechsel zu einem neuen Host müssen neben Map-Saves auch Clusterpfade und Berechtigungen stimmen. Teste Transfers mit einer Kopie, bevor der alte Cluster abgeschaltet wird.
Monitoring pro Map
Ein Cluster kann teilweise ausfallen. Überwache deshalb jede Instanz separat und ergänze einen funktionalen Test: Prozessstatus allein sagt nicht, ob Transfers und Joins funktionieren.
Cluster-ID und Storage nicht spontan ändern
Eine Änderung an Cluster-ID oder Speicherpfad betrifft Transferdaten mehrerer Instanzen gleichzeitig. Plane solche Migrationen wie eine Datenbankumstellung: vollständiges Backup, klarer Cutover-Zeitpunkt, Testtransfer und dokumentierter Rückweg. Erst wenn ein Survivor erfolgreich zwischen zwei Testmaps wechseln konnte, sollte der alte Pfad entfernt werden.