ハイブリッドクラウドにおける災害対策(後編)

今回も前回に続き、データ管理の観点から見た、ハイブリッドクラウドのような増大する複合インフラにおける災害対策について説明します。

前回、災害対策の方法として、「バックアップデータの外部保管」と「本番データのリモートレプリケーション」の2つを紹介しました。今回は、この2つの方法を実現する具体的な手法について説明します。

これら2つの方法はそれぞれ複数のデータの転送手法を持っています。バックアップデータの外部保管は「テープへのバックアップと外部搬出保管」と「ディスクバックアップのレプリケーション」の2種類、本番データのリモートレプリケーションは「ストレージ機能によるレプリケーション」「サーバ機能によるレプリケーション」「 仮想環境ハイパーバイザーによるレプリケーション」の3種類の方法があります。

外部保管用メディア「テープ」と「ディスクバックアップ」の比較

まずは、バックアップによる外部保管の手法であるテープとディスクバックアップのレプリケーションを比較してみたいと思います。

この2つの方法を「整合性」「コスト」「復旧迅速性」「論理復旧性」から比較すると、以下の表のようになります。

	テープへのバックアップと外部搬出保管	ディスクバックアップのレプリケーション
コスト	◎比較的に安価	〇比較的に高価だが本番データのリモートレプリケーションほどではない
機密性	×暗号化を用いてもテープ媒体自体に盗難、紛失のリスクがある	◎暗号化しさらに重複排除された小さな粒が転送されるため、機密性は高い
復旧迅速性	△比較的に高速。ただし、復旧システム単位にきれいに体系化されバックアップされている場合に限る	◎ランダムアクセスが可能なディスクの性質により大量なバックアップデータから多重で複数システムに同時にリストア可能
復旧確実性	×災害時には非常に大量のデータリストアが必要で多数のテープが全て正常に読み込める必要があるが、テープはメディアエラーが発生しやすく、関連する全データを完全に復旧できないリスクが高い	◎転送されたデータはストレージもしくはバックアップソフトウェアにより定期的にデータの可読性が確認され、復旧不能が検知された場合は災害発生前に対処可能であり、災害時に全必要データがリストア可能

各項目を見ても、もはやテープによる災害対策は現実的ではないと言えます。一昔前なら災害対策と言えば、テープが一般体なソリューションでした。その一番の理由はコストです。

20年ほど前はテープ1本にディスク数本分のバックアップが可能でした。データセンターのデータ容量もそれほど多くなく、1日分の重要データのバックアップがテープ数本で済んでいた時代です。

加えて、重複排除技術がまだ製品化されていなかった当時、フルバックアップのデータをディスクに複数世代持つことはコスト的に不可能でしたし、フルバックのアップデータを細くて非常に高価だった回線で別拠点に転送するのも不可能でした。

しかし、今は状況が違います。ビジネスのIT依存度が高まったため、保護すべきデータは膨大に増えました。しかし、ディスク密度の増加ほどテープ密度は上がらず、ある大規模なデータセンターでは1日のバックアップテープを数百本搬出しているという声も聞こえてきます。

一方、回線コストが以前に比べて下がってきたことに加え、重複排除技術の登場により、繰り返し同じデータのコピーを保存するバックアップにとってはディスク容量を圧倒的に削減でき、レプリケーションに必要な転送量も格段に減ったためディスクバックアップのレプリケーションがコスト面でも十分現実的になりました。

結果、今日のバックアップではテープのほうが少数派になってきています。機密性の視点でもテープは排除されつつあります。

テープの暗号化は可能であるものの、テープそのものの盗難紛失のリスクがあり、テープの暗号化解読がどれだけ困難であっても盗難紛失という事件が発生すれば企業は社会的に信を問われます。これは以前にもまして、コンプライアンスの重要性が認知されている社会の変化にも起因します。

とある大手企業では、会社の信用を維持するために、コンプライアンスの観点1点のみで、企業グループ全体からテープを廃止しました。テープは膨大な技術データの保存やストリーミング系データに対しては有効な手段ですが、バックアップ、災害対策用としては不適切な時代になってきたのです。

本番データのレプリケーションを実現する3つの手法

さて、本番データのレプリケーションですが、前述したように、以下の3つの手法があります。

• ストレージ機能によるレプリケーション
• サーバ機能によるレプリケーション
• 仮想環境ハイパーバイザーによるレプリケーション

ただ、これらはどれを選ぶべきかというよりは、その環境に適したものを選択する形で適材適所の選択を行うものであるため、ここでは比較しての議論は割愛させていただきます。

ここまで、本番データを別のサイトに搬出する手法について述べましたが、ここからは実際に業務を復旧するために必要な要件について説明していきます。

端的にいうと、データが別の場所にあるだけでは業務は復旧できないという事です。では、何が必要なのでしょうか。

災害時復旧に必須である4つの要件

災害時に業務を復旧するにあたっては、以下の4つの要件が必須となります。

1. 業務アプリを復旧させるに足りるデータの整合性があること
2. 復旧手順が単純で緊急時でも容易に確実に実施可能なこと、または自動復旧できること
3. 業務が複数の業務アプリで稼働している場合、正しい順番で業務アプリ(システム)を復旧稼働させること
4. 災害時に業務が復旧できることを定期的に確認できること(災害訓練)

以下、それぞれの要件について解説します。

(1)業務アプリを復帰させるに足りるデータの整合性があること

データベースやメールサーバなど、構造化データと呼ばれるデータは、単純にその時点のデータ状態のコピーを作成しても業務アプリからは一般的に不整合な状態となり、意味のないデータとなります。

Oracleなどの一部のアプリケーションは、不整合なデータに対し正常復旧させるために自動修復を行う機能を持っていますが、復旧時のリスクを最小限にするためにも整合性を確保してのバックアップやレプリケーションが必要となります。

完全な整合性を担保するには、業務アプリを正常停止した状態でバックアップやレプリケーションを行う必要がありますが、重要な業務ほど停止することができない場合が多いです。そのような場合を想定し、少なくとも自身の整合性を担保できるバックアップ手法やAPIを提供している業務アプリを選定することが重要です。

(2)復旧手順が単純で緊急時でも容易に確実に実施可能なこと、または自動復旧できること

実際に災害が発生した場合、その復旧を担う人的要員の確保が重要です。

災害という異常事態では、本来復旧を行う担当者が災害に付随する諸般の事情で対応ができない場合も想定されます。そのような場合に、ある程度の知識や情報しか持ち合わせていない代行者が確実に復旧を行うには、その手順が単純であることが求められます。できれば、人手を介さず自動的に業務復旧まで行えるシステムを構築できていれば安心です。

(3)業務が複数の業務アプリで稼働している場合、正しい順番で業務アプリ(システム)を復旧稼働させること

業務全体の正常稼働を考えた時、複数のシステムが連携して業務を実現している場合が多く存在します。そのような場合、あるシステムが起動するには別の特定のシステムが稼働している必要がある場合も少なくありません。このような場合、担当者が注意深く起動順を見極めて復旧を行う必要があります。

業務やシステムごとにその関連性を把握し、正常に業務を復旧に導くことは、特に大規模なデータセンター環境では困難な場合が多いです。そのような場合のために、人の代わりに正しい順序で関連システムを立ち上げてくれる管理ソフトウェアがあると助かります。こうした人の代わりに複数のシステムを制御、管理する「統合型DR制御ソリューション」が注目を集めています。

(4)災害時に業務が復旧できることを定期的に確認できること(災害訓練)

さまざまな組織が、実際に災害が発生した時の人的安全確保の目的で災害訓練を実施しています。実際には想定していなかった問題を事前に洗い出したり、災害時にスムーズにとるべき行動をとれるようにしたりするための準備です。

