(57)【特許請求の範囲】
【請求項１】
シンプロビジョニングボリュームに割り当てられる記憶領域を含むストレージシステム内の複数の記憶領域に対して、ストレージコントローラが、データリカバリのために異なる優先度を付与する工程と、
前記ストレージシステム内の一つ以上の前記記憶領域を巻き込む障害の発生時に、前記ストレージコントローラが、前記優先度に基づいて前記ストレージシステムのデータリカバリを実行する工程と、
を備え、
前記優先度を付与する工程には、
前記ストレージコントローラが、前記ストレージシステム内で一つ以上の前記記憶領域を巻き込む障害の発生を契機として、少なくとも当該障害の発生位置と当該契機における前記記憶領域の割り当て先を示すマッピング情報とに基づいて、当該障害によって影響を受け、かつ、割り当て済みの記憶領域を特定する工程と、
前記ストレージコントローラが、前記記憶領域のリリースの可否を示すリリーサビリティ情報に基づいて、前記工程で特定した記憶領域がリリース可能であるか否かを確認し、リリース不可の記憶領域である場合は高い優先度を付与する一方で、リリース可能な記憶領域である場合は低い優先度を付与する工程と、が含まれ、
前記ストレージシステムのデータリカバリを実行する工程において、前記ストレージコントローラが、前記優先度を付与する工程で付与された優先度に従って、前記優先度の高い記憶領域のデータリカバリを前記優先度の低い記憶領域のデータリカバリよりも先に実行する
ことを特徴とするストレージシステムにおけるストレージ使用方法。
【請求項２】
前記優先度を付与する工程が、
前記ストレージシステム内の前記記憶領域のアクセス特性を監視する工程と、
前記監視したアクセス特性に基づいて、前記ストレージシステム内の前記記憶領域に対して、データリカバリにおける異なる優先度を付与する工程と、
を備える、請求項１に記載の方法。
【請求項３】
前記アクセス特性が、アクセス頻度、アクセスレート、及び、アクセス間隔のうち少なくとも一つを備える、請求項２に記載の方法。
【請求項４】
前記優先度を付与する工程が、前記ストレージシステム内の前記記憶領域に対して前記異なる優先度を割り当てる工程を備える、請求項１に記載の方法。
【請求項５】
前記記憶領域内のデータの使用状況又は重要度の少なくとも一方に基づいて、前記異なる優先度が割り当てられる、請求項４に記載の方法。
【請求項６】
前記記憶領域内のデータの使用状況に基づいて前記異なる優先度が割り当てられる場合、各前記記憶領域内に記憶されているデータの使用状況を分析して前記優先度を決定し、前記分析した使用状況に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新する工程と、
前記記憶領域内のデータの重要度に基づいて前記異なる優先度が割り当てられる場合、各前記記憶領域に記憶されているデータの重要度を分析して前記優先度を決定し、前記分析した重要度に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新する工程と、
をさらに備える、請求項５に記載の方法。
【請求項７】
データプロセッサと、
メモリと、
シンプロビジョニングボリュームに割り当てられる記憶領域を含み、データリカバリにおいて異なる優先度が付与される複数の記憶領域と、
ストレージシステム内の一つ以上の前記記憶領域を巻き込む障害の発生時に、前記優先度に基づいて、前記ストレージシステムのデータリカバリを実行するストレージコントローラと、を備え、
前記ストレージコントローラは、
前記ストレージシステム内で一つ以上の前記記憶領域を巻き込む障害の発生を契機として、少なくとも当該障害の発生位置と当該契機における前記記憶領域の割り当て先を示すマッピング情報とに基づいて、当該障害によって影響を受け、かつ、割り当て済みの記憶領域を特定し、
さらに、前記記憶領域のリリースの可否を示すリリーサビリティ情報に基づいて、前記特定した記憶領域がリリース可能であるか否かを確認し、リリース不可の記憶領域である場合は高い優先度を付与する一方で、リリース可能な記憶領域である場合は低い優先度を付与し、
前記優先度の高い記憶領域のデータリカバリを前記優先度の低い別の記憶領域のデータリカバリよりも先に実行する
ことを特徴とするストレージシステム。
【請求項８】
前記ストレージコントローラが、前記ストレージシステム内の前記記憶領域のアクセス特性を監視し、前記監視したアクセス特性に基づいて、前記ストレージシステム内の前記記憶領域に対して、データリカバリにおける異なる優先度を付与する、請求項７に記載のストレージシステム。
【請求項９】
前記アクセス特性が、アクセス頻度、アクセスレート、及び、アクセス間隔のうち少なくとも一つを備える、請求項８に記載のストレージシステム。
【請求項１０】
前記ストレージシステムにおいて、前記記憶領域に対して前記異なる優先度が割り当てられる又は登録される、請求項７に記載のストレージシステム。
【請求項１１】
前記記憶領域内のデータの使用状況又は重要度の少なくとも一方に基づいて、前記異なる優先度が割り当てられる、請求項１０に記載のストレージシステム。
【請求項１２】
前記記憶領域内のデータの使用状況に基づいて前記異なる優先度が割り当てられる場合、
前記ストレージコントローラは、各前記記憶領域内に記憶されているデータの使用状況の分析に関する情報を受信して前記優先度を決定し、
前記記憶領域内のデータの重要度に基づいて前記異なる優先度が割り当てられる場合、前記ストレージコントローラは、各前記記憶領域に記憶されているデータの重要度の分析に関する情報を受信して前記優先度を決定し、
前記ストレージコントローラは、前記受信した情報に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新する、
請求項１１に記載のストレージシステム。
【請求項１３】
ストレージシステム内のストレージを使用するようにデータプロセッサを制御するための複数の命令を記憶する、コンピュータ読取可能な記憶媒体であって、
前記複数の命令は、
シンプロビジョニングボリュームに割り当てられる記憶領域を含む前記ストレージシステム内の複数の記憶領域に対してデータリカバリにおける異なる優先度を付与するように、前記データプロセッサに指示する命令と、
前記ストレージシステム内の一つ以上の前記記憶領域を巻き込む障害の発生時に、前記優先度に基づいて前記ストレージシステムのデータリカバリを実行するように、前記データプロセッサに指示する命令と、を備え、
前記優先度を付与するように前記データプロセッサに指示する命令には、
前記ストレージシステム内で一つ以上の前記記憶領域を巻き込む障害の発生を契機として、少なくとも当該障害の発生位置と当該契機における前記記憶領域の割り当て先を示すマッピング情報とに基づいて、当該障害によって影響を受け、かつ、チャンクを割り当て済みの記憶領域を特定する処理を実行させる命令と、
前記記憶領域のリリースの可否を示すリリーサビリティ情報に基づいて、前記特定された記憶領域がリリース可能であるか否かを確認し、リリース不可の記憶領域である場合は高い優先度を付与する一方で、リリース可能な記憶領域である場合は低い優先度を付与する処理を実行させる命令と、が含まれ、
前記データリカバリを実行するように前記データプロセッサに指示する命令によって、前記ストレージシステムにおいて、前記優先度の高い記憶領域のデータリカバリは、前記優先度の低い別の記憶領域のデータリカバリよりも先に実行される
ことを特徴とするコンピュータ読取可能な記憶媒体。
【請求項１４】
前記ストレージシステム内の複数の記憶領域に対してデータリカバリにおける異なる優先度を付与するように、前記データプロセッサに指示する前記命令は、
前記ストレージシステム内の前記記憶領域のアクセス特性を監視するように、前記データプロセッサに指示する命令と、
前記監視したアクセス特性に基づいて、前記ストレージシステム内の前記記憶領域に対してデータリカバリにおける異なる優先度を付与するように、前記データプロセッサに指示する命令と、を備える、
請求項１３に記載のコンピュータ読取可能な記憶媒体。
【請求項１５】
前記ストレージシステム内の複数の記憶領域に対してデータリカバリにおける異なる優先度を付与するように、前記データプロセッサに指示する前記命令は、
前記ストレージシステム内の前記記憶領域に対して前記異なる優先度を割り当てるように、前記データプロセッサに指示する命令、を備える、
請求項１４に記載のコンピュータ読取可能な記憶媒体。
【請求項１６】
前記記憶領域内のデータの使用状況又は重要度の少なくとも一方に基づいて、前記異なる優先度が割り当てられる、
請求項１５に記載のコンピュータ読取可能な記憶媒体。
【請求項１７】
前記ストレージシステム内の複数の記憶領域に対してデータリカバリにおける異なる優先度を付与するように、前記データプロセッサに指示する前記命令は、
前記記憶領域内の前記データの使用状況に基づいて前記異なる優先度が割り当てられる場合、各前記記憶領域内に記憶されている前記データの使用状況を分析して前記優先度を決定し、前記分析した使用状況に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新するように、前記データプロセッサに指示する命令と、
前記記憶領域内の前記データの重要度に基づいて前記異なる優先度が割り当てられる場合、各前記記憶領域に記憶されている前記データの重要度を分析して前記優先度を決定し、前記分析した重要度に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新するように、前記データプロセッサに指示する命令と、を備える、
請求項１６に記載のコンピュータ読取可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]  本発明はストレージシステムに関し、特に、大容量ディスクドライブを使用する方法及び装置に関する。
【背景技術】
【０００２】
[0002]  ハードディスクドライブ（ＨＤＤ）市場では、ＨＤＤベンダが提供する単一のＨＤＤ装置の容量が急速に増加している。また、ソリッドステートディスク（ＳＳＤ）装置の容量も増加している。ディスク装置の障害によるデータ損失を防ぐため、殆どのストレージシステムではミラーリングやＲＡＩＤ技術といったデータ保護を採用している。参考文献１に開示されるように、ＲＡＩＤ構成は、いわゆるＲＡＩＤレベルに従って分類される。ＲＡＩＤ４、ＲＡＩＤ５、及び、ＲＡＩＤ６の構成は、記憶されているデータから冗長情報として生成されるパリティコードを使用する。パリティコードを使用することによって、複数のディスクに分散して記憶されたデータを、ディスク障害時に再構成することができる。このようにして高いデータ可用性が実現される。上記参考文献では、複数のディスクに同一のデータを持たせるいわゆるミラーリング技術をデータ保護の一つの方法として紹介し、これをＲＡＩＤ１として分類している。
【０００３】
[0003]   米国特許第７，３８６，７５８号にはオブジェクトベースのストレージデバイス（ＯＳＤ）が開示されており、同ストレージデバイスは、ＲＡＩＤ技術を使用し、各オブジェクトがＯＳＤ内のどこに記憶されているかを示すＯＳＤの情報に従って、データの再構成を行う。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】米国特許第７，３８６，７５８号
【非特許文献】
【０００５】
【非特許文献１】「A Case for Redundant Arrays of Inexpensive disks (RAID)」（D.A. Patterson、G. Gibson、R.H. Kats著、Proc. ACM SIGMOD社発行、１９８８年６月、１０９〜１１６頁）
【発明の開示】
【発明が解決しようとする課題】
【０００６】
[0004]  データのリカバリは、障害が発生したディスクに記憶されているデータをコピーしかつ／又は当該データと同一のデータを生成することによって実現されるため、リカバリプロセスには相当の時間が必要となる。また、ディスク障害の影響として、障害発生からリカバリ完了までの間に、冗長性の低下による使用不能やデータ損失の回避可能性が低くなり、データコピーによる負荷から性能が劣化してしまう。
【０００７】
[0005]  大容量ディスクドライブを使用すると、従来の小容量ディスクドライブを使用する場合に比べてリカバリ対象となるデータ量が大きいため、上述の期間が長くなってしまう。したがって、現在、ユーザのアプリケーションや使用状況に合ったディスク障害リカバリ方法が求められている。
【課題を解決するための手段】
【０００８】
[0006]  本発明の例示的な実施形態では、ディスク障害の発生時にリカバリ対象となるデータの記憶位置に対して優先度を付与することができるストレージシステムが提供される。ある実施形態では、アクセス頻度等のアクセス特性を監視することによって優先度を付与する。ストレージシステムは、データの使用状況としてアクセス特性を監視し、その統計データに従ってリカバリプロセスにおける優先度を決定する。別の実施形態では、ホストコンピュータ又は管理コンピュータが、ストレージシステムに記憶されているデータの使用状況及び又は重要度に基づいて優先度を決定する。この優先度は、ホストコンピュータ又は管理コンピュータがストレージシステムに登録する。そして、ストレージシステムは、決定された優先度に従ってディスク障害からのリカバリを行う。また別の実施形態では、ストレージシステムによる優先度の決定が、シンプロビジョニングボリュームの領域割当て／リリース（つまり使用状況）に基づいて行われる。上記のような方法を使用することにより、一つのディスクドライブ内にあるデータ記憶領域を複数の優先度に分類し、この優先度に従ってディスク障害からのリカバリを行うことができる。本発明は、大容量ディスクドライブに記憶されたデータのリカバリに適用すると特に有利である。
【０００９】
[0007]  本発明の一態様によると、ストレージシステムにおけるストレージの使用方法は、前記ストレージシステム内の複数の記憶領域に対して、データリカバリにおける異なる優先度を付与する工程と、前記ストレージシステム内の一つ以上の前記記憶領域を巻き込む障害の発生時に、前記優先度に基づいて前記ストレージシステムのデータリカバリを実行する工程と、を備える。ストレージシステムにおいて、優先度の高い記憶領域のデータリカバリは、優先度の低い別の記憶領域のデータリカバリよりも先に実行される。
【００１０】
[0008]  いくつかの実施形態では、前記優先度を付与する工程が、前記ストレージシステム内の前記記憶領域のアクセス特性を監視する工程と、前記監視したアクセス特性に基づいて、前記ストレージシステム内の前記記憶領域に対して、データリカバリにおける異なる優先度を付与する工程と、を備える。前記アクセス特性は、アクセス頻度、アクセスレート、及び、アクセス間隔のうち少なくとも一つを備える。
【００１１】
[0009]  特定の実施形態では、前記優先度を付与する工程が、前記ストレージシステム内の前記記憶領域に対して前記異なる優先度を割り当てる工程を備える。前記記憶領域内のデータの使用状況又は重要度の少なくとも一方に基づいて、前記異なる優先度が割り当てられる。ストレージシステムにおけるストレージの使用方法は、さらに、前記記憶領域内のデータの使用状況に基づいて前記異なる優先度が割り当てられる場合、各前記記憶領域内に記憶されているデータの使用状況を分析して前記優先度を決定し、前記分析した使用状況に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新する工程と、前記記憶領域内のデータの重要度に基づいて前記異なる優先度が割り当てられる場合、各前記記憶領域に記憶されているデータの重要度を分析して前記優先度を決定し、前記分析した重要度に基づいて、前記ストレージシステム内の前記記憶領域に対する前記異なる優先度を更新する工程と、を備える。
【００１２】
[0010]  いくつかの実施形態では、シンプロビジョニングボリュームである記憶ボリュームについて、前記優先度を付与する工程が、前記シンプロビジョニングボリュームについての領域割当て処理に関する情報及び領域リリース処理に関する情報を使用して、前記シンプロビジョニングボリュームの領域割当て及びリリースに基づいて前記異なる優先度を決定する工程、を備える。
【００１３】
[0011]  本発明の別の態様によると、ストレージシステムは、データプロセッサと、メモリと、データリカバリにおいて異なる優先度を有する複数の記憶領域と、ストレージシステム内の一つ以上の前記記憶領域を巻き込む障害の発生時に、前記優先度に基づいて、前記ストレージシステムのデータリカバリを実行するストレージコントローラと、を備える。前記ストレージシステムにおいて、優先度の高い記憶領域のデータリカバリは、優先度の低い別の記憶領域のデータリカバリよりも先に実行される。
【００１４】
[0012]  本発明の別の態様は、ストレージシステム内のストレージを使用するようにデータプロセッサを制御するための複数の命令を記憶する、コンピュータ読取可能な記憶媒体である。前記複数の命令は、前記ストレージシステム内の複数の記憶領域に対してデータリカバリにおける異なる優先度を付与するように、前記データプロセッサに指示する命令と、前記ストレージシステム内の一つ以上の前記記憶領域を巻き込む障害の発生時に、前記優先度に基づいて前記ストレージシステムのデータリカバリを実行するように、前記データプロセッサに指示する命令と、を備える。前記ストレージシステムにおいて、優先度の高い記憶領域のデータリカバリは、優先度の低い別の記憶領域のデータリカバリよりも先に実行される。
【００１５】
[0013]  本発明の上記及びその他の特徴及び利点は、以下に詳述する特定の実施形態から当業者に明らかとなるであろう。
【図面の簡単な説明】
【００１６】
【図１】[0014]  図１は、本発明の方法及び装置が適用されうるシステムのハードウェア構成の一例を示している。
【図２】[0015]  図２は、図１のストレージシステム内のメモリの一例を示している。
【図３】[0016]  図３は、シンプロビジョニングボリュームを提供するための構造及び方法を示している。
【図４】[0017]  図４は、マッピング情報の一例を示している。
【図５】[0018]  図５は、プール情報の一例を示している。
【図６】[0019]  図６は、ボリューム情報の一例を示している。
【図７】[0020]  図７は、ディスク、パリティグループ、プールボリューム、及び、慣用ボリューム間の関係の一例を示している。
【図８】[0021]  図８は、パリティ情報を生成するための例示的な方法を示している。
【図９】[0022]  図９は、関連データが更新される際に新たなパリティ値を計算するための例示的な方法を示している。
【図１０】[0023]  図１０は、パリティ及び他のデータストライプからデータストライプを再構成するための例示的な方法を示している。
【図１１】[0024]  図１１は、内部ボリューム情報の一例を示している。
【図１２】[0025]  図１２は、パリティグループ情報の一例を示している。
【図１３】[0026]  図１３は、ホストコンピュータからのライト要求に対する処理の概要を示すフロー図の一例である。
【図１４】[0027]  図１４は、ホストコンピュータからのリード要求に対する処理の概要を示すフロー図の一例である。
【図１５】[0028]  図１５は、シンプロビジョニングボリュームに対するライト処理を示すフロー図の一例である。
【図１６】[0029]  図１６は、セグメントへのアクセスに関するアクセス情報の一例を示している。
【図１７】[0030]  図１７は、シンプロビジョニングボリュームに対するリード処理を示すフロー図の一例である。
【図１８】[0031]  図１８は、慣用ボリュームに対するライト処理を示すフロー図の一例である。
【図１９】[0032]  図１９は、慣用ボリュームに対するアクセス情報の一例を示している。
【図２０】[0033]  図２０は、慣用ボリュームに対するリード処理を示すフロー図の一例である。
【図２１】[0034]  図２１は、シンプロビジョニングボリュームに対するリリース要求処理を示すフロー図の一例である。
【図２２】[0035]  図２２は、リリーサビリティ情報の一例を示している。
【図２３】[0036]  図２３は、シンプロビジョニングボリュームのチャンクをリリースする処理を示すフロー図の一例である。
【図２４】[0037]  図２４は、慣用ボリューム及びシンプロビジョニングボリュームの各領域のリカバリ優先度を決定する処理を示すフロー図の一例である。
【図２５】[0038]  図２５は、リカバリ優先度情報の一例を示している。
【図２６】[0039]  図２６は、ボリュームの各領域のリカバリ優先度を性能要件に基づいて登録する処理を示すフロー図の一例である。
【図２７】[0040]  図２７は、ボリュームの各領域のリカバリ優先度をデータの重要度に基づいて登録する処理を示すフロー図の一例である。
【図２８】[0041]  図２８は、シンプロビジョニングボリュームの各領域のリカバリ優先度を、当該シンプロビジョニングボリュームの領域割当て／リリース（つまり使用状況）に基づいて生成する処理を示すフロー図の一例である。
【図２９】[0042]  図２９は、リカバリ優先度に従うディスク障害からのリカバリ処理を示すフロー図の一例である。
【発明を実施するための最良の形態】
【００１７】
[0043]  以下に記載する本発明の詳細な説明において添付図面を参照するが、同図面は開示内容の一部を形成するとともに、本発明を実施しうる例示的な実施形態を説明するものであり、本発明を同実施形態に限定するものではない。添付図面中、複数の図面を通して、同種の数字は実質的に類似する構成要素を示している。また、以下に記載及び図示するように、詳細な説明において様々な例示的実施形態を示すが、本発明はここに記載及び図示される実施形態に限定されることはなく、当業者に知られている又はこれから知られるように、他の実施形態にも及びうる。本明細書中の「一実施形態」「本実施形態」又は「これら実施形態」という記載は、同実施形態に関連して記載される特定の特徴、構造、又は特性が本発明の少なくとも一つの実施形態に含まれることを意味するものであり、本明細書の様々な箇所で用いられるこれらの表現が必ずしも同じ実施形態を指しているとは限らない。また、以下の詳細な説明では、本発明の完全な理解のために具体的な詳細を数多く示している。しかし、当業者に明らかなように、本発明を実施する際にこれら具体的な詳細すべてが必要となる訳ではない。また、他の状況においては、本発明を曖昧にすることがないよう、周知の構造、材料、回路、プロセス及びインターフェースを詳細に記載してはおらず、また／又はブロック図の形式で図示する場合がある。
【００１８】
[0044]  また、以下に記載する詳細な説明の一部は、コンピュータ内のオペレーションをアルゴリズム的及び象徴的に表現する観点から示されている。これらアルゴリズム的記載及び象徴的表現は、データ処理の分野における当業者が自身の技術の要点を他の当業者に最も効果的に伝達する際に使用される手段である。アルゴリズムとは、所望の最終状態又は結果につながる一連の定義されたステップである。本発明中、実施される工程においては、明確な結果を得るべく具体的数量を物理的に操作することが必要となる。通常（必ずしもではないが）、当該数量は、記憶、転送、結合、比較、及びその他の操作が可能な、電気的又は磁気的信号又は命令の形態をとる。上記信号は、主として一般的な用法であるという理由により、ビット、値、エレメント、記号、文字、用語、数字、命令、等と呼ぶのが便利である。ただし、上記用語及びそれに類似する用語はすべて、適切な物理的数量と関連付けされるものであって、それら数量に適用される利便的ラベルでしかない旨留意すべきである。特に明記しない限り、以下の記載からも明らかなように、本明細書全体を通じて、「処理」「算出」「計算」「決定」「表示」等の表現を使用する記載は、コンピュータシステムのレジスタ及びメモリ内の物理的（電子的）数量として表わされるデータを操作しかつそれをコンピュータシステムのメモリ又はレジスタ又は他の情報記憶、送信又は表示デバイス内の物理的数量として上記同様に表現される他のデータに変換するコンピュータシステム又は他の情報処理装置の動作又は処理を含むものとする。
【００１９】
[0045]  本発明は、また、本発明の動作を実行するための装置に関する。この装置は、所望の目的のために具体的に構成された装置であってよく、あるいは、一つ以上のコンピュータプログラムによって選択的に起動又は再構成される一つ以上の汎用コンピュータを含んだ装置であってもよい。かかるコンピュータプログラムは、コンピュータ読取り可能な記憶媒体、例えば、光ディスク、磁気ディスク、読取り専用メモリ、ランダムアクセスメモリ、ソリッドステートデバイス及びドライブ、又は、電子情報を記憶するのに適した他の種類の媒体（これらに限定されない）に記憶されたものであってよい。本明細書中に提示されるアルゴリズム及び表示は、特定のコンピュータ又は他の装置に本質的に関連するものではない。本明細書中の教示内容に従って多様な汎用システムをプログラム及びモジュールとともに使用してよく、あるいは、所望の方法工程を実行するために、より特化された装置を構成するのも好都合である。また、本発明は特定のプログラミング言語を基準に記載されるものではない。本明細書に記載される本発明の教示内容を実行するために多様なプログラミング言語を使用することができる。プログラミング言語の命令は、例えば、中央処理装置（ＣＰＵ）、プロセッサ、又は、コントローラ等の一つ以上の処理デバイスによって実行することができる。
【００２０】
[0046]  本発明の例示的な実施形態では、以下に詳述するように、大容量ディスクドライブにおいて特に有利となる、障害時にリカバリするデータの記憶位置に対して優先度を付与するための装置、方法、及び、コンピュータプログラムを提供する。
【００２１】
[0047]  例示的実施形態によると、本発明の方法は、
【００２２】
[0048]  Ａ．  システム構成
【００２３】
[0049]  図１は、本発明の方法及び装置を適用することができるシステムのハードウェア構成の一例を示している。ストレージシステム１００は、ストレージコントローラ１１０、メインプロセッサ１１１、スイッチ１１２、ホストインターフェース１１３、メモリ２００、キャッシュ３００、ディスクコントローラ４００、ディスク６００（例えば、ＨＤＤやＳＳＤ）、及び、バックエンドパス６０１（例えば、ファイバチャネル、ＳＡＴＡ、ＳＡＳ、及び、ｉＳＣＳＩ（ＩＰ））を有する。
【００２４】
[0050]  メインプロセッサ１１１は、ストレージコントローラ１１０に関する様々な処理を実行する。メインプロセッサ１１１及び他のコンポーネントは、図２に示される、メモリ２００に記憶されているマッピング情報２０１、プール情報２０２、ボリューム情報２０３、アクセス情報２０４、セグメントグループ情報２０５、内部ボリューム情報２０６、パリティグループ情報２０７、リリーサビリティ情報２０８、及び、リカバリ優先度情報２０９を使用する。
【００２５】
[0051]  メインプロセッサ１１１は、図２に示される、メモリ２００に記憶されているライト処理プログラム２１１、リード処理プログラム２１２、リリース登録プログラム２１３、リリースプログラム２１４、リカバリ優先度決定プログラム２１５、リカバリ優先度登録プログラム２１６、及び、リカバリプログラム２１７を実行することにより処理を行う。処理の詳細については後述する。
【００２６】
[0052]  ホスト５００及び管理コンピュータ５２０は、ＳＡＮ９００（例えば、ファイバチャネル、ファイバチャネル・オーバー・イーサネット、及び、ｉＳＣＳＩ（ＩＰ））を介してホストインターフェース１１３に接続されている。ホスト５００、管理コンピュータ５２０、及び、ストレージコントローラ１１０は、ＬＡＮ９０２（例えば、ＩＰネットワーク）を介して互いに接続されている。
【００２７】
[0053]  ホスト５００は、ファイルシステム５０１、オペレーティングシステムＯＳ５０２、及び、アプリケーションプログラム５０３を有する。これらのプログラムを実行するため、ホスト５００はさらに、図１には示されていない、プロセッサ、メモリ、及び、ストレージデバイス等のリソースを有する。
【００２８】
[0054]  管理コンピュータ５２０は、ファイルシステム５０１、ＯＳ５０２、及び、管理プログラム５２３を有する。これらのプログラムを実行するため、管理コンピュータ５２０はさらに、図１には示されていない、プロセッサ、メモリ、及び、ストレージデバイス等のリソースを有する。管理コンピュータ５２０は、以下に記載するように、メモリ上にリカバリ優先度情報５２９を保持する。
【００２９】
[0055]  Ｂ．  ボリューム提供方法の概要
【００３０】
[0056]  一実施形態において、ストレージシステム１００は、シンプロビジョニングボリューム（ＴＰＶ）６１０及び慣用（シンプロビジョニングされていない）ボリューム６３０を提供する。これらの種類のボリュームに関しては、特許文献２が慣用ボリューム及びシンプロビジョニングボリュームを提供するストレージシステムを開示している。図３は、ＴＰＶ６１０を提供する構造及び方法を示している。ストレージシステム１００は、複数のプールボリューム６２０を有し、これらプールボリューム６２０をチャンク６９０と呼ばれる多数の固定長領域に分割する。ストレージシステム１００は、ライトアクセス時に、仮想ボリューム（ＴＰＶ）の一つのセグメントに対して一つのチャンク６９０を割り当てる。つまり、物理記憶領域を要求に応じて割り当てる。図３中、ＴＰＶ６１０は複数のセグメントから仮想的に構成され、プールボリューム６２０からセグメント（つまり、ＴＰＶ６１０の固定長領域（ページ））へチャンク６９０が割り当てられる。例えば、図３では、チャンク４がセグメント６に割り当てられている。つまり、ＴＰＶ６１０はページベースのボリュームである。
【特許文献２】米国特許番号第７，１６２，６００号
【００３１】
[0057]  上記を達成するため、ストレージコントローラ１１０はマッピング情報２０１及びプール情報２０２を使用する。図４は、マッピング情報２０１の一例を示している。マッピング情報２０１は、各ボリュームのチャンクとセグメントとのマッピングを保持するものである。チャンクがセグメントに割り当てられていない場合、割当て状態は「ＮＯ」となる。マッピング情報２０１は、高速検索用の各エレメントのリスト又はディレクトリとして構成することができる。
【００３２】
[0058]  図５は、プール情報２０２の一例を示している。プール情報２０２は、チャンクが使用されているか否かを管理している。プール情報２０２を使用することによって、ストレージコントローラ１１０は、後述するライト処理において、空き（使用されていない）チャンクを見つけることができる。プール情報２０２もまた、空きチャンクを迅速に検索するための各エレメントのリスト又はディレクトリとして構成することができる。
【００３３】
[0059]  ストレージシステム１００はまた、慣用ボリューム６３０を提供する。図１に示すように、ストレージコントローラ１１０は、慣用ボリュームの生成時に、当該慣用ボリューム６３０の全領域に記憶領域を割り当てる。慣用ボリューム６３０用の記憶領域を管理するため、ストレージコントローラ１１０はボリューム情報２０３を使用する。
【００３４】
[0060]  図６は、ボリューム情報２０３の一例を示している。ボリューム情報２０３は、各ボリュームの種別（つまり、慣用又はＴＰＶ）、サイズ、及び、公用ボリュームＩＤを含んでいる。公用ボリュームＩＤは、ホストコンピュータ５００を含む他のコンピュータが当該ボリュームを認識するために使用される。また後述するように、ストレージコントローラ１１０は、内部ボリュームＩＤを用いて、さらには内部ボリューム情報２０６及びパリティグループ情報２０７を参照することによって、慣用ボリューム６３０とパリティグループ６０３との関係（図７参照）を認識することができる。ボリューム情報２０３はまた、慣用ボリューム６３０の公用ボリュームＩＤと内部ボリュームＩＤとの関係（マッピング）を保持する。
【００３５】
[0061]  また、ボリューム情報２０３は、ＴＰＶＩＤを参照することでＴＰＶ６１０をストレージシステム１００が提供するデータ記憶ボリュームとしてホスト５００に供給するために使用される。つまり、ボリューム情報２０３は、公用ボリュームＩＤとＴＰＶＩＤとの関係（マッピング）を保持する。ボリューム情報２０３はさらに、ＴＰＶ６１０だけではなく各慣用ボリューム６３０のセグメントサイズに関する情報も含んでいる。つまり、ＴＰＶ及び慣用ボリュームともに固定長セグメントを有する。セグメントサイズは、ホスト５００、管理コンピュータ５２０、及び／又は、ストレージシステム１００の管理端末を介して、ユーザが選択及び登録してもよい。
【００３６】
[0062]  Ｃ．  パリティグループ及びデータ保護
【００３７】
[0063]  図７は、ディスク６００、パリティグループ６０３、プールボリューム６２０、及び、慣用ボリューム６３０間の関係を示している。パリティグループ６０３は、複数の物理記憶ディスク６００の集合体である。ＲＡＩＤ技術により、データ及び当該データから生成されるパリティは、パリティグループ６０３内の複数のディスク６００に分散されている。パリティグループは、データを分散して記憶するための記憶リソースを提供する。パリティグループによって提供される記憶領域は、ボリューム（つまり、慣用ボリューム６３０及びプールボリューム６２０）に細分されている。また、各慣用ボリューム６３０及びプールボリューム６２０は、複数のパリティグループ６０３の記憶領域を有することができる。
【００３８】
[0064]  図８、図９、及び図１０は、パリティを生成するとともにＲＡＩＤ技術に基づいてデータを再構成する例示的方法を示している。具体的には、図８は、パリティ情報を生成する例示的方法を示している。パリティは排他的論理和（exclusive OR：ＥＯＲ）計算により生成され、同計算において、データ‐Ａ、データ‐Ｂ、及びデータ‐Ｃは、一つのパリティを生成する各データ群（ストライプ）であり、単一のパリティグループ内の各ディスクに分散される情報単位を表している。特に、パリティは、以下の計算式で計算される。
式：データ‐Ａ  ＸＯＲ  データ‐Ｂ  ＸＯＲ  データ‐Ｃ＝パリティ
【００３９】
[0065]  物理ディスクに記憶されているデータとパリティとの関係を維持するため、記憶されているデータに変更があればパリティも変更しなければならない。図９は、関連データが更新された際に新たなパリティ値を計算するための例示的方法を示している。新たなパリティ値は、以下の式を使用して計算される。
式：新データ‐Ａ  ＸＯＲ  旧データ‐Ａ  ＸＯＲ  旧パリティ＝新パリティ
【００４０】
[0066]  上述したようなデータとパリティとの関係は常に維持されるため、あるデータストライプを、他のデータストライプ及びパリティ値から再構成することができる。つまり、パリティグループ内のディスク障害によって記憶されているデータの一部が失われた場合でも、失われたデータストライプをリカバリすることができる。図１０は、あるデータストライプを、パリティ及び他のデータストライプから再構成するための例示的方法を示している。具体的には、データ‐Ｃは、式「データ‐Ａ  ＸＯＲ  データ‐Ｂ  ＸＯＲ  パリティ＝データ‐Ｃ」を使用して再構成することができる。ＲＡＩＤレベル６（ＲＡＩＤ６）で構成されるストレージシステムでは、二つのパリティコードが維持されかつそれらが二つの異なるディスクに分散しているため、二つのデータストライプを失った場合でも、データを復旧することができる。
【００４１】
[0067]  また、ディスク６００に記憶されたデータは、データのミラーリング（つまり、ＲＡＩＤ１）によって保護することもできる。ミラーリングを使用すれば、障害が発生したディスク６００に記憶されたデータを復旧する際、障害が発生したディスク６００とミラーリングペアを成すディスク６００内に記憶されたデータを別のディスク６００にコピーする。
【００４２】
[0068]  上述したディスク６００、パリティグループ６０３、及び、ボリューム間の関係を管理するため、ストレージコントローラ１１０は、内部ボリューム情報２０６及びパリティグループ情報２０７を保持する。図１１は、内部ボリューム情報２０６の一例を示している。内部ボリューム情報２０６は、パリティグループ６０３の一領域がどのように各ボリューム（つまり、慣用ボリューム６３０及びプールボリューム６２０）に割り当てられているかに関する関係を示している。この内部ボリューム情報２０６は、内部ボリュームＩＤ、各ボリュームの種別、各ボリュームのサイズ、パリティグループＩＤ、及び、当該ボリュームに対する領域の開始アドレスを有する。図１２は、パリティグループ情報２０７の一例を示している。パリティグループ情報２０７は、各パリティグループ６０３の構成及び当該パリティグループ６０３に対するデータ保護の種別を保持維持するものである。例えば、パリティグループ＃０は四つのディスク６００から構成され、ミラーリングで保護されている（つまり、ＲＡＩＤ１）。この例では、ディスク＃０とディスク＃１とがミラーリングペアを形成し、ディスク＃２とディスク＃３からなるペアと同一のデータを有している。
【００４３】
[0069]  Ｄ．  ライト処理の概要
【００４４】
[0070]  図１３は、ホストコンピュータ５００からのライト要求に対する処理の概要を示すフローダイアグラムの一例である。ステップ１００１において、ホスト５００はライト要求を発行し、ストレージコントローラ１１０にライトデータを転送する。ステップ１００２において、ストレージコントローラ１１０は、ライト要求を参照して、ライトアクセスの対象ボリュームを確認する。ステップ１００３において、当該対象ボリュームの種別がＴＰＶであれば、ストレージコントローラ１１０はＴＰＶに対するライト処理を実行する（ステップ１００４）。そうでない場合、ストレージコントローラ１１０は慣用ボリュームに対するライト処理を実行する（ステップ１００５）。各ライト処理の詳細は後述する。
【００４５】
[0071]  Ｅ．  リード処理の概要
【００４６】
[0072]  図１４は、ホストコンピュータ５００からのリード要求に対する処理の概要を示すフロー図の一例である。ステップ１１０１において、ホスト５００は、ストレージコントローラ１１０へリード要求を発行する。ステップ１１０２において、ストレージコントローラ１１０は、当該リード要求を参照してリードアクセスの対象ボリュームを確認する。ステップ１１０３において、当該対象ボリュームの種別がＴＰＶであれば、ストレージコントローラ１１０はＴＰＶに対するリード処理を実行する（ステップ１１０４）。そうでない場合、ストレージコントローラ１１０は慣用ボリュームに対するリード処理を実行する（ステップ１１０５）。各リード処理の詳細は後述する。
【００４７】
[0073]  Ｆ．  ＴＰＶに対するライト処理
【００４８】
[0074]  図１５は、ＴＰＶ６１０に対するライト処理を示すフロー図の一例である。ステップ１２０１において、ストレージコントローラ１１０は、ライト要求を参照して、ライトアクセスの対象ＴＰＶ６１０及び対象領域を確認する。ステップ１２０２において、ストレージコントローラ１１０は、当該対象領域内のセグメントについてのマッピング情報を確認する。既に当該セグメントにチャンクが割り当てられている場合、ステップ１２０５へ進む。割り当てられていない場合は、ステップ１２０３へ進む。
【００４９】
[0075]  ステップ１２０３（チャンク未割当て）において、ストレージコントローラ１１０は、ライトデータを記憶するための新たなチャンクを割り当てる。この割当てを行うために、ストレージコントローラ１１０は、マッピング情報２０１及びプール情報２０２を更新する。プール情報２０２を使用することにより、ストレージコントローラ１１０は内部ストレージから新しいチャンクを見つける。ステップ１２０４において、ストレージコントローラ１１０はこの新しいチャンクにライトデータを記憶し、処理はステップ１２０６へ進む。
【００５０】
[0076]  ステップ１２０５（チャンク割当て済み）において、ストレージコントローラ１１０は、既存のチャンクにライトデータを記憶する。
【００５１】
[0077]  ステップ１２０６において、ストレージコントローラ１１０はアクセス情報２０４を更新する。アクセス情報２０４は、セグメント（つまり、ページ）に関するアクセス特性を記録している。ステップ１２０７において、ストレージコントローラ１１０が当該対象領域のすべてのセグメントを確認済みであれば、処理が終了する。そうでない場合は、ストレージコントローラ１１０は次のセグメントについての確認を進める（ステップ１２０８）。
【００５２】
[0078]  図１６は、セグメントへのアクセスに関するアクセス情報２０４の一例を示している。図１６に示すように、アクセス情報２０４は、各セグメントグループへのアクセスに関する情報、例えば、リード及びライトそれぞれについて、単位時間当たりのアクセスレート、最終アクセス時刻、平均アクセス長、等を保持する。一つのセグメントグループは、ＴＰＶのセグメントの集合体であり、固定数の連続するセグメントからなる。各セグメント番号内のセグメント数は、セグメントグループ情報２０５で定義されており、ユーザが直接又は管理コンピュータ５２０を介して選択することができる。値が１に設定されている場合、一つのセグメントグループが一つのセグメントに相当する。一つのセグメントグループ内のセグメント数が小さければ高精度の統計が可能になるが、統計データを記憶するためのメモリのサイズが大きくなる。平均アクセス長に関する情報は定期的に初期化してもよい。当該情報を参照することにより、各セグメントグループについてのアクセス頻度及びアクセス間隔を取得することができる。
【００５３】
[0079]  Ｇ．  ＴＰＶに対するリード処理
【００５４】
[0080]  図１７は、ＴＰＶ６１０に対するリード処理を示すフロー図の一例である。ステップ１３０１において、ストレージコントローラ１１０は、リード要求を参照して、リードアクセスの対象ＴＰＶ６１０及び対象領域を確認する。ステップ１３０２において、ストレージコントローラ１１０は、当該対象領域内のセグメントについてのマッピング情報２０１を確認する。既に当該セグメントにチャンクが割り当てられている場合、ステップ１３０３へと進む。割り当てられていない場合は、ステップ１３０５へ進む。
【００５５】
[0081]  ステップ１３０３（チャンク割当て済み）において、ストレージコントローラ１１０は当該チャンクに記憶されているデータをホスト５００へ転送する。ステップ１３０４において、ストレージコントローラ１１０はアクセス情報２０４を更新する。ステップ１３０５（チャンク未割当て）において、ストレージコントローラ１１０はゼロ（０）のデータをホスト５００へ送信する。最後に、ステップ１３０６において、ストレージコントローラ１１０が当該対象領域のすべてのセグメントを確認済みであれば、処理が終了する。そうでない場合は、ストレージコントローラ１１０は次のセグメントについての確認を進める（ステップ１３０７）。
【００５６】
[0082]  Ｈ．  慣用ボリュームに対するライト処理
【００５７】
[0083]  本発明の実施形態によると、慣用ボリューム６３０についてもアクセス情報２０４が記録される（つまり、アクセス特性が監視される）。
【００５８】
[0084]  図１８は、慣用ボリューム６３０に対するライト処理を示すフロー図の一例である。ステップ１４０１において、ストレージコントローラ１１０は、ライト要求を参照して、ライトアクセスの対象慣用ボリューム６３０及び対象領域を確認する。ステップ１４０２において、ストレージコントローラ１１０は、ライトアクセスの当該対象領域にライトデータを記憶する。ステップ１４０３において、ストレージコントローラ１１０はアクセス情報２０４を更新する。
【００５９】
[0085]  図１９は、慣用ボリュームについてのアクセス情報２０４の一例を示している。図１９のアクセス情報２０４は、慣用ボリュームＩＤ及び慣用ボリュームセグメントＩＤを有する点を除き、図１６に示すアクセス情報２０４と同一である。
【００６０】
[0086]  Ｉ．  慣用ボリュームに対するリード処理
【００６１】
[0087]  図２０は、慣用ボリューム６３０に対するリード処理を示すフロー図の一例である。ステップ１５０１において、ストレージコントローラ１１０は、リード要求を参照して、リードアクセスの対象慣用ボリューム６３０及び対象領域を確認する。ステップ１５０２において、ストレージコントローラ１１０はリードアクセスの当該対象領域に記憶されているデータをホスト５００へ転送する。ステップ１５０３において、ストレージコントローラ１１０はアクセス情報２０４を更新する。
【００６２】
[0088]  Ｊ．  ＴＰＶに対するリリース要求
【００６３】
[0089]  ホスト５００は、使われなくなった領域（つまり、セグメント）についてストレージシステム１００に報告し、当該セグメントからのチャンク６９０の取り戻しを要求することができる。
【００６４】
[0090]  図２１は、ＴＰＶ６１０に対するリリース要求処理を示すフロー図の一例である。ステップ１６０１において、ホスト５００は、ＴＰＶ６１０の使用されなくなった領域を検索し、ストレージコントローラ１１０へリリース要求を発行する。上記使用されなくなったセグメントを探す処理については、ファイルシステム５０１がＴＰＶ６１０内のデータ記憶状態及び記憶領域の使用状況を把握することができるため、ファイルシステム５０１によって実行してもよい。ステップ１６０２において、ストレージコントローラ１１０は、受信した要求を参照して、リリース対象となる対象ＴＰＶ６１０及び対象領域を確認する。ステップ１６０３において、ストレージコントローラ１１０は、当該対象領域のリリーサビリティ情報２０８を更新する。
【００６５】
[0091]  図２２はリリーサビリティ情報２０８の一例を示している。リリーサビリティ情報２０８は、各セグメントのリリーサビリティを示す情報である。リリース要求によって、ストレージコントローラ１１０は当該対象領域の「リリース可能」状態を「可」に変更する。
【００６６】
[0092]  Ｋ．  ＴＰＶのチャンクのリリース処理
【００６７】
[0093]  図２３は、ＴＰＶ６１０のチャンクをリリースする処理を示すフロー図の一例である。この処理は定期的に繰り返されるか又はストレージシステム１１０の負荷が小さい時に行われる。ステップ１７０１において、ストレージコントローラ１１０はリリーサビリティ情報２０８を確認する。リリース可能と記されたセグメントがあれば、処理はステップ１７０２へ進む。そのようなセグメントがない場合は処理が終了する。ステップ１７０２において、ストレージコントローラ１１０はリリーサビリティ情報２０８を更新する。ストレージコントローラ１１０は、リリース対象となるチャンクを有するセグメントについて、「リリース可能」状態を「不可」に変更する。ステップ１７０３において、ストレージコントローラ１１０は、マッピング情報２０１及びプール情報２０２を更新することにより、上記セグメントからチャンク６９０をリリースする。
【００６８】
[0094]  Ｌ．  リカバリ優先度決定処理
【００６９】
[0095]  図２４は、慣用ボリューム６３０及びＴＰＶ６１０の各領域のリカバリ優先度を決定する処理を示すフロー図の一例である。本例では、アクセスレート、アクセス頻度、及びアクセス間隔等のアクセス特性に従って、優先度が決定される。ステップ１８０１において、ストレージコントローラ１１０はディスク６００の障害を検出する。ステップ１８０２において、ストレージコントローラ１１０は、ＴＰＶ６１０及び慣用ボリューム６３０において上記障害の影響を受けた領域を見つける。ストレージコントローラ１１０は、障害が発生したディスク６００についてのマッピング情報２０１、内部ボリューム情報２０６、及びパリティグループ情報２０７を参照することにより、影響を受けた領域を把握する。ステップ１８０３において、ストレージコントローラ１１０は、影響を受けた領域についてのアクセス情報２０４を確認し、アクセス頻度等のアクセス特性を取得する。ステップ１８０４において、ストレージコントローラ１１０は、アクセス特性に従って、当該影響を受けた領域を、いくつか（例えば、三つ）の優先度、高、中、低に分類する。例えば、ストレージコントローラ１１０は、各領域又はセグメントグループについて、アクセス頻度の順位（ランキング）を取得し、各領域又はセグメントを三つのクラスに分類する。ステップ１８０５において、ストレージコントローラ１１０は取得した優先度をリカバリ優先度情報２０９に登録する。
【００７０】
[0096]  図２５は、リカバリ優先度情報２０９の一例を示している。本例では、ボリュームＩＤの列において、ボリューム情報２０３で使用する識別子が示されている。図２５に示すように、慣用ボリューム６３０及びＴＰＶ６１０を含むボリューム内の領域は、リカバリ処理に関連して、複数のクラス、例えば、高優先度グループ、中優先度グループ、及び、低優先度グループに分類される。本例では、アクセス頻度の高い領域が高い優先度を有し、アクセス頻度の低い領域が低い優先度を有する。アクセス特性の他の要因を、優先度を決定する別の例として使用することもできる。領域を示す態様については、開始アドレス及び領域長を使用する代わりに、別の例として、セグメントＩＤ又はセグメントグループＩＤを使用してもよい。本発明に関する別の方法の例として、ホスト５００が監視するアクセス特性を使用して優先度を決定するようにしてもよい。
【００７１】
[0097]  Ｍ．  性能要件に対するリカバリ優先度登録処理
【００７２】
[0098]  ディスク障害のリカバリにおける優先度の付与又は分類の別の方法として、ホスト５００又は管理コンピュータ５２０から優先度を登録することができる。図２６は、性能要件に基づいてボリュームの各領域のリカバリ優先度を登録する処理を示すフロー図の一例である。本例では、ホスト５００又は管理コンピュータ５２０が各ボリュームの各領域の性能要件を分析する。例えば、データベースアプリケーションのデータ、特にデータベースのインデックスは、高い性能を要する。トランザクションアプリケーションのデータもまた高い性能を要する。ホスト５００又は管理コンピュータ５２０は、そのようなデータを記憶している領域に対して高い優先度を割り当てることができる。ホスト５００又は管理コンピュータ５２０は、複数のアプリケーション間での性能要件の違いを評価することができる。
【００７３】
[0099]  ステップ１９０１において、管理コンピュータ５２０は、ボリューム内の領域に記憶されているデータについての性能要件を分析する。ステップ１９０２において、管理コンピュータ５２０は、当該データの記憶位置を取得し、その領域を、分析した性能要件の差に従って、いくつか（例えば、三つ）の優先度、高、中、低のいずれかに分類する。ステップ１９０３において、管理コンピュータ５２０は、取得した優先度をリカバリ優先度情報５２９に記録する。図２５に示すリカバリ優先度情報２０９の一例を、上述のリカバリ優先度情報５２９に適用することもできる。ステップ１９０４において、管理コンピュータ５２０は、スレージコントローラ１１０に対してリカバリ登録要求を発行する。この要求と共に、リカバリ優先度情報５２９の内容がストレージコントローラ１１０へ転送される。ステップ１９０５において、ストレージコントローラ１１０は、受信した情報を参照して、リカバリ優先度情報２０９を更新する。別の例として、管理コンピュータ５２０は、複数のクラスを特定する代わりに高優先度領域のみを特定するようにしてもよい。
【００７４】
[0100]  Ｎ．  データ重要度に基づくリカバリ優先度登録処理
【００７５】
[0101]  考慮すべき別の要因として、データの重要度がある。つまり、データ損失を回避する必要性に基づいて優先度を評価するようにしてもよい。図２７は、データの重要度に基づいてボリュームの各領域のリカバリ優先度を登録する処理を示すフロー図の一例である。本例では、ホスト５００又は管理コンピュータ５２０は、各ボリュームの各領域の重要度を分析する。例えば、ファイルシステム５０１、ＯＳ５０２、及びアプリケーションプログラム５０３が使用するメタデータは、損失によってソフトウェアが使用するデータ全体が失われる又は使用できなくなることがあるため、重要である。ホスト５００又は管理コンピュータ５２０は、そのようなデータを記憶する領域に対して高い優先度を割り当てる。また、ユーザの観点から、殆どのアプリケーションプログラム５０３は、重要なユーザデータと重要でないデータの両方を保持している。つまり、重要度に差が存在することになる。ホスト５００又は管理コンピュータ５２０は、複数のアプリケーションによって維持される複数種類のデータ間において、重要度の差を評価することができる。
【００７６】
[0102]  ステップ２００１において、管理コンピュータ５２０は、ボリューム内の領域に記憶されているデータについて、上述したような重要度を分析する。ステップ２００２において、管理コンピュータ５２０は当該データの記憶位置を取得し、その領域を、分析したデータ重要度における又はデータ損失回避の必要性における差に従って、いくつか（例えば、三つ）の優先度、高、中、低のいずれかに分類する。ステップ２００３において、管理コンピュータ５２０は、取得した優先度をリカバリ優先度情報５２９に記録する。図２５に示すリカバリ優先度情報２０９の一例を、上述のリカバリ優先度情報５２９に適用することもできる。ステップ２００４において、管理コンピュータ５２０は、スレージコントローラ１１０に対してリカバリ登録要求を発行する。この要求と共に、リカバリ優先度情報５２９の内容がストレージコントローラ１１０に転送される。ステップ２００５において、ストレージコントローラ１１０は、受信した情報を参照して、リカバリ優先度情報２０９を更新する。別の例として、管理コンピュータ５２０は、複数のクラスを特定する代わりに高優先度領域のみを特定するようにしてもよい。
【００７７】
[0103]  Ｏ．  ＴＰＶに対する処理に基づくリカバリ優先度の決定
【００７８】
[0104]  上述したように、ＴＰＶ６１０を提供する処理には、チャンク９１０の割当て及びリリース要求が含まれる。割当て処理及びリリース処理に関する情報は、リカバリ優先度情報２０９の生成に使用することができる。図２８は、シンプロビジョニングボリュームの各領域の割当て／リリース（つまり、使用状態）に基づいて、シンプロビジョニングボリュームの各領域のリカバリ優先度を生成する処理を示すフロー図の一例である。この処理によって、データを引き続き記憶することが期待される領域は、ディスク障害からのリカバリについて高い優先度を得る。
【００７９】
[0105]  ステップ２１０１において、ストレージコントローラ１１０は、ディスク６００の障害を検出する。ステップ２１０２において、ストレージコントローラ１１０は、障害の影響を受けたＴＰＶ６１０の領域を見つける。ストレージコントローラ１１０は、障害が発生したディスク６００についてマッピング情報２０１、内部ボリューム情報２０６、及びパリティグループ情報２０７を参照することにより、影響を受けた領域を把握する。ステッ２１０３において、ストレージコントローラ１１０は、リカバリ優先度情報２０９を初期の値である「低」にリセットする。ステップ２１０４において、ストレージコントローラ１１０は、影響を受けた領域内のセグメントについてマッピング情報２０１を確認する。既に当該セグメントにチャンクが割り当てられている場合、ステップ２１０５へ進む。割り当てられていない場合、ステップ２１０８へ進む。ステップ２１０５において、ストレージコントローラ１１０は、当該セグメントについてリリーサビリティ情報２０８を確認する。当該セグメントがリリース可能と記されている場合は、ステップ２１０８へ進む。そうでない場合は、ステップ２１０６へ進む。ステップ２１０６において、ストレージコントローラ１１０は、当該セグメントの領域を、リカバリについて高い優先度を有するものとして分類する。ステップ２１０７において、ストレージコントローラ１１０は取得した優先度をリカバリ優先度情報２０９に記録する。ステップ２１０８において、当該影響を受けた領域のすべてのセグメントをストレージコントローラ１１０が確認済みであれば、処理が終了する。そうでない場合は、ストレージコントローラ１１０は次のセグメントについての確認を進める（ステップ２１０９）。
【００８０】
[0106]  Ｐ．  リカバリ処理
【００８１】
[0107]  図２９は、上述のリカバリ優先度に従うディスク障害からのリカバリの処理を示すフロー図の一例である。ステップ２２０１において、ストレージコントローラ１１０は、リカバリ対象となるディスク６００上の各領域のリカバリ優先度を取得する。ストレージコントローラ１１０は、ボリューム情報２０３、内部ボリューム情報２０６、及び／又はマッピング情報２０１を参照して、ディスク６００上の記憶位置を認識する。ストレージコントローラ１１０はさらにリカバリ優先度情報２０９を参照して、優先度を取得する。ステップ２２０２において、ストレージコントローラ１１０は、上述の方法を使用して、取得した優先度に従い、障害が発生したディスク６００に記憶されているデータを別のディスク６００に復旧する。
【００８２】
[0108]  優先度に基づくリカバリを実現するため、ストレージコントローラ１１０は、複数の記憶位置に対して行われる同時並行リカバリ処理のそれぞれに対し、各記憶位置の優先度に応じて、演算リソース（例えば、メインプロセッサ１１１及びディスクコントローラ４００の処理タイム、メモリ２００、及び、バックエンドパス６０１のバンド幅）を割り当てることができる。ストレージコントローラ１１０はまた、優先度に従って、リカバリ処理の実行順を制御することもできる。上述した方法及び処理によって、ユーサのアプリケーション及び使用状況に合ったディスク障害リカバリ方法を実現することができる。
【００８３】
[0109]  当然であるが、図１に示すシステム構成は、単に、本発明を実施しうる例示的な情報システムであり、本発明は特定のハードウェア構成に限定されない。本発明を実施するコンピュータ及びストレージシステムは、上記発明の実現に使用されるモジュール、プログラム、及びデータ構造を記憶しかつ読み出すことのできる既知のＩ／Ｏデバイス（例えば、ＣＤ及びＤＶＤドライブ、フロッピーディスクドライブ、ハードドライブ等）を有することもできる。これらモジュール、プログラム、及び、データ構造は、コンピュータ読取可能な媒体上に符号化することができる。例えば、本発明のデータ構造は、本発明で使用されるプログラムが存在する一つ以上のコンピュータ読取可能な媒体とは別の、コンピュータ読取可能な媒体に記憶することができる。当該システムのコンポーネントは、デジタルデータ通信のいずれかの形態又は媒体、例えば、通信ネットワークによって、相互接続することができる。通信ネットワークの例としては、ローカルエリアネットワーク、ワイドエリアネットワーク（例、インターネット）、ワイヤレスネットワーク、記憶領域ネットワーク等がある。
【００８４】
[0110]  上記説明において、本発明を十分理解するための説明として、数多くの詳細を示している。しかし、当業者に明らかなように、本発明を実施する際にこれら具体的な詳細すべてが必要となる訳ではない。また本発明は、一般的にフローチャート、フロー図、構造図、又はブロック図として記載される処理として説明してもよい。フローチャートでは順次的な処理として動作を記載してもよいが、動作の多くは並行又は同時に実施することができる。また、動作の順序を入れ替えることもできる。
【００８５】
[0111]  本分野において知られているように、上述の動作は、ハードウェア、ソフトウェア、又は両者の組み合わせによって実現することができる。本発明の実施形態の様々な態様は、回路及び論理機構（ハードウェア）を使用して実現でき、他の態様についても、機械読取可能な媒体（ソフトウェア）上に記憶されている命令を使用して実現でき、また、プロセッサがこれを実現する場合は、当該命令によって本プロセッサが本発明の実施形態の実現方法を実行する。また、本発明の実施形態は、ハードウェアのみで実行してよいものや、ソフトウェアのみで実行してよいものがある。また、記載した様々な機能は、単一のユニットが実行してもよく、あるいは、各種方法を用いて多数のコンポーネントで実行してもよい。ソフトウェアが実行する場合、本発明の実施形態を実行する方法は、コンピュータ読取可能な媒体に記憶された命令に基づいて、汎用コンピュータ等のプロセッサによって実行されうる。所望の場合、これらの命令は、圧縮及び／又は暗号化されたフォーマットで媒体上に記憶することができる。
【００８６】
[0112]  上記より明らかなように、本発明は、大容量ディスクドライブにおいて特に有利となる、障害時のリカバリ対象データの記憶位置に優先度を付与するための方法、装置、及び、コンピュータ読取可能な媒体に記憶されたプログラムを提供するものである。また、本明細書中、特定の実施形態を図示及び記載してきたが、当業者達が認識するように、開示された特定の実施形態の代わりに、同一の目的を達成するべく計算されたあらゆる構成を使用してもよい。本開示内容は、本発明のあらゆる調整又は変更を含むものとし、特許請求の範囲に使用される用語は、本発明を明細書中に開示される特定の実施形態に制限するものとして解釈されるべきではない。むしろ、本発明の範囲は、特許請求の範囲によって完全に決定されるものであり、特許請求の範囲は、それが有するあらゆる均等物とともに、請求項の解釈の確立された原則に従って解釈されるものとする。
【図１】
0005537976.tif 000002
【図２】
0005537976.tif 000003
【図３】
0005537976.tif 000004
【図４】
0005537976.tif 000005
【図５】
0005537976.tif 000006
【図６】
0005537976.tif 000007
【図７】
0005537976.tif 000008
【図８】
0005537976.tif 000009
【図９】
0005537976.tif 000010
【図１０】
0005537976.tif 000011
【図１１】
0005537976.tif 000012
【図１２】
0005537976.tif 000013
【図１３】
0005537976.tif 000014
【図１４】
0005537976.tif 000015
【図１５】
0005537976.tif 000016
【図１６】
0005537976.tif 000017
【図１７】
0005537976.tif 000018
【図１８】
0005537976.tif 000019
【図１９】
0005537976.tif 000020
【図２０】
0005537976.tif 000021
【図２１】
0005537976.tif 000022
【図２２】
0005537976.tif 000023
【図２３】
0005537976.tif 000024
【図２４】
0005537976.tif 000025
【図２５】
0005537976.tif 000026
【図２６】
0005537976.tif 000027
【図２７】
0005537976.tif 000028
【図２８】
0005537976.tif 000029
【図２９】
0005537976.tif 000030