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

Configuración del regulador de emergencias

El direccionador On Demand (ODR) y los gestores autónomos asociados pueden dar soporte a objetivos empresariales en momentos de intensos flujos de peticiones tomando decisiones inteligentes relacionadas con el trabajo que entra en el servidor. El gestor de flujo de peticiones autónomo (ARFM) controla la prioridad de peticiones HTTP en el ODR. Algunas veces, las situaciones de emergencia aparecen cuando determinados sensores detectan situaciones de sobrecarga. Estas situaciones de sobrecarga incluyen una utilización de nodos extremadamente alta, anomalías de comunicación intermitente entre el controlador ARFM y las pasarelas de planificación de peticiones y anomalías de comunicación intermitente entre los generadores de datos de supervisión de AsyncPMI y las pasarelas. Para impedir que estas situaciones se prolonguen, cuando se produzcan, y la degradación que ello comporta en el rendimiento, las pasarelas están equipadas con controladores de reguladores de emergencia que controlan y protegen las velocidades de envíos de peticiones a los nodos de programas de fondo. ARFM se maneja en el programa de fondo de las peticiones IIOP/JMS.

El ARFM consta de dos partes: un controlador y una pasarela. La función de ARFM la implementa, para cada grupo de nodos, un controlador más una colección de pasarelas en los direccionadores On Demand (ODR). El controlador de ARFM (activado pro el controlador eWLM, si está disponible en el sistema) puede iniciar directivas reguladoras típicas para las pasarelas. En la modalidad típica, las directivas reguladoras proceden del controlador de ARFM a través de RatesMessages, y el controlador del regulador los impone inmediatamente en la pasarela.

Hay un regulador conectado a cada cola de la pasarela y por omisión está en el estado no regulado. Cuando se produce una emergencia o cuando llegan mensajes de velocidad del controlador de ARFM, éste recibe directivas del controlador del regulador y pasa a estado regulado.

En el caso de que uno o más sensores de sobrecarga detecten una condición de sobrecarga, a pesar de la regulación típica, el controlador del regulador de pasarela pasa a modalidad de emergencia. Un sensor de suspensión de transmisión de emergencia detecta anomalías en la comunicación entre un controlador de ARFM y pasarelas de planificación de peticiones o anomalías en la comunicación entre los generadores de datos de supervisión AsyncPMI y las pasarelas. El término suspensión de transmisión significa que el sensor no recibe los mensajes esperados. En modalidad de emergencia, el controlador del regulador reduce de forma gradual las velocidades de entrega de las colas de pasarela hasta que los sensores sobrecargados detienen la emisión de avisos. A continuación, restaurará de forma gradual las velocidades a sus valores originales previos a la modalidad de emergencia. Mientras se lleva a cabo, el controlador del regulador garantiza que las directivas de velocidad del controlador de ARFM nunca se excedan y así mantener la integridad de las decisiones reguladoras realizadas por distintos controladores. El funcionamiento conjunto de estos componentes permite limitar correctamente las peticiones de entrada.

Varios sensores detectan las situaciones de emergencia, lo que provoca que el controlador del regulador pase a modalidad de emergencia. Cada sensor puede estar en uno de dos estados: activado o desactivado. Durante una situación de emergencia, hay dos fases para el controlador del regulador: emergency_throttle y emergency_unthrottle. Durante la fase emergency_throttle, el regulador reduce la velocidad de todas las colas siempre y cuando uno de los sensores siga estando activado. En la fase emergency_unthrottle, todos los sensores pasan al estado no activado y las velocidades de todas las colas se restauran de forma gradual a los valores originales que tenían antes de entrar en modalidad de emergencia.

La regulación de emergencia está habilitada por omisión (EnableEmergencyThrottlling=true); si desea inhabilitarla, modifique un archivo de configuración del sistema principal del ODR llamado arfm.cfg que se encuentra en WAS_HOME/profiles/node/properties/arfm.cfg. Para inhabilitar la modalidad de emergencia:
  1. Edite arfm.cfg.
  2. Añada EnableEmergencyThrottling=false.
La imposición de directivas de velocidad desde el controlador ARFM (iniciada por eWLM) está habilitada por omisión. Puede inhabilitarla modificando el archivo arfm.cfg como se indica a continuación:
  1. Edite arfm.cfg.
  2. Añada EnableExternalThrottling=false.
Otros parámetros de configuración que puede añadir a arfm.cfg son:
  1. EmergencyRateChangeStep=x, donde x es un entero comprendido entre 0 y 100 que especifica el cambio de porcentaje en la velocidad en cada paso de la reducción/aumento gradual de la velocidad del regulador.
    • El valor por omisión es EmergencyRateChangeStep=20
  2. EmergencyRateChangeInterval=x, donde x es el tiempo transcurrido entre dos pasos sucesivos de cambio de velocidad en modalidad de emergencia en milisegundos.
    • El valor por omisión es EmergencyRateChangeInterval=15000
  3. EmergencyBlackoutMultiplier=x, donde x es un multiplicador multiplicado por distintos ciclos de mensajes normales que se utilizan como entrada para un sensor de corte de electricidad de emergencia. EmergencyBlackoutMultiplier es un parámetro de configuración que indica indirectamente al sensor cuánto esperará antes de que se desencadene. Este intervalo se determina como el producto (multiplicación) de este EmergencyBlackoutMultiplier y el intervalo anticipado normal entre mensajes sucesivos.
    • El valor por omisión es EmergencyBlackoutMultiplier=2
  4. EmergencyCPUUtilLimit=x, donde x es un entero comprendido entre 0 y 100 que especifica la marca de límite de utilización de la CPU, en nodos de programas de fondo, que desencadena la regulación de emergencia.
    • El valor por omisión es EmergencyCPUUtilLimit=100
  5. TokenBucketSizeMillis=x. Este parámetro especifica indirectamente la cantidad de señales que pueden acumularse en la cubeta de señales de una cola.
    • El valor por omisión es TokenBucketSizeMillis=1000



Related tasks
Configuración del gestor de flujo de peticiones autónomo

Tema de concepto    

Condiciones de uso | Comentarios Última actualización: Mar 14, 2006 11:02:37 AM 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. Reservados todos los derechos.
Este centro de información se ha realizado con tecnología de Eclipse. (http://www.eclipse.org)