1. Configurer une solution de récupération après sinistre hybride pour Oracle WebLogic Server
  2. Préparer le niveau Web sur OCI

Préparer le niveau Web sur OCI

Provisionnez et configurez votre site secondaire sur Oracle Cloud Infrastructure (OCI) pour qu'il soit cohérent avec votre site sur place principal.

Note :

Vous pouvez trouver du code Terraform pour créer les ressources décrites dans cette section (équilibreur de charge OCI, certificat SSL, jeux dorsaux et dorsaux, politiques d'acheminement, modules d'écoute et jeux de règles) dans Télécharger le code.

(Facultatif) Préparez les hôtes Oracle HTTP Server

Créez et configurez les instances de calcul Oracle HTTP Server dans Oracle Cloud Infrastructure.

Note :

La création et la configuration d'Oracle HTTP Server sont facultatives. Vous pouvez configurer le niveau Web sur OCI uniquement à l'aide de l'équilibreur de charge OCI (sans utiliser Oracle HTTP Server).

Provisionner les hôtes Oracle HTTP Server

Créez une instance de calcul sur le sous-réseau de niveau Web Oracle Cloud Infrastructure (OCI) pour chaque hôte Oracle HTTP Server principal sur place. Les instances de calcul doivent utiliser l'image de système d'exploitation et la forme de calcul qui sont les plus similaires à l'image et à la forme utilisées par les hôtes Oracle HTTP Server sur place.

Chaque Oracle HTTP Server exécuté dans OCI doit avoir un contrat de licence et de soutien valide en plus du contrat de licence et de soutien utilisé pour couvrir Oracle HTTP Server exécuté sur place. Vous pouvez utiliser des images Oracle WebLogic Server pour OCI pour créer des instances de calcul pour Oracle HTTP Server sur Oracle Cloud. Les instances de calcul créées avec ces images incluent le droit d'exécuter Oracle HTTP Server et sont facturées par OCPU/heure pour le droit d'exécuter le logiciel WebLogic lorsqu'elles sont en cours d'exécution. Lors de la création des instances de calcul avec Oracle WebLogic Server pour OCI, vous pouvez utiliser la console d'instance de calcul ou le marché des applications. Ces images sont disponibles pour les systèmes d'exploitation Oracle Linux 7.9 et Oracle Linux 8.5.

Cet exemple utilise deux instances de calcul dans un seul domaine de disponibilité dans le compartiment, comme indiqué dans le tableau.

Le nom Compartiment Domaine de disponibilité Image Forme VCN Sous-réseau
hydrohs1 HyDRCompmt AD1 Image UCM Oracle WebLogic Enterprise Edition (Oracle Linux 7.9) VM.Standard2.2 hydrvcn webTierSubnet
hydrohs2 HyDRCompmt AD1 Image UCM Oracle WebLogic Enterprise Edition (Oracle Linux 7.9) VM.Standard2.2 hydrvcn webTierSubnet

Pour provisionner les instances de calcul à l'aide de la console d'instance de calcul :

  1. Se connecter à la console OCI pour votre location.
  2. Sélectionnez la région appropriée.
  3. Cliquez sur le menu de navigation, sélectionnez Calcul. Cliquez sur Instances, puis sur Créer une instance.
  4. Entrez les noms de l'instance de calcul et du compartiment.
  5. Sous Positionnement, sélectionnez le domaine de disponibilité dans lequel créer l'instance. Si la région OCI comporte plusieurs domaines de disponibilité, vous pouvez placer les instances de calcul WebLogic dans des domaines de disponibilité différents.
  6. Sous Image et forme, cliquez sur Modifier l'image et effectuez les opérations suivantes :
    1. Dans la liste déroulante Source de l'image, sélectionnez Images Oracle, puis Image UCM Oracle WebLogic Server Enterprise Edition dans la liste des images Oracle WebLogic Server pour OCI.
    2. Pour l'image sélectionnée, cliquez sur la flèche à droite, puis sélectionnez la version de création d'image pour les images payantes.
      • Oracle Linux 7.9 (étiqueté release-ol7.9-build-timestamp)
      • Oracle Linux 8.5 (étiquette : release-ol8.5-build-timestamp)
    3. Vérifiez les conditions générales. Cochez la case Conditions d'utilisation d'Oracle et cliquez sur Sélectionner une image.
  7. Sous Image et forme, cliquez sur Modifier la forme. Sélectionnez le type d'instance et sélectionnez la forme la plus similaire aux hôtes principaux.
    Voir Images pour Oracle WebLogic Server pour OCI pour obtenir la liste des formes prises en charge.
  8. Sélectionnez le VCN, le sous-réseau (sous-réseau de niveau Web) et le domaine de disponibilité de votre environnement.
    Pour spécifier le type de capacité et le domaine d'erreur, cliquez sur Afficher les options avancées.
  9. Configurez le réseau de l'instance. Pour spécifier des paramètres de réseau avancés, cliquez sur Afficher les options avancées.
  10. Sous Ajouter des clés SSH, générer une clé, charger votre clé publique ou coller les clés.
  11. Sous Volume de démarrage, spécifiez les options de taille et de chiffrement pour le volume de démarrage de l'instance.
  12. Cliquez sur Afficher les options avancées pour configurer des paramètres avancés.
  13. Cliquez sur Créer.
  14. Répétez les étapes pour créer une autre instance de calcul.

Préparer les utilisateurs et les groupes du système d'exploitation

Les mêmes utilisateur et groupe que ceux utilisés par le logiciel Oracle principal sur place sont nécessaires dans les instances de calcul secondaires.

