ふたつの川うるおう日記

_ [Server][Admin] DRBDとクラスタファイルシステムのテストで手詰まり中 (解決済み)

[20080713追記] このエントリの内容は、DRBD (Primary/Primary) + GFS2で1ノード落としても大丈夫にで解決しました。

ちょっとテストしてて手詰まり中。OSはCentOS 5.2。Kernelは2.6.18-92.1.6.el5xen。

• DRBD (Primary/Primary) + GFS2
  • 問題: 片方のノードに障害が起きたと仮定してLAN線を切るとクラスタ全体でFAIL_ALL_STOPPEDになって、生きてる方もファイルを読めなくなる。fence_manualのせい？でも、fennce_ack_manualやcman kill -n node名とかやっても生き返らないし、死んだノードを生きてるノード上で切り離せない。以下、ステータス。

[root@host01 ~]# cman_tool services
type             level name     id       state
fence            0     default  00010002 FAIL_ALL_STOPPED
[1 2]
dlm              1     clvmd    00020002 FAIL_ALL_STOPPED
[1 2]
dlm              1     drbd0    00020001 FAIL_ALL_STOPPED
[1 2]
gfs              2     drbd0    00010001 FAIL_ALL_STOPPED
[1 2]

[root@host01 ~]# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-06-26 19:33:29
 0: cs:WFConnection st:Primary/Unknown ds:UpToDate/DUnknown C r---
    ns:0 nr:0 dw:0 dr:5548 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:0

自分自身はPrimaryなんだから死んだノードは一時的に切り離すなりして読み書きしたい。

• DRBD (Primary/Primary) + GFS
  • 問題: GFS2と同じでFAIL_ALL_STOPPEDになる。

• DRBD (Primary/Primary) + OCFS2
  • 問題: mountできない。

[root@host01 ~]# mount -t ocfs2 /dev/drbd0 /home/cluster/drbd0
ocfs2_hb_ctl: I/O error on channel while starting heartbeat
mount.ocfs2: Error when attempting to run /sbin/ocfs2_hb_ctl: "Operation not permitted"

Heartbeat2 Xen cluster with drbd8 and OCFS2 のコメント欄によると、Kernel 2.6.22以降にすれば良いらしい？Kernelはできれば標準の使いたいので保留中。

Primary/Primaryは諦めて一般的なPrimary/Secondaryにして、ファイルシステムはext3にするのがやっぱし無難っぽい。GFS2/GFSでノードが正常時ならライブマイグレーション上手く動いてるだけにちょっと捨てがたいけど。

| Bookmark:

_ [Server][Admin] DRBD (Primary/Primary) + GFS2で1ノード落としても大丈夫に

DRBDとクラスタファイルシステムのテストで手詰まり中で書いたDRBD (Primary/Primary)で構成した2ノードのうち、1ノード落とすともう1ノードでGFS2領域にアクセスできなくなるのは、コメントにあるRAさんの情報をもとにQuorumをよく調べることで解決しました。

Red Hat Cluster Suite(GFS/GFS2はこの一部)では、Quorumを次の式で決定し、この数字より小さいノード数になるとサービスが停止する作りになっています。

Quorum = 稼働していたノード台数 / 2 + 1

具体的な数字を書くと次のとおり。

6台構成: 6/2+1 = 4台以上稼働し続けていればOK、3台以下になったらアウト
3台構成: 3/2+1 = 2台以上稼働し続けていればOK、1台以下になったらアウト

ここで今回やっていたDRBDの場合、2台構成なので次のようになります。

2台構成: 2/2+1 = 2台以上稼働し続けていればOK、1台以下になったらアウト

つまり2台構成の時は、普通であれば1台落ちたらアウトだったんです。稼働中のQuorumを知りたい場合は、cman_tool status コマンドで知ることができます。

# cman_tool status
...
Expected votes: 2
Total votes: 2
Quorum: 2
Active subsystems: 8
Flags: Dirty
...

で、それだと困るわけで実は2台構成の時にQuorumを1に固定する設定として、<cman two_node="1" expected_votes="1"> があります。この設定は、ccs_tool コマンドで設定することはできないみたいなので、次のように /etc/cluster/cluster.conf を編集します。

• 編集前: /etc/cluster/cluster.conf

<cluster name="drbd_cluster" config_version="5">
  <clusternodes>
...

• 編集後: /etc/cluster/cluster.conf
  • config_versionは編集前 +1 の数字にすること

<cluster name="drbd_cluster" config_version="6">
  <cman two_node="1" expected_votes="1">
  </cman>
  <clusternodes>
...

編集したら、次のコマンドで稼働中の全ノードへ設定を反映させます。

ccs_tool update /etc/cluster/cluster.conf

早速 cman_tool status を調べます。

# cman_tool status
...
Expected votes: 1
Total votes: 2
Quorum: 2
Active subsystems: 8
Flags: 2node Dirty
...

ここで困ったことが起きていて、Expected votesとFlagsの値は変わったのにQuorumは2のままです。これが前回上手くいかなかった原因です。ccs_tool update してもQuorumは書き換わって無かったのです。これはマシンごと再起動してcmanを起動し直すことで次のように意図する値になりました。

# cman_tool status
...
Expected votes: 1
Total votes: 2
Quorum: 1
Active subsystems: 8
Flags: 2node Dirty
...

これで1ノード障害でいなくなってもOKです。実際に断線させると次のようになり、生きているノードでマウントしていたGFS2領域もそのまま読み書きできます。

[root@host01 ~]# cman_tool services
type             level name     id       state
fence            0     default  00010001 none
[1]
dlm              1     clvmd    00020001 none
[1]
dlm              1     drbd0    00040001 none
[1]
gfs              2     drbd0    00030001 none
[1]

fence_manual以外のfenceデバイスを設定している場合は自動的に上記の状態になります。fence_manualを使っている場合は、fence_as_manualを使って手動でサービスを継続するよう指示しないといけません。次のようなコマンドです。

fence_ack_manual -O -e -n 落ちたノード名

今回の構成ではデータはDRBDで同期されていることが前提ですので、上記は自動的に実行して欲しいです。そこでDRBDの outdate-peer を使って自動的に実行するようにすれば良いです。これについては下記の資料を参考にしました。

• DRBD_Cookbook
  • outdate-peer用スクリプト (このままではダメ)

outdate-peer用スクリプトは、fence_manual用になっていないので、 DRBD-user MLのoutdate-peerスクリプトの編集例を真似て編集します。GFS2用の場合、cman_tool nodesが返す値が違うのでそこも直します。最終的な編集箇所は次のとおりです。

--- drbd-peer-outdater.default  2008-07-01 02:46:16.000000000 +0900
+++ drbd-peer-outdater  2008-07-13 09:53:22.000000000 +0900
@@ -49,7 +49,7 @@
-done < <(cman_tool nodes 2>/dev/null | grep -v '^Node' | awk '{print $1,$6}')
+done < <(cman_tool nodes 2>/dev/null | grep -v '^Node' | awk '{print $1,$4,$6}')
@@ -71,7 +71,8 @@
-fence_node $REMOTE
+#fence_node $REMOTE
+fence_ack_manual -O -e -n $REMOTE

以上でfence_manualでも1ノードで自動でサービスを継続できるようになりました。

まだ良く検証していませんが懸念事項として、障害で1ノード完全に死ぬのではなく、短い時間ネットワークがLink Downしてクラスタから切り離されても、切り離されているときに両方とも同じGFS/GFS2領域をマウントしている状態だと、一度どちらかのノードのマシンを再起動しないといけなくなります(どっちが必要なPrimaryかが自動では判別が付かないため)。それをどうするかや、そういったことが起きる頻度がどれくらいあるかを今後調べる必要があります。

| Bookmark:

_ [Seasar][Project] Seasar Conference 2008 Autumn

9月6日(土)にSeasar Conference 2008 Autumnが開催されます。まだ一般募集は始まってませんがサイトは立ちあがっています。サイトデザインは前回に続いてsugaさんの手によるものです。2匹のシーサーがお行儀よくお月様を眺める後ろ姿が可愛らしくてGood!です。左右の花瓶にも向きの違う尻尾マークが入ってたりしてほんと上手いです。いつもデザインありがとうございます。

今回は、スピーカーをSeasarのコミッタに限らず一般募集していますので、他のオープンソースコミュニティ、開発者コミュニティなどの「話したくてうずうずしている皆さん」、スピーカーとして是非ご参加ください。応募方法は、イベントサイトに詳細書いてありますのでどうぞご確認ください。

• Seasar Conference 2008 Autumn

また、一般来場参加はセッションが決まってからの募集になりますので、もうしばらくお待ちください。

| Bookmark:

_ [雑記] EeePC 901-X買った

SonyがVAIOでAtom乗ったちっこいの出るまで待とうと思ってたけど、当分でなそうなので、EeePC 901-Xのパールホワイトをポチった。

