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

DRBDを軸に、データを遠隔地にも即時複製して万が一の事態に備える「冗長化／高可用性システム」の構築テクニックを紹介する本連載。今回は、DRBDをはじめとするクラスタ環境で発生するトラブルの1つ、「スプリットブレイン」からの復旧方法を解説します。

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

連載バックナンバー

目次

• 1：「スプリットブレイン」とは何か
• 2：なぜ、スプリットブレインが発生するのか
  • DRBDのワンポイント
  • スプリットブレインが発生していないかを確認する
• 3：スプリットブレインが発生したら実施すること
  • スプリットブレインをテストとして再現する方法
• 4：正しい状態に戻す手順
  • データ同期を復旧させる、正しい方法
• 6：スプリットブレインを予防する対策

　本連載は、サービスを止めてはならない環境で活躍する冗長化支援ツール「DRBD（Distributed Replicated Block Device）」を使い、災害対策システムや高可用性WordPressシステムなどを構築するノウハウをお届けしています。今回は、DRBD環境をはじめとするクラスタ環境で悩ましいトラブルの1つである「スプリットブレイン」の対策を解説します。

「スプリットブレイン」とは何か

　DRBDを始め、クラスタ環境で特に悩ましいトラブル状況の1つが「スプリットブレイン」です。

　スプリットブレインとは何か。まず、その「状態」から説明します。以下に「正常」なシステム例を示します（図1）。

図1　DRBD＋Corosyncで構成した正常動作時の高可用性WordPressサーバ環境

　図1は、一号機をプライマリー機としてWordPressサーバを稼働させ、同じ構成の二号機が待機している、DRBD＋Pacemaker＋Corosyncを用いた冗長化構成です。ユーザーはVIP（仮想IPアドレス）を通じて一号機へアクセスし、更新データが一号機から二号機へ同期されることで冗長化する仕組みです。

　これによって、もし一号機に何らかの障害が発生したとしても、二号機へプライマリー機を切り替えることでサービスを継続できます。ユーザーは不変的なVIP（図では、192.168.0.50）へアクセスするので、一号機と二号機が入れ替わったとしてもアクセス先のIPアドレスは変わりません。「どちらかがプライマリー機であること」が保たれることによって、仮にどちらかに障害が発生したとしても、ユーザーに影響を与えず、サービスも止めない運用を実現します。

　続いて、スプリットブレインが発生した環境は何が違うのでしょう（図2）。

図2　スプリットブレイン発生時の高可用性WordPressサーバ

　本来、どちらかがプライマリー機ならば、他方はセカンダリー機でなければなりませんが、「どちらもプライマリー機」になっています。

　このように、クラスタが分断された時にプライマリー機が複数存在してしまう状態のことをスプリットブレインと呼びます。この状態でデータ更新が掛かると、データの不整合が発生してしまう恐れがあります。

なぜ、スプリットブレインが発生するのか

　スプリットブレインは、主に一号機と二号機を結ぶネットワーク障害によって発生します。

　上記の図1は、現プライマリー機に障害が発生したら、ネットワークを経由して他方のサーバがその障害を検知することで、プライマリー側とセカンダリー（待機）側が入れ替わります。

　一号機と二号機は、eth1とeth2、2経路のネットワークでお互いのサーバを監視し合っています。2つのサーバは大抵の場合、それぞれ離れた場所に置かれ、ネットワーク越しに互いの状況を一定の間隔で監視しています。

　ネットワーク障害／不調などによって「監視対象のサーバ（一号機）が見えなくなった」ら、二号機は、現プライマリー機である一号機が「障害が発生した／ダウンした」と見なし、自身がプライマリー機に昇格します。同時に、一号機はセカンダリー機に変更されます。本来ならばこの時点で一号機と二号機の役割が入れ替わるのですが、ネットワークが不通だとその情報がお互いに伝わりません。一号機は、正常に稼働しているならば、そのままプライマリー機として存在し続けます。

　つまり、一号機は「切り替える情報を受けとっていない」のでプライマリー機のままで変わらず、二号機は一号機が見えなくなったので「一号機がダウンした」と判断し、プライマリー機に切り替わります。それぞれが仕様に沿った正しい動作をした結果、複数のプライマリー機が存在することになるのです（図3）。

図3　ネットワーク障害が発生した時の高可用性WordPressサーバ

ワンポイント

　これまでにも紹介してきた図1のようなDRBDのシステム構成は、eth1とeth2の2経路を使って監視を二重化することによって、スプリットブレインのリスクを防ぐ仕組みを設けています。

　実は、eth1のインタフェース1つだけでもDRBD同期と監視を行うシステムは構築可能です。しかしこのようなシステムでは、一号機と二号機を結ぶ拠点間のネットワーク障害があっただけでスプリットブレインが発生してしまいます。

　図1のシステムは、監視経路を二重化しつつ、データ同期の経路はeth2で行います。DRBDによるデータ同期の経路こそ二重化されていませんが、どちらかで監視が正しく動作していれば、スプリットブレインは発生しないというわけです。

　もっとも、eth2に障害が発生したら、DRBDによるデータ同期は停止します。しかし、インタフェースを復旧させればシステムは元に戻ります。インタフェースが切れていた時間に応じて、同期に時間がかかってしまうことに注意するくらいとなります。

スプリットブレインが発生していないかを確認する

　「スプリットブレインが発生していないか」は、一号機、二号機それぞれで「cat /proc/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:WFConnection ro:Primary/Unknown ds:UpToDate/Outdated C r-----
    ns:2048 nr:2058 dw:20542 dr:45063 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/Outdated C r-----
    ns:9942 nr:2301 dw:31388 dr:135801 al:4 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:56

一号機の状態を確認

# 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:Primary/Unknown ds:UpToDate/Outdated C r-----
    ns:2058 nr:2048 dw:30740 dr:65878 al:2 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:2052
 1: cs:WFConnection ro:Primary/Unknown ds:UpToDate/Outdated C r-----
    ns:2301 nr:9942 dw:41746 dr:207934 al:3 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:2124

二号機の状態を確認

　出力結果の「ro:Primary」と「cs:WFConnection」が確認ポイントです。「ro:Primary」は、そのリソースがプライマリー機であることを示す値です。それぞれのリソースが「ro:Primary」となっていたら、両方ともプライマリー機である＝スプリットブレインが発生してしまっています。また、接続待ち状態であることを示す「cs:WFConnection」となっていたら、DRBDの接続も切れてしまっています。