Funciones del gestor, asesores y Metric Server para Dispatcher, CBR y Site Selector

Este capítulo explica cómo configurar los parámetros de equilibrio de carga y cómo configurar las funciones de gestor, asesor y Metric Server de Load Balancer.

Nota:
Al leer este capítulo, si no está utilizando el componente Dispatcher, sustituya "dscontrol" por lo siguiente:
Tabla 10. Tareas de configuración avanzadas para Load Balancer
Tarea Descripción Información relacionada
Si se desea, se pueden cambiar los valores del equilibrio de carga

Puede cambiar los siguientes valores de equilibrio de carga:

  • Proporción de la importancia otorgada a la información de estado

    La proporción predeterminada es 50-50-0-0. Si emplea el valor predeterminado, no se utilizará la información de asesores, Metric Server y WLM.

  • Pesos
  • Pesos fijados por el gestor
  • Intervalos del gestor
  • Umbral de sensibilidad
  • Índice de suavizado
Optimización del equilibrio de carga proporcionado por Load Balancer
Utilizar scripts para generar una alerta o anotar anomalía de servidor cuando el gestor marca los servidores como inactivos o activos Load Balancer proporciona salidas de usuario que desencadenan scripts que se pueden personalizar cuando el gestor marca el servidor o los servidores como inactivos o activos Utilización de scripts para generar una alerta o anotar anomalías en el servidor
Utilizar asesores Describe y lista los asesores, que informan sobre estados concretos de los servidores Asesores
Utilizar la opción de solicitud y respuesta (URL) del asesor HTTP o HTTPS Define una serie de URL HTTP de cliente exclusiva, específica de un servicio que desea examinar en la máquina Configuración del asesor HTTP o HTTPS utilizando la opción de solicitud y respuesta (URL)
Utilizar el asesor automático Proporciona estado de carga del servidor de programa de fondo en una configuración WAN de dos niveles de Load Balancer Utilización de asesor automático en una configuración WAN de dos niveles
Crear asesores personalizados Describe cómo escribir sus propios asesores personalizados Crear asesores personalizados (personalizables)
Utilizar agente de Metric Server Metric Server proporciona información de carga de sistema a Load Balancer Metric Server
Utilizar asesor WLM (Workload Manager - Gestor de carga de trabajo) El asesor WLM proporciona información de carga de sistema a Load Balancer Asesor de Workload Manager

Optimización del equilibrio de carga proporcionado por Load Balancer

La función de gestor de Load Balancer realiza el equilibrio de carga basándose en los siguientes valores:

Si lo desea, modifique estos valores para optimizar el equilibrio de carga para la red.

Proporción de la importancia otorgada a la información de estado

El gestor puede tener en cuenta algunos de los siguientes factores externos o todos cuando se sopesan las decisiones:

Junto con el peso actual para cada servidor y alguna otra información necesaria para sus cálculos, el gestor obtiene los dos primeros valores (conexiones activas y nuevas) del ejecutor. Estos valores se basan en la información generada y almacenada internamente en el ejecutor.

Nota:
En el caso de Site Selector, el gestor obtiene los dos primeros valores (CPU y memoria) para Metric Server.

Puede cambiar la proporción de importancia relativa de los cuatros valores clúster por clúster (o nombre de sitio). Piense en las proporciones como si fueran porcentajes; la suma de las proporciones relativas debe ser 100%. La proporción predeterminada es 50/50/0/0, que ignora la información del asesor y del sistema. En el entorno, es posible que necesite probar diferentes proporciones para encontrar la combinación que ofrece el mejor rendimiento.

Nota:
Al añadir un asesor (que no sea WLM), si la proporción del puerto es cero, el gestor aumenta este valor hasta 1. Puesto que la suma de las proporciones relativas debe ser 100, se restará 1 al valor más alto.

Al añadir el asesor WLM, si la proporción de métrica del sistema es cero, el gestor aumenta este valor hasta 1. Puesto que la suma de las proporciones relativas debe ser 100, se restará 1 al valor más alto.

El número de conexiones activas depende del número de clientes así como del periodo de tiempo necesario para utilizar los servicios proporcionados por las máquinas de servidor con equilibrio de carga. Si las conexiones de cliente son rápidas (como páginas Web pequeñas servidas mediante HTTP GET), el número de conexiones activas será bastante bajo. Si la conexiones de cliente son más lentas (como una consulta a una base de datos), el número de conexiones activas será más alto.

Debe evitar establecer demasiado bajos los valores de las proporciones de conexiones activas y nuevas. Debe inhabilitar el equilibrio de carga y el suavizado, a menos que estos dos valores estén establecidos como mínimo en 20 cada uno.

Para definir la proporción de los valores de importancia, emita el mandato dscontrol cluster set clúster proportions. Consulte dscontrol cluster — configurar clústeres para obtener más información.

Pesos

La función de gestor establece los pesos basándose en contadores internos del ejecutor, información de retorno de los asesores y la información de retorno un programa de supervisión del sistema, por ejemplo Metric Server. Si desea establecer pesos manualmente mientras ejecuta el gestor, especifique la opción fixedweight en el mandato dscontrol server. Para obtener una descripción de la opción fixedweight, consulte Pesos fijados por el gestor.

Los pesos se aplican a todos los servidores de un puerto. Para cualquier puerto concreto, las solicitudes se distribuyen entre los servidores en función del peso relativo que dichos servidores tienen entre sí. Por ejemplo, si el peso de un servidor se establece en 10 y el de otro en 5, el servidor establecido en 10 debería recibir el doble de solicitudes que el servidor establecido en 5.

Para especificar el límite máximo de peso que un servidor puede tener, utilice el mandato dscontrol port set puerto weightbound peso. Este mandato afecta a la diferencia permitida entre la cantidad de solicitudes que cada servidor obtendrá. Si establece el valor máximo de weightbound en 1, todos los servidores podrán tener un peso de 1, 0 si está inmovilizado o -1 si se marca inactivo. Cuando se incrementa este número, aumentará la diferencia entre el peso que se puede otorgar a los servidores. A un valor de weightbound máximo de 2, un servidor puede obtener el doble de solicitudes que otro. A un máximo de ponderación de 10, un servidor puede obtener 10 veces más solicitudes que otro. El valor máximo predeterminado de weightbound es 20.

Si un asesor encuentra que un servidor ha concluido, lo comunica al gestor y éste establecerá el peso para el servidor en cero. Como resultado, el ejecutor no enviará ninguna conexión adicional a dicho servidor siempre que dicho peso permanezca en cero. Si hay alguna conexión activa con dicho servidor antes de que cambie el peso, ésta se dejará que se complete normalmente.

Si todos los servidores están inactivos, el gestor establece los pesos a la mitad de la ponderación.

Pesos fijados por el gestor

Sin el gestor, los asesores no se pueden ejecutar y no pueden detectar si un servidor está inactivo. Si opta por ejecutar los asesores, pero no desea que el gestor actualice el peso establecido para un servidor concreto, utilice la opción fixedweight en el mandato dscontrol server. Por ejemplo:

dscontrol server set cluster:port:server fixedweight yes

Una vez que fixedweight se establece en yes, utilice el mandato dscontrol server set weight para establecer el peso en el valor que desee. El valor de peso de servidor permanece fijo mientras el gestor se está ejecutando hasta que emite otro mandato dscontrol server con el valor de fixedweight establecido en no. Para obtener más información, consulte dscontrol server — configurar servidores.

Envío de una restauración TCP a un servidor inactivo (sólo componente Dispatcher)

Si se activa una restauración TCP, Dispatcher enviará una restauración TCP al cliente cuando éste tenga una conexión con un servidor con un peso 0. El peso de un servidor puede ser 0 si se ha configurado 0 o si un asesor lo marca como inactivo. Una restauración TCP hará que la conexión se cierre inmediatamente. Esta característica es útil para conexiones de larga duración donde acelera la capacidad el cliente para renegociar una conexión anómala. Para activar la restauración TCP, utilice el mandato dscontrol port add|set puerto reset yes. El valor predeterminado para reset es no.

Nota:
La restauración TCP se aplica a todos los métodos de reenvío de Dispatcher. No obstante, para utilizar la característica de restauración TCP, la opción clientgateway en el mandato dscontrol executor debe se establecer en una dirección de direccionador. .

Una característica que será de gran utilidad configurar, junto con la restauración TCP, es advisor retry. Con esta característica, un asesor tiene la posibilidad de volver a intentar una conexión antes de marcar un servidor como inactivo. Esto ayudará a impedir que el asesor marque prematuramente el servidor como inactivo, lo que podría provocar problemas en la restauración de la conexión. Es decir, sólo porque el asesor haya fallado en el primer intento, no significa necesariamente que las conexiones existentes también están sufriendo anomalías. Consulte Reintento del asesor para obtener más información.

Intervalos del gestor

Para optimizar el rendimiento general, se restringe la frecuencia con la que el gestor puede interactuar con el ejecutor. Puede realizar cambios en este intervalo entrando los mandatos dscontrol manager interval y dscontrol manager refresh.

El intervalo del gestor especifica la frecuencia con la que el gestor actualizará los pesos del servidor que el ejecutor utiliza en el direccionamiento de conexiones. Si el intervalo del gestor es demasiado bajo, puede suponer un bajo rendimiento como resultado de que el gestor interrumpe constantemente al ejecutor. Si el valor de intervalo del gestor es demasiado alto, puede indicar que el direccionamiento de solicitudes del ejecutor no se basará en información actualizada y precisa.

Por ejemplo, para establecer el intervalo en 1 segundo, escriba el siguiente mandato:

 dscontrol manager interval 1

El ciclo de renovación del gestor especifica con qué frecuencia el gestor solicitará información de estado al ejecutor. El ciclo de renovación se basa en el intervalo de tiempo.

Por ejemplo, para establecer el ciclo de renovación del gestor en 3, escriba el siguiente mandato:

  dscontrol manager refresh 3

Esto hará que el gestor espere 3 intervalos antes de solicitar el estado al ejecutor.

Umbral de sensibilidad

Hay otros métodos disponibles para optimizar el equilibrio de carga para los servidores. Para trabajar a máxima velocidad, sólo se actualizan los pesos de los servidores si dichos pesos han cambiado de una manera significativa. Si se actualizan constantemente los pesos cuando no se produce ningún cambio en el estado del servidor o dicho cambio es muy pequeño, supondrá una carga adicional innecesaria. Cuando el cambio de porcentaje del peso total de todos los servidores de un puerto es mayor que el umbral de sensibilidad, el gestor actualiza los pesos utilizados por el ejecutor para distribuir las conexiones. Por ejemplo, suponga que el total de los cambios de pesos pasa de 100 a 105. El cambio es del 5%. Con el umbral de sensibilidad predeterminada 5, el gestor no actualizará los pesos utilizados por el ejecutor, porque el cambio del porcentaje no está por encima del umbral. Sin embargo, si el peso total pasa de 100 a 106, el gestor actualizará los pesos. Para establecer el umbral de sensibilidad el gestor en un valor distinto del valor predeterminado (por ejemplo, 6), especifique el siguiente mandato:

  dscontrol manager sensitivity 6

En la mayoría de los casos, no es necesario cambiar este valor.

Índice de suavizado

El gestor calcula los pesos de servidores de forma dinámica. En consecuencia, un peso actualizado puede ser muy distinto de uno anterior. En la mayoría de casos, esto no será un problema. Sin embargo, en algunas ocasiones puede causar un efecto de fluctuación en la forma en que se realiza el equilibrio de carga en las solicitudes. Por ejemplo, un servidor puede acabar recibiendo la mayoría de las solicitudes debido a un peso alto. El gestor verá que el servidor tiene un elevado número de conexiones activas y que el servidor responde muy lentamente. Entonces pasará el peso a los servidores libres, lo que producirá el mismo efecto y provocará una utilización de recursos ineficaz.

Para aliviar este problema, el gestor utiliza un índice de suavizado. El índice de suavizado limita la cantidad que el peso de un servidor puede cambiar, mitigando el cambio en la distribución de solicitudes. Un índice de suavizado más alto hará que los pesos de servidores cambien menos radicalmente. Un índice más bajo hará que los pesos de servidores cambien de forma más radical. El valor predeterminado para el índice de suavizado es 1,5. Con un índice de 1,5, los pesos de servidores pueden ser bastante dinámicos. Si se especifica un índice de 4 o 5, los pesos serán más estables. Por ejemplo, para establecer el índice de suavizado en 4, escriba el siguiente mandato:

  dscontrol manager smoothing 4

En la mayoría de los casos, no es necesario cambiar este valor.

Utilización de scripts para generar una alerta o anotar anomalías en el servidor

Load Balancer proporciona salidas de usuario que desencadenan scripts que se pueden personalizar. Puede crear los scripts para realizar acciones automatizadas, como avisar a un administrador cuando el gestor ha marcado que los servidores están inactivos o simplemente anotar el suceso de la anomalía. Los scripts de ejemplo, que puede personalizar, están en el directorio siguiente:

Para ejecutar los archivos, debe ponerlos en el directorio siguiente y eliminar la extensión de archivo "sample".

Se proporcionan los siguientes scripts de ejemplo:

Si todos los servidores de un clúster se marcan como inactivos (por el usuario o por los asesores), se inicia managerAlert (si está configurado) y Load Balancer intenta direccionar el tráfico a los servidores utilizando una técnica de turno rotativo. El script serverDown no se inicia cuando se ha detectado que el último servidor del clúster está fuera de línea.

Load Balancer se ha diseñado de modo que intente continuar direccionando el tráfico en caso de que un servidor vuelva a estar en línea y responda a la solicitud. Si en lugar de esto, Load Balancer dejara de direccionar todo el tráfico, el cliente no recibiría ninguna respuesta.

Cuando Load Balancer detecta que el primer servidor de un clúster vuelve a estar en línea, se inicia el script managerClear (si está configurado), aunque el script serverUp (si está configurado) no se ejecutará hasta que no vuelva a estar en línea un servidor adicional.

Factores que deben tenerse en cuenta cuando se utilizan los scripts serverUp y serverDown:

Asesores

Los asesores son agentes Load Balancer. Su finalidad es evaluar el estado y la carga de las máquinas servidor. Esto lo llevan a cabo con un intercambio parecido a los clientes proactivos con los servidores. Los asesores se consideran como clientes ligeros de los servidores de aplicaciones.

El producto proporciona varios asesores específicos de protocolo para la mayoría de los protocolos más utilizados. No obstante, no tiene sentido utilizar todos los asesores proporcionados con cada componente de Load Balancer. (Por ejemplo, no utilice el asesor Telnet con el componente CBR). Load Balancer también soporta el concepto de "asesor personalizado" que permite a los usuarios escribir sus propios asesores.

Limitación en la utilización de aplicaciones de servidor específicas de enlace: Para poder utilizar asesores en servidores específicos del enlace, inicie dos instancias del servidor: una instancia para enlazar el clúster:puerto y la otra instancia para enlazar en servidor:puerto. Para determinar si el servidor es específico del enlace, emita el mandato netstat -an y busque server:port. Si el servidor no es específico del enlace, el resultado del mandato será 0.0.0.0:80. Si el servidor es específico del enlace, verá una dirección parecida a 192.168.15.103:80.

Para sistemas HP-UX y Solaris, limitación en la utilización de aplicaciones de servidor específicas de enlace: Si utiliza el mandato arp publish en lugar del mandato ifconfig alias, Load Balancer dará soporte al uso de asesores cuando los servidores que realizan el equilibrio de carga con aplicaciones de servidores específicos del enlace (incluidos otros componentes de Load Balancer, como CBR o Site Selector) cuando están enlazados a la dirección IP del clúster. Sin embargo, cuando se utilizan asesores en aplicaciones de servidor específicas de enlace, no coloque Load Balancer en la misma máquina que la aplicación de servidor.

Nota:
Cuando Load Balancer se está ejecutando en un sistema con varias tarjetas de adaptador de red y desea que el tráfico del asesor circule por un adaptador concreto, puede forzar la dirección IP de origen de los paquetes de forma que sea una dirección concreta. Para forzar que la dirección de origen de paquetes del asesor sea una dirección concreta, añada la siguiente línea java...SRV_XXXConfigServer... en el archivo script (dsserver, cbrserver o ssserver) de inicio de Load Balancer adecuado.
-DLB_ADV_SRC_ADDR=dirección_IP

Cómo funcionan los asesores

Los asesores abren periódicamente una conexión TCP con cada servidor y envían un mensaje de solicitud al servidor. El contenido del mensaje es específico para el protocolo que se ejecuta en el servidor. Por ejemplo, el asesor HTTP envía una solicitud HTTP "HEAD" al servidor.

Los asesores están a la escucha de la respuesta del servidor. Después de obtener la respuesta, el asesor realiza una evaluación del servidor. Para calcular este valor de "carga", la mayoría de los asesores estiman el tiempo que el servidor tarda en responder y luego utilizan este valor (en milisegundos) como carga.

A continuación, los asesores notifican el valor de carga a la función de gestor, donde aparece en el informe de gestor en la columna "Puerto". Luego, el gestor calcula los valores de peso total de todas las fuentes, según sus proporciones y establece estos valores en la función del ejecutor. El ejecutor utilizará estos valores para realizar el equilibrio de carga de nuevas conexiones de cliente entrantes.

Si el asesor determina que un servidor está activo y funciona, notificará al gestor un número de carga positivo distinto de cero. Si el asesor determina que un servidor no está activo, devolverá un valor de carga especial de uno negativo (-1). El gestor y el ejecutor no reenviarán conexiones adicionales a dicho servidor hasta que el servidor vuelva a estar de activo.

Nota:
Antes de enviar el mensaje de solicitud inicial, el asesor emitirá el mandato ping al servidor. Esto proporcionará rápidamente el estado para determinar si la máquina está en línea. Una vez que el servidor responda al mandato ping, no se enviarán más mandatos ping. Para inhabilitar el envío de mandatos ping, añada -DLB_ADV_NO_PING al archivo script de inicio de Load Balancer.

Inicio y detención de un asesor

Si lo desea, puede iniciar un asesor para un puerto concreto de todos los clústeres (asesor de grupo). O bien, puede optar por ejecutar distintos asesores en el mismo puerto, pero en distintos clústeres (asesor específico del clúster/sitio). Por ejemplo, si Load Balancer está definido con tres clústeres (clústerA, clústerB, clústerC), cada uno de los cuales tiene el puerto 80, puede realizar lo siguiente:

Si utiliza el ejemplo de configuración anterior para el asesor de grupo, puede decidir detener el asesor personalizado ADV_personalizado para el puerto 80 en sólo uno de los clústeres o en ambos (clústerB y clústerC).

Intervalos de asesor

Nota:
Los valores predeterminados del asesor deben funcionar de forma eficaz para la gran mayoría de casos posibles. Tenga cuidado al especificar valores distintos a los valores predeterminados.

El intervalo del asesor establece la frecuencia con la que un asesor solicita el estado de los servidores en el puerto que está supervisando y, a continuación, notifica los resultados al gestor. Si el intervalo del asesor es demasiado bajo, puede suponer un bajo rendimiento como resultado de que el asesor interrumpe constantemente a los servidores. Si el valor de intervalo del asesor es demasiado alto, puede indicar que las decisiones del gestor sobre la ponderación no se basan en información actualizada y precisa.

Por ejemplo, para establecer el intervalo en 3 segundos para el asesor HTTP para el puerto 80, escriba el siguiente mandato:

  dscontrol advisor interval http 80 3

No tiene sentido especificar un intervalo de asesor más pequeño que el intervalo del gestor. El valor predeterminado del intervalo del asesor son siete segundos.

Tiempo de espera de informe del asesor

Para asegurarse de que el gestor no utiliza información desfasada en sus decisiones de equilibrio de carga, el gestor no utilizará información procedente del asesor cuya indicación de la hora sea anterior a la hora establecida en el tiempo de espera de informe del asesor. El tiempo de espera de informe del asesor debe ser mayor que el intervalo de sondeo del asesor. Si el tiempo de espera es más pequeño, el asesor ignorará informes que en buena lógica deberían utilizarse. De manera predeterminada, los informes de asesor no exceden el tiempo de espera — el valor predeterminado es ilimitado.

Por ejemplo, para establecer el tiempo de espera de informe del asesor en 30 segundos para el asesor HTTP para el puerto 80, escriba el siguiente mandato:

dscontrol advisor timeout http 80 30 

Para obtener más información sobre cómo establecer el tiempo de espera de informe de asesor, consulte dscontrol advisor — controlar el asesor.

Tiempo de espera de conexión y recepción del asesor para los servidores

Para Load Balancer, puede establecer los valores de tiempo de espera del asesor en los que éste detecta que un puerto determinado del servidor (un servicio) ha sufrido una anomalía. Los valores de tiempo de espera del servidor anómalo (connecttimeout y receivetimeout) determinan cuánto tiempo espera un asesor antes de informar que se ha producido una anomalía en una conexión o recepción.

Para obtener la detección más rápida de servidor anómalo, establezca los tiempos de espera de conexión y recepción de asesor en el valor más pequeño (un segundo) y establezca el intervalo de tiempo de asesor y gestor en el valor más pequeño (un segundo).

Nota:
Si el volumen de tráfico de la red oscila entre moderado a alto y la respuesta del servidor aumenta, no establezca los valores timeoutconnect y timeoutreceive demasiado bajos o el asesor podría marcar prematuramente un servidor ocupado como anómalo.

Por ejemplo, para establecer connecttimeout y receivetimeout en 9 segundos para el asesor HTTP en el puerto 80, escriba el siguiente mandato:

dscontrol advisor connecttimeout http 80 9
dscontrol advisor receivetimeout http 80 9  

El valor predeterminado para el tiempo de espera de conexión y recepción es 3 veces el valor especificado para el tiempo de intervalo del asesor.

Reintento del asesor

Los asesores tienen la capacidad de reintentar una conexión antes de marcar un servidor como inactivo. El asesor no marcará un servidor como inactivo hasta que la consulta del servidor haya fallado el número de reintentos más 1. El valor de retry no debe ser mayor que 3. El siguiente mandato establece un valor de reintento de 2 para el asesor LDAP en el puerto 389:

dscontrol advisor retry ldap 389 2

Lista de asesores

Configuración del asesor HTTP o HTTPS utilizando la opción de solicitud y respuesta (URL)

La opción URL para el asesor HTTP o HTTPS está disponible para los componentes Dispatcher y CBR.

Después de haber iniciado un asesor HTTP o HTTPS, puede definir una serie URL HTTP de cliente exclusiva, específica para el servicio que desea consultar en el servidor. Esto permite que el asesor evalúe el estado de servicios individuales dentro de un servidor. Para hacerlo, defina los servidores lógicos con nombres de servidor exclusivos que tengan la misma dirección IP física. Consulte Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP) para obtener más información.

Para cada servidor lógico definido bajo el puerto HTTP, puede especificar una serie URL HTTP de cliente exclusiva, específica para el servicio que desea examinar en el servidor. El asesor HTTP o HTTPS utiliza la serie advisorrequest para consultar el estado de los servidores. El valor predeterminado es HEAD / HTTP/1.0. La serie advisorresponse es la respuesta en la que el asesor busca la respuesta HTTP. El asesor utiliza la serie advisorresponse y la compara con la respuesta real que se recibe del servidor. El valor predeterminado es null.

Importante: si la serie URL de HTTP incluye un espacio en blanco:

Cuando cree la solicitud que el asesor HTTP o HTTPS envía a los servidores de fondo para comprobar si están funcionando, escriba el comienzo de la solicitud HTTP y Load Balancer completará el final de la solicitud con lo siguiente:

\r\nAccept:
*/*\r\nUser-Agent:IBM_Load_Balanacer_HTTP_Advisor\r\n\r\n 

Si desea añadir otros campos de cabecera HTTP antes de que Load Balancer añada esta serie al final de la solicitud, puede hacerlo incluyendo su propia serie \r\n en la solicitud. A continuación se muestra un ejemplo de lo que podría escribir para añadir el campo de cabecera de host HTTP a la solicitud:

GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Nota:
Después de iniciar un asesor HTTP o HTTPS para un número de puerto HTTP especificado, se habilita el valor de solicitud y respuesta de asesor para los servidores bajo dicho puerto HTTP.

Consulte dscontrol server — configurar servidores para obtener más información.

Utilización de asesor automático en una configuración WAN de dos niveles

El asesor automático está disponible en el componente Dispatcher.

Para Load Balancer, en una configuración de WAN (red de área amplia) de dos niveles, Dispatcher proporciona un asesor automático que recopila información de estado de carga en servidores de programa de fondo.

Figura 31. Ejemplo de configuración WAN de dos niveles utilizando el asesor automático
Configuración WAN de dos niveles utilizando el asesor automático

En este ejemplo, el asesor automático junto con Metric Server reside en las dos máquinas Dispatcher cuya carga está siendo equilibrada por el Load Balancer de nivel superior. El asesor automático mide automáticamente el índice de conexiones por segundo en los servidores de programa de fondo de Dispatcher en el nivel del ejecutor.

El asesor automático escribe los resultados en el archivo dsloadstat. Load Balancer también proporciona una métrica externa denominada dsload. El agente de Metric Server de cada máquina Dispatcher ejecuta su configuración que llama al dsload de métrica externa. El script dsload extrae una serie del archivo dsloadstat y la devuelve al agente de Metric Server. Posteriormente, cada uno de los agentes de Metric Server (de cada uno de los Dispatcher) devuelve el valor de estado de carga al Load Balancer de nivel superior para utilizarlo al determinar a qué Dispatcher se deben reenviar las solicitudes de cliente.

El ejecutable dsload reside en el directorio siguiente:

Consulte el apartado Configurar soporte de Dispatcher de área amplia para más información sobre la utilización de Dispatcher en configuraciones WAN. Consulte Metric Server para obtener más información sobre Metric Server.

Crear asesores personalizados (personalizables)

El asesor personalizado (personalizable) es un trozo pequeño de código Java que se proporciona como archivo de clases y es llamado por el código base. El código base proporciona todos los servicios administrativos, como iniciar y detener una instancia del asesor personalizado, proporcionar estado e informes y anotar la información de historial en un archivo de anotaciones cronológicas. También notifica los resultados al componente del gestor. De forma periódica, el código base lleva a cabo un ciclo de asesor, donde evalúa de forma individual todos los servidores en su configuración. Empieza abriendo una conexión con una máquina servidor. Si se abre socket, el código base llamará al método "getLoad" (función) en el asesor personalizado. A continuación, el asesor personalizado llevará a cabo los pasos necesarios para evaluar el estado del servidor. En general, enviará al servidor un mensaje definido por el usuario y luego esperará una respuesta. (Se proporciona acceso al socket abierto para el asesor personalizado). A continuación, el código base cierra el socket con el servidor y notifica la información de carga al gestor.

El código base y el asesor personalizado puede funcionar en modalidad normal o de sustitución. La selección de la modalidad de operación se especifica en el archivo de asesor personalizado como parámetro en el método del constructor.

En modalidad normal, el asesor personalizado intercambia datos con el servidor y el código del asesor base calcula la duración del intercambio y calcula el valor de carga. A continuación, el código base informa de este valor de carga al gestor. El asesor personalizado sólo necesita devolver un cero (cuando es satisfactorio) o un valor negativo (cuando es erróneo). Para especificar la modalidad normal, el distintivo de sustitución en el constructor se establece en false.

En modalidad de sustitución, el código base no lleva a cabo las mediciones de tiempo. El código del asesor personalizado realiza todas las operaciones que desee para sus requisitos exclusivos y, a continuación, devuelve un número de carga real. El código base aceptará el número y lo notificará al gestor. Para obtener los mejores resultados, normalice el número de carga entre 10 y 1000, en donde 10 representa un servidor rápido y 1000 representa un servidor lento. Para especificar la modalidad de sustitución, el distintivo de sustitución en el constructor se establece en true.

Con esta característica, puede escribir sus propios asesores de forma que proporcionen la información exacta que necesite sobre los servidores. Con el producto Load Balancer se proporciona un asesor personalizado de ejemplo, ADV_sample.java.

Después de instalar Load Balancer, puede encontrar el código de ejemplo en:

Nota:
Si añade un asesor personalizado a Dispatcher o a cualquier otro componente de Load Balancer pertinente, debe detener y, a continuación, reiniciar dsserver (o el servicio en sistemas Windows) para que proceso Java pueda leer los nuevos archivos de clase de asesor personalizado. Los archivos de clase de asesor personalizado sólo se cargan durante el arranque. No es necesario detener el ejecutor. El ejecutor sigue en ejecución incluso cuando se ha detenido dsserver o el servicio.

Si el asesor personalizado hace referencia a clases Java adicionales, se debe actualizar la classpath en el archivo script de inicio de Load Balancer (dsserver, cbrserver, ssserver) de forma que incluya la ubicación.

Asesor WAS

Se proporcionan archivos de asesor personalizados de ejemplo específicamente para el asesor de WebSphere Application Server (WAS) en el directorio de instalación de Load Balancer.

Los archivos de ejemplo de asesor de WebSphere Application Server residen en el mismo directorio de ejemplos que el archivo ADV_sample.java.

Convenio de denominación

El nombre del archivo de asesor personalizado debe tener el formato "ADV_miasesor.java." Debe empezar con el prefijo " ADV_" en mayúsculas. Todos los caracteres subsiguientes deben indicarse en minúsculas.

Según los convenios Java, el nombre de la clase definida dentro del archivo debe coincidir con el nombre del archivo. Si copia el código de ejemplo, asegúrese de cambiar todas las instancias de "ADV_sample" dentro del archivo por el número nombre de clase.

Compilación

Los asesores personalizados se escriben en lenguaje Java. Utilice el compilador Java que se instala con Load Balancer. Durante la compilación aparecen referenciados los siguientes archivos:

La vía de acceso de clases debe apuntar al archivo de asesor personalizado y el archivo de clases base durante la compilación.

En sistemas Windows, un mandato de compilación de ejemplo es:

dir_instalación/java/bin/javac -classpath
    dir_instalación\lb\servers\lib\ibmlb.jar ADV_fred.java

donde:

La salida de la compilación está en un archivo de clases, por ejemplo:

ADV_fred.class

Antes de iniciar el asesor, copie el archivo de clases en el directorio siguiente:

Nota:
Si lo desea, los asesores personalizados pueden compilarse en un sistema operativo y ejecutarse en otro. Por ejemplo, puede compilar el asesor en sistemas Windows, copiar el archivo de clase (en binario) en una máquina AIX y ejecutar aquí el asesor personalizado.

En sistemas AIX, HP-UX, Linux y Solaris, la sintaxis es parecida.

Ejecución

Para ejecutar el asesor personalizado, primero debe copiar el archivo de clases en el directorio de instalación adecuado:

Configure el componente, inicie la función de gestor y emita el mandato para iniciar el asesor personalizado:

dscontrol advisor start fred 123

donde:

Si el asesor personalizado hace referencia a clases Java adicionales, se debe actualizar la classpath en el archivo script de inicio de Load Balancer (dsserver, cbrserver, ssserver) de forma que incluya la ubicación.

Rutinas necesarias

Como todos los asesores, un asesor personalizado amplía la función del asesor base, denominada ADV_Base. Se trata de la base del asesor que en realidad efectúa la mayoría de las funciones del asesor, como informar de las cargas al gestor para que se utilicen en el algoritmo de peso del gestor. La base del asesor también realiza operaciones de conexión y cierre de sockets, y proporciona métodos de envío y recepción para que el asesor los utilice. El asesor sólo se utiliza para enviar datos y recibir datos en el puerto del servidor que se está asesorando. Para calcular la carga, se calcula la duración de los métodos TCP incluidos en la base del asesor. Un distintivo incluido en el constructor en ADV_base escribe encima de la carga existente la nueva carga devuelta desde el asesor, si se desea.

Nota:
La base del asesor proporciona la carga al algoritmo de peso a intervalos especificados en función de un valor fijado en el constructor. Si el asesor real no se ha completado y no puede devolver una carga válida, la base del asesor utiliza la carga anterior.

A continuación se indican los métodos de clase base:

Orden de búsqueda

Load Balancer primero busca en la lista de los asesores nativos que proporciona. Si no encuentra un determinado asesor aquí, Load Balancer lo buscará en la lista de asesores personalizados del cliente.

Denominación y vía de acceso

Asesor de ejemplo

La lista de programas de un asesor de ejemplo se incluye en Asesor de ejemplo. Después de la instalación, este asesor de ejemplo puede encontrarse en el directorio siguiente:

Metric Server

Esta característica está disponible para todos los componentes de Load Balancer.

Metric Server proporciona información de carga de servidor a Load Balancer en forma de métrica específica del sistema, informando sobre el estado de los servidores. El gestor de Load Balancer consulta el agente de Metric Server que reside en cada uno de los servidores, asignando pesos al proceso de equilibrio de carga utilizando la métrica recopilada de los agentes. Los resultados también aparecen en el informe del gestor.

Nota:
Cuando se recopilan y normalizan dos o más métricas para cada servidor en un solo valor de carga del sistema, pueden producirse errores de redondeo.

Para obtener información sobre el funcionamiento de Metric Server (inicio y detención) y la utilización de las anotaciones cronológicas de Metric Server, consulte Utilización del componente Metric Server.

Para obtener un ejemplo de configuración, consulte la Figura 5.

Restricción para WLM

Igual que el asesor WLM, Metric Server informa sobre los sistemas de servidor en general, en lugar de hacerlo sobre daemons de servidor individuales específicos de protocolo. WLM y Metric Server ponen los resultados en la columna de sistema del informe de gestor. Como consecuencia, no se soporta la ejecución del asesor WLM y de Metric Server al mismo tiempo.

Requisitos previos

El agente de Metric Server debe estar instalado y en ejecución en todos los servidores en los que se está realizando el equilibrio de carga.

Cómo utilizar Metric Server

A continuación se muestran los pasos para configurar Metric Server para Dispatcher. Se pueden realizar pasos similares para configurar Metric Server para los demás componentes de Load Balancer.

Para que Metric Server se ejecute en una dirección distinta del host local, es necesario editar el archivo metricserver en la máquina servidor con equilibrio de carga. Después de la aparición de "java" en el archivo metricserver, inserte lo siguiente:

-Djava.rmi.server.hostname=OTRA_DIRECCIÓN

Además, antes de las sentencias "if" en el archivo metricserver, añada esta línea: hostname OTRA_DIRECCIÓN.

Para la plataforma Windows: También es necesario crear un alias de OTRA_DIRECCIÓN en la pila de Microsoft de la máquina de Metric Server. Por ejemplo:

call netsh interface ip add address "Conexión de área local"
  addr=9.37.51.28 mask=255.255.240.0

Al recopilar métricas por distintos dominios, debe establecer de forma explícita java.rmi.server.hostname en el script del servidor (dsserver, cbrserver, etc) con el nombre de dominio completo (FQDN) de la máquina que solicita la métrica. Esto es necesario porque, en función de la configuración y del sistema operativo que utilice, es posible que InetAddress.getLocalHost.getHostName() no devuelva el nombre de dominio completo (FQDN).

Asesor de Workload Manager

WLM es código que se ejecuta en sistemas principales MVS. Se le puede consultar para conocer la carga en la máquina MVS.

Cuando se ha configurado la gestión de carga de trabajo de MVS en el sistema OS/390, Dispatcher puede aceptar información de capacidad de WLM y utilizarla en el proceso de equilibrio de carga. Con el asesor WLM, Dispatcher abre de forma periódica las conexiones a través del puerto de WLM en cada servidor de la tabla de hosts de Dispatcher y aceptar los enteros de capacidad devueltos. Puesto que estos enteros representan la cantidad de capacidad que todavía está disponible y Dispatcher espera valores que representan las cargas en cada máquina, el asesor invierte los enteros de capacidad y se sistematizan en valores de carga (es decir, un entero de gran capacidad y un valor de carga pequeño representan un servidor eficaz. Las cargas resultantes se colocan en la columna de sistema del informe del gestor.

Hay varias diferencias importantes entre el asesor WLM y los demás asesores de Dispatcher.

  1. Otros asesores abren conexiones para los servidores utilizando el mismo puerto en el que circula el tráfico de cliente normal. El asesor WLM abre conexiones para los servidores utilizando un puerto distinto del que utiliza el tráfico normal. El agente de WLM en cada máquina servidor debe configurarse de modo que escuche en el mismo puerto en el que se inicia el asesor WLM de Dispatcher. El puerto predeterminado de WLM es 10007.
  2. Otros asesores sólo evalúan a los servidores definidos en la configuración clúster:puerto:servidor de Dispatcher para la que el puerto del servidor coincide con el puerto del asesor. El asesor WLM informa sobre cada servidor de la configuración de Dispatcher (independientemente del clúster:puerto). Por lo tanto, no puede definir ningún servidor que no sea WLM cuando utiliza el asesor WLM.
  3. Otros asesores ponen la información de carga en el informe de gestor bajo la columna "Puerto". El asesor WLM pone su información de carga en el informe del gestor bajo la columna del sistema.
  4. Junto con el asesor WLM es posible utilizar los dos asesores específicos del protocolo. Los asesores específicos de protocolo sondearán los servidores en sus puertos de tráfico normal y el asesor WLM sondeará la carga del sistema utilizando el puerto WLM.

Restricción para Metric Server

Igual que el agente de Metric Server, el agente de WLM informa sobre los sistemas de servidor en general, en lugar de hacerlo sobre daemons de servidor individuales específicos del protocolo. Metric Server y WLM colocan los resultados en la columna de sistema del informe de gestor. Como consecuencia, no se soporta la ejecución del asesor WLM y de Metric Server al mismo tiempo.