Designüberlegungen für resiliente Arbeitslasten mit regionalen Laufwerken

Last reviewed 2020-09-23 UTC

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, synchron replizierten Laufwerken verwendet wird.

Dieses Dokument richtet sich an Anwendungsentwickler als ein Follow-up zu Hochverfügbarkeitsdienste mit regionalen Laufwerken erstellen mit einer Erweiterung zum Design und zur Architektur, die im Abschnitt Hochverfügbarkeits-Datenbankdienste mit regionalen Laufwerken 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 Compute Engine-Instanz in einer anderen Zone ausgeführt wird. Wenn die primäre Instanz ausfällt, wird die Anwendung weiterhin auf der sekundären Instanz ausgeführt. Eine zustandsorientierte Anwendung kann ihren Anwendungsstatus auf einem zonalen Laufwerk oder einem Laufwerk beibehalten, das nur in einer einzigen Zone verfügbar ist, um den Zustand nach einem Neustart der Instanz wiederherzustellen. Damit der Status stabil bleibt, muss eine zustandsorientierte Anwendung auch den Anwendungsstatus in einer sekundären Instanz beibehalten.

Abbildung 1 zeigt eine typische zustandsorientierte Anwendung mit zwei Knoten, die über zwei Zonen hinweg repliziert wird. Die Anwendung in jeder Zone hat einen zonalen Datenträger, um den Anwendungsstatus zu erfassen. Sie hat auch eine Netzwerkverbindung zwischen den Instanzen, um Änderungen des Anwendungsstatus zwischen den Knoten zu synchronisieren.

Ein Load Balancer wird verwendet, um den Anwendungsstatus auf eine primäre und eine sekundäre Instanz zu replizieren, die sich in verschiedenen Zonen befinden.

Abbildung 1. Zwei-Knoten-Anwendung mit Zustandsspeicher ohne regionale Laufwerke

Regionales Laufwerk hinzufügen

Eine weitere Möglichkeit zur Synchronisierung des Anwendungsstatus einer zustandsorientierten Anwendung besteht darin, einen regionalen Datenträger hinzuzufügen. Wenn eine Anwendung ihren Anwendungsstatus auf einen regionalen Datenträger schreibt, synchronisiert Google Cloud automatisch den Blockspeicher mit einer anderen Zone.

Abbildung 2 zeigt die Architektur einer zustandsorientierten Datenbankanwendung.

Grafik: Ein regionales Laufwerk ist in zwei Zonen an zwei VM-Instanzen angehängt.

Abbildung 2. Zustandsorientierte Datenbankanwendung

Wie Abbildung 2 zeigt, gibt es immer noch zwei Compute-Instanzen der Anwendung – eine primäre und eine sekundäre –, die in zwei Zonen bereitgestellt werden. Neben dem Einsatz eines regionalen Laufwerks zum Speichern des Anwendungsstatus gibt es jetzt eine zusätzliche Entität: die anwendungsspezifische regionale Steuerungsebene. Die anwendungsspezifische regionale Steuerungsebene entscheidet darüber, welche Instanz an den regionalen Datenträger angehängt ist und welche Instanz die aktuelle primäre Instanz ist. Diese Architektur ist eine Aktiv-Passiv-Konfiguration, da nur die primäre Instanz einen Anwendungsstatus an den regionalen Datenträger übergeben kann.

Compute-Instanzen und die zustandsorientierte Anwendung

Abbildung 2 zeigt 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 Instanz birgt, können Sie die Compute Engine-Kosten senken, indem Sie nur die aktive Instanz ausführen. Bei einem Failover startet die anwendungsspezifische regionale Steuerungsebene die sekundäre Instanz und hängt das regionale Laufwerk an diese Instanz an.
  • Batch- oder Streamverarbeitungsarbeitslasten, die ihren Fortschritt auf den regionalen Datenträger prüfen. In einem Failover setzt die Anwendung die Verarbeitung ab dem letzten Prüfpunkt fort.

Start von Compute Engine-Instanzen verwalten

Da nur einer einzigen Compute-Instanz jeweils ein regionales Laufwerk angehängt sein kann, müssen Sie die Instanzen starten und das regionale Laufwerk systematisch anhängen. Eine Best Practice besteht darin, die Compute-Instanz und den Anwendungsstart vom Anhang des regionalen Laufwerks zu trennen. Die Startskripts der Instanz sollten den Anhang des regionalen nichtflüchtigen Speichers nicht initiieren. Stattdessen sollten die Startskripts den Systemdiagnose-Agent starten und warten, bis der regionale Datenträger angehängt ist.

Beim Start muss die Compute-Instanz die folgenden sequenziellen Schritte ausführen:

  1. Systemdiagnose-Agent starten
  2. Warten, bis das regionale Laufwerk angehängt ist
  3. Nachdem das regionale Laufwerk angehängt wurde, das Dateisystem bereitstellen
  4. 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 Datenträger an die sekundäre Instanz angehängt. Der regionale Datenträger wird gleichzeitig von der primären Instanz entfernt und E/A-Vorgänge an das Dateisystem schlagen fehl. An diesem Punkt müssen Sie die Compute-Instanz herunterfahren oder neu starten.

Systemdiagnose-Agent und Systemdiagnosen ausführen

Wie im vorherigen Abschnitt beschrieben, wartet die Compute-Instanz darauf, dass der regionale Datenträger angehängt wird, bevor die Anwendung gestartet wird. Die anwendungsspezifische regionale Steuerungsebene hängt den regionalen nichtflüchtigen Speicher an, jedoch nur an eine Compute-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 Compute-Instanz hat einen der folgenden Status:

  • Ausgefallen
  • Wird gestartet
  • Auf Laufwerk warten
  • Anwendung wird ausgeführt

Der Systemdiagnose-Agent meldet den aktuellen Zustand der Instanz. Anstatt diese beiden Zustände über eine einzige Systemdiagnose zu melden, können Sie zwei binäre Systemdiagnosen ausführen. Wenn die Compute-Instanz bereit ist, den regionalen Datenträger anzuhängen oder der regionale Datenträger angehängt und beschreibbar ist, meldet die Systemdiagnose der Instanz einen fehlerfreien Status. Wenn die Anwendung ausgeführt wird und den Anwendungsstatus auf den regionalen Datenträger schreiben kann, meldet die Systemdiagnose für Anwendungen einen fehlerfreien Status.

Die Verwendung von zwei binären Systemdiagnosen bietet mehrere Vorteile:

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 Compute-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:

  1. Sie prüft, ob eine sekundäre Instanz ausgeführt wird, und wartet, bis das regionale Laufwerk angehängt ist.
  2. Sie erzwingt das Anhängen des regionalen Laufwerks an die sekundäre Instanz.
  3. Sie überwacht die ausgefallene primäre Instanz und startet sie neu. Wenn die primäre 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 Compute-Instanz die primäre 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:

Abbildung 3 veranschaulicht die Verwendung von Cloud Run-Funktionen für die anwendungsspezifische regionale Steuerungsebene zusammen mit einer zustandsorientierten verwalteten Instanzgruppe und verwalteten Systemdiagnosen.

Grafik: Die primären und sekundären VMs werden von einer anwendungsspezifischen regionalen Steuerungsebene verwaltet.

Abbildung 3. Anwendungsspezifische regionale Steuerungsebene

Abbildung 3 zeigt zwei Compute-Instanzen der Anwendung, eine primäre und eine sekundäre. Jede Instanz wird in einer separaten Zone ausgeführt und von einer zustandsorientierten regionalen MIG verwaltet. Ein regionales Laufwerk ist in denselben zwei Zonen verfügbar. Es werden zwei verwaltete Systemdiagnosedienste ausgeführt. Ein verwalteter Systemdiagnosedienst überwacht den Zustand der 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 das Anhängen des regionalen Laufwerks an die aktuelle fehlerfreie Compute-Instanz.

Nächste Schritte