JP2011511360A - ハイブリッド型のコンピューティング環境を管理するためのシステムおよび方法 - Google Patents

Abstract

ノードをワークロードに対して動的にプロビジョニングするためのシステム、ハイブリッド型のコンピューティング環境、方法およびコンピュータ可読媒体が開示される。上記ハイブリッド型のコンピューティング環境で、各ノードが、第１のオペレーティングシステムと関連付けられた第１のリソースマネージャおよび第２のオペレーティングシステムと関連付けられた第２のリソースマネージャと通信する。上記方法は、ハイブリッド型のコンピューティング環境の少なくとも１つのノードを第１のオペレーティングシステムから第２のオペレーティングシステムへプロビジョニングする命令を受け取るステップと、第２のオペレーティングシステムをプロビジョニングした後に、上記少なくとも１つのノードと関連付けられたリソースマネージャからの少なくとも１つの信号をプールするステップと、上記少なくとも１つのノードと関連付けられた第２のリソースマネージャからの少なくとも１つの信号を処理するステップと、第２のオペレーティングシステムがプロビジョニングされた上記少なくとも１つのノードと関連付けられたリソースを消費するステップとを含む。

Description

本発明は、そのコンピューティング環境の内部に複数の異なるタイプのオペレーティングシステムが様々なノード上に存在する、グリッドにおけるクラスタなどのハイブリッド型のコンピューティング環境に関し、より詳細には、１つまたは複数のノード上のオペレーティングシステムを、それが保留中のまたは予測されるワークロードに関連する要求などの様々な要素に基づいて単独のオペレーティングシステムになるように自動的に再プロビジョニングすることができる、自動化されたプロビジョニング（供給、準備）を管理するシステムおよび方法に関する。

ハイパフォーマンスコンピューティング（ＨＰＣ）は一般に、市販の相互接続により単一のシステムに同時にリンクされたマルチプロセッサを備える、並列スーパーコンピュータおよびコンピュータクラスタを利用することをいう。高レベルの技術的スキルが一般に、かかるシステムの構成および管理に必要とされるが、それらは市販品のコンポーネントによって作成することができる。これらの柔軟性と比較的低いコストのために、ＨＰＣシステムは徐々に、スーパーコンピューティングの世界で優位を占めてきている。ＨＰＣでは従来より、Ｌｉｎｕｘ（登録商標）オペレーティングシステムが優位を占めてきた。しかしながら、専門家は、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｗｉｎｄｏｗｓ（登録商標）ベースのデータセンタ、クラスタまたはコンピューティング環境が近い将来、より普及する可能性があると予測している。これは、Ｍｉｃｒｏｓｏｆｔとアプリケーションベンダの強力な関係などの様々な要素によると考えられる。こういったベンダの多くは、そのＨＰＣアプリケーションをＷｉｎｄｏｗｓ Ｃｏｍｐｕｔｅ Ｃｌｕｓｔｅｒ Ｓｅｒｖｅｒ ２００３（ＣＣＳ）へすでに移植している。さらに、ＨＰＣ概念に不慣れなＷｉｎｄｏｗユーザからなる市場が主に関わる、ワークグループクラスタの需要が増加している。その結果、これまではＬｉｎｕｘを専ら動作させていたＨＰＣ環境で、Ｗｉｎｄｏｗｓベースのクラスタリングの選択肢が模索されている。Ｗｉｎｄｏｗ／Ｌｉｎｕｘハイブリッド型のクラスタを用いることにより、ＨＰＣ環境におけるＷｉｎｄｏｗｓ導入へのＬｉｎｕｘ環境の障壁が低くなる。しかしながら、場合によっては、ノードの一部はＬｉｎｕｘなどの第１のコンピュータオペレーティングシステムを実行でき、他のノードはＷｉｎｄｏｗｓベースのオペレーティングシステムなどの第２のオペレーティングシステムを実行できるハイブリッド型の環境を管理しようとするときに必要な柔軟性に問題が生じる。したがって、当技術分野には、ハイブリッド型のクラスタ環境を管理する改良された方法が必要である。

図２Ａは、複数の異なるコンピューティング環境を示している。これは、単一のハイブリッド型のコンピューティング環境であってもよい。第１の環境２００は、別個のコンピューティング環境を表していても、ハイブリッド型のコンピューティング環境の一部分を表していてもよい。ＬｉｎｕｘオペレーティングシステムとＷｉｎｄｏｗｓベースのオペレーティングシステムについて説明するが、本発明は第２のオペレーティングシステムとは異なる任意の第１のオペレーティングシステムに関するものであることが企図されている。本発明の範囲内で企図されているオペレーティングシステムには、Ｍａｃｉｎｔｏｓｈオペレーティングシステムなど多種多様のタイプがあるが、ＬｉｎｕｘおよびＷｉｎｄｏｗｓが普及タイプのオペレーティングシステムであることから、これらの用語のみを使用する。本発明は、この２つのタイプのオペレーティングシステムの範囲内で柔軟性を実現することによって開発された。

ノード２０２は、第１のリソースマネージャ２０４によって管理される、Ｌｉｎｕｘオペレーティングシステムなどの第１のオペレーティングシステムを表す。当技術分野で知られているように、この第１のリソースマネージャは、ＴＯＲＱＵＥ、Ｐｌａｔｆｏｒｍ’ｓ Ｌｏａｄ Ｓｈａｒｉｎｇ Ｆａｃｉｌｉｔｙ（ＬＳＦ）、ＰＢＳＰｒｏ（Ａｌｔ
ａｉｒ Ｅｎｇｉｎｅｅｒｉｎｇ製）などであってよい。こういったリソースマネージャによって一般に、当技術分野で知られているように、ノード２０２が、ユーザが投入するジョブ２０８を受けるワークロードマネージャ２０６と通信できるようになる。環境２１０が、Ｗｉｎｄｏｗｓベースの環境（すなわち第２のオペレーティングシステム）を表す。この環境もやはり、同じハイブリッド型のコンピューティング環境の一部分であってもよく、あるいはノード２１２がＷｉｎｄｏｗｓのＣｏｍｐｕｔｅ Ｃｌｕｓｔｅｒ Ｓｅｒｖｅｒ（ＣＣＳ）などのＷｉｎｄｏｗｓベースのオペレーティングシステムを実行する別個の環境であってもよい。第２のオペレーティングシステムのためのリソースマネージャ２１４により、ワークロードマネージャ２１６がＷｉｎｄｏｗｓベースのノードと通信できるようになる。この場合も、ジョブ２０８をワークロードマネージャ２１６を介して投入することができ、ワークロードマネージャ２１６はリソースマネージャ２１４と通信して、ジョブが環境２１０内部で実際にリソースを消費するのを可能にする。

本発明の追加の特徴および利点については、以下で説明し、その説明からある程度明らかになるか、あるいは本発明の実施によって知ることができる。本発明の特徴および利点は、添付の特許請求の範囲に詳細に示されている機器およびその組合せによって実現し、享受することができる。本発明のこれらの特徴およびその他の特徴は、以下の説明および添付の特許請求の範囲からより完全に明らかになるか、あるいは本明細書に記載の本発明を実施することによって知ることができる。

米国特許公開第２００６／０１４３３５０号明細書 米国特許公開第２００６／０１１７２０８号明細書 米国特許公開第２００５／０２６２５０８号明細書 米国特許公開第２００５／０１５４８６１号明細書 米国特許公開第２００５／０２７８７６０号明細書 米国特許公開第２００２／０１２０７４１号明細書

本発明は、ハイブリッド型のコンピューティング環境の管理に関する当技術分野の欠陥に対処する。

ハイブリッド型のＷｉｎｄｏｗｓ／Ｌｉｎｕｘクラスタを有する能力があると、アドレス指定可能なユーザの数が増大し、クラスタ効率が改善する。Ｃｌｕｓｔｅｒ Ｒｅｓｏｕｒｃｅｓ Ｉｎｃ．社製のＭＯＡＢ（登録商標）などのワークロード管理ソフトウェアが近年開発されたことで、Ｗｉｎｄｏｗｓベースのシステムを使用するより大きな科学者／技術者の基盤を利用することにより、ユーザがその生産性および利用率を向上させ、その範囲を広げることが可能になる。ＭＯＡＢソフトウェアなどの管理ソフトウェアは、ワークロードおよび定義したポリシーに基づいてオペレーティングシステムをいつ変更すべきか最適に判定するための、インテリジェントなスケジューリングポリシーエンジンを提供する。条件が満たされると、この管理ソフトウェアは、ディスクフルまたはディスクレスプロビジョニング、デュアルブート、仮想化などの、現場的に好ましいオペレーティングシステム変更テクノロジによって、変更をトリガすることができる。例えば、こういった方法体系は当分野の技術者に知られている。

本発明は、ハイブリッド型のマルチノードコンピューティング環境においてワークロードを管理するためのシステム、コンピューティング環境、データセンタ、方法およびコンピュータ可読媒体を備え、少なくとも１つのノードが、第１のリソースマネージャによって制御される第１のオペレーティングシステムを有し、少なくとも１つのノードが、第２のリソースマネージャによって制御される第２のオペレーティングシステムを有する。上記方法は、上記コンピューティング環境の上記第１のオペレーティングシステムと上記第２のオペレーティングシステムの間でノードのバランスを取る、ポリシー確立ステップと、確立されたポリシーとの整合性を判定するために、上記コンピューティング環境を周期的に解析するステップと、上記確立されたポリシーに従って少なくとも１つのノードを、上記第１のオペレーティングシステムから上記第２のオペレーティングシステムへ、または上記第２のオペレーティングシステムから上記第１のオペレーティングシステムへ変更するために、前記解析に基づいて、上記コンピューティング環境のノードをプロビジョニングするステップとを含む。

本発明の別の態様は、上記方法が、上記ハイブリッド型のコンピューティング環境のノードをワークロードに対して動的にプロビジョニングするステップを伴う。各ノードは、上記第１のオペレーティングシステムと関連付けられた第１のリソースマネージャおよび上記第２のオペレーティングシステムと関連付けられた第２のリソースマネージャと通信する。上記方法は、ハイブリッド型のコンピューティング環境の少なくとも１つのノードを第１のオペレーティングシステムから上記第２のオペレーティングシステムへプロビジョニングする命令を、ワークロードマネージャから受け取るステップを含む。上記第２のオペレーティングシステムをプロビジョニングした後、上記システムは、上記少なくとも１つのノードと関連付けられた上記第１のリソースマネージャからの少なくとも１つの信号をプールし、上記少なくとも１つのノードと関連付けられた上記第２のリソースマネージからの少なくとも１つの信号を処理し、上記第２のオペレーティングシステムがプロビジョニングされた上記少なくとも１つのノードと関連付けられたリソースを消費できるようにする。

この概念の実際の例は、１０個のノードクラスタが現在状態を有し、３個のノードがＷｉｎｄｏｗｓオペレーティングシステムでプロビジョニングされ、７個のノードがＬｉｎｕｘベースのオペレーティングシステムでプロビジョニングされる場合、Ｗｉｎｄｏｗｓ実行システムを動作させる５個のノードを必要とするはずであるジョブが投入されるものとするというものである。ワークロードマネージャまたはその他のソフトウェアモジュールが、上記コンピューティング環境の２個のノードを上記Ｌｉｎｕｘオペレーティングシステムから上記Ｗｉｎｄｏｗｓオペレーティングシステムへプロビジョニングする命令を生成するはずである。上記Ｌｉｎｕｘノードは、トルク、ＬＳＦ、ＰＢＳｐｒｏなどのリソースマネージャや当技術分野で知られているリソースマネージャと関連付けることができる。上記Ｗｉｎｄｏｗｓベースのノードは、Ｗｉｎｄｏｗｓベースのリソースマネージャと通信することができる。オペレーティングシステムを再プロビジョニングした場合、どのリソースマネージャを利用するべきかに関してと、ワークロードマネージャが所与のノード状態と関連付けられたリソースマネージャからの様々な状態信号またはその他の情報信号をどのように管理するかに関して問題が発生する。この例の下では、ＬｉｎｕｘオペレーティングシステムからＷｉｎｄｏｗｓオペレーティングシステムへプロビジョニングされる上記２つのノードのそれぞれが、各ノードと関連付けることができるリソースマネージャを有しているはずである。しかしながら、Ｌｉｎｕｘオペレーティングシステムがノードにプロビジョニングされる場合、Ｗｉｎｄｏｗｓベースのリソースマネージャはそのノードを認識しないはずであり、したがって、そのノードがダウン状態であることを示すことができる状態信号を送信しているはずである。ただし、ワークロードマネージャは、実際には、別個のオペレーティングシステムがプロビジョニングまたは使用されていることをインテリジェントに識別しているはずであり、交互オペレーティングシステムがノード上で機能している場合は、かかる状態信号をインテリジェントにプールするはずである。これに関して、上記システムは、複数のノードでＬｉｎｕｘ環境からＷｉｎｄｏｗｓベースの環境へ再プロビジョニングするときに、Ｗｉｎｄｏｗｓベースのリソースマネージャからの状態信号のプールから、Ｌｉｎｕｘベースのリソースマネージャからの信号のプールへ切り替わるはずである。上記システムは、適切な数のノードを所望のオペレーティングシステムへ自動的に移行させるために、各リソースマネージャからの様々な競合レポート間で必要な変換、競合緩和および競合管理を実行する。

上記プールされた信号は、所与のノード能力および履歴を解釈して次にそのノードにどのオペレーティングシステムをプロビジョニングできるかを識別するために、ならびに課金またはその他の解析のためにそのノードの履歴を維持するために、ワークロードマネージャから、消費されているワークロードについてはインテリジェントに無視されるが、参照またはアクセスすることができる。

本明細書に開示する原理によるハイブリッド型のクラスタモデルは、両方のオペレーティングシステムのプラットフォームをまたがって管理を統合し、ジョブの投入を集中化する。管理者は、１つの統合されたコンソールから、両方のオペレーティングシステムのポリシーおよびワークロードにコマンドを出すことができる。本明細書に開示されるように動作するソフトウェアすなわちシステムはまた、エンドユーザが指定する必要なくオペレーティングシステム上でジョブが実行されるようにする適用情報およびワークロード情報を利用することによって、クラスタ環境のデュアルオペレーティングシステムの性質を透過的にする。

本発明の上述した利点およびその他の利点と特徴を得ることができる形について説明するために、上記で簡単に説明した本発明の詳細な説明を、添付の図面に示されているその特定の実施形態を参照することによって示す。この添付の図面が本発明の例示的な実施形態のみを示し、したがってその範囲を限定しないとみなすべきであるという条件で、本発明は、添付の図面を併せ読むことによってさらに明確かつ詳細に描写され、説明される。

システム実施形態による基本的なハードウェアコンポーネントを示す図である。 従来技術のハイブリッド型クラスタリング手法の図である。 本発明の態様による環境の例の図である。 本発明の態様による環境の、別の態様の図である。 本発明による方法の実施形態の図である。 本発明による方法の、別の実施形態の図である。

本発明の様々な実施形態について以下に詳細に説明する。特定の実施形態について説明するが、それは例示の目的のためにだけ行われることを理解されたい。その他のコンポーネントおよび構成を、本発明の趣旨および範囲を逸脱することなしに使用できることが当分野の技術者には理解されよう。

図１を参照すると、例示的システムが、汎用コンピューティングデバイス１００を含んでいる。この汎用コンピューティングデバイス１００は、演算処理装置（ＣＰＵ）１２０と、その演算処理装置１２０に様々なシステムコンポーネントを結合するシステムバス１１０とを備える。システムコンポーネントはリードオンリーメモリ（ＲＯＭ）１４０、ランダムアクセスメモリ（ＲＡＭ）１５０などのシステムメモリを含む。その他のシステムメモリ１３０もまた利用することができる。本発明は、複数のＣＰＵ１２０を備えるコンピューティングデバイス上で、あるいはより大きな処理能力を実現するためにネットワーク化されたコンピューティングデバイスのグループすなわちクラスタ上で動作させることができることが理解できよう。システムバス１１０は、メモリバスもしくはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのうちの任意のものを使用するローカルバスを含む、複数のタイプのバス構造のうちの任意のものであってよい。ＲＯＭ１４０などに格納された基本入力／出力（ＢＩＯＳ）が、起動中などにコンピューティングデバイス１００内部の要素間で情報を転送する働きをする基本ルーチンを提供することができる。コンピューティングデバイス１００はさらに、ハードディスクドライブ１６０、磁気ディスクドライブ、光ディスクドライブ、テープドライブなどの記憶装置を含む。記憶装置１６０は、ドライブインターフェースによってシステムバス１１０に接続される。こういったドライブとそれに関連付けられたコンピュータ可読媒体が、コンピューティングデバイス１００のためのコンピュータ可読命令、データ構造、プログラムモジュールおよびその他の不揮発性データ記憶装置を形成する。上記の基本的なコンポーネントは当分野の技術者に周知であり、装置が小型のハンドヘルドコンピューティングデバイスか、デスクトップコンピュータか、コンピュータサーバかなど装置のタイプに応じて、適切な変形形態が企図される。

本明細書に記載の例示的な環境はハードディスクを用いるが、磁気カセット、フラッシュメモリカード、デジタル汎用ディスク、カートリッジ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、ビットストリームを含んだ有線または無線信号などの、コンピュータによりアクセス可能な、データを保存できるその他のタイプのコンピュータ可読媒体を、その例示的な動作環境に使用できることも当分野の技術者によって理解されるはずである。

コンピューティングデバイス１００とユーザの対話を可能にするために、入力デバイス１９０が、音声用のマイクロフォン、ジェスチャ入力すなわち図入力用のタッチスクリーン、キーボード、マウス、動作入力、スピーチなどの、任意の数の入力機構となる。出力デバイス１７０は、当分野の技術者に周知のいくつかの出力機構のうちの１つまたは複数のものであってもよい。いくつかの例では、マルチモードシステムを用いることで、コンピューティングデバイス１００と通信するために、ユーザが複数のタイプの入力を行うことが可能になる。通信インターフェース１８０は、ユーザの入力およびシステムの出力を全体的に制御、管理する。本発明の動作は特定のハードウェア構成に限定されず、したがって、改良型のハードウェア構成またはファームウェア構成が開発されると、それらに対して本明細書の基本的特徴を簡単に代用することができる。

説明を明確にするために、個々の機能ブロック（「プロセッサ」と表示された機能ブロックを含む）を備える例示的システム実施形態を示す。これらのブロックが表す機能は、共有または専用のハードウェアを使用することによって提供することができる。こういったハードウェアは、ソフトウェアを実行できるハードウェアを含むが、それに限定されない。例えば、図１に示されている１つまたは複数のプロセッサの機能を、単一の共有プロセッサまたはマルチプロセッサによって提供することができる。（用語「プロセッサ」を使用しても、ソフトウェアを実行できるハードウェアを限定的に表すと解釈すべきではない）。各例示的実施形態は、マイクロプロセッサおよび／またはデジタルシグナルプロセッサ（ＤＳＰ）のハードウェアと、下記に述べる動作を実行するソフトウェアを保存するためのリードオンリーメモリ（ＲＯＭ）と、結果を保存するためのランダムアクセスメモリ（ＲＡＭ）とを備えることができる。超大規模集積回路（ＶＬＳＩ）のハードウェア実施形態や、汎用ＤＳＰ回路と組み合わせたカスタムＶＬＳＩ回路を設けてもよい。

次に、本発明の一態様によるハイブリッド型のコンピューティング環境が示されている図２Ｂに移る。図２Ｂでは、ハイブリッド型の環境２２０が、Ｌｉｎｕｘなどの第１のオペレーティングシステムを実行するいくつかのノード２０２と、Ｗｉｎｄｏｗｓベースのオペレーティングシステムなどの第２のオペレーティングシステムを動作させるノード２１２の第２のグループとを含む。第３または第４のオペレーティングシステムを動作させるノードが存在していてもよい。本発明の原理は明らかに、ユーザの必要性に応じてこの環境にオペレーティングシステムを追加する柔軟性を含んでいる。各ノードは、それに関連付けられた少なくとも２つのリソースマネージャを有する。第１のリソースマネージャ２０４は、第１のオペレーティングシステムを実行するノード上のワークロードを管理するように構成される。第２のリソースマネージャ２１４は、第２のオペレーティングシステムを実行するノード上のワークロードを管理するように構成される。上記で述べたように、様々なタイプのオペレーティングシステムの数に応じて、第３、第４のリソースマネージャ、場合によってはさらに多くのリソースマネージャが存在してもよい。さらに、同じタイプのオペレーティングシステムに対して異なるリソースマネージャもむろん存在してよい。例えば、一部のＬｉｎｕｘベースのノードがＬＳＦを介してワークロードマネージャと通信することができる一方、他のＬｉｎｕｘベースのノードがＴＯＲＱＵＥなどを介してそのワークロードマネージャと通信することができる。エンドユーザに対して透過的になり得る柔軟性レベルは、本明細書の開示により所望のレベルにすることができる。機能２２２は、本明細書の開示のインテリジェンスに相当する。これは、リソースマネージャとワークロードマネージャの間のインターフェースを動作させることができ、あるいはワークロードマネージャの変更形態であってもよい。基本的に、コンピューティング環境内部でジョブを受け取り、リソースを実際に消費するプロセス全体の特定の位置において、その環境でリソースを実際に効率的に消費するために、互いに通信する各種モジュールの特定の機能がどこで行われるかは問題ではない。したがって、モジュール２２２は、ワークロードマネージャ２２４と２つ以上のリソースマネージャ２０４、２１４との間のインターフェースを総称して表す。

図３はさらに、各ノードと関連付けられた複数のリソースマネージャを使用する一般的な適用例を示す。この場合、第１のリソースマネージャ２０４および第２のリソースマネージャ２１４との通信リンクを有するノード３０２が示されている。同様に、それぞれのリソースマネージャへの通信リンクを有するノード３０４および３０６がそれぞれ示されている。各リソースマネージャはインターフェース２２２を介してワークロードマネージャ２２４と通信する。

当技術分野で周知のように、リソースマネージャは実際に、コンピューティング環境におけるリソースとリソースを消費するジョブとを監視し、ワークロードに対しても動作を行う。リソースマネージャは、特定のノード上のジョブの取り消しプロセスまたは開始プロセスの管理を実際に行なうはずである。ＭＯＡＢなどのワークフロー管理ソフトウェアが、その環境でどのようにワークロードを実行すべきかリソースマネージャに指示する。本発明は一般に、１つまたは複数のリソースマネージャと交信するインターフェースであって、バッチシステム自体が特定のジョブに特定のオペレーティングシステムが必要であるとインテリジェントに判定する能力を可能にするインターフェース２２２の構築に関する。インターフェース２２２は、全体または一部分をワークロードマネージャ２２４に組み込むことができる。この場合、システムはその特定オペレーティングシステムを動的にプロビジョニングし、必要なら、１つのノードを第１のオペレーティングシステムの実行から第２のオペレーティングシステムへ戻し、それと同時に第２のオペレーティングシステムと関連付けられたリソースマネージャからの状態情報をアクティブ状態にするか、呼び出すか、あるいはそれと異なる形で処理し、次いでそのジョブをユーザに対して透過的に実行する。このプロセスでは、プロビジョニングが行われるとノードがダウン中といった状態信号などの信号を第１のオペレーティングシステムと関連付けられたリソースマネージャが送信し始めることから、リソースマネージャ２０４、２１４からの競合レポート間での変換、競合の緩和および管理が必要となる。しかしながら、ノードがプロビジョニングされた第２のオペレーティングシステムと関連付けられているリソースマネージャは、そのノードがアップ状態で、特定の属性を有し、ワークロードを消費できる状態にあるという信号を送信開始することになる。したがって、インターフェース２２２は、エンドユーザが単に一般的な周知のインターフェースを介してコンピューティング環境にノードを投入するだけで、ハイブリッド型のコンピューティング環境内部のリソースを透過的な形でワークロードに消費させることができるように競合情報を緩和、管理する。

一態様では、「ダウン」中のノード（すなわち別のオペレーティングシステムがそのノード上にプロビジョニングされている）からの信号が、その潜在的な情報を上記ダウン中ノードの課金履歴情報と今後プロビジョニングできるオペレーティングシステムの識別に役立つ情報に利用できるよう、インテリジェントにプールされる。

デュアルブートは、以前は手動プロセスであった。バッチ環境またはデータセンタ環境ではめったに使用されず、ユーザにとってはかなり静的なエクスペリエンスになる。例えば、一般に、デュアルブートエクスペリエンスとは、複数のオペレーティングシステムを単一のコンピュータにインストールし、次いで、ユーザが起動するときに、どのオペレーティングシステムで起動するか選択する能力を可能にすることである。本発明は、手動プロセスではなく、バッチ環境またはデータセンタ環境の効率的な実行に必要な様々なモジュールおよびソフトウェアを伴なう自動化されたプロセスであることから、それとは異なる。一態様では、一定の構成または要件でジョブを投入する場合に、適切な環境を実行するようにオンデマンドリソースを切り替え、再プロビジョニングできるように、ポリシーまたはインテリジェンスをシステムすなわちユーザが解析することができる。例として、Ｗｉｎｄｏｗｓジョブが投入され、システムが十分なＷｉｎｄｏｗｓノードを検出できない場合、システムはＷｉｎｄｏｗｓノードを自動的にプロビジョニングし、次いでその新たにプロビジョニングされたリソースを消費するように、その環境に上記ジョブを投入することができる。

他の態様を、ハイブリッド型の環境のインテリジェントな管理に用いることもできる。例えば、管理者は自分で、特定のタイプのオペレーティングシステムで一定数のノードを維持すると決定することができる。このとき、これまでシステムが第１のオペレーティングシステムから第２のオペレーティングシステムへ再プロビジョニングされるノードを有している場合、そのシステムは、一定のオペレーティングシステムを実行する一定数のノードを維持するポリシーに従うように、ハイブリッド型の環境内で他のノードを自動的に再プロビジョニングすることができる。ポリシーは、任意の目的のために確立し、それに従うことができる。例えば、サービスレベルアグリーメント（ＳＬＡ）ごとにＱｏＳを維持するには、時刻に基づいた顧客Ｘに対する一定数のノードなどがある。ハイブリッド型の環境では、リソースの管理に関連した任意のポリシーを確立し、それに従うことができる。ユーザ／グループに対して特定のオペレーティングシステムを実行するノードの数とワークロードサービスレベルのバランスを取ることができる単一の自己最適化システムによって、システムはワークロードスループットを最大限にすることができる。

ポリシーは、計算リソース、ネットワークリソースまたはその他のリソースの障害と関連付けられたフォールトトレランスポリシーもしくは高可用性ポリシーであってもよい。そういったポリシーは、かかる要件を処理するため、またはオンデマンドリソースを利用できるようにするためにプールに対して再プロビジョニングを行い、特定のワークロードについてプロビジョニングを行うが、違反または閾値スケジューリングの要件の状況処理についてもプロビジョニングを行う。再プロビジョニングは、予測される閾値違反またはポリシー要件違反に対して行われてもよい。その例は、必要なオンデマンド環境などの、解析に基づくとポリシー要件の違反が存在する可能性があると予測される場合や、障害、現在のワークロード問題、予測されるワークロード問題などのいくつかのイベントに基づいて、サービスレベルアグリーメントの特定のパラメータが満たされない場合である。したがって、自動再プロビジョニングを、予測される障害またはその他の予測イベントに先んじてそのイベントが行われないように行うことができ、実施することができる。任意の特定のインスタンスにおいてポリシーまたはサービスレベルアグリーメントを満たし、それを維持するように、必要なリソースがプロビジョニングされ、準備される。これの別の例は、ポリシーまたはサービスレベルアグリーメントを違反する可能性がある一定の今後のイベントの予測を特定するために、履歴の情報だけでなく、環境と今後のワークロードを監視するものである。かかる事例では、システムは、再プロビジョニングが行われないときの予測されるイベントの発生を回避するために、再プロビジョニングをトリガできるシステムジョブやその他の種類のプロビジョニング命令などの命令を実行または自動投入する。

コンピューティング環境を管理する他の態様を用いることもできる。例えば、管理者またはポリシーを、一定のタイプの応答時間を可能にしたり、一定のスループットを可能にしたり、一定の実行基準を用いてバックログを管理したりなどするように確立することができる。例えば、バックログが特定のターゲットの上または下に生じた場合、システムは、ノードの再プロビジョニングを自動的に開始して、所望のパラメータに従ってバックログを処理し、特定のバランスを再確立することができる。例えば、ユーザが異なるオペレーティングシステムを実行するノードからなる２つのグループの間で比例バランスを維持したい場合などがある。管理者は、ハイブリッド型の環境でＷｉｎｄｏｗｓジョブがＬｉｎｕｘベースのジョブよりも２０％だけ長く待機し、各種ノード上でオペレーティングシステムのバランスを絶えず取ってそのポリシー要件を維持するように確定することができる。

本発明の能力によると有益である別の態様は、システムが保守をスケジュールできるものである。例えば、ハイブリッド型の環境全体を停止させる代わりに、システムは実際に、ジョブをプロビジョニングステップとしてスケジュールすることができる。ワークロードマネージャは、消費ジョブ間のオペレーティングシステム切り替え動作を、それがシステムに対して最低限の影響を有するようにインテリジェントに配置し、現在および今後の消費ジョブをスケジュールすることができる。これらのジョブは、インテリジェンスを内部的に使用して階層的なスケジューリングに関する情報を提供する動的なサービスジョブによって、実現することができる。この階層的なスケジューリングでは、各ジョブの一番上にシステムがジョブをスケジュールでき、その環境内部の特定のリソースプールをポリシーに従って増減させることができる。こういった動的なサービスジョブの一番上に、実行中の実際のコンピューティングジョブが含まれる。したがって、ジョブまたはシステムジョブと関連付けられたプロビジョニングステップの投入を、本明細書に開示する原理を利用して実現することができる。

さらに、任意のカレンダー設定や、ハイブリッド型環境における混成の実行を可能にするための固定予約機能に重畳させる、一定時間枠にわたる環境構成方法の決定など、他の態様を用いることができる。例えば、標準ポリシー下で構成されるよりも多くのＬｉｎｕｘベースのノードを必要とする特定のジョブ（テレビ局用の天候解析など）のための固定予約があるなどの理由により、システムは、その環境の一定の再プロビジョニングを土曜日の朝の午前２：００に開始して、ＷｉｎｄｏｗｓオペレーティングシステムとＬｉｎｕｘオペレーティングシステムの間のバランスを変更することができる。したがって、このハイブリッド型の環境の管理により、任意のタイプの任意のイベントでプロビジョニングをトリガすることが可能になる。Ｃｙｂａｓｅ（登録商標）データベースサーバがダウン状態になり、このときポリシーが、１つのノードプールに他のプールとは対照的にもう４つのノードを追加するようシステムに要求すると、任意のイベントによってトリガできる任意の種類のプロビジョニング動作を実行するジョブまたは命令を実施することができる。

本明細書の開示の１つの利点は、エンドユーザからみて、あるいは管理者またはマネージャからみて、そのマネージャが単一の統合リソースを利用できることである。このマネージャは、ワークロードマネージャ２２４であってよく、人との対話を非常に簡略化／省いてハイブリッド型の環境の高度に柔軟性を有する効率的な利用を実現するために、ポリシー空間、単一の統合課金空間および単一の管理空間を結合することができる。さらに、エンドユーザは、誰からでも統一された状態に見え、プロビジョニング技術をやはり利用する、そのワークロード全てに対する単一の共通投入／ジョブ管理空間を有することができる。したがって、Ｗｉｎｄｏｗｓ投入のツールを有するユーザは、そのＷｉｎｄｏｗｓ投入ツール（エンドユーザ用Ｌｉｎｕｘ投入ツールと異なってもよい）を継続して使用することができ、そのどちらを用いても、こういった各ユーザにとって使い馴れたインターフェースからハイブリッド型のコンピューティング環境へアクセスすることができる。

さらに、ユーザは、アプリケーションプログラミングインターフェース（ＡＰＩ）、コマンドライン、ウェブベースもしくは標準のデスクトップＧＵＩを使用することができ、選択すれば、ワークロードマネージャ全体をバイパスすることによって、リソースマネージャに直接、継続して投入を行うこともできる。他の利点は、本明細書に開示する手法には無駄なサイクルが無いことである。オペレーティングシステムが双方向に自動的に切り替えられることから、オペレーティングシステムが利用されていないサイクルがなくなる、または少なくなるはずであるので、無駄なサイクルが無い。例えば、しばしば、ユーザにとっては、ジョブがどの種のオペレーティングシステムを求めているのか分からず、ジョブの混成がどのようなものになるのか管理者は分からず、したがって、ジョブの混成が同時刻に日々刻々と変化していくのかどうかも分からないという懸念がある。これらは、管理者共通の課題である。しかしながら、本明細書に開示する原理によるインターフェースまたはワークロードマネージャを使用すると、管理者のこの種の懸念を軽減するために、システムが自動的にプロビジョニングを実現し、ワークロードを解釈することができる。

本明細書の原理を利用して環境を制御する機構および機会は無数にある。例えば、ワークロードマネージャがクラスタを自動的に適合する速度をユーザが指定することができる。例えば、１時間に１度、１分に１度、日に１度、週に１度、検出されたイベントに基づいてなど、システムにそれ自体を最適化するようワークロードマネージャで指定することもできる。これに関して、システムは指定した時間に、リソースの消費と関連付けられた履歴、ジョブの投入と関連付けられた履歴、現在のワークロード、現在のネットワーク環境パラメータを評価し、環境と関連付けられた性能マトリックスにおいて最適なバランスをもたらすことができる調節を行うことができる。したがって、第１のオペレーティングシステムを動作させるノードと第２のオペレーティングシステムを動作させるノードとの厳密なバランスを設定するのではなく、第１のオペレーティングシステムを動作させるノードと第２のオペレーティングシステムを動作させるノード（または第３のオペレーティングシステムと第４のオペレーティングシステムも）の比率のバランスをその評価に応じてとる際に、システムが柔軟に対応できるようにする一定のパラメータを最適化するように、ポリシーを確立することができる。したがって、この環境において最適なバランスを実現するために、一定時刻または可変時刻に、使用履歴、現在の活動および保留中のワークロードを全て評価することができる。

上記で述べたように、１つのオペレーティングシステムから別のオペレーティングシステムへ切り替える場合、システムは、仮想化、ディスクフルまたはディスクレスプロビジョニング、あるいは１つのオペレーティングシステムから別のオペレーティングシステムへの切り替えを含むことができるその他任意の周知の機構を使用することができる。ワークロードマネージャは、好ましくはシステムジョブを使用して、プロビジョニング動作をスケジュールする。システムジョブは、例えばノード１３をＷｉｎｄｏｗｓオペレーティングシステムからＬｉｎｕｘオペレーティングシステムへ切り替えるように指示することができる。ただし、システムは、Ｗｉｎｄｏｗｓ環境でもう７分間実行するジョブがあることを認識しているので、このジョブを７分間で開始するようスケジュールすることになる。このスケジュールされるシステムジョブは、システムに対して、その時間に特定のイメージで再起動するよう、または特定のイメージでネットブートするよう、あるいはプロビジョニング動作を実際に開始してオペレーティングシステムを新しいイメージに実際に再インストールするよう指示する操作である。この例では、当初のジョブが完了し、その後のシステムジョブが開始され、実際に変更を行う。ＷｉｎｄｏｗｓからＬｉｎｕｘへ切り替える変更が行われると、ＣＣＳデーモンなどのノードデーモンは、この時点でＬｉｎｕｘオペレーティングシステムが実行中のためもう動作していないことから、ダウン状態であると報告される。ＣＣＳは引き続き、ワークロードマネージャにノードがダウン状態であると報告するが、ワークロードマネージャは、現在アップし、実行中であることを報告するＬｉｎｕｘオペレーティングシステムと関連付けられた、異なるリソースマネージャと通信することから、上記状態情報信号を解釈、無視、またはプールするのに十分なインテリジェンスを有する。つまり、ワークロードマネージャへのインターフェースまたはワークロードマネージャは、複数のリソースマネージャと通信するインテリジェンスを有し、どのリソースマネージャを信頼すべきか判断する。したがって、本明細書に開示する特殊な設定およびインテリジェンス設定を使用するワークロードマネージャは、適切なリソースマネージャにのみに注目する。したがって、新たにプロビジョニングされた１つまたは複数のノードに引き続きジョブの投入を可能にするために、全ての状態情報、属性情報、および新たにプロビジョニングされたノードと関連付けられたリソースマネージャを介して情報を提供するその他のあらゆるものが伝達され、インテリジェントに利用される。

したがって、本発明の重要な態様は、エンドユーザおよび管理者にとってシームレスであるような形でオペレーティングシステムを切り替える時がきたことを示すために、適切に構成されたシステムジョブのスケジュールを通知し、全ての「ダウンノード」を隠蔽し、全ての属性を再マッピングし、その変更された環境全体にわたる全ての課金統計情報を保持することである。

これらの原理を考慮して、次に、図４について説明する。図４は、少なくとも１つのノードが第１のリソースマネージャによって制御される第１のオペレーティングシステムを有し、少なくとも１つのノードが第２のリソースマネージャによって制御される第２のオペレーティングシステムを有する、ハイブリッド型のマルチノードコンピューティング環境においてワークロードを管理する方法を示している。上記方法は、第１のオペレーティングシステムと第２のオペレーティングシステムの間のコンピューティング環境においてノードのバランスを取る、ポリシー確立ステップ（４０２）と、上記確立されたポリシーとの上記コンピューティング環境の整合性を判定するために、そのコンピューティング環境を周期的に解析するステップ（４０４）と、上記確立されたポリシーに従って、少なくとも１つのノードを上記第１のオペレーティングシステムから上記第２のオペレーティングシステムに変更、または少なくとも１つのノードを上記第２のオペレーティングシステムから上記第１のオペレーティングシステムに変更するために、上記解析に基づいて上記コンピューティング環境のノードをプロビジョニングするステップ（４０６）とを含む。上記解析は、使用履歴、現在の活動、保留中のワークロードおよび予想される必要条件のうちの少なくとも１つに基づいて行うことができる。予想されるポリシーの欠陥または違反などの、その他の要素によっても再プロビジョニングをトリガすることができる。例えば、予想される必要条件は、リソースの消費に対する既存のおよび／または予想される予約に従って予測されるワークロードの必要条件を基にすることができる。予想される必要条件は、ワークロードまたは予測されるワークロードに関連していなくてもよい。例えば、特定のアーキテクチャが、特定の今後の目的のために上記コンピューティング環境で必要になってもよい。したがって、今後の必要条件が、今後の環境または構造のプロビジョニングに関連していてもよい。例えば、環境が、試験、ベンチマーキング、障害解析、保守、あるいはバッチ処理と異なる任意の特定の用途に必要になってもよい。上記環境がまた、データセンタサービスまたは継続的なサービスを提供するために必要になってもよい。他のポリシーの例は、個別のパーティションごとに応答時間タイプと関連付けられたバックログの量に基づいて、負荷バランスを提供することである。応答時間は、スループット、負荷、カレンダー、特定の選択可能なワークロード、障害などに関連していてもよい。したがって、１つまたは複数のポリシーが、幅のある数の要素に関連し得る。上記プロビジョニングが、プロビジョニングポリシーに従って少なくとも１つのノードをプロビジョニングするようリソースマネージャに指示するシステムジョブを、ワークロードマネージャが発行することによって行われると好ましい。上記プロビジョニングポリシーにより、システムジョブが、スケジュールされたコンピューティングジョブの合間に少なくとも１つのノードをプロビジョニングしてもよい。これには、プロビジョニングできるようになる消費ジョブの完了まで、システムジョブが場合により７分間待機するという上記に述べた例がある。

プロビジョニングを可能にするように、コンピューティングジョブの予約またはバランスを調節することができる上記の他の態様があってもよい。例えば、１つのコンピューティングジョブが現在処理中で、１０分間のうちに完了するようにスケジュールされ、別のコンピューティングジョブが、今から１１分間で開始するようにスケジュールされていると仮定する。システムジョブと関連付けられたプロビジョニングは、オペレーティングシステムの切り替えに３分を必要とするはずである。このとき、この方法は、システムジョブと関連付けられたプロビジョニングの完了に必要な時間を活用するために、スケジュールされたコンピューティングジョブに対してわずかな変更を実行するステップを伴ってもよい。したがって、システムジョブは、現在適所にある全てのワークロードポリシーに従うプロビジョニングをスケジュール、管理するための機構として使用される。これにより、この環境に対して確立された全てのポリシーに従うプロビジョニングを実現する、統合された方法が提供される。

本発明の別の態様では、複数のノードを有するハイブリッド型のコンピューティング環境において、ノードをワークロードに対して動的にプロビジョニングする方法が開示される。動的なコンピューティング環境では、各ノードが、第１のオペレーティングシステムを有する第１のリソースマネージャおよび第２のオペレーティングシステムと関連付けられた第２のリソースマネージャと通信する。この方法は、図５に示されている。この方法は、ハイブリッド型のコンピューティング環境の少なくとも１つのノードを第１のオペレーティングシステムから第２のオペレーティングシステムへプロビジョニングする命令を、ワークロードマネージャまたはその他のソフトウェアもしくはハードウェアコンポーネントもしくはモジュールから受けるステップ（５０２）を含む。第２のオペレーティングシステムをプロビジョニングした後、上記システムは、上記少なくとも１つのノードと関連付けられた第１のリソースマネージャからの少なくとも１つの信号を、インテリジェントにフィルタリング、プール、または無視し（５０４）、上記少なくとも１つのノードと関連付けられた第２のリソースマネージャからの少なくとも１つの信号を処理する（５０６）。複数のリソースマネージャが、同じ物理的なオブジェクトすなわちノードの２つの異なる状態を同時に報告する場合、１つはアクティブ状態、１つは非アクティブ状態であるはずであることから、それらは競合している。上記システムは、他のデータと競合している一定のデータを無視するインテリジェンスを有する。したがって、上記システムは、非アクティブなリソースマネージャからの一定の信号を、インテリジェントにフィルタリング、プール、または無視すべきことを認識している。例えば、状態情報は、アクティブなリソースマネージャにとっても非アクティブなリソースマネージャにとっても重要である。その他のデータには、各ノードと関連付けられた、ならびに各ノードの１つまたは複数リソースマネージャと関連付けられた、特徴、能力、クエリー、属性、ポリシー、ルールセットが含まれる。したがって、無効のオペレーティングシステムには、構成や、能力、サポートされているオペレーティングシステム、ノードがどのソフトウェアおよびオペレーティングシステムに切り替わるかまたはプロビジョニングできるかなどの、いくつかの情報がやはり必要である。上記インテリジェントなフィルタリングは、非アクティブなノードの信号と、履歴、課金、再プロビジョニング情報のデータをプールするステップを伴うと好ましい。このプールは、ダウンノードのレイテンシプールと呼ぶことができる。レイテンシプールは、そのプール（および特定のリソースマネージャ）と関連付けられたオペレーティングシステムがノードに対してプロビジョニングされるかどうかに応じて、潜在的状態からアクティブ状態に切り替わることができる。

上記システムは、インテリジェンスを有するワークロードマネージャがノードについて別の環境に切り替えるかどうか識別でき、それが適正な判断かどうか識別するためにその環境と関連付けられた属性、ポリシーおよび制約を収集できるように、継続すべき属性を特定する。ただし、ワークロードマネージャは、この情報収集物が、ノードの属性、ポリシーおよび制約に関する潜在的な情報であることを認識している。この情報は、適切なプロビジョニングが行われた後に初めて、環境に作用すると認識されている。これに関して、上記システムは、そのノードを再プロビジョニングするのが適当だと判定した場合にアクセスできる情報を、潜在情報プールに概念的に配置する。プロビジョニングが適切なステップであるかどうか、その後のワークロードが特定のノードに適合するかどうかに関連する一部分の評価のための属性情報は、リダイレクトされ、分離される。１つの例では、上記システムは、可能なイメージまたは可能なリソースバージョンのリストを生成する。上記システムは、１つのノードがアクティブ状態であることを、現在のオペレーティングシステム、ジョブキュー、特徴／ポリシーのセット（これらの全てが、ノードのリソースを消費するワークロードに対してアクティブな状態にある）と共に識別する。しかし、上記システムが切り替えを行って、そのノードを異なった形でプロビジョニングをした場合、その新しいノードは、新しいオペレーティングシステムを受け取るが、レイテンシプールからのものである属性、ポリシーなどの他の収集物も受け取る。したがって、各潜在的なオペレーティングシステムごとに、こういった属性プールリストをシステムは維持する。各ノードは、１つ、２つ、３つ以上の情報レイテンシプールを有することができる。

このとき、上記コンピューティング環境は、第２のオペレーティングシステムがプロビジョニングされた少なくとも１つのノードと関連付けられたリソースを消費することができる（５０８）。上記のように、ワークロードマネージャは、少なくとも１つのノードと関連付けられた第１のリソースマネージャから、少なくとも１つの信号を受信し、インテリジェントにフィルタリングまたはレイテンシプールにプールすることができ、次いで、第２のリソースマネージャからの少なくとも１つの信号を処理して、第２のオペレーティングシステムがプロビジョニングされた少なくとも１つのノード上のリソースの消費を管理することができる。こういった信号は、オペレーティングシステムを切り替えるときのそのノードの状態、属性、ポリシーおよび制約に関連する。上記システムは、レイテンシプールからアクティブなプールへとデータを利用開始し、解放されるオペレーティングシステムからレイテンシプールへデータをプール開始する。したがって、上記システムは、レイテンシ情報プールとアクティブな情報プールを切り替える方法を認識している。ノードがプロビジョニングされ、アクティブな情報プールがそのノードと関連付けられると、ワークロードがその空間にスケジュールされ始める。システムが変更ステップまたはノードのプロビジョニングステップをスケジュールした場合は、その変更ワークロードと関連付けられたステップが、属性プールに変化をもたらすと常に解釈される。

一態様では、第２のオペレーティングシステムまたは第１のオペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔオペレーティングシステムであってよい。上記方法はさらに、属性を再マッピングするステップと、第１のオペレーティングシステムから第２のオペレーティングシステムへ課金統計情報を保持するステップを含むことができる。これに関して、上記システムは、属性を再マッピングする場合、統計情報を無視しない。上記システムは、上記システムが特定のリソースまたは特定のノードの統計情報の視点をそのライフサイクル全体にわたって維持できるように、物理的なノードの統計情報だけでなくオペレーティングシステムレベルの統計情報を維持する。したがって、そのライフサイクルおよびオペレーティングシステム間の切替えの間一貫して特定のノードとして、上記システムは、そのライフサイクル全体にわたってそのリソースの使用の解釈を維持することができる。別の態様では、上記方法は、第１のリソースマネージャおよび第２のリソースマネージャからの様々な情報と関連付けられた、変換、競合緩和および競合管理を実行するステップを含む。これは、各リソースマネージャが情報をわずかな差の形でいかに報告するかに関連付けられる。例えば、Ｍｉｃｒｏｓｏｆｔオペレーティングシステムと関連付けられたリソースマネージャは、Ｌｉｎｕｘオペレーティングシステムと関連付けられる可能性のあるリソースマネージャから、様々なパラメータによる属性および統計情報を報告することができる。したがって、ワークロードマネージャの意思決定ポリシーが、ワークロードの割り当てだけでなく今後のプロビジョニングの判定の基になる共通の属性を有するように、サービスを実行するインテリジェント層が、ワークロードマネージャ２２４内またはインテリジェントなフロントエンド層２２２に構築される。つまり、ワークロードマネージャから見た視点が一貫するように様々な属性が調和または標準化されるように、フィルタリングと処理を行うことができる。この簡単な例は、１つのワークロードマネージャがメートル単位系に従って統計情報および属性を報告し、別のリソースマネージャがヤードポンド単位系に従って統計情報を報告するとすると、最終的にワークロードマネージャからみた統計情報が標準化され、したがって一貫するように、その情報を整合させる必要があるといった場合である。明らかに、これは、多様な統計情報をどのように調和できるかという点における概念上の例である。

本明細書の開示の態様により、ワークロードマネージャまたは別のインターフェースが、単一の統合リソース空間、単一の統合ポリシー空間および単一の統合課金空間を使用して、単一の統合管理空間も存在するように、ハイブリッド型のコンピューティング環境のワークロードを管理することが可能になる。したがって、本明細書の開示の目的は、ワークロードを投入／管理／監視する単一の方法が単一のインターフェースを使用するマネージャすなわち管理者と、全てのポリシーが定義／構成／制御／最適化される単一の空間と、イメージおよびコンピューティング環境が絶えず変化し、各種ノードが異なるオペレーティングシステムに再プロビジョニングされているところで、その時点でそれらがそれまで動作していたにもかかわらず、課金処理のための記録が保たれる単一の空間とを有する、簡易化された環境を提供することである。したがって、本発明により、共通性が存在できるようになり、上記の空間全てのスーパーセットを管理することができる。

仮想化の場合、リソースマネージャへ伝えられる状態データが、基本的に本明細書に開示されるように動作する。各オペレーティングシステムからの全てのデータが全体的に、その空間内部に存在する。したがって、第１のオペレーティングシステムは、Ｌｉｎｕｘであってよく、データをそれに関連付けられたリソースマネージャへ伝える。第１のシステムの上層に重ねられた第２のオペレーティングシステムがまた、そのデータをそのリソースマネージャへ伝える。

一態様では、仮想化におけるホストオペレーティングシステムは、別個のリソースマネージャを保持しない。この場合、各階層化されたオペレーティングシステムがそれぞれリソースマネージャを有する。交互に、監視専用リソースマネージャが、ホストオペレーティングシステムと通信することができる。この監視専用リソースマネージャは、ノードが動作状態、健全、作業／仮想化可能などの基本的な情報を報告するはずである。監視専用リソースマネージャは、ノードへのワークロードの投入には使用されず、そのワークロードの変更または操作に使用されない。監視専用レポートは、ノードのヘルスチェックと、仮想化が良好であるというレポートに関連する。仮想化は、Ｗｉｎｄｏｗｓ Ｓｅｒｖｅｒ ２００８内に含まれるＨｙｐｅｒ−Ｖ、ＶＭＷａｒｅ（登録商標）、Ｘｅｎを使用して、あるいは周知のその他の手法を介しても、利用することができる。

プロビジョニング用リソースマネージャを、ノード上のオペレーティングシステムの実際のプロビジョニングまたは変更や、新たにプロビジョニングされたノードのためのソフトウェアスタックの変更などの管理に、ワークロードマネージャが使用することができる。

本発明の範囲内にある実施形態は、保存されたコンピュータで実行可能な命令またはデータ構造を担持すなわち有するためのコンピュータ可読媒体を含むこともできる。かかるコンピュータ可読媒体は、汎用または特殊用途のコンピュータからアクセスできる、任意の入手可能な媒体であってよい。限定するのではなく一例として、かかるコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくはその他の光ディスク記憶装置、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または、コンピュータで実行可能な命令もしくはデータ構造の形での所望のプログラムコード手段の担持もしくは保存に使用できるその他任意の媒体を備えることができる。ネットワークまたは他のコンピュータ通信接続（有線、無線、またはその組合せ）を介して、コンピュータに情報が転送または提供されると、そのコンピュータは、その接続をコンピュータ可読媒体と適切にみなす。したがって、かかる任意の接続は、然るべくコンピュータ可読媒体と呼ばれる。上記の組合せもまた、コンピュータ可読媒体の範囲内に含まれるべきである。

コンピュータで実行可能な命令は、例えば、汎用コンピュータ、特殊用途のコンピュータ、または特殊用途の処理装置に一定の機能または機能グループを実行させる命令およびデータを含む。コンピュータで実行可能な命令はまた、スタンドアロンまたはネットワーク環境でコンピュータによって実行されるプログラムモジュールを含む。一般に、プログラムモジュールは、特定のタスクを実行、または特定の抽象データ型を実装する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。コンピュータで実行可能な命令とそれに関連付けられたデータ構造、およびプログラムモジュールは、本明細書に開示する方法の各ステップを実行するプログラムコード手段の例になる。かかる実行可能な命令またはそれに関連付けられたデータ構造の特定のシーケンスは、それに対応する、かかるステップに記述された機能を実施するための動作の例になる。プログラムモジュールはまた、コンピュータ可読媒体に含まれるプログラムの命令に基づく特定の機能を実行するように動作している場合、本明細書に開示する様々なハードウェアコンピュータコンポーネントと接続して、任意の実体のあるコンピュータ可読媒体を備えることができる。

本発明のその他の実施形態が、数多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境で実施でき、パーソナルコンピュータ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な民生用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含むことが当分野の技術者には理解されるであろう。各実施形態はまた、通信ネットワークを介してリンクされた（有線リンク、無線リンク、またはその組合せ）タスクがローカルおよびリモート処理装置によって実行される分散コンピューティング環境で、実施することもできる。分散コンピューティング環境では、プログラムモジュールをローカルとリモートのメモリ記憶装置に配置することができる。

上記の説明は、特定の詳細を含む場合があるが、それらは特許請求の範囲を何らかの形で限定すると解釈すべきではない。本発明の説明した実施形態のその他の構成は、本発明の範囲の一部分である。したがって、本発明を定義するのは、所与の特定の例ではなく、添付の特許請求の範囲およびその法的均等物のみであるべきである。

Claims (20)

1. 少なくとも１つのノードが第１のリソースマネージャによって制御される第１のオペレーティングシステムを有し、少なくとも１つのノードが第２のリソースマネージャによって制御される第２のオペレーティングシステムを有する、ハイブリッド型のマルチノードコンピューティング環境でワークロードを管理する方法において、
   前記コンピューティング環境の前記第１のオペレーティングシステムと前記第２のオペレーティングシステムの間でノードのバランスを取る、ポリシー確立ステップであって、前記第１のオペレーティングシステムおよび前記第２のオペレーティングシステムがノードのハードウェアで直接実行されるステップと、
   前記確立されたポリシーとの前記コンピューティング環境の整合性を判定するために、該コンピューティング環境を周期的に解析するステップと、
   前記確立されたポリシーに従って少なくとも１つのノードを、前記第１のオペレーティングシステムから前記第２のオペレーティングシステムへ、または前記第２のオペレーティングシステムから前記第１のオペレーティングシステムへ変更するために、前記解析に基づいて、前記コンピューティング環境のノードをプロビジョニングするステップとを含む方法。
2. 前記解析は、使用履歴、現在の活動、保留中のワークロードおよび予想される必要条件のうちの少なくとも１つに基づいている、請求項１に記載の方法。
3. 前記少なくとも１つのノードをプロビジョニングポリシーに従ってプロビジョニングするシステムジョブをワークロードマネージャが発行することによって、プロビジョニングが行われる、請求項１に記載の方法。
4. 前記プロビジョニングポリシーにより、前記システムジョブは、スケジュールされたコンピューティングジョブの間に前記少なくとも１つのノードをプロビジョニングする、請求項３に記載の方法。
5. 前記プロビジョニングが、仮想化、ディスクフルプロビジョニング、ディスクレスプロビジョニングまたはデュアルブートを使用して実行される、請求項１に記載の方法。
6. 前記プロビジョニングノードにユーザソフトウェアスタックをロードするステップをさらに含む、請求項１に記載の方法。
7. 少なくとも１つのノードが第１のオペレーティングシステムと関連付けられた第１のリソースマネージャと通信し、少なくとも１つのノードが第２のオペレーティングシステムと関連付けられた第２のリソースマネージャと通信する、複数のノードを有するハイブリッド型のコンピューティング環境で、ノードをワークロードに対して動的にプロビジョニングする方法において、
   ハイブリッド型のコンピューティング環境の少なくとも１つのノードを前記第１のオペレーティングシステムから前記第２のオペレーティングシステムへプロビジョニングする命令を、ワークロードマネージャから受け取るステップであって、前記第１のオペレーティングシステムおよび前記第２のオペレーティングシステムがノードのハードウェアで直接実行されるステップと、
   前記第２のオペレーティングシステムをプロビジョニングした後、前記少なくとも１つのノードと関連付けられた前記第１のリソースマネージャからの少なくとも１つの信号をプールするステップと、
   前記少なくとも１つのノードと関連付けられた前記第２のリソースマネージャからの少なくとも１つの信号を処理するステップと、
   前記第２のオペレーティングシステムがプロビジョニングされた前記少なくとも１つのノードと関連付けられたリソースを消費するステップとを含む方法。
8. 前記ワークロードマネージャは、前記少なくとも１つのノードと関連付けられた前記第１のリソースマネージャから前記少なくとも１つの信号を受け取り、レイテンシプールにプールする、請求項７に記載の方法。
9. 前記ワークロードマネージャは、前記第２のオペレーティングシステムがプロビジョニングされた前記少なくとも１つのノード上のリソースの消費を管理するために、前記第２のリソースマネージャからの前記少なくとも１つの信号を処理する、請求項８に記載の方法。
10. 前記第２のオペレーティングシステムは、Ｍｉｃｒｏｓｏｆｔオペレーティングシステムである、請求項７に記載の方法。
11. 前記第１のオペレーティングシステムから前記第２のオペレーティングシステムへ属性を再マッピングし、課金統計情報を保持するステップをさらに含む、請求項７に記載の方法。
12. 前記第１のリソースマネージャおよび前記第２のリソースマネージャからの異なる情報と関連付けられた変換、競合緩和および競合管理をさらに含む、請求項７に記載の方法。
13. 単一の統合リソース空間、単一の統合ポリシー空間、単一の統合課金空間および単一の管理空間を使用して、マネージャは、前記ハイブリッド型のコンピューティング環境におけるワークロードを管理する、請求項７に記載の方法。
14. ハイブリッド型のマルチノードコンピューティング環境でワークロードを管理するためにコンピューティングデバイスを制御するための命令を保存するコンピュータ可読媒体において、少なくとも１つのノードが第１のリソースマネージャによって制御される第１のオペレーティングシステムを有し、少なくとも１つのノードが第２のリソースマネージャによって制御される第２のオペレーティングシステムを有し、前記命令は、
    前記コンピューティング環境の前記第１のオペレーティングシステムと前記第２のオペレーティングシステムの間でノードのバランスを取る、ポリシー確立ステップであって、前記第１のオペレーティングシステムおよび前記第２のオペレーティングシステムがノードのハードウェアで直接実行されるステップと、
    前記確立されたポリシーとの前記コンピューティング環境の整合性を判定するために、該コンピューティング環境を周期的に解析するステップと、
    前記確立されたポリシーに従って少なくとも１つのノードを、前記第１のオペレーティングシステムから前記第２のオペレーティングシステムへ、または前記第２のオペレーティングシステムから前記第１のオペレーティングシステムへ変更するために、前記解析に基づいて、前記コンピューティング環境のノードをプロビジョニングするステップとを含む、コンピュータ可読媒体。
15. 前記解析は、使用履歴、現在の活動、保留中のワークロードおよび予想される必要条件のうちの少なくとも１つに基づいている、請求項１４に記載のコンピュータ可読媒体。
16. 前記少なくとも１つのノードをプロビジョニングポリシーに従ってプロビジョニングするシステムジョブをワークロードマネージャが発行することによって、プロビジョニングが行われる、請求項１４に記載のコンピュータ可読媒体。
17. 前記プロビジョニングポリシーにより、前記システムジョブは、スケジュールされたコンピューティングジョブの合間に前記少なくとも１つのノードをプロビジョニングする、請求項１６に記載のコンピュータ可読媒体。
18. 複数のノードを有するハイブリッド型のコンピューティング環境を管理するためにコンピューティングデバイスを制御するための命令を保存するコンピュータ可読媒体において、少なくとも１つのノードが第１のオペレーティングシステムと関連付けられた第１のリソースマネージャと通信し、少なくとも１つのノードが第２のオペレーティングシステムと関連付けられた第２のリソースマネージャと通信し、前記命令は、ノードをワークロードに対して動的にプロビジョニングするステップに関連し、前記命令は、
    ハイブリッド型のコンピューティング環境の少なくとも１つのノードを前記第１のオペレーティングシステムから前記第２のオペレーティングシステムへプロビジョニングする命令を、ワークロードマネージャから受け取るステップであって、前記第１のオペレーティングシステムおよび前記第２のオペレーティングシステムがノードのハードウェアで直接実行されるステップと、
    前記第２のオペレーティングシステムをプロビジョニングした後、前記少なくとも１つのノードと関連付けられた前記第１のリソースマネージャからの少なくとも１つの信号をプールするステップと、
    前記少なくとも１つのノードと関連付けられた前記第２のリソースマネージャからの少なくとも１つの信号を処理するステップと、
    前記第２のオペレーティングシステムがプロビジョニングされた前記少なくとも１つのノードと関連付けられたリソースを消費するステップとを含む、コンピュータ可読媒体。
19. 前記ワークロードマネージャは、前記少なくとも１つのノードと関連付けられた前記第１のリソースマネージャから前記少なくとも１つの信号を受け取り、レイテンシプールにプールする、請求項１８に記載のコンピュータ可読媒体。
20. 前記ワークロードマネージャは、前記第２のオペレーティングシステムがプロビジョニングされた前記少なくとも１つのノード上のリソースの消費を管理するために、前記第２のリソースマネージャからの前記少なくとも１つの信号を処理する、請求項１９に記載のコンピュータ可読媒体。

Images