Verfügbarkeit, Kompatibilität und Grenzen

Opfield trennt die Verfügbarkeit der Verwaltung von der Verfügbarkeit der Dienste. Ein Ausfall der Control Plane entzieht die Möglichkeit, neue Änderungen vorzunehmen und zu autorisieren; Infrastruktur, die bereits auf verwalteten Hosts angewendet wurde, läuft weiter.

Diese Unterscheidung ist zentral für die Produktionsplanung: Der kundenseitige Anwendungspfad, die Opfield-Anwendung und Relay können unterschiedliche Fehlerdomänen haben.

Was während eines Ausfalls weiterläuft

Ausfall	Was normalerweise weiterläuft	Was nicht verfügbar oder unsicher wird
Opfield-Anwendung nicht verfügbar; Relay fehlerfrei	nginx liefert die angewendete Konfiguration weiter aus; Container und Datenbanken laufen weiter; Relays lassen neue Secure-Link- und Datenbankverbindungen anhand ihrer letzten signierten Richtlinie für die Dauer der Richtlinien-Lease (standardmäßig 72 Stunden) weiter zu; Availability-Richtlinien im Lease-Modus führen weiter Failover durch, ebenso Datenbanken und Speicher auf mehreren Servern; die öffentliche Statusseite wird aus dem Cache des Ingress Nodes ausgeliefert	Oberfläche, API, Änderungen am Sollzustand, neue oder geänderte Routen und Verbindungen, Widerrufe, neue verwaltete Operationen und das Backend-Failover von Availability
Opfield-Host nicht verfügbar; lokales Relay läuft auf demselben Host	öffentliche Routen und Workloads, die nicht von Relay abhängen, laufen auf ihren eigenen Hosts weiter; Verbindungen, die zusätzlich ein Relay auf einem anderen Host verwenden, funktionieren darüber weiter, und Availability im Lease-Modus führt über solche Relays Failover durch	auch das lokale Relay fällt aus; die Steuerung verwalteter Nodes ist nicht verfügbar, und Verbindungen, die nur das lokale Relay transportiert, brechen ab
Ein externes Relay-Mitglied nicht verfügbar	Workloads laufen weiter; zugewiesener Datenverkehr kann andere bereite Mitglieder nur dort verwenden, wo Platzierung und aktive Zuweisungen diesen Weg bieten	Sitzungen, die nur dem ausgefallenen Mitglied zugewiesen sind, verbinden sich möglicherweise neu oder schlagen fehl; neue Kapazität ist bis zur Wiederherstellung und Neuverteilung reduziert
Kein erreichbares Relay	gewöhnliche hostlokale Workloads und direkt ausgelieferter öffentlicher Datenverkehr können weiterlaufen	die Steuerung verwalteter Nodes und neue private Verbindungen schlagen fehl; bestehende, von Relay abhängige Datenströme sind nicht garantiert
Ein verwalteter Node nicht verfügbar	Ressourcen auf anderen Nodes laufen weiter; eine Availability-Richtlinie im Lease-Modus verschiebt die Slots des Nodes innerhalb von etwa 45 Sekunden auf andere Kandidaten, mit oder ohne Opfield; eine Datenbank oder ein Speicher auf mehreren Servern mit automatischem Failover wechselt zu einer Kopie	Ressourcen, die diesem Node gehören, sind nicht verfügbar oder veraltet; Opfield darf nicht auf Grundlage veralteten Inventars ändern; beim Backend-Failover benötigen Ersatzplatzierungen ein laufendes Opfield
Lizenzschlüssel läuft regulär ab, oder ein kostenpflichtiger Tarif wird herabgestuft, widerrufen oder deaktiviert	alles während der Kulanzfrist (keine bei Widerruf, Übertragung oder Deaktivierung); danach bestehende Workloads, die Datenebene, Daten, geplante Backups sowie Ansicht, Monitoring und Löschen bestehender kostenpflichtiger Ressourcen	das Erstellen kostenpflichtiger Ressourcen und das Ändern ihrer Konfiguration; SIEM-Weiterleitung und Tokens für externe Registries pausieren bis zur Verlängerung; siehe Downgrade und Ablauf
Lizenzdienst nicht erreichbar	Opfield, Workloads und kostenpflichtige Funktionen laufen weiter; ein zuvor gültiger kostenpflichtiger Schlüssel bleibt 100 Tage nach seinem letzten signierten Lizenzzustand gültig	das Aktivieren eines Schlüssels und das Aktualisieren einer Installation, die einen kostenpflichtigen Tarif hat oder hatte (eine Community-Installation ohne Schlüssel wird weiterhin aktualisiert); nach 100 Tagen die Regeln eines regulären Ablaufs nach der Kulanzfrist
Gültiger kostenpflichtiger Schlüssel, kommerzieller Kern fehlt oder wird abgelehnt	bestehende Infrastruktur und Community-Funktionen laufen weiter	kostenpflichtige Funktionen werden als nicht bereit gemeldet, bis Enable paid features gelingt

„Läuft weiter“ bedeutet, dass der zuletzt erfolgreich angewendete lokale Zustand aktiv bleibt. Es garantiert weder, dass eine Anwendung genug Replikate hat, noch dass ihre Datenbank fehlerfrei ist oder dass ein bestehender privater Datenstrom jeden Netzwerkausfall übersteht.

Workload Availability

Workload Availability (HA) ist in Business und Enterprise verfügbar. Sie unterstützt 2–32 Replikate oder eine bedienende Platzierung mit Ersatz für Container ohne Mounts, Deployments und ganze Compose-Projekte. Wenn jeder Docker Node, jeder Ingress Node und jedes Relay eines Workloads ein Release mit Failover der Datenebene ausführt, ersetzen die Nodes einen ausgefallenen Inhaber selbst, auch während Opfield ausgefallen ist, und ein abgeschnittener Node stoppt seine eigene Kopie. Andernfalls stellt Opfield die angeforderten Platzierungen auf verfügbaren geeigneten Nodes wieder her, was eine fehlerfreie Control Plane erfordert. Beides benötigt Kapazität, Artefakte und Abhängigkeiten; keines bietet Hochverfügbarkeit für Opfield selbst oder nginx. Der nginx-Ingress wird mit Ingress-Gruppen redundant gemacht.

Datenbanken und Speicher auf mehreren Servern

In Business und Enterprise können verwaltete Datenbanken und verwalteter Speicher auf 2 bis 5 Storage Nodes mit einem Primary und Kopien laufen. Mit Witnesses auf Relays oder anderen Docker Nodes übernimmt eine Kopie automatisch, auch während Opfield ausgefallen ist, solange die signierte Richtlinie der Relays gültig ist (standardmäßig 72 Stunden). Zwei Server ohne Witness-Host bilden ein replicated pair, das Sie manuell umschalten. Was ein Failover verlieren kann, hängt von Engine und Dauerhaftigkeit ab; siehe Datenbanken und Speicher auf mehreren Servern.

Das Problem des lokalen Relays

Jede Installation enthält ein lokales Relay. Teilen sich Opfield und dieses Relay einen Host, entfernt der Verlust des Hosts sowohl die Verwaltung als auch den Transport, den Secure Links und Sitzungen verwalteter Nodes verwenden.

Fügen Sie für Umgebungen, in denen private Verbindungen den Verlust des Opfield-Hosts überstehen müssen, externe Relay-Mitglieder in unabhängigen Fehlerdomänen hinzu und prüfen Sie, dass jeder relevante Node sie erreichen kann. Opfield platziert dann jeden Secure Link auf mindestens einem Relay außerhalb des Opfield-Hosts, das seine Nodes erreichen können, und Settings → Relay warnt vor Verbindungen, die vom Opfield-Host abhängen, weil ihre Nodes kein anderes Relay erreichen können. Einen zweiten Relay-Container auf derselben Maschine, hinter derselben Firewall, an derselben Stromversorgung oder auf demselben Netzwerkpfad zu betreiben, verbessert die Fehlertoleranz nicht.

Testen Sie den genauen Anwendungspfad. Eine öffentliche Route zu einem lokalen Upstream kann ohne Relay weiterlaufen, während eine Route oder ein Datenbank-Binding einer Anwendung, das einen Secure Link verwendet, von erreichbarem Relay-Transport abhängt.

Versionskompatibilität

Behandeln Sie Opfield, Relay, verwaltete Daemons und ihre Protokollversionen als einen getesteten Release-Satz.

Verwenden Sie die Versionen, die gemeinsam durch die Release-Metadaten und das unterstützte Installationsprogramm veröffentlicht werden.
Aktualisieren Sie die Mitglieder des Relay-Pools jeweils für eine Fehlerdomäne.
Aktualisieren Sie zuerst repräsentative Nodes und prüfen Sie frische Fähigkeiten, Inventar und eine echte Operation.
Nehmen Sie nicht an, dass beliebige ältere oder neuere Daemons kompatibel sind, nur weil sie eine TCP-Verbindung aufbauen können.
Behalten Sie die vorherigen freigegebenen Image-Referenzen und das passende Backup, bis das Beobachtungsfenster endet.
Führen Sie kein Downgrade über eine Datenbankmigration hinweg durch, sofern die Release Notes es nicht ausdrücklich unterstützen und ein abgestimmter Wiederherstellungspunkt existiert.

Das Failover der Datenebene benötigt dasselbe Release auf jedem Teilnehmer eines Workloads: Eine Richtlinie wechselt erst dorthin, nachdem alle es 2 Minuten lang ausgeführt haben, und verlässt es, wenn ein Ingress Node oder ein Relay 2 Minuten lang veraltet bleibt. Siehe Updates und gemischte Versionen.

Kompatibilität wird pro Release festgelegt, nicht als Matrix aller historischen Komponentenkombinationen: Betreiben Sie die Daemons und Relays desselben Releases wie Opfield und beschränken Sie gemischte Versionen auf das Update-Fenster. Erfordert Ihre Richtlinie ein längeres Fenster mit gemischten Versionen, testen Sie genau diese Kombination auf einer Staging-Installation und halten Sie sie als installationsspezifische Einschränkung fest.

Kapazität und getestete Grenzen

Es gibt keine einzelne sinnvolle Höchstzahl an Nodes, Routen, Workloads, Builds, Datenbanken oder gleichzeitigen privaten Datenströmen. Die Kapazität hängt von Host-Ressourcen, Operationsrate, Aufbewahrung, Form der Nutzdaten, Relay-Platzierung, Build-Last und externen Anbietern ab.

Wandeln Sie Kontingente des Tarifs nicht in eine Leistungsgarantie um. Testen Sie vor der Produktion einen repräsentativen Workload bei erwarteter Spitzenlast plus vereinbarter Reserve und halten Sie fest:

API-Latenz von Opfield und Verzögerung der Hintergrundwarteschlange;
PostgreSQL-Verbindungen, -Latenz, Speicherwachstum und Backup-Dauer;
Arbeitsspeicher und Warteschlangenzustand von Redis;
Relay-Verbindungen, Arbeitsspeicher, Durchsatz, Verhalten beim erneuten Verbinden und Streuung der Zuweisungen;
Volumen und Aktualität der Node-Meldungen;
Build-Parallelität, Artefaktgröße und Festplattendruck;
Wachstum der Aufbewahrung von Logs, Audit, Metriken und Pages;
Wiederherstellungszeit nach dem Neustart jeder gemeinsam genutzten Komponente.

Bewahren Sie diese Werte zusammen mit dem Release und der Topologie auf, auf denen sie gemessen wurden, und messen Sie nach wesentlichen Upgrades erneut.

Produktionsentscheidung

Dokumentieren Sie, bevor Sie einen Workload annehmen, welche Ausfallpfade er toleriert, welche Pfade ein externes Relay erfordern, welche Datendienste unabhängige Hochverfügbarkeit haben und wer die Control Plane wiederherstellt. Führen Sie dann die Checkliste für die Produktionsreife und das Incident-Runbook für diese Topologie durch.