Réplication des artefacts du 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. Exemples :
- 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 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 : le dossier orainventory contient 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 qui changent fréquemment. Ces artefacts sont les suivants :
- Répertoire de base du domaine : 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 dispose de 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 SOAINFRA.
- Les 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 sur le site de secours via Oracle Data Guard sous-jacent.
- Plans de déploiement, utilisés pour mettre à jour les 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 sur 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 (comme le référentiel MDS, les schémas SOAINFRA, 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 SOA 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 points de montage	Commentaires	Type d'artefact
NFS : VOLFMW1 `/export/soa/products1`	SOAHOST1	`/u01/oracle/products`	Volume pour les fichiers binaires JDK et FMW.	Statique
NFS : VOLFMW2 `/export/soa/products2`	SOAHOST2	`/u01/oracle/products`	Volume pour les fichiers binaires JDK et FMW.	Statique
VOLADMIN NFS`/export/soa/config`	SOAHOST1, SOAHOST2	`/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 d'accès.	Dynamique
LOCAL* `/u02/oracle/config`	SOAHOST1	`/u02/oracle/config`	Volume pour la configuration privée dans SOAHOST1	Dynamique
LOCAL* `/u02/oracle/config`	SOAHOST2	`/u02/oracle/config`	Volume pour la configuration privée dans SOAHOST2	Dynamique
NFS VOLRUNTIME `/export/soa/runtime`	SOAHOST1, SOAHOST2	`/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 emplacements 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 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/mysoadomain`
`DEPLOY_PLAN_HOME`	`/u01/oracle/config/dp`
`KEYSTORE_HOME`	`/u01/oracle/config/keystores`
`ASERVER_HOME`	`/u01/oracle/config/domains/mysoadomain`
`PRIVATE_CONFIG_DIR`	`/u02/oracle/config`
`MSERVER_HOME`	`/u02/oracle/config/domains/mysoadomain`
`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 SOA principaux doivent se connecter aux hôtes SOA (OCI) Oracle Cloud Infrastructure de secours distants, et inversement.

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

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 OCI SOA 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 SOA sur site principaux pour inclure les noms physiques et les adresses IP des hôtes SOA homologues distants.

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              SOAHOST1.example.com    SOAHOST1
10.10.10.14   host4.myopnnetwork.com       host4              SOAHOST2.example.com    SOAHOST2
# Front-end name (resolved but primary Load Balancer IP
10.10.10.100    mysoa.example.com
# Remote OCI soa hosts physical names (without virtual host name aliases!)
100.70.10.13    hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa1        
100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2

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

Voici un exemple d'alias sur les hôtes OCI SOA de secours.

#################################
# ALIASES in OCI
#################################
100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrsoa-vip    ADMINVHN.example.com    ADMINVHN
100.70.10.13   hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa1       SOAHOST1.example.com    SOAHOST1
100.70.10.14   hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa2       SOAHOST2.example.com    SOAHOST2
# Front-end name (resolved by secondary OCI LBR IP)
1070.70.70    mysoa.example.com
# Remote on-prem soa 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 SOA sur site principaux et les hôtes SOA OCI secondaires.
Une clé SSH est requise lors de la connexion aux instances de calcul OCI.
```
ssh -i my_private_key oracle@hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com
```
Utilisez la commande SSH pour vérifier la connectivité croisée entre les hôtes OCI SOA secondaires et les hôtes SOA principaux sur site.
Une clé SSH peut ne pas être 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 SOA (OCI) Oracle Cloud Infrastructure. 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 SOAHOST1.

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/mysoadomain
mkdir -p /u01/oracle/config/applications/mysoadomain
mkdir -p /u01/oracle/config/dp/mysoadomain
mkdir -p /u01/oracle/config/keystores

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

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

Copier `ORACLE_HOME` et `JAVA_HOME` vers 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 de produits à partir de SOAHOST1 principal sur site vers SOAHOST1 distant.
Copiez le dossier de base des produits à partir du serveur SOAHOST2 principal sur site et enregistrez-le dans le serveur SOAHOST2 distant. 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 simplement 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 le fichier 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 SOAHOST1 vers l'instance distante SOAHOST1 dans Télécharger le 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 SOAHOST2 à SOAHOST2 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 SOA Oracle Cloud Infrastructure (OCI).

Copiez le dossier de configuration partagée du domaine WebLogic de l'instance principale sur site SOAHOST1 vers l'instance OCI SOAHOST1 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 de SOAHOST1 principal sur site vers SOAHOST1 distant. Il s'agit d'un dossier partagé. Il vous suffit donc de le copier vers l'un des hôtes SOA 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 SOAHOST1 principale sur site et enregistrez-le dans l'instance OCI SOAHOST1 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 SOA. Par conséquent, vous devez effectuer la copie pour chaque serveur. Vous devez copier la configuration privée de SOAHOST1 sur site vers OCI SOAHOST1, la configuration privée de SOAHOST2 sur site vers OCI SOAHOST2, 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 SOAHOST1 vers la base de données distante SOAHOST1.

Copier le dossier Exécution partagée

Copiez le dossier d'exécution partagé vers les hôtes SOA Oracle Cloud Infrastructure (OCI), 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.