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

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

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

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

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

図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」コマンドで作成してください。

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

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

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

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

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