JP2006285377A - 故障監視プログラム及び負荷分散装置 - Google Patents

Abstract

【課題】 振り分け先サーバの背後に接続するサーバの故障を監視する。
【解決手段】 定義管理手段１ａは、たとえば、利用者に故障監視に関する定義の設定を促し、得られた設定情報に基づいて故障監視定義情報２ｂを生成する。故障監視定義情報２ｂには、振り分け先サーバごとに、振り分け先サーバに対応する故障監視対象の故障監視サーバ、使用する監視パケットを含む故障監視サーバを正常と判断する判定基準が設定される。故障監視手段１ｂは、故障監視定義情報２ｂに基づき、故障監視サーバに故障監視方法に応じた監視パケットを送信し、応答により故障を判断する。応答パケットが受信されない場合、または受信した応答パケットが判定基準と合わない場合には、この故障監視サーバを故障と判定する。そして、振り分け先サーバに対応する故障監視サーバの故障で、この振り分け先サーバへの振り分け不可と判定する。
【選択図】 図１

Description

本発明は故障監視プログラム及び負荷分散装置に関し、特にクライアントからの要求パケットを複数サーバに振り分けて負荷を分散するため、サーバの故障を監視する処理を行う故障監視プログラム及び負荷分散装置に関する。

従来、多様化、複雑化するネットワークシステムにおいて、サーバのデータ処理能力の確保や、アクセス集中によるレスポンスの低下を防止するため、負荷分散技術が必須となっていた。

図１７は、従来の負荷分散システムの一例を示した構成図である。負荷分散システムでは、ネットワーク９４０を介して接続するクライアント９２１、９２２と、サーバ１（９３１）、サーバ２（９３２）及びサーバ３（９３３）との間に負荷分散装置９１０が配置される。負荷分散装置９１０は、クライアントからの要求を振り分け先であるサーバ１（９３１）、サーバ２（９３２）及びサーバ３（９３３）に振り分ける処理を行う。サーバ１（９３１）及びサーバ２（９３２）は、ＳＳＬ（Secure Socket Layer）処理とＨＴＴＰ（HyperText Transfer Protocol）処理を行うＨＴＴＰＳ（HyperText Transfer Protocol Security）サーバである。また、サーバ３（９３３）のＳＳＬアクセラレータとサーバ４（９３４）のＨＴＴＰサーバとで同様の処理を行う。

振り分け処理を行う負荷分散装置９１０は、サーバ１（９３１）、サーバ２（９３２）及びサーバ３（９３３）の故障監視を行って、故障と判断したサーバにはクライアントからの要求パケットを振り分けないようにしている。故障監視は、負荷分散装置９１０からサーバ１（９３１）、サーバ２（９３２）及びサーバ３（９３３）に対し監視パケットを送信し、その応答の有無で故障しているか否かを判断する。診断は、プロトコルのレイヤに応じて、ｐｉｎｇ監視（ＩＰ層レベルでの診断）、ｓｙｎ監視（ＴＣＰ層レベルでのコネクション接続による診断）、アプリ監視（アプリケーション層レベルでのパケット診断）などが実行される。

また、負荷分散装置とサーバとがルータなどを介して接続し、負荷分散装置とサーバ間のパケット送信経路が複数ある負荷分散システムでは、ルータとの間で正常にパケットを送信できるかを確認するだけでなく、ルータを経由した複数の経路を通ってサーバまで正常に送信できるかどうかを確認し、パケットの送信経路を決定するシステムが提案されている（たとえば、特許文献１参照）。
特開２００２−２７１３７１号公報（段落番号〔００１１〕〜〔００２２〕、図１）

しかし、従来の負荷分散装置における故障監視では、振り分け先のサーバの背後にサーバが存在する場合に、背後にあるサーバの故障監視が難しいという問題点があった。
近年では、サーバに、特定の処理機能を高速化するためのアクセラレータを付加した構成が増えてきている。ＳＳＬ通信を行う場合、図１７に示したように、ＨＴＴＰなどのアプリケーション処理を行うサーバ４（９３４）の前段、すなわち、負荷分散装置９１０とサーバ４（９３４）との間に、ＳＳＬ処理を行うサーバ３（９３３）を配置する構成をとることがある。従って、負荷分散装置９１０側からすると、振り分け先サーバに相当するサーバ３（９３３）の背後に、別のサーバ４（９３４）が存在していることになる。

しかしながら、従来の負荷分散システムにおける故障監視では、故障監視の対象である故障監視対象サーバと振り分け先サーバとは１対１の関係で定義する。この場合、故障監視対象としてサーバ３（９３３）のみが定義され、負荷分散装置９１０はサーバ３（９３３）との間でしか監視パケットのやりとりをしない。このため、背後にあるサーバ４（９３４）の故障監視ができないという問題点がある。

特に、従来の故障監視では、負荷分散装置から送信した監視パケットの応答の有無によってしか、振り分け先サーバの故障を判断していない。たとえば、上記のような構成で振り分け先サーバ３（９３３）は正常であるが背後のサーバ４（９３４）が故障していた場合、アプリケーションレベルで正常な応答を返すことができないはずであるが、監視パケットの応答のみで故障監視を行っているため、振り分け先サーバ３（９３３）から応答が返ってくる間は、振り分け先は正常と判断してしまう。

このように、従来の故障監視では、振り分け先サーバとの間でしか監視パケットとやりとりをしないので、背後のサーバの故障監視ができないという問題点がある。
本発明はこのような点に鑑みてなされたものであり、振り分け先サーバの背後に接続するサーバに対する故障監視処理も行うことが可能な故障監視プログラム及び負荷分散装置を提供することを目的とする。

本発明では上記課題を解決するために、図１に示すような処理をコンピュータに実行させるための故障監視プログラムが提供される。本発明にかかる故障監視プログラムは、負荷分散装置１に適用され、コンピュータに以下の処理を実行させることができる。

負荷分散装置１は、定義管理手段１ａと故障監視手段１ｂを有し、定義管理手段１ａが生成した故障監視定義情報２ｂに基づいて、故障監視手段１ｂがサーバの故障監視を行う。定義管理手段１ａは、クライアントからの要求パケットを振り分ける振り分け先サーバごとに、故障監視対象とする故障監視サーバと、故障監視サーバの診断に用いる監視パケットを含む監視方法と、必要に応じて故障監視サーバを正常と判断する判定基準と、が定義される故障監視定義情報２ｂを生成して管理する。故障監視手段１ｂは、故障監視定義情報２ｂに基づき、定義された監視方法に応じた監視パケットを故障監視サーバに送信し、この故障監視サーバから応答がない、または応答パケットが定義された判定基準と一致しない場合にこの故障監視サーバを故障と判定する。さらに、振り分け先サーバに対応する故障監視サーバが故障の場合には、この振り分け先サーバへの振り分け不可と判定する。

このような負荷分散装置１によれば、定義管理手段１ａによって、故障監視定義情報２ｂが生成される。定義管理手段１ａは、たとえば、利用者に故障監視に関する定義の設定を促し、得られた設定情報に基づいて故障監視定義情報２ｂを生成する。故障監視定義情報２ｂには、振り分け先サーバごとに、振り分け先サーバに対応する故障監視対象の故障監視サーバ、使用する監視パケットを含む監視方法、及び故障監視サーバを正常と判断する判定基準が設定される。なお、正常の判定基準が応答パケットの有無など、自明である場合には判定基準は特に定義される必要はない。故障監視手段１ｂは、故障監視定義情報２ｂに基づき、故障監視サーバに監視パケットを送信し、応答により故障かどうかを判断する。応答パケットが受信されない場合、または受信した応答パケットが判定基準と合わない場合には、この故障監視サーバを故障と判定する。そして、振り分け先サーバに対応する故障監視サーバの故障で、この振り分け先サーバへの振り分け不可と判定する。

また、上記課題を解決するために、クライアントからの要求パケットを複数サーバに振り分けて負荷を分散するとともに、前記サーバの故障を監視する負荷分散装置において、前記クライアントからの要求パケットを振り分ける振り分け先サーバが定義される振り分け定義情報を生成するとともに、前記振り分け先サーバごとに、故障監視対象とする故障監視サーバと、前記故障監視サーバの診断に用いる監視パケットを含む監視方法と、必要に応じて前記故障監視サーバを正常と判断する判定基準と、が定義される故障監視定義情報を生成し、生成した前記振り分け定義情報と前記故障監視定義情報を管理する定義管理手段と、前記故障監視定義情報に基づいて、前記監視方法に応じた監視パケットを前記故障監視サーバに送信し、前記故障監視サーバからの応答なし、または応答パケットが前記判定基準と一致しない場合に前記故障監視サーバを故障と判定し、前記振り分け先サーバに対応する前記故障監視サーバが故障の場合には前記振り分け先サーバへの振り分け不可と判定する故障監視手段と、前記クライアントからの要求パケットを入力すると、前記振り分け定義情報に定義された前記振り分け先サーバのうち、前記故障監視手段によって振り分け可と判断された前記振り分け先サーバに対して適宜前記クライアントからの要求パケットを振り分けるサーバ振り分け手段と、を具備することを特徴とする負荷分散装置、が提供される。

