A propos de la gestion des défaillances

La topologie de cluster étendue Oracle Fusion Middleware (FMW) est résiliente aux pannes de tout composant individuel.

Chaque site suit les meilleures pratiques de haute disponibilité décrites dans la topologie de déploiement Oracle FMW Enterprise, ce qui garantit une protection de la redondance locale contre les perturbations 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 à prendre en compte pour résoudre des scénarios tels qu'une défaillance complète d'un niveau au sein d'un site ou une défaillance totale d'un site sont traités dans les sections suivantes.

Gérer l'échec 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 stratégie de pilotage de la gestion du trafic Oracle Cloud Infrastructure (OCI)) doit marquer le site comme étant en mauvais état.

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

Par conséquent, les serveurs Oracle WebLogic du site avec les serveurs Web en échec ne recevront pas de nouvelles demandes. Ils peuvent poursuivre le traitement (par exemple, le traitement des composites Oracle SOA et des messages JMS (Java Message Service). Cependant, tous les rappels 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 échecs de tous les serveurs Web sur un même site.

Description de l'illustration échecs-all-web-servers-one-site.png

échec-tout-serveurs-web-un-site-oracle.zip

Récupération suite à l'échec

Aucune intervention manuelle n'est nécessaire pour une récupération immédiate après une panne sur tous les serveurs Web d'un même site.

Les clients sont automatiquement redirigés vers l'autre site grâce aux stratégies 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 définissez le paramètre DynamicServerList sur ON.
   2. Appliquez cette modification en redémarrant OHS de manière non simultanée pour éviter les temps d'arrêt.
   3. En outre, 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 des rappels HTTP (Hypertext Transfer Protocol) provenant du site avec des serveurs OHS indisponibles, mettez à jour l'entrée du nom de front-end dans le fichier /etc/hosts des hôtes du serveur WebLogic ou dans le système de noms de domaine privé (DNS), afin de pointer vers l'équilibreur de charge de l'autre site.

Une fois les serveurs défaillants à nouveau disponibles :

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

   Dès que Oracle Cloud Infrastructure Health Checks est de nouveau correct, la stratégie de pilotage de la gestion du trafic équilibre la charge des demandes client entre les deux sites, conformément aux règles définies.

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

L'image suivante présente les messages de file d'attente JMS (Java Message Service) et les demandes client ayant échoué en cas d'échec de tous les serveurs Web sur un même site :

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

Objectif de délai de récupération attendu

Lors de l'utilisation des stratégies de pilotage de 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 (TTL).

La mise à jour DNS affecte les clients dont la préférence de stratégie de pilotage est définie sur la région en échec. La valeur de durée de vie détermine la durée pendant laquelle ces clients continueront à utiliser l'ancienne entrée avant de la mettre à jour pour pointer vers le site en bon état. Le délai supplémentaire (environ 1 minute) dépend de la fréquence et du délai d'attente des vérifications de l'état configurées dans la stratégie de pilotage OCI (30 secondes ont été utilisées dans le test ci-dessus pour l'intervalle de vérification de l'état et un délai d'attente de 10 secondes).

Lors de l'utilisation d'un équilibreur de charge global (GLBR), le temps d'indisponibilité dépend de la fréquence des vérifications de l'état configurées dans GLBR. Dès que le GLBR marque un pool comme étant en mauvais état, 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 front-end n'est pas pertinente.

Gérer l'échec de tous les serveurs Oracle WebLogic sur un seul site

Lorsque tous les serveurs WebLogic sont arrêtés sur un site, l'autre site poursuit le traitement des demandes.

L'équilibreur de charge du site en échec renvoie une réponse en échec. Par conséquent, la fonctionnalité d'équilibrage global front-end, basée sur les stratégies de pilotage du trafic Oracle Cloud Infrastructure (OCI) et les vérifications de l'état, doit marquer le site comme étant en mauvais état. Toutes les demandes du client, quelle que soit leur préférence, seront routées vers l'autre site.

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

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

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

Description de l'illustration échecs-all-weblogic-servers-one-site.png

échecs-tout-weblogic-serveurs-un-site-oracle.zip

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

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

Le graphique Messages JMS comporte quatre lignes, chacune représentant la file d'attente JMS d'un serveur. Les lignes vertes et bleues (qui se chevauchent presque) 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 la panne.

Les lignes rouge et jaune représentent les serveurs qui restent actifs 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. Cependant, le taux auquel les messages s'accumulent dans leurs files d'attente est différent. En effet, les serveurs JMS des serveurs en échec ont migré vers l'un des serveurs restants. Les messages de ce serveur sont donc désormais traités par trois files d'attente. Par conséquent, la pente apparaît plus bas dans le jaune (notez que l'outil de surveillance n'affiche pas le nombre de messages pour les files d'attente migrées).

Récupération suite à l'échec

Aucune intervention manuelle n'est nécessaire pour une récupération immédiate suite à une panne sur tous les serveurs Oracle WebLogic Server d'un site.

Une fois les serveurs défaillants à nouveau disponibles :

1. Démarrez les serveurs gérés sur le site défaillant.
2. Dès que l'état d'Oracle Cloud Infrastructure Health Checks est rétabli, la stratégie de pilotage de Traffic Management équilibre la charge des demandes client entre les deux sites, conformément aux règles définies.

Objectif de délai de récupération attendu

Lors de l'utilisation des stratégies de pilotage de 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 (TTL).

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

La mise à jour DNS affecte les clients dont la préférence de stratégie de pilotage est définie sur la région en échec. La valeur de durée de vie détermine la durée pendant laquelle ces clients continueront à utiliser l'ancienne entrée avant de la mettre à jour pour pointer vers le site en bon état. Le délai supplémentaire (environ 1 minute) dépend de la fréquence et du délai des vérifications de l'état configurées dans la stratégie de pilotage OCI Traffic Management (30 secondes ont été utilisées dans le test pour l'intervalle de vérification de l'état et un délai d'attente de 10 secondes).

Lors de l'utilisation d'un équilibreur de charge global (GLBR), le temps d'indisponibilité dépend de la fréquence des vérifications de l'état configurées dans GLBR. Dès que le GLBR marque un pool comme étant en mauvais état, 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 front-end n'est pas pertinente.

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

Si un problème affecte uniquement la base de données 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 la section "Configuration des 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 globales é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 un impact sur la durée totale. Reportez-vous à la section En savoir plus pour obtenir des liens vers la documentation 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 produisent. 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 crédit-bail par défaut est :

1. Si la panne de la base de données est très courte (<1-2 min), aucun redémarrage automatique du serveur WebLogic n'est attendu.
2. Si la coupure de la base de données est plus longue (2 à 10 min), 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 "Configuration du réglage de la location de base de données WebLogic".

3. Si la panne de la base de données est beaucoup plus longue (>10 min), les serveurs WebLogic peuvent redémarrer automatiquement en raison d'autres échecs tels que la perte de l'accès aux espaces de stockage JDBC critiques ("l'emplacement de stockage JDBC de JTA n'est pas disponible").

Le schéma suivant illustre la permutation de bases de données dans la topologie des clusters étendus FMW.

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

extended-clusters-db-switchover-oracle.zip

L'image 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 extends-clusters-db-switchover-messages.png

Récupération suite à l'échec

Pour effectuer une récupération immédiate suite à une défaillance d'une 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 broker Oracle Data Guard.
2. Si la base principale n'est pas disponible, effectuez un basculement de la base à partir de cette base.

   Les serveurs Oracle WebLogic Server se reconnectent automatiquement à la nouvelle base de données principale, de sorte qu'aucune action manuelle n'est nécessaire, sauf pour récupérer des 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 des erreurs).

Une fois les serveurs défaillants à nouveau disponibles :

1. Rétablissez la base de données en échec 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 délai de récupération attendu

Pour une permutation planifiée, la durée totale de récupération est courte et 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.

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 la base de données presque immédiatement, la durée totale de récupération est courte. 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 temps de récupération attendu (RTO) 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 les redémarrages automatiques Oracle WebLogic Server, qui augmentent le RTO. Dans ce cas, le RTO attendu est :

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gestion des échecs 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.

Il s'agit essentiellement de 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 d'une même région ou une restauration à partir d'une sauvegarde ou d'une réplication de système de fichiers mise à la disposition des noeuds d'une autre région.

Remarques :

Quelle que soit la configuration du cluster étendu, les procédures de sauvegarde appropriées sont en place pour le domaine Oracle WebLogic.

Par conséquent, dans une topologie de cluster étendue Oracle Fusion Middleware (FMW), différents éléments à prendre en compte lors de la migration du serveur d'administration vers un noeud d'une autre région sont différents de ceux de la migration vers un noeud de la même région.

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

Description de l'illustration échecs-admin-server.png

échec-admin-server-oracle.zip

Basculement vers une autre région

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

1. Rendez disponible la sauvegarde du répertoire de domaine de votre serveur d'administration (ASERVER_HOME) sur le site de basculement.
2. Restaurez le répertoire ASERVER_HOME (y compris le répertoire du domaine et celui des applications) sur le site de basculement afin que la même structure de répertoires de domaine soit cohérente avec le site d'origine.
3. Les sous-réseaux des régions 1 et 2 utilisent généralement différents blocs de routage interdomaine sans classe (CIDR). 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) corresponde à 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 blog Utilisation d'une adresse IP virtuelle dans Oracle Cloud Infrastructure.
   2. Mettez à jour les vues privées /etc/hosts ou DNS dans les 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 le fichier ASERVER_HOME et redémarrez le gestionnaire de noeuds :

   domain_name=MSERVER_HOME;ASERVER_HOME

5. Démarrez le serveur d'administration dans 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 le cache de résolution DNS. Vous disposez de deux approches :
   1. Redémarrez les serveurs OHS pour actualiser le cache de résolution DNS.
   2. Vous pouvez également définir 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 fois à la WebLogic Remote Console et à Oracle Enterprise Manager Fusion Middleware Control.

Basculement vers la même région

Pour basculer le serveur d'administration sur un hôte de la même région, vous n'avez pas besoin de copier le répertoire de 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 Enterprise pour le serveur d'administration, dans la section Vérification du basculement manuel du serveur d'administration.

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

Gérer l'échec de l'ensemble de 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 renvoie une réponse en échec. Par conséquent, la fonctionnalité d'équilibrage global front-end doit marquer le site comme étant en mauvais état. Toutes les demandes du client, quelle que soit leur préférence, seront routé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 des services avec les espaces de stockage persistants JDBC. Dans le cas d'Oracle Fusion Middleware (FMW) Oracle SOA Suite, si le maître du cluster de récupération automatique était hébergé sur les serveurs défaillants, un nouveau maître du cluster apparaîtra sur le site disponible. Le nouveau gestionnaire de clusters effectue une récupération automatisée des instances SOA lancées sur l'autre site.

Le schéma suivant illustre la défaillance de l'ensemble de la région 1 dans la topologie des clusters étendus FMW :

Description de l'illustration échec-entire-region.png

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

Récupération suite à l'échec

Pour effectuer une récupération immédiate suite à une panne 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 broker Oracle Data Guard.

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

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 suite à des erreurs propres à l'application (par exemple, dans Oracle SOA Suite, vous devrez peut-être récupérer des composites dans l'hôpital des 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 disponible à nouveau :

1. Redémarrez les processus dans les hôtes en échec : serveurs Oracle HTTP, 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'aucun fichier orphelin n'empêche le démarrage.

2. Rétablissez la base de données en échec 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 délai de récupération attendu

Lorsque 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 s'exécute à nouveau sur le site restant, de sorte que le temps d'arrêt dépend de la durée utilisée avant le basculement de la base de données.

• Si vous effectuez le basculement ou la permutation de la base de données presque immédiatement, la durée totale de récupération est courte. 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 le 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 les redémarrages automatiques Oracle WebLogic Server, qui augmentent le RTO. Le RTO attendu est :

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gérer l'échec de l'ensemble de la région hébergeant la base de données de secours

Si une panne affecte l'ensemble de la région 2, la fonction d'équilibrage global front-end doit marquer le site comme étant en mauvais état.

Toutes les demandes 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 migrent automatiquement vers les serveurs du site 1 lors de l'utilisation de la migration automatique des services avec les espaces de stockage persistants JDBC.

Dans le cas Oracle Fusion Middleware (FMW) avec Oracle SOA Suite, si le maître du cluster de récupération automatique était hébergé sur les serveurs défaillants, un nouveau maître du cluster apparaît sur le site disponible. Ce serveur effectue une récupération automatique 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 la panne n'affecte pas la base principale.

Le schéma suivant illustre l'échec de l'ensemble de la région 2 dans la topologie des clusters étendus FMW.

Description de l'illustration échecs-standby-db-region.png

échecs-de secours-db-region-oracle.zip

Récupération suite à l'échec

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

Une fois le site défaillant à nouveau disponible, redémarrez les processus dans les hôtes défaillants pour les serveurs Oracle HTTP et les serveurs gérés WebLogic.

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

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

Objectif de délai de récupération attendu

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

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

Lors de l'utilisation d'un équilibreur de charge global (GLBR), le temps d'indisponibilité dépend de la fréquence des vérifications de l'état configurées dans GLBR. Dès que le GLBR marque un pool comme étant en mauvais état, 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 front-end n'est pas pertinente.