Remarques :

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

Automatiser la récupération pour Oracle E-Business Suite à plusieurs noeuds à l'aide d'OCI Full Stack Disaster Recovery

Introduction

OCI Full Stack Disaster Recovery s'appuie sur les équipes d'ingénierie des applications pour concevoir, écrire et maintenir leurs propres fonctionnalités et fonctionnalités de récupération après sinistre. Si une équipe d'ingénierie des applications dispose de fonctionnalités intégrées de récupération après sinistre natives OCI qui incluent des API de kit de développement logiciel (SDK) OCI pour la récupération après sinistre, cette application peut être ajoutée à Full Stack DR en tant que ressource membre native.

Oracle E-Business Suite ne dispose actuellement d'aucune fonctionnalité ou fonctionnalité de récupération après sinistre native OCI et, en tant que telle, n'est pas une ressource membre native dans Full Stack DR. Cependant, l'équipe d'ingénierie Oracle E-Business Suit a documenté un processus de déploiement et de récupération manuelle d'EBS dans les régions OCI. Le processus manuel peut être automatisé à l'aide de Full Stack DR. Ce document explique comment automatiser le processus de récupération manuelle en ajoutant des groupes de plans personnalisés et définis par l'utilisateur et des étapes aux plans de récupération après sinistre de base pour le basculement, la permutation et les explorations.

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

Oracle E-Business Suite prend en charge les modèles commerciaux en constante évolution, stimule la productivité et répond aux exigences des utilisateurs mobiles d'aujourd'hui. S'appuyant sur 30 ans d'innovation, Oracle E-Business Suite continue de fournir de nouvelles fonctionnalités d'application et d'étendre les fonctionnalités des fonctionnalités existantes tout en vous aidant à tirer parti de tous les avantages d'OCI.

Oracle E-Business Suite fait généralement partie d'un système plus grand

Oracle E-Business Suite est normalement la base d'un système métier plus complexe qui inclut un certain nombre de bases de données supplémentaires, d'applications OCI Marketplace et de services OCI qui doivent tous être récupérés en tant qu'unité unique. Pour simplifier les choses et se concentrer sur Oracle E-Business Suite, ce tutoriel présente uniquement les tâches liées à Oracle E-Business Suite. Mais il est très inhabituel qu'Oracle E-Business Suite soit la seule application faisant partie du groupe de protection de récupération après sinistre et des plans de récupération après sinistre.

Attention à l'implémentation incrémentielle

L'ajout ou la suppression de membres supplémentaires à un groupe de protection de récupération après sinistre après la création de plans de récupération après sinistre entraînera l'actualisation des plans de récupération après sinistre existants dans les groupes de protection des deux régions. Pour plus d'informations, reportez-vous à Actualisation d'un plan de récupération après sinistre.

OCI Full Stack DR est conçu en supposant que l'ensemble de la pile d'applications pour un système métier donné est déjà déployé 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 métier inclut plus d'Oracle E-Business Suite, ajoutez tous les autres services de calcul, de stockage, de bases de données, d'applications ou OCI aux groupes de protection de récupération après sinistre avant de créer des plans de récupération après sinistre.

Fonctionnement de la récupération

La solution de récupération pour Oracle E-Business Suite nécessite OCI Full Stack DR pour exécuter une série de scripts bash personnalisés lors d'une opération de récupération, telle qu'un basculement, une permutation ou des explorations. Dans ce tutoriel, nous allons utiliser les noeuds d'application Oracle E-Business Suite comme noeud de contrôle pour l'hébergement et l'exécution de scripts.

Les scripts référencés dans ce tutoriel sont fournis par l'équipe spécialisée Oracle EMEA Cloud Engineering - Applications Oracle à OCI et disponibles dans les scripts Oracle E-Business Suite pour OCI Full Stack Disaster Recovery. Les scripts bash peuvent avoir besoin d'être légèrement modifiés pour répondre aux besoins uniques de votre déploiement.

Fig. 1 : Scripts Oracle E-Business Suite disponibles dans l'exemple de référentiel GitHub Oracle

Ce tutoriel explique comment télécharger les scripts et comment les utiliser ultérieurement. Ce tutoriel utilise l'option 1 pour héberger les scripts bash uniquement car il n'inclut rien d'autre qu'Oracle E-Business Suite.

Remarque : les scripts suivants sont fournis à titre indicatif. Vous pouvez utiliser vos propres scripts ou les personnaliser en fonction de vos exigences en matière de sécurité et de stratégie d'entreprise.

Option 1 pour les scripts d'hébergement

Installez les scripts bash sur les serveurs d'applications Oracle E-Business Suite exécutés dans les deux régions. Ce tutoriel fait référence aux instances de calcul dans lesquelles vous installez les scripts en tant que noeud de contrôle ou noeud de récupération après sinistre, même s'il s'agit d'un ou de plusieurs serveurs d'applications Oracle E-Business Suite dans votre pile d'applications.

Option 2 pour les scripts d'hébergement

Créez un noeud de contrôle ou un noeud de récupération après sinistre spécialisé pour héberger tous les scripts Oracle E-Business Suite ainsi que les scripts nécessaires pour d'autres applications ou services OCI.

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

En règle générale, OCI Full Stack DR ne nécessite aucun serveur de gestion spécialisé pour automatiser les opérations de récupération. En revanche, vous allez créer une instance de calcul qui servira de serveur de gestion spécialisé dans ce cas. Dans ce document, le serveur de gestion spécialisé est considéré comme un noeud de contrôle ou un noeud de récupération après sinistre. L'objectif global du noeud de contrôle est simplement d'agir comme un serveur où tous les scripts personnalisés peuvent résider et être appelés par OCI Full Stack DR lors d'une opération de récupération.

Remarque : dans ce tutoriel, nous utiliserons l'option 1, dans laquelle nous stockerons les scripts personnalisés liés à l'application Oracle E-Business Suite dans les serveurs d'applications Oracle E-Business Suite.

Architecture de déploiement d'Oracle E-Business Suite

Oracle E-Business Suite doit d'abord être déployé pour la récupération après sinistre dans les régions OCI avant d'introduire OCI Full Stack DR. Il est très important que les étapes manuelles d'exécution d'une récupération soient testées et fonctionnent correctement avant de tenter d'automatiser le processus de récupération à l'aide d'OCI Full Stack DR.

Vous pouvez suivre l'une des deux architectures de référence suivantes présentées ci-dessous lors du déploiement d'Oracle E-Business Suite pour la récupération après sinistre dans les régions OCI. Les deux architectures de référence illustrent une topologie à plusieurs niveaux avec des ressources redondantes réparties dans deux régions OCI.

Les bases de données multi-instances sont créées avec Oracle Real Application Clusters (Oracle RAC) et utilisent Oracle Data Guard pour maintenir la synchronisation de la base de données entre deux régions OCI.

Architecture de référence pour Oracle E-Business Suite avec Oracle Base Database Service

Choisissez cette architecture de déploiement si Oracle E-Business Suite utilise Oracle Base Database Service. Oracle E-Business Suite doit être déployé pour la récupération après sinistre dans deux régions OCI, comme expliqué dans Business Continuity for Oracle E-Business Suite Release 12.2 avec Oracle Database 19c sur les systèmes de base de données Oracle Base Database Service (ID de document 2875417.1). L'illustration illustrée à la figure 1 a été obtenue à partir du document Doc ID 2875417.1.

Fig 1 : architecture de déploiement Oracle E-Business Suite DR à l'aide d'OCI Base Database (pour plus de détails, reportez-vous au document 2875417.1)

Architecture de référence pour Oracle E-Business Suite utilisant Oracle Exadata Database Service on Dedicated Infrastructure

Choisissez cette architecture de déploiement si Oracle E-Business Suite utilise Oracle Exadata Database Service on Dedicated Infrastructure. Oracle E-Business Suite doit être déployé pour la récupération après sinistre dans deux régions OCI, comme expliqué dans Business Continuity for Oracle E-Business Suite Release 12.2 avec Oracle Database 19c sur Oracle Exadata Database Service on Dedicated Infrastructure (ID de document 2919723.1). L'illustration illustrée à la figure 1 a été obtenue à partir du document Doc ID 2919723.1.

Fig 2 : architecture de déploiement Oracle E-Business Suite DR avec OCI Exadata Database (pour plus de détails, reportez-vous au document 2919723.1)

Différence entre les noms d'hôte logiques et les noms d'hôte physiques

Oracle E-Business Suite suggère fortement d'utiliser des noms d'hôte logiques pour les serveurs d'applications et des noms d'hôte physiques pour la base de données. La continuité des activités pour Oracle E-Business Suite version 12.2 avec Oracle Database 19c sur les systèmes de base de données Oracle Base Database Service (ID de document 2875417.1) et la continuité des activités pour Oracle E-Business Suite version 12.2 avec Oracle Database 19c sur les systèmes de base de données Oracle Base Database Service (ID de document 2919723.1) écrites par l'ingénierie Oracle E-Business Suite exigent que le niveau d'application utilise des noms d'hôte logiques tandis que le niveau de base de données utilise des noms d'hôte physiques.

OCI Full Stack DR n'a aucune exigence quant à l'utilisation des noms d'hôte logiques ou physiques, mais nous vous recommandons de respecter les exigences Oracle E-Business Suite afin de garantir le support fourni par Oracle E-Business Suite en cas de problème. Certains clients utilisent des noms d'hôte logiques pour les niveaux application et base de données. Les scripts fournis avec cette solution sont conçus pour être utilisés avec des noms d'hôte logiques pour le niveau application et le niveau base de données des noms d'hôte physiques. Pour obtenir des instructions de téléchargement, reportez-vous à la tâche 1.2.

Architecture de déploiement d'OCI Full Stack DR

Les illustrations suivantes montrent les ressources de calcul ajoutées en tant que membres à chaque groupe de protection de récupération après sinistre (DRPG) pour OCI Full Stack DR. Ces composants représentent les différents composants qu'OCI Full Stack DR peut gérer en dehors de l'application Oracle E-Business Suite.

OCI Full Stack DR dispose d'une automatisation intégrée pour gérer OCI Compute, OCI Block Storage, OCI File Storage, les bases de données Oracle, OCI Load Balancer, les clusters Oracle Cloud Infrastructure Kubernetes Engine (OKE) et de nombreuses autres ressources pendant une récupération, mais elle ne dispose pas d'une automatisation intégrée pour Oracle E-Business Suite elle-même. La récupération Oracle E-Business Suite est contrôlée par une série de scripts bash qui peuvent être téléchargés à partir d'un référentiel GitHub dédié à ce tutoriel. Les scripts bash doivent être installés sur l'instance de calcul de votre choix, en suivant l'une des options suivantes pour le placement et le contrôle des scripts.

Option 1 : automatiser la récupération pour Oracle E-Business Suite à l'aide d'Oracle Base Database Service

Cette architecture de déploiement n'est pas typique et a été conçue pour de très rares situations où Oracle E-Business Suite est la seule application récupérée par OCI Full Stack DR. Dans ce cas, nous hébergerons les scripts personnalisés dans les noeuds d'application Oracle E-Business Suite.

Fig 3 : architecture de déploiement de récupération après sinistre de pile complète à l'aide du service OCI Base Database

Option 2 : automatisation de la récupération pour Oracle E-Business Suite à l'aide d'Oracle Exadata Database Service on Dedicated Infrastructure

L'architecture de déploiement simplifiée illustrée à la figure 4 est un exemple de déploiement plus courant d'Oracle E-Business Suite, qui n'est qu'un composant d'une pile d'applications plus grande et plus complexe où de nombreux services et applications doivent être récupérés ensemble. La plupart des systèmes métier sont beaucoup plus complexes que le système fictif illustré dans l'image suivante et incluent généralement des bases de données supplémentaires, d'autres applications Oracle et/ou non Oracle, ainsi que d'autres services OCI tels qu'OIC, ODI, OHS, OCI IAM, etc.

Fig 4 : architecture de déploiement de récupération après sinistre de pile complète utilisant Oracle Exadata Database Service on Dedicated Infrastructure

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

Régions

