Ripristino di emergenza con snapshot dell'ambiente

Cloud Composer 3 | Cloud Composer 2 | Cloud Composer 1

Questa pagina descrive come utilizzare gli snapshot dell'ambiente per il ripristino di emergenza.

Definizioni

Questa guida utilizza le seguenti definizioni:

  • Disastro è un evento in cui Cloud Composer o altri componenti essenziali per il funzionamento del tuo ambiente non sono disponibili. Questo evento richiede un failover in una regione e in ambienti Cloud Composer diversi. La causa di un disastro può essere naturale o provocata dall'uomo, includendo sia i tempi di riposo delle regioni che le interruzioni della tua infrastruttura. Google Cloud
  • Il ripristino di emergenza (RE), nel contesto di Cloud Composer, è un processo di ripristino del funzionamento dell'ambiente dopo un disastro. Il processo prevede la ricreazione dell'ambiente, eventualmente in un'altra regione. Per saperne di più sul ripristino di emergenza, consulta la guida alla pianificazione del ripristino di emergenza.
  • L'ambiente principale è un ambiente Cloud Composer per cui vuoi attivare una funzionalità di DR.
  • L'ambiente di failover è un ambiente Cloud Composer designato per assumere le attività dall'ambiente principale.
  • Lo scenario di DR a caldo è una variante del ripristino di emergenza, in cui utilizzi un ambiente di failover di riserva creato prima che si verifichi un disastro.
  • Lo scenario di RE a freddo è una variante del ripristino di emergenza, in cui viene creato un ambiente di failover dopo un'emergenza.
  • Il ripristino di emergenza tra regioni è una variante del ripristino di emergenza caldo o a freddo in cui l'ambiente principale e quello di failover si trovano in regioni diverse.

Informazioni sulla procedura di ripristino di emergenza

La procedura di ripristino di emergenza risolve il problema quando l'ambiente principale non è più operativo (difettoso o altrimenti non accessibile) a causa di un disastro.

Questa procedura presuppone che l'ambiente principale non verrà riparato sul posto per risolvere il problema. Crea invece un secondo ambiente (di failover) affiancato. Questo ambiente viene utilizzato al posto dell'ambiente primario. In un secondo momento, puoi decidere di tornare all'ambiente primario o di continuare a utilizzare l'ambiente di failover.