Les images Oracle WebLogic Server for Oracle Cloud Infrastructure ont déjà un utilisateur et un groupe oracle. Toutefois, ces valeurs (nom d'utilisateur, nom de groupe, uid et gid) peuvent ne pas correspondre aux valeurs que vous avez dans votre instance principale et vous devrez configurer les hôtes secondaires pour qu'ils correspondent aux valeurs de l'utilisateur et du groupe oracle principal. Les exemples suivants montrent comment configurer les hôtes secondaires de ce niveau pour qu'ils correspondent aux valeurs de l'utilisateur et du groupe oracle principal.

Chaque groupe et utilisateur dans les instances de calcul OCI doit avoir le même ID sur chaque noeud et le même que dans l'instance principale.
  1. Identifiez l'utilisateur, le groupe et les ID de l'utilisateur oracle dans les hôtes principaux en vous connectant à un hôte sur place avec l'utilisateur oracle, puis utilisez la commande id.
    [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)

[oracle@host3.myopnetwork.com ~]$ more /etc/passwd | grep oracle
oracle:x:1001:1002::/home/oracle:/bin/bash

    Le tableau suivant présente des exemples d'utilisateur et de groupes pour un environnement sur place type.

    Utilisateur ou groupe Le nom ID Description
    Utilisateur oracle 1001 Propriétaire du logiciel Oracle
    Groupes oinstall 1002 Groupe principal de l'utilisateur oracle
    dba 1001 Groupe secondaire de l'utilisateur oracle
  2. Identifiez les utilisateurs, les groupes et les ID qui existent dans les hôtes secondaires à l'aide de SSH pour accéder à l'instance récemment créée en tant qu'utilisateur opc. Connectez-vous à des hôtes secondaires avec l'utilisateur opc, puis sudo avec l'utilisateur oracle et exécutez la commande id.
    [opc@hydrwls1 ~]$ sudo su - oracle
[oracle@hydrwls1 ~]$ id
uid=1001(oracle) gid=1001(oracle) groups=1001(oracle),1002(docker) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

    Le tableau suivant présente l'utilisateur et le groupe oracle qui existent déjà dans les instances de calcul secondaires.

    Utilisateur ou groupe Le nom ID Description
    Utilisateur oracle 1001 Propriétaire du logiciel Oracle
    Groupes oracle 1001 Groupe principal de l'utilisateur oracle
    docker 1002 Groupe secondaire de l'utilisateur oracle
  3. Les scénarios et solutions possibles sont les suivants :
    • Les utilisateurs et les groupes dans le secondaire sont des noms et des ID différents de ceux dans le primaire.

      Solution : Créez les utilisateurs et les groupes dans le secondaire tels qu'ils existent dans le primaire.

    • Les utilisateurs et les groupes secondaires portent les mêmes noms, mais des ID différents de ceux de l'instance principale.

      Solution : Modifiez les ID du secondaire pour qu'ils correspondent aux ID du principal.

    • Les utilisateurs et les groupes dans le secondaire sont des noms différents de ceux dans le principal, mais les mêmes ID.

      Solution : Modifiez les noms de l'utilisateur et du groupe dans le secondaire.

    • Il y a des conflits : certains ID de l'utilisateur principal ou des groupes sont utilisés par d'autres utilisateurs ou groupes dans le secondaire.

      Solution : Corrigez le conflit en modifiant l'ID de l'utilisateur ou du groupe en conflit dans le secondaire, puis créez l'utilisateur ou les groupes dans le secondaire pour qu'ils correspondent à ceux qui se trouvent dans le principal.

    Le tableau suivant récapitule les commandes que vous pouvez utiliser pour résoudre les conflits :

    Action Commande (exécuter en tant que racine)
    Pour créer un nouveau groupe groupadd group_name -g group_id

    Par exemple :

    groupadd oinstall -g 1002 groupadd dba -g 1001
    Pour créer un nouvel utilisateur useradd -u user_id user_name -g principal_group -G other groups

    Par exemple :

    useradd -u 1001 oracleuser -g oinstall -G dba
    Pour modifier le groupe principal de l'utilisateur usermod -g new_primary_groupname user_name
    Pour ajouter un utilisateur à un groupe usermod -a -G secondary_groupname user_name
    Pour modifier l'ID d'un utilisateur

    usermod -u new_id user_name

    find / -user old_uid -exec chown -h user_name {} \;

    Par exemple, l'ID de l'utilisateur oracle passe de 1001 à 501 :

    usermod -u 501 oracle

    find / -user 1001 -exec chown -h oracle {} \;
    Pour modifier l'ID d'un groupe

    groupmod -g new_id group_name

    find / -group old_id -exec chgrp -h group_name {} \;

    Par exemple, l'ID du groupe oracle passe de 1001 à 501 :

    groupmod -g 501 oracle

    find / -user 1001 -exec chgrp -h oracle {} \;

    Note :

    Oracle recommande d'effectuer les modifications dans les instances de calcul OCI secondaires. Ne modifiez pas les valeurs d'ID dans l'ID principal.

    Voici un exemple où les ID des groupes utilisés dans les hôtes principaux sont déjà utilisés par d'autres groupes dans les hôtes secondaires. Pour résoudre ce conflit, les actions suivantes sont nécessaires :

    1. Le groupe docker dans le secondaire utilise l'ID 1002, qui est en conflit avec l'ID du groupe principal oinstall.
      Pour résoudre le conflit, remplacez l'ID du groupe docker dans les hôtes secondaires par un ID différent et non conflictuel. Par exemple, sélectionnez 1005 comme nouvel ID et vérifiez qu'il n'est pas utilisé en confirmant qu'il n'apparaît pas dans le fichier /etc/group.
      [opc@hydrwls1 ~]$ sudo -s  
[root@hydrwls1 ~]$ more /etc/group | grep 1005
      Lorsque vous confirmez que le code n'est pas utilisé, remplacez-le par le nouveau.
      [opc@hydrwls1 ~]$ sudo -s 
[root@hydrwls1 ~]$ groupmod -g 1005 docker
[root@hydrwls1 ~]$ find / -group 1002 -exec chgrp -h docker {} \;
    2. Le groupe oracle dans le secondaire utilise l'ID 1001, qui est en conflit avec l'ID du groupe principal dba.
      Pour résoudre le conflit, remplacez l'ID du groupe oracle dans les hôtes secondaires par un ID différent et non conflictuel. Par exemple, sélectionnez 1006 comme nouvel ID et vérifiez qu'il n'est pas utilisé en confirmant qu'il n'apparaît pas dans le fichier /etc/group.
      [opc@hydrwls1 ~]$ sudo -s 
[root@hydrwls1 ~]$ more /etc/group | grep 1006
      Lorsque vous confirmez que le code n'est pas utilisé, remplacez-le par le nouveau.
      [opc@hydrwls1 ~]$ sudo -s 
[root@hydrwls1 ~]$ groupmod -g 1006 oracle
[root@hydrwls1 ~]$ find / -group 1001 -exec chgrp -h oracle {} \;
    3. Créez les groupes d'utilisateurs oracle oinstall et dba dans les hôtes secondaires avec les mêmes ID que les ID principaux. 
      [opc@hydrwls1 ~]$ sudo -s
[root@hydrwls1 ~]$ groupadd oinstall -g 1002
[root@hydrwls1 ~]$ groupadd dba -g 1001
    4. L'utilisateur oracle a le même nom et le même ID dans la base principale et la base de secours, de sorte qu'aucune modification n'est nécessaire.
      Toutefois, vous devez remplacer le groupe principal de l'utilisateur par oinstall dans les hôtes secondaires.
      [root@hydrwls1 ~]$ usermod -g oinstall oracle
      Puis, ajoutez l'utilisateur au groupe dba. 
      [root@hydrwls1 ~]$ usermod -a -G dba oracle
    5. Vérifiez que la sortie de la commande id pour l'utilisateur oracle dans les hôtes secondaires correspond à la sortie principale pour les groupes principal et secondaire.
      Sortie dans la base principale :
      [oracle@host3.myopnetwork.com ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba)
      Sortie dans le secondaire (le secondaire peut avoir des groupes supplémentaires) :
      oracle@hydrwls1 ~]$ id
uid=1001(oracle) gid=1002(oinstall) groups=1002(oinstall),1001(dba),1005(docker)
        …
    6. (Recommandé) Effectuez un redémarrage de l'hôte après ces modifications.
  4. (Facultatif, mais recommandé) Activez l'accès SSH à l'utilisateur oracle.
    Elle est utile dans cette topologie de récupération après sinistre car elle permet à l'utilisateur oracle d'avoir une connexion directe pour exécuter les commandes utilisées pour copier le contenu du système de fichiers du système principal vers le système secondaire.
    1. Copiez la clé publique que vous utilisez pour vous connecter aux instances de calcul dans un fichier texte. Vous l'utiliserez plus tard dans cette procédure.
    2. Connectez-vous à l'instance et sudo à l'utilisateur racine.
    3. Créez un répertoire .ssh dans le répertoire de base du nouvel utilisateur.
      mkdir -p /home/oracle/.ssh
    4. Copiez la clé publique SSH que vous utilisez pour vous connecter au service de calcul dans le fichier.
      /home/oracle/.ssh/authorized_keys
    5. Remplacez le responsable et le groupe du répertoire /home/oracle/.ssh par l'utilisateur oracle.
      chown -R oracle:oinstall /home/oracle/.ssh
    6. Vérifiez la connexion en vous connectant avec SSH à l'aide de l'utilisateur oracle et de votre clé privée.
    7. Définissez les autorisations du fichier authorized_keys sur 600.
      chmod 600 /home/oracle/.ssh/authorized_keys

Préparer les exigences du système d'exploitation

Les fichiers binaires Oracle HTTP Server seront copiés des hôtes Oracle HTTP Server principaux vers les hôtes Oracle HTTP Server secondaires. Par conséquent, il n'est pas nécessaire d'exécuter runinstaller dans les hôtes secondaires. Comme les images Oracle WebLogic Server for Oracle Cloud Infrastructure sont préparées pour le logiciel WebLogic, vous n'avez pas besoin d'ajouter manuellement des ensembles pour WebLogic. Toutefois, ces hôtes Oracle HTTP Server exécuteront le produit Oracle HTTP Server. Assurez-vous que les hôtes secondaires répondent aux exigences d'Oracle HTTP Server.
  1. Assurez-vous que votre environnement répond aux exigences d'installation minimales pour les produits installés sur les hôtes principaux. Vérifiez le document correspondant dans Exigences et spécifications du système Oracle Fusion Middleware.
  2. Vérifiez les ensembles de système requis pour votre version et votre système d'exploitation.
  3. Installez les ensembles système manquants avec yum.

    Cet exemple utilise Oracle HTTP Server 12.2.1.4 et Oracle Linux 7. Certains ensembles requis sont déjà installés dans les instances de calcul de niveau intermédiaire Oracle Cloud Infrastructure (OCI). Dans cet exemple, les éléments suivants étaient manquants et devaient être installés à l'aide de yum : 

    yum install compat-libcap1.x86_64
yum install compat-libstdc++-33.x86_64
yum install compat-libstdc++-33.i686 
yum install gcc-c++.x86_64
yum install libaio-devel.x86_64
yum install libstdc++.i686    
yum install libstdc++-devel.x86_64
yum install dejavu-serif-fonts
yum install numactl.x86_64
yum install numactl-devel.x86_64
yum install motif.x86_64
yum install motif-devel.x86_64
yum install redhat-lsb.x86_64
yum install xorg-x11-utils.x86_64
  4. Configurez les limites des fichiers et des processus dans le fichier /etc/security/limits.conf. Vérifiez les limites de vos hôtes Oracle HTTP Server sur place et définissez les valeurs dans les instances de calcul Oracle HTTP Server OCI en conséquence.

Préparer les alias de nom d'hôte pour Oracle HTTP Server

Configurez les mêmes noms d'hôte virtuel que ceux utilisés par les hôtes Oracle HTTP Server dans l'environnement principal en tant qu'alias dans les instances de calcul Oracle HTTP Server pour Oracle Cloud Infrastructure (OCI) secondaires, mais pointez vers les adresses IP des hôtes secondaires.

Cela peut être mis en œuvre de 2 façons :

  • Ajoutez les noms d'hôte en tant qu'alias aux fichiers /etc/hosts des instances de calcul Oracle WebLogic Server pour OCI.
  • Utilisez une vue DNS privée dans le VCN OCI secondaire.
Utiliser les fichiers /etc/hosts
Les noms d'hôte virtuel utilisés en tant qu'alias dans les serveurs principaux sont ajoutés aux fichiers /etc/hosts des hôtes secondaires, pointant vers les adresses IP des hôtes secondaires. Ce mode est valide dans tous les scénarios lorsque le serveur DNS est le même dans les sites sur place principal et sur les sites Oracle Cloud Infrastructure secondaires (OCI), et lorsque des serveurs DNS séparés sont utilisés dans les sites principal et secondaire. Les entrées du fichier /etc/hosts ont priorité sur la résolution DNS, car il s'agit de la priorité définie prête à l'emploi dans les "hôtes" de directive du fichier /etc/nsswitch.conf.

Toutefois, cette méthode nécessite que vous ajoutiez manuellement les entrées à tous les hôtes Oracle HTTP Server :

  1. Modifiez le fichier /etc/oci-hostname.conf de chaque instance de calcul Oracle HTTP Server et réglez la propriété PRESERVE_HOSTINFO=3 pour conserver les entrées /etc/hosts lors du redémarrage de l'instance.
  2. Utilisez la commande hostname --fqdn pour identifier les noms d'hôte complets des instances de calcul OCI.
  3. Ajoutez les entrées suivantes au fichier /etc/hosts des instances de calcul Oracle HTTP Server OCI :
    #################################
# ALIASES for WLS DR
#################################
# Aliases of the Oracle HTTP Server hosts
ohshost1_compute_instance_IP  ohshost1_fqdn  ohshost1_hostname    ALIASES_OF_WEBHOST1
ohshost2_compute_instance_IP  ohshost2_fqdn  ohshost2_hostname    ALIASES_OF_WEBHOST2
# The aliases for WebLogic
                                Server are added too
virtual_IP_for_admin          virtualIP_fqdn  virtualIP_hostname    ALIASES_OF_ADMINVHN
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname     ALIASES_OF_APPHOST1
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname     ALIASES_OF_APPHOST2

    Note :

    En plus d'ajouter les noms virtuels des hôtes Oracle HTTP Server en tant qu'alias, les noms virtuels des hôtes Oracle WebLogic Server sont ajoutés, pointant vers les adresses IP secondaires de l'hôte du serveur WebLogic. Comme Oracle HTTP Server communique avec les hôtes du serveur WebLogic à l'aide de leurs noms d'hôte virtuel.
    The following is an example of the /etc/hosts file in the secondary Oracle HTTP Server compute instance:
    #################################
# ALIASES for WLS DR - SECONDARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.60.10.11 hydrohs1.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs1    WEBHOST1.example.com WEBHOST1
100.60.10.12 hydrohs2.webTiersubnet.hydrvcn.oraclevcn.com    hydrohs2    WEBHOST2.example.com WEBHOST2
# The aliases of the WLS hosts
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
    Voici un exemple du fichier /etc/hosts existant des hôtes Oracle HTTP Server principaux :
    #################################
# ALIASES for WLS DR - PRIMARY
#################################
# The aliases of the Oracle HTTP Server hosts
100.10.10.11 host1.myopnetwork.com    host1    WEBHOST1.example.com WEBHOST1
100.10.10.12 host2.myopnetwork.com    host2    WEBHOST2.example.com WEBHOST2
# The aliases of the WebLogic
                                Server hosts
10.10.10.20    host-vip1.myopnetwork.com         host-vip1       ADMINVHN.example.com   ADMINVHN
10.10.10.13    host3.myopnetwork.com             host3           APPHOST1.example.com   APPHOST1
10.10.10.14    host4.myopnetwork.com             host4           APPHOST2.example.com   APPHOST2
Utiliser le système de noms de domaine (DNS)
Les noms d'hôte virtuel utilisés par les hôtes Oracle HTTP Server principaux sont ajoutés au résolveur DNS utilisé par le VCN des hôtes Oracle HTTP Server secondaires, pointant vers les adresses IP des hôtes Oracle HTTP Server secondaires. Ce mode est valide lorsque des serveurs DNS distincts sont utilisés dans les systèmes sur place principal et secondaire sur Oracle Cloud Infrastructure (OCI). Sinon, cela peut provoquer des conflits dans la résolution des noms. Le serveur de chaque site doit résoudre ces noms avec ses propres adresses IP.
L'avantage de cette méthode est que vous pouvez ajouter toutes les entrées à une vue DNS privée, au lieu de les ajouter aux fichiers /etc/hosts de tous les hôtes.

Ajoutez les entrées des noms d'hôte virtuel Oracle HTTP Server à la vue privée créée dans OCI à l'étape Préparer le niveau intermédiaire sur OCI :

  1. Dans la console OCI, allez à la région secondaire et localisez la vue privée :
    1. Cliquez sur Réseau, Gestion DNS, Vues privées.
      Par exemple, HYBRID_DR_VIRTUAL_HOSTNAMES
    2. Dans la vue privée, cliquez sur le nom de zone que vous avez créé pour ajouter les hôtes virtuels.
      Dans cet exemple : example.com.
    3. Ajoutez les noms des hôtes virtuels Oracle HTTP Server à cette zone, mais résolus avec les adresses IP secondaires des hôtes Oracle HTTP Server.

      Il vous suffit de fournir le nom non-fqdn dans le menu de la console OCI pour ajouter l'enregistrement. Le domaine DNS de la zone est automatiquement ajouté à l'enregistrement.

    4. Cliquez sur Publier les modifications.
  2. Validez la résolution des hôtes SECONDARY, en exécutant ping et nslookup des noms d'hôte virtuel ajoutés.
    Ils doivent être résolus avec les PI SECONDAIRES équivalentes.

Ouvrir les ports requis dans les pare-feu de l'hôte OCI

Chaque instance de calcul dispose d'un service de pare-feu local. Pour des raisons de sécurité, la configuration par défaut consiste à rejeter les connexions pour tous les ports, à l'exception du minimum requis (ssh, dhcp). Vous devez ouvrir les ports utilisés par Oracle HTTP Server.
  1. Vérifier le statut et les règles du service de pare-feu :
    bash-4.2# firewall-cmd --state
running
bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
    Cette sortie signifie qu'il n'y a pas de ports ouverts autres que 22.
  2. En tant qu'utilisateur racine, utilisez les commandes firewall-cmd pour ouvrir les ports utilisés en tant que ports d'écoute par Oracle HTTP Server dans chaque instance de calcul Oracle HTTP Server.
    Par exemple :
    firewall-cmd --permanent --add-port=7001/tcp 
firewall-cmd --permanent --add-port=8890/tcp 
service firewalld reload
  3. Vérifier le statut et les règles du service de pare-feu :
    bash-4.2# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens3
  sources:
  services: dhcpv6-client ssh
  ports: 7001/tcp 8890/tcp 8888/tcp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Créer les variables d'environnement d'utilisateur oracle pour Oracle HTTP Server

Il est courant d'avoir des variables d'environnement liées à Oracle HTTP Server dans le profil de l'utilisateur oracle dans les hôtes Oracle HTTP Server. Par exemple, ORACLE_HOME, JDK_HOME, PATH, WEB_DOMAIN_HOME, etc.
  1. Vérifiez les fichiers de profil de l'utilisateur oracle dans les hôtes Oracle HTTP Server principaux.
  2. Dans secondaire, ajoutez les mêmes variables d'environnement liées à Oracle HTTP Server aux fichiers de profil de l'utilisateur oracle (.bashrc ou .bash_profile).

    Notez que le fichier .bashrc de l'utilisateur oracle dans les hôtes Oracle HTTP Server peut déjà contenir des variables définies (MIDDLEWARE_HOME, WLS_HOME, etc.), mais elles seront probablement destinées aux dossiers de votre environnement et ne seront pas valides pour vous. Assurez-vous de les supprimer ou de les modifier en conséquence dans vos dossiers d'environnement.

Répliquer le produit et la configuration Oracle HTTP Server à partir de l'instance principale

Puisque les instances de calcul OCI Oracle HTTP Server secondaires sont créées en tant qu'hôtes Oracle HTTP Server principaux (le même système d'exploitation, les mêmes ID utilisateur, les mêmes alias de nom d'hôte, etc.), vous pouvez utiliser rsync pour copier les fichiers binaires et la configuration Oracle HTTP Server à partir des noeuds Oracle HTTP Server principaux.

Vous pouvez également télécharger le logiciel Oracle HTTP Server, l'installer et le configurer à partir de zéro dans les instances de calcul Oracle HTTP Server pour OCI. Cette approche n'entre pas dans le champ d'application du présent document. Toutefois, vous devez utiliser cette approche lorsque les instances de calcul OCI pour Oracle HTTP Server ont un système d'exploitation différent de celui des hôtes Oracle HTTP Server principaux.

Les fichiers binaires et les fichiers de configuration d'Oracle HTTP Server résident normalement dans le stockage privé. Dans OCI, vous pouvez utiliser le volume par blocs dont dispose l'instance de calcul par défaut. Vous pouvez également créer un volume par blocs pour chaque service de calcul Oracle HTTP Server (comme décrit dans Préparer les volumes par blocs OCI) et monter chacun d'eux dans les instances de calcul Oracle HTTP Server (comme décrit dans Monter les volumes par blocs OCI).

Cet exemple utilise le volume par blocs par défaut des instances de calcul Oracle HTTP Server sans créer de volumes par blocs supplémentaires.

  1. Identifiez les dossiers des fichiers binaires et de la configuration d'Oracle HTTP Server dans les noeuds principaux d'Oracle HTTP Server.
    Par exemple :
  2. Créez les mêmes dossiers dans les instances de calcul Oracle HTTP Server OCI. Vous devez utiliser le même chemin que celui utilisé dans l'instance principale.
    1. Accédez par SSH aux instances de calcul du système d'exploitation et sudo à l'utilisateur root.
    2. Créez les dossiers et définissez oracle comme responsable.
      Par exemple :
      bash-4.2# mkdir -p /u02/oracle/products/ohs_12214
bash-4.2# mkdir -p /u02/oracle/config/ohsdomain_12214
bash-4.2# chown -R oracle:oinstall /u02
    3. Répétez pour chaque instance de calcul OCI Oracle HTTP Server.
  3. Utilisez rsync pour copier le dossier products de l'instance principale sur place WEBHOST1 vers l'instance distante WEBHOST1. Répétez l'étape pour copier le dossier de produits de WEBHOST2 vers WEBHOST2 distant. Répétez également cette étape pour toutes les autres instances de calcul Oracle HTTP Server.

    Note :

    Il existe un exemple de script que vous pouvez utiliser pour copier le dossier des produits Oracle HTTP Server du répertoire principal sur place WEBHOST1 vers le répertoire distant WEBHOST1.

    Allez à Télécharger le code pour télécharger le script.

  4. Utilisez rsync pour copier le dossier de configuration Oracle HTTP Server de l'instance principale sur place WEBHOST1 vers l'instance distante WEBHOST1. Répétez l'étape pour copier le dossier de configuration de WEBHOST2 vers WEBHOST2 distant. Répétez également cette étape pour toutes les autres instances de calcul Oracle HTTP Server.

    Note :

    Il existe un exemple de script que vous pouvez utiliser pour copier le dossier de configuration Oracle HTTP Server du répertoire principal sur place WEBHOST1 vers le répertoire distant WEBHOST1.

    Allez à Télécharger le code pour télécharger le script.

  5. Copiez le fichier /etc/oraInst.loc à partir des hôtes Oracle HTTP Server 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.
  6. Si le dossier oraInventory se trouve sous le dossier Produits, il est copié avec le répertoire de base Oracle pour Oracle HTTP Server. Si votre dossier oraInventory se trouve à un autre emplacement, assurez-vous de le copier également vers les hôtes secondaires.

La configuration et les fichiers binaires d'Oracle HTTP Server ne changent pas fréquemment pour les heures supplémentaires. Après cette réplication initiale, vous pouvez répéter la même réplication pendant le cycle de vie. Vous pouvez également tenir à jour manuellement la configuration d'Oracle HTTP Server dans le serveur principal et le serveur secondaire en mettant en oeuvre les modifications de configuration d'Oracle HTTP Server dans les deux sites.

Préparer l'équilibreur de charge OCI

Créez et configurez l'équilibreur de charge Oracle Cloud Infrastructure sur le nuage.

Note :

Vous pouvez trouver du code Terraform pour créer les ressources décrites dans cette section (équilibreur de charge OCI, certificat SSL, jeux dorsaux et dorsaux, politiques d'acheminement, modules d'écoute et jeux de règles) dans Télécharger le code.

Provisionner l'équilibreur de charge OCI

Pour être cohérent avec le site sur place principal, provisionnez un équilibreur de charge sur votre site secondaire sur Oracle Cloud Infrastructure (OCI) comme point d'entrée du système.

  1. Connectez-vous à la console OCI.
  2. Sélectionnez la région et le compartiment appropriés.
  3. Naviguez jusqu'à Réseau, puis Équilibreurs de charge. Cliquez sur Créer un équilibreur de charge.
  4. Sélectionnez le type Équilibreur de charge.
  5. Indiquez un nom pour l'équilibreur de charge.
    Par exemple : hyDRlbr.
  6. Sélectionnez le type de visibilité (publique ou privée) et la bande passante qui correspondent à vos besoins.
    • Si votre système est accessible à partir de clients externes par Internet, sélectionnez une visibilité publique. L'équilibreur de charge OCI utilisera une adresse IP publique.
    • Si votre système est accessible à partir de clients en interne uniquement, vous pouvez choisir une visibilité privée pour provisionner l'équilibreur de charge avec une adresse IP privée uniquement.
  7. Sélectionnez le VCN et le sous-réseau appropriés.
    Par exemple, hydrvcn et webTierSubnet.
  8. N'ajoutez aucun élément dorsal à ce stade.
  9. Laisser le module d'écoute par défaut avec les valeurs par défaut
  10. Cliquez sur Soumettre.
Enregistrez l'adresse IP de l'équilibreur de charge OCI (par exemple, 100.100.100.10).

Charger les certificats

Chargez les certificats utilisés par l'équilibreur de charge principal.

  1. Dans la console, cliquez sur Équilibreur de charge, sur Certificats, puis sur Ajouter un certificat.
  2. Chargez le certificat SSL public et la clé privée du certificat utilisé par l'équilibreur de charge principal. Chargez les certificats d'autorité de certification (autorité de certification), s'ils sont utilisés.
  3. Entrez le nom du certificat, puis cliquez sur Ajouter un certificat.
    Le nouveau certificat apparaît dans la liste des certificats pour l'équilibreur de charge.
  4. Si vous utilisez plusieurs certificats pour accéder au système principal, répétez ces étapes pour charger tous les certificats.

Créer les jeux dorsaux

Un jeu dorsal est une entité logique qui contient une liste de serveurs dorsaux exécutant les mêmes applications. Lorsque vous définissez un jeu dorsal, vous devez spécifier une politique d'équilibrage de charge et un test de vérification de l'état. Vous pouvez ensuite ajouter la liste des serveurs dorsaux.

La configuration des jeux dorsaux dépend de l'utilisation ou non d'Oracle HTTP Server devant les hôtes du serveur WebLogic.

Si vous utilisez Oracle HTTP Server, l'équilibreur de charge Oracle Cloud Infrastructure (OCI) envoie les demandes aux serveurs HTTPS. Créez un jeu dorsal pour chaque port exposé par les serveurs HTTPS. Par exemple, créez un jeu dorsal pour le module d'écoute Oracle HTTP Server qui donne accès aux applications, et un autre jeu dorsal pour le module d'écoute Oracle HTTP Server qui donne accès à chaque console d'administration d'Oracle WebLogic Server.

Si vous n'utilisez pas Oracle HTTP Server, l'équilibreur de charge OCI envoie les demandes aux serveurs WebLogic directement. Créez un jeu dorsal pour chaque grappe Oracle WebLogic Server et un autre jeu dorsal pour le serveur d'administration.

  1. Connectez-vous à la console OCI.
  2. Sélectionnez la région et le compartiment appropriés.
  3. Dans le menu de navigation, cliquez sur Réseau, puis sur équilibreurs de charge.
  4. Cliquez sur l'équilibreur de charge auquel vous voulez ajouter un serveur dorsal.
  5. Cliquez sur Jeux dorsaux dans le menu Ressources, puis cliquez sur Créer un jeu dorsal.
  6. Entrez les informations suivantes dans la boîte de dialogue Créer un jeu dorsal :
    1. Nom : Spécifiez un nom pour le jeu dorsal.
      Le nom de jeu dorsal doit inclure uniquement des caractères alphanumériques, des tirets et des traits de soulignement.
    2. Politique de répartition du trafic : Sélectionnez Service en cascade pondéré.
    3. Persistance de session : Sélectionnez Activer la persistance de témoin de l'équilibreur de charge.
    4. Nom du témoin : Entrez un nom pour le témoin utilisé pour activer la persistance de session.
    5. Attributs : Sélectionnez Sécurisé.
    6. Vérification de l'état : Sélectionnez TCP pour vérifier le port ou HTTP pour vérifier le chemin de l'URL (URI) et le code de réponse attendu.
      Voici des exemples HTTP pour la vérification d'état :
      • OHS_Admin_backendset : Chemin de l'URL /console, code de statut 302
      • OHS_HTTP_backendset:
        • Chemin d'URL /, code de statut 200 (ou 404, selon la configuration d'Oracle HTTP Server)
        • Chemin de l'URL /app1, code de statut 200
  7. Cliquez sur Créer.

Si vous avez des grappes de serveur WebLogic supplémentaires, créez un jeu dorsal pour chaque grappe de la même manière.

Voici un exemple de jeux dorsaux lorsque vous utilisez Oracle HTTPS Server avec Oracle WebLogic Server.

Composant Nom du jeu dorsal Politique de répartition du trafic Persistance de session Nom du témoin (exemple) Attribut : sécurisé Bilan de santé
Administration de serveur OHS_Admin_backendset Circuit circulaire pondéré Activer la persistance de témoin de l'équilibreur de charge X-Oracle-LBR-ADMIN-Backendset Non vérifié TCP ou HTTP
Grappes WebLogic OHS_HTTP_backendset Circuit circulaire pondéré Activer la persistance de témoin de l'équilibreur de charge X-Oracle-LBR-OHS-HTTP-Backendset Sélectionné TCP ou HTTP

Voici un exemple de jeux dorsaux lorsque vous n'utilisez pas Oracle HTTP Server.

Composant Nom du jeu dorsal Politique de répartition du trafic Persistance de session Nom du témoin (exemple) Attribut : sécurisé Bilan de santé
Administration de serveur Admin_backendset Circuit circulaire pondéré Activer la persistance de témoin de l'équilibreur de charge X-Oracle-LBR-ADMIN-Backendset Non vérifié TCP ou HTTP
Grappe WebLogic 1 WLS_Cluster1_backendset Circuit circulaire pondéré Activer la persistance de témoin de l'équilibreur de charge X-Oracle-LBR-WLSCluster1-Backendset Sélectionné TCP ou HTTP
Grappe WebLogic 2 WLS_Cluster2_backendset Circuit circulaire pondéré Activer la persistance de témoin de l'équilibreur de charge X-Oracle-LBR-WLSCluster2-Backendset Sélectionné TCP ou HTTP

Si vous avez des grappes WebLogic supplémentaires, créez un jeu dorsal pour chaque grappe de la même manière.

Définir les serveurs dorsaux pour chaque jeu dorsal

Définissez les serveurs dorsaux pour chaque jeu dorsal dans l'équilibreur de charge Oracle Cloud Infrastructure (OCI).

Si vous utilisez Oracle HTTP Server, ajoutez les noeuds Oracle HTTP Server et les ports appropriés en tant que serveurs dorsaux dans chaque jeu dorsal.

Si vous n'utilisez pas Oracle HTTP Server, ajoutez les noeuds Oracle WebLogic Server et les ports appropriés en tant que serveurs dorsaux dans chaque jeu dorsal.

  1. Dans la console, sélectionnez un jeu dorsal. Cliquez sur Serveurs dorsaux, puis cliquez sur Ajouter des serveurs dorsaux.
  2. Entrez l'adresse IP et le port du serveur dorsal.
Le tableau présente les jeux dorsaux créés dans l'exemple de ce document lors de l'utilisation d'Oracle HTTP Server :
Nom du jeu dorsal Serveurs dorsaux
OHS_Admin_backendset Instances de calcul :
  • hydrohs1, le port Oracle HTTP Server pour le module d'écoute des consoles (par exemple, 7001)
  • hydrohs2, le port Oracle HTTP Server pour le module d'écoute des consoles (par exemple, 7001)
OHS_HTTP_backendset Instances de calcul :
  • hydrohs1, le port Oracle HTTP Server pour le module d'écoute HTTP (par exemple, 8890)
  • hydrohs2, le port Oracle HTTP Server pour le module d'écoute HTTP (par exemple, 8890)

Le tableau présente les jeux dorsaux créés dans l'exemple de ce document lorsqu'ils N'utilisent PAS Oracle HTTP Server :

Nom du jeu dorsal Serveurs dorsaux
Admin_backendset Adresse IP :
  • Adresse IP virtuelle du serveur d'administration créée précédemment, port du serveur d'administration (7001)
WLSCluster1_backendset Instances de calcul :
  • hydrwls1, port du serveur 1 de la grappe WLS 1 (8001)
  • hydrwls2, port du serveur 1 de la grappe WLS 1 (8001)
WLSCluster2_backendset Instances de calcul :
  • hydrwls1, port du serveur 1 de la grappe WLS 2 (9001)
  • hydrwls2, port du serveur 2 de la grappe WLS 2 (9001)

Définir les politiques d'acheminement et configurer les règles

Les politiques d'acheminement sont utilisées pour transmettre les demandes entrantes au jeu dorsal approprié. Par exemple, une demande à /console est envoyée au jeu dorsal d'administration et une demande à /app1 est envoyée au jeu dorsal de la grappe où app1 est en cours d'exécution.

Si vous utilisez Oracle HTTP Server, vous définissez normalement les routes (telles que /app1, /app2, /console, etc.) dans la configuration d'Oracle HTTP Server. Dans ce cas, vous n'avez pas besoin de définir les politiques et règles d'acheminement dans l'équilibreur de charge Oracle Cloud Infrastructure (OCI).

Si vous n'utilisez pas Oracle HTTP Server, vous devez définir les politiques et règles d'acheminement dans l'équilibreur de charge OCI pour transmettre les demandes au jeu dorsal approprié.

  1. Dans la console Oracle Cloud Infrastructure, cliquez sur l'équilibreur de charge.
  2. Cliquez sur Politiques d'acheminement, puis sur Créer des politiques d'acheminement pour définir les politiques.
    Les politiques d'acheminement seront ajoutées aux modules d'écoute de l'équilibreur de charge plus tard.
  3. Entrez un nom pour la politique d'acheminement (jeu de règles).
    Par exemple, Admin_Rules.
  4. Pour créer des règles dans la politique de routage, entrez un nom pour la règle.
    Par exemple, Admin_routerule.
  5. Définissez les conditions de règle pour acheminer les demandes vers différents jeux dorsaux. Sélectionnez Si une correspondance existe, puis Type de condition : Chemin, sélectionnez Opérateur : Commence par et entrez une chaîne d'URL.
    Par exemple, Si une correspondance, un chemin, commence par, /console.
  6. Sélectionnez le jeu dorsal dans le menu pour configurer l'action.
    Par exemple, OHS_Admin_backendset.
Le tableau présente les politiques et règles de routage dans l'équilibreur de charge Oracle Cloud Infrastructure créé selon l'exemple de ce document lorsque Oracle HTTP Server n'est pas utilisé.
Composant Nom de la politique d'acheminement Règle Conditions : Si un chemin de correspondance commence par Action : Acheminer vers un jeu dorsal
Consoles de serveur d'administration Admin_Rules Admin_routerule

/console

/em

 Admin_backendset
Application 1 Application_Rules WLSCluster1_routerule

/app1

 WLSCluster1_backendset
Application 2 Application_Rules WLSCluster2_routerule

/app1

 WLSCluster2_backendset

Vous pouvez créer autant de politiques, de règles et de conditions d'acheminement que nécessaire pour votre environnement.

Créer les processus d'écoute

Créez les processus d'écoute pour chaque combinaison de nom frontal et de port utilisée pour accéder au système. Vous devez utiliser les mêmes noms d'hôte (noms frontaux virtuels) et ports que ceux utilisés par l'équilibreur de charge principal.

  1. Ajoutez le nom d'hôte frontal virtuel en tant que nom d'hôte dans l'équilibreur de charge d'Oracle Cloud Infrastructure.
  2. Créez les modules d'écoute.

Le tableau suivant présente un sommaire des modules d'écoute créés dans l'exemple de ce document, ainsi que le protocole, le port, les jeux dorsaux, la politique d'acheminement, le nom d'hôte et l'utilisation SSL qui leur sont associés. C'est comme un exemple de référence. Si votre système utilise des noms d'hôte, des ports ou des protocoles frontaux supplémentaires dans le système Oracle WebLogic Server principal, vous devez créer les modules d'écoute et les noms d'hôte correspondants en fonction de vos besoins. Par exemple, si vous utilisez une autre interface frontale pour accéder à la console Oracle WebLogic Server et à la console Oracle Enterprise Manager.

Module d'écoute Protocole Port Jeu dorsal Politique d'acheminement HostName Utiliser SSL
Admin_listener HTTP 7,001

OHS_Admin_backendset (si Oracle HTTP Server est utilisé)

Admin_backendset (si Oracle HTTP Server n'est pas utilisé)

Admin_Rules wlsfrontend.example.com Non
HTTPS_listener HTTPS 443

OHS_HTTP_backendset (si Oracle HTTP Server est utilisé)

WLSCluster1_routerule (si Oracle HTTP Server n'est pas utilisé)

App_Rules wlsfrontend.example.com Oui
HTTP_listener HTTP 80 Sans objet* S.O wlsfrontend.example.com Non

* HTTP_listener dans cet exemple est utilisé uniquement pour rediriger les demandes vers HTTPS_listener (HTTPS). Le serveur dorsal qui lui est affecté ne sera pas utilisé. Mais, puisqu'il est obligatoire d'en fournir un, vous devez en fournir un qui n'a pas de SSL coché (utilisez un jeu dorsal vide par défaut).

Créer le jeu de règles pour les en-têtes SSL

Créez un jeu de règles pour les en-têtes SSL dans l'équilibreur de charge Oracle Cloud Infrastructure (OCI) et associez-le au module d'écoute HTTPS.

Tout comme dans le site principal, l'équilibreur de charge OCI met fin au protocole SSL et la communication entre l'équilibreur de charge et le serveur dorsal est effectuée par protocole HTTP. Pour que cela fonctionne correctement, vous devez ajouter des en-têtes de demande dans l'équilibreur de charge OCI. Ces en-têtes sont ajoutés aux demandes du client qui arrivent au module d'écoute HTTPS, avant d'être envoyés au serveur dorsal WebLogic. Les en-têtes indiquent à WebLogic que la communication entre le client final et l'équilibreur de charge a utilisé HTTPS. Ainsi, toute URL créée dynamiquement par WebLogic sera correctement générée à l'aide de HTTPS.
  1. Sélectionnez l'équilibreur de charge dans la console. Cliquez sur Jeux de règles, puis sur Créer un jeu de règles.
  2. Indiquez un nom pour la règle.
    Par exemple, SSLHeaders.
  3. Cochez Préciser les règles d'en-tête de demande et ajoutez les actions suivantes :
    Action En-tête Valeur
    Ajouter une en-tête de demande is_ssl SSL
    Ajouter une en-tête de demande WL-Proxy-SSL Vrai
  4. Cliquez sur Créer.
  5. Cliquez sur Équilibreur de charge, puis sur Module d'écoute. Modifiez le module d'écoute qui utilise HTTPS pour associer la règle au module d'écoute HTTPS.
  6. Cliquez sur +Additional Jeu de règles, puis sélectionnez le jeu de règles SSLHeaders.

Créer un jeu de règles pour rediriger le protocole HTTP vers HTTPS

Créez une règle de redirection et associez-la à HTTP_listener pour rediriger le port 80 vers le port 443. Pour la topologie EDG, toutes les demandes qui atteignent le port 80 (HTTP) dans l'équilibreur de charge doivent être redirigées vers le port 443 (HTTPS).

  1. Dans la console, sélectionnez l'équilibreur de charge.
  2. Cliquez sur Jeux de règles, puis sur Créer un jeu de règles.
  3. Entrez un nom pour la règle.
    Par exemple, HTTP_to_HTTPS_redirect.
  4. Cochez Spécifier les règles de redirection d'URL et ajoutez les actions suivantes
    • Chemin d'accès à la source : /
    • Type de correspondance : Forcer la correspondance de préfixe la plus longue
    • Redirection vers :
    • Protocole : HTTPS
    • Hôte : {host} (laisser la valeur par défaut)
    • Port : 443
    • Chemin : /{path} (laisser la valeur par défaut)
    • Interrogation :?{query} (laisser la valeur par défaut)
    • Code de réponse : 301 - Définitivement déplacé
  5. Cliquez sur Équilibreur de charge, puis sur Module d'écoute. Modifiez le module d'écoute qui utilise le port HTTP 80 pour l'associer au module d'écoute HTTP.
  6. Cliquez sur +Additional Jeu de règles et sélectionnez la règle HTTP_to_HTTPS_redirect.

Ajouter le nom et l'adresse IP frontaux virtuels aux instances de calcul WLS

Dans une topologie de récupération après sinistre, les clients doivent accéder au système à l'aide d'un nom de domaine complet (généralement appelé nom frontal virtuel ou URL personnalisée) qui est indépendant du centre de données. Ce nom frontal virtuel doit être résolu à l'adresse IP de l'équilibreur de charge du site actif (principal) courant.

Le système principal doit déjà utiliser un nom virtuel frontal qui est résolu par le DNS avec l'adresse IP de l'équilibreur de charge principal. Toutefois, les hôtes Oracle WebLogic Server de chaque site doivent toujours résoudre le nom frontal avec son équilibreur de charge local, quelle que soit la résolution du client avec le DNS. Pour cela, le nom frontal virtuel est ajouté à leur fichier /etc/hosts avec l'adresse IP appropriée dans chaque site. Vous pouvez également le faire en utilisant différents serveurs DNS dans chaque site. Dans ce cas, le serveur DNS local résoudrait le nom frontal avec l'adresse IP de l'équilibreur de charge appropriée dans chaque site.

Utiliser les fichiers /etc/hosts
Le fichier /etc/hosts des hôtes Oracle WebLogic Server principaux et secondaires ne doit pas être modifié en cas de permutation ou de basculement. Les hôtes Oracle WebLogic Server résolvent toujours le nom frontal virtuel avec son adresse IP frontale. La mise à jour DNS requise lors des procédures de permutation et de basculement est effectuée dans les fichiers DNS ou d'hôte utilisés par les clients Oracle WebLogic Server.
  1. En tant qu'utilisateur racine, modifiez le fichier /etc/oci-hostname.conf dans les instances de calcul Oracle WebLogic Server for Oracle Cloud Infrastructure secondaires et mappez le nom frontal à l'adresse IP de l'équilibreur de charge Oracle Cloud Infrastructure (OCI).

    Voici un exemple du fichier /etc/hosts de l'instance de calcul Oracle WebLogic Server pour OCI secondaire, y compris l'entrée du nom frontal. 

    #################################
# 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 to secondary OCI LBR IP)
100.100.100.10    wlsfrontend.example.com
  2. Si ce n'est pas déjà fait, suivez les mêmes étapes dans les hôtes Oracle WebLogic Server principaux. Le nom frontal doit pointer vers l'adresse IP de l'équilibreur de charge principal.
    Voici un exemple du fichier /etc/hosts de l'hôte principal Oracle WebLogic Server sur place, y compris l'entrée du nom frontal. 
    #################################
# 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 to primary Load Balancer IP)
10.10.10.100    wlsfrontend.example.com
  3. Si votre système Oracle WebLogic Server utilise plus de noms frontaux virtuels, ajoutez-les au fichier en suivant la même règle.
Utiliser le système de noms de domaine (DNS)
Ce mode est valide lorsque des serveurs DNS séparés sont utilisés dans les systèmes sur place principal et secondaire sur Oracle Cloud Infrastructure (OCI). Sinon, cela peut provoquer des conflits dans la résolution des noms.

Si vous suivez cette approche, vous pouvez ajouter le nom frontal (pointant sur l'adresse IP de l'équilibreur de charge secondaire) au service DNS utilisé par les niveaux intermédiaires secondaires. Dans l'instance principale, on s'attend à ce que le nom frontal soit déjà résolu pointant vers l'adresse IP de l'équilibreur de charge principal.

Dans l'instance principale, on s'attend à ce que le nom frontal soit déjà résolu pointant vers l'adresse IP de l'équilibreur de charge principal.