Le rôle de la base de données principale et de la base de données de secours sont fonction des groupes de protection OCI Full Stack DR, et non des régions elles-mêmes. Une région peut fonctionner comme principale pour une pile d'applications, mais aussi comme de secours pour une pile d'applications complètement différente. Le rôle de la base principale et de la base de secours est fluide.

Ce tutoriel commence par la pile d'applications Oracle E-Business Suite exécutée dans Phoenix et toutes les ressources de secours exécutées dans Ashburn. Ces deux régions sont des exemples uniquement. En pratique, vous pouvez utiliser deux régions OCI qui prennent en charge votre pile d'applications.

• La région 1 est Phoenix.

  • Phoenix commencera comme la région principale.
  • Phoenix commence comme région principale parce que :
    • L'application Oracle E-Business Suite est exécutée à Phoenix.
    • Le travail cron rsync d'Oracle E-Business Suite copie les données de /u01 sur les serveurs d'applications (VM) Oracle E-Business Suite à Phoenix vers les serveurs d'applications exécutés à Ashburn.
    • La base de données de Phoenix a le rôle principal Oracle Data Guard.
  • Phoenix finira par devenir la base de secours une fois que vous serez invité à effectuer une permutation dans des tâches ultérieures.

• La région 2 est Ashburn.

  • Ashburn démarre en tant que région de secours.
  • Ashburn commence comme région de secours pour les raisons suivantes :
    • Les serveurs d'applications de secours Oracle E-Business Suite sont exécutés à Ashburn.
    • L'application Oracle E-Business Suite n'est pas exécutée à Ashburn.
    • Les données de /u01 sont copiées de Phoenix vers les machines virtuelles d'Ashburn.
    • La base de données d'Ashburn a le rôle de secours Oracle Data Guard.
  • Ashburn finira par devenir la principale lorsque vous serez invité à effectuer une permutation dans des tâches ultérieures.

Catégories

Vous êtes libre d'organiser Oracle E-Business Suite et OCI Full Stack DR 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 de récupération après sinistre dans un seul compartiment où tous les systèmes métier peuvent être vus en un coup d'œil.

• L'organisation de tous les groupes de protection de récupération après sinistre dans un seul compartiment en dehors des applications permet au personnel informatique de localiser et d'exécuter plus facilement des plans de récupération après sinistre pour de nombreux systèmes métier complètement différents.
• Le fait de disposer d'un seul compartiment pour tous les groupes de protection de récupération après sinistre permet d'éliminer les erreurs humaines et d'accélérer la recherche et l'exécution des plans de récupération après sinistre.
  • Compartiment pour Oracle E-Business Suite (ebstesting). Le compartiment pour Oracle E-Business Suite lui-même, le stockage, les buckets de stockage, le calcul et la base de données liés à Oracle E-Business Suite est ebstesting dans ce tutoriel.
  • Compartiment pour OCI Full Stack DR myprojects. Le compartiment pour les plans et groupes de protection de récupération après sinistre OCI Full Stack est myprojects dans ce tutoriel.

Objectifs

Les tâches suivantes seront traitées dans ce tutoriel expliquant comment automatiser la récupération pour Oracle E-Business Suite à l'aide d'OCI Full Stack DR.

Remarque : Nous commençons par la région 1 (Phoenix) et la région 2 (Ashburn). L'application Oracle E-Business Suite de production s'exécute dans la région 1 et la récupération après sinistre est configurée dans la région. Cela est très important car tout au long du tutoriel, nous faisons référence à la région 1 et à la région 2 plutôt qu'à la région réelle name.If, votre déploiement utilise différentes régions OCI. Veillez ensuite à faire référence à ces régions de production et de récupération après sinistre respectives.

1. Tâche 1 : déployer Oracle E-Business Suite pour la récupération après sinistre dans les régions OCI.

   1. Installez et déployez manuellement Oracle E-Business Suite pour la récupération après sinistre dans deux régions OCI.
   2. Testez manuellement toutes les étapes de récupération de la région 1 à la région 2 souhaitée.
   3. Testez manuellement toutes les étapes de récupération de la région 2 à la région 1 souhaitée.

2. Tâche 2 : préparation d'OCI Full Stack DR.

   1. Configurez des stratégies OCI IAM pour Full Stack DR.
   2. Configurez des stratégies OCI IAM pour d'autres services OCI.
   3. Télécharger et installer des scripts Oracle E-Business Suite personnalisés sur des serveurs d'applications Oracle E-Business Suite.
   4. Assurez-vous que les serveurs d'applications Oracle E-Business Suite peuvent exécuter des scripts et des commandes.
   5. Créez des clés secrètes de coffre pour la base de données Oracle E-Business Suite.
   6. Créez des buckets de stockage d'objet pour les journaux.

3. Tâche 3 : créer et associer des groupes de protection de récupération après sinistre.

4. Tâche 4 : ajoutez des membres de base de données et de calcul Oracle E-Business Suite aux groupes de protection de récupération après sinistre des régions 1 et 2.

5. Tâche 5 : créez les plans de récupération après sinistre dans la région 2 (Ashburn).

   1. Créer un plan de permutation.
   2. Créer un plan de basculement.
   3. Créer un plan d'analyse de démarrage.

6. Tâche 6 : personnalisez les plans de récupération après sinistre dans la région 2 (Ashburn).

7. Tâche 7 : exécutez le plan de permutation dans la région 2 (Ashburn).

8. Tâche 8 : créer des plans de récupération après sinistre de base dans la région 1 (Phoenix) et personnaliser les plans de récupération après sinistre dans la région 1 (Phoenix).

   1. Créez un plan de permutation et personnalisez le plan de permutation dans la région 1 (Phoenix).
   2. Créez un plan de basculement et personnalisez-le dans la région 1 (Phoenix).
   3. Créez un plan de démarrage et personnalisez le plan de démarrage dans la région 1 (Phoenix).

Prérequis

Oracle E-Business Suite doit être déployé pour la récupération après sinistre dans les deux régions avant de commencer à travailler avec OCI Full Stack DR. Cette question est traitée dans la tâche 1.

Tâche 1 : déploiement d'Oracle E-Business Suite pour la récupération après sinistre

OCI Full Stack DR n'est impliqué dans aucune partie de cette tâche.

Oracle E-Business Suite doit être déployé pour la récupération après sinistre dans les régions OCI à l'aide de l'un des deux articles de la base de connaissances My Oracle Support (MOS) (notes de module de connaissances) différents avant de commencer à utiliser OCI Full Stack DR.

Il est également très important que les étapes manuelles décrites dans les notes du module de connaissances, ainsi que les scripts/automatisation personnalisés nécessaires à la récupération d'Oracle E-Business Suite, aient été entièrement testées avant de commencer à travailler avec OCI Full Stack DR.

Oracle E-Business Suite prend actuellement en charge les services Oracle Base Database Service et Oracle Exadata Database Service on Dedicated Infrastructure. Le service Oracle Autonomous Database n'est actuellement pas pris en charge avec Oracle E-Business Suite. Suivez les instructions figurant dans l'une ou l'autre des notes de module de connaissances suivantes :

• ID document 2875417.1 : Déployer Oracle E-Business Suite pour la récupération après sinistre à l'aide de BaseDB

• ID document 2919723.1 : Déployer Oracle E-Business Suite pour la récupération après sinistre à l'aide de ExaDB-D

Tâche 2 : préparation de la location pour OCI Full Stack DR

OCI Full Stack DR n'est impliqué dans aucune partie de cette tâche. Les étapes suivantes préparent la location, le compartiment, les services OCI et Oracle E-Business Suite pour une récupération automatisée par OCI Full Stack DR. La plupart des tâches décrites dans cette section sont traitées dans Prérequis pour la récupération après sinistre de pile complète.

Tâche 2.1 : configuration des stratégies OCI IAM pour OCI Full Stack DR

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

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

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

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

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

Tâche 2.3 : téléchargement et installation d'Oracle E-Business SuiteScripts personnalisé sur les serveurs d'applications Oracle E-Business Suite

OCI Full Stack DR dispose d'une intelligence intégrée pour orchestrer la récupération pour les ressources OCI Infrastructure as a Service (IaaS) et Platform as a Service (PaaS). OCI Full Stack DR ne dispose pas d'intelligence intégrée pour orchestrer la récupération pour Oracle E-Business Suite, car Oracle E-Business Suite ne fournit actuellement pas d'API de récupération après sinistre native OCI pour déployer ou gérer sa propre récupération après sinistre intégrée.

Cependant, OCI Full Stack DR peut toujours orchestrer la récupération pour Oracle E-Business Suite en ajoutant des groupes de plans de récupération après sinistre définis par l'utilisateur et des étapes aux plans de récupération après sinistre de base créés ultérieurement dans ce tutoriel. Comme indiqué dans la partie 1 de ce tutoriel, les étapes définies par l'utilisateur appellent une série de scripts personnalisés qui effectuent diverses tâches nécessaires à la récupération d'Oracle E-Business Suite. Les scripts doivent être téléchargés et installés sur toutes les instances de calcul des serveurs d'applications Oracle E-Business Suite dans les deux régions :

1. Téléchargez les scripts Oracle E-Business Suite à partir d'ici : Scripts Oracle E-Business Suite pour OCI Full Stack Disaster Recovery.
2. Copiez les scripts dans n'importe quel répertoire sur chacun des serveurs d'applications Oracle E-Business Suite de la région 1.
3. Copiez les scripts dans le même emplacement de répertoire sur chacun des serveurs d'applications Oracle E-Business Suite de la région 2.
4. Vérifiez que les fichiers appartiennent à l'utilisateur oracle.
5. Assurez-vous que les fichiers sont exécutables.

Tâche 2.4 : Vérifier que les serveurs d'applications Oracle E-Business Suite peuvent exécuter des scripts et des commandes

OCI Full Stack DR devra exécuter les scripts Oracle E-Business Suite téléchargés sur les serveurs d'applications Oracle E-Business Suite. OCI Full Stack DR exécute les scripts à l'aide de l'agent Oracle Cloud sur chaque instance de calcul. Il est très important que toutes les instances de calcul utilisées en tant que serveurs d'applications Oracle E-Business Suite dans les deux régions puissent exécuter des commandes via la console OCI à l'aide de l'agent Oracle Cloud.

Pour plus d'informations, reportez-vous à Préparation d'instances Compute pour Full Stack Disaster Recovery. Portez une attention particulière aux instructions pour Exécution de commandes avec des privilèges d'administrateur.

Vérifier que les commandes peuvent être exécutées à partir de la console OCI

Remarque : cette tâche permet de s'assurer que l'agent Oracle Could Agent peut exécuter des commandes. Elle ne vérifie pas que les stratégies appropriées sont en place pour autoriser Full Stack DR à exécuter des commandes via l'agent Oracle Cloud. Cela apparaîtra dans les étapes ultérieures lorsque le tutoriel expliquera comment valider le plan de récupération après sinistre de permutation dans la région 2.

Utilisez la fonctionnalité Exécuter la commande de Compute Instanced pour vérifier que l'agent Oracle Cloud peut exécuter des commandes. Les images suivantes montrent la commande Run sur la page de détails des instances de calcul dans la console OCI.

1. Sélectionnez Exécuter la commande.
2. Sélectionnez Créer une commande et saisissez toute commande Linux valide, telle que date. Remplacez le délai d'expiration par quelque chose de raisonnable comme 3 minutes avant d'exécuter la commande.

Figure 2.4.1.1 : exécutez une commande à partir de la console OCI.

Tâche 2.5 : créer des clés secrètes OCI Vault pour la base de données Oracle E-Business Suite

OCI Full Stack DR aura besoin du mot de passe sys de la base de données afin de pouvoir déclencher automatiquement Oracle Data Guard lors des basculements et des permutations. Ajoutez le mot de passe sys de base de données à une clé secrète de coffre dans les deux régions, comme expliqué ici : Préparation des bases de données Oracle pour Full Stack Disaster Recovery.

Tâche 2.6 : création de buckets OCI Object Storage pour les journaux

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

Créez des buckets OCI Object Storage dans les régions principale et de secours pour stocker les journaux générés par OCI Full Stack DR lors des opérations de récupération après sinistre, comme expliqué ici : Préparation de l'emplacement des journaux d'opérations.

Tâche 2.6.1 : accédez à OCI Object Storage

Commencez par accéder à Object Storage & Archive Storage, comme illustré à la figure 2-1.

1. Assurez-vous que le contexte du navigateur est défini sur la région 1 (Phoenix).
2. Cliquez sur Stockage.
3. Cliquez sur Buckets.

Figure 2.6.1.1 : Accédez au stockage d'objets.

Tâche 2.6.2 : création d'un bucket OCI Object Storage dans les régions 1 et 2

Créez un bucket OCI Object Storage dans la région 1. Créez ensuite un bucket de stockage identique dans la région 2. Les buckets seront affectés aux groupes de protection de récupération après sinistre des régions 1 et 2 dans une tâche ultérieure.

1. Sélectionnez le compartiment contenant les ressources associées à Oracle E-Business Suite. Le compartiment peut être différent dans chaque région.
2. Cliquez sur Créer un bucket.
3. Donnez au bucket un nom significatif qui identifie facilement l'application et l'objectif 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 OCI Full Stack liés aux opérations de récupération après sinistre pour Oracle E-Business Suite.
4. Utilisez la valeur par défaut pour Niveau et Cryptage.
5. Cliquez sur Créer pour créer le bucket.

Figure 2.6.2.1 : créer un bucket de stockage d'objets dans les régions 1 et 2

Tâche 3 : création et association de groupes de protection de récupération après sinistre

Il s'agit de la première tâche impliquant Full Stack DR. Créez des groupes de protection de récupération après sinistre dans les régions 1 et 2 si les groupes de protection de cette pile d'applications n'existent pas encore.

Remarque : ignorez entièrement la tâche 3 si Oracle E-Business Suite est ajouté à des groupes de protection de récupération après sinistre existants.

Cette tâche commence la première étape de configuration d'OCI Full Stack DR pour la pile d'applications qui inclut Oracle E-Business Suite. Les groupes de protection de récupération après sinistre indiquent à OCI Full Stack DR quels services OCI IaaS et PaaS font partie d'une pile d'applications unique et quels sont les deux régions qui agiront en tant que principale et de secours pour le système métier. Les groupes de protection de récupération après sinistre constituent la base sur laquelle tout le reste est construit.

Toutes les ressources OCI IaaS et PaaS qui appartiennent à la pile d'applications dans les deux régions seront ajoutées dans le cadre de la tâche 4.

Remarque : bien que ce tutoriel ne contienne que Oracle E-Business Suite, les groupes de protection de récupération après sinistre contiennent normalement les services OCI IaaS et PaaS pour de nombreuses applications Oracle et non Oracle différentes, ainsi que ceux requis par Oracle E-Business Suite.

Tâche 3.1 : créer un groupe de protection dans la région de secours 2 (Ashburn)

Commencez par créer un groupe de protection de récupération après sinistre non associé dans la région 2. Il n'est pas nécessaire que le groupe de protection soit créé dans la région de secours, le processus s'écoule un peu mieux en commençant dans la région 2.

Tâche 3.1.1 : accédez aux groupes de protection de récupération après sinistre

Commencez par accéder aux groupes de protection de récupération après sinistre (OCI Full Stack DR), comme indiqué dans la figure 3.1.1.

1. Assurez-vous que le contexte de région OCI est défini sur la région 2 (Ashburn).
2. Cliquez sur Migration et récupération après sinistre.
3. Cliquez sur Groupes de protection de récupération après sinistre.

Figure 3.1.1 : Accédez aux groupes de protection de récupération après sinistre.

Tâche 3.1.2 : créer le groupe de protection

Créez un groupe de protection de récupération après sinistre (DRPG) de base dans la région 2, comme indiqué dans la figure 3-1-2. Le pair, le rôle et les membres seront affectés dans des étapes ultérieures.

1. Sélectionnez le compartiment dans lequel créer le DRPG. Il peut s'agir du compartiment dans lequel des ressources Oracle E-Business Suite existent ou de tout autre compartiment lié au projet.
2. Sélectionnez Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue dans laquelle vous allez saisir les paramètres de création du groupe de protection.

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

Tâche 3.1.3 : Ajouter les paramètres nécessaires à la création du groupe de protection

Ajoutez un nom et un bucket OCI Object Storage pour les journaux, comme indiqué dans la figure 3.1.3.

1. Utilisez un nom simple et significatif pour DRGP. Cet exemple montre le nom du système métier et de la région.
2. Sélectionnez le compartiment dans lequel créer le DRPG dans la région 2.
3. Sélectionnez le bucket de stockage d'objet créé dans la tâche 2 pour la région 2. Vous devrez peut-être modifier le compartiment si vous avez créé le bucket dans un autre compartiment.

N'entrez aucun paramètre supplémentaire. Cliquez sur Créer en bas de la boîte de dialogue (non illustré ici).

Figure 3.1.3 : Paramètres nécessaires pour créer un groupe de protection de récupération après sinistre dans la région 2

Ce que vous devez voir après la création du groupe de protection

Le premier groupe de protection de récupération après sinistre sera créé comme illustré à la figure 3-2.3. Les rôles et les informations sur les pairs seront affectés dans le cadre de la tâche 3.4.

Figure 3.1.4 : Affichage du groupe de protection de récupération après sinistre nouvellement créé dans la région 2

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

Créez un groupe de protection dans la région 1. Dans une tâche ultérieure, vous ajouterez toutes les ressources OCI qui appartiennent à la pile d'applications dans cette région. C'est ainsi qu'OCI Full Stack DR sait quelles ressources sont considérées comme faisant partie d'un système métier dans cette région.

Tâche 3.2.1 : créer le groupe de protection

Créez un groupe de protection de récupération après sinistre (DRPG) de base dans la région 1, comme indiqué dans la figure 3.2.1. Le pair, le rôle et les membres seront affectés dans des étapes ultérieures.

1. Remplacez le contexte de région OCI par la région 1.
2. Sélectionnez le compartiment dans lequel créer le DRPG. Normalement, les utilisateurs choisissent le même compartiment que celui utilisé pour créer le DRPG dans la région 2.
3. Sélectionnez Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue dans laquelle vous allez entrer les paramètres de création du groupe de protection.

Figure 3.2.1 : commencez à créer un groupe de protection de récupération après sinistre dans la région 1.

Tâche 3.2.2 : ajouter les paramètres nécessaires à la création du groupe de protection

Ajoutez un nom et un bucket de stockage d'objet pour les journaux, comme illustré à la figure 3-5.

1. Utilisez un nom simple et significatif pour le groupe PRotection de récupération après sinistre. Cet exemple montre le nom du système métier et de la région.
2. Sélectionnez le compartiment dans lequel créer le DRPG dans la région 1. Les personnes utilisent généralement le même compartiment dans les deux régions.
3. Sélectionnez le bucket de stockage d'objet créé dans la tâche 2 pour la région 1. Vous devrez peut-être modifier le compartiment si vous avez créé le bucket dans un autre compartiment.

Figure 3.2.2 : Paramètres nécessaires pour créer un groupe de protection de récupération après sinistre dans la région 1

Ce que vous devez voir après la création du groupe de protection

Le deuxième groupe de protection de récupération après sinistre sera créé comme indiqué dans la figure 3.2.3. Les rôles et les informations sur les pairs seront affectés dans le cadre de la tâche 3.3.

Figure 3.2.3 : Affichage du groupe de protection de récupération après sinistre nouvellement créé dans la région 2

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

Associez les DRPG de chaque région en tant que pairs les uns des autres et affectez les rôles de base de données principale et de base de données de secours. C'est ainsi qu'OCI Full Stack DR saura quelles deux régions fonctionnent ensemble pour la récupération d'Oracle E-Business Suite. Les rôles de la base de données principale et de la base de données de secours sont automatiquement modifiés par OCI Full Stack DR dans le cadre de toute exécution d'opération de récupération après sinistre/de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment après l'affectation des rôles initiaux aux DRPG dans cette tâche.

Tâche 3.3.1 : démarrer l'association

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

Figure 3.3.1 : Commencer l'association DRPG

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

Indiquez les paramètres comme indiqué dans la figure 3.3.2.

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

Figure 3.3.2 : Paramètres nécessaires pour associer les DRPG

Ce que vous devriez voir une fois l'association terminée :

OCI Full Stack DR montrera quelque chose comme la figure 3.3.3 une fois l'association terminée.

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

Figure 3.3.3 : Affichage de la relation homologue du point de vue du DRPG individuel

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

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

Figure 3.4.3.2 : Affichage de la relation homologue du point de vue global DRPG

Tâche 4 : ajouter des membres Oracle E-Business Suite aux groupes de protection de récupération après sinistre des régions 1 et 2

Ajoutez la base de données et les serveurs d'applications Oracle E-Business Suite non mobiles en tant que membres du groupe de protection de récupération après sinistre (DRPG) dans les deux régions. Le calcul mobile signifie que les serveurs d'applications Oracle E-Business Suite qui existent dans la région 1 ne sont jamais lancés ou démarrés dans la région 2. Les volumes d'initialisation pour un calcul non mobile ne sont pas répliqués à l'aide de la réplication OCI Storage vers la région 2 et ne sont ajoutés en tant que membres d'aucun des groupes de protection de récupération après sinistre.

Ce tutoriel présente uniquement les étapes liées à Oracle E-Business Suite, mais vous devez également saisir cette occasion pour ajouter d'autres services OCI IaaS et PaaS qui doivent être récupérés avec Oracle E-Business Suite. Par exemple, il peut y avoir d'autres instances de calcul mobiles, des instances de calcul mobiles, des bases de données, des équilibreurs de charge, des systèmes de fichiers, du stockage de blocs ou du stockage d'objets associés à d'autres applications internes ou Oracle qui font partie de l'écosystème Oracle E-Business Suite.

Remarque : cette tâche actualisera tous les plans de récupération après sinistre existants dans les deux régions lors de l'ajout de membres à des groupes de protection de récupération après sinistre existants. Pour plus d'informations, reportez-vous à Actualisation d'un plan de récupération après sinistre.

Tâche 4.1 : ajouter des ressources membres au groupe de protection de récupération après sinistre à la région 1 (Phoenix)

Vous allez ajouter les ressources suivantes en tant que membres du DRPG principal dans la région 1.

1. Deux serveurs d'applications Oracle E-Business Suite mobiles (Oracle E-Business Suite est installé et en cours d'exécution).
2. Base de données Oracle RAC pour Oracle E-Business Suite (homologue principal Oracle Data Guard).

Tâche 4.1.1 : accédez au groupe de protection de récupération après sinistre principal

Accédez au groupe de protection de récupération après sinistre dans la région 1, comme indiqué dans la figure 4.1.1.

1. Assurez-vous que le contexte de la région OCI est la région 1 (Phoenix).
2. Sélectionnez le groupe de protection de récupération après sinistre dans la région 1.

Figure 4.1.1 : Accédez au groupe de protection de récupération après sinistre dans la région 1.

Tâche 4.1.2 : Ajouter Oracle E-Business Suite Application Server 1

Commencez par ouvrir la boîte de dialogue Ajouter un membre pour ajouter le premier serveur d'applications.

1. Cliquez sur Membres.
2. Cliquez sur Ajouter un membre,

Figure 4.1.2.1 : Ouvrez la boîte de dialogue Ajouter des membres.

Sélectionnez le serveur d'applications 1 dans la région 1, comme illustré dans la figure 4.1.2.2. Vous n'avez pas besoin d'ajouter de groupes de volumes de blocs ou d'indiquer de propriétés réseau car il s'agit d'une instance non mobile.

1. Sélectionnez Calcul comme type de ressource.
2. Choisissez le compartiment contenant les serveurs d'applications Oracle E-Business Suite et sélectionnez l'instance de calcul que vous avez désignée comme serveur d'applications 1.
3. Sélectionnez Instance non mobile. Elle indique à OCI Full Stack DR qu'elle ne doit pas tenter de lancer une machine virtuelle répliquée dans la région de secours lors d'une opération de récupération après sinistre.
4. Cliquez sur Ajouter pour ajouter l'instance de calcul au DRPG (non affiché).

