たぶん期待通りの動作になりました。
要は、IPaddr2に渡すパラメータを調整すれば良いわけで、いろいろ見て、clone-max=1 と言うパラメータを、crm 設定ファイルに追加すれば良さそうと。で

group g-storage dlm lvmlockd
group vip-group vip
clone cl-storage g-storage \
meta interleave=true target-role=Started
clone vip-clone vip-group \
meta clone-max=1

のように書き換えたところ、たぶん期待通りの動作になりました。ノードを standby 状態にすると、IP アドレスが相手側に移動します。
なので、IPaddr2 の動作としては問題ないし、heartbeat としての動作も問題ないけれど、パラメータの設定がミソ、という感じです。この辺 SLES のドキュメントには無いので、もう少し追記してもらえればありがたかったかなと。

IP_CIP が yes になる条件が分かりました。
ソースを見ると、IPaddr2 の ip_init() 関数の中で、

    if [ "$IP_INC_GLOBAL" -gt 1 ] && ! ocf_is_true "$OCF_RESKEY_unique_clone_address"; then
            IP_CIP="yes"
            IP_CIP_HASH="${OCF_RESKEY_clusterip_hash}"

という行があるのですね。IP_CIP を yes にしているのはここだけです。で、IP_CIP を yes にする条件は、IP_INC_GLOBAL が2以上の時(1より大きいとき)、で、IP_INC_GLOBAL を設定しているのは、やはり ip_init() の始まりの方で、

    IP_INC_GLOBAL=${OCF_RESKEY_CRM_meta_clone_max:-1}
    IP_INC_NO=`expr ${OCF_RESKEY_CRM_meta_clone:-0} + 1`

という行の所。で、OCF_RESKEY_CRM_meta_clone_max を設定しているのは IPaddr2 内ではなくて、これを起動する heartbeat。情報は https://clusterlabs.org/projects/pacemaker/doc/2.1/Pacemaker_Administration/html/agents.html にあります。あとhttps://blog.drbd.jp/2017/12/advance_resource/ も参考になります。どうやら、OCF_RESKEY_CRM_meta_clone_max が2に設定されているみたいです。なので、iptables を動かすロジックに進んでしまったみたい。

openSUSE で動かないので、では、本家本元の Red Hat Enterprise Linux ではどうなのか、を調べてみました。RHEL では IPaddr2 からのメッセージは ocf_log という関数を使っているようで、add_interface() 関数内にある ocf_log に少し細工をして、実行コマンドと引数が表示されるようにしてみました。すると、

4月 04 21:38:17 rh9-a IPaddr2(ClusterIP)[467709]: INFO: Adding inet address 192.168.3.179/24 with broadcast address 192.168.3.255 to device ens18 ip -f inet addr add 192.168.3.179/24 brd 192.168.3.255 dev ens18
4月 04 21:38:17 rh9-a avahi-daemon[749]: Registering new address record for 192.168.3.179 on ens18.IPv4.
4月 04 21:38:17 rh9-a IPaddr2(ClusterIP)[467715]: INFO: Bringing device ens18 up ip link set ens18 up

と表示されていたんですね。つまり、RHEL では ip コマンドを使って IP アドレスを設定していると。
おそらく、どこかの引数で、ip コマンドを指定していると思うのですが、そこが分かれば RHEL と同じように openSUSE でも設定すれば、うまくいきそうです。

2025/4/5 追記
で、IPaddr2 にあっちこっち logger 入れて調べてみたら、

Apr 05 20:59:41 clvm-a root[7827]: ip_served cur_nic=,IP_CIP=yes,OCF_RESKEY_ip=192.168.3.169
Apr 05 20:59:41 clvm-a root[7828]: ip_saved return no
Apr 05 20:59:41 clvm-a root[7829]: ip_start: IP_CIP=yes,IP_STATUS=no
Apr 05 20:59:41 clvm-a root[7830]: IP_CIP=yes,ip_status=noq
Apr 05 20:59:41 clvm-a root[7833]: iptables-legacy -I INPUT -d 192.168.3.169 -i eth0 -j CLUSTERIP –new –

と言うトレース結果が。あれ、IP_CIP は IP アドレスじゃなくて yes が入っている! RHEL だとここには何も入らないか、IPアドレスのどちらか。なので、IP_CIP に yes が入ることがおかしい。でソースを読むと、IP_CIP が 空 じゃなくて、 ip_status が no だとすると、iptables を呼び出す模様。どうやら IP_CIP が yes なので誤動作した感じ。

openSUSE でSLES のマニュアルを見ながら、クラスタのテストをしています。clvm 環境ができたので、今度は仮想IP のテストをしようとしたらハマりました。

