A propos de la configuration de la récupération après sinistre JD Edwards à l'aide d'OCI Full Stack Disaster Recovery

Architecture JD Edwards

Cette illustration présente l'architecture de déploiement de l'application JD Edwards, avec des régions principale et secondaire.

description de l'illustration jdr-dr-fsdr.png,

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 :

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 : Oracle_ClientHome/network/admin

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 : Oracle_ClientHome/network/admin

Chemin de fichier sur les serveurs Web : SM_Agent_Home/SCFHA/Target/Managed Instance/config

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 DB SYSTEM SETTINGS avec le nom de serveur correct pour l'environnement de récupération après sinistre.

Chemin de fichier : JDE_HOME/e920/ini

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 JDBj-BOOTSTRAP DATA SOURCE.

Chemin du fichier : SM_Agent_Home/SCFHA/Target/Managed Instance/config

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 :

Section FORMSERVICE avec l'hôte et le port AIS corrects.
Section Security avec le paramètre OracleAccessSSOSignOffURL approprié si SSO est activé.

Chemin du fichier : 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 :

Section BASIC CONFIG avec l'hôte et le port JAS corrects.
Section Security avec la mise à jour IDCSSSOSignOffURL si SSO est activé.

Chemin du fichier : 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 management-console.xml

Chemin du fichier : SM_Console_Home/SCFMC/targets/home

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 agent.properties.

Chemin de fichier : SM_Console_Home/ SCFMC/config

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 :

Hôtes Linux et fichiers fstab : assurez-vous que des adresses IP et des noms de domaine qualifiés complets valides sont définis.
Fichier d'hôtes Windows : mettez à jour avec les mappages IP et FQDN actuels, le cas échéant.
Fichiers de portefeuille WebLogic : doivent être mis à jour pour refléter le portefeuille de base de données propre à la récupération après sinistre afin de garantir la connectivité si la base de données est autonome.

La maintenance et la mise à jour correctes de ces fichiers de configuration garantissent que JDE continue de fonctionner correctement dans un environnement de récupération après sinistre, ce qui réduit les temps d'arrêt et maintient une connectivité d'application sécurisée et cohérente.

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.

update_rest

Serveur applicable : AIS

#Define the old and new file names
old_file1="rest_dr.ini"
new_file1="rest.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"
 # Copy the new second file back to the original name, preserving attributes
 cp -p "$new_file1" "$old_file1"
 echo "Copied $new_file1 back to $old_file1 (preserving attributes)"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_tnsnames_jdbj

Serveurs applicables : JAS, AIS

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="jdbj_dr.ini"
old_file3="jas_dr.ini"
new_file1="tnsnames.ora"
new_file2="jdbj.ini"
new_file3="jas.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"

 # Rename the third file
 mv "$old_file3" "$new_file3"
 echo "Renamed $old_file3 to $new_file3"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_wallet

Serveurs applicables : tous les serveurs JDE (Enterprise, AIS, JAS, Fatclient, intégrations, etc.)

# Define old and new wallet folder names
old_wallet="Wallet_jdeorcl_hyderabad"
new_wallet="Wallet_jdeorcl"

# Check if the old wallet directory exists
if [ -d "$old_wallet" ]; then
  # Remove any existing new_wallet directory to avoid conflict
  if [ -d "$new_wallet" ]; then
    echo "Removing existing $new_wallet directory..."
    rm -rf "$new_wallet"
  fi

  # Rename the old wallet to the new name
  mv "$old_wallet" "$new_wallet"
  echo "Renamed $old_wallet to $new_wallet"

  # Copy the new wallet back to the old wallet directory for reuse
  cp -r "$new_wallet" "$old_wallet"
  echo "Copied $new_wallet back to $old_wallet for reuse"

else
  echo "Directory $old_wallet does not exist. Aborting operation."
fi

update_ini

Serveur applicable : Enterprise

# Define the old and new file names
old_file2="JDE_DR.INI"
old_file3="jdbj_dr.ini"
new_file2="JDE.INI"
new_file3="jdbj.ini"

# Check if the old files exist in the folder
if [ -e "$old_file2" ] && [ -e "$old_file3" ] ; then
    # Rename the second file
    mv "$old_file2" "$new_file2"
    echo "Renamed $old_file2 to $new_file2"

    # Rename the third file
    mv "$old_file3" "$new_file3"
    echo "Renamed $old_file3 to $new_file3"
else
    echo "Old files do not exist in the folder."
fi

update_tnsnames_sqlnet

Serveurs applicables : Enterprise, déploiement, clients gras

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="sqlnet_dr.ora"
new_file1="tnsnames.ora"
new_file2="sqlnet.ora"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"
else
 echo "One or both of the old files do not exist in the folder."
fi

update_agent_properties

Serveurs applicables : tous les serveurs gérés par le gestionnaire de serveurs

# Define the old and new file names
old_file1="agent.properties"
new_file1="agent_dr.properties"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi

update_management_console

Serveur applicable : Sever Manager

# Define the old and new file names
old_file1="management-console_dr.xml"
new_file1="management-console.xml"

# Check if the old files exist in the folder
if [ -e "$old_file1" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi