JP2016189105A - ストレージシステム - Google Patents

Abstract

【課題】記憶するデータの信頼性を維持しつつ、記憶コストを低下させることができるストレージシステムを提供する。【解決手段】ストレージシステム１００は、複数の記憶装置１１０を備えており、記憶対象データを所定の記憶装置１１０に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、所定の記憶装置とは異なる記憶装置に記憶するデータ管理部１０１を備えた。【選択図】図２２

Description

本発明は、ストレージシステムにかかり、特に、データの冗長性を維持して記憶するストレージシステムに関する。

データの冗長性を維持する方法として、データを多重に持ち、冗長なデータが失われてもデータを維持する方法があるこのような方法を使用した分散ストレージとして、GlusterFSのreplicated volumeがある。

また、データの冗長性を維持するストレージシステムとして、特許文献１に開示のものがある。このシステムでは、ファイルを少なくとも１つのチャンクに分割し、分割されたチャンクを複製して分散格納している。

特開２０１２−０７４０３９号

しかしながら、上述したようなストレージシステムでは、データの冗長性を維持するためにデータを多重化して記憶しているが、冗長分のデータを実際に格納する領域が必要となる。特に、データ領域が多く必要になればなるほど、ハードディスクドライブなど記憶媒体の容量が多く必要となる。その結果、記憶コストが上昇してしまう、という問題が生じる。

このため、本発明の目的は、記憶コストが上昇してしまう、という課題を解決することができるストレージシステムを提供することにある。

本発明の一形態であるストレージシステムは、
複数の記憶装置を備えており、
記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶するデータ管理部を備えた、
という構成をとる。

また、本発明の一形態であるプログラムは、
複数の記憶装置を備えた情報処理装置に、
記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶するデータ管理部、
を実現させる、
という構成をとる。

また、本発明の一形態であるデータ記憶方法は、
複数の記憶装置を備えたストレージシステムによるデータ記憶方法であって、
記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶する、
という構成をとる。

本発明は、上述した構成をとることにより、記憶するデータの信頼性を維持しつつ、記憶コストを低下させることができる。

本発明のストレージシステムの全体構成を示す図である。 図１に開示したノードの構成を示す図である。 図２に開示したノードが備えるファイルシステムの構成を示す図である。 図２に開示したノードが備える分散ファイルシステムの構成を示す図である。 図１に開示したクライアントの構成を示す図である。 図５に開示したクライアントが備える分散ファイルシステムモジュールの構成を示す図である。 記憶するファイルの担当ノードを決定する方法を説明するための図である。 記憶するファイルの担当ノードを決定する方法を説明するための図である。 本発明におけるファイルを記憶するときの様子を説明するための図である。 本発明におけるファイルを記憶するときのデータ構造を説明するための図である。 本発明における各ノードに記憶されるデータの変化の様子を説明するための図である。 本発明における各ノードに対して記憶されるデータの配置を説明するための図である。 図１０の状況からノードが追加されたときのデータの配置の変化を説明するための図である。 図１０の状況からノードが追加されたときのデータの配置の変化を説明するための図である。 図１０の状況からノードが追加されたときのデータの配置の変化を説明するための図である。 図１０の状況からノードが削除されたときのデータの配置の変化を説明するための図である。 図１０の状況からノードが削除されたときのデータの配置の変化を説明するための図である。 図１０の状況からノードが削除されたときのデータの配置の変化を説明するための図である。 本発明のストレージシステムにおけるデータ書き込み時の動作を示すシーケンス図である。 本発明のストレージシステムにおけるデータ読み込み時の動作を示すシーケンス図である。 本発明のストレージシステムを構成するノードにおけるデータ書き込み時の動作を示すシーケンス図である。 本発明のストレージシステムを構成するノードにおけるデータ書き込み時の動作を示すシーケンス図である。 本発明のストレージシステムを構成するノードにおけるデータ読み込み時の動作を示すシーケンス図である。 本発明の付記１におけるストレージシステムの構成を示す図である。

本発明の第１の実施形態を、図１乃至図２１を参照して説明する。図１乃至図６は、ストレージシステムの構成を説明するための図である。図７乃至図２１は、ストレージシステムの動作を説明するための図である。

［構成］
本発明におけるストレージシステムは、分散ファイルシステムを形成している。図１は、ストレージシステムである分散ファイルシステムの外観図である。分散ファイルシステム（以下、「分散ＦＳ」ともいう。）は、複数のノード１〜３（３）が公開する記憶領域（Brick（１〜Ｎ））を１つにまとめて、クライアント２からは１つのファイルシステムとしてみせる記憶装置である。各ノード３をとりまとめた総体を、分散ＦＳクラスタ１又はクラスタと本発明では呼ぶこととする。また、分散ＦＳとして公開された記憶領域に対し、ファイルを格納し、読み出すコンピュータを、クライアント２と呼ぶこととする。

次に、分散ＦＳクラスタ１を構成するノード３の構造を、図２、図３を参照して説明する。ノード３は、自身が持つ記憶装置の記憶領域をBrickとして設定する。分散ＦＳクラスタ１にBrickを追加することで、その記憶領域をネットワーク上に公開する。本発明では、分散ＦＳと一部ＦＳ以外の機能は、一般的なLinuxなどのUNIXが備えている機能を想定している。なお、分散ＦＳの大枠も、一例として、GlusterFSと呼ぶ既存の分散ＦＳを想定している。

なお、ノード３は、演算装置と記憶装置とを備えた情報処理装置（ストレージ装置）であり、演算装置がプログラムを実行することで、以下に説明する分散ファイルシステム３１やファイルシステム３２が実現される。そして、このような構成が、以下に説明するように、記憶装置に対するデータの書き込み、読み出しを制御するデータ管理部として機能する。

ノード３が備えるファイルシステム３２は、一連のデータを二次記憶装置３３上にファイルとして格納・管理できるようにする機能である。Linux上にはSXFSやext3など複数のファイルシステムが存在しており、本発明でもそれらの使用（符号３２２）を想定している。ただし、本発明では、さらに、図３に示すように、圧縮データ管理機構３２１と、エクテント管理構造体３２３に圧縮データか否かを判断する圧縮フラグ３２４と、を追加している。

圧縮データ管理機構３２１ は、書き込まれたデータが圧縮されたデータか否かを制御する。具体的には、XFSなどの既存ファイルシステムが使用するエクステント構造体３２３に圧縮、非圧縮を識別するためのフラグ３２４を追加し、書込み時にこのフラグ３２４をセットすることで実現される。なお、エクステント構造体３２３は、データの開始ブロック、サイズ、オフセットを持っている。

二次記憶装置３３は、ファイルシステム３２以下で、実際に記憶媒体にデータを記憶・読み出し行う。例えば、既存のSCSIドライバやHDD（磁気記憶装置）をそのまま流用できる。

ネットワーク機能３４は、ethernetなどのネットワーク装置３５を制御し、他のノードやクライアントとデータを送受信することができる機能である。本発明でも既存のTCP/IPの使用を想定している。

ネットワーク装置３５は、ネットワーク回線を使い他のノードやクライアントとのやりとりを行うことができる装置である。本発明では、既存のethernetデバイスとその制御を行うethernetドライバを想定しているが、データ通信が行えるならばInfinibandなど他の装置を使用してよい。

ノード３が備える分散ＦＳ３１の内部構造について、図４を用いて詳細に説明する。分散ＦＳ３１は、分散ＦＳクラスタ１を管理するためのノード管理機能４２、クライアントからのアクセス要求を管理する分散ファイルアクセス機能４３、データをノード内に格納するための制御を行う分散ファイルシステム管理機能４４、分散ハッシュテーブル４１（以下DHT）とそれを管理するDHT管理機能４０、auditor４５を有する。

分散ＦＳ３１は、ファイルの分散管理のためにDHT４１を持ち、それを管理するDHT管理機能４０を有する。本発明では、DHT４１をConsistency Hashing法で利用する。

そして、DHT４１は、
種別フラグ：ハッシュ値：ハッシュコンテンツ
をエントリとして持つ表で実現できる。

上記種別フラグは、ハッシュの対象がファイルであるか、ノードであるかを区別するフラグである。種別フラグがノードの場合、ノードの識別情報から得られるハッシュ値をハッシュ値へ、ハッシュコンテンツへノードの識別情報を格納する。種別フラグがファイルの場合、ファイルのパス名から得られるハッシュ値をハッシュ値へ、ハッシュコンテンツにパス名を格納する。

また、DHT管理機能４０は、DHT４１を使って次の機能を提供する。
・ファイルのパス名からハッシュ値を算出する機能：
Hash(path_name) = SHA1(path_name)
具体的な算出方法：
ファイルのパス名をpath_nameとしたとき、ハッシュ関数の一例として本発明ではSHA1を用いてハッシュ値Hath(path_name) を計算し、計算した値をHash(path_name)とする。

・ハッシュ値から担当するノードのハッシュ値を算出する機能：
OwnerNodeHash(path_name)
具体的な算出方法：
ファイルのパス名のハッシュ値を得たのち、DHTを元にConsistency Hashing法で担当するノードを確定し、そのハッシュ値を得る。

・ノードのハッシュ値を得る機能：
NodeHash(node_info)
具体的な算出方法：
ノードの識別子（例えばノードが使用する通信のソースIPアドレス、ソースポート番号を組み) をキーにしてハッシュ値を計算する。IPアドレス、ポート番号の他にノードを識別する手段があればそれを代わりに使用してもよい。

・ノードのハッシュ値から担当ノードの情報を提供する機能：
NodeInfo(hash_no)
具体的な算出方法：
hash_noをキーにしてDHTを検索する。種別がノードでハッシュ値にhash_noを持つエントリが存在すれば、そのエントリが該当の担当ノードである。ハッシュコンテンツ内のノード情報(IPアドレス、ポート番号) を返却する。

・ノードのハッシュ値から次の担当ノードのハッシュ値を算出する機能：
NextNodeHash(hash_no)
具体的な算出方法：
hash_no +1をキーにして後方に向かってDHTを検索する (OwnerNodeHash(hash_no + 1) と同義)。該当する担当ノードが次の担当ノードなのでそのハッシュ値を返却する。

・ノードのハッシュ値から前方の担当ノードのハッシュ値を算出する機能：
PrevNodeHash(hash_no)
具体的な算出方法：
hash_no -1をキーに前方に向かってDHTを検索する。なお、検索の方向は、ハッシュ値が大きくなる方向を後方と呼ぶ。小さくなる方向を前方と呼ぶ。種別がノードで最初に検出したノードが前方の担当ノードなので、そのハッシュ値を返却する。

ノード管理機能４２は、分散ＦＳクラスタ１として必要な、他のノードの識別情報をDHT管理機能４０を経由して保存する。IPアドレス、通信ポートを元にノードのハッシュ値を計算し、DHT管理機能４０を使ってDHT４１へノードの登録（種別フラグ：ノード、計算したハッシュ値、コンテンツ情報：ノードの識別情報） を行う。

通信の高速化のため、ノード管理機能４２に別途通信に必要な情報を管理していてもよい。その場合
ノードのハッシュ値：ノード識別情報（IPアドレス：ポート番号）
のように、ファイルのハッシュ情報を除去したテーブルで管理でき、ノード情報検索の高速化が期待できる。

分散ＦＳ３１の他ノードの情報は、ノード３が分散ＦＳクラスタ１に参加する際に、ネットワーク通信によりノード情報をクラスタ全体でシェアする。

分散ファイルアクセス機能４３は、ネットワーク経由で受け取ったクライアントからの分散ＦＳへのアクセス要求を制御し、応答を返す機能である。以下の機能を有する。
・ファイルのパス名からDHT管理機能４０を使い、ファイルのハッシュ値を得る。次にファイルのハッシュ値とオフセットから自ノードが担当するChunkデータか否かを判断する機能
・自ノードが該当Chunkを担当する場合、ファイルのパス名に応じて、下位レイヤのファイルシステムを使い、スパースファイルとしてデータを格納する機能、またはデータを読出す機能
・自ノードが冗長化データを格納する対象か否かを判断する機能
・自ノードが冗長化データを格納する対象だった場合、ファイルのパス名に応じ、下位レイヤのファイルシステムを使って、スパースファイルとしてデータを格納・読出す機能

分散ファイルシステム管理機能４４は、データをノード上に格納する機能である。下位レイヤのファイルシステムへスパースファイルとしてChunkデータを格納したり、格納されたChunkデータを読み出したりする。

auditor４５は、ファイル（Chunkデータ）の正常性の確認や、冗長性の回復で用いる。詳細は、動作説明の箇所で記載する。

次に、クライアント２の構造について図５を用いて説明する。クライアント２は、情報処理装置であり、分散ＦＳへファイルの読み書きを行うアプリケーションプログラム２６と、プログラムからの要求に応じて計算機を制御するOS２７と、を備えている。なお、これらの機能は、クライアント２が備える演算装置がプログラムを実行することで実現される。本発明では、一例としてLinuxなどの一般的なOS内部のファイルシステムに、本発明の分散ＦＳへのアクセスを行うためのモジュール２１を組み込むが、OS外部に配置しアプリケーションプログラムと連携してデータアクセスすることも可能である。

次に図６を参照して、クライアント２に持たせた分散ＦＳモジュール２１について説明する。分散ＦＳモジュール２１は、分散ＦＳクラスタ１へのアクセスを行う分散ファイルアクセス機能５２とDHT５１を含むDHT管理機能５０を持ち、分散ＦＳクラスタ１が持つ機能の必要最小限のみ利用する。つまり、クライアント２は、上述したノード３と同等の機能をもち、以下に説明するように、記憶装置に対するデータの書き込み、読み出しを制御するデータ管理部として機能する。

［動作］
次に、上述した構成の動作を説明する。本発明では、データの冗長性を確保したうえで、データを分散ＦＳクラスタ１内の複数のノード３に分散して格納する。具体的には、次のような形でデータを保存する。

まず、ファイルを分散格納する際のデータ配置について、概略を説明する。ファイルを分散配置するために、本発明では、Consistency Hashing法を用いる。ここで、Consistency Hashing法について、図７Ａ及び図７Ｂを参照して説明する。

まず、ハッシュ空間をノード数に関連した値の剰余で、分割して管理する方法を考える。このような場合には、ノード数が変化した場合に剰余が変化してしまうため、全体の担当範囲が変わってしまう。もしこの方法をキャッシュに利用していた場合、キャッシュが全て無効化されてしまい著しい速度低下を及ぼしてしまう。これを防ぐアイディアとしてConsistent Hashingと呼ぶ方法が提案されている。

ここで、SHA-1のハッシュ空間は、0以上2の160乗より小さい値であるが、これを図７Ａに示すように、円周上に配置する。ある特別なハッシュ値Ａ，Ｂが存在したとき、Ｂの担当範囲をA＜x, x≦B (0≦ x ≦ 2^160 -1) と定める。ただしAが2^160 -1より大きく、Bが0≦B＜A の関係の場合は、A＜x, x＜2^160 -1 または 0＜x, x＜Bの値を担当範囲とする。例えば、図７Ａの例では、円環上に配置されたIDは、右回りに担当していく。ノードに対してA, Bを割り当て、データを識別するIDにハッシュ値を使うと、データの担当範囲が決定できる。

ここで、ノードが追加された場合、加わったA, Bの範囲を分割する形で担当範囲を変更でき、他の部分に対しては影響を与えない。また、図７Ｂに示すように、ノードが削減された場合は、削減されたノードに対応するIDがBとして、Bの隣のCへ担当範囲が拡大するが、全体には波及せず、局所的な影響に留まる。

上述したようなConsistency Hashing法を用いて、本発明では、まず、各ノード３間でハッシュ空間を分割する。つまり、ここでは、複数のノード３を、ハッシュ値が小さい順に順序付けて管理する。そして、記憶対象データであるファイルを分割した分割データをハッシュ空間に配置する。つまり、複数のノード３間に、それぞれ分割データを配置する。このようなハッシュ空間での配置状況において、自ノード３のハッシュ値よりも前（小さいハッシュ値）の分割データを自ノードの担当とする。つまり、分割データから特定の方向に向かって一番目に位置するノード３を、分割データを格納する担当とする。さらに、自ノード３の次のノードに分割データの冗長データを保存するようにする。これにより、ノードダウン時にもデータが取得できるようになる。

具体的には、全体として以下のように動作する。なお、以下では、クライアント２がデータの格納先となるノードを決定しているが、同様の処理をノード３が実行することも可能である。

まず、クライアント２は、記憶対象となるファイルのパス名からハッシュ値を計算する。また、算出したハッシュ値からConsistency Hashing法でファイルの担当ノードを算出する。そして、クライアント２は、図８Ａに示すように、ファイルをある一定のサイズ（Chunkサイズ単位）に分割する。

続いて、図８Ａに示すように、ファイルの担当ノードを「0」として、Consistency Hashing法の並びで順にChunkサイズに分割したデータを、スパースファイルとして保存する。つまり、ChunkごとにChunkの担当ノードを割り振る。ここでは、ファイルのハッシュ値から、先頭の分割データの担当ノードを「０」とした場合に、後続の各分割データの担当ノードは、一つずつ後ろにずらすこととする。続いて、クライアント２は、Consistency Hashing法の並びの順の方向に沿って、担当ノードの隣のノード「１」に対して、Chunkサイズに分割したデータを圧縮した冗長データを、スパースファイルとして保存する。つまり、圧縮した冗長データを、１つずつノードをずらして格納する。なお、図８Ａでは、圧縮した冗長データを斜線で示している。

このように、本発明では、冗長化するデータはデータ圧縮を行い、必要な記憶領域を減らしている。なお、chunkのデータ圧縮は、元のデータ列に復元できるのであれば手法を問わないので、既存のデータ圧縮方法を用いればよい。

なお、図８Ａでは、表記のため非圧縮データ列と圧縮データ列を並べているが、スパースファイル上では、図８Ｂのように、間をあけてデータを格納する。なお、圧縮データが元データ列よりも大きなサイズとなる場合は、圧縮データとして保存しない。格納したデータが圧縮されたものか否かは、エクステント管理データへフラグを追加し、判別できるようにする。

ここで、スパースファイルについて説明する。スパース（Sparse）ファイルは、データとデータの間に書込みがないスペースが存在するファイルである。実際に書込みがない領域にディスクを割り当てないため、ディスク（記憶装置）の容量を減らすことができる。

次に、分散ＦＳクラスタ１を構成するノード３になんらかの異常が発生しダウンし、復旧する場合を、図９を参照して説明する。

図９における時刻t0は、ノードNに異常が発生する前であり、ノードN, N+1とも正常な状態である。あるChunkに着目し、データ状態をAとし、圧縮した形をA’と記している。

時刻t1は、ノードNに異常が発生しダウンした状態を示す。この状態ではノード(N+1)にAを圧縮したA’が保存されており、それを使うことでデータ参照が可能である。
時刻t2で、ノードNがダウン中に、Chunkが更新されたとする。このとき、ノードNはダウン中のため更新できないが、ノード(N+1)は、更新された(A+1)を圧縮した(A+1)’を保存する。
時刻t3は、ノードNが復旧に成功した状態である。この状態ではノードNが持つ情報がノード(N+1)よりも古く、そのままノードNの情報を読み出す場合は問題となる。このため、本発明では、いかに説明するようにして、ノード(N+1)にある新しいデータを読み出す。

クライアント２は、データを参照する際、上述同様に、ファイルのハッシュ値からChunkの担当ノードを算出し、担当ノードNにアクセスして、データの更新時刻情報を取得する。次に、ノードNの次のノード(N+1)にもアクセスし、ノードNと同じようにデータの更新時刻情報を入手する。

そして、クライアント２は、両ノードの更新時刻情報を比較し、より新しい方のノードに対して、データの取得を要求して取得する。このようにすることで、ラグによる不一致を避けることが可能となる。
時刻t4は、次に新しい更新が発生した状態である。

次に、分散ＦＳクラスタ１へノード３を追加した場合を説明する。まず、Consistency Hashing法で、一部ハッシュ空間を一部切り出し、ノード（Ｎ−１，Ｎ，Ｎ＋１）及びChunk（Ｄ１，Ｄ２，Ｄ３）の配置を示したものが図１０である。この図において、Chunkの非圧縮データの担当ノードを上部実線矢印、圧縮データ（冗長データ）の担当ノードを下部点線矢印で示している。なお、以下に説明するデータ格納位置の移動は、ノード３の機能によって実現される。

この状態から分散ＦＳクラスタ１へノード３を追加すると、図１１のようになる。ここでは、ChunkＤ２とChunkＤ３との間に、ノードＮ’を追加した場合を考える。この場合、ChunkＤ２については、非圧縮データ及び圧縮データの担当が移動することとなるまた、ChunkＤ１については、圧縮データの担当が移動することとなる。つまり、非圧縮データに関しては、ノード（N-1）から追加したノードN’までの区間のChunkが担当になるが、影響する区間は最大で追加される区間（図１１では、ノード(N-1)とノードNの間）内に収まる。圧縮データに関しては、ノードN’の次のノードNが担当していたものが全てノードN’の担当となる。

ここで視点を変えて、あるChunkデータに着目すると、非圧縮データの前にノードが追加される場合と、圧縮データの前にノードが追加される場合に分類できる。つまり、図１１の例では、ChunkＤ２の場合とChunkＤ１の場合で分類できる。

まず、非圧縮データの隣にノードが追加された場合、つまり、図１１ではChunkＤ２に着目した場合が、図１２となる。
時刻t0は、追加ノードN'がクラスタに登録された直後の状態を示す。この時はまだ、ChunkＤ２に対応するデータがノードN'には存在していない。データの更新を行わないとノードN'にはデータが持てない。
時刻t1は、ChunkＤ２に対し更新された（A→A+1）ことを表している。最初に非圧縮データの担当ノードN'に更新がなされる。つまり、ノードが追加されることにより、ハッシュ空間においてハッシュ値が大きくなる方向にChunkに対して一番目に位置することとなったノードN'に、ChunkＤ２を格納することとなる。

時刻t2は、ノードNに対し圧縮データが更新されたことを表している。つまり、ノードが追加されることにより、ハッシュ空間においてハッシュ値が大きくなる方向にChunkに対して二番目に位置することとなったノードNに、ChunkＤ２の圧縮データ（冗長データ）を格納することとなる。なお、非圧縮データと圧縮データのみやりとりする形態では、ノード(N+1)に以前格納したデータが残存し、データ量を減らすのに邪魔する事が分かる。本発明では、次のようにしてこの問題を克服する。

auditor４５と呼ぶ機能を用意する。auditor４５は、起動してから一定時間経過すると、自身が格納しているデータをチェックし、非圧縮データ、圧縮データの担当から外れているものを検出すると、そのChunkのデータを破棄する。図１２では、時刻t3にて、ノード(N+1)に記憶されているA'が削除される。つまり、圧縮データA'は、時刻t2のときにノードNに記憶し直しているため、かかるデータA'は不要となり、削除する。なお、このとき、ノードNに、ノードN'に記憶し直した更新前の非圧縮データAが残っている場合には、当該非圧縮データAをauditor４５で削除してもよい。

なお、auditor４５のような形態をとらずに、影響する範囲をすべて移動し終えておく方法も考えられる。この方法では、データの冗長性を保ったままノードを追加することが可能だが、データのコピーなどを行うまでの間、クラスタに参加できない問題を抱える。負荷分散を直ちに行いたい場合に支障が出るため、本発明ではauditor４５による方法を用いることが望ましい。

次に、圧縮データの前に追加された状態、つまり、図１１ではChunkＤ１に着目した場合が、図１３となる。
時刻t0は、ノードN'が追加された直後を示す。この時はまだ、ChunkＤ１に対応するデータがノードN'には存在していない。データの更新を行わないとノードN'にはデータが持てない。

時刻t1は、ChunkＤ１に対しデータ更新が行われた(A→A+1)状態を示す。ノード(N-1)が担当なのでA+1と状態を更新している。
時刻t2は、圧縮データを次のノードN'へ格納した状態を示す。つまり、ノードが追加されることにより、ハッシュ空間においてハッシュ値が大きくなる方向にChunkに対して二番目に位置することとなったノードN'に、ChunkＤ１の圧縮データ（冗長データ）を格納することとなる。

ここで、この格納パターンでは、上述した場合とは異なり、非圧縮データが前のノードNへ残ってしまい、記憶領域の削減に問題があることが分かる。この問題も上述同様に、auditor４５を用意することで回避できる。つまり、時刻t3にてノードNのA'を削除する。

次に、分散ＦＳクラスタ１からノード３を削除する事を考える。分散ＦＳクラスタへのノード追加と同様に、ノードの削除を行った場合は、図１０の状態から図１４のように推移する。この場合、非圧縮データに関しては、ノード(N-1)から削除したノードNまでの区間の担当がノード(N+1)となる。ノード(N+1)にとっては、ノード(N-1)からノードNまでの区間の担当が増える。圧縮データに関しては、ノードNが担当していたものが全てノード(N+2)の担当へ変更される。

ノードの削除においても、あるChunkに着目した場合に、非圧縮データの隣のノードが削除される場合と、圧縮データの隣のノードが削除される場合とで分類できる。ここで視点を変えて、あるChunkデータに着目すると、非圧縮データの前に削除される場合と、圧縮データの前に削除される場合に分類できる。つまり、図１１の例では、ChunkＤ２の場合とChunkＤ１の場合で分類できる。

なお、ノードのダウン状態とクラスタの登録削除は異なるのは、登録削除ではDHTからノード情報を削除することにあり、非圧縮データ、圧縮データとも書込みができる状態になっていることである。

図１５は、非圧縮データの前のノード、つまり、ChunkＤ２に着目した場合を示している。
時刻t0は、ノードNを分散ＦＳクラスタから削除する前の状態である。
時刻t1は、ノードNを分散ＦＳクラスタから削除した状態である。

時刻t2は、着目するChunkＤ２に対し更新を行った(A→A+1)状態であり、この場合には、ノード(N+1)に非圧縮データが格納される。つまり、ノードが削除されることにより、ハッシュ空間においてハッシュ値が大きくなる方向にChunkに対して一番目に位置することとなったノード(N+1)に、ChunkＤ２を格納することとなる。

時刻t3は、圧縮データ(A+1)'の書き込みも終了した状態であり、この場合には、ノード(N+2)に圧縮データが格納される。つまり、ノードが削除されることにより、ハッシュ空間においてハッシュ値が大きくなる方向にChunkに対して二番目に位置することとなったノード(N+2)に、ChunkＤ２の圧縮データを格納することとなる。

なお、分散ＦＳクラスタからのノード削除は、ノード追加とは異なり、データが残ってしまう問題は発生しない。

図１６は、圧縮データの前のノードN、つまり、ChunkＤ１に着目した場合を示している。
時刻t0は、ノードNを分散ＦＳクラスタから削除する前の状態である。
時刻t1は、ノードNを分散FSクラスタから削除した状態である。
時刻t2は、着目するChunkＤ１に対し更新を行った状態である。非圧縮データの担当ノードであるノード(N-1)上で、データが更新される。

時刻t3は、圧縮データ(A+1)'の書き込みも終了した状態である。圧縮データの担当ノードがノード(N+1)に移動するので、ノード(N+1)上に圧縮データが格納される。つまり、ノードが削除されることにより、ハッシュ空間においてハッシュ値が大きくなる方向にChunkに対して二番目に位置することとなったノード(N+1)に、ChunkＤ１の圧縮データを格納することとなる。

なお、このパターンでも、上述同様にデータが残る問題は発生しない。つまり、分散ＦＳクラスタからのノード削除ではノード追加とは異なりデータが残る問題が発生しないことが分かる。

上記までの概要を踏まえ、個々のコンポーネントの動作を詳細に説明する。
まず、分散ＦＳクラスタ１へのクライアント２のマウントについて説明する。クライアント２は、分散ＦＳ領域をマウントすることで、ファイルがアクセス可能となる。マウントを行った時、ノード３からDHTのコピーを行う。なお、本実施形態では、クライアント２側でノード３を選択し分散アクセスできるようにしているが、指定したノード３から宛先を教えてもらう分散方法も考えられる。

分散ＦＳクラスタ１のクライアント２のデータアクセス動作について、図１７及び図１８を参照して説明する。データアクセスは、クライアント２のアプリケーションがファイル参照・書込みを行うことが起点となる。アプリケーション２６からOS２７へ書込み要求・読込み要求は発行され、OS２７内部の分散ＦＳモジュール２１では以下のように動作する。

クライアント２は、まずファイルのパス名からファイルに対するハッシュ値Hash(path_name)を分散FSモジュール２１で算出する（図１７のステップＳ１，（図１８のステップＳ１１）。そして、ファイルのハッシュ値から担当ノードのハッシュ値OwnerNodeHash(path_name)を取得する。

ファイルの読み出し、書込み位置がオフセットとなる。オフセットを一定のサイズ(Chunk)で割り、操作対象のChunkを算出する。取得したOwnerNodeHash(path_name)をChunk数分NextNodeHash() を実行し、該当Chunkの担当ノードのハッシュ値を得る。また、通信のためそのハッシュ値をキーにNodeInfo(hash_no) を実行し、IPアドレスとポート番号を取得する（図１７のステップＳ２，図１８のステップＳ１２）。

該当Chunkの担当ノードの次のノード情報を得るためNextNodeHash() を該当Chunkの担当ノードをキーにして実行し、ノードのハッシュ値を得る。また通信のためそのハッシュ値をキーにNodeInfo(hash_no) を実行し、IPアドレスとポート番号を取得する（図１７のステップＳ２，図１８のステップＳ１２）。

続いて、該当Chunkの担当ノードと通信し、読み込み、書込み要求を行う。書込み要求の場合、まず、該当Chunkの担当ノードに対し、非圧縮のデータを書込み要求する（図１７のステップＳ３）。また、該当Chunkの担当ノードの次のノードに対し、圧縮したデータの書込み要求を行う（図１７のステップＳ５）。上記の書き込み要求に対して、書込み完了通知が返ってこなかったら、書込み要求元のアプリケーションに対し、書込みエラーを返却する。エラーにならなかった場合は、書込み完了を通知する（図１７のステップＳ４，Ｓ６）。

