Note :

• Ce tutoriel nécessite l'accès à Oracle Cloud. Pour vous inscrire à un compte gratuit, voir Introduction au niveau gratuit d'Oracle Cloud Infrastructure.
• Il utilise des exemples de valeurs pour les données d'identification, la location et les compartiments Oracle Cloud Infrastructure. À la fin de votre laboratoire, remplacez ces valeurs par celles propres à votre environnement en nuage.

Automatiser la récupération pour Oracle Integration à l'aide de la récupération après sinistre de pile complète OCI

Partie 1 : Introduction

Oracle Cloud Infrastructure Full Stack Disaster Recovery (RD de pile complète OCI) orchestre la transition des calculs, des bases 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 à la récupération d'un ou de plusieurs systèmes d'affaires sans repenser ou réorganiser l'infrastructure, les bases de données ou les applications existantes.

Oracle Integration est une plate-forme unifiée et sécurisée qui vous permet de connecter des applications en nuage et sur place, d'automatiser des processus d'affaires, d'obtenir des informations sur votre entreprise au moyen d'analyses de mesures d'affaires 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 (CNS). 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 fonction d'intégration d'Oracle Integration.

Oracle Integration est une offre de plate-forme-service OCI gérée (PaaS) qui n'est pas quelque chose que la récupération après sinistre de pile complète OCI 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, la récupération après sinistre de pile complète OCI 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, configurer et récupérer son service pour la récupération après sinistre entre les régions OCI. L'équipe d'ingénierie d'Oracle Integration a documenté Configuration d'une solution de récupération après sinistre pour Oracle Integration Génération 2 expliquant comment provisionner, configurer et récupérer manuellement Oracle Integration.

La récupération après sinistre de pile complète OCI n'est pas utilisée 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 étape par étape figurant dans Configuration d'une solution de récupération après sinistre pour Oracle Integration Génération 2 avant de tenter d'utiliser la récupération après sinistre de pile complète OCI de quelque façon que ce soit.

Les étapes de basculement manuel prescrites par l'ingénierie Oracle Integration dans cette documentation : La configuration d'une solution de récupération après sinistre pour Oracle Integration Génération 2 doit également être testée avec succès pour la permutation et la permutation avant d'utiliser la récupération après sinistre de pile complète OCI.

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 RS. Ce n'est pas normal.

Ce tutoriel est inhabituel car seul Oracle Integration est présenté et discuté dans tout le document pour simplifier les choses. Normalement, Oracle Integration ne sera qu'une petite partie d'un système d'affaires beaucoup plus vaste et complexe qui comprend de nombreux services et applications différents dans un seul groupe de protection RS de pile complète OCI et un jeu de plans RS. Il est fort probable que vous suiviez des tutoriels similaires à Oracle Help Center (OHC) pour d'autres applications et services tels que PeopleSoft, WebLogic Server, Oracle Analytics Cloud, etc.

Note : Les étapes de ce tutoriel ont été testées à l'aide d'Oracle Integration Génération 2. Ce tutoriel explique comment mettre en oeuvre la reprise après sinistre pour la capacité d'intégration d'applications d'Oracle Integration Génération 2, car nous ne voulons pas submerger le lecteur en introduisant trop de pièces et de pièces mobiles.

Mise en œuvre progressive

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

La récupération après sinistre de pile complète OCI est conçue en supposant que toute la pile d'applications pour un système d'affaires donné est déjà déployée dans les régions OCI et que la récupération après sinistre manuelle a déjà été prouvée. Si votre système d'affaires comprend plus d'Oracle Integration, ajoutez tous les membres de toutes les autres applications ou services OCI aux groupes de protection RS avant de créer des plans RS.

Fonctionnement de la récupération

La solution de récupération pour Oracle Integration nécessite la récupération après sinistre de pile complète OCI 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 de spécialistes d'Oracle Integration et disponibles dans un référentiel GitHub spécialement conçu pour cette solution de reprise après sinistre d'Oracle Integration. Les scripts bash sont téléchargés dans une instance de calcul qui fait partie de la pile d'applications que la récupération après sinistre de pile complète OCI 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 vos exigences en matière de politique d'entreprise et de sécurité. Vous devez installer l'interface de ligne de commande OCI et configurer vos données d'identification pour utiliser les scripts.

De plus, 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 et 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. Vous pouvez utiliser le processus d'intégration et de développement en continu privilégié pour y parvenir.

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

Option 1 pour les scripts d'hébergement

Oracle Integration fait le plus souvent partie d'un système d'affaires plus vaste et plus complexe qui comprend une application comme Oracle E-Business Suite, PeopleSoft ou JD Edwards Enterprise, plus 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 " mobiles " qui font déjà partie du système d'affaires pour héberger les scripts. L'instance de calcul sélectionnée peut être n'importe quel endroit où Oracle Linux est installé et sera probablement une machine virtuelle existante qui sert un autre objectif, comme un serveur d'applications ou un serveur d'administration.

Ce tutoriel référence cette instance de calcul particulière en tant que noeud de contrôle ou noeud RS même si elle remplit vraiment un autre objectif dans la pile d'applications.

Option 2 pour les scripts d'hébergement

S'il s'agit d'une circonstance inhabituelle où Oracle Integration sera le seul service d'application que la récupération après sinistre de pile complète OCI 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, la récupération après sinistre de pile complète OCI 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 que la récupération après sinistre de pile complète OCI peut gérer de manière native. Dans ce document, le serveur de gestion spécialisé est considéré comme un noeud de contrôle ou un noeud RS. L'objectif du noeud de contrôle est simplement d'agir en tant que serveur où les scripts personnalisés peuvent résider et être appelés par la récupération après sinistre de pile complète OCI lors d'une opération de récupération. Ce tutoriel explique comment créer des groupes et des étapes de plan RS personnalisés définis par l'utilisateur dans le cadre de vos plans RS pour appeler les scripts installés sur le noeud de contrôle.

Architecture de déploiement d'Oracle Integration

Comme le montre la figure, l'architecture de reprise après sinistre d'Oracle Integration Génération 2 comprend deux instances Oracle Integration, principales et secondaires, fonctionnant simultanément. Toutefois, 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 RS d'Oracle Integration

Une fois les instances provisionnées, exportez les métadonnées de l'instance principale vers l'instance de secours. Vous pouvez le faire à l'aide d'apis REST ou en tirant parti de l'interface utilisateur d'Oracle Integration pour exporter et importer les métadonnées. Une fois cette migration initiale et ponctuelle 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 mettre en oeuvre CICD pour vos instances et synchroniser les métadonnées. Vous pouvez également utiliser une instance de calcul OCI en tant que serveur d'intégration de composant Jenkins et concentrateur de 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 la récupération après sinistre de pile complète OCI. Il est extrêmement important que les étapes manuelles de permutation d'Oracle Integration documentées par l'ingénierie Oracle Integration soient testées et fonctionnent correctement avant de tenter d'automatiser le processus de permutation ou de basculement à l'aide de la récupération après sinistre de pile complète OCI.

