JP6132766B2 - データセンタサービスの制御された自動復旧 - Google Patents

Description

本発明は、データセンタサービスの制御された自動復旧に関する。

データセンタは、クラウドと呼ばれることがある、ネットワーク化されたコンピュータリソース（例えば、サーバ、ディスク、仮想マシンなど）からなり、これらのリソースは、ホストされたアプリケーションを配置するために活用される。そうすることで、分散アプリケーションは、基になるハードウェアの可用性よりも高い可用性のレベルを達成することができる。すなわち、場合によっては、基になるハードウェアは、アプリケーションがリソースに割り振られ、リソースを利用中である間の時間に、障害のある状態（例えば、調査または修復）に入ることがある。

したがって、アプリケーションを、障害のあるリソースから障害のないリソースへ再割り当てするために、適切な手段を有し、それにより、アプリケーションが可用性を維持できるようにすることが有用である。また、移動中でも、アプリケーションが使用可能なままであることを可能にする方法で、アプリケーションを再割り当てすることが有用である。

本発明の実施形態は、以下の特許請求の範囲によって定義され、この概要によって定義されない。本明細書で説明する主題の高レベルの概観を、そのためにここで提供して、本開示の概観を提供し、詳細な説明のセクションでさらに後述する概念の選択を紹介する。この概要は、特許請求の範囲に記載された主題の主要な特徴または必須の特徴を識別するように意図されておらず、特許請求の範囲に記載された主題の範囲を決定するための分離の助けとして使用されるようにも意図されていない。

本明細書で説明する主題は、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てすることを対象とする。バックグラウンドモニタは、障害のあるデータセンタリソースを識別し、アプリケーションコンポーネントの、障害のあるデータセンタリソースから障害のないデータセンタリソースへの移行をスケジュールする。移行は、アプリケーションが使用可能なままであることを可能にする、自動的な方法で実施される。しきい値は、移行のレートを制御するため、ならびに、リソースエラーが、データセンタ全体の処理またはアプリケーションエラーの結果として生じている可能性がある場合を検出するために、適切である。

本発明の例示的実施形態を、添付の図面を参照して詳細に後述する。
本発明の実施形態による使用のために適した、例示的コンピューティングデバイスを示すブロック図である。 本発明の一実施形態による例示的動作環境のブロック図である。 本発明の一実施形態による例示的流れ図である。 本発明の一実施形態による例示的流れ図である。

主題を、本明細書で、法定要件を満たすために、特定性を有して説明する。しかし、その説明自体は、必ずしも特許請求の範囲の範囲を限定するように意図されているとは限らない。むしろ、特許請求の範囲に記載された主題が、他の現在または将来の技術と共に、他の方法で実施されて、異なるステップ、または、本書で説明するステップに類似したステップの組み合わせを含むようにしてもよい。用語は、個々のステップの順序が明記されない限り、および、明記される場合を除いて、本明細書で開示する様々なステップ間のいかなる特定の順序を含意するようにも解釈されるべきではない。

全体として、本発明の一実施形態は、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てすることを、対象とする。本明細書で使用される場合、「アプリケーションコンポーネント」は、データセンタリソース上で配置され、および、１つまたは複数の他のアプリケーションコンポーネントと共に実行されて、アプリケーションの所望の機能性が達成される、アプリケーションの少なくとも一部を説明する。アプリケーションコンポーネントは、「インスタンス」、「ロールインスタンス」または「アプリケーションロールインスタンス」と呼ばれることがある。「データセンタリソース」には、サーバ（「ノード」とも呼ばれる）、ディスクまたは仮想マシン（ＶＭ）など、データセンタのコンピューティングリソースが含まれる。典型的には、データセンタは、接続されて、リソースのネットワークが形成される、ある量の（例えば、数千の）個々のリソースを含む。

アプリケーションは、そのアプリケーションがどのようにリソースのネットワークの中で配置されるべきであるかを規定する、命令（「アプリケーションモデル」または「アプリケーション配置パラメータ」とも呼ばれる）を含むことが多い。例えば、命令は、アプリケーションを、５０個のロールインスタンス（すなわち、アプリケーションコンポーネント）として、各々が別々の電源を含む５個の異なるデータセンタリソース（例えば、サーバ）の中に、均等に配置（配置）することを、指示してもよい。それに応じて、１０個のロールインスタンスが、５個のリソースの各々において配置されるようになる。１０個のロールインスタンスの各セットを、それぞれの仮想グループ（「アップグレードドメイン」とも呼ばれる）として指定してもよい。アプリケーションモデルの可用性制約に基づいて、複数の仮想グループは、同時にアップグレードまたは移行可能としないことが多い。

この例を続けると、５個のリソースのうち１個がエラーを起こす場合、本発明の一実施形態は、１０個のアプリケーションコンポーネントを、エラーが起こったリソースから正常なリソースへ移行させる。また、１０個のアプリケーションコンポーネントが、アプリケーションモデルに整合する方法で、再割り当てされる。すなわち、１０個のアプリケーションコンポーネントの移行は、任意の他のアプリケーションコンポーネントの再割り当てまたは任意の他のメンテナンス動作が開始される前に完了され、それにより、仮想グループ移行要件に従う。加えて、１０個のアプリケーションコンポーネントを受け入れる正常なリソース（複数可）は、その上で他の４０個のアプリケーションコンポーネントが配置される４個のリソースのうち１個ではなく、それにより、５個の異なるデータセンタリソースを必要とするパラメータに従う。

実施形態を簡単に説明したが、図１を次に説明し、図１では、本発明の実施形態を実施するための例示的動作環境が示され、全体としてコンピューティングデバイス１００として指定される。コンピューティングデバイス１００は、しかし、適切なコンピューティング環境の一例であり、本発明の実施形態の使用または機能性の範囲についてのいかなる限定を示唆するようにも意図されていない。コンピューティングデバイス１００はまた、例示されたコンポーネントのいずれか１つまたは組み合わせに関係する、いかなる依存性または要件を有するように解釈されるべきでない。

本発明の実施形態は、一般に、コンピュータ、または、パーソナルデータアシスタントもしくは他のハンドヘルドデバイスなど、他のマシンによって実行される、プログラムモジュールなど、コンピュータ実行可能命令を含む、コンピュータコードまたはマシン使用可能命令との関連で説明されうる。一般に、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含むプログラムモジュールは、特定のタスクを行うか、または、特定の抽象データ型を実装する、コードを指す。本発明の実施形態は、ハンドヘルドデバイス、消費者向け電子機器、汎用コンピュータ、より専門のコンピューティングデバイスなどを含む、様々なシステム構成で実施されてもよい。本発明の実施形態はまた、通信ネットワークを通してリンクされるリモート処理デバイスによってタスクが行われる、分散コンピューティング環境で実施されてもよい。

本発明の実施形態は、とりわけ、方法、システム、または、１つもしくは複数のコンピュータ可読メディア上で実施された命令のセットとして、実施されてもよい。コンピュータ可読メディアは、揮発性および不揮発性メディア、リムーバブルおよびノンリムーバブルメディアを共に含み、データベース、スイッチ、および、様々な他のネットワークデバイスによって可読なメディアを企図する。例として、コンピュータ可読メディアは、情報を保存するための任意の方法または技術において実装されたメディアを含む。保存された情報の例には、コンピュータ使用可能命令、データ構造、プログラムモジュール、および、他のデータ表現が含まれる。メディアの例には、情報配信メディアに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）、ホログラフィックメディアまたは他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置および他の磁気記憶装置が含まれる。これらの技術は、データを瞬間的に、一時的に、または永続的に保存することができる。

図１を参照すると、コンピューティングデバイス１００は、以下のデバイスを直接または間接的に結合するバス１１０を含み、これらのデバイスは、メモリ１１２、１つまたは複数のプロセッサ１１４、１つまたは複数の提示コンポーネント１１６、入出力ポート１１８、入出力コンポーネント１２０、および、電源装置１２２である。バス１１０は、１つまたは複数のバス（アドレスバス、データバス、または、それらの組み合わせなど）でありうる物を表す。図１の様々なブロックを、明快にするために線で示すが、実際には、様々なコンポーネントを図で表すことは、それほど明快ではなく、比喩的には、これらの線は、より正確には、どっちつかずで不明瞭となる。例えば、ディスプレイデバイスなど、提示コンポーネントを、Ｉ／Ｏコンポーネントであると見なすことができる。また、プロセッサも、メモリを有する。我々は、そのようなことが当技術分野の性質であると認識し、図１の図が、本発明の１つまたは複数の実施形態に関連して使用されうる、例示的コンピューティングデバイスを例示するのみであることを、繰り返し述べる。「ワークステーション」、「サーバ」、「ラップトップ」、「ハンドヘルドデバイス」などのようなカテゴリ間の区別は行われず、その理由は、すべてが図１および「コンピューティングデバイス」への言及の範囲内で企図されるからである。

コンピューティングデバイス１００は典型的には、様々なコンピュータ可読メディアを含む。例として、コンピュータ可読メディアには、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電子的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリもしくは他のメモリ技術、ＣＤＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光もしくはホログラフィックメディア、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、搬送波、または、所望の情報を符号化するために使用でき、コンピューティングデバイス１００によってアクセス可能な、任意の他のメディアが含まれてもよい。

メモリ１１２には、揮発性および／または不揮発性メモリの形態の、コンピュータ記憶メディアが含まれる。このメモリは、リムーバブル、ノンリムーバブル、または、それらの組み合わせであってもよい。例示的ハードウェアデバイスには、ソリッドステートメモリ、ハードドライブ、光ディスクドライブなどが含まれる。コンピューティングデバイス１００は、メモリ１１２またはＩ／Ｏコンポーネント１２０など、様々なエンティティからデータを読み取る、１つまたは複数のプロセッサ１１４を含む。提示コンポーネント（複数可）１１６は、ユーザまたは他のデバイスに、データ指示を提示する。例示的提示コンポーネントには、ディスプレイデバイス、スピーカ、印刷コンポーネント、振動コンポーネントなどが含まれる。

Ｉ／Ｏポート１１８は、コンピューティングデバイス１００を、Ｉ／Ｏコンポーネント１２０を含む他のデバイスに論理的に結合できるようにし、Ｉ／Ｏコンポーネント１２０のうちいくつかは、組み込まれてもよい。例示的コンポーネントには、マイクロホン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ、プリンタ、ワイヤレスデバイスなどが含まれる。

次に図２を参照すると、本発明の一実施形態を実施するために適した例示的動作環境が、全体として参照番号２１０によって示され、識別される。環境２１０は、ネットワーク化されたデータセンタコンピュータリソース２１２およびコントローラ２１４のセットを含み、コントローラ２１４は、リソース２１２の監視、維持および割り振りを行って、データセンタ内で配置されたアプリケーションをホストする。

リソース２１２は、リソースＡ２１６、リソースＢ２１８、リソースＣ２２０、および、リソースＤ２２２を含む。リソースＡ〜Ｄを、例示の目的で示すが、リソース２１２は、省略符号２２４で示すように、いくつかの他のリソース（例えば、数千）を含んでもよい。

図２では、アプリケーションは、リソースＡ２１６およびリソースＢ２１８を使用して配置されている。リソースＡ２１６は、アプリケーションロールインスタンス１ ２２６、および、アプリケーションロールインスタンス２ ２２８を含み、リソースＢ２１８は、アプリケーションロールインスタンス３ ２３０、および、アプリケーションロールインスタンス４ ２３２を含む。すなわち、アプリケーション（例えば、アプリケーションモデル２５０内で識別された「アプリケーション例」）が、リソースＡ２１６およびリソースＢ２１８を使用して配置されており、このアプリケーションは、少なくとも４個のロールインスタンスを含む。また、これらの４個のロールインスタンス（すなわち、２２６、２２８、２３０および２３２）は、仮想グループ（例えば、アップグレードドメイン）に分割される。例えば、仮想グループＡ１は、ロールインスタンス１ ２２６、および、ロールインスタンス２ ２２８を含み、仮想グループＢ１は、ロールインスタンス３ ２３０、および、ロールインスタンス４ ２３２を含む。４個のロールインスタンスのみを、例示の目的で図２に示すが、アプリケーションは、他のリソースの中に配置され、より大きい、より多数の仮想グループに分割された、いくつかの他のロールインスタンスを含んでもよい。

リソースＡ２１６およびリソースＢ２１８は、障害のある状態を示すために、影付きである。リソースは、様々な理由のために、障害のある状態を含むと見なされることがあり、リソースが、手動調査状態（例えば、ＨｕｍａｎＩｎｖｅｓｔｉｇａｔｉｖｅ（ＨＩ）状態）、または、修復状態（例えば、「ＯｕｔＦｏｒＲｅｐａｉｒ」）である場合などである。リソース２１２はまた、リソースＣ２２０およびリソースＤ２２２をも含み、リソースＣ２２０およびリソースＤ２２２は共に、障害のない状態を示すために、影付きではない。また、リソースＣ２２０およびリソースＤ２２２の各々は、空のボックス２３６、２３８、２４０および２４２によって示すように、アプリケーションコンポーネント（例えば、アプリケーションロールインスタンス）を受け入れるための可用性を含む。

コントローラ２１４（例えば、ファブリックコントローラ）は、互いに通信し、ならびに、ネットワーク化されたコンピュータリソースインベントリ２４４、アプリケーション情報データストア２４６、および、アプリケーションコンポーネントリアロケータ（ｒｅａｌｌｏｃａｔｏｒ）２４８を含む、様々なコンポーネントを含む。以前に示したように、コントローラ２１４は、リソース２１２の監視、維持および割り振りを行って、データセンタ内に配置されたアプリケーションをホストする。したがって、インベントリ２４４は、リソース２１２の中に含まれたすべてのリソースのリスト、ならびに、各リソースの正常性または状況の指示を含む。例えば、インベントリ２４４は、リソースＡをリストし、リソースＡが障害のある状況を含むことを指示する。すなわち、インベントリ２４４内にリストされた「リソースＡ」は、リソース２１２の中で示されたリソースＡ２１６に対応する。同様に、インベントリ２４４はまた、リソースＢ〜Ｄ、ならびに、それぞれの状況の指示をもリストする。

アプリケーション情報データストア２４６は、リソース２１２を使用して配置するアプリケーションに関連する情報を保存する。データストア２４６内に保存された情報の例示的タイプには、アプリケーションモデル２５０およびアプリケーション正常性履歴２５２が含まれる。本明細書の例示の目的のために、データストア２４６内に保存された情報は、リソースＡ２１６およびリソースＢ２１８上に配置されるとして説明される、同じアプリケーションに関連する。すなわち、情報２５４の分解図において識別された「アプリケーション例」は、リソースＡ２１６およびリソースＢ２１８を使用して配置される。アプリケーションモデル２５０は、配置される場合、アプリケーション例が、２個のサーバの中で分割された４個のインスタンスを含むことになることを指示する。アプリケーション正常性履歴２５２は、アプリケーションがある期間の全体を通じて再割り当てされた回数または機会の数、ならびに、特定のアプリケーションコンポーネント（例えば、インスタンス）がある期間の全体を通じて再割り当てされた回数を追跡する。以下でより詳細に説明するように、そのようなメトリックスは、アプリケーションおよび／または、およびアプリケーションコンポーネントが、基になるハードウェアに対立するように、障害のある状況を引き起こしている可能性がある場合を識別するために、有用である。

コントローラ２１４はまた、アプリケーションコンポーネントリアロケータ２４８をも含む。リアロケータ２４８は、様々なモニタを含み、これらのモニタは、共に機能して、障害のあるリソースを識別し、使用可能で適切な（すなわち、アプリケーションモデルに整合する）障害のないリソースを決定し、アプリケーションモデル２５０に従って、アプリケーションコンポーネントを、障害のあるリソースから障害のないリソースへ移行させる。

コンポーネントリアロケータ２４８は、リソース状況バックグラウンドモニタ２５６を含み、リソース状況バックグラウンドモニタ２５６は、障害のある状態を含むリソース（例えば、サーバ、ディスクまたはＶＭ）を識別する。一実施形態では、リソース状況バックグラウンドモニタ２５６がウェイクアップする場合、リソース状況バックグラウンドモニタ２５６は、インベントリ２４４を参照して、障害のある状況を含むリソースを識別する。例えば、リソース状況バックグラウンドモニタ２５６は、インベントリ２４４を参照して、リソースＡ２１６が障害のある状況を含むと決定してもよい。以前に説明したように、リソースＡ２１６は、アプリケーションロールインスタンス１ ２２６、および、アプリケーションロールインスタンス２ ２２８をホストする。リソースＡ２１６はエラーを起こしているので、アプリケーションロールインスタンス１ ２２６、および、アプリケーションロールインスタンス２ ２２８を再割り当てして、アプリケーション例が可用性を維持できるようにすることが望ましい。

障害のあるリソースを識別すると、リソース状況バックグラウンドモニタ２５６は、サービス復旧タスク２６０を生成し、サービス復旧タスク２６０は、復旧タスクキュー２６２内で維持される。サービス復旧タスク２６０は、アプリケーションコンポーネントが、識別された障害のあるリソースから再割り当てされる必要があるという、命令を含む。例えば、図２に示すように、サービス復旧タスク２６０は、アプリケーションロールインスタンス１ ２２６がリソースＡから再割り当てされる必要があるという、命令を含んでもよい。明確に示されていないが、タスク２６０は同様に、ロールインスタンス２ ２２８がリソースＢから再割り当てされる必要があるという、命令を含んでもよい。

リソースは、データセンタ制御ソフトウェアアップグレードの配置におけるエラー、構成変更、または、大きいハードウェアエラーなど、グループ全体の状態（すなわち、ネットワーク全体の状態）により、障害のある状況に入る可能性がある。そのようなシナリオでは、コントローラ２１４の少なくともいくつかの動作を一時停止して、調査を可能にするか、または、そうでない場合、アプリケーションコンポーネントを保護することが、望ましいことがある。したがって、再割り当ては望ましくないことがあり、その理由は、再割り当てが、調査を妨げる可能性があり、障害のないノードから再割り当てする可能性があり、または、そうでない場合、アプリケーションに割り当てられたリソースの正常性を復元できない可能性があるからである。したがって、リソース状況バックグラウンドモニタ２５６は、グループ正常性依存ディスエイブラ（ｄｉｓａｂｌｅｒ）２５８を含む。サービス復旧タスク（例えば、２６０）を生成する前に、ディスエイブラ２５８は、リソースのグループの中の障害のあるリソースの数が、グループ正常性しきい値を超えるかどうかを判定する。グループ正常性しきい値は、構成可能であり、障害のあるリソースのしきい値数、または、障害のあるリソースと障害のないリソースの比を含んでもよい。したがって、ディスエイブラ２５８は、インベントリ２４４から、障害のあるリソースの量を決定し、その量を、グループ正常性しきい値と比較する。その量がしきい値未満である場合、リソース状況バックグラウンドモニタ２５６は、続行する。しかし、その量がしきい値を超える場合、リソース状況バックグラウンドモニタ２５６は、無効化され、それにより、復旧動作が中断される。

アプリケーション欠陥は、リソースを障害のある状態に入らせ、アプリケーションの連続的な再割り当てが後続のリソースに悪影響を与えるようになる可能性もある。したがって、リソース状況バックグラウンドモニタ２５６は、アプリケーション復旧レート依存ディスエイブラ２６４を含む。サービス復旧タスク（例えば、２６０）が生成される前に、ディスエイブラ２６４は、アプリケーションの復旧頻度（すなわち、アプリケーションが所与の期間内に何回復旧されたか）を決定する。例えば、アプリケーション正常性履歴２５２が参照されて、アプリケーションがある期間内に何回復旧されたかが決定されてもよい。ディスエイブラ２６４は、アプリケーションの復旧頻度を、アプリケーション復旧レートしきい値と比較する。アプリケーションの復旧頻度が、アプリケーション復旧レートしきい値未満である場合、リソース状況バックグラウンドモニタ２５６は、続行する。しかし、アプリケーションの復旧頻度が、アプリケーション復旧レートしきい値を超える場合、ディスエイブラ２６４は、アプリケーションのためのさらなる復旧の試行を無効化する。加えて、アラームまたは通知が送出され、アプリケーションが調査されるべきであることが指示されてもよい。

アプリケーション復旧レートしきい値は、様々な方法を使用して決定されてもよい。例えば、アプリケーション復旧レートしきい値は、経験に基づいて、ヒューリスティックに決定されてもよい。代替として（または、加えて）、アプリケーション復旧レートしきい値は、リソース（例えば、サーバ）が、アプリケーション欠陥によって引き起こされない、障害のある状態に入る、計算された確率に基づいてもよい。一実施形態では、計算された確率は、ポワソン分布を使用して決定される。すなわち、ポワソン分布は、あるイベント（例えば、リソースが障害のある状態に入ること）が、その最後のイベント以来の時間にかかわらず、そのイベントが既知の平均レートで発生する場合、固定された期間内で発生する確率を表す。したがって、あるアプリケーションが５個のノード上でホストされる場合、ポワソン分布が使用されて、それらの５個のノードが、独立してランダムに引き起こされる（すなわち、アプリケーション欠陥によって引き起こされない）障害のある状態に入る、頻度が示唆される。ポワソン分布によって示唆された頻度よりも多い、それらの５個のノードによるエラーは、アプリケーション欠陥がそれらのエラーを引き起こしている可能性があることを指示する。したがって、ポワソン分布頻度（Ｐｏｉｓｓｏｎ ｄｉｓｔｒｉｂｕｔｉｏｎ ｆｒｅｑｕｅｎｃｙ）を、アプリケーション復旧レートしきい値として使用することができ、または、アプリケーション復旧レートしきい値を示唆するために使用することができる。

アプリケーション欠陥が、リソースを障害のある状態に入らせることと同様に、アプリケーションコンポーネント（例えば、インスタンス）は、リソースを障害のある状態に入らせる欠陥を含むことがある。したがって、リソース状況バックグラウンドモニタ２５６は、アプリケーション復旧レート依存ディスエイブラ２６４と同様に機能する、コンポーネント復旧レート依存ディスエイブラ２６６を含む。すなわち、サービス復旧タスク（例えば、２６０）が生成される前に、ディスエイブラ２６６は、コンポーネントの復旧頻度（すなわち、コンポーネントが所与の期間内に何回復旧されたか）を決定する。例えば、アプリケーション正常性履歴２５２が参照されて、コンポーネントがある期間内に何回復旧されたかが決定されてもよい。ディスエイブラ２６６は、コンポーネントの復旧頻度を、コンポーネント復旧レートしきい値と比較する。コンポーネントの復旧頻度が、コンポーネント復旧レートしきい値未満である場合、リソース状況バックグラウンドモニタ２５６は、続行する。しかし、コンポーネントの復旧頻度が、コンポーネント復旧レートしきい値を超える場合、ディスエイブラ２６６は、コンポーネントのアプリケーションのためのさらなる復旧の試行を無効化する。加えて、アラームまたは通知が送出され、アプリケーションコンポーネントが調査されるべきであることが指示されてもよい。

チェックされない場合、アプリケーションコンポーネントリアロケータ２４８による再割り当ては、コントローラ２１４のワークロードを考慮に入れることなく、多数のタスクを生成することがある。したがって、しきい値は、再割り当てセッション内で生成されるタスクの数を制限するために、確立されてもよい。すなわち、リソース状況バックグラウンドモニタ２５６は、部分的には、休止状態からウェイクすること、障害のあるリソースを識別すること、サービス復旧タスクを作成すること、および、休止状態へ戻ることによって、機能する。リソース状況バックグラウンドモニタ２５６がウェイクアップするたびに、リソース状況バックグラウンドモニタ２５６は、再割り当てセッションを開始する。

したがって、コントローラ２１４のワークロードを管理するために、リソース状況バックグラウンドモニタ２５６が所与の再割り当てセッション内で再割り当て可能にされる、アプリケーションの概数に、上限が設定されてもよい。したがって、セッションごとのスロットル２６８は、再割り当てセッション内で再割り当て可能にされる、アプリケーションの数を制御する。セッションごとのスロットル２６８が、セッションごとの上限を確立する場合、リソース状況バックグラウンドモニタ２５６は、次のリソース境界に丸められた、ほぼ、セッションごとの上限で再割り当てするようになる。例えば、リソース状況バックグラウンドモニタ２５６は、ウェイクアップし、各リソースが８個のアプリケーションをホストする、障害のある３個のリソースを、識別することがある。セッションごとのスロットル２６８が、再割り当ての上限を１０個のアプリケーションに定める場合、３個のリソースのうち２個（すなわち、１６個のアプリケーション）が再割り当てされ、残りの１つのリソースは、後続のセッション内で再割り当てされる。すなわち、セッションごとの上限（例えば、１０）が超えられる場合、最大で次のリソース境界までのリスト（例えば、１６個のアプリケーション）が再割り当てされるようになるが、それより多くは再割り当てされないようになる。

コンポーネント再配置バックグラウンドモニタ２７０は、サービス復旧タスクを使用し、アプリケーションコンポーネントが移行されうる先の障害のないリソースを識別する。例えば、サービス復旧タスク２６０を受け入れると、コンポーネント再配置バックグラウンドモニタ２７０は、インベントリ２４４を参照して、アプリケーションロールインスタンス１ ２２６を受け入れるために使用可能であるリソースを識別してもよい。

使用可能な障害のないリソースを識別することに加えて、コンポーネント再配置バックグラウンドモニタ２７０は、アプリケーションロールインスタンス１ ２２６の、特定の障害のないリソースへの移行が、アプリケーションモデル２５０に適合することを保証する。例えば、アプリケーションモデル２５０は、アプリケーション例が２個のサーバを使用して配置されることになることを、規定する。したがって、単一のサーバが、アプリケーションロールインスタンス１〜４の各々をホストするために使用可能であった場合でも、コンポーネント再配置バックグラウンドモニタ２７０は、それらのアプリケーションコンポーネントのすべてがその単一のサーバへ再割り当てされるように、スケジュールするようにはならない。

コンポーネント再配置バックグラウンドモニタ２７０が、アプリケーションコンポーネントが再割り当てされうる先の、使用可能で適切なリソースを識別した後、コンポーネント再配置バックグラウンドモニタ２７０は、アップグレードタスク２７２を生成する。例えば、アップグレードタスク２７２は、アプリケーションロールインスタンス１ ２２６の、リソースＣ２２０への再割り当てを命令する。明確に示されていないが、タスク２７２は同様に、ロールインスタンス２ ２２８が、使用可能で適切なリソースへ再割り当てされる必要があるという、命令を含んでもよい。アプリケーションロールインスタンス２ ２２８に関連するアップグレードタスク（例えば、２７２）は、アプリケーションモデル２５０への適合が維持される限り、アプリケーションロールインスタンス２ ２２８がリソースＣ２２０またはリソースＤ２２０のいずれかに移行されるべきであることを、命令してもよい。アップグレードタスクは、ローリングアップグレードタスクキュー２７６内で優先される。

コンポーネント再配置モニタ２７０はまた、セッションごとのスロットル２７４をも含んでもよく、セッションごとのスロットル２７４は、セッションごとのスロットル２６８と同様に機能する。すなわち、セッションごとのスロットル２７４は、再割り当てセッション内で再割り当て可能なアプリケーションの数を制御する。セッションごとのスロットル２７４が、セッションごとの上限を確立する場合、ウェイクすると、コンポーネント再配置バックグラウンドモニタ２７０は、上限にほぼ等しい数のサービス復旧タスクを処理する。すなわち、コンポーネント再配置バックグラウンドモニタ２７０は、リソース状況バックグラウンドモニタ２５６と同様に、次のリソース境界に丸められた数を処理してもよい。

ローリングアップグレードバックグラウンドモニタ２７８は、アップグレードタスクを使用し、アプリケーションコンポーネントの再割り当てを実行する。例えば、ローリングアップグレードバックグラウンドモニタ２７８は、アプリケーションロールインスタンス１ ２２６をリソースＣへ再割り当てる。一実施形態では、ローリングアップグレードバックグラウンドモニタ２７８は、仮想グループルールを適用する。例えば、ローリングアップグレードバックグラウンドモニタ２７８は、あるアプリケーションの別の仮想グループ（例えば、仮想グループＢ１）の移行を開始する前に、同じアプリケーションのある仮想グループ（例えば、仮想グループＡ１）全体が新しいリソースに移行するのを、待機してもよい。この点において、ローリングアップグレードタスクキューは、先入先出処理スキームに従わない。

ローリングアップグレードバックグラウンドモニタ２７８はまた、セッションごとのスロットル２８０をも含んでもよく、セッションごとのスロットル２８０は、セッションごとのスロットル２６８およびセッションごとのスロットル２７４と同様に機能する。すなわち、セッションごとのスロットル２８０は、再割り当てセッション内で再割り当て可能にされる、アプリケーションの数を制御する。セッションごとのスロットル２８０が、セッションごとの上限を確立する場合、ウェイクすると、ローリングアップグレードバックグラウンドモニタ２７８は、上限にほぼ等しい数のアップグレードタスクを処理する。すなわち、ローリングアップグレードバックグラウンドモニタ２７８は、リソース状況バックグラウンドモニタ２５６およびコンポーネント再配置モニタ２７０と同様に、次のリソース境界に丸められた数を処理してもよい。

図３を参照すると、本発明の一実施形態で行われる方法の概略を述べる、流れ図が示される。この方法は全体として、参照番号３１０によって示され、図３を説明する場合、図２もまた参照されることがある。この方法は、その上で実施されるコンピュータ実行可能命令を有する、１つまたは複数のコンピュータ可読メディア上で実施されてもよく、その命令は、実行される場合、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てする方法を実施する。

方法３１０は、３１２で、その上でアプリケーションコンポーネント（例えば、インスタンス２２６および２２８）がホストされる、障害のあるデータセンタリソース（例えば、サーバ、ディスク、仮想マシン）を識別することを含む。例えば、障害のあるデータセンタリソースは、リソース状況バックグラウンドモニタがウェイクアップし、インベントリ２４４を参照する場合、識別される。ステップ３１４は、アプリケーションコンポーネントを、障害のあるデータセンタリソースから移動することを命令する、サービス復旧タスク（例えば、２６０）を生成することを含む。例えば、障害のあるデータセンタリソースを識別した後、リソース状況バックグラウンドモニタ２５６は、サービス復旧タスクを生成してもよい。

ステップ３１６で、方法３１０は、サービス復旧タスクを使用し、アプリケーションコンポーネントを受け入れるために使用可能な、障害のないデータセンタリソースを識別する、コンポーネント再配置バックグラウンドモニタを実行することを含む。例えば、出願人モデル２５０がチェックされて、アプリケーションコンポーネントを再割り当てする場合に満たされることになるパラメータが決定されてもよい。例示的パラメータは、その中でアプリケーションコンポーネントが配分されることになる、リソース（例えば、サーバ）の総数を含む。インベントリ２４４が参照されて、どのリソースに障害がないか、および、それらのパラメータに適合する、選択された使用可能な障害のないリソースが、決定されてもよい。

ステップ３１８は、アプリケーションコンポーネントが、障害のないデータセンタリソースへ移動されることになることを命令する、ローリングアップグレードタスク（例えば、２７２）を生成することを含む。加えて、ステップ３２０は、ローリングアップグレードタスクを使用し、アプリケーションコンポーネントを障害のないデータセンタリソースへ再割り当てする、ローリングアップグレードバックグラウンドモニタを実行することを含む。以前に説明したように、方法３１０を実行する場合、様々なしきい値が利用されて、ワークロードが制御されてもよく（例えば、セッションごとのスロットル）、ならびに、リソースエラーが、データセンタ全体の処理（例えば、グループ正常性しきい値）またはアプリケーションエラー（例えば、アプリケーション復旧レートしきい値）の結果として生じている可能性がある場合が、検出されてもよい。

次に図４を参照すると、本発明の一実施形態で行われる方法の概略を述べる、別の流れ図が示される。この方法は全体として、参照番号４１０によって示され、図４を説明する場合、図２もまた参照されることがある。この方法は、その上で実施されるコンピュータ実行可能命令を有する、１つまたは複数のコンピュータ可読メディア上で実施されてもよく、その命令は、実行される場合、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てする方法を実施する。

動作４１２で、方法４１０は、データセンタリソースのグループの中で、障害のあるデータセンタリソースを含む、そのグループの部分を決定することを含む。加えて、ステップ４１４は、その部分を、グループ正常性しきい値と比較することを含む。例えば、グループ正常性依存ディスエイブラ２５８は、障害のあるリソースの部分が高すぎないことを確認してもよく、その確認は、サービス復旧が継続する前に、ネットワーク全体の状態が考慮に入れられるべきであることを、示唆することがある。

動作４１６は、その部分がグループ正常性しきい値未満である場合、その上でアプリケーションコンポーネントが配置されている障害のあるデータセンタリソースを識別することを含み、アプリケーションコンポーネントは、所与の期間内である回数の量（ｑｕａｎｔｉｔｙ ｏｆ ｔｉｍｅｓ）だけ再割り当てされている。また、ステップ４１８は、その回数の量を、別のしきい値と比較することを含む。別のしきい値には、アプリケーション復旧レートしきい値、コンポーネント復旧レートしきい値、または、アプリケーション復旧レートしきい値およびコンポーネント復旧レートしきい値の両方が含まれてもよい。例えば、アプリケーション復旧レート依存ディスエイブラ２６４は、その回数の量が高すぎないことを確認してもよく、その理由は、高い再割り当てレートが、アプリケーションがリソースエラーの根本原因であることを示唆するためである。さらに、動作４２０は、その量が別のしきい値未満である場合、アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てすることを含む。

示された様々なコンポーネントの多数の異なる配置、ならびに、図示されないコンポーネントは、以下の特許請求の範囲の範囲から逸脱することなく、可能である。本発明の実施形態を、限定的ではなく、例示的であるように意図して、説明した。代替的実施形態は、本開示を読んだ後、および、本開示を読むことにより、本開示の読者には明らかになるであろう。上記を実施する代替手段は、以下の特許請求の範囲の範囲から逸脱することなく、完成されうる。ある特徴およびサブコンビネーションは、他の特徴およびサブコンビネーションに関係なく有益であり、採用可能であり、特許請求の範囲の範囲内で企図される。

Claims (12)

1. アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てする方法であって、
   前記アプリケーションコンポーネントが配置されている前記障害のあるデータセンタリソースを識別するステップであって、前記アプリケーションコンポーネントは、アプリケーションの少なくとも一部を含み、前記アプリケーションを実行する複数のアプリケーションコンポーネントとともに実行されるステップと、
   所与の期間内で前記アプリケーションコンポーネントが複数のデータセンタリソース間で再割り当てされた機会の数を示すアプリケーション履歴をデータストアで参照するステップと、
   前記機会の数が、計算される確率分布頻度を超えるか判断するステップであって、前記計算される確率分布頻度は、前記複数のデータセンタリソースの各障害状態に入ることが前記アプリケーションにより生じたことの計算される確率を含むステップと、
   前記機会の数が前記計算される確率分布頻度を超える場合、サービス復旧動作を中断するステップと、
   前記機会の数が前記計算される確率分布頻度を超えない場合、前記アプリケーションコンポーネントを再割り当てするステップであって、前記再割り当てするステップは、
   サービス復旧タスクを生成するステップであって、前記サービス復旧タスクは、前記アプリケーションコンポーネントを、前記障害のあるデータセンタリソースから移動するタスクである、ステップと、
   コンポーネント再配置バックグラウンドモニタを実行するステップであって、前記コンポーネント再配置バックグラウンドモニタが前記サービス復旧タスクを使用して、前記アプリケーションコンポーネントを受け入れるために使用可能な前記障害のないデータセンタリソースを識別する、ステップと、
   ローリングアップグレードタスクを生成するステップであって、前記ローリングアップグレードタスクは前記アプリケーションコンポーネントを、前記障害のないデータセンタリソースへ移動することになることを命令するタスクである、ステップと、
   ローリングアップグレードバックグラウンドモニタを実行するステップであって、前記ローリングアップグレードバックグラウンドモニタが前記ローリングアップグレードタスクを使用して、前記アプリケーションコンポーネントを前記障害のないデータセンタリソースへ再割り当てする、ステップとにより行われるステップと、
   を備えることを特徴とする方法。
2. 前記アプリケーションコンポーネントは、アプリケーションコンポーネントのセットのうちの１つのコンポーネントであり、
   前記セットが、２つ以上の仮想グループの間で分割され、前記アプリケーションコンポーネントは１つの仮想グループ内にあり、前記セットの別のアプリケーションコンポーネントは別の仮想グループ内にあるようにすることを特徴とする請求項１に記載の方法。
3. 前記１つの仮想グループおよび前記別の仮想グループが、それぞれ障害のあるデータセンタリソース上で割り当てられており、
   前記ローリングアップグレードタスクに従った、前記アプリケーションコンポーネントの再割り当ての開始は、前記別の仮想グループ内の前記別のアプリケーションコンポーネントの再割り当ての完了を条件とすることを特徴とする請求項２に記載の方法。
4. 前記障害のないデータセンタリソースを識別するために、前記コンポーネント再配置バックグラウンドモニタは、ネットワーク化されたコンピュータリソースコントローラによって維持されるリソースのインベントリを参照することを特徴とする請求項１に記載の方法。
5. 前記障害のあるデータセンタリソースが、複数のデータセンタリソースのネットワーク内に含まれ、
   前記障害のあるデータセンタリソースを識別するステップに先立って、前記複数のうち、障害のあるデータセンタリソースを含む部分が識別され、
   前記部分がしきい値部分を超える場合、前記サービス復旧タスクが生成されないことを特徴とする請求項１に記載の方法。
6. アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てするシステムであって、
   一以上の処理ユニットと、
   コンピュータ読み取り可能記憶メモリであって、前記一以上の処理ユニットに
   前記アプリケーションコンポーネントが配置されている前記障害のあるデータセンタリソースを識別するステップであって、前記アプリケーションコンポーネントはアプリケーションの少なくとも一部を含み、前記アプリケーションを実行する複数のアプリケーションコンポーネントとともに実行されるステップと、
   所与の期間内で前記アプリケーションコンポーネントが複数のデータセンタリソース間で再割り当てされた機会の数を示すアプリケーション履歴をデータストアで参照するステップと、
   前記機会の数が、計算される確率分布頻度を超えるか判断するステップであって、前記計算される確率分布頻度は、前記複数のデータセンタリソースの各障害状態に入ることが前記アプリケーションにより生じたことの計算される確率を含むステップと、
   前記機会の数が前記計算される確率分布頻度を超える場合、サービス復旧動作を中断するステップと、
   前記機会の数が前記計算される確率分布頻度を超えない場合、前記アプリケーションコンポーネントを再割り当てするステップであって、前記再割り当てするステップは、
   サービス復旧タスクを生成するステップであって、前記サービス復旧タスクは、前記アプリケーションコンポーネントを、前記障害のあるデータセンタリソースから移動するタスクである、ステップと、
   コンポーネント再配置バックグラウンドモニタを実行するステップであって、前記コンポーネント再配置バックグラウンドモニタが前記サービス復旧タスクを使用して、前記アプリケーションコンポーネントを受け入れるために使用可能な前記障害のないデータセンタリソースを識別する、ステップと、
   ローリングアップグレードタスクを生成するステップであって、前記ローリングアップグレードタスクは前記アプリケーションコンポーネントを、前記障害のないデータセンタリソースへ移動することになることを命令するタスクである、ステップと、
   ローリングアップグレードバックグラウンドモニタを実行するステップであって、前記ローリングアップグレードバックグラウンドモニタが前記ローリングアップグレードタスクを使用して、前記アプリケーションコンポーネントを前記障害のないデータセンタリソースへ再割り当てする、ステップとにより行われるステップと、
   を実行させるコンピュータプログラムを記憶したコンピュータ読み取り可能記憶メモリと
   を備えることを特徴とするシステム。
7. データセンタリソースのグループの中で障害のあるデータセンタリソースの割合を決定するグループ正常性依存ディスエイブラをさらに備え、
   前記割合がしきい値の割合を超える場合、障害のあるデータセンタリソースを識別するリソース状況バックグラウンドモニタが無効化されることを特徴とする請求項６に記載のシステム。
8. 前記アプリケーションコンポーネントを所与の期間内で復旧する回数を追跡するコンポーネント復旧レート依存ディスエイブラをさらに備え、
   前記回数がコンポーネントごとの復旧頻度しきい値を超える場合、前記アプリケーションを復旧することを目的とする動作が無効化されることを特徴とする請求項６に記載のシステム。
9. セッションごとのスロットルをさらに備え、当該セッションごとのスロットルが、
   障害のあるデータセンタリソースを識別するリソース状況バックグラウンドモニタが、単一の再割り当てセッション内で処理可能なアプリケーションコンポーネントの数、
   前記コンポーネント再配置バックグラウンドモニタが、単一の再割り当てセッション内で処理可能なアプリケーションコンポーネントの数、
   アップグレードバックグラウンドモニタが、単一の再割り当てセッション内で処理可能なアプリケーションコンポーネントの数、または、
   それらの組み合わせを
   制御することを特徴とする請求項６に記載のシステム。
10. アプリケーションコンポーネントを、障害のあるデータセンタリソースから障害のないデータセンタリソースへ再割り当てするコンピュータプログラムであって、コンピュータに、
    データセンタリソースのグループの中で、前記グループの部分であって、障害のあるデータセンタリソースを含む部分を決定するステップと、
    前記部分を、グループ正常性しきい値と比較するステップと、
    前記部分が前記グループ正常性しきい値未満である場合、その上で前記アプリケーションコンポーネントが配置されている前記障害のあるデータセンタリソースを識別するステップとを実行させ、
    前記アプリケーションコンポーネントはアプリケーションの少なくとも一部を含み、前記アプリケーションを実行する複数のアプリケーションコンポーネントとともに実行され、
    前記アプリケーションコンポーネントが、所与の期間内である回数の量だけ再割り当てされ、
    前記回数の量をポワソン分布頻度と比較するステップであって、前記ポワソン分布頻度は前記複数のデータセンタリソースの各障害状態に入ることが前記アプリケーションにより生じたことの計算される確率を含むステップと、
    前記量が前記ポワソン分布頻度未満である場合、前記アプリケーションコンポーネントを、前記障害のあるデータセンタリソースから前記障害のないデータセンタリソースへ再割り当てするステップと
    を実行させることを特徴とするコンピュータプログラム。
11. 前記アプリケーションコンポーネントは、アプリケーションコンポーネントのセットのうちの１つのコンポーネントであり、
    前記セットが、２つ以上の仮想グループの間で分割され、前記アプリケーションコンポーネントは１つの仮想グループ内にあり、前記セットの別のアプリケーションコンポーネントは別の仮想グループ内にあるようにすることを特徴とする請求項１０に記載のコンピュータプログラム。
12. 前記１つの仮想グループおよび前記別の仮想グループが、それぞれ障害のあるデータセンタリソース上で割り当てられ、
    前記アプリケーションコンポーネントを再割り当てするステップは、前記別の仮想グループ内の前記別のアプリケーションコンポーネントの再割り当ての完了を条件とすることを特徴とする請求項１１に記載のコンピュータプログラム。

Images