JP2005538470A - ノーダルフェイルオーバを用いるプライマリーデータバックアップおよびリモートデータバックアップ - Google Patents

Abstract

本発明は、ファイルバックアップとリモートレプリケーションとを行う機能を統合して、統合ストレージシステムを備えたコンピュータプライマリデータストレージシステムに関する。本発明の一実施の形態は、ファイルサーバのファイルを保護するためのデータ保護システムを提供する。このシステムは、ネットワークを介してファイルサーバと通信するプライマリリポジトリを含む。本発明の別の実施の形態は、対応するノードマネージャを用いて、複数のノードを有するリポジトリ内のノードマネージャを管理する方法を提供する。

Description

（発明の背景）
本発明は、ファイルバックアップとリモートレプリケーションとを行う機能を統合して、統合ストレージシステムを備えたコンピュータプライマリデータストレージシステムに関する。

（プライマリストレージ）
大抵の既存のプライマリデータストレージシステムは、その能力に融通性がなく、記憶容量とＩ／Ｏ帯域幅／性能とを別々に拡大縮小する。例えば、既存のディスクアレイは、３２個の帯域幅Ｉ／Ｏポートを最大１０テラバイトの記憶容量でサーバに備えることができるが、カスタマにとっては、４個のＩ／Ｏポートしか必要でないのに、アプリケーションに対して５０テラバイトの記憶容量が必要である。今日のデータストレージシステム対するこのようなモノリシックアプローチでは、時間の経過と共に（アプリケーションが）帯域幅／性能のいずれかをますます必要としていくにつれて、ストレージサブシステムの帯域幅／性能または記憶容量を別々に拡大縮小することが困難になっている。

今日では、データストレージシステムを分離した要素として、企業の各データセンター内に配備している。これらのシステムは、１つのデータセンター内で動作することに限定されていて、大都市圏または広域ネットワーク全域に渡ってインターネットワーク化されていることはほとんどない。２つ以上のデータセンターの間で相互接続されているという珍しい例では、これらのシステムはカスタムインターフェースとプロトコルとを用いており、構成と管理とが複雑である。複数のデータセンター全体に渡ってストレージリソースの相互接続性が欠けていることにより、十分利用されていないリソースがあるのにもかかわらず、完全に使い切られているストレージリソースがあるという問題が発生している。

一般に、プライマリストレージシステムは、企業の複数の部署に渡る複数のローカルクライアントアプリケーション間で確実に共有されるように設計されてはいなかった。ストレージエリアネットワーク（ＳＡＮ）ベースのディスクシステムを配置して、各サーバから別のサーバの論理装置番号（ＬＵＮ）の内容（ある程度のＲＡＩＤ保護が可能な１つ以上のディスクドライブによる記憶容量の量）を見られないように保護しようとすることができる。ＳＡＮがセキュリティおよび／またはホスト／サーバセキュリティを切り換えるディスクサブシステムセキュリティを用いて、ＬＵＮを不要のサーバから遮蔽する、競合し、協働する多くの方法がある。これらの方法は、組み合わせて用いると管理が難しく、複雑である。この理由のため、大抵の場合、ある部署からのＳＡＮに接続するサーバについては、データが同じＳＡＮ上でその他の部署のデータと混同しないようにする必要がある。この要件のため、ＳＡＮの費用と複雑さとが著しく増加してしまう。

また、記憶容量リソースを共有しない場合では、全リソースの平均的な消費量は一般に５０％未満である。各アプリケーションが長期にわたって必要とするデータストレージは予測不可能なので、ストレージリソースの半分は利用が９０％に達するが、他の半分は１０〜２０％の容量でほとんど未使用の状態で動作する。これらのストレージリソースの全部を確実なやり方でもっと多くのアプリケーションで共有できるならば、全体的な利用状態を約８０〜９０％まで増加できる。”実社会でのストレージの利用（Ｒｅａｌ−Ｗｏｒｌｄ Ｓｔｏｒａｇｅ Ｕｔｉｌｉｚａｔｉｏｎ）”『ストレージマガジン』２００３年４月号の記事では、平均的なＳＡＮストレージの利用は３９％であると指摘している。

今日では、ファイルシステムをボリュームに基づいて構築し、ボリュームを複数の物理ディスクドライブからのストレージスペースの集合とすることができる。ユーザまたはアプリケーションに対し、ファイルシステムに容量がもうない場合、ストレージアドミニストレータまたはシステムアドミニストレータが、ディスクドライブをサーバに多く割り当てることができる。そして、アドミニストレータがこれらのディスクドライブをより大きなボリュームにまとめて、最後に、アドミニストレータがファイルシステムを拡張して、ユーザデータをさらに格納することができる。ファイルシステムが満杯になったら、全ストレージスペースを使い切ってアプリケーションが機能しなくなる前に、アドミニストレータは直ちにこの状態に対応する必要がある。一般的なデータセンターは何百ものファイルシステムを有しており、一日のうちの数時間でそれぞれが満杯になるので、直ちに対策をとる必要がある。『汎用部品から構築されるディスクストレージシステムのシステム管理にかかる費用を低減すること』（Ｒｅｄｕｃｉｎｇ ｔｈｅ Ｃｏｓｔ ｏｆ Ｓｙｓｔｅｍ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ ｏｆ ａ Ｄｉｓｋ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ Ｂｕｉｌｔ ｆｒｏｍ Ｃｏｍｍｏｄｉｔｙ Ｃｏｍｐｏｎｅｎｔｓ）、浅見賢（Ｓａｔｏｓｈｉ Ａｓａｍｉ）（カリフォルニア州立大学バークレー校リポート（ＵＣ Ｂｅｒｋｅｌｅｙ−Ｒｅｐｏｒｔ）Ｎｏ． ＵＣＢ／ＣＳＤ−００−１１００）というタイトルの論文では、通常の業務時間外に行われる必要があるサービス業務に関する次の調査データに基づいている：
・真夜中にポケベルで呼び出されたばかりのシステムアドミニストレータは、通常の勤務時間の間だけで修復作業を行うアドミニストレータよりもずっとミスをしやすい。睡眠不足は、とんでもないディスクコピーミスを起こす１つの要因であった。

・睡眠不足と人間の働きの問題に関して、生理学および心理学の分野で調査が非常に多く行われていた。人々は、長時間労働の後と通常の睡眠時間の間とでは、正確にかつ効率的に仕事ができない恐れがある。

・問題処理に関するモデルに基づく方法によれば、睡眠不足の問題は、予防を行うよりもむしろ、事後対応の行動を示す傾向がある。障害が起きた時にシステムを安定させるために、オペレータはもっと頻繁に操作を行うが、何が悪いのかはっきり考えていないことが良くある。この種の不注意を反映する行動は、脆弱な状態にあるストレージシステムにとって危険であり、データ損失に容易につながってしまうと指摘する価値がある。

また、従来のネットワーク接続ストレージ（ＮＡＳ）システムでは、ファイルシステムが満杯になると、データのある量をあるＮＡＳサーバから別のものへ移動する必要がある。この移動により、この移動の間はユーザはデータにアクセスできなくなり、移動が完了するまで何時間もかかることが良くある。

高価なＳＡＮベースのストレージシステムは、ＮＡＳゲートウェイ機器を有するフロントエンド型で、ＮＡＳクライアントシステムにネットワークファイルシステム（ＮＦＳ）と、ＳＡＮディスクストレージに対する共通のインターネットファイルシステム（ＣＩＦＳ）アクセスとを備える。この方法により、アプリケーションの必要が増加するにつれて、ＮＡＳ記憶容量を拡張する便利なやり方が行えるが、プライマリデータストレージの形態で最も高価なものであるＳＡＮストレージに、十分利用されず、まれにしかアクセスしないデータの量が、ますます増加してしまうことになる。最長時間未使用データをＳＡＮからコストがもっと安いストレージへ移動させるために用いる増設階層型ストレージ管理用の製品あるが、このデータ管理用ソフトウェアを最も普及している既存のＮＡＳサーバにインストールして実行することができない。

（データ保護、バックアップ、階層型ストレージ管理（ＨＳＭ）および保存）
バックアップサーバ、テープライブラリ装置、テープドライブ、バックアップサーバ、クライアントソフトウェアや媒体等のデータ保護システムはまた、複数のサイトに渡って、あるいは同じデータセンター内の複数のバックアップサーバの間で共用することができない。このことにより、テープドライブリソースについて、不均衡な能力を越えた利用と不十分な利用とが発生する。

また、ストレージアドミニストレータがデータを磁気テープに格納する場合、一般に第２のコピーしたテープを作成して、オフサイトストレージ施設に送信する。このテープコピープロセスは管理に費用がかかり、バックアップデータ保護に関する媒体費用を２倍にする。

関連したことでは、プライマリストレージは保持できる履歴データの量に限度がある。データセンターがデータを磁気テープに定期的に保管して、サーバからデータを除去して容量を新しいアプリケーションのために空けることは周知のことである。サーバから除去されたので、アプリケーションがアクセスすることはもうできない。アプリケーションが保管されたファイルにアクセスする必要がある場合には、一般にアドミニストレータに対する操作要求を介して復元する必要がある。どのデータを保管して、どのデータをサーバに残すか評価することは難しいので、頻繁にアクセスしてプライマリストレージ上で保持する重要なデータをうっかり保存して、保存すべきデータをプライマリストレージ上に残してもっと重要なデータが使用するはずの貴重な記憶容量を使ってしまうことは周知のことである。

また、プライマリストレージを保護するために用いられる、競合する別々のデータ保護方法が多くある。これらの保護方法は、独立ディスク冗長アレイ（ＲＡＩＤ）、スナップショット（特定の時点の１セットのデータのコピー）、テープバックアップ、オフサイトテープストレージ、ブロックまたはファイルレベルのいずれかでのリモート同期または非同期ディスク複製を含む。これらの作業は全て、あるレベルのデータ保護を独立して行う。これらの独立性により、この多種多様の独立したデータ保護ツール上で、それぞれ１メガバイトのプライマリデータストレージを１５メガバイトものデータで保護してしまうという、過剰複製の問題が発生することになる。

地理的に１つまたは２つの主要データセンターを持ち、数十から数百のより小さな遠方のオフィスから構成される企業が多く存在する。一般に、訓練を受けていないストレージアドミニストレータがより小さな遠方のオフィスにいるので、適切にストレージ管理をすることが難しい。このようなサイトに渡るデータ管理の習慣の多様性により、これらの企業は、サイト災害の後で１つ以上の遠方のオフィスが失われた場合、大量の新しいデータを失う危険にさらされている。この問題に対する解決策の１つは、遠方のオフィスのデータの全てを集中的に中央データセンターにバックアップすることである。残念ながら、バックアップソフトウェアプログラムは長距離の広域通信リンクでさらに待ち時間があり十分機能しないので、これは現在のところ実行可能な解決策ではない。

アプリケーションの必要性に目を向けると、医療用放射線画像、医薬品臨床試験、油田探査、デジタルライブラリ等のアプリケーションでは、何十年もの間データを保持してアクセスできるようにする必要がある。磁気テープを用いるデータ保護システムは一般に、テープドライブが７〜１０年ごとに旧式になり、逆方向の互換性がない。磁気テープの開始から、一説には１００以上の、非常に多くの磁気テープカートリッジ／媒体の構成が作成されていた。一般に、今では旧式の媒体に貴重な長期の履歴データを保持している企業は、これらの媒体を継続して読み出せる旧式の駆動装置を継続するか、これらの旧式の媒体技術からもっと新しい媒体技術へデータをコピーするという管理が難しい作業を行うか、決定する必要がある。また、データが古くなればなるほど、データを正常に検索することがますます難しくなる。これは、互換性のある駆動装置の技術が利用できるかどうかばかりでなく、テープに記録されたデータの判読率が長期間経ると劣化してしまうからである。データに長期に渡ってアクセスすることに伴う別の問題は、テープ保管室またはリポジトリから貸し出したものが戻ってこなかったりしたテープや、リポジトリ内の間違った場所に置いたりしたテープをちゃんと探し出すことである。

地震錐芯試料分析や医療用画像／放射線といったアプリケーションの多くは、長期のアーカイブストレージシステムから非常の恩恵を受けていて、何十年も前のデータがまさに作成された時の状態で速やかに、確実に、効率的にデータにアクセスすることができる。

関連したことでは、システムアドミニストレータは頻繁に階層型ストレージ管理（ＨＳＭ）システムを用いて、長時間未使用データをもっと安いデータストレージ媒体に移動する。システムアドミニストレータは一般に、ＨＳＭストレージシステムをテープにバックアップして、最も使用されるデータをもっと安い媒体に移動しないように保護する。これらの分離型データ管理アプリケーション、例えば、移動したデータを保護するＨＳＭシステムや、移動しないデータを保護するバックアップシステムは一般に、別々の業者から購入して、大抵の場合は互いに相互運用しないものである。このことがデータの過剰複製につながるのは、どちらのアプリケーションももう一方のアプリケーションのデータ保護方法を理解しないからである。

磁気ディスクのコストがすぐに磁気テープのコストになってしまうことから、”ディスク間バックアップ”製品と呼ばれる多数の新しい製品が出現している。これらの解決策の大抵は、磁気テープストレージに伴う大きな管理運営問題を解決しようとするものではない。実際、バックアップサーバとそのテープライブラリとの間に価格の低いディスクストレージシステムを挿入することにより、すでに複雑なテープバックアッププロセスが複雑になってしまう。これらの価格の低いディスクサブシステムは、クライアントデータのバックアップにかかる時間を短縮するのに有効である場合もあるが、これらの解決策はまた、ストレージ管理の複雑さと主要経費とを増加する。

テープバックアップに戻ると、テープバックアップは一般に、全プライマリストレージデータを１セットの磁気テープに週１回の頻度で全バックアップの一部として書き込むスケジュールで行われる。これらの全バックアップで変更するデータは、インクリメンタルまたは差分バックアップの一部として夜間にテープに記録される。全バックアップは、金曜の夜から月曜の早朝までの週末のバックアップウインドウ内でバックアップを完了させるもので、多くのバックアップアドミニストレータにとって最大の課題である。保護するデータの量が継続して増加するにつれて、バックアップを完了する週末のウインドウを定期的に延長するようになる時点まで、全バックアップを行う時間が増加する。

関連したことでは、今日のソフトウェアベースのファイル複製システムにより、ローカルでもリモートでもデータコピーを行うことができる。災害復旧のある形態として複製を行うことができるが、ソフトウェアベースの複製製品では各ファイルの最新のコピーしか保持できない。これらのシステムはまた、テープバックアップの解決策により保護して、完全なデータ保護には時間の経過と共に保持される各ファイルの履歴バージョンを備える必要がある。また、複製製品にはファイル削除をどのように処理するかという問題がある。すなわち、複製製品は、ファイルのローカルコピーをいつ削除するか決定し、リモートコピーを削除するかどうか決定しなければならない。ローカルコピーを削除する場合はファイルの全コピーを削除する必要があるアプリケーションや、リモートコピーを削除してはならないアプリケーションまたは付随的操作がある。大抵の製品には、ローカルファイルを削除する場合にファイルのリモートコピーに何が発生するか制御する機能が備えられているが、ファイル削除を操作する一般的な方法を適用することが難しいのは、ファイル毎にその方法が変化するからである。最後に、複製を用いるシステムが有効にプライマリストレージを２倍にして、作成したファイル毎に保持する複製の数がまたもや増加してしまう。

（ストレージ管理アプリケーション）
今日のプライマリストレージ装置およびデータ管理ソフトウェアアプリケーションは全て、図形のユーザインターフェースおよび／またはコマンドラインインターフェースの形式のユーザインターフェースを有している。ストレージアドミニストレータは、これらのインターフェースが各ストレージ構成要素を正常に監視し、制御し、構成するように、定期的に訓練を受ける必要がある。データ保護システムの集まりを有するプライマリストレージシステム毎に、アドミニストレータは多くの、例えば、１２もの別々のインターフェースに熟達している必要がある。

また、企業がデータストレージとデータ保護業者との限られた組み合わせを標準化する場合でも、これらの構成要素のそれぞれについて、これらのストレージリソースやアプリケーションの全てをマルチデータセンターという観点で提示していない。各データセンターは、それぞれのローカルストレージリソースをそれぞれのデータセンター内のストレージや保護リソースの限られた見方で管理することになる。ウェブベースの管理インターフェースでは、ユーザがデータを任意のロケーションから見ることができる。ユーザインターフェース内で示されるデータは一般に、１つのサイトに限定されている。

関連したことでは、ストレージリソースの消費量に対する原価計算は複雑な問題である。ストレージリソース管理アプリケーションにより、ユーザ、ファイルシステム、部署、コストセンター、地域等からのプライマリストレージ消費量に関する全体的な見方を提供することができるが、バックアップ、複製、ＲＡＩＤ、スナップショット等のデータ保護アプリケーションで消費したストレージリソースの明細を提供することはできない。プライマリストレージとデータ保護リソースとの両方に対する適切な原価計算がないと、全ストレージリソース消費量をある部署には過剰に請求して、別の部署には料金以下の請求をすることになる。

（発明の要約）
本発明は、ファイルバックアップとリモートレプリケーションとを行う機能を統合して、統合ストレージシステムを備えるコンピュータプライマリデータストレージシステムに関する。本発明の一実施の形態は、ファイルサーバのファイルを保護するためのデータ保護システムを提供する。このシステムは、ネットワークを介してファイルサーバと通信するプライマリリポジトリを含む。

このプライマリリポジトリは次のものを有する。データを格納するためのプライマリリポジトリノードと、プライマリリポジトリノードおよびネットワークと通信し、ファイルサーバと通信するためのプライマリリポジトリノードＡＰＩと、プライマリリポジトリノードおよびネットワークと通信し、ファイルサーバからファイルを受信するためのプライマリリポジトリファイル転送部と、プライマリリポジトリノードＡＰＩと通信するデータムーバ（ファイルサーバからプライマリリポジトリノードへのファイルの複製を監視する）と、データムーバと通信し、ファイルロケーションデータを格納するロケーション構成要素と、プライマリリポジトリノードの保存状態を維持するためのディレクトリサービスと、ロケーション構成要素およびディレクトリサービスと通信するノードマネージャ（プライマリリポジトリノードの記憶容量と性能とを管理する）である。

このシステムはさらに、ファイルサーバおよび／またはリモートリポジトリを含むことができる。一実施の形態では、リモートリポジトリは、ネットワークを介してプライマリリポジトリと通信する。リモートリポジトリは次のものを含むことができる。データを格納するように機能するリモートリポジトリノードと、リモートリポジトリノードおよびネットワークと通信するように構成されているリモートリポジトリノードＡＰＩと、プライマリリポジトリファイル転送部およびリモートリポジトリノードと通信し、プライマリリポジトリファイル転送部からファイルを受信するように構成されているリモートリポジトリファイル転送部と、リモートリポジトリＡＰＩと通信し、プライマリリポジトリノードからリモートリポジトリノードへのファイルの複製を監視するように機能するデータムーバと、データムーバと通信し、ファイルロケーションデータを格納するように機能するロケーション構成要素と、リモートリポジトリノードの保存状態を保持するように機能するディレクトリサービスと、ロケーション構成要素およびディレクトリサービスと通信し、プライマリリポジトリノードの記憶容量と性能とを管理するように機能するノードマネージャである。

本発明の別の実施の形態は、対応するノードマネージャを用いて、複数のノードを有するリポジトリ内のノードマネージャを管理する方法を提供する。この方法は以下を含む。ブートストラップした状態でノードマネージャを起動して、指定した基準により、マスタノードマネージャおよび複製ノードマネージャを選択して、残りの全ノードマネージャをドローン状態に設定して、マスタノードマネージャおよび複製ノードマネージャのうちの少なくとも１つが故障した場合は、指定した基準により、ドローンノードマネージャから代わりのノードマネージャを選択する。

（図面の詳細な説明）
図１は、本発明の統合プライマリデータストレージ兼データ保護システムを示す図である。ファイルサーバ４は、ネットワークファイルシステム（ＮＦＳ）、コモンインターネットファイルシステム（ＣＩＦＳ）、ファイル転送プロトコル（ＦＴＰ）等の標準ネットワーク接続ストレージ（ＮＡＳ）プロトコルを介して、プライマリデータ記憶容量をクライアントシステム５に供給する。この装置は、データセンターＡ、Ｂ、Ｄとして図１に示す２つ以上のデータセンター１の間で動作するように設計されている。これらのデータセンターの間で配置されている２つ以上のリポジトリ３により、記憶容量とデータ管理処理機能とを備えて、完全なデータ保護を対応するファイルサーバプライマリストレージシステムに供給する。この装置により、大都市圏または広域インターネットプロトコル（ＩＰ）ネットワーク（ＭＡＮまたはＷＡＮ）２を強化して、リポジトリが、あるリポジトリから別のリポジトリに複製する必要があるデータを送受信できるようにする。データを発信ファイルサーバからローカルの少なくとも１つのリモートリポジトリに複製することにより、これらのリポジトリが、従来のオンサイトテープバックアップとオフサイトテープストレージ／保管サービスを置換したものとして動作する。サイト災害の場合には、新しいファイルサーバを残っているサイトに配備して、故障したファイルサーバの内容を残っているリポジトリの内容から再現することにより、破壊された全ファイルサーバを速やかに復旧する。

図２は、ファイルサーバ６と、データセンターに渡って配置する２つ以上のリポジトリ８との間の相関関係を示す。ＮＦＳ、ＣＩＦＳまたはＦＴＰ共有資源７を介して、全プライマリデータストレージの動作は、１つ以上のクライアントと１つ以上のファイルサーバとの間で発生する。共有資源は、記憶容量のディレクトリまたはフォルダとしてファイルサーバに生成される。共有したディレクトリまたはフォルダの内容は、ローカルエリアネットワーク全域で複数のクライアントからアクセス可能である。例えば、マイクロソフトウインドウズ環境では、ＣＩＦＳ共有資源が、ウインドウズエクスプローラユーザインターフェースの”Ｍｙ Ｎｅｔｗｏｒｋ Ｐｌａｃｅｓ”のＬＡＮ接続サーバ内のストレージフォルダとして現れる。ＵＮＩＸ（登録商標）環境では、共有資源には、データをローカルクライアントシステムのファイルシステムの仮想フォルダと共に格納する実際のファイルサーバとフォルダとを定義するマウント点を介してアクセスする。

ファイルサーバを、少なくとも１つの、可能なら数十の共有資源を有するように構成する。これらの共有資源により、ファイルサーバのプライマリ記憶容量を共有して、複数のクライアントシステム間で確実にパーティションに分割できるようになる。この装置はプライマリデータストレージでありかつデータ保護システムでもあるので、ストレージアドミニストレータが、その共有資源に対する一意の保護方法９の基準を介して、２つ以上のリポジトリに渡ってどのようにファイルサーバの各共有資源を保護するか定義する。一実施の形態では、この保護方法により、どのリポジトリを用いて各共有資源のデータを保護するか定義するかだけでなく、一実施の形態では、どのくらいの頻度でデータ保護を行うか、共有資源のデータの重要度に基づいて各リポジトリ内に複製をいくつ保持するか、共有資源データに対する更新や変更をどのように保持するかについても定義する。定期的に各ファイルサーバがその共有資源に対する保護方法を検討して、適切ならば、ファイルサーバが共有資源のファイルに対する最新の変更をすべて取得し、２つ以上のリポジトリ内にこれらのファイルを格納して保護する。

図３は、３つのリポジトリ１０、すなわち、大都市圏または広域ネットワーク１１を介してリモートで互いに接続しているリポジトリ１、３、８を示す図である。各リポジトリは、２つ以上のリポジトリノード１２、例えば、リポジトリノードＲＮ３ａおよびＲＮ３ｂを有する。各リポジトリノードは、その全ファイルの妥当性チェックを行い、そのファイルをデルタ圧縮またはファイル圧縮し、各ファイルのバージョン連鎖を保持し、ファイルを圧縮する処理機能を有する。妥当チェックに失敗したファイルや、リポジトリノードのディスクドライブ、リポジトリノード、もしくは全リポジトリが故障したため利用できないファイルを複製したり再複製したりするために、各リポジトリノードは他のリポジトリノードと相互作用する。図３に示すように、リポジトリの記憶容量に対する必要性が高まれば、リポジトリノードを別々に各リポジトリに追加することができる。また、ファイルサーバを追加して、全装置にアクセスする際のクライアントアプリケーションの全帯域幅および性能を増加することができる。

図４は、本発明の一実施の形態の保護方法のスクリーンショットである。一実施の形態では、各ファイルサーバのそれぞれの共有資源に対してストレージアドミニストレータが定義する一意の保護方法がある。保護方法の画面に到達する前に、ストレージアドミニストレータは共有資源を生成して、それに対してＣＩＦＳおよび／またはＮＦＳおよび／またはＦＴＰがアクセスできるようにする。一旦新しい共有資源が生成されると、保護方法の画面が表示される。この画面内では、ストレージアドミニストレータが次のデータ保護パラメータを指定することができる：
・この共有資源１３を保護する−通常、このチェックボックスにチェックマークを付けて、この共有資源のデータをリポジトリで保護する必要があることを示す。プライマリストレージのファイルサーバを用いるために選択する、あるクライアントアプリケーションが存在する場合もあるが、サードパーティのバックアップ製品またはアーカイブ製品を用いてデータ保護を継続する。このチェックボックスにチェックマークを付けない場合は、保護方法のユーザインターフェースの他の全選択肢が使用不可能になる。

・保護管理−バックアップ頻度１４−この選択肢により、ファイルサーバの共有資源のデータをローカルリポジトリおよびリモートリポジトリ内でどのくらいの頻度で保護するか決定する。一実施の形態では、バックアップ頻度の間隔を時間間隔リストから選択することができる。これは、１５分、３０分、１時間、２時間、３時間、４時間、６時間、８時間、１２時間、２４時間を含む。全バックアップ頻度の間隔は各ファイルサーバのローカル時間帯の深夜１２：００に固定されている。バックアップ頻度を２４時間に設定することは、従来の毎日のインクリメンタルバックアップの実施と同様である。この間隔を１５分に設定することにより、日中頻繁に変更するファイルのバージョンを１５分間隔で保護することができる。最新のバックアップが行われたために変更したファイルだけをリポジトリにセーブする。

・保護管理−１リポジトリ当たりの複製の数。この選択肢は、ストレージアドミニストレータが、共有資源を保護する際にデータの複製１５をいくつ各リポジトリ１６内に生成するか決定するものである。一実施の形態では、共有資源のファイルサーバに対しローカルのリポジトリ内に少なくとも１つの複製が存在する。１つのリポジトリ内に複数の複製を保持することができる。この場合、複製を１つのリポジトリの別々のリポジトリノードに保持して、１つのリポジトリノードが故障したり、ネットワーク故障があったりした際に複製に確実に継続してアクセスできる。複製のロケーションや数を、時間の経過と共に変更することができる。重要度がますます大きくなるデータのデータ利用可能性を高めるために、１リポジトリ当たりの複製をさらに増やして、追加のリポジトリを指定することもできる。重要性が低下しているデータについてはリポジトリ内にもっと少ない数の複製を保持して、それらのリポジトリを使用する他の共有資源が記憶容量をより多く利用できるようにする。

・バージョン管理−バージョン履歴１７の維持−そのファイル内容を定期的に更新した共有資源について、このチェックボックスにチェックマークを付ける必要がある。チェックマークを付けると、指定したリポジトリが各バックアップ頻度の間隔で特定した全変更のバージョン連鎖を保持する。ファイル内容の変更がないデータの共有資源については、このチェックボックスにチェックマークを付ける必要はない。

・バージョン管理−バージョン圧縮１８−一実施の形態では、３つの圧縮選択肢がある。圧縮しない、デルタ圧縮、あるいは共有のファイルのファイル圧縮である。ファイル圧縮とは、等業者が周知の様々なファイル圧縮技術のことをいい、圧縮しないファイルと同じだけのストレージスペースをとらないようにする。デルタ圧縮は一般に、そのファイルを定期的に変更した共有資源に対し最も大きい圧縮率となる。

・バージョン管理−バージョン圧縮１９−圧縮により、バージョンの古さに基づいて、ファイルのバージョンを削除する手段を提供する。例えば、ファイルの共有資源に対するバージョン圧縮選択肢を構成して、１年経過したら１月毎のファイルのバージョンを、６ヶ月経過したら１週間毎のファイルのバージョンを、１ヶ月経過したら１日毎のファイルのバージョンを保持するようにする。全ての”余分な”バージョンを自動的にリポジトリから削除することにより、ファイルの新しいバージョンがもっと記憶容量を利用できるようにする。

・詳細な選択肢−削除２０に関する除外−一実施の形態では、デフォルトではこの選択肢を選択しない。この方式では、アプリケーションまたはユーザが故意に、あるいは誤ってファイルサーバからファイルを削除してしまった場合でも、リポジトリに存在する複製やそのファイルに対応するバージョンは影響を受けない。これにより、ストレージアドミニストレータが、今日のバックアップテープから復元したデータとほぼ同じ方法でファイルサーバから誤って削除したファイルを復元することができる。削除選択肢の除外は、チェックマークを付けた場合にサードパーティのバックアップ、ファイルアーカイブ、文書および内容管理、電子メールアーカイブ等のアプリケーションで有効となる。リポジトリから得た複製やバージョンのあるものは、そのアプリケーションの復旧ウインドウの条件を満たすのにもはや必要ではなくなるので、ファイルをファイルサーバから削除する際に全リポジトリから除外することもできる。

・詳細な選択肢−キャッシングレベル２１−この選択肢により、ストレージアドミニストレータがファイルサーバにキャッシュするクライアントデータの量を設定することができる。一実施の形態では、通常この選択肢を”読出の最適化”に設定して、最短時間アクセスファイルの最大数を最も高い性能レベルでクライアントアプリケーションが利用できるようにする。全ての最長時間未使用データを２つ以上のリポジトリに保持する。逆に、キャッシングレベルを”書込の最適化”に設定して、クライアントが利用できるキャッシュデータの量を減らすことができるが、サードパーティのバックアップ等の主として書込用のアプリケーションが利用可能な記憶容量を常に高レベルにする。この方式では、データを積極的にファイルサーバからリポジトリに移動することにより、アプリケーションがファイルサーバを仮想的に無限の容量を有するストレージ装置として見なすようにする。

図５は、図１に示すシステム等のデータ保護システムを管理するウェブベースのアプリケーションのユーザインターフェースに関する一実施の形態を示す。ユーザインターフェースの左下の窓は、この場合では１つ以上のデータセンターがある都市のロケーションにより定義されるトップレベルの階層を示すアセットツリー２２である。各データセンターは、１つ以上のファイルサーバとリポジトリとを有する。各リポジトリは、２つ以上のリポジトリノードを有する。従って、一構成では、本発明の統合データストレージ兼保護システムを２つ以上のデータセンターに渡って配置する。例えば、西ボストン、東ボストン、ニューヨークに位置するデータセンターである。図５〜図８に示すユーザインターフェースでは、ファイルサーバ、すなわち、プライマリデータストレージ装置をグリッドポート（ＧＲＩＤｐｏｒｔ）、リポジトリノードをグリッドディスク（ＧＲＩＤｄｉｓｋ）と呼ぶ。

一実施の形態では、各リアルアセット（リポジトリノードおよびファイルサーバ）の状態を、その要素の動作状態を表すカラーオブジェクト２３で示す。構成要素が正常に動作している場合は、緑の球で示す。容量が低下している状態で構成要素が動作している場合は、黄色の警告を示す三角形を表示する。最後に、構成要素が動作していない場合は、中に”Ｘ”が付いた赤丸を表示する。リポジトリノードおよびファイルサーバの状態は、階層のより高いレベルに上がる。例えば、リポジトリノードがダウンしたら、リポジトリノード、そのリポジトリ、そのデータセンター、その都市、トップレベルツリーインジケータの全てがその”ダウン”状態を反映することになる。これのことは、問題のある構成要素を速やかに簡単に突き止められるので、時間の経過と共に数百個になるであろう構成要素の数が増加するにつれて非常に重要になる。

タブメニューバー２４により、アドミニストレータは、例えば、状態、グリッドポート、グリッドディスク、リポジトリ消費量、詳細な消費量、共有資源消費量、グリッドポート消費量、複製といった数個の利用可能なリポートから選択することができる。

また、タブメニューバーにより、アドミニストレータは構成タブを選択することができる。構成ユーザインターフェースを介してアプリケーションマネージャにより、アドミニストレータは装置をリモートで制御することができる（例えば、リポジトリノードを再スタートしたり、ファイルサーバをオンラインにしたりする）。アドミニストレータは、この構成タブを介して、ファイルの復元を行い、各ファイルサーバ共有資源の保護方法を構成することもできる。

図６は、図５のユーザインターフェースに対応する共有消費量リポートの一実施の形態を示す。このリポートは、共有資源容量の消費量に基づいて、個別の部署に対するストレージリソースの利用の明細を定期的に明らかにする手段として、ＣＩＯおよびＣＦＯにとって有益である。始めの４列、すなわち、サイト、サイトグリッド、グリッドポート、共有資源は、ファイルサーバおよびそれらの共有資源のロケーションを定義する。現在のバージョンの容量は、リポジトリの記憶容量を共有資源内のファイルの現在のバージョンの共有資源がどのくらい消費しているかに対応する。以前のバージョンの容量は、共有資源内のファイルの最新バージョン以外の全ファイルの全バージョンのリポジトリが消費している全容量に対応する。最後に、現在および以前のバージョンの容量の合計を右端の列に表示する。このリポートにより、どの共有資源が、配置している多くのリポジトリの間で最大または最小の記憶容量を消費しているかについての最新の情報が得られる。

図７は、より詳細な容量リポートを示し、各ファイルサーバの共有資源と、１リポジトリ当たりで消費する現在及び以前のバージョンの記憶容量の量とを示す。このリポートをストレージアドミニストレータが頻繁に用いて、特定のリポジトリの記憶容量を一番消費する記憶容量の共有資源を特定する。各共有資源を、２つ以上のリポジトリで保護する。

図８は、１リポジトリ当たりで消費する容量を示す。ストレージアドミニストレータは、リポジトリ容量の消費量レベルを監視して、もっと多くのリポジトリノードをリポジトリに追加する必要があるのはいつか決定する。すなわち、リポジトリ消費量概要リポートは、サイト、サイトグリッド、ディスク容量、消費した容量、消費した容量の割合に関する列を有する。サイトグリッドは、ファイルサーバ（グリッドポート）およびリポジトリの集まりを表す。また、この容量リポート図により、警告閾値列を提供する。警告閾値は、ストレージアドミニストレータが１リポジトリ当たり毎に設定でき、リポジトリの消費量が指定した消費量割合を越えた際にアドミニストレータに対して警告することができる閾値である。

