ふたつの川うるおう日記
2008-11-30 (Sun)
_ [Server][Admin][Linux] DRBD 8.3がでるらしいと書いた傍からDRBD 8.3.0 rc1がリリースされた
昨日、DRBD 8.3からは16TBのブロックデバイスを3台以上で同期できるようになると書きましたが、書いた傍からDRBD 8.3.0 rc1がリリースされました。
ちょっと見てみたところDRBD+にあった機能がそのままマージされたようで、同期台数が3台以上というのはDRBD+にあった通常の2台構成の上にVIPでサービスした運用ノードと同期するディザスタリカバリノード(バックアップノード)での同期という意味だったようです。そんなわけでクラスタファイルシステム用の共有ディスクとして3台以上で使うのは本来、意図された使い方ではなさそうです。それでも、バックアップノードを確保でいるのは嬉しいのに違いはありませんね。
なお、3台以上でってのはDRBD 9でDevice-Mapperと組み合わせた形で開発しているようです。
2008-11-29 (Sat)
_ [Server][Admin][Linux] DRBD 8.3からは16TBのブロックデバイスを3台以上で同期できるようになる
昨日、DRBD 8.xで初期同期をスキップする方法を書きましたが、今日もDRBDの話題です。 drbd.orgやMLではまだ話題になっていないようですが、DRBDの元々の開発元であるLINBITは、今年中にDRBD 8.3をリリース予定であるとプレスリリースを出しています。
このDRBD 8.3では、これまで商用版であったDRBD+とオープンソース版DRBDが1つに統合され、GPLライセンスの元にすべての機能が使えるようになるとあります。具体的には今までオープンソース版で制限されていた1リソース4TB制限が無くなり16TB使え、さらに同期台数が2台だったのが、3台、4台で同期できるようになります!
詳細については、以下のブログにも書かれていますのでそちらも要チェックです。
- DRBD+ is going open source! << Florian’s blog (LINBITのPartner Manager and Senior Consultant)
3台以上で同期できることにより、ネットワークに掛かる負荷は増加することになりますが、より安心できるバックアップ環境を手に入れられきますし、GFSやOCFS2といったクラスタファイルシステム用の共有ディスクとして使うにしても、2ノードゆえの問題も解決し、ますますそのメリットを享受できるようになります。
drbd.orgのgitリポジトリにはまだdrbd-8.3のリポジトリは追加されていませんが、プレスリリースどおり年内に出るのであれば、クリスマスプレゼントとしてリリースされるんじゃないかと勝手に思っています。何にしてもリリースが楽しみですね。
2008-11-28 (Fri)
_ [Server][Admin][Linux] DRBD 8.xで初期同期をスキップする方法
DRBD 8.xでの初期同期をスキップする日本語での説明が無さそうなので、メタデータの状態がどのように変わっていくのかを説明しながら書きます。 手順的にはLINBITのWikiに書いてある手順そのままです。
あらまし
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 -> 0x0000000000000000)
注意
手順に出てくる 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 が設定されました。この値は次回同期時にすべてのデータを同期する必要がある状態と認識されてしまうため、同期されていると認識されるように 0x0000000000000000 に変更します。
変更するためにメタデータを dump します。
(2ノードで実施) # drbdadm dump-md drbd1 > drbd1.dat
後で比較するためにオリジナルのメタデータをコピーしておきます。
(2ノードで実施) # cp -a drbd1.dat drbd1.dat.default
dump したファイル内の bitmap の初期値 0xFFFFFFFFFFFFFFFF を 0x0000000000000000 へ変更します。
(2ノードで実施)
# sed -i -r -e 's/0xF{16}/0x0000000000000000/g' drbd1.dat
変更出来ているか確認します。
(2ノードで実施) # diff drbd4.dat.default drbd4.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での初期同期のスキップ方法はウノウラボさんのところにありますのでそちらを見ると良いと思います。
2008-11-24 (Mon)
_ [大学] 東京工業大学クローバルCOEプログラム”計算世界観の深化と展開”
12月2日(火)、3日(水)、4日(木)の東工大でのCompViewシンポジウム2008にNVIDIAのCEOであるジェン・スン・ファン氏が来るらしい(2日17時〜18時)。うちの大学のCG関係やってる人達行ってみると良いんじゃないかな。
僕は同じ頃、京都にいる予定。
2008-11-05 (Wed)
_ [Seasar][Project][Server][Admin] Seasar Project用のHudsonテスト環境
Seasar Project用のHudsonテスト環境を用意しました。コミッタの皆さんいろいろな設定のジョブを登録してみてください。
サンプルで1個登録してありますが、Hudsonの使い方が良く判っていないのでもっと良い方法があると思います。追加されたジョブ設定を見て、良い使い方をWikiに用意したHudsonのページに集めていきます。
Pluginは適当に次のを入れてあります。他にオススメのものがあれば是非教えてください。
- Disk Usage Plugin
- JIRA Plugin
- Task Scanner
- Checkstyle Plugin
- FindBugs Plugin
- PMD Plugin
- Warnings Plugin
Hudson導入に関して、開発者であるid:kkawaさんとid:cactusmanさんからご協力のお申し出をいただいております。何か困ったことが起きてもこれで大丈夫です!ありがとうございます。
また、紹介してくださったid:skirnirさんとid:j5ik2oさんありがとうございます。
2008-11-02 (Sun)
_ [Server][Admin][Linux] RRDtoolのデータファイルをi386からx86_64環境へ移行する
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
終わり。
2008-10-29 (Wed)
_ [Server][Admin][Linux] Munin ipmitool_sensor_ Plugin

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が使えるマシンを使っている方は是非お試しください。
2008-10-28 (Tue)
_ [Server][Admin] HDD故障: WDC WD10EACS-00D6B0 1TB

最近いろいろなとこでサーバを交換する作業をしています。このサイトが動いてるサーバもリース切れになるので新しいサーバを準備しています。今度のサーバはHP ProLiant ML110 G5にパーツを追加したマシンです。
準備中、だいぶ前に買って使っていなかった未使用Western Digital WDC WD10EACS-00D6B0 1TB 1台がすぐにS.M.A.R.T.でエラー吐いて死ぬことに気付きました。Western DigitalのData Lifeguard DiagnosticsのEXTEND TESTを実行してみてもエラーが出たのでこれはもうダメそうです。というわけでRMAという制度を利用して交換してもらおうと思います。
サーバは、代わりの部品としてWESTERN DIGITAL WD1001FALS 1TBを買って環境未構築状態でもう設置しちゃいました。HDDがWD10EACS-00D6B0からWD1001FALSになって性能良くなったので良しとします(実際には1TB * 4台構成中の1台なので1台だけ速度早くてアンバランスだけど)。
2008-10-18 (Sat)
_ [Java][Server][Admin] さりげなく安全ではないMavenへの対策
- [#MNG-2477] Implement repository security improvements for verification of downloaded artifacts
- Repository Security Improvements
将来的には安全になる様子。誰が署名するのってもあるけどとりあえずは。



_ nasobeme [ありがたく使わせてもらってます。 ただ、fanのucrが"inf"になるパターンがありました。こんな感じ↓ FAN..]
_ nasobeme [つづけて。 volt_threshold()でlncとuncを出してるところで unc = $ucr * (100..]
_ jfut [ご指摘ありがとうございます。 inf 対応と $unc が正しい値になるように修正したものを下記にアップしました。 ..]
_ nasobeme [ありがとうございます。 こっちの環境でも試してみます。]
_ nasobeme [一個目のコメントで書いた、 FAN1 ROTOR1 | 7680.492 | RPM | ok | na | in..]
_ jfut [man ipmitoolの説明によると次の割り当てになるようなので1000.400はucrでOKだと思います。 FA..]
_ nasobeme [ボードの方が正しい順番で値を出してないみたいですね。 1000.400がucrだとすると、currentの回転数が7..]
_ jfut [なるほどです。見落としていました。 lcr、lncにinfの時も値をひっくり返すようにしましたのでお試しください。 ..]
_ nasobeme [新しいスクリプトでconfig実行してみました。 /etc/munin/plugins/ipmitool_sens..]
_ jfut [動作確認ありがとうございます。上手くいってそうですのでMuninExchangeへもアップロードしておきました。]