Remarques :

Ce tutoriel nécessite un accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, reportez-vous à Introduction au niveau gratuit d'Oracle Cloud Infrastructure.
Il utilise des exemples de valeurs pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. Lorsque vous terminez votre atelier, remplacez ces valeurs par celles propres à votre environnement cloud.

Automatiser la récupération après sinistre à froid pour Oracle HeatWave MySQL à l'aide d'OCI Full Stack Disaster Recovery

Introduction

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestre la transition du calcul, de la base de données et des applications entre les régions OCI du monde entier en un seul clic. Les clients peuvent automatiser les étapes nécessaires à la récupération d'un ou de plusieurs systèmes métier sans repenser ou modifier l'architecture de l'infrastructure, des bases de données ou des applications existantes, et sans avoir besoin de serveurs de gestion ou de conversion spécialisés.

Oracle HeatWave MySQL est un service de base de données entièrement géré déployé dans Oracle Cloud Infrastructure (OCI) qui prend en charge les opérateurs et les développeurs souhaitant déployer rapidement des applications sécurisées natives du cloud. Oracle HeatWave MySQL est la seule offre MySQL qui inclut la possibilité d'utiliser HeatWave, un accélérateur de requêtes en mémoire intégré et hautes performances. HeatWave permet aux clients d'exécuter des analyses sophistiquées directement sur leur base de données MySQL opérationnelle, éliminant ainsi la nécessité d'une migration et d'une intégration de données complexes, chronophages et coûteuses avec une base de données d'analyse distincte. HeatWave accélère considérablement les performances MySQL pour les analyses et les charges de travail mixtes. HeatWave est entièrement optimisé pour OCI et Oracle HeatWave MySQL est 100 % conçu, géré et pris en charge par les équipes d'ingénierie OCI et MySQL.

Dans ce tutoriel, vous allez apprendre à automatiser une récupération après sinistre à froid pour Oracle HeatWave MySQL dans OCI. Il décrit les procédures d'utilisation du service OCI Full Stack DR pour gérer les processus de permutation et de basculement.

Remarque : ce type de stratégie de récupération après sinistre s'appuie sur un mécanisme de sauvegarde et de restauration, ce qui le rend plus adapté aux applications non critiques lorsque les exigences métier relatives aux objectifs de délai de récupération (RTO) et aux objectifs de point de récupération (RPO) ne sont pas trop exigeantes.

Description de l'architecture

L'architecture présentée dans ce tutoriel présente une application WordPress exécutée sur des machines virtuelles OCI intégrées de manière transparente à Oracle HeatWave MySQL. En outre, la configuration tire parti du service OCI File Storage en tant que partage NFS (Network File System) pour stocker le contenu WordPress. Ce stockage partagé est monté sur chaque machine virtuelle, garantissant un accès immédiat et synchronisé à tout nouveau contenu dans l'environnement.

Un équilibreur de charge OCI est déployé dans un sous-réseau public pour gérer efficacement les connexions utilisateur externes, en répartissant le trafic entrant entre les machines virtuelles WordPress.

Description de l'architecture de récupération après sinistre

La stratégie de récupération après sinistre pour les machines virtuelles d'application WordPress implique une approche complète, notamment la réplication complète de chaque volume d'initialisation de machine virtuelle avec réplication de groupe de volumes et l'utilisation de la réplication File Storage pour assurer la synchronisation du contenu WordPress.

Un équilibreur de charge est pré-provisionné dans la région distante, ce qui garantit qu'il est prêt à gérer le trafic de manière transparente lorsque les machines virtuelles WordPress sont transférées vers la région distante lors d'un scénario de permutation ou de basculement.

Pour Oracle HeatWave MySQL, les sauvegardes sont copiées régulièrement dans la région distante afin de garantir la protection des données et la préparation à la récupération après sinistre. Ce processus peut être lancé à partir d'une machine virtuelle d'application à l'aide d'un script personnalisé, qui peut être planifié via crontab pour une exécution automatisée et cohérente.

Le diagramme suivant illustre le workflow de copie de la dernière sauvegarde MySQL disponible de la région principale vers la région distante.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

La configuration crontab suivante a été configurée sous l'utilisateur opc sur l'application WordPress VM1 pour exécuter le script mds_copy_bkp.py toutes les 4 heures. Cela garantit la synchronisation automatique des sauvegardes vers la région de secours, contribuant ainsi à une meilleure récupération après sinistre :

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

Ce travail exécute le script à la minute 15 au-delà de toutes les 4e heures.

Tous les scripts sont disponibles sur GitHub et sont détaillés dans les sections suivantes.

Remarque : veillez à programmer ce script (ou un script similaire) en fonction des besoins de votre entreprise pour copier régulièrement la sauvegarde MySQL vers la région distante. Sans cette étape, le processus de restauration peut échouer car la sauvegarde n'est pas disponible dans la région secondaire.

Fonctionnement de la récupération

Une fois qu'une permutation planifiée est exécutée, les rôles sont inversés : la charge globale principale est exécutée dans la région 2, tandis que la base de données de secours est exécutée dans la région 1. L'architecture se présente comme suit :

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

Dans la configuration actuelle, nous utilisons le service DNS privé OCI pour gérer un enregistrement DNS qui dirige le trafic vers l'adresse Oracle HeatWave MySQL active. Au cours du processus de récupération, cet enregistrement DNS est mis à jour au moyen d'un script personnalisé afin de refléter le nouveau Oracle HeatWave MySQL, garantissant ainsi un basculement fluide et une continuité de service.

Le diagramme suivant illustre le workflow de restauration de la sauvegarde MySQL la plus récente dans la région de secours.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

La solution de récupération pour ce déploiement nécessite qu'OCI Full Stack DR exécute une série de scripts Python personnalisés lors d'une opération de récupération, telle qu'un basculement ou une permutation. Les scripts référencés dans ce tutoriel sont fournis par l'équipe de spécialistes de l'architecture cloud EMEA et disponibles ici : full-stack-disaster-recovery, qui est spécifiquement adapté à cette solution de récupération après sinistre.

Ce tutoriel explique comment télécharger les scripts et comment les utiliser dans une tâche ultérieure.

Remarque : les scripts suivants sont fournis à des fins génériques. Vous pouvez utiliser vos propres scripts ou les personnaliser en fonction des exigences de votre stratégie d'entreprise et de sécurité.

Définitions et hypothèses dans tout le tutoriel

Régions:
- La région 1 est Dubaï : Dubaï servira initialement de région principale. Cependant, ce rôle passera en mode de secours pendant le processus de permutation, qui sera effectué dans les tâches ultérieures dans le cadre du plan de récupération après sinistre.
- La région 2 est Abu Dhabi : Abu Dhabi fonctionnera initialement en tant que région de secours. Ce rôle passera ensuite au rôle principal après le processus de permutation, qui sera effectué dans les tâches suivantes dans le cadre de la procédure de récupération après sinistre.
Compartiments : vous êtes libre d'organiser ce déploiement et OCI Full Stack DR dans n'importe quel modèle de compartiment qui fonctionne dans les normes de gouvernance informatique. Nous avons choisi d'organiser toutes les ressources OCI pour ce tutoriel dans un seul compartiment.

WordPress Machines virtuelles d'application et stockage de fichiers OCI

L'architecture utilisée dans ce tutoriel est conçue autour d'OCI File Storage pour garantir que toutes les machines virtuelles d'application ont un accès partagé au même contenu WordPress.

Pour plus d'informations sur le montage correct du système de fichiers sur les instances Linux, reportez-vous à Configuration du montage automatique d'un système de fichiers (instances Linux).

Voici un exemple de configuration de fichier /etc/fstab pour le montage du système de fichiers sur la machine virtuelle d'application WordPress.

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

Remplacez xxx.xxx.xxx.xxx par l'adresse IP de la cible de montage située dans la région 1 pour garantir une connectivité correcte.

Objectifs

Les tâches suivantes seront décrites dans ce tutoriel :

Tâche 1 : préparer l'environnement pour la récupération après sinistre
Tâche 2 : création de groupes de protection de récupération après sinistre dans les deux régions
Tâche 3 : ajout de membres au groupe de protection de récupération après sinistre
Tâche 4 : créer des plans de récupération après sinistre de base dans la région 2
Tâche 5 : personnaliser le plan de permutation de rôles dans la région 2
Tâche 6 : personnalisation du plan de basculement dans la région 2
Tâche 7 : exécuter les prévérifications des plans de récupération après sinistre dans la région 2
Tâche 8 : exécuter le plan de permutation dans la région 2
Tâche 9 : créer et personnaliser les plans de récupération après sinistre dans la région 1

Tâche 1 : préparer l'environnement pour la récupération après sinistre

Tâche 1.1 : création de groupes de volumes et activation de la réplication

Créez un groupe de volumes pour les machines virtuelles d'application WordPress dans la région 1 et assurez-vous qu'il est répliqué dans la région 2. Assurez-vous que le volume d'initialisation de chaque machine virtuelle d'application (WordPress) est membre du groupe de volumes et que le groupe de volumes est répliqué vers la région 2.

L'image suivante illustre l'affichage du groupe de volumes créé, qui inclut les volumes d'initialisation des deux machines virtuelles d'application WordPress, avec la réplication activée vers la région 2. Pour plus d'informations, reportez-vous à Création d'un groupe de volumes.

Tâche 1.2 : activer la réplication File Storage pour le contenu WordPress

Dans la région 2, créez un système de fichiers spécifiquement désigné pour la réplication. Ce système de fichiers sera utilisé pour répliquer de manière transparente les données de la région 1 vers la région 2.
Dans la région 2, créez une cible de montage qui sera utilisée lors du processus de récupération de la région 1 à la région 2.
Utilisez le système de fichiers créé à l'étape 1 pour activer et configurer la réplication à partir du stockage de fichiers OCI source dans la région 1.

L'image suivante illustre les détails de réplication File Storage vers la région 2.

Pour plus d'informations, reportez-vous à Réplication de système de fichiers.

Tâche 1.3 : préparation des machines virtuelles d'application pour l'exécution de l'automatisation personnalisée

Installer et configurer l'interface de ligne de commande Oracle Cloud Infrastructure Pour ce tutoriel, Oracle Linux 8 est utilisé pour la machine virtuelle d'application WordPress. Pour plus d'informations, reportez-vous à Installation de l'interface de ligne de commande.
Déployez le script à partir du référentiel GitHub (mds_colddr_scripts) dans le dossier /home/opc.
Installez les pandas et tabulez les modules utilisés par le script fourni.
```
pip install pandas
pip install tabulate
```
Mettez à jour le fichier config.csv avec les détails nécessaires pour Oracle HeatWave MySQL dans la région 1.
- Remplacez MYSQL_DB_SYSTEM_OCID par l'OCID d'Oracle HeatWave MySQL. Vous pouvez conserver ou personnaliser le libellé MySQL pour l'aligner sur vos exigences spécifiques.
- Remplacez COMPARTMENT_OCID par l'OCID du compartiment dans lequel se trouve le système MySQL.
- Remplacez PRIMARY_SUBNET_OCID et STANDBY_SUBNET_OCID par les OCID de sous-réseau des deux régions.
- Remplacez PRIMARY_DNS_VIEW_OCID et STANDBY_DNS_VIEW_OCID par les OCID des vues DNS privées associées à la zone DNS privée gérant l'enregistrement d'adresse Oracle HeatWave MySQL.
Remarque : assurez-vous que toutes les valeurs sont mises à jour avec précision.

