À propos de la configuration de la récupération après sinistre JD Edwards à l'aide de la récupération après sinistre de pile complète pour OCI

Architecture JD Edwards

Cette illustration décrit l'architecture de déploiement de l'application JD Edwards, comportant à la fois 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é au sein d'un réseau en nuage virtuel (VCN) segmenté en trois sous-réseaux dédiés, qui sont séparés par la fonctionnalité des 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 permet aux utilisateurs finaux d'accéder aux services Web JDE.
Niveau d'application
Le niveau application contient les composants de base de l'application, notamment le serveur d'entreprise, le serveur Web et le serveur AIS (Application Interface Services).
Niveau de gestion
Le niveau de gestion comprend des outils et des services pour la gestion et l'administration JDE, tels que le serveur de déploiement et le serveur de console Server Manager.
Niveau de base de données
Dans la couche de base de données, la base de données JDE est déployée sur la base de données Autonomous Transaction Processing - Partagée (ATP-S). Les serveurs d'applications se connectent à la base de données à l'aide de points d'extrémité. Oracle Autonomous Data Guard est activé, créant une base de données de secours dans la région secondaire et assurant 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 par blocs utilisés par les instances de calcul sont protégés par une réplication inter-région de groupe de volumes, 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 de la region.It principale contenant :

Structure de VCN répliquée correspondant à la disposition réseau de la région principale.
Un réplica d'équilibreur de charge pour assurer la continuité de l'accès lors du basculement.
Base de données ATP-S de secours qui est synchronisée avec la base principale à l'aide d'Autonomous Data Guard.
Répliques de groupes de volumes, qui garantissent la disponibilité des données en cas de défaillance 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 reprise après sinistre afin d'assurer une fonctionnalité d'application transparente.

Voici un sommaire des fichiers de configuration clés :

sqlnet.ora

Objectif : Stocke la configuration d'Oracle Wallet utilisée par l'application pour se connecter en toute sécurité à la base de données.

Emplacement : Serveurs JDE Enterprise/Batch. Dt

Considération : Assurez-vous que le chemin d'accès au portefeuille pointe vers l'emplacement de portefeuille valide de la base de données DR.

Chemin du fichier : Oracle_ClientHome/network/admin

tnsnames.ora

Objet : Stocke les noms de service réseau, qui servent d'alias pour les adresses réseau de base de données.

Emplacement : Serveurs JDE Enterprise, Batch et Web.

Considération de récupération après sinistre : Effectuez une mise à jour avec l'adresse réseau (FQDN/IP) correcte de la base de données de récupération après sinistre.

Chemin d'accès aux fichiers sur les serveurs Enterprise/Batch : Oracle_ClientHome/network/admin

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

jde.ini

Fonction : Stocke la configuration d'exécution de 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.

Considération relative au service de récupération après sinistre : Mettez à jour la section DB SYSTEM SETTINGS avec le nom de serveur approprié pour l'environnement de récupération après sinistre.

Chemin du fichier : JDE_HOME/e920/ini

jdbj.ini

Fonction : Contient les paramètres du pilote JDBj et les paramètres de connexion à la base de données pour les applications JDE.

Emplacement : Serveurs Web et AIS JDE.

Considération relative au service de 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

Objet : Stocke la configuration du composant HTML Server des clients Web EnterpriseOne.

Emplacement : Serveurs Web JDE.

Considération en matière de récupération après sinistre : Mettez à jour les éléments suivants :

Section FORMSERVICE avec l'hôte et le port AIS appropriés.
Section Security avec la section OracleAccessSSOSignOffURL appropriée si l'authentification unique est activée.

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

rest.ini

Objet : Contient la configuration du serveur AIS, notamment les chemins d'API REST, les paramètres d'authentification et les liens de serveur JAS.

Emplacement : Serveurs AIS JDE.

Considération en matière de récupération après sinistre : Mettez à jour les éléments suivants :

Section BASIC CONFIG avec l'hôte et le port JAS appropriés.
Section Security avec la valeur IDCSSSOSignOffURL mise à jour si l'authentification unique est activée.

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

gestion-console.xml

Fonction : Ce fichier XML contient des informations sur les différents serveurs, leurs configurations et les autorisations d'accès des utilisateurs.

Emplacement : Serveur du gestionnaire de serveurs

Considération relative au service de 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 de l'agent.

Fonction : Fichier de configuration contenant les paramètres de l'agent de gestion, composant qui interagit avec la console de gestion et gère les serveurs EnterpriseOne

Emplacement : Serveur du gestionnaire de serveurs

Considération DR : Assurez-vous que le nom de serveur correct est spécifié dans la section agent.properties.

Chemin du fichier : SM_Console_Home/ SCFMC/config

Mises à jour supplémentaires au niveau du système

En plus des fichiers de configuration d'application, les fichiers système suivants doivent également être examinés et mis à jour lors d'une implémentation DR :

Hôtes Linux et fichiers fstab : Assurez-vous que les adresses IP et les noms de domaine complets valides sont définis.
Fichier d'hôtes Windows : Effectuez une mise à jour avec les mappages IP et nom de domaine complet courants, si nécessaire.
Fichiers de portefeuille WebLogic : Doit ê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 appropriées de ces fichiers de configuration garantissent que JDE continue de fonctionner correctement dans un environnement de reprise après sinistre, réduisant ainsi les temps d'arrêt et assurant une connectivité d'application cohérente et sécurisée.

Comprendre les concepts relatifs à la récupération après sinistre de pile complète

Lors de la configuration et de l'implémentation du service FSDR, vous devez comprendre les concepts et terminologies suivants.

Groupe de protection RS
- Définition : Un groupe de protection RS comprend 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 RS est traité comme une unité unique pour le basculement, la restauration automatique et les scénarios de test. Il garantit que toutes les ressources sont récupérées ensemble, ce qui réduit les temps d'arrêt et les pertes de données.
Plan RS
Un plan RS est un dossier d'exploitation automatisé créé par FSDR pour effectuer la récupération après sinistre de toutes les ressources du groupe de protection RS principal. Il se compose d'étapes qui définissent comment toutes les ressources d'une région de groupe de protection RS principal sont transférées vers sa région de groupe de protection RS secondaire pair. Voici les différents types de plan de reprise après sinistre :
- Basculement (non planifié) : Utilisez un plan de basculement lorsque vous voulez effectuer une transition immédiate en activant 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 servent généralement à effectuer des transitions de récupération après sinistre lorsqu'une panne ou un sinistre touche la région principale.
- Permutation (planifiée) : Utilisez un plan de permutation lorsque vous voulez effectuer une transition ordonnée en arrêtant la pile d'applications dans la région principale, puis en l'activant 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 correctifs logiciels, et de test et de validation pour la récupération après sinistre.
- Démarrer le forage : Un forage de début génère un plan pour effectuer le forage RS sans interrompre les ressources principales du groupe de protection RS. Il crée une réplique des ressources dans le groupe de protection RS de secours.
- Arrêter le forage : Ce plan RS arrête le forage RS en supprimant la réplique des ressources créées par le forage de début.
Instance mobile
- Définition : Instances déployées uniquement dans la région principale.
- Cas d'utilisation : Commun dans les topologies RS froides, où très peu ou aucun des composants d'une application ou d'un service doivent être prédéployés dans la région de secours en vue d'une future transition RS.
- Comportement : Lors d'un événement de sinistre, le déplacement des instances est déplacé du groupe de protection RS de la région principale vers le groupe de protection RS de la région de secours.
- Avantage : Rentabilité, car les ressources de la région de secours ne s'exécutent pas en continu.
- Considération : 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 RS active-passive, où tout ou partie des composants d'une application ou d'un service sont prédéployés dans la région de secours en vue d'une future transition RS.
- Comportement : Lors des opérations de récupération après sinistre, ces instances sont démarrées ou arrêtées selon les besoins pour assurer la transition du service entre les régions.
- 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 un coût plus élevé, car l'infrastructure doit être tenue à jour dans les deux régions.

Préalables pour la récupération après sinistre de pile complète

Avant de poursuivre le processus FSDR, vous devez remplir les préalables suivants :

Provisionnez un VCN, des sous-réseaux, des tables de routage, des listes de sécurité et des passerelles de réseau dans la région RS. Pour prendre en charge la fonctionnalité et la connectivité de basculement, assurez-vous que les configurations réseau reflètent celles de la région principale.
Définissez un groupe dynamique pour autoriser les politiques qui accordent des privilèges d'administrateur aux instances créées dans le cadre de l'environnement RS.
Vous devez disposer des droits d'administrateur pour exécuter des scripts sur les instances de calcul. Le plugiciel d'exécution de 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/
```
Activer 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 le jeu dorsal (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 dans la région de secours à l'avance.
Configurez une instance de base de données (pair) correspondante dans la région DR pour prendre en charge le basculement d'application.
Créez un seau de stockage d'objets pour les journaux dans la région principale. Ce seau stockera les journaux RS et les artefacts propres à l'environnement.
Créez un seau de stockage d'objets supplémentaire dans la région de secours. Ce seau sera utilisé à des fins de réplication ou de journalisation pour garantir la disponibilité de 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, Integrations, 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 : Entreprise

# 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, Deployment, Fatclients

#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 : Gestionnaire de serveurs

# 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