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 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 a una regione diversa e a Cloud Composer ambienti cloud-native. La causa di un disastro può essere naturale o generata dall'uomo inclusi i tempi di inattività delle regioni Google Cloud e le interruzioni automatiche dell'infrastruttura.
  • Il ripristino di emergenza (RE), nel contesto di Cloud Composer, è una per ripristinare il funzionamento dell'ambiente dopo un'emergenza. La comporta la ricreazione dell'ambiente, possibilmente in un'altra regione. Per ulteriori informazioni sul ripristino di emergenza, vedi Guida alla pianificazione del ripristino di emergenza.
  • L'ambiente principale è un ambiente Cloud Composer che abilitare una funzionalità di RE.
  • L'ambiente di failover è un ambiente Cloud Composer designato per assumere il controllo delle attività dell'ambiente principale.
  • Lo scenario RE a caldo è una variante del ripristino di emergenza, in cui viene utilizzato uno stato standby dell'ambiente di failover, che creerai prima che si verifichi un'emergenza.
  • 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 a caldo o 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 il tuo ambiente principale non venga corretto in loco per affrontare il disastro. ma viene creato un secondo (failover). l'uno o l'altro dell'ambiente. che funziona invece dell'ambiente principale completamente gestito di Google Cloud. In una fase successiva, puoi decidere di tornare 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. Cambiamenti tra la piattaforma principale e l'ambiente di failover include (l'elenco non è completo):

  • L'URL del server web sarà diverso. In questo modo viene modificato l'indirizzo UI di Airflow e endpoint 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 2.0.32 e versioni successive. Gli snapshot dell'ambiente sono supportati nella versione 2.0.9 e successive.

Panoramica della preparazione

Entrambi gli scenari di RE 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. Dopo aver completato la preparazione, eliminare questo ambiente e crearlo di nuovo dopo un'emergenza.
  2. Crea un bucket per gli snapshot.

    • Il bucket deve essere disponibile nella regione di 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.

    • Controlla che i DAG possano accedere alle risorse di regione.

  3. Configura la manutenzione del database.

  4. Configura snapshot pianificati.

  5. Testa la procedura di ripristino di emergenza.

Panoramica del ripristino di emergenza

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 al failover completamente gestito di Google Cloud.
  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 di emergenza per il tuo ambiente.

Crea 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.

  • Nello scenario "hot RE", assicurati di aggiornare e eseguire l'upgrade di entrambi gli ambienti sincronizzati. 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, una gamma più ampia di possibili disastri possibili, ad esempio una calamità che influisce sulla disponibilità dell'intera regione.

  • Consigliamo di usare Terraform per creare un cluster principale 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.

  • La configurazione dell'ambiente di failover (ad esempio dimensioni dell'ambiente, di scheduler e autorizzazioni IAM) è consigliato per conformarsi alla configurazione dell'ambiente primario. le autorizzazioni IAM per entrambi gli ambienti devono concedere l'accesso appropriato a utenti e snapshot.

Verifica la disponibilità delle risorse

I DAG possono operare su risorse esterne e l'accesso a queste risorse potrebbe essere dipendono dalla configurazione dell'ambiente (come le autorizzazioni concesse l'account di servizio, la configurazione di rete o il progetto dell'ambiente). Marca 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 bucket di ambiente per il ripristino di emergenza, poiché la configurazione il criterio di conservazione e il ciclo di vita vengono applicati 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:

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

Configura la manutenzione del database

Riduci le dimensioni del database di metadati Airflow eseguendo il comando DAG di manutenzione del database. In questo modo la procedura di salvataggio e il caricamento degli snapshot più rapidamente. Il database di metadati Airflow deve avere meno risorse di oltre 20 GB di dati per supportare gli snapshot.

Configura snapshot pianificati

Configura snapshot pianificati per l'istanza principale completamente gestito di Google Cloud.

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 le Salva uno snapshot di ambiente della serie documentazione per informazioni su dove trovare gli snapshot salvati.

(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 pianificazioni con 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 tuoi canali di notifica. Torna a Avvisi dopo aver aggiunto i 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 ci sono risultati dopo aver filtrato il menu, disattiva fai clic su Mostra solo risorse attive pulsante di attivazione/disattivazione delle metriche.
    2. Per Tipo di risorsa, seleziona Ambiente Cloud Composer.
    3. Per Categoria di 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.
    Monitora l'etichetta > 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.

    • Per 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 seguente tabella.
    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 temporale continua 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. Ciò aiuta a prevenire generando 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 l'operazione di snapshot non è stata completata. correttamente e Cloud Monitoring attiva l'avviso.

    Condition name Il tuo nome personalizzato per la condizione.
  10. Fai clic su Avanti.
  11. (Facoltativo) Per aggiungere notifiche al 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 della chiusura automatica degli incidenti. Questo campo determina quando Il monitoraggio 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.
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 i potenziali problemi che influire sull'effettivo processo di ripristino di emergenza.

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 degli istantanea salvati e verificare se gli snapshot sono pronti per il ripristino di emergenza diversi scenari.

Questo metodo è utile se salvi gli snapshot con minore frequenza di almeno una volta ogni 12 ore. Per verificare le istantanee salvate con maggiore frequenza, è preferibile configurare 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 ai comandi, vedi 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 Cold DR) Creare 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 dalla del bucket dell'ambiente o in una cartella all'esterno di /dags nell'istanza del bucket dell'ambiente.

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, esegue attività come se non fosse stato eseguito nulla dall'ambiente principale dopo creando 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 dopo aver caricato lo snapshot dell'ambiente principale al suo interno.

Ad esempio, in uno scenario di RE a freddo, potrebbe essere necessario usare 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 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 primario attraverso la rete a causa di un'infrastruttura errore. Come ulteriore esempio, l'ambiente funziona con alcuni errori o con ridotta, ma alcuni DAG vengono comunque eseguiti.

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. Per Ad esempio, potresti voler recuperare non inclusi negli snapshot dell'ambiente, come la configurazione di rete o i contenuti esterno alle 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 non appena 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 di RE per l'ambiente di failover, come l'impostazione per creare 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 dei DAG nell'ambiente di failover oppure arrestale.
  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