JP2009244945A - 負荷分散プログラム、負荷分散方法、負荷分散装置およびそれを含むシステム - Google Patents

Abstract

【課題】保守者に負担をかけなくても、サーバの更新にかかる時間を短縮する。
【解決手段】負荷分散装置１は、各サーバ４ａ〜４ｅの処理の量を示すデータを記録部に格納する監視部１４と、サーバ４ａ〜４ｅの更新準備要求を受信する要求受付部８１と、
未更新であってかつ処理の量が最も少ないサーバを更新対象サーバと次回更新対象サーバとを決定する更新サーバ決定部９１と、前記更新対象サーバと、次回更新対象サーバとに対する端末からの新規処理要求の割り当ての比率は０にするように分散比率を設定する分散比率設定部９２と、分散比率に基づいて、端末からの新規処理要求を転送する負荷分散部と、更新対象サーバの処理の量が０になると、更新対象サーバが更新可能である旨を通知する通知部８２と、更新対象サーバの更新終了を受け付ける更新終了検知部８３とを備える。
【選択図】図１

Description

本発明は、端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送するための負荷分散装置、負荷分散プログラムおよび負荷分散方法に関する。

近年、例えば、ＩＰ（Internet Protocol）ネットワーク上でＷｅｂサイト、電子メール、ＩＰ電話、ファイルサーバといった様々なサービスを提供するサービス提供サーバが存在する。サービス提供サーバは、例えば、Ｗｅｂ、ＦＴＰ（File Transfer Protocol）、Ｔｅｌｎｅｔ等を用いたサービスをクライアントに対して提供している。このようなサービス提供サーバは、利用者が増えて、サービスの規模が大きくなってくると、安定したサービスを提供するために何らかの対策を行う必要がある。この対策として、例えば、既存のサービス提供サーバと同等程度の性能を持つサービス提供サーバを増設することが挙げられる。この場合、負荷分散装置を用いて複数のサービス提供サーバに負荷を分散させる負荷分散システムが構築される。

負荷分散装置は、サービス利用者（クライアント）の端末からの処理の要求を受信し、同一サービスを提供する複数のサービス提供サーバに振り分けることで、特定のサービス提供サーバに対する負荷の軽減を実現する装置である。負荷分散装置は、例えば、クライアントの端末とサービス提供サーバ群との間に設置される。負荷分散装置の導入により、特定のサービス提供サーバへの負荷の集中によるサービス品質の低下を回避し、クライアントへの快適なサービス提供を目指すことができる。

ところで、サービス提供サーバを構成するソフトウエアまたはハードウエアは、サービス提供サーバの運用開始後も、例えば、バグの改修、機能改善、セキュリティ面での強化など、様々な要因で更新が必要となる。サービス提供サーバのソフトウエアの更新として、例えば、アプリケーションのアップグレード、セキュリティパッチの適用、カーネルやファームウエアの更新等が挙げられる。このようなソフトウエアの更新は、保守者がＣＤ（Compact Disc）やフラッシュメモリなどの可搬記憶媒体を使用して行われる場合がある。もしくは、自動更新機能を有するアプライアンスサーバによりサービス提供サーバのソフトウエアの更新が行われる場合もある。

アプライアンスサーバは、特定の用途向けに設計・開発されたサーバである。自動更新機能を有するアプライアンスサーバは、例えば、セキュリティホールの発覚や不具合発生に対応するためのソフトウエア更新情報（パッチ類）を、提供側ベンダと連携してネットワークを介して自動的に検出する。そして、アプライアンスサーバは、検出した更新情報に基づいて、保守対象のサーバに対して自動的に更新作業を行う。

サービス提供サーバのソフトウエアを更新する際、更新中は、サービス提供サーバの動作が不安定になるので、サービス提供機能は停止する必要がある。例えば、サーバのソフトウエア構成を変更する際に、ソフトウエア構成変更対象となるサーバにクライアントからの計算処理リクエストを配分しないようにするとともに、一定時間経過するか、サーバに残留する計算処理リクエスト数を確認してからソフトウエア構成を変更する方法が提案されている（例えば、特許文献１参照）。
特開２００６−２８５３１５号公報

サーバ提供サーバが更新される際に、クライアントから要求された処理が途中でエラーになることを避けるために、まず、クライアントから更新対象のサーバ提供サーバへのアクセスが無い状態にする必要がある。このために、負荷分散装置は、更新しようとするサービス提供サーバにおいて、すでに存在するアクセス（処理）以外は振り分けないようにし（以下、これを「予閉塞」と称する）、すでに存在していたアクセス（処理）の終了をもって、該サービス提供サーバへのアクセスを完全に停止する（以下、これを「閉塞」と称する）、という手順を踏むことができる。

サービス提供サーバの更新にかかる時間には、この予閉塞から閉塞に至る時間が大きく影響し、これを短くすることが望まれる。例えば、複数のサービス提供サーバの更新順序および振り分け条件を、予閉塞から閉塞に至る時間が短くなるように、適切に決定することが考えられる。しかしながら、適切な更新順序および振り分け条件を決定するには、負荷状況やサーバの性能など、多くの条件を考慮せねばならない。そのため、保守者がこれを検討するには非常に大きな労力を要する。また、複数のサービス提供サーバの更新処理の進行に伴って、１台のサービス提供サーバについての更新処理が終了する度に、振り分け条件の設定変更を保守者が行わねばならず、保守者の作業負荷が大きい。

ゆえに、本発明は、保守者に負担をかけなくても、サーバの更新にかかる時間を短縮することができる、負荷分散装置、負荷分散プログラムおよび負荷分散方法を提供することを目的とする。

本願に開示する負荷分散装置は、端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送する負荷分散装置であって、前記複数のサーバ各々と端末との通信データまたは前記複数のサーバ各々の稼動状態を監視することにより、各サーバが端末からの処理要求を受けて実行している処理の量を示すデータを記録部に格納する監視部と、保守者端末または自動更新サーバから、前記複数のサーバの更新準備の要求を受信する要求受付部と、前記複数のサーバのうち、未更新のサーバであって、かつ、前記記録部のデータが示す当該サーバの処理の量が最も少ないサーバを更新対象サーバとし、前記更新対象サーバ以外の未更新のサーバであって、かつ、当該サーバの処理の量が最も少ないサーバを次回更新対象サーバとする、更新サーバ決定部と、前記更新対象サーバ及び次回更新対象サーバとして決定されたサーバに対しては、端末からの新規処理要求の割り当てを行わず、他のサーバへ端末からの新規処理要求を割り当てるように、前記複数のサーバ各々に対する新規処理要求の分散比率を設定し前記記録部へ記録する、分散比率設定部と、前記分散比率に基づいて、端末からの新規処理要求を前記複数のサーバのうち少なくとも１つに割り当てて転送する負荷分散部と、前記記録部のデータが示す前記更新対象サーバの処理の量を監視し、前記更新対象サーバが更新可能な状態になったと判断すると、前記保守者端末または自動更新サーバに対して、前記更新対象サーバが更新可能である旨を通知する通知部と、前記保守者端末または自動更新サーバから、前記更新対象サーバの更新が終了した旨の通知を受け付ける更新終了検知部とを備え、前記更新終了検知部が、前記更新対象サーバの更新が終了した旨の通知を受けた場合、前記更新サーバ決定部は、更新が終了した前記更新対象サーバを、更新済みとして、新たな更新対象サーバおよび次回更新対象サーバを決定し、前記分散比率設定部に、分散比率の設定を指示する。

上記構成により、要求受付部が更新要求を受けた場合、更新サーバ決定部は、端末から要求された処理の処理量が最も少ないサーバを更新対象サーバ、その次に処理量が少ないかまたは同じであるサーバを次回更新対象サーバに決定する。そして、分散比率設定部により、更新対象サーバと、次回更新対象サーバへの新規処理要求の割り当て比率は０に設定される。これにより、負荷分散部は、端末からの新たな処理要求を、更新対象サーバと、次回更新対象サーバには転送せず、その他のサーバに転送する。そのため、更新対象サーバおよび次回更新対象サーバの処理の量は減り続けやがて０になる。ここで、更新サーバ決定部が、処理量の最も少ないサーバを更新対象サーバとすることによって、処理量が０になるまでの時間が最も短いと予測されるサーバが更新対象サーバになる。また、通知部が更新対象サーバを保守者または自動更新サーバに通知して、保守者または自動更新サーバが更新対象サーバを更新している間にも、次回更新対象サーバの処理量は減り続ける。そして、更新終了受付部が更新対象サーバの更新終了通知を受けて、更新サーバ決定部が新たな更新対象サーバおよび新たな次回更新対象サーバを決定する際には、次回更新対象サーバの処理量が減少している。そのため、この処理量が減少した次回更新対象サーバまたはそれより処理量の少ないサーバが新たな更新対象サーバになる。したがって、新たな更新対象サーバの処理量が０になるまでの時間が短くて済むようになる。その結果、保守者に負担をかけなくても、サーバの更新にかかる時間が短縮される。ひいては、サーバの更新によるサーバの処理能力への影響を抑えることができる。

本願明細書に開示の負荷分散装置によれば、保守者に負担をかけなくても、サーバの更新にかかる時間を短縮することが可能になる。なお、コンピュータを上記負荷分散装置として機能させる負荷分散プログラムおよび負荷分散方法によっても、同様の効果が得られる。

本発明の実施形態において、前記監視部は、前記複数のサーバ各々の負荷を示すデータも前記記録部に記録し、前記分散比率設定部は、前記記録部に記録された複数のサーバ各々の負荷に基づいて、前記更新対象サーバおよび前記次回更新対象サーバ以外の分散比率を計算する態様でもよい。

これにより、分散比率設定部は、各サーバにかかる負荷の状況に応じた分散比率を決定することができる。例えば、負荷の高いサーバに割り当てる比率を低くするなどといったサーバの負荷に応じた分散比率の調整が可能になる。

本発明の実施形態において、前記要求受付部は、ネットワークを介して、前記複数のサーバの更新情報を検出した自動更新サーバから、前記更新情報に係る更新要求を受け付けてもよい。

これにより、自動更新サーバが検出した更新情報に基づく更新が、前記複数のサーバに対して自動的に実行され、サーバの更新にかかる時間が短縮される。その際、更新に伴うサーバの機能低下による影響が抑えられる。

本発明の負荷分散システムは、端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送する負荷分散装置と、前記複数のサーバを自動更新する自動更新サーバとを含む負荷分散システムである。前記自動更新サーバは、ネットワークを介して、前記複数のサーバの更新情報を検出する更新情報監視部と、前記更新情報を検出された場合に、前記負荷分散装置に対して、前記複数のサーバの更新要求を送信する通信部と、前記更新情報に基づいて前記複数のサーバを自動更新する自動更新部とを備える。前記負荷分散装置は、前記複数のサーバ各々と端末との通信データまたは前記複数のサーバ各々の稼動状態を監視することにより、各サーバが端末からの処理要求を受けて実行している処理の量を示すデータを記録部に格納する監視部と、自動更新サーバから、前記複数のサーバの更新準備の要求を受信する要求受付部と、前記複数のサーバのうち、未更新のサーバであって、かつ、前記記録部のデータが示す当該サーバの処理の量が最も少ないサーバを更新対象サーバとし、前記更新対象サーバ以外の未更新のサーバであって、かつ、当該サーバの処理の量が最も少ないサーバを次回更新対象サーバとする、更新サーバ決定部と、前記更新対象サーバ及び次回更新対象サーバとして決定されたサーバに対しては、端末からの新規処理要求の割り当てを行わず、他のサーバへ端末からの新規処理要求を割り当てるように、前記複数のサーバ各々に対する新規処理要求の分散比率を設定し前記記録部へ記録する、分散比率設定部と、前記分散比率に基づいて、端末からの新規処理要求を前記複数のサーバのうち少なくとも１つに割り当てて転送する負荷分散部と、前記記録部のデータが示す前記更新対象サーバの前記処理の量を監視し、前記更新対象サーバが更新可能な状態になったと判断すると、前記自動更新サーバに対して、前記更新対象サーバが更新可能である旨を通知する通知部と、前記自動更新サーバから、前記更新対象サーバの更新が終了した旨の通知を受け付ける更新終了検知部とを備え、前記更新終了検知部が、前記更新対象サーバの更新が終了した旨の通知を受けた場合、前記更新サーバ決定部は、更新が終了した前記更新対象サーバを、更新済みとして、新たな更新対象サーバおよび次回更新対象サーバを決定し、前記分散比率設定部に、分散比率の設定を指示する。

本願に開示する負荷分散プログラムは、端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送する処理をコンピュータに実行させる負荷分散プログラムであって、前記複数のサーバ各々と端末との通信データまたは前記複数のサーバ各々の稼動状態を監視することにより、各サーバが端末からの処理要求を受けて実行している処理の量を示すデータを前記コンピュータがアクセス可能な記録部に格納する監視処理と、保守者端末または自動更新サーバから、前記複数のサーバの更新準備の要求を受信する要求受付処理と、前記複数のサーバのうち、未更新のサーバであって、かつ、前記記録部のデータが示す当該サーバの処理の量が最も少ないサーバを更新対象サーバとし、前記更新対象サーバ以外の未更新のサーバであって、かつ、当該サーバの処理の量が最も少ないサーバを次回更新対象サーバとする、更新サーバ決定処理と、前記更新対象サーバ及び次回更新対象サーバとして決定されたサーバに対しては、端末からの新規処理要求の割り当てを行わず、他のサーバへ端末からの新規処理要求を割り当てるように、前記複数のサーバ各々に対する新規処理要求の分散比率を設定し前記記録部へ記録する分散比率設定処理と、前記分散比率に基づいて、端末からの新規処理要求を前記複数のサーバのうち少なくとも１つに割り当てて転送する負荷分散処理と、前記記録部のデータが示す前記更新対象サーバの前記処理の量を監視し、前記更新対象サーバが更新可能な状態になったと判断すると、前記保守者端末または自動更新サーバに対して、前記更新対象サーバが更新可能である旨を通知する通知処理と、前記保守者端末または自動更新サーバから、前記更新対象サーバの更新が終了した旨の通知を受け付ける更新終了検知処理とをコンピュータに実行させ、前記更新終了検知処理において、前記更新対象サーバの更新が終了した旨の通知を受けた場合であってかつ未更新のサーバが存在する場合は、更新が終了した前記更新対象サーバを更新済みとして、前記更新サーバ決定処理、前記分散比率設定処理、前記負荷分散処理、通知処理および前記更新終了検知処理を繰り返しコンピュータに実行させる。

（第１の実施形態）
＜ネットワーク構成＞
図１は、第１の実施形態の負荷分散装置を含むネットワーク全体の構成を示す図である。本実施形態の負荷分散装置１は、ユーザ端末５ａ〜５ｃからサーバ４ａ〜４ｅに対する処理要求を、ネットワーク６を介して受信し、サーバ４ａ〜４ｅのいずれかに振り分ける。さらに、負荷分散装置１は、サーバ４ａ〜４ｅの機能を更新する際に、更新に必要な時間が短く、かつ保守者に負担が係らぬように、効率よく複数のサーバ４ａ〜４ｅへ負荷を分散する機能も備える。

図１に示すように、負荷分散装置１は、ネットワーク６を介してユーザ端末５ａ〜５ｃからアクセス可能な位置に設けられ、かつ、サーバ４ａ〜４ｅに接続されている。また、サーバ４ａ〜４ｅおよび負荷分散装置１は、保守者端末２からもアクセス可能になっている。サーバ４ａ〜４ｅの保守者は、保守者端末２を介して、サーバ４ａ〜４ｅに対して、各種データの設定、ハードウエアまたはソフトウエアの更新など、サーバ４ａ〜４ｅの保守のために必要な操作が可能である。また、保守者は、保守者端末２を介して、負荷分散装置１に対して、動作を指示することができる。

サーバ４ａ〜４ｅは、ユーザ端末５ａ〜５ｃからの処理要求を受け取って、所望の処理を実行し処理結果を返信する。これにより、サーバ４ａ〜４ｅは、ユーザ端末５ａ〜５ｃのユーザへサービスを提供する。本実施形態では、サーバ４ａ〜４ｅは、いずれも同じ機能を持ち、同一サービスを提供する。ユーザ端末５ａ〜５ｃからの処理要求は、負荷分散装置１によってサーバ４ａ〜４ｅのいずれかに転送され、処理される。

