Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

3.2. LVS con enrutado directo

As mentioned in Sección 1.4.2, “Enrutado directo”, direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well.
Capas de red
En una configuración LVS de enrutado directo, el enrutador LVS necesita recibir las solicitudes entrantes y enrutarlas al servidor real apropiado para que sean procesadas. Los servidores reales necesitan luego enrutar directamente la respuesta al cliente. Por ejemplo, si el cliente está en internet y envía el paquete a través del enrutador LVS al servidor real, éste debe ser capaz de dirigirse directamente al cliente a través de Internet. Esta tarea puede llevarse a cabo configurando una puerta de enlace (gateway) para que el servidor real pase paquetes a Internet. Cada servidor real en el grupo de servidores puede tener su propia puerta de enlace separada (y cada puerta de enlace con su propia conexión a Internet), permitiendo una mayor tasa de transferencia y escalabilidad. Sin embargo, para configuraciones LVS típicas, los servidores reales pueden comunicarse a través de una puerta de enlace (y una conexión de red).

Importante

No se recomienda utilizar un enrutador LVS como puerta de enlace para los servidores reales ya que esto conllevaría innecesarias complejidades de configuración y cargas de red en el enrutador LVS. Además, el cuello de botella del enrutado NAT que se trataba de evitar es introducido nuevamente.
Hardware
Los requerimientos de hardware de un sistema LVS que utiliza enrutado directo es similar a otras topologías LVS. Mientras que el enrutador LVS debe ejecutar Red Hat Enterprise Linux para procesar la solicitud entrante y ejecutar balance de carga para los servidores reales, éstos no necesitan ser máquinas Linux para funcionar correctamente. Los enrutadores LVS necesitan uno o dos NIC cada uno (dependiendo de si hay un enrutador de respaldo). Puede utilizar dos NIC para facilitar la configuración y para separar el tráfico — las solicitudes entrantes son manejadas por un NIC y los paquetes enrutados al servidor real por el otro.
Ya que los servidores reales evitan el enrutador LVS y envían los paquetes salientes directamente al cliente, se requiere una puerta de enlace a Internet. Para alcanzar máximo rendimiento y disponibilidad, cada servidor real puede estar conectado a su propia ruta de enlace. Ésta tiene su propia conexión dedicada a la red en la cual el cliente está conectado (por ejemplo, Internet o Intranet).
Software
There is some configuration outside of Piranha Configuration Tool that needs to be done, especially for administrators facing ARP issues when using LVS via direct routing. Refer to Sección 3.2.1, “Enrutado directo y arptables_jf or Sección 3.2.2, “Enrutado directo y iptables for more information.

3.2.1. Enrutado directo y arptables_jf

In order to configure direct routing using arptables_jf, each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs.
Al usar el método arptables_jf, las aplicaciones podrían vincularse a cada VIP o puerto que el servidor real esté sirviendo. Por ejemplo, el método arptables_jf permite la ejecución de múltiples instancias de Apache HTTP Server vinculadas explícitamente a diferentes VIP del sistema. Hay también varias ventajas de rendimiento cuando se utiliza arptables_jf en vez de iptables.
Sin embargo, al utilizar el método arptables_jf no se puede configurar las VIP para que sean iniciadas durante el arranque con las herramientas de configuración estándar de Red Hat Enterprise Linux.
Para configurar cada servidor real para ignorar las solicitudes ARP para cada una de las direcciones IP virtuales, ejecute los siguientes pasos:
  1. Crear las entradas ARP para cada dirección IP virtual en cada servidor real (el real_ip es el IP que el nodo director utiliza para comunicarse con el servidor real; frecuentemente este es el IP vinculado a eth0):
    arptables -A IN -d <virtual_ip> -j DROP
    arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
    
    Esto hará que los servidores reales ignoren todas las solicitudes ARP para la dirección IP virtual y cambia la IP virtual con la IP real en cualquier solicitud ARP saliente. El único servidor que debe responder a solicitudes ARP para cualquier VIP es el nodo LVS activo.
  2. Una vez esta tarea ha sido completada en cada servidor real, se deben salvar las entradas ARP escribiendo el siguiente comando en cada servidor real:
    service arptables_jf save
    chkconfig --level 2345 arptables_jf on
    El comando chkconfig causará que el sistema recargue la configuración de arptables durante el periodo de arranque — antes de iniciar la red.
  3. Configure la dirección IP Virtual en todos los servidores reales con ifconfig para crear un alias IP. Por ejemplo:
    # ifconfig eth0:1 192.168.76.24 netmask 255.255.252.0 broadcast 192.168.79.255 up
    O utilizando la utilidad iproute2 ip, por ejemplo:
    # ip addr add 192.168.76.24 dev eth0
    Como se mencionó anteriormente las direcciones IP virtuales no pueden ser configuradas para ser iniciadas durante el arranque con las herramientas de configuración de Red Hat. Para solucionar este inconveniente, ubique estos comandos en /etc/rc.d/rc.local.
  4. Configure Piranha for Direct Routing. Refer to Capítulo 4, Configuración de los enrutadores LVS con la Piranha Configuration Tool for more information.