Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Réplication d'applications entre les systèmes back-end avec la technologie SnapMirror

Contributeurs
PDF

Avec Astra Control, vous pouvez assurer la continuité de l'activité de vos applications avec un objectif de point de récupération (RPO) et un objectif de délai de restauration (RTO) faible grâce aux fonctionnalités de réplication asynchrone de la technologie NetApp SnapMirror. Une fois configuré, vos applications peuvent répliquer les modifications des données et des applications d'un système back-end de stockage vers un autre, sur le même cluster ou entre différents clusters.

Pour une comparaison entre les sauvegardes/restaurations et la réplication, reportez-vous à la section "Concepts de protection des données".

Vous pouvez répliquer des applications dans différents scénarios, comme : uniquement sur site, environnements hybrides et multicloud :

  • Du site A sur site au site A sur site

  • Du site A au site B sur site

  • Du site au cloud avec Cloud Volumes ONTAP

  • Cloud avec Cloud Volumes ONTAP vers une infrastructure sur site

  • Cloud avec Cloud Volumes ONTAP vers le cloud (entre différentes régions du même fournisseur cloud ou vers des fournisseurs de cloud différents)

Astra Control peut répliquer les applications entre les clusters sur site, le stockage sur site vers le cloud (avec Cloud Volumes ONTAP) ou entre les clouds (Cloud Volumes ONTAP vers Cloud Volumes ONTAP).

Remarque Vous pouvez répliquer simultanément une autre application dans la direction opposée. Par exemple, les applications A, B, C peuvent être répliquées depuis Datacenter 1 vers Datacenter 2. Et les applications X, y, Z peuvent être répliquées depuis Datacenter 2 vers Datacenter 1.

Avec Astra Control, vous pouvez effectuer les tâches suivantes relatives aux applications de réplication :

Conditions préalables à la réplication

Avant de commencer, vous devez remplir les conditions préalables suivantes :

  • Clusters ONTAP :

    • Astra Trident : Astra Trident version 22.10 ou ultérieure doit exister sur les clusters Kubernetes source et de destination qui utilisent ONTAP en tant que back-end.

    • Licences : les licences asynchrones de SnapMirror ONTAP utilisant le bundle protection des données doivent être activées sur les clusters ONTAP source et cible. Reportez-vous à la section "Présentation des licences SnapMirror dans ONTAP" pour en savoir plus.

  • Peering :

    • Cluster et SVM : les systèmes back-end de stockage ONTAP doivent être peering. Reportez-vous à la section "Présentation du cluster et de SVM peering" pour en savoir plus.

      Important S'assurer que les noms de SVM utilisés dans la relation de réplication entre deux clusters ONTAP sont uniques.

    • Astra Trident et SVM : les SVM distants à peering doivent être disponibles pour Astra Trident sur le cluster destination.

  • Astra Control Center :

    Astuce "Déployez Astra Control Center" dans un troisième domaine de panne ou un site secondaire pour une reprise après incident transparente.

    • Clusters gérés : les clusters suivants doivent être ajoutés et gérés par Astra Control, idéalement sur différents sites ou domaines de défaillance :

      • Cluster Kubernetes source

      • Cluster Kubernetes de destination

      • Clusters ONTAP associés

    • Comptes d'utilisateur : lorsque vous ajoutez un back-end de stockage ONTAP à Astra Control Center, appliquez les informations d'identification de l'utilisateur avec le rôle « admin ». Ce rôle a des méthodes d'accès http et ontapi Activation sur les clusters ONTAP source et de destination Reportez-vous à la section "Gérer les comptes utilisateur dans la documentation ONTAP" pour en savoir plus.

  • Configuration d'Astra Trident / ONTAP : Astra Control Center exige que vous configuriez au moins un back-end de stockage qui prend en charge la réplication pour les clusters source et de destination. Si les clusters source et cible sont identiques, l'application de destination doit utiliser un back-end de stockage différent de l'application source pour une résilience optimale.

Important La réplication Astra Control prend en charge les applications qui utilisent une seule classe de stockage. Lorsque vous ajoutez une application à un espace de noms, assurez-vous que cette application possède la même classe de stockage que les autres applications de l'espace de noms. Lorsque vous ajoutez une demande de volume persistant à une application répliquée, assurez-vous que la nouvelle demande de volume persistant possède la même classe de stockage que les autres demandes de volume persistant dans l'espace de noms.

Configuration d'une relation de réplication

