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-Lösung-Regionen physisch in Einrichtungen außerhalb von Google gehostet. Aufgrund des Regionserweiterungsmodells folgt die Bare-Metal-Lösung nicht dem herkömmlichen zonalen Trennungsmodell, 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)
- Leitfaden zur Planung der Notfallwiederherstellung für Google Cloud (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ösungsumgebung wird über eine Interconnect-Verbindung und das Google Cloud-Backbone übertragen. 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 wählen die Region für die Bare-Metal-Lösung in der Regel anhand anderer Google Cloud-Dienste aus, 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 Datenspeicherorte, 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, verbinden sich über die Application VPC
. 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 auf Google 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.