Workload Availability (HA)

Availability fügt einem bestehenden Container, Deployment oder Compose-Projekt Platzierungen auf unabhängigen Docker Nodes hinzu. Opfield bewahrt Ressourcenidentität, Konfiguration und Beziehungen, während es Laufzeitinstanzen gemäß seiner Availability-Richtlinie erstellt und ersetzt.

Die Funktion ist in Business und Enterprise verfügbar. Verwalten Sie Instanzen über die zuständige Ressource statt als einzelne Container: Die Richtlinie ist für die Anzahl der Platzierungen, Generationen, Routing-Mitgliedschaft und Bereinigung zuständig.

Failover läuft auf eine von zwei Arten ab. Wenn jeder Docker Node, jeder Ingress Node und jedes Relay des Workloads ein Release ausführt, das es unterstützt, führen die Nodes das Failover selbst durch, ohne Opfield; siehe Failover der Datenebene. Andernfalls ersetzt Opfield verlorene Platzierungen selbst (Backend-Failover), wie auf dieser Seite beschrieben.

Einen Modus wählen

Modus	Verhalten	Wann er geeignet ist
Replicated	Hält 2–32 bedienende Platzierungen, höchstens eine pro Node	Die Anwendung unterstützt gleichzeitige Instanzen
Failover	Hält eine bedienende Platzierung und erstellt nach einem Node-Ausfall einen Ersatz	Eine bedienende Instanz mit Wiederherstellung auf einem anderen Node ist erforderlich

Ohne Availability behält die Ressource ihren gewöhnlichen Lebenszyklus auf einem Node. Jede Compose-Platzierung enthält das gesamte Projekt; Opfield verteilt keine einzelnen Dienste einer Instanz über Nodes.

Die Anzahl der Replikate wird manuell festgelegt. Metrikbasiertes Autoscaling, mehrere Platzierungen desselben Workloads auf einem Node und opportunistische Neuverteilung fehlerfreier Instanzen liegen außerhalb dieses Modells.

Voraussetzungen

Das Aktivieren von Availability erfordert mindestens zwei kompatible Docker Nodes, die online sind. In der Produktion benötigt es außerdem mindestens zwei Relays auf anderen Hosts als dem Opfield-Host, in unterschiedlichen Fehlerdomänen; mit nur dem lokalen Relay hängt das Failover vom Opfield-Host ab. Siehe Wie viele Relays. Stellen Sie genug Kapazität für die gewünschte Anzahl an Replikaten und für vorübergehende Platzierungen während Updates bereit.

Der Workload darf keine konfigurierten oder beobachteten Mounts haben, einschließlich benannter, externer oder schreibgeschützter Volumes und Host-Bind-Mounts. Bei Compose wird das gesamte Projekt geprüft. Persistente Daten müssen in separaten Diensten liegen; Availability kopiert keine lokalen Daten zwischen Nodes.

Opfield legt Images nach Repository und Digest in seiner internen Registry fest und bezieht sie vorab auf geeigneten Bereitschafts-Nodes. Prüfen Sie den Registry-Zugriff, die Pfade über Relay und Secure Link sowie abhängige verwaltete Datenbanken.

Availability aktivieren

1. Öffnen Sie den Container, das Deployment oder das Compose-Projekt und dessen Bereich Availability.
2. Wählen Sie Check eligibility und lösen Sie Inkompatibilitäten auf.
3. Schalten Sie Enable ein und wählen Sie Mode. Legen Sie bei Replicated Serving placements fest.
4. Wählen Sie unter Eligible nodes entweder All compatible nodes oder Selected nodes mit einer ausdrücklichen Node-Liste.
5. Prüfen Sie die Einstellungen für Ersatz und Rollout und wählen Sie dann Save.
6. Verfolgen Sie die Operation und die Liste Placements, bis die angeforderte Anzahl bedienender Platzierungen erreicht ist.
7. Prüfen Sie eine echte Anfrage über die Route, den Datenbankzugriff und die Anwendungslogs.

