Guida alla pianificazione del ripristino di emergenza

Questo articolo è la prima parte di una serie che tratta di disaster ripristino (DR) in Google Cloud. Questa parte fornisce una panoramica della procedura di pianificazione della RE: ciò che devi sapere per progettare e implementare un piano DR. Le parti successive descrivono casi d'uso specifici di RE con implementazioni di esempio su Google Cloud.

La serie è composta da queste parti:

Introduzione

Gli eventi che interrompono il servizio possono verificarsi in qualsiasi momento. Si potrebbe verificare un'interruzione della rete, l'ultimo push delle applicazioni potrebbe introdurre un bug critico oppure un giorno potresti dover affrontare un disastro naturale. Quando le cose non vanno per il meglio, è importante avere un piano DR solido, mirato e ben testato.

Creando un piano DR ben progettato e ben implementato, avrai la certezza che, se la catastrofe viene raggiunta, l'impatto sui risultati della tua azienda sarà minimo. Indipendentemente da come funziona la RE, Google Cloud offre una selezione di prodotti e funzionalità robusta, flessibile ed economica per la creazione o l'integrazione della soluzione adatta a te.

Nozioni di base sulla pianificazione della risposta diretta

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

  • Un obiettivo di tempo di recupero (RTO), la durata massima accettabile per cui la tua applicazione può essere offline. Questo valore di solito viene definito come parte di un accordo sul livello del servizio (SLA) più ampio.
  • Un obiettivo del punto di ripristino, che rappresenta il periodo di tempo massimo accettabile durante il quale i dati potrebbero essere persi dall'applicazione a causa di un incidente grave. Questa metrica varia in base a come vengono utilizzati i dati. Ad esempio, i dati utente modificati di frequente potrebbero avere un RPO di pochi minuti, Al contrario, i dati meno critici e modificati raramente potrebbero avere un RPO di diverse ore. Questa metrica descrive solo la durata del tempo e non la quantità o la qualità dei dati che sono andati persi.

In genere, più bassi sono i valori RTO e RPO (ovvero, maggiore è la velocità di ripristino dell'applicazione da un'interruzione), maggiore sarà il costo dell'esecuzione dell'applicazione. Il seguente grafico mostra il rapporto tra il costo e l'RTO.

Grafico che mostra che le piccole unità RTO/RPO corrispondono ai costi elevati.

Poiché valori RTO e RPO inferiori corrispondono spesso a una maggiore complessità, il sovraccarico amministrativo associato segue una curva simile. Un'applicazione ad alta disponibilità potrebbe richiedere la gestione della distribuzione tra due data center fisicamente separati, la gestione della replica e altro ancora.

I valori RTO e RPO solitamente vengono raggruppati in un'altra metrica: l'obiettivo del livello di servizio (SLO), che è un elemento misurabile misurabile di uno SLA. SLA e SLO sono spesso combinati. Uno SLA è l'intero contratto che specifica quale servizio deve essere fornito, in che modo è supportato, gli orari, le sedi, i costi, le prestazioni, le sanzioni e le responsabilità delle parti coinvolte. Gli SLO sono caratteristiche specifiche e misurabili dello SLA, come disponibilità, velocità effettiva, frequenza, tempo di risposta o qualità. Uno SLA può contenere molti SLO. gli RPO e gli RPO sono misurabili e devono essere considerati SLO.

Puoi trovare ulteriori informazioni su SLO e SLA nel libro Google Site Reliability Engineering.

Potresti anche pianificare un'architettura per l'alta disponibilità (HA). L'alta disponibilità non si sovrappone completamente alla RE, ma spesso è necessario prendere in considerazione l'alta disponibilità quando si pensa ai valori RTO e RPO. L'alta disponibilità aiuta a garantire un livello concordato di prestazioni operative, di solito tempo di attività, per un periodo più elevato del normale. Quando esegui carichi di lavoro di produzione su Google Cloud, puoi utilizzare un sistema distribuito a livello globale in modo che, se si verificano problemi in un'area geografica, l'applicazione continui a fornire il servizio anche se è meno disponibile. In sostanza, quell'applicazione chiama il suo piano DR.

Perché Google Cloud?

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

  • Capacità: protezione di risorse sufficienti per la scalabilità necessaria.
  • Sicurezza: sicurezza fisica per proteggere le risorse.
  • Infrastruttura di rete: inclusi componenti software come firewall e bilanciatori del carico.
  • Assistenza: mettere a disposizione dei tecnici qualificati le attività necessarie per eseguire la manutenzione e risolvere i problemi.
  • Larghezza di banda: pianificazione di larghezza di banda adatta per il carico di picco.
  • 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 a aggirare la maggior parte di questi fattori complicati, o tutti, rimuovendo molti costi aziendali. Inoltre, l'attenzione della Google Cloud alla semplificazione amministrativa comporta la riduzione dei costi di gestione di un'applicazione complessa.

