JP2016526735A - 仮想ハドゥープマネジャ - Google Patents

Abstract

ハドゥープアプリケーションおよび仮想環境内で実行される他の作業負荷の高弾力性マルチテナントプラットホームを提供する分散計算アプリケーションについて説明する。ハドゥープなどの分散計算フレームワークの複数のインスタンスは同時に実行され得る。中央集中型マネジャは、メモリおよびＣＰＵなどの計算資源の競合により、タスクが、所与のホスト上で実行するＶＭ上でより遅く実行される時を検知し、かつ検知された資源競合に基づきクラスタを拡大または縮小する。

Description

本開示は、仮想ハドゥープマネジャに関する。

ハドゥープ（Hadoop）または他のマップ削減関連フレームワークなどの分散計算プラットホームは、複数の計算デバイスにより実行される分散ソフトウェアコンポーネントのグループまたは「クラスタ」にわたって計算タスクを割り振るソフトウェアを含み、大きな作業負荷（例えば、データセット）が並列に、かつ単一ソフトウェアインスタンスまたは単一デバイスにより通常実行可能な速度より速く処理されることを可能にする。このような分散計算プラットホームは通常、大量（例えば、ペタバイト）のデータへアクセスするために多く（例えば、何千程度）の計算デバイス上で実行される入力／出力集約型分散ソフトウェアコンポーネントを支援し得る分散ファイルシステムを利用する。例えば、ハドゥープにより解析されるデータセットは、ハドゥープソフトウェアを実行する様々な計算デバイスがファイルの異なる部分を同時に処理することができるようにするハドゥープと共に通常使用されるハドゥープ分散ファイルシステム（ＨＤＦＳ）内に格納され得る。

一態様は、仮想計算環境内のマルチテナント分散計算アプリケーションを実行する方法である。当該方法は、仮想計算環境内で実行している複数の計算クラスタからクラスタ関連メトリックを受信することであって、各計算クラスタが作業負荷スケジューラと複数のワーカノードとを含むことと、前記仮想計算環境の性能に関連付けられた資源関連メトリックを受信することであって、前記資源関連メトリックがメモリ関連メトリックおよびＣＰＵ関連メトリックのうちの少なくとも１つを含むことと、前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、ホストの計算資源について前記複数の計算クラスタ間の資源競合の状態を判断すること、前記資源競合の状態を判断することに応じて、前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小すること、資源競合が前記ホスト上に存在しないと判断することに応じて、前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大することを備える。

他の態様は、プロセッサにより実行可能なコンピュータソフトウェアを格納した非一時的コンピュータ可読記憶媒体である。前記コンピュータソフトウェアは、仮想計算環境内のマルチテナント分散計算アプリケーションを実行するための上述した方法を具現化するものである。

更なる態様は、仮想計算環境内の分散計算アプリケーションを実行するためのシステムであって、ホストコンピュータシステムが、メモリデバイスと、プロセッサであって、仮想計算環境内で実行している複数の計算クラスタからのクラスタ関連メトリックを受信するステップであって、各計算クラスタが作業負荷スケジューラと複数のワーカノードとを含むステップと、前記仮想計算環境の性能に関連付けられた資源関連メトリックを受信するステップであって、前記資源関連メトリックがメモリ関連メトリックおよびＣＰＵ関連メトリックのうちの少なくとも１つを含むステップと、前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、ホストの計算資源について前記複数の計算クラスタ間の資源競合の状態を判断するステップと、前記資源競合の状態を判断することに応じて、前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小するステップと、資源競合が前記ホスト上に存在しないと判断することに応じて、前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大するステップと、を行うようにプログラムされたプロセッサとを備えるものである。

本開示の１つまたは複数の実施形態が利用され得る仮想計算システムを示すブロック図である。 本開示の一実施形態による、１つまたは複数の仮想マシンを支援するホストコンピュータを示すブロック図である。 ハドゥープクラスタ内のノードの様々な実施形態を描写するブロック図である。 本開示の一実施形態による、分散計算の複数の仮想クラスタとして動作するように構成された仮想ハドゥープマネジャを有する仮想計算システムを示すブロック図である。 本開示の一実施形態による仮想ハドゥープマネジャ（ＶＨＭ）をさらに詳細に描写するブロック図である。 本開示の一実施形態による、仮想環境内のマルチテナント分散計算アプリケーションの弾力的スケーラビリティのための方法のステップを示す流れ図である。

本明細書において開示される１つまたは複数の実施形態は、複数のデータフレームワーク（例えば、ハドゥープ（Hadoop）クラスタ）同士の共存および仮想環境内の他の作業負荷との共存を可能にする方法、システムおよびコンピュータプログラムを提供する。仮想ハドゥープマネジャ（ＶＨＭ）は、資源競合を示すとして識別された１つまたは複数のメトリックに基づき仮想環境内に資源競合が存在するかどうかを判断し、クラスタを縮小または拡大するなどの１つまたは複数の是正措置を提案する。資源競合により仮想マシン（ＶＭ）上でのタスクの実行が遅くなる場合、そうすることで落伍者（straggler）と遅延タスクとを生じ得るため、そのＶＭ上でタスクを実行しないことが望ましいことがあり得ることが判明した。このような資源競合を有しない他のホスト内のＶＭがこれらのタスクを実行した方がよいことがあり得る。外部スケジューラを再生成または変更するのではなく、仮想ハドゥープマネジャはハドゥープクラスタ内のホスト、ＶＭおよびノードにより提供される「周囲」情報に反応するように構成される。

図１は、本開示の１つまたは複数の実施形態が利用され得る計算システム１００を示すブロック図である。図示のように、計算システム１００は、ホスト１０８−１、１０８−２、１０８−３、１０８−４として識別されホスト１０８として集合的に参照されるホストコンピュータのホストグループ１０６を含む。各ホスト１０８は、同じホスト１０８上で同時に実行される複数の仮想マシン（ＶＭ）１１２内へハードウェアプラットホーム１１８のプロセッサ、メモリ、記憶およびネットワーク資源を抽出する仮想化層を提供するように構成される。ＶＭ１１２は、ＶＭ１１２によるホスト１０８のハードウェア資源の共有を可能にするソフトウェアインターフェース層（本明細書ではハイパーバイザ１１６と呼ぶ）上で実行される。本明細書で説明する実施形態において使用され得るハイパーバイザ１１６の一例は、ブイエムウェア社（VMware, Inc.）から市販されているブイエムウェアブイスフィア（VMware vSphere）ソリューションの一部として提供されるブイエムウェアＥＳＸｉ（VMware ESXi）ハイパーバイザである。

一実施形態では、ＶＭ１１２は、ＣＰＵおよびメモリなどのハードウェアプラットホーム１１８の利用可能資源を論理的に分断する複数の資源プール（資源プール１１４−１、１１４−２、１１４−３として識別される）中に編成される。資源プール１１４は階層にグループ分けすることができ；資源プール１１４は資源を「子」資源プールと仮想マシンへ提供する。資源プール１１４は、システム管理者が、計算システム１００の資源を編成し、ＶＭおよび計算資源を一方の資源プールから他方のプールへ隔離し、資源に寄与する実際のホスト１０８から資源を抽出し、資源プール１１４に関連付けられたＶＭ１１２の組を管理できるようにする。例えば、システム管理者は、ＶＭの囲う資源プール１１４上の設定を変更することにより一組のＶＭ１１２への資源の総割り振りを制御し得る。

図示のように、ホスト１０８のＶＭ１１２は、ウェブサービス、データベースサービス、データ処理サービスおよびディレクトリサービスを含む情報技術サービスを提供する多くの作業負荷（例えば、作業負荷１２２）を実行するために設けられ使用され得る。一実施形態では、１つまたは複数のＶＭ１１２は、その作業負荷を、分散計算アプリケーションのノード１２８として動作する複数のＶＭにわたって弾力的に分散するように構成された分散計算アプリケーション１２４により生成され管理されるクラスタ１３４のＶＭノード１２８として動作するように構成される。分散計算アプリケーション１２４は、特定の作業負荷要求に基づき追加ＶＭを取り込むまたはそのクラスタから未使用ＶＭノード１２８を解放し、これにより計算システム１００内のそのプロファイルを増大および縮小するように構成される。ホスト１０８上のノード１２８として実行するＶＭ１１２は図２においてさらに詳しく示される。

図２は、本開示の一実施形態による、１つまたは複数の仮想マシン１１２を支援するホストコンピュータ１０８を示すブロック図である。図示のように、各ホスト１０８のハードウェアプラットホーム１１８は、メモリ２０２、プロセッサ２０４、ローカル記憶装置２０６、ディスクインターフェース２０８およびネットワークインターフェース２１０などの従来の計算デバイスのコンポーネントを含み得る。プロセッサ２０４は、命令（例えば、本明細書で説明する１つまたは複数の動作を行う実行命令）を実行するように構成され、メモリ２０２内およびローカル記憶装置２０６内に格納され得る。メモリ２０２とローカル記憶装置２０６は、実行可能命令、暗号鍵、仮想ディスク、構成および他のデータなどの情報が格納および検索され得るようにするデバイスである。メモリ２０２は、例えば１つまたは複数のランダムアクセスメモリ（ＲＡＭ）モジュールを含み得、ローカル記憶装置２０６は例えば１つまたは複数のハードディスク、フラッシュメモリモジュール、固体ディスクおよび光ディスクを含み得る。ディスクインターフェース２０８はホスト１０８が１つまたは複数のネットワークデータ記憶システムと通信できるようにし、ネットワークデータ記憶システムは例えばＶＭノードによりアクセスされる「仮想ディスク」を格納し得る。ディスクインターフェース２０８の例は、ホスト１０８を記憶領域ネットワーク（ＳＡＮ）またはネットワークファイルシステムインターフェイス（ネットワーク記憶装置２２０として描写される）へ結合するホストバスアダプタ（ＨＢＡ）である。ネットワークインターフェース２１０は、ホスト１０８がネットワーク１１０などの通信媒体を介し別のデバイスと通信できるようにする。ネットワークインターフェース２１０の例は、ネットワークインターフェースカード（ＮＩＣ）とも呼ばれるネットワークアダプタである。いくつかの実施形態では、複数のＮＩＣがネットワークインターフェース２１０に含まれる。

先に説明したように、仮想マシン（例えば、ＶＭ１１２−１〜１１２−Ｎ）は、仮想マシンによりホスト１０８のハードウェアプラットホーム１１８の資源の共有を可能にするハイパーバイザ１１６上で実行される。ハイパーバイザ１１６は、ホスト１０８のオペレーティングシステムの上でまたはホスト１０８のハードウェアコンポーネント上で直接実行され得る。ハイパーバイザ１１６は、各ＶＭ１１２−１〜１１２−Ｎがその対応する仮想ハードウェアプラットホーム（例えば、仮想ハードウェアプラットホーム２１４−１〜２１４−Ｎのうちの対応する１つ）を有するように、各ＶＭ１１２の「仮想」資源へハードウェアプラットホーム１１８の物理資源をマッピングするように構成されたデバイスドライバ層を提供する。このような仮想ハードウェアプラットホーム２１４はそれぞれ、例えばその対応するＶＭ１１２の等価な従来のハードウェアアーキテクチャとして機能し得るエミュレートハードウェア（例えば、メモリ２０２Ａ、プロセッサ２０４Ａ、ローカル記憶装置２０６Ａ、ネットワーク記憶２０８Ａ、ネットワークインターフェース２１０Ａなど）を提供する。仮想ハードウェアプラットホーム２１４−１〜２１４−Ｎは、ハイパーバイザ１１６と対応するＶＭ１１２−１〜１１２−Ｎとの間の動作を協調させるために仮想システム支援を実施する仮想コンピュータモニタ（ＶＭＭ）２１２−１〜２１２−Ｎの一部と考えられ得る。図２に描写する実施形態では、各ＶＭ１１２は、ゲストオペレーティングシステム（ＯＳ）２１６（例えば、マイクロソフトウインドウズ（Microsoft Windows）（登録商標）、リナックス（Linux）（登録商標））と、ゲストＯＳ２１６上で実行される１つまたは複数のゲストアプリケーションとを含む。一実施形態では、各ＶＭ１１２は、分散計算アプリケーション１２４の分散ソフトウェアコンポーネントコード２２０（例えば、Ｊａｖａ（登録商標）コード）の実行を支援するＪａｖａ（登録商標）仮想マシン（ＪＶＭ）などのランタイム環境２１８を含む。例えば、分散計算アプリケーション１２４がハドゥープアプリケーションであれば、ＶＭ１１２は、以下にさらに説明する作業負荷スケジューラ機能（時に「ジョブトラッカー（Job Tracker）」と呼ばれる）、「タスクトラッカー（Task Tracker）」機能、または「ネームノード（Name Node）」機能、「データノード」機能を実施することにより分散ソフトウェアコンポーネントコード２２０を実行するランタイム環境２１８（例えば、ＪＶＭ）を有し得る。代替的に、各ＶＭ１１２は、ゲストＯＳ２１６上で本来実行されるように構成された分散計算アプリケーション１２４の分散ソフトウェアコンポーネントコード２２０を含み得る。

図１に描写するように、計算システム１００は、ネットワーク１１０を介し複数のホスト１０８と通信し得る仮想化管理モジュール１３０を含む。一実施形態では、仮想化管理モジュール１３０は、計算システム１００内に存在し得る中央サーバ中に存在して実行するか、またはそうでなければホスト１０８の１つにおいてＶＭとして実行されるコンピュータプログラムである。仮想化管理モジュールの一例はブイエムウェア社（VMware, Inc.）から入手可能なブイセンタ（vCenter）（登録商標）サーバ製品である。仮想化管理モジュール１３０は計算システム１００の管理業務を行うように構成される。管理業務は、ホスト１０８を管理すること、各ホスト１０８内で実行されるＶＭを管理すること、ＶＭを提供すること、ＶＭをホストからホストへ移動すること、ホスト１０８間の負荷をバランスさせること、ホスト１０８とＶＭ１１２の計算資源からなる資源プール１１４を生成すること、ＶＭおよび物理資源を割り振るおよび割り振りを解除するために資源プール１１４を修正すること、および資源プール１１４の構成を修正することを含む。一実施形態では、仮想化管理モジュール１３０は、性能データを収集すると共に、ホスト１０８、ＶＭ１１２および資源プール１１４の可用性、状態、および性能に関係する性能メトリック（例えば、カウンタ値、統計値）を生成するためにホスト１０８と通信するように構成される。

仮想化管理モジュール１３０は、ホストグループ１０６のホスト１０８全体にわたってＶＭをバランスさせることによりシステム１００全体にわたる負荷をバランスさせる仮想環境スケジューラ機能を提供するように構成され得る。例えば、資源プール内のＶＭのうちの１つの上の資源利用が劇的に変化すれば、仮想化管理モジュール１３０は、ホスト全体にわたる仮想マシンの分布を最適化するために物理的ホスト間でＶＭを移動させる（すなわち移行させる）。さらに、すべてのＶＭの全体作業負荷が低下すれば、仮想化管理モジュール１３０は、物理的ホストのいくつかの電源を切り、残りの物理的ホスト全体にわたってＶＭを集約し得る。仮想環境スケジューラの一例は、ブイエムウェア社（VMware, Inc.）から入手可能なブイエムウェア（VMware）分散資源スケジューラ（ＤＳＲ：Distributed Resource Scheduler）（登録商標）製品である。

一実施形態では、仮想化管理モジュール１３０は、ＶＭ１１２および資源プール１１４に関連付けられた１つまたは複数の資源制御を調整するように構成される。資源制御は、構成、属性、およびどのようにハードウェア資源（例えば、メモリ２０２、ＣＰＵ２０４、記憶装置、ネットワーク帯域幅）がＶＭ１１２と資源プール１１４により割り振られ利用されるかを規定する他の設定である。一実施形態では、どのように資源（例えば、ＣＰＵ、メモリ、記憶装置、ネットワーク）がＶＭ１１２へ割り振られるかを管理するために、仮想化管理モジュール１３０は、１つまたは複数のＶＭ１１２の「予約」、「制限」、「共有」のための資源制御と、１つまたは複数の資源プール１１４へ割り当てられた「予約」、「制限」、「共有」のための資源制御とを修正し、修正された資源制御に基づき上記仮想環境スケジューリング動作を行う。別の実施形態では、仮想化管理モジュール１３０は、システム１００全体にわたって資源を管理するために特定のホスト１０８上で実行する１つまたは複数のＶＭ１１２の電源を入れる、１つまたは複数のＶＭ１１２の電源を切る、１つまたは複数のＶＭ１１２のクローンを作る、１つまたは複数のＶＭ１１２を配備する命令を発行し得る。一例では、計算ＶＭは、いかなる資源競合も他の資源プール内の他のより重要なＶＭ（例えば、マスターＶＭ）により見られる前にこれらの計算ＶＭにより最初に見られるように、より低い優先度を示す「低い」共有設定を有する資源プール１１４内に配置され得る。

一実施形態では、分散計算アプリケーション１２４は、分散計算アプリケーションに関連付けられたＶＭノード１２８内で１つまたは複数の作業負荷を実行することにより作業負荷全体の実行を管理するように構成されたアプリケーション作業負荷スケジューラ１２６（例えば、ＶＭ１１２内で実行する）を含む。動作中、アプリケーション作業負荷スケジューラ１２６は、追加作業負荷を処理するための資源の状態と可用性とを判断するために、分散計算アプリケーションに割り振られたＶＭノード１２８に問い合わせを行い得る。例えば、アプリケーション作業負荷スケジューラ１２６は、ＶＭが作動されているかどうかを判断するために、そして作動されていれば、分散計算アプリケーションにより行われる作業負荷の一部を実行するためにどれくらいの量のＲＡＭが全体として各ＶＭから割り振られ得るかを判断するために、分散計算アプリケーションに割り振られたＶＭ１１２−３〜１１２−９に問い合わせを行い得る。

本開示の実施形態は、計算システム１００などの仮想環境上の弾力的分散計算を可能にするように構成された仮想ハドゥープマネジャ１３２を含む。ＶＨＭ１３２は、システム１００の計算資源に関連付けられた性能メトリックと計算クラスタに関連付けられた性能メトリックとに基づき計算クラスタを縮小または拡大するために仮想化管理モジュール１３０と（例えば、ＡＰＩコールを介し）通信するように構成される。

仮想ハドゥープマネジャ１３２は図１および図３ではホスト１０８のうちの１つの中で実行されるＶＭ１１２上に存在し実行する別個のコンポーネントとして描写されるが、仮想ハドゥープマネジャ１３２は代替的に、仮想計算システム１００（例えば、仮想化管理モジュール１３０が存在する同じ中央サーバなど）の計算デバイスのうちの任意の１つ内に存在し得ることが理解される。さらに、添付図面はすべてのホスト１０８の単一仮想ハドゥープマネジャを描写するが、本開示の実施形態は効果的にスケーリングされ得ることに注意すべきである。すなわち、計算システム１００内のホストの数が増加すると、ＶＨＭ１３２の分散クラスタが、独立した組のホストを管理するために使用され得る。加えて、ハドゥープフレームワークと共に使用するための仮想ハドゥープマネジャ１３２について詳細に説明したが、ＶＨＭ１３２はデータフレームワークアグノスティック（data framework-agnostic）であるように構成される、すなわち、ハドゥープに限定されない他のフレームワークと共に使用され得ることに留意すべきである。例えば、ＶＨＭ１３２は、Ｈベース（ＨＢａｓｅ）などの分散データベースフレームワークまたはイムパラ（Impala）などのメモリ内フレームワークと共に使用され得る。

図３は、本開示の１つまたは複数の実施形態による、ハドゥープクラスタ内のノード（例えば、ノード１２８）の様々な実施形態を描写するブロック図である。計算データ分離のための様々な方法が描写される。一つの方法３００では、各ノード３０２（すなわち、ＶＭ１１２上で実行する）はそのノード３０２上に記憶ノードと計算ノードの組み合せを含み得る。例えば、各ノード３０２は、その上で実行する１つのタスクトラッカーと１つのデータノードとを有し得る。いくつかのケースでは、ＶＭライフサイクルはデータノードにより判断され、このような方法は限定された弾力性を有し得、ハドゥープマルチテナンシィ（multi-tenancy）に限定され得ることが判明した。

方法３１０では、記憶ノード３１４は、計算ノード３１２と記憶ノード３１４が別個のＶＭ上で実行し得るように計算ノード３１２から分離される。このような実施形態では、計算ノード３１２は弾力的計算ノードとして構成され得る。方法３１０では、共有作業負荷が使用可能にされ（すなわち、異なる作業負荷がハドゥープクラスタ内で実行し得る）、これにより計算システムの利用率を上げる。

方法３２０では、計算システム１００はテナント毎に別個の仮想クラスタを含み得る。図３に示すように、別個の計算テナント（compute tenant）３２２、３２４（「Ｔ１」、「Ｔ２」と標記される）が計算システム１００内で実行し得る。このような実施形態は有利には、より強いＶＭ級セキュリティと資源隔離を提供し、また複数のハドゥープ・ランタイムバージョンの配備を、またはハドゥープに加えておよびそれを含み様々な種類のフレームワークの配備を可能にする。例えば、テストバージョンである配備フレームワークの１つのクラスタは、ハドゥープの製品バージョンである配備フレームワークの別のクラスタと同じ計算システム内に配備され得る。計算システム１００の一実施形態は、同じ記憶層（例えば、ハドゥープ分散ファイルシステム（ＨＤＦＳ）を共有する異なるテナントのための別個の計算クラスタを配備する。一実施形態によると、計算ノードは優先度および利用可能資源に従って委託または委託解除され得る。方法３２０を使用する例示的アーキテクチャが図４にさらに詳細に描写される。

［マルチテナンシィを有する例示的な弾力的ハドゥープアプリケーション］
図４は、本開示の一実施形態による、分散計算の複数の仮想クラスタ１３４−１、１３４−２（クラスタ１３４と総称される）として動作するように構成された仮想ハドゥープマネジャ１３２を有する仮想計算システム４００を示すブロック図である。仮想計算システム４００は、ホスト１０８内の他の非ハドゥープ関連作業負荷を実行する他の非ハドゥープ関連ＶＭ（ホスト１０８−Ｎ上で実行するＶＭ４１０により表される）を含み得ることを認識すべきである。分散計算アプリケーション１２４は単一エンティティとして描写されるが、仮想クラスタ１３４は、同じ分散計算アプリケーションの異なるバージョンのものであり得る、または異なる分散計算フレームワークを纏めたものであり得ることを認識すべきである。

図３に示す実施形態では、分散計算アプリケーション１２４は、ハドゥープアプリケーションへ割り振られた一組の分散作業負荷ノード（例えば、ＶＭ１１２）を使用して大きな一組のデータを処理するように構成されたハドゥープアプリケーションである。ハドゥープアプリケーションの別のアーキテクチャ（ヤーン（YARN）など）が本明細書で説明する技術と共に利用され得ることを認識すべきであり、フロントエンドスケジューラまたは大型スケーラブルデータベースシステムを有するウェブアプリケーション（例えば、モンゴＤＢ（MongoDB）、アパッチカサンドラ（Apache Cassandra））などの他の分散計算アプリケーションが本明細書で提供される技術に従って構成され利用され得る。

各ハドゥープクラスタ１３４は、クライアントからジョブを受諾すると共にクラスタ１３４の一部である複数のスレーブノード上の実行のために対応する作業負荷をスケジューリングする少なくとも１つのジョブトラッカー４０２（例えば、図示しないＶＭ上で実行する）を含む。各ハドゥープクラスタ１３４は、ジョブトラッカー４０２により提供される要求タスク（例えば、マップタスク（map task）、削減タスク（reduce task））を行うワーカノード（worker node）である複数のタスクトラッカー４０４（例えば、ＶＭ上で実行する）を含む。一実施形態では、各タスクトラッカー４０４は、１つまたは複数の利用可能「スロット」内で１つまたは複数のタスクを実行するように構成される。一例では、各スロットは、単一タスクを完了するための分散ソフトウェアコンポーネントコード（例えば、コード２２０）を実行するランタイム環境（例えば、Ｊａｖａ（登録商標）仮想マシン）のインスタンスとして実装され得る。したがって、いくつかの実施形態では、各トラックトラッカー４０４は、ジョブトラッカー４０２によりタスクトラッカーへ割り当てられた複数のタスクを並列に実行するためにランタイム環境の複数のインスタンスを実行し得る。

図４に示すように、第１のハドゥープクラスタ１３４−１は、第２のハドゥープクラスタ１３４−２の一組のジョブトラッカー４０２−２とタスクトラッカーノード４０４（異なる塗りつぶしパターンにより図示される）とは別であるがホスト１０８のハードウェア資源を共有する一組のジョブトラッカー４０２−１と複数の計算ノード（タスクトラッカー４０４）を有し得る。

一実施形態では、ハドゥープクラスタ１３４−１、１３４−２は、少なくとも１つのネームノード４０６と複数のデータノード４０８とからなる単一データ層を共有し得る。各データノード４０８（例えば、ＶＭとして実行する）は、ハドゥープクラスタにより使用されるデータの一部を、データノードが実行するホスト１０８に利用可能な記憶装置（ローカルデータ記憶装置（例えば、ローカル記憶装置２０６）および／またはネットワーク記憶装置２２０など）内に格納する。ネームノード４０６は、データの分散部分がハドゥープアプリケーションの分散データノード４０８間に位置する場所（例えば、ローカル記憶装置２０６またはネットワーク記憶装置２２０）を追跡する。

図５は、本開示の一実施形態による仮想ハドゥープマネジャ（ＶＨＭ）１３２をさらに詳細に描写するブロック図である。ＶＨＭ１３２は、ハドゥープクラスタを弾力的にスケーリングするために仮想化管理モジュール１３０およびジョブトラッカー４０２と協調するように構成される。一実施形態では、ＶＨＭ１３２は仮想化管理モジュール１３０と分散計算アプリケーション１２４により提供される周囲データに基づきクラスタ１３４を（例えば、ジョブトラッカー４０２を介し）拡大または縮小するように構成される。周囲データは、以下にさらに詳細に説明される資源関連メトリックおよびフレームワーク関連メトリックを含む。いくつかの実施形態では、ＶＨＭ１３２は、ＶＨＭ１３２が、行うべき仕事が存在すると判断し、仮想計算システム１００内に資源の競合が存在しないと判断すると、クラスタ１３４を拡大する。いくつかの実施形態では、ＶＨＭ１３２は、ＶＨＭ１３２が、仮想計算システム１００内に資源の競合が存在すると判断すると、クラスタ１３４を縮小する。本開示の実施形態は有利には、顧客の期待、試験の容易さ、および資源利用の改善のための予測スケーリングを提供する。

ＶＨＭ１３２は、スケーリング応答に対する入力として競合検出を使用する。以下にさらに詳細に説明されるように、資源の競合は、ユーザの資源制御設定（例えば、「予約」、「制限」、および「共有」設定）と作業負荷要求とを反映する。ＶＨＭ１３２は、複数のＶＭにまたがる分散計算アプリケーションのための仮想化管理モジュール１３０により提供される仮想環境スケジューラ機能（すなわち、ＤＲＳ）に対する拡張として機能し得る。ＶＨＭ１３２は、仮想化管理モジュール１３０と、ジョブトラッカー４０２などのアプリケーションスケジューラとの間のグルー（glue）として機能する。ＶＨＭ１３２は、資源を割り振る際にすべてのＶＭを軽度に（すなわち、一様に）不利にするよりもむしろいくつかのＶＭを重度に（すなわち、偏って）不利にするように構成され得る。ＶＨＭ１３２は、ジョブ実行時間の増加を引き起す（すなわち、余りに遅い反応は落伍者またはタスクエラーを引き起こし、余りに速い反応は過渡現象に反応し得る）真の競合が存在する場合（すなわち、活発に使用されている特定の資源が奪われた場合）だけにタイムリーに反応するように構成され得る。ＶＨＭ１３２は、クラスタのスケーリングに関する判断を誘導するために、ヒステリシスと一時的窓および閾値などの他の制御理論概念（以前の行為からフィードバックされる）とを適用し得る。

動作中、ＶＨＭ１３２は、仮想化管理モジュール１３０（例えば、ブイセンタ（vCenter））とハドゥープクラスタ１３４から情報５０２、５０４を定期的に（例えば２０秒間隔で）収集する。図５に示すように、仮想化管理モジュール１３０からの情報５０４は、ハドゥープクラスタが実行される下位仮想インフラストラクチャの状態およびそれについての統計値を規定し得る。いくつかの実施形態では、情報５０４（資源関連メトリックとも呼ばれる）はＶＭ構成とＶＭ１１２についての資源制御設定（例えば、ＣＰＵおよびメモリ割り振り）とを含み得る。いくつかの実施形態では、情報５０４は、ホストレベルおよびゲストレベルメモリ、ＣＰＵ、ネットワークおよび記憶性能メトリックなどの性能メトリックを含み得る。ハドゥープクラスタ１３４からの（例えば、ジョブトラッカー４０２により報告された）情報５０２は、分散計算アプリケーションクラスタ１３４のアプリケーションレベル状態およびそれについての統計値を規定し得る。いくつかの実施形態では、情報５０２（本明細書ではクラスタ、フレームワークまたはハドゥープ関連メトリックとも呼ばれる）は、保留中または現在行われているジョブまたはタスクの量、ジョブを行うためのスロットの可用性、エラーおよび他のジョブ状態情報、使用されるスロットに関連する統計値および性能メトリック、待ち行列に入れられた保留中作業の量、および他の統計値などの状態情報を含み得る。

１つまたは複数の実施形態では、ＶＨＭ１３２は、様々なメトリック（例えば、情報５０２、５０４から収集された）の移動平均または中央値を時間窓にわたり維持することにより資源消費における一時的スパイクなどの一時的データを除去するように構成される。ＶＨＭ１３２は、移動平均および中央値に基づき異常であると判断された値を有するいかなる収集メトリックも無視するように構成され得る。

一実施形態では、ＶＨＭ１３２は、サイクル（本明細書では「動作サイクル」と呼ぶ）ベースで資源競合をチェックして１つまたは複数の行為を行うように構成される。例えば、ＶＨＭ１３２は、動作サイク毎（例えば、３００秒毎）に一回縮小および拡大判断を行う。ＶＨＭ１３２は、過渡現象を除去する一方で、１つまたは複数のアルゴリズム５１０を使用して情報５０２、５０４を解析し、縮小および拡大のための事象を生成する。一実施形態では、アルゴリズム５１０は、縮小および拡大判断の影響が次の動作サイクル内のアルゴリズム中にフィードバックされる制御理論ベースアルゴリズムを含む。いくつかの実施形態では、ＶＨＭ１３２は、歴史的メトリックだけでなく現在のメトリックにも基づき資源競合および縮小／拡大に関する判断を行う。ＶＨＭ１３２により行われる判断（例えば、縮小、拡大）は様々なメトリック（例えば、ＣＰＵ使用率、メモリ使用率、保留中ジョブの数など）を所定期間にわたって変化させ得ることが理解される。これらの変更されたメトリックは、次の動作サイクルのための新しい判断を行うためにアルゴリズム５１０中にフィードバックされ得る。

