1. Configurer une solution de récupération après sinistre hybride pour Oracle SOA Suite
  2. Vérification de la configuration

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 SOA 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 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.
  1. En tant qu'utilisateur oracle, utilisez Oracle Data Guard Broker dans l'hôte de base de données principal et convertissez le broker 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.
  2. Vérifiez qu'aucune action n'est en attente dans l'environnement secondaire.
    If there are pending actions (transactions, messages) in the primary DB when the standby is converted to snapshot, then the secondary SOA servers will try process them when they start.You can use the SOA truncate script to remove the records from the SOA runtime tables in the secondary database to clean the runtime data before starting the secondary servers. Exécutez cette action avec ATTENTION ; ne tronquez pas les tables de la base principale. Reportez-vous à la section Suppression d'enregistrements des tables d'exécution sans suppression des tables.
  3. S'ils ne sont pas déjà en fonctionnement, démarrez les systèmes Oracle HTTP Server sur le site secondaire.
  4. Démarrez le serveur d'administration sur le site secondaire.
  5. Démarrez les serveurs gérés secondaires sur le site secondaire.
    Utilisez les scripts ou la console WebLogic pour démarrer les serveurs gérés secondaires.
  6. 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 services SOA 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 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 rétablir le rôle de secours.

    Remarque :

    La validation du site secondaire peut prendre du temps.
  7. 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.
  8. En tant qu'utilisateur oracle, utilisez Oracle Data Guard Broker dans l'hôte de base de données primary et convertissez à nouveau le broker secondaire en base de données de secours physique.
    Vous aurez besoin du 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.
  9. 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.

Remarque :

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

Lors 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.

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 de DR hybride SOA, propagez toutes les modifications de configuration en attente. Assurez-vous qu'aucune modification répliquée n'est en attente sur le site secondaire.
  1. 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.
  2. Arrêtez les systèmes Oracle HTTP Server sur le site principal.
  3. Arrêtez les serveurs sur le site principal.
    Utilisez les scripts ou la console du serveur d'administration WebLogic pour arrêter les serveurs WebLogic dans le site principal.

    Remarque :

    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 attendu que la configuration de domaine du site de secours soit remplacée par la configuration principale pendant le cycle de vie. Si le serveur d'administration fonctionne alors, il sera exécuté avec une configuration obsolète.
  4. Permutez le nom DNS frontal.

    Exécutez la transmission DNS requise sur 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 permutation : si la durée de vie est élevée (par exemple, 20 min), la modification DNS prendra ce temps pour être effective dans les clients. L'utilisation de valeurs de durée de vie inférieures accélère cette opération, mais cela peut entraîner une surcharge car les clients frappent plus fréquemment le DNS 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 minute) avant la modification du DNS. Ensuite, effectuez la modification et une fois la procédure de permutation terminée, rétablissez à nouveau la valeur d'origine de la durée de vie.

  5. En tant qu'utilisateur oracle, utilisez Oracle Data Guard Broker dans l'hôte de la base de données principale pour effectuer la permutation de base de données.
    Vous aurez besoin du 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
  6. S'ils ne sont pas déjà en fonctionnement, démarrez les systèmes Oracle HTTP Server sur le site secondaire (nouveau serveur principal).
  7. Démarrez le serveur d'administration sur 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 d'appliquer les modifications de configuration répliquées alors qu'il s'agissait d'une base de données de secours.
  8. Démarrez les serveurs gérés secondaires sur le site secondaire (nouveau serveur principal).
    Utilisez les scripts ou la console WebLogic pour démarrer les serveurs gérés secondaires.