Cloud Composer 1 est en mode post-maintenance. Google ne publie plus de mises à jour de Cloud Composer 1, y compris les nouvelles versions d'Airflow, les corrections de bugs et les mises à jour de sécurité. Nous vous recommandons de planifier la migration vers Cloud Composer 2.

Reprise après sinistre avec des instantanés d'environnement

Cloud Composer 1 | Cloud Composer 2

Cette page explique comment utiliser des instantanés d'environnement pour la reprise après sinistre.

Définitions

Ce guide utilise les définitions suivantes:

Un catastrophe est un événement pour lequel Cloud Composer ou d'autres composants essentiels au fonctionnement de votre environnement ne sont pas disponibles. Cet événement nécessite un basculement vers une région et des environnements Cloud Composer différents. Un sinistre peut être d'origine naturelle ou d'origine humaine, y compris les temps d'arrêt des régions Google Cloud et les pannes de votre propre infrastructure.
Dans le contexte de Cloud Composer, la reprise après sinistre (DR) est un processus de restauration du fonctionnement de l'environnement après un sinistre. Le processus implique de recréer l'environnement, éventuellement dans une autre région. Pour en savoir plus sur la reprise après sinistre, consultez la page Guide de planification de reprise après sinistre.
L'environnement principal est un environnement Cloud Composer pour lequel vous souhaitez activer une fonctionnalité de reprise après sinistre.
L'environnement de basculement est un environnement Cloud Composer conçu pour reprendre les activités de l'environnement principal.
Le scénario de reprise après sinistre à chaud est une variante de la reprise après sinistre, dans laquelle vous utilisez un environnement de basculement de secours que vous créez avant qu'un sinistre ne se produise.
Le scénario de reprise après sinistre à froid est une variante de la reprise après sinistre, dans laquelle vous créez un environnement de basculement après un sinistre.
La reprise après sinistre interrégionale est une variante de la reprise après sinistre tiède ou à froid, dans laquelle l'environnement principal et l'environnement de basculement sont situés dans des régions différentes.

À propos de la procédure de reprise après sinistre

La procédure de reprise après sinistre résout le problème lorsque votre environnement principal est devenu inopérant (cassé ou inaccessible) en raison d'un sinistre.

Cette procédure suppose que votre environnement principal ne sera pas fixe en place pour faire face au sinistre. À la place, vous créez un second environnement (de basculement) côte à côte. Cet environnement fonctionne à la place de l'environnement principal. Par la suite, vous pourrez décider de revenir à l'environnement principal ou de continuer à utiliser l'environnement de basculement.

Étant donné que la procédure utilise un environnement de basculement, des modifications sont apportées lorsque vous passez à l'environnement principal. Voici les modifications apportées entre l'environnement principal et l'environnement de basculement (cette liste n'est pas exhaustive):

L'URL du serveur Web sera différente. Cette opération modifie l'adresse de l'interface utilisateur Airflow et du point de terminaison de l'API REST Airflow.
L'URL du bucket de l'environnement sera différente.
La configuration des autorisations d'accès et concernant le réseau peut nécessiter un ajustement.

Si vous utilisez le scénario de reprise après sinistre tiède, vous connaissez à l'avance les valeurs du serveur Web, les adresses des buckets de l'environnement et la configuration du réseau.

Avant de commencer

Cloud Composer est compatible avec les instantanés programmés à partir de la version 2.0.32. Les instantanés d'environnement sont compatibles avec les versions 2.0.9 et ultérieures.

Présentation de la préparation

Les deux scénarios de reprise après sinistre incluent les étapes de préparation suivantes:

Créez un environnement de basculement.
- Dans le scénario de reprise après sinistre tiède, cet environnement reste disponible.
- Dans le scénario de reprise après sinistre à froid, vous créez cet environnement uniquement pour tester votre procédure de reprise après sinistre. Une fois la préparation terminée, vous devez supprimer cet environnement, puis le recréer après un sinistre.
Créez un bucket pour les instantanés.
- Le bucket doit être disponible dans la région de reprise après sinistre. Pour la reprise après sinistre interrégionale, le bucket d'instantanés doit être multirégional ou se trouver dans une région différente de celle de l'environnement principal.
- Vérifiez que les DAG peuvent accéder aux ressources régionales.
Configurez la maintenance de BDD.
Configurer des instantanés programmés
Tester votre procédure de reprise après sinistre

Présentation de la reprise après sinistre

Après un sinistre:

(Reprise après sinistre à froid uniquement) Créez un environnement de basculement.
Si possible, empêchez l'environnement principal d'exécuter les DAG.
Chargez un instantané à partir du bucket d'instantanés vers l'environnement de basculement.
Si nécessaire, ajustez la configuration de l'environnement de basculement.
Décidez de ce que vous souhaitez faire avec l'environnement principal.

Étapes de préparation

Suivez la procédure ci-dessous pour configurer la reprise après sinistre pour votre environnement.

Créer un environnement de basculement

Créez un environnement qui agira en tant qu'environnement de basculement.

Respectez les consignes suivantes :

Votre environnement principal et votre environnement de basculement doivent utiliser la même version de Cloud Composer et d'Airflow.

Attention :N'effectuez pas de basculement vers une version plus récente de Cloud Composer ou Airflow, car cela pourrait nécessiter des modifications supplémentaires liées à la compatibilité.
Dans le scénario de reprise après sinistre tiède, assurez-vous de mettre à jour et de mettre à niveau les deux environnements de manière synchronisée. Par exemple, si vous mettez à niveau l'environnement principal vers une version ultérieure de Cloud Composer ou si vous installez des packages PyPI, votre environnement de basculement doit également comporter ces modifications.
Nous vous recommandons de créer l'environnement de basculement dans une région différente de l'environnement principal. Ainsi, un plus large éventail de scénarios de sinistre possibles peut être couvert, par exemple un sinistre qui affecte la disponibilité de l'ensemble de la région.
Nous vous recommandons d'utiliser Terraform pour créer des environnements principaux et de basculement, de sorte que la configuration soit cohérente. Assurez-vous que les définitions Terraform pour les environnements principal et de basculement sont synchronisées.
La configuration de l'environnement de basculement (telle que la taille de l'environnement, le nombre de programmeurs et les autorisations IAM) est recommandée pour être conforme à la configuration de l'environnement principal. Les autorisations IAM pour les deux environnements doivent accorder l'accès approprié aux utilisateurs et aux instantanés.

Vérifier la disponibilité des ressources

Les DAG peuvent fonctionner sur des ressources externes, et l'accès à ces ressources peut dépendre de la configuration de l'environnement (par exemple, les autorisations accordées au compte de service, à la configuration réseau ou au projet de l'environnement). Assurez-vous que ces ressources sont disponibles pour l'environnement de basculement.

Un environnement peut interagir avec certaines ressources externes via des connexions stockées dans Airflow. Vérifiez si ces ressources doivent être ajustées dans l'environnement de basculement par rapport à l'environnement principal.

Créer un bucket de stockage pour les instantanés

Créez un bucket de stockage pour les instantanés d'environnement. N'utilisez pas les buckets d'environnement pour la reprise après sinistre, car la configuration de la règle de conservation et du cycle de vie est appliquée au niveau du bucket.

Assurez-vous que ce bucket de stockage dispose d'autorisations IAM, d'une règle de conservation et d'une configuration de cycle de vie définie de manière à empêcher toute suppression accidentelle ou accès non autorisé. Pour en savoir plus sur la configuration d'un bucket pour les instantanés, consultez la page Configurer des instantanés programmés.

Vous pouvez :

Créez un bucket dans une autre région.
Créer un bucket multirégional

Configurer la maintenance de BDD

Réduisez la taille de la base de données de métadonnées Airflow en exécutant le DAG de maintenance de la base de données. Cela accélère l'enregistrement et le chargement des instantanés. La base de données de métadonnées Airflow doit contenir moins de 20 Go de données pour prendre en charge les instantanés.

Configurer des instantanés programmés

Configurez des instantanés programmés pour l'environnement principal.

Les instantanés ne peuvent être créés que dans un environnement sain. Ils doivent donc être enregistrés avant que le sinistre ne survienne.

Pour en savoir plus sur le fonctionnement des instantanés, consultez Enregistrer et charger des instantanés d'environnement. Consultez la section Enregistrer un instantané d'environnement de la documentation pour savoir où trouver les instantanés enregistrés.

(Facultatif) Configurer la surveillance pour les opérations d'instantanés planifiées

Pour les instantanés programmés à une fréquence au moins une fois toutes les 12 heures, vous pouvez utiliser Cloud Monitoring pour vous avertir lorsqu'un instantané n'est pas créé automatiquement.

Pour les programmations de fréquences inférieures, vous devez vérifier les résultats des opérations d'instantanés à l'aide de Google Cloud CLI. Consultez la section Vérifier les opérations d'enregistrement d'instantanés.

Dans la console Google Cloud, accédez à la page Monitoring.
Accéder à Monitoring
Dans le volet de navigation Monitoring, sélectionnez Alertes :
Si vous n'avez pas créé vos canaux de notification et que vous souhaitez être averti, cliquez sur Modifier les canaux de notification et ajoutez vos canaux de notification. Revenez à la page Alertes après avoir ajouté vos canaux.
Sur la page Alertes, cliquez sur Créer une règle.
Pour sélectionner la métrique, développez le menu Select a metric (Sélectionner une métrique), puis procédez comme suit :
1. Pour limiter le menu aux entrées pertinentes, saisissez Composer Snapshot dans la barre de filtre. Si aucun résultat ne s'affiche après avoir filtré le menu, désactivez l'option Afficher seulement les ressources et les métriques actives.
2. Dans le champ Type de ressource, sélectionnez Environnement Cloud Composer.
3. Dans le champ Catégorie de métrique, sélectionnez Environnement.
4. Pour le champ Métrique, sélectionnez Nombre de créations d'instantanés.
5. Sélectionnez Apply (Appliquer).

Cliquez sur Ajouter un filtre et utilisez les menus déroulants pour ajouter les filtres suivants:

Filtre	Comparateur	Valeur
Libellé de la ressource > Environment_name	=	Nom de l'environnement dans lequel vous souhaitez surveiller les instantanés programmés.
Surveiller libellé > Résultat	=	`SUCCEEDED`

Dans la section Transformer les données, définissez les attributs suivants :
- Dans le champ Fenêtre glissante, sélectionnez la fenêtre de surveillance pour cette alerte. Cette valeur a une incidence sur la configuration du seuil à l'étape suivante.
  Valeur recommandée pour la surveillance programmée des instantanés: 1 jour.
- Pour Fenêtrage glissant, sélectionnez delta.
Cliquez sur Suivant.

Les paramètres de la page Configurer le déclencheur d'alerte déterminent le moment où l'alerte se déclenche. Renseignez les paramètres indiqués dans le tableau ci-dessous sur cette page.

Champ	Valeur
`Condition type`	`Threshold`
`Alert trigger`	`Any time series violates`
`Threshold position`	`Below threshold`
`Threshold value`	Nombre d'instantanés programmés que vous prévoyez d'enregistrer dans le délai configuré en tant que Fenêtre glissante pour l'alerte. Calculez cette valeur à l'aide de la formule suivante: `(rolling window in hours / schedule frequency in hours) - 1` Remarque:Le fait de déduire `1` heure dans la formule permet de prendre en compte les délais d'achèvement des instantanés variables. Cela permet d'éviter de générer de faux positifs si le dernier instantané est toujours en cours d'exécution lors d'une vérification de la surveillance. Exemple: Si vous utilisez la période glissante recommandée de 1 jour et que la fréquence de programmation est définie sur une fois toutes les deux heures, définissez cette valeur sur `11` (selon le calcul: `24 / 2 - 1 = 11`). Si votre programmation s'exécute correctement, vous devez avoir au moins 11 instantanés au cours d'une période de 24 heures. Sinon, cela signifie qu'une opération d'instantané n'a pas abouti et que Cloud Monitoring déclenche cette alerte.
`Condition name`	Nom personnalisé de la condition.

Cliquez sur Suivant.
Facultatif : Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.
(Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
Cliquez sur Créer une stratégie.

Pour en savoir plus, consultez la page Règles d'alerte.

Tester votre procédure de reprise après sinistre

Veillez à tester votre procédure de reprise après sinistre après l'avoir configurée, puis régulièrement par la suite. Cela vous permet de résoudre les problèmes potentiels qui pourraient avoir une incidence sur le processus réel de reprise après sinistre.

Dans le scénario de reprise après sinistre à froid, vous pouvez supprimer l'environnement de basculement une fois que vous avez terminé de tester la procédure de reprise après sinistre.

Vérifier les opérations d'enregistrement d'instantanés

Vous pouvez utiliser Google Cloud CLI pour récupérer la liste des opérations d'enregistrement d'instantanés et vérifier si vos instantanés sont prêts pour des scénarios de reprise après sinistre.

Cette méthode est utile si vous enregistrez des instantanés moins d'une fois toutes les 12 heures. Pour vérifier les instantanés enregistrés plus fréquemment, il est préférable de configurer les alertes Cloud Monitoring. Consultez Configurer la surveillance des opérations d'instantanés planifiées.

gcloud

Répertoriez toutes vos opérations d'instantané pour un environnement spécifique. Pour obtenir la documentation de référence complète sur les commandes, consultez la section 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

Remplacez :

LOCATIONS par la liste des identifiants des régions où se trouve l'environnement ;
PROJECT_ID par l'identifiant du projet dans lequel se trouve l'environnement ;
ENVIRONMENT_ID par l'identifiant de l'environnement dans lequel vous souhaitez vérifier les opérations d'instantané.

Exemple :

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

Après un sinistre

Après un sinistre, suivez les étapes ci-dessous pour récupérer votre environnement principal.

(Reprise après sinistre à froid uniquement) Créer un environnement de basculement

Suivez les instructions de la section Créer un environnement de basculement.

Empêcher l'environnement principal d'exécuter les DAG

Si possible, empêchez l'environnement principal d'exécuter les DAG:

Si l'environnement principal est toujours accessible, suspendez tous les DAG.
Si le bucket de l'environnement principal est accessible, déplacez tous les DAG depuis le bucket de l'environnement ou vers un dossier à l'extérieur de /dags dans le bucket de l'environnement principal.

Charger un instantané dans l'environnement de basculement

Chargez un instantané depuis l'environnement principal vers l'environnement de basculement.

Une fois l'instantané chargé dans l'environnement de basculement, il planifie et exécute les tâches comme si rien n'avait été exécuté par l'environnement principal après la création d'un instantané. Cependant, certaines de ces tâches peuvent déjà avoir été exécutées par l'environnement principal. L'environnement de basculement n'a aucun moyen de reconnaître les tâches qui ont été exécutées après la création de l'instantané et avant un sinistre. Par conséquent, certaines tâches peuvent être exécutées deux fois (à la fois dans l'environnement principal et dans l'environnement de basculement). Nous vous recommandons de faire en sorte que toutes les tâches soient idempotentes et que les instantanés planifiés soient créés toutes les deux heures.

(Si nécessaire) Ajuster la configuration de l'environnement de basculement

Dans certains cas, vous pouvez modifier la configuration de l'environnement de basculement après y avoir chargé l'instantané de l'environnement principal.

Par exemple, dans un scénario de reprise après sinistre à froid, vous devrez peut-être utiliser un autre ensemble de variables d'environnement Airflow dans l'environnement de basculement. Autre exemple : dans un scénario de reprise après sinistre tiède, vous devrez peut-être accorder des autorisations aux utilisateurs dans l'interface utilisateur d'Airflow, afin qu'ils puissent accéder à l'environnement de basculement.

Vous pouvez effectuer ces modifications manuellement ou préparer un script shell avec des commandes qui modifient la configuration de l'environnement de basculement en exécutant des commandes gcloud composer environment update.

Décider de ce que vous souhaitez faire avec l'environnement principal

Certains sinistres peuvent se produire lorsque l'environnement principal est inaccessible, mais reste opérationnel ou ne fonctionne pas correctement. Par exemple, vous ne pouvez pas accéder à l'environnement principal via le réseau en raison d'une défaillance de l'infrastructure. Autre exemple : l'environnement fonctionne avec des erreurs ou avec une capacité réduite, mais certains DAG sont tout de même exécutés.

Si l'environnement d'origine est toujours en cours d'exécution, il peut générer des coûts directement liés à Cloud Composer ou à d'autres services accessibles via les DAG, même si un environnement de remplacement a été créé. Cet environnement peut toujours exécuter certains DAG. Par conséquent, certaines opérations peuvent être exécutées deux fois: dans l'environnement principal toujours en cours d'exécution et dans l'environnement de basculement après le chargement de l'instantané.

Si l'environnement principal existe, mais ne fonctionne pas correctement

L'environnement principal peut être supprimé si toutes les données pertinentes ont été récupérées. Par exemple, vous pouvez récupérer des données qui ne sont pas incluses dans les instantanés d'environnement, telles que la configuration de la mise en réseau ou le contenu du bucket de l'environnement situé en dehors des dossiers /dags et /plugins.

Si l'environnement principal redevient accessible et opérationnel

Si l'environnement principal n'a été inaccessible que temporairement, et qu'il redevient accessible et opérationnel, vous pouvez choisir une méthode:

Continuez à utiliser l'environnement de basculement.
Revenez à l'environnement principal.

Pour continuer à utiliser l'environnement de basculement, procédez comme suit:

Si l'environnement principal exécute toujours les DAG, suspendez-les dès que possible.
Assurez-vous que toutes les données pertinentes ont été récupérées, puis supprimez l'environnement principal.
Répétez les étapes de préparation de reprise après sinistre pour l'environnement de basculement, telles que la configuration d'instantanés programmés.

Pour revenir à l'environnement principal:

Suspendez tous les DAG dans l'environnement de basculement.
Attendez que toutes les exécutions du DAG se terminent dans l'environnement de basculement ou arrêtez-les.
Enregistrez un instantané de l'environnement de basculement.
Chargez cet instantané dans l'environnement principal.
Réactivez les DAG dans l'environnement principal.
Si nécessaire, supprimez l'environnement de basculement.