Szenarien der Notfallwiederherstellung von Anwendungen

Last reviewed 2023-05-25 UTC

Dieser Artikel 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 Artikel werden DR-Szenarien für Anwendungen in Verbindung mit DR-Mustern dargestellt. Diese Muster legen fest, 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 -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 sind potenziell kostengünstige Produkte wie z. B. VM-Instanzen auf Abruf geeignet. Solche Instanzen können zu einem wesentlich niedrigeren Preis als herkömmliche Instanzen erstellt und ausgeführt werden. Allerdings ist zu beachten, dass Compute Engine diese Instanzen vorzeitig beendet, wenn der Zugriff auf diese Ressourcen für andere Aufgaben erforderlich ist. Sie werden dann bis zu 24 Stunden nach dem Start beendet.

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 Dataproc 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. So muss z. B. für die eigentliche Einkaufspipeline eine hohe Verfügbarkeit vorhanden sein. Für die E-Mail-Verarbeitung, über die Bestellbestätigungen an Kunden gesendet werden, ist hingegen eine Verzögerung von einigen Stunden kein Problem. 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. Ein solches Szenario besteht aus der Kombination eines "heißen Musters" (Hot Pattern), was den Einkauf betrifft, und eines "warmen/kalten Musters" (Warm/Cold Pattern) hinsichtlich der Benachrichtigung.

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 kalte, warme und heiße Muster implementieren, wenn Ihre Anwendung lokal ausgeführt wird und sich Ihre DR-Lösung in Google Cloud befindet.

Kaltes Muster: Wiederherstellung in Google Cloud

In einem kalten Muster haben Sie nur minimale Ressourcen im DR-Google Cloud-Projekt, die gerade ausreichen, um ein Wiederherstellungsszenario zu aktivieren. Tritt ein Problem auf, das die Ausführung von Produktionsarbeitslasten in der Produktionsumgebung verhindert, muss für die Umsetzung der Failover-Strategie eine Spiegelung der Produktionsumgebung in Google Cloud gestartet werden. Die Clients verwenden dann die Dienste aus der DR-Umgebung.

Dieser Abschnitt zeigt im Detail ein Beispiel für dieses Muster. Im Beispiel wird Cloud Interconnect mit einer selbstverwalteten VPN-Lösung (nicht Google Cloud) für die Verbindung mit Google Cloud konfiguriert. Die Daten werden als Teil der Produktionsumgebung in Cloud Storage kopiert.

DR-Bausteine:

  • 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 einen Dienstkontoschlüssel für ein dediziertes Dienstkonto. Mit dieser Datei werden Anmeldedaten an ein automatisiertes Skript übergeben.

  5. Kopieren Sie den Dienstkontoschlüssel auf den lokalen Computer, auf dem Sie das Skript ausführen, das Ihre Datenbanksicherungen hochlädt. Dies kann auch Ihr Datenbankserver sein. Beachten Sie aber, dass darauf aufgrund von Sicherheitsrichtlinien eventuell keine zusätzliche Software installiert werden darf.

  6. 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.

  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.

  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 Konfiguration des benutzerdefinierten Images für den Datenbankserver ein Startskript. Dieses Skript soll die letzte Sicherung automatisch von einem Cloud Storage-Bucket in die Instanz kopieren und dann den Wiederherstellungsvorgang starten.

  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 eine Wiederherstellung auf dem in Google Cloud ausgeführten System vornehmen. 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 den Produktionstraffic annehmen können, passen Sie das DNS so an, dass es auf den Webserver in Google Cloud verweist.

Im Folgenden wird ein typischer Wiederherstellungsablauf dargestellt:

  1. Verwenden Sie die Deployment Manager-Vorlage, um in Google Cloud eine 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 Cloud verweist. 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 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. Erstellen Sie eine Sicherung der in Google Cloud ausgeführten Datenbank.
  2. Kopieren Sie die Sicherungsdatei in Ihre Produktionsumgebung.
  3. Übernehmen Sie die Sicherungsdatei für Ihr Produktionsdatenbanksystem.
  4. Sperren Sie Verbindungen zur Anwendung in Google Cloud. 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 wurde, um Konnektivität zu Google Cloud bereitzustellen. Eine mehrschichtige Anwendung wird lokal ausgeführt, während in Google Cloud eine minimale Wiederherstellungssuite verwendet wird. Die Wiederherstellungssuite besteht aus einer betriebsbereiten Datenbankserverinstanz in 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. Wenn Sie eine Instanz mit langer Laufzeit verwenden, gelten Rabatte für eine dauerhafte Nutzung.

