Remarques :

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

Automatisez la récupération pour Oracle Enterprise Performance Management à l'aide d'OCI Full Stack Disaster Recovery

Partie 1 : Introduction

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

Ce tutoriel décrit les procédures d'utilisation du service de récupération après sinistre de la pile complète OCI pour gérer les processus de permutation et de basculement pour un environnement système Oracle Enterprise Performance Management 11.1.2.x et 11.2.x dans une structure de récupération après sinistre OCI. Il est important de noter que la configuration de la topologie système et d'autres activités de cycle de vie (telles que l'application de patches, les tests, l'extension, etc.) ne relèvent pas du champ d'application de la récupération après sinistre OCI Full Stack.

La stratégie de récupération après sinistre utilise une réplication complète des volumes d'initialisation et de blocs de l'application et d'Oracle Data Guard pour la base de données de l'environnement de production vers le site de secours, ce qui simplifie considérablement la configuration de l'emplacement de secours. Cette méthode est conforme aux directives de récupération après sinistre décrites dans le Guide des options de déploiement EPM System, qui respecte les recommandations de récupération après sinistre fournies pour Fusion Middleware.

Oracle Enterprise Performance Management (Oracle EPM) et Hyperion EPM sont utilisés de manière interchangeable dans le tutoriel.

Oracle Enterprise Performance Management fait normalement partie d'un système plus grand

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

Ce tutoriel se concentre exclusivement sur Oracle EPM System pour plus de clarté. En pratique, Oracle EPM est généralement un composant d'un système métier plus large qui inclut divers services et applications au sein d'un seul groupe de protection de récupération après sinistre OCI Full Stack et d'un ensemble de plans de récupération après sinistre. Vous suivrez probablement des tutoriels Oracle Help Center (OHC) similaires pour d'autres applications et services tels que PeopleSoft,Oracle WebLogic Server,Oracle Analytics Cloud,Oracle Integration.

Attention à l'implémentation incrémentielle

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

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

Fonctionnement de la récupération

La solution de récupération pour Oracle EPM nécessite OCI Full Stack DR pour exécuter une série de scripts shell personnalisés lors d'une opération de récupération telle qu'un basculement ou une permutation. Les scripts référencés dans ce tutoriel sont fournis par l'équipe des spécialistes de l'architecture cloud EMEA et disponibles dans le référentiel Oracle EPM GitHub spécialement conçu pour cette solution Hyperion EPM DR. Les scripts sont téléchargés vers une instance de calcul faisant partie de la pile d'applications qu'OCI Full Stack DR gérera lors d'une opération de récupération.

Ce tutoriel explique comment télécharger les scripts et comment les utiliser ultérieurement.

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

Architecture de déploiement Oracle EPM

Dans ce tutoriel, nous utiliserons la topologie des instances de déplacement pour l'application Oracle EPM. En terminologie générale, les instances en mouvement sont appelées topologie Cold VM/Pilot light DR. Les machines virtuelles d'application sont déployées uniquement dans la région principale. Lors de l'exécution de la récupération après sinistre, les machines virtuelles sont créées dans la région de secours. Le système Oracle DB avec Oracle Data Guard doit être créé dans les régions principale et de secours. Avant de pouvoir implémenter la solution OCI Full Stack DR, le système Hyperion EPM principal doit être installé et entièrement configuré dans une région OCI.

Cette conception est basée sur l'architecture de récupération après sinistre de référence pour Hyperion sur OCI, qui peut être examinée en détail. Pour plus d'informations, reportez-vous à Conception de l'infrastructure pour déployer Oracle Enterprise Performance Management dans le cloud.

Equilibreur de charge OCI privé

Le trafic provenant de vos utilisateurs internes et sur site passe par des tunnels VPN IPSec ou des circuits virtuels FastConnect vers la passerelle de routage dynamique (DRG) attachée au VCN. Un équilibreur de charge privé intercepte les demandes et les distribue au niveau Web privé.

Le niveau Web est hébergé sur une instance de calcul attachée à un sous-réseau privé.

Niveau Applications

Toutes les instances de calcul du niveau d'application sont attachées à un sous-réseau privé. Cet isolement au niveau du réseau protège les applications des accès réseau non autorisés et des autres ressources de la topologie.

La passerelle de service permet aux instances de calcul privées du niveau application d'accéder aux serveurs Yum et WSUS de la région pour obtenir des mises à jour de système d'exploitation et des packages supplémentaires. De plus, la passerelle de service vous permet de sauvegarder les applications vers OCI Object Storage au sein de la région, sans passer par le réseau Internet public.

Les données stockées dans des volumes de blocs et un système de fichiers sont répliquées vers une région de secours à l'aide de la réplication inter-région (CRR).

Niveau base de données

Oracle Base Database Service héberge les schémas EPM System. Les données sont synchronisées avec la région de secours à l'aide de Data Guard.

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

Se familiariser avec l'ensemble du processus

Le spécialiste OCI EMEA et les équipes d'ingénierie de récupération après sinistre OCI Full Stack ont créé une série de vidéos complémentaires pour ce tutoriel afin de comprendre l'ensemble du flux de processus. Ces vidéos font partie d'une liste de lecture OCI Full Stack DR Oracle EPM dans YouTube accessible à l'aide des liens suivants :

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

Partie 2 : Instructions étape par étape

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

Objectifs

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

1. Tâche 1 : déployer Oracle EPM pour la récupération après sinistre
   1. Configurer une instance Oracle Data Guard inter-région pour Oracle Base Database Service
   2. Préparer le noeud de contrôle de récupération après sinistre pour exécuter l'automatisation personnalisée
   3. Créer un groupe de volumes de blocs
   4. Création de stratégies Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) pour la récupération après sinistre de la pile complète
   5. Création de stratégies OCI IAM pour d'autres services OCI
   6. Créer des buckets OCI Object Storage pour les journaux
   7. Créer un équilibreur de charge de secours (facultatif)
