Plan für die Notfallwiederherstellung
Auf dieser Seite finden Sie Informationen, mit denen Sie die Notfallwiederherstellung für Ihre Arbeitslasten in der Bare-Metal-Lösungsumgebung planen können.
Die Bare-Metal-Lösung wird über eine regionale Erweiterung bereitgestellt. Seit Februar 2024 werden alle Bare Metal Solution-Regionen physisch in Einrichtungen außerhalb von Google gehostet. Aufgrund des Modells für die Regionserweiterung folgt Bare Metal Solution nicht dem herkömmlichen Modell der zonalen Trennung, das von anderen Google Cloud Diensten wie der Compute Engine verwendet wird. Jede Bare-Metal-Lösungsbereitstellung innerhalb einer regionalen Erweiterung wird als Pod bezeichnet. In einigen Regionen werden Bare-Metal-Lösungsressourcen von mehreren Pods bereitgestellt. Es ist jedoch nicht erforderlich oder zu erwarten, dass die Pods geografisch getrennt sind.
Wenn Sie geschäftskritische Arbeitslasten ausführen, empfehlen wir Ihnen, eine Notfallwiederherstellung zu planen.
Empfohlene Ressourcen für die Notfallwiederherstellung
Wir empfehlen Ihnen, die folgenden Ressourcen zur Notfallwiederherstellung zu lesen:
- Plan für die Notfallwiederherstellung (dieses Dokument)
- Google Cloud Leitfaden zur Planung der Notfallwiederherstellung (enthält weitere Informationen zur Implementierung Ihres Notfallwiederherstellungsplans)
- Optionen für die Notfallwiederherstellung von Oracle-Datenbanken (gilt, wenn Sie Oracle-Datenbanken verwenden)
Podübergreifende Konnektivität
Pods und Regionserweiterungen haben keine direkte Konnektivität. Der gesamte Traffic (ein- und ausgehend) Ihrer Bare-Metal-Lösung wird über ein Interconnect und den Google Cloud Backbone geleitet. Für die Replikation auf Speicherebene wird kein unterstützter Datenpfad verwendet. Dies schließt Notfallwiederherstellungsoptionen aus, die auf den Speichertechnologien basieren, z. B. die Speicherreplikation auf Blockebene oder die Remote-Snapshot-Replikation.
Planung der Notfallwiederherstellungsregion
Sie können eine Region für die Bare-Metal-Lösung in der Regel anhand andererGoogle Cloud Dienste auswählen, die Sie verwenden. Die Notfallwiederherstellung für Datenbanken entspricht jedoch in der Regel den Regionen, die für die entsprechenden Anwendungen und ihre Integrationen verwendet werden. Berücksichtigen Sie daher die Netzwerklatenz zwischen den Regionen, wenn Sie planen, welche Regionen Sie für die Notfallwiederherstellung verwenden möchten.
Je nach Branche gelten möglicherweise regulatorische Anforderungen an die Datenspeicherung, die festlegen, wo Sie Daten replizieren können. Jede Anwendung hat ihre eigenen Anforderungen. Die Auswahl der Region für die Notfallwiederherstellung liegt daher in Ihrer Verantwortung.
Überlegungen zum Netzwerk
Traffic für Interconnects isolieren
In vielen Fällen sollten Sie den Replikationstraffic von Anwendungssitzungen trennen.
Die Traffic-Isolation kann durch die Bereitstellung separater Partner-Interconnects in jeder Region erreicht werden, die in einem Transit-VPC enden, das für die Replikation verwendet wird. Das folgende Diagramm zeigt diese Konfiguration.
Im Diagramm verwenden die Bare-Metal-Lösungsserver in der Region us-west2
das Netzwerk 10.10.10.0/24
und die Bare-Metal-Lösungsserver in der Region us-east4
das Netzwerk 10.20.20.0/24
. Das Nutzerprojekt enthält separate VPCs für Anwendungs- und Replikationsverkehr mit den Namen Application VPC
und Replication VPC
. Die BGP-Anzeigen sind so konfiguriert, dass jeder Cloud Router in der Replication VPC
eine Route zum regionenübergreifenden Bare-Metal-Lösungsnetzwerk anbietet. Dadurch wird der regionenübergreifende Traffic über die Replication VPC
geleitet. Die Cloud Router in der Application VPC
kündigen eine generische 0.0.0.0/0
-Route oder Routen zu bestimmten CIDR-Blöcken an, mit denen die Bare-Metal-Lösungsserver kommunizieren müssen. In diesem Beispiel steht 0.0.0.0/0
für eine Route, über die Traffic an ein beliebiges anderes Ziel gesendet wird.
Die Anwendungsserver und andere Dienste, die eine Verbindung zu lokalen Rechenzentren herstellen, werden über die Application VPC
verbunden. Die Instanzen innerhalb der Application VPC
können weiterhin mit Datenbanken kommunizieren, die in einer der beiden Regionserweiterungen der Bare-Metal-Lösung ausgeführt werden.
Die Interconnects, die in der Transit-VPC enden, können auch für den Zugriff aufGoogle Cloud Dienste wie Cloud Storage, Filestore oder Sicherung und Notfallwiederherstellung verwendet werden. Dazu können Sie die Filestore-Instanz in der Transit-VPC erstellen oder Private Service Connect-Endpunkte verwenden, die sich in der Transit-VPC befinden.