このような負荷分散装置によれば、定義管理手段は、振り分け定義情報及び故障監視定義情報を生成して管理する。振り分け定義情報には、クライアントの要求を振り分ける振り分け先のサーバに関する定義がされる。故障監視定義情報には、振り分け先サーバごとに、故障監視対象の故障監視サーバと、使用する監視パケットを含む監視方法と、必要に応じて故障監視サーバを正常と見なす判定基準と、が定義される。故障監視手段は、故障監視定義情報に基づき、定義された監視方法に応じた監視パケットを故障監視サーバに送信し、その応答がない場合、または応答パケットが判定基準に一致しない場合には、この故障監視サーバを故障とみなす。さらに、故障監視サーバに対応する振り分け先サーバへの振り分け不可と判定する。サーバ振り分け手段は、クライアントからの要求パケットを入力すると、振り分け定義情報に定義された振り分け先サーバに対し、各振り分け先サーバの負荷が分散されるように、クライアントからの要求パケットを振り分けて送信する。このとき、故障監視手段によって振り分け不可と見なされた振り分け先サーバには、振り分けを行わないようにする。

本発明では、監視を行う故障監視サーバ、故障監視方法及び正常と判定する判定基準が定義される故障監視定義情報に基づき、振り分け先サーバの故障監視処理が行われる。このため、負荷分散装置を利用する環境に応じて、利用者が詳細な監視方法を定義することが可能となる。たとえば、負荷分散装置側から見て振り分け先サーバの背後にサーバが存在する場合、背後のサーバを含む振り分け先サーバに接続する複数の故障監視サーバを定義しておけば、振り分け先サーバから先のサーバに対しても故障監視を行うことができる。この結果、背後のサーバの故障監視が可能となり、背後のサーバが故障であっても負荷分散装置で認識されずに振り分け先サーバにクライアントからの要求パケットが振り分けられてしまうケースを防ぐことができる。

以下、本発明の実施の形態を図面を参照して説明する。まず、実施の形態に適用される発明の概念について説明し、その後、実施の形態の具体的な内容を説明する。
図１は、実施の形態に適用される発明の概念図である。

本発明にかかる負荷分散装置１は、定義管理手段１ａ、故障監視手段１ｂ及びサーバ振り分け手段１ｃを具備し、図示しないクライアントからの要求パケットを入力すると、サーバの負荷を分散するように振り分け先サーバに振り分ける。

サーバは、サーバＳ１（３ａ）とサーバＢ１（３ｂ）が１組となって所定の処理機能を実現する。たとえば、サーバＳ１（３ａ）がＳＳＬアクセラレータでサーバＢ１（３ｂ）がＨＴＴＰサーバで構成され、サーバＳ１（３ａ）がＳＳＬ処理を行い、サーバＢ１（３ｂ）がＨＴＴＰアプリケーション処理を実行するというように機能を分担する。従って、クライアントからの要求パケットは、サーバＳ１（３ａ）を経由してサーバＢ１（３ｂ）に送信される。サーバＳ２（３ｃ）とサーバＢ２（３ｄ）の組も同様に動作する。以下の説明では、振り分け先サーバとなるサーバをサーバＳｎ（ｎは任意の数）、その背後に存在するサーバをサーバＢｎと表す。

定義管理手段１ａは、クライアントからの要求パケットを振り分けるサーバを定義する振り分け定義情報２ａと、故障監視対象やその方法などを定義する故障監視定義情報２ｂを生成して管理する。定義は利用者によって行われ、たとえば、利用者に故障監視に関する定義の設定を促す定義情報設定画面などを提示し、画面に従って入力された設定情報に基づいて振り分け定義情報２ａ及び故障監視定義情報２ｂを生成する。なお、定義の設定は、通常、システムの管理者が行う。振り分け定義情報２ａには、クライアントからの所定のサービス要求に対し、この要求をサーバの負荷状態に応じて振り分ける振り分け先サーバが定義される。図の例では、サーバＳ１（３ａ）とサーバＳ２（３ｃ）が振り分け先サーバに定義される。故障監視定義情報２ｂは、振り分け先サーバごとに、故障監視対象の監視サーバ、監視パケット及び故障監視サーバを正常と判断する基準が定義される。なお、応答パケットの有無など、判断基準が自明の場合は、定義されなくてもよい。図の例では、振り分け先サーバＳ１（３ａ）について、故障監視サーバとして、サーバＳ１（３ａ）とサーバＢ１（３ｂ）が定義され、監視方法や正常かどうかの判定基準などが定義される。同様に、振り分け先サーバＳ２（３ｃ）について、故障監視サーバとして、サーバＳ２（３ｃ）とサーバＢ２（３ｄ）が定義され、監視方法や正常かどうかの判定基準などが定義される。

故障監視手段１ｂは、定義管理手段１ａが生成した故障監視定義情報２ｂに基づき、所定のタイミングで故障監視サーバに対し、監視パケットを送信し、故障監視サーバからの応答を待つ。なお、監視パケットは、定義された監視方法によって規定される。また、監視パケットが直接定義されている場合は、その監視パケットを使用する。応答パケットが受信されない場合、または、受信した応答パケットが判定基準に合っていない場合、この故障監視サーバを故障と判定する。そして、振り分け先サーバに対応する故障監視サーバが故障の場合、この振り分け先サーバも故障と判定する。こうして得られた故障監視サーバ及び振り分け先サーバの故障状態に基づき故障監視情報２ｃを生成し、サーバ振り分け手段１ｃに伝達する。振り分け先サーバに対応して複数の故障監視サーバが設定されていた場合、そのうちの１台の故障監視サーバが故障していれば、振り分け先サーバへの振り分け不可、すなわち、振り分け先サーバも故障と判定する。機能分担を行っている一連のサーバ群のうち、１台が故障したら全体として処理機能は果たせないからである。故障監視情報２ｃには、振り分け先サーバごとに振り分け先サーバの振り分け可／不可の状態（稼動中／故障）が設定される。

サーバ振り分け手段１ｃは、振り分け定義情報２ａ及び故障監視情報２ｃに基づき、クライアントからの要求パケットの振り分け先のサーバを適宜判断し、選択された振り分け先サーバにクライアントからの要求パケットを送信する。このとき、故障監視情報２ｃで振り分け先に定義された振り分け先サーバが「故障」と設定されていた場合、この振り分け先サーバには要求パケットを送信しないようにする。

なお、上記の説明の各処理手段は、コンピュータが故障監視プログラム及び負荷分散処理プログラムを実行することによりその処理機能を実現する。
このような構成の負荷分散装置１の動作について説明する。

定義管理手段１ａによって、予め振り分け先を定義する振り分け定義情報２ａと故障監視方法を定義する故障監視定義情報２ｂが生成され、装置内に格納されている。たとえば、図の例で、振り分け定義情報２ａに、振り分け先サーバとして、サーバＳ１（３ａ）とサーバＳ２（３ｃ）が定義されているとする。また、故障監視定義情報２ｂに、故障監視サーバとして、振り分け先サーバＳ１（３ａ）に対し、サーバＳ１（３ａ）とサーバＢ１（３ｂ）が定義され、振り分け先サーバＳ２（３ｃ）に対し、サーバＳ２（３ｃ）とサーバＢ２（３ｄ）が定義されているとする。

故障監視手段１ｂは、所定のタイミングで故障監視定義情報２ｂに基づき、監視パケットを故障監視サーバに送信して診断を行う。上記のような定義が故障監視定義情報２ｂに設定されていた場合、故障監視手段１ｂは、振り分け先サーバとしてのサーバＳ１（３ａ）の診断のため、監視パケットを故障監視サーバに定義されたサーバＳ１（３ａ）とサーバＢ１（３ｂ）に送信し、診断を行う。そして、サーバＳ１（３ａ）またはサーバＢ１（３ｂ）から応答パケットを受信できなかった場合、または、受信した応答パケットが判定基準と一致しなかった場合、その故障監視サーバを故障と判定する。そして、サーバＳ１（３ａ）またはサーバＢ１（３ｂ）のいずれかが故障と判定された場合、振り分け先サーバとしてのサーバＳ１（３ａ）も故障と判定する。同様に、振り分け先サーバとしてのサーバＳ２（３ｃ）の診断のため、監視パケットを故障監視サーバに定義されたサーバＳ２（３ｃ）とサーバＢ２（３ｄ）に送信し、診断を行う。そして、サーバＳ２（３ｃ）またはサーバＢ２（３ｄ）から応答パケットを受信できなかった場合、または、受信した応答パケットが判定基準と一致しなかった場合、その故障監視サーバを故障と判定する。そして、サーバＳ２（３ｃ）またはサーバＢ２（３ｄ）のいずれかが故障と判定された場合、振り分け先サーバとしてのサーバＳ２（３ｃ）も故障と判定する。振り分け先サーバとしてのサーバＳ１（３ａ）及びサーバＳ２（３ｃ）の故障情報は、故障監視情報２ｃに設定され、サーバ振り分け手段１ｃに伝達される。

