JP6568576B2 - サーバー・プラットフォーム上においてアトミック・タスクを開始するときにおける制御 - Google Patents

Description

[0001] 計算システムおよび関連するネットワークは、人間が働き、遊び、そして伝える方法に大変革を起こした。私たちの生活のほぼあらゆる面が、いろいろな意味で計算システムによって影響を受ける。計算システムは、現在では、広範囲に広がる通信を可能にするように、ネットワークおよびインターネットに大々的に接続されている。このような計算ネットワークの広い能力により、ネットワークを通じて提供される種々のサービスの激増が生じた。ネットワーク・サービスの例には、ウェブ・サイト、電子メール、メッセージング、ソーシャル・ネットワーク、データーベース管理、仮想化、カレンダー管理、ストレージ、ポリシー管理等が含まれる。

[0002] １つの計算モデルでは、プラットフォームは複数のテナント（例えば、コンポーネント・プログラム）をホストし、各テナントがそれら自体のサービスをそのテナントのプロバイダーの顧客に提供する。プラットフォームは、例えば、サーバー・プラットフォームであってもよく、１つ以上のサーバーによってサポートされてもよい。また、プラットフォームはクラウド・プラットフォームであってもよく、この場合プラットフォームはデーター・センターのリソースの全てを有する。クラウド・プラットフォームは、プライベート・クラウド、パブリック・クラウド、または各々の一部を代表するハイブリッド・クラウドであってもよい。

[0003] いずれの場合でも、複数のテナントをホストするとき、プラットフォームは、各テナントのデーターが保護されることを確保するため、そして十分な計算リソースが各テナントに割り当てられることを保証するために、多数の保証措置(safeguard)を採用する。また、プラットフォームは、各テナントに関連するワークフローを把握する。各テナントがその対応するワークフローにわたって進展するに連れて、プラットフォームは、各ワークフローに従っていること、そしてワークフローの種々のタスクが時宜を得て首尾良く遂行されることを保証する。したがって、ワークフロー管理は、特に複数のテナントを管理するときには、プラットフォームの重要な役割となる。

[0004] 本明細書において特許請求する主題は、いずれの欠点を解決する実施形態にも、以上で説明したような環境のみにおいて動作する実施形態にも限定されない。むしろ、この背景は、本明細書において説明する実施形態を実施することができる１つの実証的技術分野を例示するために提示されたに過ぎない。

[0005] 本明細書において説明する少なくとも一部の実施形態は、複数のテナントを実行するサーバー・プラットフォーム（クラウド・プラットフォームのような）の動作に関する。具体的には、本明細書において説明する実施形態は、サーバー・プラットフォームおよびそのテナントの１つ以上が、アトミック・タスク(atomic task)を調整するのを助ける。アトミック・タスクは、サーバー・プラットフォームによって実行されることになっているが、少なくとも潜在的な影響をテナントに対して有する。

[0006] 具体的には、サーバー・プラットフォームは、特定のテナントに時間枠を許容し、この時間枠内でテナント自体が１つ以上のタスクの各々の開始(initiation)を承認することができる。テナントは、結局、サーバー・プラットフォームに入手可能でない情報を有することができ、更に、テナントの観点から特定のタスクを開始するならばいつが適しているかに関連する可能性がある情報を有することができる。サーバー・プラットフォームは、時間枠に時間制約を強いることによって、アクションの遅れからそれ自体を保護することができる。時間枠が経過した後、テナントはもはや特定のタスクの開始をトリガーすることに対して制御することができず、代わりにサーバー・プラットフォームが特定のタスクの開始時刻を決定することを担当する。したがって、テナントにはサーバー・プラットフォームによって実行されるタスクの開始を制御することに対する柔軟性が与えられ、一方サーバー・プラットフォームはそのリソースを保護するための制御のレベルを維持し、種々のテナントの要望を調和する。

[0007] この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を判断するときに補助として使用されることを意図するのでもない。

[0008] 以上で挙げたおよびその他の利点ならびに特徴を得ることができる仕組み(manner)を説明するために、添付図面を参照して種々の実施形態の更に特定的な説明を行う。これらの図面は実施形態の見本を図示するに過ぎず、したがって本発明の範囲を限定するように解釈してはならないことを理解した上で、添付図面を使用することによって、更に具体的にそして詳細に実施形態について説明する(described and explained)。
図１は、本明細書において説明するいくつかの実施形態を採用することができる計算システムを抽象的に示す。 図２は、複数のテナントが実行するサーバー・プラットフォームを含み、説明する原理を採用することができる環境を示す。 図３は、少なくとも１つのテナントを含むサーバー・プラットフォームにおいて特定のアトミック・タスクをスケジューリングする方法のフローチャートを示す。 図４は、本明細書において説明する原理によるタスクおよび時間枠の指定(designation)を示す。 図５は、本明細書において説明する原理による補足情報の例を示す。

[0014] 本明細書において説明する少なくとも一部の実施形態は、複数のテナントを実行するサーバー・プラットフォーム（クラウド・プラットフォームのような）の動作に関する。具体的には、本明細書において説明する実施形態は、サーバー・プラットフォームおよびそのテナントの１つ以上が、アトミック・タスク(atomic task)を調整するのを助ける。アトミック・タスクは、サーバー・プラットフォームによって実行されることになっているが、少なくとも潜在的な影響をテナントに対して有する。

[0015] 具体的には、サーバー・プラットフォームは、特定のテナントに時間枠を許容し、この時間枠内でテナント自体が１つ以上のタスクの各々の開始(initiation)を承認することができる。テナントは、結局、サーバー・プラットフォームに入手可能でない情報を有することができ、更に、テナントの観点から特定のタスクを開始するならばいつが適しているかに関連する可能性がある情報を有することができる。サーバー・プラットフォームは、時間枠に時間制約を強いることによって、アクションの遅れからそれ自体を保護することができる。時間枠が経過した後、テナントはもはや特定のタスクの開始をトリガーすることに対して制御することができず、代わりにサーバー・プラットフォームが特定のタスクの開始時刻を決定することを担当する。したがって、テナントにはサーバー・プラットフォームによって実行されるタスクの開始を制御することに対する柔軟性が与えられ、一方サーバー・プラットフォームはそのリソースを保護するための制御のレベルを維持し、種々のテナントの要望を調和する。

[0016] 図１に関して、計算システムの序論についていくらか記載する。次いで、後続の図面に関して、本明細書において説明する原理を使用する支援(supporting)アーキテクチャおよび方法について説明する。

[0017] 今日、計算システムは、増々多種多様な形態をなしつつある。計算システムは、例えば、ハンドヘルド・デバイス、アプライアンス、ラップトップ・コンピューター、デスクトップ・コンピューター、メインフレーム、分散型計算システム、または従来では計算システムと見なされなかったデバイスであってもよい。この説明および特許請求の範囲において、「計算システム」(computing system)という用語は、少なくとも１つの物理的および有形プロセッサー、ならびにプロセッサーによって実行することができるコンピューター実行可能命令を有することができる物理的および有形メモリーを含む任意のデバイスまたはシステム（またはその組み合わせ）を含むように、広く定められるものとする。メモリーは、任意の形態をなすことができ、計算システムの本質(nature)および形態に依存してもよい。計算システムは、ネットワーク環境にわたって分散されてもよく、複数の要素計算システムを含んでもよい。

[0018] 図１に示すように、計算システム１００は、その最も基本的な構成では、通例少なくとも１つのハードウェア処理ユニット１０２とメモリー１０４とを含む。メモリー１０４は、物理システム・メモリーであるとしてもよく、揮発性、不揮発性、またはこれら２つの何らかの組み合わせであってもよい。また、「メモリー」という用語は、本明細書では、物理記憶媒体のような、不揮発性大容量ストレージを指すために使用されることもある。計算システムが分散型である場合、処理、メモリー、および／または記憶能力も分散することができる。本明細書において使用する場合、「実行可能モジュール」または「実行可能コンポーネント」という用語は、計算システムにおいて実行することができるソフトウェア・オブジェクト、ルーチン、またはメソッドを指すことができる。本明細書において説明する異なるコンポーネント、モジュール、エンジン、およびサービスが、計算システムにおいて実行するオブジェクトまたはプロセスとして実装されてもよい（例えば、別個のスレッドとして）。

[0019] 以下に続く説明では、１つ以上の計算システムによって実行されるステップを参照しながら、実施形態について説明する。このようなステップがソフトウェアで実装される場合、このステップを実行する関連計算システムの１つ以上のプロセッサーは、コンピューター実行可能命令を実行したことに応答して、計算システムの動作を指令する。例えば、このようなコンピューター実行可能命令は、コンピューター・プログラム製品を形成する１つ以上のコンピューター読み取り可能媒体において具体化することができる。このような動作の一例は、データーの操作を伴う。コンピューター実行可能命令（および操作されたデーター）は、計算システム１００のメモリー１０４に格納することができる。また、計算システム１００は、通信チャネル１０８も内蔵することができる。通信チャネル１０８は、計算システム１００が、例えば、ネットワーク１１０を介して、他のメッセージ・プロセッサーと通信することを可能にする。

[0020] 本明細書において説明する実施形態は、特殊目的コンピューターまたは汎用コンピューターを含むまたは利用することができ、以下で更に詳しく説明するように、例えば、１つ以上のプロセッサーおよびシステム・メモリーのような、コンピューター・ハードウェアを含む。また、本明細書において説明する実施形態は、コンピューター実行可能命令および／またはデーター構造を搬送または格納するために、物理コンピューター読み取り可能媒体または他のコンピューター読み取り可能媒体も含む。このようなコンピューター読み取り可能媒体は、汎用コンピューター・システムまたは特殊目的コンピューター・システムによってアクセスすることができる任意の入手可能な媒体とすることができる。コンピューター実行可能命令を格納するコンピューター読み取り可能媒体は物理記憶媒体である。コンピューター実行可能命令を搬送するコンピューター読み取り可能媒体は送信媒体である。つまり、一例として、そして限定ではなく、本発明の実施形態は、少なくとも２つの全く異なる種類のコンピューター読み取り可能媒体、即ち、コンピューター記憶媒体および送信媒体を含むことができる。

[0021] コンピューター記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭまたは他の光ディスク・ストレージ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、あるいは所望のプログラム・コード手段をコンピューター実行可能命令の形態で格納するために、またはデーター構造を格納するために使用することができ、更に汎用コンピューターまたは特殊目的コンピューターによってアクセスすることができる任意の他の有形媒体を含む。

[0022] 「ネットワーク」とは、コンピューター・システムおよび／またはモジュールおよび／または他の電子デバイス間における電子データーの移送を可能にする１つ以上のデーター・リンクとして定められる。情報がネットワークまたは他の通信接続（ハードワイヤ接続、ワイヤレス、あるいはハードワイヤ接続またはワイヤレスの組み合わせ）を介してコンピューターに転送または提供されるとき、コンピューターはこの接続を正しく送信媒体と見なす。送信媒体は、所望のプログラム・コード手段をコンピューター実行可能命令の形態でまたはデーター構造を搬送するために使用することができ、汎用コンピューターまたは特殊目的コンピューターによってアクセスすることができるネットワークおよび／またはデーター・リンクを含むことができる。以上のものの組み合わせも、コンピューター読み取り可能媒体の範囲に含まれてしかるべきである。

[0023] 更に、種々のコンピューター・システム・コンポーネントに到達したとき、コンピューター実行可能命令の形態であるプログラム・コード手段またはデーター構造を自動的に送信媒体からコンピューター記憶媒体に（またはその逆に）転送することができる。例えば、ネットワークまたはデーター・リンクを介して受信されたコンピューター実行可能命令またはデーター構造は、ネットワーク・インターフェース・モジュール（例えば、「ＮＩＣ」）内にあるＲＡＭにバッファされ、次いで最終的にコンピューター・システムのＲＡＭ、および／またはコンピューター・システムにおいてそれよりも揮発性でないコンピューター記憶媒体に転送することができる。このように、コンピューター記憶媒体は、送信媒体も利用する（またはこれを主に使用するのであっても）コンピューター・システム・コンポーネントに含むことができることは理解されてしかるべきである。

[0024] コンピューター実行可能命令は、例えば、命令およびデーターを含み、プロセッサーにおいて実行されると、汎用コンピューター、特殊目的コンピューター、または特殊目的処理デバイスに、一定の機能または機能の集合を実行させる。コンピューター実行可能命令は、例えば、バイナリー、またはアセンブリー言語のような中間フォーマット命令といった、プロセッサーによる直接実行の前に何らかの変換（コンパイルのような）が行われる命令であってもよく、あるいはソース・コードであってもよい。構造的特徴および／または方法論的ステップに特定の文言で、本主題について説明したが、添付する特許請求の範囲において定められる主題は、以上で説明した特徴やステップに必ずしも限定されないことは理解されよう。逆に、以上で説明した特徴およびステップは、特許請求の範囲を実現する形態例として開示したまでである。

[0025] 尚、本発明は、多くのタイプのコンピューター・システム構成を有するネットワーク計算環境においても実現できることは当業者には認められよう。コンピューター・システム構成には、パーソナル・コンピューター、デスクトップ・コンピューター、ラップトップ・コンピューター、メッセージ・プロセッサー、ハンドヘルド・デバイス、マルチプロセッサー・システム、マイクロプロセッサー・ベースまたはプログラマブル消費者用電子機器、ネットワークＰＣ、ミニコンピューター、メインフレーム・コンピューター、移動体電話機、ＰＤＡ、ページャ、ルーター、スイッチ等が含まれる。また、本発明は分散型システム環境においても実施することができ、ネットワークを介して（ハードワイヤ接続データー・リンク、ワイヤレス・データー・リンク、またはハードワイヤ接続およびワイヤレス・データー・リンクの組み合わせのいずれかによって）リンクされたローカルおよびリモート・コンピューター・システムの双方がタスクを実行する。分散型システム環境では、プログラム・モジュールはローカルおよびリモート双方のメモリー記憶デバイス内に配置されてもよい。

[0026] 図２は、説明する原理を採用することができる環境２００を示す。環境２００は、複数のテナント２２０が実行するサーバー・プラットフォーム２０１を含む。各テナントは、例えば、環境２００においてサービスを実行しているサービス・プロバイダーに関連するソフトウェアであってもよい。例えば、サーバー・プラットフォーム２０１は、１つのサーバー、複数の分散型サーバー、あるいはパブリック・クラウド、プライベート・クラウド、またはハイブリッド・クラウドを構成するクラウド計算環境であることも可能である。サーバー・プラットフォーム２０１は、クラウド計算環境における場合には広く分散されることもありそうであるが、図１の計算システム１００について以上で説明したように構成することができる。

[0027] サーバー・プラットフォーム２０１は、テナント２２０の各々のワークフロー・ステータスを追跡し、各テナントのワークフロー・ステータスを完了する目的に向かってアトミック・タスクを実行する。時間が進むに連れて、サーバー・プラットフォーム２０１が特定のテナントに関してワークフローを開始することができ、またはその特定のテナントが、ワークフローを開始するように求めることができる。

[0028] テナントが開始するワークフローでは、サーバー・プラットフォーム２０１がテナントと調整してワークフローを開始し継続することができる。例えば、テナントが、このテナントの役割のインスタンスの一部を新たなバージョンに更新することを決定したと仮定する。テナントはこの意思をサーバー・プラットフォーム２０１に伝えることができる。次いで、サーバー・プラットフォーム２０１は、承認のために、このアクションをテナントに差し戻す(present back)。テナントが要求したアクションを承認のためにこのテナントに差し戻す理由は、テナントがその意思を表明した時点では、サーバー・プラットフォームが開始したアクションが全くないことがあり得るからである。サーバー・プラットフォーム２０１が、テナントが開始したアクションを実行する準備ができる時点までに、他のプラットフォームがアクションを開始することもあり得る。したがって、この時点において、テナントは、他の保留中のアクションの方がもっと短い時間制約を有する可能性が潜在的にあるという状況(context)では、いつインスタンスがアップグレードされるか制御することを望むこともあり得る。

[0029] サーバー・プラットフォーム２０１は、ワークフロー・ステータス・ストア２１１にアクセスすることができる。ワークフロー・ステータス・ストア２１１は、各テナントに関して現在アクティブなワークフローを追跡するのを補助し、更にワークフロー自体の構造を追跡するのを補助する（各ワークフローにおいて実行される次のタスクを識別するように）。

[0030] 強力なサーバー・プラットフォームは、多くの場合数百または数千ものテナントをホストすることができる。しかしながら、図示する実施形態では、簡略さおよび明確さのために、３つのテナント２２１、２２２、および２２３のみが図示されている。しかしながら、本明細書において説明する原理の主旨や範囲から逸脱することなく、楕円２２４は、プラットフォーム内において任意の数のテナントが動作してもよいことを象徴的に表す。したがって、本明細書において説明する原理は、プラットフォーム内で動作する実際のテナント数に限定されず、更にテナントがプラットフォームに追加されるまたはプラットフォームから削除されることがあるので、テナントの数さえも一定ではない。

[0031] このようなテナントは、全く無関係であってもよい。例えば、１つのテナントが企業向けに電子メール・サービスを提供してもよく、他のテナントが世界中で顧客が製品を注文することができるウェブ・サイトを提供してもよく、更に他のテナントが動物およびペットの世話についての話題に応えるブログ・サービスであってもよい。サーバー・プラットフォーム２０１は、各テナントのデーター所有権およびプライバシーを尊重するために、各テナント間で適正なデーター分離を維持し、更に各テナントに関連するアクティブなワークフローの遂行に向けて適正な処理リソースを割り当てる。

[0032] 図３は、少なくとも１つのテナントを含むサーバー・プラットフォームにおいて特定のアトミック・タスクをスケジューリングする方法３００のフローチャートを示す。方法３００のステップの一部は、図２のサーバー・プラットフォーム２０１によって（また恐らく具体的にはコントローラー２１０によって）実行され、「プラットフォーム」という見出しの下で図３の左側の列に示されている。方法３００のステップのその他のものは、「テナント」という見出しの下で図３の右側の列において表されるように、対応するテナント（例えば、テナント２２１）によって実行される。方法３００は、恐らくテナントに影響を及ぼす可能性がある新たなタスクが実行されようとするとき、所与のテナントに関して繰り返し実行することができる。

[0033] 方法３００は、プラットフォームが１つ以上の（潜在的に複数の）アトミック・タスクを識別したときに開始される（ステップ３１１）。アトミック・タスクは、サーバー・プラットフォームによって実行されるが、少なくとも特定のテナントに影響を及ぼす潜在的な可能性がある。例えば、図２を参照すると、以後「特定事例」(specific case example)と呼ぶ例において、プラットフォーム２０１のコントローラー２１０が、プラットフォーム２０１が４つのタスクを実行することを決定したと仮定する。これらのタスクは、テナント２２１に影響を及ぼす潜在的な可能性があり、以後、タスクＡ、タスクＢ、タスクＣ、およびタスクＤと呼ぶ。テナントに影響を及ぼす可能性があり、プラットフォームが実行する可能性があるタスクの例には、テナントの全てまたは一部が動作している物理機械(physical machine)をリブートすること、テナントの全てまたは一部を実行する仮想機械を初期化し直すこと、テナントのソフトウェア・コンポーネントを更新すること、テナントのコンフィギュレーションを更新すること、テナントに利用可能なリソースを追加または削除すること等が含まれる。

[0034] 一実施形態では、ワークフロー・ステータス・ストア２１１に格納されているワークフローを評価することによって、プラットフォーム・コントローラー２１０によってタスクを識別する。例えば、プラットフォーム・コントローラー２１０は、テナント２２１に対してアクティブなワークフローおよび新たなワークフローを評価し、そのワークフロー・ステータスに基づいて次のアトミック・タスクを決定することができる。ワークフローは、１つのアトミック・タスクのように単純であってもよく、またはいつ実行すべきかまたは実行できるかについて何らかの時間的関係がある複数のアトミック・タスクを含んでもよい。テナント２２１のワークフローは、プラットフォーム２０１またはテナント２２１のいずれの指令で開始されたのでもよい。ある場合には、所与のテナントに影響を及ぼす可能性があるタスクを発見するために、プラットフォーム・コントローラー２１０は、テナントにアクティブに割り当てられたワークフロー以外のワークフローを調べることもできる。例えば、特定のタスクが、各々異なるテナントを担当する３つの仮想機械が実行中である機械の物理リブートを必要とする場合、このリブートするタスクは、これらのテナントの各々に影響を及ぼすと考えることができる。タスクが仮想機械の停止を伴う場合、恐らく、その仮想機械によって実行されているテナントだけが影響を受けると判定される。このため、この説明および特許請求の範囲において、プラットフォームがタスクの開始に対する制御を特定のテナントに与えるとき、この特定のテナントはこのような制御を１つ以上の他のテナントと共有することができる。

[0035] 必ずしも全部のタスクではないが、タスクの一部に対して、プラットフォームは、影響を受けたテナントに、対応するタスクをいつ開始するかについて何らかの制御を行わせることもできる。つまり、テナントは、対応するタスクの開始の是認(endorsement)を与える。例えば、特定事例において、プラットフォーム２１０が、タスクＤを単に先に進めることを決定し、一方プラットフォームは、タスクＡ、Ｂ、およびＣをいつ開始するかについて、テナント２２１が何らかの制御を行うべきことを決定したと仮定する。テナントがタスクの開始について何らかの制御を行うことができるとプラットフォームが決定したタスクに対して、プラットフォーム・コントローラーは、テナントが特定のタスクの開始について制御を行うことができる時間枠も特定する（ステップ３１２）。この時間枠は、時間切れとして考えることもでき、この後では、プラットフォームは任意の時点でタスクを開始してもよい。

[0036] 特定される時間枠は、プラットフォームおよびテナントに対するタスクの緊急性に依存してもよい。例えば、タスクを緊急に実行しなければならない場合（タスクＤの場合のように）、恐らくプラットフォームはテナントに制御を渡さない。しかしながら、緊急性が少し低めのタスクに対して、時間枠は比較的短い。一般に、タスクがプラットフォームに対して緊急性が低い程、時間枠を長くすることができる。時間枠は無限であってもよく、その場合、テナントは、プラットフォームがいつタスクを開始するかについて、自由な裁量を有する。時間枠はテナント毎に異なってもよい。例えば、いくつかのテナントには、プラットフォームによって、他よりも高いレベルのサービスが提供されるとしてもよい。一般に、このようなテナントには、プラットフォームにタスクを開始することを命令するための時間枠を長くして付与することができる。

[0037] 次いで、プラットフォームは、プラットフォームによって実行されるが、少なくともテナントに影響を及ぼす潜在的な可能性がある１つ以上のアトミック・タスクの指定(designation)を行う(generate)（ステップ３１３）。図２に関する特定事例では、コントローラー２１０は指定を行い、その指定内でタスクＡ、Ｂ、およびＣを識別する。

[0038] また、コントローラーは、タスク毎に時間枠を決定し、それを指定の中に含ませた。例えば、恐らく、タスクＡの時間枠は１５分であり、タスクＢの時間枠は１５日であり、タスクＣの時間枠は空白である（恐らく、暗示的に終端がない無限時間枠を伝える）。このように、プラットフォーム・コントローラー２１０は、タスクＡを実行するまで１５分だけ待つ用意があり、いつプラットフォームにタスクＡを開始させるかについて、その１５分の期間内だけテナント２２１の裁量を許容することを決定した。同様に、プラットフォーム・コントローラー２１０は、タスクＢを実行するまで１５日だけ待つ用意があり、いつプラットフォームにタスクＢを開始させるかについて、その１５日の期間だけテナント２２１の裁量を許容することを決定した。最後に、プラットフォーム・コントローラー２１０は、テナント２２１がタスクＣを実行しようとする限り待つ用意があると決定した。例えば、恐らく、タスクＣは、全体としてプラットフォームには影響を及ぼさず、テナント２２１のみに影響を及ぼす。

[0039] 次いで、ステップの識別および任意の対応する時間枠を含む指定を、このステップが影響を及ぼす特定のテナントに伝える（ステップ３１４）。例えば、これは１回の通信で行われてもよい。同様に、必要に応じて、プラットフォームは、特定のタスクをいつ承認するか判断するときに特定のテナントを補助するために、補足情報も提供する（ステップ３１５）。例えば、特定事例では、コントローラー２１０は、タスクＡ、Ｂ、およびＣを識別し、更に該当する場合は、それらの関連する時間枠を特定する通信（恐らくは１回の通信）を、テナント２２１に向けて行わせる。例えば、図４は、テナントに伝えることができる表の例を示す。ここでは、この表は、各タスクＡ、Ｂ、およびＣの識別を含む。更に、タスク毎に、時間枠が伝えられる。また、サーバー・プラットフォーム２０１は、時間枠を変更することもでき、または実行すべきステップを取り消すこともできる。これは、サーバー・プラットフォーム２０１からそれぞれのテナントへの別個の通信において行われてもよい。

[0040] ステップ３１４および３１５のその通信において、プラットフォーム・コントローラー２１０は補足情報も伝えることができる。繰り返すと、補足情報は、テナントがプラットフォームに対応するタスクを開始させるときを判断するために役に立つあらゆる情報を含むことができる。例えば、任意の所与のタスクについて、補足情報は、タスクを実行する際のリカバリー(recovery)までの推定時間または平均時間、一旦開始命令が検出されてからタスクがプラットフォームによって開始されるまでの期待時間または平均時間というような、タスク特定情報を含むことができる。例えば、図４において、各タスクはリカバリーに対する平均時間も含む。また、補足情報は、データーの利用可能性、ストレージ・アクセス速度、メモリー使用度、プロセッサー利用度等のような、タスク実行のその他の結果も含むことができる。

[0041] また、補足情報は、テナント特定情報も含むことができる。例えば、プラットフォーム・コントローラーが、プラットフォームの視点から推定したテナントの健全性、特定のテナントの状態（例えば、テナント上で実行する種々のソフトウェアのバージョン）、テナントのコンフィギュレーション等を指定することもできる。例えば、図５は、テナントに伝えることができ、テナントの４つのコンポーネントの各々について健全性ステータス（この場合、コンポーネントが実行しているか否か）を指定する健全性の表を示す。

[0042] 次いで、テナントは最適に(optimally)指定を受ける（ステップ３２１）。したがって、特定事例では、テナント２２１は、タスクＡ、Ｂ、およびＣの指定をプラットフォーム・コントローラー２１０から受ける。したがって、テナントは、このテナントがいつタスクＡを実行するか制御することができる１５分の窓を有し、このテナントがいつタスクＢを実行するか制御することができる１５日の窓を有し、このテナントがいつタスクＣを実行するか制御することができる無限の窓を有することを知る。

[0043] 次いで、対応する時間枠内でタスク承認の表現で応答することにより、または承認を表現せずに時間枠を経過させることによって、テナントは各タスクを承認する（ステップ３２２）ことによって、暗示的に、サーバー・プラットフォームが特定のアトミック・タスクを実行することを承認する。承認を表現する場合、１回の通信において、複数のタスクに対する承認の表現を与えることができる。例えば、特定事例では、１３分のマークにおいて、テナント２２１がタスクＡおよびＢ双方を開始することを決定したと仮定する。双方のタスクの時間枠内にあるので、テナントは双方のタスクについてその制御を未だ行うことができる。したがって、１回の通信で、テナント２２１はタスクＡおよびＢの開始を許可することができる。

[0044] 次いで、プラットフォームは、指定の通信に対応する応答ステータスに基づいて、サーバー・プラットフォームが特定のタスク実行を進めることを決定する（ステップ３１６）。例えば、特定事例では、１３分のマークにおいて、プラットフォーム・コントローラー２１０は、テナントがタスクＡおよびＢを先に進めることを承認したことの指示をテナント２２１から受ける。この場合、サーバー・プラットフォームは自由に先に進める。しかしながら、タスクＡに関してテナント２２１から通信がないまま、１５分が経過したと仮定する。この時点において、（応答が受け取られていないという）この応答ステータスを受けて、プラットフォームは、応答がないことを、先に進めることに対する暗黙の了承として解釈することができる。したがって、プラットフォームはタスクＡを先に進めることができる。

[0045] このメカニズムは、プラットフォームとテナントとの間における通信の問題に対して回復力がある(resilient)。例えば、タスクおよび時間枠の指定がテナントによって受け取られなかった、および／またはタスクを実行することの明示的な承認がプラットフォームによって全く受け取られなかったと仮定する。この場合、プラットフォームは、プラットフォーム・コントローラーとテナントとの間で通信の完全な遮断を想定しても、タスクを実行し続ける。例えば、一旦対応する時間枠が経過したなら、プラットフォームはタスクを実行することを引き受けるだけである。

[0046] テナントに影響を及ぼす特定のタスクをいつ開始するかについて、そのテナントに制御させることができると、タスクをいつ始めるかの判断に関連する情報をテナントがより多く有することができるという点で役に立つ。例えば、プラットフォームはテナントが健全でない（例えば、実行していない）ことを確信するが、テナントはそうでないことを知っている場合、プラットフォームは、通常であれば、テナントに補正措置を直ちに取らせればよいであろう。しかしながら、テナントはそれ自体の健全性を知っているので、テナントはそれに関してそれ程緊急性がなくてもよい。したがって、このメカニズムは、テナントには分かっている事実を考えて、テナントがその高いインテリジェンスを使用して、もっと適した時刻までタスクを遅らせることを許可する。これには、状況から考えて一層適したペースでワークフローを進めることを可能にするという効果がある。

[0047] 本発明は、その主旨や本質的な特性から逸脱することなく、他の特定的な形態においても具体化することができる。説明した実施形態は、あらゆる観点において、限定的ではなく例示的なものとして解釈されるものとする。したがって、本発明の範囲は、以上の説明によってではなく、添付した特許請求の範囲によって示される。請求項の均等の意味および範囲に該当する全ての変更は、それらの範囲内に包含されるものとする。

Claims (11)

1. 少なくとも１つのテナントを含むサーバー・プラットフォームにおいて特定のアトミック・タスクをスケジューリングするためのコンピューターによって実行される方法であって、前記コンピューターによって実行される方法が、当該コンピューターによって実行される方法のコンピューター実行可能命令を実行する１つ以上のプロセッサーによって実行され、前記コンピューターによって実行される方法が、
   前記テナントが、前記サーバー・プラットフォームによって実行されるが少なくとも前記テナントに影響を及ぼす潜在的な可能性がある少なくとも１つの特定アトミック・タスクを含む１つ以上のアトミック・タスクの指定を前記サーバー・プラットフォームから受けるステップであって、前記指定が、前記サーバー・プラットフォームが前記特定アトミック・タスクを実行することを承認するために前記テナントが制御することができる特定の時間枠を指定する、ステップと、
   前記テナントが、前記サーバー・プラットフォームが前記特定アトミック・タスクを実行することを承認するステップと、
   を含む、コンピューターによって実行される方法。
2. 請求項１に記載のコンピューターによって実行される方法において、前記サーバー・プラットフォームを承認するステップが、
   前記テナントが、前記特定アトミック・タスクを承認する明示的な通信を前記サーバー・プラットフォームに送ることなく、前記特定の時間枠の終了まで待つことによって、前記サーバー・プラットフォームが前記特定アトミック・タスクを実行することを暗示的に承認するステップを含む、コンピューターによって実行される方法。
3. 請求項１又は２に記載のコンピューターによって実行される方法において、前記サーバー・プラットフォームを承認するステップが、
   前記テナントが、前記特定の時間枠内に、前記サーバー・プラットフォームに、前記特定アトミック・タスクの明示的な承認を伝えるステップを含む、コンピューターによって実行される方法。
4. 請求項１〜３のいずれか一項に記載のコンピューターによって実行される方法であって、更に、
   前記テナントが、前記サーバー・プラットフォームによって実行されるタスクを提案するステップを含み、前記１つ以上のアトミック・タスクの指定が、少なくとも部分的に前記提案されたタスクに基づく、コンピューターによって実行される方法。
5. コンピューター実行可能命令を含むコンピューター・プログラムであって、前記コンピューター実行可能命令が、複数のテナントを含むサーバー・プラットフォームの１つ以上のプロセッサーによって実行されると、前記サーバー・プラットフォームに、前記複数のテナントの内特定のテナントのために、特定のタスクをスケジューリングするためのコンピューターによって実行される方法を実行させ、前記コンピューターによって実行される方法が、
   前記特定のタスクを含み、前記サーバー・プラットフォームによって実行されるが少なくとも前記特定のテナントに影響を及ぼす潜在的な可能性がある１つ以上のアトミック・タスクを識別するステップと、
   前記１つ以上のアトミック・タスクの指定を行うステップであって、前記指定が、前記特定のテナントが、前記サーバー・プラットフォームが前記特定のタスクを実行することを承認するために制御することができる少なくとも１つの特定の時間枠の特定を含む、ステップと、
   前記指定を前記特定のテナントに伝えることを少なくとも試させるステップと、
   前記指定の通信に対応する応答ステータスに基づいて、前記サーバー・プラットフォームが前記特定のタスクの実行を進めることを決定するステップと、
   を含む、コンピューター・プログラム。
6. 請求項５に記載のコンピューター・プログラムにおいて、前記サーバー・プラットフォームが前記特定のタスクの実行を進めることを決定するステップが、前記特定の時間枠内に前記特定のテナントから明示的な承認を受けたことに応答して実行される、コンピューター・プログラム。
7. 請求項５又は６に記載のコンピューター・プログラムにおいて、前記サーバー・プラットフォームが前記特定のタスクの実行を進めることを決定するステップが、前記特定の時間枠内に前記特定のテナントから明示的な承認を受けることなく、前記特定の時間枠が経過したと判定したことに応答して実行される、コンピューター・プログラム。
8. 請求項５〜７のいずれか一項に記載のコンピューター・プログラムにおいて、前記サーバー・プラットフォームが前記特定のタスクを実行することを承認するために前記特定のテナントが制御することができる少なくとも１つの特定の時間枠の特定を含む、前記１つ以上のアトミック・タスクの指定を行うステップが、前記サーバー・プラットフォームによって実行される、コンピューター・プログラム。
9. 請求項５〜８のいずれか一項に記載のコンピューター・プログラムにおいて、前記特定の時間枠が、前記サーバー・プラットフォームによって取り消し可能である、コンピューター・プログラム。
10. 請求項５〜９のいずれか一項に記載のコンピューター・プログラムにおいて、前記コンピューターによって実行される方法が、更に、前記特定のテナントが前記特定のタスクをいつ承認するか判断するときに前記特定のテナントを補助するために補足情報を提供するステップを含む、コンピューター・プログラム。
11. 請求項５〜１０のいずれか一項に記載のコンピューター・プログラムを記録した記録媒体。

Images