JP2017506776A - ラックスケールアーキテクチャコンピューティングシステムのためのワークロード最適化、スケジューリング及び配置 - Google Patents

Abstract

データセンタ管理のための複数の技術は、それぞれがラックコントローラを含む１又は複数のコンピューティングラックを含む。ラックコントローラは、コンピューティングラックの複数の要素について、システム、性能、又は健全性測定基準を受信してよい。ラックコントローラは、コンポーネント寿命を予測する回帰モデルを生成し、含まれるハードウェアコンポーネントの寿命に基づいて、論理的な機械寿命を予測してよい。ラックコントローラは、残っている要素又は論理的機械寿命に基づいて、複数の通知を生成してよく、又はメンテナンスセッションを計画してよい。ラックコントローラは、複数の論理マシンを、同様の残りの寿命を有する複数の要素を用いて構成してよい。いくつかの実施形態において、ラックコントローラは、コンポーネント故障の確率に基づいて、アプリケーションを実行する前にサービスレベルアグリーメントを認証してよい。管理インタフェースは、システム状態のインタラクティブな可視化を生成してよく、可視化に対して応答する人間の入力から派生した複数の最適化ルールに基づいて、データセンタスケジュールを最適化してよい。他の複数の実施形態が記載され、特許請求される。

Description

［関連する応用に対する相互参照］ 本出願は、米国特許法第１１９条（ｅ）の定めにより、２０１４年２月２７日に出願された「ＷＯＲＫＬＯＡＤ ＯＰＴＩＭＩＺＡＴＩＯＮ ＦＯＲ ＲＡＣＫ ＣＯＭＰＵＴＩＮＧ ＡＲＣＨＩＴＥＣＴＵＲＥＳ」と題する米国特許仮出願第６１／９４５，５８８号及び２０１４年２月２７日に同様に出願された「ＧＲＡＹ ＢＯＸ ＯＰＴＩＭＩＺＡＴＩＯＮ ＦＯＲ ＤＡＴＡＣＥＮＴＥＲ ＷＯＲＫＬＯＡＤ ＳＣＨＥＤＵＬＩＮＧ ＡＮＤ ＰＬＡＣＥＭＥＮＴ」と題する米国特許仮出願第６１／９４５，５９７号の優先権を主張する。

「クラウド」コンピューティングとは、サービスとしての複数のコンピューティングリソースのプロビジョニングを指すのにしばしば用いられる用語であり、通常は、複数のサービスが要求される場所から離れた場所で共にネットワーク接続される多数のコンピュータサーバによって行われる。クラウドデータセンタは、通常、クラウド又はクラウドの特定の一部を成す複数のサーバの物理的配置を指す。例えば、複数のサーバは、データセンタにおいて複数の空間、グループ、列及びラックへと物理的に配置され得る。データセンタは、複数のサーバの１又は複数の空間を含み得る１又は複数のゾーンを有してよい。各空間は、１又は複数の列のサーバを有してよく、各列は、１又は複数のラックを含んでよい。各ラックは、１又は複数の個々のサーバノードを含んでよい。ゾーン、空間、ラック及び／又は列内のサーバは、電力、エネルギー、熱、温度及び／又は複数の他の要件を含み得るデータセンタ施設の複数の物理的インフラストラクチャ要件に基づいて、複数の仮想グループへと配置され得る。

クラウドコンピューティングの人気が増すにつれて、顧客は、複数のクラウドサービスプロバイダにそれらの契約の範囲内でサービスレベルアグリーメント（ＳＬＡ）を含むようにますます要求する。そのような複数のＳＬＡは、複数のクラウドサービスプロバイダに、１又は複数の測定基準（例えば、システムアップタイム、スループット等）で測定され得る少なくとも特定のレベルのサービスを顧客に提供することに同意するよう要求する。（サービス配信目標（ＳＤＯ）及びサービスレベル目標（ＳＬＯ）のゴールを含む）複数のＳＬＡゴール、複数の効率ターゲット、複数のコンプライアンス目標、複数の施設を含む複数のエネルギーターゲット、及び複数の他の環境及びコンテクスト上の制約もまた全て考慮され得る。そのような複数の取り決めを満たすためには、複数のクラウドサービスプロバイダが、複数の物理的サーバ及び／又は複数のノードもしくはリソースの間での複数の顧客ワークロードを同じサーバ上で最適に割り当てることが重要である。しかしながら、典型的にはそのような割り当ては、新たな、又は保留中のワークロードが生成される場合にどの複数のリソースが利用可能であるかに基づいており、それがハードウェア故障の確率を考慮しない。それは、サービスプロバイダがＳＬＡを満たすことをできなくさせ得る。

ブラックボックスの最適化は、多数の領域で応用されてきたが、設計者及び／又は制御者のループ中に人間を含むための問題及び必要性の動的な発展性により、計算の最適化が首尾よく適用されてこなかった多くの状況が未だにある。従来の複数の最適化アルゴリズムは、複数の厳格な制約、例えばカッティング及びパッキングアルゴリズムの（例えば、標準の輸送コンテナに格納された複数の物理的商品の最も有益な組み合わせを決定すること）に対処してよい。例えば、混合整数の問題解決は、複数の厳格な制約を対処してよい従来のアルゴリズムの１つの代表的な例である。ブラックボックスの最適化の複数の解決策は、問題がアルゴリズムで、複数の特定の領域のコンテクストの詳細を概して参照することなく記載されるように要求し得る。従って、これらのシステムは、ユーザ規定の知識を容易には統合しなくてよく、又は動的な複数の変更を検出もしくは考慮しなくてもよい。加えて、複数のブラックボックスの最適化アルゴリズムは、全てのユーザには直接アクセス可能又は閲覧可能でなくてもよい。

本明細書において記載される複数の概念は、例として示されるものであり、添付の複数の図において限定の目的で示されるものではない。説明を簡潔かつ明確にすべく、複数の図において示される複数の要素は必ずしも縮尺どおりに描かれてはいない。適切とみなされる場合には、複数の参照ラベルは、複数の対応する又は類似の要素を示すために、複数の図の間で繰り返されている。

ラックスケールコンピューティングアーキテクチャにおけるワークロード最適化、スケジューリング、及び配置のためのシステムの少なくとも１つの実施形態の簡易ブロックダイアグラムである。

図１のシステムのラックコントローラの環境の少なくとも１つの実施形態の簡易ブロックダイアグラムである。

図１及び図２のラックコントローラによって実行され得るデータセンタ管理の方法の少なくとも１つの実施形態の簡略化したフロー図である。

図１のシステムのいくつかの環境の少なくとも１つの実施形態の簡易ブロックダイアグラムである。

図１及び図４のラックコントローラによって実行され得るワークロード最適化、スケジューリング、及び配置の方法の少なくとも１つの実施形態の簡略化したフロー図である。

図１及び図４の性能データサーバによって実行され得る予測ワークロードデータ取得の方法の簡略化したフロー図である。

図１及び図４のラックコントローラによって実行され得る性能監視の方法の少なくとも１つの実施形態の簡略化したフロー図である。

図１及び図４の性能データサーバによって実行され得る性能データ管理の方法の簡略化したフロー図である。

図１及び図４のシステムによって実行され得るワークロードスケジューリング及び配置を最適化するための方法の簡略化したフロー図である。

本開示の複数の概念は、様々な変更及び代替的な形態に影響されやすい一方で、それらの複数の具体的な実施形態は、複数の図面において例として示され、本明細書で詳細に記載されるであろう。しかしながら、本開示の複数の概念を開示された特定の複数の形態に限定する意図はなく、反対に、本開示及び添付された特許請求の範囲に一致する全ての変更、均等物及び代替物を包含することを意図することが理解されるべきである。

明細書における「一実施形態」、「実施形態」、「例示的な実施形態」等についての複数の言及は、記載される実施形態が特有の機能、構造又は特性を含み得ることを示しているが、いずれの実施形態も、それら特有の機能、構造または特性を含んでもよく、又は、必ずしも含まなくてもよい。さらに、そのような複数の語句は、必ずしも同じ実施形態を指すわけではない。さらに、特定の機能、構造または特性が、ある実施形態と関連して記載される場合、明示的に記載されているか否かに関わらず、このような特徴、構造または特性を他の複数の実施形態に関連してもたらすことは、当業者の知識の範囲内にあるとされる。加えて、「少なくとも１つのＡ、Ｂ、及びＣ」の形におけるリストに含まれる複数のアイテムは、（Ａ）、（Ｂ）、（Ｃ）、（Ａ及びＢ）、（Ａ及びＣ）、（Ｂ及びＣ）、又は（Ａ、Ｂ、及びＣ）を意味し得るものとして理解されるべきである。同様、「Ａ、Ｂ、又はＣの少なくとも１つ」の形で列挙された複数のアイテムは、（Ａ）、（Ｂ）、（Ｃ）、（Ａ及びＢ）、（Ａ及びＣ）、（Ｂ及びＣ）又は（Ａ、Ｂ、及びＣ）を意味し得る。

開示される複数の実施形態は、場合によっては、ハードウェア、ファームウェア、ソフトウェア、又は、それらの任意の組み合わせにおいて実装されてもよい。開示される複数の実施形態は、また、１又は複数のプロセッサによって読み取られ実行され得る、１又は複数の一時的又は非一時的機械可読（例えば、コンピュータ可読）記憶媒体によって運ばれる又はそれに格納されている複数の命令として実装されてよい。機械可読記憶媒体は、任意のストレージデバイス、メカニズム、又は機械によって可読な形態で情報を格納又は送信するための他の物理的構造（例えば、揮発性または不揮発性メモリ、メディアディスク又は他のメディアデバイス）として具現化されてもよい。

複数の図面において、いくつかの構造的又は方法の特徴が、複数の具体的な配置及び／又は順序で示されてよい。しかしながら、そのような複数の具体的な配置及び／又は複数の順序が必要とされなくてもよいことが理解されるべきである。むしろ、いくつかの実施形態において、そのような特徴は、例示的な複数の図において示されるものとは異なる態様及び／又は順序で構成されてもよい。加えて、特定の図において構造的又は方法の特徴を含むことにより、そのような特徴が全ての実施形態で必要とされることの示唆は意味しておらず、いくつかの実施形態では含まれなくてよく、又は、他の複数の特徴と組み合わされてもよい。

ここで図１を参照すると、例示的な実施形態において、ワークロード最適化、スケジューリング及び配置のためのシステム１００は、ネットワーク１０８を介して通信している数個のコンピューティングラック１０２、管理インタフェース１０４、性能データサーバ１０６を含む。使用中、コンピューティングラック１０２のコントローラコンポーネントは、コンピューティングラック１０２のハードウェアコンポーネントに関連付けられたシステム測定基準、性能測定基準又は健全性測定基準を監視してよい。コントローラコンポーネントは、各要素について平均故障間隔値を予測するために用いられてよい各ハードウェアコンポーネントのための回帰モデルを決定する。コントローラコンポーネントは、また、コンピューティングラック１０２の複数のハードウェアコンポーネントで構成される各論理マシンについて、平均故障間隔値を決定してよい。コントローラコンポーネントは、例えば、複数の適切な警告又はアラームを生成し、メンテナンスセッションをスケジューリングし、あるいは同様の残りの寿命を持つ複数のコンポーネントから複数の論理マシンを構成することで、平均故障間隔値に基づいてコンピューティングラック１０２又はシステム１００を管理してよい。従って、システム１００は効率を改善し、複数のコンピューティングラック１０２のための複数のメンテナンスセッションの頻度を減らしてよい。

加えて、又は代替的に、コンピューティングラック１０２のコントローラコンポーネントは、使用中、実行されることになっているアプリケーションの記述を性能データサーバ１０６に送信してよい。それに応答して性能データサーバ１０６は、そのアプリケーション記述に関連付けられた予測ワークロードデータを送信する。予測ワークロードデータは、記述されたアプリケーションを実行することに関連付けられたコンピューティングラック１０２の様々なハードウェアコンポーネントについての複数の使用パターンを示す。性能データサーバ１０６は、多くのコンピューティングラック１０２から受信されたそのアプリケーションについての履歴ワークロードデータに基づいて、ワークロードデータを決定してよい。各コンピューティングラック１０２は、複数のハードウェア監視要素を用いて多数の性能測定基準を監視してよい。予想されるワークロードデータに基づいて、コンピューティングラック１０２は、アプリケーションに関連付けられたハードウェア故障の確率（例えば、予め定められた期間アプリケーションを実行する間に複数の特定のハードウェアコンポーネントが故障し得る確率）を決定する。故障の確率に基づいて、コンピューティングラック１０２は、複数の特定のハードウェアコンポーネント（例えば、最も低い故障の確率を持つ複数の要素）による実行のためのアプリケーションを計画してよく、またはアプリケーションに関連付けられた１又は複数のサービスレベルアグリーメントを検証してよい。従って、システムオペレータ（例えば、クラウドサービスプロバイダ、管理者等）は、顧客のアプリケーションによって、そのアプリケーションが実行される前に表されると予期される負荷のもとで、顧客のサービスレベルアグリーメント（ＳＬＡ）をハードウェアコンポーネントの予期される寿命に一致させてよい。

加えて、又は代替的に、コンピューティングアプリケーション又は他の複数のワークロードは、使用中、システム１００の利用可能な複数のコンピューティング要素（例えば、複数の計算ノード、メモリ、ストレージ、又はネットワーキング）を用いて任意の数のコンピューティングラック１０２に分散されてよい。管理インタフェース１０４は、例えば、複数のコンピューティングラック１０２の複数のコンピューティング要素の間における複数のワークロードの現在の分散及びスケジューリングを含む、現在のシステム状態のインタラクティブな可視化を生成する。管理インタフェース１０４は、可視化に応答して受信された人間の入力を、多数の機械可読のユーザ規定の最適化ルールに変換する。管理インタフェース１０４は、複数のユーザ規定の最適化ルール並びに複数の予め定められたゴール及び制約を用いてデータセンタワークロードを最適化（すなわち、システム１００の複数のコンピューティング要素の間の複数のワークロードの配置及び／又はスケジューリングを最適化）する。ワークロードを最適化した後、管理インタフェース１０４は、システム状態をリフレッシュし、可視化及び最適化を繰り返す。従って、システム１００は、複数の最適化アルゴリズムとの直観的な人間のインタラクションをサポートする「グレイボックスの最適化」システムであってよく、これにより、（最適化以外の分野の専門家を含む）複数のエンドユーザは、開発された解決策を改善するべくコンテクストの及び暗黙的な知識を最適化アルゴリズムに分け与える。システム１００は、非常にヘテロジニアスである（すなわち、細分類された及び／又はモジュール式の）データセンタ環境における複数の内部（例えば、効率）及び／又は外部（例えば、サービス配信目標）の複数の制約を用いて、ワークロードの改善されたスケジューリング及び配置を可能にし得る。加えて、システム１００は、複数のサービスプロバイダが、動作のコストを密に管理する一方でシステム１００の全てのコンピューティング要素から最適に利益を得るサービスプロバイダの能力によって、複数の顧客に広範囲のサービスレベル及び複数のテンプレートを提供することを可能にし得る。加えて、管理インタフェース１０４により実行されるとして記載されたが、いくつかの実施形態では、それらの機能のいくつか又は全ては、１又は複数のコンピューティングラック１０２等、システム１００の複数の他の要素によって実行され得る。

各コンピューティングラック１０２は、本明細書に記載される複数の機能を単独又は複数の他のコンピューティングラック１０２と組み合わせて実行することができるモジュール式コンピューティングデバイスとして具現化されてよい。例えば、コンピューティングラック１０２は、複数の計算トレイ、複数のストレージトレイ、複数のネットワークトレイ等、複数のラック取付けモジュール式コンピューティングユニット用の筐体、又は複数のサーバもしくはスイッチ等、従来のラックが搭載された複数の要素等として具現化されてよい。図１に示されるように、各コンピューティングラック１０２は、プールされたコンピュートエンクロージャ１２４（ｃｏｍｐｕｔｅ ｅｎｃｌｏｓｕｒｅ）、プールされたメモリエンクロージャ１３０、プールされたストレージエンクロージャ１３６、及びプールされたネットワークエンクロージャ１４２に結合されたラックコントローラ１２０及び相互接続１２２を例示的に含む。当然のことながら、各コンピューティングラック１０２は、複数の他の実施形態におけるサーバデバイス（例えば、電力分散システム、冷却システム、または様々な入出力デバイス）において一般に見られるもの等、複数の他の又は追加のコンポーネントを含んでよい。

いくつかの実施形態において、ラックコントローラ１２０、プールされたコンピュートエンクロージャ１２４、プールされたメモリエンクロージャ１３０、プールされたストレージエンクロージャ１３６、及びプールされたネットワークエンクロージャ１４２のそれぞれは、トレイ、拡張ボード、もしくはブレード、又は任意の他のフォームファクタとして具現化されてよいことは理解されるべきである。複数のそのような実施形態において、各エンクロージャは、アプリケーション又はワークロードに割り当てられ得る任意の数のコンピューティング要素を含んでよい。コンピューティングラック１０２が複数のトレイ、複数のブレード、又は複数の拡張ボードを含む複数の実施形態において、個々の要素は、置き換えられるか又はアップグレードされてよく、「ホットスワップ対応」のものであってよいことは理解されるべきである。例えば、いくつかの実施形態において、プールされたコンピュートエンクロージャ１２４は、複数のプロセッサ及び／又は処理／制御回路を含むＣＰＵトレイとして具現化されてよい。複数のそのような実施形態において、追加の処理電力が、プールされたコンピュートエンクロージャ１２４を、より新しい及び／又はより有力な複数のプロセッサを含む別のプールされたコンピュートエンクロージャ１２４によりスワップアウトすることによってコンピューティングラック１０２に追加されてよい。

プールされたコンピュートエンクロージャ１２４は、計算トレイ、拡張ボード、ブレード、筐体、又は他のモジュール式ユニット等の任意のモジュール式コンピューティングユニットとして具現化されてよい。プールされたコンピュートエンクロージャ１２４は、１又は複数のプロセッサ１２６を含んでよい。例えば、プールされたコンピュートエンクロージャ１２４は、それぞれが１又は複数のプロセッサ１２６を含む多数の計算モジュール又はノードとして具現化されてよい。各プロセッサ１２６は、本明細書に記載された複数の機能を実行することが可能な任意のタイプのプロセッサとして具現化されてよい。例えば、各プロセッサは、１又は複数のシングルコアもしくはマルチコアプロセッサ、デジタル信号プロセッサ、マイクロコントローラ、又は他のプロセッサもしくは処理／制御回路として具現化されてよい。プロセッサ１２６は、ヘテロジニアスであってよい。例えば、複数のプロセッサ１２６のいくつかは、高性能サーバプロセッサとして具現化されてよく、その他の複数のプロセッサ１２６は、より高密度の配置に好適な複数の低電力のプロセッサとして具現化されてよい。プールされたコンピュートエンクロージャ１２４は、測定基準コンポーネント１２８を含んでよい。測定基準コンポーネント１２８は、プールされたコンピュートエンクロージャ１２４のプロセッサ１２６及び／又は複数の他のコンポーネントの複数の性能測定基準を生成、測定、又はそうでなければキャプチャすることが可能な任意の性能カウンタ、性能監視ユニット、又は他のハードウェアモニタとして具現化されてよい。

プールされたメモリエンクロージャ１３０は、メモリトレイ、拡張ボード、ブレード、筐体、又は他のモジュール式ユニット等の任意のモジュール式のメモリユニットとして具現化されてよい。プールされたメモリエンクロージャ１３０は、プールされたメモリ１３２を含む。プールされたメモリ１３２は、プールされたコンピュートエンクロージャ１２４の１又は複数のプロセッサ１２６による使用のために分割され、配分され、又はそうでなければ割り当てられることが可能である任意のメモリとして具現化されてよい。例えば、プールされたメモリ１３２は、多数の従来のＲＡＭ ＤＩＭＭ等、揮発性もしくは不揮発性メモリに結合されたプールされたメモリコントローラとして具現化されてよい。動作中、プールされたメモリエンクロージャ１３０は、複数のオペレーティングシステム、複数の仮想機械モニタ、及び複数のユーザワークロード等、コンピューティングラック１０２の動作中に用いられる様々なデータ及びソフトウェアを格納してよい。プールされたメモリエンクロージャ１３０は、測定基準コンポーネント１３４を含んでよい。測定基準コンポーネント１３４は、プールされたメモリエンクロージャ１３０のプールされたメモリ１３２及び／又は複数の他のコンポーネントの複数の性能測定基準を生成、測定、又はそうでなければキャプチャすることができる任意の性能カウンタ、性能監視ユニット、又は他のハードウェアモニタとして具現化されてよい。

同様に、プールされたストレージエンクロージャ１３６は、ストレージトレイ、拡張ボード、ブレード、筐体、又は他のモジュール式ユニット等、任意のモジュール式ストレージユニットとして具現化されてよい。プールされたストレージエンクロージャ１３６は、プールされたストレージ１３８を含む。プールされたストレージ１３８は、プールされたコンピュートエンクロージャ１２４のプロセッサ１２６の１又は複数による使用のために分割され、割り当てられ、又はそうでなければ割り当てられることが可能な任意のタイプのデータストレージとして具現化されてよい。例えば、プールされたストレージ１３８は、１又は複数のメモリデバイス及び回路、メモリカード、ハードディスクドライブ、ソリッドステートドライブ、又は他のデータストレージデバイスとして具現化されてよい。例えば、プールされたストレージ１３８は、コンピューティングラック１０２によって初期化及び／又は実行されることになっている１又は複数のオペレーティングシステムを格納するように構成されてよい。プールされたストレージエンクロージャ１３６は、測定基準コンポーネント１４０を含んでよい。測定基準コンポーネント１４０は、プールされたストレージエンクロージャ１３６のプールされたストレージ１３８及び／又は他のコンポーネントの複数の性能測定基準を生成、測定、又はそうでなければキャプチャすることが可能な任意の性能カウンタ、性能監視ユニット、又は他のハードウェアモニタとして具現化されてよい。

同様に、プールされたネットワークエンクロージャ１４２は、ネットワークトレイ、拡張ボード、ブレード、筐体、又は他のモジュール式ユニット等、任意のモジュール式ネットワークユニットとして具現化されてよい。プールされたネットワークエンクロージャ１４２は、複数のプールされたネットワークデバイス１４４を含む。プールされたネットワークデバイス１４４は、プールされたコンピュートエンクロージャ１２４のプロセッサ１２６の１又は複数による使用のために分割され、割り当てられ、又はそうでなければ割り当てられることが可能な、任意の通信回路、デバイス、又はそれらの集合として具現化されてよい。例えば、プールされたネットワークデバイス１４４は、任意の数のネットワークインタフェースポート、カード、又はスイッチとして具現化されてよい。いくつかの実施形態において、プールされたネットワークデバイス１４４は、ソフトウェア規定のネットワーク（ＳＤＮ）において動作することが可能であってよい。プールされたネットワークデバイス１４４は、任意の１又は複数の通信技術（例えば、有線又は無線通信）及び複数の関連するプロトコル（例えばイーサネット（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ‐Ｆｉ（登録商標）、ＷｉＭＡＸ等）を用いて、そのような通信をもたらすように構成され得る。

プールされたコンピュートエンクロージャ１２４、プールされたメモリエンクロージャ１３０、プールされたストレージエンクロージャ１３６、及びプールされたネットワークエンクロージャ１４２は、相互接続１２２を介して互いに、且つ複数の他のコンピューティングラック１０２に結合されている。相互接続１２２は、コンピューティングラック１０２の複数のコンピューティング要素間のデータ転送を容易にするべく、複数のメモリコントローラハブ、入出力コントロールハブ、ファームウェアデバイス、通信リンク（すなわち、ポイントツーポイントリンク、バスリンク、ワイヤ、ケーブル、ライトガイド、プリント回路基板トレース等）及び／又は複数の他のコンポーネント及びサブシステムとして具現化されてよく、又はそうでなければそれらを含んでよい。例えば、いくつかの実施形態において、相互接続１２２は、シリコンフォトニックスイッチファブリック及び多数の光相互接続として具現化されてよく、又はそれらを含んでよい。加えて、又は代替的に、いくつかの実施形態において、相互接続１２２は、トップオブラックスイッチ（ｔｏｐ−ｏｆ−ｒａｃｋ ｓｗｉｔｃｈ）として具現化されてよく、又はそれを含んでよい。

ラックコントローラ１２０は、コンピューティングラック１０２のためのワークロード管理及びオーケストレーション（ｏｒｃｈｅｓｔｒａｔｉｏｎ）機能を実行することができ、及びそうでなければ本明細書において記載される複数の機能を実行することができる任意のコンピューティングノード又は他のコンピューティングデバイスとして具現化されてよい。例えば、ラックコントローラ１２０は、１又は複数のコンピュータサーバ、埋め込み型コンピューティングデバイス、管理された複数のネットワークデバイス、管理された複数のスイッチ、又は複数の他の計算デバイスとして具現化されてよい。いくつかの実施形態において、ラックコントローラ１２０は、例えばトップオブラックスイッチにおいて、相互接続１２２に組み込まれてよく、又はそうでなければそれと組み合わされてよい。

上記のように、いくつかの実施形態において、システム１００は、管理インタフェース１０４を含んでよい。管理インタフェース１０４は、ユーザがシステム１００を編成し、運営し、又はそうでなければ管理するためのインタラクティブなインタフェースを提供するように構成されている。管理インタフェース１０４は、コンピュータ、マルチプロセッサシステム、サーバ、ラックマウント式サーバ、ブレードサーバ、ラップトップコンピュータ、ノートブックコンピュータ、タブレットコンピュータ、ウェアラブルコンピューティングデバイス、ネットワーク機器、ウェブ機器、分散コンピューテイングシステム、プロセッサベースのシステム及び／又は家庭用電子機器を限定することなく含む、本明細書に記載される複数の機能を実行することが可能な任意のタイプの計算デバイス又はコンピュータデバイスとして具現化されてよい。いくつかの実施形態において、管理インタフェース１０４は、例えばいくつか又は全ての計算機能が複数のコンピューティングラック１０２により実行され、且つ複数のユーザインタフェース機能が管理インタフェース１０４により実行される分散システムとして具現化されてよい。加えて、いくつかの実施形態において、管理インタフェース１４０は、ネットワーク１０８をわたって分散された複数のコンピューティングデバイスから形成され、パブリック又はプライベートクラウドにおいて動作する「仮想サーバ」として具現化されてよい。従って、管理インタフェース１０４は、単一サーバコンピューティングデバイスとして具現化されることが図１に示されるが、管理インタフェース１０４は、以下に記載される機能を容易にするべく共に協働する複数のデバイスとして具現化されてよいことは理解されるべきである。図１に示されるように、管理インタフェース１０４は、プロセッサ１４０、入出力サブシステム１４２、メモリ１４４、データストレージデバイス１４６、及び通信回路１４８を例示的に含む。当然のことながら、管理インタフェース１０４は、複数の他の実施形態において、ワークステーションにおいて一般に見られる複数のもの（例えば、様々な入出力デバイス）等、複数の他の又は追加のコンポーネントを含んでよい。加えて、いくつかの実施形態において、複数の例示的な要素のうち１又は複数は、別の要素に組み込まれてよく、又はそうでなければその一部を形成してもよい。例えば、メモリ１４４又はそれらの複数部分は、いくつかの実施形態において、プロセッサ１４０に組み込まれてよい。

プロセッサ１４０は、本明細書において記載される複数の機能を実行することが可能な任意のタイプのプロセッサとして具現化されてよい。プロセッサ１４０は、１又は複数のシングルコアもしくはマルチコアプロセッサ、デジタル信号プロセッサ、マイクロコントローラ、又は他のプロセッサもしくは処理／制御回路として具現化されてよい。同様に、メモリ１４４は、本明細書において記載される複数の機能を実行することが可能な任意のタイプの揮発性または不揮発性メモリ又はデータストレージとして具現化されてよい。動作中、メモリ１４４は、複数のオペレーティングシステム、複数のアプリケーション、複数のプログラム、複数のライブラリ、及び複数のドライバ等、管理インタフェース１０４の動作中に用いられる様々なデータ及びソフトウェアを格納してよい。メモリ１４４は、管理インタフェース１０４のプロセッサ１４０、メモリ１４４、及び複数の他のコンポーネントを用いて複数の入出力操作を容易にするべく、電気回路及び／又は複数の要素として具現化され得るＩ／Ｏサブシステム１４２を介して、プロセッサ１４０に通信可能に結合される。例えば、Ｉ／Ｏサブシステム１４２は、入出力操作を容易にするべく、複数のメモリコントローラハブ、複数の入出力コントロールハブ、複数の統合センサハブ、複数のファームウェアデバイス、複数の通信リンク（すなわち、複数のポイントツーポイントリンク、複数のバスリンク、複数のワイヤ、複数のケーブル、複数のライトガイド、複数のプリント回路基板トレース等）及び／又は複数の他のコンポーネント及びサブシステムとして具現化されてよく、又はそうでなければそれらを含んでよい。いくつかの実施形態において、Ｉ／Ｏサブシステム１４２は、システムオンチップ（ＳｏＣ）の一部を形成してよく、管理インタフェース１０４のプロセッサ１４０、メモリ１４４及び複数の他のコンポーネントと共に単一の統合回路チップ上に組み込まれてよい。

データストレージデバイス１４６は、例えば、複数のメモリデバイス及び回路、複数のメモリカード、複数のハードディスクドライブ、複数のソリッドステートドライブ、又は、複数の他のデータストレージデバイス等の、データの短期間もしくは長期間保存用に構成された任意のタイプのデバイスまたは複数のデバイスとして具現化されてもよい。管理インタフェース１０４の通信回路１４８は、ネットワーク経由１０８を介して管理インタフェース１０４、複数のコンピューティングラック１０２及び／又は複数の他のリモートデバイスの間における複数の通信を可能にすることができる任意の通信回路、デバイス、又はそれらの集合として具現化されてよい。通信回路１４８は、任意の１又は複数の通信技術（例えば、有線又は無線通信）及び複数の関連するプロトコル（例えばイーサネット（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ‐Ｆｉ（登録商標）、ＷｉＭＡＸ等）を用いて、そのような通信をもたらすように構成され得る。

管理インタフェース１０４は、ディスプレイ１５０をさらに含む。管理インタフェース１０４のディスプレイ１５０は、液晶ディスプレイ（ＬＣＤ）、発光ダイオード（ＬＥＤ）、プラズマディスプレイ、ブラウン管（ＣＲＴ）又は他のタイプのディスプレイデバイス等のデジタル情報を表示することが可能な任意のタイプのディスプレイとして具現化されてよい。以下にさらに記載されるように、ディスプレイ１５０は、システム１００の管理用のインタラクティブグラフィカルユーザインタフェースを提示してよい。

上記のように、いくつかの実施形態において、システム１００は、性能データサーバ１０６を含んでよい。性能データサーバ１０６は、ワークロードデータを特定のアプリケーション記述に関連付けるアプリケーション性能データベース１６０を維持するように構成される。性能データサーバ１０６は、コンピュータ、マルチプロセッサシステム、サーバ、ラックマウント式サーバ、ブレードサーバ、ラップトップコンピュータ、ノートブックコンピュータ、タブレットコンピュータ、ウェアラブルコンピューティングデバイス、ネットワーク機器、ウェブ機器、分散コンピューテイングシステム、プロセッサベースのシステム及び／又は家庭用電子機器を限定することなく含む、本明細書に記載される複数の機能を実行することが可能な任意のタイプの計算もしくはコンピュータデバイスとして具現化されてよい。性能データサーバ１０６は、サーバ又はプロセッサ、Ｉ／Ｏサブシステム、メモリ、データストレージデバイス、通信回路及び／又は他の複数の周辺機器等、同様のコンピューティングデバイスにおいて一般に見られる複数の要素及びデバイスを含んでよい。性能データサーバ１０６のそれらの個々の要素は、複数のコンピューティングラック１０２及び／又は管理インタフェース１０４の対応する複数のコンポーネントに類似してよく、その記述は、性能データサーバ１０６の対応する複数のコンポーネントに適用可能であり、本開示を不明確にしないように本明細書では繰り返されない。加えて、いくつかの実施形態において、性能データサーバ１０６は、ネットワーク１０８にわたって分散される複数のコンピューティングデバイスから形成され、パブリック又はプライベートクラウドにおいて動作する「仮想サーバ」として具現化されてよい。従って、性能データサーバ１０６は、単一サーバコンピューティングデバイスとして具現化されることが図１に示されるが、性能データサーバ１０６は、以下に記載される複数の機能を容易にするべく共に協働する複数のデバイスとして具現化されてよいことは理解されるべきである。

以下においてより詳細に検討されるように、複数のコンピューティングラック１０２、管理インタフェース１０４及び性能データサーバ１０６は、ネットワーク１０８を介して、互いに及び／又はシステム１００の複数の他のデバイスとデータを送受信するように構成されてよい。ネットワーク１０８は、任意の数の様々な有線及び／又は無線ネットワークとして具現化されてよい。例えば、ネットワーク１０８は、有線又は無線ローカルエリアネットワーク（ＬＡＮ）、有線又は無線ワイドエリアネットワーク（ＷＡＮ）、セルラーネットワーク及び／又はインターネット等、公にアクセス可能なグローバルネットワークとして具現化されてよく、又はそうでなければそれらを含んでよい。そのように、ネットワーク１０８は、システム１００の複数のデバイス間の複数の通信を容易にするべく、追加の複数のコンピュータ、複数のルータ、及び、複数のスイッチ等の任意の数の追加デバイスを含んでよい。

ラックスケールアーキテクチャ（ＲＳＡ）システムとして示されているが、複数の他の実施形態において、システム１００は、従来のデータセンタ、コンピューティングクラスタ、又は複数のコンピューティングマシンの他の集合として具現化されてよい。例えば、システム１００は、ネットワークを介して通信においてラックマウントの又は独立している多数の計算ノード、ネットワーク切り替えファブリック、ストレージエリアネットワーク、クラウドコントローラ、又は他の複数の典型的なデータセンタ要素を含んでよい。加えて、いくつかの実施形態において、１又は複数の例示的な要素が別の要素に組み込まれてよく、又はそうでなければその一部を形成してよい。例えば、１又は複数のプールされたメモリエンクロージャ１３０又はそれらの複数部分は、いくつかの実施形態において、複数のプールされたコンピュートエンクロージャ１２４の１又は複数に組み込まれてよい。同様に、各コンピューティングラック１０２は、単一のプールされたコンピュートエンクロージャ１２４、プールされたメモリエンクロージャ１３０、プールされたストレージエンクロージャ１３６及びプールされたネットワークエンクロージャ１４２を含むとして示されているが、各コンピューティングラック１０２は、それらのモジュール式エンクロージャのうち任意の数のモジュール式エンクロージャ及び／又はそれらの任意の組み合わせを含んでよいことは理解されるべきである。

ここで図２を参照すると、例示的な実施形態においてラックコントローラ１２０は、環境２００を動作中に確立する。例示的な環境２００は、性能監視モジュール２０２、分析モジュール２０４及びデータセンタ管理モジュール２１０を含む。環境２００の様々なモジュールは、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせとして具現化されてよい。例えば、環境２００の複数のモジュール、論理及び複数の他のコンポーネントのそれぞれは、ラックコントローラ１２０のプロセッサ又は他の複数のハードウェアコンポーネントの一部を形成してよく、又はそうでなければそれらによって確立されてよい。そのように、いくつかの実施形態において、環境２００の複数のモジュールのうち１又は複数は、複数の電気デバイスの回路又は集合（例えば、性能監視回路、解析回路等）として具現化されてよい。加えて、又は代替的に、いくつかの実施形態において、環境２００の一部又は全ては、１又は複数のプールされたコンピュートエンクロージャ１２４又は複数のコンピューティングラック１０２の複数の他のコンポーネントによって等、システム１００の他の複数のエンティティ（ｅｎｔｉｔｙ）によって確立されてよい。

性能監視モジュール２０２は、コンピューティングラック１０２の複数のハードウェアコンポーネントと関連付けられた複数の測定基準を受信するように構成されている。複数のハードウェアコンポーネントは、複数の計算リソース、複数のメモリリソース、複数のストレージリソース及び／又は複数のネットワークリソースを含んでよい。以下にさらに記載されるように、複数の測定基準は、複数のシステム測定基準、複数の性能測定基準及び／又は複数の健全性測定基準を含んでよい。いくつかの実施形態において、性能監視モジュール２０２は、また、複数のサービスに関連付けられた複数の性能指標又はコンピューティングラック１０２により実行される複数の他のコンピューティングアプリケーションを受信するように構成されてもよい。

分析モジュール２０４は、関連する複数の測定基準に基づいて、コンピューティングラック１０２の各ハードウェアコンポーネントのための回帰モデルを決定するように構成されている。分析モジュール２０４は、関連する回帰モデルに基づいて各ハードウェアコンポーネントについての平均故障時間（ＭＴＴＦ）値を決定し、複数のハードウェアコンポーネントから構成される論理マシンについてのＭＴＴＦ値を決定するようにさらに構成されている。平均故障時間は、複数のサービス保証の品質又は１又は複数のサービスレベルアグリーメントによって確立される他の複数のサービス配信目標に基づいてよい。分析モジュール２０４は、複数のハードウェアコンポーネント及び／又は複数の論理マシンについてのＭＴＴＦ値を含む１又は複数のＭＴＴＦテーブルを維持してよい。分析モジュール２０４のそれらの機能は、１又は複数のサブモジュールによって、例えばＭＴＴＦテーブルモジュール２０６又はサービスレベルアグリーメント（ＳＬＡ）モジュール２０８によって、実行されてよい。

データセンタ管理モジュール２１０は、コンピューティングラック１０２及び／又はシステム１００を計算された平均故障間隔値に基づいて管理するように構成されている。データセンタ管理モジュール２１０は、各ハードウェアコンポーネントについての平均故障間隔値を、例えば複数の警告又はアラームを作成することによってユーザに通知するように構成されてよい。データセンタ管理モジュール２１０は、各論理マシンに関連付けられた平均故障間隔値に基づいて複数のメンテナンスセッションのための未来時を決定するように構成されてよい。データセンタ管理モジュール２１０は、複数のハードウェアコンポーネントを、関連する複数の平均故障間隔値に基づいて複数の論理マシン内に構成するように構成されてよい。例えば、データセンタ管理モジュール２１０は、同様の平均故障間隔値を有する複数のハードウェアコンポーネントを含む複数の論理マシンを作成するように構成されてよい。データセンタ管理モジュール２１０のそれらの機能は、１又は複数のサブモジュールによって、例えば通知モジュール２１２、計画的メンテナンスモジュール２１４、又は組立てモジュール２１６によって実行されてよい。

ここで図３を参照すると、ラックコントローラ１２０は、使用中、データセンタ管理のための方法３００を実行してよい。方法３００は、ブロック３０２で開始し、そこでラックコントローラ１２０はコンピューティングラック１０２の１又は複数のハードウェアコンポーネントのための複数の測定基準を受信する。複数の測定基準は、コンポーネント寿命予測を可能にする任意のタイプのデータとして具現化されてよい。複数の測定基準は、複数のシステム測定基準（例えば、複数の製造仕様、及び温度もしくは電力等の要素において直接測定可能な複数の値）又は健全性及び性能測定基準（例えば、帯域幅、レイテンシ、もしくはスループット等の要素の機能に関連する複数の測定基準）を含んでよい。複数の測定基準は、複数のサブコンポーネントログファイルへとコンパイルされてよく、次に処理及びストレージ用にラックコントローラ１２０に送信されてよい。

例示的には、プールされたコンピュートエンクロージャ１２４について、複数のシステム測定基準は、完全なＣＰＵ仕様、性能カウンタ監視データ（例えば、プロセッサ１２６によってリタイアされた複数の命令におけるデータ、プロセッサ１２６周波数、オンボードメモリコントローラ帯域幅、キャッシュミス統計値等）、温度データ、電力サイクルカウンタ、合計使用時間の複数のカウンタ又は複数の他の測定基準として具現化されてよい。プールされたコンピュートエンクロージャ１２４のための複数の健全性測定基準は、複数のカーネルパニックカウンタ（ｋｅｒｎｅｌ ｐａｎｉｃ ｃｏｕｎｔｅｒｓ）、複数のプロセッサ除外カウンタ、又は複数の他の測定基準として具現化されてよい。プールされたコンピュートエンクロージャ１２４のための複数の性能測定基準は、複数の一秒当たり命令カウンタ（ｉｎｓｔｒｕｃｔｉｏｎｓ−ｐｅｒ−ｓｅｃｏｎｄ ｃｏｕｎｔｅｒｓ）（例えば、ＭＩＰＳ）又は複数の他の測定基準として具現化されてよい。

例示的には、プールされたメモリエンクロージャ１３０について、複数のシステム測定基準は、複数の完全な仕様、温度データ、複数の電力サイクルカウンタ、合計使用時間の複数のカウンタ、複数のメモリアクセスカウンタ、又は複数の他の測定基準として具現化されてよい。プールされたメモリエンクロージャ１３０についての複数の健全性測定基準は、複数のパリティエラーカウンタ又は複数の他の測定基準として具現化されてよい。プールされたメモリエンクロージャ１３０についての複数の性能測定基準は、観測されたメモリ帯域幅又は複数の他の測定基準として具現化されてよい。

例示的には、プールされたストレージエンクロージャ１３６について、複数のシステム測定基準は、複数の完全な仕様（例えば、ソリッドステートドライブ、ハードディスクドライブ、キャッシュサイズ等）、複数の読み取り／書き込みカウンタ、複数の秒当たりのＩ／Ｏオペレーション（ＩＯＰＳ）カウンタ、合計使用時間の複数のカウンタ、温度データ、又は複数の他の測定基準を含むストレージタイプとして具現化されてよい。プールされたストレージエンクロージャ１３６についての複数の健全性測定基準は、複数のブロック障害カウンタ、複数のページフォルトカウンタ、シークタイムデータ、レイテンシデータ、又は複数の他の測定基準として具現化されてよい。プールされたストレージエンクロージャ１３６についての複数の性能測定基準は、ランダム読み取りスループットデータ又は複数の他の測定基準として具現化されてよい。

例示的には、プールされたネットワークエンクロージャ１４２について、複数のシステム測定基準は、複数の完全な仕様（例えば、１００Ｍｂｐｓ、１０００Ｍｂｐｓ等）、温度データ、複数の電力サイクルカウンタ、合計使用時間の複数のカウンタ、又は複数の他の測定基準を含むネットワーク技術タイプとして具現化されてよい。プールされたネットワークエンクロージャ１４２について、複数の健全性測定基準は、複数のデータ受信及び送信カウンタ、複数の送受信エラーカウンタ、及び複数の他の測定基準として具現化されてよい。プールされたネットワークエンクロージャ１４２について、複数の性能測定基準は、帯域幅データ又は複数の他の測定基準として具現化されてよい。

いくつかの実施形態において、ブロック３０４では、ラックコントローラ１２０が１又は複数の専用ハードウェア監視コンポーネントから複数の測定基準を受信してよい。例えば、ラックコントローラ１２０は、プールされたコンピュートエンクロージャ１２４の測定基準コンポーネント１２８、プールされたメモリエンクロージャ１３０の測定基準コンポーネント１３４、プールされたストレージエンクロージャ１３６の測定基準コンポーネント１４０、又はプールされたネットワークエンクロージャ１４２の測定基準コンポーネント１４６から複数の測定基準を受信してよい。ラックコントローラ１２０は、また、１又は複数のファームウェアモジュール、埋め込み型ファームウェアデバイス、複数のマネージャビリティエンジン（ｍａｎａｇｅａｂｉｌｉｔｙ ｅｎｇｉｎｅ）、又はコンピューティングラック１０２の他の複数の帯域外管理要素からも複数の測定基準を受信してよい。いくつかの実施形態において、ブロック３０６では、ラックコントローラ１２０が１又は複数のソフトウェアモニタから複数の測定基準を受信してよい。複数のソフトウェアモニタから複数の測定基準を収集することにより、コンピューティングラック１０２によって実行される他のソフトウェアを変更するか、又はそうでなければそれに合わせる必要があるかもしれない。

ブロック３０８で、ラックコントローラ１２０は、関連する残りのハードウェア寿命を推定するために用いられ得るコンピューティングラック１０２の各要素について回帰モデルを生成する。回帰モデルは、数式ｙ＝Ｘｂを用いて生成されてよい。ここでｙは応答ベクトル（例えば、健全性又は性能測定基準のいずれか）であり、Ｘは複数の観測（例えば、複数のシステム測定基準）のマトリックスであり、ｂは適合パラメータの推定値を表すベクトルである。

いくつかの実施形態において、ブロック３１０で、ラックコントローラ１２０は線形回帰モデリングを実行する。ラックコントローラ１２０は、ロバスト多線形回帰アプローチを用いてよい。ラックコントローラ１２０は、複二乗重み関数を用いる（ＱＲ分解を用いて実現される）マトリックス因数分解で最小二乗を反復して重み付け直してよい。従って、線形回帰モデリングは、複数の大規模なデータセンタにより必要とされるように大規模で効率的に計算されてよい。

いくつかの実施形態において、ブロック３１２で、ラックコントローラ１２０が非線形回帰モデリングを実行する。ラックコントローラ１２０は、一般化線形モデル（ＧＬＭ）を用いる。ラックコントローラ１２０は、ロジスティック回帰を生成するためにプロビットリンク及び２項分布を用いる。非線形回帰モデリングは、線形の場合に複数の二乗平均平方根エラーが考慮されるべきであるときに好ましい。

ブロック３１４で、ラックコントローラ１２０は、回帰モデルに基づいて各ハードウェアコンポーネントについての平均故障時間（ＭＴＴＦ）値を決定する。回帰モデルは、複数のハードウェアコンポーネントの健全性又は性能に対する将来的な複数の変更を（例えば、健全性測定基準又は性能測定基準の将来値を予測することによって）予測するために用いられてよい。複数の予測測定基準は、複数の製造仕様又は複数のサービスレベルアグリーメント（ＳＬＡ）要件（例えば、複数のサービス品質要件、又は複数のサービスレベル目標、又は複数の他の要件）等、複数の予め定められた閾値に比較されてよい。予測測定基準及び複数の予め定められた閾値が交わるときの時点は、予測されるコンポーネント故障を表し、この時点までの間隔は平均故障時間（ＭＴＴＦ）である。ラックコントローラ１２０は、各要素についてのＭＴＴＦ値を、１又は複数のデータテーブル、データベース、又は他のデータソース内に格納してよい。

ブロック３１６で、ラックコントローラ１２０は、データセンタの各論理マシンについてＭＴＴＦを決定する。上記のように、コンピューティングラック１０２の複数の要素は、複数のコンピューティングアプリケーションを実行する、又はそうでなければ複数のサービスを提供するために用いられ得る１又は複数の論理マシンへと構成されてよい。論理マシンの寿命は、その構成要素である要素の最も短い寿命として決定されてよい。例えば、計算、ストレージ、ネットワーク、及びメモリリソースで構成される論理マシンについて、ラックコントローラ１２０は、論理マシンについてのＭＴＴＦを、その論理マシンを構成する計算、ストレージ、ネットワーク、及びメモリコンポーネントの複数のＭＴＴＦの最小値として決定してよい。

ブロック３１８で、ラックコントローラ１２０は、コンピューティングラック１０２及び／又はシステム１００を、計算された複数のＭＴＴＦ値に基づいて管理してよい。いくつかの実施形態において、ブロック３２０で、ラックコントローラ１２０は、管理者又は他のユーザに、ハードウェアコンポーネントの残りの寿命について通知してよい。複数のささいなエラーが過度に頻繁に出現し始めた場合、又は要素の性能が、ＳＬＡが要求するものよりも下回る場合、要素が置き換え用にマーキングされてよい。ラックコントローラ１２０は、例えば、１又は複数のアラーム又は警告を設定し、起こり得るコンポーネント故障について管理者に通知してよい。例えば、ラックコントローラ１２０は、故障を回避するべく、ある一定時間前に置き換えられることになっているコンポーネントを識別するアラームを生成してよく、又はある一定時間内にメンテナンスを必要とする要素を識別する警告を生成してよい。従って、ラックコントローラ１２０は、複数の管理者が置き換えを必要とする複数のサブコンポーネントを識別し、論理マシンにおける利用の影響を理解することを可能にし得る。

いくつかの実施形態において、ブロック３２２で、ラックコントローラ１２０は、論理マシンの残りの寿命に基づいてメンテナンスを計画してよい。複数の機能しなくなる論理マシンは、機能しなくなる要素が置き換えられるときに仮想再アセンブルプロセスを経てよい。再アセンブル中、論理マシンは、機能停止されてよい。従って、配信されたサービス品質又はＳＬＡは深刻に低下し得る。論理マシンのメンテナンスを、それらの予測されるＭＴＴＦ前に複数の要素を置き換えるようにスケジューリングすることが、計画外のダウンタイムを阻止することに役立つかもしれない。いくつかの実施形態において、ブロック３２４で、ラックコントローラ１０２は、各論理マシンによって実行されるサービスの複数の性能指標又は他のコンピューティングアプリケーションに基づいてメンテナンスをさらに計画してよい。ラックコントローラ１２０は、例えば、論理マシンによってサポートされるサービスがその最もビジーでない期間にある場合、論理マシンのためのメンテナンスセッションを計画してよい。

いくつかの実施形態において、ブロック３２６で、ラックコントローラ１２０は、同様の残りの寿命を持つ複数のハードウェアコンポーネントを用いて論理マシンを構成してよい。割り当てプロセス中、ラックコントローラ１２０は、複数の論理マシンを組み立てるべく、計算、ストレージ、ネットワーク、又はメモリコンポーネントの複数のプールに対してクエリを行ってよい。ラックコントローラ１２０は、複数のＭＴＴＦ値のための１又は複数のデータソースにクエリを行ってよく、選択プロセスで各要素について予測される複数の故障日を組み込んでよい。同様の寿命を持つ複数の要素から複数の論理マシンを構成することにより、複数の要素が、それぞれの計画的メンテナンスセッションにおいて置き換えられてよく、それにより、複数の繰り返されるメンテナンスセッションが減らされるかもしれなく、そうでなければサービス品質が改善されるかもしれない。コンピューティングラック１０２及び／又はデータセンタを管理した後、方法３００は、ブロック３０２に引き返し、複数のハードウェアコンポーネントについて複数の測定基準の監視を継続する。

図４をここで参照すると、いくつかの実施形態において、ラックコントローラ１２０は、付加的に又は代替的に、環境４００を動作中に確立する。例示的な環境４００は、オーケストレーションモジュール４０２、ハードウェア故障予測モジュール４０４、スケジューリングモジュール４０６、サービスレベルアグリーメントモジュール４０８、及び性能監視モジュール４１０を含む。環境４００の様々なモジュールは、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせとして具現化されてよい。例えば、環境４００の複数のモジュール、論理、及び複数の他のコンポーネントのそれぞれは、ラックコントローラ１２０のプロセッサもしくは他の複数のハードウェアコンポーネントの一部を形成してよく、又はそうでなければそれによって確立されてよい。そのように、いくつかの実施形態において、環境４００の複数のモジュールの１又は複数は、複数の電気デバイスの回路又は集合（例えば、オーケストレーション回路、ハードウェア故障予測回路等）として具現化されてよい。

オーケストレーションモジュール４０２は、コンピューティングラック１０２によって実行され得るアプリケーションの記述を受信し、アプリケーション記述を性能データサーバ１０６に送信し、それに応答してアプリケーションに関連付けられた予測ワークロードデータを性能データサーバ１０６から受信するように構成されている。以下に記載されるように、予測ワークロードデータは、コンピューティングラック１０２の１又は複数のハードウェアコンポーネント（例えば、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソース）の使用パターンを示し、多くの他のコンピューティングラック１０２から生成されてよく、又はそうでなければそれらから供給されてもよい。

ハードウェア故障予測モジュール４０４は、予想されるワークロードデータに基づいて、コンピューティングラック１０２の１又は複数のハードウェアコンポーネントの故障の確率を決定するように構成されている。ハードウェア故障予測モジュール４０４は、また、複数のハードウェアコンポーネントに関連付けられたローカルに格納された使用履歴データ等、他のデータを考慮してもよい。ハードウェア故障予測モジュール４０４は、その確率の決定を、アプリケーションを実行するのに利用可能な複数のハードウェアコンポーネントに限ってよい。

スケジューリングモジュール４０６は、アプリケーションを実行するのに利用可能なコンピューティングラック１０２の複数のハードウェアコンポーネントを識別し、利用可能なハードウェアコンポーネントの各々の故障の確率に基づいて、コンピューティングアプリケーションを実行するのに利用可能なハードウェアコンポーネントを選択するように構成されている。

サービスレベルアグリーメントモジュール４０８は、コンピューティングアプリケーションに関連付けられたサービスレベルアグリーメント（ＳＬＡ）が、ハードウェアコンポーネントの故障の確率によって満たされるかどうかを決定するように構成されている。サービスレベルアグリーメントモジュール４０８は、ハードウェアコンポーネントが、予め定められた期間内にアプリケーションを実行する間に故障する確率が、アプリケーション（例えば、アップタイム、信頼性、又は他のサービス配信目標（ＳＤＯ）及びサービスレベル目標（ＳＬＯ）ゴール）に関連付けられた１又は複数のＳＬＡゴールを満たすかどうかを決定してよい。

性能監視モジュール４１０は、例えば、ハードウェア測定基準コンポーネント１２８、１３４、１４０、１４６から、コンピューティングラック１０２の複数のハードウェアコンポーネントと関連付けられた複数のハードウェア性能測定基準を収集するように構成されている。性能監視モジュール４１０は、例えば、複数の性能測定基準に基づいて１又は複数の正規化された波形を生成することによって、複数のハードウェア性能測定基準に基づいて、（性能データサーバ１０６から受信された予測ワークロードデータと同様に）ワークロードデータを決定するように構成されている。性能監視モジュール４１０は、コンピューティングラック１０２によって実行される１又は複数の現在のアプリケーションを識別し、それらの１又は複数のアプリケーションのアプリケーション記述をワークロードデータと関連付けるように構成されている。性能監視モジュール４１０は、ワークロードデータ及び１又は複数の現在のアプリケーションの１又は複数のアプリケーション記述を、性能データサーバ１０６に送信するように構成されている。

図４をさらに参照すると、例示的な実施形態において、性能データサーバ１０６が環境４２０を動作中に確立する。例示的な環境４２０は、アプリケーション性能データベースモジュール４２２及び通信モジュール４２４を含む。環境４２０の様々なモジュールは、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせとして具現化されてよい。例えば、環境４２０の複数のモジュール、論理、及び複数の他のコンポーネントのそれぞれは、性能データサーバ１０６のプロセッサ又は他の複数のハードウェアコンポーネントの一部を形成してよく、又はそうでなければそれにより確立されてよい。そのように、いくつかの実施形態において、環境４２０の１又は複数のモジュールは、複数の電気デバイスの回路又は集合（例えば、アプリケーション性能データベース回路又は通信回路）として具現化されてよい。

アプリケーション性能データベースモジュール４２２は、例えばアプリケーション性能データベース１６０から、アプリケーション記述に関連付けられたワークロードデータを取り出すように構成されている。上記のように、ワークロードデータは、１又は複数のコンピューティングラック１０２から受信された履歴ワークロードデータであってよい。アプリケーション性能データベースモジュール４２２は、アプリケーション記述に関連付けられた履歴ワークロードデータが存在するかどうかを決定し、結果が否定的な場合、アプリケーション記述について推定ワークロードデータを生成するようにさらに構成されている。アプリケーション性能データベースモジュール４２２は、後に、推定ワークロードデータをコンピューティングラック１０２から受信された履歴ワークロードデータに置き換えてよい。

通信モジュール４２４は、１又は複数のコンピューティングアプリケーションの履歴ワークロードデータ及び複数の関連する記述を複数のコンピューティングラック１０２から受信するように構成されている。通信モジュール４２４は、コンピューティングラック１０２からアプリケーション記述を含む複数のクエリを受信し、複数のクエリに応答して、アプリケーション記述に関連付けられたワークロードデータを、複数のコンピューティングラック１０２に送信するようにさらに構成されている。従って、ワークロードデータが、性能データサーバ１０６から多くのコンピューティングラック１０２に広められてよい。

図４をさらに参照すると、例示的な実施形態において、管理インタフェース１０４が、環境４４０を動作中に確立する。例示的な環境４４０は、最適化エンジンモジュール４４２、システム状態モジュール４４４、インタラクティブ可視化モジュール４４６、及びインタラクション変換モジュール４４８を含む。環境４４０の様々なモジュールは、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組み合わせとして具現化されてよい。例えば、環境４４０の複数のモジュール、論理、及び複数の他のコンポーネントのそれぞれは、管理インタフェース１０４のプロセッサ１４０又は複数の他のハードウェアコンポーネントの一部を形成してよく、又はそうでなければそれらによって確立されてよい。そのように、いくつかの実施形態において、環境４４０の複数のモジュールの１又は複数は、複数の電気デバイスの回路又は集合（例えば、オーケストレーション回路、ハードウェア故障予測回路等）として具現化されてよい。いくつかの実施形態において、環境４４０の一部又は全ては、複数のコンピューティングラック１０２のラックコントローラ１２０又は複数の他のコンポーネント等、システム１００の他の複数のエンティティによって確立されてよい。

最適化エンジンモジュール４４２は、１又は複数の最適化制約に基づいて、システム１００のデータセンタスケジュールを最適化するように構成されている。最適化制約は、下記のように、複数の予め定められたゴール、複数の制約、又は（例えば、システム１００に関連付けられた１又は複数のサービスレベルアグリーメントからの）複数の他のルールに基づいてよく、複数のユーザ規定のゴール、複数の制約、又は複数の他のルールに基づいてよい。最適化エンジンモジュール４４２は、最適化されたデータセンタスケジュールに基づいて、データセンタのシステム状態を、例えば、最適化されたデータセンタスケジュールをシステム１００の１又は複数のラックコントローラ１２０に通信することによって調整するように構成されてよい。

システム状態モジュール４４４は、システム１００のセンサーネットワークからセンサーデータを受信するように構成されている。センサーネットワークは、システム１００の状態と、使用及び性能データ、電力消費データ、温度データ、及び複数の他の状態データを含む複数のその要素とを測定する数個のセンサを含む。センサーネットワークは、例えば、複数のコンピューティングラック１０２の測定基準コンポーネント１２８、１３４、１４０、１４６を含んでよい。

インタラクティブ可視化モジュール４４６は、システム１００の状態を表すインタラクティブな可視化を生成し、インタラクティブな可視化に応答して人間の入力を受信するように構成されている。インタラクティブな可視化は、システム状態モジュール４４４によって決定されたシステム状態、並びに最適化エンジンモジュール４４２によって生成されたデータセンタスケジュールの任意の以前の最適化を組み込んでよい。

インタラクション変換モジュール４４８は、インタラクティブな可視化に応答して、受信された人間の入力を、システム１００のワークロードスケジューリングを最適化するための１又は複数の機械可読ゴール、複数の制約、又は複数の他のルールに変換するように構成されている。上記のように、それらのユーザ規定のルールは、データセンタスケジューリングをさらに最適化する場合に最適化エンジンモジュール４４２によって解釈されてよい。

図５をここで参照すると、ラックコントローラ１２０は、使用中に、最適化、スケジューリング、及び複数のデータセンタワークロードの配置のための方法５００を実行してよい。方法５００は、ラックコントローラ１２０が、コンピューティングラック１０２によって実行（例えば、動作（ｒｕｎ）、初期化、処理等）されることになっている新しいアプリケーションの記述を受信するブロック５０２において、開始する。アプリケーション記述は、コンピューティングラック１０２のユーザ（例えば、管理者、開発者、顧客、購読者等）から（例えば、任意の好適な入力デバイスもしくはプロセスを介して）受信されてよい。例えば、いくつかの実施形態において、ラックコントローラ１２０は、顧客がコンピューティングラック１０２により動作した（例えば、実行した、初期化した、処理した等）ことを望んでいるワークロードについて、アプリケーション（例えば、特定のウェブサーバ、データベース、金融取引サーバ等）に対応するアプリケーション記述を受信してよい。アプリケーション記述は、その特定のアプリケーションの識別、及び／又は他の複数の固有の特性もしくは特徴を記述してよい。いくつかの実施形態において、アプリケーション記述データは、アプリケーションの記述、及びＯＡＳＩＳのクラウドアプリケーションのためのトポロジ及びオーケストレーション仕様（ＴＯＳＣＡ）に従ってフォーマットされたその構成要素である複数のサービスとして具現化されてよい。アプリケーション記述は、例えば、アプリケーションのトポロジ又は他の構造、並びにアプリケーションを形成し終了し、及び／又はそうでなければ管理するために用いられる１又は複数のオーケストレーション方法を記述する１又は複数のサービステンプレートとして具現化されてよい。当然のことながら、任意の他のフォーマットがアプリケーション及びその構成要素である複数のサービスを説明するために用いられてよいことは理解されるべきである。

ブロック５０４で、ラックコントローラ１２０は、新しいアプリケーションに関連付けられた１又は複数のサービスレベルアグリーメント（ＳＬＡ）を受信してよい。ＳＬＡは、コンピューティングラック１０２によって顧客に提供されることになっているサービスのレベルを規定する。ＳＬＡは、１又は複数のゴール（サービス配信目標（ＳＤＯ）及び複数のサービスレベル目標（ＳＬＯ）ゴール等）、効率ターゲット、コンプライアンス目標、複数の施設を含むエネルギーターゲット、及び複数の他の環境又はコンテクスト上の制約を含んでよい。アプリケーション記述と同様に、ＳＬＡは、コンピューティングラック１０２のユーザ（例えば、管理者、開発者、顧客、購読者等）から受信されてよい。概して、ＳＬＡは、複数のコンピューティングラック１０２の複数の要素についての特定の性能又は複数の品質制約（例えば、プールされたストレージ１３８の複数の個々のディスクのための複数の信頼性ゴール）よりもむしろ、アプリケーションの配信について複数のゴール及び制約（例えば、ウェブサーバについての複数のアップタイムゴール）を規定する。

ブロック５０６で、ラックコントローラ１２０は、アプリケーション記述を性能データサーバ１０６に送信する。以下に図６と関連してさらに記載されるように、性能データサーバ１０６は、複数の他のコンピューティングラック１０２によって提供されたかもしれないアプリケーション記述に関連付けられた性能履歴データを検索する。

ブロック５０８で、ラックコントローラ１２０は、アプリケーション記述に関連付けられた予測ワークロードデータを性能データサーバ１０６から受信する。予測ワークロードデータは、アプリケーション記述データ（例えば、ＴＯＳＣＡアプリケーション記述）が送信されたアプリケーションに関連付けられた、予測されたハードウェア使用パターンに対応する。いくつかの実施形態において、予測ワークロードデータは、アプリケーションに対応する平均で観測された機械ワークロード等、平均ロード履歴データとして具現化されてよい。すなわち、平均ロード履歴データは、アプリケーションの実行（例えば、動作、初期化、処理等）が、コンピューティングラック１０２（又は複数の他のコンピューティングラック１０２）の複数の計算もしくは他のリソースに対して有した以前の影響を示すデータを含んでよい。例えば、予測ワークロードデータは、履歴プロセッサ、メモリ、ストレージ、又はアプリケーションの実行によって生じるネットワークロードを示してよい。いくつかの実施形態において、予測ワークロードデータは、アプリケーションについての履歴ワークロードデータの平均として具現化されてよい。いくつかの実施形態において、予測ワークロードデータは、フーリエ変換を介して振幅、周波数、及び位相として一時的ロードを説明する複数の波形の集合として具現化されてよい。

ブロック５１０で、コンピューティングラック１０２の１又は複数のハードウェアコンポーネントについての故障の確率を、ラックコントローラ１２０は、予測ワークロードデータに基づいて、アプリケーションの実行中に決定する。ラックコントローラ１２０は、例えば、コンピューティングラック１０２の１又は複数のコンポーネントに対応する、受信された予測ワークロードデータ及びローカル要素固有の測定基準データ（例えば、コンピューティングラック１０２の１又は複数のコンポーネントに関連付けられた使用履歴データ）を分析してよい。ラックコントローラ１２０は、受信された予測ワークロードデータを分析することのみによって、又は受信された予測ワークロードデータを、要素が故障し得るかどうか及び要素がいつ故障し得るかを決定するのに好適な任意の他のデータもしくは測定基準と組み合わせて分析することによって、故障の確率を決定してよい。例えば、ラックコントローラ１２０は、試験を通して又は別の方法で決定され得る、製造で提供され得る複数のコンポーネント故障率の統計的データを更に分析してよい。例示として、予測ワークロードデータは、特定のアプリケーションが、ストレージが集中的であることを示してよい。その例において、ラックコントローラ１２０は、プールされたストレージエンクロージャ１３６の各ディスク、ストレージモジュール、又は他のコンポーネントについての故障の確率を、その要素の使用履歴データ、予測されたワークロード及びその要素の故障率における統計的データに基づいて決定してよい。いくつかの実施形態において、要素の故障の確率は、要素が予め定められた（例えば、基準等）期間内に故障する可能性の割合として表されてよい。例えば、故障の確率は、要素が次の４週間以内のあるときに故障する確率として表されてもよい。故障の確率及び／又は故障の期間は、任意の他の態様で表されてもよいことは理解されるべきである。いくつかの実施形態において、ブロック５１２では、ラックコントローラ１２０が、確率の計算をコンピューティングラック１０２の複数の利用可能なコンポーネントに限定してよい。例えば、ラックコントローラ１０２は、プールされたコンピュートエンクロージャ１２４のいずれのタスクにも割り当てられなかった複数のプロセッサ１２６についての故障の確率を決定してよい。

ブロック５１４で、ラックコントローラ１２０は、故障の確率に基づいて、アプリケーションを実行するために１又は複数のハードウェアコンポーネントを選択する。例えば、ラックコントローラ１２０は、アプリケーションを実行（例えば、動作、初期化、処理、サービス等）する複数の利用可能なコンポーネントのリストを生成してよく、次にそれらの要素を、予め定められた期間内に故障に遭遇する確率が最も低いものから、その同じ期間内に故障に遭遇する確率が最も高い要素までランク付けしてよい。ラックコントローラ１２０は、アプリケーションの実行のために故障に遭遇する確率が最も低いハードウェアコンポーネントを選択してよい。例えば、ラックコントローラ１２０は、複数の利用可能なプロセッサ１２６を識別してよく、それらの利用可能なプロセッサ１２６を故障の確率でランク付けしてよく、最も低い故障の確率を有する利用可能なプロセッサ１２６を選択してよい。加えて、又は代替的に、ラックコントローラ１２０は、複数の利用可能なリソース、近接、セキュリティ、又は他の複数の基準等、１又は複数の追加の基準に基づいて、複数のハードウェアコンポーネントを選択してよい。１又は複数のコンポーネントを選択した後、コンピューティングラック１０２のオーケストレータは、選択された複数の要素を用いてアプリケーションの実行を形成してよく、又はそうでなければアプリケーションの実行を初期化してよい。

ブロック５１６で、ラックコントローラ１２０は、アプリケーションのために要求されたＳＬＡが故障の確率で満たされることが可能かどうかを決定する。ラックコントローラ１２０は、コンピューティングラック１０２の１又は複数の利用可能なコンポーネントが、ＳＬＡの１又は複数のゴール、制約、又は複数の他の要件を満たす閾値測定基準を満たすことが可能であるか、又はそうでなければ閾値測定基準内にあるかを決定してよい。この場合、ラックコントローラ１２０は、アプリケーション及び／又はワークロードを実行するように選択されたコンピューティングラック１０２の１又は複数のコンポーネントがＳＬＡを満たすことが可能であることを、アプリケーション及び／又はワークロードの割り当て前に認証してよい。ＳＬＡを認証した後、方法５００が、複数の新しいアプリケーションの記述の処理を続けるべく、ブロック５０２に引き返す。

図６をここで参照すると、使用中に、性能データサーバ１０６は、予測ワークロードデータ取得のための方法６００を実行してよい。方法６００は、性能データサーバ１０６がコンピューティングラック１０２によって実行されることになっているアプリケーションの記述を受信する、ブロック６０２で開始する。上記のように、アプリケーション記述データは、アプリケーションの記述及びＯＡＳＩＳのクラウドアプリケーションのためのトポロジ及びオーケストレーション仕様（ＴＯＳＣＡ）に従ってフォーマットされたその構成要素である複数のサービスとして具現化されてよい。アプリケーション記述は、例えば、アプリケーションのトポロジ又は他の構造、並びにアプリケーションを形成し終了し、及び／又はそうでなければ管理するために用いられる１又は複数のオーケストレーション方法を記述する１又は複数のサービステンプレートとして具現化されてよい。

ブロック６０４で、性能データサーバ１０６は、アプリケーション記述に関連付けられた、格納された履歴ワークロードデータを検索する。例えば、性能データサーバ１０６は、アプリケーション名及び／又はアプリケーションに関連付けられた複数の他の識別子によってインデキシングされ得る、アプリケーション性能データベース１６０におけるワークロードデータを検索してよい。ブロック６０６で、性能データサーバ１０６は、履歴ワークロードデータがアプリケーション記述について存在するかどうかを決定する。存在する場合、方法６００は、以下に記載されるブロック６１２へと分岐して進む。ワークロードデータが存在しない場合、方法６００はブロック６０８に進む。

ブロック６０８で、性能データサーバ１０６は、アプリケーション記述について推定ワークロードデータを生成する。例えば、性能データサーバ１０６は、未知のアプリケーションについての平均ワークロードデータの推定を生成してよく、又は既定のワークロードデータを提供してよい。性能データサーバ１０６は、例えばアプリケーション性能データベース１６０において、将来用いるための推定ワークロードデータを格納してよい。いくつかの実施形態において、ブロック６１０で、性能データサーバ１０６は、複数の同様のアプリケーションの履歴ワークロードデータに基づいて、未知のアプリケーションについての推定ワークロードデータを生成してよい。例えば、アプリケーション記述が未知のウェブサーバに関連付けられる場合、性能データサーバ１０６は、複数の既知のウェブサーバについてのワークロードデータ（例えば、Ａｐａｃｈｅ２及びｎｇｉｎｘのためのワークロードデータ）を組み合わせるか又は平均することにより、推定ワークロードデータを生成してよい。

ブロック６１２で、性能データサーバ１０６は、コンピューティングラック１０２にワークロードデータを送信する。性能データサーバ１０６は、例えば、ブロック６０４に関連して上述されたように、決定された履歴ワークロードデータ又はブロック６０８に関連して上述したように決定された推定ワークロードデータを送信してよい。図５に関連して上述したように、コンピューティングラック１０２は、アプリケーションに関連付けられたハードウェアコンポーネント故障の確率を予測するべく、ワークロードデータを分析してよい。ワークロードデータを送信した後、方法６００は、ブロック６０２に引き返し、複数のアプリケーション記述を複数のコンピューティングラック１０２から受信し続ける。

図７をここで参照すると、使用中、ラックコントローラ１２０は、複数のデータセンタワークロードの性能監視のための方法７００を実行してよい。方法７００は、ラックコントローラ１２０が、コンピューティングラック１０２の１又は複数のハードウェアコンポーネントについての複数の性能測定基準を受信するブロック７０２で、開始する。複数の性能測定基準は、タイプ（例えば、ストレージタイプ、プロセッサタイプ等）、性能測定基準（例えば、シークタイム、パリティ及びエラー頻度等）、動作特性（例えば、温度等）、利用測定基準（例えば、合計使用時間、合計アクセス数等）、及び／又はコンピューティングラック１０２の複数のハードウェアコンポーネントのそれぞれのために生成及び／又はキャプチャされ得る任意の他のタイプの測定基準を記述する任意のタイプのデータとして具現化されてよい。例えば、複数の性能測定基準は、複数の特定のハードウェアコンポーネントのロードの一式の低レベルサンプル又は複数の使用態様を表すバイナリデータとして具現化されてよい。

例示的には、プールされたコンピュートエンクロージャ１２４について、性能測定基準は性能カウンタ監視データ（例えば、複数のプロセッサ１２６によってリタイアされた複数の命令におけるデータ、プロセッサ１２６周波数、オンボードメモリコントローラ帯域幅、キャッシュミス統計値等）、複数のカーネルパニック又はプロセッサ除外カウンタ、温度データ、複数の電力サイクルカウンタ、合計使用時間の複数のカウンタ、又は複数の他の測定基準として具現化されてよい。プールされたメモリエンクロージャ１３０について、複数の性能測定基準は、観測されたメモリ帯域幅、複数のパリティ及びエラーカウンタ、メモリ周波数、複数のメモリアクセスカウンタ、温度データ、複数の電力サイクルカウンタ、合計使用時間の複数のカウンタ、又は複数の他の測定基準として具現化されてよい。プールされたストレージエンクロージャ１３６について、複数の性能測定基準は、ストレージタイプ（例えば、ソリッドステートドライブ、ハードディスクドライブ、キャッシュサイズ等）、１秒当たりの読み取り、グローバル読み取りカウンタ、１秒当たりの書き込み、グローバル書き込みカウンタ、１秒当たりのＩ／Ｏオペレーションの合計（ＩＯＰＳ）、ＩＯＰＳ、ブロック障害カウンタ、ページフォルトカウンタ、シークタイムデータ、レイテンシデータ、温度データ、複数の電力サイクルカウンタ、合計使用時間の複数のカウンタ、又は複数の他の測定基準として具現化されてよい。プールされたネットワークエンクロージャ１４２について、性能測定基準は、秒当たりの接続、送信されたデータ、受信されたデータ、温度データ、電力サイクルカウンタ、合計使用時間の複数のカウンタ、又は複数の他の測定基準として具現化されてよい。

いくつかの実施形態において、ブロック７０４で、ラックコントローラ１２０は、１又は複数の専用ハードウェア監視コンポーネントから複数の性能測定基準を受信してよい。例えば、ラックコントローラ１２０は、プールされたコンピュートエンクロージャ１２４の測定基準コンポーネント１２８、プールされたメモリエンクロージャ１３０の測定基準コンポーネント１３４、プールされたストレージエンクロージャ１３６の測定基準コンポーネント１４０、又はプールされたネットワークエンクロージャ１４６の測定基準コンポーネント１４６から、複数の性能測定基準を受信してよい。いくつかの実施形態において、ブロック７０６で、ラックコントローラ１２０は、１又は複数のソフトウェアモニタから複数の性能測定基準を受信してよい。複数の性能測定基準を複数のソフトウェアモニタから収集することにより、コンピューティングラック１０２によって実行される他のソフトウェアを変更すること又はそうでなければそれに合わせることが要求されてよい。

ブロック７０８において、ラックコントローラ１２０は、複数の性能測定基準を格納し処理して、履歴ワークロードデータを生成する。例えば、ラックコントローラ１２０は、コンピューティングラック１０２の複数のコンポーネントのそれぞれから受信された性能測定基準データをローカルハードウェア／性能データベース内に格納してよい。ワークロードデータは、１時間の平均使用量についての性能測定基準データを表してよい。例えば、ワークロードデータは、一時的ロードを振幅、周波数、及び位相として説明する複数の正規化された波形の集合として具現化されてよい。ラックコントローラ１２０は、例えばフーリエ変換を性能測定基準データに適用することでワークロードデータを生成してよい。

ブロック７１０で、ラックコントローラ１２０は、コンピューティングラック１０２によって現在実行（例えば、動作、初期化、処理、サービス等）されている１又は複数のアプリケーションの記述に、ワークロードデータを関連付けてもよい。従って、ラックコントローラ１２０は、それぞれのアプリケーションを、そのアプリケーションを実行するのに必要とされる複数のハードウェアリソース（例えば、計算、メモリ、ストレージ、又はネットワークリソース）に関連付けてよい。アプリケーション記述は、その特定のアプリケーションの識別及び／又は他の複数の固有の特性もしくは特徴を記述してよい。いくつかの実施形態において、アプリケーション記述データは、アプリケーションの記述、及びＯＡＳＩＳのクラウドアプリケーションのためのトポロジ及びオーケストレーション仕様（ＴＯＳＣＡ）に従ってフォーマットされたその構成要素である複数のサービスとして具現化されてよい。アプリケーション記述は、例えば、アプリケーションのトポロジ又は他の構造、並びにアプリケーションを形成し終了し、及び／又はそうでなければ管理するために用いられる１又は複数のオーケストレーション方法を記述する１又は複数のサービステンプレートとして具現化されてよい。当然のことながら、任意の他のフォーマットが、アプリケーション及びその構成要素である複数のサービスを記述するために用いられてもよいことは理解されるべきである。

ブロック７１２で、ラックコントローラ１２０は、ワークロードデータ及び１又は複数の関連するアプリケーション記述を性能データサーバ１０６に送信する。いくつかの実施形態において、ラックコントローラ１２０は、組み合わされた及び／又は一致するデータを、予め定められた（例えば、基準）時間間隔に応じて性能データサーバ１０６に送信してよい。例えば、いくつかの実施形態において、ラックコントローラ１２０は、組み合わされた及び／又は一致するデータを毎時に性能データサーバ１０６に送信してよい。図８に関連して以下に記載されるように、性能データサーバ１０６は、ワークロードデータを格納し、処理してよい。ワークロードデータ及び関連するアプリケーション記述を送信した後、方法７００は、ブロック７０２に引き返し、複数の性能測定基準を監視し続ける。

図８をここで参照すると、使用中、性能データサーバ１０６は、性能データ管理のための方法８００を実行してよい。方法８００は、性能データサーバ１０６がワークロードデータ及び１又は複数の関連するアプリケーション記述をコンピューティングラック１０２から受信するブロック８０２において、開始する。図７に関連して上述したように、ワークロードデータは、関連するアプリケーション又は複数のアプリケーションの実行中、コンピューティングラック１０２の１又は複数のハードウェアコンポーネントの測定されたロードを表す。ワークロードデータは、例えば、コンピューティングラック１０２の様々なハードウェアコンポーネントの１時間の平均使用量を示す複数の正規化された波形の集合として具現化されてよい。上記のように、アプリケーション記述データは、アプリケーションの記述及びＯＡＳＩＳのクラウドアプリケーションのためのトポロジ及びオーケストレーション仕様（ＴＯＳＣＡ）に従ってフォーマットされたその構成要素である複数のサービスとして具現化されてよい。アプリケーション記述は、例えば、アプリケーションのトポロジ又は他の構造、並びにアプリケーションを形成し終了し、及び／又はそうでなければ管理するために用いられる１又は複数のオーケストレーション方法を記述する１又は複数のサービステンプレートとして具現化されてよい。

ブロック８０４で、性能データサーバ１０６は、アプリケーション記述に関連付けられたワークロードデータを処理し格納する。例えば、性能データサーバ１０６は、ワークロードデータ及び関連する複数のアプリケーション記述をアプリケーション性能データベース１６０内に格納してよい。格納された後、ワークロードデータは、図５及び図６と関連して上述したように、複数の関連するアプリケーションのハードウェアコンポーネント使用を予測するべく、コンピューティングラック１０２に提供されてよい。ワークロードデータは多くの異なるコンピューティングラック１０２から生じ得るので、アプリケーション性能データベース１６０は、「クラウドソースとされた（ｃｒｏｗｄ ｓｏｕｒｃｅｄ）」データベースとして記載されてよい。いくつかの実施形態において、ブロック８０６では、性能データサーバ１０６が、アプリケーション性能データベース１６０内の関連するアプリケーション記述についての履歴ワークロードデータを更新してよい。例えば、性能データサーバ１０６は、複数の平均値を更新してよく、又は一時的ロードを振幅、周波数及び位相として記述する複数の正規化された波形を更新してよい。いくつかの実施形態において、ブロック８０８で、性能データサーバ１０６は、アプリケーション性能データベース１６０内の推定データをコンピューティングラック１０２から受信された履歴ワークロードデータと置き換えてよい。図６のブロック６０８に関連して上述したように、ある特定の複数の未知のアプリケーション又は履歴ワークロードデータがない他の複数のアプリケーションについて、性能データサーバ１０６が推定ワークロードデータを生成してよい。推定ワークロードデータを複数のコンピューティングラック１０２によって提供される履歴ワークロードデータに置き換えることで、性能データサーバ１０６は、測定されたワークロードデータを推定ワークロードデータよりも優先させる。ワークロードデータを格納した後、方法８００は、ブロック８０２に引き返し、コンピューティングラック１０２からワークロードデータ及び関連する複数のアプリケーション記述を受信し続ける。

図９をここで参照すると、使用中、管理インタフェース１０４は、ワークロードスケジューリング及び配置を最適化するための方法９００を実行してよい。管理インタフェース１０４によって実行されているとして示されるが、いくつかの実施形態では、方法９００のいくつか又は全ての機能は、複数のコンピューティングラック１０２及び／又は複数のラックコントローラ１２０の１又は複数によって実行されることを含む、システム１００の複数の他の要素によって実行されることは理解されるべきである。方法９００は、管理インタフェース１０４が１又は複数の初期最適化制約をロードし、最適化エンジンモジュール４４２をそれらの制約で構成するブロック９０２で開始する。複数の初期最適化制約は、１又は複数の予め定められた制約及び／又はゴールとして具現化されてよい。いくつかの実施形態において、ブロック９０４で、管理インタフェース１０４は、１又は複数のサービスレベルアグリーメント（ＳＬＡ）に基づいて複数の初期制約を決定してよい。例えば、複数の初期最適化制約は、性能のレベル、アップタイム／信頼性、又は他の複数の定量的測定等、１又は複数のサービスレベル目標（ＳＬＯ）に対応してよく、又はデータ位置、複数のセキュリティ規格、又は他の複数のＳＤＯ等、１又は複数のサービス配信目標（ＳＤＯ）に対応してよい。別の例として、初期最適化制約は、複数の効率ターゲット、複数のコンプライアンス目標、複数の施設を含む複数のエネルギーターゲット、及び複数の他の環境及びコンテクスト上の制約を含んでよい。複数の初期最適化制約は、グラフィカルユーザインタフェース（ＧＵＩ）設定モジュールを用いて提供されてよい。

ブロック９０６で、管理インタフェース１０４は、システム１００についてワークロードの最適化された配置及び／又はスケジューリングを、最適化エンジンモジュール４４２に提供された複数の最適化制約に基づいて決定する。複数の最適化制約は、以下にさらに記載されるように、複数の初期最適化制約であってよく、又は複数のユーザ規定のルールもしくは制約に基づいてよい。従って、最適化エンジンモジュール４４２は、複数の人間の入力で問題空間の複数のフォーマルな予め定められた記述を統合し、複数の最適な結果を有する複数のソリューションジョイント（ｓｏｌｕｔｉｏｎ ｊｏｉｎｔ）認知システムを形成する。最適化エンジンモジュール４４２は、複雑な問題を解決するべくアルゴリズムを用いる自動化プログラムとして具現化されてよい。特に、最適化エンジンモジュール４４２は、システム１００の様々なコンピューティング要素における複数のワークロードについての最適な配置及び／又は計画を含む、システム１００についての最適なシステム状態を決定してよい。最適化エンジンモジュール４４２は、確率的最適化アルゴリズムを含む任意の最適化アルゴリズムを用いてよい。特に、例示的な最適化エンジンモジュール４４２は、複数のデータセンタスケジュール（例えば、複数のワークロードの配置及び／又はスケジューリングのための複数の計画）を最適化するときに、複数の「軟らかい制約」を評価してよい。例えば、完全に互換性があるわけではない２つの異なる設定オプション、例えば、（１）システム１００の特定の複数のコンピューティング要素において利用可能なプラットフォーム機能オプション及び（２）データ転送速度設定オプション、から利益を得てよいワークロードの到着要素を考慮されたい。その例において、ワークロードの実行に対する相対的な利益は、両方のオプションについては正確に知られておらず、利益はある範囲内であり得る。その例において、その利益は、統計に基づいて確立又はモデル化されてよく、その場合、複数のシナリオが、好みの順序のモデルを通知するべく、選択されてよい。当然のことながら、それは、非常に単純化した例であり、拡大した規模では、最適化は、コスト、柔軟性、コンポーネント寿命、性質、サービスレベル保証（ＳＬＡ）、及びリスクの態様を組み込んでよい。

最適化エンジンモジュール４４２は、システム１００の複数のコンピューティング要素の構成を記述する複数のシステムパラメータ並びに計算ワークロードを含むシステム状態に基づいて、最適な複数の解決策を提供することを試みる。最適化エンジンモジュール４４２は、システム１００の性能を評価するために用いられる適合度関数を調整するのに複数の最適化制約を用いてよい。最適化エンジンモジュール４４２は、例えば、「もし〜だったらどうなるか」というシナリオ計画に従事している場合に利用可能であるべく、非常に迅速に複数の結果を生成する必要があってよい。複数の迅速な結果は、メタヒューリスティックなアプローチを必要としてよい。従って、最適化エンジンモジュール４４２は、複数の結果を迅速に提供するべく、一致検索、シミュレーテッドアニーリング、又は他の複数の確率的最適化アルゴリズム等の確率的最適化の形式を用いてよい。従って、管理インタフェース１０４は、システム１００の動作の信頼性のあるモデル（知識ベース）を確立するべく、システム状態の実行時データをキャプチャしてよく、実行時の動作の統計的証拠を収集するべく実行時データを処理してよく、この統計的証拠を前述の一致検索等の複数の最適化技術と組み合わせてよい。

ブロック９０８で、管理インタフェース１０４は、最適化エンジンモジュール４４２の出力に基づいて、システム１００の状態を調整する。例えば、管理インタフェース１０４は、システム１００の複数のコンピューティング要素を、異なる複数のワークロードに対して割り当て又は再割り当てをしてよく、複数のワークロードを複数の異なるコンピューティング要素又は複数のコンピューティングラック１０２に転送してよく、複数のワークロードのスケジューリングを調整してよく、又は最適化エンジンモジュール４４２により決定された最適化されたデータセンタスケジュールによって記載されたような任意の他の構成を実行してよい。管理インタフェース１０４は、コンピューティングラック１０２の複数のラックコントローラ１２０及び／又は複数の他のオーケストレーション要素と通信することで、システム１００の状態を調整してよい。

ブロック９１０で、管理インタフェース１０４は、システム１００の状態を示すセンサーデータを収集する。管理インタフェース１０４は、システム１００のセンサーネットワークを用いてシステム状態のデータを収集してよい。システム状態は、リソース利用データ、容量データ、サーマルデータ、エネルギー消費データ、又は他のデータを含む、システム１００のワークロードに関する任意のデータを含んでよい。センサーネットワークが、複数のコンピューティングラック１０２の測定基準コンポーネント１２８、１３４、１４０、１４６及び／又は他の複数のセンサ、モニタ、又は監視要素を含んでよい。管理インタフェース１０４は、システム１００内のシステム状態データベースにシステム状態データを格納してよい。

ブロック９１２で、管理インタフェース１０４は、システム１００の状態を表すインタラクティブな可視化を生成し表示する。インタラクティブな可視化は、最適化エンジンモジュール４４２により生成された複数の任意の以前の最適化を含むシステム１００の現在の状態を表すため且つユーザが直観的なインタラクションを通してシステム１００に情報を伝えることを可能にするための両方に用いられてよい。最適化アルゴリズムの初期の出力が、ユーザ又は複数のユーザに提示されてよい。ユーザ又は複数のユーザは、次に、単純なインタラクションを通して、例えば、新しい複数の入力を指定するべく、プロンプトベース（ｐｒｏｍｐｔ‐ｂａｓｅｄ）の「ウィザード（ｗｉｚａｒｄ）」インタフェースを用いて、システム１００に情報を分け与えてよい。インタラクティブな可視化は、システム１００の様々なコンピューティング要素における複数のワークロードの現在の配置及び／又はスケジューリングを含む、システム１００のシステム状態を表す任意の可視化として具現化されてよい。インタラクティブな可視化は、データセンタオペレータ及び／又は管理者の管理インタフェース（「ダッシュボード（ｄａｓｈｂｏａｒｄ）」の一部又は全てとして具現化されてよく、ワークロード配置及び／又は複数のスケジューリング履歴の非常に直観的な表現を提供してよい。加えて、インタラクティブな可視化は、ユーザが複数の介入を用いて実験しそれらの意味合いを検討することを可能にするインタラクティブな複数の推奨情報を提供してよく、最適化アルゴリズムが複数の介入に応答して自動的に更新される。いくつかの実施形態において、インタラクティブな可視化は、ユーザが最適化エンジンによって生成された数個の潜在的シナリオの間で選択することを可能にしてよい。複数のユーザは、インタラクティブな可視化を用いてシステム１００と協調して対話し、それらの専門のコンテクストの知識を動的に分け与えてよい。例えば、データセンタ及び複数のネットワークオペレータ、複数の開発オペレーションチーム、複数のミドルウェア積分器、及び複数の施設オペレータは全員、インタラクティブな可視化を通して伝える知識を有してよい。インタラクティブな可視化は、例えばシステム１００の管理インタフェース１０４又は別のコンソールインタフェースのディスプレイ１５０を用いてローカルに、あるいは、例えばウェブページ又は遠隔管理コンソールを用いて遠隔で提示されてよい。

ブロック９１４で、管理インタフェース１０４は、インタラクティブな可視化に基づいてユーザ入力を受信する。例えば、さらに上述したように、管理インタフェース１０４は、インタラクティブな可視化によって生成されたウィザードインタフェースへの１又は複数のユーザ応答を受信してよい。

ブロック９１６で、管理インタフェース１０４は、ユーザ入力を最適化エンジンモジュール４４２のための１又は複数の機械可読のユーザ規定のルールへと変換する。機械可読ルールは、最適化エンジンモジュール４４２のオペレーション又は出力を構成、制約、又はそうでなければ調整する任意のルールとして具現化されてよい。ユーザ入力に基づいて複数の機械可読ルールを生成することにより、ユーザが認識し得る複数のソフト及び／又は統計的制約を、ユーザがユーザの暗黙的な知識に基づいて入力することが可能になるが、それは、センサーネットワークによって測定可能ではないかもしれない。従って、ユーザは、ワークロード配置が実行時に妥当であり得るという一式のルール又はヒューリスティックを確立し維持してよい。これは、システム１００の柔軟性を改善し得る。従って、インタラクションは、ユーザにとって既知のコンテクスト情報を表すユーザの複数のアクションの変換を最適化エンジンモジュール４４２により理解されるフォーマットへと変換することを可能にしてよく、従って、解決策は最適化エンジンモジュール４４２（又は使用中にある特定の最適化アルゴリズム）自体にとらわれない。

ユーザ入力を最適化エンジンモジュール４４２のための複数のユーザ規定のルールに変換した後、方法９００は、ブロック９０６に引き返し、最適化アルゴリズムを再実行する。従って、管理インタフェース１０４は、ダイナミックユーザフィードバックを最適化アルゴリズムの動作に迅速に組み込んでよい。ユーザ入力に応答することに加えて、方法９００は、また、システム１００の状態の複数の変更に対して応答してもよい。システム状態データは、現在のデータセンタスケジュールから外れることに調整するべく、定期的に、断続的に、又は応答に基づいて最適化エンジンモジュール４４２によってポーリングされてよい、又はそうでなければクエリされてよい。システム状態データの連続的に更新するデータベースへの接続により、複数のデータセンタスケジュールの監視及び複数の逸脱が生じた場合の通知がサポートされてよい。データセンタスケジュールから外れる（又は、上記のように、ユーザが新しいゴール及び／又は制約を規定する）状況において、最適化エンジンモジュール４４２は、再実行し、更新されたデータセンタスケジュールを提供してよい。従って、システム１００は、データセンタスケジュールの迅速な陳腐化の課題を克服し得る。

例 本明細書で開示される複数の技術の複数の例示的な例が、以下に提供される。 複数の技術の実施形態は、後述される複数の例の任意の１又は複数、及び任意の組み合わせを含んでよい。

例１は、コンピューティングラックのラックコントローラを含み、ラックコントローラは、コンピューティングラックのハードウェアコンポーネントに関連付けられた測定基準を受信する性能監視モジュールであって、測定基準は、システム測定基準、性能測定基準、又は健全性測定基準を有する、性能監視モジュールと、ハードウェアコンポーネントに関連付けられた測定基準に基づいてハードウェアコンポーネントについての回帰モデルを決定し、ハードウェアコンポーネントについての回帰モデルに基づいて、ハードウェアコンポーネントの平均故障間隔値を決定し、ハードウェアコンポーネントの平均故障間隔値に基づいて、論理マシンの平均故障間隔値を決定する、分析モジュールと、を備え、論理マシンはハードウェアコンポーネントに関連付けられている。

例２は、例１の主題を含み、測定基準を受信することは、ハードウェアコンポーネントの測定基準コンポーネントから測定基準を受信することを有する。

例３は、例１及び２のいずれかの主題を含み、ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例４は、例１−３のいずれかの主題を含み、回帰モデルを決定することは、線形回帰モデルを決定することを有する。

例５は、例１−４のいずれかの主題を含み、回帰モデルを決定することは、非線形回帰モデルを決定することを有する。

例６は、例１−５のいずれかの主題を含み、ハードウェアコンポーネントについての平均故障間隔値を決定することは、回帰モデルに基づいて、ハードウェアコンポーネントに関連付けられた予測測定基準を決定し、予測測定基準を予め定められた閾値測定基準と比較することを有する。

例７は、例１−６のいずれかの主題を含み、ハードウェアコンポーネントについての平均故障間隔値を決定することは、回帰モデルに基づいて、ハードウェアコンポーネントに関連付けられた予測測定基準を決定し、ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定し、予測測定基準をサービスレベル測定基準と比較することを有する。

例８は、例１−７のいずれかの主題を含み、ハードウェアコンポーネントについての平均故障間隔値をユーザに通知するデータセンタ管理モジュールをさらに備える。

例９は、例１−８のいずれかの主題を含み、論理マシンの平均故障間隔値に基づいて、論理マシンに関連付けられるメンテナンスセッションのための未来時を決定するデータセンタ管理モジュールをさらに備える。

例１０は、例１−９のいずれかの主題を含み、性能監視モジュールは、さらに、論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられた性能指標を受信し、未来時を決定することは、さらに、性能指標に基づいて、未来時を決定することを有する。

例１１は、例１−１０のいずれかの主題を含み、コンピューティングラックの複数のハードウェアコンポーネントを識別し、複数のハードウェアコンポーネントを含む論理マシンを構成するデータセンタ管理モジュールをさらに備え、複数のハードウェアコンポーネントは、ハードウェアコンポーネントを有し、ハードウェアコンポーネントのそれぞれに関連付けられる平均故障間隔値は、ハードウェアコンポーネントの平均故障間隔値と同様である。

例１２は、コンピューティングラックのラックコントローラを含み、ラックコントローラは、コンピューティングラックによって実行可能なコンピューティングアプリケーションの記述を受信し、コンピューティングアプリケーションの記述をリモートコンピューティングデバイスに送信し、コンピューティングアプリケーションの記述を送信することに応答して、リモートコンピューティングデバイスからアプリケーションに関連付けられた予測ワークロードデータを受信するオーケストレーションモジュールであって、予測ワークロードデータは、コンピューティングラックのハードウェアコンポーネントの使用パターンを示す、オーケストレーションモジュールと、予側ワークロードデータに基づいて、コンピューティングラックのハードウェアコンポーネントの故障の確率を決定するハードウェア故障予測モジュールと、を備える。

例１３は、例１２の主題を含み、コンピューティングアプリケーションの記述は、サービステンプレートを有する。

例１４は、例１２及び１３のいずれかの主題を含み、記述は、コンピューティングアプリケーションの構造又は初期化方法を示す。

例１５は、例１２−１４のいずれかの主題を含み、予測ワークロードデータは、ハードウェアコンポーネントにおけるロードを示す波形の振幅、周波数、又は位相を含む。

例１６は、例１２−１５のいずれかの主題を含み、ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例１７は、例１２−１６のいずれかの主題を含み、コンピューティングラックの複数のハードウェアコンポーネントから複数の利用可能なハードウェアコンポーネントを識別するスケジューリングモジュールをさらに備えることを含み、複数の利用可能なハードウェアコンポーネントは、コンピューティングアプリケーションを実行するのに利用可能であり、ハードウェア故障予測モジュールは、さらに、予測ワークロードデータに基づいて、複数の利用可能なハードウェアコンポーネントの各々の故障の確率を決定する。

例１８は、例１２−１７のいずれかの主題を含み、スケジューリングモジュールは、さらに、コンピューティングアプリケーションを、複数の利用可能なハードウェアコンポーネントの各々の故障の確率に応じて実行するべく、複数の利用可能なハードウェアコンポーネントから利用可能なハードウェアコンポーネントを選択する。

例１９は、例１２−１８のいずれかの主題を含み、コンピューティングアプリケーションに関連付けられたサービスレベルアグリーメントが、ハードウェアコンポーネントの故障の確率に応じて満たされるかどうかを決定するサービスレベルアグリーメントモジュールをさらに備える。

例２０は、例１２−１９のいずれかの主題を含み、コンピューティングラックの第２のハードウェアコンポーネントに関連付けられたハードウェア性能測定基準を受信し、第２のハードウェアコンポーネントの使用パターンを示す履歴ワークロードデータをハードウェア性能測定基準に応じて決定し、コンピューティングラックの現在のアプリケーションのアプリケーション記述を履歴ワークロードデータに関連付け、現在のアプリケーションの履歴ワークロードデータ及びアプリケーション記述をリモートコンピューティングデバイスに送信する、性能監視モジュールをさらに備える。

例２１は、例１２−２０のいずれかの主題を含み、ハードウェア性能測定基準を受信することは、第２のハードウェアコンポーネントの測定基準コンポーネントからハードウェア性能測定基準を受信することを含む。

例２２は、例１２−２１のいずれかの主題を含み、履歴ワークロードデータは、第２のハードウェアコンポーネントにおけるロードを示す波形の振幅、周波数、又は位相を有する。

例２３は、例１２−２２のいずれかの主題を含み、履歴ワークロードデータを決定することは、ハードウェア性能測定基準のフーリエ変換を用いて、履歴ワークロードデータを決定することを含む。

例２４は、例１２−２３のいずれかの主題を含み、第２のハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例２５は、性能データ管理のためのコンピューティングデバイスを含み、当該コンピューティングデバイスは、第１のコンピューティングラックの第１のラックコントローラから、第１のコンピューティングラックによって実行可能なコンピューティングアプリケーションの履歴ワークロードデータ及び関連する記述を受信し、履歴ワークロードデータは、第１のコンピューティングラックのハードウェアコンポーネントの使用パターンを示し、第２のコンピューティングラックの第２のラックコントローラから、コンピューティングアプリケーションの記述を受信する、通信モジュールと、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出すアプリケーション性能データベースモジュールとを備え、通信モジュールは、第２のラックコントローラの履歴ワークロードデータをさらに送信する。

例２６は、例２５の主題を含み、コンピューティングアプリケーションの記述はサービステンプレートを有する。

例２７は、例２５及び２６のいずれかの主題を含み、記述は、コンピューティングアプリケーションの構造又は初期化方法を示す。

例２８は、例２５−２７のいずれかの主題を含み、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出すことは、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在するかどうかを判断することと、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在するという判断に応答して、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出すことと、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータは存在しないという判断に応答して、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを推定することと、を含む。

例２９は、例２５−２８のいずれかの主題を含み、履歴ワークロードデータを推定することは、第２のコンピューティングアプリケーションに関連付けられた履歴ワークロードデータに基づいて履歴ワークロードデータを推定することを含み、第２のコンピューティングアプリケーションは、上記コンピューティングアプリケーションと同様である。

例３０は、例２５−２９のいずれかの主題を含み、アプリケーション性能データベースモジュールは、さらに、コンピューティングアプリケーションの履歴ワークロードデータ及び関連する記述の受信に応答して、コンピューティングアプリケーションに関連付けられた推定ワークロードデータを、コンピューティングアプリケーションに関連付けられた履歴ワークロードデータに置き換える。

例３１は、データセンタワークロードの最適化のための管理インタフェースを含み、管理インタフェースは、（ｉ）データセンタのシステム状態を表すインタラクティブな可視化を生成し、（ｉｉ）インタラクティブな可視化に応答する人間の入力を受信するインタラクティブ可視化モジュールと、人間の入力をデータセンタのワークロードスケジューリングを最適化するために機械可読ルールに変換するインタラクション変換モジュールと、機械可読ルールに基づいてデータセンタのデータセンタスケジュールを最適化する最適化エンジンモジュールと、を有する。

例３２は、例３１の主題を含み、最適化エンジンモジュールは、さらに、データセンタのワークロードスケジューリングを最適化するために予め定められたルールを決定し、データセンタスケジュールを最適化することは、さらに、予め定められたルールに基づいて、データセンタデータセンタスケジュールを最適化することを含む。

例３３は、例３１及び３２のいずれかの主題を含み、予め定められたルールを決定することは、データセンタに関連付けられたサービスレベルアグリーメントに基づいて、予め定められたルールを決定することを含む。

例３４は、例３１−３３のいずれかの主題を含み、データセンタの複数のセンサからセンサーデータを受信するシステム状態モジュールをさらに備え、センサーデータは、データセンタのシステム状態を示し、インタラクティブな可視化を生成することは、センサーデータの受信に応答してインタラクティブな可視化を生成することを含む。

例３５は、例３１−３４のいずれかの主題を含み、最適化エンジンモジュールは、さらに、データセンタスケジューラの最適化に応答して、データセンタスケジュールに基づいてデータセンタのシステム状態を調整し、インタラクティブ可視化モジュールは、さらに、データセンタのシステム状態の調整に応答して、データセンタのシステム状態を表すインタラクティブな可視化を更新する。

例３６は、データセンタ管理のための方法を含み、当該方法は、コンピューティングラックのラックコントローラによって、コンピューティングラックのハードウェアコンポーネントに関連付けられた、システム測定基準、性能測定基準、又は健全性測定基準を有する測定基準を受信する段階と、ラックコントローラによって、ハードウェアコンポーネントに関連付けられた測定基準に基づいてハードウェアコンポーネントについての回帰モデルを決定する段階と、ラックコントローラによって、ハードウェアコンポーネントについての回帰モデルに基づいて、ハードウェアコンポーネントの平均故障間隔値を決定する段階と、ラックコントローラによって、論理マシンの平均故障間隔値をハードウェアコンポーネントの平均故障間隔値に基づいて決定する段階と、を備え、論理マシンは、ハードウェアコンポーネントに関連付けられる。

例３７は、例３６の主題を含み、測定基準を受信する段階は、ハードウェアコンポーネントの測定基準コンポーネントから測定基準を受信する段階を含む。

例３８は、例３６及び３７のいずれかの主題を含み、ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例３９は、例３６−３８のいずれかの主題を含み、回帰モデルを決定する段階は、線形回帰モデルを決定する段階を含む。

例４０は、例３６−３９のいずれかの主題を含み、回帰モデルを決定する段階は、非線形回帰モデルを決定する段階を含む。

例４１は、例３６−４０のいずれかの主題を含み、ハードウェアコンポーネントの平均故障間隔値を決定する段階は、回帰モデルに基づいて、ハードウェアコンポーネントに関連付けられた予測測定基準を決定する段階と、予測測定基準を予め定められた閾値測定基準と比較する段階とを含む。

例４２は、例３６−４１のいずれかの主題を含み、ハードウェアコンポーネントの平均故障間隔値を決定する段階は、回帰モデルに基づいて、ハードウェアコンポーネントに関連付けられた予測測定基準を決定する段階と、ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定する段階と、予測測定基準をサービスレベル測定基準と比較する段階と、を含む。

例４３は、例３６−４２のいずれかの主題を含み、ラックコントローラによって、ハードウェアコンポーネントの平均故障間隔値をユーザに通知する段階をさらに備える。

例４４は、例３６−４３のいずれかの主題を含み、ラックコントローラによって、論理マシンの平均故障間隔値に基づいて、論理マシンに関連付けられたメンテナンスセッションのための未来時を決定する段階をさらに備える。

例４５は、例３６−４４のいずれかの主題を含み、ラックコントローラによって、論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられた性能指標を受信する段階をさらに備え、未来時を決定する段階は、性能指標に基づいて、未来時を決定する段階をさらに含む。

例４６は、例３６−４５のいずれかの主題を含み、ラックコントローラによって、コンピューティングラックの複数のハードウェアコンポーネントを識別する段階であって、複数のハードウェアコンポーネントは、ハードウェアコンポーネントを有し、ハードウェアコンポーネントのそれぞれに関連付けられる平均故障間隔値は、ハードウェアコンポーネントの平均故障間隔値と同様である、段階と、ラックコントローラによって、論理マシンが複数のハードウェアコンポーネントを含むように構成する段階と、をさらに備える。

例４７は、データセンタスケジューリングを最適化するための方法を含み、当該方法は、コンピューティングラックのラックコントローラによって、コンピューティングラックによって実行可能なコンピューティングアプリケーションの記述を受信する段階と、ラックコントローラによって、コンピューティングアプリケーションの記述をリモートコンピューティングデバイスに送信する段階と、コンピューティングアプリケーションの記述を送信する段階に応答して、ラックコントローラによって、リモートコンピューティングデバイスからアプリケーションに関連付けられた予測ワークロードデータを受信する段階であって、予測ワークロードデータは、コンピューティングラックのハードウェアコンポーネントの使用パターンを示す、段階と、ラックコントローラによって、予側ワークロードデータに基づいて、コンピューティングラックのハードウェアコンポーネントの故障の確率を決定する段階と、を備える。

例４８は、例４７の主題を含み、コンピューティングアプリケーションの記述は、サービステンプレートを含む。

例４９は、例４７及び４８のいずれかの主題を含み、記述は、コンピューティングアプリケーションの構造又は初期化方法を示す。

例５０は、例４７−４９のいずれかの主題を含み、予測ワークロードデータは、ハードウェアコンポーネントにおけるロードを示す波形の振幅、周波数、又は位相を含む。

例５１は、例４７−５０のいずれかの主題を含み、ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例５２は、例４７−５１のいずれかの主題を含み、ラックコントローラによって、コンピューティングラックの複数のハードウェアコンポーネントから複数の利用可能なハードウェアコンポーネントを識別する段階であって、複数の利用可能なハードウェアコンポーネントは、コンピューティングアプリケーションを実行するのに利用可能である、段階と、ラックコントローラによって、予測ワークロードデータに基づいて、複数の利用可能なハードウェアコンポーネントの各々の故障の確率を決定する段階と、をさらに備える。

例５３は、例４７−５２のいずれかの主題を含み、ラックコントローラによって、複数の利用可能なハードウェアコンポーネントからコンピューティングアプリケーションを複数の利用可能なハードウェアコンポーネントの各々の故障の確率に応じて実行するのに利用可能なハードウェアコンポーネントを選択する段階をさらに備える。

例５４は、例４７−５３のいずれかの主題を含み、ラックコントローラによって、コンピューティングアプリケーションに関連付けられたサービスレベルアグリーメントが、ハードウェアコンポーネントの故障の確率に応じて満たされるかどうかを決定する段階をさらに備える。

例５５は、例４７−５４のいずれかの主題を含み、ラックコントローラによって、コンピューティングラックの第２のハードウェアコンポーネントに関連付けられたハードウェア性能測定基準を受信する段階と、ラックコントローラによって、第２のハードウェアコンポーネントの使用パターンを示す履歴ワークロードデータをハードウェア性能測定基準に応じて決定する段階と、ラックコントローラによって、コンピューティングラックの現在のアプリケーションのアプリケーション記述を履歴ワークロードデータに関連付ける段階と、ラックコントローラによって、現在のアプリケーションの履歴ワークロードデータ及びアプリケーション記述をリモートコンピューティングデバイスに送信する段階と、をさらに備える。

例５６は、例４７−５５のいずれかの主題を含み、ハードウェア性能測定基準を受信する段階は、第２のハードウェアコンポーネントの測定基準コンポーネントからハードウェア性能測定基準を受信する段階を含む。

例５７は、例４７−５６のいずれかの主題を含み、履歴ワークロードデータは、第２のハードウェアコンポーネントにおけるロードを示す波形の振幅、周波数、又は位相を有する。

例５８は、例４７−５７のいずれかの主題を含み、履歴ワークロードデータを決定する段階は、ハードウェア性能測定基準のフーリエ変換を用いて履歴ワークロードデータを決定する段階を含む。

例５９は、例４７−５８のいずれかの主題を含み、第２のハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例６０は、性能データ管理のための方法を含み、当該方法は、第１のコンピューティングラックの第１のラックコントローラからコンピューティングデバイスによって、第１のコンピューティングラックによって実行可能なコンピューティングアプリケーション履歴ワークロードデータ及び関連する記述を受信する段階であって、履歴ワークロードデータは、第１のコンピューティングラックのハードウェアコンポーネントの使用パターンを示す、段階と、第２のコンピューティングラックの第２のラックコントローラからコンピューティングデバイスによって、コンピューティングアプリケーションの記述を受信する段階と、コンピューティングデバイスによって、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出す段階と、コンピューティングデバイスによって、履歴ワークロードデータを第２のラックコントローラに送信する段階と、を備える。

例６１は、例６０の主題を含み、コンピューティングアプリケーションの記述は、サービステンプレートを含む。

例６２は、例６０及び６１のいずれかの主題を含み、記述は、コンピューティングアプリケーションの構造又は初期化方法を示す。

例６３は、例６０−６２のいずれかの主題を含み、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出す段階は、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在するかどうかを判断する段階と、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在するという判断に応答して、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出す段階と、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在しないとい判断に応答して、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを推定する段階と、を含む。

例６４は、例６０−６３のいずれかの主題を含み、履歴ワークロードデータを推定する段階は、第２のコンピューティングアプリケーションに関連付けられた履歴ワークロードデータに基づいて履歴ワークロードデータを推定する段階を含み、第２のコンピューティングアプリケーションは、コンピューティングアプリケーションと同様である。

例６５は、例６０−６４のいずれかの主題を含み、コンピューティングアプリケーションの履歴ワークロードデータ及び関連する記述を受信する段階に応答して、コンピューティングデバイスによって、コンピューティングアプリケーションに関連付けられた推定ワークロードデータを、コンピューティングアプリケーションに関連付けられた履歴ワークロードデータに置き換える段階をさらに備える。

例６６は、データセンタワークロードの最適化のための方法を含み、当該方法は、管理インタフェースによって、データセンタのシステム状態を表すインタラクティブな可視化を生成する段階と、管理インタフェースによって、インタラクティブな可視化に応答する人間の入力を受信する段階と、管理インタフェースによって、データセンタのワークロードスケジューリングを最適化するための人間の入力を機械可読ルールに変換する段階と、管理インタフェースによって、機械可読ルールに基づいてデータセンタのデータセンタスケジュールを最適化する段階と、を備える。

例６７は、例６６の主題を含み、管理インタフェースによって、データセンタのワークロードスケジューリングを最適化するための予め定められたルールを決定する段階をさらに備え、データセンタスケジュールを最適化する段階は、予め定められたルールに基づいて、データセンタのデータセンタスケジュールを最適化する段階をさらに含む。

例６８は、例６６及び６７のいずれかの主題を含み、予め定められたルールを決定する段階は、データセンタに関連付けられたサービスレベルアグリーメントに基づいて、予め定められたルールを決定する段階を含む。

例６９は、例６６−６８のいずれかの主題を含み、管理インタフェースによって、データセンタの複数のセンサから、データセンタのシステム状態を示すセンサーデータを受信する段階をさらに備え、インタラクティブな可視化を生成する段階は、センサーデータを受信する段階に応答してインタラクティブな可視化を生成する段階を含む。

例７０は、例６６−６９のいずれかの主題を含み、データセンタスケジューラを最適化する段階に応答して、管理インタフェースによって、データセンタスケジュールに基づいてデータセンタのシステム状態を調節する段階と、データセンタのシステム状態を調節する段階に応答して、管理インタフェースによって、データセンタのシステム状態を表すインタラクティブな可視化を更新する段階と、をさらに備える。

例７１は、プロセッサと、プロセッサによって実行された場合に、コンピューティングデバイスに例３６−７０のいずれかの方法を実行させる複数の命令が中に格納されたメモリとを備える、コンピューティングデバイスを含む。

例７２は、実行されたことに応答して、コンピューティングデバイスが、例３６−７０のいずれかの方法を実行する結果をもたらす複数の命令をそこに格納して、備える、１又は複数の機械可読記憶媒体を含む。

例７３は、例３６−７０のいずれかの方法を実行するための手段を備えるコンピューティングデバイスを含む。

例７４は、コンピューティングラックのラックコントローラを含み、当該ラックコントローラは、コンピューティングラックのハードウェアコンポーネントに関連付けられた測定基準を受信するための手段であって、測定基準は、システム測定基準、性能測定基準、又は健全性測定基準を有する、手段と、ハードウェアコンポーネントに関連付けられた測定基準に基づいてハードウェアコンポーネントについて回帰モデルを決定するための手段と、ハードウェアコンポーネントについての回帰モデルに基づいて、ハードウェアコンポーネントの平均故障間隔値を決定するための手段と、ハードウェアコンポーネントの平均故障間隔値に基づいて、論理マシンの平均故障間隔値を決定するための手段とを備え、論理マシンは、ハードウェアコンポーネントに関連付けられる。

例７５は、例７４の主題を含み、測定基準を受信するための手段は、ハードウェアコンポーネントの測定基準コンポーネントから測定基準を受信するための手段を含む。

例７６は、例７４及び７５のいずれかの主題を含み、ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例７７は、例７４−７６のいずれかの主題を含み、回帰モデルを決定するための手段は、線形回帰モデルを決定するための手段を含む。

例７８は、例７４−７７のいずれかの主題を含み、回帰モデルを決定するための手段は、非線形回帰モデルを決定するための手段を含む。

例７９は、例７４−７８のいずれかの主題を含み、ハードウェアコンポーネントの平均故障間隔値を決定するための手段は、回帰モデルに基づいて、ハードウェアコンポーネントに関連付けられた予測測定基準を決定するための手段と、予測測定基準を予め定められた閾値測定基準と比較するための手段とを含む。

例８０は、例７４−７９のいずれかの主題を含み、ハードウェアコンポーネントの平均故障間隔値を決定するための手段は、回帰モデルに基づいて、ハードウェアコンポーネントに関連付けられた予測測定基準を決定するための手段と、ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定するための手段と、予測測定基準をサービスレベル測定基準と比較するための手段とを含む。

例８１は、例７４−８０のいずれかの主題を含み、ハードウェアコンポーネントの平均故障間隔値をユーザに通知するための手段をさらに備える。

例８２は、例７４−８１のいずれかの主題を含み、論理マシンの平均故障間隔値に基づいて、論理マシンに関連付けられたメンテナンスセッションのための未来時を決定するための手段をさらに備える。

例８３は、例７４−８２のいずれかの主題を含み、論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられた性能指標を受信するための手段をさらに備え、未来時を決定するための手段は、性能指標に基づいて、未来時を決定するための手段をさらに含む。

例８４は、例７４−８３のいずれかの主題を含み、コンピューティングラックの複数のハードウェアコンポーネントを識別するための手段であって、複数のハードウェアコンポーネントは、上記ハードウェアコンポーネントを有し、ハードウェアコンポーネントのそれぞれに関連付けられる平均故障間隔値は、ハードウェアコンポーネントの平均故障間隔値と同様である、手段と、複数のハードウェアコンポーネントを含む論理マシンを構成するための手段と、をさらに備える。

例８５は、コンピューティングラックのラックコントローラを含み、ラックコントローラは、コンピューティングラックによって実行可能なコンピューティングアプリケーションの記述を受信するための手段と、コンピューティングアプリケーションの記述をリモートコンピューティングデバイスに送信するための手段と、コンピューティングアプリケーションの記述を送信する段階に応答して、リモートコンピューティングデバイスからアプリケーションに関連付けられた予測ワークロードデータを受信するための手段であって、予測ワークロードデータは、コンピューティングラックのハードウェアコンポーネントの使用パターンを示す、手段と、予側ワークロードデータに基づいて、コンピューティングラックのハードウェアコンポーネントの故障の確率を決定するための手段と、を備える。

例８６は、例８５の主題を含み、コンピューティングアプリケーションの記述は、サービステンプレートを含む。

例８７は、例８５及び８６のいずれかの主題を含み、記述は、コンピューティングアプリケーションの構造又は初期化方法を示す。

例８８は、例８５−８７のいずれかの主題を含み、予測ワークロードデータは、ハードウェアコンポーネントにおけるロードを示す波形の振幅、周波数、又は位相を含む。

例８９は、例８５−８８のいずれかの主題を含み、ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例９０は、例８５−８９のいずれかの主題を含み、コンピューティングラックの複数のハードウェアコンポーネントから複数の利用可能なハードウェアコンポーネントを識別するための手段であって、複数の利用可能なハードウェアコンポーネントは、コンピューティングアプリケーションを実行するのに利用可能である、手段と、予測ワークロードデータに基づいて、複数の利用可能なハードウェアコンポーネントの各々の故障の確率を決定するための手段とをさらに備える。

例９１は、例８５−９０のいずれかの主題を含み、コンピューティングアプリケーションを、複数の利用可能なハードウェアコンポーネントの各々の故障の確率に応じて実行するべく、複数の利用可能なハードウェアコンポーネントから利用可能なハードウェアコンポーネントを選択するための手段をさらに備える。

例９２は、例８５−９１のいずれかの主題を含み、コンピューティングアプリケーションに関連付けられたサービスレベルアグリーメントがハードウェアコンポーネントの故障の確率に応じて満たされるかどうかを判断するための手段をさらに備える。

例９３は、例８５−９２のいずれかの主題を含み、コンピューティングラックの第２のハードウェアコンポーネントに関連付けられたハードウェア性能測定基準を受信するための手段と、履歴ワークロードデータをハードウェア性能測定基準に応じて決定するための手段であって、履歴ワークロードデータは第２のハードウェアコンポーネントの使用パターンを示す、手段と、コンピューティングラックの現在のアプリケーションのアプリケーション記述を履歴ワークロードデータに関連付けるための手段と、現在のアプリケーションの履歴ワークロードデータ及びアプリケーション記述をリモートコンピューティングデバイスに送信するための手段と、をさらに備える。

例９４は、例８５−９３のいずれかの主題を含み、ハードウェア性能測定基準を受信するための手段は、ハードウェア性能測定基準を第２のハードウェアコンポーネントの測定基準コンポーネントから受信するための手段を含む。

例９５は、例８５−９４のいずれかの主題を含み、履歴ワークロードデータは、第２のハードウェアコンポーネントにおけるロードを示す波形の振幅、周波数、又は位相を含む。

例９６は、例８５−９５のいずれかの主題を含み、履歴ワークロードデータを決定するための手段は、ハードウェア性能測定基準のフーリエ変換を用いて履歴ワークロードデータを決定するための手段を含む。

例９７は、例８５−９６のいずれかの主題を含み、第２のハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する。

例９８は、性能データ管理のためのコンピューティングデバイスを含み、当該コンピューティングデバイスは、履歴ワークロードデータ及び第１のコンピューティングラックによって実行可能なコンピューティングアプリケーションの関連する記述を第１のコンピューティングラックの第１のラックコントローラから受信するための手段であって、履歴ワークロードデータは、第１のコンピューティングラックのハードウェアコンポーネントの使用パターンを示す、手段と、第２のコンピューティングラックの第２のラックコントローラからコンピューティングアプリケーションの記述を受信するための手段と、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出すための手段と、履歴ワークロードデータを第２のラックコントローラに送信するための手段と、を備える。

例９９は、例９８の主題を含み、コンピューティングアプリケーションの記述は、サービステンプレートを含む。

例１００は、例９８及び９９のいずれかの主題を含み、記述は、コンピューティングアプリケーションの構造又は初期化方法を示す。

例１０１は、例９８−１００のいずれかの主題を含み、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出すための手段は、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在するかどうかを判断するための手段と、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在するという判断に応答して、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを取り出すための手段と、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータが存在しないという判断に応答して、コンピューティングアプリケーションの記述に関連付けられた履歴ワークロードデータを推定するための手段と、を含む。

例１０２は、例９８−１０１のいずれかの主題を含み、履歴ワークロードデータを推定するための手段は、第２のコンピューティングアプリケーションに関連付けられた履歴ワークロードデータに基づいて履歴ワークロードデータを推定するための手段を含み、第２のコンピューティングアプリケーションは、コンピューティングアプリケーションと同様である。

例１０３は、例９８−１０２のいずれかの主題を含み、コンピューティングアプリケーションの履歴ワークロードデータ及び関連する記述を受信することに応答して、コンピューティングデバイスによって、コンピューティングアプリケーションに関連付けられた推定ワークロードデータを、コンピューティングアプリケーションに関連付けられた履歴ワークロードデータに置き換えるための手段をさらに備える。

例１０４は、データセンタワークロードの最適化のための管理インタフェースを含み、当該管理インタフェースは、データセンタのシステム状態を表すインタラクティブな可視化を生成するための手段と、インタラクティブな可視化に応答した人間の入力を受信するための手段と、データセンタのワークロードスケジューリングを最適化するために人間の入力を機械可読ルールに変換するための手段と、機械可読ルールに基づいてデータセンタのデータセンタスケジュールを最適化するための手段とを備える。

例１０５は、例１０４の主題を含み、データセンタのワークロードスケジューリングを最適化するために予め定められたルールを決定するための手段をさらに備え、データセンタスケジュールを最適化するための手段は、予め定められたルールに基づいて、データセンタのデータセンタスケジュールを最適化するための手段をさらに含む。

例１０６は、例１０４及び１０５のいずれかの主題を含み、予め定められたルールを決定するための手段は、データセンタに関連付けられたサービスレベルアグリーメントに基づいて、予め定められたルールを決定するための手段を含む。

例１０７は、例１０４−１０６のいずれかの主題を含み、データセンタの複数のセンサからセンサーデータを受信するための手段をさらに備え、センサーデータは、データセンタのシステム状態を示し、インタラクティブな可視化を生成するための手段は、センサーデータを受信することに応答してインタラクティブな可視化を生成するための手段を含む。

例１０８は、例１０４−１０７のいずれかの主題を含み、データセンタスケジューラを最適化することに応答して、データセンタスケジュールに基づいてデータセンタのシステム状態を調節するための手段と、データセンタのシステム状態を調節することに応答して、データセンタのシステム状態を表すインタラクティブな可視化を更新するための手段とをさらに備える。

例１０８は、例１０４−１０７のいずれかの主題を含み、データセンタスケジューラを最適化することに応答して、データセンタスケジュールに基づいてデータセンタのシステム状態を調節するための手段と、データセンタのシステム状態を調節することに応答して、データセンタのシステム状態を表すインタラクティブな可視化を更新するための手段とをさらに備える。
［項目１］
コンピューティングラックのラックコントローラであって、
上記コンピューティングラックのハードウェアコンポーネントに関連付けられた測定基準を受信する性能監視モジュールであって、上記測定基準は、システム測定基準、性能測定基準、又は健全性測定基準を有する、性能監視モジュールと、
上記ハードウェアコンポーネントに関連付けられた上記測定基準に基づいて上記ハードウェアコンポーネントについて回帰モデルを決定し、
上記ハードウェアコンポーネントについての上記回帰モデルに基づいて、上記ハードウェアコンポーネントの平均故障間隔値を決定し、
上記ハードウェアコンポーネントの上記平均故障間隔値に基づいて、論理マシンの平均故障間隔値を決定する、分析モジュールであって、
上記論理マシンは、上記ハードウェアコンポーネントに関連付けられる、分析モジュールと、を備える、
ラックコントローラ。
［項目２］
上記測定基準を受信することは、上記ハードウェアコンポーネントの測定基準コンポーネントから上記測定基準を受信することを含む、項目１に記載のラックコントローラ。
［項目３］
上記ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する、項目１又は２に記載のラックコントローラ。
［項目４］
上記回帰モデルを決定することは、線形回帰モデルを決定することを含む、項目１から３のいずれか一項に記載のラックコントローラ。
［項目５］
上記回帰モデルを決定することは、非線形回帰モデルを決定することを含む、項目１から３のいずれか一項に記載のラックコントローラ。
［項目６］
上記ハードウェアコンポーネントの上記平均故障間隔値を決定することは、
上記回帰モデルに基づいて、上記ハードウェアコンポーネントに関連付けられた予測測定基準を決定することと、
上記予測測定基準を予め定められた閾値測定基準と比較することと、を含む、項目１から５のいずれか一項に記載のラックコントローラ。
［項目７］
上記ハードウェアコンポーネントの上記平均故障間隔値を決定することは、
上記回帰モデルに基づいて、上記ハードウェアコンポーネントに関連付けられた予測測定基準を決定することと、
上記ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定することと、
上記予測測定基準を上記サービスレベル測定基準と比較することと、を含む、項目１から６のいずれか一項に記載のラックコントローラ。
［項目８］
上記ハードウェアコンポーネントの上記平均故障間隔値をユーザに通知するデータセンタ管理モジュールをさらに備える、項目１から７のいずれか一項に記載のラックコントローラ。
［項目９］
上記論理マシンの上記平均故障間隔値に基づいて、上記論理マシンに関連付けられたメンテナンスセッションのための未来時を決定するデータセンタ管理モジュールをさらに備える、項目１から７のいずれか一項に記載のラックコントローラ。
［項目１０］
上記性能監視モジュールは、上記論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられた性能指標をさらに受信し、
上記未来時を決定することは、上記性能指標に基づいて、上記未来時を決定することをさらに含む、項目９に記載のラックコントローラ。
［項目１１］
データセンタ管理モジュールをさらに備え、当該データセンタ管理モジュールは、上記コンピューティングラックの複数のハードウェアコンポーネントを識別し、上記複数のハードウェアコンポーネントは上記ハードウェアコンポーネントを有し、上記複数のハードウェアコンポーネントのそれぞれに関連付けられた平均故障間隔値は、上記ハードウェアコンポーネントの平均故障間隔値と同様であり、
上記論理マシンが上記複数のハードウェアコンポーネントを含むように上記論理マシンを構成する、項目１から７のいずれか一項に記載のラックコントローラ。
［項目１２］
データセンタ管理のための方法であって、
コンピューティングラックのラックコントローラによって、上記コンピューティングラックのハードウェアコンポーネントに関連付けられた測定基準を受信する段階であって、上記測定基準は、システム測定基準、性能測定基準、又は健全性測定基準を有する、段階と、
上記ラックコントローラによって、上記ハードウェアコンポーネントに関連付けられた上記測定基準に基づいて上記ハードウェアコンポーネントについて回帰モデルを決定する段階と、
上記ラックコントローラによって、上記ハードウェアコンポーネントについての上記回帰モデルに基づいて、上記ハードウェアコンポーネントの平均故障間隔値を決定する段階と、
上記ラックコントローラによって、上記ハードウェアコンポーネントの上記平均故障間隔値に基づいて、論理マシンの平均故障間隔値を決定する段階であって、上記論理マシンは、上記ハードウェアコンポーネントに関連付けられる、段階と、を備える、方法。
［項目１３］
上記測定基準を受信する段階は、上記ハードウェアコンポーネントの測定基準コンポーネントから上記測定基準を受信する段階を有する、項目１２に記載の方法。
［項目１４］
上記ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する、項目１２又は１３に記載の方法。
［項目１５］
上記回帰モデルを決定する段階は、線形回帰モデルを決定する段階を有する、項目１２から１４のいずれか一項に記載の方法。
［項目１６］
上記回帰モデルを決定する段階は、非線形回帰モデルを決定する段階を有する、項目１２から１４のいずれか一項に記載の方法。
［項目１７］
上記ハードウェアコンポーネントの上記平均故障間隔値を決定する段階は、
上記回帰モデルに基づいて、上記ハードウェアコンポーネントに関連付けられた予測測定基準を決定する段階と、
上記予測測定基準を予め定められた閾値測定基準と比較する段階と、を有する、項目１２から１６のいずれか一項に記載の方法。
［項目１８］
上記ハードウェアコンポーネントの上記平均故障間隔値を決定する段階は、
上記回帰モデルに基づいて、上記ハードウェアコンポーネントに関連付けられた予測測定基準を決定する段階と、
上記ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定する段階と、
上記予測測定基準を上記サービスレベル測定基準と比較する段階と、を有する、項目１２から１７のいずれか一項に記載の方法。
［項目１９］
上記ラックコントローラによって、上記ハードウェアコンポーネントの上記平均故障間隔値をユーザに通知する段階をさらに備える、項目１２から１８のいずれか一項に記載の方法。
［項目２０］
上記ラックコントローラによって、上記論理マシンの上記平均故障間隔値に基づいて、上記論理マシンに関連付けられたメンテナンスセッションのための未来時を決定する段階をさらに備える、項目１２から１９のいずれか一項に記載の方法。
［項目２１］
上記ラックコントローラによって、上記論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられる性能指標を受信する段階をさらに備え、
上記未来時を決定する段階は、上記性能指標に基づいて、上記未来時を決定する段階をさらに有する、項目２０に記載の方法。
［項目２２］
上記ラックコントローラによって、上記コンピューティングラックの複数のハードウェアコンポーネントを識別する段階であって、上記複数のハードウェアコンポーネントは、上記ハードウェアコンポーネントを有し、上記複数のハードウェアコンポーネントのそれぞれに関連付けられた平均故障間隔値は、上記ハードウェアコンポーネントの上記平均故障間隔値と同様である、段階と、
上記ラックコントローラによって、上記論理マシンが上記複数のハードウェアコンポーネントを含むように上記論理マシンを構成する段階と、をさらに備える、項目１２から２１のいずれか一項に記載の方法。
［項目２３］
コンピューティングデバイスであって、
プロセッサと、
上記プロセッサが実行された場合、上記コンピューティングデバイスに、項目１２から２２のいずれか一項に記載の方法を実行させる複数の命令を格納したメモリと、を備える、コンピューティングデバイス。
［項目２４］
実行されることに応答して、コンピューティングデバイスが項目１２から２２のいずれか一項に記載の方法を実行するという結果をもたらす、それに格納された複数の命令を備える、１又は複数の機械可読記憶媒体。
［項目２５］
項目１２から２２のいずれか一項に記載の方法を実行するための手段を備える、コンピューティングデバイス。

Claims (25)

1. コンピューティングラックのラックコントローラであって、
   前記コンピューティングラックのハードウェアコンポーネントに関連付けられた測定基準を受信する性能監視モジュールであって、前記測定基準は、システム測定基準、性能測定基準、又は健全性測定基準を有する、性能監視モジュールと、
   前記ハードウェアコンポーネントに関連付けられた前記測定基準に基づいて前記ハードウェアコンポーネントについて回帰モデルを決定し、
   前記ハードウェアコンポーネントについての前記回帰モデルに基づいて、前記ハードウェアコンポーネントの平均故障間隔値を決定し、
   前記ハードウェアコンポーネントの前記平均故障間隔値に基づいて、論理マシンの平均故障間隔値を決定する、分析モジュールであって、
   前記論理マシンは、前記ハードウェアコンポーネントに関連付けられる、分析モジュールと、を備える、
   ラックコントローラ。
2. 前記測定基準を受信することは、前記ハードウェアコンポーネントの測定基準コンポーネントから前記測定基準を受信することを含む、請求項１に記載のラックコントローラ。
3. 前記ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する、請求項１又は２に記載のラックコントローラ。
4. 前記回帰モデルを決定することは、線形回帰モデルを決定することを含む、請求項１から３のいずれか一項に記載のラックコントローラ。
5. 前記回帰モデルを決定することは、非線形回帰モデルを決定することを含む、請求項１から３のいずれか一項に記載のラックコントローラ。
6. 前記ハードウェアコンポーネントの前記平均故障間隔値を決定することは、
   前記回帰モデルに基づいて、前記ハードウェアコンポーネントに関連付けられた予測測定基準を決定することと、
   前記予測測定基準を予め定められた閾値測定基準と比較することと、を含む、請求項１から５のいずれか一項に記載のラックコントローラ。
7. 前記ハードウェアコンポーネントの前記平均故障間隔値を決定することは、
   前記回帰モデルに基づいて、前記ハードウェアコンポーネントに関連付けられた予測測定基準を決定することと、
   前記ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定することと、
   前記予測測定基準を前記サービスレベル測定基準と比較することと、を含む、請求項１から６のいずれか一項に記載のラックコントローラ。
8. 前記ハードウェアコンポーネントの前記平均故障間隔値をユーザに通知するデータセンタ管理モジュールをさらに備える、請求項１から７のいずれか一項に記載のラックコントローラ。
9. 前記論理マシンの前記平均故障間隔値に基づいて、前記論理マシンに関連付けられたメンテナンスセッションのための未来時を決定するデータセンタ管理モジュールをさらに備える、請求項１から７のいずれか一項に記載のラックコントローラ。
10. 前記性能監視モジュールは、前記論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられた性能指標をさらに受信し、
    前記未来時を決定することは、前記性能指標に基づいて、前記未来時を決定することをさらに含む、請求項９に記載のラックコントローラ。
11. データセンタ管理モジュールをさらに備え、当該データセンタ管理モジュールは、前記コンピューティングラックの複数のハードウェアコンポーネントを識別し、前記複数のハードウェアコンポーネントは前記ハードウェアコンポーネントを有し、前記複数のハードウェアコンポーネントのそれぞれに関連付けられた平均故障間隔値は、前記ハードウェアコンポーネントの平均故障間隔値と同様であり、
    前記論理マシンが前記複数のハードウェアコンポーネントを含むように前記論理マシンを構成する、請求項１から７のいずれか一項に記載のラックコントローラ。
12. データセンタ管理のための方法であって、
    コンピューティングラックのラックコントローラによって、前記コンピューティングラックのハードウェアコンポーネントに関連付けられた測定基準を受信する段階であって、前記測定基準は、システム測定基準、性能測定基準、又は健全性測定基準を有する、段階と、
    前記ラックコントローラによって、前記ハードウェアコンポーネントに関連付けられた前記測定基準に基づいて前記ハードウェアコンポーネントについて回帰モデルを決定する段階と、
    前記ラックコントローラによって、前記ハードウェアコンポーネントについての前記回帰モデルに基づいて、前記ハードウェアコンポーネントの平均故障間隔値を決定する段階と、
    前記ラックコントローラによって、前記ハードウェアコンポーネントの前記平均故障間隔値に基づいて、論理マシンの平均故障間隔値を決定する段階であって、前記論理マシンは、前記ハードウェアコンポーネントに関連付けられる、段階と、を備える、方法。
13. 前記測定基準を受信する段階は、前記ハードウェアコンポーネントの測定基準コンポーネントから前記測定基準を受信する段階を有する、請求項１２に記載の方法。
14. 前記ハードウェアコンポーネントは、計算リソース、メモリリソース、ストレージリソース、又はネットワークリソースを有する、請求項１２又は１３に記載の方法。
15. 前記回帰モデルを決定する段階は、線形回帰モデルを決定する段階を有する、請求項１２から１４のいずれか一項に記載の方法。
16. 前記回帰モデルを決定する段階は、非線形回帰モデルを決定する段階を有する、請求項１２から１４のいずれか一項に記載の方法。
17. 前記ハードウェアコンポーネントの前記平均故障間隔値を決定する段階は、
    前記回帰モデルに基づいて、前記ハードウェアコンポーネントに関連付けられた予測測定基準を決定する段階と、
    前記予測測定基準を予め定められた閾値測定基準と比較する段階と、を有する、請求項１２から１６のいずれか一項に記載の方法。
18. 前記ハードウェアコンポーネントの前記平均故障間隔値を決定する段階は、
    前記回帰モデルに基づいて、前記ハードウェアコンポーネントに関連付けられた予測測定基準を決定する段階と、
    前記ハードウェアコンポーネントに関連付けられたサービスレベルアグリーメントのサービスレベル測定基準を決定する段階と、
    前記予測測定基準を前記サービスレベル測定基準と比較する段階と、を有する、請求項１２から１７のいずれか一項に記載の方法。
19. 前記ラックコントローラによって、前記ハードウェアコンポーネントの前記平均故障間隔値をユーザに通知する段階をさらに備える、請求項１２から１８のいずれか一項に記載の方法。
20. 前記ラックコントローラによって、前記論理マシンの前記平均故障間隔値に基づいて、前記論理マシンに関連付けられたメンテナンスセッションのための未来時を決定する段階をさらに備える、請求項１２から１９のいずれか一項に記載の方法。
21. 前記ラックコントローラによって、前記論理マシンに割り当てられたコンピューティングアプリケーションに関連付けられる性能指標を受信する段階をさらに備え、
    前記未来時を決定する段階は、前記性能指標に基づいて、前記未来時を決定する段階をさらに有する、請求項２０に記載の方法。
22. 前記ラックコントローラによって、前記コンピューティングラックの複数のハードウェアコンポーネントを識別する段階であって、前記複数のハードウェアコンポーネントは、前記ハードウェアコンポーネントを有し、前記複数のハードウェアコンポーネントのそれぞれに関連付けられた平均故障間隔値は、前記ハードウェアコンポーネントの前記平均故障間隔値と同様である、段階と、
    前記ラックコントローラによって、前記論理マシンが前記複数のハードウェアコンポーネントを含むように前記論理マシンを構成する段階と、をさらに備える、請求項１２から２１のいずれか一項に記載の方法。
23. コンピューティングデバイスであって、
    プロセッサと、
    前記プロセッサが実行された場合、前記コンピューティングデバイスに、請求項１２から２２のいずれか一項に記載の方法を実行させる複数の命令を格納したメモリと、を備える、コンピューティングデバイス。
24. 実行されることに応答して、コンピューティングデバイスが請求項１２から２２のいずれか一項に記載の方法を実行するという結果をもたらす、それに格納された複数の命令を備える、１又は複数の機械可読記憶媒体。
25. 請求項１２から２２のいずれか一項に記載の方法を実行するための手段を備える、コンピューティングデバイス。

Images