Alternativas de alias de bucle de retorno de Linux cuando se utiliza el reenvío MAC de Load Balancer

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

  1. Utilice un kernel que no publique las direcciones. Esta es la opción preferida, ya que no provoca una actividad adicional por paquete y no requiere una reconfiguración por kernel.
  2. Utilice tablas IP para redirigir todo el tráfico de clúster entrante hacia el host local. Si utiliza este método, no configure el adaptador de bucle de retorno con un alias. En su lugar, utilice el mandato:
     # iptables -t nat -A PREROUTING -d $CLUSTER_ADDRESS -j REDIRECT
    Este mandato hace que los sistemas Linux realicen una conversión de direcciones de red (NAT) de destino en cada paquete, convirtiendo la dirección de 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.
  3. Aplique la versión 1.2.0 o posterior del módulo noarp. El código fuente del kernel debe estar disponible y configurado correctamente; también deben estar disponibles las herramientas de desarrollo (gcc, gnu make, etc.). Cada vez que se amplía el kernel se debe compilar e instalar el módulo. Está disponible en http://www.masarlabs.com/noarp/. Puesto que el código del kernel por sí mismo no se modifica, es menos intrusiva que la solución número 4 (indicada más abajo) y es menos propensa a errores. También debe configurarse antes de crear un alias de dirección de clúster en el bucle de retorno. Por ejemplo:
    # modprobe noarp
    # noarpctl add $CLUSTER_ADDRESS dir_primaria_nic
    donde 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
    Nota:
    Para las configuraciones con ubicación compartida de alta disponibilidad, se debe indicar noarpctl adds y dels en los scripts go*. Esto asegura que el sistema Load Balancer activo pueda utilizar ARP para la dirección del clúster y que el sistema Load Balancer en espera, que actúa como servidor, no empiece a recibir de forma accidental (es decir, de forma indeterminada) todo el tráfico del clúster.
  4. Obtenga el parche Julian en el siguiente sitio Web: http://www.ssi.bg/~ja/#hidden. Siga las instrucciones de distribuciones para aplicar el parche y compilar un kernel apto para su uso con dicha distribución. Si es un sistema Load Balancer de alta disponibilidad con ubicación compartida, asegúrese de que uname -r coincida con el kernel suministrado por la distribución, así como que empieza con el archivo .config del kernel de distribución. Después de compilar, instalar y ejecutar el kernel con el parche oculto Julian, siga las instrucciones especificadas bajo la primera solución descrita para habilitar el parche.
    Nota:
    Si se ejecuta un kernel personalizado, puede tener consecuencias en el soporte de la distribución.