異なるサブネット上の2つのノードでのIPフェイルオーバー：2番目のノードから仮想IPにpingを実行できませんか？

冗長フェイルオーバーをセットアップします Redmine ：

別のインスタンスが問題なく2番目のサーバーにインストールされました
MySQL（Redmineと同じマシンで実行）はマスターマスターレプリケーションとして構成されました

それらは異なるサブネット（192.168.3.xと192.168.6.x）にあるため、 VIPArip が唯一の選択肢のようです。

/etc/ha.d/ha.cf on node1

logfacility none
debug 1
debugfile /var/log/ha-debug
logfile /var/log/ha-log
autojoin none
warntime 3
deadtime 6
initdead 60
udpport 694
ucast eth1 node2.ip
keepalive 1
node node1
node node2
crm respawn

/etc/ha.d/ha.cf on node2：

logfacility none
debug 1
debugfile /var/log/ha-debug
logfile /var/log/ha-log
autojoin none
warntime 3
deadtime 6
initdead 60
udpport 694
ucast eth0 node1.ip
keepalive 1
node node1
node node2
crm respawn

crm configure show：

node $id="6c27077e-d718-4c82-b307-7dccaa027a72" node1
node $id="740d0726-e91d-40ed-9dc0-2368214a1f56" node2
primitive VIPArip ocf:heartbeat:VIPArip \
        params ip="192.168.6.8" nic="lo:0" \
        op start interval="0" timeout="20s" \
        op monitor interval="5s" timeout="20s" depth="0" \
        op stop interval="0" timeout="20s" \
        meta is-managed="true"
property $id="cib-bootstrap-options" \
        stonith-enabled="false" \
        dc-version="1.0.12-unknown" \
        cluster-infrastructure="Heartbeat" \
        last-lrm-refresh="1338870303"

crm_mon -1：

============
Last updated: Tue Jun  5 18:36:42 2012
Stack: Heartbeat
Current DC: node2 (740d0726-e91d-40ed-9dc0-2368214a1f56) - partition with quorum
Version: 1.0.12-unknown
2 Nodes configured, unknown expected votes
1 Resources configured.
============

Online: [ node1 node2 ]

 VIPArip    (ocf::heartbeat:VIPArip):   Started node1

ip addr show lo：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope Host lo
    inet 192.168.6.8/32 scope global lo
    inet6 ::1/128 scope Host 
       valid_lft forever preferred_lft forever

Node1（192.168.3.x）から192.168.6.8にpingを実行できます。

# ping -c 4 192.168.6.8
PING 192.168.6.8 (192.168.6.8) 56(84) bytes of data.
64 bytes from 192.168.6.8: icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from 192.168.6.8: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 192.168.6.8: icmp_seq=3 ttl=64 time=0.059 ms
64 bytes from 192.168.6.8: icmp_seq=4 ttl=64 time=0.071 ms

--- 192.168.6.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.046/0.059/0.071/0.011 ms

ただし、node2（192.168.6.x）および外部から仮想IPにpingを実行することはできません。私は何か見落としてますか？

PS：次のようなものが得られた場合は、IP2UTIL=/sbin/ipリソースエージェントスクリプトで/usr/lib/ocf/resource.d/heartbeat/VIPAripを設定することをお勧めします。

6月5日11：08：10node1 lrmd：[19832]：情報：RA出力：（VIPArip：stop：stderr）2012/06/05_11：08：10エラー：無効なOCF_RESK EY_ip [192.168.6.8]

http://www.clusterlabs.org/wiki/Debugging_Resource_Failures

@ DukeLionへの返信：

どのルーターがRIPアップデートを受信しますか？

VIPAripリソースを起動すると、以下の構成ファイル（node1）でripdが実行されました。

/var/run/resource-agents/VIPArip-ripd.conf：

hostname ripd
password zebra
debug rip events
debug rip packet
debug rip zebra
log file /var/log/quagga/quagga.log
router rip
!nic_tag
 no passive-interface lo:0
 network lo:0
 distribute-list private out lo:0
 distribute-list private in lo:0
!metric_tag
 redistribute connected metric 3
!ip_tag
access-list private permit 192.168.6.8/32
access-list private deny any

show ip route：

Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, A - Babel,
       > - selected route, * - FIB route

K>* 0.0.0.0/0 via 192.168.3.1, eth1
C>* 127.0.0.0/8 is directly connected, lo
K>* 169.254.0.0/16 is directly connected, eth1
C>* 192.168.3.0/24 is directly connected, eth1
C>* 192.168.6.8/32 is directly connected, lo

sh ip rip status：

Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in 7 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interface is not set
    lo:0 filtered by private
  Incoming update filter list for all interface is not set
    lo:0 filtered by private
  Default redistribution metric is 1
  Redistributing: connected
  Default version control: send version 2, receive any version 
    Interface        Send  Recv   Key-chain
  Routing for Networks:
    lo:0
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
  Distance: (default is 120)

clusterheartbeatpacemakerquaggavirtual-ip

2012/06/05quanta

問題はクラスター構成ではなく、ルーティングアーキテクチャにあると思います。

VIPAripリソースエージェントは、ローカルクアッガを管理してルーティングアップデートを送信します。ただし、このルーティング更新を使用して、アクティブサーバーを指すようにルートを変更する必要もあります。それがどのように機能するかを説明しようと思います。

RIP HA

写真を見てください。 HA1とHA2は、quaggaが実行されているlinux-haクラスターメンバーです。青いルーターは、両方のネットワークリンクからRIPをリッスンします。

HA1でvipがアップすると、quaggaはRIPアップデートを青いルーターに送信します。 192.168.1.2ネクストホップを使用してルーティングテーブルにvipプレフィックスを追加します。

フェイルオーバーが発生すると、HA1でvipがダウンし、quaggaが完全に停止するため、更新は送信されません。青いルーターは、VIPがHA2で上昇しない場合でも、タイムアウト後にルーティングテーブルレコードを削除します。また、VIPがHA2で上昇すると、クアッガを開始し、ブルールーターは、192.168.2.2ネクストホップを使用してルーティングテーブルにレコードを追加します。

より複雑なネットワークトポロジでviparipを使用することは可能ですが、境界ルーターがネットワーク全体でルーティングの更新を取得することを確認してください。

2012/06/06DukeLion