Tâches de cycle

La maintenance régulière du cycle de vie est nécessaire pour que le site secondaire reste synchronisé avec le site principal. Tout au long du cycle de vie, vous serez en mesure d'effectuer une permutation planifiée pour changer les rôles des sites principal et secondaire et répondre à des opérations inattendues ou imprévues.

A propos de la réplication de configuration

Une réplication initiale du contenu résidant dans les systèmes de fichiers a été effectuée lors de la configuration de la reconfiguration dynamique. Vous devez répéter régulièrement la réplication du système de fichiers pour maintenir le site secondaire à jour avec le site principal.

Vous pouvez utiliser les mêmes scripts que vous avez créés lors de la configuration de la récupération après sinistre, Répliquer les artefacts du système de fichiers vers OCI, et planifier la réplique des systèmes de fichiers en tenant compte des points suivants pour chaque artefact :

Réplication des répertoires de base Oracle au cours du cycle de vie
Il s'agit d'un artefact statique. Il ne change pas fréquemment, il n'est donc pas nécessaire de le répliquer régulièrement. Ce n'est que lorsque vous effectuez une modification dans le répertoire de base Oracle (par exemple, une activité d'application de patches) que vous devez la répliquer.
Réplication de la configuration partagée du domaine WebLogic pendant le cycle de vie
Il s'agit d'un artefact dynamique. Il contient notamment ASERVER_HOME, qui est la source de vérité de la configuration de domaine du serveur WebLogic, et APPLICATION_HOME, qui est mis à jour chaque fois qu'une application est déployée, non déployée, mise à jour, etc.

Cette configuration partagée de domaine WebLogic devrait changer fréquemment. Planifiez une réplique régulière de cet artefact, qui doit être plus ou moins fréquente selon la fréquence des modifications de configuration dans votre système. Une autre approche contrôlée consiste à effectuer une réplique chaque fois que vous modifiez la configuration de la base de données principale.
Réplication de la configuration privée du domaine WebLogic pendant le cycle de vie
Il s'agit également d'un artefact dynamique. Il contient les éléments MSERVER_HOME et NM_HOME. Il n'est pas prévu que le répertoire de base nodemanager soit fréquemment mis à jour après la configuration initiale. Le contenu du fichier MSERVER_HOME change aussi fréquemment que le fichier ASERVER_HOME car il contient le dossier de domaine utilisé par les serveurs gérés. Toutefois, la plupart de son contenu (ASERVER_HOME/config) est actualisé et téléchargé à partir de AdminServer lorsque les serveurs gérés démarrent et lorsque les modifications de configuration sont appliquées à l'aide de l'outil de script WebLogic (WLST) ou de la console d'administration Oracle WebLogic Server. Il n'est pas aussi important de répliquer cet artefact aussi fréquemment que la configuration partagée. Il est obligatoire de répliquer cette opération uniquement lorsque des modifications sont apportées à d'autres dossiers dans MSERVER_HOME (par exemple, une modification dans le dossier MSERVER_HOME/bin).
Réplication du dossier d'exécution partagé
Si vous stockez un artefact d'exécution dans ce dossier, planifiez la réplique sur De secours, en fonction des besoins de votre entreprise.

Au lieu d'utiliser le système de fichiers Oracle Cloud Infrastructure File Storage et de répliquer avec rsync, vous pouvez utiliser un montage DBFS (Oracle Database File System) pour le contenu d'exécution partagé. De cette façon, le contenu réside dans la base de données et est automatiquement répliqué vers le secondaire avec la réplique Oracle Data Guard sous-jacente. Pour plus d'informations sur l'utilisation de DBFS, reportez-vous à A propos d'Oracle Database File System dans En savoir plus.

Le tableau suivant récapitule les recommandations pour la réplication d'artefacts de système de fichiers au cours du cycle de vie.

Artefact	Contient	Recommandation
Répertoires de base Oracle	Répertoire de base FMW, JDK, inventaire	Répliquer uniquement à la demande (par exemple, après l'application de patches)
WebLogic Configuration partagée de domaine	`ASERVER_HOME`, applications, plans de déploiement, keystores	Programmer la réplication, une fréquence élevée peut être requise. La fréquence dépend de la fréquence à laquelle les modifications de configuration sont effectuées sur le système WebLogic Server.
Configuration privée de domaine WebLogic	`MSERVER_HOMES`, `nodemanager config`	Planifiez la réplication. La fréquence élevée n'est normalement pas requise.
Environnement partagé	Artefacts d'exécution propres au client (pas JMS, pas TLOGS)	Déterminé par vos besoins. S'il s'agit d'un montage DBFS, le contenu est répliqué automatiquement par Oracle Data Guard.

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.

Exécuter un basculement

Une opération de basculement est généralement une opération non planifiée qui est effectuée lorsque le site principal devient indisponible. Vous pouvez faire passer une base de données de secours au rôle de base de données principale lorsque la base de données principale d'origine échoue et qu'il est impossible de la récupérer dans les meilleurs délais. Il peut y avoir une perte de données, selon que vos bases de données principale et de secours cible étaient cohérentes au moment de la panne de la base principale.

Si possible, propagez les modifications de configuration en attente.
Reportez-vous à Réplication des artefacts de système de fichiers vers OCI pour répliquer les modifications vers 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.
Si possible, arrêtez les serveurs gérés sur le site principal.

Utilisez la console ou les scripts du serveur d'administration WebLogic pour arrêter les serveurs gérés dans l'instance principale.
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.

Pour les scénarios où le DNS est utilisé pour la résolution frontale externe (OCI DNS, DNS commercial, etc.), utilisez l'API appropriée pour propager la modification. Pour voir un exemple qui propage cette modification dans un DNS OCI, cliquez ici.

Remarque :
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. L'utilisation de valeurs de durée de vie inférieures accélère cette opération. 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 dans l'hôte de base de données secondaire pour effectuer le basculement.
Vous aurez besoin de votre mot de passe système et du nom unique de votre base de données principale.
```
[oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
DGMGRL> failover 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.

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.

Basculement local du serveur d'administration sur OCI

Vous pouvez démarrer le serveur d'administration sur un autre noeud du même site en cas d'échec sur l'hôte sur lequel le serveur d'administration était initialement exécuté. Il n'est pas nécessaire de procéder à une permutation complète du système vers l'autre site.

Remarque :

Cette tâche de cycle de vie est applicable uniquement lorsque les serveurs d'administration WebLogic utilisent une adresse IP virtuelle à des fins de haute disponibilité locale et que le dossier de configuration du serveur d'administration (ASERVER_HOME) se trouve dans un emplacement partagé.

Pour ce faire, reportez-vous à la section Verifying Manual Failover of the Administration Server. Cela fournit une protection de basculement local pour le serveur d'administration. Cette opération n'est pas nécessaire pour les serveurs gérés, qui disposent d'une protection locale haute disponibilité basée sur la fonctionnalité de migration automatique des services.

Si vous devez effectuer un basculement du serveur d'administration vers un autre hôte lorsque le serveur principal est en cours d'exécution sur le site OCI, vous pouvez suivre cette procédure. Toutefois, une action supplémentaire est requise en relation avec l'étape "Migrer l'adresse IP virtuelle ADMINVHN vers le deuxième hôte".

Effectuez les étapes suivantes pour détacher l'adresse IP virtuelle de l'hôte du serveur WebLogic sur lequel le serveur d'administration était en cours d'exécution et l'attacher à l'hôte du serveur WebLogic sur lequel l'administration est déplacée (détachez l'adresse IP virtuelle de APPHOST1 et attachez-la à APPHOST2 sur le site OCI) :

En tant qu'utilisateur root, exécutez les commandes suivantes dans APPHOST1 pour supprimer l'adresse IP virtuelle du serveur d'administration de l'interface réseau.
1. Arrêter le serveur d'administration au cas où il serait encore en cours d'exécution
2. Vérifiez l'emplacement d'exécution de l'adresse IP virtuelle.
```
ip addr show dev ens3
```
3. Supprimez l'adresse IP de l'interface réseau.
```
ip addr del 100.70.8.120/20 dev ens3
```
Détachez l'adresse IP virtuelle du serveur d'administration d'APPHOST1.
1. Connectez-vous à la console OCI et sélectionnez la région et le compartiment appropriés.
2. Accédez à l'instance de calcul. Cliquez sur Compute, Instances, puis sur APPHOST1.
3. Cliquez sur VNIC attachées, puis sélectionnez la VNIC à laquelle l'adresse IP virtuelle du serveur d'administration est attachée.
4. Cliquez sur IPv4 Addresses et modifiez l'adresse IP virtuelle utilisée par le serveur d'administration.
5. Enregistrez l'adresse IP et le nom fqdn de l'adresse IP virtuelle dans une note (par exemple : 100.70.8.120, hydrwls-VIP.midtiersubnet.hydrvcn.oraclevcn.com).
6. Cliquez sur Supprimer l'adresse IP privée.
Attachez l'adresse IP virtuelle du serveur d'administration à APPHOST2.
1. Accédez à l'instance de calcul. Cliquez sur Compute, Instances, puis sur APPHOST2.
2. Cliquez sur VNIC attachées, puis sélectionnez la VNIC à laquelle l'adresse IP virtuelle du serveur d'administration est attachée.
3. Cliquez sur affecter l'adresse IP privée secondaire.
4. Cliquez sur IPv4 Adresses, puis sur Affecter une adresse IP privée secondaire.
5. Entrez les valeurs d'adresse IP privée et de nom d'hôte utilisées précédemment. Par exemple : 100.70.8.120 pour l'adresse IP et hydrwls-vip pour le nom d'hôte.
Connectez-vous à APPHOST2 en tant qu'utilisateur root, puis exécutez les commandes suivantes pour associer l'adresse IP virtuelle du serveur d'administration à l'interface réseau.
1. Confirmez l'emplacement d'exécution de l'interface réseau.
```
ip addr show dev ens3
```
2. Ajoutez l'adresse IP virtuelle du serveur d'administration à l'interface réseau.
```
ip addr add 100.70.8.120/20 dev ens3 label ens3:1
```
Effectuez les autres étapes décrites à la section Vérification du basculement manuel du serveur d'administration.