Equilibrage des charges de travail

Vous devez utiliser les clusters de serveurs et les membres de cluster pour contrôler et gérer les charges de travail des serveurs d'applications.

Avant de commencer

Vous devez connaître les options qui s'offrent à vous pour configurer vos serveurs d'applications. Pour vous aider à comprendre comment configurer et utiliser les clusters pour la gestion des charges, examinez le scénario suivant. Les demandes des clients sont réparties entre les membres du cluster installés sur une même machine. Le terme client désigne ici un servlet, une application Java™ ou un autre programme ou composant qui connecte l'utilisateur final et le serveur d'applications auquel il accède.

[AIX Solaris HP-UX Linux Windows]Dans des scénarios de pondération de charge de travail plus complexes, vous pourriez répartir les membres du cluster sur plusieurs machines distantes.

[z/OS]Dans des scénarios de pondération de charge de travail plus complexes, vous pourriez répartir les membres du cluster au sein du même sysplex.

Pourquoi et quand exécuter cette tâche

Si vous décidez d'utiliser des clusters pour équilibrer votre charge de travail, procédez comme suit.

Procédure

  1. Déterminez le serveur d'applications que vous voulez ajouter à un cluster.
  2. Déterminez si vous souhaitez répliquer les données. La réplication est un service qui permet de transférer des données, des objets ou des événement entre serveurs d'applications.

    Vous pouvez créer un domaine de réplication lors de la création d'un cluster.

  3. Déployez l'application sur le serveur d'applications.
  4. Créez un cluster.

    Après avoir configuré le serveur d'applications et les composants de l'application exactement comme vous le souhaitez, créez un cluster. L'instance originale du serveur devient un membre de cluster qui sera administré à travers le cluster.

  5. Créez un ou plusieurs membres de cluster.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Configurez un cluster de secours.
    Eviter les incidents Eviter les incidents: Si vous disposez de clients s'exécutant dans un environnement :
    • qui inclut des clients légers Java,
    • où des demandes sont acheminées entre plusieurs cellules,
    • où des demandes sont acheminées dans une seule cellule qui inclut des noeuds provenant de versions antérieures du produit,
    il peut arriver que dans ces clients, les informations de port relatives aux membres du cluster cible deviennent périmées.

    Cette situation survient le plus fréquemment lorsque tous les membres de cluster ont des ports dynamiques et sont redémarrés pendant une période durant laquelle aucune demande n'est envoyée. Le processus client peut tenter d'accéder à l'agent de noeud afin de recevoir les nouvelles données de port pour les membres de cluster puis utiliser ces dernières pour accéder à nouveau aux membres du cluster.

    Si des problèmes surviennent qui empêchent le client de communiquer avec l'agent de noeud ou qui empêchent les nouvelles données de port d'être propagées entre les membres de cluster et l'agent de noeud, les demandes peuvent échouer sur le client. Dans certains cas, ces échecs sont temporaires. Il peut également être nécessaire de redémarrer un ou plusieurs processus pour résoudre une situation d'échec.

    Pour éviter les problèmes d'acheminement client, vous pouvez configurer des ports statiques sur les membres de cluster. Sur les ports statiques, les données de port ne changent pas lorsqu'un processus client obtient des informations sur les membres du cluster. Même si ces derniers sont redémarrés ou s'il existe des problèmes de communication ou de propagation des données entre les processus, les données de port conservées par le client sont toujours valides. Il n'est pas toujours possible de résoudre les problèmes de communication ou de propagation des données sous-jacents, cependant les symptômes des décisions d'acheminement client inappropriées ou inattendues sont supprimés.

    gotcha

    Un cluster de secours gère les requêtes en cas de défaillance du cluster principal.

  7. Démarrez le cluster.

    Lorsque vous démarrez le cluster, tous les serveurs d'applications qui en sont membres démarrent. La pondération de charge de travail débute automatiquement après le démarrage des membres du cluster.

  8. Une fois le cluster en cours de fonctionnement, vous pouvez réaliser les tâches suivantes :
    • Arrêtez le cluster.
    • Mettez à niveau les applications installées sur les membres du cluster.
    • Identifiez et traitez les problèmes des clusters et de leurs charges de travail.
    • Modifiez la fréquence d'actualisation de l'état de la gestion de la charge de travail du client.

      Le délai d'attente par défaut pour la propriété JVM com.ibm.CORBA.RequestTimeout est 0, autrement dit, attendre indéfiniment. Cette valeur par défaut n'est pas adaptée aux situations de reprise en ligne (par basculement). Par conséquent, si votre application rencontre des problèmes de dépassement de délai ou si vous avez configuré votre système pour les situations de reprise en ligne, utilisez l'option -CCD avec la commande LaunchClient pour indiquer une valeur différente de zéro.

      Si l'état de la pondération de charge de travail du client est actualisé trop tôt ou trop tard, modifiez la valeur d'intervalle de la propriété personnalisée JVM com.ibm.websphere.wlm.unusable.interval.

[IBM i][AIX Solaris HP-UX Linux Windows]

Que faire ensuite

Pour les clients Java autonomes, définissez un hôte d'amorçage. Les clients Java autonomes sont des clients situés sur une machine différente de celle du serveur d'applications et pour lesquels il n'existe pas de serveur d'administration. Ajoutez la ligne suivant aux arguments de la machine virtuelle Java (JVM) du client:
-Dcom.ibm.CORBA.BootstrapHost=machine_name
nom_machine est le nom de la machine sur laquelle s'exécute le serveur d'administration.

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