☰

Equilibrio de carga de múltiples conexiones a Internet de Linux con manejo de fallas

tag-icon • tag-icon linux networking gentoo routing
Equilibrio de carga de múltiples conexiones a Internet de Linux con manejo de fallas

Tengo dos conexiones ISP y necesito un equilibrio de carga automático entre ellas. También necesito manejar conexiones fallidas (no usar una que no funcione).

El primer enlace es una conexión PPTP ( ppp0), el segundo es Ethernet habitual. El sistema es Gentoo Linux.

Actualmente, logré un equilibrio básico con ip route, pero parece que no funciona muy bien. Esto es lo que he usado:

ip rule $ADD from $IP1 table rt_link1
ip rule $ADD fwmark 1 lookup rt_link1
ip rule $ADD from $IP2 table rt_link2
ip rule $ADD fwmark 2 lookup rt_link2
$NET2 dev eth2 src $IP2 table rt_link2
default via GW2 table rt_link2
$NET2 dev eth2 src $IP2
$NET1 dev ppp0 src $IP1 table rt_link1
default via GW1 table rt_link1
$NET1 dev ppp0 src $IP1
default scope global nexthop via $GW1 weight 1 nexthop via $GW2 dev eth2 weight 1

Respuesta1

Como ex miembro del equipo central del proyecto LVS, desaconsejaría encarecidamente el uso de esta tecnología para equilibrar múltiples conexiones a Internet; de hecho, casi puedo garantizarles que no funcionará como se esperaba.

Ahora, el manejo de enlaces de proveedores fallidos a menudo se denomina detección de puerta de enlace inactiva (DGD) y, a veces, detección de inaccesibilidad de vecino (NUD). Según RFC816 y RFC1122, hay varias formas de realizar DGD, sin embargo, solo he visto alrededor de 3 de ellas en la naturaleza (de unviejo post mioa la lista de correo de LVS):

  • La información de la capa de enlace que detecta e informa de manera confiable fallas del host (por ejemplo, mensajes de destino muerto de ARPANET) debe usarse como consejo negativo.
  • Un mensaje de redireccionamiento ICMP desde una puerta de enlace en particular debe usarse como un consejo positivo sobre esa puerta de enlace.
  • Los paquetes que llegan desde una dirección de capa de enlace particular son evidencia de que el sistema en esta dirección está vivo. Sin embargo, convertir esta información en consejos sobre puertas de enlace requiere asignar la dirección de la capa de enlace a una dirección IP y luego comparar esa dirección IP con las puertas de enlace a las que apunta el caché de ruta. Probablemente esto sea prohibitivamente ineficiente.

Cuando dejé el desarrollo activo de redes del kernel de Linux en 2006, todavía no había una decisión definitiva sobre cómo implementar los cambios de estado de NUD. Un amigo mío y desarrollador principal de LVS, Julian Anastasov, necesitaba resolver su desafío en 2002. Entonces, una noche se sentó y escribió una versión funcional del DGD para enrutamiento estático agregando el estado NUD al FIB (información directa). base). Puedes encontrar su parche.aquíy la documentacionaquí,aquíyaquí. Esto debería brindarle mucha información sobre su futura búsqueda para abordar esta tarea no trivial. Veo que los parches todavía se utilizan ampliamente y, por lo tanto, se mantienen actualizados con los kernels más recientes. Es posible que desee comenzar con un guión como el siguiente (escrito porRobert Kurjata):

#!/bin/bash
# This script is done by : Robert Kurjata Sep, 2003.
# feel free to use it in any useful way

# CONFIGURATION
IP=/sbin/ip
PING=/bin/ping

#--------------- LINK PART -----------------
# EXTIFn - interface name
# EXTIPn - outgoing IP
# EXTMn  - netmask length (bits)
# EXTGWn - outgoing gateway
#-------------------------------------------

# LINK 1
EXTIF1=eth2
EXTIP1=
EXTM1=
EXTGW1=

# LINK 2
EXTIF2=eth1
EXTIP2=
EXTM2=
EXTGW2=

#ROUTING PART
# removing old rules and routes

echo "removing old rules"
${IP} rule del prio 50 table main
${IP} rule del prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule del prio 202 from ${EXTIP2}/${EXTM2} table 202
${IP} rule del prio 221 table 221
echo "flushing tables"
${IP} route flush table 201
${IP} route flush table 202
${IP} route flush table 221
echo "removing tables"
${IP} route del table 201
${IP} route del table 202
${IP} route del table 221

# setting new rules
echo "Setting new routing rules"

# main table w/o default gateway here
${IP} rule add prio 50 table main
${IP} route del default table main

# identified routes here
${IP} rule add prio 201 from ${EXTIP1}/${EXTM1} table 201
${IP} rule add prio 202 from ${EXTIP2}/${EXTM2} table 202

${IP} route add default via ${EXTGW1} dev ${EXTIF1} src ${EXTIP1} proto static table 201
${IP} route append prohibit default table 201 metric 1 proto static

${IP} route add default via ${EXTGW2} dev ${EXTIF2} src ${EXTIP2} proto static table 202
${IP} route append prohibit default table 202 metric 1 proto static

# mutipath
${IP} rule add prio 221 table 221

${IP} route add default table 221 proto static \
            nexthop via ${EXTGW1} dev ${EXTIF1} weight 2\
            nexthop via ${EXTGW2} dev ${EXTIF2} weight 3

${IP} route flush cache

while : ; do
  ${PING} -c 1 ${EXTGW1}
  ${PING} -c 1 ${EXTGW2}
  sleep 60
done

Además de eso, puede consultar la opción de ejecutar protocolos de enrutamiento dinámico.

Respuesta2

Utilice LVS junto con lvs-kiss. O algo similar.

LVS es básicamente el ìpvsadmcomando. El único inconveniente de ese equilibrador de carga es que no monitorea. Por lo tanto, necesita un programa que haga eso por usted y elimine el enlace inactivo de su configuración (y lo vuelva a agregar vivo).

ldirectordde la pila de latidos del corazón podría haber otra adición de lvs (en lugar de lvs-kiss).

información relacionada