La configuration d'une relation de réplication implique les éléments suivants :

  • Choix de la fréquence à laquelle vous souhaitez qu'Astra Control prenne une copie Snapshot d'application (qui inclut les ressources Kubernetes de l'application et les copies Snapshot de volume pour chacun des volumes de l'application)

  • Choix de la planification de réplication (ressources Kubernetes incluses ainsi que données de volume persistant)

  • Définition de la durée de prise de l'instantané

Étapes

  1. Dans le menu de navigation gauche Astra Control, sélectionnez applications.

  2. Sélectionnez l'onglet protection des données > réplication.

  3. Sélectionnez configurer la stratégie de réplication. Ou, dans la zone protection des applications, sélectionnez l'option actions et sélectionnez configurer la stratégie de réplication.

  4. Entrez ou sélectionnez les informations suivantes :

    • Cluster de destination : entrez un cluster de destination (il peut être identique au cluster source).

    • Classe de stockage de destination : sélectionnez ou entrez la classe de stockage qui utilise le SVM peering sur le cluster ONTAP de destination. Dans le cadre de la meilleure pratique, la classe de stockage de destination doit pointer vers un système back-end de stockage différent de la classe de stockage source.

    • Type de réplication : Asynchronous est actuellement le seul type de réplication disponible.

    • Espace de noms de destination : saisissez des espaces de noms de destination nouveaux ou existants pour le cluster de destination.

    • (Facultatif) Ajouter des espaces de noms supplémentaires en sélectionnant Ajouter espace de noms et en choisissant l'espace de noms dans la liste déroulante.

    • Fréquence de réplication : définissez la fréquence à laquelle vous souhaitez qu'Astra Control prenne un snapshot et le réplique vers la destination.

    • Offset : définit le nombre de minutes à partir du haut de l'heure où vous souhaitez qu'Astra Control prenne un instantané. Vous pouvez utiliser un décalage afin qu'il ne coïncide pas avec d'autres opérations planifiées.

      Astuce Décaler les plannings de sauvegarde et de réplication pour éviter les chevauchements de planification. Par exemple, effectuez des sauvegardes en haut de l'heure toutes les heures et planifiez la réplication pour qu'elle commence avec un décalage de 5 minutes et un intervalle de 10 minutes.

  5. Sélectionnez Suivant, examinez le résumé et sélectionnez Enregistrer.

    Remarque Au début, l'état affiche « APP-mirror » avant que le premier programme ne se produise.

    ASTRA Control crée un snapshot d'application utilisé pour la réplication.

  6. Pour afficher l'état de l'instantané de l'application, sélectionnez l'onglet applications > instantanés.

    Le nom du snapshot utilise le format de replication-schedule-<string>. ASTRA Control conserve le dernier snapshot utilisé pour la réplication. Les anciens snapshots de réplication sont supprimés après la fin de la réplication.

Résultat

Cela crée la relation de réplication.

Astra Control effectue les actions suivantes à la suite de l'établissement de la relation :

  • Crée un espace de noms sur la destination (s'il n'existe pas)

  • Crée une demande de volume persistant sur l'espace de noms de destination correspondant aux demandes de volume virtuel de l'application source.

  • Effectue un snapshot initial cohérent avec les applications.

  • Établit la relation SnapMirror pour les volumes persistants utilisant le snapshot initial.

La page Data protection affiche l'état et l'état de la relation de réplication :
<Health status> | <Relationship life cycle state>

Par exemple :
Normal | établi

Pour en savoir plus sur l'état et l'état de la réplication, consultez cette rubrique.

Mettre une application répliquée en ligne sur le cluster de destination (basculement)

Avec Astra Control, vous pouvez basculer les applications répliquées vers un cluster de destination. Cette procédure arrête la relation de réplication et met l'application en ligne sur le cluster de destination. Cette procédure n'arrête pas l'application sur le cluster source s'il était opérationnel.

Étapes

  1. Dans le menu de navigation gauche Astra Control, sélectionnez applications.

  2. Sélectionnez l'onglet protection des données > réplication.

  3. Dans le menu actions, sélectionnez basculement.

  4. Dans la page basculement, consultez les informations et sélectionnez basculer.

Résultat

La procédure de basculement entraîne les actions suivantes :

  • L'application de destination démarre sur la base du dernier snapshot répliqué.

  • Le cluster source et l'app (si opérationnel) ne sont pas arrêtés et continuent à fonctionner.

  • L'état de réplication passe à « basculement » puis à « basculement » une fois terminé.

  • La règle de protection de l'application source est copiée vers l'application de destination en fonction des plannings présents sur l'application source au moment du basculement.

  • Si un ou plusieurs crochets d'exécution post-restauration sont activés dans l'application source, ces crochets d'exécution sont exécutés pour l'application de destination.

  • Astra Control affiche l'application sur les clusters source et de destination et son état de santé respectif.

Resynchroniser un basculement de réplication impossible

L'opération de resynchronisation rétablit la relation de réplication. Vous pouvez choisir la source de la relation pour conserver les données sur le cluster source ou destination. Cette opération rétablit les relations SnapMirror pour démarrer la réplication du volume dans le sens de votre choix.

Le processus arrête l'application sur le nouveau cluster de destination avant de rétablir la réplication.

Remarque Pendant le processus de resynchronisation, l'état du cycle de vie apparaît comme « établissement ».
Étapes

  1. Dans le menu de navigation gauche Astra Control, sélectionnez applications.

  2. Sélectionnez l'onglet protection des données > réplication.

  3. Dans le menu actions, sélectionnez Resync.

  4. Dans la page Resync, sélectionnez l'instance d'application source ou de destination contenant les données que vous souhaitez conserver.

    Avertissement Choisissez soigneusement la source de resynchronisation, car les données de la destination sont écrasées.

  5. Sélectionnez Resync pour continuer.

  6. Tapez « resynchroniser » pour confirmer.

  7. Sélectionnez Oui, resynchronisation pour terminer.

Résultat

  • La page réplication affiche « établissement » comme état de réplication.

  • Astra Control arrête l'application sur le nouveau cluster de destination.

  • Astra Control rétablit le processus de réplication du volume persistant dans la direction sélectionnée à l'aide de la resynchronisation de SnapMirror.

  • La page réplication affiche la relation mise à jour.

Réplication inverse des applications

Il s'agit de l'opération planifiée pour déplacer l'application vers le back-end de stockage de destination tout en continuant à répliquer vers le back-end de stockage source d'origine. ASTRA Control arrête l'application source et réplique les données vers la destination avant de basculer vers l'application de destination.

Dans ce cas, vous permutez la source et la destination.

Étapes

  1. Dans le menu de navigation gauche Astra Control, sélectionnez applications.

  2. Sélectionnez l'onglet protection des données > réplication.

  3. Dans le menu actions, sélectionnez réplication inversée.

  4. Dans la page réplication inverse, vérifiez les informations et sélectionnez réplication inverse pour continuer.

Résultat

Les actions suivantes se produisent suite à la réplication inverse :

  • Une copie Snapshot des ressources Kubernetes de l'application source d'origine est effectuée.

  • Les pods de l'application source d'origine sont « interrompus » en supprimant les ressources Kubernetes de l'application (laissant les demandes de volume persistant et les volumes persistants en place).

  • Une fois les pods arrêtés, des copies Snapshot des volumes de l'application sont prises et répliquées.

  • Les relations SnapMirror sont rompues, les volumes de destination étant prêts pour la lecture/l'écriture.

  • Les ressources Kubernetes de l'application sont restaurées à partir du snapshot de pré-arrêt, à l'aide des données du volume répliquées après la fermeture de l'application source d'origine.

  • La réplication est rétablie dans la direction inverse.

Rétablir le fonctionnement des applications sur le cluster source d'origine

Avec Astra Control, vous pouvez obtenir le « retour arrière » après une opération de basculement à l'aide de la séquence d'opérations suivante. Dans ce flux de travail pour restaurer le sens de réplication d'origine, Astra Control réplique (resyncs) toute modification d'application vers l'application source d'origine avant d'inverser le sens de réplication.

Ce processus commence à partir d'une relation qui a effectué un basculement vers une destination et implique les étapes suivantes :

  • Commencer par un état de basculement défaillant.

  • Resynchroniser la relation.

  • Inverser la réplication.

Étapes

  1. Dans le menu de navigation gauche Astra Control, sélectionnez applications.

  2. Sélectionnez l'onglet protection des données > réplication.

  3. Dans le menu actions, sélectionnez Resync.

  4. Pour une opération de retour arrière, choisissez l'application de basculement comme source de l'opération de resynchronisation (conservation des données écrites après basculement).

  5. Tapez « resynchroniser » pour confirmer.

  6. Sélectionnez Oui, resynchronisation pour terminer.

  7. Une fois la resynchronisation terminée, dans l'onglet protection des données > réplication, dans le menu actions, sélectionnez réplication inverse.

  8. Dans la page réplication inverse, vérifiez les informations et sélectionnez réplication inverse.

Résultat

Cette action associe les résultats des opérations de resynchronisation et de « relation inversée » pour que l'application soit en ligne sur le cluster source d'origine et que la réplication reprend au cluster de destination d'origine.

Supprime une relation de réplication d'application

La suppression de la relation se traduit par deux applications distinctes sans relation entre elles.

Étapes

  1. Dans le menu de navigation gauche Astra Control, sélectionnez applications.

  2. Sélectionnez l'onglet protection des données > réplication.

  3. Dans la zone protection des applications ou dans le diagramme des relations, sélectionnez Supprimer la relation de réplication.

Résultat

Les actions suivantes se produisent suite à la suppression d'une relation de réplication :

  • Si la relation est établie mais que l'application n'a pas encore été mise en ligne sur le cluster de destination (échec), Astra Control conserve les demandes de volume persistant créées lors de l'initialisation, laisse une application gérée « vide » sur le cluster de destination et conserve l'application de destination pour conserver les sauvegardes qui pourraient avoir été créées.

  • Si l'application a été mise en ligne sur le cluster de destination (avec échec), Astra Control conserve les demandes de volume persistant et les applications de destination. Les applications source et de destination sont désormais traitées comme des applications indépendantes. Les planifications de sauvegarde restent sur les deux applications mais ne sont pas associées les unes aux autres. 

État de santé des relations de réplication et état du cycle de vie des relations

Astra Control affiche l'état de santé de la relation et les États du cycle de vie de la relation de réplication.

États d'intégrité des relations de réplication

Les États suivants indiquent l'état de santé de la relation de réplication :

  • Normal : la relation est soit établie, soit établie, et le snapshot le plus récent a été transféré avec succès.

  • Avertissement : la relation est soit basculée, soit a échoué (et donc ne protège plus l'app source).

  • Critique

    • La relation est établie ou a échoué et la dernière tentative de réconciliation a échoué.

    • La relation est établie, et la dernière tentative de concilier l'ajout d'un nouveau PVC est un échec.

    • La relation est établie (un snapshot a donc été répliqué avec succès et un basculement est possible), mais le snapshot le plus récent a échoué ou n'a pas pu être répliqué.

États du cycle de vie de la réplication

Les États suivants reflètent les différentes étapes du cycle de vie de la réplication :

  • Établissement: Une nouvelle relation de réplication est en cours de création. Astra Control crée un espace de noms si nécessaire, crée des demandes de volume persistant sur les nouveaux volumes du cluster de destination et crée des relations SnapMirror. Cet état peut également indiquer que la réplication est resynchronyée ou inversée.

  • Créé : il existe une relation de réplication. ASTRA Control vérifie régulièrement que les ESV sont disponibles, vérifie la relation de réplication, crée régulièrement des instantanés de l'application et identifie les nouvelles ESV source dans l'application. Si c'est le cas, Astra Control crée les ressources qui les incluent dans la réplication.

  • Basculement : Astra Control rompt les relations SnapMirror et restaure les ressources Kubernetes de l'application à partir du dernier snapshot d'application répliqué avec succès.

  • Basculement : Astra Control arrête la réplication à partir du cluster source, utilise le snapshot d'application répliqué le plus récent (avec succès) sur la destination et restaure les ressources Kubernetes.

  • Resynchronisation : le contrôle Astra resynchronque les nouvelles données de la source de resynchronisation vers la destination de resynchronisation à l'aide de la resynchronisation SnapMirror. Cette opération peut écraser certaines données de la destination en fonction de la direction de la synchronisation. Astra Control arrête l'application exécutée sur l'espace de noms de destination et supprime l'application Kubernetes. Pendant le processus de resynchronisation, l'état indique « établissement ».

  • Reversing : l' est l'opération planifiée pour déplacer l'application vers le cluster de destination tout en continuant à effectuer la réplication vers le cluster source d'origine. Astra Control arrête l'application du cluster source. Il réplique les données vers la destination avant de basculer l'application vers le cluster de destination. Pendant la réplication inverse, l'état indique « établissement ».

  • Suppression :

    • Si la relation de réplication a été établie mais n'a pas encore été rétablie, Astra Control supprime les demandes de volume persistant qui ont été créées pendant la réplication et supprime l'application gérée de destination.

    • Si la réplication a déjà échoué, Astra Control conserve les ESV et l'application de destination.