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

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

「他方のサーバ」のデータを破棄し、データ同期を復旧させる

　続いて、スプリットブレインからの復旧において最も重要となる、「同期される側のサーバのデータを破棄する」作業を行います。

　作業の前に、どちらのサーバのデータが最新か、残すべき本来のデータはどちらにあるか、などの見極めを再度行ってください。重ねて述べますが、破棄するデータを間違えると、正しく復旧できなくなります。その見極めと作業には十分な注意が必要です。

　では削除の作業を行っていきます。今回の例では、一号機が実サーバとして稼働しているので、二号機のデータを破棄します。二号機にSSHでログインします。

　二号機の状態を再確認します。

# 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

二号機の状態を再確認する

　csのステータスが「cs:StandAlone」に、roのステータスが「ro:Secondary」となっていますでしょうか。

　確認ができたら、二号機のデータを破棄します。今回の例はリソースが2つあるので、それぞれのリソースに対してコマンドを実行します。

# drbdadm -- --discard-my-data connect r0 
# drbdadm -- --discard-my-data connect r1

二号機のデータを破棄する

　実行後の状態は以下の通りです。

# 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:WFConnection ro:Secondary/Unknown ds:UpToDate/Outdated C r-----
    ns:0 nr:0 dw:20545 dr:45063 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:8
 1: cs:WFConnection ro:Secondary/Unknown ds:UpToDate/Outdated C r-----
    ns:0 nr:0 dw:34014 dr:135801 al:4 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:284

二号機のデータを破棄したあとの状態

　csのステータスが「cs: WFConnection」、roのステータスが「ro:Secondary」となったことを確認します。データを破棄したことによって、二号機はスタンドアロン状態から「（一号機との）接続待ち」状態に変更されました。

　続いて、一号機（同期する側のサーバ）にSSHでログインします。一号機の状態は以下の通りです。

# 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:74064 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:58839 dr:229735 al:5 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5084

一号機の状態

　csのステータスは「cs:StandAlone」、roのステータスは「ro:Primary」となっています。

　この状態であることを確認したら、一号機でDRBD接続コマンドを実行します。

# drbdadm connect r0 
# drbdadm connect r1

一号機で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:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:2056 nr:0 dw:32790 dr:76120 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 1: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
    ns:996 nr:0 dw:58900 dr:230731 al:5 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:4088
        [===================>] sync'ed:100.0% (4088/5084)K
        finish: 0:00:03 speed: 996 (996) K/sec

DRBD接続コマンド実行後の一号機の状態

　roのステータスは「ro:Primary/Secondary」に、csのステータスは「Connected」「SyncSource」となり、一号機は同期元として、二号機と正しく接続されました。

　接続完了と同時に、DRBDでの同期が再実行されます。

　同期が完了するまで多少の時間を要しますが、今回の構成例においては、同期中もWordPressのサービスは継続されます。なお、障害発生から復旧までの時間がかかるほど、DRBDでの同期時間も要するので注意してください。

　同期が完了すると、正常な状態に戻ります（図4）。

図4　スプリットブレイン状態から復旧した高可用性WordPressサーバ

スプリットブレインを予防する方法

　仕組みと対処方法を正しく理解することで、「スプリットブレインは決して危機的な状況ではない」ことはお分かりいただけたと思います。対処作業において、「破棄するデータを正しく選択すること」に気を付けるくらいです。

　スプリットブレイン対策の基本は、「ネットワーク障害が発生しないようにすること」です。その方法は多岐にわたりますが、例えばDRBDを用いるシステムにおいては、「eth1、eth2のネットワークインタフェースを、さらにBondingなどを使って冗長化する」「（自社のオンプレミス環境よりも）物理的なネットワーク障害の発生率が少ないとされ、高いSLAを保証するパブリッククラウド上にシステムを構築する」などの方法を推奨します。

　次回は、DRBDの最新版となる「DRBD9」の刷新ポイントと使い方を解説します。お楽しみに。

筆者紹介

澤田健（さわだ けん）

株式会社サードウェア

さまざまなIT関連業務経験ののちに2013年よりインフラエンジニアとしての業務に携わる。また、DRBDを始めとするオープンソースソフトウェアのサポート業務にも携わっている。ツイッターでDRBDの情報発信も行っている。TwitterID：@ksawada1979。