Vérification de la configuration

Une fois la configuration DR terminée, vérifiez 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'a aucune incidence sur le système exécuté 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 données de secours instantanée. Cela permet aux serveurs WebLogic Server secondaires d'être démarrés sur 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é est supprimée une fois qu'elle est de nouveau convertie en base de secours physique. Les données principales ne sont pas affectées par les validations de site secondaire.

Remarque :

Cette opération doit être effectuée avec précaution : si la base de données contient des messages JMS en attente lors de la conversion en cliché, les serveurs du site de secours les traiteront au démarrage. Vérifiez qu'aucune action n'est en attente dans la base principale lors de la conversion en base de secours instantanée.

En tant qu'utilisateur oracle, utilisez le broker Oracle Data Guard dans l'hôte de base de données principal et convertissez le secondaire en base de données 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à en fonctionnement, démarrez les systèmes Oracle HTTP Server sur le site secondaire.
Démarrez le serveur d'administration sur le site secondaire.
Démarrez les serveurs gérés secondaires sur 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 est résolu en adresse IP d'équilibreur de charge du site principal. Par conséquent, tout accès au navigateur est, par défaut, redirigé vers le site principal actif.

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

Remarque :
Vérifiez que le client utilisé pour les validations n'accède pas au système via un proxy HTTP, car le proxy 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 le fichier /etc/hosts du client.

Les clients non Linux peuvent nécessiter une réinitialisation de leur cache DNS local pour qu'un navigateur puisse résoudre 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 rétablir le rôle de secours.

Remarque :
La validation du site secondaire peut prendre du temps.
Arrêtez les serveurs gérés et les serveurs d'administration sur le site secondaire.
Utilisez la console WebLogic secondaire pour arrêter les serveurs gérés et le serveur d'administration sur le site secondaire.
En tant qu'utilisateur oracle, utilisez Oracle Data Guard Broker sur l'hôte de la base de données principale et convertissez à nouveau le secondaire en base de données 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établissez 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 à des fins de validation, rétablissez l'état précédent afin que le nom frontal virtuel pointe à nouveau vers l'adresse IP principale.

Réalisation d'une permutation

Une permutation est une opération planifiée au cours de laquelle 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îne un temps d'inactivité sur le site principal.

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

Désactivez toute réplication planifié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 sur le site principal.
Arrêtez les serveurs sur le site principal.
Utilisez la console ou les scripts du serveur d'administration WebLogic pour arrêter les serveurs WebLogic sur le site principal.

Remarque :
Le serveur d'administration du site principal peut rester en service pendant la permutation. Toutefois, il est recommandé de l'arrêter lorsque le site a le rôle de site de secours car la configuration de domaine du site de secours doit être remplacée par la configuration principale au cours du cycle de vie. Si le serveur d'administration est en service pendant cette opération, il s'exécutera avec une configuration obsolète.
Permutez le nom DNS frontal.

Effectuez la propagation DNS requise dans le serveur DNS hébergeant les noms utilisés par le système ou modifiez la résolution d'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.

Dans les cas où le DNS est utilisé pour la résolution frontale externe (telle qu'OCI DNS ou DNS commercial), vous pouvez utiliser une API pour propager la modification. Pour voir un exemple qui propage cette modification dans un DNS OCI, accédez à GitHub pour obtenir des exemples de scripts.

Notez que la valeur de durée de vie de l'entrée DNS affectera le RTO de la commutation : si la durée de vie est élevée (par exemple, 20 min), la modification DNS prendra ce temps pour entrer en vigueur dans les clients. Si vous utilisez des valeurs de durée de vie inférieures, cela sera plus rapide. Toutefois, cela peut entraîner une surcharge car les clients toucheront le DNS plus fréquemment au lieu d'utiliser des noms mis en cache. Une bonne approche consiste à définir temporairement la durée de vie sur une valeur faible (par exemple, 1 min), avant la modification du DNS. Effectuez ensuite la modification et, une fois la procédure de permutation terminée, rétablissez la durée de vie initiale.
En tant qu'utilisateur oracle, utilisez le broker Oracle Data Guard sur l'hôte de la base de données principale pour effectuer la permutation de la 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à en fonctionnement, démarrez les systèmes Oracle HTTP Server sur le site secondaire (nouveau serveur principal).
Démarrez le serveur d'administration sur le site secondaire (nouveau serveur principal) ou redémarrez le serveur s'il était déjà démarré.
Le démarrage du serveur d'administration permet l'application des modifications de configuration répliquées alors qu'il s'agissait d'une base de secours.
Démarrez les serveurs gérés secondaires sur le site secondaire (nouveau serveur principal).
Utilisez la console ou les scripts WebLogic pour démarrer les serveurs gérés secondaires.