1. Configurer une solution de reprise après sinistre hybride pour Oracle SOA Suite
  2. Configurer l'environnement

Configurer l'environnement

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

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

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

Préparez 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 double chaîne, différentes chaînes de connexion et alias TNS. Pour plus de détails et une comparaison entre les différentes approches, consultez le guide de récupération après sinistre pour Oracle Fusion Middleware. Nous utiliserons l'alias TNS car il nécessite une configuration unique. 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 lors du démarrage de FMW version 12.2.1.3.

L'alias TNS porte le même nom dans les sources principale et 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 le 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 de 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 d'utiliser un 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 vers la base de secours.
  • Comme chaque site pointe uniquement vers la base de données locale, il n'y a aucun risque d'interconnexion entre le niveau intermédiaire et la base de données 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 qui est partagé par tous les serveurs. Toutefois, dans ce cas, assurez-vous d'exclure le dossier tns lorsque vous copiez la configuration de domaine de la base principale vers la base 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 les fichiers de sécurité OPSS 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 la 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 fichiers jps dans 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 18.3 et versions ultérieures. Cela s'applique à Fusion Middleware 12.2.1.4 (qui utilise le pilote JDBC 19.3) et aux versions ultérieures.

  4. Utilisez l'alias dans l'URL de définition de la 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 d'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 le lien de téléchargement du script.

  5. Redémarrez chaque 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 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 des services de notification Oracle 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 d'Oracle WebLogic Server.
    2. Allez à Services, puis à Sources de données. Sélectionnez le nom de la source de données, 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 à large bande passante. Vous choisissez une vitesse de port appropriée en fonction de la quantité de données. Vous pouvez également utiliser un RPV site-à-site, même s'il fournit une bande passante inférieure, ainsi qu'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 nécessaires 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é dans chaque sous-réseau.

    Pour plus d'informations sur les règles de sécurité de réseau, voir la documentation OCI.

    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 (lorsqu'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, 8888) Accès aux services et 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 sur 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 de système de fichiers du service de stockage de fichiers OCI avec NFS.
    Sous-réseau de niveau intermédiaire OCI Hôtes de milieu de gamme 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 l'interface

    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 sur place principale et la base 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, les 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 que vous avez terminé la configuration d'Oracle Data Guard (é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 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 nécessaire 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 (valeur 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) de votre base de données principale pour empêcher la suppression des journaux d'archives 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 avoir le même niveau de correctif. Pour ce faire, vous pouvez :

  • Lors de la sélection 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 que le répertoire de base de données dans l'environnement en nuage.

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

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

    Voici la sortie de cet exemple :

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

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

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

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

    30489227;OCW MISE À JOUR DE LA VERSION 19.6.0.0.0 (30489227)

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

    29780459;AUGMENTER _LM_RES_HASH_BUCKET ET ANNULER LES CHANGEMENTS DU BUG 29416368 CORRECTION

    30310195;CONTRAINTES DÉSACTIVÉES SIGNALÉES PAR DBSAT POUR LA PARTITION 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 LE RÉPERTOIRE DE BASE ORACLE DE LA BASE DE DONNÉES 19C VERS V5.32

    32490416;CORRECTIF D'ENSEMBLE JDK 19.0.0.0.210420

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

    32579761;MISE À JOUR DE LA VERSION 19.11.0.0.0 (32579761)

    32545013;Mise à jour de la version de la base de données : 19.11.0.0.210420 (32545013)
  2. Analysez les correctifs existants : déterminez quels correctifs sont ponctuels, vérifiez s'ils sont déjà corrigés dans les nouveaux correctifs RU ou si de nouveaux correctifs de chevauchement sont nécessaires, déterminez lesquels d'entre eux doivent être désinstallés, localisez les fichiers de correctifs appropriés pour RU, etc.
  3. Sur la base de l'analyse, désinstallez les correctifs ponctuels qui sont déjà corrigés dans la nouvelle RU avant d'installer la mise à jour RU (sinon, ils provoqueront un conflit). Dans cet exemple, les patches on-off sont fixés en 19.11, de sorte que les patches doivent être repositionnés avant l'installation de la RU 19.11.
    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 patchs RU 19.11 sont situés dans le patch combo 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 dont dispose le répertoire de base de la base de données OCI au-dessus de l'UR. 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 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 principale et la base de secours : Oracle Data Guard est complètement indépendant de tout ce qui se trouve dans la base de données. Vous pouvez donc exécuter différentes versions du système d'exploitation, d'Oracle Clusterware, du matériel ou des logiciels de stockage sur différents sites, sans aucune restriction de version ni de temps. (Doc ID 1265700.1)
  • Indépendamment 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 la version 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 en tout temps. Par exemple, Grid Infrastructure peut être à l'adresse 18.1.0.0 et Database peut être à l'adresse 18.3.0.0. (Doc ID 337737.1)

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