У нас есть некоторые требования, которые объяснили здесь. Мы пытались удовлетворить их без любого успеха, как описано. Вот краткая информация:
Вот требования:
Текущая конфигурация:
Сервер № 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, мы добавили вручную запись.
Хотя я выполнил все инструкции в Интернете, которые более или менее идентичны, но, очевидно, есть один пропущенный шаг. Я не уверен, что это из-за моей системы (включая характеристики программного или аппаратного обеспечения). В любом случае, основываясь на инструкции, которую я нашел в сети Майклом Шварцкопффом ( Linxu Magazine ), необходимо выполнить следующее на обеих машинах (по крайней мере, в моем случае):
ip addr add 10.17.243.15/24 dev eth0
Если вы будете следовать инструкции в сети + этот дополнительный шаг, в кэше ARP не будет «неполной» записи, и все работает нормально.
Спасибо, Майкл Шварцкопфф :)
Мы хотим делать то же, что и вы: иметь виртуальный IP-адрес, назначенный обоим серверам.
Мы работаем на CentOS 7.
Итак, делаем это:
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
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 он не работает ...