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

» 2016年12月15日 05時00分 公開
[澤田健株式会社サードウェア]
前のページへ 1|2|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)。

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

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

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

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

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

筆者紹介

澤田健(さわだ けん)

株式会社サードウェア

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


前のページへ 1|2|3       

Copyright © ITmedia, Inc. All Rights Reserved.

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。