[AIX Solaris HP-UX Linux Windows][z/OS]

Intelligent Management : identification et résolution des incidents liés à la gestion de santé

Vous pouvez rechercher les incidents ci-dessous lorsque Health Management Controller ne fonctionne pas correctement ou ne s'exécute pas comme vous le souhaitez.

Recherche des journaux corrects

Le contrôleur de santé est une ressource distribuée qui est gérée par le gestionnaire de haute disponibilité. Il existe dans tous les processus d'agent de noeud et de gestionnaire de déploiement et est activé dans l'un d'entre eux. Si un processus échoue, le contrôleur devient actif dans un autre processus d'agent de noeud ou de gestionnaire de déploiement.

Pour déterminer l'emplacement d'exécution du contrôleur de santé, cliquez sur Opérations d'exécution > Stabilité du composant > Composants centraux dans la console d'administration. L'emplacement et l'état de stabilité du contrôleur de santé s'affichent.

L'assistant de performances est activé avec la stratégie de santé pour la fuite de mémoire par défaut.

La stratégie de santé pour la fuite de mémoire prédéfinie utilise la fonction d'assistant de performances ; par conséquent, l'assistant de performances est activé lorsque des membres sont affectés à cette stratégie. Pour désactiver l'assistant de performances, supprimez cette stratégie de santé ou limitez les membres de la stratégie de santé. Pour conserver la stratégie de santé pour une utilisation ultérieure, conservez la stratégie de santé pour la fuite de mémoire par défaut, mais supprimez tous les membres. Pour modifier les membres, cliquez sur Stratégies opérationnelles > Stratégies de santé > default_memory_leak. Vous pouvez modifier les membres de la stratégie de santé en ajoutant ou en supprimant des membres.

Paramètres du contrôleur de santé

Voici la liste des incidents que vous pouvez rencontrer lors de la définition des paramètres du contrôleur de santé :
Le contrôleur d'état est désactivé
Pour vérifier le paramètre dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de santé, sélectionnez les onglets Configuration et Exécution. Le contrôleur de santé est activé par défaut.
Les redémarrages ne sont pas autorisés pour le moment.
Pour vérifier les heures de redémarrage interdites dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de santé et sélectionnez la zone Heures de redémarrage interdites. Par défaut, aucune heure interdite n'est définie.
Redémarrage prématuré après le redémarrage précédent
Pour vérifier l'intervalle de redémarrage minimal dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de santé et modifiez la zone Intervalle minimal entre les redémarrages. Aucun intervalle minimal n'est défini par défaut.
Cycle de contrôle trop long
Pour vérifiez la longueur du cycle de contrôle dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de santé et ajustez la valeur si nécessaire. Le contrôleur de santé vérifie régulièrement si les stratégies sont respectées. Si le cycle de contrôle défini est trop long, il est possible que les serveurs ne soient pas redémarrés assez rapidement.
Le serveur a été redémarré X fois à la suite et la condition de santé n'est toujours pas respectée.
Dans ce cas, X indique le paramètre de nombre maximal de redémarrages consécutifs du contrôleur de santé. Le contrôleur de santé en conclut que les redémarrages ne permettent pas de résoudre le problème et désactive l'option pour le serveur. Le message suivant s'affiche dans le journal :
WXDH0011W: Le nombre maximal d'échecs de vérification a été dépassé pour le serveur nom_serveur : désactivation des redémarrages.
Le contrôleur de santé continue de surveiller le serveur et consigne des messages dans le journal si la stratégie de santé n'est pas respectée :
WXDH0012W: La vérification de santé du serveur servername avec désactivation des redémarrages a échoué.
Vous pouvez autoriser les redémarrages du serveur en effectuant l'une des actions suivantes :
  • Désactiver puis activer le contrôleur de santé.
  • Adapter la valeur définie pour le paramètre du contrôleur Nombre maximal de redémarrages consécutifs.
  • Exécuter la commande suivante à partir de l'invite de commande :
    wsadmin -profile HmmControllerProcs.jacl enableServer servername
    Ce script se trouve dans le répertoire <racine_serveur_app>\bin des noeuds d'agent de noeud et de gestionnaire de déploiement. Ce script nécessite un gestionnaire de déploiement actif.

Paramètres de stratégie de santé

