JP6116102B2 - クラスタシステム、および、負荷分散方法 - Google Patents

Description

本発明は、クラスタシステム、および、負荷分散方法の技術に関する。

近年、クラウドコンピューティングの隆盛に伴い、多量のデータの処理や保持を効率的に行うことが求められている。そこで、複数のサーバを協調動作させることにより効率的な処理を実現する分散処理技術が発展している。分散処理を行う際には、処理対象（管理対象）のデータを、クラスタを構成する各サーバ（以下、「クラスタメンバ」または「メンバ」とも称する。）に振り分けておく必要がある。

非特許文献１に記載のコンシステント・ハッシュ法（Consistent Hashing）を用いたデータ振り分け手法では、クラスタメンバとデータの双方にＩＤ（IDentifier）を割り当て、データのＩＤからＩＤ空間を時計回りに辿った場合に最初に出合ったクラスタメンバをそのデータの担当とする。
クラスタメンバに離脱があった場合には、その離脱したメンバに隣接するクラスタメンバが、新しくデータを担当するクラスタメンバとなる。

入江他,"コンシステント・ハッシュ法におけるデータの複製を意識した負荷分散手法", 信学技法 IN 2010-77

コンシステント・ハッシュ法を用いた分散サーバシステムでは、各サーバの担当領域がＩＤ空間内に割り当てられる。一方、同じＩＤ空間内に各サーバの処理対象となるデータも割り当てられるが、データの配置によっては、特定のサーバへと負荷が集中してしまう。
なお、負荷の集中は、単純に特定サーバの担当領域内に多くのデータが集中してしまうケースだけでなく、データ量が少なくても参照頻度が高いデータが、特定サーバに割り当てられるケースでも発生する。そのため、各サーバの担当領域の広さを単純に均等にしただけでは、負荷の集中を解消できないこともある。

また、非特許文献１に記載のように、ＩＤ空間内に新たなサーバを追加することにより、負荷の集中をある程度緩和することはできる。しかし、新たなサーバを追加するためのコスト増が発生してしまうため、無条件にサーバを追加できるわけでもない。

そこで、本発明は、クラスタを構成する各サーバへの負荷を適切に分散するとともに、サーバ増設のコスト増を抑制することを、主な課題とする。

前記課題を解決するために、本発明のクラスタシステムは、スケールアウト閾値およびリバランシング閾値が格納されている記憶手段と、クラスタを構成する各サーバの負荷値を取得する負荷測定部と、前記取得された各サーバの負荷値の合計が前記スケールアウト閾値に基づく前記クラスタの負荷基準を超過しているときに、前記クラスタへのスケールアウトが必要と判定するとともに、前記取得された各サーバの負荷値が前記リバランシング閾値を超過しているときに、その超過したサーバについてリバランシングが必要と判定する負荷判定部と、前記スケールアウトが必要と判定されたときに、前記クラスタを構成するサーバ群に対して新たなサーバを追加することにより、追加前のサーバ群が担当していた負荷の一部を前記新たなサーバに割り当てるスケールアウト処理を実施するスケールアウト部と、前記リバランシングが必要と判定されたときに、前記クラスタを構成するサーバ群に対して、前記リバランシング閾値を超過したサーバが担当していた負荷の一部を、前記クラスタを構成する別のサーバに割り当てるリバランシング処理を実施するリバランシング部とを有する管理装置と、前記クラスタを構成するサーバ群とがネットワークで接続されて構成され、前記記憶手段には、各サーバと各サーバの担当データとを対応付けるデータ構造として、環状のＩＤ空間内に各サーバを示すＩＤと、各担当データを示すＩＤとが配置されているＩＤ空間管理情報が記憶されており、前記リバランシング部は、前記リバランシング閾値を超過しているサーバに対して、前記環状のＩＤ空間において隣接する２つのサーバそれぞれの負荷を取得し、それらの取得した負荷の小さいサーバを、負荷の一部の割り当て先となる前記別のサーバとすることを特徴とする。

これにより、負荷判定部がリバランシングとスケールアウトとを適切に併用することで、クラスタを構成する各サーバへの負荷を適切に分散するとともに、サーバ増設のコスト増を抑制することができる。
さらに、負荷の小さいサーバが負荷の一部の割り当て先となることで、少ない手順で効率的なリバランシングを実施することができる。

本発明は、前記負荷判定部が、前記負荷値の合計が前記前記クラスタの負荷基準を超過しているうちは、前記スケールアウト部にスケールアウト処理を実施させ、前記負荷値の合計が前記前記クラスタの負荷基準を超過しなくなった後に、負荷値が前記リバランシング閾値を超過しているサーバについて、前記リバランシング部にリバランシング処理を実施させることを特徴とする。

これにより、新たなサーバを追加するスケールアウト処理を最小限に抑え、低コストで安定的なクラスタを構成することができる。

本発明は、前記負荷判定部が、負荷値が前記リバランシング閾値を超過しているサーバについて、前記リバランシング部にリバランシング処理を実施させる処理を所定回数実行した後でも、負荷値が前記リバランシング閾値を超過しているサーバが存在するときには、負荷値の合計が前記前記クラスタの負荷基準を超過していなくても、前記スケールアウト部にスケールアウト処理を実施させることを特徴とする。

これにより、負荷が高いデータが複数ハッシュ空間上で近接していて、リバランシングしても分散しきれないようなケースでも、適切に負荷分散できる。

本発明によれば、クラスタを構成する各サーバへの負荷を適切に分散するとともに、サーバ増設のコスト増を抑制することができる。

本発明の一実施形態に関する分散処理システムを示す構成図である。 本発明の一実施形態に関する管理装置を主に示す構成図である。 本発明の一実施形態に関するＩＤ空間を示す説明図である。図３（ａ）は、５台のサーバＭ１〜Ｍ５が配置された状態を示す。図３（ｂ）は、図３（ａ）の状態から６台目のサーバＭ６が増設された状態を示す。 本発明の一実施形態に関するＩＤ空間を示す説明図である。図４（ａ）は、図３（ａ）の状態からサーバＭ４の負荷がサーバＭ３へとリバランシングされた状態を示す。図４（ｂ）は、図３（ａ）の状態からサーバＭ４の負荷がサーバＭ５へとリバランシングされた状態を示す。 本発明の一実施形態に関する管理装置の処理を示す動作説明図である。

以下、本発明の一実施形態について、図面を参照して詳細に説明する。

図１は、分散処理システムを示す構成図である。
分散処理システムは、負荷分散装置３、管理装置４、クラスタ１００を構成する複数のサーバ５を備えている。負荷分散装置３は、インターネットなどのネットワーク２を介して、複数のクライアントマシン１と接続されている。

クライアントマシン１からのデータ処理リクエストを、ネットワーク２経由で負荷分散装置３が受け取る。負荷分散装置３は、データのＩＤ空間上のサーバ割当表（図２のＩＤ空間管理情報４１１）に基づいて、そのリクエストを、データ処理を行う複数のサーバ５のいずれかに振り分ける。振り分けられたサーバ５は、そのリクエストの処理を行う。管理装置４は、ＩＤ空間管理情報４１１を管理する。

負荷分散装置３は、記憶部３１、処理部３２、通信部３３を備える。
記憶部３１は、情報を記憶する手段であり、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）などのメモリ、ＨＤＤ（Hard Disk Drive）などによって構成される。記憶部３１には、管理装置４から受信したＩＤ空間管理情報４１１が、格納されている。なお、記憶部３１には、処理部３２の動作プログラムなども格納されている（図示を省略）。
処理部３２は、記憶部３１に格納された情報に基づいて演算処理を行う手段であり、例えばＣＰＵ（Central Processing Unit）によって構成される。
通信部３３は、外部装置との通信に用いられる通信インタフェースである。なお、負荷分散装置３は、ほかに、負荷分散装置３のユーザが情報を入力する入力部や、情報を表示する表示部などを備えていてもよい。

