JP4473694B2

JP4473694B2 - 長期データ保護システム及び方法

Info

Publication number: JP4473694B2
Application number: JP2004283018A
Authority: JP
Inventors: 雄一矢川
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-03-15
Filing date: 2004-09-29
Publication date: 2010-06-02
Anticipated expiration: 2024-09-29
Also published as: US20050203973A1; US7177995B2; US20070011501A1; JP2005267600A; US7100008B2

Description

本発明は一般にストレージ・システムに関連し、さらに詳しくはデータを高い信頼性で長期間保持するためのシステム及び方法に関する。

最近の事件でデータの長期保存の必要性が認識された。ビジネス及びデータのユーザは一般に長期間にわたってデータをアーカイブする必要がある。企業は長期データ保存に関心を示しており、これは政策による条例によるところが大きい。例えば、米国証券取引委員会（ＳＥＣ）は、証券取引法１９３４規則１７ａ−４で、取引所会員、ブローカー、ディーラーに対し、口座取引の記録を口座終了後６年間保存することを義務づけ、全ての通信たとえば顧客との電子メールの記録も６年以上の期間保存しておく必要がある。米国証券業者協会（ＮＡＳＤ）も規則３０１０条と３１１０条で同様の規制を行なっている。詳細については例えば非特許文献１を参照されたい。

長期データ保存が重要な産業の別の例はヘルスケア産業である。規則ではＨＩＰＡＡ（健康保険移動説明責任法）により患者の死後２年にわたり医療記録を保存するよう病院に義務づけている。詳細については非特許文献２を参照されたい。

長期データ保存には、バックアップの頻度、記憶媒体、データ保管室の場所等といった、幾つか重要な問題点がある。最も重要な問題点の一つが長い年月の保管後に正確にデータを復元し、長い時間が経過した後でももともと保存してあった通りに正確に同一のデータをユーザに提供することである。一般に、ユーザはデータ生成時に使用されていたよりもコストの低い記憶システムを使用してデータを保存（又はアーカイブ）している。低コストの記憶システムの例としてはテープ・ライブラリ、光ディスク・ライブラリ、ＡＴＡ方式ディスク・ストレージ・システムがある。これらのシステムを代表的な高性能高信頼性生成データ用ストレージ・システム、例えばＦＣ／ＳＣＳＩ方式ディスクを使用したＲＡＩＤシステムと比較する。アーカイブ・ストレージ・システムは低コストであるので、その信頼性も同様に生成データ用システムより低い。そのため長い期間の後にはデータ損失が発生する可能性がある。

長期データの信頼性及び再現性を向上させるための従来技術はチェックサムの使用である。各ファイルを「分析」してそのファイルに関連するチェックサムを決定する。例えば、ファイル内のデータの各バイト（又は数バイト）を加算してチェックサムと呼ばれる和を発生することができる。チェックサムをファイルと一緒に保存する。後にファイルを検証するには、チェックサムの計算をもう一度行ない保存しておいたチェックサムと照合して、ファイルが時間経過とともに改竄がなかったかを判定することができる。他の同様の技術も例えばハッシュ符号を使用している。これらの方法では、ファイルが改竄されたかどうかを検出できるものの、改竄をもとに戻すことはできない。

もう一つの従来技術はファイルの複製（replica）を１つ又はそれ以上作製しておきファイルとその複製を別々のストレージ・デバイスに保存することである。例えば、特許文献１では内容に基づいて格納位置の特定可能な情報のカプセル化、表現、及び転送の方法を開示している。理解されるように、ハッシュ値を生成してファイル記述子として使用し、ファイルは幾つかのストレージ資源に複製される。ハッシュ値を用いてこれらの複製へユニークにアクセスできる。複製（群）は別のストレージ・システム（群）に存在するので、ハッシュ値を用いることでオリジナルのファイルが改竄されたことを検出した場合でもファイルを復元することが可能である。しかし、この方法ではストレージ・システム上に余分な容量を必要とすると言う問題点がある。その結果、この解決方法のコストは比較的高価なものになる。

ＰＣＴ国際公開番号ＷＯ９９／３８０９３号ＳＥＣのウェブ・サイトhttp://www.sec.gov http://www.cms.hhs.gov/hipaa/

高信頼で長期のデータ保存の必要性が存在する。低コスト実装でこれを達成するのが望ましい。

本発明によれば、ストレージ・システム上に保存しようとする入力ファイルの１つ又はそれ以上のパーティションが識別される。当該入力区画各々について充分な個数の同一区画がストレージ・システム内に存在するかどうかの判定を行なう。１個又はそれ以上の複製を作製して同一区画の個数を必要なだけ増加させる。逆に、保存されているファイルの区画は、ファイルへアクセスするユーザ要求への応答として、又は保存ファイルの定期チェック中に、読み出すことができる。当該読み出した区画を検証することができる。改竄が検出された読み出し区画は検証済みの予備区画で置き換えることができる。

本発明の態様、利点及び新規な特徴は添付の図面との組み合わせで提示される本発明の以下の詳細な説明から明らかになろう。

図１は本発明の１つの態様による代表的実施例の一般化ブロック図を示す。図面ではファイル構造化したデータ・オブジェクトを操作するためのファイル・サーバ・アーキテクチャを示してあるが、本発明はその他のストレージ・アーキテクチャ、例えばストレージ・エリア・ネットワーク（ＳＡＮ）やオブジェクトベース・ストレージ・デバイス（ＯＳＤ）等で実現することができ、またファイルとして構成されたデータ以外のデータ・オブジェクトについて動作可能であること理解されるであろう。

図１の代表的実施例では、ファイル・サーバ・システム１が１台又はそれ以上のクライアント５０、５１にファイル・サービスを提供する。ファイル・サーバは、ストレージ・システムによってサポートされる１つまたはそれ以上のファイル・システムに格納されたファイルへアクセスするために、１つ又はそれ以上のストレージ・システム７０、７１、７２（及びサブシステム）とデータ通信するように構成することができる。状況によって、用語「ストレージ・システム」を使って個別のストレージ・システム７０、７１、７２を表わす、又は用語「ストレージ・システム」を使ってストレージ・システムの集合体を単一のストレージ・システム（又はストレージ・サブシステム）として表現するのが便利な場合もあろう。負荷バランシング用、冗長性と信頼性の向上のため、等に追加のファイル・サーバを提供できることは理解されよう。代表的には、ストレージ・システムは読み書き可能である。本発明の特定用途のためにはライトワンス型ストレージ媒体を使用するのが適しているかもしれないことは理解されよう。以下で説明するある種の動作はライトワンス型ストレージ媒体には便利でないことがあることも理解されよう。