Dans le cadre du tutoriel, nous utiliserons cette même machine virtuelle pour exécuter des scripts définis par l'utilisateur. Assurez-vous que la machine virtuelle agissant en tant que noeud de contrôle de récupération après sinistre a été configurée pour exécuter des commandes. Pour plus d'informations, reportez-vous à Appel de scripts personnalisés à l'aide de la commande d'exécution avec Oracle Cloud Infrastructure Full Stack Disaster Recovery.

Tâche 1.4 : création de stratégies OCI IAM pour OCI Full Stack DR

Configurez les stratégies OCI IAM requises pour OCI Full Stack DR, comme indiqué dans les documents suivants.

Tâche 1.5 : création de stratégies OCI IAM pour d'autres services gérés par OCI Full Stack DR

OCI Full Stack DR doit avoir la possibilité de contrôler et de gérer d'autres services OCI clés tels que le calcul, le réseau, le stockage et d'autres services divers. Afin de configurer les stratégies OCI IAM requises pour d'autres services, reportez-vous à Stratégies pour d'autres services gérés par Full Stack Disaster Recovery et à Stratégies OCI IAM.

Tâche 2 : création de groupes de protection de récupération après sinistre dans les deux régions

Créez des groupes de protection de récupération après sinistre dans les régions 1 et 2 si les groupes de protection de cette pile d'applications n'existent pas encore.

Tâche 2.1 : créer un groupe de protection dans la région 1

Accédez à la console OCI et accédez à Groupes de protection de récupération après sinistre, comme illustré à la figure 2.1.
1. Assurez-vous que le contexte de région OCI est défini sur Région 1 (Dubaï).
2. Cliquez sur Migration et récupération après sinistre.
3. Cliquez sur DR Protection Groups.
Figure 2.1 : Accéder aux groupes de protection de récupération après sinistre
Créez un groupe de protection de récupération après sinistre de base (DRPG) dans la région 1, comme illustré à la figure 2.2. Le pair, le rôle et les membres seront affectés dans les étapes ultérieures.
1. Sélectionnez le compartiment dans lequel créer le DRPG.
2. Cliquez sur Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue.
3. Utilisez un nom explicite pour le DRPG.
4. Sélectionnez le bucket OCI Object Storage pour les journaux OCI Full Stack DR.
5. Cliquez sur Créer.
Figure 2.2 : Paramètres nécessaires à la création d'un groupe de protection de récupération après sinistre dans la région 1

Tâche 2.2 : créer un groupe de protection dans la région 2

Accédez à la console OCI, puis à Groupes de protection de récupération après sinistre, comme illustré à la figure 2.3.
1. Assurez-vous que le contexte de région OCI est défini sur Région 2 (Abou Dhabi).
2. Cliquez sur Migration et récupération après sinistre.
3. Cliquez sur DR Protection Groups.
Figure 2.3 : Accédez aux groupes de protection de récupération après sinistre.
Créez un groupe de protection de récupération après sinistre de base (DRPG) dans la région 2, comme illustré à la figure 2.4. Le pair, le rôle et les membres seront affectés dans les étapes ultérieures.
1. Sélectionnez le compartiment dans lequel créer le DRPG.
2. Cliquez sur Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue.
3. Utilisez un nom explicite pour le DRPG.
4. Sélectionnez le bucket OCI Object Storage pour les journaux OCI Full Stack DR.
5. Cliquez sur Créer.
Figure 2.4 : Paramètres nécessaires à la création d'un groupe de protection de récupération après sinistre dans la région 2

Tâche 2.3 : associer des groupes de protection dans les régions 1 et 2

Associez les DRPG de chaque région en tant qu'homologues les uns des autres et affectez les rôles homologues de la base de données principale et de la base de données de secours. Les rôles principal et de secours sont automatiquement modifiés par OCI Full Stack DR dans le cadre de toute opération de récupération après sinistre/exécution de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment.

Accédez à la page Détails du groupe de protection DR.
1. Assurez-vous que le contexte de région OCI est défini sur Région 1 (Dubaï).
2. Cliquez sur Associer pour démarrer le processus.
Fig : Début de l'association DRPG
Entrez les paramètres comme indiqué dans l'image suivante.
1. Rôle : sélectionnez le rôle Principal. OCI Full Stack DR affecte automatiquement le rôle de secours à la région 2.
2. Région homologue : sélectionnez la région 2 (Abou Dhabi), où l'autre DRPG a été créé.
3. Groupe de protection de DR homologue : sélectionnez le DRPG homologue créé.
4. Cliquez sur Associer.
Fig : Paramètres nécessaires pour associer les DRPG

OCI Full Stack DR affiche un exemple tel qu'illustré dans l'image suivante, une fois l'association terminée.

Le DRPG principal actuel est Dubaï (région 1).
Le DRPG actuel est Abu Dhabi (région 2).

Fig : Affichage de la relation homologue du point de vue de chaque DRPG

Les mêmes informations peuvent être trouvées chaque fois que le contexte/la vue est d'une perspective globale affichant tous les groupes de protection de récupération après sinistre, comme illustré dans l'image suivante.

Le DRPG principal actuel est Dubaï (région 1).
Le DRPG actuel est Abu Dhabi (région 2).

Fig : Affichage de la relation homologue du point de vue du DRPG global

Tâche 3 : ajout de membres au groupe de protection de récupération après sinistre

Dans cette tâche, nous ajouterons les ressources OCI suivantes au DRPG principal dans la région 1.

Les deux instances de calcul hébergeant l'application WordPress seront ajoutées en tant que machines virtuelles mobiles. En outre, assurez-vous que la section Systèmes de fichiers des Options avancées est correctement configurée.
Groupe de volumes contenant le volume d'initialisation des noeuds de calcul d'application WordPress.
Stockage de fichiers OCI contenant le contenu WordPress.
Equilibreur de charge principal.

Tâche 3.1 : ajouter des membres à DRPG dans la région 1

Sélectionnez le DRPG dans la région 1 comme indiqué dans l'image suivante.
1. Assurez-vous que le contexte de région OCI est Région 1 (Dubaï).
2. Sélectionnez le DRPG dans la région 1.
3. Sélectionnez membres.
4. Cliquez sur Ajouter un membre pour lancer le processus.
Fig : procédure pour commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 1
Ajoutez une instance de calcul pour les machines virtuelles d'application WordPress.
1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Entrez Compute en tant que type de ressource de membre.
3. Sélectionnez l'instance de calcul hébergeant l'application WordPress.
4. Sélectionnez Instance mobile.
5. Cliquez sur Ajouter une correspondance de carte d'interface réseau virtuelle pour sélectionner le VCN et le sous-réseau à affecter aux cartes d'interface réseau virtuelles de la région 2 lors d'une récupération.
6. Cliquez sur Afficher les options avancées.
7. Dans Paramètres, sélectionnez Conserver le domaine de pannes.
8. Dans Systèmes de fichiers, complétez la section de mise en correspondance d'export en fonction de votre configuration, comme illustré dans les images suivantes.
Fig : paramètres nécessaires pour ajouter la machine virtuelle d'application WordPress

Fig : paramètres nécessaires pour mettre en correspondance la carte d'interface réseau virtuelle dans la région 2

Fig : options avancées, Conserver le domaine de pannes

Fig : options avancées, mise en correspondance des systèmes de fichiers

Fig : instance de calcul ajoutée au DRPG dans la région 1

Remarque : répétez les sous-étapes précédentes pour toutes les instances de calcul des machines virtuelles d'application WordPress.

Fig : deux instances de calcul ajoutées au DRPG dans la région 1
Ajoutez le groupe de volumes de blocs contenant le volume d'initialisation des machines virtuelles d'application WordPress.
1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Sélectionnez Groupe de volumes en tant que type de ressource membre.
3. Assurez-vous que le compartiment approprié contenant le groupe de volumes est sélectionné et sélectionnez le groupe de volumes.
Fig : paramètres nécessaires pour ajouter le groupe de volumes pour le calcul WordPress

Fig : groupe de volumes pour le calcul WordPress ajouté au DRPG dans la région 1
Ajoutez le stockage de fichiers OCI contenant le contenu WordPress.
1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Sélectionnez Système de fichiers comme type de ressource membre.
3. Assurez-vous que le compartiment approprié contenant le système de fichiers est sélectionné et sélectionnez le système de fichiers.
4. Sélectionnez le domaine de disponibilité de destination à utiliser dans la région 2.
5. Sélectionnez Chemin d'export source pour ce système de fichiers. Ce chemin d'export est créé dans la région de destination 2 après la restauration du système de fichiers.
6. Sélectionnez Cible de montage de destination dans la région 2 utilisée afin de créer un export pour le système de fichiers restauré.
Fig : paramètres nécessaires pour ajouter le système de fichiers pour le contenu WordPress

Fig : système de fichiers pour le contenu WordPress ajouté au DRPG dans la région 1
Ajoutez OCI Load Balancer.

Dans cet exemple, nous allons ajouter l'équilibreur de charge en tant que membre du DRPG dans la région 1.
1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Sélectionnez Equilibreur de charge comme type de ressource de membre.
3. Assurez-vous que les compartiments appropriés pour l'équilibreur de charge sont sélectionnés et sélectionnez l'équilibreur de charge à ajouter.
4. Sélectionnez l'équilibreur de charge de destination à utiliser dans la région 2.
5. Sélectionnez Ensemble de back-ends source. Il s'agit de l'ensemble de back-ends utilisé par les machines virtuelles d'application WordPress. Un équilibreur de charge OCI peut être partagé entre plusieurs applications et plusieurs ensembles de back-ends peuvent être configurés. Lors d'une permutation de récupération après sinistre, seuls les ensembles de back-ends indiqués ici verront leur configuration déplacée vers la région de secours.
6. Sélectionnez Ensemble de back-ends de destination. Il s'agit de l'ensemble de back-ends vide créé dans la région 2.
Fig : paramètres nécessaires pour ajouter un équilibreur de charge

Fig : équilibreur de charge ajouté au DRPG dans la région 1

Tâche 3.2 : Ajouter des membres au DRPG dans la région 2

Sélectionnez le DRPG dans la région 2 comme indiqué dans l'image suivante.
1. Assurez-vous que le contexte de région OCI est Région 1 (Abou Dhabi).
2. Sélectionnez le DRPG dans la région 2.
3. Sélectionnez membres.
4. Cliquez sur Ajouter un membre pour lancer le processus.
Fig : procédure pour commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 2
Ajoutez OCI Load Balancer.

Dans cet exemple, nous allons ajouter l'équilibreur de charge en tant que membre du DRPG dans la région 2.
1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Sélectionnez Equilibreur de charge comme type de ressource de membre.
3. Assurez-vous que le compartiment approprié pour l'équilibreur de charge est sélectionné et sélectionnez l'équilibreur de charge à ajouter.
4. Sélectionnez l'équilibreur de charge de destination à utiliser dans la région 1.
5. Sélectionnez Ensemble de back-ends source. Il s'agit de l'ensemble de back-ends utilisé par les machines virtuelles d'application WordPress. Un équilibreur de charge OCI peut être partagé entre plusieurs applications et plusieurs ensembles de back-ends peuvent être configurés. Lors d'une permutation de récupération après sinistre, seuls les ensembles de back-ends indiqués ici verront leur configuration déplacée vers la région de secours.
6. Sélectionnez Ensemble de back-ends de destination. Cet ensemble de back-ends est créé dans la région 2.
Fig : paramètres nécessaires pour ajouter un équilibreur de charge

Fig : équilibreur de charge ajouté au DRPG dans la région 2

Tâche 4 : créer des plans de récupération après sinistre de base dans la région 2

Dans cette tâche, nous allons créer les plans de permutation et de basculement initiaux associés au groupe de protection de récupération après sinistre de secours dans la région 2 (Abou Dhabi).

L'objectif de ces plans est de faire passer en toute transparence la charge de travail de la région principale (région 1) à la région de secours (région 2). Dans le cadre de toute opération de récupération après sinistre, les rôles des groupes de protection de récupération après sinistre dans les deux régions sont automatiquement inversés : le groupe de protection dans la région 1 devient le groupe de secours, tandis que le groupe de protection dans la région 2 assume le rôle principal après un basculement ou une permutation.

OCI Full Stack DR préremplira ces plans avec des étapes intégrées dérivées des ressources membres ajoutées lors des tâches précédentes. Ces plans seront ensuite personnalisés pour gérer les tâches propres à Oracle HeatWave MySQL pendant le processus de récupération.

Les plans de permutation sont toujours créés au sein du groupe de protection qui détient le rôle de secours. Puisque la Région 2 (Abou Dhabi) est actuellement le groupe de protection de secours, nous allons commencer à y créer les plans.

Tâche 4.1 : créer des plans de récupération après sinistre

Créez un plan de base en sélectionnant le DRPG dans la région 2 (Abu Dhabi)
1. Assurez-vous que le contexte de région OCI est Région 2 (Abou Dhabi).
2. Sélectionnez le DRPG de secours dans la région 2.
3. Sélectionnez Plans.
4. Cliquez sur Créer un plan pour lancer le processus.
Fig : commencer à créer des plans de récupération après sinistre de base dans la région 2
Créez un plan de permutation.
1. Entrez un nom simple mais significatif pour le plan de permutation. Le nom devrait être aussi court que possible mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
2. Sélectionnez Type de plan comme Permutation (planifiée).
Fig : paramètres nécessaires à la création d'un plan de permutation de récupération après sinistre
Créez un plan de basculement.

Suivez la même procédure pour créer un plan de basculement de base, comme illustré dans l'image suivante.
1. Entrez le nom du plan de basculement, simple mais significatif. Le nom devrait être aussi court que possible mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
2. Sélectionnez Type de plan comme Basculement (non planifié).
Fig : paramètres nécessaires à la création d'un plan de basculement de récupération après sinistre

Le groupe de protection de récupération après sinistre de secours de la région 2 doit désormais disposer des deux plans de récupération après sinistre, comme illustré dans l'image suivante. Ils géreront la transition des charges de travail de la région 1 vers la région 2. Vous allez créer des plans similaires dans la région 1 pour faire passer les charges globales de la région 2 à la région 1 dans une tâche ultérieure.

plan-créer-auh-completed.png
Fig : Affichage des deux plans de récupération après sinistre de base qui doivent exister dans la région 2 avant de poursuivre

Tâche 5 : personnaliser le plan de permutation de rôles dans la région 2

Les plans de récupération après sinistre de base créés dans la tâche 4 contiennent des étapes préremplies pour les tâches de récupération intégrées à OCI Full Stack DR et ne contiennent aucune information permettant de gérer les tâches de récupération propres à Oracle HeatWave MySQL. Cette tâche explique comment ajouter des groupes de plans de récupération après sinistre personnalisés et définis par l'utilisateur, ainsi que les étapes de gestion des tâches à effectuer lors d'une permutation :

Créez une sauvegarde de base de données après avoir arrêté progressivement les machines virtuelles d'application pour assurer la cohérence des données.
Transférez la dernière sauvegarde de base de données vers la région OCI 2 distante à des fins de redondance et de récupération après sinistre.
Restaurez la sauvegarde de base de données la plus récente dans la région 2 pour préparer l'environnement à la permutation.
Mettez à jour l'enregistrement DNS de base de données privée, ce qui permet aux machines virtuelles d'application de se connecter de manière transparente à la base de données dans la région 2.
Mettez fin à la base de données MySQL source dans la région 1.

Tâche 5.1 : sélectionner le plan de permutation

Accédez au plan de permutation créé dans la tâche 4.

Fig : commencer à personnaliser le plan de permutation dans la région 2

Tâche 5.2 : (facultatif) activer les groupes de plans de récupération après sinistre qui mettent fin aux artefacts

Trois groupes de plans sont désactivés par défaut dans les plans de permutation, comme illustré dans l'image suivante. Ces groupes de plans sont désactivés pour être rassurés pendant le test, ce qui garantit qu'aucun artefact n'est supprimé et qu'une copie de sauvegarde viable reste intacte en cas de problème pendant la phase de test.

Toutefois, ces trois groupes de plans sont conçus pour mettre fin aux artefacts (supprimés) qui ne seront plus nécessaires pour les futures opérations de récupération après sinistre. Si ces groupes de plans ne sont pas activés, les artefacts inutilisés continueront de s'accumuler au fil du temps lorsque vous effectuerez des permutations entre les deux régions, ce qui peut prêter à confusion quant aux instances de calcul, à OCI File Storage et aux groupes de volumes qui doivent être actifs.

Si vous le souhaitez, l'activation de ces groupes de plans permet d'éviter le nettoyage manuel des artefacts inutiles avant leur mise en production. Cette étape proactive permet de rationaliser la transition vers la production et de maintenir un environnement plus propre et plus gérable.

Fig : groupes de plans désactivés par défaut

Pour activer les groupes de plans, sélectionnez Activer toutes les étapes dans le menu contextuel à droite du nom du groupe de plans.

Fig : activation de la terminaison du système de fichiers

Fig : cliquez sur Activer pour valider.

Fig : procédure d'activation de la terminaison d'instances de calcul

Fig : cliquez sur Activer pour valider.

Fig : activation de l'interruption du groupe de volumes

Fig : cliquez sur Activer pour valider.

Tâche 5.3 : réorganiser les groupes de plans de récupération après sinistre

Vous devez monter le système de fichiers sur les nouvelles machines virtuelles déplacées vers la région 2 avant de mettre à jour les ensembles de back-ends de l'équilibreur de charge. Cela garantit que l'application dispose d'un accès approprié aux ressources de stockage requises, ce qui facilite une transition en douceur pendant le processus de permutation.

Fig : Capture d'écran illustrant l'ordre initial du plan de permutation et la procédure de réorganisation

Fig : lancez la réorganisation

Déplacez Systèmes de fichiers - Montage sur les instances de calcul avant Equilibreurs de charge - Mettre à jour les ensembles de back-ends de destination.
Cliquez sur Enregistrer les modifications.

Fig : Ordre du plan de permutation final

Tâche 5.4 : créer un groupe de plans pour exécuter des scripts personnalisés

Commencez par ajouter des groupes de plans de récupération après sinistre personnalisés et définis par l'utilisateur pour adapter le workflow de récupération après sinistre aux besoins spécifiques du processus de récupération après sinistre de sauvegarde/restauration MySQL.

Ces groupes de plans appellent les scripts nécessaires à partir de WordPress VM1 dans la région 1 et doivent être positionnés dans le workflow de récupération après sinistre avant de démarrer les machines virtuelles d'application WordPress. Cela garantit que la base de données MySQL est entièrement restaurée et opérationnelle avant la mise en ligne des machines virtuelles d'application.

Le plan personnalisé suivant doit être ajouté au plan de permutation prérempli : Créer une sauvegarde MySQL Database, Copier une sauvegarde MySQL Database, Restaurer une sauvegarde MySQL Database, Mettre à jour le DNS MySQL Database et Mettre fin à la source MySQL Database.

Ajoutez un groupe de plans personnalisé pour créer la sauvegarde de base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Create MySQL DB Backup.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Instances de calcul - Lancement.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de création de la sauvegarde de base de données MySQL.
Fig : paramètres permettant de créer une sauvegarde de base de données MySQL de groupe de plans

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Create MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez Instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : paramètres permettant de créer une sauvegarde de base de données MySQL de création d'étape

Cliquez sur Ajouter.

Fig : ajoutez un groupe de plans pour créer une sauvegarde de base de données MySQL.
Ajoutez un groupe de plans personnalisé pour copier la sauvegarde de base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Copy MySQL DB Backup.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer le groupe de plans défini par l'utilisateur après le groupe de plans intégré Créer une sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de copie de la sauvegarde de base de données MySQL.
Fig : paramètres permettant de créer une sauvegarde de base de données de copie de groupe de plans MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Copy MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant d'ajouter une sauvegarde de base de données de copie d'étape MySQL

Cliquez sur Ajouter.

Fig : ajoutez un groupe de plans Copier une sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour restaurer la sauvegarde de base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Restore MySQL DB Backup.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer le groupe de plans défini par l'utilisateur après le groupe de plans intégré Copier la sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de restaurer la sauvegarde de base de données MySQL.
Fig : paramètres permettant de créer une sauvegarde de base de données MySQL de restauration de groupe de plans

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Restore MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant d'ajouter une sauvegarde de base de données MySQL de restauration d'étape

Cliquez sur Ajouter.

Fig : ajoutez un groupe de plans Restaurer une sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour mettre à jour le DNS de base de données MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Update MySQL DB DNS.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Restaurer la sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour du DNS de base de données MySQL.
Fig : paramètres permettant de créer le DNS de base de données de mise à jour de groupe de plans MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Update MySQL DB DNS. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant d'ajouter un DNS de base de données MySQL de mise à jour d'étape

Cliquez sur Ajouter.

Fig : ajoutez un DNS de base de données de mise à jour de groupe de plans MySQL.
Ajoutez un groupe de plans personnalisé pour mettre fin à la base de données source MySQL.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Terminate MySQL DB Source.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer le groupe de plans défini par l'utilisateur après le groupe de plans intégré Systèmes de fichiers - Enlever du groupe de protection de récupération après sinistre.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de terminaison de la source de base de données MySQL.
Fig : paramètres permettant de créer le groupe de plans Mettre fin à la base de données source MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Terminate MySQL Source DB. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : paramètres permettant d'ajouter une base de données source MySQL de terminaison d'étape

Cliquez sur Ajouter.

Fig : ajoutez un groupe de plans Terminer la base de données source MySQL
(Facultatif) Ajoutez un groupe de plans personnalisé pour arrêter l'application WordPress.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Stop.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur à la fin après le groupe de plans intégré Equilibreurs de charge - Mettre à jour les ensembles de back-ends source.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script d'arrêt de l'application.
Fig : Paramètres permettant de créer le groupe de plans Application - Arrêter

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Stop - VM1.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_stop.sh.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant de créer une application d'étape - Arrêter - VM1

Cliquez sur Ajouter une étape pour ajouter une seconde étape afin d'arrêter l'application sur VM2.

Fig : Ajouter une application d'étape - Arrêter - VM2

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Stop - VM2.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM2 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM2 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_stop.sh.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant de créer une application d'étape - Arrêter - VM2

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Application - Arrêter
(Facultatif) Ajoutez un groupe de plans personnalisé pour démarrer l'application WordPress.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Start.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, sélectionnez Ajouter après pour insérer le groupe de plans défini par l'utilisateur à la fin, après le groupe de plans intégré Systèmes de fichiers - Montage sur les instances de calcul.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage de l'application.
Fig : Paramètres permettant de créer le groupe de plans Application - Démarrage

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Start - VM1.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans ce cas, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_start.sh.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant de créer une application d'étape - Démarrage - VM1

Cliquez sur Ajouter une étape pour ajouter une seconde étape afin de démarrer l'application sur VM2.

Fig : Ajouter une application d'étape - Démarrer - VM2

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Start - VM2.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans ce cas, le script sera exécuté sur l'application WordPress VM2 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM2 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_start.sh.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant de créer une application d'étape - Démarrer - VM2

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Application - Démarrer

La personnalisation du plan de permutation a été effectuée avec succès.

Tâche 6 : personnalisation du plan de basculement dans la région 2

Dans cette tâche, ajoutez des groupes de plans de récupération après sinistre personnalisés et définis par l'utilisateur et des étapes pour gérer les tâches à effectuer lors d'un basculement.

Restaurez la sauvegarde de base de données la plus récente dans la région 2 pour préparer l'environnement à la permutation.
Mettez à jour l'enregistrement DNS de base de données privée, ce qui permet aux machines virtuelles d'application de se connecter de manière transparente à la base de données dans la région 2.

Tâche 6.1 : sélectionner le plan de basculement

Accédez au plan de basculement créé dans la tâche 4.

Fig : procédure de personnalisation du plan de basculement dans la région 2

Tâche 6.2 : créer un groupe de plans pour exécuter des scripts personnalisés dans la région 2

Ces groupes de plans appellent les scripts nécessaires à partir de la machine virtuelle d'application WordPress et doivent être positionnés dans le workflow de récupération après sinistre avant de redémarrer les machines virtuelles d'application WordPress. Cela garantit que la base de données MySQL est entièrement restaurée et opérationnelle avant la mise en ligne des machines virtuelles d'application.

Le plan personnalisé suivant doit être ajouté au plan de basculement prérempli : Restaurer la sauvegarde MySQL Database et Mettre à jour le DNS MySQL Database.

Ajoutez un groupe de plans personnalisé pour restaurer la sauvegarde de base de données MySQL.
1. Cliquez sur Ajouter un groupe pour commencer.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Restore MySQL DB Backup.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Instances de calcul - Lancement.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de restaurer la sauvegarde de base de données MySQL.
Fig : paramètres permettant de créer une sauvegarde de base de données MySQL de restauration de groupe de plans

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Restore MySQL DB Backup. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant d'ajouter une sauvegarde de base de données MySQL de restauration d'étape

Cliquez sur Ajouter.

Fig : ajoutez un groupe de plans Restaurer une sauvegarde de base de données MySQL
Ajoutez un groupe de plans personnalisé pour mettre à jour le DNS de base de données MySQL.
1. Cliquez sur Ajouter un groupe pour commencer.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Update MySQL DB DNS.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré Restaurer la sauvegarde de base de données MySQL.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour du DNS de base de données MySQL.
Fig : paramètres permettant de créer le DNS de base de données de mise à jour de groupe de plans MySQL

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Update MySQL DB DNS. Identique au nom du groupe de plans.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : paramètres permettant de créer un DNS de base de données MySQL de mise à jour d'étape

Cliquez sur Ajouter.

Fig : ajoutez un DNS de base de données de mise à jour de groupe de plans MySQL.
(Facultatif) Ajoutez un groupe de plans personnalisé pour redémarrer l'application WordPress.
1. Cliquez sur Ajouter un groupe.
2. Entrez un nom de groupe de plans simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Restart.
3. Sélectionnez le profil dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans cet exemple, sélectionnez Ajouter après pour insérer le groupe de plans défini par l'utilisateur après le groupe de plans intégré Systèmes de fichiers - Montage sur les instances de calcul.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage de l'application.
Fig : Paramètres permettant de créer le groupe de plans Application - Redémarrer

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Restart - VM1.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM1 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM1 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_restart.sh.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant de créer une application d'étape - Redémarrer - VM1

Cliquez sur Ajouter une étape pour ajouter une seconde étape afin de redémarrer l'application sur VM2.

Fig : Ajouter une application d'étape - Redémarrer - VM2

Dans Ajouter une étape de groupe de plans, entrez les informations suivantes.
1. Entrez un nom d'étape simple mais descriptif. Dans cet exemple, nous allons utiliser Application - Start - VM2.
2. Sélectionnez une région contenant l'instance sur laquelle cette étape sera exécutée. Dans cet exemple, le script sera exécuté sur l'application WordPress VM2 dans la région 1.
3. Sélectionnez Exécuter un script local.
4. Sélectionnez l'instance cible, qui est l'application WordPress VM2 dans la région 1.
5. Dans Paramètres de script, entrez le chemin complet du script avec les paramètres. Par exemple : /home/opc/fsdrscripts/wdp_restart.sh.
6. Dans Exécuter en tant qu'utilisateur, saisissez opc.
7. Cliquez sur Ajouter une étape.
Fig : Paramètres permettant de créer une application d'étape - Redémarrer - VM2

Cliquez sur Ajouter.

Fig : Ajouter un groupe de plans Application - Redémarrer

La personnalisation du plan de basculement s'est terminée avec succès.

plan-personnalisé-fo-auh-complete.png

Tâche 7 : exécuter des prévérifications dans la région 2

Les plans de reconfiguration dynamique de permutation et de basculement ont été créés dans la région de secours 2. Ces plans permettent à OCI Full Stack DR de faire passer les charges de travail de la région 1 à la région 2. La tâche suivante consiste à exécuter les prévérifications pour les plans de permutation et de basculement afin de garantir la préparation et de valider le processus de transition.

Tâche 7.1 : lancer les pré-vérifications pour le plan de permutation

Exécutez des prévérifications pour le plan de récupération après sinistre de permutation.

Assurez-vous que le contexte de région est défini sur la région de secours 2.
Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné. Il doit être le rôle de secours.
Cliquez sur le nom du plan de permutation.
Cliquez sur Exécuter les prévérifications.

Fig : indique comment exécuter des prévérifications du plan de permutation

Fig : Affichage des prévérifications terminées du plan de permutation

Tâche 7.2 : lancer les pré-vérifications pour le plan de basculement

Exécutez les prévérifications pour le plan de récupération après sinistre de basculement.

Assurez-vous que le contexte de région est défini sur la région de secours 2.
Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné. Il doit être le rôle de secours.
Cliquez sur le nom du plan de basculement.
Cliquez sur Exécuter les prévérifications.

Fig : indique comment exécuter des prévérifications du plan de basculement

Fig : Affichage des prévérifications terminées du plan de basculement

Tâche 8 : exécution du plan de permutation de rôles dans la région 2

Exécutez le plan de récupération après sinistre de permutation pour commencer le processus de transition de l'application WordPress avec Oracle HeatWave MySQL de la région 1 vers la région 2.

Assurez-vous que le contexte de région est défini sur la région de secours 2.
Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné. Il doit être le rôle de secours.
Cliquez sur le nom du plan de permutation.
Cliquez sur Exécuter le plan.

Cette tâche exécute le plan de permutation dans la région 2.

Désélectionnez Activer les prévérifications, car elles ont déjà été exécutées dans la tâche 7.
Cliquez sur Exécuter le plan de récupération après sinistre pour commencer.

Fig : Affichage de l'exécution du plan de permutation

Fig : Affichage du plan de permutation en cours

Surveillez le plan de permutation jusqu'à ce que la charge globale complète passe de la région 1 à la région 2.

L'exécution du plan de permutation s'est terminée avec succès en 52 minutes environ.

Fig : Affichage d'une exécution de plan de permutation terminée.

Tâche 9 : créer et personnaliser des plans de récupération après sinistre dans la région 1

Avec l'achèvement réussi de la permutation par OCI Full Stack DR, la région 2 a désormais pris le rôle de la région principale, tandis que la région 1 a basculé en tant que région de secours.

Suivez la même approche que celle décrite dans les tâches 1 à 8. Créez et personnalisez les plans de permutation et de basculement au sein du groupe de protection de récupération après sinistre pour la région 1, qui sert désormais de région homologue de secours.

plan-créer-dxb.png
Fig : Capture d'écran présentant les plans créés dans la région 1

Fig : Capture d'écran illustrant le plan de permutation dans la région 1

Fig : Capture d'écran illustrant le plan de basculement dans la région 1

Etapes suivantes

Pour plus d'informations, reportez-vous à la documentation OCI Full Stack DR et Oracle HeatWave MySQL dans la section Liens associés.

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery
Oracle HeatWave MySQL
OCI Full Stack Disaster Recovery
HeatWave MySQL
Rejoignez le canal slack #full-stack-dr

Remerciements

Auteur - Antoun Moubarak (spécialiste Hyperscaler vers OCI)
Contributeur - Suraj Ramesh (gestionnaire de produit pour OCI Full Stack DR)

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation produit, consultez le site Oracle Help Center.

Informations relatives au titre et au copyright

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24417-01

January 2025

Oracle et/ou ses affiliés.