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 Managed Airflow ou d'autres composants essentiels au fonctionnement de votre environnement sont indisponibles. Cet événement nécessite un basculement vers une autre région et des environnements Managed Airflow. Un sinistre peut être d'origine naturelle ou humaine, y compris une interruption de service dans les Cloud de Confiance by S3NS régions et des pannes dans votre propre infrastructure.
- La reprise après sinistre (DR), dans le contexte de Managed Airflow, 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 le guide de planification de la reprise après sinistre.
- Un environnement principal est un environnement Managed Airflow pour lequel vous souhaitez activer une fonctionnalité de reprise après sinistre.
- Un environnement de basculement est un environnement Managed Airflow désigné pour prendre le relais des activités de l'environnement principal.
- Un 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.
- Un 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 qu'un sinistre s'est produit.
- La reprise après sinistre interrégionale est une variante de la reprise après sinistre à chaud ou à froid dans laquelle 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 (endommagé ou inaccessible) en raison d'un sinistre.
Cette procédure suppose que votre environnement principal ne sera pas réparé sur place pour faire face au sinistre. Au lieu de cela, vous créez un deuxième environnement (de basculement) côte à côte. Cet environnement fonctionne à la place de l'environnement principal. Vous pourrez ensuite 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 seront introduites lorsque vous passerez de l'environnement principal. Les modifications entre l'environnement principal et l'environnement de basculement incluent (liste non exhaustive) :
L'URL du serveur Web sera différente. Cela modifie l'adresse de l'interface utilisateur d'Airflow et le 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 du réseau peut nécessiter un ajustement.
Si vous utilisez le scénario de reprise après sinistre à chaud, vous connaissez à l'avance les valeurs du serveur Web, les adresses du bucket de l'environnement et la configuration réseau.
Avant de commencer
La base de données Airflow doit contenir moins de 20 Go de données pour créer des instantanés.
Le nombre total d'objets dans les dossiers
/dags,/pluginset/datadu bucket de l'environnement doit être inférieur à 100 000 pour créer des instantanés.Si vous utilisez le mécanisme XCom pour transférer des fichiers, assurez-vous de l' utiliser conformément aux consignes d'Airflow. Le transfert de fichiers volumineux ou d'un grand nombre de fichiers à l'aide de XCom a un impact sur les performances de la base de données Airflow et peut entraîner des échecs lors du chargement d'instantanés ou de la mise à niveau de votre environnement. Envisagez d'utiliser des 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 à chaud, vous maintenez cet environnement disponible.
- Dans le scénario de reprise après sinistre à froid, vous ne créez cet environnement que pour tester votre procédure de reprise après sinistre. Une fois la préparation terminée, vous supprimez cet environnement et le recréez 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 situé dans une région différente de celle de l'environnement principal.
Vérifiez 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.
- Si possible, empêchez l'environnement principal d'exécuter des DAG.
- Chargez un instantané du bucket d'instantanés dans l'environnement de basculement.
- Si nécessaire, ajustez la configuration de l'environnement de basculement.
- Décidez de ce que vous allez faire avec l'environnement principal.
Étapes de préparation
Suivez les étapes ci-dessous pour configurer la reprise après sinistre pour votre environnement.
Créer un environnement de basculement
Créez un environnement qui fait office d'environnement de basculement.
Respectez les consignes suivantes :
-
Votre environnement principal et votre environnement de basculement doivent utiliser la même version et le même build d'Airflow.
Dans le scénario de reprise après sinistre à chaud, assurez-vous de mettre à jour et mettre à niveau les deux environnements de manière synchronisée. Par exemple, si vous mettez à niveau l'environnement principal vers un build Airflow ultérieur, 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 celle de l'environnement principal. Par conséquent, 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, afin que les deux aient une configuration cohérente. Assurez-vous que les définitions Terraform pour les environnements principal et de basculement sont synchronisées.
Il est recommandé que la configuration de l'environnement de basculement (telle que la taille de l'environnement, le nombre de planificateurs et les autorisations IAM) soit conforme à la configuration de l'environnement principal. Les autorisations IAM pour les deux environnements doivent accorder un 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 de l'environnement, la configuration réseau ou le projet). 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 de 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éfinies de manière à empêcher toute suppression accidentelle ou tout 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éer un bucket dans une autre région ;
- créer un bucket multirégional.
Configurer la maintenance de la base de données
Maintenez la base de données Airflow petite et dans la limite de taille en configurant le nettoyage de la base de données. Cela accélère le processus d'enregistrement et de chargement des instantanés. La base de données Airflow doit contenir moins de 20 Go de données pour créer des 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 le sinistre.
Pour en savoir plus sur le fonctionnement des instantanés, consultez la page 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 des opérations d'instantanés programmés
Pour les instantanés programmés avec une fréquence d'au moins une fois toutes les 12 heures, vous pouvez utiliser Cloud Monitoring pour vous alerter lorsqu'un instantané n'est pas créé automatiquement.
Pour les programmations à fréquence plus faible, utilisez Google Cloud CLI pour vérifier les résultats des opérations d'instantanés. Consultez la page Vérifier les opérations d'enregistrement d'instantanés.
- Dans la Cloud de Confiance 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 Snapshotdans la barre de filtre. Si aucun résultat ne s'affiche après avoir filtré le menu, désactivez l'option Afficher uniquement les ressources et métriques actives. - Pour le Type de ressource, sélectionnez Environnement Cloud Composer.
- Pour la Catégorie de métriques, sélectionnez Environnement.
- Pour la 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 :
Filtre Comparateur Valeur Libellé de ressource > environment_name = Nom de l'environnement dans lequel vous souhaitez surveiller les instantanés programmés. Libellé de surveillance > résultat = SUCCEEDED - Dans la section Transformer les données, définissez les attributs suivants :
- Pour Fenêtrage glissant, sélectionnez la fenêtre de surveillance de cette alerte.
Cette valeur a un impact sur la configuration du seuil à l'étape suivante.
Valeur recommandée pour la surveillance des instantanés programmés : 1 jour.
- Pour Fonction de fenêtrage glissant, sélectionnez delta.
- Pour Fenêtrage glissant, sélectionnez la fenêtre de surveillance de cette alerte.
Cette valeur a un impact sur 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 typeThresholdAlert triggerAny time series violatesThreshold positionBelow thresholdThreshold valueNombre d'instantanés programmés que vous prévoyez d'enregistrer dans le délai configuré comme Fenêtrage glissant pour l'alerte. Calculez cette valeur à l'aide de la formule suivante :
(rolling window in hours / schedule frequency in hours) - 1Remarque : La déduction d'
1une heure dans la formule permet de tenir compte des temps d'achèvement variables des instantanés. Cela permet d'éviter de générer des 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 fenêtre glissante recommandée de 1 jour, et que la fréquence de votre programmation est d'une fois toutes les deux heures, définissez cette valeur sur11(conformément au calcul :24 / 2 - 1 = 11).Si votre programmation s'exécute correctement, vous devriez avoir au moins 11 instantanés dans n'importe quelle fenêtre de 24 heures. Si ce n'est pas le cas, cela signifie qu'une opération d'instantané n'a pas abouti et que Cloud Monitoring déclenche cette alerte.
Condition nameNom 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
Assurez-vous de 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 un impact sur le processus de reprise après sinistre réel.
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 save snapshot (enregistrer l'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 souvent qu'au moins 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 la page Configurer la surveillance des opérations d'instantanés programmés.
gcloud
Répertoriez toutes vos opérations d'instantanés pour un environnement spécifique.
Pour obtenir la documentation de référence complète sur la commande, 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 :
LOCATIONSpar la liste des identifiants de région où se trouve l'environnement ;PROJECT_IDpar l'identifiant du projet dans lequel se trouve l'environnement ;ENVIRONMENT_IDpar l'identifiant de l'environnement dans lequel vous souhaitez vérifier les opérations d'instantanés.
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 une catastrophe
Suivez les étapes ci-dessous après un sinistre 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 des DAG
Si possible, empêchez l'environnement principal d'exécuter des 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 du bucket de l'environnement ou vers un dossier en dehors de
/dagsdans 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é. Toutefois, certaines de ces tâches ont peut-être déjà é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 (dans l'environnement principal et dans l'environnement de basculement). Nous vous recommandons que toutes les tâches soient idempotentes et que les instantanés programmé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 ensemble différent de variables d'environnement Airflow dans l'environnement de basculement. Autre exemple : dans un scénario de reprise après sinistre à chaud, 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
gcloud composer environment update commandes.
Décider de ce que vous allez faire avec 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 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 toujours 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 à Managed Airflow ou à d'autres services auxquels vous accédez via les DAG, même si un nouvel environnement a été créé en remplacement. 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 qui est 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 réseau ou le contenu du
bucket de l'environnement en dehors des dossiers /dags et /plugins.
Si l'environnement principal redevient accessible et sain
Si l'environnement principal n'était inaccessible que temporairement et redevient accessible et sain, vous pouvez choisir une approche :
- Continuer à utiliser l'environnement de basculement.
- Revenir à l'environnement principal.
Pour continuer à utiliser l'environnement de basculement :
- Si l'environnement principal exécute toujours des DAG, suspendez-les 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 reprise après sinistre pour l'environnement de basculement, par exemple en configurant des instantanés programmé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.