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.