特許 5980914 相互クラウド管理および障害診断

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5980914

(24)【登録日】2016年8月5日

(45)【発行日】2016年8月31日

(54)【発明の名称】相互クラウド管理および障害診断

(51)【国際特許分類】

   G06F 11/30 20060101AFI20160818BHJP

   G06F 9/50 20060101ALI20160818BHJP

【ＦＩ】

   G06F11/30 165

   G06F11/30 140A

   G06F9/46 465Z

【請求項の数】15

【全頁数】17

(21)【出願番号】特願2014-512899(P2014-512899)

(86)(22)【出願日】2012年5月18日

(65)【公表番号】特表2014-515522(P2014-515522A)

(43)【公表日】2014年6月30日

(86)【国際出願番号】US2012038647

(87)【国際公開番号】WO2012162171

(87)【国際公開日】20121129

【審査請求日】2015年5月18日

(31)【優先権主張番号】13/111,956

(32)【優先日】2011年5月20日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100101373

【弁理士】

【氏名又は名称】竹内 茂雄

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100153028

【弁理士】

【氏名又は名称】上田 忠

(74)【代理人】

【識別番号】100120112

【弁理士】

【氏名又は名称】中西 基晴

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100147991

【弁理士】

【氏名又は名称】鳥居 健一

(74)【代理人】

【識別番号】100119781

【弁理士】

【氏名又は名称】中村 彰吾

(74)【代理人】

【識別番号】100162846

【弁理士】

【氏名又は名称】大牧 綾子

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(74)【代理人】

【識別番号】100138759

【弁理士】

【氏名又は名称】大房 直樹

(72)【発明者】

【氏名】イヤー，カンナン・シー

(72)【発明者】

【氏名】ワトソン，エリック・ビー

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２００７−１４８７３８（ＪＰ，Ａ）

【文献】 特開２００６−３４４０２５（ＪＰ，Ａ）

【文献】 特開２０１１−０９０４２９（ＪＰ，Ａ）

【文献】 特開２００８−２１７７３５（ＪＰ，Ａ）

【文献】 特開２０１１−０５４０４３（ＪＰ，Ａ）

【文献】 特表２００９−５０１３８６（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／００５５３７８（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ１１／３０−１１／３４

Ｇ０６Ｆ ９／４６− ９／５４

(57)【特許請求の範囲】

【請求項1】

分散されたアプリケーション・インスタンスからアプリケーション管理データーにアクセスする管理ツールからの要求を扱うコンピューター実装方法であって、
アプリケーション管理ツールから、１つ以上のデーターセンターにおいてインスタンスを実行するアプリケーションに関する管理データーにアクセスする管理ツール要求を受けるステップと、
受けた要求を満たす１つ以上のタイプの管理データーを特定するステップと、
前記アプリケーションの２つ以上のインスタンスを含む前記アプリケーションの分散を決定するステップと、
分散した各アプリケーション・インスタンスから、前記要求を満たす管理データーを収集するステップと、
受けた管理ツール要求に対して均一な応答を行うために、収集した管理データーを統一するステップと、
受けた管理ツール要求に応答して、収集し統一した管理データーを報告するステップと、
を含み、前記ステップが少なくとも１つのプロセッサーによって実行される、コンピューター実装方法。

【請求項2】

請求項１記載の方法において、前記管理要求を受けるステップが、管理データーを要求するためのツールに露出されたアプリケーション・プログラミング・インターフェース（ＡＰＩ）を介して、前記管理ツール要求を受けるステップを含む、方法。

【請求項3】

請求項２記載の方法において、前記ＡＰＩが、どこでまたは何ヶ所でアプリケーション・インスタンスが実行しているか把握するツールを必要とすることなく、管理データーにアクセスする均一インターフェースを含む、方法。

【請求項4】

請求項１記載の方法において、前記管理ツール要求を受けるステップが、１つ以上のアプリケーション・インスタンスの動作を記述するステータス情報にアクセスする要求を、動作監視ツールから受けるステップを含む、方法。

【請求項5】

請求項１記載の方法において、管理データーの１つ以上のタイプを特定するステップが、前記管理ツール要求が、前記アプリケーションの各インスタンスによって生成された情報を求めていると判断するステップを含む、方法。

【請求項6】

請求項１記載の方法において、管理データーの１つ以上のタイプを特定するステップが、各アプリケーション・インスタンスからどの情報を収集すべきか、および前記１つ以上のタイプの管理データーが、各アプリケーション・インスタンスによって中央場所にプッシュされたデーターからローカルに既に収集されているか否か判断するステップを含む、方法。

【請求項7】

請求項１記載の方法において、前記アプリケーションの分散を決定するステップが、前記アプリケーションがどこで実行しているか、および前記要求を満たす管理データーをどこで発見するか判断するステップを含む、方法。

【請求項8】

請求項１記載の方法において、管理データーを収集するステップが、プライベート・データーセンターにおける少なくとも１つのインスタンスと、クラウド計算設備における少なくとも１つのインスタンスとにアクセスするステップを含む、方法。

【請求項9】

請求項１記載の方法において、管理データーを収集するステップが、受けた前記管理ツール要求を満たすために、前記アプリケーションの各インスタンスと連絡を取るステップを含む、方法。

【請求項10】

請求項１記載の方法であって、更に、１つ以上の障害診断コマンドを１つ以上の離れたアプリケーション・インスタンスに送るステップを含み、前記離れたアプリケーション・インスタンスが、前記障害診断コマンドを実行し、要求されたデーターを中央場所に報告し、該中央場所において前記管理ツールが報告された前記要求されたデーターに関連した情報にアクセスすることができる、方法。

【請求項11】

請求項１記載の方法において、収集したデーターを統一するステップが、管理ツールによって管理されるアプリケーションの種々の可能な分散の理解を含むように前記管理ツールを書く必要がないように、データーをフォーマットするステップを含む、方法。

【請求項12】

請求項１記載の方法において、収集したデーターを統一するステップが、アプリケーション負荷を扱うために必要に応じて、前記アプリケーションを自由に場所から場所にまたは複数の場所に移動させることができつつ、なおも一貫した管理および障害診断体験をアドミニストレーターに提供できるように、データーをフォーマットするステップを含む、方法。

【請求項13】

請求項１記載の方法において、前記データーを報告するステップが、前記管理ツール要求が受けられたインターフェースを介して、前記データーを前記管理ツールに送るステップを含む、方法。

【請求項14】

相互クラウド管理および障害診断のための相互クラウド計算コンピューター・システムであって、
以下のコンポーネント内に具体化されているソフトウェア命令を実行するように構成されたプロセッサーおよびメモリーと、
アプリケーションのインスタンスが実行している複数のデーターセンター位置についての情報を管理する位置管理コンポーネントと、
前記アプリケーションのインスタンスが実行している場所を記述する情報を格納する位置データー・ストアと、
１つ以上のツールが前記アプリケーションについての管理および障害診断情報にアクセスすることができるインターフェースを、前記コンピューター・システムに設けるツール・インターフェース・コンポーネントと、
管理情報にアクセスするため、またはアプリケーション障害診断を実行するために、前記ツール・インターフェース・コンポーネントに接続する１つ以上の管理ツールと、
前記アプリケーションが実行している１つ以上の離れた場所にある管理情報を、前記アプリケーションのホーム・ロケーションに移動させるデーター移動コンポーネントと、
１箇所以上の場所において前記アプリケーションに対して１つ以上の障害診断タスクを実行する障害診断コンポーネントと、
を含む、システム。

【請求項15】

請求項１〜１３のいずれかに記載の方法をコンピューター・システムに実行させるためのコンピューター実行可能命令を格納したコンピューター読み取り可能記憶デバイス。

【発明の詳細な説明】

【従来技術】

【0001】

[0001] データーセンターは、大きなアプリケーションを実行するためのサーバーを提供する。企業は、データーセンターを使用して、販売、マーケティング、人的資源、課金、製品カタログなどのような中核業務機能を実行させることが多い。また、データーセンターは、ウェブ・サイト、ウェブ・サービス、電子メール・ホスト、データーベース、および多くの他のアプリケーションというような、顧客向けのアプリケーションも実行する。データーセンターは、通例、予測ピーク負荷を決定し、このピーク負荷レベルに対処するために、サーバー、ネットワーク・インフラストラクチャー、冷却(cooling)、およびその他のリソースを提供する。データーセンターは、非常に費用がかかること、そしてピーク以外のときには過小利用されていることが知られている。また、データーセンターは、当該データーセンターを監視しその保守を行うための機器および人員双方に関して比較的高い管理費用も伴う。殆ど全ての企業が何らかの種類のデーターセンターを使用するので、大きな冗長性がある機能が世界中の組織によって実行されることになる。

【0002】

[0002] クラウド・コンピューティング(crowd computing)は、従前からのデーターセンターの１つの最適化として出現した。クラウドは、少なくとも何らかの従前からのデーターセンター機能を企業にサーブすることができ、ネットワークを介して利用可能な１組のリソース（例えば、処理、格納、または他のリソース）と定められる。クラウドは、多くの場合、そのクラウドのアプリケーションおよびユーザーが、アプリケーションが実行している具体的なハードウェア、そのハードウェアがどこにあるか等について知らなくてもよいように、抽象レイヤーを伴う。これによって、クラウドの操作者には、リソースをサービス、保守等に順に切り替えることに関して、いくらか自由度を高めることができる。クラウドは、MICROSOFT （商標） Azure、Amazon Web Services、およびその他というようなパブリック・クラウド、ならびにEucalyptus Systems、MICROSOFT （商標）等によって提供されているような、プライベート・クラウドを含むことができる。会社は、企業が彼ら自体のデーターセンター内に置いて、種々のレベルのクラウド機能とデーターセンターを接続することができるアプライアンス(appliance)（例えば、MICROSOFT （商標）のAzure Appliance）を提供し始めている。

【発明の概要】

【発明が解決しようとする課題】

【0003】

[0003] データーセンターを有する企業は、クラウド・ベースのリソースを利用するのであっても、大きなデーターセンターを構築するには多大なコストが発生する。企業は、未だに「最悪の場合」のピーク・シナリオに対して計画することが多く、そのためにある量のハードウェアを含ませるが、少なくともその一部は、滅多に使用されないか、または余分な処理容量、余分な記憶空間等に対して過小利用される。この余分な量のリソースは、高いコストが発生するが殆ど収益が得られない。構内のクラウド・ベース・コンピューティングを使用する顧客は、ピーク容量時、災害復旧のシナリオ、または単に容量管理のために、他の互換性があるクラウド（例えば、他の場所にある彼ら自身の第２インスタンス、Microsoft社のパブリック・クラウド等）における容量を使用できることを期待する。このようにする方が、最悪の場合のシナリオに対して構築し冗長性を得るために二重化するよりも、遙かに少ない費用で済む。加えて、複数のクラウドにまたがって分割されたアプリケーションを管理（例えば、障害診断、運用）できることも期待する。今日では、アプリケーション、クラウド管理、および障害診断は、クラウドまたは他のデーターセンターを跨がって動作することができない。

【課題を解決するための手段】

【0004】

[0004] 本明細書では、アプリケーションが２つ以上のクラウド（長距離に及んでもよい）に跨がる能力を提供しつつ、分散型アプリケーションの動作、管理、および障害診断を１つのアプリケーションとして許容するクラウド管理システムについて記載する。本システムは、異なる場所で実行しているアプリケーションのインスタンスの実行のため、そしてその知識を集中させるために、データーセンターを跨いで通信するインフラストラクチャーを提供する。場合によっては、本システムは、計算アプライアンス(computing appliance)を提供する。この計算アプライアンスは、企業がそれ自体のプライベート・データーセンター内に置くことができ、アドミニストレーターが少なくとも一部のアプリケーション負荷をパブリック・クラウドまたは他の別の場所に分散することを可能にしつつ、計算アプライアンスを介して統一した管理を行う。本システムによって提供されるインフラストラクチャーは、アプリケーションおよびクラウド間の接続の双方を監視し、アプリケーション内部で、またはクラウド間における接続のために問題があるか否か把握するインテリジェンスを有する。本システムは、複数のクラウド・プラットフォーム／位置に跨がる管理機能を調整する。アドミニストレーターがアプリケーションをデバッグしたい場合、本システムは、シームレスで統一されたインターフェースを介して、正しい位置における生のデバッグ処理を可能にする。このように、本クラウド管理システムは、１つの監視および障害診断インターフェース、ならびに知識および実行「ファブリック」を複数のクラウドに跨がって作るので、複数のクラウドに跨がって広げられたアプリケーションを一層容易に監視し、管理し、デバッグすることができる。

【0005】

[0005] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを簡略化された形式で紹介するために、設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために使用されることを意図するのでもない。

【図面の簡単な説明】

【0006】

【図1】図１は、一実施形態において、２つのクラウドにおいて実行するアプリケーションを、関連する管理インフラストラクチャーと共に示す。

【図2】図２は、一実施形態におけるクラウド管理システムのコンポーネントを示すブロック図である。

【図3】図３は、一実施形態において、分散アプリケーション・インスタンスからデーターにアクセスするために管理ツールからの要求を扱うクラウド管理システムの処理を示す流れ図である。

【図4】図４は、一実施形態において、リモート・アプリケーション・インスタンスの位置から戻って来るデーターを報告し、その位置において障害診断要求を扱うクラウド管理システムの処理を示す流れ図である。

【発明を実施するための形態】

【0007】

[0010] 本明細書では、アプリケーションが２つ以上のクラウド（長距離に及んでもよい）に跨がる能力を提供しつつ、分散型アプリケーションの動作、管理、および障害診断を１つのアプリケーションとして許容するクラウド管理システムについて記載する。本システムは、異なる場所で実行しているアプリケーションのインスタンスの実行のため、そしてその知識を集中させるために、データーセンターを跨いで通信するインフラストラクチャーを提供する。例えば、本システムは、ロギング(logging)、動作追跡、およびその他の管理機能を、アプリケーションがどこで実行しているかには関係なく、集中させることができる。場合によっては、本システムは、計算アプライアンスを提供する。この計算アプライアンスは、企業がそれ自体のプライベート・データーセンター内に置くことができ、アドミニストレーターが少なくとも一部のアプリケーション負荷をパブリック・クラウドまたは他の別の場所に分散することを可能にしつつ、計算アプライアンスを介して統一した管理を行う。

【0008】

[0011] 本クラウド管理システムによって提供されるインフラストラクチャーは、アプリケーションおよびクラウド間の接続の双方を監視し、アプリケーション内部で、またはクラウド間における接続のために問題があるか否か把握するインテリジェンスを有する。本システムは、複数のクラウド・プラットフォーム／位置に跨がる管理機能を調整する（１つのクラウドのインフラストラクチャーから、２つ以上のクラウドに跨がって実行するようにタスクを調整する）。アドミニストレーターがアプリケーションをデバッグしたい場合、本システムは、シームレスで統一されたインターフェースを介して、正しい位置における生のデバッグ処理を可能にする。このように、本クラウド管理システムは、１つの監視および障害診断インターフェース、ならびに知識および実行「ファブリック」を複数のクラウドに跨がって作るので、複数のクラウドに跨がって広げられたアプリケーションを一層容易に監視し、管理し、デバッグすることができる。

【0009】

[0012] 図１は、一実施形態において、管理インフラストラクチャーに関連する２つのクラウドにおいて実行するアプリケーションを示す。実施形態の中には、アプリケーション（および／またはアドミニストレーター）が、全ての位置におけるデーターを有する／そのデーターにアクセスすることができる１つのクラウドとなっているインフラストラクチャーを使用して、クラウド管理システムがアプリケーションを完全に監視／障害診断できるようにすることを必要とする場合がある。一例として、２つのクラウド、図１に示すようなクラウド１１０および１５０において実行するインスタンスを有するアプリケーションについて考える。クラウド１１０は、インフラストラクチャー１３０を含むMICROSOFT （商標）のAzureアプライアンス・インスタンス１２０を含む。アプライアンス・インスタンス１２０は、役割１４０および役割１４５を実行しているアプリケーション・インスタンス１２５を含む。第２クラウド１５０は、役割１６０および役割１７０を実行しているアプリケーション・インスタンス１５５を含む。また、第２クラウド１５０はインフラストラクチャー１８０も含む。アプライアンス・インスタンス１２０は、これらの役割の各々について知っており、これらが同じアプリケーションの一部であることも知っている。各位置においてインフラストラクチャーがぶら下がることにより(plumbing)、アプライアンス・インスタンス１２０が、第２クラウド１５０において実行している役割１６０および役割１７０についての情報を引き出すことが可能になる。本システムは、個々の役割、アプリケーション全体、または双方を分散させることができる。管理データー（例えば、アプリケーション、装置(machine)、およびインフラストラクチャーからのログ）の全てによって、本システムは、予め定められている健全性規則を適用することにより、これらの役割の全てがローカルであるかのように、アプリーションの健全性にアクセスすることができる。また、本システムは、アプリケーションまたはインフラストラクチャー／ネットワークに問題が発生しているか否か評価するために、両方の位置にわたるインフラストラクチャーの健全性、およびそれらの間にある接続１９０を跨ぐインフラストラクチャーの健全性を調べることもできる。

【0010】

[0013] 同様に、自動または手動障害診断または修復ステップが必要とされる場合、クラウド１１０におけるインフラストラクチャー１３０は、クラウド１５０におけるインフラストラクチャー１８０と調整して、障害診断およびデバッグ処理のサポートを提供することができる。例えば、システム・ファブリックは、アプリケーション全体の更新、停止等を実行するために、複数の位置を経由して広がることができる。尚、当業者には、相互位置制御(cross-location control)を実行するための複数の方法が認められるであろう。例えば、インフラストラクチャー１３０は直接インフラストラクチャー１８０を制御することができ、インフラストラクチャー１３０は、インフラストラクチャー１８０に、インフラストラクチャー１３０の代わりに実行するように要求すること等ができる。同様に、操作者／アドミニストレーター障害診断ツール（例えば、監視可視化、警告、ログおよび構成データー確認等）によって、アプリケーションおよびインフラストラクチャーの位置が入手可能であり論理的に表示されるが、アドミニストレーターからの別個のツールや精神的訓練(mental gymnastics)を一緒にする必要はない。例えば、障害診断し全ての役割についてのデーターを確認するとき、アドミニストレーター１０５の次のステップが１つ以上のツール１９５を使用してアプリケーションのログを確認している場合または役割のインスタンスに対するリモート・セッションを開始している場合、本システムは、どの位置にその役割が存在しているかには関係なく、アドミニストレーター１０５を直接接続する。

【0011】

[0014] 本クラウド管理システムの設計は、複数のクラウド／位置を跨いだサービスの簡素化した一貫性のある実行に備えている。本システムは「計算リソース」の定義をサーバーからデーターセンターを超えてインターネットの一部に移動させる（データーセンターおよびそれらの間にある接続）。これによって、サービス・レベル同意（ＳＬＡ：service level agreement）をサービス・レベルで定め、監視し、管理することが可能になる。これは、サービス所有者が多くの場合最も注意していることである。

【0012】

[0015] 実施形態の中には、クラウド管理システムが、必要に応じてアプリケーションを１つの場所から他の場所にシームレスに移動させるクラウド移動システム(cloud migration system)と協同して動作する場合もある。これをバースティング(bursting)と呼ぶ。クラウド移動システムは、ピーク負荷状態を検出し自動的に計算を他のソースに動かす（そして戻す）ことによって、そして２つ以上のクラウドに跨がって計算を提供し、１つのサイトにおける災害の場合に完全に１つに動かすことによって、容量管理および災害復旧に備えている。これによって、企業は長期負荷レベルに対するローカル・リソースの計画を立て、ピークまたは他の異常負荷のためにクラウド・ベース・リソースを利用することが可能になる。多くの場合、企業の業務は、一年の内特定の時期に忙しくなり、この時期の間だけ余分なリソースが必要になる場合があるというようになっている。例えば、税務計画企業は４月中旬に特に忙しく、電子商取引サイトは、勤労感謝の日およびクリスマスの辺りに休日の繁忙が起こる等があげられる。クラウド移動システムは、データーセンター内における負荷を監視し、現在の負荷がデーターセンターの容量に近づきつつあることを示すしきい値を検出する。例えば、本システムは、中央演算装置（ＣＰＵ）の使用度、メモリーの使用度、ストレージの使用度、ネットワークの帯域幅、およびその他の計量値を監視して、データーセンターが現在の負荷をどのように扱っているか判断することができる。また、本システムは傾向（例えば、リソース使用度の加速率）を観察して、しきい値に達したかまたは直に達するか判断することもできる。

【0013】

[0016] しきい値に達したことを検出すると、クラウド移動システムは、少なくとも一部のデーターセンター負荷を他のデーターセンターまたはクラウド・ベース・リソースに順序正しく移動し易くする。例えば、本システムはあるピーク負荷をパブリック・クラウドに移動させることができる。クラウド価格設定モデルは様々であると考えられるので、本システムはコストを判断要素として含めることができる。例えば、本システムは、コストを削減するためにできるだけ多くの負荷を企業のデーターセンターにおいてホストすることを優先しつつ、顧客の要求を満たすために必要とされる範囲でのみクラウド・リソースを利用するのでもよい。また、本システムは、管理および監視ツールも設けることができる。これらのツールは、特定の負荷をどこで実行するか（例えば、ローカルに企業内において、またはクラウドを使用して公に）には関係なく、情報技術（ＩＴ）要員に一貫性のある体験を提供する。また、本システムは、高負荷の間他のリソースに移動させるのに適した作業負荷またはアプリケーションを決定するのに役立つ計画ツールも設けることができる。例えば、アプリケーションには種々の法令遵守／規制またはネットワーク接続／設計制約がある場合があり、そのために移動に適したものまたは移動に適さないものとなる。また、本システムは、データーセンター／ネットワーク・レベルにおける災害復旧アーキテクチャーとして用い、災害の場合に迅速な作業負荷移転を管理することができる。データーセンターのリソースが永続的に故障した場合、本システムは素早くそして効率的に追加の負荷をクラウドまたは他のリソースに移動させて、データーセンターの顧客が故障によって迷惑を受けないようにする、または迷惑を少なくすることができる。このように、クラウド移動システムは、企業が、希にしかない余分な負荷に対して他のリソースを利用して、データーセンターを小型化し一層効率的に構築することを可能にする。

【0014】

[0017] クラウド管理システムは、クラウド移動システムと共に動作して、アプリケーションを１つの場所から他の場所に移動させるときに、シームレスな管理および障害診断に備えている。前述のように、クラウド移動システムは、一時的に（即ち、バースティング）または永続的に（即ち、災害復旧）、リソースをデーターセンターとクラウドとの間で移動させることができる。一時的な移動は、データーセンターの容量を超えるピークまたは他の高負荷を扱うために短い時間期間だけアプリケーションまたは他のロードをバースティングすることを含む。一時的な移動は、２ヶ所以上場所に跨がって、アプリケーション全体をバースティングすること、またはアプリケーションの負荷を分割することを含むこともできる。永続的移動は、データーセンターにおけるハードウェアの故障による負荷の長期間移動、容量要求増大の長期化、動的な負荷均衡によってアプリケーションを全域的に分散させる要望等を含む。以下に、企業が本システムを使用することができる様々なシナリオ例を示す。

【0015】

[0018] 第１の例では、企業が容量を管理するためにアプリケーション負荷をパブリック・クラウドにバースティングする。業務判断部署（即ち、ＣＥＯ、ＣＦＯ、またはＶＰマーケティング／販売）およびデーターセンター・システム・アドミニストレーターは、毎年使用／トラフィック・レベルが最も多いピークの３日だけ一部の作業をパブリック・クラウドにバースティングし、毎月のピーク使用レベルのときは彼ら自身のデーターセンターを維持する（クラウド機器を使用する可能性がある）ことが、価格効率を高め、より良い顧客体験を提供することであると判断する。彼らは、業務をクラウドにバースティングするためにクラウド・プロバイダーと業務契約に署名し、いつどの位の作業をバースティングするかについての推定を計画する。彼らのアカウントが設定され、クラウド・アプライアンスに情報が入力される。計画段階の間、アドミニストレーターはクラウド・プロバイダーからの検査アプリケーションを用いて検査を行い、接続が適正に動作することを確認する。次いで、アドミニストレーターは容量管理ツールにおいて指定されたレベルに容量を維持するアプリケーションのバースティングを開始するために、容量値（例えば、しきい値）を設定する。アドミニストレーターは、このツールを起動し、この状況（例えば、一時的移動に対して規制の問題がない、技術的に非常に適している）において移動させるのに相応しいアプリケーションを更に指定する。

【0016】

[0019] 使用が制限を超える日が来て、システムは自動的にアプリケーションをパブリック・クラウドに移動させる。監視／使用システムにおいて、容量が開始されたバースティングの５％以内であるとき、システムがバースティングするとき、システムが何をバースティングするのかについて、システムがアプリケーションを元に戻すときに、警告を出す。全ての計算リソースおよび／またはストレージについて明示的なログを維持し、課金のためにアドミニストレーターに彼らのパブリック・クラウド・アカウントに行くように警告する。バースティング・パラメーターおよび移動可能という印を付けたアプリケーションの見直しを、企業のデーターセンター・グループおよび管理における定期的な容量計画会議において行う。

【0017】

[0020] 第２の例では、容量を管理するために、企業はクラウドに跨がってアプリケーションを分割する。このシナリオは、先のシナリオと同様であるが、移動させるアプリケーションのタイプがこのシナリオの方が複雑であるので、異なる優先順位を付けるために分割する。会社は、アプリケーションをクラウドに分割するためにクラウドと関係を有することを決定する（バースティングの形態）。この場合、大きなアプリケーションがバースティング候補として予め特定されている。容量がしきい値に達したとき、１００個の作業インスタンス(worker instance)の内５０個をパブリック・クラウドに自動的に移動させる。この時点で、アプリケーションは２つのアプライアンス・インスタンスまたはクラウド・インスタンスに跨がって分割されており、集中的に管理できるように、全ての監視および課金データーは開始インスタンスに送られる。企業自体のデーターセンターにおけるクラウド・アプライアンスは、障害診断ツールを有し、分割されたアプリケーションに起こり得る問題（例えば、ネットワーク接続問題、ネットワーク帯域幅／レイテンシ問題、ファブリック通信等）をデバッグするのに役立つ。アプライアンスにおいて容量の状況が鎮まった場合、５０個の作業インスタンスがアプライアンスに戻され、再度通常に機能するアプリケーションとなる。

【0018】

[0021] 他の例では、クラウド・プロバイダーがあるクラスターから他のクラスターにバースティングすることを決定する。パブリック・クラウド容量計画チームは、シカゴ・データーセンターにおけるクラスターが危機的に満杯であるが高い利用度を維持したいと判断する。彼らは、利用度が９０％に達したときに、西海岸データーセンターにあり過小利用されているクラスターへのバースティングを設定する。アドミニストレーターは容量管理ツールを起動し、しかるべき顧客／アプリケーション（例えば、データー使用度が低い）を移動候補に選択する。シカゴ・クラスターの使用度がしきい値に達する日が来て、本システムは自動的に選択したアプリケーション（例えば、クラスターのアプリケーションの１０％）を西海岸データーセンターに１日だけ移動させる。使用度がしきい値未満に戻ると、本システムはアプリケーションをシカゴに戻す。本システムは、顧客の質問に答えることができるように、指定された監視チームにこのバースティングについて事前に通知する。

【0019】

[0022] 他の例では、本システムは相互クラウド・ポートフォリオ管理のために使用される。企業は、彼らのクラウド・アプライアンスにおいて効率的に容量を管理するために、全ての可変デマンド・アプリケーションをパブリック・クラウドに入れて、彼らの一定デマンド・アプリケーションをアプライアンスまたはローカル・データーセンター・リソースに入れたいと決定する（そして、利用度を上げてアプライアンスを実行できるようにするため）。彼らはその計算リソースを分割することを望むが、彼らのアプリケーション開発者に同様にアプリケーションを管理させ、更に双方に跨がる部門毎の課金を１つの検証で維持するために（例えば、消費者販売グループ、国内ＩＴ、Ｂ２Ｂ販売等に割り当てるためのコストはどれくらいか）、なおも彼らのアプリケーションの健全性全てにわたって全般的な検証(view)も望む。企業は、アプライアンスと同じ分類で、パブリック・クラウドに総合アカウントを設定し、課金データーを得て彼らの側で統合することができる。同様に、彼らは彼らのアプリケーションが実行しているプラットフォームおよびアプリケーション・レベルの監視についてのパブリック・クラウド監視データーへのアプリケーション−プログラミング・インターフェース（ＡＰＩ）アクセスを得ることができるので、彼らのネットワーク運用センター（ＮＯＣ）は、企業の計算活動の状態について完全で一貫性のある検証を行うことができる。

【0020】

[0023] 他の例では、企業は、動的な負荷均衡によって、全般的に分散されるアプリケーションを設定する。企業の顧客は、２つ以上のクラウド・インスタンスに跨がって容量を管理することを望み、大量の彼らの負荷を、独立しているが地理的に分散したインスタンス（例えば、ドイツ語のクエリーにサーブするＵＳおよびＵＫ双方のデーターセンターによるビング・サーチ(Bing search)）に有する。正常な状況下では、グローバル・トラフィック・マネージャーが５０％トラフィックを各位置に送る。主要位置において負荷が高くなると、本システムは負荷バランサーに、トラフィックの７５％をＵＫシステムに送るように命令し、こうしてＵＳクラウド・インスタンスから容量を解放して、容認可能なレベルに持って行く。容量が正常に戻ったとき、本システムは負荷バランサーに５０／５０分割に戻すように伝える。これには、パブリック・クラウドを副データーセンターとして使用するための変形がある（例えば、負荷の１％とし、顧客のサイトのアプライアンスで残りの９９％）。災害または負荷を顧客のサイトから移動させる他の理由の場合、トラフィックの１００％をパブリック・クラウドに移す。

【0021】

[0024] 他の例では、企業はそのデーターセンターの容量に既に達しており、余分な計算リソースを必要とするが、データーセンターを拡張するために利用可能な資本を未だ有していない。この場合、この会社は、ハードウェアの購入を完了できるまで、スピルオーバー(spillover)に対してパブリック・クラウドを使用することができる。

【0022】

[0025] 図２は、一実施形態におけるクラウド管理システムのコンポーネントを示すブロック図である。システム２００は、位置管理コンポーネント２１０、位置データー・ストア２２０、ツール・インターフェース・コンポーネント２３０、１つ以上の管理ツール２４０、データー移動コンポーネント２５０、障害診断コンポーネント２６０、および課金コンポーネント２７０を含む。これらのコンポーネントの各々について、ここで更に詳しく説明する。

【0023】

[0026] 位置管理コンポーネント２１０は、アプリケーションのインスタンスが実行している複数のデーターセンター位置についての情報を管理する。コンポーネント２１０は、各位置にどのようにして到達するか記述する情報、そして管理情報を引き出すために利用可能な接続、関連するセキュリティ証明書と共に位置毎に使用するユーザー・アカウント、障害診断情報を集める元であり障害診断コマンドを送る先であるアプリケーションおよびデーターセンター・コンポーネント等を記述する情報を含む。位置管理コンポーネント２１０は、アプリケーション負荷の任意の移動、または１つのデーターセンター／クラウドから他へのバースティングを記述する情報を受け取り、アプリケーションが実行している場所の全ての完全な絵図をコンポーネント２１０が有するように、管理している情報を更新する。これによって、どこでまたは何ヶ所でアプリケーションが実行しているかには関係なく、システム２００はこの完全な絵図を提示し、アプリケーションの管理を均一に行うことができる。条件が変わり、アプリケーションが分散されるに連れて、位置管理コンポーネント２１０は、管理ツールに総合的な１組の管理データーを提示することができる。

【0024】

[0027] 位置データー・ストア２２０は、アプリケーションのインスタンスが実行している位置を記述する情報を格納する。データー・ストア２２０は、１つ以上のファイル、ファイル・システム、ハード・ドライブ、データーベース、クラウド・ベースの記憶サービス、またはシステム２００とのセッションの間情報を保存するための他の設備を含むことができる。格納される情報は、接続情報、ユーザーの役割、管理データーのソース、利用可能なログ・ファイル、および複数の位置に分散されるアプリケーションの管理および障害診断に関係する任意の他の情報を含むことができる。

