iptable CLUSTERIP не работает
У нас есть некоторые требования, которые объясняются здесь. Мы пытались удовлетворить их без какого-либо успеха, как описано. Вот краткая информация:
Вот требования:
- Высокая доступность
- Балансировки нагрузки
Текущая конфигурация:
Сервер № 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
Когда мы пытаемся пинговать 10.17.243.15, ответа нет. И веб-сервис (tomcat на порту 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 во время пинга:
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 Cache:
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
И нет ответа пинг, как я уже сказал. Кто-нибудь знает, какую часть я пропустил?
Заранее спасибо.
ОБНОВЛЕНИЕ: Чтобы разрешить "неполный" HWaddress для IP-адреса кластера в ARP-кэше, мы добавили запись вручную.
2 ответа
Хотя я следовал всем инструкциям в Интернете, которые более или менее идентичны, но, видимо, есть один пропущенный шаг. Я не уверен, что это из-за моей системы (включая спецификации программного или аппаратного обеспечения). В любом случае, основываясь на инструкции, которую я нашел в Интернете от Михаэля Шварцкопфа ( Linxu Magazine), необходимо выполнить следующее на обеих машинах (по крайней мере, в моем случае):
ip addr add 10.17.243.15/24 dev eth0
Если вы будете следовать инструкции в Интернете + этот дополнительный шаг, в ARP-кэше не будет "неполной" записи, и все будет работать нормально.
Спасибо Михаил Шварцкопфф:)
Мы хотим сделать то же самое, что и вы: иметь виртуальный IP-адрес, назначенный обоим серверам.
Мы работаем на CentOS 7.
Итак, мы делаем это:
- Cluster01: 10.10.10.11
- Cluster02: 10.10.10.12
- 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 это не работает...