(57)【要約】  動的な信頼性およびセキュリティ能力を提供する。動的な信頼性およびセキュリティ能力は、時間の関数と顧客のアプリケーションまたはサービスの要件の関数との両方として顧客の信頼性パラメータを指定する動的信頼性プロファイル（ＤＲＰ）の使用をサポートするように構成され得る。信頼性パラメータは、顧客の信頼性要件および／または信頼性目標を指定することができ、これによって、時間変動する要件／目標プロファイルを提供する。動的な信頼性およびセキュリティ能力は、ＤＲＰによって指定される要求される信頼性を提供するようにクラウドリソースを動的に構成するように構成され得る。ＲＳＧ能力は、サービス保証を提供するための自己回復能力の使用を含むことができる、指定された信頼性が実際に提供されつつあることを保証するためにその後に挙動を監視し、計測するように構成され得る。
2014532246.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサおよびメモリであって、プロセッサが、
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取り、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定する
ように構成される、プロセッサおよびメモリ
を含む、装置。
【請求項２】
プロセッサが、
顧客アプリケーション情報とクラウドプロバイダのクラウドシステムに関連するクラウドシステム情報とを使用して顧客の仮想アプリケーショントポロジを決定することと、
顧客の仮想アプリケーショントポロジとクラウドシステムに関連するクラウドシステム情報とを使用して信頼性マップを決定することと、
信頼性マップとクラウドシステムに関連するクラウドシステム情報とを使用してクラウドリソースの構成を決定することと
によって、ＤＲＰに基づいて顧客のクラウドリソースの構成を決定するように構成される、請求項１に記載の装置。
【請求項３】
プロセッサが、複数の時間期間のそれぞれでの顧客のクラウドリソースの構成を決定するように構成される、請求項１に記載の装置。
【請求項４】
プロセッサが、
ＤＲＰ内で指定される信頼性パラメータが満足されつつあるかどうかを決定するためにクラウドリソースの挙動を監視し、
ＤＲＰ内で指定される信頼性パラメータを満足するためのクラウドリソースの挙動を計測する
ようにさらに構成される、請求項１に記載の装置。
【請求項５】
プロセッサが、
仮想構成を生成するために顧客に関連するＤＲＰを処理し、
仮想構成をクラウドリソースにマッピングするように構成されたスケジューリングエンジンに仮想構成を提供する
ように構成された構成エンジンを提供するように構成される、請求項１に記載の装置。
【請求項６】
プロセッサが、
顧客に関連するＤＲＰを満足する仮想構成を受け取り、
仮想構成をクラウドリソースにマッピングする
ように構成されたスケジューリングエンジンを提供するように構成される、請求項１に記載の装置。
【請求項７】
プロセッサが、
クラウドプロバイダのクラウドシステムに関連するシステム状況情報とクラウドシステムのクラウドプロバイダによって指定されるポリシ情報および制約情報のうちの少なくとも１つとを使用して、信頼性完全性メーターとクラウドシステムのクラウドリソースを制御する際の使用のために構成された制御情報とのうちの少なくとも１つを生成する
ように構成された監視エンジンを提供するように構成される、請求項１に記載の装置。
【請求項８】
プロセッサが、
クラウドリソースを制御する際の使用のために構成された制御情報を受け取り、
制御情報を使用して、クラウドリソースの少なくとも一部を変更するように構成された少なくとも１つのフィードバックアクションを生成する
ように構成された制御エンジンを提供するように構成される、請求項１に記載の装置。
【請求項９】
コンピュータによって実行される時に、コンピュータに、
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取ることと、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することと、
を含む方法を実行させる命令を記憶する、コンピュータ可読記憶媒体。
【請求項１０】
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取り、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定する
のにプロセッサを使用すること
を含む、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全般的には通信環境に関し、限定はしないがより具体的には、通信環境での信頼性およびセキュリティの提供に関する。
【背景技術】
【０００２】
クラウドコンピューティングは、サービスおよびリソースの顧客を基礎になるインフラストラクチャの管理から分離すると同時に、すばやいセルフサービスプロビジョニングを使用して、インターネットを介して顧客にサービスおよびリソースを提供する形を提供する。しかし、クラウドコンピューティングのさまざまな利点およびクラウドコンピューティングの最近の成長にもかかわらず、多数の顧客は、それでも、とりわけクラウドコンピューティングの信頼性およびセキュリティなど、ある種の懸念事項と苦闘している。
【発明の概要】
【課題を解決するための手段】
【０００３】
従来技術のさまざまな欠陥は、クラウド環境内で信頼性およびセキュリティを提供する実施形態によって対処される。
【０００４】
一実施形態では、装置は、クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取り、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定するように構成されるプロセッサを含む。
【０００５】
一実施形態では、コンピュータ可読記憶媒体は、コンピュータによって実行される時に、コンピュータに、クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取ることと、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することと、を含む方法を実行させる命令を記憶する。
【０００６】
一実施形態では、方法は、クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取ることと、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することとを含む。
【０００７】
本明細書の教示は、添付図面に関連して次の発明を実施するための形態を考慮することによってたやすく理解され得る。
【図面の簡単な説明】
【０００８】
【図１】信頼性およびセキュリティガーディアン（Ｒｅｌｉａｂｉｌｉｔｙ  ａｎｄ  Ｓｅｃｕｒｉｔｙ  Ｇｕａｒｄｉａｎ、ＲＳＧ）を含むクラウドシステムの一実施形態を示す図である。
【図２】図１のＲＳＧによって使用される例示的な動的信頼性プロファイル（ＤＲＰ）を示す図である。
【図３】図１のクラウドシステムの３人の顧客の時間の関数としての例示的なアプリケーションミックス（ａｐｐｌｉｃａｔｉｏｎ  ｍｉｘ）を示す図である。
【図４】顧客アプリケーション情報を図１のクラウドシステムの物理リソースにマッピングするプロセスの一実施形態を示す図である。
【図５】物理インフラストラクチャへのアプリケーショントポロジの例示的なマッピングを示す図である。
【図６】イベント相関を実行し、反応／予測制御情報を決定する、図１のＲＳＧの例示的な使用を示す図である。
【図７】図１のＲＧＳを実現する際の使用に適する自己信頼コンピュートストアユニット（Ｃｏｍｐｕｔｅ  Ｓｔｏｒｅ  Ｕｎｉｔ、ＣＳＵ）の一実施形態を示す図である。
【図８】分散自己信頼クラウドシステムを形成するための顧客ドメイン内の図７の複数のＣＳＵの例示的デプロイを示す図である。
【図９】図１のクラウドシステムの部分内でデプロイされた図１のＲＳＧを実現する際の使用に適するシステム制御ユニット（ＳＣＵ）の一実施形態を示す図である。
【図１０】クラウドシステムの顧客に信頼性を提供する方法の一実施形態を示す図である。
【図１１】本明細書で説明される機能を実行する際の使用に適するコンピュータを示す高水準ブロック図である。
【発明を実施するための形態】
【０００９】
理解を容易にするために、可能な場合には、複数の図面に共通する同一の要素を指定するのに、同一の符号が使用されている。
【００１０】
一般に、信頼性およびセキュリティ能力が、本明細書で図示され、説明されるが、さまざまな他の能力も、本明細書で提示される可能性がある。
【００１１】
クラウドコンピューティングは、サービスおよびリソースの顧客を基礎になるインフラストラクチャの管理から分離すると同時に、すばやいセルフサービスプロビジョニングを使用して、インターネットを介して顧客にサービスおよびリソースを提供する形を提供する。多くの場合に、クラウドプロバイダによって提供されるサービスは、通常はクラウドシステムのソフトウェアの抽象化のレベルおよびクラウドシステムのリソースの管理のレベルに基づいて区別されるユーティリティコンピューティングである。たとえば、このスペクトルの一端には、抽象化が物理ハードウェアレベルである実施態様があり、顧客は、カーネルから上のソフトウェアスタック全体を制御することができる（これは、フェイルオーバ能力の提供をむずかしくするが）。たとえば、このスペクトルの他端には、ステートレス計算およびステートフルストレージシステムを有する、ウェブアプリケーションに固有のアプリケーションドメインである実施態様がある。他の実施態様も、このスペクトルの中間部分に含まれる可能性があることに留意されたい。
【００１２】
クラウドコンピューティングは、多数の関連する利点を有する。一般に、クラウドコンピューティングは、高いスケーラビリティ、構成可能性、動的ベースでのリソース可用性の弾力性、復帰が簡単、および類似する利点を可能にする。クラウドコンピューティングは、負荷の急増に従うのに十分にすばやくオンデマンドで使用可能であり、これによって事前のプロビジョニングの必要をなくす「無限の」コンピューティングリソースの外見をハードウェアプロビジョニングが作成する広範囲の能力を提供する。クラウドコンピューティングは、そのサイジングの容易さを考慮すると、クラウドサービスのオンデマンドまたは従量制課金（ｐａｙ−ａｓ−ｙｏｕ  ｇｏ）の性質のゆえに、より安価なフェイルオーバソリューションの実施を可能にする。クラウドコンピューティングでは、顧客は、必要に応じて短期ベースでコンピューティングリソースの使用（たとえば、プロセッサ１時間あたりの、ストレージ１日あたりの、など）について支払い、必要に応じてコンピューティングリソースを要求したり、解放したりすることができる。また、クラウドコンピューティングは、規模の経済（たとえば、電気、ネットワーク帯域幅、動作、ソフトウェアおよびハードウェア、などの改善の要因）を可能にし、リソース利用を高めるための統計的多重化を可能にし、動作を単純化する。クラウドコンピューティングのさまざまな他の利点も、了解されるであろう。
【００１３】
しかし、前述の利点およびクラウドコンピューティングの成長にもかかわらず、多くの顧客は、まだ、その信頼性およびセキュリティに関する疑問を解決するために苦闘している。たとえば、物理リソースの共有は、セキュリティ問題（たとえば、他者に可視のデータ、障害または終了の後に残されるデータインプリント（ｄａｔａ  ｉｍｐｒｉｎｔ）、など）を提起する。さらに、セキュリティ／データプライバシおよび司法権の問題、サービスレベルアグリーメント（Ｓｅｒｖｉｃｅ  Ｌｅｖｅｌ  Ａｇｒｅｅｍｅｎｔ、ＳＬＡ）の未成熟／変動、性能およびアクセス制御／待ち時間、信頼性およびベンダ中立性、クラウドサービスをビジネスアプリケーションに統合する能力、クラウドサービスモデルの相対的な未成熟および継続する進化、など、クラウドサービスの広まった採用に対する障壁は、無視することができない。さらに、ミッションクリティカルなアプリケーションをデプロイする企業は、通常、ＳＬＡを介する穏当なシステム応答性の保証、マルチテナント環境でのデータ分離を介する保護、サービス停止を最小にするためのフェイルオーバ保護、予測可能なリチャージレート（ｒｅｃｈａｒｇｅ  ｒａｔｅ）、ならびにさまざまな関連するサービスおよび能力を求めることに留意されたい。さらに、ミッションクリティカルなアプリケーションの保証は、定量化可能ではなく、公衆クラウド（たとえば、便宜を提供する）対私有クラウド（たとえば、セキュリティおよびプライバシのよりよい制御および保証を提供する）のコスト／便益を強調するための尺度は、明瞭ではない。したがって、クラウドシステムのソフトウェアの抽象化のレベルおよびクラウドシステムの管理のレベルは、クラウド提供の間の主要な差別化要因になる可能性を有する。
【００１４】
一実施形態では、前述の懸念事項および／または必要性の少なくとも一部に、新しいシステムアーキテクチャ、新しいデバイス／要素、新しいプログラミングモデル、新しい開発環境、および新しいテスティング方法論のうちの１つまたは複数の使用を介して対処することができ、そのようなアーキテクチャ、デバイス／要素、モデル、環境、および／または方法論は、性能、可用性、セキュリティ、弾力性、使用量アカウンティング、などに関する顧客のＳＬＡ要件のより深い理解に基づいて自己信頼システムを提供するように構成され得る。これが、公衆クラウドコンピューティングと私有クラウドコンピューティングとの両方が、より信頼できセキュアになり、したがって、ミッションクリティカルな使用に適するものになることを可能にするはずであることに留意されたい。
【００１５】
一実施形態では、前述の懸念事項および／または必要性の少なくとも一部に、クラウドシステム内の信頼性およびセキュリティガーディアン（ＲＳＧ）の使用を介して対処することができる。
【００１６】
ＲＳＧ能力は、動的信頼性プロファイル（ＤＲＰ）の使用をサポートするように構成され得、ＤＲＰは、顧客ＳＬＡの一部として含まれ得、顧客ＳＬＡは、時間の関数と顧客のアプリケーションまたはサービスの要件の関数との両方として顧客の信頼性パラメータを指定する。信頼性パラメータは、顧客の信頼性要件および／または目標を指定し、これによって時間変動する要件／目標プロファイルを提供することができる。ＲＳＧ能力は、ＤＲＰによって指定される要求される信頼性を提供するためにクラウドリソースを動的に構成するように構成され得る。ＲＳＧ能力は、サービス保証を提供するための自己回復能力の使用を含むことができる、指定された信頼性が実際に提供されつつあることを保証するために挙動をその後に監視し、計測するように構成され得る。信頼性は、可用性に関連するので、動的信頼性プロファイルが、本明細書で動的信頼性／可用性プロファイルと呼ばれる場合もあることに留意されたい。
【００１７】
ＲＳＧ能力は、不断の経験として顧客に提供されるサービスの信頼性の向上、ユーザから視えることの影響または手作業の介入なしに機能的可用性レベルまでシステムが自動的にリバランスすることの可能化、これによって公衆クラウドコンピューティングおよび／または私有クラウドコンピューティングがより信頼でき、セキュアであり、弾力的であることを可能にし、したがってミッションクリティカル使用に適するものにする、性能、信頼性、可用性、セキュリティ、弾力性使用量アカウンティング、などに関するサービスレベルアグリーメント（ＳＬＡ）要件の動的保証の提供、時間とアプリケーションもしくはサービスの要件との両方の関数としての顧客の信頼性要件／目標の表現、要求される／望まれる信頼性を提供するためにクラウドリソースを動的に構成するように構成された自己信頼システムの提供、要求される／望まれる信頼性が満足されつつあることを保証するためのシステムの監視および計測、使用可能なネットワークおよびサービスデータのセキュアな収集および集中化を伴う近リアルタイムでのソリューション全体にわたるエンドツーエンドサービス可用性の監視、使用可能なネットワークおよびサービスデータからクリティカルなエンドツーエンドサービス可用性メトリックを導出し、適当な回復アクションおよび制御アクションをトリガする信頼性完全性メーターの生成、クリティカルな問題を絶えず検出し、トラブルシューティングするための切迫した問題の表示の生成および先を見越したインサービステスティングを可能にする予防制御能力を提供し、などのうちの１つまたは複数を実行しまたは提供するように構成され得る。
【００１８】
ＲＳＧ能力は、さまざまな他の関連する機能を提供するように構成され得る。言い替えると、顧客は、あたかも電話で信頼性を申し込むことができ、クラウドシステムは、それを提供することを試みて反応するかのようである。
【００１９】
一実施形態では、ＲＳＧ能力は、インフラストラクチャ層内でデプロイされる。クラウドコンピューティングの全般的傾向が、産業に連繋し動的で自己学習する自己管理ソリューションに向かっていることに留意されたい。一実施形態では、ソリューションレベルの能力が、有機的、自己認識的、自己回復的ネットワークの構築を可能にし、これによって、顧客が必要とする時にその必要に応じてクラウドプロバイダが保証を提供することを可能にする。さらに、そのような有機的、自己認識的、自己回復的ネットワークが、高価値アプリケーションを含むさまざまな顧客アプリケーションをサポートできることに留意されたい。一実施形態では、そのようなアプリケーション（高価値アプリケーションを含む）をサポートするために、（１）信頼性が、プラットフォーム層内のサービスとして提供され（ＲａａＳすなわちＲｅｌｉａｂｉｌｉｔｙ  ａｓ  ａ  Ｓｅｒｖｉｃｅと表される）、（２）ＲＳＧ能力と称する能力が、インフラストラクチャ層内で提供され、ＲＳＧ能力は、動的構成、高可用性のためのリソーススケジューリング、完全性計測、インサービス頑健性テスティング、障害の予測および防止、障害の間際条件およびセキュリティ違反条件を認識し、診断するためのネットワークイベントの相関、など、ならびにそのさまざまな組合せなどの機能を提供するように構成される。このように、動的に自己信頼的なクラウドシステムが提供され得る。
【００２０】
一実施形態では、ＲＧＳ能力は、顧客ネットワーク内でデプロイされる。これは、既存のクラウドシステムに関連するセキュリティ障壁を克服する。すなわち、既存のクラウドシステムでは、セキュリティを厳密に考慮するので、クラウドサービスプロバイダは、顧客がプロバイダの内部管理システムまたは性能データおよび故障データにアクセスすることを、めったに許可しない。たとえば、希な場合に、アラームおよび性能データへの顧客による「読取専用」アクセスが、オフライン分析のために許可される場合がある。対照的に、ＲａａＳがサポートされる場合には、ＲＳＧ能力と顧客ネットワーク内のさまざまな他のエンティティ（たとえば、データ収集エンティティ、管理エンティティ、など）との間のインターフェースが、信頼されるインターフェースとして実現され得るように、ＲＳＧ能力が、顧客ネットワーク内に常駐することができる。すべてのデータが、顧客ドメイン内でローカルにアクセスされ、分析されるので、非武装化.（ＤＭＺ）機能（たとえば、セキュア仮想私有ネットワーク（ＶＰＮ）を介してルーティングされた暗号化されたデータ）の必要はない。さらに、外部エンティティが用いられないので、監視されたデータに基づく先を見越した制御が、今や可能である。したがって、顧客ネットワーク内にＲＳＧ能力を組み込むことによる既存のセキュリティハードルの克服により、真に有機的、自己認識的、自己回復的ネットワークの構築が可能になる。
【００２１】
クラウドシステムは、図示され本明細書で説明される信頼性およびセキュリティガーディアン（ＲＳＧ）を介するなど、１つまたは複数の能力を介してそのような機能をサポートすることができる。例示的なクラウドシステム内の例示的なＲＳＧを、図１に関して図示し、説明する。
【００２２】
図１は、信頼性およびセキュリティガーディアン（ＲＳＧ）能力を含むクラウドシステムの一実施形態を示す。
【００２３】
図１に示されているように、クラウドシステム１００は、顧客１０２にクラウドサービスを提供するクラウドプロバイダによって管理される物理インフラストラクチャ１０１を含む。クラウドシステム１００は、物理インフラストラクチャ１０１を使用する顧客１０２へのクラウドサービスの提供の文脈でクラウドプロバイダが顧客１０２にサービス保障を提供することを可能にするように構成された信頼性／セキュリティガーディアン（ＲＳＧ）１２０をも含む。
【００２４】
物理インフラストラクチャ１０１は、クラウドリソース１１０を含み、オプションで、クラウドサービスをサポートするためにクラウドプロバイダによってデプロイされ得る任意の他の物理インフラストラクチャを含むことができる。
【００２５】
顧客１０２は、クラウドリソース１１０にアクセスし、これを使用することができる任意の適切なタイプの顧客とすることができる。たとえば、顧客１０２は、企業顧客、家庭顧客、などとすることができる。
【００２６】
顧客１０２は、顧客１０２のＳＬＡ  １０３を生成するのに使用され得る情報を提供することができる。ＳＬＡは、通常、顧客に固有であり、顧客の仮想環境を定義し、顧客は、通常、全体としてのクラウドシステムのインフラストラクチャ全体に関してではなく、彼らの仮想環境に関してＳＬＡが満足されることにのみ関心を持つ。クラウドプロバイダは、通常、複数の顧客をサポートする（上で注記したように、明瞭さのために、単一の顧客１２０が図示され、本明細書で説明されるが）。その結果、クラウドプロバイダは、通常、クラウドシステムのインフラストラクチャが、その顧客のすべての仮想環境のすべてについてＳＬＡを満足できることを保証する。クラウドシステム１００が、クラウドプロバイダがこの能力を提供することを可能にするように構成されることに留意されたい。
【００２７】
顧客１０２は、顧客１０２の動的信頼性プロファイル（ＤＲＰ）１０５を生成するのに使用され得る情報を提供することができる。顧客１０２のＤＲＰ  １０５は、顧客１０２によって直接に指定され得、ＳＬＡ  １０３内で顧客１０２によって指定され得、ＳＬＡ  １０３について入力された情報の処理および／もしくはＳＬＡ  １０３自体の処理を介して決定され得（たとえば、信頼性指定子１０４および／または任意の他の適切なシステムもしくはコンポーネントによって）、など、ならびにそのさまざまな組合せによって指定され得る。ＤＲＰ  １０５は、任意の適切な粒度で提供され得る（たとえば、特定のアプリケーションについて、アプリケーションのセットについて、特定のサービスについて、サービスのセットについて、１つまたは複数のサービスおよび１つまたは複数のアプリケーションについて、全体としての顧客１０２について、など）。図１に示されているように、顧客１０２のＤＲＰ  １０５は、ＲＳＧ  １２０に提供される。
【００２８】
クラウドリソース１１０は、顧客１０２による使用のために構成され得る。クラウドリソース１１０は、コンピューティングリソース１１１、メモリリソース１１２、ストレージリソース１１３、入出力リソース１１４、およびネットワークリソース１１５を含むことができる。クラウドリソース１１０が、事実上無限であると仮定され得る（すなわち、すべての顧客需要を満足するのに十分なクラウドリソース１１０がある）ことに留意されたい。さらに、クラウドリソース１１０は、分散され得、動的にグループ化され得ることに留意されたい。クラウドリソース１１０が、顧客１２０による使用のために割り当てられ得る典型的な方法は、当業者によって理解される。主に特定のタイプのクラウドリソース１１０に関して図示され、説明されるが、クラウドリソース１１０が、顧客による使用のために構成され得る任意の他のタイプのクラウドリソースを含むことができることを了解されたい。
【００２９】
ＲＳＧ  １２０は、クラウドシステム１００が自己信頼システムとして動作することを可能にするさまざまな機能を提供するように構成される。たとえば、ＲＳＧ  １２０は、顧客１０２のＤＲＰ１０５を受け取り、ＤＲＰ  １０５によって指定される要求される信頼性を提供するようにクラウドシステム１００のクラウドリソース１１０を動的に構成するように構成され得る。ＲＳＧ  １２０は、指定された信頼性が実際に提供されることを保証するために、その後に挙動を監視し、計測するようにも構成され得る。ＲＳＧ  １２０は、さまざまな他の関連する機能を提供するようにも構成され得る。図１に表されているように、ＲＳＧ  １２０が、集中化された形または分散された形で実現され得ることに留意されたい。
【００３０】
ＲＳＧ  １２０は、４つの機能コンポーネントすなわち、構成エンジン（ＣＥ）１２２、スケジューリングエンジン（ＳＥ）１２４、監視エンジン（ＭＥ）１２６、および制御エンジン（ＣＥ）１２８を含む。４つの機能コンポーネントが、１つまたは複数の物理デバイスを使用して実現され得る（たとえば、ＲＳＧ  １２０の機能は、単一のシステム内に集中化されたり、１つまたは複数のシステムにまたがって分散されたり、などを行われ得る）ことに留意されたい。したがって、ＲＳＧ  １２０は、４つの機能コンポーネントがクラウドシステム１００内で実現され得るさまざまな形を示すことを意図された破線の箱を使用して表されている。
【００３１】
ＣＥ  １２２は、顧客１０２によって定義されたＤＲＰ  １０５（またはＤＲＰ  １０５を含むＳＬＡ  １０３）を受け取り、顧客１０２の仮想構成１３１を動的に生成するのにＤＲＰ  １０５を使用する。仮想構成１３１は、顧客１０２のＤＲＰ  １０５を満足する（たとえば、ＤＲＰ  １０５の要件および／または目標を満足する）顧客１０２の仮想構成を指定する。仮想構成１３１は、時間の関数として指定され得る。ＣＥ  １２２は、クラウドシステム１００の現在の状態および／またはクラウドシステム１００によって課せられるポリシ／制約をも考慮に入れると同時に、ＤＲＰ  １０５を満足する仮想構成１３１を動的に生成することができる。ＣＥ  １２２は、仮想構成１３１をＳＥ  １２４に供給する。ＣＥ  １２２は、本明細書で議論されるようにさまざまな他の機能を提供することができる。
【００３２】
ＳＥ  １２４は、ＣＥ  １２２から仮想構成１３１を受け取る。ＳＥ  １２４は、ＤＲＰ  １０５とクラウドシステム１００の現在の状態および／またはクラウドシステム１００によって課せられるポリシ／制約とによって支配される適当な時に、仮想構成１３１を物理インフラストラクチャ１０１に（たとえば、クラウドリソース１１０に）マッピングする。ＳＥ  １２４によって決定されたマッピングを、マッピング１３２と表す。ＳＥ  １２４は、ＤＲＰ  １０５の実現に関連する必須のタイプの冗長性方式（１つまたは複数）および／または回復方式（１つまたは複数）を指定することができる。ＤＲＰ  １０５が、任意の適切な粒度で指定され得るのと同様に、関連するマッピング１３２が、任意の適切な粒度で提供され得ることに留意されたい。ＳＥ  １２４は、顧客１０２がクラウドリソース１１０を利用できるように、物理インフラストラクチャ１０１内でマッピング１３２を実現する（たとえば、顧客１０２によるクラウドリソース１１０の使用を可能にするための物理インフラストラクチャ１０１の構成を介して）ように構成される。ＳＥ  １２４は、本明細書で議論されるようにさまざまな他の機能を提供することができる。
【００３３】
ＭＥ  １２６は、物理インフラストラクチャ１０１のコンポーネント（たとえば、クラウドリソース１１０の、コンピューティングリソース１１１、メモリリソース１１２、ストレージリソース１１３、入出力リソース１１４、およびネットワークリソース１１５、ならびに任意の他の関連する物理コンポーネントまたはリソース）の状態を観察する。ＭＥ  １２６は、物理インフラストラクチャ１０１からＭＥ  １２６で受け取られるシステム状態情報１３３（たとえば、アラーム、プローブ、ログファイル、など、ならびにそのさまざまな組合せ）を受け取り、分析することによって、物理インフラストラクチャ１０１のコンポーネントの状態を観察する。ＭＥ  １２６は、物理インフラストラクチャ１０１のコンポーネントの観察された状態を、顧客１０２の仮想環境の状態に変換する。ＭＥ  １２６は、信頼性／セキュリティ情報１３４（少なくともいくつかの実施形態で、信頼性完全性メーター（ＲＩＭ）として表され得る）として信頼性およびセキュリティに関連するイベントおよび状態を取り込むように構成され得る。ＭＥ  １２６は、ＣＥ  １２８による使用のために制御情報（制御情報１３５と表される）（たとえば、クラウドシステム１００内のイベントまたは条件に反応してＣＥ  １２８によって使用される反応制御情報、潜在的なイベントまたは条件がクラウドシステム１００内で発生するのを防ぐ際にＣＥ  １２８によって使用される予測予防制御情報、など、ならびにそのさまざまな組合せ）を決定するように構成され得る。ＭＥ  １２６は、本明細書で議論されるようにさまざまな他の機能を提供することができる。
【００３４】
ＣＥ  １２８は、ＭＥ  １２６から制御情報１３５を受け取り、ポリシ／制約情報１３６（たとえば、ＳＬＡ  １０３、ＤＲＰ  １０５、など、ならびにその組合せの一部として指定され得る）を受け取り、クラウドシステム１００の物理インフラストラクチャ１０１（たとえば、クラウドリソース１１０）を制御／構成する際の使用に適合されたフィードバックアクション１３７を決定するのに制御情報１３５およびポリシ／制約情報１３６を使用するように構成される。ＣＥ  １２８は、クラウドシステム１００の物理インフラストラクチャ１０１を制御／構成するために、物理インフラストラクチャ１０１にフィードバックアクション１３７を供給する。フィードバックアクション１３７は、反応フィードバックアクション（たとえば、識別されたイベント（１つまたは複数）または条件に反応する）および／または予測予防フィードバックアクション（たとえば、予測されたイベント（１つまたは複数）または条件（１つまたは複数）が発生するのを防ぐ）の両方を含むことができる。たとえば、ＣＥ  １２８は、障害が検出される時に回復アクションをトリガし、かつ／または障害が発生するのを避けるために予防手段を開始することができる。ＣＥ  １２８は、本明細書で議論されるようにさまざまな他の機能を提供することができる。
【００３５】
図１に示されているように、ＲＳＧ  １２０のコンポーネントは、任意の適切な形でクラウドシステム１００内に組み込まれ得る。たとえば、一実施形態では、ＲＳＧ  １２０のコンポーネントは、クラウドシステム１００のインフラストラクチャ層、プラットフォーム層、およびサービス層内に組み込まれ得る。図１および本明細書で提供される他の説明から明白であるように、クラウドシステム１００の自己信頼の性質は、（１）ハードウェアおよび／またはソフトウェアの障害または破壊に関係ない、クライアントへのサービス可用性の提供、（２）攻撃からのサービス、データ、およびインフラストラクチャの保護とパーソナルデータのプライバシの保証、（３）イベントまたはポリシに基づくリアルタイムでの柔軟で動的なリソース割振りすなわちスケーラビリティの提供、（４）提供における許容できる経済を伴う広範囲のワークロード需要にわたる予測可能な性能、という特徴／便益のうちの１つまたは複数によって特徴を表され得る。クラウドシステム１００の実施形態の使用から実現され得るさまざまな他の特徴／便益は、図１および本明細書で提供される他の説明から了解される。
【００３６】
本明細書で説明されるように、ＤＲＰ  １０５は、時間の関数と顧客１０２のアプリケーションまたはサービスの要件の関数との両方として顧客１０２の信頼性パラメータ（たとえば、要件／目標）を指定する。顧客スイート内のすべてのアプリケーション／サービスが、同一の信頼性の必要性を有すると期待されるわけではなく、さらに、アプリケーション／サービスの信頼性の必要性が、時間に伴って変化する可能性があることを了解されたい。その時間変動する性質を示す、例示的なＤＲＰ  １０５が、図２に関して図示され、説明される。
【００３７】
図２は、図１のＲＳＧによって使用される例示的な動的信頼性プロファイル（ＤＲＰ）を示す。図２に示されているように、ＤＲＰ  １０５は、時間（ｘ軸に図示）に対する顧客の信頼性の必要性の変化（ｙ軸に図示）を表す。本明細書で説明されるように、ＲＳＧ  １２０は、ＤＲＰ  １０５で指定された要求される信頼性を提供するようにクラウドリソース１１０を動的に構成するのにＤＲＰ  １０５を使用するように構成される。事実上無限のクラウドリソースを有するクラウドシステムでは、これが、より多くのリソース利用、より多くのコスト節約、電力使用のより高い効率、およびさまざまな他の利点をもたらすことに留意されたい。
【００３８】
本明細書で説明されるように、クラウドシステム１００は、それぞれが１つまたは複数の関連するＤＲＰ  １０５を有する複数の顧客１０２をサポートすることができる。その結果、クラウドシステム１００は、ＤＲＰ  １０５が時間変動するプロファイルであるという事実を考慮に入れると同時に、複数の顧客１０２のＤＲＰ  １０５を同時に管理する必要がある。複数の顧客１０２のＤＲＰ  １０５の時間変動する性質に関して、次の３つのケースが、本明細書で考慮される（さまざまな他のケースも考慮される可能性があることに留意されたい）（１）所与の顧客のアプリケーションミックスの要件が、時間に伴って変化する可能性があり、（２）顧客グループの要件が、時間に伴って変化する可能性があり、（３）所与のアプリケーションの要件が、時間に伴って変化する可能性がある。異なるアプリケーションミックスを有する３人の顧客１０２の例が、図３に関して図示され、説明される。
【００３９】
図３は、図１のクラウドシステムの３人の顧客の時間の関数としての例示的なアプリケーションミックスを示す。
【００４０】
図３に示されているように、アプリケーションミックス３００は、顧客Ａ、Ｂ、およびＣと表される３人の顧客のアプリケーションの例示的なミックスを示す。３人の顧客Ａ、Ｂ、およびＣのアプリケーションは、それぞれＡｉ、Ｂｉ、およびＣｉと表される。アプリケーションＡｉ、Ｂｉ、およびＣｉは、それぞれ、それに関連する信頼性要件を有する（明瞭さのために、３つの可能な信頼性要件は、高、中、低にサポートされる）。この例では、高の信頼性要件は、完全にアクティブ／アクティブ冗長性が期待されることを示し、中の信頼性要件は、アクティブ／スタンバイの冗長性方式が期待されることを示し、低の信頼性要件は、冗長性が期待されないことを示す。
【００４１】
アプリケーションミックス３００は、経時的に変化し、４つの例示的な時間期間３１０１−３１０４（合計で時間期間３１０）が、経時的なアプリケーションミックス３００の変化を示す際の使用のために示されている。
【００４２】
時間期間３１０１では、顧客Ａは、アプリケーションＡ１からＡ５を有し、アプリケーションＡ１、Ａ３、およびＡ５は、それぞれ高の信頼性要件を有し、アプリケーションＡ２は、中の信頼性要件を有し、アプリケーションＡ４は、低の信頼性要件を有する。また、時間期間３１０１では、顧客Ｂは、アプリケーションＢ１からＢ４を有し、アプリケーションＢ１およびＢ２は、それぞれ中の信頼性要件を有し、アプリケーションＢ３およびＢ４は、それぞれ高の信頼性要件を有する。また、時間期間３１０１では、顧客Ｃは、中の信頼性要件を有するアプリケーションＣ１を有する。
【００４３】
時間期間３１０２では、顧客Ａ、Ｂ、およびＣのアプリケーションのミックスは、時間期間３１０１のアプリケーションミックス３００と同一である（すなわち、何も変化していない）。
【００４４】
時間期間３１０３では、顧客Ａ、Ｂ、およびＣのアプリケーションのミックスは、複数の形で変化している（たとえば、以前のアプリケーションがもはや存在せず、まだ存在する以前のアプリケーションの信頼性要件が変更され、新しいアプリケーションが導入され、など）。時間期間３１０３では、顧客Ａは、アプリケーションＡ２、Ａ４、Ａ５、Ａ６（新規）、およびＡ７（新規）を有し、アプリケーションＡ２およびＡ７は、それぞれ中の信頼性要件を有し、アプリケーションＡ４は、高の信頼性要件を有し、アプリケーションＡ５およびＡ６は、それぞれ低の信頼性要件を有する。また、時間期間３１０３では、顧客Ｂは、アプリケーションＢ３、Ｂ５、Ｂ６、およびＢ７を有し、アプリケーションＢ３およびＢ５は、それぞれ高の信頼性要件を有し、アプリケーションＢ６は、中の信頼性要件を有し、アプリケーションＢ７は、低の信頼性要件を有する。また、時間期間３１０３では、顧客Ｃは、中の信頼性要件を有するアプリケーションＣ２（新規）を有する。
【００４５】
時間期間３１０４では、顧客Ａ、Ｂ、およびＣのアプリケーションのミックスは、複数の形で再び変化している（たとえば、以前のアプリケーションがもはや存在せず、まだ存在する以前のアプリケーションの信頼性要件が変更され、新しいアプリケーションが導入され、など）。
【００４６】
図３に関して図示され、説明された信頼性要件が、単に例示的であることに留意されたい。現実には、粒度がより微細である可能性があり、アプリケーションの複雑さおよびそれに関連する信頼性要件が、異なる可能性がある。たとえば、例示的な信頼性要件のうちの１つまたは複数が、他の値を使用して表される可能性があり、例示的な信頼性要件のうちの１つまたは複数が、他の形で定義される可能性があり、より少数またはより多数の信頼性要件（異なる信頼性要件を含む）が、サポートされる可能性があり、さまざまな信頼性目標が、サポートされる可能性があり（たとえば、信頼性要件の代わりにおよび／またはそれに加えて）、など、ならびにそのさまざまな組合せ）。
【００４７】
図４は、顧客アプリケーション情報を図１のクラウドシステムの物理リソースにマッピングするプロセスの一実施形態を示す。
【００４８】
一般に、プロセス４００は、顧客１０２によって必要とされ、かつ／または望まれるものの、基礎になるクラウドインフラストラクチャ内で実現可能なものヘの制約されたマッピング（すなわち、あたかも顧客１０２が、電話で信頼性を申し込むことができ、クラウドシステム１００が、それを提供することを試みるかのようである）を実行する。
【００４９】
一実施形態では、方法４００は、ＲＳＧ  １２０のＣＥ  １２２によって実行される。
【００５０】
図４に示されているように、方法４００では、入力情報が、ある点で受け取られ、使用される。入力情報は、顧客アプリケーション情報４０１およびクラウドシステム情報４０２を含む。顧客アプリケーション情報４０１は、顧客１０２の顧客アプリケーショントポロジ情報（たとえば、明示的に指定され、かつ／または記述から抽出され得る）、顧客１０２の顧客ＳＬＡ情報、顧客１０２のＤＲＰ  １０５、などを含む。クラウドシステム情報４０２は、現在のシステム状態情報、ポリシ／制約情報（たとえば、一つまたは複数のハードウェアおよび／またはソフトウェアリソース使用情報、顧客プロファイル情報、要求される性能情報、セキュリティ制約、コスト制約など）、などを含む。
【００５１】
ステップ４１０では、仮想アプリケーショントポロジ４１５が、顧客アプリケーション情報４０１の少なくとも一部および／またはクラウドシステム情報４０２の少なくとも一部を使用して生成される。一実施形態では、たとえば、仮想アプリケーショントポロジ４１５は、アプリケーショントポロジ情報、現在のシステム状態情報、およびポリシ制約を使用して生成され得る。
【００５２】
ステップ４２０では、信頼性マップ４２５が、仮想アプリケーショントポロジ４１５とクラウドシステム情報４０２の少なくとも一部と（および、オプションで、明瞭さのために省略されているが、顧客アプリケーション情報４０１の少なくとも一部）を使用して生成される。信頼性マップ４２５は、顧客１０２のアプリケーション必要性および／またはアプリケーション目標を満足すると期待される信頼性構成を識別する。一実施形態では、信頼性マップ４２５は、信頼度ブロック図（ＲＢＤ）として表され得る。信頼性マップ４２５の生成に関連する多数の考慮事項があることに留意されたい。たとえば、冗長性アーキテクチャおよびフェイルオーバ方式は、プロセッサリソースの位置によって影響を受ける（たとえば、プロセッサリソースが同一のマルチコアチップ内、同一のブレード上、ブレードにまたがって、シャシーにまたがって、ＬＡＮ内、ＷＡＮにまたがって、などのどれであるのか）。たとえば、メモリおよびディスクの割振りも、考慮され得る。たとえば、ディスク割振り、ファイルシステム、およびデータベース構成、ローカルまたはリモートのどちらであるのかも考慮され得る。さらに、フォールトトレラント要件（たとえば、ＤＲＰ  １０５内で指定される）が、問題の一部にすぎない可能性がある（たとえば、性能、セキュリティ、コスト、などは、最適構成を決定する際にＤＲＰ  １０５と一緒に考慮される必要がある可能性がある他の要素である）ので、信頼性マップ４２５の生成は、さらに複雑化され得る。
【００５３】
ステップ４３０では、物理構成４３５が、信頼性マップ４２５とクラウドシステム情報４０２の少なくとも一部と（および、オプションで、明瞭さのために省略されているが、顧客アプリケーション情報４０１の少なくとも一部）を使用して決定される。一実施形態では、たとえば、物理構成４３５は、信頼性マップ４２５、現在のシステム状態情報、およびポリシ／制約情報を使用して決定され得る。物理構成４３５は、クラウドシステム１００の使用可能な物理インフラストラクチャ１０１（たとえば、クラウドリソース１１０）への、顧客１０２の信頼性マップ４２５のマッピングを指定する。たとえば、物理構成４３５は、プロセッサ、メモリユニット、ディスク、ファイル、データベース、入出力リソース、ネットワークリソース、などのうちの１つまたは複数への顧客１０２の信頼性マップ４２５のマッピングを指定する。
【００５４】
図５は、物理インフラストラクチャへのアプリケーショントポロジの例示的なマッピングを示す。
【００５５】
図５の例示的なマッピング５００は、図４の方法４００に関して図示され、説明されたステップに対応する。図５の例示的なマッピング５００は、アプリケーショントポロジ５１０（たとえば、経時的なアプリケーション信頼性仕様を提供する）、信頼性マップ５２０（たとえば、経時的なＤＲＰ仕様を提供する）、および物理構成５３０（たとえば、経時的な物理コンポーネントへのマッピングを指定する）を示し、これらは、それぞれ図４の仮想アプリケーショントポロジ４１５、信頼性マップ４２５、および物理構成４３５に対応する。
【００５６】
図５に示されているように、例示的なマッピング５００は、その信頼性の必要性が時間に伴って変化するアプリケーションに関する。アプリケーションは、経時的に変化し、４つの例示的な時間期間５０１１−５０１４（合計で時間期間５０１）が、経時的なアプリケーションの変化の図示での使用のために図示されている。
【００５７】
アプリケーショントポロジ５１０は、アプリケーション内のアプリケーションコンポーネント５１１と、アプリケーションコンポーネント５１１の関連する信頼性要件とを示す（実例として、高、中、低の信頼性要件を示すのに、それぞれＨ、Ｍ、およびＬを使用する）。時間期間５０１１では、アプリケーションは、高信頼性要件を有する第１アプリケーションコンポーネントおよび低信頼性要件を有する第２アプリケーションコンポーネントを含む２つのアプリケーションコンポーネントを含む。他の時間期間５０１では、アプリケーショントポロジ５１０は、アプリケーションが変化するので変化する。
【００５８】
信頼性マップ５２０は、ＲＢＤの形で表される。時間期間５０１１では、アプリケーションは、２つのコンポーネントＡおよびＢにマッピングされ、コンポーネントＡは、冗長対Ａ１およびＡ２である（高信頼性要件に起因して）。コンポーネントＢは、コンポーネントＡにカスケードされ、動作中にはシンプレックスである（その低信頼性要件に起因して）。他の時間期間５０１では、ＲＢＤで表される信頼性マップ５２０は、アプリケーショントポロジ５１０が変化するので変化する。
【００５９】
物理構成５３０は、クラウドシステムの使用可能な物理インフラストラクチャへのアプリケーションの信頼性マップ５２０（実例として、アプリケーションのＲＢＤのアプリケーションコンポーネント）のマッピングを指定する。たとえば、物理構成５３０は、プロセッサ、メモリユニット、ディスク、ファイル、データベース、入出力リソース、ネットワークリンク、などのうちの１つまたは複数への信頼性マップ５２０のマッピングを指定することができる。時間期間５０１１では、冗長対Ａ１およびＡ２を含むアプリケーションコンポーネントＡは、そのような冗長性を提供するように構成された２つのプロセッサリソースにマッピングされ、アプリケーションコンポーネントＢは、１つのプロセッサリソースにマッピングされる。他の時間期間５０１では、物理構成５３０は、ＲＢＤで表された信頼性マップ５２０が変化するので変化する。主に、プロセッサリソースへのマッピングに関して図示され、説明されるが、物理構成５３０が、任意の他の適切なリソースへのアプリケーションの信頼性マップ５２０のマッピング、たとえば、プロセッサリソースへのより詳細なマッピング（たとえば、セキュリティ仕様およびユーザプロファイル仕様と一貫するファイル、データベース、入出力ポート、および通信ポートへの適当な特権、読取／書込／実行許可、およびアクセスを有するプロセッサ）、他のタイプのリソース（たとえば、メモリユニット、ディスク、ファイル、データベース、入出力リソース、ネットワークリンク、など）へのマッピング、など、ならびにそのさまざまな組合せを指定することができることに留意されたい。
【００６０】
もう一度図１に戻ると、ＭＥ  １２６は、クラウドシステム１００の監視機能および計測機能を実行するように構成される。ＭＥ  １２６は、クラウドシステム１００内でサポートされる自己回復能力を可能にするためにＲＳＧ  １２０の他のコンポーネントと協力することができる。
【００６１】
ＭＥ  １２６は、故障を識別し、セキュリティ攻撃を識別し、アプリケーションの性能を測定、などを行い、さらに、関連する結果を報告する（たとえば、故障の識別、セキュリティ攻撃の識別、性能劣化の検出、など、ならびにそのさまざまな組合せ）ために、クラウドシステム１００内のコンピューティングリソースを周期的にスキャンするように構成され得る。
【００６２】
ＭＥ  １２６は、異常が検出される時にアラートを生成するように構成され得、関連するアラートは、ネットワーク条件に影響するサービスの存在（または不存在）を決定するために相関され、分析される。
【００６３】
ＭＥ  １２６は、アラームを収集し（たとえば、クラウドシステム１００のネットワークコンポーネントの一部またはすべてから）、時間的関連性および／または空間的関連性に基づいて、収集されたアラートをアラート条件に対して相関させるように構成され得る。
【００６４】
ＭＥ  １２６は、クラウドシステム１００のネットワークトポロジ情報を収集し、そのような相関機能を実行する際に使用される１つまたは複数のモデルにネットワークトポロジ情報を組み込むように構成され得る。
【００６５】
ＭＥ  １２６は、独立ネットワークイベントのルート原因を決定し、オプションで、検出されたネットワークイベントを停止関連（サービスに影響する）または非停止関連（サービスに影響しない）としてマークするように構成され得る。
【００６６】
ＭＥ  １２６は、指定された時間期間内に含まれるセットを決定するために独立のルート原因イベントのセットを分析することと、指定された時間期間内の総停止時間を計算するために相関されたイベントの持続時間を組み合わせることと、ネットワークトポロジ情報およびイベントによって影響されるサービスのタイプに対してイベントを比較することと、ネットワーク影響の範囲および停止時間のパーセンテージを使用して、評価されつつあるサービス（１つまたは複数）の総サービス可用性を決定することとによって、指定された時間期間にわたる特定の集約レベルのサービス可用性を計算するように構成され得る。サービス可能性の決定が、考慮されるサブネットワーク（１つまたは複数）、使用される基礎になるネットワークトポロジ、ネットワークトポロジ／サイズ、および同様の要因に依存する可能性があることに留意されたい。
【００６７】
ＭＥ  １２６は、信頼性完全性メーターを決定し、ＣＥ  １２８による使用のために制御情報を決定するように構成され得る。そのような機能を実行するためのＭＥ  １２６の例示的な使用は、図６に関して図示され、説明される。
【００６８】
図６は、イベント相関／集約を実行し、反応／予測制御情報を決定する、図１のＲＳＧの例示的な使用を示す。
【００６９】
図６に示されているように、ＭＥ  １２６は、イベント相関／集約を実行し、反応／予測制御情報を決定するように構成され得る。
【００７０】
ＭＥ  １２６は、イベント６０２およびポリシ／制約情報６０４を受け取る。イベント６０２は、図６に示されているように、クラウドシステム１００の物理インフラストラクチャ１０１から直接に受け取られ得、かつ／あるいはクラウドシステム１００の物理インフラストラクチャ１０１の代わりに１つもしくは複数の他の監視するおよび／または管理要素／システム（たとえば、１つまたは複数のプローブ、１つまたは複数のＥｌｅｍｅｎｔ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ（ＥＭＳ）、１つまたは複数のネットワーク管理システム（ＮＭＳ）、など）から受け取られ得る。イベント６０２の監視は、ＭＥ  １２６によって、および／またはクラウドシステム１００の物理インフラストラクチャ１０１にまたがって（たとえば、ＭＥ  １２６に報告するために）実行され得る。監視が実行されるイベント６０２のタイプは、サブシステムによって生成されるソフトウェアアラート、さまざまなメトリックの測定カウンタ内で発生するしきい値越え、アプリケーション障害（たとえば、全面的および／または部分的）、サービスが影響を受けることをもたらすセキュリティ攻撃、ハードウェア障害（たとえば、回復可能または回復不能）、トラフィック負荷の変動、ネットワーク障害、などを含むことができる。ポリシ／制約情報６０４は、図４に示されているように、ハードウェアおよび／またはソフトウェアリソース使用情報、顧客プロファイル情報、要求される性能情報、セキュリティ制約、コスト制約、など、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【００７１】
ＭＥ  １２６は、集約エンジン６１２、相関分析エンジン６１４、および処理エンジン６１６を含む。ＭＥ  １２６は、ヒストリデータベース６１９をも含む。
【００７２】
集約エンジン６１２は、物理インフラストラクチャ１０１に関連するイベント６０２を受け取り、イベント６０２を集約する。集約エンジン６１２は、指定された時間期間の間に処理を実行する時に、指定された時間期間内に含まれるセットを決定するためにイベント６０２を分析することによって、イベント６０２を集約することができる。集約エンジン６１２は、集約されたイベント情報を相関分析エンジン６１４および／またはヒストリデータベース６１９に供給することができる。
【００７３】
相関分析エンジン６１４は、集約されたイベント情報を受け取り（たとえば、集約エンジン６１２および／またはヒストリデータベース６１９から）、集約されたイベントの相関を実行する。相関分析エンジン６１４は、任意の適切な相関機能を実行することができる。たとえば、関連するイベント６０２は、サービスに影響するネットワーク条件の存在（または不存在）を決定するために相関され、分析され得、イベント６０２は、時間的関連性および／または空間的関連性、など、ならびにそのさまざまな組合せに基づいて、アラート条件に対して相関され得る。相関分析エンジン６１４は、相関されたイベント情報を処理エンジン６１６および／またはヒストリデータベース６１９に供給することができる。
【００７４】
処理エンジン６１６は、ポリシ／制約情報６０４を受け取り、相関されたイベント情報を受け取る（たとえば、相関分析エンジン６１４および／またはヒストリデータベース６１９から）。
【００７５】
処理エンジン６１６は、ＭＥ  １２６によって監視され、集約され、相関される情報の要約を含むことができる信頼性完全性メーター（ＲＩＭ）６２２を生成する。処理エンジン６１６は、ＲＩＭ  ６２２をローカルに（たとえば、ヒストリＤＢ  ６１９内に）格納することができ、かつ／または任意の適切なシステム、デバイス、エンジン、および／または他のコンポーネントもしくは要素にＲＩＭ  ６２２を供給することができる。
【００７６】
処理エンジン６１６は、反応／予測制御情報６２４を生成する。ＭＥ  １２６は、クラウドシステム１００の物理インフラストラクチャ１０１内で制御機能を実行する際のＣＥ  １２８による使用のために反応／予測制御情報６２４をＣＥ  １２８に供給する。たとえば、ＭＥ  １２６は、（１）クラウドシステム１００の物理インフラストラクチャ１０１内で反応制御機能を提供するためのＣＥ  １２８の１つまたは複数の反応制御エンジンによる使用のために反応制御情報をＣＥ  １２８に、および（２）クラウドシステム１００の物理インフラストラクチャ１０１内で予測予防制御機能を提供するためのＣＥ  １２８の１つまたは複数の予測予防制御エンジンによる使用のために予測予防制御情報をＣＥ  １２８に、供給する。
【００７７】
処理エンジン６１６は、ＭＥ  １２６によって収集された生データからさまざまなタイプの性能メトリック（たとえば、ｋｅｙ  ｑｕａｌｉｔｙ  ｉｎｄｉｃａｔｏｒ（ＫＱＩ）、ｋｅｙ  ｐｅｒｆｏｒｍａｎｃｅ  ｉｎｄｉｃａｔｏｒ（ＫＰＩ）、など）を計算するように構成され得る。メトリックは、ＲＩＭ  ６２２に含めるために計算され得る。たとえば、信頼性計測に使用され得る性能メトリックは、ハードウェアおよび／またはソフトウェアの障害頻度（たとえば、サービスレベル、コンポーネントレベル、または任意の他の適切なレベルでの）、ハードウェアおよび／またはソフトウェアのダウンタイム（たとえば、サービスレベル、コンポーネントレベル、または任意の他の適切なレベルでの）、ハードウェアおよび／またはソフトウェアの可用性（たとえば、サービスレベル、コンポーネントレベル、または任意の他の適切なレベルでの）、データ非可用性（たとえば、障害、セキュリティ攻撃、などに起因する）、など、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。メトリックは、任意の適切なレベルで指定され得る（たとえば、仮想化されたアプリケーションまたはコンポーネントについて、仮想化されたアプリケーションまたはコンポーネントのセットについて、サービスについて、サービスのセットについて、エンドツーエンドソリューションについて、データセンタについて、など、ならびにそのさまざまな組合せ）ことに留意されたい。性能インジケータは、考慮中の顧客１０２に最も関連する性能インジケータとすることができることに留意されたい。処理エンジン６１６は、性能インジケータを期待される値と比較するようにも構成され得る。
【００７８】
図６にさらに示されているように、ＣＥ  １２８は、ＭＥ  １２６から反応／予測制御情報６２４を受け取り、クラウドシステム１００の物理インフラストラクチャ１０１内で反応／予測制御機能を実行するのに反応／予測制御情報６２４を使用するように構成される。ＣＥ  １２８は、関連するフィードバックアクション（たとえば、図１に関して図示され、説明されたフィードバックアクション１３７）を物理インフラストラクチャ１０１に供給することによって、反応制御機能および予測予防制御機能を提供することができる。ＭＥ  １２６が、クラウドシステム１００の挙動を観察し、測定するが、ＣＥ  １２８が、測定された挙動が期待される挙動と一致すること、および、さらに、逸脱がある場合に適当な補正アクションが開始されることを保証するために、ループを閉じることに留意されたい。さらに、ＭＥ  １２６が、機能を実行し、ＣＥ  １２８によって実行される制御アクションを最終的に駆動する結果を作る（たとえば、ＭＥ  １２６は、相関分析エンジン６１４の結果をポリシ／制約情報６０４と組み合わせ、ＲＩＭ  ６２２内に含まれるメトリックを作り、結果および現在の状態をヒストリデータベース６１９内のヒストリカル情報として保存し、ＣＥ  １２８によって実行される反応制御アクションおよび予測予防制御アクションを導出するためにポリシ／制約情報６０４およびヒストリカル情報を使用する）ことに留意されたい。
【００７９】
ＣＥ  １２８は、反応制御エンジン６３２および予測予防制御エンジン６３４を含む。
【００８０】
反応制御エンジン６３２は、ＭＥ  １２６から反応制御情報を受け取り、物理インフラストラクチャ１０１内で反応制御機能を実行する。反応制御エンジン６３２は、条件（たとえば、イベント、障害、など）から回復するためにアクションを用いて応答するように構成され得る。たとえば、回復アクションは、プロセスリスタートの実行、別のプロセッサ（たとえば、ローカルまたはリモート）上でのプロセスリブートおよびプロセスリスタートの実行、障害を発生したネットワーク接続の再確立、ストレージユニットに対するリスタートの実行、ソフト障害に関連する回復アクション（たとえば、データの再初期化、プロセスの復元またはリセット、など）の実行、など、ならびにそのさまざまな組合せを含むことができる。反応制御エンジン６３２は、条件のソースまたはルート原因を識別するために診断テストを実行するように構成され得る。
【００８１】
予測予防制御エンジン６３４は、ＭＥ  １２６から予測予防制御情報を受け取り、物理インフラストラクチャ１０１内で予測予防制御機能を実行する。予測予防制御エンジン６３４は、再編成の実行、再平衡化アクションの実行、監査の実行、先を見越したテスティングの実行、などの予測予防手段を実行するように構成され得る。
【００８２】
たとえば、予測予防制御エンジン６３４は、リソースを再編成するように構成され得る（たとえば、新しいサービスが構成される時またはシステム内で発生する最近のイベントに起因する動的モデル構築、既存の合成サービスの構造を変更する再構成、など）。
【００８３】
たとえば、予測予防制御エンジン６３４は、デフラグメンテーションを実行するように構成され得る（たとえば、ディスクアクセスをより滑らかでより効率的にし、これによって性能を改善し、ディスク寿命を保存するために、ストレージシステムを周期的にデフラグメンテーションすることによって）。
【００８４】
たとえば、予測予防制御エンジン６３４は、動的信頼性計算が障害データの増分更新に基づく動的信頼性モデリングを実行するように構成され得る。一実施形態では、動的信頼性モデリングの焦点は、ランタイムデータ収集から信頼性評価までのプロセス全体にあり、ヒストリカルデータを使用するのみではなく、データ収集および動的プロファイリングが強調される。一実施形態では、ＲＩＭ  ６２２は、ソフトウェアがクラウドシステム１００の変化する環境に合わせて再構成される時に、動的に更新され得る。
【００８５】
たとえば、予測予防制御エンジン６３４は、再平衡化動作を実行するように構成され得る（たとえば、ポリシ／制約情報６０４の対象である使用可能なリソースへの負荷を再平衡化することによって）。
【００８６】
たとえば、予測予防制御エンジン６３４は、監査を実行するように構成され得る。一実施形態では、周期的監査が、物理リソースおよび論理リソースを追跡し、データ完全性を維持し、セキュリティを保証するために実行される。一実施形態では、監査は、（１）リソースインベントリ（たとえば、ＣＰＵリソース、メモリリソース、入出力リソース、およびネットワークリソース）および（２）インフラストラクチャのトポロジ（たとえば、冗長性構成を含むコンポーネントの間の接続性）に対して実行され得る。一実施形態では、監査は、データ完全性を保証し、すべての潜在的な問題を明らかにするために、ユーザデータベースおよびファイルに対して実行される。
【００８７】
たとえば、予測予防制御エンジン６３４は、先を見越したテスティングを実行するように構成され得る。一実施形態では、先を見越したテスティングは、インサービスのシミュレートされた攻撃の実行、障害の間際条件テスティング、および計画された保守アクションに関連するテスティング（たとえば、プラグを抜く）を含むことができる。一実施形態では、先を見越したテスティングの少なくとも一部は、物理インフラストラクチャ１０１内の事実上無限のリソースの可用性に頼ることができる。このタイプのテスティングは、クラウドシステム１００が頑健であり続けることを保証するのを助けることができる。
【００８８】
この形で、ＲＳＧ  １２０は、クラウドシステム１００が自己信頼システムとして機能することを可能にするように構成される。
【００８９】
主にＲＳＧ  １２０の特定の機能を提供するための特定のコンポーネント（実例として、ＣＥ  １２２、ＳＥ  １２４、ＭＥ  １２６、およびＣＥ  １２８）の使用に関して図示され、説明されるが、ＲＳＧ  １２０の機能が、１つまたは複数の任意の適切なコンポーネントを使用して提供され得ることに留意されたい。たとえば、図示のコンポーネントによって実行されるものとして図示され、説明される機能は、異なる形で図示のコンポーネントにまたがって分散され得る。たとえば、１つまたは複数の他のコンポーネント（たとえば、図示のコンポーネントの代わりにおよび／またはこれに加えて）が、図示のコンポーネントによって実行されるものとして図示され、説明される機能を提供するのに使用され得る。
【００９０】
主に、クラウドシステム１００内のＲＳＧ  １２０の特定のデプロイ（実例として、特定の分散アーキテクチャを使用する）に関して図示され、説明されるが、ＲＳＧ  １２０が、ＲＳＧ  １２０のさまざまな機能の集中化されたデプロイまたは分散されたデプロイを含むことができる任意の他の適切なデプロイを使用してクラウドシステム１００内で実現され得ることを了解されたい。
【００９１】
したがって、ＲＳＧ  １２０が、任意の適切な形でクラウドシステム１００に組み込まれ得ることを了解されたい。
【００９２】
一実施形態では、ＲＳＧ  １２０は、（１）その例示的実施形態が図７および８に関して図示され、説明される、１つまたは複数のコンピュートストアユニット（ＣＳＵ）から構成される仮想層、および（２）その例示的実施形態が図９に関して図示され、説明される、１つまたは複数のシステム制御ユニット（ＳＣＵ）から構成される物理層を使用して、クラウドシステム１００に組み込まれ得る。
【００９３】
図７は、図１のＲＳＧを実現する際の使用に適する自己信頼コンピュートストアユニット（ＣＳＵ）の一実施形態を示す。
【００９４】
ＣＳＵ  ７００は、クラウドシステム１００の分散バージョンの抽象基本構成要素である。ＣＳＵ  ７００は、ＣＳＵ  ７００がセキュアで回復可能であると期待する顧客１０２によって指定され得る。ＣＳＵ  ７００は、顧客１０２によってプロビジョニングされ得るさまざまなパラメータ（たとえば、ＳＬＡ  １０３、ＤＲＰ  １０５、ＱｏＳパラメータ、など）に基づいて制御され得る。顧客１０２は、関連情報（たとえば、分散クラウドシステムのトポロジ、分散クラウドシステムの支配するポリシルール、など）をもプロビジョニングすることができる。顧客ドメインが、１つまたは複数のＣＳＵ  ７００を含むことができることに留意されたい。顧客ドメインが複数のＣＳＵ  ７００を含む場合に、複数のＣＳＵ  ７００は、仮想分散コンピューティングマシンを形成するためにお互いと通信することができる。一実施形態では、ＲＳＧ  １２０は、ＣＳＵ  ７００が、示されるように自己信頼的であることを保証するために、各ＣＳＵ  ７００内に組み込まれる。
【００９５】
ＣＳＵ  ７００は、仮想計算機（ＶＭ）７１０、仮想ストレージボリューム（ＶＳＶ）７２０、仮想サブネットワークインターフェース（ＶＳＩ）７３０、仮想プローブ（ＶＰ）７４０、仮想信頼性／セキュリティガーディアン（ＶＲＳＧ）７５０、ＣＳＵコントローラ（ＣＣ）７６０、およびＣＳＵ仕様（ＣＳ）７７０を含む。
【００９６】
ＶＭ  ７１０は、ＣＳＵ  ７００のさまざまな機能を提供するように構成されたプロセッサおよび関連するメモリを含む。ＶＭ  ７１０は、性能および信頼性の複数のレベルについて構成された基本コンピュートエンジンとして使用され得る。
【００９７】
ＶＳＶ  ７２０は、ＣＳＵ  ７００にストレージを提供する。ＶＳＶ  ７２０は、データベース（１つまたは複数）、１つまたは複数のファイル、１つまたは複数のディスク、１つまたは複数のフラッシュメモリコンポーネント、など、ならびにそのさまざまな組合せのうちの１つまたは複数を含むことができる。
【００９８】
ＶＳＩ  ７３０は、クラウドシステム１００の他のＣＳＵ  ７００へのインターフェースを提供する（たとえば、ＶＭ  ７１０に関連する仮想メモリを共有するため、ＶＳＶ  ７２０内のストレージを共有するため、など）。ＶＳＩ  ７３０は、そのような共有能力を提供するためにセキュア接続をサポートすることができる。複数の関連するＶＳＩ  ７３０を介して通信する複数のＣＳＵ  ７００を使用する例示的な分散自己信頼クラウドシステムは、図８に関して図示され、説明される。
【００９９】
ＶＰ  ７４０は、ＣＳＵ  ７００の利用データ、信頼性データ、性能データ、およびセキュリティデータを収集する。
【０１００】
ＶＲＳＧ  ７５０は、それぞれＣＥ  １２２、ＳＥ  １２４、ＭＥ  １２６、およびＣＥ  １２８によって実行されるものとして図１−６に関して図示され、説明された構成機能、スケジューリング機能、監視機能、および制御機能を実行する、ＣＳＵ  ７００のＲＳＧ  １２０として動作するように構成される。ＶＲＳＧ  ７５０は、ＣＳＵ  ７００のコンポーネントを監視し、管理するようにも構成され得る（たとえば、ＶＲＳＧ  ７５０が実現されるＣＳＵ  ７００内および／または他のＶＲＳＧ  ７５０を有する他のＣＳＵ  ７００内での障害からの回復に関する回復アクションの実行を含めて、ＣＳＵ  ７００内のコンポーネントの回復を監視し、管理するために）。
【０１０１】
ＣＣ  ７６０は、ＣＳＵ  ７００の動作を管理するように構成される。ＣＣ  ７６０は、クラウドプロバイダと相互作用することができる。ＣＣ  ７６０は、ＶＲＳＧ  ７５０を介して仮想インフラストラクチャの状況を監視することもできる。ＣＣ  ７６０は、ＳＣＵと通信するように構成される。
【０１０２】
ＣＳ  ７７０は、ＣＳＵ  ７００に関連する属性を維持する（たとえば、ＣＰＵ要件、メモリ要件、ＶＳＶ  ７２０のストレージボリュームアタッチメント、ＶＳＩ  ７３０を介する他のＣＳＵ  ７００への接続、信頼性レベル、回復方式、障害などの条件の場合の挙動、スケーラビリティポリシ属性、ＱｏＳ属性、セキュリティ制約、性能制約、など、ならびにそのさまざまな組合せ）。ＣＳＵ  ７００内の要素の間のセキュリティがある場合があり、同様に、複数の自己信頼ＣＳＵ  ７００を含む分散クラウドシステムの場合に自己信頼ＣＳＵ  ７００の間のセキュリティがある場合があることに留意されたい。ＣＳ  ７７０は、プロビジョニングを介して属性に対する変更をサポートすることができる。
【０１０３】
本明細書で説明されるように、顧客ドメインは、任意の適切な個数のＣＳＵ  ７００を含むことができる。顧客ドメインが複数のＣＳＵ  ７００を含む一実施形態では、複数のＣＳＵ  ７００は、仮想分散コンピューティングマシンとして動作するように構成された分散自己信頼クラウドシステムを形成するためにお互いと通信することができる。１つのそのような実施形態では、複数のＣＳＵ  ７００のＶＲＳＧ  ７５０は、分散自己信頼クラウドシステムを形成するために複数のＣＳＵ  ７００のＶＳＩ  ７３０を介してお互いと通信することができる。一例が、図８に関して図示され、説明される。
【０１０４】
図８は、分散自己信頼クラウドシステムを形成するための顧客ドメイン内の図７の複数のＣＳＵの例示的デプロイを示す。
【０１０５】
図８に示されているように、顧客ドメイン８００は、３つのＣＳＵ  ７００１−７００３を含み、各ＣＳＵ  ７００は、図７のＣＳＵ  ７００に関して図示され、説明されたように実現される。
【０１０６】
３つのＣＳＵ  ７００は、通信ネットワーク８１０を介してお互いと通信するように構成される。より具体的には、ＣＳＵ  ７００のＶＲＳＧ  ７５０は、ＣＳＵ  ７００のそれぞれのＶＳＩ  ７３０を介して通信ネットワーク８１０にアクセスすることによって、お互いと通信するように構成される。一実施形態では、ＣＳＵ  ７００が、物理サーバ上で合併され、プラットフォームの関連するネットワーキングの必要性が、結果として強まる時に、ローカル通信は、仮想化され得（たとえば、ＣＳＵ  ７００の間の通信のすべてをプラットフォームの物理層に強制するのではなく）、この仮想化は、任意の適切な形で実現され得る（たとえば、物理スイッチのように振る舞うように構成されるが、プラットフォームに仮想化される１つまたは複数の仮想スイッチを使用して、または任意の他の適切な形で）。
【０１０７】
３つのＣＳＵ  ７００は、Ｒｅｌｉａｂｌｅ  Ａｄａｐｔｉｖｅ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｐｒｏｔｏｃｏｌ（ＲＡＤＰ）を使用してお互いと通信するように構成され得る。ＲＡＤＰは、３つのＣＳＵ  ７００がさまざまなタイプの情報（たとえば、信頼性データ、セキュリティデータ、性能データ、トポロジデータ、イベントデータ、など、ならびにそのさまざまな組合せのうちの１つまたは複数に関する情報）を交換することを可能にし、これによって、３つのＣＳＵ  ７００がアクションを調整することを可能にする。
【０１０８】
他の通信関連能力がサポートされ得ることに留意されたい。たとえば、一実施形態では、デフォルトネットワークは、同一サブネット上のＶＭ  ７１０の間で交換されることに制限される。たとえば、一実施形態では、ＶＳＶ  ７２０は、同一のＣＳＵ  ７００内の接続およびイメージングに関してのみ可視とすることができる。たとえば、一実施形態では、ＣＳＵ  ７００の間のＶＳＶ  ７２０からの情報の共有は、セキュアパスを介するトランスポートに制限される。
【０１０９】
この形で、クラウドプロバイダは、物理インフラストラクチャ１０１にまたがってクラウドサービスを効率的に分散させるために、通信ネットワーク８１０の到達範囲およびスケールを使用することができる。
【０１１０】
上で注記したように、ＲＳＧ  １２０は、１つまたは複数のＣＳＵ  ７００から構成される仮想層に加えて、１つまたは複数のＳＣＵから構成される物理層を使用してクラウドシステム１００に組み込まれ得る。
【０１１１】
図９は、図１のクラウドシステムの部分内でデプロイされた図１のＲＳＧを実現する際の使用に適するシステム制御ユニット（ＳＣＵ）の一実施形態を示す。
【０１１２】
図９に示されているように、単純化された物理インフラストラクチャ９００は、物理リソース部分９１０およびＳＣＵ  ９２０を含む。
【０１１３】
物理リソース部分９１０は、物理インフラストラクチャ９００の物理リソース９１１（図１に関して図示され、説明された物理インフラストラクチャ１０１の一部とすることができる）およびハイパーバイザ９１９を含む。
【０１１４】
物理リソース９１１は、コンピューティングリソース、メモリリソース、入出力リソース、ストレージリソース、など、ならびにそのさまざまな組合せを含むことができる。
【０１１５】
ハイパーバイザ９１９は、物理リソース９１１の管理機能を提供するように構成される。ハイパーバイザ９１９は、ＣＰＵ仮想化をサポートし、これによって、ＣＰＵが複数のオペレーティングシステムと共に共有されることを可能にする。ハイパーバイザ９１９は、さまざまな他の機能を提供することができる。
【０１１６】
ＳＣＵ  ９２０は、顧客ドメインのＣＳＵ（たとえば、図７のＣＳＵ  ７００のうちの１つまたは複数）を管理するＣＳＵ管理機能を提供するように構成される。ＳＣＵ  ９２０は、顧客ドメインのＣＳＵ  ７００のＣＣ（１つまたは複数）７６０と通信するように構成される。ＳＣＵ  ９２０は、仮想コンポーネントの作成／管理／削除、ＣＳＵ内相互作用およびＣＳＵ間相互作用について定義された接続性ポリシの管理、など、ならびにそのさまざまな組合せなどの機能を含むことができるＣＳＵ管理機能を実行するように構成される。
【０１１７】
ＳＣＵ  ９２０は、ホストマネージャ（ＨＭ）９２１、リソースマネージャ（ＲＭ）９２２、ストレージマネージャ（ＳＭ）９２３、物理信頼性／セキュリティガーディアン（ＰＲＳＧ）９２４、および物理プローブ（ＰＰ）９２５を含む。
【０１１８】
ＨＭ  ９２１は、特権を与えられた仮想計算機内の物理ホスト（たとえば、ホストＯＳ）上で動作し、物理ホスト上で発生するアクションを管理し、妥当性検査する。ＨＭ  ９２１は、物理ホストのさまざまなリソース（たとえば、コンピュート、ストレージ、ネットワーク、など）へのアクセスを調停することによって、お互いからおよびＳＣＵ  ９２０からのＣＳＵ  ７００の分離を実現する。ＨＭ  ９２１は、抽象仮想計算機を、物理ホストの基礎になるハイパーバイザ９１９に適当な構成データに変換する。ＨＭ  ９２１は、ホスティングされる仮想計算機によって要求される仮想ブロックデバイスを作成し、除去するためにＳＭ  ９２３と相互作用する。ＣＳＵ  ７００は、特殊なハードウェアを全く必要とせずに、単一の共有される物理ネットワーク上の仮想オーバーレイネットワークとして実現され得る。ネットワーク層は、仮想計算機帯域幅消費を制限し、優先順位を付けるためにリソース制御を提供する。
【０１１９】
ＳＣＵ  ９２０およびハイパーバイザ９１９は、クラウドシステムの物理インフラストラクチャへの仮想アプリケーショントポロジのマッピング（たとえば、図４および図５に関して図示され、説明された）を実行するために協力することができる。顧客１０２は、仮想計算機、仮想ストレージブロック、および仮想ネットワークの所望のトポロジを指定し、ここで、指定されるトポロジは、定義された制約のセットを満足すると期待される。制約は、許容される通信パターン、仮想計算機同一位置制約、ＱｏＳ制約、など、ならびにそのさまざまな組合せを含む。トポロジおよび制約の記述は、さまざまな条件（たとえば、負荷条件、障害条件、など）に応答して動的に変更され得る。顧客ドメインのＣＳＵ（１つまたは複数）７００は、変化する要件を満足するために自動的に適合することができる。ストレージ側では、サービスが負荷条件の下であってもデータスループットを維持することを可能にする、スケーラブルで永続的な暗号化されたストアがあることに留意されたい。
【０１２０】
図１−９に関して図示され、説明された自己信頼アーキテクチャは、その少なくとも一部が自己信頼アーキテクチャ内のサービス信頼性と関係がある可能性があるさまざまな他の能力および／または技術を利用し、かつ／または提供することができる。
【０１２１】
第１の能力は、自己信頼アーキテクチャの文脈内の障害モードおよび回復に関する。
【０１２２】
多くの場合に、自己信頼システムは、冗長性およびフォールトトレランスに関する。単一のコンポーネントは、１００％アップタイムを保証することができないので、アーキテクチャは、システム全体の可用性に影響せずに個々のコンポーネントが障害を発生することを可能にする。自己信頼動作は、分散システム内のシステムの、すべてではないとしても多くが、それが依存する他のシステムからの障害を許容することを期待する。
【０１２３】
一実施形態では、ＲＳＧ  １２０は、仮想レベルおよび物理レベルで、さまざまなタイプの障害を検出し、隔離し、これから回復する責任を負う。１つのそのような実施形態では、故障隔離は、クラウドシステム１００の物理インフラストラクチャ１０１の共有される性質に起因して、かなりの重要性を帯びる可能性がある。
【０１２４】
一実施形態では、次の障害タイプおよび関連する回復モードがサポートされ得る：（１）プロセス障害（たとえば、ローカルプロセスリセット／リスタート、別のＣＰＵ上でのプロセスリスタート、別の同一位置に配置されたブレード、シェルフ、コンテナ、および／またはＣＰＵ上でのプロセスリスタート、リモートＣＰＵ上でのプロセスリスタート、他）、（２）アプリケーション障害（たとえば、ローカルリスタート、別の：ＣＰＵ、ブレード、シェルフ、コンテナ、すべてがサーバを介する複数のプロセス、リモート、他）、（３）プロセッサ／ＣＰＵ障害（たとえば、ＣＰＵ、ブレード、シェルフ、コンテナ、サイトの障害、他）、および（４）ネットワーク障害（たとえば、リンク、ノード、などの障害、ネットワーク経路の周期的監査、他）。
【０１２５】
一実施形態では、故障の検出時に、物理ユニットは、即座に「隔離される」。セキュリティ境界は、凍結される。回復は、ＤＲＰ  １０５、クラウドシステム１００に関連するシステム状態情報、および／またはクラウドシステム１００に関連するポリシ／制約情報によって案内され得る。回復戦略は、事前に確立され得、あるいは、ＲＳＧ  １２０によって判断され得る。回復戦略がＲＳＧ  １２０によって判断される一実施形態では、ＲＳＧ  １２０は、１つまたは複数の要因（たとえば、信頼性のレベル、コスト、性能、セキュリティ考慮事項、など）に基づいて回復戦略を判断することができる。たとえば、プロセス障害からの回復の場合に、ＲＳＧ  １２０は、プロセスをローカルにリスタートする、プロセスを同一ブレード上の別のプロセッサ上でリスタートする、プロセスを同一シャシー内の異なるブレード上でリスタートする、プロセスを別のシェルフ内のブレード上でリスタートする、またはプロセスをリモートシェルフ内のブレード上でリスタートすると判断することができる。ＲＳＧ  １２０は、他のタイプの障害条件および関連する回復モードについて、他の決定を行うことができる。
【０１２６】
第２の能力は、自己信頼アーキテクチャの文脈内の先を見越したテスティングに関する。
【０１２７】
一実施形態では、先を見越したテスティングの目的は、実際に障害に耐えるためのシステムの用意を保証するために、インサービス弾力性テストおよびインサービス頑健性テストを周期的に実行することである。たとえば、先を見越したテスティングは、シミュレートされた条件の下で動作し続ける、クラウドシステム１００の能力を確認するために、さまざまな条件をシミュレートすることを含むことができる。たとえば、先を見越したテスティングは、高ストレス条件中に成功する、クラウドシステム１００の能力を確認するために、障害の間際条件のシミュレーションを含むことができる。
【０１２８】
一実施形態では、ＲＳＧ  １２０は、クラウドシステム１００が顧客への影響なしにこの一般的なタイプの障害に耐えることができることを保証するために、製品インスタンスをランダムにディスエーブルするテストを周期的に実行する。一実施形態では、ＲＳＧ  １２０は、サイレント障害を明らかにするために、先を見越した診断を実行する。一実施形態では、クラウドシステム１００の「無限のリソース」特徴は、ＲＳＧ  １２０が、はるかにより大きいスケールでアクティブなスタンバイ回復シナリオを行うことを可能にする。少なくともいくつかのそのような実施形態では、テストは、任意の適切なコンポーネント（たとえば、ＣＰＵ、メモリ、ストレージ、入出力、ネットワーク、など、ならびにそのさまざまな組合せ）をカバーするように設計され得る。
【０１２９】
一実施形態では、ＲＳＧ  １２０は、クラウドシステム１００の信頼性およびセキュリティを評価するために適合された１つまたは複数のインサービステストをサポートすることができる。たとえば、ＲＳＧ  １２０は、（１）複数のバージョンのネットワークドライバを使用し、ＯＳおよびドライバレベルのネットワークセッティングを微調整し、カーネルホットフィックスを入手し、インサービスで適用すること、（２）仮想化プロバイダを切り替え、ＴＣＰ／ＩＰホストモデルを変更すること、および（３）複数の地理位置で構成およびランタイムの問題についてチェックすることなど、インサービス構成テストを実行するように構成され得る。たとえば、ＲＳＧ  １２０は（１）障害および／または保守アクションをシミュレートし、回復アクションをトリガするために、プロセッサ、メモリ、ディスク、ネットワークポート、などをランダムにイネーブルし、ディスエーブルし、切断し、再接続すること、（２）プロセッサおよびデータベースに関するフェイルオーバテストを実行し、ＣＳＵ  ７００にまたがるデータの複数の冗長コピーがあることを保証し、Ｎ＋１冗長性をチェックすること、および（３）周期的なまたは不断のベースでセキュリティ攻撃を行うことなど、インサービスの破損テストおよびフェイルオーバテストを実行するように構成され得る。たとえば、ＲＳＧ  １２０は、普通でないアクティビティによって引き起こされる負荷の大きいスパイクに対抗する、クラウドシステム１００の能力を確認すること、および過渡的な障害のリップル効果に対抗する、クラウドシステム１００の能力を確認することなど、インサービスの負荷テストおよび容量テストを実行するように構成され得る。たとえば、ＲＳＧ  １２０は、（１）タイムアウトをチェックし、積極的なタイムアウトをセットし、フォールバックをチェックし、回復時間を確認すること、（２）サービス劣化をシミュレートし、アップストリームサービス応答を測定し、依存性障害をチェックするためにクライアント−サーバ通信層に人工的な遅延を誘導することなど、インサービスの遅延テストおよびタイムアウトテストを実行するように構成され得る。たとえば、ＲＳＧ  １２０は、（１）各インスタンスに対してヘルスチェックを実行し、不健全なインスタンスを検出するために健全性の外部サイン（たとえば、ＣＰＵ負荷）を監視し、トランザクション障害を明らかにするためにオンラインでテストを実行する（たとえば、不正な入力、順序はずれの項目、および類似する条件を使用する）こと、（２）ベストプラクティスを厳守しないサブシステムインスタンスを見つけるためにテストを実行すること、（３）未使用のリソースを検索し、それらが使用可能なリソースのプールに戻されることを保証すること、および（４）セキュリティ違反または脆弱性を見つけるためにテストを実行することなど、インサービスの監査テストおよびヘルスチェックテストを実行するように構成され得る。
【０１３０】
第３の能力は、自己信頼アーキテクチャの文脈内のデータ完全性／セキュリティおよびデータの機密性に関する。一般に、顧客１０２は、信頼性問題に起因するデータ消失に対して脆弱である。一実施形態では、ＲＳＧ  １２０を使用して、ＣＳＵ（１つまたは複数）７００のそれぞれは、（１）顧客をお互いから、（２）インフラストラクチャを顧客から、および（３）顧客をプロバイダ不正行為から保護する。セキュリティ障害は、リソースの一部が仮想化されていない、仮想化ソフトウェアがバグフリーではない、コードが束縛されていない状況、顧客がクラウドプロバイダインフラストラクチャまたは他の顧客のリソースの機密部分にアクセスすることを可能にする不正なネットワーク仮想化、という理由のうちの１つまたは複数について生じる可能性があることに留意されたい。
【０１３１】
第４の能力は、自己信頼アーキテクチャの文脈内のデータ可用性／非可用性に関する。
【０１３２】
多くの場合に、ソフトウェアアプリケーションおよび／またはデータが使用可能でない（たとえば、停止状態に起因して）時に、可用性が復元されるまで、仕事が遅くなるか、潜在的に停止されることすらあるように、ソフトウェアアプリケーションおよびデータは、仕事にとって非常に重要である。短期的には、そのような停止状態は、データ消失、従業員および顧客のフラストレーション、ならびに収入の損失をもたらす。長期的には、そのような停止状態は、仕事の全期間にわたって仕事に影響する可能性がある（かつ、失われたレコード、トランザクション、および／またはアカウンティングファイルは、仕事に規制違反の危険を負わせる可能性がある）。データが、多数の理由から使用不能になる可能性があり、これを、データが完全にアクセス可能である正常な状態（ＮＯＲＭＡＬ（正常）状態と表される）からデータが部分的に使用可能または使用不能である異常な状態への遷移を要約する状態図を使用して表すことができることを了解されたい。たとえば、そのような異常な状態は、システムが、セキュリティ攻撃に起因してハッキングされた時（ＨＡＣＫＥＤ（ハックド）状態と表される）、オペレータエラーまたはプログラム欠陥に起因して破壊される時（ＣＯＲＲＵＰＴ／ＣＯＭＰＲＯＭＩＳＥＤ（破壊／欠陥）状態と表される）、失われた暗号化鍵に起因して使用不能になる時（ＣＯＲＲＵＰＴ／ＣＯＭＰＲＯＭＩＳＥＤ状態と表される）、または計画された保守アクションを受ける時（ＭＡＩＮＴＥＮＡＮＣＥ（保守）状態と表される）に生じる可能性がある。
【０１３３】
一実施形態では、ＲＳＧ  １２０は、顧客データ可用性が危険にさらされないことを保証するために、顧客データを保護するように構成される。ＲＳＧ  １２０は、監査、インサービステスト、データ修理、など、ならびにそのさまざまな組合せのうちの１つまたは複数を介して顧客データを保護することができる。データバックアップ方式およびストレージ方式は、しばしば、災害復旧計画の主要コンポーネントであることに留意されたい。一実施形態では、顧客データは、必要に応じて簡単に自動的に移動され得る。一実施形態では、顧客データは、データを同期状態に保つ複数の位置での顧客データの複数のコピーのストレージを介して復元され得る。一実施形態では、データ復元戦略は、特定のタイプの条件について指定され得る（たとえば、ファイル障害、データベース障害、またはディスク障害の場合には、（１）ファイルスナップショットがとられ、ファイルが保存され、バックアップされる、コールドバックアップ方式、（２）リソースが顧客のために予約されるウォームバックアップ方式、（３）リモートサイトの同期化されたリソースによって管理されるデータの複製を用いるホットバックアップ方式（たとえば、停止の場合には、二重の代替フェイルオーバサイトが即座に引き継ぐ）というデータ復元戦略のうちの１つまたは複数が使用され得る。
【０１３４】
第５の能力は、自己信頼アーキテクチャの文脈内のエラーハンドリングおよびアラームハンドリングに関する。
【０１３５】
一実施形態では、ＲＳＧ  １２０は、顧客サービスが影響を受ける前に、ＣＳＵ  ７００およびＳＣＵ  ９２０上の異常な挙動の早期検出のために能動的監視を実行するように構成される。
【０１３６】
一実施形態では、ＶＲＳＧ  ７５０は、問題を分析し、関連する予防制御アクションを決定するように構成される。１つのそのような実施形態では、ＶＲＳＧ  ７５０は、ＣＳＵ  ７００のコンポーネントが異常イベントを検出し、回復する時に生じるアラートの受取に応答して、そのような機能を実行するように構成される。
【０１３７】
一実施形態では、ＶＲＳＧ  ７５０は、さまざまな制御機能（たとえば、故障の制御、フィルタリング、分析、など、ならびにそのさまざまな組合せ）を提供するために、さまざまなタイプの入力情報を処理するように構成される。
【０１３８】
ＶＲＳＧ  ７５０は、さまざまな制御機能を提供するために各ＣＳＵ  ７００に関する情報を処理することができる。クラウドシステム１００は、その動作の過程において、任意のまたはすべてのレベル（たとえば、物理ＳＣＵレベル、仮想ＣＳＵレベル、ネットワークレベル、サービスレベル、などのうちの１つまたは複数）で、異常イベント（たとえば、アラート、アラーム、など）を生成するように構成される。クラウドシステム１００は、さまざまなタイプの性能データを収集するようにも構成される。監視されるイベント変数の値は、異常な条件に達したかどうかを決定するために、しきい値が定められうる。少なくともいくつかの場合に、フィルタリング判断基準が、適用され、判断基準を満足する変数が、記録される（たとえば、ログファイルに）。すべての時間間隔に記録される、有限個数のイベント変数があることを了解されたい。イベント変数は、関連するコンポーネントの挙動を取り込み、イベント処理に関する追加の文脈を提供する。たとえば、イベント変数は、拡大された機能エラー、回復されたトラップ／例外、総ＣＰＵ利用、総メモリ利用、打ち切られたトランザクション、プロセスリスタート、エラーになった送信ＴＰＤＵ、エラーになった受信ＴＰＤＵ、発生したトランスポートタイムアウト、サニティタイムアウトの回数、ブレードリスタート、フェイルオーバの回数、ディスクアクセス障害、ファイルアクセス障害、ディスク使用量、およびクリティカルアラームの個数を含むことができる。上で注記したように、ＶＲＳＧ  ７５０は、さまざまな制御機能を提供するために、各ＣＳＵ  ７００に関するこの情報を処理するように構成される。
【０１３９】
ＶＲＳＧ  ７５０は、複数のソース（たとえば、ＣＳＵ  ７５０のコンポーネントからの障害の自律的レポート、顧客およびピアＶＲＳＧ  ７５０からのトラブルレポート、ＶＲＳＧ  ７５０からの診断／エクササイズ／監査の結果、（４）性能マネージャからの減損表示、構成マネージャからのネットワーク構成データ、など、ならびにそのさまざまな組合せ）から情報を受け取り、処理することができる。ＶＲＳＧ  ７５０は、この情報を統合し、故障の制御、フィルタリング、分析、などの機能を提供するように構成される。ＶＲＳＧ  ７５０によるそのような処理の結果として、障害を発生したインフラストラクチャリソースが、認識され、故障のルート原因が、識別され、修理アクションが、配置され、スケジューリングされ、障害を発生したリソースが、サービスに戻される。
【０１４０】
ＶＲＳＧ  ７５０およびＰＲＳＧ  ９２４は、イベント通知を受け取るように構成される。アラートおよびアラームの収集は、そのうちの少なくともいくつかがＣＳＵ  ７００（ＶＲＳＧ  ７５０に関して）およびＳＣＵ  ９２０（ＰＲＳＧ  ９２４に関して）によって指定される判断基準に基づいてローカルホスト内でハンドリングされる、ハードウェアイベントおよび／またはソフトウェアイベントを含むことができる。一実施形態では、イベント通知は、条件が対処されていても、ＶＲＳＧ  ７５０およびＰＲＳＧ  ９２４に送られる。このように、ヒストリ情報が、シグネチャ分析および可能な予防アクションの決定のために維持され得る。ソフトウェアエラーの場合に、エラーの大多数が、しばしば例外ハンドラによって解決されるので、比較的少数のそのようなエラーだけが、回復不能な例外につながることに留意されたい。さらに、少なくともいくつかのアクションは、ホスト計算機によってローカルに実行され、その場合に、ＶＲＳＧ  ７５０およびＰＲＳＧ  ９２４は、単に、行われたアクションについて知らされ得る。
【０１４１】
第６の能力は、自己信頼アーキテクチャの文脈内の信頼性およびスケーラブルストレージに関する。多くの場合に、スケール目標およびコスト目標を満足するために、クラウドシステムは、複数の地理的に分散されたデータセンタにまたがって分散されたコモディティサーバ、ディスク、およびネットワークのクラスタから作られる。多数の障害シナリオが、そのような環境で可能である（たとえば、ディスク障害、ネットワーク停止、配電停止、災害、など）ことに留意されたい。結果として、ストレージ障害からの回復は、いくつかのケースで基礎になるストレージシステムのセマンティックスが知られていない場合に、クラウドアプリケーションの開発者にとってむずかしいものになる可能性がある。たとえば、データ不一致につながる障害条件は、部分的書込、ストレージノードクラッシュ、ネットワークパーティション、複数サイトでの複数のリーダ／ライタ、などを含む。一実施形態として、顧客は、異なるコスト、能力、信頼性のトレードオフを成立させるために、異なる符号化を指定することができる。たとえば、一時的な簡単に再作成されるデータは、最小の冗長性およびコストで格納され得、アーカイブデータは、信頼性を改善するために広く散在され得、ストレージは、最終的な一貫性セマンティクスを提供することができるなどである。一実施形態では、ストレージシステムは、異なる動作条件の下で異なるタイプの冗長性および一貫性（たとえば、データの複製、ＲＡＩＤ、消去訂正符号（ｅｒａｓｕｒｅ  ｃｏｄｉｎｇ）、など）を提供することができる。
【０１４２】
第７の能力は、自己信頼アーキテクチャの文脈内の性能および過負荷に関する。多くの場合に、サービスの需要は、時間に伴って変化し、これによって、性能が予測不能になることをもたらす。データセンタの動作時間の小さいパーセンテージの間にのみ維持されるピーク負荷条件のためのデータセンタのプロビジョニングは、データセンタリソースの利用をもたらすことを了解されたい。その結果、従量課金方式（たとえば、コンピューティングリソースについて１時間ごとに支払う）が、好まれる可能性がある。しかし、従量課金方式は、それに関連する問題をも有する可能性がある（たとえば、需要が前もって知られていない（たとえば、初めに大きいスパイクがあり、これに定常トラフィックが続く場合がある）、クラウドを介して購入される時間が、時間において不均一に変化する可能性があるなど）。さらに、多くのサービスは、需要の季節変動または周期的変動（たとえば、１２月のｅコマース、ニュースイベントに起因する予期されない需要、など）をも経験する。さらに、性能劣化は、障害、過負荷、または設計に起因する場合がある（たとえば、計画され制御された過負荷ポリシ制御、トラフィック過負荷、ＶＭの間の入出力性能の変動、ＶＭの間の入出力干渉、など、ならびにそのさまざまな組合せに起因するトランザクション可用性の消失）。
【０１４３】
第８の能力は、自己信頼アーキテクチャの文脈内の電力管理およびハードウェア寿命に関する。いくつかの場合に、データセンタは、多数のサーバ上に多数のユーザを有する場合がある（たとえば、数百万人のユーザをサポートする数千台のサーバ）。多くのそのような場合に、電力および冷却は、主要な問題および出費である。一実施形態では、インフラストラクチャのさまざまな部分は、ソフトウェアスタック、スケーラブルストレージ、高密度ブレードを有するサーバブロック、フラッシュベースの不揮発性メモリを有する非集約メモリブレード（ｄｉｓａｇｇｒｅｇａｔｅｄ  ｍｅｍｏｒｙ  ｂｌａｄｅ）、クロスレイヤ電力管理、など、ならびにそのさまざまな組合せの使用を介してより効率的にされ得る。一実施形態では、ハードウェア寿命は、顧客の不満の最も一般的な原因のうちの１つを防ぐか遅延させる自動化されたディスクデフラグメンテーションなどのソフトウェア戦略を介して延長され得る。
【０１４４】
第９の能力は、自己信頼アーキテクチャの文脈内のシステム可用性およびビジネス継続性に関する。継続性は、単一の会社によるクラウドコンピューティングサービスの管理が、単一故障点である（たとえば、異なる位置の複数のデータセンタを有する場合であっても、その会社は、共通のソフトウェアインフラストラクチャ、アカウンティング、および他の共通の要素および能力を有する）ので、別の要因であることに留意されたい。一実施形態では、ビジネス継続性戦略がサポートされる。１つのそのような実施形態では、ほとんどの場合に、データが、真のビジネス継続性および災害復旧計画の唯一のコンポーネントなので、ビジネス継続性戦略は、データ回復以上のものを指定することができる。
【０１４５】
主に別々の能力と同程度に独立に説明されるが、そのような能力のさまざまな組合せが、さまざまな機能を提供するために一緒に使用され得ることに留意されたい。
【０１４６】
図１０は、クラウドシステムの顧客に信頼性を提供する方法の一実施形態を示す。方法１０００のさまざまなステップは、本明細書で図示され、説明された図１から図９の関連部分に関連して考慮される時によりよく理解され得ることに留意されたい。
【０１４７】
ステップ１０１０では、方法１０００が開始する。
【０１４８】
ステップ１０２０では、顧客のＤＲＰが受け取られる。顧客は、クラウドシステムを管理するクラウドプロバイダの顧客とすることができる。
【０１４９】
ステップ１０３０では、顧客のクラウドリソースの構成が、顧客のＤＲＰに基づいて決定される。
【０１５０】
ステップ１０４０では、クラウドリソースが、クラウドリソースの決定された構成を使用して、顧客のために構成される。
【０１５１】
ステップ１０５０では、クラウドシステムが、条件および／または潜在的な条件について監視される。
【０１５２】
ステップ１０６０では、１つまたは複数の条件が検出されたかどうかに関する決定が行われる。条件が検出されなかった場合には、方法１０００は、ステップ１０５０に戻る（すなわち、条件および／または潜在的な条件に関するクラウドシステムの監視が継続する）。条件が検出された場合には、方法１０００は、ステップ１０７０に進む。
【０１５３】
ステップ１０７０では、１つまたは複数のアクションが、検出された条件（１つまたは複数）に基づいて開始される。ステップ１０７０から、方法１０００は、ステップ１０５０に戻る（すなわち、条件および／または潜在的な条件に関するクラウドシステムの監視が継続する）。
【０１５４】
クラウドシステム内では、信頼性が、単に考慮すべき１つのコンポーネントである（たとえば、考慮され得る他のコンポーネントは、性能、セキュリティ、コスト、などを含む）ことに留意されたい。したがって、主にクラウドシステムの信頼性態様および可用性態様の考慮に関して本明細書で図示され、説明されるが、クラウドシステムの信頼性態様および可用性態様の改善に関して本明細書で図示され、説明されるさまざまな原理、能力、および機能が、１つまたは複数のそのような他の考慮事項（たとえば、性能、セキュリティ、コスト、など）をハンドリングするために拡張され得ることを了解されたい。
【０１５５】
本明細書では主にクラウドシステムの文脈内で図示され、説明されるが、本明細書で図示され、説明されるさまざまな能力および機能が、他の環境での使用のために適合され得ることに留意されたい。たとえば、本明細書でクラウドシステムの文脈内で図示され、説明されるさまざまな能力および機能は、マシントゥーマシン環境、スマート計測環境、などでの使用のために適合され得る。
【０１５６】
図１１は、本明細書で説明される機能を実行する際の使用に適するコンピュータの高水準ブロック図を示す。
【０１５７】
図１１に示されているように、コンピュータ１１００は、処理要素１１０２（たとえば、中央処理装置（ＣＰＵ）および／または他の適切なプロセッサ（１つまたは複数））およびメモリ１１０４（たとえば、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、など）を含む。コンピュータ１１００は、協力するモジュール／プロセス１１０５および／またはさまざまな入出力デバイス１１０６（たとえば、ユーザ入力デバイス（キーボード、キーパッド、マウス、など）、ユーザ出力デバイス（ディスプレイ、スピーカ、など）、入力ポート、出力ポート、受信器、送信器、およびストレージデバイス（たとえば、テープドライブ、フロッピドライブ、ハードディスクドライブ、コンパクトディスクドライブ、など））をも含むことができる。
【０１５８】
本明細書で図示され、説明される機能が、ソフトウェアで実現され得（たとえば、１つまたは複数のプロセッサ上でのソフトウェアの実現を介して）、かつ／またはハードウェアで実現され得る（たとえば、汎用コンピュータ、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）、および／または任意の他のハードウェア同等物を使用して）ことを了解されたい。
【０１５９】
本明細書で図示され、説明される機能が、ソフトウェアで実現され得（たとえば、特殊目的コンピュータを実現するために汎用コンピュータ上で実行される（たとえば、１つまたは複数のプロセッサによる実行を介して））、かつ／またはハードウェアで実現され得る（たとえば、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）および／または１つもしくは複数の他のハードウェア同等物を使用して）ことを了解されたい。
【０１６０】
一実施形態では、協力するプロセス１１０５は、本明細書で議論される機能を実現するために、メモリ１１０４にロードされ、プロセッサ１１０２によって実行され得る。したがって、協力するプロセス１１０５（関連するデータ構造を含む）は、コンピュータ可読記憶媒体、たとえば、ＲＡＭメモリ、磁気または光学的なドライブまたはディスケット、などに記憶され得る。
【０１６１】
図１１に示されたコンピュータ１１００が、本明細書で説明される機能要素および／または本明細書で説明される機能要素の諸部分を実現するのに適する全般的なアーキテクチャおよび機能性を提供することを了解されたい。たとえば、コンピュータ１１００は、本明細書で図示され、説明されるさまざまな物理リソース、モジュール、ユニット、要素、コンポーネント、などのうちの１つまたは複数を実現するのに適する全般的なアーキテクチャおよび機能性を提供する。
【０１６２】
本明細書でソフトウェア方法として議論されるステップの一部が、ハードウェア内で、たとえば、さまざまな方法ステップを実行するためにプロセッサと協力する回路網として、実現され得ることが企図されている。本明細書で説明される機能／要素の諸部分は、コンピュータプログラム製品として実現され得、コンピュータ命令は、コンピュータによって処理される時に、本明細書で説明される方法および／または技法が呼び出されるか他の形で提供されるように、コンピュータの動作を適合させる。発明的方法を呼び出す命令は、固定媒体またはリムーバブル媒体に記憶され、放送媒体または他の信号担持媒体内のデータストリームを介して伝送され、かつ／または命令に従って動作するコンピューティングデバイス内のメモリ内に記憶され得る。
【０１６３】
さまざまな実施形態の諸態様は、特許請求の範囲で指定される。さまざまな実施形態のそれらおよび他の態様は、次の番号付きの節で指定される。
【０１６４】
１．プロセッサおよびメモリであって、プロセッサが、
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取り、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定する
ように構成される、プロセッサおよびメモリ
を含む装置。
【０１６５】
２．ＤＰＲが、顧客に関連するサービスレベルアグリーメント（ＳＬＡ）の一部として指定されるように構成される、節１に記載の装置。
【０１６６】
３．クラウドリソースが、コンピューティングリソース、メモリリソース、入出力リソース、ストレージリソース、およびネットワークリソースのうちの少なくとも１つを含む、節１に記載の装置。
【０１６７】
４．プロセッサが、
顧客アプリケーション情報とクラウドプロバイダのクラウドシステムに関連するクラウドシステム情報とを使用して顧客の仮想アプリケーショントポロジを決定することと、
顧客の仮想アプリケーショントポロジとクラウドシステムに関連するクラウドシステム情報とを使用して信頼性マップを決定することと、
信頼性マップとクラウドシステムに関連するクラウドシステム情報とを使用してクラウドリソースの構成を決定することと
によって、ＤＲＰに基づいて顧客のクラウドリソースの構成を決定するように構成される、節１に記載の装置。
【０１６８】
５．クラウドシステム情報が、クラウドシステムに関連する現在のシステム状況情報と、ポリシ情報および制約情報のうちの少なくとも１つとを含む、節４に記載の装置。
【０１６９】
６．信頼性マップが、アプリケーションコンポーネントのそれぞれの信頼性の必要性およびアプリケーションコンポーネントの間の少なくとも１つの関係に関してアプリケーションの複数のアプリケーションコンポーネントを表すように構成された信頼度ブロック図（ＲＢＤ）として表される、節４に記載の装置。
【０１７０】
７．プロセッサが、複数の時間期間のそれぞれでの顧客のクラウドリソースの構成を決定するように構成される、節１に記載の装置。
【０１７１】
８．プロセッサが、
ＤＲＰ内で指定される信頼性パラメータが満足されつつあるかどうかを決定するためにクラウドリソースの挙動を監視し、
ようにさらに構成される、節１に記載の装置。
【０１７２】
９．プロセッサが、
ＤＲＰ内で指定される信頼性パラメータを満足するためのクラウドリソースの挙動を計測する
ようにさらに構成される、節１に記載の装置。
【０１７３】
１０．プロセッサが、
仮想構成を生成するために顧客に関連するＤＲＰを処理し、
仮想構成をクラウドリソースにマッピングするように構成されたスケジューリングエンジンに仮想構成を提供する
ように構成された構成エンジンを提供するように構成される、節１に記載の装置。
【０１７４】
１１．プロセッサが、
顧客に関連するＤＲＰを満足する仮想構成を受け取り、
仮想構成をクラウドリソースにマッピングする
ように構成されたスケジューリングエンジンを提供するように構成される、節１に記載の装置。
【０１７５】
１２．プロセッサが、
クラウドプロバイダのクラウドシステムに関連するシステム状況情報とクラウドプロバイダによって指定されるポリシ情報および制約情報のうちの少なくとも１つとを使用して、信頼性完全性メーターとクラウドシステムのクラウドリソースを制御する際の使用のために構成された制御情報とのうちの少なくとも１つを生成する
ように構成された監視エンジンを提供するように構成される、節１に記載の装置。
【０１７６】
１３．監視エンジンが、
クラウドシステムの物理インフラストラクチャに関連するイベントを受け取り、集約するように構成された集約エンジンと、
クラウドシステムに関連するシステム状況情報を形成するために、集約されたイベントを相関させるように構成された相関分析エンジンと、
信頼性完全性メーターおよびクラウドシステムのクラウドリソースを制御する際の使用のために構成された制御情報のうちの少なくとも１つを生成するために、クラウドシステムに関連するシステム状況情報とクラウドシステムのクラウドプロバイダによって指定されるポリシ情報および制約情報のうちの少なくとも１つとを処理するように構成された処理エンジンと
を含む、節１２に記載の装置。
【０１７７】
１４．信頼性完全性メーターが、システム状況情報とシステム状況情報から導出されたメトリックとのうちの少なくとも１つを含む、節１２に記載の装置。
【０１７８】
１５．クラウドシステムのクラウドリソースを制御する際の使用のために構成された制御情報が、クラウドシステム内の少なくとも１つの条件に反応するように構成された反応制御情報と、少なくとも１つの条件がクラウドシステム内で発生するのを防ぐように構成された予測予防制御情報とのうちの少なくとも１つを含む、節１２に記載の装置。
【０１７９】
１６．プロセッサが、
クラウドリソースを制御する際の使用のために構成された制御情報を受け取り、
制御情報を使用して、クラウドリソースの少なくとも一部を変更するように構成された少なくとも１つのフィードバックアクションを生成する
ように構成された制御エンジンを提供するように構成される、節１に記載の装置。
【０１８０】
１７．プロセッサが、コンピュートストアユニット（ＣＳＵ）をサポートするように構成され、ＣＳＵが、
仮想プロセッサおよびメモリリソースを含む仮想計算機と、
仮想ストレージリソースを含む仮想ストレージボリュームと、
少なくとも１つの他のＳＣＵとの少なくとも１つのセキュア接続をサポートするように構成された仮想サブネットワークインターフェースと、
ＣＳＵの要素の回復を管理することと、
信頼性データ、セキュリティデータ、性能データ、トポロジデータ、およびイベントデータのうちの少なくとも１つを少なくとも１つの他のＣＳＵと交換する
のうちの少なくとも１つを実行するように構成された仮想信頼性／セキュリティガーディアン（ＶＲＳＧ）と、
ＣＳＵの利用データ、信頼性データ、性能データ、およびセキュリティデータのうちの少なくとも１つを収集するように構成された仮想プローブと、
ＣＳＵを管理するように構成されたコントローラと、
ＣＳＵの複数の属性を含むＣＳＵ仕様と
のうちの少なくとも１つを含む、節１に記載の装置。
【０１８１】
１８．プロセッサが、物理ホスト上に配置され、プロセッサが、物理ホストのシステム制御ユニット（ＳＣＵ）をサポートするように構成され、ＳＣＵが、
物理ホスト上のアクションの管理、物理ホスト上で使用されるコンピュートストアユニット（ＣＳＵ）の作成および削除、ならびに物理ホスト上のＣＳＵと少なくとも１つの他の物理ホスト上のＣＳＵとの間のセキュア通信の実現のうちの少なくとも１つを実行するように構成されたホストマネージャ（ＨＭ）と、
物理ホスト上のリソースを管理するように構成されたリソースマネージャ（ＲＭ）と、
物理ホスト上のストレージを管理するように構成されたストレージマネージャ（ＳＭ）と、
物理ホスト上のＣＳＵを監視し、その回復を管理するように構成された物理信頼性／セキュリティガーディアン（ＰＲＳＧ）と、
物理ホストに関連する利用データ、信頼性データ、性能データ、およびセキュリティデータのうちの少なくとも１つを収集するように構成された物理プローブと
のうちの少なくとも１つを含む、節１に記載の装置。
【０１８２】
１９．コンピュータによって実行される時に、コンピュータに、
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取ることと、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することと、
を含む方法を実行させる命令を記憶するコンピュータ可読記憶媒体。
【０１８３】
２０．クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取り、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定する
のにプロセッサを使用すること
を含む方法。
【０１８４】
本発明の教示を組み込むさまざまな実施形態が、本明細書で詳細に図示され、説明されたが、当業者は、これらの教示を組み込む多数の他の変更された実施形態をたやすく考案することができる。
【図１】
2014532246.tif 000003
【図２】
2014532246.tif 000004
【図３】
2014532246.tif 000005
【図４】
2014532246.tif 000006
【図５】
2014532246.tif 000007
【図６】
2014532246.tif 000008
【図７】
2014532246.tif 000009
【図８】
2014532246.tif 000010
【図９】
2014532246.tif 000011
【図１０】
2014532246.tif 000012
【図１１】
2014532246.tif 000013
【手続補正書】
【提出日】平成26年6月10日(2014.6.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
プロセッサおよびメモリであって、プロセッサが、
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取り、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定する
ように構成され、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定するために、プロセッサが、
顧客のＤＲＰに基づいて顧客の仮想トポロジを決定し、
顧客の仮想トポロジに基づいて信頼性マップを決定し、
信頼性マップに基づいて顧客のクラウドリソースの構成を決定する
ように構成される、プロセッサおよびメモリ
を含む、装置。
【請求項２】
プロセッサが、
クラウドプロバイダのクラウドシステムに関連するクラウドシステム情報に基づいて、顧客の仮想トポロジを決定し、
クラウドシステムに関連するクラウドシステム情報に基づいて、信頼性マップを決定し、
クラウドシステムに関連するクラウドシステム情報に基づいて、クラウドリソースの構成を決定する
ように構成される、請求項１に記載の装置。
【請求項３】
プロセッサが、複数の時間期間のそれぞれでの顧客のクラウドリソースの構成を決定するように構成される、請求項１に記載の装置。
【請求項４】
プロセッサが、
顧客のＤＲＰ内で指定される信頼性パラメータが満足されつつあるかどうかを決定するためにクラウドリソースの挙動を監視し、
顧客のＤＲＰ内で指定される信頼性パラメータを満足するためのクラウドリソースの挙動を計測する
ようにさらに構成される、請求項１に記載の装置。
【請求項５】
プロセッサが、
顧客の仮想構成を生成するために顧客のＤＲＰを処理し、
顧客のクラウドリソースの構成をこれによって提供するために、仮想構成をクラウドプロバイダのクラウドリソースにマッピングするように構成されたスケジューリングエンジンに顧客の仮想構成を提供する
ように構成された構成エンジンを提供するように構成される、請求項１に記載の装置。
【請求項６】
プロセッサが、
顧客の仮想構成を受け取り、顧客の仮想構成は顧客のＤＲＰを満足し、
顧客のクラウドリソースの構成をこれによって提供するために、顧客の仮想構成をクラウドプロバイダのクラウドリソースにマッピングする
ように構成されたスケジューリングエンジンを提供するように構成される、請求項１に記載の装置。
【請求項７】
プロセッサが、
クラウドプロバイダのクラウドシステムに関連するシステム状況情報とクラウドプロバイダによって指定されるポリシ情報および制約情報のうちの少なくとも１つとを使用して、信頼性完全性メーターとクラウドシステムのクラウドリソースを制御する際の使用のために構成された制御情報とのうちの少なくとも１つを生成する
ように構成された監視エンジンを提供するように構成される、請求項１に記載の装置。
【請求項８】
プロセッサが、
クラウドリソースを制御する際の使用のために構成された制御情報を受け取り、
制御情報を使用して、クラウドリソースの少なくとも一部を変更するように構成された少なくとも１つのフィードバックアクションを生成する
ように構成された制御エンジンを提供するように構成される、請求項１に記載の装置。
【請求項９】
コンピュータによって実行される時に、コンピュータに、
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取ることと、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することと
を含む方法であって、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することが
顧客のＤＲＰに基づいて顧客の仮想トポロジを決定することと、
顧客の仮想トポロジに基づいて信頼性マップを決定することと、
信頼性マップに基づいて顧客のクラウドリソースの構成を決定することと
を含む、方法を実行させる命令を記憶する、コンピュータ可読記憶媒体。
【請求項１０】
クラウドプロバイダの顧客に関連する動的信頼性プロファイル（ＤＲＰ）であって、時間と顧客のアプリケーションまたはサービスの要件との両方の関数として顧客の信頼性パラメータを指定するＤＲＰを受け取ることと、
顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することであって、顧客のＤＲＰに基づいて顧客のクラウドリソースの構成を決定することは
顧客のＤＲＰに基づいて顧客の仮想トポロジを決定することと、
顧客の仮想トポロジに基づいて信頼性マップを決定することと、
信頼性マップに基づいて顧客のクラウドリソースの構成を決定することと
を含む、決定することと
のためにプロセッサおよびメモリを使用すること
を含む、方法。
【国際調査報告】
2014532246.tif 000014
2014532246.tif 000015