仮想ディスク・ドライブのシステムおよび方法
【課題】動的にデータを割り当てる改善されたシステムを提供する。
【解決手段】システムは、ストレージのプール(RAIDのフリーリストを維持するストレージのページプール等)又はRAIDのヌルリストを維持するディスクストレージブロックのマトリックスを持つRAIDサブシステムと、ディスク記憶システム制御装置を持つディスクマネジャとを含む。サブシステム及びマネジャは、ストレージのプール及びディスクドライブにわたりデータを動的に割り当て、また、ディスクドライブが更に必要かを判定して必要な場合に通知を送る。
【解決手段】システムは、ストレージのプール(RAIDのフリーリストを維持するストレージのページプール等)又はRAIDのヌルリストを維持するディスクストレージブロックのマトリックスを持つRAIDサブシステムと、ディスク記憶システム制御装置を持つディスクマネジャとを含む。サブシステム及びマネジャは、ストレージのプール及びディスクドライブにわたりデータを動的に割り当て、また、ディスクドライブが更に必要かを判定して必要な場合に通知を送る。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、一般には、ディスク・ドライブのシステムおよび方法に関し、より詳細には、動的データ割り当てやディスク・ドライブ仮想化などの機能を有するディスク・ドライブ・システムに関する。
【背景技術】
【0002】
既存のディスク・ドライブ・システムは、仮想ボリューム(virtual volume)・データ・ストレージ空間が、データの格納のための特定のサイズおよび場所を有する物理ディスクと静的に関連するように、設計されている。こうしたディスク・ドライブ・システムでは、データを格納するために、データ・ストレージ空間の仮想ボリュームの厳密な場所およびサイズを知ること及び監視/制御を行うことが必要である。更に、このシステムでは、しばしば、より大きなデータ・ストレージ空間が必要であり、そのため、RAID装置が追加される。しかし、しばしば、こうした追加のRAID装置は、高価であり、また、余分なデータ・ストレージ空間が実際に必要となるまでは、必要ではない。
【0003】
図14のAに、データの格納、読み出し/書き込み、および/またはリカバリ(復旧)のための特定のサイズおよび場所を有する物理ディスクと関連する仮想ボリューム・データ・ストレージ空間を有する従来の既存のディスク・ドライブ・システムを示す。このディスク・ドライブ・システムでは、データの割り当てを、データ・ストレージ空間の仮想ボリュームの特定の場所およびサイズに基づいて、静的に行う。その結果、空のデータ・ストレージ空間は使用されず、このシステムでデータを格納、読み出し/書き込み、および/またはリカバリするために、余分であり時には高価なデータ・ストレージ装置、例えばRAID装置が前もって獲得される。こうした余分なデータ・ストレージ空間は、必要でなく、かつ/または、後の時まで使用されない可能性がある。
【発明の概要】
【0004】
従って、改善されたディスク・ドライブのシステムおよび方法が必要とされている。効率のよい、動的なデータ割り当てならびにディスク・ドライブの空間および時間管理のシステムおよび方法が更に必要とされている。
【0005】
本発明は、動的にデータを割り当てる能力を有する改善されたディスク・ドライブのシステムおよび方法を提供する。このディスク・ドライブ・システムは、ディスク・ストレージ・ブロックのマトリックスを有するRAIDサブシステムと、少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャとを含むことができる。RAIDサブシステムおよびディスク・マネージャは、RAIDからディスクへのマッピング(RAID-to-disk mapping、RAID−ツー−ディスク・マッピング)に基づいて、ディスク・ストレージ・ブロックのマトリックスおよび複数のディスク・ドライブを通して、データを動的に割り当てる。RAIDサブシステムおよびディスク・マネージャは、更に別のディスク・ドライブが必要かどうかを判定し、更に別のディスク・ドライブが必要である場合には、通知を送る。動的なデータの割り当て(アロケーション)により、ユーザは、ディスク・ドライブを、後の時間に、必要となったときに得ることができる。また、動的データ割り当てにより、ディスク・ストレージ・ブロックの仮想ボリューム・マトリックスまたはプールのスナップショット/ポイント・イン・タイム(時)・コピーの効率のよいデータ格納や、データのバックアップ、リカバリなどのためのインスタント・データ・リプレイおよびデータ・インスタント・フュージョン(fusion)や、リモート・データ・ストレージや、データ・プログレッション(Data Progression)などが、可能になる。また、データ・プログレッションにより、より安価なディスク・ドライブは、後の時間に購入されるため、延期が可能になる。
【0006】
一実施形態では、仮想ボリュームまたはディスク・ストレージ・ブロックのマトリックスまたはプールが、物理ディスクと関連付けるために提供される。仮想ボリュームまたはディスク・ストレージ・ブロックのマトリックスまたはプールの監視/制御は、複数のディスク・ストレージ・システム・コントローラによって動的に行われる。一実施形態では、それぞれの仮想ボリュームのサイズはデフォルトまたはユーザの予め定義したものとすることができ、それぞれの仮想ボリュームの場所はデフォルトでヌル(null)となっている。仮想ボリュームは、データが割り当てられるまでヌルである。データは、マトリックスまたはプールの任意のグリッドに割り当てることができる(例えば、データがそのグリッドに割り当てられた後は、そのグリッド内の「ドット」(dot)になる)。そのデータが削除された後、その仮想ボリュームは再び使用可能になり「null」として示される。このため、余分なデータ・ストレージ空間や、時には高価なデータ・ストレージ装置、例えばRAID装置を、後の時間に、必要となるたびに得ることができる。
【0007】
一実施形態では、1つのディスク・マネージャが複数のディスク・ストレージ・システム・コントローラを管理することができ、複数の冗長ディスク・ストレージ・システム・コントローラを実装して、動作させているディスク・ストレージ・システム・コントローラの障害をカバーすることができる。
【0008】
一実施形態では、RAIDサブシステムは、RAID−0、RAID−1、RAID−5、RAID−10などのRAIDタイプのうちの少なくとも1つからなる組合せを含む。代替のRAIDサブシステムでは、RAID−3、RAID−4、RAID−6、RAID−7などのような他のRAIDタイプを使用できることも理解されよう。
【0009】
また、本発明は、動的データ割り当ての方法を提供するものであり、この方法は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを与えて、RAIDサブシステムのディスク空間がディスク・ストレージ・ブロックのマトリックスを形成するようにするステップと、データを書き込み、そのデータをディスク・ストレージ・ブロックのマトリックスに割り当てるステップと、RAIDサブシステムのディスク空間の占有率の履歴に基づいて、RAIDサブシステムのディスク空間の占有率の決定するステップと、更に別のディスク・ドライブが必要かどうかを決定するステップと、更に別のディスク・ドライブが必要である場合に、RAIDサブシステムに通知を送るステップとを含む。一実施形態では、通知は電子メールによって送られる。
【0010】
本発明のディスク・ドライブ・システムの利点の1つは、RAIDサブシステムが、仮想的な数のディスクにわたってRAID技法を使用できることである。残りのストレージ空間は自由に使用可能である。RAIDサブシステムのストレージ空間を監視し、そのストレージ空間の占有率を決定することにより、ユーザは、高価であるが購入時点では用途のない大量のドライブを得なくて済む。こうして、ドライブの追加を、ストレージ空間の増大する需要を満たすために実際に必要であるときに行うことにより、ディスク・ドライブの全体のコストが著しく低減される。その一方で、ドライブの使用の効率は著しく改善される。
【0011】
本発明の別の利点は、ディスク・ストレージ・システム・コントローラが、特定のコンピュータ・ファイル・システムだけでなく、どのようなコンピュータ・ファイル・システムに対しても普遍的であることである。
【0012】
また、本発明は、データ・インスタント・リプレイ(data instant replay)の方法を提供する。一実施形態では、データ・インスタント・リプレイの方法は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを与えて、RAIDサブシステムのディスク空間がストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスを形成するようにするステップと、ストレージのページ・プールのボリュームのスナップショットまたはディスク・ストレージ・ブロックのマトリックスのスナップショットを、所定の時間間隔で自動的に生成するステップと、スナップショットまたは変分(delta、デルタ)のアドレス・インデックスを、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスに保存して、ディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタを、その保存したアドレス・インデックスを介して直ちに見つけ出せるようにするステップとを含む。
【0013】
このデータ・インスタント・リプレイの方法では、RAIDサブシステムのスナップショットの自動生成を、ユーザの定義する時間間隔で、または、ユーザのコンフィギュレーションした動的なタイム・スタンプ、例えば、数分または数時間ごとなどに、または、サーバの指示する時刻に、行う。システム障害またはウイルス攻撃が発生した場合、こうしたタイム・スタンプを有する仮想スナップショットにより、データ・インスタント・リプレイおよびデータ・インスンタント・リカバリが、約数分または数時間などで可能になる。この技法は、インスタント・リプレイ・フュージョン(instant replay fusion)とも呼ばれる。即ち、クラッシュまたは攻撃のすぐ前のデータのフュージョンが遅れずに行われ、クラッシュまたは攻撃の前に保存したスナップショットを直ちにそれ以降の動作で使用することができる。
【0014】
一実施形態では、スナップショットをローカルのRAIDサブシステムまたはリモートのRAIDサブシステムで保存し、重大なシステム・クラッシュが例えばテロリスト攻撃などが原因で生じた場合に、データの完全性(integrity)に対しての影響を受けないようにし、データを直ちにリカバリできるようにすることができる。
【0015】
このデータ・インスタント・リプレイの方法の別の利点は、スナップショットを、システムが動作し続けたままで、検査のために使用できることである。生(live)のデータをリアル・タイムの検査に使用することができる。
【0016】
また、本発明は、RAIDサブシステムと、少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャとを含むデータ・インスタント・リプレイのシステムを提供する。一実施形態では、RAIDサブシステムおよびディスク・マネージャは、複数のドライブのディスク空間にわたって、データを、RAID−ツー−ディスク・マッピングに基づいて動的に割り当てるものであり、ここでRAIDサブシステムのディスク空間は、ディスク・ストレージ・ブロックのマトリックスを形成する。ディスク・ストレージ・システム・コントローラは、ディスク・ストレージ・ブロックのマトリックスのスナップショットを所定の時間間隔で自動的に生成し、スナップショットまたはデルタのアドレス・インデックスをディスク・ストレージ・ブロックのマトリックスに保存して、ディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタを、その保存したアドレス・インデックスを介して直ちに見つけ出せるようにする。
【0017】
一実施形態では、ディスク・ストレージ・システム・コントローラは、ディスク・ストレージ・ブロックのマトリックスのスナップショットからデータ使用の頻度を監視し、そして、使用またはアクセスの頻度の低いデータほど、より安価なRAIDサブシステムへと移動させるような、エージング(aging、加齢)規則を適用する。同様に、安価なRAIDサブシステム中のデータが頻繁に使用され始めると、コントローラは、そのデータを、より高価なRAIDサブシステムへと移動させる。このため、ユーザは、ユーザ自身のストレージに対する必要性を満たす所望のRAIDサブシステム・ポートフォリオを選ぶことができる。従って、ディスク・ドライブ・システムのコストを著しく低減させること、およびユーザにより動的に制御することが可能となる。
【0018】
本発明のこうしたおよび他の特徴および利点は、本発明を実現するために企図された最良の形態を含む本発明の例示的な実施形態を示し説明する以下の詳細な説明から、当業者に明らかとなろう。本発明は、様々な自明な態様における変更が、すべて本発明の趣旨および範囲から逸脱することなく可能であることが理解されよう。従って、図面および詳細な説明は、本来例示的であって限定的でないと見なすべきである。
【図面の簡単な説明】
【0019】
【図1】図1は、本発明の諸原理に従ったコンピュータ環境におけるディスク・ドライブ・システムの一実施形態を示す。
【図2】図2は、本発明の諸原理に従った、ディスク・ドライブのRAIDサブシステムのためのストレージのページ・プールを有する動的なデータ割り当ての一実施形態を示す。
【図2A】図2Aは、ディスク・ドライブ・システムのRAIDサブシステムにおける従来のデータ割り当てを示す。
【図2B】図2Bは、本発明の諸原理に従った、ディスク・ドライブ・システムのRAIDサブシステムにおけるデータ割り当てを示す。
【図2C】図2Cは、本発明の諸原理に従った動的なデータ割り当ての方法を示す。
【図3】図3のAおよびBは、本発明の諸原理に従った、複数の時間間隔におけるRAIDサブシステムのディスク・ストレージ・ブロックのスナップショットの概略図であり、Cは、本発明の諸原理に従ったデータ・インスタント・リプレイの方法を示す。
【図4】図4は、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することによるデータ・インスタント・フュージョン機能の概略図である。
【図5】図5は、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することによるローカル/リモートのデータの複製およびインスタント・リプレイの機能の概略図である。
【図6】図6は、本発明の諸原理に従った、I/Oを行うために同じRAIDインターフェースを使用し、複数のRAID装置を1つのボリュームへと連結するスナップショットの概略図を示す。
【図7】図7は、本発明の諸原理に従った、スナップショット構造の一実施形態を示す。
【図8】図8は、本発明の諸原理に従った、PITCライフ・サイクルの一実施形態を示す。
【図9】図9は、本発明の諸原理に従った、マルチ・レベル・インデックスを有するPITCテーブル構造の一実施形態を示す。
【図10】図10は、本発明の諸原理に従った、PITCテーブルのリカバリの一実施形態を示す。
【図11】図11は、本発明の諸原理に従った、所有ページ・シーケンスおよび非所有ページ・シーケンスを有する書き込みプロセスの一実施形態を示す。
【図12】図12は、本発明の諸原理に従った、例示的なスナップショット動作を示す。
【図13A】図13Aは、データを静的に割り当てるために特定のサイズおよび場所をもつ物理ディスクと関連付けられた仮想ボリューム・データ・ストレージ空間を有する従来の既存のディスク・ドライブ・システムを示す。
【図13B】図13Bは、図13Aの従来の既存のディスク・ドライブ・システムでのボリューム論理ブロック・マッピングを示す。
【図14】図14のAは、本発明の諸原理に従った、システムにおいてデータを動的に割り当てるための、ディスク・ストレージ・ブロックの仮想ボリューム・マトリックスを有するディスク・ドライブ・システムの一実施形態を示す。図14のBは、図14のAに示すディスク・ストレージ・ブロックの仮想ボリューム・マトリックスにおける動的なデータ割り当ての一実施形態を示す。図14のCは、本発明の諸原理に従った、ストレージの仮想ボリューム・ページ・プールの一実施形態のボリューム−RAIDページ再マッピングの概略図を示す。
【図15】図15は、本発明の諸原理に従った、RAIDサブシステムの複数のディスク・ストレージ・ブロックへマッピングされる3つのディスク・ドライブの例を示す。
【図16】図16は、図15に示す3つのディスク・ドライブへ1つのディスク・ドライブを追加した後のディスク・ドライブ・ストレージ・ブロックの再マッピングの例を示す。
【図17】図17は、本発明の諸原理に従った、データ・プログレッション動作におけるアクセス可能なデータ・ページの一実施形態を示す。
【図18】図18は、本発明の諸原理に従った、データ・プログレッション・プロセスの一実施形態の流れ図を示す。
【図19】図19は、本発明の諸原理に従った、圧縮されたページ・レイアウトの一実施形態を示す。
【図20】図20は、本発明の諸原理に従った、高レベル・ディスク・ドライブ・システムにおけるデータ・プログレッションの一実施形態を示す。
【図21】図21は、本発明の諸原理に従った、サブシステムにおける外部データ・フローの一実施形態を示す。
【図22】図22は、サブシステムにおける内部データ・フローの一実施形態を示す。
【図23】図23は、コヒーレンシを独立して維持する各サブシステムの一実施形態を示す。
【図24】図24は、本発明の諸原理に従った、混合RAIDウォーターフォール・データ・プログレッションの一実施形態を示す。
【図25】図25は、本発明の諸原理に従った、ストレージのページ・プールの複数のフリー・リストの一実施形態を示す。
【図26】図26は、本発明の諸原理に従った、データベースの例の一実施形態を示す。
【図27】図27は、本発明の諸原理に従った、MRI画像の例の一実施形態を示す。
【発明を実施するための形態】
【0020】
本発明は、動的にデータを割り当てる能力を有する改善されたディスク・ドライブのシステムおよび方法を提供する。このディスク・ドライブ・システムは、RAIDの空きリスト(フリー・リスト、free list)を維持するストレージのページ・プール、または代替例としてはディスク・ストレージ・ブロックのマトリックスを有するRAIDサブシステムと、少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャとを含むことができる。RAIDサブシステムおよびディスク・マネージャは、データを、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスおよび複数のディスク・ドライブにわたって、RAID−ツー−ディスク・マッピングに基づいて、動的に割り当てる。RAIDサブシステムおよびディスク・マネージャは、更に別のディスク・ドライブが必要かどうかを判定し、更に別のディスク・ドライブが必要である場合には通知を送る。動的なデータ割り当てにより、ユーザは、ディスク・ドライブを、後にそれが必要となったときに得ることができる。また、動的なデータ割り当てにより、ディスク・ストレージ・ブロックの仮想ボリュームのマトリックスまたはプールのスナップショット/ポイント・イン・タイム・コピーの効率のよいデータ・ストレージや、データ・バックアップやリカバリなどのためのインスタント・データ・リプレイおよびデータ・インスタント・フュージョン(fusion)や、リモート・データ・ストレージや、データ・プログレッションなどが可能になる。また、データ・プログレッションにより、より安価なディスク・ドライブは後の時間に購入されるため、その延期が可能になる。
【0021】
図1に、本発明の諸原理に従った、コンピュータ環境102におけるディスク・ドライブ・システム100の一実施形態を示す。図1に示すように、ディスク・ドライブ・システム100は、RAIDサブシステム104と、少なくとも1つのディスク・ストレージ・システム・コントローラ(図16)を有するディスク・マネージャ106とを含む。RAIDサブシステム104およびディスク・マネージャ106は、データを、複数のディスク・ドライブ108のディスク空間にわたって、RAID−ツー−ディスク・マッピングに基づいて、動的に割り当てる。更に、RAIDサブシステム104およびディスク・マネージャ106は、更に別のディスク・ドライブが必要かどうかの判定を、ディスク空間全体にわたるデータ割り当てに基づいて行う能力がある。更に別のディスク・ドライブが必要である場合にはその通知がユーザへ送られて、希望される場合には更に別のディスク空間を追加できる。
【0022】
本発明の諸原理に従った、動的なデータ割り当て(または「ディスク・ドライブ仮想化」と呼ばれる)を有するディスク・ストレージ・システム100を、図2に一つの実施形態の形で示し、図14のAおよび図14のBに別の実施形態の形で示している。図2に示すように、ディスク・ストレージ・システム110は、ストレージのページ・プール112、即ち、自由にデータを保存できるデータ・ストレージ空間のリストを含むデータ・ストレージのプールを含む。ページ・プール112は、RAID装置114のフリー・リストを維持し、読み出し/書き込みの割り当ての管理を、ユーザの要求に基づいて行う。ユーザの要求したデータ・ストレージ・ボリューム116は、ストレージ空間を得るために、ページ・プール112へと送られる。それぞれのボリュームは、同じまたは異なるRAIDレベル、例えば、RAID10、RAID5、RAID0などで、同じまたは異なるクラスのストレージ装置を要求することができる。
【0023】
本発明の動的なデータ割り当ての別の実施形態を、図14のAおよび図14のBに示しており、この例では、複数のディスク・ストレージ・システム・コントローラ1402と、複数のディスク・ストレージ・システム・コントローラ1402により制御されるディスク・ストレージ・ブロックのマトリックス1404とを有するディスク・ストレージ・システム1400は、そのシステムにおいて本発明の諸原理に従ってデータを動的に割り当てる。仮想ボリュームまたはブロックのマトリックス1404は、物理ディスクと関連づけるように提供される。仮想ボリュームまたはブロックのマトリックス1404は、複数のディスク・ストレージ・システム・コントローラ1402によって動的に監視/制御される。一実施形態では、それぞれの仮想ボリューム1404のサイズは、例えば2メガバイトのように、予め定めることができ、それぞれの仮想ボリューム1404の場所はデフォルトでnullとなっている。仮想ボリューム1404のそれぞれは、データが割り当てられるまでnullである。データは、そのマトリックスまたはプールの任意のグリッドに割り当てることができる(例えば、データがそのグリッドに割り当てられた後は、そのグリッド内の「ドット」になる)。そのデータが削除された後は、その仮想ボリューム1404は再び使用可能になり、「null」と示される。このため、余分な、時には高価なデータ・ストレージ装置、例えばRAID装置を、後に必要となったときに得ることができる。
【0024】
従って、RAIDサブシステムは、仮想的な数のディスクにわたってRAID技法を使用することができる。残りのストレージ空間は自由に使用可能である。RAIDサブシステムのストレージ空間を監視し、そのストレージ空間の占有率を決定することにより、ユーザは、高価であるのに購入時点では用途のない大量のドライブを得なくても済む。このように、ドライブの追加を、ストレージ空間の増大する需要を満たすために実際に必要であるときに行うことにより、ディスク・ドライブの全体のコストが著しく低減される。一方、ドライブの使用の効率も著しく改善される。
【0025】
また、本発明のディスク・ドライブ・システムの動的なデータ割り当てにより、ストレージの仮想ボリューム・ページ・プール、または、ディスク・ストレージ・ブロックの仮想ボリューム・マトリックスの、スナップショット/ポイント・イン・タイム・コピーの効率のよいデータ・ストレージや、データ・リカバリおよびリモート・データ・ストレージのためのインスタント・データ・リプレイおよびデータ・インスタント・フュージョンや、データ・プログレッションが可能になる。
【0026】
ディスク・ドライブ・システム100における動的データ割り当てのシステムおよび方法ならびにその実装形態の結果として得られる上述の特徴および利点を、以下で詳細に論じる。
【0027】
動的なデータ割り当て
図2Aに、ディスク・ドライブ・システムのRAIDサブシステムにおける従来のデータ割り当てを示し、ここでは、空けられたデータ・ストレージ空間は専属(captive)であり、データ・ストレージ用に割り当てることができない。
【0028】
図2Bには、本発明の諸原理に従ったディスク・ドライブ・システムのRAIDサブシステムにおけるデータ割り当てを示し、ここでは、データ・ストレージ用に使用可能である空けられたデータ・ストレージは、一緒にまとめられて、ページ・プール、例えば、本発明の一実施形態では1つのページ・プール、を形成する。
【0029】
図2Cに、本発明の諸原理に従った動的なデータ割り当ての方法200を示す。動的なデータの割り当ての方法200は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを定義して、RAIDサブシステムのディスク空間がディスク・ストレージ・ブロックのマトリックスを形成するようにするステップ202と、データを書き込み、そのデータを、マトリックスの、「null」を示すディスク・ストレージ・ブロックに割り当てるステップ204とを含む。この方法は、更に、RAIDサブシステムのディスク空間の占有率を、そのRAIDサブシステムのディスク空間の占有率履歴に基づいて決定するステップ206と、更に別のディスク・ドライブが必要かどうかを判定し、必要な場合に、RAIDサブシステムへ通知を送るステップ208とを含む。一実施形態では、通知は電子メールによって送られる。更に、ディスク・ストレージ・ブロックのサイズはデフォルトに設定し、ユーザにより変更可能とすることができる。
【0030】
一実施形態では、動的なデータ割り当ては、時には「仮想化」または「ディスク空間仮想化」と呼ばれるものであり、数多くの読み出しおよび書き込みの要求を秒単位で効率よく取り扱う。このアーキテクチャでは、キャッシュ・サブシステムを直接に呼び出す割り込みハンドラが必要であることもある。動的なデータの割り当てでは、要求(リクエスト)をキューに入れないので要求の最適化はなされないが、一度に数多くの未解決(pending)の要求を有し得る。
【0031】
また、動的なデータの割り当てでは、データのインテグリティを維持し、データの内容をどのようなコントローラの障害に対しても保護することができる。そうするために、動的なデータの割り当てでは、状態情報を信頼性をもって記憶するためにRAID装置へ書き込む。
【0032】
動的なデータの割り当てでは、更に、読み出しおよび書き込みの要求の順序を維持し、読み出しまたは書き込みの要求を、要求を受け取った順序で完了させることができる。動的なデータの割り当ては、最大のシステム可用性(availability)を提供し、異なる地理的場所へのデータのリモートの複製をサポートする。
【0033】
更に、動的なデータの割り当ては、データ破壊からのリカバリ機能を提供する。スナップショットにより、ユーザは、過去におけるディスクの状態を閲覧することができる。
【0034】
動的なデータの割り当てでは、RAID装置を管理し、大規模な装置を作成し拡張するためのストレージ抽象化を提供する。
【0035】
動的なデータの割り当てでは、サーバに対して仮想ディスク装置を提示するものであり、この装置がボリューム(volume)と呼ばれる。サーバに対して、ボリュームは同じ働きをする。ボリュームは、シリアル番号に関して異なる情報を返し得るが、本質的にはディスク・ドライブのような働きをする。ボリュームは、より大きい動的なボリューム装置を作成するために、複数のRAID装置のストレージ抽象化を提供する。ボリュームは複数のRAID装置を含み、ディスク空間の効率的な使用を可能にする。
【0036】
図21に、従来の既存のボリューム論理ブロック・マッピングを示す。図14のCには、本発明の諸原理に従った、ストレージの仮想ボリュームのページ・プールの一実施形態のボリューム−RAIDページ再マッピングを示す。それぞれのボリュームは1組のページ、例えば、1、2、3などへと分割され、それぞれのRAIDは1組のページへと分割される。ボリュームのページ・サイズと、RAIDのページ・サイズとは、一実施形態では同じとすることができる。従って、本発明のボリューム−RAIDページ再マッピングの一例では、RAID−2を使用するページ#1がRAIDページ#1へとマッピングされる。
【0037】
動的なデータの割り当てでは、ボリュームのデータ・インテグリティを維持する。データは、ボリュームへと書き込まれ、サーバへの確認が行われる。データ・インテグリティは、コントローラの障害を通して、スタンド・アロンや冗長なものを含めての様々なコントローラのコンフィギュレーションに適用される。コントローラの障害としては、電源障害、パワー・サイクル(power cycle)、ソフトウェア例外、およびハード・リセットがある。動的なデータの割り当てでは、一般には、RAIDでカバーされるディスク・ドライブ障害を取り扱わない。
【0038】
動的なデータの割り当ては、コントローラに対する最も高レベルのデータ抽象化を提供する。動的なデータの割り当ては、フロント・エンドから要求を受理し、最終的にはRAID装置を使用してデータをディスクへ書き込む。
【0039】
動的なデータの割り当ては、幾つもの内部サブシステムを含む。
・キャッシュ − ボリュームへの読み出しおよび書き込みの動作を、サーバへの迅速な応答時間を提供し、データ・プラグインに対して書き込みをまとめることによって、スムーズにする。
・コンフィギュレーション − データ割り当てオブジェクトの作成、削除、取り出し、および変更の方法を含む。より高レベルのシステム・アプリケーションに対するツールボックスを作成するためのコンポーネントを提供する。
・データ・プラグイン − ボリュームの読み出しおよび書き込みの要求を、ボリューム・コンフィギュレーションに応じて、様々なサブシステムへ配布する。
・RAIDインターフェース − より大きいボリュームを作成するためのRAID装置抽象化を、ユーザおよび他の動的なデータの割り当てサブシステムに提供する。
・コピー/ミラー/スワップ − ボリュームのデータを、ローカルおよびリモートのボリュームへと複製する。一実施形態では、サーバの書き込まれたブロックのコピーのみを行うことができる。
・スナップショット − データの増分的(incremental)ボリューム・リカバリを提供する。過去のボリューム状態の閲覧ボリューム(View Volume)を即座に作成する。
・プロキシ・ボリューム − リモートの宛先ボリュームへの要求の通信を行えるようにして、リモート複製(Remote Replication)をサポートする。
・請求(billing) − 割り当てたストレージ、活動、パフォーマンス、およびデータのリカバリに対してユーザに料金請求する機能。
【0040】
また、動的なデータの割り当てでは、エラーおよびコンフィギュレーションにおける顕著な変更のログ記録も行う。
【0041】
図21に、サブシステムにおける外部データ・フローの一実施形態を示す。外部要求はフロント・エンドから来る。要求には、ボリューム情報取得(get volume information)、読み出し(read)、および書き込み(write)がある。すべての要求はボリュームIDをもつ。ボリューム情報は、ボリューム・コンフィギュレーション・サブシステムによって取り扱われる。読み出しおよび書き込みの要求はLBAを含む。また、書き込み要求はデータを含む。
【0042】
動的なデータの割り当ては、ボリューム・コンフィギュレーションに応じて、要求を幾つもの外部レイヤへ渡す。リモート複製は、要求をフロント・エンドへ渡すが、あて先はリモートの宛先ボリュームである。RAIDインターフェースは要求をRAIDへ渡す。コピー/ミラー/スワップは、要求を、宛先ボリュームに対する動的データ割り当てへと戻す。
【0043】
図22に、サブシステムにおける内部データ・フローの一実施形態を示す。内部データ・フローはキャッシュを行うことから始まる。キャッシュを行うと、書き込み要求がキャッシュに入れられるか、または、その要求が直接にデータ・プラグインへ渡される。キャッシュは、フロント・エンドのHBA装置からの直接DMAをサポートする。要求は迅速に完了され、応答がサーバに返される。データ・プラグイン・マネージャが、キャッシュより下の要求フローの中心である。それぞれのボリュームに対して、データ・プラグイン・マネージャは、要求ごとに、登録されたサブシステム・オブジェクトを呼び出す。
【0044】
データ・インテグリティに影響を及ぼす動的データ割り当てサブシステムでは、コントローラの一貫性(コヒーレンシ)に対するサポートが必要となることがある。図23に示すように、それぞれのサブシステムは、独立してコヒーレンシを維持する。コヒーレンシの更新により、コヒーレンシ・リンクを通じてのデータ・ブロックのコピーを回避する。キャッシュのコヒーレンシでは、データをピア(peer)コントローラにコピーする必要があり得る。
【0045】
ディスク・ストレージ・システム・コントローラ
図14のAに、本発明の諸原理に従った、システムにおいて動的にデータを割り当てるための、複数のディスク・ストレージ・システム・コントローラ1402と、複数のディスク・ストレージ・システム・コントローラ1402により制御されるディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404とを有するディスク・ストレージ・システム1400を示す。図14のBには、ディスク・ストレージ・ブロックまたは仮想ボリュームの仮想ボリューム・マトリックス1404における動的なデータの割り当ての一実施形態を示す。
【0046】
ある動作では、ディスク・ストレージ・システム1400は、ディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404のスナップショットを、所定の時間間隔で時間的に生成し、スナップショットまたはデルタのアドレス・インデックスを、ディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404に保存して、ディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404のスナップショットまたはデルタが、保存したアドレス・インデックスによって直ちに見つけ出せるようにする。
【0047】
更にある動作では、ディスク・ストレージ・システム・コントローラ1402は、ディスク・ストレージ・ブロックのマトリックス1404のスナップショットからデータ使用の頻度を監視し、そして、使用またはアクセスの頻度の低いデータほど、より安価なRAIDサブシステムへと移動させるようなエージング規則を適用する。同様に、より安価なRAIDサブシステム中のデータがより頻繁に使用され始めると、コントローラは、そのデータを、より高価なRAIDサブシステムへと移動させる。従って、ユーザは、ユーザ自身のストレージの必要性を満たすように所望のRAIDサブシステム・ポートフォリオを選ぶことができる。従って、ディスク・ドライブ・システムのコストを著しく低減させ、また、ユーザによる動的な制御を可能とする。
【0048】
RAID−ツー−ディスク・マッピング(RAID-to-Disk Mapping)
RAIDサブシステムおよびディスク・マネージャは、データを、複数のディスク・ドライブのディスク空間にわたって、RAID−ツー−ディスク・マッピングに基づいて、動的に割り当てる。一実施形態では、RAIDサブシステムおよびディスク・マネージャは、更に別のディスク・ドライブが必要かどうかを判定し、更に別のディスク・ドライブが必要である場合には通知を送る。
【0049】
図15に、本発明の諸原理に従った、RAID−5サブシステム1500内の複数のディスク・ストレージ・ブロック1502〜1512へとマッピングされる3つのディスク・ドライブ108(図1)の例を示す。
【0050】
図16は、図15に示す3つのディスク・ドライブ108にディスク・ドライブ1602を追加した後の、ディスク・ドライブ・ストレージ・ブロックの再マッピング1600の例を示す。
【0051】
ディスク・マネージャ
図1に示すディスク・マネージャ106は、一般には、ディスクおよびディスク・アレイの管理を行うものであり、それには、グループ化/資源プーリング、ディスク属性の抽象化、フォーマット、ディスクの追加(addition)/削減(subtraction)、およびディスク・サービス時間およびエラー率の追跡を含む。ディスク・マネージャ106は、ディスクの様々なモデルの間の違いを区別せず、RAIDコンポーネントについて包括的なストレージ装置を提示する。また、ディスク・マネージャ106はグループ化機能を提供し、これは、例えば10000RPMのディスクなどのような特定の特徴をもつRAIDグループの構築を容易にする。
【0052】
本発明の一実施形態では、ディスク・マネージャ106は、少なくとも3重のものとなっている。その3重のものとは、抽象化、コンフィギュレーション、およびI/O最適化である。ディスク・マネージャ106は、「ディスク」を上位レイヤに提示し、上位レイヤは、例えば、ローカルまたはリモートに取り付けられた物理ディスク・ドライブや、リモートに取り付けられたディスク・システムなどとすることができる。
【0053】
共通の基礎にある特徴は、こうした装置の何れもがI/O動作のターゲットであり得ることである。抽象化サービスは、特にRAIDサブシステムのような上位レイヤに対して、一様なデータ・パス・インターフェースを提供し、そして、管理者に対して、ターゲット装置の管理のための包括的な機構を提供する。
【0054】
また、本発明のディスク・マネージャ106は、ディスクのグループ化機能を提供して管理およびコンフィギュレーションを簡素化する。ディスクには名前を付け、グループに入れることができ、グループにも名前を付けることができる。グループ化は強力な機能であり、これにより、ボリュームを或るディスクのグループから別のグループへと移行させるタスクや、或るグループのディスクを特定の機能専用にするタスクや、或るグループのディスクをスペアに指定するタスクなどのタスクを簡単にする。
【0055】
また、ディスク・マネージャは、外部装置の存在を検出する役目をもつSCSI装置サブシステムなどのような装置とインターフェースを行う。SCSI装置サブシステムは、少なくともファイバ・チャネル/SCSIタイプの装置については、ブロック型のターゲット装置である装置のサブセットを判定する能力をもつ。ディスク・マネージャが管理および抽象化を行うのはこうした装置である。
【0056】
更に、ディスク・マネージャは、SCSI装置レイヤからのフロー制御に応答する役目をもつ。ディスク・マネージャは、キューイング機能を有し、これにより、ディスク・ドライブ・システムのスループットを最適化する一方法として、I/O要求を集合させる機会が与えられる。
【0057】
更に、本発明のディスク・マネージャは、複数のディスク・ストレージ・システム・コントローラを管理する。また、複数の冗長ディスク・ストレージ・システム・コントローラを実装して、動作させられるディスク・ストレージ・システム・コントローラの障害をカバーすることができる。この冗長ディスク・ストレージ・システム・コントローラもディスク・マネージャによって管理される。
【0058】
ディスク・マネージャと他のサブシステムとの関係
ディスク・マネージャは、他の幾つかのサブシステムとやり取りを行う。RAIDサブシステムは、データ・パス活動に関してディスク・マネージャが提供するサービスの重要なクライアントである。RAIDサブシステムは、ディスク・マネージャを、I/Oのためのディスクへの独占的なパスとして使用する。また、RAIDシステムでも、ディスク・マネージャからのイベントについて聴取を行い、ディスクの存在および動作状態の判定を行う。また、RAIDサブシステムはディスク・マネージャと協働して、RAID装置の構築のための範囲(extent)を割り当てる。管理コントロールは、ディスクの存在の情報を得るため、また動作状態の変化について情報を得るために、ディスク・イベントについて聴取を行う。本発明の一実施形態では、RAIDサブシステム104は、RAID−0、RAID−1、RAID−5、RAID−10などのRAIDタイプのうちの少なくとも1つからなる組合せを含むことができる。代替のRAIDサブシステムでは、RAID−3、RAID−4、RAID−6、RAID−7などのような他のRAIDタイプを使用できることも理解されよう。
【0059】
本発明の一実施形態では、ディスク・マネージャは、コンフィギュレーション・アクセスのサービスを使用して、持続的なコンフィギュレーションを保存し、また、統計などのような過渡的な読み出し専用情報をプレゼンテーション・レイヤへ提示する。ディスク・マネージャは、こうしたパラメータへのアクセスのためにコンフィギュレーション・アクセスへのハンドラの登録を行う。
【0060】
また、ディスク・マネージャは、ブロック・デバイスの存在および動作状態についての情報を得るためにSCSI装置レイヤのサービスを使用するものであり、また、こうしたブロック・デバイスへのI/Oパスをもつ。ディスク・マネージャは、ディスクを一意に識別するための補助的な方法として、装置についてSCSI装置サブシステムに問い合わせを行う。
【0061】
データ・インスタント・リプレイおよびデータ・インスタント・フュージョン
また、本発明は、データ・インスタント・リプレイ(data instant replay)およびデータ・インスタント・フュージョン(data instant fusion)の方法を提供する。図3のAおよびBに、本発明の諸原理に従った、複数の時間間隔でのRAIDサブシステムのディスク・ストレージ・ブロックのスナップショットの概略図を示す。図3Cには、データ・インスタント・リプレイの方法300を示し、この方法は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを定義して、RAIDサブシステムのディスク空間がストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスを形成するようにするステップ302と、ページ・プールのボリュームのスナップショットまたはディスク・ストレージ・ブロックのマトリックスのスナップショットを所定の時間間隔で時間的に生成するステップ304と、スナップショットまたはデルタ(delta)のアドレス・インデックスを、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスに保存して、ディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタをその保存したアドレス・インデックスによって直ちに見つけ出せるようにするステップとを含む。
【0062】
図3Bに示すように、所定の各時間間隔、例えば、T1(午後12:00)、T2(午後12:05)、T3(午後12:10)、T4(午後12:15)などのような5分毎に、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスのスナップショットが自動的に生成される。ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスの中のスナップショットまたはデルタのアドレス・インデックスは、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスに保存されて、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタを、その保存したアドレス・インデックスによって直ちに見つけ出せるようにされる。
【0063】
従って、このデータ・インスタント・リプレイの方法では、RAIDサブシステムのスナップショットを、ユーザの定義する時間間隔や、ユーザのコンフィギュレーションする例えば数分や数時間ごとなどのような動的なタイム・スタンプや、サーバの指示する時刻に、時間的に生成する。システム障害やウイルス攻撃にあった場合、こうしたタイム・スタンプを有する仮想スナップショットにより、データ・インスタント・リプレイおよびデータ・インスンタント・リカバリが、約数分または数時間などで可能になる。この技法は、インスタント・リプレイ・フュージョンとも呼ばれる。即ち、クラッシュまたは攻撃のすぐ前のデータのフュージョンが遅れずに行われ、クラッシュまたは攻撃の前に保存したスナップショットを直ちにそれ以降の動作で使用することができる。
【0064】
図4に、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックの複数のスナップショットを使用することによるデータ・インスタント・フュージョン機能400の概略図を更に示している。T3で、スナップショットの並列チェインT3’〜T5’が生成され、それにより、フュージョンされたデータT3’によってフュージョンおよび/またはリカバリされたデータを、T4でフュージョンされるデータと置き換えるために使用することができる。同様に、スナップショットの複数の並列チェインT3’’、T4’’’を生成して、T4’〜T5’およびT4’’〜T5’’でフュージョンされるデータと置き換えることができる。一代替実施形態では、T4、T4’〜T5’、T5’’でのスナップショットは、なおもページ・プールまたはマトリックスに保存することができる。
【0065】
スナップショットをローカルのRAIDサブシステムまたはリモートのRAIDサブシステムに保存することができ、それにより、重大なシステム・クラッシュが、例えば、テロリスト攻撃などが原因で生じた場合にも、データ・インテグリティについて影響を受けず、データを直ちにリカバリできる。図5に、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することによる、ローカル−リモートのデータ複製およびインスタント・リプレイ機能500の概略図を示す。
【0066】
リモート複製(replication)は、リモート・システムに対してボリューム・データを複製するサービスを行う。リモート複製では、ローカルとリモートとのボリュームを、可能な限り同期させた状態に保つことを試みる。一実施形態では、リモートのボリュームのデータが、ローカルのボリュームのデータの完全なコピーをミラーリングしていないこともあり得る。ネットワークの接続性(コネクティビティ)およびパフォーマンスに起因して、リモートのボリュームがローカルのボリュームと同期しない状態が引き起こされる場合もあり得る。
【0067】
データ・インスタント・リプレイおよびデータ・インスタント・フュージョンの方法の別の特徴は、スナップショットを、システムが動作している状態で検査のために使用できることである。生のデータ(live data)をリアル・タイムの検査に使用することができる。
【0068】
スナップショットおよびポイント・イン・タイム・コピー(PITC)
データ・インスタント・リプレイの一例は、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することである。スナップショットは、ボリュームへの書き込み動作を記録して、過去のボリュームの内容を見るためにビューを作成できるようにする。また、スナップショットは、ボリュームのそれまでのポイント・イン・タイム・コピー(Point-in-Time-Copy(特定の時にとられたコピー)、PITC)に対するビューを作成することによって、データ・リカバリのサポートを行う。
【0069】
スナップショットのコアは、スナップショットの作成、合体(coalesce)、管理、およびI/O動作を実現する。スナップショットは、ボリュームへの書き込みを監視し、ボリュームのビューを通してアクセスのためにポイント・イン・タイム・コピー(PITC)を作成する。スナップショットは、論理ブロック・アドレス(logical block address、LBA)再マッピング・レイヤを、仮想化レイヤ内のデータ・パスへ追加する。これは、I/Oパス内の仮想LBAマッピングの別レイヤである。PITCは、すべてのボリューム情報をコピーしない場合もあり得、単に再マッピングで使用されるテーブルを変更するだけであり得る。
【0070】
スナップショットは、ボリューム・データについての変更を追跡し、それまでのポイント・イン・タイムからのボリューム・データを見る機能を提供する。スナップショットは、この機能を、それぞれのPICTに対するデルタ書き込みのリストを維持することによって、行う。
【0071】
スナップショットは、PITCプロファイルのための複数の方法を提供するが、これは、アプリケーションにより開始されるもの、および時間により開始されるものを含む。スナップショットは、アプリケーションがPITCを作成するようにする機能を提供する。アプリケーションは、作成を、サーバ上のAPIを通して制御し、これはスナップショットAPIへと送られる。また、スナップショットは、時間プロファイルを作成する機能を提供する。
【0072】
スナップショットは、ジャーナル用システムの実装や、ボリュームへの書き込みのすべてのリカバリを行わない場合もあり得る。スナップショットは、PITCウィンドウ内の一つのアドレスへの最後の書き込みを保持するのみであり得る。スナップショットにより、ユーザは、例えば分や時間などの定められた短期間をカバーするPITCを作成することが可能とされる。スナップショットは、障害を取り扱うために、すべての情報をディスクに書き込む。スナップショットは、デルタ書き込み(delta writes)を含むボリューム・データ・ページ・ポインタを維持する。テーブルはマップをボリューム・データへ提供するものであり、これがなければボリューム・データへはアクセス不能であるため、テーブル情報はコントローラ障害の場合を取り扱わなければならない。
【0073】
ビュー・ボリューム機能(ボリュームを見る機能)により、PITCへのアクセスが提供される。ビュー・ボリューム機能は、アクティブなPITCを除き、そのボリューム内の任意のPITCに付加させることができる。PITCへの付加は、比較的迅速な動作である。ビュー・ボリューム機能の用途は、検査、訓練、バックアップ、およびリカバリを含む。ビュー・ボリューム機能は、書き込み動作を可能にし、その基礎とされている基礎的PITCの変更は行わない。
【0074】
一実施形態では、スナップショットは、ディスク空間を使用して、パフォーマンスを最適化し、使用を容易にするように設計されおり、それは下記のようである。
【0075】
・スナップショットにより、ユーザ要求に対する応答時間が速くなる。ユーザ要求には、I/O、PITCの作成、ビュー・ボリュームの作成/削除が含まれる。これを達成するために、スナップショットは、必要最小量よりも多くのディスク空間を使用してテーブル情報を保存する。I/Oについては、スナップショットは、ボリュームの現在の状態を要約して一つのテーブルにして、読み出しおよび書き込みの要求をすべて一つのテーブルで満たすことができるようにする。スナップショットは、通常のI/O動作に対する影響をできる限り低減する。第2に、ビュー・ボリューム動作については、スナップショットは、メイン・ボリュームのデータ・パスと同じテーブル機構を使用する。
【0076】
・スナップショットは、コピーされるデータの量を最小化する。このためには、スナップショットは、それぞれのPITCについてのポインタのテーブルを維持する。スナップショットはポインタのコピーおよび移動を行うが、ボリューム上のデータの移動は行わない。
【0077】
・スナップショットは、固定サイズのデータ・ページを用いてボリュームの管理を行う。個々のセクタを追跡するには、一つの手頃なサイズのボリュームでも膨大な量のメモリが必要になる。セクタよりも大きなデータ・ページを使用することにより、ある種のページは、別のページから直接に複製された情報の一部を含むことができる。
【0078】
・スナップショットは、ボリューム上のデータ空間を使用して、データ・ページ・テーブルを保存する。ルックアップ・テーブルは、コントローラ障害の後に複製される。ルックアップ・テーブルは、ページを割り当て、それをさらに分割する。
【0079】
・スナップショットがコントローラ障害を取り扱うが、その際、一実施形態では、スナップショットを用いるボリュームが一つのコントローラ上で動作することが必要とされる。この実施形態ではコヒーレンシは必要ない。ボリュームへのすべての変更は、代替のコントローラによるリカバリのために、ディスクまたは信頼できるキャッシュへ記録される。コントローラ障害からのリカバリの際には、一実施形態では、スナップショット情報をディスクから読み取ることが必要である。
【0080】
・スナップショットは、仮想RAIDインターフェースを使用して、ストレージへのアクセスを行う。スナップショットは、複数のRAID装置を単一のデータ空間として使用することができる。
【0081】
・スナップショットは、ボリュームあたり「n」個のPITCおよびボリュームあたり「m」個のビューをサポートする。「n」および「m」に対する制限は、ディスク空間およびコントローラのメモリの関数となる。
【0082】
ボリュームおよびボリュームの割り当て/レイアウト
スナップショットは、LBA再マッピング・レイヤをボリュームに追加する。再マッピングは、I/O要求LBAおよびルックアップ・テーブルを使用して、アドレスをデータ・ページへと変換する。図6に示すように、スナップショットを用いた提示されるボリュームは、スナップショットのないボリュームと同じふるまいをする。それは、線形LBA空間を有し、I/O要求を取り扱う。スナップショットは、RAIDインターフェースを使用してI/Oを行うものであり、複数のRAID装置を1つのボリュームに含める。一実施形態では、スナップショット・ボリュームに対するRAID装置のサイズは、提示されるボリュームのサイズではない。RAID装置により、スナップショットは、ボリューム内でデータ・ページ用の空間を拡張することを可能とされる。
【0083】
新しいボリュームは、初めにスナップショットをイネーブルにしてあると、新しいデータ・ページ用の空間を含めればよいだけである。スナップショットは、ボトム・レベルのPITCに置くページのリストを作成しない。ボトム・レベルPITCは、この場合には空である。割り当て時に、すべてのPITCページはフリー・リスト上にある。初めにスナップショットをイネーブルにしたボリュームを作することにより、ボリュームが提示するよりも少ない物理空間を割り当て得る。スナップショットは、ボリュームへの書き込みを追跡する。本発明の一実施形態では、ヌル(NULL)・ボリュームは、ページ・プールまたはマトリックスへコピーおよび/または保存されず、これにより、ストレージ空間の使用の効率が高まる。
【0084】
一実施形態では、どちらの割り当て方式でも、PITCが、仮想NULLボリュームをリストの底部に置く。NULLボリュームに対する読み出しは、ゼロのブロックを返す。NULLボリュームは、サーバがそれまで書き込んでいないセクタを取り扱う。NULLボリュームへの書き込みは起こり得ない。ボリュームは、NULLボリュームを、書き込まれていないセクタに対する読み出しのために使用する。
【0085】
空きページの数は、ボリュームのサイズ、PITCの数、および予測されるデータ変化レートに依存する。システムは、所与のボリュームに対しての割り当てるページの数を決定する。データ・ページの数は、時間が経つにつれて拡張される可能性がある。拡張により、予測されるよりも急速なデータの変化、より多くのPITC、またはより大きなボリュームを、サポートすることができる。新しいページはフリー・リストへ追加される。フリー・リストへのページの追加は自動的に行ってもよい。
【0086】
スナップショットは、ボリューム空間の管理のためにデータ・ページを使用する。それぞれのデータ・ページは数メガバイトのデータを含み得る。オペレーティング・システムを使用すると、ボリュームの同じ領域へ多くのセクタが書き込まれる傾向がある。メモリ要件からも、スナップショットがボリュームの管理のためにページを使用することが要求される。1テラバイトのボリュームの各セクタについて一つの32ビットポインタを維持すると、8ギガバイトのRAMが必要となり得る。異なるボリュームは異なるページ・サイズを有し得る。
【0087】
図7に、スナップショット構造の一実施形態を示す。スナップショットは、多くのオブジェクトをボリューム構造に付加する。付加されるオブジェクトとしては、PITC、アクティブなPITCへのポインタ、データ・ページ・フリー・リスト、子のビュー・ボリューム、およびPITC合体オブジェクトがある。
【0088】
・アクティブPITC(AP)ポインタはボリュームにより維持される。APは、ボリュームに対する読み出しおよび書き込みの要求のマッピングを取り扱う。APは、ボリューム内のすべてのデータの現在の場所の要約(一覧、summary)を含む。
【0089】
・データ・ページ・フリー・リストは、ボリューム上の使用可能なページの追跡を行う。
【0090】
・オプションの子ビュー・ボリューム(child view volume)は、ボリュームPITCへのアクセスを提供する。ビュー・ボリュームは、PITCへの書き込みを記録するためにそれ自体のAPを含むが、基礎となるデータの変更は行わない。1つのボリュームが複数の子ビュー・ボリュームをサポートしてもよい。
【0091】
・スナップショット合体オブジェクトは、以前のPITCを取り除く目的で2つのPITCを一時的にリンクする。PITCの合体は、データ・ページの所有権を移動し、データ・ページを解放することを含む。
【0092】
・PITCは、そのPITCがアクティブであった間に書き込まれたページに対するテーブルおよびデータ・ページを含む。PITCは、PITCが書き込み要求の受理を停止した時点の凍結タイム・スタンプを含む。また、PITCは、何れの時間にPITCが合体することになるかを決めるTime−to−Live(タイム・ツー・ライブ、生きる時間)値を含む。
【0093】
また、スナップショットは、ボリューム全体に対するデータ・ページ・ポインタの要約を、PITCが取られた時点で行って、読み出しおよび書き込みの予測可能なパフォーマンスを提供する。他の解決策は、最新のポインタを見つけるために複数のPITCを検査するために、読み出しを必要とし得る。こうした解決策では、テーブル・キャッシング・アルゴリズムが必要であるが、パフォーマンスは最低となる場合がある。
【0094】
また、本発明におけるスナップショットを要約することにより、テーブルの最悪のメモリ使用が低減される。その場合、テーブル全体をメモリへロードすることを必要とされ得るが、単一のテーブルだけをロードすることを必要とされ得る。
【0095】
要約(一覧)は、現在のPITCの所有するページを含むが、それまでのすべてのPITCからのページを含むことができる。PITCがどのページに書き込みを行うかを決定するために、それぞれのデータ・ページについてのページ所有権を追跡する。また、一覧は、合体プロセスに対する所有権の追跡も行う。これを取り扱うために、データ・ページ・ポインタはページ・インデックスを含む。
【0096】
図8に、PITCのライフ・サイクルの一実施形態を示す。それぞれのPITCは、読み出し専用として記憶(コミット)される前に、多数の下記の状態を経過する。
【0097】
1.テーブル作成 − 作成を行うと、テーブルが作成される。
【0098】
2.ディスクへのコミット(記憶、commit) − これは、PITCに対してディスク上にストレージを生成する。この時点でテーブルを書き込むことにより、テーブル情報の保存に必要な空間が、PITCが取られる前に割り当てられることが保証される。同時に、PITCオブジェクトもディスクへ記憶(コミット)される。
【0099】
3.I/Oの受け入れ − これはPITCはアクティブPITC(AP)になっている。 − ここでは、PITCは、ボリュームに対する読み出しおよび書き込みの要求を取り扱う。これは、テーブルへの書き込み要求を受理する唯一の状態である。PITCは、いまアクティブであるというイベントを生成する。
【0100】
4.ディスクへのテーブルの記憶 − PITCはもはやAPではなく、もはやそれ以上のページを受理しない。新しいAPによる引き継ぎが行われている。この時点より後では、テーブルは、合体動作中に取り除かれない限り、変更されない。これは読み出し専用である。PITCは、この時点で、凍結され記憶されているというイベントを生成する。何れのサービスもそのイベントを聴取することができる。
【0101】
5.テーブルのメモリの解放(リリース) − テーブルが必要とするメモリを解放する。また、このステップは、変更がすべてディスクへと書き込まれていることを示すために、ログをクリアする。
【0102】
ボリュームまたはビュー・ボリュームのためのトップ・レベルPITCは、アクティブPITC(AP)と呼ばれる。APは、ボリュームへのすべての読み出しおよび書き込みの要求を満たす。APは、そのボリュームに対しての唯一の、書き込み要求を受理できるPITCである。APは、ボリューム全体に対するデータ・ページ・ポインタの一覧を含む。
【0103】
APは、合体プロセスに関して、宛先(destination)となることはできるが、ソース(source)となることはできない。宛先である場合、APは、所有するページの数を増加するが、データのビューは変更しない。
【0104】
ボリュームの拡張に関しては、APはボリュームとともに直ちに大きくなる。新しいページは、NULLボリュームを指す。APではないPITCは、ボリュームの拡張のために変更は必要ではない。
【0105】
それぞれのPITCは、入ってくるLBAを、基礎となるボリュームへのデータ・ページ・ポインタへとマッピングするテーブルを維持する。テーブルは、データ・ページへのポインタを含む。テーブルは、提示される論理空間よりも多くの物理ディスク空間をアドレスする必要がある。図9に、マルチ・レベル・インデックスを有するテーブル構造の一実施形態を示す。この構造は、ボリュームLBAを復号化してデータ・ページ・ポインタにする。各レベルでは、図9に示すように、アドレスの増加していくLSB(less significant bit)を復号化する。このテーブルの構造により、高速のルックアップおよびボリュームの拡張の機能が提供される。高速ルックアップのために、マルチ・レベル・インデックス構造は、テーブルを浅い状態に維持し、各レベルで複数のエントリをもつようにしている。このインデックスは、各レベルでアレイのルックアップを行う。ボリュームの拡張をサポートするため、マルチ・レベル・インデックス構造により、拡張をサポートするための別のレイヤを追加することが可能になっている。この場合のボリュームの拡張は、上位レイヤへ提示されるLBAカウント(計数)の拡張であり、そのボリュームへ割り当てられるストレージ空間の実際の量ではない。
【0106】
マルチ・レベル・インデックスは、ボリューム全体のデータ・ページ再マッピングの一覧(要約)を含む。それぞれのPITCは、記憶されたポイント・イン・タイム(時(特定の時))の、このボリュームに対する完全な再マッピング・リストを含む。
【0107】
マルチ・レベル・インデックス構造は、テーブルのレベルに対して異なるエントリ・タイプを使用する。異なるエントリ・タイプは、情報をディスクから読み出す必要性や、情報をメモリに格納する必要性をサポートする。ボトム・レベルのエントリは、データ・ページ・ポインタのみを含み得る。トップおよび中間のレベルのエントリは2つのアレイを含み、1つは次のレベルのテーブル・エントリのLBAであり、そして、テーブルへのメモリ・ポインタを含む。
【0108】
提示されるボリューム・サイズが拡張する際に、以前のPITCテーブルのサイズは増やす必要はなく、また、テーブルを変更する必要もない。テーブルの中の情報は、読み出し専用であるので、変わらず、そして、拡張プロセスは、テーブルを、NULLページ・ポインタを末尾に追加することによって、変更する。スナップショットは、以前のPITCからのテーブルを直接にユーザに提示しない。
【0109】
I/O動作があると、テーブルには、LBAをデータ・ページ・ポインタへマッピングすることが求められる。その場合、I/Oでは、データ・ページ・ポインタにデータ・ページ・サイズを乗算して、基礎となるRAIDのLBAを得る。一実施形態では、データ・ページ・サイズは、2のべき乗である。
【0110】
テーブルは、LBAの再マッピング、ページの追加、およびテーブルの合体のためのAPIを提供する。
【0111】
スナップショットは、PITCオブジェクトおよびLBAマッピング・テーブルを保存するためにデータ・ページを使用する。テーブルは、そのテーブル・エントリに対するI/OのためにRAIDインターフェースへ直接にアクセスする。テーブルは、RAID装置に対してそのテーブルの読み出しおよび書き込みを行うときの変更を最小にする。変更がない場合には、テーブルの情報の読み出しおよび書き込みを、テーブル・エントリ構造に対して直接に行うことが可能になる。これにより、I/Oのために必要となるコピーが低減される。スナップショットは、ディスク上のホット・スポットの発生を防ぐために、変化ログを使用することができる。ホット・スポットとは、ボリュームへの更新を追跡するために繰り返し使用される場所のことである。変化ログは、PITCテーブルへの更新、およびボリュームに関するフリー・リストを記録する。リカバリ中には、スナップショットは変化ログを使用して、メモリ内AP(in-memory AP)およびフリー・リスト(free list)の再作成を行う。図10にテーブルのリカバリの一実施形態を示し、これにより、メモリ内APと、ディスク上AP(on-disk AP)と、変化ログとの間の関係を示している。この図は、フリー・リストに関しても同じ関係を示している。メモリ内APテーブルは、ディスク上APテーブルおよびログから再構築することができる。どのようなコントローラ障害の場合でも、APは、ディスク上APを読み出してそれにログ変化を適用することによって、再構築される。変化ログは、システム・コンフィギュレーションに応じて、異なる物理資源を使用する。多重コントローラのシステムでは、変化ログは、ストレージのためにバッテリ−バックアップされたキャッシュ・メモリを頼りにしている。キャッシュ・メモリを使用することにより、スナップショットは、ディスクへのテーブル書き込みの数を減らし且つデータ・インテグリティを維持することができる。変化ログは、リカバリのためにバックアップ・コントローラに対しての複製を行う。単一コントローラのシステムでは、変化ログは、すべての情報をディスクへ書き込む。これには、ディスク上のログの場所にホット・スポットを発生させるという副作用がある。これにより、幾つもの変化を単一のデバイス・ブロックへ書き込むことが可能とされる。
【0112】
スナップショットは、定期的に、PITCテーブルおよびフリー・リストをディスクへ書き込んで、ログにおけるチェックポイントの作成およびそのクリアを行う。この期間は、PITCへの更新の数に応じて変わり得る。合体プロセスは変化ログを使用しない。
【0113】
スナップショットのデータ・ページI/Oは、要求がデータ・ページ境界内に収まることを必要とし得る。スナップショットは、ページ境界にまたがるI/O要求にであった場合に、その要求を分割する。次いで、スナップショットは、その要求を要求ハンドラへと渡す。書き込みおよび読み出しのセクションは、I/Oがページ境界内に収まることを仮定している。APは、LBA再マッピングを提供してI/O要求を満たす。
【0114】
APはすべての書き込み要求を満たす。スナップショットは、所有ページと非所有ページに対する2つの異なる書き込みシーケンスをサポートする。異なるシーケンスにより、テーブルへのページの追加が可能になる。図11に、所有ページ・シーケンスおよび非所有ページ・シーケンスがある書き込みプロセスの一実施形態を示す。
【0115】
所有ページ・シーケンスでは、プロセスは以下のものを含む。
1)テーブル・マッピングを見つける。
2)所有の書き込みをページングする(Page Owned Write) − LBAを再マッピングし、データをRAIDインターフェースへ書き込む。
【0116】
以前に書き込まれたページは、純粋な書き込み要求である。スナップショットは、データをそのページに書き込んで、現在の内容を上書きする。APの所有するデータ・ページだけが書き込まれる。他のPITCの所有するページは、読み出し専用である。
【0117】
非所有ページ・シーケンスでは、プロセスは以下のものを含む。
1)テーブル・マッピングを見つける。
2)以前のページを読み出す − そのデータ・ページに対する読み出しを行い、書き込み要求と読み取ったデータとでページ全部が出来上がるようにする。これが、コピー・オン・ライト(copy on write)・プロセスの開始となる。
3)データを組み合わせる − データ・ページの読み出しおよび書き込みの要求のペイロードを、単一の連続するブロックに入れる。
4)リスト割り当てを自由にする − 新しいデータ・ページ・ポインタを、フリー・リストから得る。
5)組み合わせたデータを、新しいデータ・ページへ書き込む。
6)新しいページ情報をログへ記憶する。
7)テーブルを更新する − テーブル内のLBA再マッピングを変更して、新しいデータ・ページ・ポインタを反映させる。これでデータ・ページはPITCにより所有される。
【0118】
ページを追加するには、そのページがテーブルに追加されるまで、読み出しおよび書き込みの要求を妨げることが必要であり得る。スナップショットは、テーブルの更新をディスクへ書き込み、ログの複数のキャッシュ記憶されたコピーを維持することにより、コントローラのコヒーレンシを達成する。
【0119】
読み出し要求に関して、APはすべての読み出し要求を満たす。読み出し要求は、APテーブルを用いて、LBAを、そのデータ・ページのLBAへ再マッピングする。再マッピングされたLBAはRAIDインターフェースへと渡されて、その要求が満たされる。ボリュームは、それまでにそのボリュームへ書き込まれていないデータ・ページに対する読み出し要求を満たすことができる。こうしたページは、PITCテーブルにおいてNULLアドレス(すべて1)でマークされている。このアドレスに対する要求は、NULLボリュームにより満たされ、一定のデータ・パターンを返す。異なるPITCテーブルの所有するページは、ページ境界にまたがる読み出し要求を満たすことができる。
【0120】
スナップショットは、NULLボリュームを使用して、以前に書き込まれていないデータ・ページに対する読み出し要求を満たす。これは、それぞれのセクタ読み出しに対して、すべてゼロを返す。これは、RAID装置も、割り当てられた空間もない。NULLボリュームに対する読み出しについてのデータ要件を満たすために、すべてゼロであるブロックをメモリ内に置いておくことが予期される。すべてのボリュームは、読み出し要求を満たすためにNULLボリュームを共用する。
【0121】
一実施形態では、合体プロセスが、PITCと、その所有ページの一部とをボリュームから取り除く。PITCを取り除くと、新しい差異を追跡するために使用可能な空間がより多く作成される。合体では、2つの隣接するテーブルを差異があるかどうか比較し、新しい差異だけを維持する。合体は、ユーザによるコンフィギュレーションに従って、定期的にまたは手動で起きる。
【0122】
このプロセスは、2つのPITC、即ち、ソースと宛先とを含む。一実施形態での、適格なオブジェクトについての規則は、次のようなものである。
1)ソースは、宛先に対して、以前のPITCでなければならない − ソースは宛先より前に作成されなければならない。
2)宛先は、同時にソースであってはならない。
3)ソースは、複数のPITCにより参照されてはならない。複数の参照は、ビュー・ボリュームがPITCから作成されたときに、起きる。
4)宛先は、複数の参照をサポートし得る。
5)APは宛先であり得るが、ソースではない。
【0123】
合体・プロセスは、すべての変更をディスクへ書き込むものであり、コヒーレンシを必要としない。コントローラが故障した場合に、ボリュームがPITC情報をディスクからリカバリし、合体プロセスを再開する。
【0124】
このプロセスは、2つのPITCを合体のためにマークするものであり、以下の諸ステップを含む。
【0125】
1)ソースの状態が合体のソースに設定される − この状態は、コントローラ障害のリカバリのために、ディスクへ記憶される。この時点で、ソースはもはやアクセスされないが、それは、そのデータ・ページが無効であるからである。データ・ページがフリー・リストへ返されるか、または所有権が宛先へ移される。
【0126】
2)宛先の状態が合体の宛先へ設定される − この状態は、コントローラ障害のリカバリのためにディスクへ記憶される。
【0127】
3)テーブルのロードおよび比較を行う − このプロセスは、データ・ページ・ポインタを移動させる。解放されたデータ・ページは、直ちにフリー・リストに追加される。
【0128】
4)宛先の状態が正常に設定される − プロセスが完了する。
【0129】
5)リストを調整する − ソースのnext(次)ポインタのprevious(以前)を、宛先へと変更する。これにより、ソースがリストから効率よく取り除かれる。
【0130】
6)ソースを解放する − 制御の情報に使用された何れのデータ・ページをも、フリー・リストへ戻す。
【0131】
上述のプロセスは、2つのPITCの組合せをサポートしている。合体を、単一のパスにおいて複数のPITCの削除と複数のソースの作成とを行うように設計できることが、当業者には理解されている。
【0132】
図2に示すように、ページ・プールは、そのページ・プールに関連するすべてのボリュームが使用するように、データ・ページ・フリー・リストを維持する。フリー・リスト・マネージャは、ページ・プールからのデータ・ページを使用して、フリー・リストを永久的ストレージへ記憶する。フリー・リストの更新を引き起こすものは幾つもあり、書き込みプロセスはページを割り当て、制御ページ・マネージャはページを割り当て、合体用プロセスはページを返す。
【0133】
フリー・リストは、それ自体をある閾値のところで自動的に拡張するためのトリガを維持することができる。このトリガは、ページをページ・プールへ追加するためのページ・プール拡張方法を使用する。自動的な拡張は、ボリューム・ポリシの一機能とすることもできる。重要度の高いデータ・ボリュームには拡張を可能にし、重要度の低いボリュームは強制的に合体させる。
【0134】
ビュー・ボリュームは、以前のポイント・イン・タイムへのアクセスを提供し、正常のボリュームI/O動作をサポートする。PITCは、PITC間の差異を追跡し、ビュー・ボリュームは、PITC内に含まれる情報へユーザがアクセスできるようにする。ビュー・ボリュームはPITCから分岐する。ビュー・ボリュームは、リカバリ、検査、バックアップ動作などをサポートする。ビュー・ボリュームの作成は、データ・コピーを必要としないので、ほぼ瞬間的に生じる。ビュー・ボリュームは、ビュー・ボリュームへの書き込みをサポートするために、それ自体のAPが必要になり得る。
【0135】
ボリュームの現在の状態から取られたビューでは、APを現在のボリュームのAPからコピーすることができる。APを用い、ビュー・ボリュームは、ビュー・ボリュームのへの書き込み動作を、基礎となるデータを変更せずに行うことを可能にする。OSは、データを使用するために、ファイル・システムまたはファイルの再構築を必要とし得る。ビュー・ボリュームは、APおよび書き込まれたデータ・ページに対して親ボリュームから空間を割り当てる。ビュー・ボリュームは、関連するRAID装置情報を有さない。ビュー・ボリュームを削除すると、空間が解放され親ボリュームへ戻される。
【0136】
図12に、スナップショットを用いてのあるボリュームに関する推移を示す例示的なスナップショット動作を示す。図12は、10ページをもつボリュームを示す。それぞれの状態(ステート)は、ボリュームに対する読み出し要求遂行(Read Request Fulfillment)リストを含む。影を付けたブロックは、所有データ・ページ・ポインタを示す。
【0137】
図の左側(即ち、初期状態)から図の中央への推移は、ページ3および8への書き込みを示している。ページ3への書き込みには、PITC I(AP)への変更が必要である。PITC Iは、新ページ書き込み処理に従い、ページ3をテーブルへ追加する。PITCは、変更されていない情報をページJから読み出し、ドライブ・ページBを使用してそのページを保存する。このPITCのページ3へのこれ以降のすべての書き込みは、ページを移動させずに取り扱われる。ページ8への書き込みでは、ページへの書き込みに関する第2の場合を示す。PITC Iはすでにページ8を含んでいるため、PITC Iは、ページ8のそのデータのその部分へ書き込む。この場合、それはドライブ・ページCに存在する。
【0138】
図の中央から図の右側(即ち、最終状態)への推移は、PITC IIとIIIとの合体を示す。スナップショットの合体は、それぞれ、古いページを削除すること、および両方のPITCにおけるすべての変更を維持することを含む。両方のPITCがページ3および8を含む。プロセスは、PITC IIからのの新しい方のページを保ち、PITC IIIからのページを解放し、ページAおよびDをフリー・リストへ返す。
【0139】
スナップショットは、フリー・リストおよびPITCテーブル情報を保存するために、ページ・プールからデータ・ページの割り当てを行う。制御ページの割り当ては、データ・ページを、オブジェクトに必要とされるサイズに合うように、更に細かく割り当てる(sub-allocate)。
【0140】
ボリュームは、制御ページ情報の先頭に対するページ・ポインタを含む。このページから、他のすべての情報を読み出すことができる。
【0141】
スナップショットは、特定の時間間隔で、使用中のページの数を追跡する。これにより、スナップショットは、いつユーザがシステムに更なる物理ディスク空間を追加する必要があるかを予測して、スナップショットが不足するのを防ぐ。
【0142】
データ・プログレッション
本発明の一実施形態では、データ・プログレッション(DP、data progression)を使用して、データを、徐々に、適切なコストのストレージ空間へと移動させる。本発明により、ユーザは、ドライブが実際に必要であるときにドライブの追加を行える。これにより、ディスク・ドライブのコスト全体が著しく低減される。
【0143】
データ・プログレッションでは、最近アクセスされていないデータおよび履歴のスナップショット・データを、より安価なストレージへ移動させる。最近アクセスされていないデータについては、最近アクセスされていないページがに対してのストレージのコストを徐々に低減する。データは、コストが最も低いストレージへ直ちに移動させない。履歴のスナップショット・データについては、読み出し専用ページを、例えばRAID5などのようなより効率のよいストレージ空間へ移動させ、また、そのページにもはやボリュームからアクセス可能でない場合には、最も安価なストレージへ移動される。
【0144】
本発明のデータ・プログレッションの他の利点は、現在アクセス中のデータへの高速のI/Oアクセスを維持すること、および高速であるが高価なディスク・ドライブを購入する必要性を減らすことを含む。
【0145】
データ・プログレッションでは、動作時に、ストレージのコストを、物理メディアのコストおよびデータ保護に使用されるRAID装置の効率を用いて、判定する。また、データ・プログレッションでは、ストレージ効率を判定し、それに従ってデータの移動を行う。例えば、データ・プログレッションは、物理ディスク空間をより効率よく使用するために、RAID10装置をRAID5装置へと変換することができる。
【0146】
データ・プログレッションでは、アクセス可能なデータを、サーバが現在読み出しまたは書き込みできるデータと定義している。データ・プログレッションでは、アクセス可能性(accessibility)を使用して、ページが使用すべきストレージのクラスを決定する。ページは、履歴PITCに属する場合には、読み出し専用である。サーバが、一番最近のPITCにおいてそのページを更新していない場合には、そのページはまだアクセス可能である。
【0147】
図17に、データ・プログレッション動作におけるアクセス可能なデータ・ページの一実施形態を示す。アクセス可能なデータ・ページは、以下のカテゴリに分かれる。
【0148】
・アクセス可能な、最近アクセスされたもの − これらは、ボリュームが最もよく使用しているアクティブ・ページである。
【0149】
・アクセス可能な、最近アクセスされていないもの − 最近使用されていない読み出し/書き込みページ。
【0150】
・履歴のアクセス可能なもの − ボリュームによる読み出しが行える読み出し専用ページ −− スナップショット・ボリュームに当てはまる。
【0151】
・履歴のアクセス不能なもの − ボリュームによって現在アクセスされていない読み出し専用データ・ページ −− スナップショット・ボリュームに当てはまる。スナップショットは、こうしたページをリカバリ目的で維持し、ページは、一般に、可能な限り低コストのストレージに置かれる。
【0152】
図17に、スナップショット・ボリューム用の様々な所有ページを有する3つのPITCを示している。動的容量のボリュームは、PITC Cだけで代表させてある。すべてのページは、アクセス可能であり読み出し/書き込みである。ページは異なるアクセス時間を有し得る。
【0153】
下記のテーブルは、様々なストレージ装置を、効率の高くなる順または金銭的な支出の減る順に示す。ストレージ装置のリストは、より遅い書き込みI/Oアクセスの一般的な順序にも従い得る。データ・プログレッションでは、論理保護空間の効率をRAID装置の総物理空間で割ったものを計算する。
【0154】
【表1】
【0155】
RAID5の効率は、ストライプのドライブ数が増えると高くなる。ストライプのディスク数が増えると、フォールト・ドメインが増大する。ストライプのドライブ数の増加により、RAID装置の作成に必要なディスクの最小数も増える。一実施形態では、データ・プログレッションは、9ドライブを超えるRAID5ストライプ・サイズを使用しない。なぜなら、フォールト・ドメイン・サイズが増え、効率の増加が限られるからである。データ・プログレッションは、スナップショット・ページ・サイズの整数倍であるRAID5ストライプ・サイズを使用する。これにより、データ・プログレッションは、ページをRAID5へと移動させるときにフル・ストライプ書き込みを行えるようになり、移動の効率を高める。すべてのRAID5コンフィギュレーションは、データ・プログレッションの目的で、同じ書き込みI/O特性を有する。例えば、2.5インチ(6.5cm)FCディスク上のRAID5は、そうしたディスクの性能を効率よく使用しない可能性がある。この組合せを防ぐために、データ・プログレッションは、あるRAIDタイプが特定のディスクタイプ上で動作しないようにする機能をサポートする必要がある。また、データ・プログレッションのコンフィギュレーションは、システムがRAID10またはRAID5の空間を使用しないようにすることもできる。
【0156】
ディスクのタイプを次のテーブルに示す。
【0157】
【表2】
【0158】
データ・プログレッションは、システム内のドライブに相対的なディスク・ドライブの分類を自動的に行う機能を含む。システムは、ディスクを検査して、そのパフォーマンスをシステム内の他のディスクと比較して決定する。より速いディスクは高評価区分へと分類され、より遅いディスクは低評価区分へと分類される。ディスクがシステムへ追加されると、システムは、ディスクの評価分類のバランスを自動的にとり直す。このアプローチでは、決して変化することのないシステムと、新しいディスクが追加されると頻繁に変化するシステムとの双方を取り扱う。この自動分類は、複数のドライブ・タイプを同じ評価区分内に入れることがある。ドライブの評価がかなり近接しているものと判定された場合には、その評価は同じになる。
【0159】
一実施形態では、システムは次のドライブを含む。即ち、
高 − 10K FCドライブ
低 − SATAドライブ
【0160】
15K FCドライブを追加すると、データ・プログレッションは、ディスクを自動的に再分類し、10K FCドライブを降格させる。この結果として次の分類となる。
高 − 15K FCドライブ
中 − 10K FCドライブ
低 − SATAドライブ
【0161】
別の実施形態では、システムには次のドライブ・タイプを有し得る。
高 − 25K FCドライブ
低 − 15K FCドライブ
【0162】
従って、15K FCドライブは評価の低い区分として分類され、これに対して15K FCドライブは評価の高い区分として分類される。
【0163】
SATAドライブがシステムに追加された場合、データ・プログレッションは、ディスクを時間的に再分類する。その結果として次の分類となる。
高 − 25K FCドライブ
中 − 15K FCドライブ
低 − SATAドライブ
【0164】
データ・プログレッションは、ウォーターフォール(waterfall)・プログレッションを含むことができる。典型的に、ウォーターフォール・プログレッションはデータをより安価な資源へ移動させるが、その移動は、その資源が完全に使用されたときにのみ行う。ウォーターフォール・プログレッションは、最も高価なシステム資源の使用を効率的に最大化する。システムのコストの最小化も行う。安いディスクを最も低いプールに追加すると、ボトム(底部)において、より大きなプールが作成される。
【0165】
典型的なウォーターフォール・プログレッションは、RAID10空間を使用し、次いで、RAID5空間などのような、RAID空間の次のものを使用する。このことにより、ウォーターフォールが次のクラスのディスクのうちのRAID10へ直接向かうように強制される。代替例として、データ・プログレッションは、図24に示すような混合RAIDウォーターフォール・プログレッションを含んでもよい。この代替のデータ・プログレッション方法により、ディスク空間およびパフォーマンスを最大化する問題が解決され、ストレージは同じディスク・クラスにおいて更に効率のよい形式へと変形できる。また、この代替方法では、RAID10およびRAID5が或るディスク・クラスの資源全体を共用するという要件をサポートする。これには、あるRAIDレベルがあるクラスのディスク用に使用する、ディスク空間の一定の割合をコンフィギュレーションすることが必要であることがある。従って、この代替のデータ・プログレッション方法では、高価なストレージの使用が最大化され、かつ、別のRAIDクラスが共存する余地を残す。
【0166】
また、混合RAIDウォーターフォールでは、ストレージが限られているときのみ、ページをより安価なストレージへと移動させる。ディスク空間全体のうちの或るパーセンテージなどのような閾値により、特定のRAIDタイプのストレージの量が制限される。これにより、システムにおける最も高価なストレージの使用が最大化される。ストレージがその限度に近づくと、データ・プログレッションは、ページを、コストのより低いストレージへと自動的に移動させる。データ・プログレッションは、書き込みスパイクに対するバッファを提供することができる。
【0167】
上述のウォーターフォール方法では、一部の場合のように、ページをコストが最も低いストレージへと直ちに移動させ得るということが理解され、履歴およびアクセス不能のページをより安価なストレージ上へ適時に移動させる必要性があり得る。また、履歴ページをより安価なストレージへ直ちに移動させることもできる。
【0168】
図18に、データ・プログレッションのプロセス1800の流れ図を示す。データ・プログレッションは、システムのそれぞれのページを、そのアクセスのパターンおよびストレージのコストに関して絶えず検査して、移動させるべきデータ・ページがあるかどうか判定する。また、データ・プログレッションは、ストレージがその最大割り当て量に達しているかどうかを判定することもできる。
【0169】
データ・プログレッションのプロセスは、そのページがどのボリュームからもアクセス可能かどうかを判定する。プロセスは、履歴に付加されている各ボリュームについてのPITCを検査して、そのページが参照されているかどうかを判定する。そのページがアクティブに使用中である場合には、そのページは昇格させるに又は降格を遅くするに望ましい。そのページがどのボリュームからもアクセス可能でない場合には、使用可能な最も低コストのストレージへ移動させられる。また、データ・プログレッションは、PITCが期限切れになる前に時間を計算に入れる。スナップショットで、PITCがまもなく期限切れになるようにスケジュールしている場合には、ページのプログレッションは行わない。ページ・プールがアグレッシブ・モードで動作中の場合には、ページのプログレションが行われ得る。
【0170】
データ・プログレッションの最近アクセス検出(recent access detection、最近されたアクセスの検出)では、ページの昇格動作から一塊の活動を取り除く必要がある。データ・プログレッションでは、読み出しと書き込みのアクセス追跡を分離している。これにより、データ・プログレッションは、アクセス可能であるRAID5装置上のデータを保持することが可能とされる。ウイルスのスキャンや報告などのような動作は、データを読み出すのみである。データ・プログレッションは、ストレージが残り少なくなっているときに、最近アクセス(recent access)の資格を変更する。これにより、データ・プログレッションは、ページの降格をよりアグレッシブに行えるようになる。また、これは、ストレージが残り少なくなっているときに、システムをボトム(底)の方から詰めていくのに役立つ。
【0171】
データ・プログレッションは、システム資源が少なくなるとデータ・ページをアグレッシブ(積極的)に移動させることができる。より多くのディスクまたはコンフィギュレーションの変更は、こうした場合のすべてでやはり必要である。データ・プログレッションは、時間のない状況においてシステムが動作し得る時間の量を延ばす。データ・プログレッションは、システムをできるだけ長く動作可能に保つように試みる。その時間とは、そのすべてのストレージ・クラスの空間がなくなるときである。
【0172】
RAID10空間が残り少なくなっており、使用可能なディスク空間全体が残り少なくなっている場合には、データ・プログレッションは、RAID10ディスク空間を取り上げて、より効率のよいRAID5へと移動させることができる。これにより、システムの全体容量が、書き込み性能を犠牲にして、増加する。より多くのディスクはやはり必要である。特定のストレージ・クラスが完全に使用された場合、データ・プログレッションは、受け入れ可能でないページを借りてシステムを動作させ続けることができる。例えば、あるボリュームが、RAID10―FCを、そのアクセス可能情報用に使用するようにコンフィギュレーションされている場合に、より多くのRAID10−FC空間が使用可能になるまで、RAID5−FCまたはRAID10−SATAからページを割り当てる。
【0173】
また、データ・プログレッションは、システムの知覚される容量を増加させるための圧縮をサポートする。圧縮が使用されるのは、アクセスされていない履歴ページに対して、またはリカバリ情報の記憶のためにである。圧縮は、ストレージ・コストの最下部近くの別のクラスのストレージとして現れる。
【0174】
図25に示すように、ページ・プールは、本質的に、フリー・リストおよび装置情報を含む。ページ・プールは、複数のフリー・リスト、強化されたページ割り当て方式、およびフリー・リストの分類をサポートする必要がある。ページ・プールは、ストレージのクラスごとに別々のフリー・リストを維持する。この割り当て方式により、ページを多くのプールのうちの1つから割り当て、且つ、許可される最小または最大のクラスを設定する。フリー・リストの分類は、装置のコンフィギュレーションに由来する。それぞれのフリー・リストは、統計の収集および表示のためにそれ自体のカウンタを提供する。また、それぞれのフリー・リストは、ストレージ効率の統計の収集のためのRAID装置効率情報を提供する。
【0175】
一実施形態では、装置リストには、ストレージ・クラスのコストを追跡する更なる機能が必要であり得る。組合せにより、ストレージのクラスが決定される。これが起きるのは、ユーザが、コンフィギュレーションしたクラスの粒度がより荒いまたは細かいものであることを希望する場合である。
【0176】
図26に、高性能のデータベースの一実施形態を示しており、ここでは、すべてのアクセス可能なデータは、最近アクセスされていない場合でも、2.5FCドライブ上にある。アクセス不能な履歴データは、RAID5ファイバ・チャネルへ移動される。
【0177】
図27は、MRI画像ボリュームの一実施形態を示しており、ここでは、アクセス可能なストレージは、この動的なボリューム用のSATA RAID10およびRAID5である。画像が最近アクセスされていない場合、画像はRAID5へ移動される。その場合、新しい書き込みは、初めはRAID10へ向かう。図19は、圧縮されたページ・レイアウトの一実施形態を示す。データ・プログレッションは、圧縮を、固定サイズのデータ・ページを更に細かく割り当てることによって、実装する。更に細かい割り当て(sub-allocation、サブ・アロケーション)の情報は、ページの空きの部分、およびページの割り当て済みの部分の場所を追跡する。データ・プログレッションは、圧縮の効率を予測することはできないが、そのサブ・アロケーション範囲内で可変サイズのページを取り扱うことができる。
【0178】
圧縮されたページは、CPUの性能に著しく影響することがある。書き込みアクセスの場合、圧縮されたページは、ページ全体の圧縮解除および再圧縮が必要となるはずである。従って、アクティブにアクセスされているページは、圧縮されず、非圧縮の状態に戻される。書き込みは、ストレージが極度に限られた状況で必要となり得る。
【0179】
PITC再マッピング・テーブルは、サブ・アロケーション情報を指し、圧縮されているページを示すようにマークされる。圧縮されたページにアクセスするには、非圧縮のページよりも高いI/Oカウントが必要になり得る。アクセスには、実際のデータの場所を取り出すために、サブ・アロケーション情報の読み出しが必要になる。圧縮されたデータは、ディスクから読み出し、プロセッサで圧縮解除することができる。
【0180】
データ・プログレッションでは、圧縮は、ページ全体のうちの一部を圧縮解除できるようにすることが必要とされ得る。これにより、データ・プログレッションの読み出しアクセスは、そのページの小さな部分のみの圧縮解除を行える。読み出しキャッシュの先読み機能は、圧縮の遅延に対して役立ち得る。一つの圧縮解除で、幾つものサーバI/Oを取り扱うことができる。データ・プログレッションは、圧縮の候補として適さないページにマークし、それによって、或るページの圧縮を続けて試みないようにする。
【0181】
図20に、本発明の諸原理に従った、高レベルのディスク・ドライブ・システムにおけるデータ・プログレッションの一実施形態を示す。データ・プログレッションは、ボリュームの外面的な振る舞いやデータ・パスの動作を変更しない。データ・プログレッションは、ページ・プールへの変更を必要とし得る。ページ・プールは、本質的に、フリー・リストおよび装置情報を含む。ページ・プールは、複数のフリー・リスト、強化されたページ割り当て方式、およびフリー・リストの分類をサポートする必要がある。ページ・プールは、ストレージのそれぞれのクラスに対して個々のフリー・リストを維持する。割り当て方式は、許可される最小および最大のクラスを設定しつつ、ページが多くのプールのうちの1つから割り当てられるようにする。フリー・リストの分類は、装置のコンフィギュレーションに由来することができる。それぞれのフリー・リストは、統計の収集および表示のためにそれ自体のカウンタを提供する。また、それぞれのフリー・リストは、ストレージの効率の統計の収集のためにRAID装置効率情報を提供する。
【0182】
PITCは、移動の候補を識別し、その移動のときには、アクセス可能なページへのI/Oを妨げる。データ・プログレッションは、候補に関してPITCを継続的に検査する。ページのアクセス可能性は、サーバI/O、新しいスナップショット・ページ更新、およびビュー・ボリュームの作成/削除に起因して、継続的に変化する。また、データ・プログレッションは、ボリュームのコンフィギュレーションの変更を継続的に検査し、ページのクラスおよびカウントの現在のリストをまとめあげる。これにより、データ・プログレッションは、そのまとめ(一覧)を評価し、移動するページがあるかを判定できる。
【0183】
それぞれのPITCは、ストレージの各クラスに使用されるページの数に関するカウンタを提示する。データ・プログレッションは、この情報を使用して、閾値に達したときにページを移動させるための良い候補になるPITCを識別する。
【0184】
RAIDは、ディスクのコストに基づいて、1組のディスクから装置を割り当てる。また、RAIDは、装置または潜在的な装置の効率を取り出すAPIを提供する。また、これは、書き込み動作に必要なI/Oの数についての情報を返す必要がある。また、データ・プログレッションは、また、サード・パーティのRAIDコントローラをデータ・プログレッションの一部として使用するために、RAID NULLを必要とし得る。RAID NULLは、ディスク全体を消費し得、単にパス・スルー・レイヤとして働き得る。
【0185】
また、ディスク・マネージャは、ディスク分類を自動的に決定し保存することができる。ディスク分類を自動的に決定するには、SCSIイニシエータへの変更が必要となり得る。
【0186】
上述の説明および図面から、ここに示し説明した特定の諸実施形態は、もっぱら例示を目的としており、本発明の範囲を限定するものではないことが当業者には理解されよう。本発明を他の特定の形式で実施することは、その趣旨または本質的な諸特徴から逸脱することなく行えることが当業者には理解されよう。特定の諸実施形態の詳細への言及は、本発明の範囲を限定するものではない。
【技術分野】
【0001】
本発明は、一般には、ディスク・ドライブのシステムおよび方法に関し、より詳細には、動的データ割り当てやディスク・ドライブ仮想化などの機能を有するディスク・ドライブ・システムに関する。
【背景技術】
【0002】
既存のディスク・ドライブ・システムは、仮想ボリューム(virtual volume)・データ・ストレージ空間が、データの格納のための特定のサイズおよび場所を有する物理ディスクと静的に関連するように、設計されている。こうしたディスク・ドライブ・システムでは、データを格納するために、データ・ストレージ空間の仮想ボリュームの厳密な場所およびサイズを知ること及び監視/制御を行うことが必要である。更に、このシステムでは、しばしば、より大きなデータ・ストレージ空間が必要であり、そのため、RAID装置が追加される。しかし、しばしば、こうした追加のRAID装置は、高価であり、また、余分なデータ・ストレージ空間が実際に必要となるまでは、必要ではない。
【0003】
図14のAに、データの格納、読み出し/書き込み、および/またはリカバリ(復旧)のための特定のサイズおよび場所を有する物理ディスクと関連する仮想ボリューム・データ・ストレージ空間を有する従来の既存のディスク・ドライブ・システムを示す。このディスク・ドライブ・システムでは、データの割り当てを、データ・ストレージ空間の仮想ボリュームの特定の場所およびサイズに基づいて、静的に行う。その結果、空のデータ・ストレージ空間は使用されず、このシステムでデータを格納、読み出し/書き込み、および/またはリカバリするために、余分であり時には高価なデータ・ストレージ装置、例えばRAID装置が前もって獲得される。こうした余分なデータ・ストレージ空間は、必要でなく、かつ/または、後の時まで使用されない可能性がある。
【発明の概要】
【0004】
従って、改善されたディスク・ドライブのシステムおよび方法が必要とされている。効率のよい、動的なデータ割り当てならびにディスク・ドライブの空間および時間管理のシステムおよび方法が更に必要とされている。
【0005】
本発明は、動的にデータを割り当てる能力を有する改善されたディスク・ドライブのシステムおよび方法を提供する。このディスク・ドライブ・システムは、ディスク・ストレージ・ブロックのマトリックスを有するRAIDサブシステムと、少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャとを含むことができる。RAIDサブシステムおよびディスク・マネージャは、RAIDからディスクへのマッピング(RAID-to-disk mapping、RAID−ツー−ディスク・マッピング)に基づいて、ディスク・ストレージ・ブロックのマトリックスおよび複数のディスク・ドライブを通して、データを動的に割り当てる。RAIDサブシステムおよびディスク・マネージャは、更に別のディスク・ドライブが必要かどうかを判定し、更に別のディスク・ドライブが必要である場合には、通知を送る。動的なデータの割り当て(アロケーション)により、ユーザは、ディスク・ドライブを、後の時間に、必要となったときに得ることができる。また、動的データ割り当てにより、ディスク・ストレージ・ブロックの仮想ボリューム・マトリックスまたはプールのスナップショット/ポイント・イン・タイム(時)・コピーの効率のよいデータ格納や、データのバックアップ、リカバリなどのためのインスタント・データ・リプレイおよびデータ・インスタント・フュージョン(fusion)や、リモート・データ・ストレージや、データ・プログレッション(Data Progression)などが、可能になる。また、データ・プログレッションにより、より安価なディスク・ドライブは、後の時間に購入されるため、延期が可能になる。
【0006】
一実施形態では、仮想ボリュームまたはディスク・ストレージ・ブロックのマトリックスまたはプールが、物理ディスクと関連付けるために提供される。仮想ボリュームまたはディスク・ストレージ・ブロックのマトリックスまたはプールの監視/制御は、複数のディスク・ストレージ・システム・コントローラによって動的に行われる。一実施形態では、それぞれの仮想ボリュームのサイズはデフォルトまたはユーザの予め定義したものとすることができ、それぞれの仮想ボリュームの場所はデフォルトでヌル(null)となっている。仮想ボリュームは、データが割り当てられるまでヌルである。データは、マトリックスまたはプールの任意のグリッドに割り当てることができる(例えば、データがそのグリッドに割り当てられた後は、そのグリッド内の「ドット」(dot)になる)。そのデータが削除された後、その仮想ボリュームは再び使用可能になり「null」として示される。このため、余分なデータ・ストレージ空間や、時には高価なデータ・ストレージ装置、例えばRAID装置を、後の時間に、必要となるたびに得ることができる。
【0007】
一実施形態では、1つのディスク・マネージャが複数のディスク・ストレージ・システム・コントローラを管理することができ、複数の冗長ディスク・ストレージ・システム・コントローラを実装して、動作させているディスク・ストレージ・システム・コントローラの障害をカバーすることができる。
【0008】
一実施形態では、RAIDサブシステムは、RAID−0、RAID−1、RAID−5、RAID−10などのRAIDタイプのうちの少なくとも1つからなる組合せを含む。代替のRAIDサブシステムでは、RAID−3、RAID−4、RAID−6、RAID−7などのような他のRAIDタイプを使用できることも理解されよう。
【0009】
また、本発明は、動的データ割り当ての方法を提供するものであり、この方法は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを与えて、RAIDサブシステムのディスク空間がディスク・ストレージ・ブロックのマトリックスを形成するようにするステップと、データを書き込み、そのデータをディスク・ストレージ・ブロックのマトリックスに割り当てるステップと、RAIDサブシステムのディスク空間の占有率の履歴に基づいて、RAIDサブシステムのディスク空間の占有率の決定するステップと、更に別のディスク・ドライブが必要かどうかを決定するステップと、更に別のディスク・ドライブが必要である場合に、RAIDサブシステムに通知を送るステップとを含む。一実施形態では、通知は電子メールによって送られる。
【0010】
本発明のディスク・ドライブ・システムの利点の1つは、RAIDサブシステムが、仮想的な数のディスクにわたってRAID技法を使用できることである。残りのストレージ空間は自由に使用可能である。RAIDサブシステムのストレージ空間を監視し、そのストレージ空間の占有率を決定することにより、ユーザは、高価であるが購入時点では用途のない大量のドライブを得なくて済む。こうして、ドライブの追加を、ストレージ空間の増大する需要を満たすために実際に必要であるときに行うことにより、ディスク・ドライブの全体のコストが著しく低減される。その一方で、ドライブの使用の効率は著しく改善される。
【0011】
本発明の別の利点は、ディスク・ストレージ・システム・コントローラが、特定のコンピュータ・ファイル・システムだけでなく、どのようなコンピュータ・ファイル・システムに対しても普遍的であることである。
【0012】
また、本発明は、データ・インスタント・リプレイ(data instant replay)の方法を提供する。一実施形態では、データ・インスタント・リプレイの方法は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを与えて、RAIDサブシステムのディスク空間がストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスを形成するようにするステップと、ストレージのページ・プールのボリュームのスナップショットまたはディスク・ストレージ・ブロックのマトリックスのスナップショットを、所定の時間間隔で自動的に生成するステップと、スナップショットまたは変分(delta、デルタ)のアドレス・インデックスを、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスに保存して、ディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタを、その保存したアドレス・インデックスを介して直ちに見つけ出せるようにするステップとを含む。
【0013】
このデータ・インスタント・リプレイの方法では、RAIDサブシステムのスナップショットの自動生成を、ユーザの定義する時間間隔で、または、ユーザのコンフィギュレーションした動的なタイム・スタンプ、例えば、数分または数時間ごとなどに、または、サーバの指示する時刻に、行う。システム障害またはウイルス攻撃が発生した場合、こうしたタイム・スタンプを有する仮想スナップショットにより、データ・インスタント・リプレイおよびデータ・インスンタント・リカバリが、約数分または数時間などで可能になる。この技法は、インスタント・リプレイ・フュージョン(instant replay fusion)とも呼ばれる。即ち、クラッシュまたは攻撃のすぐ前のデータのフュージョンが遅れずに行われ、クラッシュまたは攻撃の前に保存したスナップショットを直ちにそれ以降の動作で使用することができる。
【0014】
一実施形態では、スナップショットをローカルのRAIDサブシステムまたはリモートのRAIDサブシステムで保存し、重大なシステム・クラッシュが例えばテロリスト攻撃などが原因で生じた場合に、データの完全性(integrity)に対しての影響を受けないようにし、データを直ちにリカバリできるようにすることができる。
【0015】
このデータ・インスタント・リプレイの方法の別の利点は、スナップショットを、システムが動作し続けたままで、検査のために使用できることである。生(live)のデータをリアル・タイムの検査に使用することができる。
【0016】
また、本発明は、RAIDサブシステムと、少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャとを含むデータ・インスタント・リプレイのシステムを提供する。一実施形態では、RAIDサブシステムおよびディスク・マネージャは、複数のドライブのディスク空間にわたって、データを、RAID−ツー−ディスク・マッピングに基づいて動的に割り当てるものであり、ここでRAIDサブシステムのディスク空間は、ディスク・ストレージ・ブロックのマトリックスを形成する。ディスク・ストレージ・システム・コントローラは、ディスク・ストレージ・ブロックのマトリックスのスナップショットを所定の時間間隔で自動的に生成し、スナップショットまたはデルタのアドレス・インデックスをディスク・ストレージ・ブロックのマトリックスに保存して、ディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタを、その保存したアドレス・インデックスを介して直ちに見つけ出せるようにする。
【0017】
一実施形態では、ディスク・ストレージ・システム・コントローラは、ディスク・ストレージ・ブロックのマトリックスのスナップショットからデータ使用の頻度を監視し、そして、使用またはアクセスの頻度の低いデータほど、より安価なRAIDサブシステムへと移動させるような、エージング(aging、加齢)規則を適用する。同様に、安価なRAIDサブシステム中のデータが頻繁に使用され始めると、コントローラは、そのデータを、より高価なRAIDサブシステムへと移動させる。このため、ユーザは、ユーザ自身のストレージに対する必要性を満たす所望のRAIDサブシステム・ポートフォリオを選ぶことができる。従って、ディスク・ドライブ・システムのコストを著しく低減させること、およびユーザにより動的に制御することが可能となる。
【0018】
本発明のこうしたおよび他の特徴および利点は、本発明を実現するために企図された最良の形態を含む本発明の例示的な実施形態を示し説明する以下の詳細な説明から、当業者に明らかとなろう。本発明は、様々な自明な態様における変更が、すべて本発明の趣旨および範囲から逸脱することなく可能であることが理解されよう。従って、図面および詳細な説明は、本来例示的であって限定的でないと見なすべきである。
【図面の簡単な説明】
【0019】
【図1】図1は、本発明の諸原理に従ったコンピュータ環境におけるディスク・ドライブ・システムの一実施形態を示す。
【図2】図2は、本発明の諸原理に従った、ディスク・ドライブのRAIDサブシステムのためのストレージのページ・プールを有する動的なデータ割り当ての一実施形態を示す。
【図2A】図2Aは、ディスク・ドライブ・システムのRAIDサブシステムにおける従来のデータ割り当てを示す。
【図2B】図2Bは、本発明の諸原理に従った、ディスク・ドライブ・システムのRAIDサブシステムにおけるデータ割り当てを示す。
【図2C】図2Cは、本発明の諸原理に従った動的なデータ割り当ての方法を示す。
【図3】図3のAおよびBは、本発明の諸原理に従った、複数の時間間隔におけるRAIDサブシステムのディスク・ストレージ・ブロックのスナップショットの概略図であり、Cは、本発明の諸原理に従ったデータ・インスタント・リプレイの方法を示す。
【図4】図4は、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することによるデータ・インスタント・フュージョン機能の概略図である。
【図5】図5は、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することによるローカル/リモートのデータの複製およびインスタント・リプレイの機能の概略図である。
【図6】図6は、本発明の諸原理に従った、I/Oを行うために同じRAIDインターフェースを使用し、複数のRAID装置を1つのボリュームへと連結するスナップショットの概略図を示す。
【図7】図7は、本発明の諸原理に従った、スナップショット構造の一実施形態を示す。
【図8】図8は、本発明の諸原理に従った、PITCライフ・サイクルの一実施形態を示す。
【図9】図9は、本発明の諸原理に従った、マルチ・レベル・インデックスを有するPITCテーブル構造の一実施形態を示す。
【図10】図10は、本発明の諸原理に従った、PITCテーブルのリカバリの一実施形態を示す。
【図11】図11は、本発明の諸原理に従った、所有ページ・シーケンスおよび非所有ページ・シーケンスを有する書き込みプロセスの一実施形態を示す。
【図12】図12は、本発明の諸原理に従った、例示的なスナップショット動作を示す。
【図13A】図13Aは、データを静的に割り当てるために特定のサイズおよび場所をもつ物理ディスクと関連付けられた仮想ボリューム・データ・ストレージ空間を有する従来の既存のディスク・ドライブ・システムを示す。
【図13B】図13Bは、図13Aの従来の既存のディスク・ドライブ・システムでのボリューム論理ブロック・マッピングを示す。
【図14】図14のAは、本発明の諸原理に従った、システムにおいてデータを動的に割り当てるための、ディスク・ストレージ・ブロックの仮想ボリューム・マトリックスを有するディスク・ドライブ・システムの一実施形態を示す。図14のBは、図14のAに示すディスク・ストレージ・ブロックの仮想ボリューム・マトリックスにおける動的なデータ割り当ての一実施形態を示す。図14のCは、本発明の諸原理に従った、ストレージの仮想ボリューム・ページ・プールの一実施形態のボリューム−RAIDページ再マッピングの概略図を示す。
【図15】図15は、本発明の諸原理に従った、RAIDサブシステムの複数のディスク・ストレージ・ブロックへマッピングされる3つのディスク・ドライブの例を示す。
【図16】図16は、図15に示す3つのディスク・ドライブへ1つのディスク・ドライブを追加した後のディスク・ドライブ・ストレージ・ブロックの再マッピングの例を示す。
【図17】図17は、本発明の諸原理に従った、データ・プログレッション動作におけるアクセス可能なデータ・ページの一実施形態を示す。
【図18】図18は、本発明の諸原理に従った、データ・プログレッション・プロセスの一実施形態の流れ図を示す。
【図19】図19は、本発明の諸原理に従った、圧縮されたページ・レイアウトの一実施形態を示す。
【図20】図20は、本発明の諸原理に従った、高レベル・ディスク・ドライブ・システムにおけるデータ・プログレッションの一実施形態を示す。
【図21】図21は、本発明の諸原理に従った、サブシステムにおける外部データ・フローの一実施形態を示す。
【図22】図22は、サブシステムにおける内部データ・フローの一実施形態を示す。
【図23】図23は、コヒーレンシを独立して維持する各サブシステムの一実施形態を示す。
【図24】図24は、本発明の諸原理に従った、混合RAIDウォーターフォール・データ・プログレッションの一実施形態を示す。
【図25】図25は、本発明の諸原理に従った、ストレージのページ・プールの複数のフリー・リストの一実施形態を示す。
【図26】図26は、本発明の諸原理に従った、データベースの例の一実施形態を示す。
【図27】図27は、本発明の諸原理に従った、MRI画像の例の一実施形態を示す。
【発明を実施するための形態】
【0020】
本発明は、動的にデータを割り当てる能力を有する改善されたディスク・ドライブのシステムおよび方法を提供する。このディスク・ドライブ・システムは、RAIDの空きリスト(フリー・リスト、free list)を維持するストレージのページ・プール、または代替例としてはディスク・ストレージ・ブロックのマトリックスを有するRAIDサブシステムと、少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャとを含むことができる。RAIDサブシステムおよびディスク・マネージャは、データを、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスおよび複数のディスク・ドライブにわたって、RAID−ツー−ディスク・マッピングに基づいて、動的に割り当てる。RAIDサブシステムおよびディスク・マネージャは、更に別のディスク・ドライブが必要かどうかを判定し、更に別のディスク・ドライブが必要である場合には通知を送る。動的なデータ割り当てにより、ユーザは、ディスク・ドライブを、後にそれが必要となったときに得ることができる。また、動的なデータ割り当てにより、ディスク・ストレージ・ブロックの仮想ボリュームのマトリックスまたはプールのスナップショット/ポイント・イン・タイム・コピーの効率のよいデータ・ストレージや、データ・バックアップやリカバリなどのためのインスタント・データ・リプレイおよびデータ・インスタント・フュージョン(fusion)や、リモート・データ・ストレージや、データ・プログレッションなどが可能になる。また、データ・プログレッションにより、より安価なディスク・ドライブは後の時間に購入されるため、その延期が可能になる。
【0021】
図1に、本発明の諸原理に従った、コンピュータ環境102におけるディスク・ドライブ・システム100の一実施形態を示す。図1に示すように、ディスク・ドライブ・システム100は、RAIDサブシステム104と、少なくとも1つのディスク・ストレージ・システム・コントローラ(図16)を有するディスク・マネージャ106とを含む。RAIDサブシステム104およびディスク・マネージャ106は、データを、複数のディスク・ドライブ108のディスク空間にわたって、RAID−ツー−ディスク・マッピングに基づいて、動的に割り当てる。更に、RAIDサブシステム104およびディスク・マネージャ106は、更に別のディスク・ドライブが必要かどうかの判定を、ディスク空間全体にわたるデータ割り当てに基づいて行う能力がある。更に別のディスク・ドライブが必要である場合にはその通知がユーザへ送られて、希望される場合には更に別のディスク空間を追加できる。
【0022】
本発明の諸原理に従った、動的なデータ割り当て(または「ディスク・ドライブ仮想化」と呼ばれる)を有するディスク・ストレージ・システム100を、図2に一つの実施形態の形で示し、図14のAおよび図14のBに別の実施形態の形で示している。図2に示すように、ディスク・ストレージ・システム110は、ストレージのページ・プール112、即ち、自由にデータを保存できるデータ・ストレージ空間のリストを含むデータ・ストレージのプールを含む。ページ・プール112は、RAID装置114のフリー・リストを維持し、読み出し/書き込みの割り当ての管理を、ユーザの要求に基づいて行う。ユーザの要求したデータ・ストレージ・ボリューム116は、ストレージ空間を得るために、ページ・プール112へと送られる。それぞれのボリュームは、同じまたは異なるRAIDレベル、例えば、RAID10、RAID5、RAID0などで、同じまたは異なるクラスのストレージ装置を要求することができる。
【0023】
本発明の動的なデータ割り当ての別の実施形態を、図14のAおよび図14のBに示しており、この例では、複数のディスク・ストレージ・システム・コントローラ1402と、複数のディスク・ストレージ・システム・コントローラ1402により制御されるディスク・ストレージ・ブロックのマトリックス1404とを有するディスク・ストレージ・システム1400は、そのシステムにおいて本発明の諸原理に従ってデータを動的に割り当てる。仮想ボリュームまたはブロックのマトリックス1404は、物理ディスクと関連づけるように提供される。仮想ボリュームまたはブロックのマトリックス1404は、複数のディスク・ストレージ・システム・コントローラ1402によって動的に監視/制御される。一実施形態では、それぞれの仮想ボリューム1404のサイズは、例えば2メガバイトのように、予め定めることができ、それぞれの仮想ボリューム1404の場所はデフォルトでnullとなっている。仮想ボリューム1404のそれぞれは、データが割り当てられるまでnullである。データは、そのマトリックスまたはプールの任意のグリッドに割り当てることができる(例えば、データがそのグリッドに割り当てられた後は、そのグリッド内の「ドット」になる)。そのデータが削除された後は、その仮想ボリューム1404は再び使用可能になり、「null」と示される。このため、余分な、時には高価なデータ・ストレージ装置、例えばRAID装置を、後に必要となったときに得ることができる。
【0024】
従って、RAIDサブシステムは、仮想的な数のディスクにわたってRAID技法を使用することができる。残りのストレージ空間は自由に使用可能である。RAIDサブシステムのストレージ空間を監視し、そのストレージ空間の占有率を決定することにより、ユーザは、高価であるのに購入時点では用途のない大量のドライブを得なくても済む。このように、ドライブの追加を、ストレージ空間の増大する需要を満たすために実際に必要であるときに行うことにより、ディスク・ドライブの全体のコストが著しく低減される。一方、ドライブの使用の効率も著しく改善される。
【0025】
また、本発明のディスク・ドライブ・システムの動的なデータ割り当てにより、ストレージの仮想ボリューム・ページ・プール、または、ディスク・ストレージ・ブロックの仮想ボリューム・マトリックスの、スナップショット/ポイント・イン・タイム・コピーの効率のよいデータ・ストレージや、データ・リカバリおよびリモート・データ・ストレージのためのインスタント・データ・リプレイおよびデータ・インスタント・フュージョンや、データ・プログレッションが可能になる。
【0026】
ディスク・ドライブ・システム100における動的データ割り当てのシステムおよび方法ならびにその実装形態の結果として得られる上述の特徴および利点を、以下で詳細に論じる。
【0027】
動的なデータ割り当て
図2Aに、ディスク・ドライブ・システムのRAIDサブシステムにおける従来のデータ割り当てを示し、ここでは、空けられたデータ・ストレージ空間は専属(captive)であり、データ・ストレージ用に割り当てることができない。
【0028】
図2Bには、本発明の諸原理に従ったディスク・ドライブ・システムのRAIDサブシステムにおけるデータ割り当てを示し、ここでは、データ・ストレージ用に使用可能である空けられたデータ・ストレージは、一緒にまとめられて、ページ・プール、例えば、本発明の一実施形態では1つのページ・プール、を形成する。
【0029】
図2Cに、本発明の諸原理に従った動的なデータ割り当ての方法200を示す。動的なデータの割り当ての方法200は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを定義して、RAIDサブシステムのディスク空間がディスク・ストレージ・ブロックのマトリックスを形成するようにするステップ202と、データを書き込み、そのデータを、マトリックスの、「null」を示すディスク・ストレージ・ブロックに割り当てるステップ204とを含む。この方法は、更に、RAIDサブシステムのディスク空間の占有率を、そのRAIDサブシステムのディスク空間の占有率履歴に基づいて決定するステップ206と、更に別のディスク・ドライブが必要かどうかを判定し、必要な場合に、RAIDサブシステムへ通知を送るステップ208とを含む。一実施形態では、通知は電子メールによって送られる。更に、ディスク・ストレージ・ブロックのサイズはデフォルトに設定し、ユーザにより変更可能とすることができる。
【0030】
一実施形態では、動的なデータ割り当ては、時には「仮想化」または「ディスク空間仮想化」と呼ばれるものであり、数多くの読み出しおよび書き込みの要求を秒単位で効率よく取り扱う。このアーキテクチャでは、キャッシュ・サブシステムを直接に呼び出す割り込みハンドラが必要であることもある。動的なデータの割り当てでは、要求(リクエスト)をキューに入れないので要求の最適化はなされないが、一度に数多くの未解決(pending)の要求を有し得る。
【0031】
また、動的なデータの割り当てでは、データのインテグリティを維持し、データの内容をどのようなコントローラの障害に対しても保護することができる。そうするために、動的なデータの割り当てでは、状態情報を信頼性をもって記憶するためにRAID装置へ書き込む。
【0032】
動的なデータの割り当てでは、更に、読み出しおよび書き込みの要求の順序を維持し、読み出しまたは書き込みの要求を、要求を受け取った順序で完了させることができる。動的なデータの割り当ては、最大のシステム可用性(availability)を提供し、異なる地理的場所へのデータのリモートの複製をサポートする。
【0033】
更に、動的なデータの割り当ては、データ破壊からのリカバリ機能を提供する。スナップショットにより、ユーザは、過去におけるディスクの状態を閲覧することができる。
【0034】
動的なデータの割り当てでは、RAID装置を管理し、大規模な装置を作成し拡張するためのストレージ抽象化を提供する。
【0035】
動的なデータの割り当てでは、サーバに対して仮想ディスク装置を提示するものであり、この装置がボリューム(volume)と呼ばれる。サーバに対して、ボリュームは同じ働きをする。ボリュームは、シリアル番号に関して異なる情報を返し得るが、本質的にはディスク・ドライブのような働きをする。ボリュームは、より大きい動的なボリューム装置を作成するために、複数のRAID装置のストレージ抽象化を提供する。ボリュームは複数のRAID装置を含み、ディスク空間の効率的な使用を可能にする。
【0036】
図21に、従来の既存のボリューム論理ブロック・マッピングを示す。図14のCには、本発明の諸原理に従った、ストレージの仮想ボリュームのページ・プールの一実施形態のボリューム−RAIDページ再マッピングを示す。それぞれのボリュームは1組のページ、例えば、1、2、3などへと分割され、それぞれのRAIDは1組のページへと分割される。ボリュームのページ・サイズと、RAIDのページ・サイズとは、一実施形態では同じとすることができる。従って、本発明のボリューム−RAIDページ再マッピングの一例では、RAID−2を使用するページ#1がRAIDページ#1へとマッピングされる。
【0037】
動的なデータの割り当てでは、ボリュームのデータ・インテグリティを維持する。データは、ボリュームへと書き込まれ、サーバへの確認が行われる。データ・インテグリティは、コントローラの障害を通して、スタンド・アロンや冗長なものを含めての様々なコントローラのコンフィギュレーションに適用される。コントローラの障害としては、電源障害、パワー・サイクル(power cycle)、ソフトウェア例外、およびハード・リセットがある。動的なデータの割り当てでは、一般には、RAIDでカバーされるディスク・ドライブ障害を取り扱わない。
【0038】
動的なデータの割り当ては、コントローラに対する最も高レベルのデータ抽象化を提供する。動的なデータの割り当ては、フロント・エンドから要求を受理し、最終的にはRAID装置を使用してデータをディスクへ書き込む。
【0039】
動的なデータの割り当ては、幾つもの内部サブシステムを含む。
・キャッシュ − ボリュームへの読み出しおよび書き込みの動作を、サーバへの迅速な応答時間を提供し、データ・プラグインに対して書き込みをまとめることによって、スムーズにする。
・コンフィギュレーション − データ割り当てオブジェクトの作成、削除、取り出し、および変更の方法を含む。より高レベルのシステム・アプリケーションに対するツールボックスを作成するためのコンポーネントを提供する。
・データ・プラグイン − ボリュームの読み出しおよび書き込みの要求を、ボリューム・コンフィギュレーションに応じて、様々なサブシステムへ配布する。
・RAIDインターフェース − より大きいボリュームを作成するためのRAID装置抽象化を、ユーザおよび他の動的なデータの割り当てサブシステムに提供する。
・コピー/ミラー/スワップ − ボリュームのデータを、ローカルおよびリモートのボリュームへと複製する。一実施形態では、サーバの書き込まれたブロックのコピーのみを行うことができる。
・スナップショット − データの増分的(incremental)ボリューム・リカバリを提供する。過去のボリューム状態の閲覧ボリューム(View Volume)を即座に作成する。
・プロキシ・ボリューム − リモートの宛先ボリュームへの要求の通信を行えるようにして、リモート複製(Remote Replication)をサポートする。
・請求(billing) − 割り当てたストレージ、活動、パフォーマンス、およびデータのリカバリに対してユーザに料金請求する機能。
【0040】
また、動的なデータの割り当てでは、エラーおよびコンフィギュレーションにおける顕著な変更のログ記録も行う。
【0041】
図21に、サブシステムにおける外部データ・フローの一実施形態を示す。外部要求はフロント・エンドから来る。要求には、ボリューム情報取得(get volume information)、読み出し(read)、および書き込み(write)がある。すべての要求はボリュームIDをもつ。ボリューム情報は、ボリューム・コンフィギュレーション・サブシステムによって取り扱われる。読み出しおよび書き込みの要求はLBAを含む。また、書き込み要求はデータを含む。
【0042】
動的なデータの割り当ては、ボリューム・コンフィギュレーションに応じて、要求を幾つもの外部レイヤへ渡す。リモート複製は、要求をフロント・エンドへ渡すが、あて先はリモートの宛先ボリュームである。RAIDインターフェースは要求をRAIDへ渡す。コピー/ミラー/スワップは、要求を、宛先ボリュームに対する動的データ割り当てへと戻す。
【0043】
図22に、サブシステムにおける内部データ・フローの一実施形態を示す。内部データ・フローはキャッシュを行うことから始まる。キャッシュを行うと、書き込み要求がキャッシュに入れられるか、または、その要求が直接にデータ・プラグインへ渡される。キャッシュは、フロント・エンドのHBA装置からの直接DMAをサポートする。要求は迅速に完了され、応答がサーバに返される。データ・プラグイン・マネージャが、キャッシュより下の要求フローの中心である。それぞれのボリュームに対して、データ・プラグイン・マネージャは、要求ごとに、登録されたサブシステム・オブジェクトを呼び出す。
【0044】
データ・インテグリティに影響を及ぼす動的データ割り当てサブシステムでは、コントローラの一貫性(コヒーレンシ)に対するサポートが必要となることがある。図23に示すように、それぞれのサブシステムは、独立してコヒーレンシを維持する。コヒーレンシの更新により、コヒーレンシ・リンクを通じてのデータ・ブロックのコピーを回避する。キャッシュのコヒーレンシでは、データをピア(peer)コントローラにコピーする必要があり得る。
【0045】
ディスク・ストレージ・システム・コントローラ
図14のAに、本発明の諸原理に従った、システムにおいて動的にデータを割り当てるための、複数のディスク・ストレージ・システム・コントローラ1402と、複数のディスク・ストレージ・システム・コントローラ1402により制御されるディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404とを有するディスク・ストレージ・システム1400を示す。図14のBには、ディスク・ストレージ・ブロックまたは仮想ボリュームの仮想ボリューム・マトリックス1404における動的なデータの割り当ての一実施形態を示す。
【0046】
ある動作では、ディスク・ストレージ・システム1400は、ディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404のスナップショットを、所定の時間間隔で時間的に生成し、スナップショットまたはデルタのアドレス・インデックスを、ディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404に保存して、ディスク・ストレージ・ブロックまたは仮想ボリュームのマトリックス1404のスナップショットまたはデルタが、保存したアドレス・インデックスによって直ちに見つけ出せるようにする。
【0047】
更にある動作では、ディスク・ストレージ・システム・コントローラ1402は、ディスク・ストレージ・ブロックのマトリックス1404のスナップショットからデータ使用の頻度を監視し、そして、使用またはアクセスの頻度の低いデータほど、より安価なRAIDサブシステムへと移動させるようなエージング規則を適用する。同様に、より安価なRAIDサブシステム中のデータがより頻繁に使用され始めると、コントローラは、そのデータを、より高価なRAIDサブシステムへと移動させる。従って、ユーザは、ユーザ自身のストレージの必要性を満たすように所望のRAIDサブシステム・ポートフォリオを選ぶことができる。従って、ディスク・ドライブ・システムのコストを著しく低減させ、また、ユーザによる動的な制御を可能とする。
【0048】
RAID−ツー−ディスク・マッピング(RAID-to-Disk Mapping)
RAIDサブシステムおよびディスク・マネージャは、データを、複数のディスク・ドライブのディスク空間にわたって、RAID−ツー−ディスク・マッピングに基づいて、動的に割り当てる。一実施形態では、RAIDサブシステムおよびディスク・マネージャは、更に別のディスク・ドライブが必要かどうかを判定し、更に別のディスク・ドライブが必要である場合には通知を送る。
【0049】
図15に、本発明の諸原理に従った、RAID−5サブシステム1500内の複数のディスク・ストレージ・ブロック1502〜1512へとマッピングされる3つのディスク・ドライブ108(図1)の例を示す。
【0050】
図16は、図15に示す3つのディスク・ドライブ108にディスク・ドライブ1602を追加した後の、ディスク・ドライブ・ストレージ・ブロックの再マッピング1600の例を示す。
【0051】
ディスク・マネージャ
図1に示すディスク・マネージャ106は、一般には、ディスクおよびディスク・アレイの管理を行うものであり、それには、グループ化/資源プーリング、ディスク属性の抽象化、フォーマット、ディスクの追加(addition)/削減(subtraction)、およびディスク・サービス時間およびエラー率の追跡を含む。ディスク・マネージャ106は、ディスクの様々なモデルの間の違いを区別せず、RAIDコンポーネントについて包括的なストレージ装置を提示する。また、ディスク・マネージャ106はグループ化機能を提供し、これは、例えば10000RPMのディスクなどのような特定の特徴をもつRAIDグループの構築を容易にする。
【0052】
本発明の一実施形態では、ディスク・マネージャ106は、少なくとも3重のものとなっている。その3重のものとは、抽象化、コンフィギュレーション、およびI/O最適化である。ディスク・マネージャ106は、「ディスク」を上位レイヤに提示し、上位レイヤは、例えば、ローカルまたはリモートに取り付けられた物理ディスク・ドライブや、リモートに取り付けられたディスク・システムなどとすることができる。
【0053】
共通の基礎にある特徴は、こうした装置の何れもがI/O動作のターゲットであり得ることである。抽象化サービスは、特にRAIDサブシステムのような上位レイヤに対して、一様なデータ・パス・インターフェースを提供し、そして、管理者に対して、ターゲット装置の管理のための包括的な機構を提供する。
【0054】
また、本発明のディスク・マネージャ106は、ディスクのグループ化機能を提供して管理およびコンフィギュレーションを簡素化する。ディスクには名前を付け、グループに入れることができ、グループにも名前を付けることができる。グループ化は強力な機能であり、これにより、ボリュームを或るディスクのグループから別のグループへと移行させるタスクや、或るグループのディスクを特定の機能専用にするタスクや、或るグループのディスクをスペアに指定するタスクなどのタスクを簡単にする。
【0055】
また、ディスク・マネージャは、外部装置の存在を検出する役目をもつSCSI装置サブシステムなどのような装置とインターフェースを行う。SCSI装置サブシステムは、少なくともファイバ・チャネル/SCSIタイプの装置については、ブロック型のターゲット装置である装置のサブセットを判定する能力をもつ。ディスク・マネージャが管理および抽象化を行うのはこうした装置である。
【0056】
更に、ディスク・マネージャは、SCSI装置レイヤからのフロー制御に応答する役目をもつ。ディスク・マネージャは、キューイング機能を有し、これにより、ディスク・ドライブ・システムのスループットを最適化する一方法として、I/O要求を集合させる機会が与えられる。
【0057】
更に、本発明のディスク・マネージャは、複数のディスク・ストレージ・システム・コントローラを管理する。また、複数の冗長ディスク・ストレージ・システム・コントローラを実装して、動作させられるディスク・ストレージ・システム・コントローラの障害をカバーすることができる。この冗長ディスク・ストレージ・システム・コントローラもディスク・マネージャによって管理される。
【0058】
ディスク・マネージャと他のサブシステムとの関係
ディスク・マネージャは、他の幾つかのサブシステムとやり取りを行う。RAIDサブシステムは、データ・パス活動に関してディスク・マネージャが提供するサービスの重要なクライアントである。RAIDサブシステムは、ディスク・マネージャを、I/Oのためのディスクへの独占的なパスとして使用する。また、RAIDシステムでも、ディスク・マネージャからのイベントについて聴取を行い、ディスクの存在および動作状態の判定を行う。また、RAIDサブシステムはディスク・マネージャと協働して、RAID装置の構築のための範囲(extent)を割り当てる。管理コントロールは、ディスクの存在の情報を得るため、また動作状態の変化について情報を得るために、ディスク・イベントについて聴取を行う。本発明の一実施形態では、RAIDサブシステム104は、RAID−0、RAID−1、RAID−5、RAID−10などのRAIDタイプのうちの少なくとも1つからなる組合せを含むことができる。代替のRAIDサブシステムでは、RAID−3、RAID−4、RAID−6、RAID−7などのような他のRAIDタイプを使用できることも理解されよう。
【0059】
本発明の一実施形態では、ディスク・マネージャは、コンフィギュレーション・アクセスのサービスを使用して、持続的なコンフィギュレーションを保存し、また、統計などのような過渡的な読み出し専用情報をプレゼンテーション・レイヤへ提示する。ディスク・マネージャは、こうしたパラメータへのアクセスのためにコンフィギュレーション・アクセスへのハンドラの登録を行う。
【0060】
また、ディスク・マネージャは、ブロック・デバイスの存在および動作状態についての情報を得るためにSCSI装置レイヤのサービスを使用するものであり、また、こうしたブロック・デバイスへのI/Oパスをもつ。ディスク・マネージャは、ディスクを一意に識別するための補助的な方法として、装置についてSCSI装置サブシステムに問い合わせを行う。
【0061】
データ・インスタント・リプレイおよびデータ・インスタント・フュージョン
また、本発明は、データ・インスタント・リプレイ(data instant replay)およびデータ・インスタント・フュージョン(data instant fusion)の方法を提供する。図3のAおよびBに、本発明の諸原理に従った、複数の時間間隔でのRAIDサブシステムのディスク・ストレージ・ブロックのスナップショットの概略図を示す。図3Cには、データ・インスタント・リプレイの方法300を示し、この方法は、論理ブロックまたはディスク・ストレージ・ブロックのデフォルトのサイズを定義して、RAIDサブシステムのディスク空間がストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスを形成するようにするステップ302と、ページ・プールのボリュームのスナップショットまたはディスク・ストレージ・ブロックのマトリックスのスナップショットを所定の時間間隔で時間的に生成するステップ304と、スナップショットまたはデルタ(delta)のアドレス・インデックスを、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスに保存して、ディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタをその保存したアドレス・インデックスによって直ちに見つけ出せるようにするステップとを含む。
【0062】
図3Bに示すように、所定の各時間間隔、例えば、T1(午後12:00)、T2(午後12:05)、T3(午後12:10)、T4(午後12:15)などのような5分毎に、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスのスナップショットが自動的に生成される。ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスの中のスナップショットまたはデルタのアドレス・インデックスは、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスに保存されて、ストレージのページ・プールまたはディスク・ストレージ・ブロックのマトリックスのスナップショットまたはデルタを、その保存したアドレス・インデックスによって直ちに見つけ出せるようにされる。
【0063】
従って、このデータ・インスタント・リプレイの方法では、RAIDサブシステムのスナップショットを、ユーザの定義する時間間隔や、ユーザのコンフィギュレーションする例えば数分や数時間ごとなどのような動的なタイム・スタンプや、サーバの指示する時刻に、時間的に生成する。システム障害やウイルス攻撃にあった場合、こうしたタイム・スタンプを有する仮想スナップショットにより、データ・インスタント・リプレイおよびデータ・インスンタント・リカバリが、約数分または数時間などで可能になる。この技法は、インスタント・リプレイ・フュージョンとも呼ばれる。即ち、クラッシュまたは攻撃のすぐ前のデータのフュージョンが遅れずに行われ、クラッシュまたは攻撃の前に保存したスナップショットを直ちにそれ以降の動作で使用することができる。
【0064】
図4に、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックの複数のスナップショットを使用することによるデータ・インスタント・フュージョン機能400の概略図を更に示している。T3で、スナップショットの並列チェインT3’〜T5’が生成され、それにより、フュージョンされたデータT3’によってフュージョンおよび/またはリカバリされたデータを、T4でフュージョンされるデータと置き換えるために使用することができる。同様に、スナップショットの複数の並列チェインT3’’、T4’’’を生成して、T4’〜T5’およびT4’’〜T5’’でフュージョンされるデータと置き換えることができる。一代替実施形態では、T4、T4’〜T5’、T5’’でのスナップショットは、なおもページ・プールまたはマトリックスに保存することができる。
【0065】
スナップショットをローカルのRAIDサブシステムまたはリモートのRAIDサブシステムに保存することができ、それにより、重大なシステム・クラッシュが、例えば、テロリスト攻撃などが原因で生じた場合にも、データ・インテグリティについて影響を受けず、データを直ちにリカバリできる。図5に、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することによる、ローカル−リモートのデータ複製およびインスタント・リプレイ機能500の概略図を示す。
【0066】
リモート複製(replication)は、リモート・システムに対してボリューム・データを複製するサービスを行う。リモート複製では、ローカルとリモートとのボリュームを、可能な限り同期させた状態に保つことを試みる。一実施形態では、リモートのボリュームのデータが、ローカルのボリュームのデータの完全なコピーをミラーリングしていないこともあり得る。ネットワークの接続性(コネクティビティ)およびパフォーマンスに起因して、リモートのボリュームがローカルのボリュームと同期しない状態が引き起こされる場合もあり得る。
【0067】
データ・インスタント・リプレイおよびデータ・インスタント・フュージョンの方法の別の特徴は、スナップショットを、システムが動作している状態で検査のために使用できることである。生のデータ(live data)をリアル・タイムの検査に使用することができる。
【0068】
スナップショットおよびポイント・イン・タイム・コピー(PITC)
データ・インスタント・リプレイの一例は、本発明の諸原理に従った、RAIDサブシステムのディスク・ストレージ・ブロックのスナップショットを使用することである。スナップショットは、ボリュームへの書き込み動作を記録して、過去のボリュームの内容を見るためにビューを作成できるようにする。また、スナップショットは、ボリュームのそれまでのポイント・イン・タイム・コピー(Point-in-Time-Copy(特定の時にとられたコピー)、PITC)に対するビューを作成することによって、データ・リカバリのサポートを行う。
【0069】
スナップショットのコアは、スナップショットの作成、合体(coalesce)、管理、およびI/O動作を実現する。スナップショットは、ボリュームへの書き込みを監視し、ボリュームのビューを通してアクセスのためにポイント・イン・タイム・コピー(PITC)を作成する。スナップショットは、論理ブロック・アドレス(logical block address、LBA)再マッピング・レイヤを、仮想化レイヤ内のデータ・パスへ追加する。これは、I/Oパス内の仮想LBAマッピングの別レイヤである。PITCは、すべてのボリューム情報をコピーしない場合もあり得、単に再マッピングで使用されるテーブルを変更するだけであり得る。
【0070】
スナップショットは、ボリューム・データについての変更を追跡し、それまでのポイント・イン・タイムからのボリューム・データを見る機能を提供する。スナップショットは、この機能を、それぞれのPICTに対するデルタ書き込みのリストを維持することによって、行う。
【0071】
スナップショットは、PITCプロファイルのための複数の方法を提供するが、これは、アプリケーションにより開始されるもの、および時間により開始されるものを含む。スナップショットは、アプリケーションがPITCを作成するようにする機能を提供する。アプリケーションは、作成を、サーバ上のAPIを通して制御し、これはスナップショットAPIへと送られる。また、スナップショットは、時間プロファイルを作成する機能を提供する。
【0072】
スナップショットは、ジャーナル用システムの実装や、ボリュームへの書き込みのすべてのリカバリを行わない場合もあり得る。スナップショットは、PITCウィンドウ内の一つのアドレスへの最後の書き込みを保持するのみであり得る。スナップショットにより、ユーザは、例えば分や時間などの定められた短期間をカバーするPITCを作成することが可能とされる。スナップショットは、障害を取り扱うために、すべての情報をディスクに書き込む。スナップショットは、デルタ書き込み(delta writes)を含むボリューム・データ・ページ・ポインタを維持する。テーブルはマップをボリューム・データへ提供するものであり、これがなければボリューム・データへはアクセス不能であるため、テーブル情報はコントローラ障害の場合を取り扱わなければならない。
【0073】
ビュー・ボリューム機能(ボリュームを見る機能)により、PITCへのアクセスが提供される。ビュー・ボリューム機能は、アクティブなPITCを除き、そのボリューム内の任意のPITCに付加させることができる。PITCへの付加は、比較的迅速な動作である。ビュー・ボリューム機能の用途は、検査、訓練、バックアップ、およびリカバリを含む。ビュー・ボリューム機能は、書き込み動作を可能にし、その基礎とされている基礎的PITCの変更は行わない。
【0074】
一実施形態では、スナップショットは、ディスク空間を使用して、パフォーマンスを最適化し、使用を容易にするように設計されおり、それは下記のようである。
【0075】
・スナップショットにより、ユーザ要求に対する応答時間が速くなる。ユーザ要求には、I/O、PITCの作成、ビュー・ボリュームの作成/削除が含まれる。これを達成するために、スナップショットは、必要最小量よりも多くのディスク空間を使用してテーブル情報を保存する。I/Oについては、スナップショットは、ボリュームの現在の状態を要約して一つのテーブルにして、読み出しおよび書き込みの要求をすべて一つのテーブルで満たすことができるようにする。スナップショットは、通常のI/O動作に対する影響をできる限り低減する。第2に、ビュー・ボリューム動作については、スナップショットは、メイン・ボリュームのデータ・パスと同じテーブル機構を使用する。
【0076】
・スナップショットは、コピーされるデータの量を最小化する。このためには、スナップショットは、それぞれのPITCについてのポインタのテーブルを維持する。スナップショットはポインタのコピーおよび移動を行うが、ボリューム上のデータの移動は行わない。
【0077】
・スナップショットは、固定サイズのデータ・ページを用いてボリュームの管理を行う。個々のセクタを追跡するには、一つの手頃なサイズのボリュームでも膨大な量のメモリが必要になる。セクタよりも大きなデータ・ページを使用することにより、ある種のページは、別のページから直接に複製された情報の一部を含むことができる。
【0078】
・スナップショットは、ボリューム上のデータ空間を使用して、データ・ページ・テーブルを保存する。ルックアップ・テーブルは、コントローラ障害の後に複製される。ルックアップ・テーブルは、ページを割り当て、それをさらに分割する。
【0079】
・スナップショットがコントローラ障害を取り扱うが、その際、一実施形態では、スナップショットを用いるボリュームが一つのコントローラ上で動作することが必要とされる。この実施形態ではコヒーレンシは必要ない。ボリュームへのすべての変更は、代替のコントローラによるリカバリのために、ディスクまたは信頼できるキャッシュへ記録される。コントローラ障害からのリカバリの際には、一実施形態では、スナップショット情報をディスクから読み取ることが必要である。
【0080】
・スナップショットは、仮想RAIDインターフェースを使用して、ストレージへのアクセスを行う。スナップショットは、複数のRAID装置を単一のデータ空間として使用することができる。
【0081】
・スナップショットは、ボリュームあたり「n」個のPITCおよびボリュームあたり「m」個のビューをサポートする。「n」および「m」に対する制限は、ディスク空間およびコントローラのメモリの関数となる。
【0082】
ボリュームおよびボリュームの割り当て/レイアウト
スナップショットは、LBA再マッピング・レイヤをボリュームに追加する。再マッピングは、I/O要求LBAおよびルックアップ・テーブルを使用して、アドレスをデータ・ページへと変換する。図6に示すように、スナップショットを用いた提示されるボリュームは、スナップショットのないボリュームと同じふるまいをする。それは、線形LBA空間を有し、I/O要求を取り扱う。スナップショットは、RAIDインターフェースを使用してI/Oを行うものであり、複数のRAID装置を1つのボリュームに含める。一実施形態では、スナップショット・ボリュームに対するRAID装置のサイズは、提示されるボリュームのサイズではない。RAID装置により、スナップショットは、ボリューム内でデータ・ページ用の空間を拡張することを可能とされる。
【0083】
新しいボリュームは、初めにスナップショットをイネーブルにしてあると、新しいデータ・ページ用の空間を含めればよいだけである。スナップショットは、ボトム・レベルのPITCに置くページのリストを作成しない。ボトム・レベルPITCは、この場合には空である。割り当て時に、すべてのPITCページはフリー・リスト上にある。初めにスナップショットをイネーブルにしたボリュームを作することにより、ボリュームが提示するよりも少ない物理空間を割り当て得る。スナップショットは、ボリュームへの書き込みを追跡する。本発明の一実施形態では、ヌル(NULL)・ボリュームは、ページ・プールまたはマトリックスへコピーおよび/または保存されず、これにより、ストレージ空間の使用の効率が高まる。
【0084】
一実施形態では、どちらの割り当て方式でも、PITCが、仮想NULLボリュームをリストの底部に置く。NULLボリュームに対する読み出しは、ゼロのブロックを返す。NULLボリュームは、サーバがそれまで書き込んでいないセクタを取り扱う。NULLボリュームへの書き込みは起こり得ない。ボリュームは、NULLボリュームを、書き込まれていないセクタに対する読み出しのために使用する。
【0085】
空きページの数は、ボリュームのサイズ、PITCの数、および予測されるデータ変化レートに依存する。システムは、所与のボリュームに対しての割り当てるページの数を決定する。データ・ページの数は、時間が経つにつれて拡張される可能性がある。拡張により、予測されるよりも急速なデータの変化、より多くのPITC、またはより大きなボリュームを、サポートすることができる。新しいページはフリー・リストへ追加される。フリー・リストへのページの追加は自動的に行ってもよい。
【0086】
スナップショットは、ボリューム空間の管理のためにデータ・ページを使用する。それぞれのデータ・ページは数メガバイトのデータを含み得る。オペレーティング・システムを使用すると、ボリュームの同じ領域へ多くのセクタが書き込まれる傾向がある。メモリ要件からも、スナップショットがボリュームの管理のためにページを使用することが要求される。1テラバイトのボリュームの各セクタについて一つの32ビットポインタを維持すると、8ギガバイトのRAMが必要となり得る。異なるボリュームは異なるページ・サイズを有し得る。
【0087】
図7に、スナップショット構造の一実施形態を示す。スナップショットは、多くのオブジェクトをボリューム構造に付加する。付加されるオブジェクトとしては、PITC、アクティブなPITCへのポインタ、データ・ページ・フリー・リスト、子のビュー・ボリューム、およびPITC合体オブジェクトがある。
【0088】
・アクティブPITC(AP)ポインタはボリュームにより維持される。APは、ボリュームに対する読み出しおよび書き込みの要求のマッピングを取り扱う。APは、ボリューム内のすべてのデータの現在の場所の要約(一覧、summary)を含む。
【0089】
・データ・ページ・フリー・リストは、ボリューム上の使用可能なページの追跡を行う。
【0090】
・オプションの子ビュー・ボリューム(child view volume)は、ボリュームPITCへのアクセスを提供する。ビュー・ボリュームは、PITCへの書き込みを記録するためにそれ自体のAPを含むが、基礎となるデータの変更は行わない。1つのボリュームが複数の子ビュー・ボリュームをサポートしてもよい。
【0091】
・スナップショット合体オブジェクトは、以前のPITCを取り除く目的で2つのPITCを一時的にリンクする。PITCの合体は、データ・ページの所有権を移動し、データ・ページを解放することを含む。
【0092】
・PITCは、そのPITCがアクティブであった間に書き込まれたページに対するテーブルおよびデータ・ページを含む。PITCは、PITCが書き込み要求の受理を停止した時点の凍結タイム・スタンプを含む。また、PITCは、何れの時間にPITCが合体することになるかを決めるTime−to−Live(タイム・ツー・ライブ、生きる時間)値を含む。
【0093】
また、スナップショットは、ボリューム全体に対するデータ・ページ・ポインタの要約を、PITCが取られた時点で行って、読み出しおよび書き込みの予測可能なパフォーマンスを提供する。他の解決策は、最新のポインタを見つけるために複数のPITCを検査するために、読み出しを必要とし得る。こうした解決策では、テーブル・キャッシング・アルゴリズムが必要であるが、パフォーマンスは最低となる場合がある。
【0094】
また、本発明におけるスナップショットを要約することにより、テーブルの最悪のメモリ使用が低減される。その場合、テーブル全体をメモリへロードすることを必要とされ得るが、単一のテーブルだけをロードすることを必要とされ得る。
【0095】
要約(一覧)は、現在のPITCの所有するページを含むが、それまでのすべてのPITCからのページを含むことができる。PITCがどのページに書き込みを行うかを決定するために、それぞれのデータ・ページについてのページ所有権を追跡する。また、一覧は、合体プロセスに対する所有権の追跡も行う。これを取り扱うために、データ・ページ・ポインタはページ・インデックスを含む。
【0096】
図8に、PITCのライフ・サイクルの一実施形態を示す。それぞれのPITCは、読み出し専用として記憶(コミット)される前に、多数の下記の状態を経過する。
【0097】
1.テーブル作成 − 作成を行うと、テーブルが作成される。
【0098】
2.ディスクへのコミット(記憶、commit) − これは、PITCに対してディスク上にストレージを生成する。この時点でテーブルを書き込むことにより、テーブル情報の保存に必要な空間が、PITCが取られる前に割り当てられることが保証される。同時に、PITCオブジェクトもディスクへ記憶(コミット)される。
【0099】
3.I/Oの受け入れ − これはPITCはアクティブPITC(AP)になっている。 − ここでは、PITCは、ボリュームに対する読み出しおよび書き込みの要求を取り扱う。これは、テーブルへの書き込み要求を受理する唯一の状態である。PITCは、いまアクティブであるというイベントを生成する。
【0100】
4.ディスクへのテーブルの記憶 − PITCはもはやAPではなく、もはやそれ以上のページを受理しない。新しいAPによる引き継ぎが行われている。この時点より後では、テーブルは、合体動作中に取り除かれない限り、変更されない。これは読み出し専用である。PITCは、この時点で、凍結され記憶されているというイベントを生成する。何れのサービスもそのイベントを聴取することができる。
【0101】
5.テーブルのメモリの解放(リリース) − テーブルが必要とするメモリを解放する。また、このステップは、変更がすべてディスクへと書き込まれていることを示すために、ログをクリアする。
【0102】
ボリュームまたはビュー・ボリュームのためのトップ・レベルPITCは、アクティブPITC(AP)と呼ばれる。APは、ボリュームへのすべての読み出しおよび書き込みの要求を満たす。APは、そのボリュームに対しての唯一の、書き込み要求を受理できるPITCである。APは、ボリューム全体に対するデータ・ページ・ポインタの一覧を含む。
【0103】
APは、合体プロセスに関して、宛先(destination)となることはできるが、ソース(source)となることはできない。宛先である場合、APは、所有するページの数を増加するが、データのビューは変更しない。
【0104】
ボリュームの拡張に関しては、APはボリュームとともに直ちに大きくなる。新しいページは、NULLボリュームを指す。APではないPITCは、ボリュームの拡張のために変更は必要ではない。
【0105】
それぞれのPITCは、入ってくるLBAを、基礎となるボリュームへのデータ・ページ・ポインタへとマッピングするテーブルを維持する。テーブルは、データ・ページへのポインタを含む。テーブルは、提示される論理空間よりも多くの物理ディスク空間をアドレスする必要がある。図9に、マルチ・レベル・インデックスを有するテーブル構造の一実施形態を示す。この構造は、ボリュームLBAを復号化してデータ・ページ・ポインタにする。各レベルでは、図9に示すように、アドレスの増加していくLSB(less significant bit)を復号化する。このテーブルの構造により、高速のルックアップおよびボリュームの拡張の機能が提供される。高速ルックアップのために、マルチ・レベル・インデックス構造は、テーブルを浅い状態に維持し、各レベルで複数のエントリをもつようにしている。このインデックスは、各レベルでアレイのルックアップを行う。ボリュームの拡張をサポートするため、マルチ・レベル・インデックス構造により、拡張をサポートするための別のレイヤを追加することが可能になっている。この場合のボリュームの拡張は、上位レイヤへ提示されるLBAカウント(計数)の拡張であり、そのボリュームへ割り当てられるストレージ空間の実際の量ではない。
【0106】
マルチ・レベル・インデックスは、ボリューム全体のデータ・ページ再マッピングの一覧(要約)を含む。それぞれのPITCは、記憶されたポイント・イン・タイム(時(特定の時))の、このボリュームに対する完全な再マッピング・リストを含む。
【0107】
マルチ・レベル・インデックス構造は、テーブルのレベルに対して異なるエントリ・タイプを使用する。異なるエントリ・タイプは、情報をディスクから読み出す必要性や、情報をメモリに格納する必要性をサポートする。ボトム・レベルのエントリは、データ・ページ・ポインタのみを含み得る。トップおよび中間のレベルのエントリは2つのアレイを含み、1つは次のレベルのテーブル・エントリのLBAであり、そして、テーブルへのメモリ・ポインタを含む。
【0108】
提示されるボリューム・サイズが拡張する際に、以前のPITCテーブルのサイズは増やす必要はなく、また、テーブルを変更する必要もない。テーブルの中の情報は、読み出し専用であるので、変わらず、そして、拡張プロセスは、テーブルを、NULLページ・ポインタを末尾に追加することによって、変更する。スナップショットは、以前のPITCからのテーブルを直接にユーザに提示しない。
【0109】
I/O動作があると、テーブルには、LBAをデータ・ページ・ポインタへマッピングすることが求められる。その場合、I/Oでは、データ・ページ・ポインタにデータ・ページ・サイズを乗算して、基礎となるRAIDのLBAを得る。一実施形態では、データ・ページ・サイズは、2のべき乗である。
【0110】
テーブルは、LBAの再マッピング、ページの追加、およびテーブルの合体のためのAPIを提供する。
【0111】
スナップショットは、PITCオブジェクトおよびLBAマッピング・テーブルを保存するためにデータ・ページを使用する。テーブルは、そのテーブル・エントリに対するI/OのためにRAIDインターフェースへ直接にアクセスする。テーブルは、RAID装置に対してそのテーブルの読み出しおよび書き込みを行うときの変更を最小にする。変更がない場合には、テーブルの情報の読み出しおよび書き込みを、テーブル・エントリ構造に対して直接に行うことが可能になる。これにより、I/Oのために必要となるコピーが低減される。スナップショットは、ディスク上のホット・スポットの発生を防ぐために、変化ログを使用することができる。ホット・スポットとは、ボリュームへの更新を追跡するために繰り返し使用される場所のことである。変化ログは、PITCテーブルへの更新、およびボリュームに関するフリー・リストを記録する。リカバリ中には、スナップショットは変化ログを使用して、メモリ内AP(in-memory AP)およびフリー・リスト(free list)の再作成を行う。図10にテーブルのリカバリの一実施形態を示し、これにより、メモリ内APと、ディスク上AP(on-disk AP)と、変化ログとの間の関係を示している。この図は、フリー・リストに関しても同じ関係を示している。メモリ内APテーブルは、ディスク上APテーブルおよびログから再構築することができる。どのようなコントローラ障害の場合でも、APは、ディスク上APを読み出してそれにログ変化を適用することによって、再構築される。変化ログは、システム・コンフィギュレーションに応じて、異なる物理資源を使用する。多重コントローラのシステムでは、変化ログは、ストレージのためにバッテリ−バックアップされたキャッシュ・メモリを頼りにしている。キャッシュ・メモリを使用することにより、スナップショットは、ディスクへのテーブル書き込みの数を減らし且つデータ・インテグリティを維持することができる。変化ログは、リカバリのためにバックアップ・コントローラに対しての複製を行う。単一コントローラのシステムでは、変化ログは、すべての情報をディスクへ書き込む。これには、ディスク上のログの場所にホット・スポットを発生させるという副作用がある。これにより、幾つもの変化を単一のデバイス・ブロックへ書き込むことが可能とされる。
【0112】
スナップショットは、定期的に、PITCテーブルおよびフリー・リストをディスクへ書き込んで、ログにおけるチェックポイントの作成およびそのクリアを行う。この期間は、PITCへの更新の数に応じて変わり得る。合体プロセスは変化ログを使用しない。
【0113】
スナップショットのデータ・ページI/Oは、要求がデータ・ページ境界内に収まることを必要とし得る。スナップショットは、ページ境界にまたがるI/O要求にであった場合に、その要求を分割する。次いで、スナップショットは、その要求を要求ハンドラへと渡す。書き込みおよび読み出しのセクションは、I/Oがページ境界内に収まることを仮定している。APは、LBA再マッピングを提供してI/O要求を満たす。
【0114】
APはすべての書き込み要求を満たす。スナップショットは、所有ページと非所有ページに対する2つの異なる書き込みシーケンスをサポートする。異なるシーケンスにより、テーブルへのページの追加が可能になる。図11に、所有ページ・シーケンスおよび非所有ページ・シーケンスがある書き込みプロセスの一実施形態を示す。
【0115】
所有ページ・シーケンスでは、プロセスは以下のものを含む。
1)テーブル・マッピングを見つける。
2)所有の書き込みをページングする(Page Owned Write) − LBAを再マッピングし、データをRAIDインターフェースへ書き込む。
【0116】
以前に書き込まれたページは、純粋な書き込み要求である。スナップショットは、データをそのページに書き込んで、現在の内容を上書きする。APの所有するデータ・ページだけが書き込まれる。他のPITCの所有するページは、読み出し専用である。
【0117】
非所有ページ・シーケンスでは、プロセスは以下のものを含む。
1)テーブル・マッピングを見つける。
2)以前のページを読み出す − そのデータ・ページに対する読み出しを行い、書き込み要求と読み取ったデータとでページ全部が出来上がるようにする。これが、コピー・オン・ライト(copy on write)・プロセスの開始となる。
3)データを組み合わせる − データ・ページの読み出しおよび書き込みの要求のペイロードを、単一の連続するブロックに入れる。
4)リスト割り当てを自由にする − 新しいデータ・ページ・ポインタを、フリー・リストから得る。
5)組み合わせたデータを、新しいデータ・ページへ書き込む。
6)新しいページ情報をログへ記憶する。
7)テーブルを更新する − テーブル内のLBA再マッピングを変更して、新しいデータ・ページ・ポインタを反映させる。これでデータ・ページはPITCにより所有される。
【0118】
ページを追加するには、そのページがテーブルに追加されるまで、読み出しおよび書き込みの要求を妨げることが必要であり得る。スナップショットは、テーブルの更新をディスクへ書き込み、ログの複数のキャッシュ記憶されたコピーを維持することにより、コントローラのコヒーレンシを達成する。
【0119】
読み出し要求に関して、APはすべての読み出し要求を満たす。読み出し要求は、APテーブルを用いて、LBAを、そのデータ・ページのLBAへ再マッピングする。再マッピングされたLBAはRAIDインターフェースへと渡されて、その要求が満たされる。ボリュームは、それまでにそのボリュームへ書き込まれていないデータ・ページに対する読み出し要求を満たすことができる。こうしたページは、PITCテーブルにおいてNULLアドレス(すべて1)でマークされている。このアドレスに対する要求は、NULLボリュームにより満たされ、一定のデータ・パターンを返す。異なるPITCテーブルの所有するページは、ページ境界にまたがる読み出し要求を満たすことができる。
【0120】
スナップショットは、NULLボリュームを使用して、以前に書き込まれていないデータ・ページに対する読み出し要求を満たす。これは、それぞれのセクタ読み出しに対して、すべてゼロを返す。これは、RAID装置も、割り当てられた空間もない。NULLボリュームに対する読み出しについてのデータ要件を満たすために、すべてゼロであるブロックをメモリ内に置いておくことが予期される。すべてのボリュームは、読み出し要求を満たすためにNULLボリュームを共用する。
【0121】
一実施形態では、合体プロセスが、PITCと、その所有ページの一部とをボリュームから取り除く。PITCを取り除くと、新しい差異を追跡するために使用可能な空間がより多く作成される。合体では、2つの隣接するテーブルを差異があるかどうか比較し、新しい差異だけを維持する。合体は、ユーザによるコンフィギュレーションに従って、定期的にまたは手動で起きる。
【0122】
このプロセスは、2つのPITC、即ち、ソースと宛先とを含む。一実施形態での、適格なオブジェクトについての規則は、次のようなものである。
1)ソースは、宛先に対して、以前のPITCでなければならない − ソースは宛先より前に作成されなければならない。
2)宛先は、同時にソースであってはならない。
3)ソースは、複数のPITCにより参照されてはならない。複数の参照は、ビュー・ボリュームがPITCから作成されたときに、起きる。
4)宛先は、複数の参照をサポートし得る。
5)APは宛先であり得るが、ソースではない。
【0123】
合体・プロセスは、すべての変更をディスクへ書き込むものであり、コヒーレンシを必要としない。コントローラが故障した場合に、ボリュームがPITC情報をディスクからリカバリし、合体プロセスを再開する。
【0124】
このプロセスは、2つのPITCを合体のためにマークするものであり、以下の諸ステップを含む。
【0125】
1)ソースの状態が合体のソースに設定される − この状態は、コントローラ障害のリカバリのために、ディスクへ記憶される。この時点で、ソースはもはやアクセスされないが、それは、そのデータ・ページが無効であるからである。データ・ページがフリー・リストへ返されるか、または所有権が宛先へ移される。
【0126】
2)宛先の状態が合体の宛先へ設定される − この状態は、コントローラ障害のリカバリのためにディスクへ記憶される。
【0127】
3)テーブルのロードおよび比較を行う − このプロセスは、データ・ページ・ポインタを移動させる。解放されたデータ・ページは、直ちにフリー・リストに追加される。
【0128】
4)宛先の状態が正常に設定される − プロセスが完了する。
【0129】
5)リストを調整する − ソースのnext(次)ポインタのprevious(以前)を、宛先へと変更する。これにより、ソースがリストから効率よく取り除かれる。
【0130】
6)ソースを解放する − 制御の情報に使用された何れのデータ・ページをも、フリー・リストへ戻す。
【0131】
上述のプロセスは、2つのPITCの組合せをサポートしている。合体を、単一のパスにおいて複数のPITCの削除と複数のソースの作成とを行うように設計できることが、当業者には理解されている。
【0132】
図2に示すように、ページ・プールは、そのページ・プールに関連するすべてのボリュームが使用するように、データ・ページ・フリー・リストを維持する。フリー・リスト・マネージャは、ページ・プールからのデータ・ページを使用して、フリー・リストを永久的ストレージへ記憶する。フリー・リストの更新を引き起こすものは幾つもあり、書き込みプロセスはページを割り当て、制御ページ・マネージャはページを割り当て、合体用プロセスはページを返す。
【0133】
フリー・リストは、それ自体をある閾値のところで自動的に拡張するためのトリガを維持することができる。このトリガは、ページをページ・プールへ追加するためのページ・プール拡張方法を使用する。自動的な拡張は、ボリューム・ポリシの一機能とすることもできる。重要度の高いデータ・ボリュームには拡張を可能にし、重要度の低いボリュームは強制的に合体させる。
【0134】
ビュー・ボリュームは、以前のポイント・イン・タイムへのアクセスを提供し、正常のボリュームI/O動作をサポートする。PITCは、PITC間の差異を追跡し、ビュー・ボリュームは、PITC内に含まれる情報へユーザがアクセスできるようにする。ビュー・ボリュームはPITCから分岐する。ビュー・ボリュームは、リカバリ、検査、バックアップ動作などをサポートする。ビュー・ボリュームの作成は、データ・コピーを必要としないので、ほぼ瞬間的に生じる。ビュー・ボリュームは、ビュー・ボリュームへの書き込みをサポートするために、それ自体のAPが必要になり得る。
【0135】
ボリュームの現在の状態から取られたビューでは、APを現在のボリュームのAPからコピーすることができる。APを用い、ビュー・ボリュームは、ビュー・ボリュームのへの書き込み動作を、基礎となるデータを変更せずに行うことを可能にする。OSは、データを使用するために、ファイル・システムまたはファイルの再構築を必要とし得る。ビュー・ボリュームは、APおよび書き込まれたデータ・ページに対して親ボリュームから空間を割り当てる。ビュー・ボリュームは、関連するRAID装置情報を有さない。ビュー・ボリュームを削除すると、空間が解放され親ボリュームへ戻される。
【0136】
図12に、スナップショットを用いてのあるボリュームに関する推移を示す例示的なスナップショット動作を示す。図12は、10ページをもつボリュームを示す。それぞれの状態(ステート)は、ボリュームに対する読み出し要求遂行(Read Request Fulfillment)リストを含む。影を付けたブロックは、所有データ・ページ・ポインタを示す。
【0137】
図の左側(即ち、初期状態)から図の中央への推移は、ページ3および8への書き込みを示している。ページ3への書き込みには、PITC I(AP)への変更が必要である。PITC Iは、新ページ書き込み処理に従い、ページ3をテーブルへ追加する。PITCは、変更されていない情報をページJから読み出し、ドライブ・ページBを使用してそのページを保存する。このPITCのページ3へのこれ以降のすべての書き込みは、ページを移動させずに取り扱われる。ページ8への書き込みでは、ページへの書き込みに関する第2の場合を示す。PITC Iはすでにページ8を含んでいるため、PITC Iは、ページ8のそのデータのその部分へ書き込む。この場合、それはドライブ・ページCに存在する。
【0138】
図の中央から図の右側(即ち、最終状態)への推移は、PITC IIとIIIとの合体を示す。スナップショットの合体は、それぞれ、古いページを削除すること、および両方のPITCにおけるすべての変更を維持することを含む。両方のPITCがページ3および8を含む。プロセスは、PITC IIからのの新しい方のページを保ち、PITC IIIからのページを解放し、ページAおよびDをフリー・リストへ返す。
【0139】
スナップショットは、フリー・リストおよびPITCテーブル情報を保存するために、ページ・プールからデータ・ページの割り当てを行う。制御ページの割り当ては、データ・ページを、オブジェクトに必要とされるサイズに合うように、更に細かく割り当てる(sub-allocate)。
【0140】
ボリュームは、制御ページ情報の先頭に対するページ・ポインタを含む。このページから、他のすべての情報を読み出すことができる。
【0141】
スナップショットは、特定の時間間隔で、使用中のページの数を追跡する。これにより、スナップショットは、いつユーザがシステムに更なる物理ディスク空間を追加する必要があるかを予測して、スナップショットが不足するのを防ぐ。
【0142】
データ・プログレッション
本発明の一実施形態では、データ・プログレッション(DP、data progression)を使用して、データを、徐々に、適切なコストのストレージ空間へと移動させる。本発明により、ユーザは、ドライブが実際に必要であるときにドライブの追加を行える。これにより、ディスク・ドライブのコスト全体が著しく低減される。
【0143】
データ・プログレッションでは、最近アクセスされていないデータおよび履歴のスナップショット・データを、より安価なストレージへ移動させる。最近アクセスされていないデータについては、最近アクセスされていないページがに対してのストレージのコストを徐々に低減する。データは、コストが最も低いストレージへ直ちに移動させない。履歴のスナップショット・データについては、読み出し専用ページを、例えばRAID5などのようなより効率のよいストレージ空間へ移動させ、また、そのページにもはやボリュームからアクセス可能でない場合には、最も安価なストレージへ移動される。
【0144】
本発明のデータ・プログレッションの他の利点は、現在アクセス中のデータへの高速のI/Oアクセスを維持すること、および高速であるが高価なディスク・ドライブを購入する必要性を減らすことを含む。
【0145】
データ・プログレッションでは、動作時に、ストレージのコストを、物理メディアのコストおよびデータ保護に使用されるRAID装置の効率を用いて、判定する。また、データ・プログレッションでは、ストレージ効率を判定し、それに従ってデータの移動を行う。例えば、データ・プログレッションは、物理ディスク空間をより効率よく使用するために、RAID10装置をRAID5装置へと変換することができる。
【0146】
データ・プログレッションでは、アクセス可能なデータを、サーバが現在読み出しまたは書き込みできるデータと定義している。データ・プログレッションでは、アクセス可能性(accessibility)を使用して、ページが使用すべきストレージのクラスを決定する。ページは、履歴PITCに属する場合には、読み出し専用である。サーバが、一番最近のPITCにおいてそのページを更新していない場合には、そのページはまだアクセス可能である。
【0147】
図17に、データ・プログレッション動作におけるアクセス可能なデータ・ページの一実施形態を示す。アクセス可能なデータ・ページは、以下のカテゴリに分かれる。
【0148】
・アクセス可能な、最近アクセスされたもの − これらは、ボリュームが最もよく使用しているアクティブ・ページである。
【0149】
・アクセス可能な、最近アクセスされていないもの − 最近使用されていない読み出し/書き込みページ。
【0150】
・履歴のアクセス可能なもの − ボリュームによる読み出しが行える読み出し専用ページ −− スナップショット・ボリュームに当てはまる。
【0151】
・履歴のアクセス不能なもの − ボリュームによって現在アクセスされていない読み出し専用データ・ページ −− スナップショット・ボリュームに当てはまる。スナップショットは、こうしたページをリカバリ目的で維持し、ページは、一般に、可能な限り低コストのストレージに置かれる。
【0152】
図17に、スナップショット・ボリューム用の様々な所有ページを有する3つのPITCを示している。動的容量のボリュームは、PITC Cだけで代表させてある。すべてのページは、アクセス可能であり読み出し/書き込みである。ページは異なるアクセス時間を有し得る。
【0153】
下記のテーブルは、様々なストレージ装置を、効率の高くなる順または金銭的な支出の減る順に示す。ストレージ装置のリストは、より遅い書き込みI/Oアクセスの一般的な順序にも従い得る。データ・プログレッションでは、論理保護空間の効率をRAID装置の総物理空間で割ったものを計算する。
【0154】
【表1】
【0155】
RAID5の効率は、ストライプのドライブ数が増えると高くなる。ストライプのディスク数が増えると、フォールト・ドメインが増大する。ストライプのドライブ数の増加により、RAID装置の作成に必要なディスクの最小数も増える。一実施形態では、データ・プログレッションは、9ドライブを超えるRAID5ストライプ・サイズを使用しない。なぜなら、フォールト・ドメイン・サイズが増え、効率の増加が限られるからである。データ・プログレッションは、スナップショット・ページ・サイズの整数倍であるRAID5ストライプ・サイズを使用する。これにより、データ・プログレッションは、ページをRAID5へと移動させるときにフル・ストライプ書き込みを行えるようになり、移動の効率を高める。すべてのRAID5コンフィギュレーションは、データ・プログレッションの目的で、同じ書き込みI/O特性を有する。例えば、2.5インチ(6.5cm)FCディスク上のRAID5は、そうしたディスクの性能を効率よく使用しない可能性がある。この組合せを防ぐために、データ・プログレッションは、あるRAIDタイプが特定のディスクタイプ上で動作しないようにする機能をサポートする必要がある。また、データ・プログレッションのコンフィギュレーションは、システムがRAID10またはRAID5の空間を使用しないようにすることもできる。
【0156】
ディスクのタイプを次のテーブルに示す。
【0157】
【表2】
【0158】
データ・プログレッションは、システム内のドライブに相対的なディスク・ドライブの分類を自動的に行う機能を含む。システムは、ディスクを検査して、そのパフォーマンスをシステム内の他のディスクと比較して決定する。より速いディスクは高評価区分へと分類され、より遅いディスクは低評価区分へと分類される。ディスクがシステムへ追加されると、システムは、ディスクの評価分類のバランスを自動的にとり直す。このアプローチでは、決して変化することのないシステムと、新しいディスクが追加されると頻繁に変化するシステムとの双方を取り扱う。この自動分類は、複数のドライブ・タイプを同じ評価区分内に入れることがある。ドライブの評価がかなり近接しているものと判定された場合には、その評価は同じになる。
【0159】
一実施形態では、システムは次のドライブを含む。即ち、
高 − 10K FCドライブ
低 − SATAドライブ
【0160】
15K FCドライブを追加すると、データ・プログレッションは、ディスクを自動的に再分類し、10K FCドライブを降格させる。この結果として次の分類となる。
高 − 15K FCドライブ
中 − 10K FCドライブ
低 − SATAドライブ
【0161】
別の実施形態では、システムには次のドライブ・タイプを有し得る。
高 − 25K FCドライブ
低 − 15K FCドライブ
【0162】
従って、15K FCドライブは評価の低い区分として分類され、これに対して15K FCドライブは評価の高い区分として分類される。
【0163】
SATAドライブがシステムに追加された場合、データ・プログレッションは、ディスクを時間的に再分類する。その結果として次の分類となる。
高 − 25K FCドライブ
中 − 15K FCドライブ
低 − SATAドライブ
【0164】
データ・プログレッションは、ウォーターフォール(waterfall)・プログレッションを含むことができる。典型的に、ウォーターフォール・プログレッションはデータをより安価な資源へ移動させるが、その移動は、その資源が完全に使用されたときにのみ行う。ウォーターフォール・プログレッションは、最も高価なシステム資源の使用を効率的に最大化する。システムのコストの最小化も行う。安いディスクを最も低いプールに追加すると、ボトム(底部)において、より大きなプールが作成される。
【0165】
典型的なウォーターフォール・プログレッションは、RAID10空間を使用し、次いで、RAID5空間などのような、RAID空間の次のものを使用する。このことにより、ウォーターフォールが次のクラスのディスクのうちのRAID10へ直接向かうように強制される。代替例として、データ・プログレッションは、図24に示すような混合RAIDウォーターフォール・プログレッションを含んでもよい。この代替のデータ・プログレッション方法により、ディスク空間およびパフォーマンスを最大化する問題が解決され、ストレージは同じディスク・クラスにおいて更に効率のよい形式へと変形できる。また、この代替方法では、RAID10およびRAID5が或るディスク・クラスの資源全体を共用するという要件をサポートする。これには、あるRAIDレベルがあるクラスのディスク用に使用する、ディスク空間の一定の割合をコンフィギュレーションすることが必要であることがある。従って、この代替のデータ・プログレッション方法では、高価なストレージの使用が最大化され、かつ、別のRAIDクラスが共存する余地を残す。
【0166】
また、混合RAIDウォーターフォールでは、ストレージが限られているときのみ、ページをより安価なストレージへと移動させる。ディスク空間全体のうちの或るパーセンテージなどのような閾値により、特定のRAIDタイプのストレージの量が制限される。これにより、システムにおける最も高価なストレージの使用が最大化される。ストレージがその限度に近づくと、データ・プログレッションは、ページを、コストのより低いストレージへと自動的に移動させる。データ・プログレッションは、書き込みスパイクに対するバッファを提供することができる。
【0167】
上述のウォーターフォール方法では、一部の場合のように、ページをコストが最も低いストレージへと直ちに移動させ得るということが理解され、履歴およびアクセス不能のページをより安価なストレージ上へ適時に移動させる必要性があり得る。また、履歴ページをより安価なストレージへ直ちに移動させることもできる。
【0168】
図18に、データ・プログレッションのプロセス1800の流れ図を示す。データ・プログレッションは、システムのそれぞれのページを、そのアクセスのパターンおよびストレージのコストに関して絶えず検査して、移動させるべきデータ・ページがあるかどうか判定する。また、データ・プログレッションは、ストレージがその最大割り当て量に達しているかどうかを判定することもできる。
【0169】
データ・プログレッションのプロセスは、そのページがどのボリュームからもアクセス可能かどうかを判定する。プロセスは、履歴に付加されている各ボリュームについてのPITCを検査して、そのページが参照されているかどうかを判定する。そのページがアクティブに使用中である場合には、そのページは昇格させるに又は降格を遅くするに望ましい。そのページがどのボリュームからもアクセス可能でない場合には、使用可能な最も低コストのストレージへ移動させられる。また、データ・プログレッションは、PITCが期限切れになる前に時間を計算に入れる。スナップショットで、PITCがまもなく期限切れになるようにスケジュールしている場合には、ページのプログレッションは行わない。ページ・プールがアグレッシブ・モードで動作中の場合には、ページのプログレションが行われ得る。
【0170】
データ・プログレッションの最近アクセス検出(recent access detection、最近されたアクセスの検出)では、ページの昇格動作から一塊の活動を取り除く必要がある。データ・プログレッションでは、読み出しと書き込みのアクセス追跡を分離している。これにより、データ・プログレッションは、アクセス可能であるRAID5装置上のデータを保持することが可能とされる。ウイルスのスキャンや報告などのような動作は、データを読み出すのみである。データ・プログレッションは、ストレージが残り少なくなっているときに、最近アクセス(recent access)の資格を変更する。これにより、データ・プログレッションは、ページの降格をよりアグレッシブに行えるようになる。また、これは、ストレージが残り少なくなっているときに、システムをボトム(底)の方から詰めていくのに役立つ。
【0171】
データ・プログレッションは、システム資源が少なくなるとデータ・ページをアグレッシブ(積極的)に移動させることができる。より多くのディスクまたはコンフィギュレーションの変更は、こうした場合のすべてでやはり必要である。データ・プログレッションは、時間のない状況においてシステムが動作し得る時間の量を延ばす。データ・プログレッションは、システムをできるだけ長く動作可能に保つように試みる。その時間とは、そのすべてのストレージ・クラスの空間がなくなるときである。
【0172】
RAID10空間が残り少なくなっており、使用可能なディスク空間全体が残り少なくなっている場合には、データ・プログレッションは、RAID10ディスク空間を取り上げて、より効率のよいRAID5へと移動させることができる。これにより、システムの全体容量が、書き込み性能を犠牲にして、増加する。より多くのディスクはやはり必要である。特定のストレージ・クラスが完全に使用された場合、データ・プログレッションは、受け入れ可能でないページを借りてシステムを動作させ続けることができる。例えば、あるボリュームが、RAID10―FCを、そのアクセス可能情報用に使用するようにコンフィギュレーションされている場合に、より多くのRAID10−FC空間が使用可能になるまで、RAID5−FCまたはRAID10−SATAからページを割り当てる。
【0173】
また、データ・プログレッションは、システムの知覚される容量を増加させるための圧縮をサポートする。圧縮が使用されるのは、アクセスされていない履歴ページに対して、またはリカバリ情報の記憶のためにである。圧縮は、ストレージ・コストの最下部近くの別のクラスのストレージとして現れる。
【0174】
図25に示すように、ページ・プールは、本質的に、フリー・リストおよび装置情報を含む。ページ・プールは、複数のフリー・リスト、強化されたページ割り当て方式、およびフリー・リストの分類をサポートする必要がある。ページ・プールは、ストレージのクラスごとに別々のフリー・リストを維持する。この割り当て方式により、ページを多くのプールのうちの1つから割り当て、且つ、許可される最小または最大のクラスを設定する。フリー・リストの分類は、装置のコンフィギュレーションに由来する。それぞれのフリー・リストは、統計の収集および表示のためにそれ自体のカウンタを提供する。また、それぞれのフリー・リストは、ストレージ効率の統計の収集のためのRAID装置効率情報を提供する。
【0175】
一実施形態では、装置リストには、ストレージ・クラスのコストを追跡する更なる機能が必要であり得る。組合せにより、ストレージのクラスが決定される。これが起きるのは、ユーザが、コンフィギュレーションしたクラスの粒度がより荒いまたは細かいものであることを希望する場合である。
【0176】
図26に、高性能のデータベースの一実施形態を示しており、ここでは、すべてのアクセス可能なデータは、最近アクセスされていない場合でも、2.5FCドライブ上にある。アクセス不能な履歴データは、RAID5ファイバ・チャネルへ移動される。
【0177】
図27は、MRI画像ボリュームの一実施形態を示しており、ここでは、アクセス可能なストレージは、この動的なボリューム用のSATA RAID10およびRAID5である。画像が最近アクセスされていない場合、画像はRAID5へ移動される。その場合、新しい書き込みは、初めはRAID10へ向かう。図19は、圧縮されたページ・レイアウトの一実施形態を示す。データ・プログレッションは、圧縮を、固定サイズのデータ・ページを更に細かく割り当てることによって、実装する。更に細かい割り当て(sub-allocation、サブ・アロケーション)の情報は、ページの空きの部分、およびページの割り当て済みの部分の場所を追跡する。データ・プログレッションは、圧縮の効率を予測することはできないが、そのサブ・アロケーション範囲内で可変サイズのページを取り扱うことができる。
【0178】
圧縮されたページは、CPUの性能に著しく影響することがある。書き込みアクセスの場合、圧縮されたページは、ページ全体の圧縮解除および再圧縮が必要となるはずである。従って、アクティブにアクセスされているページは、圧縮されず、非圧縮の状態に戻される。書き込みは、ストレージが極度に限られた状況で必要となり得る。
【0179】
PITC再マッピング・テーブルは、サブ・アロケーション情報を指し、圧縮されているページを示すようにマークされる。圧縮されたページにアクセスするには、非圧縮のページよりも高いI/Oカウントが必要になり得る。アクセスには、実際のデータの場所を取り出すために、サブ・アロケーション情報の読み出しが必要になる。圧縮されたデータは、ディスクから読み出し、プロセッサで圧縮解除することができる。
【0180】
データ・プログレッションでは、圧縮は、ページ全体のうちの一部を圧縮解除できるようにすることが必要とされ得る。これにより、データ・プログレッションの読み出しアクセスは、そのページの小さな部分のみの圧縮解除を行える。読み出しキャッシュの先読み機能は、圧縮の遅延に対して役立ち得る。一つの圧縮解除で、幾つものサーバI/Oを取り扱うことができる。データ・プログレッションは、圧縮の候補として適さないページにマークし、それによって、或るページの圧縮を続けて試みないようにする。
【0181】
図20に、本発明の諸原理に従った、高レベルのディスク・ドライブ・システムにおけるデータ・プログレッションの一実施形態を示す。データ・プログレッションは、ボリュームの外面的な振る舞いやデータ・パスの動作を変更しない。データ・プログレッションは、ページ・プールへの変更を必要とし得る。ページ・プールは、本質的に、フリー・リストおよび装置情報を含む。ページ・プールは、複数のフリー・リスト、強化されたページ割り当て方式、およびフリー・リストの分類をサポートする必要がある。ページ・プールは、ストレージのそれぞれのクラスに対して個々のフリー・リストを維持する。割り当て方式は、許可される最小および最大のクラスを設定しつつ、ページが多くのプールのうちの1つから割り当てられるようにする。フリー・リストの分類は、装置のコンフィギュレーションに由来することができる。それぞれのフリー・リストは、統計の収集および表示のためにそれ自体のカウンタを提供する。また、それぞれのフリー・リストは、ストレージの効率の統計の収集のためにRAID装置効率情報を提供する。
【0182】
PITCは、移動の候補を識別し、その移動のときには、アクセス可能なページへのI/Oを妨げる。データ・プログレッションは、候補に関してPITCを継続的に検査する。ページのアクセス可能性は、サーバI/O、新しいスナップショット・ページ更新、およびビュー・ボリュームの作成/削除に起因して、継続的に変化する。また、データ・プログレッションは、ボリュームのコンフィギュレーションの変更を継続的に検査し、ページのクラスおよびカウントの現在のリストをまとめあげる。これにより、データ・プログレッションは、そのまとめ(一覧)を評価し、移動するページがあるかを判定できる。
【0183】
それぞれのPITCは、ストレージの各クラスに使用されるページの数に関するカウンタを提示する。データ・プログレッションは、この情報を使用して、閾値に達したときにページを移動させるための良い候補になるPITCを識別する。
【0184】
RAIDは、ディスクのコストに基づいて、1組のディスクから装置を割り当てる。また、RAIDは、装置または潜在的な装置の効率を取り出すAPIを提供する。また、これは、書き込み動作に必要なI/Oの数についての情報を返す必要がある。また、データ・プログレッションは、また、サード・パーティのRAIDコントローラをデータ・プログレッションの一部として使用するために、RAID NULLを必要とし得る。RAID NULLは、ディスク全体を消費し得、単にパス・スルー・レイヤとして働き得る。
【0185】
また、ディスク・マネージャは、ディスク分類を自動的に決定し保存することができる。ディスク分類を自動的に決定するには、SCSIイニシエータへの変更が必要となり得る。
【0186】
上述の説明および図面から、ここに示し説明した特定の諸実施形態は、もっぱら例示を目的としており、本発明の範囲を限定するものではないことが当業者には理解されよう。本発明を他の特定の形式で実施することは、その趣旨または本質的な諸特徴から逸脱することなく行えることが当業者には理解されよう。特定の諸実施形態の詳細への言及は、本発明の範囲を限定するものではない。
【特許請求の範囲】
【請求項1】
ストレージのプールにおいてデータを動的に割り当てる能力を有するディスク・ドライブ・システムであって、
データ・ストレージ・サブシステムと、
前記データ・ストレージ・サブシステムからのストレージ空間からなる複数のユーザ・ボリュームと、
少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャと
を含み、
前記ディスク・マネージャは、
前記データ・ストレージ・サブシステムの仮想ボリュームのマトリックスを含むストレージのプールを維持するように構成され、前記仮想ボリュームのそれぞれは、複数の物理的ストレージ・デバイスの抽象化されたものであり、予め定められたサイズを有するものであり、
自由な仮想ボリュームを、前記仮想ボリュームのマトリックスから前記複数のユーザ・ボリュームへ動的に割り当てるように構成され、
割り当てられた前記仮想ボリュームへデータを書き込むように構成される
ものである、
システム。
【請求項2】
請求項1に記載のシステムであって、前記データ・ストレージ・サブシステムおよび前記ディスク・マネージャは、更に別のディスク・ドライブが必要であるかを判定し、前記更に別のディスク・ドライブが必要である場合には通知が送られる、システム。
【請求項3】
請求項1または2に記載のシステムであって、前記ディスク・マネージャは複数のディスク・ストレージ・システム・コントローラを管理する、システム。
【請求項4】
請求項1ないし3の何れかに記載のシステムであって、動作されるディスク・ストレージ・システム・コントローラの障害をカバーするために複数の冗長なディスク・ストレージ・システム・コントローラを更に備える、システム。
【請求項5】
請求項1ないし4の何れかに記載のシステムであって、前記データ・ストレージ・サブシステムは、RAID−0、RAID−1、RAID−5、RAID−10などのようなRAIDタイプのうちの少なくとも1つを含む組合せを更に備える、システム。
【請求項6】
請求項5に記載のシステムであって、前記データ・ストレージ・サブシステムは、RAID−3、RAID−4、RAID−6、およびRAID−7を含むRAIDタイプを更に備える、システム。
【請求項7】
請求項1ないし6の何れかに記載のシステムであって、前記仮想ボリュームは、複数のRAIDデバイスを抽象化したものである、システム。
【請求項8】
請求項1ないし7の何れかに記載のシステムであって、前記少なくとも1つのディスク・ストレージ・システム・コントローラは、自動的に、所定の時間間隔で前記仮想ボリュームのそれぞれに対するスナップショットを生成し、それぞれのスナップショットのアドレス・インデックスを関連する仮想ボリュームに記憶し、記憶したアドレス・インデックスを介して前記仮想ボリュームの前記スナップショットの位置が即座に見つかるようにするものであり、前記スナップショットは、以前の時間間隔でとられた以前のスナップショット以降になされた、関連する仮想ボリュームにおけるデータに対する変更を含むものである、システム。
【請求項9】
請求項1ないし7の何れかに記載のシステムであって、前記少なくとも1つのディスク・ストレージ・システム・コントローラは、自動的に、前記仮想ボリュームのそれぞれに対するスナップショットを生成し、それぞれのスナップショットのアドレス・インデックスを記憶し、記憶した前記アドレス・インデックスを介して少なくとも1つの前記スナップショットにアクセスし、第1の時点での関連する仮想ボリュームのコンテンツのビューを提供する少なくとも1つの前記スナップショットに基づいて少なくとも1つの前記スナップショットのそれぞれから一時的なボリュームを生成するものであり、前記スナップショットは、以前の時点である第2の時点でとられた以前のスナップショット以降になされた、関連する仮想ボリュームにおけるデータに対する変更を含むものである、システム。
【請求項10】
データ・ストレージ・サブシステムのデータを動的に割り当てる方法であって、
前記データ・ストレージ・サブシステムの複数のデータ・ストレージ・デバイスからのストレージ空間の複数のユーザ・ボリュームを生成するステップと、
前記データ・ストレージ・サブシステムの仮想ボリュームのマトリックスを含むストレージのプールを管理するステップであって、前記仮想ボリュームのそれぞれは、複数の物理的ストレージ・デバイスの抽象化されたものであり、予め定められたサイズを有するものである、ステップと、
ストレージのプールを用いて、自由な仮想ボリュームを、前記仮想ボリュームのマトリックスから前記複数のユーザ・ボリュームへ動的に割り当てるステップと、
割り当てられた前記仮想ボリュームへデータを書き込むステップと
を備える方法。
【請求項11】
請求項10に記載の方法であって、
前記データ・ストレージ・サブシステムのディスク空間の占有率を、前記データ・ストレージ・サブシステムの前記ディスク空間の占有率の履歴に基づいて決定するステップと、
前記占有率に基づいて、前記データ・ストレージ・サブシステムに追加のディスク・ドライブが必要であるかを判定するステップと、
前記追加のディスク・ドライブが必要である場合には、通知を前記データ・ストレージ・サブシステムへ送るステップと
更に備える方法。
【請求項12】
請求項11に記載の方法であって、前記通知を電子メールによって送ることを更に含む、方法。
【請求項13】
請求項10ないし12の何れかに記載の方法であって、仮想ボリュームの前記予め定められたサイズは、デフォルトのサイズであり、ユーザによって変更可能である、方法。
【請求項14】
請求項10ないし13の何れかに記載の方法であって、前記複数のユーザ・ボリュームは、RAID−0、RAID−1、RAID−5、RAID−10の、複数のRAIDタイプのうちの少なくとも1つからのディスク空間ブロックを備える、方法。
【請求項15】
請求項10ないし14の何れかに記載の方法であって、
所定の時間間隔で前記仮想ボリュームのそれぞれに対するスナップショットを自動的に生成するステップであって、それぞれのスナップショットは、以前の時間間隔でとられた以前のスナップショット以降になされた、関連する仮想ボリュームにおけるデータに対する変更を含むものである、ステップと、
それぞれのスナップショットのアドレス・インデックスを記憶するステップであって、記憶したアドレス・インデックスを介して前記仮想ボリュームの前記スナップショットの位置が即座に見つかるようにするものである、ステップと
を更に備える方法。
【請求項16】
請求項15に記載の方法であって、それぞれのスナップショットは、関連する仮想ボリュームへの書き込み動作の記録を含む、方法。
【請求項17】
請求項15または16に記載の方法であって、前記所定の時間間隔はユーザにより定められたものである、方法。
【請求項18】
請求項15ないし17の何れかに記載の方法であって、前記時間間隔は、数秒毎から数時間毎の範囲である、方法。
【請求項19】
請求項15ないし18の何れかに記載の方法であって、前記スナップショットは、主とするシステムが壊れた場合にデータのインテグリティに影響がなく且つデータを即座にリカバリできるように、リモートのデータ・ストレージ・サブシステムで記憶される、
方法。
【請求項20】
請求項15ないし19の何れかに記載の方法であって、ユーザのリクエストに応じて少なくとも1つの仮想ボリュームに対するスナップショットを生成するステップを更に備える方法。
【請求項21】
請求項15ないし20の何れかに記載の方法であって、少なくとも2つのスナップショットを、関連する仮想ボリュームについて、合体させるステップを更に備える方法。
【請求項22】
請求項10ないし14の何れかに記載の方法であって、
前記仮想ボリュームに対して複数のスナップショットを生成するステップと、
前記スナップショットのアドレス・インデックスを記憶するステップと、
記憶された前記アドレス・インデックスを介して複数の前記スナップショットの少なくとも1つのスナップショットにアクセスするステップと、
アクセスされた前記少なくとも1つのスナップショットから一時的なボリュームを生成するステップであって、前記一時的なボリュームは、特定の時点での関連する仮想ボリュームのコンテンツのビューを提供するものである、ステップと
を更に備える方法。
【請求項23】
請求項22に記載の方法であって、前記スナップショットは所定の時間間隔で生成される、方法。
【請求項24】
請求項22または23に記載の方法であって、前記仮想ボリュームの基礎となるデータを変えることなく前記一時的なボリュームを変更するステップを更に備える方法。
【請求項25】
請求項22ないし24の何れかに記載の方法であって、前記一時的なボリュームは検査に使用され、前記検査は、前記仮想ボリュームの基礎となるデータを変えることなく、前記時点にあったときのデータに対して行われる、方法。
【請求項26】
請求項22ないし25の何れかに記載の方法であって、前記一時的なボリュームは訓練に使用され、前記訓練は、前記仮想ボリュームの基礎となるデータを変えることなく、前記時点にあったときのデータに対して行われる、方法。
【請求項27】
請求項22ないし26の何れかに記載の方法であって、前記一時的なボリュームは前記データのバックアップに使用される、方法。
【請求項28】
請求項22ないし27の何れかに記載の方法であって、前記一時的なボリュームは前記データのリカバリに使用される、方法。
【請求項1】
ストレージのプールにおいてデータを動的に割り当てる能力を有するディスク・ドライブ・システムであって、
データ・ストレージ・サブシステムと、
前記データ・ストレージ・サブシステムからのストレージ空間からなる複数のユーザ・ボリュームと、
少なくとも1つのディスク・ストレージ・システム・コントローラを有するディスク・マネージャと
を含み、
前記ディスク・マネージャは、
前記データ・ストレージ・サブシステムの仮想ボリュームのマトリックスを含むストレージのプールを維持するように構成され、前記仮想ボリュームのそれぞれは、複数の物理的ストレージ・デバイスの抽象化されたものであり、予め定められたサイズを有するものであり、
自由な仮想ボリュームを、前記仮想ボリュームのマトリックスから前記複数のユーザ・ボリュームへ動的に割り当てるように構成され、
割り当てられた前記仮想ボリュームへデータを書き込むように構成される
ものである、
システム。
【請求項2】
請求項1に記載のシステムであって、前記データ・ストレージ・サブシステムおよび前記ディスク・マネージャは、更に別のディスク・ドライブが必要であるかを判定し、前記更に別のディスク・ドライブが必要である場合には通知が送られる、システム。
【請求項3】
請求項1または2に記載のシステムであって、前記ディスク・マネージャは複数のディスク・ストレージ・システム・コントローラを管理する、システム。
【請求項4】
請求項1ないし3の何れかに記載のシステムであって、動作されるディスク・ストレージ・システム・コントローラの障害をカバーするために複数の冗長なディスク・ストレージ・システム・コントローラを更に備える、システム。
【請求項5】
請求項1ないし4の何れかに記載のシステムであって、前記データ・ストレージ・サブシステムは、RAID−0、RAID−1、RAID−5、RAID−10などのようなRAIDタイプのうちの少なくとも1つを含む組合せを更に備える、システム。
【請求項6】
請求項5に記載のシステムであって、前記データ・ストレージ・サブシステムは、RAID−3、RAID−4、RAID−6、およびRAID−7を含むRAIDタイプを更に備える、システム。
【請求項7】
請求項1ないし6の何れかに記載のシステムであって、前記仮想ボリュームは、複数のRAIDデバイスを抽象化したものである、システム。
【請求項8】
請求項1ないし7の何れかに記載のシステムであって、前記少なくとも1つのディスク・ストレージ・システム・コントローラは、自動的に、所定の時間間隔で前記仮想ボリュームのそれぞれに対するスナップショットを生成し、それぞれのスナップショットのアドレス・インデックスを関連する仮想ボリュームに記憶し、記憶したアドレス・インデックスを介して前記仮想ボリュームの前記スナップショットの位置が即座に見つかるようにするものであり、前記スナップショットは、以前の時間間隔でとられた以前のスナップショット以降になされた、関連する仮想ボリュームにおけるデータに対する変更を含むものである、システム。
【請求項9】
請求項1ないし7の何れかに記載のシステムであって、前記少なくとも1つのディスク・ストレージ・システム・コントローラは、自動的に、前記仮想ボリュームのそれぞれに対するスナップショットを生成し、それぞれのスナップショットのアドレス・インデックスを記憶し、記憶した前記アドレス・インデックスを介して少なくとも1つの前記スナップショットにアクセスし、第1の時点での関連する仮想ボリュームのコンテンツのビューを提供する少なくとも1つの前記スナップショットに基づいて少なくとも1つの前記スナップショットのそれぞれから一時的なボリュームを生成するものであり、前記スナップショットは、以前の時点である第2の時点でとられた以前のスナップショット以降になされた、関連する仮想ボリュームにおけるデータに対する変更を含むものである、システム。
【請求項10】
データ・ストレージ・サブシステムのデータを動的に割り当てる方法であって、
前記データ・ストレージ・サブシステムの複数のデータ・ストレージ・デバイスからのストレージ空間の複数のユーザ・ボリュームを生成するステップと、
前記データ・ストレージ・サブシステムの仮想ボリュームのマトリックスを含むストレージのプールを管理するステップであって、前記仮想ボリュームのそれぞれは、複数の物理的ストレージ・デバイスの抽象化されたものであり、予め定められたサイズを有するものである、ステップと、
ストレージのプールを用いて、自由な仮想ボリュームを、前記仮想ボリュームのマトリックスから前記複数のユーザ・ボリュームへ動的に割り当てるステップと、
割り当てられた前記仮想ボリュームへデータを書き込むステップと
を備える方法。
【請求項11】
請求項10に記載の方法であって、
前記データ・ストレージ・サブシステムのディスク空間の占有率を、前記データ・ストレージ・サブシステムの前記ディスク空間の占有率の履歴に基づいて決定するステップと、
前記占有率に基づいて、前記データ・ストレージ・サブシステムに追加のディスク・ドライブが必要であるかを判定するステップと、
前記追加のディスク・ドライブが必要である場合には、通知を前記データ・ストレージ・サブシステムへ送るステップと
更に備える方法。
【請求項12】
請求項11に記載の方法であって、前記通知を電子メールによって送ることを更に含む、方法。
【請求項13】
請求項10ないし12の何れかに記載の方法であって、仮想ボリュームの前記予め定められたサイズは、デフォルトのサイズであり、ユーザによって変更可能である、方法。
【請求項14】
請求項10ないし13の何れかに記載の方法であって、前記複数のユーザ・ボリュームは、RAID−0、RAID−1、RAID−5、RAID−10の、複数のRAIDタイプのうちの少なくとも1つからのディスク空間ブロックを備える、方法。
【請求項15】
請求項10ないし14の何れかに記載の方法であって、
所定の時間間隔で前記仮想ボリュームのそれぞれに対するスナップショットを自動的に生成するステップであって、それぞれのスナップショットは、以前の時間間隔でとられた以前のスナップショット以降になされた、関連する仮想ボリュームにおけるデータに対する変更を含むものである、ステップと、
それぞれのスナップショットのアドレス・インデックスを記憶するステップであって、記憶したアドレス・インデックスを介して前記仮想ボリュームの前記スナップショットの位置が即座に見つかるようにするものである、ステップと
を更に備える方法。
【請求項16】
請求項15に記載の方法であって、それぞれのスナップショットは、関連する仮想ボリュームへの書き込み動作の記録を含む、方法。
【請求項17】
請求項15または16に記載の方法であって、前記所定の時間間隔はユーザにより定められたものである、方法。
【請求項18】
請求項15ないし17の何れかに記載の方法であって、前記時間間隔は、数秒毎から数時間毎の範囲である、方法。
【請求項19】
請求項15ないし18の何れかに記載の方法であって、前記スナップショットは、主とするシステムが壊れた場合にデータのインテグリティに影響がなく且つデータを即座にリカバリできるように、リモートのデータ・ストレージ・サブシステムで記憶される、
方法。
【請求項20】
請求項15ないし19の何れかに記載の方法であって、ユーザのリクエストに応じて少なくとも1つの仮想ボリュームに対するスナップショットを生成するステップを更に備える方法。
【請求項21】
請求項15ないし20の何れかに記載の方法であって、少なくとも2つのスナップショットを、関連する仮想ボリュームについて、合体させるステップを更に備える方法。
【請求項22】
請求項10ないし14の何れかに記載の方法であって、
前記仮想ボリュームに対して複数のスナップショットを生成するステップと、
前記スナップショットのアドレス・インデックスを記憶するステップと、
記憶された前記アドレス・インデックスを介して複数の前記スナップショットの少なくとも1つのスナップショットにアクセスするステップと、
アクセスされた前記少なくとも1つのスナップショットから一時的なボリュームを生成するステップであって、前記一時的なボリュームは、特定の時点での関連する仮想ボリュームのコンテンツのビューを提供するものである、ステップと
を更に備える方法。
【請求項23】
請求項22に記載の方法であって、前記スナップショットは所定の時間間隔で生成される、方法。
【請求項24】
請求項22または23に記載の方法であって、前記仮想ボリュームの基礎となるデータを変えることなく前記一時的なボリュームを変更するステップを更に備える方法。
【請求項25】
請求項22ないし24の何れかに記載の方法であって、前記一時的なボリュームは検査に使用され、前記検査は、前記仮想ボリュームの基礎となるデータを変えることなく、前記時点にあったときのデータに対して行われる、方法。
【請求項26】
請求項22ないし25の何れかに記載の方法であって、前記一時的なボリュームは訓練に使用され、前記訓練は、前記仮想ボリュームの基礎となるデータを変えることなく、前記時点にあったときのデータに対して行われる、方法。
【請求項27】
請求項22ないし26の何れかに記載の方法であって、前記一時的なボリュームは前記データのバックアップに使用される、方法。
【請求項28】
請求項22ないし27の何れかに記載の方法であって、前記一時的なボリュームは前記データのリカバリに使用される、方法。
【図1】
【図2】
【図2A】
【図2B】
【図2C】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図2】
【図2A】
【図2B】
【図2C】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13A】
【図13B】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【公開番号】特開2011−108258(P2011−108258A)
【公開日】平成23年6月2日(2011.6.2)
【国際特許分類】
【出願番号】特願2011−3337(P2011−3337)
【出願日】平成23年1月11日(2011.1.11)
【分割の表示】特願2006−523434(P2006−523434)の分割
【原出願日】平成16年8月13日(2004.8.13)
【出願人】(506051681)コンペレント・テクノロジーズ (10)
【Fターム(参考)】
【公開日】平成23年6月2日(2011.6.2)
【国際特許分類】
【出願日】平成23年1月11日(2011.1.11)
【分割の表示】特願2006−523434(P2006−523434)の分割
【原出願日】平成16年8月13日(2004.8.13)
【出願人】(506051681)コンペレント・テクノロジーズ (10)
【Fターム(参考)】
[ Back to top ]