(57)【要約】  各種の例示的実施形態は、複数のハードウェア部品のうち故障した部品のハードウェア故障を特定するステップと、故障した部品を利用するように現在設定されているエージェント装置のセットを判定するステップと、複数のハードウェア部品のうち機能している部品を利用するようにエージェント装置を再設定するステップと、の１つまたは複数を含む方法およびそれに関連するネットワークノードに関する。各種の例示的実施形態は、それに加えて、またはそれに代えて、ハードウェアモジュールの故障日を予想するステップと、予想故障日が許容できるかどうかをハードウェアモジュールの目標交換日に基づいて判定するステップと、予想故障日が許容できない場合、ハードウェア部品に対するパラメータ調整を選択するステップであって、パラメータ調整は、予想故障日を目標交換日に近づけるように選択される、選択するステップと、そのパラメータ調整をハードウェア部品に適用するステップと、の１つまたは複数を含む方法およびそれに関連するネットワークノードに関する。
2014531690.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアシステムの漸次的な機能停止を可能にするためにハードウェア管理装置によって行われる方法であって、ハードウェアシステムはハードウェアモジュールを含み、ハードウェアモジュールは、複数のハードウェア部品が搭載された回路基板を含み、方法は、
複数のハードウェア部品のうち故障した部品のハードウェア故障を特定する（３１０）ステップと、
故障した部品を利用するように現在設定されているエージェント装置のセットを判定する（３１５）ステップと、
エージェント装置のセットのうち少なくとも１つのエージェント装置について、故障した部品に代えて、複数のハードウェア部品のうち機能している部品を利用するようにそのエージェント装置を再設定する（３２０）ステップと、
故障した部品を非アクティブ状態にする（３２５）ステップであって、複数のハードウェア部品の他のハードウェア部品は稼働状態を保つ、非アクティブ状態にするステップと
を含む、方法。
【請求項２】
複数のハードウェア部品のうち少なくとも１つの他の部品に電力を供給し続けながら、故障部品の電源を切るようにハードウェアモジュールを再設定するステップをさらに含む、請求項１に記載の方法。
【請求項３】
回路基板に搭載されたすべてのハードウェア部品が単一種類のハードウェア部品である、請求項１または２に記載の方法。
【請求項４】
ハードウェア管理装置がハイパーバイザを含み、ハードウェア管理装置が、複数のハードウェア部品のうち少なくとも１つの部品を利用して動作する、請求項１から３のいずれか一項に記載の方法。
【請求項５】
ハードウェア管理装置がクラウドコンピューティングゲートウェイ装置を含み、
ハードウェア管理装置が複数のハイパーバイザを管理し、
複数のハイパーバイザのうち第１のハイパーバイザが複数のハードウェア部品を管理する、請求項１から４のいずれか一項に記載の方法。
【請求項６】
エージェント装置のセットの少なくとも１つのエージェント装置について、複数のハイパーバイザのうち第２のハイパーバイザで管理されるようにそのエージェント装置を再設定するステップをさらに含む、請求項５に記載の方法。
【請求項７】
ハードウェアモジュールの故障日を予想する（６５０）ステップと、
予想故障日が許容できるかどうかをハードウェアモジュールの目標交換日に基づいて判定する（６５５）ステップと、
予想故障日が許容できない場合、
複数のハードウェア部品のうち少なくとも１つのハードウェア部品に対する少なくとも１つのパラメータ調整を決定する（７１０）ステップであって、少なくとも１つのパラメータ調整は、予想故障日を目標交換日に近づけるように選択される、決定するステップと、
少なくとも１つのパラメータ調整を、複数のハードウェア部品の当該少なくとも１つのハードウェア部品に適用する（７４０）ステップと
をさらに含む、請求項１から６のいずれか一項に記載の方法。
【請求項８】
少なくとも１つのパラメータ調整が、ハードウェアモジュールを予想故障日よりも前に故障させるように選択される、請求項７に記載の方法。
【請求項９】
ハードウェア管理装置が複数のハードウェアモジュールを管理し、各ハードウェアモジュールが現在の寿命段階に関連付けられ、方法がさらに、
エージェント装置の確立を求める要求を受け取るステップと、
要求に関連付けられた寿命段階の許可を判定するステップであって、寿命段階の許可は、許された寿命段階を持つモジュールが要求を満たすために使用されることを指示する、判定するステップと、
複数のハードウェアモジュールからハードウェアモジュールを選択するステップであって、選択されるハードウェアモジュールは許された寿命段階に対応する、選択するステップと、
選択されたハードウェアモジュールを使用して要求を満たすステップと
を含む、請求項７または８に記載の方法。
【請求項１０】
漸次的なハードウェアの機能停止が可能なハードウェアシステムであって、
回路基板（２６０、２７０、２８０）と、
回路基板に搭載された複数のハードウェア部品（２６２、２７２、２７４、２８６）と、
複数のハードウェア部品（２６２、２７２、２７４、２８６）のうち少なくとも１つのハードウェア部品を利用するように構成された少なくとも１つのエージェント装置と、
実行時に、複数のハードウェア部品の少なくとも１つの残りの部品が稼働状態を保ったままで、複数のハードウェア部品のうち少なくとも１つのハードウェア部品を非アクティブ状態にする管理装置（１４０ａ、１４０ｂ）と
を備える、ハードウェアシステム。
【請求項１１】
少なくとも１つのハードウェア部品を非アクティブ状態にする際に、管理装置（１４０ａ、１４０ｂ）が、少なくとも１つの部品の電源を切るように回路基板（２６０、２７０、２８０）を再設定する、請求項１０に記載のハードウェアシステム。
【請求項１２】
管理装置（１４０ａ、１４０ｂ）がハイパーバイザを含み、管理装置が複数のハードウェア部品のうち少なくとも１つのハードウェア部品を利用する、請求項１０または１１に記載のハードウェアシステム。
【請求項１３】
回路基板に搭載されたすべてのハードウェア部品が同一種類である、請求項１０から１２のいずれか一項に記載のハードウェアシステム。
【請求項１４】
少なくとも１つのハードウェア部品を非アクティブ状態にする際に、管理装置（１４０ａ、１４０ｂ）が、
当該少なくとも１つのハードウェア部品を利用するように設定されているエージェント装置のセットを特定し
当該少なくとも１つのハードウェア部品の代わりに、少なくとも１つの残りの部品を利用するように、エージェント装置のセットのうち少なくとも１つのエージェント装置を再設定する、請求項１０から１３のいずれか一項に記載のハードウェアシステム。
【請求項１５】
管理装置（１４０ａ、１４０ｂ）が、複数のハードウェア部品（２６２、２７２、２７４、２８６）の少なくとも１つのハードウェア部品が故障したと判定すると、当該少なくとも１つのハードウェア部品を非アクティブ状態にする、請求項１０から１４のいずれか一項に記載のハードウェアシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、同時係属出願である出願番号第１３／２５０，３３３号、整理番号ＡＬＣ３７４８、Ｂａｕｅｒらによる「稼働中モジュールの診断検査」を相互引用し、同文献は引用によりその全体が本明細書に組み込まれている。
【０００２】
本明細書に開示される各種の例示的実施形態は、一般にはシステムの信頼性および可用性に関する。
【背景技術】
【０００３】
仮想化やクラウドコンピューティング等の技術の台頭により、それまで専用の独立したハードウェアに関連付けられていた各種のアプリケーションを、共有ハードウェアリソースを提供するマシンに移行することが容易になっている。このいわゆる「サーバ統合」により、利用可能なリソースをより完全に利用し、したがって充分に利用されていないリソースに伴う費用を低減させることが可能になる。例えば、それまであまり利用されていなかったサーバを廃棄することにより、エネルギー消費、占有面積、および他のサーバ関係の費用を下げることができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、サーバ統合は様々な望ましくない影響をもたらす可能性もある。ハードウェアリソースの利用率が増大することにより、ハードウェアの故障率が上がる可能性がある。これらの故障は、次いでそのハードウェアを利用するアプリケーションに影響を及ぼす恐れがある。さらに、現在のアーキテクチャでは、ブレードやラックマウントサーバなどの現場交換可能ユニット（ｆｉｅｌｄ  ｒｅｐｌａｃｅａｂｌｅ  ｕｎｉｔ：ＦＲＵ）のハードウェア部品が故障すると、多くの場合そのユニットを交換または修理しなければならず、サーバのハードウェア部品の大半は稼働し続ける可能性があるにも関わらず、そのユニットに関連するリソースを、アプリケーションの実行に利用できるリソースプールから取り除くことになる。
【課題を解決するための手段】
【０００５】
各種例示的実施形態の簡単な概要を下記に提示する。以下の概要では多少の簡略化と省略を行うことがあるが、この概要は各種の例示的実施形態のいくつかの態様を取り上げて紹介するものであり、本発明の範囲を限定するものではない。当業者が本発明の概念を実施し、使用することを可能にするのに十分な好ましい例示的実施形態の詳細な説明はその後の項で述べる。
【０００６】
各種の例示的実施形態は、ハードウェアシステムの漸次的な機能停止を可能にするためにハードウェア管理装置によって行われる方法に関し、ハードウェアシステムは複数のハードウェア部品を含み、方法は、複数のハードウェア部品のうち故障した部品のハードウェア故障を特定するステップと、故障した部品を利用するように現在設定されているエージェント装置のセットを判定するステップと、エージェント装置のセットのうち少なくとも１つのエージェント装置について、故障した部品に代えて、複数のハードウェア部品のうち機能している部品を利用するようにそのエージェント装置を再設定するステップと、故障した部品を非アクティブ状態にするステップであって、複数のハードウェア部品の他のハードウェア部品は稼働状態を保つ、非アクティブ状態にするステップと、の１つまたは複数を含む。
【０００７】
各種の例示的実施形態は、漸次的なハードウェアの機能停止が可能なハードウェアシステムに関し、ハードウェアシステムは、回路基板と、回路基板に搭載された複数のハードウェア部品と、実行時に、複数のハードウェア部品の少なくとも１つの残りの部品が稼働状態を保ったままで、複数のハードウェア部品のうち少なくとも１つのハードウェア部品を非アクティブ状態にする管理装置とを備える。
【０００８】
各種の例示的実施形態は、ハードウェアシステムの漸次的な故障を可能にするためにハードウェア管理装置によって実行される命令が符号化された有形で持続性の機械可読記憶媒体に関し、ハードウェアシステムは複数のハードウェア部品を含み、有形で持続性の機械可読記憶媒体は、複数のハードウェア部品のうち故障した部品のハードウェア故障を特定するための命令と、故障した部品を利用するように現在設定されているエージェント装置のセットを判定するための命令と、エージェント装置のセットのうち少なくとも１つのエージェント装置について、故障部品に代えて、複数のハードウェア部品のうち機能している部品を利用するようにそのエージェント装置を再設定するための命令と、故障部品を非アクティブ状態にするための命令であって、複数のハードウェア部品の他のハードウェア部品は稼働状態を保つ、非アクティブ状態にするための命令と、の１つまたは複数を含む。
【０００９】
各種の例示的実施形態は、それに加えて、複数のハードウェア部品のうち少なくとも１つの他の部品に電力を供給し続けながら、故障部品の電源を切るようにハードウェアモジュールを再設定するステップを含む。
【００１０】
記載される各種の例示的実施形態では、ハードウェアシステムは、複数のハードウェア部品が搭載された回路基板を含むハードウェアモジュールである。
【００１１】
記載される各種の例示的実施形態では、回路基板に搭載されたすべてのハードウェア部品は単一種類のハードウェア部品である。
【００１２】
記載される各種の例示的実施形態では、ハードウェア管理装置がハイパーバイザを含み、ハードウェア管理装置は、複数のハードウェア部品のうち少なくとも１つの部品を利用して動作する。
【００１３】
記載される各種の例示的実施形態では、ハードウェア管理装置がクラウドコンピューティングゲートウェイ装置を含み、クラウド管理装置が複数のハイパーバイザを管理し、複数のハイパーバイザのうち第１のハイパーバイザが複数のハードウェア部品を管理する。
【００１４】
各種の例示的実施形態は、それに加えて、エージェント装置のセットの少なくとも１つのエージェント装置について、複数のハイパーバイザのうち第２のハイパーバイザで管理されるようにそのエージェント装置を再設定するステップを含む。
【００１５】
各種の例示的実施形態は、ハードウェアモジュールの消費を制御するためにハードウェア管理装置によって行われる方法に関し、ハードウェアモジュールは複数のハードウェア部品を含み、方法は、ハードウェアモジュールの故障日を予想するステップと、予想故障日が許容できるかどうかをハードウェアモジュールの目標交換日に基づいて判定するステップと、予想故障日が許容できない場合、複数のハードウェア部品のうち少なくとも１つのハードウェア部品に対する少なくとも１つのパラメータ調整を決定するステップであって、少なくとも１つのパラメータ調整は、予想故障日を目標交換日に近づけるように選択される、決定するステップと、少なくとも１つのパラメータ調整を、複数のハードウェア部品の当該少なくとも１つのハードウェア部品に適用するステップと、の１つまたは複数を含む。
【００１６】
各種の例示的実施形態は、ハードウェアモジュールの消費を制御するハードウェア管理装置に関し、ハードウェアモジュールは複数のハードウェア部品を含み、ハードウェア管理装置は、ハードウェアモジュールの故障日を予想して予想故障日が許容できるかどうかをハードウェアモジュールの目標交換日に基づいて判定するように構成された消費ポリシーエンジンと、予想故障日が許容できない場合、複数のハードウェア部品のうち少なくとも１つのハードウェア部品に対する少なくとも１つのパラメータ調整を決定し、少なくとも１つのパラメータ調整は、予想故障日を目標交換日に近づけるように選択され、少なくとも１つのパラメータ調整を、複数のハードウェア部品の当該少なくとも１つのハードウェア部品に適用するように構成されたパラメータアジャスタと、の１つまたは複数を含む。
【００１７】
各種の例示的実施形態は、ハードウェアモジュールの消費を制御するためにハードウェア管理装置によって実行される命令が符号化された有形で持続性の機械可読記憶媒体に関し、ハードウェアモジュールは複数のハードウェア部品を含み、有形で持続性の機械可読記憶媒体は、ハードウェアモジュールの故障日を予想するための命令と、予想故障日が許容できるかどうかをハードウェアモジュールの目標交換日に基づいて判定するための命令と、予想故障日が許容できない場合、複数のハードウェア部品のうち少なくとも１つのハードウェア部品に対する少なくとも１つのパラメータ調整を決定するための命令であって、少なくとも１つのパラメータ調整は、予想故障日を目標交換日に近づけるように選択される、決定する命令と、少なくとも１つのパラメータ調整を、複数のハードウェア部品の当該少なくとも１つのハードウェア部品に適用するための命令と、の１つまたは複数を含む。
【００１８】
記載される各種の例示的実施形態では、少なくとも１つのパラメータ調整が、ハードウェアモジュールを予想故障日よりも前に故障させるように選択される。
【００１９】
各種の例示的実施形態は、それに加えて、複数のハードウェア部品各々の故障率に基づいて、モジュールの現在の寿命段階を推定するステップを含み、ハードウェアモジュールの故障日を予想するステップは、モジュールの現在の寿命段階に基づいて行われる。
【００２０】
記載される各種の例示的実施形態では、ハードウェア管理装置が複数のハードウェアモジュールを管理し、各ハードウェアモジュールが現在の寿命段階に関連付けられ、エージェント装置の確立を求める要求を受け取るステップと、要求に関連付けられた寿命段階の許可を判定するステップであって、寿命段階の許可は、許された寿命段階を持つモジュールが要求を満たすために使用されることを指示する、判定するステップと、複数のハードウェアモジュールからハードウェアモジュールを選択するステップであって、選択されるハードウェアモジュールは許された寿命段階に対応する、選択するステップと、選択されたハードウェアモジュールを使用して要求を満たすステップと、の１つまたは複数をさらに含む。
【００２１】
記載される各種の例示的実施形態では、ハードウェアモジュールの故障日を予想するステップは、故障条件が満たされる日を予想するステップを含み、故障条件は、稼働状態にあるハードウェア部品が、設定された数より少ない時に満たされる。
【００２２】
各種の例示的実施形態は、それに加えて、複数のハードウェア部品のうち少なくとも１つの故障率を判定するステップを含み、ハードウェアモジュールの故障日を予想するステップは、複数のハードウェア部品のうち少なくとも１つの故障率に基づいて行われる。
【００２３】
記載される各種の例示的実施形態では、少なくとも１つのパラメータ調整は、冷却率、電圧、クロック周波数、およびアクティブ化のスケジュール、の少なくとも１つの調整を含む。
【００２４】
各種の例示的実施形態をよりよく理解するために、添付図面を参照する。
【図面の簡単な説明】
【００２５】
【図１ａ】共有ハードウェアリソースを提供する例示的システムを示す図である。
【図１ｂ】図１ａの一部の構成要素の代替構成を示す図である。
【図１ｃ】図１ａの一部の構成要素の別の代替構成を示す図である。
【図２−１】消耗ハードウェアリソースを提供する例示的ハードウェアシステムを示す図である。
【図２−２】消耗ハードウェアリソースを提供する例示的ハードウェアシステムを示す図である。
【図３】故障したハードウェア部品に対処する例示的方法の図である。
【図４】時間の経過に伴うハードウェアモジュールの故障率の例示的グラフを示す図である。
【図５】ハードウェアの状態情報を記憶する例示的なデータ配列を示す図である。
【図６】ハードウェアリソースの消費を制御する例示的方法を示す図である。
【図７】ハードウェアパラメータを調整する例示的方法を示す図である。
【発明を実施するための形態】
【００２６】
理解を助けるために、実質的に同じもしくは同様の構造および／または実質的に同じもしくは同様の機能を持つ要素は、同じ参照符号を使用して識別している。
【００２７】
前述から、故障したハードウェアリソースが利用可能な全リソースに及ぼす影響を制限するハードウェアアーキテクチャを提供することが望ましい。詳細には、そのようなアーキテクチャは、故障した部品を非アクティブ状態にし、すべての他の部品は完全に稼働可能な状態を保つことが望ましい。次いで図面を参照すると、各種例示的実施形態の広い態様が開示される。
【００２８】
図１ａは、共有ハードウェアリソースを提供する例示的システム１００ａを示す。そのようなハードウェアリソースは、例えばクライアントユーザにサービスを提供する何らかのネットワーク化されたアプリケーションを支援するために共有されることが考えられる。例示的なシステムは、いくつかのクライアント装置１１０ａ−ｃ、ネットワーク１２０、クラウドコンピューティングゲートウェイ１３０、リソース割振り装置１４０ａ−ｂ、およびいくつかのエージェント装置１５０ａ−ｄを含むことができる。リソース割振り装置１４０ａ−ｂおよびエージェント装置１５０ａ−ｄは、１つまたは複数のクラウドコンピューティングインフラストラクチャに存在することができる。
【００２９】
クライアント装置１１０ａ−ｃは各々、ネットワーク１２０等のネットワークと通信することが可能な任意の装置を含むことができる。ここでは３つの装置を示すが、例示的システム１００ａは、それよりも少ない、または多い装置を含むことが可能である。さらに、例示的システム１００ａに参加するクライアント装置の数は運用中に変わる可能性がある。例えば、クライアント装置１１０ａが例示的システム１００ａへの参加をやめる、および／または新たに２つのクライアント装置（図示せず）が同様の参加を開始する等の可能性がある。
【００３０】
各クライアント装置１１０ａ−ｃは、パーソナルコンピュータもしくはラップトップコンピュータ、端末、サーバ、タブレット、ワイヤレス電子メール機器、携帯電話、スマートフォン、テレビのセットトップボックス、またはネットワーク１２０を介して他の装置と通信可能な任意の他の装置とすることができる。各クライアント装置１１０ａ−ｃは種々の理由で例示的システム１００ａに参加する可能性がある。例えば、クライアント装置１１０ａはシンクライアントであり、例示的システム１００ａ内の他のリソースに依存して、クライアント装置１１０ａの通常動作に関連する大半またはすべての処理を行う。別の例として、クライアント装置１１０ｂは、大半の作業は独力で行うことが可能なパーソナルコンピュータであり、例えば大きな音楽や電子書籍の集まりなどのデータを記憶して取り出すために例示的システム１００ａ内の他のリソースに依存する。さらに別の例として、クライアント装置１１０ｃは、他の装置（図示せず）から要求を受け取り、応答するサーバである。クライアント装置１１０ｃは、要求の到着率が非常に高く、何らかの効率性の尺度、応答時間、またはサーバ負荷を測る他の尺度の範囲内でクライアント装置１１０ｃが要求を処理できない時に、例示的システム１００ａ内の他のリソースに依存して要求の一部を処理することができる。
【００３１】
ネットワーク１２０は、例示的システム１００ａの他の装置間の通信を提供するようになされた装置または装置のグループとすることができる。したがって、ネットワーク１２０は、適切な宛先にパケットを転送するためのいくつかのルータおよび／またはスイッチを含むことができる。各種実施形態で、ネットワーク１２０は、１つまたは複数の２Ｇ、３Ｇ、および／もしくは４Ｇシステム、ならびに／または他のワイヤレスシステムを含むことができる。さらに、各種実施形態で、ネットワーク１２０は、インターネットおよび／もしくは１つまたは複数のローカルエリアネットワーク（ＬＡＮ）等の有線ネットワークを含むことができる。
【００３２】
クラウドコンピューティングゲートウェイ１３０は、ハードウェアリソースを管理するようになされた装置または装置のグループとすることができる。そのため、クラウドコンピューティングゲートウェイは、エージェント装置１５０ａ−ｄ等のエージェント装置の確立を実施し、クライアント装置１１０ａ−ｃおよびエージェント装置１５０ａ−ｄ間でメッセージを伝送し、ハードウェア利用についてユーザに課金し、ハードウェアリソースの状態を監視し、および／またはハードウェアリソースの消費を制御することができる。クラウドコンピューティングゲートウェイの詳細な動作は、下記で図２に関連して詳細に説明する。
【００３３】
下記でより詳細に説明するが、クラウドコンピューティングゲートウェイ１３０に管理されるハードウェアリソースは、いくつかのハードウェアモジュールを含むことができる。各ハードウェアモジュールは、いくつかのハードウェア部品を含む回路基板とすることができる。そして、ハードウェア部品は、クラウドコンピューティングゲートウェイ１３０で管理されるハードウェアリソースを提供する。例えば、あるハードウェアモジュールは、３２個のプロセッサが搭載された回路基板とすることができる。クラウドコンピューティングゲートウェイ１３０は、その３２個のプロセッサの処理能力の使用と消費を少なくとも部分的に管理するように動作することができる。ハードウェアモジュールのさらなる例は、後に図２を参照して説明する。例示的なシステム１００ａは、図示するように２つのハードウェアモジュール１６０ａ、１７０ａを含むことができる。図には２つのハードウェアモジュール１６０ａ、１７０ａを示すが、例示的システム１００ａはそれよりも少ない、または多いハードウェアモジュール（図示せず）を含むことが可能であることに留意されたい。
【００３４】
リソース割振り装置１４０ａ−ｂは各々、ハードウェアモジュール１６０ａ、１７０ａ等のハードウェアモジュールのハードウェアリソースを利用する装置とすることができる。リソース割振り装置１４０ａ−ｂは、エージェント装置１５０ａ−ｄを管理することもできる。例えば、リソース割振り装置１４０ａがエージェント装置１５０ａ−ｂを管理し、リソース割振り装置１４０ｂがエージェント装置１５０ｃ−ｄを管理することができる。エージェント装置１５０ａ−ｄを管理する際、リソース割振り装置１４０ａ−ｂは、各エージェント装置１４０ａ−ｄに関してハードウェアモジュール１６０ａ、１７０ａの共有ハードウェアリソースを割り当てる、および／または実施することができる。例えば、リソース割振り装置１４０ａは、エージェント装置１  １５０ａは第１のＣＰＵの処理時間の２０％を使用することができ、エージェント装置Ｍ  １５０ｂは同じＣＰＵの処理時間の１０％を使用できることを保証することができる。したがって、各種実施形態で、リソース割振り装置１４０ａ−ｂは各々ハイパーバイザを含むことができる。リソース割振り装置１４０ａ−ｂは、例えば要求および応答メッセージのルーティング、リソースの確保、負荷平衡、使用量の計測、および／または課金等の多数の追加的な機能を行うことができる。例示的システム１００ａは２つのリソース割振り装置１４０ａ−ｂを含むが、各種実施形態は、それよりも少ない、または多くのリソース割振り装置（図示せず）を含むことが可能であることに留意されたい。
【００３５】
エージェント装置１５０ａ−ｄは、各々、クライアント装置１１０ａ−ｃの１つまたは複数と連携して動作するように構成された装置とすることができる。各エージェント装置１５０ａ−ｄは、１つまたは複数のプロセッサ、メモリ、記憶域、および／またはネットワークインターフェース等のハードウェアリソースを含むことができる。各種実施形態で、エージェント装置１５０ａ−ｄは、そのようなハードウェアリソースを他のエージェント装置１５０ａ−ｄおよび／またはリソース割振り装置１４０ａ−ｂと共有することができる。例えば、エージェント装置１  １５０ａは、ＣＰＵをリソース割振り装置１４０ａおよびエージェント装置Ｍ  １５０ｂと共有することができる。そのようなハードウェアリソースは、ハードウェアモジュール１６０ａ、１７０ａ等の１つまたは複数の物理ハードウェアモジュールに分散配置することができる。各種実施形態で、エージェント装置１５０ａ−ｄの１つまたは複数は仮想マシンを含むことができる。
【００３６】
一部の実施形態によると、リソース割振り装置１４０ａ−ｂは、それらが管理するエージェント装置１５０ａ−ｄと同じ物理ハードウェアモジュールに共に存在することができる。例えば、リソース割振り装置１４０ａおよびエージェント装置１５０ａ−ｂが１つの物理ハードウェアモジュール１６０ａに共に存在することができる。そのような実施形態では、リソース割振り装置１４０ａがハイパーバイザを含み、一方エージェント装置１５０ａ−ｂは各々仮想装置を含むことができ、それらはすべて同じハードウェアモジュールの各種ハードウェア部品を使用して実行することができる。同様に、リソース割振り装置１４０ｂとエージェント装置１５０ｃ−ｄは共に別の物理ハードウェアモジュール１７０ａに存在することができる。ただし、本明細書に記載される方法は、各種の代替構成に適用可能であることが明らかであろう。例えば、図１ｂに示す代替構成１００ｂは、リソース割振り装置１４０ａが第１のハードウェアモジュール１６０ｂにあり、エージェント装置１５０ａ−ｂがすべて第２のハードウェアモジュール１６２ｂにあることを示している。別の代替例として、図１ｃに示す代替構成１００ｃは、リソース割振り装置１４０ａおよびエージェント装置１５０ａ−ｂがそれぞれ別個のハードウェアモジュール１６０ｃ、１６２ｃ、１６４ｃにあることが可能であることを示している。さらに、各リソース割振り装置１４０ａおよびエージェント装置１５０ａ−ｂは、複数のハードウェアモジュールから提供されるリソースを利用することができる。各種の他の構成が当業者には明らかとなろう。
【００３７】
図１ａに戻ると、クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａ−ｂは、ハードウェアモジュールのハードウェア部品の故障に対処するように構成することができる。例えば、ハードウェアモジュール１６０ａのＣＰＵが故障したか、または他の理由で使用不可能と見なされる場合、クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａは、そのＣＰＵのソフトウェアまたはハードウェアの構成を変更するか、他の方法でＣＰＵを利用可能リソースプールから除外することにより、故障したＣＰＵを非アクティブ状態にすることができる。クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａは、その後、ハードウェアモジュール１６０ａを再設定して故障したＣＰＵの電源を切ることにより、稼働費も低減させることができる。クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａはさらに、それまで故障したＣＰＵを使用していたエージェント装置１５０ａ−ｂを再設定して、モジュール１６０ａの別のＣＰＵか、またはモジュール１７０ａ等の別のモジュールのＣＰＵを代わりに利用させることができる。このようにして、ハードウェアモジュール１６０ａ、１７０ａは、各自の構成要素が機能しなくなっても動作可能な状態を保つことができる。モジュールは、漸次機能しなくなっていくため、能力は低下するものの機能し続けることができる。モジュールの能力が、稼働を継続することに費用効果がある点を下回ると、そのハードウェアモジュールは破棄し、交換することができる。上記のように、本アーキテクチャは、ハードウェアリソースの消費に対応する。
【００３８】
クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａ−ｂはさらに、ハードウェアモジュール１６０ａ、１７０ａの消費を管理するように適合することができる。詳細には、クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａ−ｂは、ハードウェアモジュール１６０ａ、１７０ａ、またはそれらの構成要素の各種動作パラメータを調整して、ハードウェアモジュール１６０ａ、１７０ａが、目標交換日またはそのわずかに後に耐用寿命に達することを保証する。例えば、ハードウェアモジュール１６０ａが目標交換日よりも前に費用効果がなくなると予測される場合は、クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ａはハードウェアモジュールの寿命を延ばすように動作パラメータを調整し、例えば動作電圧やクロックレートを下げて、部品のストレスを軽減し、それにより有効耐用期間を延ばすことができる。逆に、ハードウェアモジュール１７０ａが目標交換日の後もしばらく費用効果があると予測される場合には、クラウドコンピューティングゲートウェイ１３０および／またはリソース割振り装置１４０ｂは、ハードウェアモジュールの寿命を短縮するように動作パラメータを調整し、例えば、作業負荷を増大させることにより交換時までにハードウェアモジュールが最大限に使用されることを保証するか、または冷却率を下げることにより稼働費を下げることができる。
【００３９】
システム管理者は、上記の機能を使用してすべてのハードウェアモジュールの定期的な交換の計画を立てることができる。例えば、システム管理者は、耐用寿命が３年になるように各ハードウェアモジュールを設定して、毎月全ハードウェアモジュールの１／３６が交換されるようにずらすことができる。本明細書に記載の方法を用いるシステムでは、システム管理者は、予定された日にハードウェアモジュールが交換される時点で最大限に利用されており、動作を継続することに全く費用効果がなくなっていることを確信することができる。
【００４０】
図２は、消耗ハードウェアリソースを提供する例示的ハードウェアシステム２００を示す。例示的ハードウェアシステム２００は例示的システム１００ａの一部分に相当することができる。例示的なハードウェアシステム２００は、ネットワーク２２０、クラウドコンピューティングゲートウェイ２３０、およびハードウェアモジュール２６０、２７０、２８０を含むことができる。
【００４１】
ネットワーク２２０は、例示的システム１００ａの他の装置間に通信を提供するようになされた装置または装置のグループとすることができる。したがって、ネットワーク１２０は、適切な宛先にパケットを転送するためのいくつかのルータおよび／またはスイッチを含むことができる。各種実施形態で、ネットワーク１２０は、１つまたは複数の２Ｇ、３Ｇ、および／もしくは４Ｇシステム、ならびに／または他のワイヤレスシステムを含むことができる。さらに、各種実施形態で、ネットワーク１２０は、インターネットおよび／もしくは１つまたは複数のローカルエリアネットワーク（ＬＡＮ）等の有線ネットワークを含むことができる。各種実施形態で、ネットワーク２２０は、例示的システム１００ａのネットワーク１２０に対応することができる。
【００４２】
クラウドコンピューティングゲートウェイ２３０は、ハードウェアリソースを管理するようになされた装置または装置グループとすることができる。したがって、クラウドコンピューティングゲートウェイ２３０は、例示的システム１００ａのクラウドコンピューティングゲートウェイ１３０に相当することができる。クラウドコンピューティングゲートウェイ２３０は、要求ハンドラ２３２、エージェント装置割当てストレージ２３４、モジュールインターフェース２３６、診断エンジン２３８、モジュール状態ストレージ２４０、故障ハンドラ２４２、消費ポリシーエンジン２４４、消費規則ストレージ２４６、パラメータアジャスタ２４８、管理者インターフェース２５０、課金プロセッサ２５２、およびサービスプランストレージ２５４を含むことができる。クラウドコンピューティングゲートウェイ２３０の種々の構成要素は、上記に代えて、または上記に加えて、１つまたは複数のハードウェアモジュール２６０、２７０、２８０に存在する１つまたは複数のリソース割振り装置（図示せず）に配置してもよいことに留意されたい。
【００４３】
要求ハンドラ２３２は、エージェント装置に対する要求を受け取って処理するように構成されたハードウェアおよび／または機械可読の記憶媒体に記憶された実行可能命令を含むことができる。例えば、要求ハンドラ２３２は、新しいエージェント装置の確立を求める要求を、ネットワーク２２０を介してクライアント装置（図示せず）から受け取ることができる。その後、要求ハンドラは、新しいエージェント装置をホストするのに適当なモジュール２６０、２７０、２８０を決定し、次いでモジュールインターフェース２３６を介してモジュール２６０、２７０、２８０に存在するリソース割振り装置（図示せず）と通信して、新しいエージェント装置の確立を実施することができる。適当なモジュール２６０、２７０、２８０の選択は、少なくとも部分的に、モジュール状態ストレージ２４０に記憶されているモジュール２６０、２７０、２８０の現在の状態、サービスプランストレージ２５４に記憶されている要求元ユーザのサービスプラン、および／または新しいエージェント装置で実行しようとするアプリケーションの信頼性の要件に基づくことができる。新しいエージェント装置を確立する際、要求ハンドラ２３２は、要求元のクライアント装置と、エージェント装置と、そのエージェント装置に割り当てられる（１つまたは複数の）ハードウェアモジュールとの間の対応関係を反映するようにエージェント装置割当て記憶の内容を更新することもできる。
【００４４】
要求ハンドラ２３２は、クライアント装置（図示せず）とアクティブ状態のエージェント装置（図示せず）の間のメッセージの伝送等の追加的機能を行うことができる。そのような機能を実施するために、要求ハンドラ２３２は、エージェント装置割当てストレージ２３４に記憶されたデータを参照して、どのリソース割振り装置および／またはハードウェアモジュールがどのクライアント装置に関連付けられているかを判定することができる。要求ハンドラ２３２は、各クライアント装置（図示せず）のユーザが適切に課金されるように、エージェント装置の確立および使用状況に関するデータを課金プロセッサに転送することもできる。
【００４５】
エージェント装置割当てストレージ２３４は、エージェント装置を記述する情報を記憶することが可能な任意の機械可読媒体であってよい。したがって、エージェント装置割当てストレージ２３４は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置、および／または同様の記憶媒体等の機械可読の記憶媒体を含むことができる。各種実施形態で、エージェント装置割当てストレージ２３４は、各エージェント装置とそれに関連付けられたリソース割振り装置および／または（１つまたは複数の）ハードウェアモジュール間の対応関係を記憶することができる。
【００４６】
モジュールインターフェース２３６は、１つまたは複数のハードウェアモジュール２６０、２７０、２８０との通信を可能にするように構成されたハードウェアおよび／または機械可読の記憶媒体に符号化された実行可能命令を含むインターフェースとすることができる。各種実施形態で、モジュールインターフェース２３６は、Ｅｔｈｅｒｎｅｔ（登録商標）、ＰＣＩ、ＳＣＳＩ、ＡＴＡ、および／または他のハードウェアインターフェース技術を含むことができる。各種実施形態で、モジュールインターフェース２３６は、ブレードサーバのバックプレーンを含むことができる。
【００４７】
診断エンジン２３８は、ハードウェアモジュール２６０、２７０、２８０およびそのハードウェア部品２６２、２７２、２７４、２８６に各種診断の実行を実施して、それらハードウェア装置の現在の動作状態および／または故障率を計測するように構成されたハードウェアおよび／または機械可読の記憶媒体に記憶された実行可能命令を含むことができる。各種実施形態で、診断エンジン２３８は、各ハードウェア部品２６２、２７２、２７４、２８６の検査を周期的に開始して、ハードウェア部品２６２、２７２、２７４、２８６の現在および／またはこれまでの故障率を判定することができる。例えば、診断エンジンは、該当ハードウェアモジュール２６０、２７０、２８０に存在するリソース割振り装置と通信して、リソースプールから当該部品を除外するか、および／または１つまたは複数の診断検査を行うために新しいエージェント装置を確立することができる。そして、診断エンジン２３８は、モジュールインターフェース２３６を介して検査結果を受け取り、その後、検査したハードウェア部品の現在の状態を反映するようにモジュール状態ストレージ２４０を更新することができる。検査でハードウェア部品が故障しているか他の理由により使用不能であることが示された場合、下記でさらに詳細に説明するように、診断エンジンは、故障ハンドラ２４２に命令を送って状況に合わせた適切な措置を取らせることができる。
【００４８】
診断エンジン２３８はさらに、個々のハードウェア部品２６２、２７２、２７４、２８６の診断結果と、当技術分野で知られている各種の「耐用寿命」技術を利用して、ハードウェアモジュール２６０、２７０、２８０の全体的な現在の寿命段階を計測することができる。下記で図４との関連でさらに詳細に説明するように、ハードウェア部品は、耐用寿命の様々な段階で異なる故障率を示すことが予想される。この現象はしばしば、よく知られる「バスタブ曲線」モデルに従う。診断エンジン２３８は、段階的なサービスプランと故障予想の目的で、各モジュール２６０、２７０、２８０の現在の寿命段階を判定するように適合することができる。
【００４９】
モジュール状態ストレージ２４０は、ハードウェアモジュールおよびハードウェア部品に関連する状態情報を記憶することが可能な任意の機械可読の媒体である。したがって、モジュール状態ストレージ２４０は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置、および／または同様の記憶媒体等の機械可読の記憶媒体を含むことができる。モジュール状態ストレージ２４０の例示的な内容は下記で図５に関連して詳細に説明する。各種実施形態で、モジュール状態ストレージ２４０は、エージェント装置割当てストレージ２３４と同一の装置とすることができる。
【００５０】
故障ハンドラ２４２は、機能しなくなりつつある、または他の理由で使用不可能となりつつある各種ハードウェア部品２６２、２７２、２７４、２８６に対応するように構成されたハードウェアおよび／または機械可読の記憶媒体に記憶された実行可能命令を含むことができる。故障ハンドラ２４２は、診断エンジン２３８から、および／または対応するハードウェアモジュール２６０、２７０、２８０で動作するリソース割振り装置（図示せず）から直接、そのような故障の通知を受け取ることができる。あるハードウェア部品が新たに使用不可能になった旨の通知があると、故障ハンドラ２４２は、エージェント装置割当てストレージ２３４を参照して、どのエージェント装置がそのハードウェア部品を利用していた可能性があるかを判定することができる。故障ハンドラ２３４は、対応するハードウェアモジュールの低下した能力で、そのモジュールが現在割り当てられているすべてのエージェント装置に充分に対応し続けられるかどうかも判定することができる。その情報に基づいて、故障ハンドラ２４２は、１つまたは複数のエージェント装置を他のハードウェアモジュールに再分配することができる。例えば、モジュールＡのプロセッサ２６２が使用不可能になると、故障ハンドラ２４２は、モジュール２６０、２７０のリソース割振り装置と通信して、モジュールＢ  ２７０への１つまたは複数のエージェント装置の移動を実施して、モジュールＡ  ２６０を利用しているエージェント装置の動作が、モジュールＡの能力が低下したことによって悪化しないことを保証することができる。故障ハンドラ２４２は、再分配後のエージェント装置を反映するようにエージェント装置割当てストレージ２３４の内容を更新することもできる。
【００５１】
消費ポリシーエンジン２４４は、モジュールの予想残り寿命に応じて取るべき措置を決定するように構成されたハードウェアおよび／または機械可読の記憶媒体に記憶された実行可能命令を含むことができる。各種実施形態で、消費ポリシーエンジン２４４は、モジュール状態ストレージ２４０に記憶された状態情報を使用して、当技術分野で知られている各種技術を使用して、各ハードウェアモジュール２６０、２７０、２８０の推定故障日を予想することができる。各種実施形態で、各モジュールが完全に機能しなくなる日を予想する代わりに、消費規則ストレージは、１つまたは複数のモジュール２６０、２７０、２８０の故障条件を記憶してもよい。この故障条件は、そのモジュールを稼働させ続けることに費用効果がなくなるモジュール状態を指定することができる。例えば、モジュールＡ  ２６０は少なくとも８つのプロセッサが機能している間のみ稼働を続けることに費用効果があると管理者が判断することができる。それに応じて、消費ポリシーエンジンは、モジュールＡ  ２６０の機能しているプロセッサが８個未満になると予想される日を予想することができる。
【００５２】
そして、消費ポリシーエンジン２４４は、予想される故障日をそのモジュールの目標交換日と比較することができる。そのような目標交換日は消費規則ストレージ２４６に記憶することができる。予想故障日が目標交換日に充分に近くない場合、消費ポリシーエンジン２４４は、モジュールの消費率を変更できるようにその旨をパラメータアジャスタに知らせることができる。各種実施形態で、消費ポリシーエンジン２４４は、予想故障日が目標交換日と一致することを要求し、他の実施形態では、何日間または何カ月間かの許容誤差を見越すことができる。そのような他の実施形態では、その許容誤差は目標交換日の前ではなく後に見越しておくことができる。
【００５３】
消費規則ストレージ２４６は、各ハードウェアモジュールを交換すべき時および交換が見込まれる時に関する状態情報を記憶することが可能な任意の機械可読媒体とすることができる。したがって、消費規則ストレージ２４６は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置、および／または同様の記憶媒体等の機械可読の記憶媒体を含むことができる。各種実施形態で、消費規則ストレージ２４６は、各モジュールの故障条件および目標交換日を記憶することができる。各種実施形態で、消費規則ストレージ２４６は、エージェント装置割当てストレージ２３４および／またはモジュール状態ストレージ２４０と同一の装置とすることができる。
【００５４】
パラメータアジャスタ２４８は、ハードウェア部品の各種動作パラメータを調整して、ハードウェアモジュールの耐用寿命を短縮または延長するように構成されたハードウェアおよび／または機械可読の記憶媒体に記憶された実行可能命令を含むことができる。消費ポリシーエンジンから報告されるモジュールの目標交換日およびモジュールの予想故障日に基づいて、パラメータアジャスタは、１つまたは複数の予測モデルを利用して、モジュールの予想故障日を目標交換日に近づかせるように作用する１つまたは複数のパラメータ調整を決定することができる。そのような予測モデルは、例えば、ハードウェア部品２６２、２７２、２７４、２８６および／またはハードウェアモジュール２６０、２７０、２８０のハードウェア製造者から提供されることができる。例えば、パラメータアジャスタ２６０は、モジュールＡ  ２６０が１０月に交換予定であるが予想寿命が１１月中まで至る旨の通知を受け取った場合、パラメータアジャスタ２４８は、モジュールＡの耐用寿命を１カ月短くすべきであると判断してもよい。パラメータアジャスタ２４８は、製造者から提供される予測モデルを使用して、プロセッサ２６２を２００ＭＨｚだけオーバークロックさせるとモジュールＡ  ２６０の耐用寿命が約１カ月短くなると判断することができる。適切なパラメータ調整を決定すると、パラメータアジャスタ２４８はさらに、モジュールインターフェース２３６を介してハードウェアモジュール２６０、２７０、２８０と通信して、そのパラメータ調整をハードウェアに実施するように適合することができる。
【００５５】
管理者インターフェース２５０は、管理者がクラウドコンピューティングゲートウェイ２３０と対話することができるように、表示装置、キーボード、および／またはマウス等の各種装置を含むことができる。各種実施形態で、診断エンジン２３８、消費ポリシーエンジン２４４、または他の構成要素が、モジュール２６０、２７０、２８０が故障し、目標交換日よりも前に交換しなければならない可能性があると判断すると、管理者インターフェースは管理者にその故障を通知することができる。さらに、管理者インターフェース２５０は、管理者が消費規則ストレージ２４６の内容を変更できるようにしてよい。例えば、管理者は管理者インターフェース２５０を使用して各種モジュール２６０、２７０、２８０の故障条件と目標交換日を設定することができる。例えば、管理者は、最新の業務上の決定を考慮して、モジュールＡの故障条件を、動作状態にあるプロセッサが６個未満であることから、動作状態にあるプロセッサが８個未満であることに変更することができる。管理者インターフェース２５０のこの他の様々な使用法が当業者には明らかになろう。
【００５６】
課金プロセッサ２５２は、例示的なハードウェアシステムのユーザに課金するように構成されたハードウェアおよび／または機械可読の記憶媒体に記憶された実行可能命令を含むことができる。課金プロセッサ２５２は、要求ハンドラ２３２から活動の通知を受け取り、その後ユーザのサービスプランに基づいて該当するユーザのアカウントに課金することができる。各種の計量および課金方法が当業者には明らかになろう。
【００５７】
サービスプランストレージ２５４は、例示的ハードウェアシステム２００の各ユーザに関連付けられたサービスプランに関する情報を記憶することが可能な任意の機械可読媒体とすることができる。したがって、サービスプランストレージ２５４は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置、および／または同様の記憶媒体等の機械可読の記憶媒体を含むことができる。各種実施形態で、サービスプランストレージ２５４は、ユーザの識別データ、課金情報、サービス階層、および様々なユーザについて特権や課金の詳細を定義する際に有用な他の情報を記憶することができる。各種実施形態で、サービスプランストレージ２５４は、エージェント装置割当てストレージ２３４、モジュール状態ストレージ２４０、および／または消費規則ストレージ２４６と同じ装置とすることができる。
【００５８】
ハードウェアモジュール２６０、２７０、２８０は各々、例示的ハードウェアシステム２００で使用されるハードウェアリソースを提供するハードウェアモジュールとすることができる。ハードウェアモジュール２６０、２７０、２８０は、ハードウェアモジュールの３つの可能な異なる構成を例示している。当業者は、３つの可能性を例示するが、各種の代替の構成も存在しうることを理解されよう。さらに、図には３つのハードウェアモジュール２６０、２７０、２８０を示すが、ハードウェアシステム２００はそれよりも少ない、または多いハードウェアモジュールを含むことも可能である。
【００５９】
ハードウェアモジュールＡ  ２６０は同種型のハードウェアモジュールであってよい。すなわち、モジュールＡ  ２６０は、単一種類のハードウェア部品を含むことができる。図の例では、モジュールＡ  ２６０は１８個のプロセッサ２６２を含み、その他のハードウェア部品は含まない。本明細書で使用する場合、用語「ハードウェア部品」は、リソース割振り装置またはエージェント装置の一部として使用されるハードウェアリソース、または外部のクライアント装置による使用のためにその他の形で提供されるハードウェアリソースを提供する構成要素を指すことに留意されたい。したがって、モジュールＡ  ２６０は、例えばプロセッサ２６２を支援する電源や通信インターフェース等の追加的なハードウェアを含むことが可能であるが、そのようなハードウェアはハードウェア部品に相当しない。
【００６０】
プロセッサ２６２の１つまたは複数は、少なくとも一部が、リソース割振り装置（図示せず）に属することができる。先に説明したように、リソース割振り装置は、プロセッサ２６２の１つまたは複数を少なくとも部分的に含むいくつかのエージェント装置（図示せず）の管理を担うことができる。上記のように、モジュールＡ  ２６０  は同種型のモジュールとすることができる。そのため、プロセッサ２６２を利用するエージェント装置は、他のハードウェアモジュール（図示せず）に位置する他のハードウェア部品もさらに利用することができる。例えば、プロセッサ２６２の１つを利用するエージェント装置が、別のモジュール（図示せず）に搭載された主メモリ（図示せず）の一部分も利用することができる。
【００６１】
モジュールＢ  ２７０は、分離型の異種混成ハードウェアモジュールを例示する。図に示すように、モジュールＢ  ２７０は、１２個のプロセッサ２７２と３つのメモリバンク２７４を備える。モジュールＡ  ２６０と同様に、モジュールＢ  ２７０は、１つのリソース割振り装置と複数のエージェント装置をサポートすることができる。ただし、モジュールＢ  ２７０の場合は、各リソース割振り装置およびエージェント装置は、同じ物理モジュールから複数種類のハードウェアリソースを選ぶことができる。任意のプロセッサ２７２が任意のメモリバンク２７４を利用することができ、すなわち２つのリソースが切り離されている。ただし、効率的で効果的な使用を保証するために、リソース割振り装置は、１つまたは複数のプロセッサ２７２および１つまたは複数のメモリバンク２７４の特定の割当て分を各エージェント装置に割り当てる責任を負うことができる。
【００６２】
モジュールＣ  ２８０は、結合型の異種混成ハードウェアモジュールを例示する。図のように、モジュールＣ  ２８０は１８個の「演算コア」２８６を含む。各演算コア２８６は、共に１つの単位として働くように設計された複数のハードウェア装置を含むことができる。例えば、各演算コア２８６は、プロセッサおよびメモリバンク（図示せず）を含むことができる。そのため、各演算コアはハードウェア要素と呼ぶことができる。この場合も、１つのリソース割振り装置といくつかのエージェント装置が演算コア２８６を共有することができる。ただし、様々な種類のハードウェアリソースが密結合されているため、リソース割振り装置は、エージェント装置への多くの異なる種類のリソースの割当てを管理する必要はなく、代わりに、リソース割振り装置は単に、各エージェント装置に１つまたは複数のコンピュータコア２８６の割当て分を割り当てればよい。
【００６３】
図３に関して下記でさらに詳細に説明するが、各モジュール２６０、２７０、２８０は、残りのハードウェア部品が動作を続けている状態で任意の１つのハードウェア部品を非アクティブ状態にできるように設計することができる。そのため、各モジュール２６０、２７０、２８０は、搭載された各ハードウェア部品への制御信号で遮断されることが可能な電源供給回路を含むことができる。そのような制御信号は、リソース割振り装置、クラウドコンピューティングゲートウェイ、および／または、特定のハードウェア部品が故障したか、その他の理由でもはや使用可能でないと判断するとそのハードウェアモジュールの動作状態を管理するようになされた別個の装置（図示せず）によってアサートすることができる。
【００６４】
図３は、故障したハードウェア部品に対処する例示的方法３００を示す。説明のために、方法３００はリソース割振り装置によって行われるものと仮定する。ただし、例示的方法３００は、それに加えて、またはそれに代えて、クラウドコンピューティングゲートウェイ２００等のクラウドコンピューティングゲートウェイの構成要素で行うことも可能であることが理解されよう。
【００６５】
例示的方法３００はステップ３０５で開始し、ステップ３１０に進んで、リソース割振り装置がハードウェア部品の故障を特定する。詳細には、リソース割振り装置は、ハードウェア部品が故障した、または近い将来故障する可能性が高いことを判定することができる。各種実施形態で、リソース割振り装置は、その他の理由でハードウェア部品を使用不可能と見なすことができる。方法３００は次いでステップ３１５に進み、リソース割振り装置が、使用不可能になったハードウェア部品の割当てを現在含んでいるエージェント装置を判定する。次いで、ステップ３２０で、リソース割振り装置は、代わりに他のハードウェア部品を使用するようにそれらのエージェント装置を割り当て直すことができる。このステップの実施後、故障部品は、装置へのハードウェアリソースの提供にそれ以上使用されない場合もある。この時点で、方法３００は任意で終了し、リソース割振り装置は単に故障部品をその後使用することを回避してもよい。
【００６６】
各種実施形態で、方法３００はステップ３２５に進み、リソース割振り装置が、故障したハードウェア部品の電源を切るようにハードウェアモジュールを再設定することができる。これには、電力消費を下げ、その結果、全体としてモジュールの動作を継続させることに伴う費用を下げる効果がある。次いでステップ３３０で、リソース割振り装置が、故障をクラウドコンピューティングゲートウェイに報告することができる。その報告を使用して、クラウドコンピューティングゲートウェイは、リソース割振り装置よりも高いレベルで複数のリソース割振り装置にエージェント装置を再分配することができる。方法３００がクラウドコンピューティングゲートウェイ自体で行われる実施形態では、ステップ３３０はなくてもよいことが明らかであろう。方法３００は次いでステップ３３５で終了することができる。
【００６７】
図４は、時間の経過に伴うハードウェアモジュールの故障率の例示的グラフ４００を示す。線４１０は、ハードウェアのハードウェア故障率は一般に時間と共に「バスタブ曲線」モデルをたどることを示している。ハードウェア装置の寿命の最初の頃は、ハードウェア故障は、いわゆる「幼児死亡率」のために比較的高い場合がある。すなわち、一部のハードウェア装置は、潜在的な欠陥のために稼働開始直後に故障する。その段階を故障せずに過ぎると、ハードウェアはその耐用寿命の大部分を異常なしに送る。そして、ハードウェアが老朽化するにつれて、「摩耗」のためにハードウェア故障の頻度が増して行き、最終的にハードウェアは完全に使用不可能となる。
【００６８】
本明細書に記載されるシステムの各種態様によると、ハードウェア部品の耐用寿命は、ハードウェアの割当ておよび課金の目的で各種の段階に分類することができる。図のように、グラフ４００は５つの寿命段階に分けられている。すなわち、新品段階４２１、最安定段階４２２、経年変化段階４２３、摩耗段階４２４、および終末期段階４２５である。各種の代替の段階設定が可能であることが明らかであろう。
【００６９】
ハードウェアモジュールの現在の状態を評価する一環として、クラウドコンピューティングゲートウェイおよび／またはリソース割振り装置は、ハードウェアモジュールの現在の寿命段階を判定するように適合することができる。この情報は、当技術分野で知られる各種の耐用寿命技術、ならびにモジュールの構成要素の故障率の履歴を使用して求めることができる。その後、その情報を使用して、モジュールの寿命段階に基づいて、ハードウェアモジュールに新しいエージェント装置を割り当てることができる。例えば、上客のユーザは、ハードウェア故障が発生しにくい最安定段階４２２で現在動作しているハードウェアを使用するためにより高い代価を支払う可能性がある。別の例として、用途が異なると、故障の許容度が異なる場合がある。そのため、リスクへの耐性が高い用途には、新品段階４２１または摩耗段階４２４で動作しているハードウェアを割り当てることができる。さらに、クラウドコンピューティングゲートウェイおよび／またはリソース割振り装置は、終末期段階４２５にあるモジュールは完全に回避してもよい。
【００７０】
図５は、ハードウェアの状態情報を記憶するための例示的なデータ配列５００を示す。例示的データ配列５００は、例示的ハードウェアシステム２３０のモジュール状態ストレージ２４０の内容例を示す。データ配列は、例えばモジュールフィールド５１０、寿命段階フィールド５２０、部品フィールド５３０、および故障率フィールド５４０等のいくつかのフィールドを含むことができる。
【００７１】
モジュールフィールド５１０は、特定のモジュールレコードが該当するモジュールを特定することができる。寿命段階フィールド５２０は、モジュールの最新の推定寿命段階を示すことができる。部品フィールド５３０は、モジュールに搭載されているハードウェア部品を特定することができる。故障率フィールド５４０は、部品に観測された最新の故障率を示すことができる。データ配列５００はモジュールレコードに入れ子になった部品レコードを示しているが、これは抽象化である場合があることに気付かれよう。当業者は、データ配列５００は実際にはいくつかの異なる方式で記憶することが可能であることを認識されよう。例えば、データ配列５００は、実際には、それぞれが別々にハードウェアモジュールおよびハードウェア部品に専用とされた複数のテーブルに記憶することができる。
【００７２】
一例として、モジュールレコード５６０は、モジュールＡが現在は３番目の寿命段階、すなわち経年変化段階４２３にあると推定されることを示す。モジュールレコード５６０は、いくつかの部品下位レコード５６２、５６４、５６６を含むことができる。部品下位レコード５６２は、ＣＰＵ１の故障率が５％であることが観測されていることを示してもよく、部品下位レコード５６４は、ＣＰＵ２の故障率が５０％であることが観測されていることを示してもよい。モジュールレコード５６０は、多数の追加的な部品下位レコード５６６を含むことができる。例示的なモジュールレコード５７０、５８０および例示的な部品下位レコード５７２、５７３、５７４、５７６、５７８、５８２、５８４、５８６も同様の情報を示し、その意味は前述の説明から明らかになろう。
【００７３】
図６は、ハードウェアリソースの消費を制御する例示的方法６００を示す。説明のために、方法６００は、クラウドコンピューティングゲートウェイ２００等のクラウドコンピューティングゲートウェイの構成要素によって行われるものと仮定する。ただし、例示的方法３００は、それに加えて、またはそれに代えて、リソース割振り装置で行うことも可能であることは理解されよう。
【００７４】
方法６００はステップ６０５で開始し、ステップ６１０に進み、クラウドコンピューティングゲートウェイがハードウェア部品に対する診断検査の実行を実施することができる。例えば、クラウドコンピューティングゲートウェイは、リソースプールから対象部品を除外するか、および／または部品に対して新しいエージェント装置を開始して、１つまたは複数の検査を行うことができる。診断検査の結果を受け取ると、クラウドコンピューティングゲートウェイはステップ６１５で、検査で部品がもはや使用可能でないと示されるかどうかを判定することができる。各種実施形態で、クラウドコンピューティングゲートウェイは、部品の稼働を継続することにもはや費用効果がなく、および／または充分に低い故障リスクで許容品質のサービスを提供することが可能でない時に、部品が「もはや使用可能でなく」、したがって「故障した」と判断することができる。そのように、部品は技術的に動作可能であり続ける可能性もあるが、クラウドコンピューティングゲートウェイは、各種の追加的な要因に基づいて故障部品と見なすことができる。
【００７５】
部品が故障した場合、クラウドコンピューティングゲートウェイは、ステップ６２０で１つまたは複数のエージェント装置を別のハードウェアモジュールに移し替えて、故障部品があるモジュールの負荷を軽減することができる。部品がまだ故障していない場合、またはクラウドコンピューティングゲートウェイがエージェント装置を移し替えると、方法６００はステップ６２５に進み、クラウドコンピューティングゲートウェイは、検査した部品に関連付けられた故障率情報を更新することができる。
【００７６】
ステップ６３０で、クラウドコンピューティングゲートウェイは、さらに他の部品を検査するかどうかを判定することができる。例えば、クラウドコンピューティングゲートウェイは、１つのモジュールの全部品を同時に検査する、またはいくつかの部品を特定の時に検査するように予定することができる。検査すべき部品がさらにある場合、方法６００はループしてステップ６１０に戻ることができる。検査すべきすべての部品が検査されると、方法６００はステップ６３０からステップ６３５に進むことができる。
【００７７】
ステップ６３５で、クラウドコンピューティングゲートウェイは、ハードウェアモジュールの現在の寿命段階を推定することができる。このステップは、当業者に知られる各種の「耐用寿命」技術に従って行うことができ、ハードウェアモジュールの構成要素の故障率に基づくことができる。説明のために、方法６００では、図４に関して説明した方式で寿命段階を定義するものと仮定する。各種の代替の寿命段階方式を用いてもよいことが明らかであろう。モジュールの寿命段階を推定すると、クラウドコンピューティングゲートウェイは、モジュールレコードおよび方法６００を更新することができる。
【００７８】
次いでステップ６４０で、クラウドコンピューティングゲートウェイは、対象モジュールが現在寿命段階５で動作していると推定されるかどうかを判定することができる。すなわち、クラウドコンピューティングゲートウェイは、モジュールが「終末期」段階にあるかどうかを判定することができる。「終末期」段階にある場合、ステップ６４５で、クラウドコンピューティングゲートウェイは、モジュールがもはや使用可能でなく、交換すべきことを管理者に通知することができる。一方、モジュールが別の寿命段階にある場合は、方法８００はステップ６５０に進む。各種の代替実施形態で、クラウドコンピューティングゲートウェイは、例えば「摩耗段階」等の別の寿命段階でモジュールを交換すべきことを管理者に通知するようになされてもよいことに留意されたい。さらに、各種実施形態で、ステップ６４５の交換の通知を行わせる寿命段階は、システム規模またはモジュール単位で管理者が設定できるようにしてもよい。ステップ６４０の各種の他の変更が当業者には明らかになろう。
【００７９】
ステップ６５０で、クラウドコンピューティングゲートウェイは、モジュールの故障日を予想することができる。このステップは、当業者に知られる各種の方法に基づいて行うことができる。例えば、クラウドコンピューティングゲートウェイは、ハードウェア製造者から提供される予測モデルを利用して、いつハードウェアモジュールが指定の故障条件を満たすかを推定することができる。この判定は、例えばモジュールの寿命段階やその構成要素の故障率等の各種状態情報に基づくことができる。
【００８０】
次いでステップ６５５で、クラウドコンピューティングゲートウェイは、予想される故障日が目標交換日に充分に近いかどうかを判定することができる。各種実施形態で、方法６００は２つの日が一致することを要求し、他の実施形態では方法６００は２つの日に所定の不一致を許すことができる。２つの日が充分に近い場合、モジュールは予定通り交換日までに消費されると見なされ、その後方法６００はステップ６５５で終了することができる。
【００８１】
一方、２つの日が充分に近くない場合、ステップ６６０でクラウドコンピューティングゲートウェイがハードウェアの各種動作パラメータを調整することができる。パラメータを調整することにより、クラウドコンピューティングゲートウェイはハードウェアモジュールの故障を早めるか、または遅らせて、ハードウェアモジュールが目標交換日に十分近い時に故障すると予想できるようにする。この機能を実現する例示的処理については、下記で図７に関して詳細に説明する。ハードウェアモジュールを再設定すると、方法６００はステップ６６５で終了することができる。
【００８２】
図７は、ハードウェアパラメータを調整する例示的方法７００を説明する図である。説明のために、方法７００は、クラウドコンピューティングゲートウェイ２００等のクラウドコンピューティングゲートウェイの構成要素によって行われるものと仮定する。ただし、例示的方法７００は、それに加えて、またはそれに代えて、リソース割振り装置で行われることも可能であることは理解されよう。方法７００は、方法６００のステップ６６０に対応する。
【００８３】
方法７００はステップ７０５で開始し、ステップ７１０に進み、クラウドコンピューティングゲートウェイが調整するパラメータを決定することができる。例えば、クラウドコンピューティングゲートウェイは、クロック周波数、冷却率、および／または適用電圧を調整することを決定することができる。それに代えて、またはそれに加えて、クラウドコンピューティングゲートウェイは、ハードウェアモジュールが稼働状態である時間のうち対象部品がアクティブである時間の割合を短く、または長くするようにアクティブ化のスケジュールを調整してもよい。この判定は、予め決められたパラメータの優先度、状況データに基づいて適切なパラメータを決定する規則のセットを適用するルールエンジン、または当業者に知られる別の方法に基づいて行うことができる。
【００８４】
次にステップ７１５で、クラウドコンピューティングゲートウェイは、選択したパラメータをどのように調整するかを決定することができる。例えば、クラウドコンピューティングゲートウェイは、選択したパラメータに関連付けられた予測モデルを利用して、パラメータをどのように変更すればモジュールが目標交換日を満たすかを判断することができる。例えば、予測モデルは、モジュールのＣＰＵを２００ＭＨｚだけオーバークロックさせる、冷却を１０％低下する、または各ＣＰＵがアクティブ状態にある時間の割合を１０％増大すると、モジュールが目標交換日により近い時に故障することを示す。次いで、ステップ７２５で、クラウドコンピューティングゲートウェイは、パラメータ値が許容できるかどうかを判定することができる。パラメータ値は、例えば実現不可能である場合や非現実的である場合に許容不可能となる。例えば、モジュールは、一定レベルを超えると電圧を安全に上げることができない可能性がある。別の例として、現在のＣＰＵの負荷がすでに低い場合は、ＣＰＵのオーバークロックは実際的でない可能性がある。パラメータ値が許容できない場合、方法はステップ７３０に進む。
【００８５】
ステップ７３０で、クラウドコンピューティングゲートウェイは代替の調整を決定することができる。例えば、クラウドコンピューティングゲートウェイは、現在の値とステップ７１５で求められた値の間のパラメータ値を選択することができる。あるいは、クラウドコンピューティングゲートウェイは、パラメータを一切調整すべきでないと判断してもよい。次いでステップ７３５で、パラメータを代替値に調整する場合は、クラウドコンピューティングゲートウェイがそのパラメータ調整を実施することができる。ただし、代替の調整が使用されたため、モジュールが目標交換日を満たすようにまだ設定されていない可能性がある。そのため、方法７００はループしてステップ７１０に戻り、異なるパラメータでこの処理を繰り返すことができる。そのように、クラウドコンピューティングゲートウェイは複数のパラメータを調整して、モジュールが目標交換日に近い時に消耗されることを保証することができる。
【００８６】
ステップ７２５で、クラウドコンピューティングゲートウェイが、モジュールに目標交換日を満たさせるのに十分で許容可能なパラメータ調整を特定すると、方法７００はステップ７４０に進む。ステップ７４０で、クラウドコンピューティングゲートウェイはパラメータ調整を実施し、その後方法７００はステップ７４５で終了することができる。
【００８７】
前述により、各種実施形態は、故障したハードウェアリソースが、利用可能な全リソースに及ぼす影響を制限するハードウェアアーキテクチャを可能にする。詳細には、故障したハードウェア部品を選択的に非アクティブ状態にする、または使用を中止することができるハードウェアモジュールを提供することにより、１つの単位としてのハードウェアモジュールが動作を継続することができる。さらに、そのようなハードウェアモジュールの状態を監視し、そのハードウェア部品の動作パラメータを調整することにより、ハードウェアシステムは、ハードウェアモジュールが目標交換日の近くまでに完全に消費されることを保証することができる。
【００８８】
前述の説明から、本発明の各種の例示的実施形態は、ハードウェア、ソフトウェア、および／またはファームウェアとして実施できることが明らかであろう。さらに、各種の例示的実施形態は、機械可読の記憶媒体に記憶された命令として実施し、それを少なくとも１つのプロセッサで読み取って実行することにより、本明細書に詳細に記載される動作を行うことができる。機械可読の記憶媒体は、パーソナルコンピュータもしくはラップトップコンピュータ、サーバ、または他のコンピューティング装置等の機械により読み取ることが可能な形態で情報を記憶する任意の機構を含むことができる。したがって、有形で持続性の機械可読記憶媒体は、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、磁気ディスク記憶媒体、光学記憶媒体、フラッシュメモリ装置、および同様の記憶媒体を含むことができる。
【００８９】
当業者には、本明細書中のブロック図は、本発明の原理を実施する例示的な回路の概念図を表すことが理解されよう。同様に、フローチャート、流れ図、状態遷移図、疑似コード等は、実際には機械可読媒体に表され、したがってコンピュータやプロセッサによって実行することが可能な各種処理を表し、そのようなコンピュータやプロセッサは明示的に図示される場合もされない場合もあることが理解されよう。
【００９０】
各種の例示的実施形態について、特定の例示的態様を参照して詳細に説明したが、本発明は他の実施形態も可能であり、その詳細は様々な自明な点で変更可能であることを理解されたい。当業者には容易に明らかになるように、本発明の主旨および範囲内で変形および変更を実施することができる。したがって、前述の開示、説明、および図は説明を目的とするものにすぎず、特許請求の範囲のみで定義される本発明を何ら限定するものではない。
【図１ａ】
2014531690.tif 000003
【図１ｂ】
2014531690.tif 000004
【図１ｃ】
2014531690.tif 000005
【図２−１】
2014531690.tif 000006
【図２−２】
2014531690.tif 000007
【図３】
2014531690.tif 000008
【図４】
2014531690.tif 000009
【図５】
2014531690.tif 000010
【図６】
2014531690.tif 000011
【図７】
2014531690.tif 000012
【国際調査報告】
2014531690.tif 000013
2014531690.tif 000014
2014531690.tif 000015