(58)【調査した分野】(Int.Cl.,DB名)
前記障害のないデータセンタリソースを識別するために、前記コンポーネント再配置バックグラウンドモニタは、ネットワーク化されたコンピュータリソースコントローラによって維持されるリソースのインベントリを参照することを特徴とする請求項1に記載の方法。
【発明を実施するための形態】
【0007】
主題を、本明細書で、法定要件を満たすために、特定性を有して説明する。しかし、その説明自体は、必ずしも特許請求の範囲の範囲を限定するように意図されているとは限らない。むしろ、特許請求の範囲に記載された主題が、他の現在または将来の技術と共に、他の方法で実施されて、異なるステップ、または、本書で説明するステップに類似したステップの組み合わせを含むようにしてもよい。用語は、個々のステップの順序が明記されない限り、および、明記される場合を除いて、本明細書で開示する様々なステップ間のいかなる特定の順序を含意するようにも解釈されるべきではない。
【0008】
全体として、本発明の一実施形態は、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てすることを、対象とする。本明細書で使用される場合、「アプリケーションコンポーネント」は、データセンタリソース上で配置され、および、1つまたは複数の他のアプリケーションコンポーネントと共に実行されて、アプリケーションの所望の機能性が達成される、アプリケーションの少なくとも一部を説明する。アプリケーションコンポーネントは、「インスタンス」、「ロールインスタンス」または「アプリケーションロールインスタンス」と呼ばれることがある。「データセンタリソース」には、サーバ(「ノード」とも呼ばれる)、ディスクまたは仮想マシン(VM)など、データセンタのコンピューティングリソースが含まれる。典型的には、データセンタは、接続されて、リソースのネットワークが形成される、ある量の(例えば、数千の)個々のリソースを含む。
【0009】
アプリケーションは、そのアプリケーションがどのようにリソースのネットワークの中で配置されるべきであるかを規定する、命令(「アプリケーションモデル」または「アプリケーション配置パラメータ」とも呼ばれる)を含むことが多い。例えば、命令は、アプリケーションを、50個のロールインスタンス(すなわち、アプリケーションコンポーネント)として、各々が別々の電源を含む5個の異なるデータセンタリソース(例えば、サーバ)の中に、均等に配置(配置)することを、指示してもよい。それに応じて、10個のロールインスタンスが、5個のリソースの各々において配置されるようになる。10個のロールインスタンスの各セットを、それぞれの仮想グループ(「アップグレードドメイン」とも呼ばれる)として指定してもよい。アプリケーションモデルの可用性制約に基づいて、複数の仮想グループは、同時にアップグレードまたは移行可能としないことが多い。
【0010】
この例を続けると、5個のリソースのうち1個がエラーを起こす場合、本発明の一実施形態は、10個のアプリケーションコンポーネントを、エラーが起こったリソースから正常なリソースへ移行させる。また、10個のアプリケーションコンポーネントが、アプリケーションモデルに整合する方法で、再割り当てされる。すなわち、10個のアプリケーションコンポーネントの移行は、任意の他のアプリケーションコンポーネントの再割り当てまたは任意の他のメンテナンス動作が開始される前に完了され、それにより、仮想グループ移行要件に従う。加えて、10個のアプリケーションコンポーネントを受け入れる正常なリソース(複数可)は、その上で他の40個のアプリケーションコンポーネントが配置される4個のリソースのうち1個ではなく、それにより、5個の異なるデータセンタリソースを必要とするパラメータに従う。
【0011】
実施形態を簡単に説明したが、
図1を次に説明し、
図1では、本発明の実施形態を実施するための例示的動作環境が示され、全体としてコンピューティングデバイス100として指定される。コンピューティングデバイス100は、しかし、適切なコンピューティング環境の一例であり、本発明の実施形態の使用または機能性の範囲についてのいかなる限定を示唆するようにも意図されていない。コンピューティングデバイス100はまた、例示されたコンポーネントのいずれか1つまたは組み合わせに関係する、いかなる依存性または要件を有するように解釈されるべきでない。
【0012】
本発明の実施形態は、一般に、コンピュータ、または、パーソナルデータアシスタントもしくは他のハンドヘルドデバイスなど、他のマシンによって実行される、プログラムモジュールなど、コンピュータ実行可能命令を含む、コンピュータコードまたはマシン使用可能命令との関連で説明されうる。一般に、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含むプログラムモジュールは、特定のタスクを行うか、または、特定の抽象データ型を実装する、コードを指す。本発明の実施形態は、ハンドヘルドデバイス、消費者向け電子機器、汎用コンピュータ、より専門のコンピューティングデバイスなどを含む、様々なシステム構成で実施されてもよい。本発明の実施形態はまた、通信ネットワークを通してリンクされるリモート処理デバイスによってタスクが行われる、分散コンピューティング環境で実施されてもよい。
【0013】
本発明の実施形態は、とりわけ、方法、システム、または、1つもしくは複数のコンピュータ可読メディア上で実施された命令のセットとして、実施されてもよい。コンピュータ可読メディアは、揮発性および不揮発性メディア、リムーバブルおよびノンリムーバブルメディアを共に含み、データベース、スイッチ、および、様々な他のネットワークデバイスによって可読なメディアを企図する。例として、コンピュータ可読メディアは、情報を保存するための任意の方法または技術において実装されたメディアを含む。保存された情報の例には、コンピュータ使用可能命令、データ構造、プログラムモジュール、および、他のデータ表現が含まれる。メディアの例には、情報配信メディアに限定されないが、RAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)、ホログラフィックメディアまたは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置および他の磁気記憶装置が含まれる。これらの技術は、データを瞬間的に、一時的に、または永続的に保存することができる。
【0014】
図1を参照すると、コンピューティングデバイス100は、以下のデバイスを直接または間接的に結合するバス110を含み、これらのデバイスは、メモリ112、1つまたは複数のプロセッサ114、1つまたは複数の提示コンポーネント116、入出力ポート118、入出力コンポーネント120、および、電源装置122である。バス110は、1つまたは複数のバス(アドレスバス、データバス、または、それらの組み合わせなど)でありうる物を表す。
図1の様々なブロックを、明快にするために線で示すが、実際には、様々なコンポーネントを図で表すことは、それほど明快ではなく、比喩的には、これらの線は、より正確には、どっちつかずで不明瞭となる。例えば、ディスプレイデバイスなど、提示コンポーネントを、I/Oコンポーネントであると見なすことができる。また、プロセッサも、メモリを有する。我々は、そのようなことが当技術分野の性質であると認識し、
図1の図が、本発明の1つまたは複数の実施形態に関連して使用されうる、例示的コンピューティングデバイスを例示するのみであることを、繰り返し述べる。「ワークステーション」、「サーバ」、「ラップトップ」、「ハンドヘルドデバイス」などのようなカテゴリ間の区別は行われず、その理由は、すべてが
図1および「コンピューティングデバイス」への言及の範囲内で企図されるからである。
【0015】
コンピューティングデバイス100は典型的には、様々なコンピュータ可読メディアを含む。例として、コンピュータ可読メディアには、ランダムアクセスメモリ(RAM)、読み取り専用メモリ(ROM)、電子的消去可能プログラマブル読み取り専用メモリ(EEPROM)、フラッシュメモリもしくは他のメモリ技術、CDROM、デジタル多用途ディスク(DVD)もしくは他の光もしくはホログラフィックメディア、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、搬送波、または、所望の情報を符号化するために使用でき、コンピューティングデバイス100によってアクセス可能な、任意の他のメディアが含まれてもよい。
【0016】
メモリ112には、揮発性および/または不揮発性メモリの形態の、コンピュータ記憶メディアが含まれる。このメモリは、リムーバブル、ノンリムーバブル、または、それらの組み合わせであってもよい。例示的ハードウェアデバイスには、ソリッドステートメモリ、ハードドライブ、光ディスクドライブなどが含まれる。コンピューティングデバイス100は、メモリ112またはI/Oコンポーネント120など、様々なエンティティからデータを読み取る、1つまたは複数のプロセッサ114を含む。提示コンポーネント(複数可)116は、ユーザまたは他のデバイスに、データ指示を提示する。例示的提示コンポーネントには、ディスプレイデバイス、スピーカ、印刷コンポーネント、振動コンポーネントなどが含まれる。
【0017】
I/Oポート118は、コンピューティングデバイス100を、I/Oコンポーネント120を含む他のデバイスに論理的に結合できるようにし、I/Oコンポーネント120のうちいくつかは、組み込まれてもよい。例示的コンポーネントには、マイクロホン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、プリンタ、ワイヤレスデバイスなどが含まれる。
【0018】
次に
図2を参照すると、本発明の一実施形態を実施するために適した例示的動作環境が、全体として参照番号210によって示され、識別される。環境210は、ネットワーク化されたデータセンタコンピュータリソース212およびコントローラ214のセットを含み、コントローラ214は、リソース212の監視、維持および割り振りを行って、データセンタ内で配置されたアプリケーションをホストする。
【0019】
リソース212は、リソースA216、リソースB218、リソースC220、および、リソースD222を含む。リソースA〜Dを、例示の目的で示すが、リソース212は、省略符号224で示すように、いくつかの他のリソース(例えば、数千)を含んでもよい。
【0020】
図2では、アプリケーションは、リソースA216およびリソースB218を使用して配置されている。リソースA216は、アプリケーションロールインスタンス1 226、および、アプリケーションロールインスタンス2 228を含み、リソースB218は、アプリケーションロールインスタンス3 230、および、アプリケーションロールインスタンス4 232を含む。すなわち、アプリケーション(例えば、アプリケーションモデル250内で識別された「アプリケーション例」)が、リソースA216およびリソースB218を使用して配置されており、このアプリケーションは、少なくとも4個のロールインスタンスを含む。また、これらの4個のロールインスタンス(すなわち、226、228、230および232)は、仮想グループ(例えば、アップグレードドメイン)に分割される。例えば、仮想グループA1は、ロールインスタンス1 226、および、ロールインスタンス2 228を含み、仮想グループB1は、ロールインスタンス3 230、および、ロールインスタンス4 232を含む。4個のロールインスタンスのみを、例示の目的で
図2に示すが、アプリケーションは、他のリソースの中に配置され、より大きい、より多数の仮想グループに分割された、いくつかの他のロールインスタンスを含んでもよい。
【0021】
リソースA216およびリソースB218は、障害のある状態を示すために、影付きである。リソースは、様々な理由のために、障害のある状態を含むと見なされることがあり、リソースが、手動調査状態(例えば、HumanInvestigative(HI)状態)、または、修復状態(例えば、「OutForRepair」)である場合などである。リソース212はまた、リソースC220およびリソースD222をも含み、リソースC220およびリソースD222は共に、障害のない状態を示すために、影付きではない。また、リソースC220およびリソースD222の各々は、空のボックス236、238、240および242によって示すように、アプリケーションコンポーネント(例えば、アプリケーションロールインスタンス)を受け入れるための可用性を含む。
【0022】
コントローラ214(例えば、ファブリックコントローラ)は、互いに通信し、ならびに、ネットワーク化されたコンピュータリソースインベントリ244、アプリケーション情報データストア246、および、アプリケーションコンポーネントリアロケータ(reallocator)248を含む、様々なコンポーネントを含む。以前に示したように、コントローラ214は、リソース212の監視、維持および割り振りを行って、データセンタ内に配置されたアプリケーションをホストする。したがって、インベントリ244は、リソース212の中に含まれたすべてのリソースのリスト、ならびに、各リソースの正常性または状況の指示を含む。例えば、インベントリ244は、リソースAをリストし、リソースAが障害のある状況を含むことを指示する。すなわち、インベントリ244内にリストされた「リソースA」は、リソース212の中で示されたリソースA216に対応する。同様に、インベントリ244はまた、リソースB〜D、ならびに、それぞれの状況の指示をもリストする。
【0023】
アプリケーション情報データストア246は、リソース212を使用して配置するアプリケーションに関連する情報を保存する。データストア246内に保存された情報の例示的タイプには、アプリケーションモデル250およびアプリケーション正常性履歴252が含まれる。本明細書の例示の目的のために、データストア246内に保存された情報は、リソースA216およびリソースB218上に配置されるとして説明される、同じアプリケーションに関連する。すなわち、情報254の分解図において識別された「アプリケーション例」は、リソースA216およびリソースB218を使用して配置される。アプリケーションモデル250は、配置される場合、アプリケーション例が、2個のサーバの中で分割された4個のインスタンスを含むことになることを指示する。アプリケーション正常性履歴252は、アプリケーションがある期間の全体を通じて再割り当てされた回数または機会の数、ならびに、特定のアプリケーションコンポーネント(例えば、インスタンス)がある期間の全体を通じて再割り当てされた回数を追跡する。以下でより詳細に説明するように、そのようなメトリックスは、アプリケーションおよび/または、およびアプリケーションコンポーネントが、基になるハードウェアに対立するように、障害のある状況を引き起こしている可能性がある場合を識別するために、有用である。
【0024】
コントローラ214はまた、アプリケーションコンポーネントリアロケータ248をも含む。リアロケータ248は、様々なモニタを含み、これらのモニタは、共に機能して、障害のあるリソースを識別し、使用可能で適切な(すなわち、アプリケーションモデルに整合する)障害のないリソースを決定し、アプリケーションモデル250に従って、アプリケーションコンポーネントを、障害のあるリソースから障害のないリソースへ移行させる。
【0025】
コンポーネントリアロケータ248は、リソース状況バックグラウンドモニタ256を含み、リソース状況バックグラウンドモニタ256は、障害のある状態を含むリソース(例えば、サーバ、ディスクまたはVM)を識別する。一実施形態では、リソース状況バックグラウンドモニタ256がウェイクアップする場合、リソース状況バックグラウンドモニタ256は、インベントリ244を参照して、障害のある状況を含むリソースを識別する。例えば、リソース状況バックグラウンドモニタ256は、インベントリ244を参照して、リソースA216が障害のある状況を含むと決定してもよい。以前に説明したように、リソースA216は、アプリケーションロールインスタンス1 226、および、アプリケーションロールインスタンス2 228をホストする。リソースA216はエラーを起こしているので、アプリケーションロールインスタンス1 226、および、アプリケーションロールインスタンス2 228を再割り当てして、アプリケーション例が可用性を維持できるようにすることが望ましい。
【0026】
障害のあるリソースを識別すると、リソース状況バックグラウンドモニタ256は、サービス復旧タスク260を生成し、サービス復旧タスク260は、復旧タスクキュー262内で維持される。サービス復旧タスク260は、アプリケーションコンポーネントが、識別された障害のあるリソースから再割り当てされる必要があるという、命令を含む。例えば、
図2に示すように、サービス復旧タスク260は、アプリケーションロールインスタンス1 226がリソースAから再割り当てされる必要があるという、命令を含んでもよい。明確に示されていないが、タスク260は同様に、ロールインスタンス2 228がリソースBから再割り当てされる必要があるという、命令を含んでもよい。
【0027】
リソースは、データセンタ制御ソフトウェアアップグレードの配置におけるエラー、構成変更、または、大きいハードウェアエラーなど、グループ全体の状態(すなわち、ネットワーク全体の状態)により、障害のある状況に入る可能性がある。そのようなシナリオでは、コントローラ214の少なくともいくつかの動作を一時停止して、調査を可能にするか、または、そうでない場合、アプリケーションコンポーネントを保護することが、望ましいことがある。したがって、再割り当ては望ましくないことがあり、その理由は、再割り当てが、調査を妨げる可能性があり、障害のないノードから再割り当てする可能性があり、または、そうでない場合、アプリケーションに割り当てられたリソースの正常性を復元できない可能性があるからである。したがって、リソース状況バックグラウンドモニタ256は、グループ正常性依存ディスエイブラ(disabler)258を含む。サービス復旧タスク(例えば、260)を生成する前に、ディスエイブラ258は、リソースのグループの中の障害のあるリソースの数が、グループ正常性しきい値を超えるかどうかを判定する。グループ正常性しきい値は、構成可能であり、障害のあるリソースのしきい値数、または、障害のあるリソースと障害のないリソースの比を含んでもよい。したがって、ディスエイブラ258は、インベントリ244から、障害のあるリソースの量を決定し、その量を、グループ正常性しきい値と比較する。その量がしきい値未満である場合、リソース状況バックグラウンドモニタ256は、続行する。しかし、その量がしきい値を超える場合、リソース状況バックグラウンドモニタ256は、無効化され、それにより、復旧動作が中断される。
【0028】
アプリケーション欠陥は、リソースを障害のある状態に入らせ、アプリケーションの連続的な再割り当てが後続のリソースに悪影響を与えるようになる可能性もある。したがって、リソース状況バックグラウンドモニタ256は、アプリケーション復旧レート依存ディスエイブラ264を含む。サービス復旧タスク(例えば、260)が生成される前に、ディスエイブラ264は、アプリケーションの復旧頻度(すなわち、アプリケーションが所与の期間内に何回復旧されたか)を決定する。例えば、アプリケーション正常性履歴252が参照されて、アプリケーションがある期間内に何回復旧されたかが決定されてもよい。ディスエイブラ264は、アプリケーションの復旧頻度を、アプリケーション復旧レートしきい値と比較する。アプリケーションの復旧頻度が、アプリケーション復旧レートしきい値未満である場合、リソース状況バックグラウンドモニタ256は、続行する。しかし、アプリケーションの復旧頻度が、アプリケーション復旧レートしきい値を超える場合、ディスエイブラ264は、アプリケーションのためのさらなる復旧の試行を無効化する。加えて、アラームまたは通知が送出され、アプリケーションが調査されるべきであることが指示されてもよい。
【0029】
アプリケーション復旧レートしきい値は、様々な方法を使用して決定されてもよい。例えば、アプリケーション復旧レートしきい値は、経験に基づいて、ヒューリスティックに決定されてもよい。代替として(または、加えて)、アプリケーション復旧レートしきい値は、リソース(例えば、サーバ)が、アプリケーション欠陥によって引き起こされない、障害のある状態に入る、計算された確率に基づいてもよい。一実施形態では、計算された確率は、ポワソン分布を使用して決定される。すなわち、ポワソン分布は、あるイベント(例えば、リソースが障害のある状態に入ること)が、その最後のイベント以来の時間にかかわらず、そのイベントが既知の平均レートで発生する場合、固定された期間内で発生する確率を表す。したがって、あるアプリケーションが5個のノード上でホストされる場合、ポワソン分布が使用されて、それらの5個のノードが、独立してランダムに引き起こされる(すなわち、アプリケーション欠陥によって引き起こされない)障害のある状態に入る、頻度が示唆される。ポワソン分布によって示唆された頻度よりも多い、それらの5個のノードによるエラーは、アプリケーション欠陥がそれらのエラーを引き起こしている可能性があることを指示する。したがって、ポワソン分布頻度(Poisson distribution frequency)を、アプリケーション復旧レートしきい値として使用することができ、または、アプリケーション復旧レートしきい値を示唆するために使用することができる。
【0030】
アプリケーション欠陥が、リソースを障害のある状態に入らせることと同様に、アプリケーションコンポーネント(例えば、インスタンス)は、リソースを障害のある状態に入らせる欠陥を含むことがある。したがって、リソース状況バックグラウンドモニタ256は、アプリケーション復旧レート依存ディスエイブラ264と同様に機能する、コンポーネント復旧レート依存ディスエイブラ266を含む。すなわち、サービス復旧タスク(例えば、260)が生成される前に、ディスエイブラ266は、コンポーネントの復旧頻度(すなわち、コンポーネントが所与の期間内に何回復旧されたか)を決定する。例えば、アプリケーション正常性履歴252が参照されて、コンポーネントがある期間内に何回復旧されたかが決定されてもよい。ディスエイブラ266は、コンポーネントの復旧頻度を、コンポーネント復旧レートしきい値と比較する。コンポーネントの復旧頻度が、コンポーネント復旧レートしきい値未満である場合、リソース状況バックグラウンドモニタ256は、続行する。しかし、コンポーネントの復旧頻度が、コンポーネント復旧レートしきい値を超える場合、ディスエイブラ266は、コンポーネントのアプリケーションのためのさらなる復旧の試行を無効化する。加えて、アラームまたは通知が送出され、アプリケーションコンポーネントが調査されるべきであることが指示されてもよい。
【0031】
チェックされない場合、アプリケーションコンポーネントリアロケータ248による再割り当ては、コントローラ214のワークロードを考慮に入れることなく、多数のタスクを生成することがある。したがって、しきい値は、再割り当てセッション内で生成されるタスクの数を制限するために、確立されてもよい。すなわち、リソース状況バックグラウンドモニタ256は、部分的には、休止状態からウェイクすること、障害のあるリソースを識別すること、サービス復旧タスクを作成すること、および、休止状態へ戻ることによって、機能する。リソース状況バックグラウンドモニタ256がウェイクアップするたびに、リソース状況バックグラウンドモニタ256は、再割り当てセッションを開始する。
【0032】
したがって、コントローラ214のワークロードを管理するために、リソース状況バックグラウンドモニタ256が所与の再割り当てセッション内で再割り当て可能にされる、アプリケーションの概数に、上限が設定されてもよい。したがって、セッションごとのスロットル268は、再割り当てセッション内で再割り当て可能にされる、アプリケーションの数を制御する。セッションごとのスロットル268が、セッションごとの上限を確立する場合、リソース状況バックグラウンドモニタ256は、次のリソース境界に丸められた、ほぼ、セッションごとの上限で再割り当てするようになる。例えば、リソース状況バックグラウンドモニタ256は、ウェイクアップし、各リソースが8個のアプリケーションをホストする、障害のある3個のリソースを、識別することがある。セッションごとのスロットル268が、再割り当ての上限を10個のアプリケーションに定める場合、3個のリソースのうち2個(すなわち、16個のアプリケーション)が再割り当てされ、残りの1つのリソースは、後続のセッション内で再割り当てされる。すなわち、セッションごとの上限(例えば、10)が超えられる場合、最大で次のリソース境界までのリスト(例えば、16個のアプリケーション)が再割り当てされるようになるが、それより多くは再割り当てされないようになる。
【0033】
コンポーネント再配置バックグラウンドモニタ270は、サービス復旧タスクを使用し、アプリケーションコンポーネントが移行されうる先の障害のないリソースを識別する。例えば、サービス復旧タスク260を受け入れると、コンポーネント再配置バックグラウンドモニタ270は、インベントリ244を参照して、アプリケーションロールインスタンス1 226を受け入れるために使用可能であるリソースを識別してもよい。
【0034】
使用可能な障害のないリソースを識別することに加えて、コンポーネント再配置バックグラウンドモニタ270は、アプリケーションロールインスタンス1 226の、特定の障害のないリソースへの移行が、アプリケーションモデル250に適合することを保証する。例えば、アプリケーションモデル250は、アプリケーション例が2個のサーバを使用して配置されることになることを、規定する。したがって、単一のサーバが、アプリケーションロールインスタンス1〜4の各々をホストするために使用可能であった場合でも、コンポーネント再配置バックグラウンドモニタ270は、それらのアプリケーションコンポーネントのすべてがその単一のサーバへ再割り当てされるように、スケジュールするようにはならない。
【0035】
コンポーネント再配置バックグラウンドモニタ270が、アプリケーションコンポーネントが再割り当てされうる先の、使用可能で適切なリソースを識別した後、コンポーネント再配置バックグラウンドモニタ270は、アップグレードタスク272を生成する。例えば、アップグレードタスク272は、アプリケーションロールインスタンス1 226の、リソースC220への再割り当てを命令する。明確に示されていないが、タスク272は同様に、ロールインスタンス2 228が、使用可能で適切なリソースへ再割り当てされる必要があるという、命令を含んでもよい。アプリケーションロールインスタンス2 228に関連するアップグレードタスク(例えば、272)は、アプリケーションモデル250への適合が維持される限り、アプリケーションロールインスタンス2 228がリソースC220またはリソースD220のいずれかに移行されるべきであることを、命令してもよい。アップグレードタスクは、ローリングアップグレードタスクキュー276内で優先される。
【0036】
コンポーネント再配置モニタ270はまた、セッションごとのスロットル274をも含んでもよく、セッションごとのスロットル274は、セッションごとのスロットル268と同様に機能する。すなわち、セッションごとのスロットル274は、再割り当てセッション内で再割り当て可能なアプリケーションの数を制御する。セッションごとのスロットル274が、セッションごとの上限を確立する場合、ウェイクすると、コンポーネント再配置バックグラウンドモニタ270は、上限にほぼ等しい数のサービス復旧タスクを処理する。すなわち、コンポーネント再配置バックグラウンドモニタ270は、リソース状況バックグラウンドモニタ256と同様に、次のリソース境界に丸められた数を処理してもよい。
【0037】
ローリングアップグレードバックグラウンドモニタ278は、アップグレードタスクを使用し、アプリケーションコンポーネントの再割り当てを実行する。例えば、ローリングアップグレードバックグラウンドモニタ278は、アプリケーションロールインスタンス1 226をリソースCへ再割り当てる。一実施形態では、ローリングアップグレードバックグラウンドモニタ278は、仮想グループルールを適用する。例えば、ローリングアップグレードバックグラウンドモニタ278は、あるアプリケーションの別の仮想グループ(例えば、仮想グループB1)の移行を開始する前に、同じアプリケーションのある仮想グループ(例えば、仮想グループA1)全体が新しいリソースに移行するのを、待機してもよい。この点において、ローリングアップグレードタスクキューは、先入先出処理スキームに従わない。
【0038】
ローリングアップグレードバックグラウンドモニタ278はまた、セッションごとのスロットル280をも含んでもよく、セッションごとのスロットル280は、セッションごとのスロットル268およびセッションごとのスロットル274と同様に機能する。すなわち、セッションごとのスロットル280は、再割り当てセッション内で再割り当て可能にされる、アプリケーションの数を制御する。セッションごとのスロットル280が、セッションごとの上限を確立する場合、ウェイクすると、ローリングアップグレードバックグラウンドモニタ278は、上限にほぼ等しい数のアップグレードタスクを処理する。すなわち、ローリングアップグレードバックグラウンドモニタ278は、リソース状況バックグラウンドモニタ256およびコンポーネント再配置モニタ270と同様に、次のリソース境界に丸められた数を処理してもよい。
【0039】
図3を参照すると、本発明の一実施形態で行われる方法の概略を述べる、流れ図が示される。この方法は全体として、参照番号310によって示され、
図3を説明する場合、
図2もまた参照されることがある。この方法は、その上で実施されるコンピュータ実行可能命令を有する、1つまたは複数のコンピュータ可読メディア上で実施されてもよく、その命令は、実行される場合、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てする方法を実施する。
【0040】
方法310は、312で、その上でアプリケーションコンポーネント(例えば、インスタンス226および228)がホストされる、障害のあるデータセンタリソース(例えば、サーバ、ディスク、仮想マシン)を識別することを含む。例えば、障害のあるデータセンタリソースは、リソース状況バックグラウンドモニタがウェイクアップし、インベントリ244を参照する場合、識別される。ステップ314は、アプリケーションコンポーネントを、障害のあるデータセンタリソースから移動することを命令する、サービス復旧タスク(例えば、260)を生成することを含む。例えば、障害のあるデータセンタリソースを識別した後、リソース状況バックグラウンドモニタ256は、サービス復旧タスクを生成してもよい。
【0041】
ステップ316で、方法310は、サービス復旧タスクを使用し、アプリケーションコンポーネントを受け入れるために使用可能な、障害のないデータセンタリソースを識別する、コンポーネント再配置バックグラウンドモニタを実行することを含む。例えば、出願人モデル250がチェックされて、アプリケーションコンポーネントを再割り当てする場合に満たされることになるパラメータが決定されてもよい。例示的パラメータは、その中でアプリケーションコンポーネントが配分されることになる、リソース(例えば、サーバ)の総数を含む。インベントリ244が参照されて、どのリソースに障害がないか、および、それらのパラメータに適合する、選択された使用可能な障害のないリソースが、決定されてもよい。
【0042】
ステップ318は、アプリケーションコンポーネントが、障害のないデータセンタリソースへ移動されることになることを命令する、ローリングアップグレードタスク(例えば、272)を生成することを含む。加えて、ステップ320は、ローリングアップグレードタスクを使用し、アプリケーションコンポーネントを障害のないデータセンタリソースへ再割り当てする、ローリングアップグレードバックグラウンドモニタを実行することを含む。以前に説明したように、方法310を実行する場合、様々なしきい値が利用されて、ワークロードが制御されてもよく(例えば、セッションごとのスロットル)、ならびに、リソースエラーが、データセンタ全体の処理(例えば、グループ正常性しきい値)またはアプリケーションエラー(例えば、アプリケーション復旧レートしきい値)の結果として生じている可能性がある場合が、検出されてもよい。
【0043】
次に
図4を参照すると、本発明の一実施形態で行われる方法の概略を述べる、別の流れ図が示される。この方法は全体として、参照番号410によって示され、
図4を説明する場合、
図2もまた参照されることがある。この方法は、その上で実施されるコンピュータ実行可能命令を有する、1つまたは複数のコンピュータ可読メディア上で実施されてもよく、その命令は、実行される場合、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てする方法を実施する。
【0044】
動作412で、方法410は、データセンタリソースのグループの中で、障害のあるデータセンタリソースを含む、そのグループの部分を決定することを含む。加えて、ステップ414は、その部分を、グループ正常性しきい値と比較することを含む。例えば、グループ正常性依存ディスエイブラ258は、障害のあるリソースの部分が高すぎないことを確認してもよく、その確認は、サービス復旧が継続する前に、ネットワーク全体の状態が考慮に入れられるべきであることを、示唆することがある。
【0045】
動作416は、その部分がグループ正常性しきい値未満である場合、その上でアプリケーションコンポーネントが配置されている障害のあるデータセンタリソースを識別することを含み、アプリケーションコンポーネントは、所与の期間内である回数の量(quantity of times)だけ再割り当てされている。また、ステップ418は、その回数の量を、別のしきい値と比較することを含む。別のしきい値には、アプリケーション復旧レートしきい値、コンポーネント復旧レートしきい値、または、アプリケーション復旧レートしきい値およびコンポーネント復旧レートしきい値の両方が含まれてもよい。例えば、アプリケーション復旧レート依存ディスエイブラ264は、その回数の量が高すぎないことを確認してもよく、その理由は、高い再割り当てレートが、アプリケーションがリソースエラーの根本原因であることを示唆するためである。さらに、動作420は、その量が別のしきい値未満である場合、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てすることを含む。
【0046】
示された様々なコンポーネントの多数の異なる配置、ならびに、図示されないコンポーネントは、以下の特許請求の範囲の範囲から逸脱することなく、可能である。本発明の実施形態を、限定的ではなく、例示的であるように意図して、説明した。代替的実施形態は、本開示を読んだ後、および、本開示を読むことにより、本開示の読者には明らかになるであろう。上記を実施する代替手段は、以下の特許請求の範囲の範囲から逸脱することなく、完成されうる。ある特徴およびサブコンビネーションは、他の特徴およびサブコンビネーションに関係なく有益であり、採用可能であり、特許請求の範囲の範囲内で企図される。