[z/OS]

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.

Figure 1. Contenu d'une instance de serveur en cluster

Les demandes entrantes sont acheminées vers la région de contrôle, en transitant par la file d'attente Workload Manager, puis affectées à des unités d'exécution de travail contenues dans une région serviteur spécifique.

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.

Il existe des définitions WLM pour les serveurs d'applications dans ce cluster. Toutes les demandes d'une instance de serveur d'applications quelconque du cluster azsr01 sont affectées à la même classe de service. Les règles de classification WLM affectent toutes les enclaves exécutées sur le serveur d'applications azsr01a à la classe de service AZAMS1. Les diagrammes suivants présentent un exemple de définition de classe de service WLM et de règles de classification.
Figure 2. Définition de classe de service WLM
   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 ********************************
Figure 3. Règles de classification de sous-système WLM CB
   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.

Figure 4. Les utilisateurs établissent des objets de session HTTP

L'utilisateur 1 établit un objet de session HTTP sur le serviteur 3 et l'utilisateur 2 fait de même sur le serviteur 2.

Lorsqu'un utilisateur accède à une région serviteur sans qu'un objet de session HTTP ait été établi, il n'existe aucune affinité de région serviteur. Ainsi, la demande peut être transmise à n'importe quel serviteur disponible. La fonction WLM peut démarrer un nouveau serviteur si toutes les conditions suivantes sont remplies :
  • 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 :

Dans ce dernier cas, un décalage non souhaité se produit dans la distribution des objets de session HTTP. Dans le diagramme suivant, la plupart des objets de session HTTP sont affectés au serviteur 1.
Figure 5. Objets de session HTTP affectés à un serviteur à chaud

Les objets de session HTTP sont affectés au serviteur à chaud qui correspond au serviteur 1.

Un pourcentage important d'objets de session HTTP sont installés dans un ou deux serviteurs car, la plupart du temps, le nombre de demandes en file d'attente WLM est insuffisant pour assurer la transmission des travaux entre un grand nombre de serviteurs. Ce comportement peut entraîner les résultats indésirables ci-dessous.
  • 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.

Figure 6. Objets de session HTTP affectés aux serviteurs sans affinité

Chaque serviteur reçoit approximativement le même nombre d'objets de session HTTP.

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.


Icône indiquant le type de rubrique Rubrique de concept



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