[z/OS]

Distribuição Uniforme do WLM de Pedidos de HTTP

O componente WLM (gerenciamento de trabalho de trabalho) do z/OS suporta distribuição de pedidos HTTP de entrada sem a afinidade de servant, de maneira circular entre os servants. Essa funcionalidade foi planejada para, mas não se limita a, objetos de sessão HTTP de duração longa que são mantidos na memória, EJB (Enterprise JavaBeans) de sessão sem estado e método de criação para enterprise beans de sessão com estado. Você pode configurar o produto para utilizar essa funcionalidade para difundir pedidos HTTP entre servants ativos que estão ligados atualmente à mesma fila de trabalho dos pedidos de entrada.

O diagrama a seguir representa uma instância de servidor em cluster. O cluster azsr01 contém a instância do servidor de aplicativos azsr01a. Na instância do servidor de aplicativos está um controlador, a fila do WLM (Workload Manager) e os servants onde os aplicativos são executados. O controlador é o ponto de terminação de HTTP e IIOP. A fila do WLM controla o fluxo de trabalho do controlador para um dos servants. Cada um dos servants contém encadeamentos trabalhadores que selecionam o trabalho a partir da fila do WLM.

Figura 1. O Conteúdo de uma Instância de Servidor em Cluster

Os pedidos que chegam vão para a região de controle, por meio da fila do gerenciador de carga de trabalho, e são designados a worker threads em uma região servidora específica.

No diagrama anterior, o servidor de aplicativos está configurado para ter o número mínimo e máximo de servants definido como três.

Existem definições de WLM para os servidores de aplicativos neste cluster. Todos os pedidos para qualquer instância de servidor de aplicativos no cluster azsr01 são designados para a mesma classe de serviço. As regras de classificação do WLM designam todos os enclaves que estão sendo executados no servidor de aplicativos azsr01a para a classe de serviço AZAMS1. Consulte os diagramas a seguir para obter um exemplo da definição da classe de serviço do WLM e das regras de classificação.
Figura 2. A Definição da Classe de Serviço do WLM
   Classe de Serviço Xref  Notas Opções Ajuda                                    
 --------------------------------------------------------------------------     
                           Modificar uma Classe de Serviço               Linha 1 para 2 de 2 
 Command ===> ______________________________________________________________    
                                                                                
 Nome da Classe de Serviço . . . . . : AZAMS1                                          
 Description  . . . . . . . . . Trabalho de Enclave do WAS                                
 Nome da Carga de Trabalho  . . . . . . . . ONL_WKL   (nome ou ?)                           
 Base Resource Group  . . . . . ________  (nome ou ?)                           
 Cpu Crítica . . . . . . . . . NÃO        (SIM ou NÃO)                           
                                                                                
 Especificar Informações da META BASE.  Códigos de Ação: I=Inserir novo período,             
 E=Editar período, D=Excluir período.                                                
                                                                                
         ---Período---  ---------------------Meta---------------------           
 Ação  #  Duração   Imp.  Descrição                                        
   __                                                                           
   __    1              1    Velocidade de execução de 50                           
 ******************************* Final dos dados ********************************
Figura 3. As Regras de Classificação do Subsistema WLM CB
   Tipo de Subsistema Xref Notas  Opções  Ajuda                              
 --------------------------------------------------------------------------
                  Modificar Regras para o Tipo de Subsistema    Linha 11 para 20 de 20
 Comando ===> ____________________________________________ SCROLL ===> CSR 
                                                                           
 Subsystem Type . : CB Envolver nomes de qualificadores?   Y  (Y or N)        
 Description  . . . Pedidos do Component Broker                              
                                                                           
 Códigos de ação:   D=Depois     C=Copiar        M=Mover     I=Inserir regra        
                 A=Antes    E=Excluir linha  R=Repetir   IS=Inserir subregra   
                                                              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 *****************************

O produto suporta o uso de objetos de sessão HTTP na memória para os servidores de aplicativos com diversos servidores, também conhecidos como estratégia de servidor hot. No diagrama a seguir, dois usuários acessaram um aplicativo na instância do servidor de aplicativos azsr01a. O usuário 1 estabeleceu um objeto de sessão HTTP no servant 3. O usuário 2 estabeleceu um objeto de sessão HTTP no servant 2.

Figura 4. Usuários Estabelecem Objetos de Sessão HTTP

O usuário 1 estabelece um objeto de sessão HTTP no servant 3. O usuário 2 estabelece um objeto de Sessão HTTP no servant 2.

Quando um usuário acessa uma região servidora sem um objeto de sessão HTTP estabelecido, não existe afinidade de região servidora. Portanto, o pedido pode ser despachado para qualquer servant disponível. O WLM poderá iniciar um novo servant se todas as condições a seguir existirem:
  • A configuração permite a criação de novos servants
  • A lógica do gerenciador de carga de trabalho determina se o sistema pode sustentar um servant adicional
  • A inclusão de um outro servant causa retardo reduzido da fila e permite que os enclaves sejam concluídos dentro do objetivo especificado

Quando vários servants estão ligados à mesma classe de serviço, o WLM tenta despachar os novos pedidos para um servant automático. Um servant automático possui um pedido recente despachado para ele e possui encadeamentos disponíveis. Se o servant automático possuir um acúmulo de trabalho, o WLM despachará o trabalho para outro servant.

Normalmente a execução dessa estratégia do servant automático é boa porque o servant automático provavelmente possui todas as suas páginas necessárias em armazenamento, os métodos de aplicativos JIT (Just-In-Time) compilados salvos em local próximo e um cache cheio de dados para recuperação rápida de dados. No entanto, essa estratégia apresenta um problema nas seguintes situações:

Na última situação, o resultado é uma distorção indesejada na distribuição de objetos de sessão HTTP. No seguinte diagrama, a maior parte de objetos de sessão HTTP foram designados como servant 1.
Figura 5. Objetos de Sessão HTTP Designados para um Servant Automático

Os objetos de sessão HTTP são designados ao servant automático, o servant 1.

Uma grande porcentagem de objetos de sessão HTTP residem em um ou dois servants porque, na maior parte do tempo, não existem pedidos suficientes na fila WLM para garantir o despacho do trabalho entre muitos servants. Esse comportamento pode levar aos seguintes resultados indesejáveis.
  • Se o aplicativo criar um grande número de objetos em um único servant, poderá resultar em horas de longa coleta de lixo.
  • Se todos os objetos de sessão HTTP estiverem ligados a um servant, os pedidos poderão ser mantidos na fila por um longo período de tempo porque o trabalho não poderá ser gerenciado pelo WLM e não poderá ser despachado em nenhum servant.
  • Se todos os objetos de sessão HTTP residirem em um ou dois servants, um tempo limite em um único servant poderá afetar um número de usuários maior do que se os objetos de sessão HTTP estiverem divididos igualmente entre vários servants.

Se a configuração passar por uma das situações descritas que provocam um problema com a estratégia do servant automático, será possível configurar o servidor de aplicativos para suportar a distribuição de pedidos de HTTP recebidos por meio de servants sem afinidade com o servant. Quando essa funcionalidade é ativada, o servidor de aplicativos utiliza uma distribuição round-robin de pedidos de HTTP para os servants.

No exemplo a seguir, assuma que o servidor de aplicativos foi configurado para utilizar a distribuição round-robin de pedidos de HTTP entre os servants e vários servants são iniciados para os pedidos de fila de trabalho que possuem a mesma classe de serviço designada.

Quando um novo pedido de HTTP sem afinidade chega a uma fila de serviço, o WLM verifica se existe um servant que possui pelo menos um encadeamento trabalhador esperando trabalho. Se não existir nenhum encadeamento trabalhador disponível em nenhum servant, o WLM colocará o pedido na fila até que um encadeamento trabalhador em qualquer um dos servants esteja disponível. Se houver encadeamentos trabalhadores disponíveis, o WLM localizará o servant com o menor número de afinidades. Se houver regiões servants com número igual de afinidades, o WLM despachará o trabalho para a região servidora com o menor número de encadeamentos de servidores ocupados.

O objetivo desse algoritmo é que o WLM equilibre os pedidos recebidos sem afinidade de servant entre servants de espera, enquanto considera as alterações nas condições. O algoritmo não atribui pedidos cegamente aos servidores, como seria em um verdadeiro modo round-robin. O diagrama a seguir mostra a distribuição equilibrada de objetos de sessão HTTP por meio de servants.

Figura 6. Objetos de Sessão HTTP Designados para Servants sem Afinidade

Cada servant recebe aproximadamente o mesmo número de objetos de sessão HTTP.

Esse mecanismo de distribuição funciona para todos os pedidos de entrada sem afinidade. Após a criação do objeto de sessão HTTP, todos os pedidos do cliente são direcionados para esse servant até que o objeto de sessão HTTP seja removido.

Se você decidir ativar a distribuição de pedidos de HTTP que chegam sem afinidade de servant, poderá ser necessário fazer algumas alterações no arquivo de mapeamento de classificação. Se você tiver configurado o arquivo de mapeamento de classificação para especificar mais de uma classe de transação em uma regra de mapeamento para o suporte circular gerenciado que o produto fornece, remova essa seção do arquivo de mapeamento de classificação.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_wlm_sessionplacement
Nome do arquivo: crun_wlm_sessionplacement.html