JP2011013870A

JP2011013870A - 負荷分散システム

Info

Publication number: JP2011013870A
Application number: JP2009156508A
Authority: JP
Inventors: Shigeki Yokoya; 茂樹横谷
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2009-07-01
Filing date: 2009-07-01
Publication date: 2011-01-20

Abstract

【課題】
処理要求数から必要サーバ台数を計算し停止可能、または起動サーバを効率よく決定する。
【解決手段】
クライアント１００（＃１，＃２・・・＃ｎ）からの単位時間あたりの処理要求数最大値を求め、保存してある過去の処理要求数最大値とその時点に稼働していたサーバ台数から、その時点のサーバ１台あたりの処理数を求め、今回取得した処理要求数最大値との関係から現在の処理要求数を処理するのに必要なサーバ台数を計算し、停止可能、または起動すべきサーバがあるか判定する。停止可能なサーバがあると判定された場合は対象サーバにクライアント１００（＃１，＃２・・・＃ｎ）からの新規の処理要求を振り分けずサーバが処理する要求が無くなるまで待ち、処理要求が０になったことを検出してサーバを停止するする。起動すべきサーバがあると判定された場合は直ちに起動する。
【選択図】図１

Description

本発明は複数クライアント、複数サーバと前記複数サーバの処理負荷を分散させる負荷分散装置から構成される負荷分散システムに関する。

負荷分散システムとは複数クライアント、負荷分散装置と複数サーバから構成され、複数サーバ上で同じアプリケーションを実行することで負荷を分散するシステムである。この負荷分散システムにおいて各サーバの負荷状態に応じて、特定サーバを停止または起動の制御を行う方法としては特許文献１が知られている。
従来、サーバ全体の負荷状態が高負荷検出用に設定した閾値を超えると高負荷状態と判断し停止中のサーバを起動し、低負荷検出用に設定した閾値を下回ると低負荷と判断し一定時間後にサーバを停止、または起動している。

特開２００８−２３４３５６号公報

しかし、従来のサーバ起動、停止方法には以下のような問題がある。
低負荷検出用閾値を下回りサーバ停止可能と判断された場合、停止予定サーバのＩＰアドレスを負荷分散装置から切り離す方法では、接続中クライアントの有無に関わらず、停止予定サーバを負荷分散装置から切り離してしまうため、処理がいきなり中断するクライアントが発生する。この場合、処理を中断されたクライアントは業務を最初からやり直さなければならない。

また、低負荷検出用閾値を下回りサーバ停止可能と判断された場合、サーバ１台を負荷分散装置から切り離して、他のサーバの負荷状態を監視し、高負荷検出用閾値を超えなければ、サーバを停止する方法では、その時点で何台のサーバがあれば全処理要求を処理できるのか判定できないので、サーバを１台ずつ停止しながら様子を見ることになる。このため効率が悪い。
高負荷検出用閾値を超えた場合に停止中のサーバを起動する方法では、朝の就業開始時間のように決まった時間に一斉に処理要求が増えるような場合でも１台ずつサーバを起動して、負荷状況を見て、さらにサーバを起動するといった運用になり、急激な負荷増加に耐えられない。

上記の問題はサーバを停止する前に停止予定サーバに対する新規処理要求の振り分けを抑止し、処理要求が無くなったことを確認した後にサーバを停止すること、過去の一定時間毎の処理要求数最大値およびその時点のサーバ負荷状態を保存しておくこと、および過去の情報に基づいてサーバ起動時間をスケジュールすることで回避できる。
本発明はこのような問題を解決するためになされたものであり、安全で的確なサーバの停止、または起動を行うことができ、スケジュールによるサーバ起動が可能な負荷分散システムを提供することを目的とする。

上記の目的を達成するために、本発明では以下のような手段を講じる。
請求項１の発明は、複数クライアントと、複数サーバと、複数クライアントからの処理要求を分散して複数サーバに振り分ける負荷分散装置を備え、複数クライアントからの処理要求数から、必要サーバ台数を計算し、計算した必要サーバ数と稼働中サーバ数の関係から、サーバの停止、または起動を行うことのできるシステムに適用され、複数サーバそれぞれの負荷情報を取得する負荷情報取得手段と、複数クライアントからの処理要求数を収集し、単位時間ごとの最大値を求める処理要求数収集手段と、単位時間ごとにサーバの生死情報を取得するサーバ監視手段と、負荷情報取得手段で取得した負荷情報と、処理要求数収集手段によって求められた最大値を関連付けるデータ統合手段と、データ統合手段により統合されたデータと、格納されている過去の最大処理要求数の関係からを最大値の更新を行う基本情報格納手段と、過去のデータを人手で更新できる入力手段と、基本情報格納手段によって、格納されている過去の処理要求数の最大値と、データ統合手段により統合された最大処理要求数の関係から、現在の必要サーバ台数を計算し、監視手段によって取得される現在の稼働サーバ数を比較して停止可能なサーバ、または起動するサーバがあるか否かを判定する判定手段と、判定手段が規定回数連続で同じ判定を行ったか監視する判定監視手段と、判定監視手段によって規定回数連続で同じ判定が行われた場合に、過去の停止サーバ情報から、どのサーバを停止させるかを決定するサーバ決定手段と、サーバ決定手段によって決定されたサーバへの複数クライアントからの処理要求の振り分けを抑止する振り分け抑止手段と、サーバ決定手段により決定された停止対象サーバの情報を格納しておくサーバ情報格納手段と、振り分け抑止手段により、振り分けを抑止したサーバの処理要求がなくなったことを検出する検出手段と、検出手段によって、サーバの処理要求がなくなったことが確認できたとき、または判定手段の結果から停止中のサーバを稼働させる必要があると判定された場合に、サーバの電源を制御する電源制御手段とを備える。

請求項２の発明は基本情報格納手段によって格納されている過去の単位時間毎の最大値から、その時間の必要サーバ数を計算する計算手段と、計算手段の結果から停止中のサーバを稼働させるスケジュールを作成するスケジュール手段と、スケジュール手段によって作成されたスケジュールにもとづきサーバを稼働させるサーバ稼働手段とを備える。

本発明によれば、低負荷状態になった場合に、安全で的確なサーバ停止、およびサーバ起動が可能となる。また、サーバ起動スケジュールによるサーバ起動が可能となり、特定時間に負荷が増加する運用に対して予めサーバを起動することができる。

負荷分散システムの構成例を示す構成図負荷分散装置のブロック図サーバ側の負荷情報を収集のための機能ブロック図サーバ停止、起動のための負荷分散装置内の機能ブロック図判定部の動作フローチャートサーバ決定部の動作フローチャート振り分け抑止部の動作フローチャートサーバ制御部の動作フローチャート過去の最大値データ

以下に、本発明を実施するための形態について図面を参照しながら説明する。

図１は、本実施の形態に係る負荷分散システムの全体構成を概略的に示すブロック図である。

本実施の形態に係る負荷分散システムは図１のように複数のクライアント１００（＃１，＃２・・・＃ｎ）と、複数のサーバ１０２（＃１，＃２・・・＃ｎ）とクライアント１００（＃１，＃２・・・＃ｎ）からの処理要求をサーバ１０２（＃１，＃２・・・＃ｎ）の負荷を分散させるように各サーバ１０２（＃１，＃２・・・＃ｎ）に振り分ける負荷分散装置１０１を備えた負荷分散システム１０に適用され、クライアント１００（＃１，＃２・・・＃ｎ）からの処理要求数にもとづき停止、または起動させることが可能なサーバを決定することができる、負荷分散システムであり、図１における負荷分散装置１０１に備えられる。

各クライアント１００（＃１，＃２・・・＃ｎ）、各サーバ１０２（＃１，＃２・・・＃ｎ）の負荷制御および負荷情報の取得を行う負荷分散装置１０１および各サーバ１０２（＃１，＃２・・・＃ｎ）はＬＡＮ１０３に接続され、ルータ等を介して複数のサブネットから構成される場合もある。

この負荷分散システム１０では処理要求数が減少した場合、サーバの必要台数を計算し停止可能なサーバがあるか否かを判定し、停止可能なサーバがあると判定された場合は、サーバ１０２（＃１，＃２・・・＃ｎ）のうち何れかが停止される。また、処理要求数が増加した場合もサーバの必要台数を計算し、起動が必要なサーバがあると判定された場合は、停止中のサーバの何れかが起動される。これを実現するために、負荷分散装置１０１は図２、図３、および図４に示す構成をしている。

図２は負荷分散装置の概略構成図であり、クライアント１００（＃１，＃２・・・＃ｎ）およびサーバ１０２（＃１，＃２・・・＃ｎ）をＬＡＮ１０３で接続するためのスイッチ部２００、スイッチ部２００を制御するコントローラ２０１、クライアントからの処理要求数の収集、サーバの負荷情報収集、収集した情報から停止可能なサーバ、または起動が必要なサーバがあるか否か等の判定処理を行うＣＰＵ部２０２、ＣＰＵ部２０２が使用するメモリ２０３、収集したデータを格納しておくディスク部２０４から構成される。
クライアント１００（＃１，＃２・・・＃ｎ）からの処理要求は負荷分散装置１０１により各サーバ１０２（＃１，＃２・・・＃ｎ）に振り分けられて処理されているが、処理要求数の大小によりサーバの負荷は変わってくる。

図３の負荷情報収集部３０１は単位時間毎にサーバの負荷情報を収集し、情報保存部３０２が収集した情報を保存している。負荷分散装置１０１から、ある時間の情報送信要求をデータ送受信部３０４が受け取ると、情報抽出部３０３は情報保存部３０２により保存された負荷情報を検索し指定時間のサーバ負荷情報を抽出しデータ送受信部３０４に渡す。データ送受信部３０４は受け取ったサーバ負荷情報を負荷分散装置１０１に送信する。

図４はサーバの停止または起動の判定と、サーバの停止または起動処理を行う負荷分散装置に備えられた機能ブロック図である。
データ収集および統合部４０２は、クライアント１００（＃１，＃２・・・＃ｎ）からの処理要求数と、稼働サーバ台数を収集し、単位時間ごとの最大値を求め、最大値が観測された時間の各サーバ１０２（＃１，＃２・・・＃ｎ）の負荷情報を送受信部４０３を介して、データ送受信部３０４に送ることで取得する。データ収集および統合部４０２は送受信部４０３を介して取得したサーバ負荷情報と、自身が取得した処理要求数の最大値と、最大値観測時点の稼働サーバ台数と、データを収集した時間帯を関連付けるようにデータを統合する。この処理は単位時間間隔で繰り返し行われる。

最大値比較部４０１は、最大値管理部４０４によって管理されている過去の単位時間毎の統合データから、今回生成された統合データの時間帯を指定して、過去の統合データを抽出する。抽出した過去の統合データと今回生成された統合データの処理要求数の最大値を比較する。今回生成された統合データの処理要求数の最大値が大きければデータを更新し、最大値管理部４０４を介して保存する。保存されたデータは図９の形式をしている。なお、最大値管理部４０４を介して保存したデータは人手入力手段を用いて更新することもできる。

判定部４０５の動作は図５のフローチャートを使用して説明する。判定部４０５は過去の各時間帯毎の最大処理要求数９０２の中から最も大きな値（図９の例では２５５）を検索し、そのレコートを最大値管理部４０４を介して取得する（ステップＳ１１）。取得したレコードの最大処理要求数と稼働台数から、サーバ１台あたりの処理数を求める（ステップＳ１２）。また最新の統合データをデータ収集および統合部４０２から取得する（ステップＳ１３）。次に取得したレコードから各サーバの負荷状況をチェックする（ステップＳ１４）。各サーバの負荷状況が予め指定した値より大きければ過負荷状態と判定して（ステップＳ１５）、指定された係数を掛けて、サーバ１台あたりの処理数とする（ステップＳ１６）。

次にステップＳ１３で取得した最新の統合データから処理要求数を取り出し、最新の処理要求数とステップＳ１２またはステップＳ１６で求めたサーバ１台あたりの処理数から、現時点での必要サーバ台数を求める（ステップＳ１７）。また、統合データから現時点で稼働しているサーバの台数を取得し（ステップＳ１８）、稼働台数と必要台数の関係を調べる（ステップＳ１９）。必要台数より稼働台数のほうが大きければサーバ停止用カウンタを１加算し（ステップＳ２０）、サーバ停止用カウンタがあらかじめ設定した値に達したか判定する（ステップＳ２１）。達していなければ、一定時間待ち（ステップＳ２４）、ステップＳ１３を実行する。達していれば、サーバ停止の通知と、停止サーバ台数をサーバ決定部に行い（ステップＳ２２）、サーバ停止用カウンタを０に設定する（ステップＳ２３）。
ステップＳ１９で稼働台数より必要台数のほうが大きければ、停止中サーバの起動が必要と判断し、サーバ起動の通知と、起動サーバ台数をサーバ決定部に行う。

サーバ決定部４０６は判定部４０５から通知がくるまで待機していて（ステップＳ３１）、通知が来ると処理を開始する。判定部４０５から通知が来るとサーバ情報管理部４０７を介して過去の停止サーバ情報を取得し（ステップＳ３２）、その後、判定部４０５からの通知がサーバ停止の通知なのか、サーバ起動の通知なのか識別（ステップＳ３３）する。判定部４０５からの通知が停止の場合（ステップＳ３４）は、判定部４０５から受け取った停止サーバ台数を確認し（ステップＳ３５）、停止サーバ台数と、ステップＳ３２で取得した過去の停止サーバ情報から今回停止するサーバを選択する（ステップＳ３６）。停止するサーバは、停止回数に偏りが発生しないよう停止回数の少ないサーバから選択される。停止回数が同じ場合は、あらかじめ決められた方法で選択される。例えばリストの上から順に選択する方法がある。停止するサーバが選択できれば、振り分け抑止部４０８に選択したサーバの情報と、振り分け抑止の開始を通知し（ステップＳ３７）、今回選択したサーバ停止情報をサーバ情報管理部４０７を介して更新する（ステップＳ３８）。

判定部４０５からの通知がサーバ起動の通知であった場合は、判定部４０５から受け取った起動サーバ台数を確認し（ステップＳ３９）、起動サーバ台数と、サーバ情報管理部４０７を介して取得した停止サーバ情報から今回起動するサーバを選択する（ステップＳ４０）し、サーバ制御部４０９に通知し（ステップＳ４１）、今回選択した起動サーバの情報をサーバ情報管理部４０７を介して更新する（ステップＳ３８）。起動するサーバは、起動回数に偏りが発生しないよう停止回数の多いサーバから選択される。停止回数が同じ場合は、あらかじめ決められた方法で選択する。例えばリストの上から順に起動する方法がある。

振り分け抑止部４０８はサーバ決定部４０６からの通知があると処理を開始し（ステップＳ５１）、停止対象サーバの情報を受け取り確認し（ステップＳ５２）、振り分け抑止対象サーバに対して、クライアント１００（＃１，＃２・・・＃ｎ）からの新規の処理要求をあらかじめ決められた方法で振り分けないようにする（ステップＳ５３）。振り分けを抑止する方法として、例えば負荷分散装置１０１の設定変更をおこなう方法がある。ここでいう新規の処理要求とは、業務開始時の処理要求のように、一連の操作の開始となる処理要求を意味している。振り分け抑止処理が終了すると、振り分け抑止対象サーバ情報と、振り分け抑止終了の通知をサーバ制御部に行う（ステップＳ５４）。
サーバ制御部４０９は振り分け抑止部４０８からの通知を受け取ると処理を開始する。振り分け抑止部４０８からの通知があれば（ステップＳ６１）、振り分け抑止処理を行ったサーバに対しクライアント１００（＃１，＃２・・・＃ｎ）からの継続処理要求数を定期的にチェックする（ステップＳ６３）。
ここでいう継続処理要求とは開始した業務を継続するための処理要求のように、一連の操作の途中の処理要求を意味する。継続処理要求数が０になった場合は（ステップＳ６４）、振り分け抑止を行ったサーバに対して、シャットダウンコマンドを発行する（ステップＳ６５）。サーバはＩＰＭＩ（intelligent platform management interface ）インタフェース経由でシャットダウンコマンドを受け取るとシャットダウン処理を開始する。ここでいう継続処理要求数が０の状態とは、処理する要求が全て無くなり、新規の処理要求もこない状態を意味している。ステップＳ６１で振り分け抑止部４０８からの通知がない場合は、サーバ決定部４０６からの通知があるか確認する（ステップＳ６２）。サーバ決定部４０６からの通知があれば、起動するサーバを確認し、起動対象サーバに対して電源ＯＮコマンドを発行する（ステップＳ６６）。サーバはＩＰＭＩインタフェース経由で電源ＯＮコマンドを受け取ると、起動処理を開始する。

次に最大値管理部４０４が管理している最大値情報を使用してサーバ起動のスケジュールを作成する方法について説明する。
最大値情報（図９）には時間９０１と、その時間帯の最大処理要求数９０２と、その時点の稼働サーバ数９０９があるので、あらかじめ、どの時間帯で何台のサーバが複数クライアント１００（＃１，＃２，・・・＃ｎ）からの処理要求を処理していたか知り得ることができる。最大値管理部４０４は、最大値データの通りにサーバを稼働させるために、時間９０１と、稼働台数９０９と使用してサーバを起動するスケジュールを作成する。サーバを起動する時間は、時間９０１の時間より前となるようにスケジュールする。そして、作成したスケジュールをサーバ制御部４０９に送付する。サーバ制御部４０９は送付されたスケジュールに基づいてサーバを起動していく。サーバの起動方法は前述の通り。

１０・・・負荷分散システム、１００・・・クライアント、１０１・・・負荷分散装置、１０２・・・サーバ、１０３・・・LAN、２００・・・スイッチ部、２０１・・・コントローラ、２０２・・・ＣＰＵ、２０３・・・メモリ、２０４・・・ディスク、３０１・・・負荷情報収集部、３０２・・・情報保存部、３０３・・・情報抽出部、３０４・・・データ送受信部、４０１・・・最大値比較部、４０２・・・データ収集および統合部、４０３・・・送受信部、４０４・・・最大値管理部、４０５・・・判定部、４０６・・・サーバ決定部、４０７・・・サーバ情報管理部、４０８・・・振り分け抑止部、４０９・・・サーバ制御部

Claims

複数サーバと、複数クライアントからの処理要求を分散して前記複数サーバに割り振る負荷分散装置を備えた負荷分散システムであって、
前記複数サーバそれぞれの負荷情報を取得する負荷情報取得手段と、
前記複数クライアントからの処理要求数を収集し、単位時間ごとの最大値を求める処理要求数収集手段と、
単位時間ごとにサーバの生死情報を取得するサーバ監視手段と、
前記負荷情報取得手段で取得した負荷情報と、前記処理要求数収集手段によって求められた最大値を関連付けるデータ統合手段と、
前記データ統合手段により統合されたデータと、格納されている過去の最大処理要求数の関係からを最大値の更新を行う基本情報格納手段と、
過去のデータを人手で更新できる入力手段と、
前記基本情報格納手段によって、格納されている過去の処理要求数の最大値と、前記データ統合手段により統合された最大処理要求数の関係から、現在の必要サーバ台数を計算し、前記監視手段によって取得される現在の稼働サーバ数を比較して停止可能なサーバ、または起動するサーバがあるか否かを判定する判定手段と、
前記判定手段が規定回数連続で同じ判定を行ったか監視する判定監視手段と、
前記判定監視手段によって規定回数連続で同じ判定が行われた場合に、過去の停止サーバ情報から、どのサーバを停止させるかを決定するサーバ決定手段と、
前記サーバ決定手段によって決定されたサーバへの前記複数クライアントからの処理要求の振り分けを抑止する振り分け抑止手段と、
前記サーバ決定手段により決定された停止対象サーバの情報を格納しておくサーバ情報格納手段と、
前記振り分け抑止手段により、振り分けを抑止したサーバの処理要求がなくなったことを検出する検出手段と、
前記検出手段によって、サーバの処理要求がなくなったことが確認できたとき、または前記判定手段の結果から停止中のサーバを稼働させる必要があると判定された場合に、サーバの電源を制御する電源制御手段とを備えた負荷分散システム。
前記基本情報格納手段によって格納されている過去の単位時間毎の最大値から、その時間の必要サーバ数を計算する計算手段と、
前記計算手段の結果から停止中のサーバを稼働させるスケジュールを作成するスケジュール手段と、
前記スケジュール手段によって作成されたスケジュールにもとづきサーバを稼働させるサーバ稼働手段とを備えた請求項１記載の負荷分散システム。