Tâches de cycle de vie

Une 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 pourrez effectuer une permutation planifiée pour changer les rôles des sites principal et secondaire et répondre à des opérations inattendues ou non planifiées.

À propos de la réplication de la configuration

Une première réplication du contenu qui réside dans les systèmes de fichiers a été effectuée lors de la configuration de la récupération après sinistre. Vous devez répéter la réplication du système de fichiers régulièrement pour maintenir le site secondaire à jour avec le site principal.

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

Réplication des répertoires de base Oracle pendant le 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 (telle que l'activité d'application de correctifs) 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, entre autres, ASERVER_HOME, qui est la source de la 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.

La configuration partagée de ce domaine WebLogic devrait être modifiée fréquemment. Planifiez une réplique régulière de cet artefact, qui devrait être plus ou moins fréquente selon la fréquence à laquelle les modifications de configuration se produisent dans votre système. Une autre approche contrôlée consiste à effectuer une réplique chaque fois que vous effectuez une modification de configuration vers la base principale.
Réplication de la configuration privée du domaine WebLogic pendant le cycle de vie
Il s'agit également d'un artefact dynamique, qui contient MSERVER_HOME et NM_HOME. Il ne devrait pas y avoir de mises à jour fréquentes sur le répertoire de base nodemanager après la configuration initiale. Le contenu de MSERVER_HOME sera modifié aussi fréquemment que 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 au démarrage des serveurs gérés et lors de l'application des modifications de configuration à l'aide de l'outil de script WebLogic (WLST) ou de la console d'administration d'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 ceci 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, programmez la réplique en tant que base de secours, en fonction des besoins de votre entreprise.

Au lieu d'utiliser le système de fichiers du service de stockage de fichiers pour Oracle Cloud Infrastructure et de le répliquer avec rsync, vous pouvez utiliser un montage du système de fichiers Oracle Database (DBFS) 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 la réplique secondaire avec la réplique Oracle Data Guard sous-jacente. Voir À propos du système de fichiers Oracle Database dans En savoir plus sur l'utilisation de DBFS.

Le tableau suivant est un sommaire des recommandations pour la réplication des artefacts du système de fichiers au cours du cycle de vie.

Artefact	Contient	Recommandation
Répertoires de base d'Oracle	Répertoire de base FMW, JDK, inventaire	Répliquer uniquement sous la demande (par exemple, après l'application de correctifs)
Configuration partagée du domaine WebLogic	`ASERVER_HOME`, applications, plans de déploiement, magasins de clés	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 du domaine WebLogic	`MSERVER_HOMES`, `nodemanager config`	Programmer la réplication. La fréquence élevée n'est normalement pas requise.
Exécution partagée	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.

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.

Effectuer 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 un rôle de base de données de secours au rôle de base de données principale lorsque la base de données principale initiale échoue et qu'il n'est pas possible de la récupérer en temps opportun. Il peut y avoir une perte de données, selon que les bases de données de secours principale et cible étaient cohérentes au moment de la défaillance de la base de données principale.

Propagation des modifications de configuration en attente, si possible.
Voir Répliquer les artefacts de système de fichiers vers OCI pour répliquer les modifications vers 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 gérés du site principal, si possible.

Utilisez la console ou les scripts du serveur d'administration WebLogic pour arrêter les serveurs gérés dans l'instance principale.
Passez du 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ù DNS est utilisé pour la résolution frontale externe (DNS OCI, DNS commercial, etc.), utilisez l'API appropriée pour pousser la modification. Pour voir un exemple qui pousse cette modification dans un DNS OCI, cliquez ici.

Note :
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 efficace dans les clients. L'utilisation de valeurs de durée de vie inférieures accélérera cette opération, mais 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 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à 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.

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.

Basculement local du serveur d'administration sur OCI

Vous pouvez démarrer le serveur d'administration sur un noeud différent dans le même site en cas de défaillance de l'hôte sur lequel le serveur d'administration s'exécutait initialement. Une permutation complète du système vers l'autre site n'est pas nécessaire.

Note :

Cette tâche de cycle de vie s'applique 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é.

La procédure pour ce faire est expliquée sous Vérification du basculement manuel du serveur d'administration. Cela fournit une protection locale contre le basculement pour le serveur d'administration. Notez que cela n'est pas nécessaire pour les serveurs gérés, qui disposent d'une protection locale haute disponibilité basée sur la fonction de migration automatique de 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 dans le site OCI, vous pouvez suivre cette procédure. Toutefois, une action supplémentaire est requise pour 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 s'exécutait 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 s'il est toujours en cours d'exécution
2. Confirmez où l'adresse IP virtuelle est exécutée.
```
ip addr show dev ens3
```
3. Supprimez l'adresse IP de l'interface de réseau.
```
ip addr del 100.70.8.120/20 dev ens3
```
Détachez l'adresse IP virtuelle du serveur d'administration dans APPHOST1.
1. Connectez-vous à la console OCI et sélectionnez la région et le compartiment appropriés.
2. Naviguez jusqu'à l'instance de calcul. Cliquez sur Compute, Instances, puis sur APPHOST1.
3. Cliquez sur Cartes VNIC attachées, puis sélectionnez la carte VNIC à laquelle l'adresse IP virtuelle du serveur d'administration est attachée.
4. Cliquez sur IPv4 Adresses et modifiez l'adresse IP virtuelle utilisée par le serveur d'administration.
5. Enregistrez l'adresse IP virtuelle et le nom fqdn 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. Naviguez jusqu'à l'instance de calcul. Cliquez sur Compute, Instances, puis sur APPHOST2.
2. Cliquez sur Cartes VNIC attachées, puis sélectionnez la carte VNIC à laquelle l'adresse IP virtuelle du serveur d'administration est attachée.
3. Cliquez sur Affecter une adresse IP privée secondaire.
4. Cliquez sur IPv4 Adresses, puis sur Affecter des adresses IP privées secondaires.
5. Entrez les valeurs d'adresse IP privée et de nom d'hôte qui ont été utilisées précédemment. Par exemple : 100.70.8.120 pour l'adresse IP et hydrwls-vip comme nom d'hôte.
Connectez-vous à APPHOST2 en tant qu'utilisateur racine, puis exécutez les commandes suivantes pour attacher 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 sous Vérification du basculement manuel du serveur d'administration.