test

Guide des services de données Sun Cluster pour Sun Java System Application Server pour SE Solaris

Réglage du détecteur de pannes pour Sun Cluster HA pour Sun Java System Application Server

Le détecteur de pannes pour Sun Cluster HA pour Sun Java System Application Server versions antérieures à 8.1 est contenu dans une ressource du type SUNW.s1as.

Les propriétés du système et les propriétés d'extension des types de ressources contrôlent le comportement des détecteurs de pannes. Les valeurs par défaut de ces propriétés déterminent le comportement prédéfini des détecteurs de pannes. Le comportement prédéfini doit être adapté à la plupart des installations Sun Cluster. Par conséquent, vous devez régler les détecteurs de pannes uniquement si vous devez modifier ce comportement prédéfini.

Le réglage des détecteurs de pannes implique l'exécution des tâches suivantes :

Exécutez ces tâches lorsque vous enregistrez et configurez Sun Cluster HA pour Sun Java System Application Server, comme décrit dans la section Enregistrement et configuration de Sun Cluster HA pour Sun Java System Application Server Versions antérieures à 8.1.

Pour de plus amples informations sur ces tâches, reportez-vous à la section Tuning Fault Monitors for Sun Cluster Data Services du Sun Cluster Data Services Planning and Administration Guide for Solaris OS.

Vous y trouverez les informations suivantes :

Opérations exécutées par le détecteur de pannes Sun Cluster HA pour Sun Java System Application Server lors d'une analyse

La sonde du détecteur de pannes Sun Cluster HA pour Sun Java System Application Server envoie une requête au serveur pour identifier l'état de fonctionnement du serveur Sun Java System Application Server. Elle exécute la procédure suivante :

  1. Le détecteur de pannes sonde l'instance Sun Java System Application Server pendant le délai d'attente défini par la propriété de ressources Probe_timeout.

  2. La sonde se connecte à l'adresse IP et aux associations de port définies par la configuration de ressources réseau et le réglage Port_list pour le 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. La sonde se connecte au serveur Sun Java System Application Server et effectue une vérification HTTP 1.1 GET en envoyant une requête HTTP à chacun des URI de la liste Monitor_Uri_List, et en en recevant une réponse.

    Le résultat de chaque requête HTTP est un échec ou 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. Si la propriété Monitor_Uri_List est mal configurée et qu'un URI de la liste Monitor_Uri_List inclut un port ou un nom d'hôte incorrect, le résultat enregistré peut être considéré comme une erreur. Par exemple, si l'instance du serveur d'application effectue une écoute sur l'hôte logique schost-1 et que l'URI a été spécifié comme http://schost-2/servlet/monitor, la sonde tente de contacter schost-2 pour interroger /servlet/monitor .

  4. Elle enregistre une erreur dans le journal si elle ne reçoit pas de réponse dans le délai imparti (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 délai_sonde, 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. 


      Failed to connect to the host <%s> and port <%d>. Receiving a
response code of 500 Internal Server Error HTTP GET
Response Code for probe of %s is 500. Failover will be in
progress

    • 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. 


      Write to server failed: server %s port %d: %s.

  5. Le moniteur accumule les échecs partiels qui se produisent dans la définition de la propriété de ressource Retry_interval jusqu'à obtenir 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 Délai_sonde. Le %d indique le numéro de port et le %s le nom de la ressource. 


      Failed to disconnect from port %d of resource %s.

    • L'impossibilité d'exécuter toutes les étapes d'analyse dans le délai imparti dans Délai_sonde constitue un échec partiel.

    • Le message d'erreur suivant s'affiche en cas d'échec de lecture des données du serveur pour d'autres raisons. 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 de communication avec le port %d du serveur %s : %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.