WebSphere Extended Deployment, Version 6.0.x     Sistemas Operacionais: AIX,, HP-UX, Linux, Solaris , Windows , z/OS

Configurando a Retenção de Emergência

O ODR (On Demand Router) e os gerenciadores autônomos associados podem suportar metas de negócios em tempos de fluxos de pedidos intensos, tomando decisões inteligentes sobre o trabalho que chega no servidor. O ARFM (Autonomic Request Flow Manager) controla a priorização de pedidos HTTP no ODR. Às vezes, as condições de emergência ocorrem quando determinados sensores detectam tais situações sobrecarregadas. Essas situações de sobrecarga incluem a utilização extremamente alta de nós, falhas intermitentes na comunicação entre o controlador do ARFM e os gateways de planejamento de pedido e falhas intermitentes na comunicação entre os produtores de dados de monitoramento AsyncPMI e os gateways. Para prevenir o prolongamento destas condições, caso ocorram, e a degradação de desempenho correspondente, os gateways são equipados com controladores de retenção de emergência que controlam e protegem as taxas de dispatch de pedidos para nós de backend. O ARFM é manipulado no backend para pedidos IIOP/JMS.

O ARFM contém duas partes: um controlador e um gateway. A função do ARFM é implementada, para cada grupo de nós, por um controlador mais uma coleta de gateways nos ODRs. O controlador do ARFM (acionado pelo controlador do eWLM se estiver disponível no sistema) pode iniciar diretivas típicas de retenção para os gateways. Em um modo típico, as diretivas de retenção vêm do controlador do ARFM por meio de RatesMessages, e são imediatamente impostas no gateway pelo controlador de retenção.

Uma retenção é conectada a cada fila no gateway e, por padrão, está no estado acelerado. Quando ocorre uma emergência ou quando chegam mensagens de taxas do controlador ARFM, ele recebe diretivas do controlador de retenção e é alterado para o estado retido.

No caso de um ou mais sensores de sobrecarga detectarem uma condição de sobrecarga, apesar da retenção típica, o controlador de retenção do gateway entra no modo de emergência. Um sensor de blecaute de emergência detecta falhas na comunicação entre um controlador ARFM e gateways de planejamento de pedidos, ou falhas na comunicação entre os produtores de dados de monitoramento de AsyncPMI e os gateways. O termo blackout significa que o sensor não recebe as mensagens esperadas. No modo de emergência, o controlador de retenção reduz gradualmente as taxas de dispatch das filas do gateway até que o sensor ou sensores sobrecarregados parem de disparar. Ele então restaura gradualmente as taxas para suas configurações originais anteriores ao modo de emergência. Enquanto estiver fazendo isto, o controlador de retenção assegura que as diretivas de taxas do controlador ARFM nunca sejam excedidas, preservando, assim, a integridade das decisões de retenção tomadas por diferentes controladores. Trabalhando juntos, esses componentes podem limitar apropriadamente os pedidos que chegam.

Vários sensores detectam condições de emergência, fazendo com que o controlador de retenção entre no modo de emergência. Cada sensor pode estar em um dos dois estados: disparado ou não disparado. Durante uma emergência, existem duas fases para o controlador de retenção: emergency_throttle e emergency_unthrottle. Durante a fase emergency_throttle, a retenção reduz todas as taxas da fila enquanto um dos sensores ainda dispara. Na fase emergency_unthrottle, todos os sensores retornam ao estado não disparado e, gradualmente, restauram todas as taxas da fila para os valores originais que tinham antes de entrarem no modo de emergência.

A retenção de emergência é ativada por padrão (EnableEmergencyThrottlling=true). Você pode desativá-la modificando um arquivo de configuração no host ODR, chamado arfm.cfg, localizado em WAS_HOME/profiles/node/properties/arfm.cfg. Para desativar o modo de emergência:
  1. Edite arfm.cfg.
  2. Inclua EnableEmergencyThrottling=false.
O reforço de diretivas de taxa do controlador ARFM (iniciado por eWLM) é ativado por padrão. Você pode desativá-lo modificando arfm.cfg da seguinte forma:
  1. Edite arfm.cfg.
  2. Inclua EnableExternalThrottling=false.
Outros parâmetros de configuração que podem ser incluídos em arfm.cfg:
  1. EmergencyRateChangeStep=x, em que x é um inteiro entre 0 e 100 que especifica a alteração de porcentagem na taxa em cada etapa da redução/do aumento gradual da taxa de retenção.
    • O padrão é EmergencyRateChangeStep=20.
  2. EmergencyRateChangeInterval=x, em que x é o tempo entre duas etapas sucessivas de alteração de taxa em modo de emergência, em milissegundos.
    • O padrão é EmergencyRateChangeInterval=15000.
  3. EmergencyBlackoutMultiplier=x, em que x é um multiplicador multiplicado por ciclos diferentes de mensagens normais, utilizados como entrada para o sensor de blackout de emergência. O EmergencyBlackoutMultiplier é um parâmetro de configuração que instrui o sensor indiretamente por quanto tempo ele deve aguardar antes de disparar. Este intervalo é determinado como o produto (multiplicação) deste EmergencyBlackoutMultiplier e o intervalo normal antecipado entre mensagens sucessivas.
    • O padrão é EmergencyBlackoutMultiplier=2.
  4. EmergencyCPUUtilLimit=x, em que x é um inteiro entre 0 e 100 que especifica a marca d'água de utilização da CPU, em nós de backend, que aciona a retenção de emergência.
    • O padrão é EmergencyCPUUtilLimit=100.
  5. TokenBucketSizeMillis=x. Este parâmetro especifica indiretamente quantos tokens podem ser acumulados no quadro de tokens de uma fila.
    • O padrão é TokenBucketSizeMillis=1000.



Related tasks
Configurando o Autonomic Request Flow Manager

Tópico de Conceito    

Termos de Uso | Feedback Última atualização: Mar 21, 2006 12:47:43 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/todoecnfthrottle.html

© Copyright IBM 2005, 2006. Todos os Direitos Reservados.
Este centro de informações é desenvolvido em tecnologia Eclipse. (http://www.eclipse.org)