【0025】

[0028] ツール・インターフェース・コンポーネント２３０は、システム２００へのインターフェースを設け、これを介して１つ以上のツールがアプリケーションに対する管理および障害診断情報にアクセスすることができる。このインターフェースは、１つ以上のウェブ・ページ、ウェブ・サービス、アプリケーション・プログラミング・インターフェース（ＡＰＩ）、あるいはアドミニストレーターまたはツールが直接またはプログラムによってシステム２００の管理および障害診断情報にアクセスすることができる他のインターフェースを含むことができる。実施形態の中には、ツール・インターフェース・コンポーネント２３０が企業のプライベート・データーセンター内に位置するクラウド−計算アプライアンスにおいて、アプリケーションに関係する情報にツールがアクセスするための初期接続ポイントを設ける場合もある。このアプライアンスは、パブリック・クラウドまたは他のデーターセンターへのアプリケーション負荷の移動および分散を管理することができ、管理情報を集めるまたはアプリケーションの障害診断を行うツールに、中央コンタクト・ポイントを提供する。

【0026】

[0029] １つ以上の管理ツール２４０が、管理情報にアクセスするためまたはアプリケーションの障害診断を行うために、ツール・インターフェース・コンポーネント２３０に接続する。これらのツールは、ログ・ビューア、報告ツール、デバッグ処理ツール、あるいは実行中のアプリケーションに伴う問題についての情報を表示するまたは問題の解決において補助する他のツールを含むことができる。管理ツール２４０は、ローカル・アプリケーションと共に動作するように設計されているツールを含むことができ、システム２００は、これらのツールの知識がなく複数の場所で実行している分散アプリケーションを記述する情報を、これらのツールに提供する。これによって、自動アプリケーション負荷移動がデーターセンターまたはクラウドに導入されても、アドミニストレーターが拠り所とする既存のツールを、使用することが可能になる。他の場合では、分散アプリケーションを理解するように、そして複数の場所に関する具体的な管理情報を提供するまたは障害診断に備えるように、具体的にツールを書くこともできる。ツール・インターフェース・コンポーネント２３０は、複数のインターフェースを提供することができ、これらのインターフェースを介して、管理ツール２４０は、各ツールによって理解される枠組みを使用して、システム２００に接続する。

【0027】

[0030] データー移動コンポーネント２５０は、アプリケーションが実行している１つ以上の離れた位置における管理情報を、そのアプリケーションのホーム・ロケーションに戻す移動を行う。ホーム・ロケーションは、プライベート・データーセンター、クラウド−計算アプライアンスの位置、あるいはアプリケーションが通常定常状態の下で実行する他の位置を含むことができる。あるレベルの負荷（例えば、ピークまたは周期的なバースティング）に当たったとき、アプリケーションは顧客(client)の要求を満たすのを助けるために、一部の負荷を１つ以上の他のデーターセンターまたはパブリック・クラウドに移動させることができる。これらの他の場所は、丁度ホーム・ロケーションのように、ログ・ファイル、トランザクション・データー等のような管理データーを生成し、管理ツール２４０がアプリケーションの動作(activity)の総合的な絵図をアドミニストレーターに提供できるように、データー移動コンポーネント２５０はこのデーターをホーム・ロケーションに戻す移動を行い、またはホーム・ロケーションからのデーターへのアクセスを付与する。

【0028】

[0031] 障害診断コンポーネント２６０は、１ヶ所以上の場所でアプリケーションに対する障害診断タスクを実行する。障害診断は、デバッグ処理、検査データーの処理、またはアプリケーションが正しく動作しているか否かについての他の形態の判断を含むことができる。障害診断は、一般に、ホーム・ロケーションにおいては十分に理解されるが、アプリケーションが複数のデーターセンターまたはクラウドに広がり始めるに連れて一層複雑になる。クラウド管理システム２００は均一のインターフェースを設け、これを介してツールおよびアドミニストレーターが管理情報にアクセスし複数の場所において障害診断の実行することによって、管理ツール２４０およびアドミニストレーターからこの複雑さを遠ざける。つまり、ブレークポイントをホーム・ロケーションにおけるアプリケーション・コードの特定の部分に置くことまたはトレース情報をこの特定の部分から受け取ることが、管理ツールによって、アドミニストレーターに可能になれば、障害診断コンポーネント２６０は、アプリケーションの離れたクラウド・ベースのインスタンスにおいてそうすることも全く同様に容易にする。これらのツールおよびアドミニストレーターは、アプリケーションが実行している場所の全てを知らなくてもよいが、それでもなお、アプリケーションがホーム・ロケーションのみで実行しているかのように、管理タスクを実行することができる。

【0029】

[0032] 課金コンポーネント２７０は、アプリケーションが実行している１ヶ所以上の場所に関係する課金情報を報告する。１つの共通する管理タスクは、計算コストを管理することであり、パブリック・クラウドは多くの場合作業負荷（例えば、計算時間、使用した記憶容量等）に基づいて課金する。アドミニストレーターにとって、種々の場所においてアプリケーション・インスタンスによって発生するコストの絵図を集めることは有用であろうし、クラウド管理システム２００は、管理ツールまたは報告を介して報告することができるように、このタイプの情報を収集するために課金コンポーネント２７０を任意に設けることができる。

【0030】

[0033] クラウド管理システムが実装されている計算デバイスは、中央演算装置、メモリー、入力デバイス（例えば、キーボードおよびポインティング・デバイス）、出力デバイス（例えば、ディスプレイ・デバイス）、および記憶デバイス（例えば、ディスク・ドライバまたは他の不揮発性記憶媒体）を含むことができる。メモリーおよび記憶デバイスは、コンピューター読み取り可能記憶媒体であり、本システムを実現またはイネーブルするコンピューター実行可能命令（例えば、ソフトウェア）をエンコードすることができる。加えて、データー構造およびメッセージ構造は、通信リンク上の信号というような、データー送信媒体によって格納または送信することもできる。インターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、ポイント・ツー・ポイント・ダイアルアップ接続、セル・フォン・ネットワーク等のような、種々の通信リンクを使用することができる。

【0031】

[0034] 本システムの実施形態は、種々の動作環境において実現することができ、これらの動作環境には、パーソナル・コンピューター、サーバー・コンピューター、ハンドヘルドまたはラップトップ・デバイス、マルチプロセッサー・システム、マイクロプロセッサー・ベースのシステム、プログラマブル消費者用電子機器、ディジタル・カメラ、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、以上のシステムまたはデバイスの内任意のものを含む分散型計算環境、セット・トップ・ボックス、チップ上システム（ＳＯＣ）等が含まれる。コンピューター・システムは、セル・フォン、パーソナル・ディジタル・アシスタント、スマート・フォン、パーソナル・コンピューター、プログラマブル消費者用電子機器、ディジタル・カメラ等であってもよい。

【0032】

[0035] 本システムは、１つ以上のコンピューターまたは他のデバイスによって実行される、プログラム・モジュールのような、コンピューター実行可能命令という一般的なコンテキストで説明することができる。一般に、プログラム・モジュールはルーチン、プログラム、オブジェクト、コンポーネント、データー構造等を含み、特定のタスクを実行するか、または特定の抽象データー・タイプを実現する。通例、プログラム・モジュールの機能は、種々の実施形態における所望に応じて、組み合わせることまたは分散させることもできる。

【0033】

[0036] 図３は、一実施形態において、管理ツールから、分散されたアプリケーション・インスタンスからデーターにアクセスする要求を扱うためのクラウド管理システムの処理を示す流れ図である。ブロック３１０において開始し、本システムは管理ツールから、１つ以上のデーターセンターにおいてインスタンスを実行しているアプリケーションに関する管理データーにアクセスする要求を受ける。例えば、動作監視ツール(performance-monitoring tool)が、どのくらいの顧客要求をアプリケーションが扱っているか記述するステータス情報、アプリケーションのリソース使用度、またはアプリケーションからの他の情報を要求するのでもよい。本システムは、当該システムがツールに露出するＡＰＩを介して、管理データーを要求するツール要求を受けることができる。ＡＰＩは、どこでそして何ヶ所でアプリケーション・インスタンスが実行しているかには関係なく、管理データーにアクセスするための均一なインターフェースを含むことができる。

【0034】

[0037] ブロック３２０に進んで、本システムは、受けた要求を満たす１つ以上のタイプの管理データーを特定する。例えば、本システムは、要求が、アプリケーションの各インスタンスによって生成されたログ情報を求めていると判断することができる。要求されたデーターを特定することによって、本システムは各アプリケーション・インスタンスからどの情報を収集すべきか判断すること、または各アプリケーション・インスタンスによって中央位置にプッシュされたデーターから、そのデーターが既にローカルに収集されているか否か判断することができる。

【0035】

[0038] ブロック３３０に進んで、本システムは、アプリケーションの２つ以上のインスタンスを含むアプリケーションの分散を決定する。分散では、アプリケーションがどこで実行しているか判断し、そして要求を満たすためにシステムがどこで管理データーを発見するか判断する。本システムは、アプリケーション負荷の他のデーターセンターへおよびからのバースティングまたは他の移動を記述する情報を追跡するデーター・ストアを含むことができるので、本システムは、アプリケーション・インスタンスが実行している各場所を把握している。管理ツール要求を受けたときに、この情報によって、本システムはどこから管理データーを収集すべきか決定することが可能になる。

【0036】

[0039] ブロック３４０に進んで、本システムは、分散されている各アプリケーション・インスタンスから、要求を満たすための管理データーを収集する。インスタンスは、ローカルのプライベート・データーセンター、離れたプライベート・データー・センター、プライベート・クラウド計算設備、パブリック・クラウド計算設備、他のプライベート・データーセンターによって提供される予備のリソース等におけるインスタンスを含むことができる。本システムは、アプリケーションの各インスタンスと連絡を取り、または各インスタンスから、受けた管理ツール要求を満たすための情報（動作データー、障害等というような情報）を含む、以前に送られた情報にアクセスする。

【0037】

[0040] ブロック３５０に進んで、本システムは、任意に、１つ以上の障害診断コマンドを１つ以上の離れたアプリケーション・インスタンスに送る。例えば、１つの場所で障害が発生している場合、アドミニストレーターは管理ツールを用いて追加のトレース情報を要求し、１つ以上の検査要求を送り、または他のタイプのデバッグ処理を実行することができる。離れたアプリケーション・インスタンスは、障害診断コマンドを実行し、要求されたデーターを中央位置に報告する。管理ツールは、この中央位置において情報にアクセスすることができる。

【0038】

[0041] ブロック３６０に進んで、本システムは収集したデーターを統一して、受けた管理ツール要求に対して均一な応答を供給する。このように、ツールによって管理されるアプリケーションの種々の可能な分散の理解を含むように管理ツールを書く必要がない。このように、本システムはアプリケーション負荷を扱う必要に応じて、アプリケーションを場所から場所に、または複数の場所に自由に移動させることができ、しかもアドミニストレーターに単刀直入な管理および障害診断体験を提供する。

【0039】

[0042] ブロック３７０に進んで、本システムは、受けた管理ツール要求に応答して、収集し統一した管理データーを報告する。本システムは、要求を受けたインターフェースを介して、あるいは通知インターフェースまたはデーターをツールに提供する他の設備を介して、このデーターを送ることができる。ブロック３７０の後、これらのステップは終結する。

【0040】

[0043] 図４は、一実施形態において、クラウド管理システムが、離れたアプリケーション・インスタンスにデーターを報告し、このアプリケーション・インスタンスの位置において障害診断要求を扱う処理を示す流れ図である。ブロック４１０において開始して、本システムはアプリケーションの顧客からの要求によって生成された負荷の一部を扱う離れたアプリケーション・インスタンスにおいて、管理データーを受け取る。この管理データーは、動作データー、ログ情報、誤りの詳細、統計的情報、販売履歴、またはアプリケーションの管理に有用なアプリケーション動作の他の指示を含むことができる。

【0041】

[0044] ブロック４２０に進んで、本システムは、アプリケーションのホーム・ロケーションを決定する。ホーム・ロケーションでは、分散した離れた位置において実行するアプリケーションの複数のインスタンスによって報告された管理データーに、アドミニストレーターがアクセスすることができる。アプリケーション・インスタンスは、このインスタンスの作成時における構成情報をホーム・ロケーションから受け取ることができる。この構成情報は、どこでホーム・ロケーションに連絡することができるか特定し、更にこのアプリケーション・インスタンスが、アプリケーションの離れたインスタンスであることを特定する。本システムは、ピーク負荷を扱うために、処理がピーク以外でありしたがって安く済む場所で優先順位の低いタスクを実行するため、またはアドミニストレーターによって決定された他の理由のために、複数の場所にアプリケーションを移動させることができる。アプリケーションは、そのアプリケーションが通常実行する場所であるホーム・ロケーションを有することができ、１ヶ所以上の分散した離れた場所でピークまたは他の負荷を扱うことができる。

【0042】

[0045] ブロック４３０に進んで、本システムは、離れたアプリケーション・インスタンスから受け取った管理データーを、決定したアプリケーションのホーム・ロケーションに送る。本システムは、周期的に、分散されたインスタンスにおいて生成されたデーターを、ホーム・ロケーションに戻す移動を行い、アドミニストレーターおよび管理ツールの便宜のために、ホーム・ロケーション１ヶ所で管理データーが入力可能となるようにする。また、本システムはオン・デマンドのデーター、即ち、種々のツールによって要求されるデーターも移動させることができる（例えば、図３参照）。場合によっては、本システムはアプリケーション負荷を離れた場所に短期間バースティングし、次いでこの負荷をホーム・ロケーションに戻す移動を行い、離れたインスタンスを終了するときに、アプリケーションの実行に関する情報を収集することもできる。

【0043】

[0046] ブロック４４０に進んで、本システムは、任意に、離れたアプリケーション・インスタンスの故障診断を行うための故障診断要求を、ホーム・ロケーションにおいて実行する管理ツールから受ける。この故障診断要求は、デバッグ・ブレークポイント、詳細なトレース情報の要求、あるいは障害診断動作を実行する他のコマンドまたは要求を含むことができる。

【0044】

[0047] ブロック４５０に進んで、本システムは、受けた障害診断要求に応答して、１つ以上の障害診断動作を実行する。この動作は、デバッグ・ブレークポイントを設定する、ロギング・レベルを上げる、検査データーをアプリケーションに送る、またはアプリケーションが適正に動作しているか否か判断するために、要求によって指定された任意の他の動作を実行することを含むことができる。

【0045】

[0048] ブロック４６０に進んで、本システムは、受けた障害診断要求に応答して、障害診断結果をホーム・ロケーションに送る。障害診断コマンドを離れて実行する設備を設けることによって、本システムは、インスタンスがどこで実行しているかに関係なく、ホーム・ロケーションにおいて動作する障害診断ツールがアプリケーション・インスタンスの障害診断を行うことを可能にし、更に、本システムが、アドミニストレーターのアプリケーションを管理および障害診断する能力を中断することなく、アプリケーションのインスタンスを種々の場所にシームレスに移動させることを可能にする。

【0046】

[0049] 実施形態の中には、クラウド管理システムが、ドメイン・ネーム・サービス（ＤＮＳ）記録を変更することによって、アプリケーション負荷を移動させる場合もある。本システムは、到来する顧客要求を１つ以上の新たな宛先インターネット・プロトコル（ＩＰ）アドレスに向けさせ(point)、負荷をソース・データーセンターから離れて目標データーセンター／クラウドに導くように、ＤＮＳサーバーを変更することができる。グローバル・トラフィック・マネージャー（ＧＴＭ）は、多くの場合、要求を扱うために、顧客を最も近いサーバーに向けさせ、負荷または他の条件に基づいてトラフィックをリディレクトするために、これらのソリューション(solution)を変更することができる。このように、１つのデーターセンターが過剰負荷または容量近くになったとき、本システムは、過剰負荷を扱うことができる新たな場所に、少なくとも一部の顧客要求を導くように、ＧＴＭに伝えることができる。同様に、本システムは、管理ツールが管理要求を宛てることができるＤＮＳまたは他のアドレスを供給し、アプリケーション・インスタンスがどこに存在するかには関係なく、これらに接続することができる。

【0047】

[0050] 実施形態の中には、移動条件が緩和した後、クラウド管理システムがログおよび他のデーターをターゲット計算リソースから戻す移動を行う場合もある。例えば、ピーク負荷の期間に続いて、本システムは全てのアプリケーション負荷を元のデーターセンターに戻す移動を行うことができ、アプリケーション・ログのような、ターゲット・データーセンターにおいて生成された情報をプルして、後の分析のために元のデーターセンターに戻すこともできる。一部のアプリケーションにとっては、顧客要求を追跡することは規制対応の問題であることや、単にデバッグ処理や報告に有用であることもある。いずれの場合でも、ソース位置においてログを統合することは、ソース位置に首尾良く戻す移動の一部であることができる。

【0048】

[0051] 実施形態の中には、クラウド管理システムがアプリケーション負荷の動的可変量を、ソース計算リソースと１つ以上のターゲット計算リソースとの間で割り当てる場合もある。例えば、本システムは、ソース計算リソースを最大容量またはその付近に維持するために要求を動的に導き(route)、ソース計算リソースが首尾良く扱うことができなかった要求だけを外部計算リソースに送るのでもよい。このような判断は、コスト、データーの安全性、あるいは必要に応じてできるだけ少ないアプリケーションを外部に移動させるためまたは最も安くまたは最も効率的に実行できるところにアプリケーション負荷を持って行くための他の考慮事項の問題とするとよい。場合によっては、この判断はアプリケーションの規制要件に基づくこともできる。例えば、健康管理または他の記録保持法(recordkeeping law)の対象となるアプリケーションは、これらが動作することができるデーターセンター／クラウドについての規制を有することもある。

【0049】

[0052] 実施形態の中には、クラウド管理システムが、災害復旧のために種々の選択肢を設ける場合もある。場合によっては、本システムが主要データーセンターを監視して超過を見つけるために、外部データーセンターにリソースを入れる(enlist)こともできる。外部データーセンターが主要データーセンターに到達できなくなった場合、外部データーセンターは、災害が起こったと判断し、アプリケーション負荷を外部データーセンターに移動させることができる。過去のシステムでは、組織は災害を首尾良く扱うために、必要とされる容量の２００％を維持することが通例であった（多大な費用をかけて）。本クラウド管理システムでは、組織は、それよりも低い量の利用可能な容量を第２の場所に維持すればよく（例えば、１０％）、障害の場合には必要に応じてもっと多くの容量を迅速に要求することができる。保険と全く同様に、クラウド・プロバイダーの顧客全てが同時に故障し高容量の予備を要求する可能性は低く、複数の顧客は１組の冗長な補助リソースを、主要リソースの障害の場合に用いるために共有することができる。また、本システムは、管理が中断なく継続するように、災害復旧に続いて、新たな場所を示すように、管理ツールおよび障害診断リソースを設定し直す(re-home)こともできる。

【0050】

[0053] 以上の説明から、本明細書では例示の目的に限って、クラウド管理システムの具体的な実施形態について説明したことが認められるであろうが、本発明の主旨および範囲から逸脱することなく、種々の変更も行えることも認められよう。したがって、本発明は、添付した特許請求の範囲による以外は、限定されないこととする。

【図1】

【図2】

【図3】

【図4】