Relay und Relay-Pool

Relay ist der authentifizierte Transport, der Opfield mit verwalteten Nodes verbindet und unterstützten privaten Datenverkehr wie Secure Links transportiert. Ein Relay-Pool fügt Mitglieder hinzu, damit Transportkapazität und Verfügbarkeit nicht von einer einzigen Fehlerdomäne abhängen. Er ist weder ein universelles VPN noch ein Load Balancer für Anwendungen.

Wie viele Relays

Betreiben Sie mindestens zwei Relays auf anderen Hosts als dem Opfield-Host, in unterschiedlichen Fehlerdomänen: ein anderer Host, eine andere Stromversorgung und ein anderer Netzwerkpfad. Das ist die Regel für jede Produktionsinstallation und für jede Availability-Konfiguration: Docker Availability und Datenbanken und Speicher auf mehreren Servern. Zwei Relays hinter demselben Host, derselben Stromversorgung, derselben Firewall oder derselben Route sind eine Fehlerdomäne und zählen als ein Relay.

Wenn ein Relay ausfällt:

• Die Datenströme, die es transportiert hat, wechseln ohne Abbruch zu einem anderen Relay. Relay-Datenströme sind fortsetzbar: Ein Datenstrom wird auf einem anderen Relay fortgesetzt, und die Sockets der Anwendung und der Datenbank an beiden Enden bemerken den Wechsel nicht.
• Die Nodes, die es verwendet haben, verbinden sich selbstständig mit den anderen Relays neu.
• Die Mitglieds-Links von Availability-Workloads sind bereits auf jedem bereiten Relay registriert und bedienen daher weiter über die anderen.

Mit nur dem lokalen Relay hängen Secure Links, Datenbank- und Speicherverbindungen sowie das Failover der Datenebene vom Opfield-Host ab und stoppen mit ihm.

Der Netzwerkverantwortliche stellt Endpunkte bereit, die die Nodes erreichen können; Opfield übernimmt Registrierung, Zuweisung, Leeren und Updates.

Details für Betreiber: Topologie und Endpunkt

Das lokale Relay ist ein erforderlicher, langlebiger Dienst der Datenebene und der einzige öffentliche Inhaber von 9443/tcp. Es authentifiziert Sitzungen verwalteter Nodes und unterstützten privaten Tunnelverkehr.

Ein Relay-Pool fügt Supervisor/Worker-Mitglieder und eine Platzierung hinzu, die Fehlerdomänen berücksichtigt. Operatoren prüfen getrennte physische Domänen und kündigen erreichbare Worker-Endpunkte an; Opfield verteilt Zuweisungen automatisch neu, und das Relay-Pool-Update leert, aktualisiert und prüft ein Mitglied nach dem anderen.

Opfield erstellt keine Firewall-Regeln, keine NAT-Überwindung und kein universelles Overlay-Netzwerk. Jeder zugewiesene verwaltete Host muss den Datenendpunkt seines Workers erreichen. Bewahren Sie bei einem Relay-Vorfall das Identitäts-Volume und führen Sie keinen alternativen, nicht authentifizierten Pfad ein.

Topologie

Jede Installation hat einen lokalen Relay-Dienst, der Opfield zugeordnet ist. Zusätzliche Relay-Nodes betreiben einen Supervisor, der sich über den Standardablauf für Node-Identitäten registriert und einen Relay-Worker verwaltet. Opfield verteilt signierte Richtlinien und Workload-Zuweisungen; verwaltete Nodes bauen authentifizierte ausgehende Verbindungen zu ihren zugewiesenen Relay-Endpunkten auf.

Relay ist Transport, nicht Zuständigkeit für Workloads. Ingress-, Docker-, Datenbank-, Monitoring- und Builder-Daemons bleiben für ihre Host-Operationen zuständig. Relay transportiert authentifizierte Steuerungs- und unterstützte private Datenströme, ohne zu einem allgemeinen Netzwerktunnel zu werden.

Einen Relay-Node hinzufügen

1. Bereiten Sie einen dedizierten Host in der vorgesehenen physischen oder Netzwerk-Fehlerdomäne vor.
2. Stellen Sie sicher, dass seine angekündigte Adresse für die beteiligten Nodes über TCP 9443 erreichbar ist.
3. Öffnen Sie Settings → Relay und wählen Sie Add relay node, oder erstellen Sie ein Relay unter Nodes.
4. Geben Sie den Anzeigenamen und die erreichbare Relay Address ein.
5. Führen Sie den generierten einmaligen Installationsbefehl auf dem Zielhost aus.
6. Warten Sie, bis sich der Registrierungsdialog schließt, nachdem dieser Node online gegangen ist.
7. Bestätigen Sie, dass die Relay-Instanz bereit meldet, bevor Sie Datenverkehr zuweisen oder neu verteilen.

Ein ausstehender Relay-Node ist keine Pool-Kapazität. Betrachten Sie einen erstellten Datenbankeintrag oder einen installierten Supervisor erst als bereit, wenn Opfield den Worker-Endpunkt und den Zustand geprüft hat.

Das Installationsprogramm wartet, bis der Supervisor registriert und mit Opfield verbunden ist, und endet andernfalls mit dem Grund. Ein physischer Host trägt ein Relay des Pools: Das Registrieren eines neuen Relays auf einem Host, der bereits eines hat, wird mit dem Namen dieses Relays abgelehnt, und nichts wird registriert; registrieren Sie dieses Relay neu oder entfernen Sie es zuerst. Um den Benutzer eines registrierten Relays zu ändern, führen Sie dessen Installationsprogramm erneut ohne --token und mit OPFIELD_RELAY_RUN_USER aus: Es behält seine Identität und übernimmt Opfield-Adresse, Zertifikats-Pin, angekündigte Adresse und Port aus seiner Konfiguration. Siehe Einen Daemon ohne Root ausführen.

Platzierung und Zuweisung

Platzieren Sie jedes Mitglied in einer eigenen Fehlerdomäne; siehe Wie viele Relays. Bestätigen Sie, dass jeder verwaltete Host jedes Relay erreichen kann, das ihm zugewiesen werden könnte. Die Streuung der Zuweisung steuert, wie viele bereite Relays neue Workload-Verbindungen erhalten; eine größere Streuung verbessert die Redundanz, verbraucht aber zusätzliche Verbindungen und Arbeitsspeicher.

Nächstgelegene Relays zuerst

Daemons messen die Umlaufzeit zu jedem Relay, das sie erreichen können, und melden sie an Opfield. Für jeden Endpunkt addiert Opfield die Umlaufzeit vom Node des Endpunkts zur durchschnittlichen Umlaufzeit der Nodes, die sich mit ihm verbinden, und macht die nächstgelegenen Relays zu primären; die übrigen Plätze der Streuung gehen an Bereitschafts-Relays in anderen Fehlerdomänen. Relays, die höchstens etwa 20 % oder 3 ms vom nächstgelegenen entfernt sind, teilen sich die primäre Rolle, sodass sich Relays in einem Rechenzentrum die Last teilen. Primäre Relays wechseln nur, wenn ein anderes Relay deutlich näher ist, um mindestens 30 % und 5 ms, sodass Schwankungen der Umlaufzeit nie Datenverkehr verschieben. Solange ein Node keine Messungen gemeldet hat, verwendet die Platzierung wie bisher einen stabilen Hash des Endpunkts.

Availability-Mitglieder und der Opfield-Host

Zusätzlich zur Streuung gelten zwei Regeln:

• Die Secure Links von Platzierungen der Workload Availability (Mitglieds-Links) liegen auf jedem bereiten Relay, das das Failover der Datenebene unterstützt (availability_lease_v2), unabhängig von der Streuung. Bereitschaftsplatzierungen bleiben dort ebenfalls registriert, nehmen aber keinen Datenverkehr an, bis ihr Node den Workload hält, sodass der neue Inhaber nach einer Übernahme bereits über jedes Relay erreichbar ist. Ein neuer Mitglieds-Link startet sofort auf diesen Relays.
• Jeder andere Secure Link behält seine Streuung, umfasst aber mindestens ein Relay, das nicht auf dem Opfield-Host läuft, sobald seine Nodes ein solches Relay als erreichbar gemessen haben. Ein Link, den nur das lokale Relay transportiert, stoppt mit dem Opfield-Host. Können die Nodes eines Links kein Relay außerhalb des Opfield-Hosts erreichen, bleibt der Link dort, wo er funktioniert, und Settings → Relay zeigt eine Warnung: „No relay off the Opfield host is reachable from <node>: traffic of this link depends on the Opfield host.“ Der Pool bleibt fehlerfrei; die Warnung ist kein Alarm.

Rechnen Sie nach einem Update auf ein Release mit diesen Regeln mit einer automatischen Neuverteilung für jeden Link, dessen Platzierung sich ändert.

Die Neuverteilung erfolgt automatisch. Ändert sich die Relay-Kapazität oder die Workload-Streuung, startet Opfield eine Neuverteilung, nachdem die neue Platzierung 30 Sekunden stabil geblieben ist; bestehende Verbindungen laufen ohne Unterbrechung aus. Vor einem Wechsel prüfen die Daemons, die den Endpunkt verwenden, das neue Relay; eine Prüfung, die das Relay nur deshalb ablehnt, weil das Ziel ein Availability-Bereitschaftsziel ist, gilt als geprüft, und pro Daemon laufen höchstens 2 Prüfungen gleichzeitig. Die automatische Neuverteilung pausiert während eines Relay-Pool-Updates, Workloads wechseln aber weiterhin von geleerten Mitgliedern weg.

Der Pool bleibt im stabilen Zustand healthy. Opfield unterscheidet drei Arten von Fehlern bei der Neuverteilung:

• Vorübergehende Bedingungen, etwa ein ausgelasteter Daemon, ein nicht verbundener Node, ein neu startendes lokales Relay oder eine durch einen Opfield-Neustart unterbrochene Vorbereitung, zählen nicht als Fehler. Der Wechsel wird mit dem Hinweis „Deferred by a transient condition and retried automatically“ zurückgestellt und nach 30 Sekunden erneut versucht, wobei sich die Wartezeit bis auf 5 Minuten verdoppelt; der Pool wird nicht herabgestuft.
• Echte Fehler stufen den Pool herab und werden nach 5 Minuten automatisch wiederholt; Rebalance wiederholt sie sofort.
• Ein Workload, der während einer Neuverteilung entfernt wird, scheidet einfach aus; die anderen Wechsel werden fortgesetzt.

Relays unter Last

Ein Relay, dem Kapazität fehlt, etwa CPU, Arbeitsspeicher oder Dateideskriptoren, lehnt neue Tunnel ab, bevor es die bestehenden scheitern lassen würde. Datenbank- und Speicherverbindungen behalten einen reservierten Anteil und werden zuletzt abgelehnt. Lehnt ein Relay einen neuen Tunnel auf diese Weise ab, versuchen die Daemons für dieses Relay zuerst jedes andere verbundene Relay, anfangs für 30 Sekunden und bis zu 5 Minuten, solange es weiter ablehnt. Neue Verbindungen gehen an die anderen Relays; bereits offene Datenströme bleiben, wo sie sind. Ein ablehnendes Relay, das als einziges übrig ist, erhält weiterhin neue Verbindungen mit begrenzter Rate, sodass es sie wieder annimmt, sobald es zulässt.

Die Daemon-Logs zeigen dies auf jedem Node, der das Relay verwendet: eine Warnung „relay refuses new tunnels under load“, jede Minute eine Erinnerung „still refuses“ und „admits again“, wenn es zurück ist. Es ist kein Eingreifen nötig; lehnt ein Relay häufig ab, geben Sie ihm mehr Ressourcen oder fügen Sie dem Pool ein weiteres Relay hinzu.

Relays, die die Nodes nicht erreichen können