現物見に言ったけど在庫なしだったのでヨドバシのオンラインショップで申し込み入金も完了。2週間以内には届くと思う。

[追記] E-MOBILEセットの方が良い気がしたので一旦キャンセルした。ヨドバシごめんなさい。

[追記] E-MOBILEセットで買い直した。ただし納期は未定。まぁ最悪でも1ヶ月以内には手に入ると思うのでOK。本体が入荷してからの手続きになるけど、2/9に契約した新にねんライトデータ月額1980(上限5480)が新にねんスーパーライトデータプラン月額1000円(上限4980)になって、端末も1個貰えるので結果オーライ。

| Bookmark:

_ [Server][Admin] DRBD + (ext3|GFS2) ベンチマーク

DRBDとGFS2のベンチマークを取ってたら、id:shakemidさんのDRBDベンチマークってのがあったので、ついでなのでext3も同じように測ってみました。なお、接続しているスイッチはテスト対象のマシン2台と100Mbpsの上流を繋いだまま実行したので綺麗な環境での実行ではありません。

環境

• ハードウェア

下記のマシンを2台用意して試しました。

• ソフトウェア

DRBDはCentOS PlusにあるRPMで、Bonnie++以外は全部RPMです。

ネットワーク

GigabitスイッチであるPLANEX FXG-08IMVにストレートケーブルでそれぞれ接続。用意したハード2台の片方にFTPサーバを立てて、もう1台からAnonymous接続で150MBあるファイルを何回か転送したところ約112MB/secでてました。

テスト結果

以下の条件でBonnie++を使ってベンチマークを行いました。Bonnie++は、MinTimeを0.01に修正してコンパイルしてあります。結果の値は、大きなファイルを1つ読み書きするSequential Read/WriteのBlockをピックアップします。

• 使用コマンド: ./bonnie++ -d 対象ディレクトリ

条件1と2の結果から通常KernelとXen Kernelの差はほぼないっぽいので、条件3以降のKernelもすべてXen Kernelで計測しました。

考察

Sequential Read (Block) の性能

• 通常KernelとXen Kernelの性能差はほぼない (1%以内)
• DRBD(C)であれば、DRBD有り無しでの性能差はほぼない、DRBD(A,B)は約10%劣る
• DRBD(C) + GFS2では、GFS2領域の1台マウントと2台マウントで性能差はほぼない (1%以内)

Sequential Write (Block) の性能

• 通常KernelとXen Kernelの性能差はほぼない (3.5%良くなってる)
• DRBDなしのローカルHDDの性能を100%とすると、DRBDなし : DRBD(C) + ext3 : DRBD(C) + GFS2 = 100% : 約36.3% : 約32.3% の性能比になった
• DRBD(C) + ext3では、DRBDのPrimary/Primary(マウントは片方のみ)とPrimary/Secondaryの状態による性能差はほぼない (6%以内)
• DRBD(C) + GFS2では、GFS2領域の1台マウントと2台マウントで性能差はあまりない (6%以内)

まとめ

• DRBD + ext3でのDRBDのプロトコル間の比較は、id:shakemidさんのDRBDベンチマーク同様、C > B > Aの順に速いという結果になりました。イメージと違いますが、同じ結果なのでこういうものなのでしょう。
  • ただし、その差は気にする程の大きさではないと思います
• DRBD(C) + ext3では、Read性能はDRBDなしの場合と同等なので問題にならない。Write性能は1/3程度まで劣化するが、32791 KB/sec = 262.328 Mbpsであり、十分に実用できる場面がある。
• DRBD + GFS2では、Read性能はDRBDなしの場合と同等なので問題にならない。Write性能は1/3程度まで劣化するが、ext3同様十分に実用できる場面がある。
  • ただし、今回のテストでは常に片方のノードでしかRead/Writeを実施していないことを注意する必要があります。複数ノードで同時にRead/Writeすると劣化すると思われます。

生データと番外編

DRBD上でのext3とGFS2のSequential Read/Writeではそんなに差が出ませんでしたが、大量のファイルを作成したりメタデータを操作するSequential CreateとRandom Createではものすごく差がでています。どれくらい差があるかは下記の生データで確認してください。CPUはちっとも消費していないため、何かチューニングなどで改善できる箇所があるのかもしれません。

• 1. DRBDなし (通常Kernel + LVM + ext3)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen01.example.o 16G 72087  89 87962  17 38257   5 83055  90 85773   5 178.8   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 95510 100 555991  98 108221 100 98191 100 854762  99 111761 100
xen01.example.org,16G,72087,89,87962,17,38257,5,83055,90,85773,5,178.8,0,16,95510,100,555991,98,108221,100,98191,100,854762,99,111761,100

