JP5699202B1 - 呼処理システム、負荷分散方法及び負荷分散プログラム - Google Patents

Abstract

【課題】負荷分散装置を備えた呼処理システムにおいて、確実な音声通話を実現すること。【解決手段】負荷分散装置１において、ＴＴＳサーバ３ａに動作状態を確認するための確認要求を送信し、その確認要求に対する応答結果からＴＴＳサーバ３ａの動作状態を判別し、その判別結果に基づきＴＴＳサーバ３ａの動作状態を閉塞状態又は非閉塞状態として管理する。【選択図】図１

Description

本発明は、サーバの状態を管理・監視する技術に関する。

現在では、所定のサービスを提供するサーバの負荷を軽減するため、様々なシステムにおいて負荷分散装置が用いられている。例えば、図１４に示すように、音声をＩＰ（Internet Protocol）で伝える呼処理システム１００に導入されている。

図１４は、呼処理システムにおいて一部の機能部を模式的に示す図である。ＳＤＰ（Service Delivery Platform）サーバ２は、ＳＩＰ（Session Initiation Protocol）を用いてマルチメディアのセッションを制御するサーバである。また、ＴＴＳ（Text to Speech）サーバ３は、ＳＤＰサーバ２からの要求に基づき、その要求に係るテキストデータをデジタル音声データに変換するサーバであり、変換されたデジタル音声データはＳＩＰで確立されたマルチメディアのセッション中にＲＴＰ（Real-time Transport Protocol）に変換され、ユーザ端末へ通知される。

このような構成において負荷分散装置１は、ＳＤＰサーバ２と複数のＴＴＳサーバ３ａ〜３ｎとの間に接続され、ＨＴＴＰ要求をＳＤＰサーバ２から受信すると一定のアルゴリズムに基づいて１つのＴＴＳサーバ３ｉ（ｉ：ａ〜ｎ）を決定し、そのＴＴＳサーバ３ｉに先のＨＴＴＰ要求を転送する。例えば、ラウンドロビン方式で転送先を順番に割り振ることにより、特定のＴＴＳサーバ３ｉにのみ音声変換に係る負荷が集中するのを防止している。

特開２００３−９９４１３号公報

しかしながら、単にＳＤＰサーバからの要求を負荷分散する処理を実行するため、動作不能の状態にあるＴＴＳサーバに要求が転送されると音声への変換処理が実行できず、結果として要求元の音声が要求先のユーザ端末に届かないという課題があった。

また、更にＳＤＰサーバ２より受信するテキストデータの変換処理に失敗した場合、単なる負荷分散処理では異なるＴＴＳサーバ３ｉへのリトライ処理を繰り返すため、全てのＴＴＳサーバ３ａ〜３ｎの動作不具合を引き起こす可能性があり、結果として要求元の音声が要求先のユーザ端末に届かないという課題もあった。

本発明は、上記事情を鑑みてなされたものであり、負荷分散装置を備えた呼処理システムにおいて、確実な音声通話を実現することを目的とする。

請求項１に記載の呼処理システムは、負荷分散装置を備えた呼処理システムにおいて、前記負荷分散装置は、マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送する要求転送手段と、前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別する変換サーバ状態管理手段と、前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて記憶する変換サーバ閉塞情報記憶手段と、を有し、前記負荷分散装置は、全ての変換サーバが閉塞状態の際に前記要求の受付を拒否する、又は、前記制御サーバは、全ての変換サーバが閉塞状態の際に前記要求に係る他のサーバからの要求の受付を拒否することを要旨とする。

本発明によれば、変換サーバに動作状態を確認するための確認要求を送信し、その確認要求に対する応答結果から変換サーバの動作状態を判別し、その判別結果に基づき変換サーバの動作状態を閉塞状態又は非閉塞状態として管理するため、その管理内容に基づいて制御サーバからの要求を変換サーバに転送できることから、結果として確実な音声通話を実現できる。

本発明によれば、全ての変換サーバが閉塞状態の際に制御サーバからの要求の受付を拒否するため、閉塞状態の変換サーバ群に対する要求のリトライを抑止できる。また、本発明によれば、制御サーバが、全ての変換サーバが閉塞状態の際に他のサーバからの要求の受付を拒否するため、閉塞状態の変換サーバ群に対する要求のリトライを抑止できる。