Nur den Schalter umzulegen, wendet die Richtlinie nicht an: Save ist erforderlich. Ein erfolgreiches Speichern bedeutet, dass der Sollzustand angenommen wurde, nicht dass die Erstellung der Instanzen abgeschlossen ist.

Aktivieren bei einem laufenden Workload

Das Aktivieren von Availability bei einem Workload, der bereits bedient, unterbricht ihn nicht und startet nie eine zweite Kopie daneben. Der laufende Container, das Deployment oder das Compose-Projekt wird zur ersten Platzierung auf dem Node, auf dem es läuft:

• Ein Container wird nie neu erstellt. Benötigte Netzwerke verwalteter Datenbanken werden angebunden, während er läuft.
• Ein Deployment oder Compose-Projekt, das bereits das Image ausführt, das Opfield in seine Registry gespiegelt hat, wird im laufenden Betrieb übernommen. Ein übernommenes Deployment behält die Portbindung seines Routers und ein übernommenes Compose-Projekt seine veröffentlichten Ports, bis ein Rollout sie neu erstellt.
• Ein Deployment oder Compose-Projekt, das nicht im laufenden Betrieb übernommen werden kann, weil es die Verbindungseinstellungen der verwalteten Datenbank benötigt oder ein anderes Image ausführt, wird ohne Bedienlücke ersetzt, wo die Richtlinie zwei Kopien erlaubt (Replicated oder Failover mit Allow available mode): Ein Deployment stellt die neue Konfiguration in seinem inaktiven Slot bereit und schaltet nach Bereitschaft um; ein Compose-Projekt erhält zuerst eine Kopie auf einem anderen Node, die Routen wechseln zu ihr, dann wird das Original neu erstellt und im Failover-Modus die zusätzliche Kopie entfernt. Kann kein anderer Node die Kopie bedienen, bleibt das Original unverändert, und die Aktivierung wird erneut versucht.
• Ein Failover-Einzelexemplar mit ausgeschaltetem Allow available mode führt nie zwei Kopien aus und nimmt daher stattdessen eine kurze geplante Lücke in Kauf: Ein Deployment erstellt seinen neuen Slot mit bereits bezogenem Image, bevor der alte Slot stoppt, und schaltet zurück, wenn der neue Slot nicht bereit wird; ein Compose-Projekt bezieht jedes Image, bevor ein Dienst neu erstellt wird.

Der Node, auf dem der Workload läuft, bedient ihn weiter, auch wenn Priority mode einen anderen Node an die erste Stelle setzt; das Failback verschiebt ihn danach.

Routen erreichen den ursprünglichen Workload über ihren eigenen Secure Link, bis eine Platzierung über ihren Mitglieds-Link bedient. Erst dann schaltet Opfield die Route auf die Mitglieder um; es behält den alten Link weitere 5 Sekunden, damit Anfragen, die die vorherigen Worker von nginx noch halten, abgeschlossen werden können, und entfernt ihn dann.

Einstellungen für Ersatz und Rollout

• Replacement grace – Wartezeit nach dem Verlust der Steuerungsverbindung zum Node, bevor ein Ersatz erstellt wird. Der Standard ist 15 Sekunden; Image-Vorbereitung, Start und Health Checks benötigen zusätzliche Zeit.
• Maximum unavailable – wie viele Platzierungen ein geplantes Update gleichzeitig nicht verfügbar machen darf.
• Maximum surge – wie viele vorübergehende Platzierungen über der gewünschten Anzahl existieren dürfen. Diese erfordern zusätzliche Kapazität.
• Drain interval – Zeit zwischen dem Entfernen einer Platzierung aus dem neuen Routing und ihrem Stoppen, damit bestehende Verbindungen abgeschlossen werden können.

Prioritätsmodus

Standardmäßig platziert Opfield bedienende Instanzen nach freier Kapazität auf geeigneten Nodes. Priority mode lässt beide Modi stattdessen Nodes in einer festen Reihenfolge bevorzugen. Schalten Sie ihn unter Eligible nodes ein und ordnen Sie die Liste mit den Schaltflächen nach oben und unten: Der erste Node ist Primary, die nächsten sind Backup 1, Backup 2 und so weiter. Die Liste enthält nur geeignete Nodes; Nodes, die später geeignet werden, werden am Ende hinzugefügt. Wählen Sie Save, um die Reihenfolge anzuwenden.

Bedienende Platzierungen landen auf den ersten verfügbaren Nodes der Reihenfolge. Kehrt ein Node mit höherer Priorität zurück und bleibt er für Return to the primary after fehlerfrei (standardmäßig 300 Sekunden, 0–3600), führt Opfield eine Failback-Operation aus: Es startet den Workload auf diesem Node, schaltet den Datenverkehr auf ihn um und leert und entfernt dann die Backup-Platzierung, sodass durchgehend eine Platzierung bedient. Das Einschalten des Prioritätsmodus oder eine Änderung der Reihenfolge verschiebt den Workload auf dieselbe Weise. Die Availability-Zusammenfassung zeigt den Primary-Node und von wo der Workload bedient wird (Serving from), gekennzeichnet mit On backup, solange ein Backup bedient.

• Ein Node, der offline geht oder einen Fehler meldet, startet seine Wartezeit neu, sodass ein schwankender Node den Datenverkehr nicht zurückholt.
• Das Failback läuft nur, solange die Richtlinie fehlerfrei ist und keine andere Operation derselben Richtlinie aktiv ist; Ersatz, Rollout und Skalierung dieser Richtlinie haben Vorrang. Operationen verschiedener Richtlinien laufen parallel, sodass ein Failback nie auf die Heilung eines anderen Workloads wartet.
• Ein fehlgeschlagenes Failback lässt das Backup weiter bedienen und wird nach 15 Minuten erneut versucht. Verwenden Sie Retry unter Operations, um es früher zu versuchen.
• Das Failback erfordert Maximum surge von mindestens 1, damit während des Wechsels eine Platzierung bedient; im Modus Replicated genügt auch Maximum unavailable von mindestens 1. Andernfalls warnt Check eligibility, und der Workload bleibt auf dem Backup.
• Wenn die Nodes das Failover selbst ausführen (Failover der Datenebene), ist ein Failback stattdessen eine Übergabe: Der bedienende Node stoppt seine Kopie, bevor der nächste Node seine eigene startet, weil der standardmäßige strikte Partitionsmodus nie zwei Kopien gleichzeitig ausführt. Im Failover-Modus bedient der Workload nicht, während die alte Kopie stoppt und die neue startet und bereit wird, meist 5–15 Sekunden; im Modus Replicated bedienen die anderen Replikate weiter.
• Nach einem Neustart von Opfield beginnt die fehlerfreie Zeit jedes Nodes neu, sodass kein Failback läuft, bis die Wartezeit verstrichen ist.

In der API und in MCP (manage_docker_availability) heißen die Richtlinienfelder priorityMode, nodePriority (Node-IDs in Reihenfolge, Primary zuerst) und failbackDelaySeconds.

Routen und Datenbank-Bindings

Proxy Hosts, Additional Routes und Advanced Secure Links können den logischen Workload ansteuern. Opfield stellt die Endpunkte fehlerfreier Platzierungen bereit und verteilt neue Ingress-Verbindungen nach dem Verfahren der wenigsten Verbindungen. Bestehende Verbindungen wechseln nicht zwischen Replikaten.

Veröffentlichte Host-Ports werden nur auf dem ursprünglichen Node bedient: Platzierungen auf anderen Nodes veröffentlichen keine und werden über Routen, Container-Links oder Advanced Secure Links erreicht. Die Vorabprüfung warnt davor mit AVAILABILITY_HOST_PORTS_NOT_REPLICATED.