• 2 DRBDなし (Xen Kernel + LVM + ext3)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen01.exampl 15856M 54356  68 90184  18 37734   0 80736  90 85094   0 177.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 75970 102 388964  85 91870 100 76957  93 491625 120 94078  96
xen01.example.org,15856M,54356,68,90184,18,37734,0,80736,90,85094,0,177.5,0,16,75970,102,388964,85,91870,100,76957,93,491625,120,94078,96

• 3 DRBD Protocol A (LVM + ext3)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen02.exampl 15856M 30375  40 29344   6 24303   2 76117  84 78366   1 147.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 62557  84 384590  93 91716 100 77508 100 474650 115 93507 102
xen02.example.org,15856M,30375,40,29344,6,24303,2,76117,84,78366,1,147.5,0,16,62557,84,384590,93,91716,100,77508,100,474650,115,93507,102

• 4 DRBD Protocol B (LVM + ext3)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen02.exampl 15856M 33260  46 31218   6 26036   2 77506  86 78337   2 150.7   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 71903  93 383278  93 90318  99 76782  99 478631  81 93038 102
xen02.example.org,15856M,33260,46,31218,6,26036,2,77506,86,78337,2,150.7,0,16,71903,93,383278,93,90318,99,76782,99,478631,81,93038,102

• 5 DRBD Protocol C (Primary/Primary + LVM + ext3)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen02.exampl 15856M 32229  44 30969   6 25675   0 79680  89 84964   0 120.4   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 74174  90 385153  94 91028 100 76385 102 479851  82 92681 101
xen02.example.org,15856M,32229,44,30969,6,25675,0,79680,89,84964,0,120.4,0,16,74174,90,385153,94,91028,100,76385,102,479851,82,92681,101

• 6 DRBD Protocol C (Primary/Secondary + LVM + ext3)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen02.exampl 15856M 31714  43 32791   6 25150   0 77275  85 85020   0 143.4   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 74151  94 383222 102 91399 100 76116 102 482763  82 92257 101
xen02.example.org,15856M,31714,43,32791,6,25150,0,77275,85,85020,0,143.4,0,16,74151,94,383222,102,91399,100,76116,102,482763,82,92257,101

• 7 DRBD Protocol C (1マウント状態 + LVM + GFS2)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen01.exampl 15856M 27498  37 28730   7 24922   1 69905  77 84985   0 120.5   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   122   0 181884  97   249   0   123   0 188347  91   247   0
xen01.example.org,15856M,27498,37,28730,7,24922,1,69905,77,84985,0,120.5,0,16,122,0,181884,97,249,0,123,0,188347,91,247,0

• 8 DRBD Protocol C (2マウント状態 + LVM + GFS2)

Version 1.03c       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
xen01.exampl 15856M 25856  34 27162   6 26546   1 72257  76 84794   0 122.6   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16   122   0 181319  88   246   0   122   0 186669  91   249   0
xen01.example.org,15856M,25856,34,27162,6,26546,1,72257,76,84794,0,122.6,0,16,122,0,181319,88,246,0,122,0,186669,91,249,0

| Bookmark:

_ [Server][Admin] Mailman の digest.mbox の処理でエラーが出てメール配送が止まる場合への楽観的な対策

以前別のMLでも同じように発生した digest.mbox の処理でエラーが出て(正確にはqrunnerが落ちたというログしか出ず、非常に判り難い)メールが配送されなくなる現象、原因がMailmanの文字コード処理だったりPythonのライブラリの文字コード処理だったり、それぞれのバージョンによったりして対策方法が判り難い。

このファイルは、まとめ読み機能にしか使われていないようだし、そもそもまとめ読み機能もほとんどの場合、誰も使っていない。また、メールの流通量が多いとこのファイルがどんどんでかくなり、結果、会員への配送遅延にもなるというあまり良いことがない。

管理ページから以下の設定をすることでこのファイルが作られなくなる(更新されなくなる)ことが判ったので、原因箇所がはっきりしない場合は止めちゃうことにした。

• 「まとめ読み」オプション
  • リスト会員はダイジェストでまとめ読みするオプションを選択できますか? (digestable): いいえ

既にこの現象が起きてしまった場合は、Mailmanを止めて、$MAILMAN_HOME/lists/ML名/digest.mbox から問題となっている文字列を探して除去するか、まとめ読み機能自体使わないならこのファイルをリネームか削除してしまえば良いです。

| Bookmark: