それぞれディスクが接続されている2つのWebサーバーがあります。このディスクは、「dual-primary」モードでdrbd
(2:8.3.13-1.1ubuntu1)を使用して同期され、その上でocfs2
(1.6.4-1ubuntu1)を実行します。 )クラスタファイルシステムとして。ノードはプライベートネットワーク192.168.3.0/24
で通信します。ほとんどの場合、これは安定しており、うまく機能します。
昨夜、ネットワークが停止したようです。これにより、node01がStandalone
とPrimary
に残され、node02がWFConnection
とprimary
に残されるスプリットブレインシナリオが発生しました。リカバリは今朝、2つのファイルシステムを区別し、node01が信頼できるものであると判断し、node02をセカンダリに配置してから各ノードでdrbdadm connect
コマンドを発行する手動プロセスでした。この後、ファイルシステムを再マウントすると、バックアップして実行されます。
私の質問は次のとおりです。このタイプの停止には常に手動による解決が必要ですか?または、このプロセスを自動化する方法はありますか?私の理解では、どのノードをプライマリとセカンダリにするかについて頭脳が分裂した場合、drbdはインテリジェントにしようとする必要があります。この場合、単純なネットワークの停止により、両方がプライマリに残っているようです。これは、私の設定では「切断」とだけ表示されています。ログを見ると、私が興味深いと思うのは、node02
をSyncSourceにする必要があることに両者が同意しているように見えたにもかかわらず、rsyncログを見ると、実際にはnode01
が最新のものであるという事実です。変更します。また、node01
の「私はSyncTargetになりますが、私はプライマリです!」という行も興味深いものです。私には、drbdがこれを解決しようとしたように見えますが、何らかの理由で失敗しました。
これを行うためのより良い方法はありますか?
r0
の構成は次のとおりです。
resource r0 {
meta-disk internal;
device /dev/drbd0;
disk /dev/xvda2;
syncer { rate 1000M; }
net {
#We're running ocfs2, so two primaries desirable.
allow-two-primaries;
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
handlers{
before-resync-target "/sbin/drbdsetup $DRBD_MINOR secondary";
split-brain "/usr/lib/drbd/notify-split-brain.sh root";
}
startup { become-primary-on both; }
on node02 { address 192.168.3.8:7789; }
on node01 { address 192.168.3.1:7789; }
}
kern.log
ファイルもPastebinに置きました。
Node01: http://Pastebin.com/gi1HPtut
Node02: http://Pastebin.com/4XSCDQdC
私見あなたはすでにDRBDに最適なSBポリシーを選択しています。したがって、あなたの場合、ファイルシステムの同じ部分(つまり、DRBDブロック)の両側で変更を加える必要がありました。
したがって、その場合は-はい-手動で解決する必要があります。
私に生じる質問はなぜこれらの同時アクセスが発生したのか?
その方向を調査する必要があります。ネットワークがダウンしている場合、片側にアクセスがないはずなので、「ゼロ変更を破棄」が役立つはずですが、そうではありませんでした。
それとは別に、2つ以上の独立したネットワーク接続を使用して、スプリットブレインを防ぐ必要があります。私はいつもクラスターでそれらのうちの3つを使用しています。