請求項２に記載の呼処理システムは、請求項１に記載の呼処理システムにおいて、前記要求転送手段は、転送先の変換サーバが閉塞状態の際に前記要求を他の変換サーバに転送することを要旨とする。

請求項３に記載の呼処理システムは、請求項１又は２に記載の呼処理システムにおいて、前記変換サーバ状態管理手段は、前記要求に対する変換サーバでの処理結果がＮＧの際にのみ前記判別処理を実行することを要旨とする。

請求項４に記載の呼処理システムは、請求項１乃至３のいずれかに記載の呼処理システムにおいて、前記制御サーバは、全てのメディアサーバが使用不能状態の際又は電話網が輻輳状態の際に、前記要求に係る他のサーバからの要求の受付を拒否する要求規制手段を有することを要旨とする。

請求項５に記載の負荷分散方法は、負荷分散装置を備えた呼処理システムで行う負荷分散方法において、マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送するステップと、前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別するステップと、前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて変換サーバ閉塞情報記憶手段に記憶するステップと、全ての変換サーバが閉塞状態の際に、前記要求の受付又は前記要求に係る他のサーバからの要求の受付を拒否するステップと、を有することを要旨とする。

請求項６に記載の負荷分散プログラムは、請求項５に記載の負荷分散方法をコンピュータに実行させることを要旨とする。

本発明によれば、負荷分散装置を備えた呼処理システムにおいて、確実な音声通話を実現できる。

呼処理システムの全体構成を模式的に示す図である。 負荷分散装置の機能ブロック構成を示す図である。 ＳＤＰサーバの機能ブロック構成を示す図である。 ＴＴＳサーバの状態管理動作フローを示す図である。 ＴＴＳサーバ閉塞情報の例を示す図である。 ＴＴＳサーバの状態監視動作フローを示す図である。 ＴＴＳサーバの動作状態に基づく新たなＨＴＴＰ要求の規制処理シーケンスを示す図である。 ＭＳサーバの動作状態に基づく新たなＨＴＴＰ要求の規制処理シーケンスを示す図である。 ＭＳサーバの状態監視動作フローを示す図である。 ＭＳサーバの状態監視動作フローを示す図である。 図９及び図１０を説明する際の参照図である。 ＭＳ状態管理テーブルの例を示す図である。 電話網の動作状態に基づく新たなＨＴＴＰ要求の規制処理シーケンスを示す図である。 呼処理システムにおいて一部の機能部を模式的に示す図である。

本発明は、（１）負荷分散装置においてＴＴＳサーバの動作状態を管理・監視し、（２）特に全てのＴＴＳサーバが閉塞状態の場合には、負荷分散装置やＳＤＰサーバにおいてＨＴＴＰ要求の受付を拒否することにより、確実な音声通話を実現するようにしている。以下、本発明を実施する一実施の形態について図面を用いて説明する。

図１は、本実施の形態に係る呼処理システムの全体構成を模式的に示す図である。本呼処理システム１００は、負荷分散装置１と、ＳＤＰサーバ２と、複数のＴＴＳサーバ３ａ〜３ｎと、を備えて構成される。以下、それらの機能について説明する。

負荷分散装置１は、ＳＤＰサーバ２と複数のＴＴＳサーバ３ａ〜３ｎとの間に接続される。そして、図２に示すように、ＨＴＴＰ要求転送部１１と、ＴＴＳサーバ状態管理部１２と、ＴＴＳサーバ閉塞情報記憶部１３と、を備えて構成される。

ＨＴＴＰ要求転送部１１は、ＨＴＴＰ要求をＳＤＰサーバ２から受信すると、予め設定されたアルゴリズムに基づいて複数のＴＴＳサーバ３ａ〜３ｎの中から１つのＴＴＳサーバ３ｉ（ｉ：ａ〜ｎ）を決定し、その決定されたＴＴＳサーバ３ｉに先のＨＴＴＰ要求を転送する機能部である。

また、ＨＴＴＰ要求転送部１１は、後述するＴＴＳサーバ閉塞情報を参照し、全てのＴＴＳサーバ３ａ〜３ｎが閉塞状態の場合にＳＤＰサーバ２からのＨＴＴＰ要求の受付を拒否する機能や、転送先のＴＴＳサーバ３ｉが閉塞状態の場合にＨＴＴＰ要求を他のＴＴＳサーバ３ｉ’に転送する機能を更に備えている。

ＴＴＳサーバ状態管理部１２は、動作状態を確認するための状態確認コマンドを実行して１つのＴＴＳサーバ３ｉ又は全部のＴＴＳサーバ３ａ〜３ｎにおける現在の動作状態を確認し、その確認結果に基づきＴＴＳサーバ３の動作状態を閉塞状態又は非閉塞状態として管理する機能部である。

ＴＴＳサーバ閉塞情報記憶部１３は、ＴＴＳサーバ状態管理部１２で確認された各ＴＴＳサーバ３ａ〜３ｎの夫々の動作状態を各ＴＴＳサーバ３ａ〜３ｎの識別子ＩＤに夫々関連付けてＴＴＳサーバ閉塞情報として記憶する機能部である。このＴＴＳサーバ閉塞情報は、ＨＴＴＰ要求転送部１１によってＨＴＴＰ要求の受付時や転送時に参照される。

以上が負荷分散装置１の備える機能である。続いて、ＳＤＰサーバ２の機能について説明する。ＳＤＰサーバ２は、ＳＩＰを用いてマルチメディアのセッションを制御するサーバであり、負荷分散装置１やＴＴＳサーバ３以外に、Ｗｅｂサーバ４や複数のＭＳ（Media Server）サーバ５ａ〜５ｎ、更には任意の電話網６に通信可能に接続されている（図１参照）。そして、図３に示すように、ＨＴＴＰ要求受付部２１と、ＨＴＴＰ要求規制部２２と、ＴＴＳサーバ状態確認部２３と、を備えて構成される。

ＨＴＴＰ要求受付部２１は、上位のＷｅｂサーバ４から送信されたＨＴＴＰ要求を受け付けて、負荷分散装置１を通じてＴＴＳサーバ３に当該ＨＴＴＰ要求を送信する機能部である。

ＨＴＴＰ要求規制部２２は、全てのＴＴＳサーバ３ａ〜３ｎが閉塞状態の場合、全てのＭＳサーバ５ａ〜５ｎが使用不能状態の場合、又は、電話網６が輻輳状態の場合に、Ｗｅｂサーバ４からの新たなＨＴＴＰ要求の受付を拒否する機能部である。

ＴＴＳサーバ状態確認部２３は、負荷分散装置１に対して各ＴＴＳサーバ３ａ〜３ｎの動作状態を問い合わせる機能部である。

以上がＳＤＰサーバ２の備える機能である。ここで、他のサーバについて説明しておく。ＴＴＳサーバ３とは、負荷分散装置１を介してＳＤＰサーバ２から送信されたＨＴＴＰ要求に基づき、そのＨＴＴＰ要求に係るＲＴＰ内のテキストデータをデジタル音声に変換するサーバである。また、ＭＳサーバ５は、音声ガイダンスの再生やユーザの音声を録音等するサーバである。また、電話網６は、既存のＰＳＴＮ（Public Switched Telephone Network）網やＰＳＴＮを代替するＮＧＮ（Next Generation Network）網等である。

次に、本実施の形態に係る呼処理システムの動作について説明する。最初に、負荷分散装置１で行うＴＴＳサーバ３の状態管理動作について説明する。図４は、ＴＴＳサーバ３の状態管理処理フローを示す図である。

まず、あるＨＴＴＰ要求をＳＤＰサーバ２から受信すると、ＨＴＴＰ要求転送部１１は、所定のアルゴリズムに基づいて複数のＴＴＳサーバ３ａ〜３ｎの中から例えばＴＴＳサーバ３ａを転送先として決定し、ＨＴＴＰ要求の宛先に設定されているバーチャルＩＰアドレス（負荷分散装置１のＳＤＰサーバ側のＩＰアドレス）をＴＴＳサーバ３ａのプライベートＩＰアドレスに書き換えて転送処理を実行する（ステップＳ１０１）。