Eine Platzierung nimmt erst Datenverkehr an, wenn ihr Workload bereit ist: Ihr Image-Health-Check meldet fehlerfrei, sofern das Image einen hat; andernfalls nimmt ihr Port Verbindungen an. Bei einem Deployment muss die Anwendung des aktiven Slots über den Deployment-Router antworten, nicht nur der Router selbst. Der Health-Zustand der Route wird über die Secure Links der Platzierungen geprüft, sodass eine fehlerfreie Availability-Route als online angezeigt wird.

Eine Platzierung, die nicht bedient, etwa eine Bereitschaftsplatzierung oder eine gestoppte Kopie, hält ihren Link auf dem Ingress Node in jedem Modus geschlossen, sodass keine Anfrage sie erreicht: nginx lässt die Verbindung fehlschlagen, bevor es etwas sendet, und geht zur nächsten Platzierung über, was für jede Methode sicher ist.

Schlägt eine Platzierung dennoch fehl, versucht der Ingress Node die nächste Platzierung: bei Verbindungsfehlern für jede Anfrage und bei Antworten 502, 503 und 504 für Anfragen, die sicher wiederholt werden können, etwa GET und HEAD, bis zu 5 Versuche innerhalb von 10 Sekunden. POST-, PATCH- und LOCK-Anfragen werden nicht erneut gesendet, sobald sie eine Platzierung erreicht haben. Eine fehlgeschlagene Platzierung wird für eine Sekunde übersprungen; jede Platzierung ist außerdem als Backup aufgeführt, das nie übersprungen wird, sodass der Route nie die Upstreams ausgehen, solange eine Platzierung bedient.

Wird der Host einer Platzierung unerreichbar, verwerfen die Relays seine Verbindung innerhalb von etwa 3,5 Sekunden und melden sie als nicht bereit, und der Ingress Node schließt ihren Link. Bis dahin kostet eine neue Verbindung zu ihr höchstens 2 Sekunden, bevor nginx die nächste Platzierung versucht. Laufende Anfragen an sie werden auf einer anderen Platzierung wiederholt, wenn sie sicher wiederholt werden können; ein bereits gesendetes POST erhält 502. Der Link einer Platzierung gibt nur dann sofort auf, wenn ein Relay zu dieser Platzierung geantwortet hat und eine andere Platzierung bedient. Ist überhaupt kein Relay erreichbar, zum Beispiel während das einzige Relay neu startet, oder bedient keine andere Platzierung, werden neue Verbindungen wie bei jedem Secure Link zurückgehalten: bis zu 3 Sekunden oder 8 Sekunden bei einem angekündigten Neustart.

Bindings verwalteter Datenbanken erhalten Verbindungen pro Platzierung. Halten Sie Beziehungen an der logischen Ressource statt an vorübergehenden Containernamen. Um eine bestimmte Instanz zu diagnostizieren, verwenden Sie, wo verfügbar, die Platzierungsauswahl in Logs, Konsole und Monitoring.

Ein Container-Link zu einem Availability-Workload folgt seinen fehlerfreien Platzierungen: Jeder Node eines Nutzers bevorzugt eine Platzierung auf seinem eigenen Node, der Link wechselt von einer Platzierung weg, die Availability als fehlerhaft einstuft, und kehrt zurück, sobald sie ihre Health Checks wieder besteht. Ein Link zu einem Availability-Deployment muss einen der Ports des Deployments verwenden, weil der Deployment-Router nur diese weiterleitet.

Updates und Zustand der Replikate

Ein rollierendes Update, das endgültig fehlschlägt oder 3 Versuche lang bzw. 15 Minuten lang immer wieder fehlschlägt, wird automatisch zurückgesetzt: Bereits aktualisierte Replikate kehren zum vorherigen Image und zu den vorherigen Einstellungen zurück, und die Richtlinie behält den ursprünglichen Fehler. Eine Einstellungsänderung erstellt nicht mehr jedes Replikat neu.

