仕組みを理解すれば怖くない 「スプリットブレイン」からの復旧方法：DRBDの仕組みを学ぶ（13）（2/3 ページ）

[澤田健，株式会社サードウェア]

スプリットブレインが発生したらまず実施すること

　スプリットブレインはシステム管理者にとって悩ましい問題です。しかし、発生したらすぐにサービス停止→障害発生となるわけではありません。

　前述した例では、eth1とeth2の経路が切れてしまったとしても、VIP経由でどちらかのWordPressサーバへ通じるルートであるeth0は正常に稼働しています。このサーバが正しく動作しているならば、ひとまずユーザーアクセス／サービス提供状況に影響はありません。

　ただし、可用性は著しく低くなった状態です。また、どちらもプライマリー機となっていることから、実際にどちらのWordPressサーバが本番として使われているかが分からなくなり、本来残すべきデータを削除してしまうといったリスクも想定されます。

　スプリットブレインが発生したと想定される場合には、まず一号機、二号機それぞれにSSHログインして、どちらのサーバに実アクセスがされているかを確認します。今回の構成例としたWordPressサーバならば、どちらかのアクセスログ「/var/log/httpd/access_log」を確認すると分かるでしょう。

（参考）スプリットブレインをテストとして再現する方法

　参考までに、テストとしてスプリットブレインを再現したい場合には、「/etc/drbd.d global_common.conf」に以下の内容を追加します。

# vi /etc/drbd.d/global_common.conf 
common {
        handlers {
　
＜省略＞
＜ここから＞
                 fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
                 after-resync-target "/usr/lib/drbd/crm-unfence-peer.sh";
＜ここまでの2行を追加する＞
        }
　
＜省略＞
　
}

「/etc/drbd.d global_common.conf」を修正

　「global_common.conf」の中のcommon→handlersの中に、＜ここから＞＜ここまで＞の間の2行を追加して、設定変更後にPacemakerを再起動します。

　もう1つのネットワークの障害部分は、LANケーブルを抜く、もしくはOS側でインタフェースをダウンさせます。

高可用性サーバとして正しい状態に戻す

　では、スプリットブレインが発生し、一号機に実アクセスされているシーンを例に、正しい状態に戻す手順を紹介していきます。

　まず、「ネットワークの復旧」を行います。今回の例では、eth1とeth2の経路を復旧させることになります。よくある原因には、LANケーブルが断線した、サーバのインタフェースカードが壊れたなどがあると思います。

　部品交換などを行い、ネットワークを復旧できたら、正しく復旧したかどうかを一号機、二号機それぞれから、他方にpingを打って確認します。

# ping 10.0.0.2
　
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.290 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.262 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.309 ms
#
# ping 10.0.1.2 
PING 10.0.1.2 (10.0.1.2) 56(84) bytes of data.
64 bytes from 10.0.1.2: icmp_seq=1 ttl=64 time=0.255 ms
64 bytes from 10.0.1.2: icmp_seq=2 ttl=64 time=0.300 ms
64 bytes from 10.0.1.2: icmp_seq=3 ttl=64 time=0.253 ms
#

一号機から二号機へping

# ping 10.0.0.1
　
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.231 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.253 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.291 ms
# ping 10.0.1.1
PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 bytes from 10.0.1.1: icmp_seq=1 ttl=64 time=0.251 ms
64 bytes from 10.0.1.1: icmp_seq=2 ttl=64 time=0.258 ms
64 bytes from 10.0.1.1: icmp_seq=3 ttl=64 time=0.271 ms
#

二号機から一号機へping

　ネットワークが復旧したことを確認できました。

　ネットワークの復旧と併せて、DRBDの同期も復旧したことを確認します。

# cat /proc/drbd 
　
version: 8.4.8-1 (api:1/proto:86-101)
GIT-hash: 22b4c802192646e433d3f7399d578ec7fecc6272 build by mockbuild@, 2016-10-13 19:58:26
 0: cs:StandAlone ro:Primary/Unknown ds:UpToDate/Outdated   r-----
    ns:2058 nr:2048 dw:32790 dr:71664 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:2056
 1: cs:StandAlone ro:Primary/Unknown ds:UpToDate/Outdated   r-----
    ns:2301 nr:9942 dw:46550 dr:229735 al:3 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:2344

一号機のDRBDの状態を確認

# cat /proc/drbd
　
version: 8.4.8-1 (api:1/proto:86-101)
GIT-hash: 22b4c802192646e433d3f7399d578ec7fecc6272 build by mockbuild@, 2016-10-13 19:58:26
 0: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/Outdated   r-----
    ns:2048 nr:2058 dw:20545 dr:45063 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:8
 1: cs:StandAlone ro:Secondary/Unknown ds:UpToDate/Outdated   r-----
    ns:9942 nr:2301 dw:34014 dr:135801 al:4 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:284

二号機のDRBDの状態を確認

　このように、一号機がプライマリ−（ro:Primary）、二号機がセカンダリー（ro:Secondary）となっており、csのステータスがどちらも「cs:StandAlone」となっていれば確認は完了です。

　もし、どちらかのcsのステータスが接続待ち状態であることを示す「cs:WFConnection」となっていたら、cs:WFConnectionとなっているサーバで以下の切断コマンドを実行して、「StandAlone」に戻します。

# drbdadm disconnect r0

リソース名が「r0」の場合のコマンド実行例（r0は実環境のリソース名に置き換えてください）

　コマンド実行後、上記の「cat /proc/drbd」コマンドを再実行して、ステータスが「cs:StandAlone」に変わったことを確認できれば準備は完了です。