月刊あんどりゅーくん(6月号)

ここ最近、あんどりゅーくんよりふぃりっぷくんが荒ぶってましたなあ。

ということで、今月はDRBDのリリースノートを一生懸命読んでみました。

リリースといってもまだ rc なので、正式版が出た段階で改めてご紹介したいと思います。

今月のお題はこちらのお二つ。

リリース情報
知恵袋

1.リリース情報

drbd-8.4.0rc1のリリース

DRBD 8.4.0rc1がリリースされました。

8.3系からの大きな変更点は、こちら。

The most noticeable change is the support for multiple replicated volumes in a single DRBD connection.

8.3系では、一本の同期LANで複数のリソース（ブロックデバイス）を同期させたい場合

リソースごとに同期用のポート番号を変える必要があったのですが

8.4系では「volumes」というパラメータを使って、同一の同期LANかつ同一のポート番号で

複数のリソースを同期することができるようになりました。

「プロトコルAを使用して遠隔地への同期処理を実行しているユーザにとってもこの機能は重要である（直訳）」

とも書いてありました。

volumesの設定方法はこんな感じ。

drbd.confを見慣れてる人は「なるほど！」ですね。

drbd-8.4.0rc2のリリース

間をおかず、rc2もリリースされました。

rc2のアナウンスではサポートするカーネルのバージョンが2.6.18となっています。

With this rc we have the compatibility code in place.

It is expected to work on kernels 2.6.18 and newer. I.e. RHEL5.

Compatibility code down to at least kernel 2.6.18

私が検証用OSとしてRHELしか使っていないので、RHELのバージョンに限って話をさせていただくと

RHEL5 → OK、RHEL6 → NGということになります。

なんでRHEL6がだめかっていうバックグラウンドはこちら。

Background: the bio->bi_rw flags have been changed a few times

in the upstream kernel, and RHEL 6.1 changed it again in yet some

different way, so the compat wrappers and ifdefs in DRBD don’t get it

right yet, leading to a compile error.

RHEL 6.1ではbio->bi_rwフラグの取り扱いが変更されており、DRBDはそれに対応できていないとのこと。

（8.3系も8.4系もどっちも未対応です）

なんでRHEL 6.1からそんなん変わるの！というのは

なんかいろいろ大人の事情があるんでしょうねー。もうしらーん。

ちなみに今回の人柱は @bellche さんでした！

さらにちなみにですが、RHEL 6.0+DRBD 8.3.10は動いたので、これはこれで紛らわしい。

あ、この組み合わせはたぶん偶然うまくいったパターンなのでお勧めはしないですよ。

RHEL 6.0はこんなとこではみだしてて大丈夫なのか。

8.4.0の正式リリースでRHEL 6.1も対応してくれるのかなあ。

でも、がっつり修正が入っちゃうようだと、.0はちょっと人柱すぎるという気がしないでもない。