Ein Relay kann mit Opfield verbunden und dennoch für die Nodes über seine angekündigte Adresse nicht erreichbar sein, zum Beispiel ohne Portweiterleitung oder hinter einer Firewall. Wenn die meisten Nodes, die ein Relay messen, seinen Relay-Port nicht erreichen können, erhält das Relay keine neuen Zuweisungen. Settings → Relay zeigt es als unreachable mit „Nodes cannot reach <address>; check the port forward and firewall. It gets no connections meanwhile.“, und das Benachrichtigungsereignis Relay Unreachable by Nodes (standardmäßig kritisch) wird ausgelöst. Beides wird aufgehoben, wenn die Nodes das Relay wieder erreichen. Unmittelbar nach einem Neustart eines Relays für ein Update melden die Nodes noch, was sie gemessen haben, während es nicht verfügbar war; solche Meldungen zählen erst, wenn sie den Neustart überdauern.

Relays ohne Opfield

Opfield signiert die Richtlinie, die es an jedes Relay sendet, mit einer Lease. Ein Relay lässt Verbindungen anhand seiner letzten signierten Richtlinie zu, bis diese Lease abläuft, sodass Secure Links und Datenbankverbindungen über ein entferntes Relay weiterhin neue Verbindungen aufbauen, während Opfield gestoppt, aktualisiert oder nicht erreichbar ist. Legen Sie die Lease unter Settings → Relay unter Policy lease fest: standardmäßig 72 Stunden, von 1 Stunde bis 7 Tage (168 Stunden).

Grant lifetime (1–224 Stunden, standardmäßig 4) legt fest, wie lange neu ausgestellte Endpunkt- und Verbindungsfreigaben gültig sind. Freigaben eines Mitglieds des Relay-Pools gelten immer mindestens ein Drittel länger als die Richtlinien-Lease (96 Stunden mit den Standardwerten), sodass einem Relay nie die Freigaben ausgehen, solange es noch anhand seiner letzten Richtlinie zulässt. Eine Rotation des Signaturschlüssels für Freigaben wartet, bis jedes Relay den neuen Schlüssel angewendet hat oder seine Lease abgelaufen ist. Ein Relay von 2.10 behält eine Lease von 15 Minuten und begrenzt seine Freigaben auf 48 Stunden, bis es aktualisiert wird.

Was Opfield benötigt: neue und geänderte Routen und Verbindungen, Widerrufe, neue Freigaben, Registrierung und jede Verwaltungsoperation. Das lokale Relay stoppt mit dem Opfield-Host, daher transportieren nur Relays auf anderen Hosts Datenverkehr, wenn der gesamte Host ausgefallen ist. Verbindet sich ein Relay nach einer Lücke neu, erfasst das Audit-Log die Zeit, in der es auf seiner letzten Richtlinie lief, als relay.instance.policy.stale_period mit from und to.

Kehren Opfield oder ein Relay zurück, erhält das Relay jede Richtlinienänderung, sobald es wieder verbunden ist, und Secure Links, die weiter bedienen, werden nicht abgebaut: Schlägt die Aktualisierung eines Links fehl, weil ein Node sich noch nicht neu verbunden hat, behält der Link seinen Relay-Endpunkt, und Opfield versucht es erneut.

Registrierungen und Änderungen an Freigaben

• Änderungen der Endpunkt-Generation. Wechselt ein Endpunkt zu einer neuen Generation, zum Beispiel nachdem das Zertifikat seines Ziels rotiert wurde oder sein Ziel auf einen anderen Node gewechselt ist, lässt das Relay die vorherige Registrierung samt ihren Tunneln weiter bedienen, bis sich die neue Generation registriert. Tunnel werden nur bei Routen- oder Zuweisungsänderungen und bei entfernten Endpunkten geschlossen.
• Freigaben vor der Richtlinie. Ein Daemon kann eine Freigabe erhalten, bevor sein Relay die Richtlinie hat, die sie enthält. Das Relay wartet dann bis zu 10 Sekunden auf diese Richtlinie, statt abzulehnen, und eine Registrierung, die ein älteres Relay mit „does not match policy“ abgelehnt hat, wird in den ersten 10 Sekunden alle 0,2–0,4 Sekunden wiederholt.
• Nicht erreichbare Daemons. Ein Relay verwirft die Verbindung eines Daemons, dessen Host Daten nicht innerhalb von etwa 2 Sekunden bestätigt, meist etwa 3,5 Sekunden nachdem der Host nicht mehr erreichbar war. Seine Registrierungen und Tunnel enden damit, und Availability-Routen wechseln zu anderen Platzierungen. Ein Daemon, der nur ausgelastet ist, behält seine Verbindung, weil sein Host noch bestätigt.
• Neu startende Daemons. Ein Docker-Daemon, der geordnet neu startet, kündigt dies an; das Relay behält seine Registrierungen bis zu 15 Sekunden, bis sich der nächste Prozess registriert, und beantwortet neue Tunnel währenddessen mit „target endpoint is restarting“, was Ingress Nodes zurückhalten, statt es fehlschlagen zu lassen. Siehe Neustarts des Docker-Daemons.

Widerruf von Routen

Wird eine Route oder Verbindung gelöscht oder ändert sich ihr Ziel, sendet Opfield an jedes Relay eine Richtlinie, die die alte Route widerruft. Ein Relay, das sie nicht innerhalb von 90 Sekunden angewendet hat, gilt für die widerrufenen Routen als veraltet: Opfield entfernt es aus deren Kandidaten, und der Daemon am Endpunkt verweigert diese Routen über dieses Relay, weil jeder Tunnel die Route trägt, für die er zugelassen wurde. Die anderen Routen des Relays funktionieren weiter. Unter Settings → Relay zeigt ein solches Relay „Revocation of N revoked routes pending“ und dann „Stale for revocation of N revoked routes“, bis es die erforderliche Richtlinienrevision anwendet.

Leeren, aktualisieren und entfernen

Drain verschiebt neue Tunnel zu anderen Mitgliedern. Bestehende Datenströme können bis zu 10 Minuten weiterlaufen und werden dann getrennt; Force disconnect beendet das Warten sofort. Resume gibt das Mitglied wieder in den Betrieb zurück. Drain, Resume und Force disconnect erfordern admin:system. Ein Mitglied, das nicht verbunden ist, kann geleert werden; das Leeren wird wirksam, wenn es sich neu verbindet. Resume und Force disconnect benötigen ein verbundenes Mitglied und werden andernfalls abgelehnt (409 RELAY_NOT_CONNECTED).

Ein Relay-Pool-Update führt das rollierende Verfahren selbst durch: Es leert jedes entfernte Mitglied, aktualisiert seinen Supervisor und dann über den aktualisierten Supervisor seinen Worker, prüft beide und gibt das Mitglied wieder in den Betrieb zurück, bevor es zum nächsten übergeht. Es wartet bis zu 30 Minuten darauf, dass langlebige Datenströme auf einem Mitglied enden, etwa Datenbank-Verbindungspools und WebSockets; danach trennt es die verbleibenden, erfasst eine erzwungene Trennung im Audit-Log und fährt fort. Force disconnect beendet das Warten früher. Ein fehlgeschlagener Lauf gibt die Leerungen frei, die er vorgenommen hat. Ein Mitglied, das nicht verbunden ist, zum Beispiel weil sein Host ausgefallen ist, hält das Update nicht auf: Der Lauf überspringt es, erfasst Skipped: the relay is not connected; it is updated when it reconnects bei seinem Schritt, aktualisiert die anderen Mitglieder und das lokale Relay und wird abgeschlossen. Settings → Relay zeigt das übersprungene Mitglied, und sobald es sich neu verbindet, wird das Relay-Pool-Update erneut angeboten und aktualisiert nur die Mitglieder, die noch zurückliegen. Derselbe Lauf aktualisiert zuletzt das lokale Relay. Ist ein anderes Relay des Pools bereit und verbunden, kann es jeden Workload bedienen, den das lokale Relay transportiert, und ist das laufende lokale Relay 2.11.1 oder neuer, leert der Lauf zuerst das lokale Relay auf dieselbe Weise: Seine Workloads wechseln zu den anderen Relays, das Leeren wartet wie oben, dann erstellt Opfield den Relay-Container neu, prüft, dass er die Zielversion ausführt, und gibt ihn wieder in den Betrieb zurück. Die interne Registry, die nur das lokale Relay bereitstellt, bleibt auf ihm: Ein leerendes Relay lässt weiterhin Image-Pulls zu, und ein durch die Neuerstellung abgebrochener Pull wird vom Docker-Daemon erneut gesendet. Andernfalls wird das lokale Relay sofort neu erstellt, und Verbindungen darüber brechen einmal für etwa eine Sekunde ab und verbinden sich neu: wenn kein anderes Relay bereit ist, wenn das laufende lokale Relay älter als 2.11.1 ist (sodass das erste Relay-Pool-Update auf 2.11.1 oder neuer es noch sofort neu erstellt), wenn ein Daemon auf dem Pfad eines Workloads keine Relay-Pool-Unterstützung hat, wenn der Node eines Workloads kein Relay außerhalb des Opfield-Hosts erreicht oder wenn die Workloads des lokalen Relays innerhalb von 5 Minuten nach dem Leeren nicht gewechselt sind. Der Schritt des lokalen Relays im Lauf erfasst den Grund. Sobald das lokale Relay neu erstellt wird, kann der Lauf nicht mehr abgebrochen werden (409 RELAY_UPDATE_COMMITTED) und wird abgeschlossen oder setzt das lokale Relay zurück, falls er fehlschlägt. In 2.11 erfordern Relay-Releases Opfield 2.11 oder neuer, und Opfield bietet kein Update an, solange sein lokales Relay zwei oder mehr Minor-Versionen hinter dem Ziel liegt.

Mit nur einem Relay unterbricht dessen Neuerstellung kurz den Secure-Link-Verkehr: Anfragen, die in diesem Moment über das alte Relay offen sind, enden, und Daemons verbinden sich innerhalb eines Sekundenbruchteils neu, nachdem das neue Relay lauscht. Ingress Nodes halten neue Secure-Link-Verbindungen bis zu 3 Sekunden zurück, bis das Relay oder der Ziel-Daemon zurück ist, sodass aktuelle Daemons zusätzliche Latenz statt 502-Antworten sehen. Ein Relay von 2.10 wird nach 2 Sekunden gestoppt, statt auf den Stopp-Timeout von 10 Sekunden von Docker zu warten. Aktualisieren Sie bei einem Update von 2.10 die Node-Daemons vor dem Relay-Pool, damit das neu erstellte Relay auf Daemons trifft, die sich schnell neu verbinden. Relay-Updates ganz ohne Unterbrechung erfordern ein zweites Relay im Pool.

Relays stimmen beim Failover der Datenebene ab, und ein Relay, dem ein Administrator das Hosten von Witnesses erlaubt hat, stimmt auch für Datenbanken und Speicher auf mehreren Servern ab (Settings → Relay, Spalte Witnesses). Bevor ein Relay geleert wird, wartet das Update, bis die anderen Abstimmenden und Kandidaten seiner Availability-Richtlinien zurück sind und abstimmen, und nach dem Neustart wartet es, bis das Relay wieder abstimmt (höchstens 3 Minuten), sodass ein Relay-Update einer Richtlinie nie eine zweite Stimme entzieht.

Ein Relay, das auf einer Maschine installiert ist, die jemand anderem gehört, kann im geschützten Modus laufen, der Opfield-Administratoren von diesem Host fernhält.

Entfernen Sie ein entferntes Relay, nachdem es geleert wurde und ihm nichts mehr zugewiesen ist. Ein Mitglied, das offline ist, kann ebenfalls entfernt werden, aber erst nachdem seine signierte Richtlinie abgelaufen ist und es mindestens 90 Sekunden nicht gesehen wurde, und nur solange jeder betroffene Workload von einem bereiten verbleibenden Mitglied bedient wird; Opfield verweigert ein Entfernen, das einen Endpunkt verwaisen lassen würde. Bis die Richtlinie abläuft, könnte das Mitglied noch selbst Verbindungen zulassen. Für ein Mitglied, das offline ist, zeigt Settings → Relay Can be removed after mit Datum und Uhrzeit in Ihrer Ortszeit und hält Remove bis dahin deaktiviert; ein früheres Entfernen wird mit 409 RELAY_OFFLINE_REMOVAL_UNSAFE abgelehnt, dessen Meldung und details.removableAfter denselben Zeitpunkt angeben.

Das Entfernen des Opfield-Eintrags ersetzt nicht die normale Außerbetriebnahme des Hosts. Deinstallieren Sie den Supervisor und entfernen Sie das Host-Material über das dokumentierte betriebliche Verfahren.

Relay-Wiederherstellung in 2.11

Opfield behebt häufige Probleme mit Vertrauen und Zertifikaten von Relays selbst:

• Zertifikate. Relay-Serverzertifikate werden vor ihrem Ablauf automatisch verlängert; siehe Zertifikatsverlängerung. Jedes Mitglied zeigt, ob sein Zertifikat bald abläuft, abgelaufen ist oder nicht verlängert werden konnte. Renew certificate erscheint bei einem abgelaufenen Zertifikat oder einer fehlgeschlagenen Verlängerung und erfordert ein verbundenes Mitglied.
• Richtlinienvertrauen, lokales Relay. Lehnt das lokale Relay die signierte Richtlinie von Opfield ab, legt Opfield den aktiven Signaturschlüssel automatisch erneut fest, höchstens einmal alle 10 Minuten, und erfasst die Wiederherstellung im Audit-Log. Ein lokales Relay ohne diese Fähigkeit zeigt eine Meldung mit dem manuellen Verfahren; aktualisieren Sie zuerst den Relay-Pool.
• Richtlinienvertrauen, entfernte Mitglieder. Ein entferntes Mitglied, das keinem Schlüssel mehr vertraut, mit dem Opfield signieren kann, wird zur erneuten Registrierung markiert.
• Neu registrieren. Für ein entferntes Mitglied, das eine erneute Registrierung benötigt, ein abgelaufenes Zertifikat hat oder offline ist bzw. fehlschlägt, stellt Re-enroll einen einmaligen Installationsbefehl aus, der 7 Tage gültig und auf die Relay-Version festgelegt ist, die der Pool ausführt. Opfield akzeptiert das Token nur vom eigenen Host des Mitglieds. Das Mitglied behält seinen Platz und seine Zuweisungen; auf dem Host legt der Supervisor seine vorherige Identität beiseite und stellt sie wieder her, wenn Opfield die Registrierung ablehnt. Das Installationsprogramm wartet auf die Registrierung und endet mit einem Fehler, wenn Opfield das Token ablehnt (bereits verwendet, abgelaufen, für ein anderes Relay ausgestellt oder auf einem anderen Host ausgeführt); das Relay läuft dann mit seiner vorherigen Identität weiter. Um ein Relay unverändert zu lassen, führen Sie das Installationsprogramm erneut ohne --token aus. Das lokale Relay kann nicht neu registriert werden; Opfield stellt es automatisch wieder her.
• Verbindungen nach Verlängerung oder erneuter Registrierung. Docker und Ingress Nodes übernehmen das verlängerte oder neu registrierte Zertifikat eines Mitglieds ohne Neustart des Daemons. Bestehende Verbindungen bleiben über eine Verlängerung hinweg bestehen; eine abgebrochene Verbindung wird mit dem neuen Zertifikat und der neuen Adresse neu aufgebaut.
• Verlorener Zustand. Ein Relay, das ohne seine gespeicherte Richtlinie neu startet, zum Beispiel nachdem seine Datendatei zurückgesetzt wurde, erhält seine Richtlinie erneut, sobald es sich neu verbindet, statt Verbindungen mit „policy snapshot is required“ abzulehnen.
• Neustarts des lokalen Relays. Mit aktivierter Automatic recovery startet Opfield ein lokales Relay neu, das abgestürzt ist oder hängt. Einen Neustart oder Stopp, den jemand anderes gestartet hat, lässt es unabhängig von der Dauer in Ruhe und verbindet sich innerhalb von Sekunden mit dem neuen Relay. Ein docker stop des lokalen Relays durch einen Operator wird weiterhin rückgängig gemacht, 2 Sekunden nach Abschluss des Stopps. Ein Node, dessen Verbindung während eines Relay-Neustarts abbricht, wird erst nach 5 Sekunden als offline angezeigt, und Daemons wiederholen Registrierungen mit wachsender Verzögerung bis zu 15 Sekunden, sofort sobald das Relay wieder erreichbar ist.

