Home > Linux
Linux Archive
XenからKVMへ、ファイルからLVMへ
この日記が動いてるサーバはまだXenですが、新しく仮想マシンをたくさん作る機会があったので、XenからKVMに乗り換えました。OSはdebootstrapになっていますが、virt-installで強引なことしているのでDebianじゃなくてCentOSに入れ替わっています。
# gnt-instance list Instance Hypervisor OS Primary_node Status Memory admin1.example.org kvm debootstrap node1.example.org running 1.0G admin2.example.org kvm debootstrap node2.example.org running 1.0G cron1.example.org kvm debootstrap node1.example.org running 1.0G db1.example.org kvm debootstrap node1.example.org running 1.0G ftp1.example.org kvm debootstrap node2.example.org running 512M irc1.example.org kvm debootstrap node1.example.org running 512M lvs1.example.org kvm debootstrap node2.example.org running 512M lvs2.example.org kvm debootstrap node1.example.org running 512M mail1.example.org kvm debootstrap node1.example.org running 1.0G mail2.example.org kvm debootstrap node2.example.org running 1.0G nouse.example.org kvm debootstrap node2.example.org ADMIN_down - template.example.org kvm debootstrap node1.example.org ADMIN_down - web1.example.org kvm debootstrap node2.example.org running 1.0G web-ssl1.example.org kvm debootstrap node1.example.org running 1.0G web-ssl2.example.org kvm debootstrap node2.example.org running 1.0G
ディスクイメージもファイルからLVMへ乗り換えました。I/O的にも早くなりましたし、1仮想マシンに1LV割り当てたのでライブマイグレーションも出来るようになりました。
# cat /proc/drbd
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by mockbuild@v20z-x86-64.home.local, 2009-08-29 14:07:55
1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:1030228 nr:0 dw:1030228 dr:515856 al:499 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
2: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:684592 dw:684592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
3: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:282556 nr:0 dw:282556 dr:432780 al:226 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
4: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:594628 dw:594628 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
5: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:281224 nr:0 dw:281224 dr:433112 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
6: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:281116 dw:281116 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
7: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:281048 nr:0 dw:281048 dr:432008 al:227 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
8: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:283900 dw:283900 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
9: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:286256 nr:0 dw:286256 dr:430084 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
10: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:281384 dw:281384 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
11: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:306608 nr:0 dw:306608 dr:532548 al:286 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
13: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:681680 nr:0 dw:681680 dr:823276 al:468 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
14: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
ns:0 nr:571076 dw:571076 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
100: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
ns:48640 nr:0 dw:48640 dr:217 al:23 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
101: cs:Connected ro: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 ep:1 wo:b oos:188
今回KVMを使ってみて、XenとKVMでは、ホストマシン上でのCPU(uptime)とメモリ(free)の表示が違っていることに気付きました。
Xenを使った時のuptimeの表示は、ホスト側も特殊なDom0 Kernelなのでゲスト側でCPUに負荷が掛かってもホスト側のuptimeにその負荷具合が反映されませんでした。一方、KVMの場合はゲストマシンは1プロセスとして見えるので、ゲスト側に負荷を与えるとホスト側のuptimeの表示に負荷具合が反映されました。
Xenを使った時のfreeの表示は、dom_mem0を指定していない場合、割り当てたメモリ分だけtotalの値が減り、ホスト側では見えなくなります。一方、KVMの場合は起動時に指定したメモリを上限とし、実際にゲスト上でメモリが使用されるとホスト側のfreeが消費されてusedが増えていき、totalの値は常に物理メモリの量のままでした。つまり常に動的なバルーン機能が働いているような状態。もしくは、Sparseファイルのメモリ版のような状態。
どちらが良いかは好みですが、ホスト側で状況を把握できるKVMの方が良い気がしています。あと、最近はXenよりKVMが推されているようなので今後はXenとKVMどちらでも良い場合はKVMを使っていこうと思っています。
- コメント: 0
- Trackbacks: 0
DRBD 8.3.x + Heartbeat 2.1.4 + CRMのDRBDリソース を使用する場合の修正
- DRBD 8.3.x + Heartbeat 2.1.4 を使用する場合、この修正が必要です。
- DRBD 8.2.x + Heartbeat 2.1.4 を使用する場合、この修正は不要です。
DRBD 8.3.x にアップデートしたら、HeartbeatでCRMのDRBDリソースが上手く動かなくなりました。以下のようなエラー。
lrmd[11950]: 2009/09/03_14:15:12 info: rsc:drbd1:0: start crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op: Performing op=drbd1:1_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op: Performing op=drbd1:0_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) lrmd[11950]: 2009/09/03_14:15:12 info: RA output: (drbd1:0:start:stdout) 1: Failure: (124) Device is attached to a disk (use detach first) Command 'drbdsetup 1 disk /dev/VolGroup01/DRBD1 /dev/VolGroup01/DRBD1 internal --set-defaults --create-device' terminated with exit code 10 drbd[12636]: 2009/09/03_14:15:12 ERROR: drbd1 start: not in Secondary mode after start. crmd[11953]: 2009/09/03_14:15:12 info: process_lrm_event: LRM operation drbd1:0_start_0 (call=16, rc=1) complete
原因はDRBDリソースが drbdadm state コマンドを使っているせいです。8.3からは drbdadm role コマンドを使うのが正しいそうです。以下、drbdadmコマンドの実行例です。
# drbdadm state drbd1 drbdadm state' is deprecated, use 'drbdadm role' instead. Primary/Secondary
1行目の警告が邪魔してHeartbeatが上手く動かないようです。しょうがないので手動でDRBDリソース /usr/lib/ocf/resource.d/heartbeat/drbd を修正しましょう。以下、修正後のdiffです。
# diff /usr/lib/ocf/resource.d/heartbeat/drbd.default /usr/lib/ocf/resource.d/heartbeat/drbd 235c235 < DRBD_STATE=$(do_drbdadm state $RESOURCE) --- > DRBD_STATE=$(do_drbdadm role $RESOURCE)
これで上手く起動するようになります。たぶん、Heartbeat 2.1.5 がリリースされれば修正されたものがインストールされます。
ちなみに Heartbeat 2.1.3 の Master/Slaveリソースはバグってて、1個のMaster/Slaveリソースでフェイルオーバが始まると他のすべてのMaster/Slaveリソースも一旦ダウンしてしまうので使わない方が良いです。
- コメント: 0
- Trackbacks: 0
CentOS 4 と CentOS 5 のDRBDパッケージに8.3.x系が加わる予定
後輩から教えて貰いました。CentOS 4 と CentOS 5 のDRBDパッケージにDRBD 8.3系が加わるようです。来週リリースされるらしいので準備しておきましょう。
今までCentOS 5では、DRBD 8.0系と8.2系があって、それぞれdrbd-8.0.x, kmod-drbd-8.0.xとdrbd82-8.2.x, kmod-drbd82-8.2.xというパッケージがありましたが、これにdrbd83-8.3.x, kmod-drbd83-8.3.xが加わるようです。
パッケージ名が違うので勝手に入ることはないと思いますが既に使っている方は把握しておいた方が良いでしょう。既に使っていて8.3系に更新する場合は、上記のブログではセカンダリノードから更新していく手順が書かれています。
手元の環境はたすき掛けにしているので、結果的に一気にやることになりますね。
[追記] 9/2にリリースされました。
- コメント: 0
- Trackbacks: 0
OpenSSH-LPK Patch for OpenSSH 5.2p1
OpenSSH-LPK Patch はだいぶ昔に本家 OpenSSH にマージの提案が出てたけどそれっきりペンディング(?)状態で、OpenSSH-LPKのサイトも流浪を続け今はGoogle Codeにいました。
とりあえず自分が必要なので OpenSSH 5.2p1 にあたるPatchを用意しました。
- openssh-lpk-5.2p1-0.3.10.patch
- ベース: contrib-openssh-lpk-5.1p1-0.3.10.patch
- これは openssh-lpk-*-0.3.9.patch に 64-bit環境対応Patchがあたったもの (Gentoo Bug 210110 – ~net-misc/openssh-4.7_p1: LPK fix for 64-bit Linux)
- ベース: contrib-openssh-lpk-5.1p1-0.3.10.patch
ただし、Patch FAILEDを直しただけ。一応最低限の動作確認はしてあります。
OpenSSH-LPKに対応した公開鍵をLDAPでコマンドラインで管理したいなら、smbldap-ssh-tools? が便利です。Javaから扱いたいなら S2Directory が便利です。
- コメント: 0
- Trackbacks: 0
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
- コメント: 0
- Trackbacks: 0
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が出てからになりそうです。
- コメント: 0
- Trackbacks: 0
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
- コメント: 0
- Trackbacks: 0
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と組み合わせた形で開発しているようです。
- コメント: 2
- Trackbacks: 0
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のリポジトリは追加されていませんが、プレスリリースどおり年内に出るのであれば、クリスマスプレゼントとしてリリースされるんじゃないかと勝手に思っています。何にしてもリリースが楽しみですね。
- コメント: 0
- Trackbacks: 0
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での初期同期のスキップ方法はウノウラボさんのところにありますのでそちらを見ると良いと思います。
- コメント: 0
- Trackbacks: 0
ホーム > Linux
-
書いている人: ふたがわ (jfut)
主な内容: サーバやJava関係の話題など
-
- 2010-01
- 2009-11
- 2009-10
- 2009-09
- 2009-08
- 2009-07
- 2009-05
- 2009-04
- 2009-03
- 2009-02
- 2009-01
- 2008-12
- 2008-11
- 2008-10
- 2008-09
- 2008-08
- 2008-07
- 2008-06
- 2008-05
- 2008-04
- 2008-03
- 2008-02
- 2008-01
- 2007-12
- 2007-11
- 2007-10
- 2007-09
- 2007-08
- 2007-07
- 2007-06
- 2007-05
- 2007-04
- 2007-03
- 2007-02
- 2007-01
- 2006-12
- 2006-11
- 2006-10
- 2006-09
- 2006-08
- 2006-07
- 2006-06
- 2006-05
- 2006-04
- 2006-03
- 2006-02
- 2006-01
- 2005-12
- 2005-11
- 2005-10
- 検索
- フィード
- メタ情報