Google PCA: Betrouwbaarheid, Disaster Recovery en Bedrijfscontinuïteit — Studiegids

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

Onderdeel van de Google Professional Cloud Architect — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Betrouwbaarheid, disaster recovery (DR) en bedrijfscontinuïteit zorgen ervoor dat services aan de afgesproken doelstellingen blijven voldoen, ondanks storingen van componenten, zones of regio’s. Op Google Cloud wordt betrouwbaarheid gerealiseerd door inzicht in storingsdomeinen (zonaal, regionaal en globaal), het definiëren van hersteldoelstellingen (RTO/RPO), het selecteren van veerkrachtige servicearchitecturen (bijv. active-active) en het rigoureus testen van herstelplannen. Uw ontwerp moet de criticaliteit van services koppelen aan expliciete beschikbaarheidsdoelen, duurzaamheidsgaranties en gevalideerde hersteltrajecten, waarbij een balans wordt gevonden tussen beschikbaarheid, consistentie, kosten en operationele complexiteit. Kernthema’s zijn het isoleren van single points of failure, het waar mogelijk gebruiken van beheerde replicatie, het automatiseren van failover-beslissingen en het continu valideren dat aannames standhouden onder productie-achtige omstandigheden.

Storingsdomeinen, Locaties en Multi-Regionale Services

Beschikbaarheidszones en regio’s:
- Zones zijn onafhankelijke storingsdomeinen binnen een regio. Zonale storingen zijn de meest voorkomende grootschalige gebeurtenissen waarvoor u ontwerpt.
- Regio’s zijn verzamelingen van zones met verbindingen met lage latentie. Regionale storingen zijn zeldzamer, maar moeten worden overwogen voor systemen met een hoge criticaliteit.
- Ontwerppatronen:
  - Intra-regionaal: Plaats stateless compute over ten minste twee zones via regionale managed instance groups (MIG’s).
  - Inter-regionaal: Repliceer state en failover-verkeer voor kritieke services die geen regionaal verlies kunnen tolereren.
Multi-regionale en globale services:
- Globale control planes: VPC-netwerken, Cloud DNS, global external HTTP(S) load balancing en Cloud IAM zijn services met een globale scope die worden gebruikt om regionale koppeling te verminderen.
- De plaatsing van het data-plane is van belang:
  - Cloud Storage: kies regionale, dual-region of multi-region buckets die zijn afgestemd op toegangspatronen en DR-behoeften.
  - BigQuery: datasets bevinden zich in een regio of multi-regio; multi-regio verbetert de beschikbaarheid van het analyseoppervlak, maar houd rekening met dataresidentie en egress voor externe joins.
  - Spanner: de instantieconfiguratie (regionaal of multi-regionaal) definieert de replicatopologie en het consistentiegedrag.
Analyse van storingsdomeinen:
- Breng van elk component de blast radius in kaart. Voorbeelden:
  - Zonaal: enkele VM, zonale GKE node pool, zonale SSD PD.
  - Regionaal: Cloud SQL HA primary+standby zijn regionaal; sommige onderhoudsgebeurtenissen kunnen een hele regio beïnvloeden.
  - Globaal: een verkeerd geconfigureerde IAM of Cloud DNS heeft invloed op alle regio’s.
- Identificeer gecorreleerde storingen zoals gedeelde afhankelijkheden (bijv. één NAT-gateway, één Memorystore-instantie) of door de mens veroorzaakt risico (gedeeld serviceaccount, enkele Terraform-state).
- Beschouw quota’s als storingsdomeinen; een autoscaler die een regionaal quotumlimiet bereikt, is functioneel buiten werking.

Afwegingen:

Replicatie tussen zones vermindert downtime, maar voegt verkeer en kosten tussen zones toe.
Ontwerpen die meerdere regio’s omspannen, verlagen de RTO, maar verhogen de latentie, complexiteit en uitgaven.
Globale anycast load balancing vereenvoudigt failover, maar maskeert onjuist functionerende backends alleen als de health checks nauwkeurig zijn.

Doelstellingen, Afhankelijkheidsmapping en DR-Validatie