クライアント５０、５１はファイル・サーバ・システム１と適切な通信リンク６上で通信する。例えば、通信リンクはＴＣＰ／ＩＰによる通信ネットワーク例えばローカル・エリア・ネットワーク（ＬＡＮ）又は広域ネットワーク（ＷＡＮ）上にある。ファイル・サーバ・システム１とストレージ・システム７０、７１、７２との間の通信は、使用するアーキテクチャに好適な通信リンク７上に提供され得る。例えば、ストレージ・システムがＳＡＮをベースとしているなら、ファイバ・チャンネル・プロトコル（ＦＣＰ）が適切である。ネットワーク接続ストレージ（ＮＡＳ）アーキテクチャを使用する場合にはＴＣＰ／ＩＰベースのプロトコルが適当である。別の例として、ファイル・サーバ・システム１とストレージ・システム７０、７１、７２を単一のシステムとして構成し、この場合通信リンク７はInfiniBand、ＰＣＩ、又は専用プロトコルとすることができる。説明の目的で、ファイル・サーバ・アーキテクチャを次の想定する。ファイル・サーバ・システム１とストレージ・システムとの間のインタフェースがファイル・インタフェースであって、ストレージ・システム７０、７１、７２がファイル単位でデータを格納するものとする。

ファイル書き込み動作を実行するクライアントは「エントリ・クライアント」と呼ばれる。エントリ・クライアント（例えばクライアント５０）はファイル・ライター機能５５を使用してファイル・サーバ・システム１と通信し書き込み動作を実行する。本発明の状況ではファイル内容の何らかの変更が「書き込み」動作であると見なし、これにはファイル作成、ファイルの更新、ファイル削除を含む。本発明の詳細な実施例では、あるファイルは「不変（fixity）」の属性（この属性のファイルは一旦書き込まれたら、何度も読み出されるが更新されない）で特徴付けることができる。このようなファイルは「参照情報」とも呼ばれる。

ファイル読み出し動作を実行するクライアントは「ビュー・クライアント」と呼ばれる。ビュー・クライアント（例えばクライアント５１）はファイル・リーダ機能５６を使用してファイル・サーバ・システム１と通信してファイルにアクセスし、内容を表示したり、又は何らかをクライアントに提示することができる。代表的には、どのクライアントもファイル・サーバ経由でファイルを書き込み読み出す能力を保有でき、つまり実行しようとするファイル操作によってエントリ・クライアント又はビュー・クライアントとなることができる。

ファイル・サーバ・システム１はファイル・サーバ・システムに代表的に見られるハードウェア・コンポーネントを含む。例えば、ファイル・サーバは計算又はその他の適当なデータ処理コンポーネント、適当なメモリ・コンポーネントを含み何らかの形の大容量ストレージ（例えばローカル・ハードディスク・ドライブ）を含むことが多いと理解される。ソフトウェア・コンポーネントはオペレーティング・システム（ＯＳ）とその他の支援プログラムを含み、コンピューティング・コンポーネントを制御することでクライアントと通信しまたストレージ・システム７０、７１、７２と通信するものと理解される。ある種のファイル・システム又はファイル・システム群はストレージ・システム上に定義され、ファイル・サーバにはファイル・システムへアクセスしてファイル・ストレージ・サービスを提供するための適当なハードウェア及びソフトウェアのコンポーネントを含んでいるものと理解される。

図１に示した実施例によれば、ファイル・サーバ・システム１はさらにファイル入力プログラム・コンポーネント１０も含む。図面に示してあるファイル入力プログラム・コンポーネントは本発明によるファイル書き込み動作を実行するソフトウェアの集合体を表わす。ファイル・サーバはファイル出力プログラム・コンポーネント２０を含む。図面に示してあるファイル出力プログラム・コンポーネントは本発明によるファイル・アクセス動作を実行するソフトウェアの集合体を表わす。ファイル・サーバはさらにメタデータ３０とパーティション識別情報４０を含み、これらは適当な大容量ストレージ・デバイス（例えばＲＡＩＤデバイス）上に格納することができる。後に明らかになるように、これらのテーブルは本発明の重要な態様に於けるコンポーネントである。したがってこれらのテーブルを他のストレージ・デバイスにバックアップするか又は他のスタンバイ・システムへ複製することが望ましい。例えば、テーブルの高信頼性ストレージはＲＡＩＤデバイスにこれらのテーブルを格納することで提供できる。メタデータ３０とパーティション識別情報４０はファイル入力プログラム及びファイル出力プログラムを含むソフトウェア・コンポーネントによってアクセス可能である。

ファイル入力プログラム・コンポーネント１０の一つの機能はクライアント５０と通信してファイル書き込み要求に対応するデータを構成するデータ・ストリームを受信することである。ファイル入力プログラムはストレージ・システムと通信してファイルを構成するデータを格納する。ファイル入力プログラム・コンポーネントによって実行される更なる処理については後述する。図１に示した本発明の詳細な実施例によれば、ファイル入力プログラムもメタデータ３０とパーティション識別情報４０を必要に応じて更新する。

ファイル入力プログラム・コンポーネント１０はファイル・パーティショニング・モジュール１１を含む。後述するように、このモジュールはファイルを構成するパーティション（入力パーティションと呼ばれる）を識別する。パーティション・ハッシュ化モジュール１２はハッシュ演算を実行する。パーティション同一性検査モジュール１３は同一パーティションを識別する。パーティション同一性検査モジュールは複製モジュール１４を含む。

ファイル出力プログラム・コンポーネント２０の一つの機能はビュー・クライアント５１と通信してストレージ・システムから要求されたファイルにアクセスしデータをビュー・クライアントに提供することである。後述するように、これにはメタデータ３０へのアクセスを含みパーティション識別情報４０へのアクセスを含むことがある。

ファイル出力プログラム・コンポーネント２０はファイル・パーティショニング・モジュール２１を含む。このモジュールは読み出そうとするファイルに対してファイル・パーティショニング・モジュール１１と同じ機能を実行する。読み出そうとするファイルで識別されたパーティションは「読み出しパーティション」と呼ばれる。パーティション認証モジュール２２は読み出そうとするファイルを構成する各々の読み出しパーティションを認証する。パーティション訂正モジュール２３は改竄された読み出しパーティションを訂正する。パーティション訂正モジュールはパーティション同一性検索モジュール２４を含む。

図２及び図３を参照して、図１に示してあるように本発明の詳細な実施例によるファイル書き込み動作の処理を説明する。前述したように、クライアント５０はファイル・サーバ・システム１へ要求を通信しファイル書き込み動作を実行させる。要求を処理する一環として、ファイルがストレージ・システムへ書き込まれる。本発明によれば、以下の追加動作がファイルに対して実行される。図３は図１のファイル入力プログラム・コンポーネント１０に於いて発生する処理を明示する高レベル・フローチャートである。

本発明によれば、ストレージ・システムへ書き込む（新規ファイルの場合には初回時、又は既存ファイルの変更の結果としてのいずれかで）ファイルは１つ又はそれ以上のパーティションに分割される。各々の構成パーティションに付いて、同一パーティションがストレージ・システムに存在するかしないかを確かめ、見つからない場合複製パーティションが作成される（複製）。各構成パーティションに付いてこれを反復し、ファイルの各パーティションのコピーがストレージ・システムのどこかに見つかるようにする。入力ファイルはパーティション・サイズより小さいことがあり、その場合ファイルは単一パーティションで構成されることが理解されよう。後述する別の実施例では、各ファイルはパーティションと見なすことができ、ここでファイルは単一パーティションを含むことができる。

つまり、本発明の詳細な実施例では、ファイルの構成パーティションは図３のステップ３００で識別される。図２はこのプロセスを模式的に示している。クライアント５０はファイル１００を提供する。パーティショニング・ステップ３００によって入力パーティション１０１〜１０５と呼ばれる複数のパーティションの識別が行なわれる。パーティションはファイルを構成するデータの一定サイズのブロックと定義することができる。つまり、ファイルのＮバイト（又はビット、又は何らかの便利な単位）ごとにあるパーティションを構成することになる。ファイルは何個かのパーティションへ論理的に分割され、各々がＮバイトを有する（「パーティション・サイズ」）。ファイルの最後のパーティションはパーティション・サイズより小さくなることがある。しかし、利便のため、これもパーティションと呼ぶことにする。

パーティション・サイズは所定のサイズとすることができる。その時々でパーティション・サイズを変更するシステム管理者を提供することが可能である。パーティション・サイズは、利用可能なストレージ容量等の要因に基づいて、定期的かつ自動的にプログラム的に変更することができる。パーティション・サイズはファイルの何らかの態様、例えばファイル形式、ファイル・サイズ、ファイルがどのストレージ・システム７０、７１、７２に存在するか、等によって決定してもよい。例えば、全てのビットマップ画像ファイルはパーティション・サイズ１Ｋビットとしてもよく、テキストファイルは５１２バイト・ブロックに分割することができる。

ループ３１０を実行してファイル１００の各入力パーティション１０１〜１０５を処理する。本発明によれば、各入力パーティションはその内容によって識別される。図示した詳細な実施例では、パーティションの内容はハッシュ符号とグループＩＤとを含むパーティションＩＤによってユニークに識別できる。ハッシュ符号についてここで説明し「グループＩＤ」の概念は後述する。ハッシュ符号（ハッシュ値）はステップ３２０で、入力パーティションの内容の幾らか又は全部をハッシュ関数に適用することで決定される。ハッシュ関数は一方向アルゴリズム、例えばＭＤ５、ＳＨＡ−１等とすることができ、一般的に、適切なものであればどのようなアルゴリズムでも良い。つまり、例えば、図２は入力パーティション１０１をハッシュして値「１５」を生じ、入力パーティション１０２をハッシュして値「１１」を生じ、入力パーティション１０３をハッシュして値「１３」を生じ、入力パーティション１０４をハッシュして値「２０」を生じ、入力パーティション１０５をハッシュして値「４０」を生じることを示している。ハッシュ符号の代わりに他の符号化アルゴリズムを使用できることは理解されよう。さらに、例えばテキストファイルとバイナリファイルとビットマップ・ファイル等、異なる内容には異なる符号化技術を使用するのが望ましい。

図３の処理に戻ると、処理中の入力パーティションに付いてハッシュ値を決めた後、ハッシュ値はステップ３３０でメタデータとしてファイル１００に関連付けられる。ここで一旦、図４を参照すると、メタデータ３０の代表例が図示してある。従来のファイル・システムは通常ファイルについてのメタデータを格納する。メタデータはファイルの属性、場所、その他ファイルに関する情報、すなわちファイルの内容から分離された情報を表わす。図４に示してあるメタデータ３０は本発明の実施例による、各ファイルの持つであろう情報の論理的表現であって、テーブル形式で表現してある。メタデータはファイルＩＤ７００、位置情報７１０、その他の情報７２０（例えばアクセス情報、ファイル・サイズ等）を含む。ファイルに関連付けられたメタデータは複数のハッシュ値を含む。ファイル内で識別されるパーティションごとにハッシュ値が存在する。例えば、図２に示したファイル１００はエントリ７５２として図４の論理表現で示されてあり、識別されたパーティションの各々にハッシュ値を有する。

前述したように、パーティショニング・ステップ３００では異なるサイズのパーティションを作成することができる。メタデータ３０はサイズ情報７４０を含むことができる。したがって、例えば、ファイル・エントリ７５１は５１２バイトのサイズで（又は何らかの便利な単位で）分割された。

引き続き図３である。次のステップでは処理中の入力パーティションと同一のパーティションがストレージ・システム内のどこかに存在するかを識別する。本発明の本実施例では、ここではストレージ・システム内の各ファイルを構成するパーティション各々を考慮し入力パーティションと同一のパーティションかどうかの判定を行なう。

一方のパーティションの内容が他方のパーティションの内容とビット毎に同一であれば２つのパーティションは「同一」である。一方のファイルからのパーティションにあるデータ（「パーティション・データ」と呼ぶ）は他方のファイルからのパーティション・データと同一であり得る。実際、同一ファイルからの２つ又はそれ以上の異なるパーティションが同一である（同じデータを有する）ことは可能で、例えば、ビットマップ・ファイルでは、広い白色領域（又は暗い領域）を含む画像の場合、長いゼロの列を有することがあるから、このようなファイルの２つ又はそれ以上のパーティションはゼロだけで構成されることがある。図１に示した詳細な実施例では、本発明のこの態様はパーティション識別情報４０へのアクセスを含む。

ここで図５を参照すると、パーティション識別情報４０の一例が図示してある。パーティション識別情報は同一パーティションとこれらのパーティションを含むファイルを全部識別する。第１に、パーティション識別子を考えてみる。これはパーティションの内容をユニークに識別する。前述したように、パーティション識別子はハッシュ符号（ステップ３１０）とグループＩＤとを含む。特定の実装仕様によっては、ハッシュ関数が各パーティションの内容をユニークに識別できる符号を保証しないことも起こりうる。例えば、パーティション・サイズが２５６バイトで、ハッシュ符号が８バイトの場合、ハッシュ符号の８バイトは２５６バイト・パーティションで可能な組み合わせ全部を表現するには不十分なことは明白である。結果として、互いに異なる内容を有する２つのパーティションが同じハッシュ値を得ることが可能である。同一のハッシュ値を持つこれらのパーティション間でさらに識別するため、「グループＩＤ」を使用することができる。つまり、後述するように、同一の内容を持つ（すなわち同一である）これらのパーティションは同一のハッシュ符号値と同一のグループＩＤ値によって識別される。グループＩＤをどのように決定するかは後述する。

図５に示してあるパーティション識別情報４０は便宜的にテーブル形式で論理的に表現してある。パーティション識別情報はストレージ・システムに格納された各ファイルの各パーティションに提供される。各パーティションにはパーティションＩＤが関連付けられ、これにはハッシュ値８００とグループＩＤ８１０が含まれる。各パーティションにはさらにファイルＩＤ８２０も関連付けられており、これでそのパーティションを含むファイルを識別する。このファイルＩＤは図４に示してあるファイルＩＤ７００に関連する。各パーティションにはさらにパーティション番号８３０も関連付けられている。パーティション番号は、そのファイルを含む他のパーティションに対するそのファイル内でのそのパーティションの位置を表わす序数である。つまり、例えば、パーティション・エントリ８５１はファイルＩＤ「１０００」によって識別されるファイルに属する。この特定のパーティションはハッシュ値が１３（かつグループＩＤが１）で、ファイルの２番目のパーティションである。エントリ８５４はパーティション情報への新規パーティションの追加を表わしており、これを以下で説明する。

図３で強調した処理ステップに戻ると、ループ３１０で処理される入力パーティションと同一のあるパーティションが存在するかどうかを識別するステップは、ステップ３４０で同一ハッシュ値をもつパーティション識別情報４０からエントリを取り出すステップを含む。したがって、図２に示したファイルの３番目のパーティション１０３が入力パーティションだと仮定する。このパーティションからはハッシュ値「１３」がハッシュされる。パーティション情報テーブルにアクセスして同一ハッシュ値をもつ他のパーティション（もしあれば）を識別する。この場合、参照番号８５１〜８５３で識別されるパーティションが候補パーティションで、これらが後続のステップで考慮される。

ループ３５０では、各候補パーティションは次の処理の対象になる：
・ステップ３６０：候補パーティションの内容にアクセスする。したがって、パーティション８５１については、「１０００」として識別されたファイルにアクセスすれば、ファイル「１０００」についてのメタデータ３０にアクセスすれば所在が特定できる。ファイル「１０００」の２番目のパーティションの内容も読み出せる。

・ステップ３７０：アクセスされた候補パーティションをハッシュする。つまりファイル「１０００」の２番目のパーティションがハッシュされる。

・ステップ３８０：処理中の入力パーティションのハッシュ値と候補のハッシュ値とを比較する。これらは同一になるはずである。しかし、異なっている場合には、候補パーティション（この場合ではファイル「１０００」の２番目のパーティション）が改竄されたと結論することができる。本発明のこの詳細な実施例では、このパーティションに対してこれ以上のことを行なわず、パーティションはスキップされて処理はループ３５０の先頭に進み次の候補パーティション（群）、この場合にはパーティション８５２と８５３の処理を行なう。これ以外に、パーティション識別情報４０に追加の情報を提供して、この候補パーティションが改竄されたものであるとの決定を表示できる。さらに別の実施例ではこの候補パーティションが後続の訂正ステップ用にマークされる。さらに別の実施例ではエラーを発見し次第訂正を行なうよう試みる。訂正ステップの一例は図７に関連して後述する。

・ステップ３９０：ステップ３８０でハッシュ値が一致した場合には識別テストを実施する。この詳細な実施例では、テストには、処理中の入力パーティションの内容とアクセスした候補パーティションとを比較して２つのパーティションがビット毎に同一であるかを判定する、すなわち同一パーティションであるかを判定するステップを含む。

・ステップ４００：候補パーティションと処理中の入力パーティションが同一のものであると判定されたら、パーティション識別情報４０を更新して（ステップ４１０）入力パーティションを含めるようにする。更新情報には入力パーティションのハッシュ値、一致する候補パーティションのグループＩＤ、入力パーティションが属するファイルのファイルＩＤ、入力パーティションの相対位置が含まれる。この場合、入力パーティションは同一であると判定されているので新規エントリ８５４をパーティション識別情報４０に追加する。ハッシュ値は「１３」でグループＩＤは一致した候補パーティションのそれ、すなわち「１」である。ファイルＩＤとパーティション番号も記録される。この場合、入力パーティションは「２０００」と識別されたファイルからのものでファイル内の３番目のパーティションである（図２参照）。図３の説明を続けると、処理はループ３１０の先頭へ進み、ここで入力ファイル１００の次の入力パーティションを処理する。

・ステップ４００：候補パーティションと処理中の入力パーティションが同一でない場合、処理はループ３５０の先頭へ戻って次の候補パーティションを処理する（この場合次のパーティションは参照番号８５２である）。

ループ３５０からの候補パーティションのどれも処理中の入力パーティションと同一ではなかった場合、処理はステップ４２０へ進む。この時点で、ストレージ・システム内のファイルのどれも入力パーティションと同一のパーティションを含まないと結論することができる。ステップ４２０で、１つ又はそれ以上のファイルが作成され、その各々が入力パーティションの内容を含む。このようなファイルは「複製（replicas）」又は「複製ファイル」と呼ばれる。複製ファイルは「ユーザ・ファイル」とは区別され、ユーザ・ファイルはクライアント５０、５１が作成するが、複製ファイルは本発明にしたがって内部的に作成される。同一パーティションがストレージ・システム内に格納された非複製ファイルの中に存在しない場合には、入力パーティションの複製を少なくとも一つ作成することで、入力パーティションの複製（すなわち同一の）パーティションがストレージ・システム内のどこかに存在することが保証される。実際には、信頼性のある長期保存をある程度のレベルで保証するため、１つ以上の複製を作成するのが恐らく望ましいと思われる。複製の実際の個数は所定の値としたり、システム管理者が決定したり、したがって、またその時々で変更したりでき、自動的にアルゴリズムにしたがって決定したり等が可能である。実際には、ストレージ・システム全体に複製を格納するのが恐らくは望ましいと思われる。つまり、例えば、図１に示した構成は複数ストレージ・システム７０、７１、７２を示している。入力パーティションを含むファイルがストレージ・システム７０に格納されている場合、例えば１つ又はそれ以上の複製をストレージ・システム７１、７２に格納して喪失又は改竄データの可能性を減少させるのが望ましいと言える。

この時点で、「パーティション」はファイル内でデータのブロックとして（パーティション・サイズと等しい）存在できることは特筆に値する。ファイルはユーザが作成したファイルだったり、又はユーザとの対話によって作成されたファイル（ユーザ関連ファイル）だったりすることがある。例えば、データベース・システムの構成ファイルはユーザによって直接作成されるものではないが、ユーザがアクセスするデータベースをサポートするために作成される。ファイルはユーザ関連ファイルに存在するパーティションの複製であり得る。つまり、パーティションを参照する、パーティションにアクセスする又は別の方法でパーティションを操作するといった概念は、まずファイルにアクセスし、次に注目するパーティションを含むデータを読み出すことを含む。これ以外に、パーティションを参照するのは単にメタデータ３０又はパーティション識別情報４０に含まれる情報を参照するだけかもしれない。

図３の説明を続けると、ステップ４３０で、複製を作成したときに新規のグループＩＤが作成される。この時点で処理中の入力パーティションはストレージ・システム内に格納されたどのファイルにも同一パーティションがないことが分かっているから（作成されたばかりの複製は除いて）、新規グループＩＤを作成して新規にユニークなパーティションをシステム内で識別する。入力パーティションのハッシュ値との組み合わせで、得られた新規パーティションＩＤは入力パーティションの内容をユニークに識別する。グループＩＤの割り当ては例えば、各ハッシュ値にカウンタを関連付けることによって実現することが可能である。各カウンタは初期化してゼロにすることができる。任意のハッシュ値について新規グループＩＤを必要とする場合、そのハッシュ値に対応するカウンタをインクリメントして新規ＩＤを発生させる。そのハッシュ値について次回に別の新規グループＩＤが必要になれば、そのハッシュ値に関連したカウンタをもう一度インクリメントして次のＩＤを発生させる。当然のことながら、他の何らかのＩＤ生成メカニズムを実装可能であることがこの説明から理解されよう。

ステップ４４０で、メタデータ３０を更新して新規作成した複製の各々を反映させる。同様に、パーティション識別情報４０を更新して処理中の入力パーティションを識別し、新規作成した複製の各々を識別する情報を含める。新規入力パーティションについて、ファイルに含まれる入力パーティションが処理されるまで、ループ３１０の先頭で処理を反復実行することが可能である。図２に於いて、ループ３１０は各パーティション１０１〜１０５ごとに１回づつ、計５回実行される。

前述のステップを図示するために図２を考える。図面にはパーティション１０２がシステム内に同一パーティションを持っていない状況が図示してある。結果として、ループ３５０の処理は入力パーティションのパーティションＩＤはまだ存在していないことから得られていない。この時点での入力パーティション１０２のパーティションＩＤは図２で（１１，ＮＵＬＬ）と表現してあるが、これは「１１」がパーティション１０２のハッシュ符号であり、ＮＵＬＬは入力パーティションが存在しないことを表わしている。ここで複製ステップ４２０を実行して１つ又はそれ以上の複製を作成する。新規グループＩＤをステップ４３０で作成する。パーティション１０２の場合、例えば、システム内の他のパーティションはハッシュ値「１１」にハッシュされていない。したがってグループＩＤの値は「１」とし、ハッシュ値「１１」を持つ最初のパーティションであることを示す。ステップ４４０で、メタデータ３０とパーティション識別情報４０を更新してパーティション１０２についてと１つ又はそれ以上の複製についての情報を含める。

図４Ａと図５Ａはメタデータ３０とパーティション識別情報４０に対して行なった更新を表わす。幾つか追加の点が特筆に値する。複製を識別するのに命名規則を採用することができる。図４Ａの実施例に示してあるように、このような規則の一つは特別なファイルＩＤの使用である。ここではパーティション１０２の複製は「Ｒ３００」として識別され、「Ｒ」はそのファイルがあるパーティションの複製であることを示す。本発明のこの詳細な実施例では、各複製は単一パーティションについてのパーティション・データを含む。本発明の別の実施例では、複製ファイルは１つ以上のパーティションを格納できるが、これは利便性の低い実施例であるかも知れないし、そうでないかも知れない。

ステップ４１０をもう一度参照して、開示した実施例の変形を説明する。処理しようとしている入力パーティションと同一の既存のパーティションが存在する場合にステップ４１０となる。パーティション識別情報を更新して入力パーティションに関連する情報を含める。さらに、パーティション識別情報を検索して同一パーティションが１つ又はそれ以上のユーザ・ファイルからのパーティションと、複製ファイルであるパーティションを含むかどうかを調べる。このような場合、同一パーティションが１つ又はそれ以上のユーザ・ファイルに存在するので、何らかの複製は冗長である。したがって複製によって消費されるストレージ空間を節約するため複製ファイルの１つ又はそれ以上を削除するのが望ましい。これは独立した処理で実行できることに注意する。

ステップ４１０のさらに別の態様は、パーティション識別情報から、ユーザ・ファイルに属するパーティションや複製であるパーティションを含めて、処理中の入力パーティションと一致する同一パーティションの個数を決定することである。一つの変形に於いて、同一パーティションの個数は何らかの所定の値に維持しておき、ステップ４１０で１つ又はそれ以上の複製を作成（又は削除）して同一パーティションの個数を一定の値に維持するようにできる。ストレージ・システムからファイルを削除する場合、削除されることになるファイルの各パーティションについて、１つ又はそれ以上の複製を作成するかどうかを決定するのが望ましい。ステップ４１０のさらに別の変形では、決定を別の処理で実行できることに注意する。一般に、各種図面で開示したステップは共有メモリ又はその他同様のデータ共有メカニズムを使用して必要に応じて情報を受渡しできるようにした多数の独立した処理へ適切に分割できることに注意する。

さらに別の変形に於いて、第１の所定のレベルと第２の所定のレベルで「バッファ領域」を定義することができる。つまり、任意のパーティションＩＤ（ハッシュ符号、グループＩＤ）の同一パーティションの個数が第１の所定のレベルを越えた場合、そのパーティションの複製は同一パーティションの個数が第２の所定レベル以下に納まるまで（又は全部の複製が削除されるまで、いずれか最初に発生する方）そのパーティションの複製を削除することができる。この操作はステップ４１０で実行できるが、ステップ４１０で実行しなければならないものではない。例えば、これは独立した処理で実行することができる。第１と第２の所定レベルは同一レベルでも又は異なったレベルでも良い。

複製作成について同様のバッファ領域を定義することができる。つまり、任意のパーティションＩＤの同一パーティションの個数が第３の所定レベル以下の場合には、充分な複製を作成可能であるから第４の所定レベル以上に同一パーティションの個数を増加する。第３と第４の所定レベルは同一レベルでも又は異なるレベルでも良い。

前述の実施例によれば、図１と図３に示した処理はファイルをストレージ・システムに格納するユーザ要求が発生した場合に開始される。図３の処理はストレージ・システムにすでに格納されているファイルに対して実行可能であることが理解されよう。つまり、図３の処理を実行するループが各ファイルについて提供可能である。

ここで図６と図７を参照して、図１に示した本発明の詳細な実施例によるファイル読み出し操作の処理を説明する。前述したように、ビュー・クライアント５１はファイル・サーバ・システム１への要求を通信してファイル読み出し操作を実行させる。要求を処理する一環として、ストレージ・システムからファイルがアクセスされてビュー・クライアントへ供給される。本発明によれば、以下の追加の動作をファイルに対して実行する。図７は図１に示したファイル出力プログラム２０で発生する処理を示す高レベル・フローチャートである。以下の説明からファイル出力プログラムを含むモジュールでどのステップが実行可能かは明らかであろう。

この詳細な説明に於いて、図７の処理は読み出し動作の状況で実行されることに注意する。しかし図７の処理が読み出し動作とは独立して開始可能であることが当業者には理解されよう。図７に示した活動は改竄ファイルを検出して検出された改竄を修復することに関係する。このような活動は読み出そうとしてユーザがファイルにアクセスすることによる以外でも開始できることが理解されよう。例えば、システム管理者はシステムにコマンドを発行して、アクティブな格納ファイル又はアーカイブしたファイルの保守動作の一環として、ストレージ・システムに格納されたファイルの検証と修復を行なうことができる。自動処理でチェックを定期的に行なうなどが可能である。

本発明によれば、ファイルの各構成パーティションがアクセスされる。各パーティションについて、そのパーティションが改竄されているかどうかの判定を行なう。あるパーティションが改竄されている場合、改竄されていない同一パーティションを見つけ出す試みが行なわれる。このような同一パーティションが見つかった場合改竄されたパーティションのファイルにあるデータを改竄されていない同一パーティションからのデータで置き換える。ファイルを構成する各パーティションに対してこれを反復実行する。

この処理の詳細な実施例について図７を参照すると、ステップ５００で、ファイルを含む各パーティションにアクセスする。図６はファイル２００についてのこの処理を模式的に示している。パーティショニング・ステップ５００では、「読み出しパーティション」と呼ばれる複数の構成パーティション２０１〜２０５を作成する。各読み出しパーティションはループ５１０で以下のように処理される。

ステップ５２０に於いて、ファイルが書き込まれたときにそのパーティションに対して使用したハッシュ・アルゴリズムを第１の読み出しパーティション２０１に適用してハッシュ値を作成する。例えば、図６の例は、読み出しパーティション２０１からハッシュ値（２１１）の「１５」がハッシュされる。読み出しパーティション２０２はハッシュ値（２１２）の「１１」を持ち、読み出しパーティション２０３はハッシュ値（２１３）として「１４」を持ち、以下同様である。

ステップ５２０で作成したハッシュ値を（ステップ５３０で）ファイルを書き込んだ際に作成された読み出しパーティションの値と比較する。この値はメタデータ３０から得られる。つまり、あるファイルのｉ番目の読み出しパーティションはこれに対応するハッシュ値をメタデータに持っている、言い換えればそのファイルについてメタデータのｉ番目の値である。計算された値が格納されている値と一致すれば、処理中の読み出しパーティションは改竄されておらず、有効であると仮定することができる。ループ５１０で処理を継続して次の読み出しパーティション０２を処理する。

計算された値がメタデータ３０に格納されている値と一致しない場合には、ステップ５４０で同一パーティションの検索を実行する。これにはパーティション識別情報に問い合わせて処理中の読み出しパーティションと同一なパーティションのリスト（「同一パーティション」）を識別するステップを含む。つまり、図６を参照すると、改竄されたパーティションの一例が読み出しパーティション２０３であり、これはハッシュ値（２１３）の「１４」を持っている。言い換えれば、ファイルＩＤ「２０００」のファイルの３番目のパーティションはハッシュ値「１４」を持っている。図４Ａに示したメタデータ３０を参照すると、ファイルＩＤ「２０００」のファイルの３番目のハッシュ値は「１３」である。「１４」は「１３」と同一ではないから、このファイルの３番目のパーティションは改竄されていると判定される。

つまり、読み出しパーティション２０３について、図５Ａに示したパーティション識別情報４０に問い合わせる。読み出しパーティション２０３についてのパーティション識別情報はそのパーティションのファイルＩＤをファイル内での順序位置に基づいて識別される。ここで、このパーティションはファイル（ファイルＩＤ「２０００」）の３番目のパーティションである。これは図５Ａに示したパーティション識別情報８５１に相当する。この情報から、処理中の読み出しパーティション（すなわちパーティション２０３）はパーティションＩＤ（１３，１）を持っていると決定できる。つまり、ステップ５４０によれば、パーティションＩＤ（１３，１）のパーティション全てがループ５５０で考慮される。図５Ａに示した例では、ファイル（ファイルＩＤ「２０００」）は読み出しパーティション２０３と同一であると識別されたパーティション（２番目のパーティション）を含んでいる。

この時点で特筆に値することは、複製ファイルの使用で各パーティションがシステム内にコピーを有することを保証できることである。そのコピーが有効かどうかは別問題であるが、本発明のこの態様はシステム内にあるパーティションが少なくとも一つの同一パーティションを持つように保証する。例えば、図５Ａのパーティション識別情報はファイル（ファイルＩＤ「２０００」）内の第２のパーティションと同一なパーティションだけが複製ファイル（ファイルＩＤ「Ｒ３００」）に格納されたパーティションであることを示している。

続けて、ステップ５６０で、このような「候補」パーティション各々がストレージ・システムから読み出される。これは候補パーティションが属するファイルにアクセスすることによる。ステップ５７０で、対応するファイルをストレージ・システムに書き込んだ際に候補パーティションへ最初に適用したハッシュ・アルゴリズムを候補パーティションに適用してハッシュ値を作成する。ハッシュ値を候補パーティションに対応するメタデータ３０に格納された値と比較する（ステップ５８０）。一致が見られなければ、処理はループ５５０へ進んで次の候補パーティションを考慮する。これ以上候補パーティションが見つからない場合、ステップ６００でエラー条件をユーザへ報告するか、又は後に参照するためのログを残すことができる。エラー条件はファイルが改竄されたことを示す。

一致が見つかれば、候補パーティションは有効であると見なされる。ステップ５９０で、処理しようとしている、改竄された読み出しパーティションを含むデータは、有効な候補パーティションを含むデータによって置換される。この動作はファイル出力プログラム２０（図１）においてファイルＩ／Ｏユティリティを使用しサポートされるファイル・システム内のファイルを変更することで実行される。例えば、パーティション訂正モジュール２３は本発明のこの態様を実行可能である。処理はループ５１０へ戻って次の読み出しパーティションを処理する。

本発明の前述した実施例は既存のストレージ・システムアーキテクチャに好適である。前述の実施例に於いて、あるファイルの構成パーティションは複製ファイル以外物理的に保存されていない。ファイルのパーティションは論理パーティションである。あるパーティションがサイズ１０２４バイトの場合、ｎ番目のパーティションを「識別する」動作は１０２４バイトのデータのブロックを読み出してｎ番目のブロックを保持することによる。ハッシュ・アルゴリズムをそのデータ・ブロックに適用できる。単純に次の１０２４バイトのデータを読み出すことによって次のブロックにアクセスする。

しかしストレージ・システムはパーティション単位でファイルを格納するように構成されることがあることは理解されよう。このようなストレージ・アーキテクチャではパーティションへのアクセスを最適化することにより旧来のシステムに対して性能の向上を提供できる。実装によっては、メタデータ８３０を含む情報とパーティション識別情報８４０を含む情報について変更が必要になることがあることは当業者には理解されよう。このようなストレージ・システムの周知の例はオブジェクト・ベース・ストレージである。ＳＮＩＡ（ストレージ・ネットワーク工業会）はＯＳＤ（オブジェクト・ストレージ・デバイス）についてオブジェクト・ベース・ストレージの標準化を進めて来た。この場合、パーティションは「オブジェクト」と呼ばれる。

図８は本発明のこの態様の実施例の代表例である。図１に示したシステムとの主な相違点は、ストレージ・システム８７０、８７１、８７２の存在である。ストレージ・システムは、情報をファイル８０、８１、８２の単位で格納する図１のストレージ・システム７０、７１、７２と比較して、パーティション８８０、８８１、８８２の単位で各々情報を格納するように示してある。同様に、パーティション複製８９０、８９１、８９２は図１の複製ファイル９０、９１、９２とは異なるものになる。

ファイル・サーバ８０１はストレージ・システム８７０、８７１、８７２によって提供される追加機能にアクセスできる。例えば、ファイル・サーバはオブジェクト再配置機能により所定のユーザ・ポリシーに基づいてストレージ・システム間でのパーティションの再配置又は構成を行なう。ユーザがシステム全体の冗長性を増加させたい場合、ファイルのパーティションを別のストレージ・システムへ再配置する試みが行なえる。

本発明のこの実施例によるファイル・サーバ８０１のコンポーネントはファイル入力プログラム・コンポーネント１０のファイル・パーティショニング・モジュール１１又はファイル出力プログラム・コンポーネント２０のファイル・パーティショニング・モジュール２１を必要としない。その理由は、パーティショニング機能がストレージ・システム８７０，８７１，８７２によって提供されていることによる。しかし、ストレージ・システムによって提供されるのとは異なるパーティション・サイズを用いてファイルをパーティションすることが望まれることがあり、この場合ファイル・パーティショニング・モジュール１１、２１が必要とされる。モジュールはグレーの輪郭で示し必要とされる又は必要とされないことのあるコンポーネントであることを示している。

図９を参照すると、本発明の別の実施例の説明は次のようになる。ここで図示したシステム構成は図１に示してある構成と同様である。ユーザ５０、５１は適当な通信リンク６を介してファイル・サーバ・システム１ａにアクセスする。ストレージ・システム７０ａ、７１ａ、７２ａはユーザにデータ・ストレージ容量を提供する。適当なデータパス７はファイル・サーバとストレージ・システムの間のデータ・リンクを提供する。

