(57)【要約】【課題】  異種類のボリュームの特徴を活かしてストレージ装置の性能を向上させる。【解決手段】  ストレージ装置１の制御部３は、メモリ６上に仮想ボリューム７を構築している。仮想ボリューム７は、低速ボリューム４と高速ボリューム５とから構成され、低速ボリューム４と同一サイズの容量を有する。ホスト２のアプリケーションプログラム２Ａがデータの更新を要求すると（Ｓ１）、ライトデータは各ボリューム４，５にそれぞれ書き込まれる（Ｓ２，Ｓ３）。仮想ボリューム７には、予めデータの保存期間を示すライフタグが設定されている。保存期間が経過すると、そのデータは高速ボリューム５から消去される（Ｓ４）。低速ボリューム４のデータはそのまま維持される。データが高速ボリューム５に保持されている間は、高速ボリューム５のデータを利用してホスト２からのアクセスを処理する。【選択図】        図１
2006139552.tif 000002
【特許請求の範囲】
【請求項１】
上位装置により利用されるデータを記憶する第１ボリュームと、
前記第１ボリュームに記憶されるデータのうち一部のデータを記憶する第２ボリュームと、
前記第２ボリュームに記憶されているデータを管理するための第１管理部と、
前記第２ボリュームに記憶されているデータと前記第１ボリュームに記憶されているデータとの対応関係を管理する第２管理部と、
前記第２ボリュームへのデータ更新の際に、この更新データに保存期間を対応付けて管理する第３管理部と、
前記第２ボリュームに記憶されているデータのうち、前記保存期間の経過したデータを検出して前記第２ボリュームから消去するデータ消去部と、
前記第１管理部又は／及び前記第２管理部を用いることにより、前記上位装置からのアクセス要求を処理するアクセス処理部と、
を備えたストレージ装置。
【請求項２】
前記第１ボリュームは相対的に低速なボリュームであり、前記第２ボリュームは相対的に高速なボリュームである請求項１に記載のストレージ装置。
【請求項３】
前記アクセス処理部は、前記上位装置からのアクセス要求が対象とするデータが、前記第１ボリューム及び前記第２ボリュームの両方に記憶されている場合、前記第２ボリュームを用いて前記アクセス要求を処理する請求項１に記載のストレージ装置。
【請求項４】
前記第１ボリュームと前記第２ボリュームとを含んで仮想化された仮想ボリュームが前記上位装置に提供され、かつ、前記仮想ボリュームは前記第１ボリュームと同一の記憶容量を有しており、前記上位装置は、前記仮想ボリュームに対して前記アクセス要求を行う請求項１に記載のストレージ装置。
【請求項５】
前記アクセス処理部は、前記上位装置から前記仮想ボリュームにデータが書き込まれる場合、前記仮想ボリュームにおける格納位置と同一の格納位置で前記第１ボリュームに前記データを書込み、前記仮想ボリュームにおける格納位置と異なる格納位置で前記第２ボリュームに前記データを書き込むものである請求項４に記載のストレージ装置。
【請求項６】
前記保存期間は、前記上位装置によって所定の単位毎に設定されるものであり、前記第３管理部は、前記上位装置により指示された保存期間を管理する請求項１に記載のストレージ装置。
【請求項７】
前記上位装置は、ファイル単位又はディレクトリ単位のいずれか又は双方で、前記保存期間を設定可能である請求項６に記載のストレージ装置。
【請求項８】
前記上位装置は、前記保存期間を含むライトコマンドを発行するものであり、前記第３管理部は、このライトコマンドによって書き込まれるデータに、前記ライトコマンドに含まれている前記保存期間を対応付けて管理する請求項６に記載のストレージ装置。
【請求項９】
前記保存期間は、段階的に設定可能である請求項１に記載のストレージ装置。
【請求項１０】
前記保存期間は、ＬＵ（Logical Unit）単位で予め設定可能である請求項１に記載のストレージ装置。
【請求項１１】
前記保存期間は、ＬＵ（Logical Unit）に対応付けられる論理ボリューム単位で設定可能である請求項１に記載のストレージ装置。
【請求項１２】
前記データ消去部は、消去対象のデータが前記第１ボリュームに記憶されていることを確認し、前記消去対象のデータが前記第１ボリュームに記憶されていない場合、この消去対象のデータを前記第１ボリュームに記憶させてから、この消去対象のデータを前記第２ボリュームから消去する請求項１に記載のストレージ装置。
【請求項１３】
前記上位装置から書き込まれるデータを一時的に記憶するキャッシュメモリをさらに備えており、
前記アクセス処理部は、前記キャッシュメモリに所定の空き容量が存在しない場合、前記上位装置からのデータを前記第２ボリュームに記憶させる請求項１に記載のストレージ装置。
【請求項１４】
前記第２ボリュームに記憶されたデータは、所定のタイミングで、前記第１ボリュームに記憶される請求項１４に記載のストレージ装置。
【請求項１５】
前記第１ボリュームまたは前記第２ボリュームのいずれか又は両方は、外部に設けられた他のストレージ装置が有する外部ボリュームに対応付けられており、前記第１ボリュームまたは前記第２ボリュームを対象とする書込みデータは、前記外部ボリュームに記憶される請求項１に記載のストレージ装置。
【請求項１６】
前記第１ボリュームは複数設けられており、これら複数の第１ボリュームに対して前記第２ボリュームがそれぞれ対応付けられている請求項１に記載のストレージ装置。
【請求項１７】
前記第１ボリュームは複数設けられており、前記第２ボリュームは、これら各複数の第１ボリュームに対してそれぞれ対応付けられている請求項１に記載のストレージ装置。
【請求項１８】
ストレージ装置に記憶されるデータのライフサイクルを管理する方法であって、
相対的に低速な第１ボリュームと相対的に高速な第２ボリュームとを仮想化してなる仮想ボリュームに対する上位装置からのデータを受信するステップと、
前記データに保存期間を対応付けて管理するステップと、
前記データを前記第２ボリュームに記憶させるステップと、
前記データを前記第１ボリュームに記憶させるステップと、
前記上位装置からのアクセス要求を前記第２ボリュームに記憶されたデータを用いて処理するステップと、
前記第２ボリュームに記憶されているデータのうち、前記保存期間の経過したデータを検出するステップと、
前記検出されたデータを前記第２ボリュームから消去するステップと、
を含むストレージ装置のデータライフサイクル管理方法。
【請求項１９】
上位装置とのデータ授受と、相対的に低速な記憶デバイスから構成される第１ボリュームとの間のデータ授受及び相対的に高速な記憶デバイスから構成される第２ボリュームとの間のデータ授受とをそれぞれ制御する制御部と、
前記制御部により使用されるメモリ部と、
前記第１ボリューム及び前記第２ボリュームを仮想化して構成される仮想ボリュームに記憶されるデータのうち、前記第２ボリュームに記憶されているデータを管理するための更新ビットマップテーブルと、
前記第２ボリュームに記憶されているデータと前記第１ボリュームに記憶されているデータとの対応関係及び前記第２ボリュームに記憶されているデータに対応付けられた保存期間をそれぞれ管理する管理テーブルと、
前記第２ボリュームに記憶されているデータのうち、前記保存期間の経過したデータを検出し、この保存期間の経過したデータを前記第２ボリューム上で無効化するデータ消去部と、
前記更新ビットマップテーブル又は／及び前記管理テーブルを用いることにより、前記上位装置からのアクセス要求を処理するアクセス処理部と、
を備えたストレージ装置。
【請求項２０】
前記更新ビットマップテーブルは前記メモリ部に記憶され、前記管理テーブルは前記第２ボリュームに記憶されている請求項１９に記載のストレージ装置。
【請求項２１】
上位装置とこの上位装置に接続されるストレージ装置とを備えたストレージシステムであって、
前記上位装置は、前記ストレージ装置に記憶されているデータを利用する場合に、ファイル単位又はディレクトリ単位のいずれか又は双方で、データの保存期間を指定することができ、
前記ストレージ装置は、
前記上位装置により利用されるデータを記憶する第１ボリュームと、
前記第１ボリュームに記憶されるデータのうち一部のデータを記憶する第２ボリュームと、
前記第２ボリュームに記憶されているデータを管理するための第１管理部と、
前記第２ボリュームに記憶されているデータと前記第１ボリュームに記憶されているデータとの対応関係を管理する第２管理部と、
前記第２ボリュームへのデータ更新の際に、この更新データに前記上位装置により指定された保存期間を対応付けて管理する第３管理部と、
前記第２ボリュームに記憶されているデータのうち、前記保存期間の経過したデータを検出して前記第２ボリュームから消去するデータ消去部と、
前記第１管理部又は／及び前記第２管理部を用いることにより、前記上位装置からのアクセス要求を処理するアクセス処理部と、
を備えて構成されている、ストレージシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストレージ装置及びストレージ装置のデータライフサイクル管理方法に関する。
【背景技術】
【０００２】
ストレージ装置は、例えば、ハードディスクドライブや半導体メモリドライブ等の記憶デバイスを用いて、RAID（Redundant Array of Independent Disks）に基づく記憶領域を構築する。この物理的な記憶領域（論理ボリューム）は、例えば、サーバマシン等のホストコンピュータ（以下、ホスト）に提供される。ホスト上で稼働するアプリケーションプログラムは、論理ボリュームに対してデータを書き込んだり、論理ボリュームからデータを読み出すことにより、ホストに接続されたクライアント端末に対して情報処理サービスを提供する。
【０００３】
ストレージシステムが記憶すべきデータ量は、日々刻々増大し、また、データの種類によっては長期間の保存が義務づけられる場合もある。そこで、増大する需要に対応するために、大容量のディスクドライブと交換したり、あるいは、新型の高性能ストレージ装置を導入等する。
【０００４】
なお、各ストレージ装置がそれぞれ有する論理ボリュームを仮想化して仮想ボリュームを構成し、この仮想ボリュームを各ホストに提供できるようにした技術も知られている（特許文献１）。
【特許文献１】特開２００２−９１７０６
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のストレージシステムでは、記憶容量の増大や応答性を改善するために、新型のディスクドライブや新型のストレージ装置を必要に応じて導入する。しかし、アプリケーションプログラムの種類等によっても異なるが、データの利用価値（利用頻度）は、長期間にわたって一定ではなく、時間と共に低下していく。例えば、データベースの場合、ある月の月次集計表を構成するデータ群は、その月次集計表を作成する期間内だけ頻繁に利用され、その月次集計表が完成した後は、年次集計表の作成時期が到来するまで殆ど使用されることがなく、保存されたままとなる。また、例えば、メール管理プログラムの場合、電子メールのデータは、受信直後の比較的短い期間内だけ参照され、その電子メールへの返信が完了した後は、長期間使用されずに保存されたままとなる。
【０００６】
従って、応答性の良いディスクドライブから構成される高速なボリュームを導入した場合でも、運用を続ける間に、その高速ボリュームは、利用頻度の低下したデータ群で一杯になってしまう。一方、低速ボリュームに記憶されているデータが参照や更新される場合は、そのデータの読み出しや書込みに時間を要するため、応答性が低下する。
【０００７】
全てのボリュームを高速ボリュームから構成するのではコストが増大するため、高速ボリュームと低速ボリュームとを混在させて運用する必要がある。しかし、上述の通り、高速ボリュームもいずれは不要不急のデータで一杯になってしまうため、その高速性を長期間にわたって活かすことができない。
【０００８】
一方、データマイグレーションと呼ばれる技術も知られている。このデータマイグレーションでは、例えば、メインボリュームから別のボリュームに不要不急のデータを移動させて、メインボリュームの空き容量を確保する。この場合、ストレージ装置側では、例えば、どのデータがどのファイルに対応するのか、どのファイルの使用頻度が低いのか等について把握することができないため、ホスト側からの指示に基づいてデータマイグレーションが行われる。
【０００９】
従って、ホスト側で各ファイルの使用頻度を把握し、このファイルを現在のボリュームから別のボリュームに移動させる必要があり、ホスト側の処理負荷が増大し、使い勝手が低い。例えば、ユーザは、移動対象のファイルを特定して、データ移動を指示しなければならない。また、例えば、ホストは、移動対象のファイルを現在のボリュームから読出して、この読出したファイルを別のボリュームに書き込む必要があり、データ入出力のネットワークの負荷が増す。
【００１０】
そこで、本発明の一つの目的は、異種類のボリュームが混在する環境下で、利用頻度に応じてデータの格納位置を制御できるようにしたストレージ装置及びストレージ装置のデータライフサイクル管理方法を提供することにある。本発明の一つの目的は、高速ボリュームの応答性を生かしつつ、利用頻度に応じてデータを配置することができるストレージ装置及びストレージ装置のデータライフサイクル管理方法を提供することにある。本発明の一つの目的は、高速ボリュームと低速ボリュームとが混在する環境下で、高速ボリュームの高速応答性を維持し、記憶資源を効率的に使用することができるストレージ装置及びストレージ装置のデータライフサイクル管理方法を提供することにある。本発明のさらなる目的は、後述する実施形態の記載から明らかになるであろう。
【課題を解決するための手段】
【００１１】
上記課題を解決すべく、本発明のストレージ装置は、上位装置により利用されるデータを記憶する第１ボリュームと、第１ボリュームに記憶されるデータのうち一部のデータを記憶する第２ボリュームと、第２ボリュームに記憶されているデータを管理するための第１管理部と、第２ボリュームに記憶されているデータと第１ボリュームに記憶されているデータとの対応関係を管理する第２管理部と、第２ボリュームに記憶されているデータの保存期間を管理する第３管理部と、第２ボリュームに記憶されているデータのうち、保存期間の経過したデータを検出して第２ボリュームから消去するデータ消去部と、第１管理部又は／及び第２管理部を用いることにより、上位装置からのアクセス要求を処理するアクセス処理部と、を備えている。
【００１２】
第１ボリュームには、上位装置により利用される全てのデータを記憶させることができ、第２ボリュームには、第１ボリュームに記憶されるデータのうち一部のデータを記憶させることができる。但し、ある時点では、第２ボリュームにのみ記憶され、第１ボリュームには記憶されていないデータが存在する場合もある。第２ボリュームに記憶されたデータは、所定のタイミングで第１ボリュームにも記憶される。従って、第２ボリュームには、第１ボリュームに記憶されたデータ、または、第１ボリュームに記憶されるデータの一部が記憶されている。
【００１３】
第１ボリュームは相対的に低速なボリュームとして、第２ボリュームは相対的に高速なボリュームとして構成することもできる。つまり、上位装置により利用される全てのデータは、低速な第１ボリュームに記憶されるが、このうち一部のデータは高速な第２ボリュームにも保持される。
【００１４】
アクセス処理部は、上位装置からのアクセス要求が対象とするデータが、第１ボリューム及び第２ボリュームの両方に記憶されている場合、第２ボリュームを用いてアクセス要求を処理することができる。これにより、第２ボリュームが高速ボリュームである場合、上位装置への応答性を高めることができる。
【００１５】
第１ボリュームと第２ボリュームとを含んで仮想化された仮想ボリュームが上位装置に提供され、かつ、仮想ボリュームは第１ボリュームと同一の記憶容量を有しており、上位装置は、仮想ボリュームに対してアクセス要求を行うことができる。
【００１６】
仮想ボリュームとは、第１ボリュームと第２ボリュームとを含んで仮想化されたボリュームであり、第１ボリュームと同一サイズの記憶空間を有している。即ち、仮想ボリュームは、第１ボリュームに格納されるデータと、第２ボリュームに期限付きで格納されるデータとが融合して構成されるもので、上位装置は、仮想ボリュームに対してデータの読み書きを行うことができる。上位装置により仮想ボリュームに書き込まれたデータは、第１ボリュームに記憶されると共に、そのデータに設定された保存期間だけ第２ボリュームにも記憶される。
【００１７】
アクセス処理部は、上位装置から仮想ボリュームにデータが書き込まれる場合、仮想ボリュームにおける格納位置と同一の格納位置で第１ボリュームにデータを書込み、仮想ボリュームにおける格納位置と異なる格納位置で第２ボリュームにデータを書き込むこともできる。
【００１８】
即ち、第１ボリュームと仮想ボリュームとは同一の記憶空間を有しており、仮想ボリュームを対象として書き込まれたデータは、仮想ボリューム上での格納位置と同一の格納位置で第１ボリュームに記憶される。一方、仮想ボリュームと第２ボリュームとは記憶空間が一致する必要はなく、仮想ボリュームと第２ボリュームとでそれぞれデータの格納位置が異なってもよい。これにより、仮想ボリュームよりも少ない記憶容量の第２ボリュームを用いて、比較的新しいデータのみを第２ボリュームに保持させることができる。
【００１９】
第３管理部は、第２ボリュームへのデータ更新の際に、この更新データに保存期間を対応付けて管理することができる。ここで、保存期間は、例えば、１２時間、１日間、３日間、１週間、１ヶ月間、６ヶ月間、１年間等のように段階的に設定可能である。
【００２０】
保存期間は、ＬＵ（Logical Unit）単位で予め設定することもできるし、ＬＵに対応付けられる論理ボリューム単位で設定することもできる。即ち、例えば、各仮想ボリューム毎に、または各仮想ボリュームをそれぞれ構成する各論理ボリューム毎に、予め保存期間を設定しておき、そのボリュームに書き込まれたデータについては、一律に保存期間を対応付けることができる。このように、各データの保存期間は、上位装置を介さずに、ストレージ装置側で全て管理可能である。
【００２１】
一方、保存期間は、上位装置によって所定の単位毎に設定することもできる。この場合、第３管理部は、上位装置により指示された保存期間を管理する。そして、上位装置は、ファイル単位又はディレクトリ単位のいずれか又は双方で、保存期間を設定することもできる。例えば、上位装置は、保存期間を含むライトコマンドを発行することにより、所定の単位毎に保存期間を設定し、第３管理部は、このライトコマンドによって書き込まれるデータに、このライトコマンドに含まれている保存期間を対応付けて管理する。このように、保存期間の設定は上位装置側で行い、保存期間に応じたデータ移動はストレージ装置側で行うことにより、上位装置とストレージ装置とで作業を分担することもできる。
【００２２】
データ消去部は、消去対象のデータが第１ボリュームに記憶されていることを確認し、消去対象のデータが第１ボリュームに記憶されていない場合、この消去対象のデータを第１ボリュームに記憶させてから、この消去対象のデータを第２ボリュームから消去することができる。即ち、第２ボリュームにのみ記憶されているデータを誤って消去することがないように、データ消去部は、消去対象のデータが第１ボリュームに記憶されていることを確認し、第１ボリュームに記憶されていない場合は、消去対象のデータを第２ボリュームから第１ボリュームにコピーさせた後で、消去対象のデータを消去する。
【００２３】
上位装置から書き込まれるデータを一時的に記憶するキャッシュメモリをさらに備える場合、アクセス処理部は、キャッシュメモリに所定の空き容量が存在しない場合、上位装置からのデータを第２ボリュームに記憶させる。
【００２４】
第１ボリュームまたは第２ボリュームのいずれか又は両方は、外部に設けられた他のストレージ装置が有する外部ボリュームに対応付けることができ、第１ボリュームまたは第２ボリュームを対象とする書込みデータは、外部ボリュームに記憶させてもよい。即ち、外部の他のストレージ装置が有する外部ボリュームをあたかも自己の支配する内部ボリュームであるかのように使用することもできる。第１ボリューム及び第２ボリュームの両方を、外部ボリュームから構成する場合、ストレージ装置は、ボリュームへのアクセス等を制御する機能のみを備えていれば足りる。従って、この場合、ストレージ装置は、ストレージ装置として構成される必要はなく、例えば、高機能化されたスイッチ等として構成することも可能である。
【００２５】
第１ボリュームは複数設けることができ、これら複数の第１ボリュームに対して単一の第２ボリュームをそれぞれ対応付けることもできる。つまり、例えば、一つの第２ボリュームによって、複数の第１ボリュームにそれぞれ書き込まれるデータのうち比較的新しいデータのみを保持することができる。なお、各第１ボリューム毎にそれぞれ独立した第２ボリュームを対応付ける構成としてもよい。
【００２６】
本発明の機能、手段、ステップの全部または一部は、例えば、マイクロコンピュータにより実行されるコンピュータプログラムとして構成可能な場合がある。そして、このコンピュータプログラムは、例えば、ハードディスク、光ディスク、半導体メモリ等の記憶媒体に固定して配布することができる。または、コンピュータプログラムをインターネット等の通信ネットワークを介して、配信することもできる。
【発明を実施するための最良の形態】
【００２７】
以下、図面に基づき、本発明の実施の形態を説明する。図１は、本実施形態の全体概念図である。詳細はさらに後述するが、図１に示すように、本実施形態のストレージ装置１は、例えば、FC_SAN（Fibre Channel_Storage Area Network）等のような通信ネットワークを介して、ホスト２に接続されている。ホスト２のアプリケーションプログラム（以下、アプリケーションと略記）２Ａは、ストレージ装置１に対してデータを読み書きすることにより、図外のクライアント端末に対して所定の情報処理サービスを提供する。
【００２８】
ストレージ装置１は、制御部３と、第１のボリュームに該当する低速ボリューム４と、第２のボリュームに該当する高速ボリューム５とを備えており、制御部３は、メモリ６を備えている。
【００２９】
低速ボリューム４は、例えば、SATA（Serial AT Attachment）ディスクやSCSI（Small Computer System Interface）ディスク等から構成可能である。高速ボリューム５は、例えば、ＦＣディスク（ファイバチャネルディスク）から構成可能である。一般的には、ＦＣディスク、SCSIディスク、SATAディスクの順番で、性能及びコストが低下する。なお、SAS（Serial Attached SCSI）ディスクを用いることもできる。また、ディスクとしてはこれらに限らず、FCディスク、SCSIディスク、SATAディスク、SASディスク等の均等物及び将来開発されるであろう記憶デバイスを利用することができる。例えば、ハードディスクドライブに限らず、半導体メモリドライブや光ディスクドライブ等を用いて、低速ボリューム４及び高速ボリューム５をそれぞれ構成できる場合もある。
【００３０】
低速ボリューム４は、ホスト２によって利用される全てのデータを保持し、高速ボリューム５は、低速ボリューム４に記憶されるデータのうち比較的新しい一部のデータのみを記憶する。後述のように、高速ボリューム５に記憶されるデータには、予め保存期間（ライフタグ）が設定されており、保存期間が経過したデータは高速ボリューム５から消去される。従って、高速ボリューム５から消去されたデータは、低速ボリューム４のみに存在することになる。
【００３１】
制御部３は、ホスト２からのデータアクセス要求を処理し、ストレージ装置１の全体動作を制御するものである。制御部３は、複数の制御パッケージを連携させて構成することもできるし、単一のコントローラとして構成することもできる。
【００３２】
制御部３のメモリ６には、更新ビットマップテーブル６Ａと、ライフタグ管理テーブル６Ｂとが記憶されている。また、メモリ６の記憶空間には、仮想ボリューム７が構築されている。仮想ボリューム７は、メモリ６の記憶空間に形成されるもので、低速ボリューム４と同一サイズの記憶容量を備えている。仮想ボリューム７の実体は、低速ボリューム４及び高速ボリューム５である。
【００３３】
更新ビットマップテーブル６Ａは、仮想ボリューム７の記憶空間に記憶されるデータが、高速ボリューム５上に存在するか否かを管理するための管理情報である。ライフタグ管理テーブル６Ｂは、仮想ボリューム７に予め設定されている保存期間（ライフタグ）を管理するための管理情報である。ライフタグとは、高速ボリューム５にそのデータを保持すべき期間を示す情報であり、例えば、１日間、１週間、１ヶ月等のように、各仮想ボリューム７毎に段階的に設定することができる。つまり、ある仮想ボリューム７に記憶されるデータは、１日間だけ高速ボリューム５上に保持させ、別の仮想ボリューム７に記憶されるデータは、１週間だけ高速ボリューム５上に保持させることができる。図１中は、説明の便宜上、一つの仮想ボリューム７のみを示しているが、ストレージ装置１は、複数の仮想ボリューム７を備えることができる。
【００３４】
高速ボリューム５には、データの他に、更新セグメント管理テーブル８を記憶させることができる。更新セグメント管理テーブル８は、例えば、ホスト２によって更新された高速ボリューム５上のセグメント（データ記憶の単位）位置と、この更新セグメントに対応するデータを記憶する低速ボリューム４上のセグメント位置と、更新日時、高速ボリューム５上での保存期間（ライフタグ）等を対応付けることにより、構成可能である。なお、これらのデータは、１つのテーブルで管理される必要はなく、複数のテーブルを連携させて管理してもよい。また、更新セグメント管理テーブル８の全部または一部は、メモリ６に記憶させることもできる。
【００３５】
次に、本実施形態の動作を説明する。まず、ストレージ装置１は、ホスト２に対して、仮想ボリューム７を提供している。ホスト２は、仮想ボリューム７を物理的なディスクとして認識する。ホスト２のアプリケーション２Ａは、仮想ボリューム７に対してライトコマンドを発行する（Ｓ１）。
【００３６】
ストレージ装置１の制御部３は、ホスト２からのライトコマンドを受領すると、ホスト２から送信されたライトデータをメモリ６に一時的に記憶し、書込み完了をホスト２に応答する。制御部３は、最初に、ライトデータを高速ボリューム５に書込み（Ｓ２）、次に、所定のタイミングを見計らって、このライトデータを低速ボリューム４にも書き込む（Ｓ３）。ここで、低速ボリューム４には、仮想ボリューム７上の位置と同一の位置にライトデータが書き込まれる。高速ボリューム５には、仮想ボリューム７上の位置と無関係にライトデータが書き込まれる。
【００３７】
高速ボリューム５にライトデータが書き込まれると、更新ビットマップテーブル６Ａは、このライトデータにより更新されたセグメントについて、フラグをセットする。このフラグは、そのセグメントのデータが高速ボリューム５上の所定の位置に存在することを示す情報である。高速ボリューム５内の更新セグメント管理テーブル８には、ライトデータを格納したセグメントと、そのライトデータに対応付けられたライフタグとがそれぞれ登録される。
【００３８】
制御部３は、更新セグメント管理テーブル８を定期的に参照し、高速ボリューム５に記憶されているデータのうち、保存期間の切れたデータを検出する。そして、制御部３は、保存期間の経過したデータを高速ボリューム５から消去する（Ｓ４）。なお、データは、物理的に消去される必要はなく、論理的に無効にすれば足りる。即ち、更新ビットマップテーブル６Ａで管理されているセグメントを無効化し、上書きを許可することにより、そのセグメントを別の新たなライトデータの格納に用いることができる。
【００３９】
以上の通り、本実施形態によれば、ホスト２からのライトデータを、予め設定された保存期間だけ高速ボリューム５に保持させることができ、保存期間の経過したデータは高速ボリューム５から消去して低速ボリューム４にのみ記憶させることができる。つまり、ライトデータを受信してから保存期間が経過するまでの間、このライトデータは低速ボリューム４及び高速ボリューム５の両方にそれぞれ記憶され、保存期間の経過後は、低速ボリューム４にのみ記憶される。
【００４０】
従って、高速ボリューム５には、利用頻度が高いデータのみを記憶することができ、利用頻度の高いデータについての応答性を改善することができる。また、ライトデータを低速ボリューム４及び高速ボリューム５の両方に書込み、利用頻度の低いデータは、保存期間の経過後に高速ボリューム５から消去するため、利用頻度の低いデータを低速ボリューム４のみに配置する手間がかからない。
【００４１】
さらに、ストレージ装置１内で、データのライフサイクルを管理することができるため、ホスト２側に新たなソフトウェア等を搭載する必要がない。そして、ユーザは、利用頻度を確認して移動対象のデータを選択し、選択したデータを別のボリュームに移動させるという指示を出す必要がなく、簡易かつ有効なデータライフサイクル管理を実現することができる。以下、本実施形態をより詳細に説明する。
【実施例１】
【００４２】
図２は、ストレージ装置１００を含むストレージシステムの全体概要を示すブロック図である。このストレージシステムは、それぞれ後述するように、例えば、少なくとも一つ以上のホスト１０と、一つまたは複数のストレージ装置１００，２００とを備えて構成することができる。
【００４３】
ホスト１０は、例えば、いわゆるオープン系ホストとメインフレーム系ホストとに大別できる。オープン系ホストとしては、例えば、Windows（登録商標）やUNIX（登録商標）等の汎用的なOS（Operating System）を搭載し、ＦＣ（Fibre Channel）、iSCSI（Internet SCSI）、TCP/IP（Transmission Control Protocol/Internet Protocol）等の比較的汎用性のある通信プロトコルを介してストレージ装置１００にアクセスするサーバマシンを挙げることができる。メインフレーム系ホストとしては、例えば、FICON（Fibre Connection：登録商標）、ESCON（Enterprise System Connection：登録商標）、ACONARC（Advanced Connection Architecture：登録商標）、FIBARC（Fibre Connection Architecture：登録商標）等の通信プロトコルを介してストレージ装置１００にアクセスするメインフレームマシンを挙げることができる。
【００４４】
ホスト１０は、例えば、メタルケーブルや光ファイバケーブル、スイッチ等を含むことができる通信ネットワークＣＮ１を介して、ストレージ装置１００に接続される。ホスト１０は、例えば、一つまたは複数のHBA（Host Bus Adapter）１１と、入出力（Ｉ／Ｏ）制御プログラム１２と、アプリケーションプログラム群（図中、「アプリケーション群」と略記）１３とを備えて構成可能である。図１中では、説明の便宜上、一つのホスト１０のみを示しているが、複数のホスト１０を設けることもできる。また、オープン系ホストとメインフレーム系ホストとが混在してもよい。
【００４５】
ここで、各HBA１１は、所定のプロトコルに基づいてデータの送受信をそれぞれ行うものである。Ｉ／Ｏ制御プログラム１２は、例えば、ＨＢＡ１１を用いて行われるデータ入出力を制御するドライバプログラムである。アプリケーションプログラム群１３は、例えば、電子メール処理プログラムやデータベース管理ソフトウェアあるいはファイルシステム等のようなプログラムであり、図外のクライアント端末に対し、所定の情報処理サービスをそれぞれ提供する。
【００４６】
管理端末２０は、後述のサービスプロセッサ（SVP）１８０を介して、ストレージ装置１００の各種情報を収集したり、ストレージ装置１００に必要な指令を与えるための装置である。管理端末２０は、例えば、LAN（Local Area Network）等の通信ネットワークＣＮ２を介して、SVP１８０に接続されている。管理端末２０は、例えば、ウェブブラウザをベースとしたGUI（Graphical User Interface）を備えており、SVP１８０が提供するWWW（World Wide Web）サーバにログインすることにより、各種情報の収集と指令の入力とを行う。本実施例では、例えば、管理端末２０を介して、ライフタグの設定作業が行われる。なお、管理端末２０を介して管理する場合に限らず、ホスト１０から管理することもできる。
【００４７】
ストレージ装置１００は、例えば、複数のCHA１１０と、複数のDKA１２０と、キャッシュメモリ１３０と、共有メモリ１４０と、接続制御部１５０と、記憶部１６０と、SVP１８０とを備えて構成することができる。
【００４８】
ストレージ装置１００には、複数のCHA１１０を設けることができる。各CHA１１０は、各ホスト１０との間のデータ転送を制御する制御パッケージである。各CHA１１０は、複数の通信ポート１１１を備えており、少なくとも一つ以上のホスト１０と接続可能である。各CHA１１０は、複数のホスト１０との間のデータ転送をそれぞれ個別に制御することができる。また、一つのCHA１１０は、外部に位置する第２ストレージ装置２００との間のデータ通信を制御する。
【００４９】
ストレージ装置１００には、複数のDKA１２０を設けることができる。各DKA１２０は、記憶部１６０とのデータ転送をそれぞれ制御するものである。各DKA１２０は、例えば、ホスト１０から指定された論理ブロックアドレス（LBA）を物理ディスクのアドレスに変換等することにより、各ディスクドライブ１７１にアクセスし、データの読出しまたはデータの書込みを行う。
【００５０】
キャッシュメモリ１３０は、ホスト１０から書き込まれたライトデータや、ホスト１０に読み出されたリードデータを記憶するものである。キャッシュメモリ１３０は、例えば、揮発または不揮発のメモリから構成可能である。キャッシュメモリ１３０が揮発性メモリを含んで構成される場合、図示せぬバッテリ電源等によりメモリバックアップを行うことが好ましい。
【００５１】
キャッシュメモリ１３０は、例えば、リードキャッシュ領域とライトキャッシュ領域との２つの領域から構成することができる。ライトキャッシュ領域は、例えば、キャッシュ面とNVS（Non-volatile Storage）面とを含んでおり、ライトデータを多重記憶（冗長記憶）することができる。
【００５２】
共有メモリ（あるいは制御メモリとも呼ばれる）１４０は、例えば、不揮発メモリから構成可能であるが、揮発メモリから構成してもよい。共有メモリ１４０には、例えば、制御情報や管理情報等が記憶される。これらの制御情報等の情報は、複数のメモリ１４０により多重管理することができる。
【００５３】
共有メモリ１４０及びキャッシュメモリ１３０は、それぞれ別々のメモリパッケージとして構成することもできるし、同一のメモリパッケージ内にキャッシュメモリ１３０及び共有メモリ１４０を設けてもよい。また、メモリの一部をキャッシュ領域として使用し、他の一部を制御領域として使用することもできる。つまり、共有メモリとキャッシュメモリとは、同一のメモリまたはメモリ群として構成することもできる。
【００５４】
接続制御部１５０は、各CHA１１０と、各DKA１２０と、キャッシュメモリ１３０と、共有メモリ１４０とをそれぞれ相互に接続するものである。これにより、全てのCHA１１０，DKA１２０は、キャッシュメモリ１３０及び共有メモリ１４０にそれぞれ個別にアクセス可能である。接続制御部１５０は、例えば、超高速クロスバスイッチ等として構成することができる。
【００５５】
なお、後述のように、CHA１１０，DKA１２０，キャッシュメモリ１３０及び共有メモリ１４０を一つまたは複数のコントローラに集約することもできる。
【００５６】
記憶部１６０は、多数のディスクドライブ１７１を備えて構成される。記憶部１６０は、各CHA１１０及び各DKA１２０等のコントローラ部分と共に同一の筐体内に設けることもできるし、コントローラ部分とは別の筐体内に設けることもできる。
【００５７】
記憶部１６０は、例えば、複数種類のディスクドライブ１７１を混在させて構成することができる。ディスクドライブ１７１としては、例えば、ＦＣディスク（ファイバチャネルディスク）、SCSI（Small Computer System Interface）ディスク、SATA（Serial AT Attachment）ディスク等を用いることができる。なお、ディスクの種類は、上記のものに限定されず、例示したディスクドライブと同等の記憶デバイスまたは将来開発されるであろう記憶デバイスを利用可能な場合もある。
【００５８】
記憶部１６０には、複数のパリティグループ（RAIDグループとも呼ばれる）１７２を設けることができる。各パリティグループ１７２は、同一種類の物理ディスク１７１からそれぞれ構成される。即ち、あるパリティグループ１７２は、ＦＣディスクのみから構成され、他のパリティグループ１７２は、SATAディスクのみから構成される。
【００５９】
そして、詳細はさらに後述するが、各パリティグループ１７２がそれぞれ提供する論理的な記憶領域には、少なくとも一つ以上の論理ボリューム（LDEVとも呼ぶ）１７３を設けることができる。この論理ボリューム１７３をＬＵ（Logical Unit）１７４に対応付けることにより、オープン系のホスト１０は、そのボリュームを物理的な記憶デバイスとして認識し、利用することができる。なお、オープン系ホスト１０のアクセス対象ボリュームはＬＵであるが、メインフレーム系ホストのアクセス対象は、論理ボリューム（LDEV）となる。
【００６０】
ところで、ストレージ装置１００が使用する記憶資源は、全てストレージ装置１００内に存在する必要はない。後述のように、ストレージ装置（第１ストレージ装置と呼ぶこともできる）１００は、ストレージ装置１００の外部に存在する第２ストレージ装置２００の記憶資源を、あたかも自己の記憶資源であるかのように取り込んで、利用することもできる。
【００６１】
SVP１８０は、LAN等の内部ネットワークＣＮ３を介して、例えば、各CHA１１０及び各DKA１２０とそれぞれ接続されている。SVP１８０は、ストレージ装置１００内部の各種状態を収集し、そのままで又は加工して、管理端末２０に提供する。また、SVP１８０は、管理端末２０から入力されたデータを共有メモリ１４０内の各種テーブルＴに登録させることもできる。
【００６２】
第２ストレージ装置２００は、例えば、コントローラ２１０と、ディスクドライブ２２０とを備えて構成することができる。コントローラ２１０は、外部装置（ホスト１０及びストレージ装置１００）との間のデータ授受と、ディスクドライブ２２０とのデータ授受とをそれぞれ制御する。第２ストレージ装置２００は、ストレージ装置１００とほぼ同一の構成を備えてもよいし、ストレージ装置１００と異なる構成でもよい。
【００６３】
第２ストレージ装置２００は、例えば、SAN（Storage Area Network）等の通信ネットワークＣＮ４を介して、ストレージ装置１００と直接的に接続されている。具体的には、図３に示すように、ストレージ装置１００の外部接続用ポート１１１Ｂと第２ストレージ装置２００のターゲットポート２１１とは、通信ネットワークＣＮ４を介して、双方向のデータ通信が可能に接続されている。そして、第２ストレージ装置２００は、ストレージ装置１００からのリード要求またはライト要求に応じて、ディスクドライブ２２０へのデータの読書きを行う。
【００６４】
図３は、ストレージ装置１００の記憶構造に着目した構成説明図である。ストレージ装置１００の記憶構造は、物理的なディスクであるPDEV（Physical Device）１７１と、グループ化された複数のPDEV１７１が提供する仮想的な記憶領域であるVDEV（Virtual Device）１７２と、このVDEV１７２に設定されたLDEV（Logical Device）１７３とから構成することができる。ここで、PDEV１７１は、図２中のディスクドライブ１７１に対応し、VDEV１７２は、図２中のパリティグループ１７２に対応する。
【００６５】
ここで、幾つかの論理ボリューム（LDEV）には、LUN（Logical Unit Number ）がそれぞれ割り当てられており、オープン系ホスト１０からＬＵ１７４として認識される。ホスト１０は、ターゲットポート１１１Ａを介して、アクセス権限のある論理ボリューム（ＬＵ１７４）にそれぞれアクセスする。ターゲットポート１１１Ａは、図２中の各CHA１１０が提供する通信ポート１１１に対応する。
【００６６】
VDEV１７２には、それぞれ複数のLDEV１７３を設けることができる。一つのLDEV１７３を一つのＬＵ１７４に対応付けることもできるし、複数のLDEV１７３を一つのＬＵ１７４に対応付けることもできる。また、それぞれ別々のVDEV１７２に設けられた複数のLDEV１７３を一つのＬＵ１７４に対応付けることもできる。
【００６７】
図３中右側に示すVDEV「＃０」及びVDEV「＃１」は、仮想的な中間デバイスであり、実記憶領域は第２ストレージ装置２００内に存在する。つまり、第２ストレージ装置２００の記憶構造も、PDEV２２０と、VDEV２３０と、LDEV２４０とを備えて構成可能であり、LDEV２４０はＬＵ２５０に対応付けられている。この第２ストレージ装置２００の有する実ボリュームとしてのLDEV「＃０」，「＃１」は、ストレージ装置１００の仮想的な中間デバイスVDEV「＃０」，「＃１」にそれぞれ対応付けられている。
【００６８】
ストレージ装置１００が備えるディスクドライブ１７１は、例えば、高速なＦＣディスクから構成することができ、第２ストレージ装置２００が備えるディスクドライブ２２０は、例えば低速なSATAディスクから構成することができる。従って、ストレージ装置１００内で生成されるボリュームは、高速なボリュームとなり、第２ストレージ装置２００の有するボリュームは、低速なボリュームとなる。
【００６９】
本実施例では、ストレージ装置１００内の高速であるが高価なボリュームと、第２ストレージ装置２００内の低価であるが低速なボリュームとを有効に利用して、データの最適配置を可能とする。なお、ストレージ装置１００内に高速ボリューム及び低速ボリュームの両方を備える構成でもよく、あるいは、高速ボリューム及び低速ボリュームの両方をストレージ装置１００の外部に設ける構成でもよい。
【００７０】
図４は、ストレージ装置１００の主要な構成に着目した概略構成図である。ストレージ装置１００のコントローラ１０１は、各CHA１１０及び各DKA１２０がそれぞれ有する制御機能を集約したものである。コントローラ１０１は、ストレージ装置１００内の全体動作を制御する。コントローラ１０１は、例えば、CPU１０２と、タイマ１０３と、キャッシュメモリ１３０及び共有メモリ１４０を備えることができる。なお、図４中では、説明の便宜上、キャッシュメモリ１３０と共有メモリ１４０とを区別せずに、メモリ１３０／１４０として示してある。
【００７１】
メモリ１３０／１４０上には、例えば、マッピングテーブルＴ１と、ライフタグ設定テーブルＴ２と、ライフタグ定義テーブルＴ３と、更新ビットマップテーブルＴ４とをそれぞれ記憶させることができる。マッピングテーブルＴ１は、各ＬＵ（後述の仮想ボリューム）への実ボリュームの対応付けを管理するテーブルである。ライフタグ設定テーブルＴ２は、各ＬＵ毎にデータの保存期間を示すライフタグを設定するためのテーブルである。ライフタグ定義テーブルＴ３は、設定されたライフタグの示す期間を定義するためのテーブルである。更新ビットマップテーブルＴ４は、各ＬＵ毎にそれぞれ設けられるもので、どのデータが高速なＦＣボリューム３２０に記憶されているか等を示すテーブルである。なお、各テーブルＴ１〜Ｔ４の詳細は、さらに後述する。
【００７２】
メモリ１３０／１４０には、複数の仮想ボリューム３１０，３１１を構築することができる。メモリ１３０／１４０（特に例えば、キャッシュメモリ１３０）の記憶空間は、所定量のセグメントに分割して管理されており、多数のセグメントから各仮想ボリューム３１０，３１１がそれぞれ構成されている。各仮想ボリューム３１０，３１１は、第２ストレージ装置２００が提供する低速なSATAボリューム３３０，３３１とそれぞれ同一の記憶容量を備える。これらのSATAボリューム３３０，３３１は、図３中の各LDEV２４０「＃０」，「＃１」にそれぞれ対応する。
【００７３】
ストレージ装置１００は、ＦＣボリューム３２０を備えている。このＦＣボリューム３２０は、図３中のLDEV１７２「＃２」に対応する。ＦＣボリューム３２０は、複数の仮想ボリューム３１０，３１１にそれぞれ対応付けられている。ＦＣボリューム３２０には、データ記憶領域（図４中「更新セグメント」と表示）に加えて、更新セグメント管理テーブルＴ５が記憶されている。更新セグメント管理テーブルＴ５の詳細は後述するが、ＦＣボリューム３２０に記憶されているデータとSATAボリューム３３０，３３１に記憶されているデータとの対応関係及び保存期間等を管理するテーブルである。
【００７４】
図４では、ホスト１０Ａのファイルシステム１３Ａが第１の仮想ボリューム３１０を利用し、ホスト１０ＢのDBMS（DataBase Management System）１３Ｂが第２の仮想ボリューム３１１を利用しているものとする。そして、上述のように、第１の仮想ボリューム３１０は、第１のSATAボリューム３３０及びＦＣボリューム３２０から構成され、第２の仮想ボリューム３１１は、第２のSATAボリューム３３１及びＦＣボリューム３２０から構成されている。
【００７５】
詳細な動作についてはさらに後述するが、ホスト１０Ａ，１０Ｂが各仮想ボリューム３１０，３１１にデータを書き込む場合、このライトデータはメモリ１３０／１４０（特に例えばキャッシュメモリ１３０）に一時的に保持された後、ＦＣボリューム３２０に書き込まれる。そして、ストレージ装置１００の負荷等を考慮して、所定のタイミングを見計らって、ライトデータはSATAボリューム３３０，３３１にも書き込まれる。ここで、仮想ボリューム３１０，３１１における書込み位置と、SATAボリューム３３０，３３１における書込み位置とは同一である。
【００７６】
ＦＣボリューム３２０に記憶されたデータは、各仮想ボリューム３１０，３１１毎に予め設定されている保存期間が経過するまで、ＦＣボリューム３２０上に存在する。保存期間の経過したデータは、ＦＣボリューム３２０から消去され、SATAボリューム３３０，３３１にのみ存在するようになる。
【００７７】
ホスト１０Ａ，１０Ｂには、ＦＣボリューム３２０内に記憶されたデータが優先して提供され、所望のデータがＦＣボリューム３２０に記憶されていない場合にのみ、SATAボリューム３３０，３３１から所望のデータが読み出されてホスト１０Ａ，１０Ｂに提供される。これにより、ホスト１０Ａ，１０Ｂは、主に、高速なＦＣボリューム３２０を利用してデータの読み書きを行うことができる。
【００７８】
図５は、マッピングテーブルＴ１の構成例を示す説明図である。マッピングテーブルＴ１は、例えば、共有メモリ１４０に記憶させることができる。また、後述の各テーブルについても同様であるが、マッピングテーブルＴ１の全部または一部は、各CHA１１０内のローカルメモリにコピーすることもできる。
【００７９】
マッピングテーブルＴ１は、例えば、LUNと、そのLUNに対応付けられるLDEV番号及びLDEVサイズ（スロット数）と、そのLDEVに対応付けられるVDEV番号及びVDEVサイズと、そのVDEVのデバイス種別と、そのVDEVが形成されるディスクドライブへのパス情報とを対応付けることにより、構成することができる。図５に示すように、外部の第２ストレージ装置２００のボリュームを取り込んで使用する場合、パス情報には、第２ストレージ装置２００のボリュームにアクセスするためのパスが設定される。また、ストレージ装置１００内のボリューム（実施例では、ＦＣボリューム３２０）を使用する場合、その内部ボリュームへアクセスするための情報が設定される。
【００８０】
図６は、ライフタグ設定テーブルＴ２及びライフタグ定義テーブルＴ３の構成例をそれぞれ示す説明図である。これら各テーブルＴ２，Ｔ３は、例えば、共有メモリ１４０に記憶させることができる。ライフタグ設定テーブルＴ２では、例えば、LUNとライフタグとが対応付けられている。各LUN毎に、即ち、各仮想ボリューム３１０，３１１毎にそれぞれ異なるライフタグを設定可能である。ライフタグには、例えば、０，１，２，３等のように、複数のレベルが存在する。
【００８１】
ライフタグ定義テーブルＴ３は、例えば、各ライフタグのレベル毎に、具体的な保存期間を定義する。例えば、ライフタグが「０」の場合は１日間、ライフタグが「１」の場合は３日間、ライフタグが「２」の場合は７日間、ライフタグが「３」の場合は３０日間等のように、ライフタグのレベル毎に保存期間がそれぞれ定義されている。ライフタグ設定及びライフタグ定義は、ユーザが管理端末２０を介してそれぞれ設定可能である。
【００８２】
図７は、更新ビットマップテーブルＴ４の構成例を示す説明図である。更新ビットマップテーブルＴ４は、例えば、各LUN毎に、即ち各仮想ボリューム３１０，３１１毎にそれぞれ設けられるもので、共有メモリ１４０に記憶させることができる。
【００８３】
各更新ビットマップテーブルＴ４は、例えば、キャッシュメモリ１３０上のセグメント番号と、ＦＣフラグと、ＦＣボリューム３２０上の更新セグメント番号とを対応付けることにより、構成することができる。
【００８４】
ここで、ＦＣフラグとは、そのセグメントのデータがＦＣボリューム３２０上に存在するか否かを示す情報であり、ＦＣフラグに「１」がセットされている場合は、そのセグメントのデータがＦＣボリューム３２０に記憶されていることを示す。ＦＣフラグに「０」がセットされている場合は、そのセグメントのデータがＦＣボリューム３２０上に存在しないことを示す。
【００８５】
セグメント番号は、キャッシュメモリ１３０上に構築された仮想ボリューム３１０，３１１におけるデータの格納位置を示す。上述のように、仮想ボリューム３１０，３１１におけるデータ格納位置と、各SATAボリューム３３０，３３１におけるデータ格納位置とは、同一である。更新セグメント番号とは、ＦＣボリューム３２０におけるデータの格納位置を示す。ＦＣボリューム３２０におけるデータ格納位置（更新セグメント番号）と、仮想ボリューム３１０，３１１におけるセグメント番号とは一致しない。ＦＣボリューム３２０の記憶領域を有効に使用するため、ＦＣボリューム３２０には、例えば、空いている更新セグメントに順番にデータが記憶されていく。
【００８６】
図８は、更新セグメント管理テーブルＴ５の構成及び更新セグメント管理テーブルＴ５等を用いて、保存期間の経過したデータをＦＣボリューム３２０から消去する様子を示す説明図である。
【００８７】
更新セグメント管理テーブルＴ５は、例えば、ＦＣボリューム３２０上の格納位置を示すセグメント番号（図７中の更新セグメント番号に対応）と、そのセグメントに記憶されたデータが属するLUN（仮想ボリューム番号）と、そのセグメントに記憶されたデータと同一のデータを記憶するSATAボリューム３３０，３３１上の格納位置を示す更新実セグメント番号（図７中のセグメント番号に対応）と、そのセグメントに記憶されたデータのライフタグレベル（保存期間）と、そのセグメントが更新された日時と、そのセグメントに記憶されているデータがSATAボリューム３３０，３３１にも記憶されているか否かを示すSATA更新ビットとを対応付けることにより、構成することができる。
【００８８】
更新日には、年月日の形式で設定する必要はなく、図８に示すように、タイマ１０３がカウントする値を設定すれば足りる。タイマ１０３は、１日毎に１つずつ値をインクリメントさせる。従って、タイマ１０３のカウント値同士を比較することにより、あるカウント値が記録された時点から何日間が経過したのかを求めることができる。なお、年月日形式で更新日を登録してもよい。
【００８９】
コントローラ１０１は、定期的にまたは不定期に、更新セグメント管理テーブルＴ５を参照し、ＦＣボリューム３２０の各セグメント（データの格納されたセグメントのみ）について、ライフタグの示す保存期間と現在までの経過時間とをそれぞれ比較する。この比較は、少なくとも一日一回行えばよい。なお、図８中の比較テーブルＴ６は、説明の便宜上示されたもので、比較テーブルＴ６を生成することなく、データのクリーニング処理を行うことができる。
【００９０】
例えば、更新セグメント管理テーブルＴ５を参照すると、ＦＣボリューム３２０のセグメント「＃０００１」に記憶されているデータは、仮想ボリューム３３０「＃０」に属するもので、ライフタグのレベルとして「１」が対応付けられている。ライフタグレベルが「１」の場合の保存期間は、３日間である。なお、このデータがＦＣボリューム３２０のセグメント「＃０００１」に格納されたとき、タイマ１０３のカウント値は「２５０」を示していたとする。
【００９１】
現在、タイマ１０３のカウント値が「２５４」を示しているとする。ＦＣボリューム３２０のセグメント番号「＃０００１」に記憶されているデータは、更新されてから既に４日が経過している。しかし、このデータの保存期間は、３日間に設定されている。そこで、コントローラ１０１は、更新ビットマップテーブルＴ４の更新セグメント（ＦＣボリューム上のセグメントに対応）を無効とし、上書きを許可する。これにより、保存期間の経過したデータを格納するセグメントには、別の新たなデータを格納可能となる。
【００９２】
図９は、更新処理の概略を示すフローチャートである。この処理は、例えば、CHA１１０によって実行されるが、以下の説明では、動作の主体をコントローラ１０１であるとして述べる。
【００９３】
コントローラ１０１は、ホスト１０からライトコマンドを受信すると（S11：YES）、キャッシュメモリ１３０にライトデータを格納するための空き容量が存在するか否かを判定する（Ｓ１２）。ライトデータの記憶に必要な空き容量が存在しない場合（S12：NO）、コントローラ１０１は、空き容量が形成されるまで、ホスト１０を待機させる。後述のディステージ処理で述べるように、キャッシュメモリ１３０に記憶されたデータは、順次ＦＣボリューム３２０に書き込まれていき、ＦＣボリューム３２０に書き込まれたデータは、キャッシュメモリ１３０から消去される。従って、ホスト１０に対しライトデータの送信を待機させている間に、キャッシュメモリ１３０上のデータはＦＣボリューム３２０に書き込まれていき、空き容量が増加してく。
【００９４】
そして、必要な空き容量が形成されると（S12：YES）、コントローラ１０１は、ホスト１０にライトデータの送信を許可し、ホスト１０から送信されたライトデータを受信する（Ｓ１３）。コントローラ１０１は、ホスト１０から受信したライトデータをキャッシュメモリ１３０に記憶させた後（Ｓ１４）、ホスト１０に対してライトコマンドの完了を通知する（Ｓ１５）。即ち、コントローラ１０１は、ライトデータをキャッシュメモリ１３０に冗長記憶させた時点で、ホスト１０にライトコマンドの完了を通知し、ライトデータのボリュームへの書込みは、別のタイミングで行う。このように、ライトデータをボリュームに書き込むタイミングとホスト１０へのコマンド完了を通知するタイミングとが同期していないモードを、非同期書込みモードと呼ぶことができる。非同期モードを採用することにより、ホスト１０を早期にデータ書込み処理から開放することができる。
【００９５】
図１０は、ディステージ処理の概略を示すフローチャートである。この処理は、例えば、DKA１２０によって実行することができるが、以下の説明では、動作の主体をコントローラ１０１であるとして述べる。
【００９６】
コントローラ１０１は、ライトコマンドに基づいて、ライトデータにより更新されるセグメントを特定する（Ｓ２１）。例えば、ライトデータが書き込まれるべきLUN（仮想ボリューム番号）と、ライトデータを格納すべきLBAとから、更新すべきセグメントを特定することができる。
【００９７】
コントローラ１０１は、ライトデータを書き込むべきＬＵ（仮想ボリューム）に対応付けられている更新ビットマップテーブルＴ４を参照し（Ｓ２２）、更新対象のセグメントのデータがＦＣボリューム３２０に存在するか否かを判定する（Ｓ２３）。
【００９８】
更新対象のセグメントのデータがＦＣボリューム３２０上に記憶されていない場合（S23：NO）、コントローラ１０１は、更新対象の仮想ボリュームに対応するSATAボリュームから旧データを読出し、この旧データとライトデータとを結合させて、更新対象のセグメントに格納すべき更新データを生成する（Ｓ２４）。
【００９９】
なお、旧データがキャッシュメモリ１３０上に記憶されている場合は、SATAボリュームから読み出す必要はなく、キャッシュメモリ１３０に記憶されているデータを用いればよい。通常の場合、更新処理を行うよりも前に、参照処理が実行されて旧データがキャッシュメモリ１３０上に読み出されるため、キャッシュヒットする可能性が高い。キャッシュメモリ１３０に旧データが記憶されている場合、低速なSATAボリュームにアクセスしてデータを読み出す必要がなく、応答性が向上する。
【０１００】
次に、コントローラ１０１は、ＦＣボリューム３２０において使用されていないセグメントを所定数確保し、更新データを格納すべき更新セグメントの番号を特定（確定）させる（Ｓ２５）。
【０１０１】
コントローラ１０１は、更新ビットマップテーブルＴ４に、特定された更新セグメントの番号を登録すると共に、その更新セグメントについてＦＣフラグを「１」にセットする（Ｓ２６）。続いて、コントローラ１０１は、更新ビットマップテーブルＴ４に登録された更新セグメントに更新データを格納し（Ｓ２７）、更新セグメント管理テーブルＴ５を更新させる（Ｓ２８）。
【０１０２】
一方、更新対象のセグメントのデータがＦＣボリューム３２０上に存在する場合（S23：YES）、コントローラ１０１は、更新対象のセグメント番号を特定し（Ｓ２９）、その特定されたセグメントに更新データを記憶する（Ｓ３０）。また、コントローラ１０１は、Ｓ３０において、そのセグメントの更新日を現在の日付（タイマ１０３の最新のカウント値）に書き直し、更新セグメント管理テーブルＴ５を更新させる（Ｓ２８）。
【０１０３】
以上のようにして、ホスト１０から受信したライトデータを高速なＦＣボリューム３２０に記憶させた後、コントローラ１０１は、SATAボリュームを更新可能であるか否かを判定する（Ｓ３１）。ＦＣボリューム３２０へのデータ書込みとSATAボリュームへのデータ書込みとを同時に実行することもできるし、タイミングをずらしてSATAボリュームにライトデータを書き込むこともできる。コントローラ１０１は、例えば、ストレージ装置１００の処理負荷が比較的少なくなったタイミングを見計らって、SATAボリュームを更新させることができる。
【０１０４】
SATAボリュームを更新可能な場合（S31：YES）、コントローラ１０１は、更新対象の仮想ボリュームに対応するSATAボリュームの所定の格納位置に、更新データを書込み（Ｓ３２）、このセグメントに対応するSATA更新ビットに「１」をセットして（Ｓ３３）、更新セグメント管理テーブルＴ５を更新させる。そして、コントローラ１０１は、キャッシュメモリ１３０上でライトデータが記憶されていた記憶領域を開放する（Ｓ３４）。これにより、そのライトデータが記憶されていた記憶領域には、別のデータを上書きすることができる。
【０１０５】
一方、ストレージ装置１００の処理負荷が重い等の理由によって、SATAボリュームの更新を行うことができない場合（S31：NO）、コントローラ１０１は、ＦＣボリューム３２０上で更新されたセグメントに対応するSATA更新ビットに「０」をセットし（Ｓ３５）、キャッシュメモリ１３０に記憶されているライトデータを消去し、その記憶領域を開放する（Ｓ３４）。
【０１０６】
以上のように、ディステージ処理では、ホスト１０から受信したライトデータが、まず最初に高速なＦＣボリューム３２０に格納され、ＦＣボリューム３２０への格納と略同時か、またはそれよりも遅れて、SATAボリュームにライトデータが格納される。そして、ＦＣボリューム３２０にライトデータを格納した場合、ライトデータをSATAボリュームに格納したか否かを問わず、キャッシュメモリ１３０上のライトデータを消去し、空き容量を生成する。
【０１０７】
図１１は、参照処理の概略を示すフローチャートである。コントローラ１０１は、ホスト１０からリードコマンドを受信すると（S41：YES）、リードコマンドを解析することにより、参照するセグメントを特定する（Ｓ４２）。参照セグメントは、例えば、参照対象のLUN（仮想ボリューム番号）と参照対象のセグメント番号とにより、特定することができる。
【０１０８】
コントローラ１０１は、参照対象の仮想ボリュームに対応付けられた更新ビットマップテーブルＴ４を参照し（Ｓ４３）、読出しが要求されたセグメントのデータがＦＣボリューム３２０上に存在するか否かを判定する（Ｓ４４）。ホスト１０から要求されたデータがＦＣボリューム３２０に記憶されている場合（S44：YES）、コントローラ１０１は、参照対象のセグメント番号を特定し（Ｓ４５）、ＦＣボリューム３２０のセグメントからデータを読み出す（Ｓ４７）。
【０１０９】
一方、後述のクリーニング処理の実行により、ホスト１０から要求されたデータがＦＣボリューム３２０に記憶されていない場合（S44：NO）、コントローラ１０１は、ホスト１０から要求されたデータをSATAボリュームから読み出す（Ｓ４７）。
【０１１０】
コントローラ１０１は、ＦＣボリューム３２０またはSATAボリュームのいずれか一方から読み出したデータを、キャッシュメモリ１３０に記憶させた後、ホスト１０に送信する（Ｓ４８）。そして、コントローラ１０１は、ホスト１０にリードコマンドの処理が完了した旨を通知する（Ｓ４９）。
【０１１１】
以上のように、参照処理（リードコマンド処理）では、要求されたデータがＦＣボリューム３２０に記憶されている場合、コントローラ１０１は、ＦＣボリューム３２０からデータを読出してホスト１０に提供する。
【０１１２】
図１２は、クリーニング処理の概要を示すフローチャートである。コントローラ１０１は、クリーニング処理を少なくとも一日一回実行する。本実施例では、ライフタグの最低保存期間が１日であるため、毎日一回実行すればよい。コントローラ１０１は、例えば、ライフタグの最低保存期間に合わせてクリーニング処理を実行する。
【０１１３】
コントローラ１０１は、更新セグメント管理テーブルＴ５を参照し、ＦＣボリューム３２０に記憶されている各更新セグメントのそれぞれについて、現在までの経過日数を算出する（Ｓ５１）。経過日数は、現在の日付（タイマのカウント値）からそのセグメントの更新日（更新時のカウント値）を減算することにより、求めることができる。
【０１１４】
コントローラ１０１は、そのセグメントについて算出された経過日数と、そのセグメントに記憶されているデータに設定された保存期間とを比較し、保存期間が経過しているか否かを判定する（Ｓ５２）。保存期間が既に経過している場合（S52：YES）、コントローラ１０１は、そのセグメントに対応付けられているSATA更新ビットが「１」にセットされているか否かを判定する（Ｓ５３）。
【０１１５】
SATA更新ビットに「１」がセットされていない場合（S53：NO）、クリーニング対象のデータがSATAボリュームに保存されていない場合なので、コントローラ１０１は、データ更新対象となるSATAボリュームのLUN及びセグメントを確認し（Ｓ５４）、この確認されたSATAボリュームのセグメントに消去対象のデータを書き込む（Ｓ５５）。一方、SATA更新ビットに「１」がセットされている場合（S53：YES）、消去対象のデータはSATAボリュームに記憶されているので、Ｓ５４及びＳ５５はスキップされる。
【０１１６】
次に、コントローラ１０１は、消去対象のデータに対応する更新ビットマップテーブルＴ４において、その消去対象のデータを格納するセグメントを無効化し（Ｓ５６）、そのセグメントに対応するＦＣフラグを「０」にリセットする（Ｓ５７）。これにより、消去対象のデータを格納するＦＣボリューム３２０上のセグメントには、別のライトデータを上書きすることができる。
【０１１７】
コントローラ１０１は、ＦＣボリューム３２０の全ての更新セグメントについて検査したか否かを確認し（Ｓ５８）、全ての更新セグメントについて検査を終えていない場合は（S58：NO）、更新セグメント管理テーブルＴ５の次のセグメントに移動し（Ｓ５９）、Ｓ５１に戻る。そして、更新セグメント管理テーブルＴ５に登録されている全ての更新セグメントについて検査を完了した場合（S58：YES）、本処理を終了する。
【０１１８】
本実施例は、上述のように構成されるので、以下の効果を奏する。本実施例では、データ更新時に、高速なＦＣボリューム３２０と低速なSATAボリューム３３０，３３１との両方にそれぞれデータを書込み、ライフタグによって予め設定された保存期間だけ、高速なＦＣボリューム３２０にデータを保持させる構成とした。
【０１１９】
従って、利用頻度の高いデータをＦＣボリューム３２０に保持させて、その後のデータアクセスに速やかに応答することができる。また、保存期間の経過後は、低速で安価なSATAボリューム３３０，３３１にのみデータを保存することにより、高速なＦＣボリューム３２０が不要不急のデータで満杯になるのを未然に防止し、高速ボリュームの応答性を維持することができる。
【０１２０】
本実施例では、ストレージ装置１００内で、高速なＦＣボリューム３２０上から保存期間の経過したデータを消去するため、ホスト１０に特別な機能を何ら追加することなく、データの利用頻度（利用価値）に応じたデータ配置を実現できる。従って、従来のデータマイグレーションのように、ユーザは、移動対象のデータを指定等する必要がなく、使い勝手が向上する。また、ホスト１０とストレージ装置１００間を接続する通信ネットワークＣＮ１上に、移動対象のデータが流れることもなく、トラフィックの増大を防止することができる。
【０１２１】
本実施例では、仮想ボリューム３１０，３１１毎にそれぞれライフタグを設定する構成のため、結果的に、例えば、その仮想ボリュームを使用するアプリケーションプログラム毎に、または、その仮想ボリュームを使用するホスト毎に、ライフタグを自動的に設定することができる。
【０１２２】
本実施例では、複数のSATAボリューム３３０，３３１のそれぞれに単一のＦＣボリューム３２０を対応付けて仮想ボリューム３１０，３１１を構成する。従って、各SATAボリューム３３０，３３１の合計記憶容量に比べて少ない記憶容量のＦＣボリューム３２０により、複数の仮想ボリューム３１０，３１１を構築することができる。これにより、比較的小容量のＦＣボリューム３２０で、ストレージ装置１００の応答性等を改善することができる。
【０１２３】
本実施例では、段階的にライフタグのレベルを設定可能としたので、例えば、仮想ボリュームを使用するアプリケーションプログラムの種類に応じて、適切な保存期間を設定することができる。また、ライフタグの設定及びその内容の定義は、ユーザが管理端末２０を介して手動で行うことができ、ユーザの使用形態に応じて保存期間を自由に設定することができる。
【実施例２】
【０１２４】
図１３〜図１８に基づいて、第２実施例を説明する。本実施例では、ホスト１０において、ファイル単位またはディレクトリ単位でライフタグを設定する。そして、ストレージ装置１００は、ホスト１０により設定されたライフタグに従って、データの再配置（高速ボリュームからのデータ消去）を実行する。
【０１２５】
図１３の全体概略構成図に示すように、本実施例におけるホスト１０Ｃは、前記実施例で述べたホスト１０Ａ，１０Ｂと同様に、Ｉ／Ｏ制御プログラム１２Ｃと、アプリケーション群１３Ｃ等に加えて、ライフタグ設定部１４を備えている。
【０１２６】
ライフタグ設定部１４は、ファイル単位またはディレクトリ単位で、段階的に保存期間を設定するための機能であり、その全部または一部は、例えばアプリケーション群１３Ｃ内に設けることができる。そして、本実施例では、ホスト１０Ｃにおいてライフタグを設定するため、ストレージ装置１００のメモリ１３０／１４０には、ライフタグ設定テーブルＴ２が記憶されていない。
【０１２７】
図１４は、更新処理時に、ホスト１０Ｃとストレージ装置１００との間で行われる通信の様子を示す模式図である。一例として、ホスト１０には、上位アプリケーションプログラム（以下、上位アプリケーション）１５を設けることができる。上位アプリケーション１５は、例えば、文書作成ソフトウェア、作図ソフトウェア等である。
【０１２８】
例えば、上位アプリケーション１５がファイルの更新を要求すると、アプリケーション群の一例であるファイルシステム１３Ｃは、更新対象のファイルデータをＩ／Ｏ制御プログラム１２Ｃに引き渡す。本実施例では、Ｉ／Ｏ制御プログラム１２Ｃは、例えば、FCP_SCSIドライバプログラムとして構成される。
【０１２９】
Ｉ／Ｏ制御プログラム１２Ｃは、ストレージ装置１００のコントローラ１０１に対し、ライトコマンド（FCP_CMND（write））を発行する。コントローラ１０１は、ライトコマンドを受信すると、キャッシュメモリ１３０に空き容量が存在するか否かを確認し、空き容量を確保できた場合は、ホスト１０Ｃに対してライトデータの受信準備が完了した旨を通知する（FCP_XFER_READY）。
【０１３０】
ホスト１０Ｃは、この通知を受信すると、ファイルデータをストレージ装置１００に向けて送信する（FCP_DATA）。コントローラ１０１は、ファイルデータを正常に受信してキャッシュメモリ１３０に格納した場合、ホスト１０Ｃにライトコマンドの処理完了を通知する（FCP_RSP）。後述のように、本実施例では、ホスト１０Ｃから発行されるライトコマンド中に、ライフタグを埋め込むようになっている。
【０１３１】
図１５は、ファイル単位またはディレクトリ単位でライフタグを設定する一例を示す模式図である。例えば、図１５（ａ）に示すように、ユーザは、ファイルツリー構造を端末画面に表示させ、マウス等のポインティングデバイスによって、所望のファイルまたはディレクトリを選択する。ユーザは、選択したファイルまたはディレクトリについて、ライフタグ設定メニューＭ１を表示させ、希望するレベルのライフタグを設定する。
【０１３２】
図１５では、ユーザがディレクトリ「User１」を選択して、レベル３のライフタグを設定したものとする。すると、図１５（ｂ）に示すように、そのディレクトリ「User１」に含まれる全てのファイル「file１」〜「file４」のそれぞれについて、レベル３のライフタグがそれぞれ設定される。
【０１３３】
なお、図１５（ｂ）では、説明の便宜上、ライフタグのレベルを可視化して示してあるが、これに限らず、例えば、ファイルの属性を表示させるウィンドウ等でライフタグのレベルを確認する構成でもよい。また、ライフタグの設定方法は、上述の例に限らず、種々の方法を採用することができる。例えば、上位アプリケーション１５でファイルを保存等する場合に、上位アプリケーション１５のユーザインターフェースを介して所望のライフタグを設定する構成でもよい。また、ユーザが選択したディレクトリ内に含まれる全てのファイルに同一レベルのライフタグを一律に設定する構成を挙げたが、これに限らず、例えば、システム隠しファイルやユーザが事前に設定したファイル等のような所定のファイルについては、ライフタグの設定を禁止するように構成することもできる。
【０１３４】
図１６は、ライトコマンド内にライフタグを埋め込む様子を示す説明図である。上位アプリケーション１５がファイルの更新を行う場合、上位アプリケーション１５からファイルシステム１３Ｃに対して、「更新」を示すファイル制御関数が入力される。この時点では、更新されるファイルについてライフタグは設定されていない。
【０１３５】
ファイルシステム１３Ｃは、例えば、各ファイル毎に、ファイル識別情報と、ファイル名と、ファイルデータの格納先アドレスと、ファイル属性情報と、ライフタグ等を関連付けて管理している。上位アプリケーション１５からファイル制御関数を入力されると、ファイルシステムは、その更新されるファイルデータについてライフタグを対応付けて、更新用のＩ／Ｏ制御関数を生成し、Ｉ／Ｏ制御プログラム１２Ｃに入力する。
【０１３６】
この更新用のＩ／Ｏ制御関数には、例えば、更新対象のファイルデータを記憶するLUN（仮想ボリューム番号）と、更新されるファイルデータの開始アドレス（LBA：Logical Block Address）と、LBA長と、ライフタグのレベルと、更新されるファイルデータを含めることができる。
【０１３７】
そして、Ｉ／Ｏ制御プログラム１２Ｃは、更新用のＩ／Ｏ制御関数をファイルシステム１３Ｃから受領すると、所定のライトコマンド（FCP_CMND（write））を生成し、ストレージ装置１００に向けて送信する。
【０１３８】
図１７は、ライトコマンドの構成を示す説明図である。Ｉ／Ｏ制御関数内に含まれるライフタグは、種々の方法で、ライトコマンド内に埋め込むことができる。例えば、ライフタグは、後述する領域Ｄ３３１，Ｄ３３４ａ，Ｄ３３４ｇのうち少なくともいずれか一つの領域に格納することができる。
【０１３９】
図１７の下側から順番に説明する。ファイバチャネル（FCP）で使用されるフレームフォーマットＤ３は、領域Ｄ３１〜Ｄ３５を含むことができる。領域Ｄ３１は、フレームの先頭を識別するためのSOF（Start Of File）領域である。領域Ｄ３２は、フレームヘッダ領域である。領域Ｄ３３は、コマンド等を収容するデータフィールド領域である。領域Ｄ３４は、フレームヘッダ領域Ｄ３２とデータフィールド領域Ｄ３３とのデータをチェックするCRC（Cyclic Redundancy Check）コードを格納するためのCRC領域である。領域Ｄ３５は、フレームの最後を識別するためのEOF（End Of File）領域である。
【０１４０】
データフィールド領域Ｄ３３は、領域Ｄ３３１〜Ｄ３３５から構成可能である。領域Ｄ３３１は、オプショナルヘッダ領域であり、フレームヘッダ領域Ｄ３２で存在が示された場合に設けられる。オプショナルヘッダ領域Ｄ３３１では、例えば、送信したフレームの満了時間、ネットワーク間のルーティング、プロセスグループやプロセスの識別等を行うための情報を格納することができるが、通常の場合は使用されない。
【０１４１】
領域Ｄ３３２は、LUNを記憶するFCP_LUN領域である。領域Ｄ３３３は、コントロール情報を記憶するFCP_CNTL領域である。領域Ｄ３３４は、SCSIコマンドを記憶するFCP_CDB（Command Descriptor Block）である。領域Ｄ３３５は、データ長を記憶するFCP_DL領域である。
【０１４２】
FCP_CDB領域Ｄ３３４は、領域Ｄ３３４ａ〜Ｄ３３４ｈから構成可能である。領域Ｄ３３４ａは、ライトアクセスであることを示すオペレーションコード領域である。続く領域Ｄ３３４ｂは、LUNを記憶するLUN領域であるが、通常の場合は使用されない。領域３３４ｃは、DPO（Disable Page Out）／FUA（Force Unit Access）領域である。領域Ｄ３３４ｄは、論理ブロックアドレス（LBA）を記憶するLBA領域である。領域Ｄ３３４ｅは、予約された領域である。領域Ｄ３３４ｆは、LBA長領域である。領域Ｄ３３４ｇは、ベンダー固有の情報を格納するVU（Vendor Unique）領域である。領域Ｄ３３４ｈは、予約情報やフラグ情報等を格納可能な領域である。
【０１４３】
ここで、ライフタグの情報を格納可能な領域を検討する。まず、既に使用されている領域にはライフタグの情報を記憶させることはできない。ライフタグは、未使用の領域にセットする必要がある。そして、ライフタグの種類（レベル）を仮に「４」と定めた場合、ライフタグの情報を格納するためには、２ビット以上の空き領域が必要となる。従って、図１７中に示す領域Ｄ３３１，Ｄ３３４ｂまたはＤ３３４ｇのうち少なくともいずれか一つの領域に、ライフタグ情報をセットすることができる。
【０１４４】
図１８は、本実施例によるディステージ処理の概要を示すフローチャートである。本処理におけるＳ６２〜Ｓ７５は、図１０中のＳ２２〜Ｓ３５にそれぞれ対応するので、その説明を省略することができる。
【０１４５】
本処理のＳ６１では、図１０中のＳ２１とは異なり、ライトコマンドからライフタグの情報を抽出する。抽出されたライフタグは、更新セグメント管理テーブルＴ５の所定位置に格納される。
【０１４６】
このように、本実施例では、ホスト１０Ｃ側において、ファイル単位またはディレクトリ単位で、ライフタグを段階的に設定可能とした。従って、同一の仮想ボリュームに記憶されるデータであっても、それぞれ異なる保存期間に設定され得る。このように、ファイル単位やディレクトリ単位でライフタグを設定することにより、より一層、利用頻度に応じてデータの配置を管理することができ、使い勝手が向上する。
【０１４７】
また、本実施例では、ホスト側で更新データのライフタグを設定し、ストレージ装置は、ホストにより設定されたライフタグに従って、保存期間の経過したデータを高速ボリュームから消去する構成とした。従って、細かなデータ管理であっても、対象データの検索やデータ移動について、ホストへ負荷がかかることがない。即ち、本実施例では、ホストは、ファイル単位またはディレクトリ単位で、データ管理の指標となる情報（ライフタグ）のみを設定するだけでよく、そのデータ管理指標に基づく実際のデータ管理は、ストレージ装置内で実行される。このように、データ管理指標の設定と、このデータ管理指標に基づく制御の実行とを、ホストとストレージ装置間で分担することにより、ホストの負荷を増大させずに細かなデータ管理を行うことができる。
【０１４８】
また、本実施例では、既に用意されているコマンド構造を利用してライフタグの情報を埋め込むため、既存の枠組みを維持したままでストレージ装置１００の使い勝手等を改善することができる。
【実施例３】
【０１４９】
図１９に基づいて、第３実施例を説明する。本実施例では、ライフタグ設定テーブルＴ２Ａを拡張し、一つのLUNに複数のLDEVが対応付けられている場合でも、ライフタグを設定可能としている。
【０１５０】
ライフタグ設定テーブルＴ２Ａは、各LUN毎に、それぞれ複数のLDEV及び各LDEV毎のライフタグを対応付けている。このように、１つのLUN（仮想ボリューム）が、複数のSATAボリュームから構成される場合にも、本発明は適用可能である。
【実施例４】
【０１５１】
図２０，図２１に基づいて、第４実施例を説明する。図２０の概略構成図に示すように、本実施例では、各仮想ボリューム３１０毎に、それぞれＦＣボリューム３２０を対応付けることができる。
【０１５２】
このように、各SATAボリューム３３０毎にそれぞれ異なるＦＣボリューム３２０を対応付けて仮想ボリューム３１０を構築することにより、一つの仮想ボリューム３１０に占める高速な記憶領域の比率を増加させることができ、前記各実施例の場合よりもより多くのデータをより長くＦＣボリューム３２０に保存することができる。
【０１５３】
図２１は、各仮想ボリューム（LUN）毎にそれぞれＦＣボリューム３２０を対応付ける場合に使用するLUN−FCボリューム対応テーブルＴ７の構成例を示す。図２１（ａ）に示すように、このテーブルＴ７では、各LUN毎に、ＦＣボリュームの番号を対応付けて管理する。なお、図２１（ｂ）に示すように、複数のＦＣボリュームを設け、各ＦＣボリュームをそれぞれ複数の仮想ボリュームに対応付けることもできる。
【実施例５】
【０１５４】
図２２に基づいて、第５実施例を説明する。本実施例では、更新セグメント管理テーブルＴ５をＦＣボリューム３２０に記憶させるのではなく、メモリ１３０／１４０（特に、例えば、共有メモリ１４０）に記憶させる。
【０１５５】
このように、更新セグメント管理テーブルＴ５をメモリ１３０／１４０に記憶させることにより、ＦＣボリューム３２０にはデータのみを格納させることができ、ＦＣボリューム３２０の記憶領域をより有効に利用することができる。
【０１５６】
なお、本発明は、上述した実施の形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。例えば、当業者であれば、前記各実施例を適宜組み合わせることができる。また、例えば、NAS（Network Attached Storage）用のファイルシステムを搭載した制御パッケージ（NASブレード）をストレージ装置に設けることにより、NASサービスを提供することができる。この場合、例えば、NASブレード内で、更新されたファイルにライフタグを関連付けることができる。
【図面の簡単な説明】
【０１５７】
【図１】本発明の実施形態の概念を示す説明図である。
【図２】第１実施例に係るストレージシステムの全体構成図である。
【図３】ストレージ装置の記憶構造を示す説明図である。
【図４】第１実施例の構成を模式的に示す構成説明図である。
【図５】マッピングテーブルの構成を示す説明図である。
【図６】ライフタグ設定テーブル及びライフタグ定義テーブルをそれぞれ示す説明図である。
【図７】更新ビットマップテーブルの構成を示す説明図である。
【図８】更新セグメント管理テーブルの構成及び更新セグメント管理テーブルを用いて保存期間の経過したデータを消去する様子を示す説明図である。
【図９】更新処理を示すフローチャートである。
【図１０】ディステージ処理を示すフローチャートである。
【図１１】参照処理を示すフローチャートである。
【図１２】クリーニング処理を示すフローチャートである。
【図１３】第２実施例に係る構成を説明する構成説明図である。
【図１４】ライトアクセス時にホストとストレージ装置との間で交換される情報の様子を示す模式図である。
【図１５】ファイルまたはディレクトリ毎にライフタグを設定する場合の説明図である。
【図１６】ホストでライフタグを設定する場合のホストのプログラム構成を示す説明図である。
【図１７】ライトコマンドの構成を示す説明図である。
【図１８】ディステージ処理を示すフローチャートである。
【図１９】第３実施例に用いられるライフタグ設定テーブルを示す説明図である。
【図２０】第４実施例の概略構成を示す説明図である。
【図２１】LUN−FCボリューム対応テーブルを示す説明図であり、（ａ）は各LUNに各ＦＣボリュームをそれぞれ対応付ける場合を、（ｂ）は複数のＦＣボリュームを複数のLUNにそれぞれ対応付ける場合を、それぞれ示す。
【図２２】第５実施例の概略構成を示す説明図である。
【符号の説明】
【０１５８】
１…ストレージ装置、２…ホスト、２Ａ…アプリケーション、３…制御部、４…低速ボリューム、５…高速ボリューム、６…メモリ、６Ａ…更新ビットマップテーブル、６Ｂ…ライフタグ管理テーブル、７…仮想ボリューム、８…更新セグメント管理テーブル、１０，１０Ａ〜１０Ｃ…ホスト、１２…制御プログラム、１３…アプリケーションプログラム群、１４…ライフタグ設定部、１５…上位アプリケーション、２０…管理端末、１００，２００…ストレージ装置、１０１…コントローラ、１０２…CPU、１０３…タイマ、１１１…通信ポート、１１１Ａ…ターゲットポート、１１１Ｂ…外部接続用ポート、１３０…キャッシュメモリ、１３０／１４０…メモリ、１４０…共有メモリ、１５０…接続制御部、１６０…記憶部、１７１…ディスクドライブ（PDEV）、１７２…パリティグループ（VDEV）、１７３…論理ボリューム（LDEV）、１７４…ＬＵ、２１０…コントローラ、２１１…ターゲットポート、２２０…ディスクドライブ、３１０，３１１…仮想ボリューム、３２０…ＦＣボリューム（高速ボリューム）、３３０，３３１…SATAボリューム（低速ボリューム）、Ｔ１〜Ｔ７…テーブル
【図１】
2006139552.tif 000003
【図２】
2006139552.tif 000004
【図３】
2006139552.tif 000005
【図４】
2006139552.tif 000006
【図５】
2006139552.tif 000007
【図６】
2006139552.tif 000008
【図７】
2006139552.tif 000009
【図８】
2006139552.tif 000010
【図９】
2006139552.tif 000011
【図１０】
2006139552.tif 000012
【図１１】
2006139552.tif 000013
【図１２】
2006139552.tif 000014
【図１３】
2006139552.tif 000015
【図１４】
2006139552.tif 000016
【図１５】
2006139552.tif 000017
【図１６】
2006139552.tif 000018
【図１７】
2006139552.tif 000019
【図１８】
2006139552.tif 000020
【図１９】
2006139552.tif 000021
【図２０】
2006139552.tif 000022
【図２１】
2006139552.tif 000023
【図２２】
2006139552.tif 000024