Google ACE: Affidabilità, backup e ripristino di emergenza — Guida allo studio

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

Fa parte della Google Associate Cloud Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’affidabilità, il backup e il disaster recovery su Google Cloud richiedono una progettazione intenzionale che tenga conto dei domini di errore, dei meccanismi di protezione dei dati, della gestione del traffico e della prontezza operativa. Questa sezione spiega come strutturare i servizi tra zone e regioni, come proteggere e ripristinare i dati stateful e come convalidare gli obiettivi di ripristino con runbook rigorosi e test di resilienza continui. Vengono inoltre illustrati i compromessi delle strategie di DR e la pianificazione della capacità per garantire che la piattaforma possa essere ripristinata entro gli obiettivi definiti di tempo di ripristino (RTO) e punto di ripristino (RPO).

Domini di Errore e Progettazione Regionale

• Zone, regioni e servizi multi-regione

  • Le zone sono i più piccoli domini di errore indipendenti. Un singolo guasto zonale non dovrebbe interrompere un servizio regionale.
  • Le regioni raggruppano zone indipendenti con collegamenti a bassa latenza. Le architetture regionali sopravvivono ai guasti zonali, ma non necessariamente a eventi che coinvolgono un’intera regione.
  • I servizi multi-regione replicano i dati tra più regioni, proteggendo dalla perdita di una regione a un costo più elevato e con una latenza di scrittura potenzialmente maggiore.
  • Principio di progettazione: evitare singoli punti di guasto (single point of failure) nel dominio di errore più piccolo che si intende proteggere. Se i propri RTO/RPO richiedono la sopravvivenza a un guasto zonale, è necessario effettuare il deployment in almeno due zone. Per la sopravvivenza a livello regionale, distribuire componenti attivi in più regioni o utilizzare servizi multi-regione.

• Managed Instance Group (MIG) e autoriparazione (self-healing)

  • Preferire i MIG regionali per distribuire le istanze tra le zone di una singola regione. Questo mitiga le interruzioni zonali senza richiedere strumenti separati.
  • Gli health check del bilanciatore di carico rimuovono le VM non integre dal traffico. L’autoriparazione (autohealing) del MIG sostituisce le VM non integre o che non rispondono. Usare entrambi.
  • Utilizzare health check a livello di applicazione HTTP(S) che verifichino gli endpoint di readiness e le dipendenze. Un controllo TCP valida solo la raggiungibilità della porta.
  • Modalità di guasto per errata configurazione dell’autoriparazione: l’uso del solo health check del bilanciatore di carico impedisce l’invio di traffico a un’istanza difettosa, ma non la ricrea. Configurare l’health check proprio del MIG per la sostituzione e un ritardo iniziale (initial delay) per evitare riavvii prematuri durante l’avvio.

Esempio:

• Creare un health check applicativo con intervalli di 10 secondi e 3 soglie di non integrità (unhealthy threshold) per attivare l’autoriparazione dopo circa 30 secondi: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Associare l’health check a un MIG regionale per l’autoriparazione: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Considerazioni multi-regione

  • Il Global external HTTP(S) Load Balancing supporta backend in più regioni con failover automatico basato sugli health check.
  • La sincronizzazione dello stato tra le regioni è il compromesso critico. Il throughput in modalità attivo-attivo è elevato, ma la coerenza (consistency) e la risoluzione dei conflitti devono essere progettate. La modalità attivo-passivo è più semplice ma ha un failover più lento e un RPO potenzialmente più grande.

Protezione dei dati: database, storage e compute

• Cloud SQL: alta disponibilità e repliche
  • La configurazione ad alta disponibilità posiziona uno standby in una zona diversa con replica sincrona. Il failover automatico si verifica in caso di guasto del primario. L’RTO è tipicamente di alcuni minuti; l’RPO è ≈ 0 all’interno di una regione, ma bisogna considerare le transazioni in corso (in-flight).
  • Le repliche di lettura (read replica) scaricano le operazioni di lettura e possono essere cross-region per il DR. Sono asincrone; aspettarsi un ritardo di replica (replication lag) e un RPO diverso da zero.
  • Backup e PITR
    • Abilitare i backup automatici e il point-in-time recovery (PITR). Per MySQL, abilitare il binary logging; per PostgreSQL, abilitare la conservazione per il PITR.
    • Flussi di ripristino: in caso di corruzione o errore dell’utente, ripristinare su una nuova istanza a un timestamp specifico, puntare le applicazioni o le repliche all’istanza ripristinata e convalidare i dati.
  • Modalità di guasto e compromessi
    • L’alta disponibilità (HA) non protegge dalla corruzione logica dei dati; i backup e il PITR sì.
    • Le repliche cross-region proteggono dalla perdita di una regione ma possono subire ritardi; testare il proprio RPO accettabile.

Esempio:

• Abilitare il binary logging (MySQL) e i backup automatici: gcloud sql instances patch my-mysql
  –enable-bin-log
  –backup-start-time=03:00 –retained-backups=7

• Snapshot di Persistent disk (PD) e machine image

  • Gli snapshot di PD sono backup incrementali e crash-consistent dei dischi. La loro posizione di archiviazione è configurabile e possono essere usati per creare nuovi dischi in qualsiasi zona all’interno dell’ambito di localizzazione dello snapshot.
  • Per ottenere backup application-consistent, mettere in quiescenza il filesystem e l’applicazione, o coordinare gli snapshot con meccanismi di backup specifici del database.
  • Le machine image acquisiscono dischi e metadati dell’istanza (dischi di avvio, dischi collegati, proprietà dell’istanza). Utilizzare le machine image per un ripristino più rapido della flotta (fleet) o per clonare una configurazione “golden server”.
  • Le policy di pianificazione degli snapshot (snapshot schedule policies) automatizzano i backup, applicano la conservazione (retention) e taggano di conseguenza i dischi critici.
  • Flusso di lavoro per il ripristino: creare un disco da uno snapshot, collegarlo a una nuova istanza, aggiornare gli script di avvio e i service account, quindi convalidare l’integrità dell’applicazione prima di reintrodurre il traffico.

Esempio:

• Creare uno snapshot e ripristinarlo su un nuovo disco: 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: replica, versioning e conservazione (retention)

  • Scelta della classe di archiviazione: Standard per dati “caldi” (hot data); Nearline per accessi mensili poco frequenti; Coldline per accessi trimestrali (consigliato per backup e DR); Archive per dati a lungo termine a cui si accede raramente.
  • I bucket Regional, Dual-Region e Multi-Region offrono durabilità tramite la replica. Dual-Region con turbo replication può limitare l’RPO di replica per gli oggetti appena scritti; Multi-Region offre un’ampia resilienza geografica.
  • Il versioning degli oggetti (Object versioning) protegge da cancellazioni e sovrascritture accidentali conservando le versioni non correnti. Combinarlo con policy di conservazione (retention policies) e bucket lock per applicare una conservazione WORM (Write-Once, Read-Many).
  • Protezione dalla cancellazione accidentale: abilitare l’Object Versioning, usare una policy di conservazione con un lock, implementare blocchi basati su eventi (event-based holds) per controlli legali o di elaborazione, limitare le cancellazioni tramite IAM e l’accesso uniforme a livello di bucket. Per l’accesso esterno a tempo, utilizzare URL firmati (signed URLs) con scadenze rigorose.

Esempio di ciclo di vita per spostare i dati in Coldline dopo 90 giorni ed eliminarli dopo 365 giorni:

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

Resilienza del traffico, della capacità e delle dipendenze

• Failover tramite DNS e gestione del traffico

  • Preferire il Global External HTTP(S) Load Balancing per i servizi esposti su Internet; utilizza IP anycast ed esegue il failover basato sull’integrità (health-based) tra le regioni.
  • Per i servizi privati, utilizzare i load balancer interni HTTP(S) o TCP/UDP. Progettare per l’indipendenza zonale con più backend.
  • Compromessi del TTL DNS: TTL bassi consentono un failover più rapido ma aumentano il carico di query e possono essere ignorati da alcuni resolver a causa del comportamento della cache.
  • Il failover di un load balancer basato su health check è più veloce e deterministico del failover basato solo su DNS.
  • Le policy DNS ponderate (weighted) o di failover possono essere un piano di controllo (control plane) di ultima istanza per l’evacuazione di una regione, ma dipendono dalla scadenza della cache.

• Pianificazione della capacità e progettazione delle quote

  • Identificare la capacità minima integra (healthy) per zona e per regione. Applicare buffer di margine (headroom) per il failover (capacità “N+1 zone”).
  • Utilizzare le prenotazioni regionali (regional reservations) per le configurazioni (shape) critiche di Compute Engine per garantire la capacità durante eventi di scalabilità o failover.
  • Pre-allocare indirizzi IP, regole di forwarding, capacità di Cloud NAT, tracciamento delle connessioni e certificati SSL per evitare ritardi del control plane durante il ripristino.
  • Richiedere aumenti di quota con largo anticipo; convalidare le quote nelle regioni secondarie e per tutte le dipendenze (es. istanze Cloud SQL per regione, regole di forwarding per VPC, throughput di Pub/Sub, QPS di Cloud KMS).
  • Considerazioni sull’autoscaling: configurare i periodi di cooldown, l’autoscaling predittivo se necessario, e impostare limiti min/max per mantenere esattamente un’istanza quando richiesto dalla policy.

• Resilienza delle dipendenze

  • Fare un inventario dei servizi upstream e downstream. Per ciascuno, definire il comportamento in caso di guasto e le soluzioni di ripiego (fallback): configurazione in cache, modalità degradate, circuit breaker, code con dead-letter topic e backpressure.
  • Convalidare l’ambito (scoping) di IAM e dei service account nelle regioni di ripristino. La mancanza di ruoli causa comunemente guasti silenziosi durante gli eventi di DR.
  • Chiavi di crittografia: assicurarsi che le repliche delle chiavi di Cloud KMS o le chiavi multi-regione siano allineate con la posizione dei dati. Pianificare la località dei key-ring e l’IAM nelle regioni secondarie.

Operazioni di Resilienza e Miglioramento Continuo

• RTO, RPO, piani di ripristino e runbook

  • L’RTO definisce la rapidità con cui un servizio deve essere ripristinato; l’RPO definisce la perdita di dati accettabile. Questi valori derivano dall’analisi dell’impatto sul business (business impact analysis).
  • Associa ogni componente del sistema a meccanismi specifici che soddisfino RTO/RPO: HA per i guasti di zona, replica cross-region per i guasti di regione, backup per la corruzione dei dati e classe di storage/replica per la durabilità.
  • Mantieni i runbook: procedure precise, comandi, accesso alle credenziali, controlli di validazione dello stato (health check) e alberi decisionali. Archiviali in un repository versionato con controllo degli accessi ed esercitati regolarmente.
  • Validazione del ripristino: pianifica esercitazioni per misurare gli RTO/RPO effettivi, convalidare l’integrità dei dati e raccogliere azioni di miglioramento. Testa sia ripristini di portata limitata (tabella, disco) sia il ripristino completo del sito.

• Strategie di DR e compromessi

  • Active-active: tutte le regioni servono traffico; RTO minimo e RPO basso se la sincronizzazione dei dati è progettata correttamente. Complessità e costi più elevati; richiede la risoluzione dei conflitti e il bilanciamento del carico globale.
  • Active-passive: la regione primaria è attiva; la secondaria è “warm” (pronta) e riceve i dati replicati. Costo moderato; RTO da minuti a decine di minuti; RPO non nullo a seconda della replica.
  • Pilot-light: i servizi critici minimi sono in esecuzione nella regione secondaria (replica del database, footprint minimo dell’applicazione). RTO di ore; efficiente in termini di costi; è necessaria un’attenta orchestrazione per scalare le risorse di calcolo durante il failover.
  • Cold-standby: l’infrastruttura è definita come codice ma non è provisionata. RTO di giorni; costo più basso; rischio di imprevisti dovuti a drift, quote e scarsità di capacità.

• Chaos testing e simulazioni di guasto

  • Simula regolarmente crash di istanze, blocchi di processi, fallimenti degli health check, condizioni di disco pieno e interruzioni delle dipendenze. Usa strumenti o script per terminare istanze, bloccare il traffico in uscita (egress) verso i backend o iniettare latenza a livello di proxy.
  • Convalida l’auto-riparazione (autohealing) del MIG e la rimozione dal LB fallendo intenzionalmente l’endpoint di health check. Conferma il comportamento di sostituzione e le tempistiche di ripristino.
  • Esercitati nell’evacuazione di una regione: svuota (drain) i backend in una regione, osserva il failover del bilanciatore del carico globale e verifica le dipendenze stateful nella regione secondaria.
  • Miglioramento continuo: registra le metriche per il tempo medio di rilevamento (MTTD), il tempo di failover e la perdita di dati durante i test. Dai priorità alle correzioni che riducono RTO/RPO ed eliminano i passaggi manuali.

Scenario Pratico

Brightlane Retail gestisce una piattaforma di e-commerce in us-central1 con requisiti di disponibilità stringenti e un RPO di quattro ore per i dati degli ordini. La direzione richiede di poter sopravvivere a un’interruzione di zona senza downtime e a un’interruzione di regione con un impatto minimo per i clienti.

Approccio:

1. Implementare un MIG regionale con auto-riparazione (autohealing) HTTP e un HTTP(S) Load Balancer globale
   • Motivazione: Un MIG regionale distribuisce le istanze tra più zone, e gli health check HTTP a livello di applicazione abilitano l’auto-riparazione dopo tre controlli falliti di 10 secondi ciascuno. Il bilanciatore del carico globale rimuove automaticamente le VM non integre e devia il traffico verso le zone integre.
   • Comandi:

undefined

undefined

2. Abilitare l’HA di Cloud SQL con una replica di lettura cross-region e PITR
   • Motivazione: L’HA regionale garantisce la sopravvivenza a livello di zona con failover automatico. Una replica di lettura in us-east1 fornisce DR a livello regionale con un RPO non nullo ma limitato. L’abilitazione del PITR (binary logging per MySQL) gestisce la corruzione logica consentendo il ripristino a un punto specifico nel tempo (point-in-time restore).
   • Comandi:

undefined

undefined

3. Proteggere gli asset di oggetti con Cloud Storage Dual-Region e policy di lifecycle

   • Motivazione: Le immagini dei prodotti e gli asset statici sono archiviati in un bucket dual-region per la resilienza a livello regionale. Le transizioni del ciclo di vita spostano gli artefatti più vecchi su Coldline per ottimizzare i costi, mentre il versioning e le policy di conservazione (retention) prevengono la cancellazione accidentale di asset critici.
   • Passaggi: Abilitare l’Object Versioning, impostare una policy di conservazione di 30 giorni per i bucket critici e applicare regole di lifecycle per la transizione a Coldline dopo 90 giorni e la cancellazione dopo un anno per gli artefatti di build non critici.

4. Pianificare snapshot di PD e creare machine image per i servizi stateful

   • Motivazione: Gli snapshot incrementali dei dischi delle VM offrono opzioni di ripristino veloci e crash-consistent. Le machine image acquisiscono l’avvio e la configurazione per accelerare la reidratazione dei server applicativi durante un failover di regione. La pianificazione degli snapshot garantisce backup coerenti e basati su policy.
   • Comandi:

undefined

undefined

undefined

5. Definire RTO/RPO e codificare i runbook di DR e l’IaC

   • Motivazione: Impostare un RTO a livello di servizio di 15 minuti per web/API e un RPO di quattro ore per gli ordini. I runbook specificano le procedure di failover del traffico, la promozione della replica di lettura di Cloud SQL, le contingenze DNS e i passaggi di verifica. L’Infrastructure as Code (Terraform/Deployment Manager) garantisce ricostruzioni deterministiche e riduce l’errore umano.

6. Provisionare capacità e quote nella regione secondaria

   • Motivazione: Creare prenotazioni per le tipologie di VM critiche, pre-provisionare un backend di standby per il bilanciatore del carico, certificati SSL, capacità NAT e verificare le quote per Compute, SQL, forwarding rules e KMS in us-east1. Questo previene l’esaurimento della capacità durante un failover.

7. Convalidare il ripristino tramite esercitazioni di chaos e documentare i miglioramenti

   • Motivazione: Esercitazioni trimestrali di guasto di zona convalidano il comportamento di MIG e LB; l’evacuazione semestrale della regione promuove la replica di lettura in us-east1, indirizza il LB globale verso i backend di us-east1 e misura RTO/RPO. I risultati guidano miglioramenti come la riduzione dei passaggi manuali o l’aumento della capacità della replica.

Seguendo questi passaggi, Brightlane Retail ottiene un’alta disponibilità a livello di zona con auto-riparazione automatizzata e una postura di DR regionale con runbook definiti e testati, garantendo che i dati degli ordini rispettino un RPO di quattro ore e che i servizi applicativi vengano ripristinati entro i limiti di RTO prefissati.

← Sicurezza · Tutti i domini · Gestione dei costi →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Google →