(57)【要約】クラウド計算ネットワークのファブリック・コントローラーとクラウド計算ネットワークで実行されるサービス・アプリケーションとの間の調整を容易にするためのシステムおよびコンピューター可読媒体を提供する。最初に、サービス・アプリケーションのロール・インスタンス（１以上）を含むアップデート・ドメイン（ＵＤ）を選択し、サービス・アプリケーションは、ステートフル・アプリケーションが、それに対して実行されるテナント・ジョブを受け取るターゲットとされることを、表す。調整のプロセスは、テナント・ジョブを実行するためにＵＤを準備することと、ＵＤのロール・インスタンス（１以上）をディスエーブル化してオフライン・コンディションにすることと、テナント・ジョブの実行を可能にすることと、テナント・ジョブの実行の完了後にロール・インスタンス（１以上）をレストアしてオンライン・コンディションにすることとを含む。ＵＤを準備することは、サービス・アプリケーション内に確立された管理ロールへ、テナント・ジョブを実行することのファブリック・コントローラーのインテントを通知することと、テナント・ジョブの影響を受けるロール・インスタンス（１以上）の内部状態（１以上）の複製の存在を通信する管理ロールの応答を受け取ることとを含む。
2015505095.tif 000002
【特許請求の範囲】
【請求項１】
コンピューター実行可能命令が具現化された１以上のコンピューター可読媒体であって、前記コンピューター実行可能命令は、実行されたときに、クラウド計算ネットワークのファブリック・コントローラーと前記クラウド計算ネットワークで実行されるサービス・アプリケーションとの間のインタラクションを容易にする方法を行わせ、前記方法は、
前記サービス・アプリケーションの１以上のロール・インスタンスを含む第１アップデート・ドメイン（ＵＤ）を選択するステップであって、前記１以上のロール・インスタンスはオンライン・コンディションで動作している、ステップと、
テナント・ジョブを実行するために前記第１ＵＤを準備するステップであって、
（ａ）前記サービス・アプリケーション内の管理ロールに、前記テナント・ジョブを実行することの前記ファブリック・コントローラーのインテントを通知するステップと、
（ｂ）前記テナント・ジョブにより影響を受ける前記１以上のロール・インスタンスの内部状態が、前記テナント・ジョブによる影響を受けない前記サービス・アプリケーションの部分で複製されたかを判定した後に、前記管理ロールから応答を受け取るステップと
を含むステップと、
オフライン・コンディションへと、前記第１ＵＤの前記１以上のロール・インスタンスのディスエーブル化を開始するステップと、
前記第１ＵＤに関して前記テナント・ジョブを実行することを許可するステップと
を含む、コンピューター可読媒体。
【請求項２】
請求項１に記載のコンピューター可読媒体であって、前記方法は更に、前記テナント・ジョブの実行を完了した後に、前記第１ＵＤの前記１以上のロール・インスタンスを前記オンライン・コンディションへとレストアするステップを含む、コンピューター可読媒体。
【請求項３】
請求項２に記載のコンピューター可読媒体であって、前記第１ＵＤの前記１以上のロール・インスタンスを前記オンライン・コンディションへとレストアするステップは、
前記テナント・ジョブにより影響を受けた前記１以上のロール・インスタンスが機能することを確認するステップと、
前記１以上のロール・インスタンスに関する前記テナント・ジョブの実行が完了したことを管理ロールに伝えるステップであって、それにより、前記サービス・アプリケーションに対して、前記１以上のロール・インスタンスを用いることを再開するように促すステップと
を含む、コンピューター可読媒体。
【請求項４】
請求項３に記載のコンピューター可読媒体であって、オフライン・コンディションへと前記１以上のロール・インスタンスをディスエーブル化するステップは、前記第１ＵＤ内の前記１以上のロール・インスタンスをホストするノードのセットを動作不能にするステップを含み、前記１以上のロール・インスタンスを前記オンライン・コンディションへとレストアするステップは、前記第１ＵＤ内の前記１以上のロール・インスタンスをホストする前記ノードのセットを動作可能にするステップを含む、コンピューター可読媒体。
【請求項５】
請求項４に記載のコンピューター可読媒体であって、前記ノードのセットのそれぞれは、前記サービス・アプリケーションの前記１以上のロール・インスタンスを実行できる物理マシンまたは仮想マシンを表し、前記ロール・インスタンスは、前記サービス・アプリケーションの機能をサポートする個々のコンポーネント・プログラムを表す、コンピューター可読媒体。
【請求項６】
請求項１に記載のコンピューター可読媒体であって、前記方法は更に、前記テナント・ジョブを実行するための、ロール・インスタンスの第２ＵＤを選択するステップを含み、前記第１ＵＤと前記第２ＵＤとはメンバーシップにおいて相互排他的であり、それぞれは、前記クラウド計算ネットワーク全体を通じての前記テナント・ジョブの伝播において個別的なフェーズを表す、コンピューター可読媒体。
【請求項７】
テナント・ジョブを実行するときに高優先度のジョブをスケジュールするためのコンピューター化した方法であって、
サービス・アプリケーションに対して前記テナント・ジョブを実行する指示を受け取るステップと、
前記サービス・アプリケーションの１以上のロール・インスタンスを含むアップデート・ドメイン（ＵＤ）を識別するステップであって、前記１以上のロール・インスタンスはオンライン・コンディションで動作している、ステップと、
前記テナント・ジョブを実行するために前記ＵＤを準備するステップと、
オフライン・コンディションへと、前記ＵＤの前記１以上のロール・インスタンスのディスエーブル化を開始するステップと、
高優先度のジョブをインプリメントする指示を受け取るステップであって、前記高優先度のジョブは、優先度スキーム内で前記テナント・ジョブより優先されることが予め定められている、ステップと、
前記テナント・ジョブのデプロイメントを、前記高優先度のジョブへ明け渡すステップであって、
（ａ）前記オンライン・コンディションへと前記１以上のロール・インスタンスをレストアする切り詰めたオペレーション・セットを行うことを、前記サービス・アプリケーションに命令するステップと、
（ｂ）前記テナント・ジョブをホールドに置くステップと、
（ｃ）前記１以上のロール・インスタンスに関して前記高優先度のジョブの実行を開始するステップと
を含むステップと、
前記高優先度のジョブの実行を完了した後に、前記テナント・ジョブのデプロイメントを再開するステップであって、
（ａ）前記オフライン・コンディションへの前記ＵＤの前記１以上のロール・インスタンスのディスエーブル化を再開するステップと、
（ｂ）前記１以上のロール・インスタンスに関する前記テナント・ジョブの実行を可能にするステップ
を含むステップと、
前記テナント・ジョブの実行が完了した後、前記ＵＤの前記１以上のロール・インスタンスを、前記オンライン・コンディションへとレストアするステップと
を含む方法。
【請求項８】
請求項７に記載のコンピューター化した方法であって、前記テナント・ジョブを実行するために前記ＵＤを準備するステップは、
前記サービス・アプリケーション内の管理ロールへ、前記テナント・ジョブを実行するインテントを通知するステップと、
前記テナント・ジョブによる影響を受ける前記１以上のロール・インスタンスの前記内部状態が、前記テナント・ジョブによる影響を受けない前記サービス・アプリケーションの部分で複製されたと判定した後、前記管理ロールから肯定的応答を受け取るステップか、または
前記テナント・ジョブによる影響を受ける前記１以上のロール・インスタンスの前記内部状態が前記１以上のロール・インスタンスに限られると判定した後、前記管理ロールから否定的応答を受け取るステップと
を含む、方法。
【請求項９】
請求項８に記載のコンピューター化した方法であって、
前記管理ロールから前記肯定的応答を受け取った後、前記１以上のロール・インスタンスに関して前記テナント・ジョブを実行することを可能にするステップと、
前記管理ロールから前記否定的応答を受け取った後、
（ａ）前記テナント・ジョブを実行する指示が顧客から開始されたものであるとき、前記内部状態の複製を可能とするために、前記１以上のロール・インスタンスに関する前記テナント・ジョブの実行を遅延させ、
（ｂ）前記テナント・ジョブを実行する指示がプラットフォームから開始されたものであるとき、前記１以上のロール・インスタンスに関する前記テナント・ジョブの実行を進めるステップと
を更に含む方法。
【請求項１０】
サービス・アプリケーションの部分へのテナント・ジョブの増分的デプロイメントを調整する方法を行うためのコンピューター・システムであって、コンピューター・ストレージ媒体と結合される処理装置を含み、前記コンピューター・ストレージ媒体は、前記処理装置により実行可能な複数のコンピューター・ソフトウェア・コンポーネントを格納しており、前記コンピューター・ソフトウェア・コンポーネントは、
前記サービス・アプリケーションの１以上のロール・インスタンスであって、前記サービス・アプリケーションの機能をサポートするコンポーネント・プログラムを表すロール・インスタンスと、
前記テナント・ジョブのデプロイメントを指揮するテナント変更マネージャーであって、デプロイメントを指揮することは、前記テナント・ジョブの前記デプロイメントの指示を通信することと、オフライン・コンディションへの前記１以上のロール・インスタンスのディスエーブル化を開始することと、前記１以上のロール・インスタンスに関する前記テナント・ジョブの実行を可能にすることと、オンライン・コンディションへの前記１以上のロール・インスタンスのレストアを開始することとを含む、テナント変更マネージャーと、
前記１以上のロール・インスタンスの内部状態を監視するための前記サービス・アプリケーションの管理ロールであって、前記テナント・ジョブの前記デプロイメントの前記指示を受け取った後、前記管理ロールは、前記テナント・ジョブの影響を受ける前記１以上のロール・インスタンスの監視された前記内部状態が、前記テナント・ジョブの影響を受けない前記サービス・アプリケーションの部分で複製されたかを判定することと、前記内部状態の可用性の指示を前記テナント変更マネージャーへ通信することとの責任を負う、管理ロールと
を含む、コンピューター・システム。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  一般に、分散型のサービス・アプリケーションは、クラウド計算ネットワーク（様々なノードにわたる）においてホストされ、主に、サービス・アプリケーション・コンポーネントの冗長性を通じて可用性を高くすることを意図している。これらのサービス・アプリケーションは、サービス・アプリケーション・コンポーネントのグループを含む複数の部分へと分割されることが多い。それらの部分の使用は、サービス・アプリケーションをホストするノードに対するアップデートや修復の間に、サービス・アプリケーション全体が使用不可能にならないことを補償する助けとなる。動作において、それらの部分は個々にオフラインへと引かれるので、サービス・アプリケーションの複数の部分のバランスは、オンラインで動作することを継続することを可能にする。即ち、理想的には、サービス・アプリケーションのユーザーは、サービス・アプリケーションの可用性が失われることに遭遇しない。
【０００２】
[0002]  現在、サービス・アプリケーションの分割は、場所と関連する基準（例えば、データ・センター内の共通ノード（common node）に存在するサービス・アプリケーション・コンポーネント）、または機能と関連する基準（例えば、同時に停止させる（ｔａｋｅｎ  ｄｏｗｎ）ことができない、特定のロールを行う全てのサービス・アプリケーション・コンポーネント）に基づく。サービス・アプリケーション・コンポーネントを複数の部分へとグループ化するこれらの基準は、ステートレス・アプリケーション（即ち、そのコンポーネントの外部に格納されるデータに依存する揮発性のソフトウェア）に対しては、ある程度は有効である。しかし、それらの基準は、サービス・アプリケーション・コンポーネントにおいて持続される持続的内部状態を維持するステートフル・アプリケーションに対しては、有効ではない。即ち、上記の基準を用いると、サービス・アプリケーション・コンポーネントの現在の状態を考慮できず、従って、サービス・アプリケーションの以前に形成された部分をオフラインへと引いたときに、サービス・アプリケーションの可用性を無くさせることになり得る。従って、ここで、内部状態を維持する分散型のサービス・アプリケーションに対しての高い可用性を可能にすることの上述の問題に対処する技術を紹介する。
【発明の概要】
【０００３】
[0003]  この概要は、以下の詳細な説明で更に説明する概念を、簡素化した形で紹介するために提供される。この概要は、特許請求の範囲に記載の主題事項の鍵となる特徴や本質的な特徴を特定することを意図しておらず、また、特許請求の範囲に記載の主題事項の範囲を決定する際の支援として用いることを意図していない。
【０００４】
[0004]  本発明の実施形態は、内部状態または複数の部分を維持するサービス・アプリケーションに関しての高い可用性を促進させるためのシステム、方法、およびコンピューター・ストレージ媒体と関連する。一般に、これらの「ステートフル」なサービス・アプリケーションは、クラウド計算ネットワーク（以下、「クラウド」）内の複数のノード（例えば、物理マシンや仮想マシン）にわたって分散される複数の部分を含み、ノードは、１以上のデータ・ストアに収容される。典型的には、クラウドはファブリック・コントローラーを備え、ファブリック・コントローラーは、一般には、クラウドの基礎的機能をサポートするコンピューター・リソースの正常性（health）のメンテナンスおよび管理の周囲の様々な職務に対する責任を負う。
【０００５】
[0005]  例えば、クラウドで実行されているステートフル・サービス・アプリケーションへのアップデートを調整する責任を負うことができ、これは、複数のステートフル・サービス・アプリケーションの複数の部分が存在している複数のノードに対して、目標を定めて再構成する。これらのアップデートの間、ファブリック・コントローラーは、ノードに対する目標を定めるときに、動作不能になるステートフル・サービス・アプリケーションが無いことを保証するために、サービス・アプリケーションの複数の部分の可用性を考慮する。更に、ファブリック・コントローラーは、サービス・アプリケーションの複数の部分の内部状態を考慮することにより、何れのノードに目標を定めるかを決定し、従って、アップデート中に何れの内部状態も完全にオフラインにされないことを保証することを試みる。
【０００６】
[0006]  例示の実施形態では、ファブリック・コントローラーは、ステートフル・サービス・アプリケーションがオンラインにとどまって完全に機能するような形で、ノードの再構成をスケジュールするために、アップデートを調整するためのソフトウェア・コンポーネント（ここでは「テナント変更マネージャー」という）に依存する。動作において、テナント変更マネージャーは、ファブリック・コントローラーとステートフル・サービス・アプリケーションの特化したコンポーネントとの間でインタラクションを行うプロトコルを用いる。それらの特化されたコンポーネント（ここでは「管理ロール」という）は、ステートフル・サービス・アプリケーションのロールのインスタンスなどのような、ステートフル・サービス・アプリケーションの機能部分の内部状態を監視するために、ステートフル・サービス・アプリケーション内でインプリメントされる。
【０００７】
[0007]  このインタラクションは、テナント変更マネージャーが、ステートフル・サービス・アプリケーション全体の高い可用性を一定的に維持するために、ロール・インスタンスの内部状態の可用性を考慮することにより、ステートフル・サービス・アプリケーション内の変更オペレーションの適切な順序付けを保証することにより、容易にされる。例として、この内部状態の可用性の考慮は、変更オペレーションの間に内部状態を推論し、この情報をテナント変更マネージャーへ報告する管理ロールを含む。テナント変更マネージャーは、ステートフル・サービス・アプリケーションの特定のロール・インスタンスにおける変更オペレーションまたは「テナント・ジョブ」をインプリメントする開始時間を確立するために、この情報を用いる。従って、テナント変更マネージャーと管理ロールとの間のインタラクションは、分散されたロール・インスタンスの個々の内部状態を考慮することにより、ステートフル・サービス・アプリケーションの真の可用性を評価する。
【０００８】
[0008]  本発明の実施形態は、添付の図面を参照して詳細説明する。
【図面の簡単な説明】
【０００９】
【図１】図１は、本発明の実施形態をインプリメントする際の使用に適する例示の計算環境のブロック図である。
【図２】図２は、本発明の実施形態をインプリメントする際の使用に適するデータ・センターを示すブロック図であり、データ・センターは、データ・センターの複数のノードにわたって分散させられるサービス・アプリケーションのオペレーションに適応してサポートするように構成される。
【図３】図３は、本発明の実施形態に従った、例示のホストする環境を示すブロック図であり、ロールのインスタンスは、データ・センター内でテナント・ジョブを増分的にインプリメントするためにアップデート・ドメインを形成するように、グループ化される。
【図４】図４は、本発明の実施形態に従った、ステートフル・ノードとステートレス・ノードとの双方のプロセス・フローのグラフィカル表現である。
【図５】図５は、本発明の実施形態に従った、テナント・ジョブをインプリメントする際の個々のオペレーションを行うための様々なコンポーネントを含むクラウド計算ネットワークを示すブロック図である。
【図６】図６は、本発明の実施形態に従った、ファブリック・コントローラーとサービス・アプリケーションとの間のインタラクションを示す、データ・センターの例示のトポロジーのグラフィカル表現である。
【図７】図７は、本発明の実施形態に従った、クラウド計算ネットワークのファブリック・コントローラーとサービス・アプリケーションとの間のインタラクションを容易にする方法の全体を示すフロー図である。
【図８】図８は、本発明の実施形態に従った、テナント・ジョブを実行するときに高優先度のジョブをスケジュールするための方法の全体を示すフロー図である。
【発明を実施するための形態】
【００１０】
[0017]  ここでは、本発明の実施形態の主題事項は、法定的な要求に適合するように特定的に説明される。しかし、説明自体は、本特許の範囲を限定することを意図していない。むしろ、発明者は、別の現存する技術や将来の技術と関連して、この書類に記載のステップと似た別のステップやステップの組み合わせを含むように、特許請求の範囲に記載の主題事項が別の方法で実施でき得ることを企図している。
【００１１】
[0018]  一般に、本発明の実施形態は、ステートフル・サービス・アプリケーションがそれらの顧客に対して高い可用性を維持することを可能にすることにより、それらのステートフル・サービス・アプリケーションのアップデートおよび修復をサポートするための、クラウド計算ネットワーク内の機構を紹介する。特に、それらの機構は、ステートフル・サービス・アプリケーションの部分（ここでは「ロール・インスタンス」という）に対してのアップグレード、構成変更、スケール・アップまたはダウン、および再配置のプロシージャーの間のそれらステートフル・サービス・アプリケーションの現在の可用性を管理することが、可能である。例示の実施形態では、それらの機構は、ステートフル・サービス・アプリケーションとファブリック・コントローラーとの間のインタラクションに依存しており、ファブリック・コントローラーは、ステートフル・サービス・アプリケーションのロール・インスタンスのライフサイクルを管理する。後に詳細に説明するように、１つの場合には、機構は、アップデートまたは修復を知的にスケジュールするようにインタラクションする、ファブリック・コントローラーに存在するテナント変更マネージャーと、ステートフル・サービス・アプリケーション内に存在する管理ロール（１以上）とからなる。
【００１２】
[0019]  ここで用いるフレーズ「ステートフル・サービス・アプリケーション」は、一般に、ステートがそれぞれのロール・インスタンスまたはプログラム・コンポーネントへ埋め込まれたサービス・アプリケーションのことをいう。例えば、銀行業務を行うための特定のオンライン・インターフェースを公開する仕事が与えられている金融機関のサービス・アプリケーション内では、状態は顧客データ（例えば、アカウント情報）を含むことができ、これは、サービス・アプリケーションのロール・インスタンス内に維持される。即ち、顧客データは、リモートの位置へアップロードされるのとは逆に、サービス・アプリケーションのロール・インスタンスにおいてローカルにホストされる。従って、サービス・アプリケーションが、クラウド計算ネットワーク内の様々なノードにわたって分散させられる場合、顧客に提供されるアカウント情報または「状態」もまた、クラウド計算ネットワーク内のノードにわたって分散させられる。更には、サービス・アプリケーションと銀行業務を行う複数の顧客がいるので、各ロール・インスタンスは、少し異なる内部状態を有し得る。
【００１３】
[0020]  従って、クラウド計算ネットワークの基礎となるプラットフォームの可用性および正常性を知ることと共に、そこで実行される分散型のサービス・アプリケーションの内部状態を理解することは、メンテナンスおよびリカバリーのオペレーションのタイミングをスケジュールすることの手助けとなる。例えば、メンテナンスおよびリカバリーのオペレーションを行うとき、サービス・アプリケーションの複数の部分をオフラインに持って行くことができる。それらの部分をオフラインに持って行くことは、特定の内部状態のコピーがオンラインに残っていない場合には、悪い方に影響することがあり、更には、サービス・アプリケーション全体をディスエーブルにする場合もあり得る。従って、本発明の実施形態は、様々な内部状態の位置を理解するため、およびそれぞれの内部状態のコピーがオンラインに残るように、メンテナンスおよびリカバリーのオペレーションを調整するための機構を含む。
【００１４】
[0021]  結果として、内部状態の位置を理解してのメンテナンスおよびリカバリーのオペレーションの調整は、ロール・インスタンスの内部状態の高い信頼性を達成することを手助けする。１つの実施形態では、調整は、特定の状態をローカルでホストするロール・インスタンスのうちの１つをオフラインへ持って行くことを可能とするために、同じロールの複数のインターフェースにわたる特定の状態を複製することを、含むことができる。例えば、ロールが、現在、データ・センター中に分散させられた５つのインターフェースを有し、かつ、ロール・インスタンスのうちの特定のものが、顧客により持続が望まれる状態を格納する場合、その格納された状態は、その特定のロール・インスタンスがオフラインへ持って行かれる前に、コピーされ、伝播され、５つのインスタンスのうちの別のもの（１以上）において維持される。このようにして、様々なノードの様々なロール・インスタンスにわたって格納された状態の複製は、特定の状態の信頼性を保証する。従って、特定のロール・インスタンスが、メンテナンスおよびリカバリーのオペレーションの範囲外で故障した場合でも、別のロール・インスタンスが、その故障したロール・インスタンスの格納された状態を持続する。
【００１５】
[0022]  メンテナンスおよびリカバリーのオペレーションの観点からの、状態を複製するための様々な異なる実施形態を説明したが、ここで説明したプロセスを介して別のタイプの適切なサービス・アプリケーションをアップデートできることや、本発明の実施形態がここで説明したステートフル・サービス・アプリケーションに限定されないことを、理解および認識すべきである。例えば、ステートレス・サービス・アプリケーションにも、クラウド計算ネットワークの基礎となるプラットフォーム内でテナント・ジョブを実行するときに、同様の様式で対処することができる。ここで用いられるフレーズ「ステートレス・サービス・アプリケーション」は、一般に、クラウド計算ネットワークによりホストされ、ストレージ・データを外部エンティティへオフロードするサービスのことをいい、外部エンティティは、ストレージ・データを管理することができる別のデータ・センターなどである。このデータ・センターは、様々な物理マシンの様々な状態を保持することができるが、多くの冗長性（例えば、多数のマシンにわたる多数のコピー）を生成することにより状態を管理することができる。
【００１６】
[0023]  従って、１つの態様では、本発明の実施形態は、コンピューター実行可能命令が具現化された１以上のコンピューター可読媒体と関連し、コンピューター実行可能命令は、実行されたときに、クラウド計算ネットワークのファブリック・コントローラーとクラウド計算ネットワークで実行されるサービス・アプリケーションとの間のインタラクションを容易にする方法を行わせる。方法は、最初に、サービス・アプリケーションの１以上のロール・インスタンスを含む第１アップデート・ドメイン（ＵＤ）を選択することを、含むことができる。典型的には、ロール・インスタンスは、オンライン・コンディションで動作しており、サービス・アプリケーションの機能をサポートするそれぞれのコンポーネント・プログラム（例えば、サービス・アプリケーションのロールの１つの複製）を表す。
【００１７】
[0024]  方法は、テナント・ジョブ（例えば、プラットフォームから開始されるアップデートや、顧客から開始されるアップデートや、プラットフォームから開始される修復や、顧客から開始される修復）の実行のために第１ＵＤを準備することを、更に含むことができる。例示の実施形態では、第１ＵＤを準備することは、少なくとも以下のステップ、即ち、サービス・アプリケーション内の管理ロールに、ファブリック・コントローラーの、テナント・ジョブを実行することのインテント（intent）を通知するステップと、テナント・ジョブにより影響を受けるロール・インスタンス（１以上）の内部状態が、テナント・ジョブにより影響を受けないサービス・アプリケーションの部分で複製されたかを判定した後に、管理ロールから応答を受け取るステップとを、含む。実施形態では、応答は、ロール・インスタンス（１以上）の内部状態を検査した後、および／または別のアクションを行った後に、管理ロールにより生成される。これらの別のアクションは、例えば、クラウド計算ネットワークのインフラストラクチャー内に構築されたチャンネルを用いて追加の情報（例えば、テナントのロールの状態）を取り出すことを、含むことができる。第１ＵＤのロール・インスタンス（１以上）の準備の後、オフライン・コンディションへのそれらのロール・インスタンス（１以上）のディスエーブル化が開始される。一般に、ロール・インスタンス（１以上）をディスエーブル化することは、第１ＵＤ内で１以上のロール・インスタンスをホストするノードのセットが動作しないようにすることを、含む。テナント・ジョブは、ロール・インスタンス（１以上）がオフライン・コンディションになった後に第１ＵＤで実行されることが、可能とされる。
【００１８】
[0025]  更に、方法は、テナント・ジョブの実行が完了した後に、第１ＵＤのロール・インスタンス（１以上）をオンライン・コンディションへとレストアすることを、含むことができる。例示の実施形態では、第１ＵＤのロール・インスタンス（１以上）をオンライン・コンディションへとレストアすることは、少なくとも以下のステップ、即ち、テナント・ジョブにより影響を受けたロール・インスタンス（１以上）が機能することを確認するステップと、ロール・インスタンス（１以上）へのテナント・ジョブの実行が完了したことを管理ロールに伝え、従って、サービス・アプリケーションに、タスクを行うためにロール・インスタンス（１以上）を用いることを再開するように促すステップとを、含む。一般に、第１ＵＤ内のロール・インスタンス（１以上）をオンライン・コンディションへとレストアすることはまた、ロール・インスタンス（１以上）をホストするノードのセットが動作するようにすることを、含む。第１ＵＤ内のロール・インスタンス（１以上）をオンライン・コンディションへとレストアした後、方法は、テナント・ジョブを実行するための、ロール・インスタンスの第２ＵＤを選択することにより、継続することができる。典型的には、第１ＵＤと第２ＵＤとは相互排他的であり、それぞれは、クラウド計算ネットワーク全体を通じてのテナント・ジョブの伝播において個別的なフェーズを表すことができる。
【００１９】
[0026]  別の態様では、本発明の実施形態は、テナント・ジョブを実行するときの高優先度ジョブをスケジュールするためのコンピューター化された方法と関連する。コンピューター化された方法は、サービス・アプリケーションにおいてテナント・ジョブを実行する指示を受け取る論理ステップと、サービス・アプリケーションの１以上のロール・インスタンスを含むアップデート・ドメイン（ＵＤ）を識別する論理ステップとを実行することを、含む。この点において、ロール・インスタンス（１以上）はオンライン・コンディションで動作している。ＵＤは、テナント・ジョブの実行のために準備され、その後、ＵＤのロール・インスタンス（１以上）は、オフライン・コンディションへとディスエーブルにされる。例示の実施形態では、テナント・ジョブの実行のためにＵＤを準備するプロセスは、サービス・アプリケーション内の管理ロールに、テナント・ジョブを実行することのインテントを伝える論理ステップ、および管理ロールから肯定的応答を受け取る又は管理ロールから否定的応答を受け取る論理ステップとを含む様々な論理ステップを、含む。
【００２０】
[0027]  典型的には、肯定的応答が受け取られるのは、管理ロールが、テナント・ジョブによる影響を受けるロール・インスタンス（１以上）の内部状態が、テナント・ジョブによる影響を受けないサービス・アプリケーションの部分で複製されたと判定した後である。テナント変更マネージャー（ファブリック・コントローラー内で動作する）が管理ロールから肯定的応答を受け取った後、テナント・ジョブは、ロール・インスタンス（１以上）へ実行することを可能にされるであろう。代わりに、否定的応答が受け取られるのは、管理ロールが、テナント・ジョブによる影響を受けるロール・インスタンス（１以上）の内部状態がそれらのロール・インスタンス（１以上）に限られると判定した後である。テナント変更マネージャーが管理ロールから否定的応答を受け取った後、複数のオペレーションが後に続き得る。１つの実施形態では、テナント・ジョブを実行する指示が、顧客から開始されたものであるとき、ロール・インスタンス（１以上）へのテナント・ジョブの実行は、内部状態の複製を可能とするために、遅延される。別の実施形態では、テナント・ジョブを実行する指示が、プラットフォームから開始されたものであるとき、ロール・インスタンス（１以上）へのテナント・ジョブの実行は、進めることを促される。
【００２１】
[0028]  或る後の時点で、高優先度のジョブをインプリメントする指示が受け取られる。ここで用いるフレーズ「高優先度」は、限定することを意味せず、優先度スキーム内でテナント・ジョブより優先されることが予め定められている任意のジョブを表し得る。高優先度のジョブをインプリメントする指示を受け取った後、テナント・ジョブのデプロイメント（deployment；配置、展開）が、高優先度のジョブへ明け渡される。例示の実施形態では、明け渡すプロセスは、以下の論理ステップ、即ち、オンライン・コンディションへとロール・インスタンス（１以上）をレストアする切り詰めたオペレーション・セット（truncated set of operations）を行うことをサービス・アプリケーションに命令する論理ステップと、テナント・ジョブをホールドに置く論理ステップと、ロール・インスタンス（１以上）において高優先度のジョブの実行を開始する論理ステップとを含む様々な論理ステップを、含む。
【００２２】
[0029]  高優先度のジョブの実行を完了した後、テナント・ジョブのデプロイメントが再開される。例示の実施形態では、再開するプロセスは、以下の論理ステップ、即ち、オフライン・コンディションへのＵＤのロール・インスタンス（１以上）のディスエーブル化を再開する論理ステップと、ロール・インスタンス（１以上）へのテナント・ジョブの実行を可能にする論理ステップとを含む様々な論理ステップを、含む。テナント・ジョブの実行が完了した後、ＵＤのロール・インスタンス（１以上）は、オンライン・コンディションへとレストアすることができる。例示の実施形態では、オンライン・コンディションへとロール・インスタンス（１以上）をレストアするプロセスは、以下の論理ステップ、即ち、テナント・ジョブにより影響を受けたロール・インスタンス（１以上）が機能することを確認する論理ステップと、ロール・インスタンス（１以上）へのテナント・ジョブの実行が完了したことを管理ロールに伝え、従って、サービス・アプリケーションに、様々なタスクを行うためにロール・インスタンス（１以上）の使用を再開するように促す論理ステップとを含む様々な論理ステップを、含む。
【００２３】
[0030]  更に別の態様では、本発明の実施形態は、サービス・アプリケーションのコンポーネント・プログラムに対してのテナント・ジョブのデプロイメントを調整する方法を行うためのコンピューター・システムと関連する。一般に、コンピューター・システムは、コンピューター・ストレージ媒体と結合される処理装置を含み、コンピューター・ストレージ媒体は、処理装置により実行可能な複数のコンピューター・ソフトウェア・コンポーネントを格納する。最初に、コンピューター・ソフトウェア・コンポーネントは、サービス・アプリケーションの１以上のロール・インスタンス、テナント変更マネージャー、管理ロール、ホスト・エージェント、ワイヤー・プロトコル、スケジューリング・コンポーネント、およびノード状態ドライバーを含む。実施形態では、ロール・インスタンスは、サービス・アプリケーションの機能をサポートするコンポーネント・プログラムを表す。テナント変更マネージャーは、典型的には、テナント・ジョブのデプロイメントを指揮するように構成される。デプロイメントを指揮するプロセスは、一般には、テナント・ジョブのデプロイメントの指示を通信することと、オフライン・コンディションへのロール・インスタンス（１以上のロール・インスタンス）のディスエーブル化を開始することと、ロール・インスタンス（１以上）へのテナント・ジョブの実行を可能にすることと、オンライン・コンディションへのロール・インスタンス（１以上）のレストアを開始することとを、含む。
【００２４】
[0031]  サービス・アプリケーションのコンポーネントである管理ロールは、典型的には、ロール・インスタンス（１以上）の内部状態を監視するように構成される。実施形態では、テナント・ジョブのデプロイメントの指示を受け取った後、管理ロールは、テナント・ジョブの影響を受けるロール・インスタンス（１以上）の監視された内部状態が、テナント・ジョブの影響を受けないサービス・アプリケーションの部分で複製されたかを判定する責任を、負う。また、管理ロールは、内部状態の可用性の指示をテナント変更マネージャーへ通信するように構成することができる。
【００２５】
[0032]  ホスト・エージェントは、典型的には、ロール・インスタンス（１以上）をホストするノードに存在する。動作において、ホスト・エージェントは、ロール・インスタンス（１以上）の期待状態（expected state）を、ワイヤー・プロトコルを介して、サービス・アプリケーションへ示す。ここで用いるフレーズ「期待状態」は、一般には、オフライン・コンディションまたすオンライン・コンディションを呈するというロール・インスタンスの目標を表す。スケジューリング・コンポーネントは、一般には、優先度スキームに従って高優先度のジョブをテナント・ジョブへ割り込ませるように、構成される。そして、ノード状態ドライバーは、一般には、テナント変更マネージャーの指揮の下で、オフライン・コンディションへとロール・インスタンス（１以上）をディスエーブル化するように、及びテナント・ジョブを実行するように、及びオンライン・コンディションへとロール・インスタンス（１以上）をレストアするように、構成される。
【００２６】
[0033]  上述のように、サービス・アプリケーションの全てのロール・インスタンスを同時にオフラインへ持って行くのとは逆に、テナント・ジョブは、フェーズに分割されて、サービス・アプリケーションのロール・インスタンスのグループにわたって増分的に行われることがしばしばある。従って、本発明の実施形態は、ホストする環境内またはデータ・センター内のアップデート・ドメインを識別することと関連する。ここで用いるフレーズ「アップデート・ドメイン」は、限定することを意味せず、一般には、サービス・アプリケーションの１以上のロール・インスタンスをホストし且つオフラインへ同時に持って行かれ得るノード（例えば、物理機構や仮想機構）のセットの記述のことをいう。特定の実施形態では、アップデート・ドメインにより記述されるノードのセットは、同時に使用不可能になり得る（例えば、それらのノードを、それらへソフトウェアをインストールするためにオフラインにするように、意図的に含めた後）ノードを表し、それらのノードに依存するサービス・アプリケーションが使用可能であり続けることを保証する。即ち、アップデート・ドメインのノードのセットは、典型的には、テナント・ジョブを実行するときに、同時に機能しないようにすることを許可される限定数のノードを含み、ノードのセットで実行されるロール・インスタンスがアップデート・ドメインの外部に複製を有することを保証するようにする。従って、アップデート・ドメインは、サービス・アプリケーションのオーナーに対して、サービス・アプリケーションの最小数のロール・インスタンスのみが同時に働かなくなることを保証するために、適切に設定される。
【００２７】
[0034]  アップデート・ドメインを確立することは、一般に、ホストする環境により課せられる様々な規則に従うことを含む。例えば、共通アップデート・ドメインへ加わり得るロールＡのインスタンスの数についての制限が存在し得る。また、ロールＡのインスタンスをもつ共通アップデート・ドメインへ加わり得るロールＢのインスタンスの数についての制限が存在し得る。一般に、ここで用いる「ロール」は、サービス・アプリケーションの機能部分のテンプレート記述を提供する。例えば、オンライン・ショッピング・サービス・アプリケーションの場合、３つのロールの中でそれぞれに分割される３つのコア・タスクがあり得、それらは、ロールＡ（購入の注文を受けるために第１ＧＵＩを呈示するタスクが割り当てられる）と、ロールＢ（購入の注文を行うためのタスクが割り当てられる）と、ロールＣ（購入の注文の状態を通信するために第２ＧＵＩを呈示するタスクが割り当てられる）とである。例示の実施形態では、それぞれのロールは、サービス・アプリケーションのプログラム・コンポーネントの特定のクラスを表す。典型的には、サービス・モデルは、それぞれのロールの幾つのインスタンスをデータ・センター内に置くかを描写し、インスタンスのそれぞれは、プログラム・コンポーネントまたはロールの特定のクラスの複製である。換言すると、各ロールは、各クラスのプログラム・コンポーネントのインスタンスのコレクションを表し、サービス・アプリケーションは、その機能を行うために、任意の数のクラスのプログラム・コンポーネントを有し得る。
【００２８】
[0035]  ロールは、それへ適用される構成設定を有することがよくある。１つの場合には、ロールの構成設定は、ロールの全インスタンスにより共有される集合的設定を含み得る。別の場合には、構成設定は、ロールの各インスタンスに特定的な個別的設定を含み得る。それらの個別的設定は、ロールのインスタンスにおいて格納される状態を含み得、その状態は、そのロール・インスタンスに特定的である。上述のオンライン・ショッピング・サービス・アプリケーションを参照すると、ロールＢのインスタンスにおいて格納される状態は、特定の顧客による特定の購入の注文の詳細であり得る。
【００２９】
[0036]  本発明の実施形態の概観を簡単に説明したが、以下で、本発明の実施形態をインプリメントするための適切な例示の動作環境を説明する。
動作環境
[0037]  最初に特に図１を参照すると、本発明の実施形態をインプリメントするための例示の動作環境が示されており、全体を計算デバイス１００として示している。計算デバイス１００は、適切な計算環境の単なる一例であり、本発明の使用や機能の範囲の限定を提案することを意図していない。計算デバイス１００は、示されたコンポーネントの何れか又は組み合わせと関連する依存性や必要性を有すると、解釈すべきではない。
【００３０】
[0038]  本発明は、パーソナル・データ・アシスタントや他の手持ち型デバイスなどのようなコンピューターや他の機械で実行される、プログラム・モジュールなどのようなコンピューター実行可能命令を含むコンピューター・コードや機械で使用可能な命令の一般的な状況で、説明され得る。一般に、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含むプログラム・モジュールは、特定のタスクを行う又は特定の抽象データ型をインプリメントするコードを指す。本発明は、手持ち型デバイス、消費者向け電子製品、汎用コンピューター、より専門的な計算デバイスなどを含む様々なシステム構成で実施することができる。本発明はまた、通信ネットワークを通じてリンクされたリモートの処理装置でタスクが行われる分散型の計算環境でも、実施することができる。
【００３１】
[0039]  図１を参照すると、計算デバイス１００はバス１１０を含み、バス１１０は、以下のデバイス、即ち、メモリ１１２、１以上のプロセッサー１１４、１以上のプレゼンテーション・コンポーネント１１６、入力／出力（Ｉ／Ｏ）ポート１１８、入力／出力コンポーネント１２０、および例示の電源１２２といったデバイスを直接的または間接的に結合する。バス１１０は、１以上のバス（アドレス・バスやデータ・バスやそれらの組み合わせ）を表し得る。図１の様々なブロックは、明瞭化を目的として線で示されているが、実際には、様々なコンポーネントの輪郭はそれほど明確ではなく、例えれば、線は、より正確には、灰色で曖昧である。例えば、或る者は、ディスプレイなどのようなプレゼンテーション・コンポーネントをＩ／Ｏコンポーネントと考えるであろう。また、プロセッサーはメモリを有する。発明者は、そのようなことは技術の特質であると認識しており、繰り返しになるが、図１の図は、単に、本発明の１以上の実施形態と関連して使用できる例示の計算デバイスを示すものである。「ワークステーション」、「サーバー」、「ラップトップ」、「手持ち型デバイス」などのカテゴリの間での区別は行われていない。なぜなら、これらの全ては図１の範囲内にあると考えられ、「計算デバイス」と関連する。
【００３２】
[0040]  計算デバイス１００は、典型的には、様々なコンピューター可読媒体を含む。コンピューター可読媒体は、計算デバイス１００によりアクセスでき、且つ揮発性および不揮発性、および取り外し可能および取り外し不可能の双方の、任意の使用可能な媒体とすることができる。限定ではなく例として、コンピューター可読媒体は、コンピューター・ストレージ媒体と通信媒体とを含むことができる。コンピューター・ストレージ媒体は、揮発性および不揮発性、および取り外し可能および取り外し不可能の双方の媒体を含むものであり、その媒体は、コンピューター可読命令、データ構造、プログラム・モジュール、または他のデータなどのような情報を記憶するための任意の方法および技術で実現される。コンピューター・ストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、デジタル・バーサタイル・ディスク（ＤＶＤ）、または他の光記ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージ、または望まれる情報を記憶するために使用でき且つ計算デバイス１００によりアクセスできる他の媒体を含むが、これらには限定されない。通信媒体は、典型的には、搬送波や他のトランスポート機構などのような変調されたデータ信号において、コンピューター可読命令、データ構造、プログラム・モジュール、または他のデータを実現するものであり、任意の情報配信媒体を含む。「変調されたデータ信号」という用語は、信号内において情報をエンコードするように、その信号の特性のうちの１以上の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体は、有線ネットワークや直接有線接続などのような有線媒体と、音響、ＲＦ、赤外線、および他のワイヤレス媒体などのようなワイヤレス媒体とを含む。上記のものの任意の組み合わせも、コンピューター可読媒体の範囲内に含まれるべきである。
【００３３】
[0041]  メモリ１１２は、揮発性および／または不揮発性のメモリの形のコンピューター・ストレージ媒体を含む。メモリは、取り外し可能、取り外し不可能、またはそれらの組み合わせとすることができる。例示のハードウェア・デバイスは、ソリッドステート・メモリ、ハード・ドライブ、光ディスク・デバイスなどを含む。計算デバイス１００は、メモリ１１２やＩ／Ｏコンポーネント１２０などのような様々なエンティティからデータを読み出す１以上のプロセッサーを含む。プレゼンテーション・コンポーネント（１以上）１１６は、データのインジケーションをユーザーまたは他のデバイスへ呈示する。例示のプレゼンテーション・コンポーネントは、ディスプレイ・デバイス、スピーカー、印刷コンポーネント、振動コンポーネントなどを含む。
【００３４】
[0042]  Ｉ／Ｏポート１１８は、計算デバイス１００が、Ｉ／Ｏコンポーネント１２０を含む他のデバイスと論理的に結合することを可能にし、Ｉ／Ｏコンポーネント１２０の幾つかはビルトインとすることができる。例示のコンポーネントは、マイクロフォン、ジョイスティック、ゲーム・パッド、サテライト・ディッシュ、スキャナー、プリンター、ワイヤレス・デバイスなどを含む。
【００３５】
データ・センターのアーキテクチャー
[0043]  ここで図２へ移ると、本発明の実施形態に従ったブロック図が示されており、これは、サービス・モデルに従ったサービス・アプリケーションのコンポーネント・プログラムまたはロールのインスタンスのオペレーションに適応してサポートするように構成されるデータ・センター２００を示している。図２に示すデータ・センター２００は、ホストする環境における適切な部分の単なる例であり、本発明の実施形態の使用や機能の範囲の限定を提案することを意図していないことを、当業者は理解および認識するであろう。データ・センター２００は、示された１つの何れかのリソースまたはリソースの組み合わせと関連する依存性や必要性を有すると、解釈すべきではない。更に、図２の様々なブロックは、明瞭化を目的として線で示されているが、実際には、様々なコンポーネントの輪郭はそれほど明確ではなく、例えれば、線は、より正確には、灰色で曖昧である。
【００３６】
[0044]  データ・センター２００は、ネットワーク・クラウド２４０を介して相互接続される様々なリソースを含む。ここで説明されるそれらのリソースは、ソフトウェア・コンポーネント（例えば、ファブリック・コントローラー２９５）と、ラックＡ  ２０５、ラックＢ  ２１０、ラックＣ  ２１５、トップ・ラック・スイッチ２３０、パワー・ストリップ２３５、サーバー２７０、計算デバイス２８０、アップデート・ドメイン２５１、およびアップデート・ドメイン２５２などのような実体的なハードウェア・エレメントとを含むことができる。ネットワーク・クラウド２４０は、それらのリソースを相互接続するが、これは、様々な物理リソースにわたって分散して配され得るサービス・アプリケーションのインスタンスが、他のインスタンスとの間での通信を確立するために、他のインスタンスの位置を認識し得るようにされる。更に、ネットワーク・クラウド２４０は、サービス・アプリケーションのインスタンスを、およびサービス・モデルにより要求される他のエレメントを接続するチャンネルを介して、この通信を容易にする。限定ではないが、ネットワークは、ローカル・エリア・ネットワーク（ＬＡＮ）および／またはワイド・エリア・ネットワーク（ＷＡＮ）の１以上のものを含むことができる。そのようなネットワーク環境は、オフィス、エンタープライズ−ワイド・コンピューター・ネットワーク、イントラネット、およびインターネットにおいて一般的である。従って、ここではネットワークについて更に説明しない。
【００３７】
[0045]  一般に、データ・センター２００は、サービス・アプリケーションの複数のコンポーネント・プログラムまたはロール・インスタンスを持つ分散型システムに適応し、コンポーネント・プログラムは、コンポーネント・プログラムを実行する処理装置で独立して実行されるが、ネットワーク・クラウド２４０を介して相互接続される。場合によっては、それらの計算リソースまたはノードは、様々なアップデートの対象となることができる。アップデート・ドメイン２５１および２５２は、典型的には、サービス・アプリケーションのロール・インスタンスがデータ・センター２００のリソースにわたって分散されること、および基礎的プラットフォームのアップデートの間に全てが同時にオフラインにならないことの、何らかの保証セットを提供する。従って、サービス・アプリケーションのオペレーションにおける一貫性が提供される。
【００３８】
[0046]  データ・センター２００の構成に戻ると、サーバー２７０、計算デバイス２８０、フォールト・ドメイン２５１および２５２、および動作するように結合されたブレード（例えば、ブレードＡ  ２６０、Ｂ  ２６１、およびＣ  ２６２）を有するラックＡ  ２０５、Ｂ  ２１０、およびＣ  ２１５のそれぞれは、例えば、図１を参照して説明した計算デバイス１００などのような、任意のタイプの計算デバイスとすることができる。限定ではない単なる例として、サーバー２７０、計算デバイス２８０、ブレードＡ  ２６０、ブレードＢ  ２６１、およびブレードＣ  ２６２のそれぞれは、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、手持ち型デバイス、モバイル・ハンドセット、消費者向け電子製品などとすることができる。実施形態では、データ・センター２００は、任意の数の上記の物理リソースを含むことができ、また、サービス・アプリケーションを実行できる計算デバイスまたは他の機構の任意のコレクションを含むことができる。
【００３９】
[0047]  更に、上記の１以上の物理リソースは更に、それに存在するファブリック・コントローラー２９５を、データ・センター２００を通じて有線またはワイヤレスのネットワーク経路を介してサービス・アプリケーションをデプロイ（deploy；配置、展開）、アクセス、および管理するように、ホストすることができる。しかし、本発明の実施形態は、図２に示すような物理リソースでインプリメントすることに限定されず、実施形態の範囲内で、様々な異なるタイプの計算デバイスや装置のうちの任意のものでインプリメントでき得ることに、留意されたい。換言すると、データ・センター２００の例示されているリソースは、単に説明を目的とすることを意図した例示的な構成を示し、従って、計算の業界で知られているリソースの任意の適切なレイアウトを用いることができ、それは本発明で考慮されている。
【００４０】
[0048]  特に、データ・センター２００の例示のリソースは、アップデート・ドメインの概念を紹介するために役立つ。上述のように、アップデート・ドメインは、データ・センター２００内でのテナント・ジョブの実行後に使用不可能になるノードのコレクションまたはセットを表す。上述のように、ノードは、ブレード（例えば、ブレードＡ  ２６０、ブレードＢ  ２６１、およびブレードＣ  ２６２）、コンピューター（例えば、計算デバイス２８０）、マシン（例えば、サーバー２７０）、またはデータ・センター２００においてサービス・アプリケーションのコンポーネント・プログラムまたはインスタンスを実行できる任意の他のデバイスを、参照することができる。従って、アップデート・ドメインを抽象化する利点は、テナント・ジョブの１つのフェーズの実行後に、データ・センター内の何れのリソースのグループが共にオフラインになるかと、他のリソースが、オフラインになることから、どのように仕切られるかとを、理解することである。
【００４１】
[0049]  データ・センター２００およびアップデート・ドメイン２５１および２５２の様々な異なる構成を説明したが、実行されるロール・インスタンスのアイデンティティに基づいて、ノードのセットをグループにする他のタイプの適切なアップデート・ドメインを抽象化できること、および本発明の実施形態が、ここで示したアップデート・ドメイン２５１および２５２に限定されないことが、当業者には理解および認識されるはずである。
【００４２】
サービス・アプリケーションのアップデート・ドメイン
[0050]  ここで図３へ移ると、本発明の実施形態に従った、例示のホストする環境３００のグラフィカル表現が示されている。特に、ホストする環境３００は、ファブリック・コントローラー２９５と、サービス・アプリケーション３５０と、ファブリック・コントローラー２９５およびサービス・アプリケーション３５０のオペレーションをサポートするデータ・センター２００とを含む。上述のように、データ・センター２００は、サービス・アプリケーション３５０のロールＡ、Ｂ、およびＣの冗長性に部分的に基づいてアップデート・ドメイン３０５および３１０へと編成されたリソースを含み、ロールは、インスタンス３１１、３１２、３１３、３２１、３２２、および３２３に配されている。一般に、アップデート・ドメイン３０５および３１０のそれぞれは、アップデート・スキームまたは「ジョブ・リスト」に従って同時に使用不可能になるように意図的に含まれた１以上のノードを、記述する。実施形態では、ジョブ・リスト（図６の参照番号６１０を参照）は、優先度に従って、スケジュールされた及び／又は継続中のテナント・ジョブを整理する。後に、十分に説明するが、ジョブ・リストの少なくとも一部は、サービス・アプリケーション３５０が近いうちに来るテナント・ジョブの受け取りの準備をするために、サービス・アプリケーション３５０の管理ロールへ公開される。
【００４３】
[0051]  ここで用いるフレーズ「テナント・ジョブ」は、ファブリック・コントローラー２９５によりサービス・アプリケーション３５０に対抗して行われる不変の変更オペレーション・セットのことをいう。これらの変更オペレーションは、サービス・アプリケーション３５０の可用性に影響を与えることができる。実施形態では、現在、ホストする環境３００により定められた固定数のテナント・ジョブのタイプがある。しかし、それらのテナント・ジョブは、将来には拡張でき得る。サービス・アプリケーション３５０へ焦点を合わされる例示的なテナント・ジョブは、サービス・アプリケーションのアップデート・ジョブ（例えば、メンテナンス・アクション）と、サービス・アプリケーションのコード改訂（例えば、アップグレード・アクションや新バージョンのロール・アウト）と、サービス・アプリケーションのトポロジー変更と、サービス・アプリケーションの構成変更と、リブート（例えば、ストップ−アンド−スタート・オペレーション）を用いるノード３２０の仮想マシン（ＶＭ）内のサービス・アプリケーションのゲストＯＳ変更と、リブートおよび再舗装（repave）（例えば、ゲストＯＳのレジストリーを変更）を用いるサービス・アプリケーションの修復とを、含む。一般に、修復は、ＶＭが他のプロセスでレストアできないときに、開始される。
【００４４】
[0052]  他のタイプのテナント・ジョブは、ホストする環境３００のメンテナンスへ焦点が合わされ得る。それらのテナント・ジョブの例は、インフラストラクチャーのアップデート（インスタンス３２１、３２２、および３２３を、正しく機能しないときにオフラインへと持って行く）と、或る地理学的位置（geo-location）から別の地理学的位置へのアプリケーション３５０の移動（例えば、ハードウェアや別のプラットフォームの問題に起因しての、インスタンス３１１、３１２、および３１３の再配置）と、リソースのアップデート（例えば、ノード３２０のＶＭで実行されるインスタンス３２１、３２２、および３２３を監視するエージェントに対するアップデート）とを、含む。ホストする環境３００を変更することに焦点を合わせたが、これらのタイプのテナント・ジョブはまた、インスタンス３２１、３２２、および３２３の可用性の割り込みを生成することもできる。
【００４５】
[0053]  テナント・ジョブの実行は、ホストする環境３００の要求（例えば、オペレーティング・システム・ソフトウェアをアップデートすること）により駆動すること、またはそのキュレーターにより起こすことができる。データ・センター２００で実行のためにテナント・ジョブが選択されたとき、テナント・ジョブの実際の実行は、フェーズ単位で増分的に行うことができる。即ち、テナント・ジョブはフェーズへと分割され、それぞれのフェーズの実行は、サービス・アプリケーション３５０の一部（例えば、１以上のロール・インスタンス）に影響し得る。例えば、サービス・アプリケーション３５０がロールＡの１０のインスタンスを有する場合、テナント・ジョブは、１０のフェーズへと分けることができ、それらは、更にサブセットへと分けることができる。実施形態では、アップデート・ドメイン全体またはアップデート・ドメインのサブセットが、テナント・ジョブのタイプや、テナント・ジョブに特定的な制約や、サービス・アプリケーション３５０のデプロイメント・レイアウトに応じて、フェーズの影響を受け得る。更に、フェーズの実行の順は、テナント・ジョブのタイプに特定的とすること、および／またはサービス・アプリケーション３５０のサービス・モデルにより決定することができる。
【００４６】
[0054]  動作において、各フェーズを行うことは、アップデート・ドメインのそれぞれが扱われる（addressed）まで、異なるアップデート・ドメインでテナント・ジョブを実行することを含む。例えば、テナント・ジョブの第１フェーズは、メンテナンス・オペレーションを行うためにアップデート・ドメイン３０５内のノード３２０をディスエーブルにすることを含むことができ、テナント・ジョブの第２フェーズは、アップデート・ドメイン３１０内のノードをディスエーブルにすることを含むことができる。ノード３２０をディスエーブルにすることは、暗黙的および同時に、ロール３２１、３２２、および３２３をオフラインへと引っ張る。しかし、ロールＡはインスタンス３１１および３２１に位置し、ロールＢはインスタンス３２２および３１２に位置し、ロールＣはインスタンス３２３および３１３に位置するので、ロール３２１、３２２、および３２３をオフラインへと引っ張ることは、必ずしもサービス・アプリケーション３５０を使用不可能にはしない。
【００４７】
[0055]  時折、ロールが最小数のインスタンスのみに位置するとき、アップデート・ドメインのサブセットのみが、テナントのフェーズの間に、実際に停止する（ｔａｋｅｎ  ｄｏｗｎ）。即ち、ロール・インスタンス３２１、３２２、および３２３の任意の組み合わせを、それらが同じアップデート・ドメイン３０５へとグループ化されているときには、同時に停止する（ｔａｋｅｎ  ｄｏｗｎ）ことができる。なおも、テナント・ジョブの影響は、第１フェーズの間、アップデート・ドメイン３０５のロール・インスタンス３２１、３２２、および３２３のみに限定される。
【００４８】
[0056]  サービス・アプリケーション３５０がステートフル・アプリケーションであり、ロール・インスタンス３２１、３２２、および３２３（アップデート・ドメイン３０５に含まれる）の状態がロール・インスタンス３１１、３１２、および３１３（アップデート・ドメイン３１０に含まれる）において複製されていない場合、テナント・ジョブの第１フェーズをインプリメントするときに、情報が使用不可能になり得る。従って、後に説明する本発明の実施形態は、テナント・ジョブのフェーズを反復して行うときに、ロール・インスタンスに格納される状態が使用不可能にされないように、テナント・ジョブを調整する技術を含む。
【００４９】
[0057]  本発明の実施形態は、分散型のサービス・アプリケーション３５０のトポロジーに対するアップデートを更に含む。好都合なことに、トポロジーのアップデートは、サービス・アプリケーション３５０のロール・インスタンスが、相互通信を目的として、サービス・アプリケーション３５０の他のロール・インスタンスを検査することを、可能にする。多くの場合、トポロジーのアップデートは、サービス・アプリケーションのトポロジーに関する情報を、そのロール・インスタンス全体に伝播させるための機構を含む。例として、この伝播される情報は、再配置されたロール・インスタンスの変更されたアドレスの記述および／またはサービス・アプリケーション３５０全体へ分散され得る他のデータを、含むことができる。
【００５０】
[0058]  ここで図３を参照してトポロジーのアップデートを説明する。最初に、ロールＡのインスタンス３２１がロールＢのインスタンス３２２との通信を望む場合、インスタンス３２１は、通信を開始するために、インスタンス３２２の位置（例えば、ＩＰアドレス）を知るべきである。典型的には、ロール・インスタンス３２１および３２２のそれぞれの名前に対するＩＰアドレスのマッピングが、それらの間での通信を助長するために、用いられる。このマッピングは、インスタンス３２１および３３３のそれぞれで維持される。
【００５１】
[0059]  インスタンス３２１および３２２の初期デプロイメントの後、マッピングは現在のものである。なぜなら、インスタンス３２１および３２２の位置は、ノード３２０でのインスタンス化以来、静的に維持されているからである。時間が経過後、サービス・アプリケーション３５０に対してアップデートが動的に生じた後（例えば、再配置や付加や除去）、インスタンス３２１および３２２の一方または双方が、元のＩＰアドレスに対する変更を経験し得る。インスタンス３２１および３２２のうちの１以上のものの変更されたＩＰアドレスは、サービス・アプリケーションの他方のインスタンスに不正確なマッピングを残すことになり得、従って、サービス・アプリケーションのトポロジーの首尾一貫しないビューと相互通信の崩壊とを、結果として生じさせる。例えば、インスタンス３２２が移動したため、インスタンス３２１に維持されるマッピングが、サービス・アプリケーションのトポロジーに関する不正確な情報を含む場合、インスタンス３２１は、インスタンス３２２の位置を見つけることやインスタンス３２２と話すことが、不可能となり得る。
【００５２】
[0060]  上述の問題を解決するため、アップデート・ドメインに関するＩＰアドレスの変更を記憶する冗長性手段を課すように、トポロジーのアップデートが構成される。例えば、２つのロール・インスタンス３２１および３１１が２つの別個のアップデート・ドメイン３０５および３１０へそれぞれに付加されたとき、第１アップデート・ドメイン３０５内で動作するサービス・アプリケーション３５０へは、第１ロール・インスタンス３２１が第１アップデート・ドメイン３０５へ付加されていることを通知し、第２アップデート・ドメイン３１０内で動作するサービス・アプリケーション３５０へは、第２ロール・インスタンス３１１が第２アップデート・ドメイン３１０へ付加されていることを通知する。次に、通知を分配した後、第１ロール・インスタンス３２１および第２ロール・インスタンス３１１は、インスタンス化され、それぞれのアップデート・ドメイン３０５および３１０において開始される。従って、他のロール・インスタンス３２２、３２３、３１２、および３１３のマッピングにあるトポロジー情報は２度アップデートされ、サービス・アプリケーション３５０に、新たなロール３２１および３１１が位置する場所の首尾一貫したビューを与える。
【００５３】
アップデート・ドメイン（ＵＤ）へのテナント・ジョブの適用
[0061]  ここで図４へ移ると、本発明の実施形態に従った、ステートフル・サービス・アプリケーション（例えば、ロールＡ）とステートレス・サービス・アプリケーション（例えば、ロールＢ）との双方におけるテナント・ジョブのフェーズを実行するためのプロセス・フローを示すグラフィカル表現が示されている。ステートレス・サービス・アプリケーションへテナント・ジョブを実行するとき、典型的には、特にロール・インスタンスのうちの１以上のものに格納された内部状態は、考慮されない。従って、ステートレス・アプリケーションのロール・インスタンスは、スケジュールされたようにオフラインへ持って行くことができる。例えば、テナント・ジョブのフェーズが、ステートレス・アプリケーションのロール・インスタンスＢ  ４１０を含むＵＤをアップデートすることを含むとき、テナント・ジョブは、ロール・インスタンスＢ  ４１０に対して行われ（図４のブロック４４０を参照）、アップデートされたロール・インスタンスＢ’４２０を生じさせる。この例では、ステートレス・アプリケーションの他のロール・インスタンスとの調整を行う理由はない。なぜなら、状態は、リモートのデータ・ストアへ安全にアップロードされるからである（即ち、ロール・インスタンスＢ  ４１０でローカルに格納されない）。
【００５４】
[0062]  しかし、ステートレス・サービス・アプリケーションに対してテナント・ジョブを実行するときには、ロール・インスタンスに格納された内部状態を考慮する。従って、ステートレス・サービス・アプリケーションのロール・インスタンスは、調整された形でオフラインへ持って行くことができる。例示の実施形態では、この調整は、ＵＤでテナント・ジョブを実行するときに、少なくとも以下のステージ、即ち、ＵＤを準備するステージ（ブロック４３０を参照）、ＵＤに作業を行うステージ（ブロック４４０を参照）、およびＵＤをレストアするステージ（ブロック４５０を参照）を用いることを、含む。テナント・ジョブを受け取るためにＵＤのロール・インスタンスＡ  ４０５を準備するとき、ステートフル・サービス・アプリケーションの管理コンポーネント（図５の参照番号５９７、５９８、および５９９を参照）は、ロール・インスタンスＡ  ４０５がオフラインへ持って行かれるかを判定することの責任を負い、ロール・インスタンスＡ  ４０５に格納された内部状態（１以上）を識別する。
【００５５】
[0063]  実施形態では、ロール・インスタンスＡ  ４０５がオフラインへ持って行かれるかを判定することは、少なくとも以下のステップ、即ち、ファブリック・コントローラーの、特定のテナント・ジョブを実行することのインテントを認識する（例えば、ファブリック・コントローラーから、ロール・インスタンスＡ  ４０５の目標状態を受け取り、これは、管理ロールに、ロール・インスタンスＡ  ４０５がオフライン・コンディションへ持って行かれるということを警告する）ステップと、テナント・ジョブのタイプ（例えば、行われるオペレーションと、それらのオペレーションのロール・インスタンスＡ  ４０５への影響）を記述する情報をファブリック・コントローラーから受け取るステップと、ファブリック・コントローラーに、テナント・ジョブの実行を一時停止させる（例えば、管理ロールが、先へ進むことの承認を返答するまで、または所定の期間が満了するまで）ステップと、ロール・インスタンスＡ  ４０５をオフライン・コンディションへ持って行った後に、サービス・アプリケーションが使用可能でとどまるかを確かめるアクションを行うステップと、メッセージによりファブリック・コントローラーへ応答するステップとを含む。従って、管理ロールは、サービス・アプリケーションに、オフライン・コンディションへと持って行かれているＵＤ内のロール・インスタンスＡ  ４０５に今後は依存や期待をしないようにサービス・アプリケーション自体を再構成することを、促す。このように、ファブリック・コントローラーに応答して管理ロールから送られるメッセージは、ロール・インスタンスＡ  ４０５がオフラインへ持って行かれる準備ができていることを、示すことができる。
【００５６】
[0064]  ロール・インスタンスＡ  ４０５で実行されることをスケジュールされたテナント・ジョブのタイプを評価した後、ロール・インスタンスＡ  ４０５をオフライン・コンディションへと持って行った後にはサービス・アプリケーションが使用可能にとどまらないことを確かめた場合、管理ロールは、ＵＤを停止させる（ｔａｋｉｎｇ  ｄｏｗｎ）ことに同意しないであろう。このように、管理ロールは、ファブリック・コントローラーに、ロール・インスタンスＡ  ４０５へのテナント・ジョブの継続を許可することを拒否するメッセージにより、応答することができる。管理ロールからの、テナント・ジョブの拒否を伝えるメッセージを考慮した後、ファブリック・コントローラーは、どのように進めるかを、テナント・ジョブのタイプに部分的に基づいて、知的に決定する。例えば、テナント・ジョブのタイプが、ホストする環境の基礎となるプラットフォームに対する修復を含む場合、ファブリック・コントローラーは、管理ロールが拒否を試みたにもかかわらず、ロール・インスタンスＡ  ４０５へテナント・ジョブを実行するように、進めることができる。テナント・ジョブのタイプが、サービス・アプリケーションのみのアップデートを含む場合、ファブリック・コントローラーは、管理ロールの拒否を留意して、ロール・インスタンスＡ  ４０５へのテナント・ジョブの実行をキャンセルすることができる。テナント・ジョブのタイプが、ロール・インスタンスＡ  ４０５をホストするノードのＯＳのメンテナンス・アクションを含む場合、ファブリック・コントローラーは、管理ロールとロール・インスタンスＡ  ４０５をオフライン・コンディションへと持って行くことの調整を、試みることができる。１つの場合において、調整は、管理ロールが一時停止を要求することを含み、この一時停止は、ロール・インスタンスＡ  ４０５が、その内部状態を、現在テナント・ジョブのターゲットとされているＵＤの外部にある別のロール・インスタンスへ複製することを可能とするために、テナント・ジョブの実行へ一時的に割り込むものである。別の場合には、調整は、フェイルオーバーの仲立ちをすることを含み、これは、ロール・インスタンスＡ  ４０５をオフライン・コンディションへ持って行くことを、制御可能に遅延することと、ＵＤにわたって冗長性を生成し、同時に、ＵＤの他のロール・インスタンスをオフライン・コンディションへと持って行くために、その内部状態を複製することとによりなされる。
【００５７】
[0065]  管理ロールおよび／またはファブリック・コントローラーが、ロール・インスタンスＡ  ４０５をオフライン・コンディションへ持って行くことができると判定したとき（ブロック４３５を参照）、次に、ロール・インスタンスＡ  ４０５を含むＵＤで作業を開始することができる（ブロック４４０を参照）。作業ステージ内で、ファブリック・コントローラーは、テナント・ジョブの定義に従って様々なタスクを行う（例えば、メンテナンス・アクションを行う）。典型的には、作業ステージの間、ファブリック・コントローラーは、管理ロールと会話せずにテナント・ジョブを実行する。テナント・ジョブのタスクが達成された後、ロール・インスタンスＡ  ４０５は、次のステージへ移る前に、内部状態（１以上）が一時のものではないように固定化することを許可される。
【００５８】
[0066]  ロール・インスタンスＡ  ４０５を固定化した後、ＵＤをレストアすることができる（ブロック４５０を参照）。レストア・ステージの間に、サービス・アプリケーションの管理ロールには、ファブリック・コントローラーにより、テナント・ジョブが完了したことが通知される。更に、レストア・ステージの間、管理ロールは、ＵＤをオンライン・コンディションへ持って行く前に、影響を受けた全てのロール・インスタンスが機能すること及び固定的であることを保証することと（ブロック４５５を参照）、ロール・インスタンスＡ  ４０５を、更新したロール・インスタンスＡ’４１５として表すこととの責任を負う。理解できるように、ＵＤ準備ステージ４３０とＵＤレストア・ステージ４５０との間に、サービス・アプリケーションの管理ロールとファブリック・コントローラーとの間での調整が存在する。特に、これら２つのステージ４３０と４５０との間で、管理ロールは、テナント・ジョブが次のステージへ進めるかを判定するために、サービス・アプリケーションの可用性を計算する。ジョブのタイプとサービス・アプリケーションのアカウントの設定とに応じて、アプリケーションは、ジョブの実行をブロックすることもしないこともできるが、何れの場合も、ジョブの実行を遅延させ得る。
【００５９】
[0067]  時折、テナント・ジョブが継続中であるときに（例えば、ロールＡ  ４０５がステージ４３０、４４０、４５０のうちの１つで処理中である）、高優先度のジョブが発行され得る。高優先度のジョブが発行されていることを検出すると、継続中のテナント・ジョブは阻止される。例示の実施形態では、阻止（preemption）は、テナント・ジョブの実行を明け渡すことと、高優先度のジョブをロールＡ  ４０５で実行することを可能にすることと、高優先度のジョブの完了の後にテナント・ジョブを再開することとを、含むことができる。
【００６０】
[0068]  阻止の間、例えば、スケジューリング・コンポーネント（図５の参照番号５３０を参照）は、明け渡しリクエストを、ノード状態ドライバー（図５の参照番号４６０を参照）へ送ることができ、これは、ロールＡ  ４０５においてステージ４３０、４４０、および４５０を進める責任を負う。この明け渡しリクエストは、継続中のテナント・ジョブを一時的に停止させてテナント・ジョブの進行を停止させ、また、高優先度のジョブを呼び出してロールＡ  ４０５で開始させる。換言すると、典型的にはロールＡ  ４０５では一度に１つのジョブのみが実行されるので、スケジューリング・コンポーネントは、ノード状態ドライバーに命令して、テナント・ジョブをアクティブ状態からパッシブ状態へ切り替え、高優先度のジョブをパッシブ状態からアクションへ切り替える適切なオペレーションを、行わせる。それらの適切なオペレーションは、ロールＡ  ４０５が実質的にレストアされるように、ロールＡ  ４０５をオンライン・コンディションへと強制的に持って行くことと、高優先度のジョブがロールＡ  ４０５で行われ得るように、ロールＡ  ４０５をオフライン・コンディションへ持って行くこととを含む。
【００６１】
[0069]  テナント・ジョブが再開を待っている間に高優先度のジョブが完了すると、割り込まれたテナント・ジョブを再招集するかについての判定を、スケジューラーにより行うことができる。例として、ロールＡ  ４０５の状態（例えば、ロールＡで実行されるソフトウェアの現在のバージョン）を測定することができ、その状態に基づいて、テナント・ジョブを、ロールＡ  ４０５において再招集すること又はキャンセルすることができる。従って、継続中のテナント・ジョブを阻止するプロセスは、テナント・ジョブの典型的な進行内でステージ４３０、４４０、および４５０を変更（例えば、付加、削除、変更）できる様々な判定およびアクションを、含むことができる。
【００６２】
テナント・ジョブをインプリメントするためのコンポーネント
[0070]  図５を参照すると、本発明の実施形態に従った、テナント・ジョブをインプリメントするための個々のオペレーションを行うための様々なコンポーネントを含むクラウド計算ネットワーク５００を示すブロック図が、示されている。一般に、ネットワーク５００は、テナント変更マネージャー５８０とサービス・アプリケーション３５０の管理ロール５９７〜５９９との間のインタラクションの一例を示す。このインタラクションは、ネットワーク５００にわたって及び／又はサービス・アプリケーション３５０にわたってのテナント・ジョブのインプリメントの調整に影響し得る。
【００６３】
[0071]  最初に、テナント変更マネージャー５８０は、図３のファブリック・コントローラー２９５のコンポーネントを表し、サービス・アプリケーション３５０の管理ロール５９７〜５９９とのインタラクションを行うことと、それらのインタラクションに部分的に基づいてのテナント・ジョブのデプロイメントの指揮を行うこととの責任を負う。デプロイメントを指揮するプロセスは、一般に、テナント・ジョブのデプロイメントの指示を管理ロール５９７〜５９９へ通信することと、オフライン・コンディションへとロール・インスタンス５２１〜５２３のディスエーブル化を開始することと、ロール・インスタンス５２１〜５２３へのテナント・ジョブの実行を許可することと、オンライン・コンディションへとロール・インスタンス５２１〜５２３のレストアを開始することとを、含む。サービス・アプリケーション３５０のコンポーネントである管理ロール５９７〜５９９は、典型的には、アップデート・ドメイン３０５内でグループにされたロール・インスタンス５２１〜５２３のそれぞれの内部状態を監視するために、構成される。実施形態では、テナント・ジョブのデプロイメントの指示を受け取った後に、管理ロール５９７〜５９９は、ロール・インスタンス５２１〜５２３のそれぞれの監視された内部状態が、アップデート・ドメイン３１０のノードＡ、Ｂ、およびＣなどのような、テナント・ジョブによる影響を受けないサービス・アプリケーション３５０の部分で複製されたかを判定する責任を負う。ここで示すように、テナント・ジョブは、最初はアップデート・ドメイン３０５をターゲットにし、これは、ノードＸ、Ｙ、およびＺでそれぞれホストされるコンポーネント５０１、５０２、および５０３の可用性に影響を及ぼす。また、管理ロール５９７〜５９９は、内部状態の可用性の指示をテナント変更マネージャー５８０へ通信するために、構成することができる。
【００６４】
[0072]  ここで、テナント変更マネージャー５８０を、図５と関連して詳細に説明する。上述のように、テナント変更マネージャー５８０は、一般には、クラウド計算ネットワーク５００の基礎的プラットフォームのアップデートおよび／または修復の制御（例えば、テナント・ジョブのスケジューリングおよび調整）を行う義務を課せられる。制御を行うプロセスは、テナント変更マネージャー５８０が管理ロール５９７〜５９９と目標状態機構５１０との間のインタラクションを管理することを、含むことができる。典型的には、各テナント・ジョブは特定の目標状態機構と関連し、目標状態機構は、テナント・ジョブの実行に内在する作業を駆動するための状態マシンとして動作する。従って、テナント変更マネージャー５８０により管理されるインタラクションは、以下のステップ、即ち、アップデート・ドメイン３０５のノードＸ、Ｙ、およびＺに対するテナント・ジョブをスケジュールするステップと、ノードＸ、Ｙ、およびＺでホストされるコンポーネント５０１、５０２、および５０３のアイデンティティを決定するステップと、コンポーネント５０１、５０２、および５０３がそれぞれロール・インスタンス５２１、５２２、および５２３を含むことを認識した後に、スケジュールされたテナント・ジョブを実行するインテントを、サービス・アプリケーション３５０の部分である管理ロール５９７〜５９９へ通信するステップと、管理ロール５９７〜５９９から、ロール・インスタンス５２１、５２２、および５２３の内部状態についての情報を通信するメッセージを受け取るステップと、ロール・インスタンス５２１、５２２、および５２３の内部状態を考慮することにより、テナント・ジョブの実行を取り扱うステップとを、含むことができる。動作において、ロール・インスタンス５２１、５２２、および５２３の内部状態は、ノードＸ、Ｙ、およびＺがオンライン・コンディションからオフライン・コンディションへと移行させられるときに、目標状態機構５１０がどのように進むべきかに関して、目標状態機構５１０を案内する。
【００６５】
[0073]  管理ロール５９７〜５９９に、ロール・インスタンス５２１〜５２３の内部状態をそれぞれ監視する責任を割り当てることにより、テナント変更マネージャー５８０は、効率的に動作するように、サービス・アプリケーション３５０のインプリメントの特定の詳細に対して不可知（agnostic）にとどまることを可能にする。従って、管理ロール５９７〜５９９は、テナント変更マネージャー５８０と共同して、以下の全てのこと、即ち、任意のアプリケーション管理目標を実現するために、サービス・アプリケーション３５０の状態についての十分な情報を基礎的プラットフォームへ提供することと、基礎的プラットフォームにより開始された任意の進行中のメンテナンス活動のサービス・アプリケーション３５０に対しての可視性を提供することと、サービス・アプリケーション３５０に、プラットフォームにより開始される活動の時間を適切に定める機会を提供することとを行うことができる汎用プロトコルを、ファブリック・コントローラーとアプリケーション３５０との間に有効にもたらす。
【００６６】
[0074]  ここで、例示の管理ロールのパフォーマンスを、図５の管理ロール５９７〜５９９と関連して詳細に説明する。一般に、例示の管理ロールは、サービス・アプリケーション３５０の１以上のロール・インスタンスでローカルに格納された内部状態（１以上）を理解するように、およびこの理解を、テナント・ジョブ（例えば、メンテナンス、アップデート、およびリカバリーのオペレーション）のデプロイメントの間に、ネットワーク５００の基礎的プラットフォーム全体へ通信するように、プログラムされている。従って、ここで用いられるフレーズ「管理ロール」は、サービス・アプリケーションの内部状態を監視および評価する責任を負うサービス・アプリケーションのコンポーネント（１以上）を広く指すものである。更に、例示の管理ロールは、テナント・ジョブの実行に含まれる、ファブリック・コントローラーとのオペレーションを調整することの、責任を負うことができる。
【００６７】
[0075]  これらの責任を管理ロールへ委ねた後、ファブリック・コントローラーには、サービス・アプリケーションのロール・インスタンスにローカルな内部状態（１以上）へのアクセス可能なビューが提供される。従って、ロール・インスタンスの内部状態の複製は、ファブリック・コントローラーに知られて考慮されることができる。実際には、ロール・インスタンスの内部状態を記述する情報を収集および分配することにより、管理ロールは、テナント・ジョブの間にノード（１以上）をオフライン・コンディションへ持って行くときに、ファブリック・コントローラーが特定の内部状態の全ての複製を停止させない（ｎｏｔ  ｔａｋｅ  ｄｏｗｎ）ことを保証することの手助けを、試みる。従って、ファブリック・コントローラーがデータ・センター内の全ステートフル・アプリケーションの全ロール・インスタンスの内部状態を直接に監視することで被る非効率性は、改善され、なおも、内部状態は、管理ロールを介してファブリック・コントローラーに対して可視とされる。
【００６８】
[0076]  一例では、サービス・アプリケーションがロールＡ（例えば、顧客からデジタル・イメージのセットを受け取る）と、ロールＢ（例えば、受け取り後にデジタル・イメージをフォーマットする）と、ロールＣ（例えば、フォーマットされたデジタル・イメージをＵＩＤディスプレイに呈示する）とを有する場合、ロールＡ、Ｂ、およびＣにおけるインスタンスの内部状態（例えば、特定の顧客データ）を追跡する第４セットのロールＤを作ることができる。従って、管理ロールＤ（例えば、管理ロール５９７〜５９９）は、サービス・アプリケーション３５０の内部の詳細の深い理解を有する。例えば、管理ロールＤは、どこにデジタル・イメージの各複製が格納さているかや、デジタル・イメージを格納しているロール・インスタンス（例えば、ロール・インスタンス５２１〜５２３）が現在使用可能であるかを、知り得る。更に、管理ロールＤは、そのデジタル・イメージを個々にローカルに格納するロール・インスタンスの数を知り得る。
【００６９】
[0077]  実施形態では、管理ロール５９７〜５９９は、以下のステップ、即ち、サービス・アプリケーション３５０を、高い可視性を設定するためにファブリック・コントローラーが選択したステートフル・アプリケーションとして、識別するステップと、アプリケーション３５０の１以上のロール・インスタンス（例えば、管理ロール５９７〜５９９）を、サービス・アプリケーション３５０を構成する他のロール・インスタンス（例えば、ロール・インスタンス５２１〜５２３）の内部状態を理解する責任を負わせるために、指定するステップとにより、確立することができる。一般に、サービス・モデルの観点からは、管理ロール５９７〜５９９は、サービス・モデル定義においてフラッグにより指定される通例のサービス・アプリケーションのロールを表す。更に、管理ロール５９７〜５９９の確立後、サービス・アプリケーション３５０は、サービス・アプリケーション３５０の様々な独立した部分についての監視および報告を行うように、管理ロール５９７〜５９９のうちの１以上のものを構成することができる。
【００７０】
[0078]  典型的には、サービス・アプリケーション３５０は、ファブリック・コントローラーにより実施されるコンディションのセットの中で管理ロール５９７〜５９９をどこへ置くかを判断するように、プログラムされる。例えば、ファブリック・コントローラーは、２つの管理ロールが同じノードを共有できないというコンディションを課すことができ、従って、様々なロール・インスタンスを高い可用性に維持する。この場合、図５を参照すると、管理ロール５９７〜５９９は、監視されている他のロール・インスタンス５２１〜５２３（即ち、サービス・ロール・インスタンス対管理ロール・インスタンス）と同じノードＸ、Ｙ、およびＺ（例えば、物理マシンや仮想マシン）において確立されていない。
【００７１】
[0079]  管理ロール５９７〜５９９を確立し配した後、管理ロール５９７〜５９９は、管理ロール５９７〜５９９の内部状態の管理ロール５９７〜５９９による理解を、上述のようにテナント・ジョブのインプリメントを管理するテナント変更マネージャー５８０へ公開することにより、監視されるロール・インスタンス５２１〜５２３へのテナント・ジョブの調整に影響を及ぼすことを、一般に可能とされる。このロール・インスタンスの内部状態を理解することは、ロール・インスタンス５２１〜５２３をクロールすること、および内部状態の複製の数および位置についてのサービス・アプリケーション３５０自体の可用性の理解に基づく複合的論理を任意にインプリメントすることにより、達成することができる。内部状態の理解が知られた後、この理解は、テナント変更マネージャー５３０へ通信される。ロール・インスタンス５２１〜５２３の内部状態の理解を通信するために管理ロール５９７〜５９９により用いられるスキームの例では、管理ロール５９７〜５９９は、ロール・インスタンス５２１〜５２３を評価して、テナント変更マネージャー５８０からの要求に応じて、その評価を入れたメッセージを通信することができる。または、評価および通信するプロセスは、管理ロール５９７〜５９９により自動的に行うことができる（例えば、予め定めた期間に、又はトリガーするイベントの検出後に）。
【００７２】
[0080]  実施形態では、テナント変更マネージャー５８０は、テナント・ジョブを調整することと関連する特定のタスクを行うための様々なコンポーネントを含むことができる。図５で示すように、例示のコンポーネントは、実行エンジン５２０と、スケジューリング・コンポーネント５３０と、テナント・ジョブ管理コンポーネント５４０と、ジョブ・コンパチビリティ・コンポーネント５５０とを含む。ジョブ・コンパチビリティ・コンポーネント５５０は、或るジョブ（２番目にデプロイされたもの）は別の継続中のテナント・ジョブ（最初にデプロイされたもの）よりも優先度が高いというところでの、テナント・ジョブの阻止（preemption）プロセスを扱うように構成される。テナント・ジョブ管理コンポーネント５４０は、テナント・ジョブのデプロイメントを調整し、スケジューリング・コンポーネント５３０へ命令を送り、テナント・ジョブの進行を追跡する。スケジューリング・コンポーネント５３０は、一般に、テナント・ジョブの実行をスケジュールする責任を負い、異なるサービス・アプリケーションにわたって現在実行されている継続中のテナント・ジョブのタイプを考慮する。更に、スケジューリング・コンポーネントは更に、優先度スキーム（図６を参照して後に説明する）に従って高優先度のジョブにより１以上のテナント・ジョブへ割り込みが行われるように、構成することができる。
【００７３】
[0081]  実施形態において、実行エンジン５２０は、テナント・ジョブの開始および実行を呼び出すように構成された汎用の有限状態マシン（ＦＳＭ）を表す。典型的には、実行エンジン５２０は、特定のテナント・ジョブのための作業を行うために行われるステップのセットを記述するフレームワークを含む。フレームワークはまた、１つのステップから別のステップへと進むことと関連する、ステップのセットとリンクとの間の順序付けを提供する。これらのリンクは、別のステップへ移る前に第１のステップを行うときに満足させるべきコンディションと関連する。例えば、実行エンジン５２０は、アップデート・ドメイン３０５の状態移行を駆動するために、スケジューリング・コンポーネント５３０および／または目標状態機構５１０から入力および出力を読むことができ、アップデート・ドメイン３０５での状態移行の完了は、それへテナント・ジョブを適切に実行すること、およびアップデート・ドメイン３１０へ進むことを、可能にする。
【００７４】
[0082]  特定の実施形態では、実行エンジン５２０は、ＦＳＭとして行動するとき、テナント・ジョブの移行（例えば、パッシブ状態とアクティブ状態）およびロール・インスタンスの移行（例えば、オンライン・コンディションとオフライン・コンディション）と関連する有限数の状態から構成され、それぞれの移行は、或る状態で開始して別の状態で終了するアクションのセットを含む。移行は、典型的には、検出されたイベント（例えば、書き込み／格納のオペレーション）などのようなトリガーにより、開始される。１つの場合において、トリガーは、アップデート・ドメイン３０５および３１０へテナント・ジョブを行うことを実行エンジン５２０に促す、スケジューリング・コンポーネント５３０からの命令の受け取りを、含むことができる。一般に、ＦＳＭは、一度に１つの状態のみに存在することが可能とされ、これは、ここでは、継続中のテナント・ジョブの現在状態という。
【００７５】
[0083]  ネットワーク５００の基礎的プラットフォームは、テナント・ジョブを知的にデプロイおよび実行する際にテナント変更マネージャー５８０を援助する追加のコンポーネントを含む。それらの追加のコンポーネントは、ファブリック・コントローラーの範囲に含まれることができ、また、それらのコンポーネントは、ファブリック・コントローラーをサポートするがファブリック・コントローラーから分離して存在することもできる。実施形態では、基礎的プラットフォームのコンポーネントは、ルート・アップグレード・エンジン５９０、目標状態機構５１０、およびノード状態ドライバー４６０を含むが、これらには限定されない。
【００７６】
[0084]  ルート・アップグレード・エンジン５９０は、一般に、基礎的プラットフォームまたはサービス・アプリケーション３５０のサービス・モデルの所定の規則に違反せずにアップデートできるノードのセット（例えば、アップデート・ドメイン３１０のノードＡ、Ｂ、およびＣ、またはアップデート・ドメイン３０５のノードＸ、Ｙ、およびＺ）を選択するように、設計される。例えば、規則は、受け取るために選択されたノードのセットが、わずか１つのアップデート・ドメインに属するロール・インスタンスをホストすることを、保証することができる。テナント・ジョブを受け取るためにノードのセットが選択された後、選択されたノードのセットは、テナント・ジョブのデプロイメントを案内するために、テナント変更マネージャー５８０へ提示される。
【００７７】
[0085]  目標状態機構５１０は、一般に、管理ロール５９７〜５９９と通信し、また、実行エンジン５２０により命令されたように、ロール・インスタンス５２１〜５２３を期待状態へ移行させる及び期待状態で持続させるように、構成される。例として、アップデート・ドメイン３０５の準備ステージ（図４の参照番号４３０を参照）の間、ロール・インスタンス５２１〜５２３の期待状態は、オフライン・コンディション４３５であり得る。他方、アップデート・ドメイン３０５のレストア・ステージ（図４の参照番号４５０を参照）の間、ロール・インスタンス５２１〜５２３の期待状態は、オンライン・コンディション４５５であり得る。
【００７８】
[0086]  目標状態機構５１０のオペレーションの一例では、実行エンジン５２０および／またはスケジューリング・コンポーネント５３０は、アップデート・ドメイン３０５を期待状態へ移行させることを目標状態機構５１０に要求する命令５６０を、目標状態機構５１０へ送ることができる。ここで用いるフレーズ「期待状態」は、一般に、ロール・インスタンス５２１〜５２３に関しての、オフライン・コンディションまたはオンライン・コンディションを呈するための目標を表す。ロール・インスタンス５２１〜５２３を期待状態へ移行するための適切なアクションが取られた後、ロール・インスタンス５２１〜５２３の実際の状態を、ワイヤー・プロトコル（矢印の無い破線で示す）を介して、それぞれのホスト・エージェント（ロール・インスタンス５２１〜５２３として共通ノードに存在）へ報告することができ、ホスト・エージェントはその実際の状態をテナント変更マネージャー５８０へ渡す。テナント変更マネージャー５８０は、次に、進行中のテナント・ジョブのインプリメントをどのように進めるかを決定する際に目標状態機構５１０を援助するために、テナント・ジョブの実際の状態を目標状態機構５１０へ渡す。
【００７９】
[0087]  別の実施形態では、アップデート・ドメイン３０５のノードＸ、Ｙ、およびＺが期待状態へ到達した後、目標状態機構５１０は、ロール・インスタンス５２１〜５２３の状態を管理ロール５９７〜５９９と通信することができる。オフライン・コンディションが期待状態であるときの実施形態では、サービス・アプリケーション３５０がロール・インスタンス５２１〜５２３を使用することに頼らないように準備されるように、通信は、管理ロール５９７〜５９９に、ロール・インスタンス５２１〜５２３がディスエーブルであると考慮すべきであることを通知する第１メッセージを送ることを、含むことができる。オンライン・コンディションが期待状態であるときの実施形態では、サービス・アプリケーション３５０がロール・インスタンス５２１〜５２３に依存できるように、通信は、管理ロール５９７〜５９９に、ロール・インスタンス５２１〜５２３がイネーブルであると考慮すべきであることを通知する第２メッセージを送ることを、含むことができる。
【００８０】
[0088]  幾つかの場合、期待状態を運ぶメッセージは、テナント・ジョブによる影響を受けているノードＸ、Ｙ、およびＺのそれぞれのルート・パーティションで実行されるホスト・エージェントへ、直接に送られる。例えば、メッセージは、適切な管理ロール５９７〜５９９へメッセージを分配する前に、図６のホスト・エージェント６１５へ送ることができる。従って、ホスト・エージェントは、ロール・インスタンス５２１〜５２３の状態をサービス・アプリケーション３５０へ示すように、機能する。更に、メッセージをノードＸ、Ｙ、およびＺにローカルに格納することにより、メッセージは、ファブリック・コントローラーのフェイルオーバーのとき、及び／又は管理ロール５９７〜５９９をホストするそれぞれのノードがオフラインへ持って行かれたとき（例えば、リブートや再舗装のオペレーションの間）に、生き残ることができる。従って、ネットワーク５００の基礎的プラットフォームは、現在進行中のテナント・ジョブにかかわらず、メッセージに対しての首尾一貫した可視性を維持するように、設計される。
【００８１】
[0089]  実施形態では、メッセージを介して主張される期待状態は、サービス・アプリケーション３５０の管理ロールのインスタンスをホストするノードのそれぞれへ送ることができる。次に、管理ロール５９７〜５９９は、メッセージを規則的に検査することにより、アップデート・ドメイン３０５および３１０の期待状態の周期的ポーリングのための機構をインプリメントすることができる。これらのポーリングは、期待状態および他の情報を取り出し、それをサービス・アプリケーション３５０に対して使用可能とするように、働く。
【００８２】
[0090]  目標状態機構５１０が期待状態を設定して通信すると、ノード状態ドライバー４６０は、一般には、期待状態に従って、テナント変更マネージャー５８０の指揮の下で、ロール・インスタンス５２１〜５２３をオフライン・コンディションへとディスエーブルにするように、テナント・ジョブを実行するように、およびオンライン・コンディションへとロール・インスタンス５２１〜５２３をレストアするように、構成される。
【００８３】
[0091]  本発明の実施形態によると、ノードは任意の形の計算デバイスを表し得るものであり、計算デバイスは、例えば、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、モバイル・デバイス、消費者向け電子デバイス、サーバー（１以上）、図１の計算デバイスなどである。典型的には、ノードは、ロール・インスタンスおよびノードで実行される他のコンポーネントのオペレーションをサポートするための何らかの形の計算ユニット（例えば、中央処理装置、マイクロプロセッサーなど）を含むか、またはそれらへリンクされる。ここで用いるフレーズ「計算ユニット」は、一般に、１以上のオペレーティング・システムや他の基礎的ソフトウェアをサポートする、処理力および格納メモリを持つ専用の計算デバイスをいう。１つの場合、計算ユニットは、各エンドポイントが様々なプロセスやオペレーションを行うことを可能にするために、ノードと統合された又は動作可能に結合された実体的なハードウェア・エレメントや機械を用いて、構成される。別の場合、計算ユニットは、ノードに収容されるコンピューター可読媒体へ結合されるプロセッサー（示さず）を、含むことができる。一般に、コンピューター可読媒体は、プロセッサーにより実行可能な複数のコンピューター・ソフトウェア・コンポーネント（例えば、ロール・インスタンス５２１〜５２３）を、少なくとも一時的に、格納する。ここで用いる用語「プロセッサー」は、限定することを意味せず、計算容量内で働く計算ユニットの任意のエレメントを含むことができる。そのような計算容量において、プロセッサーは、命令を処理する実体的な物として構成することができる。例示の実施形態では、処理は、フェッチ、デコード／割り込み、実行、およびライト・バックの命令を含むことができる。
【００８４】
[0092]  図５に示すように、アップデート・ドメイン３０５のノードＸ、Ｙ、およびＺと、アップデート・ドメイン３１０のノードＡ、Ｂ、およびＣとのそれぞれは、仮想マシンまたは物理マシンを表す。仮想マシンとして表される場合、ノードは、図１のメモリ１１２の部分および／または図１のプロセッサー１１４の部分を、含むことができる。ここで用いるフレーズ「仮想マシン」は、限定することを意味せず、サービス・アプリケーションの機能の基礎となるように処理ユニットにより実行される任意のソフトウェア、アプリケーション、オペレーティング・システム、またはプログラムのことであり得る。実施形態では、仮想マシンは、ノードのそれぞれのゲスト・パーティションを表し、ゲスト・パーティションは、サービス・アプリケーション３５０又は少なくともその一部をホストすることを可能とされる。
【００８５】
[0093]  一般に、サービス・アプリケーション３５０は、分散型の様式でサービス・アプリケーション３５０をホストするクラウド計算ネットワーク５００のテナント（例えば、顧客）により、所有される。ノードは更に、そこで実行されるホスト・エージェント（図６の参照番号６１５を参照）をサポートすることができる。実施形態では、ホスト・エージェント６１５は、ノードのルート・パーティションに存在し、ルート・パーティションは、ディスクのＩ／Ｏオペレーションをインプリメントすることのリクエストなどのような、仮想マシンからのリクエストを一般に管理する仕事を課せられる。
【００８６】
[0094]  図５に示すクラウド計算ネットワーク５００は、１つの適切な計算システム環境の単なる例であり、本発明の実施形態の使用や機能の範囲に関する何れの限定を提案することも意図していないことを、理解および認識すべきである。例えば、クラウド計算ネットワーク５００は、公開クラウド、非公開クラウド、または専用クラウドとすることができる。クラウド計算ネットワーク５００は、ここで示す１つのコンポーネントやコンポーネントの組み合わせと関連する依存性や必要性を有するものと、解釈すべきではない。更に、図５の様々なブロックは、明瞭化を目的として線で示されているが、実際には、様々なコンポーネントの輪郭はそれほど明確ではなく、例えれば、線は、より正確には、灰色で曖昧である。更に、本発明の実施形態の範囲内で望まれる機能を達成するために、任意の数の物理マシン、仮想マシン、データ・センター、エンドポイント、またはそれらの組み合わせを、用いることができる。
【００８７】
[0095]  クラウド計算ネットワーク５００は、典型的には、クラウド計算ネットワーク３５０のテナント／顧客により所有される分散型サービス・アプリケーションのロール・インスタンスのオペレーションをホストおよびサポートするためのデータ・センターを、含む。ここで用いるフレーズ「サービス・アプリケーション」は、クラウド計算ネットワーク５００の最上部で実行される又はクラウド計算ネットワーク５００内のストレージ場所へアクセスする任意のソフトウェアまたはソフトウェアの一部を、広く指すものである。１つの実施形態では、ロール・インスタンスは、サービス・アプリケーション（例えば、サービス・アプリケーション３５０）の機能のサポートに参加するソフトウェアの一部またはコンポーネント・プログラムを表す。図５に示される各ロール・インスタンスは、サービス・アプリケーションをサポートするための適切な部分の単なる例であり、本発明の実施形態の使用や機能の範囲についての何れの限定を提案することも意図していないことが、理解および認識されるであろう。
【００８８】
[0096]  クラウド計算ネットワーク５００のコンテキスト内で、示された様々なコンポーネントは、ノード内で内部の通信を行うことができ、データ・センターを横切る動的に行われる接続を通じて物理ノードにわたって、および物理ネットワーク・トポロジーを通じてリモート・ネットワーク（例えば、エンタープライズ・プライベート・ネットワーク）のリソースと外的に、通信を行うことができる。接続は、ネットワーク・クラウド（示さず）を介して、データ・センターの物理リソースにわたって分散されたコンポーネントを相互接続することを、含むことができる。ネットワーク・クラウドはそれらのリソースを相互接続して、コンポーネント間で通信を確立するように、或るコンポーネントが別のコンポーネントの位置を認識できるようにする。例えば、ネットワーク・クラウドは、共通サービス・アプリケーションのロール・インスタンスを接続するチャンネルを介して、この通信を確立することができる。例として、限定ではないが、チャンネルは、１以上のローカル・エリア・ネットワーク（ＬＡＮ）および／またはワイド・エリア・ネットワーク（ＷＡＮ）を、含むことができる。そのようなネットワーク環境は、オフィス、エンタープライズ−ワイド・コンピューター・ネットワーク、イントラネット、およびインターネットにおいて一般的である。従って、ここではネットワークについて更に説明しない。
【００８９】
[0097]  更に、本発明の実施形態の範囲内で望まれる機能を達成するために、任意の数のコンポーネントを用いることができる。図５の様々なブロックは、明瞭化を目的として線で示されているが、実際には、様々なコンポーネントの輪郭はそれほど明確ではなく、例えれば、線は、より正確には、灰色で曖昧である。更に、図５の幾つかのコンポーネントは１つのブロックで示されているが、この描写は、本質的に、また数の上でも、例であり、限定するものと解釈されない（例えば、１つのみの実行エンジン５２０が示されているが、個々のテナント・ジョブと関連する移行を管理するために、更に多くのものを確立することができる）。
【００９０】
テナント・ジョブの優先および阻止
[0098]  ここで図６へ移ると、本発明の実施形態に従った、データ・センター６００の例示のトポロジーのグラフィカル表現が示され、これは、ファブリック・コントローラー２９５とサービス・アプリケーション３５０との間のインタラクションを示している。最初に、ファブリック・コントローラー２９５は、現在継続中のテナント・ジョブ（例えば、テナント・ジョブ６１１〜６１３）のジョブ・リスト６１０を維持することができる。スケジューリング・コンポーネント５３０は、サービス・アプリケーション３５０の少なくとも１つの管理ロール６２０へ、サービス・アプリケーション３５０へ影響を及ぼす現在アクティブで継続中のテナント・ジョブと、ジョブ・リスト６１０内で生じる関連する変更（例えば、テナント・ジョブ６１１〜６１３の順序変更や、継続中のテナント・ジョブの阻止）とを伝えるように、構成される。
【００９１】
[0099]  時折、上述のように、テナント・ジョブが現在継続中でありアクティブ状態にデプロイされているときに、高優先度のジョブが発行され得る。高優先度のジョブに対してどのように対処するかを管理するポリシー６０５が、スケジューリング・コンポーネント５３０に対して使用可能とされ、様々ポリシー６０５は、テナント・ジョブを様々な様式で行わせることになり得る。動作において、ポリシー６０５は、テナント・ジョブ６１１〜６１３を取り囲む競合に対するスケジューリング・コンポーネント５３０の反応（例えば、タイムアウトやキャンセルのメッセージ）を管理する。実施形態では、反応は、ポリシー６０５により示されるテナント・ジョブのファクターにより、駆動される。
【００９２】
[00100]  それらのファクターのうちの１つは、テナント・ジョブを開始したエンティティのタイプと関連する。テナント・ジョブは、アプリケーションまたは顧客により開始されるものと、インフラストラクチャーにより開始されるものという２つのカテゴリに分けることができる。顧客が、顧客のサービス・アプリケーション３５０に対してテナント・ジョブ（例えば、バージョンのアップデート）を開始するとき、このテナント・ジョブは、ジョブ・リスト６１０へ置かれ、管理ロール６２０へ公開される。顧客により開始されたテナント・ジョブが開始されると（例えば、ジョブ・リスト６１０の順序の最上位へ到達した後）、ファブリック・コントローラー２９５は管理ロール６２０に対してクエリを行い、顧客により開始されたテナント・ジョブによりターゲットとされるロール・インスタンスで別のテナント・ジョブが現在継続中であるかを、判定することができる。インフラストラクチャーにより開始されたテナント・ジョブ（例えば、基礎的プラットフォームにより内部で開始されたメンテナンス・オペレーションや、影響されるノードのリブートを含む新たなルート・オペレーティング・システムのバージョンのインストレーション）が、ターゲットとされたロール・インスタンス対して現在デプロイされている場合、顧客により開始されたテナント・ジョブは、ホールドに置かれる（中断された状態へ移行）か、または完全に終了させられる（キャンセルされた状態へ移行）。
【００９３】
[00101]  インフラストラクチャーがサービス・アプリケーション３５０に対するテナント・ジョブを開始したとき、このジョブは、ジョブ・リスト６１０へ置かれるか、または高い優先度が割り当てられて即座にデプロイされるかの、何れかである。インフラストラクチャーにより開始されたテナント・ジョブのデプロイメントが検出されると、ファブリック・コントローラー２９５は管理ロール６２０に対してクエリを行い、インフラストラクチャーにより開始されたテナント・ジョブによりターゲットとされるロール・インスタンスにおいて別のテナント・ジョブが現在継続中であるかを、判定することができる。顧客により開始されたテナント・ジョブが、ターゲットとされたロール・インスタンスで現在デプロイされている場合、幾つかのステップが生じ得る。１つのステップは、顧客により開始されたテナント・ジョブに、優先順位において、インフラストラクチャーにより開始されたテナント・ジョブよりもランクを高くし得る何らかの特権が与えられているかを判定することを、含む。特権が与えられていない場合、別のステップは、顧客により開始されたテナント・ジョブを阻止することを含む。実施形態では、阻止は、顧客により開始されたテナント・ジョブが作業を一時的に停止するようにさせ（パッシブ状態への移行）、インフラストラクチャーにより開始されたテナント・ジョブが開始することを許可する（アクティブ状態への移行）。従って、顧客により開始された継続中のテナント・ジョブは、インフラストラクチャーにより開始されたテナント・ジョブをブロックしない。
【００９４】
[00102]  別の実施形態では、スケジューリング・コンポーネント５３０は、ジョブ・リスト６１０を構築するように、および特定のテナント・ジョブがジョブ・リスト６１０の最上部へ到達したときに実行を呼びかけるように、構成される。ジョブ・リスト６１０を構築するとき、スケジューリング・コンポーネント５３０は、ジョブ・リスト６１０内でのテナント・ジョブの順序付けを生成するために優先度スキームに依存することができる。更に、スケジューリング・コンポーネント５３０は、共通のノードをターゲットにしている２以上のテナント・ジョブの間での競合がある場合、即座に実行する適切なテナント・ジョブを選択するように、構成される。この選択は、優先度スキームを調べることと、優先度スキームに従って、テナント・ジョブのうちの何れを最初に開始すべきかを確かめることとに、基づくことができる。典型的には、優先度スキームは、基礎的プラットフォームにより確立されたポリシー６０５を組み入れる。
【００９５】
[00103]  ここで、優先度スキームを用いるための例示のプロセスを説明する。最初に、継続中のテナント・ジョブが、対象とされるロール・インスタンスで実行されているときに、新たなテナント・ジョブが、スケジューリング・コンポーネント５３０へ到着する。このとき、新たなテナント・ジョブはパッシブ状態にあり、継続中のテナント・ジョブはアクティブ状態にあり、対象のロール・インスタンスはオフライン・コンディションにある。新たなテナント・ジョブの優先度は、優先度スキームから決定され得る。その決定された優先度が、継続中のテナント・ジョブよりも低い場合、スケジューリング・コンポーネント５３０は、継続中のテナント・ジョブの実行を継続させ（アクティブ状態にとどまる）、また、決定された優先度に従って、新たなテナント・ジョブ（パッシブ状態にとどまる）を、ジョブ・リスト６１０のテナント・ジョブ６１１〜６１３のキューへ入れる。
【００９６】
[00104]  しかし、決定された優先度が、継続中のテナント・ジョブよりも高い場合、スケジューリング・コンポーネント５３０は、ジョブ阻止シーケンスの仲裁アクションを行うことにより、継続中のテナント・ジョブの実行を阻止することができる。これらの仲裁アクションは、継続中のテナント・ジョブをパッシブ状態へ移行させ、且つ新たなテナント・ジョブをアクティブ状態へ移行させることを、含むことができる。継続中のテナント・ジョブをパッシブ状態へ移行させるとき、スケジューリング・コンポーネント５３０の目標は、対象のロール・インスタンスを、可能な限りはやく現在のオフライン・コンディションからオンライン・コンディションへ持って行くことである。そのために、継続中のテナント・ジョブの実行は、対象のロール・インスタンスにおいてホールドに置かれるか、または実行を終了することを許可されて（例えば、図４の作業ステージ４４０を行う）明確な状態移行経路を通って出て行くかの、何れかである。継続中のテナント・ジョブがホールドに置かれたとき、新たなテナント・ジョブは、対象のロール・インスタンスで実行され、新たなテナント・ジョブの実行が完了すると、対象のロール・インスタンスで、前の継続中のテナント・ジョブが、割り込まれたところから再開される。
【００９７】
[00105]  継続中のテナント・ジョブが対象のロール・インスタンスでの実行を終了することを、スケジューリング・コンポーネント５３０が許可したときの場合、継続中のテナント・ジョブが所定の時間内に終了することを保証するために、タイムアウト論理が施行され得る。動作において、対象のロール・インスタンスが、所定の時間が満了する前にオンライン・コンディションを呈することができなかったとき、タイムアウト論理は、新たなテナント・ジョブのデプロイメントをブロックすることを止めさせるように、継続中のテナント・ジョブに実行の早期停止を強制する。しかし、タイムアウト論理の利点は、対象のロール・インスタンスで継続中のテナント・ジョブの現在のステージ（例えば、図４のステージ４３０、４４０、および４５０）を、割り込まれずに完了するように実行することを可能にすることであり、従って、阻止の間、サービス・アプリケーション３５０を、首尾一貫した状態に置く。
【００９８】
[00106]  例示の実施形態では、継続中のテナント・ジョブを終わらせるためにタイムアウト論理により割り当てられる予め定めた量の時間は、高い優先度の新たなテナント・ジョブによりターゲットとされるサービス・アプリケーション（１以上）へ割り当てられた特権レベルに部分的に基づいて、変化し得る。換言すると、特権レベルは、一般に、継続中のテナント・ジョブを中断させる前にファブリック・コントローラー２９５により待たれる時間に対してサービス・アプリケーションの挙動が影響を与えることを可能とされるレベルを、表す。多くの場合、低い特権レベルを割り当てられたサービス・アプリケーション（１以上）に短い時間が割り当てられるのとは異なり、高い特権レベルを割り当てられたサービス・アプリケーション（１以上）には、「準備」および「レストア」のステージを終了させるために長い時間が割り当てられ得る。例えば、鍵となる内部アプリケーションには、第三者のホストするアプリケーションよりも高い特権レベルが与えられ得る。これらの特権レベルは、基礎的プラットフォームの管理者がテナント・ジョブを実行するためのポリシー６０５を確立した後に、変更することができる。別の例では、サービス・アプリケーション（１以上）へ割り当てられた特権レベルは、例えば、テナント・ジョブの障害の場合に操作アラームを生成するときなどに、他のオペレーションを制御するために用いることができる。
【００９９】
[00107]  上記で、阻止のイベントにおいて行われるアクションの様々な実施形態を説明したが、異なる優先度のテナント・ジョブは、異なって処理され得、また、スケジューリング・コンポーネント５３０において代替のアクションを呼び出し得ることを、理解および認識すべきである。
【０１００】
[00108]  サービス・アプリケーション３５０でテナント・ジョブをインプリメントするとき、ファブリック・コントローラー２９５は、サービス・アプリケーション３５０のロール・インスタンスのランタイム正常性（health）情報を、管理ロール６２０へ公開することができる。この正常性情報は、ファブリック・コントローラー２９５がホスト・エージェント６１５のインスタンスに対して発行するタイムスタンプを有するメッセージ（例えば、ＸＭＬドキュメント）であって、ワイヤー・プロトコル６１６を介してサービス・アプリケーション３５０へ供給されるメッセージを介して、管理ロール６２０に対して使用可能とすることができる。一般に、ワイヤー・プロトコル６１６は、ホスト・エージェント６１５とサービス・アプリケーション３５０のロールとの間での通信を運ぶ。図６に示されるように、典型的には、ワイヤー・プロトコル６１６とホスト・エージェント６１５との間は１対１の対応である。
【０１０１】
[00109]  実施形態では、正常性情報を使用可能にするプロセスは、サービス・アプリケーション３５０のロール・インスタンスにクエリを行うことを含み、これは、それらの正常性情報をファブリック・コントローラー３５０へ報告することになり、プロセスはまた、メッセージを管理ロール６２０が検討することを可能にする前に正常性情報を集めることを含む。メッセージの検討後、管理ロール６２０は、問題（例えば、オンライン・コンディションへ戻ることに失敗）を経験した１以上のロール・インスタンスを検出することができ、救済アクション（例えば、障害が生じたロール・インスタンスのリブートをファブリック・コントローラー２９５に要求する）を行うことができる。従って、ロール・インスタンスの正常性情報を理解することにより、管理ロール６２０は、テナント・ジョブの結果を評価すること、および／またはテナント・ジョブの次のステージへ進むかを計算することが、可能となる。
【０１０２】
[00110]  実施形態では、正常性情報はまた、サービス・アプリケーション３５０のロール・インスタンス（１以上）における特定の内部状態の存在（１以上）（presence(s)）を記述する内部状態情報を含む。一般に、内部状態情報は、ファブリック・コントローラー２９５がサービス・アプリケーション３５０の一部へのテナント・ジョブを開始するときのタイミングに影響を及ぼすように、用いることができる。単に例証を目的とする図６に示すように、サービス・アプリケーション３５０が、ロールＡの３つのインスタンス（Ａ１、Ａ２、およびＡ３）と、ロールＢの３つのインスタンス（Ｂ１、Ｂ２、およびＢ３）とを含む場合、内部状態情報は、ロールＡの何れのインスタンスが第１内部状態をローカルに格納するか、およびロールＢの何れのインスタンスが第２内部状態情報をローカルに格納するかを、記述することができる。継続中のテナント・ジョブの特定のフェーズがデプロイされた後、テナント変更マネージャー５８０が管理ロール６２０へ、オフライン・コンディションにするようにターゲットとされたロール・インスタンスの指示を通信するとき、管理ロール６２０は、ターゲットとされたロール・インスタンスをオフライン・コンディションへ持って行っても安全であるかを判定するために、正常性情報を調べることができる。
【０１０３】
[00111]  例えば、管理ロール６２０は、ロール・インスタンスＡ１（第１内部状態情報を維持する）およびＢ１（第２内部状態情報を維持する）をオフライン・コンディションへもって行くことに関してのフィードバックを求められたときに、第１内部状態情報がロールＡの少なくとも２以上のインスタンスで複製されたか、および第２内部状態情報がロールＢの少なくとも２以上のインスタンスで複製されたかを判定するために、正常性情報を調べることができる。内部状態情報が、ターゲットとされたロール・インスタンス（Ａ１およびＢ１）の外部で第１および第２の内部状態情報が複製されたことを示すとき、管理ロール６２０は、継続中のテナント・ジョブをスケジュールされたようにデプロイできることを、信号で示すことができる。しかし、内部状態情報が、ターゲットとされたロール・インスタンス（Ａ１およびＢ１）の外部で第１および第２の内部状態情報が複製されていないことを示すとき、管理ロール６２０は、第１および第２の内部状態情報をロール・インスタンスＡ２、Ａ３、Ｂ２、およびＢ３のうちの１以上のものでそれぞれに複製するために、継続中のテナント・ジョブが遅延されることを、要求することができる。この遅延は、管理ロール６２０の時間が第１および第２の内部状態の可用性を保つことを可能にする。上述のように、要求された遅延はファブリック・コントローラー２９５により考慮されるが、常に与えられるわけではない（例えば、継続中のテナント・ジョブの優先度に基づく）。
【０１０４】
プロセスのフロー
[00112]  ここで図７を参照すると、本発明の実施形態に従った、クラウド計算ネットワークのファブリック・コントローラーとサービス・アプリケーションとの間のインタラクションを容易にするための方法７００を全体的に示すフロー図が示されている。ここでは、「ステップ」および／または「ブロック」という用は、用いられる方法の様々なエレメントを意味するように用いられ得るが、これらの用語は、個々のステップの順序が明確に記述されていないかぎり、また、明確に記述されている場合を除き、ここで説明する様々なステップ中またはステップ間での何れかの特定の順序を暗示するものと、解釈すべきではない。方法７００は、最初に、ブロック７１０に示すように、サービス・アプリケーションの１以上のロール・インスタンスを含む第１アップデート・ドメイン（ＵＤ）を選択することを、含むことができる。典型的に、ロール・インスタンス（１以上）は、オンライン・コンディションで動作しており、サービス・アプリケーションの機能をサポートする個々のコンポーネント・プログラム（例えば、サービス・アプリケーションのロールの１つの複製）を表す。
【０１０５】
[00113]  方法７００は、ブロック７１２に示すように、テナント・ジョブ（例えば、プラットフォームにより開始されるアップデート、顧客により開始されるアップデート、プラットフォームにより開始される修復、または顧客により開始される修復）を実行するために第１ＵＤを準備することを、更に含むことができる。例示の実施形態では、第１ＵＤを準備することは、少なくとも以下のステップ、即ち、サービス・アプリケーション内の管理ロールへ、ファブリック・コントローラーの、テナント・ジョブを実行することのインテントを知らせるステップと（ブロック７１４を参照）、テナント・ジョブにより影響を受けるロール・インスタンス（１以上）の内部状態が、テナント・ジョブにより影響を受けないサービス・アプリケーションの部分で複製されたかを判定した後に、管理ロールから応答を受け取るステップ（ブロック７１６を参照）とを含む。第１ＵＤのロール・インスタンス（１以上）を準備後、ブロック７１８に示すように、オフライン・コンディションへの、それらのロール・インスタンス（１以上）のディスエーブル化を開始する。一般に、ロール・インスタンス（１以上）をディスエーブル化することは、第１ＵＤ内の１以上のロール・インスタンスをホストするノードのセットを動作不能にすることを含む。テナント・ジョブは、ロール・インスタンス（１以上）がオフライン・コンディションとなった後、ブロック７２０に示すように、第１ＵＤに対して実行することを可能とされる。
【０１０６】
[00114]  更に、方法７００は、ブロック７２２に示すように、テナント・ジョブの実行を完了した後に、オンライン・コンディションへと第１ＵＤのロール・インスタンス（１以上）をレストアすることを、含むことができる。例示の実施形態では、オンライン・コンディションへと第１ＵＤのインスタンス（１以上）をレストアすることは、少なくとも以下のステップ、即ち、テナント・ジョブにより影響を受けたロール・インスタンス（１以上）が機能することを確認するステップと（ブロック７２４を参照）、ロール・インスタンス（１以上）へのテナント・ジョブの実行が完了したことを管理ロールに伝えるステップと（ブロック７２６を参照）、従って、サービス・アプリケーションに対して、タスクを行うためにロール・インスタンス（１以上）を用いることを再開するように、促すステップとを含む。一般に、オンライン・コンディションへと第１ＵＤ内のロール・インスタンス（１以上）をレストアすることはまた、ロール・インスタンス（１以上）をホストするノードのセットを動作可能にすることを含む。第１ＵＤ内のロール・インスタンス（１以上）をオンライン・コンディションへとレストアした後、方法７００は、テナント・ジョブを実行するためのロール・インスタンスの第２ＵＤを選択することにより、続けることができる。典型的には、第１ＵＤと第２ＵＤとは、メンバーシップにおいて相互排他的であり、それぞれは、クラウド計算ネットワーク全体を通じてのテナント・ジョブの伝播において個別的なフェーズを表すことができる。
【０１０７】
[00115]  ここで図８を参照すると、本発明の実施形態に従った、テナント・ジョブを実行するときに高優先度のジョブをスケジュールするための方法８００を全体的に示すフロー図が示されている。方法８００は、サービス・アプリケーションに対してテナント・ジョブを実行する指示を受け取ることと（ブロック８１０を参照）、サービス・アプリケーションの１以上のロール・インスタンスを含むアップデート・ドメイン（ＵＤ）を識別することと（ブロック８１２を参照）を含む。このとき、ロール・インスタンス（１以上）はオンライン・コンディションで動作している。テナント・ジョブを実行するためにＵＤが準備され（ブロック８１４を参照）、その後、オフライン・コンディションへとＵＤのインスタンス（１以上）がディスエーブルにされる（ブロック８１６を参照）。例示の実施形態では、テナント・ジョブを実行するためにＵＤを準備するプロセスは、下記の論理ステップ、即ち、サービス・アプリケーション内の管理ロールへ、テナント・ジョブを実行するインテントを通知する論理ステップと、管理ロールから肯定的応答を受け取る又は管理ロールから否定的応答を受け取る論理ステップとを含む様々な論理ステップを、含む。
【０１０８】
[00116]  或る後のときに、ブロック８１８で示されるように、高優先度のジョブをインプリメントする指示を受け取る。ここで用いるフレーズ「高優先度」は、限定することを意味せず、優先度スキーム内でテナント・ジョブより優先されることが予め定められている任意のジョブを表し得る。高優先度のジョブをインプリメントする指示を受け取った後、ブロック８２０で示すように、テナント・ジョブのデプロイメントが、高優先度のジョブへ明け渡される。例示の実施形態では、明け渡すプロセスは、以下の論理ステップ、即ち、オンライン・コンディションへとロール・インスタンス（１以上）をレストアする切り詰めたオペレーション・セット（truncated set of operations）を行うことを、サービス・アプリケーションに命令する論理ステップ（ブロック８２２を参照）と、テナント・ジョブをホールドに置く論理ステップ（ブロック８２４を参照）と、ロール・インスタンス（１以上）に対して高優先度のジョブの実行を開始する論理ステップ（ブロック８２６を参照）とを含む様々な論理ステップを含む。
【０１０９】
[00117]  高優先度のジョブの実行を完了した後、ブロック８２８に示すように、テナント・ジョブのデプロイメントが再開される。例示の実施形態では、再開するプロセスは、以下の論理ステップ、即ち、オフライン・コンディションへのＵＤのロール・インスタンス（１以上）のディスエーブル化を再開する論理ステップ（ブロック８３０を参照）と、ロール・インスタンス（１以上）へのテナント・ジョブの実行を可能にする論理ステップ（ブロック８３２を参照）とを含む様々な論理ステップを含む。テナント・ジョブの実行が完了した後、ブロック８３４に示すように、ＵＤのロール・インスタンス（１以上）を、オンライン・コンディションへとレストアすることができる。例示の実施形態では、オンライン・コンディションへとロール・インスタンス（１以上）をレストアするプロセスは、以下の論理ステップ、即ち、テナント・ジョブにより影響を受けたロール・インスタンス（１以上）が機能することを確認する論理ステップと、ロール・インスタンス（１以上）へのテナント・ジョブの実行が完了したことを管理ロールに伝える論理ステップ、従って、サービス・アプリケーションに対して、様々なタスクを行うためにロール・インスタンス（１以上）の使用を再開するように促す論理ステップとを含む様々な論理ステップを、含む。
【０１１０】
[00118]  本発明の実施形態を、全ての点で限定ではなく例示であることを意図した特定の実施形態と関連して説明した。本発明の範囲から離れずに、代替の実施形態も、本発明の実施形態と関連する当業者には明らかになるであろう。
【０１１１】
[00119]  上記から、本発明が、明白であり且つシステムおよび方法に内在する他の利点と共に、上記の全ての目的および目標を達成するために、良好に適合するものであることが、分かるであろう。特定のフィーチャーおよびサブコンビネーションは実用性があり、他のフィーチャーおよびサブコンビネーションを参照せずに用いることができることが、理解されるであろう。これは、特許請求の範囲により考慮されており且つその範囲内にある。
【図１】
2015505095.tif 000003
【図２】
2015505095.tif 000004
【図３】
2015505095.tif 000005
【図４】
2015505095.tif 000006
【図５】
2015505095.tif 000007
【図６】
2015505095.tif 000008
【図７】
2015505095.tif 000009
【図８】
2015505095.tif 000010
【国際調査報告】
2015505095.tif 000011
2015505095.tif 000012