Szenarien der Notfallwiederherstellung von Anwendungen

Last reviewed 2024-08-05 UTC

Dieses Dokument ist Teil einer Reihe zur Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloud. In diesem Teil werden allgemeine Szenarien der Notfallwiederherstellung für Anwendungen behandelt.

Die Reihe besteht aus folgenden Teilen:

Einführung

In diesem Dokument werden DR-Szenarien für Anwendungen im Hinblick auf DR-Muster beschrieben, die angeben, wie schnell die Anwendung nach einem Notfall wiederhergestellt werden kann. Der Artikel basiert auf den im Artikel Bausteine für die Notfallwiederherstellung dargestellten Konzepten und erläutert, wie Sie einen für Ihre Wiederherstellungsziele geeigneten End-to-End-DR-Plan implementieren.

Als Erstes wird anhand einiger typischer Arbeitslasten gezeigt, wie sich Wiederherstellungsziele und deren Architektur direkt auf Ihren DR-Plan auswirken.

Arbeitslasten der Batchverarbeitung

Arbeitslasten der Batchverarbeitung sind in der Regel nicht geschäftskritisch. Daher sind normalerweise keine Kosten für eine Hochverfügbarkeitsarchitektur erforderlich, um die Betriebszeit zu maximieren. Im Allgemeinen können Arbeitslasten der Batchverarbeitung Unterbrechungen bewältigen. Für diese Art von Arbeitslast können kostengünstige Produkte wie Spot-VMs und VM-Instanzen auf Abruf verwendet werden. Diese Instanzen können Sie zu einem viel niedrigeren Preis als normale Instanzen erstellen und ausführen. (Compute Engine kann diese Instanzen jedoch vorzeitig beenden oder löschen, wenn für andere Aufgaben Zugriff auf diese Ressourcen benötigt wird.

Durch Implementierung regelmäßiger Prüfpunkte im Rahmen der Verarbeitung kann, wenn neue VMs gestartet werden, der verarbeitete Job ab dem Zeitpunkt des Ausfalls wieder aufgenommen werden. Wenn Sie Managed Service for Apache Spark verwenden, wird das Starten von Worker-Knoten auf Abruf von einer verwalteten Instanzgruppe verwaltet. Dies wird als "warmes Muster" (Warm Pattern) bezeichnet, bei dem einen kurzen Moment lang auf die Verarbeitung durch die Ersatz-VMs gewartet werden muss.

E-Commerce-Websites

Bei E-Commerce-Websites haben Sie die Möglichkeit, für Teile der Anwendung höhere RTO-Werte (Recovery Time Objective, Wiederherstellungsdauer) anzusetzen. Beispielsweise muss die eigentliche Kaufpipeline eine hohe Verfügbarkeit haben, aber der E-Mail-Prozess, der Bestellbenachrichtigungen an Kunden sendet, kann eine Verzögerung von einigen Stunden tolerieren. Die Kunden wissen über ihren Kauf ja bereits Bescheid, d. h., sie erwarten zwar eine Bestätigungs-E-Mail, die Benachrichtigung ist aber für die Ausführung der Bestellung nicht ausschlaggebend. Dies ist eine Mischung aus einem heißen (Kauf) und einem warmen und kalten (Benachrichtigung) Muster.

Der Transaktionsteil der Anwendung erfordert eine hohe Verfügbarkeit mit einem möglichst niedrigen RTO-Wert. Deshalb wird mit der HA die Verfügbarkeit dieses Teils der Anwendung maximiert. Dieser Ansatz wird als "heißes Muster" bezeichnet.

Das E-Commerce-Szenario ist ein Beispiel dafür, wie innerhalb einer Anwendung unterschiedliche RTO-Werte vorhanden sein können.

Video-Streaming

Eine Video-Streaming-Lösung hat viele Komponenten, die hochverfügbar sein müssen – von der Suchfunktion bis zum tatsächlichen Streaming von Inhalten an den Nutzer. Darüber hinaus erfordert das System eine niedrige Latenz, damit die Akzeptanz durch die Nutzer gewährleistet ist. Wenn auch nur ein Aspekt der Lösung suboptimal ist, kann dies schon zu Unzufriedenheit sowohl beim Anbieter als auch beim Kunden führen. Kunden haben heutzutage die Möglichkeit, zu einem Konkurrenzprodukt zu wechseln.

In einem solchen Szenario ist eine HA-Architektur unverzichtbar. Außerdem sind niedrige RTO-Werte erforderlich. Dieses Szenario benötigt für die gesamte Anwendungsarchitektur ein heißes Muster, damit die Auswirkungen im Notfall auf ein Mindestmaß beschränkt werden können.

DR- und HA-Architekturen für eine lokale Produktion

In diesem Abschnitt wird beschrieben, wie Sie drei Muster – kalt, warm und heiß – implementieren, wenn Ihre Anwendung lokal ausgeführt wird und sich Ihre DR-Lösung inGoogle Cloudbefindet.

Kaltes Muster: Wiederherstellung in Google Cloud

Bei einem kalten Muster haben Sie nur minimale Ressourcen im DR-Projekt von Google Cloud, gerade genug, um ein Wiederherstellungsszenario zu ermöglichen. Wenn ein Problem auftritt, das verhindert, dass die Produktionsumgebung Produktionsarbeitslasten ausführt, muss die Failover-Strategie einen Spiegel der Produktionsumgebung in Google Cloudstarten. Die Clients verwenden dann die Dienste aus der DR-Umgebung.

Dieser Abschnitt zeigt im Detail ein Beispiel für dieses Muster. In diesem Beispiel ist Cloud Interconnect mit einer selbstverwalteten (nicht-Google Cloud) VPN-Lösung konfiguriert, um eine Verbindung zu Google Cloudherzustellen. Die Daten werden als Teil der Produktionsumgebung in Cloud Storage kopiert.

Bei diesem Muster werden die folgenden DR-Bausteine verwendet:

  • Cloud DNS
  • Cloud Interconnect
  • Selbstverwaltete VPN-Lösung
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

Diese Beispielarchitektur wird im folgenden Diagramm veranschaulicht:

Architektur für kalte Muster bei lokaler Produktion

Mit den folgenden Schritten können Sie eine solche Umgebung konfigurieren:

  1. Erstellen Sie ein VPC-Netzwerk.
  2. Konfigurieren Sie die Verbindung zwischen Ihrem lokalen Netzwerk und dem Google Cloud -Netzwerk.
  3. Erstellen Sie einen Cloud Storage-Bucket als Ziel für die Datensicherung.
  4. Erstellen Sie ein Dienstkonto.
  5. Erstellen Sie eine IAM-Richtlinie zur Einschränkung des Zugriffs auf den Bucket und seine Objekte. Erteilen Sie dabei dem speziell für diesen Zweck erstellten Dienstkonto und einem lokalen Operatorkonto den Zugriff. Fügen Sie zur Richtlinie für Ihren Operator oder Systemadministrator auch das Nutzerkonto oder die Nutzergruppe hinzu und erteilen Sie diesen Identitäten die entsprechenden Berechtigungen. Weitere Informationen zu Berechtigungen für den Zugriff auf Cloud Storage finden Sie unter IAM-Berechtigungen für Cloud Storage.
  6. Mit der Identitätsübernahme des Dienstkontos gewähren Sie Ihrem lokalen Google Cloud-Nutzer (oder Dienstkonto) Zugriff, um sich als das zuvor erstellte Dienstkonto auszugeben. Alternativ können Sie einen neuen Nutzer speziell für diesen Zweck erstellen.
  7. Testen Sie, ob Sie Dateien in den Ziel-Bucket hochladen und von dort herunterladen können.
  8. Erstellen Sie ein Datenübertragungsscript.
  9. Erstellen Sie eine geplante Aufgabe für die Ausführung des Skripts. Sie können Tools wie Linux crontab und den Windows-Aufgabenplaner verwenden.

  10. Erstellen Sie benutzerdefinierte Images, die für jeden Server in der Produktionsumgebung konfiguriert sind. Jedes Image muss genauso konfiguriert sein wie sein lokales Äquivalent.

    Erstellen Sie im Rahmen der benutzerdefinierten Image-Konfiguration für den Datenbankserver ein Startskript, das die neueste Sicherung automatisch aus einem Cloud Storage-Bucket in die Instanz kopiert und dann den Wiederherstellungsprozess aufruft.

  11. Konfigurieren Sie Cloud DNS so, dass es auf Ihre Webdienste im Internet verweist.

  12. Erstellen Sie eine Deployment Manager-Vorlage, die in Ihrem Google Cloud -Netzwerk Anwendungsserver mithilfe der zuvor konfigurierten benutzerdefinierten Images erstellt. Mit dieser Vorlage müssen auch die erforderlichen Firewallregeln eingerichtet werden.

Es müssen entsprechende Prozesse implementiert werden, die gewährleisten, dass die benutzerdefinierten Images die gleiche Anwendungsversion haben wie die lokale Version. Achten Sie darauf, dass im Rahmen des Standardaktualisierungszyklus Upgrades für die benutzerdefinierten Images ausgeführt werden und in der Deployment Manager-Vorlage das neueste benutzerdefinierte Image verwendet wird.

Failover-Vorgang und Aufgaben nach dem Neustart

Im Notfall können Sie das System wiederherstellen, das aufGoogle Cloudausgeführt wird. Starten Sie dazu den Wiederherstellungsprozess, um die Wiederherstellungsumgebung auf der Grundlage der von Ihnen erstellten Deployment Manager-Vorlage zu erstellen. Wenn die Instanzen in der Wiederherstellungsumgebung bereit sind, Produktionstraffic zu akzeptieren, passen Sie das DNS so an, dass es auf den Webserver inGoogle Cloudverweist.

Im Folgenden wird ein typischer Wiederherstellungsablauf dargestellt:

  1. Verwenden Sie die Deployment Manager-Vorlage, um inGoogle Cloudeine Bereitstellung vorzunehmen.
  2. Wenden Sie die neueste Datenbanksicherung in Cloud Storage auf den in Google Cloud ausgeführten Datenbankserver an. Folgen Sie dazu der Anleitung Ihres Datenbanksystems zur Wiederherstellung von Sicherungsdateien.
  3. Übernehmen Sie die neuesten Transaktionslogs in Cloud Storage.
  4. Testen Sie, ob die Anwendung wie erwartet funktioniert. Simulieren Sie dazu Nutzerszenarien in der wiederhergestellten Umgebung.
  5. Wenn die Tests erfolgreich sind, konfigurieren Sie Cloud DNS so, dass es auf den Webserver in Google Cloudverweist. Sie können beispielsweise eine Anycast-IP-Adresse hinter einem Google Cloud -Load-Balancer mit mehreren Webservern hinter dem Load-Balancer verwenden.

Das folgende Diagramm zeigt die wiederhergestellte Umgebung:

Konfiguration eines kalten Musters für die Wiederherstellung bei lokaler Produktion

Wenn die Produktionsumgebung wieder lokal ausgeführt wird und die Umgebung Produktionsarbeitslasten verarbeiten kann, führen Sie die Schritte zum Failover in die Google Cloud -Wiederherstellungsumgebung in umgekehrter Reihenfolge aus. Im Folgenden ist eine typische Abfolge für die Rückkehr zur Produktionsumgebung aufgeführt:

  1. Sichern Sie die Datenbank, die auf Google Cloudausgeführt wird.
  2. Kopieren Sie die Sicherungsdatei in Ihre Produktionsumgebung.
  3. Übernehmen Sie die Sicherungsdatei für Ihr Produktionsdatenbanksystem.
  4. Verbindungen zur Anwendung in Google Cloudverhindern. Sie können beispielsweise Verbindungen zum globalen Load-Balancer sperren. Ab diesem Zeitpunkt ist Ihre Anwendung bis zur Wiederherstellung der Produktionsumgebung nicht verfügbar.
  5. Kopieren Sie alle Transaktions-Log-Dateien in die Produktionsumgebung und übernehmen Sie diese in den Datenbankserver.
  6. Konfigurieren Sie Cloud DNS so, dass es auf Ihren lokalen Webdienst verweist.
  7. Prüfen Sie, ob das Kopieren von Daten nach Cloud Storage wie erwartet funktioniert.
  8. Löschen Sie Ihr Deployment.

Warmer Standby: Wiederherstellung in Google Cloud

In der Regel wird ein warmes Muster implementiert, wenn die RTO- und RPO-Werte ohne Aufwand und Kosten für eine komplette HA-Konfiguration so niedrig wie möglich sein sollen. Je niedriger ein RTO- oder ein RPO-Wert ist, desto höher sind die Kosten bei einer vollständig redundanten Umgebung, bei der der Traffic von zwei Umgebungen übernommen wird. Die Implementierung eines warmen Musters für das DR-Szenario ist deshalb ein guter Kompromiss zwischen Kosten und Verfügbarkeit.

Ein Beispiel für diesen Ansatz ist die Verwendung von Cloud Interconnect, das mit einer selbstverwalteten VPN-Lösung konfiguriert ist, um eine Verbindung zu Google Cloudherzustellen. Eine mehrstufige Anwendung wird lokal ausgeführt, während eine minimale Wiederherstellungssuite in Google Cloudverwendet wird. Die Wiederherstellungssuite besteht aus einer betriebsbereiten Datenbankserverinstanz auf Google Cloud. Diese Instanz muss permanent ausgeführt werden, damit sie replizierte Transaktionen über asynchrone oder halbsynchrone Replikationstechniken empfangen kann. Zur Senkung der Kosten können Sie die Datenbank auf dem kleinsten Maschinentyp ausführen, mit dem sich der Datenbankdienst ausführen lässt. Da Sie eine langlebige Instanz verwenden können, werden Rabatte für kontinuierliche Nutzung gewährt.

Bei diesem Muster werden die folgenden DR-Bausteine verwendet:

  • Cloud DNS
  • Cloud Interconnect
  • Selbstverwaltete VPN-Lösung
  • Compute Engine
  • Deployment Manager

Compute Engine-Snapshots ermöglichen die Verwendung von Sicherungen, mit denen sich ein früherer Status wiederherstellen lässt. In diesem Beispiel sind Snapshots hilfreich, da häufig aktualisierte Webseiten und Anwendungsbinärdateien in das Produktionswebsystem und auf Anwendungsserver geschrieben werden. Diese Aktualisierungen werden regelmäßig auf die Referenz-Webserver- und Anwendungsserverinstanzen in Google Cloudrepliziert. Die Referenzserver übernehmen dabei keinen Produktionstraffic. Sie werden nur zum Erstellen der Snapshots verwendet.

Das im Folgenden aufgeführte Diagramm veranschaulicht eine Architektur, die diesen Ansatz implementiert. Die Replikationsziele werden nicht im Diagramm angezeigt.

Architektur für ein warmes Muster bei lokaler Produktion

Mit den folgenden Schritten können Sie eine solche Umgebung konfigurieren:

  1. Erstellen Sie ein VPC-Netzwerk.
  2. Konfigurieren Sie die Verbindung zwischen Ihrem lokalen Netzwerk und dem Google Cloud -Netzwerk.
  3. Replizieren Sie Ihre lokalen Server auf Google Cloud -VM-Instanzen. Dafür können Sie eine Partnerlösung verwenden. Die jeweils passende Methode hängt von den jeweiligen Bedingungen ab.
  4. Erstellen Sie ein benutzerdefiniertes Image Ihres Datenbankservers in Google Cloud , das dieselbe Konfiguration wie Ihr lokaler Datenbankserver hat.
  5. Erstellen Sie Snapshots der Instanzen von Webserver und Anwendungsserver.
  6. Starten Sie eine Datenbankinstanz in Google Cloud mit dem zuvor erstellten benutzerdefinierten Image. Verwenden Sie den kleinsten Maschinentyp, mit dem sich replizierte Daten aus der lokalen Produktionsdatenbank übernehmen lassen.
  7. Hängen Sie nichtflüchtige Speicher an die Google Cloud -Datenbankinstanz für die Datenbanken und Transaktionslogs an.
  8. Konfigurieren Sie die Replikation zwischen Ihrem lokalen Datenbankserver und dem Datenbankserver in Google Cloud . Folgen Sie dazu der Anleitung für Ihre Datenbanksoftware.
  9. Setzen Sie für die nichtflüchtigen Speicher, die an die Datenbankinstanz angehängt sind, das Flag zum automatischen Löschen auf no-auto-delete.
  10. Konfigurieren Sie eine geplante Aufgabe, um von den nichtflüchtigen Speichern der Datenbankinstanz regelmäßig Snapshots in Google Cloudzu erstellen.
  11. Erstellen Sie Reservierungen, um die Kapazität für Ihren Webserver und Ihre Anwendungsserver nach Bedarf sicherzustellen.
  12. Testen Sie das Erstellen von Instanzen aus Snapshots und das Erstellen von Snapshots der nichtflüchtigen Speicher.
  13. Erstellen Sie Instanzen des Webservers und des Anwendungsservers mithilfe der zuvor angelegten Snapshots.
  14. Erstellen Sie ein Skript, mit dem Aktualisierungen in die Webanwendung und in den Anwendungsserver kopiert werden, wenn die entsprechenden lokalen Server aktualisiert werden. Schreiben Sie ein Skript zum Erstellen eines Snapshots des aktualisierten Servers.
  15. Konfigurieren Sie Cloud DNS so, dass es auf den lokalen Webdienst für das Internet verweist.

Failover-Vorgang und Aufgaben nach dem Neustart

Zur Verwaltung eines Failovers verwenden Sie in der Regel ein Monitoring- und Benachrichtigungssystem, mit dem ein automatisiertes Failover gestartet wird. Wenn die lokale Anwendung ein Failover ausführen muss, konfigurieren Sie das Datenbanksystem in Google Cloud so, dass es Produktionstraffic akzeptieren kann. Außerdem müssen Sie Instanzen des Web- und Anwendungsservers starten.

Das folgende Diagramm zeigt die Konfiguration nach dem Failover aufGoogle Cloud , sodass Produktionsarbeitslasten vonGoogle Cloudbereitgestellt werden können:

Konfiguration eines warmen Musters für die Wiederherstellung bei lokaler Produktion

Im Folgenden wird ein typischer Wiederherstellungsablauf dargestellt:

  1. Ändern Sie die Größe der Datenbankserverinstanz so, dass darauf Produktionsarbeitslasten verarbeitet werden können.
  2. Verwenden Sie die Webserver- und Anwendungs-Snapshots in Google Cloud, um neue Webserver- und Anwendungsinstanzen zu erstellen.
  3. Testen Sie, ob die Anwendung wie erwartet funktioniert. Simulieren Sie dazu Nutzerszenarien in der wiederhergestellten Umgebung.
  4. Wenn die Tests erfolgreich sind, konfigurieren Sie Cloud DNS so, dass es auf Ihren Webdienst in Google Cloudverweist.

Wenn die Produktionsumgebung wieder lokal ausgeführt wird und Produktionsarbeitslasten verarbeiten kann, führen Sie die Schritte zum Failover in die Google Cloud -Wiederherstellungsumgebung in umgekehrter Reihenfolge aus. Im Folgenden ist eine typische Abfolge für die Rückkehr zur Produktionsumgebung aufgeführt:

  1. Sichern Sie die Datenbank, die auf Google Cloudausgeführt wird.
  2. Kopieren Sie die Sicherungsdatei in Ihre Produktionsumgebung.
  3. Übernehmen Sie die Sicherungsdatei für Ihr Produktionsdatenbanksystem.
  4. Verbindungen zur Anwendung in Google Cloudverhindern. Eine Möglichkeit besteht darin, Verbindungen zum Webserver zu verhindern, indem Sie die Firewallregeln ändern. Ab dann ist Ihre Anwendung bis zur Wiederherstellung der Produktionsumgebung nicht verfügbar.
  5. Kopieren Sie alle Transaktions-Logdateien in die Produktionsumgebung und übernehmen Sie diese in den Datenbankserver.
  6. Testen Sie, ob die Anwendung wie erwartet funktioniert. Simulieren Sie dazu Nutzerszenarien in der Produktionsumgebung.
  7. Konfigurieren Sie Cloud DNS so, dass es auf Ihren lokalen Webdienst verweist.
  8. Löschen Sie die Webserver- und Anwendungsserverinstanzen, die inGoogle Cloudausgeführt werden. Lassen Sie die Referenzserver laufen.
  9. Ändern Sie die Größe des Datenbankservers in Google Cloud auf die Mindestinstanzgröße, die replizierte Daten aus der lokalen Produktionsdatenbank akzeptieren kann.
  10. Konfigurieren Sie die Replikation zwischen Ihrem lokalen Datenbankserver und dem Datenbankserver in Google Cloud . Folgen Sie dazu der Anleitung für Ihre Datenbanksoftware.

Hot-HA für lokale und Google Cloud

Wenn Sie kleine RTO- und RPO-Werte haben, können Sie diese nur erreichen, wenn Sie Hochverfügbarkeit in Ihrer Produktionsumgebung und gleichzeitig in Google Cloud ausführen. Dieser Ansatz bietet Ihnen ein Hot-Muster, da sowohl die lokale Umgebung als auch Google CloudProduktionstraffic verarbeiten.

Der Hauptunterschied zum warmen Muster besteht darin, dass die Ressourcen in beiden Umgebungen im Produktionsmodus ausgeführt werden und Produktionstraffic übernehmen.

Bei diesem Muster werden die folgenden DR-Bausteine verwendet:

  • Cloud Interconnect
  • Cloud VPN
  • Compute Engine
  • Verwaltete Instanzgruppen
  • Cloud Monitoring
  • Cloud Load Balancing

Diese Beispielarchitektur wird im folgenden Diagramm veranschaulicht. Die Implementierung dieser Architektur ermöglicht einen DR-Plan, der im Notfall nur einen minimalen Eingriff erfordert.

Architektur für ein heißes Muster bei lokaler Produktion

Mit den folgenden Schritten können Sie eine solche Umgebung konfigurieren:

  1. Erstellen Sie ein VPC-Netzwerk.
  2. Konfigurieren Sie die Verbindung zwischen Ihrem lokalen Netzwerk und Ihrem Google Cloud -Netzwerk.
  3. Erstellen Sie in Google Cloud benutzerdefinierte Images, die für jeden Server in der lokalen Produktionsumgebung konfiguriert sind. Jedes Google Cloud -Image sollte dieselbe Konfiguration haben wie sein lokales Äquivalent.

  4. Konfigurieren Sie die Replikation zwischen Ihrem lokalen Datenbankserver und dem Datenbankserver in Google Cloud . Folgen Sie dazu der Anleitung für Ihre Datenbanksoftware.

    Viele Datenbanksysteme erlauben nur eine einzige beschreibbare Datenbankinstanz für die Konfiguration der Replikation. Daher müssen Sie möglicherweise dafür sorgen, dass eines der Datenbankreplikate als schreibgeschützter Server verwendet wird.

  5. Erstellen Sie individuelle Instanzvorlagen, die die Images für die Anwendungs- und die Webserver verwenden.

  6. Konfigurieren Sie regionale verwaltete Instanzgruppen für die Anwendungs- und Webserver.

  7. Konfigurieren Sie Systemdiagnosen mit Cloud Monitoring.

  8. Konfigurieren Sie den Load-Balancer mithilfe der zuvor konfigurierten regionalen verwalteten Instanzgruppen.

  9. Konfigurieren Sie eine geplante Aufgabe zum Erstellen regelmäßiger Snapshots nichtflüchtiger Speicher.

  10. Konfigurieren Sie einen DNS-Dienst, um den Traffic zwischen Ihrer lokalen Umgebung und der Google Cloud -Umgebung zu verteilen.

Für diesen hybriden Ansatz benötigen Sie einen DNS-Dienst, der das gewichtete Routing zu den beiden Produktionsumgebungen unterstützt. Dies ist die Voraussetzung dafür, dass eine Anwendung von beiden Umgebungen aus bedient werden kann.

Sie müssen das System auch für Fehler konfigurieren, die eventuell nur in einem Teil einer Umgebung auftreten (Teilfehler). In diesem Fall muss der Traffic zum entsprechenden Dienst in der anderen Sicherungsumgebung umgeleitet werden. Wenn beispielsweise die lokalen Webserver nicht mehr verfügbar sind, können Sie das DNS-Routing in diese Umgebung deaktivieren. Unterstützt Ihr DNS-Dienst Systemdiagnosen, erfolgt dies automatisch, wenn bei der Systemdiagnose festgestellt wird, dass Webserver in einer der Umgebungen nicht mehr erreichbar sind.

Wenn Sie ein Datenbanksystem verwenden, das nur eine einzige beschreibbare Instanz zulässt, wird das schreibgeschützte Replikat in vielen Fällen automatisch als beschreibbare Primärdatenbank hochgestuft, wenn der Heartbeat zwischen der ursprünglichen beschreibbaren Datenbank und dem Lesereplikat unterbrochen wird. Beachten Sie diesen Aspekt der Datenbankreplikation, wenn Sie nach einem Notfall eingreifen müssen.

Sie müssen Prozesse implementieren, um sicherzustellen, dass die benutzerdefinierten VM-Images inGoogle Cloud dieselbe Version der Anwendung haben wie die lokalen Versionen. Binden Sie dazu Upgrades der benutzerdefinierten Images in den Standardaktualisierungszyklus ein. Sorgen Sie dafür, dass Ihre Deployment Manager-Vorlage das neueste benutzerdefinierte Image verwendet.

Failover-Vorgang und Aufgaben nach dem Neustart

Die im Folgenden beschriebene Konfiguration eines heißen Szenarios gilt für einen Notfall, bei dem eine der beiden Umgebungen nicht verfügbar ist. Es findet hier kein Failover wie bei warmen oder kalten Szenarien statt, bei denen Daten oder die Verarbeitung in die zweite Umgebung verschoben werden müssen. Möglicherweise müssen Sie aber die folgenden Änderungen an der Konfiguration vornehmen:

  • Wenn Ihr DNS-Dienst den Traffic bei einem Fehler der Systemdiagnose nicht automatisch umleitet, müssen Sie das DNS-Routing manuell konfigurieren, um den Traffic an das System zu senden, das noch aktiv ist.
  • Wenn Ihr Datenbanksystem im Fehlerfall ein schreibgeschütztes Replikat nicht automatisch als beschreibbare Primärdatenbank hochstuft, müssen Sie das Replikat manuell hochstufen

Wenn die zweite Umgebung wieder ausgeführt wird und den Produktionstraffic verarbeitet, müssen Sie die Datenbanken synchronisieren. Da beide Umgebungen Produktionsarbeitslasten unterstützen, muss keine Datenbank als primäre Datenbank festgelegt werden. Nach der Synchronisation der Datenbanken kann der Produktionstraffic wieder auf beide Umgebungen verteilt werden. Dazu müssen Sie die DNS-Einstellungen entsprechend anpassen.

DR- und HA-Architekturen für die Produktion in Google Cloud

Wenn Sie Ihre Anwendungsarchitektur für die Produktionsarbeitslast inGoogle Cloudentwerfen, haben die HA-Funktionen der Plattform einen direkten Einfluss auf Ihre DR-Architektur.

Der Backup- und DR-Dienst ist eine zentrale, cloudnative Lösung zum Sichern und Wiederherstellen von Cloud- und Hybrid-Arbeitslasten. Er ermöglicht eine schnelle Datenwiederherstellung und erleichtert die schnelle Wiederaufnahme wichtiger Geschäftsabläufe.

Weitere Informationen zur Verwendung des Backup- und DR-Dienstes für Anwendungsszenarien inGoogle Cloudfinden Sie unter:

Kaltes Szenario: wiederherstellbarer Anwendungsserver

Bei einem kalten Failover-Szenario, bei dem eine einzelne aktive Serverinstanz benötigt wird, sollte nur eine Instanz auf das Laufwerk schreiben. In einer lokalen Umgebung verwenden Sie häufig einen Aktiv/Passiv-Cluster. Wenn Sie eine Produktionsumgebung inGoogle Cloudausführen, können Sie eine VM in einer verwalteten Instanzgruppe erstellen, die nur eine Instanz ausführt.

Bei diesem Muster werden die folgenden DR-Bausteine verwendet:

  • Compute Engine
  • Verwaltete Instanzgruppen

Dieses kalte Failover-Szenario ist in der folgenden Beispielarchitekturbild dargestellt:

Konfiguration eines kalten Musters für die Wiederherstellung bei Produktion in Google Cloud

Mit folgenden Schritten können Sie ein solches Szenario für ein kaltes Failover konfigurieren:

  1. Erstellen Sie ein VPC-Netzwerk.
  2. Erstellen Sie ein benutzerdefiniertes VM-Image, das mit Ihrem Anwendungswebdienst konfiguriert ist.
    1. Konfigurieren Sie die VM so, dass die vom Anwendungsdienst verarbeiteten Daten auf einen angehängten nichtflüchtigen Speicher geschrieben werden.
  3. Erstellen Sie einen Snapshot vom hinzugefügten nichtflüchtigen Speicher.
  4. Erstellen Sie eine Instanzvorlage, die auf das benutzerdefinierte VM-Image für den Webserver verweist.
    1. Konfigurieren Sie ein Startscript, das einen nichtflüchtigen Speicher aus dem letzten Snapshot erstellt und das Laufwerk bereitstellt. Dieses Script muss den neuesten Snapshot des Laufwerks abrufen können.
  5. Erstellen Sie eine verwaltete Instanzgruppe und Systemdiagnosen mit einer Zielgröße von Eins, die auf die Instanzvorlage verweist.
  6. Erstellen Sie eine geplante Aufgabe zum Erstellen von regelmäßigen Snapshots des nichtflüchtigen Speichers.
  7. Konfigurieren Sie einen externen Application Load Balancer.
  8. Konfigurieren Sie Benachrichtigungen mit Cloud Monitoring, um eine Warnung zu senden, wenn der Dienst fehlschlägt.

In diesem kalten Failover-Szenario werden einige der in Google Cloudverfügbaren HA-Funktionen genutzt. Wenn eine VM ausfällt, versucht die verwaltete Instanzgruppe automatisch, die VM neu zu erstellen. Sie müssen diesen Failover-Schritt nicht initiieren. Der externe Application Load Balancer stellt sicher, dass auch dann, wenn eine Ersatz-VM benötigt wird, die gleiche IP-Adresse vor dem Anwendungsserver verwendet wird. Die Instanzvorlage und das benutzerdefinierte Image garantieren, dass die Ersatz-VM identisch mit der Instanz ist, die sie ersetzt.

Der RPO-Wert wird durch den zuletzt aufgenommenen Snapshot bestimmt. Je häufiger Sie Snapshots erstellen, desto kleiner ist der RPO-Wert.

Die verwaltete Instanzgruppe ermöglicht eine umfassende Hochverfügbarkeit. Die verwaltete Instanzgruppe bietet Optionen, um auf Fehler auf Anwendungs- oder VM-Ebene zu reagieren. Bei Eintreten eines dieser Szenarios greifen Sie nicht manuell ein. Mit einer Zielgröße von Eins wird dafür gesorgt, dass Sie nur eine aktive Instanz haben, die in der verwalteten Instanzgruppe ausgeführt wird und Traffic bereitstellt.

Nichtflüchtige Speicher sind zonal. Sie müssen daher Snapshots erstellen, um im Falle eines Zonenfehlers Laufwerke neu zu erstellen. Snapshots stehen auch regionenübergreifend zur Verfügung. Dadurch können Sie ein Laufwerk in einer anderen Region ähnlich wie in derselben Region wiederherstellen.

Im unwahrscheinlichen Fall eines zonalen Ausfalls müssen Sie manuell eingreifen, um eine Wiederherstellung durchzuführen, wie im nächsten Abschnitt beschrieben.

Failover-Vorgang

Wenn eine VM ausfällt, versucht die verwaltete Instanzgruppe automatisch, die VM in derselben Zone neu zu erstellen. Das Startskript in der Instanzvorlage erstellt dabei aus dem letzten Snapshot einen nichtflüchtigen Speicher und hängt ihn an die neue VM an.

Eine verwaltete Instanzgruppe der Größe Eins wird jedoch nicht wiederhergestellt, wenn ein Zonenfehler auftritt. In einem Szenario, in dem eine Zone ausfällt, müssen Sie auf die Cloud Monitoring-Benachrichtigung oder eine andere Monitoring-Plattform reagieren, wenn der Dienst fehlschlägt, und manuell eine Instanzgruppe in einer anderen Zone erstellen.

Eine Variante dieser Konfiguration besteht darin, regionale nichtflüchtige Speicher statt zonalen nichtflüchtigen Speichern zu verwenden. Bei diesem Ansatz benötigen Sie keine Snapshots zur Wiederherstellung des nichtflüchtigen Speichers im Rahmen der Wiederherstellung. Diese Variante verbraucht jedoch doppelt so viel Speicher, wofür auch ein Budget vorhanden sein muss.

Die jeweils geeignete Variante hängt von Ihrem Budget sowie von den RTO- und RPO-Werten ab.

Warmes Szenario: Failover für statische Website

Wenn Instanzen der Compute Engine fehlschlagen, können Sie die Dienstunterbrechung durch Einrichtung einer Cloud Storage-basierten statischen Website im Standby-Modus verkürzen. Dieses Muster ist geeignet, wenn Ihre Webanwendung größtenteils statisch ist.

In diesem Szenario wird die primäre Anwendung auf Compute Engine-Instanzen ausgeführt. Diese Instanzen werden in verwalteten Instanzgruppen zusammengefasst. Die Instanzgruppen dienen als Backend-Dienste für einen HTTPS-Load-Balancer. Der HTTP-Load-Balancer leitet den eingehenden Traffic an die Instanzen entsprechend der Konfiguration des Load-Balancer, der Konfiguration der einzelnen Instanzgruppen und der Integrität der einzelnen Instanzen weiter.

Bei diesem Muster werden die folgenden DR-Bausteine verwendet:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

Diese Beispielarchitektur wird im folgenden Diagramm veranschaulicht:

Architektur für ein warmes Failover auf eine statische Website bei Produktion in Google Cloud

Mit den folgenden Schritten können Sie ein solches Szenario konfigurieren:

  1. Erstellen Sie ein VPC-Netzwerk.
  2. Erstellen Sie ein benutzerdefiniertes Image, das mit dem Anwendungswebdienst konfiguriert ist.
  3. Erstellen Sie eine Instanzvorlage, die das Image für die Webserver verwendet.
  4. Konfigurieren Sie eine verwaltete Instanzgruppe für die Webserver.
  5. Konfigurieren Sie Systemdiagnosen mithilfe von Monitoring.
  6. Konfigurieren Sie den Load-Balancer mithilfe der verwalteten Instanzgruppen, die Sie zuvor konfiguriert haben.
  7. Erstellen Sie eine Cloud Storage-basierte statische Website.

In der Produktionskonfiguration ist Cloud DNS so konfiguriert, dass es auf diese Primäranwendung verweist, während die statische Stand-by-Website inaktiv ist. Wenn die Compute Engine-Anwendung ausfällt, muss Cloud DNS so konfiguriert sein, dass es auf diese statische Website verweist.

Failover-Vorgang

Wenn der oder die Anwendungsserver ausfallen, muss für die Wiederherstellung Cloud DNS so konfiguriert sein, dass es auf Ihre statische Website verweist. Das folgende Diagramm zeigt die Architektur im Wiederherstellungsmodus:

Konfiguration nach einem Failover auf eine statische Website bei Produktion in Google Cloud.

Wenn die Compute Engine-Instanzen der Anwendung wieder ausgeführt und Produktionsarbeitslasten unterstützt werden, setzen Sie die Wiederherstellung wieder zurück: Sie konfigurieren Cloud DNS so, dass von den Instanzen auf den Load-Balancer verwiesen wird.

Alternativ können Sie die asynchrone Replikation für Persistent Disks verwenden. Sie bietet eine Blockspeicherreplikation mit niedrigem Recovery Point Objective (RPO) und niedrigem Recovery Time Objective (RTO) für die regionsübergreifende Aktiv-Passiv-Notfallwiederherstellung. Mit dieser Speicheroption können Sie die Replikation für Compute Engine-Arbeitslasten auf Infrastrukturebene statt auf Arbeitslastebene verwalten.

Heißes Szenario: HA-Webanwendung

Ein gängiges Muster, wenn Ihre Produktionsumgebung in Google Cloudausgeführt wird, ist die Einrichtung einer gut strukturierten HA-Bereitstellung.

Bei diesem Muster werden die folgenden DR-Bausteine verwendet:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Diese Beispielarchitektur wird im folgenden Diagramm veranschaulicht:

Architektur eines heißen Musters bei Produktion in Google Cloud

In diesem Szenario werden die HA-Funktionen in Google Cloudgenutzt. Sie müssen keine Failover-Schritte einleiten, da diese im Notfall automatisch ausgeführt werden.

Wie das Diagramm zeigt, wird in der Architektur eine regionale verwaltete Instanzgruppe zusammen mit einem globalen Load-Balancing und Cloud SQL verwendet. In diesem Beispiel werden die Instanzen über eine regionale verwaltete Instanzgruppe auf drei Zonen verteilt.

Dieser Ansatz ermöglicht eine umfassende hohe Verfügbarkeit. Regionale verwaltete Instanzgruppen bieten Verfahren zur Verarbeitung von Fehlern auf Anwendungs-, Instanz- oder Zonenebene. Bei Eintreten eines solchen Szenarios müssen nicht manuell eingreifen.

Zur Wiederherstellung auf Anwendungsebene konfigurieren Sie bei der Einrichtung der verwalteten Instanzgruppe HTTP-Systemdiagnosen, die prüfen, ob die Dienste in den Instanzen dieser Gruppe ordnungsgemäß ausgeführt werden. Wenn mit einer solchen Systemdiagnose der Ausfall eines Dienstes auf einer Instanz festgestellt wird, erstellt die Gruppe diese Instanz automatisch neu.

Weitere Informationen zum Erstellen skalierbarer und robuster Anwendungen inGoogle Cloudfinden Sie unter Skalierbare und robuste Anwendungen erstellen.

Nächste Schritte