Hochverfügbarkeitsoptionen mit regionalen nichtflüchtigen Speichern

In diesem Dokument wird erläutert, wie Sie mithilfe von regionalen nichtflüchtigen Speichern Hochverfügbarkeitsdienste erstellen, indem Sie verschiedene Optionen zur Erhöhung der Dienstverfügbarkeit sowie Kosten, Leistung und Stabilität für verschiedene Dienstarchitekturen vergleichen. Darüber hinaus werden Fehlertypen und Wiederherstellungsaktionen beschrieben, damit Sie besser entscheiden können, ob regionale nichtflüchtige Speicher die richtige Lösung für Ihren Hochverfügbarkeitsdienst sind.

Regionaler nichtflüchtiger Speicher ist eine Speicheroption, die eine synchrone Replikation von Daten zwischen zwei Zonen in einer Region ermöglicht. Regionale nichtflüchtige Speicher können ein geeigneter Baustein sein, wenn Sie Hochverfügbarkeitsdienste in Compute Engine implementieren.

Regionale nichtflüchtige Speicher haben den Vorteil, dass bei einem zonalen Ausfall, bei dem Ihre VM-Instanz möglicherweise nicht mehr verfügbar ist, das Anhängen eines regionalen nichtflüchtigen Speichers an eine VM-Instanz in einer sekundären Zone erzwungen werden kann. Zum Ausführen dieser Aufgabe haben Sie zwei Möglichkeiten: Entweder Sie starten eine andere VM-Instanz in derselben Zone wie der regionale nichtflüchtige Speicher, dessen Anhängen Sie erzwingen, oder Sie verwalten eine VM-Instanz mit Hot-Standby in dieser Zone. Ein "Hot-Standby" ist eine ausgeführte VM-Instanz, die mit der von Ihnen verwendeten VM-Instanz identisch ist. Die beiden Instanzen haben dieselben Daten.

Der Vorgang zum erzwungenen Anhängen ist nach weniger als einer Minute abgeschlossen, wodurch eine Recovery Time Objective (RTO) in Minuten erreicht wird. Die Gesamt-RTO hängt nicht nur vom Speicher-Failover (dem erzwungenen Anhängen des regionalen nichtflüchtigen Speichers), sondern auch von folgenden Faktoren ab: ob eine sekundäre VM-Instanz zuerst erstellt werden muss, wie lange es dauert, bis das zugrunde liegende Dateisystem ein im "Hot"-Verfahren angehängtes Laufwerk erkennt, die RTO der entsprechenden Anwendungen usw.

Überlegungen zum Design

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 ist, kann es sein, dass die Verwendung von regionalen nichtflüchtigen Speichern oder sogar Snapshots von zonalen nichtflüchtigen Speichern ebenfalls ausgeschlossen sind. 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 nichtflüchtigen Speicher übertragen wurden.

Beachten Sie dabei Folgendes:

  1. Machen Sie sich mit den Auswirkungen auf die Anwendung und die Schreibleistung vertraut.
  2. Legen Sie die RTO des Dienstes fest. Bestimmen Sie, wie schnell Ihr Dienst nach einem zonalen Ausfall wiederhergestellt werden muss, sowie die SLA-Anforderungen.
  3. Informieren Sie sich über die Kosten für die Erstellung einer stabilen und zuverlässigen Dienstarchitektur. In Bezug auf die Kosten haben Sie folgende Möglichkeiten für eine synchrone oder asynchrone Anwendungsreplikation:

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

    • Kosten für VM-Instanz
    • Kosten für nichtflüchtigen Speicher
    • Kosten für die Verwaltung der Anwendungsreplikation

    Wenn Sie mit einem regionalen nichtflüchtigen Speicher Hochverfügbarkeit erreichen möchten, verwenden Sie dieselbe VM-Instanz und dieselben nichtflüchtigen Speicherkomponenten, zusätzlich aber einen regionalen nichtflüchtigen Speicher. Regionale nichtflüchtige Speicher sind pro Byte doppelt so teuer wie zonale nichtflüchtige Speicher, da sie in zwei Zonen repliziert werden.

    Die Verwendung von regionalen nichtflüchtigen Speichern trägt jedoch möglicherweise zu einer Reduzierung der Wartungskosten bei, da die Daten automatisch in zwei Replikate repliziert werden, ohne die Anwendungsreplikation verwalten zu müssen.
    Sie können die Hostkosten zusätzlich senken, indem Sie die Backup-VM nur bei Bedarf während des Failovers starten, anstatt die VM als Hot-Standby 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
