「災害対策システム」で、DRBDを活用する方法:DRBDの仕組みを学ぶ(3)(2/3 ページ)
障害監視ツールなどと一緒に使うことで、サービスの継続提供を助けるDRBD。前回の高可用性システムに続き、今回は「災害対策システム」でどう使うか、実践的な運用方法を解説します。
障害発生時の動作
ここからは、DRBD Proxyを使った場合の障害発生時の動きを見ていきましょう。
障害発生直前のプライマリ機はバックアップサーバーが動作しています。セカンダリ機も同じくバックアップサーバーですが、機能は待機している状態です。データのみプライマリ機からセカンダリ機へリアルタイムに同期されています。
図2はプライマリ機に障害が発生した場合を示しています。
サーバー管理者は手動でプライマリ機をセカンダリ機に切り替え、他方のセカンダリ機をプライマリ機に変更します。以後、セカンダリからプライマリ機に切り替わった大阪のサーバーでバックアップデータが取得されるようになります。
自動で切り替えることもできますが、WAN経由もしくはVPN経由でデータを同期している場合、伝送遅延などの影響で途中で通信が途切れた場合に、一部のデータが消失し、復旧が難しくなってしまう可能性があります。
手動で実施した場合も、通信が途切れれば同様ではありますが、少なくとも明示的に操作していくことで、不用意なデータロスが発生しにくくなります。
クラウドを活用した災害対策システムを構築
ここまでは、離れた拠点へサーバーを配置する例を説明しました。しかし、中堅中小規模の企業などではもう一つの拠点を用意できない、つまり遠隔地へもう1台サーバーを置く場所を確保できないこともあるでしょう。
そのような場合には、セカンダリ機にクラウド環境を使うこともできます。
通常はローカルにある物理サーバー環境を使用し、災害発生時にクラウド環境のサーバーに切り替えてサービスを継続する方法です。基本的な構成は図3のようになります。
図1の構成との違いは、データを同期しておくセカンダリ機が大阪拠点のローカルサーバーなのか(図1)、クラウド環境のサーバーなのか(図3)となります。
障害発生時の動きは以下、図4の通りです。
基本は図2の動きと同じです。手動でプライマリ機をセカンダリ機に切り替え、他方のセカンダリ機をプライマリ機に変更します。そしてプライマリに切り替えたクラウドのサーバーでバックアップデータを取得するようにします。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- DRBD(Distributed Replicated Block Device)とは何か
障害監視ツールなどと一緒に使うことで、サービスの継続提供を助けるDRBD。Linuxカーネルに統合されている機能ですが、上手に使いこなしているでしょうか? 本連載では、DRBDの動作や使いどころを順を追って紹介していきます。 - ミラーリングツール「DRBD」によるデータ保護
「Heartbeat」の適切な導入によってHAクラスタを構成し、Linux上で動作しているサービスの可用性を上げることができます。続いて、肝心のデータそのものを保護できるツール「DRBD」について紹介しましょう。