Poiché la procedura utilizza un ambiente di failover, le modifiche verranno introdotte quando passi dall'ambiente principale. Le modifiche tra l'ambiente principale e quello di failover includono (l'elenco non è esaustivo):

  • L'URL del server web sarà diverso. In questo modo viene modificato l'indirizzo dell'UI di Airflow e dell'endpoint dell'API REST di Airflow.

  • L'URL del bucket dell'ambiente sarà diverso.

  • La configurazione delle autorizzazioni di rete e di accesso potrebbe richiedere modifiche.

Se utilizzi lo scenario di DR a caldo, conosci in anticipo i valori del server web, gli indirizzi dei bucket dell'ambiente e la configurazione di rete.

Prima di iniziare

  • Cloud Composer supporta gli snapshot pianificati nelle versioni 2.0.32 e successive. Gli snapshot dell'ambiente sono supportati nelle versioni 2.0.9 e successive.

  • Il database Airflow deve avere meno di 20 GB di dati per creare snapshot.

  • Per creare gli snapshot, il numero totale di oggetti nelle cartelle /dags,/plugins e /data nel bucket dell'ambiente deve essere inferiore a 100.000.

  • Se utilizzi il meccanismo XCom per trasferire i file, assicurati di utilizzarlo in base alle linee guida di Airflow. Il trasferimento di file di grandi dimensioni o di un numero elevato di file utilizzando XCom influisce sul rendimento del database Airflow e può causare errori durante il caricamento degli snapshot o l'upgrade dell'ambiente. Valuta la possibilità di utilizzare alternative come Cloud Storage per trasferire grandi volumi di dati.

Panoramica della preparazione

Entrambi gli scenari di RP includono i seguenti passaggi di preparazione:

  1. Crea un ambiente di failover.

    • Nello scenario di DR a caldo, mantieni questo ambiente disponibile.
    • Nello scenario di DR a freddo, crei questo ambiente solo per testare la procedura di recupero in caso di disastro. Al termine della preparazione, elimina questo ambiente e creane uno nuovo dopo un disastro.

  2. Crea un bucket per gli snapshot.

    • Il bucket deve essere disponibile nella regione di destinazione. Per il disaster recovery tra regioni, il bucket degli snapshot deve essere multiregionale o trovarsi in una regione diversa dall'ambiente principale.

    • Verifica che i DAG possano accedere alle risorse regionali.

  3. Configura la manutenzione del database.

  4. Configura gli snapshot pianificati.

  5. Testa la procedura di ripristino di emergenza.

Panoramica del disaster recovery

Dopo un disastro:

  1. (Solo per il piano di ripristino di emergenza a freddo) Crea un ambiente di failover.
  2. Se possibile, interrompi l'esecuzione dei DAG nell'ambiente principale.
  3. Carica uno snapshot dal bucket di snapshot nell'ambiente di failover.
  4. Se necessario, modifica la configurazione dell'ambiente di failover.
  5. Decidi cosa fare con l'ambiente principale.

Passaggi di preparazione

Segui i passaggi descritti di seguito per configurare il ripristino dei dati dopo un disastro per il tuo ambiente.

Creare un ambiente di failover

Crea un ambiente che funge da ambiente di failover.

Segui queste linee guida:

  • L'ambiente principale e di failover deve utilizzare la stessa versione di Cloud Composer e Airflow.

  • Nello scenario di DR a caldo, assicurati di aggiornare e eseguire l'upgrade di entrambi gli ambienti in sincronia. Ad esempio, se esegui l'upgrade dell'ambiente principale a una versione successiva di Cloud Composer o installi pacchetti PyPI, anche l'ambiente di failover deve avere queste modifiche.

  • Ti consigliamo di creare l'ambiente di failover in un'area geografica diversa dall'ambiente primario. Di conseguenza, è possibile coprire una gamma più ampia di possibili scenari di calamità, ad esempio una calamità che influisce sulla disponibilità dell'intera regione.

  • Ti consigliamo di utilizzare Terraform per creare ambienti principali e di failover, in modo che entrambi abbiano una configurazione coerente. Assicurati che le definizioni di Terraform per gli ambienti principali e di failover siano sincronizzate.

  • È consigliabile che la configurazione dell'ambiente di failover (ad esempio le dimensioni dell'ambiente, il numero di pianificatori e le autorizzazioni IAM) sia conforme alla configurazione dell'ambiente principale. Le autorizzazioni IAM per entrambi gli ambienti devono fornire accesso appropriato a utenti e snapshot.

Verificare la disponibilità delle risorse

I DAG possono operare su risorse esterne e l'accesso a queste risorse potrebbe dipendere dalla configurazione dell'ambiente (ad esempio le autorizzazioni concesse all'account di servizio, alla configurazione di rete o al progetto dell'ambiente). Assicurati che queste risorse siano disponibili per l'ambiente di failover.

Un ambiente potrebbe interagire con alcune risorse esterne tramite connessioni memorizzate in Airflow. Verifica se queste risorse devono essere regolate nell'ambiente di failover rispetto all'ambiente principale.

Creare un bucket di archiviazione per gli snapshot

Crea un nuovo bucket di archiviazione per gli snapshot dell'ambiente. Non utilizzare i bucket dell'ambiente per il ripristino di emergenza, poiché la configurazione del criterio di conservazione e del ciclo di vita viene applicata a livello di bucket.

Assicurati che questo bucket di archiviazione abbia autorizzazioni IAM, un criterio di conservazione e una configurazione del ciclo di vita impostata in modo da impedire l'eliminazione accidentale o l'accesso non autorizzato. Per ulteriori informazioni sulla configurazione di un bucket per gli snapshot, consulta la pagina Configurare gli snapshot pianificati.

Puoi:

  • Crea un bucket in un'altra regione.
  • Crea un bucket multiregionale.

Configura la manutenzione del database

Mantieni il database Airflow di piccole dimensioni e rispetta il limite di dimensioni impostando la pulizia del database. In questo modo, la procedura di salvataggio e caricamento degli istantanei sarà più rapida. Il database Airflow deve avere meno di 20 GB di dati per creare snapshot.

Configurare gli snapshot pianificati

Configura gli snapshot pianificati per l'ambiente principale.

Gli snapshot possono essere creati solo in un ambiente in buono stato, pertanto devono essere salvati prima che si verifichi un disastro.

Per ulteriori informazioni sul funzionamento degli snapshot, consulta Salvare e caricare gli snapshot dell'ambiente. Consulta la sezione Salvare uno snapshot dell'ambiente della documentazione per informazioni su dove trovare gli snapshot salvati.

(Facoltativo) Configura il monitoraggio per le operazioni di snapshot pianificate

Per gli snapshot pianificati con una frequenza di almeno una volta ogni 12 ore, puoi utilizzare Cloud Monitoring per ricevere un avviso quando uno snapshot non viene creato automaticamente.

Per le pianificazioni con una frequenza inferiore, utilizza Google Cloud CLI per verificare i risultati delle operazioni di snapshot. Consulta Verificare le operazioni di salvataggio degli snapshot.

  1. Nella console Google Cloud, vai alla pagina Monitoring.

    Vai a Monitoring

  2. Nel riquadro di navigazione di Monitoring, seleziona Avvisi.
  3. Se non hai creato i canali di notifica e vuoi ricevere notifiche, fai clic su Modifica canali di notifica e aggiungili. Torna alla pagina Avvisi dopo aver aggiunto i tuoi canali.
  4. Nella pagina Avvisi, seleziona Crea criterio.
  5. Per selezionare la metrica, espandi il menu Seleziona una metrica e poi procedi nel seguente modo:
    1. Per limitare il menu alle voci pertinenti, inserisci Composer Snapshot nella barra dei filtri. Se non vengono visualizzati risultati dopo aver filtrato il menu, disattiva l'opzione Mostra solo risorse e metriche attive.
    2. Per Tipo di risorsa, seleziona Ambiente Cloud Composer.
    3. Per Categoria metrica, seleziona Ambiente.
    4. Per Metrica, seleziona Conteggio creazione snapshot.
    5. Seleziona Applica.
  6. Fai clic su Aggiungi filtro e utilizza i menu a discesa per aggiungere i seguenti filtri:
    Filtro Comparatore Valore
    Etichetta della risorsa > environment_name = Il nome dell'ambiente in cui vuoi monitorare gli snapshot pianificati.
    Etichetta del monitor > risultato = SUCCEEDED

  7. Nella sezione Trasforma i dati, imposta i seguenti attributi:
    • Per Finestra mobile, seleziona la finestra di monitoraggio per questo avviso. Questo valore influisce sulla configurazione della soglia nel passaggio successivo.

      Valore consigliato per il monitoraggio degli snapshot pianificati: 1 giorno.

    • In Funzione finestra temporale continua, seleziona delta.
  8. Fai clic su Avanti.
  9. Le impostazioni nella pagina Configura attivatore di avvisi determinano quando viene attivato l'avviso. Completa questa pagina con le impostazioni riportate nella tabella seguente.
    Campo Valore
    Condition type Threshold
    Alert trigger Any time series violates
    Threshold position Below threshold
    Threshold value Il numero di istantanee pianificate che prevedi di salvare entro il periodo di tempo configurato come Finestra mobile per l'avviso.

    Calcola questo valore utilizzando la seguente formula:

    (rolling window in hours / schedule frequency in hours) - 1

    Nota: la detrazione di un'ora nella formula è necessaria per tenere conto dei tempi di completamento degli istantanei variabili.1 In questo modo, si evita di generare falsi positivi se lo snapshot più recente è ancora in esecuzione durante un controllo di monitoraggio.

    Esempio:
    Se utilizzi la finestra mobile consigliata di 1 giorno e la frequenza della pianificazione è una volta ogni 2 ore, imposta questo valore su 11 (come da calcolo: 24 / 2 - 1 = 11).

    Se la programmazione viene eseguita correttamente, in un intervallo di 24 ore dovresti avere almeno 11 istantanee. In caso contrario, significa che un'operazione di snapshot non è stata completata correttamente e Cloud Monitoring attiva questo avviso.

    Condition name Il nome personalizzato per la condizione.
  10. Fai clic su Avanti.
  11. (Facoltativo) Per aggiungere notifiche al tuo criterio di avviso, fai clic su Canali di notifica. Nella finestra di dialogo, seleziona uno o più canali di notifica dal menu e fai clic su OK.
  12. (Facoltativo) Aggiorna la Durata chiusura automatica incidenti. Questo campo determina quando Monitoring chiude gli incidenti in assenza di dati delle metriche.
  13. (Facoltativo) Fai clic su Documentazione e aggiungi tutte le informazioni che vuoi includere in un messaggio di notifica.
  14. Fai clic su Nome avviso e inserisci un nome per il criterio di avviso.
  15. Fai clic su Crea criterio.