Figure 4.1.2.2 : Indiquer les paramètres du serveur d'applications 1

Tâche 4.1.3 : Ajouter Oracle E-Business Suite Application Server 2

1. Cliquez sur Ajouter un membre,

   
   Figure 4.1.3.1 : Ouvrez la boîte de dialogue Ajouter des membres.

Sélectionnez le serveur d'applications 2 dans la région 1, comme illustré dans la figure 4.1.3.2. Vous n'avez pas besoin d'ajouter de groupes de volumes de blocs ou d'indiquer de propriétés réseau car il s'agit d'une instance non mobile.

1. Sélectionnez Calcul comme type de ressource.
2. Choisissez le compartiment contenant les serveurs d'applications Oracle E-Business Suite et sélectionnez l'instance de calcul que vous avez désignée comme serveur d'applications 2.
3. Sélectionnez Instance non mobile. Elle indique à OCI Full Stack DR qu'elle ne doit pas tenter de lancer une machine virtuelle répliquée dans la région de secours lors d'une opération de récupération après sinistre.
4. Cliquez sur Ajouter pour ajouter l'instance de calcul au DRPG (non affiché).

Figure 4.1.3.2 : Indiquer les paramètres du serveur d'applications 2

Tâche 4.1.4 : Ajouter une base de données Oracle Database principale en cluster

1. Cliquez sur Ajouter un membre pour ajouter la base de données en tant que membre.

   
   Figure 4.1.4.1 : Ouvrez la boîte de dialogue Ajouter des membres.

Sélectionnez la base de données RAC pour Oracle E-Business Suite dans la région 1, comme illustré dans la figure 4.1.4.2. Cela fonctionne exactement de la même manière pour les bases de données à instance unique.

1. Choisissez Base de données comme type de ressource. Le type de ressource Base de données permet de choisir entre Oracle Base Database Service ou Oracle Exadata Database Service on Dedicated Infrastructure, tous deux pris en charge par l'ingénierie Oracle E-Business Suite en tant que choix valides.
2. L'image montre Oracle Base Database Service, mais vous pouvez également utiliser le populaire service Oracle Exadata Database Service on Dedicated Infrastructure.
3. Sélectionnez les valeurs de ces champs qui correspondent à votre déploiement. Demandez à l'administrateur de base de données si vous ne connaissez pas les réponses à ces sélections.
4. Sélectionnez le compartiment et la clé secrète de coffre contenant le mot de passe de la base de données. Vous devez avoir créé un coffre et une clé secrète similaires dans la région 2 dans le cadre de la tâche 2.4. Ce paramètre est dans la boîte de dialogue pour assurer la compatibilité avec les autres API DBaaS, mais le mot de passe n'est pas du tout utilisé.
5. Cliquez sur Ajouter pour ajouter la base de données en tant que membre (non affiché).

Figure 4.1.4.2 : Indiquer les paramètres de la base de données RAC dans la région 1

La liste des membres du groupe de protection de récupération après sinistre doit ressembler à la capture d'écran illustrée à la figure 4.1.4.3. Votre liste peut être différente si vous ajoutez plus d'Oracle E-Business Suite à ce groupe de protection de récupération après sinistre particulier ou si vous ajoutez des ressources membres Oracle E-Business Suite à un groupe de protection de récupération après sinistre existant.

Figure 4.1.4.3 : Liste complète des membres nécessaires pour Oracle E-Business Suite dans la région 1

Tâche 4.2 : Ajouter des ressources de membre au DRPG dans la région 2 (Ashburn)

Vous ajouterez les ressources affichées dans la liste en tant que membres du DRPG de secours dans la région 2.

1. Les deux serveurs d'applications Oracle E-Business Suite non mobiles (Oracle E-Business Suite est installé mais n'est pas en cours d'exécution).
2. Base de données RAC pour Oracle E-Business Suite (homologue de secours Oracle Data Guard).

Oracle E-Business Suite exige que les serveurs d'applications existent dans les deux régions où l'application est installée. Le ou les serveurs d'applications doivent être en cours d'exécution à tout moment dans la région de secours avec l'application Oracle E-Business Suite installée, mais pas dans la région de secours.

Cela signifie que les mises à niveau du système d'exploitation et des applications, les correctifs et toute autre maintenance de routine doivent être effectués indépendamment dans les deux régions.

OCI Full Stack DR fait référence à ce modèle de calcul mobile car les machines virtuelles ne sont pas répliquées vers une autre région et ne déplacent vers aucune autre région au cours d'une opération de récupération après sinistre. Les périphériques d'initialisation pour les instances de calcul désignées comme calcul non mobile dans OCI Full Stack DR ne doivent pas être répliqués vers la région de secours. Par conséquent, aucun groupe de volumes de blocs répliqués contenant des périphériques d'initialisation pour un calcul non mobile n'est ajouté aux groupes de protection de récupération après sinistre (DRPG).

Remarque : comme indiqué précédemment, il est inhabituel qu'Oracle E-Business Suite soit la seule application ou le seul service associé à une paire de groupes de protection de récupération après sinistre OCI Full Stack. Vous pouvez également disposer d'autres ressources IaaS et PaaS en tant que membres du groupe de protection de récupération après sinistre dans la région de secours.

Tâche 4.2.1 : accéder au groupe de protection de récupération après sinistre de secours

Accédez au groupe de protection de récupération après sinistre dans la région 2, comme illustré à la figure 4.2.1.

1. Assurez-vous que le contexte de la région OCI est la région 2 (Ashburn).
2. Sélectionnez le groupe de protection de récupération après sinistre dans la région 2.

Figure 4.2.1 : Accédez au groupe de protection de récupération après sinistre dans la région 2.

Tâche 4.2.2 : Ajouter Oracle E-Business Suite Application Server 1

Commencez par ouvrir le champ Ajouter un membre pour ajouter le premier serveur d'applications.

1. Sélectionnez Membres.
2. Cliquez sur Ajouter un membre,

Figure 4.2.2.1 : Ouvrez la boîte de dialogue Ajouter des membres.

Sélectionnez le serveur d'applications 1 dans la région 2, comme illustré dans la figure 4.2.2.2. Vous n'avez pas besoin d'ajouter de groupes de volumes de blocs ou d'indiquer de propriétés réseau car il s'agit d'une instance non mobile.

1. Sélectionnez Calcul comme type de ressource.
2. Choisissez le compartiment contenant les serveurs d'applications Oracle E-Business Suite et sélectionnez l'instance de calcul que vous avez désignée comme serveur d'applications 1.
3. Sélectionnez Instance non mobile. Elle indique à OCI Full Stack DR qu'elle ne doit pas tenter de lancer une machine virtuelle répliquée dans la région de secours lors d'une opération de récupération après sinistre.
4. Cliquez sur Ajouter pour ajouter l'instance de calcul au DRPG (non affiché).

Figure 4.2.2.2 : Indiquer les paramètres du serveur d'applications 1

Tâche 4.2.3 : Ajouter Oracle E-Business Suite Application Server 2

1. Cliquez sur Ajouter un membre pour ajouter le 2e serveur d'applications.

   
   Figure 4.2.3.1 : Ouvrez la boîte de dialogue Ajouter des membres.

Sélectionnez le serveur d'applications 2 dans la région 2, comme illustré dans la figure 4.2.3.2. Vous n'avez pas besoin d'ajouter de groupes de volumes de blocs ou d'indiquer de propriétés réseau car il s'agit d'une instance non mobile.

1. Sélectionnez Calcul comme type de ressource.
2. Choisissez le compartiment contenant les serveurs d'applications Oracle E-Business Suite et sélectionnez l'instance de calcul que vous avez désignée comme serveur d'applications 2.
3. Sélectionnez Instance non mobile. Elle indique à OCI Full Stack DR qu'elle ne doit pas tenter de lancer une machine virtuelle répliquée dans la région de secours lors d'une opération de récupération après sinistre.
4. Cliquez sur Ajouter pour ajouter l'instance de calcul au DRPG (non affiché).

Figure 4.2.3.2 : Indiquer les paramètres du serveur d'applications 2

Tâche 4.2.4 : Ajouter une base de données de secours Oracle clusterisée

1. Cliquez sur Ajouter un membre pour ajouter la base de données en tant que membre.

   
   Figure 4.2.4.1 : Ouvrez la boîte de dialogue Ajouter des membres.

Sélectionnez la base de données RAC pour Oracle E-Business Suite dans la région 2, comme illustré dans la figure 4.2.4.2. Cela fonctionne exactement de la même manière pour les bases de données à instance unique.

1. Choisissez Base de données comme type de ressource. Le type de ressource Base de données permet de choisir entre Oracle Base Database Service ou Oracle Exadata Database Service on Dedicated Infrastructure, tous deux pris en charge par l'ingénierie Oracle E-Business Suite en tant que choix valides.
2. La figure ci-dessous illustre Oracle Base Database Service, mais vous pouvez également utiliser le populaire service Oracle Exadata Database Service on Dedicated Infrastructure.
3. Choisissez les valeurs de ces champs qui correspondent à votre déploiement. Demandez à l'administrateur de base de données si vous ne connaissez pas les réponses à ces sélections.
4. Sélectionnez le compartiment et la clé secrète de coffre contenant le mot de passe de la base de données. Vous devez avoir créé un coffre et une clé secrète similaires dans la région 2 dans le cadre de la tâche 2.4. Ce paramètre est dans la boîte de dialogue pour assurer la compatibilité avec les autres API DBaaS, mais le mot de passe n'est pas du tout utilisé.
5. Cliquez sur Ajouter pour ajouter la base de données en tant que membre (non affiché).

Figure 4.2.4.2 : Indiquer les paramètres de la base de données RAC dans la région 2

La liste des membres du groupe de protection de récupération après sinistre doit ressembler à la capture d'écran illustrée à la figure 4.2.4.3. Votre liste peut être différente si vous ajoutez plus d'Oracle E-Business Suite à ce groupe de protection de récupération après sinistre particulier ou si vous ajoutez des ressources membres Oracle E-Business Suite à un groupe de protection de récupération après sinistre existant.

Figure 4.2.4.3 : Liste complète des membres nécessaires pour Oracle E-Business Suite dans la région 2

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

Cette tâche crée des plans d'analyse basiques de permutation, de basculement et de démarrage associés au groupe de protection de récupération après sinistre de secours dans la région 2 (Ashburn).

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

OCI Full Stack DR pré-remplit les deux plans avec des étapes intégrées en fonction des ressources membres ajoutées dans les tâches précédentes. Les plans seront personnalisés dans les étapes ultérieures pour gérer toutes les tâches liées à Oracle E-Business Suite System lors d'une opération de récupération.

Les plans de récupération après sinistre sont toujours créés dans le groupe de protection avec le rôle de secours. La région 2 est actuellement le groupe de protection de secours. Nous allons donc commencer à Ashburn.

Créez un plan de base en sélectionnant le DRPG dans la région 2, comme indiqué dans la figure 5-1.

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

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

Tâche 5.1 : Créer un plan de récupération après sinistre pour la permutation vers la région 2

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

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 Type de plan. Il n'y a que quatre types de plan au moment de l'écriture.

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

Tâche 5.2 : Créer un plan de récupération après sinistre pour le basculement vers la région 2

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

1. Rendre le nom du plan de basculement simple mais significatif.
2. Sélectionnez Type de plan. Il n'y a que quatre types de plan au moment de l'écriture.

Figure 5-2 : Paramètres nécessaires pour créer un plan de basculement de récupération après sinistre

Tâche 5.3 : Créer un plan de récupération après sinistre pour l'exploration de début - Région 2

Suivez la même procédure pour créer un plan d'exploration de départ, comme illustré à la figure 5-3.

1. Rendre le nom du plan d'analyse de début simple mais significatif.
2. Sélectionnez Type de plan. Il n'y a que quatre types de plan au moment de l'écriture.

Figure 5-3 : Paramètres nécessaires pour créer un plan d'analyse de démarrage de récupération après sinistre

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

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

Remarque : OCI Full Stack DR ne prendra en charge la création d'un plan d'analyse d'arrêt qu'une fois le plan d'analyse de démarrage exécuté. Pour le tutoriel, il est hors de portée de créer un plan d'analyse d'arrêt, mais il est fortement recommandé de créer un analyse d'arrêt dans les deux groupes de protection de récupération après sinistre.

Tâche 6 : personnaliser les plans de récupération après sinistre dans la région 2 (Ashburn)

OCI Full Stack DR dispose d'une intelligence intégrée pour orchestrer la récupération pour les ressources OCI Infrastructure as a Service (IaaS) et Platform as a Service (PaaS). OCI Full Stack DR ne dispose pas d'intelligence intégrée pour orchestrer la récupération pour Oracle E-Business Suite, car Oracle E-Business Suite ne fournit actuellement pas d'API de récupération après sinistre native OCI pour déployer ou gérer sa propre récupération après sinistre intégrée.

Cependant, OCI Full Stack DR peut toujours orchestrer la récupération pour Oracle E-Business Suite en ajoutant des groupes de plans de récupération après sinistre définis par l'utilisateur et des étapes aux plans de récupération après sinistre de base créés dans le cadre de la tâche 5. Les étapes définies par l'utilisateur appellent les scripts Oracle E-Business Suite qui ont été téléchargés et installés sur les serveurs d'applications Oracle E-Business Suite des deux régions ou sur le noeud de contrôle de récupération après sinistre dédié dans le cadre de la tâche 2.3. Les groupes de plans définis par l'utilisateur sont les suivants : Les groupes de plans à ajouter varient en fonction des types de plan de récupération après sinistre.

1. Arrêtez Oracle E-Business Suite et désactivez les travaux rsync sur node2 dans la région 1.
2. Arrêtez Oracle E-Business SuiteS et désactivez les travaux rsync sur node1 dans la région 1.
3. Effacez les noms de noeud dans les tables fnd de la base de données dans la région 2.
4. Configurez le contexte d'application dans la base de données sur node1 dans la région 2.
5. Configurez le contexte d'application dans la base de données sur node2 dans la région 2.
6. Exécutez autoconfig sur node1 dans la région 2.
7. Exécutez autoconfig sur node2 dans la région 2.
8. Démarrez Oracle E-Business Suite et activez les travaux rsync sur node1 dans la région 2.
9. Démarrez Oracle E-Business Suite et activez les travaux rsync sur node2 dans la région 2.

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

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

Figure 6.1 : Sélectionner un plan de permutation dans la région 2

OCI Full Stack DR générera les groupes de plans Prechecks-Built in et Databases-Switchover, qui ont été générés en fonction des membres que nous avons ajoutés aux groupes de protection de récupération après sinistre dans les régions 1 et 2.

Figure 6.1.1 : Groupes de plans par défaut pour le plan de permutation de rôles dans la région 2

Tâche 6.2 : Créer un groupe de plans pour arrêter Oracle E-Business Suite et désactiver les travaux de synchronisation sur le noeud 2 dans la région 1

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

Le premier groupe de plans défini par l'utilisateur arrête Oracle E-Business Suite et désactive les travaux rsync sur node2 dans la région 1. Ce groupe de plans contient deux étapes qui appellent les scripts bash shutdownapps.sh et fsdr-rsync-ebs.sh téléchargés sur les noeuds de serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6-2.1 : Commencer à ajouter un groupe de plans pour arrêter Oracle E-Business Suite et désactiver les travaux rsync sur node2

Tâche 6.2.2 : Indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous allons ajouter deux étapes pour exécuter des scripts bash afin d'arrêter Oracle E-Business Suite sur node2 et de désactiver les travaux cron rsync sur node2 dans la région 1. Dans notre exemple, le nom node2 est ebshaapp02phx.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur avant d'ajouter le groupe de plans Databases-Switchover.
3. Sélectionnez le groupe de plans Bases de données - Permutation intégré.
4. Nous allons ajouter deux étapes. La première étape consiste à arrêter Oracle E-Business Suite sur le noeud 2 et le second script à désactiver les travaux rsync sur le noeud 2.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle vous indiquez le script d'arrêt d'Oracle E-Business Suite sur node2.

Figure 6.2.2 : Planifier un groupe pour arrêter Oracle E-Business Suite et arrêter les travaux rsync

Tâche 6.2.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter deux étapes dans ce groupe de plans.

• L'étape 1 consiste à arrêter l'application Oracle E-Business Suite sur node2.
• Etape 2 : permet de désactiver les travaux rysnc sur node2.

Pour cette configuration, le noeud 2 est ebshaapp02phx

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez la région 1, donc dans notre cas c'est Phoenix..

3. Sélectionnez Run local script (Exécuter un script locale).

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node2 et sélectionnez le noeud 2. Dans notre cas, il s'agit de ebshaapp02phx.

5. Collez le chemin absolu dans lequel vous avez installé le script shutdownapps.sh sur l'application Oracle E-Business Suite node2 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter l'application Oracle E-Business Suite sur node2. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 1800 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.2.3.1 : Paramètres permettant de créer l'étape de plan pour arrêter Oracle E-Business Suite sur le noeud 2

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.2.3.2 : L'étape Arrêter Oracle E-Business Suite à l'étape du noeud 2 est ajoutée

11. Cliquez sur Ajouter une étape pour ajouter une deuxième étape à ce groupe de plans.

12. Nom descriptif expliquant la tâche effectuée par cette étape.

13. Sélectionnez la région 1, donc dans notre cas c'est Phoenix.

14. Sélectionnez Run local script (Exécuter un script locale).

15. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node2 et sélectionnez le noeud 2. Dans notre cas, il s'agit de ebshaapp02phx.

16. Collez le chemin absolu dans lequel vous avez installé le script fsdr-rsync-ebs.sh sur l'application Oracle E-Business Suite node2 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

17. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

18. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à désactiver les travaux rsync sur node2. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

19. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 300 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

20. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

    
    Figure 6.2.3.1 : Paramètres permettant de créer l'étape de plan pour désactiver les travaux rysnc sur le noeud 2

21. Il apparaîtra comme ci-dessous une fois l'étape 2 ajoutée.

    
    Figure 6.2.3.2 : La désactivation des travaux rysnc sur le noeud 2 est ajoutée.

Tâche 6.2.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

Les travaux d'arrêt de l'application Oracle E-Business Suite et de désactivation de rsync sur node2 sont ajoutés au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.2.4.1 : Finaliser l'ajout d'un groupe de plans et d'étapes pour arrêter Oracle E-Business Suite et désactiver le travail de synchronisation sur node1

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.2.4.1 : Arrêtez Oracle E-Business Suite et désactivez le travail de synchronisation sur le groupe de plans node1 ajouté.

Tâche 6.3 : Créer un groupe de plans pour arrêter Oracle E-Business Suite et désactiver les travaux de synchronisation sur le noeud 1 dans la région 1

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur arrête Oracle E-Business Suite et désactive les travaux rsync sur node1 dans la région 1. Ce groupe de plans contient deux étapes qui appellent les scripts bash shutdownapps.sh et fsdr-rsync-ebs.sh téléchargés sur les noeuds de serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6-3.1 : Commencer à ajouter un groupe de plans pour arrêter Oracle E-Business Suite et désactiver les travaux rsync sur node1

Tâche 6.3.2 : indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous allons ajouter deux étapes pour exécuter des scripts bash afin d'arrêter Oracle E-Business Suite sur node1 et de désactiver les travaux cron rsync sur node1 dans la région 1. Dans notre exemple, le nom node1 est ebshaapp01phx.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après l'arrêt d'EBS sur node2 dans le groupe de plans PHX.
3. Sélectionnez le groupe de plans Arrêter EBS sur node2 dans PHX défini par l'utilisateur.
4. Nous allons ajouter deux étapes. La première étape consiste à arrêter Oracle E-Business Suite sur le noeud 1 et le deuxième script à désactiver les travaux rsync sur le noeud 1.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle vous indiquez le script d'arrêt d'Oracle E-Business Suite sur node2.

Figure 6.3.2 : Planifier un groupe pour arrêter Oracle E-Business Suite et arrêter les travaux rsync

Tâche 6.3.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter deux étapes dans ce groupe de plans.

• L'étape 1 consiste à arrêter l'application Oracle E-Business Suite sur node1.
• L'Step 2 consiste à désactiver les travaux rysnc sur node1.

Pour cette configuration, le noeud 1 est ebshaapp01phx

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 1, donc dans notre cas c'est Phoenix.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp01phx.

5. Collez le chemin absolu dans lequel vous avez installé le script shutdownapps.sh sur l'application Oracle E-Business Suite node2 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter l'application Oracle E-Business Suite sur node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 1800 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.3.3.1 : Paramètres permettant de créer l'étape de plan pour arrêter Oracle E-Business Suite sur le noeud 1

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.3.3.2 : L'étape Arrêter Oracle E-Business Suite à l'étape du noeud 1 est ajoutée

11. Cliquez sur Ajouter une étape pour ajouter une deuxième étape à ce groupe de plans.

12. Nom descriptif expliquant la tâche effectuée par cette étape.

13. Sélectionnez la région 1, donc dans notre cas c'est Phoenix.

14. Sélectionnez Run local script (Exécuter un script locale).

15. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp02phx.

16. Collez le chemin absolu dans lequel vous avez installé le script fsdr-rsync-ebs.sh sur l'application Oracle E-Business Suite node2 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

17. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

18. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à désactiver les travaux rsync sur node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

19. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 300 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

20. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

    
    Figure 6.3.3.1 : Paramètres permettant de créer l'étape de plan pour désactiver les travaux rysnc sur le noeud 1

21. Il apparaîtra comme ci-dessous une fois l'étape 2 ajoutée.

    
    Figure 6.3.3.2 : La désactivation des travaux rysnc sur le noeud 1 est ajoutée.

Tâche 6.3.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

Les travaux d'arrêt de l'application Oracle E-Business Suite et de désactivation de rsync sur node2 sont ajoutés au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.3.4.1 : Finaliser l'ajout d'un groupe de plans et d'étapes pour arrêter Oracle E-Business Suite et désactiver le travail de synchronisation sur node1

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.3.4.1 : Arrêtez Oracle E-Business Suite et désactivez le travail de synchronisation sur le groupe de plans node1 ajouté.

Tâche 6.4 : Créer un groupe de plans pour effacer les noms de noeud dans les tables fnd de la base de données dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur effacera les noms de noeud dans les tables fnd de la base de données de la région 2. Ce groupe de plans contient une étape qui appelle le script bash fndnodeclean.sh téléchargé sur les noeuds du serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6.4.1 : Commencer à ajouter un groupe de plans pour arrêter Oracle E-Business Suite et désactiver les travaux rsync sur node1

Tâche 6.4.2 : Indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Nous allons en ajouter un pour exécuter le script bash afin d'effacer les noms de noeud dans les tables fnd de la base de données sur node1 dans la région 1. Dans notre exemple, le nom node1 est ebshaapp01iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer le groupe de plans défini par l'utilisateur ajouter après le groupe de plans Bases de données - Permutation.
3. Sélectionnez le groupe de plans Bases de données - Permutation intégré.
4. Nous allons ajouter une étape pour effacer les noms de noeud dans les tables fnd de la base de données.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant d'effacer les noms de noeud dans les tables fnd de la base de données.

Figure 6.4.2 : Planifiez le groupe pour effacer les noms de noeud dans les tables fnd de la base de données.

Tâche 6.4.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter un seul élément dans ce groupe de plans.

• L'étape consiste à exécuter fndnodeclean sur node1.

Pour cette configuration, le noeud 1 est ebshaapp01iad

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit de Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp01iad.

5. Collez le chemin absolu dans lequel vous avez installé le script fndnodeclean.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter l'application Oracle E-Business Suite sur node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 900 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.4.3.1 : Paramètres permettant de créer l'étape de plan permettant d'effacer les noms de noeud dans les tables fnd de base de données

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.4.3.2 : Effacer les noms de noeud dans les tables fnd de la base de données

Tâche 6.4.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

L'étape d'effacement des noms de noeud dans les tables fnd de la base de données est ajoutée au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.4.4.1 : Finaliser l'ajout d'un groupe de plans et d'une étape pour effacer les noms de noeud dans les tables fnd de la base de données

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.4.4.2 : Pour effacer les noms de noeud dans les tables fnd de base de données sur le groupe de plans node1 ajouté

Tâche 6.5 : Créer un groupe de plans pour configurer le contexte de l'application dans la base de données sur node1 dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur configurera le contexte d'application dans la base de données sur node1 dans la région 2. Ce groupe de plans contient une étape qui appelle le script bash dbtxkconfig.sh téléchargé sur les noeuds du serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6.5.1 : Commencez à ajouter un groupe de plans à la configuration du contexte d'application dans la base de données sur node1

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

Nous allons ajouter une étape pour exécuter le script bash afin de configurer le contexte d'application dans la base de données sur node1 dans la région 2. Dans notre exemple, le nom node1 est ebshaapp01iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer le groupe de plans défini par l'utilisateur après l'option Effacer les noms de noeud dans les tables fnd de la base de données au niveau du groupe de plans IAD.
3. Sélectionnez le groupe de plans intégré Effacer les noms de noeud dans les tables fnd de base de données dans IAD.
4. Nous allons ajouter une étape pour configurer le contexte de l'application dans la base de données sur node1.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de configuration du contexte d'application dans la base de données sur node1.

Figure 6.5.2 : Groupe de plans pour configurer le contexte d'application dans la base de données sur node1

Tâche 6.5.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter un seul élément dans ce groupe de plans.

• L'étape consiste à exécuter dbtxkconfig sur node1 (modifier les noms d'hôte physiques).

Pour cette configuration, le noeud 1 est ebshaapp01iad

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit de Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp01iad.

5. Collez le chemin absolu dans lequel vous avez installé le script dbtxkconfig.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte. Il est extrêmement important de fournir tous les détails avec les bons paramètres.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à configurer le contexte d'application dans la base de données node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 900 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.5.3.1 : Paramètres permettant de créer l'étape de plan permettant de configurer le contexte d'application dans la base de données node1

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.5.3.2 : Pour configurer le contexte d'application dans la base de données node1

Tâche 6.5.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

L'étape de configuration du contexte d'application dans la base de données node1 est ajoutée au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.5.4.1 : Finaliser l'ajout d'un groupe de plans et d'une étape de configuration du contexte d'application dans la base de données node1

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.5.4.2 : Pour configurer le contexte d'application dans la base de données node1, groupe de plans ajouté

Tâche 6.6 : Créer un groupe de plans pour configurer le contexte de l'application dans la base de données sur node2 dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur configurera le contexte d'application dans la base de données sur node2 dans la région 2. Ce groupe de plans contient une étape qui appelle le script bash dbtxkconfig.sh téléchargé sur les noeuds du serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6.6.1 : Commencez à ajouter un groupe de plans à la configuration du contexte d'application dans la base de données sur node2

Tâche 6.6.2 : Indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Nous allons ajouter une étape pour exécuter le script bash afin de configurer le contexte d'application dans la base de données sur node2 dans la région 2. Dans notre exemple, le nom node2 est ebshaapp02iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le contexte d'application de configuration dans la base de données sur node1 dans le groupe de plans IAD.
3. Sélectionnez le contexte d'application de configuration intégré dans la base de données sur node1 dans le groupe de plans IAD.
4. Nous allons ajouter une étape pour configurer le contexte de l'application dans la base de données sur node2.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de configuration du contexte d'application dans la base de données sur node1.

Figure 6.6.2 : Groupe de plans pour configurer le contexte d'application dans la base de données sur node2

Tâche 6.6.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter un seul élément dans ce groupe de plans.

• L'étape consiste à exécuter dbtxkconfig sur node2 (modifier les noms d'hôte physiques).

Pour cette configuration, le noeud 2 est ebshaapp02iad

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit de Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp02iad.

5. Collez le chemin absolu dans lequel vous avez installé le script dbtxkconfig.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte. Il est extrêmement important de fournir tous les détails avec les bons paramètres.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à configurer le contexte d'application dans la base de données node2. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 900 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.6.3.1 : Paramètres permettant de créer l'étape de plan permettant de configurer le contexte d'application dans la base de données node2

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.6.3.2 : Pour configurer le contexte d'application dans la base de données node2

Tâche 6.6.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

L'étape de configuration du contexte d'application dans la base de données node1 est ajoutée au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.6.4.1 : Finaliser l'ajout d'un groupe de plans et d'une étape de configuration du contexte d'application dans la base de données node2

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.6.4.2 : Pour configurer le contexte d'application dans la base de données node2, groupe de plans ajouté

Tâche 6.7 : créer un groupe de plans pour exécuter autoconfig sur l'application node1 dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur exécutera autoconfig sur l'application node1 dans la région 2. Ce groupe de plans contient une étape qui appelle le script bash autoconfigapps.sh téléchargé sur les noeuds du serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6.7.1 : Commencer à ajouter un groupe de plans pour exécuter la configuration automatique sur l'application node1

Tâche 6.7.2 : Indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Nous allons ajouter une étape pour exécuter le script bash afin d'exécuter autoconfig sur l'application node1 dans la région 2. Dans notre exemple, le nom node1 est ebshaapp01iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le contexte d'application de configuration dans la base de données sur node2 dans le groupe de plans IAD.
3. Sélectionnez le contexte d'application de configuration intégré dans la base de données sur node2 dans le groupe de plans IAD.
4. Nous allons ajouter une étape pour configurer le contexte de l'application dans la base de données sur node2.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script à exécuter autoconfig sur l'application node1.

Figure 6.7.2 : Groupe de plans pour exécuter la configuration automatique sur l'application node1

Tâche 6.7.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter un seul élément dans ce groupe de plans.

• L'étape consiste à exécuter autoconfig sur node1.

Pour cette configuration, le noeud 1 est ebshaapp01iad

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit de Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp01iad.

5. Collez le chemin absolu dans lequel vous avez installé le script autoconfigapps.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte. Il est extrêmement important de fournir tous les détails avec les bons paramètres.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à exécuter autoconfig sur l'application node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 900 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.7.3.1 : Paramètres permettant de créer l'étape de plan permettant d'exécuter la configuration automatique sur l'application node1

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.7.3.2 : Pour exécuter la configuration automatique sur l'application node1

Tâche 6.7.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

L'étape d'exécution de autoconfig sur l'application node1 est ajoutée au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.7.4.1 : Finaliser l'ajout d'un groupe de plans et d'une étape pour exécuter la configuration automatique sur l'application node1

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.7.4.2 : Pour exécuter la configuration automatique sur le groupe de plans d'application node1 ajouté

Tâche 6.8 : créer un groupe de plans pour exécuter autoconfig sur l'application node2 dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur exécutera autoconfig sur l'application node2 dans la région 2. Ce groupe de plans contient une étape qui appelle le script bash autoconfigapps.sh téléchargé sur les noeuds du serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6.8.1 : Commencer à ajouter un groupe de plans pour exécuter la configuration automatique sur l'application node2

Tâche 6.8.2 : indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Nous allons ajouter une étape pour exécuter le script bash afin d'exécuter autoconfig sur l'application node2 dans la région 2. Dans notre exemple, le nom node2 est ebshaapp02iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après l'option Exécuter la configuration automatique sur l'application node1 dans le groupe de plans IAD.
3. Sélectionnez le groupe de plans intégré Exécuter la configuration automatique sur l'application node1 dans IAD.
4. Nous allons ajouter une étape pour configurer le contexte de l'application dans la base de données sur node2.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script à exécuter autoconfig sur l'application node2.

Figure 6.8.2 : Groupe de plans pour exécuter la configuration automatique sur l'application node2

Tâche 6.8.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter un seul élément dans ce groupe de plans.

• L'étape consiste à exécuter autoconfig sur node2.

Pour cette configuration, le noeud 1 est ebshaapp02iad

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit de Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node2 et sélectionnez le noeud 2. Dans notre cas, il s'agit de ebshaapp02iad.

5. Collez le chemin absolu dans lequel vous avez installé le script autoconfigapps.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte. Il est extrêmement important de fournir tous les détails avec les bons paramètres.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à exécuter la configuration automatique sur l'application node2. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 900 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.8.3.1 : Paramètres permettant de créer l'étape de plan permettant d'exécuter la configuration automatique sur l'application node2

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.8.3.2 : Pour exécuter la configuration automatique sur l'application node2

Tâche 6.8.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

L'étape d'exécution de autoconfig sur l'application node2 est ajoutée au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.8.4.1 : Finaliser l'ajout d'un groupe de plans et d'une étape pour exécuter la configuration automatique sur l'application node2

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.8.4.2 : Pour exécuter la configuration automatique sur le groupe de plans d'application node2 ajouté

Tâche 6.9 : Créer un groupe de plans pour démarrer Oracle E-Business Suite et activer les travaux de synchronisation sur le noeud 1 dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur va démarrer Oracle E-Business Suite et activer les travaux rsync sur node1 dans la région 2. Ce groupe de plans contient deux étapes qui appellent les scripts bash startapps.sh et fsdr-rsync-ebs.sh téléchargés sur les noeuds de serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6-9.1 : Commencer à ajouter un groupe de plans pour démarrer Oracle E-Business Suite et activer les travaux de synchronisation sur node1

Tâche 6.9.2 : Indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous allons ajouter deux étapes pour exécuter des scripts bash afin de démarrer Oracle E-Business Suite sur node1 et d'activer les travaux cron rsync sur node1 dans la région 2. Dans notre exemple, le nom node1 est ebshaapp01iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après l'option Exécuter la configuration automatique sur l'application node2 dans le groupe de plans IAD.
3. Sélectionnez le groupe de plans défini par l'utilisateur Exécuter la configuration automatique sur l'application node2 dans IAD.
4. Nous allons ajouter deux étapes. La première étape consiste à démarrer Oracle E-Business Suite sur le noeud 1 et le deuxième script à activer les travaux de synchronisation sur le noeud 1.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'Oracle E-Business Suite sur node2.

Figure 6.9.2 : groupe de plans permettant de démarrer ebs et d'activer les travaux rsync sur node1

Tâche 6.9.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter deux étapes dans ce groupe de plans.

• L'étape 1 consiste à démarrer l'application Oracle E-Business Suite sur node1.
• L'Step 2 permet d'activer les travaux rysnc sur node1.

Pour cette configuration, le noeud 1 est ebshaapp01iad.

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit d'Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp01iad.

5. Collez le chemin absolu dans lequel vous avez installé le script startapps.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à démarrer l'application Oracle E-Business Suite sur node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 1800 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.9.3.1 : Paramètres permettant de créer l'étape de plan pour démarrer Oracle E-Business Suite sur le noeud 1

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.9.3.2 : Démarrage d'Oracle E-Business Suite à l'étape du noeud 1 ajoutée

11. Cliquez sur Ajouter une étape pour ajouter une deuxième étape à ce groupe de plans.

12. Nom descriptif expliquant la tâche effectuée par cette étape.

13. Sélectionnez la région 2. Dans notre cas, il s'agit d'Ashburn.

14. Sélectionnez Run local script (Exécuter un script locale).

15. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 1. Dans notre cas, il s'agit de ebshaapp0iad.

16. Collez le chemin absolu dans lequel vous avez installé le script fsdr-rsync-ebs.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

17. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

18. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à activer les travaux rsync sur node1. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

19. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 300 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

20. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

    
    Figure 6.9.3.1 : Paramètres permettant de créer l'étape de plan pour activer les travaux rysnc sur le noeud 1

21. Il apparaîtra comme ci-dessous une fois l'étape 2 ajoutée.

    
    Figure 6.9.3.2 : l'activation des travaux rysnc sur le noeud 1 est ajoutée

Tâche 6.9.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

Les travaux rsync de démarrage et d'activation de l'application Oracle E-Business Suite sur node1 sont ajoutés au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.9.4.1 : Finaliser l'ajout d'un groupe de plans et d'étapes pour démarrer Oracle E-Business Suite et activer le travail de synchronisation sur node1

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.9.4.1 : Démarrez Oracle E-Business Suite et activez le travail de synchronisation sur le groupe de plans node1 ajouté.

Tâche 6.10 : Créer un groupe de plans pour démarrer Oracle E-Business Suite et activer les travaux de synchronisation sur le noeud 2 dans la région 2

Maintenant, ajoutons le prochain groupe de plans défini par l'utilisateur.

Ce groupe de plans défini par l'utilisateur va démarrer Oracle E-Business Suite et activer les travaux rsync sur node2 dans la région 2. Ce groupe de plans contient deux étapes qui appellent les scripts bash startapps.sh et fsdr-rsync-ebs.sh téléchargés sur les noeuds de serveur d'applications Oracle E-Business Suite dans la tâche 2.3.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.

   
   Figure 6-10.1 : Commencer à ajouter un groupe de plans pour démarrer Oracle E-Business Suite et activer les travaux de synchronisation sur node2

Tâche 6.10.2 : indiquer le nom du groupe de plans, l'ordre et l'étape Ajouter

Un groupe de plans de récupération après sinistre peut contenir de nombreuses étapes qui sont toutes exécutées en parallèle. Nous allons ajouter deux étapes pour exécuter des scripts bash afin de démarrer Oracle E-Business Suite sur node1 et d'activer les travaux cron rsync sur node1 dans la région 2. Dans notre exemple, le nom node1 est ebshaapp02iad.

1. Donnez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste dans lequel le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le démarrage d'EBS sur node1 dans le groupe de plans IAD.
3. Sélectionnez le groupe de plans défini par l'utilisateur Démarrer EBS sur node1 dans IAD.
4. Nous allons ajouter deux étapes. La première étape consiste à démarrer Oracle E-Business Suite sur le noeud 2 et le deuxième script à activer les travaux rsync sur le noeud 2.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de démarrage d'Oracle E-Business Suite sur node2.

Figure 6.10.2 : Groupe de plans permettant de démarrer Oracle E-Business Suite et d'activer les travaux de synchronisation sur node2

Tâche 6.10.3 : fournir des noms d'étape et des paramètres de script local

La boîte de dialogue Ajouter une étape de groupe de plans permet d'indiquer les paramètres relatifs à l'exécution de cette étape et à son comportement lors de la récupération. Nous allons ajouter deux étapes dans ce groupe de plans.

• L'étape 1 consiste à démarrer l'application Oracle E-Business Suite sur node2.
• L'Step 2 permet d'activer les travaux rysnc sur node2.

Pour cette configuration, le noeud 2 est ebshaapp02iad

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.

2. Sélectionnez le type défini par l'utilisateur Exécuter le script local.

3. Sélectionnez la région 2. Dans notre cas, il s'agit d'Ashburn.

4. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 2. Dans notre cas, il s'agit de ebshaapp02iad.

5. Collez le chemin absolu dans lequel vous avez installé le script startapps.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

6. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

7. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à démarrer l'application Oracle E-Business Suite sur node2. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

8. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 1800 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

9. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

   
   Figure 6.10.3.1 : Paramètres permettant de créer l'étape de plan pour démarrer Oracle E-Business Suite sur le noeud 2

10. Il apparaîtra comme ci-dessous une fois l'étape 1 ajoutée.

    
    Figure 6.10.3.2 : Démarrage d'Oracle E-Business Suite à l'étape du noeud 2 ajoutée

11. Cliquez sur Ajouter une étape pour ajouter une deuxième étape à ce groupe de plans.

12. Nom descriptif expliquant la tâche effectuée par cette étape.

13. Sélectionnez la région 2. Dans notre cas, il s'agit d'Ashburn.

14. Sélectionnez Run local script (Exécuter un script locale).

15. Sélectionnez le compartiment approprié qui contient l'application Oracle E-Business Suite node1 et sélectionnez le noeud 2. Dans notre cas, il s'agit de ebshaapp0iad.

16. Collez le chemin absolu dans lequel vous avez installé le script fsdr-rsync-ebs.sh sur l'application Oracle E-Business Suite node1 avec les bons paramètres. Vous pouvez consulter les détails du fichier README à partir du lien GitHub fourni dans la tâche 2.3 pour connaître la syntaxe exacte.

17. Spécifiez oracle en tant qu'utilisateur pour exécuter le script.

18. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à activer les travaux rsync sur node2. Cela permettra à n'importe qui de voir s'il y a un problème et de le résoudre. OCI Full Stack DR offre la possibilité de continuer à exécuter le plan de permutation après avoir résolu le problème.

19. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est de 60 minutes (3600 secondes). Cette valeur peut être remplacée par 300 secondes ou tout ce qui semble être une valeur de délai d'attente plus réaliste.

20. Cliquez sur Ajouter étape pour ajouter cette étape au groupe de plans.

    
    Figure 6.10.3.1 : Paramètres permettant de créer l'étape de plan pour activer les travaux rysnc sur le noeud 2

21. Il apparaîtra comme ci-dessous une fois l'étape 2 ajoutée.

    
    Figure 6.10.3.2 : L'activation des travaux rysnc sur le noeud 2 est ajoutée.

Tâche 6.10.4 : terminer l'ajout d'un groupe de protocoles et d'étapes

Les travaux rsync de démarrage et d'activation de l'application Oracle E-Business Suite sur node2 sont ajoutés au groupe de plans de récupération après sinistre.

1. Cliquez sur Ajouter pour ajouter le groupe de plans de récupération après sinistre et les étapes au plan de récupération après sinistre.

   
   Figure 6.10.4.1 : Finaliser l'ajout d'un groupe de plans et d'étapes pour démarrer Oracle E-Business Suite et activer le travail de synchronisation sur node2

2. Vérifiez que le groupe de plans ajouté est disponible dans le plan de permutation.

   
   Figure 6.10.4.1 : Démarrez Oracle E-Business Suite et activez le travail de synchronisation sur le groupe de plans node2 ajouté.

Remarque : ce faisant, nous avons terminé tous les groupes de plans définis par l'utilisateur requis pour le plan de permutation. Assurez-vous de vérifier que vous avez les groupes de plan dans le bon ordre, c'est vraiment important.

Une fois le plan de permutation personnalisé, il doit se présenter comme suit :

Figure 6.10.5.1 : Tous les groupes de plans pour le plan de permutation de rôles dans la région 2

Remarque : vous pouvez réorganiser le groupe de plans au cas où vous n'auriez pas commandé dans le bon ordre.

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

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

Figure 6.11 : Sélectionner un plan de basculement en cas d'incident dans la région 2

OCI Full Stack DR générera les groupes de plans Prechecks-Built in et Databases-Failover, qui ont été générés en fonction des membres que nous avons ajoutés aux groupes de protection de récupération après sinistre dans les régions 1 et 2.

Figure 6.11.1 : Groupes de plans par défaut pour le plan de basculement en cas d'incident dans la région 2

Comme pour la personnalisation du plan de permutation, nous allons ajouter les groupes de plans définis par l'utilisateur requis pour le plan de basculement.

Vous devez ajouter les groupes de plans définis par l'utilisateur suivants après le groupe de plans intégré Databases-Failover.

1. Effacez les noms de noeud dans les tables fnd de la base de données dans la région 2.
2. Configurez le contexte d'application dans la base de données sur node1 dans la région 2.
3. Configurez le contexte d'application dans la base de données sur node2 dans la région 2.
4. Exécutez autoconfig sur node1 dans la région 2.
5. Exécutez autoconfig sur node2 dans la région 2.
6. Démarrez Oracle E-Business Suite et activez les travaux rsync sur node1 dans la région 2.
7. Démarrez Oracle E-Business Suite et activez les travaux rsync sur node2 dans la région 2.

Remarque : nous ne sommes pas en train de suivre les étapes pour ajouter à nouveau les groupes de plans définis par l'utilisateur. Pour obtenir des instructions détaillées, voir Tâche 6.4 à 6.9.

Une fois le plan de basculement personnalisé, il doit se présenter comme suit :

Figure 6.11.1 : Tous les groupes de plans pour le plan de basculement en cas d'incident dans la région 2

Remarque :

• Vous pouvez réorganiser les groupes de protocoles au cas où vous n'auriez pas prescrit dans le bon ordre.

• Vous pouvez également personnaliser le plan Démarrer l'exploration.

  Pour le plan d'exploration de démarrage, aucun groupe de plans intégré n'est créé pour la base de données.

  Vous devez créer un groupe de plans défini par l'utilisateur pour convertir la base de données de secours physique en base de données de secours instantanée. Vous pouvez utiliser les commandes standard du broker Oracle Data Guard pour effectuer ces opérations et les placer dans un script wrapper.

  En outre, vous pouvez ajouter des groupes de plans définis par l'utilisateur liés à l'application, comme pour un plan de basculement.

• OCI Full Stack DR permet de créer un plan d'analyse d'arrêt une fois le plan d'analyse de démarrage exécuté. Pour plus d'informations, voir Plans d'exploration de données. Le plan Arrêter l'analyse annule les opérations effectuées dans le plan d'analyse de démarrage.

• Vous pouvez également personnaliser le plan d'arrêt de l'exploration.

  Pour le plan d'analyse d'arrêt, aucun groupe de plans intégré n'est créé pour la base de données.

  Vous devez créer un groupe de plans défini par l'utilisateur pour convertir la base de données de secours cliché en base de données physique. Vous pouvez utiliser les commandes standard du broker Oracle Data Guard pour effectuer ces opérations et les placer dans un script wrapper.

  En outre, vous pouvez ajouter des groupes de plans définis par l'utilisateur liés à l'application pour arrêter toutes les applications associées à Oracle E-Business Suite.

Dans le cadre de ce tutoriel, nous exécuterons un plan **Permutation dans les tâches suivantes.**

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

Les plans de reprise après sinistre et de basculement ont été créés dans la région de secours 2 (Ashburn). Les plans de récupération après sinistre de la région 2 permettent à OCI Full Stack DR de faire passer les workloads de la région 1 à la région 2. La tâche suivante consiste à créer une permutation, un basculement et à démarrer des plans d'analyse dans le groupe de protection pour la région 1 (Phoenix) afin qu'OCI Full Stack DR puisse faire passer les charges globales de la région 2 à la région 1.

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

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

Tâche 7.1 : lancer l'exécution du plan

Exécutez le plan de récupération après sinistre pour commencer le processus de transition de la charge globale Oracle Integration Cloud de la région 1 vers la région 2.

1. Assurez-vous que le contexte de région est toujours défini sur la région de secours 2 (Ashburn).
2. Utilisez le chemin de navigation en haut de la console pour vous assurer que les détails du groupe de protection de récupération après sinistre constituent le contexte de plan en cours.
3. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné ; il doit s'agir du rôle Standby.
4. Assurez-vous que les plans de basculement et de permutation existent avant de continuer. Dans le cas contraire, revenez aux étapes précédentes pour créer et personnaliser les deux plans de récupération après sinistre.
5. Cliquez sur Exécuter le plan de récupération après sinistre.

Figure 7-1 : Procédure d'exécution d'une permutation de rôles vers une région de secours

Tâche 7.2 : Sélectionner un 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. Sélectionnez Activer les prévérifications.
3. Cliquez sur Exécuter le plan de récupération après sinistre pour commencer.

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

Tâche 7.3 : surveiller l'exécution du plan de récupération après sinistre

Surveillez le plan de permutation jusqu'à ce que la charge globale Oracle E-Business Suite passe entièrement de la région 1 à la région 2. Une fois le plan de permutation terminé, OCI Full Stack DR se charge de nettoyer les rôles des groupes de protection de récupération après sinistre principal et de secours entre les régions.

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

1. Vérifiez que l'exécution du plan de permutation a réussi.

   
   Figure 7-2 : Plan de permutation terminé avec succès dans la région 2

2. Vérifiez que le changement de rôle dans le groupe de protection de récupération après sinistre, que la région 2 (Phoenix) aura désormais le rôle de secours et que la région 1 (Ashburn) aura désormais le rôle principal.

   
   Figure 7-2 : Modification du rôle d'un groupe de protection de récupération après sinistre après un plan de permutation

Tâche 8 : créer des plans de récupération après sinistre et les personnaliser dans la région 1 (Phoenix)

Créez les plans de récupération après sinistre dans le groupe de protection de récupération après sinistre de la région 1 (Phoenix), qui est désormais le pair de secours.

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

OCI Full Stack DR pré-remplit les deux plans avec des étapes intégrées en fonction des ressources membres ajoutées à l'étape précédente. Les plans seront personnalisés dans les étapes ultérieures afin de gérer toutes les tâches liées à Oracle Integration Cloud lors d'une opération de récupération.

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

Suivez la même procédure que la tâche 5 pour créer les plans de récupération après sinistre dans la région 1. Une fois les plans créés, vérifiez-les.

Figure 8-1 : Plans de récupération après sinistre de la région 1

Suivez la même procédure que pour la tâche 6 afin de personnaliser les plans de récupération après sinistre dans la région 1. Veillez à ajouter les groupes de plans définis par l'utilisateur. Il est très important de sélectionner les machines virtuelles d'application Oracle E-Business Suite appropriées pour les régions de production et de récupération après sinistre pour l'exécution des scripts.

1. Arrêtez Oracle E-Business Suite et désactivez les travaux rsync sur node2 dans la région 2.
2. Arrêtez Oracle E-Business Suite et désactivez les travaux rsync sur node1 dans la région 2.
3. Effacez les noms de noeud dans les tables fnd de la base de données dans la région 1.
4. Configurez le contexte d'application dans la base de données sur node1 dans la région 1.
5. Configurez le contexte d'application dans la base de données sur node2 dans la région 1.
6. Exécutez autoconfig sur node1 dans la région 1.
7. Exécutez autoconfig sur node2 dans la région 1.
8. Démarrez Oracle E-Business Suite et activez les travaux rsync sur node1 dans la région 1.
9. Démarrez Oracle E-Business Suite et activez les travaux rsync sur node2 dans la région 1.

Une fois le plan de permutation personnalisé, il doit se présenter comme suit :

Figure 8.2 : Tous les groupes de plans pour le plan de permutation de rôles dans la région 1

Une fois le plan de basculement personnalisé, il doit se présenter comme suit :

Figure 8.3 : Tous les groupes de plans pour le plan de basculement en cas d'incident dans la région 1

Remarque :

• Vous pouvez réorganiser les groupes de protocoles au cas où vous n'auriez pas prescrit dans le bon ordre.

• Vous pouvez également personnaliser le plan Démarrer l'exploration.

  Pour le plan d'exploration de démarrage, aucun groupe de plans intégré n'est créé pour la base de données.

  Vous devez créer un groupe de plans défini par l'utilisateur pour convertir la base de données de secours physique en base de données de secours instantanée. Vous pouvez utiliser les commandes standard du broker Oracle Data Guard pour effectuer ces opérations et les placer dans un script wrapper.

  En outre, vous pouvez ajouter des groupes de plans définis par l'utilisateur liés à l'application, comme pour un plan de basculement.

• OCI Full Stack DR permet de créer un plan d'analyse d'arrêt une fois le plan d'analyse de démarrage exécuté. Pour plus d'informations, voir Plans d'exploration de données. Le plan Arrêter l'analyse annule les opérations effectuées dans le plan d'analyse de démarrage.

• Vous pouvez également personnaliser le plan d'arrêt de l'exploration.

  Pour le plan d'analyse d'arrêt, aucun groupe de plans intégré n'est créé pour la base de données.

  Vous devez créer un groupe de plans défini par l'utilisateur pour convertir la base de données de secours cliché en base de données physique. Vous pouvez utiliser les commandes standard du broker Oracle Data Guard pour effectuer ces opérations et les placer dans un script wrapper.

  En outre, vous pouvez ajouter des groupes de plans définis par l'utilisateur liés à l'application pour arrêter toutes les applications associées à Oracle E-Business Suite.

Etapes suivantes

OCI Full Stack DR pour Oracle E-Business Suite doit être entièrement implémenté à ce stade. Toutefois, l'intégralité des fonctionnalités doit être validée avant d'utiliser OCI Full Stack DR pour la production. Tous les plans de basculement et de permutation doivent être exécutés pour confirmer que tout fonctionne comme prévu et que l'équipe de récupération comprend parfaitement l'ensemble du processus.

Tester les plans de permutation

Les plans de permutation sont conçus pour nettoyer tous les artefacts et garantir que tous les rôles pour les étapes de récupération intégrées telles qu'OCI Load Balancer, OCI Block Storage, OCI File Systems, Oracle Base Database Service et Oracle Autonomous Database sont prêts à être récupérés à partir de la région de secours sans intervention humaine.

Tester les plans de basculement

Les basculements sont différents. 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 à repasser les charges globales vers la région 1. L'équipe de récupération doit comprendre et effectuer des tâches pour s'assurer qu'Oracle Data Guard est dans le bon état, que les artefacts pour les instances de stockage et de calcul ont pris fin, etc. Pour plus d'informations, reportez-vous à Réinitialisation de la configuration DR après un basculement.

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

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

• Testez la permutation de la région 2 (principale) vers la région 1 (de secours).
• Testez le basculement de la région 1 (principale) vers la région 2 (de secours).
• Préparez la région 1 (principale) pour le basculement 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 de récupération après sinistre et la pile d'applications doivent être en état de fonctionnement normal et prêts pour un basculement ou une permutation à ce stade.
• Vous pouvez également exécuter des plans d'exploration de récupération après sinistre dans l'une ou l'autre des régions en fonction des besoins.

Obtenir de l'aide pour cette solution

L'ingénierie de récupération après sinistre OCI Full Stack fournit un support de 1er niveau pour cette solution.

Toutefois, la solution et toute automatisation personnalisée présentées dans ce tutoriel ont été conçues et implémentées par l'équipe de spécialistes Oracle Cloud EMEA indépendamment de l'organisation Oracle E-Business Suite ou de l'équipe d'ingénierie OCI Full Stack DR.

Relation entre Oracle E-Business Suite et OCI Full Stack DR

OCI Full Stack DR ne fait pas partie du processus d'installation ou de déploiement d'Oracle E-Business Suite et n'est mentionné dans aucune documentation écrite et gérée par Oracle E-Business Suite. La méthode d'installation, de configuration et de déploiement d'Oracle E-Business Suite pour la récupération après sinistre entre les régions OCI a été conçue et écrite dans l'ingénierie E-Business Suite byOracle. Elle est entièrement indépendante de ce tutoriel ou d'OCI Full Stack DR.

L'organisation Oracle E-Business Suite n'est pas familière avec OCI Full Stack DR et peut uniquement aider à résoudre les problèmes liés au processus Oracle E-Business Suite, comme décrit dans la documentation écrite par Oracle E-Business Suite pour la récupération après sinistre exécutée manuellement en dehors d'OCI Full Stack DR.

Le dépannage des problèmes avec le processus manuel Oracle E-Business Suite documenté par Oracle E-Business Suite relève de la responsabilité du support Oracle E-Business Suite et est effectué indépendamment de la récupération après sinistre OCI Full Stack. OCI Full Stack DR n'empêche pas les clients ou le support Oracle E-Business Suite d'exécuter manuellement le processus de récupération après sinistre Oracle E-Business Suite documenté. Par conséquent, le support Oracle E-Business Suite résoudra les problèmes liés à son processus manuel de récupération après sinistre sans impliquer OCI Full Stack DR.

Cependant, le fait de parcourir le processus de récupération manuelle documenté par Oracle E-Business Suite laissera probablement les groupes de protection de récupération après sinistre OCI Full Stack dans un état inutilisable qui devra être réinitialisé avant que les opérations puissent reprendre à l'aide d'OCI Full Stack DR avec Oracle E-Business Suite. La prise en charge d'OCI Full Stack DR aidera les clients à réinitialiser les groupes de protection de récupération après sinistre une fois que la prise en charge d'Oracle E-Business Suite aura terminé le dépannage et la résolution manuels.

La prise en charge commence avec OCI Full Stack DR

La prise en charge d'OCI Full Stack DR est le premier point de contact pour l'aide en cas de problème lié aux étapes et tâches décrites dans ce tutoriel. La prise en charge d'OCI Full Stack DR isolera le problème et déterminera quelle organisation de support est la mieux qualifiée pour résoudre le problème.

1. La prise en charge d'OCI Full Stack DR est responsable des éléments suivants :
   1. Aider les clients à comprendre la signification et la cause des messages d'erreur générés lors d'une opération de récupération après sinistre.
   2. Aider les clients à résoudre les problèmes grâce aux stratégies IAM qui empêchent Full Stack DR de gérer les ressources pendant une opération de récupération après sinistre.
   3. Problèmes lors de la création ou de la gestion des groupes de protection de récupération après sinistre.
   4. Problèmes liés à la création, à l'exécution ou aux échecs d'appel correct de l'automatisation personnalisée fournie par Oracle E-Business Suite ou l'équipe des solutions EMEA Cloud.
   5. Les clients sont responsables du dépannage et de la résolution des problèmes liés aux scripts personnalisés écrits par le client qui ne font pas partie de ce tutoriel.
2. La prise en charge d'OCI Full Stack DR ouvrira une demande de service avec le support Oracle E-Business Suite pour tous les problèmes directement liés à Oracle E-Business Suite lui-même. Les clients travailleront directement avec le support Oracle E-Business Suite pour résoudre les problèmes liés à Oracle E-Business Suite. Il incombe à Oracle E-Business Suite :
   1. Tout problème lié à la documentation My Oracle Support (MOS) écrite et conservée par Oracle E-Business Suite.
   2. Tous les problèmes liés aux scripts fournis aux clients par Oracle E-Business Suite.
   3. Tous les problèmes de base de données liés à Oracle E-Business Suite.
   4. Tout problème d'application lié à Oracle E-Business Suite.
   5. Tous les problèmes liés au processus Oracle E-Business Suite documenté pour récupérer Oracle E-Business Suite manuellement en dehors d'OCI Full Stack DR.
3. La prise en charge d'OCI Full Stack DR ouvrira une demande de service auprès de l'équipe interne Oracle Cloud Solutions appropriée pour tous les problèmes directement liés aux scripts ou au processus décrits dans ce tutoriel. Les clients travailleront directement avec l'équipe Oracle Cloud Solutions pour résoudre les problèmes liés à ce tutoriel. L'équipe Oracle Cloud Solutions est responsable des éléments suivants :
   1. Tous les problèmes liés aux scripts personnalisés fournis par l'équipe des solutions cloud.
   2. Tout problème avec le processus global tel que décrit dans ce tutoriel.

Comment ouvrir une requête d'assistance

Utilisez la console OCI pour ouvrir une demande d'assistance avec la prise en charge d'OCI Full Stack DR. Assurez-vous que le contexte du navigateur affiche le groupe de protection de récupération après sinistre que vous avez créé dans le cadre de ce tutoriel avant de démarrer ce processus.

1. Assurez-vous que le contexte du navigateur est défini sur le groupe de protection de récupération après sinistre approprié.
2. Sélectionnez le serveur de durée de vie dans la console OCI.
3. Sélectionnez Créer une requête d'assistance.

Fig 5 : utilisez l'outil d'aide de la console OCI pour ouvrir une demande de service

Fig 6 : les demandes d'assistance doivent être ouvertes à l'aide du bouton d'aide de la demande.

Liens connexes

• Page du produit OCI Full Stack Disaster Recovery

• Documentation OCI Full Stack Disaster Recovery

• Exemples de scripts Oracle E-Business Suite d'Oracle

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

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

Accusés de réception

• Auteurs - Chandra Dharanikota (spécialiste Oracle Apps to OCI, ingénierie Oracle Technology Cloud, EMEA), Suraj Ramesh - (récupération après sinistre de la pile complète, réviseur technique)

Ressources de formation supplémentaires

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

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

---

Informations relatives au titre et au copyright

Automate Recovery for Multi-Node Oracle E-Business Suite Using OCI Full Stack Disaster Recovery

G35483-02

Copyright ©2025, Oracle and/or its affiliates.