Création d'une stratégie de santé : définition des propriétés générales d'une stratégie de santé

Cette page permet de créer des stratégies de santé, qui effectuent diverses évaluations de la santé des clusters, des clusters dynamiques et des instances de serveur d'applications s'exécutant sur les noeuds.

Pour afficher cette page de la console d'administration, cliquez sur Stratégies d'exploitation > Stratégies de santé > Nouveau.

Les privilèges des stratégies de santé diffèrent selon le rôle de l'utilisateur. Moniteur, Opérateur, Configurateur et Administrateur sont les rôles disponibles. Si vous êtes un utilisateur doté du rôle Moniteur ou Opérateur, vous pouvez uniquement afficher les informations de la stratégie de santé. En revanche, si vous êtes un utilisateur doté du rôle Configurateur ou Administrateur, vous disposez de tous les privilèges de configuration des stratégies de santé.

Lorsque vous avez rempli toutes les zones requises, cliquez sur Suivant pour continuer.

Nom

Nom de la stratégie de santé. Le nom de la stratégie de santé est requis et doit être unique parmi toutes les autres stratégies de la cellule.

Le nom de l'application ne peut pas commencer par un point (.) ni un espace. Un espace ne provoque pas d'erreur mais tout espace placé au début ou à la fin du nom est supprimé automatiquement. Utilisez des noms de stratégies de santé significatifs et cohérents. Par exemple, les stratégies de santé basées sur l'ancienneté peuvent être spécifiées en nommant les stratégies ANCIENNETE_20JOURS, ANCIENNETE_15JOURS, et ainsi de suite.

Description

Description supplémentaire de la stratégie de santé. La description est facultative. Vous pouvez la modifier lorsque vous créez ou supprimez une stratégie de santé. Pensez à utiliser la description facultative lorsque vous utilisez de nombreuses stratégies de santé ou lorsque plusieurs administrateurs gèrent le même ensemble de stratégies de santé.

Condition de santé prédéfinie

La condition de santé définit la stratégie mise en oeuvre. Les conditions de santé prédéfinies sont celles fournies avec WebSphere Extended Deployment.

Certaines stratégies sont basées sur la prévention, d'autres sur la détection. Les stratégies basées sur la prévention permettent d'éviter les conditions pouvant provoquer des problèmes, tandis que les stratégies basées sur la détection identifient les conditions existantes et offrent une résolution. Vous pouvez utiliser ces stratégies pour effectuer des évaluations fondées sur la santé des clusters, des clusters dynamiques et des instances de serveur d'applications exécutées sur les noeuds. Dans le cas des clusters dynamiques, et quelle que soit la stratégie de santé utilisée, le nombre minimal d'instances de cluster dynamique reste actif.

  • La condition basée sur l'ancienneté redémarre les membres associés lorsque leur ancienneté atteint la valeur d'ancienneté maximale. Ce redémarrage efface toutes les données acquises mises en cache et en mémoire. Si vous sélectionnez une condition basée sur l'ancienneté, vous devez définir les critères d'ancienneté. La condition basée sur l'ancienneté est prise en charge sur tous les types de serveurs.
  • La condition de dépassement du nombre de demandes arrivées à expiration effectue le suivi de la mémoire utilisée pour les demandes arrivant à expiration. Lorsque le pourcentage des demandes arrivant à expiration dépasse la limite de la condition, les membres sont redémarrés. Si vous sélectionnez cette condition, vous devez définir le seuil de pourcentage de mémoire utilisée. La condition de dépassement du nombre de demandes arrivées à expiration est prise en charge sur tous les types de serveurs.
    Restriction : La condition de dépassement du nombre de demandes arrivées à expiration ne s'applique pas au trafic JMS (Java Message Service) et IIOP (Internet Inter-ORB Protocol).
  • La stratégie de la condition de dépassement de temps de réponse effectue le suivi des demandes et la durée d'exécution requise. Utilisez cette stratégie pour nettoyer les serveurs ayant un nombre moyen de demandes dont l'exécution dépasse un délai prédéfini. Dans le cas d'un tel dépassement, les membres sont redémarrés. Lorsque vous sélectionnez la stratégie de dépassement de temps de réponse, vous devez définir le seuil du temps de réponse. La condition de dépassement du temps de réponse est prise en charge sur tous les types de serveurs.
  • La condition de mémoire : dépassement de mémoire effectue le suivi de l'utilisation de mémoire correspondant à un membre. Lorsque l'utilisation de la mémoire dépasse un certain pourcentage de la taille de segment et ce pendant une durée définie, des actions sont entreprises pour corriger la situation. Si vous définissez la stratégie de santé sur un serveur autonome, un cluster statique ou un cluster dynamique en mode manuel, le membre s'arrête et redémarre. Si vous définissez la stratégie de santé sur un cluster dynamique en mode automatique ou supervisé, le membre marqué par la condition s'arrête. Le cas échéant, le contrôleur de positionnement décide de manière dynamique quels serveurs doivent être démarrés en fonction de son évaluation de l'environnement. Ces actions sont exécutées automatiquement si vous êtes en mode automatique. Si vous êtes en mode supervisé, vous pouvez approuver les tâches d'exécution qui sont générées pour corriger la situation. Lorsque vous sélectionnez la stratégie de dépassement de temps de réponse, vous devez définir la mémoire utilisée et le seuil de dépassement du temps de réponse. La condition de dépassement de mémoire est prise en charge uniquement sur des serveurs d'applications sur des noeuds exécutant WebSphere Application Server ou WebSphere Application Server Community Edition. Il n'est pas possible de définir la condition de dépassement de mémoire pour d'autres types de serveurs middleware.
  • La stratégie condition de mémoire : fuite de mémoire effectue le suivi des tendances régulières de baisse de la mémoire disponible pour un serveur dans le segment Java. Le paramètre de détection de niveau détermine le moment où ces tendances sont détectées. Lorsque vous sélectionnez la stratégie condition de mémoire : fuite de mémoire, vous devez définir un niveau de détection. Le niveau de détection le plus lent nécessite la quantité maximale de données historisées. Les niveaux de détection normal et rapide nécessitent la même quantité de données historisées, mais la détection rapide autorise l'analyse avant que le segment Java n'ait atteint sa taille maximale configurée. Ceci permet une détection anticipée, mais plus encline aux faux positifs. Cette condition prend en charge les clichés de segment de mémoire, en plus des redémarrages de serveur comme réactions. La condition de fuite de mémoire n'est pas prise en charge pour d'autres types de serveurs middleware.
  • La stratégie condition de drainage incorrect des demandes effectue le suivi des demandes restées bloquées. Le serveur associé à cette stratégie redémarre lorsque le niveau de détection indiqué est atteint. La détection de drainage incorrect des demandes fait appel à la détection des points de transition dans des données de série temporelle précises. Les critères de mesure utilisés pour détecter un drainage incorrect des demandes sont les temps de réponse et les pondérations du gestionnaire de charge de travail de déploiement qui sont observés pour le serveur. La condition de drainage incorrect des demandes s'applique uniquement aux clusters dynamiques et aux cellules. Si vous sélectionnez cette stratégie, vous devez sélectionner le niveau de détection.

    Pour détecter des points de transition, le contrôleur de santé calcule une moyenne de gauche et une moyenne de droite pour un point donné. Pour un point, la moyenne de gauche correspond à la valeur moyenne de N échantillons qui arrivent avant cet échantillon et la moyenne de droite est la valeur moyenne de N échantillons, y compris le point en cours, qui arrivent après. La différence des valeurs moyennes de gauche et de droite est enregistrée et comparée à d'autres différences dans un ensemble de valeurs à N pour déterminer si cette différence est un maxima local. Si cette différence correspond à la différence maximale, alors le point auquel cette différence correspond, est appelé point de transition. Les deux métriques utilisées pour détecter un drainage incorrect des demandes sont les temps de réponse et les pondérations du gestionnaire de charge de travail dynamique qui sont observés pour le serveur.

    La condition de drainage incorrect des demandes est prise en charge sur tous les types de serveurs.
    Restriction : La condition de drainage incorrect des demandes ne s'applique pas au trafic JMS et IIOP.
  • La stratégie de condition de charge de travail redémarre les membres lorsqu'un certain nombre de demandes définies par l'utilisateur a été traité. Cette stratégie efface la mémoire et les caches. Lorsque vous sélectionnez la stratégie de charge de travail, vous devez définir les critères du nombre total de demandes. La condition de charge de travail est prise en charge sur tous les types de serveurs.
Condition de santé personnalisée

Vous pouvez définir des conditions de santé si les conditions existantes ne répondent pas à vos besoins. Les conditions de santé personnalisées peuvent être testées à l'aide de métriques dans votre environnement.




Centre de documentation de WebSphere Extended Deployment (en ligne)

Informations connexes
Collection de stratégies de santé
Paramètres des stratégies de santé
Création d'une stratégie de santé : définition des propriétés de condition de santé
Création d'une stratégie de santé : spécification des membres à contrôler
Collection d'actions personnalisées
Paramètres des actions personnalisées

hc_detail_main_new