Protocoles de reconnaissance et de détection des incidents du groupe central

Lorsqu'un membre du groupe central démarre, aucune connexion n'est établie avec les autres membres du groupe. Si un groupe central est configuré pour être exécuté avec les protocoles de reconnaissance et de détection d'incidents ou un autre fournisseur de protocole, les tâches de reconnaissance et de détection d'incidents ou les tâches de l'autre fournisseur de protocole démarrent comme partie de la procédure de démarrage du processus. Ces tâches établissent les connexions à d'autres membres du groupe central, les surveillent et gèrent les incidents de connexion pour ce membre du groupe central, à intervalles planifiés réguliers, aussi longtemps que le membre du groupe central est actif.

Le protocole de reconnaissance par défaut

Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.

Le protocole de reconnaissance par défaut établit les connexions réseau avec les autres membres du groupe central. Pour ce faire, le protocole de reconnaissance extrait la liste des membres du groupe central, ainsi que les informations réseau associées, à partir des paramètres de configuration du produit . Il tente ensuite d'ouvrir des connexions réseau avec tous les autres membres du groupe central. A intervalle régulier, le protocole de reconnaissance recalcule l'ensemble des membres non connectés et tente d'ouvrir des connexions avec ces derniers.

Lorsqu'une connexion est établie avec un autre membre du groupe central, le protocole de reconnaissance en informe le protocole de synchronisation de la vue et consigne cet événement sous la forme d'un message d'information, similaire à celui présenté ci-dessous, dans le fichier SystemOut.log.
DCSV1032I: Pile DCS DefaultCoreGroup au niveau du membre MyCell\anzio\nodeagent: 
Membre défini connecté MyCell\anzioCellManager\dmgr.

Les connexions peuvent être rompues à tout moment pour une multitude de raisons. Le protocole de détection des incidents détecte les ruptures de connexion et en informe le protocole de reconnaissance. Ce dernier tente alors d'ouvrir une nouvelle connexion réseau vers ce membre à l'intervalle planifié suivant.

La quantité de cycles de l'unité centrale consommée par la tâche du protocole de reconnaissance est proportionnelle au nombre de membres du groupe central arrêtés ou inaccessibles. Celle-ci est négligeable lorsque les paramètres par défaut sont utilisés.

Protocole de détection des incidents par défaut

Le protocole de détection des incidents surveille les connexions réseau que le protocole de reconnaissance a établies avec le groupe central. Lorsqu'il détecte une rupture de connexion, il signale l'incident au protocole de synchronisation de la vue et au protocole de reconnaissance. Le protocole de synchronisation de la vue ajuste la vue afin d'exclure le membre défaillant. Le protocole de reconnaissance tente de rétablir la connexion réseau avec ce dernier. Cette dernière s'exécute tant que le membre est actif.

Le protocole de détection des incidents utilise deux mécanismes distincts pour rechercher les membres défaillants.
Il recherche les connexions qui ont été fermées à la suite de la fermeture de la socket sous-jacente.

Lorsqu'un membre du groupe central s'arrête dans des conditions normales en réponse à une commande d'administration, le transport du groupe central pour ce membre s'arrête également et la socket associée se ferme. Si un membre du groupe central s'arrête dans des conditions anormales, le système d'exploitation sous-jacent ferme normalement les sockets ouvertes par le processus, ainsi que la socket associée au transport du groupe central.

Quel que soit le type d'arrêt, les membres du groupe central pour lesquels une connexion a été ouverte avec le membre arrêté sont informés que la connexion n'est plus utilisable. Le membre du groupe central qui reçoit la notification de fermeture de la socket considère que le membre arrêté est défaillant.

Lorsqu'un membre défaillant est détecté en raison du déclenchement du mécanisme de fermeture de socket, le message suivant est consigné dans le fichier SystemOut.log pour les membres restants :
DCSV1115W : Pile DCS DefaultCoreGroup au niveau du membre anzioCell01\anzio\ServerD :
La connexion au membre anzioCell01\anzio\ServerC a été fermée. Le membre sera supprimé de la vue.
L'état de la connexion DCS est Discovery|Ptp, émetteur fermé.

C'est généralement par le biais du mécanisme de fermeture de socket que sont détectés les membres défaillants. Les paramètres TCP du système d'exploitation sous-jacent, tels que FIN_WAIT, affectent le délai de réception des événements de fermeture de socket.

Il détecte les signaux de présence actifs émis par le membres du groupe central.

Le mécanisme d'émission de signaux de présence actifs présente des similitudes avec la fonction TCP de maintien en vie. A intervalle régulier, chaque membre du groupe central envoie un paquet de données ping à chaque connexion ouverte au sein du groupe. La vitesse ou la périodicité à laquelle le paquet est envoyé est appelée période de transmission par émission de signal de présence.