2. Tâche 2 : création de groupes de protection de récupération après sinistre (DRPG)
3. Tâche 3 : ajouter des membres aux DRPG des régions 1 et 2
4. Tâche 4 : créer des plans de récupération après sinistre de base dans la région 2 (Newport)
   1. Créer un plan de permutation
   2. Créer un plan de basculement
5. Tâche 5 : personnaliser le plan de permutation dans la région 2 (Newport)
6. Tâche 6 : personnaliser le plan de basculement dans la région 2 (Newport)
7. Tâche 7 : exécuter le plan de permutation dans la région 2 (Newport)
8. Tâche 8 : créer des plans de récupération après sinistre de base dans la région 1 (Londres)
   1. Créer un plan de permutation
   2. Créer un plan de basculement
9. Tâche 9 : personnaliser le plan de permutation dans la région 1 (Londres)
10. Tâche 10 : personnaliser le plan de basculement dans la région 1 (Londres)

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

Régions

La région 1 est Londres

• Londres sera la première région. Ce rôle finira par passer en mode veille une fois que vous serez invité à effectuer une permutation dans les étapes ultérieures.

La région 2 est Newport

• Newport démarre en tant que région de secours. Ce rôle deviendra le rôle principal une fois que vous serez invité à effectuer une permutation dans les étapes ultérieures.

Catégories

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

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

Le noeud de contrôle de récupération après sinistre est toute instance de calcul que vous désignez pour héberger des scripts personnalisés qui effectuent des tâches spécifiques pour récupérer EPM System. Les scripts sont appelés par Full Stack DR lors d'une opération de récupération. Toute instance de calcul existante membre d'un groupe de protection de récupération après sinistre (DRPG) peut être le noeud de contrôle. Dans cet exemple, le serveur d'applications EPM System héberge tous les scripts personnalisés utilisés dans le processus de récupération. Dans ce tutoriel, le noeud d'application et le noeud de contrôle sont identiques.

Prérequis

• Un système EPM entièrement configuré doit être déployé dans une région OCI. Il doit utiliser Oracle Base Database Service avec une licence permettant le déploiement d'une instance Oracle Data Guard inter-région.
• VCN et sous-réseaux dans la région de secours. Il est recommandé de mettre en miroir la topographie du réseau à partir de la région principale dans la région de secours. Pour la réplication Oracle Data Guard inter-région, l'appairage VCN entre les régions principale et de secours doit être activé. Par conséquent, les réseaux cloud virtuels ne doivent pas comporter de chevauchement de plages CIDR IP.

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

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

Tâche 1.1 : configurer une instance Oracle Data Guard inter-région pour Oracle Base Database Service

Afin de déployer Oracle Data Guard pour Oracle Base Database Service entre régions, reportez-vous à Utilisation d'Oracle Data Guard sur un système de base de données.

Lors de la synchronisation des bases de données de votre système avec Oracle Data Guard, il est essentiel d'utiliser le même nom de service de base de données ou alias TNS pour les bases de données principale et de secours. Cette pratique minimise les modifications nécessaires au niveau de la couche applicative après une permutation, ce qui garantit une transition en douceur. Pour obtenir des instructions détaillées, reportez-vous à la section "Remarques concernant la base de données" de la documentation Fusion Middleware DR, dans laquelle les différentes approches sont décrites en détail.

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

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

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

Téléchargez sur le noeud de contrôle de récupération après sinistre les scripts personnalisés d'ici : Scripts Oracle EPM Github écrits spécifiquement pour cet exemple de récupération après sinistre EPM System. Les scripts présentés ci-dessous doivent être copiés dans n'importe quel sous-répertoire de l'instance de calcul agissant en tant que noeud de contrôle de récupération après sinistre. Dans ce tutoriel, nous allons également utiliser le noeud d'application EPM en tant que noeud de contrôle de récupération après sinistre. Les scripts ont été créés spécifiquement pour cet exemple de récupération EPM System et devront être modifiés pour être utilisés dans votre solution de récupération. Dans ce tutoriel, l'application EPM s'exécute sur une machine virtuelle Windows et les scripts Powershell (ps1) sont donc utilisés. Si vous utilisez une machine virtuelle Linux, les scripts shell sont disponibles dans le même référentiel github. Etant donné que nous utilisons la machine virtuelle EPM pour exécuter les scripts, le noeud de contrôle de récupération après sinistre est référencé à la même machine virtuelle EPM.

Tâche 1.3 : créer un groupe de volumes de blocs

Créez un groupe de volumes de blocs dans la région 1 et assurez-vous qu'il est répliqué dans la région 2. Assurez-vous que le volume d'initialisation du noeud de contrôle de récupération après sinistre est membre d'un groupe de volumes de blocs et que le groupe de volumes de blocs est répliqué vers la région 2. Pour plus d'informations, reportez-vous à Création d'un groupe de volumes.

Assurez-vous que tout autre amorçage et bloc appartenant à tout autre calcul mobile pour ce projet de récupération après sinistre OCI Full Stack appartient également au groupe de volumes de blocs répliqué dans la région 2.

Tâche 1.4 : création de stratégies OCI IAM pour la récupération après sinistre de la pile complète OCI

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

• Stratégies pour OCI Full Stack DR
• Configuration des stratégies Identity and Access Management (IAM) pour utiliser la récupération après sinistre sur la pile complète

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

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

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

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

Commencez par accéder à Object Storage et Archive Storage, comme illustré à la figure 1.1.

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

Figure 1.1 : Accéder au stockage d'objets

Tâche 1.6.2 : bucket OCI Object Storage dans la région 1

Créez un bucket OCI Object Storage dans la région 1. Dans une étape ultérieure, le bucket sera affecté au groupe de protection de récupération après sinistre de la région 1.