Voici la liste des incidents que vous pouvez rencontrer lors de la définition des paramètres de stratégie de santé :
Le serveur n'est pas inclus dans les stratégies de santé.
Pour vérifier que les stratégies d'adhésion aux stratégies de santé s'appliquent à votre serveur dans la console d'administration, cliquez sur Stratégies d'exploitation > Stratégie de santé.
Le mode de réaction d'une règle contenant le serveur est en mode Supervisé.
Pour vérifier la console d'administration, cliquez sur Administration du système > Gestion des tâches > Tâches d'exécution. Recherchez des demandes d'approbation correspondant à une action de redémarrage pour une règle en mode Supervisé. Les serveurs sont redémarrés automatiquement quand vous choisissez Automatique. Le message suivant est inscrit dans le journal pour une condition supervisée :
WXDH0024I: Le serveur nom_serveur a violé la condition de santé stratégie de santé, 
le mode de réaction est en mode d'exploitation supervisé.
Le serveur est membre d'un cluster statique et il s'agit du seul membre du cluster en cours d'exécution
La stratégie de santé n'arrête pas simultanément tous les membres d'un cluster. Si un cluster ne possède qu'un seul membre ou qu'un seul membre de cluster est en cours d'exécution, il n'est pas redémarré.
Le serveur est membre d'un cluster dynamique. Le nombre d'instances actives ne dépasse pas la valeur minimale et le contrôleur de positionnement est désactivé
Pour vérifier le nombre minimal d'instances requis pour le cluster dynamique, cliquez sur Serveurs > Clusters > Clusters dynamiques dans la console d'administration. Dans ce cas, Health Management Controller traite le cluster dynamique comme un cluster statique en utilisant le nombre minimal de paramètres d'instance défini.
Le contrôleur de santé n'a pas reçu la stratégie
Le contrôleur de santé ne s'exécute pas sur le gestionnaire de déploiement où les stratégies de santé sont créées. Si le gestionnaire de déploiement a été redémarré après le lancement du contrôleur de santé, il est possible que le contrôleur de santé ne dispose pas de la nouvelle stratégie.
Pour résoudre ce problème, exécutez les étapes suivantes :
  1. Désactivation du contrôleur de santé. Dans la console d'administration, cliquez sur Stratégies d'exploitation > Gestionnaires autonomes > Contrôleur de santé.
  2. Synchronisation des référentiels de configuration avec les noeuds dorsaux. Dans la console d'administration, cliquez sur Administration du système > Noeuds. Sélectionnez les noeuds à synchroniser, puis cliquez sur Synchroniser.
  3. Redémarrage du contrôleur de santé. Dans la console d'administration, cliquez sur Stratégies d'exploitation > Gestionnaires autonomes > Contrôleur de santé.
  4. Synchronisation des référentiels de configuration avec les noeuds dorsaux. Dans la console d'administration, cliquez sur Administration du système > Noeuds. Sélectionnez les noeuds à synchroniser, puis cliquez sur Synchroniser.

Interactions du contrôleur de positionnement d'application

Voici la liste des incidents déclenchés par des interactions du contrôleur HMC et du contrôleur de positionnement d'application :

Le serveur est membre d'un cluster dynamique mais le contrôleur de positionnement ne peut pas être contacté.
Pour les membres d'un cluster dynamique, le gestionnaire de santé vérifie avec le contrôleur de positionnement d'application si un serveur peut être redémarré. Si le contrôleur de positionnement d'application est activé mais qu'il ne peut pas être contacté, le message suivant est consigné dans le journal :
WXDH1018E: Impossible de contacter le serveur de positionnement
Vérifiez que le contrôleur de positionnement s'exécute Pour déterminer l'emplacement d'exécution du contrôleur de santé, cliquez sur Opérations d'exécution > Stabilité du composant > Composants centraux dans la console d'administration. L'emplacement et l'état de stabilité du contrôleur de santé s'affichent. Le contrôleur de santé consigne des messages sur le gestionnaire de déploiement ou l'agent de noeud particulier indiqué par l'emplacement actuel.
Le serveur est arrêté mais non démarré.
Dans un cluster dynamique, la procédure de redémarrage peut prendre plusieurs formes :
  • Redémarrage standard (arrêt du serveur et redémarrage du serveur).
    Remarque : Cela se produit systématiquement lorsqu'un cluster dynamique est en mode manuel.
  • Démarrage de l'instance du serveur sur un autre noeud et arrêt du serveur défaillant.
  • Arrêt du serveur défaillant uniquement, en supposant que les autres instances d'application peuvent satisfaire la demande.

Problèmes liés aux données de détection

Voici la liste des incidents liés aux paramètres d'appartenance de gestion de santé et de groupe de noeuds :

Aucune information de détecteur n'est reçue pour le serveur.
Health Management Controller ne peut pas détecter de violation des stratégies s'il ne reçoit pas les données des détecteurs requis par la stratégie. Si aucune donnée de détecteur n'est reçue lors du cycle de contrôle, la gestion de santé affiche le message de journal suivant :
WXDH3001E: Aucune donnée de capteur reçue pendant le cycle de contrôle du serveur nom_serveur pour la 
classe de santé stratégieSanté.
Pour les conditions liées au temps de réponse, Health Management Controller reçoit les données envoyées par le routeur ODR (On-Demand Router). Aucune donnée n'est générée dans ces situations tant que des demandes ne sont pas envoyées via le routeur ODR.

Statut de gestion des tâches

Parfois, le statut d'une tâche Action de redémarrage devient Echec ou Inconnu. Tel est le cas lorsque le serveur ne s'arrête pas au cours de la période de temps allouée par défaut ou lorsque la tâche expire. Utilisez la propriété de niveau cellule suivante pour ajuster le délai d'attente pour votre environnement : HMM.StopServerTimeout. La valeur est exprimée en millisecondes et il s'agit de 10000 par défaut. Cette propriété permet à la gestion de santé d'augmenter le délai d'attente pour les notifications d'arrêt du serveur qui sont reçues de la configuration On Demand.

Pour augmenter le délai d'attente pour votre environnement, sélectionnez Stratégies d'exploitation > Gestionnaires autonomes > Contrôleur de santé > Délai de redémarrage. La valeur par défaut est 5 minutes. La tâche de redémarrage démarre au bout de deux fois le temps spécifié, ce qui permet au serveur de s'arrêter et de redémarrer.


Icône indiquant le type de rubrique Rubrique de référence



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=rwve_odhealthfail
Nom du fichier : rwve_odhealthfail.html