Tâches de cycle de vie
A propos de la réplication de configuration
Vous pouvez utiliser les mêmes scripts que ceux 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 programmer la réplique des systèmes de fichiers avec les considérations suivantes 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 de domaine WebLogic au cours du 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, etAPPLICATION_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 de domaine WebLogic au cours du cycle de vie
Il s'agit également d'un artefact dynamique, qui contient
MSERVER_HOME
etNM_HOME
. Il ne devrait pas avoir de mises à jour fréquentes sur le répertoire de basenodemanager
après la configuration initiale. Le contenu deMSERVER_HOME
sera modifié aussi fréquemment queASERVER_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 deAdminServer
lorsque les serveurs gérés démarrent et lorsque des modifications de configuration sont appliquées à l'aide de l'outil de génération de script (WLST) WebLogic ou de la console d'administration Oracle WebLogic Server. Il n'est pas aussi essentiel de répliquer cet artefact que la configuration partagée. Il est obligatoire de répliquer cette opération uniquement lorsque des modifications sont apportées à d'autres dossiers dansMSERVER_HOME
(par exemple, une modification dans le dossierMSERVER_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 mode veille, 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 relatives à la réplication d'artefacts de système de fichiers au cours du cycle de vie.
Artefact | Contient | Recommandation |
---|---|---|
Répertoires de base Oracle | FMW home, JDK, inventory | Réplication uniquement sur demande (par exemple, après l'application de patches) |
WebLogic Configuration partagée de domaine | ASERVER_HOME , applications, plans de déploiement, fichiers 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 de domaine WebLogic | MSERVER_HOMES , nodemanager config |
Planifiez 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. |
Réalisation d'une permutation
Exécuter un basculement
Ouvrir le secondaire pour validation
Remarque :
Cette opération doit être effectuée avec précaution : si la base de données contient des messages ou des composites en attente lors de sa conversion en cliché, les serveurs SOA du site de secours les traiteront au démarrage. Vérifiez qu'aucune action n'est en attente dans la base de données principale lors de la conversion en base de données de secours cliché. Sinon, enlevez les enregistrements des tables SOA d'exécution dans la base de données de secours après leur conversion en base de données de secours cliché et avant de démarrer les serveurs SOA du site secondaire. Reportez-vous à la section Suppression d'enregistrements des tables d'exécution sans suppression des tables pour connaître les étapes permettant de valider le site de secours sans effectuer de permutation.Remarque :
ORA-01403 : aucune donnée trouvée avec des erreurs ORA-06512Lors de la validation du site secondaire comme décrit ici (sans effectuer de permutation complète, c'est-à-dire simplement ouvrir la base de données de secours en mode de secours instantanée) "ORA-01403 : no data found ORA-06512" erreurs peuvent apparaître dans les journaux des serveurs SOA de secours. Ces erreurs sont liées au travail de purge automatique SOA. Ces erreurs se produisent parce que les travaux de la base de données peuvent avoir des dépendances de rôle de base de données (ils sont définis pour être activés uniquement lorsque la base de données est en rôle principal). Il s'agit d'un comportement attendu et souhaité qui empêche l'exécution de travaux deux fois (une fois en mode principal et une fois en mode de secours). Le travail de purge automatique SOA est défini avec le rôle principal. Il n'est donc pas affiché dans la vue DBA_SCHEDULER_JOBS lorsque la base de données est en mode de secours de cliché. Le fichier database_role
défini pour chaque travail 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. Le travail du planificateur pour la purge automatique SOA sera exécuté sur la base de données si, et seulement si, l'instance change son rôle en PRIMARY.
Basculement local du serveur d'administration sur OCI
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 SOA sur lequel le serveur d'administration était en cours d'exécution 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. - Détachez l'adresse IP virtuelle du serveur d'administration de SOAHOST1.
- Connectez-vous à la console OCI et sélectionnez la région et le compartiment appropriés.
- Accédez à l'instance de calcul. Cliquez sur Compute, Instances, puis sur SOAHOST1.
- Cliquez sur Cartes d'interface réseau virtuelles attachées, puis sélectionnez la carte d'interface réseau virtuelle dans laquelle l'adresse IP virtuelle du serveur d'administration est attachée.
- Cliquez sur Adresses IPv4 et modifiez l'adresse IP virtuelle utilisée par le serveur d'administration.
- Enregistrez l'adresse IP et le nom
fqdn
de l'adresse IP virtuelle dans une note (par exemple : 100.70.8.120, hydrsoa-VIP.midtiersubnet.hydrvcn.oraclevcn.com). - Cliquez sur Supprimer l'adresse IP privée.
- Associez l'adresse IP virtuelle du serveur d'administration à SOAHOST2.
- Accédez à l'instance de calcul. Cliquez sur Compute, Instances, puis sur SOAHOST2.
- Cliquez sur Cartes d'interface réseau virtuelles attachées, puis sélectionnez la carte d'interface réseau virtuelle dans laquelle l'adresse IP virtuelle du serveur d'administration est attachée.
- Cliquez sur Affecter une adresse IP privée secondaire.
- Cliquez sur Adresses IPv4, puis sur Affecter une adresse IP privée secondaire.
- 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
hydrsoa-vip
pour le nom d'hôte.
- Connectez-vous à SOAHOST2 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.
- Effectuez les autres étapes décrites à la section Vérification du basculement manuel du serveur d'administration.