Google Cloud offre diverse funzionalità pertinenti per la pianificazione DR, tra cui:

  • Una rete globale. Google dispone di una delle reti di computer più grandi e avanzate al mondo. La rete backbone di Google utilizza servizi di networking avanzati definiti dal software e di memorizzazione in una cache perimetrale per offrire prestazioni veloci, coerenti e scalabili.
  • Ridondanza. Più punti di presenza (PoP) in tutto il mondo significano ridondanza elevata. Il mirroring dei tuoi dati viene eseguito automaticamente sui dispositivi di archiviazione in più posizioni.
  • Scalabilità: Google Cloud è progettato per scalare come altri prodotti Google (ad esempio, Ricerca e Gmail), anche quando si verifica un picco di traffico elevato. I servizi gestiti come App Engine, i gestori della scalabilità automatica di Compute Engine e Datastore offrono la scalabilità automatica che consente alla tua applicazione di crescere e ridursi secondo le necessità.
  • Sicurezza. Il modello di sicurezza di Google si basa su oltre 15 anni di esperienza nella protezione dei clienti su applicazioni Google come Gmail e Google Workspace. Inoltre, i team di tecnici di Google che si occupano dell'affidabilità dei siti aiutano a garantire l'alta disponibilità e a prevenire l'abuso delle risorse delle piattaforme.
  • Conformità. Google si sottopone a regolari controlli indipendenti di terze parti per verificare che Google Cloud sia in linea con le normative e le best practice per la sicurezza, la privacy e la conformità. Google Cloud conforme a certificazioni come ISO 27001, SOC 2/3 e PCI DSS 3.0.

Modelli DR

I modelli DR sono considerati caldi, freddi o molto caldi. Questi pattern indicano la facilità di ripristino del sistema in caso di problemi. Potrebbe trattarsi di un'analogia con ciò che faresti se stessi guidando e forando uno pneumatico.

Tre foto di scene di pneumatici automobilistici: nessuna di scorta; quella degli attrezzi; uno pneumatico da corsa.

La misura di pneumatici dipende dalla tua preparazione:

  • Freddo: non hai uno pneumatico di scorta, quindi devi chiamare qualcuno per rivolgersi a te con un nuovo pneumatico e sostituirlo. La corsa continua fino all'arrivo dell'assistenza per effettuare la riparazione.
  • Caldo: hai un pneumatico di scorta e un kit di sostituzione, così puoi rimetterti in viaggio utilizzando quello che hai in auto. tuttavia, devi interrompere il viaggio per risolvere il problema.
  • Piccante: di pneumatici da corsa. Potrebbe essere necessario rallentare un po', ma il percorso non avrà alcun impatto immediato. Gli pneumatici sono abbastanza buoni da poter continuare (anche se alla fine devi risolvere il problema).

Creazione di un piano DR dettagliato

Questa sezione fornisce consigli su come creare il tuo piano DR.

Progettare in base agli obiettivi di recupero

Quando progetti il tuo piano DR, devi combinare le tecniche per il ripristino di applicazioni e dati e osservare il quadro generale. In genere, si tratta di esaminare i valori RTO e RPO e il modello DR che puoi adottare per soddisfarli. Ad esempio, nel caso di dati storici orientati alla conformità, probabilmente non hai bisogno di un accesso rapido ai dati, pertanto un valore RTO elevato e un pattern DR freddo sono appropriati. Tuttavia, se il servizio online subisce un'interruzione, dovrai recuperare sia i dati sia la parte lato client dell'applicazione il più rapidamente possibile. In tal caso, un pattern hot sarebbe più appropriato. Il tuo sistema di notifiche via email, che di solito non è importante per l'azienda, è probabilmente candidato per una tendenza frequente

Per indicazioni sull'utilizzo di Google Cloud per affrontare gli scenari di RE comuni, esamina gli scenari di recupero delle applicazioni. Questi scenari forniscono strategie DR target per una varietà di casi d'uso e offrono implementazioni di esempio su Google Cloud per ognuno.

Progetta per il ripristino end-to-end

