WebSphere Extended Deployment, Version 6.0.x     Systèmes d'exploitation : AIX, HP-UX, Linux, Solaris, Windows, z/OS

Définition de la priorité des demandes de résolution des incidents

Il est possible que le processus de définition de la priorité des demandes ne s'exécute pas toujours comme vous l'aviez prévu. La présente rubrique décrit les éléments à vérifier lorsque la définition de la priorité des demandes se déroule de façon inattendue.

Les demandes HTTP sont toutes discrétionnaires

Si votre environnement traite toutes les demandes entrantes de la même manière, il est possible que la stratégie de service n'ait pas été définie ni appliquée aux URI (Uniform Resource Identifiers) de module d'application appropriés. La stratégie de faible priorité, également appelée stratégie discrétionnaire, est la stratégie par défaut. Pour vérifier que la stratégie de service est configurée et appliquée, effectuez les opérations suivantes :
Action Effectuée par
Vérifiez que les stratégies de service sont créées. Dans la console d'administration, sélectionnez Stratégies d'exploitation > Stratégies de service. Le système affiche toutes les stratégies de service actuellement définies. Si votre stratégie de service n'est pas répertoriée, configurez une nouvelle stratégie de service en cliquant sur Nouveau.
Vérifiez que les stratégies de service sont appliquées aux URI d'application appropriés. Dans la console d'administration, sélectionnez Stratégies d'exploitation > Stratégies de service > Sélectionnez une stratégie de service existante. Vérifiez les classes de transaction affectées dans la zone Classes de transaction. Vous pouvez créer une classe de transaction en cliquant sur Nouveau.

Si les membres de la classe de transaction que vous recherchez ne sont pas affichés, vérifiez qu'ils n'ont pas été déjà affectés à une autre stratégie de service. Vérifiez également que l'application vers laquelle vous souhaitez appliquer une stratégie de service est déployée dans votre environnement.

Absence de différenciation entre les stratégies de service

La fluctuation du temps de réponse devient apparente lorsque le groupe de noeuds est sur le point d'atteindre ses capacités maximales, ce qui se produit lorsque tous les noeuds d'un groupe sont utilisés. Dans un environnement dynamique le contrôleur de positionnement d'application lance des instances d'application supplémentaires pour continuer à prendre en charge les demandes, et s'il est installé, Tivoli Intelligent Orchestrator (TIO) peut ajouter des noeuds à l'environnement. Si votre environnement traite toutes les demandes de la même manière, suivez les étapes du tableau précédent pour vérifier que la stratégie est correctement configurée.

Temps de réponse trop long pour la définition de la priorité des demandes

Si le gestionnaire ARFM (Autonomic Request Flow Manager) ne réagit pas assez vite et génère des temps de réponse trop longs lors de la définition de la priorité des demandes, vous pouvez modifier les paramètres ARFM. Pour plus d'informations, voir Configuration du gestionnaire autonome de flux de demandes. Vérifiez notamment le paramètre Longueur minimale du cycle de contrôle et assurez-vous que la valeur sélectionnée est appropriée.

Utilisation de l'unité centrale maintenue à 100 % sur un ou plusieurs noeuds centraux

Le gestionnaire ARFM calcule en permanence le nombre de tâches que chaque classe de transaction demande au système d'exécuter et affine ses évaluations au fur et à mesure que les tâches sont transmises au système. Pour vérifier que le gestionnaire ARFM fonctionne de manière optimale, vous devez exécuter votre système pendant des périodes prolongées en le soumettant à des charges de travail extrêmement variables. L'association de charges de travail fluctuantes et de période de fonctionnement prolongées permet au gestionnaire ARFM d'adapter ses propres paramètres et d'effectuer des évaluations plus précises pour éviter les incidents.

Si un ou plusieurs noeuds restent fortement utilisés alors que les autres noeuds sont moins sollicités, vous pouvez modifier les paramètres du gestionnaire ARFM. Pour plus d'informations, voir Configuration du gestionnaire autonome de flux de demandes. Vérifiez notamment le paramètre Utilisation CPU maximale et veillez à sélectionner une valeur inférieure à la valeur d'utilisation en cours de votre noeud.

Veillez à regrouper les classes de transaction de manière cohérente. Par exemple, évitez de regrouper dans la même classe de transaction les URI dotés d'une valeur discrétionnaire ou d'une valeur stratégie de service faible et les URI dotés d'une valeur de stratégie de service élevée. Si une même classe de transaction comporte une combinaison de demandes représentant des charges très fluctuantes, le gestionnaire AFRM risque de générer des évaluations inexactes. Pour modifier les classes de transactions, sélectionnez Stratégies d'exploitation > Stratégies de service > Sélectionnez une stratégie de service existante et vérifiez que la classe de transaction contient des regroupements cohérents.

Dans une cellule hétérogène, tous les noeuds ne sont pas utilisés de façon égale

Le système fonctionne conformément à sa conception. L'équilibreur de charge tente d'égaliser le temps de réponse sur tous les noeuds dorsaux d'un cluster. Si un noeud est moins puissant qu'un autre, l'équilibreur de charge peut distribuer moins de travail au noeud le moins puissant pour que le temps de réponse soit similaire à celui d'un noeud plus rapide.




Related tasks
Configuration du gestionnaire autonome de flux de demandes

Rubrique Référence    

Conditions d'utilisation | Commentaires Dernière mise à jour le : Mar 16, 2006 9:57:08 AM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/rodflowfail.html

© Copyright IBM 2005, 2006. All Rights Reserved.
Ce centre de documentation s'appuie sur la technologie Eclipse. (http://www.eclipse.org)