Configurer l'environnement

Configurez le système secondaire dans OCI et configurez-le en tant que base de secours du système principal sur place.

Des scripts sont disponibles pour automatiser certaines des étapes. Ces scripts n'automatisent pas la configuration complète. Vous devez donc effectuer les tâches et vous pouvez les utiliser lorsqu'ils sont référencés.

Allez à Télécharger le code pour obtenir le lien permettant de télécharger les scripts référencés dans ce document.

Préparer les sources de données WebLogic dans le centre de données principal

Il existe plusieurs approches que vous pouvez utiliser pour la chaîne de connexion à la base de données des sources de données WebLogic dans une topologie de récupération après sinistre, telles que la double chaîne, différentes chaînes de connexion et l'alias TNS. Voir le guide de récupération après sinistre d'Oracle Fusion Middleware pour plus de détails et pour une comparaison entre les différentes approches. Nous utiliserons l'alias TNS car il nécessite une configuration ponctuelle. L'utilisation d'un alias TNS signifie que vous n'aurez pas besoin de modifier la configuration WebLogic chaque fois que vous la copiez dans le secondaire. L'utilisation d'un alias TNS dans les sources de données GridLink est prise en charge à partir de la version FMW 12.2.1.3.

L'alias TNS est du même nom dans le primaire et le secondaire; par conséquent, les sources de données utilisent la même chaîne de connexion de base de données. Il est résolu avec un fichier tnsnames.ora qui n'est pas copié dans la base de données de secours, de sorte que vous pouvez avoir un contenu tnsnames.ora différent dans chaque site. Vous pouvez la placer séparément de la configuration du domaine WebLogic, dans un système de fichiers qui n'est pas répliqué entre les sites. Ou, étant donné qu'il fait partie de la configuration, vous pouvez également le stocker dans un dossier sous la configuration du domaine. Dans ce cas, assurez-vous d'exclure ce dossier lorsque vous copiez la configuration du domaine de la base principale vers la base de secours. Chaque site résoudra l'alias TNS avec la chaîne de connexion appropriée dans chaque site, pointant uniquement vers la base de données locale. Par exemple : 

Connect string in data sources in primary site:
jdbc:oracle:thin:@soapdb

The tnsnames.ora file in primary contains:
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=prmy-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Connect string in data sources in secondary site:
jdbc:oracle:thin:@soapdb
The tnsnames.ora file in secondary: 
SOAPDB =
(DESCRIPTION=
 (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=stby-scan)(PORT=1521)))
    (CONNECT_DATA=(SERVICE_NAME=soapdb.example.com))
)

Voici les avantages liés à l'utilisation d'alias TNS :

  • Comme la même chaîne de connexion de base de données est utilisée dans le domaine WebLogic config, vous n'avez pas besoin de modifier la configuration WebLogic après avoir répliqué config de la base principale à la base de données de secours.
  • Comme chaque site pointe uniquement vers la base de données locale, il n'y a aucun risque de connexions croisées entre le niveau intermédiaire et la base distante.

Si vous n'utilisez pas déjà cette approche dans le système SOA principal, effectuez les étapes suivantes pour utiliser un alias TNS dans les sources de données.

  1. Créez le dossier tns dans les hôtes de niveau intermédiaire principaux :

    Ce dossier doit être lisible par l'utilisateur Oracle et placé dans un système de fichiers qui n'est pas répliqué entre les sites.

    Étant donné que le dossier tns fait partie de la configuration, vous pouvez également le créer sous le dossier de configuration partagé par tous les serveurs. Dans ce cas, assurez-vous d'exclure le dossier tns lorsque vous copiez la configuration de domaine de la base de données principale vers la base de données de secours ou mettez à jour tnsnames.ora dans le système de secours, après un basculement ou une permutation, pour pointer vers la base de données secondaire. 

    [oracle@host3 ~]$ mkdir -p /home/oracle/tnsnames_dir
[oracle@host4 ~]$ mkdir -p /home/oracle/tnsnames_dir
  2. Créez un fichier tnsnames.ora dans le répertoire avec l'alias TNS qui sera utilisé dans les sources de données, comme illustré dans l'exemple.
    Oracle recommande d'entrer la chaîne sur une seule ligne.
    SOAPDB = 
(DESCRIPTION=
  (ADDRESS_LIST=
    (LOAD_BALANCE=ON)
    (ADDRESS=(PROTOCOL=TCP)(HOST=dbhost-scan.example.com)(PORT=1521))
  )
  (CONNECT_DATA=(SERVICE_NAME= soapdb.example.com))
)
  3. Spécifiez la propriété oracle.net.tns_admin pointant vers l'emplacement du répertoire du fichier tnsnames.ora. Utilisez l'une des méthodes suivantes :

    • Option 1 : Définissez la propriété en tant que propriété de connexion à la source de données. Oracle recommande cette méthode.

      1. Spécifiez la propriété oracle.net.tns_admin=tns_directory dans la configuration de la source de données.

        Pour spécifier cette propriété dans la console d'administration WebLogic, allez à Services, cliquez sur Sources de données, sélectionnez une source de données dans la liste, cliquez sur Réserve de connexions, puis ajoutez-la à la zone de texte Propriétés. Répétez cette étape pour chaque source de données.

        Par exemple : oracle.net.tns_admin=/home/oracle/tnsnames_dir

      2. Spécifiez cette propriété dans la sécurité OPSS pour stocker les fichiers jps-config-jse.xml et jps-config.xm disponibles dans le dossier $ASERVER_HOME/config/fmwconfig.

        Pour modifier ces fichiers jps, modifiez-les et ajoutez la propriété oracle.net.tns_admin après la propriété jdbc.url. Par exemple, 

        …
<property name="jdbc.url" value="jdbc:oracle:thin:@soaedg"/>
<property name="oracle.net.tns_admin" value="tns_directory"/>
…

        Note :

        Cette propriété s'applique au fichier spécifique (source de données, fichier jps) dans lequel elle est spécifiée.

    • Option 2 : Définissez la propriété en tant que propriété de système java.

      1. Spécifiez la propriété de système -Doracle.net.tns_admin=tns_directory où tns_directory est l'emplacement du répertoire du fichier tnsnames.ora.

        Pour le définir en tant que propriété java pour les serveurs, modifiez les fichiers suivants :
        • $ASERVER_HOME/bin/setUserOverrides.sh and
        • $MSERVER_HOME/bin/setUserOverrides.sh (Ce fichier n'est pas partagé. Par conséquent, vous devez modifier le fichier dans tous les hôtes de niveau intermédiaire SOA.)

      2. Ajoutez le contenu suivant à ces fichiers : 

        # For using tns alias in the datasources 
export EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Doracle.net.tns_admin=/home/oracle/tnsnames_dir

        Note :

        Cette propriété s'applique à toutes les sources de données et à tous les fichiers jps d'Oracle WebLogic Server. Avant d'exécuter certaines commandes WLST et l'assistant de configuration, vous devez définir la propriété dans l'environnement.
        • Avant d'exécuter WLST, définissez la propriété dans la variable d'environnement WLST_PROPERTIES.
        • Avant d'exécuter l'assistant de configuration, ajoutez la propriété à la variable d'environnement JVM_ARGS du script config_internal.sh.
      3. Option 3 : Définissez la propriété dans l'URL jdbc.

        Spécifiez l'emplacement du fichier tnsnames.ora dans la chaîne de connexion des sources de données et des fichiers jps : 

        jdbc:oracle:thin:@alias?TNS_ADMIN=tns_directory

      Note :

      Cette propriété s'applique au fichier spécifique (source de données, fichier jps) dans lequel elle est spécifiée.

      Vous pouvez utiliser cette méthode avec le pilote JDBC version 18.3 et ultérieure. Cela s'applique à Fusion Middleware 12.2.1.4 (qui utilise le pilote JDBC 19.3) et versions ultérieures.

  4. Utilisez l'alias dans l'URL de définition de source de données en remplaçant la chaîne de connexion par l'alias.
    jdbc:oracle:thin:@soapdb
    Modifiez les fichiers suivants :
    • Dans les fichiers de source de données, situés dans $ASERVER_HOME/config/jdbc/
    • Dans les fichiers jps-config.xml et jps-config-jse.xml, situés dans $ASERVER_HOME/config/fmwconfig/
    Vous pouvez utiliser la console d'administration Oracle WebLogic Server pour modifier les sources de données, mais vous devez modifier manuellement les fichiers jps-config xml. Vous pouvez utiliser le script update_dbconnect.sh pour effectuer le remplacement dans tous les fichiers mentionnés.

    Allez à Télécharger le code pour obtenir le lien permettant de télécharger le script.

  5. Redémarrez chaque serveur Oracle WebLogic Server dans le domaine.
    1. Arrêtez tous les serveurs WebLogic du domaine principal (serveur d'administration et serveurs gérés).
    2. Démarrez le serveur d'administration dans le domaine principal.
    3. Une fois le serveur d'administration en cours d'exécution, démarrez les serveurs gérés.
    4. Vérifiez que les connexions sont correctement établies avec la base de données.
  6. Meilleures pratiques supplémentaires : Lorsque vous utilisez une version d'Oracle Database 12c ou une version ultérieure, les valeurs de configuration d'hôte et de port du service d'avis Oracle (ONS) ne sont pas requises dans les sources de données GridLink.
    La liste Oracle Notification Service est automatiquement obtenue à partir de la base de données par le pilote client. Oracle recommande d'utiliser cette fonction au lieu de fournir l'adresse de balayage ou la liste des noeuds Oracle RAC dans la configuration ONS de chaque source de données. Assurez-vous que l'avis rapide des applications est activé et que la propriété ONS nodes est vide dans chaque source de données.
    1. Ouvrez la console d'administration Oracle WebLogic Server.
    2. Allez à Services, puis à Sources de données. Sélectionnez le nom de la source de données, puis Configuration et ONS.
    3. Vérifiez que la liste des noeuds ONS est vide.

Configurer le réseau

La connectivité est requise entre le réseau sur place principal et le réseau Oracle Cloud Infrastructure (OCI) secondaire. Oracle recommande d'utiliser Oracle Cloud Infrastructure FastConnect, qui vous permet de vous connecter directement à votre réseau en nuage virtuel OCI au moyen d'une connexion dédiée, privée et à bande passante élevée. Vous choisissez une vitesse de port appropriée en fonction de la quantité de données. Vous pouvez également utiliser un RPV site à site, bien qu'il fournisse une bande passante plus faible et une latence, une gigue et un coût variables.
  1. Créez le VCN et les sous-réseaux dans le compartiment OCI, tels que définis dans Déterminer les ressources requises sur OCI. Configurez Oracle Cloud Infrastructure FastConnect (ou RPV site à site) pour permettre la communication entre votre réseau sur place et le VCN. Pour plus d'informations, voir FastConnect et RPV site à site.
  2. Créez les règles de réseau requises dans OCI et dans le pare-feu sur place et configurez la source, les cibles, les protocoles et les ports, comme indiqué dans le tableau.

    On suppose que tout le trafic est activé à l'intérieur de chaque sous-réseau.

    Voir la documentation sur OCI pour plus d'informations sur les règles de sécurité de réseau.

    Source Cible Protocole et port Syntaxe
    Réseau sur place Sous-réseau de niveau intermédiaire OCI SSH (port 22) Configuration et cycle de vie
    Réseau sur place Sous-réseau de niveau Web OCI SSH (port 22) Configuration et cycle de vie (lorsque Oracle HTTP Server est utilisé dans OCI)
    Réseau sur place Sous-réseau de niveau de base de données OCI SSH (port 22) Configuration et cycle de vie
    Hôtes de base de données sur place Sous-réseau de niveau de base de données OCI SQLNET (port 1521) Pour Oracle Data Guard redo transport
    Réseau sur place Sous-réseau de niveau Web OCI HTTPS/HTTP (443, 80, 7001, 88888) Accès aux services et aux consoles d'administration d'Oracle SOA Suite
    Réseau sur place Sous-réseau de niveau intermédiaire OCI HTTP (7001,7010,8001,8011,8021,9001) Pour les vérifications directes dans Oracle WebLogic Server
    Sous-réseau de niveau Web OCI Sous-réseau de niveau intermédiaire OCI HTTP (7001,7010,8001,8011,8021,9001) Pour la connectivité des composants de niveau Web (équilibreur de charge OCI, Oracle HTTP Server) aux serveurs WebLogic
    Sous-réseau de niveau intermédiaire OCI Sous-réseau de niveau de base de données OCI SQLNET (1521), ONS (6200) Pour la connectivité des serveurs WebLogic à la base de données
    Sous-réseau de niveau intermédiaire OCI Sous-réseau de niveau CSS OCI Pour plus d'informations, voir Configuration de règles de sécurité de réseau VCN pour le service de stockage de fichiers. Pour monter les exportations du système de fichiers du service de stockage de fichiers OCI avec NFS.
    Sous-réseau de niveau intermédiaire OCI Hôtes de niveau intermédiaire sur place SSH (port 22) Pour rsync
    Sous-réseau de niveau de base de données OCI Hôtes de base de données sur place SQLNET (1521) Pour Oracle Data Guard redo transport
    Sous-réseau de niveau intermédiaire OCI Sous-réseau de niveau Web OCI HTTPS (443) Pour les rappels de l'application vers le front-end

    Note :

    Vous pouvez trouver le code terraform pour créer le VCN, les sous-réseaux et les règles de sécurité dans Télécharger le code.

Configurer Oracle Data Guard

Configurez Oracle Data Guard entre la base de données principale sur place et la base de données de secours dans Oracle Cloud Infrastructure (OCI).
  1. Configurez Oracle Data Guard entre une base de données principale sur place et une base de données de secours dans OCI, comme décrit dans Hybrid Data Guard vers Oracle Cloud Infrastructure.
    Pour faciliter la configuration d'Oracle Data Guard, des scripts sont disponibles dans GitHub et référencés dans Télécharger le code.
  2. Vérifiez que la configuration d'Oracle Data Guard est correcte à l'aide de l'interface de ligne de commande d'Oracle Data Guard (DGMGRL).
    DGMGRL> show configuration verbose
  3. Une fois la configuration d'Oracle Data Guard terminée (étape 2), créez les mêmes services de base de données dans le système de base de données OCI que ceux utilisés dans le système principal sur place. Configurez le service avec le rôle PRIMARY et avec le rôle SNAPSHOT_STANDBY.
    La configuration du service avec les deux rôles permet au service d'être démarré automatiquement par DG Broker lorsque la base de données est convertie en base de secours instantanée, ce qui est requis lorsque vous souhaitez valider le système secondaire sans effectuer une permutation complète.
    Par exemple, si la base de données principale utilise le service de base de données soapdb.example.com pour accéder à la base de données enfichable, créez le même service dans le système de base de données OCI secondaire. 
    srvctl add service -db $ORACLE_UNQNAME -service soapdb.example.com -preferred ORCL1,ORCL2 -pdb PDB1 -role "PRIMARY,SNAPSHOT_STANDBY"
srvctl modify service -db $ORACLE_UNQNAME -service soapdb.example.com -rlbgoal SERVICE_TIME -clbgoal SHORT
srvctl config service -db $ORACLE_UNQNAME -service soapdb.example.com
  4. Si le service de la base de données principale a été créé avec le rôle PRIMARY uniquement (par défaut), vous pouvez le modifier pour ajouter le rôle de base de secours instantanée.
    srvctl modify service -db $ORACLE_UNQNAME -s soapdb.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. Vérifiez les politiques Oracle Recovery Manager (RMAN) dans votre base de données principale pour empêcher la suppression des journaux d'archivage avant leur application à la base de données de secours.
    Assurez-vous d'avoir la clause applied on all standby dans la politique de suppression archivelog de RMAN, dans les bases de données principale et de secours.

À propos de la version de la base de données et du niveau de correctif

Le répertoire de base Oracle dans la base de données sur place et la base de données de secours sur OCI doivent avoir la même version et le même niveau de correctif. Pour ce faire, procédez comme suit :

  • Lors du choix de l'image logicielle de base de données lors du provisionnement du système de base de données dans OCI, sélectionnez Afficher toutes les versions et sélectionnez la même version de base de données et le même niveau de jeu de correctifs que la base de données sur place.
  • Si la version du répertoire de base Oracle de la base de données source n'est plus disponible dans OCI pour le provisionnement, vous devrez appliquer des correctifs à l'environnement source au même niveau de correctif de base de données que celui du répertoire de base dans l'environnement en nuage.

Le scénario suivant est un véritable exemple de référence. Le répertoire de base de base de données sur place est 19.6 et le répertoire de base OCI est 19.11.

  1. Exécutez la commande $ORACLE_HOME/OPatch/opatch lspatches pour identifier les correctifs installés à la fois sur les environnements source et cible.
    $ORACLE_HOME/OPatch/opatch lspatches

    Voici la sortie de cet exemple :

    Correctifs de répertoire de base Oracle de base de données sur place Correctifs DB Oracle HOME sur OCI

    30676209;LNX64-20.1-RAC ASM HIT ORA-07445 EXCEPTION ENCOUNTERED CORE DUMP [KSXPOSDIFQRY()+556]

    30613937; IPCOR TOPO SERVICE CORRECTION IP TYPE BUG DANS LA SÉLECTION IP

    30484981;MISE À JOUR DE VERSION D'OJVM : 19.6.0.0.200114 (30484981)

    30489227;OCW VERSION MISE À JOUR 19.6.0.0.0 (30489227)

    30557433;Mise à jour de version de base de données : 19.6.0.0.200114 (30557433)

    29780459;AUGMENTEZ _LM_RES_HASH_BUCKET ET ANNULEZ LES CHANGEMENTS DE LA CORRECTION DU BOGUE 29416368

    30310195;DBSAT A SIGNALÉ DES CONTRAINTES DÉSACTIVÉES POUR LE PARTAGE STS_CHUNKS SUR GSMADMIN_INTERNAL.SHARD_TS

    32327201;RDBMS - DSTV36 MISE À JOUR - TZDATA2020E

    31335037;RDBMS - DSTV35 MISE À JOUR - TZDATA2020A

    30432118;DEMANDE DE FUSION AU-DESSUS DE 19.0.0.0.0 POUR LES BOGUES 28852325 29997937

    31732095;METTRE À JOUR PERL DANS 19C DATABASE ORACLE HOME VERS V5.32

    32490416;CORRECTIF DU GROUPE JDK 19.0.0.0.210420

    32399816;MISE À JOUR DE VERSION D'OJVM : 19.11.0.0.210420 (32399816)

    32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)

    32545013;Mise à jour de version de base de données : 19.11.0.0.210420 (32545013)
  2. Analyser les correctifs existants : déterminer quels correctifs sont uniques, vérifier s'ils sont déjà corrigés dans les nouveaux correctifs de mise à jour de version ou si de nouveaux correctifs de chevauchement sont nécessaires, déterminer lesquels d'entre eux doivent être désinstallés, localiser les fichiers de correctifs appropriés pour la mise à jour de version, etc.
  3. Sur la base de l'analyse, désinstallez les correctifs uniques qui sont déjà corrigés dans la nouvelle RU avant d'installer la mise à jour de RU (sinon, ils provoqueront un conflit). Dans cet exemple, les patches on-off sont corrigés dans la version 19.11, de sorte que les patches doivent être annulés avant l'installation de la version 19.11 RU.
    30676209;LNX64-20.1-RAC  ASM HIT ORA-07445  EXCEPTION ENCOUNTERED  CORE DUMP [KSXPOSDIFQRY()+556]
30613937;IPCOR TOPO SERVICE  FIX IP TYPE BUG IN IP SELECTION
  4. Localisez, téléchargez et installez les correctifs RU. Dans cet exemple, les correctifs RU 19.11 sont situés dans le correctif combiné 32578973 : COMBO OF OJVM RU COMPONENT 19.11.0.0.210420 + GI RU 19.11.0.0.210420 et sont les suivants :
    32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)  
32579761;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)            
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
  5. Localisez, téléchargez et installez les superpositions, les correctifs ponctuels et les autres correctifs que le répertoire de base de base de données OCI contient en plus de la mise à jour de version. Par exemple : 
    29780459;INCREASE _LM_RES_HASH_BUCKET AND BACK OUT CHANGES FROM THE BUG 29416368 FIX
30310195;DBSAT REPORTED DISABLED CONSTRAINTS FOR SHARDING STS_CHUNKS ON GSMADMIN_INTERNAL.SHARD_TS
30432118;MERGE REQUEST ON TOP OF 19.0.0.0.0 FOR BUGS 28852325 (DSTV33 update) 29997937 (DSTV34 update)
31335037;RDBMS - DSTV35 UPDATE - TZDATA2020A
32327201;RDBMS - DSTV36 UPDATE - TZDATA2020E
32490416;JDK BUNDLE PATCH 19.0.0.0.210420
31732095;UPDATE PERL IN 19C DATABASE ORACLE HOME TO V5.32
  6. Effectuez une analyse similaire pour les correctifs GI.

Note :

Cet exemple inclut uniquement le répertoire de base Oracle du SGBDR. L'application de correctifs à l'installation GI sur place au même niveau que l'installation secondaire peut ne pas être strictement nécessaire :
  • Du point de vue d'Oracle Data Guard, il n'est pas strictement nécessaire d'avoir les mêmes versions GI dans la base de données principale et la base de secours : Oracle Data Guard est complètement indépendant de tout ce qui se trouve sous la base de données, de sorte que vous pouvez exécuter différentes versions du système d'exploitation, d'Oracle Clusterware, du matériel ou du logiciel de stockage sur différents sites sans restrictions sur les versions ou l'heure. (Doc ID 1265700.1)
  • Quelle que soit la version d'Oracle Data Guard, il n'est pas nécessaire d'avoir la même version dans les versions GI et RDBMS dans une base de données RAC : À partir de 18c, la version d'Oracle Grid Infrastructure (GI) /Clusterware (CRS) doit être identique ou la version la plus élevée jusqu'au premier chiffre des combinaisons possibles à tout moment. Par exemple : Grid Infrastructure peut être sur 18.1.0.0 et Database peut être sur 18.3.0.0. (Doc ID 337737.1)

Il est recommandé d'appliquer des correctifs à l'infrastructure géographique au même niveau que le répertoire de base de données. Une fois que vous devez appliquer un correctif au répertoire de base de base de données à une mise à jour de version plus récente, la plupart des correctifs sont communs pour la base de données et l'interface GI, et vous pouvez utiliser OPatchAuto pour les deux répertoires en même temps.