Non è sufficiente avere un piano per il backup o l'archiviazione dei dati. Assicurati che il tuo piano DR risponda all'intero processo di ripristino, dal backup al ripristino e alla pulizia. Ne parliamo nei documenti correlati relativi ai dati e al recupero della RE.

Rendi specifiche le tue attività

Quando è il momento di eseguire il tuo piano DR, non devi essere incerto su cosa significhi ogni passaggio. Fai in modo che ogni attività nel tuo piano DR sia costituita da una o più azioni o comandi concreti e ambigui. Ad esempio: "Esegui lo script di ripristino" è troppo generico. Al contrario, "Apri Bash ed esegui /home/example/restore.sh" è preciso e concreto.

Implementare misure di controllo

Aggiungi controlli per impedire il verificarsi di catastrofi e per rilevare i problemi prima che si verifichino. Ad esempio, aggiungi un monitor che invii un avviso quando un flusso distruttivo dei dati, come una pipeline di eliminazione, mostra picchi imprevisti o altre attività insolite. Questo monitor potrebbe terminare anche i processi della pipeline se viene raggiunta una determinata soglia di eliminazione, impedendo una situazione catastrofica.

Preparazione del software

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

Verifica se riesci a installare il software

Assicurati che il software dell'applicazione possa essere installato dall'origine o da un'immagine preconfigurata. Assicurati di disporre di una licenza appropriata per ciascun software di cui eseguirai il deployment su Google Cloud. Per informazioni, rivolgiti al fornitore del software.

Assicurati che le risorse Compute Engine necessarie siano disponibili nell'ambiente di ripristino. Potresti dover preallocare le istanze o prenotarle.

Progetta il deployment continuo per il recupero

Il set di strumenti di deployment continuo (CD) è parte integrante quando esegui il deployment delle applicazioni. Nell'ambito del piano di recupero, devi considerare dove eseguire il deployment degli artefatti nell'ambiente recuperato. Pianifica la sede del tuo ambiente CD e gli artefatti, che devono essere disponibili e operativi in caso di disastro.

Implementare controlli di sicurezza e conformità

Quando progetti un piano RE, la sicurezza è importante. Gli stessi controlli presenti nell'ambiente di produzione devono essere applicati all'ambiente recuperato. Le normative sulla conformità verranno applicate anche all'ambiente recuperato.

Configura la sicurezza allo stesso modo per gli ambienti di ripristino di emergenza e di produzione

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

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

  • Se il tuo ambiente di produzione è Google Cloud, la replica dei criteri IAM nell'ambiente DR è semplice. Puoi utilizzare i metodi infrastructure as code (IAC) e utilizzare strumenti come Cloud Deployment Manager per eseguire il deployment dei criteri IAM in produzione. Quindi, utilizza gli stessi strumenti per vincolare i criteri alla corrispondenza delle risorse nell'ambiente DR come parte del processo di preparazione dell'ambiente DR.

  • Se il tuo ambiente di produzione è on-premise, puoi mappare i ruoli funzionali, ad esempio i ruoli amministratore di rete e revisore, ai criteri IAM con i ruoli IAM appropriati. La documentazione IAM contiene alcune configurazioni di ruolo funzionali di esempio, consulta la documentazione per la creazione di ruoli funzionali di networking e di audit logging.

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

  • Se il tuo ambiente di produzione è un altro cloud provider, mappa le autorizzazioni nei criteri IAM del provider ai criteri Google Cloud IAM. Ad esempio, se il tuo ambiente di produzione è AWS, puoi leggere Google Cloud per AWS Professional: gestione per i dettagli.

Verificare la sicurezza DR

Dopo aver configurato le autorizzazioni per l'ambiente DR, assicurati di eseguire il test di tutto. Crea un ambiente di test. Utilizza i metodi IAC che utilizzano strumenti come Deployment Manager per il deployment dei tuoi criteri Google Cloud nell'ambiente di test. Verifica che l'accesso concesso agli utenti confonda le stesse autorizzazioni concesse agli utenti on-premise.

Assicurati che gli utenti possano accedere all'ambiente DR

Allo stesso modo, non aspettare che si verifichi una calamità prima di verificare che i tuoi utenti possano accedere all'ambiente RE. Assicurati di aver concesso i diritti di accesso appropriati a utenti, sviluppatori, operatori, data scientist, amministratori di sicurezza, amministratori di rete e qualsiasi altro ruolo nella tua organizzazione. Se utilizzi un sistema di identità alternativo, assicurati che gli account siano stati sincronizzati con il tuo account Cloud Identity. Poiché l'ambiente DR sarà il tuo ambiente di produzione per un po' di tempo, invita gli utenti che dovranno accedere all'ambiente DR per accedere e risolvere eventuali problemi di autenticazione. Incorpora gli utenti che accedono all'ambiente DR come parte dei normali test DR implementati.