Se familiariser avec l'ensemble du processus

L'équipe d'ingénierie de la récupération après sinistre de pile complète a créé une série de vidéos complémentaires pour ce tutoriel afin de comprendre l'ensemble du flux de processus. These videos are part of a OCI Full Stack DR Oracle Integration playlist in YouTube that can be accessed using the following links:

• Vidéo 1 : Déployer Oracle Integration pour la récupération après sinistre.
• Vidéo 2 : Automatiser les opérations de récupération après sinistre pour Oracle Integration à l'aide de la récupération après sinistre de pile complète OCI.
• Vidéo 3 : Scripts utilisés pour automatiser la récupération pour Oracle Integration.

Partie 2 : Instructions étape par étape

Cette partie commence les instructions étape par étape nécessaires pour ajouter Oracle Integration à la récupération après sinistre de pile complète OCI.

Objectifs

Les étapes suivantes seront décrites dans ce tutoriel expliquant comment automatiser la récupération pour Oracle Integration à l'aide de la récupération après sinistre de pile complète OCI :

1. Tâche 1 : Déployer Oracle Integration pour la reprise après sinistre dans les régions OCI
   1. Préparer le noeud de contrôle RS d'Oracle Integration
   2. Télécharger des scripts personnalisés sur le noeud de contrôle RS
   3. Installer et déployer manuellement Oracle Integration pour la reprise après sinistre sur deux régions OCI
   4. Tester manuellement toutes les étapes de récupération de la région 1 à la région 2 souhaitée
   5. Tester manuellement toutes les étapes de récupération de la région 2 souhaitée à la région 1
2. Tâche 2 : Préparer la récupération après sinistre de pile complète OCI
   1. Créer des politiques IAM pour la récupération après sinistre de pile complète OCI
   2. Créer des politiques IAM pour d'autres services OCI
   3. Créer des seaux de stockage d'objets pour les journaux
3. Tâche 3 : Créer des groupes de protection RS (DRPG)
4. Tâche 4 : Ajouter des membres à la passerelle DRPG de la région 1
5. Tâche 5 : Créer des plans RS 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 RS 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 commencera comme région principale.
  • Ce rôle finira par passer à la base de secours une fois que vous aurez reçu l'ordre d'effectuer une permutation de rôles dans les étapes suivantes.
• La région 2 est Phoenix
  • Phoenix commencera comme région de secours.
  • Ce rôle passera finalement au rôle principal une fois que vous aurez reçu l'ordre d'effectuer une permutation dans les étapes suivantes.

Compartiments

Vous êtes libre d'organiser la reprise après sinistre de pile complète pour Oracle Integration et OCI dans n'importe quel modèle de compartiment qui respecte vos normes de gouvernance informatique. Nous avons choisi d'organiser les applications dans leurs propres compartiments individuels, puis d'organiser tous les groupes de protection RS dans un seul compartiment où des systèmes d'affaires complètement différents peuvent tous être vus en un coup d'œil.

• L'organisation de tous les groupes de protection RS dans un seul compartiment en dehors des applications facilite grandement la localisation et l'exécution des plans de récupération après sinistre pour de nombreux systèmes d'entreprise complètement différents.
• Disposer d'un seul compartiment pour tous les groupes de protection RS contribue à éliminer les erreurs humaines et augmente la vitesse à laquelle les plans RS peuvent être trouvés et exécutés
  • Compartiment pour Oracle Integration : OIC-demo. Le compartiment pour OIC lui-même, le stockage, les seaux de stockage, le calcul et la base de données liés à OIC est OIC-demo dans ce tutoriel.
  • Compartiment pour la récupération après sinistre de pile complète OCI : OIC-demo Le compartiment pour les groupes et plans de protection RS de pile complète OCI est OIC-demo dans ce tutoriel.

Noeud de contrôle Oracle Integration DR

Le noeud de contrôle RS 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 la récupération après sinistre de pile complète OCI lors d'une opération de récupération. Ce tutoriel explique comment ajouter les scripts à la récupération après sinistre de pile complète OCI 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 pour agir en tant qu'hôte pour les scripts personnalisés.
• Pour Oracle Integration dans une pile d'applications : Il s'agit de toute instance de calcul existante membre d'un groupe de protection RS (DRPG). Par exemple, Oracle E-Business Suite ou PeopleSoft aura des serveurs d'applications qui sont membres des mêmes passerelles DRPG qui gèrent la récupération pour Oracle Integration; n'importe lequel d'entre eux peut remplir le rôle de noeud de contrôle DR dans ce tutoriel.

Préalables

Oracle Integration doit être déployé pour la récupération après sinistre dans les deux régions avant de commencer à travailler avec la récupération après sinistre de pile complète OCI. Ceci est couvert dans la tâche 1 ci-dessous.

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

La récupération après sinistre de pile complète OCI n'est impliquée dans aucune partie de cette étape.

Tâche 1.1 : Préparer le noeud de contrôle RS à exécuter l'automatisation personnalisée

Désignez une instance de calcul pour agir en tant que noeud de contrôle RS 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, consultez les options ci-dessous. Assurez-vous que les instances de calcul agissant en tant que noeud de contrôle RS ont été configurées pour exécuter des commandes à l'aide de l'agent OCI Cloud Agent : 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 créerez donc une instance de calcul avec Oracle Linux dans la région 1. Utilisez la forme à faible coût 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 la majorité des organisations.

L'instance de calcul spécialisée sera ajoutée en tant que membre du groupe de protection RS dans la région 1 à une étape ultérieure.

Option 2 : Oracle Integration dans une pile d'applications

Vous pouvez utiliser n'importe quel calcul mobile existant qui fait partie d'une application Oracle ou non Oracle gérée par la récupération après sinistre de pile complète OCI dans la région 1. Cela remplira le rôle du noeud de contrôle RS chaque fois que ce tutoriel se réfère au noeud de contrôle RS.

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 n'avez pas de calcul mobile dans le cadre de votre solution de reprise 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 comportant plusieurs offres PaaS

Votre système d'entreprise comprend peut-être également Oracle HTTP Server (OHS), Oracle Integration et 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 : Assurez-vous que le groupe de volumes est répliqué vers la région 2

Assurez-vous que le volume de démarrage du noeud de contrôle RS est membre d'un groupe de volumes par blocs et que le groupe de volumes par blocs est répliqué vers la région 2.

Assurez-vous que tout autre démarrage et bloc appartenant à tout autre calcul mobile pour ce projet de récupération après sinistre de pile complète OCI appartient également aux groupes de volumes par blocs répliqués dans la région 2. Pour plus de détails, consultez la documentation sur le stockage par blocs d'OCI

Tâche 1.3 : Télécharger les scripts bash sur le noeud de contrôle RS

Téléchargez les scripts bash personnalisés à partir de github qui ont été écrits spécifiquement pour cette solution Oracle Integration DR. Les scripts présentés ci-dessous doivent être copiés dans n'importe quel sous-répertoire de l'instance de calcul en tant que noeud de contrôle RS pour Oracle Integration

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

