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

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

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

ではipmiプラグインを追加してみましょう。まずはpm01をフェンシングするためのリソース設定を追加します。

デフォルト値を使用するパラメータ(stonith-timeout, priority)については設定を省略しています。
primitive stonith1 stonith:external/ipmi \
	params \
		userid="ipmiuser1" \
		passwd="ipmipass1" \
		ipaddr="192.168.100.1" \
		hostname="pm01" \
		interface="lanplus" \
	op start interval="0s" timeout="60s" on-fail="restart" \
	op monitor interval="300s" timeout="60s" on-fail="restart" \
	op stop interval="0s" timeout="60s" on-fail="ignore"

"stonith1"は,このリソースを識別するIDで任意の文字列です。useridやpasswd, ipaddrには,IPMIボードに設定した情報を記述します。また,hostnameにはこの設定でフェンシングできるサーバ名 "pm01"を設定します。interfaceは,IPMIのバージョンに依存し,バージョン2.0の場合lanplus, バージョン1.5の場合lanを指定します。

同様にpm02をフェンシングするためのリソース設定を追加します。

primitive stonith2 stonith:external/ipmi \
	params \
		userid="ipmiuser2" \
		passwd="ipmipass2" \
		ipaddr="192.168.100.2" \
		hostname="pm02" \
		interface="lanplus" \
	op start interval="0s" timeout="60s" on-fail="restart" \
	op monitor interval="300s" timeout="60s" on-fail="restart" \
	op stop interval="0s" timeout="60s" on-fail="ignore"

コラム1:IPMIボードないけどちょっとSTONITH試したい!

Pacemakerリポジトリパッケージに入っているcluster-glue-libs-develというパッケージ に external/sshというプラグインが入っています。相手のサーバにパスフレーズなしでsshログインできるようにしておけば,このプラグインは相手のサーバにsshログインし,コマンドで電源を落としてくれます。ただしログインできないような故障だと動作できないのであくまでお試し用と考え,実際の環境で使うのは避けましょう。

その他,仮想環境ではXenに対応したxen0(本体同梱⁠⁠ やXen, KVMに対応したlibvirt(開発中)というプラグインもあります。

以下にsshプラグインを使う場合のリソース設定例を載せておきます。

primitive stonith1 stonith:external/ssh \
	params \
		livedangerously="yes" \
		hostlist="pm01" \
	op start interval="0s" timeout="60s" on-fail="restart" \
	op monitor interval="300s" timeout="60s" on-fail="restart" \
	op stop interval="0s" timeout="60s" on-fail="ignore"

primitive stonith2 stonith:external/ssh \
	params \
		livedangerously="yes" \
		hostlist="pm02" \
	op start interval="0s" timeout="60s" on-fail="restart" \
	op monitor interval="300s" timeout="60s" on-fail="restart" \
	op stop interval="0s" timeout="60s" on-fail="ignore"
sshプラグインを使用するには,DNSや/etc/hostsを利用して,pm01, pm02というホスト名が名前解決できるようにしておいてください。sshの通信経路はホスト名に割り当てられたIPが使用されますので,ホスト名にインターコネクト用LANのIPを割り当てないように注意してください。

以上の設定だけで一応STONITHリソースは起動しますが,これだけではSTONITHリソースがどのサーバで起動するかわかりません。Pacemakerは自分のサーバ上のSTONITHリソースで自分のサーバをフェンシングすることができないので,pm01をフェンシングするSTONITHリソースはpm02上で,pm02をフェンシングするSTONITHリソースはpm01上で起動するように制約設定を追加します。

location location-stonith1 stonith1 \
	rule 200: #uname eq pm02 \
	rule -INFINITY: #uname eq pm01

location location-stonith2 stonith2 \
	rule 200: #uname eq pm01 \
	rule -INFINITY: #uname eq pm02

200や-INFINITY(-1000000と同等)は優先度を表すスコア値と呼ばれるもので,上3行の意味を要約すると,先ほど設定したstonith1というリソースはホスト名pm02というサーバ上ではスコア値200になり,ホスト名pm01というサーバ上では-INFINITY,つまりリソース起動禁止となります。

以上で設定完了です。設定を反映させ,設定モードを終了します。

crm(live)configure# commit
crm(live)configure# exit

実際にSTONITHリソースが起動したかどうか確認してみましょう。

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

Online: [ pm01 pm02 ]

stonith1        (stonith:external/ipmi):        Started pm02
stonith2        (stonith:external/ipmi):        Started pm01

stonith1, stonith2が,pm02, pm01でStartedになり,無事意図したサーバで起動しました。

実際にインターコネクト通信のケーブルを全部抜いて,フェンシングが実行されれば成功です。通信断検知直後(スプリットブレイン状態時)は相手のサーバはUNCLEANという状態になり,フェンシングが成功するとOFFLINEになります。

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

Online: [ pm01 ]
OFFLINE: [ pm02 ]

stonith2        (stonith:external/ipmi):        Started pm01

なお,STONITHは通常のリソースの故障にも使うことができますので紹介しておきます。第2回の仮想IPの設定を例にすると,以下のような設定があったと思います。

primitive vip ocf:heartbeat:IPaddr2 \
        params ip="192.168.68.100" \
                nic="eth0" cidr_netmask="24" \
        op monitor interval="10s"

この"op" の設定には故障時の動作をon-failで定義することができます。たとえば以下のように op stop のon-failにfenceという設定をすると,リソースの停止失敗時に,STONITHでフェンシングすることできます。これによりフェイルオーバ中の中途半端な状態で止まってしまうことを防ぐことができます。第2回の設定と組み合わせてチャレンジしてみてください。

primitive vip ocf:heartbeat:IPaddr2 \
        params ip="192.168.68.100" \
                nic="eth0" cidr_netmask="24" \
        op start interval="0s" on-fail="restart" \
        op monitor interval="10s" on-fail="restart" \
        op stop interval="0s" on-fail="fence"

コラム2:補助プラグインって?

今回使用したipmiプラグインのように実際に電源を制御する実プラグイン以外に,電源を制御しない補助プラグインというものが存在します。では補助プラグインって何をしてくれるの?という疑問が湧くと思いますので,よく使われる補助プラグイン2つを紹介します。

STONITHは,スプリットブレインが発生した場合,各サーバが相手をフェンシングしようとするため,どちらのサーバが停止するかはタイミング次第です。そこで役に立つのがLinux-HA Japan提供のpm_extrasパッケージに含まれるstonith-helperプラグインです。このプラグインではあるパラメータに任意のコマンドを設定し,その戻り値によって処理を一時停止 (sleep実行)します。つまりこのプラグインを実プラグインの前に実行することで,タイミングを意図的にずらすことができるようになるわけです。その他に相手のサーバとつながっている全ネットワークインターフェースにpingを打ち,フェンシングの必要性可否を判断する機能も備えています。

2つ目は本体同梱のmeatwareというプラグインです。STONITHはフェンシングに失敗すると,成功するまでフェンシングを繰り返してしまいます。そういう場合ユーザが手動で電源を落とす必要がでてきます。ところがPacemakerはユーザが手動で電源を落としたことには気づいてくれないので,次の状態に遷移することができません。そこでmeatwareの出番です。meatwareはmeatclientコマンドが用意されており,このような状態に陥った時にユーザがこのコマンドを実行することで,Pacemakerにフェンシングが成功した旨を通知することができます。その結果次の状態に遷移することができるようになります。

図3

画像

著者プロフィール

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

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

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