So funktioniert Failover in Opfield, ohne Kubernetes

Wer einen Dienst auf mehr als einem Server betreiben will, landet meist bei einem Cluster: Kubernetes oder Docker Swarm, ein Overlay-Netz und jemand, der sich darum kümmert. Opfield geht einen anderen Weg. Jeder Server bleibt ein gewöhnlicher Docker-Host. Availability legt Kopien eines Workloads auf anderen Servern an und verlagert den Traffic, wenn einer davon ausfällt. Dieser Beitrag erklärt, wie das funktioniert und wo die Grenzen liegen.

Eine Einstellung an einem bestehenden Workload

Availability wird an einem Container, einem Deployment oder einem ganzen Compose-Projekt eingeschaltet, das es schon gibt. Nichts wird neu gebaut oder migriert. Es gibt zwei Modi:

• Replicated hält 2 bis 32 Kopien gleichzeitig in Betrieb, höchstens eine pro Server. Geeignet, wenn die Anwendung mehrere Instanzen nebeneinander verträgt.
• Failover hält eine Kopie in Betrieb und ersetzt sie auf einem anderen Server, wenn ihr Server verloren geht. Geeignet, wenn genau eine Instanz laufen soll.

Nötig sind mindestens zwei erreichbare Docker-Server. Der Workload darf keine Mounts haben: Availability kopiert keine lokalen Daten zwischen Servern, dauerhafte Daten liegen daher in eigenen Diensten wie verwalteten Datenbanken. In Produktion sollten außerdem mindestens zwei Relays auf anderen Hosts als dem Opfield-Host laufen, in verschiedenen Fehlerdomänen.

Vorbereitet, bevor es gebraucht wird

Eine Übernahme geht schnell, weil die Arbeit vorher erledigt ist. Opfield spiegelt das Image des Workloads in seine interne Registry, festgelegt auf einen exakten Digest, und lädt es vorab auf die Standby-Server. Ein Standby-Container ist angelegt, aber nicht gestartet, sodass eine Übernahme ihn nur noch starten muss. Jede Kopie läuft mit demselben Image.

Der Traffic erreicht die Kopien über Routen. Nginx-Knoten schicken neue Verbindungen an die gesunde Kopie mit den wenigsten Verbindungen; bestehende Verbindungen bleiben, wo sie sind. Jede Kopie bekommt ihre eigene Verbindung zu den verwalteten Datenbanken, an die der Workload gebunden ist.

Die Server entscheiden, nicht das Panel

Fällt ein Server aus oder wird er abgeschnitten, zieht der Workload innerhalb von etwa 45 Sekunden auf einen anderen Server um, auch während Opfield gestoppt ist, aktualisiert wird oder nicht erreichbar ist.

Seit 2.11 entscheiden die Server und Relays eines Workloads untereinander, wer ihn bedient. Dafür gibt es keinen Schalter: Es beginnt, sobald alle Docker-Knoten, Nginx-Knoten und Relays des Workloads 2.11 ausführen. Jede laufende Kopie hält eine Lease, die sie alle paar Sekunden bei einer Mehrheit der Stimmberechtigten des Workloads erneuert. Ein Server, der diese Mehrheit nicht mehr erreicht, stoppt seine eigene Kopie, und der nächste Server übernimmt den Slot und startet seine Kopie. Standardmäßig laufen zwei Kopien eines Slots nie gleichzeitig, auch nicht bei einer Netztrennung. Ein kleiner Watchdog-Dienst auf jedem Docker-Knoten stoppt eine Kopie, deren Lease abgelaufen ist, selbst wenn Docker hängt.

Ist Opfield zurück, schreibt es jede Übernahme aus der Zeit seiner Abwesenheit ins Audit-Log. Workloads mit Komponenten älter als 2.11 werden ebenfalls umgeschaltet, aber Opfield steuert das selbst: Nach dem Verlust eines Servers wartet es standardmäßig 15 Sekunden und startet dann einen vorbereiteten Standby oder legt anderswo einen Ersatz an. Dieser Weg braucht ein laufendes Opfield.

Kein Cluster zu betreiben

Opfield legt keinen Swarm-Zustand an, kein Overlay-Netz, kein Vertrauen zwischen Servern und keine eingehenden Cluster-Ports. Jeder Server verbindet sich selbst nach außen mit Opfield, und verwaltete Server brauchen keine eingehenden Management-Ports. Die Server eines Workloads sprechen nur über Relays miteinander.

Eines sollten Sie einplanen: Auf dem Host veröffentlichte Ports werden nur auf dem ursprünglichen Server bedient. Kopien auf anderen Servern veröffentlichen keine und werden über Routen erreicht.

Wenn Opfield selbst offline ist

Opfield liegt nicht im Traffic-Pfad. Ist die Opfield-Anwendung offline, liefert nginx weiter aus, Container laufen weiter, und verwaltete Datenbanken laufen mit dem zuletzt angewendeten Zustand. Mit einem funktionierenden Relay bleiben private Datenbankverbindungen über einen Neustart der Opfield-Anwendung hinweg bestehen. Relays nehmen neue Verbindungen nach der letzten Richtlinie an, die Opfield für sie signiert hat, standardmäßig 72 Stunden lang. Bis Opfield zurück ist, fehlt nur die zentrale Steuerung: die Oberfläche, die API und neue Änderungen.

Das lokale Relay von Opfield stoppt zusammen mit dem Opfield-Host. Damit Failover auch den Verlust dieses Hosts übersteht, betreiben Sie mindestens ein Relay auf einem anderen Host.

Was es nicht leistet

• Es macht weder Opfield selbst noch den Registry-Speicher oder gemeinsame Volumes hochverfügbar.
• Die Zahl der Kopien legen Sie fest; eine Skalierung nach Metriken gibt es nicht.
• Es kopiert keine Daten von der Festplatte eines Servers auf andere Server.

Pläne und nächste Schritte

Availability ist Teil der Pläne Business und Enterprise. Die Einrichtung, die Anforderungen an Relays und das Verhalten bei Netztrennungen beschreiben die Seiten Workload Availability und Failover der Datenebene in der Dokumentation.