ディザスタリカバリ環境の構築、複数サイト方式とクラウド利用方式を比較する：備えがあり過ぎても困る

適切なディザスタリカバリ（DR）の選択には、コスト、目標復旧時間（RTO）、専門知識の有無が重要だ。慎重に分析した結果、クラウドが最適と考える企業もあるだろう。

[Jim O'Reilly，TechTarget]

DR対策では「最悪を考える」とどうしても過剰投資になりやすい

　ディザスタリカバリ（DR）は、スムーズで高速な対応を必要とする。それは火災や洪水、ランサムウェアなどが原因でシステムが停止した場合、1時間当たりの損失があまりに大きいからだ。それ故に企業はいつまでも一昔前のDR手法に頼っているわけにはいかない。

　新しいDRの導入を検討するとき、対象をプロプライエタリなレガシーシステムと、オープン技術ベースの最近の製品とに分けて考える必要がある。オープン技術ベースの環境であれば、クラウドをリカバリーサイトとして活用し、強力なDR対策を実現できる。

併せて読みたいお薦め記事

事業継続性のカギを握る災害対策最新事情

• 災害対策の基本、データセンターを正しく停止させるためのチェックリスト
• サービスとしての災害対策「DRaaS」にフラッシュクラウドストレージを
• Windows Server 2016のコンテナ機能が災害復旧に有効な理由
• バックアップツールの主要機能、重複排除、レプリケーション、DRを押さえる
• 徹底解説：Hyper-Vの災害復旧（DR）機能

　一般的なDR手法の1つに、ワークロードを実行するためのサイトを複数構築するという方法がある。1つのサイトがダウンしても、別のサイトでワークロードを再開できるようにするという考え方だ。サイトを遠隔地に分散させれば、この方法はうまくいく。

　このDR手法の問題点はコストだ。追加のプラットフォームが必要となるからだ。基幹系のワークロードだけを保護するのか、全てのジョブストリームをミラーリングするのかによっても異なるが、コストは50〜100％ほど増加する可能性がある。管理スタッフの増員の他、設備の追加、電気や水道などのインフラ費用の増大も覚悟しなければならない。ハードウェアとソフトウェアがセミカスタマイズしたプロプライエタリな要素で構成されるレガシーシステムにおいては、こうしたマルチサイトを使ったDRが一般的だ。

　レガシーシステムのDRには、データのバックアップという方法もある。通常はテープへのバックアップとなる。データをテープにコピーするのは比較的楽な作業だ。ただし代替ハードウェアをすぐに利用できるか、物理的に調達しなければならないかによって、復旧時間には数時間から数日の幅が生じる。なおテープではなくクラウドへのバックアップは、一部のCOTS環境にも適した方法だ。

クラウドを活用

　DRに関しては、オープン技術ベースの環境の方がはるかに楽だ。クラウドを活用すればいいからだ。大半のアプリケーションを仮想インスタンスで実行できるので、社内クラウドやクラスタはパブリッククラウドの新しいインスタンスセットでワークロードを再構成できる。

　DRにクラウドを活用する方法は幾つかある。1つは、クラウドバースティングを使用し、過剰なワークロードを自動的にクラウドに移行させるという方法だ。本稿では、クラウドバースティングにおけるデータ配置の問題については詳しく取り上げない。短い目標復旧時間（RTO）を実現するには、適正なデータ配置が不可欠であるという点だけ述べておく。

　他に、エンドポイントのバックアップという手法もある。最近のデータやインスタンスイメージのコピーをパブリッククラウドに保存し、災害時に起動できるよう準備を整えておくという方法だ。パブリッククラウドでは、復旧用のインスタンスをアクティブにしておく必要はない。インスタンスは数分で構築でき、料金は実行回数に応じて発生する。「Docker」コンテナはハイパーバイザーインスタンスよりもはるかに高速に起動できるので、RTOの点で好ましい。

　クラウド環境に適したバックアップツールは豊富にある。問題はリカバリーできるかどうかだ。バックアップがあったとしても、リカバリーはそう簡単ではない。適切なファイルを適切な場所に配置し、適切な連係を構築するのは、注意を要する作業だ。10年に1回くらいの頻度でこの問題に直面するIT部門にとっては、なおさらだろう。

クラウドベースのDRサービス