1. Configurer la récupération après sinistre d'Oracle Fusion Middleware sur Oracle Cloud avec une base de données autonome
  2. Configuration de la topologie de récupération après sinistre

Configuration de la topologie de récupération après sinistre

Configurez la topologie de récupération après sinistre. Des scripts sont disponibles pour rationaliser le processus.

Télécharger les scripts

Obtenez les derniers scripts de configuration à partir du référentiel GitHub.

Remarque :

Placez tous les scripts téléchargés dans le même dossier.
  1. Accédez au référentiel GitHub.
  2. Téléchargez tous les scripts dans le répertoire maa/fmw-wls-with-adb-dr.
  3. Téléchargez tous les scripts dans le répertoire maa/app_dr_common.
    Ces scripts se font des appels. Bien que l'opération spécifique soit effectuée à un moment donné, téléchargez tous les répertoires et placez tous les scripts dans le même dossier. Vous aurez besoin des scripts des sites principal et secondaire.
  4. Suivez les instructions de ce document et lisez les variables requises dans chaque script pour chaque opération que vous effectuez.

Le fichier téléchargé inclut des scripts permettant d'effectuer les tâches suivantes :

  1. Configuration d'un alias TNS pour les sources de données
  2. Configuration de la reconfiguration dynamique initiale
  3. Configurer la réplication continue
  4. Modifiez les portefeuilles d'un système Oracle WebLogic Server, Oracle SOA ou Oracle Fusion Middleware.
Chaque script fournit une automatisation des différentes parties de la configuration de la récupération après sinistre et du cycle de vie d'un système de protection contre les sinistres. Le tableau suivant fournit un récapitulatif des utilitaires :
Nom du script Description
fmwadb_config_replica.sh Répliquez la configuration entre les sites.
fmwadb_dr_prim.sh Prépare un site principal pour la configuration de la récupération après sinistre.
fmwadb_dr_stby.sh Prépare un site secondaire pour la configuration de la récupération après sinistre.
fmwadb_rest_api_listabds.sh Obtenez la base de rôles Autonomous Database sur l'ID ADB et les informations de location.
fmwadb_switch_db_conn.sh Remplace les informations de connexion existantes par une nouvelle balise ADBS WALLET.
fmw_change_to_tns_alias.sh Remplacez les chaînes de connexion utilisées par les sources de données Oracle WebLogic et les fichiers jps config par un alias tns.
fmw_dec_pwd.sh Décrypte un mot de passe crypté Oracle WebLogic.
fmw_enc_pwd.sh Crypte un mot de passe à l'aide du cryptage Oracle WebLogic.
fmw_get_connect_string.sh Renvoie la chaîne de connexion utilisée par une source de données Oracle WebLogic, Oracle SOA ou Oracle Fusion Middleware.
fmw_get_ds_property.sh Renvoie la valeur d'une propriété de source de données spécifique.

Préparation du niveau intermédiaire principal pour le système frontal virtuel

Si le niveau intermédiaire principal n'est pas déjà configuré avec un nom frontal virtuel, effectuez ces actions pour le préparer à la configuration de la récupération après sinistre.

  1. Ajoutez le nom et l'adresse IP frontaux virtuels au fichier /etc/hosts dans tous les hôtes de niveau intermédiaire (middle tier) principaux.
    Chaque site doit toujours résoudre le nom frontal vers son équilibreur de charge local, quelle que soit la résolution côté client via le système de noms de domaine (DNS). En tant qu'utilisateur root, modifiez le fichier /etc/hosts et mettez en correspondance l'adresse IP publique de l'équilibreur de charge principal avec le nom de domaine qualifié complet frontal virtuel. Répétez cette opération sur tous les hôtes Oracle WebLogic principaux. Par exemple : 
    [oracle@wlsociprefix-wls-0 ~]$ more /etc/hosts
(...)
# Front-end virtual name
111.111.111.111 mywebapps.example.com

    Remarque :

    Le fichier /etc/hosts des hôtes Oracle WebLogic principaux ne doit pas être modifié en cas de permutation ou de basculement. Les hôtes Oracle WebLogic principaux résolvent toujours le nom frontal virtuel avec son adresse IP frontale. La mise à jour DNS nécessaire au cours des procédures de permutation et de basculement est effectuée dans les fichiers DNS ou hôte utilisés par les clients.

  2. Configurez le nom frontal en tant que serveur frontal de cluster.
    1. Connectez-vous à la console Oracle WebLogic de votre instance.
    2. Accédez à Environment, puis à Clusters et sélectionnez le cluster.
    3. Accédez à Configuration, puis à HTTP.
    4. Définissez l'hôte frontal sur le nom de domaine qualifié complet frontal.
      Par exemple, mywebapps.example.com.
    5. Assurez-vous que les ports frontaux pour HTTP et HTTPS sont correctement configurés avec des valeurs.
    6. Cliquez sur Enregistrer, puis sur Activer.
  3. Redémarrez le cluster pour implémenter les modifications.

Modification des sources de données principales et de la configuration JPS pour utiliser un alias TNS

L'utilisation d'un alias TNS (Transparent Network Substrate) dans les URL JDBC (Java Database Connectivity) facilite la reconfiguration des sources de données Oracle WebLogic Server for Oracle Cloud Infrastructure à l'aide de clones actualisables distants pour passer d'une source principale à une autre.

Remarque :

Les instances Oracle SOA Suite on Marketplace provisionnées avec la version 23.1.1 (février 2023) ou une version ultérieure sont configurées avec l'approche d'alias TNS prête à l'emploi. Dans ce cas, vous pouvez ignorer cette tâche.

L'utilisation d'un alias TNS nécessite que les sources de données et les fichiers jps incluent la variable oracle.net.tns_admin dans les fichiers de configuration Oracle Fusion Middleware.

  1. Utilisez la commande grep pour rechercher la variable oracle.net.tns_admin dans le fichier de configuration Oracle Fusion Middleware. 
    [oracle@soarefr-soa-0 ~]$ grep oracle.net.tns_admin ${DOMAIN_HOME}/config/fmwconfig/jps-config.xml 
<property name="oracle.net.tns_admin" value="/u01/data/domains/soarefr_domain/config/atp"/>

[oracle@soarefr-soa-0 ~]$ grep oracle.net.tns ${DOMAIN_HOME}/config/jdbc/opss-datasource-jdbc.xml  -A1 | grep value 
<value>/u01/data/domains/soarefr_domain/config/atp</value>
[oracle@soarefr-soa-0 ~]$
    Le répertoire indiqué dans jps-config.xml (et les sources de données) doit être disponible et accessible à partir de tous les noeuds du domaine WebLogic Server.
    • Dans Oracle SOA Suite on Marketplace, ce répertoire se trouve sous le répertoire $DOMAIN_HOME/config/atp (avant la version 23.1.1) ou le répertoire $DOMAIN_HOME/config/tnsadmin (pour les versions 23.1.1 et ultérieures) et est automatiquement répliqué par le serveur WebLogic sur tous les autres noeuds lorsque les serveurs gérés sont démarrés.

      Remarque :

      Si la version principale d'Oracle SOA Suite on Marketplace est antérieure à la version 23.1.1, il est recommandé de déplacer le dossier vers le répertoire $DOMAIN_HOME/config/tnsadmin pour le rendre cohérent avec la version de secours.
    • Dans Oracle WebLogic Server for Oracle Cloud Infrastructure, il se trouve sous $DOMAIN_HOME/atpwallet.

      Remarque :

      Si le portefeuille n'est pas situé sous le répertoire DOMAIN_HOME/config, les modifications apportées au contenu du répertoire de portefeuille NE seront PAS répliquées automatiquement par l'infrastructure Oracle WebLogic Server vers d'autres noeuds. Dans ce cas, vous devez modifier le répertoire du portefeuille (et mettre à jour les configurations de sources de données requises) ou le copier manuellement vers d'autres noeuds lors de sa mise à jour.
    • Dans d'autres configurations, vous pouvez placer le répertoire sur le stockage partagé.
    Dans tous les cas, le même répertoire tns_admin doit être accessible par tous les différents membres d'un domaine WebLogic Server. Ce répertoire contient un fichier tnsnames.ora avec différents alias pour les différents services créés dans Oracle Autonomous Database.

    Voici un exemple de fichier tnsnames.ora pour et la configuration Oracle Fusion Middleware avec Oracle Autonomous Database Serverless. 

    [oracle@soarefr-soa-0 ~]$ cat 
$DOMAIN_HOME}}/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Les modifications apportées au fichier tnsnames.ora sont utilisées dynamiquement par les sources de données WLS. Cela signifie que vous pouvez modifier le fichier tnsnames.ora (par exemple pour pointer vers un autre service) sans nécessiter le redémarrage de la source de données.

  2. Pour modifier une configuration de source de données standard afin d'utiliser un alias TNS dans un système Oracle SOA Suite on Marketplace ou Oracle WebLogic Server for Oracle Cloud Infrastructure qui utilise Autonomous Database, utilisez le script fmw_change_to_tns_alias.sh.

    L'alias doit être utilisé dans tous les fichiers de source de données sous $DOMAIN_HOME/config/jdbc et dans les fichiers jps config sous $DOMAIN_HOME/config/fmwconfig.

    Remarque :

    Ce script modifie uniquement la chaîne de connexion et la propriété tns_admin. Si vous ajoutez d'autres sources de données personnalisées, elles devront également utiliser un alias TNS comme les sources internes pour Oracle WebLogic, Oracle SOA Suite on Marketplace et Oracle Fusion Middleware.
    Lorsque Oracle WebLogic Server for Oracle Cloud Infrastructure ou Oracle SOA Suite on Marketplace sont provisionnés à l'aide d'Oracle Autonomous Database, la configuration du portefeuille de base de données est incluse dans les sources de données (emplacement du magasin de confiance, emplacement du fichier de clés, etc.). Ces paramètres ne sont PAS modifiés par le script fmw_change_to_tns_alias.sh et sont valides que l'alias TNS soit utilisé ou non. Un répertoire de portefeuille est créé par Oracle WebLogic Server for Oracle Cloud Infrastructure et Oracle SOA Suite on Marketplace lors du provisionnement et contient déjà un fichier tnsnames.ora. Vous pouvez également obtenir le portefeuille Oracle Autonomous Database à partir de l'interface utilisateur de base de données autonome dans OCI.

    Remarque :

    Le portefeuille Oracle Autonomous Database utilisé par Oracle WebLogic Server for Oracle Cloud Infrastructure et Oracle SOA Suite on Marketplace est téléchargé vers le noeud de serveur d'administration lorsqu'ils sont provisionnés. Vous pouvez mettre à jour le portefeuille pour les systèmes principal et de secours en le téléchargeant à nouveau à partir de l'interface utilisateur Oracle Autonomous Database et en mettant à jour le mot de passe du portefeuille dans le répertoire $DOMAIN_HOME/config/jdbc et dans les fichiers jps config sous $DOMAIN_HOME/config/fmwconfig. L'utilisation du même mot de passe pour les portefeuilles du clone principal, du clone de secours et du clone actualisable facilitera la manipulation de la configuration de la source de données sur les deux sites ; toutefois, les scripts fournis ci-dessous pourront gérer différents mots de passe. Utilisez le script fmwadb_switch_db_conn.sh pour mettre à jour le système avec un nouveau portefeuille.

    Lorsque votre système principal a été provisionné, vous avez choisi (dans les écrans de provisionnement) l'un des niveaux de service Oracle Autonomous Database. Exécutez le script fmw_change_to_tns_alias.sh avec le même niveau de service. Les niveaux de service d'un service de base de données dans Oracle Autonomous Database sont : faible, moyen, élevé, tpurgent. Voici un exemple de modification d'Oracle Fusion Middleware en alias TNS : 

    [oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))"/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
<url>jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))</url>
 
NOTICE the "low" label in g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com, that is the service flag that will allow you identify the tns alias that needs to be used
 
[oracle@soarefr-soa-0 good]$ cat $DOMAIN_HOME/config/atp/tnsnames.ora | grep low | awk -F '=' '{print $1}'
soaadb1_low
 
[oracle@soarefr-soa-0 good]$ ./fmw_change_to_tns_alias.sh soaadb1_low                                                                                          
Getting variables from current datasource ...............
An existing tns_admin property was found in /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml and will be used
Found soaadb1_low  as tns_alias
No modifications will be required in /u01/data/domains/soarefr_domain/config/atp/tnsnames.ora
*******************WILL USE THESE SETTINGS********************
**************************************************************
TNS admin:........................./u01/data/domains/soarefr_domain/config/atp
TNS alias:........................ soaadb1_low
Current connect string:............(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current jps connect string:........(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current tnsnames.ora:..............
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
**************************************************************
Taking backup of existing config...
************** Replacing DB connect information **************
Replacing jdbc url in config/jdbc files...
Replacing jdbc url in config/fmwconfig files...
Replacement complete!
 
[oracle@soarefr-soa-0 ~]$ grep url $DOMAIN_HOME/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
    <url>jdbc:oracle:thin:@soaadb1_low </url>
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$
  3. Redémarrez tous les serveurs Oracle WebLogic du domaine pour utiliser les modifications effectuées par le script.

Création d'un VCN et d'un sous-réseau dans la région secondaire

Si vous ne l'avez pas encore fait, créez un VCN dans la région de secours avec un CIDR qui n'est pas en conflit avec le CIDR de la région principale. Par exemple, si le VCN principal utilise 10.1.0.0/16, le VCN secondaire peut utiliser 10.2.0.0/16.

  1. Créez un VCN et un sous-réseau dans la région secondaire.
    Vous pouvez créer une pile cloud pour provisionner un groupe de services cloud associés.
  2. Assurez-vous que les listes de sécurité autorisent les communications appropriées entre les niveaux.

    Vérifiez les communications suivantes :

    • De l'équilibreur de charge OCI au serveur WebLogic
    • Du serveur WebLogic à la base de données
    • Du serveur WebLogic au stockage partagé

    En outre, incluez les règles requises pour autoriser les communications entre les noeuds de serveur d'administration via la passerelle de routage dynamique (DRG) une fois qu'elle a été créée.

Configuration d'un DRG entre les réseaux cloud virtuels principaux et secondaires

La configuration de la récupération après sinistre nécessite que les noeuds d'administration Oracle WebLogic Server principal et secondaire communiquent entre eux pour recevoir la configuration de domaine via des copies Oracle Cloud Infrastructure File Storage. Pour cela, vous devez créer une passerelle de routage dynamique (DRG) entre les réseaux cloud virtuels de niveau intermédiaire.

  1. Créez un DRG entre les réseaux cloud virtuels de niveau intermédiaire (middle tier).
  2. Vérifiez que le nouveau DRG apparaît sur la page Passerelles de routage dynamique du compartiment ou de la région que vous avez choisi.
    Les scripts de configuration de la récupération après sinistre vérifieront que les connexions requises peuvent être établies.
  3. Configurez les routages et les règles de sécurité appropriés dans les réseaux cloud virtuels principal et de secours pour autoriser les connexions SSH entre les niveaux intermédiaires.
  4. Vérifiez que vous pouvez établir une connexion SSH entre le noeud Oracle WebLogic Administration Server principal et le noeud Oracle WebLogic Administration Server secondaire.
    Par exemple, si 10.2.1.104 est l'adresse IP du noeud du serveur d'administration secondaire, exécutez la commande suivante à partir du noeud du serveur d'administration principal.
    [opc@soarefr-soa-0 ~]$ ssh -i KeySOAMAA.ppk opc@10.2.1.104
Last login: Wed Dec 14 16:59:15 2022 from 10.2.0.83
[opc@soarefr-soa-0 ~]$

Création d'une base de données de secours Oracle Autonomous Data Guard dans la région secondaire

Créez une base de données de secours pour Oracle Autonomous Database principal existant.

  1. Pour Oracle Autonomous Database Serverless, créez une instance Oracle Autonomous Database Serverless de secours dans la région secondaire.
    1. Dans la console OCI, cliquez sur Oracle Database dans le menu de navigation de gauche pour accéder au Oracle Autonomous Database principal.
    2. Sur la page Détails d'Autonomous Database, sous Ressources, cliquez sur Récupération après sinistre, puis sur Ajouter une base de données homologue.
    3. Utilisez les sous-réseaux VCN et private que vous avez créés précédemment.
  2. Pour Oracle Autonomous Database on Dedicated Exadata Infrastructure
    1. Dans la console OCI, accédez à la page de détails de la base de données Conteneur Autonomous et sélectionnez la ressource Associations Autonomous Data Guard dans la section Ressources.
    2. Cliquez sur Activer Autonomous Data Guard.
    3. Entrez les informations sur le cluster de machines virtuelles Autonomous homologue, le mode de protection et le choix du basculement automatique. Après avoir saisi toutes les informations nécessaires, cliquez sur Activer Autonomous Data Guard.
      Dans le cadre de ce workflow, une base de données Conteneur Autonomous de secours est créée avec toutes les bases de données autonomes de secours du cluster de machines virtuelles Autonomous sélectionné.

Préparation de la base de données Autonomous Database de secours pour la configuration de la récupération après sinistre

Cette tâche varie selon que vous utilisez l'approche Snapshot Standby ou Remote Refreshable Clone.

Pour l'approche de secours cliché, reportez-vous à la section Convert the Standby to a Snapshot Standby.

Pour l'approche Clone actualisable distant, reportez-vous à Création d'un clone actualisable distant dans la région secondaire.

Convertir la base de données de secours en base de secours cliché

A l'aide de l'approche Snapshot Standby, convertissez votre base de données autonome de secours en Snapshot Standby.

  1. Dans le menu de navigation de gauche de la console Oracle Cloud Infrastructure, cliquez sur Autonomous Database.
  2. Dans la région secondaire, sélectionnez l'instance Autonomous Database de secours.
  3. Dans la liste déroulante Actions supplémentaires, cliquez sur Convertir en base de données de secours instantanée.
  4. Si vous utilisez une infrastructure dédiée, sélectionnez Utiliser les services de base de données principale.

Remarque :

Lorsqu'une base de données de secours cliché dans une infrastructure Exadata dédiée Oracle n'est pas convertie en base de données de secours physique dans les 7 jours, elle est automatiquement convertie en base de données de secours physique.

Lorsqu'une base de données de secours de cliché dans Oracle Autonomous Database Serverless n'est pas convertie en base de données de secours physique dans les 2 jours, la base de données de secours de cliché est automatiquement convertie en base de données de secours physique.

Création d'un clone actualisable distant dans la région secondaire

A l'aide de l'approche Clone actualisable distant, créez un clone actualisable à partir de l'instance Oracle Autonomous Database Serverless principale existante dans la région distante.

  1. Créez un clone actualisable à partir de l'instance Oracle Autonomous Database Serverless principale existante.
    Placez le clone actualisable dans la région secondaire (distante) à l'intérieur du VCN et du sous-réseau privé que vous avez créé précédemment.

    Remarque :

    Vous ne pouvez pas utiliser le même nom de base de données que celui de la base de données principale car ce nom est déjà utilisé par la base de données de secours physique.
  2. Utilisez Private Endpoint Access Only pour accéder à la base de données.

    Une fois créé, le clone actualisable reste connecté et en mode lecture seule. Les systèmes Oracle WebLogic Server, Oracle SOA et Oracle Fusion Middleware ne peuvent pas être provisionnés par rapport à lui SOUS la conversion en lecture-écriture (déconnecté de la base principale).

  3. Déconnectez le clone actualisable de la base de données autonome principale et convertissez-le en mode lecture/écriture.

    Remarque :

    Le clone actualisable distant ne peut pas rester déconnecté pendant plus de 24 heures. Par exemple, la création des niveaux intermédiaires secondaires pointant vers la base de données clone actualisable distante ne peut pas prendre plus de 24 heures.
    1. Dans le menu de navigation de gauche d'Oracle Cloud Infrastructure, cliquez sur Autonomous Database.
    2. Sélectionnez le nom du clone actualisable.
    3. Sélectionnez la base de données source, puis cliquez sur Déconnecter.

Provisionner le système secondaire

Provisionnez le service Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou un autre service Oracle Cloud Infrastructure (OCI) de niveau intermédiaire qui utilise Oracle Fusion Middleware (système) pointant vers la base de données secondaire (pour l'approche de secours instantanée) ou vers le clone actualisable (pour l'approche de clone actualisable à distance).

  1. Suivez les recommandations standard de préfixe de sous-réseau, CIDR, de règles de sécurité et d'instance pour la récupération après sinistre.

    Le nom de la pile peut être différent, mais vous devez utiliser le même préfixe de nom de ressource EXACT que celui utilisé dans votre emplacement principal. Oracle recommande d'utiliser exactement la même capacité et la même configuration de calcul sur les emplacements principal et de secours pour un comportement idéal de basculement/permutation.

    Assurez-vous que la version et le niveau de patch d'Oracle WebLogic Server for OCI à provisionner dans l'emplacement secondaire correspondent à celui en cours d'exécution sur le site principal.

    Si vous avez besoin de plus de détails, reportez-vous au tableau récapitulant les options d'assistant de provisionnement pour la récupération après sinistre configurées dans la section "Provisionner WLS pour OCI sur le site secondaire" de Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery ou dans la section "Provisionner SOA Suite sur Marketplace sur le site secondaire" de SOA Suite sur Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  2. Créez le système de niveau intermédiaire secondaire en fonction du processus de provisionnement standard.
  3. Vérifiez le service Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace standard ou tout autre service Oracle Cloud Infrastructure (OCI) de niveau intermédiaire qui utilise les URL Oracle Fusion Middleware (par exemple, console, soa-infra, etc.) pour vérifier que le système est correctement créé.
  4. Une fois validés, arrêtez les processus Oracle WebLogic dans la base de données de secours : serveurs gérés, serveurs d'administration et gestionnaires de noeuds.
  5. Si vous utilisez un clone actualisable distant, vous pouvez le reconnecter à la source. Si vous utilisez la base de données de secours instantanée, vous pouvez la convertir à nouveau en base de données de secours physique.
    N'essayez pas de démarrer les processus Oracle WebLogic en mode secondaire tant que la configuration de la récupération après sinistre n'est pas terminée.

Modification des chaînes de connexion d'alias TNS du secondaire

Modifiez l'alias utilisé dans le système secondaire pour qu'il soit identique à celui du système principal.

Comme dans le système principal, vous devez utiliser un alias TNS (Transparent Network Substrate) dans tous les fichiers de source de données sous $DOMAIN_HOME/config/jdbc et dans les fichiers jps config sous $DOMAIN_HOME/config/fmwconfig. L'alias utilisé dans le système secondaire (de secours) sera le même que dans le système principal car les sources de données sont répliquées à partir du principal contenant l'alias créé précédemment.

Cette tâche varie selon que vous utilisez une approche de secours instantanée ou de clone actualisable à distance.

Modification des chaînes de connexion d'alias TNS du secondaire pour l'approche de secours instantanée

Pour l'approche de base de données de secours instantanée, les alias du fichier tnsnames.ora doivent être identiques à ceux du fichier principal (bien que les chaînes de connexion pointent vers l'adresse de la base de données de secours). Vous n'avez pas besoin de les modifier.

  1. Si les chaînes du fichier tnsnames.ora sont doubles (qui contiennent à la fois des hôtes de base de données autonomes locaux et distants), Oracle vous recommande de les modifier pour qu'elles pointent UNIQUEMENT vers la base de données locale.
    Cela peut se produire lorsque vous utilisez Oracle Autonomous Database sur une infrastructure dédiée. Vous n'avez besoin d'effectuer cette modification qu'une seule fois, car le fichier tnsnames.ora de la base de données de secours n'est pas modifié par la réplication de configuration et d'autres opérations de cycle de vie.

    Voici un exemple où les entrées du fichier tnsnames.ora sont doubles : 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…
  2. Si vous disposez de deux entrées, modifiez-les pour qu'elles pointent uniquement vers Autonomous Database local en supprimant l'ADDRESS de la base de données distante.

    Le fichier tnsnames.ora dans le fichier secondaire doit inclure uniquement l'ADDRESS de la base de données de secours. Par exemple : 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…

Modification des chaînes de connexion d'alias TNS du secondaire pour l'approche de clone actualisable à distance

Pour l'approche de clone actualisable à distance, modifiez l'alias utilisé dans le système secondaire pour qu'il soit identique à celui du système principal.

Le fichier tnsnames.ora inclus dans la création du système Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware secondaire contient un alias basé sur le nom du clone actualisable distant. Par exemple, si un clone actualisable distant est créé avec le nom soaadb1rc2, le fichier tnsnames.ora (dans le répertoire de portefeuille créé lors du provisionnement) contient l'alias suivant : soaadb1rc2_high, soaadb1rc2_low, soaadb1rc2_medium, soaadb1rc2_tp, soaadb1rc2_tpurgent. Pour simplifier la configuration, vous devez utiliser le même nom d'alias dans le fichier tnsnames.ora des systèmes principal et secondaire. Modifiez donc l'alias TNS avec lequel Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou le domaine Oracle Fusion Middleware est configuré (clone actualisable à distance) pour utiliser le même nom d'alias que le domaine principal. Vous pouvez obtenir le nom d'alias en tant qu'alias principal à partir du fichier $tns_admin/tsnames.ora. Différents alias sont créés pour différents services et tous déduiront un préfixe du nom de la base de données. Notez que vous souhaitez modifier uniquement le nom d'alias, et non les services. N'utilisez pas de recherche globale et de remplacement dans le fichier, car cela modifiera probablement également les noms de service dans les chaînes de connexion du fichier tnsnames.ora.

  • Modifiez le fichier tnsnames.ora du système secondaire pour qu'il utilise le même alias que le système principal.

    Voici un exemple de fichier tnsnames.ora pour une configuration Oracle Fusion Middleware avec Oracle Autonomous Database Serverless dans le système principal. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Voici un exemple de fichier tnsnames.ora pour une configuration Oracle Fusion Middleware avec Oracle Autonomous Database Serverless dans le secondaire avec clone actualisable. 

    oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
rcsoaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Comme il s'agit d'une opération unique, le moyen le plus simple de modifier l'alias du clone actualisable consiste à modifier le fichier. Vous pouvez modifier l'alias du niveau de service utilisé ou tous pour assurer la cohérence.

    Remarque :

    Cette opération doit être effectuée chaque fois qu'un nouveau clone actualisable est utilisé pour les tests ou les validations et qu'un nouveau portefeuille est utilisé.

    Voici un exemple de fichier tnsnames.ora pour une configuration Oracle Fusion Middleware avec Oracle Autonomous Database Serverless dans le secondaire avec clone actualisable à l'aide de l'alias du serveur principal. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

Tout comme dans le système principal, tous les fichiers de source de données sous $DOMAIN_HOME/config/jdbc et dans les fichiers de configuration JPS sous $DOMAIN_HOME/config/fmwconfig utilisent l'alias choisi. Le même niveau de service doit être choisi avec le clone actualisable distant comme dans le système principal (low, mid, high, tp ou tpurgent). Etant donné que l'alias et les sources de données sont copiés à partir du système principal, vous n'avez pas besoin d'exécuter le script fmw_change_to_tns_alias.sh dans le système secondaire. La configuration de la récupération après sinistre gérera les remplacements requis.

Si vous disposez d'alias supplémentaires pour pointer vers d'autres bases de données dans le fichier tnsnames.ora principal, ajoutez-les en conséquence dans le fichier tnsnames.ora du système secondaire.

Mise à jour des alias de nom d'hôte et de l'adresse frontale dans les niveaux intermédiaire principal et de secours

La configuration de domaine WebLogic dans le domaine secondaire sera une copie du domaine WebLogic principal une fois la configuration de la récupération après sinistre terminée. Par conséquent, les noms d'hôte utilisés comme adresses d'écoute par les serveurs Oracle WebLogic principaux (qui sont les noms d'hôte des hôtes principaux) doivent être valides dans l'emplacement secondaire, mais ils doivent être mis en correspondance avec les adresses IP secondaires.

La même adresse frontale doit être utilisée à la fois dans la base principale et dans la base de données de secours. Pendant le fonctionnement normal, ce nom d'hôte frontal est mis en correspondance avec l'adresse IP de l'équilibreur de charge Oracle Cloud Infrastructure (OCI) principal. En cas d'exécution à partir d'un serveur secondaire (après une permutation ou un basculement), ce nom d'hôte frontal est mis en correspondance avec l'adresse IP de l'équilibreur de charge OCI secondaire.

Remarque :

Le fichier /etc/hosts des hôtes de niveau intermédiaire ne doit pas être modifié en cas de permutation ou de basculement. Les hôtes de niveau intermédiaire résolvent toujours le nom frontal virtuel avec son adresse IP frontale. La mise à jour DNS nécessaire au cours des procédures de permutation et de basculement est effectuée dans les fichiers DNS ou hôte utilisés par les clients.

Vous pouvez implémenter cette définition d'alias d'hôte de l'une des manières suivantes :

  • Ajoutez les noms d'hôte en tant qu'alias aux fichiers /etc/hosts des instances de calcul Oracle WebLogic Server for OCI.
  • Utiliser une vue DNS privée dans le VCN OCI secondaire

Utiliser les fichiers /etc/hosts

Les noms d'hôte utilisés par le serveur Oracle WebLogic Server principal sont ajoutés aux fichiers /etc/hosts des hôtes Oracle WebLogic Server secondaires, pointant vers les adresses IP des hôtes Oracle WebLogic Server secondaires. Ce mode est valide lorsque le serveur DNS est le même sur les sites Oracle Cloud Infrastructure (OCI) principaux et secondaires, ainsi que lorsque des serveurs DNS séparés sont utilisés sur les sites principal et secondaire. Les entrées du fichier /etc/hosts sont prioritaires sur la résolution DNS, car il s'agit de la priorité définie prête à l'emploi dans la directive "hôtes" du fichier /etc/nsswitch.conf.
  1. Modifiez le fichier /etc/oci-hostname.conf de chaque instance de calcul WebLogic Server et définissez la propriété PRESERVE_HOSTINFO=3 pour conserver les entrées /etc/hosts lors des réinitialisations d'instance.
  2. Utilisez la commande hostname --fqdn pour identifier les noms d'hôte complets des instances de calcul OCI WebLogic Server.
  3. Ajoutez les entrées suivantes au fichier /etc/hosts des instances de calcul de niveau intermédiaire :
    #################################
# ALIASES on OCI for DR
#################################
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname   ALIAS_OF_APPHOST1 
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname   ALIAS_OF_APPHOST2 
#################################
# Frontend name 
#################################
IP_OF_LBR  frontend_name_fqdn
    Voici un exemple du fichier /etc/hosts des hôtes Oracle WebLogic Server principaux :
    # Aliases for DR in primary region
10.0.2.10 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0 
10.0.2.11 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-1

# Front-end virtual name to primary LBR IP
111.111.111.111 mywebapps.mycompany.com

    Voici un exemple de fichier /etc/hosts dans l'instance de calcul secondaire OCI WebLogic Server.

    Remarque :

    Les noms d'hôte principaux sont ajoutés en tant qu'alias des noeuds secondaires et ce nom virtuel frontal pointe vers l'adresse IP de l'équilibreur de charge secondaire :

    # Aliases for DR in secondary region
10.1.2.5 wlsociprefix-wls-0.subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-0 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0
10.1.2.4 wlsociprefix-wls-1. subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-1 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0

# Front-end virtual name to secondary LBRIP
222.222.222.222 mywebapps.example.com

Utilisation du système de noms de domaine (DNS) OCI

Les noms d'hôte utilisés par les hôtes Oracle WebLogic Server principaux sont ajoutés au résolveur DNS utilisé par le VCN des serveurs de niveau intermédiaire secondaires, pointant vers les adresses IP des hôtes Oracle WebLogic Server secondaires. Ce mode est valide lorsque des serveurs DNS distincts sont utilisés sur les sites Oracle Cloud Infrastructure (OCI) principaux et secondaires. Sinon, cela peut entraîner des conflits dans la résolution de noms. Le serveur de chaque site doit résoudre ces noms avec leurs 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 à tous les hôtes Oracle WebLogic Server /etc/hosts.

Les étapes suivantes permettent de créer la vue privée dans le VCN secondaire et de résoudre les noms d'hôte utilisés par le serveur principal avec les adresses IP secondaires :

  1. Dans la console OCI, accédez à la région secondaire et créez la vue privée pour résoudre les noms des hôtes PRIMARY avec les adresses IP SECONDARY.
    1. Cliquez sur Fonctions de réseau, Gestion DNS, Vues privées, puis Créer une vue privée.
      Par exemple, vous pouvez nommer la vue privée : PRIMARY_HOSTNAMES_PRIVATE_VIEW
    2. Cliquez sur Créer une zone dans la vue privée.
      Pour le nom de zone, vous devez utiliser le domaine complet des hôtes. Par exemple : subnetpri.vcnpri.oraclevcn.com
    3. Ajoutez les noms d'hôte principaux à cette zone (nom abrégé), mais résolus avec l'adresse IP des hôtes Oracle WebLogic Server secondaires.
    4. Cliquez sur Publier les modifications.
  2. Ajoutez la vue privée au résolveur VCN secondaire.
    1. Cliquez sur la ressource Résolveur DNS dans le VCN.
    2. Ajoutez la vue privée DNS créée précédemment.
      Les hôtes du VCN secondaire résoudront les noms d'hôte utilisés par les hôtes Oracle WebLogic Server principaux à l'aide de la vue privée.
  3. Validez les hôtes SECONDARY de résolution en effectuant les opérations ping et nslookup sur les noms d'hôte.
    Ils doivent être résolus avec les adresses IP SECONDARY équivalentes.

    Remarque :

    Vous pouvez trouver du code Terraform pour créer cette vue et ces enregistrements privés OCI dans GitHub.

Configuration du système secondaire

Pour configurer le système en tant que système secondaire, vous devez copier la configuration du domaine WebLogic Server du domaine principal vers le domaine système secondaire WebLogic Server, Oracle SOA Suite ou Oracle Fusion Middleware.
La configuration de la récupération après sinistre remplace tous les domaines secondaires, à l'exception des répertoires et fichiers spécifiques qui doivent rester localement valides. Ces répertoires sont explicitement exclus par les scripts. En outre, le script remplace les fichiers de source de données de sorte que le secondaire utilise les mêmes noms de schéma de base de données que dans le schéma principal, mais avec le jdbc url existant pointant vers la base de données locale (clone actualisable pendant la configuration de la récupération après sinistre et le clone de secours en préparation de la permutation) avec les portefeuilles requis.
  1. Exécutez le script fmwadb_dr_prim.sh dans le noeud d'administration du serveur WebLogic principal.
    Le script vérifie la connectivité entre les noeuds du serveur d'administration WebLogic Server via la passerelle de routage dynamique et copie le domaine dans le répertoire intermédiaire d'un montage Oracle Cloud Infrastructure File Storage dans la région secondaire.

    Utilisez les paramètres suivants :

    • REMOTE_ADMIN_NODE_IP

      Adresse IP du noeud secondaire du serveur d'administration WebLogic Server.

      Cette adresse IP doit être accessible à partir de cet hôte (noeud principal du serveur d'administration Oracle WebLogic Server).

      Il est recommandé d'utiliser la passerelle de routage dynamique pour interconnecter les sites principal et secondaire, ce qui vous permet de fournir l'adresse IP privée.

    • REMOTE_SSH_PRIV_KEYFILE

      Fichier de clés SSH privé permettant de se connecter au noeud de serveur d'administration Oracle WebLogic distant.

    • FSS_MOUNT

      Répertoire monté OCI File Storage utilisé pour préparer la copie de la configuration de domaine du serveur WebLogic. 

    ./fmwadb_dr_prim.sh [REMOTE_ADMIN_NODE_IP] [REMOTE_SSH_PRIV_KEYFILE] [FSS_MOUNT]
    Voici un exemple de commande et de sortie :
    [oracle@soarefr-soa-0 ~]$ ./fmwadbs_dr_prim.sh '10.2.1.104' '/u01/soacs/dbfs/share/KeyWithoutPassPhraseSOAMAA.ppk' /u01/soacs/dbfs/share/
 Checking ssh connectivity to remote WebLogic Administration server node....
    Connectivity to 10.2.1.104 is OK
    REMOTE_ADMIN_HOSTNAME...... soarefr-soa-0.sub09051735411.soaadbvcnstby.oraclevcn.com
 Checking local FSS mount folder readiness........
     The FSS is expected to be mounted in /u01/soacs/dbfs/share
     The folder for the copy of the domain is expected to be /u01/soacs/dbfs/share/domain_config_copy
     Local folder /u01/soacs/dbfs/share/domain_config_copy exists.
 Checking remote FSS mount folder readiness........
     Remote folder 10.2.1.104:/u01/soacs/dbfs/share/domain_config_copy exists.
 
----------- Rsyncing from local domain to local FSS folder ---------------
 
Local rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_local_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
 
----------- Local rsync complete -----------------------------------------
 
----------- Rsyncing from local FSS folder to remote site... --------------
Remote rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_remote_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
  2. Une fois l'exécution du script fmwadb_dr_prim.sh terminée, si ce n'est déjà fait, arrêtez tous les systèmes WebLogic Server et les gestionnaires de noeuds du système secondaire.
  3. Connectez-vous au noeud d'administration WebLogic Server du secondaire et exécutez le script fmwadb_dr_stby.sh.

    Le script copie le domaine du serveur WebLogic à partir du répertoire intermédiaire d'un montage OCI File Storage vers le répertoire de domaine secondaire du serveur WebLogic et remplace les entrées de portefeuille et de mot de passe requises. Le portefeuille à fournir est celui du clone actualisable afin que le secondaire puisse être validé après la configuration initiale de la récupération après sinistre.

    Utilisez les paramètres suivants :

    • WALLET_DIR

      Répertoire d'un portefeuille Oracle Autonomous Database décompressé. Noeud du serveur d'administration WebLogic Server.

      Ce répertoire doit contenir au moins les fichiers tnsnames.ora, keystore.jks et truststore.jks.

      Si vous utilisez l'approche de secours instantanée, il s'agit simplement du dossier tnsadmin.

    • WALLET_PASSWORD

      Mot de passe fourni lors du téléchargement du portefeuille à partir de l'interface utilisateur OCI d'Oracle Autonomous Database Serverless.

      Si le portefeuille est le portefeuille initial créé par le système WebLogic Server, Oracle SOA Suite ou Oracle Fusion Middleware lors du provisionnement. Vous pouvez l'obtenir à l'aide de la commande suivante :

      Oracle SOA :
      python /opt/scripts/atp_db_util.py generate-atp-wallet-password
      Oracle WebLogic Server:
      python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    • FSS_MOUNT

      Répertoire monté OCI File Storage utilisé pour préparer la configuration de domaine du serveur WebLogic. 

    ./fmwadb_dr_stby.sh [WALLET_DIR] [WALLET_PASSWORD] [FSS_MOUNT]
    Voici un exemple d'exécution et de sortie de la commande :
    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_dr_stby.sh /u01/data/domains/wsladbs2_domain/config/atpwallet/  7f3e3ed8ee7921fed058b481298eca55 /u01/shared/
Backing up current domain...
Backup created at /u01/data/domains/wsladbs2_domain/ /u01/data/domains/wsladbs2_domain_backup_11_42_19-26-10-22
Rsyncing from FSS  mount to domain dir...
 Syncing the Weblogic Administration server node...
Rsync complete!
Switching config to /u01/data/domains/wsladbs2_domain/config/atpwallet/
The password provided for the wallet is valid. Proceeding...
Gathering Data Soure information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_11_42_33-26-10-22
Replacing values in datasources...
Replacement complete!
  4. Exécutez le script fmwadb_dr_stby.sh dans les autres noeuds de serveur géré WebLogic Server de la région secondaire.
  5. Assurez-vous que la base de données de secours est accessible en mode lecture/écriture.
    • Si vous utilisez l'approche de secours instantanée, assurez-vous que la base de données de secours est convertie en base de données de secours instantanée, de sorte qu'elle est accessible en mode lecture/écriture.
    • Si vous utilisez l'approche de clone actualisable à distance, assurez-vous qu'il est déconnecté de la source, de sorte qu'il est accessible en mode lecture-écriture.
  6. Démarrez le gestionnaire de noeuds et le serveur d'administration Oracle WebLogic Administration Server dans le secondaire. Accédez à la console et démarrez les serveurs gérés WebLogic Server dans le domaine.
  7. Vérifiez que les applications et déploiements existants dans la base principale sont également disponibles dans la base secondaire.
  8. Arrêtez les serveurs WebLogic en mode secondaire.
  9. Convertissez la base de données de secours en base de données de secours physique ou reconnectez le clone actualisable.

    • Si vous utilisez l'approche de secours cliché, convertissez la base de données de secours en base de données de secours physique.

    • Si vous utilisez le clone actualisable distant, reconnectez le clone actualisable. Rappel : le clone actualisable ne peut pas rester déconnecté de la base principale pendant plus de 24 heures.

Laisser le système prêt pour la permutation

Une fois le système secondaire configuré et validé avec un clone actualisable, laissez le système prêt pour la permutation en pointant l'alias TNS vers l'instance Oracle Autonomous Database Serverless de secours.

Remarque :

Cette tâche n'est nécessaire que lorsque le système secondaire est configuré et validé avec un clone actualisable à distance.

Téléchargez le portefeuille de la base de données de secours à partir de l'interface utilisateur de la base de données secondaire. Evitez les chaînes de connexion doubles (hôtes principal et de secours) dans les cas de reconfiguration dynamique distante car elles provoquent des tentatives inutiles.

  1. Connectez-vous à l'interface utilisateur Oracle Autonomous Database Serverless de la base de données de secours.
  2. Cliquez sur Autonomous Database, sélectionnez autonomous_db_name, cliquez sur Connexion de base de données, puis sur Télécharger le portefeuille.
  3. Si le portefeuille contient des chaînes doubles pointant vers la base de données principale, enlevez l'entrée de la description principale du fichier tnsnames.ora afin que la chaîne de connexion pointe UNIQUEMENT vers la base de données locale dans la région secondaire.

    Voici un exemple de modification du fichier tnsnames.ora : 

    soaadb1_high = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_low = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_medium = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tp = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tpurgent = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))

SHOULD BE

soaadb1_high = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))) 
soaadb1_low = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
  4. Copiez le portefeuille dans un dossier temporaire du noeud de serveur d'administration WebLogic Server de la région secondaire et accédez au répertoire.
    [oracle@wsladbs2-wls-0 scripts]$ cd /tmp
[oracle@wsladbs2-wls-0 tmp]$ mkdir wallet-stby
[oracle@wsladbs2-wls-0 tmp]$ cd wallet-stby/
  5. Décompressez le portefeuille.
    [oracle@wsladbs2-wls-0 wallet-stby]$ unzip /tmp/Wallet_soaadb1-standby.zip
Archive:  ../Wallet_soaadb1-standby.zip
  inflating: ewallet.pem
  inflating: README
  inflating: cwallet.sso
  inflating: tnsnames.ora
  inflating: truststore.jks
  inflating: ojdbc.properties
  inflating: sqlnet.ora
  inflating: ewallet.p12
  inflating: keystore.jks
  6. Exécutez le script fmwadb_switch_db_conn.sh pour laisser le niveau intermédiaire prêt avec le portefeuille secondaire et la chaîne de connexion.

    Voici un exemple de script exécuté pour pointer vers le portefeuille Oracle Autonomous Database Serverless de secours : 

    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_switch_db_conn.sh /tmp/wallet-stby/ wallet_password
The password provided for the wallet is valid. Proceeding...
Gathering Data Source information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_10_38_32-27-10-22
Replacing values in datasources...
Replacement complete!

Configurer la réplication de configuration continue

Lorsque le cycle de vie du système implique des mises à jour gratuites du système de fichiers de domaine, vous pouvez utiliser un script pour automatiser le processus de réplication de configuration. Le script fmwadb_config_replica.sh réplique régulièrement les modifications via le répertoire intermédiaire Oracle Cloud Infrastructure File Storage (OCI File Storage).

La configuration est prête (préparée) pour une permutation après chaque réplication.

Lorsque vous utilisez le clone actualisable à distance, la configuration répliquée est supposée "adaptée" à la base de données de secours physique (et non au clone actualisable). Si vous avez besoin d'une validation ou d'un test à l'aide de clones actualisables, vous pouvez modifier la configuration du domaine de secours pour qu'elle pointe vers le clone actualisable.

Vous devez exécuter le script fmwadb_config_replica.sh dans les noeuds d'administration du serveur WebLogic (du serveur principal et du serveur de secours) pour répliquer la configuration. En général, ce script est planifié avec un travail cron pour répliquer la configuration entre un serveur WebLogic, un serveur Oracle SOA Suite ou un système Oracle Fusion Middleware de secours sur le système Oracle Autonomous Database à intervalles réguliers. Ce script vérifie le rôle actuel de la base de données locale pour déterminer si elle est en cours d'exécution sur le site principal ou de secours.

  • Lorsque le script est exécuté sur le site PRIMARY, il copie la configuration du domaine du domaine principal vers le dossier d'assistance local (FSS), puis vers le dossier d'assistance du site secondaire (via rsync).
  • Lorsque le script est exécuté sur le site STANDBY, il copie la configuration du domaine à partir du dossier d'assistance secondaire (OCI File Storage) vers le domaine secondaire et effectue les remplacements nécessaires pour que les sources de données fonctionnent avec la base de données locale.

Vous devez collecter différents paramètres de la console OCI et crypter le mot de passe permettant d'accéder aux portefeuilles Oracle Autonomous Database pour des raisons de sécurité.

Voici une description des variables utilisées dans le script et comment les obtenir :

  • REMOTE_WLSADMIN_NODE_IP

    Adresse IP du noeud de serveur d'administration WebLogic Server homologue et distant.

    Il s'agit de l'adresse IP de l'hôte du noeud dans le serveur d'administration WebLogic Server du site homologue. Il doit être accessible à partir du noeud local. Il est recommandé de se connecter à l'adresse IP privée distante du noeud à l'aide d'une passerelle de routage dynamique.

  • REMOTE_SSH_PRIV_KEYFILE

    Fichier de clés SSH privé permettant de se connecter au noeud de serveur d'administration Oracle WebLogic distant.

  • TENANCY_OCID

    OCID de la location dans laquelle réside Oracle Autonomous Database. Vous pouvez obtenir l'OCID à partir de l'interface utilisateur Oracle Cloud Infrastructure (OCI).

  • USER_OCID

    OCID de l'utilisateur propriétaire de l'instance de base de données autonome. Vous pouvez trouver l'OCID dans l'interface utilisateur OCI.

  • PRIVATE_KEY

    Chemin de la clé de format PEM privé pour cet utilisateur.

  • LOCAL_ADB_OCID

    OCID d'Oracle Autonomous Database en cours d'inspection. Vous pouvez trouver l'OCID dans l'écran Oracle Autonomous Database de la console OCI.

  • WALLET_DIR

    Répertoire du portefeuille Oracle Autonomous Database local (décompressez le portefeuille téléchargé à partir de la console OCI). Ce répertoire doit contenir au moins les fichiers tnsnames.ora, keystore.jks et truststore.jks. Lorsque vous utilisez l'approche de secours cliché, il s'agit du dossier tnsadmin

  • ENC_WALLET_PASSWORD

    Incarnation WLS ENCRYPTED du mot de passe fourni lors du téléchargement du portefeuille à partir de l'interface utilisateur OCI d'Oracle Autonomous Database.

    Si le portefeuille est le portefeuille initial créé par le serveur WebLogic, Oracle SOA Suite ou Oracle Fusion Middleware lors du provisionnement du serveur WebLogic, vous pouvez utiliser les commandes suivantes pour obtenir le mot de passe :

    Pour WebLogic :
    [oracle@wsladbs2-wls-1 ~]$ python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Pour SOA :
    [oracle@soarefr-soa-0 ~]$ python /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Pour crypter le mot de passe, que celui fourni dans la console OCI ou celui utilisé lors du provisionnement, vous pouvez utiliser le script fmw_enc_pwd.sh.
    ./fmw_enc_pwd.sh UNENC_WALLET_PASSWORD

    Utilisez la chaîne obtenue pour la variable ENC_WALLET_PASSWORD.

  • FSS_MOUNT

    Répertoire monté OCI File Storage qui sera utilisé pour préparer la configuration de domaine du serveur WebLogic.

Une fois que vous avez collecté les informations relatives aux variables, procédez comme suit pour copier et personnaliser les scripts de votre environnement :

  1. Chiffrez le mot de passe permettant d'accéder aux portefeuilles Oracle Autonomous Database pour des raisons de sécurité.
  2. Copiez le script sur le site principal, puis modifiez le script en complétant les variables requises pour le site principal.
    Vous trouverez ci-dessus la description des variables utilisées dans le script.
  3. Copiez le script sur le site de secours, puis modifiez le script contenant les variables requises pour le site de secours.
    Vous trouverez ci-dessus la description des variables utilisées dans le script.
  4. Une fois personnalisé pour la région EACH (vous devez fournir l'OCID de base de données LOCAL pour chaque région), effectuez les tâches suivantes :
    1. Exécutez le script dans l'hôte d'administration Oracle WebLogic en tant qu'hôte principal.
    2. Exécutez le script dans l'hôte d'administration Oracle WebLogic de la région secondaire.
  5. Ajoutez le script à un travail cron dans chaque région.