Linux Archive

DRBD 8.xでの初期同期をスキップする日本語での説明が無さそうなので、メタデータの状態がどのように変わっていくのかを説明しながら書きます。手順的にはLINBITのWikiに書いてある手順そのままです。

• How to circumvent the initial resync. skip-initial-sync

あらまし

DRBDを使い始めるには対となるブロックデバイス同士を一度フル同期する必要がありますが、仮にDRBDリソースに1TB割り当てて平均50MB/secで同期される環境の場合(実際には1TBのHDDで1TB使えるわけではないですが)、

1024000(MB) / 50(MB/sec) / 60(秒) / 60(分) = 5.68時間

掛かります。初めて使用するHDDの場合は、フル同期することでHDD上の不良箇所がないかのテストにもなるのでスキップせずに同期するのが良いと思いますが、実験などで何回もDRBDリソースを構成し直す場合は面倒です。というわけで、初期同期をスキップします。DRBD 0.7ではスキップ用のPerlスクリプトが用意されていましたが、DRBD 8.xではいくつかのコマンドを実行してスキップすることができます。

環境とポイント

試した環境は次のとおりです。

• CentOS 5.2 x86_64
• drbd82-8.2.6-1.el5.centos + kmod-drbd82-xen-8.2.6-2 (CentOS Extras)
• DRBDの設定は完了済み
  • 対象リソース: drbd1 (465GのLVM論理領域)
• /etc/init.d/drbd start で起動済み

スキップするためのポイントは次のとおりです。

• Current data generation UUID を 2 以上で併せる (0, 1は不可)
• Data consistancy flag を 1 にする
• bitmap をリセットする (0xFFFFFFFFFFFFFFFF -> 0×0000000000000000)

注意

手順に出てくる drbd1 は /etc/drbd.conf で定義しているリソース名です。環境に併せて読み変えてください。通常 r0 や drbd0 から設定する例が多いですが、複数DRBDリソースがある時に判りやすいように drbd1 から設定しています。

resource drbd1 {
  ...
  on ... {
    device /dev/drbd1;
  }
}

手順

DRBDを起動して、2ノードとも Unconfigured になっているか確認します。

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
 1: cs:Unconfigured

なっていない場合は、対象リソースを2ノードとも down させます。

(2ノードで実施)
# drbdadm down drbd1

Unconfigured になっているか確認したら、2ノードでDRBDのメタデータを新規に作成します。

(2ノードで実施)
# drbdadm create-md drbd1

この時、メターデータは次のような状態になっています。

# drbdadm show-gi drbd1
       +--<  Current data generation UUID  >-
       |               +--<  Bitmap's base data generation UUID  >-
       |               |                 +--<  younger history UUID  >-
       |               |                 |         +-<  older history  >-
       V               V                 V         V
0000000000000004:0000000000000000:0000000000000000:0000000000000000:0:0:0:0:0:0
                                                                    ^ ^ ^ ^ ^ ^
                                      -<  Data consistancy flag  >--+ | | | | |
... 省略 ...
zero size device -- never seen peer yet?

• 注目点
  • Current data generation UUID の値
  • Data consistancy flag が 0
  • zero size device — never seen peer yet? になっている

# drbdadm dump-md drbd1
... 省略 ...
version "v08";
... 省略 ...
uuid {
    0x0000000000000004; 0x0000000000000000; 0x0000000000000000; 0x0000000000000000;
    flags 0x00000000;
}
la-size-sect 0;
bm-byte-per-bit 4096;
device-uuid 0xDE2945EBEA68D659;
# bm-bytes 0;
bm {
}
# bits-set 0;

• 注目点
  • la-size-sect, bm-bytes, bits-set が 0
  • bm {} の中が空

2ノードが同期されているように見せかけるため、ダミーのdata generation UUIDを設定し、Data consistancy flag を 1 にします。

(2ノードで実施)
# drbdadm -- 6::::1 set-gi drbd1
previously 0000000000000004:0000000000000000:0000000000000000:0000000000000000:0:0:0:0:0:1
set GI to  0000000000000006:0000000000000000:0000000000000000:0000000000000000:1:0:0:0:0:1
Write new GI to disk?
[need to type 'yes' to confirm] yes

この例ではLINBITのWikiと同じ 6 にしていますが6以外でも 2 以上の数字であれば大丈夫でした。

この時点では対となるブロックデバイスでDRBDで使用できるサイズが確定していないため、一度DRBDリソースを接続させます。また初めて接続した時に初期値となる bitmap も設定されます。

(2ノードで実施)
# drbdadm up drbd1

接続が上手くいっているか確認します。wfc-timeoutの設定値と drbdadm up drbd1 を2ノードで実行したタイミングによっては上手く接続出来ていない場合があるので注意してください。

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
 1: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:487572924

確認するポイントは、drbdadm — 6::::1 set-gi drbd1 した時に Data consistancy flag を 1 にしたことで同期状態であると見せかけたので、ds状態が Inconsistent/Inconsistent ではなく UpToDate/UpToDate になっていることです。

接続に問題がないことを確認したら一度2ノードともDRBDリソースを down させます。

(2ノードで実施)
# drbdadm down drbd1

down させたら、サイズが確定し、bitmap の初期値が設定されたか確認します。

# drbdadm show-gi drbd1
       +--<  Current data generation UUID  >-
       |               +--<  Bitmap's base data generation UUID  >-
       |               |                 +--<  younger history UUID  >-
       |               |                 |         +-<  older history  >-
       V               V                 V         V
0000000000000006:0000000000000000:0000000000000000:0000000000000000:1:1:0:0:0:0
                                                                    ^ ^ ^ ^ ^ ^
                                      -<  Data consistancy flag  >--+ | | | | |
                             -<  Data was/is currently up-to-date  >--+ | | | |
... 省略 ...
last agreed size: 464 GB

464GBと認識されました。

# drbdadm dump-md drbd1
... 省略 ...
version "v08";
... 省略 ...
uuid {
    0x0000000000000004; 0x0000000000000000; 0x0000000000000000; 0x0000000000000000;
    flags 0x00000011;
}
la-size-sect 975145848;
bm-byte-per-bit 4096;
device-uuid 0xDE2945EBEA68D659;
# bm-bytes 15236656;
bm {
   # at 0kB
    1904580 times 0xFFFFFFFFFFFFFFFF;
    0xFFFFFFFFFFFFFFFF; 0x00007FFFFFFFFFFF;
}
# bits-set 121893180;

bitmap の初期値として 0xFFFFFFFFFFFFFFFF が設定されました。この値は次回同期時にすべてのデータを同期する必要がある状態と認識されてしまうため、同期されていると認識されるように 0×0000000000000000 に変更します。

変更するためにメタデータを dump します。

(2ノードで実施)
# drbdadm dump-md drbd1 > drbd1.dat

後で比較するためにオリジナルのメタデータをコピーしておきます。

(2ノードで実施)
# cp -a drbd1.dat drbd1.dat.default

dump したファイル内の bitmap の初期値 0xFFFFFFFFFFFFFFFF を 0×0000000000000000 へ変更します。

(2ノードで実施)
# sed -i -r -e 's/0xF{16}/0x0000000000000000/g' drbd1.dat

変更出来ているか確認します。

(2ノードで実施)
# diff drbd1.dat.default drbd1.dat
23,24c23,24
<     1904580 times 0xFFFFFFFFFFFFFFFF;
<     0xFFFFFFFFFFFFFFFF; 0x00007FFFFFFFFFFF;
---
>     1904580 times 0x0000000000000000;
>     0x0000000000000000; 0x00007FFFFFFFFFFF;

変更したメタデータをDRBDリソースに restore しますが、その前にメタデータをどこに持っているか確認します。

(2ノードで実施)
# drbdadm -d dump-md drbd1
drbdmeta /dev/drbd1 v08 /dev/VolGroup01/DRBD1 internal dump-md

この例では、/dev/VolGroup01/DRBD1 という論理ボリュームに internal として持っているのでそこへ restore します。

(2ノードで実施、2ノードでリストア先の論理領域がそれぞれ違う場合はその環境に併せます)
# drbdmeta /dev/drbd1 v08 /dev/VolGroup01/DRBD1 internal restore-md drbd1.dat

これで初期同期をスキップするための手順は完了です。DRBDリソースを up します。

(2ノードで実施)
# drbdadm up drbd1

/proc/drbd の見た目上の変化がありませんが一応確認です。

# cat /proc/drbd
version: 8.2.6 (api:88/proto:86-88)
GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-x8664-build, 2008-10-03 11:30:32
 1: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 oos:487572924

正しく初期同期がスキップできているか確認するには、適当にファイルシステムを作成した後に接続し直してみると良いです。上手くスキップ出来ていない時は、フル同期が始まります。

(どちらか片方のノードで実施)
# drbdadm primary drbd1
# mkfs.ext3 /dev/drbd1
(2ノードで実施)
# drbdadm down drbd1
# drbdadm up drbd1

まとめ

これで実験環境で何度もDRBDリソースを作り直すことになっても、短時間ですぐに実験できる環境を用意できます。また、障害実験などでSplit-Brainが起きた場合も、それまでのデータがいらなければフル同期するのではなく、DRBDリソースを作り直してしまえばすぐに実験できる状態に戻せます。

ただし、最初にも書きましたが、初めて使用するHDDの場合は、フル同期することでHDD上の不良箇所がないかのテストにもなるのでスキップせずに同期した方が良いと思います。

DRBD 7.xでの初期同期のスキップ方法はウノウラボさんのところにありますのでそちらを見ると良いと思います。

• ウノウラボ Unoh Labs: DRBDによるコンテンツの相互バックアップ

RRDtoolのデータファイルはアーキテクチャに依存しているようで、i386環境で使っていたRRDファイルをx86_64環境にコピーすると次のように怒られました。

This RRD was created on other architecture

rrdtool dumpでXML形式にダンプできるようなので、1回ダンプしてrrdtool restoreすればOKっぽいのでそうします。

# old i386 machine
cd $DATA
mkdir dump
for i in *.rrd; do rrdtool dump $i > dump/$i; done
rm *.rrd -rf

$DATA ディレクトリを丸ごと新しいマシンへ移動

# new x86_64 machine
cd $DATA/dump
for i in *; do rrdtool restore $i ../$i; done

終わり。

Muninでマシンのファン回転数、温度、電圧をグラフ化するにはsensor_というPluginを使うのが楽です。ただし、このPluginはlm_sensorsの値を見るので、比較的新しい対応していないマザーボードだと値を取ることができません。そんな対応していないマザーボードでも、最近のサーバ用マシンであればIPMIが入っているので、IPMI経由で取得した値を使ってファン回転数、温度、電圧をグラフ化すれば良いです。

そんなわけで、Munin用のIPMIを使ったPluginを調べたところ次の3つありました。

• ipmi_sensor_ (Ruby)
• ipmi_ (Python)
• ipmisensors (バイナリ?)

1個目が良い感じなのですが、自分の環境だとそのままでは動かなかったのと、HP ProLiant ML110 G5(Lights-Out 100)のセンサーのアラート出す閾値の出力がどうも逆さになってるっぽい箇所があり、しょうがないので別のPluginを作りました。

• ipmitool_sensor_ (Perl)

このPluginは、sensor_ のコードをベースにしています。なのでPerlです。まだまだデフォルトでRuby入っていない環境もあるので良いかなと思います。

以下、CentOS 5.2環境での使い方。Muninは導入済みとします。

• 必要なIPMIに関するパッケージをインストールしてIPMI用Kernelモジュールのロード

yum -y install OpenIPMI OpenIPMI-tools
chkconfig ipmi on
/etc/init.d/ipmi start

• 動作確認

ipmitool sensor

値がバラバラでてくればOKです。

• Muninへipmitool_sensor_ Plugin導入

便宜上、/usr/share/munin/plugins/ipmitool_sensor_ にPluginをダウンロードしてあることにします。

ln -s /usr/share/munin/plugins/ipmitool_sensor_ /etc/munin/plugins/ipmitool_sensor_fan
ln -s /usr/share/munin/plugins/ipmitool_sensor_ /etc/munin/plugins/ipmitool_sensor_temp
ln -s /usr/share/munin/plugins/ipmitool_sensor_ /etc/munin/plugins/ipmitool_sensor_volt

• munin-node 設定

[ipmitool_sensor*]
user root
timeout 20

オプションで次の値が設定できます。

env.ipmitool          - ipmitool command (default: ipmitool)
env.ipmitool_options  - ipmitool command options (default: sensor)
env.cache_file        - cache file
                        (default: /var/lib/munin/plugin-state/plugin-ipmitool_sensor.cache)
env.cache_expires     - cache expires (default: 275)

env.fan_warn_percent  - Percentage over mininum for warning
env.volt_warn_percent - Percentage over mininum/under maximum for warning
                        Narrow the voltage bracket by this.

• munin-node 再起動

/etc/init.d/munin-node restart

これで、添付してある画像のようにグラフが作られます。

Dell PowerEdge 1800(BMC)とHP ProLiant ML110 G5(Lights-Out 100)で使っていますが両方ともうまく動いています。HPの方のipmitool sensorによる値取得は値が取れるまでちょっと時間が掛かりますが、env.cache_fileにenv.cache_expires秒だけキャッシュするようにしているのでMunin本体が毎回グラフ作成時(デフォルトだと5分毎)に値を取りに行っても2つ目のグラフ作成時はキャッシュが使われるので良い感じに動きます(この機能はRubyで書かれたipmi_sensor_にもあります)。

というわけで、lm_sensorsで値とれないけどIPMIが使えるマシンを使っている方は是非お試しください。

• [2009-02-08追記] 2009-02-08 (Sun) – Munin Plugin: ipmitool_sensor_ 1.4

GAはGeneral Availableかな。Betaにあったとおりsyslogがrsyslogになった。

手動で入れる必要があったドライバとかサポートされてなかったチップセットが通るか試しに入れようと思ってRHNにアクセスしたものの、生きてて使えるライセンスがなかた。。

• openssh-lpk-5.0p1-0.3.9.patch

ただし、Patch FAILEDを直しただけ。

Red Hat Enterprise Linux 5.2からsysklogdに代わってrsyslogってのが標準になるそうです。syslog-ngはライセンスと設定ファイルの互換性の問題から消えたそうな。rsyslogには、

• TCPでのログメッセージ転送
• セキュア転送
• データベースバックエンド

などの特徴があり、syslog-ngを導入したいキッカケとなる(?)TCPでのログメッセージ転送もあるので、多くの場合の要望を満たせると思います。

ただ、設定ファイルが、互換性あるにはあるけど、もともとsyslogの設定ファイルは見難いのでsyslog-ngの設定の方が判り易いです。

• rsyslog.conf configuration file

Xenが3.1.2になった。試すならRHNからダウンロードできます。

意外とCentOS 5と違う点がある。土日潰して検証して良かった。

• CentOS 5にあるyum-cronがない
  • 代替1: 標準の yum-updatesd を設定する
    • 5.0で登場した最初に登場した yum-updatesd がバグってた(アップデートされない)のでCentOS 5.xではyum-cron使ってました
    • 設定: /etc/yum/yum-updatesd.conf
  • 代替2: RHELらしくRHNでスケジュール組んで、rhnsdに任せる
    • 設定: /etc/sysconfig/rhn/rhnsd

あと、RHEL4までのup2dateが無くなっているので、RHELでも標準となったyumを使いましょう。

Mailman.Handlers.ToDigestがエラー吐かずにCPU食いまくってロック握ったまま落ちるものの、次のキュー処理し続けてる(ロックは解除されてないのでそのまま無限ループ)のは原因探すの難しいです。

対処方法は、$MAILMAN_HOME/lists/ML名/digest.mbox をリネームしました。

この問題が実は配送遅延してた原因の1つでもあるような気がするので、そっちも解決したならめでたしめでたし。

問題無く認識します。

ただ、個人的な問題はShuttleの最近のCubeマシンが3ware 9650SE-2LP BIOSを認識してくれないこと・・・。おかげで使えない(泣。

PCI ExpressとPCIスロットが1スロットずつあって、PCI Expressの方がビデオカードを想定してか、マザー内臓ビデオカードとぶつからないように起動時にディレイが入ってるようで、そのせいでRAIDカードのBIOSが認識されないっぽい。PCIスロットに3ware 9500Sなら認識するもののそれだとだいぶ速度が劣るから微妙なところ。