Cycle de vie

Différentes opérations sont effectuées sur le système au cours de son cycle de vie. Les plus pertinents sont le basculement et le test ou l'ouverture du secondaire pour les validations, l'application de patches, etc.

Réalisation d'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 le système principal. L'exécution d'une permutation entraîne un temps d'inactivité sur le site principal.

Une permutation est effectuée selon les procédures standard (reportez-vous aux sections relatives à la permutation dans Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery et à SOA Suite on Oracle Cloud Infrastructure Marketplace Disaster Recovery).

1. Propager toutes les modifications de configuration en attente selon les étapes indiquées dans "Configuration de la réplication de configuration en cours".
2. Arrêtez les serveurs sur le site principal.
3. Permutation des noms DNS.
4. Permuter la base de données.
5. Démarrez les serveurs sur le site secondaire.

La principale différence réside dans le fait que seule la console Oracle Cloud Infrastructure (OCI) est utilisée pour permuter l'instance Oracle Autonomous Database.

Remarque :

Pour les clones actualisables distants, si une permutation permanente est effectuée (si le secondaire devient principal au-delà d'un test ou d'une vérification non permanent), vous devez créer un clone actualisable homologue dans la région principale d'origine afin de disposer d'un système secondaire pour les tests et les validations dans la nouvelle base de données de secours (à l'origine principale). Le clone actualisable dans le secondaire ne pourra plus être reconnecté car sa source sera désormais une base de données de secours (les clones actualisables ne peuvent pas être créés, maintenus ou connectés à partir d'Oracle Autonomous Database Serverless de secours). Il n'est pas possible de l'actualiser à nouveau et, si nécessaire, vous pouvez enlever la base de données pour réduire les coûts. Pour la création du nouveau clone actualisable dans la base principale d'origine (maintenant de secours), suivez la même procédure qu'avec la première.

Effectuez les étapes suivantes pour l'opération de permutation :

1. 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.
2. Arrêtez les serveurs du site principal.
   Utilisez les scripts ou la console Oracle WebLogic Administration Server pour arrêter les instances Oracle WebLogic Server sur 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 veille car la configuration de domaine dans le site de secours doit être remplacée par la configuration principale pendant le cycle de vie. Si le serveur d'administration est démarré alors que cela se produit, il s'exécute avec une configuration obsolète.
3. Permutation du 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, par exemple, des scripts pour mettre à jour le DNS frontal.

   Remarque :

   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 sur les clients. L'utilisation de valeurs de durée de vie inférieures rend cette opération plus rapide. Toutefois, cela peut entraîner une surcharge car les clients frappent 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. Ensuite, effectuez la modification et, une fois la procédure de permutation terminée, rétablissez la valeur d'origine de la durée de vie.
4. Connectez-vous à la console Oracle Cloud Infrastructure (OCI) pour la région SECONDAIRE, puis accédez à Autonomous Database.
5. Sélectionnez le compartiment hébergeant la base de données Oracle WebLogic et cliquez sur son nom.
6. Sélectionnez Permutation dans le menu déroulant Actions supplémentaires, puis confirmez la saisie du nom de la base de données de secours.
7. Attendez que l'opération soit terminée.

   Le statut apparaît dans le menu Demandes de travail sous Ressources à gauche.

8. Démarrez le serveur d'administration secondaire (ou redémarrez-le s'il a déjà été démarré, de sorte que les modifications de configuration qui ont été répliquées alors qu'il s'agissait d'une base de données de secours prennent effet).
9. Démarrez les serveurs gérés secondaires (à l'aide de la console ou des scripts Oracle WebLogic Server).

Exécuter un basculement

Une opération de basculement est effectuée lorsque le site principal devient indisponible et qu'il s'agit généralement d'une opération non planifiée. Vous pouvez faire passer une base de données de secours à une base principale lorsque la base de données principale d'origine échoue et qu'il n'est pas possible de la récupérer rapidement.

Il peut y avoir ou non perte de données, selon que les bases de secours principale et cible étaient cohérentes au moment de la défaillance de la base principale. Une procédure de basculement est similaire à une procédure de permutation, mais vous effectuez un basculement à la place d'une opération de permutation dans la base de données.

Normalement, une opération de basculement est exécutée lorsqu'une panne affecte la région principale. Par conséquent, il peut y avoir des tâches que vous ne pouvez pas effectuer dans le primaire. Par exemple, vous ne pourrez peut-être pas arrêter les processus Oracle WebLogic Server dans le serveur principal car les hôtes sont inaccessibles.

1. Si possible, arrêtez les serveurs WebLogic sur le site principal.
2. Permutation des noms DNS.
3. Basculez la base de données.

   Remarques :

   Lorsque vous utilisez Oracle Autonomous Database Serverless, le lien de basculement ne s'affiche que lorsque la base de données principale est indisponible et qu'une base de données de secours l'est. Vous pouvez lancer le basculement manuel à l'aide de l'API à tout moment
4. Démarrez les serveurs sur le site secondaire.
5. Une fois qu'une opération de basculement est terminée et que le site principal précédent est à nouveau accessible, vous devez effectuer les tâches manuelles suivantes pour préparer le système à une future permutation.
   1. Arrêtez les processus Oracle WebLogic Server sur le site en échec.
      Si vous ne les avez pas arrêtés lors du basculement, les processus peuvent être bloqués. Assurez-vous qu'ils sont arrêtés.
   2. Pour Oracle Autonomous Database Serverless, vous n'avez pas besoin de rétablir manuellement la base principale en échec.
      Après un basculement manuel d'Oracle Autonomous Data Guard, la base de données de secours est automatiquement reconnectée ou, si nécessaire, reprovisionnée automatiquement (de manière transparente) lorsque la région revient en ligne.
      Pour plus d'informations, reportez-vous à Remarques relatives au basculement manuel avec une base de données de secours.
   3. Pour Oracle Autonomous Database on Dedicated Exadata Infrastructure, rétablissez la base de données Conteneur en échec sur un rôle de secours activé à partir de sa page de détails.
      Après un basculement, le rôle de la base de données Conteneur de secours devient Principal et le rôle de la base de données Conteneur principale devient Base de données de secours désactivée avec l'état Non disponible.
      Pour plus de détails, reportez-vous à Basculement vers la base de données de secours dans une configuration Autonomous Data Guard.
   4. Vérifiez l'exécution correcte de la réplique de configuration (de la nouvelle base de données principale à la nouvelle base de données de secours).