Der Hauptgrund für die Berücksichtigung der Geschäftskontinuität für geschäftskritische Systeme ist, dass ein Unternehmen dadurch widerstandsfähiger wird und seinen Geschäftsbetrieb während und nach Ausfällen fortsetzen kann. Wenn Sie Systeme und Daten über mehrere geografische Regionen hinweg replizieren und Single Points of Failure vermeiden, können Sie das Risiko einer Naturkatastrophe und deren Auswirkung auf die lokale Infrastruktur minimieren. Andere Fehlerszenarien sind beispielsweise ein schwerer Systemausfall, ein Cyberangriff oder ein Fehler bei der Systemkonfiguration.
Die Optimierung eines Systems, um Ausfällen standzuhalten, ist für eine effektive Geschäftskontinuität unerlässlich. Die Systemzuverlässigkeit kann durch verschiedene Faktoren beeinflusst werden, darunter Leistung, Ausfallsicherheit, Verfügbarkeit, Sicherheit und Nutzerfreundlichkeit. Weitere Informationen zum Entwerfen und Betreiben zuverlässiger Dienste aufGoogle Cloudfinden Sie im Zuverlässigkeits-Pillar des Google Cloud Well-Architected Framework und unter Bausteine für Zuverlässigkeit in Google Cloud.
Dieses Architekturmuster basiert auf einer redundanten Bereitstellung von Anwendungen in mehreren Rechenumgebungen. Bei diesem Muster stellen Sie dieselben Anwendungen in mehreren Rechenumgebungen bereit, um die Zuverlässigkeit zu erhöhen. Geschäftskontinuität kann als die Fähigkeit einer Organisation definiert werden, ihre wichtigsten Geschäftsfunktionen oder ‑dienste nach einer Störung auf einem vordefinierten akzeptablen Niveau fortzusetzen.
Die Notfallwiederherstellung ist ein Teil der Geschäftskontinuität und hat zum Ziel, dass die IT-Systeme, die wichtige Geschäftsfunktionen unterstützen, nach einer Störung so schnell wie möglich wieder betriebsbereit sind. Im Allgemeinen sind DR-Strategien und ‑Pläne oft ein wichtiger Bestandteil für eine erweiterte Strategie zur Aufrechterhaltung der Geschäftskontinuität. Aus technologischer Sicht sollten in Ihrer Geschäftsauswirkungsanalyse zwei wichtige Messwerte definiert werden, wenn Sie mit der Entwicklung von Strategien zur Notfallwiederherstellung beginnen: das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO). Weitere Informationen zur Verwendung von Google Cloud für die Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
Je kleiner die RPO- und RTO-Zielwerte sind, desto schneller können Dienste nach einer Unterbrechung mit minimalem Datenverlust wiederhergestellt werden. Dies ist jedoch mit höheren Kosten verbunden, da redundante Systeme erforderlich sind. Redundante Systeme, die in der Lage sind, Daten in nahezu Echtzeit zu replizieren und die nach einem Fehlerereignis im gleichen Umfang arbeiten, erhöhen die Komplexität, den Verwaltungsaufwand und die Kosten.
Die Entscheidung für eine DR-Strategie oder ein ‑Muster sollte auf einer Geschäftsauswirkungsanalyse basieren. Beispielsweise können die finanziellen Verluste, die durch einen Ausfall von nur wenigen Minuten für ein Finanzdienstleistungsunternehmen entstehen, die Kosten für die Implementierung eines DR-Systems bei Weitem übersteigen. Unternehmen in anderen Branchen können sich jedoch stundenlange Ausfallzeiten leisten, ohne dass dies erhebliche Auswirkungen auf das Geschäft hat.
Wenn Sie geschäftskritische Systeme in einem lokalen Rechenzentrum ausführen, können Sie zur Notfallwiederherstellung beispielsweise Standby-Systeme in einem zweiten Rechenzentrum in einer anderen Region unterhalten. Ein kostengünstigerer Ansatz stellt jedoch die Verwendung einer Rechenumgebung in der öffentlichen Cloud für Failover-Zwecke dar. Dieser Ansatz ist der Hauptgrund für das Muster Hybridmuster für Geschäftskontinuität. Die Cloud kann aus Kostensicht besonders attraktiv sein, da Sie einen Teil Ihrer DR-Infrastruktur deaktivieren können, wenn sie nicht verwendet wird. Um eine kostengünstigere DR-Lösung zu erhalten, kann ein Unternehmen mit einer Cloudlösung die potenziellen Erhöhungen der RPO- und RTO-Werte in Kauf nehmen.
Das obige Diagramm zeigt die Verwendung der Cloud als Failover- oder Notfallwiederherstellungsumgebung für eine lokale Umgebung.
Eine weniger gebräuchliche (und selten erforderliche) Variante dieses Musters ist das Multi-Cloud-Muster für Geschäftskontinuität. Bei diesem Muster wird für die Produktionsumgebung ein Cloud-Anbieter und für die DR-Umgebung ein anderer Cloud-Anbieter verwendet. Wenn Sie Arbeitslastkopien über mehrere Cloudanbieter bereitstellen, können Sie die Verfügbarkeit in einem Maß erhöhen, das eine Bereitstellung in mehreren Regionen nicht bieten kann.
Die Bewertung eines DR über mehrere Clouds hinweg im Vergleich zur Verwendung eines Cloud-Anbieters mit verschiedenen Regionen erfordert eine gründliche Analyse mehrerer Aspekte, darunter:
- Verwaltung
- Sicherheit
- Gesamte Machbarkeit.
- Kosten
- Die potenziellen Kosten für die ausgehende Datenübertragung von mehr als einem Cloud-Anbieter können bei kontinuierlicher Inter-Cloud-Kommunikation hoch sein.
- Beim Replizieren von Datenbanken kann es zu einem hohen Traffic kommen.
- Gesamtbetriebskosten und Kosten für die Verwaltung der cloudübergreifenden Netzwerkinfrastruktur.
Wenn Ihre Daten aufgrund von behördlichen Anforderungen in Ihrem Land verbleiben müssen, kann die Verwendung eines zweiten Cloud-Anbieters, der sich ebenfalls in Ihrem Land befindet, als DR-Option infrage kommen. Bei der Verwendung eines zweiten Cloud-Anbieters wird davon ausgegangen, dass es keine Möglichkeit gibt, eine lokale Umgebung für die Erstellung einer Hybridkonfiguration zu nutzen. Um eine Neugestaltung Ihrer Cloud-Lösung zu vermeiden, sollte Ihr zweiter Cloud-Anbieter idealerweise alle erforderlichen Funktionen und Dienste in der Region anbieten.
Designaspekte
- DR-Erwartung: Die RPO- und RTO-Ziele, die Ihr Unternehmen erreichen möchte, sollten Ihre DR-Architektur und die Planungsphase bestimmen.
- Lösungsarchitektur: Bei diesem Muster müssen Sie die vorhandenen Funktionen und Möglichkeiten Ihrer lokalen Umgebung replizieren, um Ihre DR-Erwartungen zu erfüllen. Daher müssen Sie die Machbarkeit und Rentabilität des Rehostings, Refaktorierens oder der Neugestaltung Ihrer Anwendungen bewerten, um in der Cloudumgebung dieselben (oder optimierte) Funktionen und Leistung zu bieten.
- Entwerfen und erstellen: Das Erstellen einer Landing-Zone ist fast immer eine Voraussetzung für die Bereitstellung von Unternehmensarbeitslasten in einer Cloud-Umgebung. Weitere Informationen finden Sie unter Landing Zone-Design in Google Cloud.
DR-Aufruf: Bei der Gestaltung und dem Prozess für die Notfallwiederherstellung sollten Sie die folgenden Fragen berücksichtigen:
- Was löst ein Notfallwiederherstellungsszenario aus? Ein DR kann beispielsweise durch den Ausfall bestimmter Funktionen oder Systeme am primären Standort ausgelöst werden.
- Wie wird das Failover zur DR-Umgebung ausgelöst? Ist es ein manueller Genehmigungsprozess oder kann er automatisiert werden, um ein niedriges RTO-Ziel zu erreichen?
- Wie sollten Mechanismen zur Erkennung und Benachrichtigung von Systemfehlern konzipiert sein, um das Failover in Übereinstimmung mit dem erwarteten RTO auszulösen?
- Wie wird der Traffic nach dem Erkennen des Fehlers zur DR-Umgebung umgeleitet?
Überprüfen Sie Ihre Antworten auf diese Fragen durch Tests.
Testen: Testen und bewerten Sie das Failover zur Notfallwiederherstellung gründlich. Achten Sie darauf, dass es Ihren RPO- und RTO-Erwartungen entspricht. So können Sie bei Bedarf mit größerer Zuversicht DR aufrufen. Führen Sie die Tests jedes Mal neu durch, wenn eine neue Änderung oder Aktualisierung am Prozess oder an der Technologielösung vorgenommen wird.
Teamfähigkeiten: Mindestens ein technisches Team muss über die Fähigkeiten und das Fachwissen verfügen, um die Produktionsarbeitslast in der Cloud-Umgebung zu erstellen, auszuführen und Fehler zu beheben, sofern Ihre Umgebung nicht von einem Drittanbieter verwaltet wird.
Vorteile
Die Nutzung von Google Cloud für die Geschäftskontinuität bietet mehrere Vorteile:
- Da Google Cloud viele Regionen auf der ganzen Welt zur Auswahl hat, können Sie damit Daten an einem anderen Standort auf demselben Kontinent sichern oder replizieren. Sie können Daten auch an einem Standort auf einem anderen Kontinent sichern oder replizieren.
- MitGoogle Cloud können Daten in Cloud Storage in einem biregionalen oder multiregionalen Bucket gespeichert werden. Daten werden redundant in mindestens zwei separaten geografischen Regionen gespeichert. Daten, die in bi- oder multiregionalen Buckets gespeichert sind, werden über die Standardreplikation an geografischen Orten repliziert.
- Biregionale Buckets bieten Georedundanz zur Unterstützung von Geschäftskontinuitäts- und Notfallwiederherstellungsplänen. Um die Replikation zu beschleunigen und einen niedrigeren RPO zu erreichen, können in Dual-Regionen gespeicherte Objekte optional die Turboreplikation über diese Regionen hinweg verwenden.
- Die multiregionale Replikation bietet Redundanz über mehrere Regionen hinweg, indem Ihre Daten innerhalb der geografischen Grenzen der multiregionalen Konfiguration gespeichert werden.
- Bietet eine oder mehrere der folgenden Optionen zur Reduzierung von Investitions- und Betriebsausgaben für die Erstellung einer DR:
- Beendete VM-Instanzen verursachen lediglich Speicherkosten und sind wesentlich günstiger als ausgeführte VM-Instanzen. So können Sie die Kosten für den Unterhalt von Cold-Standby-Systemen minimieren.
- Mit dem nutzungsbasierten Abrechnungsmodell von Google Cloud zahlen Sie nur für die tatsächlich verwendete Speicher- und Rechenkapazität.
- Mit Funktionen für die Elastizität wie Autoscaling können Sie Ihre DR-Umgebung nach Bedarf automatisch skalieren.
Das folgende Diagramm zeigt beispielsweise eine Anwendung, die in einer lokalen Umgebung (Produktion) ausgeführt wird und Wiederherstellungskomponenten aufGoogle Cloud mit Compute Engine, Cloud SQL und Cloud Load Balancing verwendet. In diesem Szenario wird die Datenbank mit einer VM-basierten Datenbank oder einer Google Cloud verwalteten Datenbank wie Cloud SQL vorab bereitgestellt, um eine schnellere Wiederherstellung mit kontinuierlicher Datenreplikation zu ermöglichen. Sie können Compute Engine-VMs aus vorab erstellten Snapshots starten, um die Kosten im Normalbetrieb zu senken. Bei dieser Einrichtung muss DNS nach einem Fehlerereignis auf die externe IP-Adresse von Cloud Load Balancing verweisen.
Damit die Anwendung in der Cloud funktioniert, müssen Sie die Web- und Anwendungs-VMs bereitstellen. Je nach angestrebtem RTO-Level und Unternehmensrichtlinien kann der gesamte Prozess zum Auslösen eines DR, zum Bereitstellen der Arbeitslast in der Cloud und zum Umleiten des Traffics manuell oder automatisch abgeschlossen werden.
Um die Bereitstellung der Infrastruktur zu beschleunigen und zu automatisieren, sollten Sie die Infrastruktur als Code verwalten. Sie können Cloud Build, einen Dienst für die kontinuierliche Integration, verwenden, um Terraform-Manifeste automatisch auf Ihre Umgebung anzuwenden. Weitere Informationen finden Sie unter Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten.
Best Practices
Beachten Sie bei Verwendung des Musters für die Geschäftskontinuität folgende Best Practices:
- Erstellen Sie einen Notfallwiederherstellungsplan, in dem Ihre Infrastruktur sowie Failover- und Wiederherstellungsverfahren dokumentiert werden.
- Berücksichtigen Sie die folgenden Maßnahmen basierend auf Ihrer Geschäftsauswirkungsanalyse und den ermittelten erforderlichen RPO- und RTO-Zielen:
- Entscheiden Sie, ob das Sichern von Daten in Google Cloud ausreicht oder ob Sie eine andere DR-Strategie (Cold-, Warm- oder Hot-Standby-Systeme) in Betracht ziehen müssen.
- Definieren Sie die Dienste und Produkte, die Sie als Bausteine für Ihren DR-Plan verwenden können.
- Formulieren Sie die entsprechenden Notfallwiederherstellungsszenarien für Ihre Anwendungen und Daten im Rahmen Ihrer ausgewählten Notfallwiederherstellungsstrategie.
- Verwenden Sie das Handover-Muster, wenn Sie nur Daten sichern. Andernfalls ist das Mesh-Muster möglicherweise eine gute Option, um die Netzwerkarchitektur der vorhandenen Umgebung zu replizieren.
- Minimieren Sie Abhängigkeiten zwischen Systemen, die in verschiedenen Umgebungen ausgeführt werden, insbesondere wenn die Kommunikation synchron erfolgt. Diese Abhängigkeiten können die Leistung beeinträchtigen und die Gesamtverfügbarkeit verringern.
Vermeiden Sie das Split-Brain-Problem. Wenn Sie Daten bidirektional über Umgebungen hinweg replizieren, werden Sie unter Umständen mit dem sogenannten Split-Brain-Problem konfrontiert. Das Split Brain-Problem tritt auf, wenn zwei Umgebungen, die Daten bidirektional replizieren, die Kommunikation miteinander verlieren. Diese Trennung kann dazu führen, dass Systeme in beiden Umgebungen annehmen, dass die jeweils andere Umgebung nicht mehr verfügbar ist und sie exklusiven Zugriff auf die Daten haben. Dies kann zu widersprüchlichen Änderungen der Daten führen. Es gibt zwei gängige Möglichkeiten, das Split-Brain-Problem zu vermeiden:
- Verwenden Sie eine dritte Rechenumgebung. In dieser Umgebung können Systeme ein Quorum abfragen, bevor Daten geändert werden.
Zulassen, dass in Konflikt stehende Datenänderungen abgeglichen werden, wenn die Verbindung wiederhergestellt ist.
Bei SQL-Datenbanken können Sie das Split-Brain-Problem vermeiden, indem Sie die ursprüngliche primäre Instanz nicht mehr zugänglich machen, bevor Clients die neue primäre Instanz verwenden. Weitere Informationen finden Sie unter Notfallwiederherstellung für Cloud SQL-Datenbanken.
Achten Sie darauf, dass CI-/CD-Systeme und Artefakt-Repositories nicht zu einem Single Point of Failure werden. Wenn eine Umgebung nicht verfügbar ist, müssen Sie weiterhin in der Lage sein, neue Releases zur Verfügung zu stellen oder Konfigurationsänderungen zu übernehmen.
Sorgen Sie bei Verwendung von Standby-Systemen dafür, dass alle Arbeitslasten portierbar sind. Alle Arbeitslasten sollten portierbar sein (sofern von den Anwendungen unterstützt und machbar), damit die Systeme in allen Umgebungen konsistent bleiben. Dieser Ansatz lässt sich mit Containern und Kubernetes umsetzen. Mit Google Kubernetes Engine (GKE) können Sie die Entwicklung und den Betrieb vereinfachen.
Binden Sie die Bereitstellung von Standby-Systemen in Ihre CI/CD-Pipeline ein. Damit sorgen Sie dafür, dass Anwendungsversionen und -konfigurationen in allen Umgebungen einheitlich sind.
Damit DNS-Änderungen schnell weitergegeben werden, konfigurieren Sie Ihr DNS mit einer relativ kurzen Gültigkeitsdauer, damit Sie Nutzer im Notfall auf Standby-Systeme umleiten können.
Wählen Sie die DNS- und Routingrichtlinie aus, die Ihrer Architektur und Ihrem Lösungsverhalten entspricht. Außerdem können Sie mehrere regionale Load Balancer mit DNS-Routingrichtlinien kombinieren, um globale Load-Balancing-Architekturen für verschiedene Anwendungsfälle zu erstellen, einschließlich Hybridkonfigurationen.
Verwenden Sie mehrere DNS-Anbieter. Wenn Sie mehrere DNS-Anbieter verwenden, haben Sie folgende Möglichkeiten:
- Verbessern Sie die Verfügbarkeit und Ausfallsicherheit Ihrer Anwendungen und Dienste.
Sie können die Bereitstellung oder Migration von Hybridanwendungen mit Abhängigkeiten zwischen lokalen Umgebungen und Cloud-Umgebungen vereinfachen, indem Sie eine DNS-Konfiguration mit mehreren Anbietern verwenden.
Google Cloud bietet eine Open-Source-Lösung auf Basis von octoDNS, mit der Sie eine Umgebung mit mehreren DNS-Anbietern einrichten und betreiben können. Weitere Informationen finden Sie unter Öffentliches DNS von mehreren Anbietern mit Cloud DNS.
Verwenden Sie Load-Balancer, wenn Sie Standby-Systeme verwenden, um ein automatisches Failover zu erstellen. Beachten Sie, dass die Hardware des Load-Balancers ausfallen kann.
Verwenden Sie Cloud Load Balancing anstelle von Hardware-Load-Balancern, um einige Szenarien zu ermöglichen, die bei Verwendung dieses Architekturmusters auftreten. Interne Clientanfragen oder externe Clientanfragen können basierend auf verschiedenen Messwerten wie der gewichteten Trafficaufteilung an die primäre Umgebung oder die DR-Umgebung weitergeleitet werden. Weitere Informationen finden Sie unter Trafficverwaltung für globale externe Application Load Balancer.
Wenn das ausgehende Datenübertragungsvolumen von Google Cloud in Richtung der anderen Umgebung hoch ist, sollten Sie Cloud Interconnect oder Cross-Cloud Interconnect in Betracht ziehen. Mit Cloud Interconnect können Sie die Verbindungsleistung optimieren und die Kosten für die ausgehende Datenübertragung von Traffic senken, der bestimmte Bedingungen erfüllt. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.
Erwägen Sie, Ihre bevorzugte Partnerlösung im Google Cloud Marketplace zu verwenden, um Datensicherungen, Replikationen und andere Aufgaben zu erleichtern, die Ihren Anforderungen entsprechen, einschließlich Ihrer RPO- und RTO-Ziele.
Testen und bewerten Sie DR-Aufrufszenarien, um zu ermitteln, wie schnell die Anwendung nach einem Notfall wiederhergestellt werden kann, verglichen mit dem angestrebten RTO-Wert.
Kommunikation während der Übertragung verschlüsseln. Zum Schutz vertraulicher Informationen empfehlen wir, die gesamte Kommunikation während der Übertragung zu verschlüsseln. Wenn eine Verschlüsselung am Konnektivitätslayer erforderlich ist, stehen je nach ausgewählter Hybridkonnektivitätslösung verschiedene Optionen zur Verfügung. Zu diesen Optionen gehören VPN-Tunnel, HA VPN über Cloud Interconnect und MACsec für Cloud Interconnect.