Google PCA: Zuverlässigkeit, Disaster Recovery und Geschäftskontinuität — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Überblick

Ausfallsicherheit, Notfallwiederherstellung (Disaster Recovery, DR) und Geschäftskontinuität stellen sicher, dass Dienste trotz Ausfällen von Komponenten, Zonen oder Regionen die vereinbarten Ziele weiterhin erfüllen. In Google Cloud wird Ausfallsicherheit durch das Verständnis von Ausfalldomänen (zonal, regional und global), die Definition von Wiederherstellungszielen (RTO/RPO), die Auswahl robuster Dienstarchitekturen (z. B. Aktiv-Aktiv) und das rigorose Testen von Wiederherstellungsplänen erreicht. Ihr Design muss die Kritikalität von Diensten auf explizite Verfügbarkeitsziele, Dauerhaftigkeitsgarantien und validierte Wiederherstellungspfade abbilden und dabei Verfügbarkeit, Konsistenz, Kosten und betriebliche Komplexität abwägen. Wichtige Themen sind die Isolierung von Single Points of Failure, die Nutzung von verwalteter Replikation, wo immer möglich, die Automatisierung von Failover-Entscheidungen und die kontinuierliche Überprüfung, ob Annahmen unter produktionsähnlichen Bedingungen zutreffen.

Ausfalldomänen, Standorte und multiregionale Dienste

Verfügbarkeitszonen und Regionen:
- Zonen sind unabhängige Ausfalldomänen innerhalb einer Region. Zonale Ausfälle sind die häufigsten großflächigen Ereignisse, für die Sie planen.
- Regionen sind Sammlungen von Zonen mit Verbindungen mit geringer Latenz. Regionale Ausfälle sind seltener, müssen aber für hochkritische Systeme berücksichtigt werden.
- Designmuster:
  - Innerhalb einer Region (Intra-Region): Platzieren Sie zustandslose Rechenleistung über mindestens zwei Zonen hinweg mithilfe von regionalen verwalteten Instanzgruppen (MIGs).
  - Zwischen Regionen (Inter-Region): Replizieren Sie den Zustand und leiten Sie den Datenverkehr für kritische Dienste um (Failover), die einen regionalen Ausfall nicht tolerieren können.
Multiregionale und globale Dienste:
- Globale Steuerungsebenen: VPC-Netzwerke, Cloud DNS, globales externes HTTP(S)-Load-Balancing und Cloud IAM sind Dienste mit globalem Geltungsbereich, die zur Reduzierung der regionalen Kopplung verwendet werden.
- Die Platzierung der Datenebene ist entscheidend:
  - Cloud Storage: Wählen Sie regionale, Dual-Region- oder Multi-Region-Buckets, die auf die Zugriffsmuster und DR-Anforderungen abgestimmt sind.
  - BigQuery: Datasets befinden sich in einer Region oder Multi-Region; Multi-Region verbessert die Verfügbarkeit der Analyseoberfläche, aber berücksichtigen Sie den Datenstandort (Data Residency) und den ausgehenden Datenverkehr (Egress) für externe Joins.
  - Spanner: Die Instanzkonfiguration (regional oder multiregional) definiert die Replikat-Topologie und das Konsistenzverhalten.
Analyse der Ausfalldomänen:
- Ordnen Sie jede Komponente ihrem Auswirkungsradius (Blast Radius) zu. Beispiele:
  - Zonal: einzelne VM, zonaler GKE-Knotenpool, zonale SSD PD.
  - Regional: Cloud SQL HA Primär- und Standby-Instanzen sind regional; einige Wartungsereignisse können eine ganze Region betreffen.
  - Global: Falsch konfiguriertes IAM oder Cloud DNS betrifft alle Regionen.
- Identifizieren Sie korrelierte Ausfälle wie gemeinsame Abhängigkeiten (z. B. ein NAT-Gateway, eine Memorystore-Instanz) oder durch Menschen verursachtes Risiko (gemeinsames Dienstkonto, einzelner Terraform-State).
- Betrachten Sie Kontingente als Ausfalldomänen; ein Autoscaler, der eine regionale Kontingentgrenze erreicht, ist funktional ausgefallen.

Abwägungen:

Zonenübergreifende Replikation reduziert Ausfallzeiten, verursacht aber zusätzlichen zonenübergreifenden Datenverkehr und Kosten.
Regionsübergreifende Designs reduzieren das RTO, erhöhen aber Latenz, Komplexität und Ausgaben.
Globales Anycast-Load-Balancing vereinfacht das Failover, verschleiert aber fehlerhafte Backends nur, wenn die Systemdiagnosen (Health Checks) präzise sind.

