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

À 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 SOAINFRA.
- 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 (par exemple, le référentiel MDS, les schémas SOAINFRA, les JMS, 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 SOA principaux 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/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
NFS VOLADMIN`/export/soa/config`	SOAHOST1, SOAHOST2	`/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`	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
VOLRUNTIME NFS `/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 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/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 les hôtes principal et de secours

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

Les noms physiques des hôtes SOA distants peuvent être résolus dans le DNS, ou vous pouvez inclure les noms et adresses IP physiques 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.

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 SOA 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.

Modifiez le fichier /etc/hosts dans les hôtes SOA principaux sur place pour inclure les hôtes SOA homologues distants qui hébergent 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              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 SOA OCI de secours pour inclure les noms physiques des hôtes SOA distants sur place. N'incluez pas les alias de nom d'hôte virtuel.

Voici un exemple des alias sur les hôtes SOA OCI 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 l'interconnexion des hôtes SOA principaux sur place vers 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 l'interconnexion entre les hôtes SOA OCI secondaires et les hôtes SOA principaux sur place.
Une clé SSH n'est peut-être pas requise.
```
ssh  oracle@host3.myopnnetwork.com
ssh  oracle@host4.myopnnetwork.com
```

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 SOA 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.

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

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.

Copiez le dossier de produits de l'instance principale sur place SOAHOST1 vers l'instance distante SOAHOST1.
Copiez le dossier du répertoire de base des produits à partir du répertoire principal sur place SOAHOST2 et enregistrez-le dans le répertoire distant SOAHOST2. Répétez cette opération pour toutes les autres instances de calcul.
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 SOAHOST1 principal sur place vers SOAHOST1 distant dans Télécharger le code. 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 SOAHOST2 à SOAHOST2 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 SOA pour Oracle Cloud Infrastructure (OCI).

Copiez le dossier de configuration partagée du domaine WebLogic à partir de l'instance principale sur place SOAHOST1 vers l'instance OCI distante SOAHOST1.
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 SOAHOST1 principal sur place 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 principale sur place SOAHOST1 et enregistrez-le dans l'instance OCI distante SOAHOST1
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 SOA. Par conséquent, vous devez effectuer la copie pour chaque serveur - vous devez copier la configuration privée de SOAHOST1 sur place vers SOAHOST1 pour OCI, la configuration privée de SOAHOST2 sur place vers SOAHOST2 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ée à partir du dossier SOAHOST1 principal sur place vers le dossier SOAHOST1 distant.

Copier le dossier d'exécution partagé

Copiez le dossier d'exécution partagé vers les hôtes SOA 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.