JP2009543216A - コンピュータ・ストレージ・システムの制御のための方法およびコンピュータ・プログラム - Google Patents

Abstract

【課題】異種のストレージ・コントローラのグループにわたって、目標ベースの可用性および変更の管理を処理する。
【解決手段】ストレージ・コントローラへのストレージ・ボリュームの割り振りおよび配置、ならびに、データ可用性目標を達成するために必要なデータ冗長性の程度を決定するために、確率的および決定論的方法が採用される。確率的方法は、コントローラの可用性の過去の観察、およびオペレータの確信、ならびに、将来の可用性の確率的推定を考案する際のストレージ・コントローラ構成の状態を、考慮に入れることが可能である。
【選択図】 図１

Description

本発明は、一般に情報技術に関し、より具体的にはコンピュータ・ストレージ・システムの制御に関する。

複数の直接アクセス・ストレージ・デバイス（ＤＡＳＤ）にまたがってデータセットの容量、可用性、および性能をスケーリングする必要性が、１９８０年代初めの、ＲＡＩＤ（Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ（またはＩｎｄｅｐｅｎｄｅｎｔ） Ｄｉｓｋ）技術の開発、およびＲＡＩＤベースの論理ディスク抽象化を提供するストレージ・コントローラの実装につながった。これらのストレージ・コントローラは、通常、周辺Ｉ／Ｏ相互接続を介して多数のＤＡＳＤに接続されたコンピュータ・サーバである。これらは、ＤＡＳＤのグループを組み合わせることによってＲＡＩＤアレイを形成し、その後、これらのＲＡＩＤアレイにわたって論理ディスク抽象化を作成およびエクスポートする。ＲＡＩＤ技術は、複数のＤＡＳＤにまたがってデータを複製すること、および、障害時に失われたデータを予備ＤＡＳＤ上でトランスペアレント（透過性）に再構築することにより、ＤＡＳＤ障害によるデータ損失を防止する。（コストに直接影響を与える）ストレージ・コントローラ全体の望ましい可用性の程度に応じて、ストレージ・ベンダは、ストレージ・コントローラを設計する際に使用される構成要素の信頼性および冗長性に関するいくつかのオプションを有する。ストレージ・コントローラによって提供される全体の可用性レベルにとっては、ハードウェア構成要素の信頼性に加えて、障害回復アクションを実施するソフトウェアの品質が重要である。ＲＡＩＤ技術は、格納データセットの可用性、潜在的には性能を向上させるために、データ冗長性を使用するための多くの手法のうちの１つである。データ冗長性は、複数の形を取ることができる。実施の際の抽象化のレベルに応じて、ブロック・レベル冗長性とボリューム・レベル冗長性とを区別することができる。ブロック・レベル冗長性は、ブロック・ミラーリング（ＲＡＩＤレベル５）、パリティ・ベース保護（ＲＡＩＤレベル１０）、または消去コーディングなどの技法を使用して実行可能である。２００４年３月カリフォルニア州サンフランシスコでの０４年度ネットワーク化システムの設計および実施に関するＵＳＥＮＩＸ会議の議事録におけるＲ．Ｂｈａｇｗａｎ等による「Ｔｏｔａｌ Ｒｅｃａｌｌ：Ｓｙｓｔｅｍ Ｓｕｐｐｏｒｔ ｆｏｒ Ａｕｔｏｍａｔｅｄ Ａｖａｉｌａｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ」を参照されたい。

ブロック・レベル冗長性は、ストレージ・ボリューム抽象化の下で動作するため、その抽象化の上に階層化されたシステム・ソフトウェアに対してトランスペアレントである。これに対して、ストレージ・ボリュームの１つまたは複数の正確な複製を維持することを含むボリューム・レベルの複製は、ストレージ・ボリューム抽象化の上に階層化されたシステム・ソフトウェアによって可視である（したがって管理されなければならない）。ボリューム・レベルの複製を実行するための既知の技術には、インターナショナル・ビジネス・マシンズ・コーポレーション社からの、大容量データ・ストレージの分野で使用するためのデータ・ウェアハウジング用のＦｌａｓｈＣｏｐｙ（Ｒ）コンピュータ・ハードウェアおよびソフトウェア、ならびに、ピアツーピア・リモート・コピー（ＰＰＲＣ）が含まれる。

大規模データ・センタにおける手動の可用性管理は、エラーを起こしやすく高価であるため、実用的なソリューションではない。ＤＡＳＤグループ上に増加した可用性レベルを提供するためにデータ冗長性を採用する、ＲＡＩＤ（Ｄ．Ｐａｔｔｅｒｓｏｎ等による「Ａ Ｃａｓｅ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ（ＲＡＩＤ）」、ＡＣＭ ＳＩＧＭＯＤ議事録、シカゴ、１９８８年６月、を参照のこと）システムは、大抵は反応的に動作し、通常は目的指向ではない。また、単一のコントローラから複数のストレージ・コントローラのシステムへと容易に延在することができない。Ｋｅｌｌｅｒ等の「Ｔｈｅ ＣＨＡＭＰＳ Ｓｙｓｔｅｍ： Ｃｈａｎｇｅ Ｍａｎａｇｅｍｅｎｔ ｗｉｔｈ Ｐｌａｎｎｉｎｇ ａｎｄ Ｓｃｈｅｄｕｌｉｎｇ」、ＩＢＭ技術報告書２２８８２、２００３年８月２５日に記載されている、プランニングおよびスケジューリングを使用する変更管理（ＣＨＡＭＰＳ）システムは、分散システムにおける所与の変更（たとえば構成要素のソフトウェアのアップグレード）が他のシステム構成要素にどのように影響を与えるか、および、並列処理の機会を利用することによってこうした変更をどのように効率的に実行するか、に関係するものである。ＣＨＡＭＰＳは、構成要素の依存関係を追跡し、タスク・グラフ内で並列処理を活用する。ＣＨＡＭＰＳは当分野での実質的な進歩を表す一方で、サービス可用性の考慮に関して、および分散ストレージ・システムにおけるデータ可用性に関しては、限界がある場合がある。

複数の異種（ｈｅｔｅｒｏｇｅｎｅｏｕｓ）ストレージ・コントローラを含む環境では、自動化可用性管理システムに関するこれまでの研究はほとんどない。階層ＲＡＩＤ（ＨｉＲＡＩＤ）システム（２００１年８月の分散コンピューティング原理に関する第２０回ＡＣＭシンポジウム（ＰＯＤＣ ２００１）議事録におけるＳ．Ｈ．Ｂａｅｋ等の「Ｒｅｌｉａｂｉｌｉｔｙ ａｎｄ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ Ｈｉｅｒａｒｃｈｉｃａｌ ＲＡＩＤ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｃｏｎｔｒｏｌｌｅｒｓ」を参照）では、ＲＡＩＤコントローラ上でのＲＡＩＤ抽象化の階層化、および、ＲＡＩＤ技法を使用した単なる障害のマスキングによる変更の処理を提案している。ＨｉＲＡＩＤは、最適な目的指向ではない可能性があり、ＤＡＳＤ障害にのみ（すなわち、あたかもすべてのストレージ・コントローラに接続されたＤＡＳＤが、単一のＤＡＳＤプールの一部であるかのように）焦点を合わせている可能性がある。これは、ストレージ・コントローラ自体の追加の複雑性および異種性を考慮していない可能性があり、したがって何らかの環境では適切でない可能性がある。

他の手法も、ストレージ・コントローラの可用性を適切に特徴付けていない可能性がある。たとえば、トータルリコール（Total Recall）（２００４年３月、カリフォルニア州サンフランシスコでの０４年度ネットワーク化システムの設計および実施に関するＵＳＥＮＩＸ会議の声明におけるＲ．Ｂｈａｇｗａｎ等による「Ｔｏｔａｌ Ｒｅｃａｌｌ：Ｓｙｓｔｅｍ Ｓｕｐｐｏｒｔ ｆｏｒ Ａｕｔｏｍａｔｅｄ Ａｖａｉｌａｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ」を参照のこと）は、単なる過去の動作に基づいてピアツーピア・ストレージ・ノード可用性を特徴付け、すべてのノードをそれらの可用性プロファイルに関して同一として扱うため、エンタープライズ環境および一般に異種のストレージ・コントローラではなく、単純なストレージ・ノード（たとえばデスクトップＰＣ）および大規模な「チャーン（churn）」、すなわち、いつでもサービスから出たりサービスに戻ったりしている多数のノードによって特徴付けられるインターネット環境に、より適切である。他の関係手法では、アーカイブ・リポジトリの設計に決定分析理論を適用する。Ａ．ＣｒｅｓｐｏおよびＨ．Ｇａｒｃｉａ−Ｍｏｌｉｎａによる、「Ｃｏｓｔ−Ｄｒｉｖｅｎ Ｄｅｓｉｇｎ ｆｏｒ Ａｒｃｈｉｖａｌ Ｒｅｐｏｓｉｔｏｒｉｅｓ」、デジタル・ライブラリに関する第１回ＡＣＭ／ＩＥＥＥ−ＣＳ合同会議議事録、バージニア州ロアノーク、２００１年を、参照されたい。これは、いくつかの可能な構成間で代替を評価するため、ならびに、信頼性およびコストに関して最良の代替を選択するための、シミュレーション・ベースの設計フレームワークである。しかしながら、このフレームワーク内でのこれまでの研究は、大規模ストレージ・システムにおける異種性および複雑性の問題、ならびにストレージ・コントローラ・セットへのストレージ・ボリュームの配置の問題に対処していない。

ＩＢＭのＶｏｌｕｍｅ Ｐｅｒｆｏｒｍａｎｃｅ Ａｄｖｉｓｏｒ（ＶＰＡ）などの既存の提供システムは、主にボリューム割り振りを推奨する場合に、容量および性能に関する考慮すべき点を重視している。ＶＰＡは当分野での実質的な進歩を表しているが、可用性のための適切な措置は有していない可能性がある。
２００４年３月、カリフォルニア州サンフランシスコでの０４年度ネットワーク化システムの設計および実施に関するＵＳＥＮＩＸ会議の議事録におけるＲ．Ｂｈａｇｗａｎ等による「Ｔｏｔａｌ Ｒｅｃａｌｌ：Ｓｙｓｔｅｍ Ｓｕｐｐｏｒｔ ｆｏｒ Ａｕｔｏｍａｔｅｄ Ａｖａｉｌａｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ」 Ｄ．Ｐａｔｔｅｒｓｏｎ等による「Ａ Ｃａｓｅ ｆｏｒ Ｒｅｄｕｎｄａｎｔ Ａｒｒａｙｓ ｏｆ Ｉｎｅｘｐｅｎｓｉｖｅ Ｄｉｓｋｓ（ＲＡＩＤ）」、ＡＣＭ ＳＩＧＭＯＤ議事録、シカゴ、１９８８年６月 Ｋｅｌｌｅｒ等の「Ｔｈｅ ＣＨＡＭＰＳ Ｓｙｓｔｅｍ： Ｃｈａｎｇｅ Ｍａｎａｇｅｍｅｎｔ ｗｉｔｈ Ｐｌａｎｎｉｎｇ ａｎｄ Ｓｃｈｅｄｕｌｉｎｇ」、ＩＢＭ技術報告書２２８８２、２００３年８月２５日 ２００１年８月の分散コンピューティング原理に関する第２０回ＡＣＭシンポジウム（ＰＯＤＣ ２００１）議事録におけるＳ．Ｈ．Ｂａｅｋ等の「Ｒｅｌｉａｂｉｌｉｔｙ ａｎｄ Ｐｅｒｆｏｒｍａｎｃｅ ｏｆ Ｈｉｅｒａｒｃｈｉｃａｌ ＲＡＩＤ ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ｃｏｎｔｒｏｌｌｅｒｓ」 Ａ．ＣｒｅｓｐｏおよびＨ．Ｇａｒｃｉａ−Ｍｏｌｉｎａによる、「Ｃｏｓｔ−Ｄｒｉｖｅｎ Ｄｅｓｉｇｎ ｆｏｒ Ａｒｃｈｉｖａｌ Ｒｅｐｏｓｉｔｏｒｉｅｓ」、デジタル・ライブラリに関する第１回ＡＣＭ／ＩＥＥＥ−ＣＳ合同会議議事録、バージニア州ロアノーク、２００１年 １９８７年６月の、信頼性および分散データベースに関する第６回国際会議の議事録における、Ｊ．Ｇｒａｙによる「Ｗｈｙ ｄｏ Ｃｏｍｐｕｔｅｒｓ Ｓｔｏｐ ａｎｄ Ｗｈａｔ Ｃａｎ Ｗｅ Ｄｏ Ａｂｏｕｔ Ｉｔ？」

したがって、前述の手法における制限を克服することが望まれる。

本発明の諸原理は、コンピュータ・ストレージ・システムを制御するための技法を提供する。一態様では、例示的方法が、システムに関連する決定論的構成要素の可用性情報を取得するステップと、システムに関連する確率的構成要素の可用性情報を取得するステップと、決定論的構成要素の可用性情報および確率的構成要素の可用性情報の両方に基づいて、可用性目標の違反（ｖｉｏｌａｔｉｏｎ）をチェックするステップと、を含む。

他の態様では、例示的方法が、変更に関する要求を取得するステップと、変更に対処するために複製に関連付けられた推定複製時間を取得するステップと、変更に関する要求を評価する際に推定複製時間を考慮に入れるステップと、を含む。この方法は、コンピュータで実施可能である。この方法は、有利に組み合わせることが可能である。

本発明の１つまたは複数の実施形態は、示された方法ステップを実行するためのコンピュータ使用可能プログラム・コードを備えたコンピュータ使用可能媒体を含む、コンピュータ・プログラムの形で実施可能である。さらに、本発明の１つまたは複数の実施形態は、メモリと、メモリに結合され、例示的方法ステップを実行するように動作可能な、少なくとも１つのプロセッサとを含む、装置の形で実施可能である。

本発明の１つまたは複数の実施形態は、たとえば、標準的な保守あるいは障害またはその両方のイベントに直面するエンタープライズ・データ・センタにおける可用性および性能目標の自動管理、ＩＴインフラストラクチャ・ライフサイクル管理の標準部分であるストレージの統合およびマイグレーション活動の自動管理、などの、１つまたは複数の有利な技術的効果を提供することができる。

本発明のこれらおよび他の目的、特徴、および利点は、添付の図面と共にその例示的実施形態の以下の詳細な説明を読むことから明らかとなろう。

図１は、本発明の態様に従った、コンピュータ・ストレージ・システムを制御するための例示的方法ステップを備える流れ図１００を示す。この方法はコンピュータが実施可能である。ステップ１０２は、たとえば、変更の要求ＲＦＣに関連付けられたカレンダ時間ｔおよび期間Ｄｔなどの、システムに関連する決定論的構成要素の可用性情報（ａｖａｉｌａｂｉｌｉｔｙ ｉｎｆｏｒｍａｔｉｏｎ）を取得することを含む。変更の要求ＲＦＣ（ｔ、Ｄｔ）は、ダウンタイム・スケジュールに追加することができる。ステップ１０４は、たとえば、推定コントローラ障害確率などの、システムに関連する確率的構成要素の可用性情報を取得することを含む。意思決定ブロック１０６では、決定論的構成要素の可用性情報および確率的構成要素の可用性情報の両方に基づいて、可用性目標の違反（ｖｉｏｌａｔｉｏｎ）に関するチェックが実行される。

ブロック１０６の「ＮＯ」分岐で示されるように、追加のステップには、可用性目標の違反がないことを示すブロック１０６のチェックに応答して、現在の状況を維持することが含まれる。ブロック１０６の「ＹＥＳ」分岐の場合、追加ステップ１０８には、可用性目標の違反を示すブロック１０６のチェックに応答して、複製パラメータを決定することが含まれる。複製パラメータは、少なくともどのように複製するかおよびどこに複製するかを含むことができる。

図に示されるように、システムに関連する決定論的構成要素の可用性情報を取得することは、変更の要求を取得することを含むことができる。ステップ１１０は、推定複製時間を取得することを含むことができる。意思決定ブロック１１２を使用して、変更の要求を評価する際に推定複製時間を考慮に入れることができる。具体的に言えば、ブロック１１２では、変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定することができる。ブロック１１４では、当該判定ステップが十分な時間が使用可能でないことを示すことに応答して、変更の要求を拒否すること、あるいは変更の要求に対処するための代替プランを検索すること、またはその両方が実行可能である。

ブロック１１６では、判定ステップ１１２が実際に十分な時間が使用可能であることを示すことに応答して、変更プランを作成することができる。この変更プランは、たとえば（ｉ）複製の場所、関係、およびタイミングを示す準備情報、（ｉｉ）複製の性能を示す実行情報、（ｉｉｉ）変更の要求に関連付けられたアクションの時間までに、必要なフェイルオーバ・アクションをどのように実行するかを示す、フェイルオーバ検出情報、（ｉｖ）複製関係の保守と破棄を示す完了情報、および、（ｖ）変更の要求に関連付けられた他のアクションの時間よりも後に、必要なフェイルバック・アクションをどのように実行するかを示す情報、のうちの１つまたは複数を含むことができる。

たとえば、（ｉｉｉ）に関して、このプランは、障害または保守アクションに先立って、またはその時点で、必要なフェイルオーバ・アクション、すなわち、機能しているストレージ・コントローラ上でのオリジナルのストレージ・ボリュームからそれらの複製への切り替えを、どのように実行するかの詳細を提供することができる。（ｖ）に関して、このプランは、保守アクションの回復または完了の時点で、またはその後に、必要なフェイルバック・アクション、すなわち、複製からオリジナル・ボリュームへの切り替えを、どのように実行するかの詳細を提供することができる。

複製時間を考慮に入れるという概念は、確率的情報および決定論的情報の両方を使用する概念とは別に、またはそれらと共に、実施することが可能である。したがって、１つまたは複数の例示的実施形態では、発明の方法は、ブロック１０２のような変更の要求を取得するステップと、ブロック１１０のような変更に対処するために複製に関連付けられた推定複製時間を取得するステップと、変更の要求を評価する際に推定複製時間を考慮に入れるステップとを含むことができる。後者は、たとえばステップ１１２、１１４、および１１６のうちの１つまたは複数を含むことができる。本発明では、その要件（容量、または性能、または可用性のうちの、いずれかに関して）が個々のストレージ・コントローラの機能を超えるため、複数のストレージ・コントローラにわたって拡張（ｓｐｒｅａｄ）させなければならないデータセットに、焦点を合わせている。

複数のストレージ・コントローラを備えるストレージ・システム（しばしば「スケール・アウト」と呼ばれるアーキテクチャ）では、ストレージ・コントローラのダウンタイムに直面した場合、所望なデータセット可用性レベルを維持する問題に直面することを理解されよう。ダウンタイムは、スケジューリングされた保守アクション、あるいは１つまたは複数のストレージ・コントローラの予期せぬ障害の、いずれかによって、引き起こされる可能性がある。ＲＡＩＤ技術の利点が、複数のＤＡＳＤのグループから複数のストレージ・コントローラのグループへと簡単に拡張できない理由の１つは、ストレージ・コントローラが、個々のＤＡＳＤよりもかなり複雑なデバイスであり、一般に、ＤＡＳＤに比べてより頻繁に、および（構成要素の障害に加えて）より多様な理由で、ダウンタイムを示す傾向があることであって、個々のストレージ・コントローラの複雑性に加えて、データ・センタ内のストレージ・コントローラのグループは、通常、ＲＡＩＤアレイ内のＤＡＳＤグループよりも異種性がある。この複雑性および異種性の程度を考えると、所与のデータセットに対して正しいデータ複製の量を決定すること（どれだけのデータ複製を作成するか、およびそれらをどのストレージ・コントローラに配置するか）、ならびに、ストレージ・コントローラの非可用性にどのように反応するか、の問題は、これらの要素（すなわちストレージ・コントローラの複雑性、異種性）を考慮に入れるプロセスにおいて、１つまたは複数の発明の実施形態によって、効果的に対処することができる。

本発明の１つまたは複数の実施形態は、静的（確率的）方法および決定論的方法の組み合わせを使用して、個々のストレージ・コントローラの可用性を動的および継続的に決定することによって、データセットの可用性レベルを維持するための、事前対応型（ｐｒｏａｃｔｉｖｅ）ソリューションを提供することができる。個々のコントローラのこうした可用性特徴を考えると、１つまたは複数の例示的発明方法は、可能性のある、または予想される変更の影響を定期的に分析し、データセットの可用性目標を維持するための変更プランを考案することができる。これは通常、ＲＡＩＤなどの既存の反応型（ｒｅａｔｉｖｅ）高可用性システムと競合することなく、実施することが可能であり、実際に、１つまたは複数の発明実施形態は、通常は個々のストレージ・コントローラ内で動作するこれらのシステムと共存し、これらのシステムを活用することができる。

発明の１つまたは複数の実施形態で使用される確率的方法は、コントローラ可用性の過去の観察（たとえば、各コントローラがどれだけおよびどのタイプの非可用性インターバルを過去に経験したか）、オペレータの確信（たとえばオペレータが、コントローラはファームウェアのアップグレードを経験した直後の審査期間中に攻撃を受けやすいと確信すること）、ならびに、将来の可用性の確率的推定を考案する際のストレージ・コントローラ構成の状態（たとえば、アクティブＤＡＳＤ障害をマスキングするためにどれだけのスタンバイあるいはホット・スペアまたはその両方のＤＡＳＤが現在使用可能であるか、コントローラ・システム・ボードとＤＡＳＤアレイとの間でどれだけの冗長ストレージ・コントローラ・システム・ボードおよび内部データ・パスが適所に配置されているか）を、考慮に入れることが可能である。

発明の１つまたは複数の実施形態で使用される決定論的方法は、前述のＲＦＣを介してシステム・オペレータあるいは管理者またはその両方によってサブミット（実行）可能な、スケジューリングされたストレージ・コントローラ保守アクションなどの、今後発生する変更に関する正確な情報を考慮に入れる。

発明の１つまたは複数の実施形態は、決定論的方法および確率的方法によって推定されたコントローラ可用性測度を組み合わせること、ならびに、ボリューム配置プラン（すなわち、どれだけの複製を作成するか、およびそれらをどのコントローラに配置するか）、および変更管理プラン（すなわち、コントローラがサービスから出るかまたはサービスに戻ることへの応答として、どのタイプのフェイルオーバおよびフェイルバックのアクションを呼び出すか）を考案することが、可能である。

さらに図１を参照すると、「どのように／どこに複製するかを決定する」ブロック１０８および「変更プランを出力する」ブロック１１６が、システム管理者あるいはマネージャまたはその両方にとって重要であることを理解されよう。「ＲＦＣを追加する」ブロック１０２および「コントローラ障害確率を推定する」ブロック１０４は、トリガとみなすことができる。１つまたは複数の発明実施形態は、実行可能な配置および変更プランを考案することができる。

例示的実施形態では、データセットが、複数のストレージ・コントローラにわたって拡張されたストレージ・ボリュームＶＧ＝｛ｖ_１，ｖ_２， ．．．，ｖ_ｎ｝の集合として実施されるものと想定することができる。データセットは、潜在的に、１つまたは複数のホスト・サーバにアクセス可能であり、これらのサーバ上にインストールされたアプリケーションによって使用され得る。

データセットの所望な可用性レベルは、考慮の対象となる合計時間量全体にわたる、予測される「アップタイム（uptime、実行可能時間）」（すなわち、データセットがホスト・サーバ上のアプリケーションにアクセス可能であるか、またはアクセス可能であると予測される時間）の割合として表すことができる。データセットは、ＶＧの集合内の少なくとも１つのストレージ・ボリュームが使用不可能な場合、使用不可能（すなわちアプリケーションにアクセス不可能）であるとみなされる。たとえば、Ｔが現在時刻であり、Δｔ＝ｔ−Ｔが、データセットが時間Δｔ_{ｏｕｔａｇｅ}の間使用不可能な今後の時間間隔（たとえば、日、月、または年）である場合、データセットの可用性は、以下のように定義される。

この説明では、データセット可用性は百分率として測定され、たとえば、１ヶ月の期間にわたって９９．９９％または０．９９９９の可用性（その他の方法では「フォーナイン（four 9s）」と呼ばれる）は、最大許容ダウンタイムが約５分を超えることはできないことを意味する。上式における停止（outage）は、ストレージ・コントローラによって引き起こされる可能性があり、これは予想されている場合またはされていない場合がある。予想ダウンタイムは、スケジューリングされた保守動作によって引き起こされる可能性がある。非予想ダウンタイムは、通常、ハードウェアまたはソフトウェア構成要素の障害によって、またはオペレータのエラーによって引き起こされる。１つまたは複数の発明方法は、決定論的および確率的な計算に基づいて、個々のストレージ・コントローラの可用性の連続的特徴付けに依拠することができる。

決定論的ストレージ・コントローラ可用性の推定
決定論的計算では、発明の１つまたは複数の実施形態は、以下のように、時間ｔ_ｉおよび期間Δｔ_ｉでの将来のダウンタイムに関する正確な情報を使用して、平均保守間隔（ＭＴＢＭ）および平均ダウンタイム（ＭＤＴ）測定値の推定に基づいて、データセットの動作可用性（記号Ａ_ｄで表される）を計算する。

確率的ストレージ・コントローラ可用性の推定
確率的計算では、発明の１つまたは複数の実施形態は、以下のような情報を組み合わせる。
ａ．コントローラの過去の動作の統計的特徴付け（すなわち、コントローラの過去のアップタイムを今後予測されるアップタイムの指示として使用すること）。この推定は、以下では記号μ_αによって表される。
ｂ．ストレージ・コントローラの可用性特徴付け。しかしながらこの特徴付けは、（ｉ）いくつかの障害を維持するためのストレージ・コントローラの現在の構成の能力（たとえば、どれだけの予備ＤＡＳＤが現在適所に配置されており、アクティブＤＡＳＤ障害をマスキングするために使用可能あるいはテストされている、またはその両方であるか）、（ｉｉ）コントローラ・ソフトウェアの可用性動作（たとえば、フェイルオーバ・アクションを処理する場合に、コントローラの機能を低下させる性能動作）、（ｉｉｉ）コントローラ内の動作冗長データ・パスの数、（ｉｖ）コントローラと、そのコントローラ上のデータにアクセスしているホストとの間の動作冗長データ・パスの数などの、様々な要素を含むことができる。発明の１つまたは複数の実施形態では、コントローラの可用性における確信を、ベイズの確率としてそのオペレーティング構成に応じてカプセル化する。この推定は、以下では記号μ_βによって表される。
ｃ．それに従って、コントローラがソフトウェアのアップグレード直後の期間に特に障害の攻撃を受けやすい、「幼児死亡率」効果などの経験則を考慮に入れる、コントローラの今後の可用性に関するオペレータの確信。（ｂ）と同様に、これもベイズの確率である。この推定は、以下では記号μ_γによって表される。当業者であれば、たとえば、１９８７年６月の、信頼性および分散データベースに関する第６回国際会議の議事録における、Ｊ．Ｇｒａｙによる「Ｗｈｙ ｄｏ Ｃｏｍｐｕｔｅｒｓ Ｓｔｏｐ ａｎｄ Ｗｈａｔ Ｃａｎ Ｗｅ Ｄｏ Ａｂｏｕｔ Ｉｔ？」からの幼児死亡率の概念に精通している。

コントローラが今後使用可能となる確率μは、上記（ａ）〜（ｃ）から推定することができる。コントローラ可用性のこの推定を確率計算で使用して、データセット全体の可用性に関する確率推定を導出することができる。

前述の統計／確率および決定論的情報を使用して、ストレージ・コントローラの可用性の程度を推定することができる。これらの情報源をどのように組み合わせるかに関して、複数のオプションがある。例を挙げると、オプションの１つは、決定論的推定および（ａ）〜（ｃ）の中で最低の推定を取ることである。

上式で表されるように、コントローラの可用性の推定を、使用可能な最も厳密な推定に結びつけることで、良好に作用すると予想される。

ストレージ・ボリュームの割り振りおよび配置アルゴリズム
以下では、ある種の可用性目標を達成するために、ストレージ・コントローラのセット上にストレージ・ボリュームのセットを配置するための例示的発明技法が、ボリューム・レベル複製（すなわち、各ボリュームが、ゼロまたはそれ以上の他のストレージ・コントローラ上の１つまたは複数の他のストレージ・ボリュームに、潜在的に継続して複製またはミラーリングされている）に基づいて、提示される。この実施形態によれば、ボリューム・セットＶＧ（すなわち、１次ボリュームのセット）を備えるデータセット内の各ボリュームｖ_ｉについて、ｖ_ｉは、複製セットＶＧ’のメンバである、ボリュームｖ_ｉ１、ｖ_ｉ２、などに１回または複数回複製することができる。

たとえボリュームが１回または複数回複製可能であっても、１次ボリュームを含むストレージ・コントローラが障害を発生するか、またはサービス中止となった場合、データセット上では依然として停止（すなわちデータの非アクセス可能性）の可能性があることに留意されたい。この停止は、ほとんどの場合、２次ストレージ・ボリューム複製へのフェイルオーバにかかる時間により、不可避である。この時間は、使用される複製技術および特定のストレージ・インフラストラクチャに依存する。

この実施形態で対処可能な問題の１つが、設定された可用性目標を達成するための、ストレージ・ボリュームの数（すなわち、１次ボリュームおよび複製の数）、ならびにストレージ・コントローラ上への配置の決定である。２段階手法を使用することが可能であり、（ｉ）第１段階では、容量および性能の目標のみに基づいてボリュームの初期配置が決定され、セットＶＧおよび、ＶＧにおけるボリュームとストレージ・コントローラとの間のマッピングを生成し、（ｉｉ）第２段階では、ストレージ・ボリュームはデータ可用性目標を達成するために、必要に応じて複製される。この段階の結果、セットＶＧ’ならびに、ボリューム複製とストレージ・コントローラとの間のマッピングが生じる。

初期配置段階
第１の（初期配置）段階は、単に容量および性能の考慮に基づき、周知および前述のＩＢＭ Ｖｏｌｕｍｅ Ｐｅｒｆｏｒｍａｎｃｅ Ａｄｖｉｓｏｒなどの、既知の方法を使用して、実行することができる。しかしながら、こうしたストレージ・コントローラへのボリュームの配置では、データセットに関する可用性目標を完全に満たすことができない場合があり、これが、第２の（データ複製）段階が必要となる可能性がある理由である。

データ複製段階
初期配置段階に続き、データ複製を使用して、可用性目標を達成することができる。この実施形態では、可用性目標ならびに配置を達成するために必要なデータ複製の程度（たとえば、いくつのボリュームの複製が必要であるか）、ならびに配置（たとえば、どのストレージ・コントローラがボリューム複製を配置するか）を決定する。加えて、これらの変更を実行するための実施プランが提示される。

この段階における１つの原理は、可用性目標に達するまで、ストレージ・コントローラにまたがってストレージ・ボリュームを反復的に複製することにより、全体のデータセット可用性を累進的に向上させることである。このプロセスは、いかなる複製もなしにデータセットＶＧの初期のベースライン可用性を計算することによって開始される。その後、この可用性は、可用性の低い（おそらく、ＶＧ内の任意のコントローラ間で最も低い）ストレージ・コントローラからストレージ・ボリュームを選択すること、および、全体のデータセット可用性を上昇させるためにどのコントローラでこのボリュームを複製するかを決定することによって、向上させることができる。さらに可用性は、他のボリュームを複製すること、またはあるボリュームを複数回複製することによって、向上させることもできる。（ＶＧ内のボリュームを選択し、何らかの他のコントローラ上でこれを複製することによって）セットＶＧ’を反復的に成長させることにより、最終的に可用性目標に達するまで、データセットの可用性を単調に向上させることができる。

一般に、ストレージ・ボリュームＡが与えられると、以下の基準を使用して、Ａの複製（以下では、複製はＡ’と呼ばれる）をホストする（受け入れる）ことができるコントローラの選択が実行される。第１に、コストを最小限にするために、可能であれば、可用性が同様またはより低いストレージ・コントローラであるものとする（すなわち、かなり質の高いサービスを提供するコントローラである必要はない）。コントローラの可用性は、前述の決定論的方法および確率的方法の組み合わせを使用して推定されることに留意されたい。第２に、単純な決定論的考察が、Ａ、Ａ’をホストしている２つのコントローラのスケジューリングされた停止が、いかなる時点でも重複してはならないことを示す（実施例２の図４および図５の時間線を参照のこと）。加えて、ボリュームＡ、Ａ’に関する任意の停止間には、障害後にそれらの再同期化を可能にするために、十分な時間的距離が存在しなくてはならない。２つのストレージ・ボリューム複製を同期化させるために必要な時間は、複製技術、転送される必要のあるデータの量、およびデータ転送速度を考慮に入れて推定される。

複製Ａ’をホストするための潜在的な候補となることができるストレージ・コントローラのセットが与えられた場合、この実施形態は、何らかの順序（たとえばランダムな順序）で各候補コントローラを検査し、結果として生じた（決定論的方法および確率的方法の組み合わせられた予測を使用して計算された）データセットの可用性が、所望のターゲットを達成するかどうかを判定する。以下の実施例１で実証された確率的公式の使用に加えて、全体の可用性を推定するための潜在的にさらに正確な方法は、アーカイブ・リポジトリの設計に関する前述のクレスポ基準で使用されたシミュレーション・ベースの決定分析を使用することである。こうした分析は、ストレージ・コントローラ可用性の確率的推定（前述のソース（ａ）〜（ｃ））を使用する、イベント・ベースのシミュレーションとなる。この方法の欠点は、ほぼ即時の応答が必要なオンライン・シナリオでは好適でない可能性があることである。それらのケースでは、（以下の実施例１で説明する）確率的公式を直接使用することが、より適切な可能性がある。

前述のプロセスは、最終的にセットＶＧ’、および、ストレージ・ボリュームとストレージ・コントローラとの間の関連付けられたマッピングを生成するために、データセットＶＧ内のすべてのストレージ・ボリュームに対して反復することができる。データセットの可用性目標を達成する、単発で複製されるソリューションが存在しない（すなわち、いかなるボリュームも複数の複製を有することができない）場合、代替オプションは、３つの（またはそれ以上の）コントローラ上で、何らかのボリュームが２重に（またはそれ以上）複製されるというソリューションを試行することである。

一般に、複製セット内のボリュームのうちの１つが１次として指定され、これは、セットの第１のアクティブな代表となる複製である。これは、通常、最新のダウンタイムがスケジューリングされた、コントローラ上のストレージ・ボリュームとなるように決定される。

ＶＧおよびＶＧ’からストレージ・コントローラへとボリュームを初期に配置した後、例示的方法は、オペレータによってサブミットされたストレージ・コントローラおよびＲＦＣの一番最近および最新の可用性特徴付けに鑑みて、データセットの可用性目標が維持されているかどうかを定期的にチェックする（一例については図１にさかのぼって参照のこと）。ストレージ・コントローラの可用性レベルが変更された（たとえば、何らかの構成変更によって「監視項目リスト」に入るか、またはそれに関する１つまたは複数のＲＦＣがサブミットされる）場合、（そのコントローラ上に１つまたは複数のストレージ・ボリューム複製を有する）１つまたは複数のデータセットの可用性レベルは変更されるものと予測され、したがって、新しいストレージ・ボリューム複製が作成されなければならない可能性が最も高い。

実際のところ特に興味深いケースは、そのストレージ・コントローラの「ドレイン」（すなわち、ストレージ・コントローラからのすべてのボリュームの除去）である。この場合、そのストレージ・コントローラから他のコントローラにすべてのストレージ・ボリュームを移動しなければならず、さらに複製の作成および配置を必要とする可能性がある。このケースは、前述の汎用プロセスを使用して処理することができる。しかしながら、コントローラ間でのストレージ・ボリュームのマイグレーションは、大規模ボリュームにとっては低速プロセスとなる可能性のある、データ移動を含むことに留意されたい。

管理者がＲＦＣ（ｔ、Δｔ）を伴う新しいコントローラ停止を導入したい場合、結果としてシステムへの影響がかなり低い（たとえば、より少ない複製の作成、またはより少ないデータ移動）のであれば、ＲＡＩＣによって代替時間ｔを提案することができる。オペレータ／管理者が、オリジナルのＲＦＣ仕様に固執する場合、新しい複製は、冗長データ専用にディスク・スペースを費やして、データの非可用性を防ぐために事前対応的に（ｐｒｏａｃｔｉｖｅｌｙ）構築されることになる。

コントローラが非アクセス可能状態からサービスに戻った場合、そのストレージ・ボリュームは、通常、他のコントローラ上に有する可能性のある任意の複製と再同期化されなければならない。連続的な複製および再同期化はバックグラウンドで実行可能であり、可用性に直接影響を与えないことに留意されたい。

再考してみると、前述の方法は図１の流れ図に関して視覚化することができる。提案された実施形態は、（前述のように）ストレージ・コントローラの可用性特徴に関する情報を維持し、（ａ）ストレージ・コントローラの状況における変更ＲＦＣ（ｔ、Δｔ）の要求と、（ここでＲＦＣは変更時間ｔを指定する場合または指定しない場合があるが、変更の期間Δｔに関する推定は指定しなければならない）、（ｂ）ストレージ・コントローラの可用性特徴における変更を信号送信できる他のイベントと、（その例には、ハードウェアまたはソフトウェア・コントローラの障害、オペレータのエラー、あるいは障害を維持するためのコントローラの機能に関する改訂された確信が含まれる）、を聴取（リスニング）する。

サブミットされた各コントローラＲＦＣまたはシステム状況に関する更新された情報について、この方法は、いずれかの可用性目標が違反されているかどうかをチェックする。違反されている場合、必要に応じてボリュームを複製することができる。単なる可用性ベースの推定に加えて、複製プランは、ポリシーに基づいたビジネス規則を反映すること、たとえば、重要なデータに対してより高品質なコントローラを使用することも可能である。

典型的な可用性管理プランは、準備、実行、および完了という、３つの段階を含む。これらの段階は、前述の技法によって提案されたソリューションを実施する機構を処理し、特定の展開されたインフラストラクチャで使用される複製技術に特有のものである。

準備段階は、コントローラの障害またはシャットダウンの以前に関連し、複製の作成および同期化と必要な複製関係のセットアップとを含む。

実行段階は、コントローラの障害またはシャットダウンの時点で関連し、２次複製に対するフェイルオーバ・アクションの処理を含む。この段階の目的は、ボリューム障害をマスキングすること、および生き残ったストレージ・ボリュームへデータ・アクセスをリダイレクトすることによって、データセットの可用性を再確立することである。

完了段階は、以前にサービスから出たストレージ・コントローラが回復し、サービスに戻ってきた時点で関連する。この段階は、複製関係の再開（または、陳腐化しているとみなされる場合は破棄）、ストレージ・ボリュームの再同期化、およびオプションで、回復したストレージ・ボリュームへのデータ・アクセスの「フェイルバック」を含む。

次に、確率的および決定論的の、両方の可用性計算の例を示す。これらは本来、当業者が１つまたは複数の発明の実施形態を作成および使用する際の一助とするための単なる例示的なものであり、限定的であるとみなすべきではない。

図２および図３を参照しながら、それぞれ可用性μ_Ａ、μ_Ｂ、μ_Ｃ、μ_Ｄ、μ_Ｅを備えた５つのストレージ・コントローラＡ、Ｂ、Ｃ、Ｄ、Ｅについて考えてみる。この例では、前述のボリューム割り振りおよび配置プロシージャを使用して、性能ｙ Ｉ／Ｏおよび全体可用性μを備えたｘ ＧＢサイズのデータセットを割り振っている。第１の（初期割り振り）段階では、３つのコントローラ（Ａ、Ｂ、Ｃ）に関する容量および性能の考慮に基づいて、７つのボリュームが割り振られる。初期割り振りに続いて、割り振りアルゴリズムの第２段階では、コントローラＢおよびＣからのボリューム（おそらくは、最低の可用性μ_Ｂおよびμ_Ｃを備えるコントローラ）が、コントローラＤ、Ｅで同じボリューム数に複製されるように選択される。

全体確率の推定は、確率の理論からの以下の理論に基づくものであり、任意の２つのイベントＡ、Ｂについて、ＡあるいはＢまたはその両方のいずれかが発生する確率は、以下のように与えられる。

ＡおよびＢが独立したイベントであると想定すると、以下の通りである。

ストレージ・コントローラが独立して障害を起こし、コントローラのペアは両方のコントローラが使用不可の場合に使用不可であると想定すると、以下の通りである。

上記公式（または、複製関係ならびにコントローラの数およびタイプの所与の構成に適合された、同様に導出された公式）を使用して、データセットの可用性を決定することができる。

再考してみると、図２では、データセットは（Ａ〜Ｄでラベル付けされた）５つのストレージ・コントローラにまたがって拡張可能である。各コントローラは、可用性μ_Ａ〜μ_Ｅで特徴付けられる。データセットは、初期には３つのストレージ・コントローラ（Ａ、Ｂ、およびＣ）にまたがって拡張する、７つのストレージ・ボリュームを備え、この初期割り振りは、容量（ｘ ＧＢ）および性能（たとえばｙ ＩＯ／秒）目標に基づき、ＶＰＡなどの既知の技法を使用して決定される。データセットの可用性目標（μ）は、本明細書で説明したように満たすことができる。結果として生じる可用性目標（μ）を満たす配置が、図３に示される。

図４および５を参照しながら、異なる可用性目標（上から下へ、０．９９９９、０．９９９、および０．９）を備えた３つのデータセットについて考えてみる。既知の予測される停止の時間線（時刻表）で表され、それぞれが異なる可用性見通しを備えた７つのコントローラ（ＳＣ１〜ＳＣ７）も考えてみる。図４の時間線は、各コントローラについて既知の予測される停止を記述している。最初の６つのコントローラについては、ほぼ決定論的情報を使用する。最後のコントローラ（ＳＣ７）は、既知の停止（ｏｕｔａｇｅ、障害）はなく、最近のファームウェアのアップグレードによって疑わしいとみなされる。したがって、その確率的可用性推定は低い。

前述の例のように、アルゴリズムの第１の（初期割り振り）段階では、各データセットのボリュームが、容量および性能目標に基づいてストレージ・コントローラに割り当てられる。第１のデータセットの場合、単一のボリューム（Ａ）がＳＣ１で割り振られる。第２のデータセットの場合、３つのボリューム（Ｂ、Ｃ、およびＤ）がＳＣ３〜ＳＣ５で割り振られる。最後に、第３のデータセットの場合、単一のボリューム（Ｅ）がＳＣ７で割り振られる。

この例では、その可用性が全体データセットの可用性目標にできる限り近いストレージ・コントローラ上で初期割り振りを実行するように試行するために、初期段階で追加の作業が実行される。たとえばボリュームＡは、最高の可用性を備えるコントローラ（ＳＣ１）に割り当てられるが、それは、そのコントローラがデータセットの可用性目標に最も近く近似する（ただし、わずかに少ない）ためである。

初期割り振りが完了すると、アルゴリズムの第２段階では、可用性目標を満たすためにボリューム割り振りを使用することに注意を向ける。第１のボリューム・グループの可用性目標がかなり野心的（ambitious）である（１ヶ月にわたって４つの９とは、同じ時間間隔にわたって約４〜５分のみの停止を示唆する）ことから見て、ストレージ・ボリュームＡは他の高可用性コントローラ上で複製しなければならない。したがってこの技法は、Ａの複製であるＡ’をホストするために、ストレージ・コントローラＳＣ２を選択する。同様に、第２のデータセットについて、アルゴリズムは、それぞれボリュームＢ、Ｃ、およびＤを（Ｂ’、Ｃ’、およびＤ’に）複製することによって、そのデータセットの可用性を累進的に向上させるために、ストレージ・コントローラＳＣ４、ＳＣ３、およびＳＣ６を選択する。最後にアルゴリズムは、ＳＣ７上でボリュームＥを複製するため、および第３のデータセットの可用性目標に達するために、ＳＣ５を選択する。

再考してみると、図４では、可用性目標の異なる３つのボリューム・グループがある（ストレージ・ボリュームＡを含むＶＧの場合はμ＝０．９９９９、Ｂ、Ｃ、およびＤを含むＶＧの場合はμ＝０．９９９、ボリュームＥを含むＶＧの場合はμ＝０．９）。これらのボリュームは、可用性の順にリスト表示された７コントローラのうちの任意のサブセット上に配置されなければならない。各時間線は、各コントローラの停止を示す。第１に、可用性目標にできる限り近づくように試行しながら、容量および性能目標に基づいてストレージ・コントローラにボリュームを割り当てる。１ヶ月にわたるフォーナイン（４つの９）とは、約４〜５分のみの停止を示唆する。動作可用性が最高のコントローラがこの種のサービスを提供できないため、ストレージ・ボリュームは２つのこうしたコントローラ上で複製されなければならない。複製用のコントローラを選択する場合、コストを最小限にするために、同様の可用性を備えたコントローラでなければならない。停止は重複してはならず、再同期化されるボリュームの停止間には、十分な間隔がなければならない。ボリュームが同期を外れ、次に１次となるようにスケジューリングされた場合、同期化されなければならない。図５では、準備されたボリューム（たとえばＡ’）は、２次複製を指定する。１次ボリュームは、その第１の障害を他よりも後に有することになるコントローラ上にあるものとし、ＲＡＩＣは、Ａが同期して戻ってこられるように、Ａがサービスに戻ってきた時点からＡ’が消滅する時点までの間に十分な時間があることを保証しなければならない。典型的には、動作可用性に影響を与える唯一の停止時間は、Ａ’からＡまでのフェイルオーバ時間である。通常、その他はすべてバックグラウンドで実行可能であるため、可用性に影響を与えない。

本発明を実施するために、専用ハードウェア、汎用プロセッサ、ファームウェア、ソフトウェア、またはそれらの組み合わせを使用する、様々な技法を採用することができる。本発明の１つまたは複数の実施形態は、示された方法ステップを実行するためのコンピュータ使用可能プログラム・コードを備えるコンピュータ使用可能メディアを含むコンピュータ・プログラムの形で実施可能である。さらに本発明の１つまたは複数の実施形態は、メモリと、メモリに結合され、例示的方法ステップを実行するように動作可能な、少なくとも１つのプロセッサとを含む形で、実施可能である。

現時点では、１つまたは複数の実施形態は、事実上、汎用コンピュータまたはワークステーション上で実行するソフトウェアを使用することになると考えられている。図６を参照すると、こうした実施は、たとえばプロセッサ６０２、メモリ６０４、ならびに、たとえばディスプレイ６０６およびキーボード６０８によって形成される入力／出力インターフェースを採用することができる。本明細書で使用される「プロセッサ」という用語は、たとえば、ＣＰＵ（中央処理ユニット）あるいは他の形の処理回路またはその両方を含むものなどの、任意の処理デバイスを含むことが意図される。さらに、「プロセッサ」という用語は、複数の個々のプロセッサを言い表すこともできる。「メモリ」という用語は、たとえばＲＡＭ（ランダム・アクセス・メモリ）、ＲＯＭ（読み取り専用メモリ）、固定メモリ・デバイス（たとえばハード・ドライブ）、取り外し可能メモリ・デバイス（たとえばディスケット）、フラッシュメモリなどの、プロセッサまたはＣＰＵに関連付けられたメモリを含むことが意図される。加えて、本明細書で使用される「入力／出力インターフェース」という語句は、たとえば、処理ユニットにデータを入力するための１つまたは複数の機構（たとえばマウス）、および、処理ユニットに関連付けられた結果を提供するための１つまたは複数の機構（たとえばプリンタ）を含むことが意図される。プロセッサ６０２、メモリ６０４、ならびに、ディスプレイ６０６およびキーボード６０８などの入力／出力インターフェースは、たとえば、データ処理ユニット６１２の一部としてのバス６１０を介して相互接続することができる。たとえばバス６１０を介した好適な相互接続は、コンピュータ・ネットワークとインターフェースするために提供可能なネットワーク・カードなどのネットワーク・インターフェース６１４に、および、メディア６１８とインターフェースするために提供可能なディスケットまたはＣＤ−ＲＯＭドライブなどのメディア・インターフェース６１６に、提供することもできる。

したがって、本明細書で説明された本発明の方法論を実行するための命令またはコードを含むコンピュータ・ソフトウェアは、関連付けられたメモリ・デバイス（たとえばＲＯＭ、固定または取り外し可能メモリ）のうちの１つまたは複数に格納可能であり、使用準備ができた場合、部分的または全体が（たとえばＲＡＭ内に）ロードされ、ＣＰＵによって実行されることが可能である。こうしたソフトウェアは、ファームウェア、常駐ソフトウェア、マイクロコードなどを含むことができるが、これらに限定されることはない。

さらに本発明は、コンピュータまたは任意の命令実行システムによって、あるいはこれらに関連して使用するための、プログラム・コードを提供する、コンピュータ使用可能またはコンピュータ読み取り可能メディア（たとえばメディア６１８）からアクセス可能な、コンピュータ・プログラムの形を取ることができる。この説明では、コンピュータ使用可能またはコンピュータ読み取り可能メディアは、命令実行システム、装置、またはデバイスによって、あるいはこれらに関連して使用するための、任意の装置とすることができる。

メディアは、電子、磁気、光、電磁、赤外線、または半導体のシステム（あるいは装置またはデバイス）、あるいは伝播媒体とすることができる。コンピュータ読み取り可能媒体の例には、半導体またはソリッドステート・メモリ（たとえばメモリ６０４）、磁気テープ、取り外し可能コンピュータ・ディスケット（たとえばメディア６１８）、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛体磁気ディスク、および光ディスクが含まれる。光ディスクの現行の例には、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、コンパクト・ディスク読み取り／書き込み（ＣＤ−Ｒ／Ｗ）、およびＤＶＤが含まれる。

プログラム・コードを格納する、あるいは実行する、またはその両方に好適な、データ処理システムは、システム・バス６１０を介してメモリ要素６０４に直接または間接的に結合された、少なくとも１つのプロセッサ６０２を含むことになる。メモリ要素は、プログラム・コードの実際の実行時に採用されるローカル・メモリ、大容量ストレージ、および、実行時に大容量ストレージからコードを取り出さなければならない回数を減らすために、少なくとも一部のプログラム・コードの一時ストレージを提供するキャッシュ・メモリを、含むことができる。

入力／出力またはＩ／Ｏデバイス（キーボード６０８、ディスプレイ６０６、ポインティング・デバイスなどを含むが、これらに限定されない）は、直接（バス６１０を介するなど）、または介在するＩ／Ｏコントローラ（明瞭にするために省略）を介して、システムに結合することができる。

ネットワーク・インターフェース６１４などのネットワーク・アダプタは、データ処理システムが、介在する専用または公衆のネットワークを介して、他のデータ処理システムまたはリモート・プリンタまたはストレージ・デバイスに結合されることを可能にするために、システムに結合することもできる。モデム、ケーブル・モデム、およびイーサネット（登録商標）・カードは、現在使用可能なネットワーク・アダプタのタイプのうちのごく一部である。

いずれのケースでも、本明細書に示された構成要素は、たとえば、特定用途向け集積回路（ＡＳＩＣＳ）、機能回路、関連付けられたメモリを備える１つまたは複数の適切にプログラミングされた汎用デジタル・コンピュータなどの、様々な形のハードウェア、ソフトウェア、またはそれらの組み合わせで実施可能であることを理解されたい。本明細書で示された本発明の教示を考えると、関連分野の通常の技術者であれば、本発明の構成要素の他の実施が企図可能となろう。

以上、本発明の例示的実施形態について、添付の図面を参照しながら説明してきたが、本発明はそれらの精密な実施形態に限定されるものではないこと、ならびに、当業者であれば、本発明の範囲または趣旨を逸脱することなく、様々な他の変更および修正が実行可能であることを理解されよう。

本発明の態様に従った例示的方法ステップを示す流れ図である。 確率的情報に従った初期ボリューム配置の例を示す図である。 確率的情報に従った可用性に関するボリューム複製の例を示す図である。 決定論的情報に従った初期ボリューム配置の例を示す図である。 決定論的情報に従った可用性に関するボリューム複製の例を示す図である。 本発明の１つまたは複数の態様あるいは要素またはその両方を実施する際に有用でありうる、コンピュータ・システムを示す図である。

Claims (20)

1. コンピュータ・ストレージ・システムを制御するための方法であって、
   システムに関連する決定論的構成要素の可用性情報を取得するステップと、
   前記システムに関連する確率的構成要素の可用性情報を取得するステップと、
   前記決定論的構成要素の可用性情報および前記確率的構成要素の可用性情報の両方に基づいて、可用性目標の違反をチェックするステップと、
   を含む方法。
2. 前記可用性目標の違反がないことを示す前記チェックに応答して、現在の状況を維持する追加のステップをさらに含む、請求項１に記載の方法。
3. 前記可用性目標の違反を示す前記チェックに応答して、複製パラメータを決定する追加のステップをさらに含む、請求項１に記載の方法。
4. 前記複製パラメータは、少なくともどのように複製するかおよびどこに複製するかを含む、請求項３に記載の方法。
5. 前記システムに関連する前記決定論的構成要素可用性情報を取得するステップが、変更に関する要求を取得するステップを含み、推定複製時間を取得する追加のステップをさらに含む、請求項３に記載の方法。
6. 前記変更に関する要求を評価する際に前記推定複製時間を考慮に入れる追加のステップをさらに含む、請求項５に記載の方法。
7. 前記考慮に入れるステップが、
   前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するステップと、
   前記判定ステップが十分な時間が使用可能でないことを示すことに応答して、前記変更の要求を拒否するステップと、
   を含む、請求項６に記載の方法。
8. 前記考慮に入れるステップが、
   前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するステップと、
   前記判定ステップが十分な時間が使用可能でないことを示すことに応答して、前記変更の要求に対処するための代替プランを検索するステップと、
   を含む、請求項６に記載の方法。
9. 前記考慮に入れるステップが、
   前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するステップと、
   前記判定ステップが十分な時間が使用可能であることを示すことに応答して、変更プランを作成するステップと、
   を含む、請求項６に記載の方法。
10. 前記変更プランが、複製の場所、関係、およびタイミングを示す準備情報を含む、請求項９に記載の方法。
11. 前記変更プランが、
    複製の性能を示す実行情報と、
    前記変更の要求に関連付けられたアクションの時間までに、必要なフェイルオーバ・アクションをどのように実行するかを示す、フェイルオーバ検出情報と、
    をさらに含む、請求項１０に記載の方法。
12. 前記変更プランが、
    複製関係の保守および破棄を示す完了情報と、
    前記変更の要求に関連付けられた他のアクションの時間よりも後に、必要なフェイルバック・アクションをどのように実行するかを示す情報と、
    をさらに含む、請求項１１に記載の方法。
13. コンピュータ・ストレージ・システムを制御するための方法であって、
    変更に関する要求を取得するステップと、
    前記変更に対処するために複製に関連付けられた推定複製時間を取得するステップと、
    前記変更に関する要求を評価する際に前記推定複製時間を考慮に入れるステップと、
    を含む方法。
14. 前記考慮に入れるステップが、
    前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するステップと、
    前記判定ステップが十分な時間が使用可能でないことを示すことに応答して、前記変更の要求を拒否するステップと、
    を含む、請求項１３に記載の方法。
15. 前記考慮に入れるステップが、
    前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するステップと、
    前記判定ステップが十分な時間が使用可能でないことを示すことに応答して、前記変更の要求に対処するための代替プランを検索するステップと、
    を含む、請求項１３に記載の方法。
16. 前記考慮に入れるステップが、
    前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するステップと、
    前記判定ステップが十分な時間が使用可能であることを示すことに応答して、変更プランを作成するステップと、
    を含む、請求項１３に記載の方法。
17. コンピュータ・ストレージ・システムを制御するためのコンピュータ使用可能プログラム・コードを有するコンピュータ使用可能メディアを備えるコンピュータ・プログラムであって、
    前記システムに関連する決定論的構成要素の可用性情報を取得するための、コンピュータ使用可能プログラム・コードと、
    前記システムに関連する確率的構成要素の可用性情報を取得するための、コンピュータ使用可能プログラム・コードと、
    前記決定論的構成要素の可用性情報および前記確率的構成要素の可用性情報の両方に基づいて、可用性目標の違反をチェックするための、コンピュータ使用可能プログラム・コードと、
    を含む、コンピュータ・プログラム。
18. 前記システムに関連する決定論的構成要素の可用性情報を取得するための、前記コンピュータ使用可能プログラム・コードが、変更に関する要求を取得するためのコンピュータ使用可能プログラム・コードを含み、
    推定複製時間を取得するためのコンピュータ使用可能プログラム・コードと、
    前記変更に関する要求を評価する際に前記推定複製時間を考慮に入れるためのコンピュータ使用可能プログラム・コードと、
    をさらに含む、請求項１７に記載のコンピュータ・プログラム。
19. コンピュータ・ストレージ・システムを制御するためのコンピュータ使用可能プログラム・コードを有するコンピュータ使用可能メディアを備えるコンピュータ・プログラムであって、
    変更に関する要求を取得するためのコンピュータ使用可能プログラム・コードと、
    前記変更に対処するために複製に関連付けられた推定複製時間を取得するためのコンピュータ使用可能プログラム・コードと、
    前記変更に関する要求を評価する際に前記推定複製時間を考慮に入れるためのコンピュータ使用可能プログラム・コードと、
    を含む、コンピュータ・プログラム。
20. 前記推定された複製時間を考慮に入れるためのコンピュータ使用可能プログラム・コードが、
    前記変更の要求に対処するために、複製に十分な時間が使用可能であるかどうかを判定するためのコンピュータ使用可能プログラム・コードと、
    前記判定するためのコンピュータ使用可能プログラム・コードが十分な時間が使用可能でないことを示すことに応答して、前記変更の要求を拒否するためのコンピュータ使用可能プログラム・コードと、
    を含む、請求項１９に記載のコンピュータ・プログラム。

Images