Pacemakerでかんたんクラスタリング体験してみよう!

第3回 Pacemakerでいろいろ設定してみよう![構築応用編]

この記事を読むのに必要な時間:およそ 8 分

sfex

STONITHはPacemaker本体の機能とプラグインで実現していますが,排他制御を実現するためのリソースエージェント(RA)もいくつか存在します。その代表がsfexです。これは共有ディスクを使用している環境で使用できます。

sfexは起動されると共有ディスク上のsfex専用パーティションに所有権を定期的に書き込みます。この情報を元に,相手のサーバが生きているかどうかを判断します。つまり,相手のサーバのsfexが起動している時に自分のサーバのsfexを起動しようとするとリソース故障状態になります。もちろんsfexは単なるリソースエージェントに過ぎないので,有効に活用するにはsfexを二重起動させたくないリソースと同じグループに入れ,常にsfexを最初に起動するようにします。

なお,sfexや下記で紹介するVIPcheckだけでは,STONITHのようにリソース停止失敗時のサービス停止を防ぐことができないので,STONITHと併用することをお勧めします。なお,以下では説明を簡単にするためにSTONITHは無効にしています。

では,sfexを設定してみましょう。図4のように,ファイルシステムのマウント・アンマウントを実現するFilesystem RAとsfex RAを使い共有ディスクのダブルマウントを防いでみます。

図4 sfexの構成

図4 sfexの構成

まずはsfex専用パーティションの用意です。サイズは1024バイトもあれば十分です。fdiskやpartedコマンド等を使って共有ディスク上に用意しておいてください。今回は/dev/sdb1とします。ファイルシステムを作成する必要はなく,代わりに以下のコマンドで初期化します。-n は排他制御したいサーバ間で使う識別番号です。

# sfex_init -n 1 /dev/sdb1

次にリソースの設定を行います。今回,Filesystemリソースは,/dev/sdb2を/mnt/tmpにext3としてマウントするようにしたいと思います。

(どちらかのサーバ上で実行)
# mke2fs -j /dev/sdb2
(各サーバで実行)
# mkdir /mnt/tmp

各サーバでマウントができるか確認しておいてください。その際各サーバで同時にマウント(ダブルマウント)しないように注意してください。では,一旦Pacemakerの設定はクリアします。

(各サーバで実行)
# /etc/init.d/heartbeat stop
(各サーバで実行)
# rm -f /var/lib/heartbeat/crm/*
# /etc/init.d/heartbeat start

Pacemaker起動後,crmコマンドで設定していきます

# crm configure
crm(live)configure#

以下の設定を投入します。

property $id="cib-bootstrap-options" \
        no-quorum-policy="ignore" \
        stonith-enabled="false" \
        startup-fencing="false"

primitive sfex ocf:heartbeat:sfex \
        params \
                index="1" \
                device="/dev/sdb1" \
        op start interval="0s" timeout="120s" on-fail="restart" \
        op monitor interval="10s" timeout="60s" on-fail="restart" \
        op stop interval="0s" timeout="60s" on-fail="block"

primitive filesystem ocf:heartbeat:Filesystem \
        params \
                fstype="ext3" \
                device="/dev/sdb2" \
                directory="/mnt/tmp" \
        op start interval="0s" timeout="60s" on-fail="restart" \
        op monitor interval="10s" timeout="60s" on-fail="restart" \
        op stop interval="0s" timeout="60s" on-fail="block"

group group1 sfex filesystem

sfexのindexパラメータにsfex_init実行時に設定した識別番号を,deviceパラメータに用意したsfex専用パーティションを設定します。またgroupの設定により,リソースの起動順番はsfex, filesystemとなり,sfexが起動成功しない限りファイルシステムがマウントされることはありません。

ではcommitで設定反映します。

crm(live)configure# commit

以下のようにリソースが起動すれば成功です。

# crm_mon
============
省略
============

Online: [ pm01 pm02 ]

 Resource Group: group1
     sfex       (ocf::heartbeat:sfex):  Started pm01
     filesystem (ocf::heartbeat:Filesystem):    Started pm01

ではここでインターコネクト通信を全て抜いて,スプリットブレインを発生させて見ましょう。今回はSTONITHが動いていないので,各サーバで以下のような表示になります。

pm01側の表示
============
省略
Current DC: pm01 (519bb7a2-3c31-414a-b6b2-eaef36a09fb7) - partition with quorum
省略
============

Online: [ pm01 ]
OFFLINE: [ pm02 ]

 Resource Group: group1
     sfex       (ocf::heartbeat:sfex):  Started pm01
     filesystem (ocf::heartbeat:Filesystem):    Started pm01
pm02側の表示
pm02# crm_mon
============
省略
Current DC: pm02 (8c93dc22-a27e-409b-8112-4073de622daf) - partition with quorum
省略
============

Online: [ pm02 ]
OFFLINE: [ pm01 ]


Failed actions:
    sfex_start_0 (node=pm02, call=4, rc=1, status=complete): unknown error

pm01側では今までリソースが起動していたので,そのまま起動し続けますが,pm02側ではsfexの起動故障が発生(Faild actionsのsfex_start_0の行)し,filesystemの起動を見事抑止してくれました。なお,あえてヘッダ部分の表示を残していますが,このようにpm01側では自分がクラスタ全体の指揮している(DC)と表示され,pm02側も自分がDCだと表示されます。これがスプリットブレインになっている証拠になります。

VIPcheck

最後に,排他制御を実現するもう一つのリソースエージェントVIPcheckを紹介します。これはLinux-HA Japan提供のpm_extrasパッケージに入っており,主に仮想IP(IPaddrやIPaddr2 RA)を使用している場合に使用可能です。

動作イメージはsfexと同じで,sfexの場合は共有ディスクを参照して相手の状態を確認しますが,VIPcheckは仮想IPを参照(ping)して相手の状態を確認します。具体的には仮想IPに対してpingを打ち,応答があれば相手のサーバでリソースが起動していると判断し,自分のサーバのVIPcheckは起動できずリソース故障状態になります。

図5 VIPcheckの構成

図5 VIPcheckの構成

なお,sfexの場合,共有ディスクのケーブルが抜けて,ディスクにアクセスできない場合に起動できないのに対し,VIPcheckはネットワークケーブルが抜けてpingに応答しない場合に起動成功するので,残念ながらsfexに比べて信頼性は低いと言えるでしょう。リソース設定イメージはsfexと同じなので,今回は紹介だけにとどめておきます。

まとめ

第3回では構築応用編としてスプリットブレイン対策の機能,設定例を紹介しました。

最初からいろいろと設定された複雑な構成を見ると,Pacemakerの設定は難しそうなイメージを抱く人が多いのですが,このように一つ一つの機能を分解して見ると結構簡単ではなかったでしょうか。いよいよ次回からは運用編として,いろいろな故障を起こしてみたり,その時の復旧方法を紹介したりする予定ですのでお楽しみに。

著者プロフィール

松尾隆利(まつおたかとし)

NTTオープンソースソフトウェアセンタ所属。

Pacemakerに初めて触れて早1年。Heartbeat時代のxml設定の苦労をあまり知らないまま育つ。現在はLinux-HA Japanオリジナル機能の開発や,Webページのメンテナンス,オープンソースカンファレンス出展などに携わる。