Per ulteriori informazioni, consulta Criteri di avviso.

Testa la procedura di ripristino di emergenza

Assicurati di testare la procedura di ripristino dei disastri dopo averla configurata e poi periodicamente. In questo modo puoi risolvere i potenziali problemi che potrebbero influire sul processo di ripristino dei disastri effettivo.

Nello scenario di DR a freddo, puoi eliminare l'ambiente di failover al termine del test della procedura di disaster recovery.

Verifica le operazioni di salvataggio degli snapshot

Puoi utilizzare Google Cloud CLI per recuperare l'elenco delle operazioni di salvataggio dello snapshot e verificare se gli snapshot sono pronti per gli scenari di disaster recovery.

Questo metodo è utile se salvi gli snapshot meno di una volta ogni 12 ore. Per verificare gli snapshot salvati più di frequente, è meglio configurare gli avvisi di Cloud Monitoring. Consulta Configurare il monitoraggio per le operazioni di snapshot pianificate.

gcloud

Elenca tutte le operazioni di snapshot per un ambiente specifico. Per il riferimento completo del comando, consulta gcloud composer operations list.

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

Sostituisci:

  • LOCATIONS con l'elenco degli identificatori di regione in cui si trova l'ambiente
  • PROJECT_ID con l'identificatore del progetto in cui si trova l'ambiente
  • ENVIRONMENT_ID con l'identificatore dell'ambiente in cui vuoi controllare le operazioni di snapshot

Esempio:

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

Dopo un'emergenza

Per recuperare l'ambiente principale, segui i passaggi descritti di seguito dopo un disastro.

(Solo DR a freddo) Crea un ambiente di failover

Segui le istruzioni nella sezione Creare un ambiente di failover.

Impedire all'ambiente principale di eseguire i DAG

Se possibile, impedisci all'ambiente principale di eseguire i DAG:

  • Se l'ambiente principale è ancora accessibile, metti in pausa tutti i DAG.
  • Se il bucket dell'ambiente principale è accessibile, sposta tutti i DAG dal bucket dell'ambiente o in una cartella esterna a /dags nel bucket dell'ambiente principale.

Carica uno snapshot nell'ambiente di failover

Carica uno snapshot dall'ambiente principale nell'ambiente di failover.