Ziele, Abhängigkeits-Mapping und DR-Validierung

RTO und RPO:
- Recovery Time Objective (RTO): Zielzeit für die Wiederherstellung eines Dienstes. Bestimmt die Automatisierungstiefe, die Standby-Strategie und den Detaillierungsgrad des Runbooks.
- Recovery Point Objective (RPO): Akzeptables Zeitfenster für Datenverlust. Bestimmt die Wahl der Replikations- und Backup-Frequenz.
Dienstkritikalität und Tiering:
- Definieren Sie Tiers (z. B. Tier 0: Sicherheits-/finanzielle Auswirkungen; Tier 1: Umsatz; Tier 2: interne Tools) mit Ziel-SLOs, RTO/RPO und Testfrequenz.
- Koppeln Sie Ausgaben und Komplexität an den Tier; nicht jeder Dienst muss regionsübergreifend sein.
Abhängigkeits-Mapping:
- Inventarisieren Sie Upstream- und Downstream-Abhängigkeiten: Identität (Cloud IAM, SAML IdP), Secrets (Secret Manager, KMS), Netzwerk (DNS, Cloud Interconnect/VPN), Speicher und Datenbanken, Observability, CI/CD und APIs von Drittanbietern.
- Dokumentieren Sie Region, Zone und SLA für jede Abhängigkeit; definieren Sie kompensierende Kontrollen für schwächere Glieder.
Wiederherstellungspläne:
- Erstellen Sie Runbooks und Automatisierungen für Failover/Failback, Datenwiederherstellungen und die Übernahme von Konfigurationen (DNS, Load-Balancer-Backends, Firewall).
- Stellen Sie Berechtigungen und Dienstkonten vorab bereit; bereiten Sie Infrastrukturdefinitionen vor (Staging), um manuelle Freigaben zu eliminieren.
- Unterhalten Sie einen „Break-Glass“-Zugang mit auditierbarer Rechteerweiterung.
Testen der Wiederherstellung:
- Planen Sie routinemäßige Failover für zustandsbehaftete Systeme (z. B. Cloud SQL HA), um die Hochstufung (Promotion) und die Neuverhandlung von Verbindungen zu validieren.
- Führen Sie „Game Days“ durch, die einen zonalen oder regionalen Ausfall simulieren; beziehen Sie dabei Upstream-Anbieter und Ausfälle von IAM/KMS mit ein.
- Verwenden Sie Fault Injection, um Circuit Breaker, Timeouts und Wiederholungsversuche (Retries) zu validieren; überprüfen Sie, ob Autoscaling und Gegendruck (Backpressure) wie beabsichtigt funktionieren.
- Messen Sie RTO/RPO während der Tests kontinuierlich; passen Sie die Architektur an, wenn die Ziele verfehlt werden.

Resiliente Muster für Compute, Datenbanken und Storage

Selbstheilende Rechenleistung mit regionalen MIGs und Load Balancing:
- Verwenden Sie regionale MIGs, um Instanzen mit Autoscaling und Autohealing über Zonen zu verteilen.
- Stellen Sie einen globalen externen HTTP(S)-Load-Balancer als Frontend bereit und richten Sie den Health Check des Backend-Dienstes an der tatsächlichen Bereitschaft aus (z. B. prüft /healthz Abhängigkeiten).
- Erlauben Sie Health Checks durch Firewalls, um ständiges Recyceln von VMs zu vermeiden:

    gcloud compute firewall-rules create allow-lb-health-checks \
      --network=prod-vpc --action=ALLOW --direction=INGRESS \
      --rules=tcp:80,tcp:443 \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --target-tags=web-backend
    ```

  - Vermeiden Sie lokalen Zustand; lagern Sie Sitzungen in Memorystore oder Datenbanken aus; verwenden Sie Connection Draining bei Backends, um laufende Anfragen während des Scale-in zu erhalten.
  - Häufige Fehlermodi: falsch ausgerichtete Health Checks (die zu viel oder zu wenig prüfen), fehlende Firewall-Regeln und Bootstrapping, das von fehlerhaften Downstream-Systemen abhängt.
- Resilienz von Cloud SQL:
  - Hochverfügbarkeit: Primär- und Standby-Instanz in separaten Zonen mit synchroner Festplattenreplikation und automatischem Failover; wählen Sie ein Wartungsfenster und testen Sie Failover.
  - Lesereplikas: Fügen Sie Lesereplikas in derselben Region oder regionsübergreifend hinzu, um Lesezugriffe auszulagern und die RTO bei regionalen Ereignissen zu reduzieren; stufen Sie Replikas während des DR hoch.
  - Backups und PITR:
    - Aktivieren Sie automatisierte tägliche Backups und Point-in-Time-Recovery (PITR) über Binär-/Transaktionsprotokolle mit ausreichender Aufbewahrungsdauer für Compliance und RPO.
    - Validieren Sie Wiederherstellungen in Nicht-Produktionsumgebungen und üben Sie die Hochstufungsverfahren sowie die Aktualisierung der Anwendungs-Connection-Strings.
  - Netzwerk: Bevorzugen Sie private IP für die Produktion; stellen Sie sicher, dass Failover-Tests das Verhalten von DNS/Connection-Pooling validieren.
  - Praxistipp: Führen Sie regelmäßig ein kontrolliertes Failover durch, um zu überprüfen, ob sich die Anwendungs-Pools sauber wieder verbinden.

gcloud sql instances failover prod-sql
```

Spanner-Konfiguration und Resilienz:
- Regionale Instanzen bieten Lese-/Schreibvorgänge mit niedriger Latenz und starker Konsistenz innerhalb einer Region durch den Einsatz von Paxos über Zonen hinweg.
- Multi-regionale Instanzen replizieren über Regionen hinweg mit synchronen Quorum-Schreibvorgängen (starke globale Konsistenz) und optionalen schreibgeschützten Replikas; wählen Sie eine Leader-Region in der Nähe der schreibenden Clients.
- Kompromisse: Multi-regional verbessert RTO/RPO und Leseverfügbarkeit, erhöht aber die Schreiblatenz und die Kosten. Verwenden Sie es für global verteilte, schreibintensive Workloads, die starke Konsistenz erfordern; andernfalls ziehen Sie regionales Spanner oder Cloud SQL mit Replikas in Betracht.
Haltbarkeits- und Wiederherstellungsmuster für Cloud Storage:
- Standortstrategie: Regional für Compute-Lokalität, Dual-Region für Aktiv-Aktiv über zwei Regionen, Multi-Region für breite Verfügbarkeit für globale Benutzer.
- Versionierung: Aktivieren Sie die Objektversionierung, um nach Löschung oder Beschädigung eine Wiederherstellung zu ermöglichen; kombinieren Sie dies mit Lebenszyklusregeln zur Kostenverwaltung.
- Aufbewahrung: Wenden Sie Aufbewahrungsrichtlinien auf Bucket-Ebene und, falls erforderlich, Aufbewahrungssperren (Retention Locks) für Compliance an; verwenden Sie ereignisbasierte Sperren (Event-based Holds) für die Datensatzverwaltung.
- Backup-Muster: Projektübergreifende Buckets mit separaten Administratoren mindern versehentliches Löschen und die Ausweitung von Berechtigungen. Exportieren Sie für Datenbanken logische Backups in Cloud Storage in einem separaten Projekt.
- Beispiel für eine Lebenszyklusregel zum Löschen von Versionen, die älter als 90 Tage sind:

    {
      "rule": [
        {
          "action": { "type": "Delete" },
          "condition": { "age": 90, "isLive": false }
        }
      ]
    }
    ```

    Anwenden mit:

gsutil lifecycle set lifecycle.json gs://prod-backups
```

Wiederherstellung: Führen Sie Kataloge kritischer Objekte und testen Sie Wiederherstellungen; bei großen Datensätzen stellen Sie Wiederherstellungen in temporären Buckets bereit (Staging), um Namenskollisionen zu vermeiden und die Integrität zu validieren.

Traffic-Management, Multi-Site-Strategien und kontinuierliche Resilienz

Multi-Site-Strategien:
- Active-active: Traffic wird gleichzeitig von mehreren Regionen aus bedient; erfordert symmetrische Datenreplikation und konfliktfreie Schreibvorgänge. Beste RTO/RPO; höchste Kosten und Komplexität.
- Active-passive: Ein „heißer“ primärer und ein bereiter sekundärer Standort; Daten werden kontinuierlich repliziert, der Traffic wird im Fehlerfall umgeschaltet. Gutes Gleichgewicht zwischen Kosten und RTO.
- Warm Standby: Ein herunterskalierter sekundärer Standort mit vorsynchronisierten Daten; erfordert ein Hochskalieren beim Failover; moderate RTO und Kosten.
- Pilot Light: Minimale Replikation kritischer Daten und Infrastrukturdefinitionen; die meisten Komponenten werden beim Failover bereitgestellt; lange RTO, niedrige laufende Kosten.
- Cold Standby: Nur periodische Backups; Wiederherstellung im Fehlerfall; längste RTO, niedrigste Kosten.
DNS- und Traffic-Management-Failover:
- Bevorzugen Sie zustandsbasiertes Routing auf Layer 7 mit dem globalen externen HTTP(S)-Load-Balancer. Dieser führt Zustandsprüfungen pro Backend durch und leitet den Traffic von fehlerhaften Zonen oder Regionen weg, ohne dass DNS-Änderungen erforderlich sind.
- Verwenden Sie DNS-Einträge mit niedrigem TTL nur als grobe Failover-Steuerung oder zum Umschalten zwischen getrennten Load-Balancer-VIPs; beachten Sie, dass DNS-Caching bedeutet, dass ein Failover nicht sofort erfolgt.
- Für private Dienste verwenden Sie internes HTTP(S)-Load-Balancing mit regionalen Failover-Mustern sowie privates DNS, das Sie bei Bedarf programmatisch aktualisieren können.
Graceful-Degradation-Muster:
- Implementieren Sie Feature-Flags, um nicht kritische Funktionalitäten unter Last zu deaktivieren.
- Verwenden Sie Circuit Breaker, Timeouts, Wiederholungsversuche mit Jitter und Bulkheads, um Ausfälle zu lokalisieren.
- Stellen Sie einen schreibgeschützten Modus bereit, wenn Schreibpfade beeinträchtigt sind; reihen Sie Schreibvorgänge für einen späteren Abgleich in eine Warteschlange ein.
- Wenden Sie Ratenbegrenzungen auf Clients an und nutzen Sie Gegendruck (Backpressure), um kaskadierende Ausfälle zu verhindern.
Chaos-Testing und kontinuierliche Verbesserung:
- Fehlerinjektion auf der Netzwerk- (Latenz, Paketverlust) und Anwendungsebene validiert, dass Resilienzkontrollen wie geplant ausgelöst werden.
- Game Days operationalisieren die Wiederherstellung teamübergreifend; sie umfassen Alarmierung (Paging), Ausführung von Runbooks und Post-Mortems mit konkreten Korrekturmaßnahmen.
- Verfolgen Sie Fehlerbudgets und SLOs; passen Sie Kapazität, Wiederholungsstrategien und Replikationskonfigurationen an, wie es die Daten erfordern.
Abwägungen zwischen Verfügbarkeit, Konsistenz, Kosten und Komplexität:
- Verfügbarkeit vs. Konsistenz: Starke globale Konsistenz (z. B. Spanner Multi-Regional) kann die Schreiblatenz erhöhen; Eventual Consistency (z. B. asynchrone Replikate) kann die Latenz verbessern, birgt aber das Risiko veralteter Lesevorgänge (Stale Reads).
- Kosten vs. RTO/RPO: Dual-Region-Speicher und multiregionale Datenbanken erhöhen die Ausgaben, minimieren aber Datenverlust und Ausfallzeiten.
- Komplexität vs. Zuverlässigkeit: Jeder Failover-Mechanismus, jeder Replikationsstrom und jede Routing-Regel muss betrieben und getestet werden; halten Sie die Designs so einfach wie nötig, um die Ziele zu erreichen.

Praktisches Problemszenario

Acme Tickets, ein schnell wachsendes Online-Ticketing-Unternehmen, muss den kontinuierlichen Betrieb seiner Kauf-API und seines Veranstaltungskatalogs bei regionalen Ausfällen sicherstellen und dabei strenge RTO/RPO-Vorgaben einhalten (RTO ≤ 5 Minuten, RPO ≤ 1 Minute). Der Stack umfasst zustandslose Microservices, eine relationale Bestelldatenbank, eine Analyse-Pipeline und statische Medieninhalte.

Service-Tiers, SLOs und Wiederherstellungsziele definieren

Begründung: Klassifizieren Sie die Kauf-API und die Bestelldatenbank als Tier 0 (RTO 5 Min., RPO 1 Min.), den Katalog als Tier 1 (RTO 15 Min., RPO 5 Min.) und die Analyse als Tier 2 (Best Effort). Dies richtet Kosten und Komplexität an den Geschäftsauswirkungen aus.

Regionale Platzierung und Multi-Site-Strategie wählen