1. Affiche le chemin du référentiel où se trouvent les scripts bash sur GitHub.
2. Cette section présente le référentiel contenant les scripts bash.

Figure 2-4 : Capture d'écran du référentiel github contenant les scripts bash pour Oracle Integration

Tâche 1.4 : Déployer Oracle Integration pour la reprise après sinistre

Déployer Oracle Integration pour la reprise après sinistre dans les régions OCI à l'aide des instructions étape par étape 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 documentées dans Configuration de récupération après sinistre pour Oracle Integration doivent être réussies avant d'utiliser la récupération après sinistre de pile complète OCI.

Tâche 1.6 : Étapes suivantes

Retournez à ce document pour commencer à utiliser la récupération après sinistre de pile complète OCI une fois les exigences suivantes terminées.

1. Déployez manuellement Oracle Integration pour la reprise après sinistre sur 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éparer la récupération après sinistre de pile complète OCI

La récupération après sinistre de pile complète OCI n'est impliquée 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 récupération après sinistre de pile complète OCI.

Tâche 2.1 : Créer des politiques IAM pour la récupération après sinistre de pile complète OCI

Configurez les politiques OCI IAM requises pour la récupération après sinistre de pile complète, comme indiqué dans les documents suivants.

• Politiques pour la récupération après sinistre de pile complète.
• Configuration des politiques de gestion des identités et des accès (IAM) nécessaires pour la récupération après sinistre de pile complète.

Tâche 2.2 : Créer des politiques IAM OCI pour d'autres services gérés par la récupération après sinistre de pile complète OCI

La récupération après sinistre de pile complète OCI doit avoir la capacité de contrôler et de gérer d'autres services OCI clés tels que le calcul, le réseau, le stockage, les chambres fortes, les bases de données et d'autres services divers. Configurez les politiques IAM OCI requises pour d'autres services, comme expliqué dans le document suivant.

• Politiques pour les autres services gérés par la récupération après sinistre de pile complète.

Tâche 2.3 : Créer des seaux de stockage d'objets OCI pour les journaux DRPG

Note : Ignorez entièrement la tâche 2.3 si vous ajoutez Oracle Integration à des groupes de protection RS existants.

Créez des seaux de stockage d'objets OCI dans les régions principale et de secours pour stocker les journaux générés par la récupération après sinistre de pile complète OCI lors des opérations de récupération : Stockage d'objets.

Tâche 2.3.1 : Naviguer jusqu'au stockage d'objets OCI

Commencez par naviguer jusqu'au stockage d'objets et au stockage d'archives, comme illustré à la figure 2-1 ci-dessous

1. Assurez-vous que le contexte du navigateur est réglé à la région 1 (Ashburn).
2. Sélectionnez Storage.
3. Sélectionner des seaux.

Figure 2-1 : Naviguez jusqu'au stockage d'objets.

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

Créez un compartiment de stockage d'objets dans la région 1. Le seau sera affecté au groupe de protection RS de la région 1 à une étape ultérieure.

1. Sélectionnez le compartiment qui contient les ressources liées à OIC.
2. Sélectionnez Create Bucket.
3. Donnez au seau 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 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 chiffrement.
5. Sélectionnez Create pour créer le seau.

Figure 2-2 : Créez un seau de stockage d'objets dans la région 1

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

Suivez le même processus pour créer un seau de stockage d'objets dans la région 2 (Phoenix). Le seau sera affecté au groupe de protection RS de la région 2 dans une étape ultérieure.

1. Remplacez le contexte par la région 2.
2. Sélectionnez le compartiment qui contient les ressources liées à OIC dans la région 2.
3. Utilisez le même nom exact qui a été affecté au seau dans la région 1, ce qui facilitera l'identification dans une étape ultérieure.
4. Sélectionnez Create pour créer le seau.

Figure 2-3 : Créez un seau de stockage d'objets dans la région 2

Tâche 3 : Créer des groupes de protection RS dans les deux régions

Note : Ignorez entièrement la tâche 3 si Oracle Integration est ajouté à des groupes de protection RS existants.

Créez des groupes de protection RS 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 : Naviguer jusqu'aux groupes de protection RS

Commencez par naviguer jusqu'aux groupes de protection RS (RD de pile complète OCI), comme illustré à la figure 3-1 ci-dessous.

1. Assurez-vous que le contexte de la région OCI est réglé à la région 1 (Ashburn).
2. Sélectionnez Migration & Disaster Recovery.
3. Sélectionnez les groupes de protection RS.

Image 3-1 : Naviguez jusqu'aux groupes de protection RS

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

Créez un groupe de protection RS 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 dans lequel vous souhaitez créer la passerelle DRPG. Il peut s'agir du même compartiment que celui où existent les ressources Oracle Integration ou, comme dans ce cas, d'un compartiment agissant en tant que référentiel contenant des passerelles DRPG pour de nombreux systèmes d'affaires différents.
2. Sélectionnez Create DR protection group pour ouvrir la boîte de dialogue.

Figure 3-2 : Commencez à créer un groupe de protection RS dans la région 1

Ajoutez un nom et un seau de stockage d'objets pour les journaux, comme illustré à la figure 3-3 ci-dessous.

1. Utilisez un nom simple et significatif pour la passerelle DRPG. Cet exemple montre le nom du système d'affaires et de la région.
2. Sélectionnez le seau de stockage d'objets créé dans la tâche 2 pour la région 1.

Figure 3-3 : Paramètres nécessaires pour créer un groupe de protection RS 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 RS 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 la région OCI par la région 2.
2. Sélectionnez le compartiment dans lequel vous souhaitez créer la passerelle DRPG. Il peut s'agir du même compartiment que celui où existent les ressources Oracle Integration ou, comme dans ce cas, d'un compartiment agissant en tant que référentiel contenant des passerelles DRPG pour de nombreux systèmes d'affaires différents.
3. Sélectionnez Create DR protection group pour ouvrir la boîte de dialogue.

Figure 3-4 : Commencez à créer un groupe de protection RS dans la région 2

Ajoutez un nom et un seau de stockage d'objets pour les journaux, comme illustré à la figure 3-5 ci-dessous.

1. Utilisez un nom simple et significatif pour la passerelle DRPG. Cet exemple montre le nom du système d'affaires et de la région.
2. Sélectionnez le seau de stockage d'objets créé dans la tâche 2 pour la région 2

Figure 3-5 : Paramètres nécessaires pour créer un groupe de protection RS dans la région 2

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

Associez les passerelles DRPG de chaque région en tant que pairs les uns des autres et affectez les rôles pairs de base principale et de base de secours. Voici comment la récupération après sinistre de pile complète OCI saura quelles deux régions fonctionnent ensemble pour la récupération d'Oracle Integration. Les rôles de la base principale et de la base de secours sont automatiquement modifiés par la récupération après sinistre de pile complète OCI 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 : Commencer l'association

1. Assurez-vous que le contexte de la région OCI est réglé à la région 1 (Ashburn).
2. Sélectionnez Associer pour lancer le traitement.

Image 3-6 : Commencer l'association DRPG

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

Indiquez les paramètres indiqués à la figure 3-7 ci-dessous.

1. Sélectionnez le rôle principal. La récupération après sinistre de pile complète OCI affectera automatiquement le rôle de secours à la région 2.
2. Sélectionnez la région 2 (Phoenix) où l'autre passerelle DRPG a été créée.
3. Sélectionnez la passerelle DRPG pair dans laquelle elle a été créée.

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

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

La récupération après sinistre de pile complète OCI affiche quelque chose comme la figure 3-8 ci-dessous une fois l'association terminée.

1. La passerelle DRPG pair principale courante est Ashburn (région 1).
2. La passerelle DRPG pair de secours courante est Phoenix (région 2).

Figure 3-8 : Affichage de la relation de pair du point de vue DRPG individuel

Les mêmes informations peuvent être trouvées chaque fois que le contexte / la vue est d'une perspective globale montrant tous les groupes de protection RS comme illustré à la figure 3-9 ci-dessous.

1. La passerelle DRPG pair principale courante est Ashburn (région 1).
2. La passerelle DRPG pair de secours courante est Phoenix (région 2).

Figure 3-9 : Affichage de la relation de pair dans la perspective DRPG globale

Tâche 4 : Ajouter des membres au groupe de protection RS

Note : Cette étape supprimera tous les plans RS existants dans les deux régions lors de l'ajout de membres à des groupes de protection RS existants. La récupération après sinistre de pile complète OCI ne peut pas enregistrer de copies ni effectuer de sauvegardes des groupes de protection RS au moment de cette écriture. Assurez-vous d'avoir enregistré toutes les informations sur les groupes et les étapes de plan RS dans un fichier texte ou une feuille de calcul pour faciliter la recréation des groupes et étapes de plan 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 pour la récupération après sinistre de pile complète OCI pour recréer les groupes de plans et les étapes personnalisés définis par l'utilisateur (cela dépasse la portée de ce tutoriel).

Ajoutez le noeud de contrôle RS en tant que membres au groupe de protection RS principal. Le noeud de contrôle RS est une instance de calcul que vous avez créée uniquement pour contrôler Oracle Integration ou une instance de calcul qui fait partie de la pile d'applications que vous voulez gérer avec la récupération après sinistre de pile complète OCI.

Vous allez ajouter les ressources suivantes à la passerelle DRPG principale de la région 1 :

1. Le noeud de contrôle RS,
2. Groupe de volumes contenant le volume de démarrage du noeud de contrôle RS.

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

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

1. Assurez-vous que le contexte de la région OCI est la région 1 (Ashburn).
2. Sélectionnez la passerelle DRPG dans la région 1.
3. Sélectionner des membres.
4. Cliquez sur Ajouter un membre pour commencer le processus.

Figure 4-1 : Comment commencer à ajouter des membres au groupe de protection RS dans la région 1

Tâche 4.1.1 : Ajouter une instance de calcul pour le noeud RS

Ajoutez une instance de calcul pour le noeud de contrôle RS, comme illustré à la figure 4-2 ci-dessous.

1. Accuser réception de l'avertissement concernant les plans RS.
2. Sélectionnez Compute comme type de ressource membre.
3. Sélectionnez l'instance de calcul à utiliser pour le noeud de contrôle RS.
4. Sélectionnez une instance mobile.
5. Indiquez à OCI la récupération après sinistre de pile complète quel VCN et sous-réseau affecter aux cartes VNIC de la région 2 lors d'une récupération. La figure 4-2 présente une seule carte VNIC. La récupération après sinistre de pile complète d'OCI ne se soucie pas du nombre de cartes vNIC dont vous disposez ou de la configuration dans l'une ou l'autre région; spécifiez ce dont vous avez besoin pour répondre à vos besoins.

Figure 4-2 : Paramètres nécessaires pour ajouter un noeud de contrôle RS

Tâche 4.1.2 : Ajouter un groupe de volumes par blocs pour le noeud RS

Ajoutez le groupe de volumes par blocs contenant le démarrage pour le noeud de contrôle RS. La réplication inter-région doit déjà être configurée pour le groupe de volumes par blocs entre les deux régions avant de l'ajouter au groupe de protection RS.

1. Sélectionnez Groupe de volumes comme type de ressource membre.
2. Assurez-vous que le compartiment approprié 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 de démarrage pour le noeud de contrôle RS

Tâche 4.1.3 : Vérifier les ressources membres pour la région 1

La passerelle DRPG de la région 1 doit comporter 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 par blocs pour l'instance de calcul que nous avons désignée pour agir comme noeud de contrôle RS OIC.

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

Il n'est pas nécessaire d'ajouter des membres au groupe de protection RS de secours, car nous utilisons le déplacement de l'instance de calcul en tant que noeud RS pour héberger les scripts Oracle Integration

Tâche 5 : Créer des plans RS de base dans la région 2 (Phoenix)

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

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

La récupération après sinistre de pile complète OCI préalimentera 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 ultérieurement pour gérer toutes les tâches liées à Oracle Integration lors 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 RS

Créez des plans de base en sélectionnant la passerelle DRPG dans la région 2, comme illustré à la figure 5-1 ci-dessous.

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

Figure 5-1 : Comment commencer à créer des plans RS de base dans la région 2

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

La création d'un plan RS 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'y a que quatre types de plan au moment de l'écriture.

Image 5-2 : Paramètres nécessaires pour créer un plan de permutation RS

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

Suivez le même processus 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'y a que deux types de plan au moment de l'écriture.

Image 5-3 : Paramètres nécessaires pour créer un plan de basculement RS

Le groupe de protection RS de secours de la région 2 devrait maintenant avoir les deux plans RS comme indiqué ci-dessous. Ils traiteront les charges de travail de transition de la région 1 à la région 2. Vous allez créer des plans similaires dans la région 1 pour transférer les charges de travail de la région 2 vers la région 1 dans une étape ultérieure.

Figure 5-4 : Affichage des deux plans RS de base qui doivent exister dans la région 2 avant de poursuivre

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

Les plans RS de base créés dans la tâche 5 contiennent des étapes préalimentées pour les tâches de récupération intégrées à la récupération après sinistre de pile complète OCI 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 RS personnalisés définis par l'utilisateur et les étapes de gestion des 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 : Comment commencer à personnaliser le plan de permutation dans la région 2

Tâche 6.2 : Activer les groupes de plans RS 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 lors des tests que rien n'est réellement supprimé et que vous disposez toujours d'une copie viable des artefacts en tant que sauvegarde en cas de problème lors des tests.

Toutefois, ces deux groupes de plans mettent fin (supprimer) aux artefacts qui ne seront plus jamais utilisés dans le cadre d'une opération de récupération après sinistre. Les artefacts continueront simplement à s'accumuler au fil du temps lorsque vous passerez d'une région à l'autre, ce qui causera de la confusion quant aux instances de calcul et aux groupes de volumes qui devraient être actifs.

Ces groupes de plans doivent être activés une fois la récupération après sinistre de pile complète OCI mise en production. Tous les artefacts qui ont été laissés en place lors des tests de permutation et de permutation alors que ces deux groupes de plans étaient désactivés doivent être arrêtés et nettoyés avant d'être mis en production afin de réduire la confusion et le risque d'erreur humaine lors des opérations normales.

Facultativement, ces groupes de plans peuvent être activés maintenant pour éviter d'avoir à nettoyer manuellement les artefacts superflus avant de passer en production.

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

Voici ce que font les groupes de régimes désactivés lorsqu'ils sont activés :

1. Ce groupe de plans met fin aux artefacts des instances de calcul qui sont 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 par blocs OCI pour inverser la réplication de la région 2 vers 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'annulation de la réplication de volume par blocs crée toutes les nouvelles machines virtuelles dans de nouveaux groupes de volumes par blocs.

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

Tâche 6.2.1 : Activer l'arrêt du groupe de plans de calcul

Activez le groupe de plans.

1. Sélectionner Activer toutes les étapes du menu contextuel à droite du nom du groupe de plans

Image 6-3 : Comment activer l'arrêt des instances de calcul

Tâche 6.2.2 Activer l'arrêt du groupe de plans des groupes de volumes

Activez le groupe de plans.

1. Sélectionner Activer toutes les étapes du menu contextuel à droite du nom du groupe de plans

Image 6-4 : Comment activer l'arrêt des groupes de volumes

Tâche 6.3 : Créer un groupe de plans pour synchroniser les paramètres programmés de la région 1 à la région 2

Commencez maintenant à ajouter des groupes de plans RS personnalisés définis par l'utilisateur.

Le premier groupe de plans défini par l'utilisateur synchronisera les paramètres programmés de la région 1 vers la région. Ce groupe de plans contient une seule étape qui appelle le script bash oic-sync-schedule-parameters.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.4.

Tâche 6.3.1 : Sélectionner Ajouter un groupe de plans

Lancez le traitement d'ajout d'un groupe de plans.

1. Cliquez sur Ajouter un groupe pour commencer.

Image 6-5 : Début de l'ajout d'un groupe de plans pour synchroniser les paramètres programmés

Tâche 6.3.2 : Indiquez le nom du groupe de plans, commandez et ajoutez l'étape

Un groupe de plans RS peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous ne faisons qu'ajouter une seule étape pour exécuter un script bash afin de synchroniser les paramètres programmés.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 dans la région 1.
3. Sélectionnez le groupe de plans intégré Arrêter les instances de calcul (principales).
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour synchroniser les 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 programmés

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution 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 laissez ce détail dans toutes les captures d'écran restantes dans les étapes suivantes puisque nous effectuons le même processus à plusieurs reprises.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Sélectionnez toujours la région où le noeud de contrôle RS s'exécute en ce moment, pas où il s'exécutera lors d'une permutation. La récupération après sinistre de pile complète OCI gardera le suivi de l'exécution de la machine virtuelle. Il vous suffit donc de spécifier l'emplacement actuel. Dans ce cas, le noeud de contrôle RS s'exécute dans la région 1 (Ashburn).
3. Sélectionnez Exécuter un script local pour informer la récupération après sinistre de pile complète OCI 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 RS dans la tâche 1.3.
4. Sélectionnez le compartiment approprié qui contient le noeud de contrôle RS - il peut s'agir de n'importe quel compartiment. Sélectionnez l'instance de calcul désignée comme noeud de contrôle RS (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 où vous avez installé le script oic-sync-schedule-parameters.sh sur le noeud de contrôle RS. Ajoutez PHX comme paramètre. Il s'agit de la région cible dans laquelle nous voulons synchroniser les paramètres programmés. Vous devrez peut-être fournir les paramètres de région corrects si vous utilisez des régions OCI différentes et mettre à jour des scripts.
6. Spécifiez opc comme utilisateur pour exécuter le script.
7. Le plan RS doit s'arrêter si le script ne parvient pas à synchroniser les paramètres programmés. Cela permettra à tout le monde de voir qu'il y a un problème et de le résoudre. La récupération après sinistre de pile complète OCI permet de continuer à exécuter le plan de permutation après avoir corrigé le problème.
8. La valeur par défaut avant que la récupération après sinistre de pile complète OCI déclare un échec est d'une heure. Cette valeur peut être modifiée à 30 minutes ou tout ce qui est considéré comme une valeur de temporisation plus réaliste.
9. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Image 6-7 : Paramètres permettant de créer l'étape de plan pour synchroniser les paramètres programmés

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

L'étape d'arrêt de la synchronisation des paramètres programmés est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 6-8 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée. Il est possible d'ajouter des étapes supplémentaires à un groupe de plans RS, mais ce groupe inclut uniquement l'étape de synchronisation des paramètres programmés.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 6-8 : Finaliser l'ajout d'un groupe de plans et d'une étape pour synchroniser les paramètres programmés

Tâche 6.4 : Créer un groupe de plans pour activer les intégrations pertinentes à la base de secours

Le deuxième groupe de plans défini par l'utilisateur activera les intégrations pertinentes à la base de secours après le lancement du noeud de contrôle RS dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script bash oic-integration-switch.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 6.4.1 : Sélectionner Ajouter un groupe de plans

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

Figure 6-9 : Commencez à ajouter un groupe de plans pour activer les intégrations pertinentes à la base de secours

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

Créez un groupe de plans RS pour commencer à activer les intégrations pertinentes à la base de secours.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 RS 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 spécifierons le script pour activer les intégrations pertinentes à la base de données de secours.

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

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution 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.

Toutes les étapes de cette étape sont identiques à la tâche 6.3.3, à l'exception des éléments présentés à la figure 6-11 ci-dessous.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script oic-integration-switch.sh sur le noeud de contrôle RS. Ajoutez activer comme premier paramètre et PHX comme second.This est la région cible dans laquelle nous voulons activer les intégrations pertinentes. Vous devrez peut-être fournir les paramètres de région corrects si vous utilisez des régions OCI différentes et mettre à jour des scripts.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-11 : Paramètres de création de l'étape de plan pour l'activation des intégrations pertinentes à la base de secours

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

L'étape d'activation des intégrations pertinentes à la base de secours est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 6-12 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 6-12 : Finaliser l'ajout d'un groupe de plans et d'une étape pour activer les intégrations pertinentes à la base 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 à la base de secours après le lancement du noeud de contrôle RS dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script bash oic-integration-schedule.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 6.5.1 : Sélectionner Ajouter un groupe de plans

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

Figure 6-13 : Début de l'ajout d'un groupe de plans pour démarrer les intégrations programmées à la base de données de secours

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

Créez un groupe de plans RS pour démarrer des intégrations programmées dans la région de secours 2.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 à la base de secours
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour démarrer les intégrations programmées à 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 des intégrations programmées à la base de secours

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution de cette étape et son comportement lors de la récupération. Dans ce cas, il lancera des intégrations programmées 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 indiqués dans la figure 6-15 ci-dessous.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script oic-integration-schedule.sh sur le noeud de contrôle RS. Ajoutez start comme premier paramètre et PHX comme deuxième.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 6-15 : Paramètres de création de l'étape de plan pour démarrer les intégrations programmées à la base de secours

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

L'étape de démarrage des intégrations programmées à la base de secours est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 6-16 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 6-16 : Finaliser l'ajout d'un groupe de plans et démarrer les intégrations programmées à la base 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 à la base de secours après le lancement du noeud de contrôle RS dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script bash dns_record_update.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 6.6.1 : Sélectionner Ajouter un groupe de plans

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

Figure 6-17 : Début de l'ajout d'un groupe de plans pour mettre à jour l'enregistrement DNS à la base de secours

Tâche 6.6.2 : Indiquez le nom du groupe de plans, commandez et ajoutez l'étape

Créez un groupe de plans RS pour mettre à jour l'enregistrement DNS vers la région 2.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 à la base de secours
3. Sélectionnez le groupe de plans Démarrer les intégrations programmées à la base de secours intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour mettre à jour l'enregistrement DNS à la base de secours.

Image 6-18 : Paramètres pour créer un groupe de plans et ajouter une étape pour mettre à jour l'enregistrement DNS à la base de secours

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution de cette étape et son comportement lors de la récupération. Dans ce cas, il mettra à jour l'enregistrement DNS à la base de secours.

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

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script dns_record_update.sh sur le noeud de contrôle RS. 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 de création de l'étape de plan pour mettre à jour l'enregistrement DNS à la base de secours

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

L'étape de mise à jour de l'enregistrement DNS à la base de secours est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 6-20 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 6-20 : Finaliser l'ajout du groupe de plans et de l'étape de mise à jour de l'enregistrement DNS à la base de secours

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 final défini par l'utilisateur désactivera les intégrations programmées dans la région 1 après le lancement du noeud de contrôle RS dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script oic-integration-switch.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 6.7.1 : Sélectionner Ajouter un groupe de plans

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

Figure 6-21 : Début de l'ajout d'un groupe de plans pour désactiver les intégrations programmées dans la région 1

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

Créer un groupe de plans RS pour désactiver les intégrations programmées dans la région 1

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 à la base de secours
3. Sélectionnez le groupe de plans Mettre à jour l'enregistrement DNS dans la base de secours intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour désactiver les intégrations programmées dans 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 : Indiquez le nom de l'étape et les paramètres du script local

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution 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 indiqués dans la figure 6-23 ci-dessous.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script oic-integration-switch.sh sur le noeud de contrôle RS. 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 de création de l'étape de plan pour désactiver les intégrations programmées dans la région 1

Tâche 6.7.4 : Terminer l'ajout du groupe de plans et de l'étape

L'étape de désactivation des intégrations programmées dans la région 1 est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 6-20 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

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 RS pour Oracle Integration, comme illustré dans la capture d'écran ci-dessous. Vous pouvez avoir des 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 RS personnalisés définis par l'utilisateur et des étapes pour gérer les tâches à effectuer lors d'un basculement pour Oracle Integration dans la région 2 lors d'une interruption 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 au niveau de 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 naviguer jusqu'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 courant dans la console.
2. Sélectionnez le plan de basculement.

Figure 7-1 : La création commence à personnaliser le plan de basculement dans la région 2

Tâche 7.2 : Sélectionner Ajouter un groupe de plans

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 seule étape qui appelle le script bash oic-integration-switch.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

1. Cliquez sur Ajouter un groupe pour commencer.

Figure 7-2 : Commencez à ajouter un groupe de plans pour activer les intégrations pertinentes.

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

Un groupe de plans RS peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous ne faisons qu'ajouter une seule étape pour exécuter un script bash afin d'activer les intégrations pertinentes.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 spécifierons le script pour 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 à la base de secours

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution 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 laissez ce détail dans toutes les captures d'écran restantes dans les étapes suivantes puisque nous effectuons le même processus à plusieurs reprises.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Le plan RS doit s'arrêter si le script ne parvient pas à activer les intégrations pertinentes. Cela permettra à tout le monde de voir qu'il y a un problème et de le résoudre. La récupération après sinistre de pile complète OCI permet de continuer à exécuter le plan de permutation après avoir corrigé le problème.
3. La valeur par défaut avant que la récupération après sinistre de pile complète OCI déclare un échec est d'une heure. Cette valeur peut être modifiée à 30 minutes ou tout ce qui est considéré comme une valeur de temporisation plus réaliste.
4. Sélectionnez toujours la région où le noeud de contrôle RS s'exécute en ce moment, pas où il s'exécutera lors d'une permutation. La récupération après sinistre de pile complète OCI gardera le suivi de l'exécution de la machine virtuelle. Il vous suffit donc de spécifier l'emplacement actuel. Dans ce cas, le noeud de contrôle RS s'exécute dans la région 1 (Ashburn).
5. Sélectionnez Exécuter un script local pour informer la récupération après sinistre de pile complète OCI 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 RS dans la tâche 1.3.
6. Sélectionnez le compartiment approprié qui contient le noeud de contrôle RS - il peut s'agir de n'importe quel compartiment. Sélectionnez l'instance de calcul désignée comme noeud de contrôle RS (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 où vous avez installé le script oic-integration-switch.sh sur le noeud de contrôle RS. Ajoutez activer comme premier paramètre et PHX comme deuxième.
8. Spécifiez opc comme 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 de création de l'étape de plan pour activer les intégrations pertinentes à la base de secours

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

L'étape d'activation des intégrations pertinentes est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 7-5 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

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 programmés dans la région 2

Le deuxième groupe de plans défini par l'utilisateur mettra à jour les paramètres programmés dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script bash oic-update-parameters.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 7.3.1 : Sélectionner Ajouter un groupe de plans

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

Figure 7-6 : Commencez à ajouter un groupe de plans pour mettre à jour les paramètres programmés à la base de secours

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

Créez un groupe de plans RS pour mettre à jour les paramètres programmés dans la région 2.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 dans le groupe de plans de secours.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour mettre à jour les paramètres programmés à la base de données de secours.

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 à la base de secours

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution de cette étape et son comportement lors de la récupération. Dans ce cas, il récupérera 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 indiqués dans la figure 7-8 ci-dessous.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script oic-update-parameters.sh sur le noeud de contrôle RS. 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 mettre à jour les paramètres programmés à la base de secours

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

L'étape de mise à jour des paramètres programmés à la base de secours est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 7-9 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 7-9 : Finaliser l'ajout de paramètres programmés de mise à jour de groupe de plans et d'étape à la base 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 à la base de secours après le lancement du noeud de contrôle RS dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script bash oic-integration-schedule.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 7.4.1 : Sélectionner Ajouter un groupe de plans

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

Figure 7-10 : Début de l'ajout d'un groupe de plans pour démarrer les intégrations programmées à la base de données de secours

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

Créer un groupe de plans RS pour démarrer les intégrations programmées à la base de secours

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 intégré Mettre à jour les paramètres programmés à la base de secours.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour démarrer les intégrations programmées à 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 à la base de secours

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

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution 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 indiqués dans la figure 6-19 ci-dessous.

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script oic-integration-schedule.sh sur le noeud de contrôle RS. Ajoutez start comme premier paramètre et PHX comme deuxième.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 7-12 : Paramètres de création de l'étape de plan pour démarrer les intégrations programmées à la base de secours

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

L'étape de démarrage des intégrations programmées à la base de secours est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 7-13 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 7-13 : Finaliser l'ajout d'un groupe de plans et d'une étape pour démarrer les intégrations programmées à la base 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 à la base de secours après le lancement du noeud de contrôle RS dans la région de secours 2. Ce groupe de plans contient une seule étape qui appelle le script bash dns_record_update.sh téléchargé sur le noeud de contrôle RS dans la tâche 1.3.

Tâche 7.5.1 : Sélectionner Ajouter un groupe de plans

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

Figure 7-14 : Début de l'ajout d'un groupe de plans pour mettre à jour l'enregistrement DNS à la base de secours

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

Créez un groupe de plans RS pour mettre à jour l'enregistrement DNS vers la région 2.

1. Donnez au groupe de plans un nom simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan RS. 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 à la base de secours
3. Sélectionnez le groupe de plans Démarrer les intégrations programmées à la base de secours intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous spécifierons le script pour mettre à jour l'enregistrement DNS à la base de secours.

Image 7-14 : Paramètres pour créer un groupe de plans et ajouter une étape pour mettre à jour l'enregistrement DNS à la base de secours

Tâche 7.5.3 : Indiquez le nom de l'étape et les paramètres du script local

La boîte de dialogue Ajouter une étape de groupe de plans nous permet de spécifier des paramètres concernant l'exécution de cette étape et son comportement lors de la récupération. Dans ce cas, il mettra à jour l'enregistrement DNS à la base de secours.

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

1. Nom descriptif expliquant quelle tâche cette étape effectue.
2. Collez le chemin absolu où vous avez installé le script dns_record_update.sh sur le noeud de contrôle RS. 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 de création de l'étape de plan pour mettre à jour l'enregistrement DNS à la base de secours

Tâche 7.5.4 : Terminer l'ajout du groupe de plans et de l'étape

L'étape de mise à jour de l'enregistrement DNS à la base de secours est maintenant ajoutée au groupe de plans RS, comme illustré à la figure 7-16 ci-dessous.

1. Cela montre l'étape de plan qui vient d'être ajoutée.
2. Cliquez sur Ajouter pour ajouter le groupe de plans RS et l'étape au plan RS.

Figure 7-16 : Finaliser l'ajout du groupe de plans et de l'étape de mise à jour de l'enregistrement DNS à la base de secours

Le plan de basculement doit désormais inclure les quatre groupes de plans RS pour Oracle Integration, comme illustré dans la capture d'écran ci-dessous. Vous pouvez avoir des 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 RS de permutation et de basculement ont été terminés dans la région de secours 2 (Phoenix). Les plans RS de la région 2 permettent à la récupération après sinistre de pile complète OCI de faire la transition des charges de travail de la région 1 vers la région 2. La tâche suivante consiste à créer des plans de permutation et de basculement dans le groupe de protection pour la région 1 (Ashburn) afin que la récupération après sinistre de pile complète OCI puisse ramener les charges de travail de la région 2 à la région 1.

Toutefois, les plans RS ne peuvent être créés et modifiés que dans le groupe de protection doté du rôle de base de secours. Le groupe de protection RS de la région 1 est actuellement le principal, ce qui signifie que les plans RS 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 secours et la région 2 la principale. Exécutez le plan de permutation qui vient d'être créé pour faire passer la charge de travail de la région 1 (Ashburn) à la région 2 (Phoenix).

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

Exécutez le plan RS pour commencer le processus de transition de la charge de travail Oracle Integration de la région 1 à la région 2.

1. Assurez-vous que le contexte de région est toujours réglé à la région de secours 2 (Phoenix).
2. Utilisez les chemins de navigation en haut de la console pour vous assurer que les détails du groupe de protection RS correspondent au contexte de plan courant.
3. Assurez-vous que le groupe de protection RS 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, retournez aux étapes précédentes pour créer et personnaliser les deux plans RS.
5. Cliquez sur exécuter le plan RS.

Image 8-1 : Affichage de l'exécution d'une permutation vers une région de secours

Tâche 8.2 : Sélectionner le plan de permutation et exécuter

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

1. Sélectionnez le plan de permutation.
2. Assurez-vous que l'option Activer les vérifications préalables est sélectionnée.
3. Cliquez sur exécuter le plan RS pour commencer.

Figure 8-2 : Sélectionnez et exécutez le plan de permutation

Tâche 8.3 : Étapes suivantes

Surveillez le plan de permutation jusqu'à ce que la charge de travail Oracle Integration ait été entièrement transférée de la région 1 à la région 2. La récupération après sinistre de pile complète OCI prend en charge le nettoyage des artefacts et la modification des rôles de base de données principale et de base de secours entre les régions.

La région 2 (Phoenix) sera la région principale et la région 1 (Ashburn) sera la région de secours une fois la reprise après sinistre de pile complète OCI terminée.

Tâche 9 : Créer des plans RS dans la région 1 (Ashburn)

Créez les mêmes plans de base de permutation et de basculement dans le groupe de protection RS pour la région 1 (Ashburn), qui est maintenant l'appairage 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 RS dans les deux régions sont automatiquement annulés dans le cadre de toute opération de récupération après sinistre, de sorte que le groupe de protection de la région 2 deviendra la base de secours et que le groupe de protection de la région 1 deviendra la base principale après un basculement ou une permutation.

La récupération après sinistre de pile complète OCI préalimentera 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 ultérieurement pour gérer toutes les tâches liées à Oracle Integration lors d'une opération de récupération.

Les plans RS 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 RS

Créez des plans de base en sélectionnant la passerelle DRPG dans la région 1, comme illustré à la figure 9-1 ci-dessous.

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

Figure 9-1 : Comment commencer à créer des plans RS de base dans la région 1

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

La création d'un plan RS 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'y a que deux types de plan au moment de l'écriture.

   
   Figure 9-2 : Paramètres nécessaires pour créer un plan de permutation RS

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

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

Suivez le même processus pour créer un plan de basculement de base, comme illustré à 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'y a que deux types de plan au moment de l'écriture.

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

Figure 9-3 : Paramètres nécessaires pour créer un plan de basculement RS

Le groupe de protection RS de secours de la région 1 doit maintenant avoir les deux plans RS comme indiqué ci-dessous. Ceux-ci géreront la transition des charges de travail de la région 2 vers la région 1.

Figure 9-4 : Affichage des deux plans RS de base qui doivent exister dans la région 2 avant de poursuivre

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

Tout sur 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 est fait dans la région 1.

Les plans RS 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 RS personnalisés définis par l'utilisateur et les étapes de gestion des tâches à 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. 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 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 : Comment commencer à personnaliser le plan de permutation dans la région 1

Tâche 10.2 : Activer les groupes de plans RS qui mettent fin aux artefacts (facultatif)

Ce sont les mêmes étapes effectuées pour la région 2 dans une étape précédente; 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 lors des tests que rien n'est réellement supprimé, et vous disposez toujours d'une copie viable des artefacts en tant que sauvegarde en cas de problème lors des tests.

Toutefois, ces deux groupes de plans mettent fin (supprimer) aux artefacts qui ne seront plus jamais utilisés dans le cadre d'une opération de récupération après sinistre. Les artefacts continueront simplement à s'accumuler au fil du temps lorsque vous passerez d'une région à l'autre, ce qui causera de la confusion pour les humains concernant les instances de calcul et les groupes de volumes qui devraient être actifs.

Ces groupes de plans doivent être activés une fois la récupération après sinistre de pile complète OCI mise en production. Tous les artefacts qui ont été laissés en place lors des tests de permutation et de permutation alors que ces deux groupes de plans étaient désactivés doivent être arrêtés et nettoyés avant d'être mis en production afin de réduire la confusion et le risque d'erreur humaine lors des opérations normales.

Facultativement, ces groupes de plans peuvent être activés maintenant pour éviter d'avoir à nettoyer manuellement les artefacts superflus avant de passer en production.

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

Voici ce que font les groupes de régimes désactivés lorsqu'ils sont activés :

1. Ce groupe de plans met fin aux artefacts des instances de calcul qui sont 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 par blocs OCI pour inverser la réplication de la région 1 vers 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'annulation de la réplication de volume par blocs crée toutes les nouvelles machines virtuelles dans de nouveaux groupes de volumes par blocs.

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

Tâche 10.2.1 : Activer l'arrêt du groupe de plans de calcul

Activez le groupe de plans.

1. Sélectionnez Enable all steps from the context menu to the right of the plan group name (Activer toutes les étapes du menu contextuel à droite du nom

Image 10-3 : Comment activer l'arrêt des instances de calcul

Tâche 10.2.2 Activer l'arrêt du groupe de plans des groupes de volumes

Activez le groupe de plans.

1. Sélectionnez Enable all steps from the context menu to the right of the plan group name (Activer toutes les étapes du menu contextuel à droite du nom

Image 10-4 : Comment activer l'arrêt des groupes de volumes

Tâche 10.3 : Créer divers plans définis par l'utilisateur pour le plan de permutation

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. À l'aide du même processus, créez cinq groupes de plans personnalisés définis par l'utilisateur. Vous devez utiliser l'instance de calcul exécutée dans la région Phoenix pour exécuter des scripts.

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

Une fois ceux-ci créés, le plan de permutation doit désormais inclure les cinq groupes de plans RS pour l'intégration Oracle, comme illustré dans la capture d'écran ci-dessous. Vous pouvez avoir des 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 RS personnalisés définis par l'utilisateur et des étapes pour gérer les tâches à effectuer lors d'un basculement pour Oracle Integration dans la région 1 lors d'une interruption 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 au niveau de 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. Mettre à 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. Mettre à jour l'enregistrement DNS dans la région 1.

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

Commencez par naviguer jusqu'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 courant dans la console.
2. Sélectionnez le plan de basculement.

Figure 7-1 : La création commence à personnaliser le 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 attente)

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. À l'aide du processus similaire, créez les quatre groupes de plans personnalisés définis par l'utilisateur ci-dessous. Vous devez utiliser l'instance de calcul exécutée dans la région Phoenix pour exécuter des scripts.

1. Activez les intégrations pertinentes sur la base de données de secours /home/opc/oic-scripts/oic-integration-switch.sh pour activer IAD.

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

3. Démarrez les intégrations programmées à la base de données de secours /home/opc/oic-scripts/oic-integration-schedule.sh et démarrez IAD.

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

Une fois ceux-ci créés, le plan de basculement doit désormais inclure les quatre groupes de plans RS pour l'intégration Oracle, comme illustré dans la capture d'écran ci-dessous. Vous pouvez avoir des 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

Étapes suivantes

La récupération après sinistre de pile complète OCI pour Oracle Integration doit être entièrement mise en oeuvre à ce stade. Toutefois, toutes les fonctionnalités doivent être validées avant d'utiliser la récupération après sinistre de pile complète OCI pour la production. Tous les plans de basculement et de permutation doivent être exécutés pour valider que tout fonctionne comme prévu et que l'équipe de récupération comprend parfaitement l'ensemble du processus.

Test des plans de permutation

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

Test des plans de basculement

Les basculements sont différents. De par leur nature même, les basculements 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 à transférer les charges de travail 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 l'état correct, que les artefacts pour les instances de stockage et de calcul ont été arrêtés, etc. Lisez Réinitialisation de la configuration RS après un basculement dans la documentation de récupération après sinistre de pile complète OCI pour comprendre le processus.

Valider tous les plans RS pour l'acceptation finale

L'équipe de récupération doit effectuer une validation finale pour démontrer l'état de préparation des groupes et plans de protection RS de pile complète OCI pour les charges de travail de production. La région 2 (Phoenix) devrait être la région principale à ce stade du processus. Commencez la validation finale de tous les plans en procédant comme suit :

• Tester la permutation de la région 2 (principale) vers la région 1 (de secours).

• Testez le basculement de la région 1 (principale) vers la région 2 (de secours).

• Préparer la région 1 (principale) pour le basculement à partir de la région 2.

• Testez le basculement de la région 2 (principale) vers 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 RS et la pile d'applications doivent être dans un état opérationnel normal et prêts pour un basculement ou une permutation à ce stade.

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

Liens connexes

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

• Exemples de scripts : Télécharger des exemples de scripts à partir de GitHub

• Liste de lecture Oracle Integration pour la récupération après sinistre de pile complète OCI dans YouTube

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

  • Automatiser les opérations de récupération après sinistre pour Oracle Integration à l'aide de la récupération après sinistre de pile complète OCI (vidéo 2)

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

• OCI - Reprise après sinistre de pile complète

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

• Récupération après sinistre de pile complète OCI - Scripts de groupe définis par l'utilisateur

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

Remerciements

• Auteur - Suraj Ramesh (Gestionnaire de produit de récupération après sinistre de pile complète)

• Contributeurs - Bonnie Rockey (ingénieur en nuage, spécialiste Oracle Integration), Akshay Saxena (ingénieur en nuage, spécialiste Oracle Integration)

Vidéo 1 : Déployer Oracle Integration pour la récupération après sinistre - Vidéo 2 : Automatiser les opérations de récupération après sinistre pour Oracle Integration à l'aide de la vidéo DR de pile complète OCI 3 : Scripts utilisés pour automatiser la récupération pour Oracle Integration

Autres ressources d'apprentissage

Explorez d'autres laboratoires sur docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal YouTube d'Oracle Learning. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

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

---

Titre et droits d'auteur

Automate Recovery for Oracle Integration using OCI Full Stack Disaster Recovery

F99103-01

May 2024

Copyright ©2024,

Oracle et/ou ses sociétés affiliées.