Plan für die Notfallwiederherstellung

Auf dieser Seite finden Sie Informationen, die Sie für die Planung der Notfallwiederherstellung für Ihre Arbeitslasten in der Bare-Metal-Lösungsumgebung verwenden 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 gehostet, die nicht von Google betrieben werden. Aufgrund des Modells für die Regionenerweiterung folgt die Bare-Metal-Lösung nicht dem herkömmlichen Zonenmodell, das von anderen Google Cloud -Diensten wie Compute Engine verwendet wird. Jede Bare-Metal-Lösungsbereitstellung in einer regionalen Erweiterung wird als Pod bezeichnet. In einigen Regionen werden Bare-Metal-Lösungsressourcen über mehrere Pods bereitgestellt. Es gibt jedoch keine Anforderung oder Erwartung, dass Pods geografisch getrennt sind.

Wenn Sie geschäftskritische Arbeitslasten ausführen, empfehlen wir, die Notfallwiederherstellung zu planen.

Empfohlene Ressourcen für die Planung der Notfallwiederherstellung

Wir empfehlen Ihnen, die folgenden Ressourcen zu lesen, um die Notfallwiederherstellung zu planen:

Pod-übergreifende Verbindungen

Pods und Regionenerweiterungen haben keine direkte Verbindung. Der gesamte Traffic (ein- und ausgehend) Ihrer Bare-Metal-Lösung wird über einen Interconnect und das Google Cloud Backbone übertragen. Es gibt keinen unterstützten Datenpfad für die Replikation auf Speicherebene. Dadurch entfallen Optionen für die Notfallwiederherstellung, die auf den Speichertechnologien basieren, z. B. die Replikation von Speicher auf Blockebene oder die Replikation von Remote-Snapshots.

Planung der Region für die Notfallwiederherstellung

Berücksichtigen Sie bei der Auswahl von Regionen für die Planung der Notfallwiederherstellung die folgenden Punkte:

  • In der Regel wählen Sie eine Bare-Metal-Lösungsregion basierend auf anderenGoogle Cloud -Diensten 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 Regionen, wenn Sie planen, welche Regionen Sie für die Notfallwiederherstellung verwenden möchten.

  • Je nach Branche können regulatorische Anforderungen an den Datenstandort festlegen, wo Sie Daten replizieren dürfen. Jede Anwendung hat ihre eigenen Anforderungen. Die Auswahl der Region für die Notfallwiederherstellung liegt daher bei Ihnen.

  • In der Bare-Metal-Lösung werden bestimmte Komponenten der Steuerungsebene für eine Gruppe von Regionen ausgeführt, die zusammen als GeoSector bezeichnet werden. Ein Ausfall dieser Komponenten kann sich auf Steuerungsebenenvorgänge auswirken, z. B. auf das Erstellen, Starten und Beenden von Datenbanken oder das Skalieren von Speicher in einer oder mehreren Regionen innerhalb des GeoSector. Je nach Ihren geschäftlichen Anforderungen empfehlen wir, bei der Bereitstellung in mehreren Regionen Regionen auszuwählen, die sich in separaten GeoSectors befinden, um die Zuverlässigkeit zu verbessern.

    So sorgen Sie für die Ausfallsicherheit Ihrer Bare-Metal-Lösung:

    1. Ordnen Sie Ihre primären und sekundären Notfallwiederherstellungsumgebungen den in der folgenden Tabelle aufgeführten GeoSektoren zu:

      GeoSector Google Cloud -Region
      ap1 asia-northeast1
      asia-northeast3
      ap2 asia-southeast1
      eu1 europe-west2
      europe-west3
      eu2 europe-west4
      us1 northamerica-northeast1
      northamerica-northeast2
      southamerica-east1
      us-central1
      us-west2
      us2 us-central2
      us-east4

    2. Konfigurieren Sie die Notfallwiederherstellung über separate GeoSektoren hinweg. Wenn Sie keine Einrichtung für die Notfallwiederherstellung haben oder Ihre primären und sekundären Umgebungen im selben GeoSector bereitgestellt werden, sollten Sie Ihre sekundäre Umgebung in einen anderen GeoSector verlagern, um die Resilienz zu verbessern.

Überlegungen zum Netzwerk

Traffic für Interconnect isolieren

In vielen Fällen ist es sinnvoll, den Replikations-Traffic von Anwendungssitzungen zu isolieren.

Die Traffic-Isolation kann erreicht werden, indem in jeder Region separate Partner Interconnects bereitgestellt werden, die in einer Transit-VPC für die Replikation enden. Das folgende Diagramm zeigt diese Art der Konfiguration.

Trafficisolierung über separate Interconnect-Verbindungen.

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 Replikations-Traffic mit den Namen Application VPC bzw. Replication VPC. Die BGP-Advertisements sind so konfiguriert, dass jeder Cloud Router in der Replication VPC eine Route für das regionsübergreifende Bare-Metal-Lösungsnetzwerk bewirbt. Dadurch wird regionsübergreifender Traffic über die Replication VPC geleitet. Die Cloud Router in 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 wird 0.0.0.0/0 verwendet, um eine Route zu kennzeichnen, über die Traffic an ein beliebiges anderes Ziel gesendet wird.

Die Anwendungsserver und andere Dienste, die eine Verbindung von lokalen Rechenzentren aus herstellen, stellen die Verbindung über die Application VPC her. Die Instanzen innerhalb von 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 Backup and DR verwendet werden. Dazu muss die Filestore-Instanz in der Transit-VPC erstellt werden oder es müssen Private Service Connect-Endpunkte verwendet werden, die sich in der Transit-VPC befinden.