コラム

SEのためのストレージ講座

第19回 コンプライアンスへの対応 その3

更新

IT基盤のストレージの役割や課題から仮想化・統合化まで、CTCのエンジニアが解説します

著:クロスファンクショングループ プロダクトマーケティング室
インフラソリューション推進部 菅 博

DRにはいくつかの実装方式があり、それぞれに長所と短所があります。ここでは一般的な実装方式の特長と回線速度の決定方法、および実装方式の選択方法について説明します。

同期型のDR

図1

ローカル・システムでのデータ更新が同時にリモート・システムにも反映されるために、障害時のRPOは完全に保障されます。つまり、データの消失は1バイトもありません。ここだけを見ると同期型が最善のように思えてしまいますが、実際には次のような制限があるために同期型を選択するかどうかは慎重に考慮すべきです。

  • ローカルとリモートの拠点は100km以内でなければならない
  • 更新量に応じて品質の高い高速回線が必要になる
  • サービスやアプリケーション性能が低下する可能性が大きい

距離の制限は非常に重要で、この制限ゆえにそもそも同期型は選択できないことがあります。また、下の図からもわかるように、全ての更新情報はリモート側に反映されたことが確認できた時点で、ローカルのアプリケーションに応答が返るために、データの更新量によってはアプリケーションの性能が著しく低下する恐れがあります。

非同期型のDR

図2

ローカル・システムにおける更新はすぐに反映され、アプリケーションへの応答はその時点で返されるので、アプリケーション性能への影響がありません。更新データは適時リモート・システムにバックグラウンドで非同期に転送されていくために、ローカルとリモートのデータには基本的に常に差異が生じています。この差分がどの程度生じてしまうかはサーバ性能や書き込み量、ネットワークの品質や速度に依存するため、非同期型の設計は比較的難しいものとなります。ある程度のデータ消失は免れられないとしても、非同期型は同期型と比べて次の利点を持っています。

  • アプリケーション性能を劣化させない
  • ローカルとリモートの拠点間距離は、基本的に制限がない

バックアップ型のDR

同期、非同期がローカル・システムの更新があったタイミングでローカル・システムにデータの転送を行うのに対して、バックアップ型はローカルでの更新が発生してもデータの転送を行いません。あるタイミングでデータのバックアップ・セットを作成して、そのイメージをリモート・システムに送ることでその時点でのデータセットをリモートに保持するようにしています。この方法だと、RPOは非同期型よりもさらに緩くなり、障害時に消失するデータ量はさらに多くなる可能性がありますが、実装方式からすると非常にシンプルでわかりやすくコストも比較的抑えられるので、テープ搬送をするぐらいならこの方式を採用するだけでも十分なメリットがあります。

NASのDR方式としては、このバックアップ型を採用しているものがほとんどです。指定された時間にファイルシステムのスナップショットを作成し、そのスナップショットのイメージをリモートのNASに転送するというものです。もちろん、2回目以降の転送については差分しか転送しない仕組みになっているので、転送量は前回の転送からの更新部分に限定されます。

回線速度の考え方

図3

同期型や非同期型のDRでは、「どれぐらいの回線を準備すれば十分なのか?」というのはいつも疑問視されますが、設計の指針は意外に単純です。アプリケーションの単位時間あたりのI/O量の一日の推移がわかりさえすれば、図3を利用して回線速度の考え方は説明することができます。仮に同期型での複製を考えている場合に、アプリケーションのピーク時のI/O量は20MB/secなので、アプリケーションへの影響を最大限に配慮するならば、回線速度は20MB/sec以上でなければなりません。

非同期型の場合には、RPOをどこまで許容するかで決めなければなりません。図3で回線速度として10MB/secを選択した場合、10時から11時30分までのI/Oが回線速度を上回っていることから、11時30分の時点では、黄色の線から上に出ている一山分のデータが未送信データとしてローカルに残っていることになります。非同期型の実装方法によって未送信データをそれほど多く蓄えることができないものもあるので、その観点から回線速度の下限はおのずと決まってきます。

方式の決定

ここまで説明していきたようにDRの実装方式にはいくつかあり、それぞれの方式において製品も相当程度が販売されています。どの方式で行い、どの製品を購入するべきなのかという場合、少なくとも次の4つの視点は忘れないようにしたいものです。

  • RPO/RTOをどこまで保障するのか
  • 同期型であれば拠点間の距離は100km以内なのか
  • 既存システムに追加できるのか
  • 製品のライセンス料はどこにかかっているのか(サーバ、筺体、容量)

DRシステムを検討する場合に、いきなり“機能”や“性能”に注目して考えてしまうのは非常に危険です。上記4つの条件を最初に考慮して、残った製品の中から予算に見合った製品を選ぶようにすべきで、予算に合わない場合にはRPO/RTOをどこまで妥協できるかという点で再考するというサイクルを何度か繰り返すことになるはずです。

コラム一覧のページに戻り、続きをお読み下さい。

  • このページについてツイッターでツイート(新しいウィンドウで開く)
  • このページをフェイスブックでシェア(新しいウィンドウで開く)

このコラムに関するお問い合わせはこちら

※記載内容は掲載当時のものであり、変更されている場合がございます。