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 valeur pour les informations d'identification, la location et les compartiments Oracle Cloud Infrastructure. A la fin de l'exercice, remplacez ces valeurs par des valeurs propres à votre environnement cloud.

Automatisez la récupération pour Oracle Analytics Cloud à l'aide d'OCI Full Stack Disaster Recovery

Partie 1 - Introduction

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery 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 pour récupérer un ou plusieurs systèmes métier sans repenser ou modifier l'architecture de l'infrastructure, des bases de données ou des applications existantes.

Oracle Analytics Cloud (OAC) est une offre OCI Platform-as-a-Service gérée (PaaS), qui n'est pas quelque chose que Full Stack DR peut gérer de manière native car OAC lui-même n'expose pas le calcul, le stockage ou la base de données aux utilisateurs OCI. Toutefois, Full Stack DR peut automatiser la récupération pour les offres PaaS tant que l'équipe d'ingénierie d'un service donné, tel qu'OAC, a documenté un moyen de déployer et de récupérer son service à des fins de récupération après sinistre entre les régions OCI. L'équipe d'ingénierie OAC a écrit Configuration de récupération après sinistre pour Oracle Analytics Cloud pour expliquer comment déployer et récupérer OAC manuellement.

Full Stack DR n'est pas utilisé pour installer, configurer ou déployer des éléments relatifs à Oracle Analytics Cloud (OAC), notamment les fonctions de réseau, le calcul, le stockage, la réplication de stockage, les bases de données ou l'application/service OAC lui-même. OAC doit être entièrement déployé pour la récupération après sinistre dans les régions en suivant les instructions détaillées fournies dans Configuration de récupération après sinistre pour Oracle Analytics Cloud avant de tenter d'utiliser la récupération après sinistre sur la pile complète de quelque manière que ce soit.

Les étapes de récupération manuelle souscrites par l'ingénierie OAC dans Configuration de récupération après sinistre pour Oracle Analytics Cloud doivent également être testées pour la permutation et la permutation (également appelée reprise dans la documentation OAC) avant d'utiliser la récupération après sinistre de pile complète.

OAC fait normalement partie d'un système plus large

Ce tutoriel suppose qu'Oracle Analytics Cloud est la seule application ajoutée aux groupes de protection de récupération après sinistre. Ce n'est pas normal.

Ce tutoriel est inhabituel dans le fait que seul OAC est affiché et discuté tout au long du document pour garder les choses simples. Normalement, OAC ne sera qu'une petite partie d'un système métier beaucoup plus grand et plus complexe qui comprend de nombreux services et applications différents dans un seul groupe de protection Full Stack DR et un ensemble de plans de récupération après sinistre. Il est fort probable que vous suiviez des tutoriels Oracle Help Center similaires pour d'autres applications et services tels que PeopleSoft, WebLogic Server, Oracle Integration Cloud, etc.

Ce tutoriel montre simplement comment implémenter Oracle Analytics Cloud par lui-même car nous ne voulons pas submerger le lecteur en introduisant trop de pièces mobiles. Ce tutoriel montre donc OAC par lui-même pour réduire la confusion et rester concentré sur ce qui est nécessaire pour automatiser la récupération pour Oracle Analytics Cloud.

Attention à l'implémentation incrémentielle

L'ajout de membres supplémentaires à un groupe de protection de récupération après sinistre après la création de plans de récupération après sinistre supprimera tous les plans de récupération après sinistre existants dans les groupes de protection des deux régions.

Full Stack DR est conçu avec l'hypothèse que l'ensemble de la pile d'applications pour un système d'entreprise donné est déjà déployé dans les régions OCI et que la récupération après sinistre manuelle a déjà fait ses preuves. Si votre système métier inclut plus d'OAC, ajoutez tous les membres de toutes les autres applications ou services OCI aux groupes de protection de récupération après sinistre avant de créer des plans de récupération après sinistre.

Fonctionnement de la récupération

La solution de récupération pour OAC requiert Full Stack DR pour exécuter une série de scripts bash 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 North American Analytics Specialists et disponibles dans un référentiel GitHub spécialement conçu pour cette solution de récupération après sinistre OAC. Les scripts bash sont téléchargés vers une instance de calcul faisant partie de la pile d'applications que Full Stack DR gérera lors d'une opération de récupération.

Ce tutoriel explique comment télécharger les scripts et comment les utiliser ultérieurement. Ce tutoriel utilise l'option 2 ci-dessous pour héberger les scripts bash uniquement car le tutoriel n'inclut rien d'autre qu'OAC.

Option 1 pour l'hébergement des scripts

OAC fait le plus souvent partie d'un système métier plus vaste et plus complexe qui inclut une application telle qu'Oracle E-Business Suite, PeopleSoft ou JD Edwards Enterprise, ainsi que d'autres bases de données, instances de calcul et applications locales. Dans ce cas, il vous suffit de choisir l'une des instances de calcul "movibles" qui font déjà partie du système métier pour héberger les scripts. L'instance de calcul sélectionnée peut être n'importe quel emplacement où Oracle Linux est installé. Il s'agit probablement d'une machine virtuelle existante qui remplit une autre fonction, telle qu'un serveur d'applications ou un serveur d'administration.

Ce tutoriel fait référence à cette instance de calcul en tant que noeud de contrôle ou noeud de récupération après sinistre, même si elle remplit réellement une autre fonction dans la pile d'applications.

Option 2 pour l'hébergement des scripts

S'il s'agit d'un cas inhabituel où OAC sera le seul service d'application que Full Stack DR va gérer lors d'une opération de récupération, une instance de calcul devra être créée uniquement pour héberger les scripts.

Normalement, Full Stack DR ne nécessite aucun serveur de gestion spécialisé pour automatiser les opérations de récupération. Toutefois, vous allez créer une instance de calcul qui agira en tant que serveur de gestion spécialisé dans ce cas, car OAC n'est pas géré de manière native par Full Stack DR. Dans ce document, le serveur de gestion spécialisé est considéré comme Noeud de contrôle ou Noeud de récupération après sinistre. L'objectif du noeud de contrôle est simplement d'agir en tant que serveur où des scripts personnalisés peuvent résider et être appelés par Full Stack DR lors d'une opération de récupération. Ce tutoriel explique comment créer des groupes et des étapes de plan de récupération après sinistre personnalisés définis par l'utilisateur dans le cadre de vos plans de récupération après sinistre pour appeler les scripts installés sur le noeud de contrôle.

Architecture de déploiement OAC

Oracle Analytics Cloud (OAC) doit d'abord être déployé pour la récupération après sinistre dans les régions OCI avant d'introduire Full Stack DR. Il est extrêmement important que les étapes manuelles de récupération d'OAC décrites par l'ingénierie OAC soient testées et fonctionnent correctement avant de tenter d'automatiser le processus de récupération à l'aide de Full Stack DR.

Les deux architectures de référence suivantes peuvent être suivies lors du déploiement d'OAC pour la récupération après sinistre dans les régions OCI. Les deux architectures de référence illustrent une topologie à plusieurs niveaux avec des ressources redondantes réparties dans deux régions OCI.

Option 1 : Déployer l'instance publique OAC

Une instance publique Oracle Analytics Cloud réside sur le réseau Oracle Service et est accessible directement à partir d'Internet. L'adresse IP publique Oracle Analytics Cloud sera directement configurée avec le registraire DNS.

Fig 1 : architecture de référence OIC lors de l'utilisation d'instances publiques OAC

Option 2 : Déployer une instance privée OAC

Une instance privée Oracle Analytics Cloud n'est pas accessible à partir du réseau Internet public. Elle nécessite donc un équilibreur de charge public OCI pour faciliter l'accès. L'adresse IP de l'équilibreur de charge public sera ajoutée au registraire DNS.

Fig 2 : architecture de référence OIC lors de l'utilisation d'instances privées OAC

Architecture de déploiement de récupération après sinistre de la pile complète

Les illustrations suivantes montrent les ressources de calcul ajoutées en tant que membres à chaque groupe de protection de récupération après sinistre (DRPG) pour la récupération après sinistre sur pile complète. Il s'agit des différents composants que Full Stack DR peut gérer en dehors du service Oracle Analytics Cloud (OAC).

Aucun composant OAC autre qu'Autonomous Data Warehouse (ADW) n'est affiché dans l'une des architectures de référence DRPG présentées ci-dessous, car OAC PaaS est invisible pour la récupération après sinistre de la pile complète. Par conséquent, aucun élément OAC autre qu'ADW n'est ajouté aux DRPG dans les deux régions.

Full Stack DR dispose d'une automatisation intégrée pour gérer le calcul, le stockage de blocs, le stockage de fichiers, les bases de données Oracle, les équilibreurs de charge et de nombreuses autres ressources pendant une récupération, mais il ne dispose pas d'une automatisation intégrée pour OAC lui-même. La récupération OAC est contrôlée par une série de scripts bash qui peuvent être téléchargés à partir d'un référentiel GitHub dédié à ce tutoriel. Les scripts bash doivent être installés sur une instance de calcul de votre choix en suivant l'une des options suivantes pour le placement et le contrôle des scripts.

Option 1 : Automatiser la récupération pour OAC en tant qu'application autonome

Cette architecture de déploiement n'est pas typique et a été conçue pour des situations très rares où OAC est la seule application récupérée par Full Stack DR. Dans ce cas, une instance de calcul spécialisée affichée en tant que noeud de récupération après sinistre ci-dessous est créée pour héberger les scripts bash personnalisés appelés par Full Stack DR pour gérer la récupération d'OAC.

Fig 3 : architecture de déploiement de récupération après sinistre de pile complète nécessitant un noeud de contrôle de récupération après sinistre spécialisé

Option 2 : Automatiser la récupération pour OAC dans le cadre d'une pile d'applications

L'architecture de déploiement simpliste présentée dans la figure 4 ci-dessous est un exemple de déploiement plus courant d'OAC où il s'agit simplement d'un composant d'une pile d'applications plus vaste et plus complexe où de nombreux services et applications doivent être récupérés ensemble. La plupart des systèmes métier sont beaucoup plus complexes que celui fictif présenté ci-dessous et incluent généralement des bases de données supplémentaires, d'autres applications Oracle et/ou non Oracle, ainsi que d'autres services OCI tels qu'OIC, ODI, OHS, IAM, etc.

Dans ce cas, il n'est pas nécessaire de créer un noeud de récupération après sinistre spécialisé comme celui illustré à la figure 3 ci-dessus. Les scripts bash personnalisés qui gèrent la récupération d'OAC peuvent être installés sur l'un des serveurs indiqués comme calcul mobile dans la figure 4 ci-dessous.

Fig 4 : architecture de déploiement de récupération après sinistre de pile complète sans avoir besoin d'un noeud de contrôle de récupération après sinistre spécialisé

Se familiariser avec l'ensemble du processus

L'équipe d'ingénierie Full Stack Disaster Recovery a créé une série de vidéos complémentaires pour ce tutoriel afin d'aider les gens à comprendre l'ensemble du flux de processus. Ces vidéos font partie d'une playlist YouTube accessible à l'aide des liens suivants :

• Vidéo 1 : Déployez Oracle Analytics Cloud pour la récupération après sinistre
• Vidéo 2 : Automatiser la récupération pour Oracle Analytics Cloud
• Vidéo 3 : Scripts utilisés pour automatiser la récupération pour Oracle Analytics Cloud

Partie 2 - Instructions étape par étape

Cette partie commence les instructions détaillées nécessaires pour ajouter Oracle Analytics CLoud à Full Stack DR.

Objectifs de ce tutoriel

Les étapes suivantes seront traitées dans ce tutoriel expliquant comment automatiser la récupération pour Oracle Analytics Cloud (OAC) à l'aide de Full Stack DR :

1. Tâche 1 : déploiement d'OAC pour la récupération après sinistre dans les régions OCI
   1. Préparer le noeud de contrôle de récupération après sinistre OAC
   2. Télécharger des scripts personnalisés vers le noeud de contrôle de récupération après sinistre
   3. Installer et déployer manuellement OAC pour la récupération après sinistre dans deux régions OCI
   4. Testez manuellement toutes les étapes de récupération de la région 1 souhaitée à la région 2
   5. Testez manuellement toutes les étapes de récupération de la région 2 souhaitée vers la région 1
2. Tâche 2 : préparation de la reconfiguration dynamique de la pile complète
   1. Création de stratégies IAM pour Full Stack DR
   2. Création de stratégies IAM pour d'autres services OCI
   3. Créer des buckets de stockage d'objet pour les journaux
3. Tâche 3 : création de groupes de protection de récupération après sinistre (DRPG)
4. Tâche 4 : ajouter des membres aux DRPG des régions 1 et 2
5. Tâche 5 : créer des plans de récupération après sinistre de base dans la région 2 (Phoenix)
   1. Créer un plan de permutation
   2. Créer un plan de basculement
6. Tâche 6 : personnaliser le plan de permutation dans la région 2 (Phoenix)
7. Tâche 7 : personnaliser le plan de basculement dans la région 2 (Phoenix)
8. Tâche 8 : exécuter le plan de permutation dans la région 2 (Phoenix)
9. Tâche 9 : créer des plans de récupération après sinistre de base dans la région 1 (Ashburn)
   1. Créer un plan de permutation
   2. Créer un plan de basculement
10. Tâche 10 : personnaliser le plan de permutation dans la région 1 (Ashburn)
11. Tâche 11 : personnaliser le plan de basculement dans la région 1 (Ashburn)

Définitions et hypothèses tout au long du tutoriel

Régions

• La région 1 est Ashburn
  • Ashburn sera la région principale.
  • Ce rôle finira par passer en mode veille lorsque vous serez invité à effectuer une permutation dans les étapes ultérieures.
• La région 2 est Phoenix
  • Phoenix commencera comme la région de secours.
  • Ce rôle deviendra le rôle principal une fois que vous serez invité à effectuer une permutation dans les étapes ultérieures.

Catégories

Vous êtes libre d'organiser OAC et Full Stack DR dans n'importe quel schéma de compartiment qui respecte vos normes de gouvernance informatique. Nous avons choisi d'organiser les applications dans leurs propres compartiments individuels, puis d'organiser tous les groupes de protection de récupération après sinistre en un seul compartiment où des systèmes métier complètement différents sont visibles en un coup d'œil.

• L'organisation de tous les groupes de protection de récupération après sinistre dans un seul compartiment en dehors des applications permet au personnel informatique de localiser et d'exécuter plus facilement des plans de récupération après sinistre pour de nombreux systèmes métier complètement différents.
• Le fait de disposer d'un seul compartiment pour tous les groupes de protection de récupération après sinistre permet d'éliminer les erreurs humaines et augmente la vitesse à laquelle les plans de récupération après sinistre peuvent être trouvés et exécutés
  • Compartiment pour Oracle Analytics Cloud : oac-demo. Le compartiment pour OAC lui-même, le stockage, les buckets de stockage, le calcul et la base de données associés à OAC est oac-demo dans ce tutoriel.
  • Compartiment pour la récupération après sinistre de pile complète : myprojects_NA. Le compartiment des plans et groupes de protection de récupération après sinistre Full Stack est myprojects_NA dans ce tutoriel.

Noeud de contrôle de récupération après sinistre OAC

Le noeud de contrôle de récupération après sinistre est toute instance de calcul que vous désignez pour héberger des scripts bash personnalisés qui effectuent des tâches spécifiques pour récupérer OAC. Les scripts sont appelés par Full Stack DR lors d'une opération de récupération. Ce tutoriel explique comment ajouter les scripts à Full Stack DR aux étapes 6, 7, 10 et 11.

• Pour OAC en tant qu'application autonome : il s'agit d'une instance de calcul spécialisée que vous créez pour agir en tant qu'hôte des scripts personnalisés
• Pour OAC dans le cadre d'une pile d'applications : il s'agit de toute instance de calcul existante membre d'un groupe de protection de récupération après sinistre. Par exemple, Oracle E-Business Suite ou PeopleSoft aura des serveurs d'applications membres des mêmes DRPG qui gèrent la récupération pour OAC ; l'un d'entre eux peut remplir le rôle de noeud de contrôle de récupération après sinistre dans ce tutoriel.

Prérequis

Oracle Analytics Cloud doit être déployé pour la récupération après sinistre dans les deux régions avant de commencer à travailler avec Full Stack DR. Cette opération est traitée dans la tâche 1 ci-dessous.

Tâche 1 : déployer Oracle Analytics Cloud pour la récupération après sinistre

Full Stack DR n'est impliqué dans aucune partie de cette étape.

Tâche 1.1 : préparer le noeud de contrôle de récupération après sinistre pour exécuter l'automatisation personnalisée

Désignez une instance de calcul comme noeud de contrôle de récupération après sinistre pour OAC. Il peut s'agir d'une instance de calcul existante ou d'une instance de calcul créée uniquement à cette fin. Pour plus de détails, reportez-vous aux options ci-dessous. Assurez-vous que les instances de calcul agissant en tant que noeud de contrôle de récupération après sinistre ont été configurées pour exécuter des commandes à l'aide de l'agent cloud OCI : Exécution de commandes sur une instance.

Option 1 : OAC en tant qu'application autonome

Ce tutoriel suppose qu'OAC est un service autonome. Vous allez donc créer une instance de calcul avec Oracle Linux dans la région 1. Utilisez la forme la moins coûteuse avec Oracle Linux car elle ne sera utilisée que pour héberger les scripts bash personnalisés. La nécessité d'une instance de calcul spécialisée dédiée à l'accomplissement de ce rôle est inhabituelle ; l'option 2 est le scénario le plus courant pour une majorité d'organisations.

L'instance de calcul spécialisée sera ajoutée en tant que membre du groupe de protection de récupération après sinistre de la région 1 lors d'une étape ultérieure.

Option 2 : OAC dans le cadre d'une pile d'applications

Vous pouvez utiliser n'importe quel calcul mobile existant faisant partie de n'importe quelle application Oracle ou non Oracle gérée par Full Stack DR dans la région 1. Cette opération remplit le rôle du noeud de contrôle de récupération après sinistre chaque fois que ce tutoriel fait référence au noeud de contrôle de récupération après sinistre.

Il est préférable d'utiliser une instance de calcul mobile, mais vous pouvez également désigner une instance de calcul non mobile dans la région 1 et une autre dans la région 2 si vous ne disposez d'aucun calcul mobile dans le cadre de votre solution de récupération après sinistre. Vous devrez tenir à jour les modifications apportées aux scripts ou au système d'exploitation invité dans les deux régions si le calcul non mobile est utilisé pour ce rôle.

Option 3 : OAC dans le cadre d'une pile d'applications avec plusieurs offres PaaS

Votre système métier dispose peut-être également d'Oracle HTTP Server (OHS), d'Oracle Integration Cloud (OIC) et d'Oracle Data Integrator (ODI). Dans ce cas, vous pouvez envisager de créer une instance de calcul spécialisée comme vous le feriez avec l'option 1 pour héberger les scripts de récupération après sinistre pour tous les différents services PaaS.

Tâche 1.2 : vérifier que le groupe de volumes est répliqué vers la région 2

Assurez-vous que le volume d'initialisation du noeud de contrôle de récupération après sinistre est membre d'un groupe de volumes de blocs et que le groupe de volumes de blocs est répliqué vers la région 2.

Assurez-vous que tout autre amorçage et bloc appartenant à tout autre calcul mobile pour ce projet de récupération après sinistre de la pile complète appartient également aux groupes de volumes de blocs répliqués dans la région 2.

Tâche 1.3 : télécharger les scripts bash vers le noeud de contrôle de récupération après sinistre

Téléchargez les scripts bash personnalisés de github écrits spécifiquement pour cette solution de récupération après sinistre OAC. Les scripts présentés ci-dessous doivent être copiés dans n'importe quel sous-répertoire de l'instance de calcul agissant en tant que noeud de contrôle de récupération après sinistre pour OAC

Le lien ci-dessus doit être résolu vers le référentiel GitHub :

1. Cela indique le chemin du référentiel où se trouvent les scripts bash sur GitHub.
2. Affiche le référentiel contenant les scripts bash.

Figure 2-4 : Capture d'écran du référentiel github contenant des scripts bash pour OAC

Tâche 1.4 : déployer Oracle Analytics Cloud pour la récupération après sinistre

Déployez Oracle Analytics Cloud pour la récupération après sinistre dans les régions OCI à l'aide des instructions détaillées fournies dans les documents suivants :

1. Blog Oracle expliquant la solution : Plan de récupération après sinistre pour Oracle Analytics Cloud à l'aide de la méthode de permutation manuelle.
2. Livre technique Oracle rédigé par l'ingénierie OAC : Disaster Recovery Configuration for Oracle Analytics Cloud.
3. Architecture de référence Oracle Architecture Center écrite par les architectes cloud Data Platform : Concevoir une topologie de récupération après sinistre Oracle Analytics Cloud avec Full Stack Disaster Recovery Service.

Tâche 1.5 : tester manuellement la récupération d'Oracle Analytics Cloud

Il est recommandé de s'assurer que les étapes de récupération manuelle Les étapes manuelles de récupération d'OAC décrites dans Configuration de récupération après sinistre pour Oracle Analytics Cloud doivent être effectuées avant de pouvoir utiliser la récupération après sinistre de la pile complète.

Tâche 1.6 : étapes suivantes

Revenez à ce document pour commencer à utiliser Full Stack DR une fois les exigences suivantes remplies.

1. Déployez manuellement OAC pour la récupération après sinistre dans deux régions OCI souhaitées.
2. Testez manuellement toutes les étapes de récupération de la région 1 (Ashburn) à la région 2 (Phoenix).
3. Testez manuellement toutes les étapes de récupération de la région 2 (Phoenix) à la région 1 (Ashburn).

Tâche 2 : préparation de la récupération après sinistre de la pile complète

Full Stack DR n'est impliqué dans aucune partie de cette étape. Les étapes suivantes préparent la location, le compartiment, les services OCI et OAC pour une récupération automatisée par Full Stack DR.

Tâche 2.1 : créer des stratégies IAM pour la récupération après sinistre de la pile complète

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

• Stratégies Full Stack Disaster Recovery.
• Configuration des stratégies Identity and Access Management (IAM) nécessaires pour Full Stack Disaster Recovery.

Tâche 2.2 : créer des stratégies IAM pour d'autres services gérés par Full Stack DR

Full Stack DR doit pouvoir contrôler et gérer d'autres services OCI clés tels que le calcul, la mise en réseau, le stockage, les coffres, les bases de données et d'autres services divers. Configurez les stratégies OCI IAM requises pour les autres services, comme expliqué dans le document suivant.

• Stratégies pour les autres services gérés par Full Stack Disaster Recovery.

Tâche 2.3 : créer des buckets de stockage pour les journaux DRPG

Remarque : ignorez entièrement la tâche 2.3 si vous ajoutez OAC à des groupes de protection de récupération après sinistre existants.

Créez des buckets Object Storage dans les régions principale et de secours pour stocker les journaux générés par Full Stack DR lors des opérations de récupération : Object Storage.

Tâche 2.3.1 : accéder à OCI Object Storage

Commencez par accéder à Object Storage et Archive Storage comme illustré à la figure 2-1 ci-dessous

1. Assurez-vous que le contexte du navigateur est défini sur la région 1 (Ashburn).
2. Sélectionner un stockage.
3. Sélectionnez Buckets.

Figure 2-1 : Accéder au stockage d'objets

Tâche 2.3.2 : bucket de stockage OCI dans la région 1

Créez un bucket de stockage d'objet dans la région 1. Le bucket sera affecté au groupe de protection de récupération après sinistre de la région 1 lors d'une étape ultérieure.

1. Sélectionnez le compartiment contenant les ressources associées à OAC.
2. Sélectionnez Create Bucket.
3. Attribuez au bucket un nom significatif qui identifie facilement l'application et le but qu'il sert. Il n'y a aucune raison d'inclure la région dans le nom. Par exemple, ce nom indique qu'il est utilisé pour les journaux de récupération après sinistre de la pile complète liés aux opérations de récupération après sinistre pour OAC.
4. Utilisez la valeur par défaut pour le niveau et le cryptage.
5. Sélectionnez Create pour créer le bucket.

Figure 2-2 : Créer un bucket de stockage d'objet dans la région 1

Tâche 2.3.3 : bucket de stockage OCI dans la région 2

Suivez la même procédure pour créer un bucket de stockage d'objet dans la région 2 (Phoenix). Le bucket sera affecté au groupe de protection de récupération après sinistre de la région 2 lors d'une étape ultérieure.

1. Remplacez le contexte par la région 2.
2. Sélectionnez le compartiment contenant les ressources associées à OAC dans la région 2.
3. Utilisez le même nom exact que celui qui a été affecté au bucket dans la région 1, ce qui facilitera l'identification lors d'une étape ultérieure.
4. Sélectionnez Create pour créer le bucket.

Figure 2-3 : Créer un bucket de stockage d'objet dans la région 2

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

Remarque : ignorez entièrement la tâche 3 si OAC est ajouté aux groupes de protection de récupération après sinistre existants.

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 3.1 : accéder aux groupes de protection de récupération après sinistre

Commencez par accéder aux groupes de protection de récupération après sinistre (récupération après sinistre de la pile complète), comme indiqué dans la figure 3-1 ci-dessous.

1. Assurez-vous que le contexte de région OCI est défini sur la région 1 (Ashburn).
2. Sélectionnez Migration & Disaster Recovery.
3. Sélectionnez DR Protection Groups.

Figure 3-1 : Accéder aux groupes de protection de récupération après sinistre

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

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 3-2 ci-dessous. Le pair, le rôle et les membres seront affectés dans les étapes suivantes.

1. Sélectionnez le compartiment où créer le DRPG. Il peut s'agir du compartiment dans lequel les ressources OAC existent ou, dans ce cas, d'un compartiment agissant en tant que référentiel contenant des DRPG pour de nombreux systèmes métier différents.
2. Sélectionnez Create DR protection group pour ouvrir la boîte de dialogue.

Figure 3-2 : Commencer à créer un groupe de protection de récupération après sinistre dans la région 1

Ajoutez un nom et un bucket de stockage d'objet pour les journaux, comme indiqué dans la figure 3-3 ci-dessous.

1. Utilisez un nom simple et significatif pour DRGP ; cet exemple montre le nom du système métier et de la région.
2. Sélectionnez le bucket de stockage d'objet créé dans la tâche 2 pour la région 1.

Figure 3-3 : 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 3.3 : créer un groupe de protection dans la région 2

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 3-4 ci-dessous. Le pair, le rôle et les membres seront affectés dans les étapes suivantes.

1. Remplacez le contexte de région OCI par la région 2.
2. Sélectionnez le compartiment où créer le DRPG. Il peut s'agir du compartiment dans lequel les ressources OAC existent ou, dans ce cas, d'un compartiment agissant en tant que référentiel contenant des DRPG pour de nombreux systèmes métier différents.
3. Sélectionnez Create DR protection group pour ouvrir la boîte de dialogue

Figure 3-4 : Commencer à créer un groupe de protection de récupération après sinistre dans la région 2

Ajoutez un nom et un bucket de stockage d'objet pour les journaux, comme indiqué dans la figure 3-5 ci-dessous.

1. Utilisez un nom simple et significatif pour DRGP ; cet exemple montre le nom du système métier et de la région.
2. Sélectionnez le bucket de stockage d'objet créé dans la tâche 2 pour la région 2

Figure 3-5 : 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 3.4 : associer des groupes de protection dans la région 1 et la région 2

Associez les DRPG de chaque région en tant qu'homologues et affectez les rôles homologues de la base principale et de la base de données de secours. C'est ainsi que Full Stack DR saura quelles deux régions fonctionnent ensemble pour la récupération OAC. Les rôles de la base de données principale et de la base de données de secours sont automatiquement modifiés par 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.

Tâche 3.4.1 : démarrer l'association

1. Assurez-vous que le contexte de région OCI est défini sur la région 1 (Ashburn).
2. Sélectionnez Associer pour lancer le processus.

Figure 3-6 : Début de l'association DRPG

Tâche 3.4.2 : associer des groupes de protection dans la région 1 et la région 2

Indiquez les paramètres comme indiqué dans la figure 3-7 ci-dessous.

1. Sélectionnez le rôle principal. Full Stack DR affectera automatiquement le rôle de secours à la région 2.
2. Sélectionnez la région 2 (Phoenix) dans laquelle l'autre DRPG a été créé.
3. Sélectionnez le DRPG homologue dans lequel il a été créé.

Figure 3-7 : Paramètres nécessaires pour associer les DRPG

Tâche 3.4.3 : Ce que vous devez voir une fois l'association terminée

Full Stack DR affichera quelque chose comme la figure 3-8 ci-dessous une fois l'association terminée.

1. Le DRPG homologue principal actuel est Ashburn (région 1).
2. Le DRPG homologue de secours actuel est Phoenix (région 2).

Figure 3-8 : Montrer la relation entre pairs du point de vue DRPG individuel

Les mêmes informations peuvent être trouvées chaque fois que le contexte/la vue est d'un point de vue global montrant tous les groupes de protection de récupération après sinistre, comme le montre la figure 3-9 ci-dessous.

1. Le DRPG homologue principal actuel est Ashburn (région 1).
2. Le DRPG homologue de secours actuel est Phoenix (région 2).

Figure 3-9 : Montrer la relation entre pairs du point de vue DRPG global

Tâche 4 : ajouter des membres aux groupes de protection de récupération après sinistre

Remarque : cette étape supprimera tous les plans de récupération après sinistre existants dans les deux régions lors de l'ajout de membres aux groupes de protection de récupération après sinistre existants. Full Stack DR ne peut pas enregistrer de copies ni effectuer de sauvegardes de groupes de protection de récupération après sinistre au moment de la rédaction de ce document. Assurez-vous d'avoir enregistré toutes les informations sur les groupes et étapes de plans de récupération après sinistre dans un fichier texte ou une feuille de calcul pour vous aider à recréer les étapes et les groupes de plans personnalisés définis par l'utilisateur. Vous pouvez également créer des scripts bash qui appellent des commandes Full Stack DR CLI pour recréer les étapes et les groupes de plans personnalisés définis par l'utilisateur (cette opération dépasse le cadre de ce tutoriel).

Ajoutez la base de données et le noeud de contrôle de récupération après sinistre en tant que membres des groupes de protection de récupération après sinistre. Le noeud de contrôle de récupération après sinistre est une instance de calcul que vous avez créée uniquement pour contrôler OAC, ou une instance de calcul qui fait partie de la pile d'applications à gérer avec la récupération après sinistre de la pile complète.

Vous allez ajouter les ressources suivantes au DRPG principal dans la région 1 :

1. le noeud de contrôle DR,
2. Groupe de volumes contenant le volume d'initialisation du noeud de contrôle de récupération après sinistre,
3. La principale solution Autonomous Data Warehouse.

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

Commencez par sélectionner le DRPG dans la région 1 comme le montre la figure 4-1 ci-dessous.

1. Assurez-vous que le contexte de région OCI est la région 1 (Ashburn).
2. Sélectionnez le DRPG dans la région 1.
3. Sélectionnez Membres.
4. Cliquez sur Add Member pour lancer le processus.

Figure 4-1 : Comment commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 1

Tâche 4.1.1 : ajouter une instance de calcul pour le noeud de récupération après sinistre

Ajoutez une instance de calcul pour le noeud de contrôle de récupération après sinistre comme indiqué dans la figure 4-2 ci-dessous.

1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Sélectionnez Compute as member resource type.
3. Sélectionnez l'instance de calcul à utiliser pour le noeud de contrôle de récupération après sinistre.
4. Sélectionnez l'instance mobile.
5. Indiquez à Full Stack DR le VCN et le sous-réseau à affecter aux VNIC de la région 2 lors d'une récupération. La figure 4-2 présente une carte VNIC unique. Full Stack DR ne se soucie pas du nombre de cartes d'interface réseau virtuelles dont vous disposez ou de leur configuration dans l'une ou l'autre région. Spécifiez ce dont vous avez besoin pour répondre à vos besoins.

Figure 4-2 : Paramètres nécessaires pour ajouter un noeud de contrôle de récupération après sinistre

Tâche 4.1.2 : ajouter un groupe de volumes de blocs pour le noeud de récupération après sinistre

Ajoutez le groupe de volumes de blocs contenant l'initialisation pour le noeud de contrôle de récupération après sinistre. La réplication inter-région du groupe de volumes de blocs doit déjà être configurée entre les deux régions avant de l'ajouter au groupe de protection de récupération après sinistre.

1. Sélectionnez le groupe de volumes comme type de ressource membre.
2. Assurez-vous que le compartiment contenant le groupe de volumes est sélectionné, puis sélectionnez le groupe de volumes.

Figure 4-3 : Paramètres nécessaires pour ajouter un groupe de volumes d'initialisation pour le noeud de contrôle de récupération après sinistre

Tâche 4.1.3 : ajouter une instance Autonomous Data Warehouse principale

Autonomous Data Guard doit déjà être configuré pour Autonomous Data Warehouse (ADW) à ce stade dans le cadre de la tâche 1. Ajoutez ADW principal en tant que membre du DRPG dans la région 1.

1. Sélectionnez la base de données autonome en tant que type de ressource membre.
2. Assurez-vous que le compartiment contenant ADW est sélectionné, puis sélectionnez l'instance ADW principale pour OAC.

Figure 4-4 : Paramètres nécessaires à l'ajout d'ADW principal

Tâche 4.1.4 : vérifier les ressources membres pour la région 1

Le DRPG pour la région 1 devrait avoir trois ressources membres au minimum, comme le montre la figure 4-5 ci-dessous. Les noms de vos ressources membres seront différents.

1. ADW principal.
2. Instance de calcul mobile et groupe de volumes de blocs pour l'instance de calcul désignée pour agir sur le noeud de contrôle de récupération après sinistre OAC.

Figure 4-5 : Affichage des membres de DRPG dans la région 1

Tâche 4.2 : commencer à ajouter des membres à DRPG dans la région 2

Vous allez ajouter les ressources suivantes au DRPG principal dans la région 2 :

1. Autonomous Data Warehouse (ADW) de secours/distant.

Commencez par sélectionner le DRPG dans la région 2 comme le montre la figure 4-6 ci-dessous.

1. Assurez-vous que le contexte de région OCI est la région 2 (Phoenix).
2. Sélectionnez le DRPG dans la région 2.
3. Sélectionnez Membres.
4. Cliquez sur Add Member pour lancer le processus.

Figure 4-6 : Comment commencer à ajouter des membres au groupe de protection de récupération après sinistre dans la région 2

Tâche 4.2.1 : ajouter une instance Autonomous Data Warehouse de secours

Ajoutez ADW de secours en tant que membre du DRPG dans la région 2, comme le montre la figure 4-7 ci-dessous.

1. Remplacez le contexte de région OCI par la région 2 (Phoenix).
2. Sélectionnez le DRPG créé dans la tâche 3.3.

Figure 4-7 : Paramètres nécessaires à l'ajout d'ADW de secours

Tâche 4.2.2 : vérifier les ressources des membres pour la région 2

Le DRPG pour la région 2 doit avoir une ressource membre au minimum, comme le montre la figure 4-8 ci-dessous. Le nom de vos ressources membres sera différent.

1. ADW de secours/distante.

Figure 4-8 : Affichage du membre unique de DRPG dans la région 2

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

Cette étape crée des plans de permutation et de basculement de base associés au groupe de protection de récupération après sinistre de secours dans la région 2 (Phoenix).

Chaque plan a pour objet de faire passer la charge globale de la région principale 1 à la région de secours 2. Les rôles des groupes de protection de récupération après sinistre dans les deux régions sont automatiquement inversés dans le cadre de toute opération de récupération après sinistre. Par conséquent, le groupe de protection de la région 1 deviendra le groupe de secours et le groupe de protection de la région 2 deviendra le groupe principal après un basculement ou une permutation.

Full Stack DR préremplit les deux plans avec des étapes intégrées en fonction des ressources membres ajoutées à l'étape précédente. Les plans seront personnalisés dans les étapes suivantes pour gérer toutes les tâches liées à OAC au cours d'une opération de récupération.

Les plans de permutation sont toujours créés dans le groupe de protection avec le rôle de secours ; la région 2 est actuellement le groupe de protection de secours, nous allons donc commencer à Phoenix.

Tâche 5.1 : commencer à 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, comme le montre la figure 5-1 ci-dessous.

1. Assurez-vous que le contexte de région OCI est la région 2 (Phoenix).
2. Sélectionnez le DRPG de secours dans la région 2.
3. Sélectionner des plans.
4. Cliquez sur Créer un plan pour lancer le processus.

Figure 5-1 : Comment commencer à créer des plans de récupération après sinistre de base dans la région 2

Tâche 5.1.1 : créer un plan de permutation

La création d'un plan de récupération après sinistre est simple, comme le montre la figure 5-2 ci-dessous.

1. Rendre le nom du plan de permutation simple mais significatif. Le nom doit ê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. Choisissez le type de plan. Il n'existe que deux types de plan au moment de la rédaction de ce document.

Figure 5-2 : Paramètres nécessaires à la création d'un plan de permutation de récupération après sinistre

Tâche 5.1.2 : Créer un plan de basculement

Suivez la même procédure pour créer un plan de basculement de base, comme illustré à la figure 5-3 ci-dessous.

1. Rendre le nom du plan de basculement simple mais significatif. Le nom doit ê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. Choisissez le type de plan. Il n'existe que deux types de plan au moment de la rédaction de ce document.

Figure 5-3 : 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 indiqué ci-dessous. Ils géreront la transition des charges globales 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 à une étape ultérieure.

Figure 5-4 : Affichage des deux plans de récupération après sinistre de base qui doivent exister dans la région 2 avant de continuer

Tâche 6 : personnaliser le plan de permutation dans la région 2 (Phoenix)

Les plans de récupération après sinistre de base créés dans la tâche 5 contiennent des étapes préremplies pour les tâches de récupération intégrées à Full Stack DR et ne contiennent rien pour gérer les tâches de récupération propres à OAC. Cette étape 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 à suivre pour gérer les opérations à effectuer lors d'une permutation pour OAC :

1. Arrêtez OAC dans la région principale 1 en cours avant d'arrêter des machines virtuelles.
2. Démarrez OAC dans la région de secours en cours 2 après le lancement de machines virtuelles.
3. Récupérez le cliché périodique dans la région de secours 2. L'instantané périodique a été configuré dans le cadre de la tâche 1.4 ci-dessus.
4. Modifiez le travail cron d'instantané dans la région de secours 2. La tâche cron a été configurée dans le cadre de la tâche 1.4 ci-dessus.

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

Commencez par accéder au plan de permutation créé à l'étape précédente.

Figure 6-1 : Commencer à personnaliser le plan de permutation dans la région 2

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

Deux groupes de plans sont désactivés par défaut dans les plans de permutation, comme illustré dans la capture d'écran ci-dessous. Ils sont désactivés pour fournir un niveau de confort pendant le test que rien n'est réellement supprimé et que vous avez toujours une copie viable des artefacts en tant que sauvegarde en cas de problème lors du test.

Toutefois, ces deux groupes de plans interrompent (suppriment) les artefacts qui ne seront plus jamais utilisés dans le cadre d'une opération de récupération après sinistre à l'avenir. Les artefacts continueront tout simplement à s'accumuler au fil du temps au fur et à mesure que vous basculerez entre les deux régions, ce qui créera une confusion quant aux instances de calcul et aux groupes de volumes qui doivent réellement être actifs.

Ces groupes de plans doivent être activés une fois la reconfiguration dynamique Full Stack mise en production. Tous les artefacts qui ont été laissés en place lors des tests de permutation et de permutation alors que ces deux groupes de plans étaient désactivés doivent être arrêtés et nettoyés avant d'entrer en production afin de réduire la confusion et le risque d'erreur humaine pendant les opérations normales.

Vous pouvez éventuellement activer ces groupes de plans maintenant pour éviter d'avoir à nettoyer manuellement les artefacts superflus avant de passer en production.

Figure 6-2 : Groupes de plans désactivés par défaut

Lorsque les groupes de plans désactivés sont activés, procédez comme suit :

1. Ce groupe de plans met fin aux artefacts des instances de calcul laissés en arrière à la région 1 après le lancement des versions répliquées des machines virtuelles à la région 2 lors de l'opération de stockage de blocs OCI pour inverser la réplication de la région 2 à la région 1 dans le cadre de la permutation. Les machines virtuelles restantes ne sont pas utilisées lors d'une permutation car l'opération d'inversion de la réplication de volume de blocs crée toutes les nouvelles machines virtuelles dans de nouveaux groupes de volumes de blocs.

2. Ce groupe de plans met fin aux artefacts des groupes de volumes de blocs laissés en arrière à la région 1 une fois que les versions répliquées des groupes de volumes virtuels ont été activées à la région 2 et que la réplication de groupe de volumes a été inversée pendant la permutation. Les groupes de volumes de blocs restants ne sont plus jamais utilisés, même dans le cadre d'une permutation de la région 2 vers la région 1.

Tâche 6.2.1 : activer l'interruption du groupe de plans de calcul

Activez le groupe de plans.

1. Sélectionnez Enable all steps (Activer toutes les étapes) dans le menu contextuel à droite du nom du groupe de plans.

Figure 6-3 : Procédure d'activation de la terminaison d'instances de calcul

Tâche 6.2.2 Activer la terminaison du groupe de plans de groupes de volumes

Activez le groupe de plans.

1. Sélectionnez Enable all steps (Activer toutes les étapes) dans le menu contextuel à droite du nom du groupe de plans.

Figure 6-4 : Procédure d'activation de la terminaison de groupes de volumes

Tâche 6.3 : créer un groupe de plans pour arrêter OAC dans la région 1 (principale)

Commencez maintenant à ajouter des groupes de plans de récupération après sinistre personnalisés définis par l'utilisateur.

Le premier groupe de plans défini par l'utilisateur arrête l'exécution d'OAC dans la région principale 1. Ce groupe de plans contient une étape unique qui appelle le script bash oac-start-stop.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.4.

Tâche 6.3.1 : sélectionnez Add Plan Group.

Commencez le processus d'ajout d'un groupe de protocoles.

1. Cliquez sur Ajouter un groupe pour commencer.

Figure 6-5 : Commencer à ajouter un groupe de plans pour arrêter OAC

Tâche 6.3.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous venons d'ajouter une seule étape pour exécuter un script bash afin d'arrêter OAC.

1. Attribuez un nom simple mais descriptif au groupe de plans. Cette option est bien sûr facultative, mais il est recommandé d'ajouter une note sur la région dans laquelle le groupe de plans exécutera les étapes. Dans ce cas, il s'agit de la région principale. Nous avons donc ajouté "(Principal)" au nom du groupe.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur avant le groupe de plans intégré qui arrête les machines virtuelles à la région 1.
3. Sélectionnez le groupe de plans Arrêter les instances de calcul (principales) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant d'arrêter OAC.

Figure 6-6 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour arrêter OAC

Tâche 6.3.3 : Indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il arrêtera OAC à la région 1.

Nous allons expliquer tous les champs de cette boîte de dialogue, mais ne tenez pas compte de ces détails dans toutes les captures d'écran restantes dans les étapes suivantes, car nous ne faisons que répéter le même processus.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter OAC. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
3. La valeur par défaut avant que Full Stack DR ne déclare une défaillance est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
4. Sélectionnez toujours la région dans laquelle le noeud de contrôle de récupération après sinistre est en cours d'exécution, non dans laquelle il sera en cours d'exécution lors d'une permutation. Full Stack DR gardera une trace de l'emplacement d'exécution de la machine virtuelle. Il vous suffit donc de spécifier son emplacement actuel. Dans ce cas, le noeud de contrôle de récupération après sinistre est en cours d'exécution dans la région 1 (Ashburn).
5. Sélectionnez Exécuter le script local pour informer Full Stack DR que le script sera trouvé sur une instance de calcul. Les scripts bash ont été téléchargés sur le noeud de contrôle de récupération après sinistre dans la tâche 1.3.
6. Sélectionnez le compartiment correct qui contient le noeud de contrôle de récupération après sinistre. Il peut s'agir de n'importe quel compartiment. Sélectionnez l'instance de calcul désignée comme noeud de contrôle de récupération après sinistre (il peut s'agir d'un serveur d'applications ou d'une machine virtuelle créé uniquement pour ce projet/tutoriel).
7. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez stop comme premier paramètre et l'ID de région OCI comme deuxième.
8. Indiquez opc en tant qu'utilisateur pour exécuter le script.
9. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-7 : Paramètres permettant de créer l'étape de plan pour arrêter OAC

Tâche 6.3.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape d'arrêt d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré aux figures 6 à 8 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée. Il est possible d'ajouter des étapes supplémentaires à un groupe de plans de récupération après sinistre, mais ce groupe inclut uniquement l'étape permettant d'arrêter OAC.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 6-8 : Finaliser l'ajout d'un groupe de plans et d'une étape pour arrêter OAC

Tâche 6.4 : créer un groupe de plans pour démarrer OAC dans la région 2 (en veille)

Le second groupe de plans défini par l'utilisateur démarre OAC après le lancement du noeud de contrôle de récupération après sinistre dans la région de secours 2. Ce groupe de plans contient une étape unique qui appelle le script bash oac-start-stop.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.3.

Tâche 6.4.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 6-9 : Commencer à ajouter un groupe de plans pour démarrer OAC en standby

Tâche 6.4.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour démarrer OAC.

1. Attribuez un nom simple mais descriptif au groupe de plans. Il est toujours recommandé d'ajouter "(Standby)" au nom du groupe afin de déterminer clairement la région dans laquelle les étapes s'appliquent en un coup d'œil.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui lance la version répliquée du noeud de contrôle de récupération après sinistre dans la région 2
3. Sélectionnez le groupe de plans Lancer les instances de calcul (de secours) intégré
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 6-10 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer OAC en standby

Tâche 6.4.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il démarrera OAC à la région 2.

Tout dans cette étape est identique à la tâche 6.3.3, à l'exception des éléments présentés dans la figure 6-11 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez start en tant que premier paramètre et OCI region ID en tant que deuxième.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-11 : Paramètres permettant de créer l'étape de plan pour démarrer OAC en standby

Tâche 6.4.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape de démarrage d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré aux figures 6 à 12 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 6-12 : Finaliser l'ajout d'un groupe de plans et d'une étape pour démarrer OAC en standby

Tâche 6.5 : créer un groupe de plans pour récupérer le cliché dans la région 2 (en veille)

Une tâche cron a été configurée sur le noeud de contrôle de récupération après sinistre dans le cadre de la tâche 1.4. Le travail cron appelle un script bash nommé oac-create-snapshot.sh chargé d'exporter un cliché des données OAC de la région 1 et de l'enregistrer dans le bucket de stockage d'objet de la région de secours 2. La tâche cron et les buckets ont également été créés dans la tâche 1.4.

Le troisième groupe de plans défini par l'utilisateur récupère OAC dans la région de secours 2 à l'aide du cliché périodique répliqué à partir du bucket de stockage d'objet de la région 1 vers la région 2. Ce groupe de plans contient une étape unique qui appelle le script bash oac-register-snapshot.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.3.

Tâche 6.5.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 6-13 : Commencer à ajouter un groupe de plans pour récupérer le cliché sur la base de secours

Tâche 6.5.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour récupérer OAC dans la région de secours 2.

1. Attribuez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, insérez le groupe de plans défini par l'utilisateur après le groupe de plans défini par l'utilisateur créé dans la tâche précédente pour démarrer OAC.
3. Sélectionnez le groupe de plans Démarrer OAC (de secours) intégré
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de récupérer le cliché OAC.

Figure 6-14 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour récupérer le cliché OAC en standby

Tâche 6.5.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il récupère l'instantané OAC dans la région 2. Le cliché est pris dans la région principale pendant les opérations normales et stocké dans un bucket de stockage d'objets dans la région 2.

Tout dans cette tâche est identique à la tâche 6.3.3, à l'exception des éléments présentés dans la figure 6-15 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez l'ID de région OCI comme seul paramètre (PHX dans cet exemple).
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-15 : Paramètres de création de l'étape de plan pour la récupération du cliché en standby

Tâche 6.5.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape de récupération d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré aux figures 6 à 16 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 6-16 : Finaliser l'ajout d'un groupe de plans et d'une étape pour récupérer le cliché sur la base de données de secours

Tâche 6.6 : créer un groupe de plans pour inverser le cliché dans la région 2 (en veille)

Le dernier groupe de plans défini par l'utilisateur modifiera la tâche cron décrite dans la tâche 6.5 ci-dessus. Full Stack DR appelle oac-chg-cronjob.sh pour modifier le travail cron afin d'enregistrer l'instantané OAC exporté dans le bucket de stockage de la région 1.

Tâche 6.6.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 6-17 : Commencer à ajouter un groupe de plans pour inverser la copie de cliché sur la base de secours

Tâche 6.6.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour inverser le cliché OAC vers la région 1.

1. Attribuez un nom simple mais descriptif au groupe de plans. Il est toujours recommandé d'ajouter "(Standby)" au nom du groupe afin de déterminer clairement la région dans laquelle les étapes s'appliquent en un coup d'œil.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui récupère le cliché OAC dans la région 2.
3. Sélectionnez le groupe de plans Récupérer le cliché OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 6-18 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour inverser la copie de cliché sur la base de données de secours

Tâche 6.6.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, le cliché OAC est inversé afin d'être enregistré dans la région 1, qui devient automatiquement la région de secours une fois la permutation terminée.

Tout dans cette tâche est identique à la tâche 6.3.3, à l'exception des éléments présentés dans la figure 6-19 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-chg-cronjob.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez la clé de région OCI pour la région 1 (iad dans cet exemple) en tant que premier paramètre et clé de région pour la région 2 (phx dans cet exemple) en tant que deuxième paramètre teh.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-19 : Paramètres permettant de créer l'étape de plan permettant d'inverser la copie de cliché sur la base de données de secours

Tâche 6.6.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape d'inversion du sens des instantanés OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré à la figure 6-20 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 6-20 : Finaliser l'ajout d'un groupe de plans et d'une étape pour inverser la copie de cliché sur la base de données de secours

Le plan de permutation doit désormais inclure les quatre groupes de plans de récupération après sinistre pour OAC, comme indiqué dans la capture d'écran ci-dessous. Vous pouvez disposer de groupes de plans supplémentaires si votre groupe de protection inclut d'autres applications ou services OCI avec OAC.

Figure 6-21 : Affichage des quatre groupes de plans définis par l'utilisateur ajoutés au plan de permutation

Tâche 7 : personnaliser le plan de basculement dans la région 2 (Phoenix)

Cette tâche explique comment ajouter des groupes de plans de récupération après sinistre personnalisés définis par l'utilisateur et les étapes permettant de gérer les opérations à effectuer lors d'un basculement pour OAC dans la région 2 lors d'une panne réelle ou d'une perte d'accès à la région 1. Il s'agit d'un sous-ensemble des étapes qui viennent d'être ajoutées au plan de permutation dans la tâche 6 ci-dessus. Toutefois, seules les étapes exécutées dans la région de secours 2 seront ajoutées au plan de basculement car il est supposé que la région 1 est complètement inaccessible lors d'un basculement.

1. Démarrez OAC dans la région de secours 2 après avoir lancé des machines virtuelles.
2. Récupérez le cliché périodique dans la région de secours 2. L'instantané périodique a été configuré dans le cadre de la tâche 1.4 ci-dessus.
3. Modifiez le travail cron d'instantané dans la région de secours 2. La tâche cron a été configurée dans le cadre de la tâche 1.4 ci-dessus.

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

Commencez par accéder au plan de basculement créé dans la tâche 5.

1. Assurez-vous que la région de secours 2 est toujours le contexte de région en cours dans la console.
2. Sélectionnez le plan de basculement.

Figure 7-1 : La création commence par la personnalisation du plan de basculement dans la région 2

Tâche 7.2 : sélectionnez Add Plan Group.

Le premier groupe de plans défini par l'utilisateur démarre l'exécution d'OAC dans la région de secours 2. Ce groupe de plans contient une étape unique qui appelle le script bash oac-start-stop.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.3.

1. Cliquez sur Ajouter un groupe pour commencer.

Figure 7-2 : Commencer à ajouter un groupe de plans pour démarrer OAC

Tâche 7.2.1 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous venons d'ajouter une seule étape pour exécuter un script bash afin de démarrer OAC.

1. Attribuez un nom simple mais descriptif au groupe de plans. Cette option est bien sûr facultative, mais il est recommandé d'ajouter une note sur la région dans laquelle le groupe de plans exécutera les étapes. Dans ce cas, il s'agit de la région de secours 2. Nous avons donc ajouté "(Standby)" au nom du groupe.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui lance les machines virtuelles répliquées dans la région 2
3. Sélectionnez le groupe de plans Lancer les instances de calcul (de secours) intégré
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 7-3 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer OAC

Tâche 7.2.2 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il démarrera le CAO à la région 2, comme le montre la figure 7-4 ci-dessous.

Nous allons expliquer tous les champs de cette boîte de dialogue, mais ne tenez pas compte de ces détails dans toutes les captures d'écran restantes dans les étapes suivantes, car nous ne faisons que répéter le même processus.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Le plan de récupération après sinistre doit s'arrêter si le script ne démarre pas OAC. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
3. La valeur par défaut avant que Full Stack DR ne déclare une défaillance est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
4. Sélectionnez toujours la région dans laquelle le noeud de contrôle de récupération après sinistre est en cours d'exécution, non dans laquelle il sera en cours d'exécution lors d'une permutation. Full Stack DR gardera une trace de l'emplacement d'exécution de la machine virtuelle. Il vous suffit donc de spécifier son emplacement actuel. Dans ce cas, le noeud de contrôle de récupération après sinistre est en cours d'exécution dans la région 1 (Ashburn).
5. Sélectionnez Exécuter le script local pour informer Full Stack DR que le script sera trouvé sur une instance de calcul. Les scripts bash ont été téléchargés sur le noeud de contrôle de récupération après sinistre dans la tâche 1.3.
6. Sélectionnez le compartiment correct qui contient le noeud de contrôle de récupération après sinistre. Il peut s'agir de n'importe quel compartiment. Sélectionnez l'instance de calcul désignée comme noeud de contrôle de récupération après sinistre (il peut s'agir d'un serveur d'applications ou d'une machine virtuelle créé uniquement pour ce projet/tutoriel).
7. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez start en tant que premier paramètre et OCI region ID en tant que deuxième.
8. Indiquez opc en tant qu'utilisateur pour exécuter le script.
9. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 7-4 : Paramètres permettant de créer l'étape de plan pour démarrer OAC en standby

Tâche 7.2.3 : terminer l'ajout du groupe de plans et de l'étape

L'étape de démarrage d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré aux figures 7 à 5 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 7-5 : Finaliser l'ajout d'un groupe de plans et d'une étape pour démarrer OAC

Tâche 7.3 : créer un groupe de plans pour récupérer le cliché dans la région 2 (en veille)

Le deuxième groupe de plans défini par l'utilisateur récupère OAC dans la région de secours 2 à l'aide du cliché périodique répliqué à partir du bucket de stockage d'objet de la région 1 vers la région 2. Il s'agit de la tâche 6 qui a été ajoutée au plan de permutation.

Tâche 7.3.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 7-6 : Commencer à ajouter un groupe de plans pour récupérer le cliché sur la base de secours

Tâche 7.3.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour récupérer OAC dans la région de secours 2.

1. Attribuez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, insérez le groupe de plans défini par l'utilisateur après le groupe de plans défini par l'utilisateur créé dans la tâche précédente pour démarrer OAC.
3. Sélectionnez le groupe de plans Démarrer OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de récupérer le cliché OAC.

Figure 7-7 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour récupérer le cliché OAC en standby

Tâche 7.3.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il récupère l'instantané OAC dans la région 2. Le cliché est pris dans la région principale pendant les opérations normales et stocké dans un bucket de stockage d'objets dans la région 2.

Tout dans cette tâche est identique à la tâche 7.3.2, à l'exception des éléments présentés dans la figure 7-8 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez l'ID de région OCI comme seul paramètre (PHX dans cet exemple).
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans

Figure 7-8 : Paramètres de création de l'étape de plan pour la récupération du cliché en standby

Tâche 7.3.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape de récupération d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 7-9 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 7-9 : Finaliser l'ajout d'un groupe de plans et d'une étape pour récupérer le cliché au niveau de la base de données de secours

Tâche 7.4 : créer un groupe de plans pour inverser le cliché dans la région 2 (en veille)

Le dernier groupe de plans défini par l'utilisateur modifiera le travail CRON, de sorte que le cliché OAC sera enregistré dans la région 1 une fois qu'il sera de nouveau accessible. Il s'agit de la même tâche qui a été ajoutée au plan de permutation dans la tâche 6.

Tâche 7.4.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 7-10 : Commencer à ajouter un groupe de plans pour inverser la copie de cliché sur la base de secours

Tâche 7.4.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour inverser le cliché OAC vers la région 1.

1. Attribuez un nom simple mais descriptif au groupe de plans. Il est toujours recommandé d'ajouter "(Standby)" au nom du groupe afin de déterminer clairement la région dans laquelle les étapes s'appliquent en un coup d'œil.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui récupère le cliché OAC dans la région 2.
3. Sélectionnez le groupe de plans Récupérer le cliché OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 7-11 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour inverser la copie de cliché sur la base de données de secours

Tâche 7.4.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, le cliché OAC est inversé afin d'être enregistré dans la région 1, qui devient automatiquement la région de secours une fois la permutation terminée.

Tout dans cette tâche est identique à la tâche 7.2.2, à l'exception des éléments présentés dans la figure 6-19 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-chg-cronjob.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez la clé de région OCI pour la région 1 (iad dans cet exemple) en tant que premier paramètre et clé de région pour la région 2 (phx dans cet exemple) en tant que deuxième paramètre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 7-12 : Paramètres permettant de créer l'étape de plan permettant d'inverser la copie de cliché sur la base de données de secours

Tâche 7.4.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape d'inversion du sens des instantanés OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré à la figure 7-13 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 7-13 : Finaliser l'ajout d'un groupe de plans et d'une étape pour inverser la copie de cliché sur la base de données de secours

Le plan de basculement doit désormais inclure les trois groupes de plans de récupération après sinistre pour OAC, comme indiqué dans la capture d'écran ci-dessous. Vous pouvez disposer de groupes de plans supplémentaires si votre groupe de protection inclut d'autres applications ou services OCI avec OAC.

Figure 7-14 : Affichage des trois groupes de plans définis par l'utilisateur ajoutés au plan de basculement

Tâche 8 : exécuter le plan de permutation dans la région 2 (Phoenix)

Les plans de reconfiguration dynamique de permutation et de basculement sont terminés dans la région de secours 2 (Phoenix). Les plans de récupération après sinistre de la région 2 permettent à Full Stack DR de faire passer les workloads de la région 1 à la région 2. La tâche suivante consiste à créer des plans de permutation et de basculement dans le groupe de protection pour la région 1 (Ashburn), afin que Full Stack DR puisse faire passer les charges globales de la région 2 à la région 1.

Toutefois, les plans de récupération après sinistre ne peuvent être créés et modifiés que dans le groupe de protection doté du rôle de secours. Le groupe de protection de récupération après sinistre de la région 1 est actuellement le groupe principal, ce qui signifie que les plans de récupération après sinistre ne peuvent pas être créés dans la région 1.

Par conséquent, nous devons inverser les rôles des groupes de protection afin que la région 1 soit la base de données de secours et la région 2 la base de données principale. Exécutez le plan de permutation qui vient d'être créé pour faire passer la charge globale de la région 1 (Ashburn) à la région 2 (Phoenix).

Tâche 8.1 : Lancer l'exécution du plan

Exécutez un plan de récupération après sinistre pour commencer le processus de transition de la charge globale OAC de la région 1 à la région 2.

1. Assurez-vous que le contexte de région est toujours défini sur la région de secours 2 (Phoenix).
2. Utilisez le chemin de navigation en haut de la console pour vous assurer que les détails du groupe de protection de récupération après sinistre correspondent au contexte de plan actuel.
3. 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 s'agir du rôle De secours.
4. Assurez-vous que les plans de basculement et de permutation existent avant de continuer. Sinon, revenez aux étapes précédentes pour créer les deux plans de récupération après sinistre.
5. Cliquez sur le bouton Execute DR plan.

Figure 8-1 : Montrer comment exécuter une permutation vers la région de secours

Tâche 8.2 : sélectionner un plan de basculement et exécuter

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

1. Sélectionnez le plan de permutation.
2. Vérifiez que l'option Activer les prévérifications est sélectionnée.
3. Cliquez sur le bouton Execute DR plan pour commencer.

Figure 8-2 : Choisir et exécuter le plan de permutation

Tâche 8.3 : étapes suivantes

Surveillez le plan de basculement jusqu'à ce que la charge globale OAC passe entièrement de la région 1 à la région 2. Full Stack DR s'occupe du nettoyage des artefacts et de la modification des rôles de la base principale et de la base de secours entre les régions.

La région 2 (Phoenix) sera la région principale et la région 1 (Ashburn) sera la région de secours une fois que Full Stack DR aura terminé la permutation.

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

Créez les mêmes plans de permutation et de basculement de base dans le groupe de protection de récupération après sinistre pour la région 1 (Ashburn), qui est désormais le pair de secours.

L'objectif de chaque plan est de faire passer la charge de travail de la région 2 à la région 1 chaque fois que la région 2 est le pair principal. Les rôles des groupes de protection de récupération après sinistre dans les deux régions sont automatiquement inversés dans le cadre de toute opération de récupération après sinistre. Par conséquent, le groupe de protection de la région 2 deviendra le groupe de secours et le groupe de protection de la région 1 deviendra le groupe principal après un basculement ou une permutation.

Full Stack DR préremplit les deux plans avec des étapes intégrées en fonction des ressources membres ajoutées à l'étape précédente. Les plans seront personnalisés dans les étapes suivantes pour gérer toutes les tâches liées à OAC au cours d'une opération de récupération.

Les plans de permutation sont toujours créés dans le groupe de protection avec le rôle de secours ; la région 1 est actuellement le groupe de protection de secours après l'exécution du plan de permutation dans la tâche 8.

Tâche 9.1 : commencer à 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 comme le montre la figure 9-1 ci-dessous.

1. Assurez-vous que le contexte de région OCI est la région 1 (Ashburn).
2. Sélectionnez le DRPG de secours dans la région 1.
3. Sélectionner des plans.
4. Cliquez sur Créer un plan pour lancer le processus.

Figure 9-1 : Comment commencer à créer des plans de récupération après sinistre de base dans la région 1

Tâche 9.1.1 : créer un plan de permutation

La création d'un plan de récupération après sinistre est simple, comme le montre la figure 9-2 ci-dessous.

1. Rendre le nom du plan de permutation simple mais significatif. Le nom doit ê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. Choisissez le type de plan. Il n'existe que deux types de plan au moment de la rédaction de ce document.

Figure 9-2 : Paramètres nécessaires à la création d'un plan de permutation de récupération après sinistre

Tâche 9.2 : Créer un plan de basculement

Suivez la même procédure pour créer un plan de basculement de base, comme illustré dans la figure 9-3 ci-dessous.

1. Rendre le nom du plan de basculement simple mais significatif. Le nom doit ê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. Choisissez le type de plan. Il n'existe que deux types de plan au moment de la rédaction de ce document.
3. Cliquez sur Créer pour créer un plan de basculement de base prérempli avec des étapes de base intégrées.

Figure 9-3 : 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 1 doit désormais disposer des deux plans de récupération après sinistre comme indiqué ci-dessous. Ils géreront la transition des charges globales de la région 2 vers la région 1.

Figure 9-4 : Affichage des deux plans de récupération après sinistre de base qui doivent exister dans la région 2 avant de continuer

Tâche 10 : personnaliser le plan de permutation dans la région 1 (Ashburn)

Tout ce qui concerne cette tâche est presque exactement le même que ce que nous avons fait dans la tâche 6 pour la région 2, sauf que cela se fait dans la région 1.

Les plans de récupération après sinistre de base créés dans la tâche 9 ne contiennent rien pour gérer les tâches de récupération propres à OAC. 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 à suivre pour gérer les opérations à effectuer lors d'une permutation pour OAC :

1. Arrêtez OAC dans la région principale 2 en cours avant d'arrêter des machines virtuelles.
2. Démarrez OAC dans la région de secours en cours 1 après avoir lancé des machines virtuelles.
3. Récupérez le cliché périodique dans la région de secours 1. L'instantané périodique a été configuré dans le cadre de la tâche 1.4 ci-dessus.
4. Modifiez le travail cron d'instantané dans la région de secours 1. La tâche cron a été configurée dans le cadre de la tâche 1.4 ci-dessus.

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

Commencez par accéder au plan de permutation créé à l'étape précédente.

Figure 10-1 : Commencer à personnaliser le plan de permutation dans la région 1

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

Il s'agit des mêmes étapes effectuées pour la région 2 dans une étape antérieure ; le même processus doit être suivi pour la région 1.

Deux groupes de plans sont désactivés par défaut dans les plans de permutation, comme illustré dans la capture d'écran ci-dessous. Ils sont désactivés pour fournir un niveau de confort pendant le test que rien n'est réellement supprimé, et vous avez toujours une copie viable des artefacts en tant que sauvegarde en cas de problème lors du test.

Toutefois, ces deux groupes de plans interrompent (suppriment) les artefacts qui ne seront plus jamais utilisés dans le cadre d'une opération de récupération après sinistre à l'avenir. Les artefacts continueront tout simplement à s'accumuler au fil du temps au fur et à mesure que vous basculerez entre les deux régions, ce qui créera de la confusion pour les humains quant aux instances de calcul et aux groupes de volumes qui doivent réellement être actifs.

Ces groupes de plans doivent être activés une fois la reconfiguration dynamique Full Stack mise en production. Tous les artefacts qui ont été laissés en place lors des tests de permutation et de permutation alors que ces deux groupes de plans étaient désactivés doivent être arrêtés et nettoyés avant d'entrer en production afin de réduire la confusion et le risque d'erreur humaine pendant les opérations normales.

Vous pouvez éventuellement activer ces groupes de plans maintenant pour éviter d'avoir à nettoyer manuellement les artefacts superflus avant de passer en production.

Figure 10-2 : Groupes de plans désactivés par défaut

Lorsque les groupes de plans désactivés sont activés, procédez comme suit :

1. Ce groupe de plans met fin aux artefacts des instances de calcul laissés en arrière à la région 2 après le lancement des versions répliquées des machines virtuelles à la région 1 lors de l'opération de stockage de blocs OCI pour inverser la réplication de la région 1 à la région 2 dans le cadre de la permutation. Les machines virtuelles restantes ne sont pas utilisées lors d'une permutation car l'opération d'inversion de la réplication de volume de blocs crée toutes les nouvelles machines virtuelles dans de nouveaux groupes de volumes de blocs.