ＶＨＭ１３２は、事象を集約および配送するために事象待ち行列を使用し得る。事象待ち行列は、ＶＨＭ１３２が手動動作モード（ユーザ（例えば、システム管理者）により手動で承認され配送されるまで事象が待ち行列に入れられる）に対処できるようにするだけでなく、事象を自動的に配送する自動動作モードに対処し、行動のために適切なクラスタを呼び出すことができるようにする。他のクラスタ構成４１２だけでなく手動／自動動作モードも配備ユーティリィティアプリケーション５１０（例えば、ブイエムウェア社（VMware, Inc.）から入手可能なプロジェクト・セレンゲティ（Project Serengeti）により規定され得る。

ＶＨＭ１３２により呼び出される行為は、仮想化管理モジュール１３０へ発行された（例えば、ＶＭの電源をオン／オフする）命令により具現化される仮想化関連行為５０６と、ハドゥープクラスタ１３４へ発行された（例えば、計算ノードを委託解除または再委託する）命令により具現化されるハドゥープ行為５０８とを含む。

一実施形態では、ＶＨＭ１３２のアルゴリズム５１０は、クラスタ特有判断を行う１つまたは複数のクラスタスケールストラテジストを含み得る。すなわち、各ハドゥープクラスタ１３４は、生成された事象を解析すると共にその特定ハドゥープクラスタ１３４のすべてのホスト上の行動方針を判断するクラスタスケールストラテジストのインスタンスを有し得る。クラスタスケールストラテジストは、他の非関連クラスタがそのクラスタスケールストラテジストの観点から重要ではない「利己的」手法で判断を行い得る。ＶＨＭ１３２は、クラスタが互いに踏みにじり合うのを回避するために、クラスタ要求を承認または拒絶するアービトレータモジュールを含み得る。

図６は、本開示の一実施形態による、仮想環境内のマルチテナント分散計算アプリケーションの弾力的スケーラビリティのための方法６００のステップを示す流れ図である。本方法が図１および図３のシステムに関連して説明されたとしても本方法のステップを行うように構成されるいかなるシステムも本開示の実施形態の範囲に入ることを認識すべきである。

ステップ６０２において、ＶＨＭ１３２は、仮想計算環境内で実行する複数の計算クラスタ１３４からクラスタ関連メトリック（例えば、情報５０２）を受信する。ＶＨＭ１３２は、各計算クラスタ１３４のタスクトラッカー４０４から「ローカル」統計値を受信するだけでなく各計算クラスタ１３４のジョブトラッカー４０２から「グローバル」統計値も受信し得る。クラスタ関連メトリックの例としては、他のメトリックも使用され得るが以下のものを示す統計値が挙げられ得る：計算クラスタ内の活性計算ノードの数（「alive_nodes」）、計算クラスタ内のタスク失敗の数（「task_failures」）、待機マップ（waiting Map）タスクの数（「waiting_maps」）、待機削減（waiting Reduce）タスクの数（「waiting_reduces」）、特定のタスクトラッカー４０４内で使用されているマップスロットの数またはすべてのタスクトラッカーの総数（「map_slots_used」）、特定のタスクトラッカー４０４内のマップスロットの数またはすべてのタスクトラッカーの総数（「max_map_slots」）、特定のタスクトラッカー４０４内で使用されている削減スロット（Reduce slots）の数またはすべてのタスクトラッカーの総数（「reduce_slots_used」）、および特定のタスクトラッカー４０４内の削減スロットの最大数またはすべてのタスクトラッカーの総数（「max_reduce_slots」）。

ステップ６０４では、ＶＨＭ１３２は仮想計算環境の性能に関連付けられた資源関連メトリック（例えば、情報５０４）を受信する。ＶＨＭ１３２は、ホスト１０８の下位物理的計算資源の性能を表す「ホストレベル」統計値を受信し得る。ＶＨＭ１３２はまた、例えばＪＶＭ監視エージェントにより提供されるようなジョブトラッカー、タスクトラッカーなどのインスタンスを実行するランタイム環境２１８（すなわち、ＪＶＭ）内だけでなく所与のＶＭ１１２内の活動の統計値を提供する「ゲストレベル」統計値を受信し得る。資源関連メトリックは、メモリ２０２とＣＰＵ２０４の性能に関係するメモリ関連メトリックおよびＣＰＵ関連メトリックをそれぞれ含み得る。記憶装置およびネットワーク関連メトリックがまた使用され得る。

資源関連メトリックの例としては、以下のものを示す統計値が挙げられ得る。
・特定のＶＭ内で活発に使用されているマシンページ番号（ＭＰＮ）の数に基づきハイパーバイザにより推定される活発に使用されるメモリの量を示す「活性メモリ」メトリック。
・特定のＶＭに対して許容されたＭＰＮの数に基づき特定のＶＭに対して許容されたマシンメモリまたは「物理的」メモリの量を示す「許容メモリ」メトリック。
・ＶＭ（活性／非活性ＭＰＮを含む）により使用されているＭＰＮの数（共有ＭＰＮを除く）に基づく特定のＶＭにより消費されるゲスト物理メモリの量を示す「消費メモリ」メトリック。
・バルーニングを介しＶＭから現在再要求されているゲスト物理メモリの量を示すバルーン目標サイズを含む「メモリバルーニング（Memory Ballooning）」メトリック。
・スワッピングに利用可能なメモリの量を示すＶＭスワップファイルの目標サイズを含む「ホストスワップ（Host Swap）」メトリック。
・仮想マシンが準備できていたが、物理的ＣＰＵ上で実行されるようにスケジュールできなかった時間の百分率（または時間のサイクル）を示すＣＰＵレディメトリック。
・活発に使用される仮想ＣＰＵの量を全利用可能ＣＰＵの百分率として示すＣＰＵ使用率メトリック。
・ＶＭがその仮想マシンまたは他の仮想マシンに代わってシステムサービスを行うために中断された時間量を示すＣＰＵオーバーラップメトリック。
・その他のメトリック。

ステップ６０６では、ＶＨＭ１３２は、資源競合の状態が仮想計算環境の計算資源の複数の計算クラスタ間に存在するかどうかを受信クラスタ関連メトリックおよび資源関連メトリックに基づき判断する。ＶＨＭ１３２は資源競合をチェックし、１つまたは複数の行為をサイクルベース（例えば３００秒の動作サイクル）で行い得る。ＶＨＭ１３２はこの判断を行うために多種多様なアルゴリズム５１０を使用し得る。例えば、ＶＨＭ１３２は、資源競合が存在すると示唆する要因と資源競合が存在しないと示唆する要因とを比較検討し得る、またはこれらの要因を利用することにより、確実度の閾値レベルに基づき判断を行い得る。一実施形態では、ＶＨＭ１３２は、クラスタ関連メトリックと資源競合を示す資源関連メトリックとの識別された組合せを使用する。資源競合は、上記メトリックの集合バージョンを使用してホストベースだけでなくＶＭベースでも識別され得ることを認識すべきである。

資源競合の状態を判断するために、ＶＨＭ１３２は、「縮小関連」メトリックに基づく多くの要因を使用し得る。ＶＨＭ１３２は、特定のホスト１０８の１つまたは複数のＣＰＵ２０４が特定の計算クラスタ１３４から奪われていることを、資源関連メトリックからのＣＰＵレディメトリックを使用して判断し得る。上述のように、ＣＰＵレディは、仮想ＣＰＵ２０４Ａを実行する準備ができていたが物理的ＣＰＵ２０４上にスケジュールされなかった時間量を示す。メモリ競合はメモリバルーニングから始まり次にホストスワッピングに至り得ることが判明した。したがって、ＶＨＭ１３２はさらに、特定のホストのメモリ２０２が特定の計算クラスタから奪われていることを、資源関連メトリックからの活性メモリ、許容メモリ、メモリバルーニングおよびホストスワップメトリックを使用することにより判断し得る。例えばタスクが所与の時間制限内のハートビート（heartbeat）を介し折り返し報告するまたはチェックインするのに不十分な資源を有し得、これによりエラーを発生するため、タスクまたはジョブのエラーがメモリ競合シナリオで発生し得ることが判明した。したがって、ＶＨＭ１３２は、計算クラスタ１３４内の１つまたは複数のタスクトラッカーノード４０４が無効または故障していると報告されることを、クラスタ関連メトリックからの生存ノード（Alive Node）およびタスク失敗（Task Failure）メトリックを使用することにより判断し得る。

資源競合の状態が存在しないと判断するために、ＶＨＭ１３２は、仮想計算システム内には資源競合が存在しないことを示唆し得る「拡大関連」メトリックに基づく多くの要因を使用し得る。ＶＨＭ１３２は、ジョブが特定の計算機クラスタ内に存在することを、クラスタ関連メトリックからの待機マップおよび待機削減メトリックを使用することにより、判断し得る。ＶＨＭ１３２は、特定の計算クラスタ内のスロット使用率が高いことを、クラスタ関連メトリックからの使用マップスロットメトリック（map_slots_used）、最大マップスロットメトリック（max_map_slots）、使用削減スロットメトリック（reduce_slots_used）および最大削減スロットメトリック（max_reduce_slots）を使用することにより判断し得る。ＶＨＭ１３２は、特定のホスト内に切迫した競合が無いことを、ＣＰＵレディメトリックおよびメモリバルーニングメトリックを使用することにより判断し得る。メトリックが計算クラスタ１３４（すなわち、ハドゥープ）から利用可能でないいくつかのケースでは、ＶＨＭ１３２は、資源関連メトリックからのＣＰＵ使用率および活性メモリ使用率メトリックを使用することにより非待機ＶＭ１１２を識別し得る。

一実施形態では、ＶＨＭ１３２はゲストＶＭからのメモリ再利用の量がゲストＶＭ内の未使用メモリの量を超えれば資源競合を宣言し得る。ゲスト内の未使用メモリの量は許容メモリと活性メモリとの差（すなわち、［許容メモリ−活性メモリ］）に基づき判断され得る。多くの場合、活性メモリはメモリ集中型環境内の許容メモリを追跡する（すなわちメモリ資源の競合が発生すれば）ことが判明した。いくつかのケースでは、活性メモリは許容メモリの一定の百分率として提示され得る。ゲストＶＭからのメモリ再利用の量は、所与のＶＭのバルーン目標とスワップ目標に基づき判断され得る。バルーン目標はメモリ共有およびバルーニングの量を示唆するまたはそれに変換し、スワップ目標はホスト内で発生するメモリ圧縮およびスワッピングの量を示唆するまたはそれに変換することが判明した。いくつかの実施形態では、ＶＨＭ１３２は、メモリ競合が活性メモリ使用率に影響を与えることなく満足されれば行動を差し控え得る。すなわち、いくつかの実施形態では、ＶＨＭ１３２は、活性メモリが競合を処理するために低減される必要があれば、行動し得る（例えば、クラスタを縮小する）。一実施形態では、ＶＨＭ１３２は、上記「一次」メトリックほど重要でないと評価される消費メモリメトリックなどの「二次」メトリックを使用し得る。

別の実施形態では、ＶＨＭ１３２は、資源関連メトリックからのＣＰＵレディおよびＣＰＵオーバーラップメトリックに基づき資源競合を宣言し得る。ＣＰＵレディメトリックは所与のホストにより支援される他の仮想ＣＰＵに起因する同ホスト内の競合を測定し得、ＣＰＵオーバーラップメトリックは割り込みなどの他の要因に起因する競合を測定し得ることが判明した。「二次」メトリックとして、ＶＨＭ１３２は、レディ（Ready）、オーバーラップ（Overlap）、電力管理およびハイパー・スレッディング（Hyper Threading）特徴に起因する「盗まれた」サイクルを捕捉するＣＰＵ要求メトリックを使用し得る。いくつかの実施形態では、ＶＨＭ１３２はＣＰＵレディメトリックに基づき過渡現象を処理するように構成され得る。例えば、小さなタスクを有するハドゥープジョブは、複数のＪＶＭが頻繁に同時に開始されるため、短命なスパイクおよび過渡現象を引き起こし得る。いくつかの実施形態では、ＶＨＭ１３２は、いつメモリ競合が調整ＣＰＵレディスパイクに至るかを検知するように構成され得る。

いくつかの実施形態では、ＶＨＭ１３２は、資源競合の判断に基づいてＶＭの電源が最近入れられたかどうかを考慮し得る。拡張事象中などの新しいＶＭの電源オンは資源競合を判断する際に問題を起こすことが判明した。例えば、新しいＶＭの電源オンは、「活性メモリ」を新しいＶＭのメモリ構成の７５％まで設定されるようにし得、メモリ再利用は兄弟（sibling）資源プール１１４のＶＭにおいて場合によってはトリガされ得る。ブート時におよびハドゥープジョブが終了した時にＶＭを観測することにより、新たに電源オンされたＶＭが「零レベル」へ戻るのに数分（例えば、約１０分）かかり得ることが判明した。いくつかのケースでは、許容メモリは、小さなメモリページがブート処理中に使用され得るため、電源が入れられたＶＭの活性メモリと共に増加しないことがあり得る。他の場合では、許容メモリは、大きなメモリページがブート処理中に使用されたため、電源オン後に直ちに増加し得る。したがって、いくつかの実施形態では、ＶＨＭ１３２は、資源競合判断を行う際に、電源オン後の初期の期間の間、新たに電源がオンされたＶＭの性能メトリックを無視し得るまたは余り重視しなくてもよい。さらに、ＶＨＭ１３２は、電源オンによりトリガされた再利用に起因する他のＶＭ（例えば、兄弟ＶＭまたは「ホットスペア」ＶＭ）への影響を無視し得る。初期の期間は予め定められてもよいし、動作サイクルの倍数（例えば、３００秒の倍数）で規定されてもよい。

いくつかの実施形態では、ＶＨＭ１３２は、資源関連メトリックがそうでないと示唆したとしても、クラスタ特有メトリックに基づき、資源競合が存在しないと判断し得る。例えば、タスクトラッカーＶＭ内に明示的なマップおよび削減スロット（例えば、タスクトラッカー当たり２つの固定マップスロットと２つの固定された削減スロット）を有するいくつかのハドゥープクラスタでは、異なるＶＭが、ノード内の削減スロットが使用されているかどうかに依存してマップ削減ジョブ中の異なる時間に、より忙しく見える。１つのＶＭは、削減タスクを実行するためのより多くの資源を必要とする可能性があり、他のＶＭはそれらのマップタスクを既に実行し終えた可能性がある。このシナリオは、上述のようにメモリバルーニングメトリックを使用することにより資源競合として出現し得る待機マップ実行（idle Map-executing）ＶＭ内にバルーニングを引き起こす可能性がある。しかし、これは真の資源競合でないことがあり得、むしろ資源の再割り振りであることが判明した。したがって、ＶＨＭ１３２は、特定のホスト内に真の資源競合が存在しないと判断するために、特定のハドゥープフレームワークの理解と共に、使用マップスロットメトリック（map_slots_used）、最大マップスロットメトリック（max_map_slots）、使用削減スロットメトリック（reduce_slots_used）、および最大削減スロットメトリック（max_reduce_slots）などのクラスタ特有メトリックを使用し得る。

ステップ６０８では、資源競合が特定のホスト上に存在すると判断することに応じて、ＶＨＭ１３２は、そのホスト上で実行する複数の計算クラスタのうちの少なくとも１つを縮小する。ＶＨＭ１３２は、計算クラスタのノード（例えば、タスクトラッカーノード）として実行するＶＭ１１２のうちの１つ（資源競合（例えば、メモリ競合、ＣＰＵ競合）を経験している）を選択し得る。いくつかの実施形態では、ＶＨＭ１３２は、選択されたＶＭに関連付けられたタスクトラッカー４０４の委託を解除するハドゥープ命令を発行し得、これにより他のタスクトラッカー上のタスクをスケジューリングするジョブトラッカー４０２を生じ、選択されたＶＭ上の新規タスクの受諾を中止する。いくつかの実施形態では、ＶＨＭ１３２は、選択されたＶＭの電源を切るために仮想化管理モジュール１３０へ電源オフ命令を発行し得る。

メモリおよびＣＰＵ集約型環境を観測することにより、メモリはＣＰＵ資源より反応がはるかに遅く（数秒対何秒〜何分程度）なり得ることが判明した。メモリへの圧力はしばしばバルーニングを誘起し、より高いＣＰＵ使用率を生じる可能性がある。メモリ競合は、ＣＰＵ競合に比べて、タスクおよびジョブをより容易に失敗させる。メモリ競合ＶＭの除去は他のＶＭの準備時間を直ちに低減する可能性があることが判明した。同様に、ＣＰＵ競合ＶＭを除去することにより、メモリ競合ＶＭは回復するのにしばらく時間がかかり得る。したがって、縮小すべきＶＭを選択する際、ＶＨＭ１３２は、ＣＰＵ競合ＶＭとメモリ競合ＶＭとの両方が存在する場合、ＣＰＵ競合ＶＭよりメモリ競合ＶＭへ高い優先度を与え得る。すなわち、メモリ競合ＶＭとＣＰＵ競合ＶＭとの両方がホスト上に存在すると判断することに応じて、ＶＨＭ１３２は縮小事象のメモリ競合ＶＭを選択する。

ステップ６１０では、資源競合が前記ホスト上に存在しないと判断することに応じて、さらに計算クラスタの保留中作業が存在すると判断することに応じて、ＶＨＭ１３２は、そのホスト上で実行する計算クラスタを拡大し得る。ＶＨＭ１３２は、実行される１つまたは複数の保留中作業が存在することを示すクラスタ関連メトリックに基づき、保留中作業が存在するかどうかを判断し得る。ＶＨＭ１３２は、未競合ホスト上に割り振られるが電源オフ状態のＶＭを選択し得る。いくつかの実施形態では、ＶＨＭ１３２は、選択されたＶＭを電源オンおよびブートするために仮想化管理モジュール１３０へ電源オン命令を発行する。いくつかの実施形態では、ＶＨＭ１３２は、選択されたＶＭに関連付けられたタスクトラッカー４０４の委託を解除するハドゥープ命令を発行し、これによりジョブトラッカー４０２はそのタスクトラッカー上でタスクをスケジューリングし始める。

一実施形態では、ＶＨＭ１３２は所与のサイクルでホスト毎に最大でも１つの判断（例えば、縮小、拡大）を生じる。上述のように、各ハドゥープクラスタ１３４に関連付けられたクラスタスケールストラテジストは「利己的」判断を行い、ＶＨＭ１３２のアービトレータは他のクラスタからの入力に基づき各判断を承認または拒絶する。いくつかの実施形態では、縮小判断は破局的レベル競合ケースとは区別される。縮小判断は、最近の縮小が自身に有効になるための時間を許容するために「バックオフ」メカニズムとして、最近の縮小を考慮し得る。縮小判断の最近性は動作サイクルの倍数で規定され得る（例えば、最後の２動作サイクル内に発生する縮小判断）。ＶＨＭ１３２は、資源競合の程度（すなわち、最大競合から最小競合まで）に基づきＶＭ１１２をソートし、ソート済みのリストに基づき縮小判断を行い得る。一実施形態では、拡大判断はまた、最近の縮小または拡大を考慮し得る。

一実施形態では、ＶＨＭ１３２は、故障ＶＭを繰り返し選択することを回避するために、拡大するためのＶＭの選択をランダム化し得る。別の実施形態では、ＶＨＭ１３２は、ノードが正しく機能していることを保証するために計算ノードの健康を監視することにより「自己回復」クラスタを有効にする。計算ノードが故障していることをＶＨＭ１３２が判断すれば、ＶＨＭ１３２は計算ノードを「グレーリスト」に載せ、故障計算ノードの電源を切り、その代わりの別の新鮮な計算ノードの電源を入れる。多くの場合、ブートアップ時のおよびネットワーク内の一時的問題が計算ノードの問題を引き起こすため、後の期間中に計算ノードは使用可能な状態となる。しかし、ＶＭがこのような問題を繰り返し有するとＶＨＭ１３２が判断すれば、ＶＨＭ１３２はこのような問題の記録を維持し、ＶＭを選択することを長い期間回避し得る。

本開示の１つまたは複数の実施形態が理解の明確さのために詳しく説明されたが、いくつかの変更形態および修正形態が本開示の範囲内でなされ得ることは明らかである。したがって、記載の実施形態は例示的であって限定的でないと考えるべきであり、特許請求の範囲は本明細書に記載された詳細に限定されず、請求項の範囲および均等物内で修正され得る。特許請求の範囲において、要素および／またはステップは特許請求の範囲に明示的に示されない限り動作の任意の特定の順序を意味しない。

本明細書に記載の様々な実施形態は、コンピュータシステム内に格納されたデータに関わる様々なコンピュータ実施型操作を採用し得る。例えば、これらの操作は、物理量の物理的操作を必要とし得る。通常、必ずしもではないが、これらの量は電気的または磁気的信号の形式を取り得、これらまたはその表現は格納され、転送され、合成され、比較され、またはそうでなければ操作されることができる。さらに、このような操作は、生成、識別、判断、または比較などの用語でしばしば参照される。本開示の１つまたは複数の実施形態の一部をなす本明細書に記載の任意の操作は、有用なマシン操作であり得る。加えて、本開示の１つまたは複数の実施形態はまた、これらの操作を行うためのデバイスまたは装置に関する。上記装置は、特別に必要な目的のために特に構築され得る、またはコンピュータ内に格納されたコンピュータプログラムにより選択的に活性化または構成される汎用コンピュータデバイスであり得る。特に、様々な汎用マシンが、本明細書に記載の説明に従って書かれたコンピュータプログラムと共に使用され得る、または必要な操作を行うためにより専用化された装置を構築することがより好都合であり得る。

本明細書に記載の様々な実施形態は、携帯型デバイス、マイクロプロセッサシステム、マイクロプロセサベースまたはプログラム可能民生電子機器、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成と共に実施され得る。本開示の１つまたは複数の実施形態は、１つまたは複数のコンピュータプログラム、または１つまたは複数のコンピュータ可読媒体内に具現化された１つまたは複数のコンピュータプログラムモジュールとして実施され得る。用語「コンピュータ可読媒体」は、その後コンピュータシステムに入力され得るデータを格納し得る任意のデータ記憶装置を指す。コンピュータ可読媒体は、コンピュータプログラムをコンピュータにより読まれることを可能にする方法で具現化する任意の既存技術または今後開発される技術に基づき得る。コンピュータ可読媒体の例としては、ハードディスクドライブ、ネットワーク付属記憶装置（ＮＡＳ）、読み取り専用メモリ、ランダムアクセスメモリ（例えば、フラッシュメモリデバイス）、ＣＤ−ＲＯＭ（コンパクトディスクＲＯＭ）、ＣＤ−ＲまたはＣＤ−ＲＷ、ＤＶＤ、磁気テープ、他の光学的および非光学的データ記憶装置が挙げられる。コンピュータ可読媒体はまた、コンピュータ可読コードが分散された方法で格納され実行されるように、ネットワーク結合されたコンピュータシステム上に分散され得る。

複数のインスタンスが、単一インスタンスとして本明細書に記載のコンポーネント、操作、または構造に対し設けられ得る。最後に、様々なコンポーネント、操作、データ記憶装置間の境界はある程度任意的であり、特定の操作が特定の例示的構成に関連して示された。機能の他の割り振りが想定され、本開示の範囲に入り得る。一般的に、例示的構成において別個のコンポーネントとして提示された構造と機能は組み合わせられた構造またはコンポーネントとして実現され得る。同様に、単一構成コンポーネントとして提示された構造と機能は別々のコンポーネントとして実現され得る。これらおよび他の変形形態、修正形態、追加形態、および改良形態は添付の特許請求の範囲に入り得る。

Claims (20)

1. 仮想計算環境内のマルチテナント分散計算アプリケーションを実行する方法であって、
   仮想計算環境内で実行している複数の計算クラスタからクラスタ関連メトリックを受信することであって、各計算クラスタが作業負荷スケジューラと複数のワーカノードとを含むことと、
   前記仮想計算環境の性能に関連付けられた資源関連メトリックを受信することであって、前記資源関連メトリックがメモリ関連メトリックおよびＣＰＵ関連メトリックのうちの少なくとも１つを含むことと、
   前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、ホストの計算資源について前記複数の計算クラスタ間の資源競合の状態を判断すること、
   前記資源競合の状態を判断することに応じて、前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小すること、
   資源競合が前記ホスト上に存在しないと判断することに応じて、前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大すること
   を備える方法。
2. 前記資源競合は、前記ホスト上で実行している仮想マシンの未使用ゲストメモリの量を超える当該仮想マシンのメモリ再利用の量に基づいて判断される、請求項１に記載の方法。
3. 前記資源競合は、前記仮想計算環境内の仮想マシンが使用可能状態であったが、物理的ＣＰＵ上で実行されるようにスケジュールできなかった時間のサイクルを示すＣＰＵレディメトリックに基づいて、および前記仮想計算環境内の仮想マシンが当該仮想マシンに代わってシステムサービスを行うために中断された時間のサイクルを示すＣＰＵオーバーラップメトリックに基づいて判断される、請求項１に記載の方法。
4. 初期期間内に電源が入れられたＶＭに関連付けられた前記資源関連メトリックの一部が前記資源競合の状態を判断することから無視される、請求項１に記載の方法。
5. 前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小することはさらに、メモリ競合ＶＭとＣＰＵ競合ＶＭとの両方が前記ホスト上に存在すると判断することに応じて、前記メモリ競合ＶＭを選択することを含む、請求項１に記載の方法。
6. 前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小することはさらに、ＶＭ上で実行しているタスクトラッカーノードの委託を解除して、前記ＶＭの電源を切ることを含み、
   前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大することはさらに、前記ホスト上で実行しているＶＭの電源を入れて、前記ＶＭ上で実行するためにタスクトラッカーを再委託することを含む、請求項１に記載の方法。
7. 前記資源競合の状態は、前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づき制御理論ベースアルゴリズムに従って判断される、請求項１に記載の方法。
8. 第２の組のクラスタ関連メトリックおよび資源関連メトリックを受信すること、
   前記第２の組のクラスタ関連メトリックおよび資源関連メトリックに基づいて、および以前の動作サイクル中に受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、以後の動作サイクル中に資源競合の第２の状態を判断すること
   をさらに備える請求項７に記載の方法。
9. 前記仮想計算環境の性能に関連付けられた前記受信した資源関連メトリックに基づいて１つまたは複数の移動平均を生成すること、
   以後の動作サイクル中に受信した第２の組の資源関連メトリックを当該第２の組の資源関連メトリックが前記移動平均に比べて異常であると判断することに応じて無視すること
   をさらに備える請求項１に記載の方法。
10. プロセッサにより実行可能なコンピュータソフトウェアを格納した非一時的コンピュータ可読記憶媒体であって、
    前記コンピュータソフトウェアは、仮想計算環境内のマルチテナント分散計算アプリケーションを実行するための方法を具現化するものであり、当該方法は、
    仮想計算環境内で実行している複数の計算クラスタからクラスタ関連メトリックを受信することであって、各計算クラスタが作業負荷スケジューラと複数のワーカノードとを含むことと、
    前記仮想計算環境の性能に関連付けられた資源関連メトリックを受信することであって、前記資源関連メトリックがメモリ関連メトリックおよびＣＰＵ関連メトリックのうちの少なくとも１つを含むことと、
    前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、ホストの計算資源について前記複数の計算クラスタ間の資源競合の状態を判断すること、
    前記資源競合の状態を判断することに応じて、前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小すること、
    資源競合が前記ホスト上に存在しないと判断することに応じて、前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大すること
    を含む、非一時的コンピュータ可読記憶媒体。
11. 前記資源競合は、前記ホスト上で実行している仮想マシンの未使用ゲストメモリの量を超える当該仮想マシンのメモリ再利用の量に基づいて判断される、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
12. 前記資源競合は、前記仮想計算環境内の仮想マシンが使用可能状態であったが、物理的ＣＰＵ上で実行されるようにスケジュールできなかった時間のサイクルを示すＣＰＵレディメトリックに基づいて、および前記仮想計算環境内の仮想マシンが当該仮想マシンに代わってシステムサービスを行うために中断された時間のサイクルを示すＣＰＵオーバーラップメトリックに基づいて判断される、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
13. 初期期間内に電源が入れられたＶＭに関連付けられた前記資源関連メトリックの一部が前記資源競合の状態を判断することから無視される、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
14. 前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小することはさらに、メモリ競合ＶＭとＣＰＵ競合ＶＭとの両方が前記ホスト上に存在すると判断することに応じて、前記メモリ競合ＶＭを選択することを含む、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
15. 前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小することはさらに、ＶＭ上で実行しているタスクトラッカーノードの委託を解除して、前記ＶＭの電源を切ることを含み、
    前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大することはさらに、前記ホスト上で実行しているＶＭの電源を入れて、前記ＶＭ上で実行するためにタスクトラッカーを再委託することを含む、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
16. 前記資源競合の状態は、前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づき制御理論ベースアルゴリズムに従って判断される、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
17. 前記方法はさらに、
    第２の組のクラスタ関連メトリックおよび資源関連メトリックを受信すること、
    前記第２の組のクラスタ関連メトリックおよび資源関連メトリックに基づいて、および以前の動作サイクル中に受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、以後の動作サイクル中に資源競合の第２の状態を判断すること
    を含む、請求項１６に記載の非一時的コンピュータ可読記憶媒体。
18. 前記方法はさらに、
    前記仮想計算環境の性能に関連付けられた前記受信した資源関連メトリックに基づいて１つまたは複数の移動平均を生成すること、
    以後の動作サイクル中に受信した第２の組の資源関連メトリックを当該第２の組の資源関連メトリックが前記移動平均に比べて異常であると判断することに応じて無視すること
    を含む、請求項１０に記載の非一時的コンピュータ可読記憶媒体。
19. 仮想計算環境内の分散計算アプリケーションを実行するためのシステムであって、ホストコンピュータシステムが、
    メモリデバイスと、
    プロセッサであって、
    仮想計算環境内で実行している複数の計算クラスタからのクラスタ関連メトリックを受信するステップであって、各計算クラスタが作業負荷スケジューラと複数のワーカノードとを含むステップと、
    前記仮想計算環境の性能に関連付けられた資源関連メトリックを受信するステップであって、前記資源関連メトリックがメモリ関連メトリックおよびＣＰＵ関連メトリックのうちの少なくとも１つを含むステップと、
    前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づいて、ホストの計算資源について前記複数の計算クラスタ間の資源競合の状態を判断するステップと、
    前記資源競合の状態を判断することに応じて、前記ホスト上で少なくとも部分的に実行している前記複数の計算クラスタのうちの少なくとも１つを縮小するステップと、
    資源競合が前記ホスト上に存在しないと判断することに応じて、前記ホスト上で少なくとも部分的に実行していて保留中作業を有する前記複数の計算クラスタのうちの少なくとも１つを拡大するステップと
    を行うようにプログラムされたプロセッサと
    を備える、システム。
20. 前記資源競合の状態は、前記受信したクラスタ関連メトリックおよび資源関連メトリックに基づき制御理論ベースアルゴリズムに従って判断される、請求項１９に記載のシステム。