web-dev-qa-db-ja.com

iptablesCLUSTERIPが機能しない

ここ を説明するいくつかの要件があります。説明したように、私たちは成功せずに彼らを満足させようとしました。簡単な情報は次のとおりです。

要件は次のとおりです。

  1. 高可用性
  2. 負荷分散

現在の構成：

サーバー＃1：10.17.243.11ごとに1つの静的（実）IPサーバー＃2：10.17.243.12クラスターごとに1つの静的（実）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

10.17.243.15にpingを実行しようとしても、応答がありません。また、Webサービス（ポート8080のTomcat）にもアクセスできません。ただし、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

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の「不完全な」HWアドレスを解決するために、エントリを手動で追加しました。

linuxiptablesipclusterhigh-availability
1
Rad

私は多かれ少なかれ同一であるウェブ上のすべての指示に従いましたが、明らかに1つの欠けているステップがあります。私のシステム（ソフトウェアまたはハードウェアの仕様を含む）が原因かどうかはわかりません。とにかく、Michael Schwartzkopff（ Linxu Magazine ）がWebで見つけた指示に基づいて、両方のマシンで以下を実行する必要があります（少なくとも私の場合）：

ip addr add 10.17.243.15/24 dev eth0

Webの指示とその追加の手順に従うと、ARPキャッシュに「不完全な」エントリがなくなり、すべてが正常に機能します。

ありがとうマイケルシュワルツコフ:)

1
Rad

私たちはあなたと同じことをしたいと思っています：両方のサーバーに割り当てられた仮想IPを持っています。

CentOS7で実行しています。

だから私たちはこれを行います：

  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にpingを実行できます（ただし、Cluster01とCluster02からのみ）。 arpキャッシュにHWアドレスを手動で追加します。

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のWebページにアクセスできますが、VirtualIPでは機能しません...

0
Djé Djé