Guida alla pianificazione del ripristino di emergenza

Last reviewed 2024-07-05 UTC

Questo documento è la prima parte di una serie che illustra il ripristino di emergenza (RE) in Google Cloud. Questa parte fornisce una panoramica del processo di pianificazione del RE: ciò che devi sapere per progettare e implementare un piano di RE. Le parti successive illustrano casi d'uso specifici di RP con esempi di implementazioni su Google Cloud.

La serie è costituita dai seguenti componenti:

Gli eventi che interrompono il servizio possono verificarsi in qualsiasi momento. La tua rete potrebbe subire un'interruzione, l'ultimo push dell'applicazione potrebbe introdurre un bug critico o potresti dover affrontare una calamità naturale. Quando le cose non vanno come previsto, è importante avere un piano di RE solido, mirato e ben testato.

Con un piano di RE ben progettato e testato, puoi assicurarti che, in caso di catastrofe, l'impatto sui profitti della tua attività sarà minimo. Indipendentemente dalle tue esigenze di RE, Google Cloud offre una selezione solida, flessibile e conveniente di prodotti e funzionalità che puoi utilizzare per creare o migliorare la soluzione più adatta a te.

Nozioni di base sulla pianificazione di RE

RE è un sottoinsieme pianificazione della continuità aziendale. La pianificazione del piano di RE inizia con un'analisi dell'impatto aziendale che definisce due metriche chiave:

  • Un RTO (Recovery Time Objective), ovvero il periodo di tempo massimo accettabile per cui la tua applicazione può essere offline. Questo valore è di solito definito come parte di un l'accordo sul livello del servizio (SLA, Service Level Agreement).
  • Un Recovery Point Objective (RPO), ovvero il periodo di tempo massimo accettabile durante il quale i dati potrebbero essere perduti dall'applicazione a causa di un incidente grave. Questa metrica varia in base alle modalità di utilizzo dei dati. Ad esempio, i dati utente che sono modificati di frequente può avere un RPO di pochi minuti. Al contrario, i dati meno critici e modificati di rado potrebbero avere un RPO di diversi nell'orario lavorativo locale del TAM. Questa metrica descrive solo il periodo di tempo; non tratta la quantità o la qualità dei dati persi.)

Generalmente, minori sono i valori RTO e RPO (ovvero, più rapidamente l'applicazione deve recuperare in seguito a un'interruzione), più l'applicazione costo di esecuzione. Il seguente grafico mostra il rapporto tra il costo e RTO/RPO.

Il grafico mostra che RTO/RPO di dimensioni ridotte è associato a costi elevati.

Poiché valori RTO e RPO più piccoli spesso indicano una maggiore complessità, il carico amministrativo associato segue una curva simile. Un'applicazione ad alta disponibilità potrebbe richiedere la gestione della distribuzione tra due dati separati fisicamente center, gestione della replica e altro.

I valori RTO e RPO vengono generalmente raggruppati in un'altra metrica: l'obiettivo del livello di servizio (SLO), che è un elemento chiave misurabile di un SLA. Gli SLA e gli SLO sono spesso confusi. Uno SLA è l'intero contratto che specifica il servizio da fornire, come viene supportato, orari, località, costi, prestazioni, penali e responsabilità delle parti coinvolte. Gli SLO sono specifici e misurabili le caratteristiche dello SLA, come disponibilità, velocità effettiva, il tempo di risposta o la qualità. Uno SLA può contenere molti SLO. I tempi di risposta e i tempi di risposta obiettivo sono misurabili e devono essere considerati SLO.

Puoi scoprire di più SLO e SLA nel libro Google Site Reliability Engineering.

Potresti anche pianificare un'architettura per la disponibilità elevata (HA). L'alta disponibilità non si sovrappone completamente alla RE, ma spesso è necessario se si pensi ai valori RTO e RPO. L'alta disponibilità aiuta a garantire di prestazioni operative concordate, di solito tempo di attività, per un periodo superiore al normale. Quando esegui carichi di lavoro di produzione Google Cloud, potresti utilizzare un sistema distribuito a livello globale si è verificato un problema in una regione, l'applicazione continua a fornire il servizio anche se sono meno disponibili. In sostanza, l'applicazione richiama il proprio piano di RP.

Perché Google Cloud?

Google Cloud può ridurre notevolmente i costi associati sia a RTO che a RPO rispetto alla soddisfazione dei requisiti RTO e RPO on-premise. Ad esempio, la pianificazione del DR richiede di tenere conto di una serie di requisiti, tra cui:

  • Capacità: assicurati risorse sufficienti per eseguire la scalabilità in base alle esigenze.
  • Sicurezza: fornire sicurezza fisica per proteggere le risorse.
  • Infrastruttura di rete: inclusi componenti software come firewall e bilanciatori del carico.
  • Assistenza:mettere a disposizione tecnici qualificati per eseguire la manutenzione e risolvere i problemi.
  • Larghezza di banda: pianifica una larghezza di banda adeguata per i picchi di carico.
  • Strutture: garantire l'infrastruttura fisica, comprese attrezzature e corrente.

