À propos de la gestion des défaillances

La topologie de grappe étendue Oracle Fusion Middleware (FMW) est résiliente aux défaillances de tout composant individuel.

Chaque site suit les meilleures pratiques de haute disponibilité décrites dans la topologie Oracle FMW Enterprise Deployment, en s'assurant que la redondance locale protège contre les interruptions au niveau des composants (comme l'équilibreur de charge, les instances Oracle HTTP Server, Oracle WebLogic Server ou l'instance de base de données).

Les points à considérer pour traiter des scénarios tels qu'une défaillance complète d'un site ou une défaillance totale d'un site sont traités dans les sections suivantes.

Gérer la défaillance de tous les serveurs Web sur un seul site

Si un site perd toutes les instances Oracle HTTP Server, le système frontal (qu'il s'agisse d'un équilibreur de charge global ou d'une politique de pilotage pour la gestion du trafic Oracle Cloud Infrastructure (OCI)) doit marquer le site comme non sain.

Toutes les demandes du client, quelle que soit leur préférence de site, seront acheminées vers l'autre site.

Par conséquent, les serveurs Oracle WebLogic du site dont les serveurs Web ont échoué ne recevront pas de nouvelles demandes. Ils peuvent continuer à effectuer certains traitements (par exemple, le traitement des composites Oracle SOA et des messages JMS (Java Message Service). Cependant, tous les callbacks HTTP générés en interne à partir de ces serveurs échoueront car ils pointent vers leur propre site, dont les serveurs Web ont échoué.

Le diagramme suivant présente les défaillances de tous les serveurs Web sur un seul site

La description de l'illustration failure-all-web-servers-one-site.png

échecs-all-web-servers-one-site-oracle.zip

Récupérer après l'échec

Aucune intervention manuelle n'est nécessaire pour une récupération immédiate suite à une défaillance de tous les serveurs Web sur un seul site.

Les clients sont automatiquement redirigés vers l'autre site grâce aux politiques de pilotage d'Oracle Cloud Infrastructure (OCI) Traffic Management ou à l'équilibreur de charge global (GLBR).

Si la restauration des instances de serveur Web perdues n'est pas possible à court terme, vous pouvez effectuer les opérations suivantes pour utiliser les serveurs WebLogic du site avec le niveau Web défaillant :

1. Configurez les instances Oracle HTTP Server (OHS) sur l'autre site pour acheminer les demandes vers les instances Oracle WebLogic Server sur le site en échec.
   1. Mettez à jour la configuration OHS et réglez le paramètre DynamicServerList à ON.
   2. Appliquez cette modification en redémarrant l'application OHS de manière continue afin d'éviter les temps d'arrêt.
   3. De plus, assurez-vous que la communication inter-région est autorisée entre les serveurs Web et les serveurs WebLogic de l'autre site.
2. Pour éviter les échecs de rappel HTTP (Hypertext Transfer Protocol) en provenance du site avec des serveurs OHS indisponibles, mettez à jour l'entrée pour le nom du serveur frontal dans le fichier /etc/hosts des hôtes du serveur WebLogic ou le système de noms de domaine privé (DNS) pour pointer vers l'équilibreur de charge de l'autre site.

Une fois les serveurs défaillants de nouveau disponibles :

1. Démarrez les processus OHS dans le site en échec.

   Dès que les vérifications d'état pour Oracle Cloud Infrastructure Health Checks sont de nouveau correctes, la politique de pilotage pour la gestion du trafic équilibre la charge des demandes de client entre les deux sites, conformément aux règles définies.

2. Réglez de nouveau DynamicServerList à OFF dans l'autre site.
3. Annulez toute modification du fichier /etc/hosts des serveurs WebLogic (ou du DNS privé) afin qu'ils pointent à nouveau vers leur propre équilibreur de charge de site.

L'image suivante présente les messages de file d'attente Java Message Service (JMS) et les demandes de client ayant échoué lors d'une défaillance de tous les serveurs Web sur un site :

La description de l'illustration failure-messages-all-web-servers-one-site.png

Objectif de temps de reprise prévu

Lors de l'utilisation des politiques de pilotage pour la gestion du trafic Oracle Cloud Infrastructure (OCI) pour l'équilibrage global, des erreurs sont observées pendant une période d'environ 1 minute + durée de vie DNS.

La mise à jour DNS affecte les clients dont la préférence de politique de pilotage est réglée à la région en échec. La valeur de durée de vie détermine combien de temps ces clients continueront à utiliser l'ancienne entrée avant de la mettre à jour pour pointer vers le site sain. Le temps supplémentaire (environ 1 min) dépend de la fréquence et de la temporisation des vérifications d'état configurées dans la politique de pilotage OCI (30 secondes ont été utilisées dans le test ci-dessus pour l'intervalle de vérification d'état et une temporisation de 10 secondes).

Lors de l'utilisation d'un équilibreur de charge global (GLBR), le temps d'interruption dépend de la fréquence des vérifications d'état configurées dans le GLBR. Dès que le GLBR marque un pool comme malsain, les demandes entrantes seront redirigées vers l'autre site. Avec un GLBR, il n'y a pas de mise à jour DNS, de sorte que la valeur de durée de vie de l'entrée frontale n'est pas pertinente.

Gérer la défaillance de tous les serveurs Oracle WebLogic sur un seul site

Lorsque tous les serveurs WebLogic tombent en panne sur un site, l'autre site continue de traiter les demandes.

L'équilibreur de charge du site en échec retournera une réponse en échec. Par conséquent, la fonction d'équilibrage global frontal, basée sur les politiques de pilotage du trafic Oracle Cloud Infrastructure (OCI) et les vérifications d'état, doit marquer le site comme non sain. Toutes les demandes du client, quelle que soit leur préférence, seront acheminées vers l'autre site.

Les services WebLogic Java Message Service (JMS) et JTA (Java Transaction API) migrent automatiquement vers les serveurs de l'autre site lors de l'utilisation de la migration automatique de services avec les magasins persistants JDBC (Java Database Connectivity).

Dans le cas SOA Oracle Fusion Middleware (FMW), si le maître de grappe de récupération automatique était hébergé dans les serveurs en échec, un nouveau maître de grappe apparaîtra dans le site disponible. Ce serveur effectue une récupération automatisée des instances SOA lancées sur l'autre site.

Le diagramme suivant présente l'échec de tous les serveurs WebLogic sur un site :

La description de l'illustration failure-all-weblogic-servers-one-site.png

échecs-all-weblogic-servers-one-site-oracle.zip

L'image suivante présente les demandes en échec du client et les messages JMS par serveur lorsque tous les serveurs WebLogic échouent sur un site.

La description de l'illustration failure-messages-all-weblogic-servers-one-site.png

Dans le graphique des messages JMS, il y a quatre lignes représentant chacune la file d'attente JMS d'un serveur. Les lignes vertes et bleues (qui sont presque superposées) correspondent aux serveurs qui ont été tués. Le nombre de messages JMS pour ces files d'attente n'augmente pas après le début de l'interruption.

Les lignes rouge et jaune représentent les serveurs qui restent dans la région 2. Lorsque toutes les demandes sont redirigées vers cette région, chaque serveur restant reçoit 50 % de la charge totale. Toutefois, le taux d'accumulation des messages dans les files d'attente est différent. En effet, les serveurs JMS des serveurs défaillants ont migré vers l'un des serveurs restants, de sorte que les messages de ce serveur sont désormais traités par trois files d'attente. Par conséquent, la pente apparaît plus basse dans la pente jaune (notez que l'outil de surveillance n'affiche pas le nombre de messages pour les files d'attente migrées).

Récupérer après l'échec

Aucune intervention manuelle n'est nécessaire pour une récupération immédiate en cas de défaillance de tous les serveurs Oracle WebLogic Server sur un seul site.

Une fois les serveurs défaillants de nouveau disponibles :

1. Démarrez les serveurs gérés dans le site en échec.
2. Dès que les vérifications d'état pour Oracle Cloud Infrastructure Health Checks sont de nouveau saines, la politique de pilotage pour la gestion du trafic équilibre la charge des demandes de client entre les deux sites, conformément aux règles définies.

Objectif de temps de reprise prévu

Lors de l'utilisation des politiques de pilotage pour la gestion du trafic Oracle Cloud Infrastructure (OCI) pour l'équilibrage global, des erreurs sont observées pendant une période d'environ 1 minute + durée de vie du DNS.

Ceci est similaire au scénario où il y a une défaillance de tous les serveurs Web sur un seul site,

La mise à jour DNS affecte les clients dont la préférence de politique de pilotage est réglée à la région en échec. La valeur de durée de vie détermine combien de temps ces clients continueront à utiliser l'ancienne entrée avant de la mettre à jour pour pointer vers le site sain. Le temps supplémentaire (environ 1 min) dépend de la fréquence et de la temporisation des vérifications d'état configurées dans la politique de pilotage pour OCI Traffic Management (30 secondes ont été utilisées dans le test pour l'intervalle de vérification d'état et une temporisation de 10 secondes).

Lors de l'utilisation d'un équilibreur de charge global (GLBR), le temps d'interruption dépend de la fréquence des vérifications d'état configurées dans le GLBR. Dès que le GLBR marque un pool comme malsain, les demandes entrantes seront redirigées vers l'autre site. Avec un GLBR, il n'y a pas de mise à jour DNS, de sorte que la valeur de durée de vie de l'entrée frontale n'est pas pertinente.

Gérer les défaillances dans la base de données : Permutation et basculement Data Guard

Si un problème affecte uniquement la base principale, effectuez une permutation de base de données ou un basculement vers l'autre site dès que possible.

La chaîne d'URL JDBC (Java Database Connectivity) et la configuration ONS (Oracle Notification Service) fournies précédemment dans "Configurer les sources de données WebLogic" garantissent que la reconnexion se fait automatiquement à la nouvelle base de données principale. Pour ces tests précis (à l'aide d'Oracle Fusion Middleware (FMW) SOA FOD et même avec des charges de travail élevées de 160 appels simultanés), la permutation ou le basculement de base de données prend moins de quelques minutes. Cette durée peut varier en fonction de la configuration du système et de l'environnement. Dans les systèmes bien réglés, les temps de permutation de 1 à 5 minutes sont courants, mais des facteurs tels que la taille du système, les ressources, la charge globale, la synchronisation des fichiers de journalisation et les performances réseau peuvent avoir une incidence sur la durée totale. Voir la section Explorer plus pour les liens vers la documentation sur Oracle Data Guard et d'autres ressources.

Lors d'une permutation ou d'un basculement de la base de données, des erreurs d'application se produiront. En outre, les serveurs WebLogic qui utilisent la migration de service peuvent être arrêtés et redémarrés automatiquement par le gestionnaire de noeuds s'ils ne peuvent pas mettre à jour leur table de location. Le comportement attendu avec les paramètres de location par défaut est le suivant :

1. Si l'interruption de la base de données est très courte (<1 à 2 minutes), aucun redémarrage automatique du serveur WebLogic n'est attendu.
2. Si l'interruption de la base de données est plus longue (2 à 10 minutes), les serveurs WebLogic peuvent redémarrer automatiquement en raison de la "perte d'un bail" lorsque la base de données redémarre.

   La limite inférieure peut être augmentée en réglant les nouvelles tentatives de location de base de données de WebLogic, comme décrit précédemment dans "Configure Tuning WebLogic Database Leasing".

3. Si l'interruption de la base de données est beaucoup plus longue (>10 min), les serveurs WebLogic peuvent redémarrer automatiquement en raison d'autres défaillances telles que la perte de l'accès aux magasins JDBC critiques ("le magasin JDBC de JTA n'est pas disponible").

Le diagramme suivant présente la permutation de base de données dans la topologie des clusters étendus FMW.

Description de l'illustration stretched-clusters-db-switchover.png

stretched-clusters-db-switchover-oracle.zip

L'illustration suivante présente les performances des demandes client et les messages JMS (Java Message Service) par file d'attente de serveur lors d'une permutation de base de données dans un cluster étendu FMW.

Description de l'illustration stretched-clusters-db-switchover-messages.png

Récupérer après l'échec

Pour effectuer immédiatement une récupération suite à une défaillance de la base de données :

1. Effectuez une permutation de base de données à l'aide de la console Oracle Cloud Infrastructure (OCI) ou de l'interface de ligne de commande du courtier Oracle Data Guard.
2. Si la base principale n'est pas disponible, effectuez un basculement à partir de la base de secours.

   Les serveurs Oracle WebLogic Server se reconnectent automatiquement à la nouvelle base de données principale. Par conséquent, aucune action manuelle n'est nécessaire, sauf pour effectuer une récupération à partir d'erreurs propres à l'application, si nécessaire (par exemple, dans Oracle SOA Suite, vous devrez peut-être récupérer des composites dans l'hôpital d'erreurs).

Une fois les serveurs défaillants de nouveau disponibles :

1. Remettez en service la base de données défaillante si vous avez effectué un basculement de base de données.

   Cette action n'est pas requise si vous avez effectué une permutation.

2. Effectuez une permutation de base de données vers le site d'origine.

Objectif de temps de reprise prévu

Pour une permutation planifiée, le temps total de récupération est court et dépend du temps dont la base de données a besoin pour la permutation ou le basculement.

Pour les tests effectués, la permutation prend moins de 2 minutes.

Pour une permutation ou un basculement non planifié, le temps d'arrêt total dépend du temps d'arrêt de la base de données :

• Si vous effectuez le basculement ou la permutation de base de données presque immédiatement, le temps total de récupération est court. Cela dépend du temps nécessaire à la base de données pour la permutation ou le basculement. Pour les tests effectués, la permutation prend moins de 2 minutes, de sorte que l'objectif de délai de récupération (ODR) attendu est :

  RTO = DB DOWNTIME + SHORT TIME (1-2 min)

• Si le temps d'arrêt de la base de données est plus long, il peut y avoir des erreurs supplémentaires, telles que le redémarrage automatique d'Oracle WebLogic Server, qui augmentent l'objectif de récupération. Dans ce cas, l'OTR attendu est :

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gérer les défaillances dans le serveur d'administration WebLogic

Les échecs de processus pour le serveur d'administration sont pris en charge par le gestionnaire de noeuds WebLogic de ce noeud.

Le gestionnaire de noeuds redémarre automatiquement le serveur défaillant sur place.

Toutefois, vous devez basculer le serveur d'administration sur un autre noeud si une panne affecte complètement l'hôte sur lequel le serveur d'administration s'exécute.

Essentiellement, cela consiste à redémarrer le serveur d'administration sur un noeud différent, en s'assurant qu'il pointe vers l'emplacement qui contient le répertoire de domaine du serveur d'administration et qu'il utilise une adresse d'écoute qui correspond à l'adresse IP virtuelle (VIP) appropriée.

Ce répertoire de domaine du serveur d'administration peut être un emplacement de stockage partagé disponible pour différents noeuds de la même région, ou une restauration à partir d'une sauvegarde ou d'une réplication du système de fichiers mise à la disposition des noeuds d'une autre région.

Note :

Quelle que soit la configuration de cluster étendue, les procédures de sauvegarde appropriées doivent être mises en place pour votre domaine Oracle WebLogic.

Par conséquent, dans une topologie de grappe étendue Oracle Fusion Middleware (FMW), différentes considérations s'appliquent lors de la migration du serveur d'administration vers un noeud d'une autre région plutôt que de la migrer vers un noeud de la même région.

Le diagramme suivant présente le basculement du serveur d'administration vers l'autre site du cluster étendu FMW

Description de l'illustration failure-admin-server.png

échecs-admin-serveur-oracle.zip

Basculer vers une autre région

Pour basculer le serveur d'administration vers une autre région, procédez comme suit.

1. Rendez la sauvegarde du répertoire de domaine de votre serveur d'administration (ASERVER_HOME) disponible dans le site de basculement.
2. Restaurez le répertoire ASERVER_HOME (y compris le domaine et le répertoire des applications) dans le site de basculement de sorte que la même structure de répertoires de domaine soit cohérente avec le site initial.
3. Les sous-réseaux des régions 1 et 2 utilisent généralement différents blocs de routage interdomaine (CIDR) sans classe. Par conséquent, l'adresse IP virtuelle (VIP) utilisée par le serveur d'administration dans la région 1 (par exemple 10.10.10.1) n'est pas valide dans la région 2. Lorsque le serveur d'administration s'exécute dans la région 2, il utilise une adresse IP virtuelle différente (par exemple, 20.20.20.1). Mettez à jour la résolution du nom d'hôte afin que l'adresse d'écoute du serveur d'administration (ADMINHOSTVHN) soit mappée à la nouvelle adresse IP virtuelle.
   1. Affectez et attachez une adresse IP virtuelle à l'hôte qui exécutera le serveur d'administration dans la région 2, comme décrit dans le blogue Utilisation d'une adresse IP virtuelle dans Oracle Cloud Infrastructure.
   2. Mettez à jour les vues privées /etc/hosts ou DNS des deux régions pour remplacer l'enregistrement ADMINHOSTVHN de l'adresse IP précédente (par exemple 10.10.10.1) par la nouvelle adresse IP (par exemple 20.20.20.1).
4. Modifiez le fichier $NM_HOME/nodemanager.domains dans le noeud où le serveur d'administration sera restauré pour inclure ASERVER_HOME et redémarrez le gestionnaire de noeuds :

   domain_name=MSERVER_HOME;ASERVER_HOME

5. Démarrez le serveur d'administration sur le nouvel hôte.
6. Les instances Oracle HTTP Server utilisent un cache DNS, contrôlé par la directive WLDNSRefreshInterval dans mod_wl_ohs.conf. Il est 0 par défaut, ce qui signifie "cache pour toujours". Vous devez redémarrer OHS pour actualiser la mémoire cache de résolution DNS. Vous disposez de deux approches :
   1. Redémarrez les serveurs OHS pour actualiser la mémoire cache de résolution DNS.
   2. Ou définissez une valeur différente de zéro pour WLDNSRefreshInterval dans mod_wl_ohs.conf.

   Sinon, OHS continuera d'essayer de se connecter au serveur d'administration avec l'adresse IP précédente.

Vérifiez que le serveur d'administration fonctionne correctement en accédant à la console distante WebLogic et à Oracle Enterprise Manager Fusion Middleware Control.

Basculer vers la même région

Pour basculer le serveur d'administration vers un hôte de la même région, vous n'avez pas besoin de copier le répertoire du domaine du serveur d'administration et la valeur de l'adresse IP virtuelle (VIP) ne change pas.

Par conséquent, la procédure de basculement est la même que celle décrite dans le Guide de déploiement d'entreprise pour le serveur d'administration, dans Vérification du basculement manuel du serveur d'administration.

Pour gérer l'adresse IP virtuelle (VIP) du serveur d'administration dans les systèmes Oracle Cloud Infrastructure (OCI), vous pouvez utiliser les étapes décrites dans le blogue Utilisation d'une adresse IP virtuelle (VIP) dans Oracle Cloud Infrastructure

Gérer la défaillance de toute la région hébergeant la base de données principale

Si une panne affecte l'ensemble de la région 1, effectuez une permutation de base de données ou un basculement vers l'autre site/région dès que possible.

Les instances Oracle WebLogic Server du site restant se reconnecteront automatiquement à la nouvelle base de données principale si elles utilisent la configuration recommandée décrite dans la section précédente.

L'équilibreur de charge du site en échec retournera une réponse en échec. Par conséquent, la fonction d'équilibrage global frontal doit marquer le site comme non sain. Toutes les demandes du client, quelle que soit leur préférence, seront acheminées vers l'autre site.

Les services JMS et JTA WebLogic migrent automatiquement vers les serveurs de l'autre site lors de l'utilisation de la migration automatique de services avec des espaces de stockage persistants JDBC. Dans le cas d'Oracle Fusion Middleware (FMW) Oracle SOA Suite, si le maître de grappe de récupération automatique a été hébergé dans les serveurs en échec, un nouveau maître de grappe apparaîtra dans le site disponible. Le nouveau gestionnaire de cluster effectuera une récupération automatisée des instances SOA lancées sur l'autre site.

Le diagramme suivant illustre l'échec de l'ensemble de la région 1 dans la topologie des grappes étendues FMW :

Description de l'illustration failure-entire-region.png

échecs-entire-région-oracle.zip

Récupérer après l'échec

Pour effectuer immédiatement une récupération suite à une défaillance complète dans la région 1 :

1. Effectuez une permutation de base de données à l'aide de la console Oracle Cloud Infrastructure (OCI) ou de l'interface de ligne de commande du courtier Oracle Data Guard.

   Si la base principale n'est pas disponible, effectuez un basculement à partir de la base de secours.

2. Les instances Oracle WebLogic Server se reconnectent automatiquement à la nouvelle base de données principale. Par conséquent, aucune action manuelle n'est nécessaire, sauf pour effectuer une récupération à partir d'erreurs propres à une application (par exemple, dans Oracle SOA Suite, vous devrez peut-être récupérer des composites dans l'hôpital d'erreurs).
3. Si nécessaire, effectuez un basculement du serveur d'administration vers la région 2.

Une fois le site défaillant récupéré et de nouveau disponible :

1. Redémarrez les processus dans les hôtes en échec : serveurs HTTP Oracle, serveur d'administration WebLogic et serveurs gérés.

   Assurez-vous que l'adresse IP virtuelle (VIP) du serveur d'administration est définie et qu'il n'existe aucun fichier orphelin empêchant le démarrage.

2. Remettez en service la base de données défaillante si vous avez effectué un basculement de base de données.

   Cette action n'est pas requise si vous avez effectué une permutation.

3. Effectuez une permutation de base de données vers le site d'origine.

Objectif de temps de reprise prévu

Pendant que la base de données est arrêtée, le système n'est pas disponible.

Les serveurs du site restant peuvent continuer à traiter les demandes dès que la base de données est à nouveau en cours d'exécution sur le site restant, de sorte que le temps d'arrêt dépend du temps utilisé avant le basculement de la base de données.

• Si vous effectuez le basculement ou la permutation de base de données presque immédiatement, le temps total de récupération est court. Cela dépend du temps nécessaire à la base de données pour la permutation ou le basculement. Pour le test effectué, la permutation prend moins de 2 minutes, de sorte que l'objectif de reprise (RTO) attendu est :

  RTO = DB DOWNTIME + SHORT TIME (1-2 min).

• Si le temps d'arrêt de la base de données est plus long, il peut y avoir des erreurs supplémentaires, telles que le redémarrage automatique d'Oracle WebLogic Server, qui augmentent l'objectif de récupération. L'OTR attendu est :

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gérer la défaillance de la région entière qui héberge la base de données de secours

Si une défaillance affecte l'ensemble de la région 2, la fonction d'équilibrage global frontend doit marquer le site comme non sain.

Toutes les demandes du client, quelle que soit leur préférence de site, seront acheminées vers la région 1, qui poursuit le traitement des demandes. Les services JMS et JTA WebLogic migreront automatiquement vers les serveurs du site 1 lors de l'utilisation de la migration automatique de services avec des espaces de stockage persistants JDBC.

Dans le cas Oracle Fusion Middleware (FMW) avec Oracle SOA Suite, si le maître de grappe de récupération automatique a été hébergé dans les serveurs en échec, un nouveau maître de grappe apparaîtra dans le site disponible. Ce serveur effectue une récupération automatisée des instances SOA lancées sur l'autre site.

Il n'est pas nécessaire d'effectuer une permutation de base de données, car l'interruption n'a aucune incidence sur la base de données principale.

Le diagramme suivant montre l'échec de l'ensemble de la région 2 dans la topologie des grappes étendues FMW.

Description de l'illustration failure-standby-db-region.png

défaillances-standby-db-region-oracle.zip

Récupérer après l'échec

Aucune intervention manuelle n'est nécessaire pour une récupération immédiate suite à une défaillance complète dans la région 2.

Une fois que le site en échec est de nouveau disponible, redémarrez les processus dans les hôtes en échec pour les serveurs HTTP Oracle et les serveurs gérés WebLogic.

Assurez-vous qu'il n'existe aucun fichier orphelin empêchant le démarrage de WebLogic.

Grâce à la fonction d'équilibreur de charge global (politiques de pilotage pour la gestion du trafic d'Oracle Cloud Infrastructure ou équilibreur de charge global), les demandes du client seront rééquilibrées entre les 2 sites.

Objectif de temps de reprise prévu

Lors de l'utilisation des politiques de pilotage du trafic Oracle Cloud Infrastructure (OCI) pour l'équilibrage global, la période avec défaillances est d'environ 1 minute de plus que la durée de vie de l'entrée frontale définie dans la politique de pilotage.

La mise à jour du système de noms de domaine (DNS) a une incidence sur les clients pour lesquels la région 2 est définie comme préférence dans la politique de pilotage par géolocalisation. La mise à jour DNS affecte les clients dont la préférence de politique de pilotage est réglée à la région en échec. La valeur de durée de vie détermine combien de temps ces clients continueront à utiliser l'ancienne entrée avant de la mettre à jour pour pointer vers le site sain. Le temps supplémentaire (environ 1 min) dépend de la fréquence et de la temporisation des vérifications d'état configurées dans la politique de pilotage pour la gestion du trafic OCI (30 secondes ont été utilisées dans le test ci-dessus pour l'intervalle de vérification d'état et une temporisation de 10 secondes).

Lors de l'utilisation d'un équilibreur de charge global (GLBR), le temps d'interruption dépend de la fréquence des vérifications d'état configurées dans le GLBR. Dès que le GLBR marque un pool comme malsain, les demandes entrantes seront redirigées vers l'autre site. Avec un GLBR, il n'y a pas de mise à jour DNS, de sorte que la valeur de durée de vie de l'entrée frontale n'est pas pertinente.