[

drbd-8.3.11rc1のリリース](http://www.gossamer-threads.com/lists/drbd/announce/21472)

こちらは、8.3系のバグフィックスです。

大きな変更点は、こちら。

The most subtlety bug fixed with this release is in the area of the max_bio_size negotiation:

DRBDがローカルのブロックデバイスをプライマリ化して対向ノードと接続した後に

ローカルのディスクを「attach」すると、プライマリのmax_bio_sizeがちっさくなっちゃってたらしいです。

想像するに、絶好調で同期処理をしてる最中に、プライマリで

# drbdadm attach all

を実行したというような状況なんですかね。

で、タイミングによってはmax_bio_sizeがちっさくなる前のブロックI/Oと

ちっさくなっちゃったブロックI/Oがまざっちゃって困ったことが起こる

という意味だと思うんですが、実際どんな困ったことがおこるっていうのがたぶんこれ？

リブートしちゃったりとかではなく、ログに「ASSERT」ってでちゃうだけなのかな？

という気もしますが、8.3.11ではこのへんも修正されているようです。

あとちょっと気になったのはこの一行。

Fixed the behaviour in case ping-timeout and ping-int are set to the same value

ping-timeoutとping-intの値を同じに設定していると、何がおこるんだ…。

それぞれのデフォルト値は

ping-timeout 10秒
ping-int 500ミリ秒

なので、drbd.confでこれらのパラメータを「設定していない」場合は問題ありません。

Hawk (HA Web Konsole) 0.4.1のリリース

Hawk、地味に（失礼）進化を続けています。

が、まだ0.4。

1.0になるのはいつのことやら。

今、Hawkにできることはこちら。

クラスタの状態監視
クラスタの操作（オンライン化/スタンバイ化/停止）
リソースの開始/停止/移動
リソースの作成/変更/削除
クラスタプロパティの変更
location(配置制約),colocation(同居制約),order(順序制約)の作成/変更/削除 ← 0.4.1からの新機能！

２．知恵袋

日本語コミュニティのメーリングリストで、故障契機の話題がでていましたが

そういえば、Pacemakerでは「migration-threshold」という

パラメータが導入されておるのです。

Heartbeat v2時代は、一回故障が起こったらなにがなんでもフェイルオーバという

仕様だったのですが（on-failの設定にもよりますが）

Pacemakerは、故障回数が「migration-threshold」で設定した値に達するまで

故障とみなしません。

しかも、「migration-threshold」のデフォルト値は「0 (=disabled)」！

つまり、「migration-threshold」を明示的に設定しておかないと

いつまでたっても故障とみなしてくれないのです。

ということで、知恵袋では「migration-threshold」の設定方法をご紹介します。

Pacemakerのドキュメントで該当する箇所はこちら。

今回は「Dummy RA」を使用して動作を確認してみます。

Dummy RAは非常に単純なRAで、ちょっと新しい設定方法を試してみたい、というときに便利なRAです。

新しくRAを作るときも参考になるので、簡単に start, monitor, stop処理の中身を見てみましょう。

start処理

start処理とはいいつつ、とりあえずmonitor処理を実行。

monitor OKであれば、もう自分起動済みじゃんということで　return $OCF_SUCCES

monitor NGであれば、なんだ自分まだ起動できてないじゃんということで　touch ${OCF_RESKEY_state}

ここで作ってる${OCF_RESKEY_state}は

${HA_VARRUN}/Dummy-{OCF_RESOURCE_INSTANCE}.state”

です。

95 dummy_start() {

96 dummy_monitor

97 if [ $? = $OCF_SUCCESS ]; then

98 return $OCF_SUCCESS

99 fi

100 touch ${OCF_RESKEY_state}

101 }

monitor処理

${OCF_RESKEY_state}があればmonitor OK

${OCF_RESKEY_state}がなければmonitor NG

という単純な処理です。

Dummy RAで擬似故障を発生させる場合は、${OCF_RESKEY_state}を削除すればよいということになります。

111 dummy_monitor() {

112 # Monitor MUST! differentiate correctly between running

113 # (SUCCESS), failed (ERROR) or cleanly stopped (NOT RUNNING).

114 # That is THREE states, not just yes/no.

115

116 if [ -f ${OCF_RESKEY_state} ]; then

117 return $OCF_SUCCESS

118 fi

119 if false ; then

120 return $OCF_ERR_GENERIC

121 fi

122 return $OCF_NOT_RUNNING

123 }

stop処理 ${OCF_RESKEY_state}を削除します。

103 dummy_stop() {

104 dummy_monitor

105 if [ $? = $OCF_SUCCESS ]; then

106 rm ${OCF_RESKEY_state}

107 fi

108 return $OCF_SUCCESS

109 }

Dummy RAは、かなりまるめて説明すると

start処理でステータスファイルを作って
monitor処理でステータスファイルの有無を確認して
stop処理でステータスファイルを削除

という単純な動作をするRAです。

他のRAの代替として動作確認に使用することも可能ですが、

単純すぎるがためにはまる罠というのもたまにありますのでご注意ください。

では、Dummy RAを起動させてみましょう。

(1) Dummy RAの起動

Dummy RA用のcrmファイルを作成します。

まずは、migration-thresholdを設定せずに動作を確認してみましょう。

dummy00.crm

### Cluster Option ###
property no-quorum-policy="ignore" \
stonith-enabled="false" \
startup-fencing="false"
### Resource Defaults ###
rsc_defaults resource-stickiness="INFINITY"
### Primitive Resource ###
primitive dummy01 ocf:pacemaker:Dummy \
   op start interval="0s" timeout="100s" on-fail="restart" \
   op monitor interval="10s" timeout="100s" on-fail="restart" \
   op stop interval="0s" timeout="100s" on-fail="stop"

クラスタを起動します。

** # service heartbeat start**

crmファイルをクラスタに反映します。

** # crm configure load update dummy00.crm**

クラスタの状態を確認します。

-foオプションをつけると、failcount情報（故障回数）やoperation情報(start,monitorなどの状態)も表示されます。

** # crm_mon -i1 -fo**

============

Last updated: Mon May 30 13:08:55 2011

Stack: Heartbeat

Current DC: xen02 (22222222-2222-2222-2222-222222222222) - partition with quorum

Version: 1.0.11-db98485d06ed stable-1.0 tip

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]**

dummy01** (ocf::pacemaker:Dummy): Started xen01

Operations:

Node xen02:
Node xen01:**

dummy01: migration-threshold=1000000**

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=0 (ok)

なんと、migration-threshold=1000000！

1000000回目の故障でやっとフェイルオーバ！ということになります。

なんかいろいろムリですが、とりあえずノードxen01で起動しているdummy01を故障させてみましょう。

xen01でdummy01のステータスファイルを削除します。

# rm -f /var/run/Dummy-dummy01.state

しばらく crm_mon -i1 -fo を眺めていると。。。

============

Last updated: Mon May 30 13:09:42 2011

Stack: Heartbeat

Current DC: xen02 (22222222-2222-2222-2222-222222222222) - partition with quorum

Version: 1.0.11-db98485d06ed stable-1.0 tip

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]**

dummy01** (ocf::pacemaker:Dummy): Started xen01

Operations:

Node xen02:
Node xen01:**

dummy01: migration-threshold=1000000 **fail-count=1

(5) stop: rc=0 (ok)
(6) start: rc=0 (ok)
(7) monitor: interval=10000ms rc=0 (ok)

dummy01のfail-countが「1」にあがりましたね！

でも、フェイルオーバはしていません（xen01のまま）。

ログ（/var/log/ha-log）を見ると、monitor NGを検知してstopが実行されてはいます。

ただし、今回の例ではmonitorにon-fail=restartと設定してあるので、同一ノードで再起動に挑戦、

ステータスファイルの作成に成功（再起動成功）したので

dummy01は、再びxen01で動いているというわけです。

DCノード（この例ではxen02）でha-logを検索してみると、こんな感じになります。

# grep match_graph_event /var/log/ha-log

May 30 13:08:30 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_0 (6) confirmed on xen02 (rc=0)

May 30 13:08:32 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_0 (4) confirmed on xen01 (rc=0)

May 30 13:08:34 xen02 crmd: []: info: match_graph_event: Action dummy01_start_0 (7) confirmed on xen01 (rc=0)

May 30 13:08:35 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_10000 (8) confirmed on xen01 (rc=0

May 30 13:09:38 xen02 crmd: []: info: match_graph_event: Action dummy01_stop_0 (2) confirmed on xen01 (rc=0)

May 30 13:09:40 xen02 crmd: []: info: match_graph_event: Action dummy01_start_0 (5) confirmed on xen01 (rc=0)

May 30 13:09:42 xen02 crmd: []: info: match_graph_event: Action dummy01_monitor_10000 (6) confirmed on xen01 (rc=0)

(2) migration-threshold の設定

では、migration-thresholdを設定してみましょう

Dummy RA用のcrmファイルを作成します。

今回は、migration-thresholdの設定に注目してください。

migration-thresholdは、rsc_defaultsセクションに設定します。

dummy01.crm

Cluster Option

property no-quorum-policy=”ignore” \

stonith-enabled=”false” \

startup-fencing=”false”

Resource Defaults

rsc_defaults resource-stickiness=”INFINITY” **

migration-threshold=”1”**

Primitive Resource

primitive dummy01 ocf:pacemaker:Dummy \

op start interval=”0s” timeout=”100s” on-fail=”restart” \

op monitor interval=”10s” timeout=”100s” on-fail=”restart” \

op stop interval=”0s” timeout=”100s” on-fail=”stop”

migration-thresholdは、rsc_defaultsセクションだけでなく

リソースそれぞれに設定することもできます。

この場合、「meta」キーワードが必要となります。

Cluster Option

property no-quorum-policy=”ignore” \

stonith-enabled=”false” \

startup-fencing=”false”

Resource Defaults

rsc_defaults resource-stickiness=”INFINITY” **\

migration-threshold=”1”**

Primitive Resource

primitive dummy01 ocf:pacemaker:Dummy \

op start interval=”0s” timeout=”100s” on-fail=”restart” \

op monitor interval=”10s” timeout=”100s” on-fail=”restart” \

op stop interval=”0s” timeout=”100s” on-fail=”stop”

primitive dummy02 ocf:pacemaker:Dummy **

meta migration-threshold=3 **

op start interval=”0s” timeout=”100s” on-fail=”restart” \

op monitor interval=”10s” timeout=”100s” on-fail=”restart” \

op stop interval=”0s” timeout=”100s” on-fail=”stop”

rsc_defaultsセクションに設定したmigration-thresholdが全体のデフォルト値となります。

上の例では

dummy01にはmigration-thresholdを設定していませんが、rsc_defaultsセクションの値を引き継ぐので

dummy01 : migration-threshold=1 となります。

dummy02には、meta属性として、migration-threshold=3が設定されています。

この場合、rsc_defaultsセクションの値ではなく、meta属性の値が使用されます。よって

dummy02 : migration-threshold=3 となります。

では、(1)と同じようにDummy RAを起動してみましょう。

dummy01.crmをクラスタに反映させてみます。

# crm_mon -i1 -fo

============

Last updated: Mon May 30 13:19:37 2011

Stack: Heartbeat

Current DC: xen02 (22222222-2222-2222-2222-222222222222) - partition with quorum

Version: 1.0.11-db98485d06ed stable-1.0 tip

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]

