今こそ真剣に考える「災害対策システム」──クラウドと「DRBD Proxy」ですぐ構築する方法：DRBDの仕組みを学ぶ（7）（3/3 ページ）

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

DRBD Proxyを使った災害対策システム環境を実際に運用してみる

　冒頭で示した構成イメージ図1のように、DRBD Proxyを使った災害対策システム環境が構築できました。

図1　災害対策システムの構成イメージ

　実際にバックアップサーバにデータを保存してみましょう。一号機の/backupディレクトリに何かデータを保存してください。

「遠隔地のサーバへも保存されたか」をテストする

　一号機へ保存したデータと共に、クラウドにある二号機にもデータが保存（レプリケート）されたかを確認します。

　二号機で「cat /proc/drbd」コマンドを実行すると、nsとdwの数値が上昇したことが確認できます。

「cat /proc/drbd」を実行すると、nsとdwの数値が変化したのが確認できる

ステータス	意味
ns（ネットワーク送信量）	ネットワーク接続を介して対向ノードに送信された正味データの量（単位はKiB、以下同）
nr（ネットワーク受信量）	ネットワーク接続を介して対向ノードが受信した正味データの量
dw（ディスク書き込み）	ローカルストレージに書き込まれた正味データ
dr（ディスク読み取り）	ローカルストレージから読み取った正味データ

障害発生時に二号機へ切り替える手順

　では、障害発生時に二号機へどのように切り替えるか、その運用方法を解説します。

図2　一号機に障害が発生した場合は、二号機へ切り替える

　切り替えは手動で実施します。

　なぜ、手動で実施するのでしょう。第5回「障害時にサブサーバへ自動で切り替える“高可用性WordPressシステム”の作り方」で解説したように、こちらも完全自動化できれば良さそうですが、これには理由があります。

　DRBD ProxyはWAN越えで同期をするために、ネットワーク状態の影響を受けて想定しない通信断が発生する可能性があります。例えば、自動切り替え中に通信断が発生すると、一号機、二号機ともにプライマリとなれず、サービスが完全に止まる事態を招いてしまいます。このリスクを回避するために明示的に作業する手動切り替えを推奨しています。もちろん、切り替えの手順をシェルスクリプトなどで自動化することは問題ありません。

　ここでは、メインの物理サーバ「一号機」が被害を受けた場合を想定します。一号機への操作はリモートでも行えないので、二号機を操作して、セカンダリだった二号機をプライマリに昇格させます。

　まず、無効にしていたクラウド上のサーバのグローバルアドレスを有効にします。

　続いて、「cat /proc/drbd」コマンドで二号機の状態を確認します。

# cat /proc/drbd

切り替え前の二号機は、csが「WFConnection」、roが「Secondary/Unknown」であることが確認できる

　WFConnectionは「対向のサーバ（一号機）の接続待ち状態」、Secondary/Unknownは「二号機はセカンダリで、一号機は不明」という意味です。つまり、DRBDの接続が切断され、一号機は動作していないことを示します。

　二号機を操作して、セカンダリ機だった二号機をプライマリに昇格させます。

# drbdadm primary r0

　二号機のバックアップデータ領域をマウントします。

# mount /dev/drbd0 /backup

　マウントしたら、二号機の/backupの中身を確認します。先ほど一号機でテスト保存したデータが確認できれば、切り替え作業は完了です。

　マウントポイントがない場合は「mkdir /backup」コマンドで作成してください。

ワンポイント1：切り替え手順を自動化する簡易シェルスクリプト

#!/bin/bash
drbdadm primary r0
mount /dev/drbd0 /backup

　こちらはコマンドを羅列しただけの簡単なものです。この他に、コマンドをまとめてスクリプト化することで自動化する方法もあります。

　なお、このスクリプトにはエラー処理が入っていません。実運用においては、エラー処理なども入れて柔軟な動作を実現するスクリプトにするのもよいでしょう。

ワンポイント2：DRBD Proxy関連ログの出力場所

　DRBD Proxy関連のログは、システムログへ出力されます。DRBD ProxyはあくまでもDRBDのオプションソフトウェアのため、ログの出力先はDRBDと同じです。

　CentOS 7では、journalctlコマンドを使って参照します。CentOS 6では「/var/log/messages」下にあります。

ほぼソフトウェアのみで「災害対策システム」を構築

　DRBDとDRBD Proxy、そしてクラウドサービスを併用することで、災害対策システムの環境をほぼソフトウェアのみで実現できることがお分かりいただけたでしょうか。今回の災害対策システムは、これまでコストの都合で災害対策を実践できなかった中堅中小企業にも進められる手段だと思います。

　今回はバックアップサーバを冗長化する例としましたが、ほぼ同じ方法でSambaやNFSなどのファイルサーバの災害対策システムを構築することも可能です。この他に、IPネットワークストレージである「iSCSI」のターゲットを動かせば、Windowsなど他OSのデータもリアルタイムに遠隔地にデータ保存する応用方法もあります。

（参考記事）DRBD＋iSCSI夢の共演：〜 Windowsドライブをミラーリングで保護

　災害復旧対策は、今後の自社のビジネスに直結する課題です。ぜひ、実際のシステムでもこのノウハウを参照しながら、DRBDを活用した災害復旧対策システムを構築してみてください。

筆者紹介

澤田健（さわだ けん）

株式会社サードウェア

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