JP6190389B2 - 分散型計算環境において計算を実行する方法およびシステム - Google Patents

Description

[0001] クラウド計算環境は、対応するインフラストラクチャーにユーザーが投資する必要なく、大量の計算リソースにアクセスすることを許す発展性(potential)を提供する。代わりに、計算環境は、クラウド計算プロバイダーによってサービスとして提供することができる。これによって、ユーザーが要求する計算リソースを計算ジョブのサイズおよび重要性に一致するように調整することが可能になる。しかしながら、サービスとして利用可能な追加の計算リソースを最大限利用するには、計算タスクをもっと小さい部分に分割し、タスクを実行するために複数の物理的または仮想的プロセッサーを使用することができるようにする必要がある場合もある。

[0002] 種々の実施形態において、スケーラブルな環境においてアプリケーション定義ジョブを区分するための一般的なフレームワークを可能にするシステムおよび方法を提供する。この一般的なフレームワークは、ジョブのパーティショニングを、そのジョブの他の側面(aspects)から切り離す。その結果、アプリケーション定義ジョブを定めるために必要とされる労力が減少されるかまたは最小限とされる。これは、ユーザーがパーティショニング・アルゴリズムを提供することを要求されないからである。また、一般的なフレームワークは、分散型環境内において計算を実行するマスターおよびサーバーの管理も容易にする。

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

[0004] 本発明について、添付図面を参照しながら以下に詳しく説明する。
図１は、本発明の形態による分散型計算環境の一例の種々の形態を模式的に示す。 図２は、本発明の形態による分散型計算環境の一例の種々の形態を模式的に示す。 図３は、本発明の形態による分散型計算環境の一例の種々の形態を模式的に示す。 図４は、本発明の形態にしたがって、包括パーティショニング環境においてジョブを実行するための種々のインターフェース間における相互作用を模式的に示す。 図５は、本発明の形態による包括パーティショニング環境の一例を示す。 図６は、本発明の形態にしたがって、アクティブなマスター・ロール(master role)間でバックアップ・マシンを供給する例を示す。 図７は、本発明の実施形態を実現するときの使用に適した計算環境例のブロック図である。 図８は、本発明の形態にしたがって、マスター・ロールにバックアップ・マシンを供給する他の例を示す。 図９は、本発明の種々の実施形態による方法の例を示す。 図１０は、本発明の種々の実施形態による方法の例を示す。 図１１は、本発明の形態にしたがって、フォールト・ドメイン(fault domain)およびアップグレード・ドメインに関するマスター・ロールにバックアップ・マシンを供給する形態例を示す。

全体像
[0013] ネットワークを介するデーター送信の高速化、および他のネットワーク機構の改善のために、計算リソースが大きなネットワークを介して分散される環境において、大規模な計算タスクを実行することが増々可能になりつつある。第１位置におけるユーザーが、ジョブまたは計算タスクを計算サービスに提出し、このユーザーが直接的には知らないコンピューターのグループにおいてこのタスクを実行させることができる。ユーザーのタスクを実行する計算リソースは、複数の位置にわたって分散されてもよい。１つ以上の位置に配置された第１グループの計算リソースが、ユーザーの計算タスクを実行するために、データーおよび他の情報を格納することができ、一方第２グループの計算リソースは、同じ位置にあることも１組の１つ以上の異なる位置にあることも可能であり、この計算タスクを実行するために使用することができる。

[0014] 種々の分散型計算リソースへのアクセスは、計算リソースがどこに配置されているかユーザーが心配することなく、ジョブ・タスクを実行することを可能にする。また、分散型リソースは、ユーザーが、計算タスクを指定された時刻までに完了させるというような、計算タスクに対する目標を満たすために、使用されるリソースの量を増大（または縮小）する機会を与える。しかしながら、分散型計算リソースを使用すると、ユーザーには複数の課題が生ずる。従来より、ユーザーまたはアプリケーション設計者は、特定の分散型計算環境をどのように利用するか決定するために、アプリケーションまたはジョブの設計からリソースを転用する(divert)必要があった。

[0015] 種々の実施形態において、クラウド計算環境のような分散型環境においてスケーラブルなアプリケーションを構築するための包括フレームワークを可能にするシステムおよび方法を提供する。この包括フレームワークは、ジョブまたは作業項目のパーティショニング(partitioning)を、そのジョブまたは作業項目に関連する計算の実行から切断することを可能にする。これによって、分散型環境の所有者は、理解し易いやり方または簡略化されたやり方でリソースをユーザーに提供しつつ、分散型リソースに対して高い可用性を提供することが可能になる。この包括フレームワークは、スケーラビリティ、フォールト・トレランス、および／または可用性というような機構を扱うためのフレームワークを提供することによって、分散型環境のためのアプリケーション設計の複雑さを低減しつつ、これらの機構に取り組むために要する労力量を低減または最少にする。その結果、このフレームワークは、アプリケーション設計者に、分散型環境の要件に対して余分な時間を費やす代わりに、アプリケーションに集中させることができる。
定義
[0016] 「キー」は、包括パーティショニング・フレームワークにおいて使用される基本概念の１つである。キーとは、名称空間(namespace)またはドメインからの値である。名称空間の一例は、クラウド計算環境における全ての記憶アカウントに対応する識別子である。このような例では、キーはアカウント名、アカウント番号、または特定のアカウントを参照することを可能にする他の識別子に対応することができる。名称空間の他の例は、ジョブの入力パラメータに可能な英数字値の範囲である。好ましくは、名称空間にわたるキーは、キーが連続値の範囲として記述できるように、何らかの編成方法も有する。例えば、キーは、数字で、アルファベットで、ハッシュ値に基づいて、または範囲開始および範囲終了として２つのキーを指定することに基づいて、きーの範囲を定めることを可能にする任意の他の便利な連続的なやり方で編成することができる。

[0017] 「パーティション」とは、低（含む）および高（除外する）キーによって定められる範囲である。パーティションは決して空の範囲になることはできない。望ましければ、１つのパーティションがドメインの範囲全体を含むのでもよい。パーティションは、２つの異なるパーティションの範囲間に重複がないように、互いに排他的に定められる。全てのパーティションの連合は、ドメインまたは名称空間全体にわたる。

[0018] 「パーティション・サーバー」とは、クラウド計算環境内部において、０個以上のパーティションにサーブするロール・インスタンス(role instance)に対応する仮想マシンである。パーティションは、同時に１つよりも多いパーティション・サーバーによってサーブされない。しかしながら、所与のパーティション・サーバーが、そのパーティション・サーバーによって現在サーブされているパーティションを全く有さない場合もある。パーティション・サーバーは、種々のアクションを実行するために、アプリケーション定義インターフェース(application-defined interface)および固定インターフェース（パーティショニング・システムによって定められる）の双方を含むことができる。

[0019] 「パーティション・マスター」とは、パーティションをパーティション・サーバーに割り当てるまたは割り当てを解除することによってというようにして、所与のタイプのロールのためにパーティション・サーバーを管理するロールである。また、パーティション・マスター・ロールは、パーティション・サーバーが割り当てられたパーティションにまだサーブしていることを検証することによってというようにして、パーティション・サーバーを監視する。通例、このロールはフォールト・トレランスに対して冗長である。パーティション・マスターは、種々のアクションを実行するために、アプリケーション定義インターフェースおよび固定インターフェース（パーティショニング・システムによって定められる）の双方を含むことができる。

[0020] 「アプリケーション定義インターフェース」とは、ロール・インスタンスによる実行(performance)のために、クライアントによって定められる計算、動作、または他の機能を指す。アプリケーション定義インターフェースは、パーティション・マスターまたはパーティション・サーバー・ロールのいずれかのために作ることができる。アプリケーション定義インターフェースは、パーティショニング・システムに対する「固定インターフェース」とは対照的である。固定インターフェースは、パーティショニング・システムの一部として提供されるアプリケーション・インターフェースを指す。クライアントは、固定インターフェースのアクションを変更することができない。しかしながら、アプリケーション定義インターフェースは、固定インターフェースと共に使用することができる。例えば、マスター・ロールのための固定インターフェースは、マスター・ロールによって管理される任意のサーバーのステータスを検証するために、ある時間期間毎にハートビート・メッセージを送ることができる。サービス・ロールのための対応する固定インターフェースは、しかるべきやり方でハートビート・メッセージを受信するインターフェースとすることができる。アプリケーション定義インターフェースの一例は、追加情報をハートビート・メッセージに追加するインターフェースとすることができ、一方他の例は、このような追加情報をハートビート・メッセージから抽出するインターフェースとすることができる。この状況において、ハートビート・メッセージ自体の送出は、固定インターフェースである。ユーザーまたはアプリケーションは、メッセージを送るためのプロトコルを変更することはできない。しかしながら、メッセージ・コンテンツを定めるためのインターフェースは、ユーザーによって変更することができる。ハートビート・メッセージにおいて情報を補足するためのインターフェースの基本構造は、システムによって提供されてもよい。しかしながら、クライアントはこのインターフェースによって供給されるコンテンツを変更することができるので、このようなインターフェースは、本明細書では、アプリケーション定義インターフェースとして定められる。

[0021] 他の例として、アプリケーション定義インターフェースは、負荷均衡化の機構全体を提供するために、固定インターフェースと共に使用することができる。パーティションをパーティション・サーバーに割り当てるまたはパーティションを２つのパーティションに分割するためのインターフェースは、固定インターフェースである。しかしながら、アプリケーション定義インターフェースは、マシン間におけるパーティション割り当てを変更する、またはいつパーティションを分割するか決定するというような、いつ負荷均衡化アクションを行うべきかについての表現を供給することができる。

[0022] アクティブなパーティション・マスター・ロールまたはパーティション・サーバー・ロールは、各々、そのロールに対応するデーターを制御する、対応する記憶オブジェクトを有する。記憶オブジェクトの一例は、バイナリー・ラージ・オブジェクト(binary large object)、即ち、ブロブ(blob)である。パーティション・サーバーについては、記憶オブジェクトは、サーブされるパーティションの識別を含む。尚、パーティション・サーバーの記憶オブジェクトは、通例、そのパーティションに対応する基礎データーを含まないことを記しておく。パーティション識別だけを記憶し、基礎データーを別のデーター記憶位置に残しておくことによって、パーティションを１つのサーバーから他のサーバーへ、最少のデーター移転で動かすことができる。パーティション・マスターについては、記憶オブジェクトは、パーティション・マスターの特定のインスタンスがアクティブ・インスタンスであることを成立させるための情報を含む。任意に、記憶オブジェクトは、マスターによって管理されるサーバーの全ての記憶オブジェクトに関する情報も含むことができる。動作の間、マスター・ロールおよびサーバー・ロールは、対応する記憶オブジェクトにリース(lease)を維持することができる。あるロールの記憶オブジェクトにおけるリースが中断される(break)と、対応するロールを終了することができる。

[0023] 以上で記したように、所与のタイプのロールに対するパーティション・マスターは、障害が発生した場合に少なくとも１つの余分なパーティション・マスターが入手可能になるように、冗長であることが好ましい。「ディクテーター」(dictator)は、所与のタイプのロールに対してパーティション・マスター機能を現在実行するパーティション・マスターとして定められる。ディクテーターは、所与のパーティション・マスター・ロールに関連する記憶オブジェクトに対するリースを維持するパーティション・マスターである。

[0024] アクティブ・パーティション・マスター（ディクテーター）は、ハートビートを介してパーティション・サーバーと通信することができる。基本的ハートビートは、「キープアライブ」タイプであり、常に使用される。先に記したように、アプリケーション定義インターフェースは、任意のコマンドおよび／または情報をこのハートビート・メッセージに追加するために使用することができる。

[0025] 種々の実施形態において、ユーザーまたはアプリケーションが、分散型計算環境における処理のために自動的にパーティショニングされる計算を定めることができるように、包括パーティショニング・フレームワークが設けられる。包括パーティショニング・フレームワークを利用するために、ユーザーは名称空間に基づいて計算を定めることができる。名称空間は、その名称空間に関連するデーターに対して任意に実行される１つ以上の計算(computation or calculation)に対応する。ユーザー定義名称空間は、以下で説明するように、ある種のプロパティを有することができる。名称空間が必要なプロパティを有する限り、包括パーティショニング・フレームワークは、アプリケーション定義インターフェースに基づいて、名称空間を自動的にパーティショニングすることができる。このパーティショニングは、パーティショニング・システムと共に提供されるユーザー定義名称空間および固定インターフェースだけを使用して行われる。包括パーティショニング・システムの固定インターフェースだけを使用して名称空間をパーティショニングすることによって、パーティショニングは、ユーザーによって提供されるいずれのアプリケーション定義インターフェースからも切断され、更に実行される計算（１つまたは複数）の特性(nature)からも切断される。

[0026] ジョブの名称空間またはドメインは、計算によって処理されるおよび／または生成されるあるタイプのデーターの全範囲に対する１組の識別子に対応することができる。加えてまたは代わりに、名称空間またはドメインは、計算によって処理および／または生成することができる可能な状態のリストまたは範囲に対応することができる。更に他の選択肢は、名称空間が、分散型環境において実行される計算の複数のインスタンスに対する１組の識別子に対応できることである。計算に可能な全ての名称空間またはドメインが特定されることは必要でない。代わりに、ユーザーは、パーティショニングに使用される名称空間または状態を識別することができる。識別された名称空間またはドメインは、ユーザーが所与のロールを使用して実行することを望む計算の全体にわたらなければならない。計算によって処理されるデーター集合の全体にわたることにより、計算内部における計算のインスタンスの全体にわたることにより、または任意の他の便利なやり方で、計算の全体にわたることができる。キーは、名称空間内部で離散値または状態を指定するために使用することができる。また、キーは、値の範囲を指定するために使用することもできる。キーは範囲を指定するために使用することができるので、上位キーおよび下位キーを指定すると、範囲が一意に識別されるように、名称空間はあるタイプの連続順序を含むことは理解されよう。この順序は、アルファベットに基づく順序というような、従来の順序に基づくことができる。あるいは、この順序は、名称空間内における値のリストを含むファイルに基づく連続順序というように、任意であることもできる。

[0027] 名称空間を定めることに加えて（その名称空間を使用して実行される任意の計算を含む）、ユーザーは、サーバー・ロールに関連する１つ以上のアプリケーション定義インターフェースを提供することができる。アプリケーション定義インターフェースは、パーティション・サーバーが実行することができる１つ以上のタスクまたは機能を表し、そのタスクまたは機能は任意に１つ以上の名称空間を伴う。サーバー・ロールのためのアプリケーション定義インターフェースは、異なるサーバー・ロールが同じデーターまたは状態にアクセスしようとしないように、所与の名称空間において実行される全てのタスクまたは機能を含むことができる。任意に、形態の一例では、ロール内部における一部のアプリケーション定義インターフェースが、同じロール内部における他のアプリケーション定義インターフェースとは異なる名称空間において動作するように、サーバー・ロールがサブロールも含んでもよいことが考えられる。単純な例では、クライアントが、データー集合に対して少なくとも１タイプの計算を実行することを伴う計算を実行することを望むのでもよい。この状況では、クライアントが、データー集合から要求されたエレメント（１つまたは複数）に対して少なくとも１タイプの計算を実行するサーバーの１つのロールを定めることもできる。この１つのロールは、科学計算、データー集合に対する１つ以上の関連データー・マイニング機能、または任意の他の便利な計算を実行するように構成されたロール・インスタンスに対応する１つ以上のサーバーを表すことができる。計算および任意の関連データーは、計算を実行するための名称空間の定義の一部として定めることができる。加えて、計算に関するメトリックをマスター・ロール・インスタンスに提供するためのアプリケーション定義インターフェースというような、１つ以上のアプリケーション定義インターフェースをサーバー・ロールに提供することもできる。サーバー・ロール・インスタンスは、サーバーに渡されたキー値に基づいて、作業すべきデーター集合の１つまたは複数のエレメントを決定することができる。少なくとも１つの追加のマスター・ロールが、サーバーを管理することができ、データー集合パーティションを１つ以上のサーバーに割り当てることを含む。

[0028] 名称空間に基づいて、複数のパーティション・サーバーがその名称空間のための処理の異なる部分を扱うまたは処理するように、計算をパーティショニングすることができる。各パーティションはある範囲のキー値に対応する。パーティションがパーティション・サーバーに割り当てられると、このサーバーは、割り当てられたパーティションに対応する範囲内のキー値を含む任意の要求に対して所望の計算を実行する。サーバーに割り当てられたパーティションは、名称空間の連続順序(serial ordering)に対して、連続(consecutive)である必要はない。

[0029] 包括パーティショニング環境では、パーティションのパーティション・サーバーに対する現在の割り当てを追跡するために、パーティション表を使用することができる。アクティブなマスター即ちディクテーターがパーティションをサーバーに割り当てるとき、最初にこの割り当てを反映するためにパーティション表を更新することができる。次いで、クライアント要求において指定されたキーに基づいてクライアント要求を扱うパーティション・サーバーを決定するために、パーティション表を使用することができる。任意に、パーティショニングされる名称空間毎に異なるパーティション表を有するのではなく、複数のロールに対するパーティション割り当てを追跡するために、１つのパーティション表を使用することができる。一例として、パーティション表におけるエントリーが、ある範囲に対する低キー、その範囲に対する高キー、および要求されたキーに対応するデーターまたは状態に対して要求されたタスクを実行するロール・インスタンスまたはサーバー・インスタンスを含むことができる。また、パーティション表は、以下で更に詳しく説明するように、エポック番号(epoch number)またはバージョン番号というような、他のデーターを含むこともできる。
マスターおよびサーバー・ロール・インスタンスの管理
[0030] ジョブを実行するとき、冗長性を設けるために数個のマスター・ロール・インスタンスを有することが望ましい場合が多い。しかしながら、衝突を避けるために、所与の時点では１つのマスター・ロールだけがアクティブ・マスターになることができる。複数のマスター・ロール・インスタンスが存在する場合、これらのマスター・ロール・インスタンスは、名称空間全体に対応する記憶オブジェクトにおいてリースを求めて競合する。リースが付与されたマスター・ロール・インスタンスが、アクティブ・マスター即ちディクテーターになる。加えて、マスター・エポック番号が、そのマスター・ロール・インスタンスの記憶オブジェクトに格納される。マスターがディクテーターになるとき、この番号を増分し、それをマスター・ロール記憶オブジェクトに書き戻し、その後このエポック番号を使用して、対応するパーティション・サーバーと通信する。また、アクティブ・マスター・インスタンス即ちディクテーターは、パーティション表またはパーティション表の少なくとも一部においてリースを得ることもできる。パーティション・サーバーは、これまでに見られた最高のエポックよりも低いマスター・エポックのハートビートを無視し、こうしてもはやディクテーターではないマスター・ロールからの古いハートビートを避ける。

[0031] １つの選択肢は、記憶オブジェクト・リースによって支配権(dictatorship)を実施する(implement)ために別の支配権ライブラリーを使用することである。別の支配権ライブラリーを有すると、パーティショニング・システムの外部にあるロールに冗長性を実現させるというような、様々な利点を得ることができる。これによって、パーティショニングに関与しないロールが、アクティブなマスター・ロールを選択するために同じ方法を使用することが可能になる。

[0032] 各サーバーはそれ自体の記憶オブジェクトにリースを維持する。サーバー記憶オブジェクト名が、サーバーがその第１パーティション割り当てを受ける毎に、マスターによって生成される。また、各サーバーは、その現在のパーティション割り当て（エポック番号を含むパーティションのリスト）を記憶オブジェクトに格納する。サード・パーティが、サーバーとその記憶オブジェクトとの間のリースを強制的に終了させることができる。この機能は、パーティション・マスター・ディクテーターによって、パーティション割り当てプロトコルにおいてサーバー・リースを中断するために使用することができる。

[0033] マスター・ロールの冗長インスタンスを有することは、障害イベントが発生したときの動作改善に対処するが、冗長なインスタンスは、更新遅れ(stale update)による問題を生ずる可能性もある。更新遅れとは、新たなディクテーターが選択された後に、以前のディクテーターからのメッセージまたは命令がサーバーまたはデーター・ストアによって受信されたという状況を指す。更新遅れの問題は、外部ストアへのメッセージが遅れるまたは順番が変わる（例えば、インターネットを介して）場合、あるいはロールのフェイルオーバーのときに状態がそのストアから読み出される場合に、外部ストアに状態を維持するあらゆるロールまたはコード片(piece of code)に影響を及ぼす虞がある。

[0034] 一例として、ロールに対してパーティション表を更新している最中にフェイルオーバーしたパーティション・マスター（ディクテーター）について考える。最初に、古いマスターがパーティション表の行「Ｘ」の更新を開始する。次いで、古いマスターは作業を中止する。このマスターの冗長インスタンスが、新たなディクテーターとして選択される。この新たなアクティブ・マスターは、パーティション表の行「Ｘ」を使用して、更新し、読み出し、またそうでなければ、あるアクションを実行する。すると、古いマスターからの更新が行き渡るのは、新たなアクティブ・マスターによる行「Ｘ」に対するアクションの後になる。古いマスターからの更新がパーティション表に組み込まれると、この更新は、パーティション表を変化させるが、新たな（現在の）マスターはこの変化を知らない。このため、パーティション表に一貫性のない状態ができる可能性がある。

[0035] 以上の例における問題の１つの解決策は、古いマスターからの古い更新をどうにかして阻止することである。１つの選択肢は、パーティション・マスターに、パーティション表の部分においてリースを入手させることである。マスターのリースは、所与の名称空間に対応する表におけるパーティションの全てに対応することができる。リース範囲を指定する任意の便利な方法を使用することができる。例えば、望ましいのであれば、リースがパーティションの一部のみにわたることができ、および／または複数のパーティションにわたることもできる。新たなディクテーターが選択されても、マスターはリースを介して支配権を争い、サーバーが、古いハートビート・メッセージのような、古い更新を阻止することができるように、エポック番号が供給される。加えて、マスター・ディクテーターは、その状態を構築するときにパーティション表を読む前に、パーティション表（の関連部分）においてリースを取得することもできる。

[0036] 更に一般的には、マスターおよびサーバーの双方がリース・メカニズムを使用して、マスターまたはサーバーにデーター構造を扱うことが割り当てられるときに、ブロブ、表、および／または他のデーター構造に対するリースを取得することによって、古い更新を避けることができる。マスターまたはサーバーが、フェイルオーバーまたはマスターによる割り当て変更の明示的要求のためというように、データー構造にもはや割り当てられなくなったなら、リースは解放される。

[0037] また、古い更新は、マスターとサーバーとの間の通信に対する懸念にもなる可能性がある。古いマスターからのメッセージの処理は、例えば、マスターがディクテーターになるときにエポック番号を入手させることによって、避けることができる。エポック番号は、支配権のフェイルオーバー毎に増大する。このエポック番号は、サーバーのハートビート毎、および／またはマスターからサーバーの他のメッセージ毎に送信することができる。サーバーは、当該サーバーが見たことがある最も大きなエポック番号よりも小さなエポック番号が付いたハートビートを全て無視することができる。この高透かし(high-watermark)エポック番号は、サーバーのソフト状態に格納することができる。マスターおよびサーバーが記憶オブジェクト・リースを介してステータスを伝えている場合も、以上の方法は古いメッセージの問題を避けるのに十分であることができる。代わりに、マスターとサーバーとの間で古いメッセージを避ける他の便利な解決策を使用することもできる。

[0038] 同様のエポック番号方法は、範囲パーティション毎に、以前に割り当てられたサーバーからの古い更新を避けるために使用することができる。例えば、各パーティションは、現エポック番号を有することができ、このパーティションに変化が起こったときに、この現エポック番号がマスターによって更新される。パーティションに対する変化の例には、パーティションの新たなサーバーへの割り当て、パーティションの分割、および２つのパーティションの併合が含まれる。パーティションの新たなサーバーへの割り当ては、エポック番号を１だけ増やすことができる。パーティションの２つ以上の新たなパーティションへの分割は、各子パーティションに、親のエポック番号を１だけ増分した値を受け取らせることができる。２つのパーティションが併合されるとき、併合されたパーティションのエポック番号は、併合前のこれらのパーティションのいずれかの最大エポック番号を１だけ増やした値とすることができる。あるいは、パーティションのエポック番号の増加を追跡する任意の他の便利な方法を使用することもできる。

[0039] パーティション・エポック番号をどのように使用するとよいかについての一例として、パーティション・マスター、２つのパーティション・サーバーＳ１およびＳ２、ならびに第３サーバーＸを有するシステムについて考える。第３サーバーＸは、例えば、パーティション・マスターならびにサーバーＳ１およびＳ２によって処理される名称空間に対する実際のデーター集合を含むデーター・サーバーであることができる。サーバーＳ１およびＳ２はコマンド（または他のメッセージ）をＸに発行する。Ｘのフロント・エンドによる処理のため等で、Ｓ１またはＳ２からＸまでの途中でメッセージが遅れる可能性があると仮定する。Ｘが所与の範囲パーティションについて確認された最大のエポックを追跡するなら別であるが、古いメッセージがＸによって受け入れられる可能性があることは、容易に理解できる。例えば、エポック３のパーティションＰを最初にサーバーＳ１によってサーブすることができる。Ｓ１はメッセージＭ１をＸに送ることができる。メッセージＭ１は、エポック番号３だけでなく、パーティションＰに対応するキーも含む。次いで、パーティション・マスターがパーティションＰをＳ１からＳ２に動かす。割り当ての後、Ｓ２は新たなエポック番号を含むメッセージＭ２をサーバーＸに送る。Ｘは、メッセージＭ１を受信する前に、メッセージＭ２を受信する。このため、Ｍ１が古くなる。次いで、Ｘは古いメッセージＭ１を受信する。エポック番号を追跡することによって、サーバーＸは、古いメッセージＭ１が、もはやパーティションＰには責任がないサーバーからであることを認識することができる。

[0040] 更に古い更新の可能性を避けるために、エポック有効性判断ライブラリーを使用することができる。エポック有効性判断ライブラリーは、受信したメッセージが古くないことを確認することができる。例えば、サーバーが新たなディクテーターからメッセージを受信したときまたは新たなパーティション範囲に関する要求を受信したとき、サーバーはエポック有効性判断ライブラリーをチェックして、メッセージがマスターまたはパーティションに対して現在のエポック番号を含むことを検証することができる。

[0041] 図４は、ロール、パーティション、およびキー間の関係の模式例を示す。図４において、ユーザー４０５は、ユーザーのアカウントにおける情報にアクセスするというような、所望のデーター片に対してアクションを実行する要求を提出する。データーは、キーによって識別される。クライアント要求およびキーは、ロール４２０に渡される。ロール４２０は、クライアントまたはユーザー４０５によって行われるタイプの要求を扱う。ロール４２０は、所与のタイプの要求をロールがどのように扱うか定めるクライアント・ライブラリー４３０を含む。要求のタイプおよびキーに基づいて、ロール４２０はパーティション表４５５を参照して、要求におけるキーに対応するキー範囲を扱う現行のサーバーを発見する。パーティション表４５５における情報は、パーティション・マスター４６０によって行われるパーティション決定に基づいて入力される(populate)。パーティション・マスター４６０は、図４では、複数の可能なパーティション・マスターの内の１つとして示される。冗長性のために、追加の可能なパーティション・マスターがあるが、必要とされるまでアクティブにはならない。図４の例では、複数のパーティション・サーバー４６５が、ロール４２０に要求されるタスクを実行するためのロール・インスタンスとして利用可能である。パーティション表４５５に基づいて、複数のパーティション・サーバー４６５からのパーティション・サーバーＮが、クライアント要求におけるキーに対応するキーの範囲を扱っている。
包括パーティショニング・フレームワークの例
[0042] 図５は、本発明にしたがって、包括パーティショニング・フレームワークを設けるモジュールおよび／またはインターフェースのグループの例を示す。また、図５は、包括パーティショニング環境を利用することができる計算ジョブを提供するアプリケーション定義インターフェースの例も表示する。図５では、キーまたは名称空間がユーザーまたはアプリケーションによって供給されるが、名称空間をパーティショニングするインターフェースは、パーティショニング・システムによって提供される固定インターフェースである。これは、名称空間のパーティショニングを、名称空間に対応するデーターを処理するジョブまたは作業項目を実行することから切断する。

[0043] 図５において、ユーザーによって提供または指定されたコンポーネントまたはインターフェースには少なくとも２タイプがある。ユーザーは、キー（および対応する名称空間）５１０に対する定義、およびアプリケーションに対する複数のサーバー・インターフェース５２０を提供する。先に説明したように、キーはアプリケーションの名称空間を記述する。これによって、パーティショニング・システムは、可能なパーティショニングに対する変数、状態、および／または計算の範囲を知ることができる。キーを定めることに加えて、ユーザーは、このキーに関係する少なくとも３つのインターフェースも提供する。キー５１０に関係するインターフェースは、名称空間においてキーを直列化する機能、キーの直列を解除する機能、および２つのキーを比較する機能を設ける。ユーザーが名称空間およびキー値を選択するので、これらのインターフェースの動作は、パーティショニング・システムによって固定インターフェースとして提供されない(offer)。キーおよび名称空間に関係するインターフェースは、代わりに、ユーザーによってアプリケーション定義インターフェースとして提供される。

[0044] また、ユーザーは、サーバー・ロール・インスタンスによって使用されるアプリケーション定義インターフェース５２０も提供する。サーバー・ロール・インターフェース５２０のためのアプリケーション定義インターフェースは、サーバーがキーに対して動作する要求を受けたときにサーバーがどの動作を実行するかについての機能を含む。例えば、StartServeKeyRangeのインターフェースは、サーバーが所与のキー範囲にサーブし始めるときにこのサーバーが実行することができる１つ以上の動作を定めることができる。対応するStopServeKeyRangeのインターフェースは、サーバーに、キー範囲のサーブを規律正しく終了させることができる。加えて、サーバーから情報を収集することが望ましい場合もある。OnReceivedHeartbeatRequestインターフェースのようなインターフェースは、サーバーがどのようにして追加情報を、現行パーティション・マスターから受信したハートビート・メッセージから抽出するかについて定めることができる。BeforeSendingHeartbeatResponseのような他のインターフェースは、サーバーが、ハートビート・メッセージに応答して、何を追加情報として含むかについて定義することができる。これによって、例えば、サーバーが負荷情報をパーティション・マスターに、負荷均衡化において使用するために、伝えることが可能になる。

[0045] ユーザーがハートビート（または他のメッセージ）交換の一部として追加機能または情報を含ませる場合、ユーザーは、マスター・ロール５３０にユーザー定義インターフェースを提供することもできる。マスター・ロール５３０のためのユーザー定義インターフェースは、GPMaster５３５として模式的に示される、マスター・ロールのための固定インターフェースに対する補足となる。マスター・ロール５３０のためのユーザー定義インターフェースは、必須ではない。

[0046] 図５に示す実施形態では、総合パーティショニング環境(general partitioning environment)は、５つのモジュールおよび／またはグループの固定パーティショニング・システム・インターフェースによって実施可能とされる(enable)。これらは、GPClientモジュール５１５、GPServerモジュール５２５、GPMasterモジュール５３５、GPDictatorモジュール５３６、およびGPLeaseモジュール５４５の一部として示される固定インターフェースを含む。勿論、図５に示すモジュール、インターフェース、および／または機能を構成する他の方法を使用することもできる。

[0047] 図５に示すGPClientモジュール５１５は、クライアント・アプリケーションまたはユーザー５９９によって指定されたキーから、ユーザー要求を扱うサーバーのアドレスへの変換を可能にするインターフェースを有する。GPClientモジュール５１５のインターフェースは、パーティション・マップまたはパーティション表５５９を調べることによって、この参照を実行する。GPClientモジュール・インターフェースは、次に、例えば、キーに対応するサーバー・アドレスを、クライアント・アプリケーション５９９に戻すことができるので、クライアント・アプリケーションは要求を正しいサーバーに導くことができる。

[0048] GPServerモジュール５２５は、所望のユーザー・タスクを実行するためにアプリケーション定義インターフェースと共に作業する(work)インターフェースを有する。GPServerモジュール５２５は、マスター・ロール・インスタンスとサーバー・ロール・インスタンスとの間における通信のためのインターフェースを含む。また、GPServerモジュール・インターフェースは、GPLeaseモジュール５４５のインターフェースとも通信して、各サーバー・ロール・インスタンスに関連するリース・オブジェクトおよびリース・コンテンツを管理する。

[0049] GPMasterモジュール５３５は、マスター・ロール・インスタンスを管理する中核機能のためにインターフェースを提供する。GPMasterモジュール５３５のインターフェースは、マスター・ロール・インスタンスからのディクテーターの選択、ディクテーターとサーバー・ロール・インスタンスとの間の通信（ハートビート・メッセージを介してというような）、およびパーティション管理を扱う。パーティション管理は、更新をパーティション表５５９に供給することを含むことができる。負荷均衡化のために、GPMasterモジュール５３５のインターフェースは、内部アルゴリズムを使用して負荷均衡化を実行することができ、またはGPMasterモジュールは、ユーザーによってアプリケーション定義インターフェースとして提供される代わりの負荷均衡化表現５６０を受けることもできる。任意に、GPMasterモジュール５３５によって扱われるメッセージング機能を、１つ以上の別のメッセージング・インターフェースによって実行することもできる。

[0050] GPDirectorモジュール５３６は、ディクテーターとしてサーブするマスター・ロール・インスタンスに関係する機能を扱うインターフェースを提供する。GPDictatorインターフェースは、マスター・ロール・インスタンスを扱い、支配権を主張し（GPMasterモジュール５３５によって行われる選択において支配権を勝ち取った後のような）、支配権を解放し（フェイルオーバーの後のような）、および古い更新を避けるためのシーケンスまたはエポック番号に対する変更を扱うことができる。

[0051] GPLeaseモジュール５４５は、包括パーティショニング環境内部でリースを管理するインターフェースを提供する。これは、関連する記憶オブジェクト、パーティション、またはリースを得ることができる任意の他のタイプのデーター構造において、マスターまたはサーバーがリースを取得することを可能にすることを含むことができる。
基本的なマスター／サーバー管理プロトコル
[0052] パーティション・マスターがパーティション・サーバーと通信できる１つの方法は、規則的に送られるキープアライブ（「ピング」）ハートビートを介してである。このハートビートは、いずれのパーティションにもサーブしないサーバーを含む、全てのサーバーに送ることができる。サーバーは、そのサーバーが現在サーブしているパーティションのリストで、このキープアライブ・ハートビート（または他のタイプのハートビート・メッセージ）に応答することができる。ハートビート応答は、サーバー・パーティション・リースと共に使用すると、サーバーが正しいパーティションにサーブしていることをマスターに検証させることができる。サーバーが１つ以上のパーティションにサーブしているとき、このサーバーも、バイナリー・オブジェクト即ちブロブというような、それ自体のプライベート記憶オブジェクトにリースを維持する。サーバーが起動するとき、いずれのリースも保持しない。そうするのは、初期のパーティション割り当てのときだけである。記憶オブジェクト・リースも、サーバーによってサーブされるパーティションのリストを含むとよい。ハートビート応答または記憶オブジェクト・リース内の情報のいずれかが、マスターによって予期されるパーティション情報と異なる場合、パーティション情報の矛盾が存在する。

[0053] サーブされるパーティションに関して、マスターとサーバーとの間で矛盾(conflict)が発生した場合、そしてサーバーが１つ以上のパーティションにサーブしようとしている場合、この矛盾は致命的なエラーと見なされる。一例として、マスターは、サーバーがＰ１およびＰ２にサーブしていると考えるが、サーバーはＰ２、Ｐ４、およびＰ５を報告するということがあり得る。この状況では、マスターは、対応するパーティション・サーバー・ブロブにおいてサーバーのリースを中断する。次いで、マスターは警告を発し、パーティション表のために適正な状態を再構築する。これは、マスターの再開時に適正な状態が再構築されるように、マスターを終了することを伴うのでもよい。

[0054] また、マスターおよびサーバーが異なり、サーバーがサーブされているパーティションがないと報告するときも矛盾となる。しかしながら、これは致命的なエラーとは見なされない。これは、例えば、サーバーが２つのハートビート間でフェイルオーバーする場合に発生する可能性があり、またはリースを「保持している」間に１つ以上のハートビート中に停止し次いで再開して次のハートビートに応答する場合にも発生する可能性がある。サーブされているパーティションがないことをサーバーが報告して矛盾が発生した場合、パーティション・マスターは、サーバーの記憶オブジェクトを削除することを試すことができる。成功した場合、いずれのパーティションも他の利用可能なサーバーに割り当てし直すことができる。しかしながら、サーバーの記憶オブジェクトにおけるリースの削除は、サーバーの直前のインスタンスのリースがまだ失効していない場合、失敗する可能性がある。このため、リース期間までの間削除を再試行する必要がある場合もある。１リース期間後に記憶オブジェクトを削除することに失敗すると、致命的なエラーとなる。これは前述のように扱うことができる。マスターが再開するとき、パーティションの割り当てに進む前に、未知の記憶オブジェクトが全て削除されたことを確認する。

[0055] 他の起こり得る障害の状況は、サーバーがリースを保持しているが、このサーバーがあるタイムアウト期間内にハートビート（「キープアライブ」のような）に応答しないときである。この場合も、マスターは、矛盾を解決するために、サーバーの記憶オブジェクトを削除しようとすることができる。記憶オブジェクトを削除することに成功した場合、サーバーはもはや機能していない。サーバーがサーブしていたいずれのパーティションも、他のサーバーに割り当てし直すことができる。記憶オブジェクトを削除することができない場合、マスターは、記憶オブジェクトのコンテンツを読み取り、マスターとサーバーとの間におけるパーティション割り当てに関する矛盾をチェックすることができる。矛盾がない場合、サーバーはサーブし続けることができ、マスターは通常のハートビート処理によって直ちにサーバーに再度「ピング」することを試すことができる。好ましくは、記憶オブジェクトにおいてサーバーのリースを中断する前に、マスターがハートビートを介してサーバーと通信できない期間に対して制限があるとよい。矛盾が検出された場合、この矛盾は、以上で説明したように扱うことができる。

[0056] パーティション割り当てについて、マスターは、関連するパーティション・サーバーへのハートビートに、パーティション割り当て要求を同乗させる（ハートビートは、この場合、加速される）。パーティション割り当て要求は、サーバーの記憶オブジェクトの名称、およびサーブされるパーティションの完全な新たなリストを含む。例えば、パーティションＰ２を、現在Ｐ１にサーブしているサーバーに割り当てるには、パーティション割り当てはＰ１およびＰ２双方を含む。これは、割り当て解除(unassignment)を割り当てに対して直交にする(orthogonal)。Ｐ１およびＰ２をサーブするサーバーからＰ１を外すためには、単にＰ２のみを含む割り当てを送る。マスターは、パーティション割り当てが行われるときには、既にパーティション表を更新している。パーティション表は、パーティションがサーバーに割り当てられるとき（前）にのみ更新され、パーティションがサーバーから外されるときは、更新は必要とされない。

[0057] パーティション・サーバーは、記憶オブジェクト・リースを維持する。記憶オブジェクト・リースは、最初のパーティションがサーバーに割り当てられるときに開始する。記憶オブジェクト・リースは、サーバーが機能停止するまで、またはパーティション表におけるサーバーについての割り当て情報とサーバーによってマスターに報告された割り当て情報との間における矛盾のためというように、マスターがリースを強制的に中断させるまで維持される。記憶オブジェクト名称は、パーティション割り当てと共に渡される。後続の全てのパーティション割り当ては、同じ記憶オブジェクト名称を含むことになる。サーバーがパーティション割り当てを受けると、既存の記憶オブジェクト名称がないサーバーは、パーティション割り当てにおいて供給される記憶オブジェクト名称を取得する。サーバーが既に名称のある記憶オブジェクトを有する場合、このサーバーは要求において供給された名称を既存の名称と比較することができる。これらの名称が異なる場合、サーバーは警告を発し、終了することができる。これは、異なる名称がパーティション割り当て情報における矛盾を示すからである。パーティション割り当てを受けた後、サーバーは、任意の関連情報を、サーバーの記憶オブジェクトに書き込むことができる。この関連情報は、たとえば、サーブするキー範囲、ディクテーターに対するエポック番号、および／またはパーティションに対するエポック番号を含むことができる。次いで、サーバーは、パーティション割り当てを供給したマスターに応答し、任意の新たなパーティションにサーブし始め、外されたあらゆるパーティションにサーブするのを停止することができる。

[0058] パーティション割り当ての後、マスター・ロール・インスタンスは、割り当てを確認したサーバーからの応答を待つ。応答が割り当てと一致しない場合、または応答が遅れた場合、マスター・ロール・インスタンスはサーバーのリースを終了することができる。あるいは、マスター・ロール・インスタンスはサーバー・ステータスを判定するために、サーバーのブロブを調べることができる。例えば、サーバーの記憶オブジェクトが、割り当てが成功したことを示し、応答が不正確なのではなく、単に遅れたまたは失われただけの場合、マスター・ロール・インスタンスは待機して、サーバーが後続のハートビートまたは他のメッセージに正しく応答するか否か確認することができる。エラーが発見され、マスターがサーバーの記憶オブジェクト・リースを中断することができない場合、マスターは、新たなマスター・ロール・インスタンスによるパーティション・マップの再生を強制するために終了することができる。

[0059] 加えて、サーバー・ロール・インスタンスは、それがサーブしている範囲（即ち、パーティション）毎に統計を提供することができる。この統計は、総合パーティショニング・システムには不透明であり、名称／値対のプロパティ・バグとして表すことができる。これらの任意の統計は、ユーザーによって供給される負荷均衡化式を含む、負荷均衡化式に組み込むことができる。

[0060] マスターがアクティブ・マスター即ちディクテーターになったとき、最初に、リースを保持している記憶オブジェクトから新たなエポック番号を得る。次いで、そのシステムのビューを構築するために、そして一貫性がないあらゆる情報を訂正するために、３つの情報を収集する。最初に、マスターはパーティション表を読み取る。パーティション表は、どのパーティションが存在するかについての真理(truth)を含む。好ましくは、マスターは、以前のマスターによる古い書き込みを防止するために、パーティション表を読み取る前に、パーティション表の少なくとも関連部分においてリースを得るとよい。次に、マスターは、全ての既存のサーバー記憶オブジェクトのリストを得る。これは、サーバー記憶オブジェクトのリストを維持することによって、全てのサーバー記憶オブジェクトを指定位置に配置することを要求することによって、または他の便利な方法によって行うことができる。また、サーバーの現在のパーティション割り当てに関して各サーバーに問い合わせるために、ハートビートまたは他のタイプのメッセージが使用される。この問い合わせは、サーバーの記憶オブジェクトの名称を求める問い合わせを含むことができる。尚、以上のタスクは並列に進めることができることを記しておく。

[0061] 収集した情報に基づいて、マスターはパーティション表における割り当てと各サーバーによって報告された割り当てとの間においてあらゆる不一貫性を識別することができる。不一致がある場合、サーバー・オブジェクトにおけるサーバーのリースを中断しマスターを再開するというような、１つ以上の補正アクションを行うことができる。加えて、パーティション表において述べられていないサーバー記憶オブジェクトが識別された場合、これらの記憶オブジェクトをいずれも削除することができる。最後に、サーバーによって確認されていないパーティション表におけるいずれの割り当ても、新たなパーティション・サーバーへの割り当てのために、待ち行列に入れることができる。矛盾を解決した後、マスターは正常のハートビート処理、パーティションの割り当て、および任意の他のマスター機能を開始することができる。
負荷均衡化
[0062] 負荷均衡化は、大まかに３つのアクティビティに分割することができる。負荷均衡化は、パーティションをサーバー間で動かし、１つのパーティションを複数のパーティションに分割し、または複数のパーティションを１つのパーティションに併合することを含むことができる。通例、パーティションの割り当てを第１サーバーから第２サーバーに変更するのは、１つ以上のメトリックに基づいて、第１サーバーが十分な高負荷を有することに応答して行われる。１つのパーティションが大量の負荷を占める(account for)場合、このパーティションの分割を使用して、大きな負荷を複数のサーバー間で分割させることができる。パーティションの併合によって、アクティビティ量が低い方のパーティションを組み合わせることができる。これによって、データー集合のために種々のパーティションを追跡し維持するために必要なオーバーヘッドを低減する。任意に、ユーザーは名称空間に対してパーティション数に上限を定めることができる。パーティションの併合を開始するための閾値は、パーティションの数が上限に近づくに連れて、下げることができる。パーティション数の上限は動的に構成することができる。

[0063] パーティションをいつ分割するかまたは動かすか決定する一例として、名称空間の全てのパーティションを、負荷に基づいて、ソートすることができる。負荷は、パーティションに対する計算を実行することに関係する１つ以上のメトリックを指すことができる。つまり、負荷は、サーバーまたは個々のパーティションに対する全体的なＣＰＵ使用量、サーバーまたはパーティションに使用されたストレージ、サーバー全体または１つのパーティションによって受け取られた要求の数、あるいはサーバーによっておよび／または所与のパーティションに対して実行された作業量を示す任意の他の便利な値を指すことができる。負荷に基づいて、平均パーティション負荷の構成可能な倍数よりも大きな負荷を有する上位Ｎ個のパーティションを分割することができる。Ｎは、動的に構成可能である。例えば、これは、現在のパーティション数の対数に基づくというような、システムにおける現在のパーティション数の関数とすることができ、またはこれはシステムにおける最大許容パーティション数の関数とすることもできる。加えてまたは代わりに、各サーバーの負荷が、サーバーのパーティションの負荷を合算することによって、計算される。次いで、サーバーを負荷でソートすることができ、平均の何らかの構成可能な倍数よりも大きな負荷を有する上位Ｎ個のサーバーが、サーバー間におけるパーティションの移動のために選択される。同様に、平均負荷よりも少ない負荷を有する複数のサーバーが、それよりも負荷が高いサーバーからのパーティションを受けるために選択される。好ましくは、第１サーバーから第２サーバーへのパーティションの移動は、第１サーバーの負荷を平均負荷に近い値まで減少させるが、第１サーバーの負荷が平均負荷未満にならないように実行される。全てのパーティションがほぼ同様の負荷を有する場合には、これを行いやすくなる。以上で説明したパーティションの分割は、パーティション間における負荷の不均衡を減らすために使用することができる。

[0064] 先に記したように、パーティションに対する負荷は、サーバー・ロール・インスタンスによって収集される統計から導くことができる。この情報は、規則的な間隔のハートビート・メッセージを介してというようにして、マスター・ロール・インスタンスに渡される。好ましくは、負荷統計は、負荷メトリックが加算的になるように定められる。これによって、サーバーに対する負荷が、そのサーバーにおける個々のパーティションに対する負荷を合計することに基づいて決定することが可能になる。パーティションおよび／またはサーバーに対する負荷を決定するための１つ以上の式を、別のブロブまたは他の記憶エリアに格納することができる。パーティショニングについての規則または表現は、包括パーティショニング環境によって供給されるデフォルト規則とすることができ、あるいはユーザーが規則および／または表現を供給することができる。

[0065] ユーザーによって供給される負荷均衡化規則および／または表現について、ユーザーは、最初に、負荷均衡化メトリクスとして望まれる１つ以上のメトリクスを識別することができる。適したメトリックの例には、ＣＰＵ使用量、ネットワーク帯域幅使用量、単位時間期間に処理される要求の数、または任意の他の便利なメトリックが含まれる。一部のメトリックは、パーティションに特定であってもよく、一方他のメトリックはパーティション・サーバーにおける全てのパーティションに対してある値に対応するのでもよい。所望のメトリックに基づいて、ユーザーは、次に、各サーバーにおいて所望のメトリックを収集するために１つ以上のインターフェースを提供する。任意に、ＣＰＵ使用量または単位時間期間毎の要求数というような共通メトリックを、ユーザーによって簡単にアクセスされる標準的インターフェースとして供給することができる。収集されたメトリックは、次に、パーティション・サーバーから対応するマスターに、サーバーによって使用されるハートビート・メッセージのようなメッセージを使用して、サーバーのマスターとの現在のステータスを検証するために渡される。

[0066] ユーザーによって識別されたメトリック毎に、総合パーティショニング・システムによって認識された一連の値を計算することができる。一例として、総合パーティショニング・システムは「ディメンション」(dimension)を、ユーザーによって定義された変数として認識することができる。総合パーティショニング・システムにおけるディメンションは、予期されるフォーマット(expected format)を有することができる。ディメンションは、パーティションにわたるメトリックの値に対応するパーティション・メトリックのための表現を含むことができる。他の表現は、サーバー・メトリックのためであることができ、これはサーバーにおける全てのパーティションにわたるメトリックの値に対応する。更に他の表現は、メトリックに対する条件値のためであることができ、これはアクションが行われる状況を定める。

[0067] 単純な状況では、ＣＰＵ使用量をディメンションとしてユーザーによって定めることができる。この例では、ＣＰＵ使用量ディメンションは、サーバーが十分に忙しいのでパーティションを他のサーバーに動かすべきときを判定するために使用される。ユーザーによって定められるディメンションでは、所与のパーティションを求める要求を処理する専用の仮想マシンにおけるＣＰＵ使用率が、パーティション・メトリックとして定められる。この仮想マシンにおける全てのパーティションにわたるＣＰＵ使用率の和を、サーバー・メトリックとして定めることができる。この例では、条件は、全ＣＰＵ使用量の８０％よりも大きいサーバー・メトリック使用量として定めることができる。この条件が発生したとき、パーティションを他のサーバーに動かすことができる。動かすパーティションは、パーティション・メトリックに基づいて選択される。尚、パーティション・メトリックおよびサーバー・メトリックは双方ともユーザーによって定められることを記しておく。つまり、ユーザーは、サーバー・メトリックに類似するパーティション・メトリックを有する必要はない。例えば、サーバー・メトリックは、ＣＰＵ使用量およびネットワーク帯域幅使用量の組み合わせであることができるが、パーティション・メトリックは単に要求率(request rate)に関係するに過ぎない。

[0068] パーティションの再割り当てのためにディメンションを定めることに加えて、ユーザーはパーティション分割をトリガーするためのディメンションも定めることができる。パーティション分割をトリガーするためのディメンションの定義は、パーティションの再割り当てのためのディメンションと同様とすることができ、または異なるディメンションのフォーマットを使用することができる。例えば、サーバー・メトリック表現は、パーティション分割をトリガーするためのディメンションには必要でない場合もある。何故なら、パーティション・メトリック表現の方が、パーティションを分割するときを決定するためには有用であることが期待できるからである。加えて、パーティション分割をトリガーするためのディメンションは、パーティションを分割する条件が満たされるときにどのようにパーティションを分割するかについてのディメンションも含むことができる。尚、パーティション分割をトリガーするためのディメンションは、２つのパーティションを併合するときを識別するのにも有用である場合があることを記しておく。あるいは、ユーザーがパーティション併合のために別のディメンションを定めることができる。

[0069] 更に一般的には、任意の便利な数の条件を、負荷均衡化アクションを行うべきときを決定するために指定することができる。この条件は、複数のディメンションに対応するメトリックというような、１つ以上のディメンションに対応するメトリックを組み込むことができる。負荷均衡化を実行する特定の順序で条件が評価されるように、条件を順序付けることができる。例えば、パーティション分割に関係する条件は、パーティションを異なるパーティション・サーバーに動かす条件よりも順番において前に置くことができる。このような例では、パーティション・サーバーにおける１つのパーティションが大きな割合の負荷を担当する場合、複数のサーバー間において負荷を均衡化するためには、他のパーティションを動かすことは有効ではないかもしれない。最初にパーティションを分割するか否かチェックすることによって、問題の原因となるパーティションを、（恐らくは）負荷が少ない部分に分割することができる。同様に、パーティションの併合は、条件の順序付けにおける早い時期に行うことが望ましいであろう。例えば、大きな複数(a large number of)の低負荷パーティションを有するパーティション・サーバーは、このサーバーにかかる負荷全体が平均よりも低くても、過剰な数のパーティションのために、利用可能ではないと考えられる。割り当てを動かす前にパーティションを併合することによって、このようなサーバーは、追加のパーティション割り当てを受けることが可能になる。

[0070] 負荷均衡化を開始する条件を指定するとき、任意の便利なタイプのメトリックを条件に含ませることができる。つまり、１つのパーティションにかかる負荷、複数のパーティションにかかる負荷、サーバーにかかる負荷、または複数のサーバーにかかる負荷に対するメトリックは、所望通りに、一緒に使用されても別々に使用されてもよい。複数のパーティションまたは複数のサーバーに関係するメトリックについて、単純な例は、平均負荷を定めるために、全てのサーバーにわたる負荷を判定することである。すると、負荷均衡化を実行する条件は、サーバー負荷の絶対値と平均負荷との差というような、サーバーにかかる負荷と平均サーバー負荷との間の差、またはサーバー負荷と平均サーバー負荷からの標準偏差との比較に関係付けることができる。複数のパーティション負荷を使用する場合、サーバーにおいて最も高い負荷がかかるある数のパーティションの負荷を互いに関して考慮することが望ましいこともある。所望の負荷均衡化アクションは、同様の負荷を有する複数のパーティションがあるパーティション・サーバーでは、負荷が大きい１つだけのパーティションがあるパーティション・サーバーとは異なる場合もある。

[0071] パーティションの再割り当て、分割、および併合のためにディメンションを定めることに加えて、ユーザーはディメンションに基づいてパーティションに対するアクションを制限するために１つ以上のフィルターを定めることもできる。例えば、サーバーが７０％よりも高いＣＰＵ使用量サーバー・メトリックまたは１０よりも大きいパーティション数のいずれかを有するとき、このパーティションが新たなパーティション割り当てを受けることを防止することが望ましい場合がある。このような割り当てを防止する割り当てフィルター値を定めることができる。可能なフィルターの他の例には、既存のパーティション・サーバーからのパーティションの移動を防止するフィルター、パーティションの分割を防止するフィルター、またはパーティションの併合を防止するフィルターが含まれる。フィルターのタイプに依存して、フィルターが、負荷均衡化アクションを行うことを防止するのでもよい。あるいは、フィルターが条件の考慮順序を変更することもでき、またはフィルターが、負荷均衡化計算サイクルの間ある条件を完全に飛ばさせることもできる。

[0072] 一例として、全てのサーバー要求が同じ量のリソースを消費する仮説的システムについて考える。このようなシステムでは、適度な負荷メトリックは要求率に基づくことができる。この例では、各サーバー・ロール・インスタンスは、長い時間期間にわたる要求率の平均(RR_SlowMA)と、短い期間にわたる要求率の平均(RR_FastMA)とを収集する。これらの要求率平均は、プロパティ・バッグにおける名称／値対としてマスター・ロール・インスタンスに返送される。次いで、パーティション・メトリック＝max(RR_FastMA, RR_SlowMA)のような単純な負荷メトリックを、負荷均衡化規則において式として定めることができる。ディメンション「負荷」に対するパーティション・メトリックの左辺は、パーティショニング・システム内においてマスター・コンポーネントによって認識される識別子に対応する。この場合、ディメンション「負荷」は、ユーザーによって前もって識別される。右辺は、パーティション・メトリックに割り当てられる負荷値を生成する任意の表現(any arbitrary expression)とすることができる。この場合、負荷は、複数の移動平均の内の１つに基づく、要求数に対応する。パーティション負荷値および／または他の値に基づいて、パーティションが分割される、併合される、またはサーバー間で動かされるべきかに関して、１つ以上の条件を定めることができる。

[0073] 更に一般的には、ユーザーは、負荷均衡化判断を行うために、メトリックおよび表現（条件のような）の任意の組み合わせを定めることができる。負荷均衡化判断を行うためにユーザーによって定められる表現は、条件付きロジックおよび／または多ディメンション制約／最適化目標のためのサポートも含むことができる。つまり、ユーザーは判断ツリーを定めまたは他の条件付きロジックを使用して、いつどのように表現が評価されるかについて順序付けを行うことができる。例えば、ユーザーは、第１表現を評価させ、次いで第１表現の値に基づいて評価するために複数の可能な追加表現から選択することができる。これは、「if-then-else」タイプの条件付きロジック、決定された値に基づく次の表現に対する参照表、または任意の他の便利なタイプの条件付きロジックに基づくことができる。その結果、ユーザーは、負荷均衡化に使用するメトリックおよび表現のタイプを指定する柔軟性を有することになる。指定する柔軟性は、所与の表現が評価されるか否か、およびこのような表現を評価する順序を与えることを含む。尚、表現の評価順序は、以前に評価された表現の値に基づいて動的に決定することもできることを記しておく。

[0074] 負荷均衡化判断を行うためにユーザーによって定められる表現の他の例は、多ディメンション制約／最適化目標を含むことができる。例えば、ユーザーが複数のディメンション（例えば、２つ）を定めることができ、ディメンション毎に、ユーザーは別の最適化目標または制約を定めることができる。ＣＰＵ利用度および要求レイテンシは２つのディメンション例である。ユーザーは、パーティション・サーバーのＣＰＵ使用量が第１閾値（例えば、９０％）よりも低く、同時に定められた１組のパーティション・サーバー（例えば、全てのパーティション・サーバー）にわたって平均要求レイテンシを最小化するように、規則を指定することができる。この手法は、ユーザーがすべきことを正確に指定する「if-then-else」タイプの条件付きロジックとは異なってもよい。このモデルでは、ユーザーが制限および最適化目標を定め、これによってシステムは自動的に解決策を発見することができる。

[0075] 他の仮説的システムでは、ユーザーが評価に対して複数の条件または表現を提供することができる。これらの表現は、所与の名称空間にサーブするパーティション・サーバーに対する種々のＣＰＵ使用量メトリックに基づく。第１表現は、任意のパーティション・サーバーが、名称空間に関係して、６０％よりも高いＣＰＵ使用量を有するか否か評価する。このユーザーについて、使用量が６０％よりも高いＣＰＵがない場合、ユーザーは負荷均衡化を望まない。つまり、第１表現の結果が偽である場合（即ち、ＣＰＵ使用量が６０％よりも高いパーティション・サーバーがない）、負荷均衡化は望まれないので、他の表現は評価されない。少なくとも１つのパーティション・サーバーが６０％よりも高い使用量を有する場合、負荷均衡化アクションを実行することを決定するために、一連の表現を評価することができる。

[0076] 負荷均衡化の結果パーティションを動かすことになった場合、マスター・ロール・インスタンスに２つの割り当て要求を出させることによって、第１サーバーから第２サーバーにパーティションを動かすことができる。第１サーバーへの割り当て要求はこのパーティションを含まず、その結果、第１サーバーはそのパーティションに対するサービスを停止する。第２サーバーへの第２割り当て要求は、このパーティションを含む。

[0077] １つのパーティションが２つ以上のパーティションに分割される状況では、マスター・ロール・インスタンスが分割キーを決定することによって、分割を開始することができる。分割キーは、新たなパーティションの１つに対する包含範囲(inclusive range)の終端を形成するキー値に対応する。分割キーは、任意の便利なやり方で選択することができる。マスターまたはサーバー・ロール・インスタンスは、パーティションの範囲の中間またはその付近でキー値を選択することによってというようにして、パーティションに基づいて分割キーを選択することができる。あるいは、サーバーは、パーティションに関する追加の統計に基づいて分割キーを選択することができる。例えば、パーティション全体に対する負荷を決定するのと同様なやり方でパーティションの種々の部分に対する負荷を追跡するために、サンプリング・ベースのバケット・メカニズム(bucket mechanism)を使用することもできる。次いで、負荷が新たなパーティションに割り当てられるバケットに対して同様となるように、分割キーを選択することができる。

[0078] 所与のロール内では、（アクティブな）マスターは負荷をパーティション・サーバー間で広げることを責務とする。好ましくは、マスターは、１つ以上のサーバーに過剰負荷がかかり、そのため要求を処理できなくなることを防止する。代替実施形態では、負荷の調節は、サーバー毎に１つのパーティション／範囲を維持し、これらの範囲を調節することによって行うことができる。代わりにパーティションを動かすことによって、影響を及ぼすサーバーの数を減らしつつ、負荷の調節を行うこともできる。

[0079] パーティション再割り当てによって負荷を円滑に動かせるように、サーバー当たり最小数のパーティションを有することが望ましい場合が多い。パーティションの数が最少レベルに減ったとき、その後の併合は行われない。同様に、余りに多いパーティションを有することも避けることが望ましい場合が多い。あるサーバーに対してパーティションが最大数に近づくに連れて、パーティションを併合する可能性は高くなるはずである。一例として、サーバー当たり５および８個の間のパーティションを維持することが望ましい場合もある。勿論、本発明の種々の実施形態は、サーバー当たり１つのパーティションからサーバー当たり１００以上のパーティションまでというように、サーバー当たり任意の数のパーティションとでも動作することができる。

[0080] 好ましくは、分割および併合プロトコルは双方共ステートレスである。マスターまたは関与するサーバー（１つまたは複数）のいずれも、パーティショニング・システムにエラーを生ずることなく、いつの時点でもフェイルオーバーすることができる。言い換えると、マスターまたはサーバーのいずれかが分割または併合プロセス中に故障した場合、次のマスターまたはサーバーが、故障がいつ発生したかには関係なく、パーティション割り当ての有効なリストを作ることができる。ステートレスの分割プロトコルでは、パーティショニング・サーバーは、分割アクションを実行することを全く要求されない。一例として、パーティション表は、サーバーＳ１において、低キー値Ｄおよび高キー値Ｈまでの範囲を取るパーティションを含むことができる。この例では、パーティションのエポック番号は２である。ユーザー定義負荷均衡化式に基づいて、このパーティションの一部を他のサーバーに割り当てることができるように、このパーティションを分割することが決定される。マスター・ロール・インスタンスは、サーバーＳ１に分割キーを求める。サーバーＳ１は、Ｇのキーを分割キーとして戻す。次いで、マスターはパーティション表を変更する。以上で記した１つのエントリーの代わりに、この表は今では２つのパーティションを含む。１つは、低キー値Ｄおよび高キー値Ｇを有し、一方第２パーティションは、低キー値Ｇおよび高キー値Ｈを有する。先に記したように、低キー値および高キー値に基づくパーティション範囲定義は、低キー値を含み、高キー値を除外する。パーティション表の変更は、既存のエントリーを変更し新たなエントリーを追加することによって、既存のエントリーを除去して２つの新たなエントリーを追加することによって、または任意の他の便利な方法によって行うことができる。

[0081] 次のハートビート・サイクルにおいて、マスターはサーバーＳ１によってサーブされるパーティションとパーティション表における情報との間に矛盾を検出する。分割が行われたばかりなので、マスターはサーバーＳ１のブロブ・リースを終了しない。代わりに、マスターはパーティション範囲がＤからＧでエポックが３の割り当てをサーバーＳ１に送る。これによって、Ｓ１におけるパーティションの割り当てを、パーティション表における分割パーティションの１つと一致するように変更する。サーバーＳ１から新たな割り当ての承認を受けた後、マスターは第２分割パーティションを他のサーバーに割り当てることができる。第２分割パーティションは、３のエポック番号も有する。あるいは、分割パーティションの双方を最初にサーバーＳ１に割り当て、後の時点で負荷均衡化を実行するために一方または双方のパーティションを動かすこともできる。

[0082] また、２つのパーティションの併合もステートレスに扱うことができる。パーティションを併合するとき、最初のステップとして、併合されるパーティションが現在のサーバーから割り当て解除される。例えば、サーバーＳ２における第１サーバーは低キー値Ｋおよび高キー値Ｍを有することができる。この例では、第１パーティションのエポック番号は７である。サーバーＳ４における第２パーティションは、低キー値Ｍおよび高キー値Ｎを有することができる。この例では、第２パーティションのエポック値は９である。最初のステップとして、パーティション表がサーバーに対して未割り当て値を示すように、これらのパーティションをそれらのそれぞれのサーバーから割り当て解除することができる。次いで、２つのパーティション・エントリーは、低キーＫおよび高キーＮを有する１つのエントリーと置き換えられる。このパーティションに割り当てられるエポック番号は、併合されたパーティションの最高値よりも１大きく、この例では１０に対応する。次いで、新たなパーティションをサーバーに割り当てることができる。
追加の例
[0083] 本発明を説明するためのコンテキストを与えるために、分散型ネットワークまたはクラウド計算環境において計算リソースを編成する例を示す。以下のクラウド計算環境の説明は、代表例として示される。尚、特許請求する発明は、代わりのタイプの編成を有する分散型ネットワーク環境と共に使用できることは当業者には認められよう。以下の定義は、この代表例において使用される。

[0084] 「クライアント」とは、名称空間またはドメインに対してアプリケーション定義インターフェースによるアクションを求める１つ以上の要求を発行するロールとして定義される。クライアントは、ユーザーまたはユーザーの代わりに開始されるプロセスに対応することができる。例えば、特定のアカウントを調べる要求は、アカウント参照を求めてアプリケーションに宛てられた要求に対応し、このアカウント参照は、所望のアカウントに対応するキーを有する全てのアカウントのドメインに対して行われる。

[0085] 「作業項目」とは、クラウド計算環境において実行されるジョブの静的表現である。作業項目は、ジョブの種々の側面を指定することができ、ジョブ・バイナリー（job binaries)、処理されるデーターへのポインター、および任意にジョブを実行するためのタスクを起動するコマンド・ラインを含む。加えて、作業項目は、再実行(reoccurrence)スケジュール、優先順位、および制約を指定することもできる。例えば、ある作業項目を毎日午後５時に起動するように指定することができる。

[0086] 「ジョブ」とは、作業項目の実行インスタンスである。ジョブは、分散型計算を実行するために一緒に動作するタスクの集合体を含む。タスクは、クラウド計算環境において１つ以上の仮想マシンにおいて実行することができる。

[0087] 「タスク」とは、ジョブの基本的な実行単位である。各タスクは、仮想マシンにおいて実行する。ユーザーは、タスク毎にデーターを入力するために、コマンド・ラインおよびポインターに対して追加の入力を指定することができる。タスクは、このタスクの実行中にこのタスクを実行する仮想マシンにおいて、その作業ディレクトリーの下でファイルの階層を作ることができる。

[0088] クラウド計算環境のユーザーは、通例、クラウド計算リソースを使用してジョブを実行することを望む。ジョブは、通例、クラウド計算環境を介してアクセス可能な位置に格納されたデーターに対してジョブを実行することを伴う。運営者がクラウド計算環境を提供する１つの方法は、この環境を複数のレイヤーとして提供することである。図１は、クラウド計算環境内部においてタスクを実行するのに適したシステムの一例を模式的に示す。図１におけるシステムは、タスク・ランタイム・レイヤー１１０、サード・パーティ・タスク・ランタイム・レイヤー１２０、リソース管理レイヤー１３０、ならびにスケジューリングおよび実行レイヤー１４０を含む。

[0089] 図１に示す実施形態では、タスク・ランタイム・レイヤー１１０は、ユーザー１０５からのタスクに対して実行環境およびセキュリティ・コンテキストを設定することを責務とする。また、タスク・ランタイム・レイヤー１１０は、タスクを起動し、タスクのステータスを監視することができる。タスク・ランタイム・レイヤー１１０は、各仮想マシンにおいて実行するシステム・エージェントの形態をなすことができる。また、タスク・ランタイム・レイヤーは、ユーザーのタスク実行可能ファイルにリンクすることができるランタイム・ライブラリーも含むことができる。ランタイム・ライブラリーをタスク・ランタイム・レイヤー１１０の一部として有することによって、システム・エージェントによって実行されるタスクに一層豊富な能力を提供することができる(can potentially)。ランタイム・ライブラリーの例は、タスク間で高速通信を可能にする１つ以上の効率的な通信ライブラリー、他の仮想マシンおよび／または他のタスクからファイルを読み取るための効率的なリモート・ファイル・アクセス・ライブラリー・サポート、タスクをチェックポイント（例えば、バイナリー・ラージ・オブジェクト(binary large object)に）に移動させ再開させるチェックポイント・ライブラリー、ロギング・ライブラリー、ならびに仮想マシンのプール内部で所与のタスクを実行する仮想マシンに跨がって使用される分散型ファイル・システムを提供するためのライブラリーを含む。

[0090] サード・パーティ・タスク・ランタイム・レイヤー１２０は、追加のランタイムを構築し、タスク・ランタイム・レイヤー１１０上で実行することを可能にする。また、サード・パーティ・タスク・ランタイム・レイヤー１２０は、ジョブに対するタスクの実行を調整する追加能力も提供することができる。その例には、仮想マシンのプール内において所与のタスクを実行する仮想マシンに跨がって使用される分散型ファイル・システムを提供するライブラリーにMapReduceランタイムを含むことができる。これによって、ユーザーは、そのユーザーのジョブまたはタスクに合わせて個別にクラウド計算環境を編成することが可能になる。実施形態では、ジョブ・マネージャ・タスクが、クラウド計算リソースを実行および／または制御するために、ユーザーにサード・パーティ・ランタイム・レイヤーを使用させ易くすることができる。

[0091] リソース管理レイヤー１３０は、クラウド計算環境において利用可能な計算リソースの管理を扱う。１つの選択肢は、リソース管理レイヤー１３０に、３つの異なるレベルでリソースを管理させることである。第１レベルにおいて、リソース管理レイヤー１３０はジョブ（即ち作業項目の実行）に関連する仮想マシン、ならびにタスクに関連する各仮想マシンに格納されたファイルの割り当ておよび割り当て解除を管理する。第２レベルにおいて、ジョブに関連する仮想マシンをマシンのプールに集合化することができる。プールは、１つ以上のジョブおよび／または作業項目に関連する仮想マシンを含むことができる。実施形態に依存して、１つのプールが、データー・センターにおける全ての仮想マシン・クラスタ、地理的領域内における複数のデーター・センターに跨がる複数の仮想マシン・クラスタ、または複数の地理的領域におけるデーター・センターに跨がる複数のクラスタのように、複数の仮想マシン・クラスタに跨がる範囲を占めることができる。１つのプールが、数百万というような、大きな複数の仮想マシンを含むことができる。仮想マシンは、数十億までというような、非常に大きな複数のプール内に収容することができる。第３レベルにおいて、リソース管理レイヤーは、所与のプール・グループにおけるジョブまたは作業項目との関連付けに利用可能な仮想マシンの量を管理する。これによって、システムの現在の負荷に基づいて使用される計算リソースの量の動的な調節を可能にする。加えて、現在のプール・グループによって使用されていない仮想マシンを、他のプール・グループへの組み込みのために、解放してクラウド計算環境に戻すこともできる。

[0092] 図１に示す実施形態では、スケジューリングおよび実行レイヤー１４０は、ユーザーによって実行されつつある作業項目、ジョブ、およびタスクを管理する。スケジューリングおよび実行レイヤー１４０は、スケジューリング判断を行い、ジョブおよびタスクを起動すること、および障害時の再試行を責務とする。このようなスケジューリングおよび実行レイヤー１４０は、種々のレベルでジョブおよび／またはタスクを管理するコンポーネントを含むことができる。

[0093] 以上で説明したレイヤーは、複数の地理的位置にプロセッサーを含むクラウド計算環境において実現することができる。図２は、１つのクラウド計算アーキテクチャー内において異なる位置にあるプロセッサーをどのように統合することができるかについての例を模式的に示す。

[0094] 図２において、仮想マシンのプールを管理するために、１つ以上のタスク・テナント(task tenant)２１５を使用することができる。タスク・テナント２１５は、１組の仮想マシンを維持することができる。１人以上のユーザーのジョブは、１つ以上の仮想マシンのプールの一部として、タスク・テナント２１５内部にある仮想マシンにおいて実行することができる。所与の地理的領域において、１つ以上のタスク・テナント２１５を使用することができる。タスク・テナント２１５の責務は、１組の仮想マシンを維持し、当該タスク・テナント内部におけるリソース利用度に基づいてタスク・テナントを動的に拡大または縮小させることを含むことができる。これによって、タスク・テナント２１５は、顧客の要求増大に応えるためにタスク・テナント内部の仮想マシンの数を増大することができる。また、これによって、タスク・テナント２１５は、データー・センターにおいてホストされ他の顧客のためにサービスを扱う他のサービスに仮想マシンを割り当てることができるように、使用されていない仮想マシンを解放することができる。タスク・テナント２１５の他の責務は、プール割り当て／割り当て解除／管理ロジックの一部を実現することとすることができる。これによって、タスク・テナント２１５は、顧客のためにタスクに関連するプールにどのように仮想マシンを割り当てるか決定するときに関与することができる。また、タスク・テナント２１５は、当該タスク・テナント内部の仮想マシンにおけるタスクのスケジューリングおよび実行も責務とすることができる。

[0095] 図２に示す実施形態では、複数のタスク・テナント２１５を制御する１つ以上のタスク位置情報サービス(task location service)２２５が設けられる。複数のタスク・テナントが、所与の地理的領域における全てのタスク・テナント、世界中からの種々のタスク・テナント、または任意の他の便利なタスク・テナントの集合体に対応することができる。図２において、タスク位置情報サービス２２５は、「ＵＳ北」および「ＵＳ南」と称する領域にサーブすることが示される。タスク位置情報サービス２２５の責務は、所与の地理的領域に対するタスク・アカウントの管理を含むことができる。また、タスク位置情報サービス２２５は、ユーザーにクラウド計算環境と相互作用させるためにアプリケーション・プログラミング・インターフェース（ＡＰＩ）を提供することもできる。このようなＡＰＩは、所与の地理的領域内におけるタスク・テナントにわたって、仮想マシンのプールに関連するＡＰＩを扱うこと、プール管理ロジック、プール管理ロジックの調整を含むことができる。また、ＡＰＩは、ユーザーによって提出されたタスクを扱うためのＡＰＩ、ならびにユーザーのタスクに関連する作業項目またはジョブを維持する、スケジューリングする、および終了するためのＡＰＩも含むことができる。更に、ＡＰＩは、地理的領域における全ての作業項目、ジョブ、タスク、およびプールに対する統計の収集、集計、および報告のためのＡＰＩも含むことができる。加えて、ＡＰＩは、仮想マシンのスポット・マーケットに基づいて短期のユーザーに対するプリエンプティブルな仮想マシン(preemptible virtual machines)として、利用可能な仮想マシンのオークションを可能にするＡＰＩも含むことができる。また、ＡＰＩは使用量を計測し課金サポートを提供するＡＰＩも含むことができる。

[0096] タスク位置情報サービス２２５は、グローバル突き止めサービス２３５によって互いにリンクすることができる。グローバル突き止めサービス２３５は、タスク位置情報サービス・テナント２２５と共にタスク・アカウントを管理することを含む、アカウント作成およびアカウントの管理を責務とすることができる。これは、災害復旧を責務とすること、およびデーター・センターに甚大な災害があった場合に、作業項目およびジョブを利用可能にすることを責務とすることを含む。これは、データー・センターが何らかの理由で利用できないために、異なる位置で作業項目またはジョブを実行することを含むのでもよい。また、これは、顧客に彼らの作業項目、ジョブ、およびプールを１つのデーター・センターから他のデーター・センターに移転させることも含むことができる。通例、アクティブなグローバル突き止めサービス２３５は１つだけである。このアクティブなグローバル突き止めサービス２３５は、種々のタスク位置情報サービス２２５、およびデーター格納を管理するサービス・コンポーネント（図示せず）と通信することができる。グローバル突き止めサービスは、グローバル・アカウント名称空間２３７を維持することができる。

[0097] 図３は、タスク位置情報サービスに可能な構成を示す。図３に示す構成では、タスク位置情報サービスは、１つ以上のアカウント・サーバー３２１を含むことができる。アカウント・サーバーは、所与の地理的領域におけるアカウントのためにアカウント管理を扱い、作成、削除、またはプロパティ更新を含む。アカウント・フロント・エンド３２２は、アカウント・サービスに対するフロント・エンド・ノードとしてサーブする。アカウント・フロント・エンド３２２は、図に示すように、アカウント仮想ＩＰアドレス３２４の背後にある。アカウント・フロント・エンド３２２は、アカウントを作るまたはアカウントを削除するＡＰＩ要求というような、グローバル突き止めサービスから来るアカウントＡＰＩ要求を処理する。

[0098] また、図３の構成は、１つ以上のプール・サーバー３３１も含む。プール・サーバー３３１は、所与の地理的領域における仮想マシンのプールのために、プール管理およびプール・トランザクションを扱う。プール・サーバー３３１は、プールの作成、削除、およびプロパティ更新を扱う。また、プール・サーバー３３１は、複数のタスク・テナントに跨がる上位仮想マシン割り当てアルゴリズムを管理する。仮想マシン割り当ては、所与のユーザーに対する仮想マシンのストレージとの接続性(connectivity)を考慮することができる。また、プール・サーバーは、仮想マシンの割り当てに関係する他のタスクを実行することもできる。

[0099] また、図３における構成は、１つ以上の作業項目またはジョブ・サーバー（ＷＩＪ）３３６も含む。ＷＩＪサーバー３３６は、作業項目およびジョブの作成、削除、および更新を扱う。加えて、作業項目またはジョブが開始または終了するときにユーザーがプールの自動作成および／または破壊を要求した場合、ＷＩＪサーバー３３６は、作業項目またはジョブに関連するプールの作成および削除を開始することができる。また、ＷＩＪサーバー３３６は、スケーリングのために包括パーティショニング・メカニズムも使用する。一実施形態では、各タスク位置情報サービス内に複数のＷＩＪサーバー３３６があり、ＷＩＪサーバーの各々は作業項目の範囲を扱う。

[00100] プール・サーバー３３１およびＷＩＪサーバー３３６は、ユーザーから、タスク位置情報サービス・フロント・エンド３３８を介して要求を受ける。タスク位置情報サービス・フロント・エンド３３８は、ユーザーからの要求を処理するために対応するコンポーネントをコールすることも責務とする。タスク位置情報サービス・フロント・エンド３３８は、図に示すように、アカウント仮想ＩＰアドレス３３４の背後にある。

[00101] 図３における構成は、更に、タスク位置情報サービス・マスター(task location service master)３４２も含む。一実施形態では、タスク位置情報サービス・マスター３４２は、２つの主要な責務を有する。第１に、タスク位置情報サービス・マスター３４２は、タスク位置情報サービス２２５において対応するサーバーのためにパーティショニング・ロジックを実装するためのマスター・システムとして役割を果たす。加えて、タスク位置情報サービス・マスター３４２は、タスク位置情報サービスの地理的領域全体に対する各スポット期間の開始時にプリエンプティブルな仮想マシンについて新たな市場価格を計算することも責務とすることができる。これは、現在の入札およびリソース可用性情報をプール・サーバーおよびタスク・テナントから収集することができ、それに応じて新たな市場価格を計算する。あるいは、タスク位置情報サービス・マスターは、入札およびリソース可用性情報をスポット価格市場サービスに送ることができる。また、これは、地理的領域における全てのタスク・テナントにわたってプリエンプティブルな仮想マシンについての上位割り当て指針をプール・サーバーに作る。

[00102] 計算環境のアクティビティおよび挙動を追跡するために、タスク位置情報サービス・マスター３４２は、１つ以上の統計集計サーバー３５５と通信することができる。統計集計サーバーは、タスク、ジョブ、作業項目、およびプールについての詳細統計を収集し集計することを責務とする。システムにおける他のコンポーネントは、タスクおよび仮想マシンについてのきめ細かい統計(fine-grained statistics)を送る(emit)。統計集計サーバーは、これらのきめ細かい統計を、タスク・レベルまたは仮想マシン・レベル統計から、作業項目、アカウント・レベル、および／またはプール・レベルの統計に集計する。この統計は、ＡＰＩを介して使用のために露出することができる。加えて、統計集計サーバーは、課金に使用するために、アカウント毎に１時間毎の計測記録を生成することも責務とする。

[00103] 更に具体的な例として、包括パーティショニングを、図３に示すタスク位置情報サービスにおけるロールおよびサブロールに適用することができる。図３において説明する最上位ロールは、タスク位置情報サービスまたはテナントである。タスク位置情報サービスの複数のインスタンスが存在する場合、これらのインスタンスの１つが、タスク位置情報サービス・マスター（即ちディクテーター）３４２に対応する。このテナントの内部には、アカウント・サーバー・ロール３２１、プール・サーバー・ロール３３１、および作業項目−ジョブ・サーバー・ロール３３６がある。これらのロールの各々も、タスク位置情報サービスのインスタンスを表すが、これらのロール・インスタンスは、テナント全体内部で１組の機能を扱う。例えば、アカウント情報の要求は、テナント内部のアカウント・サーバー・ロールによって扱われる。タスク位置情報サービスまたはテナントの複数のインスタンスが存在する場合、テナント内部のロール毎のマスターが、異なるインスタンスに対応することができる。

[00104] 図６は、複数のマスター・ロールに対してどのように冗長性を提供できるかについての従来例を示す。この従来例では、各マスター・ロールが、可用性を改善するために、２つの追加のインスタンスを有する必要がある。フォールト・ドメイン(fault domain)は、共通の障害パターンを有するノードを含み、これらは一緒に故障する可能性がある。例えば、同じ電源を共有する同じラックにあるノードは、共通の問題の結果故障するかもしれないので、共通のフォールト・ドメインにある。アップグレード・ドメインは、システム・アップグレードの間同時にオフラインに移すことができる１組のノードに対応する。これらのノードは、アップグレードまたは故障の結果共通する時点に停止しないように、図６に示すように、異なる「フォールト・ドメイン」および「アップグレード・ドメイン」に跨がって広がる。

[00105] 従来の方法の下では、タスク位置情報サービス内部における３つのロールに必要な追加のインスタンスを供給するには、ロール毎に別の追加のインスタンスを有することが必要になる。図６において、これは、マスターのタイプ毎に追加のインスタンスを供給する明示的なマシン(explicit machine)を有することによって示される。つまり、アカウント・サーバーのマスター６２１は、追加のインスタンス６２２および６２３を必要とする。同様に、プール・サーバーのマスター６３２はバックアップ・インスタンス６３１および６３３を有する。ＷＩＪサーバーのマスター６４３は、バックアップ・インスタンス６４２および６４１を有する。

[00106] 図８は、包括パーティショニングを使用する分散型計算環境において、ロールのために種々のインスタンスおよびマスターを提供するためには、仮想マシンをどのように編成することができるかについての例を示す。図８において、別のＧＰマスター８２１、８３１、および８４１は、それぞれ、アカウント・サーバー、プール・サーバー、およびＷＩＪサーバーについて示される。ＧＰマスター・モジュールおよび任意の固定インターフェースは、管理されるロールに関係なく同じであるので、バックアップ・サーバーがＧＰマスター８２１、８３１、および８４１に必要であり、１つのマシンにおいて組み合わせることができる。つまり、１つのバックアップ８５２を、３つのＧＰマスターのためのバックアップとして提供することができる。ＧＰマスター８２１、８３１、または８４１の内１つに障害が起きた場合、同じＧＰマスター・モジュールおよび固定インターフェースを使用することができる。この例では、障害が起きたＧＰマスター・ロールを引き継ぐためにフェイルオーバー・バックアップによって必要とされる唯一の追加の情報タイプは、対応する名称空間および任意のアプリケーション定義インターフェースに対するキーである。同様に、１つの第２バックアップ８５３は、３つのＧＰマスター８２１、８３１、および８４１の全てに使用することができる。したがって、この例では、少なくとも３つのＧＰマスター・ロールに対して、２つのＧＰマスター・バックアップ・サーバー（８５２および８５３）だけが使用される。３つのＧＰマスター・ロールは、共通のマシンによってバックアップされるように示されるが、共通のマシンを用いて、同じユーザーまたはアカウントに属する任意の便利な数のＧＰマスターをバックアップすることができる。

[00107] 図１１は、本発明の形態にしたがって、フォールト・ドメインおよびアップグレード・ドメインに関するマスター・ロールにバックアップ・マシンを提供する形態例を示す。図８に関して先に説明した概念と同様、複数のＧＰマスター・ロールを少数のサーバーにおいてバックアップすることができる。例えば、図１１は、第１フォールト・ドメインおよび第１アップグレード・ドメインにおいてアカウントＧＰマスター１２０２を示し、第２フォールト・ドメインおよび第２アップグレード・ドメインにおいてプールＧＰマスター１２０４を示し、第３フォールト・ドメインおよび第３アップグレード・ドメインにおいてＷＩＨ ＧＰマスター１２１０、ならびに第１ＧＰバックアップ１２０６および第２ＧＰバックアップ１２０８を示す。第１ＧＰバックアップ１２０６および第２ＧＰバックアップ１２０８は、各々、ＧＰマスター・ロールとは異なるフォールト・ドメインおよびアップグレード・ドメインにある。この代表例では、１つの包括パーティショニング・システムが、この例では、３つのロールのためにマスターの全てをホストするために５つのサーバー（または４つのサーバーと１つのバックアップも可能である）しか必要としない。図６に示した例では、これら同じ３つのマスター・ロールのために、９つの異なるサーバーが必要な場合もある。図８に示す手法は、システムによってホストされる任意のタイプのロールに使用することができる２つの追加のサーバーの利用によって遂行することができる。したがって、バックアップ・サーバー（例えば、ＧＰバックアップ１２０６）は、フォールト・ドメイン(fault domain)の障害(failure)または利用できないアップグレード・ドメインのためにマスター・ロールの内１つ以上が利用できない場合に、使用することができる。この例では必要とされるサーバーの数は少なくてよいが（図６に関して説明したものと比較して）、バックアップ・サーバーの可用性を確保するために追加のフォールト・ドメインおよびアップグレード・ドメインを実装するとよいことが考えられる。先に説明した図８と同様、形態例では、任意の数のマスター・ロールが共通マシンによってバックアップされてもよいことが考えられる。

[00108] 以上、本発明の種々の実施形態の全体像について説明したので、これより本発明を実行するのに適した動作環境例について説明する。図面全体を参照し、最初に特に図７を参照すると、本発明の実施形態を実現するための動作環境例が示され、全体的に計算デバイス７００と示されている。計算デバイス７００は、適した計算環境の一例に過ぎず、本発明の使用範囲や機能に関して何ら限定を示唆する意図はない。また、計算デバイス７００が、図示されるコンポーネントのいずれか１つに関しても、またはその組み合わせに関しても、何らかの依存性または要件を有するというように解釈してはならない。

[00109] 本発明の実施形態の種々の形態は、コンピューター・コードまたは機械使用可能命令という一般的なコンテキストで説明することができ、コンピューター、あるいはパーソナル・データー・アシスタントまたは他のハンド・ヘルド・デバイスというような他のマシンによって実行されるプログラム・モジュールのような、コンピューター実行可能命令を含む。一般に、プログラム・モジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データー構造等を含み、特定のタスクを実行するコード、または特定の抽象データー型を実装するコードを指す。本発明は、ハンド・ヘルド・デバイス、消費者用電子機器、汎用コンピューター、更に特殊な計算デバイス等を含む、種々のシステム構成で実施することができる。また、本発明は、分散型計算環境において実施することもでき、この場合、タスクは、通信ネットワークを通じてリンクされるリモート処理デバイスによって実行される。

[00110] 図７を参照すると、計算デバイス７００は、以下のデバイスを直接または間接的に結合するバス７１０を含む。メモリー７１２、１つ以上のプロセッサー７１４、１つ以上のプレゼンテーション・コンポーネント７１６、入力／出力（Ｉ／Ｏ）ポート７１８、Ｉ／Ｏコンポーネント７２０、および例示の電源７２２。バス７１０は、１つ以上のバス（アドレス・バス、データー・バス、またはその組み合わせ）であってもよいものを代表する。図７の種々のブロックは、明確さのために線で示されるが、実際には、種々のコンポーネントの境界分けはそれ程明確ではなく、例えて言えば、線は、更に正確にするならば、灰色および曖昧になるであろう。例えば、ディスプレイ・デバイスのようなプレゼンテーション・コンポーネントをＩ／Ｏコンポーネントであると見なす者もいると考えられる。また、多くのプロセッサーはメモリーを有する。本発明者は、このようなことは技術の本質であると認識しており、図７の図は、本発明の１つ以上の実施形態と共に使用することができる計算デバイス例を例示するに過ぎないことを繰り返しておく。「ワークステーション」、「サーバー」、「ラップトップ」、「ハンド・ヘルド・デバイス」等の間に区別は行わない。何故なら、これらは全て図７に範囲に入ると考えられ、「計算デバイス」を指すからである。

[00111] 計算デバイス７００は、通例、種々のコンピューター読み取り可能媒体を含む。コンピューター読み取り可能媒体は、計算デバイス７００によってアクセスすることができるいずれの入手可能な媒体とすることもでき、揮発性および不揮発性、ならびにリムーバブルおよび非リムーバブル媒体の双方を含む。一例として、そして限定ではなく、コンピューター読み取り可能媒体は、コンピューター記憶媒体および通信媒体を含むことができる。コンピューター記憶媒体は、揮発性および不揮発性、リムーバブルおよび非リムーバブル媒体を含み、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターというような情報の格納のための任意の方法または技術で実現される。コンピューター記憶媒体は、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリー・メモリー（ＲＯＭ）、電子的消去可能プログラマブル・リード・オンリー・メモリー（ＥＥＰＲＯＭ）、フラッシュ・メモリーまたは他のメモリー技術、ＣＤ−ＲＯＭ、ディジタル・バーサタイル・ディスク（ＤＶＤ）または他の光ディスク・ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたは他の磁気記憶デバイス、または所望の情報を格納するために使用することができそして計算デバイス７００によってアクセスすることができる他のあらゆる媒体を含むが、これらに限定されるのではない。一実施形態では、コンピューター記憶媒体は、有形コンピューター記憶媒体から選択することができる。他の実施形態では、コンピューター記憶媒体は、非一時的コンピューター記憶媒体から選択することができる。

[00112] 通信媒体は、通例、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、または他のデーターを、搬送波のような変調データー信号または他の伝達メカニズムに具体化し、あらゆる情報配信媒体を含む。「変調データー信号」という用語は、その信号内に情報をエンコードするようなやり方で、その特性の１つ以上が設定または変更された信号を意味する。一例として、そして限定ではなく、通信媒体は、有線ネットワークまたは直接有線接続というような有線媒体と、音響、ＲＦ、赤外線、および他のワイヤレス媒体というようなワイヤレス媒体とを含む。以上のいずれの組み合わせも、コンピューター読み取り可能媒体の範囲に含まれてしかるべきである。

[00113] メモリー７１２は、揮発性および／または不揮発性メモリーの形態としたコンピューター記憶媒体を含むことができる。このメモリーは、リムーバブル、非リムーバブル、またはその組み合わせであってもよい。ハードウェア・デバイスの例には、ソリッド・ステート・メモリー、ハード・ドライブ、光ディスク・ドライブ等が含まれる。計算デバイス７００は、メモリー７１２またはＩ／Ｏコンポーネント７２０のような種々のエンティティからデーターを読み取る１つ以上のプロセッサーを含む。プレゼンテーション・コンポーネント（１つまたは複数）７１６は、データー指示をユーザーまたは他のデバイスに提示する。プレゼンテーション・コンポーネントの例には、ディスプレイ・デバイス、スピーカー、印刷コンポーネント、振動コンポーネント等が含まれる。

[00114] Ｉ／Ｏポート７１８は、 計算デバイス１００を、Ｉ／Ｏコンポーネント７２０を含む他のデバイスに論理的に結合することを可能にする。Ｉ／Ｏコンポーネント１２０の一部は内蔵されていてもよい。コンポーネントの例には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー、プリンター、ワイヤレス・デバイス等が含まれる。

[00115] 図９は、本発明による方法の一例を示す。図９において、１つ以上のアプリケーション定義パーティショニング・システム・インターフェースをアプリケーションまたはユーザーから受け取る（９１０）。例えば、アプリケーションまたはユーザーからの要求に基づいて、受け取られたアプリケーション定義パーティショニング・システム・インターフェースを含む複数のマスター・ロール・インターフェースを作る（９２０）。これら複数のマスター・ロール・インスタンスは、マスター記憶オブジェクトに対応する。マスター記憶オブジェクト９３０のリースをマスター・ロール・インターフェースの内１つに割り当てる。複数のマスター・ロール・インターフェースは、リースの割り当てを求めて競合する。リースが割り当てられたマスター・ロール・インスタンスは、ディクテーター・マスター・ロール・インターフェースになる。ディクテーター・マスター・ロール・インターフェースは、次いで、パーティションのグループを複数のパーティション・サーバーに割り当てる（９４０）。次いで、複数のパーティション・サーバーを使用して、アプリケーションに対応するジョブを実行する（９５０）。

[00116] 図１０は、本発明による方法の他の例を示す。図１０において、計算の要求を受ける（１０１０）。この計算要求は、複数の名称空間と、互いに異なる２つのマスター・ロール・インスタンスとを含む。少なくとも２つのマスター・ロール・インスタンスを作る（１０２０）。複数の作られたマスター・ロール・インスタンスにフェールオーバー・サービスを提供する少なくとも１つのマシンを割り当てる（１０３０）。フェールオーバー・サービスは、計画外フェイルオーバー、スケジューリングされた更新、計画された維持イベントというような、マスター・ロール・インスタンスが動作を停止する任意の都合がよい理由、または他の理由に対応することができる。作られたマスター・ロール・インスタンスの内１つに対するフェールオーバー・イベントを検出する（１０４０）。割り当てられたマシンにおいて、このフェールオーバー・イベントに対応するマスター・ロールの追加のインスタンスを作る（１０５０）。

[00117] 以上、特定の実施形態に関係付けて、本発明の実施形態について説明したが、これらは、あらゆる観点において限定的ではなく例示的であることを意図している。本発明の範囲から逸脱することなく、本発明に関連する技術の当業者には、代替実施形態も明白であろう。

[00118] 一実施形態では、分散型計算環境において計算を実行する方法を提供する。この方法は、１つ以上のアプリケーション定義パーティショニング・システム・インターフェースを受けるステップと、１つ以上のアプリケーション定義パーティショニング・システム・インターフェースを含む複数のマスター・ロール・インスタンスを作るステップであって、マスター・ロール・インスタンスがマスター記憶オブジェクトに対応する、ステップと、マスター記憶オブジェクトにリースを割り当てるステップであって、各マスター・ロール・インスタンスがリースを求めて競合し、リースが割り当てられるマスター・ロール・インスタンスが、ディクテーター・マスター・ロール・インスタンスになる、ステップと、ディクテーター・マスター・ロール・インスタンスによって、パーティションのグループを複数のパーティション・サーバーに割り当てるステップと、複数のパーティション・サーバーを使用して、アプリケーションに対応する１つ以上のジョブを実行するステップとを含む。

[00119] 他の実施形態では、分散型計算環境において計算を実行する方法を提供する。この方法は、複数の名称空間と少なくとも２つのマスター・ロール・インスタンスとを含む計算要求を受けるステップと、少なくとも２つのマスター・ロール・インスタンスを作るステップと、複数の作られたマスター・ロール・インスタンスにフェールオーバー・サービスを提供する少なくとも１つのマシンを割り当てるステップと、作られたマスター・ロール・インスタンスの１つに対するフェールオーバー・イベントを検出するステップと、割り当てられたマシンにおいて、検出されたフェールオーバー・イベントに対応マスター・ロールの追加のインスタンスを作るステップとを含む。

[00120] 更に他の実施形態では、分散型計算環境において計算タスクを実行するシステムを提供する。このシステムは、コンピューター使用可能命令を実行する複数のプロセッサーを含み、命令が実行されると、複数のパーティション・サーバーであって、パーティション・サーバーが、パーティション・サーバーに関連する記憶オブジェクトを管理するために少なくとも１つのパーティショニング・システム・インターフェースと、１つ以上のアプリケーション定義パーティショニング・システム・インターフェースとを有し、パーティション・サーバーが、割り当てられたパーティションに関する情報を格納するために、関連する記憶オブジェクトを有する、複数のパーティション・サーバーと、アプリケーション定義名称空間に基づいてパーティションを含むパーティション表であって、パーティションが、名称空間にわたるアプリケーション定義名称空間からのキー範囲に対応し、パーティション表が、パーティショニング・システムによってアクセス可能である、パーティション表と、パーティションのパーティション・サーバー仮想マシンへの割り当てを管理し、パーティションのパーティション・サーバー仮想マシンへのパーティション表割り当てを維持するために、固定パーティショニング・システム・インターフェースを含む第１マスター・ロール・インターフェースと、名称空間からキー値を含むクライアント要求を受け、キー値に対応するパーティション・サーバーのアドレスを戻すために、少なくとも１つの固定パーティショニング・システム・インターフェースを有するクライアント・コンポーネントとを含むシステムを提供する。

[00121] 以上のことから、本発明は、先に説明した目的(ends and objects)の全てを、自明であり本構造に固有である他の利点と共に、達成するのに適することが分かるであろう。

[00122] 尚、ある種の特徴およびサブコンビネーションは有益であり、他の特徴およびサブコンビネーションを参照しなくても採用できることは言うまでもない。これは、請求項の範囲によって想定されていることであり、その範囲に含まれることとする。

Claims (7)

1. 分散型計算環境において計算を実行する方法であって、
   １つ以上のアプリケーション定義パーティショニング・システム・インターフェースを受けるステップと、
   前記１つ以上のアプリケーション定義パーティショニング・システム・インターフェースを含む複数のマスター・ロール・インスタンスを作るステップであって、前記マスター・ロール・インスタンスがマスター記憶オブジェクトに対応する、ステップと、
   前記マスター記憶オブジェクトにリースを割り当てるステップであって、各マスター・ロール・インスタンスが前記リースを求めて競合し、前記リースが割り当てられるマスター・ロール・インスタンスが、ディクテーター・マスター・ロール・インスタンスになる、ステップと、
   前記ディクテーター・マスター・ロール・インスタンスによって、パーティションのグループを複数のパーティション・サーバーに割り当てるステップであって、前記パーティションのグループの前記複数のパーティション・サーバーへの割り当てがパーティション表に維持される、ステップと、
   前記複数のパーティション・サーバーを使用して、アプリケーションに対応する１つ以上の計算を実行するステップと、
   第１のパーティション・サーバーからのメッセージを、前記ディクテーター・マスター・ロール・インスタンスによって受けるステップであって、前記メッセージが、前記第１のパーティション・サーバーが現在サーブしていると報告しているパーティションを含む、ステップと、
   前記ディクテーター・マスター・ロール・インスタンスによって、対応する第１の記憶オブジェクトにおいて前記第１のパーティション・サーバーのリースを中断するステップであって、前記第１のパーティション・サーバーの前記リースの中断が、前記パーティション表内に維持された前記第１のパーティション・サーバーに割り当てられた１つ以上のパーティションと受けた前記メッセージにおける前記パーティションとの間の矛盾により示される、前記パーティション・サーバーが現在サーブすべきでない少なくとも１つのパーティションに対し前記第１のパーティション・サーバーが現在サーブしていることを、前記ディクテーター・マスター・ロール・インスタンスが検出したことに応答する、ステップと、
   を含む、方法。
2. 請求項１記載の方法であって、更に、前記ディクテーター・マスター・ロール・インスタンスによって、前記複数のパーティション・サーバーにハートビート・メッセージを送るステップを含み、前記第１のパーティション・サーバーからの前記メッセージが、前記ハートビート・メッセージに対する応答である、方法。
3. 請求項２記載の方法であって、更に、前記ディクテーター・マスター・ロール・インスタンスが前記マスター記憶オブジェクトにリースを維持している間に、前記ディクテーター・マスター・ロール・インスタンスによって、１つ以上のパーティションを、複数のパーティション・サーバーからの第２のパーティション・サーバーに割り当てるメッセージを送るステップであって、前記ディクテーター・マスター・ロール・インスタンスからの前記メッセージがエポック番号を含む、ステップと、
   前記複数のパーティション・サーバーからの前記第２のパーティション・サーバーによって、前記ディクテーター・マスター・ロール・インスタンスから受け取られたパーティション割り当てを維持するステップと、
   を含む、方法。
4. 請求項３記載の方法であって、更に、
   前記ディクテーター・マスター・ロール・インスタンスによって、割り当て識別子を前記１つ以上のパーティションの割り当てと関連付けるステップであって、前記ディクテーター・マスター・ロール・インスタンスが、前記割り当て識別子を前記メッセージと共に前記第２のパーティション・サーバーに送る、ステップと、
   前記第２のパーティション・サーバーによって、前記割り当て識別子を格納するために、対応する記憶オブジェクトのコンテンツを更新するステップと、
   前記第２のパーティション・サーバーによって、承認メッセージを前記ディクテーター・マスター・ロール・インスタンスに送るステップと、
   を含む、方法。
5. 請求項３記載の方法であって、更に、
   前記ディクテーター・マスター・ロール・インスタンスによって、割り当て識別子を前記１つ以上のパーティションの割り当てと関連付けるステップであって、前記ディクテーター・マスター・ロール・インスタンスが、前記割り当て識別子を前記メッセージと共に前記第２のパーティション・サーバーに送る、ステップと、
   前記第２のパーティション・サーバーによって、前記ディクテーター・マスター・ロール・インスタンスから前記メッセージを受けるステップであって、前記ディクテーター・マスター・ロール・インスタンスに承認メッセージを送らない、ステップと、
   前記ディクテーター・マスター・ロール・インスタンスによって、対応する記憶オブジェクトにおいて前記第２のパーティション・サーバーのリースを中断するステップと、
   前記ディクテーター・マスター・ロール・インスタンスによって、前記第２のパーティション・サーバーに対応する前記記憶オブジェクトを削除するステップと、
   前記第２のパーティション・サーバーによって、前記リースの中断を検出するステップであって、前記リース中断の検出に応答して、前記第２のパーティション・サーバーが終了する、ステップと、
   を含む、方法。
6. 請求項３記載の方法であって、更に、
   前記ディクテーター・マスター・ロール・インスタンスによって、割り当て識別子を前記１つ以上のパーティションの割り当てと関連付けるステップであって、前記ディクテーター・マスター・ロール・インスタンスが、前記割り当て識別子を前記メッセージと共に前記第２のパーティション・サーバーに送る、ステップと、
   前記第２のパーティション・サーバーによって、前記ディクテーター・マスター・ロール・インスタンスから前記メッセージを受けるステップであって、対応する記憶オブジェクトのコンテンツを更新しない、ステップと、
   前記ディクテーター・マスター・ロール・インスタンスによって、前記対応する記憶オブジェクトにおいて、前記第２のパーティション・サーバーのリースを中断するステップと、
   前記ディクテーター・マスター・ロール・インスタンスによって、前記第２のパーティション・サーバーに対応する前記記憶オブジェクトを削除するステップと、
   前記第２のパーティション・サーバーによって、前記リースの中断を検出するステップであって、前記リース中断の検出に応答して、前記第２のパーティション・サーバーが終了する、ステップと、
   を含む、方法。
7. 分散型計算環境において計算を実行するシステムであって、コンピューター使用可能命令を実行する複数のプロセッサーを含み、前記命令が実行されると、前記複数のプロセッサーに、請求項１から６のいずれかに記載の方法を実行させる、システム。

Images