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

Intelligent Management : foire aux questions concernant le positionnement d'application

Il se peut que la fonction de positionnement d'application ne s'exécute pas comme prévu. Cette rubrique présente certaines des questions les plus fréquentes et les éléments à rechercher lorsque le mécanisme de positionnement d'application ne fonctionne pas comme prévu.

Où le contrôleur de positionnement d'application s'exécute-il ?

Pour déterminer où le contrôleur de positionnement d'application s'exécute, vous pouvez utiliser la console d'administration ou la procédure de scriptage. Pour vérifier l'emplacement dans la console d'administration, cliquez sur Opération d'exécution > Stabilité du composant > Composants centraux. Vous exécutez également le script checkPlacementLocation.jacl pour afficher le serveur sur lequel le contrôleur de positionnement d'application s'exécute.

Quand le contrôleur de positionnement d'application démarre-t-il un serveur ?

Le contrôleur de positionnement d'application démarre des serveurs pour les raisons suivantes :
  • Atteindre le nombre minimal d'instances d'application définies pour le cluster dynamique.
  • Lorsqu'une demande est acheminée via le routeur On Demand pour un cluster dynamique désactivé.
  • Lorsqu'un cluster dynamique a besoin d'augmenter ses capacités. Le gestionnaire ARFM envoie un signal indiquant qu'un cluster dynamique a besoin de capacités supplémentaires et de nouvelles instances sont démarrées pour le cluster.
Pour déterminer les composants en cours d'exécution pour le contrôleur de positionnement d'application, reportez-vous aux messages du fichier SystemOut.log.

Quand le contrôleur de positionnement d'application arrête-il un serveur ?

Le contrôleur de positionnement d'application arrête un serveur pour les raisons suivantes :

  • Il existe une contrainte de mémoire sur un noeud. Le contrôleur de positionnement d'application analyse la configuration minimale du cluster dynamique, les capacités dont il a besoin et les contraintes de processeur et de mémoire du système. Si la mémoire disponible est insuffisante sur un noeud, le contrôleur de positionnement d'application tente d'arrêter des instances pour empêcher les opérations de permutation du noeud.
  • Le cluster dynamique est configuré pour un démarrage différé d'application et un arrêt au ralenti en mode proactif et il n'y a pas de demande du cluster dynamique. Si le cluster dynamique n'est pas sollicité, le contrôleur de positionnement d'application tente d'arrêter les instances qu'il exécute pour éviter l'utilisation de ressources d'un cluster dynamique inactif.

Pourquoi le contrôleur de positionnement d'application n'a-t-il pas démarré de serveur ?

Le contrôleur de positionnement d'application ne peut pas indiquer que le serveur a démarré pour l'une des raisons suivantes :

  • La configuration n'a pas activé la fonction de positionnement d'application dynamique :
    1. Vérifiez que le contrôleur de positionnement est activé. Dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de positionnement d'application.
    2. Vérifiez que les clusters concernés sont des clusters dynamiques. Le contrôleur de positionnement d'application agit uniquement sur les clusters dynamiques. Dans la console d'administration, cliquez sur Serveurs > Clusters dynamiques. Vérifiez que la zone Mode d'exploitation de chaque cluster indique Automatique. Sinon, sélectionnez les clusters dynamiques et cliquez sur Automatique. Après avoir sélectionné cette option pour vos clusters dynamiques, cliquez sur Définir le mode.
    3. Vérifiez que la valeur définie pour le paramètre Intervalle minimal entre les modifications de positionnement n'est pas trop élevée. Dans la console d'administration, cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de positionnement d'application. Indiquez une valeur appropriée dans la zone Intervalle minimal entre les modifications de positionnement. Les valeurs admises sont comprises entre 1 et 24 heures.
  • Valeur du délai d'expiration de l'opération du serveur trop basse.

    Le contrôleur de positionnement d'application ne démarre pas de serveur car l'opération du serveur a dépassé le délai d'expiration. Vous pouvez configurer le délai d'expiration dans la console d'administration. Cliquez sur Stratégies opérationnelles > Gestionnaires autonomes > Contrôleur de positionnement d'application. Modifiez la zone Délai d'exploitation du serveur. Si la cellule est volumineuse ou que le système est lent ou fortement sollicité, indiquez une valeur plus élevée dans cette zone. Cette valeur représente le délai dont dispose chaque serveur pour démarrer mais le délai d'expiration est déterminé par le nombre de serveurs dans la cellule. Par exemple, si vous disposez de cinq serveurs et que vous indiquez la valeur 10 minutes, le délai d'expiration est dépassé au bout de 50 minutes.

  • Mémoire disponible insuffisante :
    • Vous pouvez déterminer quand la quantité de mémoire est insuffisante en recherchant les échecs de démarrage dans le fichier SystemOut.log.
    • Le contrôleur de positionnement d'application utilise les formules suivantes pour calculer la quantité de mémoire utilisée par un membre du cluster dynamique :
      • S'il y a pas d'autres instances du cluster dynamique en cours d'exécution (démarrage à froid) :
        Utilisation de la mémoire du serveur = 1,2*TailleMaxSegmentMémoire + 64 Mo
      • Si d'autres instances du cluster dynamique sont en cours d'exécution, le profileur de mémoire du contrôleur de positionnement d'application utilise la formule suivante :
        Server memory consumption = .667*resident memory size + .333*virtual memory size
    • Les profils de mémoire ne sont pas conservés après le redémarrage du contrôleur de positionnement d'application.
    Si vous souhaitez lancer une procédure de débogage, vous pouvez désactiver le profileur de mémoire du contrôleur de positionnement d'application en associant la propriété memoryProfile.isDisabled à la valeur true.
Affichage des informations sur les échecs de démarrage
A faire : La liste des échecs de démarrage n'est pas conservée lorsque le contrôleur de positionnement d'application redémarre ou passe d'un noeud à l'autre.
Vous pouvez visualiser les informations des échecs de démarrage en utilisant l'une des options suivantes :
  • Utilisez le script PlacementControllerProcs.jacl pour connaître les opérations incluant des échecs de serveur.
    Exécutez la commande suivante :
    ./wsadmin.sh -profile PlacementControllerProcs.jacl -c "anyFailedServerOperations"
  • Utilisez les commandes de l'outil wsadmin pour afficher les échecs de démarrage.
    Par exemple, vous pouvez exécuter les commandes suivantes :
    wsadmin>apc = AdminControl.queryNames('WebSphere:type=PlacementControllerMBean,process=dmgr,*')
    wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations')
    Lorsque le serveur est de nouveau disponible, l'indicateur signalant l'échec du démarrage est supprimé. Vous pouvez utiliser la commande suivante dans l'outil wsadmin pour afficher la liste des serveurs dont l'indicateur d'échec du démarrage est activé :
    wsadmin>print AdminControl.invoke(apc,'anyFailedServerOperations') OpsManTestCell/xdblade09b09/DC1_xdblade09b09
  • Affichez les échecs de démarrage dans le fichier SystemOut.log.

Pourquoi le contrôleur de positionnement d'application démarre-t-il plus de serveurs que prévu ?

Il est possible de démarrer davantage de serveurs que prévu lorsque des erreurs de réseau ou de communication empêchent le contrôleur de positionnement d'application de recevoir la confirmation du démarrage d'un serveur. Lorsqu'il ne reçoit pas de confirmation, le contrôleur peut démarrer un autre serveur.

Pourquoi le contrôleur de positionnement d'application a envoyé plusieurs tâches pour démarrer le même serveur ?

Il se peut qu'il s'exécute sur plusieurs serveurs. Il s'agit d'une situation courante dans les topologies hétérogènes où une cellule WebSphere Application Server Version 8.5 contient un noeud WebSphere Virtual Enterprise Version 6.1.x. Le contrôleur de positionnement d'application s'exécute sur les deux noeuds : le noeud WebSphere Application Server Version 8.5 et le noeud WebSphere Virtual Enterprise Version 6.1.x. Les noeuds WebSphere Application Server Version 8.5 et WebSphere Virtual Enterprise Version 6.1.x utilisent des solutions à haute disponibilité différentes par défaut. Par conséquent, plusieurs contrôleurs de positionnement d'application s'exécutent. Pour résoudre le problème, exécutez le script useBBSON.py sur le gestionnaire de déploiement et redémarrez la cellule. Le script définit les propriétés personnalisées de cellule pour que la même solution à haute disponibilité soit utilisée dans l'ensemble de la cellule et qu'un seul contrôleur de positionnement d'application soit démarré.

Comment savoir quand le contrôleur de positionnement d'application a terminé une opération ou est sur le point de la terminer ?

Vous pouvez vérifier les actions du contrôleur de positionnement d'application avec les tâches d'exécution. Pour afficher les tâches d'exécution, cliquez sur Administration du système > Gestion des tâches > Tâches d'exécution. La liste des tâches comprend les tâches que le contrôleur de positionnement d'application est en train d'effectuer et la confirmation des modifications apportées. Chaque tâche d'exécution possède l'état Réussite, Echec ou Inconnu. L'état Inconnu signifie qu'il n'y a pas de confirmation signalant que la tâche a abouti.

Quel contrôleur de positionnement d'application fonctionne avec VMware ? Quels environnements de virtualisation matériels sont pris en charge ?

Pour plus d'informations sur le fonctionnement du contrôleur de positionnement d'application avec VMware et les environnements de virtualisation matériels, consultez les rubriques relatives à la virtualisation, à la fonction Gestion intelligente et aux environnements de virtualisation de serveur pris en charge.

Comment démarrer ou arrêter un serveur sans interférer avec le contrôleur de positionnement d'application ?

Si vous démarrez ou arrêtez un serveur alors que le cluster dynamique est en mode automatique, le contrôleur de positionnement d'application peut décider de modifier les actions que vous avez effectuées. Pour éviter d'interférer avec le contrôleur de positionnement d'application lors de l'arrêt ou d'un démarrage d'un serveur, placez le cluster dynamique en mode manuel avant de démarrer ou d'arrêter un serveur.

Sur un système hétérogène (composants matériels ou systèmes d'exploitation mixtes), comment le contrôleur de positionnement d'application détermine-t-il où il doit démarrer un serveur ?

La stratégie d'appartenance d'un cluster dynamique définit les noeuds sur lesquels les serveurs peuvent démarrer. A partir de cet ensemble de noeuds, le contrôleur de positionnement d'application sélectionne le noeud sur lequel un serveur doit être démarré en prenant en compte les contraintes système, telles que les capacités de du processeur et de la mémoire. Le contrôleur de positionnement d'application ne détermine pas le positionnement du serveur en fonction des systèmes d'exploitation.

Lorsque le cluster dynamique est surchargé, quand le contrôleur de positionnement d'application démarre-t-il un autre serveur ?

Le contrôleur de positionnement d'application fonctionne avec le gestionnaire autonome de flux de demandes et des stratégies définies pour déterminer quand il doit démarrer des serveurs. Les stratégies de service définissent les valeurs de performances et de priorité maximales des applications et guide les contrôleurs autonomes pour prendre des décisions en matière de gestion du trafic et des capacités d'approvisionnement. Les objectifs de stratégie de service influencent indirectement les actions effectuées par le contrôleur de positionnement d'application. Le contrôleur de positionnement d'application prévoit davantage de serveurs en se reportant aux informations émises par le gestionnaire autonome de flux de demandes, qui indique les capacités requises pour le nombre de demandes simultanées en cours de traitement dans ses files d'attente. Cette valeur est déterminée en fonction des capacités que chaque demande utilise lors de son traitement et du nombre de demandes simultanées identifiées par le gestionnaire autonome de flux de demandes. Le nombre de demandes simultanées repose sur la priorité de l'application, de l'objectif, etc.

Les objectifs de performances définis par des stratégies de service ne sont pas garantis. La fonction Gestion intelligente ne permet pas à l'application de répondre plus rapidement que la limite maximale fixée. En outre, des capacités supplémentaires ne sont pas prévues si des capacités suffisantes ont déjà été planifiées pour répondre à la demande, même si l'objectif de stratégie de service n'est pas respecté. La fonction Gestion intelligente permet d'éviter que des objectifs de stratégie de service irréalistes n'entraînent l'instabilité de l'environnement.

Comment le contrôleur de positionnement d'application détermine-t-il la taille maximale de segment de mémoire du serveur ?

Vous pouvez modifier la taille de segment de mémoire du serveur dans le modèle du cluster dynamique. Pour plus d'informations, reportez-vous à la rubrique relative à la modification de la taille de segment de mémoire JVM.

Pourquoi les membres du cluster dynamique n'héritent-ils pas des propriétés du modèle ?

Vous devez sauvegarder les clusters dynamiques dans le référentiel principal avec de modifier le modèle de serveur. Si certains clusters dynamiques n'héritent pas des propriétés du modèle, c'est que celui-ci a entraîné des modifications dans un espace de travail qui n'a pas été sauvegardé. Pour y remédier, supprimez le cluster dynamique, puis recréez-le.

Sauvegardez vos modifications dans le référentiel principal. Vous pouvez vérifier que vos modifications sont sauvegardées dans le référentiel principal ; pour cela, cliquez sur Terminer, puis sur Sauvegarder dans la fenêtre de messages. Cliquez de nouveau sur Sauvegarder dans la fenêtre Sauvegarde dans la configuration maîtresse. Cliquez sur Synchroniser les modifications avec les noeuds.

Pourquoi le cluster dynamique comporte-t-il trop peu de serveurs actifs ?

Si des incidents se produisent en raison d'un nombre insuffisant de serveurs actifs dans le cluster, effectuez les opérations suivantes :
  • Lorsque les noeuds du groupe de noeuds ne sont pas très utilisés, vérifiez si les stratégies de service sont respectées. Parfois, la règle n'étant pas clairement définie, le système parvient à la respecter mais pas toujours selon vos attentes. Pour vérifier ou modifier une stratégie de service dans la console d'administration, cliquez sur Stratégies opérationnelles > Stratégies de service > Sélectionnez une stratégie existante. Vérifiez le type et la valeur de l'objectif, le niveau d'importance de la règle et effectuez les modifications nécessaires.
  • Lorsque les noeuds du groupe de noeuds sont très sollicités, comparez les objectifs de la stratégie de service du cluster à ceux des autres clusters actifs. Si le niveau d'importance du trafic de ce cluster est inférieure ou que les objectifs de service cible sont plus souples que ceux des autres clusters, le système instancie moins de serveurs de ce cluster. Pour vérifier ou modifier une stratégie de service dans la console d'administration, cliquez sur Stratégies opérationnelles > Stratégies de service > Sélectionner une stratégie existante.
  • Quand le groupe de noeuds semble avoir une capacité supplémentaire alors que les conditions des stratégies de service ne sont pas remplies, vérifiez les paramètres de configuration sur le cluster dynamique. Il se peut que le nombre d'instances du cluster créé soit insuffisant en raison de la valeur du paramètre de stratégie maxInstances.

Dans un environnement de cluster dynamique, pour quelle raison le contrôleur de positionnement d'application ne parvient-il pas à distribuer les serveurs disponibles sur les noeuds ?

La fonction de positionnement dynamique d'application repose sur la répartition des charges, la stratégie de service et les ressources disponibles. Lors de la réduction du nombre maximal d'instances d'application dans un cluster dynamique, le contrôleur de positionnement d'application arrête les serveurs sur les noeuds ayant la charge de travail la plus élevée jusqu'à ce que le nombre de serveurs soit réduit à la valeur maximale définie. Si tous les noeuds sont disponibles, le contrôleur de positionnement d'application sélectionne le premier de la liste et continue avec le noeud suivant jusqu'à ce que le nombre maximal soit atteint.

Lors de la réduction du nombre maximal d'instances d'application dans plusieurs clusters dynamiques qui s'exécutent sur les mêmes noeuds, le même processus s'applique : le contrôleur de positionnement d'application arrête les serveurs dans chaque cluster dynamique jusqu'à ce ce que le nombre de serveurs atteigne la valeur maximale définie pour chaque cluster dynamique. Etant donné que tous les serveurs de chaque cluster dynamique s'exécutent sur les mêmes noeuds, l'ordre de sélection des noeuds pour l'arrêt des serveurs est le même pour chaque cluster dynamique.
Remarque : Si au moins un noeud est soumis à une charge, le contrôleur de positionnement d'application lance une solution de positionnement plus répartie.

Icône indiquant le type de rubrique Rubrique de référence



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