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:
Dispatcher también ofrece asesores que no intercambian información específica de protocolo, por ejemplo el asesor de DB2 que informa sobre el estado de los servidores de DB2 y el asesor de ping que notifica si el servidor responde a un ping. Para obtener una lista completa de asesores, consulte Lista de asesores.
También tiene la opción de escribir sus propios asesores (consulte Crear asesores personalizados (personalizables)).
El uso de asesores es opcional, pero se recomienda.
Las tres funciones clave de Dispatcher (ejecutor, gestor y asesores) interactúan para equilibrar y entregar las solicitudes entrantes entre servidores. Junto con las solicitudes 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 de un programa de supervisión de sistema, por ejemplo 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 y la disponibilidad del servidor y, a continuación, 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 solicitud 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. Si desea más información, consulte el apartado dscontrol port — configurar puertos.
Limitación de Linux: los sistemas Linux emplean un modelo basado en host para 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 al utilizar servidores zSeries o S/390: existen limitaciones al utilizar servidores zSeries o S/390 que tienen tarjetas OSA (Open System Adapter). Consulte Problema: en Linux, limitaciones cuando se utilizan servidores zSeries o S/390 que disponen de tarjetas OSA (Open System Adapter) para ver métodos alternativos posibles.
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 por omisión 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 sistema principal único que puede configurar en la máquina de Dispatcher. Dispatcher utiliza la dirección de retorno como su dirección de origen cuando equilibra la carga de la petición del cliente al servidor. Esto asegura que el servidor devuelve el paquete a la máquina de Dispatcher en lugar de enviar el paquete directamente al cliente. (Dispatcher reenviará el paquete IP al cliente). Debe especificar el valor de dirección de retorno cuando añade el servidor. 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 igual que la del clúster, la del servidor o la 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 norma 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 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 norma de tipo "content" (contenido). Cuando configure la norma de contenido, especifique la serie de búsqueda "patrón" y un conjunto de servidores en la norma. Cuando se procesa una nueva petición de entrada, esta norma 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 norma.
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 antememoria 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 debe establecerse en un valor que no sea 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 direccionamiento basado en contenido de Dispatcher (vea también 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 norma de tipo content (contenido). Si desea más información sobre el tipo de norma content, consulte el apartado Utilización de normas 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 norma de contenido (patrón).
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, solicitudes de base de datos, etc. Ahora Load Balancer proporciona la posibilidad de particionar un servidor específico de clúster y 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 solicitud de base de datos, o si no se ejecuta nada.
El particionamiento de servidor permite a Load Balancer detectar, por ejemplo, que el servicio HTML está sirviendo páginas rápidamente, pero que la conexión de base de datos 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 solicitudes JSP y HTML al servidor.
Para obtener más información sobre el parámetro advisorrequest, consulte Configuración del asesor HTTP o HTTPS utilizando la opción de solicitud 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, si define el servidor para representar un servidor particionados, debe proporcionar una dirección de servidor que se pueda resolver para el servidor físico en el parámetro address del mandato dscontrol server add. Consulte 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 solicitudes.
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 solicitudes HTML) y "B" (que gestiona solicitudes GIF). El servidor 1.1.1.3 se divide en 2 servidores lógicos de partición: "C" (que gestiona las solicitudes HTML) y "D" (que gestiona las solicitudes JSP). El servidor 1.1.1.4 se divide en 2 servidores lógicos de partición: "E" (que gestiona las solicitudes GIF) y "F" (gestiona las solicitudes JSP).
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.
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.