次に、転送したＨＴＴＰ要求に対するＨＴＴＰ応答をＴＴＳサーバ３ａから受信すると、ＨＴＴＰ要求転送部１１は、そのＨＴＴＰ応答に含まれている応答コードの番号を判別する（ステップＳ１０２）。

そして、その応答コードが２００（処理結果：ＯＫ）の場合、ＨＴＴＰ要求に対する処理がＴＴＳサーバ３ａの内部で何らの問題なく成功しているので、ＨＴＴＰ要求転送部１１は、ＴＴＳサーバ３からのＨＴＴＰ応答をそのままＳＤＰサーバ２に返信する（ステップＳ１０３）。

一方、その応答コードが２００以外（処理結果：ＮＧ）の場合、転送したＨＴＴＰ要求に対する処理が何らかの理由により失敗している可能性があるため、ＴＴＳサーバ状態管理部１２は、状態確認コマンドを実行することにより動作状態を確認するための状態確認要求を送信し、その状態確認要求に対する応答結果からＴＴＳサーバ３ａの現在の動作状態を確認する（ステップＳ１０４）。

すなわち、ＴＴＳサーバ３ａからの状態確認応答に含まれている応答コードの番号を判別し、その応答コードが１（動作状態：ＯＫ）の場合、先のＨＴＴＰ要求に対する処理については成功したものとみなし、ＨＴＴＰ要求転送部１１は、ステップＳ１０３と同様にＴＴＳサーバ３ａからのＨＴＴＰ応答をそのままＳＤＰサーバ２に返信する（ステップＳ１０５）。また、ＴＴＳサーバ状態管理部１２は、そのＴＴＳサーバ３ａの動作状態を非閉塞状態として管理する（ステップＳ１０６）。

このとき、ＴＴＳサーバ３ａの動作状態を新規に確認した場合には、そのＴＴＳサーバ３ａが非閉塞状態である情報を当該ＴＴＳサーバ３ａの識別子ＩＤに対応付けてＴＴＳサーバ閉塞情報記憶部１３のＴＴＳサーバ閉塞情報に追記して管理する。一方、ＴＴＳサーバ３ａの動作状態が過去に閉塞状態として既に管理されていた場合には、その過去に確認された閉塞状態を今回確認した非閉塞状態に変更する。

一方、ＴＴＳサーバ３ａからの状態確認応答に含まれている応答コードが０（動作状態：ＮＧ）の場合、又は、ＴＴＳサーバ３ａから状態確認応答を一定のタイムアウト時間（例えば１０秒）以内に受信しない場合、先のＨＴＴＰ要求に対する処理については失敗したものとみなし、ＨＴＴＰ要求転送部１１は、そのＨＴＴＰ要求を他のＴＴＳサーバ３ｉ’（ｉ’：ｂ〜ｎ）に振り替えて送信する（ステップＳ１０７）。

具体的には、先のアルゴリズムに基づいてＴＴＳサーバ３ａを除く全てのＴＴＳサーバ３ｂ〜３ｎの中から例えばＴＴＳサーバ３ｂを転送先として決定し、ＨＴＴＰ要求の宛先をＴＴＳサーバ３ｂのプライベートＩＰアドレスに書き換えて転送処理を実行する。

そして、ステップＳ１０７の後、ＴＴＳサーバ状態管理部１２は、ＴＴＳサーバ３ａの動作状態を閉塞状態として管理する（ステップＳ１０８）。本ステップ又はステップＳ１０６の結果、ＴＴＳサーバ閉塞情報記憶部１３には例えば図５に示すようなＴＴＳサーバ閉塞情報が記録される。その後、ＨＴＴＰ要求転送部１１は、ＨＴＴＰ要求を新たに受信した場合、このＴＴＳサーバ閉塞情報を参照して動作状態が非閉塞状態であるＴＴＳサーバ３の中から転送先を決定する。

以上の状態管理処理フローによれば、ＨＴＴＰ要求に対するＨＴＴＰ応答内の応答コードが２００以外の場合、転送先のＴＴＳサーバ３ａの動作状態を確認し、その確認結果に基づきＴＴＳサーバ３ａの動作状態を閉塞状態又は非閉塞状態として管理するので、ＨＴＴＰ要求が動作不能状態のＴＴＳサーバ３に転送されることを回避でき、結果としてユーザ端末間での音声通話を確実に実現できる。

続いて、負荷分散装置１で行うＴＴＳサーバ３の状態監視動作について説明する。図６は、ＴＴＳサーバ３の状態監視処理フローを示す図である。

まず、ＴＴＳサーバ状態管理部１２は、ＴＴＳサーバ３の動作状態が閉塞状態又は非閉塞状態のいずれかに関わらず、負荷分散装置１に接続されている全てのＴＴＳサーバ３ａ〜３ｎに対し、状態確認コマンドを実行して各ＴＴＳサーバ３ａ〜３ｎの現在の動作状態を夫々確認する（ステップＳ２０１）。

その後、各ＴＴＳサーバ３ａ〜３ｎから夫々返信された各状態確認応答に含まれる各応答コードを夫々判別し、応答コードが１（動作状態：ＯＫ）の場合、ＴＴＳサーバ状態管理部１２は、その応答コードを返信したＴＴＳサーバ３の動作状態を非閉塞状態として管理する（ステップＳ２０２）。

一方、応答コードが０（動作状態：ＮＧ）の場合、又は、ＴＴＳサーバ３から状態確認応答を一定のタイムアウト時間内に受信しない場合、ＴＴＳサーバ状態管理部１２は、その応答コードを返信したＴＴＳサーバ３、又は状態確認応答を返信しなかったＴＴＳサーバ３の動作状態を閉塞状態として管理する（ステップＳ２０３）。

そして、ステップＳ２０２及び／又はステップＳ２０３の後はステップＳ２０１に戻り、ステップＳ２０１〜Ｓ２０３を定周期で繰り返し実行する。そして、本状態監視処理による全てのＴＴＳサーバ３ａ〜３ｎの状態監視結果は、ＴＴＳサーバ閉塞情報記憶部１３のＴＴＳサーバ閉塞情報で管理され、本状態監視処理を実行する毎に更新（追加、削除、変更）される。

なお、本状態監視処理の実行期間間隔が短い場合、ＴＴＳサーバ閉塞情報内で管理している動作状態がＴＴＳサーバ３の実状態に合致している可能性が高いことから、前述したＴＴＳサーバ３の状態管理動作（図４参照）において、ステップＳ１０４をスキップし、記録済みのＴＴＳサーバ閉塞情報を元にステップＳ１０５又はステップＳ１０７を実行するようにしても構わない。

以上の状態監視処理のフローによれば、各ＴＴＳサーバ３ａ〜３ｎの動作状態を定期的に確認するため、ＴＴＳサーバ閉塞情報内の情報が随時更新されることから、ユーザ端末間での音声通話をより確実に実現できる。

これまで、ＴＴＳサーバ３の動作状態を管理・監視する方法について説明した。引き続き、その管理結果や監視結果を利用して負荷分散装置１及びＳＤＰサーバ２で行う新たなＨＴＴＰ要求の規制動作について説明する。図７は、新たなＨＴＴＰ要求の規制処理シーケンスを示す図である。なお、複数のＴＴＳサーバ３ａ〜３ｎは全て閉塞状態であるとする。

まず、ＳＤＰサーバ２において、ＴＴＳサーバ状態確認部２３は、負荷分散装置３に各ＴＴＳサーバ３ａ〜３ｎの動作状態を問い合わせる（ステップＳ３０１）。

次に、負荷分散装置１において当該動作状態の問合せを受け付けると、ＨＴＴＰ要求転送部１１は、ＴＴＳサーバ閉塞情報記憶部１３のＴＴＳサーバ閉塞情報を参照し、全てのＴＴＳサーバ３ａ〜３ｎが閉塞状態である問合せ結果を返信し、以降、ＳＤＰサーバ２からの新たなＨＴＴＰ要求の受付を拒否する（ステップＳ３０２）。

続いて、新たなＨＴＴＰ要求がＷｅｂサーバ４からＳＤＰサーバ２に送信されると、ＳＤＰサーバ２においてＨＴＴＰ要求受付部２１で一旦受信されるが、ステップＳ３０２の問合せ結果から全てのＴＴＳサーバ３ａ〜３ｎが閉塞状態であるため、ＨＴＴＰ要求規制部２２は、その新たなＨＴＴＰ要求を受け付けることなくメモリ上から削除し、その受付を拒否したことを意味する受付拒否応答をＷｅｂサーバ４に返信する（ステップＳ３０３）。

