Paramétrage du détecteur de pannes de Sun Cluster HA for Sun Java System Application Server

Cette section présente le détecteur de pannes de Sun Cluster HA for Sun Java System Application Server.

Vous y trouverez les informations suivantes :

• description de la fonction de sonde du détecteur de pannes de Sun Cluster HA for Sun Java System Application Server ;

• conditions, messages et actions de récupération associés à une analyse infructueuse ;

• conditions et messages associés à une analyse fructueuse.

Propriétés d'extension

Le détecteur de pannes de Sun Cluster HA for Sun Java System Application Server utilise les propriétés d'extension décrites dans le tableau ci-dessous. L'entrée Réglable indique si vous pouvez mettre à jour la propriété de façon dynamique ou uniquement lors de sa création.

Utilisez la ligne de commande scrgadm -x paramètre =valeur pour configurer les propriétés d'extension lors de la création de la ressource Sun Java System Application Server. Reportez-vous à la page man SUNW.s1as(5M) pour plus d'informations sur les propriétés d'extension. Reportez-vous à la rubrique “ Standard Properties” du document Sun Cluster Data Service Planning and Administration Guide for Solaris OS pour obtenir des détails sur les propriétés du service de données Sun Cluster.

Analyse d'algorithmes et de fonctionnalités

La sonde Sun Cluster HA for Sun Java System Application Server envoie une requête au serveur pour consulter l'état du serveur Sun Java System Application Server. Elle exécute la procédure suivante :

1. Elle sonde l'instance de Sun Java System Application Server en fonction du délai d'attente défini dans la propriété de ressource Probe_timeout.

2. Elle se connecte aux combinaisons adresse IP/port définies par la configuration des ressources réseau et le paramètre Port_list du groupe de ressources. Si la ressource est configurée sans que la propriété Port_list soit vide, cette étape est ignorée. Si la connexion réussit, la sonde se déconnecte. Dans le cas contraire, l'échec est enregistré.

   La requête peut échouer en raison d'un trafic réseau intense, d'une charge système importante ou d'une configuration erronée. Cette dernière situation peut survenir si vous n'avez pas configuré le serveur Sun Java System Application Server pour qu'il attende sur toutes les combinaisons adresse IP/port sondées. Le serveur Sun Java System Application Server doit traiter chaque port de chaque adresse IP spécifiée pour la ressource.

3. Elle se connecte au serveur Sun Java System Application Server et exécute un contrôle HTTP 1.1 GET en envoyant une requête HTTP et en recevant une réponse pour tous les URI de la liste Monitor_Uri_List.

   Le résultat des requêtes HTTP est soit un échec, soit une réussite. Si toutes les requêtes ont bien reçu une réponse du serveur Sun Java System Application Server, la sonde revient et poursuit le cycle d'analyse et de veille suivant.

   La sonde HTTP GET peut échouer en raison d'un trafic réseau intense, d'une charge système importante ou d'une configuration erronée. Une configuration erronée de la propriété Monitor_Uri_List peut provoquer une panne si un URI de cette liste contient un port ou un nom d'hôte incorrect. Par exemple, si l'instance du serveur d'application écoute sur l'hôte logique schost-1 et que l'URI a été spécifiée comme http://schost-2/servlet/monitor, la sonde tente de contacter schost-2 pour solliciter /servlet/monitor.

4. Elle enregistre un échec dans le journal de l'historique si la réponse à la sonde n'arrive pas dans le délai imparti par la propriété Probe_timeout. La sonde considère cette situation comme un échec de la part du service de données de Sun Java System Application Server. Un échec de la sonde de Sun Java System Application Server peut être total ou partiel.

   Si la réponse à la sonde arrive dans le délai imparti par la propriété Probe_timeout, le code de réponse HTTP fait l'objet d'un contrôle. Si le code de réponse est 500 « erreur interne du serveur », l'analyse de la sonde est considérée comme un échec total. Tous les autres codes de réponse sont ignorés.

   Vous trouverez ci-dessous des échecs d'analyse totaux.

   • Le message d'erreur suivant est émis en cas d'échec de connexion au serveur. %s correspond au nom d'hôte, et %d au numéro de port.

     
     

     Échec de connexion à l'hôte <%s> et au port <%d>. Réception d'un code de réponse de 500 “Internal Server Error” Le code de réponse d'HTTP GET pour l'analyse de %s est 500. Basculement en cours d'exécution.

   • Le message d'erreur suivant est émis en cas d'échec de l'envoi de la chaîne d'analyse au serveur. Le premier %s correspond au nom d'hôte, %d au numéro de port, et le second %s fournit de plus amples détails sur l'erreur.

     
     

     Échec d'écriture sur le serveur : serveur %s port %d : %s.

5. Le détecteur accumule les échecs partiels survenant dans la définition de la propriété de ressource Retry_interval jusqu'à ce qu'ils équivalent à un échec total.

   Vous trouverez ci-dessous des échecs d'analyse partiels.

   • Le message d'erreur suivant est émis lorsque la déconnexion échoue avant l'écoulement du délai d'attente Probe_timeout. Le premier %d correspond au numéro de port et %s au nom de la ressource.

     
     

     Échec de déconnexion du port %d de la ressource %s.

   • L'impossibilité d'exécuter toutes les étapes d'analyse dans le délai imparti par la propriété Probe_timeout constitue un échec partiel.

   • Le message d'erreur suivant est émis lors d'un échec de lecture des données du serveur pour d'autres raisons. Le premier %s correspond au nom d'hôte, et %d au numéro de port. Le second %s fournit plus de détails sur l'erreur.

     
     

     Échec de communication avec le port %s du serveur %d : %s

6. Basée sur l'historique des pannes, une défaillance peut entraîner un redémarrage local ou une panne du service de données.