ファイル・サーバ１ａはファイル入力プログラム１０ａとファイル出力プログラム２０ａとを含む。ファイル入力プログラムとファイル出力プログラムを構成するモジュールによって実行される動作は図１に示した相当物と同様である。本発明のこの詳細な実施例では、ストレージ・システムへ書き込まれる入力ファイルのパーティショニングは存在しない。同様に、ストレージ・システムから読み出されるファイルのパーティションのアクセスも存在しない。

ファイルの多数の構成パーティションの代わりに、ファイル全体が単一の大きなパーティションとして処理される。結果として、パーティショニング・モジュールは存在しないが、ファイル入力プログラム１０ａとファイル出力プログラム２０ａを含む他のモジュールは図３及び図７に示した処理フロート同様の方法で動作する。つまり、ファイル・ハッシュ化モジュール１２ａはハッシュ関数を入力ファイルの内容全体に適用する。同様に、ファイル認証モジュール２２ａはファイルの内容全体に対してハッシュ関数を適用することを含む。ハッシュ関数（又は内容に基づく符号を生成するための何らかの適当なアルゴリズム）をファイルの一部に（例えば１バイトおきに）適用することができることは理解されよう。本発明のこの詳細な実施例はファイルのパーティショニングが実行されていないことを単に指摘するものである。

入力ファイルについてファイル同一性検査モジュール１３ａは同一パーティションの代わりに同一ファイルを識別する。複製はモジュール１４ａによって作成される。複製はその結果ファイルのコピーである。つまり、ストレージ・システム７０、７１、７２に格納された複製９０ａ、９１ａ、９２ａはファイルのコピーである。ファイルを読み出すには、ファイル訂正モジュール２３ａが同一の有効なファイルを（モジュール２４ａ経由で）検索することによりファイルを修復する。図９の説明を完了するにあたり、メタデータ３０ａは各ファイルについて単一のハッシュ値しか必要としない、言い換えればファイルのハッシュ値しか必要としない。図１に示したパーティション識別情報４０はファイル識別情報４０ａで置き換えられており、これがパーティション番号８３０コンポーネントの存在しないパーティション識別情報として同種の情報を提供する。

本発明は長期データ保存を必要とし長期にわたって自動的なデータ保護も必要とされるような全ての用途でとくに有用である。本発明の前述の実施例はデータの単位としてファイルに関して記述したが、ファイル以外のデータ単位を処理することができることは理解されよう。情報は多様な形態でユーザの特定の要求に基づいて保存することができる。用途のサンプルとしては次のようなものが含まれる：
・デジタル・イメージング、データの歴史的価値が非常に重要な場合。
・電子メール・アーカイブ、同一のメッセージと同一の添付ファイルが多数ユーザに配布されるが効率の良いディスク空間でこれらを効果的にアーカイブする場合。
・コンテンツ／文書アーカイブ、バージョンアップが繰り返されその結果同一データ部分が含まれるような場合。

・医用イメージング、データが長期にわたって正確でなければならないような場合。
・デスクトップ・アーカイブ、オフィス内の全部のデスクトップにあるデータをアーカイブし、ユーザがオフィス内で通常同一の環境を使用することがら通常はデータの大半が同一であるような場合。

本発明によるストレージ・システムの代表的実施例を示す一般化したブロック図である。本発明によるファイル書き込み動作中のファイル処理の略図である。ファイル書き込み動作中の本発明の態様を明示する高レベル・フローチャートである。図１に示したメタデータの代表例である。図１に示したメタデータの代表例である。図１に示したパーティション識別情報の代表例である。図１に示したパーティション識別情報の代表例である。本発明によるファイル読み込み動作中のファイル処理の略図である。ファイル読み込み動作中の本発明の態様を明示する高レベル・フローチャートである。本発明の別の実施例を示す一般化したブロック図である。本発明のさらに別の実施例を示す一般化したブロック図である。

符号の説明

１…ファイル・サーバ、５０…クライアント、７０…ストレージ・システム。

Claims

ファイルを構成するデータを複数のパーティションに分割して、前記各パーティションを格納するストレージ・システムにアクセスするための方法であって、
前記ストレージ・システムへ第１のファイルを格納する要求をクライアントから受信するステップと、
前記要求を受信したときに、前記第１のファイルを構成するデータを複数の入力パーティションに分割して、前記各入力パーティションの内容から前記各入力パーティションのハッシュ値を識別する第１識別ステップと、
前記識別したハッシュ値を基に前記ストレージ・システムに登録されたパーティションと当該パーティションを含むファイルを識別するためのパーティション識別情報を参照して、前記識別したハッシュ値と同一のハッシュ値を有するパーティションを候補パーティションとして識別する第２識別ステップと、
前記識別した候補パーティションの内容と前記入力パーティションの内容とを比較して、前記候補パーティションと前記入力パーティションとが同一パーティションであるかを判定する判定ステップと、
前記候補パーティションと前記入力パーティションとが同一パーティションでないときには、当該入力パーティションを含むファイルの複製を少なくとも一つ、前記クライアントからの書き込みでは書き換えられない複製ファイルとして作成する作成ステップと、
含むことを特徴とする方法。
ファイルを構成するデータを複数のパーティションに分割して、前記各パーティションを格納するストレージ・システムと、
前記ストレージ・システムとクライアントに接続されるデータ処理コンポーネントとを備え、
前記データ処理コンポーネントは、前記ストレージ・システムへ第１のファイルを格納する要求を前記クライアントから受信し、前記要求を受信したときに、前記第１のファイルを構成するデータを複数の入力パーティションに分割して、前記各入力パーティションの内容から前記各入力パーティションのハッシュ値を識別し、前記識別したハッシュ値を基に前記ストレージ・システムに登録されたパーティションと当該パーティションを含むファイルを識別するためのパーティション識別情報を参照して、前記識別したハッシュ値と同一のハッシュ値を有するパーティションを候補パーティションとして識別し、前記識別した候補パーティションの内容と前記入力パーティションの内容とを比較して、前記候補パーティションと前記入力パーティションとが同一パーティションであるかを判定し、前記候補パーティションと前記入力パーティションとが同一パーティションでないときには、当該入力パーティションを含むファイルの複製を少なくとも一つ、前記クライアントからの書き込みでは書き換えられない複製ファイルとして作成することを特徴とするシステム。