プライマリ・セカンダリともにIPアドレスを固定すること。→ 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
xfs_growfs /mnt
umount /mnt

/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
とすれば、データがリセットされ相手側ノードからの再同期が開始する。