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

Configuration du gestionnaire autonome de flux de demandes

Vous pouvez adapter les paramètres du gestionnaire ARFM (ARFM) en modifiant les valeurs par défaut dans la console d'administration. Vous pouvez activer le gestionnaire autonome de flux de demandes en définissant une propriété personnalisée.

Avant de commencer

Pour modifier les paramètres du gestionnaire autonome de flux de demandes, vous devez disposer des privilèges d'opérateur, de configurateur ou d'administrateur. Les opérateurs peuvent uniquement afficher les informations de la page de configuration, mais ils peuvent modifier les paramètres de la page d'exécution. Le configurateur peut changer les paramètres dans l'onglet de configuration mais ne peut pas les changer dans l'onglet d'exécution. Les administrateurs disposent de tous les privilèges.

Lorsque la sécurité est activée, vous ne pouvez pas modifier certaines zones sans posséder les droits d'accès appropriés.

Pourquoi et quand exécuter cette tâche

Le gestionnaire de flux de demandes autonome contient les composants suivants :
  • Un contrôleur par cellule cible, comme une cellule à laquelle une passerelle ARFM envoie directement des travaux. Il s'agit d'un objet HAManagedItem exécuté dans n'importe quel agent de noeud ou gestionnaire de déploiement.
  • Une passerelle par combinaison utilisée de famille de protocoles, processus proxy et cible de déploiement. Une passerelle s'exécute dans son processus proxy. Pour HTTP et SIP (Session Initiation Protocol), les processus proxy sont les routeurs On Demand ; pour JMS (Java™ Message Service) et IIOP (Internet Inter-ORB Protocol), les processus proxy sont les serveurs d'applications WebSphere Application Server.
  • Une estimation du facteur de travail par cellule cible, qui est un processusHAManagedItem exécutable sur n'importe quel agent de noeud, routeur ou gestionnaire de déploiement.
Les passerelles interceptent et placent en file d'attente les demandes HTTP, SIP, JMS et IIOP entrantes alors que le contrôleur vérifie les signaux, ou instructions, envoyés aux passerelles et au contrôleur de positionnement. Le profileur de travaux évalue en permanence les besoins des différents types de demandes, en fonction des observations effectuées sur le système en cours d'exécution. Ensemble, ces composants définissent de manière appropriée la priorité des demandes entrantes.

[z/OS]La fonction de positionnement dynamique associée au planificateur de travaux n'est pas prise en charge sur les serveurs z/OS.

Procédure

  1. Modifiez les paramètres du gestionnaire ARFM appropriés. Dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Gestionnaire autonome de flux de demandes.
  2. Cliquez sur OK ou sur Valider après avoir apporté les modifications.
  3. Cliquez sur Sauvegarder pour enregistrer les modifications apportées au référentiel principal.
  4. Testez les paramètres que vous venez de définir et modifiez-les aussi souvent que vous le souhaitez pour obtenir les performances désirées.

Activation du gestionnaire autonome de flux de demandes reposant sur des noeuds

Le tableau ci-dessous donne des instructions spécifiques pour la configuration de chaque paramètre.
Tableau 1. Propriétés de configuration du gestionnaire ARFM
Zone Rôle Conseils pour définir une valeur
Période d'agrégation Chaque passerelle ARFM transmet régulièrement des séries de statistiques. Ce paramètre permet de définir la période. Les statistiques générées par le support des passerelles : la présentation d'exécution sous forme graphique dans la console d'administration, l'exploitation des contrôleurs ARFM, du contrôleur de positionnement d'application et des profileurs de tâches.

Lorsque vous définissez la période d'agrégation, veillez à indiquer une valeur suffisamment élevée pour collecter un nombre suffisant d'échantillons de performances. Des échantillons sont collectés par les passerelles pour chaque demande. Plusieurs centaines d'échantillons sont nécessaires pour obtenir des valeurs statistiques pertinentes.

A titre d'exemple, des demandes associées à une classe de service s'exécutent en 250 millisecondes et 10 demandes sont en moyenne exécutées simultanément. La valeur de simultanéité est calculée automatiquement par WebSphere Extended Deployment, en fonction de la taille du cluster et des ressources de l'environnement. Cette valeur est affichée dans les panneaux de la fonction de visualisation, sous la catégorie Opérations d'exécution de la console. En conséquence, la classe de service traite environ 40 demandes par seconde. L'association de la valeur 15 secondes au paramètre Période d'agrégation génère donc une série de 600 échantillons pour chaque période d'agrégation. Les mesures fournies par une analyse de 600 échantillons sont pertinentes et fiables.

La définition d'une période d'agrégation trop courte génère des mesures de performances inexploitables. Les mesures de performances provenant d'un nombre limité d'échantillons sont moins fiables que celles issues d'un nombre d'échantillons plus élevé. Comme le contrôleur ARFM est activé lorsque de nouvelles statistiques sont générées, la définition d'une valeur trop élevée pour la période d'agrégation entraîne un calcul moins fréquent des paramètres de contrôle. La fonction Gestion intelligente est donc moins réactive en cas de modifications brutales du trafic.

Longueur minimale du cycle de contrôle Ce paramètre détermine la fréquence d'activation du contrôleur ARFM. L'activation du contrôleur est une procédure consistant à évaluer les données entrées et à définir de nouveaux paramètres de contrôle en fonction de ces informations. La procédure d'activation d'un contrôleur ARFM est initiée lorsque de nouvelles statistiques sont transmises par l'une de ses passerelles ET lorsque le contrôleur n'a encore jamais été activé ou que le délai écoulé depuis la dernière activation est supérieur ou égal à la longueur minimale du cycle de contrôle. Ce paramètre permet de déterminer la longueur du cycle de contrôle et de l'associer à une valeur plus faible. Par exemple, si vous disposez d'un seul routeur ODR et définissez une période d'agrégation de 60 secondes, il est possible qu'une première activation soit effectuée à 12:00:00.0 et qu'une seconde soit lancée 90,1 secondes plus tard, à 12:01:30.1 car l'heure de réception des statistique précédente était 12:00:59.9. Pour garantir un cycle de contrôle fiable de 60 secondes environ, définissez une valeur de 58 ou 59 secondes pour le paramètre Longueur minimale du cycle de contrôle.
Fenêtre de lissage Ce paramètre permet de définir la façon dont le contrôleur ARFM réagit aux statistiques envoyées par les passerelles en autorisant une concaténation des statistiques émises par les passerelles. Pour chaque passerelle, le contrôleur ARFM associé utilise la moyenne des derniers rapports de statistiques de cette passerelle. La fenêtre de lissage contrôle le nombre de rapports qui sont associés.

Si le paramètre Fenêtre de lissage est associé à une valeur faible, le contrôleur est plus sensible aux statistiques et réagit plus rapidement. Toutefois, une valeur faible entraîne également une réaction aux anomalies figurant dans les données.

La valeur définie pour la fenêtre de lissage et la période d'agrégation doivent être à peu près identiques à celle de la longueur de cycle de contrôle réelle, qui est parfois sensiblement supérieure à la longueur minimale du cycle de contrôle.

Longueur maximale de la file d'attente

Ce paramètre permet de lier la longueur de chaque file d'attente ARFM à un nombre maximal de demandes qui peuvent être placées en file d'attente. ARFM divise l'ensemble du trafic entrant en flux et affecte une file d'attente distincte à chaque flux. Les particularités du flux incluent des demandes qui ont une classe de service particulière, qui sont servies sur une cible de déploiement particulière ou transitent par un routeur ODR particulier.

Lorsqu'une demande arrive et que sa file d'attente est saturée, la demande est rejetée.

La définition d'une valeur faible dans cette zone accroît le risque de rejet d'une demande en raison d'une augmentation passagère du trafic ; une valeur plus élevée peut permettre de conserver les demandes plus longtemps dans les files d'attente. Les demandes mises en file d'attente utilisent de la mémoire. La valeur par défaut est 1000 mais vous pouvez tester d'autres valeurs pour déterminer celle qui est la mieux adaptée à votre environnement.
Utilisation maximale de l'unité centrale

Outre ses fonctions de définition des priorités, le contrôleur ARFM protège les systèmes contre les risques de surcharge. Il place les demandes en file d'attente sur ses passerelles pour éviter la surcharge des serveurs d'applications.

Dans la présente version, la charge est évaluée en termes d'utilisation du processeur au premier niveau des serveurs d'applications. Le paramètre Utilisation CPU maximale indique au contrôleur ARFM la charge à affecter aux serveurs. Dans des conditions où le taux d'utilisation est particulièrement élevé, cette limite peut être brièvement dépassée.

La définition de valeurs élevées permet une meilleure utilisation des ressources. Des valeurs plus faibles assurent un fonctionnement plus fiable. La charge réelle est variable. Les techniques de gestion des performances de l'environnement Gestion intelligente réagissent aux modifications de la charge à traiter avec un certain retard. Au cours de cette période de réaction, le système peut fonctionner hors de sa région configurée ; cela signifie que le taux d'utilisation du processeur est supérieur à la valeur configurée. La défaillance des mécanismes de communication internes a été constatée lors de l'exécution d'un serveur d'applications avec un taux d'utilisation du processeur de 100 % pendant plusieurs minutes, au détriment de nombreuses fonctions.

La gestion des performances de cette version de Gestion intelligente ne fonctionne pas correctement si le premier niveau de serveurs d'applications traite d'autres travaux, en plus des demandes WebSphere transmises par HTTP via les routeurs ODR.

Ce paramètre a un impact sur le positionnement d'application. Si les besoins totaux prévus dépassent la limite d'utilisation maximale de l'unité centrale, le contrôleur de positionnement réduit uniformément les besoins de tous les clusters dynamiques avant de calculer le positionnement optimal.

Associez la propriété personnalisée arfmManageCpu à false pour désactiver la protection contre les surcharges du processeur et la définition de la priorité des demandes. La propriété arfmManageCpu est une propriété personnalisée de cellule que vous devez créer.

Vous pouvez définir l'utilisation de l'unité centrale comme suit :
  • Pour VMWare, configurez Intelligent Management de sorte qu'il communique avec VMWare vCenter et obtienne des statistiques exactes. Intelligent management obtient alors directement l'utilisation de l'unité centrale depuis VMWare vCenter.
  • Pour Solaris Zones, vous devez exécuter un agent de noeud WebSphere sur la zone globale pour que l'utilisation d'unité centrale sur les zones non-globales soit correctement renvoyée par WebSphere Virtual Enterprise. Dans ce cas, l'unité centrale est obtenue à partir de la zone globale via la commande suivante, où l'utilisation d'unité centrale correspond à la valeur de la zone current_clock_Hz :
    /usr/bin/kstat -m cpu_info
  • Linux utilise le temps volé. Si la valeur true est activée pour la propriété de cellule personnalisée enableStealTimeCalculation et que la valeur de maxStealTime est définie (3 par défaut), exécutez la commande suivante :
    100 - idle cpu + idle cpu x (steal/max steal) 
    sinon, la formule est :
    100 - cpu en veille
  • AIX n'utilise pas le temps volé, mais la formule suivante :
    CPU usage time/time
Contrôle d'admission pour la protection contre la surcharge de l'unité centrale

L'objectif du contrôle d'admission pour la protection contre la surcharge du processeur consiste à ne pas accepter, délibérément, des dialogues reposant sur des jugements relatifs à la quantité de travail pouvant être acceptée sans provoquer de surcharge sur les noeuds gérés et compromettre le temps de réponses des messages acceptés.

La valeur définie pour le contrôle d'admission pour la protection contre la surcharge de l'unité centrale est valable uniquement pour les demandes HTTP et SIP ; elle ne s'applique pas aux demandes IIOP et JMS.

Vous pouvez l'activer lorsque la mise en file d'attente, qui permet d'éviter la surcharge du processeur, n'est pas suffisante, c'est-à-dire lorsqu'il est important de refuser certaines charges délibérément.

Désactivé par défaut. Pour le configurer :
  1. Définissez des stratégies de service avec des objectifs de performance puis définissez le type d'objectif des stratégies comme non discrétionnaire et associez-le à "temps de réponse" ou "centile".
  2. Dans le panneau ARFM, définissez une valeur pour la limite d'utilisation de l'unité centrale ne dépassant pas 90 %. Sélectionnez le troisième bouton pour Stratégie de rejet. La stratégie de rejet indique si le contrôle d'admission pour la protection contre la surcharge du processeur est activé et, si tel est le cas, la façon dont le seuil de temps de réponse utilisé pour le contrôle d'admission est lié au seuil de temps de réponse qui figure dans l'objectif de performances.
  3. Définissez la propriété personnalisée appelée arfmInitialMsgDlgRatio au niveau de la cellule. Sa valeur est une variable flottante décimale correspondant à l'estimation initiale du rapport de chaque flux de messages de poursuite de dialogue par rapport au flux de messages d'ouverture de dialogue dans le même ensemble (famille de protocoles, cible de déploiement). En d'autres termes, il s'agit du nombre de messages de suivi entrants par dialogue. Associez arfmInitialMsgDlgRatio à une valeur comparable dans la collection des flux de messages de poursuite de dialogue.

    Elle est aussi valable lorsque l'orientation des dialogues pour la protection contre la surcharge du processeur et le service différencié est activée.

  4. Sauvegardez les modifications.

Le contrôle d'admission pour la protection contre la surcharge du processeur fonctionne si, sur un système dont la charge est élevée, l'utilisation du processeur correspond plus ou moins au paramètre de protection contre la surcharge du processeur.

Consultez la rubrique relative à la protection contre les surcharges mémoire

Indique le pourcentage maximal de la taille de segment de mémoire à utiliser pour chaque serveur d'applications.

Pourcentage maximal de la taille de segment de mémoire à utiliser pour WebSphere Application Server. Indiquez une valeur inférieure à 100.

Stratégie de rejet des requêtes

Indique le comportement adopté pour les demandes HTTP, SIP et SOAP associées à un objectif de performances lorsqu'une condition de surcharge est détectée.

Sélectionnez l'une des options pour déterminer à quel moment il est judicieux de rejeter des messages afin d'éviter la surcharge de l'unité centrale. Vous pouvez ne rejeter aucun message ou spécifier une valeur de seuil de rejet qui détermine à quel moment rejeter des messages. Par défaut, aucun message n'est rejeté.

Un travail discrétionnaire est normalement associé à un seuil de temps de réponse de 60 secondes.

Pour activer le gestionnaire autonome de flux de demandes reposant sur des noeuds, vous devez associer la propriété personnalisée arfmQueueMode à la valeur node. Pour utiliser un prédicteur reposant sur l'unité centrale pour le contrôleur de positionnement d'application (APC) lorsque vous utilisez des clusters dynamiques en mode automatique, vous devez associer la propriété personnalisée APC.predictor à la valeur CPU.

Que faire ensuite

Utilisez la documentation mustGather pour l'identification et la résolution des problèmes liés au gestionnaire ARFM ou de la fonction de positionnement d'application.


Icône indiquant le type de rubrique Rubrique de tâche



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