Hochverfügbarkeitsdienste mit synchron replizierten Laufwerken erstellen

Hyperdisk mit ausgeglichener Hochverfügbarkeit ist eine Speicheroption, mit der Sie Hochverfügbarkeitsdienste in Compute Engine implementieren können. Hyperdisk mit ausgeglichener Hochverfügbarkeit repliziert Daten synchron zwischen zwei Zonen in derselben Region und sorgt für Hochverfügbarkeit bei Laufwerksdaten für bis zu einen Zonenausfall.

Hochverfügbarkeitsdienste mit replizierten Laufwerken erstellen

In diesem Abschnitt wird erläutert, wie Sie Hochverfügbarkeitsdienste mitHyperdisk mit ausgeglichenem Hochverfügbarkeitslaufwerken erstellen.

Designaspekte

Bevor Sie die Entwicklung eines Hochverfügbarkeitsdienstes in Angriff nehmen, sollten Sie sich mit den Merkmalen der Anwendung, des Dateisystems und des Betriebssystems vertraut machen. Diese Merkmale sind die Grundlage für das Design und können verschiedene Ansätze ausschließen. Wenn eine Anwendung beispielsweise Replikation auf Anwendungsebene nicht unterstützt, sind bestimmte entsprechende Designoptionen nicht anwendbar.

Wenn die Anwendung, das Dateisystem oder das Betriebssystem nicht absturztolerant sind, ist die Verwendung von regionalem nichtflüchtigen SpeicherHyperdisk mit ausgeglichenen Hochverfügbarkeitslaufwerken (Vorschau oder sogar von zonalen Disk-Snapshots möglicherweise keine Option. Absturztoleranz wird als die Fähigkeit definiert, ein System oder eine Anwendung nach einer abrupten Beendigung ohne den Verlust oder die Beschädigung von Daten wiederherzustellen, die bereits vor dem Absturz per Commit in einen Speicher übertragen wurden.

Berücksichtigen Sie beim Planen der Hochverfügbarkeit Folgendes:

  • Die Auswirkungen auf die Anwendung der Verwendung von Hyperdisk mit ausgeglichener Hochverfügbarkeit oder anderen Lösungen
  • Schreibleistung des Laufwerks
  • Das Recovery Time Objective des Dienstes: Wie schnell Ihr Dienst nach einem zonalen Ausfall wiederhergestellt werden muss, sowie die SLA-Anforderungen.
  • Die Kosten für die Erstellung einer stabilen und zuverlässigen Dienstarchitektur

In Bezug auf die Kosten verwenden Sie die folgenden Optionen für die synchrone und asynchrone Anwendungsreplikation:

  • Die Verwendung von jeweils zwei Instanzen der Datenbank und der VM: In diesem Fall hängen die Gesamtkosten von den folgenden Faktoren ab:

    • Kosten für VM-Instanz
    • Kosten fürPersistent Disk oderHyperdisk
    • Kosten für die Verwaltung der Anwendungsreplikation

  • Einzelne VM mit synchron replizierten Laufwerken verwenden: Wenn Sie Hochverfügbarkeit mit einemHyperdisk mit ausgeglichenem Hochverfügbarkeits-Laufwerk erreichen möchten, verwenden Sie dieselbe VM-Instanz und dieselben Laufwerkskomponenten wie die vorherige Option, aber Außerdem enthält er ein synchron repliziertes Laufwerk. Hyperdisk mit ausgeglichenen Hochverfügbarkeit-Laufwerke sind im Vergleich zu zonalen Laufwerken doppelt so teuer wie zonale Laufwerke, da sie in zwei Zonen repliziert werden.

    Die Verwendung von synchron replizierten Laufwerken kann jedoch Ihre Wartungskosten reduzieren, da die Daten automatisch in zwei Replikate geschrieben werden, ohne die Anwendungsreplikation verwalten zu müssen.

  • Starten Sie die sekundäre VM erst dann, wenn ein Failover erforderlich ist. Sie können die Hostkosten zusätzlich senken, indem Sie die sekundäre VM nur bei Bedarf während des Failovers starten, anstatt sie als aktive Standby-VM beizubehalten.

Kosten, Leistung und Ausfallsicherheit verwalten

Die folgende Tabelle veranschaulicht die Vor- und Nachteile der unterschiedlichen Dienstarchitekturen im Hinblick auf Kosten, Leistung und Ausfallsicherheit.

Hochverfügbarkeits-
Architektur		 Snapshots zonaler
Laufwerke		 Anwendungsebene
synchron
 Anwendungsebene
asynchron		 Synchron replizierte Laufwerke
Schützt vor dem Ausfall von Anwendungen, VMs und Zonen1
Minderung der Anwendungsbeschädigung (Beispiel: Intoleranz gegen Anwendungsabsturz) 2 2
Kosten $ $$

  • Two instances of the database or VM running, application replication setup and maintenance, cross zone networking.
 $$

  • Zwei Instanzen der ausgeführten Datenbank oder VM, Einrichtung und Verwaltung der Anwendungsreplikation, zonenübergreifendes Networking
 1,5 x $ – $$

  • Die Kosten entsprechen der Anwendungsreplikation bei Verwendung einer aktiven Standby-VM. Sie können die Kosten senken, wenn Sie eine Backup-VM nur bei Bedarf während des Failovers hochfahren. Für zonenübergreifende Netzwerke zwischen Laufwerkreplikaten fallen keine Kosten an.
Anwendungsleistung

  • Keine Auswirkungen

  • Nachteile der synchronen Replikation im Hinblick auf die Anwendungsleistung

  • Keine Auswirkungen

  • Keine Auswirkungen für die meisten Anwendungen
Geeignet für Anwendungen mit niedriger RPO-Anforderung (sehr geringe Toleranz gegenüber Datenverlust)

  • Der Datenverlust hängt davon ab, wann der Snapshot erstellt wurde

  • Kein Datenverlust3

  • Datenverlust, weil die Replikation asynchron ist

  • Kein Datenverlust
Speicherwiederherstellung nach einem Ausfall4
  • 0 (Minuten)
  • 0 (Sekunden)
  • 0 (Sekunden)
  • 0 (Sekunden), um das Anhängen des Speichers an eine Standby-VM-Instanz zu erzwingen

1 Die Verwendung replizierter Laufwerke oder Snapshots reicht nicht aus, um Ausfälle und Beschädigungen zu verhindern oder zu mindern. Ihre Anwendung, das Dateisystem und möglicherweise andere Softwarekomponenten müssen absturzsicher sein oder eine Art von Stilllegung verwenden.

2 Durch die Replikation einiger Anwendungen können manche Anwendungsfehler vermieden werden. Beispielsweise führt eine Beschädigung der primären MySQL-Anwendung nicht dazu, dass die VM-Instanzen ebenfalls beschädigt werden. Weitere Informationen finden Sie in der Dokumentation zu Ihrer Anwendung.

3 Datenverlust bezieht sich auf den nicht wiederherstellbaren Verlust von Daten, die per Commit in den nichtflüchtigen Speicher übertragen wurden. Alle nicht per Commit übertragenen Daten gehen verloren.

4 Die Failover-Leistung umfasst keine Dateisystemprüfung und Anwendungswiederherstellung sowie kein Laden nach einem Failover.

Hochverfügbarkeits-Datenbankdienste mit synchron replizierten Laufwerken erstellen

In diesem Abschnitt werden allgemeine Konzepte zum Erstellen von Hochverfügbarkeitslösungen für zustandsorientierte Datenbankdienste (MySQL, Postgres usw.) unter Verwendung von Compute Engine mitHyperdisk mit ausgeglichenen Hochverfügbarkeits-Laufwerke (Vorschau) behandelt.

Bei großen Ausfällen in Google Cloud, z. B. wenn eine ganze Region nicht mehr verfügbar ist, ist Ihre Anwendung möglicherweise nicht mehr verfügbar. Je nach Ihren Anforderungen sollten Sieregionenübergreifende Replikationstechniken für eine noch höhere Verfügbarkeit in Betracht ziehen.

Hochverfügbarkeitskonfigurationen für Datenbanken haben in der Regel mindestens zwei VM-Instanzen. Vorzugsweise sind diese VM-Instanzen Teil einer oder mehrerer verwalteter Instanzgruppen:

  • eine primäre VM-Instanz in der primären Zone
  • eine Standby-VM-Instanz in einer sekundären Zone

Eine primäre VM-Instanz hat mindestens zwei Laufwerke: ein Bootlaufwerk und ein repliziertes Laufwerk. Der replizierte Speicher enthält Datenbankdaten und andere änderbare Daten, die bei einem Ausfall in einer anderen Zone erhalten bleiben sollen.

Eine Standby-VM-Instanz benötigt ein separates Bootlaufwerk, um eine Wiederherstellung bei konfigurationsbedingten Ausfällen zu ermöglichen, die beispielsweise durch ein Betriebssystem-Upgrade verursacht wurden. Außerdem können Sie das Anhängen eines Bootlaufwerks an eine andere VM während eines Failovers nicht erzwingen.

Die primäre Instanz und die Standby-VM-Instanz sind für die Verwendung eines Load-Balancers konfiguriert, wobei der Traffic anhand von Signalen der Systemdiagnose an die primäre VM weitergeleitet wird. Das Notfallwiederherstellungsszenario für Daten beschreibt andere Failover-Konfigurationen, die für Ihr Szenario möglicherweise geeigneter sind.

Herausforderungen bei der Datenbankreplikation

In der folgenden Tabelle sind einige häufige Herausforderungen bei der Einrichtung und Verwaltung der synchronen oder halbsynchronen Replikation von Anwendungen (wie MySQL) aufgeführt und wie sie mit der synchronen Laufwerksreplikation mitHyperdisk mit ausgeglichenen Hochverfügbarkeits-Laufwerken verglichen werden (Vorschau).

Herausforderungen Anwendung synchron
oder halb-synchrone Replikation		 Synchrone Laufwerksreplikation
Stabile Replikation zwischen Primär- und Failover-Replikat aufrechterhalten Es können eine Reihe von Problemen auftreten, die dazu führen können, dass eine VM-Instanz den Hochverfügbarkeitsmodus nicht mehr gewährleistet:
  1. Fehlkonfiguration der Replikationsparameter, z. B. nicht übereinstimmende SSL-Zertifikate oder fehlende ACLs auf der primären Seite
  2. Hohe Last auf der primären VM-Instanz, die dazu führt, dass das Failover-Replikat nicht mithalten kann
  3. Fehler, die zu Replikationsproblemen führen, wie z. B. Anwendungsprobleme, Fehlkonfiguration des Betriebssystems, Docker-Fehler
  4. Infrastrukturausfälle wie CPU-Konflikte, eingefrorene VMs oder Netzwerkunterbrechungen

Speicherfehler werden von Hyperdisk mit ausgeglichenen Hochverfügbarkeits-Laufwerken verarbeitet. Dies geschieht transparent für die Anwendung, mit Ausnahme einer möglichen Fluktuation in der Leistung des Speichers.

Es müssen benutzerdefinierte Systemdiagnosen vorhanden sein, um Anwendungs- oder VM-Probleme aufzudecken und Failover auszulösen.
End-to-End-Failover-Zeit ist länger als erwartet. Die für den Failover-Vorgang benötigte Zeit hat keine Obergrenze. Das Warten auf die Wiederholung aller Transaktionen kann je nach Schema und Auslastung der Datenbank beliebig lange dauern.

Hyperdisk mit ausgeglichenen Hochverfügbarkeits-Laufwerken bieten eine synchrone Replikation, sodass die Failover-Zeit durch die Summe der folgenden Latenzen begrenzt wird:

  1. Erstellen einer sekundären VM, wenn nicht bereits eine Standby-VM-Instanz verfügbar ist
  2. Erzwungenes Anhängen eines replizierten Laufwerks
  3. Initialisieren der Anwendung
Split-Brain Beide Ansätze erfordern Maßnahmen, die dafür sorgen, dass jeweils nur eine primäre Instanz vorhanden ist, um Split-Brain zu vermeiden.

Reihenfolge der Lese- und Schreibvorgänge auf Laufwerken

Beim Festlegen der Lese- und Schreibsequenzen oder der Reihenfolge, in der Daten von dem Laufwerk gelesen und auf das Laufwerk geschrieben werden, wird der Großteil der Arbeit vom Laufwerktreiber in der VM ausgeführt. Als Nutzer müssen Sie sich nicht mit der Replikationssemantik befassen und können wie gewohnt mit dem Dateisystem interagieren. Der zugrunde liegende Treiber übernimmt die Sequenz für Lese- und Schreibvorgänge.

Standardmäßig arbeitet eine Compute Engine-VM mitHyperdisk mit ausgeglichener Hochverfügbarkeit (Vorschau) im vollständigen Replikationsmodus, wobei gilt: Anfragen zum Lesen oder Schreiben von beiden Laufwerken werden an beide Replikate gesendet.

Im vollständigen Replikationsmodus geschieht Folgendes:

  • Beim Schreiben versucht eine Schreibanfrage, in beide Replikate zu schreiben, und bestätigt, dass beide Schreibvorgänge erfolgreich sind.
  • Beim Lesen sendet die VM eine Leseanfrage an beide Replikate und gibt die Ergebnisse von dem Replikat zurück, das erfolgreich ist. Wenn bei der Leseanfrage eine Zeitüberschreitung auftritt, wird eine weitere Leseanfrage gesendet.

Wenn ein Replikat zurückfällt oder nicht bestätigt, dass die Lese- oder Schreibanfragen abgeschlossen wurden, wird der Replikatstatus aktualisiert.

Systemdiagnosen

Die vom Load-Balancer verwendeten Systemdiagnosen werden vom Systemdiagnose-Agent implementiert. Der Systemdiagnose-Agent hat zwei Zwecke:

  1. Der Systemdiagnose-Agent befindet sich innerhalb der primären VM und der sekundären VM, um die VM-Instanzen zu überwachen und mit dem Load-Balancer bezüglich der Weiterleitung von Traffic zu kommunizieren. Diese Vorgehensweise funktioniert am besten in Verbindung mit Instanzgruppen.
  2. Der Systemdiagnose-Agent wird mit der anwendungsspezifischen regionalen Steuerungsebene synchronisiert und trifft Failover-Entscheidungen, die auf dem Verhalten der Steuerungsebene basieren. Die Steuerungsebene muss sich in einer anderen Zone als die VM-Instanz befinden, deren Status überwacht wird.

Der Systemdiagnose-Agent selbst muss fehlertolerant sein. Beachten Sie beispielsweise in der folgenden Abbildung, dass die Steuerungsebene von der primären VM-Instanz getrennt ist, die sich in der Zone us-central1-a befindet, während sich die Standby-VM in der Zone us-central1-f befindet.

Diagramm: Rolle von Systemdiagnose-Agents in der VM

Die Rolle von Systemdiagnose-Agents in primären VM-Instanzen und Standby-VM-Instanzen

Nächste Schritte