管理装置４は、記憶部４１、処理部４２、入力部４３、表示部４４、通信部４５を備える。
記憶部４１は、情報を記憶する手段であり、ＲＡＭやＲＯＭなどのメモリ、ＨＤＤなどによって構成される。記憶部４１には、処理部４２の動作プログラムと、その動作プログラムが参照する各データが格納されている。
処理部４２は、記憶部４１に格納された情報に基づいて演算処理を行う手段であり、例えばＣＰＵによって構成される。
入力部４３は、管理装置４のユーザが情報を入力する手段であり、例えば、キーボードやマウスによって実現される。
表示部４４は、情報を表示する手段であり、例えば、ＬＣＤ（Liquid Crystal Display）によって実現される。
通信部４５は、外部装置との通信に用いられる通信インタフェースである。

図２は、管理装置４を主に示す構成図である。
管理装置４は、コンシステント・ハッシュ法などのＩＤ管理方法に基づいて、クライアントマシン１からのリクエストを複数のサーバ５（クラスタ１００のメンバ）のいずれに振り分けるかを決定するコンピュータ装置である。
管理装置４の記憶部４１には、負荷測定部４１３と、負荷判定部４１４と、スケールアウト部４１５と、リバランシング部４１６とをそれぞれ処理部４２によって動作させるためのプログラムが格納されている。さらに、記憶部４１には、ＩＤ空間管理情報４１１と、設定情報４１２とがプログラムの参照データとして格納されている。

ＩＤ空間管理情報４１１は、管理対象のデータについて所定のハッシュ値変換を行って算出されたＩＤを用いて、そのデータを担当するサーバ５を管理する情報である（図３で後記）。ＩＤ空間管理情報４１１は、通信部４５を介して、負荷分散装置３（または各サーバ５）に配付される。
設定情報４１２は、各処理部（符号４１３〜４１６）の処理において参照される情報であり、入力部４３を介して管理者などにより入力される。
負荷測定部４１３は、各サーバ５から負荷の情報（マシン負荷など）を収集する。

負荷判定部４１４は、負荷測定部４１３の収集結果をもとに、スケールアウトをすべきか否かの判断、および、リバランシングをすべきか否かの判断を行う。
スケールアウト部４１５は、負荷判定部４１４が「スケールアウトをすべき」と判断したときに、クラスタ１００のメンバに新たなサーバ５を追加（増設）する。
リバランシング部４１６は、負荷判定部４１４が「リバランシングをすべき」と判断したときに、クラスタ１００内の既存メンバに対して、サーバ５の役割分担を変更する。
これらのスケールアウト部４１５およびリバランシング部４１６の処理結果は、各サーバ５に指示されるとともに、ＩＤ空間管理情報４１１へと反映される（詳細は、図３，図４）。

図３は、ＩＤ空間管理情報４１１が示すＩＤ空間を示す説明図である。なお、本実施形態では、ＩＤ空間内の各情報を円形で表記したが、計算機に各情報を記憶するときには、ＩＤ空間内の位置を示すＩＤ列と、そのＩＤ位置に配置される要素（サーバ５、データ）列とを対応付ける表形式など、任意のデータ形式で記憶することとしてもよい。

図３（ａ）は、５台のサーバＭ１〜Ｍ５が配置された状態を示す。この「Ｍ１〜Ｍ５」は、クラスタ１００を構成するサーバ５のＩＤ（識別子）を表す。
コンシステント・ハッシュ法では、環状のＩＤ空間に、管理対象の複数のデータ、および、データを管理しクラスタ１００を構成する複数のサーバ５、が割り振られる。
ＩＤ空間内のデータは、低負荷データを示す白丸（○）と、高負荷データを示す黒丸（●）とでそれぞれ示される。ＩＤ空間内のサーバ５は、それぞれサーバＩＤを記載する矩形（Ｍ１〜Ｍ５）で示される。
そして、サーバ５とデータとの役割担当について、ＩＤ空間において自身の前のサーバ５から時計回り（所定方向回り）に自身のサーバ５までの間に位置するデータを管理（担当）する。例えば、Ｍ２のサーバ５は、自身の前であるＭ１のサーバ５の位置（３６０度の円における０度）から、Ｍ２の位置（７０度）までのデータを担当する。

なお、ＩＤ空間内に配置される各サーバ（Ｍ１〜Ｍ５）は、１つのＩＤ空間内のサーバを、１台の物理的にクラスタ１００内に組み込まれるサーバ５（物理計算機）としてもよい。一方、物理的な１台の計算機であるサーバ５を、論理的に複数台に分割した仮想計算機とし、１つのＩＤ空間内のサーバを、１台の仮想計算機と対応付けてもよい。
ここで、物理計算機に対応付けられる仮想計算機の台数は、例えば、物理計算機の性能に比例した台数の仮想計算機を構築するものとする。つまり、管理装置４の処理部４２は、ＩＤ空間管理情報４１１内の各サーバ（Ｍ１〜Ｍ５）について、物理計算機か、仮想計算機かを意識して区別することなく、ＩＤ空間の管理を行う。
もし、ＩＤ空間内の仮想計算機を示すサーバにアクセスする場合は、あらかじめ記憶部４１に登録されている物理計算機と仮想計算機との対応情報を参照することで、アクセスする物理計算機を特定すればよい。このように、物理計算機を仮想的に分割することでＩＤ空間内のサーバ数（領域分割するノード数）を増やすことができ、特定のサーバへの負荷集中の発生確率を低くすることができる。

図３（ｂ）は、図３（ａ）の状態から６台目のサーバＭ６が増設された状態を示す。
スケールアウト部４１５は、最高負荷であるサーバＭ４の担当を緩和するため、サーバＭ４の旧担当領域をＩＤ空間の中間で分割し、その分割位置に新たなサーバＭ６を増設する。
これにより、サーバＭ４の負荷の約半分が新たなサーバＭ６へと移行することにより、サーバＭ４の負荷が軽減される。

図４（ａ）は、図３（ａ）の状態からサーバＭ４の負荷がサーバＭ３へとリバランシングされた状態を示す。
リバランシング部４１６は、最高負荷であるサーバＭ４の負荷を緩和するため、そのサーバＭ４に隣接するサーバＭ３の配置を、サーバＭ３の担当領域が多くなるように時計回りに移動する。
これにより、サーバＭ４の負荷の一部がサーバＭ３へと移行することにより、サーバＭ４の負荷が軽減される。

図４（ｂ）は、図３（ａ）の状態からサーバＭ４の負荷がサーバＭ５へとリバランシングされた状態を示す。
リバランシング部４１６は、最高負荷であるサーバＭ４の負荷を緩和するため、そのサーバＭ４の配置を、担当領域が少なくなるように反時計回りに移動する。
これにより、サーバＭ４の負荷の一部が隣接するサーバＭ５へと移行することにより、サーバＭ４の負荷が軽減される。

図５は、管理装置の処理を示す動作説明図である。
Ｓ１０１は、入力部４３が設定情報４１２の入力を受け付ける処理である。
設定情報４１２は、例えば、負荷測定部４１３や負荷判定部４１４が処理する「負荷」を定義するための情報と、負荷測定部４１３によって測定される負荷と比較される各種閾値（スケールアウト閾値、リバランシング閾値）の情報を含む。

Ｓ１０１のうちの「負荷」を定義するための情報を入力させるために、入力部４３は、以下に例示する各種の定量的なパラメータ値から、参照するパラメータを選択させる。
・各サーバ５のＣＰＵ使用率
・各サーバ５のメモリ使用率
・各サーバ５の担当するデータ（key）へのアクセス頻度
ここで、入力部４３は、選択された各パラメータについて、現在の瞬間値を用いるか、所定期間の統計値（平均値や中央値など）を用いるかを、併せて指定させてもよい。例えば、平均値を用いることで、上下の変動が激しい負荷に対しても、適切な負荷値を取得することができる。

次に、入力部４３は、複数の選択されたパラメータをどのように使用するかを指定させる。つまり、入力部４３は、以下の２つの内のいずれか１つを選択させる。
・複数のパラメータをそれぞれ独立に使用する。つまり、パラメータの個数分だけのＩＤ空間（ＩＤ空間管理情報４１１）を構築する。
・複数のパラメータを組み合わせて（統合させて）１つのパラメータ（負荷代表値）へと集約し、その負荷代表値に対応する１つのＩＤ空間（ＩＤ空間管理情報４１１）を構築する。なお、負荷代表値の計算方法としては、例えば、あらかじめ指定されるパラメータごとの重み値を用いた重みづけ加算により、負荷代表値を求める方法が挙げられる。

Ｓ１０１のうちの入力される各種閾値には、スケールアウトが必要と判断される「スケールアウト閾値」と、リバランシングが必要と判断される「リバランシング閾値」とが存在する。負荷を「ＣＰＵ使用率」と定義したときには、例えば、スケールアウト閾値を「65%」とし、リバランシング閾値を「75%」とする。
スケールアウトが必要な場合とは、クラスタ１００のメンバである各サーバ５のリソースの合計値が不足している状況である。
リバランシングが必要な場合とは、クラスタ１００のメンバである各サーバ５のリソースの合計値は充分だが、負荷が特定のサーバ５に集中することにより、アンバランスな状態である。

なお、リバランシング閾値とスケールアウト閾値とを同じ値（または互いに近い値）とすることにより、クラスタ１００全体でのリソースの余裕を減らす（増設の頻度を下げる）ことで、サーバ５導入のコストパフォーマンスを向上させることができる。
一方、リバランシング閾値よりもスケールアウト閾値を低く設定することにより、クラスタ１００全体でのリソースの余裕が増える（増設の頻度を上げる）ことで、特定拠点が激甚災害でダウンした際にもサービスが継続可能なようになり、信頼性が向上する。
さらに、リバランシング閾値をサーバ５の能力に比べて低めに（例えば、「50%」）設定することで、リバランシングを行う頻度が上がり、特定のサーバ５への負荷集中を予防できる。

Ｓ１０２は、負荷測定部４１３が各サーバ５の負荷を測定する処理である。
負荷測定部４１３は、分散処理システムの運用中に、Ｓ１０１で設定情報４１２として入力された負荷パラメータを各サーバ５から繰り返し（定期または不定期に）取得する。
そして、負荷測定部４１３は、各サーバ５から取得した各種の負荷パラメータを、負荷判定部４１４へと通知する。ここで、負荷測定部４１３は、設定情報４１２に従って、前記した負荷代表値への集約処理や、負荷統計値の計算処理を行い、その計算結果を負荷判定部４１４へと通知してもよい。

ここで、各サーバ５の性能情報をあらかじめ記憶部４１に登録させておき、負荷測定部４１３は、各サーバ５から取得した負荷パラメータの実測値を、登録されている性能情報で補正してから、負荷判定部４１４へと通知してもよい。
例えば、ＣＰＵ性能が「１００」のサーバ５（第１サーバ）からＣＰＵ使用率「２０％」を取得し、ＣＰＵ性能が「１０」のサーバ５（第２サーバ）からＣＰＵ使用率「５０％」を取得したときに、負荷測定部４１３は、以下のいずれかを負荷判定部４１４へと通知する。
・第１サーバの負荷＝「２０％」、第２サーバの負荷＝「５０％」（補正なし）
・第１サーバの負荷＝「１００×２０％＝２０」、第２サーバの負荷＝「１０×５０％＝５」（補正あり）

Ｓ１０３は、負荷判定部４１４がスケールアウトが必要か否かを判定する処理である。
負荷判定部４１４は、Ｓ１０２で測定されたＮ台のサーバ５の負荷合計値が、（スケールアウト閾値×Ｎ）を超過したときに、スケールアウトが必要である（Ｓ１０３，Ｙｅｓ）と判定する。Ｓ１０３でＹｅｓならＳ１０４へ進み、ＮｏならＳ１１１へ進む。
なお、（スケールアウト閾値×Ｎ）とは、スケールアウト閾値に基づくクラスタ１００の負荷基準の一例であり、他の例として、入力された所定値をそのままクラスタ１００の負荷基準として用いてもよい。
例えば、４台のサーバ５の負荷がそれぞれ「７０％，６５％，６５％，６５％」であり、かつ、スケールアウト閾値が「６５％」であるときは、負荷合計値「７０％＋６５％＋６５％＋６５％＝２６５％」＞負荷基準「６５％×４＝２６０％」なので、スケールアウトが必要であると判定される。

Ｓ１０４は、スケールアウト部４１５がスケールアウトを実施する処理である。
スケールアウト部４１５は、待機中のサーバ５をクラスタ１００に増設する場合、その増設するサーバ５のＩＤ空間における挿入位置を、図３（ｂ）で説明したように決定する。
そして、スケールアウト部４１５は、増設したサーバ５の挿入位置と、その挿入位置を元にした各サーバ５の新たな役割分担をＩＤ空間管理情報４１１に対して更新する。なお、Ｓ１０４の処理後は、Ｓ１０２へと戻って、再度負荷が測定される。

なお、Ｓ１０４の処理の変形例として、スケールアウト部４１５は、最も広い区間を挿入位置の区間として決定してもよいし、区間内の挿入位置について、図３（ｂ）のように区間中央でなくても任意の位置としてもよい。例えば、スケールアウト部４１５は、増設するサーバ５のＩＰアドレスに対して所定のハッシュ関数を計算した結果のハッシュ値をＩＤとして、そのＩＤを挿入位置としてもよい。

さらに、スケールアウト部４１５は、１回のスケールアウト（Ｓ１０４）で１台のサーバ５を増設してもよいし、複数台のサーバ５を一度に増設してもよい。例えば、スケールアウト部４１５は、（Ｎ台のサーバ５の負荷合計値）≦（スケールアウト閾値×（Ｎ＋Ｍ）台）となるように、一度に増設するＭ台のサーバ５を決定してもよい。これにより、システム全体のリソース不足を短期間で解消できる。
一方、１回のスケールアウト（Ｓ１０４）で１台ずつサーバ５を増設する場合には、増設のしすぎを予防できる。

Ｓ１１１は、負荷判定部４１４がリバランシングが必要か否かを判定する処理である。
スケールアウトは不要である（Ｓ１０３，Ｎｏ）状況下で、負荷判定部４１４は、クラスタ１００の各サーバ５に対して、（サーバ５の負荷）＞リバランシング閾値となる負荷超過サーバ、つまり、リバランシングを要するサーバであるか否かを判定する。リバランシングを要するサーバが１台でも存在する場合は（Ｓ１１１，Ｙｅｓ）、Ｓ１１２へ進み、存在しない場合は（Ｓ１１１，Ｎｏ）、処理を終了する。
例えば、４台のサーバ５の負荷がそれぞれ「８０％，６０％，５０％，４０％」であり、かつ、リバランシング閾値が「７５％」であるときは、負荷「８０％」のサーバ５だけが、リバランシングを要するサーバ５であると判定される。

Ｓ１１２〜Ｓ１１６は、リバランシング処理のループである。リバランシング部４１６は、ループを１回実行するたびに、１回のリバランシング処理を実施する（Ｓ１１３）。
このループの繰り返し回数は、あらかじめ設定情報４１２として登録されている。繰り返し回数を多くすることで、負荷のアンバランスが平滑化される。繰り返し回数を少なくすることで、負荷移動のオーバーヘッドを抑制する。

Ｓ１１３は、リバランシング部４１６がリバランシングを実施する処理である。
リバランシング部４１６は、負荷超過サーバのうちの負荷が最も高いサーバ５（図３（ａ）では「Ｍ４」）からみて、ＩＤ空間において両隣のサーバ５を特定する（図３（ａ）では「Ｍ３，Ｍ５」）。
そして、リバランシング部４１６は、両隣のサーバ５のうちの現在負荷が少ないほうのサーバ５に対して、今後負荷を増やすようにリバランシングする。
（Ｍ３の負荷）＜（Ｍ５の負荷）なら、リバランシング部４１６は、図４（ａ）で説明したように、負荷の低いＭ３の負荷を増やす。
（Ｍ３の負荷）≧（Ｍ５の負荷）なら、リバランシング部４１６は、図４（ｂ）で説明したように、負荷の低い（または同じ）Ｍ５の負荷を増やす。
このような、負荷の移動は、サーバ５の位置を一度に多く移動させてもよいし、少しずつ移動させて、（サーバ５「Ｍ４」の負荷）＜リバランシング閾値となった時点で移動を終了させてもよい。

Ｓ１１４は、Ｓ１０２と同様に、負荷測定部４１３が各サーバ５の負荷を測定する処理である。ここでは、リバランシング実施後の負荷が測定される。
Ｓ１１５は、負荷判定部４１４がサーバ５の負荷が解消されたか否かを判定する処理である。Ｓ１１１と同様に、負荷判定部４１４は、（Ｓ１１４で測定されたサーバ５の負荷）＞リバランシング閾値となる負荷超過サーバが存在するときには、サーバ負荷が解消されていない（Ｓ１１５，Ｎｏ）として、Ｓ１１６へ進む。一方、負荷超過サーバが存在しないときには（Ｓ１１５，Ｙｅｓ）、ループから脱出して処理を終了する。

なお、Ｓ１１２〜Ｓ１１６のループを実行しても、負荷超過サーバが残る場合も発生する。例えば、４台のサーバ５でクラスタ１００を構築し、それぞれの負荷値が「１００％，５０％，５０％，５０％」である場合、１００％の負荷超過サーバについての負荷をリバランシングしても、負荷移転先の５０％の負荷が１００％へと増加されてしまうだけで、負荷超過サーバの台数が減るわけではない。

このように、負荷が高いデータが複数ハッシュ空間上で近接していて、リバランシングしても分散しきれないようなケースも存在する。このケースでは、Ｓ１０３でスケールアウト不要と判定されたにもかかわらず、Ｓ１１２〜Ｓ１１６のループ後に強制的にＳ１０４でスケールアウトを実施して５台目のサーバ５を増設することで、負荷値を「５０％，５０％，５０％，５０％，５０％」と分散させることができる。
なお、４台のサーバ５の負荷合計値が２５０％であり、スケールアウト閾値「７５％」×４台＝３００％なので、Ｓ１０３ではスケールアウト不要（２５０％＜３００％）となる。

以上説明した本実施形態では、分散システム上でマシン負荷を適切に分散させるリソース管理を行う管理装置４を提案した。管理装置４は、コンシステント・ハッシュ法を用いたＩＤ空間管理情報４１１内に配置するクラスタ１００のサーバ５群について、スケールアウト部４１５によるサーバ増設やリバランシング部４１６によるデータ再配置を制御する。

負荷判定部４１４は、スケールアウトが必要ならスケールアウトを起動し（Ｓ１０３→Ｓ１０４）、スケールアウトが不要でリバランシングが必要ならリバランシングを起動する（Ｓ１１１→Ｓ１１２〜Ｓ１１６）。これにより、サーバ５の増設とリバランシングとを併用することにより、サーバ５の増設をできるだけ抑制したまま、サーバ５間での負荷分散を実現することができる。

つまり、スケールアウトが不要である状況とは、マシンリソースの総量は充分である状況であり、その状況下では、リバランシングがスケールアウトよりも優先されて実施される。よって、使用リソース量を偏りを是正するリバランシングによって効率的に負荷低減を行うことができるので、コストがかかる過剰なサーバ増設を抑止できる。

なお、本実施形態の態様は、前記した構成に限定されるものではない。
例えば、管理装置４と負荷分散装置３を同一のハードウェアに並存させる構成としてもよい。また、負荷分散装置３を使用せず、それぞれのクライアントマシン１が管理装置４から受信したＩＤ空間管理情報４１１を保持して、ネットワーク２経由で複数のサーバ５のいずれかに直接アクセスするようにしてもよい。
また、本実施形態ではコンシステント・ハッシュ法を前提としたが、他の手法を前提としてもよい。
また、本実施形態は、コンピュータを管理装置４として機能させるためのプログラムとしても具現化可能である。

１ クライアントマシン
２ ネットワーク
３ 負荷分散装置
４ 管理装置
５ サーバ
３１ 記憶部
３２ 処理部
３３ 通信部
４１ 記憶部
４２ 処理部
４３ 入力部
４４ 表示部
４５ 通信部
１００ クラスタ
４１１ ＩＤ空間管理情報
４１２ 設定情報
４１３ 負荷測定部
４１４ 負荷判定部
４１５ スケールアウト部
４１６ リバランシング部

Claims (4)

1. スケールアウト閾値およびリバランシング閾値が格納されている記憶手段と、
   クラスタを構成する各サーバの負荷値を取得する負荷測定部と、
   前記取得された各サーバの負荷値の合計が前記スケールアウト閾値に基づく前記クラスタの負荷基準を超過しているときに、前記クラスタへのスケールアウトが必要と判定するとともに、前記取得された各サーバの負荷値が前記リバランシング閾値を超過しているときに、その超過したサーバについてリバランシングが必要と判定する負荷判定部と、
   前記スケールアウトが必要と判定されたときに、前記クラスタを構成するサーバ群に対して新たなサーバを追加することにより、追加前のサーバ群が担当していた負荷の一部を前記新たなサーバに割り当てるスケールアウト処理を実施するスケールアウト部と、
   前記リバランシングが必要と判定されたときに、前記クラスタを構成するサーバ群に対して、前記リバランシング閾値を超過したサーバが担当していた負荷の一部を、前記クラスタを構成する別のサーバに割り当てるリバランシング処理を実施するリバランシング部とを有する管理装置と、
   前記クラスタを構成するサーバ群とがネットワークで接続されて構成され、
   前記記憶手段には、各サーバと各サーバの担当データとを対応付けるデータ構造として、環状のＩＤ空間内に各サーバを示すＩＤと、各担当データを示すＩＤとが配置されているＩＤ空間管理情報が記憶されており、
   前記リバランシング部は、前記リバランシング閾値を超過しているサーバに対して、前記環状のＩＤ空間において隣接する２つのサーバそれぞれの負荷を取得し、それらの取得した負荷の小さいサーバを、負荷の一部の割り当て先となる前記別のサーバとすることを特徴とする
   クラスタシステム。
2. 前記負荷判定部は、
   前記負荷値の合計が前記クラスタの負荷基準を超過しているうちは、前記スケールアウト部にスケールアウト処理を実施させ、
   前記負荷値の合計が前記クラスタの負荷基準を超過しなくなった後に、負荷値が前記リバランシング閾値を超過しているサーバについて、前記リバランシング部にリバランシング処理を実施させることを特徴とする
   請求項１に記載のクラスタシステム。
3. 前記負荷判定部は、負荷値が前記リバランシング閾値を超過しているサーバについて、前記リバランシング部にリバランシング処理を実施させる処理を所定回数実行した後でも、負荷値が前記リバランシング閾値を超過しているサーバが存在するときには、負荷値の合計が前記クラスタの負荷基準を超過していなくても、前記スケールアウト部にスケールアウト処理を実施させることを特徴とする
   請求項２に記載のクラスタシステム。
4. 記憶手段と、負荷測定部と、負荷判定部と、スケールアウト部と、リバランシング部とを有する管理装置、および、クラスタを構成するサーバ群がネットワークで接続されて構成されるクラスタシステムによって実行され、
   前記記憶手段には、スケールアウト閾値およびリバランシング閾値が格納されており、
   前記負荷測定部は、前記クラスタを構成する各サーバの負荷値を取得し、
   前記負荷判定部は、前記取得された各サーバの負荷値の合計が前記スケールアウト閾値に基づく前記クラスタの負荷基準を超過しているときに、前記クラスタへのスケールアウトが必要と判定するとともに、前記取得された各サーバの負荷値が前記リバランシング閾値を超過しているときに、その超過したサーバについてリバランシングが必要と判定し、
   前記スケールアウト部は、前記スケールアウトが必要と判定されたときに、前記クラスタを構成するサーバ群に対して新たなサーバを追加することにより、追加前のサーバ群が担当していた負荷の一部を前記新たなサーバに割り当てるスケールアウト処理を実施し、
   前記リバランシング部は、前記リバランシングが必要と判定されたときに、前記クラスタを構成するサーバ群に対して、前記リバランシング閾値を超過したサーバが担当していた負荷の一部を、前記クラスタを構成する別のサーバに割り当てるリバランシング処理を実施し、
   前記記憶手段には、各サーバと各サーバの担当データとを対応付けるデータ構造として、環状のＩＤ空間内に各サーバを示すＩＤと、各担当データを示すＩＤとが配置されているＩＤ空間管理情報が記憶されており、
   前記リバランシング部は、前記リバランシング閾値を超過しているサーバに対して、前記環状のＩＤ空間において隣接する２つのサーバそれぞれの負荷を取得し、それらの取得した負荷の小さいサーバを、負荷の一部の割り当て先となる前記別のサーバとすることを特徴とする
   負荷分散方法。

Images