Prüfungen bei Vorfällen

Prüfen Sie bei einer Relay-Warnung den Prozess des lokalen Relays oder des entfernten Workers, das Identitäts-Volume, den Autorisierungspfad über PostgreSQL, den angekündigten Endpunkt, den Listener auf 9443, die Aktualität der Richtlinie und die Erreichbarkeit der zugewiesenen Nodes. Bewahren Sie Logs und Identität vor einem Neustart. Prüfen Sie nach der Wiederherstellung erneute Verbindungen der Nodes, Secure Links, Datenbank-Bindings, aktive Datenströme, den Zuweisungszustand und die Warnung im Dashboard.

Prüfung von Kapazität und Ausfallsicherheit

Ein Relay erhöht die Verfügbarkeit nur in seiner eigenen Fehlerdomäne und nur, wenn die verwalteten Nodes es erreichen können. Testen Sie die Konnektivität aus repräsentativen Netzwerken von Ingress, Docker, Storage, Monitoring und Build Worker, bevor Sie die Streuung der Zuweisung erhöhen. Ein zweites Relay hinter demselben Host, derselben Stromversorgung, derselben Firewall oder derselben Route erhöht die Kapazität, nicht die Verfügbarkeit.

Beobachten Sie bei normaler Last Verbindungsanzahl, aktive Datenströme, Arbeitsspeicher, Rate erneuter Verbindungen und Zulassungsfehler. Schaffen Sie genug Reserve, damit ein verbleibendes Mitglied neu zugewiesene Nodes aufnehmen kann, wenn ein Mitglied geleert wird oder nicht verfügbar ist. Eine Neuverteilung während eines Vorfalls kann die Last durch erneute Verbindungen erhöhen; stellen Sie daher zuerst die ausgefallene Abhängigkeit wieder her, es sei denn, die Konzentration der Zuweisungen ist selbst das Problem.

Wiederherstellung und Rollback

Schlägt das Update eines Mitglieds fehl, pausiert das Relay-Pool-Update oder gibt seine Leerungen frei; wiederholen Sie den Lauf oder brechen Sie ihn ab und stellen Sie das signierte, bekannt fehlerfreie Release von Supervisor und Worker über den unterstützten Update-Weg wieder her. Kopieren Sie keine Binärdateien oder kein Identitätsmaterial von einem anderen Mitglied. Prüfen Sie seinen angekündigten Endpunkt und seine Bereitschaft, bevor Sie es wieder für Zuweisungen freigeben.

Ist der Steuerungszustand des Pools fehlerfrei, kann sich aber ein Netzwerk nicht verbinden, korrigieren Sie Routing, DNS, Firewall oder NAT für diesen angekündigten Endpunkt, statt Relay-Identitäten zu ersetzen. Geht die Identität eines entfernten Mitglieds verloren oder ist sie nicht mehr vertrauenswürdig, verwenden Sie Re-enroll, bevor Sie eine Ersatzregistrierung in Betracht ziehen, und entfernen Sie einen alten Eintrag erst, wenn seine Zuweisungen sicher sind. Bewahren Sie bei einem Vorfall mit dem lokalen Relay die konfigurierte Identität und das Daten-Volume; den Container ohne sie neu zu erstellen, erzeugt eine andere und unbrauchbare Transportidentität.

Testen Sie nach jeder Wiederherstellung eine neue Sitzung eines verwalteten Nodes und einen echten privaten Pfad wie einen Secure Link oder ein Datenbank-Binding. Bestehende langlebige Datenströme allein können verbergen, dass neue Verbindungen nicht zugelassen werden.

Die Matrix der Auswirkungen auf Kunden, wenn Opfield, das lokale Relay oder alle Relays nicht verfügbar sind, finden Sie unter Verfügbarkeit, Kompatibilität und Grenzen.