[z/OS]

Distribución equitativa de WLM de solicitudes HTTP

El componente de gestión de carga de trabajo (WLM) para z/OS da soporte a la distribución de solicitudes HTTP entrantes sin afinidad de sirvientes, por turno rotativo entre los sirvientes. Esta funcionalidad está especialmente indicada, pero no limitada, para los objetos de sesión HTTP de larga duración que se mantienen en la memoria, los EJB (Enterprise JavaBeans) de sesión sin estado y el método create de enterprise beans de sesión con estado. Puede configurar el producto para que utilice esta funcionalidad para repartir las solicitudes HTTP entre los sirvientes activos que estén enlazados actualmente con la misma cola de trabajo que las solicitudes entrantes.

El siguiente diagrama representa una instancia de servidor en clúster. El clúster azsr01 contiene la instancia del servidor de aplicaciones azsr01a. En la instancia del servidor de aplicaciones hay un controlador, la cola WLM (Workload Manager) y los sirvientes donde se ejecutan las aplicaciones. El controlador es el punto de terminación HTTP e IIOP. La cola WLM controla el flujo de trabajo desde el controlador a uno de los sirvientes. Cada uno de los sirvientes contiene hebras de trabajo que seleccionan el trabajo de la cola WLM.

Figura 1. El contenido de una instancia de servidor en clúster

Las solicitudes entrantes pasan a la región de control, a través de la cola del gestor de carga de trabajo, y se asignan a las hebras de trabajo en una determinada región de sirviente.

En el diagrama anterior, el servidor de aplicaciones se ha configurado para que el número máximo y el número mínimo de sirvientes sea tres.

Existen definiciones de WLM de los servidores de aplicaciones de este clúster. Todas las solicitudes de cualquier instancia de servidor de aplicaciones del clúster azsr01 se asignan a la misma clase de servicio. Las reglas de clasificación WLM asignan todos los enclaves que se están ejecutando en el servidor de aplicaciones azsr01a a la clase de servicio AZAMS1. Consulte los siguientes diagramas para ver un ejemplo de la definición de clase de servicio WLM y las reglas de clasificación.
Figura 2. La definición de clase de servicio WLM
   Service-Class  Xref  Notes  Options  Help                                    
 --------------------------------------------------------------------------     
                           Modify a Service Class               Row 1 to 2 of 2 
 Command ===> ______________________________________________________________    
                                                                                
 Service Class Name . . . . . : AZAMS1                                          
 Descripción  . . . . . . . . . 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                           
 ******************************* Bottom of data ********************************           
Figura 3. Las reglas de clasificación del subsistema CB de WLM
   Subsystem-Type  Xref  Notes  Options  Help                              
 --------------------------------------------------------------------------
                  Modify Rules for the Subsystem Type    Row 11 to 20 of 20
 Command ===> ____________________________________________ SCROLL ===> CSR 
                                                                           
 Tipo de subsistema . : CB Fold qualifier names?   Y  (Y or N)        
 Descripción  . . . 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 *****************************

El producto permite el uso de objetos de sesión HTTP en la memoria para servidores de aplicaciones con varios sirvientes, también conocido como la estrategia de sirvientes dinámicos. En el siguiente diagrama, dos usuarios han accedido a una aplicación en la instancia del servidor de aplicaciones azsr01a. El usuario 1 ha establecido un objeto de sesión HTTP en el sirviente 3. El usuario 2 ha establecido un objeto de sesión HTTP en el sirviente 2.

Figura 4. Los usuarios establecen objetos de sesión HTTP

El usuario 1 establece un objeto de sesión HTTP en el sirviente 3. El usuario 2 establece un objeto de sesión HTTP en el sirviente 2.

Cuando un usuario accede a una región de sirviente sin un objeto de sesión HTTP establecido, no existe ninguna afinidad de regiones de sirviente. Por lo tanto, la solicitud se puede asignar a cualquier sirviente que esté disponible. WLM puede iniciar un nuevo sirviente si se cumplen todas las condiciones siguientes:
  • La configuración permite la creación de nuevos sirvientes
  • La lógica del gestor de carga de trabajo determina que el sistema puede mantener otro sirviente
  • La adición de otro sirviente reduce el retraso de la cola y permite completar los enclaves dentro del objetivo especificado

Cuando hay varios sirvientes enlazados con la misma clase de servicio, WLM intenta asignar las nuevas solicitudes a un sirviente dinámico. Un sirviente dinámico tiene una solicitud reciente que se le ha asignado y hebras disponibles. Si el sirviente dinámico tiene un registro de reserva de trabajo, WLM asigna el trabajo a otro sirviente.

La ejecución de esta estrategia de sirviente dinámico es ventajosa porque el sirviente dinámico probablemente tenga todas las páginas necesarias en almacenamiento, los métodos de aplicación compilados JIT (Just-In-Time) guardados y una memoria caché llena de datos para la recuperación rápida de información. Sin embargo, esta estrategia supone un problema en las siguientes situaciones:

En este último caso, se produce un desvío no deseado en la distribución de objetos de sesión HTTP. En el siguiente diagrama, la mayoría de objetos de sesión HTTP se han asignado al sirviente 1.
Figura 5. Objetos de sesión HTTP asignados a un sirviente dinámico

Los objetos de sesión HTTP se asignan al sirviente dinámico, el sirviente 1.

Un gran porcentaje de objetos de sesión HTTP residen en uno o dos sirvientes porque, la mayoría de las veces, no hay suficientes solicitudes en la cola WLM para garantizar la asignación de trabajo entre muchos sirvientes. Este comportamiento puede dar los siguientes resultados inesperados.
  • Si la aplicación crea un gran número de objetos en un solo sirviente, pueden aumentar los tiempos de recogida de basura.
  • Si todos los objetos de sesión HTTP están enlazados con un sirviente, las solicitudes pueden mantenerse una gran cantidad de tiempo en la cola, ya que WLM no puede gestionar el trabajo, que no se puede asignar en ningún sirviente.
  • Si todos los objetos de sesión HTTP residen en uno o dos sirvientes, un tiempo de espera en un solo sirviente puede afectar a un número mayor de usuarios que si los objetos de sesión HTTP se dividen equitativamente entre varios sirvientes.

Si la configuración experimenta alguna de las situaciones descritas que generan un problema con la estrategia de sirviente dinámico, puede configurar el servidor de aplicaciones para que dé soporte a la distribución de solicitudes HTTP entrantes entre sirvientes sin afinidad de sirvientes. Cuando se habilita esta funcionalidad, el servidor de aplicaciones utiliza una distribución de turno rotativo de solicitudes HTTP en los sirvientes.

En el siguiente ejemplo, supongamos que se ha configurado el servidor de aplicaciones para utilizar la distribución de turno rotativo de solicitudes HTTP entre los sirvientes y que se han iniciado varios sirvientes para las solicitudes de cola de trabajo que tienen la misma clase de servicio asignada.

Cuando llega una nueva solicitud HTTP sin afinidad a una cola de trabajo, WLM comprueba si hay algún sirviente que tenga al menos una hebra de trabajo esperando trabajo. Si no hay hebras de trabajo disponibles en ningún sirviente, WLM pone en cola la solicitud hasta que quede disponible una hebra de trabajo en alguno de los sirvientes. Si hay hebras de trabajo disponibles, WLM busca el sirviente con el menor número de afinidades. Si hay regiones de sirviente con el mismo número de afinidades, WLM asigna el trabajo a la región de sirviente con el menor número de hebras de servidor ocupadas.

El objetivo de este algoritmo es que WLM equilibre las solicitudes entrantes sin afinidad de sirviente entre los sirvientes en espera, teniendo en cuenta las condiciones cambiantes. Este algoritmo no asigna a ciegas las solicitudes a los servidores con un turno rotativo real. En el siguiente diagrama se muestra la distribución equilibrada de objetos de sesión HTTP entre sirvientes.

Figura 6. Objetos de sesión HTTP asignados a sirvientes sin afinidad

Cada sirviente recibe aproximadamente el mismo número de objetos de sesión HTTP.

Este mecanismo de distribución funciona para todas las solicitudes entrantes sin afinidad. Una vez creado el objeto de sesión HTTP, todas las solicitudes de cliente se dirigen a ese sirviente hasta que se elimina el objeto de sesión HTTP.

Si decide habilitar la distribución de las solicitudes HTTP entrantes sin afinidad de sirvientes, deberá realizar algunos cambios en el archivo de correlación de clasificación. Si ha configurado el archivo de correlación de clasificación para que especifique más de una clase de transacción en una regla de correlación para el soporte de turno rotativo gestionado del producto proporcionado por éste, deberá eliminar esta sección del archivo de correlación de clasificación.


Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_wlm_sessionplacement
File name: crun_wlm_sessionplacement.html