(57)【要約】  様々な実施形態は、迅速な弾力性、たとえばソフトウェア／ファームウェア／ハードウェアのアップグレード、更新、改良、および増大などのインフラストラクチャの保守、ならびに、たとえばファンフィルタのクリーニングおよび障害のあるハードウェアコンポーネントの置換などの予防保守をサポートするルールを提供するクラウドベースアプリケーションのＳＰＯＦ排除を提供する方法および装置を提供する。具体的には、本方法および装置によって提供されるＳＰＯＦ排除は、インスタンスマッピングをホストするためのＶＭに加えて、ネットワークアーキテクチャおよび持続的なストレージに関する考慮事項に基づく。
2015522876.tif 000002
【特許請求の範囲】
【請求項１】
単一障害点の排除を提供するための装置であって、
データストレージと、
データストレージに通信可能に接続されたプロセッサとを備え、プロセッサが、
１つまたは複数のアプリケーションリソース要件を決定し、
リソースプール、およびリソースプールに関連付けられるネットワークアーキテクチャを決定し、
１つまたは複数のルールを決定し、
１つまたは複数のアプリケーションリソース要件、リソースプール、ネットワークアーキテクチャ、および１つまたは複数のルールに基づいて、１つまたは複数のコンポーネントインスタンスの配布を決定するように構成される、単一障害点の排除を提供するための装置。
【請求項２】
ネットワークアーキテクチャがリンクおよびネットワークノードを含み、
プロセッサが、
リンクおよびノードのうちの１つまたは複数のネットワークステータスを決定するようにさらに構成され、
１つまたは複数のコンポーネントインスタンスの配布の決定が、ネットワークステータスにさらに基づく、請求項１に記載の装置。
【請求項３】
１つまたは複数のアプリケーションリソース要件が、リソースプールのメンバーである１つまたは複数のリソースの現在の割当てと、アプリケーションに関連付けられる１つまたは複数の現在のアプリケーションリソース要件とを含む、請求項１に記載の装置。
【請求項４】
１つまたは複数のルールが、１つまたは複数のアンチアフィニティルールを含む、請求項１に記載の装置。
【請求項５】
１つまたは複数のルールが、１つまたは複数のビジネスルールをさらに含み、
１つまたは複数のビジネスルールが、保守活動のためのリソースプール内のリソースの一部の確保を含む、請求項４に記載の装置。
【請求項６】
１つまたは複数のコンポーネントインスタンスの配布の決定が障害点のセットにさらに基づく、請求項１に記載の装置。
【請求項７】
単一障害点の排除を提供するための方法であって、
データストレージに通信可能に接続されたプロセッサで、配布トリガが発生したことを決定するステップと、
データストレージと協働するプロセッサによって、１つまたは複数のアプリケーションリソース要件を決定するステップと、
データストレージと協働するプロセッサによって、リソースプール、およびリソースプールに関連付けられるネットワークアーキテクチャを決定するステップと、
データストレージと協働するプロセッサによって、１つまたは複数のルールを決定するステップと、
データストレージと協働するプロセッサによって、配布トリガ、１つまたは複数のアプリケーションリソース要件、リソースプール、ネットワークアーキテクチャ、および１つまたは複数のルールに基づいて、１つまたは複数のコンポーネントインスタンスの配布を決定するステップとを備える、単一障害点の排除を提供するための方法。
【請求項８】
配布トリガが、リソースプール内の１つまたは複数のリソースから、コンポーネントインスタンスの少なくとも一部を移行することに基づく、請求項７に記載の方法。
【請求項９】
データストレージと協働するプロセッサによって、１つまたは複数のリンクあるいはネットワークノードのネットワークステータスを決定するステップをさらに含み、
ネットワークアーキテクチャが、１つまたは複数のリンクあるいはネットワークノードを備え、
１つまたは複数のコンポーネントインスタンスの配布を決定するステップが、ネットワークステータスにさらに基づく、請求項７に記載の方法。
【請求項１０】
ネットワークアーキテクチャが第１のネットワークデバイスを備え、１つまたは複数のコンポーネントインスタンスの配布を決定するステップが、
第１のネットワークデバイスの障害が、１つまたは複数のアンチアフィニティルールのうちの少なくとも１つに違反するであろうと決定するステップに基づいて、１つまたは複数のコンポーネントインスタンスのうちの第１のコンポーネントインスタンスが、リソースプール内の第１のリソースに関連付けられていない可能性があることを決定するステップを含む、請求項７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、クラウドベースアプリケーションの単一障害点の排除を提供するための方法および装置に関する。
【背景技術】
【０００２】
このセクションは、本発明のより良い理解を容易にするために役立つと思われる態様を紹介する。したがって、このセクションの記述はこの観点から読まれるべきであり、従来技術にあるもの、または従来技術にはないものについての承認として理解されるべきではない。
【０００３】
いくつかの知られている高可用性システムでは、ネットワークアーキテクチャは、供給されるネットワーク内にいかなる単一障害点（ＳＰＯＦ）も存在しないことを保証するために、十分な冗長性を含むように明示的に設計されている。いくつかの知られているクラウドベースシステムでは、アプリケーション仮想マシン（ＶＭ）インスタンスと物理ホストマッピングとの間に「ＳＰＯＦがない（ｎｏ  ＳＰＯＦ）」ことを保証するために、アンチアフィニティルールが適用される。
【発明の概要】
【課題を解決するための手段】
【０００４】
様々な実施形態は、迅速な弾力性およびインフラストラクチャの増大をサポートするルールを提供する、クラウドベースアプリケーションのＳＰＯＦ排除を提供するための方法および装置を提供する。具体的には、本方法および装置によって提供されるＳＰＯＦ排除は、インスタンスマッピングをホストするためのＶＭに加えて、ネットワークアーキテクチャおよび持続的なストレージに関する考慮事項に基づく。
【０００５】
一実施形態では、単一障害点の排除を提供するための装置が提供される。本装置は、データストレージ、およびデータストレージに通信可能に接続されたプロセッサを含む。本プロセッサは、１つまたは複数のアプリケーションリソース要件を決定し、リソースプール、およびリソースプールに関連付けられるネットワークアーキテクチャを決定し、１つまたは複数のルールを決定し、１つまたは複数のアプリケーションリソース要件、リソースプール、ネットワークアーキテクチャ、および１つまたは複数のルールに基づいて、１つまたは複数のコンポーネントインスタンスの配布を決定するようにプログラムされている。
【０００６】
上記の実施形態のうちのいずれかでは、プロセッサは、リンクおよびノードのうちの１つまたは複数のネットワークステータスを決定するようにさらにプログラムされ、１つまたは複数のコンポーネントインスタンスの配布の決定を、ネットワークステータスに基づかせる。
【０００７】
第２の実施形態では、単一障害点の排除を提供するためのシステムが提供される。本システムは、１つまたは複数のデータセンタを含み、１つまたは複数のデータセンタは、リソースプール、および複数のデータセンタに通信可能に接続されたクラウドマネージャを含む。本クラウドマネージャは、１つまたは複数のアプリケーションリソース要件を決定し、リソースプール、およびリソースプールに関連付けられるネットワークアーキテクチャを決定し、１つまたは複数のルールを決定し、１つまたは複数のアプリケーションリソース要件、リソースプール、ネットワークアーキテクチャ、および１つまたは複数のルールに基づいて、１つまたは複数のコンポーネントインスタンスの配布を決定するようにプログラムされている。
【０００８】
第３の実施形態では、単一障害点の排除を提供するための方法が提供される。本方法は、配布トリガが発生したことを決定するステップと、１つまたは複数のアプリケーションリソース要件を決定するステップと、リソースプール、およびリソースプールに関連付けられるネットワークアーキテクチャを決定するステップと、１つまたは複数のルールを決定するステップと、配布トリガ、１つまたは複数のアプリケーションリソース要件、リソースプール、ネットワークアーキテクチャ、および１つまたは複数のルールに基づいて、１つまたは複数のコンポーネントインスタンスの配布を決定するステップとを含む。
【０００９】
上記の実施形態のうちのいずれかでは、配布トリガは、リソースプール内の１つまたは複数のリソースから、コンポーネントインスタンスの少なくとも一部を移行することに基づく。
【００１０】
上記の実施形態のうちのいずれかでは、ネットワークアーキテクチャを決定するステップは、ネットワークアーキテクチャ表現を構文解析するステップを含む。
【００１１】
上記の実施形態のうちのいずれかでは、１つまたは複数のルールは、１つまたは複数のアンチアフィニティルールを含み、１つまたは複数のアンチアフィニティルールを決定するステップは、アンチアフィニティルール表現を構文解析するステップを含む。
【００１２】
上記の実施形態のうちのいずれかでは、本方法は、１つまたは複数のリンクあるいはネットワークノードのネットワークステータスを決定するステップをさらに含み、ネットワークアーキテクチャは、１つまたは複数のリンクあるいはネットワークノードを備え、１つまたは複数のコンポーネントインスタンスの配布を決定するステップは、ネットワークステータスにさらに基づく。
【００１３】
上記の実施形態のうちのいずれかでは、ネットワークアーキテクチャは第１のネットワークデバイスを備え、１つまたは複数のコンポーネントインスタンスの配布を決定するステップは、第１のネットワークデバイスの障害が、１つまたは複数のアンチアフィニティルールのうちの少なくとも１つに違反するであろうと決定するステップに基づいて、１つまたは複数のコンポーネントインスタンスのうちの第１のコンポーネントインスタンスが、リソースプール内の第１のリソースに関連付けられていない可能性があることを決定するステップを含む。
【００１４】
上記の実施形態のうちのいずれかでは、１つまたは複数のコンポーネントインスタンスの配布を決定するステップは、目的関数を使用するステップを備える。
【００１５】
上記の実施形態のうちのいずれかでは、目的関数は、アプリケーションアクセス遅延を最小化する。
【００１６】
上記の実施形態のうちのいずれかでは、ネットワークアーキテクチャは、リンクおよびネットワークノードを含む。
【００１７】
上記の実施形態のうちのいずれかでは、１つまたは複数のアプリケーションリソース要件は、リソースプールのメンバーである１つまたは複数のリソースの現在の割当てと、アプリケーションに関連付けられる１つまたは複数の現在のアプリケーションリソース要件とを含む。
【００１８】
上記の実施形態のうちのいずれかでは、１つまたは複数の現在のアプリケーションリソース要件の決定は、アプリケーションから受信されたアプリケーションリソース要求に基づく。
【００１９】
上記の実施形態のうちのいずれかでは、１つまたは複数のアプリケーションリソース要件の決定は、アプリケーションのリソース使用量を監視するためにプロセッサをプログラミングするステップを含む。
【００２０】
上記の実施形態のうちのいずれかでは、１つまたは複数のルールは、１つまたは複数のアンチアフィニティルールを含む。
【００２１】
上記の実施形態のうちのいずれかでは、１つまたは複数のルールは、１つまたは複数のビジネスルールをさらに含む。
【００２２】
上記の実施形態のうちのいずれかでは、１つまたは複数のビジネスルールは、保守活動のためのリソースプール内のリソースの一部の確保を含む。
【００２３】
上記の実施形態のうちのいずれかでは、１つまたは複数のコンポーネントインスタンスの配布の決定は、障害点のセットにさらに基づく。
【００２４】
様々な実施形態が、添付の図面に示されている。
【図面の簡単な説明】
【００２５】
【図１】クラウドベースアプリケーションのＳＰＯＦ排除システム１００の実施形態を含む、クラウドネットワークを示す図である。
【図２】図１のデータセンタ１５０の１つおよびネットワーク１４０の一部の実施形態である、データセンタ２００Ａ、およびネットワーク２００Ｂの一部を概略的に示す図である。
【図３】クラウドマネージャ（たとえば、図１のクラウドマネージャ１３０）が、図１のＳＰＯＦ排除システム１００内のコンポーネントインスタンスを配布するための方法３００の実施形態を示す流れ図である。
【図４】クラウドマネージャ（たとえば、図１のクラウドマネージャ１３０）が、図３のステップ３４０に示されるルールを決定するための方法４００の実施形態を示す流れ図である。
【図５Ａ】コンポーネントインスタンスＡ１−Ａ２およびＢ１−Ｂ４を必要とする例示的なアプリケーションの信頼性ブロック図である。
【図５Ｂ】コンポーネントインスタンスＡ１−Ａ２およびＢ１−Ｂ３の初期のコンポーネントインスタント割当てを示す図である。
【図５Ｃ】図５Ａのコンポーネントインスタンス５００Ａの第１の例示的な配布における、コンポーネントインスタンスＢ４の割当てを示す図である。
【図５Ｄ】図５Ａのコンポーネントインスタンス５００Ａの第２の例示的な配布における、コンポーネントインスタンスＢ４の割当てを示す図である。
【図６】図１のクラウドマネージャ１３０のうちの１つなどの、様々な装置６００の実施形態を概略的に示す図である。
【発明を実施するための形態】
【００２６】
理解を容易にするために、ほぼ同一または類似の構造、あるいはほぼ同一または類似の機能を有する要素を指すために、同一の参照番号が使用されている。
【００２７】
本説明および図面は、本発明の原理を示すにすぎない。したがって、本明細書には明確に説明または図示されていないが、当業者は、本発明の原理を実施する、および本発明の範囲内に含まれる、様々な構成を考案することができることが理解されよう。さらに、本明細書に列挙されるすべての例は、本発明の原理、および当該技術分野を促進するために発明者によって寄与される概念を読者が理解するのを助けるための教育的な目的にすぎないことが主に明確に意図されており、そのような具体的に列挙された例および条件に限定されないものと解釈されるべきである。さらに、本明細書で使用される「または（ｏｒ）」という用語は、特に明記しない限り（たとえば、「さもないと（ｏｒ  ｅｌｓｅ）」あるいは「または代替で（ｏｒ  ｉｎ  ｔｈｅ  ａｌｔｅｒｎａｔｉｖｅ）」）、非排他的な「または」を指す。また、本明細書に記載の様々な実施形態は、必ずしも相互に排他的ではなく、いくつかの実施形態は、新しい実施形態を形成するために１つまたは複数の他の実施形態に結合され得る。
【００２８】
様々な実施形態は、迅速な弾力性、たとえばソフトウェア／ファームウェア／ハードウェアのアップグレード、更新、改良、および増大などのインフラストラクチャの保守、ならびに、たとえばファンフィルタのクリーニングおよび障害のあるハードウェアコンポーネントの置換などの予防保守をサポートするルールを提供するクラウドベースアプリケーションのＳＰＯＦ排除を提供する方法および装置を提供する。具体的には、本方法および装置によって提供されるＳＰＯＦ排除は、インスタンスマッピングをホストするためのＶＭに加えて、ネットワークアーキテクチャおよび持続的なストレージに関する考慮事項に基づく。
【００２９】
本明細書で使用される「ＳＰＯＦがない（ｎｏ  ＳＰＯＦ）」および「ＳＰＯＦ排除（ＳＰＯＦ  ｅｌｉｍｉｎａｔｉｏｎ）」という用語は、いかなる単一のコンポーネント障害も、容認できないサービス影響を引き起こさないことを意味する。たとえば、電話サービスプロバイダはドロップコールを容認できる場合があるが、単一の障害イベントが、プライマリ／アクティブサービスコンポーネント、ならびにセカンダリ／冗長サービスコンポーネントの両方に影響を与えたために、ドロップコールのリダイヤルを完了することができず、したがって、いかなるコンポーネントも、定義されたしきい値期間内にユーザ要求を処理するために利用可能ではない、または十分な容量を有していない、長時間のサービス停止を容認できない場合がある。自動障害検出メカニズムまたは自動回復メカニズムの障害が、サービス回復メカニズムの活性化を妨げて、長時間のサービス障害をもたらす場合があり、「ＳＰＯＦがない」という要件の範囲を超えている場合があることが理解されるべきである。
【００３０】
図１は、クラウドベースアプリケーションのＳＰＯＦ排除システム１００の実施形態を含む、クラウドネットワークを示す図である。ＳＰＯＦ排除システム１００は、通信パスを介して、データセンタ１５０−１から１５０−ｎ（集合的に、データセンタ１５０）のうちの１つまたは複数に常駐する１つまたは複数の割り当てられたアプリケーションインスタンス（明確にするために、図示せず）にアクセスする、１つまたは複数のクライアント１２０−１から１２０−ｎ（集合的に、クライアント１２０）を含む。通信パスは、クライアント通信チャネル１２５−１から１２５−ｎ（集合的に、クライアント通信チャネル１２５）のうちの適切なクライアント通信チャネル、ネットワーク１４０、およびデータセンタ通信チャネル１５５−１から１５５−ｎ（集合的に、データセンタ通信チャネル１５５）のうちの１つを含む。アプリケーションインスタンスは、クラウドマネージャ通信チャネル１３５、ネットワーク１４０、およびデータセンタ通信チャネル１５５のうちの適切なデータセンタ通信チャネルを介してデータセンタ１５０と通信するクラウドマネージャ１３０によって、データセンタ１５０のうちの１つまたは複数に割り当てられる。
【００３１】
クライアント１２０は、クライアント通信チャネル１２５のうちの１つまたは複数を介して、ネットワーク１４０を介して情報を送信または受信することができる、任意のタイプの通信デバイスを含み得る。たとえば、通信デバイスは、シンクライアント、スマートフォン（たとえば、クライアント１２０−ｎ）、パーソナルコンピュータまたはラップトップコンピュータ（たとえば、クライアント１２０−１）、サーバ、ネットワークデバイス、タブレット、テレビジョンセットトップボックス、メディアプレイヤ、または同等物でよい。通信デバイスは、処理または格納などのタスクの一部を実行するために、例示的なシステム内の他のリソースに依存してもよく、タスクを単独で実行することが可能であってもよい。本明細書では２つのクライアントが示されているが、システム１００はより少数またはより多数のクライアントを含み得ることが理解されるべきである。さらに、クライアントは操作中の様々な時点でシステムに追加される、またはシステムから削減される場合があるので、任意の時点のクライアントの数は動的でよい。
【００３２】
通信チャネル１２５、１３５、および１５５は、ワイヤレス通信（たとえば、ＬＴＥ、ＧＳＭ(登録商標)、ＣＤＭＡ、ブルートゥース）、ＷＬＡＮ通信（たとえば、Ｗｉ−Ｆｉ）、パケットネットワーク通信（たとえば、ＩＰ）、ブロードバンド通信（たとえば、ＤＯＣＳＩＳおよびＤＳＬ）、ストレージ通信（たとえば、ファイバーチャネルｉＳＣＳＩ、）および同等物などの、１つまたは複数の通信チャネルを介する通信をサポートする。単一の接続として示されているが、通信チャネル１２５、１３５、および１５５は任意の数の通信チャネルでもよく、通信チャネルの組合せでもよいことが理解されるべきである。
【００３３】
クラウドマネージャ１３０は、データセンタ１５０内のリソースを１つまたは複数のアプリケーションインスタンスに割り当てる、および割当て解除を行う、任意の装置でよい。具体的には、データセンタ１５０内のリソースの一部はプールされて、コンポーネントインスタンスを介してアプリケーションインスタンスに割り当てられる。本明細書ではクラウドマネージャが１つだけ示されているが、システム１００はより多数のクラウドマネージャを含み得ることが理解されるべきである。
【００３４】
本明細書で使用される「コンポーネントインスタンス（ｃｏｍｐｏｎｅｎｔ  ｉｎｓｔａｎｃｅ）」という用語は、特定のクライアントアプリケーションからの要求を処理するために確保された、１つまたは複数の割り当てられた物理リソースのプロパティを意味する。たとえば、割り当てられた物理リソースは、処理／計算、メモリ、ネットワーキング、ストレージ、または同等物であってもよい。いくつかの実施形態では、コンポーネントインスタンスは、処理／計算、メモリ、およびネットワーキングリソースを備える仮想マシンでよい。いくつかの実施形態では、コンポーネントインスタンスは仮想化されたストレージでよい。
【００３５】
ネットワーク１４０は、任意の数のアクセス、エッジノード、およびネットワークデバイス、ならびに任意の数および構成のリンク設定を含む。さらに、ネットワーク１４０は、ＬＴＥ、ＧＳＭ、ＣＤＭＡ、ローカルエリアネットワーク（ＬＡＮ）、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、メトロポロタンエリアネットワーク（ＭＡＮ）、または同等物を含む、任意の組合せおよび任意の数の、ワイヤレスまたはワイヤラインネットワークを含み得ることが理解されるべきである。
【００３６】
データセンタ１５０は、地理的に分散されてよく、また任意のタイプまたは構成のリソースを含んでよい。リソースは、クライアント１２０からのアプリケーション要求を処理するためにアプリケーションインスタンスによって利用される任意の適切なデバイスでよい。たとえば、リソースは、サーバ、プロセッサコア、メモリデバイス、ストレージデバイス、ネットワーキングデバイス、または同等物でよい。
【００３７】
いくつかの実施形態では、クラウドマネージャ１３０は、クラウドマネージャの階層的配列でよい。
【００３８】
図２は、図１のデータセンタ１５０の１つおよびネットワーク１４０の一部の実施形態である、データセンタ２００Ａ、およびネットワーク２００Ｂの一部を概略的に示す図である。データセンタ２００Ａは、リソース２２０−１−１−１から２２０−ｙ−ｚ−５（集合的に、リソース２２０）を含む。リソース２２０は、「ｙ」行に配列され、各行は、通信パスを通じてアクセスされる、いくつかの（たとえば、例示的に「ｘ」または「ｙ」）リソースのラック（たとえば、ラック２０５）を含む。通信パスは、ラックスイッチ２１０−１−１から２１０−ｙ−ｚ（集合的に、ＴＯＲスイッチ２１０）のトップのうちの適切なラックスイッチ、行スイッチ２４０−１から２４０−ｎ（集合的に、ＥＯＲスイッチ２４０）の末端のうちの適切な行スイッチの末端、レイヤ２アグリゲーションスイッチの２５０−１から２５０−ｎ（集合的に、アグリゲーションスイッチ２５０）のうちの適切なレイヤ２アグリゲーションスイッチ、および適切なリンク２３０−１から２３０−２（集合的に、リンク２３０）を介して、リソース２２０をネットワーク２００Ｂに通信可能に接続する（明確にするために、残りのリンクラベルは省略される）。データセンタ２００Ａとネットワーク２００Ｂとの間の通信は、アグリゲーションスイッチ２５０、ルータ２６０−１から２６０−３（集合的に、ルータ２６０）のうちの適切なルータ、および適切なリンク２３０のうちの１つを介する。データセンタを任意の適切な構成で設計することができ、データセンタ２００Ａは例示的な目的のために使用される１つの例示的なアーキテクチャにすぎないことが理解されるべきである。たとえば、通信パスは、リソース２２０とネットワーク２００Ｂとの間でデータを切り替えるために、デバイス（たとえば、スイッチ、ルータ、ハブ、および同等物）の任意の適切な構成を含み得る。
【００３９】
ＴＯＲスイッチ２１０は、関連付けられるラック内のリソースと、適切なＥＯＲスイッチとの間でデータを切り替える。たとえば、ＴＯＲスイッチ２１０−１−１は、適切なＥＯＲスイッチ（たとえば、ＥＯＲスイッチ２４０−１）を介して、ラック２０５内のリソースからネットワーク２００Ｂへデータを切り替える。
【００４０】
リソース２２０は、本明細書に記載の任意の適切なデバイスでよい。各ラック（たとえば、ラック２０５）内に５個のリソースが示されているが、各ラックは、より少数またはより多数のリソースを含んでよく、各ラックは異なるタイプの、または異なる数のリソースを含み得ることが理解されるべきである。
【００４１】
図示されるように、各リソース２２０は、行−列−リソース番号の命名法を使用してラベル付けされている。たとえば、リソース２２０−２−３−４は、第２の行および第３の列に常駐するラック内の第４のリソースである。
【００４２】
ＥＯＲスイッチ２４０は、関連付けられるＴＯＲスイッチと、適切なアグリゲーションスイッチとの間でデータを切り替える。たとえば、ＥＯＲスイッチ２４０−１は、適切なアグリゲーションスイッチ（たとえば、アグリゲーションスイッチ２５０−１または２５０−２）を介して、ＴＯＲスイッチ２１０−１−１から２１０−１−ｘからネットワーク２００Ｂへデータを切り替える。
【００４３】
アグリゲーションスイッチ２５０は、ＥＯＲスイッチ（たとえば、ラック２０５）と適切なルータとの間でデータを切り替える。たとえば、ＴＯＲスイッチ２１０−１−１は、適切なＥＯＲスイッチ（たとえば、ＥＯＲスイッチ２４０−１）および適切なアグリゲーションスイッチ（たとえば、アグリゲーションスイッチ２５０−１または２５０−２）を介して、ラック２０５内のリソースからネットワーク２００Ｂへデータを切り替える。
【００４４】
ルータ２６０は、適切なアグリゲーションスイッチを介して、ネットワーク２００Ｂとデータセンタ２００Ａとの間でデータを切り替える。たとえば、ルータ２６０−１は、アグリゲーションスイッチ２５０−１を介して、ネットワーク２００Ｂからデータセンタ２００Ａへデータを切り替える。
【００４５】
いくつかの実施形態では、ＴＯＲスイッチ２２０またはＥＯＲスイッチ２４０は、イーサネット(登録商標)スイッチである。
【００４６】
いくつかの実施形態では、ＴＯＲスイッチ２２０またはＥＯＲスイッチ２４０は、冗長であるように構成され得る。たとえば、ラック２０５は、２つ以上のＴＯＲスイッチ２１０によって処理されてよい。
【００４７】
いくつかの実施形態では、アグリゲーションスイッチ２５０は、レイヤ２イーサネットスイッチである。
【００４８】
図３は、クラウドマネージャ（たとえば、図１のクラウドマネージャ１３０）が、図１のＳＰＯＦ排除システム１００内のコンポーネントインスタンスを配布する（たとえば、割り当てる、または割当てを解除する）ための方法３００の実施形態を示す流れ図である。本方法は、配布トリガが発生したと決定すると（ステップ３１０）、（ｉ）決定されたリソースプール、およびプールの関連付けられるネットワークアーキテクチャ（ステップ３２０）、（ｉｉ）決定されたアプリケーションリソース要件（ステップ３３０）、および（ｉｉｉ）決定されたルールのセット（ステップ３４０）に基づいて、コンポーネントインスタンスの配布が修正されるべきかどうかを決定するステップ（ステップ３５０）を含む。次いで、本方法を実行する装置が、リソースへのコンポーネントインスタンスの配布を決定し、コンポーネントインスタンスの配布が修正されるべきかどうかの決定に基づいて、コンポーネントインスタンスを割り当てる、または割当てを解除する（ステップ３６０）。
【００４９】
方法３００で、ステップ３１０は、配布トリガが発生したと決定するステップを含む。トリガ決定に基づいて、本方法はステップ３２０、３３０、および３４０に進むか、戻る（ステップ３９５）。トリガは、コンポーネントインスタンスの配布が修正されるべきであると伝える任意の適切なイベントでよい。たとえば、トリガイベントは、（ａ）しきい値間隔で定期的にトリガする、（ｂ）初期のリソース割当て要求（たとえば、アプリケーションを起動する）、（ｃ）アプリケーション容量を増大させるためにさらなるリソースを求める要求、（ｄ）アプリケーション容量を縮小するために、リソースの縮小を求める要求、（ｅ）仮想化されたディスク構成にわたってＶＭ負荷またはストレージ割当てを統合／平均化するなどの、ＸａａＳ動作の間にクラウドリソースを移行／再構成する場合、（ｆ）サーバまたはインフラストラクチャ上の保守活動に備えて（たとえば、ファームウェア、ハードウェア、またはオペレーティングシステムをアップグレードするためにサーバをオフラインにする前に）、（ｇ）お金を節約するために余剰容量をオフにすることができるようにするために、低使用期間（たとえば、真夜中）内は、アプリケーションをより少数のサーバ上に統合することなどのルーティン的な操作のため、（ｈ）ＶＭスナップショットを起動／再開する場合、（ｉ）障害の後に仮想リソース（たとえば、ＶＭ、ストレージ）を再起動／回復／再割当てする場合（たとえば、障害のために壊れたコンポーネントインスタンスを置換するために新しいコンポーネントインスタンスを作成する）、（ｊ）または同等物でよい。複数のトリガイベントが同時に発生し得ることが理解されるべきである。
【００５０】
方法３００で、ステップ３２０は、リソースプール、およびリソースプールの関連付けられるネットワークアーキテクチャ決定するステップを含む。具体的には、リソースプール（たとえば、図２のリソース２００）、およびプールの関連付けられるネットワークアーキテクチャ（たとえば、図２のＴＯＲスイッチ２１０、リンク２３０、ＥＯＲスイッチ２４０、アグリゲーションスイッチ２５０、およびルータ２６０）が決定される。
【００５１】
方法３００で、ステップ３３０は、アプリケーションのリソース要件を決定するステップを含む。具体的には、本方法を実行する装置は、（ｉ）アプリケーションへの現在のリソース割当て、および（ｉｉ）アプリケーションの現在のアプリケーションリソース要件を決定する。いくつかの実施形態では、現在のリソース割当ての決定は、現在のコンポーネントインスタンスの配布に基づいてよい。
【００５２】
方法３００で、ステップ３４０は、ルールを決定するステップを含む。具体的には、アンチアフィニティルールは、「ＳＰＯＦがない」を満たすために、コンポーネントインスタンスの配布の制約要件を提供する。
【００５３】
有利なことに、コンポーネントインスタンスにアンチアフィニティルールを適用することによって、たとえ独立したハードウェアプラットフォームに２つのアプリケーションインスタンスがインストールされても、本方法を実行する装置は様々なリソース（たとえば、持続的な記憶装置）に「ＳＰＯＦがない」という要件を適用することができる。
【００５４】
方法３００で、ステップ３５０は、コンポーネントインスタンスの配布が修正されるべきかどうかを決定し、修正されるべきである場合、コンポーネントインスタンスの「ＳＰＯＦがない」に準拠した配布が可能であるかどうかを決定するステップを含む。具体的には、決定は、（ｉ）ステップ３２０で決定されたリソースプール、およびプールの関連付けられるネットワークアーキテクチャ、（ｉｉ）ステップ３３０で決定されたアプリケーションリソース要件、および（ｉｉｉ）ステップ３４０で決定されたルールに基づく。
【００５５】
本方法を実行する装置は、１つまたは複数のリソース上の割り当てられた、または割当てを解除されたコンポーネントインスタンスの複数の配布を分析することができ、それらのリソースは、ローカルまたは遠隔の任意の数のデータセンタに常駐し得ることが理解されるべきである。
【００５６】
方法３００で、ステップ３６０は、リソースプールのリソース間の、コンポーネントインスタンスの配布を決定するステップを含む。配布は、たとえば、新たに作成されたコンポーネントインスタンスの配置を決定するステップ、または既存のコンポーネントインスタンスの配置を並べ替えるステップを含み得る。具体的には、本方法を実行する装置は、（ｉ）決定されたリソースプール、および関連付けられたネットワークアーキテクチャ、（ｉｉ）決定されたアプリケーションリソース要件、ならびに（ｉｉｉ）決定されたルールのセットに基づいて、リソースプール内のリソース上のコンポーネントインスタンスを割り当てる、または割当てを解除する。
【００５７】
ステップ３２０のいくつかの実施形態では、ネットワークアーキテクチャは、機械で構文解析可能な文法で表される。有利なことに、ネットワークアーキテクチャが機械で構文解析可能な文法で格納されると、ネットワークアーキテクチャへの修正を動的に行うことができ、ネットワークアーキテクチャの動的な増大および縮小が可能になる。これらの実施形態のうちのいくつかでは、機械で構文解析可能な文法は、グラフまたは論理的な関係である。
【００５８】
いくつかの実施形態では、ステップ３２０は、ネットワークステータスを決定するステップをさらに含む。具体的には、リンク、アクセスノード、エッジノード、ネットワークデバイス、または同等物などのネットワーク要素のステータスまたは状態が決定され得る。たとえば、本方法を実行する装置は、図２のリンク２３０の動作状態および輻輳レベルを決定することができる。
【００５９】
ステップ３３０のいくつかの実施形態では、現在のアプリケーションリソース要件は、アプリケーション要求に基づく。
【００６０】
ステップ３３０のいくつかの実施形態では、現在のアプリケーションリソース要件は、使用量測定に基づく。これらの実施形態のうちのいくつかでは、本方法を実行する装置は、アプリケーションによるリソース使用量を監視する。この実施形態に加えて、監視されたリソースパラメータ（たとえば、処理、帯域幅、メモリ、またはストレージパラメータ）がしきい値を越えて増大または縮小すると、トリガイベントが発生する場合があり、監視されたリソース使用量に基づいて新しいアプリケーションリソース要件が決定され得る。たとえば、アプリケーションが、現在１０ギガバイトのストレージを割り当てられており、監視されたストレージ使用量が１０％の予備容量しきい値を越えて増大する場合、装置は、あらかじめ定められた割当てポリシー（たとえば、使用量のしきい値を超えたとき、１ギガバイト単位でストレージを増やす）に基づいて、現在のストレージアプリケーションリソース要件は１１ギガバイトであると決定することができる。
【００６１】
ステップ３４０のいくつかの実施形態では、アンチアフィニティルールは、インスタンス制限（たとえば、利用可能なコンポーネントインスタンスの最小数を指定する「ＳＰＯＦがない」の要件）で表わされる。これらの実施形態のうちのいくつかでは、インスタンス制限はｎ＋ｋで表わされる。上式で、「ｎ」は「ＳＰＯＦがない」という要件を満たすために必要な、利用可能なコンポーネントインスタンスの数であり、「ｋ」は「ＳＰＯＦがない」という要件を満たすために許容されるべき障害点の数である。たとえば、タイプ「Ａ」のコンポーネントインスタンスが、ウェブサーバのフロントエンド処理を処理する仮想マシンであり、タイプ「Ａ」の各コンポーネントインスタンスが１分当たり３０個の要求を処理すると仮定する。アプリケーションが毎分３００個の要求が処理されることを必要とする場合、アプリケーションは、ｎ＝１０のタイプ「Ａ」の利用可能なコンポーネントインスタンスを必要とする場合がある。さらに、アプリケーションがｋ＝２の障害を許容しなければならない場合、本方法を実行する装置は、ｎ＝１０のコンポーネントインスタンスのうちの２つが障害によって影響を受ける場合、フロントエンド処理要求を処理するために、タイプ「Ａ」の少なくとも２つの冗長なコンポーネントインスタンスを配布する必要がある場合がある。明確にするために、タイプ「Ａ」のコンポーネントインスタンスのうちのいずれも同じ障害によって影響を受けないと仮定する。
【００６２】
ステップ３４０のいくつかの実施形態では、アンチアフィニティルールは、リソース制限（たとえば、ストレージ、帯域幅、メモリアクセス遅延、または処理サイクルの最小しきい値）、および「ＳＰＯＦがない」という要件を満たすために必要な許容される障害の数（すなわち、「ｋ」）で表わされる。たとえば、タイプ「Ａ」のコンポーネントインスタンスは、ウェブサーバのフロントエンド処理を処理する仮想マシンであり、アプリケーションは毎分３００個の要求が処理されることを必要とすると仮定する。さらに、アプリケーションは、ｋ＝２障害の許容を必要とすると仮定する。アプリケーションは、許容される障害の数を指定することができず、デフォルト許容（たとえば、ｋ＝１）が使用され得ることが理解されるべきである。この例では、２つの障害の後で少なくとも３００個のフロントエンド処理要求を処理するために十分な利用可能なタイプ「Ａ」のコンポーネントインスタンスであり、タイプ「Ａ」のコンポーネントインスタンスの任意の適切な構成が使用され得る。第１の例では、１分当たり３０個の要求を処理することができる１０個のタイプ「Ａ」のコンポーネントインスタンス、および１分当たり１５個の要求を処理することができる４個のタイプ「Ａ」のコンポーネントインスタンスがある場合がある。この第１の例では、１分当たり３０個の要求を処理する、タイプ「Ａ」の２つのコンポーネントインスタンスの障害は、１分当たり３００個（すなわち、８×３０＋４×１５＝３００）の要求を処理することができるタイプ「Ａ」の利用可能なコンポーネントインスタンスを依然として残す可能性がある。明確にするために、タイプ「Ａ」のコンポーネントインスタンスのうちのいずれも同じ障害によって影響を受けないと仮定する。
【００６３】
ステップ３４０のいくつかの実施形態では、アプリケーションは、「ＳＰＯＦがない」を実現するためのアンチアフィニティルールを特徴付けることができる。
【００６４】
ステップ３４０のいくつかの実施形態では、アンチアフィニティルールは、機械で構文解析可能な文法で表わされる。たとえば、仮想マシン（たとえば、処理＋メモリ）、および仮想化されたストレージのアンチアフィニティルールを指定するための文法が定義され得る。
【００６５】
ステップ３５０のいくつかの実施形態では、コンポーネントインスタンスを割り当てる、または割当てを解除することができるかどうかの決定は、障害点のセット、およびそれらに関連付けられる、影響を受けたコンポーネントインスタンスに基づく。障害点は、任意の適切な仮想化されたサーバ、リソース、ネットワーク要素、冷却またはパワーコンポーネント、または同等物である。たとえば、図２を参照すると、ＴＯＲスイッチ２１０−１−１の障害は、リソース２２０−１−１−１から２２０−１−１−５のいずれかに割り当てられたすべてのコンポーネントインスタンス、および、たとえば、リソース２２０−１−１−１から２２０−１−１−５のうちのいずれかに割り当てられたコンポーネントインスタンスを有する、任意の仮想化されたサーバ（明確にするために、図示せず）に割り当てられた任意のコンポーネントインスタンスに影響を及ぼす。
【００６６】
ステップ３５０のいくつかの実施形態では、障害点は冗長なコンポーネントでよい。たとえば、図２を参照すると、アグリゲーションスイッチ２５０−１に障害が発生した場合、アグリゲーションスイッチ２５０−２が引き継ぐことができる。しかしながら、冗長なコンポーネント（たとえば、アグリゲーションスイッチ２５０−２）が、アンチアフィニティルールを満たすために十分な負荷を引き継ぐための十分な容量を有していない場合、「ＳＰＯＦがない」への違反が発生する場合がある。
【００６７】
いくつかの実施形態では、ステップ３５０は、初期の割当て、動的な割当てまたは割当て解除、移行、回復、または他のサービス管理動作の間に、決定されたルールのうちの少なくとも一部を強制するステップ（ステップ３４０）を含む。
【００６８】
ステップ３５０のいくつかの実施形態では、本方法を実行する装置が、アプリケーションのアンチアフィニティルールに違反することなしにコンポーネントインスタンスを割り当てることができない場合（たとえば、アプリケーションが、特定のデータセンタの「ＳＰＯＦがない」という能力を超えて水平に増大しようとしているので）、ステップ３５０は、要求された水平増大が禁止されており、アプリケーションは成長しすぎ（ｏｕｔ−ｇｒｏｗ）を示す適切なエラーを返す。異なる増大シナリオは、異なる「ＳＰＯＦがない」という制限を有する場合があることが理解されるべきである。たとえば、データセンタは「ＳＰＯＦがない」という制限に違反することなしに持続的なストレージ容量の増加をホストすることができる場合があるが、制限に違反することなしにサービス容量を増大させる（すなわち、新しいＶＭインスタンスを割り当てる）ことはできない場合がある。
【００６９】
ステップ３５０または３６０のいくつかの実施形態では、同じタイプのコンポーネントインスタンスのうちの１つまたは複数は、異なるストレージ、帯域幅、アクセス遅延、または処理サイクルパラメータなどの、異なるリソースパラメータを有する。たとえば、仮想化されたストレージタイプの２つのコンポーネントインスタンスは、異なるストレージサイズまたはアクセス遅延を指定することができる。
【００７０】
ステップ３６０のいくつかの実施形態では、コンポーネントインスタンスの配布の決定は、コンポーネントインスタンスの少なくとも一部の、少なくとも１つのリソースパラメータに基づく。
【００７１】
ステップ３５０または３６０のいくつかの実施形態では、ステップ３５０でコンポーネントの配布が修正されるべきかどうかの決定、またはステップ３６０におけるコンポーネントインスタンスの配布の決定は、ステップ３２０で決定されたネットワークステータスにさらに基づいてよい。たとえば、本方法を実行する装置は、ステップ３２０で、図２のリンク２３０の動作状態または輻輳レベルを決定することができる。
【００７２】
このネットワークステータス実施形態の第１の例では、本方法を実行する装置は、図２のリンク２３０−１の輻輳レベルが、リソース２２０−１−１−１から２２０−１−１−５に常駐するコンポーネントインスタンスを処理するために十分な容量を許容することができないと決定することができる。この例では、ステップ３５０または３６０における決定の実施形態は、リソース２２０−１−１−１から２２０−１−１−５に常駐する１つまたは複数のコンポーネントインスタンスの低減されたリソース容量に基づくことができ、１つまたは複数のコンポーネントインスタンスの低減された容量は、リンク２３０−１における輻輳に基づく。
【００７３】
このネットワークステータス実施形態の第２の例では、本方法を実行する装置は、図２のリンク２３０−２がサービス停止中であると決定することができる。この第２の例では、ステップ３５０または３６０における決定は、もはや冗長なアグリゲーションスイッチ２５０−２によって処理されないＥＯＲスイッチ２４０−１に基づいてよい。したがって、アグリゲーションスイッチ２５０−１はコンポーネントインスタンスを処理するために十分な容量を提供することができないと決定される場合、決定は、リソース２２０−１−１−１から２２０−１−ｘ−５に常駐する１つまたは複数のコンポーネントインスタンスの低減されたリソース容量に基づいてよい。さらに、アグリゲーションスイッチ２５０−２の可用性は排除されているので、決定は、リソース２２０−１−１−１から２２０−１−ｘ−５に常駐するコンポーネントインスタンスの単一障害点であるアグリゲーションスイッチ２５０−１に基づいてよい。
【００７４】
ステップ３６０のいくつかの実施形態では、現在のコンポーネントインスタンスのうちの１つまたは複数は、異なるリソースへ削除、修正、並べ替えされてよい（たとえば、「ＳＰＯＦがない」という条件を回避するために）。これらの実施形態のうちのいくつかでは、１つまたは複数のコンポーネントインスタンスのリソース容量は、１つまたは複数のコンポーネントインスタンスを処理するために十分な容量が利用可能ではないという決定（たとえば、上述のリンク２３０−１上のリンク輻輳）に基づいて、低減（たとえば、修正）される。
【００７５】
ステップ３６０のいくつかの実施形態では、本方法を実行する装置は、アプリケーションリソース要件を満たすために、２つ以上のコンポーネントインスタンスを作成する。たとえば、３ギガバイトのストレージを割り当てるための要件は、３ギガバイトのストレージを提供する１つのコンポーネントインスタンス、または、２ギガバイトのストレージを提供する１つのコンポーネントインスタンスおよび１ギガバイトのストレージを提供する１つのコンポーネントインスタンスによって満たされ得る。これらの実施形態のうちのいくつかでは、複数のコンポーネントインスタンスへの割当ては、アンチアフィニティルールに基づく。これらの実施形態のうちのいくつかでは、複数のコンポーネントインスタンスへの割当ては、システム内のリソースの能力または可用性に基づく。
【００７６】
ステップ３６０のいくつかの実施形態では、コンポーネントインスタンスは、ステップ３４０で決定されたルールのうちの１つまたは複数に違反しない、新たにインスタンス化された仮想化されたサーバ上で配布され得る。
【００７７】
ステップ３６０のいくつかの実施形態では、コンポーネントインスタンスの割当て解除は、現在のコンポーネントインスタンスのうちの１つまたは複数を並べ替えること必要とする場合がある。たとえば、アプリケーションリソース要件が低下したために（たとえば、アプリケーションリソース縮小要求に基づいて）、コンポーネントインスタンスが削除されると、残りのコンポーネントインスタンスのうちの１つまたは複数が、「ＳＰＯＦがない」という要件を満たすために、異なるリソース間で分割される場合がある。
【００７８】
方法３００のいくつかの実施形態では、ステップ３２０、３３０、または３４０は同時に決定されてもよく、ステップ３２０、３３０、または３４０のうちのいくつかが連続して決定されてもよい。たとえば、ステップ３３０で決定された予備容量は、ステップ３２０における割り当てられたリソースの決定と同時に決定されてよく、ステップ３６０の配布決定は、ステップ３５０の割当てまたは割当て解除決定と同時に実行されてよい。
【００７９】
図４は、クラウドマネージャ（たとえば、図１のクラウドマネージャ１３０）が、図３のステップ３４０に示されるルールを決定するための方法４００の実施形態を示す流れ図である。本方法は、アンチアフィニティルールを決定するステップ（ステップ４２０）と、コンポーネント割当てルールを決定するステップ（ステップ４４０）と、ビジネスルールを決定するステップ（ステップ４６０）と、動作ポリシーを決定するステップ（ステップ４８０）と、規制ルールを決定するステップ（ステップ４９０）とを含む。
【００８０】
方法４００で、ステップ４２０は、アンチアフィニティルールを決定するステップを含む。具体的には、上述のように、アンチアフィニティルールは、「ＳＰＯＦがない」という要件を満たすためにアプリケーションにとって利用可能である必要があるリソースの最小量を説明する。
【００８１】
方法４００は、任意選択でステップ４４０を含む。ステップ４４０は、コンポーネント割当てルールを決定するステップを含む。具体的には、コンポーネント割当てルールは、コンポーネントインスタンスのリソースパラメータを説明する。たとえば、必要なコンポーネントインスタンスのタイプ（たとえば、処理コア、仮想マシン、または仮想化されたストレージ）、またはデバイスの能力（たとえば、アクセス遅延、処理サイクル、またはストレージ要件）である。
【００８２】
方法４００は、任意選択でステップ４６０を含む。ステップ４６０は、システム内のコンポーネントインスタンスの配布に影響を及ぼす場合があるビジネスルールを決定するステップを含む。具体的には、ビジネスルールは、「ＳＰＯＦがない」システムのリソース制約を説明する。これらの実施形態のうちのいくつかでは、ビジネスルールは、（１）現在の、または今後の保守活動において使用するために識別されたリソース、（２）今後の使用のために確保されたリソース、（３）１つまたは複数の識別された顧客のために確保されたリソース、および（４）同等物を含み得る。
【００８３】
方法４００は、任意選択でステップ４８０を含む。ステップ４８０は、コンポーネントインスタンスの配布に影響を及ぼす動作ポリシールールを決定するステップを含む。具体的には、動作ポリシールールは、アプリケーション固有の配布要件を説明する。これらの実施形態のうちのいくつかでは、動作ポリシールールは、（１）コンポーネントインスタンスの割当ての制約（たとえば、特定のタイプのコンポーネントインスタンスを異なるデータセンタに割り当てられない場合がある）、（２）動作要件（たとえば、異なるタイプのコンポーネントインスタンス間の最大アクセス遅延を指定する）、（３）ソフトウェアライセンシング（または、他の商業／金融）制限、または（４）同等物を含み得る。
【００８４】
方法４００は、任意選択でステップ４９０を含む。ステップ４９０は、コンポーネントインスタンスの配布に影響を及ぼす規制ルールを決定するステップを含む。具体的には、規制ルールは、「ＳＰＯＦがない」システムの規制リソース制約を説明する。これらの実施形態のうちのいくつかでは、規制ルールは、コンポーネントインスタンスの地理的な位置の制約を含み得る。たとえば、プライバシー法が地理的境界外での個人情報の格納を制限してもよく、輸出管理規制が地理的境界外での技術データの格納を制限してもよい。
【００８５】
方法４００のいくつかの実施形態では、ステップ４２０、４４０、４６０、４８０、または４９０は、同時に決定または実行され得る。
【００８６】
主に特定の順序で図示および説明されているが、方法３００および４００で示されるステップは、任意の適切な順序で実行され得ることが理解されるべきである。さらに、あるステップによって識別されるステップは、シーケンス内の１つまたは複数の他のステップにおいて実行されてもよく、複数のステップの共通の動作が一度だけ実行されてもよい。
【００８７】
様々な上述の方法のステップは、プログラミングされたコンピュータによって実行され得ることが理解されるべきである。本明細書では、いくつかの実施形態は、機械またはコンピュータ可読および符号化機械実行可能、あるいは命令のコンピュータ実行可能プログラムであるデータ記憶媒体などの、プログラム記憶装置をカバーすることも意図しており、前記命令は、前記上述の方法のステップのうちのいくつかまたはすべてを実行する。プログラム記憶装置は、たとえば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気記憶媒体、ハードドライブ、または光学的に読み取り可能なデータ記憶媒体でよい。また、本実施形態は、上述の方法の前記ステップを実行するようにプログラミングされたコンピュータをカバーすることを意図する。
【００８８】
図３および図５Ａ−図５Ｄを参照すると、図１のクラウドマネージャ１３０による、図１のＳＰＯＦ排除システム１００におけるアプリケーションコンポーネントインスタンスの配布の例が提供されている。
【００８９】
図５Ａは、タイプ「Ａ」およびタイプ「Ｂ」のコンポーネントインスタンスを必要とする、例示的な２層構造アプリケーションの信頼性ブロック図である。コンポーネントインスタンスＡ１−Ａ２は、コンポーネントタイプ「Ａ」５００Ａ−１０であり、コンポーネントインスタンスＢ１−Ｂ４は、コンポーネントタイプ「Ｂ」５００Ａ−２０（集合的に、コンポーネントインスタンス５００Ａである。具体的には、アプリケーション処理インフロー５１０Ａとアプリケーション処理アウトフロー５２０Ａとの間の処理パスは、コンポーネントインスタンス５００Ａを介して提供される。「ＳＰＯＦがない」という要件を満たすために、処理パスは、図３のステップ３４０で決定された、およびステップ３５０または３６０で適用されたルールに基づいて、コンポーネントインスタンス５００Ａがリソースを介して配布されることを必要とする。たとえば、アンチアフィニティルールが、単一の障害の後で少なくとも１つのタイプ「Ａ」のコンポーネントインスタンスが利用可能であることを必要とする場合、コンポーネントインスタンスＡ１およびＡ２は、同じ障害点によって影響を受けない場合がある。
【００９０】
図５Ｂ−図５Ｄに示される例の目的のために、タイプ「Ａ」のコンポーネントインスタンスは、１分当たり１００個の要求を処理することができるフロントエンド処理（たとえば、仮想マシン）であり、タイプ「Ｂ」のコンポーネントインスタンスは、１分当たり３０個の要求を処理することができるバックエンド処理（たとえば、仮想マシン）である。
【００９１】
図５Ｂを参照すると、仮想化されたサーバＳ１−Ｓ５にわたるコンポーネントインスタンスＡ１−Ａ２およびＢ１−Ｂ３の初期の割当て（たとえば、ステップ３２０における現在の割当ての決定）が示されている。
【００９２】
この例では、ユーザサービスが完全に利用可能になる（すなわち、許容できる処理品質で提供された負荷を処理するための十分な容量で）ための決定されたルール（ステップ３４０）は、
（１）システムは、利用可能なフロントエンド処理が、１分当たり６０個の要求を処理することを必要とする、
（２）システムは、利用可能なバックエンド処理が、１分当たり６０個の要求を処理することを必要とする、および、
（３）システムが、１つの障害点について「ＳＰＯＦがない」を満たす、である。
【００９３】
図５Ｂにおけるコンポーネントインスタンスの初期の配布は、決定されたルールを満たすことが理解されるべきである。
【００９４】
図５Ｃおよび図５Ｄは、アプリケーション増大要求に応じて、図５Ａのコンポーネントインスタンス５００Ａの２つの例示的な配布におけるコンポーネントインスタンスＢ４の割当てを示している。これらの例では、アプリケーション増大要求に基づいてユーザサービスが完全に利用可能になるための、更新された決定されたルール（たとえば、図３のステップ３４０）は、
（１）システムは、利用可能なフロントエンド処理が、１分当たり９０個の要求を処理することを必要とする、
（２）システムは、利用可能なバックエンド処理が、１分当たり９０個の要求を処理することを必要とする、および、
（３）システムが、１つの障害点について「ＳＰＯＦがない」を満たす、である。
【００９５】
図５Ｂにおけるコンポーネントインスタンスの初期の配布は、更新された決定されたルールを満たさず、したがって、コンポーネントインスタンスの現在の配布では「ＳＰＯＦがない」という要件が満たされないことが理解されるべきである。たとえば、仮想化されたサーバＳ１−Ｓ３のいずれかに障害が発生した場合、利用可能なタイプ「Ｂ」のコンポーネントインスタンスは、１分当たり６０個の要求しか処理することができず、したがって、「（２）システムは、利用可能なバックエンド処理が、１分当たり９０個の要求を処理することを必要とする」という要件は満たされない。
【００９６】
図５Ｃの配布例を参照すると、仮想化されたサーバＳ１−Ｓ５にわたるコンポーネントインスタンス５００Ａの配布は、更新された決定されたルールを満たし、したがって、配布は「ＳＰＯＦがない」という要件を満たす。たとえば、図示されるように、仮想化されたサーバＳ１−Ｓ５のいずれかに障害が発生した場合、利用可能なタイプ「Ａ」のコンポーネントインスタンスは、１分当たり少なくとも９０個の要求を処理することができ（たとえば、どちらのサーバも１分当たり１００個の要求を処理することができる）、利用可能なタイプ「Ｂ」のコンポーネントインスタンスは、１分当たり少なくとも９０個の要求を処理することができる（たとえば、障害の後に利用可能な少なくとも３つのコンポーネントインスタンスが、１分当たり９０個の要求を処理することができる）。したがって、本方法は、コンポーネントインスタンスＢ４の割当てを達成して（ステップ３５０）、コンポーネントインスタンスＢ４を仮想化されたサーバＳ４に割り当てることができる（ステップ３６０）と決定することができる。
【００９７】
対照的に、図５Ｄの配布例を参照すると、仮想化されたサーバＳ１−Ｓ５にわたるコンポーネントインスタンス５００Ａの配布は更新された決定されたルールを満たさず、したがって、配布はＳＰＯＦ要件を満たさない。図示されるように、仮想サーバＳ３上でＢ２とＢ３の両方がホストされる場合、仮想化されたサーバＳ３の障害は要件に違反し、「（２）システムは、利用可能なバックエンド処理が、１分当たり９０個の要求を処理することを必要とする」は満たされない。
【００９８】
方法３００を実行する装置は、システム「ＳＰＯＦがない」という要件（たとえば、図５Ｃの配布）に違反しない別の配布を選択することができ、または、本方法を実行する装置は、コンポーネントインスタンス（たとえば、コンポーネントインスタンスＢ４）の割当ては、どの配布（ステップ４５０）および戻る（ステップ４９５）を使用しても達成することができないと決定することができることが理解されるべきである。
【００９９】
例に加えて、方法３００を実行する装置は、ネットワークアーキテクチャを決定することができる（ステップ３２０）。たとえば、図２を参照すると、図５Ｂ−図５Ｄの仮想化されたサーバＳ１−Ｓ４は、それぞれリソース２２０−１−１−１、２２０−２−１−１、２２０−ｙ−１−１、および２２０−ｙ−２−１に常駐することができる。図２のネットワークアーキテクチャでは、リソース２２０−ｙ−１−１、および２２０−ｙ−２−１が共通ＥＯＲスイッチ（たとえば、ＥＯＲスイッチ２４０−ｙ）を共有し、したがって、ＥＯＲスイッチ２４０−ｙの障害は、仮想サーバＳ３およびＳ４上に常駐するコンポーネントインスタンスに影響を及ぼす可能性があり、したがって、コンポーネントインスタンスＢ４が仮想化されたサーバＳ４に配置される場合、ＥＯＲスイッチ２４０−ｙは、更新された決定されたルールに違反する可能性がある単一障害点である。実際に、リソースＳ１−Ｓ４のいずれかのコンポーネントインスタンスＢ４の配布は、アンチアフィニティルール、ひいては「ＳＰＯＦがない」という要件に違反する可能性がある。いくつかの実施形態では、方法３００を実行する装置は、アンチアフィニティルールに違反しないリソース（たとえば、リソース２２０−３−１−１）上に、新しい仮想化されたサーバ（たとえば、Ｓ５）を作成して、コンポーネントインスタンスＢ４を新たに作成された仮想化されたサーバに配布することができる。ＥＯＲスイッチ２４０−ｙなどのネットワークデバイスの障害と同様に、リンク障害（たとえば、図２のリンク２３０）は、１つまたは複数のリソースに影響を及ぼす場合がある（たとえば、リンク２３０の障害が、リソース２２０−１−１−１から２２０−１−１−５に影響を及ぼす）ことが理解されるべきである。
【０１００】
いくつかの実施形態では、障害点がアグリゲーションスイッチ２５０−１などの冗長なコンポーネントの場合、冗長なデバイス（たとえば、アグリゲーションスイッチ２５０−２）の容量は、更新された決定されたルールを満たすために十分であることが必要とされる。これらの実施形態のうちのいくつかでは、図３のステップ３５０または３６０における決定は、本明細書に記載のネットワーク帯域幅の妥当性に基づく。
【０１０１】
再び図３を参照すると、いくつかの実施形態では、ステップ３５０または３６０は、コンポーネントインスタンスが配布され得るかどうか、またはその場所を決定するために、従来の古典的な最適化技法を使用するステップを含む。従来の古典的な最適化技法は、所望の目標または目的をもっともよく達成する動作を決定するステップを含む。目標または目的をもっともよく達成する動作は、目的関数の値を最大化または最小化することによって決定され得る。いくつかの実施形態では、目的関数の目標またはメトリックは、コストを最小限にすること、またはアプリケーションアクセス遅延を最小化することであってよい。
【０１０２】
問題は、以下のように表すことができる。
最適化：
［Ｅ．１］ｙ＝ｆ（ｘ１，ｘ２，・・・，ｘｎ）
以下の条件のもとで：
【０１０３】
【数１】
2015522876.tif 000003
【０１０４】
上式で、Ｅ．１は目的関数であり、式Ｅ．２は、ソリューションに課された制約のセットを構成する。ｘｉ変数、ｘ１，ｘ２，・・・，ｘｎは、決定変数のセットを表し、ｙ＝ｆ（ｘ１，ｘ２，・・・，ｘｎ）はこれらの決定変数で表わされる目的関数である。目的関数は最大化されてもよく、最小化されてもよいことが理解されるべきである。
【０１０５】
再び図５Ｂ−図５Ｄを参照すると、コンポーネントインスタンスＢ４の配置は、別のコンポーネントインスタンスからアクセス遅延を最小化する目的関数を使用して決定され得る。たとえば、コンポーネントインスタンスタイプＢが仮想ストレージであり、コンポーネントインスタンスタイプＡが仮想マシン（処理＋メモリ）である場合、目的関数は∀リソース∈リソースプール（たとえば、図２のリソース２２０）であり、コンポーネントインスタンスＢ４の配布のためのリソースを、タイプＡのコンポーネントインスタンスと、新たに割り当てられたコンポーネントインスタンスＢ４との間の平均アクセス遅延を最小化するリソースとして選択する。コンポーネントインスタンスＢ４の配布のいくつかのルールは、
（１）リソースタイプ＝ストレージデバイス、
（２）予備容量≧要求された割当てサイズ、
（３）利用可能なストレージ容量≧最小ストレージサイズしきい値∀障害点、および、
（４）アクセス遅延≦最大アクセス遅延しきい値∀コンポーネントインスタンスタイプＡでよい。
【０１０６】
図６は、図１のクラウドマネージャ１３０のうちの１つなどの、様々な装置６００の実施形態を概略的に示す図である。装置６００は、プロセッサ６１０、データストレージ６１１、およびＩ／Ｏインターフェース６３０を含む。
【０１０７】
プロセッサ６１０は、装置６００の動作を制御する。プロセッサ６１０はデータストレージ６１１と協働する。
【０１０８】
データストレージ６１１は、アンチアフィニティルール、コンポーネント割当てルール、ビジネスルール、動作ポリシールール、または同等物などのプログラムデータを、必要に応じて格納することができる。データストレージ６１１は、プロセッサ６１０によって実行可能なプログラム６２０も格納する。
【０１０９】
プロセッサ実行可能プログラム６２０は、Ｉ／Ｏインターフェースプログラム６２１、再構成プログラム６２３、またはルール決定プログラム６２５を含み得る。プロセッサ６１０は、プロセッサ実行可能プログラム６２０と協働する。
【０１１０】
Ｉ／Ｏインターフェース６３０は、上述のように、図１の通信チャネル１３５を介する通信をサポートするために、プロセッサ６１０およびＩ／Ｏインターフェースプログラム６２１と協働する。
【０１１１】
再構成プログラム６２３は、上述のように、図４の方法４００のステップを実行する。
【０１１２】
ルール決定プログラム６２５は、上述のように、図５の方法５００のステップを実行する。
【０１１３】
いくつかの実施形態では、プロセッサ６１０はプロセッサ／ＣＰＵコアなどのリソースを含んでよく、Ｉ／Ｏインターフェース６３０は任意の適切なネットワークインターフェースを含んでよく、またデータストレージ６１１はメモリまたはストレージデバイスを含んでよい。さらに、装置６００は、１つまたは複数のサーバ、プロセッサ、メモリ、ネットワークインターフェース、またはストレージデバイスなどの構成要素で構成されるブレード、などの、任意の適切な物理的ハードウェア構成でよい。これらの実施形態のうちのいくつかでは、装置６００は、相互に離れているクラウドネットワークリソースを含み得る。
【０１１４】
いくつかの実施形態では、装置６００は仮想マシンでよい。これらの実施形態のうちのいくつかでは、仮想マシンは、異なるマシンからのコンポーネントを含んでもよく、地理的に配布されてもよい。たとえば、データストレージ６１１およびプロセッサ６１０は、２つの異なる物理的マシン内にあってよい。
【０１１５】
プロセッサ実行可能プログラム６２０がプロセッサ６１０に実装されると、プログラムコードセグメントは、特定のロジック回路と類似的に動作する一意のデバイスを提供するために、プロセッサと結合する。
【０１１６】
本明細書では、たとえば、プログラムおよびロジックがデータストレージ内に格納され、メモリがプロセッサと通信可能に接続されている実施形態に関して図示および説明されているが、そのような情報は、他の任意の適切な方法で（たとえば、任意の適切な数のメモリ、ストレージ、またはデータベースを使用して）、任意の適切なデバイス構成に通信可能に接続された、メモリ、ストレージ、またはデータベースの任意の適切な構成を使用して、メモリ、ストレージ、あるいは内部または外部のデータベースの任意の適切な組合せに情報を格納して、あるいは任意の適切な数のアクセス可能な外部メモリ、ストレージ、またはデータベースを使用して、格納され得ることが理解されるべきである。したがって、本明細書に記載のデータストレージという用語は、メモリ、ストレージ、およびデータベースのすべての適切な組合せを包含することを意味する。
【０１１７】
本説明および図面は、本発明の原理を示すにすぎない。したがって、本明細書には明確に説明または図示されていないが、当業者は、本発明の原理を実施する、および本発明の趣旨および範囲内に含まれる、様々な構成を考案することができることが理解されよう。さらに、本明細書に列挙されるすべての例は、本発明の原理、および当該技術分野を促進するために発明者によって寄与される概念を読者が理解するのを助けるための教育的な目的にすぎないことが主に明確に意図されており、そのような具体的に列挙された例および条件に限定されないものと解釈されるべきである。さらに、本発明の原理、態様、および実施形態、ならびにそれらの特定の例を列挙する本明細書のすべての文は、それらの同等物を包含することを意図する。
【０１１８】
「プロセッサ」とラベル付けされた任意の機能ブロックを含む、図面に示される様々な要素の機能は、専用ハードウェア、ならびに適切なソフトウェアに関連付けられるソフトウェアを実行することができるハードウェアの使用を通じて提供され得る。プロセッサによって提供されると、機能は単一の専用プロセッサによって提供されてもよく、単一の共有されたプロセッサによって提供されてもよく、複数の個々のプロセッサによって提供されてもよく、それらのうちのいくつかが共有され得る。さらに、「プロセッサ（ｐｒｏｃｅｓｓｏｒ）」または「コントローラ（ｃｏｎｔｒｏｌｌｅｒ）」という用語の明示的な使用は、ソフトウェアを実行することができるハードウェアだけを指すものと解釈されるべきではなく、これに限定されないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性ストレージを暗黙的に含み得る。従来型またはカスタムの、他のハードウェアも含まれ得る。同様に、図面に示される任意のスイッチは概念的なものにすぎない。それらの機能は、プログラムロジックの操作を通じて、専用ロジックを通じて、プログラム制御と専用ロジックの相互作用を通じて、または手動で実行することができ、文脈からより具体的に理解されるように、特定の技法は実装者によって選択可能である。
【０１１９】
本明細書の任意のブロック図は、本発明の原理を実施する例示的な回路の概念図を表すことが理解されるべきである。同様に、任意のフローチャート、流れ図、状態遷移図、擬似コード、および同等物は、そのようなコンピュータまたはプロセッサが明示的に図示されているか否かにかかわらず、コンピュータ可読媒体内に実質的に表され、そのようにコンピュータまたはプロセッサによって実行される、様々な処理を表すことが理解されるべきである。
【図１】
2015522876.tif 000004
【図２】
2015522876.tif 000005
【図３】
2015522876.tif 000006
【図４】
2015522876.tif 000007
【図５Ａ】
2015522876.tif 000008
【図５Ｂ】
2015522876.tif 000009
【図５Ｃ】
2015522876.tif 000010
【図５Ｄ】
2015522876.tif 000011
【図６】
2015522876.tif 000012
【国際調査報告】
2015522876.tif 000013
2015522876.tif 000014
2015522876.tif 000015