読込み要求の場合は、まず、該当Chunkの担当ノードに対し、更新日付の情報を要求する（図１８のステップＳ１３）。もし一定時間経過してもノードからの応答がなかった場合、更新日付を最も古い値とする。

該当Chunkの担当ノードの次のノードに対し、更新日付の情報を要求する（図１８のステップＳ１５）。もし一定時間経過してもノードからの応答がなかった場合、更新日付を最も古い値をとする。

両ノードから得た更新日付を比較し（図１８のステップＳ１４，Ｓ１６，Ｓ１７）、より新しい更新日付を持つノードに対し、読込み要求を行う（図１８のステップＳ１８）。もし同じ値であれば、Chunkの担当ノードを優先すればよいが、応答時間を計測しておきより速いノードに対し要求を行ってもよい。

応答としてデータが返ってきたら（図１８のステップＳ１９）、読込み要求元のアプリケーションへデータを返却する。もし一定時間経過してもノードから応答が返ってこなかったら、読込み要求元のアプリケーションへ読込みエラーを返却する。

次に、分散ＦＳクラスタに参加するノードの動作を説明する。対象のハッシュ値とデータの開始位置から、自分が担当するデータか、それとも冗長データに対する要求なのかが分かる。そのため以下のように制御する。

まず、分散ＦＳへの書込みについて、図１９、図２０を参照して説明する。クライアント２から書き込み要求を受けると（図１９のステップＳ２１，図２０のステップＳ３１）、ファイルのパス名やオフセットから自身が非圧縮データあるいは圧縮データを格納する担当であるか否かを判定する（図１９のステップＳ２２，図２０のステップＳ３２）。書き込み要求を受けた格納される側（ノード側）が該当Chunkの担当であれば（図１９のステップＳ２３でＹｅｓ，図２０のステップＳ３３でＹｅｓ）、ノード３の分散ファイルアクセス機能４３は要求を受け付ける。もし担当外であれば（図１９のステップＳ２３でＮｏ，図２０のステップＳ３３でＮｏ）、分散ファイルアクセス機能４３は書込みエラーを返す（図１９のステップＳ２８，図２０のステップＳ３９）。

分散ファイルアクセス機能４３が要求を受け付けた場合、次に分散ファイルシステム管理機能４４を通して、ノード内にデータを格納する。自身が非圧縮データの担当ノードであれば、ファイルシステムへスパースファイルとしてデータを書込む（図１９のステップＳ２４）。書込みが失敗したら（図１９のステップＳ２５でＮｏ）、クライアントへエラーを返す（図１９のステップＳ２８）。圧縮データの担当ノードの場合、データを圧縮し（図２０のステップＳ３４）、圧縮したデータをスパースファイルとして書込む（図２０のステップＳ３５）。もし書込みが失敗したら（図２０のステップＳ３６でＮｏ）、クライアントへエラーを返す（図２０のステップＳ３９）。

書き込みが成功した場合には、関連するエクステント３２３の圧縮フラグ３２４を設定し（図１９のステップＳ２６，図２０のステップＳ３７）、圧縮データであるかどうかが分かるようにする。最後にクライアントに対し書込み完了通知を行う（図１９のステップＳ２７，図２０のステップＳ３８）。

次に、分散ＦＳへの読込み要求について、図２１を参照して説明する。クライアント２から読み込み要求を受けると（図２１のステップＳ４１）、ファイルのパス名やオフセットから自身が担当であるか否かを判定する（図２１のステップＳ４２）。読み込み要求を受けた側（ノード側）が該当Chunkの担当であれば（図２１のステップＳ４３でＹｅｓ）、ノード３の分散ファイルアクセス機能４３は要求を受け付ける。もし担当外であれば（図２１のステップＳ４３でＮｏ）、分散ファイルアクセス機能４３は書込みエラーを返す（図２１のステップＳ４８）。

分散ファイルアクセス機能４３が要求を受け付けた場合、要求されたChunkデータを持っているか確認する（図２１のステップＳ４４）。持っていない場合も（図２１のステップＳ４５でＮｏ）、エラーをクライアントへ返却する（図２１のステップＳ４８）。データを持っている場合は（図２１のステップＳ４５でＹｅｓ）、指定領域のデータを分散ファイルシステム３１へ取り出す。このとき、本発明では、ファイルシステムで使用するエクステント３２３に対し、圧縮、非圧縮を判別するフラグ３２４を追加している。この追加により、エクステント３２３が指す領域が圧縮されたデータなのか、それとも非圧縮のデータなのかが分かる。エクステント３２３の圧縮フラグ３２４を確認し、もし圧縮フラグがONになっていたら、取り出したデータは圧縮データのため展開を行って通常データに戻す。フラグがOFFのままであれば、展開動作は行わない（図２１のステップＳ４６）。

そして、要求元のクライアントに対し、分散ファイルアクセス機能４３から、取り出したデータを転送する（図２１のステップＳ４７）。

次に、分散ＦＳクラスタ１へのノードの追加・除去動作について説明する。追加削除の方法自体については、既存技術を流用できる。

ノードの追加の際には、まず、追加したい分散ＦＳクラスタを構成するノードへログインし、ノードAの追加要求を行う。DHT管理機能４０にて既に登録済みか確認する。登録済みであれば何もしない（以下の作業を行わない）。

ノードのハッシュ値とノードの識別情報をDHT４１へ格納する。DHT管理機能４０から、他のノード情報を得る。ノード管理機能４２を使い、他のノードに対し新規ノードが追加されたことを通知する。通知されたノードは、新しいノード情報を登録する。これを分散ＦＳクラスタを構成するすべてのノードに対し繰り返す。

以上のようにしてノードが追加されると、必要に応じて、図１１から図１３を参照して説明したように、Chunkの非圧縮データや圧縮データの格納先の変更処理が行われる。

次に、ノードの削除動作を説明する。削除したい分散ＦＳクラスタを構成するノードへログインし、ノードAの削除要求を行う。DHT管理機能４０にて該当のノード（ノードA）が登録されているか確認する。登録されていなければ以降の作業を行わない。

DHT管理機能４０は、該当するノード情報含むエントリをDHT４１から削除する。DHT管理機能４０から、他のノード情報を得る。ノード管理機能４２を使い、他のノードに対し削除要求されたことを通知する。通知されたノードは、該当のノード情報をDHT４１から削除する。これを分散ＦＳクラスタを構成するすべてのノードに対し繰り返す。

以上のようにしてノードが削除されると、必要に応じて、図１４から図１６を参照して説明したように、Chunkの非圧縮データや圧縮データの格納先の変更処理が行われる。

次に、ノードの起動時の動作を説明する。ノードが起動すると、分散ＦＳクラスタに登録されているか確認する。登録されていた場合、分散ＦＳクラスタのノードとして設定を行う。ノード管理機能４２にある通信サービス用のプログラムを起動する。分散ファイルアクセス機能４３にあるファイルアクセスのために通信するサービスプログラム（待ち受けデーモン）を起動する。auditor４５を起動する。

次に、auditor４５の動作を説明する。auditorプログラムが起動されるとまずは一定時間待機を行う。待機後、自ノードのハッシュ値をNodeHash()を使い得る。分散ファイルシステム管理機能４４を使って、スパースファイルのチェックを行う。0より大きなファイルを見つけた場合でかつ自ノードが非圧縮や圧縮の担当ノードでない場合、該当Chunkデータを削除し保存領域を解放する。

auditor４５は次の担当ノードへ該当ファイルの圧縮されたChunkデータの更新日付を確認する。もし自ノードよりも新しければ、次の担当ノードから圧縮されたChunkデータを転送し、非圧縮データとして保存する（冗長性を回復する）。

以上のように、本発明によると、記憶するデータの冗長性を保ったまま、実際に格納に要するデータ量を削減できる。この結果、必要とする二次記憶容量が減少し、記憶装置といったハードウェアコストを引き下げることができる。

＜付記＞
上記実施形態の一部又は全部は、以下の付記のようにも記載されうる。以下、本発明におけるストレージシステム（図２２参照）、プログラム、データ記憶方法の構成の概略を説明する。但し、本発明は、以下の構成に限定されない。

（付記１）
複数の記憶装置を備えたストレージシステムであって、
記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶するデータ管理部を備えた、
ストレージシステム。

（付記２）
付記１に記載のストレージシステムであって、
前記データ管理部は、前記記憶対象データを複数の分割データに分割し、当該各分割データを各記憶装置に分散して記憶すると共に、所定の記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを、当該所定の記憶装置とは異なる記憶装置に記憶する、
ストレージシステム。

（付記３）
付記２に記載のストレージシステムであって、
前記データ管理部は、複数の記憶装置を順序付けて管理し、当該順序付けられた前記各記憶装置の間に前記各分割データがそれぞれ位置するよう設定されており、前記分割データの位置に対して特定方向に沿った順序で一番目に位置する記憶装置に当該分割データを格納し、当該一番目に位置する記憶装置からさらに特定方向に沿った順序で二番目に位置する記憶装置に、前記一番目に位置する記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを記憶する、
ストレージシステム。

（付記４）
付記３に記載のストレージシステムであって、
前記データ管理部は、所定の順序の位置に前記記憶装置が追加されることにより、当該追加された記憶装置が前記分割データの位置に対して特定方向に沿った順序で一番目に位置することとなった場合に、当該分割データを当該追加された記憶装置に記憶し、当該分割データの位置に対して特定方向に沿った順序で二番目に位置する記憶装置に、当該分割データと同一のデータを圧縮した圧縮データを記憶する、
ストレージシステム。

（付記５）
付記３又は４に記載のストレージシステムであって、
前記データ管理部は、所定の順序の位置に前記記憶装置が追加されることにより、当該追加された記憶装置が前記分割データの位置に対して特定方向に沿った順序で二番目に位置することとなった場合に、当該分割データと同一のデータを圧縮した圧縮データを、当該追加された記憶装置に記憶する、
ストレージシステム。

（付記６）
付記４又は５に記載のストレージシステムであって、
前記データ管理部は、前記記憶装置が追加されることにより、別の記憶装置に記憶しなおした前記分割データ及び／又は前記圧縮データを、記憶しなおす前に記憶されていた記憶装置から削除する、
ストレージシステム。

（付記７）
付記３乃至６のいずれかに記載のストレージシステムであって、
前記データ管理部は、所定の順序に位置する前記記憶装置が削除された場合に、当該削除された記憶装置に記憶されていた前記分割データを、当該分割データの位置に対して特定方向に沿った順序で一番目に位置することとなった記憶装置に記憶し、当該分割データの位置に対して特定方向に沿った順序で二番目に位置することとなった記憶装置に、当該分割データと同一のデータを圧縮した圧縮データを記憶する、
ストレージシステム。

（付記８）
付記３乃至７のいずれかに記載のストレージシステムであって、
前記データ管理部は、所定の順序に位置する前記記憶装置が削除された場合に、当該削除された記憶装置に記憶されていた前記圧縮データを、当該圧縮データに対応する前記分割データの位置に対して特定方向に沿った順序で二番目に位置することとなった記憶装置に記憶する、
ストレージシステム。

（付記９）
複数の記憶装置を備えた情報処理装置に、
記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶するデータ管理部、
を実現させるためのプログラム。

（付記９．１）
付記９に記載のプログラムであって、
前記データ管理部は、前記記憶対象データを複数の分割データに分割し、当該各分割データを各記憶装置に分散して記憶すると共に、所定の記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを、当該所定の記憶装置とは異なる記憶装置に記憶する、
プログラム。

（付記９．２）
付記９．１に記載のプログラムであって、
前記データ管理部は、複数の記憶装置を順序付けて管理し、当該順序付けられた前記各記憶装置の間に前記各分割データがそれぞれ位置するよう設定されており、前記分割データの位置に対して特定方向に沿った順序で一番目に位置する記憶装置に当該分割データを格納し、当該一番目に位置する記憶装置からさらに特定方向に沿った順序で二番目に位置する記憶装置に、前記一番目に位置する記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを記憶する、
プログラム。

（付記１０）
複数の記憶装置を備えたストレージシステムによるデータ記憶方法であって、
記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶する、
データ記憶方法。

（付記１０．１）
付記１０に記載のデータ記憶方法であって、
前記記憶対象データを複数の分割データに分割し、当該各分割データを各記憶装置に分散して記憶すると共に、所定の記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを、当該所定の記憶装置とは異なる記憶装置に記憶する、
データ記憶方法。

（付記１０．２）
付記１０．２に記載のデータ記憶方法であって、
複数の記憶装置を順序付けて管理し、当該順序付けられた前記各記憶装置の間に前記各分割データがそれぞれ位置するよう設定されており、前記分割データの位置に対して特定方向に沿った順序で一番目に位置する記憶装置に当該分割データを格納し、当該一番目に位置する記憶装置からさらに特定方向に沿った順序で二番目に位置する記憶装置に、前記一番目に位置する記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを記憶する、
データ記憶方法。

なお、上述したプログラムは、記憶装置に記憶されていたり、コンピュータが読み取り可能な記録媒体に記録されている。例えば、記録媒体は、フレキシブルディスク、光ディスク、光磁気ディスク、及び、半導体メモリ等の可搬性を有する媒体である。

以上、上記実施形態等を参照して本願発明を説明したが、本願発明は、上述した実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明の範囲内で当業者が理解しうる様々な変更をすることができる。

１ 分散ファイルシステムクラスタ
２ クライアント
２１ 分散ファイルシステムモジュール
２２ ファイルシステム
２３ 二次記憶装置
２４ ネットワーク
２５ ネットワーク装置
２６ アプリケーションプログラム
２７ ＯＳ
３ ノード
３１ 分散ファイルシステム
３２ ファイルシステム
３３ 二次記憶装置
３４ ネットワーク
３５ ネットワーク装置
３２１ 圧縮データ管理機構
３２２ ファイルシステム機構
３２３ エクステント
３２４ 圧縮フラグ
４０ ＤＨＴ管理機能
４１ ＤＨＴ
４２ ノード管理機能
４３ 分散ファイルアクセス機能
４４ 分散ファイルシステム管理機能
４５ auditor
５０ ＤＨＴ管理機能
５１ ＤＨＴ
５２ 分散ファイルアクセス機能
１００ ストレージシステム
１０１ データ管理部
１１０ 記憶装置

Claims (10)

1. 複数の記憶装置を備えたストレージシステムであって、
   記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶するデータ管理部を備えた、
   ストレージシステム。
2. 請求項１に記載のストレージシステムであって、
   前記データ管理部は、前記記憶対象データを複数の分割データに分割し、当該各分割データを各記憶装置に分散して記憶すると共に、所定の記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを、当該所定の記憶装置とは異なる記憶装置に記憶する、
   ストレージシステム。
3. 請求項２に記載のストレージシステムであって、
   前記データ管理部は、複数の記憶装置を順序付けて管理し、当該順序付けられた前記各記憶装置の間に前記各分割データがそれぞれ位置するよう設定されており、前記分割データの位置に対して特定方向に沿った順序で一番目に位置する記憶装置に当該分割データを格納し、当該一番目に位置する記憶装置からさらに特定方向に沿った順序で二番目に位置する記憶装置に、前記一番目に位置する記憶装置に記憶した前記分割データと同一のデータを圧縮した圧縮データを記憶する、
   ストレージシステム。
4. 請求項３に記載のストレージシステムであって、
   前記データ管理部は、所定の順序の位置に前記記憶装置が追加されることにより、当該追加された記憶装置が前記分割データの位置に対して特定方向に沿った順序で一番目に位置することとなった場合に、当該分割データを当該追加された記憶装置に記憶し、当該分割データの位置に対して特定方向に沿った順序で二番目に位置する記憶装置に、当該分割データと同一のデータを圧縮した圧縮データを記憶する、
   ストレージシステム。
5. 請求項３又は４に記載のストレージシステムであって、
   前記データ管理部は、所定の順序の位置に前記記憶装置が追加されることにより、当該追加された記憶装置が前記分割データの位置に対して特定方向に沿った順序で二番目に位置することとなった場合に、当該分割データと同一のデータを圧縮した圧縮データを、当該追加された記憶装置に記憶する、
   ストレージシステム。
6. 請求項４又は５に記載のストレージシステムであって、
   前記データ管理部は、前記記憶装置が追加されることにより、別の記憶装置に記憶しなおした前記分割データ及び／又は前記圧縮データを、記憶しなおす前に記憶されていた記憶装置から削除する、
   ストレージシステム。
7. 請求項３乃至６のいずれかに記載のストレージシステムであって、
   前記データ管理部は、所定の順序に位置する前記記憶装置が削除された場合に、当該削除された記憶装置に記憶されていた前記分割データを、当該分割データの位置に対して特定方向に沿った順序で一番目に位置することとなった記憶装置に記憶し、当該分割データの位置に対して特定方向に沿った順序で二番目に位置することとなった記憶装置に、当該分割データと同一のデータを圧縮した圧縮データを記憶する、
   ストレージシステム。
8. 請求項３乃至７のいずれかに記載のストレージシステムであって、
   前記データ管理部は、所定の順序に位置する前記記憶装置が削除された場合に、当該削除された記憶装置に記憶されていた前記圧縮データを、当該圧縮データに対応する前記分割データの位置に対して特定方向に沿った順序で二番目に位置することとなった記憶装置に記憶する、
   ストレージシステム。
9. 複数の記憶装置を備えた情報処理装置に、
   記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶するデータ管理部、
   を実現させるためのプログラム。
10. 複数の記憶装置を備えたストレージシステムによるデータ記憶方法であって、
    記憶対象データを所定の記憶装置に記憶すると共に、当該所定の記憶装置に記憶した記憶対象データと同一のデータを圧縮した圧縮データを、前記所定の記憶装置とは異なる記憶装置に記憶する、
    データ記憶方法。
    

Images