2. Ce groupe de plans met fin aux artefacts des groupes de volumes de blocs laissés en arrière à la région 2 une fois que les versions répliquées des groupes de volumes virtuels ont été activées à la région 1 et que la réplication de groupe de volumes a été inversée pendant la permutation. Les groupes de volumes de blocs restants ne sont plus jamais utilisés, même dans le cadre d'une permutation de la région 1 vers la région 2.

Tâche 10.2.1 : activer l'interruption du groupe de plans de calcul

Activez le groupe de plans.

1. Sélectionnez Enable all steps (Activer toutes les étapes) dans le menu contextuel à droite du nom du groupe de plans.

Figure 10-3 : ow permettant de mettre fin aux instances de calcul

Tâche 10.2.2 Activer la terminaison du groupe de plans de groupes de volumes

Activez le groupe de plans.

1. Sélectionnez Enable all steps (Activer toutes les étapes) dans le menu contextuel à droite du nom du groupe de plans.

Figure 10-4 : Procédure d'activation de la terminaison de groupes de volumes

Tâche 10.3 : créer un groupe de plans pour arrêter OAC dans la région 2 (principale)

Commencez maintenant à ajouter des groupes de plans de récupération après sinistre personnalisés définis par l'utilisateur.

Le premier groupe de plans défini par l'utilisateur arrête l'exécution d'OAC dans la région principale 1. Ce groupe de plans contient une étape unique qui appelle le script bash oac-start-stop.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.4.

Tâche 10.3.1 : sélectionnez Add Plan Group.

Commencez le processus d'ajout d'un groupe de protocoles.

1. Cliquez sur Ajouter un groupe pour commencer.

Figure 10-5 : Commencer à ajouter un groupe de plans pour arrêter OAC

Tâche 10.3.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous venons d'ajouter une seule étape pour exécuter un script bash afin d'arrêter OAC.

1. Attribuez un nom simple mais descriptif au groupe de plans. Cette option est bien sûr facultative, mais il est recommandé d'ajouter une note sur la région dans laquelle le groupe de plans exécutera les étapes. Dans ce cas, il s'agit de la région principale. Nous avons donc ajouté "(Principal)" au nom du groupe.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur avant le groupe de plans intégré qui arrête les machines virtuelles à la région 2.
3. Sélectionnez le groupe de plans Arrêter les instances de calcul (principales) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant d'arrêter OAC.

Figure 10-6 : paramètres permettant de créer un groupe de plans et d'ajouter une étape pour arrêter OAC

Tâche 10.3.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il arrêtera OAC à la région 2.

Nous allons expliquer tous les champs de cette boîte de dialogue, mais ne tenez pas compte de ces détails dans toutes les captures d'écran restantes dans les étapes suivantes, car nous ne faisons que répéter le même processus.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter OAC. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
3. La valeur par défaut avant que Full Stack DR ne déclare une défaillance est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
4. Sélectionnez toujours la région dans laquelle le noeud de contrôle de récupération après sinistre est en cours d'exécution, non dans laquelle il sera en cours d'exécution lors d'une permutation. Full Stack DR gardera une trace de l'emplacement d'exécution de la machine virtuelle. Il vous suffit donc de spécifier son emplacement actuel. Dans ce cas, le noeud de contrôle de récupération après sinistre est en cours d'exécution dans la région 2 (Phoenix).
5. Sélectionnez Exécuter le script local pour informer Full Stack DR que le script sera trouvé sur une instance de calcul. Les scripts bash ont été téléchargés sur le noeud de contrôle de récupération après sinistre dans la tâche 1.3.
6. Sélectionnez le compartiment correct qui contient le noeud de contrôle de récupération après sinistre. Il peut s'agir de n'importe quel compartiment. Sélectionnez l'instance de calcul désignée comme noeud de contrôle de récupération après sinistre (il peut s'agir d'un serveur d'applications ou d'une machine virtuelle créé uniquement pour ce projet/tutoriel).
7. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez stop comme premier paramètre et l'ID de région OCI comme deuxième.
8. Indiquez opc en tant qu'utilisateur pour exécuter le script.
9. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 10-7 : Paramètres permettant de créer l'étape de plan pour arrêter OAC

Tâche 10.3.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape d'arrêt d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 10-8 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée. Il est possible d'ajouter des étapes supplémentaires à un groupe de plans de récupération après sinistre, mais ce groupe inclut uniquement l'étape permettant d'arrêter OAC.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 10-8 : Finaliser l'ajout d'un groupe de plans et d'une étape pour arrêter OAC

Tâche 10.4 : créer un groupe de plans pour démarrer OAC dans la région 1 (en veille)

Le second groupe de plans défini par l'utilisateur démarre OAC après le lancement du noeud de contrôle de récupération après sinistre dans la région de secours 2. Ce groupe de plans contient une étape unique qui appelle le script bash oac-start-stop.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.3.

Tâche 10.4.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 10-9 : Commencer à ajouter un groupe de plans pour démarrer OAC en standby

Tâche 10.4.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour démarrer OAC.

1. Attribuez un nom simple mais descriptif au groupe de plans. Il est toujours recommandé d'ajouter "(Standby)" au nom du groupe afin de déterminer clairement la région dans laquelle les étapes s'appliquent en un coup d'œil.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui lance la version répliquée du noeud de contrôle de récupération après sinistre dans la région 1.
3. Sélectionnez le groupe de plans Lancer les instances de calcul (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 10-10 : paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer OAC en standby

Tâche 10.4.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il démarrera OAC à la région 1.

Tout dans cette tâche est identique à la tâche 10.3.3, à l'exception des éléments présentés dans la figure 10-11 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez start en tant que premier paramètre et OCI region ID en tant que deuxième.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 10-11 : paramètres permettant de créer l'étape de plan pour démarrer OAC en mode veille

Tâche 10.4.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape de démarrage d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 10-12 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 10-12 : Finaliser l'ajout d'un groupe de plans et d'une étape pour démarrer OAC en standby

Tâche 10.5 : créer un groupe de plans pour récupérer le cliché dans la région 1 (en veille)

Le troisième groupe de plans défini par l'utilisateur récupère OAC dans la région de secours 1 à l'aide du cliché périodique répliqué à partir du bucket de stockage d'objet de la région 2 vers la région 1. Ce groupe de plans contient une étape unique qui appelle le script bash oac-register-snapshot.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.3.

Tâche 10.5.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 10-13 : Commencer à ajouter un groupe de plans pour récupérer le cliché sur la base de secours

Tâche 10.5.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour récupérer OAC dans la région de secours 1.

1. Attribuez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, insérez le groupe de plans défini par l'utilisateur après le groupe de plans défini par l'utilisateur créé à l'étape précédente pour démarrer OAC.
3. Sélectionnez le groupe de plans Démarrer OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de récupérer le cliché OAC.

Figure 10-14 : paramètres permettant de créer un groupe de plans et d'ajouter une étape de récupération du cliché OAC en standby

Tâche 10.5.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il récupère l'instantané OAC dans la région 1. Le cliché est pris dans la région principale pendant les opérations normales et stocké dans un bucket de stockage d'objets dans la région 1.

Tout dans cette tâche est identique à la tâche 10.3.3, à l'exception des éléments présentés dans la figure 10-15 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez l'ID de région OCI comme seul paramètre (PHX dans cet exemple).
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 10-15 : paramètres permettant de créer l'étape de plan pour la récupération du cliché en standby

Tâche 10.5.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape de récupération d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 10-16 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 10-16 : Finaliser l'ajout d'un groupe de plans et d'une étape pour récupérer le cliché sur la base de données de secours

Tâche 10.6 : créer un groupe de plans pour annuler le cliché dans la région 1 (en veille)

Le dernier groupe de plans défini par l'utilisateur modifiera la tâche cron décrite dans la tâche 10.5 ci-dessus. Full Stack DR appelle oac-chg-cronjob.sh pour modifier le travail cron afin d'enregistrer l'instantané OAC exporté dans le bucket de stockage de la région 2.

Tâche 10.6.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 10-17 : Commencer à ajouter un groupe de plans pour inverser la copie de cliché sur la base de secours

Tâche 10.6.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour inverser le cliché OAC vers la région 2.

1. Attribuez un nom simple mais descriptif au groupe de plans. Il est toujours recommandé d'ajouter "(Standby)" au nom du groupe afin de déterminer clairement la région dans laquelle les étapes s'appliquent en un coup d'œil.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui récupère le cliché OAC dans la région 1.
3. Sélectionnez le groupe de plans Récupérer le cliché OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 10-18 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour inverser la copie de cliché sur la base de données de secours

Tâche 10.6.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, le cliché OAC est inversé afin d'être enregistré dans la région 2, qui devient automatiquement la région de secours une fois la permutation terminée.

Tout dans cette tâche est identique à la tâche 10.3.3, à l'exception des éléments présentés dans la figure 10-19 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-chg-cronjob.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez la clé de région OCI pour la région 2 (phx dans cet exemple) en tant que premier paramètre et clé de région pour la région 1 (iad dans cet exemple) en tant que deuxième paramètre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 10-19 : Paramètres permettant de créer l'étape de plan permettant d'inverser la copie de cliché sur la base de données de secours

Tâche 10.6.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape d'inversion du sens des instantanés OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré à la figure 10-20 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

3.
Figure 10-20 : Finaliser l'ajout d'un groupe de plans et d'une étape pour inverser la copie de cliché sur la base de données de secours

Le plan de permutation doit désormais inclure les quatre groupes de plans de récupération après sinistre pour OAC, comme indiqué dans la capture d'écran ci-dessous. Vous pouvez disposer de groupes de plans supplémentaires si votre groupe de protection inclut d'autres applications ou services OCI avec OAC.

Figure 10-21 : Affichage des quatre groupes de plans définis par l'utilisateur ajoutés au plan de permutation

Tâche 11 : personnaliser le plan de basculement dans la région 1 (Ashburn)

Cette tâche explique comment ajouter des groupes de plans de récupération après sinistre personnalisés définis par l'utilisateur et les étapes permettant de gérer les opérations à effectuer lors d'un basculement pour OAC dans la région 1 lors d'une panne réelle ou d'une perte d'accès à la région 2. Il s'agit d'un sous-ensemble des étapes qui viennent d'être ajoutées au plan de permutation dans la tâche 10 ci-dessus. Toutefois, seules les étapes exécutées dans la région de secours 1 seront ajoutées au plan de basculement car il est supposé que la région 2 est complètement inaccessible lors d'un basculement.

1. Démarrez OAC dans la région de secours 1 après avoir lancé des machines virtuelles.
2. Récupérez le cliché périodique dans la région de secours 1. L'instantané périodique a été configuré dans le cadre de la tâche 1.4 ci-dessus.
3. Modifiez le travail cron d'instantané dans la région de secours 1. La tâche cron a été configurée dans le cadre de la tâche 1.4 ci-dessus.

Tâche 11.1 : créer un groupe de plans pour démarrer OAC dans la région 1 (en veille)

Commencez par accéder au plan de basculement créé dans la tâche 9.

1. Assurez-vous que la région de secours 1 est toujours le contexte de région en cours dans la console.
2. Sélectionnez le plan de basculement.

Figure 11-1 : Comment créer commence la personnalisation du plan de basculement dans la région 1

Tâche 11.2 : sélectionnez Add Plan Group.

Le premier groupe de plans défini par l'utilisateur démarre l'exécution d'OAC dans la région de secours 1. Ce groupe de plans contient une étape unique qui appelle le script bash oac-start-stop.sh téléchargé vers le noeud de contrôle de récupération après sinistre dans la tâche 1.3.

1. Cliquez sur Ajouter un groupe pour commencer.

Figure 11-2 : Commencer à ajouter un groupe de plans pour démarrer OAC

Tâche 11.2.1 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous venons d'ajouter une seule étape pour exécuter un script bash afin de démarrer OAC.

1. Attribuez un nom simple mais descriptif au groupe de plans. Cette option est bien sûr facultative, mais il est recommandé d'ajouter une note sur la région dans laquelle le groupe de plans exécutera les étapes. Dans ce cas, il s'agit de la région de secours 1. Nous avons donc ajouté "(Standby)" au nom du groupe.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui lance les machines virtuelles répliquées dans la région 1
3. Sélectionnez le groupe de plans Lancer les instances de calcul (de secours) intégré
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 11-3 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer OAC

Tâche 11.2.2 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il démarrera le CAO à la région 2, comme le montre la figure 7-4 ci-dessous.

Nous allons expliquer tous les champs de cette boîte de dialogue, mais ne tenez pas compte de ces détails dans toutes les captures d'écran restantes dans les étapes suivantes, car nous ne faisons que répéter le même processus.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Le plan de récupération après sinistre doit s'arrêter si le script ne démarre pas OAC. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
3. La valeur par défaut avant que Full Stack DR ne déclare une défaillance est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
4. Sélectionnez toujours la région dans laquelle le noeud de contrôle de récupération après sinistre est en cours d'exécution, non dans laquelle il sera en cours d'exécution lors d'une permutation. Full Stack DR gardera une trace de l'emplacement d'exécution de la machine virtuelle. Il vous suffit donc de spécifier son emplacement actuel. Dans ce cas, le noeud de contrôle de récupération après sinistre est en cours d'exécution dans la région 2 (Phoenix).
5. Sélectionnez Exécuter le script local pour informer Full Stack DR que le script sera trouvé sur une instance de calcul. Les scripts bash ont été téléchargés sur le noeud de contrôle de récupération après sinistre dans la tâche 1.3.
6. Sélectionnez le compartiment correct qui contient le noeud de contrôle de récupération après sinistre. Il peut s'agir de n'importe quel compartiment. Sélectionnez l'instance de calcul désignée comme noeud de contrôle de récupération après sinistre (il peut s'agir d'un serveur d'applications ou d'une machine virtuelle créé uniquement pour ce projet/tutoriel).
7. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez start en tant que premier paramètre et OCI region ID en tant que deuxième.
8. Indiquez opc en tant qu'utilisateur pour exécuter le script.
9. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans

Figure 11-4 : Paramètres permettant de créer l'étape de plan pour démarrer OAC en standby

Tâche 11.2.3 : terminer l'ajout du groupe de plans et de l'étape

L'étape de démarrage d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 11-5 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 11-5 : Finaliser l'ajout d'un groupe de plans et d'une étape pour démarrer OAC

Tâche 11.3 : créer un groupe de plans pour récupérer le cliché dans la région 1 (en veille)

Le deuxième groupe de plans défini par l'utilisateur récupère OAC dans la région de secours 1 à l'aide du cliché périodique répliqué à partir du bucket de stockage d'objet de la région 2 vers la région 1. Il s'agit de la tâche 9 qui a été ajoutée au plan de permutation.

Tâche 11.3.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 11-6 : Commencer à ajouter un groupe de plans pour récupérer le cliché sur la base de secours

Tâche 11.3.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour récupérer OAC dans la région de secours 1.

1. Attribuez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, insérez le groupe de plans défini par l'utilisateur après le groupe de plans défini par l'utilisateur créé à l'étape précédente pour démarrer OAC.
3. Sélectionnez le groupe de plans Démarrer OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de récupérer le cliché OAC.

Figure 11-7 : paramètres permettant de créer un groupe de plans et d'ajouter une étape de récupération du cliché OAC en standby

Tâche 11.3.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, il récupère l'instantané OAC dans la région 1. Le cliché est pris dans la région principale pendant les opérations normales et stocké dans un bucket de stockage d'objets dans la région 1.

Tout dans cette tâche est identique à la tâche 11.3.2, à l'exception des éléments présentés dans la figure 11-8 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-start-stop.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez l'ID de région OCI comme seul paramètre (PHX dans cet exemple).
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 11-8 : paramètres permettant de créer l'étape de plan pour la récupération du cliché en standby

Tâche 11.3.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape de récupération d'OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 11-9 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 11-9 : Finaliser l'ajout d'un groupe de plans et d'une étape pour récupérer le cliché en standby

Tâche 11.4 : créer un groupe de plans pour annuler le cliché dans la région 1 (en veille)

Le dernier groupe de plans défini par l'utilisateur modifiera le travail CRON, de sorte que le cliché OAC sera enregistré dans la région 2 une fois qu'il sera de nouveau accessible. Il s'agit de la même tâche qui a été ajoutée au plan de permutation dans la tâche 10.

Tâche 11.4.1 : sélectionnez Add Plan Group.

Comme précédemment, cliquez sur Ajouter un groupe pour commencer.

Figure 11-10 : Commencer à ajouter un groupe de plans pour inverser la copie de cliché sur la base de secours

Tâche 11.4.2 : indiquer le nom du groupe de plans, la commande et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour inverser le cliché OAC vers la région 2.

1. Attribuez un nom simple mais descriptif au groupe de plans. Il est toujours recommandé d'ajouter "(Standby)" au nom du groupe afin de déterminer clairement la région dans laquelle les étapes s'appliquent en un coup d'œil.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui récupère le cliché OAC dans la région 1.
3. Sélectionnez le groupe de plans Récupérer le cliché OAC (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'OAC.

Figure 11-11 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour inverser la copie de cliché sur la base de données de secours

Tâche 11.4.3 : indiquer le nom de l'étape et les paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Dans ce cas, le cliché OAC est inversé afin d'être enregistré dans la région 2, qui devient automatiquement la région de secours une fois la permutation terminée.

Tout dans cette tâche est identique à la tâche 11.3.2, à l'exception des éléments présentés dans la figure 11-19 ci-dessous.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans lequel vous avez installé le script oac-chg-cronjob.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez la clé de région OCI pour la région 2 (phx dans cet exemple) en tant que premier paramètre et la clé de région pour la région 1 (iad dans cet exemple) en tant que deuxième paramètre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 11-12 : paramètres permettant de créer l'étape de plan permettant d'inverser la copie de cliché sur la base de données de secours

Tâche 11.4.4 : terminer l'ajout du groupe de plans et de l'étape

L'étape d'inversion du sens des instantanés OAC est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré à la figure 11-13 ci-dessous.

1. Affiche l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et l'étape au plan de récupération après sinistre.

Figure 11-13 : Finaliser l'ajout d'un groupe de plans et d'une étape pour inverser la copie de cliché sur la base de données de secours

Le plan de basculement doit désormais inclure les trois groupes de plans de récupération après sinistre pour OAC, comme indiqué dans la capture d'écran ci-dessous. Vous pouvez disposer de groupes de plans supplémentaires si votre groupe de protection inclut d'autres applications ou services OCI avec OAC.

Figure 11-14 : Affichage des trois groupes de plans définis par l'utilisateur ajoutés au plan de basculement

Etapes suivantes

La reconfiguration dynamique de pile complète pour OAC doit être entièrement implémentée à ce stade. Toutefois, vous devez valider l'ensemble des fonctionnalités avant d'utiliser Full Stack DR pour la production. Tous les plans de basculement et de permutation doivent être exécutés pour vérifier que tout fonctionne comme prévu et que l'équipe de récupération comprend parfaitement l'ensemble du processus.

Tester les plans de permutation

Les plans de permutation sont conçus pour nettoyer tous les artefacts et garantir que tous les rôles des étapes de récupération intégrées telles que l'équilibreur de charge, le stockage de blocs, les systèmes de fichiers, BaseDB, ExaCS et Autonomous Data Base sont prêts à être récupérés à partir de la région de secours sans intervention humaine.

Tester les plans de basculement

Les basculements sont différents. Les basculements par nature ne peuvent pas nettoyer les artefacts ni garantir que les services et les bases de données de la région en échec sont prêts à faire passer les charges globales vers la région 1. L'équipe de récupération doit comprendre et effectuer des tâches pour s'assurer que Data Guard est dans un état correct, que les artefacts des instances de stockage et de calcul ont été arrêtés, etc. Lisez Réinitialisation de la configuration de récupération après sinistre après un basculement dans la documentation relative à la récupération après sinistre de la pile complète OCI pour comprendre le processus.

Valider tous les plans de récupération après sinistre pour acceptation finale

L'équipe de récupération doit effectuer une validation finale pour démontrer l'état de préparation des groupes de protection Full Stack DR et des plans pour les charges de travail de production. La région 2 (Phoenix) devrait être la région principale à ce stade du processus. Pour commencer la validation finale de tous les protocoles, procédez comme suit :

• Testez la permutation de la région 2 (principale) vers la région 1 (de secours).
• Testez le basculement entre la région 1 (principale) et la région 2 (de secours).
• Préparez la région 1 (principale) pour le basculement à partir de la région 2.
• Testez le basculement entre la région 2 (principale) et la région 1 (de secours).
• Préparez la région 2 (principale) pour un basculement ou une permutation vers la région 2.
• Les groupes de protection de récupération après sinistre et la pile d'applications doivent être dans un état opérationnel normal et prêts pour un basculement ou une permutation à ce stade.

Liens connexes

• Architecture de référence : Concevoir une topologie de récupération après sinistre Oracle Analytics Cloud avec Full Stack Disaster Recovery Service dans Oracle Architecture Center

• Document technique : Configuration de la récupération après sinistre pour Oracle Analytics Cloud

• Exemples de script : téléchargez des exemples de script à partir de GitHub

• Blog : Plan de récupération après sinistre pour Oracle Analytics Cloud à l'aide de la méthode de permutation manuelle

• Liste de lecture Full Stack DR Oracle Analytics Cloud dans YouTube

  • Déployez Oracle Analytics Cloud pour la récupération après sinistre (vidéo 1)

  • Automatiser la récupération pour Oracle Analytics Cloud (vidéo 2)

  • Scripts utilisés pour automatiser la récupération pour Oracle Analytics Cloud (vidéo 3)

• Page du produit OCI Full Stack Disaster Recovery

• Documentation OCI Full Stack Disaster Recovery

• Full Stack Disaster Recovery - Scripts de groupe définis par l'utilisateur

• Rejoindre le canal slack public #full-stack-dr

Remerciements

• Auteur - Bala Guddeti (Spécialiste des solutions Cloud NACE)

• Contributeurs - Greg King (chef de produit Full Stack Disaster Recovery), Suraj Ramesh (chef de produit Full Stack Disaster Recovery)

Ressources de formation supplémentaires

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

Pour obtenir de la documentation sur le produit, visitez Oracle Help Center.

---

Informations relatives au titre et au copyright

Automate Recovery for Oracle Analytics Cloud Using OCI Full Stack Disaster Recovery

F88861-01

December 2023

Copyright © 2023, Oracle and/or its affiliates.