dummy01 (ocf::pacemaker:Dummy): Started xen01

Operations:

Node xen02:
Node xen01:**

dummy01: migration-threshold=1**

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=0 (ok)

お！今回はdummy01のmigration-thresholdが「1」となっていますね！（前「1000000」だったとこ）

では、dummy01を故障させてみましょう。

# rm -f /var/run/Dummy-dummy01.state

# crm_mon -i1 -fo

============

Last updated: Mon May 30 13:20:10 2011

Stack: Heartbeat

Current DC: xen02 (22222222-2222-2222-2222-222222222222) - partition with quorum

Version: 1.0.11-db98485d06ed stable-1.0 tip

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]

dummy01 (ocf::pacemaker:Dummy): Started xen02

Operations:

Node xen02:

dummy01: migration-threshold=1

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=0 (ok)
Node xen01:**

dummy01: migration-threshold=1 fail-count=1**

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=7 (not running)
(5) stop: rc=0 (ok)

Failed actions:**

dummy01_monitor_10000 (node=xen01, call=4, rc=7, status=complete): not running**

おお！フィルオーバしました！（xen01 → xen02）

よかったよかった。

慣れていない間は、「migration-threshold」の設定を忘れてしまうことが多いので

とりあえずrsc_defaultsセクションにがつっと書いちゃってたほうが安心です。

(3) failure-timeout の設定

ちなみに、さっき紹介したドキュメントには「failure-timeout」という

パラメータもありましたが、このパラメータは Pacemaker 1.1 からしか使えません。

試しに Pacemaker 1.0(1.0.11) で動作を確認してみましたが

それなりにそれっぽい動きはしていました。

ただし、crm_monとかcrmシェルとかの表示系が追いついてない、

というか表示系がとってくる値と、状態遷移でごにょごにょした値が一致していないので

1.0系では使えないです。

failure-timeoutはその名の通り（？）、過去の失敗をなかったことにしてくれる

魔法のパラメータです。

なにかしらの故障が発生してリソースがフェイルオーバした場合、

故障ノードのフェイルカウントは運用者が「手動」でクリアする必要があります。

ここで、failure-timeout=60sとかしておくと、故障発生から60秒後にフェイルカウントを

自動でゼロに戻してくれるというなんたる魔法使い。

あ、でも故障原因を自動的に取り除いてくれるわけではないですよ！

というわけで、Pacemaker 1.1で動作を確認してみました。

設定ファイルの例

Cluster Option

property no-quorum-policy=”ignore” \

stonith-enabled=”false” \

startup-fencing=”false” **\

cluster-recheck-interval=”60s”**

Resource Defaults

rsc_defaults resource-stickiness=”INFINITY” **

migration-threshold=”1” \

failure-timeout=”120s”**

Primitive Resource

primitive dummy01 ocf:pacemaker:Dummy \

op start interval=”0s” timeout=”100s” on-fail=”restart” \

op monitor interval=”10s” timeout=”100s” on-fail=”restart” \

op stop interval=”0s” timeout=”100s” on-fail=”stop”

