vrrp ping de roteamento, mas não outro tráfego

Question

Eu tenho duas VMs executando o BusyBox (em ESX). Essas máquinas funcionam apenas como balanceadores de carga.

Estou usando caneta para fazer o balanceamento de carga em cada máquina que está funcionando bem. Mas quando eu ligo vrrpd ping funciona, mas nada mais faz.

Cada balanceador de carga tem 3 interfaces. Os IPs de gerenciamento estão em eth0, eth1 é para uma segunda configuração do balanceador de carga.

LBCO102A
10.3.16.96 - (eth0) Management IP
10.3.16.84 - (eth2) IP that pen uses

LBCO102B
10.3.16.94 - (eth0) Management IP
10.3.16.85 - (eth2) IP that pen uses

vrrpd usa 10.3.16.58

No LBCO102A, estou usando o seguinte para iniciar o vrrpd:

vrrpd -i eth2 -v 58 -p 100 10.3.16.58

No LBCO102B, estou usando o seguinte para iniciar o vrrpd:

vrrpd -i eth2 -v 58 -p 50 10.3.16.58

Eu posso conectar aos IPs 10.3.16.84 e 10.3.16.85 sem problemas na porta 80. Eu posso conectar os IPs de gerenciamento 10.3.16.94 e 10.3.16.96 sem problemas. Quando me conecto a 10.3.16.58, ele acaba. Nada é exibido no arquivo / var / run / messages, exceto que um é mestre e o outro não.

Alguém tem alguma idéia de por que o vrrpd não está empurrando o tráfego diferente de ping? Eu tenho três dessas configurações. Um no pop3, um no smtp e um no http. Nenhum deles trabalha para nada além de ping.

Aqui está o netstat - um de LBCO102A

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 10.3.16.107:110         0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:9999            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.84:80           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8889            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.107:110         10.3.17.30:53960        TIME_WAIT
tcp        0      0 10.3.16.96:22           10.3.30.154:1224        ESTABLISHED
tcp        0      0 10.3.16.107:110         10.3.17.30:54000        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54102        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54038        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:53959        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54001        TIME_WAIT
tcp        0      0 10.3.16.107:110         10.3.17.30:54101        TIME_WAIT
tcp        0      0 10.3.16.96:22           10.3.30.154:1097        ESTABLISHED
tcp        0      0 10.3.16.107:110         10.3.17.30:54037        TIME_WAIT
raw        0      0 0.0.0.0:112             0.0.0.0:*               0
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  7      [ ]         DGRAM                    983    /tmp/log
unix  2      [ ]         DGRAM                    1156708
unix  2      [ ]         DGRAM                    1156657
unix  2      [ ]         DGRAM                    1156524
unix  2      [ ]         DGRAM                    192729
unix  2      [ ]         DGRAM                    994

Aqui está o netstat -an do LBCO102B

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:9999            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.85:80           0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN
tcp        0      0 10.3.16.94:22           10.3.30.154:1118        ESTABLISHED
raw        0      0 0.0.0.0:112             0.0.0.0:*               0
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  6      [ ]         DGRAM                    981    /tmp/log
unix  2      [ ]         DGRAM                    188253
unix  2      [ ]         DGRAM                    179316
unix  2      [ ]         DGRAM                    179306
unix  2      [ ]         DGRAM                    988

Aqui está o que eu tenho em meus scripts de inicialização. (há mais nos scripts para verificar start / stop / restart) LBCO103A

echo -n "Starting eth2: "
ifconfig eth2 10.3.16.84 netmask 255.255.255.0 up
echo "OK"

echo -n "Starting vrrp-ascossrs101: "
vrrpd -i eth2 -v 58 -p 100 10.3.16.58
echo "OK"

echo -n "Starting pen-ascossrs101: "
/bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.84:80 10.3.16.56:80 10.3.16.57:80
echo "OK"

LBCO102B

echo -n "Starting eth2: "
ifconfig eth2 10.3.16.85 netmask 255.255.255.0 up
echo "OK"

echo -n "Starting vrrp-ascossrs101: "
vrrpd -i eth2 -v 58 -p 100 10.3.16.58
echo "OK"

echo -n "Starting pen-ascossrs101: "
/bin/pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.85:80 10.3.16.56:80 10.3.16.57:80
echo "OK"

    

Answer 1

Eu não usei caneta, então não tenho certeza de como isso funciona, mas posso ajudar.

Você pode executar o netstat -an e fornecer a saída por favor? Meu palpite seria caneta está vinculada ao eth2 IP, nem todos os endereços na caixa. Ele deve ser configurado para 0.0.0.0 para que ele escolha qualquer endereço que a caixa possua, ou o seu vrrpd masterscript deve ser executado para fazer com que a caneta se vincule a seu VIP. O que pode acontecer é que o masterscript tenha que lançar a própria pena já configurada para esperar que o vip seja vinculado à sua interface eth2.

Edite agora com a saída netstat: Ok, então aqui está o problema: LBCO102A tcp 0 0 10.3.16.84:80 0.0.0.0:* LISTEN

O 10.3.16.84:80 significa que você está vinculado apenas a 10.3.16.84 na porta 80, portanto, mesmo que o servidor tenha o VIP, ele não está escutando a porta 10.3.16.58.

Mais uma vez, não estou familiarizado com a caneta, mas assumindo que o primeiro endereço IP passado é a ligação: / bin / pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.84:80 10.3.16.56:80 10.3.16.57:80 poderia ser / bin / pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 0.0.0.0:80 10.3.16.56:80 10.3.16.57:80

O 0.0.0.0:80 significaria ligar-se a todos os endereços e todas as interfaces na caixa.

A outra alternativa pode ser usar: / bin / pen -C 8888 -X -l /var/log/ascossrs101.log -p /var/log/ascossrs101.pid 10.3.16.58:80 10.3.16.56:80 10.3.16.57:80

No entanto, duvido que isso funcione como está, porque quando o programa for iniciado, a VM não terá esse endereço IP, portanto, a caneta não poderá se vincular a ele explicitamente. Eu tentei olhar para a documentação do vrrpd, e não tenho certeza se isso pode ser feito, mas o freevrrp tem uma opção de masterscript, que basicamente executa um script quando ele assume um VIP. Assim, você simplesmente adicionaria o comando para iniciar a caneta como parte do masterscript, assim, quando a caixa tomar posse do VIP, ele lançará a caneta e o vinculará ao endereço IP do VIP.

    

Answer 2

ok, acho que tenho tudo funcionando agora. Foi uma combinação de coisas que eu consegui do @Kevin e algumas coisas que eu encontrei na net (há muito pouco sobre vrrpd).

Parece que o vrrpd dispara o servidor para ouvir o IP, então você não quer iniciar a interface com o IP. A interface precisa ter um IP, mas não o IP que o vrrp estará usando.

Meu próximo problema foi que eu tinha uma caneta trabalhando em um IP diferente do que o que vrrpd estava trabalhando. Acabei tendo a pena listada para todas as conexões na porta 80 em todos os IPs. Se você não fizer isso, se a caneta for inicializada e a máquina não for o balanceador de carga principal, a caneta morrerá porque o IP que está procurando não está lá.

Eu tinha configurado com caneta escutando em outro endereço IP, e assumi que vrrpd era outro balanceador de carga na frente disso. Acontece que o vrrpd apenas inicia o IP e o fecha.

Então, para recapitular o que eu acabei com isso.

LBCO102A
10.3.16.96 - eth0 (Management IP)
10.3.16.148 - eth1

LBCO102B
10.3.16.94 - eth0 (Management IP)
10.3.16.149 - eth1

Em seguida, o vrrpd em ambas as máquinas é configurado com o endereço 10.3.16.58 e a caneta nas duas máquinas é configurada com 0.0.0.0.

Ainda há mais testes para fazer, mas venho executando a caneta no modo de depuração e observando o arquivo / var / run / messages e, se reiniciar o vrrpd no nó ativo, ele se tornará passivo e o novo nó ativo começa a mostrar tráfego. O tempo dirá, mas parece promissor.

    

Answer 3

Apenas um palpite aqui. Você pode estar confuso com duas interfaces na mesma sub-rede. Você pode tentar criar uma sub-rede separada para a rede de gerenciamento.