In diesem Dokument wird das Verhalten und die Interaktionen zwischen einer zustandsorientierten Anwendung, einem Systemdiagnose-Agent und einer anwendungsspezifischen regionalen Steuerungsebene erläutert, die zum Überwachen und Orchestrieren eines zonalen Failovers mithilfe von regionalen nichtflüchtigen Speichern verwendet wird.
Dieses Dokument richtet sich an Anwendungsentwickler als ein Follow-up zu Hochverfügbarkeitsoptionen mit regionalen nichtflüchtigen Speichern mit einer Erweiterung zum Design und zur Architektur, die im Abschnitt Hochverfügbarkeits-Datenbankdienste mit regionalen nichtflüchtigen Speichern erstellen beschrieben werden. Wir empfehlen Ihnen, zuerst dieses Dokument zu lesen, insbesondere die Abschnitte zu Überlegungen zum Design und Kostenvergleich, Leistung und Ausfallsicherheit.
Eine zustandslose Anwendung erhöht die Ausfallsicherheit, indem mindestens eine sekundäre VM-Instanz in einer anderen Compute Engine-Zone ausgeführt wird. Wenn die primäre VM ausfällt, wird die Anwendung weiterhin auf der sekundären VM ausgeführt. Eine zustandsorientierte Anwendung kann ihren Anwendungsstatus auf einem zonalen nichtflüchtigen Speicher beibehalten, um den Zustand nach einem Neustart der VM-Instanz wiederherzustellen. Damit der Status stabil bleibt, muss eine zustandsorientierte Anwendung auch den Anwendungsstatus in einer sekundären VM-Instanz beibehalten.
Das folgende Diagramm zeigt eine typische zustandsorientierte Anwendung mit zwei Knoten, die über zwei Zonen hinweg repliziert wird. Die Anwendung in jeder Zone hat einen zonalen nichtflüchtigen Speicher, um den Anwendungsstatus zu erfassen. Sie hat auch eine Netzwerkverbindung zwischen den VM-Instanzen, um Änderungen des Anwendungsstatus zwischen den Knoten zu synchronisieren.
Regionalen nichtflüchtigen Speicher hinzufügen
Eine weitere Möglichkeit zur Synchronisierung des Anwendungsstatus einer zustandsorientierten Anwendung besteht darin, einen regionalen nichtflüchtigen Speicher hinzuzufügen. Wenn eine Anwendung ihren Anwendungsstatus auf einen regionalen nichtflüchtigen Speicher schreibt, synchronisiert Google Cloud automatisch den Blockspeicher mit einer anderen Zone.
Das folgende Diagramm zeigt die Architektur einer zustandsorientierten Datenbankanwendung.
Wie das obige Diagramm zeigt, gibt es immer noch zwei VM-Instanzen der Anwendung: eine primäre VM-Instanz und eine sekundäre VM-Instanz, die in zwei Zonen bereitgestellt werden. Neben dem Einsatz eines regionalen nichtflüchtigen Speichers zum Speichern des Anwendungsstatus gibt es jetzt eine zusätzliche Entität: die anwendungsspezifische regionale Steuerungsebene. Die anwendungsspezifische regionale Steuerungsebene entscheidet darüber, welche VM-Instanz an den regionalen nichtflüchtigen Speicher angehängt ist und welche VM-Instanz die aktuelle primäre VM-Instanz ist. Diese Architektur ist eine Aktiv-Passiv-Konfiguration, da nur die primäre VM-Instanz einen Anwendungsstatus an einen regionalen nichtflüchtigen Speicher übergeben kann.
VM-Instanzen und zustandsorientierte Anwendung
Das obige Architekturdiagramm veranschaulicht eine wichtige Aktiv-Passiv-Datenbankanwendung. Folgende Konfigurationen sind ebenfalls möglich:
- Wenn das Recovery Time Objective (RTO) die zusätzliche Latenz beim Starten einer sekundären VM-Instanz birgt, können Sie die Compute Engine-Kosten senken, indem Sie nur die aktive VM-Instanz ausführen. Bei einem Failover startet die anwendungsspezifische regionale Steuerungsebene die sekundäre VM-Instanz und hängt den regionalen nichtflüchtigen Speicher an.
- Batch- oder Streamverarbeitungsarbeitslasten, die ihren Fortschritt auf den regionalen nichtflüchtigen Speicher prüfen. In einem Failover setzt die Anwendung die Verarbeitung ab dem letzten Prüfpunkt fort.
Starts der VM-Instanz verwalten
Da nur einer einzigen VM-Instanz jeweils ein regionaler nichtflüchtiger Speicher angehängt sein kann, müssen Sie die VM-Instanzen starten und den regionalen nichtflüchtigen Speicher systematisch anhängen. Eine Best Practice besteht darin, die VM-Instanz und den Anwendungsstart vom Anhang des regionalen nichtflüchtigen Speichers zu trennen. Die Startskripts der VM-Instanz sollten den Anhang des regionalen nichtflüchtigen Speichers nicht initiieren. Stattdessen sollten die Startskripts den Systemdiagnose-Agent starten und warten, bis der regionale nichtflüchtige Speicher angehängt ist.
Beim Start muss die VM-Instanz die folgenden sequenziellen Schritte ausführen:
- Systemdiagnose-Agent starten
- Warten, bis der regionale nichtflüchtige Speicher angehängt ist
- Nachdem der regionale nichtflüchtige Speicher angehängt wurde, das Dateisystem bereitstellen
- Nachdem das Dateisystem bereitgestellt wurde, die Anwendung starten
Diese Schritte decken den Systemstart ab, es gibt jedoch auch ein Failover. Während eines Failovers wird der regionale nichtflüchtige Speicher an die sekundäre VM-Instanz angehängt. Der regionale nichtflüchtige Speicher wird gleichzeitig von der primären VM-Instanz entfernt und E/A-Vorgänge an das Dateisystem schlagen fehl. An diesem Punkt müssen Sie die VM-Instanz herunterfahren oder neu starten.
Systemdiagnose-Agent und Systemdiagnosen ausführen
Wie im vorherigen Abschnitt beschrieben, wartet die VM-Instanz darauf, dass der regionale nichtflüchtige Speicher angehängt wird, bevor die Anwendung gestartet wird. Die anwendungsspezifische regionale Steuerungsebene hängt den regionalen nichtflüchtigen Speicher an, jedoch nur an eine VM-Instanz, die auf das Anhängen des Laufwerks wartet. Wenn ein Laufwerk angehängt wird, überwacht die anwendungsspezifische Steuerungsebene den Status der Anwendung und initiiert ein Failover, wenn die Anwendung fehlerhaft wird.
Jede VM-Instanz hat einen der folgenden Zustände:
- Ausgefallen
- Wird gestartet
- Auf Laufwerk warten
- Anwendung wird ausgeführt
Der Systemdiagnose-Agent meldet den aktuellen Zustand der VM-Instanz. Anstatt diese beiden Zustände über eine einzige Systemdiagnose zu melden, können Sie zwei binäre Systemdiagnosen ausführen. Wenn die VM-Instanz bereit ist, den regionalen nichtflüchtigen Speicher anzuhängen oder der regionale nichtflüchtige Speicher angehängt und bearbeitbar ist, meldet die Systemdiagnose der VM-Instanz einen fehlerfreien Status. Wenn die Anwendung ausgeführt wird und den Anwendungsstatus auf den regionalen nichtflüchtigen Speicher schreiben kann, meldet die Systemdiagnose für Anwendungen einen fehlerfreien Status.
Die Verwendung von zwei binären Systemdiagnosen bietet mehrere Vorteile:
- Sie können den verwalteten Systemdiagnosedienst von Compute Engine verwenden, der den Systemdiagnose-Agent abfragt und vorübergehende Fehler durch Schwellenwertwerte behebt.
- Eine verwaltete Instanzgruppe (Managed Instance Group, MIG) kann die Systemdiagnose der Instanz überwachen und eine automatische Reparatur einer fehlerhaften VM-Instanz ausführen.
- Der Load-Balancer kann die Systemdiagnose der Anwendung überwachen und den Traffic an die aktive Anwendungsinstanz weiterleiten.
Sie können verhindern, dass das System auf einen vorübergehenden Fehler reagiert. Reduzieren Sie dazu die Häufigkeit der Berichte für die Systemdiagnose oder erhöhen Sie den Schwellenwert der wiederkehrenden Signale, die für die Umstellung von einer Stufe auf eine andere erforderlich sind. Beide Ansätze verzögern die Reaktion des Systems auf einen Ausfall und erhöhen die Zeit für die Wiederherstellung. Durch Testen und Messen dieser Parameter können Sie Parameter für die Systemdiagnose anpassen, um die Zeit für die Systemwiederherstellung auszugleichen.
Informationen zur anwendungsspezifischen regionalen Steuerungsebene
Das letzte Element in der Architektur ist die anwendungsspezifische regionale Steuerungsebene, die für die folgenden beiden Funktionen verantwortlich ist:
- Lebenszyklus der primären und sekundären VM-Instanzen verwalten
- Status der Systemdiagnose der Anwendung überwachen und bestimmen, ob ein Failover erforderlich ist
Wenn ein Failover erforderlich ist, orchestriert die anwendungsspezifische regionale Steuerungsebene das Failover mit den folgenden Schritten:
- Sie prüft, ob eine sekundäre VM-Instanz ausgeführt wird, und wartet, bis der regionale nichtflüchtige Speicher angehängt ist.
- Sie erzwingt den Anhang des regionalen nichtflüchtigen Speichers an die sekundäre VM-Instanz
- Sie überwacht die ausgefallene primäre VM-Instanz und startet sie neu Wenn die VM-Instanz neu gestartet wird, initiiert die Steuerungsebene nach Bedarf ein Failback.
Die anwendungsspezifische regionale Steuerungsebene selbst muss in den beiden Zonen, in denen die Anwendung ausgeführt wird, hochverfügbar sein. In lokalen Rechenzentren wird Hochverfügbarkeit (High Availability, HA) häufig durch Bereitstellung zusätzlicher Server zum Erstellen eines Quorums, Entscheiden, welche VM-Instanz die primäre VM-Instanz ist, und Orchestrieren eines Failovers erzielt. Dabei werden häufig HA-Monitoring-Tools wie Heartbeat, Pacemaker oder Keepalived verwendet.
Obwohl Sie die anwendungsspezifische regionale Steuerungsebene überall in der Cloud verwenden können, bietet Google Cloud die folgenden verwalteten und regional verfügbaren Dienste, die die Implementierung dieses Ansatzes vereinfachen:
- Serverlose Google Cloud-Produkte wie App Engine, Cloud Run und Cloud Run-Funktionen, die sich einfach verwalten und bereitstellen lassen
- Verwaltete Systemdiagnosen, die das Monitoring der Anwendungsinstanzen übernehmen
- Verwaltete Instanzgruppen, die den Lebenszyklus der Serverinstanzen verwalten
Das folgende Diagramm veranschaulicht die Verwendung von Cloud Run-Funktionen für die anwendungsspezifische regionale Steuerungsebene zusammen mit einer zustandsorientierten verwalteten Instanzgruppe und verwalteten Systemdiagnosen.
Das obige Diagramm zeigt zwei VM-Instanzen der Anwendung (primäre und sekundäre). Jede VM-Instanz wird in einer separaten Zone ausgeführt und von einer zustandsorientierten regionalen MIG verwaltet. Ein regionaler nichtflüchtiger Speicher ist in denselben zwei Zonen verfügbar. Es werden zwei verwaltete Systemdiagnosedienste ausgeführt. Ein verwalteter Systemdiagnosedienst überwacht den Zustand der VM-Instanz und wird von der zustandsorientierten MIG verwendet. Der andere Systemdiagnosedienst überwacht den Zustand der Anwendung und wird vom Zielpool des Load-Balancers verwendet.
Eine anwendungsspezifische regionale Steuerungsebene interagiert mit dem Zustand der Zielpoolanwendung und der zustandsorientierten regionalen MIG. Dadurch überwacht sie den Status der Anwendung und initiiert den Anhang des regionalen nichtflüchtigen Speichers an die aktuelle fehlerfreie VM-Instanz.
Nächste Schritte
- Lesen Sie Regionalen nichtflüchtigen Speicher bereitstellen in Google Kubernetes Engine.
- Informationen zum Anpassen lokaler HA-Tools für die Verwendung in Google Cloud finden Sie unter Muster für die Verwendung von Floating-IP-Adressen.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center