JP6001690B2 - クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法 - Google Patents

クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法 Download PDF

Info

Publication number
JP6001690B2
JP6001690B2 JP2015000221A JP2015000221A JP6001690B2 JP 6001690 B2 JP6001690 B2 JP 6001690B2 JP 2015000221 A JP2015000221 A JP 2015000221A JP 2015000221 A JP2015000221 A JP 2015000221A JP 6001690 B2 JP6001690 B2 JP 6001690B2
Authority
JP
Japan
Prior art keywords
feature model
job
resource feature
processor
slave device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2015000221A
Other languages
English (en)
Other versions
JP2016048536A (ja
Inventor
葉奇典
陳星宇
李育杰
鮑興國
Original Assignee
財團法人資訊工業策進會
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 財團法人資訊工業策進會 filed Critical 財團法人資訊工業策進會
Publication of JP2016048536A publication Critical patent/JP2016048536A/ja
Application granted granted Critical
Publication of JP6001690B2 publication Critical patent/JP6001690B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14Handling requests for interconnection or transfer
    • G06F13/36Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)
  • Multi Processors (AREA)
  • Automatic Analysis And Handling Materials Therefor (AREA)

Description

本発明は、マスタデバイス、スレーブデバイスおよびそのコンピューティング方法に関する。さらに詳細には、本発明は、クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法に関する。
ビッグデータの計算には、クラスタコンピューティング技術が効果的な手段である。一般に、クラスタコンピューティングとは、複数のコンピューティングユニットがクラスタ化されてこれらのコンピューティングユニットの協働を通して1つのジョブを達成することを意味する。
動作時には、クラスタコンピューティングシステムは通常、マスタデバイスおよび複数のスレーブデバイスを備えている。マスタデバイスは、スレーブデバイスにジョブを割り当てるように構成されている。各々のスレーブデバイスは、ジョブに対応して割り当てられたタスクを実行するためのコンテナを生成するように構成されている。したがって、無駄を避けるためには、クラスタコンピューティングシステムでリソースを的確に割り当ててビッグデータを計算しなければならない。
一般的には、従来のクラスタコンピューティングシステムは、以下の問題が原因でリソースを効果的に割り当てられないことがある。第一に、従来のスレーブデバイスによって生成されたコンテナはすべて、仕様(中央処理装置(CPU)仕様およびメモリ仕様など)が一定であるため、リソースの無駄が様々なジョブの様々な特性によって引き起こされる。例えば、ジョブの計算需要がコンテナの仕様よりも少ない場合、コンテナが完全に使用されていないためにリソースの無駄が起こることがある。
このほか、コンテナ仕様は各々のコンテナに対して一定であるため、従来のスレーブデバイスで生成できるコンテナ数も一定であり、それによってリソースはアイドル状態になる。例えば、1つのジョブに必要なコンテナ数が合計コンテナ数よりも少ない場合、リソースがアイドル状態であることでコンテナ数が過剰になる。また、コンテナ仕様は各々のコンテナに対して一定であるため、複数のスレーブデバイスが異なるデバイス性能を有する場合は、リソースの不適切な割り当てが起こる傾向がある。例えば、2つのスレーブデバイスのコンテナ仕様が同じであってもデバイス性能が異なる場合、2つのスレーブデバイスの処理効率が異なるために、リソースの不適切な割り当てが起こる。
したがって、先行技術による従来のクラスタコンピューティングシステムに対する効果的なリソース割り当て技術を提供することが重要である。
本発明の目的は、従来のクラスタコンピューティングシステムに対して効果的なリソース割り当て技術を提供することを含む。
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム用のマスタデバイスを備える。マスタデバイスは、接続インターフェースおよびプロセッサを備えている。接続インターフェースは、少なくとも1つのスレーブデバイスと接続するように構成されている。プロセッサは、接続インターフェースに電気接続されていて、スレーブデバイスからデバイス情報を受信し、デバイス情報およびジョブに応じてスレーブデバイスに対するリソースフィーチャーモデルを選択し、リソースフィーチャーモデルに応じてスレーブデバイスのコンテナ構成パラメータを推定し、コンテナ構成パラメータをスレーブデバイスへ伝送し、スレーブデバイスにジョブを割り当てるように構成されている。
プロセッサはさらに、複数のリソースフィーチャーモデルのサンプルを複数のグループに分類し、リソースフィーチャーモデルのサンプルを各々の前記グループからリソースフィーチャーモデルの代表として選択し、前記スレーブデバイスに対するリソースフィーチャーモデルを前記リソースフィーチャーモデルの代表から選択する。
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム用のスレーブデバイスを備える。スレーブデバイスは、接続インターフェースおよびプロセッサを備える。接続インターフェースは、マスタデバイスと接続するように構成されている。プロセッサは、接続インターフェースに電気接続されていて、デバイス情報をマスタデバイスに伝送し、マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータをマスタデバイスから受信し、コンテナ構成パラメータに応じてジョブを計算するために少なくとも1つのコンテナを生成し、ジョブに対応するジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成するように構成されている。
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム内にあるマスタデバイスに対するコンピューティング方法を備える。マスタデバイスは、接続インターフェースおよびプロセッサを備えている。接続インターフェースは、少なくとも1つのスレーブデバイスと接続するように構成されている。コンピューティング方法は、
(A)スレーブデバイスのデバイス情報をプロセッサで受信するステップと、
(B)スレーブデバイスに対するリソースフィーチャーモデルを、デバイス情報およびジョブに応じてプロセッサによって選択するステップと、
(C)スレーブデバイスのコンテナ構成パラメータを、リソースフィーチャーモデルに応じてプロセッサによって推定するステップと、
(D)プロセッサによってコンテナ構成パラメータをスレーブデバイスに伝送するステップと、
(E)プロセッサによってスレーブデバイスにジョブを割り当てるステップと
を含む。
ステップ(B)は、複数のリソースフィーチャーモデルのサンプルをプロセッサによって複数のグループに分類することと、プロセッサによって、リソースフィーチャーモデルのサンプルを各々のグループからリソースフィーチャーモデルの代表として選択することと、スレーブデバイスに対するリソースフィーチャーモデルを、プロセッサによってデバイス情報および前記ジョブに応じて、リソースフィーチャーモデルの代表から選択することとを含む。
前述の目的を達成するため、本発明の特定の実施形態は、クラスタコンピューティングシステム内にあるスレーブデバイスに対するコンピューティング方法を備える。スレーブデバイスは、接続インターフェースおよびプロセッサを備える。接続インターフェースは、マスタデバイスと接続するように構成されている。コンピューティング方法は、
(A)プロセッサによってデバイス情報をマスタデバイスに伝送するステップと、
(B)マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータを、プロセッサによってマスタデバイスから受信するステップと、
(C)プロセッサによってコンテナ構成パラメータに応じてジョブを計算するために、少なくとも1つのコンテナを生成するステップと、
(D)ジョブに対応するジョブ情報およびメトリックファイルに応じて、プロセッサによってリソースフィーチャーモデルを作成するステップと
を含む。
上記の説明によれば、本発明は、特定の実施形態では、クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法を提供する。マスタデバイスが、各々のスレーブデバイスによって伝送されたデバイス情報を受信し、デバイス情報およびジョブに応じて各々のスレーブデバイスに対するリソースフィーチャーモデルを選択し、各々のリソースフィーチャーモデルに応じて、対応するスレーブデバイスのコンテナ構成パラメータを推定し、各々のコンテナ構成パラメータを対応するスレーブデバイスに伝送し、スレーブデバイスにジョブを割り当てる。スレーブデバイスが、スレーブデバイスのデバイス情報をマスタデバイスに伝送し、マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータをマスタデバイスから受信し、コンテナ構成パラメータに応じてジョブを計算するために少なくとも1つのコンテナを生成し、ジョブに対応するジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成する。
したがって、本発明のスレーブデバイスによって生成されたコンテナの仕様は、動的に調整でき、よって様々なジョブの様々な特性が原因であるリソースの無駄がなくなる。さらに、コンテナ仕様は本発明の各々のコンテナに対して一定ではないため、本発明のスレーブデバイスのコンテナ数も動的に調整でき、よってリソースのアイドル状態がなくなる。このほか、本発明のスレーブデバイスによって生成されたコンテナ仕様およびコンテナ数を動的に調整できるため、複数のスレーブデバイスが様々なデバイス性能を有する場合であっても、リソースの不適切な割り当てが起こらない。
特許請求する本発明の特徴を当業者に確実に理解してもらうために、主たる発明に対して実装した詳細な技術および好適な実施形態について、付属の図面を添付して以下の段落に記載する。
図面の簡単な説明を以下に示すが、これは本発明を限定することを意図するものではない。
本発明の一実施形態によるクラスタコンピューティングシステムの概略構造図である。 図1に示したクラスタコンピューティングシステム内にあるマスタデバイスおよび単一のスレーブデバイスの動作を示す概略図である。 図2に示したマスタデバイス内にある最適なリソースモジュールの動作を示す概略図である。 図2に示したマスタデバイス内にあるモデル管理部の動作を示す概略図である。 図2に示したスレーブデバイス内にあるモデル生成部の動作を示す概略図である。 図2に示したスレーブデバイス内にあるジョブステータス収集部の動作を示す概略図である。 本発明の一実施形態によるクラスタコンピューティングシステム内にあるマスタデバイスおよびスレーブデバイスに対するコンピューティング方法を示す概略図である。
本発明について、本発明の例示的な実施形態を参照して説明していく。しかしながら、以下の例示的な実施形態は、本発明を任意の特定の例、実施形態、環境、用途、構造、プロセスフロー、またはこれらの実施形態に記載のステップに限定することを意図するものではない。換言すれば、以下の例示的な実施形態の説明は、本発明を限定するのではなく本発明を説明することのみを目的とするものである。
図面では、本発明に直接関係のない素子はすべて描写から省略されている。また、個々の素子どうしの寸法上の関係は、理解しやすいように示しているだけであって、実際の規模を限定するものではない。
本発明の一実施形態(簡潔に「第1の実施形態」と呼ぶ)は、クラスタコンピューティングシステムである。図1は、クラスタコンピューティングシステムの概略構造図である。
図1に示したように、クラスタコンピューティングシステム1は、マスタデバイス11および少なくとも1つのスレーブデバイス13(すなわち1つまたは複数のスレーブデバイス)を備えていてよい。マスタデバイスは、接続インターフェース111およびプロセッサ113を備えていてよく、両者は互いに直接または間接的に電気接続されて互いに通信してよい。各々のスレーブデバイス13は、接続インターフェース131およびプロセッサ133を備えていてよく、両者は互いに直接または間接的に電気接続されて互いに通信してよい。
マスタデバイス11の接続インターフェース111は、多様な媒体(図示せず)を介して各々のスレーブデバイス13の接続インターフェース111に接続されてこれと通信してよい。マスタデバイス11の接続インターフェース111は、様々な媒体(例えばネットワーク、バスなど)に応じて多様な有線または無線の方式で、各々のスレーブデバイス13の接続インターフェース111に接続してこれと通信してよい。各々のマスタデバイス11およびスレーブデバイス13は、スタンドアローンのコンピュータであってもよいし、コンピュータ内にあるスタンドアローンのコンピューティングユニットであってもよい。
クラスタコンピューティングシステム1は、任意選択として、分散ファイルシステム15を備えていてよい。分散ファイルシステム15は、複数のスレーブデバイス13で形成されるファイルシステムであり、それぞれのスレーブデバイスがリソースの一部(例えば記憶スペース)を提供する。
分散ファイルシステム15は、マスタデバイス11とスレーブデバイス13とに共有される。具体的には、マスタデバイス11の接続インターフェース111とスレーブデバイス13の接続インターフェース131との間の接続を通して、マスタデバイス11および各々のスレーブデバイス13は、分散ファイルシステム15内のデータにアクセスできる。換言すれば、マスタデバイス11および各々のスレーブデバイス13は、分散ファイルシステム15の中にデータを記憶できるほか、分散ファイルシステム15からデータを読み出すこともできる。任意選択として、マスタデバイス11は、他のインターフェースを介して、または他の方法で、分散ファイルシステム15内のデータに直接アクセスしてもよい。
図1に示すように、クラスタコンピューティングシステム1がジョブ21(例えばアルゴリズム)を計算するようになっている場合、マスタデバイス11はスレーブデバイス13に、スレーブデバイスのデバイス情報22をマスタデバイス11に伝送するよう要求してよい。このようにする代わりにスレーブデバイス13は、スレーブデバイスのデバイス情報22をマスタデバイス11に定期的に伝送してもよい。さらに詳細には、各々のスレーブデバイス13は、スレーブデバイスのデバイス情報22をスレーブデバイスの接続インターフェース131を介してマスタデバイス11に伝送できる。
マスタデバイス11は、各々のスレーブデバイス13によって伝送されたデバイス情報22を、マスタデバイスの接続インターフェース111を介して受信できる。したがって、クラスタコンピューティングシステム1がジョブ21を計算するようになっている場合、マスタデバイス11のプロセッサ113は、全スレーブデバイス13によって事前に伝送されたデバイス情報22を取得してよい。ジョブ21は、マスタデバイス11自体によって生成されてもよいし、マスタデバイスの外部の他のデバイスによって入力されてもよい。スレーブデバイス13のデバイス情報22は、ハードウェア、ソフトウェア、およびこれらの計算能力に関する情報を含んでいてよい。
全スレーブデバイス13によって伝送されたデバイス情報22を取得した後、マスタデバイス11のプロセッサ113は、デバイス情報22およびジョブ21に応じて対応する各々のスレーブデバイス13に対して、リソースフィーチャーモデル23を選択してよい。各々のリソースフィーチャーモデル23は、必要に応じて、中央処理装置(CPU)フィーチャーモデル、メモリフィーチャーモデル、ネットワークフィーチャーモデル、ディスク入出力(ディスクIO)フィーチャーモデルなどであってこれに限定されない任意の多様なフィーチャーモデルを備えていてよい。
CPUフィーチャーモデルは、コンテナを計算するジョブに必要なCPU仕様を推定するために使用されてよい。メモリフィーチャーモデルは、コンテナを計算するジョブに必要なメモリ仕様を推定するために使用されてよい。ネットワークフィーチャーモデルは、コンテナを計算するジョブに必要なネットワーク仕様を推定するために使用されてよい。ディスクIOフィーチャーモデルは、コンテナを計算するジョブにディスクIO仕様を推定するために使用されてよい。
クラスタコンピューティングシステム1が分散ファイルシステム15を備えている場合、マスタデバイス11のプロセッサ113は、各々のスレーブデバイス13に対して分散ファイルシステム15からリソースフィーチャーモデル23を選択できる。例えば、分散ファイルシステム15は、事前に複数のリソースフィーチャーモデルのサンプルを記憶してよい。マスタデバイス11のプロセッサ113は、各々のスレーブデバイス13に対して、対応するデバイス情報22およびジョブ21に応じてリソースフィーチャーモデルのサンプルからリソースフィーチャーモデル23を選択できる。
クラスタコンピューティングシステム1が分散ファイルシステム15を備えていない場合、マスタデバイス11のプロセッサ113は、各々のスレーブデバイス13に対して、他のソースによって提供されたリソースフィーチャーモデルのサンプルに応じてリソースフィーチャーモデル23を選択してもよい。例えば、マスタデバイス11は、複数のリソースフィーチャーモデルのサンプルを事前に記憶するために記憶デバイス(図示せず)を備えていてもよいし、他のデバイスから事前に複数のリソースフィーチャーモデルのサンプルを取得してもよい。
マスタデバイス11のプロセッサ113は、各々のスレーブデバイス13に対して、対応するデバイス情報22およびジョブ21に応じてリソースフィーチャーモデルのサンプルからリソースフィーチャーモデル23を選択できる。前述のリソースフィーチャーモデルのサンプルは、リソースフィーチャーモデル23自体であってもよいし、リソースフィーチャーモデルに関連する情報であってもよい。
取得できるリソースフィーチャーモデルのサンプル数が多すぎると(例えば閾値よりも多いと)、クラスタコンピューティングシステム1が分散ファイルシステム15を備えていようとなかろうと、マスタデバイス11のプロセッサ113は、任意選択として複数のリソースフィーチャーモデルのサンプルを複数のグループに分類して、各々のグループからリソースフィーチャーモデルのサンプルをリソースフィーチャーモデルの代表として選択してよい。
例えば、マスタデバイス11のプロセッサ113は、K平均アルゴリズムを用いて複数のリソースフィーチャーモデルのサンプルを複数のグループに分類できる。次に、マスタデバイス11のプロセッサ113は、各々のスレーブデバイス13に対して、対応するデバイス情報22およびジョブ21に応じてリソースフィーチャーモデルの代表からリソースフィーチャーモデル23を選択できる。前述のリソースフィーチャーモデルのサンプルは、リソースフィーチャーモデル23自体であってもよいし、リソースフィーチャーモデルに関連する情報であってもよい。
マスタデバイス11のプロセッサ113は、対応するリソースフィーチャーモデル、同様のリソースフィーチャーモデル、および事前設定されたリソースフィーチャーモデルのうちの1つを、対応するデバイス情報22およびジョブ21に応じて各々のスレーブデバイス13に対するリソースフィーチャーモデル23として選択できる。対応するリソースフィーチャーモデルは、同様のリソースフィーチャーモデルに対して優先的に選択され、同様のリソースフィーチャーモデルは、事前設定されたリソースフィーチャーモデルに対して優先的に選択される。具体的には、各々のスレーブデバイス13に対して、マスタデバイス11のプロセッサ113は、最初に、対応するデバイス情報22およびジョブ21に応じて、対応するリソースフィーチャーモデル(すなわちデバイス情報22およびジョブ21に完全に対応するリソースフィーチャーモデル)があるかどうかを判断できる。
判断結果が「はい」であれば、マスタデバイス11のプロセッサ113は、対応するリソースフィーチャーモデルをリソースフィーチャーモデル23として選択する。判断結果が「いいえ」であれば、マスタデバイス11のプロセッサ113は、対応するデバイス情報22およびジョブ21に応じて、同様のリソースフィーチャーモデル(すなわちデバイス情報22およびジョブ21にほぼ対応するリソースフィーチャーモデル)があるかどうかを判断する。判断結果が「はい」であれば、マスタデバイス11のプロセッサ113は、同様のリソースフィーチャーモデルをリソースフィーチャーモデル23として選択する。判断結果が「いいえ」であれば、マスタデバイス11のプロセッサ113は、事前設定されたリソースフィーチャーモデル(すなわち事前設定されているリソースフィーチャーモデル)をリソースフィーチャーモデル23として選択する。
マスタデバイス11のプロセッサ113は、各々のリソースフィーチャーモデル23に応じて、対応するスレーブデバイス13のコンテナ構成パラメータ24を推定できる。各々のコンテナ構成パラメータ24は、コンテナ数およびコンテナ仕様を含んでいてよい。また、各々のコンテナ仕様は、必要に応じて、CPU仕様、メモリ仕様、ネットワーク仕様、ディスク入出力(ディスクIO)仕様などであってこれに限定されない任意の多様な仕様を含んでいてよい。
具体的には、マスタデバイス11のプロセッサ113は、各々のリソースフィーチャーモデル23に応じて、対応するスレーブデバイス13に必要な多様な仕様(例えばCPU仕様、メモリ仕様、ネットワーク仕様、ディスクIO仕様など)を推定してジョブ21を計算するためのコンテナを開けられる。次に、マスタデバイス11のプロセッサ113は、スレーブデバイス13のデバイス情報22および推定した仕様(例えばCPU仕様、メモリ仕様、ネットワーク仕様、ディスクIO仕様など)に応じて、スレーブデバイス13によって開けられる必要のあるコンテナ数を推定できる。
例えば、マスタデバイス11のプロセッサ113が、スレーブデバイス13がコンテナを開けてジョブ21を計算するために必要なCPU仕様およびメモリ仕様がそれぞれ1ギガヘルツ(1GHz)および1ギガバイト(1GB)であると推定し、かつデバイス情報22が、スレーブデバイス13のCPU能力およびメモリ能力がそれぞれ4ギガヘルツ(4GHz)および4ギガバイト(4GB)であると指摘すれば、マスタデバイス11のプロセッサ113は、スレーブデバイス13がジョブ21を計算するのに必要なコンテナ数が4であると推定する。
マスタデバイス11のプロセッサ113は、各々のコンテナ構成パラメータ24を接続インターフェース111を介して対応するスレーブデバイス13に伝送し、これらのスレーブデバイスにジョブ21を割り当ててよい。
クラスタコンピューティングシステム1が同システム内に利用可能なスレーブデバイス13を1つしか有していなければ、ジョブ21は、その単一のスレーブデバイス13のみで計算される。クラスタコンピューティングシステム1が同システム内に利用可能なスレーブデバイス13を複数有していれば、ジョブ21は、これらのスレーブデバイス13全部で計算される。後者の場合、マスタデバイス11のプロセッサ113は、ジョブ21を複数のタスクに分割した後、これらのタスクをこれらのスレーブデバイス13に割り当てる。ジョブ21を複数のタスクに分割し、そのタスクを複数のスレーブデバイス13に割り当てるという方法は、当業者には公知のものであり、これについては本明細書ではこれ以上説明しない。
各々のスレーブデバイス13のプロセッサ133は、マスタデバイス11によって割り当てられたジョブ21(またはマスタデバイスによって割り当てられたジョブ21に対応するタスク)および対応するコンテナ構成パラメータ24を、接続インターフェース131を介して受信できる。次に、各々のスレーブデバイス13のプロセッサ133は、受信したコンテナ構成パラメータ24に応じてジョブ21(またはマスタデバイスによって割り当てられたジョブ21に対応するタスク)を計算するために少なくとも1つのコンテナを生成できる。
クラスタコンピューティングシステム1では、各々のスレーブデバイス13は、多様なローカルデータを記憶するためのメトリックファイルを有する。したがって、少なくとも1つのコンテナによってジョブ21(またはマスタデバイスによって割り当てられたジョブ21に対応するタスク)を計算するプロセスの過程で、スレーブデバイス13のプロセッサ133は、少なくとも1つのコンテナのジョブステータスを収集して、ジョブステータスのステータス情報をメトリックファイルに記憶できる。
ジョブ21(またはマスタデバイスによって割り当てられたジョブ21に対応するタスク)の計算が完了した後、各々のスレーブデバイス13のプロセッサ133は、ジョブ21に対応するジョブ情報およびそのメトリックファイルに応じてリソースフィーチャーモデル23を作成できる。例えば、各々のスレーブデバイス13のプロセッサ133は、サポートベクトル回帰(Support Vector Regression、SVR)モジュール生成部を使用して、ジョブ21に対応するジョブ情報およびそのメトリックファイルに応じてリソースフィーチャーモデルを作成できる。上記のように、リソースフィーチャーモデル23は、必要に応じて、CPUフィーチャーモデル、メモリフィーチャーモデル、ネットワークフィーチャーモデル、ディスク入出力(ディスクIO)フィーチャーモデルなどであってこれに限定されない任意の多様なフィーチャーモデルを含んでいてよい。
クラスタコンピューティングシステム1が分散ファイルシステム15を備えている場合、マスタデバイス11のプロセッサ113は、ジョブ21に対応するジョブ情報を事前に分散ファイルシステム15に記憶でき、各々のスレーブデバイス13のプロセッサ133は、分散ファイルシステム15からジョブ21に対応するジョブ情報を取得できる。
クラスタコンピューティングシステム1が分散ファイルシステム15を備えていない場合、各々のスレーブデバイス13のプロセッサ133は、ジョブ21に対応するジョブ情報を他の方法で取得してもよい。例として、各々のスレーブデバイス13のプロセッサ133は、接続インターフェース131および接続インターフェース111を介して、マスタデバイス11からジョブ21に対応するジョブ情報を取得してよい。もう1つの例として、各々のスレーブデバイス13は、ジョブ21に対応するジョブ情報を事前に記憶するための記憶装置(図示せず)を備えていてもよいし、ジョブ21に対応するジョブ情報を他のデバイスから事前に取得してもよい。
本発明の当業者にとっては、マスタデバイス11と複数のスレーブデバイス13との相互作用は、同じく公知のものであってよいため、クラスタコンピューティングシステム1内でのマスタデバイス11と単一のスレーブデバイス13との相互作用をさらに説明するために、図2をこの実施形態の例示的な例とみなす。しかしながら、これは本発明を限定するためではなく、説明しやすくするために過ぎない。
図2は、クラスタコンピューティングシステム1にあるマスタデバイス11および単一のスレーブデバイス13の動作を示す概略構造図である。図2に示したスレーブデバイス13は、図1に示した複数のスレーブデバイス13のいずれであってもよい
図2に示したように、マスタデバイス11は、任意選択として、前述した接続インターフェース111およびプロセッサ113の機能を達成するのを補助するために、以下の素子を備えていてよい。リソース管理部1131、ジョブ管理部1133、最適なリソースモジュール1135およびモデル管理部1137。
このほか、スレーブデバイス13は、任意選択として、前述した接続インターフェース131およびプロセッサ133の機能を達成するのを補助するために、以下の素子を備えていてよい。スレーブ管理部1331、少なくとも1つのコンテナ1333、モデル生成部1335、ジョブステータス収集部1337およびメトリックファイル1339。
まず、ジョブ21がマスタデバイス11によって受信されると、リソース管理部1131は、ジョブ管理部1133を作動させ、その後ジョブ21をジョブ管理部1133に移して処理する。同時に、リソース管理部1131は、スレーブ管理部1331からこのスレーブ管理部のデバイス情報22を取得し、その後、デバイス情報22をジョブ管理部1133に伝送してよい。次に、ジョブ管理部1133は、ジョブ21およびデバイス情報22を最適なリソースモジュール1135に伝送する。
ジョブ21およびデバイス情報22を取得した後、最適なリソースモジュール1135は、ジョブ21およびデバイス情報22に応じてモデル管理部1137からリソースフィーチャーモデル23を取得する。同時に、最適なリソースモジュール1135は、ジョブ21に対応するジョブ情報25を分散ファイルシステム15に記憶できる。次に、最適なリソースモジュール1135は、スレーブデバイス13のコンテナ構成パラメータ24をリソースフィーチャーモデル23に応じて推定し、その後、コンテナ構成パラメータ24をジョブ管理部1133に伝送する。最後に、ジョブ管理部1133は、コンテナ構成パラメータ24をリソース管理部1131に伝送する。
コンテナ構成パラメータ24を取得した後、リソース管理部1131は、コンテナ構成パラメータ24をスレーブ管理部1331に伝送し、ジョブ21をスレーブ管理部1331に割り当てる。スレーブ管理部1331は、少なくとも1つのコンテナ1333を生成して、コンテナ構成パラメータ24に応じてジョブ21(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)を計算する。
スレーブ管理部1331は、コンテナ構成パラメータ24に応じて、コンテナ数1333のほか、コンテナ1333のCPU仕様およびメモリ仕様も判断できる。コンテナ1333によってジョブ21(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)を計算するプロセスの過程で、ジョブステータス収集部1337は、コンテナ1333がジョブ21(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)を計算しているジョブステータスを収集し、そのジョブステータスに対応するステータス情報26をメトリックファイル1339に記憶する。
ステータス情報26は、以下のものを含んでいてよいがこれに限定されない。各々のコンテナ1333のCPU消費量およびメモリ消費量。
ジョブ21(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)がコンテナ1333によって計算された後、モデル生成部1335は、ジョブ21に対応するジョブ情報25(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)およびメトリックファイル1339に応じて、リソースフィーチャーモデル23を作成または更新できる。例えば、モデル生成部1335は、サポートベクトル回帰モジュール生成部を使用して、ジョブ情報25およびメトリックファイル1339に応じてリソースフィーチャーモデル23を作成できる。
モデル生成部1335は、分散ファイルシステム15から、かつ/またはスレーブ管理部1331からジョブ情報25を取得できる。
分散ファイルシステム15から取得したジョブ情報25は、以下のものを含んでいてよいがこれに限定されない。データサイズ、Map/Reduceの見せかけの数など。スレーブ管理部1331から取得したジョブ情報25は、以下のものを含んでいてよいがこれに限定されない。各々のコンテナによるMap/Reduce計算に関する情報など。メトリックファイル1339から取得した情報は、以下のものを含んでいてよいがこれに限定されない。ステータス情報26、計算プロセス中のハードウェア性能に関する情報など。
図3、図4、図5および図6は、最適なリソースモジュール1135、モデル管理部1137、モデル生成部1335およびジョブステータス収集部1337のそれぞれの特定の動作を示す概略図である。しかしながら、本発明の他の実施形態では、図2に示した最適なリソースモジュール1135、モデル管理部1137、モデル生成部1335およびジョブステータス収集部1337の動作は、図3〜図6に示したものに完全に従っている必要はないが、本発明の精神を逸脱しない限り、適切に調整、変更、かつ/または置換されてよい。
図3に示したように、最適なリソースモジュール1135は、ジョブ情報回収部1135a、利用可能なノード検査部1135b、モデル搭載部1135c、最適なリソース予測部1135d、および最適なコンテナ数予測部1135eを備えていてよい。ジョブ21がジョブ管理部1133によって取得された後、ジョブ情報回収部1135aは、以下のデータを受信する。ジョブ名(例えばアルゴリズム名)、入力データサイズおよび全Map/Reduceタスク。
入力データサイズおよび全Map/Reduceタスクはその後、分散ファイルシステム15に記憶される。利用可能なノード(すなわち利用可能なスレーブデバイス13)がクラスタコンピューティングシステム1に現れると、ノード名は、利用可能なノード検査部1135bによって受信される。次に、モデル搭載部1135cは、ジョブ名およびノード名に応じて、モデル管理部1137内の対応するリソースフィーチャーモデル23を検索する。
最適なリソース予測部1135dは、リソースフィーチャーモデル23に応じて、ノードに対応するコンテナのCPU仕様およびメモリ仕様を予測でき、最適なコンテナ数予測部1135eは、CPU仕様およびメモリ仕様に応じてノードのコンテナ数を推定できる。
したがって、前述した最適なリソース予測部1135dおよび最適なコンテナ数予測部1135eの動作を通して、ノードのコンテナ構成パラメータ24は、最適なリソースモジュール1135によって推定され、その後、ジョブ管理部1133に伝送されることが可能である。
図4に示したように、モデル管理部1137は、要求処理部1137a、モデル回収部1137b、同質モデルエンジン1137cおよび同質ノードエンジン1137dを備えていてよい。最適なリソースモジュール1135がリソースフィーチャーモデル23を検索するための要求を出すと、要求処理部1137aは、最適なリソースモジュール1135によって伝送されたジョブ名およびノード名に応じて、分散ファイルシステム15または他のソースに記憶された複数のリソースフィーチャーモデルのサンプルからリソースフィーチャーモデル23を選択する。例えば、要求処理部1137aは、対応するリソースフィーチャーモデル、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの1つをリソースフィーチャーモデル23として選択してよい。
同質モデルエンジン1137cは、モデル情報回収部(図示せず)、モデル統合部(図示せず)およびグループ決定部(図示せず)を備えていてよい。リソースフィーチャーモデルのサンプルの数が多すぎると(例えば閾値よりも多いと)、モデル情報回収部は、各々のリソースフィーチャーモデルのサンプルに関する多様な情報を回収し、その後、モデル統合部は、そのような情報に応じてリソースフィーチャーモデルのサンプルを複数のグループに分類する。
例えば、モデル統合部は、K平均アルゴリズムを用いてリソースフィーチャーモデルのサンプルを複数のグループに分類してよい。このほか、任意選択として、モデル統合部は、リソースフィーチャーモデルのサンプルをリソースフィーチャーモデルの代表として、各々のグループから選択してよく、要求管理部1137aは、最適なリソースモジュール1135によって伝送されたジョブ名およびノード名に応じて、リソースフィーチャーモデルの代表からリソースフィーチャーモデル23を選択してよい。新たなリソースフィーチャーモデルのサンプルが現れると、グループ決定部は、新たなリソースフィーチャーモデルのサンプルの多様な情報に応じて、その新たなリソースフィーチャーモデルのサンプルを最も適切なグループに追加する。
同質ノードエンジン1137dは、ノード情報回収部(図示せず)、ノード統合部(図示せず)、グループ決定部(図示せず)およびグループモデル生成部(図示せず)を備えていてよい。ノード数(すなわちスレーブデバイス13)が多すぎると(例えば閾値よりも多いと)、ノード情報回収部は、各々のノードの多様な情報(例えばハードウェア情報)を回収し、次にノード統合部は、そのような情報に応じてノードを複数のグループに分類する。
例えば、ノード統合部は、K平均アルゴリズムを用いてノードを複数のグループに分類してよい。新たなノードが現れると、グループ決定部は、その新たなノードの多様な情報に応じて、最も適切なグループに新たなノードを追加する。このほか、グループモデル生成部は、新たなノードが属するグループ内の訓練データを回収し、サポートベクトル回帰モジュール生成部を用いて新たなノードに対してリソースフィーチャーモデル23を作成し、リソースフィーチャーモデル23を分散ファイルシステム15に記憶する。他の実施形態では、同質ノードエンジン1137dは、同質モデルエンジン1137cと組み合わされてよい。
図5に示したように、モデル生成部1335は、ジョブ終了検知部1335a、ジョブ情報回収部1335bおよびサポートベクトル回帰モデル生成部1335cを備えていてよい。ジョブ終了検知部1335aは、ジョブ21(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)が終了したかどうかを検知するように構成されている。
ジョブ21(またはリソース管理部1131によって割り当てられたジョブ21に対応するタスク)が終了した後、ジョブ情報回収部1335bは、分散ファイルシステム15からジョブ21に対応するジョブ情報25を取得し、メトリックファイル1339から多様な情報(ステータス情報26を含む)を取得する。次に、サポートベクトル回帰モジュール生成部1335cは、リソースフィーチャーモデル23を作成し、これをジョブ情報25およびメトリックファイル1339の多様な情報に応じて分散ファイルシステム15に記憶する。
サポートベクトル回帰モジュール生成部1335cの入力データは、以下のものを含んでいてよいが、これに限定されない。ジョブ情報回収部1335bから得た履歴ジョブデータセットのサイズ、ジョブ情報回収部1335bから得た履歴ジョブのMapタスクの合計数、ジョブ情報回収部1335bから得た履歴ジョブのReduceタスクの合計数、履歴ジョブ内のノードに割り当てられたMapコンテナ数、履歴ジョブ内のノードに割り当てられたReduceコンテナ数、履歴ジョブ内の単一タスクのCPU使用率、履歴ジョブ内の単一タスクのメモリ使用率など。
履歴ジョブ内の単一タスクのCPU使用率は、動作中のMap数およびReduce数で割ったCPU使用率に等しく、履歴ジョブ内の単一タスクのメモリ使用率は、動作中のMap数およびReduce数で割ったメモリ使用率に等しい。ジョブ情報25およびメトリックファイル1339の多様な情報は、以下のものを含んでいてよいが、これに限定されない。入力データサイズ、割り当てられたMapタスク、割り当てられたReduceタスク、割り当てられたMapスロット、割り当てられたReduceスロット、1タスク当たりの平均CPU使用率、1タスク当たりの平均メモリ使用率など。
図6に示したように、ジョブステータス収集部1337は、ハードウェア性能収集部1337a、ジョブステータス収集部1337bおよびメトリック集計部1337cを備えていてよい。ハードウェア性能収集部1337aは、コンテナ1333中のCPU使用率およびメモリ使用率に関する情報を収集するように構成され、ジョブステータス収集部1337bは、割り当てられたMapスロット、割り当てられたReduceスロット、計算されているMapタスクおよび計算されているReduceタスクに関する情報を収集するように構成されている。
メトリック集計部1337cは、ハードウェア性能収集部1337aおよびジョブステータス収集部1337bによってメトリックファイル1339内に収集された情報を集計するように構成されている。メトリックファイル1339内に集計された情報は、以下のものを含むが、これに限定されない。割り当てられたMapスロット、割り当てられたReduceスロット、1タスク当たりの平均CPU使用率、1タスク当たりの平均メモリ使用率など。1タスク当たりの平均CPU使用率は、CPU使用率を、計算されているMapタスク数と計算されているリデュース処理されたタスク数との和で割ったものに等しく、1タスク当たりの平均メモリ使用率は、メモリ使用率を、計算されているMapタスク数と動作しているリデュース処理されたタスク数との和で割ったものに等しい。
図3〜図6に示した最適なリソースモジュール1135、モデル管理部1137、モデル生成部1135およびジョブステータス収集部1337はそれぞれ、この実施形態の例示的な例として提供しているに過ぎず、本発明を限定する意図はない。
本発明のもう1つの実施形態(簡潔に「第2の実施形態」と呼ぶ)は、クラスタコンピューティングシステム内にあるマスタデバイスおよびスレーブデバイス用のコンピューティング方法である。クラスタコンピューティングシステム、マスタデバイスおよびスレーブデバイスはそれぞれ、前述した実施形態のクラスタコンピューティングシステム1、マスタデバイス11およびスレーブデバイス13であるとみなしてよい。
図7は、クラスタコンピューティングシステム内にあるマスタデバイスおよびスレーブデバイス用のコンピューティング方法を示す概略図である。
マスタデバイスに対して、この実施形態のコンピューティング方法は、以下のステップを含む。スレーブデバイスのデバイス情報をマスタデバイスのプロセッサで受信するステップS21。デバイス情報およびジョブに応じて、スレーブデバイスに対するリソースフィーチャーモデルをマスタデバイスのプロセッサによって選択するステップS23。リソースフィーチャーモデルに応じて、スレーブデバイスのコンテナ構成パラメータをマスタデバイスのプロセッサによって推定するステップS25。コンテナ構成パラメータをマスタデバイスのプロセッサによってスレーブデバイスに伝送するステップS27。および、ジョブをマスタデバイスのプロセッサによってスレーブデバイスに割り当てるステップS29。
ステップS21〜S29を示す順序は、本発明を限定する意図はなく、本発明の精神を逸脱しない限り適切に調整できるものである。
本コンピューティング方法の例示的な一例では、クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、同システムはマスタデバイスとスレーブデバイスとで共有される。ステップS23は、以下のステップを含む。デバイス情報およびジョブに応じて、分散ファイルシステムからスレーブデバイスに対するリソースフィーチャーモデルをマスタデバイスのプロセッサによって選択するステップ。この例では、コンピューティング方法は、任意選択としてさらに以下のステップを含んでいてよい。ジョブに対応するジョブ情報をマスタデバイスのプロセッサによって分散ファイルシステム内に記憶する。
本コンピューティング方法の例示的な一例では、リソースフィーチャーモデルは、CPUフィーチャーモデルおよびメモリフィーチャーモデルを含み、コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含む。コンテナ仕様は、CPU仕様およびメモリ仕様を含む。
本コンピューティング方法の例示的な一例では、ステップS23は、以下のステップを含む。デバイス情報およびジョブに応じて、対応するリソースフィーチャーモデル、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの1つを、スレーブデバイスに対するリソースフィーチャーモデルとして、マスタデバイスのプロセッサによって選択するステップ。対応するリソースフィーチャーモデルは、同様のリソースフィーチャーモデルに対して優先的に選択され、同様のリソースフィーチャーモデルは、事前設定されたリソースフィーチャーモデルに対して優先的に選択される。
本コンピューティング方法の例示的な一例では、ステップS23は、以下のステップを含む。複数のリソースフィーチャーモデルのサンプルをマスタデバイスのプロセッサによって複数のグループに分類する。マスタデバイスのプロセッサによって、各々のグループからリソースフィーチャーモデルのサンプルをリソースフィーチャーモデルの代表として選択するステップ。および、マスタデバイスのプロセッサによって、リソースフィーチャーモデルの代表からスレーブデバイスに対するリソースフィーチャーモデルをデバイス情報およびジョブに応じて選択するステップ。
スレーブデバイスに対して、この実施形態のコンピューティング方法は、以下のステップを含む。デバイス情報をスレーブデバイスのプロセッサによってマスタデバイスに伝送するステップS31。マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータを、スレーブデバイスのプロセッサによってマスタデバイスから受信するステップS33。スレーブデバイスのプロセッサによって、コンテナ構成パラメータに応じてジョブを計算するために少なくとも1つのコンテナを生成するステップS35。および、ジョブに対応するジョブ情報およびメトリックファイルに応じて、スレーブデバイスのプロセッサによってリソースフィーチャーモデルを作成するステップS37。ステップS31〜S37を示す順序は、本発明を限定する意図はなく、本発明の精神を逸脱しない限り適切に調整できるものである。
本コンピューティング方法の例示的な一例では、クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、同システムはマスタデバイスとスレーブデバイスとで共有される。ステップS37は、以下のステップを含む。スレーブデバイスのプロセッサによって、ジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを分散ファイルシステム内に形成するステップ。この例では、コンピューティング方法は、任意選択としてさらに以下のステップを含んでいてよい。スレーブデバイスのプロセッサによって分散ファイルシステムからジョブ情報を取得するステップ。
本コンピューティング方法の例示的な一例では、コンピューティング方法はさらに、以下のステップを含む。コンテナがジョブを計算するジョブステータスを収集し、そのジョブステータスに対応するステータス情報を、スレーブデバイスのプロセッサによってメトリックファイル内に記憶するステップ。
本コンピューティング方法の例示的な一例では、リソースフィーチャーモデルは、CPUフィーチャーモデルおよびメモリフィーチャーモデルを含み、コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含み、コンテナ仕様は、CPU仕様およびメモリ仕様を含む。
本コンピューティング方法の例示的な一例では、ステップS37は、以下のステップを含む。プロセッサによってサポートベクトル回帰モジュール生成部を使用して、ジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成するステップ。
第2の実施形態のコンピューティング方法は、本質的に、前回の実施形態のマスタデバイス11およびスレーブデバイス13の動作に対応するステップをすべて含む。本発明の当業者は、前回の実施形態の関連する開示に従って、第2の実施形態に記載していないコンピューティング方法を直接理解できる。
以上に記載してきた内容に加えて、第2の実施形態のコンピューティング方法はさらに、前回の実施形態のマスタデバイス11およびスレーブデバイス13の他の動作に対応するステップを含む。第2の実施形態のコンピューティング方法が、第2の実施形態で開示していないこれらの対応するステップを実行する方法は、第1の実施形態の関連する開示に基づいて本発明の当業者が容易に理解できるものであるため、本明細書ではこれ以上説明しない。
上記の説明によれば、本発明は、クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法を提供する。本発明によれば、マスタデバイスが、各々のスレーブデバイスによって伝送されたデバイス情報を受信し、デバイス情報およびジョブに応じて各々のスレーブデバイスに対するリソースフィーチャーモデルを選択し、各々のリソースフィーチャーモデルに応じて、対応するスレーブデバイスのコンテナ構成パラメータを推定し、各々のコンテナ構成パラメータを対応するスレーブデバイスに伝送し、スレーブデバイスにジョブを割り当てる。
本発明によれば、スレーブデバイスが、スレーブデバイスのデバイス情報をマスタデバイスに伝送し、マスタデバイスによって割り当てられたジョブおよびコンテナ構成パラメータをマスタデバイスから受信し、コンテナ構成パラメータに応じてジョブを計算するために少なくとも1つのコンテナを生成し、ジョブに対応するジョブ情報およびメトリックファイルに応じてリソースフィーチャーモデルを作成する。
したがって、本発明のスレーブデバイスによって生成されたコンテナの仕様は、動的に調整でき、よって様々なジョブの様々な特性が原因であるリソースの無駄がなくなる。さらに、コンテナ仕様は本発明の各々のコンテナに対して一定ではないため、本発明のスレーブデバイスのコンテナ数も動的に調整でき、よってリソースのアイドル状態がなくなる。このほか、本発明のスレーブデバイスによって生成されたコンテナ仕様およびコンテナ数を動的に調整できるため、複数のスレーブデバイスが様々なデバイス性能を有する場合であっても、リソースの不適切な割り当てが起こらない。
上記の開示は、詳細な技術内容およびその発明性のある特徴に関するものである。当業者は、本発明の特徴を逸脱しない限り、記載した本発明の開示および提示に基づいて多種多様な修正および置換を加えてよい。ただし、そのような修正および置換は、上記の説明文には完全に開示されていないが、実質的には以下の付属の特許請求の範囲内に含まれている。

Claims (10)

  1. クラスタコンピューティングシステム用のマスタデバイスであって、
    少なくとも1つのスレーブデバイスと接続するように構成されている接続インターフェースと、
    前記接続インターフェースに電気接続されているプロセッサであって、前記スレーブデバイスからデバイス情報を受信し、前記デバイス情報およびジョブに応じて前記スレーブデバイスに対するリソースフィーチャーモデルを選択し、前記リソースフィーチャーモデルに応じて前記スレーブデバイスのコンテナ構成パラメータを推定し、前記コンテナ構成パラメータを前記スレーブデバイスへ伝送し、前記スレーブデバイスに前記ジョブを割り当てるように構成されている、プロセッサと、を備え
    前記プロセッサはさらに、複数のリソースフィーチャーモデルのサンプルを複数のグループに分類し、リソースフィーチャーモデルのサンプルを各々の前記グループからリソースフィーチャーモデルの代表として選択し、前記スレーブデバイスに対するリソースフィーチャーモデルを前記リソースフィーチャーモデルの代表から選択する
    マスタデバイス。
  2. 前記前記クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、前記マスタデバイスは、前記分散ファイルシステムを前記スレーブデバイスと共有し、前記プロセッサは、前記分散ファイルシステムから前記スレーブデバイスに対するリソースフィーチャーモデルを選択する、請求項1に記載のマスタデバイス。
  3. 前記プロセッサはさらに、ジョブに対応するジョブ情報を前記分散ファイルシステムに記憶する、請求項2に記載のマスタデバイス。
  4. 前記リソースフィーチャーモデルは、中央処理装置(CPU)フィーチャーモデルおよびメモリフィーチャーモデルを含み、前記コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含み、前記コンテナ仕様は、CPU仕様およびメモリ仕様を含む、請求項1に記載のマスタデバイス。
  5. 前記プロセッサは、前記デバイス情報および前記ジョブに完全に対応する、対応するリソースフィーチャーモデル、前記デバイス情報および前記ジョブにほぼ対応する、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの1つを、前記リソースフィーチャーモデルとして選択し、前記対応するリソースフィーチャーモデルは、前記同様のリソースフィーチャーモデルに対して優先的に選択され、前記同様のリソースフィーチャーモデルは、前記事前設定されたリソースフィーチャーモデルに対して優先的に選択される、請求項1に記載のマスタデバイス。
  6. クラスタコンピューティングシステム内にあるマスタデバイスに対するコンピューティング方法であって、前記マスタデバイスは、接続インターフェースおよびプロセッサを備え、前記接続インターフェースは、少なくとも1つのスレーブデバイスと接続するように構成されているコンピューティング方法において、
    (A)前記スレーブデバイスのデバイス情報を前記プロセッサで受信するステップと、
    (B)前記スレーブデバイスに対するリソースフィーチャーモデルを、前記デバイス情報およびジョブに応じて前記プロセッサによって選択するステップと、
    (C)前記スレーブデバイスのコンテナ構成パラメータを、前記リソースフィーチャーモデルに応じて前記プロセッサによって推定するステップと、
    (D)前記プロセッサによって前記コンテナ構成パラメータを前記スレーブデバイスに伝送するステップと、
    (E)前記プロセッサによって前記スレーブデバイスに前記ジョブを割り当てるステップとを含み、
    前記ステップ(B)は、複数のリソースフィーチャーモデルのサンプルを前記プロセッサによって複数のグループに分類することと、前記プロセッサによって、リソースフィーチャーモデルのサンプルを各々の前記グループからリソースフィーチャーモデルの代表として選択することと、前記スレーブデバイスに対するリソースフィーチャーモデルを、前記プロセッサによってデバイス情報および前記ジョブに応じて、前記リソースフィーチャーモデルの代表から選択することとを含む
    コンピューティング方法。
  7. 前記クラスタコンピューティングシステムはさらに、分散ファイルシステムを備え、前記マスタデバイスは、前記分散ファイルシステムを前記スレーブデバイスと共有し、前記ステップ(B)は、前記デバイス情報および前記ジョブに応じて、前記スレーブデバイスに対するリソースフィーチャーモデルを前記分散ファイルシステムから前記プロセッサによって選択することを含む、請求項に記載のコンピューティング方法。
  8. (F)前記ジョブに対応するジョブ情報を、前記プロセッサによって前記分散ファイルシステム内に記憶するステップをさらに含む、請求項7に記載のコンピューティング方法。
  9. 前記リソースフィーチャーモデルは、CPUフィーチャーモデルおよびメモリフィーチャーモデルを含み、前記コンテナ構成パラメータは、コンテナ数およびコンテナ仕様を含み、前記コンテナ仕様は、CPU仕様およびメモリ仕様を含む、請求項に記載のコンピューティング方法。
  10. 前記ステップ(B)は、前記デバイス情報および前記ジョブに完全に対応する、対応するリソースフィーチャーモデル、前記デバイス情報および前記ジョブにほぼ対応する、同様のリソースフィーチャーモデルおよび事前設定されたリソースフィーチャーモデルのうちの1つを、前記プロセッサによってデバイス情報および前記ジョブに応じて、前記スレーブデバイスに対するリソースフィーチャーモデルとして選択することを含み、前記対応するリソースフィーチャーモデルは、前記同様のリソースフィーチャーモデルに対して優先的に選択され、前記同様のリソースフィーチャーモデルは、前記事前設定されたリソースフィーチャーモデルに対して優先的に選択される、請求項に記載のコンピューティング方法。
