Versión 7.0
Nota |
---|
Antes de utilizar esta información y el producto al que da soporte, asegúrese de leer la información general del Apéndice E, Avisos. |
Primera edición (junio 2008)
Esta edición se aplica a:
y a todos los releases y modificaciones posteriores hasta que se indique lo contrario en nuevas ediciones.
Puede solicitar publicaciones a través del representante de IBM o a través de la sucursal de IBM que presta servicio en su localidad.
(C) Copyright International Business Machines Corporation 2008. Reservados todos
los derechos.
Derechos Restringidos para los Usuarios del Gobierno de los EE.UU.: el uso,
la duplicación y la divulgación están limitados de acuerdo con el contrato GSA ADP Schedule Contract con IBM Corporation.
Componente CBR (Content Based Routing)
Componente Cisco CSS Controller
Componente Nortel Alteon Controller
Funciones y características avanzadas de Load Balancer
Administración y resolución de problemas de Load Balancer
En este manual se describe cómo planificar la instalación, configuración, utilización y la resolución de problemas del Load Balancer de IBM(R) WebSphere(R) Application Server para sistemas operativos AIX(R), HP-UX, Linux(TM), Solaris y Windows(R). Anteriormente, este producto se llamaba Edge Server Network Dispatcher, SecureWay(R) Network Dispatcher, eNetwork Dispatcher e Interactive Network Dispatcher.
El manual Guía de administración de Load Balancer se ha escrito para aquellos administradores de red y de sistemas expertos que estén familiarizados con sus sistemas operativos y con el suministro de servicios de Internet. No es necesario tener conocimientos previos de Load Balancer.
Este manual no está concebido para dar soporte a varios releases de Load Balancer.
El sitio Web del Information Center de Edge Components tiene un enlace a la versión actual de este manual en formatos HTML y PDF.
Para obtener las actualizaciones más recientes sobre Load Balancer, visite la página de soporte del sitio Web y pulse el enlace correspondiente al sitio de notas técnicas.
Para acceder a estas páginas Web y las páginas relacionadas, vaya a las direcciones URL enumeradas en Documentos relacionados y sitios web.
Las características de accesibilidad ayudan al usuario que tiene discapacidades físicas, como por ejemplo una movilidad restringida o una visión limitada, a utilizar satisfactoriamente los productos de software. Éstas son las principales características de accesibilidad en Load Balancer:
Sus comentarios son importantes para ayudarnos a proporcionar la información más precisa y de la mayor calidad posible. Para enviar comentarios sobre este manual o sobre cualquier otro documento de Edge Components:
En esta parte se proporciona una visión general de Load Balancer y sus componentes, una descripción de alto nivel de características de configuración que están disponibles, una lista de requisitos de hardware y software e instrucciones de instalación. Contiene los capítulos siguientes:
En este capítulo se ofrece una visión general de Load Balancer y se incluyen los siguientes apartados:
Si desea una lista de alto nivel de las características de configuración proporcionadas por cada uno de los componentes de Load Balancer que le ayudará a planificar qué características utilizar para gestionar la red, consulte el apartado Gestión de la red: determinación de las características de Load Balancer que se van a utilizar.
Load Balancer es una solución de software para distribuir peticiones de cliente entrantes entre servidores. Esta solución aumenta el rendimiento de los servidores dirigiendo las peticiones de la sesión TCP/IP a servidores distintos dentro de un grupo de servidores; de este modo, se equilibran las peticiones entre todos los servidores. Este equilibrio de carga es transparente a los usuarios y otras aplicaciones. Load Balancer resulta de utilidad para aplicaciones como servidores de correo electrónico, servidores de la World Wide Web, consultas de base de datos paralelo distribuidas y otras aplicaciones TCP/IP.
Cuando se utiliza Load Balancer con servidores Web, puede ayudar a maximizar el potencial de su sitio proporcionando una solución completa, flexible y escalable a problemas de intensa demanda. Si los visitantes de su sitio no pueden comunicar en los momentos de mayor demanda, utilice Load Balancer para encontrar automáticamente el servidor óptimo para gestionar las peticiones entrantes, así mejorará la satisfacción de los clientes y la rentabilidad.
Load Balancer consta de los cinco componentes siguientes que se pueden utilizar ya sea por separado o juntos para proporcionar resultados de equilibrio de carga superiores:
Para el protocolo HTTP, también puede utilizar el dispositivo Dispatcher para equilibrar la carga según el contenido de la petición del cliente. El servidor elegido es el resultado de comparar el URL con una regla especificada. El direccionamiento basado en contenido (método de reenvío cbr) del Dispatcher no requiere Caching Proxy.
Si desea más información sobre los componentes Dispatcher, CBR, Site Selector, Cisco CSS Controller y Nortel Alteon Controller, consulte el apartado Componentes de Load Balancer.
El número de usuarios y redes conectado a Internet global aumenta exponencialmente. Este aumento produce problemas de escalabilidad que pueden limitar el acceso de los usuarios a los sitios conocidos.
Actualmente, los administradores de redes utilizan varios métodos para intentar maximizar el acceso. Con algunos de estos métodos, puede elegir de modo aleatorio un usuario distinto si una selección anterior es lenta o no responde. Este enfoque es engorroso, pesado e ineficaz. Otro método es el algoritmo de turno rotativo estándar, en el que el servidor de nombres de dominio selecciona servidores por turno para gestionar las peticiones. Este enfoque es mejor, pero sigue siendo ineficaz porque envía tráfico sin tener en cuenta la carga de trabajo del servidor. Además, aún cuando el servidor dé un error, se le seguirán enviando las peticiones.
La necesidad de una solución más completa ha dado como resultado Load Balancer. Esta solución ofrece muchas ventajas sobre las soluciones anteriores y de la competencia:
A medida que aumenta el número de peticiones de cliente, puede añadir servidores dinámicamente, proporcionando soporte para decenas de millones de peticiones al día, en decenas o incluso centenas de servidores.
El equilibrio de carga asegura que cada grupo de servidores hace un uso óptimo del hardware minimizando los puntos conflictivos que suelen aparecer con un método de turno rotativo estándar.
Load Balancer utiliza protocolos TCP/IP o UDP/IP estándar. Puede añadirlo a la red existente sin realizar ningún cambio físico en la red. Es sencillo de instalar y configurar.
Con el método sencillo de reenvío de nivel mac, el componente Dispatcher sólo presta atención a los flujos de cliente a servidor de entrada. No tiene que comprobar los flujos de salida del servidor al cliente. Esto reduce significativamente el impacto en la aplicación comparado con otros enfoques y puede producir un rendimiento de red mejorado.
Los componentes Dispatcher, Cisco CSS Controller y Nortel Alteon Controller ofrecen una alta disponibilidad integrada, utilizando una máquina de reserva que permanece preparada en todo momento para hacerse con el control del equilibrio de carga en caso de que la máquina servidor primaria dé un error. Cuando uno de los servidores da un error, el otro servidor sigue atendiendo las peticiones. Este proceso impide que haya un servidor como único punto de error y hace que el sitio esté altamente disponible.
Para obtener más información, consulte el apartado Cómo Load Balancer puede proporcionar alta disponibilidad
Junto con Caching Proxy, el componente CBR tiene la capacidad de dirigir mediante proxy peticiones HTTP y HTTPS (SSL) a servidores específicos según el contenido solicitado. Por ejemplo, si una petición contiene la serie "/cgi-bin/" en la parte del directorio de la dirección URL y el nombre de servidor es un servidor local, CBR puede dirigir la petición al mejor servidor de un conjunto de servidores específicamente asignados para gestionar peticiones cgi.
El componente Dispatcher también proporciona direccionamiento basado en contenido, pero no requiere tener instalado Caching Proxy. Dado que el direccionamiento basado en contenido del componente Dispatcher se realiza en el kernel a medida que se reciben los paquetes, puede proporcionar un direccionamiento basado en contenido más rápido que el componente CBR. El componente Dispatcher realiza un direccionamiento basado en contenido para HTTP (con la regla de tipo de "contenido") y HTTPS (con afinidad de ID de sesión SSL).
El componente Dispatcher ofrece una característica de alta disponibilidad integrada, que evita que el Dispatcher sea un único punto de error de la red. Esta característica implica el uso de una segunda máquina Dispatcher que supervisa la máquina principal o, primaria, y está preparada para hacerse con el control del equilibrio de carga en caso de que la máquina primaria dé un error en un momento dado. El componente Dispatcher también ofrece alta disponibilidad mutua que permite que dos máquinas sean a la vez primaria y secundaria (de reserva) entre sí. Consulte el apartado Configurar la alta disponibilidad.
También puede alcanzar un nivel de alta disponibilidad utilizando el componente de CBR cuando se utiliza una configuración de dos niveles con una máquina de Dispatcher que equilibra la carga entre varios servidores que tienen el componente CBR.
Los controladores tienen una característica de alta disponibilidad para impedir que el controlador sea un único punto de error. Se puede configurar un controlador como primario en una máquina y un controlador de reserva en otra máquina. El de reserva supervisa el primario y está preparado para hacerse con el control de la tarea de proporcionar pesos de servidor a los conmutadores en caso de que el primario dé un error. Consulte el apartado Alta disponibilidad para obtener más información.
En este capítulo se ofrece una visión general de los componentes de Load Balancer y se incluyen los siguientes apartados:
Si desea una lista de alto nivel de las características de configuración proporcionadas por cada uno de los componentes de Load Balancer para ayudarle a planificar qué características utilizar para gestionar la red, consulte el apartado Gestión de la red: determinación de las características de Load Balancer que se van a utilizar.
Los cinco componentes de Load Balancer son: Dispatcher, Content Based Routing (CBR), Site Selector, Cisco CSS Controller y Nortel Alteon Controller. Load Balancer le ofrece la flexibilidad de utilizar los componentes por separado o juntos en función de la configuración del sitio. En este apartado se proporciona una visión general de estos componentes.
El componente Dispatcher equilibra el tráfico entre servidores a través de una combinación exclusiva de software de equilibrio de carga y gestión. Dispatcher también puede detectar un servidor con anomalías y reenviar el tráfico sin pasar por el mismo. Dispatcher da soporte a HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP y a cualquier otra aplicación basada en UDP sin estado o TCP.
Todas las peticiones de cliente enviadas a una máquina de Dispatcher se dirigen al servidor "más idóneo" en función de los pesos que se establecen de forma dinámica. Puede utilizar los valores predeterminados de dichos pesos o cambiar los valores durante el proceso de configuración.
Dispatcher ofrece tres métodos de envío (que se especifican en el puerto):
El componente Dispatcher es la clave que permite la gestión estable y eficaz de una red de servidores grande y escalable. Con Dispatcher, puede enlazar muchos servidores individuales en lo que parecerá ser un único servidor virtual. Así, su sitio se presenta como una sola dirección IP ante los demás. Dispatcher funciona independientemente de un servidor de nombres de dominio; todas las peticiones se envían a la dirección IP de la máquina Dispatcher.
Dispatcher proporciona distintas ventajas al equilibrar la carga de tráfico para servidores agrupados en clúster, resultando en una gestión estable y eficaz del sitio.
En la Figura 1 se muestra una representación física del sitio utilizando una configuración de red Ethernet. La máquina Dispatcher puede instalarse sin realizar ningún cambio físico en la red. Cuando se utiliza el método de reenvío MAC, una vez que Dispatcher ha dirigido una petición de cliente al servidor óptimo, la respuesta se envía directamente del servidor al cliente sin la participación de Dispatcher.
Figura 2. Ejemplo de un sitio que utiliza Dispatcher y Metric Server para gestionar servidores
En la Figura 2 se muestra un sitio en el que todos los servidores están en una red local. El componente Dispatcher se utiliza para reenviar peticiones y Metric Server se utiliza para proporcionar información de carga del sistema a la máquina Dispatcher.
En este ejemplo, el daemon de Metric Server está instalado en cada servidor de programa de fondo. Puede utilizar Metric Server con el componente Dispatcher o cualquier otro componente de Load Balancer.
Figura 3. Ejemplo de un sitio que utiliza Dispatcher para gestionar servidores locales y remotos
El soporte de área amplia en Dispatcher permite utilizar los servidores locales y remotos (servidores en distintas subredes). En la Figura 3 se muestra una configuración en la que un sistema Dispatcher local (Dispatcher 1) sirve de punto de entrada para todas las peticiones. Distribuye estas peticiones entre sus propios servidores locales (ServidorA, ServidorB, ServidorC) y el sistema Dispatcher remoto (Dispatcher 2), que equilibrará la carga de sus servidores locales (ServidorG, ServidorH, ServidorI).
Al utilizar el método de reenvío NAT de Dispatcher o al utilizar el soporte de GRE, el soporte de área amplia con Dispatcher también puede lograrse sin utilizar una máquina Dispatcher en el sitio remoto (donde están ServidorD, ServidorE y ServidorF). Consulte los apartados NAT/NAPT de Dispatcher (método de reenvío nat) y Soporte de GRE (Encapsulamiento genérico de direccionamiento) para obtener más información.
CBR funciona con Caching Proxy para enviar mediante proxy las peticiones de cliente a los servidores HTTP o HTTPS (SSL) especificados. Permite manipular detalles de almacenamiento en caché a fin de conseguir una recuperación de documentos Web más rápida con menos requisitos de ancho de banda de red. CBR y Caching Proxy examina las peticiones HTTP utilizando tipos de reglas especificadas.
CBR le ofrece la capacidad de especificar un conjunto de servidores que manejan una petición basándose en una expresión normal que coincide con el contenido de la petición. Dado que CBR permite especificar varios servidores para cada tipo de petición, se puede equilibrar la carga de los servidores para obtener una respuesta al cliente óptima. CBR también detecta cuando un servidor incluido en un conjunto ha sufrido una anomalía y deja de direccionar peticiones a dicho servidor. El algoritmo de equilibrio de carga que el componente CBR utiliza es idéntico al algoritmo probado que utiliza el componente Dispatcher.
Cuando Caching Proxy recibe una petición, ésta se compara con las reglas definidas en el componente CBR. Si se encuentra una coincidencia, se elige uno de los servidores asociados a dicha regla para manejar la petición. Caching Proxy realiza su proceso normal para enviar mediante proxy la petición al servidor elegido.
CBR tiene las mismas funciones que Dispatcher, a excepción de la alta disponibilidad, el subagente SNMP, el área amplia y unos pocos mandatos de configuración.
Caching Proxy debe estar en ejecución para que CBR pueda empezar a equilibrar la carga de peticiones de cliente.
Figura 4. Ejemplo de un sitio que utiliza CBR para gestionar servidores locales
En la Figura 4 se muestra una representación lógica de un sitio en el que se emplea CBR para enviar mediante proxy algún contenido de servidores locales. El componente CBR utiliza Caching Proxy para enviar peticiones de cliente (HTTP o HTTPS) a los servidores basándose en el contenido del URL.
Site Selector actúa como servidor de nombres que funciona junto con otros servidores de nombres en un sistema de nombres de dominio para equilibrar la carga entre un grupo de servidores utilizando las medidas y los pesos que se recopilan. Puede crear una configuración del sitio que le permita equilibrar la carga del tráfico entre un grupo de servidores basándose en el nombre de dominio utilizado para la petición de un cliente.
Un cliente somete una petición para la resolución de un nombre de dominio a un servidor de nombres dentro de su red. El servidor de nombres reenvía la petición al sistema Site Selector. Site Selector luego soluciona el nombre de dominio con la dirección IP de uno de los servidores que se han configurado bajo el nombre de sitio. Site Selector devuelve la dirección IP del servidor seleccionado al servidor de nombres. El servidor de nombres devuelve la dirección IP al cliente.
Metric Server es un componente de supervisión del sistema de Load Balancer que debe instalarse en cada servidor con equilibrio de carga incluido en la configuración. Con Metric Server, Site Selector puede supervisar el nivel de actividad de un servidor, detectar si un servidor tiene la carga menos pesada y detectar un servidor anómalo. La carga es una medición del esfuerzo del servidor. Si personaliza los archivos de script de métrica del sistema, puede controlar el tipo de medidas utilizadas para medir la carga. Puede configurar Site Selector de modo que se adapte a su entorno, teniendo en cuenta factores como la frecuencia de acceso, el número total de usuarios y los tipos de acceso (por ejemplo, consultas breves, consultas de larga ejecución o cargas con mucha utilización de la CPU).
En la Figura 5 se muestra un sitio en el que se utiliza el componente Site Selector para responder a peticiones. Servidor1, Servidor2 y Servidor3 son locales. Servidor4, Servidor5 y Servidor6 son remotos.
Un cliente somete una petición para la resolución de un nombre de dominio a un servidor de nombres de cliente. El servidor de servidor de nombres reenvía la petición a través del DNS a la máquina Site Selector (ruta 1). A continuación, Site Selector resuelve el nombre de dominio en una dirección IP de uno de los servidores. Site Selector devuelve la dirección IP del servidor seleccionado al servidor de nombres de cliente. El servidor de nombres devuelve la dirección IP al cliente.
Una vez que el cliente ha recibido la dirección IP del servidor, el cliente dirige las peticiones de la aplicación directamente al servidor seleccionado (ruta 2).
Cisco CSS Controller forma una solución complementaria junto con conmutadores CSS 11000 de Cisco. La solución combinada mezcla las habilidades del direccionamiento de contenido y el reenvío de paquetes de los conmutadores CSS 1100 con los sofisticados algoritmos de Load Balancer para determinar la información de carga y la disponibilidad del servicio (base de datos o aplicación de servidor de programa de fondo). La función Cisco CSS Controller emplea el algoritmo de cálculo estándar, los asesores estándares y personalizados de Load Balancer y Metric Server para determinar la métrica, el estado y la carga del servicio. Con esta información, Cisco CSS Controller genera pesos de servicio, que enviará al conmutador Cisco CSS para obtener una selección de servicio, optimización de la carga y tolerancia de errores óptimos.
Cisco CSS Controller realiza un seguimiento de muchos criterios, incluidos:
Cuando un conmutador Cisco CSS, sin Cisco CSS Controller, determina el estado de un servicio que proporciona contenido, utiliza tiempos de respuestas para peticiones de contenido u otras medidas de red. Con Cisco CSS Controller instalado, estas actividades se descargan del conmutador Cisco CSS a Cisco CSS Controller. Cisco CSS Controller influencia el peso del servicio o la habilidad de servir contenido, y activa o suspende un servicio como apropiado cuando el servicio deja de estar disponible o vuelve a estarlo.
Cisco CSS Controller:
Cisco CSS Controller, junto con el conmutador Cisco CSS, ofrece una solución que incluye lo "mejor de los dos mundos", que combina la conmutación de contenido a velocidad de cable con la optimización del conocimiento sofisticado de aplicaciones, tolerancia de errores y carga del servicio. Cisco CSS Controller forma parte de una solución complementaria global entre el conmutador Cisco CSS e IBM WebSphere Application Server Load Balancer.
Nortel Alteon Controller junto con la familia de conmutadores Web de Nortel Alteon ofrece una solución complementaria que combina la capacidad y velocidad de reenvío de paquetes de los conmutadores con los algoritmos sofisticados de Load Balancer para determinar los pesos de servidores.
Nortel Alteon Controller permite desarrollar asesores personalizados capaces de realizar evaluaciones más inteligentes que tienen en cuenta la aplicación sobre la disponibilidad y carga de las aplicaciones utilizadas para desplegar servicios.
Metric Server facilita información de carga del sistema, como la información de utilización de la CPU y la memoria, y una infraestructura para que desarrolle medidas de carga del sistema personalizadas.
Nortel Alteon Controller recopila muchos tipos de datos de la métrica para determinar los pesos para los servidores en los que los conmutadores de Nortel Alteon Web equilibran la carga.
Nortel Alteon Controller utiliza SNMP para comunicarse con el conmutador. La información de configuración, estado y conexión se recupera del conmutador. Cuando el controlador ha calculado los pesos de servidores, éstos se definen en el conmutador. El conmutador utiliza los pesos definidos por el controlador para seleccionar el mejor servidor para manejar peticiones de cliente para un servicio.
Figura 7. Ejemplo de un sitio que utiliza Nortel Alteon Controller para gestionar servidores locales
Puede gestionar el controlador mediante un navegador, una GUI remota o una interfaz de línea de mandatos remota.
Nortel Alteon Controller junto con la familia de conmutadores web de Nortel Alteon ofrece una solución que incluye "lo mejor de los dos mundos", que combina la conmutación de paquetes a velocidad de cable con la optimización del conocimiento sofisticado de aplicaciones, tolerancia de errores y carga del servidor. Nortel Alteon Controller forma parte de una solución complementaria entre la familia de conmutadores de Web de la familia Nortel Alteon y WebSphere de IBM.
En este capítulo se enumeran las características de configuración de los componentes de Load Balancer para que pueda determinar qué características va a utilizar para gestionar la red:
Para optimizar el equilibrio de carga entre servidores y asegurar que se selecciona el servidor "correcto", consulte los apartados:
Dispatcher admite el equilibrio de carga entre los servidores HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP y cualquier otro TCP o aplicación basada en UDP sin estado.
_ Para ejecutar la configuración de Load Balancer desde una máquina aparte de aquélla donde reside Load Balancer, consulte el apartado Administración remota de Load Balancer.
_ Para ejecutar Dispatcher en la misma máquina que el servidor Web en el que va a equilibrar la carga, consulte el apartado Utilización de servidores con ubicación compartida.
_ Para utilizar Dispatcher con el fin de eliminar limitaciones de un punto de error único en la red, consulte los apartados Alta disponibilidad sencilla y Alta disponibilidad mutua.
Cuando equilibra la carga de tráfico SSL (HTTPS):
_ Para asegurarse de que el cliente utiliza el mismo servidor SSL para varias conexiones, consulte el apartado Cómo funciona la característica de afinidad para Load Balancer.
_ Para asegurarse de que el cliente utiliza el mismo servidor para tráfico HTTP y SSL, consulte el apartado Afinidad entre puertos.
_ Para asegurarse de que el cliente utiliza el mismo servidor para varias conexiones, consulte el apartado Cómo funciona la característica de afinidad para Load Balancer.
_ Para asegurarse de que un grupo de clientes utilizan el mismo servidor para varias conexiones, consulte el apartado Máscara de dirección de afinidad (stickymask).
_ Para eliminar un servidor de la configuración (por ejemplo, para fines de mantenimiento) sin interrumpir el tráfico del cliente, consulte el apartado Desactivar temporalmente el manejo de conexiones de servidor.
Para dirigir los clientes a conjuntos de servidores distintos para la misma dirección Web, puede añadir "reglas" a la configuración de Dispatcher. Para obtener más información, consulte el apartado Configuración del equilibrio de carga basado en reglas.
_ Para dirigir clientes a conjuntos de servidores distintos según la dirección IP de origen del cliente, consulte el apartado Utilización de reglas basadas en la dirección IP de cliente.
_ Para dirigir clientes a conjuntos de servidores distintos según el puerto del cliente, consulte el apartado Utilización de reglas basadas en el puerto de cliente.
_ Para dirigir clientes a conjuntos de servidores distintos según la hora del día, consulte el apartado Utilización de reglas basadas en la hora del día.
_ Para dirigir clientes a servidores según los bits TOS (Tipo de servicio) de paquetes de red, consulte el apartado Utilización de reglas basadas en el tipo de servicio (TOS).
_ Para dirigir clientes a conjuntos de servidores distintos según el tráfico del sitio:
_ Utilizando conexiones por segundo, consulte el apartado Utilización de reglas basadas en las conexiones por segundo.
_ Utilizando el total de conexiones activas, consulte el apartado Utilización de reglas basadas en el total de conexiones activas.
_ Reservando y compartiendo el ancho de banda para direcciones Web distintas, consulte el apartado Utilización de reglas basadas en ancho de banda reservado y ancho de banda compartido.
_ Asegurando que el tráfico se mide correctamente para cada uno de los conjuntos de servidores, consulte el apartado Opción de evaluación del servidor para reglas.
_ Para dirigir el tráfico de desbordamiento a un conjunto de servidores predeterminado (por ejemplo, los servidores que responderán "site busy", sitio ocupado), consulte el apartado Utilización de reglas que son siempre ciertas.
_ Para alterar temporalmente la afinidad del cliente con el fin de asegurarse de que el cliente no se "adhiera" a un servidor con desbordamiento, consulte el apartado Alteración temporal de la afinidad entre puertos.
Para asegurarse de que los clientes SSL vuelven al mismo servidor SSL, según el ID de SSL de la petición de cliente
_ Consulte la sección en HTTPS (SLL).
Para dirigir los clientes HTTP a conjuntos de servidores distintos utilizando reglas según la correspondencia del contenido del URL de la petición de cliente, consulte los apartados Direccionamiento basado en contenido de Dispatcher (método de reenvío cbr) y Utilización de reglas basadas en el contenido de peticiones para obtener más información.
_ Para distinguir entre URL determinados y sus aplicaciones de servicio, consulte el apartado Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP)
_ Para asegurarse de que los clientes vuelven al mismo servidor cuando solicitan un contenido similar en varias conexiones utilizando cookies creados por los servidores Web, consulte el apartado Afinidad de cookies pasivos.
_ Para equilibrar la carga del tráfico Web con servidores proxy de colocación en caché que permiten que se coloque en caché un contenido único en cada servidor (así aumenta el tamaño de la memoria caché del sitio al eliminar la colocación en caché del contenido redundante en varias máquinas) consulte el apartado Afinidad de URI.
La ventaja de utilizar el método de reenvío cbr de Dispatcher es que proporciona una respuesta más rápida a las peticiones de cliente que el componente CBR. Además, el reenvío cbr de Dispatcher no requiere la instalación y utilización de Caching Proxy.
Si la red incluye tráfico SSL (de cliente a través de servidor) completamente seguro, la ventaja de utilizar el componente CBR (junto con Caching Proxy) es que puede procesar el cifrado y descifrado necesario para realizar direccionamiento basado en contenido. Para conexiones completamente seguras, el reenvío cbr de Dispatcher sólo se puede configurar con la afinidad de ID de SSL porque no puede procesar el cifrado y descifrado para realizar el direccionamiento basado en contenido verdadero en el URL de la petición de cliente.
Se puede conseguir el equilibrio de carga de área amplia por varios métodos distintos.
_ Para equilibrar la carga en servidores remotos utilizando la característica de área amplia de Dispatcher, consulte los apartados: Configurar soporte de Dispatcher de área amplia y Soporte de GRE (Encapsulamiento genérico de direccionamiento).
_ Para equilibrar la carga en servidores remotos utilizando el método de reenvío nat de Dispatcher, consulte el apartado NAT/NAPT de Dispatcher (método de reenvío nat).
_ Para equilibrar la carga de una dirección Web con varios daemons de servidor en la misma máquina, donde cada daemon está a la escucha en un puerto único, consulte el apartado NAT/NAPT de Dispatcher (método de reenvío nat).
_ Para incluir el tráfico del Dispatcher en una red distinta que el tráfico del cliente (con el fin de mejorar el rendimiento disminuyendo la competencia por los recursos en la red externa), consulte el apartado Utilización de una configuración de red privada.
_ Para combinar varias direcciones Web en una sola configuración, consulte el apartado Utilizar un clúster comodín para combinar configuraciones de servidores.
_ Para equilibrar la carga de cortafuegos, consulte el apartado Utilizar un clúster comodín para equilibrar la carga de cortafuegos.
_ Para dirigir el tráfico de todos los puertos de destino, consulte el apartado Utilizar el puerto comodín para dirigir el tráfico de puerto no configurado.
_ Para detectar posibles ataques para "rechazo de servicio", consulte el apartado Detección de ataques para rechazo de servicio (DoS).
_ Para analizar el tráfico del servidor, consulte el apartado Utilización del registro cronológico binario para analizar estadísticas de servidor.
_ Para generar alertas cuando se marquen los servidores como activos o inactivos, consulte el apartado Utilización de scripts para generar una alerta o anotar anomalías en el servidor.
CBR integra el equilibrio de carga con Caching Proxy de WebSphere Application Server para dirigir mediante proxy peticiones de cliente a los servidores HTTP o HTTPS (SSL) especificados. Para utilizar CBR, debe instalarse y configurarse Caching Proxy en la misma máquina. Si desea información sobre cómo configurar Caching Proxy con el fin de utilizar CBR, consulte el apartado Paso 1. Configurar Caching Proxy para que pueda utilizar CBR.
Con el componente CBR (o el método de reenvío cbr del componente Dispatcher), puede proporcionar estas ventajas a sus clientes:
_ Equilibre la carga de peticiones de cliente para distintos tipos de contenido a conjuntos de servidores. (Consulte el apartado Peticiones de equilibrio de carga para distintos tipos de contenido.)
_ Mejore el tiempo de respuesta dividiendo óptimamente el contenido del sitio entre los servidores web. (Consulte el apartado División del contenido del sitio para obtener un mejor tiempo de respuesta.)
_ Asegúrese de que el tráfico del cliente sea ininterrumpido cuando haya un anomalía del servidor permitiendo que se asignen varios servidores a cada tipo de contenido. (Consulte el apartado Provisión de una copia de seguridad del contenido del servidor web.)
Si la red requiere un tráfico SSL (de cliente a través de servidor) completamente seguro, la ventaja de utilizar el componente CBR (junto con Caching Proxy) es que puede procesar el cifrado/descifrado SSL para realizar direccionamiento basado en contenido.
Para conexiones SSL completamente seguras, sólo se puede configurar el reenvío cbr de Dispatcher con la afinidad de ID de SSL porque no puede procesar el cifrado/descifrado para realizar el direccionamiento basado en contenido verdadero en el URL de la petición de cliente.
Para tráfico HTTP, la ventaja de utilizar el método de reenvío cbr de Dispatcher es que proporciona una respuesta más rápida a las peticiones de cliente que el componente CBR. Además, el reenvío cbr de Dispatcher no requiere la instalación y utilización de Caching Proxy.
_ Para ejecutar la configuración de Load Balancer desde una máquina aparte de aquélla donde reside Load Balancer, consulte el apartado Administración remota de Load Balancer.
_ Se puede ejecutar CBR en la misma máquina que un servidor Web del que se está equilibrando la carga. Consulte el apartado Utilización de servidores con ubicación compartida para obtener más información.
_ Para mejorar la utilización de la CPU utilizando varios procesos Caching Proxy, consulte el apartado Utilización de varios procesos Caching Proxy para mejorar la utilización de la CPU.
Para permitir direccionamiento basado en contenido de tráfico SSL:
_ Utilizando una conexión segura en ambos sentidos (cliente a proxy y proxy a servidor), consulte el apartado Equilibrio de carga entre conexiones completamente seguras (SSL).
_ Utilizando conexiones seguras sólo de cliente a proxy, consulte el apartado Equilibrio de carga de cliente a proxy en SSL y de proxy a servidor en HTTP.
_ Para distinguir entre URL determinados y sus aplicaciones de servicio, consulte el apartado Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP)
Para dirigir los clientes a conjuntos de servidores distintos para la misma dirección Web, puede añadir "reglas" a la configuración de CBR. Para obtener más información, consulte el apartado Configuración del equilibrio de carga basado en reglas.
_ Para dirigir clientes a conjuntos de servidores distintos según el contenido del URL solicitado, consulte el apartado Utilización de reglas basadas en el contenido de peticiones.
_ Para dirigir clientes a conjuntos de servidores distintos según la dirección IP de origen del cliente, consulte el apartado Utilización de reglas basadas en la dirección IP de cliente.
_ Para dirigir clientes a conjuntos de servidores distintos según la hora del día, consulte el apartado Utilización de reglas basadas en la hora del día.
_ Para dirigir clientes a conjuntos de servidores distintos según el tráfico del sitio:
Utilizando conexiones por segundo, consulte el apartado Utilización de reglas basadas en las conexiones por segundo.
Utilizando el total de conexiones activas, consulte el apartado Utilización de reglas basadas en el total de conexiones activas.
_ Para dirigir el tráfico de desbordamiento a un conjunto de servidores predeterminado (por ejemplo, el servidor o servidores que responderán "site busy", sitio ocupado), consulte el apartado Utilización de reglas que son siempre ciertas.
_ Para alterar temporalmente la afinidad del cliente con el fin de asegurarse de que el cliente no se "adhiera" a un servidor con desbordamiento, consulte el apartado Alteración temporal de la afinidad entre puertos.
_ Para asegurarse de que un cliente devuelva el mismo servidor para varias conexiones, consulte el apartado Cómo funciona la característica de afinidad para Load Balancer.
_ Para eliminar un servidor de la configuración (por ejemplo, para fines de mantenimiento) sin interrumpir el tráfico del cliente, consulte el apartado Desactivar temporalmente el manejo de conexiones de servidor.
_ Para asegurarse de que los clientes vuelven al mismo servidor cuando solicitan un contenido similar en varias conexiones sin confiar en cookies creados por los servidores Web, consulte el apartado Afinidad de cookies activos.
_ Para asegurarse de que los clientes vuelven al mismo servidor cuando solicitan un contenido similar en varias conexiones utilizando cookies creados por los servidores Web, consulte el apartado Afinidad de cookies pasivos.
_ Para equilibrar la carga del tráfico Web con servidores proxy de colocación en memoria caché que permiten que se coloque en memoria caché un contenido único en cada servidor (así aumenta el tamaño de la memoria caché del sitio al eliminar la colocación en caché del contenido redundante en varias máquinas) consulte el apartado Afinidad de URI.
_ Para eliminar las limitaciones de un punto único de anomalía en la red utilizando Dispatcher en una configuración de dos niveles con CBR, consulte el apartado Cómo Load Balancer puede proporcionar alta disponibilidad.
_ Para analizar el tráfico del servidor, consulte el apartadoUtilización del registro cronológico binario para analizar estadísticas de servidor.
_ Para generar alertas cuando se marquen los servidores como activos o inactivos, consulte el apartado Utilización de scripts para generar una alerta o anotar anomalías en el servidor.
Site Selector equilibra la carga de peticiones de servicio de nombres entre un grupo de servidores.
_ Para ejecutar la configuración de Load Balancer desde una máquina aparte de aquélla donde reside Load Balancer, consulte el apartado Administración remota de Load Balancer.
_ Se puede ejecutar Site Selector en la misma máquina que el servidor del que se está equilibrando la carga sin tener que realizar pasos de configuración adicionales.
_ La característica de alta disponibilidad está inherentemente disponible a través de metodologías de sistema de nombres de dominio (DNS) utilizando varios Site Selectors redundantes, suponiendo que la configuración del servidor de nombres padre es correcta y que los métodos de recuperación de DNS normales se encuentran en su lugar. Por ejemplo, entre los métodos de recuperación de DNS normales están: retransmisión de consultas y reintento de transferencias de zona.
_ Para eliminar las limitaciones de un punto único de anomalía en la red utilizando Dispatcher en una configuración de dos niveles con Site Selector, consulte el apartado Cómo Load Balancer puede proporcionar alta disponibilidad.
_ Para asegurarse de que el cliente utiliza el mismo servidor para varias solicitudes de servidor de nombres, consulte el apartado Cómo funciona la característica de afinidad para Load Balancer.
_ Para asegurarse de que haya afinidad de cliente con servidor utilizando el método DNS estándar de establecer el TTL (Tiempo de duración), consulte el apartado Consideraciones de TTL.
Para dirigir peticiones de cliente a conjuntos de servidores distintos para la resolución de nombres de dominio, puede añadir "reglas" a la configuración de Site Selector. Para obtener más información, consulte el apartado Configuración del equilibrio de carga basado en reglas.
_ Para dirigir clientes a conjuntos de servidores distintos según la dirección IP de origen del cliente, consulte el apartado Utilización de reglas basadas en la dirección IP de cliente.
_ Para dirigir clientes a conjuntos de servidores distintos según la hora del día, consulte el apartado Utilización de reglas basadas en la hora del día.
_ Para dirigir clientes a conjuntos de servidores distintos según los valores de carga de métrica del conjunto de servidores, consulte los apartados:
_ Para dirigir el tráfico de desbordamiento a un conjunto de servidores predeterminado (por ejemplo, el servidor o servidores que responderán "site busy", sitio ocupado), consulte el apartado Utilización de reglas que son siempre ciertas.
Se puede ejecutar Site Selector tanto en redes de área local (LAN) como en redes de área amplia (WAN).
En entornos de WAN:
_ Para equilibrar la carga de peticiones del servidor de nombres de cliente utilizando el método de selección de turno rotativo sopesado, no es necesario ningún paso de configuración adicional.
_ Para tener en cuenta la proximidad de red del servidor de nombres de cliente a los servidores que proporcionan la aplicación solicitada (los servidores de destino), consulte el apartado Utilización de la característica proximidad de red.
_ Para generar alertas cuando se marquen los servidores como activos o inactivos, consulte el apartado Utilización de scripts para generar una alerta o anotar anomalías en el servidor.
Cisco CSS Controller mejora las posibilidades de equilibrio de carga de servidores de los Conmutadores Cisco con mayor aplicación y conciencia del sistema. El controlador utiliza medidas más sensibles a la aplicación y al sistema para calcular dinámicamente los pesos del servidor. Los pesos se proporcionan al conmutador con SNMP. El conmutador utiliza los pesos cuando procesa peticiones de cliente lo que produce una optimización de la carga del servidor y una tolerancia a errores mejorada.
Para optimizar el equilibrio de carga entre servidores y asegurar que se selecciona el servidor "correcto", consulte los apartados:
_ Optimización del equilibrio de carga que proporciona Load Balancer
_ Asesores y Crear asesores personalizados (personalizables)
_ Para ejecutar la configuración de Load Balancer desde una máquina aparte de aquélla donde reside Load Balancer, consulte el apartado Administración remota de Load Balancer.
_ Se puede ejecutar Cisco CSS Controller en la misma máquina que el servidor del que se está equilibrando la carga sin tener que realizar pasos de configuración adicionales.
_ Para eliminar las limitaciones de un punto único de anomalía en la red, los dos, tanto el conmutador Cisco CSS como Cisco CSS Controller, tienen posibilidades de alta disponibilidad. Para el conmutador, están disponibles las posibilidades de alta disponibilidad utilizando el protocolo de redundancia de CSS. Para Cisco CSS Controller, se utiliza un protocolo propietario que permite la configuración de reposo dinámico de dos controladores.
Si desea más información sobre cómo configurar la característica de alta disponibilidad, consulte el apartado Alta disponibilidad.
_ Para analizar el tráfico del servidor, consulte el apartadoUtilización del registro cronológico binario para analizar estadísticas de servidor.
_ Para generar alertas cuando se marquen los servidores como activos o inactivos, consulte el apartado Utilización de scripts para generar una alerta o anotar anomalías en el servidor.
Nortel Alteon Controller mejora las posibilidades de equilibrio de carga de servidores de los Conmutadores Nortel Alteon con mayor aplicación y conciencia del sistema. El controlador utiliza medidas más sensibles a la aplicación y al sistema para calcular dinámicamente los pesos del servidor. Los pesos se proporcionan al conmutador con SNMP. El conmutador utiliza los pesos cuando procesa peticiones de cliente lo que produce una optimización de la carga del servidor y una tolerancia a errores mejorada.
Para optimizar el equilibrio de carga entre servidores y asegurar que se selecciona el servidor "correcto", consulte los apartados:
_ Optimización del equilibrio de carga que proporciona Load Balancer
_ Asesores y Crear asesores personalizados (personalizables)
_ Para ejecutar la configuración de Load Balancer desde una máquina aparte de aquélla donde reside Load Balancer, consulte el apartado Administración remota de Load Balancer.
_ Se puede ejecutar Nortel Alteon Controller en la misma máquina que el servidor del que se está equilibrando la carga sin tener que realizar pasos de configuración adicionales.
_ Para eliminar las limitaciones de un punto único de anomalía en la red, los dos, Conmutador Nortel Alteon Web y Nortel Alteon Controller, tienen posibilidades de alta disponibilidad. Para el conmutador, es posible la alta disponibilidad utilizando el protocolo de redundancia para conexiones con servidores y para servicios. Nortel Alteon Controller proporciona una alta disponibilidad utilizando un protocolo propietario que permite la configuración de reposo dinámico de dos controladores.
Si desea más información sobre cómo configurar la característica de alta disponibilidad, consulte el apartado Alta disponibilidad.
_ Para analizar el tráfico del servidor, consulte el apartadoUtilización del registro cronológico binario para analizar estadísticas de servidor.
_ Para generar alertas cuando se marquen los servidores como activos o inactivos, consulte el apartado Utilización de scripts para generar una alerta o anotar anomalías en el servidor.
Este capítulo proporciona información sobre la instalación de Load Balancer mediante herramientas de paquetes del sistema y los requisitos de todos los sistemas operativos admitidos.
Para obtener instrucciones de instalación con el programa de instalación del producto, consulte el documento Conceptos, planificación e instalación de Edge Components.
Java 2 SDK se instala automáticamente con Load Balancer en todas las plataformas.
Si va a migrar desde una versión anterior de Load Balancer, o si va a volver a instalar un sistema operativo, antes de la instalación puede guardar cualquier archivo de configuración o archivo de script anterior para Load Balancer.
Dependiendo del tipo de instalación, no se proporcionarán todos los paquetes de Load Balancer que se listan en este apartado.
Si desea información sobre los requisitos de hardware y software, incluidos los navegadores soportados, consulte la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
En la Tabla 1 se listan las imágenes installp para Load Balancer y el orden de instalación recomendado utilizando la herramienta de instalación de paquetes del sistema.
Tabla 1. Imágenes installp de AIX
Base | ibmlb.base.rte |
Administración (con los mensajes) |
|
Controlador de dispositivo | ibmlb.lb.driver |
Licencia | ibmlb.lb.license |
Componentes de Load Balancer (con los mensajes) |
|
Documentación (con los mensajes) |
|
Metric Server | ibmlb.ms.rte |
Donde componente puede ser: disp (Dispatcher), cbr (CBR), ss (Site Selector), cco (Cisco CSS Controller) o nal (Nortel Alteon Controller). De modo opcional, puede seleccionar qué componente o componentes desea instalar.
Donde idioma puede ser:
El paquete de documentación sólo incluye la documentación en inglés. El conjunto de las traducciones de la documentación de Load Balancer están en el siguiente sitio Web: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Si tiene una versión anterior instalada, desinstale esta copia antes de instalar la versión actual. Primero, asegúrese de que se han detenido todos los ejecutores y servidores. A continuación, para desinstalar el producto completo, entre el mandato installp -u ibmlb (o el nombre anterior, por ejemplo intnd). Para desinstalar catálogos de archivos determinados, deberá listarlos específicamente en lugar de indicar el nombre de paquete.
Cuando instala el producto, tiene la opción de instalar cualquiera de los elementos siguientes o todos ellos:
Siga estos pasos para instalar Load Balancer para sistemas AIX:
Con SMIT:
Cuando finalice el mandato, pulse Hecho y a continuación seleccione Salir de Smit del menú Salir o pulse F12. Si utiliza SMITTY, pulse F10 para salir del programa.
Con la línea de mandatos:
Si va a instalar desde un CD, debe entrar los mandatos siguientes para montar el CD:
mkdir /cdrom mount -v cdrfs -p -r /dev/cd0 /cdrom
Consulte la tabla siguiente con el objeto de determinar qué mandato o
mandatos ha de entrar para instalar los paquetes de Load Balancer que desea para sistemas
AIX:
Tabla 2. Mandatos de instalación de AIX
Base | installp -acXgd dispositivo ibmlb.base.rte |
Administración (con los mensajes) | installp -acXgd dispositivo ibmlb.admin.rte ibmlb.msg.idioma.admin |
Controlador de dispositivo | installp -acXgd dispositivo ibmlb.lb.driver |
Licencia | installp -acXgd dispositivo ibmlb.lb.license |
Componentes de Load Balancer (con msgs). Incluye: Dispatcher, CBR, Site Selector, Cisco CSS Controller y Nortel Alteon Controller. | installp -acXgd dispositivo ibmlb.componente.rte ibmlb.msg.idioma.lb |
Documentos (con los mensajes) | installp -acXgd dispositivo ibmlb.doc.rte ibmlb.msg.en_US.lb |
Metric Server | installp -acXgd dispositivo ibmlb.ms.rte |
donde dispositivo es:
Asegúrese de que la columna de resultados en el resumen contiene SATISFACTORIO para cada parte de Load Balancer que instale (APLICAR). No continúe hasta que todas las partes que desea instalar se hayan aplicado satisfactoriamente.
installp -ld dispositivo
donde dispositivo es:
Para desmontar el CD, escriba:
unmount /cdrom
lslpp -h | grep ibmlb
Si se ha instalado todo el producto, este mandato devolverá el resultado indicado a continuación:
ibmlb.base.rte ibmlb.admin.rte ibmlb.lb.driver ibmlb.lb.license ibmlb.<componente>.rte ibmlb.doc.rte ibmlb.ms.rte ibmlb.msg.idioma.admin ibmlb.msg.en_US.doc ibmlb.msg.idioma.lb
Las vías de acceso de instalación de Load Balancer incluyen las siguientes:
Para la administración remota de Load Balancer, con la invocación a método remoto (RMI), tendrá que instalar los paquetes de administración, base, componentes y licencia en el cliente. Para obtener información sobre RMI, consulte el apartado Remote Method Invocation (RMI).
Si desea información sobre los requisitos de hardware y software, incluidos los navegadores soportados, consulte la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
En este apartado se explica cómo instalar Load Balancer en sistemas HP-UX utilizando el CD del producto.
Antes de comenzar el procedimiento de instalación, asegúrese de que tiene autorización de raíz para instalar el software:
Si tiene una versión anterior instalada, debería desinstalar esa copia antes de instalar la versión actual. En primer lugar, asegúrese de que ha detenido el ejecutor y el servidor. A continuación, para desinstalar Load Balancer consulte el apartado Instrucciones para desinstalar los paquetes.
En la Tabla 3 se enumeran los nombres de los paquetes de
instalación de Load Balancer y el orden recomendado para instalarlos utilizando
la herramienta de instalación de paquetes del sistema.
Tabla 3. Detalles de instalación de paquetes HP-UX para Load Balancer
Descripción del paquete | Nombre del paquete de HP-UX |
Base | ibmlb.base |
Administración y mensajes | ibmlb.admin ibmlb.nlv-idioma |
Licencia de Load Balancer | ibmlb.lic |
Componentes de Load Balancer | ibmlb.componente |
Documentación | ibmlb.doc |
Metric Server | ibmlb.ms |
Notas:
|
El procedimiento especificado a continuación facilita detalles sobre los pasos necesarios para completar esta tarea.
su - root Contraseña: contraseña
swinstall -s /origen nombre_paquete
donde origen es el directorio absoluto de la ubicación del paquete y nombre_paquete es el nombre del paquete.
El siguiente mandato instala únicamente el paquete base de Load Balancer (ibmlb.base), si realiza la instalación desde el directorio raíz del CD:
swinstall -s /origen ibmlb.base
Si realiza la instalación desde el directorio raíz, emita el siguiente mandato para instalar todos los paquetes de Load Balancer:
swinstall -s /origen ibmlb
Emita el mandato swlist para enumerar todos los paquetes que ha instalado. Por ejemplo,
swlist -l fileset ibmlb
Utilice el mandato swremove para desinstalar los paquetes. Elimine los paquetes en el orden inverso en el que se instalaron. Por ejemplo, emita los siguientes mandatos:
swremove ibmlb
Para desinstalar un paquete individual, como por ejemplo el componente Dispatcher:
swremove ibmlb.disp
Si desea obtener los requisitos de hardware y software, incluidos los navegadores soportados, consulte la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
En este apartado se explica cómo instalar Load Balancer en sistemas Linux utilizando el CD del producto.
Antes de comenzar el procedimiento de instalación, asegúrese de que tiene autorización de raíz para instalar el software:
Si tiene una versión anterior instalada, debería desinstalar esa copia antes de instalar la versión actual. Primero, asegúrese de que se han detenido todos los ejecutores y servidores. Después, a fin de desinstalar el producto completo, entre el mandato rpm -e nombrepaquete. Al desinstalar, invierta el orden utilizado para la instalación de los paquetes asegurándose de que los paquetes de administración se desinstalen los últimos.
Para instalar Load Balancer:
La imagen de instalación es un archivo que tiene el formato eLBLX-versión:tar.z.
A continuación figura una lista de los paquetes instalables de RMP.
En que --
El paquete de documentación sólo incluye la documentación en inglés. El conjunto de las traducciones de la documentación de Load Balancer están en el siguiente sitio Web: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
El mandato para instalar los paquetes debe emitirse desde el mismo directorio donde residen los archivos RPM. Emita el siguiente mandato para instalar cada paquete: rpm -i paquete.rpm.
Sistemas Red Hat Linux: debido a un problema conocido del sistema Red Hat Linux, también será necesario suprimir los archivos RPM _db* o se producirá un error.
rpm -qa | grep ibmlb
Si instala el producto completo aparecerá lo siguiente:
Para la administración remota de Load Balancer, con la invocación a método remoto (RMI), debe instalar los paquetes de administración, base, componentes y licencia en el cliente. Para obtener información sobre RMI, consulte el apartado Remote Method Invocation (RMI).
Si desea información sobre los requisitos de hardware y software, incluidos los navegadores soportados, consulte la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
En este apartado se explica cómo instalar Load Balancer en sistemas Solaris utilizando el CD del producto.
Antes de comenzar el procedimiento de instalación, asegúrese de que tiene autorización de raíz para instalar el software:
Si tiene una versión anterior instalada, desinstale esa copia antes de instalar la versión actual. En primer lugar, asegúrese de que ha detenido todos los ejecutores y los servidores. A continuación, para desinstalar Load Balancer indique pkgrm nombre_paquete.
Para instalar Load Balancer:
En el indicador de mandatos, entre pkgadd -d nombreVíaAcceso , donde nombreVíaAcceso es el nombre de dispositivo de la unidad de CD-ROM o el directorio en el disco duro donde se ubica el paquete; por ejemplo: pkgadd -d /cdrom/cdrom0/.
A continuación figura una lista de los paquetes visualizados y el orden recomendado en el que deberían instalarse.
El paquete de documentación (ibmlbdoc) sólo incluye la documentación en inglés. El conjunto de las traducciones de la documentación de Load Balancer están en el siguiente sitio Web: www.ibm.com/software/webservers/appserv/ecinfocenter.html.
Si desea instalar todos los paquetes, escriba simplemente "all" y pulse Intro. Si desea instalar algunos de los componentes, entre el nombre o nombres correspondientes a los paquetes a instalar, separados por un espacio o una coma, y pulse Intro. Puede que se le solicite que cambie permisos de directorios o archivos existentes. Sólo tiene que pulsar Intro o responder "yes" (sí). Tiene que instalar los paquetes de requisito previo (porque se realiza la instalación por orden alfabético no por orden de requisito previo). Si responde "all" (todo) sólo responda "yes" (sí) a todas las solicitudes y la instalación se realizará satisfactoriamente.
Si desea instalar únicamente el componente Dispatcher con la documentación y Metric Server, debe instalar los paquetes siguientes: ibmlbbase, ibmlbadm, ibmlblic, ibmdisp, ibmlbdoc e ibmlbms.
Para la administración remota de Load Balancer, con la invocación a método remoto (RMI), tendrá que instalar los paquetes de administración, base, componentes y licencia en el cliente. Para obtener información sobre RMI, consulte el apartado Remote Method Invocation (RMI).
Las vías de acceso de instalación de Load Balancer son las siguientes:
Si desea información sobre los requisitos de hardware y software, incluidos los navegadores soportados, consulte la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
En este apartado se explica cómo instalar Load Balancer en sistemas Windows utilizando el CD del producto.
Se le proporcionará diversos paquetes de instalación:
Para la administración remota de Load Balancer, con la invocación a método remoto (RMI), tendrá que instalar los paquetes de administración, licencia y componentes en el cliente. Para obtener información sobre RMI, consulte el apartado Remote Method Invocation (RMI).
Restricciones: La versión Windows de Load Balancer no se puede instalar en la misma máquina con IBM Firewall.
Antes de comenzar el procedimiento de instalación, asegúrese de que ha iniciado la sesión como Administrador o como usuario con privilegios administrativos.
Si tiene una versión anterior instalada, debería desinstalar esa copia antes de instalar la versión actual. Para desinstalar utilizando Agregar o quitar programas, realice lo siguiente:
Para instalar Load Balancer:
E:\setup
Las vías de acceso de instalación de Load Balancer incluyen las siguientes:
Obtener una actualización: puede obtener el fixpack de Edge Components para los sistemas operativos AIX, HP-UX, Linux, Solaris o Microsoft Windows de la siguiente manera:
Para obtener información sobre sistemas operativos admitidos, consulte el sitio de soporte de IBM para Requisitos del sistema detallados para WebSphere Application Server.
Puede encontrar el enlace con los paquetes de renovación o los fixpack para Edge Components en el sitio de soporte IBM Descargas recomendadas para WebSphere Application Server.
Antes de instalar un paquete de renovación o un fixpack, detenga y desinstale las versiones existentes de Load Balancer anteriores a la versión a la que desee actualizar.
dscontrol executor stop
El ejecutor de Load Balancer puede continuar en ejecución incluso si se detiene dsserver. Si recibe un mensaje que le informa que dsserver no se está ejecutando, inicie dsserver y vuelva a emitir el mandato.
dsserver stop
Tabla 4. Mandatos específicos del sistema para desinstalar Load Balancer
Mandatos específicos del sistema para desinstalar Load Balancer | |
---|---|
Plataforma | Mandatos |
AIX | Desinstale todos los paquetes del producto Load Balancer utilizando el mandato siguiente:
installp -u ibmlb |
HP-UX | Desinstale todos los paquetes del producto Load Balancer utilizando el mandato siguiente:
swremove ibmlb |
Linux |
|
Solaris |
|
Si no ha instalado Load Balancer, sólo es necesario instalar el archivo de licencia para Load Balancer, es decir lb70Full.LIC, antes de instalar un paquete de renovación o un fixpack. Puede obtener la licencia si instala el paquete de licencia para Load Balancer.
Para instalar un paquete de renovación o un fixpack:
Tabla 5. Mandatos específicos del sistema para instalar un paquete de renovación o un fixpack
Mandatos específicos del sistema para instalar un paquete de renovación o un fixpack | |
---|---|
Sistema | Mandatos |
AIX |
|
HP-UX |
swinstall -s /origen nombre_paquete donde origen es el directorio de la ubicación del paquete y nombre_paquete es el nombre del paquete. Por ejemplo, para instalar el paquete base a partir del directorio activo, emita el mandato siguiente: swinstall -s /lb ibmlb.base |
Linux |
rpm -iv nombre_paquete donde nombre_paquete es el nombre del paquete. Por ejemplo, con el mandato siguiente se instalan todos los paquetes para Load Balancer cuando estos paquetes se encuentran en el directorio activo: rpm -iv ibmlb*.rpm
|
Solaris |
pkgadd -d nombreVíaAcceso nombre_paquete donde nombreVíaAcceso es el directorio de la ubicación del paquete y nombre_paquete es el nombre del paquete. Por ejemplo, para instalar el paquete de administración a partir del directorio activo, emita el mandato siguiente: pkgadd -d . ibmlbadm |
En esta tabla se enumeran todos los paquetes que se entregan con Edge Components y el orden de instalación necesario. Instale los paquetes que se incluyen en el paquete de renovación o en el fixpack según el orden que se especifica en la tabla siguiente.
Lista de paquetes | |
Componentes instalados | Actualice los paquetes en este orden (enumerados genéricamente) |
|
|
Documentación de Edge Components | doc-idioma |
Utilice el programa de configuración para Edge Components para actualizar tal como se muestra a continuación
Para muchos componentes, al eliminar el paquete de renovación o el fixpack, los archivos de configuración se guardan en el directorio oldfiles/component. Puede emplear estos archivos de configuración con la versión que vuelve a instalar del producto para mantener la configuración con parches en la versión anterior a la aplicación de los parches. Para el componente Load Balancer, debe guardar manualmente los archivos de configuración para mantener la configuración anterior a la aplicación de parches.
Esta parte proporciona información sobre la configuración de inicio rápido, consideraciones de planificación y describe los métodos para configurar el componente Dispatcher de Load Balancer. Contiene los capítulos siguientes:
Este ejemplo de inicio rápido muestra cómo configurar tres estaciones de trabajo conectadas localmente utilizando el método de reenvío mac del componente Dispatcher para equilibrar la carga del tráfico de la Web entre dos servidores Web. La configuración debería ser básicamente igual para equilibrar cualquier otro tráfico de aplicación TCP o UDP sin estado.
Figura 8. Configuración local sencilla de Dispatcher
El método de reenvío mac es el método predeterminado por medio del cual Dispatcher equilibra la carga de peticiones entrantes al servidor y el servidor devuelve la respuesta directamente al cliente. Para obtener más información sobre el método de reenvío MAC de Dispatcher, consulte el apartado Direccionamiento a nivel de MAC de Dispatcher (método de reenvío mac).
Para el ejemplo de inicio rápido, necesita tres estaciones de trabajo y cuatro direcciones IP. Una estación de trabajo es la máquina de Dispatcher; la otras dos son los servidores Web. Cada servidor Web requiere una dirección IP. La estación de trabajo de Dispatcher requiere dos direcciones: la dirección de no reenvío (NFA) y la dirección del clúster (la dirección en la que se equilibra la carga) que puede proporcionar a clientes para acceder al sitio web.
Estación de trabajo | Nombre | Dirección IP |
---|---|---|
1 | servidor1.Intersplashx.com | 9.47.47.101 |
2 | servidor2.Intersplashx.com | 9.47.47.102 |
3 | servidor3.Intersplashx.com | 9.47.47.103 |
Máscara de red = 255.255.255.0 |
Cada una de las estaciones de trabajo sólo contiene una tarjeta de interfaz de red Ethernet estándar.
Name= www.Intersplashx.com IP=9.47.47.104
Añada un alias para www.Intersplashx.com a la interfaz de bucle de retorno en servidor2.Intersplashx.com y servidor3.Intersplashx.com.
ifconfig lo0 alias www.Intersplashx.com netmask 255.255.255.255
ifconfig lo0:1 plumb www.Intersplashx.com netmask 255.255.255.0 up
Ahora ha completado todos los pasos de configuración que son necesarios en las dos estaciones de trabajo de servidor Web.
Con Dispatcher, puede crear una configuración mediante la línea de mandatos, el asistente de configuración o la interfaz gráfica de usuario (GUI).
Si va a utilizar la línea de mandatos, siga estos pasos:
dscontrol executor start
dscontrol cluster add www.Intersplashx.com
dscontrol port add www.Intersplashx.com:80
dscontrol server add www.Intersplashx.com:80:servidor2.Intersplashx.com
dscontrol server add www.Intersplashx.com:80:servidor3.Intersplashx.com
dscontrol executor configure www.Intersplashx.com
dscontrol manager start
Dispatcher ahora equilibrará la carga según el rendimiento del servidor.
dscontrol advisor start http 80
Dispatcher se asegurará ahora de que las peticiones del cliente no se envíen a un servidor Web con anomalías.
Ya se ha completado la configuración básica con los servidores conectados localmente.
Compruebe si la configuración funciona:
Para obtener información sobre cómo utilizar la GUI de Dispatcher, consulte los apartados GUI y Apéndice A. GUI: instrucciones generales.
Si desea información sobre cómo utilizar el asistente de configuración, consulte el apartado Configuración con el asistente de configuración.
Hay muchos modos de configurar Load Balancer para dar soporte a su sitio. Si sólo tiene un nombre de host para el sitio al que se conectarán todos sus clientes, puede definir un solo clúster de servidores. Para cada uno de estos servidores, configure el puerto a través del que Load Balancer se comunica. Vea la Figura 9.
Ejemplo de Dispatcher configurado con un solo clúster
y 2 puertos
En este ejemplo del componente Dispatcher, se define un clúster en www.productworks.com. Este clúster tiene dos puertos: el puerto 80 para HTTP y el puerto 443 para SSL. Un cliente que solicita http://www.productworks.com (puerto 80) va a un servidor distinto que un cliente que solicita https://www.productworks.com (puerto 443).
Podría resultar adecuado otro modo de configurar Load Balancer si tiene un sitio de un tamaño muy grande con muchos servidores dedicados a cada protocolo admitido. En este caso, quizá desee definir un clúster para cada protocolo con un solo puerto pero con muchos servidores, como se muestra en la Figura 10.
Figura 10. Ejemplo de Dispatcher configurado con dos clústeres, cada uno con un puerto
En este ejemplo del componente Dispatcher, se definen dos clústeres: www.productworks.com para el puerto 80 (HTTP) y www.testworks.com para el puerto 443 (SSL).
Podría ser necesario un tercer modo de configurar Load Balancer si el sitio alberga el contenido de varias empresas o departamentos, en el que cada uno entra al sitio con un URL distinto. En este caso, quizá desee definir un clúster para cada empresa o departamento y luego definir los puertos en los que va a recibir conexiones en ese URL, como se muestra en la Figura 11.
Figura 11. Ejemplo de Dispatcher configurado con 2 clústeres, cada uno con 2 puertos
En este ejemplo del componente Dispatcher, se definen dos clústeres con el puerto 80 para HTTP y el puerto 23 para Telnet para cada uno de los sitios en www.productworks.com y www.testworks.com.
En este capítulo se describe lo que debe tener en cuenta el planificador de la red antes de instalar y configurar el componente Dispatcher.
Este capítulo incluye los apartados siguientes:
Dispatcher consta de las funciones siguientes:
La utilización del gestor es opcional. No obstante, si no se utiliza el gestor, se realiza el equilibrio de carga utilizando la planificación de turno rotativo sopesado según los pesos del servidor actual y no están disponibles los asesores.
Dispatcher también ofrece asesores que no intercambian información específica del protocolo, como el asesor de DB2(R) que informa sobre el estado de los servidores de DB2 y el asesor de ping que informa de si el servidor responde o no a un mandato ping. Para obtener una lista completa de asesores, consulte el apartado Lista de asesores.
También tiene la opción de escribir sus propios asesores (consulte el apartado Crear asesores personalizados (personalizables)).
El uso de asesores es opcional, pero se recomienda.
Las tres funciones clave de Dispatcher (ejecutor, gestor y asesores) actúan conjuntamente para equilibrar y entregar las peticiones entrantes entre servidores. Junto con las peticiones de equilibrio de carga, el ejecutor supervisa el número de conexiones nuevas, de conexiones activas y de conexiones en un estado de finalizadas. El ejecutor también recoge la basura de conexiones finalizadas o restablecidas y suministra esta información al gestor.
El gestor recopila información del ejecutor, los asesores y un programa de supervisión del sistema, como Metric Server. Basándose en la información que recibe, el gestor ajusta cómo se pesan las máquinas servidor en cada puerto y proporciona al ejecutor el nuevo cálculo de pesos para utilizarlo en el equilibrado de nuevas conexiones.
Los asesores supervisan cada servidor en el puerto asignado para determinar el tiempo de respuesta del servidor y la disponibilidad, asimismo proporcionan esta información al gestor. Los asesores también supervisan si un servidor está activo o inactivo. Sin el gestor ni los asesores, el ejecutor realiza la planificación de turno rotativo según los pesos del servidor actuales.
Con Dispatcher, puede seleccionar uno entre tres métodos de reenvío especificados a nivel de puerto: reenvío MAC, reenvío NAT/NAPT o reenvío CBR (Content Based Routing).
Con el método de reenvío MAC de Dispatcher (el método de reenvío predeterminado), Dispatcher equilibra la carga de la petición de entrada con el servidor seleccionado y el servidor devuelve la respuesta directamente al cliente sin la participación de Dispatcher. Con este método de reenvío, el Dispatcher sólo tiene en cuenta los flujos de entrada del cliente al servidor. No tiene que comprobar los flujos de salida del servidor al cliente. Esto reduce significativamente el impacto en la aplicación y puede producir un rendimiento de red mejorado.
Se puede seleccionar el método de reenvío cuando se añade un puerto con el mandato dscontrol port add clúster:puerto method valor. El valor del método de reenvío predeterminado es mac. Puede especificar el parámetro del método sólo cuando se añade el puerto. Una vez que se ha añadido el puerto, no puede cambiar el valor del método de reenvío. Consulte el apartado dscontrol port -- configurar puertos para obtener más información.
Limitación de Linux: los sistemas Linux utilizan un modelo según el host de anunciar direcciones de hardware a direcciones IP utilizando ARP. Este modelo es incompatible con el servidor final o los requisitos de ubicación compartida de alta disponibilidad para el método de reenvío mac de Load Balancer. Consulte el apartado Alternativas de alias de bucle de retorno de Linux cuando se utiliza el reenvío MAC de Load Balancer, donde se describen varias soluciones para alterar el comportamiento del sistema Linux con el fin de que sea compatible con el reenvío mac de Load Balancer.
Limitación de Linux cuando se utilizan servidores zSeries o S/390: existen limitaciones cuando se utilizan servidores zSeries o S/390 que disponen de tarjetas OSA (Open System Adapter). Consulte el apartado Problema: en Linux, limitaciones cuando se utilizan servidores zSeries o S/390 que disponen de tarjetas OSA (Open System Adapter) para conocer posibles alternativas.
Con la posibilidad NAT (Network Address Translation) o NAPT (Network Address Port Translation) de Dispatcher se elimina la limitación para servidores de equilibrio de carga de estar ubicados en una red conectada localmente. Si desea tener servidores situados en ubicaciones remotas, puede utilizar la técnica de método de reenvío NAT en lugar de utilizar una técnica de encapsulación GRE/WAN. También puede utilizar la característica NAPT para acceder a varios daemons del servidor que residen en cada máquina servidor con equilibrio de carga, donde cada daemon está a la escucha en un puerto único.
Puede configurar un servidor con varios daemons de dos modos distintos:
Esta aplicación funciona bien con protocolos de aplicación de nivel superior como HTTP, SSL, IMAP, POP3, NNTP, SMTP, Telnet, etc.
Limitaciones:
Necesitará tres direcciones IP para la máquina de Dispatcher: dirección nfa, dirección del clúster y dirección de retorno. Para implementar NAT/NAPT, realice lo siguiente (consulte también el apartado Pasos de ejemplo para configurar los métodos de reenvío nat o cbr de Dispatcher):
dscontrol server add clúster:puerto:servidor mapport valor returnaddress direcciónretorno router direcciónretorno
Este parámetro correlaciona un número de puerto de destino de la petición de cliente (que es para Dispatcher) con el número de puerto del servidor que Dispatcher utiliza para equilibrar la carga de la petición del cliente. Mapport permite que Load Balancer reciba una petición de cliente en un puerto y la transmita a un puerto distinto en la máquina servidor. Con mapport puede equilibrar la carga de peticiones de cliente en una máquina servidor que podría tener varios daemons del servidor en ejecución. El valor predeterminado de mapport es el número de puerto de destino de la petición de cliente.
La dirección de retorno es una dirección o nombre de host único que puede configurar en la máquina de Dispatcher. Dispatcher utiliza la dirección de retorno como su dirección origen al realizar el equilibrio de carga de las peticiones del cliente al servidor. Esto garantiza que el servidor devuelve el paquete a la máquina Dispatcher en lugar de enviar el paquete directamente al cliente. (Dispatcher reenviará entonces el paquete IP al cliente). Al añadir el servidor, deberá especificar el valor de la dirección de retorno. No puede modificar la dirección de retorno a no ser que quite el servidor y lo añada de nuevo. La dirección de retorno no puede ser la misma que la dirección de clúster, servidor o NFA.
Al utilizar los métodos de reenvío nat o cbr, debe definir una dirección de retorno para la comunicación entre Load Balancer y los servidores de fondo. El número de conexiones que Load Balancer puede mantener activas con el servidor de fondo está limitado por el número de direcciones de retorno que se definen. Load Balancer utiliza puertos que se basan sólo en las direcciones de retorno; no en una combinación de dirección de retorno y servidor. Cuando todos los puertos disponibles están siendo utilizados, las conexiones adicionales fallan. En un entorno ocupado, utilice varias direcciones de retorno para evitar que falten puertos disponibles.
La dirección del direccionador en el servidor remoto. Si se trata de un servidor conectado localmente, entre la dirección del servidor, salvo que éste se encuentre en la misma máquina que Load Balancer. En dicho caso, continúe utilizando la dirección del direccionador real.
El componente Dispatcher permite realizar direccionamiento basado en contenido para HTTP (con la regla de tipo "content" (contenido) y HTTPS (con afinidad de ID de sesión SSL) sin tener que utiliza Caching Proxy. Para el tráfico de HTTP y HTTPS, el método de reenvío cbr de componente Dispatcher puede proporcionar un direccionamiento basado en contenido más rápido que el componente CBR, que requiere Caching Proxy.
Para HTTP: la selección de servidor para el direccionamiento basado en contenido de Dispatcher se basa en el contenido de una dirección URL o de una cabecera HTTP. Se configura utilizando la regla de tipo "content" (contenido). Cuando configure la regla de contenido, especifique la serie de búsqueda "patrón" y un conjunto de servidores en la regla. Cuando se procesa una nueva petición de entrada, esta regla compara la serie especificada con el URL del cliente o con la cabecera HTTP especificada de la petición del cliente.
Si Dispatcher encuentra la serie en la petición del cliente, reenvía la petición a uno de los servidores dentro de la regla. Luego Dispatcher transmite los datos de respuesta del servidor al cliente (método de reenvío "cbr").
Si Dispatcher no encuentra la serie en la petición del cliente, no selecciona un servidor del conjunto de servidores dentro de la regla.
Para HTTPS (SSL): CBR (Content Based Routing) de Dispatcher equilibra la carga basándose en el campo de ID de sesión SSL de la petición de cliente. Con SSL, una petición de cliente contiene el ID de sesión SSL de una sesión anterior y los servidores mantienen una memoria caché de sus conexiones SSL anteriores. La afinidad de sesiones de ID de SSL de Dispatcher permite al cliente y el servidor establecer una nueva conexión utilizando los parámetros de seguridad de la conexión anterior con el servidor. Al eliminar la renegociación de parámetros de seguridad SSL, como claves compartidas y algoritmos de cifrado, los servidores ahorran ciclos de CPU y el cliente obtiene una respuesta más rápida. Para habilitar la afinidad de ID de sesión SSL: el tipo de protocolo especificado para el puerto debe ser SSL y el tiempo de permanencia en memoria del puerto stickytime no puede establecerse en un valor cero. Si se ha superado el tiempo de permanencia en memoria, el cliente debe enviarse a un servidor distinto del anterior.
Necesitará tres direcciones IP para la máquina de Dispatcher: dirección nfa, dirección del clúster y dirección de retorno. Para implementar el direccionamiento basado en contenido de Dispatcher (consulte también el apartado Pasos de ejemplo para configurar los métodos de reenvío nat o cbr de Dispatcher):
dscontrol server add clúster:puerto:servidor mapport valor returnaddress direcciónretorno router direcciónretorno
dscontrol rule 125.22.22.03:80:contentRule1 type content pattern patrón
Donde patrón especifica el patrón que se va a utilizar para la regla de tipo content (contenido). Si desea más información sobre el tipo de regla content, consulte el apartado Utilización de reglas basadas en el contenido de peticiones. Si desea más información sobre expresiones válidas para patrón, consulte el Apéndice B. Sintaxis de la regla de contenido (patrón).
Figura 12. Ejemplo de utilización de los métodos de reenvío nat o cbr de Dispatcher
Necesitará al menos tres direcciones IP para la máquina de Dispatcher. Para la Figura 12, son necesarios estos pasos con el fin de configurar mínimamente los métodos de reenvío nat o cbr de Dispatcher:
1.Inicie el ejecutor dscontrol executor start 2.Defina la pasarela de cliente dscontrol executor set clientgateway 1.2.3.5 NOTA: si la subred no tiene un direccionador local, debe configurar una máquina para que realice IP Forwarding (reenvío IP) y lo utilice como la clientgateway (pasarela de cliente). Consulte la documentación del sistema operativo para determinar cómo habilitar IP Forwarding. 3.Defina la dirección del clúster dscontrol cluster add 1.2.3.44 4.Configure la dirección del clúster dscontrol executor configure 1.2.3.44 5.Defina el puerto con un método de nat o cbr dscontrol port add 1.2.3.44:80 method nat o bien dscontrol port add 1.2.3.44:80 method cbr protocol http 6.Configure una dirección de retorno de alias en Load Balancer (utilizando la tarjeta Ethernet 0) NOTA: En sistemas Linux, no es necesario poner un alias a la dirección de retorno si utiliza el reenvío nat en una máquina con ubicación compartida. dscontrol executor configure 10.10.10.99 O bien, utilice el mandato ifconfig (sólo para Linux o UNIX): AIX: ifconfig en0 alias 10.10.10.99 netmask 255.255.255.0 HP-UX: ifconfig lan0:1 10.10.10.99 netmask 255.255.255.0 up Linux: ifconfig eth0:1 10.10.10.99 netmask 255.255.255.0 up Solaris: ifconfig eri0 addif 10.10.10.99 netmask 255.255.255.0 up 7.Defina los servidores finales dscontrol server add 1.2.3.4:80:192.10.10.10 router 10.10.10.6 returnaddress 10.10.10.99
La pasarela de cliente (1.2.3.5) es la dirección 1 del direccionador entre Load Balancer y el cliente. El direccionador (10.10.10.6) es la dirección 2 del direccionador entre Load Balancer y el servidor final. Si no está seguro de la clientgateway o de la dirección 2 del direccionador, puede utilizar un programa traceroute con la dirección del cliente (o servidor) para determinar la dirección del direccionador. La sintaxis exacta de este programa diferirá según el sistema operativo que se utilice. Debería consultar la documentación del sistema operativo para obtener más información con respecto a este programa.
Si el servidor se encuentra en la misma subred que Load Balancer (es decir, no se devuelve ningún direccionador con traceroute) escriba la dirección del servidor como la dirección del direccionador. Sin embargo, si el servidor se encuentra en la misma máquina que Load Balancer, la dirección del direccionador debe especificarse en el campo de direccionador en lugar de la dirección del servidor. La dirección del direccionador es la que se utiliza en el mandato "server add" en la máquina Load Balancer del paso 7.
Con la creación de particiones del servidor, puede distinguir más entre los URL en particular y sus aplicaciones específicas. Por ejemplo, un servidor Web puede servir páginas JSP, páginas HTML, archivos GIF, peticiones de base de datos, etc. Load Balancer ahora proporciona la posibilidad de crear una partición de un clúster y un servidor específico de un puerto en varios servidores lógicos. Esto permite asesorar sobre un servicio en particular en la máquina para detectar si se ejecuta más rápido un motor de servlets o una petición de base de datos, o si no se ejecuta nada.
La creación de particiones del servidor permite a Load Balancer detectar, por ejemplo, que el servicio HTML atiende páginas rápidamente, pero que la conexión de la base de datos se ha quedado inactiva. Esto permite distinguir la carga según una carga de trabajo específica de servicio granular, en lugar del peso en todo el servidor únicamente.
La creación de particiones del servidor puede resultar de utilidad cuando se utiliza junto con asesores HTTP y HTTPS. Por ejemplo, cuando dispone de un servidor HTML que gestiona páginas HTML, GIF y JSP, si define (añadiendo) el servidor una vez bajo el puerto 80, recibirá sólo un valor de carga para todo el servidor HTTP. Esto podría ser confuso dado que es posible que el servicio GIF no esté funcionando en el servidor. Dispatcher aún envía páginas GIF al servidor, pero el cliente detecta un tiempo de espera excedido o una anomalía.
Si define el servidor tres veces (por ejemplo, ServerHTML, ServerGIF, ServerJSP) bajo el puerto y define el parámetro advisorrequest del servidor con una serie distinta para cada servidor lógico, podrá consultar el estado del servicio en particular en el servidor. ServerHTML, ServerGIF y ServerJSP representan tres servidores lógicos de partición de un servidor físico. Para ServerJSP, puede definir la serie advisorrequest para consultar el servicio en la máquina que gestiona páginas JSP. Para ServerGIF, puede definir la serie advisorrequest para consultar el servicio GIF. Y para ServerHTML, puede definir advisorrequest para consultar el servicio HTML. Por lo tanto, si el cliente no obtiene respuesta de advisorrequest para consultar el servicio GIF, Dispatcher marcará ese servidor lógico (ServerGIF) como inactivo, mientras que los otros dos servidores lógicos podrían funcionar bien. Dispatcher no reenvía ningún GIF más al servidor físico, pero aún puede enviar peticiones JSP y HTML al servidor.
Para obtener más información sobre el parámetro advisorrequest, consulte el apartado Configuración del asesor HTTP o HTTPS utilizando la opción de petición y respuesta (URL).
Dentro de la configuración de Dispatcher, puede representar un servidor físico o uno lógico utilizando la jerarquía de clúster:puerto:servidor. El servidor puede ser una dirección IP única de la máquina (servidor físico) con un nombre simbólico o en un formato de dirección IP. O bien, si define el servidor para representar un servidor con particiones, debe proporcionar una dirección del servidor resoluble para el servidor físico en el parámetro address del mandato dscontrol server add. Consulte el apartado dscontrol server -- configurar servidores para obtener más información.
A continuación figura un ejemplo de cómo crear particiones físicas de servidores en servidores lógicos para gestionar distintos tipos de peticiones.
Cluster: 1.1.1.1 Port: 80 Server: A (IP address 1.1.1.2) HTML server Server: B (IP address 1.1.1.2) GIF server Server: C (IP address 1.1.1.3) HTML server Server: D (IP address 1.1.1.3) JSP server Server: E (IP address 1.1.1.4) GIF server Server: F (IP address 1.1.1.4) JSP server Rule1: /*.htm Server: A Server: C Rule2: /*.jsp Server: D Server: F Rule3: /*.gif Server: B Server: E
En este ejemplo, el servidor 1.1.1.2 se divide en 2 servidores lógicos de partición: "A" (que gestiona peticiones HTML) y "B" (que gestiona peticiones GIF). El servidor 1.1.1.3 se divide en 2 servidores lógicos de partición: "C" (que gestiona las peticiones HTML) y "D" (que gestiona las peticiones JSP). El servidor 1.1.1.4 se divide en 2 servidores lógicos de partición: "E" (que gestiona las peticiones GIF) y "F" (gestiona las peticiones JSP).
Figura 13. Ejemplo de Dispatcher con alta disponibilidad sencilla
La característica de alta disponibilidad conlleva el uso de una segunda máquina de Dispatcher. La primera máquina de Dispatcher realiza el equilibrio de carga para todo el tráfico del cliente del mismo modo que en una configuración de Dispatcher sencilla. La segunda máquina de Dispatcher supervisa el "estado" de la primera y se hace con el control de la tarea de equilibrio de carga si detecta que la primera máquina de Dispatcher ha producido un error.
Se asigna a cada una de las dos máquinas un rol específico, ya sea primaria o reserva. La máquina primaria envía datos de conexión a la máquina de reserva de forma constante. Mientras que la primaria está activa (equilibrando la carga), la de reserva está en estado de espera, continuamente actualizada y preparada para hacerse con el control, si es necesario.
Se hace referencia a las sesiones de comunicación entre las dos máquinas como pulsos. Los pulsos permiten que cada máquina supervise el estado de la otra.
Si la máquina de reserva detecta que la máquina activa ha producido un error, se hará con el control y comenzará a equilibrar la carga. En el punto en que se invierten los estados de las dos máquinas: la máquina de reserva pasa a estar activa y la primaria pasa a estar en espera.
En la configuración de alta disponibilidad, la máquina primaria y la de reserva deben estar en la misma subred con una configuración idéntica.
Si desea información sobre cómo configurar la característica de alta disponibilidad, consulte el apartado Alta disponibilidad.
Figura 14. Ejemplo de Dispatcher con alta disponibilidad mutua
La característica de alta disponibilidad mutua conlleva el uso de dos máquinas de Dispatcher. Las dos máquinas realizan de forma activa el equilibrio de carga del tráfico del cliente y las dos máquinas proporcionan una reserva entre sí. En una configuración de alta disponibilidad sencilla, sólo una máquina realiza el equilibrio de carga. En una configuración de alta disponibilidad mutua, las dos máquinas equilibran la carga de una parte del tráfico del cliente.
Para la alta disponibilidad mutua, se asigna el tráfico del cliente a cada máquina de Dispatcher según la dirección del clúster. Cada clúster se puede configurar con NFA (dirección de no reenvío) de su Dispatcher primario. La máquina de Dispatcher primaria normalmente realiza el equilibrio de carga para ese clúster. En el caso de una anomalía, la otra máquina realiza el equilibrio de carga para su propio clúster y para el clúster del Dispatcher con anomalía.
Si desea una ilustración de una configuración de alta disponibilidad mutua con un "conjunto de clústeres A" compartido y un "conjunto de clústeres B" compartido, consulte la Figura 14. Cada Dispatcher puede dirigir paquetes activamente para su clúster primario. Si el Dispatcher fuera a tener una anomalía y ya no pudiera dirigir más paquetes activamente para su clúster primario, entonces el otro Dispatcher podría hacerse con el control del direccionamiento de paquetes para su clúster de reserva.
Si desea información sobre cómo configurar la alta disponibilidad y la alta disponibilidad mutua, consulte el apartado Alta disponibilidad.
Antes de llevar a cabo los pasos de este capítulo, consulte el apartado Planificación para Dispatcher. En este capítulo se explica cómo crear una configuración básica para el componente Dispatcher de Load Balancer.
Antes de empezar a realizar los pasos de configuración indicados en esta tabla, asegúrese de que la máquina Dispatcher y todas las máquinas de servidores están conectadas a la red, tienen direcciones IP válidas y que pueden enviar una sonda de paquetes Internet entre sí.
Tabla 7. Tareas de configuración para la función Dispatcher
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Dispatcher. |
Configura la configuración de equilibrio de carga.
| Configuración de la máquina Dispatcher |
Configurar máquinas en las que se va a equilibrar la carga. | Crea un alias para el dispositivo de bucle de retorno, comprueba si hay una ruta adicional y suprime todas las rutas adicionales. | Configuración de máquinas de servidor para el equilibrio de carga |
Hay cuatro métodos básicos para la configuración de Dispatcher:
Es la manera más directa que configurar Dispatcher. Los valores de los parámetros de mandatos deben especificarse en caracteres del idioma inglés. Las únicas excepciones son los nombres de host (que se utilizan en los mandatos cluster, server y highavailability) y nombres de archivo (que se utilizan en los mandatos de archivo).
Para iniciar Dispatcher desde la línea de mandatos:
Puede utilizar una versión minimizada de los parámetros del mandato dscontrol escribiendo las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir dscontrol he f en lugar de dscontrol help file.
Para iniciar la interfaz de línea de mandatos, emita dscontrol para recibir un indicador de mandatos de dscontrol.
Para finalizar la interfaz de línea de mandatos, emita exit o quit.
Puede entrar mandatos para configurar Dispatcher en un archivo de script de configuración y ejecutarlos juntos. Consulte el apartado Archivos de configuración de ejemplo de Load Balancer.
dscontrol file appendload miscript
dscontrol file newload miscript
Para guardar la configuración actual en un archivo de script (por ejemplo, guardascript), ejecute el siguiente mandato:
dscontrol file save guardascript
Este mandato guardará el archivo de script de configuración en el directorio ...ibm/edge/lb/servers/configurations/dispatcher.
Para obtener instrucciones generales y un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 41.
Para iniciar la GUI, siga estos pasos:
dsserver
Para configurar el componente Dispatcher desde la GUI, primero debe seleccionar Dispatcher en la estructura de árbol. Inicie el ejecutor y el gestor una vez que se ha conectado a un host. También puede crear clústeres que contengan puertos y servidores, así como iniciar asesores para el gestor.
La GUI puede utilizarse para llevar a cabo las mismas tareas que realizaría con el mandato dscontrol. Por ejemplo, para definir un clúster mediante la línea de mandatos, especifique el mandato dscontrol cluster add clúster. Para definir un clúster desde la GUI, pulse con el botón derecho en el Ejecutor y, en el menú emergente, pulse Añadir clúster. Escriba la dirección del clúster en la ventana emergente y pulse Aceptar.
Los archivos de configuración de Dispatcher preexistentes pueden cargarse con las opciones Cargar nueva configuración (para sustituir completamente la configuración actual) y Añadir a la configuración actual (para actualizar la configuración actual) que aparecen el menú emergente Host. Debe guardar de forma periódica la configuración de Dispatcher en un archivo con la opción Guardar archivo de configuración como que también se encuentra en el menú emergente Host. El menú Archivo situado en la parte superior de la GUI, permite guardar en un archivo las conexiones actuales del host o restaurar conexiones que se encuentran en archivos existentes en todos los componentes de Load Balancer.
Los mandatos de configuración también pueden ejecutarse de forma remota. Para obtener más información, consulte el apartado Remote Method Invocation (RMI).
Para poder ejecutar un mandato desde la GUI: resalte el nodo Host en el árbol de la GUI y seleccione Enviar mandato... en el menú emergente Host. En el campo de entrada de mandatos, escriba el mandato que desea ejecutar, por ejemplo: executor report. El resultado y el historial de los mandatos se ejecutan en la sesión actual y aparecen en la ventana que se proporciona.
Para acceder a la Ayuda, pulse el icono de signo de interrogación situado en la esquina superior derecha de la ventana de Load Balancer.
Para obtener más información sobre cómo utilizar la GUI, consulte el Apéndice A. GUI: instrucciones generales.
Si va a utilizar el asistente de configuración, siga estos pasos:
dsserver
El asistente le guiará, paso a paso, a través del proceso de creación de una configuración básica para el componente Dispatcher. Se formularán preguntas sobre la red. Se le orientará a lo largo de la configuración de un clúster para que Dispatcher equilibre la carga del tráfico de un grupo de servidores.
Antes de configurar la máquina Dispatcher, debe establecer el usuario root (en sistemas AIX, HP-UX, Linux o Solaris) o el administrador en sistemas Windows.
En todas las plataformas soportadas, Load Balancer puede tener un servidor con ubicación compartida . Ubicación compartida significa que Load Balancer puede residir físicamente en una máquina servidor en la que se está efectuando el equilibrio de carga.
En la máquina Dispatcher, al utilizar el método de reenvío MAC, como mínimo se necesitan dos direcciones IP válidas. Para CBR o el método de reenvío NAT, cómo mínimo se necesitarán tres direcciones IP válidas.
Esta dirección IP es la dirección IP primaria de la máquina Dispatcher y se denomina dirección de no reenvío (NFA). De manera predeterminada es la misma dirección que la devuelta por el mandato hostname. Utilice esta dirección para conectarse a la máquina para fines administrativos, como realizar la configuración remota utilizando Telnet o acceder al subagente SNMP. Si la máquina Dispatcher ya puede hacer ping a otras máquinas en la red, no es necesario realizar ninguna otra acción para configurar la dirección de no reenvío.
Una dirección de clúster es una dirección asociada con un nombre de host (como www.suempresa.com). El cliente utilizará esta dirección IP para conectarse a los servidores de un clúster. Esta es la dirección en la que Dispatcher equilibrará la carga.
Dispatcher utiliza la dirección de retorno como su dirección origen al realizar el equilibrio de carga de las peticiones del cliente al servidor. Esto garantiza que el servidor devuelve el paquete a la máquina Dispatcher en lugar de enviar el paquete directamente al cliente. (Dispatcher reenviará entonces el paquete IP al cliente). Al añadir el servidor, deberá especificar el valor de la dirección de retorno. No puede modificar la dirección de retorno a no ser que quite el servidor y lo añada de nuevo.
El número de conexiones que Load Balancer puede mantener activas con el servidor de fondo está limitado por el número de direcciones de retorno que se definen. Load Balancer utiliza puertos que se basan sólo en las direcciones de retorno; no en una combinación de dirección de retorno y servidor. Cuando todos los puertos disponibles están siendo utilizados, las conexiones adicionales fallan. En un entorno ocupado, utilice varias direcciones de retorno para evitar que falten puertos disponibles.
Sólo sistemas Solaris:
Por ejemplo, para cambiar el valor predeterminado, edite el archivo /opt/ibm/edge/lb/servers/ibmlb.conf como se indica a continuación:
Para dar soporte a varios tipos de adaptadores, duplique la línea en el archivo ibmlb.conf y modifique cada línea de forma que coincida con el tipo de dispositivo.
Por ejemplo, si tiene previsto utilizar dos adaptadores Ethernet de 100Mbps, el archivo ibmlb.conf debe tener una sola línea que especifique el dispositivo eri.
Si tiene previsto utilizar un adaptador Ethernet de 10 Mbps y un adaptador Ethernet de 100Mbps, es necesario especificar dos líneas en el archivo ibmlb.conf: una línea que especifique el dispositivo le y una línea que especifique el dispositivo eri.
ifconfig -a
Si obtiene la siguiente salida:
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 eri0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2 inet 9.42.93.208 netmask fffffc00 broadcast 9.42.95.255 ether 0:3:ba:2d:24:45
Edite el archivo ibmlb.conf como se indica a continuación:
eri -1 0 ibmlb
Por ejemplo, si se configuran los clústeres X e Y para que los utilice el componente CBR en cualquiera de los adaptadores listados en ibmlb.conf, los clústeres X e Y se desconfiguran cuando se emiten los mandatos dscontrol executor start o dscontrol executor stop. Es posible que no sea el resultado que desee. Cuando se configuran los clústeres X e Y en el script goAliases, los clústeres se configuran automáticamente después de iniciar o detener el ejecutor de Dispatcher.
Asegúrese de que IP Forwarding no está habilitado para el protocolo TCP/IP.
En la Figura 15 se muestra un ejemplo de Dispatcher configurado con un solo clúster, dos puertos y tres servidores.
Figura 15. Ejemplo de las direcciones IP necesarias para la máquina Dispatcher
Para obtener ayuda sobre los mandatos utilizados en este procedimiento, consulte el apartado Referencia de mandatos para Dispatcher y CBR.
Para ver un archivo de configuración de ejemplo, consulte el apartado Archivos de configuración de ejemplo de Load Balancer.
Sistemas AIX, HP-UX, Linux o Solaris: para iniciar la función de servidor, escriba dsserver.
Sistemas Windows: la función de servidor se inicia automáticamente como un servicio.
Para iniciar la función de ejecutor, escriba el mandato dscontrol executor start. En este momento también puede cambiar varios valores del ejecutor. Consulte el apartado Referencia de mandatos para Dispatcher y CBR.
La dirección de no reenvío se utiliza para conectarse a la máquina para fines administrativos, como la utilización de Telnet o SMTP para esta máquina. De manera predeterminada esta dirección es el nombre de host.
Para definir la dirección de no reenvío, escriba el mandato dscontrol executor set nfa dirección_IP o edite el archivo de configuración de ejemplo. dirección_IP es el nombre simbólico o la dirección IP.
Dispatcher equilibrará las peticiones enviadas a la dirección del clúster para los servidores configurados en los puertos de dicho clúster.
El clúster es el nombre simbólico, la dirección decimal separada por puntos o la dirección especial 0.0.0.0 que define un clúster comodín. Para definir un clúster, emita el mandato dscontrol cluster add. Para establecer las opciones del clúster, emita el mandato dscontrol cluster set o puede utilizar la GUI para emitir mandatos. Los clústeres comodín pueden utilizarse para emparejar varias direcciones IP para los paquetes entrantes sobre los cuales se realizará un equilibrio de carga. Consulte los apartados Utilizar un clúster comodín para combinar configuraciones de servidores, Utilizar un clúster comodín para equilibrar la carga de cortafuegos y Utilizar el clúster comodín con Caching Proxy para un proxy transparente para obtener más información.
Después de definir el clúster, normalmente debe configurar la dirección del clúster en una de las tarjetas de interfaz de red de la máquina Dispatcher. Para ello, emita el mandato dscontrol executor configure dirección_clúster. Este buscará un adaptador con una dirección existente que pertenezca a la misma subred que la dirección del clúster. A continuación, emitirá el mandato de configuración del adaptador del sistema operativo utilizando el adaptador que ha encontrado y la máscara de red correspondiente a la dirección existente encontrada en dicho adaptador. Por ejemplo:
dscontrol executor configure 204.67.172.72
No se recomienda configurar la dirección del clúster en los casos de clústeres añadidos a un servidor en espera en modalidad de alta disponibilidad o de clústeres añadidos a un sistema Dispatcher de área amplia que actúa como servidor remoto. Tampoco es necesario ejecutar el mandato executor configure si utiliza el script goIdle de ejemplo en modalidad autónoma. Para obtener información sobre el script goIdle, utilice Utilización de scripts.
En contadas ocasiones es posible que tenga una dirección de clúster que no coincida con ninguna subred para las direcciones existentes. En este caso, utilice la segunda forma del mandato executor configure y proporcione de forma explícita el nombre de interfaz y la máscara de red. Utilice dscontrol executor configure dirección_interfaz nombre_interfaz máscara_red.
Algunos ejemplos son:
dscontrol executor configure 204.67.172.72 en0 255.255.0.0 (Sistemas AIX) dscontrol executor configure 204.67.172.72 eth0:1 255.255.0.0 (Sistemas Linux) dscontrol executor configure 204.67.172.72 eri0 255.255.0.0 (Sistemas Solaris) dscontrol executor configure 204.67.172.72 en1 255.255.0.0 (Sistemas Windows)
Para utilizar la segunda forma del mandato executor configure en sistemas Windows, debe determinar el nombre de interfaz que utilizará. Si la máquina sólo tiene una tarjeta Ethernet, el nombre de interfaz es en0. Si sólo tiene una tarjeta Token Ring, el nombre de interfaz es tr0. Si tiene varias tarjetas de cualquiera de los dos tipos, será necesario determinar la correlación de las tarjetas. Siga estos pasos:
La salida se mostrará en la pantalla. Para determinar el nombre de interfaz que debe utilizarse para la configuración de Load Balancer, busque la dirección IP de la máquina de Load Balancer en las líneas que figuran a continuación de Number of NIC records.
La dirección IP de la máquina de Load Balancer aparecerá como: ia->ia_addr El nombre de la interfaz asociada aparecerá como: ifp->if_name.
Los nombres asignados por el mandato executor configure están correlacionados con los nombres de interfaz listados en este mandato.
Después de obtener esta información de correlación, puede crear un alias en la interfaz de red para la dirección del clúster.
En sistemas Linux o UNIX(R), el mandato executor configure ejecuta mandatos ifconfig.
Al utilizar aplicaciones de servidor específicas del enlace que enlazan a una lista de direcciones IP que no contienen el IP del servidor, utilice el mandato arp publish en lugar de ifconfig para establecer de forma dinámica una dirección IP en la máquina Load Balancer. Por ejemplo:
arp -s <clúster> <dirección MAC de Load Balancer> pub
Para definir un puerto, escriba el mandato dscontrol port add clúster:puerto, edite el archivo de configuración de ejemplo o utilice la GUI. Clúster es el nombre simbólico o la dirección IP. Puerto es el número del puerto que utiliza para dicho protocolo. En este momento también puede cambiar varios valores del puerto. Debe definir y configurar todos los servidores para un puerto. Consulte el apartado Referencia de mandatos para Dispatcher y CBR.
El número de puerto 0 (cero) se utiliza para especificar un puerto comodín. Este puerto aceptará tráfico para un puerto que no esté destinado a ninguno de los puertos definidos en el clúster. El puerto comodín se utiliza para configurar reglas y servidores para cualquier puerto. Esta función también puede utilizarse si tiene una configuración de servidor y regla idéntica para varios puertos. El tráfico de un puerto podría afectar a las decisiones de equilibrio de carga para el tráfico en otros puertos. Consulte el apartado Utilizar el puerto comodín para dirigir el tráfico de puerto no configurado para obtener más información sobre cuándo utilizar un puerto comodín.
Para definir una máquina servidor con equilibrio de carga, escriba el mandato dscontrol server add clúster:puerto:servidor, edite el archivo de configuración de ejemplo o utilice la GUI. Clúster y servidor pueden ser un nombre simbólico o la dirección IP. Puerto es el número del puerto que utiliza para dicho protocolo. Debe definir más de un servidor por puerto en un clúster para llevar a cabo el equilibrio de carga.
Servidores específicos del enlace: Si el componente Dispatcher está realizando el equilibrio de carga para servidores específicos del enlace, los servidores deben estar configurados para enlazar con la dirección del clúster. Puesto que Dispatcher reenvía paquetes sin cambiar la dirección IP de destino, cuando los paquetes alcanzan el servidor, los paquetes todavía contienen la dirección del clúster como destino. Si se ha configurado un servidor para enlazar a una dirección IP distinta de la dirección del clúster, el servidor no podrá aceptar peticiones cuyo destino es el clúster.
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.
Ubicación compartida de varias direcciones: En una configuración de ubicación compartida, la dirección de la máquina servidor con ubicación compartida no tiene que ser idéntica a la dirección de no reenvío (NFA). Puede utilizar otra dirección si la máquina se ha definido con varias direcciones IP. Para el componente Dispatcher, el servidor con ubicación compartida debe definirse como collocated utilizando el mandato dscontrol server. Para obtener más información sobre los servidores con ubicación compartida, consulte el apartado Utilización de servidores con ubicación compartida.
Para obtener más información sobre la sintaxis del mandato dscontrol server, consulte el apartado dscontrol server -- configurar servidores.
La función de gestor mejora el equilibrio de carga. Para iniciar el gestor, escriba el mandato dscontrol manager start, edite el archivo de configuración de ejemplo o utilice la GUI.
Los asesores proporcionan al gestor más información sobre la capacidad que tienen de las máquinas de servidor con equilibrio de carga para responder a las peticiones. Un asesor es específico de un protocolo. Por ejemplo, para iniciar el asesor HTTP, emita el siguiente mandato:
dscontrol advisor start http puertoPara obtener una lista de asesores junto con sus puertos predeterminados, consulte la Referencia de mandatos para Dispatcher y CBR. Para obtener una descripción de cada asesor, consulte el apartado Lista de asesores.
Si inicia asesores, puede modificar la proporción de la importancia dada a la información de asesor que se incluye en las decisiones para el equilibrio de carga. Para definir las proporciones del clúster, emita el mandato dscontrol cluster set clúster proportions. Para obtener más información, consulte el apartado Proporción de la importancia otorgada a la información de estado
Realice los siguientes pasos si una de estas condiciones es cierta:
Notas:
Al utilizar el método de reenvío MAC, Dispatcher sólo equilibrará la carga en servidores que permiten que el adaptador de bucle de retorno se configure con una dirección IP adicional, para la que el servidor de programa de fondo nunca responderá a las peticiones ARP (protocolo de resolución de direcciones). Para configurar las máquinas de servidor con equilibrio de carga, siga los pasos indicados en este apartado.
Para que las máquinas de servidor con equilibrio de carga funcionen, debe establecer (o preferiblemente asignar un alias) el dispositivo de bucle de retorno (a menudo llamado lo0) en la dirección del clúster. Cuando se utiliza el método de reenvío mac, el componente Dispatcher no cambia la dirección IP de destino en el paquete TCP/IP antes de reenviar el paquete a una máquina servidor TCP. Si se establece o crea un alias del bucle de retorno para la dirección de clúster, las máquinas de servidor con equilibrio de carga aceptarán un paquete que iba dirigido a la dirección del clúster.
Si utiliza un sistema operativo que da soporte a los alias de interfaz de red (como los sistemas AIX, HP-UX, Linux, Solaris o Windows), debe crear un alias del dispositivo de bucle de retorno para la dirección de clúster. La ventaja de utilizar un sistema operativo que dé soporte a los alias es la capacidad de poder configurar las máquinas de servidores con equilibrio de carga de modo que presten servicio para varias direcciones de clúster.
IMPORTANTE: en sistemas Linux, consulte el apartado Alternativas de alias de bucle de retorno de Linux cuando se utiliza el reenvío MAC de Load Balancer.
Si dispone de un servidor con un sistema operativo que no da soporte a los alias, debe establecer el bucle de retorno para la dirección del clúster.
Utilice el mandato correspondiente al sistema operativo, tal como se muestra en la Tabla 8 para establecer u otorgar un alias al dispositivo de bucle de retorno.
Tabla 8. Mandatos para crear alias del dispositivo de bucle de retorno (lo0) para Dispatcher
En algunos sistemas operativos, es posible que se haya una ruta predeterminada y es necesario eliminarla.
route print
IMPORTANTE: En Windows 2003 se deben ignorar todas las rutas adicionales. Si se detectan problemas con el direccionamiento después de la creación de alias, elimine el alias y vuélvalo a añadir utilizando una máscara de red distinta.
netstat -nr
Ejemplo de Windows
Rutas activas: Dirección red Máscara red Pasarela Interfaz Medida 0.0.0.0 0.0.0.0 9.67.128.1 9.67.133.67 1 9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1 9.67.128.0 255.255.248.0 9.67.133.67 9.67.133.67 1 9.67.133.67 255.255.255.255 127.0.0.1 127.0.0.1 1 9.67.133.158 255.255.255.255 127.0.0.1 127.0.0.1 1 9.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 224.0.0.0 224.0.0.0 9.67.133.158 9.67.133.158 1 224.0.0.0 224.0.0.0 9.67.133.67 9.67.133.67 1 255.255.255.255 255.255.255.255 9.67.133.67 9.67.133.67 1
9.0.0.0 255.0.0.0 9.67.133.158 9.67.133.158 1
Debe suprimir la ruta adicional. Utilice el mandato correspondiente al sistema operativo que se muestra en la Tabla 9 para suprimir la ruta adicional.
Ejemplo: para suprimir la ruta adicional tal como se muestra en la tabla de ejemplo "Rutas activas" para el paso 2, escriba:
route delete 9.0.0.0 9.67.133.158
Tabla 9. Mandatos para suprimir todas las rutas adicionales para Dispatcher
Si se utiliza el ejemplo que se muestra en la Figura 15 y se configura una máquina servidor que se ejecuta en un sistema AIX, el mandato sería:
route delete -net 204.0.0.0 204.67.172.72
Para verificar si un servidor de programa de fondo está configurado correctamente, siga los pasos siguientes desde una máquina distinta que esté en la misma subred cuando Load Balancer no esté configurado y el clúster no esté configurado:
arp -d clúster
ping clúster
No debe haber ninguna respuesta. Si hay una respuesta al mandato ping, asegúrese de que no se haya ejecutado el mandato ifconfig y se haya asociado la dirección del clúster con la interfaz. Asegúrese de que no haya ninguna máquina con una entrada ARP publicada para la dirección de clúster.
arp -a
En la salida del mandato, debería ver la dirección MAC del servidor. Emita el mandato:
arp -s clúster dirección_mac_servidor
arp -d clúster
Algunas versiones de sistemas Linux emiten respuestas ARP para cualquier dirección IP configurada en la máquina en cualquier interfaz que exista en la máquina. También puede elegir una dirección IP de origen para consultas ARP who-has en función de todas las direcciones IP que existen en la máquina, independientemente de las interfaces en las que se han configurado esas direcciones. Esto provoca que todo el tráfico del clúster se dirija a un solo servidor de una manera indeterminada.
Cuando se utiliza el método de reenvío MAC de Dispatcher, debe emplearse un mecanismo que garantice que las pilas de servidores de programas de fondo puedan aceptar el tráfico dirigido al clúster, incluida la máquina en espera de alta disponibilidad con ubicación compartida, cuando se utilizan simultáneamente la alta disponibilidad y la ubicación compartida.
En la mayoría de los casos, debe otorgar un alias a la dirección de clúster en el bucle de retorno; por lo tanto, los servidores de programas de fondo deben tener un alias del clúster en el bucle de retorno, y si utiliza la alta disponibilidad y la ubicación compartida, los servidores de equilibrio de carga en espera deben tener alias de clúster en el bucle de retorno.
Para asegurarse de que sistemas Linux no publican direcciones en el bucle de retorno, puede utilizar cualquiera de las cuatro soluciones siguientes para hacer que sistemas Linux sea compatibles con el reenvío MAC de Dispatcher.
# sysctl -w net.ipv4.conf.all.hidden=1 net.ipv4.conf.lo.hidden=1Después se pueden crear alias de los clústeres de la forma normal, como:
# ifconfig lo:1 $CLUSTER_ADDRESS netmask 255.255.255.255 up
# sysctl -w net.ipv4.conf.all.arp_ignore=3 net.ipv4.conf.all.arp_announce=2A continuación, debe crear alias a los clústeres con el siguiente mandato:
# ip addr add $CLUSTER_ADDRESS/32 scope host dev loSe debe especificar un mandato similar en los scripts go* de la configuraciones con ubicación compartida de alta disponibilidad.
# iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECTEste mandato hace que los sistemas Linux realicen una conversión de direcciones de red (NAT) de destino en cada paquete, que convierte la dirección del clúster en la dirección de interfaz. Este método tiene aproximadamente una penalización en el rendimiento del 6,4% de conexiones por segundo. Este método funciona en cualquier distribución de stock soportada; no es necesario ningún módulo kernel ni aplicar parche, compilarlo e instalarlo en el kernel.
# modprobe noarp # noarpctl add $CLUSTER_ADDRESS dir_primaria_nicdonde dir_primaria_nic es una dirección en la misma subred que la dirección de clúster. Después se pueden crear alias de los clústeres de la forma normal, como:
# ifconfig lo:1 dirección_clúster netmask 255.255.255.255 up
En esta parte se proporciona información sobre la configuración de inicio rápido, consideraciones de planificación y describe los métodos para configurar el componente CBR de Load Balancer. Contiene los capítulos siguientes:
En este ejemplo de inicio rápido se muestra cómo configurar tres estaciones de trabajo conectadas localmente utilizando CBR junto con Caching Proxy para equilibrar la carga del tráfico Web entre dos servidores Web. (Para simplicidad, este ejemplo ilustra servidores en el mismo segmento LAN, no obstante, con CBR no hay restricción para utilizar servidores en la misma LAN).
Figura 16. Configuración local sencilla de CBR
Para el ejemplo de inicio rápido, necesitará tres estaciones de trabajo y cuatro direcciones IP. Se utiliza una estación de trabajo como máquina CBR; las otras dos se utilizarán como servidores Web. Cada servidor Web requiere una dirección IP. La estación de trabajo CBR requiere una dirección real y una dirección donde se va a equilibrar la carga.
Para utilizar CBR, Caching Proxy debe estar instalado en el mismo servidor. Para configurar Caching Proxy para CBR, consulte el apartado Paso 1. Configurar Caching Proxy para que pueda utilizar CBR.
Estación de trabajo | Nombre | Dirección IP |
---|---|---|
1 | servidor1.misitioWeb.com | 9.27.27.101 |
2 | servidor2.misitioWeb.com | 9.27.27.102 |
3 | servidor3.misitioWeb.com | 9.27.27.103 |
Máscara de red = 255.255.255.0 |
Cada una de las estaciones de trabajo sólo contiene una tarjeta de interfaz de red Ethernet estándar.
Nombre= www.misitioWeb.com IP=9.27.27.104
Con CBR, puede crear una configuración mediante la línea de mandatos, el asistente de configuración o la GUI (Interfaz gráfica de usuario). Para este ejemplo de inicio rápido, los pasos de configuración se demuestran utilizando la línea de mandatos.
Desde un indicador de mandatos, siga estos pasos:
cbrcontrol executor start
ibmproxy
cbrcontrol cluster add www.misitioweb.com
cbrcontrol port add www.misitioweb.com:80
cbrcontrol server add www.misitioweb.com:80:server2.misitioweb.com
cbrcontrol server add www.misitioweb.com:80:server3.misitioweb.com
cbrcontrol rule add www.misitioweb.com:80:memberRule type content pattern uri=*/member/*
cbrcontrol rule add www.misitioweb.com:80:guestRule type content pattern uri=*/guest/*
En este ejemplo, utilizando la regla de contenido, las peticiones del cliente al sitio Web www.misitioWeb.com se envían a un servidor distinto según un directorio en su vía de acceso de la petición del URI. Consulte el Apéndice B. Sintaxis de la regla de contenido (patrón) para obtener más información.
cbrcontrol rule useserver www.misitioweb:80:memberRule server2.misitioweb.com
cbrcontrol rule useserver www.misitioweb:80:guestRule server3.misitioweb.com
CBR ahora equilibrará la carga según la regla basada en contenido. Los clientes con peticiones de URL que contengan /member/ se dirigirán a servidor2.misitioWeb.com. Los clientes con peticiones de URL que contengan /guest/ se dirigirán a servidor3.misitioWeb.com.
cbrcontrol manager start
cbrcontrol advisor start http 80
Ahora CBR se asegurará de que las peticiones del cliente no se envíen a un servidor Web que haya dado un error.
Ya se ha completado la configuración básica con los servidores conectados localmente.
Compruebe si la configuración funciona:
cbrcontrol server report www.misitioweb.com:80:La columna de conexiones totales de los dos servidores debería sumarse a "2."
Para obtener información sobre el uso de la GUI de CBR, consulte los apartados GUI y Apéndice A. GUI: instrucciones generales.
Si desea información sobre cómo utilizar el asistente de CBR, consulte el apartado Asistente de configuración.
Hay muchos modos de configurar CBR para dar soporte a su sitio. Si sólo tiene un nombre de host para el sitio al que se conectarán todos sus clientes, puede definir un solo clúster de servidores. Para cada uno de estos servidores, configure el puerto a través del que CBR se comunica. Vea la Figura 9.
Figura 17. Ejemplo de CBR configurado con un solo clúster y 2 puertos
En este ejemplo del componente CBR, se define un clúster en www.productworks.com. Este clúster tiene dos puertos: el puerto 80 para HTTP y el puerto 443 para SSL. Un cliente que solicita http://www.productworks.com (puerto 80) va a un servidor distinto que un cliente que solicita https://www.productworks.com (puerto 443).
Podría resultar adecuado otro modo de configurar CBR si tiene un sitio de un tamaño muy grande con muchos servidores dedicados a cada protocolo admitido. En este caso, quizá desee definir un clúster para cada protocolo con un solo puerto pero con muchos servidores, como se muestra en la Figura 10.
Figura 18. Ejemplo de CBR configurado con dos clústeres, cada uno con un puerto
En este ejemplo del componente CBR, se definen dos clústeres: www.productworks.com para el puerto 80 (HTTP) y www.testworks.com para el puerto 443 (SSL).
Podría ser necesario un tercer modo de configurar CBR si el sitio alberga el contenido de varias empresas o departamentos, en el que cada uno entra al sitio con un URL distinto. En este caso, quizá desee definir un clúster para cada empresa o departamento y luego definir los puertos en los que va a recibir conexiones en ese URL, como se muestra en la Figura 11.
Figura 19. Ejemplo de CBR configurado con 2 clústeres, cada uno con 2 puertos
En este ejemplo del componente CBR, se definen dos clústeres con el puerto 80 (HTTP) y el puerto 443 (SSL) para cada uno de los sitios en www.productworks.com y www.testworks.com.
En este capítulo se describe lo que debería tener en cuenta el planificador de la red antes de instalar y configurar el componente CBR con Caching Proxy.
Este capítulo incluye los siguientes apartados:
El componente CBR permite equilibrar la carga de tráfico HTTP y SSL con Caching Proxy para dirigir mediante proxy la petición. Con CBR, puede equilibrar la carga de servidores que puede configurar desde el archivo de configuración de CBR utilizando mandatos cbrcontrol.
CBR es muy similar a Dispatcher en su estructura de componentes. CBR consta de las funciones siguientes:
La utilización del gestor es opcional. No obstante, si no se utiliza el gestor, se realiza el equilibrio de carga utilizando la planificación de turno rotativo sopesado según los pesos del servidor actual y no estarán disponibles los asesores.
Las tres funciones clave de CBR (ejecutor, gestor y asesores) actúan conjuntamente para equilibrar y entregar las peticiones entrantes entre servidores. Junto con las peticiones de equilibrio de carga, el ejecutor supervisa el número de conexiones nuevas y de conexiones activas y suministra esta información al gestor.
El componente CBR proporciona la posibilidad de especificar un conjunto de servidores que gestionarán peticiones basándose en expresiones regulares comparadas con el contenido de la petición de cliente. CBR permite particionar el sitio de modo que conjuntos de servidores distintos pueden atender contenidos o servicios de aplicaciones distintos. Este particionamiento es transparente a clientes que acceden a su sitio.
Un modo de dividir su sitio sería asignar algunos servidores para gestionar sólo peticiones cgi y otro conjunto de servidores para gestionar todas las demás peticiones. Esto impide que el cálculo intensivo de scripts cgi ralentice los servidores para el tráfico de HTML normal, lo que permite a los clientes obtener un mejor tiempo de respuesta global. Con el uso de este esquema, también podría asignar estaciones de trabajo más completas para peticiones normales. Esto proporcionaría a los clientes un mejor tiempo de respuesta sin los gastos de actualizar todos los servidores. También podría asignar estaciones de trabajo más completas para peticiones cgi.
Otra posibilidad para particionar su sitio podría ser dirigir a los clientes que acceden a las páginas que requieren registrarse a un conjunto de servidores y todas las demás peticiones a un segundo conjunto de servidores. Esto impediría que navegadores eventuales de su sitio acapararan recursos que podrían utilizarlos clientes que se hayan comprometido con su registro. También le permitiría utilizar estaciones de trabajo más completas para atender a los clientes que se han registrado.
Podría por supuesto combinar los métodos anteriores para obtener aún más flexibilidad y un servicio mejorado.
Dado que CBR permite especificar varios servidores para cada tipo de petición, se puede equilibrar la carga de los servidores para obtener una respuesta al cliente óptima. Si permite que se asignen varios servidores a cada tipo de contenido, estará protegido si una estación de trabajo o un servidor da un error. CBR reconocerá el error y seguirá equilibrando la carga de peticiones de cliente con los otros servidores del conjunto.
Caching Proxy comunica con un proceso CBR mediante esta interfaz del plug-in. Para que esto funcione, CBR debe ejecutarse en la máquina local. Dado que estos son dos procesos aparte, puede haber varias instancias de Caching Proxy ejecutándose y trabajando con una sola instancia de CBR. Se podría establecer esta configuración con el fin de segregar direcciones o funcionalidad entre Caching Proxies o para mejorar la utilización de recursos de la máquina teniendo varios Caching Proxies gestionando el tráfico de clientes. Las instancias del proxy se pueden detectar en puertos distintos o enlazarse a direcciones IP únicas en el mismo puerto, en función de lo que mejor se ajuste a los requisitos de tráfico.
CBR junto con Caching Proxy examina las peticiones HTTP utilizando los tipos de reglas especificados. Cuando se ejecuta, Caching Proxy acepta peticiones de cliente y consulta al componente CBR cuál es el mejor servidor. En esta consulta, CBR compara la petición con un conjunto de reglas con prioridades. Cuando se cumple una regla, se selecciona el servidor adecuado entre un conjunto de servidores preconfigurados. Finalmente, CBR informa a Caching Proxy del servidor que ha seleccionado y la petición se dirige mediante el proxy ahí.
Después de definir un clúster para el equilibrio de carga, debe asegurarse de que todas las peticiones a ese clúster tienen una regla que seleccionará un servidor. Si no se ha encontrado ninguna regla que cumpla una petición en particular, el cliente recibirá una página de error del Caching Proxy. El modo más sencillo de asegurarse de que todas las peticiones cumplirán alguna regla es crear una regla "siempre cierta" con un número de prioridad muy alto. Asegúrese de que los servidores utilizados por esta regla puedan gestionar todas las peticiones no gestionadas explícitamente por las reglas que tienen una prioridad con un número inferior. (Nota: las reglas con un número de prioridad inferior se evalúan primero).
Para obtener más información, consulte el apartado Configuración del equilibrio de carga basado en reglas.
CBR con Caching Proxy puede recibir la transmisión SSL del cliente al proxy (en el sentido del cliente al proxy) así como dar soporte a la transmisión del proxy al servidor SSL (en el sentido del proxy al servidor). Si define un puerto SSL en un servidor en la configuración de CBR para recibir la petición SSL del cliente, tiene la posibilidad de mantener un sitio completamente seguro, utilizando CBR para equilibrar la carga entre servidores seguros (SSL).
Además de otros cambios en el archivo ibmproxy.conf para CBR, es necesario añadir otra sentencia de configuración al archivo ibmproxy.conf para Caching Proxy con el fin de habilitar el cifrado SSL en el sentido del proxy al servidor. El formato debe ser:
proxy patrón_uri patrón_url dirección
donde patrón_uri es un patrón de coincidencia (por ejemplo: /secure/*), patrón_url es una URL de sustitución (por ejemplo: https://clusterA/secure/*) y dirección es la dirección de clúster (por ejemplo: clusterA).
CBR con Caching Proxy también puede recibir la transmisión SSL del cliente y a continuación descifrar la petición SSL antes de dirigir mediante proxy la petición a un servidor HTTP. Para que CBR proporcione soporte de cliente a proxy en SSL y de proxy a servidor en HTTP, hay una palabra clave opcional mapport en el mandato del servidor cbrcontrol. Utilice esta palabra clave cuando necesite indicar que el puerto en el servidor es distinto del puerto de entrada del cliente. A continuación figura un ejemplo para añadir un puerto utilizando la palabra clave mapport, donde el puerto del cliente es 443 (SSL) y el puerto del servidor es 80 (HTTP):
cbrcontrol server add cluster:443 mapport 80
El número de puerto de mapport puede ser cualquier valor entero positivo. El valor predeterminado es el número de puerto del puerto de entrada del cliente.
Puesto que CBR debe ser capaz de asesorar sobre una petición HTTP de un servidor configurado en el puerto 443 (SSL), se proporciona un asesor especial ssl2http . Este asesor comienza en el puerto 443 (el puerto de entrada del cliente) y asesora sobre el servidor o los servidores configurados para ese puerto. Si hay dos clústeres configurados y cada clúster tiene el puerto 443, además los servidores están configurados con un mapport distinto, entonces una sola instancia del asesor puede abrir el puerto adecuado de modo correspondiente. A continuación figura un ejemplo de esta configuración:
Executor Cluster1 Port:443 Server1 mapport 80 Server2 mapport 8080 Cluster2 Port:443 Server3 mapport 80 Server4 mapport 8080 Manager Advisor ssl2http 443
Antes de llevar a cabo los pasos de este capítulo, consulte el apartado Planificación de CBR (Content Based Routing). En este capítulo se explica cómo crear una configuración básica para el componente CBR de Load Balancer.
Antes de empezar a realizar los pasos de configuración indicados en esta tabla, asegúrese de que la máquina CBR y todas las máquinas de servidores están conectadas a la red, tienen direcciones IP válidas y que pueden enviar una sonda de paquetes Internet entre sí.
Tabla 10. Tareas de configuración para el componente
CBR
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina CBR. | Averigua los requisitos. | Configuración de la máquina CBR |
Configurar máquinas en las que se va a equilibrar la carga. | Configura la configuración de equilibrio de carga. | Paso 7. Definir máquinas servidor con equilibrio de carga |
Existen cuatro métodos básicos para crear una configuración básica para el componente CBR de Load Balancer:
Para utilizar CBR, tiene que haber instalado Caching Proxy.
Es la manera más directa de configurar CBR. Los valores de los parámetros de mandatos deben especificarse en caracteres del idioma inglés. Las únicas excepciones son los nombres de host (se utiliza, por ejemplo, en los mandatos de clúster y servidor) y los nombres de archivo.
Para iniciar CBR desde la línea de mandatos:
En sistemas Windows: pulse Inicio > Configuración (en Windows 2000) > Panel de control > Herramientas administrativas > Servicios. Pulse con el botón derecho del ratón en IBM Content Based Routing y seleccione Iniciar. Para detener el servicio, efectúe los mismos pasos y seleccione Detener.
Puede entrar una versión abreviada de los parámetros del mandato cbrcontrol. Sólo es necesario especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir cbrcontrol he f en lugar de cbrcontrol help file.
Para iniciar la interfaz de línea de mandatos, emita cbrcontrol para obtener un indicador de mandatos cbrcontrol.
Para finalizar la interfaz de línea de mandatos, emita exit o quit.
Notas:
( ) paréntesis derecho e izquierdo
& ampersand
| barra vertical
! signo de exclamación
* asterisco
El shell del sistema operativo puede interpretarlos como caracteres especiales y convertirlos en texto alternativo antes de que cbrcontrol los evalúe.
Los caracteres especiales en la lista anterior son caracteres opcionales del mandato cbrcontrol rule add y se utilizan cuando se especifica un patrón para una regla de contenido. Por ejemplo, el siguiente mandato sólo puede ser válido cuando se utiliza el indicador cbrcontrol>>.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*
Para que este mismo mandato funcione en el indicador del sistema operativo, el patrón debe indicarse entre dos signos de comillas (" ") de la forma indicada a continuación:
cbrcontrol rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Si no se utilizan las comillas, alguna parte del patrón puede truncarse cuando la regla se guarda en CBR. Tenga en cuenta que las comillas no están soportadas cuando se utiliza el indicador de mandatos cbrcontrol>>.
Los mandatos para configurar CBR pueden especificarse y ejecutarse juntos en un archivo de script de configuración.
cbrcontrol file appendload miscript
cbrcontrol file newload miscript
Para guardar la configuración actual en un archivo de script (por ejemplo, guardascript), ejecute el siguiente mandato:
cbrcontrol file save guardascript
Este mandato guardará el archivo de script de configuración en el directorio ...ibm/edge/lb/servers/configurations/cbr.
Para obtener instrucciones generales y un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 41.
Para iniciar la GUI, siga estos pasos
Para configurar el componente CBR desde la GUI, primero debe seleccionar Content Based Routing en la estructura de árbol. Inicie el gestor después de conectarse a un host. También puede crear clústeres que contengan puertos y servidores, así como iniciar asesores para el gestor.
La GUI puede utilizarse para llevar a cabo las mismas tareas que realizaría con el mandato cbrcontrol. Por ejemplo, para definir un clúster mediante la línea de mandatos, especifique el mandato cbrcontrol cluster add clúster. Para definir un clúster desde la GUI, pulse con el botón derecho del ratón en Ejecutor y, en el menú emergente, pulse Añadir clúster. Escriba la dirección del clúster en la ventana emergente y pulse Aceptar.
Los archivos de configuración de CBR preexistentes pueden cargarse con las opciones Cargar nueva configuración (para sustituir completamente la configuración actual) y Añadir a la configuración actual (para actualizar la configuración actual) que aparecen el menú emergente Host. Debe guardar de forma periódica la configuración de CBR en un archivo con la opción Guardar archivo de configuración como que también se encuentra en el menú emergente Host. El menú Archivo situado en la parte superior de la GUI, permite guardar en un archivo las conexiones actuales del host o restaurar conexiones que se encuentran en archivos existentes en todos los componentes de Load Balancer.
Para acceder a la Ayuda, pulse el icono de signo de interrogación situado en la esquina superior derecha de la ventana de Load Balancer.
Para poder ejecutar un mandato desde la GUI: resalte el nodo Host en el árbol de la GUI y seleccione Enviar mandato... en el menú emergente Host. En el campo de entrada de mandatos, escriba el mandato que desea ejecutar, por ejemplo: executor report. Aparecerán en la ventana proporcionada los resultados y el historial de los mandatos ejecutados en la sesión actual.
Para obtener más información sobre cómo utilizar la GUI, consulte el Apéndice A. GUI: instrucciones generales.
Si va a utilizar el asistente de configuración, siga estos pasos:
Inicie este asistente desde el indicador de mandatos emitiendo cbrwizard. O bien, seleccione el Asistente de configuración desde el menú del componente CBR como se presenta en la GUI.
En sistemas AIX, HP-UX, Linux o Solaris: para iniciar Caching Proxy, escriba ibmproxy
En sistemas Windows: para iniciar Caching Proxy, vaya al panel Servicios: Inicio > Configuración (para Windows 2000) > Panel de control > Herramientas administrativas > Servicios.
El asistente CBR le guiará, paso a paso, a través del proceso de creación de una configuración básica para el componente CBR. Formula preguntas sobre la red y le guía mientras define un clúster que permite a CBR equilibrar la carga de tráfico entre un grupo de servidores.
Para configurar la máquina CBR, debe ser el usuario root (en sistemas AIX, HP-UX, Linux o Solaris) o el administrador (en los sistemas Windows).
Es necesaria una dirección IP válida para cada clúster de servidores que se configure. Una dirección de clúster es una dirección asociada con un nombre de host (como www.empresa.com). El cliente utilizará esta dirección IP para conectarse a los servidores de un clúster. En concreto, esta dirección se encuentra en la petición de URL del cliente. CBR equilibra la carga de todas las peticiones realizadas en la misma dirección de clúster.
Sólo para sistemas Solaris: antes de utilizar el componente CBR, deben modificarse los valores predeterminados del sistema para IPC (comunicación entre procesos). Es necesario aumentar el tamaño máximo de un segmento de memoria compartida y el número de identificadores de semáforos. Para ajustar el sistema de modo que dé soporte a CBR, edite el archivo /etc/system en el sistema y añada las siguientes sentencias y rearranque:
set shmsys:shminfo_shmmax=0x02000000 set semsys:seminfo_semmap=750 set semsys:seminfo_semmni=30 set semsys:seminfo_semmns=750 set semsys:seminfo_semmnu=30 set semsys:seminfo_semume=30
Si no aumenta el segmento de memoria compartida hasta los valores indicados más arriba, el mandato cbrcontrol executor start no se ejecutará correctamente.
Para utilizar CBR, tiene que haber instalado Caching Proxy.
Debe realizar las siguientes modificaciones en el archivo de configuración de Caching Proxy (ibmproxy.conf):
Verifique que la directiva de URL entrante CacheByIncomingUrl tiene el valor "off" (valor predeterminado).
En la sección de reglas de correlación del archivo de configuración, para cada clúster, añada una regla de correlación parecida a la siguiente:
Proxy /* http://cluster.domain.com/* cluster.domain.com
Hay cuatro entradas que deben editarse para el plug-in de CBR:
A continuación se muestran las adiciones específicas realizadas en el archivo de configuración para cada uno de los sistemas operativos.
Figura 20. Archivo de configuración de CBR para sistemas AIX, Linux y Solaris
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.so:ndServerTerm
Figura 21. Archivo de configuración de CBR para sistemas HP-UX
ServerInit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerInit PostAuth /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostAuth PostExit /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndPostExit ServerTerm /opt/ibm/edge/lb/servers/lib/liblbcbr.sl:ndServerTerm
Figura 22. Archivo de configuración de CBR para sistemas Windows
ServerInit C:\Archivos de programa\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerInit PostAuth C:\Archivos de programa\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostAuth PostExit C:\Archivos de programa\IBM\edge\lb\servers\lib\liblbcbr.dll:ndPostExit ServerTerm C:\Archivos de programa\IBM\edge\lb\servers\lib\liblbcbr.dll:ndServerTerm
Para iniciar la función de servidor de CBR, escriba cbrserver en la línea de mandatos.
Un archivo de configuración predeterminado (default.cfg) se carga de forma automática al iniciar cbrserver. Si decide guardar la configuración de CBR en default.cfg, todo lo que se guarde en este archivo se carga automáticamente la próxima vez que se inicie cbrserver.
Para iniciar la función de ejecutor, escriba el mandato cbrcontrol executor start. En este momento también puede cambiar varios valores del ejecutor. Consulte el apartado dscontrol executor -- controlar el ejecutor.
CBR equilibrará las peticiones enviadas para el clúster a los servidores correspondientes configurados en los puertos para dicho clúster.
El clúster es el nombre simbólico situado en la parte del host del URL y debe coincidir con el nombre utilizado en la sentencia Proxy del archivo ibmproxy.conf.
Los clústeres definidos en CBR deben definirse de modo que coincidan con la petición entrante. Un clúster debe definirse con el mismo nombre de host o la misma dirección IP que la petición entrante que incluirá. Por ejemplo, si la petición se entra como la dirección IP, el clúster debe definirse como la dirección IP. Si hay más de un nombre de host que se resuelve en una sola dirección IP (y las peticiones pueden llegar con cualquiera de estos nombres de host), todos los nombres de host deben definirse como clústeres.
Para definir un clúster, emita el siguiente mandato:
cbrcontrol cluster add clúster
Para establecer las opciones del clúster, emita el siguiente mandato:
cbrcontrol cluster set clúster opción valor
Para obtener más información, consulte el apartado Referencia de mandatos para Dispatcher y CBR.
Si ejecuta Caching Proxy configurado como proxy de retroceso, cuando se equilibra la carga para varios sitios web, debe añadir la dirección del clúster para cada sitio Web a, como mínimo, una de las tarjetas de interfaz de red de la máquina Load Balancer. De lo contrario, puede omitir este paso.
En sistemas AIX, HP-UX, Linux o Solaris: para añadir la dirección del clúster a la interfaz de red, utilice el siguiente mandato ifconfig. Utilice el mandato correspondiente a su sistema operativo tal como se muestra en la Tabla 11.
Tabla 11. Mandatos para crear alias
para la NIC
AIX | ifconfig nombre_interfaz alias dirección_clúster netmask máscara_red |
HP-UX | ifconfig nombre_interfaz dirección_clúster netmask máscara_red up |
Linux | ifconfig nombre_interfaz dirección_clúster netmask máscara_red up |
Solaris 8, Solaris 9 y Solaris 10 | ifconfig nombre_interfaz addif dirección_clúster netmask máscara_red up |
En sistemas Windows 2000: para añadir la dirección de clúster a la interfaz de red, haga lo siguiente:
En sistemas Windows 2003: para añadir la dirección de clúster a la interfaz de red, haga lo siguiente:
El número de puerto es el puerto en el que escuchan las aplicaciones del servidor. Para CBR con Caching Proxy ejecutando tráfico HTTP, es normalmente el puerto 80.
Para definir un puerto para el clúster definido en el paso anterior, emita el siguiente mandato:
cbrcontrol port add clúster:puerto
Para establecer las opciones del puerto, emita el siguiente mandato:
cbrcontrol port set clúster:puerto opción valor
Para obtener más información, consulte el apartado Referencia de mandatos para Dispatcher y CBR.
Las máquinas servidor son las máquinas que ejecutan las aplicaciones en las que se desea realizar el equilibrio de carga. El servidor es el nombre simbólico o dirección decimal con puntos de la máquina servidor. Para definir un servidor en el clúster y puerto, emita el siguiente mandato:
cbrcontrol server add clúster:puerto:servidor
Debe definir más de un servidor por puerto en un clúster para llevar a cabo el equilibrio de carga.
Este es el paso clave en la configuración de CBR con Caching Proxy. Una regla define cómo una petición de URL se distinguirá y se enviará a un servidor del conjunto de servidores adecuado. El tipo de regla especial utilizado por CBR se denomina regla de contenido. Para definir una regla de contenido, emita el siguiente mandato:
cbrcontrol rule add clúster:puerto:regla type content pattern patrón
El valor patrón es la expresión regular que se compara con el URL en cada petición de cliente. Para obtener más información sobre cómo configurar el patrón, consulte el Apéndice B. Sintaxis de la regla de contenido (patrón).
En CBR también se pueden utilizar algunos otros tipos de reglas definidos en Dispatcher. Para obtener más información, consulte el apartado Configuración del equilibrio de carga basado en reglas.
Cuando una regla coincide con una petición de cliente, se consulta el conjunto de servidores de la regla para saber qué servidor es el mejor. El conjunto de servidores de la regla es un subconjunto de los servidores definidos en el puerto. Para añadir servidores a un conjunto de servidores de una regla, emita el siguiente mandato:
cbrcontrol rule useserver clúster:puerto:servidor de reglas
La función de gestor mejora el equilibrio de carga. Para iniciar el gestor, emita el siguiente mandato:
cbrcontrol manager start
Los asesores proporcionan al gestor más información sobre la capacidad que tienen de las máquinas de servidor con equilibrio de carga para responder a las peticiones. Un asesor es específico de un protocolo. Por ejemplo, para iniciar el asesor HTTP, emita el siguiente mandato:
cbrcontrol advisor start http puerto
Si inicia asesores, puede modificar la proporción de la importancia dada a la información de asesor que se incluye en las decisiones para el equilibrio de carga. Para definir las proporciones del clúster, emita el mandato cbrcontrol cluster set clúster proportions. Para obtener más información, consulte el apartado Proporción de la importancia otorgada a la información de estado
/opt/ibm/edge/lb/servers/lib
/opt/ibm/edge/lb/servers/lib
C:\Archivos de programa\IBM\edge\lb\servers\lib
En el nuevo entorno, inicie Caching Proxy: en el indicador de mandatos, emita ibmproxy
Para configurar CBR, siga estos pasos:
Esta parte proporciona información sobre la configuración de inicio rápido, consideraciones de planificación y describe los métodos para configurar el componente Site Selector de Load Balancer. Contiene los capítulos siguientes:
En este ejemplo de inicio rápido se muestra cómo crear una configuración de nombre de sitio con Site Selector para el tráfico de equilibrio de carga entre un conjunto de servidores según el nombre de dominio utilizado en una petición de cliente.
Figura 23. Configuración sencilla
de Site Selector
Para este ejemplo de configuración de inicio rápido, necesitará lo siguiente:
Para este ejemplo de inicio rápido, el dominio del sitio de la empresa es mitiendaweb.com. Site Selector se encarga de un subdominio dentro de mitiendaweb.com. Por lo tanto, tendrá que definir un subdominio dentro de mitiendaweb.com. Por ejemplo: apps.mitiendaweb.com. Site Selector no es un DNS completamente implementado, como BIND y actúa como un nodo hoja en una jerarquía de DNS. Site Selector tiene autoridad para el subdominio apps.mitiendaweb.com. El subdominio apps.mitiendaweb.com incluirá los nombres de sitio siguientes: marketing.apps.mitiendaweb.com y desarrollo.apps.mitiendaweb.com.
apps.mitiendaweb.com. IN NS siteselector.mitiendaweb.com
Con Site Selector, puede crear una configuración mediante la línea de mandatos, el asistente de configuración o la interfaz gráfica de usuario (GUI). Para este ejemplo de inicio rápido, los pasos de configuración se demuestran utilizando la línea de mandatos.
Desde un indicador de mandatos, siga estos pasos:
sscontrol nameserver start
sscontrol sitename add marketing.apps.mitiendaweb.com
sscontrol sitename add developer.apps.mitiendaweb.com
sscontrol server add marketing.apps.mitiendaweb.com:servidor1+servidor2
sscontrol server add developer.apps.mitiendaweb.com:servidor3+servidor4
sscontrol manager start
sscontrol advisor start http marketing.apps.mitiendaweb.com:80
sscontrol advisor start ftp developer.apps.mitiendaweb.com:21
Site Selector ahora se asegurará de que no se envíen las peticiones de cliente a un servidor con anomalías.
Ya se ha completado la configuración básica de Site Selector.
Compruebe si la configuración funciona:
sscontrol server status marketing.apps.mitiendaweb.com:
sscontrol server status developer.apps.mitiendaweb.com:
La entrada de total de aciertos de cada servidor debería sumarse al ping y a la petición de aplicación.
Para obtener información sobre el uso de la GUI de Site Selector, consulte los apartados GUI y Apéndice A. GUI: instrucciones generales.
Si desea información sobre cómo utilizar el asistente de Site Selector, consulte el apartado Asistente de configuración.
En este capítulo se describe lo que debe tener en cuenta el planificador de la red antes de instalar y configurar el componente Site Selector.
Este capítulo incluye los apartados siguientes:
Site Selector funciona junto con un servidor de nombres de dominio para realizar el equilibrio de carga entre un grupo de servidores utilizando medidas y pesos que se recopilan. Puede crear una configuración del sitio que le permita equilibrar la carga del tráfico entre un grupo de servidores basándose en el nombre de dominio utilizado para la petición de un cliente.
Limitaciones: Site Selector únicamente da soporte a las consultas DNS de tipo A. Cualquier otro tipo de consulta generará un código de retorno NOTIMPL (no se implementa). Si todo el dominio se delega a Site Selector, asegúrese de que el dominio sólo reciba consultas de tipo A.
Figura 24. Ejemplo de un entorno DNS
Cuando se configura un subdominio para Site Selector dentro del entorno de DNS, Site Selector debe tener autoridad sobre su propio subdominio. Por ejemplo (consulte la Figura 24), se ha asignado a su empresa autoridad sobre el dominio empresa.com. Dentro de la empresa, hay varios subdominios. Site Selector tendría autoridad de siteload.empresa.com, mientras que el servidor o los servidores DNS seguirán manteniendo la autoridad de atlanta.empresa.com y boston.empresa.com .
Para que el servidor de nombres de la empresa reconozca que Site Selector tiene autoridad del subdominio siteload, será necesario añadir una entrada de servidor de nombres al archivo de datos nombrado. Por ejemplo, en sistemas AIX, un servidor de nombres se parecería a lo siguiente:
siteload.empresa.com. IN NS siteselector.empresa.com.
Donde siteselector.empresa.com es el nombre de host de la máquina Site Selector. Sería necesario crear entradas equivalentes en cualquier otro archivo de base de datos nombrado para que los servidores DNS lo utilicen.
Un cliente somete una petición de resolución de un nombre de dominio a un servidor de nombres dentro de su red. El servidor de nombres reenvía la petición al sistema Site Selector. Site Selector luego soluciona el nombre de dominio con la dirección IP de uno de los servidores que se han configurado bajo el nombre de sitio. Site Selector devuelve la dirección IP del servidor seleccionado al servidor de nombres. El servidor de nombres devuelve la dirección IP al cliente. (Site Selector actúa como un servidor de nombres no recursivo (nodo hoja) y devolverá un error si no resuelve la petición de nombre de dominio).
Consulte la Figura 5 que ilustra un sitio en el que se utiliza Site Selector junto con un sistema de DNS para equilibrar la carga entre servidores locales y remotos.
Site Selector consta de estas funciones:
La utilización del gestor es opcional. No obstante, si no se utiliza el gestor, se realiza el equilibrio de carga utilizando la planificación de turno rotativo sopesado según los pesos del servidor actual y no estarán disponibles los asesores.
Con Metric Server, Site Selector puede supervisar el nivel de actividad de un servidor, detectar si un servidor tiene la carga menos pesada o si un servidor está anómalo. La carga es una medición del esfuerzo del servidor. El administrador Site Selector de sistema controla el tipo de medida utilizado para medir la carga. Puede configurar Site Selector de modo que se adapte a su entorno, teniendo en cuenta factores como la frecuencia de acceso, el número total de usuarios y los tipos de acceso (por ejemplo, consultas breves, consultas de larga ejecución o cargas con mucha utilización de la CPU).
El equilibrio de carga se realiza según los pesos del servidor. Para Site Selector, hay cuatro proporciones que el gestor utiliza para determinar pesos:
Metric Server suministra todos los valores de CPU y memoria. Por consiguiente, se recomienda el uso de Metric Server con el componente Site Selector.
Consulte el apartado Metric Server para obtener más información.
Las cuatro funciones clave de Site Selector (servidor de nombres, gestor, Metric Server y asesores) interactúan para equilibrar y solucionar las peticiones de entrada entre servidores.
El uso del equilibrio de carga según el DNS requiere que se inhabilite la colocación en memoria caché de la resolución de nombres. El valor de TTL (tiempo de vida) determina la eficacia del equilibrio de carga según el DNS. TTL determina cuándo tiempo otro servidor de nombres colocará en memoria caché la respuesta resuelta. Valores de TTL pequeños permiten que cambios pequeños en la carga del servidor o de red se realicen de forma más ágil. No obstante, para inhabilitar la colocación en memoria caché se requiere que los clientes se pongan en contacto con el servidor de nombres autorizado para todas las peticiones de resolución de nombres, así se aumenta potencialmente la latencia del cliente. Cuando se selecciona un valor de TTL, debería tenerse en cuenta el impacto que tendrá sobre el entorno la inhabilitación de la memoria caché. Tenga en cuenta también que el equilibrio de carga según el DNS se puede limitar por la colocación en memoria caché del cliente de las resoluciones de nombres.
Se puede configurar TTL utilizando el mandato sscontrol sitename [add | set] . Consulte el apartado sscontrol sitename -- configurar un nombre de sitio para obtener más información.
La proximidad de red es el cálculo de la cercanía de cada servidor al cliente solicitante. Para determinar la proximidad de red, el agente Metric Server (que debe residir en cada servidor con equilibrio de carga) envía un ping a la dirección IP cliente y devuelve el tiempo de respuesta a Site Selector. Site Selector utiliza la respuesta de proximidad en la decisión de equilibrio de carga. Site Selector combina el valor de respuesta de proximidad de red con el peso del gestor para crear un valor de peso final combinado para el servidor.
El uso de la característica proximidad de red con Site Selector es opcional.
Site Selector proporciona estas opciones de proximidad de red que se pueden establecer por nombre de sitio:
Si se establece en sí, Metric Server ejecuta ping en el cliente para obtener el tiempo de respuesta de proximidad. El servidor de nombres espera a que todos los Metric Servers respondan o a que se exceda el tiempo de espera. Luego, para cada servidor, el servidor de nombres combina el tiempo de respuesta de proximidad con el peso que ha calculado del gestor para crear un valor de "peso combinado" para cada servidor. Site Selector suministrará al cliente la dirección IP del servidor con la mejor combinación de peso. (Se espera para la mayoría de servidores de nombres de cliente que tengan un tiempo de espera de 5 segundos. Site Selector intenta responder antes de que se supere el tiempo de espera).
Si se establece en no, se proporciona al cliente una resolución de nombres según los pesos del gestor actuales. A continuación, Metric Server ejecuta ping en el cliente para obtener el tiempo de respuesta de la proximidad. El servidor de nombres coloca en memoria caché el tiempo de respuesta que recibe de Metric Server. Cuando el cliente vuelve por una segunda petición, el servidor de nombres combina el peso del gestor actual con el valor de respuesta del mandato ping colocado en memoria caché para que cada servidor obtenga el servidor con el mejor "peso combinado". Site Selector devuelve esta dirección IP del servidor al cliente para la segunda petición.
Se pueden establecer las opciones de proximidad de red en el mandato sscontrol sitename [add | set] . Consulte el apartado Referencia de mandatos para Site Selector para obtener más información.
Antes de llevar a cabo los pasos de este capítulo, consulte el apartado Planificación para Site Selector. En este capítulo se explica cómo crear una configuración básica para el componente Site Selector de Load Balancer.
Tabla 12. Tareas de configuración para el componente Site Selector
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Site Selector. | Averigua los requisitos. | Configuración de la máquina Site Selector |
Configurar máquinas en las que se va a equilibrar la carga. | Configura la configuración de equilibrio de carga. | Paso 4. Definir máquinas servidor con equilibrio de carga |
Para crear una configuración básica para el componente Site Selector de Load Balancer, hay cuatro métodos básicos para configurar el componente Site Selector:
Es la manera más directa de configurar Site Selector. Los valores de los parámetros de mandatos deben especificarse en caracteres del idioma inglés. Las únicas excepciones son los nombres de host (se utiliza, por ejemplo, en los mandatos de nombre de sitio y servidor) y los nombres de archivo.
Para iniciar Site Selector desde la línea de mandatos:
Puede escribir una versión minimizada de los parámetros del mandato sscontrol. Sólo es necesario especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir sscontrol he f en lugar de sscontrol help file.
Para iniciar la interfaz de línea de mandatos, emita sscontrol para recibir un indicador de mandatos de sscontrol.
Para finalizar la interfaz de línea de mandatos, emita exit o quit.
Los mandatos para configurar Site Selector pueden especificarse y ejecutarse juntos en un archivo de script de configuración.
sscontrol file appendload miscript
sscontrol file newload miscript
Para guardar la configuración actual en un archivo de script (por ejemplo, guardascript), ejecute el siguiente mandato:
sscontrol file save guardascript
Este mandato guardará el archivo de script de configuración en el directorio ...ibm/edge/lb/servers/configurations/ss.
Para obtener instrucciones y un ejemplo de la GUI, consulte la Figura 41.
Para iniciar la GUI, siga estos pasos
Para configurar el componente Site Selector desde la GUI, primero debe seleccionar Site Selector en la estructura de árbol. Una vez que se ha conectado a un ssserver que se ejecuta en un host, puede crear nombres de sitio que contiene servidores, iniciar el gestor e iniciar los asesores.
La GUI puede utilizarse para llevar a cabo las mismas tareas que realizaría con el mandato sscontrol. Por ejemplo, para definir un nombre de sitio con la línea de mandatos, especifique el mandato sscontrol sitename add nombre_sitio. Para definir un nombre de sitio desde la GUI, pulse con el botón derecho del ratón en Servidor de nombres y, a continuación, en el menú emergente, pulse con el botón izquierdo del ratón en Añadir nombre de sitio. Escriba el nombre del sitio en la ventana emergente y pulse Aceptar.
Los archivos de configuración de Site Selector preexistentes pueden cargarse con las opciones Cargar nueva configuración (para sustituir completamente la configuración actual) y Añadir a la configuración actual (para actualizar la configuración actual) que aparecen el menú emergente Host. Debe guardar de forma periódica la configuración de Site Selector en un archivo con la opción Guardar archivo de configuración como que también se encuentra en el menú emergente Host. El menú Archivo situado en la parte superior de la GUI, permite guardar en un archivo las conexiones actuales del host o restaurar conexiones que se encuentran en archivos existentes en todos los componentes de Load Balancer.
Para ejecutar un mandato desde la GUI: resalte el nodo Host en el árbol de la GUI y seleccione Enviar mandato.... en el menú emergente Host. En el campo de entrada de mandatos, escriba el mandato que desea ejecutar, por ejemplo: nameserver status. Aparecerán en la ventana proporcionada los resultados y el historial de los mandatos ejecutados en la sesión actual.
Para acceder a la Ayuda, pulse el icono de signo de interrogación situado en la esquina superior derecha de la ventana de Load Balancer.
Para obtener más información sobre cómo utilizar la GUI, consulte el Apéndice A. GUI: instrucciones generales.
Si va a utilizar el asistente de configuración, siga estos pasos:
ssserver
Inicie este asistente desde el indicador de mandatos; para ello, emita el mandato sswizard. O bien, seleccione el Asistente de configuración desde el menú del componente Site Selector como se presenta en la GUI.
El asistente de Site Selector le guiará, paso a paso, a través del proceso de creación de una configuración básica para el componente Site Selector. Formula preguntas sobre la red y le guía mientras define un nombre de sitio que permite a Site Selector equilibrar la carga de tráfico entre un grupo de servidores.
Para configurar la máquina Site Selector, debe ser el usuario root (en sistemas AIX, HP-UX, Linux o Solaris) o el administrador (en los sistemas Windows).
Necesitará un nombre de host que no es posible resolver para utilizarlo como nombre de sitio para el grupo de servidores que configura. El nombre de sitio es el nombre que los clientes utilizan para acceder al sitio (como www.suempresa.com). Site Selector equilibrará la carga del tráfico de este nombre de sitio entre el grupo de servidores mediante DNS.
Para iniciar la función de servidor de Site Selector, escriba ssserver en la línea de mandatos.
Para iniciar el servidor de nombres, escriba el mandato sscontrol nameserver start.
De forma opcional, inicie el servidor de nombres utilizando la palabra clave bindaddress para establecer el enlace únicamente con la dirección especificada.
Site Selector equilibrará las peticiones enviadas para el nombre del sitio a los servidores correspondientes configurados para ello.
El nombre de sitio es un nombre de host que no es posible resolver y que solicitará el cliente. El nombre del sitio debe ser un nombre de dominio plenamente cualificado (por ejemplo, www.dnsdownload.com). Cuando un cliente solicita este nombre de sitio, se devuelve una de las direcciones IP de servidor asociadas con este nombre.
Para definir un nombre de sitio, emita el siguiente mandato:
sscontrol sitename add nombre_sitio
Para establecer las opciones del nombre de sitio, emita el siguiente mandato:
sscontrol sitename set nombre_sitio opción valor
Para obtener más información, consulte el apartado Referencia de mandatos para Site Selector.
Las máquinas servidor son las máquinas que ejecutan las aplicaciones en las que se desea realizar el equilibrio de carga. El servidor es el nombre simbólico o dirección decimal con puntos de la máquina servidor. Para definir un servidor en el nombre de sitio desde el paso 3, emita el siguiente mandato:
sscontrol server add nombre_sitio:servidor
Para poder realizar el equilibrio de carga, debe definir más de un servidor bajo un nombre de sitio.
La función de gestor mejora el equilibrio de carga. Antes de iniciar la función de gestor, asegúrese de que Metric Server está instalado en todas las máquinas con equilibrio de carga.
Para iniciar el gestor, emita el siguiente mandato:
sscontrol manager start
Los asesores proporcionan al gestor más información sobre la capacidad que tienen de las máquinas de servidor con equilibrio de carga para responder a las peticiones. Un asesor es específico de un protocolo. Load Balancer ofrece muchos asesores. Por ejemplo, para iniciar el asesor HTTP para un nombre de sitio específico, emita el siguiente mandato:
sscontrol advisor start http nombre_sitio:puerto
Consulte el apartado Metric Server para obtener información sobre la utilización de métrica de sistema y Metric Server.
Si inicia asesores, puede modificar la proporción de la importancia dada a la información (puerto) de asesor que se incluye en las decisiones para el equilibrio de carga. Para definir las proporciones del nombre de sitio, emita el mandato sscontrol sitename set nombre_sitio proportions. Para obtener más información, consulte el apartado Proporción de la importancia otorgada a la información de estado
Utilice Metric Server con el componente Site Selector. Consulte el apartado Metric Server para obtener información sobre cómo configurar Metric Server en todas las máquinas de servidor en las que Site Selector está realizando el equilibrio de carga.
En esta parte se proporciona información sobre la configuración de inicio rápido, consideraciones de planificación y describe los métodos para configurar el componente Cisco CSS Controller de Load Balancer. Contiene los capítulos siguientes:
Este ejemplo de inicio rápido muestra cómo crear una configuración mediante el componente Cisco CSS Controller. Cisco CSS Controller proporciona información de pesos del servidor que ayuda al conmutador Cisco CSS a determinar la selección de servidor óptima para decisiones de equilibrio de carga.
Figura 25. Configuración sencilla de Cisco CSS Controller
Para este ejemplo de configuración de inicio rápido, necesitará lo siguiente:
Asegúrese de se completan estos pasos antes de comenzar la configuración de este ejemplo:
Con Cisco CSS Controller, puede crear una configuración mediante la línea de mandatos o la interfaz gráfica de usuario (GUI). Para este ejemplo de inicio rápido, los pasos de configuración se demuestran utilizando la línea de mandatos.
Desde un indicador de mandatos, siga estos pasos:
ccocontrol consultant add SwConsultant-1 address 9.17.32.50 community public
Esto comprobará la conectividad con el conmutador Cisco CSS y verificará que el nombre de comunidad de lectura-grabación SNMP funcione correctamente.
ccocontrol ownercontent add SwConsultant-1:OwnerContent-1 ownername OwnerName-1 contentrule ContentRule-1
Estos valores deben coincidir con los atributos correspondientes en el conmutador Cisco CSS.
Cisco CSS Controller puede ahora comunicarse con el conmutador en SNMP y obtendrá la información de configuración necesaria del conmutador. Después de este paso, aparecerá información en Cisco CSS Controller acerca de qué servicios están configurados en el conmutador Cisco CSS para el ownercontent especificado.
ccocontrol ownercontent metrics SwConsultant-1:OwnerContent-1 activeconn 45 connrate 45 http 10
Este mandato configurará qué información de métrica y proporción desea recopilar de los servicios que se va a utilizar para el cálculo de peso. La proporción total de todas las métricas debe ser igual a 100.
ccocontrol consultant start SwConsultant-1
Con este mandato, se iniciarán todos los recopiladores de métricas y comenzarán los cálculos de peso de servicio. Cisco CSS Controller comunica el resultado de sus cálculos de peso de servicio al conmutador Cisco CSS mediante SNMP.
La configuración básica de Cisco CSS Controller ahora está completa.
Compruebe si la configuración funciona:
Para obtener información sobre el uso de la GUI de Cisco CSS Controller, consulte los apartados GUI y Apéndice A. GUI: instrucciones generales.
En este capítulo se describe lo que debe tener en cuenta el planificador de la red antes de instalar y configurar el componente Cisco CSS Controller.
Este capítulo incluye:
Si desea obtener los requisitos de hardware y software, visite la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
También necesitará
Cisco CSS Controller gestiona un conjunto de consultores de conmutador. Cada consultor determina pesos para servicios a los que un solo conmutador equilibra la carga. El conmutador para el que el consultor proporciona pesos se configura para equilibrar la carga del contenido. El consultor utiliza el protocolo SNMP para enviar los pesos calculados al conmutador. El conmutador utiliza los pesos para seleccionar un servicio para la regla de contenido que está equilibrando la carga cuando el algoritmo de equilibrio de carga es de turno rotativo sopesado. Para determinar los pesos, el consultor utiliza uno o más fragmentos de información:
Si desea una descripción del equilibrio de carga del contenido o información detallada sobre cómo configurar el conmutador, consulte el manual Cisco Content Services Switch Getting Started Guide.
Para que un consultor obtenga la información necesaria para determinar los pesos del servicio, debe tener:
Como se indica en la Figura 26, el consultor puede conectarse a la red detrás del conmutador o los conmutadores para los que aquél proporciona pesos. Algunos parámetros deben configurarse en el conmutador y otros en el controlador para habilitar la conectividad entre el controlador, el conmutador y los servicios.
En la Figura 26:
Si desea información detallada sobre cómo configurar redes VLAN y direccionamiento IP en el conmutador, consulte el manual Cisco Content Services Switch Getting Started Guide.
Figura 26. Ejemplo de un consultor conectado detrás de los conmutadores
Puede gestionar Cisco CSS Controller utilizando cualquiera de las interfaces siguientes:
Para la gestión remota, en la Figura 27:
Si desea información detallada, consulte el manual Cisco Content Services Switch Getting Started Guide.
La alta disponibilidad del controlador mejora las posibilidades de tolerancia a errores de Load Balancer. La alta disponibilidad del controlador, diseñado teniendo en cuenta la alta disponibilidad de reenvío de paquetes, implica dos controladores en ejecución a la vez, uno con la función de maestro y el otro con la función de secundario.
Cada controlador se configura con información de conmutador idéntica y sólo un controlador está activo en un momento dado. Esto significa que, como se determina por la lógica de alta disponibilidad, sólo el controlador activo calcula y actualiza el conmutador con los nuevos pesos.
La alta disponibilidad del controlador se comunica con su asociado utilizando paquetes UDP (User Datagram Protocol) sencillos en una dirección y puerto que puede configurar. Estos paquetes se utilizan para intercambiar información entre controladores dado que pertenece a alta disponibilidad (información de alcance) y para determinar la disponibilidad del controlador de asociados (pulsos). Si el controlador en espera determina que el controlador activo ha dado un error por cualquier motivo, el controlador en espera se hace con el control del controlador activo que ha dado el error. El controlador en espera ahora pasa a ser el controlador activo y comienza a calcular y a actualizar el conmutador con nuevos pesos.
Además de la disponibilidad de los asociados, se pueden configurar destinos de alcance para alta disponibilidad. La alta disponibilidad del controlador utiliza la información de alcance para determinar qué controlador está activo y cuál está en espera. El controlador activo es el que puede ejecutar ping en más destinos y es accesible desde su asociado.
Consulte el apartado Alta disponibilidad para obtener más información.
Si el consultor determina que un servicio no está disponible, suspenderá ese servicio en el conmutador para impedir que el conmutador tenga en cuenta el servidor cuando cargue peticiones de equilibrado. Cuando el servicio está disponible de nuevo, el consultor activa el servicio en el conmutador para que se considere en las peticiones de equilibrio de carga.
Cisco CSS Controller envía entradas a los archivos de anotaciones cronológicas siguientes:
Estos archivos de anotaciones cronológicas están ubicados en los directorios siguientes:
En cada archivo de anotaciones cronológicas, puede establecer su tamaño y el nivel de anotaciones. Consulte el apartado Utilización de los registros de Load Balancer para obtener más información.
Antes de llevar a cabo los pasos de este capítulo, consulte el apartado Planificación para Cisco CSS Controller. En este capítulo se explica cómo crear una configuración básica para el componente Cisco CSS Controller de Load Balancer.
Antes de llevar a cabo los métodos de configuración descritos en este capítulo:
Tabla 13. Tareas de configuración para el componente Cisco CSS Controller
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar la máquina Cisco CSS Controller | Averigua los requisitos | Configuración del controlador para la máquina Conmutadores Cisco CSS |
Probar la configuración | Confirma que la configuración funciona | Comprobación de la configuración |
Existen tres métodos para crear una configuración básica para el componente Cisco CSS Controller de Load Balancer:
Este método es la manera más directa de configurar Cisco CSS Controller. En los procedimientos de esta publicación se da por supuesto que se utiliza la línea de mandatos. Los valores de los parámetros de mandatos deben especificarse en caracteres del idioma inglés. Las únicas excepciones son los nombres de host (se utiliza, por ejemplo, en el mandato consultant add) y los nombres de archivo.
Para iniciar Cisco CSS Controller desde la línea de mandatos:
Notas:
Puede entrar una versión abreviada de los parámetros del mandato ccocontrol. Sólo es necesario especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir ccocontrol he f en lugar de ccocontrol help file.
Para iniciar la interfaz de línea de mandatos, emita ccocontrol para recibir un indicador de mandatos de ccocontrol.
Para finalizar la interfaz de línea de mandatos, emita exit o quit.
La configuración definida actualmente puede guardarse en un archivo XML. Esto permite cargar la configuración más adelante cuando desee volver a crear rápidamente la configuración.
Para ejecutar el contenido de un archivo XML (por ejemplo, miscript.xml), utilice cualquiera de los siguientes mandatos:
ccocontrol file save nombre_archivo_XML
ccocontrol file load nombre_archivo_XML
Utilice el mandato load sólo si ha ejecutado anteriormente un mandato file save.
Los archivos XML se guardan en el directorio ...ibm/edge/lb/servers/configurations/cco/.
Para obtener instrucciones generales y un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 41.
Para iniciar la GUI, siga estos pasos
ccoserver.
Para configurar el componente Cisco CSS Controller desde la GUI:
La GUI puede utilizarse para llevar a cabo las mismas tareas que realizaría con el mandato ccocontrol. Por ejemplo:
Para ejecutar un mandato desde la GUI:
El resultado y el historial de los mandatos que se ejecutan en la sesión actual aparecen en el recuadro Resultado.
Para acceder a la Ayuda, pulse el icono de signo de interrogación situado en la esquina superior derecha de la ventana de Load Balancer.
Para obtener más información sobre cómo utilizar la GUI, consulte el Apéndice A. GUI: instrucciones generales.
Antes de configurar la máquina Cisco CSS Controller, debe ser usuario root (en los sistemas AIX, HP-UX, Linux o Solaris) o el administrador (en los sistemas Windows).
El consultor debe poder conectarse al conmutador Cisco CSS como un administrador de Cisco CSS.
Al configurar el consultor, debe configurar la dirección y el nombre de comunidad SNMP de modo que coincida con los atributos correspondientes en el conmutador Cisco CSS.
Para obtener ayuda sobre los mandatos utilizados en este procedimiento, consulte el apartado Referencia de mandatos para Cisco CSS Controller.
Si ccoserver todavía no está en ejecución, escriba ccoserver como usuario root para iniciarlo.
Escriba ccocontrol para iniciar la interfaz de línea de mandatos.
Debe configurar la dirección del conmutador y el nombre de comunidad SNMP. Estos valores deben coincidir con los atributos correspondientes en el conmutador Cisco CSS.
Para añadir un consultor, escriba:
consultant add ID_consultor_conmutador address dirección_IP_conmutador community nombre_comunidad
Un contenido de propietario es una representación de una regla de contenido para un propietario, que está definido en el conmutador Cisco CSS. El nombre del propietario y el nombre de regla de contenido debe coincidir con lo definido en el conmutador.
Para definir un contenido de propietario, escriba:
ownercontent add ID_consultor_conmutador:ID_contenido_propietario ownername nombre_propietario contentrule nombre_regla_contenido
Cuando se define el contenido de propietario, el consultor realiza la configuración recuperando los servicios configurado en el conmutador. Compare la configuración del conmutador con la configuración del consultor para asegurarse de que los servicios coinciden.
La métrica son las medidas utilizadas para determinar los pesos de servicios y las proporciones asociadas (importancia de una métrica comparada con otra), y puede ser cualquier combinación de métrica de datos de conexiones, métrica de asesor de aplicaciones y métricas de Metric Server. Las proporciones siempre deben sumar 100.
Al configurar un contenido de propietario, la métrica predeterminada se define como activeconn y connrate. Si desea métricas adicionales o si desea métricas completamente distintas de los resultados, escriba:
ownercontent metrics ID_consultor_conmutador:ID_contenido_propietario métrica1 proporción1 métrica2 proporción2... métricaN proporciónN
Para iniciar el consultor, escriba:
consultant start ID_consultor_conmutador
Así se inician los recopiladores de métricas y empieza el cálculo del peso.
Si se ha definido la métrica del sistema en el paso 5, se debe iniciar Metric Server en las máquinas de servicio. Consulte el apartado Metric Server para obtener información sobre la utilización de Metric Server.
Para configurar la alta disponibilidad, escriba:
highavailability add address dirección_IP partneraddress dirección_IP port 80 role primario
En un entorno de alta disponibilidad, puede configurar varios conmutadores. Para asegurarse de que la información de peso siempre está disponible cuando un conmutador asumen el control de otro, Cisco CSS Controller debe configurarse para proporcionar pesos para todos los conmutadores y sus reservas.
Si desea información detallada sobre cómo utilizar y configurar la alta disponibilidad del controlador, consulte el apartado Características avanzadas de Cisco CSS Controller y Nortel Alteon Controller.
Compruebe si la configuración funciona:
En esta parte se proporciona información sobre la configuración de inicio rápido, consideraciones de planificación y describe los métodos para configurar el componente Nortel Alteon Controller de Load Balancer. Contiene los capítulos siguientes:
Este ejemplo de inicio rápido muestra cómo crear una configuración mediante el componente Nortel Alteon Controller. Nortel Alteon Controller proporciona pesos del servidor al conmutador Nortel Alteon Web. Estos pesos se utilizan para seleccionar servidores para servicios a los que el conmutador equilibra la carga.
Figura 28. Configuración sencilla de Nortel Alteon Controller
Para este ejemplo de configuración de inicio rápido, necesitará lo siguiente:
Asegúrese de se completan estos pasos antes de comenzar la configuración de este ejemplo:
Con Nortel Alteon Controller, puede crear una configuración mediante la línea de mandatos o la interfaz gráfica de usuario (GUI). Para este ejemplo de inicio rápido, los pasos de configuración se demuestran utilizando la línea de mandatos.
Desde un indicador de mandatos, siga estos pasos:
nalcontrol consultant add Consultant-1 address 9.87.32.50
Esto comprobará la conectividad con el conmutador Nortel Alteon Web y verificará que los nombres de comunidad SNMP funcionan correctamente.
nalcontrol service add Consultant-1:Service-1 vsid 1 vport 80
Nortel Alteon Controller se comunicará con el conmutador en SNMP y obtendrá la información de configuración necesaria del conmutador. Después de este paso, aparecerá información en Nortel Alteon Controller acerca de qué servidores están configurados en el conmutador Nortel Alteon Web para el servicio.
nalcontrol service metrics Consultant-1:Service-1 http 40 activeconn 30 connrate 30
Este mandato configurará qué información de métrica desea recopilar de los servidores y la importancia relativa de esas métricas durante el cálculo del peso.
nalcontrol consultant start Consultant-1
Con este mandato, se iniciarán todos los recopiladores de métricas y comenzarán los cálculos de peso de servidor. Nortel Alteon Controller comunica el resultado de sus cálculos de peso de servidor al conmutador Nortel Alteon Web mediante SNMP.
La configuración básica de Nortel Alteon Controller ahora está completa.
Compruebe si la configuración funciona:
Para obtener información sobre el uso de la GUI de Nortel Alteon Controller, consulte los apartados GUI y Apéndice A. GUI: instrucciones generales.
En este capítulo se describe lo que debe tener en cuenta el planificador de la red antes de instalar y configurar el componente Nortel Alteon Controller.
Este capítulo incluye:
Si desea obtener los requisitos de hardware y software, visite la siguiente página Web: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27006921
También necesitará
Nortel Alteon Controller gestiona un conjunto de consultores de conmutador. Cada consultor determina pesos para servidores a los que un solo conmutador equilibra la carga. El conmutador para el que el consultor proporciona pesos se configura para equilibrar la carga del servidor. El consultor utiliza el protocolo SNMP para enviar los pesos calculados al conmutador. El conmutador utiliza los pesos para seleccionar un servidor para el servicio al que está equilibrando la carga. Para determinar los pesos, el consultor utiliza uno o más fragmentos de información:
Si desea una descripción del equilibrio de carga del servidor o información detallada sobre cómo configurar el conmutador, consulte el manual Nortel Alteon Web OS Application Guide.
Para que un consultor obtenga la información necesaria para determinar los pesos del servidor, debe tener:
El consultor puede conectarse a la red delante o detrás del conmutador o los conmutadores para los que proporciona pesos. Algunos parámetros deben configurarse en el conmutador y otros en el controlador para habilitar la conectividad entre el controlador, el conmutador y los servidores.
En la Figura 29:
Consulte el manual Nortel Alteon Web OS Application Guide o Command Reference para obtener información detallada sobre cómo configurar las VLAN y el direccionamiento IP en el conmutador.
Figura 29. Ejemplo de un consultor conectado detrás del conmutador
En la Figura 30:
Figura 30. Ejemplo de consultor conectado mediante una intranet
delante de un conmutador
Puede gestionar Nortel Alteon Controller utilizando cualquiera de las interfaces siguientes:
En la Figura 31:
Figura 31. Ejemplo de consultor detrás del conmutador e interfaz de usuario delante del conmutador
Cuando un consultor calcula los pesos para servidores que proporcionan un servicio al que el conmutador equilibra la carga, el consultor inhabilita la comprobación normal de estado del servidor en el conmutador para reducir el tráfico innecesario en los servidores. El consultor vuelve a habilitar la comprobación de estado cuando deja de proporcionar pesos para el servicio. El intervalo de comprobación de estado del servidor corresponde a la variable MIB slbNewCgRealServerPingInterval.
Si el consultor determina que un servidor no está disponible, el consultor establece el número máximo de conexiones del servidor en cero para impedir que el conmutador tenga en cuenta el servidor cuando cargue peticiones de equilibrado. Cuando se pone de nuevo disponible el servidor, el número máximo de conexiones se restaura a su valor original. El valor máximo de conexiones del servidor corresponde a la variable MIB slbNewCfgRealServerMaxCons.
Cuando se calcula un peso para un servidor real, se establece el peso para el servidor. El valor de peso del servidor corresponde a la variable MIB slbNewCfgRealServerWeight.
El conmutador permite la configuración de varios servidores de reserva de otros. Si el conmutador determina que un servidor que tiene otro de reserva no está disponible, el conmutador debería empezar a enviar peticiones al de reserva. Cuando el consultor calcula pesos para un servicio con un servidor de reserva, calcula los pesos para los dos servidores, el de reserva y el primario y, posteriormente tiene pesos que va a utilizar para la selección de servidor cuando se requiera el de reserva.
El peso para el servidor de reserva podría ser mayor que el peso para un servidor primario. Esto es porque no se le reenvía ninguna petición, de modo que tiene pocas cargas hasta que el conmutador determina utilizarlo.
Para impedir que los recursos del servidor estén desocupados, es una práctica común que los servidores asignados a un servicio se utilicen de reserva de servidores asignados a un servicio distinto. Cuando implementa una configuración de este tipo, no asigne los mismos servidores reales a varios servicios activos a la vez. Si esto sucede, el consultor sobrescribirá el peso para el servidor para cada servicio del que es parte el servidor.
Cada servidor real se identifica por un entero y tiene un peso y un atributo de dirección IP. Dos servidores reales podrían tener la misma dirección IP. En este caso, se asocian dos servidores reales a la misma máquina servidor física. Los servidores reales identificados como reserva sólo deberían configurarse como reserva para un único servicio. Si las mismas máquinas servidor físicas harán de servidores de reserva asignadas a varios servicios, deberán configurarse una vez para cada servicio y se les dará una identificación de servidor que es única para cada servicio. Esto permite que los servidores de reserva tengan un único peso asignado a ellos para cada servicio del que hacen de reserva.
Figura 32. Ejemplo de consultor configurado con servidores de reserva
Los servidores en un conmutador se pueden configurar como parte de varios grupos y los grupos en el conmutador se pueden configurar con servicios de varios servicios.
Dado que se puede configurar el mismo servidor para varios servicios, el peso se calcula para cada servicio del que el servidor forma parte. Es posible, por lo tanto, que el peso sea incorrecto porque se desconoce en un momento dado el peso destinado al servicio.
Además, si el consultor determina pesos para un servicio y no para otro, es posible que el servicio para el que el consultor no calcula pesos tenga inhabilitada la comprobación de estado del servidor. En este caso, quizá el conmutador no equilibre correctamente la carga de ese servicio.
Debido a estas posibilidades, debe asegurarse de que no se asigna un servidor real a varios servicios de los que se está equilibrando la carga. Esto no significa que la misma máquina servidor no pueda atender peticiones de varios servicios. Significa que debe configurarse un servidor real con un identificador único en el conmutador para cada servicio para el que la máquina servidor gestionará peticiones.
Tanto Nortel Alteon Controller como el conmutador de Nortel Alteon Web tienen posibilidades de alta disponibilidad.
Puede configurar dos controladores para ejecutarse en sistemas distintos en una configuración de reposo dinámico.
Dos o más conmutadores pueden volver a activarse entre sí cuando los configura para actuar como VIR (direccionador de interfaz de IP virtual) o como VSR (direccionador de servidor IP virtual).
Un consultor (gestionado por el controlador) proporciona pesos para un conmutador únicamente. Debido a que un conmutador de reserva podría hacerse con el control del maestro, debe configurar el controlador con un consultor para cada conmutador que tenga la posibilidad de ser maestro. De este modo, cuando un conmutador pasa a ser maestro, se asegura que se le proporcionan pesos.
Además, cuando los controladores se conectan a un VIR, se asegura que tienen comunicación con los servidores, los conmutadores y el controlador de reserva, en caso de que se perdiera la conectividad con uno de los conmutadores.
Consulte el manual Nortel Alteon Web OS Application Guide para obtener información sobre alta disponibilidad en el conmutador.
La alta disponibilidad del controlador mejora las posibilidades de tolerancia a errores de Load Balancer. La alta disponibilidad del controlador, diseñado teniendo en cuenta la alta disponibilidad de reenvío de paquetes clásica, implica dos controladores en ejecución a la vez, uno con la función de maestro y el otro con la función de secundario.
Cada controlador se configura con información de conmutador idéntica. Similar a la alta disponibilidad clásica, sólo un controlador está activo en un momento dado. Esto significa que, como se determina por la lógica de alta disponibilidad, sólo el controlador activo calcula y actualiza el conmutador con los nuevos pesos.
La alta disponibilidad del controlador se comunica con su asociado utilizando paquetes UDP (User Datagram Protocol) sencillos en una dirección y puerto que puede configurar. Estos paquetes se utilizan para intercambiar información entre controladores dado que pertenece a alta disponibilidad (información de alcance) y para determinar la disponibilidad del controlador de asociados (pulsos). Si el controlador en espera determina que el controlador activo ha dado un error por cualquier motivo, el controlador en espera se hace con el control del controlador activo que ha dado el error. El controlador en espera ahora pasa a ser el controlador activo y comienza a calcular y a actualizar el conmutador con nuevos pesos.
Además de la disponibilidad de los asociados, se pueden configurar destinos de alcance para alta disponibilidad. Como con la alta disponibilidad clásica, la alta disponibilidad del controlador utiliza la información de alcance para determinar qué controlador está activo y cuál está en espera. El controlador activo es el que puede ejecutar ping en más destinos y es accesible desde su asociado.
Consulte el apartado Alta disponibilidad para obtener más información.
En la Figura 33:
Para impedir que el cambio de pesos se produzca muy a menudo, puede configurar el consultor con un umbral de sensibilidad. El umbral de sensibilidad especifica la cantidad de cambios que deben tener lugar entre los pesos antiguos y los nuevos antes de que el peso pueda cambiar. Consulte el apartado Umbral de sensibilidad para obtener más información.
Si el conmutador pasa a estar demasiado ocupado actualizando pesos, puede aumentar el tiempo de inactividad del consultor para reducir el tráfico entre el controlador y los servidores y el conmutador. El tiempo de inactividad establece el número de segundos de inactividad entre ciclos de establecimiento del peso.
Si los servidores gestionan demasiadas peticiones de supervisión del consultor, puede modificar el tiempo de inactividad de los recopiladores de métricas. Si desea una descripción detallada, consulte el apartado Tiempos de inactividad en el cálculo de pesos.
Cisco CSS Controller envía entradas a los archivos de anotaciones cronológicas siguientes:
Estos archivos de anotaciones cronológicas están ubicados en los directorios siguientes:
En cada archivo de anotaciones cronológicas, puede establecer su tamaño y el nivel de anotaciones. Consulte el apartado Utilización de los registros de Load Balancer para obtener más información.
Antes de llevar a cabo los pasos de este capítulo, consulte el apartado Planificación para Nortel Alteon Controller. En este capítulo se explica cómo crear una configuración básica para el componente Nortel Alteon Controller de Load Balancer.
Antes de llevar a cabo los métodos de configuración descritos en este capítulo, asegúrese de que el conmutador de Nortel Alteon Web y todas las máquinas de servidor se han configurado correctamente.
Tabla 14. Tareas de configuración para el componente Nortel Alteon Controller
Tarea | Descripción | Información relacionada |
---|---|---|
Configurar el conmutador Nortel Alteon Web y los servidores | Configurar el conmutador. | Configurar el conmutador, en la página (SETSWITCH) |
Configurar la máquina Nortel Alteon Controller | Configura el controlador. | Paso 1. Iniciar la función de servidor |
Probar la configuración | Confirma que la configuración funciona | Comprobación de la configuración |
Existen tres métodos para crear una configuración básica para el componente Nortel Alteon Controller de Load Balancer:
Se trata de la manera más directa de configurar Nortel Alteon Controller. En los procedimientos de esta publicación se da por supuesto que se utiliza la línea de mandatos.
Para iniciar Nortel Alteon Controller desde la línea de mandatos:
Notas:
Puede utilizar una versión abreviada de los parámetros del mandato nalcontrol escribiendo las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir nalcontrol he f en lugar de nalcontrol help file.
Para finalizar la interfaz de línea de mandatos, escriba exit o quit.
Notas:
La configuración definida actualmente puede guardarse en un archivo XML. Esto permite cargar la configuración más adelante cuando desee volver a crear rápidamente la configuración.
Para ejecutar el contenido de un archivo XML (por ejemplo, miscript.xml), utilice los siguientes mandatos:
nalcontrol file save nombre_archivo_XML
Utilice el mandato load sólo si ha ejecutado anteriormente un mandato file save.
nalcontrol file load nombre_archivo_XML
Utilice el mandato load sólo si ha ejecutado anteriormente un mandato file save.
Los archivos XML se guardan en el directorio ...ibm/edge/lb/servers/configurations/nal/.
Para ver un ejemplo de la interfaz gráfica de usuario (GUI), consulte la Figura 41.
Para iniciar la GUI:
Para configurar el componente Nortel Alteon Controller desde la GUI:
La GUI puede utilizarse para llevar a cabo las mismas tareas que realizaría con el mandato nalcontrol. Por ejemplo:
Para ejecutar un mandato desde la GUI:
El resultado y el historial de los mandatos que se ejecutan en la sesión actual aparecen en el recuadro Resultado.
Para acceder a la Ayuda, pulse el icono de signo de interrogación situado en la esquina superior derecha de la ventana de Load Balancer.
Para obtener más información sobre cómo utilizar la GUI, consulte el Apéndice A. GUI: instrucciones generales.
Para obtener ayuda sobre los mandatos utilizados en este procedimiento, consulte el apartado Referencia de mandatos para Nortel Alteon Controller.
Antes de configurar la máquina Nortel Alteon Controller:
Si nalserver todavía no está en ejecución, escriba nalserver como usuario root para iniciarlo.
Escriba nalcontrol para iniciar la interfaz de línea de mandatos.
Para añadir un consultor de conmutador, escriba:
consultant add ID_consultor_conmutador address dirección_IP_conmutador
Para añadir un servicio, escriba:
service add ID_consultor_conmutador:ID_servicio vsid ID_servidor_virtual vport número_puerto_virtual
Un servicio se identifica por identificador de servidor virtual (VSID) y un número de puerto virtual (VPORT). Los dos están asociados a un servidor virtual configurado anteriormente en el conmutador.
La métrica es la información utilizada para determinar los pesos de los servidores. A cada métrica se le asigna una proporción para indicar su importancia relativa a otra métrica. Puede configurarse cualquier combinación de métricas: métrica de datos de conexiones, métrica de asesor de aplicaciones y métrica de Metric Server. Las proporciones siempre deben sumar 100.
Al configurar un servicio, la métrica predeterminada se define como activeconn y connrate. Si desea métricas adicionales o si desea métricas completamente distintas de los resultados, escriba:
service metrics ID_consultor_conmutador:ID_servicio nombre_métrica 50 nombre_métrica2 50
Para iniciar el consultor, escriba:
consultant start ID_consultor_conmutador
Así se inician los recopiladores de métricas y empieza el cálculo del peso.
Para configurar la alta disponibilidad, escriba:
highavailability add address dirección_IP partneraddress dirección_IP port 80 role primario
Si desea información detallada sobre cómo utilizar y configurar la alta disponibilidad del controlador, consulte el apartado Características avanzadas de Cisco CSS Controller y Nortel Alteon Controller.
Si se ha definido la métrica del sistema en el paso 5, se debe iniciar Metric Server en las máquinas de servicio. Consulte el apartado Metric Server para obtener información sobre la utilización de Metric Server.
Si modifica la configuración del conmutador de Nortel Alteon Web, puede renovar la configuración del controlador. Escriba:
service refresh
Antes de renovar la configuración, detenga el consultor. Una vez que el mandato de renovación actualiza la configuración, reinicie el consultor.
Compruebe si la configuración funciona:
Esta parte proporciona información sobre funciones y características de configuración avanzada que están disponibles para Load Balancer. Contiene los capítulos siguientes:
En este capítulo se explica cómo configurar los parámetros de equilibrio de carga y cómo configurar las funciones del gestor, de los asesores y de Metric Server de Load Balancer.
Tabla 15. Tareas de configuración avanzada 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:
| Optimización del equilibrio de carga que proporciona 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 puede personalizar cuando el gestor marca 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 petición 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 petición 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 del 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 del sistema a Load Balancer | Metric Server |
Utilizar el asesor del gestor de carga de trabajo (WLM) | El asesor WLM proporciona información de carga del sistema a Load Balancer | Asesor del gestor de carga de trabajo |
La función de gestor 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 gestor puede tener en cuenta algunos de los siguientes factores externos o todos cuando se sopesan las decisiones:
O --
CPU: el porcentaje de la CPU en uso en cada máquina servidor con equilibrio de carga (entrada del agente de Metric Server). En Site Selector, esta proporción aparece en lugar de la columna de proporción de conexiones activas.
O --
Memoria: el porcentaje de la memoria en uso (entrada del agente de Metric Server) en cada servidor con equilibrio de carga. En Site Selector, esta proporción aparece en lugar de la columna de proporción de conexiones nuevas.
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.
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 sea necesario probar distintas proporciones hasta encontrar la combinación que ofrezca el mejor rendimiento.
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 el apartado dscontrol cluster -- configurar clústeres para obtener más información.
Los pesos los establece la función de gestor basándose en contadores internos del ejecutor, información procedente de los asesores e información procedente de un programa de supervisión del sistema, como 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 el apartado Pesos fijos del gestor.
Los pesos se aplican a todos los servidores de un puerto. Para cualquier puerto concreto, las peticiones 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 peticiones 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 peticiones que cada servidor obtendrá. Si establece el valor máximo de ponderación en 1, todos los servidores podrán tener el peso 1, 0 si están desactivados temporalmente o -1 si se han marcado como inactivos. Cuando se incrementa este número, aumentará la diferencia entre el peso que se puede otorgar a los servidores. Si establece el valor máximo de ponderación en 2, un servidor podría obtener el doble de peticiones que otro. Si establece el valor máximo de ponderación en 10, un servidor podría obtener diez veces más peticiones que otro. El valor máximo predeterminado de ponderación 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. En el caso de que hubiera alguna conexión activa con dicho servidor antes de cambiar el peso, se dejará que finalice normalmente.
Si todos los servidores están inactivos, el gestor establece los pesos a la mitad de la ponderación.
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 clúster:puerto:servidor 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 del servidor permanece fijo mientras el gestor se está ejecutando hasta que se emite otro mandato dscontrol server con la opción fixedweight establecida en no. Para obtener más información, consulte el apartado dscontrol server -- configurar servidores.
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.
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 capacidad 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 el apartado Reintento del asesor para obtener más información.
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 emitiendo 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 peticiones 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.
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 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.
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 peticiones. Por ejemplo, un servidor puede acabar recibiendo la mayoría de las peticiones 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 peticiones. 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.
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 de instalación ...ibm/edge/lb/servers/samples. Para ejecutar los archivos, debe ponerlos en el directorio ...ibm/edge/lb/servers/bin 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 petición. 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:
Los asesores son agentes incluidos en 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 da soporte al concepto de un asesor personalizado que permite a los usuarios escribir sus propios asesores.
Límites a la utilización de aplicaciones de servidor específicas del 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.
En sistemas HP-UX y Solaris existe una limitación en la utilización de aplicaciones de servidor específicas del enlace: Si utiliza el mandato arp publish en lugar del mandato ifconfig alias, Load Balancer permitirá el 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 utilicen asesores para la aplicación de servidor específico del enlace, Load Balancer no puede compartir la misma ubicación en la misma máquina con la aplicación de servidor.
-DLB_ADV_SRC_ADDR=dirección_IP
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 gestor, donde aparece en el informe del 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á más conexiones a dicho servidor hasta que el servidor no vuelva a estar en funcionamiento.
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 ha definido Load Balancer con tres clústeres (clústerA, clústerB, clústerC), cada uno con el puerto 80, puede hacer lo siguiente:
dscontrol advisor start http clústerA:80Este mandato iniciará el asesor HTTP en el puerto 80 para clústerA. El asesor HTTP asesorará sobre todos los servidores conectados al puerto 80 para clústerA.
dscontrol advisor start ADV_personalizado 80Este mandato iniciará el asesor ADV_personalizado en el puerto 80 para clústerB y clústerC. El asesor personalizado asesorará sobre todos los servidores conectados al puerto 80 para clusterB y clústerC. (Para obtener más información sobre asesores personalizados, consulte el apartado Crear asesores personalizados (personalizables)).
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 (clusterB y clústerC).
dscontrol advisor stop ADV_personalizado clústerB:80
dscontrol advisor stop ADV_personalizado 80
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.
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 del asesor no exceden el tiempo de espera: el valor predeterminado es unlimited.
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
Si desea más información sobre cómo establecer el tiempo de espera de informe del asesor, consulte el apartado dscontrol advisor -- controlar el asesor.
En Load Balancer, puede establecer los valores de tiempo de espera del asesor en el que detecta que un puerto particular en el 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 de servidor anómalo más rápida, 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 intervalo del gestor y asesor en el valor más pequeño (un segundo).
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.
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
La opción URL para el asesor HTTP o HTTPS está disponible para los componentes Dispatcher y CBR.
Después de iniciar un asesor HTTP o HTTPS, puede definir una serie URL HTTP de cliente exclusiva, específica para el servicio que desea examinar 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 el apartado 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 examinar 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:
server set clúster:puerto:servidor advisorrequest "head / http/1.0" server set clúster:puerto:servidor advisorresponse "HTTP 200 OK"
dscontrol server set clúster:puerto:servidor advisorrequest "\"head / http/1.0\"" dscontrol server set clúster:puerto:servidor advisorresponse "\"HTTP 200 OK\""
Cuando cree la petición que el asesor HTTP o HTTPS envía a servidores de programa de fondo para comprobar si están funcionando, escriba el comienzo de la petición HTTP y Load Balancer completará el final de la petición con lo siguiente:
\r\nAccept: */*\r\nUser-Agent:IBM_Network_Dispatcher_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 petición, también puede hacerlo incluyendo su propia serie \r\n en la petición. 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 petición:
GET /pub/WWW/TheProject.html HTTP/1.0 \r\nHost: www.w3.org
Consulte el apartado dscontrol server -- configurar servidores para obtener más información.
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 34. Ejemplo de una configuración WAN de dos niveles que utiliza el asesor automático
En este ejemplo, el asesor automático junto con Metric Server reside en las dos máquinas Dispatcher sobre las que Load Balancer realiza el equilibrio de carga 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 sistemas Dispatcher) devuelve a Load Balancer el valor del estado de la carga de nivel superior para que la utilice para determinar a qué sistema Dispatcher reenviar las peticiones de cliente.
El dsload ejecutable reside en el directorio ...ibm/edge/lb/ms/script de Load Balancer.
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 el apartado Metric Server para obtener más información sobre Metric Server.
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 el directorio de instalación
...<directorio_instalación>/servers/samples/CustomAdvisors.
El valor predeterminado del directorio de instalación es:
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.
Los archivos de asesor personalizado de ejemplo para el asesor WebSphere Application Server (WAS) se proporcionan en el directorio de instalación de Load Balancer.
Los archivos de ejemplo del asesor de WebSphere Application Server se encuentran en el mismo directorio de ejemplo que el archivo ADV_sample.java.
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_sample" dentro del archivo por el número 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 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 de instalación ...ibm/edge/lb/servers/lib/CustomAdvisors.
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:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_fred.class
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.
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.
A continuación se indican los métodos de clase base:
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.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Archivos de programa\IBM\edge\lb\servers\lib\CustomAdvisors
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 ...ibm/edge/lb/servers/samples/CustomAdvisors .
Esta característica está disponible para todos los componentes de Load Balancer.
Metric Server proporciona información de carga de servidor para Load Balancer en la forma de métricas específicas del sistema que notifica el estado de los servidores. El gestor de Load Balancer examina el agente de Metric Server que reside en cada uno de los servidores y asigna pesos al proceso de equilibrio de carga utilizando la métrica recopilada desde los agentes. Los resultados también aparecen en el informe del gestor.
Para obtener información sobre el funcionamiento de Metric Server (inicio y detención) y la utilización de los archivos de anotaciones de Metric Server, consulte el apartado Utilización del componente Metric Server.
Para obtener un ejemplo de configuración, consulte la Figura 5.
Al igual que el asesor WLM, Metric Server informa sobre los sistemas de servidor como un conjunto, en lugar de hacerlo en daemons de servidor individuales específicos del protocolo. Tanto WLM como Metric Server colocan sus resultados en la columna de sistema del informe del gestor. Como consecuencia, no se permite la ejecución simultánea del asesor WLM y de Metric Server
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 Dispatcher. Para configurar Metric Server para los demás componentes de Load Balancer puede utilizar un procedimiento parecido.
puerto es el puerto RMI seleccionado para que se ejecuten todos los agentes de Metric Server. El puerto RMI predeterminado establecido en el archivo metricserver.cmd es 10004.
métricaSistema es el nombre del script (que reside en el servidor de programa de fondo) que debe ejecutarse en cada uno de los servidores de la configuración bajo el clúster (o nombre de sitio) especificado. Se proporcionan dos scripts para el cliente, cpuload y memload. O si lo desea, puede crear scripts de métrica de sistema personalizados. El script contiene un mandato que debe devolver un valor numérico comprendido en el rango 0-100 o el valor -1 si el servidor está inactivo. Este valor numérico debe representar una medida de carga, no un valor de disponibilidad.
Limitación: en la plataforma Windows, si la extensión del nombre del script de métrica del sistema tiene una extensión distinta de ".exe", debe especificar el nombre completo del archivo (por ejemplo, "miscriptsistema.bat"). Se debe a una limitación de Java.
De manera opcional, los clientes pueden 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 script personalizados son ejecutables y que están en el directorio ...ibm/edge/lb/ms/script. Los scripts personalizados deben devolver un valor de carga numérico comprendido entre 0 y 100.
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.
En 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).
WLM es el código que se ejecuta en hosts MVS. Puede consultarse para saber la carga de 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 carga del sistema. 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 obtenidas se colocan en la columna Sistema del informe del gestor.
Hay varias diferencias importantes entre el asesor WLM y los demás asesores de Dispatcher.
Al igual que el agente de Metric Server, el agente de WLM informa sobre los sistemas de servidor como un conjunto, en lugar de hacerlo en daemons de servidor individuales específicos del protocolo. Metric Server y WLM colocan sus resultados en la columna de sistema del informe del gestor. Como consecuencia, no se permite la ejecución simultánea del asesor WLM y de Metric Server
En este capítulo se explica cómo configurar los parámetros de equilibrio de carga así como las funciones avanzadas de Load Balancer.
Tabla 16. Tareas de configuración avanzada para Load Balancer
Tarea | Descripción | Información relacionada |
---|---|---|
Poner en ubicación compartida Load Balancer en una máquina que tiene equilibrio de carga | Configura una máquina Load Balancer con ubicación compartida. | Utilización de servidores con ubicación compartida |
Configurar alta disponibilidad o alta disponibilidad mutua | Configura una segunda máquina Dispatcher para proporcionar una máquina de reserva. | Alta disponibilidad |
Configurar el equilibrio de carga basado en reglas | Define las condiciones en las que se utiliza un conjunto de servidores. | Configuración del equilibrio de carga basado en reglas |
Utilizar la alteración temporal de la afinidad entre puertos para proporcionar un mecanismo para que un servidor altere la característica de permanencia en memoria. | Permite a un servidor alterar el valor de permanencia en memoria en este puerto. | Alteración temporal de la afinidad entre puertos |
Utilizar característica de permanencia en memoria (afinidad) para configurar el puerto de un clúster para que sea permanente en memoria | Permite dirigir al mismo servidor las peticiones de cliente. | Cómo funciona la característica de afinidad para Load Balancer |
Utilizar afinidad entre puertos para expandir la característica de permanencia en memoria(afinidad) entre los puertos | Permite dirigir al mismo servidor las peticiones de cliente que se reciben en distintos puertos. | Afinidad entre puertos |
Utilizar máscara de dirección de afinidad para designar una dirección de subred IP común | Permite dirigir al mismo servidor las peticiones de cliente que se reciben en la misma subred. | Máscara de dirección de afinidad (stickymask) |
Utilizar afinidad de cookies activos para equilibrar la carga en servidores de CBR | Una opción de regla que permite que una sesión mantenga afinidad para un servidor concreto. | Afinidad de cookies activos |
Utilizar afinidad de cookies pasivos para equilibrar la carga en servidores con direccionamiento basado en contenido de Dispatcher y el componente CBR | Una opción de regla que permite que una sesión mantenga afinidad para un servidor concreto en función del valor de cookie/nombre de cookie. | Afinidad de cookies pasivos |
Utilizar la afinidad de URI para equilibrar la carga en los servidores Caching Proxy con contenido exclusivo para almacenarlo en la memoria caché de cada uno de ellos | Una opción de regla que permite que una sesión mantenga afinidad para un servidor concreto en función del URI. | Afinidad de URI |
Configurar el soporte de Dispatcher de red de área amplia | Configura un Dispatcher remoto para equilibrar la carga en toda una red de área amplia. O bien, equilibra la carga en toda una red de área amplia (sin un Dispatcher remoto) utilizando una plataforma de servidor que dé soporte a GRE. | Configurar soporte de Dispatcher de área amplia |
Utilizar enlace explícito | Evita que Dispatcher se pase por alto en los enlaces. | Utilización del enlace explícito |
Utilizar una red privada | Configura Dispatcher para equilibrar la carga en los servidores de una red privada. | Utilización de una configuración de red privada |
Utilizar un clúster comodín para combinar configuraciones de servidores comunes | Las direcciones que no se han configurado de forma explícita utilizarán el clúster comodín como una forma de equilibrar la carga del tráfico. | Utilizar un clúster comodín para combinar configuraciones de servidores |
Utilizar clúster comodín cara equilibrar la carga de cortafuegos | Se equilibrará la carga de todo el tráfico en cortafuegos. | Utilizar un clúster comodín para equilibrar la carga de cortafuegos |
Utilizar el clúster comodín con Caching Proxy para un proxy transparente | Permite utilizar Dispatcher para habilitar un proxy transparente. | Utilizar el clúster comodín con Caching Proxy para un proxy transparente |
Utilizar puerto comodín para dirigir tráfico de puerto no configurado | Maneja el tráfico que no está configurado para cualquier puerto específico. | Utilizar el puerto comodín para dirigir el tráfico de puerto no configurado |
Utilizar la detección de "ataques para rechazo de servicio" (DoS) para notificar a los administradores (mediante una alerta) los ataques potenciales | Dispatcher analiza peticiones entrantes para una cantidad llamativa de conexiones TCP medio abiertas en servidores. | Detección de ataques para rechazo de servicio (DoS) |
Utilizar el registro cronológico binario para analizar estadísticas de servidor | Permite almacenar en archivos binarios la información del servidor y recuperarla. | Utilización del registro cronológico binario para analizar estadísticas de servidor |
Utilizar una configuración de cliente con ubicación compartida | Permite a Load Balancer residir en la misma máquina que un cliente | Utilización de un cliente con ubicación compartida |
Load Balancer puede residir en la misma máquina que un servidor para el que equilibre la carga de las peticiones. Esto se conoce habitualmente como ubicación compartida de un servidor. La ubicación compartida se aplica a los componentes Dispatcher y Site Selector. La ubicación compartida también se admite en CBR, pero sólo cuando utiliza servidores Web específicos del enlace y Caching Proxy específico del enlace.
Sistemas Linux: para configurar la ubicación compartida y la alta disponibilidad a la vez cuando se ejecuta el componente Dispatcher utilizando el método de reenvío MAC, consulte el apartado Alternativas de alias de bucle de retorno de Linux cuando se utiliza el reenvío MAC de Load Balancer.
Sistemas Windows: para configurar la ubicación compartida y la alta disponibilidad a la vez cuando se ejecuta el componente Dispatcher utilizando el método de reenvío MAC, consulte el apartado Configurar la ubicación compartida y la alta disponibilidad (sistemas Windows).
Sistemas Solaris: existe una limitación; no pueden configurarse asesores WAN cuando Dispatcher de punto de entrada tiene ubicación compartida. Consulte el apartado Utilización de asesores remotos con el soporte de área amplia de Dispatcher.
En releases anteriores, era necesario especificar que la dirección del servidor con ubicación compartida fuera la misma que la dirección de no reenvío (NFA) en la configuración. Esta restricción ya no existe.
Para configurar un servidor para que forme parte de una ubicación compartida, el mandato dscontrol server proporciona una opción llamada collocated que puede establecerse en yes o no. El valor predeterminado es no. La dirección del servidor debe ser una dirección IP válida de una tarjeta de interfaz de red de la máquina. El parámetro collocated no debe establecerse para servidores con ubicación compartida que utilizan el método de reenvío NAT o CBR de Dispatcher.
Puede configurar un servidor con ubicación compartida de una de las siguientes maneras:
Para el reenvío NAT o CBR de Dispatcher, debe configurar (crear un alias) una dirección de adaptador no utilizada en la NFA. El servidor debe configurarse de modo que escuche en esta dirección. Configure el servidor con la siguiente sintaxis de mandato:
dscontrol server add clúster:puerto:nuevo_alias address nuevo_alias router ip_direccionador returnaddress dirección_retorno
Si no se configura pueden producirse errores del sistema, que no haya respuesta del servidor, o los dos.
Al configurar un servidor con ubicación compartida utilizando el método de reenvío nat de Dispatcher, el direccionador especificado en el mandato dscontrol server add debe ser una dirección de direccionador real y no la dirección IP del servidor.
El soporte para la ubicación compartida al configurar el método de reenvío NAT de Dispatcher ahora puede llevarse a cabo en todos los sistemas operativos si se llevan a cabo los siguientes pasos en la máquina Dispatcher:
arp -s hostname ether_addr pub
utilizando la dirección MAC local para ether_addr. Esto permite a la aplicación local enviar tráfico a la dirección de retorno en el kernel.
CBR da soporte a la ubicación compartida en todas las plataformas sin que sea necesario realizar configuraciones adicionales. No obstante, los servidores Web y Caching Proxy que utilice deben ser específicos del enlace.
Site Selector da soporte a la ubicación compartida en todas las plataformas sin que sea necesario realizar configuraciones adicionales.
La función de alta disponibilidad (que puede configurarse con el mandato dscontrol highavailability) está disponible para el componente Dispatcher, pero no para el componente CBR o Site Selector.
Para mejorar la disponibilidad de Dispatcher, la función del alta disponibilidad de Dispatcher utiliza los siguientes mecanismos:
Si es posible, al menos uno de los pares de pulsos debe estar en una subred distinta del tráfico del clúster normal. Si el tráfico de pulsos se identifica claramente se evitará que se produzcan falsas lecturas de otras señales en condiciones de cargas elevadas en la red y se mejorarán los tiempos de recuperación completos después de producirse una sustitución por anomalía.
La sintaxis completa para dscontrol highavailability puede verse en dscontrol highavailability -- controlar alta disponibilidad.
Para obtener una descripción completa de muchas de las tareas que se indican a continuación, consulte el apartado Configuración de la máquina Dispatcher.
dscontrol highavailability heartbeat add dirección_origen dirección_destino
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3Como mínimo un par de pulsos debe tener las NFA del par como dirección de origen y destino.
Si es posible, al menos uno de los pares de pulsos debe estar en una subred distinta del tráfico del clúster normal. Si el tráfico de pulsos se identifica claramente se evitará que se produzcan falsas lecturas de otras señales en condiciones de cargas elevadas en la red y se mejorarán los tiempos de recuperación completos después de producirse una sustitución por anomalía.
Establezca dl número de segundos que el ejecutor utiliza para indicar el tiempo de espera de los pulsos de alta disponibilidad. Por ejemplo:
dscontrol executor set hatimeout 3
El valor predeterminado es 2.
dscontrol highavailability reach add 9.67.125.18Los destinos de alcance son recomendables aunque no necesarios. Consulte el apartado Capacidad de detección de anomalías utilizando pulsos y destino de alcance para obtener más información.
dscontrol highavailability backup add primary [auto | manual] puerto
dscontrol highavailability backup add backup [auto | manual] puerto
dscontrol highavailability backup add both [auto | manual] puerto
dscontrol highavailability statusCada una de las máquinas debe tener el rol correcto (reserva, primaria o ambos), estados y subestados. La máquina primaria debe estar activa y sincronizada; la máquina de reserva debe estar en modalidad de reposo y debe sincronizarse dentro de poco tiempo. Las estrategias deben ser las mismas.
dscontrol cluster set clústerA primaryhost NFAdispatcher1 dscontrol cluster set clústerB primaryhost NFAdispatcher2
dscontrol cluster set clústerB primaryhost NFAdispatcher2 dscontrol cluster set clústerA primaryhost NFAdispatcher1
Notas:
Además de los criterios básicos de detección de anomalía (la pérdida de conectividad entre máquinas Dispatcher activas y en espera, que se detecta a través de los mensajes de pulso), hay otro mecanismo de detección de anomalías denominado criterios de accesibilidad. Al configurar Dispatcher se puede proporcionar una lista de hosts a los que cada una de las máquinas Dispatcher debe poder llegar para funcionar correctamente. Los dos socios de alta disponibilidad se comunican constantemente a través de pulsos y se actualizan mutuamente en lo que se refiere a la cantidad de destinos de alcance a los que pueden emitir mandatos ping. Si, mediante mandatos ping, la máquina en espera puede acceder a más destinos de alcance que la máquina activa, se produce una sustitución por anomalía.
Los pulsos los envía la máquina Dispatcher activa y está previsto que la máquina Dispatcher en espera los reciba cada medio segundo. Si la máquina Dispatcher en espera no puede recibir un pulso durante un intervalo 2 segundos, se empieza un proceso de sustitución por anomalía. Para que se produzca un proceso de toma de control por parte de la máquina Dispatcher en espera, es necesario que se interrumpan todos los pulsos. Es decir, cuando hay dos pares de pulsos configurados, los dos pulsos deben interrumpirse. Para estabilizar el entorno de alta disponibilidad y para evitar que se produzca una sustitución por anomalía, añada más de un par de pulsos.
Para los destinos de alcance, debe elegir como mínimo un host para cada subred que utiliza la máquina Dispatcher. Los hosts pueden ser direccionadores, servidores IP u otros tipos de hosts. La accesibilidad de hosts se obtiene mediante el asesor de alcance que emite el mandato ping al host. La sustitución por anomalía tiene lugar si los mensajes de pulso no pueden transmitirse o si los criterios de accesibilidad los satisface mejor la máquina Dispatcher en espera que la máquina Dispatcher activa. Para tomar una decisión basándose en toda la información disponible, la máquina Dispatcher activa envía regularmente su capacidad de accesibilidad a la máquina Dispatcher en espera. Luego la máquina Dispatcher en espera compara esta capacidad con la suya y decide si debe conmutar el control.
Hay configuradas dos máquinas Dispatcher: la máquina primaria y una segunda máquina denominada de reserva. Durante el arranque, la máquina primaria envía todos los datos de conexión a la máquina de reserva hasta que la máquina se sincroniza. La máquina primaria pasa a estar activa, es decir, empieza el equilibrio de carga. Mientras tanto, la máquina de reserva supervisa el estado de la máquina primaria y se dice que está en estado en espera.
Si en cualquier momento la máquina de reserva detecta que la máquina primaria ha sufrido una anomalía, tomará el control de las funciones de equilibrio de carga de la máquina primaria y pasará a ser la máquina activa. Cuando la máquina primaria vuelve a estar en funcionamiento, las máquinas responden de acuerdo con la estrategia de recuperación configurada por el usuario. Existen dos tipos de estrategia:
El parámetro strategy debe tener el mismo valor en ambas máquinas.
Utilizando el mandato takeover, la estrategia de recuperación manual permite forzar el direccionamiento de paquetes a una máquina determinada. La recuperación manual es útil cuando el mantenimiento se lleva a cabo en la otra máquina. La estrategia de recuperación de automática está diseñada para operaciones desatendidas normales.
En una configuración de alta disponibilidad mutua, no se produce ninguna anomalía por clúster. Si hay algún problema en una máquina, incluso si sólo afecta a un clúster, la otra máquina tomará el control de los dos clústeres.
Para que Dispatcher direccione paquetes, cada dirección de clúster debe tener un alias asociado a un dispositivo de interfaz de red.
Para obtener información sobre la creación de un alias para la tarjeta de interfaz de red, consulte el Paso 5. Crear un alias para la tarjeta de interfaz de red.
Puesto que las máquinas Dispatcher cambiarán su estado cuando se detecte una anomalía, los mandatos anteriores deben emitirse automáticamente. Para ello Dispatcher ejecutará scripts creados por el usuario. Los scripts de ejemplo se encuentran en el directorio ...ibm/edge/lb/servers/samples y deben moverse al directorio ...ibm/edge/lb/servers/bin para que funcionen. Los scripts se ejecutarán automáticamente sólo si dsserver se está ejecutando.
Notas:
Se pueden utilizar los siguientes scripts de ejemplo:
En sistemas Windows: en la configuración, si dispone de Site Selector para equilibrar la carga de dos máquinas Dispatcher que están funcionando en un entorno de alta disponibilidad, será necesario añadir un alias a la pila de Microsoft para los Metric Servers. Este alias debe añadirse al script goActive. Por ejemplo:
call netsh interface ip add address "Conexión de área local" addr=9.37.51.28 mask=255.255.240.0
En el caso de goStandby y goInOp, será necesario suprimir el alias: Por ejemplo:
call netsh interface ip delete address "Conexión de área local" addr=9.37.51.28
Si hay varias NIC en la máquina, compruebe primero qué interfaz debe utilizar emitiendo el siguiente mandato en el indicador de mandatos: netsh interface ip show address. Este mandato devolverá una lista de las interfaces configuradas actualmente y asignará un número a "Conexión de área local" (por ejemplo, "Conexión de área local 2") para que pueda determinar cuál debe utilizar.
En Linux para S/390(R): Dispatcher emite un ARP injustificado para poder mover direcciones IP desde un Dispatcher a otro. Este mecanismo está, por lo tanto, relacionado con el tipo de red implícito. Al ejecutar Linux para S/390, Dispatcher puede hacer tomas de control de alta disponibilidad de manera nativa (completa con movimientos de la dirección IP) sólo en aquellas interfaces que pueden emitir un ARP y configurar la dirección en la interfaz local. Este mecanismo no funcionará correctamente en interfaces punto a punto como, por ejemplo, IUCV y CTC, y no funcionará correctamente en algunas configuraciones de qeth/QDIO.
Para estas interfaces y configuraciones donde la función de toma de control de IP nativa del Dispatcher no funcionará correctamente, el cliente puede colocar mandatos adecuados en los scripts go para mover las direcciones de manera manual. De esta manera también se asegurará de que dichas topologías de red se puedan beneficiar de la alta disponibilidad.
Es posible configurar tanto la alta disponibilidad como la ubicación compartida en servidores Windows. Sin embargo, para configurar estas características de Load Balancer juntas en sistemas Windows son necesarios unos pasos adicionales.
En sistemas Windows, cuando se utiliza la ubicación compartida con la alta disponibilidad, necesitará una dirección IP adicional, una especie de dirección IP ficticia, que pueda añadirse al adaptador de bucle de retorno. Es necesario instalar el adaptador de bucle de reserva tanto en la máquina primaria como en la máquina de reserva. Para instalar el dispositivo de bucle de retorno en sistemas Windows, siga los pasos descritos en Configuración de máquinas de servidor para el equilibrio de carga.
Cuando los pasos indiquen que añada la dirección IP de clúster al bucle de retorno, deberá añadir una dirección IP ficticia, no la dirección del clúster. Esto se debe a que los scripts go* de alta disponibilidad para sistemas Windows necesitan suprimir y añadir la dirección de clúster al dispositivo de bucle de retorno, en función de si la máquina de Load Balancer está activa o en espera.
Los sistemas Windows no permitirán que se elimine del dispositivo de bucle de retorno la última dirección IP configurada porque el dispositivo de bucle de retorno no funciona en modalidad DHCP. La dirección ficticia permite a Load Balancer eliminar en cualquier momento su dirección de clúster. La dirección IP ficticia no se utilizar para ningún tipo de tráfico y se puede utilizar tanto en la máquinas activa como en la máquina de reserva.
Actualice y traslade los scripts go* de Load Balancer de la máquinas activa y en espera y, a continuación, inicie Dispatcher. La dirección del clúster se añadirá y eliminará de la interfaz de red y de los dispositivos de bucle de retorno en los momentos adecuados.
Utilice el equilibrio de carga basado en reglas para ajustar cuándo y porqué los paquetes se envían a qué servidores. Load Balancer examina todas las reglas que se añaden, desde la primera prioridad a la última, se detiene en la primera regla que es cierta y luego equilibra la carga del contenido entre todos los servidores asociados a la regla. Ya se ha equilibrado la carga basada en el destino y el puerto, pero si se utilizan reglas se amplía la capacidad de distribuir conexiones.
En la mayoría de los casos, al configurar reglas se debe configurar una regla siempre cierta para poder detectar cualquier petición pasada por otras reglas de prioridad más altas. Este valor predeterminado puede ser la respuesta "Lo sentimos, el sitio está inactivo actualmente, inténtelo más adelante" cuando los demás servidores no pueden aceptar la petición de cliente.
Debe utilizar el equilibrio de carga basado en reglas con Dispatcher y Site Selector cuando por alguna razón desea utilizar un subconjunto de servidores. Siempre debe utilizar reglas para el componente CBR.
Puede elegir entre los siguientes tipos de reglas:
Antes de empezar a añadir reglas a la configuración, planifique la lógica que desea que sigan las reglas.
Todas las reglas tienen un nombre, un tipo, una prioridad y pueden tener un inicio del rango y un final del rango, junto con un conjunto de servidores. Además, la regla de tipo contenido para el componente CBR tiene asociado un patrón de expresión regular coincidente. (Si desea ver ejemplos y casos de cómo utilizar la regla de contenido y la sintaxis de patrón válida para la regla de contenido, consulte el Apéndice B. Sintaxis de la regla de contenido (patrón)).
Las reglas se evalúen en orden de prioridad. Es decir, una regla con prioridad 1 (número más bajo) se evalúa antes que una regla con prioridad 2 (número más alto). Se utilizará la primera regla que se satisfaga. Una vez que se ha satisfecho una regla, no se evalúan más reglas.
Para que una regla se satisfaga, debe cumplir dos condiciones:
Si una regla no tiene asociado ningún servidor, sólo es necesario que la regla cumpla la condición uno para que se satisfaga. En este caso, Dispatcher descartará la petición de conexión, Site Selector devolverá la petición del servidor de nombres con un error, y CBR hará que Caching Proxy devuelva una página de error.
Si no se satisface ninguna regla, Dispatcher seleccionará un servidor del total de servidores disponibles en el puerto, Site Selector seleccionará un servidor del total de servidores disponibles en el nombre de sitio y CBR provocará que Caching Proxy devuelva una página de error.
Este tipo de regla está disponible en el componente Dispatcher, CBR o Site Selector.
Utilice reglas basadas en la dirección IP de cliente si desea filtrar los clientes y asignar los recursos en función del lugar de donde proceden.
Por ejemplo, si observa que hay demasiado tráfico sin pagar en la red, y por lo tanto no deseado, que procede de un grupo específico de direcciones IP. Cree una regla utilizando el mandato dscontrol rule , por ejemplo:
dscontrol rule add 9.67.131.153:80:ni type ip beginrange 9.0.0.0 endrange 9.255.255.255
Esta regla "ni" filtra cualquier conexión de clientes no deseados. A continuación, añada a la regla los servidores a los que se podrá acceder, o si no añade ningún servidor a la regla, los servidores no atenderán las peticiones que procedan de las direcciones 9.x.x.x.
Este tipo de regla sólo está disponible en el componente Dispatcher.
Utilice reglas basadas en el puerto de cliente, si los clientes utilizan algún tipo de software que solicita un puerto específico de TCP/IP cuando realiza peticiones.
Por ejemplo, cree una regla que indique que todas las peticiones que tengan el puerto de cliente 10002 podrán utilizar un conjunto de servidores rápidos especiales porque sabe que todas las peticiones de cliente con dicho puerto proceden de un grupo selecto de clientes.
Este tipo de regla está disponible en el componente Dispatcher, CBR o Site Selector.
Utilice reglas basadas en la hora del día por razones de planificación de capacidad. Por ejemplo, si se accede al sitio Web mayormente durante el mismo grupo de horas cada día, puede dedicar cinco servidores adicionales durante el periodo de hora punta.
Otra razón por la que puede utilizar una regla basada en la hora del día es cuando desea apagar algunos de los servidores para realizar su mantenimiento cada día a medianoche, por lo que puede establecer una regla que excluya estos servidores durante el periodo de mantenimiento necesario.
Este tipo de regla sólo está disponible en el componente Dispatcher.
Utilice reglas basadas en el contenido del campo de "tipo de servicio" (TOS) en la cabecera IP. Por ejemplo, si una petición de cliente llega con un valor TOS que indica servicio normal, puede direccionarse a un conjunto de servidores. Si una petición de cliente diferente llega con un valor de TOS distinto que indica una prioridad de servicio más alta, puede direccionarse a un grupo de servidores distinto.
La regla TOS permite configurar completamente cada bit del byte TOS utilizando el mandato dscontrol rule. Para bits significativos que desee hacer coincidir en el byte TOS, utilice 0 o 1. Si no, utilice el valor x. A continuación se muestra un ejemplo de adición de una regla TOS:
dscontrol rule add 9.67.131.153:80:tsr type service tos 0xx1010x
Este tipo de regla está disponible en los componentes Dispatcher y CBR.
Utilice reglas basadas en conexiones por segundo si necesita compartir algunos de los servidores con otras aplicaciones. Por ejemplo, puede establecer dos reglas:
O, puede utilizar Telnet y reservar dos de los cinco servidores para Telnet, excepto cuando las conexiones por segundo superen un determinado nivel. De esta forma, Dispatcher equilibrará la carga en todos los cinco servidores durante las horas punta.
Si establece la opción de evaluación de reglas "upserversonrule" junto con la regla de tipo "conexión": cuando se utiliza la regla de tipo conexión y se establece la opción upserversonrule, si algunos de los servidores del conjunto de servidores están inactivos, puede garantizar que no se sobrecargarán los servidores restantes. Si desea más información, consulte el apartado Opción de evaluación del servidor para reglas.
Este tipo de regla está disponible en el componente Dispatcher o CBR.
Utilice reglas basadas en el total de conexiones activas en un puerto si los servidores se sobrecargan y empiezan a descartar paquetes. Determinados servidores Web seguirán aceptando conexiones incluso cuando no tengan suficientes hebras para responder a la petición. Como resultado, las peticiones de cliente excederán el tiempo de espera y no se atenderá al cliente procedente del sitio Web. Utilice reglas basadas en conexiones activas para equilibrar la capacidad dentro de una agrupación de servidores.
Por ejemplo, sabe por experiencia que los servidores dejarán de dar servicio una vez que han aceptado 250 conexiones. Cree una regla utilizando el mandato dscontrol rule o el mandato cbrcontrol rule, por ejemplo:
dscontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500 o cbrcontrol rule add 130.40.52.153:80:pool2 type active beginrange 250 endrange 500
A continuación, añada a la regla los servidores actuales y a algunos servidores adicionales, que si no se utilizarán para otro proceso.
Las reglas de ancho de banda reservado y ancho de banda compartido sólo están disponibles en el componente Dispatcher.
Para las reglas de ancho de banda, Dispatcher calcula el ancho de banda como la velocidad a la que un conjunto de servidores entregan los datos a los clientes. Dispatcher realiza un seguimiento de la capacidad en los niveles de servidor, regla, puerto, clúster y ejecutor. Para cada uno de estos niveles, hay un campo de contador de bytes: kilobytes transferidos por segundo. Dispatcher calcula estas velocidades a un intervalo de 60 segundos. Puede ver estas velocidades en la GUI o en la salida de un informe de línea de mandatos.
La regla de ancho de banda reservado permite controlar el número de kilobytes por segundos que entregan un conjunto de servidores. Si se establece un umbral (asignando un rango de ancho de banda específico) para cada conjunto de servidores en toda la configuración, puede controlar y garantizar la cantidad de ancho de banda que utiliza cada combinación de clúster-puerto.
A continuación se muestra un ejemplo de adición de una regla de ancho de banda reservado:
dscontrol rule add 9.67.131.153:80:rbw type reservedbandwidth beginrange 0 endrange 300
El inicio del rango y el final del rango se especifican en kilobytes por segundo.
Antes de configurar la regla de ancho de banda compartido, debe especificar la cantidad máxima de ancho de banda (kilobytes por segundo) que puede compartirse en el nivel de ejecutor o clúster utilizando el mandato dscontrol executor o dscontrol cluster con la opción sharedbandwidth. El valor de sharedbandwidth no debe exceder el ancho de banda total (capacidad total de la red) disponible. Si se utiliza el mandato dscontrol para establecer el ancho de banda compartido sólo se proporciona un límite superior para la regla.
A continuación se muestran ejemplos de la sintaxis de mandato:
dscontrol executor set sharedbandwidth tamaño dscontrol cluster [add | set] 9.12.32.9 sharedbandwidth tamaño
El tamaño para sharedbandwidth es un valor entero (kilobytes por segundo). El valor predeterminado es cero. Si el valor es cero, el ancho de banda no puede compartirse.
El ancho de banda compartido en el nivel de clúster permite que el clúster utilice el máximo ancho de banda especificado. Mientras el ancho de banda utilizado por el clúster esté por debajo de la cantidad especificada, esta regla se evaluará como true. Si el ancho de banda total utilizado es superior a la cantidad especificada, esta regla se evaluará como false.
Si se comparte el ancho de banda en el nivel de ejecutor, se permitirá que toda la configuración de Dispatcher comparta una cantidad máxima de ancho de banda. Mientras el ancho de banda utilizado en el nivel de ejecutor esté por debajo de la cantidad especificada, esta regla se evaluará como true. Si el ancho de banda total utilizado es superior al definido, esta regla se evaluará como false.
A continuación se muestran ejemplos de la adición o definición de una regla de ancho de banda compartido:
dscontrol rule add 9.20.30.4:80:shbw type sharedbandwidth sharelevel valor dscontrol rule set 9.20.34.11:80:shrule sharelevel valor
El valor para sharelevel es executor o cluster. Sharelevel es un parámetro necesario en la regla de ancho de banda compartido.
Dispatcher permite asignar un ancho de banda específico a conjuntos de servidores dentro de la configuración mediante la regla de ancho de banda reservado. Si especifica un inicio y un final del rango puede controlar el rango de kilobytes entregados por un conjunto de servidores a los clientes. Cuando la regla ya no se evalúe como true (se excede el final del rango), se evaluará la regla con prioridad más baja siguiente. Si la regla de prioridad más baja siguiente es una regla "siempre cierta", se podría seleccionar un servidor para responder al cliente con una respuesta de "sitio ocupado".
Por ejemplo, suponga un grupo de tres servidores en el puerto 2222. Si el ancho de banda reservado se establece en 300, la cantidad máxima de kbytes por segundo es de 300, en un periodo de 60 segundos. Cuando esta velocidad se excede, la regla ya no se evaluará como true. Si ésta fuera la única regla, Dispatcher seleccionaría uno de los tres servidores para manejar la petición. Si hubiera una regla "siempre cierta" con prioridad más baja, la petición podría dirigirse a otro servidor y responderse con "sitio ocupado".
La regla de ancho de banda compartido puede proporcionar a los clientes acceso a servidores adicionales. En concreto, cuando se utiliza como una regla de prioridad más baja después de una regla de ancho de banda reservado, un cliente seguirá pudiendo acceder a un servidor incluso si se ha excedido el ancho de banda reservado.
Por ejemplo, si utiliza una regla de ancho de banda compartido después de una regla de ancho de banda reservado, puede permitir a los clientes que accedan a los tres servidores de una forma controlada. Mientras haya un ancho de banda compartido para utilizarse, la regla se evaluará como true y se otorgará el acceso. Si no hay ningún ancho de banda compartido disponible, la regla no es true y se evalúa la regla siguiente. Si a continuación hay una regla "siempre cierta", la petición puede redirigirse según sea necesario.
Si utiliza el ancho de banda reservado y compartido tal como se describe en el ejemplo anterior, se podrá ejercer una mayor flexibilidad al otorgar (o denegar) acceso a los servidores. Los servidores de un puerto específico pueden limitarse al uso de un ancho de banda, mientras que otros pueden utilizar un ancho de banda adicional mientras esté disponible.
Este tipo de regla sólo está disponible en el componente Site Selector.
Para la regla de toda la métrica, elija una métrica del sistema (cpuload, memload, o su propio script de métrica de sistema personalizado) y el Site Selector compara el valor de métrica del sistema (devuelto por el agente de Metric Server que reside en cada servidor con equilibrio de carga) con el inicio y el final del rango que se especifica en la regla. El valor de métrica del sistema actual para todos los servidores del conjunto de servidores debe estar dentro del rango para que se active la regla.
A continuación se muestra un ejemplo de adición a la configuración de una regla de toda la métrica:
sscontrol rule add dnsload.com:allrule1 type metricall metricname cpuload beginrange 0 endrange 100
Este tipo de regla sólo está disponible en el componente Site Selector.
Para la regla de media de la métrica, elija una métrica del sistema (cpuload, memload, o su propio script de métrica de sistema personalizado) y el Site Selector compara el valor de métrica del sistema (devuelto por el agente de Metric Server que reside en cada servidor con equilibrio de carga) con el inicio y el final del rango que se especifica en la regla. La media de los valores de métrica del sistema actuales para todos los servidores del conjunto de servidores debe estar dentro del rango para que se active la regla.
A continuación se muestra un ejemplo de adición a la configuración de una regla de media de la métrica:
sscontrol rule add dnsload.com:avgrule1 type metricavg metricname cpuload beginrange 0 endrange 100
Este tipo de regla está disponible en el componente Dispatcher, CBR o Site Selector.
Puede crearse una regla que sea "siempre cierta." Dicha regla siempre estará seleccionada, a menos que los servidores asociados estén inactivos. Por esta razón, habitualmente debe tener una prioridad más baja que las otras reglas.
También puede tener varias reglas "siempre cierta", con un conjunto de servidores asociado a cada una de ellas. Se selecciona la primera regla true que tenga un servidor disponible. Por ejemplo, suponga que tiene seis servidores. Desea que dos de ellos controlen el tráfico en todas las circunstancias, a menos los dos estén inactivos. Si los dos primeros servidores están inactivos, se recomienda disponer de un segundo conjunto de servidores que controle el tráfico. Si los cuatro servidores están inactivos, se utilizarán los dos últimos servidores para manejar el tráfico. Puede establecer hasta tres reglas "siempre cierta". Así pues siempre se seleccionará el primer conjunto de servidores siempre y cuando haya uno activo como mínimo. Si los dos están inactivos, se optará por uno del segundo conjunto y así sucesivamente.
Otro ejemplo sería si deseara una regla "siempre cierta" para asegurarse de que no se atenderá a los clientes entrantes si estos no coinciden con ninguna de las reglas establecidas. Puede crear una regla utilizando el mandato dscontrol rule como la siguiente:
dscontrol rule add 130.40.52.153:80:jamais type true priority 100
Entonces no añadiría ningún servidor a la regla, lo que provocaría que los paquetes de clientes se dejaran sin respuesta.
Puede definir más de una regla "siempre cierta" y, a partir de ahí, ajustar cuál se ejecuta cambiando los niveles de prioridad.
Este tipo de regla está disponible en el componente CBR o el componente Dispatcher (cuando se utiliza el método de reenvío CBR de Dispatcher).
Se recomienda utilizar reglas de tipo de contenido para enviar peticiones a conjuntos de servidores establecidos específicamente para manejar algún subconjunto del tráfico del sitio. Por ejemplo, si desea utilizar un conjunto de servidores para manejar todas las peticiones cgi-bin, otro conjunto para manejar todas las peticiones de audio de modalidad continua y un tercer conjunto para manejar las demás peticiones. Añada una regla con un patrón que coincida con la vía de acceso al directorio cgi-bin, otra que coincida con el tipo de archivo de los archivos de audio de modalidad continua y una tercera regla siempre cierta para manejar el resto del tráfico. A continuación, añada los servidores adecuados a cada una de las reglas.
Importante: si desea ver ejemplos y casos de cómo utilizar la regla de contenido y la sintaxis de patrón válida para la regla de contenido, consulte el Apéndice B. Sintaxis de la regla de contenido (patrón).
Con la alteración temporal de afinidad entre puertos, puede alterar temporalmente la permanencia en memoria de un puerto para un servidor específico. Por ejemplo, si utiliza una regla para limitar la cantidad de conexiones para cada servidor de aplicaciones y tiene un servidor de desbordamiento con una regla siempre cierta que indica "por favor, inténtelo más adelante" para dicha aplicación. El puerto tiene un valor de permanencia en memoria de 25 minutos, por lo tanto no desea que el cliente sea permanente en memoria para dicho servidor. Con la alteración temporal de afinidad entre puertos, puede cambiar el servidor de desbordamiento para alterar temporalmente la afinidad que normalmente está asociada a dicho puerto. La próxima vez que el cliente emite una petición al clúster, se equilibra su carga con el mejor servidor de aplicaciones disponible, no el servidor de desbordamiento.
Consulte el apartado dscontrol server -- configurar servidores, para obtener información detallada sobre la sintaxis del mandato de alteración temporal de afinidad entre puertos, utilizando la opción sticky del servidor.
Para añadir reglas mediante el mandato dscontrol rule add, edite el archivo de configuración de ejemplo o utilice la interfaz gráfica de usuario (GUI). Puede añadir una o más reglas a cada puerto definido.
Es un proceso de dos pasos: añadir la regla y definir qué servidores la atenderán si la regla es cierta. Por ejemplo, el administrador del sistema desea realizar un seguimiento del uso de los servidores proxy que realiza cada una de las secciones del sitio. Se han otorgado direcciones IP a cada sección. Cree el primer conjunto de reglas basándose en la dirección IP de cliente para separar la carga de cada sección:
dscontrol rule add 130.40.52.153:80:div1 type ip b 9.1.0.0 e 9.1.255.255 dscontrol rule add 130.40.52.153:80:div2 type ip b 9.2.0.0 e 9.2.255.255 dscontrol rule add 130.40.52.153:80:div3 type ip b 9.3.0.0 e 9.3.255.255
A continuación, añada un servidor distinto para cada regla y mida la carga en cada uno de los servidores para poder facturar correctamente a la sección por los servicios que está utilizando. Por ejemplo:
dscontrol rule useserver 130.40.52.153:80:div1 207.72.33.45 dscontrol rule useserver 130.40.52.153:80:div2 207.72.33.63 dscontrol rule useserver 130.40.52.153:80:div3 207.72.33.47
La opción de evaluación del servidor sólo está disponible en el componente Dispatcher.
En el mandato dscontrol rule hay una opción de evaluación del servidor para reglas. Utilice la opción evaluate para optar por evaluar la condición de la regla en todos los servidores del puerto o evaluar la condición de la regla sólo en los servidores incluidos en la regla. (En versiones anteriores de Load Balancer, sólo se podía medir la condición de cada regla en todos los servidores del puerto).
Notas:
A continuación se muestran ejemplos de la adición o definición de la opción de evaluación en una regla de ancho de banda reservado:
dscontrol rule add 9.22.21.3:80:rbweval type reservedbandwidth evaluate nivel dscontrol rule set 9.22.21.3:80:rbweval evaluate nivel
El nivel de la evaluación puede establecerse en port, rule o upserversonrule. El valor predeterminado es port.
La opción de medir la condición de la regla en todos los servidores a los que se aplica le permite configurar dos reglas con las siguientes características:
El resultado es que cuando el tráfico excede el umbral de los servidores a los que se aplica la primera regla, el tráfico se envía al servidor "sitio ocupado" al que se aplica la segunda regla. Cuando el tráfico es inferior al umbral de los servidores a los que se aplica la primera regla, el nuevo tráfico vuelve a dirigirse otra vez a los servidores a los que se aplica la primera regla.
Si utiliza las dos reglas del ejemplo anterior, si establece la opción de evaluación en port para la primera regla (evaluar condición de la regla en todos los servidores del puerto), cuando el tráfico excede el umbral de dicha regla, se envía al servidor "sitio ocupado" asociado a la segunda regla.
La primera regla mide todo el tráfico del servidor (incluido el servidor "sitio ocupado") en el puerto para determinar si el tráfico excede el umbral. Cuando la congestión disminuye en todos los servidores asociados a la primera regla, puede producirse un resultado involuntario en el que el tráfico sigue dirigiéndose al servidor "sitio ocupado" porque el tráfico en el puerto todavía supera el umbral de la primera regla.
Para los componentes Dispatcher y CBR: habilite la característica de afinidad cuando configure un puerto de clúster para que sea permanente en memoria. Si configura el puerto de un clúster de modo que sea permanente en memoria, permite que las peticiones de cliente subsiguientes se direccionen al mismo servidor. Esto se lleva a cabo estableciendo stickytime en el nivel de ejecutor, clúster o puerto en algunos segundos. Esta característica se inhabilita estableciendo el tiempo de permanencia en memoria (stickytime) en el valor cero.
Si está habilitando la afinidad entre puertos, los valores de tiempo de permanencia en memoria (stickytime) de los puertos compartidos deben ser valores iguales (no cero). Consulte el apartado Afinidad entre puertos para obtener más información.
Para el componente Site Selector: habilite la característica de afinidad cuando configure un nombre de sitio para que sea permanente en memoria. Si configura un nombre de sitio para que sea permanente en memoria, el cliente podrá utilizar el mismo servidor para varias peticiones del servicio de nombres. Esto se lleva a cabo estableciendo stickytime del nombre del sitio en algunos segundos. Esta característica se inhabilita estableciendo el tiempo de permanencia en memoria (stickytime) en el valor cero.
El período de permanencia en memoria es el intervalo entre el cierre de una conexión y la apertura de una conexión nueva, durante el cual un cliente se volverá a enviar al mismo servidor utilizado durante la primera conexión. Cuando caduca el tiempo de permanencia en memoria, el cliente puede enviarse a un servidor distinto del primero. El valor de tiempo de permanencia en memoria para un servidor se configura mediante los mandatos dscontrol, executor, port o cluster.
Cuando la característica de afinidad se inhabilita, siempre que se recibe una nueva conexión TCP de un cliente, Load Balancer elige el servidor más adecuado para dicho momento y le remite los paquetes. Si llega una conexión subsiguiente procedente del mismo cliente, Load Balancer la trata como si fuera una nueva conexión no relacionada y vuelve a elegir el servidor más apropiado para dicho momento.
Con la característica de afinidad habilitada, si se recibe una petición subsiguiente del mismo cliente, la petición se dirige al mismo servidor.
Con el tiempo, el cliente terminará el envío de transacciones y el registro de afinidad desaparecerá. De ahí el significado de "tiempo de permanencia en memoria." Cada registro de afinidad existe durante el "tiempo de permanencia en memoria" en segundos. Cuando se reciben conexiones subsiguientes dentro del tiempo de permanencia en memoria, el registro de afinidad seguirá siendo válido y la petición se dirigirá al mismo servidor. Si no se recibe una conexión subsiguiente dentro del tiempo de permanencia en memoria, el registro se depura; una conexión que se recibe después de dicho tiempo tendrá un nuevo servidor seleccionado para la misma.
El mandato server down (dscontrol server down) se utiliza para poner un servidor fuera de línea. El servidor pasará a estar inactivo una vez que caduque el valor de tiempo de permanencia en memoria (stickytime).
La afinidad entre puertos sólo se aplica a los métodos de reenvío MAC y NAT/NATP del componente Dispatcher.
La afinidad entre puertos es la característica de permanencia en memoria que se ha ampliado para cubrir varios puertos. Por ejemplo, si una petición de cliente se recibe primero en un puerto y la siguiente se recibe en otro puerto, la afinidad entre puertos permite a Dispatcher enviar la petición de cliente al mismo servidor. Para utilizar esta característica, los puertos deben:
Más de un puerto puede enlazar con el mismo crossport. Cuando llegan conexiones subsiguientes del mismo cliente al mismo puerto o a un puerto compartido, se accederá al mismo servidor. A continuación se muestra un ejemplo de cómo configurar varios puertos con una afinidad entre puertos para el puerto 10:
dscontrol port set clúster:20 crossport 10 dscontrol port set clúster:30 crossport 10 dscontrol port set clúster:40 crossport 10
Una vez que se ha establecido la afinidad entre puertos, tiene la flexibilidad de modificar el valor de tiempo de permanencia en memoria para el puerto. No obstante, se recomienda cambiar los valores de tiempo de permanencia en memoria para todos los puertos compartidos por el mismo valor; de lo contrario, pueden producirse resultados inesperados.
Para eliminar la afinidad entre puertos, establezca el valor de crossport de nuevo en el número de su propio puerto. Consulte el apartado dscontrol port -- configurar puertos, para obtener información detallada sobre la sintaxis de mandato para la opción crossport.
La máscara de dirección de afinidad sólo se aplica al componente Dispatcher.
La máscara de dirección de afinidad es una mejora de la característica de permanencia en memoria para agrupar clientes basándose en las direcciones de subred comunes. Si especifica stickymask en el mandato dscontrol port se podrán ocultar los bits de orden superior comunes de la dirección IP de 32 bits. Si se configura esta característica, la primera vez que una petición de cliente realiza una conexión con el puerto, todas las peticiones subsiguientes procedentes de clientes con la misma dirección de subred (representada por la parte de la dirección que está enmascarada) se dirigirán al mismo servidor.
Por ejemplo, si desea que todas las peticiones de clientes entrantes con la misma dirección de Clase A de red se dirijan al mismo servidor, establezca el valor de stickymask en 8 (bits) para el puerto. Para agrupar peticiones de clientes con la misma dirección de Clase B de red , establezca el valor de stickymask en 16 (bits). Para agrupar peticiones de clientes con la misma dirección de Clase C de red , establezca el valor de stickymask en 24 (bits).
Para obtener los mejores resultados, establezca el valor stickymask la primera vez que inicie Load Balancer. Si cambia el valor de stickymask de forma dinámica, los resultados pueden ser imprevisibles.
Interacción con afinidad entre puertos: si está habilitando la afinidad entre puertos, los valores de stickymask de los puertos compartidos deben ser los mismos. Consulte el apartado Afinidad entre puertos para obtener más información.
Para habilitar la máscara de dirección de afinidad, emita un mandato dscontrol port parecido al siguiente:
dscontrol port set clúster:puerto stickytime 10 stickymask 8
Los posibles valores de stickymask son 8, 16, 24 y 32. El valor 8 especifica los 8 primeros bits de orden superior de la dirección IP (dirección de Clase A de red) se ocultará. El valor 16 especifica los 16 primeros bits de orden superior de la dirección IP (dirección de Clase B de red) se ocultará. El valor 24 especifica los 24 primeros bits de orden superior de la dirección IP (dirección de Clase C de red) se ocultará. Si especifica el valor 32, está ocultando toda la dirección IP que inhabilita de hecho la característica de máscara de dirección de afinidad. El valor predeterminado de stickymask es 32.
Consulte el apartado dscontrol port -- configurar puertos, para obtener información detallada sobre la sintaxis de mandato para stickymask (característica de máscara de dirección de afinidad).
Desactivar temporalmente el manejo se aplica a Dispatcher y componentes CBR.
Para eliminar un servidor de la configuración de Load Balancer por cualquier razón (actualizaciones, ampliaciones, servicio, etc.), puede utilizar el mandato dscontrol manager quiesce. El submandato quiesce permite que las conexiones existentes finalicen (sin ser atendidas) y sólo remite las nuevas conexiones posteriores del cliente al servidor desactivado temporalmente si la conexión se ha designado como de permanencia en memoria y el tiempo de permanencia en memoria no ha caducado. El submandato quiesce no deja que se realicen otras conexiones nuevas al servidor.
Utilice la opción quiesce "now" si ha fijado el tiempo de permanencia en memoria y desea enviar nuevas conexiones a otro servidor (en lugar de enviarlas al servidor desactivado temporalmente) antes de que caduque el tiempo de espera. A continuación se muestra un ejemplo de utilización de la opción now para desactivar temporalmente el servidor 9.40.25.67:
dscontrol manager quiesce 9.40.25.67 now
La opción now determina cómo se manejarán las conexiones de permanencia en memoria:
Esta es la forma progresiva y menos brusca de desactivar temporalmente los servidores. Por ejemplo, puede desactivar temporalmente un servidor de forma progresiva y luego esperar el momento en el que haya la mínima cantidad de tráfico (quizás de madrugada) para eliminar completamente el servidor de la configuración.
Puede especificar los siguientes tipos de afinidad en el mandato dscontrol rule:
La afinidad de cookies activos sólo se aplica al componente CBR.
Cookie pasivo se aplica al componente CBR y al método de reenvío CBR del componente Dispatcher.
La afinidad de URL se aplica al componente CBR y al método de reenvío CBR del componente Dispatcher.
El valor predeterminado para la opción affinity es "none." La opción stickytime en el mandato port debe ser cero (no habilitado) para poder establecer la opción affinity en el mandato rule para el cookie activo, cookie pasivo o URI. Cuando se establece la función de afinidad en la regla, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
La función de afinidad de cookies activos sólo se aplica al componente CBR.
Proporciona una forma para hacer que los clientes sean "permanentes" para un servidor particular. Esta función se habilita estableciendo la opción stickytime de una regla en un número positivo y estableciendo la opción affinity en "activecookie." Esto puede llevarse a cabo cuando se añade la regla o se utiliza el mandato rule set. Consulte el apartado dscontrol rule -- configurar reglas, para obtener información detallada sobre la sintaxis del mandato.
Cuando se habilita una regla para la afinidad de cookies activos, se equilibra la carga de nuevas peticiones de clientes utilizando algoritmos CBR estándar, mientras que las peticiones sucesivas del mismo cliente se envían al servidor elegido al principio. El servidor elegido se almacena en forma de cookie en la respuesta al cliente. Siempre y cuando las peticiones futuras del cliente contengan el cookie y lleguen dentro del intervalo de permanencia en memoria, el cliente mantendrá afinidad con el servidor inicial.
La afinidad de cookies activos se utiliza para asegurar que un cliente siga realizando el equilibrio de carga en el mismo servidor durante un periodo de tiempo. Esto se lleva a cabo enviando un cookie para que se almacene en el navegador de los clientes. El cookie contiene los valores clúster:puerto:regla que se utilizaron para tomar una decisión, el servidor en el que se realizó el equilibrio de carga y una indicación de la hora del tiempo de espera excedido para cuando la afinidad ya no es válida. El cookie tiene el siguiente formato: IBMCBR=clúster:puerto: regla+servidor-hora! La información clúster:puerto:regla y servidor está codificada para que no muestre la configuración de CBR.
Siempre que una regla indique que tiene activada la afinidad de cookies activos, se examinará el cookie enviado por el cliente.
Este nuevo cookie se insertará en las cabeceras que se devuelven al cliente, y si el navegador del cliente se configura de forma que acepte cookies, devolverá peticiones subsiguientes.
Cada instancia de afinidad del cookie tiene una longitud de 65 bytes y termina con un signo de exclamación. Como resultado, un cookie de 4096 bytes puede mantener aproximadamente 60 reglas de cookies activos individuales por dominio. Si el cookie se rellena completamente, se depuran todas las instancias de afinidad caducadas. Si todas las instancias siguen siendo válidas, se elimina la más antigua y se añaden las nuevas instancias para la regla actual.
La opción affinity de cookies activos, para el mandato rule, sólo puede establecerse en activecookie si la opción port stickytime es cero (no habilitada). Una vez que la afinidad de cookies activos está activa en una regla, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
Para habilitar la afinidad de cookies activos para una regla concreta, utilice el mandato rule set:
rule set clúster:puerto:regla stickytime 60 rule set clúster:puerto:regla affinity activecookie
Hacer que una regla sea permanente en memoria normalmente se utiliza para CGI o servlets que almacenan estado de cliente en el servidor. El estado lo identifica un ID de cookie (estos son cookies de servidor). El estado del cliente sólo está en el servidor seleccionado, de modo que el cliente necesita el cookie de dicho servidor para mantener dicho estado entre peticiones.
La afinidad de cookies activos tiene una hora de caducidad del servidor actual predeterminado, más el intervalo de tiempo de permanencia en memoria, más veinticuatro horas. Si las horas de los sistemas clientes (aquellos que envían peticiones a la máquina CBR) son incorrectas (por ejemplo, van un día por delante de la hora del servidor), los sistemas de estos clientes ignorarán los cookies de CBR porque el sistema dará por supuesto que los cookies ya han caducado. Para fijar una hora de caducidad posterior, modifique el script cbrserver. En el archivo script, edite la línea javaw añadiendo el siguiente parámetro después de LB_SERVER_KEYS: -DCOOKIEEXPIREINTERVAL=X donde X es el número de días que desea añadir a la hora de caducidad.
En sistemas AIX, Solaris y Linux, el archivo cbrserver está en el directorio /usr/bin.
En sistemas Windows, el archivo cbrserver está en el directorio \winnt\system32.
La afinidad de cookies pasivos se aplica al método de reenvío de CBR (Content Based Routing) del componente Dispatcher y al componente CBR. Consulte el apartado Direccionamiento basado en contenido de Dispatcher (método de reenvío cbr) para obtener información sobre cómo configurar el método de reenvío cbr de Dispatcher.
La afinidad de cookies pasivos proporciona una forma para que los clientes sean permanentes en memoria para un servidor concreto. Cuando habilita la afinidad de una regla para "passivecookie", la afinidad de cookies pasivos le permite equilibrar la carga del tráfico Web con afinidad al mismo servidor, basándose en cookies que se identifican a sí mismos generados por los servidores. La afinidad de cookies pasivos se configura en el nivel de reglas.
Cuando se activa la regla, si la afinidad de cookies pasivos está habilitada, Load Balancer seleccionará el servidor basándose en el nombre de cookie de la cabecera HTTP de la petición del cliente. Load Balancer empieza a comparar el nombre de cookie de la cabecera HTTP del cliente con el valor de cookie configurado para cada servidor.
La primera vez que Load Balancer encuentre un servidor cuyo valor de cookie contenga el nombre de cookie del cliente, Load Balancer selecciona dicho servidor para la petición.
Si el nombre de cookie en la petición de cliente no se encuentra o no coincide con ningún contenido de los valores de cookie de los servidores, el servidor se selecciona utilizando la selección del servidor existente o la técnica de turno rotativo sopesado.
Para configurar afinidad de cookies pasivos:
La opción affinity de cookies pasivos, para el mandato rule, sólo puede establecerse en passivecookie si la opción port stickytime es cero (no habilitada). Una vez que la afinidad de cookies pasivos está activa en una regla, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
La afinidad de URI se aplica al método de reenvío CBR de Dispatcher y el componente CBR. Consulte el apartado Direccionamiento basado en contenido de Dispatcher (método de reenvío cbr) para obtener información sobre cómo configurar el método de reenvío cbr.
La afinidad de URI permite equilibrar la carga del tráfico Web para servidores Caching Proxy, lo que permitirá que el contenido exclusivo se almacene en la memoria caché de cada servidor individual. Como resultado, se aumentará eficazmente la capacidad de la memoria caché del sitio y se eliminará el almacenamiento en caché redundante de contenido en varias máquinas. Configure la afinidad de URI en el nivel de reglas. Una vez que la regla se activa, la afinidad de URI se habilita y el mismo conjunto de servidores están activos y responden, Load Balancer remitirá nuevas peticiones de cliente entrantes con el mismo URI al mismo servidor.
Normalmente, Load Balancer puede distribuir peticiones a varios servidores que sirven contenido idéntico. Al utilizar Load Balancer con un grupo de servidores de memoria caché, llegará un momento en que el contenido al que se suele acceder habitualmente estará almacenado en la memoria caché de todos los servidores. Esto da soporte a una carga muy alta de clientes duplicando en varias máquinas el contenido idéntico almacenado en caché. Esto es de gran utilidad para sitios Web de alto volumen.
Sin embargo, si el sitio Web da soporte a un volumen moderado de tráfico de cliente para un contenido muy diverso, y si prefiere tener una memoria caché más grande a lo largo de varios servidores, el sitio tendrá un mejor rendimiento si cada servidor de caché incluye contenido exclusivo y Load Balancer sólo distribuye la petición al servidor de caché con dicho contenido.
Con la afinidad de URI, Load Balancer le permite distribuir el contenido almacenado en memoria caché a servidores individuales y elimina el almacenamiento en caché redundante del contenido en varias máquinas. Con esta mejora aumenta el rendimiento de sitios de servidores de contenido diverso que utilizan servidores Caching Proxy. Se enviarán peticiones idénticas al mismo servidor y de esta forma sólo se almacenará en memoria caché el contenido en servidores individuales. El tamaño real de la memoria caché irá aumentando con cada nueva máquina servidor añadida a la agrupación.
Para configurar la afinidad de URI:
La opción de afinidad de URI, para el mandato rule, sólo puede establecerse en URI si la opción port stickytime es cero (no habilitada). Cuando la afinidad de URI está activa en una regla, no se puede habilitar el tiempo de permanencia en memoria en el puerto.
Esta característica sólo está disponible para el componente Dispatcher.
Si no utiliza el soporte de área amplia de Dispatcher y no utiliza el método de reenvío NAT de Dispatcher, una configuración de Dispatcher requiere que la máquina Dispatcher y todos sus servidores estén conectados al mismo segmento de LAN (consulte la Figura 35). La petición de un cliente llega a la máquina Dispatcher y se envía al servidor. Desde el servidor la respuesta se envía directamente al cliente.
Figura 35. Ejemplo de una
configuración que consta de un único segmento LAN
La característica Dispatcher de área amplia añade soporte para servidores que están en otros sitios, llamados servidores remotos (consulte la Figura 36). Si no se da soporte a GRE en el sitio remoto y no está utilizando el método de reenvío NAT de Dispatcher, el sitio remoto debe constar de una máquina Dispatcher remota (Dispatcher 2) y de sus servidores conectados localmente (ServidorG, ServidorH y ServidorI). Se transferirán los paquetes del cliente desde Internet a la máquina Dispatcher inicial. Desde la máquina Dispatcher inicial, se transferirá entonces el paquete a una máquina Dispatcher remota geográficamente y a uno de sus servidores conectados localmente.
Todas las máquinas Dispatcher (local y remota) deben estar en el mismo tipo de sistema operativo y plataforma para ejecutar configuraciones de área amplia.
Figura 36. Ejemplo de configuración mediante servidores locales y remotos
Esto permite que una dirección de clúster dé soporte a todas las peticiones de cliente mundiales a la vez que distribuye la carga por servidores situados en todo el mundo.
La máquina Dispatcher que recibe inicialmente el paquete aún puede tener conectados servidores locales y puede distribuir la carga entre sus servidores locales y los servidores remotos.
Para configurar el soporte del área amplia:
dscontrol server add clúster:puerto:servidor router dirección
Para obtener más información sobre la palabra clave router, consulte el apartado dscontrol server -- configurar servidores.
En Dispatchers de punto de entrada:
Los Dispatchers de punto de entrada que se ejecutan en plataformas AIX, Linux (con GRE) o Solaris mostrarán correctamente cargas del asesor de visualización. Otras plataformas tendrán que confiar en el equilibrio de carga mediante el algoritmo de turno rotativo o utilizar los métodos de reenvío nat/cbr de Dispatcher en lugar de la red de área amplia.
Sistemas AIX
Sistemas HP-UX
Sistemas Linux
Sistemas Solaris
arp -s mi_dirección_clúster mi_dirección_MAC pub
Sistemas Windows
En sistemas Dispatcher remotos: realice los siguientes pasos de configuración para cada dirección de clúster remoto. Para una configuración de alta disponibilidad en la ubicación del sistema Dispatcher remoto, debe llevar a cabo estos pasos en las dos máquinas.
Sistemas AIX
ifconfig en0 alias 10.10.10.99 netmask 255.255.255.255
dscontrol executor configure 204.67.172.72 en0 255.255.255.255
Sistemas HP-UX, Linux, Solaris y Windows
Figura 37. Configuración del ejemplo de área amplia con varios Load Balancer remotos
Este ejemplo se aplica a la configuración que se muestra en la Figura 37.
Aquí se muestra cómo configurar las máquinas Dispatcher para dar soporte a la dirección de clúster xebec en el puerto 80. LB1 se define como Load Balancer de "punto de entrada". Se da por supuesto una conexión Ethernet. Tenga en cuenta que LB1 tiene definidos cinco servidores: tres locales (ServidorA, ServidorB, ServidorC) y dos remotos (LB2 y LB3). Cada uno de los servidores LB2 y LB3 remotos tiene definido tres servidores locales.
En la consola de la primera máquina Dispatcher (LB1):
dscontrol executor start
dscontrol executor set nfa LB1
dscontrol cluster add xebec
dscontrol port add xebec:80
dscontrol executor configure xebec
En la consola de la segunda máquina Dispatcher (LB2):
dscontrol executor start
dscontrol executor set nfa LB2
dscontrol cluster add xebec
dscontrol port add xebec:80
En la consola de la tercera máquina Dispatcher (LB3):
dscontrol executor start
dscontrol executor set nfa LB3
dscontrol cluster add xebec
dscontrol port add xebec:80
El encapsulamiento genérico de direccionamiento (GRE) es un Internet Protocolo especificado en RFC 1701 y RFC 1702. Si utiliza GRE, Load Balancer puede encapsular paquetes IP del cliente dentro de paquetes IP/GRE y remitirlos a plataformas de servidor como OS/390 que permiten el uso de GRE. El soporte de GRE permite al componente Dispatcher equilibrar la carga de paquetes en varias direcciones de servidores asociadas a una dirección MAC.
Load Balancer implementa GRE como parte de su característica WAN. Esto permite que Load Balancer proporcione equilibrio de carga de área local directamente a todos los sistemas de servidor que puedan abrir los paquetes GRE. No es necesario que Load Balancer esté instado en el sitio remoto, si los servidores remotos dan soporte a paquetes GRE encapsulados. Load Balancer encapsula paquetes WAN con el campo clave GRE establecido en un valor decimal 3735928559.
En este ejemplo (Figura 38), para añadir el ServidorD remoto, que da soporte a GRE, defínalo dentro de la configuración de Load Balancer como si estuviera definiendo un servidor de WAN en la jerarquía clúster:puerto:servidor:
dscontrol server add clúster:puerto:ServidorD router Direccionador
Los sistemas Linux tienen la capacidad nativa para excapsular GRE que permite a Load Balancer equilibrar la carga en las imágenes del servidor Linux para s/390, donde muchas imágenes de servidor comparten una dirección MAC. Esto permite que Load Balancer de punto de entrada equilibre la carga directamente en servidores WAN de Linux, sin pasar a través de un sistema Load Balancer en el sitio remoto. También permite que los asesores del sistema Load Balancer de punto de entrada operen directamente con cada servidor remoto.
En el sistema Load Balancer de punto de entrada, configúrelo para WAN tal como se describe.
Para configurar cada servidor del programa de fondo Linux, emita los siguientes mandatos como usuario root. (Estos mandatos se pueden añadir al recurso de inicio del sistema para que los cambios se mantengan en los rearranques).
# modprobe ip_gre # ip tunnel add gre-nd mode gre ikey 3735928559 # ip link set gre-nd up # ip addr add dirección_clúster dev gre-nd
En general, las funciones de equilibrio de carga de Dispatcher funcionan independientemente del contenido de los sitios en los que se utiliza el producto. No obstante, existe un área en la que el contenido del sitio puede ser importante y donde las decisiones que se han tomado respecto al contenido pueden tener un impacto significativo en la eficacia de Dispatcher. Se trata del área de direccionamiento de enlaces.
Si las páginas especifican enlaces que apuntan a servidores individuales del sitio, en realidad está forzando a un cliente a que vaya a una máquina específica y, por lo tanto, omitirá cualquier función de equilibrio de carga que podría estar aplicándose. Por esta razón, utilice siempre la dirección de Dispatcher en todos los enlaces contenidos en las páginas. Tenga en cuenta que es posible que el tipo de direccionamiento utilizado no sea siempre evidente, si el sitio utiliza programación automatizada que crea código HTML de forma dinámica. Para maximizar el equilibrio de carga, debe conocer bien todo el direccionamiento explícito y evitarlo cuando sea posible.
Puede configurar las máquinas Dispatcher y del servidor TCP utilizando una red privada. Esta configuración puede reducir el conflicto sobre la red pública o externa que puede afectar al rendimiento.
En sistemas AIX, esta configuración también puede beneficiarse de las velocidades rápidas del conmutador de alto rendimiento de SP(TM), si está ejecutando las máquinas Dispatcher y del servidor TCP en nodos que están en una trama SP.
Para crear una red privada, cada máquina debe tener cómo mínimo dos tarjetas de LAN y una de las tarjetas está conectada a la red privada. También debe configurar la segunda tarjeta de LAN en una subred distinta. La máquina Dispatcher enviará las peticiones de cliente a las máquinas servidor TCP a través de la red privada.
Sistemas Windows: configure la dirección de no reenvío con el mandato executor configure.
Los servidores añadidos con el mandato dscontrol server add deben añadirse utilizando las direcciones de la red privada; por ejemplo, si nos remitimos al ejemplo del servidor Apple en la Figura 39, el mandato debería codificarse en la forma:
dscontrol server add dirección_clúster:80:10.0.0.1
no
dscontrol server add dirección_clúster:80:9.67.131.18
Si utiliza Site Selector para proporcionar información de carga en Dispatcher, debe configurar Site Selector de modo que notifique las cargas en las direcciones privadas.
Figura 39. Ejemplo de una red privada que utiliza Dispatcher
La utilización de la configuración de red privada sólo se aplica al componente Dispatcher.
La utilización de clúster comodín para combinar configuraciones de servidor sólo se aplica al componente Dispatcher.
La palabra "comodín" hace referencia a la capacidad del clúster para emparejar varias direcciones IP (es decir, actúa como un comodín). La dirección del clúster 0.0.0.0 se utiliza para especificar un clúster comodín.
Si tiene muchas direcciones de clúster en las que se debe equilibrar la carga y las configuraciones de puerto/servidor son idénticas en todos los clústeres, puede combinar todos los clústeres en una configuración de clúster comodín.
Deberá configurar de forma explícita cada dirección de clúster en uno de los adaptadores de la red de la estación de trabajo de Dispatcher. Sin embargo, no debe añadir ninguna de las direcciones de clúster a la configuración de Dispatcher utilizando el mandato dscontrol cluster add.
Únicamente añada un clúster comodín (dirección =.0.0.0) y configure los puertos y servidores como se requiere para el equilibrio de carga. Se equilibra la carga de todo el tráfico que se dirija a cualquiera de las direcciones configuradas del adaptador utilizando la configuración del clúster comodín.
Una ventaja de este método es que, al determinar cuál es el mejor servidor al que dirigirse, se toma en cuenta el tráfico dirigido a todas las direcciones del clúster. Si un clúster recibe mucho tráfico y ha creado muchas conexiones activas en uno de los servidores, con esta información se equilibra la carga del tráfico que se dirige a otras direcciones del clúster.
Si tiene algunas direcciones de clúster con configuraciones de puerto/servidor exclusivas y algunas con configuraciones comunes, puede combinar el clúster comodín con clústeres reales. Se debe asignar cada una de las configuraciones exclusivas a una dirección de clúster real. Todas las configuraciones comunes pueden asignarse al clúster comodín.
La utilización de clúster comodín para equilibrar la carga de cortafuegos sólo se aplica al componente Dispatcher. La dirección del clúster 0.0.0.0 se utiliza para especificar un clúster comodín.
El clúster comodín puede utilizarse para equilibrar la carga del tráfico en direcciones que no están configuradas de forma explícita en ningún adaptador de red de la estación de trabajo de Dispatcher. Para que esto funcione, Dispatcher como mínimo debe poder ver todo el tráfico en el que se va a equilibrar la carga. La estación de trabajo de Dispatcher no verá el tráfico que se dirige a las direcciones que no se han configurado de forma explícita en uno de sus adaptadores de red, a menos que se configure como la ruta predeterminada para algún conjunto de tráfico.
Después de configurar Dispatcher como una ruta predeterminada, la carga de todo el tráfico TCP o UDP que pase por la máquina Dispatcher se equilibra utilizando la configuración de clúster comodín.
Esto se aplica pare equilibrar la carga de cortafuegos. Puesto que los cortafuegos pueden procesar paquetes para cualquier dirección de destino y cualquier puerto de destino, es necesario poder equilibrar la carga del tráfico independientemente de la dirección y el puerto de destino.
Los cortafuegos se utilizan para manejar el tráfico de clientes no seguros a servidores seguros, y las respuestas de los servidores seguros, así como el tráfico de clientes que están en el lado seguro a servidores que están en el lado no seguro y las respuestas.
Debe configurar dos máquinas Dispatcher, una para equilibrar la carga del tráfico no seguro dirigido a las direcciones de cortafuegos no seguro y otra para equilibrar la carga del tráfico seguro dirigido a las direcciones del cortafuegos seguro. Puesto que los dos sistemas Dispatcher deben utilizar el clúster comodín y el puerto comodín con distintos conjuntos de direcciones de servidores, los dos sistemas Dispatcher deben estar en dos estaciones de trabajo separadas.
La utilización del clúster comodín con Caching Proxy para el proxy transparente sólo se aplica al componente Dispatcher. La dirección del clúster 0.0.0.0 se utiliza para especificar un clúster comodín.
La función de clúster comodín también permite que Dispatcher se utilice para habilitar una función de proxy transparente para un servidor Caching Proxy que resida en la misma máquina que Dispatcher. Esta característica sólo es de AIX, porque debe haber comunicación entre el componente Dispatcher y el componente TCP del sistema operativo.
Para habilitar esta característica, debe iniciar Caching Proxy escuchando peticiones de cliente en el puerto 80. A continuación, configure un clúster comodín (0.0.0.0). En el clúster comodín, configure el puerto 80. En el puerto 80, configure la NFA de la máquina Dispatcher como el único servidor. Ahora, todo el tráfico de cliente dirigido a cualquier dirección del puerto 80 se entrega al servidor Caching Proxy que se ejecuta en la estación de trabajo de Dispatcher. La petición de cliente se dirigirá a través del proxy de la forma habitual y la respuesta se devuelve de Caching Proxy al cliente. En esta modalidad, el componente Dispatcher no realiza ningún equilibrio de carga.
Se puede utilizar un puerto comodín puede manejar el tráfico que no está destinado a ningún puerto configurado de forma explícita. Un uso de lo anterior es para el equilibrio de carga de cortafuegos. Un segundo uso es para asegurar que el tráfico destinado a un puerto no configurado se maneja de forma adecuada. Mediante la definición de un puerto comodín sin servidores, garantizará que se descarte cualquier petición destinada a un puerto que no se haya configurado en lugar de devolverse al sistema operativo. El número de puerto 0 (cero) se utiliza para especificar el puerto comodín, por ejemplo:
dscontrol port add clúster:0
Cuando se configura un clúster para manejar el FTP pasivo y el puerto comodín, el FTP pasivo predeterminado utiliza el rango completo de puertos TCP sin privilegios para las conexiones de datos. Esto significa que un cliente, con una conexión existente a través de un clúster de equilibrio de carga a un puerto de control FTP, tendrá conexiones de control y conexiones de puertos altos (puerto >1023)subsiguientes al mismo clúster direccionadas automáticamente por Load Balancer al mismo servidor que el de la conexión de control FTP.
Si el puerto comodín y el puerto FTP, en el mismo clúster, no tienen el mismo conjunto de servidores, entonces es posible que las aplicaciones de puertos altos (puerto >1023) fallen cuando un cliente tenga una conexión de control FTP. Por lo tanto, no se recomienda configurar distintos conjuntos de servidores para los puertos FTP y comodín en el mismo clúster. Si se desea este escenario, se debe configurar el rango de puertos pasivos del daemon de FTP en la configuración de Load Balancer.
Esta característica sólo está disponible para el componente Dispatcher.
Dispatcher proporciona la capacidad de detectar ataques para "rechazo de servicio" (DoS) potenciales y notifica a los administradores mediante una alerta. Dispatcher lo lleva a cabo analizando las peticiones entrantes para una cantidad llamativa de conexiones TCP medio abiertas en servidores, un rasgo común de los ataques simples para rechazo de servicio (DoS). En un ataque para rechazo de servicio (DoS), un sitio recibe una gran cantidad de paquetes SYN fabricados procedentes de un gran número de direcciones IP de origen y números de puerto de origen, pero el sitio no recibe paquetes posteriores para estas conexiones TCP. Esto resulta en un gran número de conexiones TCP medio abiertas en los servidores y, con el tiempo, los servidores pueden funcionar muy lentamente y no aceptar nuevas conexiones entrantes.
Load Balancer ofrece salidas de usuario que desencadenan scripts que se pueden personalizar y que avisan al administrador de un posible ataque para rechazo de servicio (DoS). Dispatcher proporciona el siguiente script de ejemplo en el directorio ...ibm/edge/lb/servers/samples:
Para ejecutar los archivos, debe ponerlos en el directorio ...ibm/edge/lb/servers/bin y eliminar la extensión de archivo ".sample".
Para implementar la detección del ataque DoS, establezca el parámetro maxhalfopen en el mandato dscontrol port tal como se indica a continuación:
dscontrol port set 127.40.56.1:80 maxhalfopen 1000
En el ejemplo anterior, Dispatcher comparará el número total actual de conexiones medio abiertas (para todos los servidores que residen en el clúster 127.40.56.1 en el puerto 80) con el valor de umbral 1000 (especificado por el parámetro maxhalfopen). Si el número de conexiones medio abiertas actuales excede el umbral, se realiza una llamada al script de alerta (halfOpenAlert). Cuando el número de conexiones medio abiertas es inferior al umbral, se realiza una llamada a otro script de alerta (halfOpenAlertDone) para indicar que el ataque ha terminado.
Para determinar cómo establecer el valor maxhalfopen: ejecute periódicamente (quizás cada 10 minutos) un informe de conexiones medio abiertas (dscontrol port halfopenaddressreport clúster:puerto) cuando la cantidad de tráfico del sitio oscile de normal a elevada. El informe de conexiones medio abiertas devolverá el "total de conexiones medio abiertas recibidas" actuales. Debe establecer maxhalfopen en un valor entre un 50 y un 200% mayor que el número más alto de conexiones medio abiertas que se producen en el sitio.
Además de los datos estadísticos reportados, halfopenaddressreport también genera entradas en las anotaciones cronológicas (..ibm/edge/lb/servers/logs/dispatcher/halfOpen.log) para todas las direcciones de cliente (hasta aproximadamente 8000 pares de direcciones) que han accedido a servidores que han resultado en conexiones medio abiertas.
Para proporcionar protección adicional de los ataques para rechazo de servicio (DoS) para servidores de programas de fondo, puede configurar puertos y clústeres comodín. En concreto, añada un puerto comodín sin servidores bajo cada clúster configurado. Añada también un clúster comodín con un puerto comodín y sin servidores. Esto provocará que se descarten todos los paquetes que no se dirijan a un clúster y puerto que no sea comodín. Para obtener información sobre clústeres comodín y puertos comodín, consulte los apartados Utilizar un clúster comodín para combinar configuraciones de servidores y Utilizar el puerto comodín para dirigir el tráfico de puerto no configurado.
El registro cronológico binario permite almacenar información de servidor 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.
Parte de esta información se recupera del ejecutor como parte del ciclo del gestor. Por lo tanto, para que la información se pueda anotar cronológicamente en las anotaciones cronológicas en binario, el gestor debe estar en ejecución.
Utilice el mandato dscontrol binlog establecido 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 gestor, é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 gestor y del 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 gestor, si se establece el intervalo de anotaciones cronológicas en un valor inferior al valor del intervalo del gestor en realidad se establece en el mismo valor que el intervalo del gestor. 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 gestor para calcular pesos de servidor. No obstante, esta cantidad de información probablemente no es necesaria para analizar tendencias y utilización 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 sucederá si el gestor está llamando al servidor de anotaciones cronológicas, por lo tanto, si detiene el gestor no se suprimirán los archivos de anotaciones cronológicas antiguos.
La opción de estado devuelve los valores actuales del servicio de anotaciones cronológicas. Estos valores indican si el servicio se ha iniciado, el intervalo y las horas de retención.
Se proporciona un archivo de mandatos y un programa Java de ejemplo en el directorio ...ibm/edge/lb/servers/samples/BinaryLog. 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. Un ejemplo de la utilización del script proporcionado y el programa para Dispatcher sería:
dslogreport 2001/05/01 8:00 2001/05/01 17:00
para obtener un informe con la información de servidor del componente Dispatcher para el día 1 de mayo de 2001, de las 8:00 a las 17:00. (Para CBR, utilice cbrlogreport).
Sólo los sistemas Linux dan soporte a configuraciones en las que el cliente se encuentra en la misma máquina que Load Balancer.
Las configuraciones de cliente con ubicación compartida pueden no funcionar correctamente en otras plataformas porque Load Balancer utiliza distintas técnicas para examinar los paquetes de entrada en los diversos sistemas operativos a los que da soporte. En la mayoría de los casos, en sistemas que no sean Linux, Load Balancer no recibe paquetes que proceden de la máquina local. Sólo recibe paquetes que proceden de la red. Debido a ello, Load Balancer no recibirá las peticiones realizadas desde la máquina local a la dirección de clúster y no podrá atenderlas
Este capítulo incluye los apartados siguientes:
Cisco CSS Controller o Nortel Alteon Controller 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 Cisco CSS Controller y Nortel Alteon Controller.
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 conocer la sintaxis completa de 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 secondary
Los 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.20
Debe configurarse el mismo número de destinos de alcance en los controladores local y asociado.
xxxcontrol highavailability start auto
xxxcontrol highavailability report
xxxcontrol highavailability takeover
Esto sólo es necesario para realizar el mantenimiento.
Notas:
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 hosts a los que deben acceder los controladores para funcionar correctamente. Debe haber cómo mínimo un host para cada subred que utiliza la máquina del controlador. Estos hosts pueden ser direccionadores, servidores IP u otros tipos de hosts.
La accesibilidad de hosts se obtiene mediante el asesor de alcance que emite el mandato ping al host. 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 Cisco CSS Controller, consulte los Ejemplos.
Para obtener ejemplos de configuración de alta disponibilidad de Nortel Alteon Controller, consulte los 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 predeterminada 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%. De manera predeterminada, 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 del 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 Cisco CSS Controller y Nortel Alteon Controller, 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 Cisco CSS Controller o el mandato nalcontrol server en Nortel Alteon Controller.
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 predeterminada 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 predeterminado, escriba el siguiente mandato:
xxxcontrol consultant set ID_consultor sensitivity porcentaje_cambio
En la mayoría de los casos, no es necesario cambiar este valor.
Los asesores son agentes incluidos en 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 de servidor anómalo más rápida, 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 predeterminado 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 predeterminado 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 regla 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 directorio de instalación ...ibm/edge/lb/servers/samples/CustomAdvisors.
Los directorios de instalación predeterminado son:
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 ser parecido al siguiente:
dir_instalación/java/bin/javac -classpath dir_instalación\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 de instalación ...ibm/edge/lb/servers/lib/CustomAdvisors.
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:
...ibm/edge/lb/servers/lib/CustomAdvisors/ADV_pam.class
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.
/opt/ibm/edge/lb/servers/lib/CustomAdvisors/
C:\Archivos de programa\IBM\edge\lb\servers\lib\CustomAdvisors
La lista de programas de un asesor de ejemplo de controlador se incluye en Asesor de ejemplo. Después de la instalación, este asesor de ejemplo puede encontrarse en el directorio ...ibm/edge/lb/servers/samples/CustomAdvisors .
Metric Server proporciona información de carga de servidor para Load Balancer en la forma de métricas específicas del sistema que notifica el estado de los servidores. El consultor de Load Balancer examina el agente de Metric Server que reside en cada uno de los servidores y asigna 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 Cisco CSS Controller o en el informe de servidor de Nortel Alteon Controller.
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 Nortel Alteon Controller, 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. Este 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 script personalizados son ejecutables y que están en el directorio ...ibm/edge/lb/ms/script. Los scripts personalizados deben devolver un valor de carga numérico.
Para que Metric Server se ejecute en una dirección distinta del host 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 para una dirección en la pila de Microsoft, consulte la página Configuración de un alias en la pila de Microsoft para Metric Server.
WLM es el código que se ejecuta en hosts MVS. Puede consultarse para saber la carga de 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 host 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.
El dispositivo de registro cronológico binario permite almacenar información de servidor 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 archivo de mandato y un programa Java en el directorio ...ibm/edge/lb/servers/samples/BinaryLog. 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 de instalación ...ibm/edge/lb/servers/samples. Para ejecutar los archivos, cópielos en el directorio ...ibm/edge/lb/servers/bin y, a continuación, cambie el nombre de cada archivo de acuerdo con las instrucciones incluidas en el script.
Se proporcionan los siguientes scripts de ejemplo, donde xxx es cco para Cisco CSS Controller, y nal para Nortel Alteon Controller:
En esta parte se proporciona información sobre cómo administrar y resolver problemas de Load Balancer. Contiene los capítulos siguientes:
En este capítulo se describe cómo operar y gestionar Load Balancer e incluye estos apartados:
Load Balancer proporciona dos modos distintos de ejecutar los programas de configuración en una máquina aparte de aquella en la que reside Load Balancer. La comunicación entre los programas de configuración (dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol) y el servidor (dsserver, cbrserver, etc.) se puede realizar utilizando uno de estos métodos:
La ventaja de la administración remota utilizando RMI es que el rendimiento es más rápido que la administración basada en la Web.
Las ventajas de utilizar la administración basada en la Web es que proporciona administración remota, autenticada y segura y se puede comunicar con la máquina Load Balancer aún cuando esté presente un cortafuegos. Además, este método de administración no requiere la instalación y el uso de claves de autenticación (lbkeys) en la máquina cliente remota que se comunica con la máquina Load Balancer.
Para RMI, el mandato para conectar con una máquina de Load Balancer para la administración remota es dscontrol host:host_remoto.
Si la llamada a RMI procede de una máquina que no sea la máquina local, debe producirse una secuencia de autenticación de clave pública/privada antes de que sea aceptado el mandato de configuración.
La comunicación entre los programas de control que se ejecutan en la misma máquina que los servidores del componente no se autentica.
Utilice este mandato para generar claves públicas y privadas que se van a utilizar para autenticación remota:
Este mandato se ejecuta sólo en la misma máquina que Load Balancer.
El uso de la opción create crea una clave privada en el subdirectorio key del directorio servers (...ibm/edge/lb/servers/key/) y crea claves públicas en el subdirectorio keys del directorio admin (...ibm/edge/lb/admin/keys/) para cada uno de los componentes de Load Balancer. El nombre de archivo para la clave pública es: componente- DirecciónServidor-puertoRMI. Estas claves públicas deben transportarse entonces a los clientes remotos y colocarse en el subdirectorio keys del directorio admin.
Para una máquina de Load Balancer con la dirección de nombre de host 10.0.0.25 que utiliza el puerto RMI predeterminado para cada componente, el mandato lbkeys create genera estos archivos:
El conjunto de archivos de administración se ha instalado en otra máquina. Los archivos de clave pública deben ubicarse en el directorio ...ibm/edge/lb/admin/keys de la máquina cliente remota.
Ahora se autorizará al cliente remoto para configurar Load Balancer en 10.0.0.25.
Se deben utilizar estas mismas claves en todos los clientes remotos que desea autorizar para configurar Load Balancer en 10.0.0.25.
Si fuera a ejecutar de nuevo el mandato lbkeys create, se generaría un nuevo conjunto de claves públicas/privadas. Esto significaría que todos los clientes remotos que intentaran conectar con las claves anteriores no serían autorizados. La nueva clave tendría que ubicarse en el directorio correcto de los clientes a los que deseara volver a autorizar.
El mandato lbkeys delete suprime las claves privadas y públicas en la máquina servidor. Si se suprimen estas claves, no se autorizará a ningún cliente remoto para conectarse con los servidores.
Para los dos mandatos: lbkeys create y lbkeys delete, hay una opción force. La opción force suprime las indicaciones del mandato que solicitan si desea sobrescribir o suprimir las claves existentes.
Después de establecer la conexión RMI, puede comunicar entre los programas de configuración utilizando los mandatos: dscontrol, cbrcontrol, sscontrol, ccocontrol, nalcontrol, dswizard, cbrwizard y sswizard desde un indicador de mandatos. También puede configurar Load Balancer mediante la GUI escribiendo lbadmin en un indicador de mandatos.
Para utilizar administración basada en la Web, se necesita lo siguiente en la máquina cliente que realiza la administración remota:
Se necesita lo siguiente en la máquina de host a la que accede para realizar la administración remota basada en la Web:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess C:\ARCHIV~1\IBM\edge\lb\admin\lbwebaccess.pl Pass /lb-admin/help/* C:\ARCHIV~1\IBM\edge\lb\admin\help\* Pass /lb-admin/*.jar C:\ARCHIV~1\IBM\edge\lb\admin\lib\*.jar Pass /lb-admin/* C:\ARCHIV~1\IBM\edge\lb\admin\* Pass /documentation/idioma/* C:\ARCHIV~1\IBM\edge\lb\documentation\idioma\*donde idioma es el subdirectorio de idioma (por ejemplo, en_US)
En sistemas Linux y UNIX:
Protect /lb-admin/lbwebaccess PROT-ADMIN Exec /lb-admin/lbwebaccess /opt/ibm/edge/lb/admin/lbwebaccess.pl Pass /lb-admin/help/* /opt/ibm/edge/lb/admin/help/* Pass /lb-admin/*.jar /opt/ibm/edge/lb/admin/lib/*.jar Pass /lb-admin/* /opt/ibm/edge/lb/admin/* Pass /documentation/idioma/* /opt/ibm/edge/lb/documentation/idioma/*
ln -s /opt/perl/bin/perl /usr/bin/perl
Para ejecutar la administración basada en la Web, debe iniciarse ésta en la máquina de host de Load Balancer: emita lbwebaccess en el indicador de mandatos de la máquina de host.
También se necesita el ID de usuario y la contraseña para la máquina de host a la que va a acceder de forma remota. El ID de usuario y la contraseña son los mismos que para la administración de Caching Proxy.
Para presentar la administración basada en la Web de Load Balancer, acceda a esta dirección URL en el navegador Web de la ubicación remota:
http:// nombre_host/lb-admin/lbadmin.html
Donde nombre_host es el nombre de la máquina a la que va a acceder para comunicarse con Load Balancer.
Una vez que se ha cargado la página Web, aparecerá la GUI de Load Balancer en la ventana del navegador para que realice la administración remota basada en la Web.
Desde la GUI de Load Balancer, también puede emitir mandatos de control de configuración. Para emitir un mandato desde la GUI:
Renovación de la configuración de forma remota
Con la administración remota basada en la Web, si hay varios administradores actualizando la configuración de Load Balancer desde otras ubicaciones, tendrá que renovar la configuración para consultar (por ejemplo) el clúster, el puerto o el servidor que otro administrador ha añadido (o suprimido). La GUI de administración remota basada en la Web proporciona una función de Renovar configuración y Renovar todas las configuraciones.
Desde la GUI basada en la Web, para renovar la configuración
Load Balancer envía entradas a un archivo de anotaciones cronológicas de: el servidor, el gestor y el supervisor de métrica (que anota las comunicaciones con agentes Metric Server) así como a un archivo de anotaciones cronológicas para cada asesor que utiliza.
Puede establecer el nivel de anotaciones para definir la expansividad de los mensajes grabados en el archivo de anotaciones cronológicas. En el nivel 0, se anotan los errores y Load Balancer también anota las cabeceras y los registros de sucesos que suceden sólo una vez (por ejemplo, un mensaje sobre un asesor que se empieza a grabar en el archivo de anotaciones cronológicas del gestor). El nivel 1 incluye la información en curso y, así sucesivamente, con el nivel 5 incluyendo todos los mensajes producidos para ayudar a depurar un problema si es necesario. El valor predeterminado de los archivos de anotaciones cronológicas de: el gestor, el asesor, el servidor o el subagente es 1.
También puede establecer el tamaño máximo de un archivo de anotaciones cronológicas. Cuando se establece un tamaño máximo para el archivo de anotaciones cronológicas, el texto del archivo vuelve al principio; es decir, cuando el archivo alcanza el tamaño especificado, las entradas subsiguientes se anotarán al principio del archivo y se grabarán encima de las entradas de anotaciones cronológicas anteriores. No puede establecer el tamaño de archivo de anotaciones cronológicas en un valor que sea menor que el actual. Las entradas del archivo de anotaciones cronológicas llevarán la indicación de la hora, para que pueda indicar el orden en el que se han grabado.
Cuanto más alto establezca el nivel de anotaciones, debería escoger con más cuidado el tamaño de archivo de anotaciones cronológicas. En el nivel 0, probablemente sea seguro dejar el tamaño de archivo de anotaciones cronológicas con el valor predeterminado de 1MB; no obstante, cuando realiza las anotaciones a nivel 3 y superior, limite el tamaño sin hacerlo demasiado pequeño para que resulte de utilidad.
De manera predeterminada, los archivos de anotaciones cronológicas generados por Load Balancer se almacenan en el directorio logs de la instalación de Load Balancer. Para cambiar esta vía de acceso, establezca la variable lb_logdir en el script dsserver.
Sistemas AIX, HP-UX, Linux y Solaris: el script dsserver se encuentra en el directorio /usr/bin. En este script, la variable lb_logdir está establecida en el directorio predeterminado. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
LB_LOGDIR=/víaAcceso/a/mis/anotaciones/
Sistemas Windows: el archivo dsserver se encuentra en el directorio del sistema Windows C:\WINNT\SYSTEM32, para Windows 2003. En el archivo dsserver, la variable lb_logdir está establecida en el directorio predeterminado. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
set LB_LOGDIR=c:\víaAcceso\a\mis\anotaciones\
Para todos los sistemas operativos, asegúrese de que no haya espacios a ambos lados del signo igual y que la vía de acceso finaliza con una barra inclinada o invertida ("/" o "\") según sea adecuado.
La característica de anotaciones cronológicas binarias de Load Balancer utiliza el mismo directorio de anotaciones cronológicas que los demás archivos de anotaciones cronológicas. Consulte el apartado Utilización del registro cronológico binario para analizar estadísticas de servidor.
Puede establecer el nivel de anotaciones para definir la expansividad de los mensajes grabados en el archivo de anotaciones cronológicas. En el nivel 0, se anotan los errores y Load Balancer también anota las cabeceras y los registros de sucesos que suceden sólo una vez (por ejemplo, un mensaje sobre un asesor que se empieza a grabar en el archivo de anotaciones cronológicas del consultor). El nivel 1 incluye la información en curso y, así sucesivamente, con el nivel 5 incluyendo todos los mensajes producidos para ayudar a depurar un problema si es necesario. El valor predeterminado para los archivos de anotaciones cronológicas es 1.
También puede establecer el tamaño máximo de un archivo de anotaciones cronológicas. Si establece un tamaño máximo para el archivo de anotaciones cronológicas, el archivo se envolverá; cuando el archivo alcance el tamaño especificado, las entradas subsiguientes se grabarán al principio del archivo, sobrescribiendo las entradas del archivo de anotaciones cronológicas anteriores. No puede establecer el tamaño de archivo de anotaciones cronológicas en un valor que sea menor que el actual. Las entradas del archivo de anotaciones cronológicas llevarán la indicación de la hora, para que pueda indicar el orden en el que se han grabado.
Cuanto más alto establezca el nivel de anotaciones, debería escoger con más cuidado el tamaño de archivo de anotaciones cronológicas. En el nivel 0, probablemente sea seguro dejar el tamaño de archivo de anotaciones cronológicas con el valor predeterminado de 1MB; no obstante, cuando realiza las anotaciones a nivel 3 y superior, limite el tamaño sin hacerlo demasiado pequeño para que resulte de utilidad.
Cisco CSS Controller y Nortel Alteon Controller tienen anotaciones cronológicas como se detalla a continuación:
A continuación figura un ejemplo de cómo configurar el nivel de anotaciones y el tamaño máximo de las anotaciones cronológicas para el archivo de anotaciones cronológicas del supervisor de métrica que anota las comunicaciones con agentes Metric Server:
xxxcontrol metriccollector set IDconsultor:IDservicio:nombreMétrica loglevel x logsize y
De manera predeterminada, las anotaciones cronológicas generadas por los controladores se almacenarán en el directorio logs de la instalación del controlador. Para cambiar esta vía de acceso, establezca la variable xxx_logdir en el script xxxserver.
Sistemas AIX, HP-UX, Linux y Solaris: el script xxxserver se encuentra en el directorio /usr/bin. En este script, la variable xxx_logdir está establecida en el directorio predeterminado. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
xxx_LOGDIR=/víaAcceso/a/mis/anotaciones/
Sistemas Windows: el archivo xxxserver se encuentra en el directorio del sistema Windows, normalmente C:\WINNT\SYSTEM32. En el archivo xxxserver, la variable xxx_logdir está establecida en el directorio predeterminado. Puede modificar esta variable para especificar su directorio de archivo de anotaciones cronológicas. Ejemplo:
set xxx_LOGDIR=c:\víaAcceso\a\mis\anotaciones\
Para todos los sistemas operativos, asegúrese de que no haya espacios a ambos lados del signo igual y que la vía de acceso finaliza con una barra inclinada o invertida ("/" o "\") según sea adecuado.
La característica de anotaciones cronológicas binarias de Load Balancer utiliza el mismo directorio de anotaciones cronológicas que los demás archivos de anotaciones cronológicas. Consulte el apartado Utilización del registro cronológico binario para analizar estadísticas de servidor.
En este apartado se describe cómo operar y gestionar el componente Dispatcher.
Para Load Balancer, se considera que las conexiones están inactivas cuando no ha habido actividad en esa conexión durante el número de segundos especificado en el tiempo de espera sin actividad. Cuando se supere el número de segundos sin actividad, Load Balancer eliminará ese registro de conexión de sus tablas y se descartará el tráfico subsiguiente para esa conexión.
A nivel de puerto, por ejemplo, puede especificar el valor de tiempo de espera sin actividad en el mandato dscontrol port set staletimeout.
El tiempo de espera sin actividad se puede establecer a nivel de ejecutor, clúster y puerto. A nivel de ejecutor y de clúster, el valor predeterminado son 300 segundos y se filtra hasta el puerto. A nivel de puerto, el valor predeterminado depende del puerto. Algunos puertos bien definidos tienen valores distintos de tiempo de espera sin actividad. Por ejemplo, el puerto telnet 23 tiene un valor predeterminado de 259.200 segundos.
Algunos servicios también pueden tener valores de tiempo de espera sin actividad propios. Por ejemplo, LDAP (Lightweight Directory Access Protocol) tiene un parámetro de configuración denominado idletimeout. Cuando se han superado idletimeout segundos, se forzará el cierre de una conexión de cliente desocupado. También se puede establecer idletimeout en 0, lo que significa que nunca se forzará el cierre de la conexión.
Se pueden producir problemas de conectividad si el valor de tiempo de espera sin actividad de Load Balancer es menor que el valor de tiempo de espera del servicio. En el caso de LDAP, el valor de tiempo de espera sin actividad de Load Balancer se establece predeterminado en 300 segundos. Si no hay actividad en la conexión durante 300 segundos, Load Balancer eliminará el registro de conexión de sus tablas. Si el valor de idletimeout es mayor que 300 segundos (o está establecido en 0), el cliente todavía cree que tiene una conexión con el servidor. Cuando el cliente envíe paquetes, Load Balancer los descartará. Esto provocará que se cierre la comunicación de LDAP cuando se realice una petición al servidor. Para evitar este problema, establezca el idletimeout de LDAP en un valor que no sea cero, que sea igual o menor que el valor de tiempo de espera sin actividad de Load Balancer.
Un cliente envía un paquete FIN después de que ha enviado todos sus paquetes, para que el servidor sepa que ha finalizado la transacción. Cuando Dispatcher recibe el paquete FIN, marca la transacción de estado activo a estado FIN. Cuando una transacción se marca como FIN, se puede borrar la memoria reservada para la conexión.
Con el fin de mejorar el rendimiento de la asignación y reutilización del registro de conexión, utilice el mandato executor set fintimeout para controlar el período durante el cual Dispatcher conservará conexiones en el estado FIN, activas en las tablas de Dispatcher y aceptando tráfico. Cuando una conexión en el estado FIN supera el tiempo de espera de conexiones finalizadas, se eliminará de las tablas de Dispatcher y estará preparada para reutilizarse. Puede cambiar el tiempo de espera de FIN utilizando el mandato dscontrol executor set fincount.
Utilice el mandato dscontrol executor set staletimeout con el fin de controlar el período durante el que Dispatcher debería conservar conexiones en el estado de establecidas, cuando no se haya visto tráfico activo en las tablas de Dispatcher ni aceptar tráfico. Consulte el apartado Utilización del valor de tiempo de espera sin actividad para obtener más información.
Se pueden mostrar distintos diagramas según la información del ejecutor y transmitirse al gestor. (La opción de menú Supervisar de la GUI requiere que la función de gestor esté en ejecución):
Un sistema de gestión de red es un programa que se ejecuta continuamente y se utiliza para supervisar, reflejar el estado y controlar una red. El conocido protocolo SNMP (Protocolo simple de gestión de red) para comunicarse con dispositivos en red, es el estándar de gestión de red actual. Los dispositivos de red normalmente tienen un agente SNMP y uno o más subagentes. El agente SNMP se comunica con la estación de gestión de red o responde a las peticiones SNMP de línea de mandatos. El subagente SNMP recupera y actualiza datos y proporciona esos datos al agente SNMP para comunicarse de nuevo con el solicitante.
Dispatcher proporciona una Management Information Base (ibmNetDispatcherMIB) SNMP y un subagente SNMP. Esto permite utilizar cualquier sistema de gestión de red (como Tivoli(R) NetView(R), Tivoli Distributed Monitoring o HP OpenView), para supervisar el estado, el rendimiento y la actividad de Dispatcher. Los datos MIB describen el Dispatcher que se va a gestionar y reflejan el estado actual de Dispatcher. MIB se instala en el subdirectorio ..lb/admin/MIB.
El sistema de gestión de red utiliza mandatos GET SNMP para detectar valores de MIB en otras máquinas. Luego el sistema puede notificarle si se han superado los valores de umbral especificados. Usted puede entonces influir en el rendimiento de Dispatcher si modifica los datos de configuración de este componente para ajustar de forma activa o corregir problemas de Dispatcher antes de que se conviertan en caídas de Dispatcher o del servidor Web.
El sistema suele proporcionar un agente SNMP para cada estación de gestión de red. El usuario envía un mandato GET al agente SNMP. A cambio, este agente SNMP envía un mandato GET para recuperar los valores de la variable MIB especificada de un subagente encargado de esas variables MIB.
Dispatcher proporciona un subagente que actualiza y recupera datos MIB. El subagente responde con los datos MIB adecuados cuando el agente SNMP envía un mandato GET. El agente SNMP comunica los datos a la estación de gestión de red. La estación de gestión de red puede notificarle si se han superado los valores de umbral especificados.
El soporte SNMP de Dispatcher incluye un subagente SNMP que utiliza la posibilidad DPI(R) (Distributed Program Interface). DPI es una interfaz entre un agente SNMP y sus subagentes. El sistema operativo Windows utiliza el agente de ampliación de Windows como una interfaz entre el agente SNMP y sus subagentes.
Figura 40. Mandatos SNMP para sistemas Linux y UNIX
Los sistemas AIX proporcionan un agente SNMP que utiliza el protocolo SMUX (SNMP Multiplexer) y proporciona DPID2, que es un ejecutable adicional que funciona como un conversor entre DPI y SMUX.
En sistemas HP-UX, debe obtener un agente SNMP que sea compatible con SMUX puesto que HP-UX no proporciona ninguno. Load Balancer proporciona DPID2 para sistemas HP-UX.
Los sistemas Linux proporcionan un agente SNMP que utiliza SMUX. La mayoría de las versiones Linux (por ejemplo, Red Hat) vienen con un paquete UCD SNMP. UCD SNMP versión 4.1 o posteriores tienen agentes compatibles con SMUX. Load Balancer proporciona DPID2 para sistemas Linux.
En sistemas Solaris, debe obtener un agente SNMP que sea compatible con SMUX puesto que Solaris no proporciona ninguno. Load Balancer proporciona DPID2 para sistemas Solaris en el directorio /opt/ibm/edge/lb/servers/samples/SNMP.
El agente DPI debe ejecutarse como un usuario root. Antes de ejecutar el daemon de DPID2, actualice el archivo /etc/snmpd.peers y /etc/snmpd.conf como se detalla a continuación:
En sistemas AIX y Solaris:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smux 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password #dpid
En sistemas Linux:
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer .1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Además, debe poner como comentario todas las líneas del archivo snmpd.conf que comienzan por estas palabras: com2sec, group, view o access.
Para instalar el soporte de SNMP de HP-UX:
Para utilizar SNMP de Load Balancer con sistemas SuSE Linux, debe realizar lo siguiente:
Renueve snmpd (si aún está en ejecución) para que vuelva a leer el archivo snmpd.conf:
refresh -s snmpd
Inicie el DPID SMUX del igual:
dpid2
Los daemons deben iniciarse en el orden siguiente:
Para instalar el soporte de SNMP de Solaris:
/etc/rc3.d/S76snmpdx por /etc/rc3.d/K76snmpdx
/etc/rc3.d/S77dmi por /etc/rc3.d/K77dmi
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH: /usr/local/lib:/usr/local/ssl/lib:/usr/lib
export PATH=/usr/local/sbin:/usr/local/bin:$PATH
export SNMPCONFPATH =/etc/snmp
export MIBDIRS=/usr/local/share/snmp/mibs
cp /opt/ibm/edge/lb/servers/samples/SNMP/dpid2 /usr/local/sbin/dpid2
"dpid2" 1.3.6.1.4.1.2.3.1.2.2.1.1.2 "dpid_password"
smuxpeer 1.3.6.1.4.1.2.3.1.2.2.1.1.2 dpid_password
Notas:
En el sitio Web http://sunfreeware.com/, los nombres tienen una extensión de .gz, por lo tanto no utilice gunzip/untar con éstos. En su lugar, utilice pkgadd nombrePaquete.
Para instalar el soporte de SNMP de Windows:
Con el ejecutor en ejecución, utilice el mandato dscontrol subagent start [nombrecomunidad] para definir el nombre de comunidad utilizado entre el agente de extensión del SO Windows y el agente SNMP.
IMPORTANTE: en Windows 2003, de manera predeterminada SNMP no responde a ningún nombre de comunidad presentado. En tal caso, el subagente SNMP no responderá a ninguna petición SNMP. Para asegurarse de que el subagente SNMP responderá al nombre de comunidad, debe establecer las propiedades del servicio SNMP con el nombre de comunidad adecuado y el sistema o los hosts de destino. Configure las propiedades de seguridad SNMP como se detalla a continuación:
SNMP se comunica enviando y recibiendo condiciones de excepción, mensajes enviados por dispositivos gestionados para informar de condiciones de excepción o de la aparición de sucesos significativos, como un umbral alcanzado.
El subagente utiliza estas condiciones de excepción:
La condición de excepción indHighAvailStatus anuncia que el valor de la variable de estado de alta disponibilidad (hasState) ha cambiado. Los valores posibles de hasState son:
La condición de excepción indSrvrGoneDown anuncia que el peso del servidor especificado por la parte csID (ID de clúster), psNum (número de puerto) y ssID (ID de servidor) del identificador de objeto ha alcanzado cero. El último número conocido de conexiones activas del servidor se envía en la condición de excepción. Esta condición de excepción indica que, en lo que puede determinar Dispatcher, se ha quedado inactivo el servidor especificado.
La condición de excepción indDOSAttack indica que numhalfopen, el número de conexiones medio abiertas que constan sólo de paquetes SYN, ha superado el umbral maxhhalfopen del puerto especificado por la parte csID (ID de clúster) y psNum (número de puerto) del identificador de objeto. El número de servidores configurados en el puerto se envía en la condición de excepción. Esta condición de excepción indica que Load Balancer puede estar experimentando un ataque para rechazo de servicio.
La condición de excepción indDOSAttackDone indica que numhalfopen, el número de conexiones medio abiertas que constan sólo de paquetes SYN, ha caído por debajo del umbral maxhalfopen del puerto especificado por la parte csID y psNum del identificador de objeto. El número de servidores configurados en el puerto se envía en la condición de excepción. Cuando Load Balancer determina que ha finalizado el posible ataque para rechazo de servicio, se enviará esta condición de excepción después de que se envíe una condición de excepción indDOSAttack.
Para sistemas Linux y UNIX, debido a una limitación en la API de SMUX, el identificador de empresa del que se informa en condiciones de excepción del subagente ibmNetDispatcher podría ser el identificador de empresa de dpid2, en lugar del identificador de empresa de ibmNetDispatcher, 1.3.6.1.4.1.2.6.144. No obstante, los programas de utilidad de gestión de SNMP podrán determinar el origen de la condición de excepción porque los datos contendrán un identificador de objeto desde dentro del MIB de ibmNetDispatcher.
El mandato dscontrol subagent start activa el soporte de SNMP. El mandato dscontrol subagent stop desactiva el soporte de SNMP.
Si desea más información sobre el mandato dscontrol, consulte el apartado dscontrol subagent -- configurar subagente SNMP.
En el kernel Linux hay incorporado un recurso de cortafuegos llamado ipchains. Cuando Load Balancer e ipchains se ejecutan a la vez, los paquetes los detecta primero Load Balancer y luego los detecta ipchains. Esto permite el uso de ipchains para proteger una máquina de Load Balancer Linux, que podría ser, por ejemplo, una máquina de Load Balancer que se utiliza para equilibrar la carga de los cortafuegos.
Cuando se configuran ipchains o tablas ip restringidas completamente (no se permite el tráfico de entrada ni de salida), la parte de reenvío de paquetes de Load Balancer sigue funcionando normalmente.
Recuerde que no pueden utilizarse ipchains y tablas ip para filtrar el tráfico de entrada antes de que se equilibre de carga.
Debe permitirse algún tráfico adicional para que todo el Load Balancer funcione correctamente. Algunos ejemplos de esta comunicación son:
En general, una estrategia de ipchains adecuada para las máquinas Load Balancer es no permitir todo el tráfico, excepto que sea hacia o desde los servidores finales, el Load Balancer de alta disponibilidad de asociados, cualquier destino de alcance o cualquier host de configuración.
No se recomienda activar tablas ip cuando se ejecuta Load Balancer en el kernel Linux versión 2.4.10.x. La activación en esta versión del kernel Linux puede provocar con el tiempo una disminución del rendimiento.
Para desactivar las tablas ip, enumere los módulos (lsmod) con el fin de comprobar qué módulo utilizan ip_tables e ip_conntrack, luego elimínelas emitiendo rmmod ip_tables y rmmod ip_conntrack. Cuando reinicie la máquina estos módulos se añadirán de nuevo, de modo que tendrá que repetir este paso cada vez que reinicie la máquina.
Para obtener más información, consulte el apartado Problema: en sistemas Linux, iptables puede impedir el direccionamiento de paquetes.
En este apartado se describe cómo operar y gestionar el componente CBR de Load Balancer.
CBR y Caching Proxy colaboran utilizando la API del plug-in de Caching Proxy para gestionar peticiones HTTP y HTTPS (SSL). Caching Proxy debe ejecutarse en la misma máquina para que CBR comience a equilibrar la carga de los servidores. Configure CBR y Caching Proxy como se describe en el apartado Ejemplo de configuración CBR.
Después de iniciar CBR, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por CBR son similares a los que se utilizan en Dispatcher. Para obtener más información, consulte el apartado Utilización de los registros de Load Balancer.
Después de iniciar Site Selector, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por Site Selector son similares a los que se utilizan en Dispatcher. Para obtener una descripción más extensa, consulte el apartado Utilización de los registros de Load Balancer.
Después de iniciar Cisco CSS Controller, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por Cisco CSS Controller son similares a los que se utilizan en Dispatcher. Para obtener una descripción más extensa, consulte el apartado Utilización de los registros de Load Balancer.
Después de iniciar Nortel Alteon Controller, puede controlarlo utilizando uno de estos métodos:
Los archivos de anotaciones cronológicas utilizados por Nortel Alteon Controller son similares a los que se utilizan en Dispatcher. Para obtener una descripción más extensa, consulte el apartado Utilización de los registros de Load Balancer.
Metric Server proporciona información de carga del servidor a Load Balancer. Metric Server reside en cada uno de los servidores de los que se está equilibrando la carga.
Sistemas Linux y UNIX:
Sistemas Windows:
Pulse Inicio > Configuración (en Windows 2000) > Panel de control > Herramientas administrativas > Servicios. Pulse con el botón derecho del ratón en IBM Metric Server y seleccione Iniciar. Para detener el servicio, efectúe los mismos pasos y seleccione Detener.
Cambie el nivel de anotaciones en el script de inicio de Metric Server. Puede especificar un intervalo de nivel de anotaciones de 0 a 5, similar al intervalo de nivel de anotaciones de los archivos de anotaciones cronológicas de Load Balancer. Esto generará un archivo de anotaciones cronológicas agente en el directorio ...ms/logs.
Este capítulo ayuda a detectar y solucionar problemas asociados a Load Balancer.
Utilice la información de este apartado para recopilar los datos que requiere el servicio de IBM. La información se divide en los temas siguientes.
Sólo para el componente Dispatcher, hay una herramienta de determinación de problemas que recopila automáticamente datos específicos del sistema operativo y archivos de configuración específicos del componente. Para ejecutar esta herramienta, escriba lbpd en el directorio adecuado:
En sistemas Linux y UNIX: /opt/ibm/edge/lb/servers/bin/
En sistemas Windows: C:Archivos de programa\IBM\edge\lb\servers\bin
La herramienta de determinación de problemas empaqueta los datos en archivos como se detalla a continuación:
En sistemas Linux y UNIX: /opt/ibm/edge/lb/lbpmr.tar.Z
En sistemas Windows: C:\Archivos de programa\IBM\edge\lb\lbpmr.zip
Antes de llamar al servicio de IBM, tenga a mano la información siguiente.
dscontrol file save primary.cfg
Este mandato sitúa el archivo de configuración en el directorio .../ibm/edge/lb/servers/configuration/componente/.
java -fullversion
En sistemas AIX, HP-UX, Linux y Solaris: netstat -ni
En sistemas Windows: ipconfig /all
Esto se requiere de todos los servidores y de Load Balancer.
En sistemas AIX, HP-UX, Linux y Solaris: netstat -nr
En sistemas Windows: route print
Esto se requiere de todos los servidores y de Load Balancer.
Recopile la siguiente información necesaria de problemas en entornos de HA.
En sistemas AIX, HP-UX, Linux y Solaris: /opt/ibm/edge/lb/servers/bin
En sistemas Windows: C:\Archivos de programa\ibm\edge\lb\servers\bin
Los nombres de script son:
goActive
goStandby
goIdle (si está presente)
goInOp (si está presente)
Incluya también los archivos de configuración. Consulte el apartado Información general (siempre es necesaria).
Recopile esta información necesaria para problemas del asesor; por ejemplo, cuando los asesores por error marcan los servidores como inactivos.
dscontrol advisor loglevel http 80 5
o
dscontrol advisor loglevel nombreAsesor puerto nivelAnotaciones
o
dscontrol advisor loglevel nombreAsesor clúster:puerto nivelAnotaciones
o
nalcontrol metriccollector set ID_consultor:ID_servicio:nombreMétrica loglevel valor
Se creará un archivo de anotaciones cronológicas llamado ADV_nombresAsesor.log; por ejemplo ADV_http.log. Este archivo de anotaciones cronológicas se ubica como se detalla a continuación:
En plataformas AIX, HP-UX, Linux y Solaris: /opt/ibm/edge/lb/servers/logs/component
En plataformas Windows: C:\Archivos de programa\ibm\edge\lb\servers\logs\component
Donde componente es:
dispatcher = Dispatcher
cbr = CBR (Content Based Routing)
cco = Cisco CSS Controller
na = Nortel Alteon Controller
ss = Site Selector
La llamada a ADVLOG imprime sentencias al archivo de anotaciones cronológicas de asesores cuando el nivel es inferior que el nivel de anotaciones asociado a los asesores. Un nivel de anotaciones de 0 provocará que siempre se grabe la sentencia. No puede utilizar ADVLOG desde el constructor. El archivo de anotaciones cronológicas no se crea hasta inmediatamente después de que el constructor haya terminado porque el nombre de archivo de anotaciones cronológicas depende de la información que está establecida en el constructor.
Hay otro modo de depurar el asesor personalizado que evitará esta limitación. Puede utilizar sentencias System.out.println(mensaje) para imprimir mensajes a una ventana. Edite el script dsserver y cambie javaw por java para que las sentencias de impresión aparezcan en la ventana. La ventana utilizada para iniciar dsserver debe mantenerse abierta para que aparezcan las impresiones. Si utiliza plataformas Windows, debe dejar de ejecutar el Dispatcher como un servicio e iniciarlo manualmente desde una ventana para visualizar los mensajes.
Consulte el manual Guía de programación de Edge Components para obtener más información sobre ADVLOG.
Recopile la siguiente información necesaria de problemas de CBR (Content Based Routing).
En sistemas Linux y UNIX: /etc/
En sistemas Windows: C:\Archivos de programa\IBM\edge\cp\etc\en_US\
En sistemas Linux y UNIX: /opt/ibm/edge/lb/servers/configurations/cbr
En sistemas Windows: C:\Archivos de programa\IBM\edge\lb\servers\configurations\cbr
Si no se puede acceder al clúster, quizá ninguna de las máquinas de Load Balancer haya creado un alias del clúster. Para determinar qué máquina posee el clúster:
ping clúster arp -aSi utiliza los métodos de reenvío nat o cbr de Dispatcher, ejecute el mandato ping de la dirección de retorno también.
En sistemas AIX y HP-UX: netstat -ni
En sistemas Linux y Solaris: ifconfig -a
En sistemas Windows: ipconfig /all
Si no obtiene una respuesta del mandato ping y no utiliza ULB, puede que ninguna máquina haya creado el alias de la dirección IP del clúster para su interfaz; por ejemplo, en0, tr0, etc.
Si no puede solucionar problemas de direccionamiento y todo lo demás no funciona, emita el mandato siguiente para ejecutar un rastreo en el tráfico de red:
iptrace -a -s direcciónIPclienteConError -d direcciónIPclúster -b iptrace.trc
Ejecute el rastreo, vuelva a crear el problema y elimine con el mandato kill el proceso.
tcpdump -i lan0 host clúster y host cliente
Quizá tenga que bajarse tcpdump de uno de los sitios de archivadores del software HP-UX GNU.
tcpdump -i eth0 host clúster y host cliente
Ejecute el rastreo, vuelva a crear el problema y elimine con el mandato kill el proceso.
snoop -v dirección_IP_cliente dirección_IP_destino > snooptrace.out
También puede aumentar distintos niveles de anotaciones (por ejemplo, el archivo de anotaciones cronológicas del gestor o del asesor, etc.) e investigar su salida.
Para identificar un problema que ya se ha corregido en un fix pack de release de servicio o en un parche, compruebe las actualizaciones. Para obtener una lista de defectos de Edge Components corregidos, consulte la página de soporte del sitio Web de WebSphere Application Server: http://www.ibm.com/software/webservers/appserv/was/support/. Desde la página de soporte, siga el enlace al sitio de descarga del servicio de corrección.
Se instalará la versión correcta de Java como parte de la instalación de Load Balancer.
Consulte el apartado Información de consulta para obtener enlaces a las páginas Web de soporte y de biblioteca. La página Web de soporte contiene un enlace a la información de autoayuda a modo de Notas técnicas.
Consulte lo siguiente para obtener:
Tabla 17. Tabla de resolución de problemas de Dispatcher
Síntoma | Causa posible | Vaya a... |
---|---|---|
Dispatcher no se ejecuta correctamente | Números de puerto en conflicto | Comprobación de los números de puerto de Dispatcher |
Se ha configurado un servidor con ubicación compartida y no responderá a peticiones de equilibrio de carga | Dirección incorrecta o en conflicto con otra | Problema: no responderán Dispatcher y el servidor |
Conexiones de máquinas cliente no atendidas o que han superado el tiempo de espera |
| Problema: no se equilibran las peticiones de Dispatcher |
Máquinas cliente no atendidas o que han superado el tiempo de espera | No funciona la alta disponibilidad | Problema: la función de alta disponibilidad de Dispatcher no funciona |
No se han podido añadir pulsos (plataformas Windows) | La dirección de origen no se ha configurado en un adaptador | Problema: no se han podido añadir pulsos (plataforma Windows) |
El servidor no atiende las peticiones (plataforma Windows) | Se ha creado una ruta adicional en la tabla de direccionamiento | Problema: rutas adicionales (Windows 2000) |
Los asesores no funcionan correctamente con el área amplia | Los asesores no se ejecutan en máquinas remotas | Problema: los asesores no funcionan correctamente |
Dispatcher, Microsoft IIS y SSL no funcionan o no continuarán | No se han podido enviar datos cifrados entre protocolos | Problema: Dispatcher, Microsoft IIS y SSL no funcionan (plataforma Windows) |
Conexión con la máquina remota rechazada | Todavía se utiliza la versión anterior de las claves | Problema: conexión de Dispatcher con una máquina remota |
El mandato dscontrol o lbadmin ha dado un error e indica el mensaje "El servidor no responde" o "No es posible acceder al servidor RMI" |
| Problema: el mandato dscontrol o lbadmin da un error |
Se produce el mensaje de error "No se puede encontrar el archivo..." cuando se ejecuta Netscape como el navegador predeterminado para consultar la ayuda en línea (plataforma Windows) | Valor incorrecto para la asociación de archivo HTML | Problema: aparece el mensaje de error "No se puede encontrar el archivo..." al intentar consultar la ayuda en línea (plataforma Windows) |
La interfaz gráfica de usuario no se inicia correctamente | Espacio de paginación insuficiente | Problema: la GUI (interfaz gráfica de usuario) no se inicia correctamente |
Error al ejecutar Dispatcher con Caching Proxy instalado | Dependencia de archivos de Caching Proxy | Problema: error al ejecutar Dispatcher con Caching Proxy instalado |
La interfaz gráfica de usuario no se muestra correctamente. | La resolución es incorrecta. | Problema: la GUI (interfaz gráfica de usuario) no se muestra correctamente |
Los paneles de ayuda a veces desaparecen detrás de otras ventanas | Limitación de Java | Problema: en la plataforma Windows, las ventanas de ayuda a veces desaparecen detrás de otras ventanas abiertas |
Load Balancer no puede procesar y reenviar una trama | Se necesita una dirección MAC única para cada NIC | Problema: Load Balancer no puede procesar y reenviar una trama |
Aparece una pantalla azul | Tarjeta de red no instalada ni configurada | Problema: se muestra una pantalla azul cuando se inicia el ejecutor de Load Balancer |
La vía de acceso al descubrimiento impide el tráfico de retorno | Se ha creado un alias del clúster en el bucle de retorno | Problema: la vía de acceso al descubrimiento impide el tráfico de retorno con Load Balancer |
No funciona la alta disponibilidad de la modalidad de área amplia de Load Balancer. | El Dispatcher remoto debe definirse como un servidor de un clúster en el Dispatcher local | Problema: no funciona la alta disponibilidad en la modalidad de área amplia de Load Balancer |
Se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño. | Java no tiene acceso a suficiente memoria para gestionar un cambio de tan gran tamaño en la GUI | Problema: se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño |
Las direcciones IP no se resuelven correctamente en la conexión remota | Cuando se utiliza un cliente remoto en una implementación de SOCKS segura, los nombres de dominio o de host plenamente cualificados quizá no se resuelvan con la dirección IP correcta | Problema: las direcciones IP no se resuelven correctamente en la conexión remota |
La interfaz de Load Balancer coreana muestra fonts solapados o no deseados en sistemas AIX y Linux | Se deben cambiar los fonts predeterminados | Problema: la interfaz de Load Balancer coreana muestra fonts solapados o no deseados en sistemas AIX y Linux |
En sistemas Windows, después de crear un alias del adaptador MS Loopback, cuando emita determinados mandatos como hostname, el sistema operativo responderá incorrectamente con la dirección del alias | En la lista de conexiones de red, no se enumera el alias recién añadido antes de la dirección local | Problema: en sistemas Windows, se devuelve una dirección del alias en lugar de la dirección local cuando se emiten mandatos como hostname |
Comportamiento de la GUI inesperado cuando se utiliza la plataforma Windows con la tarjeta de vídeo Matrox AGP | Se produce un problema cuando se utilizan tarjetas de vídeo Matrox AGP al ejecutar la GUI de Load Balancer | Problema: en la plataforma Windows, se produce un comportamiento de la GUI inesperado al utilizar tarjetas de vídeo Matrox AGP |
Se produce un comportamiento inesperado, por ejemplo, se cierra la comunicación del sistema, cuando se ejecuta "rmmod ibmlb" en sistemas Linux | Se produce un problema cuando se elimina manualmente el módulo kernel de Load Balancer (ibmlb). | Problema: comportamiento inesperado al ejecutar rmmod ibmlb (sistemas Linux) |
Tiempo de respuesta lento cuando se ejecutan mandatos en la máquina de Dispatcher | El tiempo de respuesta lento puede deberse a una sobrecarga de la máquina por un alto volumen de tráfico del cliente | Problema: tiempo de respuesta lento cuando se ejecutan mandatos en la máquina de Dispatcher |
Para el método de reenvío mac de Dispatcher, el asesor SSL o HTTPS no registra las cargas del servidor | Se produce el problema porque la aplicación servidor SSL no se ha configurado con la dirección IP del clúster | Problema: el asesor SSL o HTTPS no registra cargas del servidor (cuando se utiliza el reenvío mac) |
Se produce una desconexión del host cuando se utiliza la administración Web remota mediante Netscape | Se producirá una desconexión del host cuando se cambie el tamaño de la ventana del navegador | Problema: se produce una desconexión del host si se cambia el tamaño de la ventana del navegador Netscape cuando se utiliza la administración Web |
Está habilitada la agrupación de sockets y el servidor Web se enlaza a 0.0.0.0 | Configure el servidor IIS de Microsoft para que sea específico del enlace | Problema: está habilitada la agrupación de sockets y el servidor Web se enlaza a 0.0.0.0 |
En la plataforma Windows, aparecen en el indicador de mandatos caracteres nacionales Latin-1 dañados | Cambie las propiedades de font de la ventana de indicador de mandatos | Problema: en sistemas Windows, aparecen caracteres nacionales Latin-1 dañados en la ventana de indicador de mandatos |
En la plataforma HP-UX, aparece este mensaje: java.lang.OutOfMemoryError unable to create new native thread (java.lang.OutOfMemoryError no se ha podido crear una nueva hebra nativa) | Algunas instalaciones de HP-UX predeterminadas permiten 64 hebras por proceso. Esto es insuficiente. | Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java |
En la plataforma Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores | No está inhabilitada Task Offload (Descarga de tareas) o quizá tenga que habilitarse ICMP. | Problema: en los sistemas Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores |
En la plataforma Windows, se produce un problema al resolver la dirección IP con nombre de host cuando se configura más de una dirección con un adaptador | La dirección IP que desea como nombre de host debe aparecer primero en el registro. | Problema: en la plataforma Windows, se resuelve la dirección IP con el nombre de host cuando se ha configurado más de una dirección con el adaptador |
En la plataforma Windows, los asesores no funcionan en una configuración de alta disponibilidad después de una caída de la red | Cuando el sistema detecta una caída de la red, borra la memoria caché ARP (Address Resolution Protocol) | Problema: en sistemas Windows, después de una caída de la red, los asesores no funcionan en una configuración de alta disponibilidad |
En sistemas Linux, el mandato "IP address add" y varios alias de bucle de retorno del clúster son incompatibles | Cuando cree alias para más de una dirección en el dispositivo de bucle de retorno, debería utilizar el mandato ifconfig, no ip address add | Problema: en sistemas Linux, no utilice el mandato IP address add cuando cree un alias de varios clústeres en el dispositivo de bucle de retorno |
Aparece el mensaje de error: "dirección del direccionador no especificada o no válida para el método del puerto" al intentar añadir un servidor | Repase la lista de comprobación de información para determinar el problema que se ha producido al añadir un servidor | Problema: mensaje de error Dirección del direccionador no especificada o no válida para el método del puerto |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. | Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado |
Se produce una ralentización cuando se cargan configuraciones de Load Balancer | El retardo puede deberse a llamadas al Sistema de nombres de dominio (DNS) que se realizan para resolver y verificar la dirección de servidor. | Problema: Se ha producido un retardo al cargar una configuración de Load Balancer |
En sistemas Windows, aparece este mensaje de error: Hay un conflicto de dirección IP con otro sistema en la red | Si se configura la alta disponibilidad, podrían configurarse direcciones del clúster en las dos máquinas por un breve período lo que produce que aparezca este mensaje de error. | Problema: en sistemas Windows, aparece un mensaje de error de conflicto de dirección IP |
Las dos máquinas, primaria y de reserva, están activas en una configuración de alta disponibilidad | Este problema podría producirse cuando no se ejecutan los scripts go en alguna de las máquinas primaria o de reserva. | Problema: las dos máquinas, primaria y de reserva, están activas en una configuración de alta disponibilidad |
No se pueden realizar las peticiones del cliente cuando Dispatcher intenta devolver respuestas de páginas de gran tamaño | Las peticiones del cliente que producen unas respuestas de páginas de gran tamaño superan el tiempo de espera si la unidad de transmisión máxima (MTU) no se establece correctamente en la máquina de Dispatcher cuando se utiliza el reenvío nat o cbr. | Problema: no se pueden realizar las peticiones del cliente cuando el sistema intenta devolver respuestas de páginas de gran tamaño |
En sistemas Windows, se produce el error "el servidor no responde" cuando se emite un mandato dscontrol o lbadmin | Cuando existe más de una dirección IP en un sistema Windows y el archivo de host no especifica la dirección que se va a asociar al nombre de host. | Problema: en sistemas Windows, se produce el error El servidor no responde cuando se emite dscontrol o lbadmin |
Es posible que las máquinas de Dispatcher de alta disponibilidad no se puedan sincronizar en Linux para S/390 en dispositivos qeth | Cuando utiliza la característica de alta disponibilidad en Linux para S/390 con el controlador de red qeth, puede que los Dispatcher activo y en espera no se sincronicen. | Problema: es posible que las máquinas de Dispatcher de alta disponibilidad no se puedan sincronizar en sistemas Linux para S/390 en controladores qeth |
Sugerencias para configurar la característica de alta configuración para Load Balancer | Las sugerencias pueden ayudarle a reducir los problemas de alta disponibilidad como por ejemplo:
| Problema: sugerencias para configurar la alta disponibilidad |
Limitaciones de configuración de reenvío MAC de Dispatcher con las plataformas zSeries y S/390 | En Linux, existen limitaciones cuando se utilizan servidores zSeries o S/390 que disponen de tarjetas OSA (Open System Adapter). Se proporcionan soluciones alternativas posibles. | Problema: en Linux, limitaciones cuando se utilizan servidores zSeries o S/390 que disponen de tarjetas OSA (Open System Adapter) |
En algunas versiones de Red Hat Linux, se produce una pérdida de memoria al ejecutar Load Balancer configurado con el gestor y los asesores | Las versiones de la MVM de SDK Java de IBM y la biblioteca de hebras POSIX nativa (NPTL) que se entregan con algunas distribuciones Linux, como Red Hat Enterprise Linux 3.0, pueden hacer que se produzca la pérdida de memoria. | Problema: en algunas versiones de Linux, se produce una pérdida de memoria al ejecutar Dispatcher configurado con el gestor y los asesores |
En SUSE Linux Enterprise Server 9, el informe de Dispatcher indica que se envían paquetes (aumenta el número de paquetes), aunque en realidad los paquetes nunca llegan al servidor de programa de fondo | Se carga el módulo NAT de iptables. En esta versión de iptables hay un posible error, aunque sin confirmar, que provoca un comportamiento extraño al interactuar con Dispatcher. | Problema: en SUSE Linux Enterprise Server 9, Dispatcher reenvía paquetes, pero los paquetes no llegan al servidor de programa de fondo |
En sistemas Windows, al utilizar la característica de alta disponibilidad de Dispatcher, pueden aparecer problemas durante la toma de control | Si se ejecuta el script go* que configura la dirección IP de clúster de la máquina activa antes de ejecutar el script go* para desconfigurar la dirección IP de clúster de la máquina en espera, pueden surgir problemas. | Problema: en sistemas Windows, se muestra un mensaje de conflicto de dirección IP durante la toma de control de alta disponibilidad |
En sistemas Linux, iptables puede impedir el direccionamiento de paquetes | iptables en Linux pueden dificultar el equilibrio de carga y debe estar inhabilitado en la máquina de Load Balancer. | Problema: en sistemas Linux, iptables puede impedir el direccionamiento de paquetes |
Cuando se instalan arreglos de servicio o se instala de forma nativa mediante las herramientas de paquetes del sistema, aparece un mensaje de aviso del conjunto de archivos Java. | La instalación de producto consta de varios paquetes que no es necesario instalar en la misma máquina y, por lo tanto, cada uno de estos paquetes instala un conjunto de archivos Java. Cuando se instalan en la misma máquina, aparece un mensaje de aviso indicando que el conjunto de archivos Java también es propiedad de otro conjunto de archivos. | Aparece un mensaje de aviso Java al instalar arreglos de servicio |
Actualización del conjunto de archivos Java que se proporciona con las instalaciones de Load Balancer | Si se detecta un problema con el conjunto de archivos Java, debe notificarlo al servicio de IBM para así poder recibir una actualización para el conjunto de archivos Java que se proporcionó con la instalación de Load Balancer. | Actualización del conjunto de archivos Java con la instalación de Load Balancer |
Pueden cerrarse conexiones permanentes durante la toma de control de alta disponibilidad en una plataforma Windows | En sistemas operativos Microsoft Windows, es posible que las conexiones permanentes se caigan durante una operación de toma de control de alta disponibilidad. Este problema se produce sólo cuando dispone de un servidor compartido que utiliza el método de reenvío MAC. | Problema: pueden cerrarse conexiones permanentes durante la toma de control de alta disponibilidad |
El programa de instalación no se ejecutará en un sistema operativo Linux de 32 bits para zSeries |
Al instalar WebSphere Edge Server utilizando ./install en el sistema operativo Linux de 32 bits para zSeries se produce un mensaje "JVM no encontrada".
| Problema: al instalar WebSphere Edge Server utilizando ./install en el sistema operativo Linux de 32 bits para zSeries se produce un mensaje JVM no encontrada |
El proceso de desinstalación no se completa correctamente en sistemas operativos Linux |
El proceso de desinstalación para WebSphere Edge Server se cierra en sistemas operativos Linux.
| Problema: el proceso de desinstalación para WebSphere Edge Server se cierra en sistemas operativos Linux |
Tabla 18. Tabla de resolución de problemas de CBR
Síntoma | Causa posible | Vaya a.... |
CBR no se ejecuta correctamente | Números de puerto en conflicto | Comprobación de los números de puerto de CBR |
El mandato cbrcontrol o lbadmin ha dado un error e indica el mensaje "El servidor no responde" o "No es posible acceder al servidor RMI" | Los mandatos dan un error debido a una pila con SOCKS. O porque no se inicia cbrserver | Problema: el mandato cbrcontrol o lbadmin da un error |
No se equilibra la carga de las peticiones | Se ha iniciado Caching Proxy antes de que se iniciara el ejecutor | Problema: no se equilibra la carga de las peticiones |
En Solaris, el mandato cbrcontrol executor start produce el mensaje de error 'Error: el ejecutor no se ha iniciado'. | El mandato da un error porque quizá sea necesario modificar los valores predeterminados de IPC del sistema o el enlace a la biblioteca es incorrecto. | Problema: en sistemas Solaris, el mandato cbrcontrol executor start da un error |
No funciona la regla de URL | Error sintáctico o de configuración | Problema: error sintáctico o de configuración |
Comportamiento de la GUI inesperado cuando se utilizan los sistemas Windows con la tarjeta de vídeo Matrox AGP | Se produce un problema cuando se utilizan tarjetas de vídeo Matrox AGP al ejecutar la GUI de Load Balancer | Problema: en la plataforma Windows, se produce un comportamiento de la GUI inesperado al utilizar tarjetas de vídeo Matrox AGP |
Se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño. | Java no tiene acceso a suficiente memoria para gestionar un cambio de tan gran tamaño en la GUI | Problema: se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño |
Se produce una desconexión del host cuando se utiliza la administración Web remota mediante Netscape | Se producirá una desconexión del host cuando se cambie el tamaño de la ventana del navegador | Problema: se produce una desconexión del host si se cambia el tamaño de la ventana del navegador Netscape cuando se utiliza la administración Web |
En la plataforma Windows, aparecen en el indicador de mandatos caracteres nacionales Latin-1 dañados | Cambie las propiedades de font de la ventana de indicador de mandatos | Problema: en plataformas Windows, aparecen caracteres nacionales Latin-1 dañados en la ventana de indicador de mandatos |
En la plataforma HP-UX, aparece este mensaje: java.lang.OutOfMemoryError unable to create new native thread (java.lang.OutOfMemoryError no se ha podido crear una nueva hebra nativa) | Algunas instalaciones de HP-UX predeterminadas permiten 64 hebras por proceso. Esto es insuficiente. | Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java |
En la plataforma Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores | No está inhabilitada Task Offload (Descarga de tareas) o quizá tenga que habilitarse icmp. | Problema: en los sistemas Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores |
En la plataforma Windows, se produce un problema al resolver la dirección IP con nombre de host cuando se configura más de una dirección con un adaptador | La dirección IP que desea como nombre de host debe aparecer primero en el registro. | Problema: en sistemas Windows, se resuelve la dirección IP con el nombre de host cuando se ha configurado más de una dirección con el adaptador |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. | Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado |
Tabla 19. Tabla de resolución de problemas de Site Selector
Síntoma | Causa posible | Vaya a... |
---|---|---|
Site Selector no se ejecuta correctamente | Número de puerto en conflicto | Comprobación de los números de puerto de Site Selector |
Site Selector no utiliza el algoritmo de turno rotativo para peticiones entrantes del cliente Solaris | Los sistemas Solaris ejecutan un "daemon de caché del servicio de nombres" | Problema: Site Selector no utiliza el algoritmo de turno rotativo en el tráfico de clientes Solaris |
El mandato sscontrol o lbadmin ha dado un error e indica el mensaje "El servidor no responde" o "No es posible acceder al servidor RMI" | Los mandatos dan un error debido a una pila con SOCKS. O porque no se inicia ssserver | Problema: el mandato sscontrol o lbadmin da un error |
No se ha podido iniciar ssserver en la plataforma Windows | Los sistemas Windows no requieren que el nombre de host esté en el DNS. | Problema: no se ha podido iniciar ssserver en la plataforma Windows |
La máquina con rutas duplicadas no equilibra la carga correctamente -- parece que la resolución de nombres da un error | Máquina de Site Selector con varios adaptadores conectados a la misma subred | Problema: Site Selector con rutas duplicadas no equilibra la carga correctamente |
Comportamiento de la GUI inesperado cuando se utiliza la plataforma Windows con la tarjeta de vídeo Matrox AGP | Se produce un problema cuando se utilizan tarjetas de vídeo Matrox AGP al ejecutar la GUI de Load Balancer | Problema: en la plataforma Windows, se produce un comportamiento de la GUI inesperado al utilizar tarjetas de vídeo Matrox AGP |
Se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño. | Java no tiene acceso a suficiente memoria para gestionar un cambio de tan gran tamaño en la GUI | Problema: se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño |
Se produce una desconexión del host cuando se utiliza la administración Web remota mediante Netscape | Se producirá una desconexión del host cuando se cambie el tamaño de la ventana del navegador | Problema: se produce una desconexión del host si se cambia el tamaño de la ventana del navegador Netscape cuando se utiliza la administración Web |
En la plataforma Windows, aparecen en el indicador de mandatos caracteres nacionales Latin-1 dañados | Cambie las propiedades de font de la ventana de indicador de mandatos | Problema: en plataformas Windows, aparecen caracteres nacionales Latin-1 dañados en la ventana de indicador de mandatos |
En la plataforma HP-UX, aparece este mensaje: java.lang.OutOfMemoryError unable to create new native thread (java.lang.OutOfMemoryError no se ha podido crear una nueva hebra nativa) | Algunas instalaciones de HP-UX predeterminadas permiten 64 hebras por proceso. Esto es insuficiente. | Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java |
En la plataforma Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores | No está inhabilitada Task Offload (Descarga de tareas) o quizá tenga que habilitarse icmp. | Problema: en los sistemas Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. | Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado |
Tabla 20. Tabla de resolución de problemas del controlador para conmutadores Cisco CSS
Síntoma | Causa posible | Vaya a... |
---|---|---|
No se iniciará ccoserver | Números de puerto en conflicto | Comprobación de los números de puerto de Cisco CSS Controller |
El mandato ccocontrol o lbadmin ha dado un error e indica el mensaje "El servidor no responde" o "No es posible acceder al servidor RMI" | Los mandatos dan un error debido a una pila con SOCKS. O porque no se inicia ccoserver | Problema: el mandato ccocontrol o lbadmin da un error |
Error de recepción: Cannot create registry on port 13099 (No se ha podido crear el registro en el puerto 13099) | Licencia del producto caducada | Problema: no se ha podido crear el registro en el puerto 13099 |
Comportamiento de la GUI inesperado cuando se utiliza la plataforma Windows con la tarjeta de vídeo Matrox AGP | Se produce un problema cuando se utilizan tarjetas de vídeo Matrox AGP al ejecutar la GUI de Load Balancer | Problema: en la plataforma Windows, se produce un comportamiento de la GUI inesperado al utilizar tarjetas de vídeo Matrox AGP |
Se ha recibido un error de conexión al añadir un consultor | Los valores de configuración son incorrectos en el conmutador o el controlador | Problema: se ha recibido un error de conexión al añadir un consultor |
No se actualizan los pesos en el conmutador | La comunicación entre el controlador o el conmutador no está disponible o se ha interrumpido | Problema: no se actualizan los pesos en el conmutador |
El mandato refresh no ha actualizado la configuración del consultor | La comunicación entre el controlador y el conmutador no está disponible o se ha interrumpido | Problema: el mandato refresh no ha actualizado la configuración del consultor |
Se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño. | Java no tiene acceso a suficiente memoria para gestionar un cambio de tan gran tamaño en la GUI | Problema: se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño |
Se produce una desconexión del host cuando se utiliza la administración Web remota mediante Netscape | Se producirá una desconexión del host cuando se cambie el tamaño de la ventana del navegador | Problema: se produce una desconexión del host si se cambia el tamaño de la ventana del navegador Netscape cuando se utiliza la administración Web |
En la plataforma Windows, aparecen en el indicador de mandatos caracteres nacionales Latin-1 dañados | Cambie las propiedades de font de la ventana de indicador de mandatos | Problema: en plataformas Windows, aparecen caracteres nacionales Latin-1 dañados en la ventana de indicador de mandatos |
En la plataforma HP-UX, aparece este mensaje: java.lang.OutOfMemoryError unable to create new native thread (java.lang.OutOfMemoryError no se ha podido crear una nueva hebra nativa) | Algunas instalaciones de HP-UX predeterminadas permiten 64 hebras por proceso. Esto es insuficiente. | Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. | Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado |
Tabla 21. Tabla de resolución de problemas de Nortel Alteon Controller
Síntoma | Causa posible | Vaya a... |
---|---|---|
No se iniciará nalserver | Números de puerto en conflicto | Comprobación de los números de puerto de Nortel Alteon Controller |
El mandato nalcontrol o lbadmin ha dado un error e indica el mensaje "El servidor no responde" o "No es posible acceder al servidor RMI" | Los mandatos dan un error debido a una pila con SOCKS. O porque no se inicia nalserver | Problema: el mandato nalcontrol o lbadmin da un error |
Error de recepción: Cannot create registry on port 14099 (No se ha podido crear el registro en el puerto 14099) | Licencia del producto caducada | Problema: no se ha podido crear el registro en el puerto 14099 |
Comportamiento de la GUI inesperado cuando se utiliza la plataforma Windows con la tarjeta de vídeo Matrox AGP | Se produce un problema cuando se utilizan tarjetas de vídeo Matrox AGP al ejecutar la GUI de Load Balancer | Problema: en la plataforma Windows, se produce un comportamiento de la GUI inesperado al utilizar tarjetas de vídeo Matrox AGP |
Se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño. | Java no tiene acceso a suficiente memoria para gestionar un cambio de tan gran tamaño en la GUI | Problema: se cierra la comunicación de la GUI (o tiene un comportamiento inesperado) cuando se intenta cargar un archivo de configuración de gran tamaño |
Se produce una desconexión del host cuando se utiliza la administración Web remota mediante Netscape | Se producirá una desconexión del host cuando se cambie el tamaño de la ventana del navegador | Problema: se produce una desconexión del host si se cambia el tamaño de la ventana del navegador Netscape cuando se utiliza la administración Web |
Se ha recibido un error de conexión al añadir un consultor | Los valores de configuración son incorrectos en el conmutador o el controlador | Problema: se ha recibido un error de conexión al añadir un consultor |
No se actualizan los pesos en el conmutador | La comunicación entre el controlador o el conmutador no está disponible o se ha interrumpido | Problema: no se actualizan los pesos en el conmutador |
El mandato refresh no ha actualizado la configuración del consultor | La comunicación entre el controlador y el conmutador no está disponible o se ha interrumpido | Problema: el mandato refresh no ha actualizado la configuración del consultor |
En la plataforma Windows, aparecen en el indicador de mandatos caracteres nacionales Latin-1 dañados | Cambie las propiedades de font de la ventana de indicador de mandatos | Problema: en sistemas Windows, aparecen caracteres nacionales Latin-1 dañados en la ventana de indicador de mandatos |
En la plataforma HP-UX, aparece este mensaje: java.lang.OutOfMemoryError unable to create new native thread (java.lang.OutOfMemoryError no se ha podido crear una nueva hebra nativa) | Algunas instalaciones de HP-UX predeterminadas permiten 64 hebras por proceso. Esto es insuficiente. | Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. | Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado |
Tabla 22. Tabla de resolución de problemas de Metric Server
Síntoma | Causa posible | Vaya a... |
---|---|---|
IOException de Metric Server en la plataforma Windows al ejecutar los archivos de métrica del usuario .bat o .cmd | Se requiere el nombre de métrica completo | Problema: IOException de Metric Server en la plataforma Windows al ejecutar archivos de métrica del usuario .bat o .cmd |
Metric Server no informa de la información de carga a la máquina de Load Balancer | Entre las causas posibles se incluyen:
| Problema: Metric Server no informa de las cargas en la máquina de Load Balancer |
El archivo de anotaciones cronológicas de Metric Server informa de que "Es necesaria la firma para acceder al agente" cuando se transfieren archivos de claves al servidor | El archivo de claves no ha superado la autorización debido a que está dañado. | Problema: el archivo de anotaciones cronológicas de Metric Server informa de que Es necesaria la firma para acceder al agente |
En sistemas AIX, cuando se ejecuta Metric Server bajo gran presión en un sistema multiprocesador (AIX 4.3.3 o AIX 5.1), podría dañar la salida del mandato ps -vg | APAR IY33804 corrige este problema de AIX conocido | Problema: en sistemas AIX, cuando se ejecuta Metric Server bajo mucha presión, la salida del mandato ps -vg podría dañarse |
Configuración de Metric Server en una configuración de dos niveles con el equilibrio de carga de Site Selector entre Dispatchers de alta disponibilidad | No se ha configurado Metric Server (que reside en el segundo nivel) para que esté a la escucha en una nueva dirección IP. | Problema: configuración de Metric Server en una configuración de dos niveles con el equilibrio de carga de Site Selector entre Dispatchers de alta disponibilidad |
Los scripts (metricserver, cpuload, memload) que se ejecutan en máquinas Solaris de varias CPU producen mensajes de la consola no deseados | Este comportamiento se debe al uso del mandato de sistema VMSTAT para recopilar estadísticas de la CPU y de memoria del kernel. | Problema: los scripts, en ejecución en máquinas Solaris de varias CPU, producen mensajes de consola no deseados |
En sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de la sesión de terminal desde la que se han iniciado | Utilice el mandato nohup para impedir que los procesos que ha iniciado reciban una señal de cierre de comunicación cuando sale de la sesión de terminal. | Problema: en sistemas Solaris, los procesos de Load Balancer finalizan cuando sale de la ventana de terminal desde la que se han iniciado |
El valor de métrica devuelve -1 después de iniciar Metric Server | Este problema puede deberse a que los archivos de claves pierden su integridad durante la transferencia de los mismos al cliente. | Problema: Después de iniciar Metric Server, el valor de métrica devuelve -1 |
Si experimenta problemas al ejecutar Dispatcher, quizá una de las aplicaciones esté utilizando un número de puerto que utiliza normalmente Dispatcher. Tenga en cuenta que el servidor de Dispatcher utiliza estos números de puerto:
Si otra aplicación está utilizando uno de los números de puerto de Dispatcher, puede cambiar los números de puerto de Dispatcher o bien el número de puerto de la aplicación.
Para cambiar los números de puerto de Dispatcher realice lo siguiente:
Para cambiar el número de puerto RMI de la aplicación realice lo siguiente:
Si experimenta problemas al ejecutar CBR, quizá una de las aplicaciones esté utilizando un número de puerto que CBR normalmente utiliza. Tenga en cuenta que CBR utiliza este número de puerto:
Si otra aplicación está utilizando uno de los números de puerto de CBR, puede cambiar los números de puerto de CBR o el número de puerto de la aplicación.
Para cambiar los números de puerto de CBR realice lo siguiente:
Para cambiar el número de puerto RMI de la aplicación realice lo siguiente:
Si experimenta problemas al ejecutar el componente Site Selector, quizá una de las aplicaciones esté utilizando un número de puerto que Site Selector normalmente utiliza. Tenga en cuenta que el servidor de Site Selector utiliza estos números de puerto:
Si otra aplicación está utilizando uno de los números de puerto de Site Selector, puede cambiar los números de puerto de Site Selector o bien el número de puerto de la aplicación.
Para cambiar los números de puerto de Site Selector realice lo siguiente:
Para cambiar el número de puerto RMI de la aplicación realice lo siguiente:
Si experimenta problemas al ejecutar el componente Cisco CSS Controller quizá otra aplicación esté utilizando uno de los números de puerto que utiliza ccoserver de Cisco CSS Controller. Tenga en cuenta que Cisco CSS Controller utiliza estos números de puerto:
13099 para recibir mandatos de ccocontrol
10004 para enviar consultas de métrica a Metric Server
13199 para el puerto del servidor RMI
Si otra aplicación está utilizando uno de los números de puerto de Cisco CSS Controller, puede cambiar los números de puerto de Cisco CSS Controller o bien el número de puerto de la aplicación.
Para cambiar los números de puerto de Cisco CSS Controller realice lo siguiente:
Para cambiar el número de puerto RMI de la aplicación realice lo siguiente:
Si experimenta problemas al ejecutar el componente Nortel Alteon Controller quizá otra aplicación esté utilizando uno de los números de puerto que utiliza nalserver de Nortel Alteon Controller. Tenga en cuenta que Nortel Alteon Controller utiliza estos números de puerto:
14099 para recibir mandatos de nalcontrol
10004 para enviar consultas de métrica a Metric Server
14199 para el puerto del servidor RMI
Si otra aplicación está utilizando uno de los números de puerto de Nortel Alteon Controller, puede cambiar los números de puerto para Nortel Alteon Controller o bien los números de puerto de la aplicación.
Para cambiar los números de puerto de Nortel Alteon Controller realice lo siguiente:
Para cambiar el número de puerto RMI de la aplicación realice lo siguiente:
Este problema puede producirse si otra aplicación utiliza uno de los puertos utilizados por Dispatcher. Para obtener más información, consulte el apartado Comprobación de los números de puerto de Dispatcher.
Este problema se produce cuando se utiliza otra dirección que no es la dirección especificada. Cuando utiliza una ubicación compartida para el Dispatcher y el servidor, asegúrese de que la dirección del servidor utilizada en la configuración es la dirección NFA o que se configura como ubicación compartida. Además, compruebe si el archivo de host tiene la dirección correcta.
Este problema tiene síntomas, por ejemplo, de conexiones de máquinas cliente no atendidas o de tiempo de espera de conexiones superado. Compruebe lo siguiente para diagnosticar este problema:
Para Windows y otras plataformas, consulte también el apartado Configuración de máquinas de servidor para el equilibrio de carga.
Este problema aparece cuando se configura un entorno de alta disponibilidad de Dispatcher y las conexiones de las máquinas cliente no se atienden o superan el tiempo de espera. Compruebe lo siguiente para corregir o diagnosticar el problema:
Los pasos siguientes son un modo eficaz de probar que los scripts de alta disponibilidad funcionan correctamente:
Los dos informes serán idénticos si se han configurado correctamente los scripts.
Este error de la plataforma Windows se produce si no se configura la dirección de origen en un adaptador. Compruebe lo siguiente para corregir o diagnosticar el problema.
dscontrol executor configure <dirección IP>
Después de configurar las máquinas servidor, puede encontrarse con que ha creado sin querer una o más rutas adicionales. Si no se eliminan, estas rutas adicionales impedirán el funcionamiento de Dispatcher. Para encontrarlas y suprimirlas, consulte el apartado Configuración de máquinas de servidor para el equilibrio de carga.
Si utiliza un soporte de área amplia y parece que los asesores no funcionan correctamente, asegúrese de que se inician en los dos Dispatcher, el local y el remoto.
Se emite un mandato ping de ICMP a los servidores antes de la petición del asesor. Si existe un cortafuegos entre Load Balancer y los servidores, asegúrese de que se admiten los mandatos ping en el cortafuegos. Si esta configuración posee un riesgo de seguridad para la red, modifique la sentencia java en dsserver para desactivar todos los mandatos ping a los servidores añadiendo la propiedad java:
LB_ADV_NO_PING="true" java -DLB_ADV_NO_PING="true"
Consulte el apartado Utilización de asesores remotos con el soporte de área amplia de Dispatcher.
Cuando utiliza Dispatcher, Microsoft IIS y SSL, si no funcionan juntos, quizá haya un problema con la habilitación de la seguridad SSL. Para obtener más información sobre cómo generar un par de claves, adquirir un certificado, instalar un certificado con un par de claves y configurar un directorio para solicitar SSL, consulte la documentación de Microsoft Information and Peer Web Services.
Dispatcher utiliza claves para permitirle conectar con una máquina remota y configurarla. Las claves especifican un puerto RMI para la conexión. Es posible cambiar el puerto RMI por motivos de seguridad o conflictos. Cuando cambia los puertos RMI, el nombre de archivo de la clave es distinto. Si tiene más de una clave en el directorio de claves para la misma máquina remota y las claves especifican puertos RMI distintos, la línea de mandatos sólo intentará la primera que encuentre. Si es incorrecta, se rechazará la conexión. No se realizará la conexión a no ser que suprima la clave incorrecta.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Esto puede producir problemas si una de las consolas de administración se ejecuta en la misma máquina que un cortafuegos o a través de un cortafuegos. Por ejemplo, cuando se ejecuta Load Balancer en la misma máquina que un cortafuegos y emite mandatos dscontrol, podrían aparecer errores como Error: el servidor no responde.
Para impedir este problema, edite el archivo de scripts dsserver para establecer el puerto utilizado por RMI para el cortafuegos (u otra aplicación). Cambie la línea: LB_RMISERVERPORT=10199 por LB_RMISERVERPORT=suPuerto. Donde suPuerto es otro puerto.
Cuando haya terminado, reinicie dsserver y abra el tráfico para los puertos: 10099, 10004, 10199 y 10100 o para el puerto seleccionado para la dirección del host desde donde se ejecutará la consola de administración.
Por ejemplo: java -Djava.rmi.server.hostname="10.1.1.1"
Para plataformas Windows, cuando utiliza Netscape como el navegador predeterminado, puede producirse este mensaje de error: "No se puede encontrar el archivo '<nombrearchivo>.html' (o uno de sus componentes). Asegúrese de que la vía de acceso y el nombre de archivo sean correctos y de que están disponibles todas las bibliotecas necesarias".
El problema se debe a un valor incorrecto de la asociación de archivo HTML. Esta es la solución:
La GUI (interfaz gráfica de usuario), que es lbadmin, requiere una cantidad de espacio de paginación suficiente para funcionar correctamente. Si no hay disponible suficiente espacio para paginación, quizá la GUI no se inicie completamente. Si ocurriera esto, compruebe el espacio de paginación y auméntelo si es necesario.
Si desinstala Load Balancer para volver a instalar otra versión y obtiene un error al intentar iniciar el componente Dispatcher, compruebe si se ha instalado Caching Proxy. Caching Proxy tiene una dependencia en uno de los archivos de Dispatcher; este archivo se desinstalará sólo cuando se desinstale Caching Proxy.
Para evitar este problema:
Si experimenta problemas con la apariencia de la GUI de Load Balancer, compruebe el valor de la resolución del escritorio del sistema operativo. La GUI se visualiza mejor con una resolución de 1024x768 píxeles.
En la plataforma Windows, cuando abre por primera vez las ventanas de ayuda, a veces desaparecen en el fondo detrás de ventanas existentes. Si esto sucediera, pulse en la ventana para traerla de nuevo al frente.
En Solaris cada adaptador de red tiene la misma dirección MAC predeterminada. Esto funciona correctamente si cada adaptador se encuentra en una subred IP distinta; no obstante, en un entorno conmutado, cuando varias NIC con la misma dirección MAC y la misma dirección de subred IP se comunican con el mismo conmutador, el conmutador envía todo el tráfico enlazado para la dirección MAC única (y las dos IP) al mismo cable. Sólo el adaptador que incluyó por última vez una trama en el cable detecta los paquetes IP enlazados para los dos adaptadores. Solaris podría descartar paquetes para una dirección IP válida que llegaran en la interfaz "incorrecta".
Si las interfaces de red no están diseñadas para Load Balancer como se configura en ibmlb.conf y si la tarjeta NIC que no se define en ibmlb.conf recibe una trama, Load Balancer no tiene la posibilidad de procesar y reenviar la trama.
Para evitar este problema, debe alterar temporalmente el valor predeterminado y establecer una dirección MAC única para cada interfaz. Utilice este mandato:
ifconfig interfaz ether dirMac
Por ejemplo:
ifconfig eri0 ether 01:02:03:04:05:06
En la plataforma Windows, debe tener instalada y configurada una tarjeta de red antes de iniciar el ejecutor.
El sistema operativo AIX contiene un parámetro de red llamado descubrimiento de MTU de la vía de acceso. Durante la transacción con un cliente, si el sistema operativo determina que debe utilizar una unidad de transmisión máxima (MTU) más pequeña para los paquetes, el descubrimiento de MTU de la vía de acceso hace que AIX cree una ruta para recordar ese dato. La nueva ruta es para esa dirección IP del cliente específica y graba la MTU necesaria para llegar a ella.
Cuando se crea la ruta, podría aparecer un problema en los servidores provocado por el clúster del que se crea un alias en el bucle de retorno. Si la dirección de pasarela para la ruta está dentro de la subred del clúster/máscara de red, los sistemas AIX crean la ruta en el bucle de retorno. Esto sucede porque esa era la última interfaz con alias con esa subred.
Por ejemplo, si el clúster es 9.37.54.69 y se utiliza una máscara de red 255.255.255.0 y la pasarela prevista es 9.37.54.1, los sistemas AIX utilizarán el bucle de retorno para la ruta. Esto provoca que las respuestas del servidor nunca abandonen la máquina y que el cliente supere el tiempo de espera. El cliente suele detectar una respuesta del clúster, luego se crea la ruta y el cliente ya no recibe nada más.
Hay dos soluciones para este problema.
Notas:
Cuando configura un Load Balancer de área amplia, debe definir el Dispatcher remoto como un servidor de un clúster en el Dispatcher local. Normalmente, puede utilizar la dirección de no reenvío (NFA) del Dispatcher remoto como la dirección de destino del servidor remoto. Si hace esto y configura la alta disponibilidad en el Dispatcher remoto, dará un error. Esto sucede porque el Dispatcher local siempre señala a la máquina primaria en el lado remoto cuando utiliza su dirección NFA para acceder a ésta.
Para solucionar este problema:
Cuando aparece el Dispatcher primario remoto, creará un alias de esta dirección en su adaptador, que le permite aceptar tráfico. Si se produce una anomalía, la dirección se desplaza a la máquina de reserva y ésta sigue aceptando el tráfico de esa dirección.
Cuando se utiliza lbadmin o la administración Web (lbwebaccess) para cargar un archivo de configuración de gran tamaño (unos 200 o más mandatos add), podría cerrarse la comunicación de la GUI o mostrar un comportamiento inesperado, como una respuesta sumamente lenta a los cambios de pantalla.
Esto se produce porque Java no tiene acceso a suficiente memoria para gestionar una configuración de tan gran tamaño.
Hay una opción en el entorno de ejecución que se puede especificar para aumentar la agrupación de asignaciones de memoria en Java.
La opción es -Xmxn donde n es el tamaño máximo, en bytes, para la agrupación de asignaciones de memoria. n debe ser múltiplo de 1024 y ser mayor que 2 MB. El valor n debe ir seguido de k o K para indicar kbytes o de m o M para indicar megabytes. Por ejemplo, -Xmx128M y -Xmx81920k son dos valores válidos. El valor predeterminado son 64 M. Solaris 8 tiene un valor máximo de 4000 M.
Por ejemplo, para añadir esta opción, edite el archivo de scripts lbadmin, modificando "javaw" con "javaw -Xmxn" como se detalla a continuación. (Para sistemas AIX, cambie "java" por "java -Xmxn"):
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
javaw -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
java -Xmx256m -cp $LB_CLASSPATH $LB_INSTALL_PATH $LB_CLIENT_KEYS com.ibm.internet.nd.framework.FWK_Main 1>/dev/null 2>&1 &
START javaw -Xmx256m -cp %LB_CLASSPATH% %LB_INSTALL_PATH% %LB_CLIENT_KEYS% com.ibm.internet.nd.framework.FWK_Main
No hay ningún valor recomendado para n, pero debería ser mayor que la opción predeterminada. Un buen punto de partida sería el doble del valor predeterminado.
Si la administración de Load Balancer (lbadmin) realiza la desconexión del servidor después de actualizar la configuración, compruebe la versión de dsserver en el servidor que intenta configurar y asegúrese de que es la misma que la versión de lbadmin o dscontrol.
Cuando se utiliza un cliente remoto en una implementación de SOCKS segura, quizá los nombres de dominio o de host plenamente cualificados no se resuelvan con la dirección IP correcta en notación de dirección IP. La implementación de SOCKS podría añadir datos específicos, relacionados con SOCKS a la resolución de DNS.
Si una dirección IP no se resuelve correctamente en la conexión remota, especifique la dirección IP en el formato de notación de dirección IP.
Para corregir el solapamiento de fonts o fonts no deseados en la interfaz coreana de Load Balancer:
En sistemas AIX
-Monotype-TimesNewRomanWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
-Monotype-SansMonoWT-medium-r-normal --*-%d-75-75-*-*-ksc5601.1987-0
En sistemas Linux
-monotype- timesnewromanwt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
-monotype-sansmonowt-medium-r-normal--*-%d-75-75-p-*-microsoft-symbol
En sistemas Windows, después de crear un alias del adaptador MS Loopback, cuando emita determinados mandatos como hostname, el sistema operativo responderá incorrectamente con la dirección del alias en lugar de la dirección local. Para corregir este problema, en la lista de conexiones de red, el alias recién añadido debe enumerarse bajo la dirección local. Esto asegurará que se accede a la dirección local antes que al alias de bucle de retorno.
Para comprobar la lista de conexiones de red:
En la plataforma Windows cuando utiliza una tarjeta Matrox AGP, puede aparecer un comportamiento inesperado en la GUI de Load Balancer. Cuando pulsa el ratón, podría dañarse un bloque de espacio ligeramente mayor que el puntero del ratón provocando una posible inversión del resaltado o un desplazamiento de imágenes fuera del lugar de la pantalla. Las tarjetas Matrox anteriores no han mostrado este comportamiento. No hay un fix pack conocido cuando se utilizan tarjetas Matrox AGP.
En sistemas Linux, si dsserver todavía está en ejecución durante la eliminación manual del módulo kernel de Load Balancer, puede producirse un comportamiento inesperado, como un javacore o que se cierre la comunicación del sistema. Cuando elimina manualmente el módulo kernel de Load Balancer, primero debe detener dsserver.
Si no funciona "dsserver stop", detenga el proceso java con SRV_KNDConfigServer. Para detener el proceso encuentre su identificador de proceso utilizando el mandato ps -ef | grep SRV_KNDConfigServer y finalice el proceso utilizando el mandato kill id_proceso.
Puede ejecutar de modo seguro el mandato "rmmod ibmlb" para eliminar el módulo Load Balancer del kernel.
Si ejecuta el componente Dispatcher para el equilibrio de carga, es posible sobrecargar el sistema con tráfico del cliente. El módulo kernel de Load Balancer tiene la máxima prioridad y, si gestiona constantemente paquetes del cliente, el resto del sistema podría quedarse sin respuesta. La ejecución de mandatos en el espacio de usuario puede llevar mucho tiempo completarse o puede que nunca se complete.
Si esto sucede, debería comenzar a reestructurar su configuración para impedir la sobrecarga de la máquina de Load Balancer con tráfico. Entre las alternativas se incluye distribuir la carga entre varias máquinas de Load Balancer o sustituir la máquina con un sistema más consistente y más rápido.
Cuando intente determinar si el tiempo de respuesta lento en la máquina se debe a un alto volumen de tráfico del cliente, considere si esto se produce durante los momentos de tráfico máximo del cliente. Los sistemas mal configurados que provocan bucles de direccionamiento también pueden provocar los mismos síntomas. Pero antes de cambiar la configuración de Load Balancer, determine si los síntomas pueden deberse a un gran volumen de carga del cliente.
Cuando se utiliza el método de reenvío mac, Load Balancer enviará paquetes a los servidores utilizando la dirección del clúster de la que se ha creado un alias en el bucle de retorno. Algunas aplicaciones servidor (como SSL) requieren que la información de configuración (como los certificados) sea según la dirección IP. La dirección IP debe ser la dirección del clúster que se configura en el bucle de retorno para que corresponda al contenido de los paquetes de entrada. Si no se utiliza la dirección IP del clúster cuando se configura la aplicación servidor, no se reenviará correctamente la petición del cliente al servidor.
Si utiliza la administración Web remota para configurar Load Balancer, no cambie el tamaño (Minimizar, Maximizar, Restaurar minimizando, etc.) de la ventana del navegador Netscape en la que aparece la GUI de Load Balancer. Dado que Netscape vuelve a cargar una página cada vez que se cambia el tamaño de la ventana del navegador, esto provocará una desconexión del host. Tendrá que volver a conectar con el host cada vez que cambie el tamaño de la ventana. Si realiza administración Web remota en la plataforma Windows, utilice Internet Explorer.
Cuando ejecuta el servidor IIS de Microsoft versión 5.0 en servidores finales Windows, debe configurar el servidor IIS de Microsoft para que sea específico del enlace. De lo contrario, se inhabilitará la agrupación de sockets predeterminada y el servidor Web se enlazará a 0.0.0.0 y realizará la escucha de todo el tráfico, en lugar de enlazar a las direcciones IP virtuales configuradas como varias identidades para el sitio. Si se queda inactiva una aplicación en el host local cuando está habilitada la agrupación de sockets, los asesores del servidor ND de AIX o Windows detectarán esto; no obstante, si se queda inactiva una aplicación en un host virtual cuando el host local está activo, los asesores no detectarán la anomalía y Microsoft IIS seguirá respondiendo a todo el tráfico, incluida la aplicación inactiva.
Para determinar si está habilitada la agrupación de sockets y si el servidor Web se enlaza a 0.0.0.0, emita este mandato:
netstat -an
Las instrucciones sobre cómo configurar el servidor IIS de Microsoft para que sea específico de enlace (inhabilite la agrupación de sockets), se encuentran en el sitio Web de servicios de soporte del producto Microsoft. También puede visitar una de estas URL para obtener esta información:
En las ventanas de indicador de mandatos del sistema operativo Windows, quizá algunos caracteres nacionales de la familia Latin-1 aparezcan dañados. Por ejemplo, la letra "a" con una tilde podría mostrarse como el símbolo pi. Para corregir esto, debe cambiar las propiedades de font de la ventana de línea de mandatos. Para cambiar el font, realice lo siguiente:
Algunas instalaciones de HP-UX 11i están preconfiguradas para sólo permitir 64 hebras por proceso. No obstante, algunas configuraciones de Load Balancer requieren una cantidad mayor. En los sistemas HP-UX, establezca las hebras por proceso como mínimo en 256. Para aumentar este valor, utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc. Si se espera un uso masivo, puede ser necesario aumentar max_thread_proc por encima de 256.
Para aumentar max_thread_proc, haga lo siguiente:
Cuando configura el adaptador en una máquina de Load Balancer, debe asegurarse de que los dos valores siguientes son correctos para que el asesor funcione:
En la plataforma Windows, cuando configura un adaptador con más de una dirección IP, configure la dirección IP que desea afiliar al nombre de host primero del registro.
Puesto que Load Balancer depende de InetAddress.getLocalHost() en muchas instancias (por ejemplo, lbkeys create), varias direcciones IP que tienen un alias con un sólo adaptador podrían provocar problemas. Para impedir este problema, enumere la dirección IP con la que desea que se resuelva la dirección IP primero en el registro. Por ejemplo:
De manera predeterminada, cuando el sistema operativo Windows detecta una caída de la red, borra su memoria caché ARP (Address Resolution Protocol), incluidas todas las entradas estáticas. Cuando la red está disponible, la memoria caché ARP se vuelve a rellenar con peticiones ARP enviadas en la red.
Con una configuración de alta disponibilidad, cuando una pérdida de conectividad de red influye en uno o los dos servidores, éstos se hacen con el control de las operaciones primarias. Cuando se envía la petición ARP para rellenar la memoria caché ARP, los dos servidores responden, lo que provoca que la memoria caché ARP marque la entrada como no válida. Por lo tanto, los asesores no pueden crear un socket para los servidores finales.
Si se impide que el sistema operativo Windows borre la memoria caché ARP cuando hay una pérdida de conectividad se soluciona este problema. Microsoft ha publicado un artículo que describe cómo llevar a cabo esta tarea. Este artículo está en el sitio Web de Microsoft, ubicado en la en la base de información de Microsoft, artículo número 239924: http://support.microsoft.com/default.aspx?scid=kb;en-us;239924.
A continuación figura un resumen de los pasos, que se describen en el artículo de Microsoft, para impedir que el sistema borre la memoria caché ARP:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters
Se deben tener determinadas consideraciones cuando se utilizan servidores Linux kernel 2.4.x y el método de reenvío MAC de Dispatcher. Si el servidor tiene una dirección del clúster configurada en el dispositivo de bucle de retorno utilizando el mandato ip address add, sólo se puede crear un alias de clúster de dirección.
Cuando cree un alias de varios clústeres con el dispositivo de bucle de retorno utilice el mandato ifconfig, por ejemplo:
ifconfig lo:num dirección_clúster netmask 255.255.255.255 up
Además, hay incompatibilidades entre los métodos ifconfig e ip de configurar interfaces. El procedimiento recomendado sugiere que un sitio seleccione un método y utilice ese método de forma exclusiva.
Cuando añade servidores a la configuración de Dispatcher, puede producirse este mensaje de error: "Error: dirección del direccionador no especificada o no válida para el método del puerto".
Utilice la lista de comprobación para determinar el problema:
El valor predeterminado del parámetro de direccionador es 0, que indica que el servidor es local. Si establece la dirección del direccionador del servidor en un valor que no es 0, esto indica que es un servidor remoto, en una subred distinta. Para obtener más información sobre el parámetro router del mandato add, consulte el apartado dscontrol server -- configurar servidores.
Si el servidor que añade se ubica en una subred distinta, el parámetro de direccionador debería ser la dirección del direccionador que se va a utilizar en la subred local para comunicarse con el servidor remoto.
En sistemas Solaris, después de iniciar scripts de Load Balancer (como dsserver o lbadmin) desde una ventana de terminal, si sale de esa ventana, también sale el proceso de Load Balancer.
Para solucionar este problema, inicie los scripts de Load Balancer con el mandato nohup. Por ejemplo: nohup dsserver. Este mandato impide que los procesos iniciados desde la sesión de terminal reciban una señal de cierre de comunicación del sistema del terminal cuando sale, que permite a los procesos continuar incluso después de que haya finalizado la sesión de terminal. Utilice el mandato nohup delante de cualquier script de Load Balancer que desee seguir procesando cuando haya terminado la sesión de terminal.
La configuración de Load Balancer puede tardar mucho en cargarse debido a las llamadas al Sistema de nombres de dominio (DNS) que se realizan para resolver y verificar la dirección de servidor.
Si el DNS de la máquina de Load Balancer se configura incorrectamente o si el DNS en general lleva mucho tiempo, disminuirá la velocidad de la carga de la configuración debido a los procesos Java que envían peticiones de DNS en la red.
Una solución para esto es añadir las direcciones del servidor y los nombres de host al archivo /etc/hosts local.
Si se configura la alta disponibilidad, podrían configurarse direcciones del clúster en las dos máquinas por un breve período y provocar este mensaje de error: Hay un conflicto de dirección IP con otro sistema en la red. En este caso, puede ignorar el mensaje con seguridad. Es posible que una dirección del clúster se configure brevemente en las dos máquinas de alta disponibilidad a la vez, especialmente durante el inicio de cualquiera de las máquinas o cuando se ha iniciado la toma del control.
Compruebe los scripts go* para asegurarse de que configuran y desconfiguran correctamente direcciones del clúster. Si ha invocado un archivo de configuración y tiene scripts go* instalados, asegúrese de que no tiene ninguna sentencia de mandato "executor configure" para las direcciones del clúster en el archivo de configuración, porque esto entrará en conflicto con los mandatos configure y unconfigure de los scripts go*.
Si desea más información sobre scripts go* cuando configura la característica de alta disponibilidad, consulte el apartado Utilización de scripts.
Este problema podría producirse cuando no se ejecutan los scripts go en alguna de las máquinas primaria o de reserva. Los scripts go no pueden ejecutarse si no se ha iniciado dsserver en las dos máquinas. Compruebe las dos máquinas y asegúrese de que dsserver está en ejecución.
Las peticiones del cliente que producen unas respuestas de páginas de gran tamaño superan el tiempo de espera si la unidad de transmisión máxima (MTU) no se establece correctamente en la máquina de Dispatcher. Para los métodos de reenvío cbr y nat del componente Dispatcher, esto puede suceder porque Dispatcher toma de manera predeterminada el valor de la MTU, en lugar de negociar el valor.
La MTU se establece en cada sistema operativo basándose en el tipo de soporte de comunicaciones (por ejemplo, Ethernet o Token-Ring). Los direccionadores del segmento local podrían tener establecida una MTU de menor tamaño si se conectan con un tipo de soporte de comunicaciones distinto. En condiciones de tráfico normal de TCP, se produce una negociación de la MTU durante la configuración de la conexión y se utiliza la MTU de menor tamaño para enviar datos entre máquinas.
Dispatcher no admite la negociación de la MTU para el método de reenvío cbr o nat de Dispatcher porque interviene activamente como un punto final para conexiones TCP. Para el reenvío cbr y nat, Dispatcher toma de manera predeterminada el valor de MTU de 1500 . Este valor es el tamaño de la MTU típico para Ethernet estándar, de manera que la mayoría de los clientes no tienen que ajustar este valor.
Cuando se utiliza el método de reenvío cbr o nat de Dispatcher, si tiene un direccionador al segmento local que tiene una MTU de menor tamaño, debe establecer la MTU en la máquina de Dispatcher para que coincida con la MTU de menor tamaño.
Para resolver este problema, utilice el mandato siguiente para establecer el valor del tamaño de segmento máximo (mss): dscontrol executor set mss nuevo_valor
Por ejemplo:
dscontrol executor set mss 1400
El valor predeterminado de mss es 1460.
El valor de mss no se aplica para el método de reenvío mac de Dispatcher ni para ningún otro componente no Dispatcher de Load Balancer.
Cuando existe más de una dirección IP en un sistema Windows y el archivo hosts no especifica la dirección que se va a asociar al nombre de host, el sistema operativo selecciona la dirección de menor tamaño para asociarla al nombre de host.
Para resolver este problema, actualice el archivo c:\Windows\system32\drivers\etc\hosts con el nombre de host de su máquina y la dirección IP que desee asociar al nombre de host.
IMPORTANTE: la dirección IP no puede ser una dirección del clúster.
Cuando utiliza la característica de alta disponibilidad en máquinas Linux para S/390 con el controlador de red qeth, puede que los Dispatcher activo y en espera no se sincronicen. Este problema podría limitarse a Linux Kernel 2.6.
Si aparece este problema, utilice este método alternativo:
Defina un dispositivo de red de canal a canal (CTC) entre las imágenes de Dispatcher activa y en espera y añada pulsos entre las dos direcciones IP de punto final de CTC.
Con la función de alta disponibilidad de Load Balancer, una máquina asociada puede tomar el control del equilibrio de carga si la máquina asociada primaria sufre una anomalía o se apaga. Para mantener conexiones entre las máquinas asociadas de alta disponibilidad, se pasan entre ellas registros de conexión. Cuando la máquina asociada en espera toma el control de la función de equilibrio de carga, la dirección IP de clúster se suprime de la máquina en espera y se añade a la nueva máquina primaria. Esta operación de toma de control puede verse afectada por muchos factores de tiempo y configuración.
Las sugerencias que se detallan en este apartado puede ayudarle a reducir la cantidad de problemas derivados de los problemas de configuración de alta disponibilidad, como por ejemplo:
Las siguientes sugerencias le ayudarán a configurar correctamente la característica de alta disponibilidad de las máquinas de Load Balancer.
Ejemplos de mandatos de alta disponibilidad son:
dscontrol highavailability heartbeat add ... dscontrol highavailability backup add ... dscontrol highavailability reach add ...
En la mayoría de los casos, debe colocar las definiciones de alta disponibilidad al final del archivo. Las sentencias de clúster, puerto y servidor se deben colocar antes de las sentencias de alta disponibilidad. Esto se debe a que al sincronizar la alta disponibilidad, busca las definiciones de clúster, puerto y servidor cuando se recibe un registro de conexión.
Si el clúster, puerto y servidor no existen, se elimina el registro de conexión. Si se produce una toma de control y el registro de conexión no se ha duplicado en la máquina asociada, la conexión falla.
La excepción a esta regla es cuando se utilizan servidores con ubicación compartida que configurados con el método de reenvío MAC. En este caso, las sentencias de alta disponibilidad deben indicarse antes de las sentencias de servidor con ubicación compartida. Si las sentencias de alta disponibilidad no se indican antes de las sentencias de servidor con ubicación compartida, Load Balancer recibe una petición para el servidor con ubicación compartida, pero parece la misma que una petición entrante para el clúster y se equilibra la carga. Esto lleva a una repetición en bucle de los paquetes de la red y a un tráfico excesivo. Cuando las sentencias de alta disponibilidad se colocan antes del servidor con ubicación compartida, Load Balancer sabe que no debe reenviar tráfico entrante a menos que esté en estado ACTIVO.
Para corregir este comportamiento, añada un retardo de inactividad en el script goActive. El intervalo de tiempo de inactividad necesario depende del despliegue. Se recomienda iniciar con un tiempo de demora de inactividad de 10.
De manera predeterminada, las máquinas intentan comunicarse entre sí cada medio segundo y detectarán una anomalía después de cuatro intentos fallidos. Si hay mucha actividad en la máquina, esto puede producir casos de sustitución por anomalía cuando el sistema en realidad sigue funcionando correctamente. Puede aumentar el número de veces hasta que se produce la anomalía emitiendo:
dscontrol executor set hatimeout <valor>
Para llevarlo a cabo, las conexiones antiguas no deben permanecer en la memoria durante un periodo de tiempo largo. En concreto, han habido problemas con los puertos LDAP y grandes periodos staletimeout (más de un un día). Si se establece un periodo staletimeout grande las conexiones antiguas permanecerán en memoria, lo que provocará que se pasen más registros de conexión durante la sincronización así como más uso de memoria en las dos máquinas.
Si la sincronización sufre una anomalía con un periodo staletimeout razonable, puede aumentar el tiempo de espera de sincronización emitiendo el mandato:
e xm 33 5 nuevo_tiempoEste mandato no se almacena en el archivo de configuración cuando se guarda, por lo tanto tendrá que añadirlo manualmente al archivo de configuración si desea que el valor se conserve después de cada conclusión.
El valor de tiempo de espera se almacena en mitad de segundos; por lo tanto, el valor predeterminado de nuevo_tiempo es 100 (50 segundos).
En general, cuando se utiliza el método de reenvío MAC, los servidores de la configuración de Load Balancer deben estar todos en el mismo segmento de red misma, independientemente de la plataforma. Los dispositivos de red activos como el direccionador, los puentes y los cortafuegos dificultan el funcionamiento de Load Balancer. Esto se debe a las funciones de Load Balancer, como un direccionador especializado, que sólo modifican las cabeceras de capa de enlace para su salto siguiente y final. Cualquier topología de red en la que el salto siguiente no sea el último salto no es válida para Load Balancer.
Se trata de una limitación para los servidores zSeries y S/390 que comparten la tarjeta OSA, porque este adaptador opera de forma distinta a la mayoría de las tarjetas de red. La tarjeta OSA dispone de una implementación de capa de enlace propia, que no tiene nada que ver con Internet, que se muestra a los hosts Linux y z/OS por detrás. En efecto, las tarjetas OSA se comunican como si fueran sistemas de Ethernet a Ethernet (no como hosts OSA) y los hosts que la utilizan responderán como si fueran Ethernet.
La tarjeta OSA también lleva a cabo algunas funciones que se relacionan directamente con la capa IP. Un ejemplo de la función que realiza es responder a peticiones ARP (Address Resolution Protocol). Otra función es que la tarjeta OSA compartida direcciona los paquetes IP en base a la dirección IP de destino, en lugar de una dirección Ethernet como un conmutador de capa 2. En efecto, la tarjeta OSA es en sí un segmento de red con puente.
Load Balancer ejecutándose en un host S/390 Linux o zSeries Linux puede efectuar reenvíos a hosts en el mismo OSA o a hosts en Ethernet. Todos los hosts que comparten OSA están en efecto en el mismo segmento.
Load Balancer puede reenviar fuera de una tarjeta OSA compartida debido a la naturaleza del puente de OSA. El puente reconoce el puerto OSA propietario de la dirección IP de clúster. El puente reconoce la dirección MAC de los hosts conectados directamente con el segmento Ethernet. Por lo tanto, Load Balancer puede utilizar el reenvío MAC a través de un puente OSA.
Sin embargo, Load Balancer no puede realizar reenvíos a una tarjeta OSA compartida. Esto incluye Load Balancer en un sistema S/390 Linux cuando el servidor de activar está en una tarjeta OSA distinta de la de Load Balancer. La tarjeta OSA correspondiente al servidor de servidor anuncia la dirección MAC de OSA para la dirección IP del servidor, pero cuando llega un paquete con la dirección de destino Ethernet de la tarjeta OSA del servidor y la dirección IP del clúster, la tarjeta OSA del servidor no sabe cuál de los hosts, si hay alguno, debe recibir dicho paquete. Los mismos principios que permiten que el reenvío MAC de OSA a Ethernet funcione fuera de una tarjeta OSA compartida no se aplican al intentar el reenvío a una tarjeta OSA compartida.
Método alternativo:
En configuraciones de Load Balancer que utilizan servidores zSeries o S/390 que tienen tarjetas OSA; hay dos enfoques que puede utilizar para resolver temporalmente el problema descrito.
Si los servidores de la configuración de Load Balancer están en el mismo tipo de plataforma zSeries o S/390, puede definir conexiones de punto a punto (CTC o IUCV) entre Load Balancer y cada servidor. Configurar los puntos finales con direcciones IP privadas. La conexión de punto a punto sólo se utiliza para el tráfico de Load Balancer a servidor. A continuación, añada los servidores con la dirección IP del punto final de servidor del túnel. Con esta configuración, el tráfico de clúster atraviesa la tarjeta OSA de Load Balancer y se reenvía a través de la conexión punto a punto donde el servidor responde mediante su propia ruta predeterminada. La respuesta utiliza la tarjeta OSA del servidor para enviarse, que puede o no ser la misma tarjeta.
Si los servidores de la configuración de Load Balancer no están en el mismo tipo de plataforma zSeries o S/390, o si no es posible definir una conexión de punto a punto entre Load Balancer y cada servidor, se recomienda utilizar la característica GRE (encapsulamiento genérico de direccionamiento) de Load Balancer, que es un protocolo que permite a Load Balancer realizar reenvíos a través de direccionadores.
Al utilizar GRE, Load Balancer recibe el paquete de IP cliente -> clúster encapsulado y lo envía al servidor. En el servidor, el paquete IP de cliente -> clúster original se excapsula y el servidor responde directamente al cliente. La ventaja de utilizar GRE es que Load Balancer sólo detecta el tráfico de cliente a servidor, no detecta el tráfico de servidor a cliente. La desventaja es que reduce el tamaño de segmento máximo (MSS) de la conexión TCP debido a la carga adicional de encapsulación.
Para configurar Load Balancer para realizar reenvíos con encapsulación GRE, añada los servidores utilizando el siguiente mandato:
dscontrol server add dir_clúster:puerto:servidor_programa_fondo router servidor_programa_fondo
Donde router backend_server es válido si Load Balancer y el servidor de programa de fondo están en la misma subred IP. De lo contrario, especifique como direccionador la dirección IP válida del salto siguiente.
Para configurar sistemas Linux para realizar la excapsulación GRE nativa, para cada servidor de programa de fondo, emita los siguientes mandatos:
modprobe ip_gre ip tunnel add grelb0 mode gre ikey 3735928559 ip link set grelb0 up ip addr add dir_clúster dev grelb0
En algunas versiones de Linux Red Hat, cuando se ejecuta Load Balancer configurado con las características de gestor y asesor, pueden producirse pérdidas de memoria importantes. La pérdida de memoria Java aumenta si configura un valor pequeño de intervalo de tiempo para el asesor.
Las versiones de la MVM de SDK Java de IBM y la biblioteca de hebras POSIX nativa (NPTL) que se entregan con algunas distribuciones Linux, como Red Hat Enterprise Linux 3.0, pueden hacer que se produzca la pérdida de memoria. La biblioteca de hebras mejorada NPTL que se proporciona con algunas distribuciones de sistemas Linux como Red Hat Enterprise Linux 3.0 da soporte a NPTL.
Consulte http://www.ibm.com/developerworks/java/jdk/linux/tested.html para obtener la última información sobre sistemas Linux y el SDK Java de IBM que se entrega con estos sistemas.
Como herramienta de determinación de problemas, utilice el mandato vmstat o ps para detectar pérdidas de memoria.
Para corregir la pérdida de memoria, emita el siguiente mandato antes de ejecutar la máquina Load Balancer para así inhabilitar la biblioteca NPTL:
export LD_ASSUME_KERNEL=2.4.10
En SuSe Linux Enterprise Server 9, cuando se utiliza el método de reenvío MAC, el informe de Dispatcher puede indicar que se ha reenviado el paquete (la cuenta de paquetes aumenta); sin embargo, el paquete nunca llega al servidor de programa de fondo.
Cuando aparece este problema, puede observar uno de estos comportamientos o ambos:
ip_finish_output2: No hay caché de cabecera ni vecina
ICMP No se puede alcanzar la fragmentación: es necesaria la fragmentación
Este problema puede deberse al módulo NAT de tablas ip que se carga. En SLES 9, hay un posible error, aunque sin confirmar, que provoca un comportamiento extraño al interactuar con Dispatcher.
Solución:
Descargue el módulo NAT de iptables y el módulo de seguimiento de conexiones.
Por ejemplo:
# lsmod | grep ip iptable_filter 3072 0 iptable_nat 22060 0 ip_conntrack 32560 1 iptable_nat ip_tables 17280 2 iptable_filter,iptable_nat ipv6 236800 19 # rmmod iptable_nat # rmmod ip_conntrack
Elimine los módulos en el orden de utilización. De manera específica, puede eliminar un módulo sólo si la cuenta de referencia (la última columna de la salida lsmod) es cero. Si ha configurado alguna regla en iptables, debe eliminarla. Por ejemplo: iptables -t nat -F.
El módulo iptable_nat utiliza ip_conntrack, por lo que primero se debe eliminar el módulo iptable_nat y, a continuación, el módulo ip_conntrack.
En sistemas Windows, si ejecuta la característica de alta disponibilidad de Load Balancer, los scripts go* se utilizan para configurar la dirección IP de clúster en el sistema activo de Load Balancer y para desconfigurar la dirección IP de clúster del sistema de reserva cuando se produce una toma de control. Si se ejecuta el script go* que configura la dirección IP de clúster de la máquina activa antes de ejecutar el script go* para desconfigurar la dirección IP de clúster de la máquina en espera, pueden surgir problemas. Es posible que aparezca una ventana emergente que le indique que el sistema ha detectado un conflicto entre direcciones IP. Si ejecuta el mandato ipconfig \all, también puede ver que aparece una dirección IP 0.0.0.0 de la máquina.
Solución:
Emita el mandato siguiente para desconfigurar manualmente la dirección IP de clúster de la máquina primaria:
dscontrol executor unconfigure IP_clúster
De esta manera se elimina la dirección 0.0.0.0 de la pila IP de Windows.
Una vez que la máquina asociada de alta disponibilidad libera la dirección IP de clúster, emita el siguiente mandato para volver a añadir manualmente la dirección IP de clúster:
dscontrol executor configure IP_clúster
Después de emitir este mandato, busque de nuevo la dirección IP de clúster en la pila IP de Windows emitiendo el siguiente mandato:
ipconfig /all
iptables en Linux pueden dificultar el equilibrio de carga y debe estar inhabilitado en la máquina de Dispatcher.
Emita el mandato siguiente para determinar si se han cargado iptables:
lsmod | grep ip_tables
La salida del mandato anterior puede ser parecida a la siguiente:
ip_tables 22400 3 iptable_mangle,iptable_nat,iptable_filter
Emita el siguiente mandato para cada iptable que aparece en la salida para visualizar las reglas de las tablas:
iptables -t <nombre_abreviado> -L
Por ejemplo:
iptables -t mangle -L iptables -t nat -L iptables -t filter -L
Si iptable_nat se ha cargado, se debe descargar. Puesto que iptable_nat tiene una dependencia en iptable_conntrack, también se debe eliminar iptable_conntrack. Emita el mandato siguiente para descargar estos dos iptables:
rmmod iptable_nat iptable_conntrack
Load Balancer proporciona un conjunto de archivos Java junto con la instalación del producto. La instalación de producto consta de varios paquetes que no es necesario instalar en la misma máquina. Un ejemplo de ello es el paquete de Metric Server, el paquete de administración y el paquete base. Todos estos paquetes de código requieren un conjunto de archivos Java para funcionar, aunque cada uno de los tres paquetes puede instalarse en una máquina distinta. Como tal, cada uno de estos paquetes instala un conjunto de archivos Java. Cuando se instalan en la misma máquina, cada uno de estos conjuntos de archivos será propietario del conjunto de archivos Java. Al instalar el segundo y tercer conjunto de datos Java, recibirá mensajes de aviso indicando que el conjunto de archivos Java también es propiedad de otro conjunto de archivos.
Al instalar código utilizando los métodos de instalación nativos (por ejemplo, installp en AIX), debe ignorar los mensajes de aviso que comunican que el conjunto de archivos Java es propiedad de otro conjunto de archivos.
Durante el proceso de instalación de Load Balancer, también se instala un conjunto de archivos Java. Load Balancer será la única aplicación que utilice la versión Java que se instala con el producto. No debe actualizar esta versión del conjunto de archivos Java sin ayuda especializada. Si hay un problema que requiera una actualización del conjunto de archivos Java, debe notificarlo al servicio de IBM para actualizar al nivel de arreglo oficial el conjunto de archivos Java que se envía con Load Balancer.
En sistemas operativos Microsoft Windows, es posible que las conexiones permanentes se caigan durante una operación de toma de control de alta disponibilidad. Este problema se produce sólo cuando dispone de un servidor compartido que utiliza el método de reenvío MAC.
Cuando se suprime la dirección IP del clúster, ya sea desde la interfaz Ethernet o la interfaz de bucle de retorno, se liberan todas las conexiones de esta dirección IP. Cuando el sistema operativo recibe un paquete en una conexión que se ha liberado, envía una respuesta RST al cliente y termina la conexión.
Si no puede permitir que las conexiones se cierren durante una toma de control de alta disponibilidad, no debería utilizar un servidor con ubicación compartida en sistemas operativos Windows si utiliza el método de reenvío MAC.
El origen de este problema es un límite del instalador de Edge en sistemas operativos Linux de 32 bits para zSeries.
Puede evitar este problema si lleva a cabo la instalación manual del sistema operativo Linux zSeries de 32 bits. Consulte el apartado Instalación para sistemas Linux para obtener más información.
Este problema es el resultado de una limitación del instalador de Edge en sistemas operativos Linux.
Para desinstalar WebSphere Edge Server en un sistema operativo Linux, deberá desinstalar manualmente el producto. Para desinstalar el producto completo, entre el mandato rpm -e 'rpm -qa | grep ibmlb'
Para desinstalar un paquete individual, entre el mandato rpm -e <nombre paquete>. Puede encontrar los nombres de paquete en la sección Instalación para sistemas Linux; recuerde que debe desinstalar los paquetes en el orden contrario en el que fueron instalados.
Este problema puede producirse si otra aplicación utiliza uno de los puertos que CBR utiliza. Para obtener más información, consulte el apartado Comprobación de los números de puerto de CBR.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Esto puede producir problemas si una de las consolas de administración se ejecuta en la misma máquina que un cortafuegos o a través de un cortafuegos. Por ejemplo, cuando se ejecuta Load Balancer en la misma máquina que un cortafuegos y emite mandatos cbrcontrol, podrían aparecer errores como Error: el servidor no responde.
Para impedir este problema, edite el archivo de scripts cbrserver para establecer el puerto utilizado por RMI para el cortafuegos (u otra aplicación). Cambie la línea: LB_RMISERVERPORT=11199 por LB_RMISERVERPORT=suPuerto. Donde suPuerto es otro puerto.
Cuando haya terminado, reinicie cbrserver y abra el tráfico para los puertos: 11099, 10004, 11199 y 11100 o para el puerto seleccionado para la dirección del host desde donde se ejecutará la consola de administración.
Se ha iniciado Caching Proxy y CBR, pero no se equilibra la carga de las peticiones. Este error puede aparecer si inicia Caching Proxy antes de iniciar el ejecutor. Si esto sucede, el archivo de anotaciones cronológicas stderr para Caching Proxy contendrá este mensaje de error: "ndServerInit: Could not attach to executor" (ndServerInit: no se ha podido conectar con el ejecutor). Para evitar que suceda este problema, inicie el ejecutor antes de iniciar Caching Proxy.
En sistemas Solaris, el mandato cbrcontrol executor start devuelve: "Error: el ejecutor no se ha iniciado". Aparece este error si no configura la IPC (Comunicación entre procesos) para el sistema de modo que el tamaño máximo de un segmento de memoria compartida y los ID de semáforo sean mayores que el valor predeterminado del sistema operativo. Para aumentar el tamaño del segmento compartido y de los ID de semáforo, debe editar el archivo /etc/system. Si desea más información sobre cómo configurar este archivo, consulte Modificación de los valores predeterminados para ICP (Inter-process Communication).
Si la regla de URL no funciona, esto puede deberse a un error sintáctico o de configuración. Para corregir este problema compruebe lo siguiente:
En la plataforma Windows cuando utiliza una tarjeta Matrox AGP, puede aparecer un comportamiento inesperado en la GUI de Load Balancer. Cuando pulsa el ratón, podría dañarse un bloque de espacio ligeramente mayor que el puntero del ratón provocando una posible inversión del resaltado o un desplazamiento de imágenes fuera del lugar de la pantalla. Las tarjetas Matrox anteriores no han mostrado este comportamiento. No hay un fix pack conocido cuando se utilizan tarjetas Matrox AGP.
Si utiliza la administración Web remota para configurar Load Balancer, no cambie el tamaño (Minimizar, Maximizar, Restaurar minimizando, etc.) de la ventana del navegador Netscape en la que aparece la GUI de Load Balancer. Dado que Netscape vuelve a cargar una página cada vez que se cambia el tamaño de la ventana del navegador, esto provocará una desconexión del host. Tendrá que volver a conectar con el host cada vez que cambie el tamaño de la ventana. Si realiza administración Web remota en la plataforma Windows, utilice Internet Explorer.
En ventanas de indicador de mandatos del sistema operativo Windows, quizá algunos caracteres nacionales de la familia Latin-1 aparezcan dañados. Por ejemplo, la letra "a" con una tilde podría mostrarse como el símbolo pi. Para corregir esto, debe cambiar las propiedades de font de la ventana de línea de mandatos. Para cambiar el font, realice lo siguiente:
Algunas instalaciones de HP-UX 11i están preconfiguradas para sólo permitir 64 hebras por proceso. No obstante, algunas configuraciones de Load Balancer requieren una cantidad mayor. En los sistemas HP-UX, establezca las hebras por proceso como mínimo en 256. Para aumentar este valor, utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc. Si se espera un uso masivo, puede ser necesario aumentar max_thread_proc por encima de 256.
Para aumentar max_thread_proc, consulte los pasos de la sección Problema: en HP-UX, se produce un error de hebra/sin memoria de Java.
Cuando configura el adaptador en una máquina de Load Balancer, debe asegurarse de que los dos valores siguientes son correctos para que el asesor funcione:
Si desea instrucciones sobre cómo configurar este valor, consulte la página Problema: en los sistemas Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores.
En la plataforma Windows, cuando configura un adaptador con más de una dirección IP, configure la dirección IP que desea afiliar al nombre de host primero del registro.
Puesto que Load Balancer depende de InetAddress.getLocalHost() en muchas instancias (por ejemplo, lbkeys create), varias direcciones IP que tienen un alias con un sólo adaptador podrían provocar problemas. Para impedir este problema, enumere la dirección IP con la que desea que se resuelva la dirección IP primero en el registro.
Consulte la página Problema: en la plataforma Windows, se resuelve la dirección IP con el nombre de host cuando se ha configurado más de una dirección con el adaptador si desea obtener los pasos para configurar el nombre de host primero en el registro.
Este problema puede producirse si otra aplicación utiliza uno de los puertos que Site Selector utiliza. Para obtener más información, consulte el apartado Comprobación de los números de puerto de Site Selector.
Síntoma: el componente Site Selector no utiliza el algoritmo de turno rotativo para peticiones entrantes de clientes Solaris.
Causa posible: los sistemas Solaris ejecutan un "daemon de caché del servicio de nombres. Si este daemon está en ejecución, se contestará la petición subsiguiente del solucionador de esta memoria caché en lugar de consultar Site Selector.
Solución: desactive el daemon del servicio de nombres en la máquina de Solaris.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Esto puede producir problemas si una de las consolas de administración se ejecuta en la misma máquina que un cortafuegos o a través de un cortafuegos. Por ejemplo, cuando se ejecuta Load Balancer en la misma máquina que un cortafuegos y emite mandatos sscontrol, podrían aparecer errores como Error: el servidor no responde.
Para impedir este problema, edite el archivo de scripts ssserver para establecer el puerto utilizado por RMI para el cortafuegos (u otra aplicación). Cambie la línea: LB_RMISERVERPORT=10199 por LB_RMISERVERPORT=suPuerto. Donde suPuerto es otro puerto.
Cuando haya terminado, reinicie ssserver y abra el tráfico para los puertos: 12099, 10004, 12199 y 12100 o para el puerto seleccionado para la dirección del host desde donde se ejecutará la consola de administración.
Site Selector debe ser capaz de participar en un DNS. Todas las máquinas que intervienen en la configuración también deberían participar de este sistema. Los sistemas Windows no siempre requieren que el nombre de host configurado esté en el DNS. Site Selector requiere que su nombre de host se defina en el DNS para que se inicie correctamente.
Verifique que este host se ha definido en el DNS. Edite el archivo ssserver.cmd y elimine la "w" de "javaw". Esto debe proporcionar más información sobre errores.
El servidor de nombres de Site Selector no se enlaza a ninguna dirección en la máquina. Responderá a peticiones destinadas para cualquier dirección IP válida en la máquina. Site Selector confía en el sistema operativo para direccionar la respuesta de nuevo al cliente. Si la máquina de Site Selector tiene varios adaptadores y cualquier número de ellos está conectado a la misma subred, es posible que el O/S enviará la respuesta al cliente desde una dirección distinta de donde la ha recibido. Algunas aplicaciones cliente no aceptarán una respuesta recibida de una dirección que no sea de donde se ha enviado. Como consecuencia, parecerá que la resolución de nombres da un error.
En la plataforma Windows cuando utiliza una tarjeta Matrox AGP, puede aparecer un comportamiento inesperado en la GUI de Load Balancer. Cuando pulsa el ratón, podría dañarse un bloque de espacio ligeramente mayor que el puntero del ratón provocando una posible inversión del resaltado o un desplazamiento de imágenes fuera del lugar de la pantalla. Las tarjetas Matrox anteriores no han mostrado este comportamiento. No hay un fix pack conocido cuando se utilizan tarjetas Matrox AGP.
Si utiliza la administración Web remota para configurar Load Balancer, no cambie el tamaño (Minimizar, Maximizar, Restaurar minimizando, etc.) de la ventana del navegador Netscape en la que aparece la GUI de Load Balancer. Dado que Netscape vuelve a cargar una página cada vez que se cambia el tamaño de la ventana del navegador, esto provocará una desconexión del host. Tendrá que volver a conectar con el host cada vez que cambie el tamaño de la ventana. Si realiza administración Web remota en la plataforma Windows, utilice Internet Explorer.
En ventanas de indicador de mandatos del sistema operativo Windows, quizá algunos caracteres nacionales de la familia Latin-1 aparezcan dañados. Por ejemplo, la letra "a" con una tilde podría mostrarse como el símbolo pi. Para corregir esto, debe cambiar las propiedades de font de la ventana de línea de mandatos. Para cambiar el font, realice lo siguiente:
Algunas instalaciones de HP-UX 11i están preconfiguradas para sólo permitir 64 hebras por proceso. No obstante, algunas configuraciones de Load Balancer requieren una cantidad mayor. En los sistemas HP-UX, establezca las hebras por proceso como mínimo en 256. Para aumentar este valor, utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc. Si se espera un uso masivo, puede ser necesario aumentar max_thread_proc por encima de 256.
Para aumentar max_thread_proc, consulte los pasos de la página Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java.
Cuando configura el adaptador en una máquina de Load Balancer, debe asegurarse de que los dos valores siguientes son correctos para que el asesor funcione:
Si desea instrucciones sobre cómo configurar este valor, consulte la página Problema: en los sistemas Windows, los asesores y los destinos de alcance marcan como inactivos todos los servidores.
Este problema puede producirse si otra aplicación utiliza uno de los puertos utilizados por el ccoserver de Cisco CSS Controller. Para obtener más información, consulte el apartado Comprobación de los números de puerto de Cisco CSS Controller.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Esto puede producir problemas si una de las consolas de administración se ejecuta en la misma máquina que un cortafuegos o a través de un cortafuegos. Por ejemplo, cuando se ejecuta Load Balancer en la misma máquina que un cortafuegos y emite mandatos ccocontrol, podrían aparecer errores como Error: el servidor no responde.
Para impedir este problema, edite el archivo de scripts ccoserver para establecer el puerto utilizado por RMI para el cortafuegos (u otra aplicación). Cambie la línea: CCO_RMISERVERPORT=14199 por CCO_RMISERVERPORT= suPuerto. Donde suPuerto es otro puerto.
Cuando haya terminado, reinicie ccoserver y abra el tráfico para los puertos: 13099, 10004, 13199 y 13100 o para el puerto seleccionado para la dirección del host desde donde se ejecutará la consola de administración.
Este problema puede aparecer si falta una licencia del producto válida. Cuando intenta iniciar ccoserver, recibe este mensaje:
La licencia ha caducado. Póngase en contacto con el representante local de IBM o un distribuidor autorizado de IBM.
Para corregir este problema:
En la plataforma Windows cuando utiliza una tarjeta Matrox AGP, puede aparecer un comportamiento inesperado en la GUI de Load Balancer. Cuando pulsa el ratón, podría dañarse un bloque de espacio ligeramente mayor que el puntero del ratón provocando una posible inversión del resaltado o un desplazamiento de imágenes fuera del lugar de la pantalla. Las tarjetas Matrox anteriores no han mostrado este comportamiento. No hay un fix pack conocido cuando se utilizan tarjetas Matrox AGP.
Cuando añade un consultor, podría experimentar un error de conexión debido a valores de configuración incorrectos. Para corregir este problema:
Para corregir este problema:
Aumente el nivel de anotaciones cronológicas del consultor y vuelva a intentar el mandato. Si vuelve a dar un error, busque en el archivo de anotaciones cronológicas si se ha excedido el tiempo de espera SNMP u otros errores de comunicación SNMP.
Si utiliza la administración Web remota para configurar Load Balancer, no cambie el tamaño (Minimizar, Maximizar, Restaurar minimizando, etc.) de la ventana del navegador Netscape en la que aparece la GUI de Load Balancer. Dado que Netscape vuelve a cargar una página cada vez que se cambia el tamaño de la ventana del navegador, esto provocará una desconexión del host. Tendrá que volver a conectar con el host cada vez que cambie el tamaño de la ventana. Si realiza administración Web remota en la plataforma Windows, utilice Internet Explorer.
En ventanas de indicador de mandatos del sistema operativo Windows, quizá algunos caracteres nacionales de la familia Latin-1 aparezcan dañados. Por ejemplo, la letra "a" con una tilde podría mostrarse como el símbolo pi. Para corregir esto, debe cambiar las propiedades de font de la ventana de línea de mandatos. Para cambiar el font, realice lo siguiente:
Algunas instalaciones de HP-UX 11i están preconfiguradas para sólo permitir 64 hebras por proceso. No obstante, algunas configuraciones de Load Balancer requieren una cantidad mayor. En los sistemas HP-UX, establezca las hebras por proceso como mínimo en 256. Para aumentar este valor, utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc. Si se espera un uso masivo, puede ser necesario aumentar max_thread_proc por encima de 256.
Para aumentar max_thread_proc, consulte los pasos de la página Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java.
Este problema puede producirse si otra aplicación utiliza uno de los puertos utilizados por el nalserver de Nortel Alteon Controller. Para obtener más información, consulte el apartado Comprobación de los números de puerto de Nortel Alteon Controller.
EXCLUDE-MODULE java EXCLUDE-MODULE javaw
Esto puede producir problemas si una de las consolas de administración se ejecuta en la misma máquina que un cortafuegos o a través de un cortafuegos. Por ejemplo, cuando se ejecuta Load Balancer en la misma máquina que un cortafuegos y emite mandatos nalcontrol, podrían aparecer errores como Error: el servidor no responde.
Para impedir este problema, edite el archivo de scripts nalserver para establecer el puerto utilizado por RMI para el cortafuegos (u otra aplicación). Cambie la línea: NAL_RMISERVERPORT=14199 por NAL_RMISERVERPORT= suPuerto. Donde suPuerto es otro puerto.
Cuando haya terminado, reinicie nalserver y abra el tráfico para los puertos: 14099, 10004, 14199 y 14100 o para el puerto seleccionado para la dirección del host desde donde se ejecutará la consola de administración.
Este problema puede aparecer si falta una licencia del producto válida. Cuando intenta iniciar nalserver, recibe este mensaje:
La licencia ha caducado. Póngase en contacto con el representante local de IBM o un distribuidor autorizado de IBM.
Para corregir este problema:
En la plataforma Windows cuando utiliza una tarjeta Matrox AGP, puede aparecer un comportamiento inesperado en la GUI de Load Balancer. Cuando pulsa el ratón, podría dañarse un bloque de espacio ligeramente mayor que el puntero del ratón provocando una posible inversión del resaltado o un desplazamiento de imágenes fuera del lugar de la pantalla. Las tarjetas Matrox anteriores no han mostrado este comportamiento. No hay un fix pack conocido cuando se utilizan tarjetas Matrox AGP.
Si utiliza la administración Web remota para configurar Load Balancer, no cambie el tamaño (Minimizar, Maximizar, Restaurar minimizando, etc.) de la ventana del navegador Netscape en la que aparece la GUI de Load Balancer. Dado que Netscape vuelve a cargar una página cada vez que se cambia el tamaño de la ventana del navegador, esto provocará una desconexión del host. Tendrá que volver a conectar con el host cada vez que cambie el tamaño de la ventana. Si realiza administración Web remota en la plataforma Windows, utilice Internet Explorer.
Cuando añade un consultor, podría experimentar un error de conexión debido a valores de configuración incorrectos. Para corregir este problema:
Para corregir este problema:
Aumente el nivel de anotaciones cronológicas del consultor y vuelva a intentar el mandato. Si vuelve a dar un error, busque en el archivo de anotaciones cronológicas si se ha excedido el tiempo de espera SNMP u otros errores de comunicación SNMP.
En ventanas de indicador de mandatos de la plataforma de sistema operativo Windows, quizá algunos caracteres nacionales de la familia Latin-1 aparezcan dañados. Por ejemplo, la letra "a" con una tilde podría mostrarse como el símbolo pi. Para corregir esto, debe cambiar las propiedades de font de la ventana de línea de mandatos. Para cambiar el font, realice lo siguiente:
Algunas instalaciones de HP-UX 11i están preconfiguradas para sólo permitir 64 hebras por proceso. No obstante, algunas configuraciones de Load Balancer requieren una cantidad mayor. En los sistemas HP-UX, establezca las hebras por proceso como mínimo en 256. Para aumentar este valor, utilice el programa de utilidad "sam" para establecer el parámetro de kernel max_thread_proc. Si se espera un uso masivo, puede ser necesario aumentar max_thread_proc por encima de 256.
Para aumentar max_thread_proc, consulte los pasos de la página Problema: en HP-UX, se produce un error de falta de memoria/hebra de Java.
Debe utilizar el nombre de métrica completo para métricas grabadas por el usuario en Metric Servers que se ejecutan en la plataforma Windows. Por ejemplo, debe especificar usermetric.bat en lugar de usermetric. El nombre usermetric es válido en la línea de mandatos, pero no funcionará cuando se ejecute desde dentro del entorno de ejecución. Si no utiliza el nombre de métrica completo, recibirá una IOException de Metric Server. Establezca la variable LOG_LEVEL en un valor de 3 en el archivo de mandatos metricserver, luego compruebe la salida de anotaciones cronológicas. En este ejemplo, aparece la excepción como:
... java.io.IOException: CreateProcess: usermetric error=2
Puede haber varios motivos por los que Metric Server no transmite la información de carga a Load Balancer. Para determinar la causa, realice estas comprobaciones:
También puede resolver este problema especificando el nombre de host en la propiedad Java java.rmi.server.hostname en el script metricserver.
El archivo de anotaciones cronológicas de Metric Server informa de este mensaje de error después de que se han transferido archivos al servidor.
Este error se anota cuando el archivo de claves no supera la autorización con la clave emparejada debido a que se ha dañado la pareja. Para corregir este problema intente lo siguiente:
Cuando ejecuta Metric Server bajo una gran presión en una plataforma AIX multiprocesador (4.3.3, de 32 bits 5.1 o de 64 bits 5.1), la salida del mandato ps -vg podría dañarse. Por ejemplo:
55742 - A 88:19 42 18014398509449680 6396 32768 22 36 2.8 1.0 java -Xms
El campo SIZE y/o RSS del mandato ps podría mostrar una cantidad excesiva de memoria utilizada.
Este es un problema del kernel AIX conocido. Apar IY33804 corregirá este problema. Obtenga el fix pack del soporte de AIX en http://techsupport.services.ibm.com/server/fixes o póngase en contacto con el representante de soporte de AIX local.
En una configuración de Load Balancer de dos niveles, si se está equilibrando la carga de Site Selector (primer nivel) entre un par de asociados de alta disponibilidad de Dispatcher (segundo nivel), hay pasos que debe completar para configurar el componente Metric Server. Debe configurar Metric Server para que esté a la escucha en una nueva dirección IP que es específicamente para uso de Metric Server. En las dos máquinas de Dispatcher de alta disponibilidad, Metric Server está activo sólo en el Dispatcher activo.
Para configurar correctamente esta configuración, complete estos pasos:
Por ejemplo:
ifconfig en0 delete 9.27.23.61 ifconfig lo0 alias 9.27.23.61 netmask 255.255.255.0 route add 9.27.23.61 127.0.0.1 metricserver stop # Está inactivo durante un número máximo de 60 segundos o hasta que se # detiene metricserver let loopcount=0 while [[ "$loopcount" -lt "60" && 'ps -ef | grep AgentStop| grep -c -v gr ep' -eq "1"]] do sleep 1 let loopcount=$loopcount+1 done route delete 9.27.23.61
Por ejemplo:
call netsh interface ip delete address "Conexión de área local" addr=9.27.23.61 call netsh interface ip add address "Conexión de área local 2" addr=9.27.2.3.61 mask = 255.255.255.0 sleep 3 metricserver stop
Cuando se ejecutan los scripts metricserver, cpuload y memload en máquinas Solaris de varias CPU pueden producir mensajes de consola no deseados. Este comportamiento se debe al uso del mandato de sistema VMSTAT para recopilar estadísticas de la CPU y de memoria del kernel. Algunos mensajes que VMSTAT devuelve indican que el estado del kernel ha cambiado. Los scripts no pueden gestionar estos mensajes, lo que provoca mensajes de consola innecesarios procedentes del shell.
Ejemplos de estos mensajes de consola son:
/opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=: syntax error /opt/ibm/edge/lb/ms/script/memload[31]: LOAD=4*100/0: divide by zero /opt/ibm/edge/lb/ms/script/memload[29]: TOTAL=659664+: more tokens expected
Estos mensajes se pueden ignorar.
Este problema puede deberse a la pérdida de integridad de los archivos de claves durante la transferencia al cliente.
Si utiliza FTP para transferir los archivos de claves desde la máquina de Load Balancer al servidor de programa de fondo, asegúrese de que está utilizando la modalidad binaria cuando utiliza los mandatos put o get para transferir archivos de claves al o desde el servidor FTP.
Esta parte proporciona información de referencia de mandatos para todos los componentes de Load Balancer. Contiene los capítulos siguientes:
El diagrama de sintaxis muestra cómo especificar un mandato para que el sistema operativo pueda interpretar correctamente lo que se escribe. Lea el diagrama de sintaxis de izquierda a derecha y de arriba a abajo, siguiendo la línea horizontal (la ruta principal).
En los diagramas de sintaxis se utilizan los símbolos siguientes:
Debe incluir todos los símbolos de puntuación, como dos puntos, comillas y signos menos que se muestran en el diagrama de sintaxis.
En los diagramas de sintaxis se utilizan los siguientes tipos de parámetros.
Los parámetros se clasifican como palabras clave o variables. Las palabras clave se muestran en letras minúsculas y se pueden especificar en minúscula. Por ejemplo, un nombre de mandato es una palabra clave. Las variables van en cursiva y representan nombres o valores que se suministran.
En el ejemplo siguiente, el mandato user es una palabra clave. La variable necesaria es id_usuario y la variable opcional es contraseña. Sustituya las variables por sus propios valores.
>>-user--id_usuario--+----------+--------------------------------->< '-contraseña-'
Palabras clave necesarias: las palabras clave y variables necesarias aparecen en la línea de ruta principal.
>>-palabra_clave_necesaria--------------------------------------------><
Debe incluir el código de las palabras clave y los valores necesarios.
Seleccione un elemento necesario de la pila: si hay más de una palabra clave o variable mutuamente exclusivas entre las que elegir, se apilarán verticalmente por orden alfanumérico.
>>-+-parámetro_necesario_1-+------------------------------------>< '-parámetro_necesario_2-'
Valores opcionales: las palabras clave y variables opcionales aparecen debajo de la línea de ruta principal.
>>-+---------+------------------------------------------------->< '-palabra_clave-'
Puede determinar no incluir en el código palabras clave y variables opcionales.
Seleccione una palabra clave opcional de una pila: si hay más de una palabra clave o variable opcional mutuamente exclusivas entre las que elegir, se apilarán verticalmente por orden alfanumérico debajo de la línea de ruta principal.
>>-+-------------+--------------------------------------------->< +-parámetro_1-+ '-parámetro_2-'
Variables: una palabra toda en cursiva es una variable . Donde aparece una variable en la sintaxis, debe sustituirla por uno de sus nombres o valores permitidos, como se define en el texto.
>>-variable----------------------------------------------------><
Caracteres no alfanuméricos: si un diagrama muestra un carácter que no es alfanumérico (como dos puntos, comillas o signos menos), debe codificar el carácter como parte de la sintaxis. En este ejemplo, debe codificar clúster:puerto.
>>-clúster:puerto------------------------------------------------><
En este capítulo se describe cómo utilizar los mandatos dscontrol de Dispatcher. También es una referencia de mandatos de CBR.
En las versiones anteriores, cuando el producto se denominaba Network Dispatcher, el nombre del mandato de control de Dispatcher era ndcontrol. El nombre del mandato de control de Dispatcher ahora es dscontrol. Asegúrese de actualizar todos los archivos de script anteriores de modo que utilicen dscontrol (no ndcontrol) para configurar Dispatcher.
CBR utiliza un subconjunto de los mandatos de Dispatcher que se enumeran en esta referencia de mandatos. Al utilizar estos diagramas de sintaxis para CBR, sustituya cbrcontrol por dscontrol. Para obtener más información, consulte el apartado Diferencias de configuración entre CBR y Dispatcher.
La lista siguiente contiene los mandatos que se describen en este capítulo:
Puede escribir una versión minimizada de los parámetros del mandato dscontrol. Sólo es necesario especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir dscontrol he f en lugar de dscontrol help file.
Para iniciar la interfaz de línea de mandatos: emita dscontrol para recibir un indicador de mandatos dscontrol.
Para finalizar la interfaz de línea de mandatos, emita exit o quit.
Los valores de los parámetros de mandatos deben especificarse en caracteres del idioma inglés. Las únicas excepciones son los nombres de host (que se utilizan en los mandatos cluster, server y highavailability) y nombres de archivo (que se utilizan en los mandatos de archivo).
La interfaz de línea de mandatos de CBR es un subconjunto de la interfaz de línea de mandatos de Dispatcher. Para CBR, indique el mandato cbrcontrol en lugar de dscontrol para configurar el componente.
A continuación se listan algunos de los mandatos que se omiten en CBR.
>>-dscontrol--advisor--+-connecttimeout--nombre--+-puerto---------+--tiempo_espera_segundos-+->< | '-clúster:puerto-' | +-interval--nombre--+-puerto---------+--segundos--------------+ | '-clúster:puerto-' | +-list---------------------------------------------------+ +-loglevel--nombre--+-puerto---------+--nivel----------------+ | '-clúster:puerto-' | +-logsize--nombre--+-puerto---------+--+-unlimited---------+-+ | '-clúster:puerto-' '-número de registros-' | +-receivetimeout--nombre--+-puerto---------+--tiempo_espera_segundos-+ | '-clúster:puerto-' | +-report--nombre--+-puerto---------+-------------------------+ | '-clúster:puerto-' | +-retries--nombre--+-puerto---------+--num_reintentos------------+ | '-clúster:puerto-' | +-start--nombre--+-puerto---------+--+----------+------------+ | '-clúster:puerto-' '-archivo_registro-' | +-status--nombre--+-puerto---------+-------------------------+ | '-clúster:puerto-' | +-stop--nombre--+-puerto---------+---------------------------+ | '-clúster:puerto-' | +-timeout--nombre--+-puerto---------+--+-unlimited-+---------+ | '-clúster:puerto-' '-segundos---' | '-version--nombre--+-puerto---------+------------------------' '-clúster:puerto-'
Consulte el apartado Lista de asesores para obtener información sobre los asesores que proporciona Load Balancer.
Los nombres de asesores personalizados están en formato xxxx, donde ADV_xxxx es el nombre de la clase que implementa el asesor personalizado. Consulte el apartado Crear asesores personalizados (personalizables) para obtener más información.
El clúster es la dirección en formato de dirección IP o un nombre simbólico. El puerto es el número del puerto que el asesor está supervisando.
Nombre del asesor | Protocolo | Puerto |
---|---|---|
cachingproxy | HTTP (mediante Caching Proxy) | 80 |
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
self | private | 12345 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
ssl2http | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10.007 |
El archivo predeterminado es puerto_nombre_asesor.log, por ejemplo, http_80.log. Para cambiar el directorio en el que se guardan los archivos de anotaciones cronológicas, consulte el apartado Cambio de las vías de acceso del archivo de anotaciones cronológicas. Los archivos de anotaciones cronológicas predeterminados para los asesores específicos del clúster (o sitio) se crean con la dirección del clúster, por ejemplo, http_127.40.50.1_80.log.
Ejemplos
dscontrol advisor start http 127.40.50.1:80
dscontrol advisor start http 88
dscontrol advisor stop http 127.40.50.1:80
dscontrol advisor connecttimeout http 80 30
dscontrol advisor connecttimeout http 127.40.50.1:80 20
dscontrol advisor interval ftp 21 6
dscontrol advisor listEste mandato genera una salida parecida a la siguiente:
--------------------------------------- | ASESOR | CLÚSTER:PUERTO | TPO ESPERA| --------------------------------------- | http |127.40.50.1:80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
dscontrol advisor loglevel http 80 0
dscontrol advisor logsize ftp 21 5000
dscontrol advisor receivetimeout http 80 60
dscontrol advisor report ftp 21Este mandato genera una salida parecida a la siguiente:
Informe del asesor: --------------- Nombre del asesor ........ Ftp Número de puerto ......... 21 Dirección del clúster .... 9.67.131.18 Dirección del servidor ... 9.67.129.230 Carga .................... 8 Dirección del clúster .... 9.67.131.18 Dirección del servidor ... 9.67.131.215 Carga .................... -1
dscontrol advisor status http 80Este mandato genera una salida parecida a la siguiente:
Estado del asesor: --------------- Intervalo (segundos) .......... 7 Tiempo de espera (segundos) ... Unlimited Tiempo espera conexión (seg) .. 21 Tiempo espera recepción (seg).. 21 Nombre anotaciones asesor ..... Http_80.log Nivel anotación cronológica ... 1 Tam. máx. arch. anot. (bytes) . Unlimited Número de reintentos .......... 0
dscontrol advisor timeout ftp 21 5
dscontrol advisor version ssl 443Este mandato genera una salida parecida a la siguiente:
Versión: 04.00.00.00 - 07/12/2001-10:09:56-EDT
>>-dscontrol--binlog--+-start----------------------+----------->< +-stop-----------------------+ +-set--+-retention--horas--+-+ | '-interval--segundos-' | '-status---------------------'
>>-dscontrol--cluster--+-add--clúster+c2+...--+----------------------------------------+-+->< | +-address--dirección-----------------------+ | | +-proportions--activo--nuevo--puerto--sistema-+ | | +-maxports--tamaño-------------------------+ | | +-maxservers--tamaño-----------------------+ | | +-stickytime--tiempo-----------------------+ | | +-weightbound--peso--------------------+ | | +-porttype--tipo-------------------------+ | | +-primaryhost--dirección-------------------+ | | +-staletimeout--tiempo_espera_inactividad-----------+ | | '-sharedbandwidth--tamaño------------------' | +-set--clúster+c2+...--+-proportions--activo--nuevo--puerto--sistema-+-+ | +-maxports--tamaño-------------------------+ | | +-maxservers--tamaño-----------------------+ | | +-stickytime--tiempo-----------------------+ | | +-weightbound--peso--------------------+ | | +-porttype--tipo-------------------------+ | | +-primaryhost--dirección-------------------+ | | +-staletimeout--tiempo_espera_inactividad-----------+ | | '-sharedbandwidth--tamaño------------------' | +-remove--clúster-------------------------------------------------+ +-report--clúster-------------------------------------------------+ '-status--clúster-------------------------------------------------'
Con la excepción del mandato dscontrol cluster add, puede utilizar dos puntos (:) como carácter comodín. Por ejemplo, al emitir el siguiente mandato, dscontrol cluster set : weightbound 80, se establecerá una ponderación de 80 en todos los clústeres.
Si cambia el valor de primaryhost de un clúster una vez que se han iniciado las máquinas primaria y de reserva y están ejecutando alta disponibilidad mutua, también debe forzar al nuevo host primario que tome control. Asimismo, es necesario actualizar los scripts y desconfigurar y configurar manualmente el clúster correctamente. Consulte el apartado Alta disponibilidad mutua para obtener más información.
Ejemplos
dscontrol cluster add 130.40.52.153
dscontrol cluster remove 130.40.52.153
dscontrol cluster set 9.6.54.12 proportions 60 35 5 0
dscontrol cluster add 0.0.0.0
dscontrol cluster set 9.6.54.12 primaryhost 9.65.70.19
dscontrol cluster status 9.67.131.167Este mandato genera una salida parecida a la siguiente:
Estado del clúster: ---------------- Clúster .................................... 9.67.131.167 Dirección .................................. 9.67.131.167 Número de puertos de destino ............... 3 Tiempo permanencia mem. predeterminado ..... 0 Tiempo de espera predeterminado ............ 30 Ponderación predeterminada para puerto ..... 20 Máximo número de puertos ................... 8 Protocolo de puerto predeterminado ......... tcp/udp Número máximo de servidores predeterminado . 32 Proporción asignada a conexiones activas.... 0,5 Proporción asignada a conexiones nuevas .... 0,5 Proporción asignada específ. para puerto.... 0 Proporción asignada a métrica sistema ...... 0 Ancho de banda compartido (KBytes) ......... 0 Dirección host primario .................... 9.67.131.167
>>-dscontrol--executor--+-report-----------------------------------------------------------+->< +-set--+-nfa--dirección IP------------+------------------------------+ | +-maxclusters--tamaño----------+ | | +-maxports--tamaño-------------+ | | +-fintimeout--tiempo_espera_fin+ | | +-hatimeout--tiempo------------+ | | +-hasynctimeout--tiempo--------+ | | +-maxservers--tamaño-----------+ | | +-mss--tamaño------------------+ | | +-staletimeout--tiempo_espera_inact+ | | +-stickytime--tiempo-----------+ | | +-clientgateway--dirección-----+ | | +-weightbound--peso------------+ | | +-porttype--tipo---------------+ | | +-wideportnumber--puerto-------+ | | '-sharedbandwidth--tamaño------+ | +-configure--dirección_interfaz+i2+...+----------------------------+-+ | +-nombre_interfaz--máscara_red| +-unconfigure--dirección_interfaz------------------------------------+ +-start-------------------------------------------------------------+ +-status------------------------------------------------------------+ '-stop--------------------------------------------------------------'
El temporizador se utiliza para asegurarse de que las máquinas primaria y de reserva intentan sincronizarse. Sin embargo, si existen demasiadas conexiones y la máquina activa sigue gestionando una carga significativa del tráfico entrante, es posible que la sincronización no se haya completado antes de que caduque el temporizador. Como consecuencia, Load Balancer intentará volver a sincronizarse constantemente y las dos máquinas nunca se sincronizan. Si se da esta situación, establezca hasynctimeout en un valor más alto que el valor predeterminado para dar a las dos máquinas suficiente tiempo para intercambiar información sobre las conexiones existentes. Para establecer este temporizador, el mandato hasynctimeout se debe emitir después del mandato dscontrol executor start pero antes de emitir los mandatos de alta disponibilidad (dscontrol highavailability).
Ejemplos
dscontrol executor status Estado del ejecutor: ---------------- Dirección de no reenvío ................ 9.67.131.151 Dirección pasarela de cliente .......... 0.0.0.0 Tiempo de espera Fin ................... 60 Número puerto red área amplia .......... 0 Ancho de banda compartido (Kbytes) ..... 0 Núm. máx. omisión puertos por clúster... 8 Número máximo de clústeres ............. 100 Núm. máx. omisión servid. por puerto.... 32 Tiempo de espera sin actividad ......... 300 Tiempo permanencia mem. predeterminado.. 0 Ponderación predeterminada ............. 20 Tipo de puerto predeterminado .......... tcp/udp
dscontrol executor set nfa 130.40.52.167
dscontrol executor set maxclusters 4096
dscontrol executor start
dscontrol executor stop
>>-dscontrol--file--+-delete--archivo[.ext]----------+------------>< +-appendload--archivo[.ext]------+ +-report-------------------------+ +-save--archivo[.ext]--+-------+-+ | '-force-' | '-newload--archivo[.ext]---------'
La extensión de archivo (.ext) puede ser cualquiera y puede omitirse.
Ejemplos
dscontrol file delete file3 Se ha suprimido el archivo (file3).
dscontrol file newload file1.sv El archivo (file1.sv) se ha cargado en Dispatcher.
dscontrol file appendload file2.sv El archivo (file2.sv) se ha añadido a la configuración actual y se ha cargado.
dscontrol file report INFORME SOBRE EL ARCHIVO: file1.save file2.sv file3
dscontrol file save file3 La configuración se ha guardado en el archivo (file3).
>>-dscontrol--help--+-advisor----------+----------------------->< +-binlog-----------+ +-cluster----------+ +-executor---------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-host-------------+ +-logstatus--------+ +-manager----------+ +-metric-----------+ +-port-------------+ +-rule-------------+ +-server-----------+ +-set--------------+ +-status-----------+ '-subagent---------'
Ejemplos
dscontrol helpEste mandato genera una salida parecida a la siguiente:
ARGUMENTOS DEL MANDATO DE AYUDA: --------------------------------- Uso: help <opción de ayuda> Ejemplo: help cluster help - imprime el texto completo de la ayuda advisor - ayuda para el mandato advisor cluster - ayuda para el mandato cluster executor - ayuda para el mandato executor file - ayuda para el mandato file host - ayuda para el mandato host binlog - ayuda para el mandato binary log manager - ayuda para el mandato manager metric - ayuda para el mandato metric port - ayuda para el mandato port rule - ayuda para el mandato rule server - ayuda para el mandato server set - ayuda para el mandato set status - ayuda para el mandato status logstatus - ayuda para el mandato logstatus del servidor subagent - ayuda para el mandato subagent highavailability - ayuda para el mandato highavailabilityObserve que los parámetros dentro de <> son variables.
fintimeout <dirección clúster>|all <tiempo> -Cambiar tiempo de espera FIN (Usar 'all' para cambiar todos los clústeres)
>>-dscontrol--highavailability--+-status--------------------------------------+->< +-backup--+-add--+-primary-+--+-auto---+--p-+-+ | | +-backup--+ '-manual-' | | | | '-both----' | | | '-delete--------------------------' | +-reach--+-add----+--dirección--máscara------------+ | '-delete-' | +-heartbeat--+-add--dirección_org--dirección_dst-+--+ | '-delete--dirección-------------' | '-takeover--+---------+-----------------------' '-dirección-'
Además, la palabra clave status devuelve información sobre diversos subestados:
Configuración de alta disponibilidad mutua (el rol de cada máquina Dispatcher es ambos, both):
Notas:
Ejemplos
dscontrol highavailability status
Salida:
Estado de alta disponibilidad: ------------------------- Rol ......................... primario Estrategia de recuperación .. manual Estado ...................... Activo Subestado ................... Sincronizado Host primario................ 9.67.131.151 Puerto ...................... 12345 Destino preferente .......... 9.67.134.223 Estado de pulso: ----------------- Recuento ...................... 1 Origen/destino ................ 9.67.131.151/9.67.134.223 Estado de accesibilidad: -------------------- Recuento ............. 1 Dirección ............ 9.67.131.1 accesible
dscontrol highavailability backup add primary auto 80
dscontrol highavailability reach add 9.67.125.18
Primary - highavailability heartbeat add 9.67.111.3 9.67.186.8 Backup - highavailability heartbeat add 9.67.186.8 9.67.111.3
dscontrol highavailability takeover
>>-dscontrol--host:--sistppal_remoto-------------------------------><
dscontrol host:sist_princ_remoto
Después de emitir el mandato en el indicador de mandatos, escriba cualquier mandato dscontrol válido que desee emitir en la máquina Load Balancer remota.
>>-dscontrol--logstatus----------------------------------------><
Ejemplos
Mostrar el estado de las anotaciones cronológicas:
dscontrol logstatus
Este mandato genera una salida parecida a la siguiente:
Estado de anotaciones de Dispatcher ------------------------------ Archivo de anotaciones ..... C:\ARCHIV~1\IBM\edge\lb\servers\logs\dispatcher \server.log Nivel anotación cronológica. 1 Tam. máx. archivo anotac. .. 1048576
>>-dscontrol--manager--+-interval--segundos----------------------+->< +-loglevel--nivel------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--nivel--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-quiesce--servidor--+-----+---------------+ | '-now-' | +-reach set--+-interval--segundos------+--+ | +-loglevel--nivel--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-refresh--renovar ciclo-----------------+ +-report--+----------------+-------------+ | '-clúster+c2+...-' | +-restart--mensaje-----------------------+ +-sensitivity--peso----------------------+ +-smoothing--índice de suavizado---------+ +-start--+-----------------------+-------+ | '-archivo_anotaciones--puerto_métrica-' | +-status---------------------------------+ +-stop-----------------------------------+ +-unquiesce--servidor--------------------+ '-version--------------------------------'
O, si ha utilizado la partición del servidor, utilice el nombre exclusivo del servidor lógico. Consulte el apartado Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP) para obtener más información.
El archivo predeterminado se instala en el directorio logs. Consulte el Apéndice C. Archivos de configuración de ejemplo. Para cambiar el directorio en el que se guardan los archivos de anotaciones cronológicas, consulte el apartado Cambio de las vías de acceso del archivo de anotaciones cronológicas.
Ejemplos
dscontrol manager interval 5
dscontrol manager loglevel 0
dscontrol manager logsize 1000000
dscontrol manager quiesce 130.40.52.153
dscontrol manager refresh 3
dscontrol manager reportEste mandato genera una salida parecida a la siguiente:
-------------------------------------------------------------------- | SERVIDOR | DIRECCIÓN IP | ESTADO | -------------------------------------------------------------------- | mach14.dmz.com | 10.6.21.14 | ACTIVO | | mach15.dmz.com | 10.6.21.15 | ACTIVO | -------------------------------------------------------------------- ----------------------------- | LEYENDA INFORMES GESTOR | ----------------------------- | ACTV | Conexiones activas | | NEWC | Conexiones nuevas | | SYS | Métrica del sistema| | NOW | Peso actual | | NEW | Nuevo peso | | WT | Peso | | CONN | Conexiones | ----------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | PESO | ACTV | NUEVAC | PUERTO | SIS | | PUERTO: 21 |NOW NUE| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | -1 | 0 | | mach15.dmz.com | 10 10 | 0 | 0 | -1 | 0 | ------------------------------------------------------------------- ------------------------------------------------------------------- | www.dmz.com | | | | | | | 10.6.21.100 | PESO | ACTV | NUEVAC | PUERTO | SIS | | PUERTO: 80 |NOW NUE| 49% | 50% | 1% | 0% | ------------------------------------------------------------------- | mach14.dmz.com | 10 10 | 0 | 0 | 23 | 0 | | mach15.dmz.com | 9 9 | 0 | 0 | 30 | 0 | ------------------------------------------------------------------- --------------------------------------------------- | ASESOR | CLÚSTER:PUERTO | TPO ESPERA| --------------------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------------------
dscontrol manager restart Reiniciando el gestor para actualizar códigoEste mandato genera una salida parecida a la siguiente:
320-14:04:54 Reiniciando el gestor para actualizar código
dscontrol manager sensitivity 10
dscontrol manager smoothing 2.0
dscontrol manager start ndmgr.log
dscontrol manager statusEste mandato genera una salida parecida al siguiente ejemplo:
Estado del gestor: =============== Puerto de métrica ............................ 10004 Archivo anotaciones del gestor ............... manager.log Nivel anotaciones del gestor ................. 1 Tamaño máximo anotaciones de gestor (bytes) .. unlimited Nivel de sensibilidad ........................ 0,05 Índice de suavizado .......................... 1,5 Intervalo de actualización (segundos) ........ 2 Ciclo de renovación de pesos ................. 2 Nivel de anotaciones asesor de alcance ....... 1 Tamaño máximo anot. asesor alcance (bytes) ... unlimited Intervalo intentos acceso a destino (seg.) ... 7 Nombre archivo anotaciones supervisor métrica. MetricMonitor.log Nivel anotac. cronológicas supervisor métrica 1 Tam. máx. arch. anotac. cronológicas supervisor métrica 1048576
dscontrol manager stop
dscontrol manager quiesce 130.40.52.153 now
dscontrol manager quiesce 130.40.52.153
dscontrol manager unquiesce 130.40.52.153
dscontrol manager version
>>-dscontrol--metric--+-add--clúster+c2+...+cN:métrica+métrica1+...+métricaN--------------+->< +-remove--clúster+c2+...+cN:métrica+métrica1+...+métricaN-----------+ +-proportions--clúster+c2+...+cN proporción1 prop2 prop3...propN-+ '-status--clúster+c2+...+cN:métrica+métrica1+...+métricaN-----------'
Ejemplos
dscontrol metric add sitio1:métrica1
dscontrol metric proportions sitio1 0 100
dscontrol metric status sitio1:métrica1Este mandato genera una salida parecida a la siguiente:
Estado de métrica: ------------ Clúster ....................... 10.10.10.20 Nombre de métrica ............. métrica1 Proporción de métrica ......... 50 Servidor .................. plm3 Datos métrica ............. -1
>>-dscontrol--port--+-add--clúster:puerto--+----------------------+-+->< | +-crossport--otro_puerto-+ | | +-maxservers--tamaño-----+ | | +-stickymask--valor------+ | | +-stickytime--tiempo-----+ | | +-method--tipo-----------+ | | +-staletimeout--valor----+ | | +-weightbound--peso------+ | | +-porttype--tipo---------+ | | +-protocol--tipo---------+ | | '-reset--valor-----------' | +-set--clúster:puerto--+-crossport--otro_puerto-+-+ | +-maxservers--tamaño-----+ | | +-stickymask--valor------+ | | +-stickytime--tiempo-----+ | | +-staletimeout--valor----+ | | +-weightbound--peso------+ | | +-porttype--tipo---------+ | | +-maxhalfopen--valor-----+ | | '-reset--valor-----------' | +-remove--clúster:puerto------------------------+ +-report--clúster:puerto------------------------+ +-status--clúster:puerto------------------------+ '-halfopenaddressreport--clúster:puerto---------'
Para eliminar la característica crossport, establezca el valor de crossport de nuevo en el número de su propio puerto. Para obtener más información sobre la característica de afinidad entre puertos, consulte el apartado Afinidad entre puertos.
para el componente Dispatcher:
Para el componente CBR: si establece port stickytime en un valor distinto de cero, el tipo de afinidad en la regla debe ser none (valor predeterminado). La afinidad basada en reglas (cookie pasivo, URI, cookie activo) no puede coexistir cuando stickytime se establece en el puerto.
Notas:
Un valor positivo indica que se realiza una comprobación para determinar si las conexiones medio abiertas actuales exceden el umbral. Si el valor actual excede el umbral, se realiza una llamada a un script de alerta. Consulte el apartado Detección de ataques para rechazo de servicio (DoS) para obtener más información.
Ejemplos
dscontrol port add 130.40.52.153:80+23
dscontrol port set 130.40.52.153:0
dscontrol port set 130.40.52.153:80 weightbound 10
dscontrol port set 130.40.52.153:80+23 stickytime 60
dscontrol port set 130.40.52.153:80 crossport 23
dscontrol port remove 130.40.52.153:23
dscontrol port status 9.67.131.153:80Este mandato genera una salida parecida a la siguiente:
Estado del puerto: ------------ Número de puerto ............... 80 Clúster ........................ 9.67.131.153 Tiempo de espera sin actividad . 300 Ponderación .................... 20 Número máximo de servidores .... 32 Tiempo de permanencia en memoria 0 Tipo de puerto ................. tcp/udp Afinidad entre puertos ......... 80 Bits máscara permanen. memoria . 32 Máx conexiones medio abiertas .. 0 Enviar restauraciones TCP ...... no
dscontrol port report 9.62.130.157:80Este mandato genera una salida parecida a la siguiente:
Informe del puerto: ------------ Dirección de clúster ........... 9.62.130.157 Número de puerto ............... 80 Número de servidores ........... 5 Peso máximo del servidor ....... 10 Total de conexiones activas .... 55 Conexiones por segundo ......... 12 KBytes por segundo ............. 298 Número de medio abiertas ...... 0 Restaur. TCP enviadas .......... 0 Método de reenvío .............. Reenvío basado en dirección MAC
dscontrol port halfopenaddressreport 9.67.127.121:80Este mandato genera una salida parecida a la siguiente:
El informe de conexiones parciales se ha creado con éxito ------------ Informe direcciones medio abiertas para clúster:puerto = 9.67.127.121:80 Total registrado de direcciones con conexiones medio abiertas ... 0 Número total registrado de conexiones medio abiertas ............ 0 Número mayor registrado de conexiones medio abiertas ............ 0 Número medio registrado de conexiones medio abiertas ............ 0 Tiempo medio registrado (segs) de conexiones medio abiertas ..... 0 Total registrado de conexiones medio abiertas ................... 0
>>-dscontrol--rule--+-add--clúster:puerto:regla--type--tipo--| opts |-+->< +-dropserver--clúster:puerto:regla--servidor--------+ +-remove--clúster:puerto:regla--------------------+ +-report--clúster:puerto:regla--------------------+ +-set--clúster:puerto:regla--| opts |-------------+ +-status--clúster:puerto:regla--------------------+ '-useserver--clúster:puerto:regla--servidor+s2+...--' opts: |--+---------------------------------+--------------------------| +-beginrange--bajo--endrange--alto-+ +-priority--nivel-----------------+ +-pattern--patrón----------------+ +-tos--valor----------------------+ +-stickytime--tiempo----------------+ +-affinity--tipo_afinidad---------+ +-cookiename--valor---------------+ +-evaluate--nivel-----------------+ '-sharelevel--nivel---------------'
Consulte el apartado Afinidad de cookies activos para obtener más información.
El tipo de afinidad "activecookie" habilita el equilibrio de carga del tráfico Web con afinidad para el mismo servidor basándose en los cookies generados por Load Balancer.
El tipo de afinidad "passivecookie" habilita el equilibrio de carga del tráfico Web con afinidad para el mismo servidor basándose en los cookies que se identifican a sí mismos generados por los servidores. Debe utilizar el parámetro cookiename junto con la afinidad de cookie pasivo.
El tipo de afinidad "URI" habilita el equilibrio de carga en el tráfico Web para los servidores Caching Proxy de forma que aumente de manera eficaz el tamaño de la memoria caché.
Consulte los apartados Afinidad de cookies activos, Afinidad de cookies pasivos y Afinidad de URI para obtener más información.
Consulte el apartado Afinidad de cookies pasivos para obtener más información.
En la regla de tipo conexión, también puede especificar una opción de evaluación: upserversonrule. Si especifica upserversonrule, puede asegurarse de que no se cargará en exceso los servidores restantes incluidos en la regla, si algunos de los servidores incluidos en el conjunto están inactivos.
O, si ha utilizado la partición del servidor, utilice el nombre exclusivo del servidor lógico. Consulte el apartado Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP) para obtener más información.
Ejemplos
dscontrol rule add 9.37.67.100:80:trule type true priority 100
dscontrol rule add 9.37.131.153:80:ni type ip b 9.0.0.0 e 9.255.255.255
dscontrol rule add cluster1:80:timerule type time beginrange 11 endrange 14 dscontrol rule useserver cluster1:80:timerule server05
dscontrol rule add 9.67.131.153:80:tosrule type service tos 0xx1001x
dscontrol rule add 9.67.131.153:80:rbwrule type reservedbandwidth beginrange 0 endrange 100 evaluate rule
dscontrol cluster set 9.67.131.153 sharedbandwidth 200 dscontrol rule add 9.67.131.153:80:shbwrule type sharedbandwidth sharelevel cluster
>>-dscontrol--server--+-add--clúster:puerto:servidor--+-------------------------+-+->< | +-address--dirección--------+ | | +-collocated--valor-------+ | | +-sticky--valor-----------+ | | +-weight--valor-----------+ | | +-fixedweight--valor------+ | | +-cookievalue--valor------+ | | +-mapport--val_puert------+ | | +-protocol--valor---------+ | | +-router--dirc------------+ | | +-returnaddress--dirc-----+ | | +-advisorrequest--serie---+ | | '-advisorresponse--serie--' | +-set--clúster:puerto:servidor--+-collocated--valor-------+-+ | +-sticky--valor-----------+ | | +-weight--valor-----------+ | | +-fixedweight--valor------+ | | +-cookievalue--valor------+ | | +-protocol--valor---------+ | | +-router--dirc------------+ | | +-advisorrequest--serie---+ | | '-advisorresponse--serie--' | +-down--clúster:puerto:servidor-----------------------------+ +-remove--clúster:puerto:servidor---------------------------+ +-report--clúster:puerto:servidor---------------------------+ +-up--clúster:puerto:servidor-------------------------------+ '-status--clúster:puerto:servidor---------------------------'
O, si utiliza un nombre exclusivo que no se resuelva en una dirección IP, debe proporcionar el parámetro address del servidor en el mandato dscontrol server add. Consulte el apartado Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP) para obtener más información.
Cuando se utiliza un mandato server down para poner un servidor fuera de línea, si el valor de tiempo de permanencia en memoria (stickytime) no es cero para dicho servidor, ese servidor seguirá atendiendo los clientes existentes hasta que caduque el tiempo de permanencia en memoria. El servidor pasará a estar inactivo una vez que caduque el valor de tiempo de permanencia en memoria (stickytime).
Ejemplos
dscontrol server add 130.40.52.153:80:27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 sticky no
dscontrol server down 130.40.52.153:80:27.65.89.42
dscontrol server remove ::27.65.89.42
dscontrol server set 130.40.52.153:80:27.65.89.42 collocated yes
dscontrol server set 130.40.52.153:80:27.65.89.42 weight 10
dscontrol server up 130.40.52.153:80:27.65.89.42
dscontrol server add 130.40.52.153:80:130.60.70.1 router 130.140.150.0
dscontrol server set 130.40.52.153:80:27.65.89.42 advisorrequest "\"HEAD / HTTP/1.0\""
dscontrol server status 9.67.131.167:80:9.67.143.154Este mandato genera una salida parecida a la siguiente:
Estado de servidor: -------------- Servidor ....................... 9.67.143.154 Número de puerto ............... 80 Clúster ........................ 9.67.131.167 Dirección del clúster .......... 9.67.131.167 Inmovilizado ................... N Servidor activo ................ Y Peso ........................... 10 Peso fijo ...................... N Permanencia memoria de regla ... Y Servidor remoto ................ N Dirección direccionador de red . 0.0.0.0 Ubicación compartida ........... N Petición del asesor ............ HEAD / HTTP/1.0 Respuesta del asesor ........... Valor del cookie ............... n/d ID de clon ..................... n/a
>>-dscontrol--set--+-loglevel--nivel--------+------------------>< '-logsize--+-unlimited-+-' '-tamaño------'
>>-dscontrol--status-------------------------------------------><
Ejemplos
dscontrol statusEste mandato genera una salida parecida a la siguiente:
Se ha iniciado el ejecutor. Se ha iniciado el gestor. ---------------------------------------- | ASESOR | CLÚSTER:PUERTO | TPO ESPERA| ---------------------------------------- | reach | 0 | unlimited | | http | 80 | unlimited | | ftp | 21 | unlimited | ----------------------------------------
>>-dscontrol--subagent--+-loglevel--nivel--------------------+->< +-logsize--+-bytes-----+-------------+ | '-unlimited-' | +-report-----------------------------+ +-start--+-------------------------+-+ | '-nombre_comunidad--archivo_anotaciones-' | +-status-----------------------------+ +-stop-------------------------------+ '-version----------------------------'
En la plataforma Windows: se utiliza el nombre de comunidad del sistema operativo.
Ejemplos
dscontrol subagent start bigguy bigguy.log
En este capítulo se describe cómo utilizar los siguientes mandatos sscontrol de Site Selector:
Puede escribir una versión minimizada de los parámetros del mandato sscontrol. Sólo es necesario especificar las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir sscontrol he f en lugar de sscontrol help file.
>>-sscontrol--advisor--+-connecttimeout--nombre--+-puerto-------+--segundos-----+->< | '-nombresitio:puerto-' | +-interval--nombre--+-puerto----------+--segundos-------------+ | '-nombresitio:puerto-' | +-list---------------------------------------------------+ +-loglevel--nombre--+-puerto----------+--nivel---------------+ | '-nombresitio:puerto-' | +-logsize--nombre--+-puerto----------+--+-size | unlimited-+-+ | '-nombresitio:puerto-' '-bytes------------' | +-receivetimeout--nombre--+-puerto----------+--segundos-------+ | '-nombresitio:puerto-' | +-report--informe--+-puerto----------+------------------------+ | '-nombresitio:puerto-' | +-retries--nombre--+-puerto----------+--num_reints-----------+ | '-nombresitio:puerto-' | +-start--nombre--+-puerto----------+--+----------+-----------+ | '-nombresitio:puerto-' '-archivo_anotaciones-' | +-status--nombre--+-puerto----------+------------------------+ | '-nombresitio:puerto-' | +-stop--nombre--+-puerto----------+--------------------------+ | '-nombresitio:puerto-' | +-timeout--nombre--+-puerto----------+-----------------------+ | '-nombresitio:puerto-' | '-version--nombre--+-puerto----------+--segundos--------------' '-nombresitio:puerto-'
.
Nombre del asesor | Protocolo | Puerto |
---|---|---|
Connect | n/d | definido por el usuario |
db2 | private | 50000 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
PING | PING | N/D |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
El archivo predeterminado es puerto_nombre_asesor.log, por ejemplo, http_80.log. Para cambiar el directorio en el que se almacenan los archivos de anotaciones cronológicas, consulte el apartado Cambio de las vías de acceso del archivo de anotaciones cronológicas.
Sólo puede iniciar un asesor para cada nombre de sitio.
Ejemplos
sscontrol advisor connecttimeout http 80 30
sscontrol advisor interval ftp 21 6
sscontrol advisor listEste mandato genera una salida parecida a la siguiente:
--------------------------------------- | ASESOR | NOM_SITIO:PUERTO|TIEMPO ESP.| --------------------------------------- | http | 80 | unlimited | | ftp | 21 | unlimited | ---------------------------------------
sscontrol advisor loglevel http misitio:80 0
sscontrol advisor logsize ftp misitio:21 5000
sscontrol advisor receivetimeout http 80 60
sscontrol advisor report ftp 21Este mandato genera una salida parecida a la siguiente:
Informe del asesor: --------------- Nombre del asesor ........ http Número de puerto ......... 80 Nombre sitio ............. miSitio Dirección del servidor ... 9.67.129.230 Carga .................... 8
sscontrol advisor start ftp 21 ftpadv.log
sscontrol advisor status http 80Este mandato genera una salida parecida a la siguiente:
Estado del asesor: --------------- Intervalo (segundos) .......... 7 Tiempo de espera (segundos) ... Unlimited Tiempo espera conexión (seg) .. 21 Tiempo espera recepción (seg).. 21 Nombre anotaciones asesor ..... Http_80.log Nivel anotación cronológica ... 1 Tam. máx. arch. anot. (bytes) . Unlimited Número de reintentos .......... 0
sscontrol advisor stop http 80
sscontrol advisor timeout ftp 21 5
sscontrol advisor version ssl 443
>>-sscontrol--file--+-delete--nombre_archivo.ext----------+---------->< +-appendload--nombre_archivo.ext------+ +-report------------------------+ +-save--nombre_archivo.ext--+-------+-+ | '-force-' | '-newload--nombre_archivo.ext---------'
La extensión de archivo (.ext) puede ser cualquiera y es opcional.
Ejemplos
sscontrol file delete file3 Se ha suprimido el archivo (file3).
sscontrol file newload file1.sv El archivo (file1.sv) se ha cargado en Dispatcher.
sscontrol file appendload file2.sv El archivo (file2.sv) se ha añadido a la configuración actual y se ha cargado.
sscontrol file report INFORME SOBRE EL ARCHIVO: file1.save file2.sv file3
sscontrol file save file3 La configuración se ha guardado en el archivo (file3).
>>-sscontrol--help--+-advisor----+----------------------------->< +-file-------+ +-help-------+ +-host-------+ +-logstatus--+ +-manager----+ +-metric-----+ +-nameserver-+ +-rule-------+ +-server-----+ +-set--------+ +-sitename---+ '-status-----'
Ejemplos
sscontrol helpEste mandato genera una salida parecida a la siguiente:
ARGUMENTOS DEL MANDATO DE AYUDA: --------------------------------- Uso: help <opción de ayuda> Ejemplo: help nombre help - imprime el texto completo de la ayuda advisor - ayuda para el mandato advisor file - ayuda para el mandato file host - ayuda para el mandato host manager - ayuda para el mandato manager metric - ayuda para el mandato metric sitename - ayuda para el mandato sitename nameserver - ayuda para el mandato nameserver rule - ayuda para el mandato rule server - ayuda para el mandato server set - ayuda para el mandato set status - ayuda para el mandato status logstatus - ayuda para el mandato logstatusLos parámetros dentro de < > son variables.
logsize <número de bytes | unlimited> -Establece el número máximo de bytes anotados en el archivo de anotaciones cronológicas
>>-sscontrol--logstatus----------------------------------------><
>>-sscontrol--manager--+-interval--segundos----------------------+->< +-loglevel--nivel------------------------+ +-logsize--+-unlimited-+-----------------+ | '-bytes-----' | +-metric set--+-loglevel--nivel--------+-+ | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-reach set--+-interval--segundos------+--+ | +-loglevel--nivel--------+ | | '-logsize--+-unlimited-+-' | | '-bytes-----' | +-report--nombresitio+sn2+...+snN-----------+ +-restart--mensaje-----------------------+ +-sensitivity--peso----------------------+ +-smoothing--índice de suavizado---------+ +-start--+----------------------+--------+ | '-archivo_anotaciones--puerto_métrica-' | +-status---------------------------------+ +-stop-----------------------------------+ '-version--------------------------------'
El archivo predeterminado se instala en el directorio logs. Consulte el Apéndice C. Archivos de configuración de ejemplo. Para cambiar el directorio en el que se guardan los archivos de anotaciones cronológicas, consulte el apartado Cambio de las vías de acceso del archivo de anotaciones cronológicas.
Ejemplos
sscontrol manager interval 5
sscontrol manager loglevel 0
sscontrol manager logsize 1000000
sscontrol manager reportEste mandato genera una salida parecida a la siguiente:
---------------------------------- | SERVIDOR | ESTADO | ---------------------------------- | 9.67.129.221| ACTIVO| | 9.67.129.213| ACTIVO| | 9.67.134.223| ACTIVO| ---------------------------------- -------------------------- | LEYENDA INFORMES GESTOR| -------------------------- | CPU | Carga CPU | | MEM | Carga memoria | | SYS | Métrica sistema | | NOW | Peso actual | | NEW | Nuevo peso | | WT | Peso | -------------------------- ------------------------------------------------------------------------ | miSitio | PESO | CPU 49% | MEM 50% | PUERTO 1%| SYS 0% | ------------------------------------------------------------------------ | |NOW NEW | WT CARGA | WT CARGA | WT CARGA | WT CARGA | ------------------------------------------------------------------------ | 9.37.56.180 | 10 10 |-99 -1|-99 -1|-99 -1| 0 0| ------------------------------------------------------------------------ | TOTALES:| 10 10 | -1| -1| -1| 0| ------------------------------------------------------------------------ ----------------------------------------- | ASESOR | NOM_SITIO:PUERTO|TIEMPO ESP.| ----------------------------------------- | http | 80 | unlimited | -----------------------------------------
sscontrol manager restart Reiniciando el gestor para actualizar códigoEste mandato genera una salida parecida a la siguiente:
320-14:04:54 Reiniciando el gestor para actualizar código
sscontrol manager sensitivity 10
sscontrol manager smoothing 2.0
sscontrol manager start ndmgr.log
sscontrol manager statusEste mandato genera una salida parecida al siguiente ejemplo:
Estado del gestor: ============= Puerto de métrica ............................ 10004 Archivo anotaciones del gestor ............... manager.log Nivel anotaciones del gestor ................. 1 Tamaño máximo anotaciones de gestor (bytes) .. unlimited Nivel de sensibilidad ........................ 5 Índice de suavizado .......................... 1,5 Intervalo de actualización (segundos) ........ 2 Ciclo de renovación de pesos ................. 2 Nivel de anotaciones asesor de alcance ....... 1 Tamaño máximo anot. asesor alcance (bytes) ... unlimited Intervalo intentos acceso a destino (seg.) ... 7
sscontrol manager stop
sscontrol manager version
>>-sscontrol--metric--+-add--nombresitio+sn2+...+snN:métrica+métrica1+...+métricaN--------------+->< +-remove--nombresitio+sn2+...+snN:métrica+métrica1+...+métricaN-----------+ +-proportions--nombresitio+sn2+...+snN:proporción1 prop2 prop3...propN-+ '-status--nombresitio+sn2+...+snN métrica+métrica1+...+métricaN-----------'
Ejemplos
sscontrol metric add sitio1:métrica1
sscontrol metric proportions sitio1 0 100
sscontrol metric status sitio1:métrica1Este mandato genera una salida parecida a la siguiente:
Estado de métrica: ------------ nombre_sitio .................. sitio1 Nombre de métrica ............. métrica1 Proporción de métrica ......... 50 Servidor ....... 9.37.56.100 Datos métrica .. -1
>>-sscontrol--nameserver--+-start--+----------------------+-+-->< | '-bindaddress--dirección-' | +-stop----------------------------+ '-status--------------------------'
>>-sscontrol--rule--+-add--nombresitio+sn2+...+snN:regla+r2+...+rN--type--valor--| value |--| opts |-+->< +-dropserver--nombresitio+sn2+...+snN:regla+r2+...+rN--servidor+s2+...+snN---------+ +-remove--nombresitio+sn2+...+snN:regla+r2+...+rN--------------------------------+ +-set--nombresitio+sn2+...+snN:regla+r2+...+rN--| value |--| opts |--------------+ +-status--nombresitio+sn2+...+snN:regla+r2+...+rN--------------------------------+ '-useserver--nombresitio+sn2+...+snN:regla+r2+...+rN--servidor+s2+...+snN----------' opts: |--+---------------------------------+--------------------------| +-beginrange--bajo--endrange--alto-+ +-priority--valor-----------------+ '-metricname--valor---------------'
Ejemplos
sscontrol rule add nombresitio:nombreregla type true priority 100
sscontrol rule add nombresitio:nombreregla type ip b 9.0.0.0 e 9.255.255.255
sscontrol rule add nombresitio:nombreregla type time beginrange 11 endrange 14 sscontrol rule useserver nombresitio:nombreregla server05
>>-sscontrol--server--+-add--nombresitio+sn2+...+snN:servidor+s2+...+sN--+------------------------+-+->< | +-metricaddress--dirección-+ | | '-weight--valor----------' | +-down--nombresitio+sn2+...+snN:servidor+s2+...+sN----------------------------+ +-remove--nombresitio+sn2+...+snN:servidor+s2+...+sN--------------------------+ +-set--nombresitio+sn2+...+snN:servidor+s2+...+sN--+------------------------+-+ | +-metricaddress--dirección-+ | | '-weight--valor----------' | +-status--nombresitio+sn2+...+snN:servidor+s2+...+sN--------------------------+ '-up--nombresitio+sn2+...+snN:servidor+s2+...+sN------------------------------'
Ejemplos
sscontrol server add sitio1:27.65.89.42
sscontrol server down sitio1:27.65.89.42
sscontrol server remove :27.65.89.42
sscontrol server up sitio1:27.65.89.42
>>-sscontrol--set--+-loglevel--nivel--------+------------------>< '-logsize--+-unlimited-+-' '-tamaño------'
>>-sscontrol--sitename--+-add--nombresitio+sn2+...+snN--+----------------------------------------+-+->< | +-cachelife--valor-----------------------+ | | +-networkproximity--sí | no-------------+ | | +-proportions--cpu--memoria--puerto--métrica-+ | | +-proximitypercentage--valor-------------+ | | +-stickytime--tiempo---------------------+ | | +-ttl--tiempo----------------------------+ | | +-waitforallresponses--sí | no-----------+ | | '-weightbound--peso----------------------' | +-remove--nombresitio+sn2+...+snN---------------------------------------+ +-set--nombresitio+sn2+...+snN--+-------------------------------------+-+ | +-cachelife--valor-----------------------+ | | +-networkproximity--sí | no-------------+ | | +-proportions--cpu--memoria--puerto--métrica-+ | | +-proximitypercentage--valor-------------+ | | +-stickytime--tiempo---------------------+ | | +-ttl--tiempo----------------------------+ | | +-waitforallresponses--sí | no-----------+ | | '-weightbound--peso----------------------' | '-status--nombresitio+sn2+...+snN------------------------------------------'
Ejemplos
sscontrol sitename add 130.40.52.153
sscontrol sitename set miSitio networkproximity yes
sscontrol sitename set miSitio cachelife 1900000
sscontrol sitename set miSitio proximitypercentage 45
sscontrol sitename set miSitio waitforallresponses no
sscontrol sitename set miSitio ttl 7
sscontrol nombresitio set miSitio proportions 50 48 1 1
sscontrol nombresitio remove 130.40.52.153
sscontrol nombresitio status miSitioEste mandato genera una salida parecida a la siguiente:
Estado del nombre del sitio: --------------- Nombre de sitio .................... miSitio Ponderación ........................ 20 TTL ................................ 5 Tiempo permanencia en memoria ...... 0 Número de servidores ............... 1 Proporción asignada a CpuLoad ...... 49 Proporción asignada a MemLoad ...... 50 Proporción asignada a Port ......... 1 Proporción asignada a métrica sist . 0 Asesor ejecutándose en puerto ...... 80 Utilización de proximidad .......... N
>>-sscontrol--status-------------------------------------------><
Ejemplos
sscontrol statusEste mandato genera una salida parecida a la siguiente:
Se ha iniciado el servidor de nombres. Se ha iniciado el gestor. ----------------------------------------- | ASESOR | NOM_SITIO:PUERTO|TIEMPO ESP.| ---------------------------------------- | http | 80 | unlimited | -----------------------------------------
En este capítulo se describe cómo utilizar los siguientes mandatos ccocontrol para Cisco CSS Controller:
Puede utilizar una versión abreviada de los parámetros del mandato ccocontrol escribiendo las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir ccocontrol he f en lugar de ccocontrol help file.
Para obtener el indicador de mandatos ccocontrol, escriba ccocontrol.
Para finalizar la interfaz de línea de mandatos, escriba exit o quit.
>>-ccocontrol--consultant--+-add--IDcc--address--dirIPconm--community--nombreComunidad-+->< +-binarylog--IDcc+IDcc2...--+-report-------------+--+ | +-set--+-intervalo--+-+ | | | '-retención-' | | | +-start--------------+ | | '-stop---------------' | +-remove--IDcc+IDcc2...-----------------------------+ +-report--IDcc+IDcc2...-----------------------------+ +-set--+-loglevel--nivel----------------+-----------+ | +-logsize--+-tamaño------+---------+ | | | '-ilimitado-' | | | +-sensitivity--porcentaje de peso-+ | | '-sleeptime--segundos-------------' | +-start--IDcc+IDcc2...------------------------------+ '-stop--IDcc+IDcc2...-------------------------------'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
Ejemplos
ccocontrol consultant add sc1 address 9.37.50.17 community comm2
ccocontrol consultant binarylog sc1 start
ccocontrol consultant report sc1
Este mandato genera una salida parecida a la siguiente:
Consultor sc1 conectado al conmutador en 9.37.50.1:cn1 El consultor se ha iniciado Tiempo de inactividad = 7 Sensibilidad = 5 Nivel anotación cronológica = 5 Tamaño de anotaciones = 1,048,576 Contenido de propietario: contenido de propietario oc1
ccocontrol consultant set sc1 sleeptime 10
ccocontrol consultant start sc1
>>-ccocontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--nivel--------+ '-logsize--+-tamaño------+-' '-ilimitado-'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
Ejemplos
ccocontrol controller report
Este mandato genera una salida parecida a la siguiente:
Informe del controlador: ------------------------ Versión . . . . . . . . . Versión: 05.00.00.00 - 03/21/2002-09:49:57-EST Nivel de anotaciones . . 1 Tamaño de anotaciones . . 1048576 Archivo de configuración. config1.xml Consultores: El consultor consult1 se ha iniciado
ccocontrol set loglevel 0
ccocontrol controller set logsize 1000000
>>-ccocontrol--file--+-delete--nombre_archivo----------+------------->< +-load--nombre_archivo------------+ +-report--------------------+ '-save--nombre_archivo--+-------+-' '-force-'
Directorio de instalación (predeterminado): C:\Archivos de programa\ibm\edge\lb\servers\configurations\cco
Ejemplos
ccocontrol file delete file1
ccocontrol file load config2
ccocontrol file report
Este mandato genera una salida parecida a la siguiente:
INFORME SOBRE EL ARCHIVO: ------------ file1.xml file2.xml file3.xml
ccocontrol file save config2
>>-ccocontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metriccollector--+ +-ownercontent-----+ '-service----------'
Ejemplos
ccocontrol help
Este mandato genera una salida parecida a la siguiente:
Están disponibles los siguientes mandatos: controller - opera en el controlador consultant - opera en consultores de conmutador file - opera en archivos de configuración help - opera en ayuda highavailability - opera en alta disponibilidad metriccollector - opera en recopiladores de métricas ownerContent - opera en contenido de propietario service - opera en servicios
>>-ccocontrol--highavailability--+-add--+-address--dirección---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--puerto---------------------+ | | '-role--+-primario---+------------' | | '-secundario-' | +-dropreach--dirección----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--tiempo-----+---------+ | +-takeoverinterval--tiempo-+ | | +-loglevel--nivel--------+ | | '-logsize--+-tamaño------+-' | | '-ilimitado-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--dirección-----------------------'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
ccocontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
ccocontrol highavailability usereach 9.37.50.9
ccocontrol highavailability dropreach 9.37.50.9
ccocontrol highavailability start manual
ccocontrol highavailability report
Este mandato genera una salida parecida a la siguiente:
Estado de alta disponibilidad: ------------------------- Nodo . . . . . . . . . . . primario Dirección de nodo . . . . 9.37.50.17 Puerto . . . . . . . . . . 12345 Dirección de socio . . . . 9.37.50.14 Estrategia de recuperación manual Intervalo de pulso . . . . 500 Intervalo de toma control. 2000 Estado . . . . . . . . . . desocupado Subestado. . . . . . . . . no sincronizado Estado de accesibilidad : Nodo/Socio --------------------------------------- Destinos de alcance no configurados
>>-ccocontrol--metriccollector--+-report--IDcc+IDcc2+...:mN+mN2...--------------------------+->< '-set--IDcc+IDcc2+...:mN+mN2...--+-timeoutconnect--segundos----+-' +-loglevel--nivel--------+ +-logsize--+-tamaño------+-+ | '-ilimitado-' | +-timeoutreceive--segundos----+ '-sleeptime--segundos---------'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
Ejemplos
ccocontrol metriccollector report sc1:http
Este mandato genera una salida parecida a la siguiente:
MetricCollector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
ccocontrol metriccollector set sc1:http timeoutconnect 15 logsize unlimited
>>-ccocontrol--ownerContent--+-add--IDcc:ocN--ownername--oN--contentrule--cN------------------------------+->< +-metrics--IDcc+IDcc2...:ocN+ocN2...--nM--importancia--nM2--i2----------------+ +-refresh--IDcc+IDcc2...:ocN+ocN2...-----------------------------------------+ +-remove--IDcc+IDcc2...:ocN+ocN2...------------------------------------------+ +-report--IDcc+IDcc2...:ocN+ocN2...------------------------------------------+ '-set--IDcc+IDcc2...:ocN+ocN2...----metric--nM--+------------------------+---' +-requeststring--serie--+ +-responsestring--serie-+ '-retry--núm_reintentos------'
A continuación se muestra una lista de nombres de métrica válidos y sus puertos asociados:
Nombre del asesor | Protocolo | Puerto |
---|---|---|
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (mediante Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10.007 |
activeconn | n/d | n/d |
connrate | n/d | n/d |
cpuload | n/d | n/d |
memload | n/d | n/d |
Ejemplos
ccocontrol ownerContent add sc1:oc1 ownername owner1 contentrule content1
ccocontrol ownerContent metrics sc1:oc1 activeconn 50 http 50
ccocontrol ownerContent report sc1:oc1
Este mandato genera una salida parecida a la siguiente:
ownerContent sc1:oc1 Weightbound = 10 Metric activeconn has proportion 25 ResponseString... n/a RequestString.... n/a Metric http has proportion 50 ResponseString... n/a RequestString.... n/a Metric connrate has proportion 25 ResponseString... n/a RequestString.... n/a Contains Service t3 Contains Service t2 Contains Service t1
ccocontrol ownerContent set sc1:oc1 metric http requeststring getCookie
>>-ccocontrol--service--+-report--IDcc+IDcc2...:ocN+ocN2...:svc+svc2...---------------------------------+->< '---set--IDcc+IDcc2...:ocN+ocN2...:svc+svc2...--+---------------------------+---' +-fixedweight--+-entero-+--+ | '-desactiva-----' | +-requestsourceip--dirIP-----+ +-metricserveraddress--dirIP-+ '-metricserverport--Npuerto---'
Ejemplos
ccocontrol service report sc1:oc1:t1
Este mandato genera una salida parecida a la siguiente:
El servicio sc1:oc1:ta tiene un peso de 10 El peso fijo tiene el valor off IP origen solicitud .. 9.27.24.156 Puerto de aplicación . 80 Direc. MetricServer .. 1.0.0.1 Puerto MetricServer .. 10004 activeconn de métrica tiene el valor -99 http de métrica tiene el valor -99 connrate de métrica tiene el valor -99
ccocontrol service set sc1:oc1:t2 metricserveraddress 9.37.50.17
En este capítulo se describe cómo utilizar los siguientes mandatos nalcontrol para Nortel Alteon Controller:
Puede utilizar una versión abreviada de los parámetros del mandato nalcontrol escribiendo las letras exclusivas de los parámetros. Por ejemplo, para obtener ayuda sobre el mandato para guardar archivos, puede escribir nalcontrol he f en lugar de nalcontrol help file.
Para obtener el indicador de mandatos nalcontrol, escriba nalcontrol.
Para finalizar la interfaz de línea de mandatos, escriba exit o quit.
>>-nalcontrol--consultant--+-add--IDcc--address--direcIPconm--+---------------------------+-+->< | +-rcommunity--NombreComLect--+ | | '-wcommunity--NombreCommEscr-' | +-binarylog--IDcc+IDcc2...--+-report------------------------+-+ | +-set--+-interval--intervalo---+-+ | | | '-retention--retención-' | | | +-start-------------------------+ | | '-stop--------------------------' | +-remove--IDcc+IDcc2...---------------------------------------+ +-report--IDcc+IDcc2...---------------------------------------+ +-set--+--------------------------------+---------------------+ | +-loglevel--nivel----------------+ | | +-logsize--+-tamaño------+---------+ | | | '-ilimitado-' | | | +-sensitivity--porcentaje de peso-+ | | '-sleeptime--segundos-------------' | +-start--IDcc+IDcc2...----------------------------------------+ '-stop--IDcc+IDcc2...-----------------------------------------'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
Ejemplos
nalcontrol consultant add sc1 address 9.37.50.17
nalcontrol consultant binarylog sc1 start
nalcontrol consultant report sc1
Este mandato genera una salida parecida a la siguiente:
ID de consultor: sc1 Direc. IP conmutador: 9.37.50.1 Comunidad de lectura: public Comunidad de lectura: private El consultor se ha iniciado Tiempo de inactividad = 7 Sensibilidad = 5 Nivel anotación cronológica = 5 Tamaño de anotaciones = 1,048,576 Servicio(s): Servicio svc1
nalcontrol consultant set sc1 sleeptime 10
nalcontrol consultant start sc1
>>-nalcontrol--controller--+-report--------------------------+->< '-set--+------------------------+-' +-loglevel--nivel--------+ '-logsize--+-tamaño------+-' '-ilimitado-'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
Ejemplos
nalcontrol controller report
Este mandato genera una salida parecida a la siguiente:
Informe del controlador: ------------------------ Versión . . . . . . . . . Versión: 05.00.00.00 - 03/21/2002-09:49:57-EST Nivel de anotaciones . . 1 Tamaño de anotaciones . . 1048576 Archivo de configuración. config1.xml Consultores: El consultor consult1 se ha iniciado
nalcontrol set loglevel 0
nalcontrol controller set logsize 1000000
>>-nalcontrol--file--+-delete--nombre_archivo-+---------------------->< +-load--nombre_archivo---+ +-report-----------+ '-save--nombre_archivo---'
Vía de acceso al directorio de instalación común: C:\Archivos de programa\ibm\edge\lb\servers\configurations\nal
Vía de acceso de directorio de instalación nativo: C:\Archivos de programa\ibm\lb\servers\configurations\nal
Ejemplos
nalcontrol file delete file1
nalcontrol file load config2
nalcontrol file report
Este mandato genera una salida parecida a la siguiente:
INFORME SOBRE EL ARCHIVO: ------------ file1.xml file2.xml file3.xml
nalcontrol file save config2
>>-nalcontrol--help--+-controller-------+---------------------->< +-consultant-------+ +-file-------------+ +-help-------------+ +-highavailability-+ +-metrinalllector--+ +-ownercontent-----+ '-service----------'
Ejemplos
nalcontrol help
Este mandato genera una salida parecida a la siguiente:
Están disponibles los siguientes mandatos: controller - opera en el controlador consultant - opera en consultores de conmutador file - opera en archivos de configuración help - opera en ayuda highavailability - opera en alta disponibilidad metriccollector - opera en recopiladores de métricas server - opera en servidores service - opera en servicios
>>-nalcontrol--highavailability--+-add--+-address--dirección---------------+-+->< | +-partneraddress--partneraddress-+ | | +-port--puerto---------------------+ | | '-role--+-primario---+------------' | | '-secundario-' | +-dropreach--dirección----------------------+ +-remove----------------------------------+ +-report----------------------------------+ +-set--+-beatinterval--tiempo-----+---------+ | +-takeoverinterval--tiempo-+ | | +-loglevel--nivel--------+ | | '-logsize--+-tamaño------+-' | | '-ilimitado-' | +-start--+-auto---+-----------------------+ | '-manual-' | +-stop------------------------------------+ +-takeover--------------------------------+ '-usereach--dirección-----------------------'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
nalcontrol highavailability add address 9.37.50.17 role primary port 12345 partneraddress 9.37.50.14
nalcontrol highavailability usereach 9.37.50.9
nalcontrol highavailability dropreach 9.37.50.9
nalcontrol highavailability start manual
nalcontrol highavailability report
Este mandato genera una salida parecida a la siguiente:
Estado de alta disponibilidad: ------------------------- Nodo . . . . . . . . . . . primario Dirección de nodo . . . . 9.37.50.17 Puerto . . . . . . . . . . 12345 Dirección de socio . . . . 9.37.50.14 Estrategia de recuperación manual Intervalo de pulso . . . . 500 Intervalo de toma control. 2000 Iniciado . . . . . . . . . N Estado . . . . . . . . . . desocupado Subestado. . . . . . . . . no sincronizado Estado de accesibilidad : Nodo/Socio ---------------------------------------
>>-nalcontrol--metricollector--+-report--IDcc+IDcc2+...:nM+nM2...--------------------------+->< '-set--IDcc+IDcc2+...:nM+nM2...--+-connecttimeout--segundos----+-' +-loglevel--nivel--------+ +-logsize--+-tamaño------+-+ | '-ilimitado-' | +-receivetimeout--segundos----+ '-sleeptime--segundos---------'
0 = Ninguno
1 = Mínimo
2 = Básico
3 = Moderado
4 = Avanzado
5 = Detallado
Ejemplos
nalcontrol metrinalllector report sc1:http
Este mandato genera una salida parecida a la siguiente:
Metrinalllector sc1:http collected metric(s).... http loglevel............... 5 logSize................ 1048576 sleepTimeSeconds....... 7 timeoutConnectSeconds.. 21 timeoutReceiveSeconds.. 21
nalcontrol metrinalllector set sc1:http connecttimeout 15 logsize unlimited
>>-nalcontrol--serer--+-report--IDcc+IDcc2...:IDsvc+IDsvc2...:IDservidor+IDsrv2...---------------------------------+->< '---set--IDcc+IDcc2...:IDsvc+IDsvc2...:IDservidor+IDsrv2--+--------------------------------+---' +-fixedweight--+-entero-+-------+ | '-desactiva-----' | +-requestsourceip--direcciónIP-----+ +-metricserveraddress--direcciónIP-+ '-metricserverport--númeroPuerto---'
Ejemplos
nalcontrol server report sc1:svc1:1
Este mandato genera una salida parecida a la siguiente:
El servidor sc1:svc1:1 tiene un peso de -99 El peso fijo tiene el valor off IP origen solicitud ... 9.27.24.156 Puerto de aplicación .. 99 Dirección MetricServer 9.99.99.98 Puerto de MetricServer 10004 activeconn de métrica tiene el valor -99 connrate de métrica tiene el valor -99
nalcontrol server set sc1:svc1:2 metricserveraddress 9.37.50.17
>>-nalcontrol--service--+-add--IDcc+IDcc2...:IDservicio+IDsvc2...--vsid--IDSvrVir--vport--NúmPuertoVirt------+->< +-metrics--IDcc+IDcc2...:IDsvc+IDsvc2...--nM--importancia--mCN2--i2---------------+ +-refresh--IDcc+IDcc2...:IDsvc+IDsvc2...-----------------------------------------+ +-remove--IDcc+IDcc2...:IDsvc+IDsvc2...------------------------------------------+ +-report--IDcc+IDcc2...:IDsvc+IDsvc2...------------------------------------------+ '-set--IDcc+IDcc2...:IDsvc+IDsvc2...----metric--nM----+-requeststring--serie--+-' +-responsestring--serie-+ '-retry--núm_reintentos------'
A continuación se muestra una lista de nombres de métrica válidos y sus puertos asociados:
Nombre del asesor | Protocolo | Puerto |
---|---|---|
connect | ICMP | 12345 |
db2 | private | 50000 |
dns | DNS | 53 |
ftp | FTP | 21 |
http | HTTP | 80 |
https | SSL | 443 |
cachingproxy | HTTP (mediante Caching Proxy) | 80 |
imap | IMAP | 143 |
ldap | LDAP | 389 |
nntp | NNTP | 119 |
ping | PING | 0 |
pop3 | POP3 | 110 |
sip | SIP | 5060 |
smtp | SMTP | 25 |
ssl | SSL | 443 |
telnet | Telnet | 23 |
WLM | private | 10.007 |
activeconn | n/d | n/d |
connrate | n/d | n/d |
cpuload | n/d | n/d |
memload | n/d | n/d |
Ejemplos
nalcontrol service add sc1:svc1 vsid 1 vport 80
nalcontrol service metrics sc1:svc1 activeconn 50 http 50
nalcontrol service report sc1:svc1
Este mandato genera una salida parecida a la siguiente:
Service sc1:svc1 Weightbound = 48 Metric activeconn has proportion 50 Metric connrate has rpoportion 50 Contains Server 4 Contains Server 3 Contains Server 2 Contains Server 1
nalcontrol service set sc1:svc1 metric http requeststring getLastErrorCode
En la interfaz gráfica de usuario de Load Balancer, el lado izquierdo del panel muestra una estructura de árbol con Load Balancer en el nivel superior y Dispatcher, CBR (Content Based Routing), Site Selector, Cisco CSS Controller y Nortel Alteon Controller como componentes.
Todos los componentes pueden configurarse desde la GUI. Puede seleccionar elementos en la estructura de árbol pulsando el botón del ratón (normalmente el botón izquierdo) y, a continuación, mostrar los menús emergentes pulsando el botón dos del ratón (normalmente el botón derecho). También se puede acceder a los menús emergentes de los tres elementos desde la barra de menús situada en la parte superior del panel.
Pulse los signos más o menos para expandir o contraer los elementos de la estructura de árbol.
Para ejecutar un mandato desde la GUI: resalte el nodo Host en el árbol de la GUI y seleccione Enviar mandato.... en el menú emergente Host. En el campo de entrada de mandatos, escriba el mandato que desea ejecutar, por ejemplo: executor report. Aparecerán en la ventana proporcionada los resultados y el historial de los mandatos ejecutados en la sesión actual.
En la parte derecha del panel se muestran pestañas que indican el estado del elemento seleccionado actualmente.
Para acceder a la Ayuda, pulse el signo de interrogación (?) situado en la esquina superior derecha de la ventana de Load Balancer.
En este apéndice se describe cómo utilizar la sintaxis de la regla de contenido (patrón) para el componente CBR y el método de reenvío CBR del componente Dispatcher, junto con los escenarios y ejemplos de su uso.
Aplicable sólo si se ha seleccionado "contenido" para el tipo de regla.
Entre la sintaxis de patrón que desea utilizar, con las siguientes restricciones
Las palabras claves reservadas siempre van seguidas de un signo igual "=".
Un valor con destino http://www.empresa.com/path/webpage.htm podría mostrar los valores siguientes:
Method=GET URI=/path/webpage.htm Version=HTTP/1.1 Host=www.empresa.com Connection=Keep-Alive Referer=http://www.empresa.com/path/parentwebpage.htm
Por ejemplo, el siguiente mandato sólo es válido cuando se utiliza el indicador cbrcontrol>> o desde un archivo de configuración.
rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern "uri=/nipoek/*"
Cuando se utilizan caracteres especiales, para que este mismo mandato funcione en el indicador del sistema operativo, debe colocar el mandato completo entre comillas:
cbrcontrol "rule add 10.1.203.4:80:cbr_prod_rule_ek type content pattern uri=/nipoek/*"
Si no se utilizan las comillas, alguna parte del patrón puede truncarse cuando la regla se guarda en CBR.
A continuación se muestra una recopilación de posibles casos y ejemplos para el uso de sintaxis de patrón
Caso de ejemplo 1:
La configuración de un nombre de clúster incluye un conjunto de servidores Web para el contenido HTML estándar, otro conjunto para servidores Web con WebSphere Application Server para peticiones de servlet, otro conjunto de servidores Lotus(R) Notes(R) para archivos NSF, etc. Para distinguir entre estas páginas solicitadas es necesario tener acceso al cliente. También es necesario enviarlas a los servidores adecuados. Las reglas de coincidencia de patrones de contenido proporcionan la separación necesaria para llevar a cabo estas tareas. Para que la separación de las peticiones necesaria se produzca automáticamente, se configura una serie de reglas. Por ejemplo, los siguientes mandatos realizan las tres separaciones antes mencionadas:
>>rule add cluster1:80:servlets type content pattern "uri=*/servlet/*" priority 1 >>rule uses cluster1:80:servlets server1+server2
>>rule add cluster1:80:notes type content pattern "uri=*.nsf*" priority 2 >>rule uses cluster1:80:notes server3+server4
>>rule add cluster1:80:regular type true priority 3 >>rule uses cluster1:80:regular server5+server6
Si una petición para un archivo NSF llega a Load Balancer, primero la examina la regla de servlets, pero no coincide. A continuación, la petición la examina la regla de notes y devuelve una coincidencia. La carga del cliente está equilibrada entre server3 y server4.
Caso de ejemplo 2
Otro ejemplo común es cuando el sitio Web principal controla varios grupos internos distintos. Por ejemplo, www.empresa.com/software incluye un conjunto de servidores y un contenido distinto de la división www.empresa.com/hardware. Puesto que las peticiones están basadas en el clúster de www.empresa.com raíz, las reglas de contenido tienen que encontrar las diferencias de URI y completar el equilibrio de carga. La regla del caso de ejemplo se parece a la siguiente:
>>rule add cluster1:80:div1 type content pattern "uri=/software/*" priority 1 >>rule uses cluster1:80:div1 server1+server2
>>rule add cluster1:80:div2 type content pattern "uri=/hardware/*" priority 2 >>rule uses cluster1:80:div2 server3+server4
Caso de ejemplo 3
Determinadas combinaciones son susceptibles al orden en el que se realiza la búsqueda en las reglas. Por ejemplo, en el caso de ejemplo 2, los clientes se separaron en función de un directorio de su vía de acceso de peticiones; sin embargo, el directorio de destino puede aparecer en varios niveles de la vía de acceso e indicar cosas distintas dependiendo del lugar en que se encuentren. Por ejemplo, www.empresa.com/pcs/fixes/software es un destino distinto de www.empresa.com/mainframe/fixes/software. Las reglas deben definirse de forma que tengan prevista esta posibilidad y no identifique demasiados casos a la vez. Por ejemplo, la prueba "uri=*/software/*" es una búsqueda con comodín demasiado amplia en este caso. Pueden estructurarse reglas alternativas de la siguiente forma:
Una búsqueda de combinación puede limitarla:
>>rule add cluster1:80:pcs type content pattern "(uri=/pcs/*)&(uri=*/software/*)" >>rule uses cluster 1:80:pcs server1
En los casos en los que no haya combinaciones, el orden pasa a ser importante:
>>rule add cluster1:80:pc1 type content pattern "uri=/pcs/*" >>rule uses cluster1:80:pc1 server2
La segunda regla detecta cuando "pcs" aparece en lugares de directorios posteriores en lugar del primero.
>>rule add cluster1:80:pc2 type content pattern "uri=/*/pcs/*" >>rule uses cluster1:80:pc2 server3
En casi cada caso, desea completar las reglas con una regla siempre cierta predeterminada para identificar todo lo que no puedan detectar otras reglas. Esto también puede ser un servidor "Lo sentimos, el sitio está inactivo actualmente, inténtelo más adelante" para los casos en los que los demás servidores no pueden aceptar la petición de este cliente.
>>rule add cluster1:80:sorry type true priority 100 >>rule uses cluster1:80:sorry server5
Este apéndice contiene archivos de configuración de ejemplo para el componente Dispatcher de Load Balancer.
Los archivos de ejemplo se ubican en el directorio ...ibm/edge/lb/servers/samples/.
#!/bin/bash
#
# configuration.sample - Archivo de configuración de ejemplo para el
componente Dispatcher
#
#
# Asegúrese de ejecutar este script como usuario root.
#
# iam=`whoami`
# if [ "$iam" != "root" ]if [ "$iam" != "root" ]
# then
# echo "Debe iniciar la sesión como root para ejecutar este script"
# exit 2
# fi
#
# Primero, inicie el servidor
#
# dsserver start
# sleep 5
#
# Después inicie el ejecutor
#
# dscontrol executor start
#
# Dispatcher puede eliminarse en cualquier momento con los
# mandatos "dscontrol executor stop" y "dsserver stop" para
# detener respectivamente el ejecutor y servidor antes de eliminar
# el software de Dispatcher.
#
# En el siguiente paso de la configuración de Dispatcher se establecerá la
# NFA (dirección de no reenvío) y las direcciones del clúster.
#
# La NFA se usa para acceder de forma remota a la máquina Dispatcher
# para fines de administración o configuración. Esta
# dirección es necesaria puesto que Dispatcher enviará paquetes
# a las direcciones de clúster.
#
# La dirección de clúster es el nombre de host (o dirección IP) al
# que se conectarán los clientes remotos.
#
# En todo este archivo puede utilizar los nombres de host y
# las direcciones IP de manera intercambiable.
#
# NFA=hostname.domain.name
# CLUSTER=www.suempresa.com
# echo "Cargando la dirección de no reenvío"
# dscontrol executor set nfa $NFA
#
# En el siguiente paso de la configuración de Dispatcher se creará
# un clúster. Dispatcher direccionará las peticiones enviadas a
# la dirección del clúster a las correspondientes máquinas servidor
# definidas para dicho clúster. Puede configurar y atender a
# varias direcciones de clúster con Dispatcher.
# Emplee una configuración parecida para CLUSTER2, CLUSTER3, etc.
#
# echo "Cargando primero la dirección de clúster"
# dscontrol cluster add $CLUSTER
#
# Ahora, tenemos que definir los puertos que usará este clúster. Todas
# las peticiones recibidas por Dispatcher en un puerto definido se
# reenviarán al correspondiente puerto de una de las
# máquinas servidor.
#
# echo "Creando puertos para clúster: $CLUSTER"
# dscontrol port add $CLUSTER:20+21+80
#
# En el último paso se añadirá cada una de las máquinas servidor a los
# puertos de este clúster.
# De nuevo, puede usar el nombre de host o la dirección IP
# de las máquinas servidor.
#
# SERVER1=server1name.domain.name
# SERVER2=server2name.domain.name
# SERVER3=server3name.domain.name
# echo "Añadiendo máquinas servidor"
# dscontrol server add $CLUSTER:20+21+80:
# $SERVER1+$SERVER2+$SERVER3
#
# Ahora empezará el equilibrio de carga de los componentes de
# Dispatcher. El principal componente del equilibrio de carga se denomina
# gestor y el segundo componente del equilibrio de carga son los
# asesores. Si el gestor y los asesores no están ejecutándose,
# Dispatcher envía peticiones de forma de turno rotativo. Una vez que
# se inicia el gestor, se emplea la ponderación de decisiones en base al
# número de conexiones nuevas y activas, y las peticiones entrantes
# se envían al mejor servidor. Los asesores ofrecen al
# gestor una mejor comprensión de la capacidad de los servidores para atender
# peticiones así como detectar si un servidor está activo. Si
# un asesor detecta que un servidor está inactivo, se marcará como inactivo
# (siempre que las proporciones del gestor se hayan establecido
# de forma que incluyan la entrada del asesor) y no se direccionarán
# más peticiones al servidor.
# En el último paso de la configuración de los componentes del equilibrio de carga
# se establecerán las proporciones del gestor. El gestor actualiza el
# peso de cada uno de los servidores basándose en cuatro políticas:
# 1. El número de conexiones activas en cada servidor.
# 2. El número de nuevas conexiones en cada servidor.
# 3. La entrada de datos desde los asesores.
# 4. La entrada de datos desde el asesor del nivel del sistema.
# La suma de estas proporciones debe ser 100. Como ejemplo, si se establecen
# las proporciones del gestor en
# dscontrol manager proportions 48 48 0 0
# otorgará a las conexiones activas y nuevas el 48% de entrada en la
# ponderación de decisiones, los asesores contribuirán un 4% y
# no se tendrá en cuenta la entrada del sistema.
#
# NOTA: de manera predeterminada, las proporciones del gestor están establecidas en 50 50 0 0
#
# echo "Iniciando el gestor..."
# dscontrol manager start
# echo "Iniciando el asesor FTP en puerto 21 ..."
# dscontrol advisor start ftp 21
# echo "Iniciando el asesor HTTP en puerto 80 ..."
# dscontrol advisor start http 80
# echo "Iniciando el asesor Telnet en puerto 23 ..."
# dscontrol advisor start telnet 23
# echo "Iniciando el asesor SMTP en puerto 25 ..."
# dscontrol advisor start smtp 25
# echo "Iniciando el asesor POP3 en puerto 110 ..."
# dscontrol advisor start pop3 110
# echo "Iniciando el asesor NNTP en puerto 119 ..."
# dscontrol advisor start nntp 119
# echo "Iniciando el asesor SSL en puerto 443 ..."
# dscontrol advisor start ssl 443
#
# echo "Definiendo las proporciones del gestor..."
# dscontrol manager proportions 58 40 2 0
#
# El último paso de la configuración de la máquina Dispatcher es crear un
# alias para la tarjeta de interfaz de red (NIC).
#
# NOTA: NO utilice este mandato en un entorno de alta
# disponibilidad. Los scripts go* configurarán la NIC y
# el bucle de retorno según sea necesario.
# dscontrol executor configure $CLUSTER
# Si la dirección de clúster está en una NIC o subred distinta
de la de NFA, utilice el siguiente formato para el mandato cluster
configure.
# dscontrol executor configure $CLUSTER tr0 0xfffff800
# donde tr0 es la NIC (tr1 para la segunda tarjeta token ring, en0
# para la primera tarjeta ethernet) y 0xfffff800 es una
# máscara de subred válida para el sitio.
#
#
# Los siguientes mandatos se establecen en los valores predeterminados.
# Utilice estos mandatos como guía para cambiar los valores predeterminados.
# dscontrol manager loglevel 1
# dscontrol manager logsize 1048576
# dscontrol manager sensitivity 5
# dscontrol manager interval 2
# dscontrol manager refresh 2
#
# dscontrol advisor interval ftp 21 5
# dscontrol advisor loglevel ftp 21 1
# dscontrol advisor logsize ftp 21 1048576
# dscontrol advisor timeout ftp 21 unlimited
# dscontrol advisor interval telnet 23 5
# dscontrol advisor loglevel telnet 23 1
# dscontrol advisor logsize telnet 23 1048576
# dscontrol advisor timeout telnet 23 unlimited
# dscontrol advisor interval smtp 25 5
# dscontrol advisor loglevel smtp 25 1
# dscontrol advisor logsize smtp 25 1048576
# dscontrol advisor timeout smtp 25 unlimited
# dscontrol advisor interval http 80 5
# dscontrol advisor loglevel http 80 1
# dscontrol advisor logsize http 80 1048576
# dscontrol advisor timeout http 80 unlimited
# dscontrol advisor interval pop3 110 5
# dscontrol advisor loglevel pop3 110 1
# dscontrol advisor logsize pop3 110 1048576
# dscontrol advisor timeout pop3 110 unlimited
# dscontrol advisor interval nntp 119 5
# dscontrol advisor loglevel nntp 119 1
# dscontrol advisor logsize nntp 119 1048576
# dscontrol advisor timeout nntp 119 unlimited
# dscontrol advisor interval ssl 443 5
# dscontrol advisor loglevel ssl 443 1
# dscontrol advisor logsize ssl 443 1048576
# dscontrol advisor timeout ssl 443 unlimited
#
A continuación se muestra un archivo de configuración de Load Balancer de ejemplo denominado configuration.cmd.sample para puede utilizarse con Windows.
@echo off rem configuration.cmd.sample - Archivo de configuración de ejemplo para el rem componente Dispatcher. rem rem dsserver debe iniciarse a través de Servicios rem rem rem Después inicie el ejecutor rem rem call dscontrol executor start rem rem En el siguiente paso de la configuración de Dispatcher se establecerá la rem NFA (dirección de no reenvío) y las direcciones rem del clúster. rem rem La NFA se usa para acceder de forma remota a la máquina rem Dispatcher para fines de configuración de administración. Esta rem dirección es necesaria puesto que Dispatcher enviará rem paquetes a las direcciones de clúster. rem rem La dirección de clúster es el nombre de host (o dirección IP) al rem que se conectarán los clientes remotos. rem rem En todo este archivo puede utilizar los nombres de host y rem las direcciones IP de manera intercambiable. rem NFA=[dirección de no reenvío] rem CLUSTER=[el nombre de clúster] rem rem set NFA=hostname.domain.name rem set CLUSTER=www.suempresa.com rem echo "Cargando la dirección de no reenvío" rem call dscontrol executor set nfa %NFA% rem rem Los siguientes mandatos se establecen en los valores predeterminados rem Utilice estos mandatos para cambiar los valores predeterminados rem call dscontrol executor set fintimeout 30 rem rem En el siguiente paso de la configuración de Dispatcher se creará rem un clúster. Dispatcher direccionará las peticiones enviadas a rem la dirección del clúster a las correspondientes máquinas servidor rem definidas para dicho clúster. Puede configurar y atender a rem varias direcciones de clúster con Dispatcher. rem Emplee una configuración parecida para CLUSTER2, CLUSTER3, etc. rem rem echo "Cargando primero la dirección de clúster" rem call dscontrol cluster add %CLUSTER% rem rem Ahora, tenemos que definir los puertos que usará este clúster. Todas rem las peticiones recibidas por Dispatcher en un puerto definido se rem reenviará al correspondiente rem puerto de una de las máquinas servidor. rem rem echo "Creando puertos para clúster: %CLUSTER%" rem call dscontrol port add %CLUSTER%:20+21+80 rem rem En el último paso se añadirá cada una de las máquinas servidor a rem los puertos de este clúster. De nuevo, puede utilizar el rem nombre de host o la dirección IP de las máquinas servidor. rem rem set SERVER1=server1name.domain.name rem set SERVER2=server2name.domain.name rem set SERVER3=server3name.domain.name rem echo "Añadiendo máquinas servidor" rem call dscontrol server add %CLUSTER%:20+21+80: rem %SERVER1%+%SERVER2%+%SERVER3% rem rem Ahora empezará el equilibrio de carga de los componentes de rem Dispatcher. El principal componente del equilibrio de carga se denomina rem gestor y el segundo componente del equilibrio de carga son los rem asesores. Si el gestor y los asesores no están rem ejecutándose, Dispatcher envía peticiones en forma de turno rotativo. rem Una vez que se inicia el gestor, se emplea la ponderación de decisiones rem en base al número de conexiones nuevas y activas rem y las peticiones entrantes se envían al mejor rem servidor. Los asesores ofrecen al gestor una mejor compresión rem de la capacidad de los servidores para atender peticiones así como rem detectar si un servidor está activo. Si un asesor detecta rem que un servidor está inactivo, se marcará como inactivo (siempre que las rem proporciones del gestor se hayan establecido de forma que incluyan rem la entrada del asesor) y no se direccionarán más peticiones al servidor. rem En el último paso de la configuración de los componentes del equilibrio rem de carga se establecerán las proporciones del gestor. El rem gestor actualiza el peso de cada uno de los servidores basándose rem en cuatro políticas: rem 1. El número de conexiones activas en cada servidor rem 2. El número de nuevas conexiones en cada servidor rem 3. La entrada de datos desde los asesores. rem 4. La entrada de datos desde el asesor del nivel del sistema. rem rem La suma de estas proporciones debe ser 100. Como ejemplo, si se rem establecen las proporciones de clúster mediante rem dscontrol cluster set <cluster> proportions 48 48 4 0 rem otorgará a las conexiones activas y nuevas el 48% de entrada en la rem ponderación de decisiones, el asesor contribuirá un 4% y rem no se tendrá en cuenta la entrada del sistema. rem rem NOTA: de manera predeterminada, las proporciones del gestor están establecidas en rem 50 50 0 0 rem echo "Iniciando el gestor..." rem call dscontrol manager start rem echo "Iniciando el asesor FTP en puerto 21 ..." rem call dscontrol advisor start ftp 21 rem echo "Iniciando el asesor HTTP en puerto 80 ..." rem call dscontrol advisor start http 80 rem echo "Iniciando el asesor Telnet en puerto 23 ..." rem call dscontrol advisor start telnet 23 rem echo "Iniciando el asesor SMTP en puerto 25 ..." rem call dscontrol advisor start smtp 25 rem echo "Iniciando el asesor POP3 en puerto 110 ..." rem call dscontrol advisor start pop3 110 rem echo "Iniciando el asesor NNTP en puerto 119 ..." rem call dscontrol advisor start nntp 119 rem echo "Iniciando el asesor SSL en puerto 443 ..." rem call dscontrol advisor start ssl 443 rem rem echo "Definiendo las proporciones del clúster..." rem call dscontrol cluster set %CLUSTER% proportions 58 40 2 0 rem rem El último paso de la configuración de la máquina Dispatcher es rem crear un alias para la tarjeta de interfaz de red (NIC). rem rem NOTA: NO utilice este mandato en un entorno de alta rem disponibilidad. Los scripts go* configurarán la NIC y rem el bucle de retorno según sea necesario. rem rem dscontrol executor configure %CLUSTER% rem Si la dirección de clúster está en una NIC o subred distinta rem de la de NFA, utilice el siguiente formato para el mandato cluster rem configure. rem dscontrol executor configure %CLUSTER% tr0 0xfffff800 rem donde tr0 es la NIC (tr1 para la segunda tarjeta token ring, rem en0 para la primera tarjeta ethernet) y 0xfffff800 es rem una máscara de subred válida para el sitio. rem rem rem Los siguientes mandatos se establecen en los valores predeterminados. rem Utilice estos mandatos como orientación para cambiar los valores predeterminados. rem call dscontrol manager loglevel 1 rem call dscontrol manager logsize 1048576 rem call dscontrol manager sensitivity 5 rem call dscontrol manager interval 2 rem call dscontrol manager refresh 2 rem rem call dscontrol advisor interval ftp 21 5 rem call dscontrol advisor loglevel ftp 21 1 rem call dscontrol advisor logsize ftp 21 1048576 rem call dscontrol advisor timeout ftp 21 unlimited rem call dscontrol advisor interval telnet 23 5 rem call dscontrol advisor loglevel telnet 23 1 rem call dscontrol advisor logsize telnet 23 1048576 rem call dscontrol advisor timeout telnet 23 unlimited rem call dscontrol advisor interval smtp 25 5 rem call dscontrol advisor loglevel smtp 25 1 rem call dscontrol advisor logsize smtp 25 1048576 rem call dscontrol advisor timeout smtp 25 unlimited rem call dscontrol advisor interval http 80 5 rem call dscontrol advisor loglevel http 80 1 rem call dscontrol advisor logsize http 80 1048576 rem call dscontrol advisor timeout http 80 unlimited rem call dscontrol advisor interval pop3 110 5 rem call dscontrol advisor loglevel pop3 110 1 rem call dscontrol advisor logsize pop3 110 1048576 rem call dscontrol advisor timeout pop3 110 unlimited rem call dscontrol advisor interval nntp 119 5 rem call dscontrol advisor loglevel nntp 119 1 rem call dscontrol advisor logsize nntp 119 1048576 rem call dscontrol advisor timeout nntp 119 unlimited rem call dscontrol advisor interval ssl 443 5 rem call dscontrol advisor loglevel ssl 443 1 rem call dscontrol advisor logsize ssl 443 1048576 rem call dscontrol advisor timeout ssl 443 unlimited rem
A continuación se muestra un archivo de asesor de ejemplo denominado ADV_sample.
/**
* ADV_sample: Asesor HTTP de Load Balancer
*
*
* Esta clase define un asesor personalizado de ejemplo para Load Balancer. Como
* todos los asesores, este asesor personalizado amplía la función de la base del
* asesor, denominada ADV_Base. Es la base del asesor que en realidad realiza la
* mayoría de las funciones del asesor, como informar de las cargas a Load Balancer
* para su uso en el algoritmo de peso de Load Balancer. La base del asesor también
* realiza operaciones de cierre y conexión de sockets, y proporciona métodos
* de envío y recepción para que el asesor los emplee. El asesor sólo se utiliza
* para enviar y recibir datos del puerto del servidor que se está asesorando.
* Se calcula la duración de los métodos TCP incluidos en la base del asesor para
* calcular la carga. Un distintivo interno del constructor de ADV_base escribe
* sobre la carga existente la nueva carga devuelta desde el asesor, si se desea.
*
* Nota: en función de un valor fijado en el constructor, la base del asesor
* suministra la carga al algoritmo de peso a intervalos especificados. Si el
* asesor real no se ha completado y puede devolver una carga válida, la base del
* asesor utiliza la carga anterior.
*
* DENOMINACIÓN
*
* El convenio de denominación es el siguiente:
*
* - El archivo debe estar en el siguiente directorio de Load Balancer:
*
* lb/servers/lib/CustomAdvisors/ (lb\servers\lib\CustomAdvisors en Windows)
*
* - El nombre del asesor debe ir precedido de "ADV_". Sin embargo, el asesor
* sólo puede empezar con el nombre; por ejemplo, el asesor "ADV_sample"
* puede empezar con "sample".
*
* - El nombre del asesor debe indicarse en minúsculas.
*
* Por lo tanto, teniendo presente estas reglas, este ejemplo se denomina:
*
* <directorio base>/lib/CustomAdvisors/ADV_sample.class
*
*
* Los asesores, al igual que el resto de Load Balancer, deben compilarse con la
* versión prereq de Java. Para garantizar el acceso a las clases de Load Balancer,
* asegúrese de que el archivo ibmlb.jar (que se encuentra en el directorio lib
* del directorio base) está incluido en la CLASSPATH del sistema.
*
* Métodos proporcionados por ADV_Base:
*
* - ADV_Base (Constructor):
*
* - Parámetros
* - String sName = Nombre del asesor
* - String sVersion = Versión del asesor
* - int iDefaultPort = Número de puerto predeterminado sobre el que asesorar
* - int iInterval = Intervalo sobre el que asesorar sobre los servidores
* - String sDefaultName = No se utiliza. Debe pasarse como "".
* - boolean replace = True - sustituye el valor de carga que calcula
* la base del asesor
* False - añade el valor de carga que calcula
* la base del asesor
* - Retorno
* - Los constructores no tienen valores de retorno.
*
* Puesto que la base del asesor se basa en hebras, tiene otros métodos
* disponibles que un asesor puede usar. Se puede hacer referencia a estos métodos
* con el parámetro CALLER pasado en getLoad().
*
* Estos métodos son los siguientes:
*
* - send - Envía un paquete de información en la conexión de socket establecida
* al servidor del puerto especificado.
* - Parámetros
* - String sDataString - Los datos que deben enviar en el formato de serie
* - Retorno
* - int RC - Si los datos se han enviado satisfactoriamente; cero indica que
* los datos se han enviado; un entero negativo indica un error.
*
* - receive - Recibe información de la conexión del socket.
* - Parámetros
* - StringBuffer sbDataBuffer - Los datos recibidos durante la llamada de
* recepción
* - Retorno
* - int RC - Si los datos se recibieron satisfactoriamente; cero
* indica que los datos se enviaron; un entero negativo indica
* un error.
*
* Si la función que proporciona la base del asesor no es suficiente,
* puede crear la función adecuada dentro del asesor y
* se ignorarán los métodos que proporciona la base del asesor.
*
* Una pregunta importante en relación a la carga devuelta es si se debe aplicar
* si la carga que se genera dentro de la base del asesor,
* o se debe sustituir; hay instancias válidas para las dos situaciones.
*
* Este ejemplo es fundamentalmente el asesor HTTP de Load Balancer. Funciona de una
* forma muy simple: se emite una petición de envío: una petición de cabecera HTTP.
* Una vez que se recibe la respuesta, el método getLoad finaliza, indicando a la
* base del asesor que detenga la medición del tiempo de la petición. Entonces el
* método finaliza. La información devuelta no se analiza; la carga se basa en el
* tiempo necesario en realizar las operaciones de envío y recepción.
*/
package CustomAdvisors;
import com.ibm.internet.nd.advisors.*;
public class ADV_sample extends ADV_Base implements ADV_MethodInterface
{
String COPYRIGHT =
"(C) Copyright IBM Corporation 1997, All Rights Reserved.\n";
static final String ADV_NAME = "Sample";
static final int ADV_DEF_ADV_ON_PORT = 80;
static final int ADV_DEF_INTERVAL = 7;
// Nota: la mayoría de los protocolos de servidor requieren un retorno de
// carro ("\r") y un salto de línea ("\n") al final de los mensajes.
// Si es así, inclúyalos en la serie aquí.
static final String ADV_SEND_REQUEST =
"HEAD / HTTP/1.0\r\nAccept: */*\r\nUser-Agent: " +
"IBM_Load_Balancer_HTTP_Advisor\r\n\r\n";
/**
* Constructor.
*
* Parámetros: Ninguno; pero el constructor de ADV_Base tiene varios parámetros
* que deben pasarse.
*
*/
public ADV_sample()
{
super( ADV_NAME,
"2.0.0.0-03.27.98",
ADV_DEF_ADV_ON_PORT,
ADV_DEF_INTERVAL,
"", // no se utiliza
false);
super.setAdvisor( this );
}
/**
* ADV_AdvisorInitialize
*
* Se inicia cualquier inicialización específica del asesor que debe tener lugar
* después de la base del asesor. Este método sólo se invoca una vez y
* normalmente no se utiliza.
*/
public void ADV_AdvisorInitialize()
{
return;
}
/**
* getLoad()
*
* La base del asesor llama a este método para completar la operación del
* asesor, basándose en detalles específicos del protocolo. En este ejemplo del
* asesor, sólo es necesario emitir un sólo envío y recepción; si es necesario
* usa una lógica más compleja, se pueden emitir varios envíos y recepciones.
* Por ejemplo, una respuesta puede recibirse y analizarse. Basándose en la
* información que se obtiene, se podría emitir otro envío y recepción.
*
* Parámetros:
*
* - iConnectTime - La carga actual relativa al intervalo de tiempo que ha
* tardado en llevarse a cabo la conexión con el servidor en
* el puerto especificado.
*
* - caller - Una referencia a la clase base del asesor donde los métodos
* que proporciona Load Balancer van a realizar peticiones TCP,
* principalmente envíos y recepciones.
*
* Resultados:
*
* - La carga, un valor expresado en milisegundos, que puede añadirse a la
* carga existente o que puede sustituir a la misma, según lo
* determina el distintivo "replace" del constructor.
*
* Cuánto mayor sea la carga, más tiempo se necesitará para que el servidor
* responda; por lo tanto, menor será el peso dentro de Load Balancer.
*
* Si el valor es negativo, se da por supuesto un error. Un error de un asesor
* indica que el servidor al que el asesor intenta llegar no es accesible y
* que se ha identificado como inactivo. Load Balancer no intentará equilibrar la
* carga en un servidor que está inactivo. Load Balancer reanudará el equilibrio
* de carga en el servidor cuando se reciba un valor positivo.
*
*/
public int getLoad(int iConnectTime, ADV_Thread caller)
{
int iRc;
int iLoad = ADV_HOST_INACCESSIBLE; // -1
// Enviar petición TCP
iRc = caller.send(ADV_SEND_REQUEST);
if (iRc >= 0)
{
// Realizar una recepción
StringBuffer sbReceiveData = new StringBuffer("");
iRc = caller.receive(sbReceiveData);
/**
* En una modalidad de asesor (el distintivo "replace" es false), la carga
* devuelta es 0 o 1, lo que indica que el servidor está activo o inactivo.
* Si la recepción es satisfactoria, se devuelve una carga de cero, lo
* que indica que se va a usar la carga incluida dentro del asesor base.
*
* De lo contrario (el distintivo "replace" es true), devuelva el valor de
* carga que desee.
*/
if (iRc >= 0)
{
iLoad = 0;
}
}
return iLoad;
}
} // Final de - ADV_sample
En este apéndice se describe cómo establecer una configuración de alta disponibilidad de 2 niveles combinando las posibilidades de dos componentes de Load Balancer (el componente Dispatcher y el componente CBR) junto con Caching Proxy.
A continuación se detalla la configuración de máquina servidor para la Figura 46:
En la Figura 46 se muestra una representación básica de varios servidores (EdgeServer1, EdgeServer2, EdgeServer3) que equilibran la carga entre varios servidores Web finales. El componente CBR utiliza Caching Proxy para reenviar peticiones según el contenido del URL a los servidores Web finales. El componente Dispatcher su utiliza para equilibrar la carga de componentes CBR entre los servidores EdgeServers. Se utiliza la función de alta disponibilidad del componente Dispatcher para asegurarse de que continúen las peticiones a los servidores finales aún cuando la máquina primaria de alta disponibilidad (EdgeServer1) diera un error en algún momento.
Instrucciones básicas de configuración:
Caching ON CacheMemory 128000 K ReversePass /* http://websrvA.empresa.com/* http://www.empresa.com/*
Archivos de configuración de ejemplo:
Los archivos de configuración de ejemplo siguientes son similares a los archivos que se crean cuando se establece una configuración de Edge Components como se detalla en la Figura 46. Los archivos de configuración de ejemplo representan los archivos para los componentes Dispatcher y CBR de Load Balancer. En la configuración de ejemplo, se utiliza un solo adaptador Ethernet para cada una de las máquinas EdgeServer y todas las direcciones se representan dentro de una subred privada. Los archivos de configuración de ejemplo utilizan las siguientes direcciones IP para las máquinas especificadas:
Archivo de configuración de ejemplo para el componente Dispatcher en EdgeServer primario de alta disponibilidad:
dscontrol executor start dscontrol cluster add 192.168.1.11 primaryhost 192.168.1.10 dscontrol port add 192.168.1.11:80 dscontrol server add 192.168.1.11:80:edgeserver1 address 192.168.1.10 dscontrol server add 192.168.1.11:80:edgeserver2 address 192.168.1.20 dscontrol server add 192.168.1.11:80:edgeserver3 address 192.168.1.30 dscontrol manager start manager.log 10004 dscontrol highavailability heartbeat add 192.168.1.10 192.168.1.20 dscontrol highavailability backup add primary auto 4567
Archivo de configuración de ejemplo para el componente CBR en los EdgeServers:
cbrcontrol set loglevel 1 cbrcontrol executor start cbrcontrol cluster add 192.168.1.11 cbrcontrol port add 192.168.1.11:80 cbrcontrol server add 192.168.1.11:80:webserverA address 192.168.1.71 cbrcontrol server add 192.168.1.11:80:webserverB address 192.168.1.72 cbrcontrol server add 192.168.1.11:80:webserverC address 192.168.1.73 cbrcontrol rule add 192.168.1.11:80:webA_rule type content pattern (URI=*WSA*)|(URI=*wsA*) priority 21 cbrcontrol rule useserver 192.168.1.11:80:webA_rule webserverA cbrcontrol rule add 192.168.1.11:80:webB_rule type content pattern (URI=/WS_B*) priority 22 cbrcontrol rule useserver 192.168.1.11:80:webB_rule webserverB cbrcontrol rule add 192.168.1.11:80:webC_rule type content pattern URI=*webC* priority 23 cbrcontrol rule useserver 192.168.1.21:80:webC_rule webserverC
Esta información se ha desarrollado para productos y servicios proporcionados en los Estados Unidos.
Es posible que IBM no ofrezca los productos, servicios o funciones que se tratan en este documento en otros países. Consulte el representante de IBM de su localidad para obtener información acerca de los productos y servicios que están disponibles actualmente en su localidad. Cualquier referencia que se haga a un producto, programa o servicio de IBM no implica que sólo se pueda utilizar dicho producto, programa o servicio de IBM. En su lugar, se puede utilizar cualquier producto, programa o servicio funcionalmente equivalente que no vulnere ningún derecho de propiedad intelectual de IBM. Sin embargo, es responsabilidad del usuario evaluar y verificar el funcionamiento de cualquier producto, programa o servicio que no sea de IBM.
IBM puede tener patentes o aplicaciones pendientes de patente que conciernan al tema
descrito en este documento. La posesión de este documento no le da ninguna licencia
sobre estas patentes. Puede enviar preguntas acerca de licencias por escrito a:
IBM Director of Licensing
IBM Corporation
500 Columbus Avenue
Thornwood, NY 10594
Estados Unidos
Para preguntas acerca de licencias referentes a información de doble byte (DBCS), póngase
en contacto con el Departamento de propiedad intelectual de
IBM de su país o envíe sus preguntas por escrito a:
IBM World Trade Asia Corporation
Licensing
2-31 Roppongi 3-chome, Minato-ku
Tokyo 106, Japón
El siguiente párrafo no se aplica al Reino Unido ni a ningún otro país donde estas disposiciones no coincidan con la legislación local:
INTERNATIONAL BUSINESS MACHINES CORPORATION LE PROPORCIONA ESTE DOCUMENTO "TAL CUAL", SIN GARANTÍAS DE NINGÚN TIPO, NI EXPLÍCITAS NI IMPLÍCITAS, INCLUIDAS, AUNQUE SIN LIMITARSE A LAS MISMAS, LAS GARANTÍAS O CONDICIONES IMPLÍCITAS DE NO INFRACCIÓN, COMERCIALIZACIÓN O ADECUACIÓN A UN PROPÓSITO DETERMINADO. Algunas legislaciones no contemplan la exclusión de garantías, explícitas o implícitas en algunas transacciones, por lo que puede haber usuarios a los que no les afecte dicha regla.
Esta publicación puede contener imprecisiones técnicas o errores tipográficos. Se realizan cambios periódicos en la información aquí contenida; estos cambios se incorporarán en nuevas ediciones o en el documento. IBM se reserva el derecho de realizar mejoras y/o cambios en los productos y/o programas descritos en esta publicación en cualquier momento sin previo aviso.
Cualquier referencia en esta información a sitios Web que no son de IBM se proporciona solamente para su comodidad y no equivale de ninguna manera a una aprobación de esos sitios Web. El material de dichos sitios Web no forma parte del material correspondiente a este producto IBM y el uso de estos sitios Web se realiza bajo riesgo del usuario.
IBM puede utilizar o distribuir cualquier información que el usuario le proporcione de la manera que considere adecuada sin incurrir en ninguna obligación con el usuario.
Los usuarios autorizados de este programa que deseen tener información sobre éste
con el propósito de posibilitar: (i) el intercambio de información entre programas creados
independientemente y otros programas (incluyendo éste) y (ii) la utilización mutua de la
información que se ha intercambiado, deben ponerse en contacto con:
IBM Corporation
Attn.: G7IA./503.
P.O. Box 12195
3039 Cornwallis Rd.
Research Triangle Park, N.C. 27709-2195
Estados Unidos
Es posible que esta información esté disponible, sujeta a los términos y condiciones adecuados, y que en algunos casos incluya el pago de una tarifa.
El programa con licencia descrito en este documento y todos los materiales con licencia disponibles para el mismo son proporcionados por IBM bajo los términos del acuerdo IBM International Program License Agreement o cualquier acuerdo equivalente entre nosotros.
Los datos sobre rendimiento aquí contenidos se han determinado en un entorno controlado. Por tanto, los resultados obtenidos en otros entornos operativos pueden variar de forma significativa. Es posible que algunas medidas se hayan tomado en sistemas de nivel de desarrollo y no existe ninguna garantía de que dichas medidas se repitan en sistemas disponibles a nivel general. Además, es posible que algunas medidas se hayan estimado mediante extrapolación. Los resultados reales pueden variar. Los usuarios de este documento deben verificar los datos aplicables para su entorno específico.
La información referente a productos que no son de IBM se ha obtenido de los suministradores de estos productos, sus anuncios publicados u otras fuentes disponibles para el público. IBM no ha probado estos productos y no puede confirmar la precisión del rendimiento, compatibilidad y otras afirmaciones relacionadas con productos que no son de IBM. Las preguntas acerca de las posibilidades de productos que no son de IBM deben dirigirse a los suministradores de estos productos.
Todas las declaraciones referentes a acciones e intenciones futuras de IBM pueden cambiar o ser retiradas sin aviso previo y solamente representan objetivos.
Esta información contiene ejemplos de datos e informes utilizados en operaciones comerciales diarias. Para ilustrarlos de la forma más completa posible, los ejemplos pueden incluir nombres de particulares, empresas, marcas y productos. Todos estos nombres son ficticios y cualquier parecido con nombres y direcciones utilizadas por una empresa de negocios real es mera coincidencia.
Si consulta esta información en copia de software, muchas de las fotografías y las ilustraciones en color no aparecerán.
Los siguientes términos son marcas registradas o marcas comerciales de IBM Corporation en Estados Unidos y/o en otros países.
AFS
AIX
DFS
IBM
iSeries(TM)
NetView
OS/2
Redbooks(TM)
RS/6000(R)
SecureWay
ViaVoice
WebSphere
zSeries(R)
Java y todas las marcas registradas y logotipos basados en Java son marcas registradas de Sun Microsystems, Inc. en Estados Unidos y/o en otros países.
Microsoft, Windows, Windows NT y el logotipo de Windows son marcas registradas de Microsoft Corporation en los Estados Unidos y/o en otros países.
Intel (TM), Intel Inside (logotipos), MMX(TM) y Pentium(R) son marcas registradas de Intel Corporation en los Estados Unidos y/o en otros países.
UNIX es una marca registrada de The Open Group en los Estados Unidos y en otros países.
Linux es una marca registrada de Linus Torvalds en los Estados Unidos y en otros países.
Otros nombres de empresas, productos o servicios pueden ser marcas registradas o marcas de servicio de terceros.