Home > Admin

Admin Archive

Munin Plugin: ipmitool_sensor_ 1.4


以前、2008-10-29 (Wed) – Munin ipmitool_sensor_ Pluginで紹介したMunin用のipmitool_sensor_ Pluginの新しいバージョンをリリースしました。

このバージョンでは、MuninExchangeのコメント欄でBenjamin Pineauさんから提案いただいた次の機能を入れました。

  • デフォルトの "ipmitool sensor" 以外に "ipmitool sdr" の出力形式をサポート
  • Voltagesセンサーと識別する単位として、従来の Volts に加え Watts と Amps を追加
  • センサーを識別する単位を指定するオプションの追加

1つ目の ipmitool sdr を使いたい場合は、/etc/munin/plugin-conf.d/munin-node に次にように設定します。

[ipmitool_sensor*]
user root
timeout 20
env.ipmitool_options sdr

これで ipmitool sensor ではなく、ipmitool sdr が使われるようになります。

ipmitool sensor は、現在のセンサーの値に加えて、ボード自体に予め設定されている閾値を取得します。ipmitool_sensor_ ではボードが有効な閾値を持っている場合は、その値を warning と critical を判断するための閾値に使うようにしています。しかし、いくつかのボードでは、ipmitool sensor による値の取得が遅く、数秒掛かる場合があります。一方で ipmitool sdr は、最低限のセンサー名と現在の値と状態を取得するだけのため、そういった ipmitool sensor による値の取得が遅いボードでも、比較的良好なパフォーマンスで値を取得できます。そのため、ipmitool sensor では timeout したり、ボードへの負荷(?)が気になる方は、ipmitool sdr を使用されると良いです。ただし、ipmitool sdr では閾値の取得が出来ないため、別途 ipmitool_sensor_ のオプションで閾値を手動で設定するか、ipmitool_sensor_ が持つデフォルトの閾値を warning と critical として使うことになります。なお、ipmitool_sensor と ipmitool sdr のどちらを使用しても、上記以外の違いは無く、それ以外のキャッシュの仕組みなどはどちらでも適用されます。

また、スクリプトを改造する方への手助け用に、今回からスクリプト本体の perldoc 用領域にテストデータを入れました。次のように実行するとそのテストデータを使って実行されます。

  • Voltagesの例 
cache_file=ipmitool_sensor_ cache_expires=-1 ./ipmitool_sensor_volt
cache_file=ipmitool_sensor_ cache_expires=-1 ./ipmitool_sensor_volt config
cache_file=ipmitool_sensor_ cache_expires=-1 ./ipmitool_sensor_volt suggest
cache_file=ipmitool_sensor_ cache_expires=-1 ./ipmitool_sensor_volt autoconf

Red Hat Enterprise Linux 5.3 (RHEL 5.3) の気になるとこまとめ


RHEL5.3がリリースされました。

以前のリリースノートより情報量が増えた気がします。そんなわけで流し読みして気になるとこをリストアップしてみました。

  • httpdの64-bit版は32-bit版が一緒にインストールされるとコンフリクトするので削除、今後は32-bit版のみに。5.2で64-bit版を既に入れてる人はアップデートする前に削除を。
    • きちんと違いを理解して64-bit版しか入れてなかった人は困るような
  • Xen + NAT + TX checksum offload時の改良
    • 同じ物理マシン上の仮想マシン2台でLVS-NATすると、CentOS 5.2の標準Xenだとネットワーク速度がひどいことになるのがこの改良に関係していると嬉しいな
  • GFS2正式サポート、kmod-gfs2は削除、標準でKernelと一緒にインストールされる
  • RPMがFedora 9以降で使われている改良版になった
  • dm-multipathがIBM DS4000に対応
  • NetworkドライバのnewにMarvell Yukonドライバが書かれていない
    • のでまだ未対応？
  • 3w-9xxx: 3ware 9690SA対応
  • 仮想マシン1台に対する仮想ディスクの最大利用可能数を16から256個まで増加
  • ext4: Technology Previewsとして入った
  • FreeIPMI: Technology Previewsとして入った、OpenIPMIとの違いは不明
  • yum-utils: –security でセキュリティによる更新のみアップデート適用ができるように
  • Samba: 3.0.x -> 3.2.0へ
  • OpenLDAP: 2.3.27 -> 2.3.43
  • Known Issues: ブート時に /var/log/boot.log にログが残らない
  • java-1.6.0-openjdk-1.6.0.0-0.25.b09.el5: 入った、JBossとの絡み
    • でも、たぶんSunのJDK/JRE使う
  • kernel-2.6.18-53.el5 – kernel-2.6.18-128.el5: 2.6.18系

ここにリストアップしたのは個人的に気になる一部分だけで、他にもCore i7対応やiSCSIまわりの改良など重要な新機能やアップデートがあります。RHEL/CentOS 5.xをお使いの方は、一度Release Notes全体に目を通しておくと良いと思います。

なお、残念ながら自由に遊べるRHEL 5.xのサブスクリションを今は持っていないので、実際僕が触るのはCentOS 5.3が出てからになりそうです。

69.50.142.11からのDNSクエリ


昨日・今日と複数のDNSサーバに69.50.142.11から1サーバに対して10万件くらいのDNSクエリが来てます。

client 69.50.142.11 view external: query (cache) 'aaklglaaaaesh0000dfaaabaaafbecde/NS/IN' denied: 1 Time(s)
client 69.50.142.11 view external: query (cache) 'aaplaeaaaaesh0000dfaaabaaafboiib/NS/IN' denied: 1 Time(s)
...

DoS攻撃かなんかだろうけど、ログが大量に出て邪魔なのでiptablesで弾くかな。

[2009-01-18 00:36 追記] 69.50.142.11以外からも来てるみたいです。

[root@xxxxx ~]# grep named /var/log/messages | cut -d':' -f 4 | cut -d'#' -f 1 | sort | uniq -c | sort -n | tail -5
   2819  client 76.9.16.171
   3409  client 216.201.83.2
   4548  client 216.201.82.19
  22091  client 69.50.137.175
 102486  client 69.50.142.11

最近SeagateのHDDを買った方は確認してみた方が良さそう


SeagateのHDDが大変なことに。 によると、2008年12月以前に生産されたSeagateのBarracuda 7200.11を含む製品のファームウェアに問題があり、突然認識しなくなる可能性があるらしいです。

価格.comの売れ筋ランキングでも今日現在1位、2位にランクインしているST31500341AS (1.5TB SATA300 7200)、ST31000333AS (1TB SATA300 7200) も対象製品なので、ファームウェアのアップデートや交換する必要がある人がたくさんいそうです。最近SeagateのHDD買った方は是非確認を。僕は最近はWestern DigitalのHDDを買ってたので対象製品は持ってませんでした。

次、HDDを買う時には、Western Digital Caviar Blackの2TBが出てて、しかも安くなってると嬉しいなー。

[追記] 該当するHDDかシリアルナンバーのチェックするCheck Serial Numberが公開されました

検索結果からHTMLメールのゴミを除外


Seasarの全文検索で検索するとHTMLメールのHTML部分が添付ファイルとして生成されたもの（Mailmanによって生成されたattachment-XXXX.html）が大量に引っ掛かって、大変残念な感じになっていたので、これらが検索結果に出ないように直しました。

HTMLメールであっても重要なメール本文は別のページに出力されていて、そっちが検索にヒットするのでこの添付ファイルを除外しても問題ありません。

また、title (begin), title (include)でも検索できるように設定を変えました。

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と組み合わせた形で開発しているようです。

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台で同期できるようになります！

詳細については、以下のブログにも書かれていますのでそちらも要チェックです。

3台以上で同期できることにより、ネットワークに掛かる負荷は増加することになりますが、より安心できるバックアップ環境を手に入れられきますし、GFSやOCFS2といったクラスタファイルシステム用の共有ディスクとして使うにしても、2ノードゆえの問題も解決し、ますますそのメリットを享受できるようになります。

drbd.orgのgitリポジトリにはまだdrbd-8.3のリポジトリは追加されていませんが、プレスリリースどおり年内に出るのであれば、クリスマスプレゼントとしてリリースされるんじゃないかと勝手に思っています。何にしてもリリースが楽しみですね。

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 -> 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での初期同期のスキップ方法はウノウラボさんのところにありますのでそちらを見ると良いと思います。

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さんありがとうございます。

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

終わり。

ホーム > Admin

About

書いている人: ふたがわ (jfut)
主な内容: サーバやJava関係の話題など

メールアドレス

最近の投稿
最近のコメント
カテゴリー
アーカイブ
検索
フィード
メタ情報

Return to page top