JP5997659B2 - 分散処理システムおよび分散処理方法 - Google Patents
分散処理システムおよび分散処理方法 Download PDFInfo
- Publication number
- JP5997659B2 JP5997659B2 JP2013099117A JP2013099117A JP5997659B2 JP 5997659 B2 JP5997659 B2 JP 5997659B2 JP 2013099117 A JP2013099117 A JP 2013099117A JP 2013099117 A JP2013099117 A JP 2013099117A JP 5997659 B2 JP5997659 B2 JP 5997659B2
- Authority
- JP
- Japan
- Prior art keywords
- processing unit
- processing
- information
- unit
- physical server
- 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
Links
Images
Description
本発明は、アプリケーション負荷を物理サーバで構成される物理サーバ群の複数の処理部において、分散処理させる技術分野に属する。
近年、システム規模の拡大やサーバ仮想化技術の普及に伴い、システム全体の調達コストを削減することが課題となっている。特に、サーバ仮想化技術を用いたシステム運用では、クライアントからの処理要求を処理するための処理部（仮想マシン）の数を柔軟に変更することが可能であるため、入力された処理要求の負荷量に応じて、実行する処理部数を調整することにより、使用する処理部数を減らし、物理サーバの台数を削減することができる。
アプリケーション負荷の変動に応じて、実行する処理部数を調整する従来技術として、特許文献１に記載の技術が挙げられる。
特許文献１に記載の技術は、クライアントから入力された処理要求の負荷およびその処理要求を処理するアプリケーションの処理部ごとの負荷を監視することにより処理部の増設判断を行い、必要に応じて処理部の増設を行うスケールアウト方式のシステム構成をとる。しかしながら、特許文献１に記載の技術は、負荷増加時に処理部を増設するのみで、負荷変動に応じた処理部の増減ができないため、リソース使用効率の低下を招く虞がある。
この問題を解決するため、クライアントから入力された処理要求の負荷を監視し、負荷の変動に応じて処理部の増設・減設の双方が可能なスケールアウト方式のシステム構成が考えられる。この場合のシステム構成は、クライアントから入力された処理要求による負荷量を、各処理部に振り分ける前の段階で監視し、監視の結果得られた負荷量に対して、上限・下限閾値を用いたシンプルな処理部の増減設判定基準を設けたものになる。
特許文献１に記載の技術は、クライアントから入力された処理要求の負荷およびその処理要求を処理するアプリケーションの処理部ごとの負荷を監視することにより処理部の増設判断を行い、必要に応じて処理部の増設を行うスケールアウト方式のシステム構成をとる。しかしながら、特許文献１に記載の技術は、負荷増加時に処理部を増設するのみで、負荷変動に応じた処理部の増減ができないため、リソース使用効率の低下を招く虞がある。
この問題を解決するため、クライアントから入力された処理要求の負荷を監視し、負荷の変動に応じて処理部の増設・減設の双方が可能なスケールアウト方式のシステム構成が考えられる。この場合のシステム構成は、クライアントから入力された処理要求による負荷量を、各処理部に振り分ける前の段階で監視し、監視の結果得られた負荷量に対して、上限・下限閾値を用いたシンプルな処理部の増減設判定基準を設けたものになる。
しかしながら、上記のようなシステム構成では、実際に処理要求を各処理部に振り分ける振分部において負荷量の総量の監視が不可能なシステム仕様の場合（例えば、単純なラウンドロビンで振り分けるロードバランサ等を振分部に用いる場合）に適用が困難になる。さらに、上限・下限閾値に基づき増減設を単純に判定するため、各閾値を超える度に処理部の増減設処理を実行することとなり、処理部数の変更や処理部の配置変更に要するオーバヘッドが増加し、システム安定性が損なわれる虞がある。
このような背景に鑑みて本発明がなされたのであり、本発明は、振分部において負荷量の監視が不可能な場合であっても、負荷量に応じて適切な処理部数を設定でき、処理部数の変更に伴うオーバヘッドの増加を抑えシステム安定性を確保できる、分散処理システムおよび分散処理方法を提供することを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、クライアントから受け取った処理要求を、物理サーバに配置された処理部に振り分ける振分装置と、前記振り分けられた処理要求を処理する処理部と、１つ以上の前記処理部を配置する複数の前記物理サーバと、前記振分装置、前記処理部それぞれおよび複数の前記物理サーバに接続され、前記物理サーバに配置される前記処理部の数を調整するリソース調整装置と、を備える分散処理システムであって、前記処理部それぞれが、当該処理部自身の使用リソース量または処理件数を収集する処理部負荷量情報収集部と、収集した前記使用リソース量または前記処理件数を処理部負荷量情報として、前記リソース調整装置に通知する処理部負荷量情報通知部と、を備え、前記リソース調整装置が、（１）前記処理部の追加を判定するための、前記処理部負荷量情報に対する上限閾値および前記上限閾値以上の値が継続する期間を示す第１の継続期間閾値、並びに、（２）前記処理部の削除を判定するための、前記処理部負荷量情報に対する下限閾値および前記下限閾値を下回る値が継続する期間を示す第２の継続期間閾値、が格納される処理部増減判定閾値情報が記憶される記憶部と、前記処理部それぞれから、前記処理部負荷量情報を受信する処理部負荷量情報受信部と、前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第１の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記上限閾値以上である期間が前記第１の継続期間閾値を超える場合に前記処理部の追加条件を満たすと判定すると共に、前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第２の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記下限閾値を下回る期間が前記第２の継続期間閾値を超える場合に前記処理部の削除条件を満たすと判定する処理部増減判定部と、前記処理部の追加条件を満たすと判定された場合に、前記物理サーバに対し処理部を追加するように制御すると共に、前記処理部の削除条件を満たすと判定された場合に、前記物理サーバに対し処理部を削除するように制御する処理部配置実行部と、前記処理部を追加する場合に、当該追加する処理部の情報を含む処理部追加情報を生成し前記振分装置に送信すると共に、前記処理部を削除する場合に、当該削除する処理部の情報を含む処理部削除情報を生成し前記振分装置に送信する処理部追加・削除情報送信部と、を備え、前記振分装置が、前記処理要求の振分先となる前記処理部を示す振分先情報が記憶される記憶部と、前記処理部追加情報に示される前記追加する処理部の情報を前記振分先情報に登録すると共に、前記処理部削除情報に示される前記削除する処理部の情報を前記振分先情報から削除する処理部追加・削除実行部と、受信した前記処理要求を、前記振分先情報を参照して、前記処理部に振り分ける振分処理部と、を備えることを特徴とする分散処理システムとした。
また、請求項４に記載の発明は、クライアントから受け取った処理要求を、物理サーバに配置された処理部に振り分ける振分装置と、前記振り分けられた処理要求を処理する処理部と、１つ以上の前記処理部を配置する複数の前記物理サーバと、前記振分装置、前記処理部それぞれおよび複数の前記物理サーバに接続され、前記物理サーバに配置される前記処理部の数を調整するリソース調整装置と、を備える分散処理システムの分散処理方法であって、前記処理部それぞれが、当該処理部自身の使用リソース量または処理件数を収集するステップと、収集した前記使用リソース量または前記処理件数を処理部負荷量情報として、前記リソース調整装置に通知するステップと、を実行し、前記リソース調整装置が、（１）前記処理部の追加を判定するための、前記処理部負荷量情報に対する上限閾値および前記上限閾値以上の値が継続する期間を示す第１の継続期間閾値、並びに、（２）前記処理部の削除を判定するための、前記処理部負荷量情報に対する下限閾値および前記下限閾値を下回る値が継続する期間を示す第２の継続期間閾値、が格納される処理部増減判定閾値情報が記憶される記憶部を備えており、前記処理部それぞれから、前記処理部負荷量情報を受信するステップと、前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第１の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記上限閾値以上である期間が前記第１の継続期間閾値を超える場合に前記処理部の追加条件を満たすと判定するステップと、前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第２の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記下限閾値を下回る期間が前記第２の継続期間閾値を超える場合に前記処理部の削除条件を満たすと判定するステップと、前記処理部の追加条件を満たすと判定された場合に、前記物理サーバに対し処理部を追加するように制御するステップと、前記処理部の削除条件を満たすと判定された場合に、前記物理サーバに対し処理部を削除するように制御するステップと、前記処理部を追加する場合に、当該追加する処理部の情報を含む処理部追加情報を生成し前記振分装置に送信するステップと、前記処理部を削除する場合に、当該削除する処理部の情報を含む処理部削除情報を生成し前記振分装置に送信するステップと、を実行し、前記振分装置が、前記処理要求の振分先となる前記処理部を示す振分先情報が記憶される記憶部を備えており、前記処理部追加情報に示される前記追加する処理部の情報を前記振分先情報に登録するステップと、前記処理部削除情報に示される前記削除する処理部の情報を前記振分先情報から削除するステップと、受信した前記処理要求を、前記振分先情報を参照して、前記処理部に振り分けるステップと、を実行することを特徴とする分散処理方法とした。
このようにすることにより、分散処理システム（分散処理方法）は、リソース調整装置が、各処理部から受信した処理部負荷量情報に基づき、処理部の追加条件または削除条件を満たすか否かを判定することができる。そして、処理部の追加条件を満たす場合には、リソース調整装置は、物理サーバの処理部を追加した上で、追加する処理部の情報を振分装置に送信し、振分装置がその追加する処理部の情報を振分先情報に登録することができる。また、処理部の削除条件を満たす場合には、リソース調整装置は、削除する処理部の情報を振分装置に送信して振分先情報から削除させ、その削除対象の処理部を物理サーバから削除することができる。
よって、本発明によれば、振分部において負荷量の監視が不可能な場合であっても、処理部の負荷量に応じて適切な処理部数を設定できる。
また、リソース調整装置は、分散処理システムの全処理部のうち所定の割合（第１の所定の割合、第２の所定の割合）以上を占める処理部における、所定の期間（第１の継続期間閾値、第２の継続期間閾値）の処理部負荷量情報に基づき、処理部の追加・削除の判定を行うため、従来技術のように、各閾値を超える度に処理部数を変更する必要がないため、処理部数の変更に伴うオーバヘッドの増加を抑えることができる。
よって、本発明によれば、振分部において負荷量の監視が不可能な場合であっても、処理部の負荷量に応じて適切な処理部数を設定できる。
また、リソース調整装置は、分散処理システムの全処理部のうち所定の割合（第１の所定の割合、第２の所定の割合）以上を占める処理部における、所定の期間（第１の継続期間閾値、第２の継続期間閾値）の処理部負荷量情報に基づき、処理部の追加・削除の判定を行うため、従来技術のように、各閾値を超える度に処理部数を変更する必要がないため、処理部数の変更に伴うオーバヘッドの増加を抑えることができる。
請求項２に記載の発明は、前記振分装置の振分処理部が、前記振分先情報に登録された前記処理部それぞれへの前記処理要求の振分比率を均等に設定したラウンドロビン、または、前記処理部それぞれへの前記処理要求の振分比率を、前記処理部が配置される前記物理サーバの処理能力に応じて設定した重み付けラウンドロビンにより、振分先となる前記処理部を決定すること、を特徴とする請求項１に記載の分散処理システムとした。
このようにすることにより、分散処理システムの振分装置は、ラウンドロビンまたは重み付けラウンドロビンを用いて、振分先となる処理部を決定し、処理要求を振り分けることができる。
請求項３に記載の発明は、クライアントから受け取った処理要求を、物理サーバに配置された処理部に振り分ける振分装置と、前記振り分けられた処理要求を処理する処理部と、１つ以上の前記処理部を配置する複数の前記物理サーバと、前記振分装置、前記処理部それぞれおよび複数の前記物理サーバに接続され、前記物理サーバに配置される前記処理部の数を調整するリソース調整装置と、を備える分散処理システムであって、前記処理部それぞれが、当該処理部自身の使用リソース量または処理件数を収集する処理部負荷量情報収集部と、収集した前記使用リソース量または前記処理件数を処理部負荷量情報として、前記リソース調整装置に通知する処理部負荷量情報通知部と、を備え、前記リソース調整装置が、（１）前記処理部の追加を判定するための、前記処理部負荷量情報に対する上限閾値および前記上限閾値以上の値が継続する期間を示す第１の継続期間閾値、並びに、（２）前記処理部の削除を判定するための、前記処理部負荷量情報に対する下限閾値および前記下限閾値を下回る値が継続する期間を示す第２の継続期間閾値、が格納される処理部増減判定閾値情報が記憶される記憶部と、前記処理部それぞれから、前記処理部負荷量情報を受信する処理部負荷量情報受信部と、前記処理部負荷量情報に基づき、前記使用リソース量または前記処理件数が、前記上限閾値以上である期間が前記第１の継続期間閾値を超える場合に前記処理部の追加条件を満たすと判定すると共に、前記処理部負荷量情報に基づき、前記使用リソース量または前記処理件数が、前記下限閾値を下回る期間が前記第２の継続期間閾値を超える場合に前記処理部の削除条件を満たすと判定する処理部増減判定部と、前記処理部の追加条件を満たすと判定された場合に、前記物理サーバに対し処理部を追加するように制御すると共に、前記処理部の削除条件を満たすと判定された場合に、前記物理サーバに対し処理部を削除するように制御する処理部配置実行部と、前記処理部を追加する場合に、当該追加する処理部の情報を含む処理部追加情報を生成し前記振分装置に送信すると共に、前記処理部を削除する場合に、当該削除する処理部の情報を含む処理部削除情報を生成し前記振分装置に送信する処理部追加・削除情報送信部と、を備え、前記振分装置が、前記処理要求の振分先となる前記処理部を示す振分先情報が記憶される記憶部と、前記処理部追加情報に示される前記追加する処理部の情報を前記振分先情報に登録すると共に、前記処理部削除情報に示される前記削除する処理部の情報を前記振分先情報から削除する処理部追加・削除実行部と、受信した前記処理要求を、前記振分先情報を参照して、前記処理部に振り分ける振分処理部と、を備え、前記処理部が、前記物理サーバ上に配置される仮想マシンで構成されており、前記物理サーバが、前記処理要求に対する処理を実行する処理部を配置する稼働中の前記物理サーバと、前記処理要求を受け付けない待機状態の前記処理部を配置するリソースプール用の前記物理サーバとで構成されており、前記物理サーバそれぞれが、当該物理サーバ自身の使用リソース量を収集する物理サーバリソース情報収集部と、収集した前記使用リソース量を物理サーバリソース情報として、前記リソース調整装置に通知する物理サーバリソース情報通知部と、備え、前記リソース調整装置が、前記記憶部にさらに、前記処理要求を処理するためのアプリケーションを実行する予定の期間を示す処理スケジュールを前記処理部ごとに示す処理スケジュール情報と、前記処理部とその処理部が配置されている前記物理サーバとを関連付けた情報である処理部配置情報と、前記物理サーバの使用リソース量に対する上限閾値および前記処理スケジュール情報を用いて算出される前記物理サーバの使用予定リソース量に対する上限閾値が格納される物理サーバ選定閾値情報と、が記憶されており、前記物理サーバそれぞれから、前記物理サーバリソース情報を受信する物理サーバリソース情報受信部と、前記処理部増減判定部が、前記処理部の追加条件を満たすと判定した場合に、前記物理サーバそれぞれについて、当該物理サーバに配置されているすべての前記処理部を前記処理部配置情報に基づき抽出し、前記抽出した前記処理部それぞれの使用予定リソース量を前記処理スケジュール情報を用いて算出し、算出した前記処理部ごとの前記使用予定リソース量を合計して、前記物理サーバごとの使用予定リソース量を算出し、当該算出した使用予定リソース量が、前記物理サーバの使用予定リソース量に対する上限閾値を超えず、かつ、前記物理サーバから受信した前記物理サーバリソース情報に示される前記使用リソース量が、前記物理サーバの使用リソース量に対する上限閾値を超えない物理サーバを選定し、前記選定した物理サーバの中から、前記処理部を追加する配置先の物理サーバを決定すると共に、前記処理部増減判定部が、前記処理部の削除条件を満たすと判定した場合に、前記削除条件を満たす処理部の中から削除対象となる処理部を決定する配置先物理サーバ決定部と、をさらに備え、前記処理部配置実行部が、前記処理部増減判定部が、前記処理部の追加条件を満たすと判定した場合に、前記リソースプール用の物理サーバに配置された処理部を、前記配置先物理サーバ決定部が決定した前記配置先の物理サーバに移動させるように制御すると共に、前記処理部増減判定部が、前記処理部の削除条件を満たすと判定した場合に、前記削除対象となる処理部を、前記リソースプール用の物理サーバに移動させるように制御すること、を特徴とする分散処理システムとした。
このように、分散処理システムは、処理部を仮想マシンで構成し、物理サーバを、処理要求に対する処理を実行する処理部を配置する稼働中の物理サーバと、待機状態の処理部を配置するリソースプール用の物理サーバとで構成する。これにより、リソース調整装置は、処理部の追加条件を満たすと判定した場合に、リソースプール用の物理サーバに配置された処理部を、配置先の物理サーバに移動させることができる。また、リソース調整装置は、処理部の削除条件を満たすと判定された場合に、削除対象の処理部を、稼働中の物理サーバからリソースプール用の物理サーバに移動させることができる。よって、処理部の増減を柔軟に実行することができる。
また、リソース調整装置は、各物理サーバから受信した物理サーバリソース情報と、物理サーバごとの使用予定リソース量とを用いて、追加する処理部のより適切な配置先となる物理サーバを決定することができる。
また、リソース調整装置は、各物理サーバから受信した物理サーバリソース情報と、物理サーバごとの使用予定リソース量とを用いて、追加する処理部のより適切な配置先となる物理サーバを決定することができる。
本発明によれば、振分部において負荷量の監視が不可能な場合であっても、負荷量に応じて適切な処理部数を設定でき、処理部数の変更に伴うオーバヘッドの増加を抑えシステム安定性を確保できる、分散処理システムおよび分散処理方法を提供することができる。
次に、本発明を実施するための形態（以下、「本実施形態」という）における分散処理システム１等について説明する。
＜システム構成と処理概要＞
最初に、図１を参照して、本実施形態に係る分散処理システム１の構成と処理概要について説明する。
本実施形態に係る分散処理システム１は、分散処理を行う各処理部２０の負荷量を所定の期間（所定の時間間隔ごとに）監視し、負荷量の変動に応じて処理部２０の数を柔軟に変更可能なスケールアウト型の分散処理システムである。
最初に、図１を参照して、本実施形態に係る分散処理システム１の構成と処理概要について説明する。
本実施形態に係る分散処理システム１は、分散処理を行う各処理部２０の負荷量を所定の期間（所定の時間間隔ごとに）監視し、負荷量の変動に応じて処理部２０の数を柔軟に変更可能なスケールアウト型の分散処理システムである。
本実施形態に係る分散処理システム１は、図１に示すように、クライアント５からの処理要求を処理部２０に振り分ける振分装置１０と、複数の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）上に設けられ、振分装置１０により振り分けられた処理要求の処理を実行し、その応答情報をクライアント５に返信する複数の処理部２０（２０ａ，２０ｂ，２０ｃ，…）と、クライアント５からの処理の実行に伴う負荷量に応じて、処理部２０の数の増減と、物理サーバ３０上での各処理部２０の配置場所とを決定するリソース調整装置４０とを備える。
各処理部２０（２０ａ，２０ｂ，２０ｃ，…）は、仮想マシンで構成され、任意の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）上に配置される。なお、１つの物理サーバ３０上に複数の処理部２０（仮想マシン）を備えてもよい。また、ある物理サーバ３０上に配置された処理部２０（仮想マシン）を、仮想化技術を用いて、別の物理サーバ３０上に移動することもできる。
リソース調整装置４０は、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）の負荷量情報（後記する「処理部負荷量情報」を示し、例えば、使用リソース量や処理件数）に基づき、処理部２０の数を調整（処理部２０の追加・削除）すると共に、各物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）の負荷量情報（後記する「物理サーバリソース情報」）に基づき、各処理部２０の配置先となる物理サーバ３０を決定する。この物理サーバ３０は、処理部２０が配置され処理要求に対する処理を実行する稼動状態の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）と、処理要求を受け付けない待機状態の処理部２０（図示省略）が配置されるリソースプール用の物理サーバ３０（３０Ｐ）の２種類で構成される。
リソース調整装置４０は、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）の負荷量情報（後記する「処理部負荷量情報」を示し、例えば、使用リソース量や処理件数）に基づき、処理部２０の数を調整（処理部２０の追加・削除）すると共に、各物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）の負荷量情報（後記する「物理サーバリソース情報」）に基づき、各処理部２０の配置先となる物理サーバ３０を決定する。この物理サーバ３０は、処理部２０が配置され処理要求に対する処理を実行する稼動状態の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）と、処理要求を受け付けない待機状態の処理部２０（図示省略）が配置されるリソースプール用の物理サーバ３０（３０Ｐ）の２種類で構成される。
リソース調整装置４０は、各処理部２０の負荷量情報（処理部負荷量情報）に基づき、処理部２０の追加が必要と判定したときは、新たに追加する処理部２０の配置先となる物理サーバ３０を決定し、その追加する処理部２０をリソースプール用の物理サーバ３０（３０Ｐ）から決定した配置先の物理サーバ３０に移動させる。その後、リソース調整装置４０から振分装置１０に新たに追加された処理部２０に関する情報（後記する「処理部追加情報」）を送信し、振分装置１０が、クライアント５からの処理要求の振り分け先となる各処理部２０が登録された振分先情報１３１に、追加した処理部２０を登録する。
また、リソース調整装置４０は、各処理部２０の負荷量情報（処理部負荷量情報）に基づき、処理部２０の削除が必要と判定したときは、削除対象となる処理部２０に関する情報（後記する「処理部削除情報」）を振分装置１０へ送信し、振分装置１０が、振分先情報１３１から削除対象となる処理部２０を削除する。その後、リソース調整装置４０は、削除対象となる処理部２０をリソースプール用の物理サーバ３０（３０Ｐ）に移動させる。
また、リソース調整装置４０は、各処理部２０の負荷量情報（処理部負荷量情報）に基づき、処理部２０の削除が必要と判定したときは、削除対象となる処理部２０に関する情報（後記する「処理部削除情報」）を振分装置１０へ送信し、振分装置１０が、振分先情報１３１から削除対象となる処理部２０を削除する。その後、リソース調整装置４０は、削除対象となる処理部２０をリソースプール用の物理サーバ３０（３０Ｐ）に移動させる。
このようにすることで、本実施形態に係る分散処理システム１は、各処理部２０の負荷量に応じて適切な処理部２０の数を調整できる。また、分散処理システム１は、処理部２０の追加または削除が必要か否かの判定を、所定の期間毎に行う。よって、処理部数の変更に伴うオーバヘッドの増加を抑え、システム安定性を確保することができる。
＜各装置等の構成＞
次に、本実施形態に係る分散処理システム１を構成する、振分装置１０、処理部２０、物理サーバ３０およびリソース調整装置４０について、具体的に説明する。
次に、本実施形態に係る分散処理システム１を構成する、振分装置１０、処理部２０、物理サーバ３０およびリソース調整装置４０について、具体的に説明する。
≪物理サーバ３０および処理部２０≫
まず、本実施形態に係る物理サーバ３０および処理部２０の構成例について説明する。
図２は、本実施形態に係る物理サーバ３０および処理部２０の構成例を示すブロック図である。物理サーバ３０は、仮想化技術を適用して複数の処理部２０（仮想マシン）を配置し、その処理部２０がクライアント５からの処理要求に対する処理を実行する。なお、本実施形態においては、１つの処理部２０（仮想マシン）が、１つのアプリケーションを実行するものとして説明する。
まず、本実施形態に係る物理サーバ３０および処理部２０の構成例について説明する。
図２は、本実施形態に係る物理サーバ３０および処理部２０の構成例を示すブロック図である。物理サーバ３０は、仮想化技術を適用して複数の処理部２０（仮想マシン）を配置し、その処理部２０がクライアント５からの処理要求に対する処理を実行する。なお、本実施形態においては、１つの処理部２０（仮想マシン）が、１つのアプリケーションを実行するものとして説明する。
物理サーバ３０は、図示を省略した制御部、入出力部および記憶部を備える装置である。この制御部は、図２に示すように、仮想化制御部３１、物理サーバリソース情報収集部３２および物理サーバリソース情報通知部３３を備える。
仮想化制御部３１は、仮想化技術に基づき、物理サーバ３０上に仮想化プラットホームを構築し、複数の処理部２０（仮想マシン）を配置する制御を行う。
物理サーバリソース情報収集部３２は、物理サーバ３０自身の各種のリソース使用量（ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ（Input/Output）量、ネットワークＩ／Ｏ量等）を物理サーバリソース情報として収集する。なお、物理サーバリソース情報収集部３２は、ＣＰＵ（Central Processing Unit）使用率、メモリ使用率、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量のうち少なくとも１つを物理サーバリソース情報として、所定の時間間隔で収集する。
物理サーバリソース情報通知部３３は、物理サーバリソース情報収集部３２が所定の時間間隔で収集した物理サーバリソース情報を、入出力部（図示省略）を介して、リソース調整装置４０に通知する。
処理部２０は、物理サーバ３０の仮想化制御部３１により物理サーバ３０上に配置される仮想マシンであり、図２に示すように、アプリケーション処理部２１、処理部負荷量情報収集部２２および処理部負荷量情報通知部２３を備える。
アプリケーション処理部２１は、クライアント５から振分装置１０を介して取得した処理要求を受け取り、アプリケーションに従い処理を実行し、その結果をクライアント５に応答情報として送信する。
処理部負荷量情報収集部２２は、処理部２０（仮想サーバ）ごとに自身の負荷量情報（処理部負荷量情報）を収集する。ここで処理部負荷量情報とは、使用リソース量や処理件数である。処理部負荷量情報収集部２２は、使用リソース量として、ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量のうち少なくもと１つを収集する。または、処理部負荷量情報収集部２２は、クライアント５から受け取った処理要求を処理した数である処理件数（処理件数／単位時間）を収集する。処理部負荷量情報収集部２２は、自身の処理部負荷量情報として予め設定された、各種の使用リソース量のいずれか、または、処理件数を処理部負荷量情報として、所定の時間間隔で収集する。
処理部負荷量情報通知部２３は、処理部負荷量情報収集部２２が所定の時間間隔で収集した処理部負荷量情報を、リソース調整装置４０に通知する。
≪リソース調整装置４０≫
次に、本実施形態に係るリソース調整装置４０の構成例について説明する。
図３は、本実施形態に係るリソース調整装置４０の構成例を示す機能ブロック図である。
リソース調整装置４０は、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）から取得した処理部負荷量情報（使用リソース量または処理件数）に基づき、処理部２０の数を増減するか否かを判定する。そして、リソース調整装置４０は、処理部２０の追加が必要と判定したときは、リソースプール用の物理サーバ３０（３０Ｐ）から新たな処理部２０を配置先となる物理サーバ３０に移動させ、その追加する処理部２０の情報を、振分装置１０に送信する。また、リソース調整装置４０は、処理部２０の削除が必要と判定したときは、削除対象の処理部２０の情報を振分装置１０の送信し、その削除対象の処理部２０をリソースプール用の物理サーバ３０（３０Ｐ）に移動させる。
このリソース調整装置４０は、図３に示すように、制御部４１と、入出力部４２と、記憶部４３とを含んで構成される。
次に、本実施形態に係るリソース調整装置４０の構成例について説明する。
図３は、本実施形態に係るリソース調整装置４０の構成例を示す機能ブロック図である。
リソース調整装置４０は、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）から取得した処理部負荷量情報（使用リソース量または処理件数）に基づき、処理部２０の数を増減するか否かを判定する。そして、リソース調整装置４０は、処理部２０の追加が必要と判定したときは、リソースプール用の物理サーバ３０（３０Ｐ）から新たな処理部２０を配置先となる物理サーバ３０に移動させ、その追加する処理部２０の情報を、振分装置１０に送信する。また、リソース調整装置４０は、処理部２０の削除が必要と判定したときは、削除対象の処理部２０の情報を振分装置１０の送信し、その削除対象の処理部２０をリソースプール用の物理サーバ３０（３０Ｐ）に移動させる。
このリソース調整装置４０は、図３に示すように、制御部４１と、入出力部４２と、記憶部４３とを含んで構成される。
入出力部４２は、振分装置１０や、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）、各物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…，３０Ｐ）等との間の情報の入出力を行う。また、この入出力部４２は、通信回線を介して情報の送受信を行う通信インタフェースと、図示を省略したキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
制御部４１は、リソース調整装置４０全体の制御を司り、処理部負荷量情報受信部４１１、物理サーバリソース情報受信部４１２、処理部増減判定部４１３、配置先物理サーバ決定部４１４、処理部配置実行部４１５および処理部追加・削除情報送信部４１６を含んで構成される。
なお、この制御部４１は、例えば、記憶部４３に格納されたプログラムを、図示を省略したＣＰＵがＲＡＭ（Random Access Memory）に展開し実行することで実現される。
なお、この制御部４１は、例えば、記憶部４３に格納されたプログラムを、図示を省略したＣＰＵがＲＡＭ（Random Access Memory）に展開し実行することで実現される。
処理部負荷量情報受信部４１１は、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）が送信した処理部負荷量情報（使用リソース量または処理件数）を受信し、記憶部４３に記憶する。なお、記憶部４３に記憶された処理部負荷量情報４３１は、処理部増減判定部４１３による後記する処理部増減判定処理の際に参照される。
物理サーバリソース情報受信部４１２は、各物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）が送信した物理サーバリソース情報（使用リソース量等）を受信し、記憶部４３に記憶する。なお、記憶部４３に記憶された物理サーバリソース情報４３２は、配置先物理サーバ決定部４１４による後記する配置先物理サーバ決定処理の際に参照される。
処理部増減判定部４１３は、処理部負荷量情報受信部４１１が受信した処理部負荷量情報４３１（使用リソース量または処理件数）に基づき、処理部２０の増減（追加または削除）を判定する。なお、処理部増減判定部４１３は、所定の時間間隔毎に受信した処理部負荷量情報４３１を集積した後記する所定期間（判定に用いる継続期間閾値）を超える間隔で、処理部増減判定処理を実行する。
以下具体的に、処理部増減判定部４１３が、処理部負荷量情報として、（１）使用リソース量（ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量のいずれか）を用いる場合と、（２）処理件数を用いる場合と、において実行する処理部増減判定処理について説明する。
以下具体的に、処理部増減判定部４１３が、処理部負荷量情報として、（１）使用リソース量（ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量のいずれか）を用いる場合と、（２）処理件数を用いる場合と、において実行する処理部増減判定処理について説明する。
（各処理部２０の使用リソース量に基づく処理部増減判定処理）
〔処理部の追加時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ａ１％以上の数の処理部２０がいずれかの使用リソース量の上限閾値ｂ１を継続して所定期間ｃ１（第１の継続期間閾値）超過するときに（ここまでを「第１の追加条件」と呼ぶ。）、処理部２０の数を所定の割合ｄ１％追加する。
〔処理部の削減時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ｅ１％以上の数の処理部２０が予め設定したすべての種類のリソース使用量において、そのリソース使用量の下限閾値ｆ１を継続して所定期間ｇ１（第２の継続期間閾値）下回るときに（ここまでを「第１の削除条件」と呼ぶ。）、処理部２０の数を所定の割合ｈ１％削減する。
〔処理部の追加時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ａ１％以上の数の処理部２０がいずれかの使用リソース量の上限閾値ｂ１を継続して所定期間ｃ１（第１の継続期間閾値）超過するときに（ここまでを「第１の追加条件」と呼ぶ。）、処理部２０の数を所定の割合ｄ１％追加する。
〔処理部の削減時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ｅ１％以上の数の処理部２０が予め設定したすべての種類のリソース使用量において、そのリソース使用量の下限閾値ｆ１を継続して所定期間ｇ１（第２の継続期間閾値）下回るときに（ここまでを「第１の削除条件」と呼ぶ。）、処理部２０の数を所定の割合ｈ１％削減する。
（各処理部２０の処理件数に基づく処理部増減判定処理）
〔処理部の追加時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ａ２％以上の数の処理部２０が処理件数（処理件数／単位時間）の上限閾値ｂ２を継続して所定期間ｃ２（第１の継続期間閾値）超過するときに（ここまでを「第２の追加条件」と呼ぶ。）、処理部２０の数を所定の割合ｄ２％追加する。
〔処理部の削減時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ｅ２％以上の数の処理部２０が、処理件数（処理件数／単位時間）の下限閾値ｆ２を継続して所定期間ｇ２（第２の継続期間閾値）下回るときに（ここまでを「第２の削除条件」と呼ぶ。）、処理部２０の数を所定の割合ｈ２％削減する。
〔処理部の追加時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ａ２％以上の数の処理部２０が処理件数（処理件数／単位時間）の上限閾値ｂ２を継続して所定期間ｃ２（第１の継続期間閾値）超過するときに（ここまでを「第２の追加条件」と呼ぶ。）、処理部２０の数を所定の割合ｄ２％追加する。
〔処理部の削減時〕
処理部増減判定部４１３は、処理部２０の全体数をＮ台としたとき、所定の割合ｅ２％以上の数の処理部２０が、処理件数（処理件数／単位時間）の下限閾値ｆ２を継続して所定期間ｇ２（第２の継続期間閾値）下回るときに（ここまでを「第２の削除条件」と呼ぶ。）、処理部２０の数を所定の割合ｈ２％削減する。
処理部増減判定部４１３は、以上説明した処理部の追加条件（「第１の追加条件」または「第２の追加条件」）と削除条件（「第１の削除条件」または「第２の削除条件」）に基づき、処理部２０の増減（追加・削除）を判定する。なお、処理部増減判定部４１３は、追加条件または削除条件のいずれも満たさない場合は、処理部２０の数を変更しないものと判定する。
なお、処理部増減判定部４１３が処理部増減判定に用いる各閾値や所定期間の情報は、記憶部４３内の処理部増減判定閾値情報４３６に予め記憶される。
なお、処理部増減判定部４１３が処理部増減判定に用いる各閾値や所定期間の情報は、記憶部４３内の処理部増減判定閾値情報４３６に予め記憶される。
また、処理部増減判定部４１３は、「第１の追加条件」を満足すると判定した場合に、「処理部の数を所定の割合ｄ１％追加する」処理を実行するが、例えば、処理部２０の全体数をＮ台＝５０台とし、所定の割合ｄ１％＝３％とした場合に、追加する処理部２０の台数は、５０×０．０３＝１．５台となる。このような場合は、小数点以下を切り上げ２台追加するようにロジックを設定しておく。「第２の追加条件」の場合も同様である。
一方、処理部増減判定部４１３は、「第１の削除条件」を満足すると判定した場合に、「処理部の数を所定の割合ｈ１％削減する」処理を実行するが、例えば、処理部２０の全体数をＮ台＝５０台とし、所定の割合ｈ１％＝３％とした場合に、削除する処理部２０の台数は、５０×０．０３＝１．５台となる。このような場合は、小数点以下を切り捨て１台削除するようにロジックを設定しておく。「第２の削除条件」の場合も同様である。
一方、処理部増減判定部４１３は、「第１の削除条件」を満足すると判定した場合に、「処理部の数を所定の割合ｈ１％削減する」処理を実行するが、例えば、処理部２０の全体数をＮ台＝５０台とし、所定の割合ｈ１％＝３％とした場合に、削除する処理部２０の台数は、５０×０．０３＝１．５台となる。このような場合は、小数点以下を切り捨て１台削除するようにロジックを設定しておく。「第２の削除条件」の場合も同様である。
配置先物理サーバ決定部４１４は、処理部増減判定部４１３が処理部２０の追加条件を満たすと判定した場合に、どの物理サーバ３０に処理部２０を追加するのかを決定する。また、配置先物理サーバ決定部４１４は、処理部増減判定部４１３が処理部２０の削除条件を満たすと判定した場合に、どの処理部２０を削除対象の処理部２０をするのかを決定する。
（処理部２０の追加時の配置先物理サーバ決定処理）
まず、配置先物理サーバ決定部４１４による、処理部２０の追加時の配置先物理サーバ決定処理について説明する。
処理部増減判定部４１３が処理部２０の追加条件を満たすと判定したとき、配置先物理サーバ決定部４１４は、リソースプール用の物理サーバ３０（３０Ｐ）から、処理部増減判定部４１３が決定した追加する数の処理部２０の配置先となる物理サーバ３０を、以下の物理サーバ選定基準を満たす物理サーバ３０の中から決定する。
まず、配置先物理サーバ決定部４１４による、処理部２０の追加時の配置先物理サーバ決定処理について説明する。
処理部増減判定部４１３が処理部２０の追加条件を満たすと判定したとき、配置先物理サーバ決定部４１４は、リソースプール用の物理サーバ３０（３０Ｐ）から、処理部増減判定部４１３が決定した追加する数の処理部２０の配置先となる物理サーバ３０を、以下の物理サーバ選定基準を満たす物理サーバ３０の中から決定する。
〔物理サーバ選定基準〕
現在稼働中の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）について、物理サーバリソース情報受信部４１２が受信した物理サーバリソース情報４３２を参照し、各種の使用リソース量（ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量のうち予め設定したもののすべて）が、各種の使用リソース量ごとに設定される上限閾値ｘを超過せず、かつ、今後所定の期間継続して物理サーバ３０の使用予定リソース量が上限閾値ｙを超過しない物理サーバを選定する。
なお、各種の使用リソース量ごとの上限閾値ｘおよび物理サーバ３０の使用予定リソース量の上限閾値ｙは、リソース調整装置４０の記憶部４３に物理サーバ選定閾値情報４３７として予め記憶される。
現在稼働中の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）について、物理サーバリソース情報受信部４１２が受信した物理サーバリソース情報４３２を参照し、各種の使用リソース量（ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏ量、ネットワークＩ／Ｏ量のうち予め設定したもののすべて）が、各種の使用リソース量ごとに設定される上限閾値ｘを超過せず、かつ、今後所定の期間継続して物理サーバ３０の使用予定リソース量が上限閾値ｙを超過しない物理サーバを選定する。
なお、各種の使用リソース量ごとの上限閾値ｘおよび物理サーバ３０の使用予定リソース量の上限閾値ｙは、リソース調整装置４０の記憶部４３に物理サーバ選定閾値情報４３７として予め記憶される。
上記の物理サーバ選定基準のうち、物理サーバ３０の使用予定リソース量とは、各物理サーバ３０に配置済みの処理部２０（仮想マシン）の使用予定リソース量の和で計算される。リソース調整装置４０の記憶部４３には、この物理サーバ３０の使用予定リソース量を算出するための情報として、処理スケジュール情報４３３、処理部使用予定リソース情報４３４、処理部配置情報４３５が記憶される。
図４は、本実施形態に係る処理スケジュール情報４３３のデータ構成の一例を示す図である。
図４に示すように、処理スケジュール情報４３３には、各アプリケーションを実行する処理部２０に対応付けて、そのアプリケーションによる処理が発生する予定の期間（処理発生期間）が処理スケジュールとして記憶される。
図４に示すように、処理スケジュール情報４３３には、各アプリケーションを実行する処理部２０に対応付けて、そのアプリケーションによる処理が発生する予定の期間（処理発生期間）が処理スケジュールとして記憶される。
図５は、本実施形態に係る処理部使用予定リソース情報４３４のデータ構成の一例を示す図である。
図５に示すように、処理部使用予定リソース情報４３４には、各処理部２０が実行するアプリケーションの種類に応じて、使用を予定するリソース量（使用予定リソース量）が格納される。
なお、配置先物理サーバ決定部４１４は、図４の処理スケジュール情報４３３において、ある処理部２０の処理スケジュールが記憶されていない場合には、例えば、所定期間内すべてにおいて処理部使用予定リソース情報４３４に基づく所定のリソース量を使用するものと仮定して、その処理部２０の使用予定リソース量を計算する。
図５に示すように、処理部使用予定リソース情報４３４には、各処理部２０が実行するアプリケーションの種類に応じて、使用を予定するリソース量（使用予定リソース量）が格納される。
なお、配置先物理サーバ決定部４１４は、図４の処理スケジュール情報４３３において、ある処理部２０の処理スケジュールが記憶されていない場合には、例えば、所定期間内すべてにおいて処理部使用予定リソース情報４３４に基づく所定のリソース量を使用するものと仮定して、その処理部２０の使用予定リソース量を計算する。
図６は、本実施形態に係る処理部配置情報４３５のデータ構成の一例を示す図である。
この処理部配置情報４３５は、処理部２０とその処理部２０が配置されている物理サーバ３０とを関連付けた情報である。
この処理部配置情報４３５は、処理部２０とその処理部２０が配置されている物理サーバ３０とを関連付けた情報である。
配置先物理サーバ決定部４１４（図３参照）は、物理サーバ３０それぞれについて、その物理サーバ３０に配置されているすべての処理部２０を処理部配置情報４３５に基づき抽出し、抽出した各処理部２０の使用予定リソース量の和を処理スケジュール情報４３３（図４参照）および処理部使用予定リソース情報４３４（図５参照）に基づき算出して、物理サーバ３０毎の使用予定リソース量を計算する。そして配置先物理サーバ決定部４１４は、その計算した物理サーバ３０の使用予定リソース量と上限閾値ｙとを比較する。
なお、配置先物理サーバ決定部４１４は、物理サーバ選定基準を満たす物理サーバ３０が、追加の決定をした物理サーバ３０の数より多く選定された場合には、物理サーバ選定基準を満たす物理サーバ３０の中から任意の物理サーバ３０を選定するようにする。
（処理部２０の削除時の削除対象の処理部２０の決定処理）
次に、配置先物理サーバ決定部４１４による、処理部２０の削除時の削除対象の処理部２０の決定処理について説明する。
処理部増減判定部４１３が、処理部２０の削除条件を満たすと判定したとき、配置先物理サーバ決定部４１４は、その削除条件を満たす処理部２０の中から、削除する処理部２０の数だけ任意の処理部２０を選定し、削除対象の処理部２０と決定する。なお、配置先物理サーバ決定部４１４は、処理部２０の削除条件を満たす処理部２０のうち、リソース使用量が低いものから順に、または、処理件数が少ないものから順に、削除する処理部の数だけ処理部２０を決定するようにしてもよい。
次に、配置先物理サーバ決定部４１４による、処理部２０の削除時の削除対象の処理部２０の決定処理について説明する。
処理部増減判定部４１３が、処理部２０の削除条件を満たすと判定したとき、配置先物理サーバ決定部４１４は、その削除条件を満たす処理部２０の中から、削除する処理部２０の数だけ任意の処理部２０を選定し、削除対象の処理部２０と決定する。なお、配置先物理サーバ決定部４１４は、処理部２０の削除条件を満たす処理部２０のうち、リソース使用量が低いものから順に、または、処理件数が少ないものから順に、削除する処理部の数だけ処理部２０を決定するようにしてもよい。
処理部配置実行部４１５は、処理部２０の追加時において、リソースプール用の物理サーバ３０（３０Ｐ）が備える処理部２０を、配置先物理サーバ決定部４１４が決定した新たに追加する処理部２０の配置先の物理サーバ３０に移動するように、リソースプール用の物理サーバ３０（３０Ｐ）および配置先の物理サーバ３０を制御する。このとき、処理部配置実行部４１５は、新たに追加する処理部２０の配置を完了すると、処理部配置情報４３５を更新する。
また、処理部配置実行部４１５は、処理部２０の削除時において、削除対象の処理部２０をその物理サーバ３０からリソースプール用の物理サーバ３０（３０Ｐ）へ移動させる制御を行う。このとき、処理部配置実行部４１５は、削除対象の処理部２０のリソースプール用の物理サーバ３０（３０Ｐ）への移動を完了すると、処理部配置情報４３５を更新する。
また、処理部配置実行部４１５は、処理部２０の削除時において、削除対象の処理部２０をその物理サーバ３０からリソースプール用の物理サーバ３０（３０Ｐ）へ移動させる制御を行う。このとき、処理部配置実行部４１５は、削除対象の処理部２０のリソースプール用の物理サーバ３０（３０Ｐ）への移動を完了すると、処理部配置情報４３５を更新する。
処理部追加・削除情報送信部４１６は、追加された処理部２０の情報（処理部２０の識別情報やアドレス等）を処理部追加情報として、入出力部４２を介して、振分装置１０へ送信する。また、処理部追加・削除情報送信部４１６は、削除された処理部２０の情報（処理部２０の識別情報等）を処理部削除情報として、入出力部４２を介して、振分装置１０へ送信する。
記憶部４３は、ハードディスクやフラッシュメモリ、ＲＡＭ等の記憶手段からなり、前記した、処理部負荷量情報４３１や、物理サーバリソース情報４３２、処理スケジュール情報４３３、処理部使用予定リソース情報４３４、処理部配置情報４３５、処理部増減判定閾値情報４３６、物理サーバ選定閾値情報４３７等が記憶される。
≪振分装置１０≫
次に、本実施形態に係る振分装置１０の構成例について説明する。
図７は、本実施形態に係る振分装置１０の構成例を示す機能ブロック図である。
振分装置１０は、クライアント５から受信した処理要求を、所定の方式にしたがい各処理部２０に振り分ける。また、振分装置１０は、処理部２０から受信した応答情報を、処理要求を送信したクライアント５に返信する装置である。
この振分装置１０は、図７に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。
次に、本実施形態に係る振分装置１０の構成例について説明する。
図７は、本実施形態に係る振分装置１０の構成例を示す機能ブロック図である。
振分装置１０は、クライアント５から受信した処理要求を、所定の方式にしたがい各処理部２０に振り分ける。また、振分装置１０は、処理部２０から受信した応答情報を、処理要求を送信したクライアント５に返信する装置である。
この振分装置１０は、図７に示すように、制御部１１と、入出力部１２と、記憶部１３とを含んで構成される。
入出力部１２は、各処理部２０や、リソース調整装置４０等との間の情報の入出力を行う。また、この入出力部１２は、通信回線を介して情報の送受信を行う通信インタフェースと、図示を省略したキーボード等の入力手段やモニタ等の出力手段等との間で入出力を行う入出力インタフェースとから構成される。
制御部１１は、振分装置１０全体の制御を司り、振分方式設定部１１１、処理部追加・削除情報受信部１１２、処理部追加・削除実行部１１３および振分処理部１１４を含んで構成される。
なお、この制御部１１は、例えば、記憶部１３に格納されたプログラムを、図示を省略したＣＰＵがＲＡＭに展開し実行することで実現される。
なお、この制御部１１は、例えば、記憶部１３に格納されたプログラムを、図示を省略したＣＰＵがＲＡＭに展開し実行することで実現される。
振分方式設定部１１１は、クライアント５からの処理要求の振分先となる処理部２０を、記憶部１３に記憶された振分先情報１３１を参照して決定する方式を設定する。この振分方式設定部１１１は、例えば、ラウンドロビンや、重み付けラウンドロビン等の方式を設定することができる。
ラウンドロビン方式では、各処理部２０への処理要求の振分比率を均等に設定する。
一方、重み付けラウンドロビン方式では、各処理部２０への処理要求の振分比率が指定した値に設定される。この振分比率の値は、例えば、物理サーバ３０のサーバスペック値（処理能力）が異なるヘテロ環境において、処理部２０を配置する物理サーバ３０のスペック値に応じた値を設定する。なお、このスペック値は、例えば、物理サーバ３０のＣＰＵのコア数や、メモリ容量等が該当する。そして、例えば、ＣＰＵのコア数が他の物理サーバ３０より多い物理サーバ３０には、処理要求の振分比率を高く設定するようにする。
一方、重み付けラウンドロビン方式では、各処理部２０への処理要求の振分比率が指定した値に設定される。この振分比率の値は、例えば、物理サーバ３０のサーバスペック値（処理能力）が異なるヘテロ環境において、処理部２０を配置する物理サーバ３０のスペック値に応じた値を設定する。なお、このスペック値は、例えば、物理サーバ３０のＣＰＵのコア数や、メモリ容量等が該当する。そして、例えば、ＣＰＵのコア数が他の物理サーバ３０より多い物理サーバ３０には、処理要求の振分比率を高く設定するようにする。
この振分方式設定部１１１は、振分処理部１１４による処理開始前に、図示を省略したシステム管理装置等から振分方式の設定情報を、入出力部１２を介して取得し、ラウンドロビン方式や重み付けラウンドロビン方式を予め設定する。
処理部追加・削除情報受信部１１２は、リソース調整装置４０から、処理部追加情報または処理部削除情報を受信し、処理部追加・削除実行部１１３に引き渡す。
処理部追加・削除実行部１１３は、処理部追加情報を取得した場合に、その処理部追加情報に含まれる新たに追加される処理部２０の情報を、記憶部１３内の振分先情報１３１に登録する。なお、振分先情報１３１は、クライアント５からの処理要求の振分先となる処理部２０の識別情報やアドレスが、リストとして記憶される情報である。
また、処理部追加・削除実行部１１３は、処理部削除情報を取得した場合に、記憶部１３内の振分先情報１３１に記憶されている削除対象の処理部２０の情報を削除する。
振分処理部１１４は、クライアント５から処理要求を受信すると、記憶部１３内の振分先情報１３１を参照し、振分方式設定部１１１により設定された振分方式にしたがって、振分先を決定し、その決定した振分先の処理部２０に処理要求を送信する。
記憶部１３は、ハードディスクやフラッシュメモリ、ＲＡＭ等の記憶手段からなり、前記した、振分先情報１３１等が記憶される。
＜処理の流れ＞
次に、本実施形態に係る分散処理システム１の処理の流れについて説明する。
図８は、本実施形態に係る分散処理システム１の処理の流れを示すフローチャートである。
なお、本実施形態に係る分散処理システム１において、以下のフローチャートの説明の前提処理として、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）が、所定の時間間隔で、処理部負荷量情報をリソース調整装置４０に送信し、各物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）が、同じく所定の時間間隔で、物理サーバリソース情報をリソース調整装置４０に送信しているものとする。
また、初期状態の物理サーバ３０の台数と、処理部２０(仮想サーバ)の物理サーバ３０への配置は、例えば、非特許文献１（中里 彦俊他，「ＯＳＳを構成する仮想マシンの最適配置手法の提案」，電子情報通信学会，信学技報，112（120），2012/07/12，31-36）に記載の仮想マシン初期配置手法により、設定済みであるものとする。そして、この初期状態の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）上の処理部２０（２０ａ，２０ｂ，２０ｃ，…）の配置に基づき、リソース調整装置４０の記憶部４３内に、処理スケジュール情報４３３および処理部配置情報４３５が記憶済みであるものとする。
さらに、分散処理システム１のシステム管理装置（図示省略）等から取得した、処理部増減判定処理に用いる各種の閾値である処理部増減判定閾値情報４３６、および、配置先物理サーバ決定処理に用いる各種の閾値である物理サーバ選定閾値情報４３７が、リソース調整装置４０の記憶部４３内に記憶されているものとする。
次に、本実施形態に係る分散処理システム１の処理の流れについて説明する。
図８は、本実施形態に係る分散処理システム１の処理の流れを示すフローチャートである。
なお、本実施形態に係る分散処理システム１において、以下のフローチャートの説明の前提処理として、各処理部２０（２０ａ，２０ｂ，２０ｃ，…）が、所定の時間間隔で、処理部負荷量情報をリソース調整装置４０に送信し、各物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）が、同じく所定の時間間隔で、物理サーバリソース情報をリソース調整装置４０に送信しているものとする。
また、初期状態の物理サーバ３０の台数と、処理部２０(仮想サーバ)の物理サーバ３０への配置は、例えば、非特許文献１（中里 彦俊他，「ＯＳＳを構成する仮想マシンの最適配置手法の提案」，電子情報通信学会，信学技報，112（120），2012/07/12，31-36）に記載の仮想マシン初期配置手法により、設定済みであるものとする。そして、この初期状態の物理サーバ３０（３０Ａ，３０Ｂ，３０Ｃ，…）上の処理部２０（２０ａ，２０ｂ，２０ｃ，…）の配置に基づき、リソース調整装置４０の記憶部４３内に、処理スケジュール情報４３３および処理部配置情報４３５が記憶済みであるものとする。
さらに、分散処理システム１のシステム管理装置（図示省略）等から取得した、処理部増減判定処理に用いる各種の閾値である処理部増減判定閾値情報４３６、および、配置先物理サーバ決定処理に用いる各種の閾値である物理サーバ選定閾値情報４３７が、リソース調整装置４０の記憶部４３内に記憶されているものとする。
まず、リソース調整装置４０の処理部負荷量情報受信部４１１は、各処理部２０から処理部負荷量情報を受信する（ステップＳ１０）。
また、リソース調整装置４０の物理サーバリソース情報受信部４１２は、各物理サーバ３０から物理サーバリソース情報を受信する（ステップＳ１１）。
なお、ステップＳ１０とステップＳ１１とは、どちらを先に実行しても構わない。
なお、ステップＳ１０とステップＳ１１とは、どちらを先に実行しても構わない。
次に、リソース調整装置４０の処理部増減判定部４１３は、処理部増減判定処理を行う（ステップＳ１２）。
ここで、処理部増減判定部４１３は、処理部増減判定処理において、前記した処理部２０の追加条件および削除条件のいずれも満たさない場合は（ステップＳ１２→「追加・削除条件満たさない」）、処理部２０の数の増減を行わず、処理を終える。一方、処理部増減判定処理において、追加条件を満たす場合には（ステップＳ１２→「追加条件を満たす」）、次のステップＳ１３に進む。また、処理部増減判定処理において、削除条件を満たす場合には（ステップＳ１２→「削除条件を満たす」）、次のステップＳ１８に進む。
（処理部２０の追加処理）
次に、ステップＳ１３〜Ｓ１７の処理部２０の追加処理について説明する。
ステップＳ１３において、リソース調整装置４０の処理部増減判定部４１３は、追加する処理部２０の数を決定する。
次に、ステップＳ１３〜Ｓ１７の処理部２０の追加処理について説明する。
ステップＳ１３において、リソース調整装置４０の処理部増減判定部４１３は、追加する処理部２０の数を決定する。
続いて、リソース調整装置４０の配置先物理サーバ決定部４１４は、物理サーバ選定基準に基づき、配置先となる物理サーバ３０を決定する配置先物理サーバ決定処理を行う（ステップＳ１４）。
具体的には、配置先物理サーバ決定部４１４は、処理部配置情報４３５（図６）を参照して、各物理サーバ３０に配置された処理部２０を抽出し、記憶部４３に記憶された処理スケジュール情報４３３（図４）および処理部使用予定リソース情報４３４（図５）を参照して、抽出した処理部２０の使用予定リソース量を計算する。そして、配置先物理サーバ決定部４１４は、抽出した処理部２０の使用予定リソース量の和を計算することにより、物理サーバ３０毎の使用予定リソース量を計算する。次に、配置先物理サーバ決定部４１４は、ステップＳ１１で取得した物理サーバリソース情報に示される実使用リソース量が上限閾値ｘを超過せず、かつ、物理サーバ３０の使用予定リソース量が上限閾値ｙを超過しない物理サーバ３０を選定する。なお、物理サーバ選定基準を満たす物理サーバ３０が、１つも選定されない場合は、稼働状態とする物理サーバ３０を１つ増設して、再び配置先物理サーバ決定処理を実行する。
続いて、配置先物理サーバ決定部４１４は、物理サーバ選定基準を満たすとして選定された物理サーバ３０の中から、処理部２０の配置先となる物理サーバ３０を決定する。なお、この配置先の物理サーバ３０の決定は、任意に決定されるものとする。
具体的には、配置先物理サーバ決定部４１４は、処理部配置情報４３５（図６）を参照して、各物理サーバ３０に配置された処理部２０を抽出し、記憶部４３に記憶された処理スケジュール情報４３３（図４）および処理部使用予定リソース情報４３４（図５）を参照して、抽出した処理部２０の使用予定リソース量を計算する。そして、配置先物理サーバ決定部４１４は、抽出した処理部２０の使用予定リソース量の和を計算することにより、物理サーバ３０毎の使用予定リソース量を計算する。次に、配置先物理サーバ決定部４１４は、ステップＳ１１で取得した物理サーバリソース情報に示される実使用リソース量が上限閾値ｘを超過せず、かつ、物理サーバ３０の使用予定リソース量が上限閾値ｙを超過しない物理サーバ３０を選定する。なお、物理サーバ選定基準を満たす物理サーバ３０が、１つも選定されない場合は、稼働状態とする物理サーバ３０を１つ増設して、再び配置先物理サーバ決定処理を実行する。
続いて、配置先物理サーバ決定部４１４は、物理サーバ選定基準を満たすとして選定された物理サーバ３０の中から、処理部２０の配置先となる物理サーバ３０を決定する。なお、この配置先の物理サーバ３０の決定は、任意に決定されるものとする。
次に、リソース調整装置４０の処理部配置実行部４１５は、新たに追加する処理部２０を、リソースプール用の物理サーバ３０から、ステップＳ１４において決定した配置先の物理サーバ３０に移動させる（ステップＳ１５）。なお、このとき、処理部配置実行部４１５は、記憶部４３内の処理部配置情報４３５を、新たに追加した処理部２０が配置先の物理サーバ３０に配置されるように更新する。
続いて、リソース調整装置４０の処理部追加・削除情報送信部４１６は、新たに追加する処理部２０の識別情報およびアドレス等の情報を含む処理部追加情報を生成し、振分装置１０へ送信する（ステップＳ１６）。
そして、振分装置１０の処理部追加・削除情報受信部１１２は、リソース調整装置４０から処理部追加情報を受信し、処理部追加・削除実行部１１３が、記憶部１３に記憶された振分先情報１３１に追加する処理部２０に関する情報を登録し（ステップＳ１７）、処理を終える。
（処理部２０の削除処理）
次に、ステップＳ１８〜Ｓ２１の処理部２０の削除処理について説明する。
ステップＳ１８において、リソース調整装置４０の処理部増減判定部４１３は、削除する処理部２０の数を決定する。また、処理部増減判定部４１３は、削除条件を満たす処理部２０の中から、実際に削除する処理部２０を決定する。この削除対象の処理部２０の決定は、削除条件を満たす処理部２０の中から任意に選択して削除対象の処理部２０を決定してもよいし、使用リソース量が最も少ない処理部２０から順に、または、処理件数が最も少ない処理部２０から順に、削除する処理部２０の数だけ選択し、削除対象の処理部２０を決定するようにしてもよい。
なお、配置先物理サーバ決定部４１４は、前記した非特許文献１に記載の仮想マシン再配置手法により、削除対象の処理部２０を削除したものとして、処理部２０を他の物理サーバ３０へ再配置することにより、稼働状態の物理サーバ３０の台数を減らすことができる。
次に、ステップＳ１８〜Ｓ２１の処理部２０の削除処理について説明する。
ステップＳ１８において、リソース調整装置４０の処理部増減判定部４１３は、削除する処理部２０の数を決定する。また、処理部増減判定部４１３は、削除条件を満たす処理部２０の中から、実際に削除する処理部２０を決定する。この削除対象の処理部２０の決定は、削除条件を満たす処理部２０の中から任意に選択して削除対象の処理部２０を決定してもよいし、使用リソース量が最も少ない処理部２０から順に、または、処理件数が最も少ない処理部２０から順に、削除する処理部２０の数だけ選択し、削除対象の処理部２０を決定するようにしてもよい。
なお、配置先物理サーバ決定部４１４は、前記した非特許文献１に記載の仮想マシン再配置手法により、削除対象の処理部２０を削除したものとして、処理部２０を他の物理サーバ３０へ再配置することにより、稼働状態の物理サーバ３０の台数を減らすことができる。
続いて、リソース調整装置４０の処理部追加・削除情報送信部４１６は、削除対象の処理部２０の識別情報を含む処理部削除情報を生成し、振分装置１０に送信する（ステップＳ１９）。
そして、振分装置１０の処理部追加・削除情報受信部１１２は、リソース調整装置４０から処理部削除情報を受信し、処理部追加・削除実行部１１３が、記憶部１３に記憶された振分先情報１３１に記憶された削除対象の処理部２０の情報を削除する（ステップＳ２０）。
次に、リソース調整装置４０の処理部配置実行部４１５は、削除対象の処理部２０を、それまでの配置先の物理サーバ３０から、リソースプール用の物理サーバ３０（３０Ｐ）に移動させる（ステップＳ２１）。なお、処理部配置実行部４１５は、記憶部４３内の処理部配置情報４３５を、削除対象の処理部２０を配置先の物理サーバ３０から削除し、リソースプール用の物理サーバ３０（３０Ｐ）に移動させるようにして更新する。そして、分散処理システム１全体の処理を終える。
以上説明したように、本実施形態に係る分散処理システム１および分散処理方法によれば、振分部において負荷量の監視が不可能な場合であっても、各処理部２０の負荷量に応じて適切な処理部２０の数を調整できる。また、処理部２０の追加または削除が必要か否かの判定を、所定の期間毎に行うため、処理部数の変更に伴うオーバヘッドの増加を抑え、システム安定性を確保することができる。
以上、本実施形態について説明したが、本発明は、ここで説明した実施形態に限定されるものではない。
例えば、本発明において、処理部２０は仮想マシンであることを前提として説明したが、例えば、物理サーバ３０に設けられた複数のＣＰＵ（コア）を処理部２０とし、この処理部２０の使用リソース量または処理件数を処理部負荷量情報としてリソース調整装置４０に送信し、処理部増減判定を行うようにすることもできる。この場合、処理部２０自体は、他の物理サーバ３０に移動はできないが、処理部２０を追加する場合には、待機状態のＣＰＵ（コア）を稼動状態にし、処理部２０を削除する場合には、稼動状態のＣＰＵ（コア）を待機状態にすることで、処理部２０の数を調整することができる。
例えば、本発明において、処理部２０は仮想マシンであることを前提として説明したが、例えば、物理サーバ３０に設けられた複数のＣＰＵ（コア）を処理部２０とし、この処理部２０の使用リソース量または処理件数を処理部負荷量情報としてリソース調整装置４０に送信し、処理部増減判定を行うようにすることもできる。この場合、処理部２０自体は、他の物理サーバ３０に移動はできないが、処理部２０を追加する場合には、待機状態のＣＰＵ（コア）を稼動状態にし、処理部２０を削除する場合には、稼動状態のＣＰＵ（コア）を待機状態にすることで、処理部２０の数を調整することができる。
１ 分散処理システム
５ クライアント
１０ 振分装置
１１，４１ 制御部
１２，４２ 入出力部
１３，４３ 記憶部
２０ 処理部
２１ アプリケーション処理部
２２ 処理部負荷量情報収集部
２３ 処理部負荷量情報通知部
３０ 物理サーバ
３１ 仮想化制御部
３２ 物理サーバリソース情報収集部
３３ 物理サーバリソース情報通知部
４０ リソース調整装置
１１１ 振分方式設定部
１１２ 処理部追加・削除情報受信部
１１３ 処理部追加・削除実行部
１１４ 振分処理部
１３１ 振分先情報
４１１ 処理部負荷量情報受信部
４１２ 物理サーバリソース情報受信部
４１３ 処理部増減判定部
４１４ 配置先物理サーバ決定部
４１５ 処理部配置実行部
４１６ 処理部追加・削除情報送信部
４３１ 処理部負荷量情報
４３２ 物理サーバリソース情報
４３３ 処理スケジュール情報
４３４ 処理部使用予定リソース情報
４３５ 処理部配置情報
４３６ 処理部増減判定閾値情報
４３７ 物理サーバ選定閾値情報
５ クライアント
１０ 振分装置
１１，４１ 制御部
１２，４２ 入出力部
１３，４３ 記憶部
２０ 処理部
２１ アプリケーション処理部
２２ 処理部負荷量情報収集部
２３ 処理部負荷量情報通知部
３０ 物理サーバ
３１ 仮想化制御部
３２ 物理サーバリソース情報収集部
３３ 物理サーバリソース情報通知部
４０ リソース調整装置
１１１ 振分方式設定部
１１２ 処理部追加・削除情報受信部
１１３ 処理部追加・削除実行部
１１４ 振分処理部
１３１ 振分先情報
４１１ 処理部負荷量情報受信部
４１２ 物理サーバリソース情報受信部
４１３ 処理部増減判定部
４１４ 配置先物理サーバ決定部
４１５ 処理部配置実行部
４１６ 処理部追加・削除情報送信部
４３１ 処理部負荷量情報
４３２ 物理サーバリソース情報
４３３ 処理スケジュール情報
４３４ 処理部使用予定リソース情報
４３５ 処理部配置情報
４３６ 処理部増減判定閾値情報
４３７ 物理サーバ選定閾値情報
Claims (4)
- クライアントから受け取った処理要求を、物理サーバに配置された処理部に振り分ける振分装置と、前記振り分けられた処理要求を処理する処理部と、１つ以上の前記処理部を配置する複数の前記物理サーバと、前記振分装置、前記処理部それぞれおよび複数の前記物理サーバに接続され、前記物理サーバに配置される前記処理部の数を調整するリソース調整装置と、を備える分散処理システムであって、
前記処理部それぞれは、
当該処理部自身の使用リソース量または処理件数を収集する処理部負荷量情報収集部と、
収集した前記使用リソース量または前記処理件数を処理部負荷量情報として、前記リソース調整装置に通知する処理部負荷量情報通知部と、を備え、
前記リソース調整装置は、
（１）前記処理部の追加を判定するための、前記処理部負荷量情報に対する上限閾値および前記上限閾値以上の値が継続する期間を示す第１の継続期間閾値、並びに、（２）前記処理部の削除を判定するための、前記処理部負荷量情報に対する下限閾値および前記下限閾値を下回る値が継続する期間を示す第２の継続期間閾値、が格納される処理部増減判定閾値情報が記憶される記憶部と、
前記処理部それぞれから、前記処理部負荷量情報を受信する処理部負荷量情報受信部と、
前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第１の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記上限閾値以上である期間が前記第１の継続期間閾値を超える場合に前記処理部の追加条件を満たすと判定すると共に、
前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第２の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記下限閾値を下回る期間が前記第２の継続期間閾値を超える場合に前記処理部の削除条件を満たすと判定する処理部増減判定部と、
前記処理部の追加条件を満たすと判定された場合に、前記物理サーバに対し処理部を追加するように制御すると共に、前記処理部の削除条件を満たすと判定された場合に、前記物理サーバに対し処理部を削除するように制御する処理部配置実行部と、
前記処理部を追加する場合に、当該追加する処理部の情報を含む処理部追加情報を生成し前記振分装置に送信すると共に、前記処理部を削除する場合に、当該削除する処理部の情報を含む処理部削除情報を生成し前記振分装置に送信する処理部追加・削除情報送信部と、を備え、
前記振分装置は、
前記処理要求の振分先となる前記処理部を示す振分先情報が記憶される記憶部と、
前記処理部追加情報に示される前記追加する処理部の情報を前記振分先情報に登録すると共に、前記処理部削除情報に示される前記削除する処理部の情報を前記振分先情報から削除する処理部追加・削除実行部と、
受信した前記処理要求を、前記振分先情報を参照して、前記処理部に振り分ける振分処理部と、を備えること
を特徴とする分散処理システム。 - 前記振分装置の振分処理部は、
前記振分先情報に登録された前記処理部それぞれへの前記処理要求の振分比率を均等に設定したラウンドロビン、または、前記処理部それぞれへの前記処理要求の振分比率を、前記処理部が配置される前記物理サーバの処理能力に応じて設定した重み付けラウンドロビンにより、振分先となる前記処理部を決定すること、
を特徴とする請求項１に記載の分散処理システム。 - クライアントから受け取った処理要求を、物理サーバに配置された処理部に振り分ける振分装置と、前記振り分けられた処理要求を処理する処理部と、１つ以上の前記処理部を配置する複数の前記物理サーバと、前記振分装置、前記処理部それぞれおよび複数の前記物理サーバに接続され、前記物理サーバに配置される前記処理部の数を調整するリソース調整装置と、を備える分散処理システムであって、
前記処理部それぞれは、
当該処理部自身の使用リソース量または処理件数を収集する処理部負荷量情報収集部と、
収集した前記使用リソース量または前記処理件数を処理部負荷量情報として、前記リソース調整装置に通知する処理部負荷量情報通知部と、を備え、
前記リソース調整装置は、
（１）前記処理部の追加を判定するための、前記処理部負荷量情報に対する上限閾値および前記上限閾値以上の値が継続する期間を示す第１の継続期間閾値、並びに、（２）前記処理部の削除を判定するための、前記処理部負荷量情報に対する下限閾値および前記下限閾値を下回る値が継続する期間を示す第２の継続期間閾値、が格納される処理部増減判定閾値情報が記憶される記憶部と、
前記処理部それぞれから、前記処理部負荷量情報を受信する処理部負荷量情報受信部と、
前記処理部負荷量情報に基づき、前記使用リソース量または前記処理件数が、前記上限閾値以上である期間が前記第１の継続期間閾値を超える場合に前記処理部の追加条件を満たすと判定すると共に、
前記処理部負荷量情報に基づき、前記使用リソース量または前記処理件数が、前記下限閾値を下回る期間が前記第２の継続期間閾値を超える場合に前記処理部の削除条件を満たすと判定する処理部増減判定部と、
前記処理部の追加条件を満たすと判定された場合に、前記物理サーバに対し処理部を追加するように制御すると共に、前記処理部の削除条件を満たすと判定された場合に、前記物理サーバに対し処理部を削除するように制御する処理部配置実行部と、
前記処理部を追加する場合に、当該追加する処理部の情報を含む処理部追加情報を生成し前記振分装置に送信すると共に、前記処理部を削除する場合に、当該削除する処理部の情報を含む処理部削除情報を生成し前記振分装置に送信する処理部追加・削除情報送信部と、を備え、
前記振分装置は、
前記処理要求の振分先となる前記処理部を示す振分先情報が記憶される記憶部と、
前記処理部追加情報に示される前記追加する処理部の情報を前記振分先情報に登録すると共に、前記処理部削除情報に示される前記削除する処理部の情報を前記振分先情報から削除する処理部追加・削除実行部と、
受信した前記処理要求を、前記振分先情報を参照して、前記処理部に振り分ける振分処理部と、を備え、
前記処理部は、前記物理サーバ上に配置される仮想マシンで構成されており、
前記物理サーバは、前記処理要求に対する処理を実行する処理部を配置する稼働中の前記物理サーバと、前記処理要求を受け付けない待機状態の前記処理部を配置するリソースプール用の前記物理サーバとで構成されており、
前記物理サーバそれぞれは、
当該物理サーバ自身の使用リソース量を収集する物理サーバリソース情報収集部と、
収集した前記使用リソース量を物理サーバリソース情報として、前記リソース調整装置に通知する物理サーバリソース情報通知部と、備え、
前記リソース調整装置は、
前記記憶部にさらに、前記処理要求を処理するためのアプリケーションを実行する予定の期間を示す処理スケジュールを前記処理部ごとに示す処理スケジュール情報と、前記処理部とその処理部が配置されている前記物理サーバとを関連付けた情報である処理部配置情報と、前記物理サーバの使用リソース量に対する上限閾値および前記処理スケジュール情報を用いて算出される前記物理サーバの使用予定リソース量に対する上限閾値が格納される物理サーバ選定閾値情報と、が記憶されており、
前記物理サーバそれぞれから、前記物理サーバリソース情報を受信する物理サーバリソース情報受信部と、
前記処理部増減判定部が、前記処理部の追加条件を満たすと判定した場合に、前記物理サーバそれぞれについて、当該物理サーバに配置されているすべての前記処理部を前記処理部配置情報に基づき抽出し、前記抽出した前記処理部それぞれの使用予定リソース量を前記処理スケジュール情報を用いて算出し、算出した前記処理部ごとの前記使用予定リソース量を合計して、前記物理サーバごとの使用予定リソース量を算出し、当該算出した使用予定リソース量が、前記物理サーバの使用予定リソース量に対する上限閾値を超えず、かつ、前記物理サーバから受信した前記物理サーバリソース情報に示される前記使用リソース量が、前記物理サーバの使用リソース量に対する上限閾値を超えない物理サーバを選定し、前記選定した物理サーバの中から、前記処理部を追加する配置先の物理サーバを決定すると共に、前記処理部増減判定部が、前記処理部の削除条件を満たすと判定した場合に、前記削除条件を満たす処理部の中から削除対象となる処理部を決定する配置先物理サーバ決定部と、をさらに備え、
前記処理部配置実行部は、前記処理部増減判定部が、前記処理部の追加条件を満たすと判定した場合に、前記リソースプール用の物理サーバに配置された処理部を、前記配置先物理サーバ決定部が決定した前記配置先の物理サーバに移動させるように制御すると共に、前記処理部増減判定部が、前記処理部の削除条件を満たすと判定した場合に、前記削除対象となる処理部を、前記リソースプール用の物理サーバに移動させるように制御すること、
を特徴とする分散処理システム。 - クライアントから受け取った処理要求を、物理サーバに配置された処理部に振り分ける振分装置と、前記振り分けられた処理要求を処理する処理部と、１つ以上の前記処理部を配置する複数の前記物理サーバと、前記振分装置、前記処理部それぞれおよび複数の前記物理サーバに接続され、前記物理サーバに配置される前記処理部の数を調整するリソース調整装置と、を備える分散処理システムの分散処理方法であって、
前記処理部それぞれは、
当該処理部自身の使用リソース量または処理件数を収集するステップと、
収集した前記使用リソース量または前記処理件数を処理部負荷量情報として、前記リソース調整装置に通知するステップと、を実行し、
前記リソース調整装置は、
（１）前記処理部の追加を判定するための、前記処理部負荷量情報に対する上限閾値および前記上限閾値以上の値が継続する期間を示す第１の継続期間閾値、並びに、（２）前記処理部の削除を判定するための、前記処理部負荷量情報に対する下限閾値および前記下限閾値を下回る値が継続する期間を示す第２の継続期間閾値、が格納される処理部増減判定閾値情報が記憶される記憶部を備えており、
前記処理部それぞれから、前記処理部負荷量情報を受信するステップと、
前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第１の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記上限閾値以上である期間が前記第１の継続期間閾値を超える場合に前記処理部の追加条件を満たすと判定するステップと、
前記処理部負荷量情報に基づき、前記分散処理システムの全処理部のうち第２の所定の割合以上を占める処理部の前記使用リソース量または前記処理件数が、前記下限閾値を下回る期間が前記第２の継続期間閾値を超える場合に前記処理部の削除条件を満たすと判定するステップと、
前記処理部の追加条件を満たすと判定された場合に、前記物理サーバに対し処理部を追加するように制御するステップと、
前記処理部の削除条件を満たすと判定された場合に、前記物理サーバに対し処理部を削除するように制御するステップと、
前記処理部を追加する場合に、当該追加する処理部の情報を含む処理部追加情報を生成し前記振分装置に送信するステップと、
前記処理部を削除する場合に、当該削除する処理部の情報を含む処理部削除情報を生成し前記振分装置に送信するステップと、を実行し、
前記振分装置は、
前記処理要求の振分先となる前記処理部を示す振分先情報が記憶される記憶部を備えており、
前記処理部追加情報に示される前記追加する処理部の情報を前記振分先情報に登録するステップと、
前記処理部削除情報に示される前記削除する処理部の情報を前記振分先情報から削除するステップと、
受信した前記処理要求を、前記振分先情報を参照して、前記処理部に振り分けるステップと、を実行すること
を特徴とする分散処理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013099117A JP5997659B2 (ja) | 2013-05-09 | 2013-05-09 | 分散処理システムおよび分散処理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2013099117A JP5997659B2 (ja) | 2013-05-09 | 2013-05-09 | 分散処理システムおよび分散処理方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2014219859A JP2014219859A (ja) | 2014-11-20 |
| JP5997659B2 true JP5997659B2 (ja) | 2016-09-28 |
Family
ID=51938239
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2013099117A Active JP5997659B2 (ja) | 2013-05-09 | 2013-05-09 | 分散処理システムおよび分散処理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5997659B2 (ja) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2017146791A (ja) * | 2016-02-17 | 2017-08-24 | 日本電信電話株式会社 | クラスタ内マイグレーション管理システム、クラスタ内マイグレーション管理方法、管理サーバ及びプログラム |
| WO2017168484A1 (ja) * | 2016-03-28 | 2017-10-05 | 株式会社日立製作所 | 管理計算機および性能劣化予兆検知方法 |
| CN115002209A (zh) * | 2022-06-23 | 2022-09-02 | 京东方科技集团股份有限公司 | 数据处理方法、装置及*** |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5287623B2 (ja) * | 2009-09-11 | 2013-09-11 | 株式会社リコー | 仮想サーバ管理システム、画像処理システム、仮想サーバ管理装置及び制御プログラム |
-
2013
- 2013-05-09 JP JP2013099117A patent/JP5997659B2/ja active Active
Also Published As
| Publication number | Publication date |
|---|---|
| JP2014219859A (ja) | 2014-11-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9571347B2 (en) | Reactive auto-scaling of capacity | |
| Tomás et al. | An autonomic approach to risk-aware data center overbooking | |
| CN107273185B (zh) | 一种基于虚拟机的负载均衡控制方法 | |
| JP5332065B2 (ja) | クラスタ構成管理方法、管理装置及びプログラム | |
| CN102388381B (zh) | 用于分配共享存储资源的***和方法 | |
| CN108182105B (zh) | 基于Docker容器技术的局部动态迁移方法及控制*** | |
| WO2017167025A1 (zh) | 一种实现任务调度的方法、装置及计算机存储介质 | |
| Hieu et al. | Virtual machine consolidation with usage prediction for energy-efficient cloud data centers | |
| JP6881575B2 (ja) | 資源割当システム、管理装置、方法およびプログラム | |
| CN107911399B (zh) | 一种基于负载预测的弹性伸缩方法及*** | |
| KR20170029263A (ko) | 부하 분산 장치 및 방법 | |
| JP2006252163A (ja) | 負荷制御装置および負荷制御プログラム | |
| CN105052074A (zh) | 用于提供虚拟化直径网络架构以及用于将业务量路由至动态实例化的直径资源实例的方法、***和计算机可读介质 | |
| JP2005196601A (ja) | 自律管理システム向けポリシシミュレータ | |
| CN105703927A (zh) | 一种资源分配方法、网络设备和网络*** | |
| CN103366022B (zh) | 信息处理***及其处理方法 | |
| US10142997B2 (en) | Method and apparatus for adjusting physical resource, and controller | |
| CN112463395A (zh) | 一种资源分配方法、装置、设备及可读存储介质 | |
| JP2015152984A (ja) | 仮想マシン配置装置及び方法及びプログラム | |
| JP5997659B2 (ja) | 分散処理システムおよび分散処理方法 | |
| CN107562537A (zh) | 一种基于万有引力搜索的云计算任务调度方法 | |
| CN112559122A (zh) | 一种基于电力专用安防设备的虚拟化实例管控方法及*** | |
| CN102480502A (zh) | 一种i/o负载均衡方法及i/o服务器 | |
| CN107203256B (zh) | 一种网络功能虚拟化场景下的节能分配方法与装置 | |
| CN114416355A (zh) | 资源调度方法、装置、***、电子设备及介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20150731 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20160412 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20160524 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20160725 |
|
| 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: 20160823 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20160826 |
|
| R150 | Certificate of patent (=grant) or registration of utility model |
Ref document number: 5997659 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |