Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3
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 sinistre est un événement au cours duquel Cloud Composer ou d'autres composants essentielles au fonctionnement de votre environnement sont indisponibles. Cet événement nécessite un basculement vers une autre région et Cloud Composer de l'infrastructure. Une catastrophe peut être naturelle ou humaine, y compris les temps d'arrêt des régions Google Cloud et les interruptions par vous-même de l'infrastructure.
- Dans le contexte de Cloud Composer, la reprise après sinistre est un processus de restauration du fonctionnement de l'environnement après un sinistre. La implique de recréer l'environnement, éventuellement dans une autre région. Pour plus d'informations 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 que vous pour lesquels vous souhaitez activer une fonctionnalité de reprise après sinistre.
- Un environnement de basculement est un environnement Cloud Composer désigné pour reprendre les activités de l'environnement principal.
- Le scénario de reprise après sinistre tiède est une variante de la reprise après sinistre, dans lequel vous utilisez de basculement 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 reprise après sinistre tiède ou à froid, où le l'environnement principal et l'environnement de basculement se trouvent 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 (défectueux ou autrement inaccessible) en raison d'un sinistre.
Cette procédure suppose que votre environnement principal ne va pas être corrigé sur place pour faire face à la catastrophe. À la place, vous créez une seconde clé (basculement) côte à côte. Cet environnement fonctionne au lieu de l'environnement principal environnement. À un stade ultérieur, vous pouvez décider de revenir à l'environnement principal ou de continuer à utiliser l'environnement de basculement.
Comme la procédure utilise un environnement de basculement, des modifications seront apportées lorsque vous passez de l'environnement principal au Pixel. les modifications entre le serveur principal et de l'environnement de basculement (liste non exhaustive):
L'URL du serveur Web sera différente. Cela modifie l'adresse Interface utilisateur d'Airflow et point de terminaison de l'API REST Airflow.
L'URL du bucket de l'environnement sera différente.
Vous devrez peut-être ajuster la configuration des autorisations d'accès et de réseau.
Si vous utilisez le scénario de DR à chaud, vous connaissez à l'avance les valeurs du serveur Web, les adresses de bucket de l'environnement et la configuration réseau.
Avant de commencer
Cloud Composer est compatible avec les instantanés planifiés dans les versions 2.0.32 et ultérieures. Les instantanés d'environnement sont compatibles avec les versions 2.0.9 et ultérieures.
La base de données Airflow doit contenir moins de 20 Go de données pour créer des instantanés.
Pour créer des instantanés, le nombre total d'objets dans les dossiers
/dags
,/plugins
et/data
du bucket de l'environnement doit être inférieur à 100 000.Si vous utilisez le mécanisme XCom pour transférer des fichiers, assurez-vous l'utiliser conformément aux instructions d'Airflow. Transfert de fichiers volumineux ou en grand nombre via XCom les performances de la base de données Airflow et peuvent entraîner des défaillances lors du chargement. ni mettre à niveau votre environnement. Pensez à utiliser des solutions alternatives telles que Cloud Storage pour transférer de grands volumes de données.
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, vous maintenez cet environnement disponible.
- Dans le scénario de reprise après sinistre à froid, vous créez cet environnement uniquement pour tester votre la procédure de reprise après sinistre. Une fois la préparation terminée, supprimer cet environnement et le créer à nouveau après un sinistre.
Créez un bucket pour les instantanés.
Le bucket doit être disponible dans la région DR. Pour la reprise après sinistre interrégionale, le bucket d'instantanés doit être multirégional ou situé dans un est différente de celle de l'environnement principal.
Vérifier que les DAG peuvent accéder aux ressources régionales
Présentation de la reprise après sinistre
Après un sinistre :
- (Reprise après sinistre à froid uniquement) Créez un environnement de basculement.
- Dans la mesure du possible, arrêtez l'exécution des DAG dans l'environnement principal.
- Chargez un instantané à partir du bucket d'instantanés vers l'environnement de basculement.
- Si nécessaire, d'ajuster la configuration de l'environnement de basculement.
- Décidez de la marche à suivre avec l'environnement principal.
Étapes de préparation
Suivez les étapes ci-dessous pour configurer la reprise après sinistre de votre environnement.
Créer un environnement de basculement
Créez un environnement qui sert d'environnement de bascule.
Respectez les consignes suivantes :
Votre environnement principal et votre environnement de basculement doivent utiliser la même version de Cloud Composer et Airflow.
Dans le scénario de reprise après sinistre tiède, veillez à mettre à jour et mettre à niveau les deux environnements simultanément. Par exemple, si vous mettre à niveau l'environnement principal vers un service Cloud Composer ultérieur ou installer des packages PyPI, votre environnement de basculement ces modifications.
Nous vous recommandons de créer l'environnement de basculement dans une région différente de l'environnement principal. Par conséquent, un plus plus large éventail de sinistres potentiels plusieurs scénarios, comme un sinistre qui affecte la disponibilité de toute la région.
Nous vous recommandons d'utiliser Terraform pour créer des environnements principaux et de basculement, afin que les deux aient une configuration cohérente. Vérifiez que Les définitions Terraform pour les environnements principal et de basculement sont synchronisé.
Nous vous recommandons de configurer l'environnement de basculement (taille de l'environnement, nombre de planificateurs et autorisations IAM, par exemple) conformément à 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 (comme 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 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 de l'environnement. N'utilisez pas de buckets d'environnement pour la reprise après sinistre, car la configuration la règle de conservation et le cycle de vie sont appliqués 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éfinies de manière à empêcher la suppression accidentelle ou l'accès non autorisé. Pour en savoir plus sur 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éez un bucket multirégional.
Configurer la maintenance des bases de données
Réduisez la taille de la base de données Airflow et respectez la limite de taille en configurant Nettoyage de la base de données. Cela facilite le processus d'enregistrement et charger les instantanés plus rapidement. La base de données Airflow doit contenir moins de de données pour créer des instantanés.
Configurer des instantanés programmés
Configurez des instantanés programmés pour l'instantané principal environnement.
Les instantanés ne peuvent être créés que dans un environnement sain. Ils doivent donc être enregistrés avant que le sinistre ne se produise.
Pour en savoir plus sur le fonctionnement des instantanés, consultez Enregistrez et chargez 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 des opérations planifiées sur les instantanés
Pour les instantanés programmés à une fréquence d'au moins une fois toutes les 12 heures, vous pouvez utiliser Cloud Monitoring pour être averti lorsqu'un instantané n'est pas créé automatiquement.
Pour les planifications à faible fréquence, vous utilisez la Google Cloud CLI pour vérifier les résultats des opérations d'instantané. Consultez la section Vérifier les opérations d'enregistrement des instantanés.
- Dans Google Cloud Console, accédez à la page Monitoring.
- Dans le volet de navigation Monitoring, sélectionnez notifications 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 Sélectionner une métrique, puis procédez comme suit :
- 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. - Pour le type de ressource, sélectionnez Environnement Cloud Composer.
- Pour Catégorie de métrique, sélectionnez Environnement.
- Dans le champ Métrique, sélectionnez Nombre de créations d'instantanés.
- Sélectionnez Appliquer.
- Pour limiter le menu aux entrées pertinentes, saisissez
-
Cliquez sur Ajouter un filtre, puis utilisez les menus déroulants pour ajouter les filtres suivants:
Filter Comparateur Valeur Étiquette de ressource > environment_name = Nom de l'environnement dans lequel vous souhaitez surveiller les instantanés programmés. Libellé du moniteur > résultat = SUCCEEDED
- Dans la section Transformer les données, définissez les attributs suivants:
<ph type="x-smartling-placeholder">
- </ph>
- Pour Fenêtre glissante, sélectionnez la période de surveillance de cette alerte.
Cette valeur affecte la configuration du seuil à l'étape suivante.
Valeur recommandée pour la surveillance planifiée des instantanés : 1 jour.
- Dans le champ Fenêtrage glissant, sélectionnez delta.
- Pour Fenêtre glissante, sélectionnez la période de surveillance de cette alerte.
Cette valeur affecte la configuration du seuil à l'étape suivante.
- 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 cette page avec les paramètres du tableau suivant.
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 au cours de la période configurée comme 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:Déduire
1
heure dans la formule est de prendre en compte les différentes durées d'exécution des instantanés. Cela permet d'éviter Générer des faux positifs si le dernier instantané est toujours en cours d'exécution lors d'un contrôle de surveillance.Exemple :
Si vous utilisez la période glissante recommandée de 1 jour et que la fréquence de planification est une fois toutes les deux heures, définissez cette valeur sur11
(selon le calcul :24 / 2 - 1 = 11
).Si votre planification fonctionne correctement, vous devez avoir au moins 11 instantanés sur une période de 24 heures. Si ce n'est pas le cas, cela signifie qu'une opération d'instantané n'a pas abouti. et 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.
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. Vous pouvez ainsi résoudre les problèmes potentiels qui pourraient affecter le processus de reprise après sinistre.
Dans le scénario de reprise après sinistre à froid, vous pouvez supprimer l'environnement de basculement après avoir terminer de tester la procédure de reprise après sinistre.
Vérifier les opérations d'enregistrement d'instantanés
Vous pouvez utiliser la Google Cloud CLI pour récupérer la liste des opérations d'enregistrement d'instantané et vérifier si vos instantanés sont prêts pour les 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 souvent, il est préférable de configurer Alertes Cloud Monitoring Consultez la section Configurer la surveillance des opérations d'instantanés planifiées.
gcloud
Répertoriez toutes les opérations d'instantané pour un environnement spécifique. Pour obtenir des informations complètes sur les commandes, consultez 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 de région où se trouve l'environnementPROJECT_ID
par l'identifiant du projet dans lequel se trouve l'environnementENVIRONMENT_ID
avec 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 la procédure ci-dessous pour récupérer votre instance principale environnement.
(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, arrêtez l'exécution des DAG dans l'environnement principal:
- Si l'environnement principal est toujours accessible, mettez tous les DAG en veille.
- Si le bucket de l'environnement principal est accessible, déplacez tous les DAG du bucket de l'environnement ou vers un dossier en dehors de
/dags
dans le bucket de l'environnement principal.
Charger un instantané dans l'environnement de basculement
Chargez un instantané de l'environnement principal dans 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 ont peut-être déjà été exécutées par l'environnement principal. L'environnement de basculement ne comporte aucune signifie 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 (dans les deux l'environnement principal et l'environnement de basculement). Nous vous recommandons que toutes les tâches soient idempotentes et que les instantanés planifiés soient créés toutes les deux heures.
(Si nécessaire) Ajustez la configuration de l'environnement de basculement.
Dans certains cas, vous pouvez modifier la configuration du basculement après 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 ensemble différent Variables d'environnement Airflow dans l'environnement de basculement. Autre exemple : Dans un scénario de reprise après sinistre annoncée, vous devrez peut-être accorder des autorisations aux utilisateurs 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
qui modifient la configuration de l'environnement de basculement en exécutant
gcloud composer environment update
.
Déterminer ce que vous souhaitez faire de l'environnement principal
Certains sinistres peuvent se produire parce que l'environnement principal n'est pas accessible, mais qu'il est toujours opérationnel ou qu'il ne fonctionne pas correctement. Par exemple, vous ne pouvez pas à l'environnement principal via le réseau en raison d'une infrastructure l'échec. Autre exemple : l'environnement fonctionne avec des erreurs ou avec 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, générer des coûts directement liés à Cloud Composer ou à d'autres services ; accessibles par le biais des DAG, même si un environnement a été créé le remplacement. Cet environnement peut toujours exécuter certains DAG, Par conséquent, certaines peuvent être exécutées deux fois: dans l'environnement principal 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. Pour
exemple, vous voudrez
peut-être récupérer
les données non incluses dans les instantanés d'environnement,
comme la configuration réseau ou le contenu
bucket en dehors des dossiers /dags
et /plugins
.
Si l'environnement principal redevient accessible et opérationnel
Si l'environnement principal n'était inaccessible que temporairement et qu'il redevient accessible et opérationnel, vous pouvez choisir l'une des approches suivantes :
- Continuez à utiliser l'environnement de basculement.
- Revenez à l'environnement principal.
Pour continuer à utiliser l'environnement de basculement:
- Si l'environnement principal exécute toujours des DAG, mettez-les en veille dès que possible.
- Assurez-vous que toutes les données pertinentes sont récupérées, puis supprimez l'environnement principal.
- Répétez les étapes de préparation de la DR pour l'environnement de basculement, par exemple en configurant des instantanés planifiés.
Pour revenir à l'environnement principal:
- Suspendez tous les DAG dans l'environnement de basculement.
- Attendez que toutes les exécutions de DAG soient terminées 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.