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 notamment ASERVER_HOME, qui est la source de vérité de la configuration de domaine SOA, 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 SOA.
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 SOA, 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 SOA secondaires 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 : si la base de données contient des messages ou des composites en attente lorsqu'elle est convertie en cliché, les serveurs SOA 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. Sinon, supprimez les enregistrements des tables SOA d'exécution de la base de données de secours après leur conversion en base de données de secours instantanée et avant de démarrer les serveurs SOA du site secondaire. Voir Suppression d'enregistrements des tables d'exécution sans supprimer les tables pour connaître les étapes de validation du site de secours sans effectuer de permutation.

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.
Vérifiez qu'il n'y a aucune action en attente dans l'environnement secondaire.
S'il existe des actions en attente (transactions, messages) dans la base de données principale lorsque la base de secours est convertie en instantané, les serveurs SOA secondaires essaient de les traiter lorsqu'ils start.You peuvent utiliser le script de troncature SOA pour supprimer les enregistrements des tables d'exécution SOA de la base de données secondaire afin de nettoyer les données d'exécution avant de démarrer les serveurs secondaires. Exécutez cette action avec l'instruction CAUTION; ne tronquez pas les tables de la base principale. Voir Suppression d'enregistrements des tables d'exécution sans supprimer les tables.
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 services SOA 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.

Note :

ORA-01403 : aucune donnée trouvée ORA-06512 erreurs

Lors de la validation du site secondaire tel que décrit ici (sans effectuer une permutation complète, c'est-à-dire qu'il suffit d'ouvrir la base de secours en mode de secours instantané) "ORA-01403 : aucune donnée trouvée ORA-06512" erreurs peuvent apparaître dans les journaux des serveurs SOA de secours. Ces erreurs sont liées à la tâche d'épuration automatique SOA. Ces erreurs se produisent parce que les tâches de la base de données peuvent avoir des dépendances de rôle de base de données (elles sont définies pour être activées uniquement lorsque la base de données est dans le rôle principal). Il s'agit d'un comportement attendu et souhaité qui empêche l'exécution des travaux deux fois (une fois dans la base principale et une fois dans la base de secours). La tâche d'épuration automatique SOA est définie avec le rôle principal. Elle n'est donc pas affichée dans la vue DBA_SCHEDULER_JOBS lorsque la base de données est en mode de secours instantané. La valeur database_role définie pour chaque tâche est visible dans la vue DBA_SCHEDULER_JOB_ROLE. En résumé, ces erreurs peuvent être ignorées tant qu'elles apparaissent dans le système de secours. La tâche du planificateur pour l'épuration automatique SOA sera exécutée sur la base de données si, et seulement si, l'instance change de rôle pour PRIMARY.

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 SOA sur lequel le serveur d'administration s'exécutait et l'attacher à l'hôte SOA sur lequel l'administration est déplacée (détachez l'adresse IP virtuelle de SOAHOST1 et attachez-la à SOAHOST2 sur le site OCI) :

En tant qu'utilisateur root, exécutez les commandes suivantes dans SOAHOST1 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 de SOAHOST1.
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 Calcul, Instances, puis sur SOAHOST1.
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, hydrsoa-VIP.midtiersubnet.hydrvcn.oraclevcn.com).
6. Cliquez sur Supprimer l'adresse IP privée.
Attachez l'adresse IP virtuelle du serveur d'administration à SOAHOST2.
1. Naviguez jusqu'à l'instance de calcul. Cliquez sur Calcul, Instances, puis sur SOAHOST2.
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 hydrsoa-vip comme nom d'hôte.
Connectez-vous à SOAHOST2 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.