IPMPを組んでみた！と言うわけで記事にする。

今回の構成はこんな感じです。他のサーバと同じように、1つのGigabitスイッチに2つのインタフェースを接続します。チーミングだとIPアドレスはひとつでよいのだけど、IPMPでは検査用アドレスを使うことで、IPレベルの疎通到達性をちゃんと見てくれるモードが昔からある方式らしく。

通常は、各検査IPアドレスからデフォルトゲートウェイに対してICMPをぶん投げ、インタフェースの到達性を確認するようです。

もし、稼動系の経路が途絶した場合は、待機系へ切り替わると。5回以上のパケット不到達でその状態を検知する仕組みのようです。何となく、IPベースのクラスタハートビートをやってるような感じに見えますね。

まず、ルーティングテーブルの確認から。インストール時にデフォルトゲートウェイを明示的に定めていたので、こうなっています。Gとかかれているのがゲートウェイアドレスでして、デフォルトゲートウェイに対してICMP確認をしながらステータスチェックする仕様となっています。

# netstat -rn

Routing Table: IPv4
Destination           Gateway           Flags  Ref     Use     Interface
——————– ——————– —– —– ———- ———
default              192.168.100.254      UG        1          8
192.168.100.0        192.168.100.207      U         1         31 bge0
192.168.100.0        192.168.100.207      U         1          0 bge0:1
192.168.100.0        192.168.100.207      U         1          8 bge1
224.0.0.0            192.168.100.207      U         1          0 bge0
127.0.0.1            127.0.0.1            UH        5        131 lo0

今回の設定は以下のとおりとなりました。まず、/etc/hostname.bge0の設定。グループ名は各NIC同じ名前にしとく必要があります。とりあえず今回「ybkmp(YaBaKeiMultiPath)」としてみました。どーでもいいことだけど。

yabakei  netmask + broadcast + group ybkmp up addif 192.168.100.107 deprecated -failover netmask + broadcast + up
(1行で書くこと。)

ここで、「yabakei」と書いているのは、hostsの以下の記述を参照しています。

192.168.100.207 yabakei loghost

よって、「192.168.100.207」と書いているのと同義と考えて良いようです。

続いて、/etc/hostname.bge1の設定。明示的にNICがStandbyであることを定義しています。

192.168.100.117 netmask + broadcast + deprecated group ybkmp -failover standby up

これらをそれぞれ保存できたら、再起動を実施。

reboot

これで再起動後、IPMP構成となってサービスIPが公開されると。

# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.100.207 netmask ffffff00 broadcast 192.168.100.255
groupname ybkmp
ether 0:14:4f:8e:6f:f2
bge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 192.168.100.107 netmask ffffff00 broadcast 192.168.100.255
bge1: flags=39040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,FAILED,STANDBY> mtu 1500 index 3
inet 192.168.100.117 netmask ffffff00 broadcast 192.168.100.255
groupname ybkmp
ether 0:14:4f:8e:6f:f3

起動時、こんなログがでてました。

Jul  8 23:02:24 yabakei in.mpathd[186]: NIC failure detected on bge1 of group ybkmp
Jul  8 23:02:41 yabakei in.mpathd[186]: Improved failure detection time 76062 ms on (inet bge0) for group “ybkmp”
Jul  8 23:02:41 yabakei in.mpathd[186]: Improved failure detection time 38031 ms on (inet bge0) for group “ybkmp”
Jul  8 23:02:42 yabakei in.mpathd[186]: Improved failure detection time 19015 ms on (inet bge0) for group “ybkmp”
Jul  8 23:02:43 yabakei in.mpathd[186]: Improved failure detection time 9507 ms on (inet bge0) for group “ybkmp”
Jul  8 23:02:44 yabakei in.mpathd[186]: Improved failure detection time 5000 ms on (inet bge0) for group “ybkmp”

これは、どうも初回起動時においては監視間隔の調整が自動的に行われるみたいです。あたしゃ設定で「障害検知されるまでの時間」を5000msに設定していたのですが、最初はシステムの負荷が高いと言うこともあり、とても大きな値に障害検知時間を変更するみたいです。

ちょうどLinuxでBondingを覚えだしてた頃、ちゃんと経路保障が出来るNIC冗長化が何とかして出来ないかとアレコレ苦心していたことを思い出します。arp監視方式ならいけるか？と思いきや、隣接ノードがいたら意味が無いじゃーんと嘆いたり。こういう機能がBonding機能にもあればなーなんて思ったり。きっとこれにもこれで色々制約とかあるんでしょうけどねー。それにしても考え方が面白いなーと思ったしだい。

とりあえずこちらの環境では無事に動きました。ひとまずはえがったえがった。その内気が向いたら障害発生時の挙動なんかを見てみようかと思います。