![[z/OS]](../images/ngzos.gif)
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.
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.
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 ********************************
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.
- 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:
- Se utilizan objetos de sesión HTTP en memoria, lo que crea afinidades de asignación.
- Los objetos de sesión HTTP duran muchas horas o días.
- Hay un gran número de clientes con objetos de sesión HTTP que se deben mantener en memoria.
- La pérdida de un objeto de sesión interrumpe la ejecución del cliente o el servidor, y transcurre mucho tiempo entre las solicitudes que crean sesiones HTTP.
- 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.
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.