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. Piense en los asesores como clientes ligeros de los servidores de aplicaciones.
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 petición 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 calculan 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 la carga a la función de consultor donde aparece en el informe del consultor. Luego, el consultor calcula los valores de peso total de todas las fuentes, según sus proporciones y envía estos valores del peso al conmutador. El conmutador utiliza 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, notifica al consultor un número de carga positivo distinto de cero. Si el asesor determina que un servidor no está activo, devuelve el valor de carga especial uno negativo (-1) para notificar al conmutador que el servidor está inactivo. Posteriormente, el conmutador no enviará más conexiones a dicho servidor hasta que el servidor no vuelva a estar en funcionamiento.
El tiempo de inactividad 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 consultor. Si el valor de tiempo de inactividad del asesor es demasiado bajo, puede dar como resultado un bajo rendimiento porque el asesor interrumpe constantemente a los servidores. Si el valor de tiempo de inactividad del asesor es demasiado alto, puede significar que la ponderación de decisiones del consultor no se basa en información actualizada y precisa.
Por ejemplo, para establecer el intervalo en 3 segundos para el asesor HTTP, escriba el siguiente mandato:
xxxcontrol metriccollector set ID_consultor:HTTP sleeptime 3
Puede establecer la cantidad de tiempo que un asesor tarda en detectar que un puerto concreto del servidor o 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 en el valor más pequeño (un segundo) y establezca el tiempo de inactividad del consultor y asesor en el valor más pequeño (un segundo).
Para establecer timeoutconnect en 9 segundos para el asesor HTTP, escriba el siguiente mandato:
xxxcontrol metriccollector set ID_consultor:HTTP timeoutconnect 9
El valor por omisión para el tiempo de espera de conexión y recepción es 3 veces el valor especificado para el tiempo de inactividad 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. Si no se establece, el valor de reintento toma el valor por omisión que es cero.
En Cisco CSS Controller, especifique el valor retry utilizando el mandato ccocontrol ownercontent set. Para obtener más información, consulte el apartado ccocontrol ownercontent — controlar el nombre de propietario y la norma de contenido.
En Nortel Alteon Controller, especifique el valor retry utilizando el mandato nalcontrol service set. Para obtener más información, consulte el apartado nalcontrol service — configurar un servicio.