Node-Updates und Offline-Verhalten

Angewendete Dienste laufen auf einem Node weiter, während er aktualisiert wird oder offline ist; was stoppt, ist die Fähigkeit von Opfield, sie in Echtzeit zu ändern oder zu beobachten. Behalten Sie die dauerhafte Node-Identität bei, stellen Sie die authentifizierte Sitzung wieder her und prüfen Sie, dass jede abhängige Ressource abgeglichen wurde, nicht nur, dass der Status wieder grün ist.

Ein Update oder eine Wiederherstellung ist abgeschlossen bei frischer Verbindung, frischem Inventar, frischen Metriken und Fähigkeiten, funktionierenden repräsentativen Workload-Pfaden und ohne ungeklärte unterbrochene Operation.

Details für Betreiber: Update und erneuter Verbindungsaufbau

Prüfen Sie die Kompatibilität, bevor Sie Opfield, Relay und Daemons aktualisieren. Wenden Sie signierte Daemon-Updates über den Node-Lebenszyklus an und prüfen Sie erneuten Verbindungsaufbau, Version, Inventar, Logs, Zustand und verwaltete Bindings.

Geht ein Node offline, laufen seine Workloads lokal weiter, und Opfield-Änderungen an ihm sind deaktiviert. Diagnostizieren Sie Verfügbarkeit des Hosts, Daemon-Dienst, Systemzeit, Zertifikatsidentität, DNS und ausgehenden Relay-Zugriff. Vermeiden Sie es, den Node-Eintrag zu löschen, solange sich der alte Daemon erneut verbinden könnte.

Prüfen Sie nach der Wiederherstellung den Abgleich des Sollzustands für Routen, Workloads, Datenbank-Bindings, Zertifikatsmaterial und Monitoring. Eine grüne Verbindung allein beweist nicht, dass sich jede abhängige Ressource erholt hat.

Absturzsicherer Update-Starter

In 2.10 erhielten Docker, nginx, Monitoring und der Relay-Supervisor einen separaten Starter (Launcher). Wird ein Update vom Starter verwaltet, bewahrt es die vorherige Binärdatei und ein Journal auf der Festplatte. Der Kandidat muss lokale Bereitschaft melden und ein Stabilitätsfenster von 30 Sekunden bestehen, bevor er übernommen wird; fehlgeschlagene Kandidaten können zurückgesetzt werden. Der Dienstmanager überwacht den Starter, der den Daemon-Prozess überwacht.

Lokale Bereitschaft beweist weder Relay-Konnektivität noch den Zustand der Anwendung. Prüfen Sie nach dem Update weiterhin Version, erneuten Verbindungsaufbau, Node-Fähigkeiten und eine echte Operation. Ist der Bootstrap des Starters nicht verfügbar und läuft der Daemon direkt, steht der Rollback-Schutz des Starters nicht zur Verfügung.

Ein Kandidaten-Daemon, der Bereitschaft der Steuerungsverbindung meldet, muss Opfield außerdem innerhalb von 3 Minuten nach der lokalen Bereitschaft erreichen, sonst stellt der Starter den vorherigen Daemon wieder her. Opfield wartet entsprechend lange (4,5 Minuten), bevor es das Update als fehlgeschlagen wertet; ein Rollback erscheint dann als „The daemon came back on … instead of …“.

Der Starter aktualisiert sich auch selbst. Sobald ein aktualisierter Daemon übernommen und verbunden ist, ersetzt sich der Starter an Ort und Stelle durch den Starter dieses Releases und behält dabei seinen Prozess, den laufenden Daemon und die lauschenden Sockets, die er hält. Das tut er nur unter systemd oder OpenRC; im manuellen Modus startet der neue Starter beim nächsten manuellen Neustart. Die Node-Details zeigen die Version des Starters.

Verbindungen während eines Daemon-Updates

Auf einem Docker- oder nginx-Node, dessen Daemon die Live-Übergabe unterstützt (ab 2.11.4), erhält ein Update Relay-Stream-Sitzungen und Container-Links zu einem Ziel auf demselben Node: Der neue Daemon-Prozess übernimmt sie nach einer Pause von ein bis zwei Sekunden. Rohe Streams älterer Gegenstellen, PostgreSQL-Verbindungen, bei denen der Daemon TLS öffnet, Registry-Pulls und -Pushes sowie Backup-Läufe werden weiterhin getrennt. Das erste Update auf einen Daemon mit Live-Übergabe und ein Rollback darunter trennen offene Verbindungen einmal. Ein Node, dessen Starter vor 2.11.4 gestartet wurde, startet bei seinem nächsten Daemon-Update einmal seinen gesamten Dienst neu, was ebenfalls offene Verbindungen einmal trennt; spätere Updates erhalten sie.

Die Node-Seite gibt an, was ein Update jetzt bewirken würde: The update keeps connections, N connections will be cut oder Open connections are cut once. Last Update unter Runtime zeigt, was das letzte Update erhalten und getrennt hat.

Zertifikatsverlängerung

Opfield verlängert seine internen Zertifikate im laufenden Betrieb ohne Neustart und erfasst jede Verlängerung im Audit-Log:

Zertifikat	Gültigkeit	Verlängerung
Opfield-Listener sowie Dienst- und Client-Zertifikate des lokalen Relays	365 Tage	Stündlich geprüft und 30 Tage vor Ablauf verlängert; bestehende Verbindungen behalten das alte Zertifikat, bis sie sich neu verbinden. Solange ungenutzte Registrierungstokens existieren, wartet die Verlängerung bis zu den letzten 7 Tagen, weil Installationsbefehle den Fingerabdruck des Opfield-Zertifikats festlegen; vor einer Verlängerung generierte Befehle müssen dann neu generiert werden
Ein über GRPC_TLS_CERT bereitgestelltes Zertifikat	Von Ihnen festgelegt	Wird von Opfield nie verlängert; täglich wird eine Warnung protokolliert
Serverzertifikate entfernter Relays	365 Tage	Stündlich geprüft, solange der Relay-Supervisor verbunden ist, und 60 Tage vor Ablauf verlängert, höchstens einmal täglich
Client-Zertifikate der Daemons auf jedem Node	365 Tage	Stündlich vom Daemon geprüft und verlängert, sobald ein Drittel der Laufzeit verbleibt, etwa 120 Tage vor Ablauf. Ein fehlgeschlagener Versuch wird nach 5, 10, 20 und 40 Minuten und danach stündlich wiederholt. Der Daemon verbindet sich neu, um das neue Zertifikat vorzulegen
Registry-Proxy-Zertifikat auf Docker Nodes	2 Jahre	Beim Start des Daemons und alle 12 Stunden geprüft und von derselben CA neu ausgestellt, sobald ein Drittel der Laufzeit oder 30 Tage verbleiben; wird ohne Neustart ausgeliefert
TLS-Zertifikate von verwaltetem Speicher und verwalteten Datenbanken	Von Opfield festgelegt	Stündlich geprüft und an Ort und Stelle ohne Neustart neu geladen; siehe verwalteter Speicher und verwaltete Datenbanken

Ein Node muss verbunden bleiben, um sein Zertifikat zu verlängern. Da die Verlängerung Monate vor dem Ablauf beginnt, bedeutet ein Node-Zertifikat mit weniger als 30 verbleibenden Tagen, dass die Verlängerung fehlschlägt: Opfield löst bei 30 Tagen einen Warnalarm und bei 7 Tagen einen kritischen Alarm aus. Stellen Sie sicher, dass der Node Opfield erreichen kann und einen aktuellen Daemon ausführt; nach Ablauf seines Zertifikats muss ein Node neu registriert werden.

Die System-CAs, die diese Zertifikate ausstellen, sind 10 Jahre gültig und haben noch keine automatische Erneuerung. Von ihnen ausgestellte Zertifikate enden mit der CA, und Opfield alarmiert 730, 365, 180, 60, 30 und 7 Tage vor dem Ablauf einer System-CA. Siehe Interne PKI.

Registrierungstokens

Registrierungstokens sind einmalig verwendbar und laufen nach 7 Tagen ab. Für einen Node, der noch aussteht, stellt New enrollment token einen Ersatz-Installationsbefehl aus. Ein registrierter Node kann nicht an Ort und Stelle neu registriert werden; nur Relay-Mitglieder unterstützen eine erneute Registrierung. Siehe Relay und Relay-Pool.

Daemon-Updates

Aktualisieren Sie einen Node auf seiner Detailseite mit Update oder mehrere gleichzeitig mit Nodes > Update Nodes. Der Dialog listet jeden Node auf, dessen Daemon älter ist als das neueste Release seines Typs, und aktualisiert die ausgewählten gemeinsam. Relay-Nodes werden nicht aufgeführt: Sie werden mit dem Relay-Pool aktualisiert (Settings > General > Update Relay Pool), der sie einzeln leert. Opfield verweigert ein Daemon-Update für einen Node, der nicht verbunden ist, für einen Relay-Node und für einen Node, der dieses oder ein neueres Release bereits ausführt.

• Update-Zustand. Ein Node behält seinen Update-Zustand in der Liste und auf seiner Seite, ohne Update-Abzeichen und ohne kurzzeitige Offline-Anzeige während des Updates. Ein fehlgeschlagenes, zurückgesetztes oder abgelaufenes Update behält seinen Grund am Node, angezeigt unter Update Available, und ein Node, der mit seiner alten Version zurückkommt, wird sofort als solcher gemeldet.
• Lease-Partner. Nodes, die sich eine Availability-Richtlinie im Lease-Modus teilen, starten nacheinander neu; ein eingereihtes Update zeigt Queued mit dem, worauf es wartet. Siehe Updates und gemischte Versionen.
• Laufende Tasks. Ein Update wartet zuerst auf die langen Tasks, die auf dem Node laufen: Backup- und Wiederherstellungsläufe, Image-Builds, Docker-Migrationen, Image-Pulls und Container-Aktionen, Speicher-Kopieraufträge sowie Exporte und Importe von Container-Archiven. Nach 30 Minuten wird es trotzdem fortgesetzt, und der Node behält eine Warnung; Update now startet es nach einer Bestätigung sofort, da die laufenden Tasks fehlschlagen können.
• Opfield-Neustarts. Nach einem Neustart von Opfield während Node-Updates warten laufende Updates, bis sich ihre Nodes neu verbinden, und werden rechtzeitig abgeschlossen oder schlagen fehl, und eingereihte Updates werden wieder aufgenommen. Opfield sucht beim Start und nach einem Opfield-Update nach Daemon-Updates.
• Unterbrochene Verbindungen. Ein Daemon, der ein Selbst-Update vorbereitet hat, startet auch dann in dieses neu, wenn seine Verbindung zu Opfield während des Downloads abgebrochen ist.
• Installationsprogramme. Einrichtungsbefehle für Nodes und Relays stammen aus dem eigenen Release der laufenden Opfield-Installation und werden gegen die Prüfsummen dieses Releases geprüft, und Daemon-Installationsprogramme legen den neuesten Daemon der Release-Linie dieser Installation fest, sodass eine Opfield-Installation nie Installationsprogramme aus einer neueren Entwicklungslinie ausgibt.

Vor einem Update

1. Lesen Sie die Release Notes der Komponente und die Kompatibilitätsuntergrenze.
2. Bestätigen Sie, dass der Update-Kanal der Installation bewusst gewählt ist: Stable für Produktionsreleases oder Preview für ausdrücklich akzeptierte Pre-Releases.
3. Prüfen Sie, dass der Node online ist und keine konkurrierende Lebenszyklusoperation ausführt.
4. Halten Sie seine aktuelle Version, Fähigkeiten, aktiven Workloads und aktuellen Fehler fest.
5. Verwenden Sie für einen Relay-Pool das Relay-Pool-Update, das ein Mitglied nach dem anderen leert, aktualisiert und prüft.
6. Stellen Sie sicher, dass ein Operator den Host erreichen kann, falls die automatische Wiederherstellung fehlschlägt.

Opfield und Daemons prüfen signierte Update-Manifeste und Prüfsummen. Ersetzen Sie ein fehlgeschlagenes signiertes Update nicht durch eine unsignierte Binärdatei, die von einem anderen Host kopiert wurde.

Prüfung nach dem Update

Prüfen Sie nach dem Neustart des Daemons mehr als nur seine Version:

• authentifizierter erneuter Verbindungsaufbau und aktueller Zeitpunkt der letzten Meldung;
• vollständige Fähigkeitsmeldung;
• Aktualisierung von Inventar und Metriken;
• rollenspezifischer Dienstzustand;
• Abgleich ausstehender Tasks;
• Routen, Zertifikate, Workloads, Compose-Projekte und Datenbank-Bindings, die diesem Node gehören;
• erwartungsgemäß ausgelöste oder aufgehobene Alarme.

Offline-Verhalten nach Zuständigkeit

Eine unterbrochene Steuerungsverbindung stoppt Host-Dienste nicht automatisch. nginx, Container, verwaltete Datenbanken und andere bereits angewendete Dienste können aus dem lokalen Zustand weiterlaufen. Opfield verhindert Änderungen, die einen aktiven Zuständigen erfordern, und zeigt zwischengespeichertes Inventar nur zur Diagnose.

Datenbank-Bindings können während eines Neustarts nur der Opfield-Anwendung über einen fehlerfreien Relay- und Datenbankpfad weiterlaufen; Relays lassen neue Verbindungen für die Dauer der Richtlinien-Lease anhand ihrer letzten signierten Richtlinie weiter zu. Ein Relay-Ausfall ist etwas anderes: Er unterbricht neue Zulassungen privater Verbindungen und den Steuerungsverkehr verwalteter Nodes, selbst wenn lokale Workloads weiterlaufen. Kehrt Opfield zurück, verbinden sich Daemons innerhalb von 15 Sekunden neu.

Neustarts des Docker-Daemons

Ein Neustart oder Update des Docker-Daemons stoppt keine Container und unterbricht den Datenverkehr zu ihnen nur kurz. Ein Update mit Live-Übergabe erhält offene Verbindungen, wie unter Verbindungen während eines Daemon-Updates beschrieben; die folgenden Punkte gelten für Neustarts, die keine Verbindungen übergeben:

• Der Daemon verbindet sich zuerst mit Opfield und registriert seine Relay-Endpunkte innerhalb von etwa einer Sekunde erneut, sobald die frischen Freigaben von Opfield eintreffen. Secure Runtime (gVisor) wird danach im Hintergrund erneut geprüft. Bis das abgeschlossen ist, meldet der Node das letzte für dieselbe runsc-Version geprüfte Ergebnis oder beim ersten Start einer neuen Version einen unbekannten Status mit dem Grund verification_pending, sodass das Erstellen sicherer Workloads nicht schwankt.
• Ein geordneter Neustart oder ein Update wird angekündigt. Bevor er stoppt, teilt der Daemon den Relays mit, dass seine Endpunkte neu starten, schließt laufende Secure-Link-Anfragen ab (höchstens 1 Sekunde) und schließt Verbindungen, die zwischen Anfragen im Leerlauf sind. Die Relays behalten seine Registrierungen bis zu 15 Sekunden, bis sich der nächste Prozess registriert, und Ingress Nodes halten neue Verbindungen zu ihm bis zu 8 Sekunden zurück, statt sie fehlschlagen zu lassen, sodass ein Neustart als Verzögerung von wenigen Sekunden statt als Fehler erscheint. Ein Availability-Replikat mit einem weiteren bedienenden Replikat wartet nicht: Seine Anfragen gehen sofort an das andere Replikat. Dies erfordert Relays und nginx-Daemons dieses Releases; mit älteren Relays hält der Ingress Node neue Verbindungen weiterhin bis zu 3 Sekunden zurück.
• Der Inhaber einer Availability-Lease bedient über einen Neustart im selben Boot hinweg weiter: Seine Lease ist noch gültig, daher nimmt seine Kopie wieder Datenverkehr an, sobald sich der neue Prozess registriert.
• Ein Daemon, der abstürzt oder dessen Host nicht mehr erreichbar ist, wird nicht zurückgehalten: Die Relays verwerfen seine Verbindung innerhalb von etwa 3,5 Sekunden, und Anfragen wechseln zu anderen Platzierungen, sofern vorhanden.
• Nach einem Neustart des Hosts wird jeder Secure Link einzeln wiederhergestellt: Ein Link, dessen Ziel nicht zurückgekehrt ist, bleibt ungebunden, bis sein Ziel läuft, und blockiert die anderen nicht.
• Eine hängende Docker Engine (dockerd) stoppt den Datenverkehr zu laufenden Containern und Deployments nicht: Secure-Link-, verwaltete Datenbank- und Speicherverbindungen warten höchstens 300 Millisekunden auf sie und verwenden dann die letzte von ihr genannte Adresse, Links bleiben gebunden, wenn sie auf eine Synchronisation nicht antwortet, und Deployment-Router verwenden weder das DNS von Docker noch ein Access-Log. Eine Anwendung, die jede Anfrage in ihre Containerausgabe schreibt, kann dennoch ins Stocken geraten, solange dockerd eingefroren ist.
• Ein Storage- oder Datenbank-Node startet auch dann, wenn einer seiner verwalteten Container fehlt; dieser Speicher bzw. diese Datenbank wird als nicht laufend angezeigt, statt den Node offline zu nehmen.
• Warnungen jeder Daemon-Komponente, etwa abgelehnte Link-Verbindungen, erreichen die Logs des Nodes in Opfield, nicht nur das Journal des Hosts.

Nodes, die bei Leases für das Failover der Datenebene abstimmen oder sie halten können, werden pro Availability-Richtlinie einzeln aktualisiert: Ein Daemon-Update eines solchen Nodes kann auf seine Lease-Partner warten, und der Node wird währenddessen als in Aktualisierung angezeigt. Siehe Updates und gemischte Versionen. Auf Docker Nodes, die Leases halten können, läuft der Lease-Watchdog als eigener Dienst, opfield-lease-watchdog, und aktualisiert sich selbst.

Ein Node, der auf ein beliebiges Daemon-Release seit 2.10.0 zurückgesetzt wurde, startet weiterhin: Daemons halten neben ihren eigenen Zustandsdateien diejenigen bereit, die ein älteres Release liest. Daemons ersetzen ihre Zustandsdateien dauerhaft (schreiben, flushen, umbenennen), sodass ein kill -9 oder ein Stromausfall nie eine unvollständige Datei hinterlässt.

Docker-Daemon 2.11.1 und der gemeinsame Connector

Der Docker-Daemon 2.11.1 bedient jedes Datenbank-Binding, jede Speicherverbindung und jeden Container-Link des Nodes über einen gemeinsamen Secure-Link-Connector, ohne Container pro Verbindung und ohne Listener auf dem Host; siehe Gemeinsamer Connector und Verbindungsnetzwerke.

• Datenbank-Bindings wechseln nach dem Update zum Connector: Opfield erstellt jeden gebundenen Workload einmal neu, einen nach dem anderen auf jedem Node, den nächsten, sobald der vorherige fehlerfrei läuft. Ein Deployment wird ohne Ausfallzeit per Blue/Green ausgerollt; ein eigenständiger Container oder ein Compose-Dienst startet einmal neu.
• Speicherverbindungen, die vor 2.11.1 erstellt wurden, wechseln nach dem Update zum Connector, und Opfield erstellt jeden verbundenen Workload einmal neu, direkt nachdem seine Verbindung gewechselt hat. Auf 2.11.1 erstellte Verbindungen benötigen keine Neuerstellung.
• Ein Rollback des Docker-Daemons auf 2.11.0 schaltet die Verbindungen automatisch zurück, wieder mit einer Neuerstellung pro Workload. Höchstens vier Workloads pro Node werden gleichzeitig neu erstellt, das Limit des Daemons für gleichzeitige Befehle, daher verbinden sich auf einem Node mit vielen verbundenen Deployments die späteren etwas später neu.
• Connector-Updates erhalten offene Verbindungen: Ab 2.11.4 übergibt der vorherige Connector sie an den neuen. Ein Connector von vor 2.11.4 behält sie bis zu einer Stunde und schließt sie dann einmal; Clients verbinden sich mit dem neuen Connector neu.
• Container-Links benötigen den Docker-Daemon 2.11.1 auf beiden Nodes und zeigen bis dahin update required.
• Adressbereich der Verbindungsnetzwerke: Neue Verbindungsnetzwerke erhalten jeweils ein /26 aus docker.secure_links.subnet_pool in /etc/docker-daemon/config.yaml, standardmäßig 10.213.x.x (ein /16). Der Daemon überspringt Subnetze, die bereits von Docker-Netzwerken oder den Routen des Hosts belegt sind; ändern Sie den Bereich, wenn er sich mit einem Netzwerk überschneidet, das der Node über seine Standardroute erreicht, und starten Sie dann den Daemon neu.

Neustarts des nginx-Daemons

Ein Neustart oder Update des nginx-Daemons auf einem Ingress Node schließt seine Secure-Link-Sockets nicht. Der Starter, der den Daemon überwacht, hält eine Kopie jedes lauschenden Sockets und übergibt sie an den nächsten Daemon-Prozess; mit systemd hält er sie außerdem im File-Descriptor-Store der Unit, sodass sie systemctl restart überstehen. Solange kein Daemon-Prozess läuft, warten neue Verbindungen in der Warteschlange des Sockets und werden vom nächsten Prozess bedient. Beim Herunterfahren nimmt der Daemon keine Verbindungen mehr an, schließt laufende Anfragen für bis zu 1,5 Sekunden ab und schließt Verbindungen, die zwischen Anfragen im Leerlauf sind, sodass nginx sich in die Warteschlange neu verbindet.

• Das Update von 2.10 ist einmal sichtbar. Der alte Daemon übergibt beim Stoppen nichts, daher unterbricht dieses eine Update Secure-Link-Routen über den Node für etwa eine Sekunde. Ab dann erhalten Neustarts und Updates die Sockets, einschließlich des Neustarts, bei dem der Starter seine neue Version ausprobiert: Solange noch ein älterer Starter läuft, der keine Sockets hält, legt der Daemon seine Listener selbst im File-Descriptor-Store von systemd ab.
• Anfragen, die länger als die Auslaufzeit von 1,5 Sekunden laufen, und langlebige Streams wie WebSocket oder Server-Sent Events werden bei einem Neustart ohne Verbindungsübergabe getrennt; ein Daemon-Update mit Live-Übergabe erhält sie.
• Auf Nodes ohne systemd (OpenRC) decken die Starter Neustarts für Updates und nach einem Absturz ab, einen Neustart des Dienstes jedoch nicht. Routen, deren Konfiguration noch einen Loopback-TCP-Listener statt eines Secure-Link-Sockets verwendet, verweigern während eines Neustarts wie bisher Verbindungen.

Secure-Link-Sockets werden unter einem temporären Namen mit ihrem endgültigen Eigentümer und Modus erstellt und dann umbenannt, sodass nginx nie einen fehlenden Socket oder einen Socket findet, den es nicht verwenden darf; bevor eine Konfiguration geladen wird, lauscht bereits jeder Socket, auf den sie verweist.

Startet Opfield, bevor sich ein Ingress Node neu verbunden hat, werden Änderungen für diesen Node, etwa nach einem Vorlagen-Update neu geschriebene Routen, der Synchronisation beim erneuten Verbindungsaufbau des Nodes überlassen, statt fehlzuschlagen.

Ablauf der Wiederherstellung

1. Stellen Sie Stromversorgung und Netzwerkerreichbarkeit des Hosts wieder her.
2. Prüfen Sie Systemzeit, DNS und die Konnektivität zum Relay-Endpunkt.
3. Prüfen Sie die systemd-Unit des Daemons und begrenzte Logs.
4. Bestätigen Sie, dass Daemon-Zertifikat und Node-Identität nicht ersetzt wurden.
5. Warten Sie auf den erneuten Verbindungsaufbau und frisches Inventar.
6. Prüfen Sie fehlgeschlagene oder unterbrochene Operationen, bevor Sie sie wiederholen.
7. Prüfen Sie jede abhängige Ressourcenfamilie, die dem Node gehört.

Löschen Sie einen Node, der offline ist, nicht nur, um eine Warnung zu beseitigen. Das Löschen ändert die dauerhafte Zuständigkeit und kann dazu führen, dass sich der noch laufende alte Daemon nicht mehr sicher abgleichen kann.

Unterbrochene Operationen

Ein Übergang in den Offline-Zustand kann eine Operation hinterlassen, deren Absicht angenommen, deren endgültiges Ergebnis auf dem Host aber nicht bestätigt wurde. Nach dem erneuten Verbindungsaufbau gleicht Opfield unterstützte unterbrochene Zustände anhand des Daemons und des Ressourceninventars ab. Prüfen Sie die Operation, bevor Sie eine weitere Aktion starten: Ein blindes Wiederholen eines Erstellens, Updates, einer Migration oder eines Löschens kann mit Arbeit kollidieren, die auf dem Host bereits abgeschlossen wurde.

Vergleichen Sie den Operationseintrag mit der tatsächlichen Eigentümerressource. Ein Container kann laufen, auch wenn der letzte Fortschritt in der Oberfläche unterbrochen wurde; ein Compose-Projekt kann eine Revision angewendet haben, ohne seine endgültige Bestätigung zurückzugeben; ein Update kann den Daemon neu gestartet haben, bevor die Steuerungssitzung zurückkam. Verwenden Sie die aktualisierte Momentaufnahme und den rollenspezifischen Zustand als Beleg und wiederholen Sie dann nur die unterstützte Fortsetzungs- oder Wiederherstellungsaktion.

Force Cancel für einen Task stoppt oder verwirft Arbeit der Control Plane, wo dies unterstützt wird; es garantiert nicht, dass jeder Unterprozess auf dem Host oder jede bereits angewendete Laufzeitänderung rückgängig gemacht wurde. Prüfen Sie die Ressource nach dem Abbruch und führen Sie eine ausdrückliche Bereinigung durch, wenn die Operation meldet, dass sie erforderlich ist.

Ersetzen oder Wiederherstellen

Stellen Sie die bestehende Identität wieder her, wenn der Host und sein persistentes Daemon-Material noch existieren. Ersetzen Sie den Node nur, wenn der Host bewusst neu aufgebaut wird oder seine Identität nicht wiederhergestellt werden kann. Erfassen Sie vor dem Ersetzen Routen, Workloads, Datenbankinstanzen, Build-Zuweisungen, Zertifikate, Volumes und Relay-Zuweisungen, die dem alten Node gehören, und verschieben oder beenden Sie sie über ihren unterstützten Lebenszyklus.

Betreiben Sie niemals dieselbe Daemon-Identität gleichzeitig auf einem alten und einem Ersatz-Host. Wenn der ursprüngliche Host zurückkehren könnte, deaktivieren oder deinstallieren Sie ihn, bevor Sie den Ersatz registrieren. Eine doppelte Identität kann widersprüchliche Inventar- und Operationsbestätigungen erzeugen, selbst wenn die beiden Hosts unterschiedliche Adressen haben.

Geplanter Offline-Test

Bevor Sie sich in der Produktion auf einen Node verlassen, führen Sie eine begrenzte Wiederherstellungsübung durch: Starten Sie den Daemon neu, bestätigen Sie, dass sich lokale Dienste wie dokumentiert verhalten, warten Sie auf den erneuten Verbindungsaufbau und prüfen Sie frisches Inventar sowie eine repräsentative abhängige Ressource. Testen Sie bei Relay- und Datenbankpfaden neue wie bestehende Verbindungen. Halten Sie die beobachtete Wiederherstellungszeit und den manuellen Zugangsweg fest, der benötigt wird, wenn der automatische erneute Verbindungsaufbau fehlschlägt.