RTO en RPO:
- Recovery Time Objective (RTO): de beoogde tijd om een service te herstellen. Bepaalt de diepgang van automatisering, de stand-by-status en de detaillering van het runbook.
- Recovery Point Objective (RPO): het acceptabele venster voor dataverlies. Bepaalt de keuze voor replicatie- en back-upcadans.
Service-criticaliteit en tiering:
- Definieer tiers (bijv. Tier 0: veiligheids-/financiële impact; Tier 1: omzet; Tier 2: interne tools) met beoogde SLO’s, RTO/RPO en testfrequentie.
- Koppel uitgaven en complexiteit aan de tier; niet elke service hoeft cross-regionaal te zijn.
Afhankelijkheidsmapping:
- Inventariseer upstream- en downstream-afhankelijkheden: identiteit (Cloud IAM, SAML IdP), secrets (Secret Manager, KMS), netwerken (DNS, Cloud Interconnect/VPN), opslag en DB’s, observability, CI/CD en API’s van derden.
- Documenteer de regio, zone en SLA voor elke afhankelijkheid; definieer compenserende maatregelen voor zwakkere schakels.
Herstelplannen:
- Maak runbooks en automatisering voor failover/failback, dataherstel en configuratiepromotie (DNS, load balancer backends, firewall).
- Provisioneer vooraf permissies en serviceaccounts; zet infrastructuurdefinities klaar om handmatige blokkades te elimineren.
- Onderhoud break-glass-toegang met auditeerbare escalatie.
Hersteltesten:
- Plan routinematige failovers voor stateful systemen (bijv. Cloud SQL HA) om promotie en heronderhandeling van verbindingen te valideren.
- Organiseer game days die een zonale of regionale storing simuleren; neem hierin ook upstream-providers en storingen van IAM/KMS mee.
- Gebruik fault injection om circuit breakers, timeouts en retries te valideren; verifieer dat autoscaling en backpressure naar behoren werken.
- Meet continu de RTO/RPO tijdens tests; pas de architectuur aan wanneer doelstellingen niet worden gehaald.

Patronen voor Veerkrachtige Compute, Databases en Storage

Zelfherstellende compute met regionale MIG’s en load balancing:
- Gebruik regionale MIG’s om instances te verdelen over zones met autoscaling en autohealing.
- Plaats een global external HTTP(S) load balancer aan de voorkant met een backend service health check die is afgestemd op de daadwerkelijke gereedheid (bijv. /healthz controleert afhankelijkheden).
- Sta health checks toe door firewalls om constant herstarten van VM’s te voorkomen:

    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
    ```

  - Vermijd lokale state; externaliseer sessies naar Memorystore of databases; gebruik connection draining op backends om in-flight requests te behouden tijdens scale-in.
  - Veelvoorkomende faalscenario's: niet goed afgestemde health checks (te veel of te weinig controleren), ontbrekende firewallregels en bootstrapping die afhankelijk is van ongezonde downstreams.
- Veerkracht van Cloud SQL:
  - Hoge beschikbaarheid: primary en standby in afzonderlijke zones met synchrone schijfreplicatie en automatische failover; selecteer een onderhoudsvenster en test failovers.
  - Read replica's: voeg read replica's toe in dezelfde regio of cross-region om reads te offloaden en de RTO te verlagen bij regionale incidenten; promoveer replica's tijdens DR.
  - Back-ups en PITR:
    - Activeer geautomatiseerde dagelijkse back-ups en point-in-time recovery (PITR) via binary/transaction logs met voldoende retentie voor compliance en RPO.
    - Valideer restores naar een niet-productieomgeving, en oefen promotieprocedures en het bijwerken van de connection string van de applicatie.
  - Netwerk: geef de voorkeur aan een private IP voor productie; zorg ervoor dat failover-tests het gedrag van DNS/connection pooling valideren.
  - Operationele tip: voer periodiek een gecontroleerde failover uit om te verifiëren dat applicatiepools correct opnieuw verbinden.

gcloud sql instances failover prod-sql
```

Spanner-configuratie en veerkracht:
- Regionale instances bieden low-latency, strongly consistent reads/writes binnen een regio met behulp van Paxos over zones heen.
- Multi-regionale instances repliceren over regio’s met synchrone quorum writes (sterke globale consistentie) en optionele read-only replica’s; kies een leader-regio dicht bij de writers.
- Afwegingen: multi-regionaal verbetert RTO/RPO en leesbeschikbaarheid, maar verhoogt de write-latency en kosten. Gebruik dit voor wereldwijd gedistribueerde, schrijf-intensieve workloads die sterke consistentie vereisen; overweeg anders regionale Spanner of Cloud SQL met replica’s.
Duurzaamheids- en herstelpatronen voor Cloud Storage:
- Locatiestrategie: regional voor nabijheid van compute, dual-region voor active-active over twee regio’s, multi-region voor brede beschikbaarheid voor wereldwijde gebruikers.
- Versioning: schakel object versioning in om te herstellen van verwijdering of corruptie; combineer met lifecycle-regels om de kosten te beheren.
- Retentie: pas retentiebeleid toe op bucket-niveau en, indien nodig, retention locks voor compliance; gebruik event-based holds voor records management.
- Back-uppatronen: cross-project buckets met een aparte beheerder beperken het risico op onbedoelde verwijdering en privilege escalation. Exporteer voor databases logische back-ups naar Cloud Storage in een afzonderlijk project.
- Voorbeeld van een lifecycle-regel om versies ouder dan 90 dagen te verwijderen:

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

    Toepassen met:

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

Herstel: onderhoud catalogi van kritieke objecten en test restores; voor grote datasets, voer restores uit naar tijdelijke buckets om naamconflicten te voorkomen en de integriteit te valideren.

Verkeersbeheer, Multi-Site Strategieën en Continue Veerkracht

Multi-site strategieën:
- Actief-actief: verkeer wordt gelijktijdig vanuit meerdere regio’s bediend; vereist symmetrische datareplicatie en conflictvrije schrijfacties. Beste RTO/RPO; hoogste kosten en complexiteit.
- Actief-passief: een ‘hot’ primaire en een gereedstaande secundaire site; data wordt continu gerepliceerd, verkeer wordt omgeschakeld bij een storing. Goede balans tussen kosten en RTO.
- Warm standby: een afgeschaalde secundaire site met vooraf gesynchroniseerde data; vereist opschalen bij failover; gemiddelde RTO en kosten.
- Pilot light: minimale replicatie van kritieke data en infrastructuurdefinities; de meeste componenten worden bij failover geprovisioneerd; lange RTO, lage doorlopende kosten.
- Cold standby: alleen periodieke back-ups; herstellen bij een storing; langste RTO, laagste kosten.
DNS en failover voor verkeersbeheer:
- Geef de voorkeur aan op health gebaseerde routing op Layer 7 met de global external HTTP(S) load balancer. Deze voert per-backend health checks uit en leidt verkeer weg van ongezonde zones of regio’s zonder DNS-wijzigingen.
- Gebruik DNS-records met een lage TTL alleen als een grofmazig failover-mechanisme of om te schakelen tussen afzonderlijke load balancer VIP’s; begrijp dat DNS-caching betekent dat een failover niet onmiddellijk is.
- Gebruik voor private services Internal HTTP(S) Load Balancing met regionale failover-patronen plus private DNS die u indien nodig programmatisch kunt bijwerken.
Patronen voor ‘graceful degradation’:
- Implementeer feature flags om niet-kritieke functionaliteit uit te schakelen onder hoge belasting.
- Gebruik circuit breakers, timeouts, retries met jitter en bulkheads om storingen te isoleren.
- Bied een read-only modus aan wanneer schrijfpaden zijn aangetast; plaats schrijfacties in een wachtrij voor latere verwerking.
- Pas rate limiting toe op clients en gebruik ‘backpressure’ om kettingreacties van storingen te voorkomen.
Chaostesten en continue verbetering:
- Foutinjectie op het netwerk (latency, packet loss) en de applicatielaag valideert dat veerkrachtmaatregelen zoals ontworpen worden geactiveerd.
- Game days operationaliseren herstelprocedures over teams heen; dit omvat paging, de uitvoering van runbooks en postmortems met concrete corrigerende acties.
- Volg error budgets en SLO’s; pas capaciteit, retry-strategieën en replicatieconfiguraties aan op basis van de verzamelde data.
Afwegingen tussen beschikbaarheid, consistentie, kosten en complexiteit:
- Beschikbaarheid vs. consistentie: sterke globale consistentie (bijv. Spanner multi-regional) kan de write-latency verhogen; eventual consistency (bijv. asynchrone replica’s) kan de latency verbeteren maar brengt het risico van verouderde ‘reads’ met zich mee.
- Kosten vs. RTO/RPO: dual-region storage en multi-regionale databases verhogen de kosten maar minimaliseren dataverlies en downtime.
- Complexiteit vs. betrouwbaarheid: elk failover-mechanisme, elke replicatiestroom en elke routeringsregel moet worden beheerd en getest; houd ontwerpen zo eenvoudig als nodig is om de doelstellingen te behalen.

Praktisch Probleemscenario

