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.



jde-dr-fsdr-oracle.zip

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

JDE s'appuie sur plusieurs fichiers de configuration pour gérer la connectivité entre ses composants et les autres niveaux participants, tels que les bases de données et les services d'authentification. Ces fichiers jouent un rôle essentiel dans la définition des paramètres de connexion, des paramètres d'exécution et du comportement d'intégration. Il est essentiel de bien comprendre ces fichiers et leur contenu lors de la configuration du scénario de récupération après sinistre pour garantir une fonctionnalité d'application transparente.
Voici un récapitulatif des fichiers de configuration clés :

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.
    1. Ouvrez oracle-cloud-agent-run-command pour modifier :
       vi ./101-oracle-cloud-agent-run-command
    2. Ajoutez les lignes suivantes dans le fichier de configuration :
      ocarun ALL=(ALL) 
      NOPASSWD:ALL
    3. Exécutez ensuite :
      vi sudo -cf ./101-oracle-cloud-agent-run-command
    4. Ajoutez le fichier de configuration à /etc/sudoers.d :
      sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
  • 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.