1. Sélectionnez le compartiment contenant les ressources liées à EPM System.
2. Cliquez sur Créer un bucket.
3. Donnez au bucket un nom significatif qui identifie facilement l'application et le but qu'il sert.
4. Utilisez la valeur par défaut pour Niveau de stockage par défaut et Cryptage.
5. Cliquez sur Créer pour créer le bucket.

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

Tâche 1.6.3 : bucket OCI Object Storage dans la région 2

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

1. Remplacez le contexte par la région 2.
2. Sélectionnez le compartiment contenant les ressources associées à EPM System dans la région 2.
3. Cliquez sur Créer pour créer le bucket.

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

Tâche 1.7 : (facultatif) créer un équilibreur de charge OCI dans la région de secours

L'utilisation de l'équilibreur de charge OCI est facultative, si votre système EPM ne l'inclut pas, ignorez cette tâche.

Créez un équilibreur de charge OCI dans la région de secours :

1. Mettez en miroir la configuration de l'équilibreur de charge principal.
2. Créez un ensemble de back-ends vide dans cet équilibreur de charge. A ce stade de la région de secours, il n'y a aucun back-end à inclure dans la configuration. Par conséquent, seul un ensemble de back-ends vide doit être créé.

Configuration lors de la permutation ou du basculement :

1. La configuration de l'ensemble de back-ends EPM System principal sera copiée dans l'ensemble de back-ends de secours vide.

Certificats et processus d'écoute :

1. Si vous utilisez vos propres certificats, chargez-les sur l'équilibreur de charge de secours.
2. Configurez les processus d'écoute pour qu'ils correspondent à la configuration de l'équilibreur de charge principal.

Mise à jour après permutation de bases de données :

1. Après la permutation, mettez à jour les informations DNS pour qu'elles pointent vers l'adresse IP de l'équilibreur de charge de secours.

Pour plus d'informations, reportez-vous à Présentation de Load Balancer.

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

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

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

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

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

1. Assurez-vous que le contexte de région OCI est défini sur la région 1 (Londres).
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 2-1 : Accéder aux groupes de protection de récupération après sinistre

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

Créez un groupe de protection de récupération après sinistre de base (DRPG) dans la région 1, comme illustré à la figure 2-2 ci-dessous. Le pair, le rôle et les membres seront affectés dans les étapes suivantes.

1. Sélectionnez le compartiment où créer le DRPG. Il peut s'agir du compartiment dans lequel les ressources EPM System existent.
2. Cliquez sur Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue.
3. Utilisez un nom explicite pour le DRPG.
4. Sélectionnez le bucket de stockage d'objet créé dans la tâche 2 pour la région 1.
5. Cliquez sur Créer.

Figure 2.2 : Paramètres nécessaires à la création d'un groupe de protection de récupération après sinistre dans la région 1

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

Créez un groupe de protection de récupération après sinistre de base (DRPG) dans la région 2, comme illustré à la figure 2-3 ci-dessous. Le pair, le rôle et les membres seront affectés dans les étapes suivantes.

1. Remplacez le contexte de région OCI par la région 2 (Newport).
2. Sélectionnez le compartiment où créer le DRPG. Il peut s'agir du compartiment dans lequel les ressources EPM System existent.
3. Cliquez sur Créer un groupe de protection de récupération après sinistre pour ouvrir la boîte de dialogue.
4. Utilisez un nom explicite pour le DRPG.
5. Sélectionnez le bucket de stockage d'objet créé dans la tâche 2 pour la région 2.
6. Cliquez sur Créer.

Figure 2-3 : Paramètres nécessaires à la création d'un groupe de protection de récupération après sinistre dans la région 2

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

Associez les DRPG de chaque région en tant qu'homologues et affectez les rôles homologues de la base principale et de la base de données de secours. C'est ainsi qu'OCI Full Stack DR saura quelles deux régions fonctionnent ensemble pour la récupération d'Oracle EPM System. Les rôles de la base de données principale et de la base de données de secours sont automatiquement modifiés par OCI Full Stack DR dans le cadre de toute opération de récupération après sinistre/exécution de plan de récupération après sinistre. Il n'est pas nécessaire de gérer les rôles manuellement à tout moment.

Tâche 2.4.1 : démarrer l'association

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

Figure 2.4.1 : Commencer l'association DRPG

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

Indiquez les paramètres comme indiqué à la figure 2.4.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 (Newport), où l'autre DRPG a été créé.
3. Sélectionnez le DRPG homologue dans lequel il a été créé.
4. Cliquez sur Associer.

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

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

OCI Full Stack DR affiche quelque chose comme la figure 2.4.3, une fois l'association terminée.

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

Figure 2.4.3 : Montrer la relation entre pairs du point de vue DRPG individuel

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

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

Figure 2.4.4 : Montrer la relation entre pairs du point de vue DRPG global

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

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

Ajoutez les noeuds de calcul de la base de données et de l'application Oracle EPM System en tant que membres des groupes de protection de récupération après sinistre. Le noeud de contrôle de récupération après sinistre est une instance de calcul que vous avez créée uniquement pour prendre en charge l'orchestration de récupération après sinistre ou une instance de calcul qui fait partie de la pile d'applications à gérer avec la récupération après sinistre de la pile complète. Dans cet exemple, le noeud d'application EPM System exécute également la fonction de noeud de contrôle de récupération après sinistre.

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

1. Le noeud de calcul de l'application EPM System, qui exécute également la fonction du noeud de contrôle de récupération après sinistre.
2. Le groupe de volumes contient le volume d'initialisation du noeud de calcul de l'application EPM System. Le cas échéant, tous les volumes de blocs supplémentaires attachés aux noeuds de calcul doivent être inclus dans le groupe de volumes.
3. Oracle Base Database Service principal.
4. Equilibreur de charge principal.

Tâche 3.1 : Début de l'ajout de membres à DRPG dans la région 1

Commencez par sélectionner le DRPG dans la région 1, comme le montre la figure 3-1.

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

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

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

Ajoutez une instance de calcul pour EPM System, qui sert également de noeud de contrôle de récupération après sinistre, comme illustré à la figure 3.1.1. Dans cet exemple, une seule instance de calcul héberge tous les modules d'EPM System. Si votre système EPM est déployé dans un environnement distribué avec plusieurs noeuds de calcul, assurez-vous que chaque noeud est inclus dans cette étape.

1. Accuser réception d'un avertissement concernant les plans de récupération après sinistre.
2. Entrez Compute en tant que type de ressource de membre.
3. Sélectionnez l'instance de calcul de l'application EPM System. Cette même instance de calcul sera également utilisée pour exécuter des scripts définis par l'utilisateur.
4. Sélectionnez Instance mobile.
5. Ajoutez OCI Full Stack DR que le VCN et le sous-réseau doivent affecter aux cartes d'interface réseau virtuelles de la région 2 lors d'une récupération. La figure 4-2 présente une carte VNIC unique. OCI Full Stack DR ne se soucie pas du nombre de cartes d'interface réseau virtuelles dont vous disposez ou de la façon dont elles sont configurées dans l'une ou l'autre région. Indiquez ce dont vous avez besoin pour répondre à vos besoins. Veillez à fournir une adresse IP valide à partir du sous-réseau cible dans la région de secours. Cela simplifiera la mise à jour des fichiers hôtes après la permutation, car l'instance de calcul utilisera systématiquement la même adresse IP connue.

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

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

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

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

Figure 3.1.2 : Paramètres nécessaires pour ajouter un groupe de volumes d'initialisation pour EPM Compute

Tâche 3.1.3 : ajouter un service Oracle Base Database Service principal

A ce stade, Oracle Data Guard doit déjà être configuré pour le système de service Oracle Base Database dans le cadre de la tâche 1. Ajoutez la base de données principale en tant que membre du DRPG dans la région 1.

1. Sélectionnez Base de données comme type de ressource de membre.
2. Assurez-vous que le compartiment approprié pour la base de données est sélectionné.
3. Fournissez les détails de la clé secrète dans OCI Vault contenant le mot de passe utilisateur SYS de la base de données EPM. Vous avez créé cette clé secrète lors de la configuration d'Oracle Data Guard dans la tâche 1.

Figure 3.1.3 : Paramètres nécessaires pour ajouter la base de données principale exécutée à partir du service de base de données de base

Tâche 3.1.4 : ajouter un équilibreur de charge OCI

Dans cet exemple, nous ajoutons l'équilibreur de charge en tant que membre du DRPG dans la région 1.

1. Sélectionnez Equilibreur de charge en tant que type de ressource de membre.
2. Assurez-vous que les compartiments appropriés pour l'équilibreur de charge sont sélectionnés.
3. Sélectionnez Ensemble de back-ends source : il s'agit de l'ensemble de back-ends utilisé par l'application EPM System. Un équilibreur de charge OCI peut être partagé entre plusieurs applications et plusieurs ensembles de back-ends peuvent être configurés. Lors d'une permutation de récupération après sinistre, seule la configuration des ensembles de back-ends indiqués ici sera déplacée vers la région de secours.
4. Sélectionnez Ensemble de back-ends de destination : il s'agit de l'ensemble de back-ends vide créé dans la tâche 1.7 de la région 2.

Figure 3.1.4 : Paramètres nécessaires à l'ajout d'un équilibreur de charge

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

Le DRPG pour la région 1 devrait maintenant disposer de quatre ressources membres, comme le montre la figure 3.1.5. Les noms de vos ressources membres seront différents.

1. La base de données principale.
2. Instance de calcul mobile.
3. Groupe de volumes de blocs pour l'instance de calcul.
4. Equilibreur de charge OCI

Figure 3.1.5 : Affichage des membres de DRPG dans la région 1

Tâche 3.2 : Début de l'ajout de membres à DRPG dans la région 2

Commencez par sélectionner le DRPG dans la région 2.

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

Vous allez ajouter les ressources suivantes au DRPG de secours dans la région 2 en procédant comme dans la région principale :

1. Système Oracle Base Database Service de secours/distant.
2. Equilibreur de charge OCI de secours.

Une fois la tâche terminée, le DRPG de la région 2 devrait disposer de deux ressources membres, comme le montre la figure 3.2 ci-dessous.

Figure 3.2 : Affichage des membres de DRPG dans la région 2

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

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

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

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

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

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

Créer un plan de base en sélectionnant le DRPG dans la région 2 (Newport)

1. Assurez-vous que le contexte de région OCI est la région 2 (Newport).
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 4-1 : Comment commencer à créer des plans de récupération après sinistre de base dans la région 2

Tâche 4.1.1 : Créer un plan de permutation de rôles

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

1. Rendre le nom du plan de permutation simple mais significatif. Le nom doit être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
2. Sélectionnez le type de plan Permutation (planifiée). Il n'existe que quatre types de plan au moment de la rédaction de ce document.

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

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

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

1. Rendre le nom du plan de basculement simple mais significatif. Le nom doit être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.
2. Sélectionnez le type de plan Basculement (non planifié). Il n'existe que quatre types de plan au moment de la rédaction de ce document.

Figure 4.1.2 : Paramètres nécessaires à la création d'un plan de basculement de récupération après sinistre

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

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

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

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

• Arrêtez les services EPM System dans la région principale 1 en cours avant d'arrêter les machines virtuelles.
• Mettez à jour les fichiers hôtes sur le noeud de calcul pour mettre en correspondance les adresses IP de secours avec les noms d'hôte de la région principale.
• Démarrez les services EPM System dans la région de secours 2 en cours après avoir lancé des machines virtuelles.

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

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

Figure 5.1 : Commencer à personnaliser le plan de permutation dans la région 2

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

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

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

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

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

Figure 5.2 : Groupes de plans désactivés par défaut

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

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

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

Tâche 5.2.1 : Activer la terminaison du groupe de plans de calcul

Activez le groupe de plans.

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

   
   Figure 5.2.1 : Procédure d'activation de la terminaison d'instances de calcul

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

Activez le groupe de plans.

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

   
   Figure 5.2.2 : Activation de la terminaison de groupes de volumes

Tâche 5.3 : créer un groupe de plans pour exécuter des scripts personnalisés dans la région 1 (principale)

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

Le premier groupe de plans défini par l'utilisateur exécute des scripts personnalisés pour arrêter l'exécution des services EPM System dans la région principale 1. Ce groupe de plans contient une étape unique qui appelle le script Windows PowerShell stop_services.ps1, qui a été téléchargé dans le dossier c:/scripts sur le noeud d'application EPM dans la tâche 1.2.

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

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

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

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

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

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

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

1. Nom descriptif de l'étape expliquant la tâche effectuée par cette étape.
2. Sélectionnez toujours la région dans laquelle le noeud d'application EPM est en cours d'exécution, et non l'endroit où il sera en cours d'exécution lors d'une permutation. OCI Full Stack DR gardera une trace de l'emplacement d'exécution de la machine virtuelle. Il vous suffit donc de spécifier son emplacement actuel. Dans ce cas, le noeud d'application EPM est exécuté dans la région 1 (Londres).
3. Sélectionnez le compartiment correct qui contient le noeud de contrôle de récupération après sinistre. Sélectionnez ensuite l'instance de calcul désignée comme noeud de contrôle de récupération après sinistre. Dans cet exemple, il s'agit du calcul d'application EPM System.
4. Sélectionnez Exécuter le script local pour informer la récupération après sinistre de la pile complète OCI que le script sera trouvé sur une instance de calcul. Les scripts Windows PowerShell ont été téléchargés vers le noeud de contrôle de récupération après sinistre dans la tâche 1.2.
5. Collez le chemin absolu dans lequel vous avez installé le script stop_services.ps1 sur le noeud de contrôle de récupération après sinistre. Ajoutez stop en tant que premier paramètre et l'ID de région OCI en tant que deuxième.
6. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter les services EPM. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. OCI Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
7. La valeur par défaut avant que Full Stack DR ne déclare une défaillance est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
8. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 5.3.2 : Paramètres permettant de créer l'étape de plan pour arrêter EPM

Tâche 5.3.3 : Terminer l'ajout d'un groupe de plans et d'une étape

L'étape d'arrêt d'EPM System a été ajoutée au groupe de plans de récupération après sinistre, comme illustré à la figure 5.3.3 ci-dessous.

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

Figure 5.3.3 : Finaliser l'ajout d'un groupe de plans et d'une étape pour arrêter EPM

Tâche 5.4 : Créer un groupe de plans pour exécuter des scripts personnalisés dans la région 2 (de secours)

Le second groupe de plans défini par l'utilisateur met à jour les fichiers hôtes sur les noeuds de calcul et démarre les services EPM System après le lancement du noeud de contrôle de récupération après sinistre dans la région de secours 2. Ce groupe de plans contient deux étapes qui appellent les scripts host_switch_failover.ps1 et start_services.ps1 PowerShell téléchargés vers le noeud de contrôle de récupération après sinistre dans la tâche 1.2.

Tâche 5.4.1 Créer un groupe de plans de récupération après sinistre pour mettre à jour le fichier hôte après la permutation vers la région de secours

1. Attribuez au groupe de plans un nom de groupe simple mais descriptif.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui lance la version répliquée du noeud d'application EPM System, qui exécute également la fonction du noeud de contrôle de récupération après sinistre à la région 2.
3. Sélectionnez le groupe de plans Lancer les instances de calcul intégré
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour du fichier hôte.

Figure 5.4.1 : Paramètres permettant de créer l'étape de plan pour démarrer EPM

Tâche 5.4.2 : indiquer le nom de l'étape et les paramètres de script local pour le script de mise à jour du fichier hôte

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Le script host_switch_failover.ps1 met à jour le fichier hôte sur le noeud de calcul afin que les nouvelles adresses IP des instances de calcul et de base de données de la région 2 soient mises en correspondance avec le nom d'hôte de la région 1 d'origine. Cela permet de démarrer l'application sans aucune autre modification dans la couche d'application.

Cette étape est identique à la tâche 5.3.2, à l'exception des éléments indiqués à la figure 5.4.2 ci-dessous.

1. Nom descriptif de l'étape expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans PowerShell.exe et l'emplacement d'installation du script host_switch_failover.ps1 sur le noeud d'application EPM.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 5.4.2 : Paramètres de mise à jour du fichier hôte

Tâche 5.4.3 : Indiquer le nom de l'étape et les paramètres de script local pour le script de démarrage du service EPM System

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

1. Nom descriptif de l'étape expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans PowerShell.exe et l'emplacement d'installation du script start_services.ps1 sur le noeud d'application EPM.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.
4. Cliquez sur Ajouter pour ajouter le groupe de plans qui contient désormais deux étapes permettant d'exécuter deux scripts personnalisés.

Figure 5.4.3 : Paramètres de démarrage d'EPM

Le plan de permutation doit désormais inclure les deux groupes de plans de récupération après sinistre, comme illustré dans la capture d'écran suivante.

Figure 5.4.4 : Script personnalisé après démarrage

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

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

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

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

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

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

Tâche 6.1.2 : ajouter des étapes au nouveau groupe de plans défini par l'utilisateur

1. Cliquez sur Ajouter un groupe.

   
   Figure 6.1.2 Paramètres permettant de créer l'étape de plan pour démarrer EPM

2. Suivez les instructions de la tâche 5.4 pour ajouter deux étapes au groupe de plans défini par l'utilisateur afin d'exécuter les scripts personnalisés : host_switch_failover.ps1 et start_services.ps1.

3. Une fois les étapes ajoutées et le groupe de plans défini par l'utilisateur, le plan de basculement doit se présenter comme suit :

   
   Figure 6.1.3 Paramètres permettant de créer l'étape de plan permettant de démarrer EPM et de mettre à jour les hôtes

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

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

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

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

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 EPM System de la région 1 à la région 2.

1. Assurez-vous que le contexte de région est toujours défini sur la région de secours 2 (Newport).
2. Utilisez le chemin de navigation en haut de la console pour vous assurer que les détails du groupe de protection de récupération après sinistre correspondent au contexte de plan actuel.
3. Assurez-vous que le groupe de protection de récupération après sinistre correct dans la région 2 est sélectionné ; il doit s'agir du rôle de secours.
4. Avant de continuer, assurez-vous que les plans de basculement et de permutation existent. Sinon, revenez aux tâches précédentes pour créer les deux plans de récupération après sinistre.
5. Cliquez sur Execute DR plan.

Figure 7-1 : Montrer comment exécuter une permutation vers la 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 Execute DR plan pour commencer.

Figure 7.2 : Choisir et exécuter le plan de permutation

Tâche 7.3 : étapes suivantes

Surveillez le plan de permutation de rôles jusqu'à ce que la charge globale EPM System passe entièrement de la région 1 à la région 2. La récupération après sinistre de la pile complète nettoie les artefacts et modifie les rôles principal et de secours entre les régions. En cas d'échec de l'exécution du plan de permutation de rôles, vérifiez les journaux et assurez-vous que le plan est exécuté correctement.

Une fois la permutation terminée, la région 2 (Newport) deviendra la région principale et la région 1 (Londres) la région de secours.

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

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

Chaque plan vise à 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. Dans le cadre de toute opération de récupération après sinistre, les rôles des groupes de protection de récupération après sinistre dans les deux régions sont automatiquement inversés, de sorte que le groupe de protection de récupération après sinistre de la région 2 devient la base de données de secours et que le groupe de protection de récupération après sinistre de la région 1 devient la base de données principale après un basculement ou une permutation.

OCI Full Stack DR préremplira les deux plans avec des étapes intégrées en fonction des ressources membres ajoutées dans la tâche précédente. Dans les étapes suivantes, les plans seront personnalisés pour gérer toutes les tâches liées à EPM System au cours d'une opération de récupération.

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

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

Créez un plan de base en sélectionnant le DRPG dans la région 1, comme le montre la figure 8.1.

1. Assurez-vous que le contexte de région OCI est la région 1 (Londres).
2. Sélectionnez le DRPG de secours dans la région 1.
3. Sélectionnez Plans.
4. Cliquez sur Créer un plan pour lancer le processus.
5. 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.
6. Sélectionnez Type de plan comme Permutation (planifiée). Il n'existe que quatre types de plan au moment de la rédaction de ce document.
7. Cliquez sur Créer pour créer un plan de permutation de base prérempli avec des étapes de base intégrées.

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

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

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

1. Rendez le nom du plan de basculement simple mais significatif. Le nom doit être aussi court que possible, mais facile à comprendre en un coup d'œil pour aider à réduire la confusion et l'erreur humaine pendant une crise.

2. Sélectionnez Type de plan comme Basculement (non planifié). Il existe quatre types de plan au moment de la rédaction de ce document.

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

Figure 8.2 : Paramètres nécessaires à la création d'un plan de basculement de récupération après sinistre

Le groupe de protection de récupération après sinistre de secours de la région 1 doit désormais disposer des deux plans de récupération après sinistre comme indiqué ci-dessous. Ceux-ci géreront la transition des charges globales de la région 2 vers la région 1.

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

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

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

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

• Arrêtez les services EPM System dans la région principale 1 en cours avant d'arrêter les machines virtuelles.
• Mettez à jour les fichiers hôtes sur le noeud de calcul pour mettre en correspondance les adresses IP de secours avec les noms d'hôte de la région principale.
• Démarrez les services EPM System dans la région de secours 2 en cours après avoir lancé des machines virtuelles.

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

Accédez au plan de permutation créé dans la tâche précédente.

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

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

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

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

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

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

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

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

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

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

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

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

Activez le groupe de plans.

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

   
   Figure 9.2.1 : Procédure d'activation de la terminaison d'instances de calcul

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

Activez le groupe de plans.

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

   
   Figure 9.2.2 : Activation de la terminaison de groupes de volumes

Tâche 9.3 : Créer un groupe de plans pour exécuter des scripts personnalisés dans la région 2 (principale)

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

Le premier groupe de plans défini par l'utilisateur exécute des scripts personnalisés pour arrêter l'exécution des services EPM System dans la région principale 2. Ce groupe de plans contient une étape unique qui appelle le script Windows PowerShell stop_services.ps1 téléchargé dans le dossier c:/scripts sur le noeud de contrôle de récupération après sinistre de la tâche 1.2.

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

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

1. Cliquez sur Ajouter un groupe pour commencer.
2. Attribuez un nom simple mais descriptif au groupe de plans.
3. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur avant le groupe de plans intégré qui arrête les machines virtuelles de la région 2.
4. Sélectionnez le groupe de plans Arrêter les instances de calcul (principales) intégré.
5. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script permettant d'arrêter EPM System.

Figure 9.3.1 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour arrêter les services EPM System

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

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

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

1. Nom descriptif de l'étape expliquant la tâche effectuée par cette étape.
2. Le plan de récupération après sinistre doit s'arrêter si le script ne parvient pas à arrêter les services EPM. Cela permettra à n'importe qui de voir qu'il y a un problème et de le résoudre. Full Stack DR permet de continuer à exécuter le plan de permutation après avoir résolu le problème.
3. La valeur par défaut avant qu'OCI Full Stack DR ne déclare un échec est d'une heure. Cette valeur peut être remplacée par 30 minutes ou par une valeur d'expiration plus réaliste.
4. Sélectionnez toujours la région dans laquelle le noeud de contrôle de récupération après sinistre est en cours d'exécution, et non l'endroit où il sera en cours d'exécution lors d'une permutation. OCI Full Stack DR gardera une trace de l'emplacement d'exécution de la machine virtuelle. Il vous suffit donc de spécifier son emplacement actuel. Dans ce cas, le noeud de contrôle de récupération après sinistre est exécuté dans la région 1 (Londres).
5. Sélectionnez Exécuter le script local pour informer Full Stack DR que le script sera trouvé sur une instance de calcul. Les scripts Windows PowerShell ont été téléchargés vers le noeud de contrôle de récupération après sinistre dans la tâche 1.2.
6. Sélectionnez le compartiment correct qui contient le noeud de contrôle de récupération après sinistre. Sélectionnez ensuite l'instance de calcul désignée comme noeud de contrôle de récupération après sinistre. Dans cet exemple, il s'agit du calcul d'application EPM System.
7. Collez le chemin absolu dans lequel vous avez installé le script stop_services.ps1 sur le noeud de contrôle de récupération après sinistre. Ajoutez stop en tant que premier paramètre et l'ID de région OCI en tant que deuxième.
8. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 9.3.2 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour démarrer les services EPM System

Tâche 9.3.3 : Terminer l'ajout d'un groupe de plans et d'une étape

1. L'étape d'arrêt d'EPM System est maintenant ajoutée au groupe de plans de récupération après sinistre, comme illustré à la figure 9.3.3.

   
   Figure 9.3.3 : Paramètres permettant de créer un groupe de plans et d'ajouter une étape pour arrêter les services EPM System

2. Affiche l'étape de plan qui vient d'être ajoutée. Il est possible d'ajouter des étapes supplémentaires à un groupe de plans de récupération après sinistre, mais ce groupe n'inclut que l'étape permettant d'arrêter les services EPM.

3. Cliquez sur Ajouter pour ajouter le groupe et l'étape de plan de récupération après sinistre au plan de récupération après sinistre.

   
   Figure 9.3.4 : Paramètres permettant de créer un groupe de plans et un groupe ajoutés pour arrêter les services EPM System

Tâche 9.4 : créer un groupe de plans pour exécuter des scripts personnalisés dans la région 1 (de secours)

Le second groupe de plans défini par l'utilisateur met à jour les fichiers hôtes sur les noeuds de calcul et démarre les services EPM System après le lancement du noeud de contrôle de récupération après sinistre dans la région de secours 1. Ce groupe de plans contient deux étapes qui appellent les scripts host_switch_failback.ps1 et start_services.ps1 PowerShell téléchargés vers le noeud de contrôle de récupération après sinistre dans la tâche 1.2. Le script host_switch_failback.ps1 inverse les modifications introduites par le script host_switch_failover.ps1 dans la région Newport et restaure les fichiers hôtes d'origine sur les noeuds de calcul une fois qu'ils ont été déplacés vers la région principale d'origine à Londres.

Tâche 9.4.1 Créer un groupe de plans de récupération après sinistre pour mettre à jour le fichier hôte après la permutation vers la région de secours

1. Attribuez un nom simple mais descriptif au groupe de plans.
2. Sélectionnez le poste où le groupe de plans sera inséré dans le plan de récupération après sinistre. Dans ce cas, nous allons insérer notre groupe de plans défini par l'utilisateur après le groupe de plans intégré qui lance la version répliquée du noeud d'application EPM System, qui exécute également la fonction du noeud de contrôle de récupération après sinistre dans la région 1.
3. Sélectionnez le groupe de plans Lancer les instances de calcul (de secours) intégré.
4. Cliquez sur Ajouter une étape pour ouvrir la boîte de dialogue dans laquelle nous indiquerons le script de mise à jour du fichier hôte.

Figure 9.4.1 : Paramètres permettant de créer un groupe de plans et un groupe de plans ajoutés pour mettre à jour le fichier hôte

Tâche 9.4.2 : indiquer le nom de l'étape et les paramètres de script local pour le script de mise à jour du fichier hôte

La boîte de dialogue Ajouter une étape de groupe de plans permet de spécifier des paramètres sur les performances de cette étape et son comportement lors de la récupération. Le script host_switch_failback.ps1 met à jour le fichier hôte sur le noeud de calcul. Il inverse les modifications introduites par le script host_switch_failback.ps1 dans la région Newport et restaure le fichier hôte d'origine pour la région 1 (Londres). Cela permettra à l'application de démarrer sans aucune autre modification dans la couche d'application.

Cette étape est identique à la tâche 9.3.2, à l'exception des éléments présentés dans la figure.

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans PowerShell.exe et dans l'emplacement où vous avez installé le script host_switch_failover.ps1 sur le noeud de contrôle de récupération après sinistre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.

Figure 9.4.2 : Paramètres permettant de créer un groupe de plans et des détails d'étape ajoutés pour mettre à jour le fichier hôte

Tâche 9.4.3 : Indiquer le nom de l'étape et les paramètres de script local pour le script de démarrage du service EPM System

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

1. Nom descriptif expliquant la tâche effectuée par cette étape.
2. Collez le chemin absolu dans PowerShell.exe et dans l'emplacement où vous avez installé le script start_services.ps1 sur le noeud de contrôle de récupération après sinistre.
3. Cliquez sur Ajouter une étape pour ajouter cette étape au groupe de plans.
4. Cliquez sur Ajouter pour ajouter le groupe de plans qui contient désormais deux étapes permettant d'exécuter deux scripts personnalisés.

Le plan de permutation doit désormais inclure les deux groupes de plans de récupération après sinistre, comme illustré dans la capture d'écran suivante.

Figure 9.4.3 : Permutation de groupes de plans définis par l'utilisateur

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

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

Tâche 10.1 : ajouter un groupe de plans défini par l'utilisateur au plan de basculement

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

Figure 10.1 : Plan de basculement en cas d'incident dans la région 1

Tâche 10.1.1 : ajouter un groupe de plans

1. Assurez-vous que la région de secours 2 est toujours le contexte de région en cours dans la console.
2. Sélectionnez le plan de basculement.
3. Cliquez sur Ajouter un groupe.
4. Indiquez le nom du groupe.
5. Ajoutez-le au plan après l'étape intégrée Lancer l'instance de calcul.

Figure 10.1 : Paramètres permettant de créer un groupe de plans pour exécuter des scripts personnalisés après le basculement vers la région 2.

Tâche 10.1.2 : ajouter des étapes au nouveau groupe de plans défini par l'utilisateur

1. Suivez les instructions de la tâche 9.4 pour ajouter deux étapes au groupe de plans défini par l'utilisateur afin d'exécuter le script personnalisé : host_switch_failback.ps1.

   
   Figure 10.2 : Paramètres permettant de créer une étape de groupe de plans pour le script de mise à jour du fichier hôte.

2. Ajoutez une deuxième étape dans le groupe de plans pour démarrer les services à l'aide du script start_services.ps1.

   
   Figure 10.3 : Paramètres permettant de créer une étape de groupe de plans pour le script de mise à jour du fichier hôte.

3. Après avoir ajouté des étapes, le groupe de plans défini par l'utilisateur doit ressembler à ceci et cliquer sur Ajouter.

   
   Figure 10.4 : Groupe de plans présentant les étapes configurées pour exécuter deux scripts locaux après le lancement de l'instance de calcul.

4. Le plan de basculement doit désormais inclure le groupe de plans de récupération après sinistre défini par l'utilisateur pour EPM System, comme illustré dans la capture d'écran suivante. Vous pouvez disposer de groupes de plans supplémentaires si votre groupe de protection inclut d'autres applications ou services OCI avec EPM System.

   
   Figure 10.5 : Plan de basculement présentant les groupes de plans définis par l'utilisateur

Etapes suivantes

La récupération après sinistre de la pile complète OCI pour EPM System doit être entièrement implémentée à ce stade. Cependant, l'intégralité des fonctionnalités doit être validée avant de l'utiliser en production. Tous les plans de basculement et de permutation doivent être exécutés pour vérifier que tout fonctionne comme prévu et que l'équipe de récupération comprend parfaitement l'ensemble du processus.

Tester les plans de permutation

Les plans de permutation sont conçus pour nettoyer tous les artefacts et garantir que tous les rôles des étapes de récupération intégrées, telles que l'équilibreur de charge, le stockage de blocs, les systèmes de fichiers, BaseDB, ExaCS et Autonomous 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. Les basculements par nature ne peuvent pas nettoyer les artefacts ni garantir que les services et les bases de données de la région en échec sont prêts à faire passer les charges globales vers la région 1. L'équipe de récupération doit comprendre et effectuer des tâches pour s'assurer qu'Oracle Data Guard est dans l'état correct, que les artefacts des instances de stockage et de calcul ont été arrêtés, etc. Pour plus d'informations, reportez-vous à la section Resetting DR Configuration After a Failover.

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

L'équipe de récupération doit effectuer une validation finale pour démontrer l'état de préparation des groupes de protection de récupération après sinistre OCI Full Stack et des plans pour les workloads de production. La région 2 (Newport) 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 entre la région 1 (principale) et la région 2 (de secours).

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

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

• Préparez la région 2 (principale) pour un basculement ou une permutation vers la région 2.

• Vous pouvez également créer et tester des plans d'exploration et d'exploration de démarrage en fonction des besoins.

• Les groupes de protection de récupération après sinistre et la pile d'applications doivent être dans un état opérationnel normal et prêts pour un basculement ou une permutation à ce stade.

Liens connexes

• Concevoir l'infrastructure pour le déploiement d'Oracle Enterprise Performance Management dans le cloud

• Guide des options de déploiement : Récupération après sinistre pour Hyperion EPM System

• Remarques concernant la base de données : Récupération après sinistre pour Fusion Middleware

• Emplacement des exemples de script 1 : téléchargez les exemples de script EPM à partir de GitHub

• Emplacement des exemples de script 2 : téléchargez les exemples de script EPM à partir de GitHub

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

  • Vidéo 1 : Déployer Oracle EPM pour la récupération après sinistre

  • Vidéo 2 : Automatisez les opérations de récupération après sinistre pour Oracle EPM à l'aide d'OCI Full Stack DR

  • Vidéo 3 : Scripts utilisés pour automatiser la récupération pour Oracle EPM

• Oracle Cloud Infrastructure (OCI) - Récupération après sinistre de la pile complète

• Documentation OCI Full Stack Disaster Recovery

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

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

Remerciements

• Auteur - Grzegorz Reizer (spécialiste Oracle EPM)

• Contributeur - Suraj Ramesh (chef de produit pour OCI Full Stack DR)

Ressources de formation supplémentaires

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

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

---

Informations relatives au titre et au copyright

Automate Recovery for Oracle Enterprise Performance Management using OCI Full Stack Disaster Recovery

G11409-01

July 2024

Copyright ©2024,

Oracle et/ou ses affiliés.