Begründung: Bereitstellung im Active-Active-Modus über us-central1 und us-east1 für zustandslose Dienste, um die RTO zu minimieren; Verwendung von Active-Passive für die Bestelldatenbank, um Schreiblatenz und Kosten auszugleichen.

Regionale MIGs und globales HTTP(S)-Load-Balancing implementieren

Begründung: Zwei regionale MIGs (eine pro Region), die sich jeweils über mindestens zwei Zonen erstrecken. Eine einzige globale Anycast-VIP leitet den Traffic über zustandsgeprüfte Backend-Dienste und schaltet fehlerhafte Regionen automatisch aus.

Zustand externalisieren und Selbstheilung konfigurieren

Begründung: Sitzungen in Memorystore mit regionsübergreifenden Lesereplikaten für den Katalog speichern und die Dienste zustandslos halten, damit MIG-Autohealing und Rolling Updates sicher sind. Zustandsprüfungen verweisen auf /healthz, das kritische nachgelagerte Systeme validiert.

Cloud SQL for PostgreSQL mit HA und regionsübergreifender Lesereplika bereitstellen

Begründung: Verwenden Sie HA in der primären Region für zonale Resilienz und aktivieren Sie PITR mit ausreichender Aufbewahrungsdauer. Erstellen Sie eine regionsübergreifende Lesereplika in der sekundären Region und ein getestetes Runbook, um diese bei einem regionalen Ausfall hochzustufen und so eine RPO ≤ 1 Minute mit minimalem Schreibverlust zu erreichen.

Routinemäßige Datenbank-Failover-Tests planen

Begründung: Führen Sie monatlich kontrollierte Failover durch, um das Wiederverbindungsverhalten der Anwendung und die Hochstufung der Replika zu validieren. Dies begegnet einem häufigen Fehlermodus, bei dem Replikate bei realen Vorfällen nie hochgestuft werden.

Statische Medien in einem Dual-Region Cloud Storage-Bucket mit Versionierung und Aufbewahrung platzieren

Begründung: Dual-Region stellt die Objektverfügbarkeit über zwei Regionen hinweg sicher; Versionierung schützt vor versehentlichem Überschreiben/Löschen. Wenden Sie Lebenszyklusregeln an, um alte Versionen auslaufen zu lassen und die Kosten zu kontrollieren.

Zustandsprüfungen und Egress-Traffic mit Firewall und Kontingenten schützen

Begründung: Erstellen Sie explizite Firewall-Regeln für die Zustandsprüfungen des Load Balancers und überwachen Sie die regionalen Instanzkontingente, um Blockaden des Autoscalers während eines Failovers zu verhindern.

DNS als grobe Steuerung mit niedrigem TTL implementieren

Begründung: Während der globale Load Balancer das zustandsbasierte Routing übernimmt, pflegen Sie einen A-Eintrag mit niedrigem TTL zu einer Standby-VIP für eine manuelle Notfallumschaltung, wobei die Einschränkungen des DNS-Cache zu beachten sind.

DR-Runbooks automatisieren und durch Game Days validieren

Begründung: Verwenden Sie Cloud Scheduler, um synthetischen Traffic auszulösen, und Cloud Monitoring SLOs, um das Verhalten während vierteljährlicher Game Days mit injizierten Fehlern (z. B. Blockieren des interregionalen Traffics, Beenden von Knoten) zu bestätigen. Erfassen Sie RTO/RPO-Metriken und verfeinern Sie die Verfahren.

Backups sichern und trennen

Begründung: Exportieren Sie tägliche logische Backups der Bestelldatenbank in einen Cloud Storage-Bucket in einem separaten Projekt mit Aufbewahrungssperren (Retention Locks); stellen Sie sie regelmäßig auf einer Staging-Instanz wieder her, um Integrität und Zeitaufwand zu validieren.

Graceful Degradation implementieren

Begründung: Wenn die Bestelldatenbank beeinträchtigt ist, schalten Sie den Katalog in den schreibgeschützten Modus, reihen Sie Schreibvorgänge für einen späteren Abgleich in eine Warteschlange ein und schalten Sie nicht kritische Funktionen ab. Dies verhindert kaskadierende Ausfälle und erhält einen Teildienst aufrecht.

Diese Architektur bietet ein automatisiertes regionales Failover für zustandslose Dienste, ein kontrolliertes und getestetes Failover für zustandsbehaftete Komponenten und verifizierte Wiederherstellungsprozesse, die die Ziele der Geschäftskontinuität von Acme Tickets erfüllen.

← Sicherheit · Alle Domänen · Migration →

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