Google ACE: Zuverlässigkeit, Backup und Notfallwiederherstellung — Lernleitfaden

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Teil des Google Associate Cloud Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Zuverlässigkeit, Backup und Disaster Recovery in Google Cloud erfordern ein bewusstes Design, das Fehlerdomänen, Datenschutzmechanismen, Traffic-Management und Betriebsbereitschaft berücksichtigt. Dieser Abschnitt erklärt, wie Dienste über Zonen und Regionen hinweg strukturiert werden, wie zustandsbehaftete Daten geschützt und wiederhergestellt werden und wie Wiederherstellungsziele durch disziplinierte Runbooks und kontinuierliche Resilienztests validiert werden. Er skizziert auch die Kompromisse bei DR-Strategien und die Kapazitätsplanung, um sicherzustellen, dass die Plattform innerhalb der definierten Wiederherstellungszeitziele (RTO) und Wiederherstellungspunktziele (RPO) wiederhergestellt werden kann.

Fehlerdomänen und regionales Design

• Zonen, Regionen und Multi-Region-Dienste

  • Zonen sind die kleinsten unabhängigen Fehlerdomänen. Ein einzelner Zonenausfall sollte einen regionalen Dienst nicht unterbrechen.
  • Regionen fassen unabhängige Zonen mit Verbindungen mit geringer Latenz zusammen. Regionale Designs überstehen Zonenausfälle, aber nicht unbedingt vollständige regionale Ereignisse.
  • Multi-Region-Dienste replizieren über Regionen hinweg und schützen so vor einem regionalen Ausfall, was mit höheren Kosten und potenziell höherer Schreiblatenz verbunden ist.
  • Designprinzip: Vermeiden Sie Single Points of Failure in der kleinsten Fehlerdomäne, die für Sie relevant ist. Wenn Ihr RTO/RPO das Überstehen eines Zonenausfalls erfordert, stellen Sie die Anwendung in mindestens zwei Zonen bereit. Um regionale Ausfallsicherheit zu gewährleisten, stellen Sie aktive Komponenten in mehreren Regionen bereit oder nutzen Sie Multi-Region-Dienste.

• Managed Instance Groups (MIG) und Selbstheilung

  • Bevorzugen Sie regionale MIGs, um Instanzen über Zonen innerhalb einer Region zu verteilen. Dies entschärft Zonenausfälle ohne separate Tools.
  • Systemdiagnosen (Health Checks) des Load Balancers entfernen fehlerhafte VMs aus dem Traffic. Die automatische Reparatur (Autohealing) von MIGs ersetzt fehlerhafte oder nicht reagierende VMs. Verwenden Sie beides.
  • Verwenden Sie HTTP(S)-Systemdiagnosen auf Anwendungsebene, die Readiness-Endpunkte und Abhängigkeiten überprüfen. Eine TCP-Prüfung validiert nur die Erreichbarkeit des Ports.
  • Fehlermodus bei Fehlkonfiguration der automatischen Reparatur: Die alleinige Verwendung einer Systemdiagnose des Load Balancers verhindert zwar den Traffic zu einer fehlerhaften Instanz, erstellt diese aber nicht neu. Konfigurieren Sie die eigene Systemdiagnose der MIG für den Austausch der Instanz und eine anfängliche Verzögerung, um vorzeitige Neustarts während des Hochfahrens zu vermeiden.

Beispiel:

• Erstellen Sie eine Anwendungs-Systemdiagnose mit 10-Sekunden-Intervallen und 3 Fehler-Schwellenwerten, um die Selbstheilung nach ca. 30 Sekunden auszulösen: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Fügen Sie die Systemdiagnose für die automatische Reparatur zu einer regionalen MIG hinzu: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Überlegungen zu Multi-Region-Setups

  • Global External HTTP(S) Load Balancing unterstützt Backends in mehreren Regionen mit automatischem Failover auf Basis von Systemdiagnosen.
  • Die Zustandssynchronisierung über Regionen hinweg ist der entscheidende Kompromiss. Der Durchsatz bei Aktiv-Aktiv-Setups ist hoch, aber Konsistenz und Konfliktlösung müssen sorgfältig entworfen werden. Aktiv-Passiv ist einfacher, hat aber ein langsameres Failover und potenziell einen größeren RPO.

Resilienzbetrieb und kontinuierliche Verbesserung

• RTO, RPO, Wiederherstellungspläne und Runbooks

  • RTO definiert, wie schnell ein Dienst wiederhergestellt sein muss; RPO definiert den akzeptablen Datenverlust. Leiten Sie diese aus einer Business-Impact-Analyse ab.
  • Ordnen Sie jede Systemkomponente spezifischen Mechanismen zu, die RTO/RPO erfüllen: HA für zonale Ausfälle, regionenübergreifende Replikation für regionale Ausfälle, Backups für Datenkorruption und Speicherklasse/Replikation für Langlebigkeit (Durability).
  • Pflegen Sie Runbooks: präzise Schritte, Befehle, Zugriff auf Anmeldeinformationen, Überprüfungen zur Integritätsvalidierung und Entscheidungsbäume. Speichern Sie sie in einem versionierten, zugriffsgesteuerten Repository und üben Sie sie regelmäßig.
  • Validierung der Wiederherstellung: Planen Sie Übungen, um die tatsächlichen RTO/RPO-Werte zu messen, die Datenintegrität zu validieren und Maßnahmen zur Verbesserung zu sammeln. Testen Sie sowohl Wiederherstellungen mit kleinem Umfang (Tabelle, Festplatte) als auch eine vollständige Standortwiederherstellung.

• DR-Strategien und Kompromisse

  • Aktiv-Aktiv: Alle Regionen bedienen den Datenverkehr; minimales RTO und niedriges RPO bei korrekt konzipierter Datensynchronisation. Höhere Komplexität und Kosten; erfordert Konfliktlösung und globales Load Balancing.
  • Aktiv-Passiv: Die primäre Region ist aktiv; die sekundäre ist „warm“ (Warm Standby) und empfängt replizierte Daten. Moderate Kosten; RTO im Bereich von Minuten bis zu zehn Minuten; RPO ungleich Null, abhängig von der Replikation.
  • Pilot-Light: Minimale kritische Dienste laufen in der sekundären Region (Datenbankreplikation, minimaler Anwendungs-Footprint). RTO im Stundenbereich; kosteneffizient; sorgfältige Orchestrierung erforderlich, um die Rechenleistung während des Failovers hochzuskalieren.
  • Cold-Standby: Infrastruktur als Code definiert, aber nicht bereitgestellt. RTO im Tagebereich; niedrigste Kosten; Risiko von Überraschungen durch Drift, Kontingente und Kapazitätsengpässe.

• Chaos-Tests und Ausfallsimulationen

  • Simulieren Sie regelmäßig Instanzabstürze, blockierte Prozesse, fehlgeschlagene Health Checks, volle Festplatten und Ausfälle von Abhängigkeiten. Verwenden Sie Tools oder Skripte, um Instanzen zu beenden, den ausgehenden Datenverkehr zu Backends zu blockieren oder Latenz auf der Proxy-Ebene einzuschleusen.
  • Validieren Sie die automatische Reparatur (Autohealing) von MIGs und die Entfernung durch den LB, indem Sie den Health-Endpunkt absichtlich fehlschlagen lassen. Bestätigen Sie das Verhalten beim Ersetzen und die Wiederherstellungszeitpläne.
  • Üben Sie die regionale Evakuierung: Leiten Sie den Datenverkehr von Backends in einer Region ab (Drain), beobachten Sie das Failover des globalen Load Balancers und überprüfen Sie zustandsbehaftete Abhängigkeiten in der sekundären Region.
  • Kontinuierliche Verbesserung: Erfassen Sie Metriken für die mittlere Zeit bis zur Erkennung (MTTD), die Failover-Zeit und den Datenverlust während der Tests. Priorisieren Sie Korrekturen, die RTO/RPO reduzieren und manuelle Schritte eliminieren.

Praktisches Problemszenario

Brightlane Retail betreibt eine E-Commerce-Plattform in us-central1 mit strengen Verfügbarkeitsanforderungen und einem RPO von vier Stunden für Bestelldaten. Die Geschäftsführung fordert, dass ein zonaler Ausfall ohne Ausfallzeit und ein regionaler Ausfall mit minimalen Auswirkungen auf die Kunden überstanden wird.

Vorgehensweise:

1. Implementieren Sie eine regionale MIG mit HTTP-Autohealing und einem globalen HTTP(S) Load Balancer
   • Begründung: Eine regionale MIG verteilt Instanzen über mehrere Zonen, und HTTP-Health-Checks auf Anwendungsebene ermöglichen die Selbstreparatur nach drei fehlgeschlagenen Prüfungen von je 10 Sekunden. Der globale Load Balancer entfernt automatisch fehlerhafte VMs und leitet den Datenverkehr auf fehlerfreie Zonen um.
   • Befehle:

undefined

undefined

2. Aktivieren Sie Cloud SQL HA mit regionenübergreifendem Lesereplikat und PITR
   • Begründung: Regionale HA bietet zonale Ausfallsicherheit mit automatischem Failover. Ein Lesereplikat in us-east1 ermöglicht regionales DR mit einem RPO, das zwar nicht null, aber begrenzt ist. Die Aktivierung von PITR (binäres Logging für MySQL) begegnet logischer Datenkorruption, indem eine Wiederherstellung zu einem bestimmten Zeitpunkt ermöglicht wird.
   • Befehle:

undefined

undefined

3. Schützen Sie Objektdaten mit Dual-Region Cloud Storage und Lebenszyklusrichtlinien

   • Begründung: Produktbilder und statische Inhalte werden für regionale Resilienz in einem Dual-Region-Bucket gespeichert. Lebenszyklus-Übergänge verschieben ältere Artefakte nach Coldline, um die Kosten zu optimieren, und Versionierung sowie Aufbewahrungsrichtlinien verhindern das versehentliche Löschen kritischer Assets.
   • Schritte: Aktivieren Sie die Objektversionierung (Object Versioning), legen Sie eine 30-tägige Aufbewahrungsrichtlinie für kritische Buckets fest und wenden Sie Lebenszyklusregeln an, um nicht kritische Build-Artefakte nach 90 Tagen nach Coldline zu verschieben und nach einem Jahr zu löschen.

4. Planen Sie PD-Snapshots und erstellen Sie Maschinen-Images für zustandsbehaftete Dienste

   • Begründung: Inkrementelle Snapshots von VM-Festplatten bieten schnelle, absturzkonsistente Wiederherstellungsoptionen. Maschinen-Images erfassen Boot- und Konfigurationsdaten, um die Wiederherstellung von App-Servern während eines regionalen Failovers zu beschleunigen. Snapshot-Zeitpläne gewährleisten konsistente, richtliniengesteuerte Backups.
   • Befehle:

undefined

undefined

undefined

5. Definieren Sie RTO/RPO und kodifizieren Sie DR-Runbooks und IaC

   • Begründung: Legen Sie ein Service-Level-RTO von 15 Minuten für Web/API und ein RPO von vier Stunden für Bestellungen fest. Runbooks spezifizieren die Vorgehensweisen für das Traffic-Failover, die Heraufstufung (Promotion) des Cloud SQL-Lesereplikats, DNS-Notfallpläne und Verifizierungsschritte. Infrastructure as Code (Terraform/Deployment Manager) gewährleistet deterministische Wiederherstellungen und reduziert manuelle Fehler.

6. Stellen Sie Kapazität und Kontingente in der sekundären Region bereit

   • Begründung: Erstellen Sie Reservierungen für kritische VM-Typen, stellen Sie ein Standby-Load-Balancer-Backend, SSL-Zertifikate und NAT-Kapazität vorab bereit und überprüfen Sie die Kontingente für Compute, SQL, Weiterleitungsregeln und KMS in us-east1. Dies verhindert Kapazitätsengpässe während eines Failovers.

7. Validieren Sie die Wiederherstellung durch Chaos-Übungen und dokumentieren Sie Verbesserungen

   • Begründung: Vierteljährliche Übungen zu zonalen Ausfällen validieren das Verhalten von MIG und LB; halbjährliche regionale Evakuierungen stufen das Lesereplikat in us-east1 herauf, leiten den globalen LB auf die Backends in us-east1 um und messen RTO/RPO. Die Ergebnisse führen zu Verbesserungen, wie z. B. der Reduzierung manueller Schritte oder der Erhöhung der Replikatkapazität.

Durch die Befolgung dieser Schritte erreicht Brightlane Retail eine zonale Hochverfügbarkeit mit automatisierter Selbstreparatur und eine regionale DR-Strategie mit definierten, getesteten Runbooks. Dadurch wird sichergestellt, dass die Bestelldaten ein RPO von vier Stunden einhalten und die Anwendungsdienste innerhalb der angestrebten RTO-Grenzen wiederhergestellt werden.

← Sicherheit · Alle Domänen · Kostenmanagement →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →