JP6231020B2 - クラウドコンピューティング環境におけるプロセスの調整 - Google Patents

Description

分野
この発明はクラウドコンピューティングに関する。特定的には、この発明はクラウドコンピューティングにおけるプロセスの調整に関する。

背景
クラウドコンピューティングは、ユーザが、ネットワークによって接続されるインフラストラクチャ上でデータを保存し計算プロセスを動作させる態様である。したがって、物理的なインフラストラクチャを購入する必要がなく、ユーザは、他のエンティティによって所有されるインフラストラクチャ上で実行され保存されるべく、プロセスおよびデータを送信する。ユーザは、ユーザが所望するデータ保存量または処理能力量の代価のみを支払う。これは、ユーザが、実際の物理的かつ莫大なコンピューティングリソースを所有せずには不可能であろうコンピューティングリソースを利用することを可能にする。クラウドコンピューティングは、利用可能な多くのリソースのため、大きな可能性を開く。しかし、まさにその性質によって、クラウドコンピューティングは、効率的に組織化することが困難な非常に多くのツールおよびリソースを有する。

概要
コンピュータクラウドリソースを管理するシステムおよび方法は、オーケストレーションサイトとして機能する少なくとも１つのサーバを介して、少なくとも１つのユーザから少なくとも１つのクラウドリソース管理プランを受けるステップと、少なくとも１つのサーバを介して、少なくとも１つのクラウドリソース管理プランを少なくとも１つのストレージに保存するステップと、オーケストレーションマネージャとして機能する少なくとも１つのサーバを介して、少なくとも１つのクラウドリソース管理プランを少なくとも１つのデータベースにおいて検索するステップと、クラウドリソース管理プランを、少なくとも１つのサーバを介して、少なくとも１つのサイトコントローラで実行するステップとを含む。

これらの例では、さらに、オーケストレーションサイトおよびオーケストレーションマネージャは、分散型メッセージ通信バス上で通信するようにさらに構成される場合を含む。さらに、通信は、少なくとも１つのクラウドリソース管理プランが実行に対してレディ状態であるかどうかに関する情報を含む。

さらに他の例では、少なくとも１つのクラウドリソース管理プランは、少なくとも１つのクラウドリソースのグループを含む。そして、少なくとも１つのクラウドリソースのグループは、少なくとも１つのクラウドリソース、および少なくとも１つのクラウドリソースに関するポリシーを含む。

いくつかの例では、クラウドリソース管理プランは、少なくとも１つのクラウドリソースのグループと他のクラウドリソースのグループとの遣り取り（interaction）に関する情報を含む場合を含む。さらに、クラウドリソース管理プランは、クラウドリソース管理プランの名称を含む。そして、少なくとも１つのサイトコントローラは、コンピュータクラウドリソースを含む。さらに他の例では、ストレージは、データベースおよびクラウドストレージの少なくとも１つである場合を含む。

例では、さらに、本システムおよび方法は、少なくとも１つのクラウドリソース管理プランは、少なくとも１つのサブオーケストレーションを駆動するようマスターオーケストレーションを構成することを含む命令を含む場合を含む。さらに、クラウドリソースは、サードパーティにより与えられるオブジェクトおよびサードパーティにより与えられるクラウドサービスの少なくとも１つを含む。

他の実施の形態では、クラウドリソースは、仮想マシン、物理マシン、オペレーティングシステム、ストレージサービス、ネットワーキングサービス、およびアプリケーションサービスまたはそれらの組合せである場合を含む。

図面の記載
この出願に記載される実施の形態のよりよい理解のために、以下の記載が、同様の参照番号は図面全体にわたって対応する部分を指す以下の図面と関連して、参照されるべきである。

いくつかの実施の形態に従ってオーケストレーションを形成するのに必要なステップの概要である。 いくつかの実施の形態に従うクラウドコンピューティングにおけるさまざまなオブジェクトを参照して図１のステップを概略的に示す。 いくつかの実施の形態に従うクラウドコンピューティングにおけるさまざまなオブジェクトを参照して図１のステップを概略的に示す。 いくつかの実施の形態に従うクラウドコンピューティングにおけるさまざまなオブジェクトを参照して図１のステップを概略的に示す。 いくつかの実施の形態に従ってあるオーケストレーションをどのように別のオーケストレーションに合わせることができるかを示す図２の拡張である。 さらに、いくつかの実施の形態に従って、複数の層のオーケストレーションが他のオーケストレーションを駆動するのを示す、図２および図３のさらなる拡張である。 いくつかの実施の形態に従ってこれらのオーケストレーションが実行されることができるシステムの概略的な概観である。 いくつかの実施の形態に従ってここに記載されるオーケストレーション技術を伴う用途に対して好適な、クラウドコンピューティングシステムの代替的な構造を示す概略図である。

詳細な記載
以下の詳細な記載において、多数の特定の詳細が、この文書において呈示された主題を示すよう述べられる。しかしながら、この主題がこれらの厳密な特定の詳細なしに実施されてもよいことが、当業者には明らかである。さらに、本記載は、例として与えられるものであり、後で主張されるどのような発明の範囲も限定するように用いられるべきでない。

多くの種類のコンピュータネットワークが今日存在する。非公開であり所有権を主張できるネットワーク、公開されているパブリックネットワーク、およびハイブリッドネットワークも同様である。これらのネットワークは、コンピュータプログラムが効率的に実行される態様で、コンピュータサーバとデータベースとを結び付ける。そのようなネットワークのいくつかの実施の形態は、「クラウドコンピューティング」として公知である。インターネットのようなそのようなネットワーク上では、クライアントユーザは、インフラストラクチャ、プラットフォームおよびアプリケーションのようなコンピュータリソースをすべて用いることができる。そのようなクラウドネットワークの物理的リソースはさまざまな物理的位置のまわりで分散されてもよいが、ともにネットワーク接続されることによって、より大きなリソースになることができる。さまざまなシステムおよび方法を用いて、そのようなクラウドネットワーク上でホストされ実行され得るリソースを管理することができる。

この文書に記載される技術は、ユーザが、ユーザのクラウドコンピューティングを、効率的であり、首尾一貫し、余剰化され、相互依存し、安全になるように調整することを可能にすることによって、これに対応することを求める。この「オーケストレーション（Orchestration）」は、高可用性（High Availability）、監視および持続性のためにユーザ定義のシステムコンポーネントの自動化された管理に対応して、ユーザが、システムの障害を追跡し、プロセスを管理し、コンピューティングクラウドにおいて、または多数のクラウド上で、複雑なプロセスを形成し調整することを可能にする。

オーケストレーションは、ユーザが異なるオブジェクトまたは他のオーケストレーションもしくはオブジェクトに対するリファレンスを指定することができ、それらの間の関係を確立することができ、それらに異なる種類のポリシーを適用することができる仕様である。これらのオブジェクトは、クラウドおよびクラウドに付加されるクラウドサービスエクステンションによって与えられるすべてのファーストクラスの特徴を含むが、それらに限定はされない。異なる種類の関係を指定することができる。「従属性」は関係の一例である。異なる種類のポリシーを適用することができる。「高可用性（ＨＡ）および自動スケール機能」はそのようなポリシーの数少ない例である。ユーザは、同じ、複数のクラウドまたはパブリッククラウド上で、いくつかのプロセスを協調させることができる。これらのプロセスは、クラウドによって与えられる任意の機能性／オブジェクトを含んでもよい。例：セキュリティポリシー、ストレージ協調、ネットワーキング、実際のＣＲ（仮想マシン、ＯＳコンテナまたは実際の物理マシンを含むがそれらに限定はされない計算リソース（computational resources））、クラウド上で可能にされる新たなクラウドサービス／エクステンションなど。

ユーザは、自身の所望のオブジェクトの収集物または他のオーケストレーションへのリファレンスを含んでもよい自身のオーケストレーションを形成／付加することができる。ユーザは、異なる種類のオブジェクト／リファレンス間の関係を確立し、ポリシーを適用することができる。例：ＨＡ。ユーザは、自身のオーケストレーションを形成した後、そのオーケストレーションを開始することができる。オーケストレーションが開始されると、クラウドオブジェクトはオーケストレーションにおける仕様に従ってオーケストレーションされる。オーケストレーションはオブジェクトの調整である。１つのオーケストレーションは、他のオーケストレーションを形成し管理することもできる。たとえば、マスターオーケストレーションは、３つの子オーケストレーション、それら自身の子のそれらの３つの各々などを駆動して、増大または急成長効果を与えることができる。

ちょうどオブジェクトがそれらの間において従属性を有することができるように、全オーケストレーションは同じことをすることができる。このようにして、別々のオブジェクトが調整されるだけではなく、オーケストレーション、協調して実行される、より複雑な一連のオブジェクトが、次いで調整される。クラウドアドミニストレータはユーザおよびグループをこのようにセキュリティとともに、または他のプロセスをセットアップすることができる。異なる種類の関係は、オブジェクトおよびオーケストレーション間において規定することができる。通常、ユーザ管理者／ユーザ／開発者などは、各自がパーミッションを有しているクラウドオブジェクトのみを指定することができることを念頭に置いておくことは、重要である。各個々のクラウドオブジェクトについてのパーミッション、アクセス、キーを含むすべての既存のセキュリティ機構が尊重される。たとえば：クラウド管理者はユーザ／グループ／ネットワークなどをオーケストレーションすることができ、一方、別のユーザはＣＲ（仮想マシン、ＯＳコンテナなど）をオーケストレーションすることができ、それらはさらにクラウドサービスを協調させることができる。

異なる種類のポリシーをクラウドオブジェクト上に適用することができる。ポリシーは、高可用性（それらが離れる場合には、異なるポリシーを適用し、たとえば同じ／別のクラウドにそれらを再形成するなど）、監視（オブジェクトの状態を監視する）、自動スケール機能（ある基準に基づいてオブジェクトを拡大または縮小する）を含むが、それらに限定はされない。クラウドはこれらのポリシーのそれ自身の実現例を与えることができ、またはユーザ／クラウド−管理者はカスタムポリシーを形成することができる。

したがって、オーケストレーションは、クラウドコンピューティングコンポーネント同士を、ともに、ユーザのための単一の管理し易い集合に結び付ける。たとえば、オーケストレーションで、ユーザは、ネットワーク、ネットワークセキュリティおよびストレージを、計算リソースのインスタンス化に関連付けることができ、それは、仮想マシン、ＯＳコンテナまたは実際の物理マシンを含むがそれらに限定はされない。このインスタンス化が自動的に再開され得るのは、それが何らかの理由のために終了する場合、監視され得る場合、または不能化され得る場合である。加えて、ユーザは、コンポーネントがどのようにオーケストレーションされるかのシーケンスに影響するよう、従属性を指定することができる。
概観
概観では、オーケストレーションの形成のためのステップが図１に示される。具体的には、１１０で、ユーザは、同様のタイプのオブジェクトをグループ化して、オーケストレーションプランまたは「oplan」を形成する。その後、１１２で、ユーザは１つ以上のポリシー、たとえば「高可用性」（ＨＡ）をその特定のoplanに付加する。次いで、１１４で、ユーザは、oplanに一意のラベルを付加する。それが終わると、１１６で、ユーザは、同様に形成されるが異なるように機能するoplanのさらなるグループ化したものを付加する。この段階１１８において、ユーザは、付加されたoplan間の関係を規定し、その後１２０で、「オーケストレーション」を形成している。したがって、オーケストレーションはオブジェクトのグループである。以下に示されるように、それは他のオーケストレーションをオブジェクトとして有することもできる。

図２（ａ）〜図２（ｃ）は、概略的に示されるクラウドコンピューティングオブジェクトを参照してこれらのプロセスを示す。図２（ａ）では、ユーザ（図示せず）は、同様のタイプのオブジェクト２１２ａ、２１２ｂおよび２１２ｃをオーケストレーションプラン２１４にグループ化している。ユーザは、「ポリシー」として概略的に示される１つ以上のポリシーを付加しており、この場合では一意のラベルＡをoplanに付加している。

図２（ｂ）では、ユーザは、（この例では２つの）他の、同様に形成されるが異なるように機能し、各々がそれら自体の名称（それぞれＢおよびＣ）ならびに「ポリシー」を伴う、oplan２１６および２１８を付加する。次いで、図２（ｃ）に示されるように、ユーザは、oplan２１４と２１６との間、および２１６と２１８との間に、同じ関係であってもなくてもよい関係２２０および２２２をそれぞれ規定している。この結果、全体的なオーケストレーション２２４が生じる。

したがって、オーケストレーションモデルはオブジェクトのグループ化を表し、すなわち、oplansは、後述される、oplanの、十分にリスト化された下位集合であり；ステータス（status）は、このオーケストレーションのための全体的なステータスであり；および、関係（relationships）は、関係のリストである。これは、２つ以上のoplan間の関係を規定する。「ｏ１＜ｏ２またはｏ２＞ｏ１」は、ｏ１がｏ２の前にあるべきである順序を意味するだろう。従属性が失敗する場合、後のoplanは開始されない。

さらに、上記について、oplanが特定のオブジェクトに対するオーケストレーションプランを表すこと、それがオーケストレーションの一部としてしか存在しないことは明らかである。それは、以下を含む多くの属性を含んでもよい、obj_type：オブジェクトのタイプを指す。それは、システムにおける他のモデルのための単なるベースパスである。例：launchplan（起動プラン）（vservice/vdhcpserviceなど）；object（オブジェクト）：オブジェクトディクショナリまたはobj_typeの名称のリスト。以下の例を参照；status（ステータス）：このoplanに対するステータス；およびha_policy：オブジェクトがたとえばインスタンスおよびlaunchplanなどとともに存続することをユーザが望む場合、ユーザはここでｈａポリシー（ha policy）を適用することができる。３つのポリシー−不能化、監視、およびアクティブ−をサポートすることが可能であり、不能化（disabled）は、オブジェクトが全く監視されないことを意味する。（これはデフォルトポリシーである）；監視（monitor）は、オブジェクトを監視し、何かがうまく行かないときには、単にエラーを報告する；アクティブ（active）は、オブジェクトを監視し、それが見出されないかまたはエラー状態である場合には、もう一度それを形成しようと試み続けるか、またはそれを健全な状態に戻そうと試み続ける。

図３に示されるように、この概念をさらに拡大して、単一のオーケストレーション、たとえば図２を参照して形成されたオーケストレーション２２４；が別のオーケストレーション３１０をオブジェクトとして有することができるようできる。先のように、この付加されたオーケストレーション３１０は、それ自体が、一意のラベル「Ｄ」およびポリシーをオーケストレーションレベルにおいて有し、さらに、図２を参照して形成されたオーケストレーション２２４と規定された関係３１２を有する。したがって、単一のオーケストレーションが他のオーケストレーションを駆動することができる。

さらに、図４に示されるように、単一のマスターオブジェクト４１０はオーケストレーション４１２を駆動することができ、オーケストレーション４１２はそれ自体が他のオーケストレーション４１４ａ、４１４ｂおよび４１４ｃを駆動することができる。これらのオーケストレーション４１４ａ、４１４ｂおよび４１４ｃはそれら自体がさらに他のオーケストレーション４１６ａおよび４１６ｂなどを駆動することができ、したがって、さらに拡張する「キノコ形効果」を形成することができる。

この文書に記載される技術の実現のためのシステムが図５に示される。具体的には、システム５１０は２つの主要コンポーネント、つまりサイトコントローラ、オーケストレーションサイト５１２を有し、それは、ウェブＡＰＩ（たとえばＲＥＳＴ、ＳＯＡＰなど）インターフェイス５１４を露出するよう機能する。さらに、それは、データベース（ＤＢ）５１６のようなストレージに対してオーケストレーションを付加／削除し、それをオーケストレーションマネージャ５２４の１つに割当てる。ストレージは、さらに、クラウドストレージでもあり得る。加えて、マネージャ、オーケストレーションマネージャ５２４は、オブジェクトをRestを介して（Restfully）または他の態様で管理することによって、実際のオーケストレーションを管理して、「高可用性」（ＨＡ）、監視および他の特徴を与える。この図はさらに複数個のコントローラ、サイトコントローラ５３０を示す。この出版−購読型機構（publish subscribe mechanism）は、同じクラウド上に、または複数のクラウドにわたって、存在することができる。

図６は、ここに記載されるオーケストレーション技術を伴う使用に対して好適な、クラウドコンピューティングシステムの代替的な構造を示す概略図である。この図では、ＡＰＩ６１０を用いて、分散する負荷分散部６３０を介してクラウド６２０に通信する。負荷分散部６３０は異なるオーケストレーションマネージャ６４０、６４２にサービスを分散し、オーケストレーションマネージャ６４０、６４２は、各々、分散型データベースシステム、分散型データストア６５０と通信状態にある。メッセージ通信サービス６６０は、クラウド６２０上および他の可能なクラウド（図示せず）間で、分散型データベースシステム、オーケストレーションマネージャ６７０、６７２および負荷分散部６３０間の通信を調整する。

より十分に以下に記載されるように、このシステムは、ユーザが、複数個のオブジェクトをグループ化して、付加／獲得／削除／更新のような多くの共通機能をオーケストレーションし；ステータスを監視し；高可用性を与え；異なるオブジェクト間の関係を指定し、あるオブジェクト、たとえばインスタンスおよびクラウドサービスを自動スケーリングすることを可能にする。

上に記載されるこのシステムおよび方法の使用を、ここで、特定の非限定的な例を参照して記載する。
オーケストレーションを用いた運用
記載されるように、オーケストレーションは高可用性、監視および持続性のためのユーザ定義されたシステムコンポーネントの自動化された管理である。オーケストレーションはウェブＡＰＩ／ＣＬＩ／ＵＩを介して利用可能になり得るが、それらは他のインターフェイスまで拡張することができる。たとえば、非限定的な例では、ウェブコンソールまたはコマンドラインのいずれかで、オーケストレーションを用いて運用することができ：ウェブコンソールは、基本的な、単純なオーケストレーションに対して十分である。より複雑なオーケストレーションは、JSONファイルに保存され、次いで、nimbula-apiコマンドで付加、開始、停止、または削除されることができる。

これらの特定の例は限定として見られるべきではない。したがって、オーケストレーションは、任意のドキュメント／オブジェクト仕様記述言語、たとえばJSON/YAML/XMLなどにおいて指定することができる。

説明するために、次の項目が以下のように調査される：単純なオーケストレーション；オーケストレーションを行なうための一般化されたプロセス；オーケストレーションのステータス；コンポーネントの数、従属性を指定すること、およびオーケストレーションをネスト化すること；コマンドライン上でオーケストレーションを用いて運用する例；およびAmazon EC2でのオーケストレーション。この例はEC2を考慮しているが、単一のオーケストレーションがプライベートクラウドおよびパブリッククラウドにわたることができることが注目されるべきである。Amazon EC2は単に１つの例である。その後、付加的特徴も探究される。
単純なオーケストレーション
一例は、仮想マシンを開始することを含み、マシンイメージリストの名称および所望されるシェイプは既知である。コマンドラインから、たとえば、オーケストレーションは以下の例に示されるように開始されてもよい。

nimbula-api orchestrate simple /acme/imagelists/lucdi64 medium
nimbula-api orchestrate simpleの完全な詳細は、高可用性ポリシー、ならびにインスタンスおよび他のオーケストレーション関連のコマンドの数を指定する方法を含んで、コマンド・ライン・インターフェイス・リファレンス・システムにあり、その詳細を、ここに引用により援用する。
オーケストレーションを行なうための一般化されたプロセス
オーケストレーションを用いて運用する基本的な例示的プロセスは以下のとおりである：
ｉ．最低でも以下を含んで、オーケストレーションを形成する。コマンドライン上での使用に対して、オーケストレーションはJSONフォーマットでファイルに保存される；Amazon EC2でのオーケストレーションを参照されたい。［重要なことに、このJSON例ならびに後のＣＬＩ例は、これを達成することができる複数の態様のほんの２つである。］
・その名称。

・その「高可用性ポリシー：」：アクティブ、監視、または無。
・インスタンス構成、仮想イーサネット、パーミッション、セキュリティリストおよびその他のような、オーケストレーションすべきオブジェクトのタイプ。

・オブジェクトタイプに依存する付加的情報。
ｉｉ．オーケストレーションをシステムに付加する。

ｉｉｉ．オーケストレーションを開始する。
ｉｖ．オーケストレーションを監視、更新、停止、または削除する。
ポリシー
上に示されるように、オーケストレーションに対してさまざまなポリシーを指定することができる［クラウドもそれら自体のポリシーを指定することができ、それらはoplanに適用することができる。］。たとえば、オーケストレーションに対して３つの高可用性ポリシーの１つを指定することができ、それは、それがどのようにシステムによって管理されるかに影響する。高可用性は、分散問題、故障状態、またはある状況における他の変更の場合に、余剰プロセスをオーケストレーションする能力である。それは、オーケストレーションにおいて実行される柔軟でフェイルセーフの一連のオブジェクトを可能にする。

一般に、最低でも、ユーザは、自分がオーケストレーションにおいて指すすべてのオブジェクトについての使用のパーミッションを有していなければならず；さもなければ、オーケストレーションは正確に開始しない。
オーケストレーション可能なコンポーネント、ユーザおよびオブジェクトパーミッション、ならびにオブジェクト生成
クラウドによって与えられる任意のオブジェクト／機能性／特徴がサポートされる。他のオーケストレーションまたはオブジェクトへのリファレンスもサポートされる。さらに、それは、クラウドに動的に付加されるオブジェクト／機能性をサポートする。

これらは、さらに、手動で作成される、JSONフォーマットにおけるオーケストレーションにおけるobj_typeフィールドに対する有効な値でもあり；以下に記載されるAmazon EC2でのオーケストレーションおよびJSONフォーマットでのオーケストレーションを参照されたい。さらに、一般に、最低でも、オーケストレーションにおいて言及するすべてのオブジェクトにおいてユーザおよびオブジェクトパーミッションを有さなければならず；そうでなければ、オーケストレーションは開始しない。

オーケストレーションにおいて言及されるネットワーク、ストレージ、セキュリティリストまたは他のオブジェクトは、前もって形成されなかった場合、オーケストレーションが開始するときに生成され、オーケストレーションが停止するときに破壊される。ネスト化されたオーケストレーション（「オーケストレーションをネスト化する」を参照）については、最上位レベル（マスターオーケストレーション）でのオブジェクトのみが開始および停止において生成および破壊される。
オーケストレーションのステータス
オーケストレーションの状態は時間とともに変化する。オーケストレーションの開始または停止は、それが規定するオブジェクトを開始または停止し；これは非同期であり、そのため、完全に開始または停止するのにいくらかの時間が必要とされるかもしれない。オーケストレーションを注視することにより、変化を見ることができる。

非限定的な例として、オーケストレーションの考えられ得る状態は以下のようであり得る（これは例としてであり、オーケストレーションは以下のステータスを反映することができるが、それはこれらのみに限定はされない）：

コンポーネントの数、従属性を指定する、およびオーケストレーションをネスト化する
任意の単一のオーケストレーションにおいて、多くのコンポーネントを含むことができる。さらに、オーケストレーションは、他の「ネスト化された」オーケストレーションへのリファレンスを含むことができ、したがって、コンポーネントの数に実効的な制限はない。ネスト化されたオーケストレーションの例については、「オーケストレーションをネスト化する」を参照されたい。オーケストレーションにおけるコンポーネントがそれらの互いへの従属性を開始するシーケンスを指定することができる。ある例については、「従属性を伴う複数のオブジェクト」におけるセクションを参照されたい。
コマンドライン上でオーケストレーションで運用する例
このセクションは、仮想マシンのインスタンス化を付加、開始、監視、および停止する、単純なオーケストレーションで運用する例である。オーケストレーションのためのnimbula-api上のシンタックスおよびパラメータについての十分な詳細は、コマンドラインインターフェイスディレクタコマンドラインインターフェイスリファレンスシステムにある。

この例におけるオーケストレーションは、「ベーシックオーケストレーション（Basic orchestration）」において示され：インスタンスを構成しlpl.jsonと呼ばれるファイルに保存される。

ｉ．オーケストレーションをシステムに付加する。
・オーケストレーションの名称はJSONファイルそれ自体において指定される。

・この例は、出力を十分に表示するために-f jsonオプションを用いる。
・付加の後、オーケストレーションのステータスは「stopped(停止された)」である。

ｉｉ．オーケストレーションを開始する。開始直後に表示されるステータスは、「stopped(停止された)」であるかもしれず、なぜならば、オーケストレーションのすべてのコンポーネントを開始することは時間がかかり得、非同期であり、時間かかり得るからである。

ｉｉｉ．オーケストレーション経過を注視する。この例では、ステータスは「Ready(レディ状態)」に変化している。さらに、エラーは報告されていない。オーケストレーションはフル稼働中である。

ｉｖ．オーケストレーションを停止する。停止直後に表示されるステータスは、「Ready(レディ状態)」であるかもしれず、なぜならば、オーケストレーションのすべてのコンポーネントを停止することは、非同期であり、時間がかかるからである。

ｖ．オーケストレーションを再度注視する。ステータスは、現在、「Stopped(停止された)」である。

Amazon EC2でのオーケストレーション
通常ＥＣ上でインスタンスを起動することができるように、Amazon EC2または任意の他のプライベート／パブリッククラウドでコンポーネントをオーケストレーションすることができる。オーケストレーションのインスタンス構成部分においては、以下の例に示されるように、１つのオーケストレーションにサイトおよびアカウントの詳細を含む必要がある：

オーケストレーションサンプラ
ここに呈示されるのは、仮想マシンのインスタンス化のためのJSONフォーマットにおけるオーケストレーションである。具体的には、このセクションは、ベーシックオーケストレーションをカバーし：インスタンスおよび完全な注釈付きのインスタンス構成を構成する。後で別の標題の下で示されるように、さまざまな用途に対する他のいくつかのオーケストレーションとしてのJSONフォーマットにおけるオーケストレーション。
ベーシックオーケストレーション：インスタンスを構成する
このオーケストレーションは単一のオブジェクト：イメージリスト/nimbula/public/lucid64において小さなシェイプ上に保存されるデフォルトマシンイメージから仮想マシンをインスタンス化するプランを有する。高可用性ポリシーはアクティブに設定される。

この例は仮想マシンのまわりに集中しているが、それは任意の計算リソース（ＣＲ）に当てはまることもあることに注目すべきである。クラウドベンダーまたはサードパーティクラウドサービス開発者によって与えられる負荷分散部、自動スケーリング機能、DNS、Platform As a Service（サービスとしてのプラットフォーム）（PaaS）のような、任意の、より高いレベルのアプリケーションサービス。
完全な注釈付きのＣＲ構成
オーケストレーションは、起動されるべきさまざまなインスタンス、それらの間の関係、ならびにそれらのネットワーキング、ストレージおよびセキュリティ特性を記載することができる。以下は、異なるノードならびに主要および２次的なデータベース上で動作しなければならない、主要および２次的なウェブサーバの単一のインスタンスに対するオーケストレーションである。この例は特定のクラウド上でのＣＲ構成のものであるが、オーケストレーションは任意の特定のクラウドに限定されないことを理解することが重要である。それらは、クラウド実現例、複数のクラウドおよびハイブリッドクラウドなどにわたる。

この例示オーケストレーションの要素はリスト化の後に詳細にされる。

クラウドリソース（ＣＲ）は、ａ）仮想マシン、物理マシンまたはＯＳコンテナ、ｂ）プライベートまたはパブリッククラウドによって提供される任意のストレージサービス、ｃ）プライベートまたはパブリッククラウドによって提供される任意のネットワーキングサービス、およびｄ）プライベートまたはパブリッククラウドによって提供される任意の特徴を含むが、それらに限定はされない。

Nimbulaクラウドにおいて計算リソース（ＣＲ）を構成することにおいては、Relationships（リレーションシップ（関係））およびInstances（インスタンス）を含むことができる。Amazonまたは他のいくつかのクラウドについては、これらのパラメータは異なることになり、オーケストレーションはＣＲを任意のクラウド上で構成することができる。

Relationshipsは、さまざまなインスタンスが同じもしくは異なるノードまたは同じもしくは異なるクラスタで起動されるべきかどうかのような、さまざまなインスタンス間の関係を規定することを可能にする。relationshipsの要素の非限定的な例は：same_node（同じノード）、different_node（異なるノード）、same_cluster（同じクラスタ）およびdifferent_cluster（異なるクラスタ）である。

各インスタンスのタイプは、起動プランにおいて別々に規定することができる。各インスタンスタイプについては、以下のパラメータを指定することができる：
「Shape」
１つのインスタンスを実行するのに必要とされるＲＡＭの量およびＣＰＵの数を伴う有効なシェイプ。
「Version」
イメージリストからどのマシンイメージを実行すべきかを識別するバージョン番号。
「tags（オプショナル）」
エンドユーザの使用に対するインスタンスにタグをつけるストリングのリスト。インスタンスに対して人に親切なタグを生成することは、インスタンスリスト化中において特定のインスタンスを容易に識別することを可能にする。これらのタグはインスタンスの内部から入手可能ではない。オーケストレーションにおけるユーザ定義のパラメータ（インスタンス構成）を参照。
「networking（オプショナル）」
networking要素は、システムネットワークサービスをサポートするのに関係する３つの下位要素：以下に記載されるvEthernet、seclistsおよびnatの仕様を可能にする。

networking要素のある組合せは一緒には可能にされないので、networking要素を構築するときには注意する。

vEthernet―vEthernetは「仮想イーサネット（vEthernet）について」において論じられる。vEthernetはセキュリティリストおよびＮＡＴとともにサポートされないので、vEthernetフィールドは、そのＮＩＣがさらにセキュリティリストおよび／またはＮＡＴが指定される場合には、省略されるかまたはデフォルトのvEthernet/nimbula/public/defaultに設定されるべきである。vEthernet下位要素を空のストリング（""）にセットすることは、受入可能ではない。

seclists - Error:リファレンスソース見つからず。インスタンスは６４個までのセキュリティリストに属することができる。すべての各顧客に対して、デフォルトセキュリティリスト/customer/default/defaultがある。セキュリティリストタグなしでＶＭを起動する場合、それは顧客のデフォルトセキュリティリストに割当てられる。

nat−ネットワークアドレス変換は、「分散型ＮＡＴを用いる」に記載される。システムの分散型ＮＡＴサービスは、システムサイトにおいて実行されるインスタンスにパブリックＩＰサービスを与える。起動プランは次のように用いることができる：
・インスタンスによる使用のため、その寿命中において、ＩＰプールから一時的なＩＰを得る（ippool要素）
・予め生成されたＩＰリザベーションを参照することによって、ＶＭに持続的なＩＰを取付ける（ipreservation要素）。
「storage_attachments（オプショナル）」
以下の下位要素とともにこのインスタンスに取付けるべきボリューム：
volume−インスタンスが取付けられるストレージボリュームの名称。あるボリュームをあるインスタンスに取付けることができるためには、使用のパーミッションがストレージボリュームにおいて必要であり、storageattachment.add（ストレージ取付け付加）パーミッションがインスタンスネームスペースの下で必要である。

index−indexはハイパーバイザに対してストレージボリュームをインスタンスに特定のデバイスとして取付けるよう命令するのに用いられる。たとえば、index = 1を指定すると、ストレージボリュームはｖｉｒｔｉｏ能力に依って/dev/vdaまたは/dev/sdaのいずれかとして露出される結果となる。Index = 2は/dev/[sv]dbなどとなる。
「placement_requirements（オプショナル）」
これらのパラメータは、オーケストレーションにおけるユーザ定義のパラメータにおいて論じられる（インスタンス構成）。ユーザは、プロパティを起動プランにおいてplacement_requirementsとして指定することができるように、プロパティにおいて使用のパーミッションを有していなければならない。
「Imagelist」
イメージリストのフルパス名
「attributes（オプショナル）」
このマシンイメージのインスタンスが起動されるときにそれに渡すことができるオプションのユーザ定義のパラメータ。「オーケストレーション、イメージおよびイメージリストにおけるユーザ定義の属性およびパラメータについて」を参照。
「Label」
起動プラン要素間の関係を規定するときに起動プランにおいてこのインスタンスを識別するように用いることができるラベル。
「Site」
このインスタンスがローカルサイト上にない場合にそれを起動したいサイト。フェデレーションについてさらに知りたい場合は、システムCloud Administrator Guideを参照。
「account」
アカウントは顧客と関連付けられるビリングコンテナである。顧客アドミニストレータは、Amazon EC2においてシステムAmazon EC2プロキシを介してワークロードを起動することができるようアカウントを生成するか、または関係のあるAmazon EC2プロキシを含むようデフォルトアカウントを更新しなければならない。デフォルトアカウントは、ワークロードをシステムサイトにわたって起動するよう用いることができ、この場合は、明示的にセットされる必要はない。アカウント情報は、すべてのコールを通過して、リモートサイトに渡される。ユーザは、フェデレーション目的に対して用いるアカウント上において使用のパーミッションを必要とする。アカウント情報は任意の起動コマンドで通過され：デフォルトアカウントまたは明示的に指定されたアカウントのいずれかが用いられる。あるアクションが、それがローカルで起動されるか、またはリモートのシステムサイトで起動されるかどうかに関係なく、ビリング可能であるかどうかは、ビリングがそのサイト内でどのようにセットアップされるか、および他システムサイトとのビリング構成に依存する。
JSONフォーマットにおけるオーケストレーション
ここに、サンプラとして呈示された、さまざまな目的に対するオーケストレーションの集合がある。背景については、オーケストレーションで運用することについての上記セクションを参照。具体的には、このセクションは、パーミッション；永久的なＩＰリザベーション；従属性を伴う複数のオブジェクト；およびオーケストレーションをネスト化することにおける例を挙げる。この例はJSONフォーマットにおいて挙げられるが、仕様記述言語はJSONに限定されない。代りに、これは単なる例である。
パーミッション

永久的なＩＰリザベーション
このオーケストレーションはＩＰリザベーションを生成し監視する。

従属性を伴う複数のオブジェクト
このオーケストレーションは、セキュリティリスト（プラン「Ａ」）およびセキュリティルール（プラン「Ｂ」）をウェブサーバインスタンスの保護（プラン「Ｃ」）のために規定する。第１のプランＡが開始され、次いでプランＢ、そして最後に、プランＣにおけるウェブサーバがインスタンス化される。

オーケストレーションをネスト化する
この例示オーケストレーションにおいては、他のいくつかのオーケストレーションは名称で指称される。

サードパーティ
システムは、ユーザが、ユーザ自身によって生成されたオブジェクトおよびプロセスだけでなく、サードパーティによって生成されたオブジェクトおよびプロセスを用いることをオーケストレーションすることも可能にする。これは、サードパーティオブジェクトおよびプロセスがクラウド内にシームレスに統合され、完全な利用可能性のためにＡＰＩまたはＣＬＩそれ自体において現れることができる、拡張可能なクラウドを可能にする。パラメータ化されたフィールドを用いて、テンプレートが、さらに、これらのオーケストレーションのために生成され、ユーザのコミュニティの中で共有されることができる。これは、コミュニティの中のアイデアの共有がマルチクラウドアプリケーションスタックを可能にすることを可能にする。ユーザは、他のオーケストレーションをそれらのテンプレートにおいて呼び、それによってより豊かなコラボレーションを可能にする。
オーケストレーションのトラブルシューティング／ステータス
オーケストレーションは、さらに、開発者がそのクラウドの全使用を直ちに観察することを可能にする。マスターオーケストレーションは、すべての相互依存のオーケストレーションがどのように実行されているかについての情報を表示することができる。何かが正確に働いていない場合、マスターオーケストレーションはその旨を示すことができる。オーケストレーションは、さらに、セキュリティルールが変更されたかどうか示すことができる。それは、クラウドの全体にわたって障害を発見し、それらを報告する。それは複数のクラウドの上において実行されているオブジェクトおよびオーケストレーション上において障害を発見し、同様にそれらを報告する。
クラウドレベルインターフェイス（ＣＬＩ）
システムに対するクラウドレベルインターフェイスの一例は、以下のように示される：

理解できるように、それは２つのオーケストレーションプラン、つまり起動プランである「tinyplan」、および別のオーケストレーションを指す「other-orchestration」からなる。この場合、オーケストレーションを「付加すること(adding)」はオーケストレーションを「開始すること（starting）」とは分離される。「開始（start）」は、オブジェクトの状態を単に変更することなので、クエリ引数は更新動作の一部として与えられる。

この場合、ＣＬＩコマンドはnimbula-api開始オーケストレーション/nimbula/public/o1であろう。RESTを介して（RESTfully）それはクエリ引数を更新動作の一部として指定する。たとえば、PUT http://api.<sitename>.nimbula/orchestration/nimbula/public/o1?action=START。
性能およびスケール
負荷分散は、異なるオーケストレーションマネージャにわたってオーケストレーションを分散することを介して達成される。このようにして、単一のオーケストレーションは複数のオーケストレーションオブジェクトを指すことができ、階層全体（すべて異なるマネージャに割当てられる）を駆動することができる。

結論
前述の記載は、説明の目的のために、特定の例を参照して記載された。しかしながら、上記の例示的議論は、網羅的であったり、またはこの発明を開示された形式そのものに限定するように意図されるものではない。多くの修正および変形が上記の教示に照らし可能である。これは、上に記載されるさまざまな主題の例を任意の組合せにおいて実施することを含む。それらの例は、この発明の原理およびその実用的適用例について最もよく説明し、それによって、他の当業者が、この発明を、企図される特定の使用に適したさまざまな修正とともに最もよく利用することを可能にするために選択され記載されている。

ここに開示されるように、この発明と整合する特徴は、コンピュータハードウェア、ソフトウェア、および／またはファームウェアを介して実現されてもよい。たとえば、ここに開示されるシステムおよび方法は、たとえば、データベース、デジタル電子回路系、ファームウェア、ソフトウェア、コンピュータネットワーク、サーバまたはそれらの組合せにおいてさらに含むコンピュータのようなデータプロセッサを含むさまざまな形式で実施されてもよい。さらに、開示された実現例のいくつかは特定のハードウェア構成要素を記載しているが、ここにおいてこの革新と整合するシステムおよび方法は、ハードウェア、ソフトウェアおよび／またはファームウェアの任意の組合せとともに実現されてもよい。さらに、ここにおけるこの革新の上記の特徴ならびに他の局面および原理は、さまざまな環境において実現されてもよい。そのような環境および関連する適用例は、この発明に従ってさまざまなルーチン、プロセスおよび／または動作の実行のために特別に構築されてもよく、またはそれらは、必要な機能性を与えるためにコードによって選択的に活性化または再構成される汎用コンピュータまたはコンピューティングプラットフォームを含んでもよい。ここに開示されるプロセスは、本来、どのような特定のコンピュータ、ネットワーク、アーキテクチャ、環境または他の装置にも関係せず、ハードウェア、ソフトウェア、および／またはファームウェアの好適な組合せによって実施されてもよい。たとえば、さまざまな汎用マシンがこの発明の教示に従って書かれたプログラムとともに用いられてもよく、または必要な方法および技術を実行するよう特殊化された装置またはシステムを構築することがより好都合であってもよい。

ロジックのような、ここに記載される方法およびシステムの局面は、プログラマブルロジックデバイス（「ＰＬＤ」）、たとえばフィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）、プログラマブルアレイロジック（「ＰＡＬ」）デバイス、電気的にプログラマブルなロジックおよびメモリデバイス、および標準セル方式に基づいたデバイス、ならびに特定用途向け集積回路などを含むさまざまな回路系のいずれか内にプログラミングされた機能性として実現されてもよい。局面を実現するための他のいくつかの可能性は、メモリデバイス、（ＥＥＰＲＯＭのような）メモリを伴うマイクロコントローラ、組込マイクロプロセッサ、ファームウェアおよびソフトウェアなどを含む。さらに、局面は、ソフトウェアに基づく回路エミュレーション、ディスクリートなロジック（シーケンスおよび組合せ）、カスタムデバイス、ファジー（ニューラル）ロジック、量子デバイス、および上記のデバイスタイプのいずれかのハイブリッドを有するマイクロプロセッサで実施されてもよい。基底にあるデバイス技術は、たとえば相補型金属酸化膜半導体（「ＣＭＯＳ」）のような金属酸化膜半導体電界効果トランジスタ（「ＭＯＳＦＥＴ」）技術、エミッタ結合ロジック（「ＥＣＬ」）のようなバイポーラ技術、重合体技術（たとえばシリコン共役ポリマーおよび金属共役ポリマー金属構造）、混合アナログおよびデジタルなど、さまざまなコンポーネントタイプにおいて与えられてもよい。

さらに、ここに開示されたさまざまなロジックおよび／または機能は、それらの挙動的、レジスタ転送、ロジックコンポーネント、および／または他の特性に関して、任意の数の組合せのハードウェア、ファームウェアを用いて、ならびに／またはさまざまなマシン読取可能またはコンピュータ読取可能媒体で実施されるデータおよび／もしくは命令として、可能にされてもよいことが注目されるべきである。そのようなフォーマット化されたデータおよび／または命令が実施されてもよいコンピュータ読取可能媒体は、さまざまな形式（たとえば光学的記録媒体、磁気記録媒体または半導体記録媒体）における不揮発性記録媒体、ならびにそのようなフォーマット化されたデータおよび／または命令を、ワイヤレス、光学的、もしくは有線上の信号送信媒体またはそれらの任意の組合せを介して転送するように用いられてもよい搬送波を含むが、それらに限定はされない。搬送波によるそのようなフォーマット化されたデータおよび／または命令の転送の例は、１つ以上のデータ転送プロトコル（たとえばＨＴＴＰ、ＦＴＰ、ＳＭＴＰなど）を介するインターネットおよび／または他のコンピュータネットワーク上の転送（アップロード、ダウンロード、電子メール、など）を含むが、それらに限定はされない。

もし前後関係が明確に他の態様を必要としなければ、明細書および特許請求の範囲の全体にわたって、「含む」、「含んでいる」などの文言は、排他的または網羅的な意味に対立するものとしての包含的な意味において；つまり「…を含むが、…に限定はされない」の意味において解釈される。単数または複数を用いる文言は、それぞれ複数または単数も含む。加えて、「ここにおいて」、「ここに」、「上記」、「以下」という文言、および同様の意味の文言は、この出願の任意の特定の部分ではなくこの出願を全体として指す。文言「または」が２つ以上の要素のリストを参照して用いられるとき、その文言はその文言の以下の解釈：つまり、リストにおける要素のいずれか、リストにおける要素のすべて、およびリストにおける要素の任意の組合せ、のすべてをカバーする。

この発明のある現在好ましい実現例が具体的にここに記載されたが、ここに示され記載されるさまざまな実現例の変形および修正が、この発明の精神および範囲から逸脱せずに、形成されてもよいことは、この発明が関係する当業者には明らかである。したがって、この発明は適用可能な法の支配によって必要とされる程度にまでのみ限定されることが意図される。

前述の記載は、説明の目的のために、特定の実施の形態を参照して記載された。しかしながら、上記の例示的議論は、網羅的であったり、またはこの発明を開示された形式そのものに限定するように意図されるものではない。多くの修正および変形が上記の教示に照らし可能である。実施の形態は、この発明の原理およびその実用的適用例について最もよく説明し、それによって、他の当業者が、この発明およびさまざまな実施の形態を、企図される特定の使用に適したさまざまな修正とともに最もよく利用することを可能にするために選択され記載されている。

Claims (13)

1. コンピュータクラウドリソースを管理する方法であって、
   オーケストレーションサイトとして機能する少なくとも１つのサーバが、少なくとも１つのユーザから、複数のオブジェクトに対する１以上の機能のオーケストレーションのために前記複数のオブジェクトを定義する情報を受けるステップを含み、
   前記複数のオブジェクトは互いに異なり、前記複数のオブジェクトの各々についての前記情報は、当該オブジェクトのインスタンスのための複数のパラメータを示し、
   前記オーケストレーションサイトとして機能する前記少なくとも１つのサーバが、前記オーケストレーションのために形成された少なくとも１つのクラウドリソース管理プランを少なくとも１つのストレージに保存するステップと、
   前記オーケストレーションサイトとして機能する前記少なくとも１つのサーバが、前記１以上の機能のうちの特定機能を実行するための入力パラメータを含むコマンドを受けるステップと、
   前記コマンドに基づいて、オーケストレーションマネージャとして機能する前記少なくとも１つのサーバが、クラウドリソース管理プランを前記少なくとも１つのストレージから検索するステップと、
   前記特定機能を実行するために、前記検索されたクラウドリソース管理プランを、前記オーケストレーションマネージャとして機能する前記少なくとも１つのサーバが、少なくとも１つのサイトコントローラで実行するステップとをさらに含む、方法。
2. コンピュータクラウドリソースを管理する方法であって、
   少なくとも１つのストレージと、
   少なくとも１つのサーバとを含み、前記少なくとも１つのサーバは、少なくとも１つのユーザから、複数のオブジェクトの１以上の機能のオーケストレーションに対する前記複数のオブジェクトを定義する情報を受けるように構成され、
   前記複数のオブジェクトは互いに異なり、前記複数のオブジェクトの各々についての前記情報は、当該オブジェクトのインスタンスの複数のパラメータを示し、
   前記少なくとも１つのサーバはさらに、
   前記複数のオブジェクトを１以上のタイプにグループ化し、
   前記グループにおける各オブジェクトにポリシーを割当て、
   前記少なくとも１つのストレージに、前記オーケストレーションのために形成された少なくとも１つのクラウドコンピューティングリソースオーケストレーションプランを保存し、
   前記１以上の機能のうちの特定機能を実行するための入力パラメータを含むコマンドを受け、
   前記少なくとも１つのクラウドコンピューティングリソースオーケストレーションプランは実行に対してレディ状態である旨を通信し、
   前記コマンドに基づいて、前記少なくとも１つのストレージから、クラウドコンピューティングリソースオーケストレーションプランを検索し、
   前記特定機能を実行するために、少なくとも１つのサイトコントローラで、前記検索されたクラウドコンピューティングリソースオーケストレーションプランを実行するように構成され、
   前記少なくとも１つのサイトコントローラはクラウドリソースを制御する、方法。
3. コンピュータクラウドリソースを管理するシステムであって、
   少なくとも１つのストレージと、
   少なくとも１つのサーバとを含み、前記少なくとも１つのサーバは、
   オーケストレーションサイトとして機能するように構成され、
   前記オーケストレーションサイトは、少なくとも１つのユーザから、複数のオブジェクトに対する１以上の機能のオーケストレーションのために前記複数のオブジェクトを定義する情報を受けるように構成され、
   前記複数のオブジェクトの各々は、互いに異なり、前記複数のオブジェクトの各々についての前記情報は、当該オブジェクトのインスタンスのための複数のパラメータを示し、
   前記オーケストレーションサイトは、さらに、
   前記オーケストレーションのために形成された少なくとも１つのクラウドリソース管理プランを少なくとも１つのストレージに保存し、前記１以上の機能のうちの特定機能を実行するための入力パラメータを含むコマンドを受けるように構成され、
   前記少なくとも１つのサーバはさらに、
   オーケストレーションマネージャとして機能するように構成され、
   前記オーケストレーションマネージャは、前記コマンドに基づいて、前記少なくとも１つのストレージからクラウドリソース管理プランを検索し、前記特定機能を実行するために前記検索されたクラウドリソース管理プランを少なくとも１つのサイトコントローラで実行するように構成される、システム。
4. 前記オーケストレーションサイトおよび前記オーケストレーションマネージャは、分散型メッセージ通信バス上で通信するようにさらに構成される、請求項３に記載のシステム。
5. 前記通信は、前記少なくとも１つのクラウドリソース管理プランが実行に対してレディ状態であるかどうかに関する情報を含む、請求項４に記載のシステム。
6. 前記少なくとも１つのクラウドリソース管理プランは、少なくとも１つのクラウドリソースのグループを含む、請求項３〜５のいずれか１項に記載のシステム。
7. 前記少なくとも１つのクラウドリソースのグループは、少なくとも１つのクラウドリソース、および前記少なくとも１つのクラウドリソースに関するポリシーを含む、請求項６に記載のシステム。
8. 前記クラウドリソース管理プランは、前記少なくとも１つのクラウドリソースのグループと他のクラウドリソースのグループとの遣り取りに関する情報を含む、請求項７に記載のシステム。
9. 前記クラウドリソース管理プランは、前記クラウドリソース管理プランの名称を含む、請求項３〜８のいずれか１項に記載のシステム。
10. 前記少なくとも１つのサイトコントローラは、クラウドリソースを含む、請求項３〜９のいずれか１項に記載のシステム。
11. 前記ストレージは、データベースおよびクラウドストレージの少なくとも１つである、請求項３〜１０のいずれか１項に記載のシステム。
12. 前記少なくとも１つのクラウドリソース管理プランは、少なくとも１つのサブオーケストレーションを駆動するようマスターオーケストレーションを構成することを含む命令を含む、請求項３〜１１のいずれか１項に記載のシステム。
13. クラウドリソースは、サードパーティにより与えられるオブジェクトおよびサードパーティにより与えられるクラウドサービスの少なくとも１つを含む、請求項３〜１２のいずれか１項に記載のシステム。

Images