Google ACE: Betrouwbaarheid, back-up en disaster recovery — Studiegids

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

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

Overzicht

Betrouwbaarheid, back-up en disaster recovery op Google Cloud vereisen een doelbewust ontwerp over storingsdomeinen, mechanismen voor gegevensbescherming, verkeersbeheer en operationele gereedheid heen. Dit gedeelte legt uit hoe u services over zones en regio’s kunt structureren, hoe u stateful data kunt beschermen en herstellen, en hoe u hersteldoelstellingen kunt valideren met gedisciplineerde runbooks en continue veerkrachttesten. Het schetst ook de afwegingen van DR-strategieën en capaciteitsplanning om ervoor te zorgen dat het platform kan herstellen binnen de gedefinieerde recovery time (RTO) en recovery point (RPO) objectives.

Storingsdomeinen en Regionaal Ontwerp

• Zones, regio’s en multi-region services

  • Zones zijn de kleinste onafhankelijke storingsdomeinen. Een enkele zonale storing mag een regionale service niet onderbreken.
  • Regio’s groeperen onafhankelijke zones met verbindingen met lage latentie. Regionale ontwerpen overleven zonale storingen, maar niet noodzakelijkerwijs volledige regionale incidenten.
  • Multi-region services repliceren over regio’s heen, wat bescherming biedt tegen het verlies van een regio tegen hogere kosten en met potentieel hogere schrijflatentie.
  • Ontwerpprincipe: vermijd single points of failure op het kleinste storingsdomein dat voor u van belang is. Als uw RTO/RPO vereist dat een zonale storing wordt overleefd, implementeer dan in ten minste twee zones. Voor regionale overlevingskansen, implementeer actieve componenten in meerdere regio’s of gebruik multi-region services.

• Managed instance groups (MIG) en self-healing

  • Geef de voorkeur aan regionale MIG’s om instances over zones binnen één regio te verdelen. Dit beperkt de impact van zonale storingen zonder afzonderlijke tooling.
  • Health checks van de load balancer verwijderen onjuist functionerende VM’s uit het verkeer. MIG autohealing vervangt onjuist functionerende of niet-reagerende VM’s. Gebruik beide.
  • Gebruik HTTP(S) health checks op applicatieniveau die readiness-eindpunten en afhankelijkheden verifiëren. Een TCP-check valideert alleen de bereikbaarheid van de poort.
  • Foutmodus bij misconfiguratie van autohealing: het uitsluitend gebruiken van een health check van de load balancer voorkomt verkeer naar een defecte instance, maar creëert deze niet opnieuw. Configureer de eigen health check van de MIG voor vervanging en een initiële vertraging om voortijdige herstarts tijdens het opstarten te voorkomen.

Voorbeeld:

• Maak een health check voor de applicatie met intervallen van 10 seconden en 3 drempelwaarden voor onjuiste werking om self-healing na ~30 seconden te activeren: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Koppel de health check aan een regionale MIG voor autohealing: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Overwegingen voor multi-region

  • Global external HTTP(S) Load Balancing ondersteunt backends in meerdere regio’s met automatische failover op basis van health checks.
  • Statussynchronisatie tussen regio’s is de kritieke afweging. De doorvoersnelheid van active-active is hoog, maar consistentie en conflictoplossing moeten worden ontworpen. Active-passive is eenvoudiger, maar heeft een langzamere failover en een potentieel grotere RPO.

Gegevensbescherming: Databases, Opslag en Compute

• Cloud SQL hoge beschikbaarheid en replica’s
  • Een configuratie voor hoge beschikbaarheid plaatst een standby in een andere zone met synchrone replicatie. Automatische failover vindt plaats bij een storing van de primaire instance. De RTO is doorgaans enkele minuten; de RPO is ≈ 0 binnen een regio, maar houd rekening met transacties die onderweg zijn (‘in-flight’).
  • Leesreplica’s (read replicas) nemen leesbewerkingen over en kunnen cross-region zijn voor DR. Ze zijn asynchroon; verwacht replicatievertraging (replication lag) en een RPO die niet nul is.
  • Back-ups en PITR
    • Schakel geautomatiseerde back-ups en point-in-time recovery (PITR) in. Voor MySQL, schakel binary logging in; voor PostgreSQL, schakel PITR-retentie in.
    • Herstelprocedures: bij corruptie of een gebruikersfout, herstel naar een nieuwe instance op een specifiek tijdstip, wijs applicaties of replica’s naar de herstelde instance en valideer de gegevens.
  • Storingsmodi en afwegingen
    • HA beschermt niet tegen logische datacorruptie; back-ups en PITR doen dat wel.
    • Cross-region replica’s beschermen tegen het verlies van een regio, maar kunnen achterlopen; test uw acceptabele RPO.

Voorbeeld:

• Schakel binary logging (MySQL) en geautomatiseerde back-ups in: gcloud sql instances patch my-mysql
  –enable-bin-log
  –backup-start-time=03:00 –retained-backups=7

• Persistent disk (PD) snapshots en machine images

  • PD-snapshots zijn incrementele, crash-consistente back-ups van schijven. Hun opslaglocatie is configureerbaar en ze kunnen worden gebruikt om nieuwe schijven te maken in elke zone binnen het locatiebereik van de snapshot.
  • Om applicatie-consistente back-ups te realiseren, moet u het bestandssysteem en de applicatie ‘quiescen’ (pauzeren), of snapshots coördineren met databasespecifieke back-upmechanismen.
  • Machine images leggen schijven en instance-metadata vast (opstartschijven, gekoppelde schijven, instance-eigenschappen). Gebruik machine images voor sneller herstel van een ‘fleet’ (groep machines) of het klonen van een ‘golden server’-configuratie.
  • Snapshot-schema’s (schedule policies) automatiseren back-ups; dwingen retentie af; tag kritieke schijven dienovereenkomstig.
  • Herstelworkflow: maak een schijf vanuit een snapshot, koppel deze aan een nieuwe instance, werk opstartscripts en service accounts bij, en valideer vervolgens de integriteit van de applicatie voordat het verkeer wordt hervat.

Voorbeeld:

• Maak een snapshot en herstel deze naar een nieuwe schijf: gcloud compute disks snapshot vm-boot –snapshot-names=boot-2024-09-01 gcloud compute disks create restored-boot –source-snapshot=boot-2024-09-01 –zone=us-central1-a

• Cloud Storage replicatie, versioning en retentie

  • Keuzes voor opslagklassen (storage class): Standard voor ‘hot’ data; Nearline voor data die maandelijks niet frequent wordt benaderd; Coldline voor data die per kwartaal wordt benaderd (aanbevolen voor back-ups en DR); Archive voor data die langdurig en zelden wordt benaderd.
  • Regional, Dual-Region en Multi-Region buckets bieden duurzaamheid via replicatie. Dual-Region met turbo-replicatie kan de replicatie-RPO voor nieuw geschreven objecten beperken; Multi-Region biedt brede geografische veerkracht.
  • Object versioning beschermt tegen onbedoelde verwijderingen en overschrijvingen door niet-huidige versies te bewaren. Combineer dit met retentiebeleid (retention policies) en bucket lock om WORM-retentie (Write Once, Read Many) af te dwingen.
  • Bescherming tegen onbedoeld verwijderen: schakel Object Versioning in, gebruik een retentiebeleid met een lock, implementeer event-based holds voor juridische of verwerkingspoorten, beperk verwijderingen via IAM en uniform bucket-level access. Gebruik voor externe, tijdgebonden toegang signed URLs met strikte vervaldatums.

Voorbeeld van een lifecycle om objecten na 90 dagen naar Coldline te verplaatsen en na 365 dagen te verwijderen:

• lifecycle.json { “rule”: [ { “action”: { “type”: “SetStorageClass”, “storageClass”: “COLDLINE” }, “condition”: { “age”: 90 } }, { “action”: { “type”: “Delete” }, “condition”: { “age”: 365 } } ] }
• Toepassen: gsutil lifecycle set lifecycle.json gs://my-bucket

Veerkracht van Verkeer, Capaciteit en Afhankelijkheden

• DNS en failover voor verkeersbeheer

  • Geef de voorkeur aan global external HTTP(S) Load Balancing voor internetgerichte services; deze maakt gebruik van anycast IP’s en voert op basis van health checks failover uit tussen regio’s.
  • Gebruik voor private services internal HTTP(S) of TCP/UDP load balancers. Ontwerp voor zonale onafhankelijkheid met meerdere backends.
  • Afwegingen bij DNS TTL: lage TTL’s maken snellere failover mogelijk, maar verhogen de query-last en kunnen door sommige resolvers worden genegeerd vanwege cachinggedrag. Failover op basis van health checks van een load balancer is sneller en deterministischer dan failover die alleen op DNS is gebaseerd.
  • Gewogen (weighted) of failover DNS-beleid kan een laatste redmiddel zijn als control plane voor de evacuatie van een regio, maar is afhankelijk van het verlopen van de cache.

• Capaciteitsplanning en quota-ontwerp

  • Identificeer de minimaal gezonde capaciteit per zone en regio. Pas ‘headroom’-buffers toe voor failover (‘N+1 zone’-capaciteit).
  • Gebruik regionale reserveringen voor kritieke Compute Engine-vormen (shapes) om capaciteit te garanderen tijdens schaalvergroting of failover.
  • Provisioneer IP-adressen, forwarding rules, Cloud NAT-capaciteit, connection tracking en SSL-certificaten vooraf om vertragingen in de control plane tijdens herstel te voorkomen.
  • Vraag quotumverhogingen ruim van tevoren aan; valideer quota in secundaire regio’s en voor alle afhankelijkheden (bijv. Cloud SQL-instances per regio, forwarding rules per VPC, Pub/Sub-doorvoer, Cloud KMS QPS).
  • Overwegingen bij autoscaling: configureer cooldowns, predictive autoscaling indien nodig, en stel min/max-grenzen in om precies één instance te behouden wanneer dit door beleid wordt vereist.

• Veerkracht van afhankelijkheden

  • Inventariseer upstream en downstream services. Definieer voor elk het gedrag bij storingen en de fallbacks: gecachte configuratie, ‘degraded modes’ (verminderde functionaliteit), circuit breakers, wachtrijen met dead-letter topics en ‘backpressure’ (tegendruk).
  • Valideer de scoping van IAM en service accounts in herstelregio’s. Ontbrekende rollen veroorzaken vaak stille storingen tijdens DR-gebeurtenissen.
  • Encryptiesleutels: zorg ervoor dat Cloud KMS-sleutelreplica’s of multi-region sleutels overeenkomen met de datalocatie. Plan voor de lokaliteit van de key ring en IAM in secundaire regio’s.

Resilience-operaties en Continue Verbetering

• RTO, RPO, herstelplannen en runbooks

  • RTO definieert hoe snel een service hersteld moet zijn; RPO definieert acceptabel dataverlies. Leid deze af uit een business impact analyse.
  • Koppel elk systeemcomponent aan specifieke mechanismen die voldoen aan RTO/RPO: HA voor zone-storingen, cross-region replicatie voor regio-storingen, back-ups voor corruptie en storage class/replicatie voor duurzaamheid.
  • Onderhoud runbooks: precieze stappen, commando’s, toegang tot credentials, validatiechecks voor de status en beslisbomen. Sla deze op in een versiebeheerde repository met toegangscontrole en oefen regelmatig.
  • Herstelvalidatie: plan oefeningen om de daadwerkelijke RTO/RPO te meten, data-integriteit te valideren en verbeteracties te verzamelen. Test zowel herstelacties met een kleine scope (tabel, schijf) als een volledig site-herstel.

• DR-strategieën en afwegingen

  • Active-active: alle regio’s verwerken verkeer; minimale RTO en lage RPO als datasynchronisatie correct is ontworpen. Hogere complexiteit en kosten; vereist conflictoplossing en global load balancing.
  • Active-passive: de primaire regio is actief; de secundaire is ‘warm’ en ontvangt gerepliceerde data. Gematigde kosten; RTO van minuten tot tientallen minuten; RPO niet nul, afhankelijk van replicatie.
  • Pilot-light: minimale kritieke services draaien in de secundaire regio (databasereplicatie, minimale app-footprint). RTO in uren; kostenefficiënt; zorgvuldige orkestratie nodig om compute op te schalen tijdens een failover.
  • Cold-standby: infrastructuur gedefinieerd als code, maar niet geprovisioneerd. RTO in dagen; laagste kosten; risico op verrassingen door drift, quota’s en capaciteitsschaarste.

• Chaos testing en storingssimulaties

  • Simuleer regelmatig het crashen van instances, vastgelopen processen, falende health checks, volle schijven en uitval van afhankelijkheden. Gebruik tools of scripts om instances te beëindigen, uitgaand verkeer naar backends te blokkeren of latency te injecteren op de proxy-laag.
  • Valideer MIG autohealing en verwijdering door de LB door opzettelijk het health-eindpunt te laten falen. Bevestig het vervangingsgedrag en de hersteltijdlijnen.
  • Oefen regionale evacuatie: ‘drain’ backends in één regio, observeer de failover van de global load balancer en verifieer stateful afhankelijkheden in de secundaire regio.
  • Continue verbetering: leg statistieken vast voor ‘mean time to detect’, failover-tijd en dataverlies tijdens tests. Geef prioriteit aan oplossingen die RTO/RPO verlagen en handmatige stappen verwijderen.

Praktisch Probleemscenario

Brightlane Retail beheert een e-commerceplatform in us-central1 met strikte beschikbaarheidseisen en een RPO van vier uur voor orderdata. Het management eist dat een zone-storing wordt overleefd zonder downtime en een regio-storing met minimale impact voor de klant.

Aanpak:

1. Implementeer een regionale MIG met HTTP autohealing en een global HTTP(S) Load Balancer

   • Reden: Een regionale MIG spreidt instances over zones, en HTTP health checks op applicatieniveau maken self-healing mogelijk na drie mislukte checks van elk 10 seconden. De global load balancer verwijdert automatisch ongezonde VM’s en leidt verkeer om naar gezonde zones.
   • Commando’s: gcloud compute health-checks create http app-hc –check-interval=10s –timeout=5s –unhealthy-threshold=3 –request-path=/healthz gcloud compute instance-groups managed update web-rmig –region=us-central1 –health-check=app-hc –initial-delay=60

2. Activeer Cloud SQL HA met een cross-region read replica en PITR

   • Reden: Regionale HA biedt overlevingskansen bij zone-storingen met automatische failover. Een read replica in us-east1 zorgt voor regionale DR met een RPO die niet nul is, maar wel begrensd. Het activeren van PITR (binary logging voor MySQL) pakt logische corruptie aan door herstel naar een specifiek tijdstip mogelijk te maken.
   • Commando’s: gcloud sql instances patch orders-mysql –enable-bin-log –backup-start-time=03:00 gcloud sql instances create orders-replica –master-instance-name=orders-mysql –region=us-east1

3. Bescherm object-assets met Dual-Region Cloud Storage en lifecycle-beleid

   • Reden: Productafbeeldingen en statische assets worden opgeslagen in een dual-region bucket voor regionale veerkracht. Lifecycle-transities verplaatsen oudere artefacten naar Coldline om kosten te optimaliseren, en versiebeheer plus bewaarbeleid voorkomen het per ongeluk verwijderen van kritieke assets.
   • Stappen: Activeer Object Versioning, stel een bewaarbeleid van 30 dagen in voor kritieke buckets en pas lifecycle-regels toe om na 90 dagen over te gaan naar Coldline en na een jaar te verwijderen voor niet-kritieke build-artefacten.

4. Plan PD-snapshots en creëer machine images voor stateful services

   • Reden: Incrementele snapshots van VM-schijven bieden snelle, crash-consistente herstelopties. Machine images leggen de opstart- en configuratiegegevens vast om het ‘rehydrateren’ van app-servers tijdens een regio-failover te versnellen. Snapshot-schema’s zorgen voor consistente, beleidsgestuurde back-ups.
   • Commando’s: gcloud compute resource-policies create snapshot-schedule daily-2am –max-retention-days=14 –on-source-disk-delete=apply-retention-policy –start-time=02:00 gcloud compute disks add-resource-policies app-disk-1 –resource-policies=daily-2am gcloud compute machine-images create app-mi-2024-09-01 –source-instance=app-vm-template

5. Definieer RTO/RPO en codificeer DR-runbooks en IaC

   • Reden: Stel een service-level RTO van 15 minuten in voor web/API en een RPO van vier uur voor orders. Runbooks specificeren procedures voor traffic failover, de promotie van de Cloud SQL read replica, DNS-noodplannen en verificatiestappen. Infrastructure as Code (Terraform/Deployment Manager) zorgt voor deterministische herbouw en vermindert handmatige fouten.

6. Provisioneer capaciteit en quota’s in de secundaire regio

   • Reden: Maak reserveringen voor kritieke VM-types, provisioneer vooraf een standby load balancer-backend, SSL-certificaten, NAT-capaciteit en verifieer quota’s voor Compute, SQL, forwarding rules en KMS in us-east1. Dit voorkomt een tekort aan capaciteit (‘capacity starvation’) tijdens een failover.

7. Valideer herstel door middel van chaos-oefeningen en documenteer verbeteringen

   • Reden: Kwartaalelijkse oefeningen voor zone-storingen valideren het gedrag van de MIG en LB; halfjaarlijkse regionale evacuaties promoten de read replica in us-east1, verwijzen de global LB naar de backends in us-east1 en meten de RTO/RPO. De bevindingen leiden tot verbeteringen, zoals het verminderen van handmatige stappen of het verhogen van de replica-capaciteit.

Door deze stappen te volgen, bereikt Brightlane Retail zonale high availability met geautomatiseerde self-healing en een regionale DR-strategie met gedefinieerde, geteste runbooks. Dit zorgt ervoor dat orderdata voldoet aan een RPO van vier uur en dat applicatieservices herstellen binnen de beoogde RTO-grenzen.

← Beveiliging · Alle domeinen · Kostenbeheer →

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

Blader door Google →