DR-Bausteine:

  • 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 Referenzwebserver- und Anwendungsserverinstanzen in Google Cloud repliziert. 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 Cloud zu 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 für die lokale Anwendung ein Failover erforderlich ist, konfigurieren Sie das Datenbanksystem in Google Cloud so, dass es den Produktionstraffic annehmen kann. Außerdem müssen Sie Instanzen des Web- und Anwendungsservers starten.

Das folgende Diagramm zeigt die Konfiguration nach dem Failover auf Google Cloud, mit der Produktionsarbeitslasten aus Google Cloud bereitgestellt 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 Cloud verweist.

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. Erstellen Sie eine Sicherung der in Google Cloud ausgeführten Datenbank.
  2. Kopieren Sie die Sicherungsdatei in Ihre Produktionsumgebung.
  3. Übernehmen Sie die Sicherungsdatei für Ihr Produktionsdatenbanksystem.
  4. Sperren Sie Verbindungen zur Anwendung in Google Cloud. Sie können Verbindungen zum Webserver sperren, 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 wiederhergestellten Umgebung.
  7. Konfigurieren Sie Cloud DNS so, dass es auf Ihren lokalen Webdienst verweist.
  8. Löschen Sie die Webserver- und Anwendungsserverinstanzen, die in Google Cloud ausgefü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.

Heiße Hochverfügbarkeit in lokalen Systemen und Google Cloud

Wenn Sie kleine RTO- und RPO-Werte haben, können Sie diese nur erreichen, wenn die Hochverfügbarkeit sowohl in der Produktionsumgebung als auch in Google Cloud gewährleistet ist. Dieser Ansatz bietet ein heißes Muster, da der Produktionstraffic sowohl lokal als auch in Google Cloud bereitgestellt wird.

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

DR-Bausteine:

  • 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 dem 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, mit denen gewährleistet wird, dass die Versionen der Anwendung auf den benutzerdefinierten VM-Images in Google Cloud den lokalen entsprechen. 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 bei einem von der Systemdiagnose ermittelten Fehler Ihr DNS-Dienst den Traffic nicht automatisch umleitet, müssen Sie das DNS-Routing manuell neu konfigurieren, damit der Traffic an das noch aktive System gesendet wird
  • 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 in Google Cloud entwerfen, haben die HA-Funktionen der Plattform direkten Einfluss auf Ihre DR-Architektur.

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 in Google Cloud ausführen, können Sie eine VM in einer verwalteten Instanzgruppe erstellen, die nur eine Instanz ausführt.

DR-Bausteine:

  • 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 Cloud verfü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. Die Verwendung einer statischen Website ist eine denkbare Möglichkeit, wenn Ihre Webanwendung zumeist 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 Back-End-Dienste für einen HTTPS-Load-Balancer. Das HTTP-Lastenausgleichsmodul leitet den eingehenden Traffic an die Instanzen entsprechend der Konfiguration des Lastenausgleichsmoduls, der Konfiguration der einzelnen Instanzgruppen und der Integrität der einzelnen Instanzen weiter.

DR-Bausteine:

  • 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.

Heißes Szenario: HA-Webanwendung

Wenn Ihre Produktionsumgebung in Google Cloud ausgeführt wird, müssen Sie für ein heißes Muster eine gut geplante HA-Bereitstellung einrichten.

DR-Bausteine:

  • 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 Cloud genutzt. Sie müssen kein Failover einleiten, da es im Notfall automatisch ausgeführt wird.

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.

Detaillierte Informationen zur Konfiguration einer hochverfügbaren Webanwendung in Google Cloud finden Sie unter Skalierbare und robuste Webanwendung in Google Cloud.

Nächste Schritte