Chaque membre du groupe central attend la réception d'un paquet sur chaque connexion ouverte, émis par le membre du groupe central à l'autre extrémité de la connexion. Si aucun paquet n'est reçu via une connexion ouverte dans l'intervalle spécifié pour le délai d'expiration de signal de présence, le membre à l'autre extrémité de la connexion est marqué comme étant en échec.

Le délai d'expiration de signal de présence doit être un nombre entier multiple du délai de transmission de signal de présence. Le délai d'expiration de signal de présence doit également être au moins deux fois plus grand que le délai de transmission de signal de présence.

Lorsqu'un membre est marqué comme étant en échec, le message suivant est envoyé au fichier historique des erreurs :
DCSV1112W: Pile DCS DefaultCoreGroup au niveau du membre anzioCell01\anzioCellManager01\dmgr: 
Suspected member anzioCell01\nettuno\ServerB because of heartbeat timeout. 
Le délai d'expiration configuré est de 180000 millisecondes. Le canal logique DCS est Connected|Ptp.

Les signaux de présence actifs sont particulièrement utiles pour détecter les membres du groupe central devenus inaccessibles à la suite de l'arrêt du réseau. Le taux d'utilisation de l'unité centrale atteint un certain niveau. Il est proportionnel au nombre de membres actifs dans le groupe central. La configuration par défaut des signaux de présence actifs vise à établir un équilibre entre le taux d'utilisation de l'unité centrale et une détection satisfaisante des membres défaillants.

Vous pouvez utiliser la console d'administration ou l'outil wsadmin pour configurer le délai de transmission de signaux de présence et le délai d'expiration des signaux de présence. Lisez la rubrique Configuration du protocole de détection d'incident pour un groupe central pour obtenir une description de l'utilisation de la console d'administration pour modifier ces paramètres.

[IBM i][AIX Solaris HP-UX Linux Windows]

Autres fournisseurs de protocole

Aucun autre fournisseur de protocole n'est actuellement disponible pour les plateformes IBM i et les plateformes réparties.

Autres fournisseurs de protocole

Vous pouvez utiliser un fournisseur de protocole différent du protocole de reconnaissance et du protocole de détection des incidents par défaut pour surveiller et gérer la communication entre les membres de groupe central. En règle générale, les fournisseurs de protocole secondaires, tels que le fournisseur z/OS Cross-system Coupling Facility (XCF) utilise moins de ressources que le protocole de reconnaissance par défaut et le protocole de détection d'erreur, notamment lorsque les groupes centraux sont inactifs. Un fournisseur de protocole alternatif utilise généralement moins de ressources système car il n'effectue pas l'envoi des commandes ping TCP/IP membre-à-membre que les fournisseurs de protocole par défaut utilisent pour déterminer si le membre d'un groupe central est toujours actif.

[z/OS]Si vous décidez d'utiliser le fournisseur de protocole XCF (Cross-system Coupling Facility) de z/OS, vous devez comprendre que, lors du démarrage, le processus serveur est lié à un groupe SCF en tant que membre. Le groupe XCF contient tous les membres actifs du groupe central. XCF fournit des notifications à tous les membres de ce groupe dès qu'un membre rejoint le groupe et dès qu'il ne peut plus être contacté quand le serveur est arrêté ou que XCF détermine que le serveur a cessé de fonctionner. Lorsqu'une connexion est établie entre des membre du groupe central, le fournisseur de protocole basé sur XCF (Cross-system Coupling Facility) de z/OS en informe le protocole de synchronisation de la vue et consigne cet événement sous la forme d'un message d'information, similaire à celui présenté ci-dessous, dans le fichier SystemOut.log.
DCSV1032I: Pile DCS DefaultCoreGroup au niveau du membre MyCell\anzio\nodeagent: 
Membre défini connecté MyCell\anzioCellManager\dmgr.
Avant de reconfigurer un groupe central spécifique à utiliser en tant que fournisseur de protocole alternatif, vous devez vérifier que le groupe central remplit les exigences suivantes. S'il ne les remplit pas toutes, vous devez continuer d'utiliser les protocoles de reconnaissance et de détection des incidents par défaut avec ce groupe central.
  • Le groupe central est homogène. Cela signifie que les processus du groupe central doivent tous résider sur la même plateforme. Par exemple, le groupe central ne peut pas contenir un mélange de processus z/OS et répartis.

    [z/OS]Si le groupe central contient des processus non z/OS ou qu'il est composé de membres qui se trouvent à des niveaux de version différents du produit, vous ne pouvez pas utiliser XCF pour ce groupe central.

  • Si le groupe central doit être relié à un autre groupe central, à l'aide du service de passerelle de groupe central, tous les groupes centraux liés à ce groupe central sont également des groupes centraux homogènes.
  • Tous les membres du groupe central doivent être à la version 7.x du produit. Si des membres du groupe central sont exécutés au niveau de la version 6.x du produit, vous devez les mettre à jour vers la version 7.x, avant de pouvoir passer au fournisseur de protocole alternatif.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_discovery
Nom du fichier : crun_ha_discovery.html