以上の規制動作シーケンスによれば、全てのＴＴＳサーバ３ａ〜３ｎの動作状態が閉塞状態の場合、負荷分散装置１においてＳＤＰサーバ２からの新たなＨＴＴＰ要求の受付を拒否するため、閉塞状態のＴＴＳサーバ３群に対するＨＴＴＰ要求のリトライを抑止できる。

同様に、全てのＴＴＳサーバ３ａ〜３ｎの動作状態が閉塞状態の場合、ＳＤＰサーバ２においてＷｅｂサーバ４からの新たなＨＴＴＰ要求の受付を拒否するため、閉塞状態のＴＴＳサーバ３群に対するＨＴＴＰ要求のリトライを抑止できる。

なお、このようなＨＴＴＰ要求の規制処理は、全てのＭＳサーバ５ａ〜５ｎが使用不能状態である場合にも適用できる。例えば、図８に示すように、全てのＭＳサーバ５ａ〜５ｎから使用不可を意味するメッセージや信号が送信された場合、ＳＤＰサーバ２は、前述のステップＳ３０３と同様に、新たなＨＴＴＰ要求を受け付けることなくメモリ上から削除し、受付拒否応答をＷｅｂサーバ４に返信する。

ここで、ＳＤＰサーバ２で行うＭＳサーバ５の状態監視方法について詳述する。図９及び図１０は、ＭＳサーバ５の状態監視動作フローを示す図である。両図面はＡ及びＢの符号によって関連付けられている。

まず、ＭＳサーバ５からＭＳ状態情報が通知されると、それに含まれている状態コードの番号を判別する（ステップＳ４０１）。ＭＳ状態情報には、ＭＳサーバ５の動作状態（以下、ＭＳ状態）を表す状態コードが含まれており、例えば、図１１に示すような状態コードのうちいずれかが入力されている。

そして、その状態コードが０００（正常），００４（システムエラー），００５（閉塞中），００６（チャネル故障中），０２１（輻輳中），０２２（一時的輻輳中），０２６（ＡＰＬ（ＭＳサーバ５を実行するためのＡｐｐｌｉｃａｔｉｏｎ）故障）のうちいずれかの場合には、まず、通知元のＭＳサーバ５がＭＳ状態管理テーブルに登録されているか否かを確認する（ステップＳ４０２）。一方、状態コードがそれら以外の場合には、特に処理を行うことなく符号Ｂを介して進み本動作を終了する。

ここで、未登録の場合には、新たなＭＳサーバ５からの通知であるため、そのＭＳサーバ５の識別子ＩＤ（例えば、ＭＳサーバ５のプライベートＩＰアドレス）をＭＳ状態管理テーブルに登録する（ステップＳ４０３）。一方、ＭＳ状態管理テーブルに登録されている場合には、既に監視対象であるため、本ステップをスキップする。

続いて、先の７つの状態コードを更に判別し、０００，００４，０２２の場合には、通知元のＭＳサーバ５のＭＳ状態をＯＫとみなし、そのＭＳサーバ５のＭＳ状態を正常として管理し、更に異常状態テーブルから処理全面停止フラグを削除して、そのＭＳサーバ５との間での処理を実行できるようにする（ステップＳ４０４）。そしてその後、符号Ａを介して進む。

例えば、図１２に示すようなＭＳ状態管理テーブルが作成される。なお、このＭＳ状態管理テーブルには、ＭＳサーバ５の識別子ＩＤやＭＳ状態の他、ＭＳ状態情報が通知された日時、セッションの確立時に設定されるセッションＩＤが対応付けて登録される。

なお、状態コードが００４や０２２の場合であっても、ＭＳサーバ５は使用可能な状態の場合があるため、正常として処理する。

