Sie können Google Cloud verwenden, um Notfallwiederherstellungslösungen für Ihre SAP-Systeme zu hosten, die in Google Cloud, lokal oder bei einem anderen Cloudanbieter ausgeführt werden.
Definition der Notfallwiederherstellung
Die Notfallwiederherstellung (Disaster Recovery, DR) und die Hochverfügbarkeit (High Availability, HA) sind zwei unterschiedliche Elemente im größeren Konzept der Geschäftskontinuität. In diesem Leitfaden geht es um die Notfallwiederherstellung.
Eine DR-Lösung dient der Wiederherstellung der Anwendungsverarbeitung nach einer Naturkatastrophe oder einer vom Menschen verursachten Katastrophe oder nach einem Infrastrukturfehler, der einen großflächigen Ausfall verursacht. Solche Ausfälle deaktivieren nicht nur das primäre Anwendungsverarbeitungssystem, sondern auch jedes Stand-by-System, das vor kleinen Systemausfällen oder lokalen Infrastrukturfehlern schützt.
Weitere Merkmale einer DR-Lösung, die sie von einer Hochverfügbarkeitslösung unterscheidet:
- Das Wiederherstellungssystem in einer DR-Lösung ist normalerweise kein Hot-Stand-by-System.
- Ein Notfallwiederherstellungsverfahren erfordert in der Regel manuelle Eingriffe, um die Anwendungsverarbeitung aus Sicherungen oder der Replikation der Daten, Systeme und Infrastruktur wiederherzustellen.
- Die Lösung umfasst einen Wiederherstellungsstandort, der sich an einem anderen geografischen Standort als das primäre System befindet.
- Das Wiederherstellungszeitziel (Recovery Time Objective, RTO) für eine Notfallwiederherstellungslösung wird normalerweise in Stunden, wenn nicht in Tagen, gemessen.
Die folgende Beispielarchitektur zeigt ein SAP-System, das sowohl eine HA- als auch eine DR-Lösung enthält. Der DR-Standort, an dem das System nach einem Notfall wiederhergestellt wird, befindet sich rechts in Region 2. Das primäre System befindet sich links in Region 1 und ist für hohe Verfügbarkeit mit Failover-Clustern konfiguriert, die sich über zwei Zonen erstrecken. Die Sicherungsfunktion der DR-Lösung wird durch gestrichelte Linien dargestellt, die beide Regionen umfassen. Für die Speicherung verwenden die Systeme einen multiregionalen Cloud Storage-Bucket, der unten im Diagramm angezeigt wird.
Das Beispiel zeigt auch eine Datenbank. Obwohl die Anwendungswiederherstellung von der Datenwiederherstellung abhängt, werden DR-Verfahren für Datenbanksysteme in diesem Leitfaden nicht behandelt. Weitere Informationen finden Sie in der Datenbankdokumentation und in den entsprechenden SAP-Hinweisen. Diese Anleitung bezieht sich speziell auf das SAP NetWeaver-System (SAP ASCS/ERS) und die Anwendungsserver (SAP AAS).
Informationen zur Implementierung von hochverfügbaren SAP-Systemen in Google Cloud finden Sie im Planungsleitfaden für Hochverfügbarkeit für SAP NetWeaver in Google Cloud.
Informationen zur Hochverfügbarkeit und Notfallwiederherstellung für SAP HANA in Google Cloud finden Sie im Planungsleitfaden für SAP HANA – Hochverfügbarkeit und im Planungsleitfaden für SAP HANA – Notfallwiederherstellung.
Allgemeine Informationen zur Notfallwiederherstellung in Google Cloud finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
Designansätze für eine Notfallwiederherstellung (DN) für SAP-Systeme, die nicht in Google Cloud ausgeführt werden
Wenn Ihr primäres SAP-System nicht in Google Cloud läuft, können Sie einen Lift-and-Shift-Ansatz für Ihre DR-Lösung wählen, bei dem die Architektur und Software des DR-Systems in Google Cloud dieselbe ist wie die des primären Systems. Sie können auch einen cloudnativen Ansatz auswählen, bei dem Sie als Teil des Designs Ihrer DR-Lösung das wiederhergestellte System für die Cloud optimieren, unterstützt durch Produkte oder Dienste von Google Cloud oder Google Cloud-Partnern.
Wenn Sie einen Lift-and-Shift-Ansatz verwenden, müssen Sie prüfen, ob die Architektur Ihres primären Systems vollständig von Google Cloud unterstützt wird. In beiden Fällen müssen Sie darauf achten, dass die gesamte verwendete Software ordnungsgemäß für die Verwendung in Google Cloud lizenziert ist.
Weitere Informationen zur Lizenzierung finden Sie in den Nutzungsbedingungen der Google Cloud Platform.
Designelemente einer DR-Lösung für SAP NetWeaver in Google Cloud
Die Designelemente einer DR-Lösung für SAP NetWeaver in Google Cloud können Folgendes umfassen:
- Speicherort des DR-Standorts
- Netzwerk
- Sicherheit
- Hinweise zu virtuellen Maschinen (VM)
- Sicherungsoptionen
- Speicher
Damit jedes dieser Designelemente implementiert wird, haben Sie eine Reihe von Optionen, um Ihre Wiederherstellungs- und Kostenziele zu erreichen.
Speicherort des DR-Standorts
Bei der Auswahl einer Google Cloud-Region für Ihren DR-Standort müssen Sie Folgendes beachten:
- Potenzielle Auswirkungen einer Katastrophe an Ihrem primären Standort
- Standort der Nutzer Ihres SAP NetWeaver-Systems
- Verfügbarkeit der von Ihrem SAP-System verwendeten Google Cloud-Ressourcen und -Funktionen in der von Ihnen ausgewählten Region und Zone
Wählen Sie eine Google Cloud-Region für Ihren DR-Standort aus, die weit genug von Ihrem primären Standort entfernt ist, damit der DR-Standort nicht von einer Katastrophe betroffen ist, die am primären Standort auftreten könnte. Eine Entfernung von 100 Kilometern oder mehr wird in der Regel als ausreichend angesehen, kann jedoch aufgrund von Vorschriften oder organisationsbezogenen Richtlinien abweichen.
Wenn Ihr primäres SAP-System in Google Cloud ausgeführt wird, platzieren Sie Ihren DR-Standort in einer Google Cloud-Region, die sich in der Nähe Ihrer Nutzer befindet, mit Ausnahme der Region, in der Ihr primäres System ausgeführt wird. Google Cloud-Regionen befinden sich weit genug voneinander entfernt, sodass wahrscheinlich nicht zwei Google Cloud-Regionen von derselben Katastrophe betroffen sind.
Wenn Ihr primäres SAP-System außerhalb von Google Cloud ausgeführt wird, platzieren Sie Ihren DR-Standort in einer Region, die so nah wie möglich an Ihren Nutzern liegt. Sie darf sich aber nicht in der potenziellen Auswirkungszone einer Katastrophe befinden, die am Primärstandort auftreten könnte.
Platzieren Sie Ihr DR-System in Ihrer DR-Region in einer Zone, die die VM-Instanztypen und andere Infrastruktur unterstützt, die Ihr SAP- und Datenbanksystem benötigt.
Nachdem Sie eine Region für Ihren DR-Standort ausgewählt haben, müssen Sie möglicherweise Ihre Ressourcenkontingente für die Region erhöhen, um vor einem Ereignis genügend Ressourcen für das DR-System bereitzustellen.
Die Standorte aller Google Cloud-Regionen finden Sie unter Regionen und Zonen.
Informationen zu den in den einzelnen Regionen verfügbaren Funktionen finden Sie unter Verfügbare Regionen und Zonen.
Informationen zu den globalen, regionalen und zonalen Google Cloud-Ressourcen finden Sie unter Globale, regionale und zonale Ressourcen.
Netzwerk
In Google Cloud bietet Virtual Private Cloud (VPC) Netzwerkfunktionen, die sich um den ganzen Globus erstrecken können.
Sie müssen ein VPC-Netzwerk für Ihren DR-Standort erstellen, falls noch keines vorhanden ist. Außerdem müssen Sie ein Subnetzwerk und einen IP-Bereich für den DR-Standort erstellen.
Wenn sich Ihr primäres System in Google Cloud befindet, ist die Konfiguration Ihres Netzwerks einfacher, wenn sich sowohl der primäre Standort als auch der DR-Standort im selben VPC-Netzwerk befinden. Bei Bedarf können Sie die primären und DR-Standorte jedoch in verschiedenen VPC-Netzwerken oder sogar in verschiedenen Projekten platzieren.
Beim Entwerfen Ihrer DR-Lösung müssen Sie die folgenden Kommunikationspfade berücksichtigen:
- Die Verbindung zwischen dem primären Standort und dem Wiederherstellungsstandort in Google Cloud
- Die interne Kommunikation zwischen den Anwendungen, Datenbanken und Servern, aus denen Ihr SAP-System besteht
- Die Verbindung zwischen Ihren Nutzern und dem SAP-System
Für Verbindungen von externen Standorten zu Google Cloud bietet Google Cloud eine Vielzahl von Netzwerkprodukten, die jeden dieser Verbindungspunkte unterstützen.
Primären Standort mit dem DR-Standort verbinden
Die Verbindung zwischen dem primären Standort und dem DR-Standort ist erforderlich, um Sicherungen zu speichern oder einen Replikationspfad zwischen den beiden Systemen bereitzustellen, damit die Wiederherstellungsressourcen im Notfall und zum Testen der Notfallverfahren sofort verfügbar sind.
Wenn Ihr primäres System in Google Cloud ausgeführt wird, erfolgt die Bereitstellung Ihrer Sicherungen am DR-Standort fast automatisch. Compute Engine-Snapshots können als multiregional festgelegt werden. Andere Sicherungen können direkt vom primären System in multiregionale Cloud Storage-Buckets gespeichert werden, sodass sie sofort am DR-Standort verfügbar sind.
Wenn Ihr primäres System nicht in Google Cloud ausgeführt wird, können Sie Ihren primären Standort über Cloud Interconnect oder Cloud VPN mit Ihrem DR-Standort in Google Cloud verbinden.
Ein Beispiel für eine hochverfügbare Cloud Interconnect-Topologie, die mit wenigen Änderungen an ein DR-Szenario angepasst werden kann, finden Sie unter Verfügbarkeit von 99,99 % für Dedicated Interconnect einrichten.
Beispiele für hochverfügbare, multiregionale VPN-Gateway-Topologien, die auch an ein DR-Szenario angepasst werden können, finden Sie unter Cloud VPN-Topologien.
Ein wichtiger Faktor bei der Einrichtung Ihrer Verbindung zu Google Cloud von einer externen Plattform ist die Bandbreite. Die Verbindung muss die regelmäßige Übertragung von Daten und Sicherungen an Google Cloud angemessen unterstützen.
Weitere Informationen zu den Optionen zum Herstellen einer Verbindung zu Google Cloud von externen Plattformen finden Sie unter Hybridkonnektivitätsprodukte.
Verbindung zwischen den SAP-Anwendungen, -Datenbanken und -Servern
Wenn Ihr primäres System in Google Cloud ausgeführt wird, ist die Aufrechterhaltung der Konnektivität zwischen den SAP-Anwendungen, -Datenbanken und -Servern am DR-Standort eine relativ einfache Angelegenheit der Modellierung der Hostnamen, Subnetze, Firewalls usw. am primären Standort.
Wenn Ihr primäres System nicht in Google Cloud ausgeführt wird, ist in der Entwurfsphase möglicherweise mehr Aufwand erforderlich, um die Netzwerkarchitektur des primären Standorts in den DR-Standort in Google Cloud zu übersetzen.
Das Testen Ihrer DR-Verfahren ist wichtig, um Verbindungsprobleme zu erkennen und zu beheben, bevor Ihr Unternehmen vom wiederhergestellten System abhängig ist.
Verbindung der Nutzer mit dem DR-Standort herstellen
Bei einer Wiederherstellung muss nach der Wiederherstellung des SAP-Systems auf den DR-Standort der Traffic von Ihren Nutzern an das wiederhergestellte System umgeleitet werden. In der Regel aktualisieren Sie dazu die Netzwerk-Aliasse in den DNS-Einträgen auf die neuen IP-Adressen, die regional sind.
Wenn Ihre Netzwerkarchitektur VPC-Routen verwendet, müssen Sie die Routen während der Wiederherstellung aktualisieren.
In Google Cloud können Sie Cloud DNS oder eine andere DNS-Lösung verwenden.
Regionale Netzwerkressourcen
Wenn Ihr primäres System in Google Cloud ausgeführt wird und Sie regionale Netzwerkressourcen wie Cloud NAT oder ein regionales Cloud Load Balancing verwenden, benötigen Sie in jeder Region eine Instanz der Ressource.
Weitere Informationen:
Netzwerkzugriffssteuerung
Achten Sie darauf, dass am DR-Standort dieselben Ports wie auf dem primären Standort geöffnet sind.
Sie können in Ihrem VPC-Netzwerk Firewallregeln definieren, um den Traffic von und zu Ihren VMs zu steuern.
Wenn Sie einen Active Directory-Dienst auf Windows Server haben, müssen Sie ihn vor der Wiederherstellung einrichten und mit der Active Directory-Instanz am primären Standort synchronisieren.
Sicherheit
Sie müssen an Ihrem DR-Standort die gleichen Sicherheitskontrollen und Berechtigungen implementieren, die Sie an Ihrem Primärstandort haben. Für die wiederhergestellte Umgebung gelten dieselben Compliance-Bestimmungen.
Jeder Nutzer oder jede Rolle, die Zugriff auf den primären Standort benötigt, benötigt auch Zugriff auf den DR-Standort.
Allgemeine Informationen zum Entwerfen von Sicherheitslösungen für eine DR-Lösung in Google Cloud finden Sie unter Sicherheits- und Compliancekontrollen implementieren.
VM-Hinweise
Mit von Google Cloud bereitgestellten Terraform-Konfigurationen, Produkten und Features wie Cloud Deployment Manager, Instanzvorlagen und benutzerdefinierten Images können Sie die Bereitstellung Ihrer Compute Engine-VM-Instanzen beschleunigen und Konfigurationsfehler am DR-Standort vermeiden.
Virtuelle Maschinen konfigurieren und bereitstellen
Google Cloud bietet Terraform-Konfigurationsdateien und Deployment Manager-Vorlagen für SAP in Google Cloud, mit denen Sie Ihr SAP-System am DR-Standort vordefinieren und bereitstellen können. Die Verwendung der Terraform- oder Deployment Manager-Dateien beschleunigt die Bereitstellung, reduziert Konfigurationsfehler und stellt sicher, dass Ihre SAP-Systeme die Anforderungen des SAP-Supports erfüllen.
Eine weitere Möglichkeit, VMs im Voraus zu konfigurieren, sind Compute Engine-Instanzvorlagen. Mit Instanzvorlagen können Sie die Bereitstellung beschleunigen und die manuelle Konfiguration Ihrer VMs während der Wiederherstellung reduzieren. Da sie jedoch eine Neukonfiguration für den DR-Standort erfordern, ist es möglicherweise einfacher, Ihre VMs von einem Wiederherstellungs-Bootlaufwerk wiederherzustellen, wie im nächsten Abschnitt beschrieben.
Weitere Informationen zu Instanzvorlagen finden Sie unter Instanzvorlagen.
Sie können auch Tools zur Bereitstellungsorchestrierung wie Terraform verwenden, um Ihre Infrastrukturbereitstellungen in Google Cloud zu verwalten.
Je nach RTO können Sie Ihre Compute Engine-Instanzen vorab bereitstellen oder, da die Bereitstellung einer VM nur wenige Minuten dauert, zum Zeitpunkt der Wiederherstellung.
Wenn Sie Ihre VMs vorab bereitstellen, können Sie sie stoppen, um Kosten zu sparen, oder für andere nicht unbedingt erforderliche Zwecke verwenden, bis sie für die Wiederherstellung benötigt werden.
Sie können die Kosten auch minimieren, wenn Sie ein verteiltes System auf weniger VMs am Wiederherstellungsstandort konsolidieren. Wenn sich die Anwendungsserver am primären Standort beispielsweise auf dedizierten Hosts am primären Standort befinden, können Sie am DR-Standort die Anwendungsserver auf demselben Host platzieren wie die SAP Central Services. Sie müssen jedoch die Kosteneinsparungen gegen die erhöhte Komplexität abwägen, die sich aus den unterschiedlichen Konfigurationen an den einzelnen Standorten ergibt.
Bootlaufwerk für die Wiederherstellung
Sie können ein benutzerdefiniertes Image vom Bootlaufwerk des Hosts auf Ihrem primären System erstellen und dann mit dem benutzerdefinierten Image die Wiederherstellungsinstanz am DR-Standort erstellen.
Wenn Ihr System in Google Cloud ausgeführt wird, erstellen Sie ein benutzerdefiniertes Image, wenn Sie ein nichtflüchtiges Compute Engine-Bootlaufwerk für Ihr primäres System erstellt und angepasst haben. Wenn Sie ein unverändertes öffentliches Google Cloud-Image verwenden, können Sie das öffentliche Google Cloud-Image auch am Wiederherstellungsstandort verwenden. Weitere Informationen finden Sie unter Benutzerdefinierte Images erstellen, löschen und verwerfen.
Wenn Ihr System nicht in Google Cloud ausgeführt wird, können Sie ein Bootlaufwerk-Image aus Ihrer lokalen Umgebung in die Google Cloud importieren oder virtuelle Laufwerke von VMs importieren, die auf Ihrer lokalen Workstation oder einer anderen Cloud-Plattform ausgeführt werden.
Sicherungsoptionen
Google Cloud bietet eine Reihe verschiedener Sicherungsoptionen, die Sie beim Entwerfen einer DR-Lösung auswählen können:
- Benutzerdefinierte Compute Engine-Images
- Snapshots des nichtflüchtigen Speichers der Compute Engine
- Replikation
Benutzerdefinierte Compute Engine-Images
Damit das Bootlaufwerk des primären Systems für die Wiederherstellung gesichert wird, können Sie es in Google Cloud als benutzerdefiniertes Compute Engine-Image speichern. Weitere Informationen finden Sie unter Bootlaufwerk zur Wiederherstellung.
Snapshots des nichtflüchtigen Speichers der Compute Engine
Wenn Sie SAP- oder anderen Dateisystemen auf einem nichtflüchtigen Compute Engine-Speicher sichern möchten, können Sie Snapshots von nichtflüchtigem Speicher verwenden.
Sie können auch einen Snapshot-Zeitplan für die automatische Erstellung von Snapshots in regelmäßigen Abständen definieren. Siehe Geplante Snapshots für nichtflüchtigen Speicher erstellen.
Snapshots bieten Konsistenz nur auf Blockebene. Damit Konsistenz auf Dateiebene gewährleistet wird, müssen Sie möglicherweise Mechanismen implementieren, die während dieser Snapshots die Schreibaktivität auf den Zieldateisystemen unterbrechen.
Replikation
Abhängig von Ihren gemeinsam genutzten Speicherlösungen und den Zielen des Wiederherstellungspunkts können Sie Ihre Dateisysteme replizieren. Die Replikation kann für Datenbanken, Blockspeicher oder Dateien verwendet werden.
Das Entwerfen einer DR-Lösung, die Replikation verwendet, eignet sich am besten für geschäftskritische Anwendungen, die eine sehr geringe Toleranz gegenüber Datenverlust aufweisen.
Wenn Ihr primäres System in Google Cloud ausgeführt wird, werden Buckets und Snapshots mit mehreren Regionen für Sie zwischen den ausgewählten Regionen repliziert.
Für die Speicherreplikation auf Blockebene können Sie PD Async Replication verwenden. PD Async Replication bietet eine asynchrone Replikation mit einem niedrigen Recovery Point Objective (RPO) und einem asynchronen RTO-Wert (Recovery Time Objective) für die regionenübergreifende Aktiv-Passiv-Notfallwiederherstellung.
Sie können auch die Replikation verwenden, die von Speicherlösungen von Drittanbietern bereitgestellt wird.
Speicher
Wenn Sie eine DR-Lösung in Google Cloud entwerfen, verwenden Sie wahrscheinlich mehrere Speichertypen, je nachdem, wo Ihr primäres System ausgeführt wird und was Sie speichern.
Cloud Storage-Buckets für Sicherungsdateien
Für andere Sicherungen als Laufwerk-Snapshots, z. B. Dateien, die Sie von einem SAP-System hochladen, das nicht in Google Cloud ausgeführt wird, erstellen Sie in Cloud Storage einen Bucket, auf den Sie sowohl von der primären als auch vom DR-Standort aus zugreifen können. Wenn Sie einen Bucket erstellen, wählen Sie eine Standardspeicherklasse und einen Standort aus.
Wählen Sie eine Standardspeicherklasse anhand des erforderlichen Service Level Agreement (SLA), der erwarteten Speichernutzung und den Kostenbeschränkungen aus. Für die Notfallwiederherstellung ist die Coldline Storage-Speicherklasse oft eine gute Option.
Wählen Sie als Bucket-Standort einen Standort aus, der die Region Ihres DR-Standorts und, falls Ihr primäres System in Google Cloud ausgeführt wird, die Region Ihres primären Standorts enthält.
Wenn sich Ihr primäres System in Google Cloud befindet, wählen Sie einen multiregionalen Standort aus, der die Regionen der primären und des DR-Standorts enthält, damit Sie von beiden Standorten aus auf den Bucket zugreifen können.
Wenn sich Ihr primäres System nicht in Google Cloud befindet, können Sie aus Kostengründen einen Standort in einer Region auswählen, der Ihren DR-Standort enthält.
Wenn sich Ihr primäres System in Google Cloud befindet und Sie eine Drittanbieterlösung für gemeinsam genutzten Speicher verwenden, werden Ihre Speicheroptionen möglicherweise von der Lösung bestimmt. Weitere Informationen erhalten Sie in der Lösungsdokumentation oder von Ihrem Ansprechpartner der Cloud-Kundenbetreuung.
Informationen zu den Preisen finden Sie unter Cloud Storage-Preise.
Speicher für Snapshots des nichtflüchtigen Speichers der Compute Engine
Sie können beim Erstellen eines Snapshots einen Speicherort angeben. Dieser wirkt sich auf die Verfügbarkeit aus und kann Netzwerkkosten verursachen, wenn Sie den Snapshot erstellen oder auf einem neuen Laufwerk wiederherstellen.
Snapshots können entweder an einem multinationalen Cloud Storage-Speicherort wie asia oder in einem regionalen Cloud Storage-Speicherort wie asia-south1 gespeichert werden.
Ein multiregionaler Speicherort sorgt für höhere Verfügbarkeit und kann die Netzwerkkosten beim Erstellen oder Wiederherstellen eines Snapshots senken. Mit einem regionalen Speicherort haben Sie mehr Kontrolle über den physischen Speicherort Ihrer Daten.
Unabhängig von den ausgewählten Standortoptionen müssen die Snapshots an einem Speicherort gespeichert werden, auf den von Ihrem DR-Standort aus zugegriffen werden kann.
Weitere Informationen zu Snapshot-Speicherorten finden Sie unter Speicherort für Snapshots auswählen.
Preisinformationen zum Snapshot-Speicher finden Sie unter Preise für nichtflüchtigen Speicher.
Speicher für benutzerdefinierte Images
Nachdem Sie der Liste benutzerdefinierter Images benutzerdefinierte Image-Dateien hinzugefügt haben, verwaltet Compute Engine den Speicher für die Images. Images in einer benutzerdefinierten Image-Liste sind globale Ressourcen und daher in jeder Region verfügbar.
Informationen zu den Preisen für den Image-Speicher finden Sie unter Image-Speicher.
DR-Plan testen
Nachdem Sie Ihren DR-Plan erstellt haben, sollten Sie ihn regelmäßig testen. Achten Sie dabei auf mögliche Probleme und passen Sie ihn entsprechend an.
Testen Sie alle Aspekte Ihres DR-Plans, einschließlich der folgenden:
- Sicherungen und Sicherungszeitpläne
- Datenübertragung von Standorten außerhalb der Plattform
- Wiederherstellung der gespeicherten Sicherungen
- Sicherheitskontrollen und Systemzugriff
- Netzwerk-Routing
Wenn Sie Ihre DR-Systeme testen, werden Ihre primären Systeme weiterhin ausgeführt. Damit Konflikte oder Split-Brain-Szenarien vermieden werden, müssen Sie das Testsystem vom primären System und seinen Nutzern isolieren.
Allgemeine Informationen zu DR-Tests in Google Cloud finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
DR-Lösung so entwickeln, dass sie Ihren RPOs und RTOs entspricht
Bestimmte Google Cloud-Produkte, -Funktionen und -Dienste sind der Schlüssel zum Entwerfen einer DR-Lösung, die Ihren RPOs und RTOs entspricht.
Design für RPO
Wenn Sie eine DR-Lösung in Google Cloud so entwerfen, dass ein bestimmter RPO erreicht wird, gibt es zwei Variablen, die den Zeitpunkt der Wiederherstellung steuern:
- Sicherungshäufigkeit
- Sicherungsaufbewahrung
Sicherungshäufigkeit
Die Sicherungshäufigkeit bestimmt die maximale Zeitspanne zwischen der letzten Sicherung und einem Notfall. Wenn Sie Ihre DR-Sicherungen alle 24 Stunden erstellen, gehen Datenaktualisierungen im Wert von fast 24 Stunden verloren, wenn der Notfall 23 Stunden und 59 Minuten nach der letzten Sicherung auftritt.
Die Replikation kann die maximal verstrichene Zeit seit der letzten Sicherung auf fast null reduzieren. Sie ist jedoch teuer, sodass Sie sie nur für Datenbanken und geschäftskritische Anwendungsdateien verwenden sollten.
In einer DR-Lösung werden zu einem bestimmten Zeitpunkt Kopien oder Snapshots verwendet, um die für die Wiederherstellung erforderlichen Dateisysteme der SAP-Anwendung zu sichern.
In Google Cloud können Sie Snapshots von nichtflüchtigem Compute Engine-Speicher automatisieren, indem Sie einen stündlichen, täglichen oder wöchentlichen Snapshot-Zeitplan erstellen. Da die Compute Engine-Snapshots jedoch nur die Konsistenz auf Blockebene steuern, sollten Sie die Schreibaktivität während der Snapshots auf den Zieldateisystemen aussetzen, um Konsistenz auf Dateiebene zu gewährleisten.
Der Hauptkostenfaktor bei der Wahl der Sicherungshäufigkeit sind die Datenübertragungskosten. Auch die Speicherkosten spielen eine Rolle. Ihre Aufbewahrungsrichtlinie für Sicherungen kann sich jedoch stärker auf die Speicherkosten auswirken als auf die Sicherungshäufigkeit.
Weitere Informationen zu Snapshot-Zeitplänen finden Sie unter Geplante Snapshots für nichtflüchtigen Speicher erstellen.
Sicherungsaufbewahrung
Die Sicherungsaufbewahrung bestimmt, wie weit Sie Ihren Wiederherstellungspunkt verschieben können. Die Aufbewahrung von Sicherungskopien schützt vor logischen Fehlern, da Sie die Wiederherstellung bis zu einem Zeitpunkt vor dem logischen Fehler durchführen können.
Sie können Aufbewahrungsrichtlinien für Compute Engine-Snapshots und Cloud Storage-Buckets festlegen, die Ihre Sicherungsdateien nach einer bestimmten Zeit automatisch löschen.
Der Hauptkostenfaktor bei der Wahl einer Aufbewahrungsrichtlinie sind die Speicherkosten. Compute Engine-Snapshots reduzieren den für mehrere Snapshots erforderlichen Speicherplatz, da nur inkrementelle Änderungen auf Blockebene gespeichert werden, nachdem der erste vollständige Snapshot gespeichert wurde.
Weitere Informationen zum Festlegen von Aufbewahrungsrichtlinien für Snapshots finden Sie unter Aufbewahrungsrichtlinie für Snapshots.
Informationen zum Festlegen von Aufbewahrungsrichtlinien für Cloud Storage-Buckets finden Sie unter Aufbewahrungsrichtlinien mit Bucket-Sperre.
Design für RTO
Wenn Sie Ihre Google Cloud DR-Lösung für ein bestimmtes RTO entwickeln, ist die Bereitschaft der Infrastruktur, Software, Dateisysteme und Daten am DR-Standort die primäre Steuerungsvariable.
Wenn Sie beispielsweise ein sehr niedriges RTO erreichen möchten, können Sie ein Hot-Stand-by-System am DR-Standort mit vorbereiteter Infrastruktur, aktiven SAP-Systemen und replizierten Daten unterhalten. Das niedrige RTO ist jedoch mit höheren Kosten verbunden.
Sie können Kosten und Wiederherstellungszeiten ausgleichen, indem Sie im Voraus eine kostengünstige oder kostenlose Infrastruktur einrichten und einige Einrichtungsschritte auf den Zeitpunkt der Wiederherstellung verschieben.
Sie können beispielsweise eine VM im Voraus konfigurieren und bereitstellen, dann aber die VM beenden. Für die an die VM angehängten Ressourcen wie externe statische IP-Adressen oder nichtflüchtige Speicher können weiterhin Gebühren anfallen, für die angehaltene VM selbst jedoch nicht.
Da es möglich ist, eine Compute Engine-VM in Google Cloud relativ schnell zu konfigurieren und bereitzustellen, können Sie dies möglicherweise zum Zeitpunkt der Wiederherstellung tun und trotzdem Ihr RTO einhalten. Dies gilt insbesondere, wenn Sie Terraform oder Deployment Manager zur Bereitstellung Ihres DR-Systems verwenden oder die VM anhand einer Vorlage und eines vorab erstellten benutzerdefinierten Images erstellen.
Überlegungen zu Kontingenten und Ressourcen für DR-Lösungen mit hohem RTO
Wenn Sie Ihre Infrastruktur und Systeme nicht vorab bereitstellen, prüfen Sie regelmäßig Ihre Ressourcenkontingente in der Region des DR-Standorts, damit die Kontingente zur Bereitstellung des DR-Systems ausreichen.
Wenn Sie so viel von der DR-Infrastruktur und den DR-Systemen vorab bereitstellen, wie es Ihr Budget zulässt, können Sie sicherstellen, dass Ihr DR-System in Ihre Kontingente passt und dass die Google Cloud-Ressourcen, die Ihr System benötigt, verfügbar sind, wenn Ihr System sie braucht.
Beispielarchitekturen für verschiedene Ziele
Die folgenden Architekturdiagramme zeigen Beispiele für DR-Designs für verschiedene RTOs.
Jedes Diagramm zeigt links Sicherungsoptionen für mehrere Regionen und rechts eine entsprechende vereinfachte SAP-Konfiguration am DR-Standort.
Jedes Beispiel zeigt eine mögliche Kombination von DR-Designelementen. Wenn Sie das DR-Design an Ihre Ziele und Bedingungen anpassen möchten, können Sie Elemente aus einem oder allen Beispielen kombinieren.
Beispiel einer DR-Architektur mit geringem RTO
Das folgende Architekturdiagramm zeigt ein DR-Designbeispiel mit niedrigem RTO.
Bei diesem Design unterhalten Sie ein fast funktionsfähiges SAP-System am DR-Standort. Die VMs sind bereitgestellt und aktiv. Die SAP-Anwendungsserver und der Datenbankserver sind aktiv, der Anwendungsdienst wird jedoch angehalten.
Die Sicherungsoptionen, die Sie in diesem Szenario verwenden werden, umfassen in Compute Engine gespeicherte Betriebssystem-Images und Snapshots nichtflüchtiger Speicher sowie die Datenreplikation zwischen dem primären und dem DR-Standort. Für die Datenreplikation können Sie PD Async Replication verwenden.
Da Datenreplikation verwendet wird, ist das Risiko eines Datenverlusts auf die letzte Datenbanksynchronisierung beschränkt.
Damit Ihr RPO in der Zeit verlängert wird, können Sie Datensicherungen zu Cloud Storage hinzufügen. Dies ist im Diagramm nicht dargestellt. Für die Snapshots des nichtflüchtigen Speichers können Sie geplante Snapshots verwenden und die Aufbewahrungsrichtlinie an Ihr RPO anpassen.
Die folgenden Schritte sind zur Wiederherstellung eines Systems mit niedrigem RTO-Wert erforderlich:
- Führen Sie bei Bedarf eine abschließende Synchronisierung der Dateien durch oder stellen Sie die Dateien aus einem Snapshot des nichtflüchtigen Speichers wieder her.
- Wechseln Sie die primäre Datenbank zum DR-Standort.
- Starten Sie die Anwendung am DR-Standort.
Von den drei gezeigten Beispielarchitekturen ist das Beispiel mit niedrigem RTO-Wert am teuersten.
Beispiel einer DR-Architektur mit mittlerem RTO
Die folgende DR-Beispielarchitektur hat ein höheres RTO als das vorherige Beispiel, aber niedrigere Kosten.
In diesem Design ist der Datenbankserver aktiv, um die Replikation vom primären Standort zu unterstützen. Die VMs für die Anwendungsserver sind nicht aktiv.
Die Sicherungsoptionen, die Sie in diesem Szenario verwenden werden, umfassen Betriebssystem-Images und Snapshots von nichtflüchtigem Speicher, die in Compute Engine gespeichert sind, sowie die Datenreplikation zwischen dem primären und dem DR-Standort. Für die Datenreplikation können Sie PD Async Replication verwenden.
Da Datenreplikation verwendet wird, ist das Risiko eines Datenverlusts auf die letzte Datenbanksynchronisierung beschränkt.
Sie können Datensicherungen in einem Cloud Storage-Bucket speichern, um das RPO in der Zeit zu verlängern. Dies ist im Diagramm nicht dargestellt. Für die Snapshots des nichtflüchtigen Speichers können Sie geplante Snapshots verwenden und die Aufbewahrungsrichtlinie an Ihr RPO anpassen.
Abhängig von den Anforderungen Ihres Datenbanksystems können Sie Ihre Datenbank möglicherweise auf einer kleineren VM am DR-Standort bereitstellen, als dies am primären Standort erforderlich ist. Dadurch können Sie die Kosten bis zur Aktivierung des DR-Systems reduzieren. In diesem Fall müssen Sie die Größe der VM während der Wiederherstellung auf die erforderliche Größe ändern.
Die folgenden Schritte sind erforderlich, um ein System wie dieses wiederherzustellen:
- Stellen Sie bei Bedarf die VM-Instanzen für SAP NetWeaver und die Anwendungsserver aus Snapshots oder Images nichtflüchtiger Speicher bereit.
- Synchronisieren Sie die Dateisysteme von Snapshots von nichtflüchtigem Speicher oder anderem Speicher.
- Ändern Sie bei Bedarf die Größe der Datenbank-VM-Instanz.
- Wechseln Sie die primäre Datenbank zum DR-Standort.
- Starten Sie den Anwendungsdienst am DR-Standort.
Beispiel einer DR-Architektur mit hohem RTO
Das folgende Architekturdiagramm zeigt den höchsten RTO-Wert der gezeigten Beispiele und ist die kostengünstigste Option.
Bei diesem Design können Sie die Server vorab bereitstellen und dann anhalten, um Gebühren für die VMs zu vermeiden. Um Kosten für nichtflüchtige Speicher und andere VM-bezogene Ressourcen zu vermeiden, können Sie die VMs als Teil des Wiederherstellungsprozesses bereitstellen.
Die Sicherungsoptionen, die Sie in diesem Szenario verwenden werden, umfassen gespeicherte Betriebssystem-Images und Snapshots von nichtflüchtigem Speicher, die in Compute Engine gespeichert sind, und Datensicherungen, die in Cloud Storage gespeichert sind.
Damit Sie Ihren RPO erreichen, können Sie sowohl die Sicherungshäufigkeit als auch die Aufbewahrungsrichtlinien Ihrer Snapshot-Zeitpläne und der Sicherungen im Cloud Storage-Bucket anpassen.
Die folgenden Schritte sind erforderlich, um ein System wie dieses wiederherzustellen:
- Stellen Sie bei Bedarf die VM-Instanzen für SAP NetWeaver, die Anwendungsserver und den Datenbankserver aus multiregionalen Snapshots oder Images nichtflüchtiger Speicher bereit, die in Compute Engine gespeichert sind.
- Synchronisieren Sie Dateisysteme von Snapshots von nichtflüchtigem Speicher oder anderem Speicher.
- Stellen Sie die Datenbank aus Sicherungsdateien in einem multiregionalen Cloud Storage-Bucket oder an einem anderen Ort wieder her.
- Wechseln Sie die primäre Datenbank zum DR-Standort.
- Starten Sie den Anwendungsdienst am DR-Standort.
Partner und Produkte für DR-Lösungen für SAP in Google Cloud
Im Google Cloud-Partnerverzeichnis finden Sie Partner, die Sie bei der Notfallwiederherstellung unterstützen.
Im Google Cloud Marketplace finden Sie außerdem verschiedene Produkte und Partner, die Ihre DR-Lösung unterstützen.