failure-timeoutだけでなく、cluster-recheck-intervalも設定する必要があります。

failure-timeoutはmigration-thresholdと同様、リソースのmeta属性として設定することもできます。

cluster-recheck-intervalは、クラスタ全体のオプションなのでリソース個別に設定することはできません。

では、リソースを起動してみましょう。

# crm_mon -i1 -fo

============

Last updated: Mon May 30 19:06:23 2011

Stack: Heartbeat

Current DC: xen01 (11111111-1111-1111-1111-111111111111) - partition with quorum**

Version: 1.1.5-e872eeb39a5f**

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]

dummy01 (ocf::pacemaker:Dummy): Started xen01

Operations:

Node xen01:

dummy01: migration-threshold=1

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=0 (ok)
Node xen02:

リソースを故障させます。

# rm -f /var/run/Dummy-dummy01.state

============

Last updated: Mon May 30 19:07:06 2011

Stack: Heartbeat

Current DC: xen01 (11111111-1111-1111-1111-111111111111) - partition with quorum**

Version: 1.1.5-e872eeb39a5f**

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]

dummy01 (ocf::pacemaker:Dummy): Started xen02

Operations:

Node xen01:**

dummy01: migration-threshold=1 fail-count=1 last-failure=’Mon May 30 19:07:03 2011’**

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=7 (not running)
(5) stop: rc=0 (ok)
Node xen02:

dummy01: migration-threshold=1

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=0 (ok)

Failed actions:

dummy01_monitor_10000 (node=xen01, call=4, rc=7, status=complete): not running

今までとは違って、「last-failure」という表示が追加されていますね！

ここで、2分（failure-timeout=”120s”）待ってみると…

============

Last updated: Mon May 30 19:09:34 2011

Stack: Heartbeat

Current DC: xen01 (11111111-1111-1111-1111-111111111111) - partition with quorum**

Version: 1.1.5-e872eeb39a5f**

2 Nodes configured, unknown expected votes

1 Resources configured.

============

Online: [ xen01 xen02 ]

dummy01 (ocf::pacemaker:Dummy): Started xen02

Operations:

Node xen01:

dummy01: migration-threshold=1

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=7 (not running)
(5) stop: rc=0 (ok)
Node xen02:

dummy01: migration-threshold=1

(3) start: rc=0 (ok)
(4) monitor: interval=10000ms rc=0 (ok)

おおおおお。fail-countとlast-failureの表示が消えた！

フェイルカウントはちゃんと「0」になっています！！

# crm resource failcount dummy01 show xen01**

scope=status name=fail-count-dummy01 value=0**

Pacemaker 1.1になるまで出番はオアズケですが、なにかいい使い道を考えておかなくては。

今回、あんどりゅーくんの出番があまりなかったので、お引っ越し情報など。

こういうのって個人情報的にどうなんですかね。

でも、あんどりゅーくんのブログにも書いてあるし、いいのかな…。

ある日、あんどりゅーくんがこんなTweetをしていました。

なにがおこった…。

そして、その次の日のTweet。

今、流行の（もう古いのか？）断捨離とかそういうの？？

と思っていたら、どうやらお引っ越しらしい。

そういや、5月の第二週にブダペストでUbuntu祭りが開催されたらしく

ふろーりあんくんは、そこでお話してきたっぽいんですよね。

で、ふろーりあんくんが、あんどりゅーくんに「オマエも来いよー」と誘っていたのですが

あんどりゅーくんは「むーりー」と断ってました。

ふろーりあんくん

Andrew, interested in making a day trip to Budapest while you’re still on this continent?

あんどりゅーくん

With under 4 weeks to go - not a chance :-)

“you’re still on this continent”ってそゆこと！

あんどりゅーくん、ヨーロッパからオーストラリアにお引っ越しかー。

オーストラリアといえば有袋類の楽園。いいなあ。

最近、オフィスの節電で窓を開け放して仕事をしているのですが

すぐ隣は隅田川だからね、うちのビル。

窓を開けてると蚊に食われるらしいのですよ(私はまだ食われてない)。

しかも隅田川仕様で、無駄にでかい蚊に。

オーストラリアは窓開けたらコアラおるんかなあ。カンガルーに乗って出勤したいかもよー。（やけくそ）

うちらは蚊取り線香買いにいかんとー。

では、今月はこれにてどろん！εεεεεヾ(*´ー`)ﾉ

夏休みーはまーだかな