A propos de la configuration de la récupération après sinistre JD Edwards à l'aide d'OCI Full Stack Disaster Recovery
Pour garantir une stratégie de récupération après sinistre robuste, automatisée et évolutive pour votre application JD Edwards (JDE) hébergée sur Oracle Cloud Infrastructure (OCI), utilisez le service Oracle Cloud Infrastructure Full Stack Disaster Recovery (FSDR). FSDR assure la continuité des activités en orchestrant les processus de basculement et de rétablissement entre les régions pour les composants d'infrastructure et d'application.
Ce document décrit l'architecture JD Edwards et fournit les procédures de configuration et d'implémentation nécessaires à la configuration de l'environnement de récupération après sinistre à l'aide d'OCI FSDR, tout en tenant compte des exigences de sécurité, de performances et de conformité nécessaires.
Architecture JD Edwards
Cette illustration présente l'architecture de déploiement de l'application JD Edwards, avec des régions principale et secondaire.
Région principale
Dans la région principale, l'environnement JDE est déployé dans un réseau cloud virtuel (VCN) segmenté en trois sous-réseaux dédiés, qui sont séparés par des fonctionnalités de ressources d'application, comme décrit ci-dessous.
- Niveau d'équilibreur de charge
Le niveau d'équilibreur de charge héberge l'équilibreur de charge OCI, qui fournit un accès aux services Web JDE aux utilisateurs finals.
- Niveau Applications
Le niveau application contient les principaux composants de l'application, notamment le serveur Enterprise Server, le serveur Web et le serveur AIS (Application Interface Services).
- Niveau de gestion
Le niveau de gestion inclut des outils et des services pour la gestion et l'administration de JDE, tels que le serveur de déploiement et le serveur Server Manager Console.
- Niveau base de données
Dans la couche de base de données, la base de données JDE est déployée sur Autonomous Transaction Processing - Partagé (ATP-S). Les serveurs d'applications se connectent à la base de données à l'aide d'adresses. Oracle Autonomous Data Guard est activé. Il permet de créer une base de données de secours dans la région secondaire et d'assurer la réplication des données en temps réel pour la haute disponibilité et la récupération après sinistre.
- Stockage et protection des données
Les groupes de volumes de blocs utilisés par les instances de calcul sont protégés par la réplication de groupe de volumes inter-région, la région secondaire étant configurée en tant que cible de réplication.
Région secondaire
La région secondaire sert de site de récupération après sinistre et met en miroir les composants critiques du fichier region.It principal :
- Structure VCN répliquée qui correspond à la disposition réseau de la région principale.
- Un équilibreur de charge de réplique pour assurer la continuité de l'accès lors du basculement.
- Base de données ATP-S de secours synchronisée avec la base de données principale à l'aide d'Autonomous Data Guard.
- Répliques des groupes de volumes, qui garantissent la disponibilité des données en cas de panne d'une région principale.
Comprendre les fichiers liés à la configuration JD Edwards
sqlnet.ora
|
Objectif : stocke la configuration Oracle Wallet utilisée par l'application pour se connecter en toute sécurité à la base de données. Emplacement : serveurs JDE Enterprise/Batch. Débit Remarques : assurez-vous que le chemin de portefeuille pointe vers l'emplacement de portefeuille valide de la base de données de récupération après sinistre. Chemin du fichier : |
tnsnames.ora
|
Objectif : stocke les noms de service réseau, qui agissent comme des alias pour les adresses réseau de base de données. Emplacement : serveurs JDE Enterprise, Batch et Web. Remarques concernant la récupération après sinistre : mettez à jour avec l'adresse réseau (FQDN/IP) correcte de la base de données de récupération après sinistre. Chemin de fichier sur les serveurs Enterprise/Batch : Chemin de fichier sur les serveurs Web : |
jde.ini
|
Objectif : stocke la configuration d'exécution pour l'application JDE, y compris les détails de connexion à la base de données et les paramètres de sécurité. Emplacement : serveurs JDE Enterprise et Batch. Remarques concernant la récupération après sinistre : mettez à jour la section Chemin de fichier : |
jdbj.ini
|
Objectif : contient les paramètres de pilote et de connexion à la base de données JDBj pour les applications JDE. Emplacement : serveurs Web et AIS JDE. Remarques concernant la récupération après sinistre : assurez-vous que le nom de serveur correct est spécifié dans la section Chemin du fichier : |
jas.ini
|
Objectif : stocke la configuration du composant Serveur HTML des clients Web EnterpriseOne. Emplacement : serveurs Web JDE. Remarques concernant la récupération après sinistre : mettez à jour les éléments suivants :
SM_Agent_Home/SCFHA/Target/Managed Instance/config |
rest.ini |
Objectif : contient la configuration du serveur AIS, y compris les chemins d'API REST, les paramètres d'authentification et les liens de serveur JAS. Emplacement : serveurs AIS JDE. Remarques concernant la récupération après sinistre : mettez à jour les éléments suivants :
SM_Agent_Home/SCFHA/Target/Managed Instance/config |
gestion-console.xml |
Objectif : ce fichier XML contient des informations sur les différents serveurs, leurs configurations et les autorisations d'accès utilisateur. Emplacement : Serveur Server Manager Remarques concernant la récupération après sinistre : assurez-vous que le nom d'hôte correct est spécifié dans Chemin du fichier : |
propriétés agent |
Objectif : fichier de configuration contenant les paramètres de l'agent OMA, composant qui interagit avec la console de gestion et gère les serveurs EnterpriseOne. Emplacement : Serveur Server Manager Remarques concernant la récupération après sinistre : vérifiez que le nom de serveur correct est spécifié dans la section Chemin de fichier : |
Mises à jour supplémentaires au niveau du système |
Outre les fichiers de configuration d'application, les fichiers système suivants doivent également être vérifiés et mis à jour lors d'une implémentation de récupération après sinistre :
|
Comprendre les concepts de récupération après sinistre de pile complète
Lors de la configuration et de l'implémentation de FSDR, vous devez comprendre les concepts et terminologies suivants.
-
Groupe de protection de récupération après sinistre
- Définition : un groupe de protection de récupération après sinistre inclut toutes les ressources OCI nécessaires, telles que les instances de calcul, les groupes de volumes, les équilibreurs de charge et les bases de données, qui forment ensemble une pile d'applications complète.
- Avantage : un groupe de protection de récupération après sinistre est traité comme une seule unité pour le basculement, le rétablissement et dans les scénarios de test. Elle garantit que toutes les ressources sont récupérées ensemble, ce qui minimise les temps d'arrêt et les pertes de données.
- Plan de récupération après sinistre
Un plan de reprise après sinistre est un dossier d'exploitation automatisé créé par FSDR afin d'effectuer une récupération après sinistre pour toutes les ressources du groupe principal de protection de reprise après sinistre. Il se compose d'étapes qui définissent la façon dont toutes les ressources d'une région de groupe de protection de récupération après sinistre principale sont transférées vers sa région de groupe de protection de récupération après sinistre secondaire homologue. Voici les différents types de plan de récupération après sinistre :
- Basculement (non planifié) : utilisez un plan de basculement lorsque vous souhaitez effectuer une transition immédiate en activent la pile d'applications dans la région de secours, sans tenter d'arrêter le service dans la région principale. Les plans de basculement sont généralement utilisés pour effectuer des transitions de récupération après sinistre lorsqu'une coupure ou un sinistre touche la région principale.
- Permutation (planifiée) : utilisez un plan de permutation lorsque vous souhaitez effectuer une transition ordonnée, en arrêtant la pile d'applications dans la région principale, puis en l'affichant dans la région de secours. Les plans de permutation sont généralement utilisés à des fins de maintenance planifiée du site, d'application de patches aux logiciels, de test de récupération après sinistre et de validation.
- Analyse de démarrage : une analyse de démarrage génère un plan pour effectuer l'analyse de récupération après sinistre sans interrompre les ressources du groupe de protection de récupération après sinistre principal. Elle crée une réplique de ressources dans le groupe de protection de récupération après sinistre de secours.
- Arrêter l'analyse : ce plan de récupération après sinistre arrête l'analyse de récupération après sinistre en supprimant la réplique des ressources créées par l'analyse de démarrage.
- Instance mobile
- Définition : Instances déployées uniquement dans la région principale.
- Cas d'utilisation : commun dans les topologies de récupération après sinistre à froid, dans lesquelles très peu, ou aucun des composants d'une application ou d'un service, ne doit être prédéployé dans la région de secours en prévision d'une future transition.
- Comportement : lors d'un sinistre, les instances en déplacement sont déplacées du groupe de protection de récupération après sinistre de la région principale vers le groupe de protection de récupération après sinistre de la région de secours.
- Avantage : rentabilité, car les ressources de la région de secours ne sont pas en cours d'exécution en continu.
- Remarques : cette méthode nécessite des temps de récupération plus longs en raison de la nécessité de provisionner et de démarrer des instances dans la région de secours.
- Instance non mobile
- Définition : instances pré-déployées dans les régions principale et de secours.
- Cas d'utilisation : commun dans les topologies de récupération après sinistre active-passive, dans lesquelles tout ou partie des composants d'une application ou d'un service sont prédéployés dans la région de secours de manière à préparer une future transition de récupération après sinistre.
- Comportement : pendant les opérations de récupération après sinistre, ces instances sont démarrées ou arrêtées selon les besoins pour faire passer le service d'une région à l'autre.
- Avantage : cette méthode permet une récupération plus rapide en raison d'une infrastructure préexistante dans la région de secours.
- Considération : cela peut entraîner des coûts plus élevés car l'infrastructure doit être maintenue dans les deux régions.
Conditions requises pour Full Stack Disaster Recovery
Avant de pouvoir poursuivre le processus FSDR, vous devez remplir les prérequis suivants :
- Provisionnez un VCN, des sous-réseaux, des tables de routage, des listes de sécurité et des passerelles réseau dans la région de récupération après sinistre. Pour prendre en charge la fonctionnalité et la connectivité de basculement, assurez-vous que les configurations réseau sont identiques à celles de la région principale.
- Définissez un groupe dynamique pour autoriser les stratégies qui accordent des privilèges d'administrateur aux instances créées dans le cadre de l'environnement de récupération après sinistre.
- Vous devez disposer des droits d'administrateur pour exécuter des scripts sur les instances de calcul. Le module d'extension Exécuter la commande utilise l'utilisateur
ocarun
pour exécuter ces scripts. Assurez-vous que cet utilisateur dispose des autorisations appropriées.- Ouvrez
oracle-cloud-agent-run-command
pour modifier :vi ./101-oracle-cloud-agent-run-command
- Ajoutez les lignes suivantes dans le fichier de configuration :
ocarun ALL=(ALL) NOPASSWD:ALL
- Exécutez ensuite :
vi sudo -cf ./101-oracle-cloud-agent-run-command
- Ajoutez le fichier de configuration à
/etc/sudoers.d
:sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
- Ouvrez
- Activez la fonctionnalité de sauvegarde inter-région pour les groupes de volumes.
- Déployez un équilibreur de charge dans la région secondaire. Dans le cadre de la configuration FSDR, seul l'ensemble de back-ends (instances) sera déplacé de la région principale vers la région de secours. L'équilibreur de charge lui-même doit être créé manuellement sur la région de secours à l'avance.
- Configurez une instance de base de données (homologue) correspondante dans la région de récupération après sinistre pour prendre en charge le basculement des applications.
- Créez un bucket de stockage d'objet pour les journaux de la région principale. Ce bucket stockera les journaux et artefacts de récupération après sinistre propres à l'environnement.
- Créez un bucket de stockage d'objet supplémentaire dans la région de secours. Ce bucket sera utilisé à des fins de réplication ou de journalisation afin de garantir la préparation à la récupération après sinistre dans la région de secours.
- Placez les scripts personnalisés suivants à l'emplacement approprié.
Appliquer des scripts personnalisés
Ces scripts personnalisés sont exécutés au cours du processus FSDR.
update_rest Serveur applicable : AIS |
|
update_tnsnames_jdbj Serveurs applicables : JAS, AIS |
|
update_wallet Serveurs applicables : tous les serveurs JDE (Enterprise, AIS, JAS, Fatclient, intégrations, etc.) |
|
update_ini Serveur applicable : Enterprise |
|
update_tnsnames_sqlnet
Serveurs applicables : Enterprise, déploiement, clients gras |
|
update_agent_properties Serveurs applicables : tous les serveurs gérés par le gestionnaire de serveurs |
|
update_management_console Serveur applicable : Sever Manager |
|