投稿者: 管理人 (40ページ目 (41ページ中))

DRBDを使っていて、うっかりスプリットブレインになっちゃった時に、リカバリー方法を間違えるとややこしいことになるような気がした(どっちをマスターにするかを間違えると、スレーブでマスターを上書きしてデータのロストとか起きたりしそう)ので、ちょっと試しにスプリットブレイン状態を作ってリカバリーしてみた。

使ったDRBDは8.3.0。インターネットを探してみると、DRBDが動いている状態でネットワークを引っこ抜くとスプリットブレインが発生すると書いてあるサイトもあったので、試しにL2スイッチの電源を落としてみた。そしたら、お互いに「WFConnection」(接続待ち)状態に遷移した。一方、マスター側は「Primary」状態なので、そのままマウントして、アプリケーションからいじってたりしたけれど影響はなかったみたいだ。で、ネットワークを再接続すれば、切断前のPrimary/Secondaryの関係性を維持したまま、「Primary」から「Secondary」への同期が始まった。で、同期が完了すると、「Connection」状態に戻った。

結局、ネットワークがダウンするだけでは、スプリットブレインは発生しないようだ。とりあえず、運用中にLANケーブルが引っこ抜ける的な障害が起こった場合は、LANケーブルを刺し直せば自動で対応してくれそうだ。

次に、意図的にスプリットブレインを作ることにした。L2スイッチを落とすところまでは同じだが、ネットワークが切れていることをいいことに、スレーブ側のマシンを「Primary」状態にしてみた。その後、L2スイッチの電源を入れる。これによって、お互いが「Primary」になっていることを検出するので、スプリットブレインとして、お互いが「StandAlone」に落ちる。ただ、もともと「Primary」になっていたマスター側は、StandAloneになっても「Primary」なので、マウントは可能っぽい。ただ、同期が取られないだけのようだ。dmesgでログを確認すると、以下のようなログが出力されていた。

drbd0: drbd_sync_handshake:

drbd0: self 6ABCC0B39EEBC9D5:03B0E55FA3B63131:38D5407DCCBC17FE:1C2D0C92A346572F

drbd0: peer 705B58F4947E0C9C:03B0E55FA3B63130:38D5407DCCBC17FE:1C2D0C92A346572F

drbd0: uuid_compare()=100 by rule 9

drbd0: Split-Brain detected, manually solved. Sync from this node

さて、両方のノードが「StandAlone」になったときにどう復旧するか。「drbdadm」にはいくつもコマンドオプションがあるので、いろいろ試してみたが、同期を取ってくれない。。。

そんなわけで、DRBDのマニュアルを探してみたら、「Manual split brain recovery」って項目があった。

DRBD detects split brain at the time connectivity becomes available again and the peer nodes exchange the initial DRBD protocol handshake. If DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection.

DRBDは、コネクティビティが復活した時や、同期相手とDRBD Protocolによるハンドシェイクを行う時にスプリットブレインを検出する。DRBDが両方のノードがPrimary(role)になっている(もしくは、接続が切れている、どこかの時点でPrimaryになっていた)場合、レプリケーションの接続をすぐに切断する。

After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain).

スプリットブレインを検出した後では、一方のノードはずっと「StandAlone」になっていて、両方のノードが同時にスプリットブレインを検出していれば、もう一方のノードも「StandAlone」になっているかもしれないし、もう一つのノードがスプリットブレインを検出する前にコネクションを落としていれば、「WFConnection」になっているかもしれない。

At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the split brain victim). This intervention is made with the following commands:

DRBDを自動的にスプリットブレインから復旧するように設定していなければ、こうなった時に、どっちのノードの変更を破棄するかを選択して、手動で介入する必要がある。この介入は、このコマンドで行われる。

と。

マスターとなる側では以下のコマンドを実行するらしい。

drbdadm connect resource

スレーブとなる側(つまり、変更点があっても破棄される側)では、以下のコマンドを実行するらしい。

drbdadm secondary resource

drbdadm — –discard-my-data connect resource

…というわけで、やってみたら、無事にConnection状態に戻った。

DRBDをマスターとなるマシンとスレーブの両方にインストールし終わっただけでは、両方とも「Secondary」状態になっているので、マスター側を「Primary」状態にする必要がある。そのためには、2つのマシン間でデータの同期を行う必要がある。

そのマスターを「Primary」にして、最初の同期を取るコマンドが、DRBD7までは「–do-what-I-say」ってオプションが有効だったけれど、それがDRBD8からは「-overwrite-data-of-peer」に変更になったそうだ。というわけで、

drbdadm — -overwrite-data-of-peer primary all

をマスターとなるマシンで実行する。確かに「do what I say」よりは「overwrite data of peer」の方がわかりやすいオプションではあるけども。で、同期が始まった後で、/proc/drbdを覗いてみると、同期の進捗などが見える。

$ cat /proc/drbd

version: 8.3.0 (api:88/proto:86-89)

GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by root@localhost.localdomain, 2008-12-22 17:52:35

0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r—

ns:0 nr:28678656 dw:28670464 dr:0 al:0 bm:1749 lo:257 pe:1560 ua:256 ap:0 ep:1 wo:b oos:13271260

[============>…….] sync’ed: 68.4% (12960/40958)M

finish: 0:07:24 speed: 29,796 (29,676) K/sec

ただ、speedのところに書いてある、この約30M/secってのは、単位は何だろうってことで、調べてみた。で、DRBDのドキュメント(no title)を見てみると、speedの単位としては書かれていなかったけど、随所で「KiByte」って書いてあるから、きっと「30MByte/sec」ってことなんだろう。ってことは、だいたい240Mbpsくらいか。ギガビットなイーサネットを使っておいてよかった。

DRBDのマスターとスレーブの通信方式は、3つの中から選べる。

drbd-8.3.0.tar.gzのサンプルのdrbd.confより

C: write IO is reported as completed, if we know it has reached _both_ local and remote DISK.

* for critical transactional data.

B: write IO is reported as completed, if it has reached local DISK and remote buffer cache.

* for most cases.

A: write IO is reported as completed, if it has reached local DISK and local tcp send buffer. (see also sndbuf-size)

*for high latency networks

DRBDを扱ったblogとかに載ってるdrbd.confを見ると、「C」になってることが多いけど、このサンプルファイルでは、「B」が「for most cases」となっている。サンプルのdrbd.confの続きにはこうも書いてあった。

uhm, benchmarks have shown that C is actually better than B. this note shall disappear, when we are convinced that B is the right choice “for most cases”. Until then, always use C unless you have a reason not to.

ベンチマーク的には「B」よりも「C」が優れているらしい。しかし、「B」の「remote buffer cache」って何を指しているんだろうか。Aがわざわざ「tcp」send bufferって書いてあるわけだから、tcpが付いてない=ネットワーク関連じゃないキャッシュなんだろう。そうなると、ディスクの書き込みキャッシュが思いついたりするが…そうなのか(汗)

でも、なんとなーく「C」の方が安心なプロトコルで、それって性能を犠牲にして実現されている方が、なんとなーく納得いくんだけどなぁ。まして、drbd.confを書いた人が、多くの場合、「B」が正しい選択って言う理由も気になるけども、、、書いてないか。

…でも、まぁ、とりあえず、「C」にしとく(汗)

Linuxカーネルに関わるモジュールを使っていたりすると、yumで自動的にkernelの更新して欲しくないケースもあるので、とりあえず、/etc/yum.confにexcludeを追加。

exclude=kernel*

これでカーネル周辺は更新されないはず。。。

会社でDELLの「デジタルハイエンドシリーズ 2007FP HAS」を使っている。この液晶、しばらく使っていると画面に横に長いノイズが何本か出て、ところどころ表示がおかしくなる傾向が出ていた。あと、液晶に特定の色が表示されているとおぼしきところがノイズでちらちらしたり。いずれにせよ、液晶の電源をいったん落として、再度、入れると直ったりする、ややこしい症状。

最初はこんなもんかなぁと思ってしばらく使っていたけど、なんとなく、いらいらしてきたのでDELLに電話してみた。そしたら、静電気が疑われるとのこと。液晶の電源を引っこ抜いて、電源ボタンを20回くらい押しまくってくれと言われた。素直に電源ケーブルを外して、電源ボタンを押しまくって、再度、電源をつっこむと普通に点いた。

…いや、点くのは点くんだよね。使っていると、時折、ノイズが出て、表示がおかしくなるのがタチ悪いわけで(汗)DELLのサポート担当には、今、その症状が出ているわけではなくて、こんなことをやっても再現性とか難しいと伝えてはみたのだが、しばらく様子を見てくださいと言われた。

これまで液晶を何枚も使ってきたが、(1)静電気がたまって、(2)それを取り除くために、電源を外して、電源ボタンを連射するなんて初めてなんだけどなぁ。。。