Réplication des artefacts de système de fichiers vers OCI

À propos des artefacts

Déterminez le type d'artefact à répliquer.

Artefacts statiques : fichiers et répertoires qui ne changent pas fréquemment. Sont incluses :
- Oracle Home : 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 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 des noeuds différents. Pour une disponibilité maximale, Oracle recommande d'utiliser des installations binaires redondantes.
- Oracle Inventory : orainventory est un dossier contenant la liste des répertoires de base Oracle existants. Il 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 fréquemment modifiés. Ces artefacts incluent :
- Répertoire d'origine du domaine : répertoires de domaine du serveur d'administration et des serveurs gérés. Dans une topologie EDG, l'élément ASERVER_HOME se trouve dans un emplacement partagé et l'élément MSERVER_HOME se trouve dans un emplacement privé et chaque serveur possède son propre élément 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.
- Emplacements de stockage 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 récupération après sinistre, car ils sont automatiquement répliqués vers le site de secours via Oracle Data Guard sous-jacent.
- Plans de déploiement, utilisés pour la mise à jour des adaptateurs de technologie, tels que les adaptateurs de fichiers et JMS. Ils doivent être enregistrés dans un emplacement accessible à tous les noeuds du cluster vers lesquels 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 résidant dans la base de données (tel que le référentiel MDS, les schémas d'application, JMS et TLOG et les données personnalisées) est automatiquement répliqué vers le site secondaire via Oracle Data Guard.

Pour répliquer le contenu résidant dans le système de fichiers (comme le répertoire de base Oracle et la configuration de domaine WebLogic) dans une topologie de récupération après sinistre, vous pouvez utiliser différentes approches. Les plus courants 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 récupération après sinistre hybride décrit ici est l'emplacement où le principal se trouve sur site et le secondaire 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. A la place, rsync est l'approche recommandée pour répliquer les artefacts de la base de données principale vers la base de données de secours. Vous pouvez utiliser une réplique basée sur Oracle Database File System (DBFS) pour répliquer certains artefacts. Pour en savoir plus, reportez-vous aux détails dans A propos d'Oracle Database File System.

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

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

Les tableaux suivants fournissent un exemple des artefacts de système de fichiers principaux 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`	APPHOST 1	`/u01/oracle/products`	Volume pour les fichiers binaires JDK et FMW.	Statique
NFS : VOLFMW2 `/export/wls/products2`	APPHOST 2	`/u01/oracle/products`	Volume pour les fichiers binaires JDK et FMW.	Statique
VOLADMIN NFS`/export/wls/config`	APPHOST1, APPHOST2	`/u01/oracle/config`	Volume pour le répertoire de domaine du serveur d'administration et d'autres configurations partagées, telles que les plans de déploiement, les applications et les fichiers de clés.	Dynamique
LOCAL* `/u02/oracle/config`	APPHOST 1	`/u02/oracle/config`	Volume pour configuration privée dans APPHOST1	Dynamique
LOCAL* `/u02/oracle/config`	APPHOST 2	`/u02/oracle/config`	Volume pour configuration privée dans APPHOST2	Dynamique
NFS VOLRUNTIME `/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 d'autres artefacts d'exécution. Remarque : Il est recommandé de stocker les messages `JMS` et `TLOGS` dans la base de données, à l'aide des espaces de stockage 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 d'un 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 l'hôte principal et l'hôte de secours

Les hôtes du serveur WebLogic principal doivent se connecter aux hôtes du serveur Oracle Cloud Infrastructure (OCI) WebLogic de secours distant, et inversement.

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

Remarque :

Si le noeud principal n'utilise pas de noms d'hôte virtuel et qu'il utilise les noms d'hôte de noeud physique comme adresses d'écoute pour les serveurs, n'effectuez pas ces étapes. Dans ce cas, les noms d'hôte du noeud physique principal doivent être résolus par les adresses IP des hôtes du serveur OCI WebLogic en veille. 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.

Modifiez le fichier /etc/hosts dans les hôtes principaux du serveur WebLogic sur site pour inclure les noms physiques et les adresses IP des hôtes du pair distant serveur WebLogic.

Voici un exemple d'alias sur les hôtes sur site.


#################################
# 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

Modifiez le fichier /etc/hosts dans les hôtes OCI WebLogic Server de secours pour inclure les noms physiques des hôtes WebLogic Server sur site distants. N'incluez pas les alias de nom d'hôte virtuel.

Voici un exemple d'alias sur les hôtes de secours du serveur WebLogic OCI.

#################################
# 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

Utilisez la commande SSH pour vérifier la connectivité croisée entre les hôtes WebLogic Server sur site principaux et les hôtes WebLogic Server OCI secondaires.
Une clé SSH est requise lors de la connexion aux instances de calcul OCI.
```
ssh -i my_private_key oracle@hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com
```
Utilisez la commande SSH pour vérifier la connectivité croisée entre les hôtes du serveur WebLogic OCI secondaire et les hôtes du serveur WebLogic sur site principal.
Une clé SSH n'est peut-être pas requise.
```
ssh  oracle@host3.myopnnetwork.com
ssh  oracle@host4.myopnnetwork.com
```

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

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

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

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

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` sur les hôtes secondaires

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

ORACLE_HOME et JAVA_HOME figurent normalement dans le même dossier de produits, avec oraInventory. Reportez-vous à Identification des dossiers et des artefacts de système de fichiers pour connaître les emplacements que vous avez identifiés précédemment.

Copiez le dossier des produits de l'instance APPHOST1 principale sur site vers l'instance APPHOST1 distante.
Copiez le dossier de base des produits à partir de l'instance APPHOST2 principale sur site et enregistrez-le dans l'instance APPHOST2 distante. Répétez l'opération pour toutes les autres instances de calcul.
Copiez le fichier /etc/oraInst.loc à partir des hôtes principaux et enregistrez-le sur les hôtes secondaires.
Ce fichier contient uniquement 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 oraInventory se trouve à un autre emplacement, veillez à le copier également sur les hôtes secondaires.

Remarque :

Vous trouverez un exemple de script qui utilise rsync pour copier le dossier products de l'instance principale sur site APPHOST1 vers l'instance distante APPHOST1 dans Download Code. Répétez la même 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 sur les hôtes de secours.

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

Copiez le dossier de configuration partagée du domaine WebLogic à partir de l'instance APPHOST1 principale sur site vers l'instance OCI APPHOST1 distante.
La configuration partagée du domaine WebLogic réside à 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.

Remarque :

Vous pouvez copier le dossier de configuration partagée à partir de l'instance APPHOST1 principale sur site vers l'instance APPHOST1 distante. Il s'agit d'un dossier partagé. Il vous suffit donc de le copier vers l'un des hôtes du serveur WebLogic OCI.

Un exemple de script est disponible dans Télécharger le code.
Copiez le dossier de configuration privée du domaine WebLogic de l'instance APPHOST1 principale sur site et enregistrez-le dans l'instance OCI APPHOST1 distante
La configuration privée WebLogic réside à l'emplacement indiqué 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 WebLogic Server. Par conséquent, vous devez effectuer la copie pour chaque serveur. Vous devez copier la configuration privée de APPHOST1 sur site vers OCI APPHOST1, la configuration privée de APPHOST2 sur site vers OCI APPHOST2, etc.

Remarque :

Dans Télécharger le code, vous pouvez trouver un exemple de script qui utilise rsync pour copier le dossier de configuration privée de la base de données principale sur site APPHOST1 vers la base de données distante APPHOST1.

Copier le dossier d'exécution partagé

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

Le dossier d'exécution partagé réside à l'emplacement indiqué par la variable ORACLE_RUNTIME. Reportez-vous à Identification des dossiers et des artefacts de système de fichiers pour connaître les emplacements que vous avez identifiés précédemment.