Dieses Dokument ist der zweite Teil einer Reihe, in der die Notfallwiederherstellung (Disaster Recovery, DR) in Google Cloud behandelt wird. Das Thema dieses Teils sind Dienste und Produkte, die Sie als Bausteine für den DR-Plan verwenden können. Hierzu zählen neben Google Cloud-Produkten auch plattformübergreifend einsetzbare Produkte.
Die Reihe besteht aus folgenden Teilen:
- Leitfaden zur Planung der Notfallwiederherstellung
- Bausteine der Notfallwiederherstellung (dieser Artikel)
- Szenarien der Notfallwiederherstellung für Daten
- Szenarien der Notfallwiederherstellung von Anwendungen
- Architektur der Notfallwiederherstellung von Arbeitslasten mit Standortbeschränkung entwickeln
- Anwendungsfälle für die Notfallwiederherstellung: Datenanalyseanwendungen mit Standortbeschränkung
- Architektur der Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur
Einführung
Google Cloud bietet eine breite Palette von Produkten, die Sie als Teil der Architektur für die Notfallwiederherstellung (Disaster Recovery, DR) verwenden können. In diesem Abschnitt werden die in Google Cloud am häufigsten als DR-Bausteine verwendeten DR-Features erläutert.
Viele der Dienste haben Funktionen zum Erreichen einer hohen Verfügbarkeit. Die Implementierung von Hochverfügbarkeit überschneidet sich nicht in allen Bereichen mit der Notfallwiederherstellung. Zahlreiche Aspekte der Hochverfügbarkeit gelten jedoch auch für das Entwerfen eines DR-Plans. Durch ein Erhöhen der Verfügbarkeit kann sich beispielsweise die Betriebszeit von Architekturen verbessern. Folglich verringern sich mitunter die Auswirkungen kleinerer Fehler, wie etwa der Ausfall einer einzelnen VM. Weitere Informationen zum Zusammenhang von Notfallwiederherstellung und Hochverfügbarkeit finden Sie im Leitfaden zur Planung der Notfallwiederherstellung.
In den folgenden Abschnitten werden diese DR-Bausteine von Google Cloud beschrieben. Außerdem erfahren Sie, wie Sie damit Ihre DR-Ziele erreichen können.
Computing und Speicher
Compute Engine |
|
Cloud Storage |
|
GKE |
|
Compute Engine
Compute Engine ist ein wichtiges Tool von Google Cloud zum Bereitstellen von VM-Instanzen. Neben dem Konfigurieren, Starten und Überwachen von Compute Engine-Instanzen kommen zum Umsetzen eines DR-Plans in der Regel diverse damit verbundene Features zum Einsatz.
Sie können bei DR-Szenarien durch Angabe des Löschschutz-Flags ein versehentliches Löschen von VMs verhindern. Dies ist besonders beim Hosting zustandsorientierter Dienste wie Datenbanken nützlich. Wie Sie möglichst niedrige RTO- und RPO-Werte erreichen, erfahren Sie in den Best Practices für den Entwurf robuster Systeme.
Sie können eine Instanz konfigurieren, in der die Anwendung vorinstalliert ist. Anschließend speichern Sie diese Konfiguration als benutzerdefiniertes Image. Das benutzerdefinierte Image kann den gewünschten RTO widerspiegeln.
Instanzvorlagen
Sie können die Konfigurationsdetails der VM mit Instanzvorlagen von Compute Engine speichern und anschließend Instanzen aus vorhandenen Instanzvorlagen erstellen. Die Vorlagen bieten Ihnen die Möglichkeit, eine beliebige Anzahl von Instanzen zu starten, die entsprechend der gewünschten DR-Zielumgebung konfiguriert sind. Instanzvorlagen werden global repliziert, sodass Sie die Instanz jederzeit an beliebiger Stelle in Google Cloud mit derselben Konfiguration neu erstellen können.
Als Basis für neue Instanzvorlagen können Sie ein benutzerdefiniertes Image oder vorhandene VM-Instanzen verwenden.
Weitere Informationen zur Verwendung von Compute Engine-Images erhalten Sie im Abschnitt Image-Konfiguration und Bereitstellungsgeschwindigkeit ausbalancieren.
Verwaltete Instanzgruppen
Verwaltete Instanzgruppen sorgen in Verbindung mit Cloud Load Balancing dafür, dass Traffic an Gruppen mit identisch konfigurierten Instanzen verteilt wird, die zwischen Zonen kopiert werden. Mehr zu Cloud Load Balancing erfahren Sie später in diesem Dokument. Verwaltete Instanzgruppen ermöglichen die Verwendung von Funktionen wie Autoscaling und der automatischen Reparatur. Die verwaltete Instanzgruppe kann Instanzen dadurch automatisch löschen und neu erstellen.
Reservierungen
Compute Engine ermöglicht die Reservierung von VM-Instanzen in einer bestimmten Zone mithilfe von benutzerdefinierten oder vordefinierten Maschinentypen mit oder ohne zusätzliche GPUs oder lokale SSDs. Sie sollten in Ihren DR-Zielzonen Reservierungen erstellen, um die Kapazität Ihrer geschäftskritischen Arbeitslasten für die Notfallwiederherstellung zu gewährleisten. Ohne Reservierungen kann es vorkommen, dass Sie nicht die On-Demand-Kapazität erhalten, die Sie benötigen, um das Wiederherstellungszeitziel zu erreichen. Reservierungen können in kalten, warmen oder heißen DR-Szenarien nützlich sein. Dadurch können Sie Wiederherstellungsressourcen für ein Failover verfügbar machen, um niedrigere RTO-Anforderungen zu erfüllen, ohne sie im Voraus vollständig konfigurieren und bereitstellen zu müssen.
Nichtflüchtige Speicher und Snapshots
Nichtflüchtige Speicher sind dauerhafte Netzwerkspeichergeräte, auf die Ihre Instanzen zugreifen können. Aufgrund der Unabhängigkeit von den Instanzen können Sie nichtflüchtige Speicher trennen und verschieben. Ihre Daten bleiben dadurch auch nach dem Löschen der Instanzen erhalten.
Sie haben die Möglichkeit, inkrementelle Sicherungen oder Snapshots von Compute Engine-VMs zu erstellen und zwischen Regionen zu kopieren. Nichtflüchtige Speicher lassen sich so nach einem Notfall neu erstellen. Durch das Erstellen von Snapshots nichtflüchtiger Speicher können Sie außerdem Datenverlusten infolge von Nutzerfehlern vorbeugen. Snapshots werden inkrementell erstellt. Die Erstellung dauert nur wenige Minuten und ist auch bei Festplatten möglich, die mit laufenden Instanzen verbunden sind.
Nichtflüchtige Speicher sind von Haus aus redundant. Ihre Daten bleiben dadurch bei Geräteausfällen erhalten und sind auch während Wartungsarbeiten am Rechenzentrum verfügbar. Nichtflüchtige Speicher sind entweder zonale oder regionale Speicher. Regionale nichtflüchtige Speicher replizieren Schreibvorgänge in zwei Zonen einer Region. Bei einem zonalen Ausfall kann eine VM-Sicherungsinstanz das Hinzufügen eines regionalen nichtflüchtigen Speichers in der sekundären Zone erzwingen. Weitere Informationen finden Sie unter Hochverfügbarkeitsoptionen mit regionalen nichtflüchtigen Speichern.
Live-Migration
Bei Live-Migrationen werden VM-Instanzen selbst bei Ereignissen wie Software- oder Hardwareaktualisierungen auf dem Hostsystem weiter ausgeführt. Bei Live-Migrationen mit Compute Engine werden laufende Instanzen zu einem anderen Host in derselben Zone migriert. Ein Neustart der VMs erübrigt sich dadurch. Google kann auf diese Weise für den Schutz und die Zuverlässigkeit der Infrastruktur erforderliche Wartungsarbeiten ausführen, ohne dass Ihre VMs unterbrochen werden.
Importtool für virtuelle Laufwerke
Mit dem Importtool für virtuelle Laufwerke lassen sich Dateiformate wie VMDK, VHD und RAW importieren, um neue Compute Engine-VMs zu erstellen. Sie können damit Compute Engine-VMs mit der gleichen Konfiguration wie Ihre lokalen virtuellen Maschinen erstellen. Dies ist hilfreich, wenn Sie bei Software, die in den Images bereits installiert ist, keine Compute Engine-Images von den Binärdateien konfigurieren können.
Cloud Storage
Cloud Storage ist ein hervorragender Objektspeicher für Sicherungsdateien. Sie können damit je nach Anwendungsfall gemäß dem folgenden Diagramm unterschiedliche Speicherklassen nutzen.
In DR-Szenarien sind speziell Nearline Storage, Coldline Storage und Archive Storage von Bedeutung. Mit diesen Speicherklassen können Sie die Speicherkosten gegenüber Standard Storage reduzieren. Für das Abrufen der in diesen Klassen gespeicherten Daten oder Metadaten fallen jedoch zusätzliche Gebühren an. Außerdem wird grundsätzlich eine Mindestspeicherdauer berechnet. Nearline wurde für Sicherungsszenarien entwickelt, in denen der Zugriff maximal einmal pro Monat erfolgt. Die Klasse eignet sich optimal, um regelmäßige DR-Belastungstests durchzuführen und gleichzeitig die Kosten niedrig zu halten.
Nearline, Coldline und Archive sind für einen seltenen Zugriff optimiert, was bei der Entwicklung des Preismodells entsprechend berücksichtigt wurde. In diesen Klassen wird grundsätzlich eine Mindestspeicherdauer berechnet. Zusätzliche Gebühren fallen an, wenn Daten oder Metadaten vor Ablauf der Mindestspeicherdauer abgerufen werden.
Um Ihre Daten in einem Cloud Storage-Bucket vor versehentlichem oder böswilligem Löschen zu schützen, können Sie die Funktion Vorläufig löschen verwenden, um gelöschte und überschriebene Objekte für einen bestimmten Zeitraum aufzubewahren.
Mit dem Storage Transfer Service können Sie Daten aus Amazon S3- oder HTTP-basierten Quellen in Cloud Storage importieren. In DR-Szenarien bietet Ihnen der Storage Transfer Service folgende Möglichkeiten:
- Sichern der Daten anderer Speicheranbieter in einem Cloud Storage-Bucket
- Verschieben der Daten aus einem Bucket in einer Dual- oder Multi-Region in einen Bucket in einer einzelnen Region, um die Kosten für das Speichern von Sicherungen zu senken.
Filestore
Filestore-Instanzen sind vollständig verwaltete NFS-Dateiserver zur Verwendung mit Anwendungen, die auf Compute Engine-Instanzen oder GKE-Clustern ausgeführt werden.
Filestore-Instanzen sind zonale Ressourcen, das heißt zonenübergreifende Replikationen werden nicht unterstützt. Eine Filestore-Instanz ist nicht verfügbar, wenn die Zone, in der sie sich befindet, inaktiv ist. Wir empfehlen, dass Sie Ihre Daten regelmäßig sichern. Synchronisieren Sie dazu Ihr Filestore-Volume mit dem Befehl gsutil rsync mit einer Filestore-Instanz in einer anderen Region. Dazu muss ein Job für die Ausführung auf Compute Engine-Instanzen oder GKE-Clustern geplant werden.
In DR-Szenarien können Anwendungen den Zugriff auf Filestore-Volumes schnell fortsetzen. Dazu wechseln sie in Failover-Regionen zu Filestore, ohne dass der Wiederherstellungsprozess abgeschlossen werden muss. Der RTO-Wert dieser DR-Lösung hängt weitgehend von der Häufigkeit des geplanten Jobs ab.
GKE
GKE ist eine verwaltete, produktionsfertige Umgebung für die Bereitstellung von Containeranwendungen. Sie können mit GKE hochverfügbare Systeme orchestrieren und folgende Funktionen nutzen:
- Automatische Knotenreparatur: Wenn aufeinanderfolgende Systemdiagnosen eines Knotens etwa 10 Minuten lang fehlschlagen, wird in GKE ein Reparaturvorgang für den Knoten initiiert.
- Aktivitätsprüfung: Sie können eine Aktivitätsprüfung festlegen, die regelmäßig an GKE meldet, dass der Pod ausgeführt wird. Wenn der Pod die Prüfung nicht besteht, kann er neu gestartet werden.
- Nichtflüchtige Volumes: Datenbanken müssen über die Lebensdauer eines Containers hinaus bestehen bleiben können. Durch die Abstraktion nichtflüchtiger Volumes, die einem nichtflüchtigen Speicher in Compute Engine zugeordnet wird, können Sie die Speicherverfügbarkeit unabhängig von den einzelnen Containern aufrechterhalten.
- Mehrzonen- und regionale Cluster: Sie können Kubernetes-Ressourcen wahlweise auf mehrere Zonen innerhalb einer Region verteilen.
- Mit Multi-Cluster-Gateway können Sie gemeinsame Load-Balancing-Ressourcen für mehrere GKE-Cluster in verschiedenen Regionen konfigurieren.
- Mit Backup for GKE können Sie Arbeitslasten in GKE-Clustern sichern und wiederherstellen.
Netzwerke und Datenübertragung
Cloud Load Balancing |
|
Traffic Director |
|
Cloud DNS |
|
Cloud Interconnect |
|
Cloud Load Balancing
Cloud Load Balancing sorgt durch die Verteilung von Nutzeranfragen auf mehrere Instanzen für eine hohe Verfügbarkeit in Compute Engine. Sie können Cloud Load Balancing mit Systemdiagnosen konfigurieren, um die Verfügbarkeit von Instanzen zu prüfen und Trafficweiterleitungen an fehlerhafte Instanzen zu vermeiden.
Mit Cloud Load Balancing benötigen Sie nur eine global zugängliche IP-Adresse für Ihre Compute Engine-Instanzen. Die Instanzen Ihrer Anwendung können in verschiedenen Regionen (z. B. in Europa und in den USA) ausgeführt werden. Endnutzer werden zur nächstgelegenen Instanz weitergeleitet. Neben dem Load-Balancing im Internet verfügbarer Dienste können Sie auch ein internes Load-Balancing für Dienste hinter einer privaten IP-Adresse konfigurieren. Diese IP-Adresse ist nur für VM-Instanzen innerhalb Ihrer Virtual Private Cloud (VPC) zugänglich.
Traffic Director
Mit Traffic Director stellen Sie eine vollständig verwaltete Trafficsteuerungsebene für Ihr Service Mesh bereit. Traffic Director verwaltet die Konfiguration von Dienstproxys, die sowohl in Compute Engine als auch in GKE ausgeführt werden. Stellen Sie einen Dienst in mehreren Regionen bereit, um für Hochverfügbarkeit zu sorgen. Traffic Director lagert die Systemdiagnosen des Dienstes aus und leitet eine Failover-Konfiguration der Dienstproxys ein, wodurch der Traffic an fehlerfreie Instanzen weitergeleitet wird.
Traffic Director unterstützt auch erweiterte Konzepte zur Trafficsteuerung, Schutzschaltungen und Fehlerinjektion. Bei Schutzschaltungen werden Limits für Anfragen an einen bestimmten Dienst erzwungen. Danach wird verhindert, dass Anfragen den Dienst erreichen, um den Dienst vor einer weiteren Verschlechterung zu schützen. Mithilfe der Fehlerinjektion kann Traffic Director Verzögerungen verursachen oder einen Teil der Anfragen an einen Dienst abbrechen. So können Sie ganz leicht testen, wie gut Ihr Dienst mit Anfrageverzögerungen oder abgebrochenen Anfragen umgehen kann.
Cloud DNS
Cloud DNS ermöglicht die programmatische Verwaltung von DNS-Einträgen im Rahmen eines automatisierten Wiederherstellungsprozesses. Cloud DNS nutzt das globale Google-Netzwerk aus Anycast-Nameservern, um DNS-Zonen über redundante Standorte auf der ganzen Welt bereitzustellen. Nutzer profitieren dadurch von Hochverfügbarkeit und geringer Latenz.
Wenn Sie DNS-Einträge lokal verwalten, können Sie VMs in Google Cloud aktivieren, um diese Adressen über die Weiterleitung von Cloud DNS aufzulösen.
Cloud DNS unterstützt Richtlinien, um zu konfigurieren, wie es auf DNS-Anfragen reagiert. Sie können beispielsweise Routingrichtlinien konfigurieren, um ein Failover auf eine Sicherungskonfiguration zu ermöglichen und Hochverfügbarkeit zu gewährleisten oder DNS-Anfragen basierend auf ihrem geografischen Standort weiterzuleiten.
Cloud Interconnect
Mit Cloud Interconnect können Sie Daten aus anderen Quellen nach Google Cloud übertragen. Dieses Produkt wird später im Bereich Daten an und von Google Cloud übertragen erläutert.
Verwaltung und Monitoring
| Cloud Status Dashboard |
|
Google Cloud Observability |
|
Cloud Status Dashboard
Das Cloud-Status-Dashboard zeigt die aktuelle Verfügbarkeit von Google Cloud-Diensten an. Sie können auf der Seite den Status prüfen und einen RSS-Feed abonnieren, um über Neuigkeiten zu einem Dienst informiert zu werden.
Cloud Monitoring
Cloud Monitoring erfasst Messwerte, Ereignisse und Metadaten von Google Cloud, AWS, gehosteten Betriebszeittests, der Anwendungsinstrumentierung und diversen weiteren Anwendungskomponenten. Sie können Benachrichtigungen an Drittanbietertools wie Slack oder PagerDuty konfigurieren, um Administratoren Aktualisierungen zeitnah zur Verfügung zu stellen. Als weitere Verwendungsmöglichkeit von Cloud Monitoring für das DR können Sie eine Pub/Sub-Senke konfigurieren und mithilfe von Cloud Functions-Funktionen automatisch auf Cloud Monitoring-Benachrichtigungen reagieren.
Plattformübergreifende DR-Bausteine
Wenn Sie Arbeitslasten auf mehreren Plattformen ausführen, können Sie den operativen Aufwand unter anderem durch die Auswahl von Tools reduzieren, die mit allen Plattformen kompatibel sind. In diesem Abschnitt werden verschiedene plattformunabhängige Tools und Dienste erläutert, die sich für plattformübergreifende DR-Szenarien eignen.
Deklarative Vorlagentools
Mit deklarativen Vorlagentools können Sie die plattformübergreifende Bereitstellung der Infrastruktur automatisieren. Terraform ist ein beliebtes deklaratives Vorlagentool.
Tools zur Konfigurationsverwaltung
Für große oder komplexe DR-Infrastrukturen empfehlen wir plattformunabhängige Softwareverwaltungstools wie Chef und Ansible. Mit diesen Tools lassen sich reproduzierbare Konfigurationen unabhängig davon anwenden, wo Rechenarbeitslasten ausgeführt werden.
Objektspeicher
Für die Notfallwiederherstellung werden in der Regel Kopien von Objekten in Objektspeichern verschiedener Cloudanbieter angelegt. Ein plattformübergreifendes Tool hierfür ist boto. Die Open-Source-Python-Bibliothek dient als Schnittstelle zu Amazon S3 und Cloud Storage.
Orchestrator-Tools
Auch Container können als DR-Bausteine betrachtet werden. Sie können darin Dienste verpacken und eine plattformübergreifende Konsistenz implementieren.
Für die Arbeit mit Containern verwenden Sie in der Regel einen Orchestrator. Kubernetes dient nicht nur zur Verwaltung von Containern in Google Cloud (mithilfe von GKE). Sie können damit auch containerbasierte Arbeitslasten auf mehreren Plattformen orchestrieren. Google Cloud, AWS und Microsoft Azure bieten verwaltete Versionen von Kubernetes.
Die Trafficverteilung auf Kubernetes-Cluster, die auf verschiedenen Cloudplattformen ausgeführt werden, ist mit einem DNS-Dienst möglich, der gewichtete Datensätze unterstützt und Systemdiagnosen durchführt.
Wichtig ist außerdem, dass Sie das Image in die Zielumgebung ziehen können. Daher ist wichtig, dass Sie im Notfall Zugriff auf Ihre Image-Registry haben. Als plattformunabhängige Lösung bietet sich hierfür Artifact Registry an.
Datenübertragung
Die Datenübertragung ist in plattformübergreifenden DR-Szenarien eine wichtige Komponente. Zum Entwerfen, Implementieren und Testen plattformübergreifender DR-Szenarien sollten Sie daher unbedingt realistische Datenübertragungsmodelle verwenden. Datenübertragungsszenarien werden im nächsten Abschnitt behandelt.
DR-Muster
In diesem Bereich werden basierend auf den bereits erläuterten Bausteinen einige der gängigsten Muster für DR-Architekturen beschrieben.
Daten an und von Google Cloud übertragen
Ein wichtiger Aspekt des DR-Plans ist die Datenübertragungsgeschwindigkeit für Übertragungen an und von Google Cloud. Deployment Manager eignet sich daher optimal zum Definieren einer DR-Wiederherstellungsumgebung, die Sie zuverlässig in der gewünschten Region anlegen können. In diesem Abschnitt werden Netzwerk- und Google Cloud-Dienste beschrieben, die einen guten Durchsatz gewährleisten.
Wenn Sie Google Cloud als Wiederherstellungsstandort für lokal oder in einer anderen Cloud-Umgebung ausgeführte Arbeitslasten verwenden, sind folgende Aspekte zu berücksichtigen:
- Die Verbindungsmethode zu Google Cloud
- Die zum Interconnect-Anbieter verfügbare Bandbreite
- Die vom Anbieter bereitgestellte Bandbreite für eine direkte Verbindung zu Google Cloud
- Die Art der sonstigen über diese Verbindung zu übertragenen Daten
Wenn Sie für die Datenübertragung eine öffentliche Internetverbindung verwenden, ist der Netzwerkdurchsatz nicht vorhersehbar, da er von der Kapazität und vom Routing des ISP abhängt. Der ISP bietet möglicherweise nur ein begrenztes oder gar kein SLA an. Dafür sind diese Verbindungen aber relativ kostengünstig.
Cloud Interconnect bietet mehrere Möglichkeiten, eine Verbindung zu Google und Google Cloud herzustellen:
- Mit Cloud VPN können IPsec-VPN-Tunnel zwischen einem VPC-Netzwerk von Google Cloud und einem Zielnetzwerk erstellt werden. Der Traffic zwischen den beiden Netzwerken ist durch ein VPN-Gateway verschlüsselt und wird anschließend von dem anderen VPN-Gateway wieder entschlüsselt. Mit HA VPN können Sie hochverfügbare VPN-Verbindungen mit einem SLA von 99,99 % erstellen. Außerdem ist das Einrichten im Vergleich zur Erstellung redundanter VPNs einfacher.
- Direct Peering bietet minimale Netzwerk-Hops zu den öffentlichen IP-Adressen von Google. Sie können Direct Peering verwenden, damit Internettraffic zwischen Ihrem Netzwerk und den Edge Points of Presence (PoPs) von Google ausgetauscht werden kann.
- Dedicated Interconnect stellt eine direkte physische Verbindung zwischen Ihrem lokalen Netzwerk und dem Netzwerk von Google bereit. Es bietet neben einem SLA auch einen konsistenteren Durchsatz für umfangreiche Datenübertragungen. Schaltungen haben entweder 10 Gbit/s oder 100 Gbit/s und werden in einer der Colocations-Einrichtungen von Google beendet.
Mit einer höheren Bandbreite können Sie die Zeit für die Datenübertragung von der lokalen Umgebung zu Google Cloud reduzieren. Die folgende Tabelle zeigt die Steigerung der Geschwindigkeit beim Upgrade von 10 Gbit/s auf 100 Gbit/s.
- Partner Interconnect bietet ähnliche Funktionen wie Dedicated Interconnect, allerdings mit einer Schaltungsgeschwindigkeit von weniger als 10 Gbit/s. Siehe Unterstützte Dienstanbieter.
Das folgende Diagramm bietet eine Übersicht über die optimalen Übertragungsmethoden für die jeweils an Google Cloud zu sendenden Datenmengen.
Sie können den Übertragungszeit-Rechner verwenden, um zu verstehen, wie viel Zeit eine Übertragung angesichts der Größe des zu verschiebenden Datasets und der für die Übertragung verfügbaren Bandbreite in Anspruch nehmen könnte. Weitere Informationen zur Datenübertragung im Rahmen der DR-Planung finden Sie unter Große Datasets übertragen.
Image-Konfiguration und Bereitstellungsgeschwindigkeit ausbalancieren
Beim Konfigurieren eines Maschinen-Images für die Bereitstellung neuer Instanzen sollten Sie berücksichtigen, wie sich die Konfiguration auf die Bereitstellungsgeschwindigkeit auswirkt. Es gilt, einen Kompromiss zwischen dem Umfang der Image-Vorkonfiguration, den Kosten für die Image-Pflege und der Bereitstellungsgeschwindigkeit zu finden. Bei einer minimalen Konfiguration eines Maschinen-Images verlängert sich die Startzeit der Instanzen, die das Image verwenden. Dies liegt daran, dass dafür Abhängigkeiten heruntergeladen und installiert werden müssen. Bei einem umfassend konfigurierten Maschinen-Image verkürzt sich hingegen die Startzeit, aber das Image muss häufiger aktualisiert werden. Die Startdauer einer voll funktionsfähigen Instanz steht in direktem Zusammenhang mit dem RTO.
Konsistentes Maschinen-Image in Hybridumgebungen
Wenn Sie eine Hybridlösung wie Lokal-zu-Cloud oder Cloud-zu-Cloud implementieren, ist es wichtig, dass Sie die VM-Konsistenz zwischen Produktumgebungen wahren.
Wenn ein vollständig konfiguriertes Image erforderlich ist, erwägen Sie beispielsweise Packer, um identische Maschinen-Images für mehrere Plattformen zu erstellen. Sie können dieselben Skripts mit plattformspezifischen Konfigurationsdateien verwenden. Mit Packer können Sie die Version der Konfigurationsdatei prüfen und dadurch die in der Produktionsumgebung bereitgestellte Version verfolgen.
Sie können auch Konfigurationsverwaltungstools wie Chef, Puppet, Ansible oder Saltstack verwenden, um feinere Anpassungen bei Instanzen zu konfigurieren. Erstellen Sie je nach Bedarf Basis-Images bzw. minimal oder vollständig konfigurierte Images. Wie Sie diese Tools effektiv nutzen, erfahren Sie unter Zero-to-Deploy with Chef on GCP.
Sie können auch vorhandene Images wie etwa Amazon AMI-, Virtualbox- und RAW-Laufwerk-Images manuell konvertieren und in Compute Engine importieren.
Mehrstufigen Speicher implementieren
Mehrstufiger Speicher wird in der Regel verwendet, um die letzte Sicherung in einem schneller abrufbaren Speicher abzulegen und ältere Sicherungen nach und nach zu einem kostengünstigeren, langsamer abrufbaren Speicher zu migrieren. Je nachdem, ob Ihre Daten von Google Cloud oder einer lokalen Umgebung übertragen werden, setzen Sie das Muster mithilfe von Cloud Storage auf unterschiedliche Art um. Sie migrieren Objekte in beiden Fällen zwischen Buckets verschiedener Storage-Klassen – normalerweise von Standard- zu kostengünstigeren Nearline-Speicherklassen.
Wenn die Quelldaten lokal generiert werden, erfolgt die Implementierung ähnlich wie in der folgenden Abbildung:
Sie können das Ändern der Speicherklasse der Objekte in einem Bucket auch mithilfe von Regeln zur Verwaltung des Objektlebenszyklus automatisieren.
IP-Adresse für private Instanzen beibehalten
Es ist üblich, eine einzelne VM-Instanz zur Bereitstellung vorzuhalten. Falls Sie die VM ersetzen müssen, muss die Ersatz-VM sich exakt wie die ursprüngliche VM verhalten. Daher sollten Sie die von Clients verwendete IP-Adresse für die Verbindung mit der neuen Instanz beibehalten.
Die einfachste Möglichkeit dazu ist, eine verwaltete Instanzgruppe einzurichten, die nur eine Instanz verwaltet. Die verwaltete Instanzgruppe ist mit einem internen (privaten) Load-Balancer versehen. So wird sichergestellt, dass für die Instanz immer dieselbe IP-Adresse verwendet wird, unabhängig davon, ob es sich um das Original-Image oder ein Ersatz-Image handelt.
Technologiepartner
Google hat ein robustes Partnernetzwerk, das Sicherungs- und DR-Anwendungsfälle in Verbindung mit Google Cloud unterstützt. Kunden verwenden Partnerlösungen speziell für folgende Zwecke:
- Zum Sichern lokaler Daten in Google Cloud. Als Speicherziel wird für die meisten lokalen Sicherungsplattformen Cloud Storage verwendet. Mit diesem Ansatz lassen sich Band- und andere Speichergeräte ersetzen.
- Zum Umsetzen eines DR-Plans für die Migration lokaler Daten zu Google Cloud. Unsere Partner unterstützen Sie dabei, sekundäre Rechenzentren zu beseitigen und Google Cloud als DR-Standort zu verwenden.
- Zum Implementieren von DR und Sicherungen für cloudbasierte Arbeitslasten.
Weitere Informationen zu Partnerlösungen finden Sie unter Partner auf der Google Cloud-Website.
Nächste Schritte
- Geografie und Regionen in Google Cloud
Weitere Artikel dieser DR-Reihe:
- Leitfaden zur Planung der Notfallwiederherstellung
- Szenarien der Notfallwiederherstellung für Daten
- Szenarien der Notfallwiederherstellung von Anwendungen
- Architektur der Notfallwiederherstellung von Arbeitslasten mit Standortbeschränkung entwickeln
- Anwendungsfälle für die Notfallwiederherstellung: Datenanalyseanwendungen mit Standortbeschränkung
- Architektonische Notfallwiederherstellung bei Ausfällen der Cloud-Infrastruktur
Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center