Une stratégie de santé correspond à la définition d'un critère de santé spécifique contre lequel l'environnement WebSphere Extended Deployment doit se protéger. La fonction de gestion de santé utilise la stratégie définie lorsqu'elle analyse l'environnement de serveur d'applications pour identifier les dysfonctionnements logiciels éventuels.
- Dans la console d'administration, cliquez sur Stratégies d'exploitation > Stratégies de santé > Nouveau.
- Définissez les propriétés générales de la stratégie de santé.
- Indiquez le nom de la stratégie de santé. Le nom indiqué doit être unique et respecter certains critères de dénomination.
Les critères de dénomination sont présentés dans le panneau d'aide de la console pour les stratégies de santé.
- OptionalColonSymbol Indiquez une description de la stratégie de santé.
- Sélectionnez la condition de santé. Toutes les conditions disponibles prennent en charge les redémarrages serveur comme réaction. Les conditions d'ancienneté et de charge de travail sont des stratégies basées sur la prévention alors que les autres reposent sur la détection.
- La condition d'ancienneté se déclenche lorsque des membres associés à cette stratégie atteigne une certaine valeur d'ancienneté.
- La condition de dépassement du nombre de demandes arrivées à expiration se déclenche si des demandes dirigées vers un membre associé arrivent à expiration et si le pourcentage du délai d'expiration dépasse la valeur indiquée. Cette condition prend en charge les clichés d'unités d'exécution en plus des réactions des démarrages serveur.
RestrictionColonSymbol La condition de dépassement du nombre de demandes arrivées à expiration ne s'applique pas au trafic IIOP et JMS.
- La condition de dépassement du temps de réponse se déclenche si le temps de réponse des membres associés à cette stratégie basée sur la détection est moyen pour les demandes dépassant une certaine durée.
- La condition de mémoire : utilisation excessive de la mémoire se déclenche si le taux d'utilisation de la mémoire des membres associés à cette stratégie de détection dépasse le pourcentage défini de la taille maximale des segments pendant une période donnée.
- La condition de mémoire : fuite de mémoire recherche les
tendances à la baisse régulières de mémoire disponible pour un serveur dans le segment de mémoire Java. Le niveau de détection détermine le moment où ces tendances sont détectées. Le paramètre de détection lente requiert la quantité de données d'historique la plus élevée. Les paramètres de détection rapide et de détection normale requièrent la même quantité de données d'historique, mais le paramètre de détection rapide autorise une analyse avant que le segment de mémoire Java ait atteint sa taille maximale configurée. Ceci permet une détection précoce mais sujette aux erreurs. Cette condition prend en charge les clichés de segment de mémoire en plus des redémarrages serveur utilisés comme réactions.
- La condition de drainage incorrect des demandes détecte les situations dans lesquelles les demandes transitent par un membre de cluster défaillant accusent des temps de réponse bas. Le drainage incorrect des demandes repose sur la détection des points de changement dans des données de séries temporelles précises. Pour détecter des points de changement, la condition calcule une moyenne gauche et une moyenne droite pour un point donné. Pour un point, la moyenne gauche est la valeur moyenne de N échantillons antérieurs à cet échantillon, et la moyenne droite est la valeur moyenne de N échantillons ultérieurs (incluant l'échantillon lui-même). La différence entre la moyenne gauche et la moyenne droite est stockée et comparée aux autres différences d'une fenêtre donnée associée à la valeur N pour déterminer si elle correspond à une valeur locale maximale. Si la différence est maximale, le point auquel correspond la différence est déclaré comme point de changement.
Les deux mesures utilisées pour la détection d'un drainage incorrect des demandes sont les temps de réponse et les pondérations du gestionnaire de charge de travail dynamique observés par le serveur.
La stratégie Détection rapide, probabilité de fausse alerte plus élevée utilise un nombre moins élevé d'échantillons (N=10) pour les temps de réponse et les pondérations du gestionnaire de charge de travail dynamique et tente de détecter un point de changement dans chaque mesure de l'ensemble d'échantillons. Par
conséquent, elle trouve une réponse plus rapidement car elle n'a besoin que de 20 échantillons, 10 pour la gauche et 10 pour la droite, afin de calculer la différence et de rechercher une valeur maximale locale. Les échantillons sont collectés dans des intervalles de 15 secondes. Par conséquent, le drainage incorrect des demandes peut être détecté dans les cinq minutes qui suivent son apparition. Cependant, comme le nombre d'échantillons est moins élevé, s'ils comportent beaucoup de pics ou de baisses transitoires, la probabilité de fausse alerte est plus élevée.
La stratégie Détection lente, probabilité de fausse alerte moins élevée utilise un nombre d'échantillons plus élevé (N=15) pour les temps de réponse et les pondérations du gestionnaire de charge de travail dynamique. Elle trouve donc une réponse moins rapidement car elle a besoin de 30 échantillons (15 pour la gauche et 15 pour la droite) afin de calculer la différence. Le temps de détection est de 7 minutes et 30 secondes. Etant donné que le nombre d'échantillons est plus élevé, la présence de quelques échantillons comportant des pics ou des baisses transitoires n'a pas d'impact notable. La probabilité de fausse alerte est moins élevée.
RestrictionColonSymbol La condition de drainage incorrect des demandes ne s'applique pas au trafic IIOP et JMS.
- La condition de charge de travail se déclenche si les membres associés à cette stratégie ont servi un nombre de demandes défini par l'utilisateur.
- Cliquez sur Suivant.
- Définissez les propriétés de condition de santé de la stratégie de santé. Les propriétés de la condition de santé qui s'affichent dépendent de la condition sélectionnée.
- Propriétés de la condition de santé
- Ancienneté
- Cette zone permet de définir l'ancienneté pour la condition de santé relative à l'ancienneté.
La stratégie qui définit la condition d'ancienneté entraîne le redémarrage des membres associés lorsque l'ancienneté atteint une valeur donnée. Les valeurs admises sont des entiers positifs (jours ou heures) compris entre 1 heure et 365 jours. Pour entrer une valeur telle que 1,5 jours, utilisez 36 heures, car les nombres décimaux ne sont acceptés.
- Pourcentage des demandes arrivées à expiration entraînant une violation de condition :
- Cette zone définit la valeur du seuil pour le pourcentage des demandes arrivées à expiration.
Elle accepte les nombres entiers compris entre 1 et 99.
- Temps de réponse :
- Cette stratégie redémarre les membres lorsque la durée de traitement du nombre moyen de demandes dépasse la valeur définie. Les valeurs admises pour cette zone sont comprises entre 1 milliseconde et 60 minutes. Pour les beans gérés par message, le temps de réponse repose sur le temps pris par la méthode onMessage.
Pour les clients synchrones, le temps de réponse est l'intervalle de temps entre les appels de réception d'un client sur le même objet de session.
Le temps de réponse comprend également le temps qui s'est écoulé dans les files d'attente du gestionnaire autonome de flux de demandes.
- Pourcentage de la taille de segment JVM maximale à contrôler :
- La stratégie fondée sur le dépassement de mémoire redémarre les membres lorsque l'utilisation de la mémoire dépasse un pourcentage de votre surtemps de taille de segment. Elle accepte les nombres entiers compris entre 1 et 99.
- Période pendant laquelle le seuil du segment JVM n'est pas respecté
- La stratégie fondée sur le dépassement de mémoire redémarre les membres lorsque l'utilisation de la mémoire dépasse un pourcentage de votre surtemps de taille de segment. Le pourcentage de mémoire totale utilisée est associé à la valeur de pourcentage pour déterminer quand redémarrer les membres. Les valeurs admises pour cette zone sont comprises entre 1 seconde et 60 minutes.
- Nombre total de demandes
- Cette zone est disponible lorsque la stratégie de santé sélectionnée est fondée sur la charge de travail.
La stratégie fondée sur la condition de charge de travail redémarre les membres
lorsque le nombre de demandes défini par l'utilisateur a été traité. Les valeurs admises sont les nombres entiers compris entre 1000 et 9223372036854775807.
- Niveau de détection de la condition :
- Sélectionnez l'une des options suivantes :
- Détection rapide, probabilité de fausse alerte plus élevée pour détecter une fuite de mémoire rapidement, mais le risque d'erreur d'identification d'une fuite de mémoire est plus élevé
- Détection standard, probabilité de fausse alerte normale pour détecter plus précisément mais plus lentement les fuites de mémoire potentielles
- Détection lente, probabilité de fausse alerte moins élevée pour une détection optimale des fuites de mémoire potentielles
- Réaction du moniteur de gestion de santé
- Mode de réaction
- Sélectionnez Supervisé ou Automatique. Le mode de réaction définit le niveau d'interaction de l'utilisateur lorsque la condition de gestion décide que des actions de correction sont nécessaires. En
mode supervisé, les plans d'action suggérés peuvent être approuvés avant leur exécution. Le mode automatique mène à bien tous les plans d'action suggérés sans nécessiter d'approbation. Les réactions automatiques doivent être utilisées avec précaution, notamment quand elles impliquent des redémarrages de serveurs automatiques. Le redémarrage d'un serveur compromet généralement la disponibilité continue du service.
- Sélectionnez les actions à effectuer après une violation de condition de santé
- Selon la condition de santé, vous pouvez sélectionner une ou plusieurs actions à effectuer en cas de violation de l'une de ces conditions.
- Redémarrer le serveur
- Prendre des clichés d'unités d'exécution
- Prendre des clichés de segments JVM sur IBM Java Development Kit (JDK) uniquement
- Cliquez sur Suivant. Les sous-fenêtres suivantes vous invitent à sélectionner les cibles de la stratégie.
- Sélectionnez les appartenances à contrôler pour votre stratégie de santé. Lorsque les types de membre figurent dans la liste Membres disponibles, sélectionnez les types à contrôler et cliquez sur Ajouter.
- Serveurs d'applications et noeuds
- Clusters
- Clusters dynamiques
- Cellules
Les couches logiques peuvent s'appliquer aux appartenances contrôlées. Par exemple, vous pouvez être amené à appliquer une stratégie de santé spécifique à tous les membres d'un cluster et à un serveur d'applications situé hors du cluster. Sélectionnez
le serveur d'applications dans le panneau correspondant et les clusters dans le panneau du serveur d'applications, qui doit comporter tous les serveurs d'applications existants et potentiels du cluster. Les membres de clusters appliquent une logique supplémentaire pour réduire au minimum l'incidence des réactions sur le service.
- Cliquez sur Suivant.
- Examinez votre nouvelle stratégie et cliquez sur Terminer. Une option de sauvegarde s'affiche dans le haut de la fenêtre de la console.
- Cliquez sur Sauvegarder. Une fenêtre comportant les options Sauvegarder et Ignorer s'affiche.
Cliquez de nouveau sur Sauvegarder pour valider la nouvelle stratégie.
Résultat
Vous avez créé une stratégie de santé que vous avez appliquée à un environnement cible.
Que faire ensuite
L'étape suivante consiste à activer la fonction de gestion de santé. Une fois la fonction activée, la stratégie de santé peut prendre des décisions pertinentes et collaborer avec la fonction de positionnement d'application pour s'assurer que les conditions entraînant un redémarrage n'ont pas d'incidence sur les travaux en cours. Pour plus d'informations, voir
Activation et désactivation de la gestion de santé.