1. Configurer une solution de récupération 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 système de secours du système sur site principal.

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

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

Préparation des sources de données WebLogic dans le centre de données principal

Vous pouvez utiliser plusieurs approches pour la chaîne de connexion de 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, des chaînes de connexion différentes et un alias TNS. Pour plus de détails et de comparaison entre les différentes approches, reportez-vous au Guide de récupération après sinistre 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 vers 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 est le même nom dans le principal 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é vers la base de données de secours. Vous pouvez donc avoir un contenu tnsnames.ora différent sur chaque site. Vous pouvez le placer séparément de la configuration de domaine WebLogic, dans un système de fichiers qui n'est pas répliqué entre les sites. Ou, étant donné qu'elle fait partie de la configuration, vous pouvez également la stocker dans un dossier sous la configuration du domaine. Dans ce cas, veillez à exclure ce dossier lorsque vous copiez la configuration de domaine de la configuration principale vers la configuration de secours. Chaque site résout l'alias TNS avec la chaîne de connexion appropriée dans chaque site, pointant vers la base de données locale uniquement. 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))
)

L'utilisation de l'alias TNS présente les avantages suivants :

  • Etant donné que 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 la réplication de config de la base de données principale vers la base de données de secours.
  • Comme chaque site pointe vers la base de données locale uniquement, il n'y a aucun risque de connexions croisées 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, procédez comme suit 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.

    Etant 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. Toutefois, dans ce cas, veillez à 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 qu'il pointe 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 indiqué dans l'exemple.
    Oracle recommande de saisir 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. Indiquez 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 de source de données. Oracle recommande cette méthode.

      1. Indiquez 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, accédez à Services, cliquez sur Sources de données, sélectionnez une source de données dans la liste, cliquez sur Pool 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. Indiquez 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"/>
…

        Remarque :

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

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

      1. Indiquez la propriété 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

        Remarque :

        Cette propriété s'applique à toutes les sources de données et aux fichiers jps dans Oracle WebLogic Server. Avant d'exécuter certaines des 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.

        Indiquez l'emplacement du fichier tnsnames.ora dans le cadre de la chaîne de connexion dans les sources de données et les fichiers jps : 

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

      Remarque :

      Cette propriété s'applique au fichier spécifique (source de données, fichier jps) dans lequel elle est indiqué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 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é 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.

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

  5. Redémarrez chaque instance Oracle WebLogic Server du 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. Meilleure pratique supplémentaire : lorsque vous utilisez Oracle Database 12c ou des versions ultérieures, les valeurs de configuration de l'hôte et du port ONS (Oracle Notification Service) 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 fonctionnalité au lieu de fournir l'adresse d'analyse ou la liste des noeuds Oracle RAC dans la configuration ONS de chaque source de données. Assurez-vous que la fonction FAN est activée 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. Accédez à 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

Une connectivité est requise entre le réseau sur site 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 cloud virtuel OCI via 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 VPN site à site, même s'il fournit une bande passante inférieure et une latence, une gigue et un coût variables.
  1. Créez le VCN et les sous-réseaux dans le compartiment OCI, comme défini dans Détermination des ressources nécessaires sur OCI. Configurez Oracle Cloud Infrastructure FastConnect (ou VPN site à site) pour permettre la communication entre votre réseau sur site et le VCN. Pour plus d'informations, reportez-vous à FastConnect et à VPN site à site.
  2. Créez les règles réseau requises dans OCI et dans le pare-feu sur site, 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.

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

    Source Cible Protocole et port Utilisation
    Réseau sur site Sous-réseau de niveau intermédiaire OCI SSH (port 22) Configuration et cycle de vie
    Réseau sur site 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 site 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 site Sous-réseau de niveau de base de données OCI SQLNET (port 1521) Pour Oracle Data Guard redo transport
    Réseau sur site Sous-réseau de niveau Web OCI HTTPS/HTTP (443, 80, 7001, 8888) Accès aux services Oracle SOA Suite et aux consoles d'administration
    Réseau sur site Sous-réseau de niveau intermédiaire OCI HTTP (7001,7010,8001,8011,8021,9001) Pour des 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é à partir des composants de niveau Web (équilibreur de charge OCI, Oracle HTTP Server) vers les 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é entre les serveurs WebLogic et la base de données
    Sous-réseau de niveau intermédiaire OCI Sous-réseau de niveau de service OCI Pour obtenir des informations spécifiques, reportez-vous à Configuration des règles de sécurité VCN pour File Storage. Procédure de montage des exports de système de fichiers OCI File Storage avec NFS.
    Sous-réseau de niveau intermédiaire OCI Hôtes de niveau intermédiaire (middle tier) sur site SSH (port 22) Pour rsync
    Sous-réseau de niveau de base de données OCI Hôtes de base de données sur site 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 au système frontal

    Remarque :

    Vous pouvez trouver du 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 site 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 site et une base de données de secours dans OCI, comme décrit dans Hybrid Data Guard vers Oracle Cloud Infrastructure.
    Pour vous aider à configurer 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 (DGMGRL) d'Oracle Data Guard.
    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 site. 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 données 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 pluggable, 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 données de secours instantanée.
    srvctl modify service -db $ORACLE_UNQNAME -s soapdb.example.com -role "PRIMARY,SNAPSHOT_STANDBY"
  5. Vérifiez les stratégies Oracle Recovery Manager (RMAN) de votre base de données principale afin d'empêcher la suppression des journaux d'archivage avant leur application à la base de données de secours.
    Assurez-vous que la clause applied on all standby figure dans la stratégie de suppression archivelog de RMAN, dans les bases de données principale et de secours.

A propos de la version de la base de données et du niveau de patch

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

  • Lorsque vous choisissez 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, puis sélectionnez la même version de base de données et le même niveau d'ensemble de patches que la base de données sur site.
  • 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 devez appliquer un patch à l'environnement source au même niveau de patch de base de données que le répertoire de base de la base de données dans l'environnement cloud.

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 site 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 patches installés dans les environnements source et cible.
    $ORACLE_HOME/OPatch/opatch lspatches

    Voici la sortie de cet exemple :

    Patches de répertoire de base Oracle de base de données sur site Patches Oracle HOME de base de données sur OCI

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

    30613937 ;IPCOR TOPO SERVICE FIX IP TYPE BUG IN IP SELECTION

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

    30489227 ;OCW RELEASE UPDATE 19.6.0.0.0 (30489227)

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

    29780459 ;AUGMENTER _LM_RES_HASH_BUCKET ET ANNULER LES MODIFICATIONS DU BUG 29416368 FIX

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

    32327201 ;RDBMS - DSTV36 MISE À JOUR - TZDATA2020E

    31335037 ;RDBMS - DSTV35 MISE À JOUR - TZDATA2020A

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

    31732095 ; METTRE À JOUR PERL DANS LE RÉPERTOIRE DE BASE DE LA BASE DE DONNÉES 19C VERS V5.32

    32490416 ; LOT DE CORRECTIFS JDK 19.0.0.0.210420

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

    32579761 ;OCW RELEASE UPDATE 19.11.0.0.0 (32579761)

    32545013 ;Mise à jour de la version de base de données : 19.11.0.0.210420 (32545013)
  2. Analysez les patches existants : déterminez les patches exceptionnels, vérifiez s'ils sont déjà corrigés dans les nouveaux patches RU ou si de nouveaux patches superposés sont nécessaires, déterminez lesquels doivent être désinstallés, localisez les fichiers de patches appropriés pour RU, etc.
  3. Selon l'analyse, désinstallez les patchs ponctuels déjà corrigés dans la nouvelle RU avant d'installer la mise à jour RU (sinon, ils provoqueront un conflit). Dans cet exemple, les patchs activés sont corrigés dans la version 19.11, de sorte que les patchs doivent être restauré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 patchs RU. Dans cet exemple, les patchs RU 19.11 se trouvent dans le patch combiné 32578973 : COMBO OF JOVM 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 patches ponctuels et les autres patches sur lesquels le répertoire de base de la base de données OCI se trouve au-dessus de l'unité d'initialisation. 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 patches GI.

Remarque :

Cet exemple inclut uniquement le répertoire de base Oracle du SGBDR. L'application de patches à l'installation de GI sur site au même niveau que le 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 de GI dans la base de données principale et 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 restriction de version ou de durée. (ID doc. 1265700.1)
  • Quelle que soit Oracle Data Guard, il n'est pas nécessaire d'avoir la même version dans les versions de GI et de SGBDR dans une base de données RAC : à partir de la version 18c, la version d'Oracle Grid Infrastructure (GI) /Clusterware (CRS) doit être égale ou la version la plus élevée jusqu'au premier chiffre des combinaisons possibles à tout moment. Par exemple : Grid Infrastructure peut être à l'emplacement 18.1.0.0 et Database à l'emplacement 18.3.0.0. (ID doc. 337737.1)

Il est recommandé d'appliquer un patch à GI au même niveau que le répertoire de base de la base de données. Une fois que vous avez à appliquer un patch au répertoire de base de base de données à une mise à jour de version plus récente, de nombreux patches sont communs à la base de données et à GI. Vous pouvez utiliser OPatchAuto dans les deux répertoires de base en même temps.