JP2015000221A 2014-08-27 2015-01-05 クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法 Active JP6001690B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
TW103129437 2014-08-27
TW103129437A TWI510931B (zh) 2014-08-27 2014-08-27 用於一叢集運算系統之主裝置、從屬裝置及其運算方法

Publications (2)

Publication Number Publication Date
JP2016048536A JP2016048536A (ja) 2016-04-07
JP6001690B2 true JP6001690B2 (ja) 2016-10-05

Family

ID=55402666

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015000221A Active JP6001690B2 (ja) 2014-08-27 2015-01-05 クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法

Country Status (4)

Country Link
US (1) US20160062929A1 (ja)
JP (1) JP6001690B2 (ja)
CN (1) CN105511955A (ja)
TW (1) TWI510931B (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9672064B2 (en) * 2015-07-13 2017-06-06 Palo Alto Research Center Incorporated Dynamically adaptive, resource aware system and method for scheduling
US10733023B1 (en) * 2015-08-06 2020-08-04 D2Iq, Inc. Oversubscription scheduling
CN107885595B (zh) * 2016-09-30 2021-12-14 华为技术有限公司 一种资源分配方法、相关设备及系统
TWI641951B (zh) * 2017-11-20 2018-11-21 宏碁股份有限公司 動態分派工作及提供資源的方法、裝置及其系統
KR102014246B1 (ko) * 2017-11-27 2019-10-21 주식회사 비디 리소스 통합관리를 위한 메소스 처리 장치 및 방법
EP3882771A1 (en) * 2020-03-16 2021-09-22 Leica Microsystems CMS GmbH Control system and method for operating a system
TWI742774B (zh) * 2020-07-22 2021-10-11 財團法人國家實驗研究院 運算系統及其主機資源分配方法
JP7459014B2 (ja) 2021-05-18 2024-04-01 トヨタ自動車株式会社 コンテナ管理装置、及びコンテナ管理プログラム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8458691B2 (en) * 2004-04-15 2013-06-04 International Business Machines Corporation System and method for dynamically building application environments in a computational grid
WO2009057208A1 (ja) * 2007-10-31 2009-05-07 Fujitsu Limited 資源割当プログラム、管理ノード、資源割当方法、および並列計算機システム
WO2009059377A1 (en) * 2007-11-09 2009-05-14 Manjrosoft Pty Ltd Software platform and system for grid computing
JP5584914B2 (ja) * 2010-07-15 2014-09-10 株式会社日立製作所 分散計算システム
CN102339296A (zh) * 2010-07-26 2012-02-01 阿里巴巴集团控股有限公司 一种查询结果的排序方法和装置
US20140122546A1 (en) * 2012-10-30 2014-05-01 Guangdeng D. Liao Tuning for distributed data storage and processing systems

Also Published As

Publication number Publication date
CN105511955A (zh) 2016-04-20
JP2016048536A (ja) 2016-04-07
TW201608382A (zh) 2016-03-01
US20160062929A1 (en) 2016-03-03
TWI510931B (zh) 2015-12-01

Similar Documents

Publication Publication Date Title
JP6001690B2 (ja) クラスタコンピューティングシステム用のマスタデバイス、スレーブデバイスおよびそのコンピューティング方法
US10635664B2 (en) Map-reduce job virtualization
CN110301128B (zh) 基于学习的资源管理数据中心云架构的实现方法
TWI547817B (zh) 叢集運算架構的資源規劃方法、系統及裝置
CN116501683A (zh) 用于协调解聚的加速器装置资源的技术
US10419437B2 (en) Quasi-agentless cloud resource management
WO2017186123A1 (en) System and method for distributed resource management
US10719363B2 (en) Resource claim optimization for containers
US20140282540A1 (en) Performant host selection for virtualization centers
US10212064B2 (en) Assessing performance of networked computing environments
CN104050042A (zh) Etl作业的资源分配方法及装置
US20210406053A1 (en) Rightsizing virtual machine deployments in a cloud computing environment
KR101656706B1 (ko) 고성능 컴퓨팅 환경에서의 작업 분배 시스템 및 방법
US20130166751A1 (en) Distributed resource management systems and methods for resource management thereof
CN112000460A (zh) 一种基于改进贝叶斯算法的服务扩缩容的方法及相关设备
KR20190061247A (ko) 빅데이터 처리 플랫폼의 실시간 자원 사용률 모니터링 시스템
Wadhwa et al. iez: Resource contention aware load balancing for large-scale parallel file systems
WO2016084327A1 (ja) 資源予測装置、資源予測方法、資源予測プログラムおよび分散処理システム
KR101980320B1 (ko) Gpu기반의 빅데이터 검색 질의 병렬 분산처리 방법
Shinwari et al. Auto scalable big data as-a-service in the cloud: a literature review
US11740942B2 (en) Smart deployment of industrial IoT workloads
KR101393237B1 (ko) 그리드 컴퓨팅에서 동적 유효자원 재배치 기반 작업 할당 장치 및 방법
US20240126565A1 (en) Offline processing of workloads stored in registries
WO2022222975A1 (zh) 负载处理方法、计算节点、计算节点集群及相关设备
KR20210008597A (ko) 이기종 프로세싱 유닛의 성능 예측 방법 및 분산 처리 시스템

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160722

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20160816

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160901

R150 Certificate of patent or registration of utility model

Ref document number: 6001690

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250