Der Hauptgrund für die Berücksichtigung der Geschäftskontinuität für geschäftskritische Systeme besteht darin, Unternehmen dabei zu helfen, widerstandsfähig zu sein und ihren Geschäftsbetrieb während und nach Ausfallereignissen fortzusetzen. 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 schwere Systemausfälle, Cyberangriffe oder sogar Systemkonfigurationsfehler.
Die Optimierung eines Systems, damit es Ausfälle übersteht, ist für die Gewährleistung einer effektiven Geschäftskontinuität unerlässlich. Die Zuverlässigkeit eines Systems kann von mehreren Faktoren beeinflusst werden, darunter Leistung, Ausfallsicherheit, Verfügbarkeit, Sicherheit und Nutzerfreundlichkeit. Weitere Informationen zum Entwerfen und Betreiben zuverlässiger Dienste in Google Cloud finden Sie in der Säule Zuverlässigkeit des Google Cloud-Architektur-Frameworks und unter Bausteine für Zuverlässigkeit in Google Cloud erstellen.
Dieses Architekturmuster basiert auf einer redundanten Bereitstellung von Anwendungen in mehreren Rechenumgebungen. Bei diesem Muster werden dieselben Anwendungen in mehreren Rechenumgebungen bereitgestellt, um die Zuverlässigkeit zu erhöhen. Die Geschäftskontinuität kann als die Fähigkeit eines Unternehmens definiert werden, seine wichtigsten Geschäftsfunktionen oder ‑dienste nach einem Unterbrechungsereignis auf einem vordefinierten akzeptablen Niveau fortzusetzen.
Die Notfallwiederherstellung (Disaster Recovery, DR) 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 tragen DR-Strategien und -Pläne oft zur Entwicklung einer umfassenderen Strategie zur Aufrechterhaltung der Geschäftskontinuität bei. Aus technologischer Sicht sollten Sie bei der Erstellung von Strategien zur Notfallwiederherstellung in Ihrer Geschäftsauswirkungsanalyse zwei wichtige Messwerte definieren: das Recovery Point Objective (RPO) und das Recovery Time Objective (RTO). Weitere Informationen zur Anwendung von Google Cloud für die Notfallwiederherstellung finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
Je kleiner die Zielwerte für RPO und RTO sind, desto schneller können Dienste nach einer Unterbrechung mit minimalen Datenverlusten wiederhergestellt werden. Dies ist jedoch mit höheren Kosten verbunden, da redundante Systeme aufgebaut werden müssen. Redundante Systeme, die eine nahezu Echtzeit-Datenreplikation ermöglichen und nach einem Ausfallereignis in der gleichen Skalierung arbeiten, erhöhen Komplexität, Verwaltungsaufwand und Kosten.
Die Entscheidung für eine DR-Strategie oder ein DR-Muster sollte auf einer Analyse der Geschäftsauswirkungen basieren. Beispielsweise können die finanziellen Verluste, die durch eine Ausfallzeit von nur wenigen Minuten für ein Finanzdienstleistungsunternehmen entstehen, die Kosten für die Implementierung eines Notfallwiederherstellungssystems bei weitem übersteigen. Unternehmen in anderen Branchen können jedoch stundenlange Ausfallzeiten verkraften, ohne dass dies erhebliche Auswirkungen auf das Geschäft hat.
Wenn Sie geschäftskritische Systeme in einem Rechenzentrum vor Ort ausführen, können Sie zur Notfallwiederherstellung beispielsweise Standby-Systeme in einem zweiten Rechenzentrum in einer anderen Region unterhalten. Ein kostengünstigerer Ansatz besteht jedoch darin, eine Rechenumgebung in der öffentlichen Cloud für Failover-Zwecke zu verwenden. Dieser Ansatz ist der Haupttreiber des Hybridmusters für Geschäftskontinuität. Die Cloud kann vor allem aus Kostengründen attraktiv sein, da Sie einen Teil Ihrer Notfallwiederherstellungsinfrastruktur deaktivieren können, wenn sie nicht verwendet wird. Um eine kostengünstigere Notfallwiederherstellungslösung zu erhalten, kann ein Unternehmen mit einer Cloud-Lösung die potenzielle Erhöhung der RPO- und RTO-Werte in Kauf nehmen.
Das obige Diagramm veranschaulicht 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 Cloudanbieter und für die Notfallwiederherstellungs-Umgebung ein anderer Cloudanbieter 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 einer Notfallwiederherstellung in mehreren Clouds im Vergleich zur Nutzung eines Cloud-Anbieters mit verschiedenen Regionen erfordert eine gründliche Analyse verschiedener 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 einer kontinuierlichen Cloud-zu-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 zur Erfüllung von behördlichen Anforderungen in Ihrem Land bleiben müssen, kann die Verwendung eines zweiten Cloud-Anbieters, der sich ebenfalls in Ihrem Land befindet, als Notfallwiederherstellungslösung eine Option sein. Die Verwendung eines zweiten Cloud-Anbieters setzt voraus, dass es keine Möglichkeit gibt, eine Hybridumgebung mit einer lokalen Umgebung zu erstellen. Damit Sie Ihre Cloud-Lösung nicht neu strukturieren müssen, sollte Ihr zweiter Cloud-Anbieter idealerweise alle erforderlichen Funktionen und Dienste in der Region anbieten.
Designaspekte
- Anforderungen an die Notfallwiederherstellung: Die RPO- und RTO-Ziele, die Ihr Unternehmen erreichen möchte, sollten die DR-Architektur und die Planung steuern.
- Lösungsarchitektur: Bei diesem Muster müssen Sie die vorhandenen Funktionen und Fähigkeiten Ihrer lokalen Umgebung replizieren, um Ihre Anforderungen an die Notfallwiederherstellung zu erfüllen. Daher müssen Sie die Machbarkeit und Rentabilität des Rehostings, der Refaktorierung oder der Neuarchitektur Ihrer Anwendungen bewerten, um in der Cloud-Umgebung dieselben (oder optimierteren) Funktionen und Leistungen zu bieten.
- Entwerfen und erstellen: Das Erstellen einer Landing-Zone ist fast immer eine Voraussetzung für die Bereitstellung von Unternehmens-Arbeitslasten in einer Cloud-Umgebung. Weitere Informationen finden Sie unter Design der Landing-Zone in Google Cloud.
Wie wird die Notfallwiederherstellung ausgelöst?: Bei der Planung und Durchführung der Notfallwiederherstellung sollten Sie die folgenden Fragen berücksichtigen:
- Was löst ein Notfallwiederherstellungsszenario aus? Eine Notfallwiederherstellung kann beispielsweise durch den Ausfall bestimmter Funktionen oder Systeme am primären Standort ausgelöst werden.
- Wie wird das Failover auf die DR-Umgebung ausgelöst? Geht es um einen manuellen Genehmigungsprozess oder kann er automatisiert werden, um ein niedriges RTO-Ziel zu erreichen?
- Wie sollten die Mechanismen zur Erkennung und Benachrichtigung von Systemausfällen gestaltet sein, damit der Failover gemäß der erwarteten RTO ausgelöst wird?
- Wie wird der Traffic nach Erkennen des Fehlers an die DR-Umgebung weitergeleitet?
Prü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 Ihre RPO- und RTO-Anforderungen erfüllt. So können Sie bei Bedarf mit mehr Zuversicht die Notfallwiederherstellung auslösen. Führen Sie die Tests jedes Mal wieder durch, wenn eine neue Änderung oder Aktualisierung am Prozess oder an der Technologielösung vorgenommen wird.
Teamkompetenzen: Mindestens ein technisches Team muss die Fähigkeiten und das Fachwissen haben, um die Produktionsarbeitslast in der Cloud-Umgebung zu erstellen, zu betreiben und Fehler zu beheben, es sei denn, Ihre Umgebung wird von einem Drittanbieter verwaltet.
Vorteile
Die Nutzung von Google Cloud für die Geschäftskontinuität bietet mehrere Vorteile:
- Da in Google Cloud viele Regionen auf der ganzen Welt zur Auswahl stehen, können Sie damit Daten an einem anderen Standort auf demselben Kontinent sichern oder replizieren. Sie können Daten auch an einem anderen Standort auf einem anderen Kontinent sichern oder replizieren.
- In Google Cloud können Sie Daten in Cloud Storage in einem Dual-Region- oder Multi-Region-Bucket speichern. Die Daten werden redundant in mindestens zwei geografisch getrennten Regionen gespeichert. Daten, die in bi- oder multiregionalen Buckets gespeichert sind, werden über die Standardreplikation an geografischen Orten repliziert.
- Dual-Region-Buckets bieten Georedundanz, um die Geschäftskontinuität und Notfallwiederherstellungspläne zu unterstützen. Außerdem können für eine schnellere Replikation mit einem niedrigeren RPO in Dual-Regionen gespeicherte Objekte optional die Turboreplikation über diese Regionen hinweg verwenden.
- Ähnlich wie bei der Replikation in mehreren Regionen wird durch die Speicherung Ihrer Daten innerhalb der geografischen Grenzen der Region eine Redundanz in mehreren Regionen erreicht.
- Bietet eine oder mehrere der folgenden Optionen zur Senkung der Kapital- und Betriebskosten für die Notfallwiederherstellung:
- Beendete VM-Instanzen verursachen lediglich Speicherkosten und sind wesentlich günstiger als laufende VM-Instanzen. So können Sie die Kosten für die Wartung 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 Elastizitätsfunktionen wie Autoscaling können Sie Ihre Notfallwiederherstellungsumgebung bei Bedarf automatisch skalieren oder verkleinern.
Das folgende Diagramm zeigt beispielsweise eine Anwendung, die in einer lokalen Umgebung (Produktion) ausgeführt wird und Wiederherstellungskomponenten in Google Cloud mit Compute Engine, Cloud SQL und Cloud Load Balancing verwendet. In diesem Szenario wird die Datenbank mit einer VM-basierten Datenbank oder einer von Google Cloud verwalteten Datenbank wie Cloud SQL vorab bereitgestellt, um eine schnellere Wiederherstellung durch kontinuierliche Datenreplizierung zu ermöglichen. Sie können Compute Engine-VMs von vorab erstellten Snapshots starten, um die Kosten bei normalem Betrieb zu senken. Bei dieser Konfiguration muss das 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 Webanwendungs- und Anwendungs-VMs bereitstellen. Je nach angestrebtem RTO-Niveau und den Unternehmensrichtlinien kann der gesamte Prozess zum Aufrufen einer Notfallwiederherstellung, zum Bereitstellen der Arbeitslast in der Cloud und zum Umleiten des Traffics manuell oder automatisch ausgeführt werden.
Um die Bereitstellung der Infrastruktur zu beschleunigen und zu automatisieren, sollten Sie die Infrastruktur als Code verwalten. Mit Cloud Build, einem Dienst für die kontinuierliche Einbindung, können Sie Terraform-Manifeste automatisch auf Ihre Umgebung anwenden. 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 Analyse der Geschäftsauswirkungen und den ermittelten erforderlichen RPO- und RTO-Zielen:
- Entscheiden Sie, ob die Sicherung von Daten in Google Cloud ausreicht oder ob Sie eine andere Notfallwiederherstellungsstrategie (Cold-, Warm- oder Hot-Standby-Systeme) in Betracht ziehen müssen.
- Definieren Sie die Dienste und Produkte, die Sie als Bausteine für Ihren Notfallwiederherstellungsplan verwenden können.
- Definieren 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 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 die Kommunikation zwischen zwei Umgebungen, die Daten bidirektional replizieren, unterbrochen wird. Diese Aufteilung kann dazu führen, dass Systeme in beiden Umgebungen zu dem Schluss kommen, dass die jeweils andere Umgebung nicht verfügbar ist und dass sie exklusiven Zugriff auf die Daten haben. Dies kann zu in Konflikt stehenden Änderungen der Daten führen. Es gibt zwei gängige Möglichkeiten, das Split-Brain-Problem zu vermeiden:
- Eine dritte Computing-Umgebung verwenden In dieser Umgebung können Systeme vor der Änderung von Daten ein Quorum prüfen.
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 von 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 portabel sein (sofern von den Anwendungen unterstützt und möglich), damit die Systeme in allen Umgebungen einheitlich bleiben. Sie können diesen Ansatz mithilfe von Containern und Kubernetes erreichen. Mit der Google Kubernetes Engine (GKE) Enterprise-Version können Sie die Erstellung und den Betrieb vereinfachen.
Binden Sie die Bereitstellung von Standby-Systemen in Ihre CI/CD-Pipeline ein. Dies gewährleistet, dass Anwendungsversionen und -konfigurationen in allen Umgebungen konsistent sind.
Damit DNS-Änderungen schnell weitergegeben werden, konfigurieren Sie Ihr DNS mit einer relativ kurzen Gültigkeitsdauer, damit Sie Nutzer bei einem Notfall auf Standby-Systeme umleiten können.
Wählen Sie die DNS- und Routingrichtlinie aus, die zu Ihrer Architektur und Ihrem Lösungsverhalten passt. 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:
- Verfügbarkeit und Ausfallsicherheit Ihrer Anwendungen und Dienste verbessern
Mit einer DNS-Konfiguration mit mehreren Anbietern können Sie die Bereitstellung oder Migration von Hybridanwendungen mit Abhängigkeiten zwischen lokalen und Cloud-Umgebungen vereinfachen.
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 mit mehreren Anbietern mit Cloud DNS verwenden.
Verwenden Sie bei der Verwendung von Standby-Systemen Load Balancer, um ein automatisches Failover einzurichten. Beachten Sie, dass die Hardware des Load Balancers ausfallen kann.
Verwenden Sie Cloud Load Balancing anstelle von Hardware-Load Balancern, um einige Szenarien zu unterstützen, die bei der 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 Notfallwiederherstellungsumgebung weitergeleitet werden. Weitere Informationen finden Sie unter Trafficverwaltung für globale externe Application Load Balancer.
Wenn das ausgehende Datenübertragungsvolumen von Google Cloud in die andere Umgebung hoch ist, sollten Sie Cloud Interconnect oder Cross-Cloud Interconnect verwenden. 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.
Sie können die bevorzugte Partnerlösung im Google Cloud Marketplace verwenden, um die Datensicherung, ‑replizierung und andere Aufgaben zu erleichtern, die Ihren Anforderungen entsprechen, einschließlich Ihrer RPO- und RTO-Ziele.
Testen und bewerten Sie Szenarien für die Notfallwiederherstellung, um zu erfahren, wie schnell die Anwendung im Vergleich zum Zielwert für die RTO nach einem Notfall wiederhergestellt werden kann.
Verschlüsseln Sie die Kommunikation während der Übertragung. Zum Schutz vertraulicher Daten 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.