いま、DRBD9を使う3の理由

2018-06-152018-06-19 1件のコメント

　これまでのDRBDの機能を拡張しSDS用途に開発されたDRBD9ですが、2015年の開発開始からたびたび
の改良を重ねて、本来のDRBDの利用目的であるHAやDRの用途でも安心して使えるようになりました。
drbdmanageやLINSTOR等の管理ツールを使わずに、直接DRBDの設定を書いてDRBD9を運用されている
ユーザも増えています。これから構築するシステムではDRBD8とDRBD9のどちらを使うべきでしょうか?

　今回はDRBD9を積極的に使う3つの理由を紹介します。

1. Pacemakerの設定が簡単

　DRBD8まではDRBDのデバイスにアクセスするために、ノードの状態をPrimaryにする必要がありまし
た。DRBDの状態にはPrimaryとSecondaryの2つがあり、Primaryにしないとデバイスへのアクセスが出
来ないルールがあります。このためDRBDを単独で利用する場合も、Pacemaker等のクラスタ管理ソフト
で利用する場合も、このPrimaryにする操作は必要で面倒な処理になります。

　DRBD9から使えるようになったAuto Promote の機能を使えば、デバイスにアクセスするだけで、
DRBDが自動的にPrimaryにします。そしてデバイスへのアクセスを終了すると、Secondaryの状態に戻し
てくれます。Auto Promoteは安心確実にDRBDのデバイスを管理しますので、Pacemakerの設定を簡略
化できます。設定を簡略化できることで、Pacemakerに熟練していない人にも判り易いシステムを作るこ
とができ、その結果、構築や運用時のコストを減らすことが可能になります。

1.1. DRBD8での設定例

　例として簡単なHAクラスタの設定を紹介します。MairaDB(MySQL)をアクティブ・スタンバイのサー
バで動かす例になります。
　まずはDRBD8に合わせて作った設定です。

primitive res_drbd_r0 ocf:linbit:drbd \　　　　--- DRBDのリソース定義
	params drbd_resource=r0 \
	op start interval=0 timeout=240 \
	op stop interval=0 timeout=100
primitive res_fsmnt Filesystem \
	params device="/dev/drbd0" directory="/drbd" fstype=xfs options=noatime \
	op start interval=0 timeout=60 \
	op stop interval=0 timeout=60
primitive res_ipadr IPaddr2 \
	params ip=10.30.210.100 cidr_netmask=16 nic=eth0 \
	op start interval=0 timeout=20 \
	op stop interval=0 timeout=20 \
	op monitor interval=10 timeout=20
primitive res_mysql mysql \
	params binary="/usr/bin/mysqld_safe" \
	op start interval=0 timeout=120 \
	op stop interval=0 timeout=120 \
	op notify interval=90 timeout=90 \
	op monitor interval=20 timeout=30
group rg_mariadb res_ipadr res_fsmnt res_mysql　
ms ms_drbd_r0 res_drbd_r0 \　　　　　　　　　　　　　　---- MSリソースの定義
	meta master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
location l_mariadb rg_mariadb 100: cluster1.example.com
colocation c_mariadb inf: rg_mariadb ms_drbd_r0:Master　　---- DRBDの制御設定1
order o_mariadb inf: ms_drbd_r0:promote rg_mariadb:start  ---- DRBDの制御設定2
property stonith-enabled=false \
	no-quorum-policy=ignore \
	default-resource-stickiness=20

　このように、DRBDのリソースを定義したり、MSリソースを設定したり、DRBDのPrimary/Secondaryの制御をcolocationとorderで行う必要があります。

1.2 DRBD9での設定例

　次に、DRBD9での設定を紹介します。

primitive res_fsmnt Filesystem \
	params device="/dev/drbd0" directory="/drbd" fstype=xfs options=noatime \
	op start interval=0 timeout=60 \
	op stop interval=0 timeout=60
primitive res_ipadr IPaddr2 \
	params ip=10.30.210.100 cidr_netmask=16 nic=eth0 \
	op start interval=0 timeout=20 \
	op stop interval=0 timeout=20 \
	op monitor interval=10 timeout=20
primitive res_mysql mysql \
	params binary="/usr/bin/mysqld_safe" \
	op start interval=0 timeout=120 \
	op stop interval=0 timeout=120 \
	op notify interval=90 timeout=90 \
	op monitor interval=20 timeout=30
group rg_mariadb res_ipadr res_fsmnt res_mysql
location l_mariadb rg_mariadb 100: cluster1.example.com
property stonith-enabled=false \
	no-quorum-policy=ignore \
	default-resource-stickiness=200

　DRBD9ではデバイスにアクセスすればPrimaryになるため、DRBD関係のリソース設定と制御のコードを書く必要がありません。今回の設定例では、DRBD9に変更した結果Pacemakerのコードを約2/3に減らすことができました。

2.スプリットブレインの危険が減る

　DRBD8を含むいろいろなHAシステムでよく発生する障害はスプリットブレインです。

　両ノードが同時にアクティブ状態になり、データ領域を参照するためデータの不整合や、場合によってはデータの破損が発生する厄介な現象です。DRBDはスプリットブレインになってもデータの破壊を防ぐ仕組みがあるので、スプリットブレインは怖くありませんが、一時的にデータの同期が停止してしまうため、できればその発生は少なくしたいものです。

　ところでDRBD8ではノードを停止する時に、どちらのノードを先に停止するかにより、比較的容易にスプリットブレインが発生します。

　その事例を紹介します。２台のサーバnodeAとnodeBがあり、nodeAでサービスが動いているとします。サーバを停止する時は、まずスタンバイのnodeBを停止したのち、次にnodeAを停止するのが正しい停止の順番です。これを逆に行うと次のようになります。

nodeAが停止する->サービスはnodeBにフェールオーバ
nodeBがアクティブノードになる->データが更新される
nodeBを停止する->データはnodeAより、nodeBが新しい状態になる

次にnodeA、nodeBを起動した場合の動きです。

nodeA、nodeBが起動する->通常nodeAがアクティブ機になる
nodeAとnodeBのデータが比較->nodeAよりnodeBの方が新しくなる
nodeBでスプリットブレインが発生->DRBDの同期が停止する

　これを防ぐ方法は最後に停止したノード（この場合はnodeB）を先に起動して、サービスが動いた後にnodeAを起動することですが、どちらを後で停止したかを常に覚えておくことは難しいですし、緊急時に両ノードを停止した場合はそもそもどちらが先に止まったかは判りません。このためDRBD8の運用では、一時的にDRBDを起動して両ノードのデータを同期してから、サービスを起動する運用方法があります。この方法ならば確実にスプリットブレインを防止できますが、サーバの起動後に自動的にサービスを起動する事が難しくなります。

　DRBD9ではDRBDのサービスはPacemakerから起動せず、通常のサービスと同様に起動スクリプトでサーバ起動時に自動的に動かします。Pacemakerが起動するまでにDRBD間の通信は完了していますので、DRBD8のようにスプリットブレインになることはありません。起動時のスプリットブレインの発生を防止できるため、その危険度を下げることができます。

3.マルチノード構成の設定が容易

　DRBD8まではデータ同期は2ノードでしか行えません。この制限のためDRBDで3ノード以上のデータ同期を行う場合は、スタッキングという手法を使う必要がありました。スタッキングは優れたアイディアですが、その操作は面倒で設定も複雑です。Pacemakerと組み合わせて使う場合は、通常のHAクラスタ構築の設定に加えて、スタッキングの制御もPacemakerの中に書く必要があるため、DRシステムの構築を大変難しくしています。

　DRBD9では設定ファイルに3ノード以上の設定を書くことができるため、もはやスタッキングを使う必要はありません。Pacemakerとの組み合わせも簡単になり、マルチノード構成のシステムの構築や保守が容易になります。

　以上のようにDRBD9でのクラスタの構築はDRBD8と比べて簡単になっているので、これから新しくシステムを構築する時にはDRBD9の利用をご検討下さい。

DRBD Tech Info