Répliquer les artefacts du système de fichiers vers OCI

Les niveaux intermédiaires secondaires doivent avoir une réplique des artefacts utilisés par le domaine du serveur WebLogic dans le domaine principal. Les artefacts peuvent être statiques ou dynamiques, selon la fréquence à laquelle ils sont modifiés. Dans le cadre de la configuration de récupération après sinistre, une réplication initiale des artefacts doit être effectuée. Cette réplique initiale est actualisée pendant le cycle de vie du système.

À propos des artefacts

Déterminez le type d'artefact que vous devez répliquer.

• Les artefacts statiques sont des fichiers et des répertoires qui ne changent pas fréquemment. Il s'agit notamment des suivantes :
  • Répertoire de base Oracle : Il se compose généralement d'un répertoire de base Oracle et d'un répertoire de base Oracle WebLogic Server. Oracle Fusion Middleware vous permet de créer plusieurs serveurs gérés Oracle WebLogic Server à partir d'une seule installation de fichier binaire. Vous pouvez installer des fichiers binaires dans un emplacement unique sur un stockage partagé et réutiliser cette installation par des serveurs situés sur différents noeuds. Pour une disponibilité maximale, Oracle recommande d'utiliser des installations binaires redondantes.
  • Oracle Inventory : orainventory est un dossier qui contient une liste des répertoires de base Oracle existants et qui se trouve dans un dossier séparé du répertoire de base Oracle. Le fichier /etc/oraInst.loc détermine l'emplacement de orainventory.
• Artefacts dynamiques : fichiers qui changent fréquemment. Ces artefacts comprennent :
  • Domain home : répertoires de domaine du serveur d'administration et des serveurs gérés. Dans une topologie EDG, ASERVER_HOME se trouve dans un emplacement partagé, et MSERVER_HOME se trouve dans un emplacement privé et chaque serveur a son propre MSERVER_HOME (bien qu'il puisse également être stocké dans un NFS).
  • Artefacts d'application, tels que les fichiers .ear ou .war.
  • Artefacts de base de données, tels que le référentiel MDS et les schémas d'application.
  • Stocks persistants, tels que les fournisseurs JMS et les journaux de transactions. Oracle recommande de stocker ces artefacts dans la base de données. Il s'agit de l'approche recommandée dans la topologie EDG, particulièrement utile pour les environnements de reprise après sinistre, car ils sont répliqués automatiquement sur le site de secours au moyen d'Oracle Data Guard sous-jacent.
  • Plans de déploiement, utilisés pour la mise à jour des adaptateurs technologiques, tels que les adaptateurs de fichiers et JMS. Ils doivent être enregistrés dans un emplacement accessible à tous les noeuds du cluster dans lequel les artefacts sont déployés.
  • Autres artefacts d'exécution, tels que les fichiers utilisés par les adaptateurs de fichiers, les fichiers transférés par MFT ou d'autres artefacts d'exécution personnalisés.

Tout le contenu qui réside dans la base de données (comme le référentiel MDS, les schémas d'application, les JMS et les TLOG et les données personnalisées) est automatiquement répliqué vers le site secondaire au moyen d'Oracle Data Guard.

Pour répliquer le contenu qui réside dans le système de fichiers (tel que le répertoire de base Oracle et la configuration du domaine WebLogic) dans une topologie de récupération après sinistre, vous pouvez utiliser différentes approches. Les plus courantes sont la réplication au niveau du stockage, la réplique basée sur rsync ou la réplique basée sur DBFS.

Le modèle de reprise après sinistre hybride, décrit ici, se trouve là où l'instance principale se trouve sur place et l'instance secondaire se trouve dans OCI. La réplication au niveau du stockage n'est pas disponible dans le modèle de récupération après sinistre hybride. À la place, rsync est l'approche recommandée pour répliquer les artefacts de la base principale vers la base de secours. Vous pouvez utiliser la réplique basée sur le système de fichiers Oracle Database (DBFS) pour répliquer certains artefacts. Voir les détails dans À propos du système de fichiers Oracle Database dans En savoir plus.

Identifier les dossiers et les artefacts de système de fichiers

Identifiez les volumes et les dossiers NFS utilisés par les hôtes principaux du serveur WebLogic de l'environnement principal et de son contenu.

Les tableaux suivants fournissent un exemple des artefacts du système de fichiers principal utilisés dans cet exemple.

Volume du système de fichiers	Hôte	Dossier de point de montage	Commentaires	Type d'artefact
NFS VOLFMW1 /export/wls/products1	HÔTE DE L'APPLICATION1	/u01/oracle/products	Volume pour les fichiers binaires JDK et FMW.	Statique
NFS VOLFMW2 /export/wls/products2	HÔTE DE L'APPLICATION2	/u01/oracle/products	Volume pour les fichiers binaires JDK et FMW.	Statique
NFS VOLADMIN/export/wls/config	APPHOST1, APPHOST2	/u01/oracle/config	Volume du répertoire du domaine du serveur d'administration et d'autres configurations partagées, telles que les plans de déploiement, les applications et les magasins de clés.	Dynamique
LOCAL* /u02/oracle/config	HÔTE DE L'APPLICATION1	/u02/oracle/config	Volume pour la configuration privée dans APPHOST1	Dynamique
LOCAL* /u02/oracle/config	HÔTE DE L'APPLICATION2	/u02/oracle/config	Volume pour la configuration privée dans APPHOST2	Dynamique
VOLRUNTIME NFS /export/wls/runtime	APPHOST1, APPHOST2	/u01/oracle/runtime	Volume pour le contenu d'exécution partagé, comme les fichiers utilisés par les adaptateurs de fichiers et les autres artefacts d'exécution. Note : Il est recommandé de stocker les messages JMS et TLOGS dans la base de données, à l'aide de magasins persistants JDBC, plutôt que dans ce dossier.	Dynamique

* Les volumes du système de fichiers local peuvent être des montages privés (non partagés) dans NFS au lieu du stockage local.

Le tableau suivant est un exemple des variables EDG pour les emplacements de dossier.

Variables EDG	Valeur
ORACLE_BASE	/u01/oracle/products
ORACLE_HOME	/u01/oracle/products/fmw
JAVA_HOME	/u01/oracle/products/jdk
SHARED_CONFIG_DIR	/u01/oracle/config
APPLICATION_HOME	/u01/oracle/config/applications/mydomain
DEPLOY_PLAN_HOME	/u01/oracle/config/dp
KEYSTORE_HOME	/u01/oracle/config/keystores
ASERVER_HOME	/u01/oracle/config/domains/mydomain
PRIVATE_CONFIG_DIR	/u02/oracle/config
MSERVER_HOME	/u02/oracle/config/domains/mydomain
NM_HOME	/u02/oracle/config/nodemanager
ORACLE_RUNTIME	/u01/oracle/runtime

Vérifier la connectivité entre les hôtes principal et de secours

Les hôtes principaux du serveur WebLogic doivent se connecter aux hôtes du serveur WebLogic de la base de données de secours distante Oracle Cloud Infrastructure (OCI), et inversement,

Les noms physiques des hôtes distants du serveur WebLogic peuvent être résolus dans le DNS, ou vous pouvez inclure les noms physiques et les adresses IP du serveur WebLogic pair distant dans les fichiers /etc/hosts. Autrement dit, ajoutez les noms physiques et leurs adresses IP des hôtes secondaires du serveur WebLogic au fichier /etc/hosts des hôtes principaux du serveur WebLogic. De même, ajoutez les noms physiques et leurs adresses IP des hôtes principaux du serveur WebLogic au fichier /etc/hosts des hôtes secondaires du serveur WebLogic.

Note :

Si le principal n'utilise pas de noms d'hôte virtuel et qu'il utilise les noms d'hôte du noeud physique comme adresses d'écoute pour les serveurs, n'effectuez pas ces étapes. Comme dans ce scénario, les noms d'hôte du noeud physique principal doivent être résolus par les adresses IP des hôtes du serveur WebLogic OCI dans la base de secours. Dans ce scénario, au lieu d'effectuer les étapes suivantes, utilisez les adresses IP des hôtes pour vous connecter avec SSH aux noeuds distants.

1. Modifiez le fichier /etc/hosts dans les hôtes principaux du serveur WebLogic sur place pour inclure le serveur WebLogic pair distant qui héberge les noms physiques et les adresses IP.
   Voici un exemple d'alias sur les hôtes sur place.

   
   #################################
   # ALIASES in on-prem
   #################################
   10.10.10.20   host-vip1.myopnetwork.com    host-vip1          ADMINVHN.example.com   ADMINVHN 
   10.10.10.13   host3.myopnnetwork.com       host3              APPHOST1.example.com    APPHOST1
   10.10.10.14   host4.myopnnetwork.com       host4              APPHOST2.example.com    APPHOST2
   # Front-end name (resolved but primary Load Balancer IP
   10.10.10.100    wlsfrontend.example.com
   # Remote OCI wls hosts physical names (without virtual host name aliases!)
   100.70.10.13    hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com      hydrwls1        
   100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com       hydrwls2

2. Modifiez le fichier /etc/hosts dans les hôtes du serveur WebLogic OCI de secours pour inclure les noms physiques du serveur WebLogic distant sur place. N'incluez pas les alias de nom d'hôte virtuel.
   Voici un exemple d'alias sur les hôtes du serveur WebLogic OCI de secours.

   #################################
   # ALIASES in OCI
   #################################
   100.70.10.20   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrwls-vip    ADMINVHN.example.com    ADMINVHN
   100.70.10.13   hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls1       APPHOST1.example.com    APPHOST1
   100.70.10.14   hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls2       APPHOST2.example.com    APPHOST2
   # Front-end name (resolved by secondary OCI LBR IP)
   1070.70.70    wlsfrontend.example.com
   # Remote on-prem wls hosts physical names (without virtual host name aliases!)
   10.10.10.13   host3.myopnnetwork.com       host3
   10.10.10.14   host4.myopnnetwork.com       host4

3. Utilisez la commande SSH pour vérifier l'interconnexion entre les hôtes principaux du serveur WebLogic sur place et les hôtes secondaires du serveur WebLogic OCI.
   Une clé SSH est requise lors de la connexion aux instances de calcul OCI.

   ssh -i my_private_key [e-mail]
   ssh -i my_private_key [e-mail]

4. Utilisez la commande SSH pour vérifier l'interconnexion entre les hôtes du serveur WebLogic OCI secondaire et les hôtes du serveur WebLogic principal sur place.
   Une clé SSH n'est peut-être pas requise.

   ssh  [e-mail]
   ssh  [e-mail]

Dupliquer la structure de dossier dans les hôtes OCI secondaires

À ce stade, le service FSS est déjà monté sur les instances de calcul du serveur WebLogic pour Oracle Cloud Infrastructure (OCI). Avant de répliquer le contenu, créez la structure de dossiers appropriée pour EDG.

L'exemple suivant montre les commandes permettant de créer la structure de dossiers EDG utilisée par l'environnement EDG de ce document.

1. En tant qu'utilisateur oracle, créez les dossiers dans OCI APPHOST1.

   mkdir -p  /u01/oracle/products/fmw
   mkdir -p  /u01/oracle/products/jdk
   mkdir -p  /u01/oracle/products/oraInventory
   mkdir -p /u02/oracle/config
   mkdir -p /u01/oracle/config/domains/mydomain
   mkdir -p /u01/oracle/config/applications/mydomain
   mkdir -p /u01/oracle/config/dp/mydomain
   mkdir -p /u01/oracle/config/keystores

2. En tant qu'utilisateur oracle, créez les dossiers dans OCI APPHOST2.

   mkdir -p  /u01/oracle/products/fmw
   mkdir -p  /u01/oracle/products/jdk
   mkdir -p  /u01/oracle/products/oraInventory
   mkdir -p /u02/oracle/config

Copiez ORACLE_HOME et JAVA_HOME dans les hôtes secondaires

Copiez ORACLE_HOME et JAVA_HOME des hôtes principaux vers les hôtes secondaires.

ORACLE_HOME et JAVA_HOME se trouvent normalement sous le même dossier de produits, ainsi que oraInventory. Voir Identifier les dossiers et les artefacts de système de fichiers pour les emplacements que vous avez identifiés précédemment.

1. Copiez le dossier de produits de l'APPHOST1 principal sur place vers l'APPHOST1 distant.
2. Copiez le dossier de base des produits à partir de l'APPHOST2 principal sur place et enregistrez-le dans l'APPHOST2 distant. Répétez cette opération pour toutes les autres instances de calcul.
3. Copiez le fichier /etc/oraInst.loc à partir des hôtes principaux et enregistrez-le dans les hôtes secondaires.
   Ce fichier ne contient que l'emplacement de oraInventory et ne change pas au fil du temps. Cette copie est donc une action ponctuelle.

   Dans l'exemple fourni, oraInventory se trouve sous /u01/oracle/products et est copié avec jdk et le répertoire de base Oracle. Si votre oraInventory se trouve à un autre emplacement, assurez-vous de la copier également vers les hôtes secondaires.

   Note :

   Vous pouvez trouver un exemple de script qui utilise rsync pour copier le dossier de produits de l'APPHOST1 principal sur place vers l'APPHOST1 distant dans le code de téléchargement. Répétez cette opération pour copier le répertoire de base des produits vers le reste des instances de calcul secondaires (c'est-à-dire de APPHOST2 à APPHOST2 distant).

Copiez les dossiers de configuration de domaine WebLogic dans les hôtes de secours

Copiez le dossier de configuration partagée du domaine WebLogic et le dossier de configuration privé vers les hôtes du serveur WebLogic pour Oracle Cloud Infrastructure (OCI).

1. Copiez le dossier de configuration partagée du domaine WebLogic à partir de l'instance principale sur place APPHOST1 vers l'instance OCI distante APPHOST1.
   La configuration partagée du domaine WebLogic réside dans l'emplacement conçu par la variable SHARED_CONFIG_DIR et inclut les dossiers de configuration partagés tels que APPLICATION_HOME, DEPLOY_PLAN_HOME, KEYSTORE_HOME et ASERVER_HOME.

   Note :

   Vous pouvez copier le dossier de configuration partagée de l'APPHOST1 principal sur place vers l'APPHOST1 distant. Il s'agit d'un dossier partagé. Il vous suffit donc de le copier sur l'un des hôtes du serveur WebLogic OCI.

   Un exemple de script est disponible dans Télécharger le code.

2. Copiez le dossier de configuration privée du domaine WebLogic de l'application APPHOST1 principale sur place et enregistrez-le dans l'application APPHOST1 OCI distante.
   La configuration privée WebLogic réside à l'emplacement spécifié par la variable PRIVATE_CONFIG_DIR et contient les dossiers MSERVER_HOME et NM_HOME. Ces dossiers ne sont pas partagés, ils sont spécifiques (privés) à chaque hôte de serveur WebLogic. Par conséquent, vous devez effectuer la copie pour chaque serveur - vous devez copier la configuration privée d'APPHOST1 sur place vers APPHOST1 pour OCI, la configuration privée d'APPHOST2 sur place vers APPHOST2 pour OCI, etc.

   Note :

   Dans Télécharger le code, vous pouvez trouver un exemple de script qui utilise rsync pour copier le dossier de configuration privé de l'APPHOST1 principal sur place vers l'APPHOST1 distant.

Copier le dossier d'exécution partagé

Copiez le dossier d'exécution partagé vers les hôtes du serveur WebLogic pour Oracle Cloud Infrastructure (OCI), si nécessaire.

Le dossier d'exécution partagé réside à l'emplacement spécifié par la variable ORACLE_RUNTIME. Voir Identifier les dossiers et les artefacts de système de fichiers pour les emplacements que vous avez identifiés précédemment.

Note :

Il est recommandé de stocker les espaces de stockage persistants JMS et les espaces de stockage TLOGS dans la base de données, à l'aide des espaces de stockage persistants JDBC. Comme ils se trouvent dans la base de données, ils sont répliqués automatiquement sur le système secondaire avec Oracle Data Guard.

• Comme il s'agit d'informations d'exécution, vous n'avez normalement pas besoin de les répliquer pendant la phase de configuration. Toutefois, si vous devez répliquer ce dossier vers les hôtes de secours, vous pouvez copier le contenu selon une approche similaire que vous avez utilisée pour copier le fichier de configuration partagée du domaine WebLogic.