サーバ４ａ〜４ｅが提供するサービスの種別や内容は特に限定されない。例えば、Ｗｅｂ、ＦＴＰまたはＴｅｌｎｅｔなどを用いて情報を提供するサービスの他、電子商取引、ＡＳＰ（Application Service Provider）などの情報サービスがサーバ４ａ〜４ｅにより提供されうる。ユーザ端末５ａ〜５ｃからサーバ４ａ〜４ｅへの処理要求の例として、ＨＴＴＰ（HyperText Transfer Protocol）リクエスト、ＦＴＰリクエスト、ｔｅｌｎｅｔ通信のコマンド等が挙げられる。

本実施形態では、一例として、サーバ４ａ〜４ｅはファイルを公開して、ユーザに対して提供しており、ユーザ端末５ａ〜５ｃは負荷分散装置１を経由してサーバ４ａ〜４ｅのいずれか１台とＨＴＴＰコネクションを確立し、公開ファイルのダウンロードが完了したらＨＴＴＰコネクションを終了する場合について説明する。

負荷分散装置１は、本実施形態のように、同一サービスを提供する複数のサーバに処理を分散させる場合に限られず、例えば、サービス種別の異なる複数のサーバに処理を分散する構成であってもよい。

ネットワーク６は、例えば、インターネット、イントラネット等である。また、ネットワーク６は、さらに回線交換網、移動体通信網等の他のネットワークに接続されてもよい。このように接続される他のネットワークのユーザ端末も、サーバ４ａ〜４ｅへ処理要求を送信することができる。なお、ネットワーク６に接続されるユーザ端末や、サーバの台数は、図１に示す例に限られない。図１では、ユーザ端末の数は、紙面の制約から３台しか描いていないが、以下では、ユーザ端末は、１０００台以上接続されている場合を説明する。

＜負荷分散装置１の構成＞
図２は、負荷分散装置１の構成を示す機能ブロック図である。負荷分散装置１は、通信部８、保守制御部９、記録部１１、受信部１２、負荷分散部１３および監視部１４を備える。通信部８は、要求受付部８１、通知部８２および更新終了検知部８３を含む。記録部１１には、更新管理テーブル４１および監視データテーブル４２が記録される。

負荷分散装置１は、例えば、コンピュータを内蔵する専用装置、もしくはパーソナルコンピュータやサーバマシン等の汎用コンピュータにより構成することができる。通信部８、保守制御部９、受信部１２、負荷分散部１３および監視部１４の各機能部の機能は、コンピュータが備えるプロセッサが所定のプログラムを実行することにより実現される。従って、コンピュータを前記各機能部として機能させるためのプログラムおよびそれを記録した記録媒体も本発明の実施形態に含まれる。このことは、後述する図１０における各機能部についても同様である。また、記録部１１は、コンピュータに内蔵された記録媒体または、コンピュータからアクセス可能な外部記録装置により具現化される。

なお、負荷分散装置１の構成は、図１および図２に示す例に限られない。例えば、負荷分散装置１の各機能ブロックは互いに接続された複数のコンピュータに分散して設けられてもよい。以下、負荷分散装置１の各機能部について説明する。

＜受信部１２および負荷分散部１３＞
受信部１２は、ユーザ端末５ａ〜５ｃから受信したフレームを解析して、フレームの送信元を特定し、負荷分散部１３に転送する。負荷分散部１３は、受け取ったフレームを、分散比率設定部によって設定された振り分け比率（分散比率）に従って、サーバ４ａ〜４ｅのいずれかに振り分けて転送する。振り分け方法として、例えば、静的な重み付き
ラウンドロビンを用いることができる。

また、負荷分散部１３は、フレームの送信元も考慮して振り分けを行ってもよい。例えば、負荷分散部１３は、同一端末からの一連の通信におけるフレームは、同じサーバに転送することができる。これにより、例えば、サーバ４ａとユーザ端末５ａとの間でコネクションが確立した場合、そのコネクション確立から終了までにユーザ端末５ａから送信されるフレームは、全てサーバ４ａに転送されるようになる。

なお、受信部１２および負荷分散部１３による負荷分散処理は、上記例のフレーム単位に振り分ける場合に限られない。例えば、さらに上位レイヤのパケット単位で振り分けることもできるし、その他のレイヤのデータ単位で振り分けることもできる。

＜監視部１４＞
監視部１４は、クライアントからのトラフィック（ここでは、受信フレーム）の監視・解析を行い、振り分け対象のサーバ４ａ〜４ｅ毎のトラフィック情報（例えばセッション数やコネクション数）を記録部１１の監視データテーブル４２に登録する。また、監視部１４は、サーバ４ａ〜４ｅと通信を行い、サーバ４ａ〜４ｅ各々のＣＰＵ負荷、メモリ使用率等の負荷情報を収集し、監視データテーブル４２に登録する。すなわち、監視部１４は、トラフィック監視機能と、サーバ監視機能とを備える。ここで、サーバが送受信する情報から得られるトラフィック情報およびサーバの負荷を示す負荷情報は、いずれも、各サーバが端末から要求された処理量を示すデータの一例である。

下記表１は、監視データテーブル４２に記録されるデータ内容の一部の例を示す表である。下記表１では、セッション数、コネクション数、ＣＰＵ負荷、メモリ使用率および帯域占有率がサーバごとに記録されている。なお、監視データテーブル４２には、下記表１に示す内容に限られず、その他、監視によって得られるデータが記録されてよい。

監視データテーブル４２のデータは、本実施形態では、保守制御部９のサーバ４ａ〜４ｅの更新時の処理に使われる。すなわち、保守制御部９は、後述するように、サーバ４ａ〜４ｅの短時間の効率よい更新を可能にするために必要なデータを、監視データテーブル４２から取り出し、更新管理テーブル４１へ記録する。

＜通信部８＞
通信部８は、負荷分散装置１が保守者端末２とデータの送受信を行うためのインタフェース機能を有する。要求受付部８１は、保守者端末２から、サーバ４ａ〜４ｅに対する更新要求を受信する。更新要求には、例えば、更新したいサーバ（以下、保守対象サーバと称する）を特定する情報が含まれる。要求受付部８１は、更新要求を保守制御部９へ渡す。

保守制御部９は、更新要求を受けると、保守対象サーバの更新のために必要なデータを記録する更新管理テーブル４１を記録部１１に作成する。そして、更新サーバ決定部９１および分散比率設定部９２が、更新管理テーブル４１のデータを用いて、後述するように、更新対象サーバの決定処理および分散比率の設定処理をそれぞれ実行する。

通知部８２は、保守制御部９からの通知に基づき、更新対象サーバの更新作業開始が可能になった旨を保守者端末２へ通知する。通知には、更新可能になった更新対象サーバを特定する情報が含まれる。保守者は、この通知を受けて更新対象サーバの更新作業を開始することができる。保守者は、更新作業が終了すると、更新作業終了した旨を、保守者端末２を用いて負荷分散装置１へ通知する。

更新終了検知部８３は、保守者端末２からの、前記更新対象サーバの更新が終了した旨の通知を受け付ける。この通知を受け付けると、更新終了検知部８３は、保守制御部９に、更新が終了したサーバを通知する。保守制御部９がこの通知を受けると、この通知に基づいて、更新サーバ決定部９１および分散比率設定部９２が動作する。

通信部８と保守者端末２との間の通信方法は特に限定されない。例えば、通信部８と保守者端末２との通信として、ＴｅｌｎｅｔやＳＳＨ（Ｓｅｃｕｒｅ Ｓｈｅｌｌ）等のプログラムを利用した通信、電子メールを利用した通信、またはこれらの組み合わせた通信が可能である。例えば、要求受付部８１は、Ｔｅｌｎｅｔで保守者端末２と通信し、通知部８２および更新終了検知部８３は、電子メールで保守者端末２と通信する形態であってもよい。

＜保守制御部９＞
保守制御部９は、上述のように、要求受付部８１から更新要求を受け取ると、更新管理テーブル４１を生成し、記録部１１に記録する。更新管理テーブル４１には、例えば、保守対象サーバ各々のユーザ端末からの要求にかかる処理の処理量を示すデータ、更新済みか否かを示すデータ、更新対象サーバおよび次回更新対象サーバを特定するデータが含まれる。

保守制御部９により、監視データテーブル４２から必要なデータを抽出し、前記処理量を示すデータとして更新管理テーブル４１に記録する。更新管理テーブル４１生成時には、例えば、処理量を示すデータと、更新済みか否かを示すデータが記録される。

下記表２は、更新管理テーブル４１に記録されるデータ内容の一例を示す図である。表２に示す例は、保守制御部９が、更新要求を受けて生成した時点（保守開始時）のデータの一例である。

上記表２に示す例では、コネクション数、ＣＰＵ負荷、振り分け比率（分散比率）、および更新状態がサーバ４ａ〜４ｅごとに記録されている。ここで、一例として、更新状態は、「未更新」、「更新済」、「更新対象」および「次回更新対象」の４つの状態のいずれかが記録される。上記表２に示すように、保守制御部９が、更新管理テーブル４１を生成する時点では、全てのサーバの更新状態に「未更新」が記録される。

ここで、「更新対象サーバ」は、現時点で更新するべきサーバである。具体的には、現時点で更新作業を行うために、現時点で、最初に、負荷分散装置１が閉塞するべきサーバである。なお、サーバにおいて、ユーザ端末から処理要求にかかる処理の処理量が０となった状態を閉塞と称する。なお、本実施例では、処理の処理量が数値化されている例で説明するが、サーバの可能な処理量に比して、どのぐらいの処理量となっているかを、「高」「中」「低」「無」といった段階的な値に変換し、「無」の状態になったら、閉塞と判断するようにしてもよい。また、負荷分散装置１が、サーバを閉塞するために、ユーザ端末からの新たな処理要求をサーバに振り分けないようにすることを予閉塞と称する。予閉塞は、具体的には、ユーザ端末からの新たな処理要求をサーバに振り分けないように負荷分散装置１が振り分け比率を設定することにより実行される。「次回更新対象サーバ」は、更新対象サーバの次に更新される予定のサーバである。すなわち、更新対象サーバの更新の後に閉塞されるべきサーバである。

更新サーバ決定部９１は、これらの更新対象サーバと、次回更新対象サーバとを、更新管理テーブル４１の処理量を示すデータを基に決定して、更新管理テーブル４１に記録する。例えば、更新サーバ決定部９１は、「未更新」であって、かつ、コネクション数が最も少ないサーバを更新対象サーバに決定することができる。そして、更新サーバ決定部９１は、この更新対象サーバ以外の「未更新」のサーバの中で、コネクション数が最も少ないサーバを次回更新対象サーバと決定することができる。すなわち、更新サーバ決定部９１は、現在の処理量が最も少ないために、新規処理要求を受け付けなければ最も早く閉塞すると予想されるサーバを更新対象サーバに決定することができる。

また、更新サーバ決定部９１は、更新終了検知部８３から、更新対象サーバの更新が終了した旨の通知を受けると、通知に基づいて更新管理テーブル４１を更新する。この場合、更新が終了した更新対象サーバの更新状態を「更新済み」に、さらに、次回更新対象サーバの更新状態を「更新対象サーバ」に更新する。

分散比率設定部９２は、更新管理テーブル４１を参照して、各サーバの振り分け比率を計算し、負荷分散部１３へ指示する。分散比率設定部９２は、更新対象サーバと、次回更新対象サーバの振り分け比率を０にして、その分を、他のサーバの振り分け比率へ上乗せする。具体例として、分散比率設定部９２は、更新対象サーバと次回更新対象サーバの２台分の振り分け率を、その他のサーバで均等に割り振ってもよい。すなわち、上記２台分の振り分け率をその他のサーバの台数で割った量が、その他のサーバ各々の元の振り分け比率に加算される。ただし、更新対象サーバ以外のサーバが全て更新済みである場合には、更新対象サーバ１台分の振り分け率を、その他のサーバで均等に割り振る。

また、分散比率設定部９２は、更新管理テーブル４１に記録されている各サーバのＣＰＵ負荷を参照して、ＣＰＵ負荷が閾値に達したサーバは振り分け対象から除外することができる。この場合、振り分け対象から除外されたサーバのＣＰＵ負荷が、前記閾値を下回ると、再び振り分け対象にされる。なお、上記閾値は、例えば、保守者により記録部１１に予め記録された値が用いられる。また、分散比率設定部９２は、ＣＰＵ負荷の他のサーバの負荷または性能を示す値を用いて、各サーバを振り分け対象から除外するか否かを判断してもよい。

＜負荷分散装置１の動作例＞
図３および図４は、第１の実施形態における負荷分散装置１の動作例を示すシーケンス図である。図３に示す処理は、図４に示す処理に続いている。図３および図４に示す処理は、保守者が、サーバ４ａ〜４ｅのセキュリティパッチを更新する際に、保守者端末２を介して負荷分散装置１に更新要求（保守開始要求）を送信した後の処理である。

図３において、要求受付部８１が、保守者端末２から更新要求を受け付けると（Ｏｐ１）、更新要求を、保守制御部９に通知する。更新要求には、保守対象サーバはサーバ４ａ〜４ｅであることを示すデータが含まれる。保守制御部９は、保守対象サーバであるサーバ４ａ〜４ｅに関するデータを記録する更新管理テーブル４１を記録部１１に生成する（Ｏｐ２）。
このとき、保守制御部９は、監視データテーブル４２からサーバ４ａ〜４ｅ各々のトラフィック情報および負荷情報を取得し、更新管理テーブル４１に記録する。本動作例では、一例として、コネクション数およびＣＰＵ負荷が、監視データテーブル４２から取得され、更新管理テーブル４１に記録される。

なお、監視部１４は、定期的に、サーバ４ａ〜４ｅおよび負荷分散部１３を監視して、負荷情報およびトラフィック情報を取得し、監視データテーブル４２を更新する（Ｏｐ３）。保守制御部９は、更新管理テーブル４１を生成した後は、監視データテーブル４２を定期的に参照し、監視データテーブル４２の更新に合わせて、更新管理テーブル４１の情報を更新する（Ｏｐ４）。これにより、刻々と移り変わるサーバ４ａ〜４ｅ各々の負荷およびトラフィックが、更新管理テーブル４１に、常に反映されることになる。

更新管理テーブル４１が生成されると、更新サーバ決定部９１は、更新管理テーブル４１を参照し、更新対象サーバおよび次回更新対象サーバを決定する（Ｏｐ５）。例えば、更新サーバ決定部９１は、ユーザ端末とのコネクション数が最も少ないサーバ（上記表２に示す例では、サーバ４ｂ）を更新対象サーバとして選択する。これにより、最も短時間で閉塞状態となると予想されるサーバが、更新対象サーバに選択される。更新サーバ決定部９１は、更新管理テーブル４１における更新対象サーバ（サーバ４ｂ）のレコードの更新状態を、「更新対象」に変更する。

また、Ｏｐ５において、更新サーバ決定部９１は、更新対象サーバ以外の「未更新」のサーバのコネクション数を比較し、最もコネクション数の少ないサーバ（表２に示す例では、サーバ４ｅ）を次回更新対象サーバとして決定する。更新管理テーブル４１のサーバ４ｅの更新状態は、「次回更新対象」に変更される。

更新サーバ決定部９１は、更新管理テーブル４１を更新すると、分散比率設定部９２に対して、振り分け比率の設定を指示する（Ｏｐ６）。分散比率設定部９２は、更新管理テーブル４１を参照し、各サーバの更新状態と振り分け比率を基に、新たな振り分け比率を計算する（Ｏｐ７）。例えば、分散比率設定部９２は、更新対象サーバ（サーバ４ｂ）および次回更新対象サーバ（サーバ４ｅ）の振り分け比率の合計（５％＋１０％＝１５％）を、他のサーバ４ａ、４ｃ、４ｄの３台で割った値（５％）を、サーバ４ａ、４ｃ、４ｄの振り分け比率にそれぞれ加算する。その結果、サーバ４ａ、４ｃ、４ｄの振り分け比率はそれぞれ３５％、２０％、４５％になる。また、次回更新対象サーバ及び更新対象サーバとして決定されたサーバ４ｂ及びサーバ４ｅには、端末からの新たな要求を振り分けないなように、サーバ４ｂ及びサーバ４ｅの振り分け比率は０％となる。

なお、Ｏｐ７における分散比率設定部９２の処理の具体例を、本実施形態の記載の最後にフローチャートを用いて説明する。

分散比率設定部９２は、Ｏｐ７で計算した振り分け比率で、新規の処理要求をサーバ４ａ〜４ｅに振り分けるように負荷分散部１３に指示する（Ｏｐ８）。具体的には、分散比率設定部９２は、Ｏｐ７で計算した振り分け比率を負荷分散部１３に通知する。負荷分散部１３は各サーバの振り分け比率を、通知に従って変更する。これにより、受信部１２が受信した、新たなコネクションを確立するためのフレームは、負荷分散部１３によって、更新対象サーバ（サーバ４ｂ）および次回更新サーバ（サーバ４ｅ）以外のサーバ（サーバ４ａ、４ｄまたは４ｄ）に転送されるようになる（Ｏｐ９）。すなわち、更新対象サーバおよび次回更新対象サーバが予閉塞される。

例えば、負荷分散部１３は、は、サーバ４ｂまたはサーバ４ｂとのセッションを接続中のユーザ端末からのアクセスは、継続してサーバ４ｂとサーバ４ｂへ転送する。しかし、新規セッションの接続要求はサーバ４ｂおよびサーバ４ｂ以外のサーバに転送する。

Ｏｐ８の処理以降は、サーバ４ｂおよびサーバ４ｅのコネクション数は、減少する一方で増えることはない。サーバ４ｂおよびサーバ４ｅのコネクション数はやがて０になる。通常、更新対象サーバであるサーバ４ｂのコネクション数の方が先に０になる。すなわち、サーバ４ｂは閉塞する。これで、サーバ４ｂの更新作業が可能になり、更新準備完了したことになる。サーバ４ｂの更新準備完了時の更新管理テーブル４１のデータ内容の例を下記表３に示す。

保守制御部９は、更新対象サーバ（サーバ４ｂ）にアクセス中のユーザ数（コネクション数）を、更新管理テーブル４１を定期的に参照するにより監視する。これにより、保守制御部９は、閉塞状態となり保守作業が開始可能になるのを待つ。なお、コネクション数、ＣＰＵ負荷、といったリアルタイムに変わる情報は保守制御部９が監視データテーブル４２から読み出し更新管理テーブル４１を更新することができる。

保守制御部９は更新対象サーバ（サーバ４ｂ）のコネクション数が０になったら更新準備が完了したことを通知部８２へ通知する（Ｏｐ１１）。通知部８２は、サーバ４ｂが更新可能であることを保守者端末２へ通知する（Ｏｐ１２）。例えば、サーバ４ｂが更新可能である旨のメッセージを含む電子メールが保守者端末２へ送信される。

これにより、保守者は、サーバ４ｂが更新可能な状態になったことを知ることができる。そして、保守者は、保守者端末２を用いて、更新対象サーバ（サーバ４ｂ）のセキュリティパッチの更新を実行する（Ｏｐ１３）。

以降の処理は、図４に示す。保守者端末２において、サーバ４ｂの更新処理が終了すると、保守者は、保守者端末２を介して、サーバ４ｂのセキュリティパッチの更新が終了したことを示すメールを負荷分散装置１へ送信する（Ｏｐ１４）。更新終了検知部８３は、このメールを受信すると、サーバ４ｂの更新が終了したことを、保守制御部９へ通知する。保守制御部９は、この通知を受けると、更新サーバ決定部９１に、更新が終了した旨を通知し、更新対象サーバおよび次回更新対象サーバを決定し直すように指示する（Ｏｐ１５）。

この指示を受けた更新サーバ決定部９１は、新たな更新対象サーバと次回更新対象サーバとを決定する（Ｏｐ５）。このとき、更新サーバ決定部９１は、更新が終了した更新対象サーバ（サーバ４ｂ）の更新状態を「更新済み」として、新たな更新対象サーバおよび次回更新対象サーバを決定する。この決定処理は、図３のＯｐ５の場合と同様であってもよい。

例えば、更新サーバ決定部９１は、「更新済み」でないサーバ（サーバ４ａ、４ｃ〜４ｅ）のうち、コネクション数が最も少ないサーバを更新対象サーバとする。ここでは、次回更新サーバであるサーバ４ｅが、新規処理要求の振り分け対象になっていないためにコネクション数が減少しているので、更新対象サーバに選択されるとする。さらに更新サーバ決定部９１は、更新対象サーバ以外の更新済みでないサーバ４ａ、４ｃおよび４ｄのうち、コネクション数が最も少ないサーバ（一例としてサーバ４ｃ）を新たな次回更新対象サーバとする。したがって、更新管理テーブル４１においては、サーバ４ｂの更新状態が「更新済み」、サーバ４ｅの更新状態が「更新対象」、サーバ４ｃの更新状態が「次回更新対象」に変更される。

なお、更新サーバ決定部９１は、新たな更新対象サーバを決定する際、次回更新対象サーバを自動的に新たな更新対象サーバとしてもよい。また、更新サーバ決定部の処理の具体例については、後述する。

以降、図３のＯｐ６〜Ｏｐ１２と同様の処理が繰り返される。すなわち、更新サーバ決定部９１によって新たに決定された更新対象サーバ（サーバ４ｅ）および次回更新対象サーバ（サーバ４ｃ）への新規処理要求の振り分け比率が０％になるように、分散比率設定部９２が振り分け比率を更新する。これにより、サーバ４ｅおよびサーバ４ｃが予閉塞される。なお、サーバ４ｅは、前回のＯｐ６で振り分け比率０％に設定され、すでに予閉塞されている。そのため、サーバ４ｅは、前回の予閉塞から時間経過とともにコネクション数が減っているはずであり、その分閉塞までにかかる時間も短くなっている。このようにして、次回更新対象サーバが更新対象サーバとなった後の、予閉塞から閉塞までにかかる時間が短縮されることになる。

下記表４は、サーバ４ｅが更新対象サーバとなり、閉塞した時点の更新管理テーブル４１のデータ内容の例を示す表である。

上記表１に示す状態では、サーバ４ｅの更新準備完了しており、保守者によるサーバ４ｅの更新作業が可能になる。

上記のＯｐ５〜Ｏｐ１５の処理が、保守対象サーバ（サーバ４ａ〜４ｅ）全てが更新済みとなるまで、繰り返される。これにより、保守者はサーバ４ａ〜４ｅ全てに対してセキュリティパッチの更新を行うことができる。

以下、表５〜表７に、上記動作例の続きにおいて、サーバ４ｃの更新準備が完了した時点、その後のサーバ４ａの更新準備が完了した時点、さらにその後のサーバ４ｄの更新準備が完了した時点の更新管理テーブル４１のデータ内容例をそれぞれ示す。

上記表７に示す状態で、更新対象のサーバ４ｄの更新が終了すると、サーバ４ａ〜４ｅすべて更新済みとなる。このような場合、例えば、上記Ｏｐ５における更新サーバ決定部９１の処理では、更新対象サーバの条件に合うと判断されるサーバが検出されない。その場合、更新サーバ決定部９１は、更新作業が完了したと判断し、更新完了通知を、要求受付部８１を介して保守者端末２へ送信することができる。これにより、上記Ｏｐ５〜Ｏｐ１５の処理の繰り返しを終了することができる。

図５（ａ）は、上記動作例において、表２〜表７に示したサーバ４ａ〜４ｅ各々のコネクション数の遷移を表すグラフである。図５（ａ）に示すグラフは、縦軸にコネクション数をとり、表２〜表７各々におけるサーバ４ａ〜４ｅのコネクション数をプロットしたグラフである。図５（ａ）において、ひし形、正方形、三角形、×、＊のプロットは、それぞれ、サーバ４ａ、４ｂ、４ｃ、４ｄ、４ｅを示す。図５（ａ）に示すコネクション数の遷移では、各サーバ４ａ〜４ｅが閉塞する前の段階で、コネクション数が減少している傾向が見られる。

図５（ｂ）は、比較形態として、上記表２に示す状態から、コネクション数に関わりなく、サーバ４ａ、４ｂ、４ｃ、４ｄ、４eの順に予閉塞させた場合のコネクション数の遷移を示すグラフである。図５（ａ）と比べると閉塞の前段階からコネクション数が図５（ａ）の場合に比べて多い傾向にある。閉塞の前段階でのコネクション数が多ければ、サーバの閉塞にかかる時間が長くなることになる。コネクション数と閉塞にかかる時間とは比例する傾向があるからである。したがって、図５（ａ）に示すグラフから、上記の図３、４に示した動作例のようにサーバ４ａ〜４ｅの更新順を制御することによって、更新にかかる時間が短縮でき、効率よい更新作業が可能になることがわかる。

図６は、図５（ａ）に示す各サーバの閉塞の前段階のコネクション数の棒グラフと、図５（ｂ）に示す各サーバの閉塞の前段階のコネクション数の棒グラフとを、各サーバの閉塞段階ごとに並べて示したグラフである。全ての段階において、図５（ａ）の実施形態の場合のコネクション数の方が、図５（ｂ）の比較形態の場合のコネクション数より少なくなっている。このことから、実施形態の方が、比較形態よりも閉塞にかかる時間が短くなっていると言える。

以上のように、本実施形態によれば、負荷分散装置１を用いた負荷分散構成におけるサーバ４ａ〜４ｅの更新において、負荷分散装置１が、サーバ更新の順序や、更新中の振り分け条件の変更を適切に行うことによって、サーバ更新にかかる時間を短縮することができる。そのため、サーバ４ａ〜４ｅが提供しているサービスの品質をできるだけ低下させずにサーバ更新を行うことができるようになる。これにより、サーバ更新に伴う利用者への影響を小さくすることができる。

また、サーバ更新の順序の制御や、更新中の振り分け条件の変更の検討や設定などの、保守者の作業負荷を軽減することができるようになる。さらに、保守者に対してサーバ更新開始タイミングの通知がなされるので、保守者がサーバ更新の開始タイミングを見張っておかねばならないという不便さから解放される。

＜更新サーバ決定部９１の動作例＞
図７は、更新サーバ決定部９１の動作例を示すフローチャートである。図７に示す例は、図３のＯｐ５における更新サーバ決定部９１の処理の例である。まず、更新サーバ決定部９１は、更新終了検知部８３から、更新対象サーバの更新終了通知（図４のＯｐ１５）を受けたか否かを判断する（Ｏｐ５１）。

更新終了通知を受けている場合（Ｏｐ５１でＹＥＳ）は、更新サーバ決定部９１は、更新管理テーブル４１における、更新終了した更新対象サーバのレコードの更新状態を「更新対象」から「更新済み」に変更する（Ｏｐ５２）。

そして、更新サーバ決定部９１は、更新状態が「更新済み」でないサーバのうち、コネクション数が最小のサーバを、更新対象テーブル４１から抽出する（Ｏｐ５３）。Ｏｐ５３でそのようなサーバが抽出されると（Ｏｐ５４でＹＥＳ）、更新サーバ決定部９１は、抽出されたサーバのレコードの更新状態を「更新対象」に変更する（Ｏｐ５５）。

さらに、更新サーバ決定部９１は、更新状態が「更新済み」でなく、かつ「更新対象」でもないサーバのうち、コネクション数が最小のサーバを更新管理テーブルから抽出する（Ｏｐ５６）。Ｏｐ５６でそのようなサーバが抽出された場合（Ｏｐ５７でＹＥＳ）、更新サーバ決定部９１は、抽出されたサーバのレコードの更新状態を「次回更新対象」に変更する（Ｏｐ５８）。

以上の処理により、更新対象サーバおよび次回更新対象が決定し、更新管理テーブルに記録される。なお、更新対象サーバの条件に適合するサーバが抽出されない場合（Ｏｐ５４でＮＯ）、または次回更新対象サーバの条件に適合するサーバが抽出されない場合（Ｏｐ５７でＮＯ）、更新サーバ決定部９１はＯｐ５の処理を終了する。更新対象サーバが決定されずにＯｐ５の処理が終了された場合、更新サーバ決定部９１は、更新すべきサーバは存在しないことを示す更新完了通知を、通知部８２を介して保守者端末２へ送信することができる。

＜分散比率設定部９２の動作例＞
図８は、図３のＯｐ７における分散比率設定部９２の動作例を示すフローチャートである。図８に示す例では、分散比率設定部９２は、更新管理テーブル４１に記録されているｉ番目のレコードが示すサーバ情報を取得する（Ｏｐ７１）。なお、ｉは変数であり、ｉ＝１で初期化される。

ｉ番目のレコードのＣＰＵ負荷が、閾値を越えている場合（Ｏｐ７２でＹｅｓ）、更新状態が「更新対象」の場合（Ｏｐ７３でＹｅｓ）、もしくは、更新対象が「次回更新対象」の場合（Ｏｐ７４でＹｅｓ）は、分散比率設定部９２は、Ｏｐ７５の処理を実行する。

Ｏｐ７５において、分散比率設定部９２は、そのレコードを振り分け比率を分配用振り分け比率を示す値Ｂに加算する。分配振り分け比率を示す値ＢはＢ＝０で初期化されている。さらに、分散比率設定部９２は、分配サーバ台数を示す値ｓに「１」を加算する。分配サーバ台数を示す値ｓもｓ＝０で初期化されている。

さらに、分散比率設定部９２は、更新管理テーブル４１におけるそのレコードの振り分け比率を「０％」に変更する（Ｏｐ７６）。

上記のＯｐ７１〜Ｏｐ７６の処理は、更新管理テーブル４１の全てのレコードについて（Ｏｐ７７でＹｅｓと判断されるまで）繰り返される。分散比率設定部９２は、Ｏｐ７７でＹｅｓと判断すると、更新管理テーブル４１に記録された保守対象サーバの台数（総サーバ台数Ａ）から分配サーバ台数ｓを減算した台数（Ａ−ｓ）を求める。そして、分散比率設定部９２は、分配用振り分け比率Ｂを求めた台数（Ａ−ｓ）で割った値（Ｂ／（Ａ−ｓ））を計算する（Ｏｐ７８）。

分散比率設定部９２は、Ｏｐ７８で計算した値（Ｂ／（Ａ−ｓ））を、上記Ｏｐ７２、Ｏｐ７３およびＯｐ７４の全てでＮｏと判断されたレコードの振り分け比率に加算する（Ｏｐ７９）。これにより、更新対象サーバ、次回更新対象サーバおよびＣＰＵ負荷が閾値を越えるサーバが、ユーザ端末５ａ〜５ｃからの処理要求の振り分け対象から除外され、他のサーバへ振り分けられるような振り分け比率が設定される。

（第２の実施形態）
図９は、第２の実施形態の負荷分散装置を含むネットワーク全体の構成を示す図である。本実施形態では、負荷分散装置１ａは、自動更新サーバ３からアクセス可能になっている。また、ネットワーク６には、更新情報提供サーバ７が接続されている。前記第１の実施形態では、保守者が保守者端末２を介してサーバ４ａ〜４ｅの更新作業を行う形態であった。これに対して、本実施形態では、保守者が更新開始指示を負荷分散装置１ａに送信することにより、負荷分散装置１ａが自動更新サーバ３と連携して、サーバ４ａ〜４ｅに対して自動的に更新を行う。すなわち、負荷分散装置１ａは、自動更新サーバ３との連携機能を有している。

更新情報提供サーバ７は、例えば、サーバ４ａ〜４ｅのソフトウエアを提供するベンダによってネットワーク上に設置されるサーバである。サーバ４ａ〜４ｅのソフトウエアを更新するためのデータ（更新情報）を、自動更新サーバ３がネットワーク６を介して取得可能な状態で提供する。例えば、更新情報の例として、セキュリティパッチの更新プログラム等が挙げられる。なお、図９では、更新情報提供サーバ７が１台だけの場合がかかれているが、例えば、複数のベンダごとの更新情報提供サーバ７がネットワーク６に接続されうる。

自動更新サーバ３は、ネットワーク６を介して更新情報提供サーバ７から、サーバ４ａ〜４ｅの更新情報を取得し、更新情報を使ってサーバ４ａ〜４ｅのソフトウエアを自動更新する。また、自動更新サーバ３は、負荷分散装置１ａから、更新可能なサーバと更新可能タイミングとを示す情報を受信し、この情報に基づいて、自動更新を行う。

自動更新サーバ３は、例えば、自動更新機能を有するアプライアンスサーバにより構成することができる。アプライアンスサーバとは、特定の用途向けに設計・開発されるサーバのことである。アプライアンスサーバは、必要な機能を備えた機器だけを選択できるため、汎用サーバに比べて、導入コストを抑えることができる。自動更新機能を有するアプライアンスサーバは、保守の必要性のある複数のサーバ４ａ〜４ｅに対して、セキュリティパッチ、アプリケーション、ファームやカーネルといったセキュリティホールの発覚や不具合発生により更新され配布されるパッチ類の公開を提供側ベンダと連携して自動的に検出する。そして、このアプライアンスサーバは、管理しているサーバ４ａ〜４ｅに対して自動的に更新作業を行うことができる。これにより、Ｗｅｂ、ＦＴＰ、Ｔｅｌｎｅｔを用いて、ユーザ端末５ａ〜５ｃにサービスを提供するサーバ４ａ〜４ｅのソフトウエアを常に最新のセキュリティパッチを適用した状態を保つことができる。

図１０は、負荷分散装置１ａの構成を示す機能ブロック図である。図１０において、図１と同じ機能ブロックには同じ符号を付す。図１０に示す負荷分散装置１ａの通信部８ａは、保守者端末２に加えて、自動更新サーバ３とも通信する機能を有する。

例えば、要求受付部８１ａは、保守者端末２から、自動更新サーバ３によるサーバ４ａ〜４ｅの自動更新の開始を指示する自動更新開始要求を受け付けると、自動更新サーバ３に対して、自動更新機能停止指示を送信し、負荷分散装置１ａから通知する更新タイミングに従ってサーバ４ａ〜４ｅを更新するように指示することができる。

通知部８２ａは、更新対象サーバが閉塞し、更新準備が完了すると、その更新対象サーバが更新可能なことを自動更新サーバ３へ通知する。これにより、更新可能なサーバおよび更新タイミングが自動更新サーバ３へ通知される。更新終了検知部８３ａは、自動更新サーバ３から、更新対象サーバの更新が終了した旨の通知を受け付ける。

自動更新サーバ３は、通信部３１、更新情報監視部３２および自動更新部３３を備える。通信部３１は、負荷分散装置１ａとの通信する機能を有する。通信部３１は、例えば、負荷分散装置１ａから、更新可能なサーバおよび更新可能なタイミングの通知を受け、通知に基づいて自動更新部３３のサーバ４ａ〜４ｅに対する更新のタイミングを制御する。

更新情報監視部３２は、ネットワーク６を定期的に監視することによって，更新情報提供サーバ７によって公開される、サーバ４ａ〜４ｅの更新情報を検出する。更新情報監視部３２は、検出した更新情報を更新情報提供サーバ７から取得し、自動更新部３３へ渡す。自動更新部３３は、渡された更新情報を用いて、サーバ４ａ〜４ｅを更新する。その際、自動更新部３３は、通信部３１からの通知に従ったタイミングで、サーバ４ａ〜４ｅを更新する。これにより、自動更新部３３のサーバ４ａ〜４ｅに対する更新のタイミングは、負荷分散装置１ａによって制御される。

また、自動更新部３３の更新タイミングは、保守者が、保守者端末２を介して制御することも可能である。例えば、保守者は、自動更新部３３の更新を、更新情報が検出されたときに随時行うのか、負荷分散装置１ａからの通知に従って行うのかを指示する信号を、保守者端末２から負荷分散装置１ａまたは自動更新サーバ３に送信することができる。

＜動作例＞
図１１は、負荷分散装置１ａおよび自動更新サーバ３の動作例を示すシーケンス図である。図１１に示すように、要求受付部８１ａは、保守者端末２から保守開始要求を受信する（Ｏｐ２１）。要求受付部８１ａは、保守開始要求を受け付けると、保守制御部９がテーブルを作成する（Ｏｐ２）。Ｏｐ２は、図３に示したＯｐ２と同様である。

さらに、要求受付部８１ａは、自動更新機能停止要求を自動更新サーバ３へ送信する（Ｏｐ２２）。自動更新サーバ３では、通信部３１がこれを受信し、自動更新部３３が、自動更新機能を停止する（Ｏｐ２３）。

その後、図３のＯｐ３〜Ｏｐ１１と同様に、更新サーバ決定部９１および分散比率決定部９２によって処理が実行される。更新対象サーバのコネクション数が０になる（閉塞する）と、更新対象サーバの更新準備完了が通知部８２ａから、自動更新サーバ３へ通知される（Ｏｐ１２−１）。

通知を受けた自動更新サーバ３は、更新対象サーバに対する更新処理を実行する（Ｏｐ１３−１）。例えば、更新情報監視部３２は、セキュリティパッチ提供ベンダの更新情報提供サーバ７からのセキュリティパッチのパッチファイルのダウンロードを要求する。パッチファイルをダウンロードした更新情報監視部３２は、自動更新部３３に更新要求を行う。自動更新部３３は更新対象サーバに対してセキュリティパッチの更新を開始し、必要に応じて更新対象サーバを再起動する。

更新作業を完了した自動更新部３３は、更新が完了したことを通信部３１経由で負荷分散装置１ａの更新終了検知部８３ａに通知する（Ｏｐ１４−１）。Ｏｐ１５以降は、図３の場合と同様にＯｐ５〜Ｏｐ１１、Ｏｐ１２−１、Ｏｐ１３−１、Ｏｐ１４−１の処理が、サーバ４ａ〜４ｂ各々について繰り返される。

上記の動作により、セキュリティパッチの更新を行いたい保守者は、負荷分散装置１ａにより保守作業に要する時間の少ない更新対象サーバからサーバ更新作業を自動更新サーバ３に実行させることができる。そのため、効率よく、サーバ４ａ〜４ｅの更新を自動的に行うことが可能となる。

図１２は、負荷分散装置１ａおよび自動更新サーバ３の他の動作例を示すシーケンス図である。図１２に示す例は、要求受付部８１ａは、保守者端末２から自動保守開始要求を受信する（Ｏｐ２１−１）。この場合、要求受付部８１ａは、自動更新サーバ３に対して、自動保守を指示する（Ｏｐ２２−１）。

自動更新サーバ３は、自動更新機能停止する（Ｏｐ２３）。また、更新情報監視部３２は、セキュリティパッチの監視を開始する（Ｏｐ２４）。更新情報監視部３２は、セキュリティパッチ更新検出機能により、新しいセキュリティパッチが提供ベンダから提供されたことを検出する（Ｏｐ２５）。新しいセキュリティパッチの提供を検出した更新情報監視部３２は新規キュリティパッチの更新要求を通信部３１経由で負荷分散装置１ａの要求受付部８１ａに送信する（Ｏｐ２６）。以降は、図１１と同様にＯｐ３〜Ｏｐ１５の処理が各サーバ４ａ〜４ｅについて繰り返される。

上記の動作により、セキュリティパッチの更新を行いたい保守者は、負荷分散装置１ａに自動保守開始要求を送信するだけで、サーバ４ａ〜４ｅのセキュリティ更新を効率よく、自動的に行うことが可能となり、常に最新のセキュリティパッチが適応された状態を維持することが可能となる。

第１の実施形態の負荷分散装置を含むネットワーク全体の構成を示す図 負荷分散装置１の構成を示す機能ブロック図 第１の実施形態における負荷分散装置１の動作例を示すシーケンス図 第１の実施形態における負荷分散装置１の動作例を示すシーケンス図 （ａ）は、上記動作例におけるサーバ４ａ〜４ｅ各々のコネクション数の遷移を表すグラフである。（ｂ）は、比較形態におけるコネクション数の遷移を示すグラフである。 図５（ａ）に示す各サーバの閉塞の前段階のコネクション数の棒グラフと、図５（ｂ）に示す各サーバの閉塞の前段階のコネクション数の棒グラフとを、各サーバの閉塞段階ごとに並べて示したグラフ 更新サーバ決定部９１の動作例を示すフローチャート 分散比率設定部９２の動作例を示すフローチャート 第２の実施形態の負荷分散装置を含むネットワーク全体の構成を示す図 第２の実施形態の負荷分散装置の構成を示す機能ブロック図 負荷分散装置および自動更新サーバの動作例を示すシーケンス図 負荷分散装置１ａおよび自動更新サーバ３の他の動作例を示すシーケンス図

符号の説明

１、１ａ 負荷分散装置
２ 保守者端末
３ 自動更新サーバ
４ａ-４ｅ サーバ
５ａ-５ｄ 端末
６ ネットワーク
７ 更新情報提供サーバ
８、８ａ 通信部
９ 保守制御部
１１ 記録部
１２ 受信部
１３ 負荷分散部
１４ 監視部
３１ 通信部
３２ 更新情報監視部
３３ 自動更新部
８１、８１ａ 要求受付部
８２、８２ａ 通知部
８３、８３ａ 更新終了検知部
９１ 更新サーバ決定部
９２ 分散比率設定部

Claims (7)

1. 端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送する負荷分散装置であって、
   前記複数のサーバ各々と端末との通信データまたは前記複数のサーバ各々の稼動状態を監視することにより、各サーバが端末からの処理要求を受けて実行している処理の量を示すデータを記録部に格納する監視部と、
   保守者端末または自動更新サーバから、前記複数のサーバの更新準備の要求を受信する要求受付部と、
   前記複数のサーバのうち、未更新のサーバであって、かつ、前記記録部のデータが示す当該サーバの処理の量が最も少ないサーバを更新対象サーバとし、前記更新対象サーバ以外の未更新のサーバであって、かつ、当該サーバの処理の量が最も少ないサーバを次回更新対象サーバとする、更新サーバ決定部と、
   前記更新対象サーバ及び次回更新対象サーバとして決定されたサーバに対しては、端末からの新規処理要求の割り当てを行わず、他のサーバへ端末からの新規処理要求を割り当てるように、前記複数のサーバ各々に対する新規処理要求の分散比率を設定し前記記録部へ記録する、分散比率設定部と、
   前記分散比率に基づいて、端末からの新規処理要求を前記複数のサーバのうち少なくとも１つに割り当てて転送する負荷分散部と、
   前記記録部のデータが示す前記更新対象サーバの処理の量を監視し、前記更新対象サーバが更新可能な状態になったと判断すると、前記保守者端末または自動更新サーバに対して、前記更新対象サーバが更新可能である旨を通知する通知部と、
   前記保守者端末または自動更新サーバから、前記更新対象サーバの更新が終了した旨の通知を受け付ける更新終了検知部とを備え、
   前記更新終了検知部が、前記更新対象サーバの更新が終了した旨の通知を受けた場合、前記更新サーバ決定部は、更新が終了した前記更新対象サーバを、更新済みとして、新たな更新対象サーバおよび次回更新対象サーバを決定し、前記分散比率設定部に、分散比率の設定を指示する、負荷分散装置。
2. 前記監視部は、前記複数のサーバ各々の負荷を示すデータも前記記録部に記録し、
   前記分散比率設定部は、前記記録部に記録された複数のサーバ各々の負荷に基づいて、前記更新対象サーバおよび前記次回更新対象サーバ以外の分散比率を計算する、請求項１に記載の負荷分散装置。
3. 前記要求受付部は、ネットワークを介して、前記複数のサーバの更新情報を検出した自動更新サーバから、前記更新情報に係る更新要求を受け付ける、請求項１または２に記載の負荷分散装置。
4. 端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送する負荷分散装置と、前記複数のサーバを自動更新する自動更新サーバとを含む負荷分散システムであって、
   前記自動更新サーバは、
   ネットワークを介して、前記複数のサーバの更新情報を検出する更新情報監視部と、
   前記更新情報を検出された場合に、前記負荷分散装置に対して、前記複数のサーバの更新要求を送信する通信部と、
   前記更新情報に基づいて前記複数のサーバを自動更新する自動更新部とを備え、
   前記負荷分散装置は、
   前記複数のサーバ各々と端末との通信データまたは前記複数のサーバ各々の稼動状態を監視することにより、各サーバが端末からの処理要求を受けて実行している処理の量を示すデータを記録部に格納する監視部と、
   自動更新サーバから、前記複数のサーバの更新準備の要求を受信する要求受付部と、
   前記複数のサーバのうち、未更新のサーバであって、かつ、前記記録部のデータが示す当該サーバの処理の量が最も少ないサーバを更新対象サーバとし、前記更新対象サーバ以外の未更新のサーバであって、かつ、当該サーバの処理の量が最も少ないサーバを次回更新対象サーバとする、更新サーバ決定部と、
   前記更新対象サーバ及び次回更新対象サーバとして決定されたサーバに対しては、端末からの新規処理要求の割り当てを行わず、他のサーバへ端末からの新規処理要求を割り当てるように、前記複数のサーバ各々に対する新規処理要求の分散比率を設定し前記記録部へ記録する、分散比率設定部と、
   前記分散比率に基づいて、端末からの新規処理要求を前記複数のサーバのうち少なくとも１つに割り当てて転送する負荷分散部と、
   前記記録部のデータが示す前記更新対象サーバの前記処理の量を監視し、前記更新対象サーバが更新可能な状態になったと判断すると、前記自動更新サーバに対して、前記更新対象サーバが更新可能である旨を通知する通知部と、
   前記自動更新サーバから、前記更新対象サーバの更新が終了した旨の通知を受け付ける更新終了検知部とを備え、
   前記更新終了検知部が、前記更新対象サーバの更新が終了した旨の通知を受けた場合、前記更新サーバ決定部は、更新が終了した前記更新対象サーバを、更新済みとして、新たな更新対象サーバおよび次回更新対象サーバを決定し、前記分散比率設定部に、分散比率の設定を指示する、負荷分散システム。
5. 端末から処理要求を受信し、複数のサーバのうち少なくとも１つへ割り当てて転送する処理をコンピュータに実行させる負荷分散プログラムであって、
   前記複数のサーバ各々と端末との通信データまたは前記複数のサーバ各々の稼動状態を監視することにより、各サーバが端末からの処理要求を受けて実行している処理の量を示すデータを前記コンピュータがアクセス可能な記録部に格納する監視処理と、
   保守者端末または自動更新サーバから、前記複数のサーバの更新準備の要求を受信する要求受付処理と、
   前記複数のサーバのうち、未更新のサーバであって、かつ、前記記録部のデータが示す当該サーバの処理の量が最も少ないサーバを更新対象サーバとし、前記更新対象サーバ以外の未更新のサーバであって、かつ、当該サーバの処理の量が最も少ないサーバを次回更新対象サーバとする、更新サーバ決定処理と、
   前記更新対象サーバ及び次回更新対象サーバとして決定されたサーバに対しては、端末からの新規処理要求の割り当てを行わず、他のサーバへ端末からの新規処理要求を割り当てるように、前記複数のサーバ各々に対する新規処理要求の分散比率を設定し前記記録部へ記録する分散比率設定処理と、
   前記分散比率に基づいて、端末からの新規処理要求を前記複数のサーバのうち少なくとも１つに割り当てて転送する負荷分散処理と、
   前記記録部のデータが示す前記更新対象サーバの前記処理の量を監視し、前記更新対象サーバが更新可能な状態になったと判断すると、前記保守者端末または自動更新サーバに対して、前記更新対象サーバが更新可能である旨を通知する通知処理と、
   前記保守者端末または自動更新サーバから、前記更新対象サーバの更新が終了した旨の通知を受け付ける更新終了検知処理とをコンピュータに実行させ、
   前記更新終了検知処理において、前記更新対象サーバの更新が終了した旨の通知を受けた場合であってかつ未更新のサーバが存在する場合は、更新が終了した前記更新対象サーバを更新済みとして、前記更新サーバ決定処理、前記分散比率設定処理、前記負荷分散処理、通知処理および前記更新終了検知処理を繰り返しコンピュータに実行させることを特徴する負荷分散プログラム。
6. 前記監視処理では、前記複数のサーバ各々の負荷を示すデータも前記記録部に記録され、
   前記分散比率設定処理では、前記記録部に記録された複数のサーバ各々の負荷に基づいて、前記更新対象サーバおよび前記次回更新対象サーバ以外の分散比率を計算する処理も実行される、請求項５に記載の負荷分散プログラム。
7. 前記要求受付処理は、ネットワークを介して、前記複数のサーバの更新情報を検出した自動更新サーバから、前記更新情報に係る更新要求を受け付ける、請求項５または６に記載の負荷分散プログラム。

Images