サーバ振り分け手段１ｃは、クライアントからの要求パケットを入力すると、振り分け定義情報２ａに定義された振り分け先サーバが稼動中であるかどうかを故障監視情報２ｃに基づき判定する。そして、稼動中である振り分け先サーバそれぞれの負荷に応じて、クライアントからの要求パケットの振り分け先を判別し、要求パケットを送信する。たとえば、上記のような定義が振り分け定義情報２ａに設定されていた場合、故障監視情報２ｃにより、振り分け先サーバとしてのサーバＳ１（３ａ）とサーバＳ２（３ｃ）の稼動状態を判別する。双方とも稼動中であれば、負荷が軽い方のサーバに要求パケットを振り分ける。また、一方が故障中であれば、稼動中のサーバに要求パケットを振り分ける。

なお、上記の説明では、背後に存在するサーバＢ１（３ｂ）及びサーバＢ２（３ｄ）に対して直接監視パケットを送信するとしたが、監視パケットの定義によって、サーバＳ１（３ａ）及びサーバＳ２（３ｃ）を経由して監視パケットを背後のサーバＢ１（３ｂ）及びサーバＢ２（３ｄ）に送信して診断することもできる。また、監視パケットとして、クライアントから取得する要求パケットを利用することもできる。どのような方法を選択するかは、故障監視定義情報２ｂにおいて定義される。

このように、本発明では、故障監視定義情報に定義することによって、振り分け先サーバばかりでなく、振り分け先サーバの背後のサーバの故障診断も行って、振り分け判断時にその故障診断結果を利用することができる。これにより、背後のサーバが故障しているにもかかわらず、振り分け先サーバに対して要求パケットが振り分け続けられてしまうことを回避することができる。

以下、実施の形態を、ＨＴＴＰプロトコルにＳＳＬ暗号化通信を用いたＨＴＴＰＳプロトコルにより通信を行うクライアント・サーバシステムの負荷分散装置に適用した場合を例に図面を参照して詳細に説明する。

図２は、本発明の実施の形態の負荷分散装置が配置されるクライアント・サーバシステムの概略構成図である。
負荷分散装置１０は、ＬＡＮ１４を介してサーバＳ１（３１）、サーバＳ２（３２）、サーバＢ１（３３）及びサーバＢ２（３４）に接続するとともに、クライアント５１、５２、５３とインターネット４０を介して接続する。

ここで、サーバＳ１（３１）及びサーバＳ２（３２）は、ＳＳＬアクセラレータとして機能し、サーバＢ１（３３）及びサーバＢ２（３４）は、ＨＴＴＰサーバとして機能する。そして、サーバＳ１（３１）とサーバＢ１（３３）、及びサーバＳ２（３２）とサーバＢ２（３４）は、それぞれ組みとなって、ＨＴＴＰＳ処理を実行する。

また、クライアント５１、５２、５３は、それぞれのＨＴＴＰＳサービス処理実行の際に、ＨＴＴＰＳプロトコルに基づく要求パケットをインターネット４０経由で送信する。
負荷分散装置１０は、通信制御部１１、記憶部１２及び制御部１３を具備し、サーバの故障監視処理とともに、クライアントからの要求をサーバに振り分ける処理を行う。

通信制御部１１は、インターネット４０を介してクライアント５１、５２、５３との間の通信を制御する。同様に、ＬＡＮ１４を介してサーバＳ１（３１）、サーバＳ２（３２）、サーバＢ１（３３）及びサーバＢ２（３４）との間の通信を制御する。なお、通信制御部は、インターネット４０用とＬＡＮ１４用など、それぞれの通信経路に合わせて複数設けるとしてもよい。

記憶部１２は、制御部１３による各種処理に必要なデータなどを格納する記憶手段である。機能的には、振り分け定義情報や故障監視定義情報などの定義情報を格納する定義情報データベース（以下、ＤＢとする）１２１と、診断結果などの故障監視情報を格納する故障監視情報ＤＢ１２２を有する。

制御部１３は、定義管理部１３１、故障監視部１３２及びサーバ振り分け部１３３を有する。
定義管理部１３１は、ＬＡＮ１４経由で接続する端末装置、または負荷分散装置１０に接続するモニタなどの表示装置とキーボードなどの入力装置を用いて利用者（システム管理者）が設定した振り分け先に関する定義と、故障監視に関する定義に基づき、振り分け定義情報と故障監視定義情報を生成し、定義情報ＤＢ１２１に格納する。

故障監視部１３２は、定義情報ＤＢ１２１に格納される故障監視定義情報を読み出し、故障監視定義情報に基づき、サーバＳ１（３１）、サーバＳ２（３２）、サーバＢ１（３３）及びサーバＢ２（３４）の故障監視を行う。故障監視は、振り分け先サーバはもちろん、その背後に存在するサーバに対しても行われ、振り分け先サーバまたはその背後のサーバのいずれかの故障を検出した場合には、その系を故障と判定する。以下、振り分け先サーバと、振り分け先サーバと連携して処理を行う連携サーバを含む所定の処理機能を実現するサーバ群を系と表記する。そして、その結果に基づき故障監視情報を生成し、故障監視情報ＤＢ１２２に格納する。故障監視処理の詳細は後述する。

サーバ振り分け部１３３は、クライアント５１、５２、５３からＨＴＴＰによる要求パケットを入力すると、サーバの状態に応じて要求パケットを振り分ける処理を行う。すなわち、定義情報ＤＢ１２１から振り分け定義情報、そして故障監視情報ＤＢ１２２から故障監視情報を読み出し、振り分け定義情報に定義された振り分け先サーバが稼動中であるか故障中であるかを故障監視情報に基づき判別する。そして、振り分け先サーバが故障中であれば、この振り分け先サーバには要求パケットを振り分けないようにする。また、故障監視定義情報に定義があれば、クライアントから受信した要求パケットを振り分け先サーバに振り分けて送受信処理を行う際に、振り分け先サーバ及びその背後のサーバに対する診断を行う。

ここで、負荷分散装置１０のハードウェア構成について説明する。図３は、本実施の形態の負荷分散装置のハードウェア構成例を示すブロック図である。
負荷分散装置１０は、ＣＰＵ（Central Processing Unit）１０１によって装置全体が制御されている。ＣＰＵ１０１には、バス１０７を介してＲＡＭ（Random Access Memory）１０２、ハードディスクドライブ（ＨＤＤ：Hard Disk Drive）１０３、グラフィック処理装置１０４、入力インタフェース１０５、通信インタフェース１０６が接続されている。

ＲＡＭ１０２には、ＣＰＵ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、ＣＰＵ１０１による処理に必要な各種データが格納される。ＨＤＤ１０３には、ＯＳやアプリケーションのプログラムが格納される。グラフィック処理装置１０４には、モニタ１０８が接続されており、ＣＰＵ１０１からの命令に従って画像をモニタ１０８の画面に表示させる。入力インタフェース１０５には、キーボード１０９ａやマウス１０９ｂが接続されており、キーボード１０９ａやマウス１０９ｂから送られてくる信号を、バス１０７を介してＣＰＵ１０１に送信する。通信インタフェース１０６は、ネットワークに接続されており、ネットワークを介してクライアント及びサーバとの間でデータの送受信を行う。

このようなハードウェア構成によって、本実施の形態の処理機能を実現することができる。なお、上記のハードウェア構成では、モニタ１０８、キーボード１０９ａ及びマウス１０９ｂが直接負荷分散装置１０に接続する構成としたが、通信インタフェース１０６を介して接続する他装置との間でデータ交換を行って、他装置のモニタ、キーボード及びマウスと間接的に接続されるようにしてもよい。

このような負荷分散装置１０では、利用者が事前に振り分け先サーバと、各振り分け先サーバに対する故障監視方法について定義を行う。故障監視方法の定義では、負荷分散装置側から見て振り分け先サーバの背後にあるサーバに何らかの方法で監視パケットが届き、背後のサーバの故障監視ができるように定義が行われる。故障監視方法の詳細は後述する。定義管理部１３１は、利用者の行った振り分け先サーバの定義に基づいて振り分け定義情報を生成し、故障監視方法の定義に基づいて故障監視定義情報を生成する。振り分け定義情報と故障監視定義情報は、定義情報ＤＢ１２１に格納し、故障監視部１３２及びサーバ振り分け部１３３から読み出せるようにしておく。

所定の故障診断周期で故障監視部１３２が起動される。故障監視部１３２は、定義情報ＤＢ１２１から故障監視定義情報を読み出し、読み出した情報に基づいて処理用の故障監視テーブルを生成する。そして、故障監視テーブルに基づいて各サーバの故障診断を行い、診断結果から故障監視情報を生成する。故障監視情報は、故障監視情報ＤＢ１２２に格納し、サーバ振り分け部１３３から読み出しできるようにしておく。一方、クライアントから要求パケットを取得すると、サーバ振り分け部１３３が起動される。サーバ振り分け部１３３では、定義情報ＤＢ１２１から振り分け定義情報を読み出し、故障監視情報を用いて、振り分け先サーバに定義されたサーバのうち、故障監視情報によって稼動中と判定された振り分け先サーバから振り分け先を選択する。

これにより、振り分け先サーバの背後のサーバの故障監視が行われ、背後のサーバが故障していた場合には、対応する振り分け先サーバにクライアントからの要求パケットが振り分けられないようになる。

以下、本実施の形態において実行される故障監視方法について詳細に説明する。
本実施の形態では、故障監視定義情報として、故障監視対象の故障監視サーバと、監視方法と、正常であるかどうかの判定基準をそれぞれ定義することができる。そこで、背後に存在するサーバの故障を確認するため、ある振り分け先サーバに対する故障監視対象を複数登録し、それぞれの対象に対して監視パケットを送信して故障監視を行う故障監視方法と、ある振り分け先サーバに対して、その背後のサーバまで届くような監視パケットを定義し、このような監視パケットを送信して故障監視を行う故障監視方法を例にとり、説明する。

まず、第１の故障監視方法として、振り分け先サーバに対し複数の故障監視サーバを定義して行う場合について説明する。図４は、本実施の形態の第１の故障監視方法の処理の流れの概略を示した図である。図２と同じものには同じ番号を付し、説明は省略する。

定義管理部１３１によって、振り分け定義情報２０１と故障監視定義情報２０２ａが生成される。図の例では、振り分け定義情報２０１として、振り分け先サーバにサーバＳ１（３１）とサーバＳ２（３２）が定義される。また、故障監視定義情報２０２ａとして、振り分け先サーバであるサーバＳ１（３１）に対する故障監視サーバとして、サーバＳ１（３１）とサーバＢ１（３３）が定義される。同様に、振り分け先サーバであるサーバＳ２（３２）に対する故障監視サーバとして、サーバＳ２（３２）とサーバＢ２（３４）が定義される。

故障監視部１３２は、定義情報ＤＢ１２１の故障管理定義情報に基づき、故障監視処理用の故障監視テーブルを作成する。
図５は、本実施の形態の第１の故障監視方法による故障監視テーブルの一例を示した図である。本実施の形態の故障監視テーブル２１０は、振り分け先サーバフィールド２１１、状態フィールド２１２、故障監視サーバ１フィールド２１３及び故障監視サーバ２フィールド２１４を有す。

振り分け先サーバフィールド２１１は、振り分け先サーバとして定義されたサーバ情報が格納される領域であり、図５の例では、振り分け先サーバに、ＳＳＬアクセラレータであるサーバＳ１（３１）と、サーバＳ２（３２）が定義されている。

状態フィールド２１２は、振り分け先サーバに要求パケットを振り分けても大丈夫かどうかについての情報が格納され、稼動中（振り分け可）または故障中（振り分け不可）が診断処理終了後に設定される。

故障監視サーバ１フィールド２１３は、振り分け先サーバに対応する第１の故障監視サーバとその監視方法の定義が格納される。図５の例では、振り分け先サーバとしてのサーバＳ１（３１）に関する第１の故障監視対象として、このサーバＳ１（３１）が定義され、監視方法としてｐｉｎｇ監視が定義されている。振り分け先サーバＳ２（３２）に関しても同様の定義がされている。

故障監視サーバ２フィールド２１４は、振り分け先サーバに対応する第２の故障監視サーバとその監視方法の定義が格納される。図５の例では、振り分け先サーバとしてのサーバＳ１（３１）に関する第２の故障監視対象として、サーバＳ１（３１）の背後にあるサーバＢ１（３３）が定義され、監視方法としてｐｉｎｇ監視が定義されている。振り分け先サーバＳ２（３２）に関しても同様の定義がされている。

以上のフィールドのうち、状態フィールド２１２を除くフィールドは、故障監視定義情報に基づき作成される。また、振り分け先サーバについて、さらに、背後にサーバが存在する場合、故障監視サーバ１フィールド２１３及び故障監視サーバ２フィールド２１４と同様の情報が順次設定される。一方、状態フィールド２１２は、故障監視処理によって設定される故障監視情報に相当する。

以上のように定義されることにより、故障監視処理モジュール１３２ａは、故障監視テーブル２１０に定義された故障監視サーバ（サーバＳ１（３１）とサーバＢ１（３３）、サーバＳ２（３２）とサーバＢ２（３４））に対し、ｐｉｎｇ監視処理を行う。なお、以下の説明では、サーバＳ２（３２）の背後にあるサーバＢ２（３４）が故障しているとして説明する。

図６は、本実施の形態の第１の故障監視方法による故障監視処理のシーケンス図である。
ここで、ｐｉｎｇ監視は、ＴＣＰ／ＩＰネットワークにおいて、ＩＰパケットが通信先まで届いているかどうかや、到達可能であるかどうかを調べるために利用される監視方法で、ＩＣＭＰ（Internet Control Message Protocol）を使って実現される。ｐｉｎｇを実行し、返答が返ってくれば相手のノードは存在し、（少なくともＩＰ層レベルでの）ネットワークソフトウェアはアクティブになっていると判定される。

まず、振り分け先サーバＳ１（３１）の系として、故障監視テーブル２１０に基づき、サーバＳ１故障監視３０１が行われ、続けてサーバＢ１故障監視３０２が行われる。図の例では、サーバＳ１故障監視３０１として負荷分散装置１０からサーバＳ１（３１）に対して要求コマンド３０１ａが送信され、応答コマンド３０１ｂが返る。従って、サーバＳ１（３１）は正常と判定される。サーバＢ１故障監視３０２では、負荷分散装置１０からサーバＢ１（３３）に対して要求コマンド３０２ａが送信され、応答コマンド３０２ｂが返る。従って、サーバＢ１（３３）も正常と判定される。そして、サーバＳ１（３１）及びサーバＢ１（３３）がともに正常であることから、振り分け先サーバＳ１（３１）の系は稼動中であると判定される。

続いて、振り分け先サーバＳ２（３２）の系として、故障監視テーブルに基づき、サーバＳ２故障監視３０３が行われ、続けてサーバＢ２故障監視３０４が行われる。図の例では、サーバＳ２故障監視３０３として負荷分散装置１０からサーバＳ２（３２）に対して要求コマンド３０３ａが送信され、応答コマンド３０３ｂが返る。従って、サーバＳ２（３２）は正常と判定される。サーバＢ２故障監視３０４では、負荷分散装置１０からサーバＢ２（３４）に対して要求コマンド３０４ａが送信されるが、サーバＢ２（３４）からの応答はない（３０４ｂ）。従って、サーバＢ２（３４）は故障と判定される。そして、サーバＳ２（３２）は正常であるが、サーバＢ２（３４）が故障であることから、振り分け先サーバＳ２（３２）の系は故障中であると判定される。

以上の故障監視処理によって、故障監視テーブル２１０の状態フィールド２１２には、振り分け先サーバＳ１（３１）の系は稼動中、振り分け先サーバＳ２（３２）の系は故障中が設定される。これにより、サーバ振り分け部１３３は、サーバＳ２（３２）には振り分けを行わない。

ここで、故障監視処理の処理手順について説明する。図７は、本実施の形態の第１の故障監視方法による故障監視処理の手順を示したフローチャートである。
故障監視処理モジュール１３２ａが起動され、処理が開始される。

［ステップＳ１１］ 故障監視テーブルに基づき、ある振り分け先サーバに関して対象サーバに設定された故障監視サーバを診断する。診断は、定義された監視方法によって行う。

［ステップＳ１２］ 診断の結果、対象の故障監視サーバに異常が検出されたかどうかを判定する。異常が検出された場合は、処理をステップＳ１５へ進める。
［ステップＳ１３］ 故障監視サーバに異常が検出されなかった場合、その振り分け先サーバに関して定義されたすべての監視対象サーバに関する処理が終了したかどうかを判断する。終了していない場合は、ステップＳ１１に戻って、次に定義された監視対象サーバに対する診断処理からの手順を行う。

［ステップＳ１４］ すべての監視対象サーバに関する処理が終了していた場合、この振り分け先サーバに対応する監視対象サーバはすべて正常と判定されるので、振り分け先サーバ稼動中（振り分け可）を故障監視テーブルに設定し、サーバ振り分け部１３３に通知する。

［ステップＳ１５］ 対象の故障監視サーバに異常が検出された場合、この振り分け先サーバの系に故障のサーバが含まれるので処理機能を実行できないと判定し、振り分け先サーバ故障中（振り分け不可）を故障監視テーブルに設定し、サーバ振り分け部１３３に通知する。

以上のように、第１の故障監視方法では、監視対象として背後のサーバを定義可能にして、定義されたサーバすべてに監視パケットを送信して故障監視を行い、その系のいずれかのサーバに故障が検出された場合には、その系の振り分け先サーバは故障中と判定する。これにより、すべてのサーバに対する監視が可能となるとともに、処理ができない系にクライアントからの要求が振り分けられないようにすることができる。

次に、第２の故障監視方法として、振り分け先サーバから背後のサーバまで届くような監視パケットを定義して行う場合について説明する。
図８は、本実施の形態の第２の故障監視方法の処理の流れの概略を示した図である。図４と同じものには同じ番号を付し、説明は省略する。

定義管理部１３１によって、振り分け定義情報２０１と故障監視定義情報２０２ｂが生成される。図の例では、振り分け定義情報２０１として、振り分け先サーバにサーバＳ１（３１）とサーバＳ２（３２）が定義される。また、故障監視定義情報２０２ｂとして、振り分け先サーバであるサーバＳ１（３１）に対し、サーバＳ１（３１）を経由してサーバＢ１（３３）に到達する監視パケットを用いた故障監視方法が定義される。同様に、振り分け先サーバであるサーバＳ２（３２）に対し、サーバＳ２（３２）を経由してサーバＢ２（３４）に到達する監視パケットを用いた故障監視方法が定義される。

故障監視部１３２は、定義情報ＤＢ１２１の故障管理定義情報に基づき、故障監視処理用の故障監視テーブルを作成する。
図９は、本実施の形態の第２の故障監視方法による故障監視テーブルの一例を示した図である。本実施の形態の故障監視テーブル２２０は、振り分け先サーバフィールド２２１、状態フィールド２２２、故障監視サーバフィールド２２３、サービスフィールド２２４及び故障監視方法と送受信パケット内容フィールド２２５を有す。

振り分け先サーバフィールド２２１には、振り分け先サーバフィールド２１１と同様で、図の例では、振り分け先サーバに、ＳＳＬアクセラレータであるサーバＳ１（３１）と、サーバＳ２（３２）が定義されている。

状態フィールド２２２も状態フィールド２１２と同様で、振り分け先サーバに要求パケットを振り分けても大丈夫かどうかについての情報が格納され、稼動中（振り分け可）または故障中（振り分け不可）が診断処理終了後に設定される。

故障監視サーバフィールド２２３には、負荷分散装置１０が故障の監視パケットを送信する送信先のサーバが定義されている。図の例では、振り分け先サーバとしてサーバＳ１（３１）に関する故障監視サーバとして、自身が定義されている。振り分け先サーバＳ２（３２）に関しても同様の定義がされている。

サービスフィールド２２４には、故障監視に利用するサービスの定義が格納される。図の例では、振り分け先サーバであるサーバＳ１（３１）に対し、ＨＴＴＰＳサービスによる処理手順を故障監視に利用することが定義されている。振り分け先サーバＳ２（３２）に関しても同様の定義がされている。

監視方法と送受信パケット内容フィールド２２５には、監視方法として、監視方法の種別と送信する監視パケット及びその振り分け先サーバと振り分け先サーバと連携して処理を行う連携サーバとからなるこの系が正常であると認められる条件が定義される。

図の例の故障監視テーブル２２０上段の振り分け先サーバとしてサーバＳ１（３１）が定義されている系では、ＨＴＴＰＳを利用した診断が定義され、下段の振り分け先サーバとしてサーバＳ２（３２）が定義されている系では、独自プロトコルを利用した診断が定義される。

上段について説明する。図の例では、監視方法として、「アプリ監視（ＳＳＬハンドシェーク以降までの通信を行う）」が定義され、送信データには、「アプリケーションデータ（ＧＥＴ／ＨＴＴＰ／１．０を暗号化したもの）」、稼動中と判断する受信パケットの内容には、「暗号化されたＨＴＴＰ／１．０ ２００ ＯＫ」が定義されている。

ＨＴＴＰＳサービスでは、負荷分散装置１０と振り分け先サーバとの間で、ＳＳＬハンドシェークの手順が実行され、正常に終了した場合にアプリケーション処理が行われる。ＳＳＬハンドシェーク確立までの処理手順の監視は従来も行われていたが、本実施の形態では、さらに、ＳＳＬハンドシェーク移行の処理手順に送信されるパケットを用いての監視を行う。これは、ＳＳＬハンドシェークまでの処理手順では、振り分け先サーバの背後のサーバまでパケットが伝達されず、その故障診断ができないためである。そこで、図の例では、背後にあるＨＴＴＰサーバ（サーバＢ１（３３））まで到達するアプリケーションデータが送信データとして定義される。そして、この送信データに対するＯＫパケットを受信できれば、この系は稼動中であると判断する。

下段について説明する。図の例では、監視方法には「アプリ監視（独自プロトコル）」、送信データには「ＸＸＸ（独自データ）」、稼動中と判断する受信パケットの内容には「ＹＹＹ（正常時の応答）」、が定義されている。この処理を実行する場合、振り分け先サーバには、予め、独自プロトコルによるデータを受信した場合には、このデータを連携先サーバに転送し、得られた応答を負荷分散装置１０に転送するという処理を設定しておく必要がある。

以上のように定義されることにより、故障監視処理モジュール１３２ｂは、故障監視テーブル２２０に定義された故障監視サーバ（サーバＳ１（３１））を経由して背後のサーバ（サーバＢ１（３３））まで転送されるパケットを送信し、この系の故障監視を行う。サーバＳ２（３２）とサーバＢ２（３４）に対しても同様の監視処理を行う。

図１０は、本実施の形態の第２の故障監視方法による故障監視処理のシーケンス図である。図１０の例は、ＨＴＴＰＳを利用した場合の故障監視方法の例を示している。
まず、振り分け先サーバＳ１（３１）の系として、故障監視テーブル２２０に基づき、サーバＳ１故障監視３１１が行われ、正常であればＳＳＬハンドシェーク３１２が行われた後、サーバＢ１（３３）を含む故障監視３１３が行われる。すなわち、ＨＴＴＰＳのプロトコル処理手順として、まず負荷分散装置１０とサーバＳ１（３１）との接続を確立するため、負荷分散装置１０からＳＹＮ（３１１ａ）が送信され、サーバＳ１（３１）が通信可能であれば負荷分散装置１０にＳＹＮ／ＡＣＫ（３１１ｂ）が返る。そして、負荷分散装置１０からＡＣＫ（３１１ｃ）が送信される。こうして、接続が確立された後、ＳＳＬハンドシェーク３１２手順が行われ、負荷分散装置１０からＣｌｉｅｎｔ Ｈｅｌｌｏ（３１２ａ）が送信され、サーバＳ１（３１）からＳｅｒｖｅｒ Ｈｅｌｌｏ（３１２ｂ）が返る。以上の手順により、負荷分散装置１０とサーバＳ１（３１）間のネゴシエーションが確立し、アプリケーション処理が開始される。なお、ここまでの手順で異常が検出された場合には、この振り分け先サーバＳ１（３１）の系は故障中と判断される。

故障監視３１３では、アプリケーションデータとして暗号化された「ＧＥＴ／ＨＴＴＰ／１．１」パケット３１３ａがサーバＳ１（３１）に送信される。ＳＳＬアクセラレータであるサーバＳ１（３１）は、暗号を解読し、「ＧＥＴ／ＨＴＴＰ／１．１」パケット３１３ｂをサーバＢ１（３３）へ送信する。サーバＢ１（３３）が正常であれば、取得した「ＧＥＴ／ＨＴＴＰ／１．１」パケット３１３ｂに対する応答データを返すが、故障中の場合、サーバＳ１（３１）には応答が返らないか、エラー応答が返る。この場合、サーバＳ１（３１）は、Ａｌｅｒｔまたは切断３１３ｃによって、正常な応答パケットが得られなかったことを負荷分散装置１０に通知する。負荷分散装置１０は、正常な応答パケットを受信した場合は振り分け先サーバＳ１（３１）の系は稼動中と判定し、Ａｌｅｒｔまたは切断の場合は、振り分け先サーバＳ２（３２）の系は故障中と判定する。

以上の故障監視処理によって、故障監視テーブル２２０の状態フィールド２２２には、振り分け先サーバに振り分けを行えるかどうかが設定される。
なお、独自プロトコルが指定された場合は、直接故障監視３１３が行われる。

ここで、故障監視処理の処理手順について説明する。図１１は、本実施の形態の第２の故障監視方法による故障監視処理の手順を示したフローチャートである。
故障監視処理モジュール１３２ｂが起動され、処理が開始される。

［ステップＳ２１］ 故障監視テーブル２２０が読込まれ、監視方法が独自プロトコルによる監視方法を用いるのか、この振り分け先サーバの系が本来実行するアプリケーションプロトコルを利用した監視方法を用いるのかを判定する。独自プロトコルの場合、処理をステップＳ２９へ進める。

［ステップＳ２２］ 独自プロトコルを使用しない場合、すなわち、この振り分け先サーバの系のアプリケーションプロトコルを利用する場合、そのプロトコル処理を行う。この場合、ＨＴＴＰＳプロトコルであるので、ＳＳＬハンドシェーク処理を行う。

［ステップＳ２３］ ＳＳＬハンドシェーク処理が正常終了したかどうかを判定する。正常終了しない場合は、処理をステップＳ２８へ進める。
［ステップＳ２４］ アプリケーションデータが定義され、送信する定義がされているかどうかを判定する。定義されていない場合、処理をステップＳ２７へ進め、診断処理を中断する。

［ステップＳ２５］ 故障監視テーブル２２０に定義された送信データを送信する。ここでは、振り分け先サーバはＳＳＬアクセラレータであるので、背後のＨＴＴＰサーバに届くような暗号化された送信データを送信する。

［ステップＳ２６］ 振り分け先サーバから応答パケットを取得した場合、故障監視テーブル２２０に定義された正常時の期待応答パケットと照合する。応答パケットを受信しない場合、及び期待応答パケットと一致しない場合には、処理をステップＳ２８へ進める。

［ステップＳ２７］ 監視用の送信データを送信せず、監視を行わなかった場合、及び
ステップＳ２６において定義された正しい応答が得られたと判定された場合、振り分け先サーバ稼動中（振り分け可）を故障監視テーブルに設定し、サーバ振り分け部１３３に通知し、処理を終了する。

［ステップＳ２８］ ＳＳＬハンドシェーク処理が正常に完了しなかった場合、及び監視用のアプリケーションデータに対する正しい応答が得られなかった場合、振り分け先サーバ故障中（振り分け不可）を故障監視テーブルに設定し、サーバ振り分け部１３３に通知し、処理を終了する。

［ステップＳ２９］ 独自プロトコルによる故障監視が設定されているので、故障監視テーブル２２０に定義された送信データを送信する。
［ステップＳ３０］ 振り分け先サーバから応答パケットを取得した場合、故障監視テーブル２２０に定義された正常時の期待応答パケットと照合する。応答パケットを受信しない場合、及び期待応答パケットと一致しない場合には、処理をステップＳ２８へ進める。

［ステップＳ３１］ ステップＳ２９において定義された正しい応答が得られたと判定された場合、振り分け先サーバ稼動中（振り分け可）を故障監視テーブルに設定し、サーバ振り分け部１３３に通知し、処理を終了する。

以上のように、第２の故障監視方法では、監視対象として背後のサーバまで到達する監視パケットを送信して故障監視を行い、期待した応答が得られない場合には、その系の振り分け先サーバは故障中と判定する。これにより、アプリケーションレベルで、この振り分け先サーバと振り分け先サーバと連携するサーバで構成される系の監視が可能となるとともに、処理ができない系にクライアントからの要求が振り分けられないようにすることができる。なお、第２の故障監視方法では、どのサーバが故障しているのかについては、問題としない。

上記の説明の第１及び第２の故障監視方法では、負荷分散装置１０の故障監視部１３２が定期的に送信する監視パケットによって故障を監視する。そのため、第１及び第２の故障監視方法では、一定間隔でしか故障を検出することができず、その間に故障が発生した場合には、まだその振り分け先サーバの系は稼動中と判断してクライアントからの要求パケットを振り分けてしまうことになる。

そこで、第３の故障監視方法として、クライアントと振り分け先サーバとのパケットのやりとりからも振り分け先サーバの故障を判断できるようにする。ただし、この場合、少なくとも１回はクライアントのパケットを故障中の振り分け先サーバに振り分けてしまうことになるため、上記の第１及び第２の故障監視方法と併用することが望ましい。

図１２は、本実施の形態の第３の故障監視方法の処理の流れの概略を示した図である。図４と同じものには同じ番号を付し、説明は省略する。
定義管理部１３１によって、振り分け定義情報２０１と図示しない故障監視定義情報２０２が生成される。また、故障監視部１３２によって、これらの定義情報に基づき故障監視テーブル２３０が作成される。図の例では、振り分け定義情報２０１として、振り分け先サーバにサーバＳ１（３１）とサーバＳ２（３２）が定義される。また、故障監視定義情報２０２として、振り分け先サーバであるサーバＳ１（３１）に振り分けられるパケットから監視対象とするパケットが定義され、振り分け先サーバが稼動中であると判定する正常判定条件が定義される。同様に、振り分け先サーバであるサーバＳ２（３２）に対し、通常時に振り分けが行われるパケットを監視対象とする故障監視方法が定義される。

サーバ振り分け部１３３では、振り分け処理モジュール１３３ａがクライアント５１からの要求パケットを取得すると、故障監視処理モジュール１３３ｂにこれを引き渡す。故障監視処理モジュール１３３ｂは、引き渡された要求パケットが故障監視テーブル２３０に定義された監視対象パケットと一致するかどうかを判定し、一致しない場合は、監視処理を中断し、振り分け処理モジュール１３３ａに以降の処理を実行させる。一致する場合は、その監視対象パケットを用いて故障監視処理を行う。

ＨＴＴＰＳプロトコルのＳＳＬパケットは、データが暗号化されているため、クライアントとサーバとのＳＳＬパケットの内容を直接見ることはできない。たとえば、クライアントが「ＧＥＴ／ＨＴＴＰ／１．０」をリクエストし、サーバからのレスポンスとして「ＨＴＴＰ／１．１ ２００ ＯＫ」を取得したかというような故障監視定義はできない。そこで、応答パケットに含まれる情報から通信状態を表す箇所を参照し、稼動中／故障中の判定を行う。

ここで、振り分け先サーバであるサーバＳ１（３１）及びサーバＳ２（３２）からの応答で、故障監視処理モジュール１３３ｂが、その系の稼動中または故障中を判断するＳＳＬパケットの参照データについて説明する。

図１３は、ＨＴＴＰＳプロトコルによるＴＣＰレイヤとＳＳＬレイヤが関連するパケット部を示したパケット構成図である。
故障監視処理モジュール１３３ｂは、図のＦｌａｇ（４０１）、Ｔｙｐｅ（４０２）及びＬｅｎｇｔｈ（４０３）を参照して、稼動中／故障中の判定を行う。

Ｆｌａｇ（４０１）は、ＴＣＰレイヤで設定される。クライアントとサーバ（ＳＳＬアクセラレータ）とのコネクション接続において、ＳＳＬハンドシェーク直後のクライアントからの暗号化された要求パケットに対し、通常、サーバ（ＳＳＬアクセラレータ）は暗号化されたレスポンスを返す。ここでは、以後のサーバが故障中の場合には、サーバ（ＳＳＬアクセラレータ）はレスポンスを返さず、単にコネクションを切断する。そこで、Ｆｌａｇ（４０１）のＦＩＮまたはＲＳＴビットがセットされていれば、コネクションが切断されたと判断し、この系を故障中と判定する。

Ｔｙｐｅ（４０２）は、ＳＳＬパケットの種類（ハンドシェーク、アプリケーションデータ、Ａｌｅｒｔ）を表し、ＳＳＬレイヤで設定される。コネクション切断と同様に、背後のサーバが故障中の場合には、サーバ（ＳＳＬアクセラレータ）はレスポンスを返さず、ＳＳＬパケットの１つであるアラート（Ａｌｅｒｔ）を返す。その後、コネクションを切断する場合もある。Ｔｙｐｅ（４０２）には、以降のデータがアプリケーションデータであれば０ｘ１７（＝２３）、アラート（Ａｌｅｒｔ）であれば０ｘ１５（＝２１）が設定されているので、パケットがアラートと判断されれば、この系の振り分け先サーバを故障中と判定する。

Ｌｅｎｇｔｈ（４０３）は、ＳＳＬレイヤで設定され、以降のデータ長が設定されている。クライアントからの暗号化されたリクエストのパケット長はサイズが大きいなどの特徴がある。さらに、そのリクエストに対するサーバからのレスポンスのパケット長は、背後のサーバが存在すればサイズが大きく、背後のサーバが存在しなければサイズが小さいなどの特徴があるので、これを利用して故障中かどうかを判断する。

図１４は、本実施の形態の第３の故障監視方法による故障監視処理のシーケンス図である。図１４の例は、背後のサーバＢ１（３３）が故障と判断される場合の動作イメージを示した図である。

負荷分散装置１０を介してクライアント５１と振り分け先サーバＳ１（３１）とのコネクション接続が開始される。負荷分散装置１０は、振り分け先サーバＳ１（３１）を振り分け先として選択し、クライアント５１から受信したパケットをサーバＳ１（３１）に転送する。この場合、クライアント５１とサーバＳ１（３１）との接続を確立するため、クライアント５１からＳＹＮ（３２１ａ）が送信され、サーバＳ１（３１）が通信可能であればクライアント５１にＳＹＮ／ＡＣＫ（３２１ｂ）が返る。そして、クライアント５１からＡＣＫ（３２１ｃ）が送信される。こうして、接続が確立された後、ＳＳＬハンドシェーク手順が行われ、クライアント５１からＣｌｉｅｎｔ Ｈｅｌｌｏ（３２２ａ）が送信され、サーバＳ１（３１）からＳｅｒｖｅｒ Ｈｅｌｌｏ（３２２ｂ）が返る。以上の手順により、クライアント５１とサーバＳ１（３１）間のネゴシエーションが確立し、アプリケーション処理が開始される。なお、ここまでの手順で異常が検出された場合には、この振り分け先サーバの系は故障中と判断される。

アプリケーション開始により、監視対象パケット３３１ａがクライアント５１より送信されると、サーバ振り分け部１３３の故障監視処理モジュール１３３ｂがこれを検出し、故障監視処理を開始する。サーバＳ１（３１）経由でサーバＢ１（３３）に送信された監視対象パケットに対し、サーバＢ１（３３）は故障であるため応答を返すことができない。このため、サーバＳ１（３１）からは、ＦＩＮ（コネクション切断）３３１ｂが通知される。故障監視処理モジュール１３３ｂは、これを検出し、サーバＳ１（３１）の系は故障中であると判定する。

ここで、故障監視処理の処理手順について説明する。図１５は、本実施の形態の第３の故障監視方法による故障監視処理の手順を示したフローチャートである。
クライアントから要求パケットを取得し、サーバ振り分け部が起動され、処理が開始される。

［ステップＳ４１］ 故障監視テーブル２３０からユーザの定義した監視条件を読込み、入力したクライアントからのパケットと照合し、入力したパケットが監視条件に合致するかどうかを判定する。一致しない場合は、処理をステップＳ４３へ進める。

［ステップＳ４２］ 入力したクライアントからのパケットが監視条件と一致した場合は、故障監視処理モジュール１３３ｂを起動し、故障監視を開始する。
［ステップＳ４３］ 入力したパケットをサーバへ送信し、応答を待つ。

［ステップＳ４４］ 応答パケットを受信し、処理を再開する。なお、応答パケットを受信した段階では、監視対象のパケットに対する応答を受信したのかどうかは、わからない。

［ステップＳ４５］ 監視条件が成立しているのかどうかを判定する。成立している場合は、故障監視処理を再開し、処理をステップＳ４７へ進める。
［ステップＳ４６］ 監視条件が成立しない場合は、故障監視処理を行わず、通常のサーバ振り分け処理を継続し、処理を終了する。

［ステップＳ４７］ 故障監視処理を再開した場合、ユーザの定義した監視条件と応答パケットを照合し、振り分け先サーバが故障中か稼動中かを判定する。稼動中と判断された場合、そのまま処理を終了する。

［ステップＳ４８］ 故障中と判断された場合、振り分け先サーバ故障中（振り分け不可）を故障監視テーブルに設定し、処理を終了する。
以上の処理手順が実行されることにより、クライアントからの要求パケットを用いて背後のサーバを含む振り分け先サーバの系が正常であるかどうかを判断することができる。これにより、故障監視処理の処理周期の間に故障が発生した場合、この故障を検出して以降、この振り分け先サーバへの振り分けを行わないようにすることができる。

なお、上記の説明では、ＳＳＬによってパケットが暗号化され、内容がわからない状態での処理について説明したが、暗号化されないパケットについて同様の処理が可能であることは当然である。

以上の説明のように、第２の故障監視方法及び第３の故障監視方法では、負荷分散装置１０が背後のサーバに直接監視パケットを送信するのではなく、背後のサーバまで到達する監視パケットを振り分け先サーバに送信することによって、振り分け先サーバから背後のサーバに対して監視パケットが送信される。ここで、監視パケットを背後のサーバに送信する振り分け先サーバ（ＳＳＬアクセラレータ）の処理手順について説明する。図１６は、本実施の形態における振り分け先サーバの処理手順を示したフローチャートである。

［ステップＳ６１］ クライアントとの間のコネクション接続処理を行う。
［ステップＳ６２］ クライアントとの間で、ＳＳＬハンドシェーク処理を行う。
［ステップＳ６３］ アプリケーション処理を開始し、取得したリクエストを復号する。

［ステップＳ６４］ 背後のサーバ（ＨＴＴＰサーバ）の状態を確認する。故障中であれば、処理をステップＳ６８へ進める。
［ステップＳ６５］ 背後のサーバ（ＨＴＴＰサーバ）が正常であるので、背後のサーバに復号したリクエストを送信し、レスポンスを取得する。

［ステップＳ６６］ 取得したレスポンスを暗号化する。
［ステップＳ６７］ 負荷分散装置に、暗号化したレスポンスのパケットを送信する。
［ステップＳ６８］ 背後のサーバが故障中と判断されれば、Ａｌｅｒｔを送信したり、コネクションを切断する。

以上の処理手順が実行されることにより、負荷分散装置１０がすべてのサーバに対して直接監視パケットを送信しなくても、監視を行うことができる。
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、負荷分散装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリなどがある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープなどがある。光ディスクには、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ（Random Access Memory）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などがある。光磁気記録媒体には、ＭＯ（Magneto-Optical disk）などがある。

プログラムを流通させる場合には、たとえば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、たとえば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

（付記１） クライアントからの要求パケットを複数サーバに振り分けて負荷を分散するため、前記サーバの故障を監視する処理を行う故障監視プログラムにおいて、
コンピュータを、
前記クライアントからの要求パケットを振り分ける振り分け先サーバごとに、故障監視対象とする故障監視サーバと、前記故障監視サーバの診断に用いる監視パケットを含む監視方法と、必要に応じて前記故障監視サーバを正常と判断する判定基準と、が定義される故障監視定義情報を生成して管理する定義管理手段、
前記故障監視定義情報に基づいて、前記監視方法に応じた監視パケットを前記故障監視サーバに送信し、前記故障監視サーバからの応答なし、または応答パケットが前記判定基準と一致しない場合に前記故障監視サーバを故障と判定し、前記振り分け先サーバに対応する前記故障監視サーバが故障の場合には前記振り分け先サーバへの振り分け不可と判定する前記故障監視手段、
として機能させることを特徴とする故障監視プログラム。

（付記２） 前記定義管理手段に、前記振り分け先サーバに定義されておらず、前記振り分け先サーバと連携して前記要求パケットの処理を行うすべてのサーバ及び前記振り分け先サーバを前記故障監視サーバとして前記振り分け先サーバに関連付けて定義させ、
前記故障監視手段に、前記振り分け先サーバに関連付けて定義された前記故障監視サーバに対して順に前記監視パケットを送信して故障診断を行わせる、
ことを特徴とする付記１記載の故障監視プログラム。

（付記３） 前記故障監視手段は、前記振り分け先サーバに関連付けて定義された前記故障監視サーバがすべて正常の場合のみ前記振り分け先サーバを含む系が正常と判断し、前記振り分け先サーバへの振り分けを可とさせる、
ことを特徴とする付記２記載の故障監視プログラム。

（付記４） 前記定義管理手段に、パケットが前記振り分け先サーバを経由し、前記振り分け先サーバに定義されておらず、前記振り分け先サーバと連携して前記要求パケットの処理を行う連携先サーバに到達する前記監視パケットを定義させるとともに、前記連携先サーバが正常である場合に得られる期待応答パケットを定義させ、
前記故障監視手段に、前記監視パケットを前記振り分け先サーバに送信するとともに、前記振り分け先サーバ経由で取得する前記連携先サーバから前記監視パケットの送信順と逆に転送され、前記振り分け先サーバ経由で取得した応答パケットを取得し、前記応答パケットを前記期待応答パケットと照合して前記振り分け先サーバへの振り分け可または不可の判定を行わせる、
ことを特徴とする付記１記載の故障監視プログラム。

（付記５） 前記定義管理手段に、前記クライアントと前記振り分け先サーバ及び前記振り分け先サーバと連携して前記要求パケットの処理を行う連携サーバの間で交換される任意のパケットを故障監視パケットとして定義させるとともに、前記故障監視パケットに対する応答パケットに応じて前記振り分け先サーバ及び前記連携サーバを正常と判定する正常判定条件を定義させ、
コンピュータを、
前記クライアントから前記要求パケットを取得すると、前記要求パケットが前記故障監視パケットであるかどうかを照合し、前記故障監視パケットである場合には、前記故障監視パケットを所定の前記振り分け先サーバに送信するとともに、前記振り分け先サーバからの応答パケットの取得状態及び取得した場合は前記応答パケットを前記正常判定条件と照合し、成立している場合には前記振り分け先サーバ及び前記連携サーバを正常と判定するサーバ振り分け手段、
として機能させることを特徴とする付記１記載の故障監視プログラム。

（付記６） クライアントからの要求パケットを複数サーバに振り分けて負荷を分散するとともに、前記サーバの故障を監視する負荷分散装置において、
前記クライアントからの要求パケットを振り分ける振り分け先サーバが定義される振り分け定義情報を生成するとともに、前記振り分け先サーバごとに、故障監視対象とする故障監視サーバと、前記故障監視サーバの診断に用いる監視パケットを含む監視方法と、必要に応じて前記故障監視サーバを正常と判断する判定基準と、が定義される故障監視定義情報を生成し、生成した前記振り分け定義情報と前記故障監視定義情報を管理する定義管理手段と、
前記故障監視定義情報に基づいて、前記監視方法に応じた監視パケットを前記故障監視サーバに送信し、前記故障監視サーバからの応答なし、または応答パケットが前記判定基準と一致しない場合に前記故障監視サーバを故障と判定し、前記振り分け先サーバに対応する前記故障監視サーバが故障の場合には前記振り分け先サーバへの振り分け不可と判定する故障監視手段と、
前記クライアントからの要求パケットを入力すると、前記振り分け定義情報に定義された前記振り分け先サーバのうち、前記故障監視手段によって振り分け可と判断された前記振り分け先サーバに対して適宜前記クライアントからの要求パケットを振り分けるサーバ振り分け手段と、
を具備することを特徴とする負荷分散装置。

実施の形態に適用される発明の概念図である。 本発明の実施の形態の負荷分散装置が配置されるクライアント・サーバシステムの概略構成図である。 本実施の形態の負荷分散装置のハードウェア構成例を示すブロック図である。 本実施の形態の第１の故障監視方法の処理の流れの概略を示した図である。 本実施の形態の第１の故障監視方法による故障監視テーブルの一例を示した図である。 本実施の形態の第１の故障監視方法による故障監視処理のシーケンス図である。 本実施の形態の第１の故障監視方法による故障監視処理の手順を示したフローチャートである。 本実施の形態の第２の故障監視方法の処理の流れの概略を示した図である。 本実施の形態の第２の故障監視方法による故障監視テーブルの一例を示した図である。 本実施の形態の第２の故障監視方法による故障監視処理のシーケンス図である。 本実施の形態の第２の故障監視方法による故障監視処理の手順を示したフローチャートである。 本実施の形態の第３の故障監視方法の処理の流れの概略を示した図である。 ＨＴＴＰＳプロトコルによるＴＣＰレイヤとＳＳＬレイヤが関連するパケット部を示したパケット構成図である。 本実施の形態の第３の故障監視方法による故障監視処理のシーケンス図である。 本実施の形態の第３の故障監視方法による故障監視処理の手順を示したフローチャートである。 本実施の形態における振り分け先サーバの処理手順を示したフローチャートである。 従来の負荷分散システムの一例を示した構成図である。

符号の説明

１ 負荷分散装置
１ａ 定義管理手段
１ｂ 故障監視手段
１ｃ サーバ振り分け手段
２ａ 振り分け定義情報
２ｂ 故障監視定義情報
２ｃ 故障監視情報
３ａ サーバＳ１
３ｂ サーバＢ１
３ｃ サーバＳ２
３ｄ サーバＢ２

Claims (5)

1. クライアントからの要求パケットを複数サーバに振り分けて負荷を分散するため、前記サーバの故障を監視する処理を行う故障監視プログラムにおいて、
   コンピュータを、
   前記クライアントからの要求パケットを振り分ける振り分け先サーバごとに、故障監視対象とする故障監視サーバと、前記故障監視サーバの診断に用いる監視パケットを含む監視方法と、必要に応じて前記故障監視サーバを正常と判断する判定基準と、が定義される故障監視定義情報を生成して管理する定義管理手段、
   前記故障監視定義情報に基づいて、前記監視方法に応じた監視パケットを前記故障監視サーバに送信し、前記故障監視サーバからの応答なし、または応答パケットが前記判定基準と一致しない場合に前記故障監視サーバを故障と判定し、前記振り分け先サーバに対応する前記故障監視サーバが故障の場合には前記振り分け先サーバへの振り分け不可と判定する前記故障監視手段、
   として機能させることを特徴とする故障監視プログラム。
2. 前記定義管理手段に、前記振り分け先サーバに定義されておらず、前記振り分け先サーバと連携して前記要求パケットの処理を行うすべてのサーバ及び前記振り分け先サーバを前記故障監視サーバとして前記振り分け先サーバに関連付けて定義させ、
   前記故障監視手段に、前記振り分け先サーバに関連付けて定義された前記故障監視サーバに対して順に前記監視パケットを送信して故障診断を行わせる、
   ことを特徴とする請求項１記載の故障監視プログラム。
3. 前記定義管理手段に、パケットが前記振り分け先サーバを経由し、前記振り分け先サーバに定義されておらず、前記振り分け先サーバと連携して前記要求パケットの処理を行う連携先サーバに到達する前記監視パケットを定義させるとともに、前記連携先サーバが正常である場合に得られる期待応答パケットを定義させ、
   前記故障監視手段は、前記監視パケットを前記振り分け先サーバに送信するとともに、前記振り分け先サーバ経由で取得する前記連携先サーバから前記監視パケットの送信順と逆に転送され、前記振り分け先サーバ経由で取得した応答パケットを取得し、前記応答パケットを前記期待応答パケットと照合して前記振り分け先サーバへの振り分け可または不可の判定を行わせる、
   ことを特徴とする請求項１記載の故障監視プログラム。
4. 前記定義管理手段に、前記クライアントと前記振り分け先サーバ及び前記振り分け先サーバと連携して前記要求パケットの処理を行う連携サーバの間で交換される任意のパケットを故障監視パケットとして定義させるとともに、前記故障監視パケットに対する応答パケットに応じて前記振り分け先サーバ及び前記連携サーバを正常と判定する正常判定条件を定義させ、
   コンピュータを、
   前記クライアントから前記要求パケットを取得すると、前記要求パケットが前記故障監視パケットであるかどうかを照合し、前記故障監視パケットである場合には、前記故障監視パケットを所定の前記振り分け先サーバに送信するとともに、前記振り分け先サーバからの応答パケットの取得状態及び取得した場合は前記応答パケットを前記正常判定条件と照合し、成立している場合には前記振り分け先サーバ及び前記連携サーバを正常と判定するサーバ振り分け手段、
   として機能させることを特徴とする請求項１記載の故障監視プログラム。
5. クライアントからの要求パケットを複数サーバに振り分けて負荷を分散するとともに、前記サーバの故障を監視する負荷分散装置において、
   前記クライアントからの要求パケットを振り分ける振り分け先サーバが定義される振り分け定義情報を生成するとともに、前記振り分け先サーバごとに、故障監視対象とする故障監視サーバと、前記故障監視サーバの診断に用いる監視パケットを含む監視方法と、必要に応じて前記故障監視サーバを正常と判断する判定基準と、が定義される故障監視定義情報を生成し、生成した前記振り分け定義情報と前記故障監視定義情報を管理する定義管理手段と、
   前記故障監視定義情報に基づいて、前記監視方法に応じた監視パケットを前記故障監視サーバに送信し、前記故障監視サーバからの応答なし、または応答パケットが前記判定基準と一致しない場合に前記故障監視サーバを故障と判定し、前記振り分け先サーバに対応する前記故障監視サーバが故障の場合には前記振り分け先サーバへの振り分け不可と判定する故障監視手段と、
   前記クライアントからの要求パケットを入力すると、前記振り分け定義情報に定義された前記振り分け先サーバのうち、前記故障監視手段によって振り分け可と判断された前記振り分け先サーバに対して適宜前記クライアントからの要求パケットを振り分けるサーバ振り分け手段と、
   を具備することを特徴とする負荷分散装置。
   

Images