Una volta caricato lo snapshot nell'ambiente di failover, le attività vengono pianificate ed eseguite come se nell'ambiente principale non fosse stato eseguito nulla dopo la creazione di uno snapshot. Tuttavia, alcune di queste attività potrebbero essere già state eseguite dall'ambiente principale. L'ambiente di failover non ha alcun modo per riconoscere le attività che sono state eseguite dopo la creazione dello snapshot e prima di un disastro. Di conseguenza, alcune attività potrebbero essere eseguite due volte (sia nell'ambiente principale sia in quello di failover). Consigliamo che tutte le attività siano idempotenti e che gli snapshot pianificati vengano creati ogni due ore.

(Se necessario) Modifica la configurazione dell'ambiente di failover

In alcuni casi, potresti voler modificare la configurazione dell'ambiente di failover dopo aver caricato lo snapshot dell'ambiente principale.

Ad esempio, in uno scenario di DR a freddo, potrebbe essere necessario utilizzare un insieme diverso di variabili di ambiente Airflow nell'ambiente di failover. Come altro esempio, in uno scenario di DR a caldo, potresti dover concedere autorizzazioni agli utenti nell'interfaccia utente di Airflow, in modo che possano accedere all'ambiente di failover.

Puoi eseguire queste modifiche manualmente o preparare uno script shell con comandi che modificano la configurazione dell'ambiente di failover eseguendo comandi gcloud composer environment update.

Decidi cosa fare con l'ambiente principale

Alcuni disastri potrebbero verificarsi perché l'ambiente principale non è raggiungibile, ma è ancora operativo o non funziona correttamente. Ad esempio, non puoi accedere all'ambiente principale tramite la rete a causa di un guasto dell'infrastruttura. Un altro esempio è un ambiente che funziona con alcuni errori o con una capacità ridotta, ma in cui vengono comunque eseguiti alcuni DAG.

Se l'ambiente originale è ancora in esecuzione, potrebbe generare costi direttamente correlati a Cloud Composer o ad altri servizi a cui si accede tramite i DAG, anche se è stato creato un nuovo ambiente come sostituzione. Questo ambiente può comunque eseguire alcuni DAG. Di conseguenza, alcune operazioni potrebbero essere eseguite due volte: nell'ambiente principale ancora in esecuzione e nell'ambiente di failover dopo il caricamento dello snapshot.

Se l'ambiente principale esiste, ma non funziona correttamente

L'ambiente principale può essere eliminato se tutti i dati pertinenti sono stati recuperati. Ad esempio, potresti voler recuperare dati non inclusi negli snapshot dell'ambiente, come la configurazione di rete o i contenuti del bucket dell'ambiente al di fuori delle cartelle /dags e /plugins.

Se l'ambiente principale diventa di nuovo accessibile e integro

Se l'ambiente principale non era accessibile solo temporaneamente e diventa nuovamente accessibile e funzionante, puoi scegliere un approccio:

  • Continua a utilizzare l'ambiente di failover.
  • Torna all'ambiente principale.

Per continuare a utilizzare l'ambiente di failover:

  1. Se l'ambiente principale esegue ancora i DAG, mettili in pausa il prima possibile.
  2. Assicurati che tutti i dati pertinenti siano recuperati, quindi elimina l'ambiente primario.
  3. Ripeti i passaggi di preparazione del DR per l'ambiente di failover, ad esempio la configurazione degli snapshot pianificati.

Per tornare all'ambiente principale:

  1. Metti in pausa tutti i DAG nell'ambiente di failover.
  2. Attendi il completamento di tutte le esecuzioni del DAG nell'ambiente di failover o interrompile.
  3. Salva uno snapshot dell'ambiente di failover.
  4. Carica questo snapshot nell'ambiente principale.
  5. Ripristina la messa in pausa dei DAG nell'ambiente principale.
  6. Se necessario, elimina l'ambiente di failover.

Passaggi successivi