iptable CLUSTERIP 不起作用

我們有一些在這裡解釋的要求。我們試圖讓他們滿意，但沒有如所描述的那樣取得任何成功。以下是簡要資訊：

以下是要求：

1. 高可用性
2. 負載均衡

目前配置：

伺服器 #1：每個 10.17.243.11 一個靜態（真實）IP 伺服器＃2：每個 10.17.243.12 一個靜態（真實）IP 集群（虛擬並在所有伺服器之間共享） 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 時沒有回复。並且 Web 服務（埠 8080 上的 tomcat）也無法訪問。但是，我們設法通過使用 TCPDUMP 在兩台伺服器上獲取數據包。

一些有用的資訊：

iptable 規則（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

ping 時的 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記憶體：

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 回复。有誰知道我錯過了哪一部分？

提前致謝。

更新：為了解決 ARP 記憶體中集群 IP 的“不完整”硬體地址，我們手動添加了條目。

儘管我遵循了網路上或多或少相同的所有說明，但顯然缺少一個步驟。我不確定這是因為我的系統（包括軟體或硬體規格）。無論如何，根據我在網上找到的 Michael Schwartzkopff（Linxu 雜誌）的說明，有必要在兩台機器上執行以下命令（至少在我的情況下）：

ip addr add 10.17.243.15/24 dev eth0

如果您按照網路上的說明+該額外步驟，則 ARP 記憶體上不會有“不完整”條目，並且一切正常。

謝謝邁克爾·施瓦茨科普夫 :)

引用自：https://serverfault.com/questions/623221