Ripristino di emergenza con snapshot dell'ambiente

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

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

Definizioni

Questa guida utilizza le seguenti definizioni:

• Disaster è 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 diversa e con Cloud Composer ambienti cloud-native. La causa di un disastro può essere naturale o provocata dall'uomo, includendo sia i tempi di riposo delle regioni Google Cloud sia le interruzioni della tua infrastruttura.
• Il ripristino di emergenza (RE), nel contesto di Cloud Composer, è una processo di ripristino del funzionamento dell'ambiente dopo un'emergenza. La comporta la ricreazione dell'ambiente, possibilmente 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 il controllo delle attività dell'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 RE freddo è una variante del ripristino di emergenza, in cui crei uno dell'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 l'ambiente non è operativo (non funzionante o comunque non accessibile) perché di un disastro.

Questa procedura presuppone che l'ambiente principale non verrà riparato sul posto per risolvere il problema. ma viene creato un secondo (failover). l'uno o l'altro dell'ambiente. 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, verranno introdotte quando si passa 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 l'endpoint dell'API REST di Airflow.

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

• Potrebbe essere necessario modificare la configurazione delle autorizzazioni di rete e di accesso.

Se utilizzi lo scenario "hot RE", conosci i valori per il server web, gli indirizzi dei bucket dell'ambiente e la configurazione di rete in anticipo.

Prima di iniziare

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

• Il database Airflow deve avere meno di 20 GB di 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 lo usi 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 l'uso di alternative come 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 caldo di RE, mantieni disponibile questo ambiente.
   • Nello scenario di RE a freddo, crei questo ambiente solo per testare una procedura di ripristino di emergenza. 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 RE. Per la RE tra regioni, Il bucket di snapshot deve essere in più regioni o trovarsi in una regione diversa rispetto all'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'emergenza:

1. (Solo Cold DR) 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 funga da ambiente di failover.

Segui queste linee guida:

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

  Attenzione: non eseguire il failover a una versione più recente di Cloud Composer o Airflow, poiché potrebbero essere necessarie modifiche aggiuntive relative alla compatibilità.

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

• Consigliamo di creare l'ambiente di failover in una regione diversa da quella nell'ambiente principale. 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. Accertati che Le definizioni di Terraform per gli ambienti primari e di failover sincronizzati.

• È 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 istantanee.

Verifica 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 archiviate in Airflow. Controllo se queste risorse devono essere regolate nell'ambiente di failover rispetto nell'ambiente principale.

Crea 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 disaster recovery, poiché la configurazione del criterio di conservazione e del ciclo di vita viene applicata a livello di bucket.

Assicurati che questo bucket di archiviazione disponga di autorizzazioni IAM, un criterio di conservazione e una configurazione del ciclo di vita impostata in modo da impedire eliminazione accidentale o accesso non autorizzato. Per ulteriori informazioni configurare un bucket per gli snapshot, Configurazione degli snapshot pianificati.

Puoi:

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

di Gemini Advanced.

Attenzione: se crei un bucket nella stessa regione dell'ambiente principale, alcuni scenari di emergenza non possono essere coperti, ad esempio un'emergenza che colpisce dell'intera regione.

Configura la manutenzione del database

Riduci le dimensioni del database Airflow e entro il limite di dimensioni configurando pulizia del database. In questo modo la procedura di salvataggio e il caricamento degli snapshot più rapidamente. Il database Airflow deve avere meno risorse di oltre 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 integro, quindi devono essere salvate prima del disastro.

Per saperne di più sul funzionamento degli snapshot, consulta Salva e carica gli snapshot dell'ambiente. Consulta la sezione Salvare uno snapshot dell'ambiente della documentazione per informazioni su dove trovare gli snapshot salvati.

Nota: i limiti di quota consentono fino a 52 operazioni di salvataggio di snapshot al giorno per un singolo ambiente. Se vuoi istantanee pianificate acquisite a intervalli regolari intervalli, l'intervallo tra loro deve essere di almeno 30 minuti.

(Facoltativo) Configurare 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 non viene creato automaticamente uno snapshot.

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 dello 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 aggiungi i canali di notifica. 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 segui questi passaggi:
   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. In Tipo di risorsa, seleziona Ambiente Cloud Composer.
   3. Per la 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:
   • In Finestra temporale continua, seleziona la finestra di monitoraggio per questo avviso. Questo valore influisce sulla configurazione della soglia nel passaggio successivo.

     Valore consigliato per il monitoraggio pianificato dello snapshot: 1 giorno.

   • In Funzione finestra temporale continua, seleziona delta.
8. Fai clic su Avanti.
9. Le impostazioni nella pagina Configura trigger di avviso determinano quando l'avviso viene attivato. 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:deduce 1 ora nella formula è tenere conto dei diversi tempi di completamento degli snapshot. 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 temporale continua consigliata di 1 giorno, e la frequenza di pianificazione è una volta ogni 2 ore, imposta questo valore su 11 (calcolo: 24 / 2 - 1 = 11). Se la pianificazione funziona correttamente, entro un periodo di 24 ore deve avere almeno 11 snapshot. In caso contrario, significa che un'operazione di snapshot non è stata completata correttamente e Cloud Monitoring attiva questo avviso.
   Condition name	Il tuo 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 una o più notifiche canali dal menu, quindi 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, quindi aggiungi le eventuali informazioni da 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.

di Gemini Advanced. Per saperne di più, consulta Criteri di avviso.

Testa la procedura di ripristino di emergenza

Assicurati di testare la procedura di ripristino di emergenza dopo la configurazione e quindi periodicamente. In questo modo puoi risolvere potenziali problemi che potrebbero influire sul processo di ripristino dei disastri effettivo.

Nello scenario di RE a freddo, puoi eliminare l'ambiente di failover completare la verifica della procedura di ripristino di emergenza.

Verifica le operazioni di salvataggio dello 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 Configura il monitoraggio per le operazioni di snapshot pianificate.

gcloud

Elenca tutte le operazioni di snapshot per un ambiente specifico. Per il riferimento completo dei comandi, 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 di identificatori di regione in cui l'ambiente si trova localizzato
• 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 disastro

Dopo un'emergenza, segui i passaggi descritti di seguito per ripristinare completamente gestito di Google Cloud.

(Solo DR a freddo) Crea un ambiente di failover

Segui le istruzioni riportate nella sezione Creare un ambiente di failover.

Interrompi l'esecuzione dei DAG nell'ambiente principale

Se possibile, interrompi l'esecuzione dei DAG nell'ambiente principale:

• 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 consente di riconoscere le attività eseguite dopo la creazione dello snapshot e prima di un disastro. Di conseguenza, alcune attività potrebbero essere eseguite due volte (in sia l'ambiente primario che quello di failover). Consigliamo di eseguire tutte le attività sono idempotenti e che gli snapshot pianificati create ogni due ore.

(Se necessario) Regola 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. Per fare un altro esempio, in uno scenario caldo di RE, potrebbe essere necessario concedere le autorizzazioni agli utenti alla UI 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.

Decidere 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 primario attraverso la rete a causa di un'infrastruttura errore. 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 sostituzione. Questo ambiente può comunque eseguire alcuni DAG; Di conseguenza, alcune operazioni potrebbero essere eseguite due volte: nell'ambiente primario 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 sono stati recuperati tutti i dati pertinenti. 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 era inaccessibile solo temporaneamente e diventa accessibile e integro, 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 vengano recuperati, quindi elimina l'account principale completamente gestito di Google Cloud.
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. Riattiva i DAG nell'ambiente principale.
6. Se necessario, elimina l'ambiente di failover.

Passaggi successivi

• Configurare gli snapshot pianificati
• Creare ambienti