Gestion de la charge de travail |
Configuration et exécution de l'exemple BeenThere |
Cette section décrit les étapes de configuration de l'environnement, comme indiqué Figure 1, ainsi que l'installation et l'exécution de l'exemple BeenThere. Il est admis que les logiciels suivants sont déjà installés :
Nom de la machine | Logiciel installé |
web |
IBM HTTP Server Plug-in IBM HTTP Server |
app1 | IBM WebSphere Application Server |
app2 | IBM WebSphere Application Server |
dm | Gestionnaire de déploiement d'IBM WebSphere Application Server |
Remarque : Les instructions suivantes partent du principe que le serveur Web et le service d'administration correspondant sont actifs et qu'une définition de serveur Web a été créée dans le gestionnaire de déploiement afin que le fichier plugin-cfg.xml soit propagé automatiquement.
Suivez la procédure ci-dessous pour ajouter les noeuds de serveur d'applications dans la cellule.
addNode <hôte gestionnaire_déploiement>
addNode.sh <hôte gestionnaire_déploiement>
racine_installation/bin/addNode <hôte gestionnaire_déploiement> <port gestionnaire_déploiement> -profileName <nomProfil> -startingport <blocport>
Les serveurs d'applications sont maintenant incorporés dans la cellule.
Le cluster MyWebCluster fournit des fonctionnalités d'équilibrage de charge et de reprise pour les servlets.
Suivez la procédure ci-dessous pour créer le cluster MyWebCluster.
Le cluster MyWebCluster est créé.
Le cluster MyEJBCluster fournit des fonctionnalités d'équilibrage de charge et de reprise pour les beans enterprise.
Suivez la procédure ci-dessous pour créer le cluster MyEJBCluster.
Note :Sur une plateforme distribuée, la sélection de l'option Environnement local préféré indique que la requête est acheminée vers un bean enterprise exécuté sur le noeud local, si ce dernier est disponible. L'option Environnement local préféré est désactivée dans la configuration de l'exemple pour illustrer la gestion de la charge de travail des requêtes EJB.
Le cluster MyEJBCluster est créé.
Au cours de la création du cluster MyWebCluster, l'option Générer des ports HTTP uniques est sélectionnée pour chaque nouveau membre du cluster. La sélection de cette option évite les conflits entre les ports HTTP en créant une valeur de port unique pour chaque serveur d'applications créé.
Suivez la procédure ci-après pour vous assurer que chaque valeur de port HTTP créée dynamiquement ait une entrée d'alias hôte associée configurée pour l'hôte virtuel hôte_par_défaut :
L'hôte virtuel est mis à jour.
Le service de configuration de WebSphere n'est pas activé pour les serveurs d'applications par défaut. Pour le présent exemple, ce service doit lire par programme les fichiers de configuration de WebSphere Application Server afin d'obtenir des informations relatives à l'environnement.
Suivez la procédure ci-dessous pour activer le service de configuration de WebSphere :
Le service de configuration de WebSphere est activé.
Suivez la procédure ci-dessous pour installer le fichier BeenThere.ear.
Si vous ne souhaitez pas utiliser l'exemple BeenThere avec la sécurité, vous pouvez ignorer cette section. Pour utiliser l'exemple BeenThere avec la sécurité, cliquez sur ici afin d'obtenir des instructions sur la configuration de la sécurité.
Suivez la procédure ci-dessous pour démarrer les serveurs :
Les serveurs ont démarré.
Pour exécuter l'exemple, connectez-vous à la page BeenThere à l'adresse http://<nom_hôte>/wlm/BeenThere dans un navigateur Web, où <nom_hôte> est le nom d'hôte ou l'adresse IP où IBM HTTP Server est exécuté.
Nota : A partir de la version 6 de WebSphere, une nouvelle fonction a fait son apparition qui est conçue pour maximiser le rendement de l'environnement dans son ensemble. En d'autres termes, lorsqu'on teste l'exemple BeenThere dans ces versions, le composant de pondération de la charge de travail ne route pas nécessairement les demandes vers les valeurs exactes de pondération. Ces valeurs risquent de changer lors de l'exécution, ce qui risque de rendre erronées les méthodes de vérification exposées ci-dessous. Dans ces scénarios, la meilleure méthode pour vérifier la gestion de la charge de travail est de s'assurer que les demandes sont acheminées vers la totalité des membres du cluster, sans se préoccuper de savoir si ce routage s'effectue ou non dans le strict respect des valeurs de pondération. Il existe également des méthodes permettant de désactiver ces mécanismes de feedback ; contactez le support IBM pour en savoir plus à ce sujet si nécessaire.
Procédez comme indiqué ci-dessous pour vérifier que la gestion de la charge de travail de conteneur Web fonctionne comme prévu dans sa configuration :
Connectez-vous à la page BeenThere à l'adresse http://<nom_hôte>/wlm/BeenThere dans un navigateur Web, où <nom_hôte> est le nom d'hôte ou l'adresse IP où IBM HTTP Server est exécuté.
Les valeurs indiquées dans le récapitulatif d'exécution du servlet changent, comme indiqué dans l'exemple suivant :
Le noeud du servlet est app2 au lieu de app1. Les résultats indiquent qu'IBM HTTP Server a transmis la demande HTTP à l'autre membre du cluster MyWebCluster, c'est-à-dire WebServer2 sur app2. Les exécutions répétées du servlet révèlent un comportement de gestion de la charge de travail des demandes HTTP fondé sur les valeurs de pondération des membres du cluster MyWebCluster.
La configuration de la fonctionnalité de gestion de la charge de travail de conteneur Web a été vérifiée.
Suivez la procédure ci-dessous pour vérifier que la gestion de la charge de travail de conteneur d'EJB fonctionne comme indiqué dans sa configuration :
Sur une plateforme distribuée, les valeurs indiquées dans le récapitulatif d'exécution du bean doivent être similaires à celles présentées dans l'exemple suivant :
Dans cet exemple, vous pouvez observer le comportement d'exécution de la gestion de la charge de travail du bean enterprise fondé sur les valeurs de pondération configurées pour les membres du cluster MyEJBCluster. Trois appels du bean enterprise exécutés sur app2 pour chaque exécution sur app1.
Sur la plateforme z/OS, les valeurs de pondération sont utilisées pour équilibrer les demandes HTTP, mais ne sont pas utilisées pour équilibre les requêtes IIOP (Internet Inter-ORB Protocol).
La configuration de la fonctionnalité de gestion de la charge de travail de conteneur d'EJB a été vérifiée.
Suivez la procédure ci-dessous pour vérifier que les valeurs de pondération des membres du cluster de bean sont définies correctement, comme indiqué dans la configuration.
Comparez les résultats à l'exemple suivant :
Les résultats indiquent les valeurs de pondération pour tous les membres du cluster MyEJBCluster. EJBServer1 a une pondération de 1 et EJBServer2 a une pondération de 3.
Les valeurs de pondération des membres du cluster de bean ont été vérifiées.
Félicitations, vous avez pu découvrir le fonctionnement de la gestion de la charge de travail et vérifier que l'exemple BeenThere a fonctionné comme indiqué dans sa configuration !