タグ: はてなダイアリーからの移行記事 (18ページ目 (18ページ中))

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)それを取り除くために、電源を外して、電源ボタンを連射するなんて初めてなんだけどなぁ。。。