![[z/OS]](../images/ngzos.gif)
Distribution équitable des demandes HTTP par la fonction WLM
Le composant de gestion de la charge de travail (WLM) z/OS prend en charge la distribution des demandes entrantes HTTP sans affinité de serviteur selon le mode de permutation circulaire entre les différents serviteurs. Cette fonction est destinée, mais non limitée, aux objets de session HTTP de longue durée qui sont conservés en mémoire, aux EJB (Enterprise JavaBeans) session sans état et à la méthode de création pour les beans enterprise session avec état. Vous pouvez configurer le produit afin qu'il utilise cette fonction dans le but de répartir les demandes HTTP entre les serviteurs actifs actuellement liés à la même file d'attente de travaux que les demandes entrantes.
Le diagramme suivant représente une instance de serveur en cluster. Le cluster azsr01 contient l'instance du serveur d'applications azsr01a. Cette dernière contient un contrôleur, la file d'attente WLM et les serviteurs dans lesquels s'exécute l'application. Le contrôleur est le point d'arrêt HTTP et IIOP. La file d'attente WLM contrôle le flux de travaux émis par le contrôleur en direction de l'un des serviteurs. Chaque serviteur contient des unités d'exécution de travail qui sélectionnent les travaux dans la file d'attente WLM.
Dans le diagramme précédent, le serveur d'applications est configuré de manière à ce que le nombre minimal et maximal de serviteurs soit égal à trois.
Service-Class Xref Notes Options Help
--------------------------------------------------------------------------
Modify a Service Class Row 1 to 2 of 2
Commande ===> ______________________________________________________________
Nom de classe de service . . . . . : AZAMS1
Description . . . . . . . . . WAS Enclave Work
Nom de charge de travail . . . . . . . . ONL_WKL (name or ?)
Groupe de ressources de base . . . . . ________ (nom ou ?)
Cpu Critical . . . . . . . . . NO (YES or NO)
Spécifiez l'information BASE GOAL. Action Codes: I=Insert new period,
E=Editer la période, D=Effacer la période.
---Period--- ---------------------Goal---------------------
Action # Durée Imp. Description
__
__ 1 1 Execution velocity of 50
******************************* Bottom of data ********************************
Subsystem-Type Xref Notes Options Help
--------------------------------------------------------------------------
Modify Rules for the Subsystem Type Row 11 to 20 of 20
Command ===> ____________________________________________ SCROLL ===> CSR
Type sous-système. : CB Fold qualifier names? Y (Y or N)
Description . . . Component Broker requests
Action codes: A=After C=Copy M=Move I=Insert rule
B=Before D=Delete row R=Repeat IS=Insert Sub-rule
More ===>
--------Qualifier-------- -------Class--------
Action Type Name Start Service Report
DEFAULTS: AZAMS1 RBBDEFLT
____ 1 CN AZSR01 ___ AZAMS1 RAZAMS1
____ 1 CN AZSR02 ___ AZAMS2 RAZAMS2
____ 1 CN AZSR03 ___ AZAMS3 RAZAMS3
****************************** BOTTOM OF DATA *****************************
Le produit prend en charge l'utilisation des objets de session HTTP conservés en mémoire pour les serveurs d'applications comportant plusieurs serviteurs, ce qu'on appelle également la stratégie de serviteur à chaud. Dans le diagramme suivant, deux utilisateurs ont accédé à une application dans l'instance du serveur d'applications azsr01a. L'utilisateur 1 a établi un objet de session HTTP sur le serviteur 3 et l'utilisateur 2 a fait de même sur le serviteur 2.
- la configuration autorise la création de serviteurs ;
- la logique Workload Manager détermine que le système peut supporter un serviteur supplémentaire ;
- l'ajout d'un autre serviteur entraîne une réduction du délai de mise en file d'attente et autorise le traitement des enclaves conformément à l'objectif indiqué.
Lorsque plusieurs serviteurs sont liés à la même classe de service, la fonction WLM tente de transmettre les nouvelles demandes à un serviteur à chaud. Un serviteur est dit à chaud lorsqu'une demande lui a été récemment transmise et qu'il possède des unités d'exécution disponibles. Si le serviteur de ce type possède des travaux en file d'attente, la fonction WLM transmet les travaux à un autre serviteur.
L'exécution de cette stratégie de serviteur à chaud est souhaitable car il est probable que toutes les pages dont ce dernier a besoin se trouvent en mémoire, que les méthodes sauvegardées de l'application compilée JIT (just-in-time) soient disponibles, et que le cache soit saturé de données pour l'extraction rapide des données. Toutefois, cette stratégie présente des inconvénients dans les cas de figure suivants :
- Les objets de session HTTP en mémoire sont utilisés, ce qui crée des affinités d'expédition.
- la durée des objets de session HTTP s'étend sur un grand nombre d'heures ou de jours ;
- un grand nombre de clients comportant des objets de session HTTP doivent être conservés en mémoire ;
- la perte d'un objet de session est gênante pour le client ou le serveur et l'intervalle entre les demandes de création des sessions HTTP est très important.
- Si l'application crée un grand nombre d'objets dans un seul serviteur, la récupération de place risque de prendre beaucoup de temps.
- Si tous les objets de session HTTP sont liés à un serviteur, les demandes peuvent rester longtemps en file d'attente car les travaux ne peuvent être ni gérés par la fonction WLM ni transmis aux serviteurs.
- Si tous les objets de session HTTP sont installés sur un ou deux serviteurs, un délai d'attente sur un serviteur unique peut affecter un nombre d'utilisateurs plus élevé que si ces objets étaient répartis équitablement entre plusieurs serviteurs.
Si des incidents liés à la stratégie de serviteur à chaud se produisent dans la configuration, vous pouvez configurer votre serveur d'applications pour qu'il prenne en charge la distribution des demandes HTTP entrantes entre les serviteurs sans affinité de serviteur. Lorsque vous activez cette fonctionnalité, le serveur d'applications distribue les demandes HTTP aux serviteurs en mode de permutation circulaire.
Dans l'exemple suivant, considérez que le serveur d'applications a été configuré pour utiliser la distribution des demandes HTTP aux serviteurs en mode de permutation et que plusieurs serviteurs sont démarrés pour les demandes de file d'attente de travaux auxquelles la même classe de service a été affectée.
Lorsqu'une nouvelle demande HTTP sans affinité arrive dans une file d'attente de travaux, la fonction WLM vérifie si un serviteur contient au moins une unité d'exécution de travail en attente de travail. Si ce n'est pas le cas, elle met la demande en file d'attente le temps qu'une unité d'exécution de travail soit disponible. Si des unités d'exécution de travail sont disponibles, la fonction WLM recherche le serviteur qui possède le moins d'affinités. Si plusieurs serviteurs ont le même nombre d'affinités, la fonction WLM transmet le travail à la région serviteur ayant le moins d'unités d'exécution de serveur actives.
Cet algorithme vise à permettre à la fonction WLM de répartir les demandes entrantes sans affinité de serveur entre les serviteurs en attente tout en envisageant de modifier les conditions. Il n'affecte pas aveuglément les demandes à des serveurs selon un mode de permutation circulaire réel. Le diagramme suivant présente la distribution équilibrée des objets de session HTTP entre les serviteurs.
Ce mécanisme de distribution s'applique à toutes les demandes entrantes sans affinité. Une fois qu'un objet de session HTTP a été créé, toutes les demandes client sont acheminées vers ce serviteur jusqu'à ce que l'objet de session HTPP soit supprimé.
Si vous décidez d'activer la distribution des demandes HTTP entrantes sans affinité de serveur, vous pouvez être amené à modifier le fichier de mappage de classification. Si vous avez configuré votre fichier de mappage de classification de façon à spécifier plusieurs classes de transaction sur une règle de mappage pour la prise en charge de permutation circulaire gérée fournie par le produit, vous devez supprimer cette partie du fichier de mappage de classification.