仮想IP の定義後、ノードを再起動すると、syslog に

Mar 23 12:28:31 clvm-a IPaddr2(vip)[3495]: ERROR: iptables failed
Mar 23 12:28:31 clvm-a pacemaker-execd[3148]: notice: vip start (call 25, PID 3394) exited with status 1 (iptables failed) (execution time 73ms)
Mar 23 12:28:31 clvm-a pacemaker-controld[3151]: notice: Result of start operation for vip on clvm-a: error (iptables failed)
Mar 23 12:28:31 clvm-a pacemaker-controld[3151]: notice: vip_start_0@clvm-a output [ iptables v1.8.7 (legacy): chain name not allowed to start with -'\n\nTryiptables -h’ or ‘iptables –help’ for more information.\nocf-exit-reason:iptables failed\n ]

調べて見たところ、crm から呼び出している IPaddr2モジュールの中で、iptables を呼び出し、それがエラーを出していました。どうも、openSUSE 15.6 にインストールされている iptables バージョン1.8.7 ではクラスタ関係の機能が無いのですね。それで動作しなかったという次第。

さて、どう対処したものか。

ことによるともうずいぶん前からあったのに気がついていなかっただけなのかもしれませんが、SLE についてのあなたの知識をチェックする簡単なプログラムが公開されています。

試してみるにはまず事前に Novell のアカウントを取得しておく必要がありますが、以下の5つのコース(いずれも英語)が用意されています。

• Novell SUSE Linux 10 Linux基本コース テクニカルスキルチェック
• Novell SUSE Linux 10 管理コース テクニカルスキルチェック
• Novell SUSE Linux 10 アドバンスド管理コース テクニカルスキルチェック
• Novell SUSE Linux 10 ネットワークサービスコース テクニカルスキルチェック
• Novell SUSE Linux 10 セキュリティコース テクニカルスキルチェック

念のためお断りしておくと、「 スキルチェックを完了することによって、 Novellあるいは、Novellパートナーから、Novell製品やサービスについてのコンタクトを許します。」ということですので、ご案内等が届くのがウザいと感じる方にはお薦めいたしませんが、興味のある方は「あなたの SUSE 理解度」をチェックされてみてはいかがでしょうか。…対象は SLE ということになっていますが、そのまま openSUSE にも当てはまることも多いと思います。

…ていうか、実は私もまだチャレンジしていなかったりするので、時間を見つけて試してみようと思ってます。

news.opensuse.org に流れた告知ですが、現在公開中の openSUSE 11.1 Beta1及び SUSE Linux Enterprise 11 Beta1(こちらは一般公開されていません) に含まれる Intel e1000e ネットワークカードドライバに深刻な不具合が発見されています。

e1000e ドライバ(e1000 ドライバなら問題はないとのこと)を使用するネットワークカードが付いているハードウェアをopenSUSE 11.1 Beta1 もしくは SUSE Linux Enterprise 11 Beta1 で起動した場合、最悪ネットワークカードを壊してしまう可能性もあります。

お使いのハードウェアに付いているネットワークカードが該当するかどうかは、上記からも辿れるこことかここあたりの情報を参照して確認してください。

もし Intel 製の Gigabit Eathernet Card が装着されていて、上記を参照しても該当しているか否か確認が取れないようでしたら、念のため openSUSE 11.1 Beta1 及び SUSE Linux Enterprise 11 Beta1 ではマシンを起動しないようにしておいたほうが良さそうです。

DRBD(Distributed Replicated Block Device)は、その名の通りネットワーク経由で複製を行ってくれるブロックデバイスです。ブロックデバイスですから、複製の単位はブロック単位で、デバイス上をどのような形式のファイルシステムが使っていても複製されます。

このDRBDですが、SLES10で標準的に提供されているパッケージはバージョン0.7で、最新版は8.x系に移っています。8.xはopenSUSE用のパッケージは存在しているのですが、SLES10用は開発元であるLINBIT社とサポート契約を締結しているユーザーにのみ提供されます。ですが、DRBはオープンソースでもあるので、ソースコードからビルドすることも可能です。大変かなと思いつつ、スタッフにSLES10でビルドしてもらったところ、思った以上にスンナリとインストールすることができました。さらにDRBDを使用する仮想マシンのライブマイグレーションも可能でした（現時点では準仮想化のみサポート）。

導入のコツとしては、あらかじめDRBD用の領域をLVMで確保しておき、LVを切り出してDRBDに組み込む、という方法でしょうか。

10月3日(金)4日(土)に開催されるオープンソースカンファレンス2008 Tokyo/Fall内で、弊社（日本仮想化技術株式会社）のブースにてデモを行っておりますので、是非ご来場ください。