また、異常状態管理テーブルとは、ＭＳ状態管理テーブルとは別の管理テーブルであり、管理対象のＭＳサーバ５が全て異常の場合に処理全面停止フラグが登録される。ＳＤＰサーバ２の起動直後には処理全面停止フラグが登録されており、ＭＳサーバ５からのＭＳ状態情報の状態コードが上記３つの場合に削除（全面停止の解除）される。

一方、状態コードが００５，００６，０２１，０２６の場合には、通知元のＭＳサーバ５のＭＳ状態をＮＧとみなし、まず、異常状態テーブルに処理全面停止フラグが登録されているか否かを確認して（ステップＳ４０５）、そのフラグが登録されていない場合、すなわち、少なくとも１つ以上のＭＳサーバ５との間で処理できる状態の場合には、通知元のＭＳサーバ５のＭＳ状態を異常として管理する（ステップＳ４０６）。そして、全てのＭＳサーバ５のＭＳ状態を確認し（ステップＳ４０７）、全てのＭＳサーバ５のＭＳ状態が異常の場合には、異常状態テーブルに処理全面停止フラグを登録し（ステップＳ４０８）、符号Ａを介して進む。

一方、ステップＳ４０５において処理全面停止フラグが登録されている場合には、全てのＭＳサーバ５のＭＳ状態が既に異常であるため、ステップＳ４０６〜Ｓ４０８をスキップして符号Ａを介して進む。

また、ステップＳ４０７において全てのＭＳサーバ５のＭＳ状態が異常でない場合には、処理全面停止フラグを登録する必要がないため、ステップＳ４０８をスキップして符号Ａを介して進む。

引き続き、図１０を参照しながら説明する。これまでは、状態コードに応じたＭＳ状態管理テーブルや異常状態テーブルへの設定方法について説明したが、これ以降は、状態コードに応じて行うセッションに対する制御方法について説明する。

続いても先の７つの状態コードを更に判別し、状態コードが００６，０２１，０２６の場合には、通知されたＭＳ状態情報にセッショングループＩＤが含まれているか否かを確認し（ステップＳ４０９）、セッショングループＩＤが含まれている場合には、そのセッショングループＩＤのセッションを切断して、ＭＳ状態管理テーブルから該当するＭＳサーバ５のセッションＩＤを削除して本動作を終了する（ステップＳ４１０）。一方、セッショングループＩＤが含まれている場合には、ステップＳ４１０をスキップして本動作を終了する。

一方、状態コードが０２６の場合には、ＭＳ状態情報にセッショングループＩＤが含まれていないことは明らかであるため、単にＭＳ状態管理テーブルから該当するＭＳサーバ５のセッションＩＤを削除して本動作を終了する（ステップＳ４１１）。また、状態コードが０００，００４，００５の場合には、そのような削除処理を実行することなく、本動作を終了する。

なお、ＭＳ状態管理テーブルは、ＳＤＰサーバ２の内部ジョブにより定期的にチェックされ、ＭＳ状態管理テーブルの通知日時が更新されていない場合には、該当のＭＳサーバ５が使用不能になったと判断し、登録されているセッションＩＤのセッションに対して切断を行い、ＭＳ状態管理テーブルから当該セッションＩＤを削除して、ＭＳ状態を異常に変更する。

以上、ＭＳサーバ５に対するＨＴＴＰ要求の規制処理について説明したが、その他、電話網６が輻輳状態である場合にも適用できる。例えば、図１３に示すように、電話網６から、輻輳によりサービス停止中であることを意味するコード番号５０３のメッセージや信号が送信された場合についても同様である。

以上、本実施の形態では、負荷分散装置１をＳＤＰサーバ２と複数のＴＴＳサーバ３ａ〜３ｎとの間に介在させた構成について説明した。一方、負荷分散装置１は、ＳＤＰサーバ２と電話網６との間に介在させることも可能である。例えば、実行系と待機系といった複数のＮＧＮ網の前段に配置する。そして、実行系のＮＧＮ網が震災等の影響により故障や輻輳が発生した場合、具体的には、ＮＧＮ網から一定時間内にデータが送信されない場合や無応答の場合等には、直ちに転送先を待機系のＮＧＮ網に切り替えると共にその旨をＳＤＰサーバ２に返信する。

通常、ＮＧＮ網のＩＰアドレスはＤＮＳ（Domain Name System）で管理されており、そのＤＮＳ内においてＮＧＮ網の待機系のＩＰアドレスが実行系のＩＰアドレスに切り替わるタイミングは１日１回程度と遅い。そこで、故障等の発生時に系を切り替えるため、系切り替えのタイミングを短縮でき、呼処理サービスを継続的に運用できる。

また、故障や輻輳が発生した場合、待機系のＮＧＮ網が実行系となるまでの間、故障中や混雑中のエラーメッセージを定型のフォーマットで安否確認システムの画面や保守運用端末の画面に出力する。ＳＤＰサーバ２からの要求に対してそのような画面で応答することにより、リアルタイム通信の利用可否を保守者に通知でき、故障等の状態からの早期回復を実現できる。

最後に、本実施の形態で説明した負荷分散装置１やＳＤＰサーバ２は、メモリやＣＰＵを備えたコンピュータで実現できる。また、その処理は、プログラムによって実行される。更に、負荷分散装置１やＳＤＰサーバ２の各動作をプログラムとして構築し、コンピュータにインストールして実行させることや、通信ネットワークを介して流通させることも可能である。

１００…呼処理システム
１…負荷分散装置
１１…ＨＴＴＰ要求転送部（要求転送手段）
１２…ＴＴＳサーバ状態管理部（変換サーバ状態管理手段）
１３…ＴＴＳサーバ閉塞情報記憶部（変換サーバ閉塞情報記憶手段）
２…ＳＤＰサーバ（制御サーバ）
２１…ＨＴＴＰ要求受付部
２２…ＨＴＴＰ要求規制部（要求規制手段）
２３…ＴＴＳサーバ状態確認部
３ａ〜３ｎ…ＴＴＳサーバ（変換サーバ）
４…Ｗｅｂサーバ
５ａ〜５ｎ…ＭＳサーバ
６…電話網
Ｓ１０１〜Ｓ１０８、Ｓ２０１〜Ｓ２０３、Ｓ３０１〜Ｓ３０３、Ｓ４０１〜Ｓ４１１…ステップ

Claims (6)

1. 負荷分散装置を備えた呼処理システムにおいて、
   前記負荷分散装置は、
   マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送する要求転送手段と、
   前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別する変換サーバ状態管理手段と、
   前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて記憶する変換サーバ閉塞情報記憶手段と、を有し、
   前記負荷分散装置は、全ての変換サーバが閉塞状態の際に前記要求の受付を拒否する、又は、前記制御サーバは、全ての変換サーバが閉塞状態の際に前記要求に係る他のサーバからの要求の受付を拒否することを特徴とする呼処理システム。
2. 前記要求転送手段は、
   転送先の変換サーバが閉塞状態の際に前記要求を他の変換サーバに転送することを特徴とする請求項１に記載の呼処理システム。
3. 前記変換サーバ状態管理手段は、
   前記要求に対する変換サーバでの処理結果がＮＧの際にのみ前記判別処理を実行することを特徴とする請求項１又は２に記載の呼処理システム。
4. 前記制御サーバは、
   全てのメディアサーバが使用不能状態の際又は電話網が輻輳状態の際に、前記要求に係る他のサーバからの要求の受付を拒否する要求規制手段を有することを特徴とする請求項１乃至３のいずれかに記載の呼処理システム。
5. 負荷分散装置を備えた呼処理システムで行う負荷分散方法において、
   マルチメディアのセッションを制御する制御サーバからの要求を、パケット内のテキストデータをデジタル音声に変換する変換サーバに転送するステップと、
   前記変換サーバに動作状態を確認するための確認要求を送信し、前記確認要求に対する応答結果から前記変換サーバの動作状態を判別するステップと、
   前記判別結果に基づき前記変換サーバの動作状態を閉塞状態又は非閉塞状態として管理し、前記変換サーバの識別子に関連付けて変換サーバ閉塞情報記憶手段に記憶するステップと、
   全ての変換サーバが閉塞状態の際に、前記要求の受付又は前記要求に係る他のサーバからの要求の受付を拒否するステップと、
   を有することを特徴とする負荷分散方法。
6. 請求項５に記載の負荷分散方法をコンピュータに実行させることを特徴とする負荷分散プログラム。

Images