nichtflüchtiger Speicher
Anwendungsebene
synchron
Anwendungsebene
asynchron
Hochverfügbarkeitslösung
mit regionalem nichtflüchtigem Speicher
Schützt vor dem Ausfall von Anwendungen, VMs und Zonen1
Minderung der Anwendungsbeschädigung (Beispiel: Intoleranz gegen Anwendungsabsturz)2
Kosten $ $$
2 Instanzen der ausgeführten Datenbank/VM plus Kosten für die Verwaltung und Einrichtung der Anwendungsreplikation und des zonenübergreifenden Netzwerks
$$
2 Instanzen der ausgeführten Datenbank/VM plus Kosten für die Verwaltung und Einrichtung der Anwendungsreplikation und des zonenübergreifenden Netzwerks
$1,5 x – $$
Die Kosten entsprechen der Anwendungsreplikation, wenn Sie einen Hot Standby-Modus verwenden. Sie können niedrigere Kosten erzielen, indem Sie eine Backup-VM nur bei Bedarf während des Failovers hochfahren.
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 (keine Toleranz gegenüber Datenverlust)
Der Datenverlust hängt davon ab, wann der Snapshot erstellt wurde

Kein Datenverlust3

Der Datenverlust nach der Replikation ist asynchron

Kein Datenverlust
Speicherwiederherstellung nach einem Ausfall4 0 (Minuten) 0 (Sekunden) 0 (Sekunden) 0 (Sekunden): Das Anhängen eines Laufwerks an die Standby-VM-Instanz erzwingen

1 Die Verwendung regionaler nichtflüchtiger Speicher oder Snapshots reicht nicht aus, um Ausfälle und Beschädigungen zu verhindern oder zu mindern. Ihre Anwendung, Ihr 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 MySQL-Masteranwendung nicht dazu, dass die Replikatinstanzen 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 regionalen nichtflüchtigen Speichern erstellen

In diesem Abschnitt werden allgemeine Konzepte zum Erstellen von Hochverfügbarkeitslösungen für zustandsorientierte Datenbankdienste (MySQL, Postgres usw.) mit regionalen nichtflüchtigen Speichern und Compute Engine behandelt.

Diese Erläuterungen drehen sich um die Minderung von Ausfällen einzelner Zonen. Eine Anwendung kann auch bei größeren Ausfällen nicht erreichbar sein, beispielsweise wenn eine ganze Region nicht mehr verfügbar ist. Abhängig von Ihren Anforderungen sollten Sie möglicherweise überregionale Replikationstechniken in Betracht ziehen, um eine noch höhere Verfügbarkeit zu erreichen.

Hochverfügbarkeitskonfigurationen für Datenbanken haben in der Regel mindestens zwei VM-Instanzen. Vorzugsweise sind diese 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 nichtflüchtige Speicher: ein Bootlaufwerk und einen regionalen nichtflüchtigen Speicher. Der regionale nichtflüchtige 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 aus konfigurationsbedingten Ausfällen zu ermöglichen, die beispielsweise durch ein Betriebssystem-Upgrade verursacht wurden. Sie können 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 basierend auf Signalen der Systemdiagnose an die primäre VM weitergeleitet wird. Diese Konfiguration wird auch als Hot-Standby bezeichnet. Das Notfallwiederherstellungsszenario für Daten beschreibt andere Failover-Konfigurationen, die für Ihr Szenario möglicherweise geeigneter sind.

Systemdiagnosen

Systemdiagnosen werden vom Systemdiagnose-Agent implementiert und dienen den folgenden Zwecken:

  1. Der Systemdiagnose-Agent befindet sich innerhalb der primären VM und der sekundären VM, um die Instanzen zu überwachen und mit dem Load-Balancer bezüglich der Weiterleitung von Traffic zu kommunizieren. Dies ist besonders nützlich bei 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 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 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.

Rolle von Systemdiagnose-Agents in der VM

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

Failover

Wenn ein Fehler in einer primären VM oder in der Datenbank erkannt wird, kann die Steuerungsebene der Anwendung ein Failover zur Standby-VM in der sekundären Zone initiieren. Während des Failovers wird der regionale nichtflüchtige Speicher, der synchron zur sekundären Zone repliziert wird, von der Steuerungsebene der Anwendung zwangsweise an die Standby-VM angehängt. Der gesamte Traffic wird dann basierend auf Signalen der Systemdiagnose an diese VM weitergeleitet.

Die Failover-Gesamtlatenz ohne die Fehlererkennungszeit ist die Summe der folgenden Latenzen:

  • Null Sekunden, um das Anhängen eines regionalen nichtflüchtigen Speichers an eine Standby-VM zu erzwingen
  • Zeit, die für die Initialisierung der Anwendung und die Wiederherstellung nach einem Absturz erforderlich ist

Auf der Seite Bausteine der Notfallwiederherstellung werden die Bausteine behandelt, die derzeit in Compute Engine verfügbar sind. Regionale nichtflüchtige Speicher stellen einen weiteren wichtigen Baustein der Architektur von Hochverfügbarkeitslösungen dar, da sie Replikation auf Laufwerksebene ermöglichen.

Fehlermodi

In der folgenden Tabelle sind die verschiedenen Fehlermodi und empfohlenen Aktionen für Dienste aufgeführt, die regionale nichtflüchtige Speicher verwenden.

Fehlerkategorie (und -wahrscheinlichkeit) Fehlertypen Aktion
Zonenfehler (mittlere Priorität) Fehler nur in der lokalen Zone. Ausfälle können entweder vorübergehend sein oder lang andauern.



Compute Engine-Steuerungsebene
Stromausfall
Netzwerkfehler

Vorübergehende Engpässe bei regionalen Laufwerksvorgängen werden transparent von einem nichtflüchtigen regionalen Speicher ohne Failover verarbeitet. Ein nichtflüchtiger regionaler Speicher erkennt automatisch Fehler und Verzögerungen, wechselt zwischen Replikationsmodi und aktualisiert Daten, die nur in einer Zone repliziert wurden.

Bei Speicherproblemen in einer primären Zone führt ein regionaler nichtflüchtiger Speicher automatisch Lesevorgänge aus einer sekundären Zone aus. Dies kann zu einer erhöhten Latenz von Lesevorgängen führen. Unter diesen Umständen kann von der Anwendung ein Failover aufgrund der Auswirkungen auf die Leistung ausgelöst werden.



Die Steuerungsebene der Anwendung kann basierend auf Schwellenwerten der Systemdiagnose ein Failover auslösen.
Anwendungsfehler (hohe Priorität) Anwendung reagiert nicht
Aktionen des Anwendungsadministrators (z. B. Upgrade) Menschlicher Fehler
(z. B. fehlerhafte Konfiguration von Parametern wie SSL-Zertifikat oder ACLs)
Die Steuerungsebene der Anwendung kann basierend auf Schwellenwerten der Systemdiagnose ein Failover auslösen.
VM-Fehler (mittlere Priorität) Infrastruktur- / Hardwarefehler
VM reagiert aufgrund von CPU-Konflikten und Netzwerkunterbrechungen nicht
VMs werden in der Regel automatisch repariert. Die Steuerungsebene der Anwendung kann ein Failover basierend auf Schwellenwerten der Systemdiagnose auslösen.
Anwendungsfehler (niedrige bis mittlere Priorität) Beschädigung der Anwendungsdaten
(z. B. aufgrund von Anwendungsfehlern oder eines fehlerhaften Betriebssystem-Upgrades)
Wiederherstellung von Anwendungen:

Herausforderungen bei der Datenbankreplikation

In der folgenden Tabelle sind einige häufige Probleme bei der Einrichtung und Verwaltung der synchronen oder halbsynchronen Anwendungsreplikation (z. B. MySQL) im Vergleich zur Blockreplikation mit regionalen nichtflüchtigen Speichern aufgeführt.

Probleme Anwendung synchron
oder halb-synchrone Replikation
Blockierung der Replikation mit
regionalen nichtflüchtigen Speichern
Stabile Replikation zwischen Master- und Failover-Replikat aufrechterhalten Es können eine Reihe von Problemen auftreten, die dazu führen können, dass eine Instanz den Hochverfügbarkeitsmodus nicht mehr gewährleistet:
  1. Fehlkonfiguration der Replikationsparameter, z. B. nicht übereinstimmende SSL-Zertifikate oder fehlende ACLs auf der Masterseite
  2. Hohe Last auf der Masterinstanz, 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
Speicherausfälle werden von regionalen nichtflüchtigen Speichern 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 zu erkennen und Failover auszulösen.
End-to-End-Failover-Zeit ist länger als gewünscht Die für den Failover-Vorgang benötigte Zeit hat keine Obergrenze. Das Warten auf die Wiederholung aller Transaktionen (Schritt 2 oben) kann je nach Schema und Auslastung der Datenbank beliebig lange dauern. Regionale nichtflüchtige Speicher ermöglichen eine synchrone Replikation, sodass die Failover-Zeit durch die Summe der folgenden Latenzen begrenzt wird:
  1. Eine sekundäre VM erstellen, wenn nicht bereits eine Hot-Standby-VM-Instanz verfügbar ist
  2. Das Anhängen eines regionalen nichtflüchtigen Speichers erzwingen
  3. Anwendungsinitialisierung
Split-Brain Beide Ansätze erfordern Maßnahmen, die dafür sorgen, dass jeweils nur ein Master vorhanden ist, um Split-Brain zu vermeiden.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

Compute Engine-Dokumentation