Per gestire a livello centrale chi ha accesso SSH a macchine virtuali (VM) avviate, abilita la funzionalità di accesso al sistema operativo nei progetti Google Cloud che costituiscono il tuo ambiente DR.

Formare gli utenti

Gli utenti devono capire come intraprendere in Google Cloud le azioni che vengono utilizzate per eseguire nell'ambiente di produzione, come l'accesso, l'accesso alle VM e così via. Utilizzando l'ambiente di test, prepara gli utenti a svolgere queste attività in modi per salvaguardare la sicurezza del tuo sistema.

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

Verifica che l'accesso al tuo ambiente DR sia limitato solo a chi deve accedervi. Assicurati che i dati PII siano oscurati e criptati. Se esegui test di penetrazione regolari sul tuo ambiente di produzione, devi includere tale ambiente come parte di questo ambito ed eseguire test regolari configurando un ambiente DR.

Assicurati che mentre il tuo ambiente DR è in servizio, tutti i log che raccogli siano sottoposti a backfill nell'archivio di log del tuo ambiente di produzione. Analogamente, assicurati che, nell'ambito del tuo ambiente DR, sia possibile esportare i log di controllo raccolti tramite Cloud Logging nell'archivio principale del sink di log. Utilizza i servizi di sink di esportazione. Per i log delle applicazioni, crea un mirroring dell'ambiente di logging e monitoraggio on-premise. Se il tuo ambiente di produzione è un altro cloud provider, mappa il logging e il monitoraggio del provider ai servizi Google Cloud equivalenti. Predisponi una procedura per formattare l'input nel tuo ambiente di produzione.

Utilizzare Cloud Storage come parte delle tue routine di backup giornaliere

Utilizza Cloud Storage per archiviare i backup. Assicurati che ai bucket che contengono i backup siano applicate le autorizzazioni appropriate.

Gestire correttamente i secret

Gestisci i secret e le chiavi a livello di applicazione utilizzando Google Cloud per ospitare il servizio di gestione di chiavi/segreti (KMS). Puoi utilizzare Cloud KMS o una soluzione di terze parti come HashiCorp Vault con un backend di Google Cloud ad esempio Spaner o Cloud Storage.

Trattare i dati recuperati come i dati di produzione

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

Scopri dove si trovano i backup e chi è autorizzato a ripristinare i dati. Assicurati che il tuo processo di ripristino sia verificabile; dopo un ripristino di emergenza, assicurati di poter mostrare chi ha avuto accesso ai dati di backup e chi ha eseguito il ripristino.

Assicurarsi che il piano DR funzioni

Per assicurarti che la tua pianificazione ripaga, assicurati che, in caso di emergenza, tutto funzioni come previsto.

Gestire più di un percorso di recupero dei dati

In caso di emergenza, il tuo metodo di connessione a Google Cloud potrebbe non essere più disponibile. Implementa un mezzo di accesso alternativo a Google Cloud per assicurarti di poter trasferire i dati in Google Cloud. Verifica regolarmente che il percorso di backup sia operativo.

Testa il tuo piano regolarmente

Dopo aver creato un piano RE, testalo regolarmente, esaminando gli eventuali problemi che si presentano e modificandolo di conseguenza. Se utilizzi Google Cloud, puoi testare scenari di ripristino a un costo minimo. Per facilitare il test, ti consigliamo di implementare quanto segue:

  • Automatizzare il provisioning dell'infrastruttura con Deployment Manager. Puoi utilizzare Deployment Manager per automatizzare il provisioning delle istanze VM e di altre infrastrutture Google Cloud. Se esegui l'ambiente di produzione on-premise, assicurati di avere un processo di monitoraggio che può avviarlo quando rileva un errore e può attivare le azioni di ripristino appropriate.
  • Monitora ed esegui il debug dei tuoi test con Cloud Logging e Cloud Monitoring. Google Cloud offre eccellenti strumenti di logging e monitoraggio a cui puoi accedere tramite le chiamate API, che ti consentono di automatizzare il deployment degli scenari di recupero reagendo alle metriche. Quando progetti i test, assicurati di disporre di risorse di monitoraggio e avviso adeguate in grado di attivare azioni di ripristino appropriate.
  • Esegui il test indicato in precedenza:

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

Passaggi successivi