Mailing List Archive

DRBDのMaster固定化に関して
お世話になります。あきやまと申します。

DRBDのMaster固定化に関して質問です。

DRBDのスプリットブレインが自動復旧する際のMasterを固定化することは可能でしょうか?
現在運用しているマシンでDRBD通信障害でスタンドアロンになった際に
マシンを再起動しましたが、再起動時にSlave側の古いデータで再同期され、
最新データが消えてしまう事象が発生してしまったので、再発防止策として設定を変更したいと考えています。
本来ならDRBDコマンド等で復旧を試みるべきなのでしょうが、
諸事情あり、詳しくないものが独自の判断で再起動を実施してしまうことがあり、
そのような場合も本事象を発生させないようにしたいと考えています。

【環境】
Red Hat Enterprise Linux Server 6.1 (for x86)
kernel-2.6.32-431.23.3.el6.i686
corosync-1.4.1-17.el6_5.1.i686
pacemaker-1.1.10-14.el6_5.3.i686
drbd-8.3.16-1.el6.i386


【Pacemaker定義】
node testsv1
node testsv2 \
attributes standby=off
primitive res_before_test-e lsb:before_test-e \
op monitor interval=30 timeout=30 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
primitive res_drbd_quota lsb:drbd_quota \
op monitor interval=30 timeout=30 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
primitive res_drbd_r0 ocf:linbit:drbd \
params drbd_resource=r0 \
op monitor interval=10 role=Master timeout=30 \
op monitor interval=30 role=Slave timeout=30 \
op start interval=0 timeout=240 \
op stop interval=0 timeout=100
primitive res_filesystem Filesystem \
params device="/dev/drbd0" directory="/drbd" fstype=ext4
options="noatime,nobarrier,usrquota" \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
primitive res_nmb lsb:nmb \
op monitor interval=30 timeout=30 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
primitive res_pgsql lsb:postgresql-9.0 \
op monitor interval=30 timeout=30 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
primitive res_samba lsb:smb \
op monitor interval=30 timeout=30 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
primitive res_vsftp lsb:vsftpd \
op monitor interval=30 timeout=30 \
op start interval=0 timeout=60 \
op stop interval=0 timeout=60
group rg_filesystem res_filesystem res_drbd_quota
group rg_samba res_samba res_nmb
ms ms_drbd_r0 res_drbd_r0 \
meta master-max=1 master-node-max=1 clone-max=2 clone-node-max=1
notify=true
location l_filesystem rg_filesystem -inf: testsv2
location l_test_drbd ms_drbd_r0 \
rule 200: #uname eq testsv1 \
rule 100: #uname eq testsv2
colocation c_filesystem inf: rg_filesystem ms_drbd_r0:Master
colocation c_test inf: res_before_test-e rg_filesystem
colocation c_pgsql inf: res_pgsql rg_filesystem
colocation c_samba inf: rg_samba rg_filesystem
colocation c_vsftp inf: res_vsftp rg_filesystem
order o_filesystem inf: ms_drbd_r0:promote rg_filesystem:start
order o_test 0: rg_samba res_before_test-e:start
order o_pgsql inf: rg_filesystem res_pgsql:start
order o_samba 0: res_vsftp rg_samba:start
order o_vsftp 0: res_pgsql res_vsftp:start
property cib-bootstrap-options: \
stonith-enabled=false \
no-quorum-policy=ignore \
default-resource-stickiness=200 \
dc-version=1.1.10-14.el6_5.3-368c726 \
cluster-infrastructure="classic openais (with plugin)" \
expected-quorum-votes=2

【DRBD定義】
global {
#usage-count yes;
usage-count no;
# minor-count dialog-refresh disable-ip-verification
}

common {
#protocol C;

handlers {
# These are EXAMPLE handlers only.
# They may have severe implications,
# like hard resetting the node under certain circumstances.
# Be careful when chosing your poison.

# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target
"/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target
/usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
}

startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout
wait-after-sb
}

disk {
# on-io-error fencing use-bmbv no-disk-barrier
no-disk-flushes
# no-disk-drain no-md-flushes max-bio-bvecs
no-disk-barrier;
no-disk-flushes;
}

net {
# sndbuf-size rcvbuf-size timeout connect-int ping-int
ping-timeout max-buffers
# max-epoch-size ko-count allow-two-primaries cram-hmac-alg
shared-secret
# after-sb-0pri after-sb-1pri after-sb-2pri
data-integrity-alg no-tcp-cork
max-buffers 8000;
max-epoch-size 8000;
after-sb-0pri discard-younger-primary;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}

syncer {
# rate after al-extents use-rle cpu-mask verify-alg
csums-alg
rate 30M;
verify-alg sha1;
}
}
Re: DRBDのMaster固定化に関して [ In reply to ]
$B$"$-$d$^$5$s(B

$B>>Eg$H?=$7$^$9!#(B

> DRBD$B$N%9%W%j%C%H%V%l%$%s$,<+F0I|5l$9$k:]$N(BMaster$B$r8GDj2=$9$k$3$H$O2DG=$G$7$g$&$+!)(B
> $B8=:_1?MQ$7$F$$$k%^%7%s$G(BDRBD$BDL?.>c32$G%9%?%s%I%"%m%s$K$J$C$?:]$K(B
> $B%^%7%s$r:F5/F0$7$^$7$?$,!":F5/F0;~$K(BSlave$BB&$N8E$$%G!<%?$G:FF14|$5$l!"(B
> $B:G?7%G!<%?$,>C$($F$7$^$&;v>]$,H/@8$7$F$7$^$C$?$N$G!":FH/KI;_:v$H$7$F@_Dj$rJQ99$7$?$$$H9M$($F$$$^$9!#(B

$BN>J}$N%N!<%I$K=q$-9~$_$,H/@8$7$F$7$^$$!"$?$^$?$^85!9(BSlave$B$@$C$?J}$N%G!<%?$G>e=q$-$5$l$?$H$$$&$3$H$G$7$g$&$+!)(B
IPMI$B$rHw$($k%5!<%P$G$"$l$P!"(BSTONITH$B$r;H$C$F%9%W%j%C%H%V%l%$%s$rKI$0$N$,3N<B$G$9$,!"$3$l$,;H$($J$$>l9g$K$O!"(B
VIPcheck RA$B$rAH$_9g$o$;$k$3$H$G$"$kDxEY2sHr$G$-$k$H;W$$$^$9!#(B
$B2C$($F!"0lC68N>c$7$?%j%=!<%9$r:FAH9~$7$J$$$h$&(B(VIPcheck$B$K$h$C$F3N<B$KAK;_$5$l$k$h$&(B)$B!"(Bmigration-threshold=1$B$rF~$l$F$*$/$HNI$$$H;W$$$^$9!#(B

VIPcheck$B$N;H$$J}$G$9$,!"(B
http://osdn.jp/projects/linux-ha/releases/45456
$B$+$i%@%&%s%m!<%I$7$F!"(BRA$B$rG[CV$5$l$?>e$G!"(B($B<jA0L#A9$G$9$,(B)
http://qiita.com/takehironet/items/08716d3a9d1165f47b5c
$B$G4JC1$K2r@b$7$F$*$j$^$9!#(B
$B%5!<%S%9(BLAN$B>e$KFCDj$N(BIP$B%"%I%l%9$,L5$$$3$H$,$o$+$k$H(BVIPcheck$B$N(BStart$B%"%/%7%g%s$O@.8y$7$^$9!#(B
$BC/$b$9$G$K(BVIP$B$r;}$C$F$$$J$$>uBV$G$"$k$3$H$r3NG'$7$?>e$G!"(BDRBD$B$N(BPromote$B$r<B9T$9$k(B(colocation$B$GG{$j$^$9(B)$B$H$$$&J}K!$K$J$j$^$9!#(B

VIPcheck -> DRBD -> DRBD$B$rMxMQ$9$k%j%=!<%9(B -> IPaddr2
$B$H$$$&N.$l$GG{$j$r$+$1$k$H$$$&$N$r;d$O$h$/;H$C$F$$$^$9!#(B


$B0J>e!"$$$+$,$G$7$g$&$+!)(B

Takehiro Matsushima
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Re: DRBDのMaster固定化に関して [ In reply to ]
松島さん

あきやまです。回答ありがとうございます。

> 両方のノードに書き込みが発生してしまい、たまたま元々Slaveだった方のデータで上書きされたということでしょうか?
そのとおりです。

> IPMIを備えるサーバであれば、STONITHを使ってスプリットブレインを防ぐのが確実ですが、これが使えない場合には、
> VIPcheck RAを組み合わせることである程度回避できると思います。
>
加えて、一旦故障したリソースを再組込しないよう(VIPcheckによって確実に阻止されるよう)、migration-threshold=1を入れておくと良いと思います。
IPMIは備えていないので、VIPcheck RAの導入可否の検討をしてみたいと思います。
使い方等で不明点あれば、また質問させてください。

以上です。


2015年6月15日 20:15 Takehiro Matsushima <takehiro.dreamizm@gmail.com>:

> あきやまさん
>
> 松島と申します。
>
> > DRBDのスプリットブレインが自動復旧する際のMasterを固定化することは可能でしょうか?
> > 現在運用しているマシンでDRBD通信障害でスタンドアロンになった際に
> > マシンを再起動しましたが、再起動時にSlave側の古いデータで再同期され、
> > 最新データが消えてしまう事象が発生してしまったので、再発防止策として設定を変更したいと考えています。
>
> 両方のノードに書き込みが発生してしまい、たまたま元々Slaveだった方のデータで上書きされたということでしょうか?
> IPMIを備えるサーバであれば、STONITHを使ってスプリットブレインを防ぐのが確実ですが、これが使えない場合には、
> VIPcheck RAを組み合わせることである程度回避できると思います。
>
> 加えて、一旦故障したリソースを再組込しないよう(VIPcheckによって確実に阻止されるよう)、migration-threshold=1を入れておくと良いと思います。
>
> VIPcheckの使い方ですが、
> http://osdn.jp/projects/linux-ha/releases/45456
> からダウンロードして、RAを配置された上で、(手前味噌ですが)
> http://qiita.com/takehironet/items/08716d3a9d1165f47b5c
> で簡単に解説しております。
> サービスLAN上に特定のIPアドレスが無いことがわかるとVIPcheckのStartアクションは成功します。
> 誰もすでにVIPを持っていない状態であることを確認した上で、DRBDのPromoteを実行する(colocationで縛ります)という方法になります。
>
> VIPcheck -> DRBD -> DRBDを利用するリソース -> IPaddr2
> という流れで縛りをかけるというのを私はよく使っています。
>
>
> 以上、いかがでしょうか?
>
> Takehiro Matsushima
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>