Semaphore bei Ausfall eines Anwendungsknotens verfügbar halten

Die dokumentierte aktiv/aktiv-Architektur verwendet mehrere Semaphore-Anwendungsknoten, eine gemeinsame PostgreSQL- oder MySQL-Datenbank, Redis-Koordination und einen Load Balancer für HTTP- und WebSocket-Verkehr. Jeder Knoten benötigt passende gemeinsame Einstellungen und eine eindeutige HA-Kennung. Planen Sie die Verfügbarkeit dieser Abhängigkeiten zusammen mit den Anwendungsknoten. Ein zweiter Prozess allein stellt nicht den gemeinsamen Zustand und die Koordination der vollständigen Topologie bereit.

Die hier beschriebene Architektur ist aktiv/aktiv: Gleichwertige Anwendungsknoten beteiligen sich am Dienst. Sie benötigt keinen dedizierten primären Anwendungsknoten und keinen passiven Ersatzknoten. Konfigurieren Sie das unterstützte Konzept anhand der aktuellen HA-Anleitung und leiten Sie aus allgemeinen Verfügbarkeitsaussagen keine separate aktiv/passiv-Referenzarchitektur ab. Benötigt Ihre Infrastruktur eine andere Topologie, klären Sie deren Zustands- und Failover-Verhalten vor der Bereitstellung.

Nein. Das dokumentierte HA-Konzept benötigt eine gemeinsame PostgreSQL- oder MySQL-Datenbank zusammen mit Redis. Die Datenbank ist die gemeinsame Quelle des Anwendungszustands für die beteiligten Knoten. Wenn Sie von einer Einzelknoteninstallation mit einer anderen Speicheroption wechseln, planen Sie Migration, Sicherungen und Validierung als eigene Arbeit. Testen Sie bereits vor dem Hinzufügen von Anwendungsknoten, dass die vorgesehene gemeinsame Datenbank die benötigten Daten enthält und bereitstellt.

Diese Komponenten benötigen eine eigene Ausfallsicherheitsstrategie. Das Mehrknotenkonzept von Semaphore erzeugt nicht automatisch Datenbank-Failover, redundante Lastverteilung oder einen verfügbaren Redis-Dienst. Ermitteln Sie Ausfallbereich, Wiederherstellungsprozess und Kapazitätsanforderungen jeder Abhängigkeit. Testen Sie den gesamten Weg von der Client-Anfrage bis zum Task-Ergebnis, damit Ihr Verfügbarkeitsplan den tatsächlich genutzten Dienst abdeckt und nicht nur die Anzahl laufender Anwendungsknoten.

Leiten Sie aus mehreren Anwendungsknoten keine unterbrechungsfreie Fortsetzung laufender Tasks ab. Das Verhalten hängt vom Ausführungsweg, der ausgefallenen Komponente und der eingesetzten Version ab. Testen Sie den benötigten Task-Lebenszyklus einschließlich Statusmeldungen und beteiligter Runner. Planen Sie auch Versionskompatibilität und Migrationen bewusst, statt jede Aktualisierung als garantiert unterbrechungsfreies Rolling-Update zu behandeln. Verfügbarkeit der Oberfläche und Fortsetzung von Tasks sind unterschiedliche Anforderungen.

Hochverfügbarkeit ist eine Enterprise-Funktion. Beginnen Sie mit Ihren erforderlichen Betriebszeiten, Wartungsabläufen, Wiederherstellungszielen sowie vorhandenen Datenbank- und Load-Balancer-Diensten. Ermitteln Sie Lücken anhand der dokumentierten Topologie und testen Sie Knotenausfälle, die Wiederherstellung von Abhängigkeiten und Sicherungen in einer repräsentativen Umgebung. Bei geschäftskritischen Anforderungen ist eine Architekturabstimmung sinnvoll, da die gesamte Bereitstellung das Ergebnis bestimmt, nicht ein einzelner Funktionsschalter.

Dazu werden aktive Anwendungsknoten hinter einer gemeinsamen, lastverteilten Dienstadresse betrieben. Der Load Balancer muss Anfragen an den ausgefallenen Knoten einstellen und HTTP- sowie WebSocket-Verkehr unterstützen. Der verbleibende Knoten benötigt weiterhin Zugriff auf die gemeinsame Datenbank, Redis und eine übereinstimmende Anwendungskonfiguration, um das Projekt bereitzustellen.

Nein. Mehrere Ausführungsstandorte werden durch Runner abgedeckt. Hochverfügbarkeit betrifft die Semaphore-Anwendungsebene; Runner bestimmen Ausführungsort und erreichbare Systeme. Eine Produktionsbereitstellung kann beides nutzen: HA-Anwendungsknoten für gemeinsame Oberfläche und API sowie Projekt-Runner nahe privater Infrastruktur.