Acme Tickets, een snelgroeiend online ticketbedrijf, moet continue operaties garanderen tijdens regionale storingen voor zijn aankoop-API en evenementencatalogus, met inachtneming van strikte RTO/RPO (RTO ≤ 5 minuten, RPO ≤ 1 minuut). De stack omvat stateless microservices, een relationele orderdatabase, een analytics-pipeline en statische media-assets.

Definieer service tiers, SLO’s en hersteldoelstellingen

Rationale: Classificeer de aankoop-API en de orderdatabase als Tier 0 (RTO 5m, RPO 1m), de catalogus als Tier 1 (RTO 15m, RPO 5m) en analytics als Tier 2 (best effort). Dit stemt de kosten en complexiteit af op de bedrijfsimpact.

Kies regionale plaatsing en multi-site strategie

Rationale: Implementeer een actief-actief-opstelling over us-central1 en us-east1 voor stateless services om de RTO te minimaliseren; gebruik een actief-passief-opstelling voor de orderdatabase om een balans te vinden tussen write-latency en kosten.

Implementeer regionale MIG’s en global HTTP(S) load balancing

Rationale: Twee regionale MIG’s (één per regio), elk verspreid over ten minste twee zones. Een enkele globale anycast VIP routeert verkeer via backend services met health checks, waardoor ongezonde regio’s automatisch worden uitgesloten.

Externaliseer state en configureer self-healing

Rationale: Sla sessies op in Memorystore met cross-region read replica’s voor de catalogus, en houd services stateless zodat MIG autohealing en rolling updates veilig zijn. Health checks verwijzen naar /healthz, dat kritieke downstreams valideert.

Provisioneer Cloud SQL for PostgreSQL met HA en een cross-region read replica

Rationale: Gebruik HA in de primaire regio voor zonale veerkracht en schakel PITR in met voldoende retentie. Maak een cross-region read replica aan in de secundaire regio en een getest runbook om deze te promoveren bij een regionale storing, waarmee een RPO ≤ 1 minuut wordt behaald met minimaal schrijfverlies.

Plan routinematige database-failovertests

Rationale: Voer maandelijks gecontroleerde failovers uit om het herverbindingsgedrag van de applicatie en de promotie van de replica te valideren. Dit pakt een veelvoorkomend storingsscenario aan waarbij replica’s tijdens echte incidenten nooit worden gepromoveerd.

Plaats statische media in een dual-region Cloud Storage bucket met versioning en retentie

Rationale: Dual-region garandeert de beschikbaarheid van objecten in twee regio’s; versioning beschermt tegen onbedoeld overschrijven/verwijderen. Pas lifecycle-regels toe om oude versies te laten verlopen en de kosten te beheersen.

Bescherm health checks en egress met firewall en quota’s

Rationale: Maak expliciete firewallregels voor de health checks van de load balancer en monitor de regionale instance-quota’s om te voorkomen dat de autoscaler vastloopt tijdens een failover.

Implementeer DNS als een grofmazig controlemechanisme met een lage TTL

Rationale: Hoewel de global load balancer de op health gebaseerde routing afhandelt, onderhoud een A-record met een lage TTL naar een standby VIP voor een handmatige nood-cutover, rekening houdend met de beperkingen van DNS-caching.

Automatiseer DR-runbooks en valideer via game days

Rationale: Gebruik Cloud Scheduler om synthetisch verkeer te genereren en Cloud Monitoring SLO’s om het gedrag te bevestigen tijdens driemaandelijkse game days met geïnjecteerde fouten (bijv. het blokkeren van interregionaal verkeer, het beëindigen van nodes). Leg RTO/RPO-metrieken vast en verfijn de procedures.

Beveilig en scheid back-ups

Rationale: Exporteer dagelijks logische back-ups van de orderdatabase naar een Cloud Storage bucket in een apart project met retention locks; herstel periodiek naar een staging-instance om de integriteit en timing te valideren.

Implementeer ‘graceful degradation’

Rationale: Als de orderdatabase is gedegradeerd, schakel de catalogus over naar read-only, plaats schrijfacties in een wachtrij voor latere verwerking en schakel niet-kritieke functies uit. Dit voorkomt kettingreacties van storingen en handhaaft een gedeeltelijke service.

Deze architectuur levert geautomatiseerde regionale failover voor stateless services, gecontroleerde en geteste failover voor stateful componenten, en geverifieerde herstelprocessen die voldoen aan de bedrijfscontinuïteitsdoelstellingen van Acme Tickets.

← Beveiliging · Alle domeinen · Migratie →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →