Vérifier la configuration

Une fois la configuration de récupération après sinistre terminée, validez immédiatement que la configuration est correcte en effectuant une permutation complète ou en ouvrant le site secondaire pour validation. L'ouverture du site secondaire pour validation n'aura aucune incidence sur le système en cours d'exécution dans le site principal.

Ouvrir le secondaire pour validation

Vous pouvez valider le site de secours sans effectuer de permutation complète en convertissant la base de données de secours en base de secours instantanée. Cela permet de démarrer les serveurs du serveur WebLogic secondaire dans le site de secours et de vérifier le système secondaire. Toute modification effectuée dans la base de données du site de secours alors qu'elle est en mode de secours instantané sera abandonnée une fois qu'elle sera de nouveau convertie en base de secours physique. Les données principales ne sont pas touchées par les validations de site secondaire.

Note :

Cette opération doit être effectuée avec prudence : s'il existe des messages JMS en attente dans la base de données lorsqu'elle est convertie en instantané, les serveurs du site de secours les traitent au démarrage. Vérifiez qu'il n'y a aucune action en attente dans la base principale lors de la conversion en base de secours instantanée.

En tant qu'utilisateur oracle, utilisez le courtier Oracle Data Guard dans l'hôte de la base de données principale et convertissez la base de données secondaire en base de secours instantanée.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Utilisez la commande show configuration pour vérifier que la conversion a été effectuée correctement.
S'ils ne sont pas déjà activés, démarrez les systèmes Oracle HTTP Server dans le site secondaire.
Démarrez le serveur d'administration dans le site secondaire.
Démarrez les serveurs gérés secondaires dans le site secondaire.
Utilisez la console ou les scripts WebLogic pour démarrer les serveurs gérés secondaires.
Validez le site secondaire.

Comme il ne s'agit pas d'une permutation et que le site principal est toujours actif, le nom frontal virtuel sera résolu à l'adresse IP de l'équilibreur de charge du site principal, de sorte que tout accès au navigateur sera, par défaut, redirigé vers le site principal actif.

Pour accéder directement aux applications de serveur WebLogic du site secondaire, vous devez mettre à jour le fichier /etc/hosts dans un client contrôlé (par exemple, un ordinateur portatif), régler le nom frontal virtuel à résoudre à l'adresse IP de l'équilibreur de charge frontal du site secondaire et exécuter toute validation à partir de ce client.

Note :
Vérifiez que le client utilisé pour les validations n'accède pas au système au moyen d'un mandataire HTTP, car le mandataire HTTP peut continuer à résoudre le nom frontal virtuel avec l'adresse IP de l'équilibreur de charge du site principal, quel que soit le nom figurant dans /etc/hosts du client.

Les clients non Linux peuvent nécessiter une réinitialisation de leur cache DNS local avant qu'un navigateur ne résolve l'adresse IP à l'aide de l'entrée de fichier hôte personnalisée.

Une fois le site secondaire validé, passez à l'étape suivante pour le rétablir au rôle de base de secours.

Note :
La validation du site secondaire peut prendre du temps.
Arrêtez les serveurs gérés et les serveurs d'administration du site secondaire.
Utilisez la console WebLogic secondaire pour arrêter les serveurs gérés et le serveur d'administration du site secondaire.
En tant qu'utilisateur oracle, utilisez le courtier Oracle Data Guard sur l'hôte de base de données principal et convertissez à nouveau la base de données secondaire en base de secours physique.
Vous aurez besoin de votre mot de passe système et du nom unique de votre base de données principale.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Utilisez show configuration pour vérifier la conversion.
Rétablir les fichiers /etc/hosts mis à jour.
Si vous avez mis à jour des fichiers /etc/hosts dans un client pour qu'ils pointent vers le site secondaire aux fins de validation, rétablissez-les de sorte que le nom frontal virtuel pointe de nouveau vers l'adresse IP frontale principale.

Effectuer une permutation

Une permutation est une opération planifiée où un administrateur rétablit les rôles des deux sites. Après une permutation, le système principal devient secondaire et le système secondaire devient principal. L'exécution d'une permutation entraînera un temps d'arrêt sur le site principal.

Avant d'effectuer une permutation dans une configuration DR hybride de serveur WebLogic, propagez toutes les modifications de configuration en attente. Assurez-vous qu'aucune modification répliquée n'est en attente pour le site secondaire.

Désactivez toute réplication programmée pendant la permutation, car elle peut échouer et interférer avec l'opération de permutation elle-même.
Arrêtez les systèmes Oracle HTTP Server dans le site principal.
Arrêtez les serveurs du site principal.
Utilisez la console ou les scripts du serveur d'administration WebLogic pour arrêter les serveurs WebLogic dans le site principal.

Note :
Le serveur d'administration du site principal peut rester actif pendant la permutation. Toutefois, il est recommandé de l'arrêter lorsque le site est en mode veille, car il est prévu que la configuration du domaine dans le site de secours sera remplacée par la configuration principale au cours du cycle de vie. Si le serveur d'administration est opérationnel pendant que cela se produit, il s'exécutera avec une configuration obsolète.
Permutez la permutation avec le nom DNS frontal.

Effectuez la poussée de DNS requise sur le serveur DNS hébergeant les noms utilisés par le système ou modifiez la résolution de l'hôte de fichier dans les clients pour pointer le nom virtuel frontal du système vers l'adresse IP publique utilisée par l'équilibreur de charge sur le site secondaire.

Pour les scénarios où le DNS est utilisé pour la résolution frontale externe (comme le DNS OCI ou le DNS commercial), vous pouvez utiliser une API pour pousser la modification. Pour voir un exemple qui pousse cette modification dans un DNS OCI, allez à GitHub, par exemple, scripts.

Notez que la valeur de durée de vie de l'entrée DNS aura une incidence sur l'OTR de la permutation : si la durée de vie est élevée (par exemple, 20 min), la modification du DNS prendra ce temps pour être effective dans les clients. L'utilisation de valeurs de durée de vie inférieures accélérera cette opération. Toutefois, cela peut entraîner des frais généraux, car les clients accèderont au DNS plus fréquemment au lieu d'utiliser des noms mis en cache. Une bonne approche consiste à régler la durée de vie à une valeur faible temporairement (par exemple, 1 minute), avant la modification du DNS. Ensuite, effectuez la modification et une fois la procédure de permutation terminée, rétablissez la durée de vie à sa valeur initiale.
En tant qu'utilisateur oracle, utilisez le courtier Oracle Data Guard dans l'hôte de la base de données principale pour effectuer la permutation de base de données.
Vous aurez besoin de votre mot de passe système et du nom unique de votre base de données principale.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
S'ils ne sont pas déjà opérationnels, démarrez les systèmes Oracle HTTP Server dans le site secondaire (nouveau principal).
Démarrez le serveur d'administration dans le site secondaire (nouveau serveur principal) ou redémarrez le serveur s'il a déjà été démarré.
Le démarrage du serveur d'administration permet la prise en compte des modifications de configuration qui ont été répliquées alors qu'il s'agissait d'une base de secours.
Démarrez les serveurs gérés secondaires dans le site secondaire (nouveau serveur principal).
Utilisez la console ou les scripts WebLogic pour démarrer les serveurs gérés secondaires.