Failover der Datenebene

Workload Availability kann auf zwei Arten ein Failover durchführen. Beim Backend-Failover bemerkt Opfield, dass ein Node verschwunden ist, und erstellt einen Ersatz; das erfordert ein laufendes Opfield. Beim Failover der Datenebene (Lease-Modus) entscheiden die Docker Nodes, Ingress Nodes und Relays des Workloads untereinander, wer ihn bedient, sodass ein ausgefallener oder abgeschnittener Node innerhalb von etwa 45 Sekunden ersetzt wird, selbst während Opfield gestoppt ist, aktualisiert wird oder nicht erreichbar ist.

Der Lease-Modus ist Teil von Business und Enterprise. Er benötigt keinen Schalter: Eine Richtlinie verwendet ihn, sobald jeder Teilnehmer ihn unterstützt und 2 Minuten stabil gelaufen ist. Teilnehmer sind die Docker Nodes, die den Workload ausführen können (Kandidaten), die Ingress Nodes seiner Routen und die Relays, die seinen Datenverkehr transportieren. Sie müssen die Fähigkeit availability_lease_v2 ankündigen, was der Docker-Daemon, der nginx-Daemon und das Relay von Opfield 2.11 tun. Komponenten früher Release Candidates von 2.11, die availability_lease_v1 ankündigen, gelten als veraltet.

Die Availability-Zusammenfassung des Workloads zeigt unter Lease mode: Lease, wenn die Nodes das Failover selbst durchführen, Legacy beim Backend-Failover und Bootstrapping oder Closing, während die Richtlinie wechselt. Fahren Sie mit dem Mauszeiger über das Abzeichen, um den Grund zu sehen.

Funktionsweise

Jede bedienende Platzierung ist ein Slot: Der Failover-Modus hat einen, der Modus Replicated einen pro Replikat. Für jeden Slot halten die Nodes und Relays der Richtlinie eine Lease, und nur der Node, der sie hält (der Inhaber), führt seine Kopie des Workloads aus.

• Erneuerung. Der Inhaber erneuert seine Lease alle paar Sekunden mit einer Mehrheit der Abstimmenden der Richtlinie. Kann er das nicht, stoppt er seine eigene Kopie, bevor die Lease an jemand anderen übergehen kann. Der nächste Kandidat übernimmt dann den freien Slot und startet seine Kopie, etwa 45 Sekunden nach dem Ausfall.
• Bereitschaftsplatzierungen. Opfield bereitet vorab bis zu zwei Bereitschaftsplatzierungen auf anderen Kandidaten-Nodes vor: Das Image wird bezogen und der Container erstellt, aber nicht gestartet, sodass eine Übernahme ihn nur noch startet.
• Datenverkehr. Anfragen erreichen nur den Inhaber jedes Slots. Der Secure Link jeder Platzierung ist auf jedem Relay registriert, das den Lease-Modus unterstützt; die Links von Bereitschaftsplatzierungen bleiben registriert, aber geschlossen, bis ihr Node den Slot hält, sodass der neue Inhaber unmittelbar nach einer Übernahme über jedes Relay erreichbar ist. Ein Inhaber nimmt erst Datenverkehr an, wenn sein Workload bereit ist; siehe Routen und Datenbank-Bindings.
• Freigabe. Ein Inhaber, der seine Kopie aus einem lokalen Grund gestoppt hat (sein Lease-Timer, ein verlorener Watchdog, ein erkanntes Einfrieren, eine geschlossene Lease), gibt den Slot frei, sobald bestätigt ist, dass der Container gestoppt ist, sodass der nächste Kandidat innerhalb von Sekunden startet, statt auf den Ablauf der Lease zu warten.
• Ein Slot pro Node. Im Modus Replicated hält ein Node nie zwei Slots derselben Richtlinie. Ein Node, der zurückkehrt, nimmt zuerst seinen eigenen vorherigen Slot zurück.
• Nicht erreichbare Inhaber. Antwortet der Host eines Inhabers nicht mehr, verwerfen die Relays seine Verbindung innerhalb von etwa 3,5 Sekunden, und Ingress Nodes senden ihm keine Anfragen mehr; siehe Routen und Datenbank-Bindings. Im Modus Replicated bedienen ab dann die anderen Replikate; der Slot selbst wechselt, sobald die Lease an den nächsten Kandidaten übergegangen ist.

Eine Docker Engine (dockerd), die auf dem Inhaber hängt, stoppt den Datenverkehr zur laufenden Kopie nicht und wird nicht als Grund gewertet, sie zu stoppen. Läuft die Lease des Inhabers währenddessen ab, stoppt der Lease-Watchdog die Kopie.

Lease-Watchdog

Jeder Docker Node, der einen Slot halten kann, betreibt den Lease-Watchdog, einen kleinen Dienst namens opfield-lease-watchdog mit eigener Release-Linie (gateway-lease-watchdog auf einem vor 2.12.1 installierten Node, bis sein Docker-Daemon aktualisiert wird). Er stoppt einen Container im Lease-Modus, sobald dessen Lease-Frist abgelaufen ist, selbst wenn der Docker-Daemon oder dockerd hängt. Das Docker-Node-Installationsprogramm installiert ihn, auf bestehenden Nodes installiert ihn der Docker-Daemon selbst, wenn er als Root läuft, und der Watchdog hält sich selbst aktuell. Ein Daemon, der ihn nicht installieren kann, lässt die Richtlinie diesen Node mit watchdog_missing aufführen: Führen Sie dort das Node-Installationsprogramm erneut aus.

Ein Watchdog, der einige Sekunden langsam ist (bis etwa 8), stoppt nie einen Workload. Fehlt sein Heartbeat etwa 10 Sekunden lang, stoppt der Inhaber seine Kopie und gibt den Slot an den nächsten Kandidaten frei. Wird ein Docker-Daemon auf ein Release ohne Lease-Unterstützung zurückgesetzt, entfernt der Watchdog die zurückgebliebenen Fristen nach 10 Minuten, sodass er keine Container stoppt, die der ältere Daemon ausführt.

Abstimmende und Witness

Jede Richtlinie hat ihre eigenen Abstimmenden: ihre Kandidaten-Nodes, einer pro physischem Host, in Übernahmereihenfolge, plus Witnesses, sodass die Anzahl ungerade und mindestens 3, höchstens 7 ist. Nur Nodes und Relays, die availability_lease_v2 ankündigen und eine Lease-Identität gemeldet haben, stimmen ab. Eine Richtlinie mit drei Kandidaten benötigt keinen Witness.

Ein Witness ist ein Relay oder Docker Node auf einem anderen Host als jeder Kandidat. Wählen Sie ihn unter Witness in der Richtlinie: Auto (farthest by latency) wählt das geeignete Mitglied, dessen kürzeste Umlaufzeit zu einem Kandidaten am längsten ist und das daher am wenigsten wahrscheinlich einen Standort mit ihnen teilt; Sie können auch ein bestimmtes Relay oder einen bestimmten Node auswählen. Der automatische Witness ist nie das lokale Relay von Opfield, solange ein anderes Relay oder ein anderer Node Witness sein kann, weil das lokale Relay zusammen mit Opfield stoppt. Er bleibt, bis er nicht mehr abstimmen kann, sodass Schwankungen der Umlaufzeit die Abstimmenden nie ändern. Die Zusammenfassung warnt, wenn der Witness wahrscheinlich am selben Standort wie ein Kandidat liegt (unter 2 ms), wenn kein geeigneter Witness existiert oder wenn der konfigurierte Witness nicht abstimmen kann und stattdessen ein automatischer verwendet wird.

Abstimmende müssen einander ohne Opfield erreichen. Jeder Node einer Richtlinie im Lease-Modus verbindet sich für seinen Lease-Verkehr mit jedem Relay, und ein lebendes Relay genügt, solange eine Mehrheit der Abstimmenden einander darüber erreichen kann. Die Zusammenfassung warnt „Voter reachability margin is insufficient“, wenn der Verlust eines weiteren Abstimmenden keine Mehrheit übrig ließe; das lokale Relay von Opfield zählt nicht zu dieser Marge. Eine Richtlinie mit zwei Kandidaten und einem Relay auf einem anderen Host hat eine Marge von einem Abstimmenden.

Netzwerkpartitionen

Allow available mode (partitionMode in der API) entscheidet, was geschieht, wenn das Netzwerk die Abstimmenden aufteilt:

• Aus (strict, der Standard). Zwei Kopien eines Slots laufen nie gleichzeitig. Nur die Seite, die eine Mehrheit der Abstimmenden behält, bedient; ein Inhaber auf der anderen Seite stoppt seine Kopie.
• Ein (available). Beide Seiten einer Partition bedienen weiter, und zwei Kopien können kurzzeitig laufen. Erlauben Sie das nie für Einzelexemplare wie Indexer, Warteschlangen-Consumer oder geplante Jobs.

Eingefrorene Hosts und Uhränderungen

Lease-Timer verwenden die monotone Uhr jedes Hosts. Eine Änderung der Wanduhr, etwa eine NTP-Korrektur in jede Richtung und jeder Größe, stoppt nie eine Kopie.

Wird der Host oder die virtuelle Maschine des Inhabers für mehr als etwa 2 Sekunden pausiert, eingefroren oder suspendiert, kann seine Lease inzwischen an einen anderen Node übergegangen sein. Nach der Fortsetzung erkennt der Node die verlorene Zeit anhand der Uhren des ersten Relays oder Abstimmenden, von dem er hört, und stoppt seine Kopie sofort, ohne Kulanzzeit, wenn seine Lease-Zeit abgelaufen ist. Der Docker-Daemon protokolliert dies als Fencing mit dem Grund host_frozen. Eine Lease, die der Node nach dem Einfrieren erwirbt, wird deswegen nie gestoppt, und kürzere Pausen bleiben innerhalb der normalen Zeitmargen. Ein Inhaber, der nach der Fortsetzung niemanden erreicht, stoppt seine Kopie nach seinem eigenen Lease-Timer.

Ausgeschlossene Nodes

Eine Bedingung eines einzelnen Nodes ändert nie den Modus der Richtlinie. Stattdessen wird der Node in der Zusammenfassung unter Excluded nodes aufgeführt (lease.excludedNodes in der API), mit einem dieser Gründe:

Grund	Bezeichnung in der Zusammenfassung	Bedeutung und Abhilfe
offline	offline	Der Node hat keine Steuerungsverbindung zu Opfield. Stellen Sie den Host oder seinen Daemon wieder her.
watchdog_missing	lease watchdog not running	Der Lease-Watchdog läuft nicht. Starten Sie opfield-lease-watchdog oder führen Sie das Node-Installationsprogramm erneut aus.
daemon_outdated	daemon outdated	Der Docker-Daemon kündigt availability_lease_v2 nicht an. Aktualisieren Sie ihn.
identity_pending	no lease identity yet	Der Daemon hat seine Lease-Identität noch nicht gemeldet, meist direkt nach einem Update.

Ein ausgeschlossener Node erhält keine neue Bereitschaftsplatzierung, kein Failback und kein anderer geplanter Wechsel geht zu ihm, und sein Daemon übernimmt keinen Slot; das tut der nächste Kandidat. Opfield schneidet einen Node, der einen Slot hält, aus diesem Grund nie ab: Ein Node ohne Watchdog stoppt seine eigene Kopie, und ein veralteter Inhaber behält seinen Slot, bis er aktualisiert wird oder übergibt. Ein veralteter oder nicht identifizierter Node verlässt die Abstimmenden und die Kandidatenliste erst, nachdem die Bedingung 2 Minuten angedauert hat, sodass ein Daemon-Neustart oder ein rollierendes Update nichts ändert. Ein Failback auf einen Node, der ausgeschlossen war, wartet Return to the primary after ab dem Ende des Ausschlusses.

Wechsel in den Lease-Modus

Eine Richtlinie im Backend-Failover wechselt erst dann in den Lease-Modus, wenn jeder Teilnehmer, den sie benötigt, availability_lease_v2 2 Minuten ohne Unterbrechung und ohne Neustart ausgeführt hat: jeder Kandidaten-Docker-Node mit seinem Lease-Watchdog und seiner Identität, die Ingress Nodes ihrer Routen, die Relays, die sie transportieren, und ihre Witnesses. Bis dahin lautet ihr Grund participants_settling und nennt die Nodes oder Relays, die sich noch stabilisieren, sodass eine Flotte mitten in einem Update nie halb wechselt. Nach einem Neustart von Opfield beginnen die 2 Minuten erneut.

Der Lease-Modus wartet außerdem, bis eine laufende Aktivierung oder ein laufendes Rollout der Richtlinie abgeschlossen ist. Der erste Inhaber jedes Slots ist der Node, auf dem der Workload in diesem Moment bedient, unabhängig davon, was die Prioritätsreihenfolge sagt; ein Prioritäts-Failback verschiebt ihn danach als geplante Übergabe. Ist dieser Node nicht bereit, seinen Slot zu übernehmen, zum Beispiel weil er keine Kopie des Workloads findet, sein Lease-Watchdog nicht läuft oder die Neustartrichtlinie der Kopie nicht no ist, protokolliert sein Docker-Daemon den Grund einmal pro Grund.

Der Wechsel in den Lease-Modus unterbricht den Workload nicht. Die bedienenden Kopien laufen weiter und behalten ihre Secure Links: Für einen Slot zählt nur eine Lease, die nach dem Wechsel gebildet wurde, sodass eine alte Lease aus einer früheren Lease-Periode einen Node nie dazu bringt, seine eigene Kopie zu stoppen, und die Links bedienender Kopien ändern ihre Rolle an Ort und Stelle, statt neu registriert zu werden.

Verlassen des Lease-Modus

Eine Richtlinie verlässt den Lease-Modus nur, wenn der Lease-Modus unmöglich geworden ist:

Grund	Ursache
insufficient_voters	Weniger abstimmungsfähige Mitglieder, als eine Mehrheit benötigt; aktualisieren Sie die Kandidaten oder fügen Sie ein Relay als Witness hinzu
ingress_not_capable	Ein Ingress Node der Routen des Workloads führt einen nginx-Daemon ohne availability_lease_v2 aus
relays_not_capable	Ein Relay, das den Workload transportiert, führt eine Version ohne availability_lease_v2 aus
candidates_not_capable, watchdog_missing	Kein Kandidat kann einen Slot halten, und kein Slot wird gehalten
controller_unsupported	Diese Opfield-Edition führt das Availability-Failover nur aus dem Backend aus
signing_key_pending	Noch kann kein Signaturschlüssel für Relay-Richtlinien Lease-Daten signieren

controller_unsupported bezeichnet einen Community-Build ohne den Lease-Controller. Die Lizenz schließt den Lease-Modus nie: Keine Änderung des Lizenzzustands, auch kein Ablauf, wirkt sich auf diese Entscheidung aus.

Außer beim Deaktivieren von Availability und bei Lebenszyklusoperationen wie Stop, Start und Restart, die ihn sofort verlassen, muss die Bedingung 2 Minuten ohne Unterbrechung andauern. Währenddessen funktioniert die Lease weiter, die API zeigt in lease.reason.since, seit wann, und die Zusammenfassung warnt: „Data-plane failover is impossible right now: … The policy goes back to backend failover at … unless this is fixed before; the serving copy keeps running.“

Das Verlassen des Lease-Modus stoppt nie die bedienende Kopie. Die Richtlinie durchläuft Closing: Opfield veröffentlicht eine geschlossene Lease, die für jeden Slot den Node nennt, der ihn hält. Sobald eine Mehrheit der Abstimmenden diesem Node das Schließen bestätigt, lässt er seine Kopie ohne Lease weiterlaufen, sein Watchdog bewacht diese Kopie nicht mehr, und das Backend-Failover übernimmt sie als laufend, meist innerhalb von Sekunden; nichts startet sie neu, und ihre Secure Links bedienen weiter. Währenddessen zeigt die Zusammenfassung den Node unter Kept serving mit „confirming“ und dann „keeps running“ (lease.retainedHolders in der API). Ein Inhaber, der während des Schließens keine Mehrheit erreichen kann, weil er abgeschnitten ist, stoppt seine Kopie wie jeder Lease-Inhaber, und das Backend-Failover startet diesen Slot wieder, sobald seine Lease abgelaufen ist, etwa 47 Sekunden nachdem eine Mehrheit der Abstimmenden das Schließen gesehen hat.

Ein Schließen behält jede Platzierung, einschließlich des ursprünglichen Workloads: Bereitschaftsplatzierungen bleiben vorbereitet, und nichts wird entfernt oder zur Bereinigung eingereiht. Muss eine Kopie danach im Backend-Failover gestartet werden, wird eine vorbereitete Bereitschaftsplatzierung gestartet, bevor eine neue Platzierung erstellt wird. Nur Stop stoppt den Workload, nach dem Schließen. Das Deaktivieren von Availability lässt die verbleibende Platzierung weiterlaufen und entfernt die anderen Platzierungen selbst. Ist die Ursache behoben, kehrt die Richtlinie nach den üblichen 2 Minuten Stabilisierung selbstständig in den Lease-Modus zurück und übernimmt die behaltenen Bereitschaftsplatzierungen unverändert.

Was Opfield weiterhin tut

Opfield plant jeden Wechsel und führt die Einträge; die Nodes entscheiden nur, wer bedient, wenn etwas ausfällt.

• Operationen laufen über Richtlinien hinweg parallel. Jede Richtlinie führt jeweils eine Operation aus. Heilungs-, Skalierungs-, Rollout- und ähnliche Hintergrundoperationen laufen für höchstens 4 Richtlinien gleichzeitig; Failback, Start, Stopp, Neustart und Deaktivierung warten nie auf dieses Limit. Ein Node, der zurückkehrt, kann daher mehrere Workloads zurückholen, ohne sich hinter Heilungen anderer Richtlinien einzureihen.
• Geplante Wechsel sind Übergaben. Ein Failback, ein Leeren, ein manueller Wechsel, eine Änderung der Prioritätsreihenfolge oder ein Rollout verschiebt einen Slot als Übergabe: Der bedienende Node stoppt seine Kopie und gibt die Lease frei, und erst dann startet der nächste Node seine eigene. Die Secure Links der Mitglieder tauschen ihre Rollen an Ort und Stelle, der des alten Inhabers zu Bereitschaft und der des neuen Inhabers zu bedienend, sodass während einer Übergabe weder ein Link noch ein Relay-Endpunkt erstellt wird. Der Slot bedient nichts für die Dauer des Stoppens der alten Kopie plus Start und Bereitschaft der neuen, meist 5–15 Sekunden. Im Failover-Modus mit ausgeschaltetem Allow available mode schlagen Anfragen in dieser Zeit fehl; im Modus Replicated bedienen die anderen Replikate weiter.
• Heilung. Eine Richtlinie mit weniger bedienenden Kopien oder Bereitschaftsplatzierungen als benötigt und geeigneter Kapazität, die online ist, erhält alle 15 Sekunden und immer dann, wenn sich ein Node verbindet, eine Wartung. Ein Node, der zurückkehrt, erhält seinen freien Slot zurück: Seine Platzierung bleibt erhalten, und eine fehlende wird neu erstellt. Ein Node, der am Ende zwei Slots hält, übergibt einen an eine Bereitschaftsplatzierung an anderer Stelle, mit einer kurzen Lücke für diese Kopie.
• Bereitschaftsplatzierungen bleiben unverändert. Eine Bereitschaftsplatzierung erneut vorzubereiten, was Heilung, ein erneuter Verbindungsaufbau oder eine Wartung regelmäßig tun, ändert nichts, solange ihre Einstellungen, ihr Image (verglichen per Image-ID) und die Verbindungseinstellungen der verwalteten Datenbank, die sie erhalten würde, unverändert sind. Eine Bereitschaftsplatzierung, deren Datenbank-Verbindungseinstellungen sich geändert haben, zum Beispiel nach der Rotation von Binding-Zugangsdaten, gilt als nicht bereit und wird erneut vorbereitet. Ein Docker-Daemon, der mit lang laufenden Befehlen beschäftigt ist, verzögert die Heilung (AVAILABILITY_DAEMON_BUSY, wiederholt), statt Platzierungen fehlschlagen zu lassen.
• Nach einer Partition oder einem Ausfall. Kehrt ein Node zurück, liest Opfield den Zustand seiner Platzierungen von seinem Daemon: Eine gestoppte Kopie wird zu einer bereiten Bereitschaftsplatzierung, und ein Prioritäts-Failback läuft wie nach jedem Ausfall.
• Wenn Opfield zurückkehrt. Eine bedienende Kopie behält ihren Secure-Link-Pfad, während Opfield seine Nodes neu verbindet: Schlägt die Aktualisierung eines Mitglieds-Links fehl, weil ein Node sich noch nicht neu verbunden hat, behält der Link seinen Relay-Endpunkt, und Opfield versucht es erneut. Ein Relay, das sich neu verbindet, erhält jede Richtlinienänderung sofort.
• Einträge. Innerhalb von Sekunden nach dem Start erfährt Opfield die tatsächlichen Inhaber von seinem lokalen Relay, noch bevor sich die Nodes neu verbinden. Eine autonome Übernahme erscheint im Audit-Log als docker.availability.lease_failover, ein geplanter Wechsel als docker.availability.lease_handoff. Beide sind mit dem Zeitpunkt datiert, zu dem der neue Inhaber den Slot erworben hat, was früher sein kann als der Moment, in dem Opfield es bemerkt hat. Ein Slot, der verfallen ist und vom selben Node erneut übernommen wurde, weil seine Kopie gestoppt oder abgeschnitten wurde, auch während Opfield ausgefallen war, erscheint als docker.availability.lease_reacquired. Ein Daemon-Neustart, bei dem die Kopie ihre Lease behalten hat, ist kein neues Halten und ändert nichts. Die beste Quelle für den Zeitpunkt gewinnt: die eigene Meldung des neuen Inhabers, dann der früheste Zeitpunkt, zu dem ein Abstimmender sie gesehen hat, und erst dann der Zeitpunkt, zu dem Opfield es bemerkt hat. Zeiten, die ein Docker-Daemon meldet, werden um den gemessenen Versatz seiner Uhr gegenüber der von Opfield korrigiert, wenn sie um mehr als 2 Sekunden abweichen, zum Beispiel bei einer virtuellen Maschine, die mit nachgehender Uhr fortgesetzt wurde; ohne messbare Uhr entscheidet die Zeit der Abstimmenden oder der Zeitpunkt, zu dem Opfield es bemerkt hat. Ist die eigene Zeit des neuen Inhabers noch nicht bekannt, zum Beispiel weil er übernommen hat, während Opfield ausgefallen war, wird der Eintrag geschrieben, sobald die Zeit feststeht: sobald der Inhaber meldet, andernfalls nach 60 Sekunden mit der Zeit der Abstimmenden oder nach 5 Minuten, wenn kein Mitglied eine Zeit gemeldet hat. Die Details enthalten takeoverAt, noticedAt, takeoverSource (holder, voters oder noticed) und takeoverId. Ein wartender Eintrag wird in der Datenbank gespeichert, sodass ein Neustart oder Absturz von Opfield während des Wartens nichts verliert und ihn nie doppelt schreibt. Die Inhaberzeit in der Zusammenfassung (holderSince in der API) ist derselbe Übernahmezeitpunkt und wird korrigiert, wenn bessere Meldungen eintreffen.

Updates und gemischte Versionen

Aktualisieren Sie zuerst Opfield, dann die Node-Daemons und den Relay-Pool; unter Relay-Updates steht, warum die Daemons bei einem Update von 2.10 zuerst an die Reihe kommen sollten. Eine Richtlinie im Backend-Failover bleibt dort, solange ein Teilnehmer noch ein älteres Release ausführt, und wechselt einmal in den Lease-Modus, 2 Minuten nachdem der letzte Teilnehmer aktualisiert wurde. Eine Richtlinie, die bereits im Lease-Modus ist, behält ihn, solange nur Kandidaten-Docker-Nodes veraltet sind; sie werden ausgeschlossen, und ein veralteter Inhaber bedient weiter, bis er aktualisiert wird. Ein Ingress Node oder Relay, der länger als 2 Minuten auf einem älteren Release bleibt, schickt die Richtlinie über Closing ins Backend-Failover, wobei die bedienenden Kopien weiterlaufen; sie kehrt selbstständig zurück, sobald sie aktualisiert sind.

Opfield ordnet Daemon-Updates von Lease-Teilnehmern selbst. Ein Update eines Docker-Daemons oder Relays, der bei einer Richtlinie im Lease-Modus abstimmt oder einen Slot halten kann, wartet, bis die anderen Abstimmenden und Kandidaten dieser Richtlinie wieder online sind, ihren Lease-Zustand gemeldet haben und wieder abstimmen. Währenddessen wird der Node als in Aktualisierung angezeigt, und die API meldet updatePhase: waiting_for_lease_peers mit den Partnern in updateWaitingFor. Gemeinsam angeforderte Updates laufen zuerst für Bereitschaftsplatzierungen, dann für Inhaber; Nodes, die keine Richtlinie teilen, werden parallel aktualisiert. Ein Partner, der sich 3 Minuten nach seinem Neustart nicht stabilisiert hat, blockiert nicht mehr, und ein Update, das 30 Minuten gewartet hat, schlägt mit einem Fehler fehl, der die Partner nennt.

Das Warten ist vor allem einmal relevant. Der erste Neustart eines von 2.10 aktualisierten Nodes enthält sich etwa 33 Sekunden der Stimme, ebenso jeder Start nach einem Neustart des Hosts oder mit frischem Zustand, sodass ein Update dann bis zu etwa einer Minute pro Partner auf seine Lease-Partner warten kann. Spätere Neustarts im selben Boot stimmen sofort weiter ab, und ein Inhaber, dessen Daemon neu startet, behält seinen Slot und bedient weiter: Seine Lease ist bis zu seiner Watchdog-Frist gültig, sodass seine Kopie wieder Datenverkehr annimmt, sobald sich der neue Daemon-Prozess registriert, und er erneuert sie bis 2 Sekunden vor dieser Frist weiter. Siehe Neustarts des Docker-Daemons.

Nach dem Update auf 2.11 wird eine Bereitschaftsplatzierung mit einem Binding an eine verwaltete Datenbank einmal erneut vorbereitet, weil Bereitschaftsplatzierungen jetzt die Datenbank-Verbindungseinstellungen erfassen, mit denen sie vorbereitet wurden.

Ein Node, der auf ein beliebiges Release seit 2.10.0 zurückgesetzt wird, startet weiterhin: Daemons halten ihre Zustandsdateien in einer Form, die ältere Releases lesen können.

Lease-Details in der API

get von manage_docker_availability und die Availability-API liefern ein Objekt lease:

• mode: legacy, bootstrapping, lease oder closing;
• reason: warum die Richtlinie im Backend-Failover ist oder warum der Lease-Modus gerade unmöglich ist, mit code, message, zu behebenden nodeIds oder relayIds und since, solange eine Richtlinie im Lease-Modus die 2 Minuten abwartet;
• excludedNodes: [{ nodeId, reason }];
• retainedHolders während closing: [{ slot, holderNodeId, confirmed }], die Kopien, die während des Schließens weiterlaufen;
• holders: pro Slot holderNodeId, placementId und holderSince;
• voters und witness, mit warning auf witness_near_candidate, no_eligible_witness oder configured_witness_unavailable gesetzt;
• voterMargin: voters, reachable, required und margin. Ist margin 0 oder kleiner, stoppt der Verlust eines weiteren Abstimmenden das autonome Failover.

Grenzen

• Das Failover der Datenebene schützt die Platzierungen des Workloads, nicht Opfield, nginx, Datenbank-Engines, Registry-Speicher oder gemeinsam genutzte Volumes.
• Eine Kopie, die ihre Lease nicht erneuern kann, stoppt. Mit ausgeschaltetem Allow available mode stoppt eine Netzwerkpartition den Workload daher auf der Seite ohne Mehrheit.
• Geplante Wechsel haben für ein Einzelexemplar im Failover-Modus eine kurze Lücke, wie oben beschrieben.