この考え方はITインフラにおける業務復旧でも重要です。どのIT管理者もその重要性は理解しているはずですが、あまり行われていないのが実情です。その理由は、以下のようにまとめることができます。

• 実施には、本番業務の停止が必要
• システム全体の復旧手順が複雑で実施自体が困難
• 手順が複雑なため、訓練にかかる人的コストが承認されにくい
• システム変更が一部でも発生すると復旧手順の見直しが必要で、その手順を文書化して維持していくにはコスト的にも人的リソース的にも困難

ここまで災害復旧を想定して各種データ転送手法と、災害復旧の必須要件について説明してきました。しかし、同時にこれらを人手で実現するのは困難そうだということもわかってきたと思います。

そこで、先にも触れたソフトウェアによる「統合型DR制御ソリューション」という考え方が重要になってきます。

現在製品化されている最先端の「統合型DR制御ソリューション」では、復旧する業務ごとにシステムをグループ化し、そのシステムの復旧順序も事前に定義して、災害時にはGUIからワンクリックで業務を正しく復旧させることが可能になっています。

非常に簡単なオペレーションで復旧が行えることに加え、本番業務を停止せずに災害訓練を行えます。これにより、災害訓練も非常に簡単に、頻繁に、コストをかけずに実施することが可能で、災害復旧の確実性をより高い次元で担保します。

また、復旧のためのデータ転送手法として、ストレージレベル、ハイパーバイザーレベルに加え、管理ソフト自身が提供するレプリケーション機能も提供します。さらには、バックアップデータのレプリケーションおよびリストアとその後のシステム復旧も加えて、それらすべてを制御可能とすることで大規模データセンターのさまざまなインフラ環境を高いサービスレベルを維持したまま統括制御することが可能です。

ここで重要な点は、特定のインフラごとに依存した形の管理ではなく、さまざまなインフラに対し網羅的に統合管理制御ができる点です。例えば、VMware用, Hyper-V用、物理サーバ用に別々の復旧管理を行うだけで復旧手順は複雑化します。理想はこれらを網羅的に単一オペレーションでDR制御、管理が行えることです。

さらに、データを単に遠隔地サイトの同じ環境に復旧させるだけでなく、パブリッククラウド上に復旧させる試みも始まっており、例えば、VMwareの仮想マシンをAWSのEC2に災害復旧させる機能などは、すでに実現されています。

今後、クラウド間のDRやAWS以外のクラウドへのDRを含め、まさにハイブリッドクラウド環境に対し簡単かつ確実なDR制御が実現されようとしています。

次回は未来に向けたデータ保護のあり方について紹介します。データの保護ソリューションは、データが破損した場合に初めて活用される保険の様な役割として働きます。その反面、データ破損などの障害が発生しない場合無駄な投資として見られがちです。

しかし、バックアップデータの中身にはそもそも失ってはならないはずの重要なデータが詰まっているため、これをデータ破損対策以外の目的で有効活用ができないかという検討が進んでいます。

勝野 雅巳(かつの まさみ)

ベリタステクノロジーズ合同会社

テクノロジーセールス＆サービス統括本部

バックアップ & リカバリーアーキテクト

1989年に日商エレクトロニクス株式会社に入社。UNIXによるメインフレーム端末エミュレータ、E-mail専用アプライアンス、NAS製品、バックアップ製品の保守、デリバリー、プリセールスSEを歴任。その後2001年EMCジャパン株式会社にバックアップソリューション担当SEとして入社。 2013年、株式会社シマンテックにバックアップソリューション担当SEとして入社。2015年、株式会社シマンテックからベリタステクノロジーズ合同会社の分社に伴い、現職となる。

IT系商社時代から約20年にわたり、データ保護の専門家として業種の如何を問わず、提案活動を通してお客様のデータ保護に関する課題を数多く解決してきた。現在は提案活動と併せて、豊富な経験をもとにセミナーなどにおける講演活動やメディアへの記事執筆を行い、社内外にデータ保護のあるべき姿について啓発を続けている。趣味はテニス。