iptable CLUSTERIP не работает

У нас есть некоторые требования, которые объяснили здесь. Мы пытались удовлетворить их без любого успеха, как описано. Вот краткая информация:

Вот требования:

  1. Высокая доступность
  2. Выравнивание нагрузки

Текущая конфигурация:

Сервер № 1: один статический (реальный) IP для каждых 10.17.243.11 Серверов № 2: один статический (реальный) IP для каждых 10.17.243.12 Кластеров (виртуальный и общий для все серверы) IP: 10.17.243.15

Я пытался использовать CLUSTERIP, чтобы иметь кластерный IP следующим:

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  

Когда мы пытаемся проверить с помощью ping-запросов 10.17.243.15 нет никакого ответа. И веб-сервис (кот на порте 8080) не доступен также. Однако нам удалось получить пакеты на обоих серверах при помощи TCPDUMP.

Немного полезной информации:
iptable 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

Сообщения журнала:

... 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 при проверке с помощью 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

Кэш 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

И нет никакого ответа ping, как я сказал. Кто-либо знает который пропущенная первая часть?
Заранее спасибо.

ОБНОВЛЕНИЕ: Для разрешения "неполного" HWaddress для кластерного IP в кэше ARP, мы добавили вручную запись.

1
задан 13 April 2017 в 15:14
2 ответа

Хотя я выполнил все инструкции в Интернете, которые более или менее идентичны, но, очевидно, есть один пропущенный шаг. Я не уверен, что это из-за моей системы (включая характеристики программного или аппаратного обеспечения). В любом случае, основываясь на инструкции, которую я нашел в сети Майклом Шварцкопффом ( Linxu Magazine ), необходимо выполнить следующее на обеих машинах (по крайней мере, в моем случае):

ip addr add 10.17.243.15/24 dev eth0

Если вы будете следовать инструкции в сети + этот дополнительный шаг, в кэше ARP не будет «неполной» записи, и все работает нормально.

Спасибо, Майкл Шварцкопфф :)

1
ответ дан 4 December 2019 в 00:20

Мы хотим делать то же, что и вы: иметь виртуальный IP-адрес, назначенный обоим серверам.

Мы работаем на CentOS 7.

Итак, делаем это:

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

В кластере 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

В кластере 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

Мы можем проверить связь с VirtualIP (но только с Cluster01 и Cluster02). Мы вручную добавляем HW-адрес в кеш 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

На обоих серверах у нас есть файл /proc/net/ipt_CLUSTERIP/10.10.10.10

С моей рабочей станции я могу получить доступ к своей веб-странице на Cluster01 & Cluster02, но на VirtualIP он не работает ...

0
ответ дан 4 December 2019 в 00:20

Теги

Похожие вопросы