Planificación de Dispatcher

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:

Nota:
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.

Consideraciones de planificación

Dispatcher consta de las funciones siguientes:

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.

Métodos de reenvío

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).

Direccionamiento a nivel de MAC de Dispatcher (método de reenvío mac)

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.

NAT/NAPT de Dispatcher (método de reenvío nat)

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):

direccionamiento basado en contenido de Dispatcher (método de reenvío cbr)

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.

Nota:
La norma de contenido se configura en el componente Dispatcher del mismo modo que se configura en el componente CBR. Dispatcher puede utilizar la norma de contenido para el tráfico HTTP. No obstante, el componente CBR puede utilizar la norma de contenido para los dos tipos de tráfico, HTTP y HTTPS (SSL).

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):

Nota:
La característica de réplica del registro de conexión de alta disponibilidad (que asegura que no se eliminará una conexión de cliente cuando una máquina Dispatcher de reserva se haga con el control de la máquina primaria) no se admite con direccionamiento basado en contenido de Dispatcher.

Pasos de ejemplo para configurar los métodos de reenvío nat o cbr de Dispatcher

Figura 12. Ejemplo para utilizar los métodos de reenvío nat o cbr de Dispatcher
Configuración para utilizar el 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.

Creación de particiones del servidor: servidores lógicos configurados con un servidor físico (dirección IP)

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.

Creación de particiones del servidor con asesores HTTP o HTTPS

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).

Ejemplo para configurar un servidor físico en servidores lógicos

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).

Alta disponibilidad

Alta disponibilidad sencilla

Figura 13. Ejemplo de un Dispatcher utilizando la alta disponibilidad simple
Dispatcher utilizando la configuración de alta disponibilidad simple

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.

Alta disponibilidad mutua

Figura 14. Ejemplo de Dispatcher con alta disponibilidad mutua
Dispatcher con una configuración de 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.

Nota:
Las dos máquinas deben configurar sus conjuntos de clústeres compartidos del mismo modo. Es decir, los puertos utilizados y los servidores bajo cada puerto deben ser idénticos en las dos configuraciones.

Si desea información sobre cómo configurar la alta disponibilidad y la alta disponibilidad mutua, consulte el apartado Alta disponibilidad.