Architektur der Notfallwiederherstellung von Arbeitslasten mit Standortbeschränkung entwickeln

Last reviewed 2022-06-10 UTC

In diesem Dokument wird beschrieben, wie Sie mit Google Cloud die Notfallwiederherstellung (Disaster Recovery, DR) so einrichten, dass standortspezifische Anforderungen erfüllt werden. In einigen regulierten Branchen müssen Arbeitslasten diese Anforderungen erfüllen. In diesem Szenario gilt mindestens eine der folgenden Anforderungen:

  • Inaktive Daten müssen auf ein angegebenes Land beschränkt sein.
  • Die Daten müssen in dem Land verarbeitet werden, in dem sie sich befinden.
  • Arbeitslasten sind nur über vordefinierte Speicherorte zugänglich.
  • Daten müssen mit Schlüsseln verschlüsselt werden, die der Kunde verwaltet.
  • Wenn Sie Cloud-Dienste verwenden, muss jeder Cloud-Dienst mindestens zwei Standorte bereitstellen, die zueinander redundant sind. Ein Beispiel für die Anforderungen an Standortredundanz finden Sie unter Cloud Computing-Compliance-Kriterienkatalog (C5).

Dieser Artikel ist der fünfte Teil einer Reihe, in der die Notfallwiederherstellung (Disaster Recovery – DR) in Google Cloud beschrieben wird. Dieser Teil bietet einen Überblick über den DR-Planungsprozess und vermittelt, was Sie wissen müssen, um einen DR-Plan zu entwerfen und zu implementieren.

Die Reihe besteht aus folgenden Teilen:

Terminologie

Bevor Sie mit der Architektur der Notfallwiederherstellung für Arbeitslasten mit Standortbeschränkung beginnen, sollten Sie die in Google Cloud verwendete Standort-Terminologie prüfen.

Google Cloud stellt Dienste in Regionen in Amerika, Europa, dem Nahen Osten und Asien-Pazifik zur Verfügung. Zum Beispiel ist London (europe-west2) eine Region in Europa und Oregon (us-west1) eine Region in Nordamerika. Einige Google Cloud-Produkte gruppieren mehrere Regionen in einem bestimmten multiregionalen Standort, der auf dieselbe Weise wie eine Region zugänglich ist.

Regionen sind weiter unterteilt in Zonen, in denen Sie bestimmte Google Cloud-Ressourcen bereitstellen. Hierzu zählen beispielsweise virtuelle Maschinen, Kubernetes-Cluster oder Cloud SQL-Datenbanken. Ressourcen in Google Cloud sind multiregional, regional oder zonal. Einige Ressourcen und Produkte, die standardmäßig als multiregional gekennzeichnet sind, können auch auf eine Region beschränkt werden. Die verschiedenen Ressourcentypen werden im Folgenden erläutert:

  • Multiregionale Ressourcen wurden von Google Cloud so konzipiert, dass sie redundant sowie in und über verschiedene Regionen hinweg verteilt sind. Multiregionale Ressourcen sind ausfallsicher gegenüber dem Ausfall einer einzigen Region.
  • Regionale Ressourcen werden redundant in mehreren Zonen einer Region bereitgestellt und sind ausfallsicher gegenüber Ausfällen einer Zone innerhalb der Region.
  • Zonale Ressourcen arbeiten innerhalb einer einzigen Zone. Wenn eine Zone nicht mehr verfügbar ist, sind alle zonalen Ressourcen in dieser Zone bis zur Wiederherstellung des Dienstes nicht verfügbar. Eine Zone sollte als einzelne fehlerhafte Domain gesehen werden. Sie müssen Ihre Anwendungen so konzipieren, dass die Auswirkungen der Nichtverfügbarkeit einer einzelnen Zone abgefedert werden.

Die folgende Tabelle zeigt die aktuelle Beziehung zwischen Regionen, Zonen und Standorten für Europa.

Region Zonen Standort
europe-north1 a, b, c Hamina, Finnland
europe-west1 b, c, d St. Ghislain, Belgien
europe-west2 a, b, c London, England, Vereinigtes Königreich
europe-west3 a, b, c Frankfurt, Deutschland
europe-west4 a, b, c Eemshaven, Niederlande
europe-west6 a, b, c Zürich, Schweiz

Weitere Informationen hierzu finden Sie unter Geografie und Regionen.

Planung für die Notfallwiederherstellung für Arbeitslasten mit Standortbeschränkung

Der Ansatz für das Entwerfen Ihrer Anwendung hängt vom Typ der Arbeitslast und den Anforderungen an den Standort ab. Überlegen Sie auch, warum Sie diese Anforderungen erfüllen müssen, denn Ihre Entscheidungen haben direkten Einfluss auf Ihre DR-Architektur.

Lesen Sie zuerst den Leitfaden zur Planung der Notfallwiederherstellung für Google Cloud. Und konzentrieren Sie sich auf die in diesem Planungsabschnitt erörterten Anforderungen, wenn Sie Arbeitslasten mit Standortbeschränkung in Betracht ziehen.

Anforderungen an den Standort definieren

Legen Sie vor dem Erstellen des Entwurfs die entsprechenden Standortanforderungen fest, indem Sie die folgenden Fragen beantworten:

  • Wo befinden sich die inaktiven Daten? Die Antwort bestimmt, welche Dienste Sie verwenden können, sowie die Hochverfügbarkeits- und Notfallwiederherstellungsmethoden, mit denen Sie Ihre RTO-/RPO-Werte erreichen können. Auf der Seite Cloud-Standorte können Sie bestimmen, welche Produkte in den Anwendungsbereich fallen.
  • Können Sie die Anforderungen mithilfe von Verschlüsselungsmethoden reduzieren? Wenn Sie die Standortanforderungen reduzieren können, indem Sie Verschlüsselungsmethoden mithilfe von Cloud External Key Manager und Cloud Key Management Service anwenden, können Sie multiregionale und dual-regionale Dienste verwenden und den Standard-HA/DR-Methoden folgen, die unter Notfallwiederherstellungsszenarien für Daten beschrieben werden.

  • Können Daten außerhalb des Speicherorts verarbeitet werden? Mit Produkten wie GKE Enterprise können Sie eine Hybridumgebung bereitstellen, die Ihren Anforderungen entspricht. Außerdem haben Sie die Möglichkeit, produktspezifische Steuerungen wie Compute Engine-Load-Balancing-Instanzen über mehreren Zonen in einer Region einzurichten. Mit der Beschränkung für Ressourcenstandorte der Organisationsrichtlinie können Sie einschränken, wo Ressourcen bereitgestellt werden können.

    Wenn Daten außerhalb des Bereichs verarbeitet werden können, in dem sie inaktiv sein müssen, können Sie die "Verarbeitungs"-Teile Ihrer Anwendung entsprechend den Anleitungen in den Bausteinen zur Notfallwiederherstellung und den Szenarien zur Notfallwiederherstellung für Anwendungen erstellen.

    Konfigurieren Sie einen VPC Security Controls-Perimeter, um festzulegen, wer auf die Daten zugreifen kann und welche Ressourcen die Daten verarbeiten können.

  • Können Sie mehrere Regionen verwenden? Wenn Sie mehrere Regionen verwenden können, können Sie viele der in der Notfallwiederherstellungsreihe beschriebenen Techniken verwenden. Prüfen Sie die Einschränkungen für mehrere Regionen und Regionen für Google Cloud-Produkte.

  • Müssen Sie einschränken, wer auf Ihre Anwendung zugreifen kann? Google Cloud bietet verschiedene Produkte und Funktionen, mit denen Sie den Zugriff auf Ihre Anwendungen einschränken können:

    • Identity-Aware Proxy (IAP). Überprüft die Identität eines Nutzers und bestimmt dann, ob dieser Nutzer auf eine Anwendung zugreifen darf. In Organisationsrichtlinien wird die Einschränkung für die domaineingeschränkte Freigabe verwendet, um die zulässigen Cloud Identity- oder Google Workspace-IDs zu definieren, die in IAM-Richtlinien zulässig sind.
    • Produktspezifische Steuerelemente. Beachten Sie die jeweiligen Standortbeschränkungen für jedes Produkt, das Sie in Ihrer Architektur verwenden möchten. Sie können beispielsweise mit dem GKE Enterprise-Konfigurationsmanager standortspezifische Richtlinien auf Ihre von GKE Enterprise verwalteten GKE-Cluster anwenden. Erstellen Sie Buckets in bestimmten Regionen, wenn Sie Cloud Storage verwenden.

Dienste identifizieren, die Sie nutzen können

Stellen Sie fest, welche Dienste auf der Grundlage Ihrer örtlichen und regionalen Granularitätsanforderungen genutzt werden können. Beim Entwerfen von Anwendungen, die Standortbeschränkungen unterliegen, müssen Sie wissen, welche Produkte auf welche Region beschränkt werden können und welche Kontrollen zur Erzwingung von Standortbeschränkungen angewendet werden können.

Regionale Granularität für Anwendungen und Daten ermitteln

Ermitteln Sie die regionale Granularität Ihrer Anwendung und Daten mithilfe folgender Fragen:

  • Können Sie in Ihrem Design multiregionale Dienste verwenden? Wenn Sie multiregionale Dienste verwenden, können Sie hochverfügbare robuste Architekturen erstellen.
  • Bestehen Standortbeschränkungen für den Zugriff auf Ihre Anwendung? Verwenden Sie diese Google Cloud-Produkte, um festzulegen, von wo aus auf Ihre Anwendungen zugegriffen werden kann:
  • Sind Ihre inaktiven Daten auf eine bestimmte Region beschränkt? Wenn Sie verwaltete Dienste verwenden, müssen Sie dafür sorgen, dass die von Ihnen verwendeten Dienste so konfiguriert werden können, dass die im Dienst gespeicherten Daten auf eine bestimmte Region beschränkt sind. Beispielsweise können Sie mit BigQuery-Standorteinschränkungen angeben, wo Ihre Datasets gespeichert und gesichert werden.
  • In welchen Regionen müssen Sie die Anwendung einschränken? Einige Google Cloud-Produkte haben keine regionalen Einschränkungen. Verwenden Sie die Seite Cloud-Standorte und die produktspezifischen Seiten, um zu prüfen, in welchen Regionen Sie das Produkt verwenden können und welche Abhilfefunktionen, falls vorhanden, verfügbar sind, um Ihre Anwendung auf eine bestimmte Region zu beschränken.

Standorteinschränkungen mithilfe von Google Cloud-Produkten erfüllen

In diesem Abschnitt werden Funktionen und Abhilfemethoden für die Verwendung von Google Cloud-Produkten als Teil Ihrer DR-Strategie für Arbeitslasten mit Standorteinschränkungen beschrieben. Wir empfehlen, diesen Abschnitt zusammen mit Bausteine der Notfallwiederherstellung zu lesen.

Organisationsrichtlinien

Mit dem Organisationsrichtliniendienst können Sie Ihre Google Cloud-Ressourcen zentral steuern. Mit Organisationsrichtlinien können Sie Einschränkungen für die gesamte Ressourcenhierarchie konfigurieren. Beachten Sie beim Entwerfen von Arbeitslasten mit Standorteinschränkungen die folgenden Richtlinieneinschränkungen:

  • Domaineingeschränkte Freigabe: Standardmäßig können alle Nutzeridentitäten zu IAM-Richtlinien hinzugefügt werden. In der Sperrliste/Zulassungsliste muss mindestens eine Identität für Cloud Identity oder Google Workspace angegeben sein. Wenn diese Beschränkung aktiv ist, können nur Identitäten in der Zulassungsliste zu den IAM-Richtlinien hinzugefügt werden.

  • Standortbezogene Ressourcen: Diese Einschränkung bezieht sich auf die Gruppe von Standorten, an denen standortbezogene Google Cloud-Ressourcen erstellt werden können. In den Richtlinien für diese Einschränkung können die Standorte der folgenden Regionen entweder zugelassen oder abgelehnt werden: Multiregionen wie Asien und Europa, Regionen wie us-east1 oder europe-west1 oder einzelne Zonen wie zum Beispiel europe-west1-b. Eine Liste der unterstützten Dienste finden Sie unter Unterstützte Dienste für Ressourcenstandorte.

Verschlüsselung

Wenn Ihre Anforderungen an den Speicherort der Daten die Einschränkung des Zugriffs auf die Daten betreffen, ist die Implementierung von Verschlüsselungsmethoden möglicherweise eine geeignete Strategie. Durch die Verwendung externer Schlüsselverwaltungssysteme zur Verwaltung von Schlüsseln, die Sie außerhalb von Google Cloud bereitstellen, können Sie möglicherweise eine Multiregionen-Architektur bereitstellen, um den Anforderungen Ihres Standortes gerecht zu werden. Ohne diese Schlüssel können die Daten nicht entschlüsselt werden.

Google Cloud bietet zwei Produkte, mit denen Sie Schlüssel verwenden können, die Sie verwalten:

  • Cloud External Key Manager (Cloud EKM): Mit Cloud EKM können Sie Daten in BigQuery und Compute Engine mit Verschlüsselungsschlüsseln verschlüsseln, die in einem Schlüsselverwaltungssystem eines Drittanbieters gespeichert und verwaltet werden, das außerhalb der Infrastruktur von Google bereitgestellt wird.

  • Vom Kunden bereitgestellte Verschlüsselungsschlüssel (Customer-Supplied Encryption Keys, CSEK): Sie können CSEK mit Cloud Storage und Compute Engine verwenden. Google verwendet Ihren Schlüssel zum Schutz der von Google generierten Schlüssel, die zum Verschlüsseln und Entschlüsseln Ihrer Daten verwendet werden.

    Wenn Sie einen vom Kunden bereitgestellten Verschlüsselungsschlüssel verwenden, wird dieser Schlüssel nicht dauerhaft von Google auf Google-Servern gespeichert und auch nicht anderweitig verwaltet. Stattdessen stellen Sie für jeden Vorgang Ihren Schlüssel bereit. Nach Abschluss des Vorgangs wird er dann von den Google-Servern gelöscht.

Bei der Verwaltung Ihrer eigenen Schlüsselinfrastruktur müssen Sie Latenz- und Zuverlässigkeitsprobleme sorgfältig berücksichtigen und sicherstellen, dass Sie geeignete HA- und DR-Prozesse für Ihren externen Schlüsselmanager implementieren. Sie müssen außerdem Ihre RTO-Anforderungen verstehen. Die Schlüssel sind integraler Bestandteil des Schreibens der Daten. Auf RPO muss also nicht das Hauptaugenmerk liegen, da ohne die Schlüssel keine Daten sicher geschrieben werden können. Das eigentliche Problem ist der RTO-Wert, weil Sie ohne Schlüssel keine Verschlüsselung durchführen oder Daten sicher schreiben können.

Speicher

Wenn Sie die Notfallwiederherstellung für Arbeitslasten mit Standorteinschränkungen entwerfen, müssen Sie darauf achten, dass sich inaktive Daten in der von Ihnen erforderlichen Region befinden. Sie können Google Cloud-Objekt- und Dateispeicherdienste entsprechend Ihren Anforderungen konfigurieren

Cloud Storage

Sie können Cloud Storage-Buckets erstellen, die Standorteinschränkungen erfüllen.

Berücksichtigen Sie neben den im Abschnitt „Cloud Storage” des Artikels „Bausteine der Notfallwiederherstellung” erläuterten Features bei der Entwicklung für die Notfallwiederherstellung für Arbeitslasten mit Standorteinschränkungen, ob regionsübergreifende Redundanz eine Anforderung ist: Objekte, die in Multiregionen und Dual-Regionen gespeichert sind, werden in mindestens zwei geografisch getrennten Bereichen gespeichert, unabhängig von den ihrer Speicherklasse. Diese Redundanz gewährleistet die maximale Verfügbarkeit Ihrer Daten auch bei großen Störungen wie Naturkatastrophen. Dual-Regionen erreichen diese Redundanz mithilfe eines Paars von ausgewählten Regionen. Multiregionen erreichen diese Redundanz durch die Verwendung einer beliebigen Kombination von Rechenzentren in der angegebenen Multiregion, die auch Rechenzentren umfassen kann, die nicht ausdrücklich als verfügbare Regionen aufgeführt sind.

Die Datensynchronisierung zwischen den Buckets erfolgt asynchron. Wenn Sie absolut sichergehen wollen, dass die Daten in eine alternative Region geschrieben wurden, um die RTO- und RPO-Werte zu erreichen, können Sie beispielsweise zwei Buckets mit nur einer Region verwenden. Sie können das Objekt dann entweder doppelt oder in einen Bucket schreiben und den zweiten Bucket vom Cloud Storage kopieren (rewriteTo) lassen.

Strategien zur Problembehebung für eine einzelne Region bei der Verwendung von Cloud Storage

Wenn Sie aufgrund Ihrer Anforderungen nur eine einzige Region verwenden können, z. B. London oder Zürich, sind Sie auf diese Region beschränkt und können nicht allein mit Google Cloud eine Architektur implementieren, die über geografische Standorte redundant ist. In diesem Szenario sollten Sie einen oder mehrere der folgenden Techniken verwenden:

  • Setzen Sie eine Multi-Cloud- oder Hybridstrategie ein. Bei diesem Ansatz können Sie eine andere Cloud-Lösung oder eine lokale Lösung im selben geografischen Bereich wie Ihre Google Cloud-Region auswählen. Sie können Kopien Ihrer Daten in Cloud Storage-Buckets lokal speichern oder Cloud Storage als Ziel für Ihre Sicherungsdaten verwenden.

    Gehen Sie folgendermaßen vor, um diesen Ansatz zu verfolgen:

    • Achten Sie darauf, dass die Anforderungen an die Entfernung erfüllt werden.
    • Wenn Sie AWS als anderen Cloud-Anbieter verwenden, finden Sie in der Anleitung Cloud Storage-Interoperabilität Informationen zur Konfiguration des Zugriffs auf Amazon S3 mit Google Cloud-Tools.
    • Open-Source-Lösungen wie minIO und Ceph für andere Clouds und lokale Lösungen bieten eine lokalen Objektspeicher.
    • Erwägen Sie die Verwendung von Partnerlösungen für einen lokalen Objektspeicher.
    • Erwägen Sie die Implementierung einer Workflowlösung, mit der Sie Daten sowohl in Cloud Storage als auch in einen alternativen Objektspeicherdienst einer anderen Cloud schreiben können.
    • Erwägen Sie die Verwendung von Cloud Composer mit der Befehlszeile gsutil, um Daten aus einem lokalen Objektspeicher in Cloud Storage zu übertragen.
    • Mit dem Transfer Service for On Premises Data können Sie lokal gespeicherte Daten in Cloud Storage kopieren.

  • Implementieren Sie Verschlüsselungstechniken. Wenn Ihre Standortanforderungen den Einsatz von Verschlüsselungstechniken als Problemumgehung erlauben, können Sie Multi-Regionen- oder Dual-Regionen-Buckets verwenden.

Filestore

Filestore bietet verwalteten Dateispeicher, den Sie gemäß Ihrer Standortanforderungen in Regionen und Zonen bereitstellen können.

Verwaltete Datenbanken

Unter Szenarien der Notfallwiederherstellung von Daten werden Methoden zur Implementierung von Sicherungs- und Wiederherstellungsstrategien für verwaltete Datenbankdienste von Google Cloud beschrieben. Zusätzlich zu diesen Methoden müssen Sie auch die Standorteinschränkungen für jeden verwalteten Datenbankdienst berücksichtigen, den Sie in Ihrer Architektur verwenden. Zum Beispiel:

  • Bigtable ist an zonalen Standorten in einer Region verfügbar. Produktionsinstanzen haben mindestens zwei Cluster, die sich in eindeutigen Zonen in der Region befinden müssen. Die Replikation zwischen Clustern in einer Bigtable-Instanz wird automatisch von Google verwaltet. Bigtable synchronisiert Ihre Daten zwischen den Clustern und erstellt eine separate, unabhängige Kopie Ihrer Daten in jeder Zone, in der Ihre Instanz einen Cluster hat. Mit der Replikation kann für eingehenden Traffic ein ein Failover auf einen anderen Cluster in derselben Instanz durchgeführt werden.

  • BigQuery hat Standorteinschränkungen, die vorschreiben, wo Ihre Datasets gespeichert werden. Dataset-Standorte können regional oder multiregional sein. Um Ausfallsicherheit bei einer regionalen Katastrophe zu gewährleisten, müssen Sie Daten an einem anderen geografischen Standort sichern. Bei BigQuery-Multiregionen sollten Sie keine Sicherung in Regionen erstellen, die sich im Bereich der Multiregionen befinden. Wenn Sie „EU (mehrere Regionen)“ auswählen, schließen Sie Zürich und London von der multiregionalen Konfiguration aus. Eine Anleitung zum Implementieren einer DR-Lösung für BigQuery, die das unwahrscheinliche Ereignis eines physischen regionalen Verlusts abdeckt, finden Sie unter Verlust von Regionen.

    In der BigQuery-Dokumentation sind die Auswirkungen einer Einführung von BigQuery-Konfigurationen für einzelne Regionen oder mehrere Regionen erläutert.

  • Sie können Firestore-Daten mit Firestore entweder an einem Standort mit mehreren Regionen oder an einem regionalen Standort speichern. Daten an einem Standort mit mehreren Regionen arbeiten in einer replizierten Konfiguration mit mehreren Zonen und mehreren Regionen. Wählen Sie einen Standort mit mehreren Regionen aus, wenn Ihre Anforderungen an die Standorteinschränkung dies zulassen und Sie die Verfügbarkeit und Langlebigkeit Ihrer Datenbank maximieren möchten. Multi-Region-Standorte können den Verlust ganzer Regionen verkraften und Verfügbarkeit ohne Datenverlust aufrechterhalten. Daten an einem regionalen Standort arbeiten in einer replizierten Konfiguration mit mehreren Zonen.

  • Sie können Cloud SQL für Hochverfügbarkeit konfigurieren. Eine Cloud SQL-Instanz, die für Hochverfügbarkeit konfiguriert wurde, wird auch als regionale Instanz bezeichnet und befindet sich in einer primären und sekundären Zone in der konfigurierten Region. In einer regionalen Instanz besteht die Konfiguration aus einer primären Instanz und einer Standby-Instanz. Informieren Sie sich über die typische Failover-Zeit von der primären zur Standby-Instanz.

    Wenn es Ihre Anforderungen zulassen, können Sie Cloud SQL mit regionenübergreifenden Replikaten konfigurieren. Wenn eine Katastrophe auftritt, kann das Lesereplikat in einer anderen Region hochgestuft werden. Da Lesereplikate für HA im Voraus konfiguriert werden können, müssen sie nach dieser Hochstufung keine zusätzlichen Änderungen vornehmen. Sie können Lesereplikate auch so konfigurieren, dass sie eigene regionenübergreifende Replikate haben, die nach dem Hochstufen des Replikats sofortigen Schutz vor regionalen Ausfällen bieten.

  • Sie können Spanner entweder als regional oder als multiregional konfigurieren. Für jede regionale Konfiguration verwaltet Spanner drei nicht schreibgeschützte Replikate, wobei sich jedes Replikat in der jeweiligen Region in einer anderen Zone von Google Cloud befindet. Jedes nicht schreibgeschützte Replikat enthält eine vollständige Kopie der operativen Datenbank, die Lese-Schreib-Anforderungen und schreibgeschützte Anforderungen verarbeiten kann.

    Spanner greift auf Replikate in verschiedenen Zonen zurück, damit die Datenbank auch dann verfügbar ist, wenn es in einer einzelnen Zone zu einem Ausfall kommt. Eine multiregionale Bereitstellung in Spanner bietet eine konsistente Umgebung über mehrere Regionen hinweg, einschließlich zwei nicht schreibgeschützter Regionen und einer Zeugenregion mit einem Zeugenreplikat. Sie müssen bestätigen, dass die Standorte aller Regionen die Anforderungen an die Standorteinschränkungen erfüllen.

Compute Engine

Compute Engine-Ressourcen sind global, regional oder zonal. Compute Engine-Ressourcen wie VM-Instanzen oder zonale nichtflüchtige Speicher werden als zonale Ressourcen bezeichnet. Andere Ressourcen wie statische externe IP-Adressen sind regional. Regionale Ressourcen können von allen Ressourcen in der Region unabhängig von der Zone genutzt werden, während zonale Ressourcen nur von anderen Ressourcen in der gleichen Zone genutzt werden können.

Die Speicherung von Ressourcen in verschiedenen Zonen in einer Region isoliert diese Ressourcen von den meisten Arten von Ausfällen der physischen Infrastruktur und von Ausfällen der Infrastruktur-Softwaredienste. Die Speicherung von Ressourcen in unterschiedlichen Regionen sorgt auch für größere Fehlerunabhängigkeit. Auf diese Weise können Sie zuverlässige Systeme mit Ressourcen konzipieren, die über verschiedene Fehlerdomains verteilt sind.

Weitere Informationen finden Sie unter Regionen und Zonen.

Lokale Umgebung oder andere Cloud als Produktionsstandort verwenden

Möglicherweise verwenden Sie eine Google Cloud-Region, die Sie daran hindert, Dual- oder Multi-Region-Kombinationen für Ihre DR-Architektur zu verwenden. Um die in diesem Fall geltende Standorteinschränkungen einzuhalten, sollten Sie gegebenenfalls Ihr eigenes Rechenzentrum oder eine andere Cloud als Produktionsstandort oder als Failover-Standort nutzen.

In diesem Abschnitt werden Google Cloud-Produkte beschrieben, die für Hybridarbeitslasten optimiert wurden. DR-Architekturen, die lokale Umgebungen und Google Cloud verwenden, werden in den Szenarien der Notfallwiederherstellung von Anwendungen besprochen.

GKE Enterprise

GKE Enterprise ist die offene Hybrid- und Multi-Cloud-Anwendungsplattform von Google Cloud, mit der Sie Ihre containerbasierten Arbeitslasten sicher ausführen können. GKE Enterprise ermöglicht eine Konsistenz zwischen lokalen und Cloud-Umgebungen. Dadurch können Sie ein konsistentes Betriebsmodell und eine einheitliche Ansicht Ihrer GKE-Cluster (Google Kubernetes Engine) verwenden, unabhängig davon, wo Sie diese ausführen.

Als Teil Ihrer Strategie zur Notfallwiederherstellung vereinfacht GKE Enterprise die Konfiguration und den Betrieb von Hochverfügbarkeits- und Failover-Architekturen über unterschiedliche Umgebungen hinweg (zwischen Google Cloud und lokalen Umgebungen oder anderen Clouds). Sie können Ihre GKE Enterprise-Produktionscluster lokal ausführen; falls ein Notfall eintritt, können Sie ein Failover auf GKE Enterprise-Clustern in Google Cloud ausführen.

GKE Enterprise in Google Cloud hat drei Clustertypen:

  • Cluster mit einer Zone: Ein Einzelzonencluster hat eine einzige Steuerungsebene, die in einer Zone ausgeführt wird. Diese Steuerungsebene verwaltet Arbeitslasten auf Knoten, die in derselben Zone ausgeführt werden.
  • Cluster mit mehreren Zonen: Ein Cluster mit mehreren Zonen hat ein einzelnes Replikat der Steuerungsebene, das in einer einzelnen Zone ausgeführt wird, und Knoten, die in mehreren Zonen ausgeführt werden.
  • Regionale Cluster: Regionale Cluster replizieren Primärcluster und Knoten über mehrere Zonen in einer einzelnen Region. Ein regionaler Cluster in der Region us-east1 erstellt beispielsweise Replikate der Steuerungsebene und der Knoten in den drei us-east1-Zonen: us-east1-b, us-east1-c und us-east1-d.

Regionale Cluster sind Zonenausfällen gegenüber am ausfallsichersten.

Google Cloud VMware Engine

Mit Google Cloud VMware Engine können Sie VMware-Arbeitslasten in der Cloud ausführen. Wenn Ihre lokalen Arbeitslasten VMware-basiert sind, können Sie Ihre DR-Lösung so konzipieren, dass sie auf derselben Virtualisierungslösung ausgeführt wird, die Sie auch lokal einsetzen. Sie können die Region auswählen, die Ihren Standortanforderungen entspricht.

Netzwerk

Wenn Ihr DR-Plan auf der Verlagerung von lokalen Daten zu Google Cloud oder von einem anderen Cloud-Anbieter zu Google Cloud basiert, müssen Sie sich mit Ihrer Netzwerkstrategie befassen. Weitere Informationen finden Sie im Bereich Daten zu und von Google Cloud übertragen des Dokuments "Bausteine der Notfallwiederherstellung".

VPC Service Controls

Bei der Planung Ihrer Notfallwiederherstellungsstrategie müssen Sie dafür sorgen, dass sich die für Ihre Produktionsumgebung geltenden Sicherheitsmaßnahmen auch auf Ihre Failover-Umgebung erstrecken. Mithilfe von VPC Service Controls können Sie einen Sicherheitsbereich von lokalen Netzwerken bis hin zu Ihren Projekten in Google Cloud definieren.

VPC Service Controls ermöglicht zur Kontrolle Ihrer Cloud-Ressourcen den kontextsensitiven Zugriff. Anhand von Attributen wie Nutzeridentität und IP-Adresse können Sie in Google Cloud detaillierte Richtlinien für die Zugriffssteuerung erstellen. Diese Richtlinien tragen dazu bei, dass in den lokalen und Google Cloud-Umgebungen die entsprechenden Sicherheitskontrollen vorhanden sind.

Weitere Informationen