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 Integration à l'aide d'OCI Full Stack Disaster Recovery

Partie 1 : Introduction

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestre la transition du calcul, de la base de données et des applications entre les régions Oracle Cloud Infrastructure (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 Integration est une plate-forme unifiée et sécurisée qui vous permet de connecter des applications cloud et on-premise, d'automatiser les processus métier, d'obtenir des informations sur votre activité grâce à l'analyse des indicateurs commerciaux et de développer des applications Web et mobiles. Oracle Integration est disponible dans une région OCI régie par des contrats de niveau de service. Ce tutoriel détaille la procédure de création d'une solution de récupération après sinistre inter-région gérée par le client pour Oracle Integration, en particulier pour la fonctionnalité d'intégration d'Oracle Integration.

Oracle Integration est une offre OCI Platform-as-a-Service (PaaS) gérée qui n'est pas quelque chose qu'OCI Full Stack DR peut gérer de manière native car Oracle Integration lui-même n'expose pas le calcul, le stockage ou la base de données aux utilisateurs OCI. Toutefois, OCI 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'Oracle Integration a documenté un moyen de provisionner, de configurer et de récupérer son service pour la récupération après sinistre entre les régions OCI. L'équipe d'ingénierie Oracle Integration a documenté Configuration d'une solution de récupération après sinistre pour Oracle Integration Generation 2 expliquant comment provisionner, configurer et récupérer manuellement Oracle Integration.

OCI Full Stack Disaster Recovery n'est pas utilisé pour provisionner ou configurer Oracle Integration. Oracle Integration doit être provisionné et configuré pour la récupération après sinistre entre les régions en suivant les instructions détaillées fournies dans Configuration d'une solution de récupération après sinistre pour Oracle Integration Generation 2 avant de tenter d'utiliser OCI Full Stack DR de quelque manière que ce soit.

Les étapes de basculement manuel prescrites par l'ingénierie Oracle Integration dans cette documentation : Configuration d'une solution de récupération après sinistre pour Oracle Integration Generation 2 doivent également être testées pour la permutation et la permutation avant d'utiliser OCI Full Stack DR.

Oracle Integration fait normalement partie d'un système plus grand

Ce tutoriel suppose qu'Oracle Integration 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 car seul Oracle Integration est présenté et abordé tout au long du document afin de simplifier les choses. Normalement, Oracle Integration sera simplement une petite partie d'un système métier beaucoup plus grand et plus complexe qui inclut de nombreux services et applications différents dans un seul groupe de protection de récupération après sinistre OCI Full Stack et un ensemble de plans de récupération après sinistre. Il est fort probable que vous suiviez des tutoriels Oracle Help Center (OHC) similaires pour d'autres applications et services tels que PeopleSoft, WebLogic Server, Oracle Analytics Cloud, etc.

Remarque : les étapes de ce tutoriel ont été testées à l'aide d'Oracle Integration Generation 2. Ce tutoriel montre simplement comment implémenter la récupération après sinistre pour la fonctionnalité d'intégration d'applications d'Oracle Integration Generation 2, car nous ne voulons pas submerger le lecteur en introduisant trop de pièces et d'éléments mobiles.

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.

OCI 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'Oracle Integration, ajoutez tous les membres pour 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 Oracle Integration nécessite OCI 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 des spécialistes Oracle Integration et disponibles dans un référentiel GitHub spécialement conçu pour cette solution de récupération après sinistre Oracle Integration. Les scripts bash sont téléchargés vers une instance de calcul faisant partie de la pile d'applications qu'OCI Full Stack DR gérera lors d'une opération de récupération.

Les scripts suivants sont fournis à des fins génériques. Vous pouvez utiliser vos propres scripts ou les personnaliser en fonction de la stratégie et des exigences de sécurité de votre entreprise. Vous devez installer l'interface de ligne de commande OCI et configurer vos informations d'identification pour utiliser les scripts.

En outre, pour vous assurer que votre instance principale est mise à jour avec les derniers paramètres programmés, assurez-vous que le fichier integrations.json est mis à jour avec tous les noms d'intégration, ainsi que les détails de version, ainsi que le fichier integration_parameters.json, qui doit être mis à jour avec les dernières valeurs de paramètre programmé pour toutes les intégrations programmées. Pour ce faire, vous pouvez utiliser le processus CI/CD préféré.

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 il n'inclut rien d'autre qu'Oracle Integration.

Option 1 pour l'hébergement des scripts

Oracle Integration 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ù Oracle Integration sera le seul service d'application qu'OCI 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, OCI 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 Oracle Integration n'est pas quelque chose qu'OCI Full Stack DR peut gérer de manière native. 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 OCI 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 Oracle Integration

Comme le montre la figure, l'architecture de récupération après sinistre d'Oracle Integration Generation 2 inclut deux instances Oracle Integration, distinguées comme principales et secondaires, fonctionnant simultanément. Cependant, le trafic est dirigé vers une seule instance à la fois. Initialement, le trafic circule vers l'instance principale. Si l'instance principale devient indisponible, l'enregistrement DNS est ajusté pour rediriger le trafic vers l'instance secondaire.

Fig 1 : Architecture de référence d'Oracle Integration DR

Une fois les instances provisionnées, exportez les métadonnées de l'instance principale vers l'instance de secours. Pour ce faire, vous pouvez utiliser des API REST ou utiliser l'interface utilisateur Oracle Integration pour exporter et importer les métadonnées. Une fois la migration unique initiale des métadonnées terminée, vous devez synchroniser les métadonnées entre les instances à l'aide de CICD. Vous pouvez utiliser Jenkins ou un outil similaire pour implémenter CICD pour vos instances et synchroniser les métadonnées. Vous pouvez également utiliser une instance OCI Compute en tant que serveur Jenkins CI et hub CD.

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

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 de comprendre l'ensemble du flux de processus. Ces vidéos font partie d'une liste de lecture OCI Full Stack DR Oracle Integration dans YouTube accessible à l'aide des liens suivants :

• Vidéo 1 : Déployer Oracle Integration pour la récupération après sinistre.
• Vidéo 2 : Automatisation des opérations de récupération après sinistre pour Oracle Integration à l'aide d'OCI Full Stack DR.
• Vidéo 3 : Scripts utilisés pour automatiser la récupération pour Oracle Integration.

Partie 2 : Instructions étape par étape

Cette partie présente les instructions détaillées nécessaires pour ajouter Oracle Integration à OCI Full Stack DR.

Objectifs

Les étapes suivantes seront traitées dans ce tutoriel expliquant comment automatiser la récupération pour Oracle Integration à l'aide d'OCI Full Stack DR :

1. Tâche 1 : déploiement d'Oracle Integration 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 Oracle Integration
   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 Oracle Integration for DR 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 récupération après sinistre de la pile complète OCI
   1. Création de stratégies IAM pour OCI 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 à la région 1 DRPG
5. Tâche 5 : créer des plans de récupération après sinistre 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 Oracle Integration et OCI Full Stack DR dans n'importe quel modèle de compartiment qui fonctionne selon 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 Integration : OIC-demo. Le compartiment pour OIC lui-même, le stockage, les buckets de stockage, le calcul et la base de données associés à OIC est Démo OIC dans ce tutoriel.
  • Compartiment pour la récupération après sinistre de pile complète OCI : Démo OIC Le compartiment pour les plans et les groupes de protection de récupération après sinistre de pile complète OCI est Démo OIC dans ce tutoriel.

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

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 Oracle Integration. Les scripts sont appelés par OCI Full Stack DR lors d'une opération de récupération. Ce tutoriel explique comment ajouter les scripts à OCI Full Stack DR aux étapes 6, 7, 10 et 11.

• Pour Oracle Integration en tant qu'application autonome : il s'agit d'une instance de calcul spécialisée que vous créez en tant qu'hôte des scripts personnalisés.
• Pour Oracle Integration 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 Oracle Integration ; 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 Integration doit être déployé pour la récupération après sinistre dans les deux régions avant de commencer à travailler avec OCI Full Stack DR. Cette opération est traitée dans la tâche 1 ci-dessous.

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

OCI 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 OIC. 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 : Oracle Integration en tant qu'application autonome

Ce tutoriel suppose qu'Oracle Integration 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 : Oracle Integration 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 OCI 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 : Oracle Integration dans le cadre d'une pile d'applications avec plusieurs offres PaaS

Il est possible que votre système d'entreprise dispose également d'Oracle HTTP Server (OHS), d'Oracle Integration 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 OCI Full Stack appartient également aux groupes de volumes de blocs répliqués dans la région 2. Si vous avez besoin de plus de détails, reportez-vous à la documentation OCI Block Storage.

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 Oracle Integration. 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 Oracle Integration

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 Oracle Integration

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

Déployez Oracle Integration pour la récupération après sinistre dans les régions OCI à l'aide des instructions pas à pas fournies par l'équipe d'ingénierie Oracle Integration.

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

Il est recommandé de s'assurer que les étapes de récupération manuelle Les étapes manuelles de récupération d'Oracle Integration décrites dans Configuration de récupération après sinistre pour Oracle Integration doivent être effectuées avant de pouvoir utiliser OCI Full Stack DR.

Tâche 1.6 : étapes suivantes

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

1. Déployez manuellement Oracle Integration for DR 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 OCI

OCI 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 Oracle Integration pour une récupération automatisée par OCI Full Stack DR.

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

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 OCI IAM pour d'autres services gérés par OCI Full Stack DR

OCI 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 OCI Object Storage pour les journaux DRPG

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

Créez des buckets OCI Object Storage dans les régions principale et de secours pour stocker les journaux générés par OCI 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électionner des 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 à OIC.
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 OCI liés aux opérations de récupération après sinistre pour OIC.
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 à OIC 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 Oracle Integration 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 (OCI Full Stack DR), 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 Oracle Integration 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 le DRPG ; 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 Oracle Integration 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 le DRPG ; 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 qu'OCI Full Stack DR saura quelles deux régions fonctionnent ensemble pour la récupération Oracle Integration. Les rôles de la base de données principale et de la base de données de secours sont automatiquement modifiés par OCI Full Stack DR dans le cadre de toute opération de récupération après sinistre/exécution de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment.

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. OCI 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

OCI 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 au groupe 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. OCI 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 d'interface de ligne de commande de récupération après sinistre OCI Full Stack pour recréer les étapes et les groupes de plans personnalisés définis par l'utilisateur (au-delà de ce tutoriel).

Ajoutez le noeud de contrôle de reconfiguration dynamique en tant que membres au groupe de protection de reconfiguration dynamique principal. Le noeud de contrôle de récupération après sinistre est soit une instance de calcul que vous avez créée uniquement pour contrôler Oracle Integration, soit une instance de calcul qui fait partie de la pile d'applications à gérer avec OCI Full Stack DR.

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.

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 de déplacement.
5. Indiquez à OCI Full Stack DR le VCN et le sous-réseau à affecter aux cartes d'interface réseau virtuelles de la région 2 lors d'une récupération. La figure 4-2 présente une carte VNIC unique. OCI Full Stack DR ne se soucie pas du nombre de cartes d'interface réseau virtuelles dont vous disposez ni de leur configuration dans l'une ou l'autre région. Indiquez 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 : vérifier les ressources membres pour la région 1

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

1. 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 OIC.

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

Il n'est pas nécessaire d'ajouter des membres dans le groupe de protection de récupération après sinistre de secours car nous utilisons le déplacement de l'instance de calcul en tant que noeud de récupération après sinistre pour héberger les scripts Oracle Integration

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.

OCI Full Stack DR préremplira 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 à Oracle Integration 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. Sélectionnez le type de plan. Il n'existe que quatre 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. Sélectionnez 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 à OCI Full Stack DR et ne contiennent rien pour gérer les tâches de récupération propres à Oracle Integration. 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 Oracle Integration :

1. Synchroniser les paramètres programmés de la région 1 vers la région 2
2. Activer les intégrations pertinentes dans la région 2
3. Démarrer les intégrations programmées dans la région 2
4. Mettre à jour l'enregistrement DNS dans la région 2
5. Désactiver les intégrations programmées dans la région 1

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 qu'OCI Full Stack DR entre 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 synchroniser les paramètres planifiés de la région 1 vers la région 2

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 synchronisera les paramètres planifiés de la région 1 à la région. Ce groupe de plans contient une seule étape qui appelle le script bash oic-sync-schedule-parameters.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.

Lancez 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 synchroniser les paramètres planifiés

Tâche 6.3.2 : indiquer le nom du groupe de plans, l'ordre 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 ajoutons juste une seule étape pour exécuter un script bash pour synchroniser les paramètres planifiés.

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, 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 de synchronisation des paramètres programmés.

Figure 6-6 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour synchroniser les paramètres planifiés

Tâche 6.3.3 : indiquer le nom de l'étape et les paramètres du 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 synchronisera les paramètres programmés de la région 1 à 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. 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. OCI 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).
3. Sélectionnez Exécuter le script local pour informer OCI 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.
4. 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).
5. Collez le chemin absolu dans lequel vous avez installé le script oic-sync-schedule-parameters.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez PHX comme paramètre. Région cible dans laquelle synchroniser les paramètres programmés. Vous devrez peut-être fournir des paramètres de région corrects si vous utilisez différentes régions OCI et des scripts de mise à jour.
6. Indiquez opc en tant qu'utilisateur pour exécuter le script.
7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à synchroniser les paramètres planifiés. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. OCI Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
8. La valeur par défaut avant qu'OCI Full Stack DR déclare un échec est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
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 les paramètres planifiés de synchronisation

Tâche 6.3.4 : ajouter un groupe de plans et une étape

L'étape permettant d'arrêter la synchronisation des paramètres planifiés est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 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 de plans inclut uniquement l'étape de synchronisation des paramètres planifiés.
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 synchroniser les paramètres planifiés

Tâche 6.4 : créer un groupe de plans pour activer les intégrations pertinentes en mode veille

Le deuxième groupe de plans défini par l'utilisateur activera les intégrations pertinentes en mode veille 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 oic-integration-switch.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 activer les intégrations pertinentes au niveau de la base de données de secours

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

Créez un groupe de plans de récupération après sinistre pour commencer à activer les intégrations pertinentes en mode veille.

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, 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 permettant d'activer les intégrations pertinentes en veille.

Figure 6-10 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour activer les intégrations pertinentes sur la base de données de secours

Tâche 6.4.3 : indiquer le nom de l'étape et les paramètres du 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 activera les intégrations pertinentes dans 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 oic-integration-switch.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez activate en tant que premier paramètre et PHX en tant que second.This est la région cible dans laquelle activer les intégrations pertinentes. Vous devrez peut-être fournir des paramètres de région corrects si vous utilisez différentes régions OCI et des scripts de mise à jour.
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 permettant d'activer les intégrations pertinentes sur la base de données de secours

Tâche 6.4.4 : ajouter un groupe de plans et une étape

L'étape d'activation des intégrations pertinentes en mode veille est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 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 activer les intégrations pertinentes au niveau de la base de données de secours

Tâche 6.5 : créer un groupe de plans pour démarrer les intégrations programmées dans la région 2

Le troisième groupe de plans défini par l'utilisateur démarre les intégrations programmées en veille 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 oic-integration-schedule.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 démarrer les intégrations programmées sur la base de données de secours

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

Créez un groupe de plans de récupération après sinistre pour démarrer les intégrations programmées 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 activer les intégrations pertinentes.
3. Sélectionnez le groupe de plans intégré Activer les intégrations pertinentes au niveau de la base de données de secours
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage des intégrations programmées sur la base de données de secours.

Figure 6-14 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer les intégrations programmées sur la base de données de secours

Tâche 6.5.3 : indiquer le nom de l'étape et les paramètres du 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, les intégrations programmées démarrent dans la région de secours 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 oic-integration-schedule.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez start en tant que premier paramètre et PHX en tant que deuxième.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-15 : Paramètres permettant de créer l'étape de plan pour démarrer des intégrations programmées sur la base de données de secours

Tâche 6.5.4 : ajouter un groupe de plans et une étape

L'étape de démarrage des intégrations programmées en veille est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 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émarrer les intégrations programmées sur la base de données de secours

Tâche 6.6 : créer un groupe de plans pour mettre à jour l'enregistrement DNS dans la région 2

Le quatrième groupe de plans défini par l'utilisateur mettra à jour l'enregistrement DNS en veille 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 dns_record_update.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.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 mettre à jour l'enregistrement DNS en veille

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

Créez un groupe de plans de récupération après sinistre pour mettre à jour l'enregistrement DNS vers la région 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, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré pour démarrer les intégrations programmées sur la base de données de secours
3. Sélectionnez le groupe de plans Démarrer les intégrations programmées sur la base de données de secours intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour de l'enregistrement DNS en veille.

Figure 6-18 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape de mise à jour de l'enregistrement DNS en standby

Tâche 6.6.3 : indiquer le nom de l'étape et les paramètres du 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 mettra à jour l'enregistrement DNS en veille.

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 dns_record_update.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 paramètre.
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 de mise à jour de l'enregistrement DNS en standby

Tâche 6.6.4 : ajouter un groupe de plans et une étape

L'étape de mise à jour de l'enregistrement DNS en veille est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans 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 mettre à jour l'enregistrement DNS en standby

Tâche 6.7 : créer un groupe de plans pour désactiver les intégrations programmées dans la région 1

Le groupe de plans défini par l'utilisateur final désactivera les intégrations programmées dans la région 1 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 oic-integration-switch.sh qui a été 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.7.1 : sélectionnez Add Plan Group.

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

Figure 6-21 : Commencez à ajouter un groupe de plans pour désactiver les intégrations programmées dans la région 1

Tâche 6.7.2 : indiquer le nom du groupe de plans, l'ordre et l'étape d'ajout

Créer un groupe de plans de récupération après sinistre pour désactiver les intégrations programmées dans la région 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, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré pour mettre à jour l'enregistrement DNS en standby
3. Sélectionnez le groupe de plans Mettre à jour l'enregistrement DNS en veille intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant de désactiver les intégrations programmées de la région 1.

Figure 6-22 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour désactiver les intégrations programmées dans la région 1

Tâche 6.7.3 : indiquer le nom de l'étape et les paramètres du 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ésactivera les intégrations programmées dans la région 1

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-23 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 oic-integration-switch.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 paramètre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-23 : Paramètres permettant de créer l'étape de plan pour désactiver les intégrations programmées dans la région 1

Tâche 6.7.4 : ajouter un groupe de plans et une étape

L'étape de désactivation des intégrations programmées dans la région 1 est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans 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-24 : Finaliser l'ajout d'un groupe de plans et d'une étape pour désactiver les intégrations programmées dans la région 1

Le plan de permutation doit désormais inclure les cinq groupes de plans de récupération après sinistre pour Oracle Integration, 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 d'autres services OCI avec Oracle Integration

Figure 6-25 : Affichage des cinq 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 Oracle Integration 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. Activer les intégrations pertinentes dans la région 2
2. Mettre à jour les paramètres programmés dans la région 2
3. Démarrer les intégrations programmées dans la région 2
4. Mettre à jour l'enregistrement DNS dans la région 2

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 activera les intégrations pertinentes dans la région 2. Ce groupe de plans contient une étape unique qui appelle le script bash oic-integration-switch.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 activer les intégrations pertinentes

Tâche 7.2.1 : indiquer le nom du groupe de plans, l'ordre 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 n'ajoutons qu'une seule étape pour exécuter un script bash afin d'activer les intégrations pertinentes.

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, 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 permettant d'activer les intégrations pertinentes

Figure 7-3 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour activer les intégrations pertinentes sur la base de données de secours

Tâche 7.2.2 : indiquer le nom de l'étape et les paramètres du 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 activera les intégrations pertinentes dans 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 parvient pas à activer les intégrations pertinentes. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. OCI 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 qu'OCI Full Stack DR déclare un échec 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. OCI 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 OCI 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 oic-integration-switch.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez activate en tant que premier paramètre et PHX 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 permettant d'activer les intégrations pertinentes au niveau de la base de données de secours

Tâche 7.2.3 : ajouter un groupe de plans et une étape

L'étape d'activation des intégrations pertinentes est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 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 activer les intégrations pertinentes

Tâche 7.3 : créer un groupe de plans pour mettre à jour les paramètres planifiés dans la région 2

Le deuxième groupe de plans défini par l'utilisateur mettra à jour les paramètres planifiés dans la région de secours 2. Ce groupe de plans contient une étape unique qui appelle le script bash oic-update-parameters.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 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 mettre à jour les paramètres planifiés sur la base de secours

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

Créez un groupe de plans de récupération après sinistre pour mettre à jour les paramètres programmés de la région 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 activer les intégrations pertinentes.
3. Sélectionnez Activer les intégrations pertinentes au niveau du groupe de plans de secours.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour des paramètres programmés en veille.

Figure 7-7 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour mettre à jour les paramètres programmés sur la base de données de secours

Tâche 7.3.3 : indiquer le nom de l'étape et les paramètres du 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 les paramètres programmés de mise à jour 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 oic-update-parameters.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez PHX 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 permettant de créer l'étape de plan pour la mise à jour des paramètres programmés sur la base de données de secours

Tâche 7.3.4 : ajouter un groupe de plans et une étape

L'étape de mise à jour des paramètres programmés en veille 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 de paramètres programmés de mise à jour de groupe de plans et d'étape au niveau de la base de données de secours

Tâche 7.4 : créer un groupe de plans pour démarrer les intégrations programmées dans la région 2

Le troisième groupe de plans défini par l'utilisateur démarre les intégrations programmées en veille 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 oic-integration-schedule.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 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 démarrer les intégrations programmées sur la base de données de secours

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

Créer un groupe de plans de récupération après sinistre pour démarrer les intégrations programmées sur la base de données de secours

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, nous allons insérer notre groupe de plans défini par l'utilisateur après la mise à jour des paramètres programmés dans les groupes de plans de secours
3. Sélectionnez le groupe de plans Mettre à jour les paramètres programmés en veille intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage des intégrations programmées sur la base de données de secours.

Figure 7-11 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer des intégrations programmées sur la base de données de secours

Tâche 7.4.3 : indiquer le nom de l'étape et les paramètres du 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.

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 oic-integration-schedule.sh sur le noeud de contrôle de récupération après sinistre. Ajoutez start en tant que premier paramètre et PHX en tant que deuxième.
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 pour démarrer des intégrations programmées sur la base de données de secours

Tâche 7.4.4 : ajouter un groupe de plans et une étape

L'étape de démarrage des intégrations programmées en veille est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans 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 démarrer les intégrations programmées sur la base de données de secours

Tâche 7.5 : créer un groupe de plans pour mettre à jour l'enregistrement DNS dans la région 2

Le quatrième groupe de plans défini par l'utilisateur mettra à jour l'enregistrement DNS en veille 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 dns_record_update.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 7.5.1 : sélectionnez Add Plan Group.

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

Figure 7-14 : Commencer à ajouter un groupe de plans pour mettre à jour l'enregistrement DNS en veille

Tâche 7.5.2 : indiquer le nom du groupe de plans, l'ordre et l'étape d'ajout

Créez un groupe de plans de récupération après sinistre pour mettre à jour l'enregistrement DNS vers la région 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, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré pour démarrer les intégrations programmées sur la base de données de secours
3. Sélectionnez le groupe de plans Démarrer les intégrations programmées sur la base de données de secours intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour de l'enregistrement DNS en veille.

Figure 7-14 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape de mise à jour de l'enregistrement DNS en standby

Tâche 7.5.3 : indiquer le nom de l'étape et les paramètres du 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 mettra à jour l'enregistrement DNS en veille.

Tout dans cette tâche est identique à la tâche 6.3.3, à l'exception des éléments présentés dans la figure 7-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 dns_record_update.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 paramètre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 7-15 : Paramètres permettant de créer l'étape de plan de mise à jour de l'enregistrement DNS en standby

Tâche 7.5.4 : ajouter un groupe de plans et une étape

L'étape de mise à jour de l'enregistrement DNS en veille est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré dans la figure 7-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 7-16 : Finaliser l'ajout d'un groupe de plans et d'une étape pour mettre à jour l'enregistrement DNS en standby

Le plan de basculement doit désormais inclure les quatre groupes de plans de récupération après sinistre pour Oracle Integration, 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 Oracle Integration.

Figure 7-14 : Affichage des quatre 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 à OCI 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 qu'OCI Full Stack DR puisse faire passer les workloads 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 Oracle Integration de la région 1 vers 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 et personnaliser les deux plans de récupération après sinistre.
5. Cliquez sur Execute DR plan.

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

Tâche 8.2 : sélectionner le plan de permutation et l'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 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 permutation jusqu'à ce que la charge globale Oracle Integration passe entièrement de la région 1 à la région 2. OCI Full Stack DR se charge du nettoyage des artefacts et de la modification des rôles de la base de données principale et de la base de données 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 qu'OCI 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.

OCI Full Stack DR préremplira 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 à Oracle Integration au cours d'une opération de récupération.

Les plans de récupération après sinistre 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 1, 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. Sélectionnez 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

3. Cliquez sur Créer pour créer un plan de permutation de base prérempli avec des étapes de base intégrées.

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. Sélectionnez 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 à Oracle Integration. 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 et explique comment gérer les opérations à effectuer lors d'une permutation pour Oracle Integration :

1. Synchroniser les paramètres programmés de la région 1 vers la région 2.
2. Activez les intégrations pertinentes dans la région 2.
3. Démarrez les intégrations programmées dans la région 2.
4. Mettez à jour l'enregistrement DNS dans la région 2.
5. Désactivez les intégrations programmées dans la région 1.

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 qu'OCI Full Stack DR entre 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 : Procédure d'activation de la terminaison d'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 différents plans définis par l'utilisateur pour le plan de permutation de rôles

Nous avons déjà montré comment créer les différents plans définis par l'utilisateur pour le plan de permutation de la tâche 6.3 à la tâche 6.7. En utilisant le même processus, créez cinq groupes de plans personnalisés définis par l'utilisateur. Vous devez utiliser l'instance de calcul en cours d'exécution dans la région Phoenix pour exécuter des scripts.

1. Synchroniser les paramètres programmés de l'IAD /home/opc/oic-scripts/oic-sync-schedule-parameters.sh principal vers l'IAD de secours.
2. Activez les intégrations pertinentes sur le site de secours /home/opc/oic-scripts/oic-integration-switch.sh pour activer IAD.
3. Démarrez les intégrations programmées sur /home/opc/oic-scripts/oic-integration-schedule.sh de secours pour démarrer IAD.
4. Mettez à jour l'enregistrement DNS dans l'IAD /home/opc/oic-scripts/dns-record-update.sh de secours.
5. Désactivez les intégrations programmées dans /home/opc/oic-scripts/oic-integration-switch.sh principal et désactivez IAD.

Une fois créés, le plan de permutation doit désormais inclure les cinq groupes de plans de récupération après sinistre pour l'intégration Oracle, 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 ainsi que l'intégration Oracle.

Figure 10-21 : Affichage des cinq 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 Oracle Integration 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. Activez les intégrations pertinentes dans la région 1.
2. Mettez à jour les paramètres programmés dans la région 1.
3. Démarrez les intégrations programmées dans la région 1.
4. Mettez à jour l'enregistrement DNS dans la région 1.

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

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

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 11.2 : créer plusieurs groupes de plans définis par l'utilisateur dans la région 1 (en veille)

Nous avons déjà montré comment créer les différents plans définis par l'utilisateur pour le plan de basculement de la tâche 7.2 à la tâche 7.5. En utilisant le même processus, créez les quatre groupes de plans personnalisés définis par l'utilisateur ci-dessous. Vous devez utiliser l'instance de calcul en cours d'exécution dans la région Phoenix pour exécuter des scripts.

1. Activez les intégrations pertinentes sur le site de secours /home/opc/oic-scripts/oic-integration-switch.sh pour activer IAD.

2. Mettez à jour les paramètres programmés dans l'IAD /home/opc/oic-scripts/oic-update-parameters.sh de secours.

3. Démarrez les intégrations programmées sur /home/opc/oic-scripts/oic-integration-schedule.sh de secours pour démarrer IAD.

4. Mettez à jour l'enregistrement DNS dans l'IAD /home/opc/oic-scripts/dns-record-update.sh de secours.

Une fois créés, le plan de basculement doit désormais inclure les quatre groupes de plans de récupération après sinistre pour l'intégration Oracle, 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 ainsi que l'intégration Oracle.

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

Etapes suivantes

OCI Full Stack DR pour Oracle Integration doit être entièrement implémenté à ce stade. Cependant, l'intégralité des fonctionnalités doit être validée avant d'utiliser OCI 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 la préparation des groupes de protection de récupération après sinistre OCI Full Stack et des plans pour les workloads 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.

Remarque : pour vous assurer que la même application client peut être utilisée pour authentifier les autres API pour les deux instances Oracle Integration, vous pouvez ajouter la portée des deux instances (principale et secondaire) à l'application client OAuth. Pour la configuration de l'application client OAuth, reportez-vous à la documentation officielle.

Liens connexes

• Document technique : Configuration d'une solution de récupération après sinistre pour Oracle Integration Generation 2

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

• Liste de lecture OCI Full Stack DR Oracle Integration dans YouTube

  • Déployer Oracle Integration pour la récupération après sinistre (vidéo 1)

  • Automatisez les opérations de récupération après sinistre pour Oracle Integration à l'aide d'OCI Full Stack DR (vidéo 2)

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

• Récupération après sinistre de la pile complète OCI

• Documentation sur la récupération après sinistre de la pile complète OCI

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

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

Remerciements

• Auteur - Suraj Ramesh (chef de produit Full Stack Disaster Recovery)

• Contributeurs - Bonnie Rockey (ingénierie cloud, spécialiste Oracle Integration), Akshay Saxena (ingénierie cloud, spécialiste Oracle Integration)

Vidéo 1 : Déployer Oracle Integration for Disaster Recovery Vidéo 2 : Automatiser les opérations de récupération après sinistre pour Oracle Integration à l'aide d'OCI Full Stack DR Vidéo 3 : Scripts utilisés pour automatiser la récupération pour Oracle Integration

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 Integration using OCI Full Stack Disaster Recovery

F99104-01

May 2024

Copyright ©2024,

Oracle et/ou ses affiliés.