Ein Rollout aktualisiert jede Kopie, einschließlich des ursprünglichen Workloads auf seinem ersten Node, und ist erst abgeschlossen, wenn jeder Node die neue Version seiner Kopie ausführt. Ein Rollout, das ein Neustart oder Update von Opfield unterbricht, wird nicht als fehlgeschlagen gewertet oder zurückgesetzt: Es wird fortgesetzt, wenn Opfield zurück ist, mit dem Image und den Einstellungen, mit denen es gestartet wurde.

Availability funktioniert mit Multi-Plattform-Images ab Docker 29, das den containerd-Image-Store verwendet. Findet eine Heilung nach einem Opfield-Update die interne Registry noch im Start, versucht sie es erneut, statt fehlzuschlagen.

Opfield prüft den Zustand der Replikate alle 30 Sekunden. Ein Replikat, das bei zwei Prüfungen hintereinander fehlt, gestoppt ist, in einer Neustartschleife hängt oder fehlerhaft ist, wird aus dem Routing entfernt und geheilt; es kehrt nach zwei fehlerfreien Prüfungen zurück. Ein eigenständiger Container, der bereits eine Route hat, kann Availability aktivieren, und Availability kann auch deaktiviert werden, wenn kein Replikat fehlerfrei ist.

Node-Ausfall und Wiederherstellung

Im Lease-Modus ersetzen die Nodes einen ausgefallenen Inhaber selbst; siehe Failover der Datenebene. Beim Backend-Failover wird ein Node, dessen Steuerungsverbindung abbricht, nach 5 Sekunden als offline angezeigt, und seine Platzierungen verlassen das Routing nach 10 Sekunden, sodass ein kurzer Relay-Neustart keinen Datenverkehr verschiebt. Nach Replacement grace startet Opfield eine vorbereitete Bereitschaftsplatzierung, sofern die Richtlinie eine hat, und erstellt andernfalls einen Ersatz auf einem verfügbaren geeigneten Node. Verbindet sich der ausgefallene Node erneut, heilt Opfield die Richtlinie sofort.

In beiden Modi wird eine Richtlinie mit weniger bedienenden Platzierungen als angefordert und geeigneter Kapazität, die online ist, ohne Bearbeitung geheilt: Opfield prüft alle 15 Sekunden, außerhalb der Offline-Kulanzzeit eines Nodes, und immer dann, wenn sich ein Node verbindet. Ein update, das die aktuelle Anzahl bedienender Platzierungen oder die Node-Auswahl erneut setzt, repariert ebenfalls fehlende Platzierungen. Wird die angeforderte Anzahl dennoch nicht wiederhergestellt, prüfen Sie die Phase der Operation, Kompatibilität und Kapazität der Nodes, das Beziehen der Images, den Zustand der Anwendung und private Abhängigkeiten.

Beim Backend-Failover kann ein nicht erreichbarer Host noch seinen alten Prozess ausführen. Opfield schließt veraltete Generationen aus dem verwalteten Routing aus und gleicht sie beim erneuten Verbindungsaufbau ab. Das ist weder ein physisches Fencing des Nodes noch eine Garantie für einen einzigen Schreiber in einem externen System; nur das Failover der Datenebene lässt einen abgeschnittenen Node seine eigene Kopie stoppen.

Das Backend-Failover erfordert eine funktionierende Opfield Control Plane. Availability bietet keine Hochverfügbarkeit für Opfield selbst, nginx, Datenbank-Engines, Registry-Speicher oder gemeinsam genutzte Volumes. Verwaltete Datenbanken und verwalteter Speicher haben ihre eigene Availability auf mehreren Storage Nodes. Prüfen Sie die Ausfallsicherheit des Relay-Pfads und jede Abhängigkeit separat.

Prüfen Sie nach der Wiederherstellung die Anzahl bedienender Platzierungen, echten Kundenverkehr, Datenbankzugriff und die Bereinigung veralteter Platzierungen. Löschen Sie keine untergeordneten Container manuell, um den Abschluss der Operation zu erzwingen.

Stoppen und starten

Stop bei einem Workload mit Availability stoppt die laufenden Kopien und behält jede Platzierung: Bereitschaftsplatzierungen bleiben vorbereitet, und die Richtlinie bleibt fehlerfrei, solange der Workload gestoppt ist. Start startet die Kopien, die zuletzt bedient haben, nie eine Bereitschaftsplatzierung, und behält die Bereitschaftsplatzierungen, sodass durch Stoppen und Starten keine Platzierung entfernt, neu erstellt oder als fehlgeschlagen gewertet wird. Der ursprüngliche Workload wird nie gelöscht: nicht beim Schließen einer Lease, nicht durch die Bereinigung veralteter Platzierungen und nicht als überzählige Bereitschaftsplatzierung. Auf einem Node, der nicht mehr ausgewählt ist, bleibt er gestoppt bestehen. Ein Docker-Daemon, der mit lang laufenden Befehlen beschäftigt ist, verzögert ein Stoppen, Starten oder Heilen (AVAILABILITY_DAEMON_BUSY, automatisch wiederholt), statt Platzierungen als fehlgeschlagen zu markieren. Ein Start, Stopp oder Neustart, der angefordert wird, während die vorherige Operation der Richtlinie noch läuft, wird eingereiht und danach ausgeführt; Container, Deployments und Compose-Projekte verhalten sich gleich.

Ein Stop, der direkt nach dem Aktivieren von Availability gesendet wird, bevor die Nodes das Failover übernommen haben, hält jede Kopie gestoppt: Kein Node startet selbstständig eine Kopie eines gestoppten Workloads.

Operationen mehrerer Richtlinien

Jede Richtlinie führt jeweils eine Operation der Reihe nach aus. Operationen verschiedener Richtlinien laufen parallel: Heilungs-, Skalierungs-, Rollout-, Aktivierungs- und Bereinigungsoperationen laufen für höchstens 4 Richtlinien gleichzeitig, während Failback, Start, Stopp, Neustart und Deaktivierung nie auf dieses Limit warten und daneben laufen.

Availability deaktivieren

Schalten Sie Enable aus und speichern Sie die Änderung. Wählen Sie unter Disable Availability die Surviving placement, geben Sie zur Bestätigung den Namen des Workloads ein und wählen Sie Disable and keep one.

Die verbleibende Platzierung läuft weiter und wird im laufenden Betrieb zum gewöhnlichen Workload; das Deaktivieren startet oder erstellt sie nicht neu:

• Der ursprüngliche Container, das Deployment oder das Compose-Projekt wird im laufenden Betrieb übernommen und erhält seine eigene Neustartrichtlinie zurück. Ein Compose-Projekt, dessen Container von Availability vorbereitet wurden, wird auf der Compose-Seite bis zu Ihrem nächsten Anwenden als abweichend angezeigt.
• Auch eine Deployment-Kopie auf einem anderen Node wird im laufenden Betrieb übernommen.
• Eine Container- oder Compose-Projekt-Kopie auf einem anderen Node läuft unter einem von Availability generierten Namen. Sie wird durch eine Kopie mit dem ursprünglichen Namen des Workloads auf diesem Node ersetzt, die startet, bevor die alte Kopie entfernt wird, sodass der Datenverkehr keine Lücke hat.

Ist die Richtlinie im Lease-Modus, schließt die Deaktivierung zuerst die Lease und hält die verbleibende Kopie während des Schließens am Laufen. Während die Deaktivierung läuft, läuft keine Heilung, Skalierung, kein Failback und kein Start der Richtlinie (AVAILABILITY_DISABLE_IN_PROGRESS), und eine Deaktivierung, die warten muss, behält den Status disabling. Ein erneuter Versuch behält die zuerst gewählte verbleibende Platzierung bei.

Warten Sie, bis die Operation und das Entfernen der anderen Platzierungen abgeschlossen sind. Prüfen Sie die verbleibende Instanz, Routen und Datenbank-Bindings: Die Ressource sollte ihren gewöhnlichen Lebenszyklus auf einem Node fortsetzen.