Fornendo una soluzione altamente gestita su una piattaforma di produzione di altissimo livello, Google Cloud ti aiuta ad aggirare gran parte o tutti questi fattori di complicazione, eliminando molti costi aziendali durante il processo. Inoltre, l'interfaccia utente di Google Cloud Focalizzarsi sulla semplicità amministrativa significa che i costi di gestione di un anche le applicazioni sono ridotte.

Google Cloud offre diverse funzionalità per la pianificazione di RE, tra cui:

  • Una rete globale. Google dispone di una delle reti informatiche più grandi e avanzate al mondo. La rete backbone di Google utilizza avanzati servizi di networking software-defined e di memorizzazione nella cache perimetrale per offrire prestazioni elevate, coerenti e scalabili.
  • Ridondanza. La presenza di molteplici punti di presenza (da un periodo all'altro) in tutto il mondo indica di elevata ridondanza. I dati vengono sottoposti a mirroring automatico su dispositivi di archiviazione in più località.
  • Scalabilità. Google Cloud è progettato per scalare come altri prodotti Google (ad esempio la Ricerca e Gmail), anche in caso di picchi di traffico elevati. Servizi gestiti come Cloud Run, Compute Engine e Firestore forniscono la scalabilità automatica che consente all'applicazione di crescere e, se necessario, ridurle.
  • Sicurezza. Il modello di sicurezza di Google si basa su decenni di esperienza nel garantire la sicurezza degli utenti su applicazioni Google come Gmail e Google Workspace. Inoltre, i team SRE (Site Reliability Engineer) di Google contribuiscono a garantire un'elevata disponibilità e a impedire utilizzi illeciti delle risorse della piattaforma.
  • Conformità. Google si sottopone a regolari controlli di terze parti indipendenti per verificare che Google Cloud sia in linea con sicurezza, privacy normative e best practice di conformità. Google Cloud conforme con certificazioni come ISO 27001, SOC 2/3 e PCI DSS 3.0.

Pattern RE

I pattern di RE sono considerati freddi, caldi o caldi. Questi pattern indicano quanto facilmente il sistema può recuperare quando si verifica un problema. Un'analogia potrebbe essere che cosa faresti se stessi guidando e forando una gomma dell'auto.

La modalità di gestione di una gomma a terra dipende da quanto sei preparato:

  • Freddo: non hai una ruota di scorta, quindi devi chiamare qualcuno che venga da te con una nuova ruota e la sostituisca. Il percorso si interrompe finché non arriva i soccorsi per effettuare la riparazione.
  • Calda: hai una ruota di scorta e un kit di sostituzione, così puoi rimetterti per strada utilizzando i componenti della tua auto. Tuttavia, devi interrompere per risolvere il problema.
  • Caldo: hai pneumatici run-flat. Potresti dover rallentare un po', ma non ci sarà alcun impatto immediato sul tuo viaggio. Gli pneumatici funzionano abbastanza bene che puoi continuare (anche se alla fine dovrai risolvere il problema).

Creare un piano di RE dettagliato

Questa sezione fornisce consigli su come creare il tuo piano di RE.

Progetta in base ai tuoi obiettivi di recupero

Quando progetti il tuo piano di RE, devi combinare l'applicazione e i dati tecniche di recupero e avere un quadro più ampio. Il modo tipico per farlo è esaminare i valori RTO e RPO e quale modello di RE puoi adottare per soddisfare quei valori. Ad esempio, nel caso di dati storici incentrati sulla conformità, probabilmente non hai bisogno di un accesso rapido ai dati, quindi è appropriato un valore RTO elevato e un pattern di RP a freddo. Tuttavia, se il tuo servizio online subisce un'interruzione, è importante poter recuperare il prima possibile sia i dati sia la parte dell'applicazione rivolta agli utenti. In questo caso, più appropriato sarebbe più appropriato. Il tuo sistema di notifica via email, tipicamente non è fondamentale per l'attività, ed è probabilmente un candidato per un modello caldo.

Per indicazioni sull'utilizzo di Google Cloud per gestire scenari di RE comuni, consulta gli scenari di recupero delle applicazioni. Questi scenari forniscono strategie di RP mirate per una serie di casi d'uso e offrono implementazioni di esempio su Google Cloud per ciascuno.

Progetta per il recupero end-to-end

Non basta avere un piano per il backup o l'archiviazione dei dati. Marca che il tuo piano di RE risolva l'intero processo di ripristino, dal backup al ripristino la pulizia. Questo argomento è trattato nei documenti correlati su dati e recupero del DR.

Rendi specifiche le tue attività

Quando è il momento di eseguire il tuo piano di RE, è meglio non essere costretti a indovinare ogni passaggio. Fai in modo che ogni attività del tuo piano di RE sia composta da una o più comandi o azioni non ambigui. Ad esempio, "Esegui lo script di ripristino" è troppo generico. Al contrario, "Apri una shell ed esegui /home/example/restore.sh" è preciso e concreto.

Implementazione di misure di controllo

Aggiungi controlli per evitare che si verifichino incidenti e per rilevare i problemi prima che si verifichino. Ad esempio, aggiungi un monitor che invii un avviso quando un flusso di dati distruttivi, ad esempio una pipeline di eliminazione, mostra picchi imprevisti o altre attività insolite. Questo monitoraggio potrebbe anche terminare la pipeline di processo se viene raggiunta una determinata soglia di eliminazione, evitando un evento catastrofico la situazione.

Preparazione del software

Parte della pianificazione di RE consiste nell'assicurarti che il software su cui fai affidamento sia pronto per un evento di recupero.

Verificare di poter installare il software

Assicurati che il software dell'applicazione possa essere installato dal codice sorgente o da un'immagine preconfigurata. Assicurati di disporre della licenza adeguata per qualsiasi di cui eseguirai il deployment su Google Cloud, fornitore del software.

Assicurati che le risorse Compute Engine necessarie siano disponibili nell'ambiente di recupero. Ciò potrebbe richiedere la preallocazione di istanze prenotare che li rappresentano.

Progetta il deployment continuo per il recupero

Il set di strumenti di deployment continuo (CD) è un componente integrante quando il deployment delle tue applicazioni. Nell'ambito del piano di recupero, devi considerare dove nell'ambiente recuperato eseguirai il deployment degli elementi. Pianifica dove vuoi ospitare l'ambiente e gli elementi del CD: devono essere disponibili e operativi in caso di emergenza.

Implementazione dei controlli di sicurezza e conformità

Quando progetti un piano di RE, la sicurezza è importante. Gli stessi controlli che hai nell'ambiente di produzione devono essere applicati all'ambiente recuperato. Le normative di conformità verranno applicate anche ai tuoi contenuti completamente gestito di Google Cloud.

Configura la sicurezza nello stesso modo per gli ambienti di produzione e di ripristino dei dati

Assicurati che i controlli di rete forniscano la stessa separazione e blocco usate dall'ambiente di produzione di origine. Scopri come configurare un VPC condiviso e i firewall per stabilire un controllo centralizzato della rete e della sicurezza del tuo deployment, per configurare le subnet e per controllare il traffico in entrata e in uscita. Scopri come utilizzare gli account di servizio per implementare il privilegio minimo per le applicazioni che accedono alle API Google Cloud. Assicurati di utilizzare gli account di servizio come parte delle regole del firewall.

Assicurati di concedere agli utenti lo stesso accesso all'ambiente di DR di quello che hanno nell'ambiente di produzione di origine. Il seguente elenco illustra i modi per sincronizza le autorizzazioni tra gli ambienti:

  • Se il tuo ambiente di produzione è Google Cloud, la replica di IAM nell'ambiente di RE è semplice. Puoi utilizzare strumenti di Infrastructure as Code (IaC) come Terraform per eseguire il deployment delle tue norme IAM in produzione. Poi, utilizza gli stessi strumenti per associare i criteri alle risorse corrispondenti nell'ambiente di DR nell'ambito della procedura di creazione dell'ambiente di DR.

  • Se il tuo ambiente di produzione è on-premise, mapperai ruoli, ad esempio i ruoli di amministratore di rete e revisore, i criteri IAM che dispongono dei livelli IAM appropriati ruoli. La documentazione IAM contiene alcuni esempi di configurazioni di ruoli funzionali. Ad esempio, consulta la documentazione per la creazione di ruoli funzionali per networking e audit logging.

  • Devi configurare i criteri IAM per concedere autorizzazioni ai prodotti. Ad esempio, potresti voler limitare l'accesso a bucket Cloud Storage specifici.

  • Se il tuo ambiente di produzione è di un altro provider cloud, mappa le autorizzazioni nei criteri IAM dell'altro provider ai criteri IAM di Google Cloud.

Verifica la sicurezza di RE

Dopo aver configurato le autorizzazioni per l'ambiente RE, assicurati di testare tutto. Crea un ambiente di test. Verifica che le autorizzazioni che gli utenti dispongono di risorse on-premise.

Assicurati che gli utenti possano accedere all'ambiente di RE

Non attendere che si verifichi una situazione di emergenza prima di verificare che i tuoi utenti possono accedere all'ambiente di RE. Assicurati di aver concesso i diritti di accesso appropriati a utenti, sviluppatori, operatori, data scientist, amministratori della sicurezza, amministratori di rete e a qualsiasi altro ruolo della tua organizzazione. Se utilizzi un sistema di identità alternativo, assicurati che gli account siano stati sincronizzati con il tuo account Cloud Identity. Poiché il RE sarà il tuo ambiente di produzione per un po', fai in modo che i tuoi utenti avrà bisogno di accedere all'ambiente RE per accedere e risolvere eventuali problemi di autenticazione. Incorporare gli utenti che accedono a RE nell'ambito dei normali test di RE implementati.

Per gestire centralmente chi ha accesso amministrativo alle macchine virtuali (VM) avviate, attiva la funzionalità di accesso al sistema operativo nei progetti Google Cloud che costituiscono il tuo ambiente di ripristino dei dati.

Formare gli utenti

Gli utenti devono capire come intraprendere le azioni in Google Cloud che per svolgere operazioni nell'ambiente di produzione, come l'accesso e l'accesso alle VM. Utilizzando l'ambiente di test, addestrare gli utenti a svolgere queste attività in modo da salvaguardare la sicurezza del sistema.

Assicurati che l'ambiente di RE soddisfi i requisiti di conformità

Verifica che l'accesso al tuo ambiente RE sia limitato solo a coloro che devono l'accesso. Assicurati che i dati PII siano oscurati e criptati. Se esegui regolarmente test di penetrazione nell'ambiente di produzione, devi includere l'ambiente di RE in questo ambito ed eseguire test regolari configurando un ambiente di RE.

Assicurati che, mentre l'ambiente di DR è in servizio, tutti i log raccolti vengano sottoposti a backfill nell'archivio dei log dell'ambiente di produzione. Analogamente, assicurati che nell'ambito del tuo ambiente di DR tu possa esportare gli audit log raccolti tramite Cloud Logging nell'archivio del tuo sink dei log principale. Utilizza i servizi di sink di esportazione. Per i log delle applicazioni, crea un'immagine speculare del tuo ambiente di logging e monitoraggio on-premise. Se il tuo ambiente di produzione è di un altro provider cloud, mappa il logging e il monitoraggio di quel fornitore ai servizi Google Cloud equivalenti. Prepara un processo per formattare l'input nel tuo ambiente di produzione.

Tratta i dati recuperati come dati di produzione

Assicurati che i controlli di sicurezza che applichi ai dati di produzione vengano applicati anche ai dati recuperati: devono essere applicati gli stessi requisiti di autorizzazioni, crittografia e controllo.

Sapere dove si trovano i backup e chi è autorizzato a ripristinare i dati. Marca sia possibile controllare il processo di ripristino; dopo un ripristino di emergenza, può mostrare chi ha accesso ai dati di backup e chi ha eseguito e il ripristino di emergenza.

Verificare il funzionamento del piano di risposta agli incidenti

Assicurati che, in caso di emergenza, il piano di ripristino funzioni come previsto.

Gestire più di un percorso di recupero dei dati

In caso di disastro, il metodo di connessione a Google Cloud potrebbe diventare non disponibile. Implementa un mezzo di accesso alternativo a Google Cloud per assicurarti di poter trasferire i dati su Google Cloud. Verifica regolarmente che il percorso di backup sia operativo.

Verifica regolarmente il piano

Dopo aver creato un piano di RE, testalo regolarmente, rilevando eventuali problemi e modificare il piano di conseguenza. Con Google Cloud puoi scenari di ripristino di test con costi minimi. Ti consigliamo di implementare per aiutarti a eseguire il test:

  • Automatizza il provisioning dell'infrastruttura. Puoi utilizzare strumenti IaC come Terraform per automatizzare il provisioning dell'infrastruttura Google Cloud. Se esegui il tuo ambiente di produzione on-premise, assicurati di disporre di un processo di monitoraggio che possa avviare quello di RE quando rileva un errore e può attivare le azioni di ripristino appropriate.
  • Monitora i tuoi ambienti con Google Cloud Observability. Google Cloud dispone di eccellenti strumenti di monitoraggio e registrazione a cui puoi accedere tramite chiamate API, che ti consentono di automatizzare il deployment di scenari di recupero reagendo alle metriche. Quando progetti i test, assicurati di disporre di un monitoraggio e di avvisi appropriati che possano attivare azioni di recupero appropriate.

  • Esegui i test indicati in precedenza:

    • Verifica che le autorizzazioni e l'accesso utente funzionino nell'ambiente di RP come nell'ambiente di produzione.
    • Esegui test di penetrazione nell'ambiente di DR.
    • Esegui un test in cui il tuo consueto percorso di accesso a Google Cloud non funziona.

Passaggi successivi

Collaboratori

Autori: