Este capítulo incluye los apartados siguientes:
Controlador Cisco CSS o Controlador Nortel Alteon puede residir en la misma máquina como servidor para el que se está equilibrando la carga de peticiones. Esto se conoce habitualmente como ubicación compartida de un servidor. No es necesario llevar a cabo más pasos de configuración.
La característica de alta disponibilidad está ahora disponible para Controlador Cisco CSS y Controlador Nortel Alteon.
Para mejorar la tolerancia de errores del controlador, la función de alta disponibilidad contiene estas funciones:
Consulte los apartados ccocontrol highavailability — controlar alta disponibilidad y nalcontrol highavailability — controlar alta disponibilidad para obtener la sintaxis completa para xxxcontrol highavailability.
Para configurar la alta disponibilidad del controlador:
xxxcontrol highavailability add address 10.10.10.10 partneraddress 10.10.10.20 port 143 role primary
xxxcontrol highavailability add address 10.10.10.20 partneraddress 10.10.10.10 port 143 role secondaryLos parámetros address y partneraddress se invierten en las máquinas primaria y secundaria.
xxxcontrol highavailability set beatinterval 1000
xxxcontrol highavailability usereach 10.20.20.20Debe configurarse el mismo número de destinos de alcance en los controladores local y asociado.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeoverEsto sólo es necesario para realizar el mantenimiento.
Además de la pérdida de conectividad entre controladores activos y en espera, que se detecta a través de los mensajes de pulsos, accesibilidad proporciona otro mecanismo de detección de anomalías.
Al configurar la alta disponibilidad del controlador, puede proporcionar una lista de los sistemas principales a los que deben acceder los controladores para funcionar correctamente. Debe haber cómo mínimo un sistema principal para cada subred que utiliza la máquina del controlador. Estos sistemas principales pueden ser direccionadores, servidores IP o otros tipos de sistemas principales.
La accesibilidad de sistemas principales se obtiene mediante el asesor de alcance que emite el mandato ping al sistema principal. Tiene lugar la conmutación si los mensajes de pulso no pueden transmitirse o si los criterios de accesibilidad los satisface mejor el controlador en espera que el controlador activo. Para tomar esta decisión basándose en toda la información disponible, el controlador activo envía regularmente al controlador en espera su capacidad de accesibilidad y viceversa. Los controladores comparan su información de accesibilidad con la información de su socio y deciden quién debe estar activo.
Los roles de las dos máquinas de controlador se configurar como primario y secundario. Durante el arranque, los controladores intercambian información hasta que se sincroniza cada máquina. En este punto, el controlador primario pasa al estado activo y empieza a calcular pesos y a actualizar el conmutador, mientras que la máquina secundaria pasa a estado de espera y supervisa la disponibilidad de la máquina primaria.
Si en cualquier momento la máquina en espera detecta que la máquina activa ha sufrido una anomalía, la máquina en espera asumirá el control de las funciones de equilibrio de carga de la máquina activa (anómala) y pasará a ser la máquina activa. Cuando la máquina primaria vuelve a estar operativa, las dos máquinas determinan qué controlador estará activo según cómo se haya configurado la estrategia de recuperación.
Hay dos tipos de estrategia de recuperación:
El controlador primario pasa al estado activo y empieza a calcular y actualizar pesos tan pronto vuelve a estar operativo. La máquina secundaria pasa al estado en espera una vez que la máquina primaria está activa.
El controlador secundario activo permanece en estado activo, incluso después de que el controlador primario sea operativo.
El controlador primario pasa al estado en espera y requiere intervención manual para pasar al estado activo.
El parámetro strategy debe tener el mismo valor en ambas máquinas.
Para obtener ejemplos de configuración de alta disponibilidad de Controlador Cisco CSS, consulte el apartado Ejemplos.
Para obtener ejemplos de configuración de alta disponibilidad de Controlador Nortel Alteon, consulte el apartado Ejemplos.
La función de controlador de Load Balancer lleva a cabo 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.
El controlador puede utilizar algunos de los siguientes recopiladores de métricas o todos cuando se sopesan las decisiones:
La métrica por omisión es activeconn y connrate.
Puede cambiar la proporción de importancia relativa de los valores de métrica. Piense en las proporciones como si fueran porcentajes; la suma de las proporciones relativas debe ser 100%. Por omisión, se utilizan las conexiones activas y la nueva métrica de conexiones y sus proporciones se fijan en 50/50. Es posible que sea necesario probar distintas combinaciones de proporciones de métrica en su entorno hasta encontrar la combinación que ofrezca el mejor rendimiento.
Para establecer los valores de proporción:
Los pesos se establecen en función del tiempo de respuesta de la aplicación, información procedente de los asesores e información procedente de un programa de supervisión del sistema, como Metric Server. Si desea establecer pasos manualmente, especifique la opción fixedweight para el servidor. Para obtener una descripción de la opción fixedweight, consulte el apartado Pesos fijos de controlador.
Los pesos se aplican a todos los servidores que proporcionan un servicio. Para cualquier servicio concreto, las peticiones se distribuyen entre servidores en función del peso 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 peticiones que el servidor establecido en 5.
Si un asesor encuentra que un servidor ha concluido, el peso para el servidor se establece en -1. En Controlador Cisco CSS y Controlador Nortel Alteon, se informa al conmutador que el servidor no está disponible y el conmutador deja de asignar conexiones al servidor.
Sin el controlador, 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 controlador actualice el peso establecido para un servidor concreto, utilice la opción fixedweight en el mandato ccocontrol service en Controlador Cisco CSS o el mandato nalcontrol server en Controlador Nortel Alteon.
Utilice el mandato fixedweight para establecer el peso en el valor que desee. El valor de peso del servidor permanece fijo mientras el controlador se está ejecutando hasta que se emite otro mandato con la opción fixedweight establecida en no.
Para optimizar el rendimiento general, puede restringir la frecuencia con la que se recopila la métrica.
El tiempo de inactividad del consultor especifica la frecuencia con la que el consultor actualiza los pesos del servidor. Si el valor de tiempo de inactividad del consultor es demasiado bajo, puede suponer un bajo rendimiento como resultado de que el consultor interrumpe constantemente al conmutador. Si el valor de tiempo de inactividad del consultor es demasiado alto, puede significar que el equilibrio de carga del conmutador no se basará en información actualizada y precisa.
Por ejemplo, para establecer el tiempo de inactividad del consultor en 1 segundo:
xxxcontrol consultant set ID_consultor sleeptime intervalo
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 en el porcentaje del peso para el peso total de todos los servidores que proporcionan un servicio es mayor que el umbral de sensibilidad, se actualizan los pesos utilizados por Load Balancer 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 por omisión 5, los pesos utilizados por Load Balancer no se actualizan, porque el cambio del porcentaje no está por encima del umbral. Sin embargo, si el peso total pasa de 100 a 106, los pesos se actualizan. Para establecer el umbral de sensibilidad del consultor en un valor distinto del valor por omisión, escriba el siguiente mandato:
xxxcontrol consultant set ID_consultor sensitivity cambio_porcentaje
En la mayoría de los casos, no es necesario cambiar este valor.
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 petición 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.
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:
También notifica los resultados al consultor. 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 el socket, el código base llama 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, envía al servidor un mensaje definido por el usuario y luego espera 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 consultor.
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 consultor. 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 consultor. 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. Se proporciona un asesor personalizado de ejemplo para los controladores, ADV_ctlrsample.java. Después de instalar Load Balancer, puede encontrar el código de ejemplo en:
El nombre de 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_ctrlsample dentro del archivo por el nuevo nombre de clase.
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 classpath debe apuntar al archivo de asesor personalizado y el archivo de clases base durante la compilación.
En la plataforma Windows, un mandato de compilación puede se parecido al siguiente:
dir_instalación/java/bin/javac -classpath <raíz_instalación>ibm\edge\lb\servers\lib\ibmlb.jar ADV_pam.java
donde:
La salida de la compilación está en un archivo de clases; por ejemplo:
ADV_pam.class
Antes de iniciar el asesor, copie el archivo de clases en el directorio siguiente:
En sistemas AIX, HP-UX, Linux y Solaris, la sintaxis es parecida.
Para ejecutar el asesor personalizado, primero debe copiar el archivo de clases en el directorio de instalación adecuado:
Inicie el consultor y luego emita este mandato para iniciar el asesor personalizado:
donde:
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 consultor para que se utilicen en el algoritmo de peso del consultor. 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.
A continuación se indican los métodos de clase base:
En primer lugar, los controladores examinan la lista de asesores nativos que se proporciona; si no encuentran un asesor específico en la lista, consultarán la lista de asesores personalizados.
La lista de programas de un asesor de ejemplo del controlador se incluye en Asesor de ejemplo. Después de la instalación, este asesor de ejemplo puede encontrarse en el directorio siguiente:
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 consultor de Load Balancer consulta el agente de Metric Server que residen en cada uno de los servidores, asignado pesos al proceso de equilibrio de carga utilizando la métrica recopilada desde los agentes. Los resultados también aparecen en el informe de servicio de Controlador Cisco CSS o en el informe de servidor de Controlador Nortel Alteon.
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.
A continuación se muestran los pasos para configurar Metric Server para los controladores.
En Controlador Nortel Alteon, añada un consultor de conmutador y añada un servicio.
donde nombre_métrica es el nombre del script de Metric Server.
El script de métrica del sistema reside en el servidor de programa de fondo y se ejecuta en cada uno de los servidores que se encuentran en la configuración bajo el servicio o contenido de propietario especificado. Se proporcionan dos scripts, cpuload y memload o puede crear scripts de métrica de sistema personalizados. El script contiene un mandato que debe devolver un valor numérico. Esta valor numérico representa una medida de carga, no un valor de disponibilidad.
Limitación: en sistemas Windows, si la extensión del nombre del script de métrica del sistema es distinta de .exe, debe especificar el nombre completo del archivo; por ejemplo, miScriptSistema.bat. Se trata de una limitación del código Java.
De manera opcional, puede escribir sus propios archivos de script de métrica personalizados que definan el mandato que Metric Server emitirá en las máquinas de servidor. Asegúrese de que todos los scripts personalizados son ejecutables y se encuentran en el directorio siguiente:
Para que Metric Server se ejecute en una dirección distinta del sistema principal local, edite el archivo metricserver en la máquina servidor con equilibrio de carga. En el archivo metricserver, inserte lo siguiente después de java:
-Djava.rmi.server.hostname=OTRA_DIRECCIÓN
Además, añada hostname OTRA_DIRECCIÓN antes de las sentencias "if" en el archivo metricserver.
En sistemas Windows: cree un alias de OTRA_DIRECCIÓN en la pila de Microsoft. Para crear un alias de una dirección en la pila de Microsoft, consulte la sección sobre cómo crear un alias de una dirección en la pila de Microsoft para un servidor de métrica.
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, los controladores pueden aceptar información de capacidad de WLM y utilizarla en el proceso de carga del sistema. Con el asesor WLM, los controladores abren de forma periódica las conexiones a través del puerto de WLM en cada servidor de la tabla de sistema principal de consultor y aceptar los enteros de capacidad devueltos. Puesto que estos enteros representan la cantidad de capacidad que todavía está disponible y los consultores esperan valores que representan las cargas en cada máquina, el asesor invierte los enteros de capacidad y se sistematizan en valores de carga (por ejemplo, un entero de gran capacidad y un valor de carga pequeño representan un servidor eficaz. Hay varias diferencias importantes entre el asesor WLM y los demás asesores de controlador.
La característica de registro cronológico en binario permite que la información de servidor se almacene en archivos binarios. Estos archivos pueden procesarse para analizar la información de servidor que se ha recopilado con el tiempo.
La siguiente información se ha almacenado en las anotaciones cronológicas en binario para cada servidor definido en la configuración.
El consultor debe estar en ejecución para anotar información en las anotaciones cronológicas en binario.
Utilice el conjunto de mandatos xxxcontrol consultant binarylog para configurar el registro cronológico en binario.
La opción start inicia el registro cronológico de la información de servidor en anotaciones cronológicas en binario en el directorio logs. Al inicio de cada hora se crea un archivo con la fecha y la hora como el nombre del archivo.
La opción stop detiene el registro cronológico de la información de servidor en las anotaciones cronológicas en binario. De manera predeterminada, el servicio de anotaciones cronológicas está detenido.
La opción set interval controla la frecuencia con la que información se escribe en las anotaciones cronológicas. Cada intervalo del consultor, éste enviará información de servidor al servidor de anotaciones cronológicas. La información se graba en las anotaciones cronológicas sólo cuando hayan transcurrido los segundos especificados en el intervalo de anotaciones cronológicas después de anotarse el último registro en las anotaciones cronológicas. De manera predeterminada, el intervalo de anotaciones cronológicas se establece en 60 segundos.
Los valores del intervalo del consultor y el intervalo de anotaciones cronológicas están relacionados. Puesto que al servidor de anotaciones cronológicas se le proporciona información cómo máximo a la velocidad indicada por los segundos del intervalo del consultor, si se establece el intervalo de anotaciones cronológicas en un valor inferior al valor del intervalo del consultor en realidad se establece en el mismo valor que el intervalo del consultor.
Esta técnica de registro cronológico permite captar información de servidor en cualquier granularidad. Puede captar todos los cambios realizados en la información del servidor detectados por el consultor para calcular pesos de servidor; sin embargo, es probable que esta cantidad de información no sea necesaria para analizar las tendencias y el uso del servidor. Si se registra información del servidor cada 60 segundos, con el tiempo dispondrá de instantáneas de información del servidor. Si establece el intervalo de anotaciones cronológicas muy bajo puede generar enormes cantidades de datos.
La opción set retention controla cuánto tiempo se mantienen los archivos. El servidor de anotaciones cronológicas elimina los archivos de anotaciones cronológicas anteriores a las horas de retención especificadas. Esto sólo sucede si el consultor llama al servidor de anotaciones cronológicas, ya que si se detiene el consultor, no se suprimirán los archivos de anotaciones cronológicas antiguos.
Se proporciona un programa y un archivo de mandatos Java en el directorio siguiente:
Este ejemplo muestra cómo recuperar toda la información de los archivos de anotaciones cronológicas e imprimirla en la pantalla. Puede personalizar realizar cualquier tipo de análisis que desea con los datos.
A continuación se proporciona un ejemplo de la utilización del programa y script suministrados:
xxxlogreport 2002/05/01 8:00 2002/05/01 17:00
Esto genera un informe de la información de servidor del controlador para el día 1 de mayo de 2002, de las 8:00 a las 17:00.
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 se marca 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, cópielos en el directorio siguiente y cambie el nombre de cada archivo según las indicaciones del script:
Se proporcionan los siguientes scripts de ejemplo, donde xxx es cco para Controlador Cisco CSS y nal para Controlador Nortel Alteon: