ここからは、DRBD Proxyを使った場合の障害発生時の動きを見ていきましょう。
障害発生直前のプライマリ機はバックアップサーバーが動作しています。セカンダリ機も同じくバックアップサーバーですが、機能は待機している状態です。データのみプライマリ機からセカンダリ機へリアルタイムに同期されています。
図2はプライマリ機に障害が発生した場合を示しています。
サーバー管理者は手動でプライマリ機をセカンダリ機に切り替え、他方のセカンダリ機をプライマリ機に変更します。以後、セカンダリからプライマリ機に切り替わった大阪のサーバーでバックアップデータが取得されるようになります。
自動で切り替えることもできますが、WAN経由もしくはVPN経由でデータを同期している場合、伝送遅延などの影響で途中で通信が途切れた場合に、一部のデータが消失し、復旧が難しくなってしまう可能性があります。
手動で実施した場合も、通信が途切れれば同様ではありますが、少なくとも明示的に操作していくことで、不用意なデータロスが発生しにくくなります。
ここまでは、離れた拠点へサーバーを配置する例を説明しました。しかし、中堅中小規模の企業などではもう一つの拠点を用意できない、つまり遠隔地へもう1台サーバーを置く場所を確保できないこともあるでしょう。
そのような場合には、セカンダリ機にクラウド環境を使うこともできます。
通常はローカルにある物理サーバー環境を使用し、災害発生時にクラウド環境のサーバーに切り替えてサービスを継続する方法です。基本的な構成は図3のようになります。
図1の構成との違いは、データを同期しておくセカンダリ機が大阪拠点のローカルサーバーなのか(図1)、クラウド環境のサーバーなのか(図3)となります。
障害発生時の動きは以下、図4の通りです。
基本は図2の動きと同じです。手動でプライマリ機をセカンダリ機に切り替え、他方のセカンダリ機をプライマリ機に変更します。そしてプライマリに切り替えたクラウドのサーバーでバックアップデータを取得するようにします。
Copyright © ITmedia, Inc. All Rights Reserved.