図９は、複数のファイルサーバの構成に関する一実施の形態を示す。例えば、ファイルサーバ１ｙ、１ｚ、２ｙ、２ｚ、３ｙ、３ｚが複数のリポジトリ、例えば、１ａ、２ａ、３ａを共有して、それらのデータをローカルでもリモートでも保護しながら、ＮＡＳ機能をクライアントに供給することである。すなわち、リポジトリ１ａ、２ａ、３ａはそれぞれ、ファイルサーバ１ｙおよび１ｚ、２ｙおよび２ｚ、３ｙおよび３ｚ、に地理的に対応する。リポジトリおよびファイルサーバは、標準ＩＰネットワークを介して共に接続していて、冗長的に配置して利用可能性を増加する。ファイルサーバは、ＮＡＳベースのプライマリストレージをファイルサーバに対してローカルのクライアントに供給する。例えば、ファイルサーバ１ｚ内に位置する共有資源は、そのデータをローカルリポジトリ１ａとリモートリポジトリ３ａとに保護させることもできる。本発明の保護方法を介して、各ファイルサーバのそれぞれの共有資源を、そのデータを２つ以上のリポジトリに保護させるように構成することもできる。１つのリポジトリに共有資源のデータの複数の複製を保持させて、さらに冗長させることも可能である。この場合は、同じリポジトリ内の２つ以上のリポジトリノードがそれぞれ複製を保持して、ネットワーク故障またはシステムリソース故障のために利用できなくなる場合に、少なくとも１つの複製を継続的に利用できるようにする。

図１０は、より小さな遠方のオフィス２６を備える集中ＩＴインフラ２５を有する企業のための本発明の構成に関する一実施の形態を示す。遠方のオフィスを、企業の既存のＩＰ大都市圏または広域ネットワーク２７を介して相互接続する。この構成では、ファイルサーバにより、プライマリストレージを各リモートロケーションのクライアントに供給する。これらのファイルサーバに対応する共有資源を構成して、それらのファイルサーバのデータをローカルリポジトリと企業の本社２５にあるリポジトリとに保護させることができる。利用可能性を高めるために、第２の主要データセンターを形成して、２つの集中データセンターにデータを複製することもできる。

図１１は、カスタマの既存のＳＡＮを用いて、階層化ストレージ機能を提供するようにした本発明の構成に関する一実施の形態を示す。図１１は、最短時間アクセスファイルデータをキャッシュするための内部ファイルサーバディスクストレージを用いる代わりに、ファイルサーバ２ｙをＳＡＮストレージに接続したことを除いて、図９に示す構成と同じである。会社のプライマリストレージインフラをＳＡＮベースのストレージに基づくように決定した企業では、ファイルサーバをＳＡＮストレージに接続することができる。図１１では、ファイルサーバ２ｙを除いて、全ファイルサーバがそれぞれ内部ディスクストレージを有する。一実施の形態では、このファイルサーバ、すなわち、ファイルサーバ２ｙを、ファイバチャネルネットワーク接続を介してＳＡＮストレージに接続する。このインターフェースを介して、ファイルサーバ２ｙは、ファイルサーバ２ｙに割り当てられた１つ以上のＳＡＮのＬＵＮを有し、これらのＳＡＮのＬＵＮの記憶容量をそのファイルサーバのローカルストレージとして動作させることができる。ファイルサーバが階層型ストレージ管理を実施するので、階層型ストレージ管理技術を用いて、最長時間アクセスのないＳＡＮのＬＵＮに存在するファイルサーバのファイルを、自動的にこれらの高価なＳＡＮボリュームからもっと価格の安いローカルリモートリポジトリに移動する。また、ファイルサーバに割り当てられたＳＡＮボリュームに存在する全データを、ローカルリモートリポジトリに保護することにより保護用のサードパーティのテープバックアップまたはオフサイト複製製品を用いる必要性を不要にする。

図１２は、従来のバックアップサーバやソフトウェアと共に用いる場合にテープドライブ／テープ媒体を置換したものとしての本発明の構成に関する一実施の形態を示す。この構成は、ＮＡＳサービスをクライアントアプリケーションに供給することの一部としてファイルサーバに生成または変更した新しいファイルのための本発明の別の実施の形態により提供する統合バックアップとは異なっている。このモデルでは、カスタマがすでに普及しているサードパーティのバックアップアプリケーションを使用していて、従来、一連の磁気テープに書き込んでファイルサーバの共有資源の集まりにする代わりに、１つ以上のクライアントシステムから集めたバックアップデータ向けになっているものである。図１２は、ファイルサーバ２ｙおよび２ｚをバックアップサーバ２Ａ、２Ｂ、２Ｃとネットワーク化して、ファイルサーバ３ｚをバックアップサーバ３ａに接続していることを除いて、図９に示すものと同じ構成である。バックアップサーバ２Ａ、２Ｂ、２Ｃはそれぞれ、ファイルサーバ２ｙおよび／または２ｚに渡って１つ以上の共有資源を用いるように構成することもできる。このモデルでは、ファイルサーバ共有資源をテープドライブの代わりに用いて、バックアップデータを格納することができる。このバックアップの形態は、一般にディスク間バックアップと呼ばれるもので、手作業でテープ媒体を管理することなく、バックアップの管理を非常に簡略化するものである。また、磁気ディスクドライブのコストはまた、磁気テープのサブシステム（テープドライブ、テープジュークボックス、テープ媒体）のコストに近づいているので、ディスク間バックアップは、従来のテープストレージの費用対効果が大きい代替えとなっている。従来のテープドライブは、直接バックアップサーバに接続するので他のバックアップサーバを共有することができない。このことにより、テープドライブの数が多くあるバックアップサーバでは使用されないままで、一方では他のバックアップサーバは十分なテープドライブと接続していないために帯域幅に制限があるという、利用の問題が発生する。この装置では、複数の共有資源を各ファイルサーバに生成でき、かつこれらのファイルサーバを全バックアップサーバで利用できるので、これらのバックアップサーバそれぞれが、バックアップ速度を上げるために、データを分割して複数のファイルサーバ共有資源に渡ってバックアップして、バックアップを平行して動作させることにより、１つ以上のファイルサーバに渡って１つ以上の共有資源を選択して用いることができる。

また、各ファイルサーバの共有資源を構成して、階層型ストレージ管理を用いて動作するようにできるので、新しいバックアップデータバックアップサーバから共有資源に書き込む際に、より古いバックアップファイルを自動的に同等のスタブファイルと置き換えて、ファイルサーバのストレージの消費量を最小限にすることができる。バックアップアプリケーションにとっては、ファイルサーバの共有資源を、バックアップアプリケーションは容量が不足しているので実行できない磁気テープを使うテープドライブとして見なすものである。

図４で述べたように、独特な保護方法の選択肢により、ファイルサーバの共有資源のキャッシングレベルを低いレベルに設定できるので、入力バックアップデータ用にそのファイルサーバの容量を最大化することができる。ローカルリポジトリおよびリモートリポジトリは、従来の複製した磁気テープおよびオフサイトストレージの置換したものとして動作する。

本発明の実施の形態を用いてバックアップと復元とを実行する他の利点は、次のものを含む：
・より速いデータの復元−復元するデータを、磁気テープの集まりではなく高速ネットワーク化ディスクから入手可能なので、復元が数秒以内で行われる。テープは、物理的に探し出し、テープドライブにロードして、データがあるテープの適切な位置を検索しなければならない。これには、１テープ当たり数十分から数時間かかってしまう。

・テープの紛失や間違った場所に置くことがない。

・各インクリメンタルバックアップにディスクの速度でアクセス可能なので、全バックアップの数がより少なくなる。現在の標準テープバックアップモデルを設定して、週末毎に全バックアップを実行し、インクリメンタルバックアップを毎日実行する。このバックアップの標準スケジュールは、データの全復元およびインクリメンタル復元を行うのに必要なテープの数を減らすように設計されたものである。本発明では、媒体を探し出し、駆動装置にロードし、データを検索する時間が数十分から数時間かかるものを、一般に１秒以下、例えば、ミリ秒に短縮するので、より少ない回数で全バックアップを実行することになる。これは、数十から数百回のインクリメンタルバックアップアクセスを、従来のテープドライブによる遅いロード検索ではなく、ディスク速度やネットワーク速度で実行できるからである。また、より少ない回数でバックアップを実行するというこのモデルにより、ストレージの消費量を飛躍的に減らすことができるのは、各全バックアップが、一般的な企業のストレージ環境では数十から数百のテープを消費してしまうからである。

・同じデータを連続するテープに格納する場合に比べて、旧式のバックアップファイルをより効率的にディスクベースのリポジトリから削除できる。テープを用いると、１つの媒体からスペースを回収することができない。磁気テープの容量は、そのテープの全データがもう使われてないと見なされた場合のみ、再使用することができる。

・１つのコピーをオフサイトストレージ施設に送信し、その他のコピーをローカルデータセンターに残しておくので、テープコピーに対応する管理を不要にする。

・サードパーティのストレージ施設での毎月のテープストレージのコストを不要にする。リポジトリを企業のデータセンター内に配置してこれらのデータセンターそれぞれを、他のデータセンターのオフサイトストレージのリポジトリとして動作させることができる。

・リポジトリにより、継続してそれらのファイル内容をチェックして修正する。リポジトリがファイルの破損を発見した場合は、破損したファイルを別のリポジトリから検証済の複製と置換する。従来、テープの品質を監視することは、時間がかかるプロセスで、ほとんど実行されることはない。

・テープ媒体およびテープドライブが旧式化するという問題を減らす。今日書き込んだテープ媒体は、５〜１０年後の駆動装置では読み出せない可能性があるので、長期保管用にテープを選択することは不適切なことである。本発明により、時間の経過と共に互換性が後退してしまうネットワーク化技術を強化する。１０Ｍｂ／秒イーサネット（登録商標）ネットワークインターフェースカード（ＮＩＣ）は、１００Ｍｂ／秒および１Ｇｂ／秒のイーサネット（登録商標）ＮＩＣとスイッチとを内蔵している。これは、旧式化を取り除く技術ポイントである。内部からリポジトリノードおよびファイルサーバへは、ディスクドライブインターフェースに多くの変更があるが、これらの変更が、外部の標準イーサネット（登録商標）ネットワーク接続に影響することはない。

・書き込むバックアップテープがないと、テープドライブに送られたバックアップが損傷してしまう。本発明を用いれば、１つ以上の共有ファイルサーバを共有テープドライブとして用いることができ、バックアップを容量がさらにあるファイルサーバの共有資源に確実に割り当てることができる。

・ディスクベースの復元は、特に、データ複数のテープから検索しなければならない時には、磁気テープベースの復元より何倍も速い。

・サービスおよび取得管理を大幅に低減する−テープドライブ及びテープライブラリの修復がなく、テープドライブ清掃スケジュールがなく、新しいテープを継続して購入する必要がなく、一意の番号が付いたバーコードやテープクリーナカートリッジを指定し、購入し、配置する必要がない。

図１３および図１４は、ローカルリポジトリとリモートリポジトリとを用いるクライアントが生成したデータファイルを保護するのに用いる各部を示す。図１３は、クライアントファイルをローカルリポジトリに保護することに対応する本発明の装置およびソフトウェア部の一実施の形態を示す。この装置は、ファイルサーバと１つのローカルリポジトリノード２８とを含む。クライアントがクライアントＩＰベースの（インターネットプロトコル）ネットワーク２９を介してファイルサーバにアクセスして、ＮＦＳ、ＣＩＦＳまたはＦＴＰプロトコルを用いてファイルサーバと通信する。全ファイルサーバと全リポジトリノードとを、内部ＩＰベースの（インターネットプロトコル）ネットワーク３０で相互接続する。現在のクライアントファイルは、ファイルサーバのファイルシステム３２に存在する。

一実施の形態では、フィルタ駆動装置３１がクライアントファイル要求により起動した全入力／出力動作を受信する。この最新のスナップショットが発生したので、ファイルサーバソフトウェアが変更または生成した全ファイルのリストを保持する。スナップショットの間隔は、保護方法のバックアップ頻度１４に基づいて、１５分から２４時間の範囲に設定することができる。バックアップ頻度のスケジュールについては、ミラーサービス３３が共有資源内の変更した全ファイルを用意して、その共有資源の保護方法で指定したリポジトリ１６（図４に図示）に格納する。

保護方法を、複数のリポジトリに渡って格納して複製し、保護方法キャッシュ３４の各ファイルサーバ内にキャッシュして、定期的に更新する。例えば、共有資源の保護方法がそのバックアップ頻度を１時間に設定していると、次の時間への移行で、ローカルリポジトリ２８への最新のバックアップであるため、ミラーサービス３３が変更した全ファイルのバックアップを開始する。

新しいファイルは全て、ローカルリポジトリの任意のリポジトリノードを用いてファイルの複製を保持することができる。変更したファイルについては、ミラーサービスが既存のファイルの新しいバージョンをそのファイルの以前のバージョンとして同じリポジトリノードに格納する。

ミラーサービスは、ロケーションキャッシュ３６を検索して、既存のファイルの更新したバージョンを受信するかどうか決定する。ファイルサーバがファイルを特定のリポジトリノードに書き込む場合には、このロケーションキャッシュをロケーションマネージャ３５で定期的に更新する。一旦ロケーションマネージャが共有資源の各ファイルの全宛先リポジトリノードを特定して、更新または生成したファイルの最新の集まりとしたならば、ファイルサーバは、ファイルサーバＡＰＩ３７とリポジトリノードＡＰＩ３８とを介して各ローカルリポジトリと通信する。

各リポジトリノードのデータムーバ３９は、ファイルサーバからそのリポジトリノードへのファイルの複製を管理する。ファイルサーバファイル転送部４０が、ファイルサーバファイルシステムから各リポジトリノードのファイル転送４１部へファイルを転送する。一旦ファイルを複製してリポジトリノード内の特定のディスクドライブに複製したならば、そのロケーションマネージャ４２がそのロケーションキャッシュ４３をリポジトリノードロケーション情報と共に更新する。

既存のファイルのバージョンを変更したリポジトリノードに到着した全ファイルについて、共有資源の保護方法４４のバージョン管理設定を検討して、新しいバージョンを圧縮するか、より古いバージョンを保持するかどうか決定する。バージョンサービス４５は、方法ベースの全ての圧縮解凍を管理し、”１つのバージョンのみを保持する”という共有資源の保護方法の選択肢に基づいて、バージョンを除外することを行う。

説明のこの時点では、クライアントデータはローカルリポジトリに複製しただけである。図１０は、データを１つ以上のリモートリポジトリに保護して、クライアントデータをサイト災害から完全に保護するプロセスを実行する各部の一実施の形態を示す。図１４は、図１３で説明した動作から、データの最初の複製を保持するローカルリポジトリノード４６を示す。図１０はまた、リモートリポジトリノード４７を示す。これらは、大都市圏または広域ネットワーク４８全域で互いに接続している。一実施の形態では、ローカルリポジトリとリモートリポジトリとの間で送信する全データを、仮想私設ネットワーク（ＶＰＮ）４９の暗号化で確保することもできる。ローカルリポジトリノードの複製サービス５０は、最新のファイルサーババックアップの一部として生成したばかりの全ファイルに対する保護方法５１の検討を行う。各リポジトリノードは、他のリポジトリノードの対等物として動作する。保護方法に基づいて、各リポジトリノードが、リポジトリノードＡＰＩ５２、５３、データムーバ５４、ファイル転送部５５、５６を用いて、全リポジトリノード間でのファイルの移動を管理する。一旦データをリモートリポジトリに複製したならば、各リポジトリノードのロケーションマネージャ５７がロケーションキャッシュ５８を更新して、そのリポジトリノード内のどこにファイルを保持しているか追跡する。リモートリポジトリノードのバージョンサービス５９が、ファイルバージョンの圧縮と保護方法に基づく圧縮とを管理する。

分散型ストレージ兼保護装置を監視して制御するよう説明してきたユーザインターフェースを、図１３および図１４に示すように、２つの基本ソフトウェア構成要素を用いて実行する。各ファイルサーバおよび各リポジトリノードは、ノードマネージャ７０を含む。また各リポジトリ内には、ＬＤＡＰディレクトリ７１の動作インスタンスを保持する、指定された最新のマスタリポジトリノードが存在する。

一実施の形態では、ノードマネージャ７０は次のことを行う：
・例えば、ファイルサーバまたはこれを実行中のリポジトリのロケーションキャッシュ等のサブ構成要素から、アセット、状態、容量、性能データを収集する。

・その収集したデータをローカルＬＤＡＰリポジトリ７１に送信して、データを永続的にリポジトリノード内に格納する。

・リポジトリノードアプリケーションプログラムインターフェース（ＡＰＩ）およびウェブベースのユーザインターフェースを介して、ＬＤＡＰ情報をストレージアドミニストレータに提示する。

・コマンドラインインターフェースにより、カスタマがプログラムスクリプトを開発して分散型ストレージ装置の情報を取得でき、かつこの装置を構成して制御できる。

・ＳＮＭＰおよび電子メールにより、構成要素故障あるいはネットワーク故障または容量が少なくなったこと等の多くのイベントにについて、ストレージアドミニストレータに通知する。

リポジトリノード内の各ノードマネージャが、リポジトリ内で果たす役割について交渉する。各リポジトリは、フォルトトーラレント型に設計されている。リポジトリノードは、マスタノードマネージャとして動作でき、複製ノードマネージャまたはドローンノードマネージャがこのフォルトトーラレンスをサポートする。マスタノードマネージャが、そのリポジトリのＬＤＡＰディレクトリを管理する。マスタノードマネージャは、その他のリポジトリノードのいずれかがいつ利用できなくなったかわかるようになっている。マスタノードマネージャが、定期的にそのリポジトリ内の他のリポジトリノードから統計を収集する。複製ノードマネージャが別のリポジトリノードを実行して、マスタノードマネージャを監視する。

図１５は、リポジトリノードのノードマネージャの状態図を示す。全リポジトリノードは、ブートストラップした状態で起動する。一実施の形態では、初期化１の間に、英数字で最下位のＩＰアドレスを持つローカルサブネット内のリポジトリノードを選択する選択プロセスにより、マスタを選択する。複製は次に低いＩＰで、他の全てのシステムはドローンである。

また、図１５では、複製からマスタへ移行、ドローンから複製へ移行させて、故障状態から復旧する。マスタが破損していると検出された場合は、複製移行２からマスタへ行く。複製が破損していると検出された場合は、次に低いＩＰアドレスを有するドローン移行３から複製へ行く。

最後に、図１５では、マスタおよび複製からドローンへ移行させることにより、リポジトリ内でマスタと複製とをコピーすることを防止する。ネットワーク故障のため残りのリポジトリノードからマスタを分離する場合には、新しいマスタと複製とを、上述のフェイルオーバ移行により選択する。古いマスタ（または複製）がネットワークに戻る場合には、新しいマスタ（または複製）を選択したので、移行４（５）でドローン状態に移行する。

分散型ＬＤＡＰデータベース内に保持したデータをフォルトトーラレンスにするため、次の２つの機構をデータ複製に用いる。リポジトリ内複製およびリポジトリ間伝搬である。

・リポジトリ内複製により、複製リポジトリノードのローカルリポジトリ内のデータベースのバックアップが確実に存在することになる。これにより、マスタ復旧ノード故障から複製を直ちに復元することができる。一実施の形態では、いつ変更があっても、データベースのファイルを、例えばＦＴＰを介して複製に送信する。複製が発見できないのでデータを複製する場合は、ローカルグリッドに新しい複製を選択したことを通知するメッセージを発行する。次の書込の際に、更新したファイルを複製する。ＦＴＰが失敗した場合は、エラーを記録する。

・リポジトリ間伝搬により、グリッドの任意の場所からのグリッド構成要素が、ローカルデータベースを在庫表、構成、状態情報のソースとして利用できるように、在庫表、構成、状態データの変更が確実にリモートマスタに伝えられる。各リポジトリからのデータを各リモートリポジトリに伝える。いずれかの伝搬の試みが失敗した場合は、エラーを記録する。２４時間毎に、各リポジトリはその最新情報を全リモートリポジトリに再送信して、失敗した伝搬を修復する。

リポジトリが失われたことに関わる災害の際には、リポジトリのディレクトリをリモートリポジトリに存在する読出専用コピーから復元することができる。

従って、本発明は、従来の分離型プライマリディスクストレージシステム兼磁気テープシステムと置換できるように設計された代替え物として、確実で、共用可能な、スケーラブルでディスクベースの、分散型データストレージ兼データ保護システムを提供することに関する。

本発明の一実施の形態は、物理的に２つ以上のデータセンターに渡って配置される統合データストレージ兼データ保護システムを提供する。各データセンター内での装置の配置は、１つ以上のファイルサーバと１つ以上のリポジトリとを含む。ファイルサーバは、ＮＦＳ、ＣＩＦＳまたはＦＴＰプロトコルを介して、プライマリディスク記憶容量をＩＰネットワーク化クライアントに供給する。各リポジトリは、ディスク記憶容量の仮想化プールである：
・変更または新しいファイルのバージョンを格納し、保持することにより、磁気テープバックアップシステムを置換したものとして動作する。

・１つ以上のオフサイトリポジトリに対するファイルサーバにとってローカルであるリポジトリ内に格納した全データを複製することにより、オフサイト媒体ストレージシステムおよびオフサイト災害復旧システムを置換したものとして動作する。

・リポジトリ内のデータを混合可能にして、リポジトリ容量の利用を向上させる論理的に確実なストレージシステムとして動作する。

・他のデータセットと混合したデータがないように構成した特定のリポジトリを有する物理的に確実なストレージシステムとして動作する。

本発明の一実施の形態は、２つのレベルのストレージシステム装置を提供する。これは、第１のレベルでプライマリデータストレージをクライアントおよびアプリケーションに供給し、第２のレベルでデータ保護用のストレージを供給する。

プライマリストレージのレベルは、ファイルサーバの集まりから構成される。これらから、ＮＦＳおよびＣＩＦＳアクセス可能なファイルサービスをクライアントおよびアプリケーションに供給する。これらのファイルサーバは、従来のＮＡＳサーバと違った、多くの特徴を有する：
・ＨＳＭを用いて、利用可能な容量を越えて定期的に実行するファイルシステムに答えることに対応する管理上の問題を取り除く。また、ＨＳＭにより確実に、最短時間アクセスデータを速やかにアクセス可能にして、生成した全データを、何十年も前のデータであっても、昨日生成したデータと同じようにアクセスできるようにする。

・テープドライブを置換したものとして動作できる。これらのファイルサーバの共有資源にＨＳＭ方法を設定して、データをより多く書き込めるスペースを常に確保することができる。これらのファイルサーバはまた、復元動作を加速するために、最新のバックアップを保持する。

・ファイルサーバは、テープドライブのように動作してサーバをバックアップすることができる。標準ＩＰネットワーク上に存在して複数のバックアップサーバが同じファイルサーバまたは複数のファイルサーバにアクセスできるようにする点で、より融通性がある。

・各ファイルサーバを追加するにつれて、これを分散型セットのデータ保護リポジトリに接続する。ファイルサーバが保護方法を含むことにより、これらのリポジトリによってその全データをどのように保護するか定義することができるようになる。

・これらのファイルサーバをＳＡＮに接続して、最短時間アクセスデータが高速ＳＡＮディスクに存在できるようにして、最長時間未使用データをトランスペアレントに、もっと価格の安いリポジトリストレージに移動できるようにする。古さやアクセスパターンにかかわらず、全データを継続して速やかにアクセスできるようにする。

データ保護レベルのストレージは、仮想リポジトリの集まりから構成される。これらのリポジトリは、２つ以上のリポジトリノードから成る。これらのノードは、基本的にＣＰＵ、メモリ、ＩＰネットワークを持ち、約１テラバイトのディスクデータストレージを持つコンピュータシステムである。特定のソフトウェアがこれらのリポジトリノードそれぞれを実行することにより、内部データ管理機能を実行すると共に、他のリポジトリノードを内蔵して長期に渡ってデータを保持することができる。リポジトリは、複数のデータセンターに渡って配置されるように設計されている。各リポジトリの容量を、第１のレベルの各ファイルサーバにより強化することができる。

データストレージ兼データ保護システム全体の一般的な配置では、２つ以上のデータセンターを有し、それぞれ複数のファイルサーバと１つ以上のリポジトリとを持つこともできる。各ローカルファイルサーバは、少なくとも１つのローカルリポジトリと１つのリモートリポジトリとにより保護される機能を有する。

ファイルサーバ上の各ＮＡＳ共有資源については、一意の保護方法が定義される。この保護方法により、その共有資源のデータを２つ以上のリポジトリの間でどのように保護するかを定義する。

複数のロケーションに渡って分散しているリポジトリにより、次のデータ保護の特徴をこの２つのレベルのストレージシステムに備える：
・最長時間未使用のファイルサーバのデータを、ファイルサーバからローカルリモートリポジトリにＨＳＭ機能の一部として移動する。ファイルサーバのプライマリストレージシステムをＳＡＮに接続している場合は、ＨＳＭ機能が階層化ストレージを供給して、最長時間未使用データを、コストが高いＳＡＮストレージのボリュームからコストがもっと低いリポジトリストレージに自動的に移動する。

・版数管理および複製技術を実行することによりバックアップおよびサイト災害復旧を完了する。

・確実にデータ保護リソースを共有する。リポジトリの容量を、複数のファイルサーバの間で確実に共有できる。データをリポジトリに配置したファイルサーバは、それが配置したファイルのみにアクセスすることができる。また、１サイト当たりに複数のリポジトリを配置することにより、アプリケーションに、データを同じ物理ストレージリソース上の他のデータと混同させないようにすることもできる。

・データ保護リソースの容量をより効果的に利用する。各サイトに配置したテープドライブや媒体のようなデータ保護リソースのアイランドを持つ代わりに、そのリポジトリにアクセス権がある全ファイルサーバが共有しているので、各リポジトリの容量の利用を最適化する。

本発明は、そのウェブベースの管理アプリケーションを用いる広範なリポートおよび制御を含む。次のものが備えられている：
・全アセットとそれらの最新の動作状態に関する全体的な見方。

・ファイルサーバのストレージリソースの確実なローカル管理。

・配賦レベルの記憶容量リポート。プライマリストレージ消費と共に、そのプライマリストレージをローカルでかつリモートで保護するのに消費した全容量を含む。この種類のリポートは、今日の断片化し、分離したデータストレージ兼データ保護ツールやシステムでは提供していない。

・従来のデータストレージシステムは、集中管理に基づいてストレージシステムの他の全構成要素を管理する。本発明は、１つの静止型マスタ管理ノードに基づくものではない。１リポジトリ当たり１つのマスタ管理ノードを選択して、マスタ管理ノードが故障した場合は、別のマスタ管理ノードを選択する。

図１は、３つのデータセンターに渡る本発明の一実施の形態の配置を示す図である。 図２は、保護方法の一実施の形態により、どのようにファイルサーバ共有資源と対応するリポジトリとの間の関係を生成するか示す。 図３は、対応するリポジトリノードを有する、例えば図１に示す３つのリポジトリを示す図である。 図４は、図２の保護方法のユーザインターフェースに関する一実施の形態のスクリーンショットを示す。 図５は、図１に示すシステム等のデータ保護システム管理するウェブベースのアプリケーションのユーザインターフェースに関する一実施の形態を示す。 図６は、図５のユーザインターフェースに対応する共有資源消費量リポートの一実施の形態を示す。このリポートは、共有資源の容量の消費量に基づいて、ストレージリソースの利用を個別の部署に定期的に配賦する手段としてＣＩＯに有益である。 図７は、図５のユーザインターフェースに対応する１リポジトリリポート当たりの１共有資源当たりの容量に関する一実施の形態を示す。このリポートは、特定のリポジトリの記憶容量を一番消費する記憶容量の共有資源を特定するために、ストレージアドミニストレータが最も良く用いるものである。 図８は、図５のユーザインターフェースに対応する１リポジトリリポート当たりの消費容量に関する一実施の形態を示す。このリポートは、リポジトリをさらに購入する必要があることを通知するために、各リポジトリがどのように消費されたか決定するのにストレージアドミニストレータが使用するものである。 図９は、複数のファイルサーバが複数のリポジトリを共有して、データをローカルでもリモートでも保護しながら、ＮＡＳ機能をクライアントに提供する構成に関する一実施の形態を示す。 図１０は、より小さな遠方のオフィスが多くある集中ＩＴインフラを有する企業のための、本発明の構成に関する一実施の形態を示す。 図１１は、カスタマの既存のＳＡＮを用いて階層化ストレージサービスを提供する本発明の構成に関する一実施の形態を示す。 図１２は、従来のバックアップサーバおよびソフトウェアを用いるテープドライブ／テープ媒体を置換したものとしての本発明の構成に関する一実施の形態を示す。 図１３は、新しいクライアントデータをローカルリポジトリノードに保護するためのシステムの一実施の形態を示す。 図１４は、リポジトリ間でデータを複製するシステムの一実施の形態を示す。 図１５は、図３、図１３、図１４に示すリポジトリ内で、リポジトリノードがノードマネージャとして行う状態変化の一実施の形態を示す。

Claims (11)

1. ファイルサーバ上のファイルを保護するためのデータ保護システムであって、以下：
   ネットワークを介してファイルサーバと通信するプライマリリポジトリであって、以下：
   データを格納するように機能するプライマリリポジトリノードと、
   プライマリリポジトリノードおよびネットワークと通信し、ファイルサーバと通信するように機能するプライマリリポジトリノードＡＰＩと、
   ネットワークおよびプライマリリポジトリノードと通信し、ファイルサーバからファイルを受信するように構成されているプライマリリポジトリファイル転送部と、
   プライマリリポジトリノードＡＰＩと通信し、ファイルサーバからプライマリリポジトリノードへのファイルの複製を監視するように機能するデータムーバと、
   データムーバと通信し、ファイルロケーションデータを格納するように機能するロケーション構成要素と、
   プライマリリポジトリノードの保存状態を保持するように機能するディレクトリと、
   ロケーション構成要素およびディレクトリサービスと通信し、プライマリリポジトリノードの記憶容量と性能とを管理するように機能するノードマネージャ
   とを有するプライマリリポジトリ、
   を備えるシステム。
2. システムがさらに以下：
   ファイルサーバであって、以下：
   クライアントファイル要求が起動する入力／出力動作を受信して、以前のバックアップから、変更し、生成したファイルのリストを保持するように機能するフィルタ駆動装置と、
   フィルタ駆動装置と通信し、クライアントファイルを格納するように機能するファイルシステムと、
   １セットのファイルに対応する保護方法を格納するように機能する方法キャッシュと、
   フィルタ駆動装置および方法キャッシュと通信するミラーサービスであって、変更し、生成したファイルを共有資源内に用意して、１セットのファイルに対応する保護方法で指定したプライマリリポジトリノードに書き込めるように機能するミラーサービスと、
   ミラーサービスと通信し、どのリポジトリが既存のファイルの更新したバージョンを受信するか表示するように機能するロケーションキャッシュと、
   ロケーションキャッシュに接続して、システムが新しいファイルを特定のリポジトリノードに書き込む際に、ロケーションキャッシュを更新するように機能するロケーションマネージャとを有する、ファイルサーバ
   を備える、請求項１に記載のデータ保護システム。
3. ミラーサービスが、既存のファイルの新しいバージョンをファイルの以前のバージョンを書き込んだリポジトリ送信する、請求項２に記載のシステム。
4. システムがさらに以下：
   ミラーサービスに接続し、リポジトリと通信するように機能するファイルサーバＡＰＩと、
   ファイルシステムと通信し、ファイルをファイルシステムから少なくとも１つのリポジトリに転送するように機能するファイルサーバファイル転送部
   とを備える、請求項２に記載のシステム。
5. プライマリリポジトリがさらに以下：
   データムーバと通信し、既存のファイルの新しいバージョンを圧縮するかどうか、既存のファイルのより古いバージョンを保持するかどうか決定するように機能する保護方法構成要素
   を備える、請求項４に記載のシステム。
6. システムがさらに以下：
   ネットワークを介してプライマリリポジトリと通信するリモートリポジトリであって、以下：
   データを格納するように機能するリモートリポジトリノードと、
   リモートリポジトリノードとネットワークと通信するように構成されているリモートリポジトリノードＡＰＩと、
   プライマリリポジトリファイル転送部およびリモートリポジトリノードと通信し、プライマリリポジトリファイル転送部からファイルを受信するように構成されているリモートリポジトリファイル転送部と、
   リモートリポジトリＡＰＩと通信し、プライマリリポジトリノードからリモートリポジトリノードへのファイルの複製を監視するように構成されているデータムーバと、
   データムーバと通信し、ファイルロケーションデータを格納するように機能するロケーション構成要素と、
   リモートリポジトリノードの保存状態を保持するように機能するディレクトリサービスと、
   ロケーション構成要素およびディレクトリサービスと通信し、プライマリリポジトリノードの記憶容量と性能とを管理するように機能するノードマネージャ
   を有する、リモートリポジトリ
   を備える、請求項５に記載のシステム。
7. 保護キャッシュが、どのリポジトリを用いてどの程度頻繁にデータ保護を行い、各リポジトリ内にいくつ複製を保持し、共有資源データに対する変更をいくつ保持するか機能する、請求項２に記載のシステム。
8. 対応するノードマネージャを用いて、複数のノードを有するリポジトリ内のノードマネージャを管理する方法であって、以下：
   ブートストラップした状態でノードマネージャを起動する工程、
   指定した基準により、マスタノードマネージャおよび複製ノードマネージャを選択する工程、
   残りの全ノードマネージャをドローン状態に設定する工程、ならびに
   マスタノードマネージャおよび複製ノードマネージャのうちの少なくとも１つが故障した場合は、指定した基準により、ドローンノードマネージャから代わりのノードマネージャを選択する工程
   を包含する、方法。
9. 指定した基準により、マスタノードマネージャおよび複製ノードマネージャを選択することが以下：
   最下位ＩＰアドレスを有するリポジトリノードを決定して、そのリポジトリノードに対応するノードマネージャをマスタノードマネージャとして選択する工程、ならびに
   次に低いＩＰアドレスを有するリポジトリノードを決定して、そのリポジトリノードに対応するノードマネージャを複製ノードマネージャとして選択する工程
   を包含する、請求項８に記載の方法。
10. マスタノードマネージャが故障した場合は、この方法により、マスタノードマネージャを複製ノードマネージャと置換する請求項８に記載の方法。
11. 複製ノードマネージャが故障した場合は、次に低いＩＰアドレスを有するリポジトリノードを決定して、そのリポジトリノードに対応するノードマネージャを複製ノードマネージャとして選択することで、この方法により、複製ノードマネージャを置換する請求項８に記載の方法。

Images