レプリケーションによるクラスタ構成の設定
プライマリ・セカンダリともにIPアドレスを固定する。
ここの例では下記のようなアドレスを使用する。
HATEST01: 192.168.61.201
HATEST02: 192.168.61.202
また、HATEST01側で既に仮想マシン aipo が論理ボリューム /dev/wbvg/aipo にセットアップされている状態を仮定する。
最初に両者でレプリケーション用の論理ボリュームを作成する。
lvcreate --addtag @wbdrbd -n drbd0 -L 3G wbvg
このボリュームをコピー元より大きいサイズで作成しておくことで xfs_copyによる高速なコピーを行うことが出来る。(コピー完了後、マウントして xfs_growfsを実行することで容量を無駄なく使うことができる)
次に/etc/drbd.d/aipo.res を両方にて作成
resource aipo {
net {
allow-two-primaries;
}
startup {
wfc-timeout 60;
}
on HATEST01 {
device /dev/drbd0;
disk /dev/wbvg/drbd0;
address 192.168.61.201:7789;
meta-disk internal;
}
on HATEST02 {
device /dev/drbd0;
disk /dev/wbvg/drbd0;
address 192.168.61.202:7789;
meta-disk internal;
}
}
レプリケーション用のデバイスを初期化する
drbdadm create-md aipo
と入力して
Writing meta data...
initializing activity log
NOT initialized bitmap
New drbd meta data block successfully created.
のような表示が出れば初期化出来ている。
レプリケーションサービス(DRBD)を起動する
/etc/init.d/drbd start
システムの次回起動時にレプリケーションサービスを自動起動させるためには下記のようにする。
rc-update add drbd default
DRBDが起動したら、状態を確認する
cat /proc/drbd
version: 8.3.7 (api:88/proto:86-91)
built-in
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent 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:3145596
両者ともセカンダリかつ Inconsistent/Inconsistent になっている。ここではHATEST01をプライマリにする。HATEST01にて下記を実行
drbdadm -- --overwrite-data-of-peer primary aipo
もう一度 cat /proc/drbd をすると、プライマリ/セカンダリが確定しかつ同期が進行中であることがわかる。
同期速度は設定しないと遅い。
drbdsetup /dev/drbd/by-res/aipo syncer -r 4M
デバイス /dev/drbd/by-res/aipo がこの時点からプライマリ側で書き込み可能になるので、xfs_copyで 仮想マシンをコピーする。
xfs_copy /dev/wbvg/aipo /dev/drbd/by-res/aipo
仮想マシンをコピーした後に、xfs_growfsでファイルシステムのサイズをコピー先のデバイスに合わせる
mount /dev/drbd/by-res/aipo /mnt/floppy
xfs_growfs /mnt/floppy
umount /mnt/floppy
/etc/xen/aipo を開き、phy:/dev/wbvg/aipo となっている部分を drbd:aipo に変更する。また、同ファイルをセカンダリノードにもコピーする。
プライマリノード側WBUIから仮想マシンを起動する。以降、この仮想マシンのデータはセカンダリにも常に同期される。プライマリノードに障害が起こった場合、プライマリノードをシャットダウンしセカンダリノードのWBUIで同じ仮想マシンを起動すればセカンダリノードは自動的にプライマリへ昇格され稼働を開始する。
プライマリノードで仮想マシンが稼働しているにもかかわらずセカンダリノードで同じ仮想マシンを絶対に起動しないこと。そのような操作はスプリットブレイン・シンドロームを起こし、最悪の場合せっかくレプリケーションされているデータは一度に両方とも破壊されてしまう。
実際に障害が起きた際には、出来るだけ障害ノードの電源を切ってからセカンダリノードの昇格を行うほうが安全である。
複製対象のデバイスをファイルシステムにマウントする
仮想マシンをシャットダウンすると、DRBDのXen連携スクリプトによりデバイスがセカンダリに降格となる。そのため、直接 /dev/drbd/by-res/aipo を mountコマンドでマウントしようとしても
mount: block device /dev/drbd0 is write-protected, mounting read-only
mount: Wrong medium type
と言われてできない。
drbdadm primary aipo
としてプライマリモードに昇格してからマウントすれば成功する。用事が終わった後はアンマウントし、必要ならば
drbdadm secondary aipo
としてセカンダリモードに降格する。
セカンダリノードの復旧方法
セカンダリノードがクラッシュした場合(もしくはプライマリノードがクラッシュし、セカンダリノードがプライマリノードに格上げされた場合)、クラッシュしたノードをパージして新しくセカンダリノードとなるホストをセットアップしたら、同じ手順でdrbdの起動までを行う。それだけで自動的に同期が開始される。
レプリケーションが切れたまま両ノードで運用を継続してしまったら
なんらかの理由でレプリケーションが出来ない状態になったまま両ノードで仮想マシンを走らせてしまうと、もはやレプリケーションが出来る状態に回復したとしても同期をすることは出来ず(互いに別の更新が行われてしまったため)、お互いにStandAloneの状態となってしまう。
drbdadm invalidate aipo
とすれば、データがリセットされ相手側ノードからの再同期が開始する。

