Distribution équitable des demandes HTTP par la fonction WLM

Le composant de gestion de la charge de travail (WLM) de z/OS® prend en charge la distribution des demandes entrantes de HTTP sans affinité de serviteur, de manière round-robin entre les 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.

Les demandes entrantes sont envoyées à la région de contrôle, via la file d'attente du gestionnaire de charge de travail, et sont affectées à des unités d'exécution de tâche dans une région serviteur spécifique. — Figure 1 : Contenu d'une instance de serveur en cluster

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 
 Command ===> ______________________________________________________________    
                                                                                
 Service Class Name . . . . . : AZAMS1                                          
 Description  . . . . . . . . . WAS Enclave Work                                
 Workload Name  . . . . . . . . ONL_WKL   (name or ?)                           
 Base Resource Group  . . . . . ________  (name or ?)                           
 Cpu Critical . . . . . . . . . NO        (YES or NO)                           
                                                                                
 Specify BASE GOAL information.  Action Codes: I=Insert new period,             
 E=Edit period, D=Delete period.                                                
                                                                                
         ---Period---  ---------------------Goal---------------------           
 Action  #  Duration   Imp.  Description                                        
   __                                                                           
   __    1              1    Execution velocity of 50                           
 ******************************* End 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 
                                                                           
 Subsystem Type . : 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    
****************************** End 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 dans le serviteur 3. L'utilisateur 2 a établi un objet de session HTTP dans le serviteur 2.

L'utilisateur 1 établit un objet de session HTTP dans le serviteur 3. L'utilisateur 2 établit un objet de session HTTP dans le serviteur 2. — Figure 4 Les utilisateurs établissent des objets de session HTTP

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 hot comporte un journal des travaux en attente, WLM répartit le travail vers un autre serviteur.

Normalement, l'exécution de cette stratégie de serviteur à chaud est bonne car le serviteur à chaud a probablement toutes ses pages nécessaires en mémoire, les méthodes d'application compilées JIT (Just-in-Time) sont sauvegardées à la fermeture et le cache est plein de données pour une 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.

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.

HTTP les objets de session sont attribués au serviteur chaud, le serviteur 1. — Figure 5. Objets de session HTTP affectés à un serviteur à chaud

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.

Chaque serviteur reçoit approximativement le même nombre d'objets de session HTTP. — Figure 6 Objets de session HTTP affectés aux serviteurs sans affinité

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.