☰

linux múltiplas conexões de internet balanceamento de carga com tratamento de falhas

tag-icon • tag-icon linux networking gentoo routing
linux múltiplas conexões de internet balanceamento de carga com tratamento de falhas

Tenho duas conexões ISP e preciso de balanceamento automático de carga entre elas. Também preciso lidar com conexões com falha (não usar uma que não funcione).

O primeiro link é uma conexão PPTP ( ppp0), o segundo é a Ethernet usual. O sistema é Gentoo Linux.

Atualmente consegui balanceamento básico com ip route, mas parece que não está funcionando muito bem. Aqui está o que eu usei:

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

Responder1

Como ex-membro da equipe principal do projeto LVS, eu desaconselho fortemente o uso desta tecnologia para equilibrar múltiplas conexões de internet; na verdade, quase posso garantir que não funcionará como esperado.

Agora, o tratamento de links de provedores com falha é frequentemente chamado de detecção de gateway morto (DGD) e, às vezes, chamado de detecção de inacessibilidade de vizinho (NUD). De acordo com RFC816 e RFC1122, existem várias maneiras de realizar DGD, no entanto, só vi cerca de 3 delas na natureza (de umpostagem antiga minhapara a lista de discussão do LVS):

  • As informações da camada de enlace que detectam e relatam falhas de host de maneira confiável (por exemplo, mensagens ARPANET Destination Dead) devem ser usadas como aconselhamento negativo.
  • Uma mensagem de redirecionamento ICMP de um gateway específico deve ser usada como um conselho positivo sobre esse gateway.
  • Os pacotes que chegam de um determinado endereço da camada de enlace são evidências de que o sistema nesse endereço está ativo. No entanto, transformar essas informações em conselhos sobre gateways requer mapear o endereço da camada de enlace em um endereço IP e, em seguida, verificar esse endereço IP em relação aos gateways apontados pelo cache de rota. Isto é provavelmente proibitivamente ineficiente.

Quando deixei o desenvolvimento ativo da rede do kernel Linux em 2006, ainda não havia uma decisão definitiva sobre como implementar mudanças de estado NUD. Um amigo meu e principal desenvolvedor do LVS, Julian Anastasov, precisava resolver seu desafio em 2002. Então, uma noite ele sentou-se e escreveu uma versão funcional do DGD para roteamento estático adicionando o estado NUD ao FIB (forward information base). Você pode encontrar o patch deleaquie a documentaçãoaqui,aquieaqui. Isso deve lhe fornecer muitas informações sobre sua busca futura para abordar essa tarefa não trivial. Vejo que os patches ainda são muito usados ​​e, portanto, mantidos atualizados com os kernels recentes. Você pode querer começar com um script como o seguinte (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

Além disso, você pode conferir a opção de executar protocolos de roteamento dinâmico.

Responder2

Use LVS em conjunto com lvs-kiss. Ou algo semelhante.

LVS é basicamente o ìpvsadmcomando. A única desvantagem desse balanceador de carga é que ele não monitora. Então você precisa de um programa que faça isso para você e remova o link morto da sua configuração (e adicione-o de volta ao vivo novamente).

ldirectordda pilha de batimentos cardíacos pode haver outra adição de lvs (em vez de lvs-kiss).

informação relacionada