iptable CLUSTERIP não funciona

Question

Temos alguns requisitos que explicam aqui . Nós tentamos satisfazê-los sem sucesso, como descrito. Aqui está a breve informação:

Aqui estão os requisitos:

1. Alta disponibilidade
2. Balanceamento de carga

Configuração atual:

Servidor # 1: um IP estático (real) para cada 10.17.243.11 Servidor # 2: um IP estático (real) para cada 10.17.243.12 Cluster (virtual e compartilhado entre todos os servidores) IP: 10.17.243.15

Eu tentei usar o CLUSTERIP para ter o IP do cluster da seguinte forma:

on the server #1
iptables -I INPUT -i eth0 -d 10.17.243.15 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1

on the server #2  
iptables -I INPUT -i eth0 -d 10.17.243.15 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 2  

Quando tentamos fazer o ping em 10.17.243.15, não há resposta. E o serviço da Web (tomcat na porta 8080) também não está acessível. No entanto, conseguimos obter os pacotes nos dois servidores usando o TCPDUMP.

Algumas informações úteis:
iptables roules (iptables -L -n -v):

Chain INPUT (policy ACCEPT 21775 packets, 1470K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 CLUSTERIP  all  --  eth0   *       0.0.0.0/0            10.17.243.15         CLUSTERIP hashmode=sourceip clustermac=01:00:5E:00:00:20 total_nodes=2 local_node=1 hash_init=0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 14078 packets, 44M bytes)
 pkts bytes target     prot opt in     out     source               destination

Mensagens de log:

... kernel: [    7.329017] e1000e: eth3 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
... kernel: [    7.329133] e1000e 0000:05:00.0: eth3: 10/100 speed: disabling TSO
... kernel: [    7.329567] ADDRCONF(NETDEV_CHANGE): eth3: link becomes ready
... kernel: [   71.333285] ip_tables: (C) 2000-2006 Netfilter Core Team
... kernel: [   71.341804] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
... kernel: [   71.343168] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
... kernel: [  108.456043] device eth0 entered promiscuous mode
... kernel: [  112.678859] device eth0 left promiscuous mode
... kernel: [  117.916050] device eth0 entered promiscuous mode
... kernel: [  140.168848] device eth0 left promiscuous mode

TCPDUMP durante o ping:

tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:11:55.335528 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.17.243.1 >     10.17.243.15: ICMP echo request, id 16162, seq 2390, length 64
12:11:56.335778 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)              
    10.17.243.1  >     10.17.243.15: ICMP echo request, id 16162, seq 2391, length 64
12:11:57.336010 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.17.243.1  >     10.17.243.15: ICMP echo request, id 16162, seq 2392, length 64
12:11:58.336287 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 
    10.17.243.1  >     10.17.243.15: ICMP echo request, id 16162, seq 2393, length 64

Cache ARP:

Address                  HWtype  HWaddress           Flags Mask            Iface
10.17.243.12             ether   00:90:0B:24:CA:58   C                     ETH01
10.17.243.11             ether   00:90:0B:24:CA:68   C                     ETH01
10.17.243.15                     (incomplete)                              ETH01

E não há resposta de ping como eu disse. Alguém sabe qual parte eu perdi?
Agradecemos antecipadamente.

UPDATE: Para resolver o HWaddress "incompleto" para o IP do cluster no cache do ARP, adicionamos manualmente a entrada.

    

Answer 1

Embora eu tenha seguido todas as instruções na web que são mais ou menos idênticas, mas aparentemente há um passo faltando. Não tenho certeza se é por causa do meu sistema (incluindo especificações de software ou hardware). De qualquer forma, baseado na instrução que encontrei na web por Michael Schwartzkopff ( Revista Linxu ), é necessário executar o seguinte em ambas as máquinas (pelo menos no meu caso):

ip addr add 10.17.243.15/24 dev eth0

Se você seguir as instruções na web + essa etapa extra, não haverá entrada "incompleta" no cache ARP e tudo funcionará bem.

Obrigado Michael Schwartzkopff:)

    

Answer 2

Queremos fazer as mesmas coisas que você: ter um IP virtual atribuído a ambos os servidores.

Estamos rodando no CentOS 7.

Então fazemos isso:

1. Cluster01: 10.10.10.11
2. Cluster02: 10.10.10.12
3. VirtualIP: 10.10.10.10

No cluster 01:

iptables -I INPUT -i ens160 -d 10.10.10.10 -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 1
ip addr add 10.10.10.10/24 dev ens160

No cluster 02:

iptables -I INPUT -d 10.66.66.10 -i ens160  -j CLUSTERIP --new --hashmode sourceip --clustermac 01:00:5E:00:00:20 --total-nodes 2 --local-node 2
ip addr add 10.10.10.10/24 dev ens160

Podemos fazer ping no VirtualIP (mas apenas a partir do Cluster01 & Cluster02). Adicionamos manualmente o endereço HW no cache de arp:

arp -i ens160 -s 10.10.10.10 01:00:5E:00:00:20 


# iptables -L -n -v

    Chain INPUT (policy ACCEPT 2221 packets, 151K bytes)
     pkts bytes target     prot opt in     out     source               destination
        0     0 CLUSTERIP  all  --  ens160 *       0.0.0.0/0            10.10.10.10          CLUSTERIP hashmode=sourceip clustermac=01:00:5E:00:00:20 total_nodes=2 local_node=2 hash_init=0

    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
     pkts bytes target     prot opt in     out     source               destination

    Chain OUTPUT (policy ACCEPT 1536 packets, 1412K bytes)
     pkts bytes target     prot opt in     out     source               destination

Em ambos os servidores, temos o arquivo /proc/net/ipt_CLUSTERIP/10.10.10.10

Da minha estação de trabalho, posso acessar a minha página da Web no Cluster01 & Cluster02 mas no VirtualIP não funciona ...