Regionaler nichtflüchtiger Speicher ist eine Speicheroption, mit der Sie Hochverfügbarkeitsdienste in Compute Engine implementieren können. Regionaler nichtflüchtiger Speicher repliziert Daten synchron zwischen zwei Zonen in derselben Region und sorgt für Hochverfügbarkeit bei Laufwerksdaten für bis zu einen Zonenausfall.
In diesem Dokument wird erläutert, wie Sie mit regionalem nichtflüchtigem Speicher HA-Dienste erstellen.
Hochverfügbarkeitsdienste mit regionalem nichtflüchtigem Speicher erstellen
In diesem Abschnitt wird erläutert, wie Sie HA-Dienste mit regionalem nichtflüchtigem Speicher erstellen.
Ü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.
Berücksichtigen Sie beim Planen der Hochverfügbarkeit Folgendes:
- Die Auswirkungen der Verwendung regionaler nichtflüchtiger Speicher oder anderer Lösungen auf die Anwendungsleistung und die Leistung von Laufwerkschreibvorgängen.
- Das Recovery Time Objective des Dienstes. Bestimmen Sie, 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 haben Sie folgende Möglichkeiten für eine 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ür nichtflüchtigen Speicher
- Kosten für die Verwaltung der Anwendungsreplikation
Einzelne VM mit regionalen nichtflüchtigen Speichern verwenden: 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.
Starten Sie die zweite VM erst, wenn ein Failover erforderlich ist. Sie können die Hostkosten zusätzlich senken, indem Sie die Backup-VM nur bei Bedarf während des Failovers starten, anstatt sie als Hot-Standby beizubehalten.
Kosten, Leistung und Ausfallsicherheit vergleichen
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 | 2 | ||
| Kosten | $ |
$$
|
$$
|
1,5 x $ – $$
|
| Anwendungsleistung |
|
|
|
|
| Geeignet für Anwendungen mit niedriger RPO-Anforderung (sehr geringe Toleranz gegenüber Datenverlust) |
|
|
|
|
| Speicherwiederherstellung nach einem Ausfall4 |
|
|
|
|
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, 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 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.
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. Abhängig von Ihren Anforderungen sollten Sie ü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 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 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 bei 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 anhand von 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.
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 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:
|
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 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:
|
| 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. | |
Systemdiagnosen
Die vom Load-Balancer verwendeten Systemdiagnosen werden vom Systemdiagnose-Agent implementiert. Der Systemdiagnose-Agent dient zwei Zwecken:
- 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.
- 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.
Nächste Schritte
- Regionale nichtflüchtige Speicher-Volumes erstellen und verwalten
- Skalierbare und robuste Webanwendungen in Google Cloud erstellen.
- Leitfaden zur Planung der Notfallwiederherstellung