読者の中にもインターネット・バンキング・サービスを利用している方も多いと思う。ATMや窓口へ直接行かずに、振り込みや金融商品の購入・解約が可能で非常に便利なサービスだが、この取引データは基本的に金融機関に保存されている。もし、災害などでこれらのデータにアクセスできなくなったら、どれだけの社会的な影響が発生するだろうか?今回は、こういった社会インフラである重要な電子データを、いかに保護するかという「災害対策」の考え方について紹介し、ストレージの視点から解決するリモートレプリケーション機能について解説する。
これまでの災害対策と近年の課題
災害対策は、コンピュータが普及する以前から行なわれてきた。当時は、商取引はすべて「帳簿」といった紙媒体に記録されていたが、災害や盗難から帳簿内のデータを守るために、紙媒体やマイクロフィルムに複写し、別の事務所や倉庫に保管していた。むろん、現代でもこういった手法は一部使われているが、「取引の電子データ化」は、コンピュータシステムとしての災害対策を必要とした。
最初に採用された電子データの災害対策手法は、バックアップメディアの移送・保管だ。日常バックアップしているテープメディアを複製し、同時に被災することのない遠隔地の事務所や倉庫へトラックなどで運送する、紙媒体と同様なやり方である。現在でもこの方法を採用している企業や情報システムは多いが、以下のような課題が存在する。
- バックアップ、メディアの運送というサイクル・所要時間のため、多くの場合で直近のリカバリポイントは24時間となる(リカバリしても、24時間かそれ以上分のデータを失う)
- データのリカバリに時間がかかる
- 運送中のメディアの盗難など情報漏えいのリスクが高い
特に、金融機関や通信サービス業などで稼働する、社会インフラとして機能している情報システムやサービスは、被災後の復旧の際にいかに「データを失わず」、「迅速にリカバリ」できるかが重要な災害対策の課題である。したがって、近年多くの企業がこのようなテープメディアの搬送による方法ではなく、後述する通信回線を利用したストレージやアプリケーションによるデータのレプリケーションを検討している。
なお、多くの企業は個々の情報システムの災害対策のみならず、企業活動全体に対する災害対策である「事業継続計画(BCP:Business Continuity Plan)」の策定に取り組んでいる。たとえば、データや情報システムが被災後復旧しても、それらを運用する人員や顧客対応する仕組みなどが欠けていれば企業活動として機能しない。最近では、IT系のコンサルティング会社やベンダーが、こういった企業全体のBCP策定を支援するコンサルティングサービスをメニューとして用意している。
リモートレプリケーションの手法
インターネットの普及により、企業は高品質で広帯域の通信回線をより低価格で利用できるようになった。この通信回線を災害対策に利用するというのは技術的にも自然な流れであり、これから紹介するリモートレプリケーション機能の前提となっている。
まず考えられるリモートレプリケーションの手法は、アプリケーション上で動作させるやり方で、多くのデータベースアプリケーションに実装されている。ローカルサイトで通常稼働しているデータベースに更新が発生したら、同時にリモートサイトの災害対策用データベースも更新する。これにより、リモートサイトにもローカルサイトと同じ内容のデータベースが用意できる。
ただし、リモートレプリケーションの対象はあくまでも対応しているデータベース(アプリケーション)となる。動作するサーバにも負荷がかかるため、限定的な適用となるケースが多い。一方、より汎用的な仕組みとして、ストレージ自身がリモートへデータをレプリケーションする方法が存在する。ストレージを利用しているアプリケーションすべてに対して、この災害対策の仕組みを適用できるため、企業ユーザーの多くが採用している。
前回紹介したEMCのハイエンドストレージあるSymmetrixでは、筐体内のレプリケーション機能であるTimeFinder以前に、筐体間リモートレプリケーション機能のSRDFを1990年代後半にリリースしている。ストレージにとって、それだけニーズが高い機能といえる。図1に、アプリケーションとストレージによるリモートレプリケーションの比較を示す。
リモートにデータをレプリケーションする際に、ローカルサイトとつねに同じ状態を保持するのは技術的にいくつかの困難を伴う。図2は、同期/非同期モードというリモートレプリケーション動作を示している。
同期モードでは、ローカルサイトへのリクエスト(データベースの更新トランザクションやストレージへのI/O)は、リモートサイトへの転送と反映が完了したあとにローカルのリクエスト元(サーバ)へ完了通知が返る。ローカルとリモートのデータ同一性は保証されるが、サイト間の距離が長いと伝送遅延によるアプリケーションの応答速度低下を招く。このため、すべての災害対策要件に、同期モードを適用することは現実的ではない。
たとえば、サイト間が100km離れているとすると、同期モードでは理論上の伝送遅延は0.67ms(ミリ秒)となる。これは、データの伝送速度は光の速さ(30万km/s)を超えることはできないためだ。非常に小さい遅延に思えるが、通信回線を流れる個々のパケット単位にこの遅延が付加されるため、トランザクションやI/Oといった単位ではより大きな遅延となる場合がある。
一方の非同期モードは、図2の通り、リクエストの完了通知は即時となる。このため、アプリケーションの動作に影響はない。ただし、サイト間のデータに一定の時差が生まれるため、災害時にはデータが消失する可能性がある。非同期モードを採用する際には、復旧後のシステムとしての動作およびビジネス上の損失の観点から、被災した際に失ったデータの対処について事前に対応を検討する必要がある。
(次ページ、「リモートレプリケーションの静止点・整合性」に続く)
この連載の記事
-
最終回
サーバー・ストレージ
クラウド時代に対応するストレージの最新技術 -
第15回
サーバー・ストレージ
ストレージを守るセキュリティ技術 -
第14回
サーバー・ストレージ
ストレージ管理を効率化するテクニック -
第13回
サーバー・ストレージ
サーバ仮想化のためのストレージの機能を探る -
第12回
サーバー・ストレージ
シンプロビジョニングによるストレージ仮想化とは? -
第11回
サーバー・ストレージ
コスト削減を実現するストレージ階層化とは? -
第9回
サーバー・ストレージ
バックアップを高速化するレプリケーションの仕組み -
第8回
サーバー・ストレージ
ストレージを使ったバックアップの技術 -
第7回
サーバー・ストレージ
FC/iSCSIとNASの違いを知っていますか? -
第6回
サーバー・ストレージ
ストレージをネットワーク化するFCとiSCSI - この連載の一覧へ