サーバの負荷分散は通常、SLB(Server Load Balancer:負荷分散装置)が利用される。SLBはクライアントである端末装置からの要求(メッセージ)をラウンドロビン方式等の自律振分アルゴリズムに従って複数のサーバのうちの一つに振り分ける。その振り分けによって、情報が交換されている時間の単位であるセッションがサーバに生成され、そのセッションを一意に識別するためのセッションID(識別情報)がSLBを介して端末装置に通知される。
SLBは、セッションIDとそのIDのセッションを保持するサーバとの関係を振分テーブルに登録する。端末装置は、セッションIDをヘッダに格納したメッセージにより要求を行う。SLBは、ヘッダに格納されたセッションIDを用いて振分テーブルを参照することにより、そのセッションIDのセッションを保持するサーバにメッセージを振り分ける。そのようにしてSLBは、セッションが継続する間、同じ端末装置からのメッセージは同じサーバに振り分ける機能を持っている。この機能は一意性保証機能(或いはセッション維持機能)と呼ばれる。
図1、及び図2は、一意性保証の実現方法を説明する図である。図1は、インターネット電話などで用いられるSIP(Session Initiation Protocol)で一意性保証を実現する場合の説明図であり、図2は、Webサーバと端末装置(ブラウザ)がデータを送受信するのに使われるHTTP(HyperText Transfer Protocol)で一意性保証を実現する場合の説明図である。
複数のサーバ1730は、SLB1720により仮想化され、仮想サーバとして端末装置であるクライアント1710からアクセスされる。クライアント1710からのSIPを用いたサービスの要求は、トランスポート・ヘッダの宛先アドレスを仮想サーバのアドレスとしたメッセージ(パケット)の送信により行われる。そのメッセージのSIPヘッダには、識別用のコールIDが格納されている。
クライアント1710から送信されたメッセージは、SLB1720により、トランスポート・ヘッダの宛先アドレス(Dst)がサーバ1730のうちの一つのアドレスに変換され、振り分けられる。その振り分けによってクライアント1710に対応付けられたサーバ1730にSIPセッション1732が生成される。サーバ1730は、そのセッション1732に割り当てた形のコールIDをSIPヘッダに、自サーバ1730のアドレスをトランスポート・ヘッダの送信元アドレス(Src)として格納したメッセージを生成し、SIP用のI/F1731を介してSLB1720に送信する。
SLB1720は、コールIDをセッション識別用の情報として、コールIDとサーバ1730のアドレスの組み合わせをSIP用の振分テーブル1721に登録する。サーバ1730から受信したメッセージは、トランスポート・ヘッダに格納された送信元アドレスを仮想サーバのアドレスに変換し、SIPクライアント1710に送信する。
以降クライアント1710は、SIPヘッダにコールID、トランスポート・ヘッダの宛先アドレスとして仮想サーバのアドレスを格納したメッセージを送信する。SLB1720は、振分テーブル1721を参照し、SIPヘッダ内のコールIDからメッセージの送信先とするサーバ1730を特定し、特定したサーバ1730にメッセージを転送する。その転送のために、トランスポート・ヘッダの宛先アドレスはサーバ1730のアドレスに変換する。サーバ1730から送信されたメッセージは、トランスポート・ヘッダの送信元アドレスは仮想サーバのアドレスに変換する。そのようにしてSLB1720は、セッション1732が保持されている間、クライアント1710から送信されたメッセージは同じサーバ1730に処理させる。この結果、一意性保証が実現される。
一意性保証は、通信プロトコルがSIPからHTTPに変わっても、図2に示すように同様の方法によって実現される。HTTPでは、SLB1720によって振り分けられたクライアント1710からのメッセージはサーバ1730のHTTP用のI/F1735によって受信され、HTTPセッション1736が生成される。サーバ1730は、そのセッション1736に割り当てられたセッションIDをHTTPヘッダのcookieに格納したメッセージを生成し、I/F1735を介してSLB1720に送信する。
SLB1720は、セッションIDとサーバ1730のアドレスの組み合わせをHTTP用の振分テーブル1722に登録する。サーバ1730から受信したメッセージは、トランスポート・ヘッダに格納された送信元アドレスを仮想サーバのアドレスに変換し、クライアント1710に送信する。それにより以降、振分テーブル1722を参照して、クライアント1710から受信したメッセージの転送先を決定することにより、一意性保証を実現させる。
振分テーブル1721に登録されたコールIDとサーバ1730のアドレスの組み合わせ、振分テーブル1722に登録されたセッションIDとサーバ1730のアドレスの組み合わせは共に、一意性保証を実現させるための情報である。このことから以降「一意性保証情報」と総称する。
ところで、例えばNGN(Next Generation Network)のSDP(Service DiscoveryProtocol)の分野では、複数の通信プロトコルを組み合わせたサービスを要求可能なアプリケーション・プログラム(以降「連携アプリケーション」と総称する。アプリケーション・プログラムは「アプリケーション」或いは「アプリ」と略記する)が提供されるようになっている。その連携アプリケーションとは、SIPの呼確立後にHTTP経由で呼情報を表示可能なものや、Webページ経由でSIPの呼制御を行えるものなどである。その連携アプリケーションの代表例として、SIPとHTTPとを連携可能なCSBNA(Call Schedule on Busy or No Answer)アプリケーションがある。
連携アプリケーションでは、通信プロトコル間の連携を実現するために、或る通信プロトコル経由でセッションが生成されたサーバに他の通信プロトコル経由でも到達させる必要がある。つまり、通信プロトコル間の連携にも、一意性保証の実現が必要である。しかしSLBは、通信プロトコル毎にメッセージを振り分けるサーバを選択する。このため、複数の通信プロトコルを連携させる場合、複数の通信プロトコルで一意性保証をサポートしない。
図3は、従来、サーバ群の前段に配置したSLBにより負荷分散させる場合のクライアント、SLB、及びサーバの動作を示すシーケンス図である。このシーケンス図は、アリス(Alice)が使用する端末装置であるクライアントにより、ボブ(Bob)が使用するクライアントとの間でSIPを用いた通話の開始を要求し、その通話が開始できなかったことから、アリスが使用するクライアントがHTTPを用いてURL(Uniform Resource Locator)にアクセスするケースを例にとったものである。通話は、サーバ群のうちの一つであるSIPサーバ1730を介して行うことを想定している。
図3では、アリス及びボブがそれぞれ使用するクライアントは、通信プロトコル別に論理的な実体(エンティティ)を表記している。クライアントの一つであるSIPメッセージを処理するUA(ユーザ・エージェント)は、アリスの使用するクライアントでは「ASU」(「Alice's SIP UA」の略記)、ボブの使用するクライアントでは「BSU」(「Bob's SIP UA」の略記)とそれぞれ表記している。符号としては1711、1713をそれぞれ付している。アリスのクライアントで実行されるブラウザは「AB」(「Alice's browser」の略記)と表記し、符号として1712を付している。論理的な実体に言及する必要がない場合には、図1および図2から「クライアント1710」と表記する。
SLB1720では、構成要素として、送受信・識別部1725、SIP処理部1726、およびHTTP処理部1727を表記している。送受信・識別部1725は、クライアント1710との間の通信や、クライアント1710が送信したメッセージから通信プロトコルを識別する構成要素である。SIP処理部1726は、SIPにより送信されたメッセージ(SIPメッセージ)を処理する構成要素である。HTTP処理部1727は、HTTPにより送信されたメッセージ(HTTPメッセージ)を処理する構成要素である。
SIPサーバ1730では、構成要素として、CSBNAアプリケーション(図中「CSBNAアプリ」と略記)1733、及びSIP UA1711による要求によって生成されるセッション(図3中「アプリセッション#1」と表記)1732を表記している。
先ず、SIP UA1711は、アリスの指示によりステップSB41の処理を実行し、ボブとの通話を開始するためにINVITE要求をSLB1720に送信する(シーケンスS2101)。INVITE要求のためのメッセージのSIPヘッダには、SIP UA1711によるコールID(図3中「Call−ID#1」と表記)が格納される。このINVITE要求は、送受信・識別部1725がステップS401を実行することによりSIPメッセージと認識され、SIP処理部1726に送られる(シーケンスS2102)。SIP処理部1726は、ステップSE41を実行することにより、振り分け先を決定し、SIPサーバ1730に送る(シーケンスS2103)。また、一意性保証を実現するために、コールIDと振り分けたSIPサーバ1730のアドレスの組み合わせを一意性保証情報として振分テーブル1721に登録する(シーケンスS2104)。
SIPサーバ1730のCSBNAアプリケーション1733は、ステップSH41を実行し、ボブ側(着呼側)で使用するコールIDを決定して、そのコールIDをSIPヘッダに格納したINVITE要求をSLB1720に返信する(シーケンスS2105)。
一方、CSBNAアプリケーション1733は、発呼者向けに、処理中であることを通知するための100Trying応答を生成して送信する(シーケンスS2131)。この応答は、送受信・識別部1725がステップSD43を実行することで識別され、SIP処理部1726に渡される(シーケンスS2132)。SIP処理部1726は、ステップSE43を実行することにより、100Trying応答をアリスが使用するクライアント1710に送信する。この結果、SIP UA1711がステップSB42を実行することで100Trying応答は処理される。
SIPサーバ1730から送信されたINVITE要求は、送受信・識別部1725がステップSD42を実行することによりSIPメッセージと識別され、SIP処理部1726に送られる(シーケンスS2106)。SIP処理部1726は、ステップSE42を実行して、INVITE要求中のコールIDとSIPサーバ1730のアドレスの組み合わせを一意性情報として振分テーブル1721に登録する(シーケンスS2107)。その後、INVITE要求をボブが使用するクライアント1710に送信する(シーケンスS2108)。
ボブのクライアント1710に送信されたINVITE要求は、SIP UA1713がステップSC41を実行することで処理される。ここでは、他の通話を行っているなどの理由により、通話を開始できない旨を送信元(アリス)に通知するための486Busy応答(レスポンス)を送信する(シーケンスS2109)。
486Busy応答は、SLB1720の送受信・識別部1725がステップSD44を実行することで識別され、SIP処理部1726に渡される(シーケンスS2110)。SIP処理部1726は、ステップSE44を実行することにより、486Busy応答中のコールIDを用いて振分テーブル1721を参照し、この応答を振り分けるべきSIPサーバ1730を特定する(シーケンスS2111)。それにより、この応答は特定したSIPサーバ1730に送信する(シーケンスS2112)。
SIPサーバ1730のCSBNAアプリケーション1733は、ステップSH42を実行して、受信した486Busy応答を処理する。それにより、セッション1732を生成する(シーケンスS2113)。そのセッション1732ではステップSI41を実行して、そのIDを返す(シーケンスS2114)。また、CSBNAアプリケーション1733は、セッション1732のデータとして、発呼者(ここではアリスのSIP−URI(Uniform Resource Identifier))と着信者(ここではボブのSIP−URI)とを保存する(シーケンスS2115、ステップSI42)。その後セッション1732からの応答が返ると(シーケンスS2116)、HTTP経由でアクセスするためのURLに取得したセッションIDを埋め込み、そのURLをコンタクトURIヘッダに記載した302応答(Redirect)をSLB1720に送信する(シーケンスS2117)。302応答は、ボブのSIP UA1713から486Busy応答が返信されたことにより、発呼者に別の対応を促すために送信される。
この302応答は、送受信・識別部1725がステップSD45を実行することにより識別され、SIP処理部1726に渡される(シーケンスS2117)。SIP処理部1726は、ステップSE45を実行することにより、302応答をアリスが使用するクライアント1710に送信させる(シーケンスS2119)。クライアント1710に送信された302応答は、SIP UA1711がステップSB43を実行することで処理される。それにより、ブラウザ1712が起動される(シーケンスS2120)。
起動されたブラウザ1712は、ステップSA41を実行することにより、302応答のコンタクトURIヘッダに記載されたURLにアクセスするためのHTTP GET要求を送信する(シーケンスS2121)。この要求は、SLB1720の送受信・識別部1725がステップSD46を実行することで識別され、HTTP処理部1727に渡される(シーケンスS2122)。HTTP処理部1727は、ステップSF41を実行することにより、HTTP GET要求で指定されたURLからセッションIDを抽出し、振分テーブル1722を参照する(シーケンスS2123)。
この参照時では、HTTP GET要求はアリスが使用するクライアント1710から受信した最初のHTTPメッセージである。このため振分テーブル1722には、その要求が指定するURLから抽出されたセッションIDは登録されていない。それにより、自律振分の対象とされる。その結果、HTTP GET要求はSIPメッセージと同じSIPサーバ1730に振り分けることは保証できないこととなる。
SLB1720の自動振分機能により、HTTPメッセージがSIPメッセージを振り分けるSIPサーバ1730とは異なるサーバ1730に振り分けられた場合、その異なるサーバ1730にはURLに含まれるセッションIDによって特定されるセッション1732が存在しない。このため、エラーとなり、処理を継続できなくなる。このようなことから、複数のサーバに負荷を分散させる場合であっても、複数の通信プロトコル間の連携に対応した一意性保証を考慮することが重要と考えられる。
サーバ上に生成されたセッションは、一定時間、端末装置からの要求を受信しないことを条件に削除するのが普通である。これは、不要、或いは不要である可能性の高いセッションを残すことによる資源の浪費を抑えるのが主な理由である。
セッションを削除する条件として設定される時間(以降「タイムアウト時刻」)は、様々な状況を考慮して決定される。しかし、端末装置とSLBを接続する通信ネットワーク上のトラフィックやSLBの負荷状態等により、端末装置から要求が送信されてからサーバが受信するまでに比較的に長い時間がかかる場合がある。その場合、本来はセッションが削除されないタイミング(タイムアウトとならないタイミング)で端末装置から要求を送信したにも係わらず、サーバがセッションを削除してしまう可能性がある。
セッションを削除した後にサーバが要求を受信した場合もエラーとなる。サーバの負荷を軽減するためには、エラー処理を行う頻度は抑えるのが望ましい。しかし、本来はタイムアウトとならないタイミングで端末装置から要求を送信したとしても、通信ネットワーク(電気通信回線)上のトラフィック等による送信時間の増大により、タイムアウトとなる場合がありうる。このことから、一意性保証の実現では、サーバの負荷を抑えるために、送信時間の増大に適切に対応できるようにすることも重要と考えられる。
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
<第1の実施形態>
図4は、第1の実施形態による一意性保証情報設定管理装置を用いて構築された通信ネットワークシステムの構成を示す図である。その通信ネットワークシステムは、複数の通信プロトコルに対応した複数の振分対象サーバ30の前段にサーバロードバランサ(SLB。負荷分散装置)20を配置することにより、端末装置であるクライアント10からの要求を振り分ける振分対象サーバ30を複数の振分対象サーバ30のなかからSLB20に選択させる構成となっている。本実施形態による一意性保証情報設定管理装置40は、SLB20による振り分けによって振分対象サーバ30に生成されるセッションを監視して、そのセッションを生成させた通信プロトコルとは異なる通信プロトコル用の一意性保証のための情報(一意性保証情報)をSLB20に設定させることにより、複数の通信プロトコル間の連携を可能とさせる一意性保証を実現させる。クライアント10とSLB20間は、インターネット等の通信ネットワークにより接続され、SLB20、複数の振分対象サーバ30、及び一意性保証情報設定管理装置40間はLAN等の通信ネットワークによって接続されている。
クライアント10は、メッセージ送受信部11を介してSLB20にメッセージ(パケット)を送信する。そのメッセージは、SLB20のクライアント発メッセージ受信部21によって受信され、メッセージ識別部22に渡され、メッセージの通信プロトコルの識別が行われる。メッセージ識別部22の後段には、通信プロトコル(メッセージ)別に複数のプロトコル/メッセージ別処理部23が配置されている。メッセージ識別部22は、その識別結果に応じて、メッセージを対応するプロトコル/メッセージ別処理部23に渡す。
各プロトコル/メッセージ別処理部23は、一意性保証情報識別部23a、MSG振分部23b及び一意性保証情報記録部23cを備えている。各部23a〜23cはそれぞれ以下のように動作する。
一意性保証情報識別部23aは、対応する通信プロトコルのメッセージ中に存在する一意性保証情報の識別情報(例えばセッションID或いはコールID)を識別(抽出)する。その識別は、一意性保証情報識別ルール203を参照して行う。その識別ルール203には、通信プロトコル別、メッセージ別に一意性保証情報の識別情報が格納されている位置に関する情報が定義されている。
MSG振分部23bは、一意性保証情報識別部23aが識別した識別情報を用いて、一意性保証DB201及び通信プロトコル/メッセージ別に用意された一意性保証テーブル202を参照し、メッセージを振り分ける振分対象サーバ30を決定する。一意性保証DB201及び各一意性保証テーブル202には、振分対象サーバ30に生成されるセッション毎に、そのセッションを一意に特定する識別情報、及びそのセッションを持つ振分対象サーバ30を一意に特定する識別情報が一意性保証情報として格納されている。このことから、一意性保証情報識別部23aが識別した識別情報が一意性保証DB201、或いは一意性保証テーブル202の何れかに格納されていた場合、その識別情報を有する一意性保証情報中の他の識別情報が示す振分対象サーバ30を振分先として決定する。一意性保証情報識別部23aが識別した識別情報が一意性保証DB201、及び一意性保証テーブル202の何れにも格納されていない場合には、ラウンドロビン方式等により自律的に振分先を決定する。このとき決定した振分先とする振分対象サーバ30の識別情報は一意性保証DB202に格納する。以降は混乱を避けるために、振分対象サーバ30の識別情報としては「アドレス」を想定する。その識別情報は、振分対象サーバ30に割り当てた番号、名称などであっても良い。
一意性保証情報記録部23cは、メッセージの種類に応じて、セッションの識別情報を一意性保証DB201に格納する。格納する識別情報は、例えばSIPでのコールIDである。HTTPでは識別情報の格納は通常、行われない。
このようにしてメッセージ識別部22からメッセージが渡されたプロトコル/メッセージ別処理部23は、そのメッセージの振分先を決定する。クライアント発メッセージ送信部24は、その決定に従ってメッセージを複数の振分対象サーバ30のうちの一つに宛てて送信する。
上記一意性保証DB201は、SLB20自体が設定する一意性保証情報の保存に用いられる。一意性保証情報設定管理装置40により設定される一意性保証情報の保存には、その一意性保証情報に対応するプロトコル/メッセージ別一意性保証テーブル202が用いられる。メッセージの振分先は、一意性保証DB201の他に、各プロトコル/メッセージ別一意性保証テーブル202を参照して決定する。このため、複数の通信プロトコルの連携時でも一意性保証が実現される。
振分対象サーバ30から送信されたメッセージは、サーバ発メッセージ受信部25により受信され、メッセージ識別部26により通信プロトコルが識別される。それにより、後段に位置する通信プロトコル(メッセージ)別の複数のプロトコル/メッセージ別処理部27のうちの一つにメッセージが渡される。
各プロトコル/メッセージ別処理部27は、一意性保証情報識別部27a、及び一意性保証情報記録部27bを備えている。一意性保証情報識別部27aは、一意性保証情報識別ルール203を参照して、メッセージ中に存在する一意性保証情報の識別情報を識別(抽出)する。一意性保証情報記録部27bは、その識別情報を必要に応じて一意性保証DB201に格納する。識別情報を格納するのは、セッションの生成により識別情報が確定する通信プロトコルのメッセージの場合である。メッセージを受信した振分対象サーバ30のアドレスと、そのメッセージ中の識別情報とを持つ一意性保証情報が一意性保証DB201に格納されていないことを条件に、メッセージ中から抽出した識別情報は、振分対象サーバ30のアドレスのみを持つ一意性保証情報のセッションの識別情報として格納する。
このような処理が行われたメッセージは、サーバ発メッセージ送信部28を介してクライアント10に送信される。
一方、各振分対象サーバ30は、SLB20から送信されたメッセージをメッセージ送受信部31により受信し、メッセージの通信プロトコルに対応するプロトコル処理部32に渡す。プロトコル処理部32の後段には、個別にサービスを提供する複数プロトコル連携部33が位置している。この複数プロトコル連携部33は、複数の通信プロトコルを連携したサービスを提供する。メッセージが渡されたプロトコル処理部32は、そのメッセージを解析して、複数プロトコル連携部33に渡す。
複数プロトコル連携部33は、複数の通信プロトコルの連携が可能なアプリケーションを振分対象サーバ30が実行することで実現される。サービスを提供可能な構成要素として複数プロトコル連携部33のみを図4に示しているのは、複数の通信プロトコル間の連携を可能とさせる一意性保証を実現させる対象だからである。このことから、サービス提供部としては複数プロトコル連携部33のみ着目する。
複数プロトコル連携部33は、プロトコル処理部32から渡されたメッセージにより、そのプロトコル生成部32に対応する通信プロトコルのセッションを生成し、そのセッションに係わるデータ(セッションデータ301)を保存する。そのセッションデータ301は、セッションを一意に特定する識別情報、及びセッションに付随するデータを含むものである。ここでは識別情報としてセッションIDを想定する。
セッション情報監視部34は、サービス提供部(アプリケーション)によるセッション生成を監視し、セッションが生成された際に、セッション関連情報、例えばセッションIDをセッション情報通知部35に渡す。セッション情報通知部35は、セッションID、及びそのセッションIDのセッションを生成した振分対象サーバ30を一意に特定する識別情報、例えばその振分対象サーバ30のアドレスをメッセージの形で一意性保証情報設定管理装置40に送信する。
一意性保証情報設定管理装置40は、振分対象サーバ30から送信されたメッセージをセッション情報収集部41で受信する。受信されたメッセージは一意性保証情報生成部42に渡される。一意性保証情報生成部42は、渡されたメッセージが示すセッションIDと振分対象サーバ30の対応関係からSLB20に設定すべき一意性保証情報を生成し、システム構成情報401を参照して、生成した一意性保証情報の設定を要求すべきSLB20を決定する。
システム構成情報401には、振分対象サーバ30毎に、その振分対象サーバ30の前段に位置するSLB20を一意に特定する識別情報、例えばそのアドレスが示されている。そのシステム構成情報401を参照することにより、複数の振分対象サーバ30を備えたサービス提供用のシステム別に一意性保証情報を設定することも可能となっている。
一意性保証情報記録要求部43は、一意性保証情報生成部42が決定したSLB20に、その一意性保証情報生成部42が生成した一意性保証情報の設定を要求するメッセージを送信する。
このようにして一意性保証情報設定管理装置40から送信されたメッセージは、SLB20の一意性保証情報記録受付部29により受信される。この一意性保証情報記録受付部29は、受信したメッセージを対応するプロトコル/メッセージ別処理部27に渡し、処理させる。それにより、メッセージ中の一意性保証情報を対応するプロトコル/メッセージ別一意性保証テーブル202に記録させる。一意性保証情報を記録するプロトコル/メッセージ別一意性保証テーブル202は、例えば振分対象サーバ30でセッションを生成した通信プロトコルから特定した別の通信プロトコル用のものである。より具体的には、セッションを生成した通信プロトコルがSIPであれば、別の通信プロトコルはHTTPである。一意性保証情報設定管理装置40から要求された一意性保証情報を1つ以上のプロトコル/メッセージ別一意性保証テーブル202に記録することにより、複数の通信プロトコルを連携させる場合であっても、複数の通信プロトコルでそれぞれ同じクライアント10から送信された関連するメッセージはSLB20で同じ振分対象サーバ30に振り分けられることになる。この結果、一意性保証が実現される。
以降は、図5〜図8に示すフローチャート、及び図9に示すシーケンス図を参照して、SLB20、SLB20によってメッセージが振り分けられた振分対象サーバ30、及び一意性保証情報設定管理装置40の動作についてより具体的に説明する。
図5は、クライアント10からのメッセージ送信によりSLB20、振分対象サーバ30、及び一意性保証情報設定管理装置40で実行される処理の流れを示す図である。クライアント10から送信されるメッセージとして想定するのは、何れの振分対象サーバ30でもセッションが生成されていないものである。図5、及び図6〜図8を参照して、振分対象サーバ30でのセッション生成により一意性保証情報をSLB20に設定するためにその振分対象サーバ30、一意性保証情報設定管理装置40、及びSLB20でそれぞれ行われる処理について詳細に説明する。
先ず、ステップS1では、メッセージが振り分けられたことでセッションを生成する振分対象サーバ30で個別処理1が実行される。この個別処理1を振分対象サーバ30が実行することにより、生成したセッションに係わる情報が一意性保証情報設定管理装置40に送信される。
ステップS1に続くステップS2では、振分対象サーバ30からセッションに係わる情報を受信した一意性保証情報設定管理装置40で個別処理2が実行される。この個別処理2を一意性保証情報設定管理装置40が実行することにより、一意性保証情報が生成され、生成した一意性保証情報の設定がSLB20に対して要求される。
ステップS2に続くステップS3では、一意性保証情報の設定が要求されたSLB20で個別処理3が実行される。この個別処理3をSLB20が実行することにより、一意性保証情報がプロトコル/メッセージ別一意性保証テーブル202に記録される。この結果、SLB20は、異なる通信プロトコルであっても一意性保証を実現するように動作するステップS4の状態に移行する。
図6は、上記個別処理1のフローチャートである。この個別処理1は、振分対象サーバ30が実行する処理のなかで一意性保証情報の設定に係わる処理を抽出してその流れを示したものである。セッションを生成していないメッセージの受信を契機に実行される。
先ず、ステップS11では、クライアント10からのメッセージによりセッションを生成する。続くステップS12では、そのセッション生成イベントを検知し、識別情報としてセッションIDを取得する。次のステップS13では、取得したセッションIDに自振分対象サーバ30のアドレス(図中「サーバID」と表記)を付与し、一意性保証情報設定管理装置40に送信する。その送信により、この個別処理1が終了する。
図4に示す構成において、上記ステップS11は複数プロトコル連携部33によって実現される。ステップS12は、セッション情報監視部34によって実現される。ステップS13は、セッション情報通知部35によって実現される。
図7は、上記個別処理2のフローチャートである。この個別処理2は、振分対象サーバ30からセッションID等の受信を契機に一意性保証情報設定管理装置40が実行する処理である。一意性保証情報設定管理装置40としての機能を搭載したプログラム(一意性保証情報設定管理プログラム)をその一意性保証情報設定管理装置40のCPUが実行することで実現される。
先ず、ステップS21では、振分対象サーバ30から送信されたセッションIDやアドレスを含むメッセージ(図中「セッション情報通知」と表記)を受信する。次のステップS22では、メッセージ中からセッションIDおよびそのセッションIDが割り当てられたセッションを保持する振分対象サーバ30のアドレス(サーバID)を取り出し、一意性保証情報生成部42に渡す。その後はステップS23に移行する。
ステップS23では、セッションIDおよび振分対象サーバ30のアドレスより一意性保証情報(図中「振り分け情報」と表記)を生成(構築)する。続くステップS24では、振分対象サーバ30のアドレスをキーにシステム構成情報401を検索し、生成した一意性保証情報の配布先とするSLB20を決定する。その次に移行するステップS25では、配布先として決定したSLB20に一意性保証情報を配布することにより、その一意性保証情報の設定を要求する。その配布により、個別処理2が終了する。
図4に示す構成において、上記ステップS21及びS22はセッション情報収集部41によって実現される。ステップS23及びS24は、一意性保証情報生成部42によって実現される。ステップS25は、一意性保証情報記録要求部43によって実現される。
図8は、上記個別処理3のフローチャートである。この個別処理3は、一意性保証情報設定管理装置40から一意性保証情報(振り分け情報)の記録を要求するメッセージの受信を契機にSLB20が実行する処理である。
先ず、ステップS31では、一意性保証情報設定管理装置40から送信された一意性保証情報(振分け情報)を含むメッセージを受信する。次のステップS32では、メッセージ中から一意性保証情報を抽出し、プロトコル/メッセージ別一意性保証テーブル202に記録する。その記録を行った後、個別処理3が終了する。図4に示す構成において、この個別処理3は一意性保証情報記録受付部29によって実現される。
図9は、クライアント10、SLB20、振分対象サーバ30及び一意性保証情報設定管理装置40の動作を示すシーケンス図である。このシーケンス図は、図3と同様に、アリス(Alice)が使用する端末装置であるクライアントにより、ボブ(Bob)が使用するクライアントとの間でSIPを用いた通話の開始を要求し、その通話が開始できなかったことから、アリスが使用するクライアントがHTTPを用いてURL(Uniform Resource Locator)にアクセスするケースを例にとったものである。通話は、サーバ群のうちの一つであるサーバ(図中「SIPアプリサーバ」と表記)30を介して行うことを想定している。
図9でも図3と同様に、アリス及びボブがそれぞれ使用するクライアントとして、「ASU」(「Alice's SIP UA」の略記」、「AB」(「Alice's browser」の略記」、及び「BSU」(「Bob's SIP UA」の略記)を表記している。符号としては15、16及び17をそれぞれ付している。一意性保証情報設定管理装置40は「振分情報一意性保証情報設定管理装置」と表記している。
SLB20では、構成要素として、送受信・識別部、SIP処理部、HTTP処理部、及び一意性保証情報記録受付部29を表記している。送受信・識別部は、クライアント発メッセージ受信部21、メッセージ識別部22、クライアント発メッセージ送信部24、サーバ発メッセージ受信部25、メッセージ識別部26、及びサーバ発メッセージ送信部28をまとめたものに相当する。SIP処理部は、SIP用のプロトコル/メッセージ別処理部23、及びプロトコル/メッセージ別処理部27をまとめたものに相当する。SLB20では、混乱を避けると共に、冗長的とならないようにするために、一意性保証情報記録受付部29以外には符号を付さないこととする。
振分対象サーバ30では、構成要素としてCSBNAアプリケーション(「CSBNAアプリ」と略記)33、及びセッション情報監視・通知部を表記している。CSBNAアプリケーション33は、複数プロトコル連携部33を実現させるアプリケーションの1例に相当する。このため、同一の符号を付している。セッション情報監視・通知部は、セッション情報監視部34、及びセッション情報通知部35をまとめたものに相当する。ここでは、それらの符号を付さないこととする。
先ず、SIP UA15は、アリスの指示によりステップSB1の処理を実行し、ボブとの通話を開始するためにINVITE要求をSLB20に送信する(シーケンスS41)。INVITE要求のためのメッセージのSIPヘッダには、SIP UA15によるコールID(図3中「Call−ID#1」と表記)が格納される。このINVITE要求は、SLB20の送受信・識別部がステップSD1を実行することによりSIPメッセージと認識され、SIP処理部に渡される(シーケンスS42)。SIP処理部は、ステップSE1を実行することにより、一意性保証DB201及びプロトコル/メッセージ別一意性保証テーブル202を参照して振り分け先を決定し(シーケンスS43)、送受信・識別部に渡す(シーケンスS44)。送受信・識別部は、決定された振り分け先となる振分対象サーバ30にSIPメッセージを送信する(シーケンスS45)。一意性保証を実現するために必要であった場合には、コールIDと振り分けた振分対象サーバ30のアドレスの組み合わせが一意性保証情報として一意性保証DB201に登録される。ここでは上記想定により、一意性保証情報の登録は行われない。
振分対象サーバ30に送信されたSIPメッセージ(ここではINVITE要求)はCSBNAアプリケーション33に渡され、そのアプリケーション33はステップSH1を実行し、ボブ側(着呼側)で使用するコールIDを決定して、そのコールIDをSIPヘッダに格納したINVITE要求をSLB20に返信する(シーケンスS46)。
振分対象サーバ30から送信されたINVITE要求は、SLB20の送受信・識別部がステップSD3を実行することで処理され、SIP処理部に渡される(シーケンスS47)。SIP処理部は、ステップSE2の実行により、INVITE要求中のコールIDとサーバのアドレスの組み合わせを一意性保証情報として一意性保証DB201に登録する(シーケンスS48)。その登録後、ボブのクライアントに送信するためにINVITE要求を送受信・識別部に渡す(シーケンスS49)。送受信・識別部はステップSD4を実行して、INVITE要求をボブのクライアント宛に送信する(シーケンスS50)。
ボブのクライアント宛に送信されたINVITE要求は、SIP UA17がステップSC1を実行することで処理される。ここでは、他の通話を行っているなどの理由により、通話を開始できない旨を送信元(アリス)に通知するための486Busy応答(レスポンス)を送信する(シーケンスS51)。
486Busy応答は、SLB20の送受信・識別部がステップSD5を実行することで識別され、SIP処理部に渡される(シーケンスS52)。SIP処理部は、ステップSE3を実行し、486Busy応答中のコールIDを用いて一意性保証DB201及びプロトコル/メッセージ別一意性保証テーブル202を参照し、この応答を振り分けるべき振分対象サーバ30を特定する(シーケンスS53)。特定した振分対象サーバ30は送受信・識別部に通知する(シーケンスS54)。送受信・識別部は、ステップSD6を実行することにより、486Busy応答を指定された振分対象サーバ30に送信する(シーケンスS55)。
振分対象サーバ30のCSBNAアプリケーション33は、ステップSH2を実行して、受信した486Busy応答を処理する。それにより、セッション36を生成する(シーケンスS56)。そのセッション36ではステップSI1を実行して、そのIDをCSBNAアプリケーション33に返す(シーケンスS57a)。また、そのIDはセッション情報監視・通知部に渡す(シーケンスS57)。セッション情報監視・通知部は、ステップSJ1を実行することにより、セッションID及び自振分対象サーバ30のアドレスを一意性保証情報設定管理装置40に送信する(シーケンスS58)。
セッション36の生成により、セッションに関連するデータがセッションデータ301として保存される。ここではセッションデータ301として、発呼者(アリス)及び受信者(ボブ)のSIP−URIなど、折り返し電話に必要な情報が保存される。
一意性保証情報設定管理装置40は、ステップSK1を実行することにより、受信したセッションID及び振分対象サーバ30のアドレスから一意性保証情報を生成し、生成した一意性保証情報の設定をSLB20に要求する(シーケンスS59)。SLB20の一意性保証情報記録受付部29は、ステップSG1を実行することにより、要求された一意性保証情報を含むメッセージをHTTP処理部に渡す。HTTP処理部は、ステップSF1を実行し、メッセージ中の一意性保証情報を対応するプロトコル/メッセージ別一意性保証テーブル202に登録する(シーケンスS61)。その登録を行った後、そのことを一意性保証情報記録受付部29に通知する(シーケンスS61a)。
一方、セッションIDが返されたCSBNAアプリケーション33は、302(Temporarily Unavailable)応答を生成し、SLB20に送信する(シーケンスS62)。その302応答のコンタクトURIヘッダには、HTTP経由でアクセスするためのURLにセッションIDを埋め込んだものを記載する。
SLB20の送受信・識別部は、ステップSD7を実行することにより、302応答の通信プロトコルを識別してSIP処理部に渡す(シーケンスS63)。SIP処理部は、ステップSE4を実行することにより、302応答の送信を送受信・識別部に要求する(シーケンスS64)。送受信・識別部は、ステップSD8の実行により、要求された302応答をアリスの使用するクライアントに送信する(シーケンスS65)。
アリスのクライアントに送信された302応答は、SIP UA15がステップSB2を実行することで処理される。それによりブラウザ16が起動される(シーケンスS66)。
起動されたブラウザ16は、ステップSA1を実行することにより、302応答のコンタクトURIヘッダに記載されたURLにアクセスするためのHTTP GET要求を送信する(シーケンスS67)。この要求は、SLB20の送受信・識別部がステップSD9を実行することで識別され、HTTP処理部に渡される(シーケンスS68)。HTTP処理部は、ステップSF2を実行することにより、HTTP GET要求で指定されたURLからセッションIDを抽出し、一意性保証DB201及びプロトコル/メッセージ別一意性保証テーブル202を参照して、この要求の振り分け先を特定する(シーケンスS69)。このとき、セッションIDを有する一意性保証情報がプロトコル/メッセージ別一意性保証テーブル202に登録されていることから、セッション36を保持する振分対象サーバ30が振り分け先として決定される(シーケンスS70)。それによりHTTP処理部は、HTTP GET要求をその振分対象サーバ30に送信することを送受信・識別部に指示する(シーケンスS71)。この結果、HTTP GET要求はセッション36を保持する振分対象サーバ30に送信される(シーケンスS72)。
振分対象サーバ30に送信されたHTTP GET要求は、CSBNAアプリケーション33がステップSH3を実行することで処理される。この要求中に存在するセッションIDから対応するセッション36を特定し、そのセッションデータ301を取得する(シーケンスS73、S74、及びステップSI2)。取得したセッションデータ301から、通話終了後の折り返し電話設定を行うためのWebページを生成し、SLB20に送信する(シーケンスS75)。このWebページは、送受信・識別部で識別され、特には図示していないが、HTTP処理部に渡された後、送受信・識別部からアリスの使用するクライアントに送信される(シーケンスS76)。送信されたWebページは、ブラウザ16によって処理される。
<第2の実施形態>
上記第1の実施形態では、振分対象サーバ30による302応答のクライアント10への送信、及び一意性保証情報設定管理装置40によるSLB20への一意性保証情報の設定は並行して行われる形となっている。そのように並行して振分対象サーバ30及び一意性保証情報設定管理装置40がそれぞれの処理を実行する場合、他の通信プロトコルでの一意性保証を実現できない可能性がある。つまりHTTPのプロトコル/メッセージ別一意性保証テーブル202への一意性保証情報を登録する前に、HTTP GET要求がクライアント10から送信される可能性がある。このようなことから第2の実施形態は、確実に一意性保証を実現できるようにしたものである。
第2の実施形態における一意性保証情報設定管理装置の構成は基本的に第1の実施形態と同じである。動作も大部分は同じである。これは、SLB20でも同様である。このようなことから、第1の実施形態で付した符号をそのまま用いて、第1の実施形態から異なる部分についてのみ説明する。
第2の実施形態では、一意性保証情報設定管理装置40による一意性保証情報を設定した後、振分対象サーバ30に302応答を送信させることにより、アリスのクライアント10からのHTTPメッセージはセッション36を保持している振分対象サーバ30に確実に振り分けられるようにしている。このため、第1の実施形態から以下の部分が異なっている。図10〜図14を参照して詳細に説明する。
図10は、クライアント10からのメッセージ送信によりSLB20、振分対象サーバ30、及び一意性保証情報設定管理装置40で実行される処理の流れを示す図である。始めに図10を参照して、第2の実施形態におけるその処理の流れについて具体的に説明する。
図10では、第1の実施形態と基本的に同じ処理には同一の符号を付している。それによりフローチャートでも、第1の実施形態から異なる部分についてのみ説明する。
先ず、ステップS81では、メッセージが振り分けられたことでセッションを生成する振分対象サーバ30で個別処理1が実行される。この個別処理1では、図11に示すように、ステップS12の実行後、ステップS91に移行して、セッションを生成したアプリケーションから制御をセッション情報監視部34に譲渡させる。それにより、アプリケーション、例えば複数プロトコル連携部33を一時的に停止させる。この停止後、ステップS13に移行する。
ステップS81の次にはステップS2で個別処理2が一意性保証情報設定管理装置40で実行され、その実行後はステップS82で個別処理3がSLB20で実行される。その個別処理2では、図12に示すように、ステップS32の実行後、ステップS901に移行して、一意性保証情報記憶要求部43に、一意性保証情報の設定が完了した旨を示す設定完了応答を返す。その応答を返した後、個別処理3を終了する。
ステップS82の個別処理3の実行後は、ステップS83に移行する。そのステップS83では、振分対象サーバ30で制御を譲渡させたアプリケーションに制御を返す個別処理4が一意性保証情報設定管理装置40で実行される。その個別処理4の実行後、ステップS4に移行する。
図13は、個別処理4のフローチャートである。ここで図13を参照して、この個別処理4について詳細に説明する。この個別処理4は。SLB20からの設定完了応答の受信を契機に実行される一意性保証情報設定管理装置40の処理の他に、振分対象サーバ30が実行する処理が含まれる。一意性保証情報設定管理装置40が実行する処理は、一意性保証情報設定管理装置40としての機能を搭載したプログラム(一意性保証情報設定管理プログラム)をその一意性保証情報設定管理装置40のCPUが実行することで実現される。
先ず、ステップS1001では、設定完了応答の受信により、セッション情報収集部41に対し、その旨を振分対象サーバ30に通知するための応答を送信するための発行要求を行う。続くステップS1002では、セッション情報収集部41に、発行要求に応じた応答(通知完了応答)を送信させる。このステップS1001及びS1002は一意性保証情報設定管理装置40が実行する。ステップS1003以降は、振分対象サーバ30が実行する。
ステップS1003に続くステップS1003では、通知完了応答をセッション情報通知部35により受信し、セッション情報監視部34にその旨を通知する。それによりセッション情報監視部34は、ステップS1004を実行して、譲渡されていた制御をアプリケーション(複数プロトコル連携部33)に返す。そのようにしてアプリケーションの停止を解除させた後、ステップS4に移行する。
図14は、第2の実施形態におけるクライアント10、SLB20、振分対象サーバ30及び一意性保証情報設定管理装置40の動作を示すシーケンス図である。このシーケンス図では、第1の実施形態と同じ処理、動作には同一の符号を付している。それにより、第1の実施形態から異なる部分のみ説明する。
第2の実施形態では、セッションID、及び振分対象サーバ30のアドレスを含むメッセージを振分対象サーバ30から受信した一意性保証情報設定管理装置40は、ステップSK11を実行する。それにより、生成した一意性保証情報の設定をSLB20に要求する(シーケンスS1101)。その要求により、ステップSG11及びSF1が実行され、シーケンスS60〜S61aが実現される。一意性保証情報記録受付部29は、シーケンスS61aにより一意性保証情報の設定が通知されると、その旨を通知するための設定完了応答を一意性保証情報設定管理装置40に送信する(シーケンスS1102)。
一意性保証情報設定管理装置40は、SLB20に一意性保証情報の設定を要求した後、この設定完了応答の受信を待つ状態に移行している。この設定完了応答を受信すると、振分対象サーバ30に一意性保証情報の設定が完了したことを通知するために、通知完了応答を振分対象サーバ30に送信する(シーケンスS1103)。
CSBNAアプリケーション33はセッション36の生成に伴うセッションIDをセッション情報監視・通知部に通知して制御を渡し停止する。セッション情報監視・通知部は、セッション36に制御を返し(シーケンスS1104)、それによってセッション36からCSBNAアプリケーション33に制御が返る(シーケンスS1105)。そのようにして制御が返ったCSBNAアプリケーション33は、セッションIDを埋め込んだURLをコンタクトURIヘッダに記載した302応答をSLB20に送信する(シーケンスS62)。
なお、第2の実施形態では、CSBNAアプリケーション33を一時的に停止することにより、302応答によるHTTPメッセージがクライアント10から送信される前に、SLB20での一意性保証情報の設定を完了させるようにしているが、別の方法を採用しても良い。例えば図15に示すように、振分対象サーバ30にメッセージの送受信を制御・管理する送信制御部37を搭載し、その送信制御部37の制御により、振分対象サーバ30から302応答を送信するタイミングを調整するようにしても良い。図15に示す変形例では、SLB20から一意性保証情報の設定完了を一意性保証情報設定管理装置40に通知することにより、送信制御部37には、一意性保証情報設定管理装置40から一意性保証情報の設定完了を通知するようになっている。その設定完了の通知は、要求された一意性保証情報をSLB20に解析させることにより、SLB20から振分対象サーバ30に行わせることもできる。
<第3の実施形態>
上記第1及び第2の実施形態では、一意性保証情報を登録するプロトコル/メッセージ別一意性保証テーブル202は、セッションを生成した通信プロトコルにより固定的に定めた通信プロトコルのプロトコル/メッセージ別一意性保証テーブル202に一意性保証情報を一意性保証情報設定管理装置40により登録するようになっている。第3の実施形態は、セッションを生成した通信プロトコルに応じて、一意性保証情報を設定すべき通信プロトコルを選択し、設定するようにしたものである。
第3の実施形態における一意性保証情報設定管理装置の構成は基本的に第1の実施形態と同じである。動作も大部分は同じである。これは、SLB20でも同様である。このようなことから、第1の実施形態で付した符号をそのまま用いて、第1、或いは第2の実施形態から異なる部分についてのみ説明する。
第3の実施形態では、一意性保証情報を設定する通信プロトコルを一意性保証情報設定管理装置40が選択するために、セッション情報監視部34は、セッションIDの他に、そのセッションIDが割り当てられたセッションを生成する契機となった要求の通信プロトコルを示すプロトコル情報をセッション情報通知部35に渡す。それによりセッション情報監視部34は、セッションID、自サーバのアドレス、及びプロトコル情報を含むメッセージを一意性保証情報設定管理装置40に送信する。このことから、図6、及び図11に示す個別処理1において、ステップS12でプロトコル情報を取得する部分、及びステップS13でプロトコル情報を送信する部分が第1及び第2の実施形態に追加されている。
図16は、第3の実施形態で実行される個別処理2のフローチャートである。
第3の実施形態では、ステップS21の次にステップS1301に移行し、受信したメッセージ中からセッションID、振分対象サーバ30のアドレス(サーバID)、及びプロトコル情報を抽出して一意性保証情報生成部42に渡すようになっている。また、ステップS24の次にステップS1302に移行して、ステップS1302で抽出されたプロトコル情報が示す通信プロトコル、つまりセッション36の生成契機となった通信プロトコルの種類の判別を行う。この結果、生成契機となった通信プロトコルがSIPと判別した場合、ステップS1303に移行して、一意性保証情報を設定すべきプロトコル/メッセージ別一意性保証テーブル202の通信プロトコルはHTTPと指定(決定)する。生成契機となった通信プロトコルがHTTPと判別した場合には、ステップS1304に移行して、一意性保証情報を設定すべきプロトコル/メッセージ別一意性保証テーブル202の通信プロトコルはSIPと指定(決定)する。その何れかの指定を行った後、ステップS25に移行する。
個別処理3としては、図17或いは図18に示すものが実行される。図17及び図18にそれぞれ示す個別処理3は、図5及び図10に示すように振分対象サーバ30、一意性保証情報設定管理装置40及びSLB20の処理が実行される場合のものである。
図17に示す個別処理3では、ステップS31の次にステップS1401に移行して、一意性保証情報設定管理装置40が指定したプロトコル/メッセージ別一意性保証テーブル202の通信プロトコルの種類を判別する。この結果、指定の通信プロトコルがSIPと判別した場合、ステップS1402に移行して、SIP用のプロトコル/メッセージ別一意性保証テーブル202に一意性保証情報を記録する。指定の通信プロトコルがHTTPと判別した場合には、ステップS1403に移行して、HTTP用のプロトコル/メッセージ別一意性保証テーブル202に一意性保証情報を記録する。そのようにして何れかのプロトコル/メッセージ別一意性保証テーブル202に一意性保証情報を記録した後、この個別処理3が終了する。
一方、図18に示す個別処理3では、ステップS1402、或いはS1403の後、ステップS1505に移行して、一意性保証情報設定管理装置40に一意性保証情報の設定が完了した旨を示す設定完了応答を返す。その応答を返した後、個別処理3を終了する。
なお、第3の実施形態では、セッションの生成契機となった通信プロトコルに応じて、一意性保証情報を設定すべき通信プロトコルを決定しているが、セッションを生成したアプリケーションに応じて、一意性保証情報を設定すべき通信プロトコルを決定するようにしても良い。或いは、更にセッションを生成したアプリケーションを考慮しても良い。これは、アプリケーションによって連携可能な通信プロトコルの組み合わせは決まっているからである。その組み合わせの例としては、SIPとSOAP(Simple Object Access Protocol)、SOAPとHTTP、SOAPとFTP(Simple Object Access Protocol)、SOAPとSMTP(Simple Mail Transfer Protocol)、SOAPとRTP(Real-time Transport Protocol)等が挙げられる。
SIPでは、コールIDによりメッセージが識別される。HTTPとSIPを連携可能なアプリケーションで先にHTTPメッセージの受信によりセッションを生成した場合、クライアント10は連携用のセッションIDを格納したSIPメッセージを生成して送信する必要がある。そのようなメッセージの送信は、サービスを提供するアプリケーションに応じて行わせれば良い部分である。SLB20による複数の振分対象サーバ30への負荷分散を実現するシステム構成用にメッセージを変更する必要はない。
また、本実施形態(第1及び第3の実施形態)では、一意性保証情報設定管理装置40は振分対象サーバ30、及びSLB20とは別の装置として実現しているが、何れかの振分対象サーバ30、或いはSLB20に搭載させる形で実現させても良い。
図4において、セッション情報収集部41は、振分対象サーバ30に生成されたセッションの識別情報を取得する識別情報取得部45として機能し、一意性保証情報生成部42及び一意性保証情報記録要求部43は、識別情報を用いて生成する一意性保証情報をSLB20に設定する保証情報設定部46として機能する。それら識別情報取得部45及び保証情報設定部46の構成は、一意性保証情報設定管理装置40を搭載させる装置によって以下のように変化する。
一意性保証情報設定管理装置40を振分対象サーバ30に搭載する場合、セッション情報通知部35は不要となり、セッション情報収集部41は、他の振分対象サーバ30から送信されるメッセージの受信に用いられることになる。このことから、識別情報取得部45はセッション情報監視部34及びセッション情報収集部41を含む構成となる。各サーバ30に一意性保証情報設定管理装置40を搭載させる想定では、識別情報取得部45はセッション情報監視部34のみを含む構成となる。一方、保証情報設定部46は、一意性保証情報生成部42及び一意性保証情報記録要求部43を含む構成のままである。
一意性保証情報設定管理装置40をSLB20に搭載した場合には、例えば一意性保証情報記録要求部43を不要として、一意性保証情報記録受付部29に、一意性保証情報生成部42が生成した一意性保証情報を渡すようにしても良い。そのような想定では、保証情報設定部46は、一意性保証情報生成部42及び一意性保証情報記録受付部29を含む構成となる。識別情報取得部45はセッション情報収集部41のみを含む構成となる。
図19は、本発明を適用可能なコンピュータのハードウェア構成の一例を示す図である。ここで図19を参照して、一意性保証情報設定管理装置40として使用可能なコンピュータ、言い換えれば上記一意性保証情報設定管理プログラムを実行させることで一意性保証情報設定管理装置40を実現可能なコンピュータの構成について具体的に説明する。
図19に示すコンピュータは、CPU61、メモリ62、入力装置63、出力装置64、外部記憶装置65、媒体駆動装置66、及びネットワーク接続装置67を有し、これらがバス68によって互いに接続された構成となっている。同図に示す構成は一例であり、これに限定されるものではない。
CPU61は、当該コンピュータ全体の制御を行う。
メモリ62は、プログラム実行、データ更新等の際に、外部記憶装置65(あるいは可搬型の記録媒体70)に記憶されているプログラムあるいはデータを一時的に格納するRAM等のメモリである。CPU61は、プログラムをメモリ62に読み出して実行することにより、全体の制御を行う。
入力装置63は、例えば、キーボード、マウス等の操作装置と接続されたインターフェースである。操作装置に対するユーザの操作を検出し、その検出結果をCPU61に通知する。
出力装置64は、例えば表示装置と接続された表示制御装置である。ネットワーク接続装置67は、例えば複数の振分対象サーバ30及びSLB20と通信ネットワークを介して通信を行うためのものである。外部記憶装置65は、例えばハードディスク装置である。主に各種データやプログラムの保存に用いられる。
媒体駆動装置66は、光ディスクや光磁気ディスク等の可搬型の記録媒体70にアクセスするものである。
一意性保証情報設定管理プログラムは、外部記憶装置65、若しくは記録媒体70に記録されているか、或いは通信ネットワークを介してネットワーク接続67により取得される。その管理プログラムをメモリ62に読み出してCPU61が実行することにより、一意性保証情報設定管理装置40は実現される。
<第4の実施形態>
振分対象サーバ30上に生成されたセッションデータ301は、そのセッションIDを格納したメッセージを一定時間(タイムアウト時間)、受信しないことを条件に削除され、タイムアウトとなる。その削除に合わせて、SLB20が管理する、対応する一意性保証情報が削除される。
端末装置であるクライアント10から送信されたメッセージが実際に対応する振分対象サーバ30に受信されるまでに要する送信時間は、クライアント10とSLB20を接続する通信ネットワークのトラフィック等によって変化する。送信時間が増大した場合には、本来はタイムアウトとならないようにクライアント10から送信されたメッセージが対応する振分対象サーバ30に届く前に、タイムアウトとなる可能性がある。振分対象サーバ30から送信されたメッセージがクライアント10に受信されるまでに要する送信時間の増大は、タイムアウトを発生し易くする。第4の実施形態は、そのような送信時間の増大によるタイムアウトに対応できるように、振分対象サーバ30に生成したセッションを管理するようにしたものである。
第4の実施形態におけるSLB、各振分対象サーバ、及び一意性保証情報設定管理装置の構成は大部分、第1の実施形態と同じである。動作も大部分は同じである。このようなことから、第1の実施形態で付した符号をそのまま用いて、第1の実施形態から異なる部分についてのみ説明する。
第4の実施形態では、振分対象サーバ30がセッションを削除する場合、その削除を予告し、その予告後にクライアント10からメッセージが受信されるか否か監視し、その監視結果から予告したセッションを実際に削除するか否か決定するようにしている。そのようにして、セッションを削除すべきタイミングとなっても直ちにセッションを削除せず、そのタイミング後にクライアント10から受信されるメッセージに対応可能な期間を設けることにより、送信時間の増大によって発生するタイムアウトを抑制する。そのタイムアウトの抑制により、エラーの発生もより抑えられる。この結果、エラー処理による振分対象サーバ30の負荷はより軽減させることができる。
第4の実施形態では、各振分対象サーバ30、一意性保証情報設定管理装置40、及びSLB20は以下の様になっている。
振分対象サーバ30のセッション情報通知部35は、一意性保証情報設定管理装置40との間でメッセージの送受信を行う。複数プロトコル連携部33は、図22に示す結果データ管理テーブル351を用いて、生成したセッション(セッションデータ301)を管理する。この結果データ管理テーブル351には、生成したセッション毎に、セッションを示すセッションID(図22中「対象ID」と表記)、対応するセッションを削除すべきタイムアウト時刻、及びセッションの削除を予告した時刻である通知時刻が格納される。セッションの削除予告は、セッション情報通知部35を介して一意性保証情報設定管理装置40に通知する。その削除予告では、例えば削除対象とするセッションのIDが併せて通知される。これは、一意性保証情報設定管理装置40とSLB20間で送受信されるメッセージ、一意性保証情報設定管理装置40から振分対象サーバ30に送信されるメッセージでも同様である。タイムアウト時刻は、対応するメッセージの受信により、予め定めた一定時間、延長される。
一意性保証情報設定管理装置40のセッション情報収集部41は、振分対象サーバ30との間でメッセージの送受信を行う。一意性保証情報記録要求部43は、SLB20との間でメッセージの送受信を行う。振分対象サーバ30から通知された削除予告は、セッション情報収集部41からSLB制御メッセージ処理部451に渡される。
SLB制御メッセージ処理部451は、振分対象サーバ30の複数プロトコル連携部33から送信されるメッセージに従い、SLB20を制御する。その制御は、図21に示す様な削除ID管理テーブル452を用いて行う。この削除ID管理テーブル452には、図22に示す様に、削除予告されたセッション毎に、そのID、そのセッションを生成している振分対象サーバ30のアドレス(図21中「サーバアドレス」と表記)、状態、その状態の最終更新時刻が格納される。
SLB制御メッセージ処理部451は、削除予告が通知された場合、クライアント10から受信する削除予告されたセッションに対応するメッセージを転送することなく保存することを指示するためのバッファ開始通知をSLB20に送信する。その送信は、一意性保証情報記録要求部43を介して行われる。
上記したようにシステム構成情報401には、振分対象サーバ30毎に、その振分対象サーバ30の前段に位置するSLB20を一意に特定する識別情報、例えばそのアドレスが示されている。SLB制御メッセージ処理部451は、システム構成情報401を参照して、バッファ開始通知を送信すべきSLB20を特定する。特定されるSLB20は、削除予告を通知した振分対象サーバ30の前段に位置するSLB20である。
バッファ開始通知を受信したSLB20は、その応答を返す。その応答は、一意性保証情報記録要求部43によって受信され、SLB制御メッセージ処理部451に渡される。それによりSLB制御メッセージ処理部451は、削除予告応答を振分対象サーバ30に送信する。
図21には、削除ID管理テーブル452の状態として「バッファ開始通知」が表記されている。SLB制御メッセージ処理部451は、バッファ開始通知の送信により、状態として「バッファ開始通知」を格納し、削除予告応答の振分対象サーバ30への送信により、状態として「削除予告応答」を格納する。そのようにして、メッセージの送信により、そのメッセージの種類に応じて状態を更新する。その更新に合わせて、最終更新時刻も更新する。
SLB20は、バッファ開始通知の受信により、削除予告されたセッションに対応するメッセージを転送することなく保存する。その保存を行う前にクライアント10から受信した対応するメッセージは、SLB20から振分対象サーバ30に転送される。そのようにメッセージが転送された振分対象サーバ30の複数プロトコル連携部33は、削除予告したセッションの削除を中止し、その旨を一意性保証情報設定管理装置40に通知する。
削除中止が通知された一意性保証情報設定管理装置40のSLB制御メッセージ処理部451は、バッファ開始通知により保存したメッセージの転送を指示するためのバッファ転送通知をSLB20に送信する。削除ID管理テーブル452の対応する状態は「バッファ転送」に更新する。
そのバッファ開始通知を受信したSLB20は、保存したメッセージの転送を行う。その後は、メッセージを保存することなく転送を行う。
バッファ開始通知を受信する前に、SLB20が削除予告されたセッションに対応するメッセージを転送しなかった場合、振分対象サーバ30の複数プロトコル連携部33は、削除予告したセッションを削除する。その削除は、一意性保証情報設定管理装置40から削除予告応答を受信するのを待って行い、その旨を一意性保証情報設定管理装置40に通知する。
削除を行った旨を示す削除完了通知を受信した一意性保証情報設定管理装置40のSLB制御メッセージ処理部451は、バッファ開始通知により保存したメッセージの削除を指示するためのバッファ削除通知をSLB20に送信する。削除ID管理テーブル452の対応する状態は「バッファ削除」に更新する。
SLB20に送信されたバッファ開始通知は、一意性保証情報記録受付部29から各プロトコル/メッセージ別処理部23に渡される。各プロトコル/メッセージ別処理部23のMSG振分部23bは、バッファ開始通知が渡されることにより、対応するメッセージをキューイング部251に格納する。その格納は、図20に示す様なバッファ対象IDテーブル252を用いて管理する。そのバッファ対象IDテーブル252には、セッションID毎に、メッセージの保存を開始した開始時刻が格納される。それにより、セッションIDを持つメッセージがキューイング部251に格納される。バッファ開始通知の受信により、プロトコル/メッセージ別処理部23のうちの一つは、一意性保証情報記録受付部29を介して応答を一意性保証情報設定管理装置40に送信させる。
MSG振分部23bは、一意性保証情報設定管理装置40からバッファ削除通知を受信した場合、その通知に対応するメッセージをキューイング部251から転送することなく削除する。バッファ転送通知を受信した場合には、その通知に対応するメッセージをキューイング部251から読み出して転送する。
図23及び図24は、第4の実施形態におけるSLB20、振分対象サーバ30、及び一意性保証情報設定管理装置40の動作を示すシーケンス図である。図23は、振分対象サーバ30が削除予告を通知後にクライアント10から対応するメッセージが送信されない場合のものであり、図24は、そのメッセージが送信された場合のものである。次に図23及び図24を参照して、SLB20、振分対象サーバ30、及び一意性保証情報設定管理装置40の動作について具体的に説明する。図23及び図24において、一意性保証情報設定管理装置40は「経路制御」と表記している。
最初に、図23を参照して、クライアント10からメッセージが送信されない場合の動作を説明する。
振分対象サーバ30は、タイムアウト時刻の到来により、削除すべきタイミングとなったセッションの削除を予告するための削除予告通知を一意性保証情報設定管理装置40に送信する(シーケンスS2301)。一意性保証情報設定管理装置40は、受信した削除予告通知を処理し、SLB20にバッファ開始通知を送信する(シーケンスS2302)。SLB20は、バッファ開始通知の受信により、その応答(開始応答)を一意性保証情報設定管理装置40に送信する(シーケンスS2503)。
その応答を受信した一意性保証情報設定管理装置40は、削除予告応答を振分対象サーバ30に送信する(シーケンスS2304)。振分対象サーバ30は、削除予告通知を送信してから一意性保証情報設定管理装置40がバッファ開始通知をSLB20に送信するまでの期間DT、削除予告したセッションに対応するメッセージを受信していない。このため、削除予告したセッションを削除し、その旨を示す削除完了通知を一意性保証情報設定管理装置40に送信する(シーケンスS2305)。その削除完了通知を受信した一意性保証情報設定管理装置40は、保存された対応するメッセージが存在すれば転送することなく削除させるためのバッファ削除通知をSLB20に送信する(シーケンスS2306)。
次に、図24を参照して、クライアント10からメッセージが送信される場合の動作を説明する。図24では、図23と同じ内容のシーケンスには同じ符号を付している。それにより、図23から異なる部分に着目して動作を説明する。
図24に示すケースでは、振分対象サーバ30が削除予告通知を送信してから一意性保証情報設定管理装置40がバッファ開始通知をSLB20に送信するまでの期間DT内に、クライアント10がメッセージをSLB20に送信している(シーケンスS2401)。それにより、そのメッセージはSLB20を介して振分対象サーバ30に転送されている(シーケンスS2402)。シーケンスS2403及びS2404は、そのメッセージが転送された結果、振分対象サーバ30からの応答の送信によって生じている。シーケンスS2405は、応答を受信したクライアント10から更なるメッセージの送信により生じている。
図24に示す様な期間DT内におけるメッセージの転送により、振分対象サーバ30は削除予告したセッションの削除を中止する。このため、削除予告応答を受信した振分対象サーバ30は、削除中止通知を一意性保証情報設定管理装置40に送信する(シーケンスS2406)。その削除中止通知の受信により、一意性保証情報設定管理装置40は、バッファ転送通知をSLB20に送信する(シーケンスS2407)。
このようにして第4の実施形態では、本来、セッションを削除すべきタイミングとなってから実際に削除すべきタイミングとなるまでの間に、クライアント10からメッセージが送信されたか否か監視する期間DTを設けている。それにより、その期間DT分、タイムアウトとするタイミングを遅らせている。このため、送信時間の増大によって発生するタイムアウトは抑制され、エラーの発生もより抑えられることとなる。
以降は、図25〜図27にそれぞれ示すフローチャートを参照して、振分対象サーバ30、一意性保証情報設定管理装置40、及びSLB20が実行する処理について詳細に説明する。
図25は、振分対象サーバ30が実行する処理のフローチャートである。この処理は、複数プロトコル連携部33を実現させるアプリケーションを振分対象サーバ30が実行することによって実現される。始めに図25を参照して、その処理について詳細に説明する。この図25では、生成したセッションの管理に特に係わる部分のみを抜粋して処理の流れを示している。
複数プロトコル連携部33は、生成したセッションを管理するために、生成したセッションのIDを格納したインスタンステーブルを用意している。それにより、クライアント10側で決定したID(識別子)を格納したメッセージでなければ、インスタンステーブルにセッションIDが格納されていないIDを格納したメッセージはエラー処理の対象となる。
先ず、ステップS2501では、クライアント10からのメッセージ(リクエスト)が転送されたか否か判定する。そのメッセージをSLB20が転送した場合、判定はYesとなってステップS2502に移行する。そのメッセージを受信していない場合には、判定はNoとなってステップS2510に移行する。
ステップS2502では、受信したメッセージ中に格納されたセッションID(図25中「識別子」と表記)をキーにインスタンステーブルを検索する。続くステップS2503では、メッセージに対応するセッション(図25中「インスタンス」と表記)が存在したか否か判定する。メッセージに格納されたセッションIDがインスタンステーブルに登録されていた場合、判定はYesとなり、ステップS2504に移行する。そのセッションIDがインスタンステーブルに存在しない場合、判定はNoとなってステップS2506に移行する。
ステップS2504では、結果データ管理テーブル351の対応するタイムアウト時刻を一定時間Tだけ延長させる。次のステップS2505では、受信したメッセージへの応答を作成して返信するための処理を実行する。その実行後、一連の処理を終了する。
ステップS2506では、転送されたメッセージがクライアント10側でIDを付ける通信プロトコルか否か判定する。転送されたメッセージがその通信プロトコルで送信されたもの(例えばSIPメッセージ)であった場合、判定はYesとなり、ステップS2507でメッセージのIDをインスタンステーブルに登録し、セッションを生成した後、ステップS2505に移行する。転送されたメッセージがクライアント10側でIDを付けない通信プロトコルで送信されたものであった場合には、判定はNoとなり、ステップS2508でログの書き出しや通知といったエラー処理を実施し、更にステップS2509でエラー応答を行った後、一連の処理を終了する。
上記ステップS2501の判定がNoとなって移行するステップS2510では、タイムアウトイベントが到来したか否か判定する。現在時刻が結果データ管理テーブル351に登録されたタイムアウト時刻のうちの何れかと一致したような場合、判定はYesとなってステップS2511に移行する。現在時刻が何れのタイムアウト時刻とも一致しないような場合には、判定はNoとなってステップS2513に移行する。図25では、ステップS2513への移行は、一意性保証情報設定管理装置40から削除予告応答を受信した場合のみを想定する。
ステップS2511では、タイムアウト時刻が一致したレコードの通知時刻として現在時刻を設定する。続くステップS2512では、タイムアウト時刻が一致したレコードのセッションIDを格納した削除予告通知を一意性保証情報設定管理装置40に送信する。その送信を行った後、一連の処理を終了する。
一方、ステップS2513では、削除予告応答に格納されているセッションIDから特定される結果データ管理テーブル351中のレコードのタイムアウト時刻が、そのレコードの通知時刻と同じか否か判定する。それらの時刻が一致している(許容範囲内で一致している)場合、判定はYesとなってステップS2514に移行する。それらの時刻が一致していない場合、つまり対応するメッセージの転送によってステップS2504の処理が実行された場合、判定はNoとなってステップS2516に移行する。
ステップS2514では、上記レコードのセッションIDを持つセッションを削除し、その旨を示す削除完了通知を一意性保証情報設定管理装置40に送信する。次のステップS2515では、そのセッションIDを格納したレコード(エントリ)を結果データ管理テーブル351から削除すると共に、そのセッションIDをインスタンステーブルから削除する。その後、一連の処理を終了する。ステップS2516では、削除中止通知を一意性保証情報設定管理装置40に送信する。その後、一連の処理を終了する。
図26は、一意性保証情報設定管理装置40が実行する処理のフローチャートである。この処理は、図25に示す処理を実行する振分対象サーバ30に関連する部分の処理の流れを示したものである。それにより、振分対象サーバ30からの削除予告通知、削除完了通知、或いは削除中止通知の受信、SLB20からのバッファ開始応答の受信に対応する部分の処理のみを示している。次に図26を参照して、この設定管理装置40が実行する処理について詳細に説明する。
SLB制御メッセージ処理部451は、図26に示す処理を実行することで実現される。図26に示す処理自体は、例えば上記一意性保証情報設定管理プログラムに搭載された機能によって実現される。
先ず、ステップS2601では、受信したメッセージは削除予告通知か否か判定する。その削除予告通知を受信した場合、判定はYesとなってステップS2602に移行する。その削除予告通知を受信しなかった場合には、判定はNoとなってステップS2605に移行する。
ステップS2602では、削除予告通知に格納されている、送信元の振分対象サーバ30のアドレス(図26中「アプリアドレスIP」と表記)をキーにシステム構成情報401を参照し、バッファ開始通知を送信すべきSLB20を決定する。続くステップS2603では、削除ID管理テーブル452に、新たにレコード(エントリ)を登録する。そのレコードは、削除予告通知に格納されているセッションID、振分対象サーバ30のアドレスを格納し、最終更新時刻として現在時刻、状態として「バッファ開始通知」が設定されたものである。そのようなレコードを登録した後は、ステップS2604でバッファ開始通知を決定したSLB20に送信する。その後、一連の処理を終了する。
ステップS2605では、バッファ開始応答を受信したか否か判定する。そのバッファ開始応答を受信した場合、判定はYesとなってステップS2606に移行する。バッファ開始応答以外のメッセージを受信した場合には、判定はNoとなってステップS2609に移行する。
ステップS2606では、バッファ開始応答に格納されたセッションIDをキーに削除ID管理テーブル452を参照し、削除予告応答を送信すべき振分対象サーバ30のアドレスを取得する。次のステップS2607では、削除ID管理テーブル452のアドレスを取得したレコード中の状態を「削除予告応答」に更新し、最終更新時刻を現在時刻に更新する。その次に移行するステップS2608では、取得したアドレスを持つ振分対象サーバ30に削除予告応答を送信する。その後、一連の処理を終了する。
ステップS2609では、削除完了通知を受信したか否か判定する。その削除完了通知を受信した場合、判定はYesとなってステップS2610に移行する。削除完了通知以外のメッセージ、つまり削除中止通知を受信した場合には、判定はNoとなってステップS2613に移行する。
ステップS2610では、削除完了通知に格納された振分対象サーバ30のアドレスをキーにシステム構成情報401を参照し、バッファ削除通知を送信すべきSLB20を決定する。続くステップS2611では、削除ID管理テーブル452の削除完了通知に格納されたセッションIDを持つレコードの状態を「バッファ削除」に更新し、最終更新時刻を現在時刻に更新する。その次に移行するステップS2612では、決定したSLB20にバッファ削除通知を送信する。その後、一連の処理を終了する。
ステップS2613では、削除中止通知に格納された振分対象サーバ30のアドレスをキーにシステム構成情報401を参照し、バッファ転送通知を送信すべきSLB20を決定する。続くステップS2614では、削除ID管理テーブル452の削除中止通知に格納されたセッションIDを持つレコードの状態を「バッファ転送」に更新し、最終更新時刻を現在時刻に更新する。その次に移行するステップS2615では、決定したSLB20にバッファ転送通知を送信する。その後、一連の処理を終了する。
このようにして一意性保証情報設定管理装置40は、削除予告通知はバッファ開始通知の形でSLB20に送信する。同様に、削除完了通知はバッファ削除通知、削除中止通知はバッファ転送通知の形でそれぞれSLB20に送信する。それにより、振分対象サーバ30から送信されるメッセージの種類に応じてSLB20は動作することになる。
図27は、SLB20が実行する処理のフローチャートである。この処理は、図26に示す処理を実行する一意性保証情報設定管理装置40に関連する部分の処理の流れを示したものである。それにより、一意性保証情報設定管理装置40からのバッファ開始通知、バッファ削除通知、或いはバッファ転送通知の受信、端末装置SLB20からのメッセージの受信に対応する部分の処理のみを示している。最後に図27を参照して、このSLB20が実行する処理について詳細に説明する。
図27に示す処理は、プロトコル/メッセージ別処理部23のMSG振分部23bを実現させる処理に相当する。その処理自体は、SLB20に搭載されたプログラム(負荷分散プログラム)をSLB20が実行することで実現される。
先ず、ステップS2701では、受信したメッセージ(図27中「Msg」と表記)はクライアント10からのものか否か判定する。そのメッセージをクライアント10から受信した場合、判定はYesとなってステップS2702に移行する。クライアント10以外から受信したメッセージであった場合には、判定はNoとなってステップS2706に移行する。
ステップS2702では、メッセージから抽出されたセッションIDをキーに、バッファ対象IDテーブル252を検索する。続くステップS2703では、バッファ対象IDテーブル252の検索にヒットしないか否か判定する。メッセージにセッションIDが格納されていない、或いは格納されたセッションIDがバッファ対象IDテーブル252に登録されていない場合、判定はYesとなってステップS2704に移行する。そのセッションIDがバッファ対象IDテーブル252に登録されていた場合には、判定はNoとなってステップS2706に移行する。
ステップS2704では、メッセージ中のセッションIDをキーに、一意性保証DB201、及び対応するプロトコル/メッセージ別一意性保証テーブル202を参照して、メッセージを転送すべき振分対象サーバ30のアドレスを抽出し、その振分対象サーバ30に送信する。転送先とすべき振分対象サーバ30のアドレスを抽出できなかった場合には、ラウンドロビン方式等により自律的に転送先を選択し転送する。そのようにしてメッセージを転送した後、一連の処理を終了する。
ステップS2705では、キューイング部251にメッセージを格納する。その格納を行った後、一連の処理を終了する。
ステップS2706では、受信したメッセージはバッファ開始通知か否か判定する。そのバッファ開始通知を受信した場合、判定はYesとなってステップS2707に移行する。バッファ開始通知以外のメッセージを一意性保証情報設定管理装置40から受信した場合には、判定はNoとなってステップS2709に移行する。
ステップS2707では、バッファ開始通知から抽出したセッションIDと開始時刻を格納したレコードをバッファ対象IDテーブル252に登録する。開始時刻としては現在時刻を格納する。次のステップS2708では、バッファ開始応答を一意性保証情報設定管理装置40に送信する。その後、一連の処理を終了する。
ステップS2709では、受信したメッセージはバッファ削除通知か否か判定する。そのバッファ削除通知を受信した場合、判定はYesとなってステップS2710に移行する。バッファ削除通知以外のメッセージ、つまりバッファ転送通知を一意性保証情報設定管理装置40から受信した場合には、判定はNoとなってステップS2713に移行する。
ステップS2710では、バッファ削除通知から抽出したセッションIDを格納したエントリをバッファ対象IDテーブル252から削除すると共に、そのセッションIDを有する一意性保証情報を一意性保証DB201、或いはプロトコル/メッセージ別一意性保証テーブル202から削除する。続くステップS2711では、そのセッションIDをキーにキューイング部251を参照し、そのセッションIDを格納したメッセージのリストを取得する。そのリストにメッセージが存在していれば、つまりエラーとなるタイミングでクライアント10から送信されたメッセージがキューイング部251に存在していれば、その旨を通知するためのメッセージをサーバ発メッセージ送信部(図27中「エラー通知部」と表記)28に転送する。その次に移行するステップS2712では、サーバ発メッセージ送信部28に転送したメッセージをクライアント10に送信させる。その後、一連の処理を終了する。
ステップS2713では、バッファ転送通知から抽出したセッションIDを格納したエントリをバッファ対象IDテーブル252から削除する。続くステップS2714では、そのセッションIDをキーにキューイング部251を参照し、そのセッションIDを格納したメッセージのリストを取得する。そのリストにメッセージが存在していれば、つまり転送すべきメッセージがキューイング部251に存在していれば、そのメッセージを全て転送すべき振分対象サーバ30に転送する。その転送を行った後、一連の処理を終了する。
第4の実施形態では、振分対象サーバ30、一意性保証情報設定管理装置40、及びSLB20は上記のような処理を実行する。それにより、図23及び図24に示す期間DT分、クライアント10からのメッセージの送信時間が増大したとしても、その増大によってタイムアウトとなるのを回避することができる。
図19に示すコンピュータは、SLB20及び振分対象サーバ30として用いることができる。そのコンピュータをSLB20或いは振分対象サーバ30として用いる場合、一意性保証情報設定管理装置40と同様に、SLB20を実現させる負荷分散プログラム、或いは振分対象サーバ30の複数プロトコル連携部33を実現させるアプリケーションは、外部記憶装置65、若しくは記録媒体70に記録されているか、或いは通信ネットワークを介してネットワーク接続67により取得される。そのようにして用意されるプログラムをメモリ62に読み出してCPU61が実行することにより、SLB20、或いは振分対象サーバ30(の複数プロトコル連携部33)は実現される。
なお、第4の実施形態では、クライアント10から送信されたメッセージを監視する監視期間は、振分対象サーバ30が削除予告通知を送信してからバッファ開始通知をSLB20が受信するまでの期間DTとしているが、その監視期間は期間DTに限定されるものではない。削除予告したセッションを実際に削除するまでの範囲内で監視期間は変更可能である。
例えばセッションの削除が通知されるまでの間に、クライアント10から受信したメッセージを振分対象サーバ30にSLB20に転送させる場合には、期間DTをより長くすることができる。その場合、SLB20はクライアント10からのメッセージを監視する役割を担っている形となる。
また、キューイング部251を利用したメッセージの保存は、第4の実施形態ではバッファ開始通知の受信により、SLB20は無条件に行うようになっているが、無条件に行わないようにしても良い。メッセージの保存を行うべきか否か判定して、メッセージの保存を行うようにしても良い。その判定は、振分対象サーバ30(複数プロトコル連携部33)が行い、その判定結果を併せて通知するようにしても良いが、一意性保証情報設定管理装置40、或いはSLB20にその判定を行わせるようにしても良い。
バッファ開始通知の受信によりSLB20にメッセージを保存し続けるのは、資源を有効利用するうえで望ましくない。このことから、削除予告通知を送信した振分対象サーバ30から削除完了通知、或いは削除中止通知を一意性保証情報設定管理装置40が受信されない状況に対応できるようにしても良い。その対応は、SLB制御メッセージ処理部451に行わせることが考えられる。
SLB制御メッセージ処理部451に対応させる場合、例えば図28に示す様なタイマー管理テーブル461をSLB制御メッセージ処理部451に管理させる。そのタイマー管理テーブル461には、受信した削除予告通知毎に、セッションID、起動時刻、及び生成イベントを格納したレコードを登録する。起動時刻は、削除予告通知を受信してから一定時間、経過した後の時刻である。生成イベントは、その起動時刻となるまでの間に、対応する削除完了通知、或いは削除中止通知を受信できなかった場合に生成すべきイベントを示している。その生成イベントとして表記の「削除中止通知」は、削除中止通知を振分対象サーバ30から受信したイベントを生成することを示している。それにより、バッファ転送通知をSLB20に送信することを示している。このようなタイマー管理テーブル461を用意し、削除完了通知、或いは削除中止通知が振分対象サーバ30から受信できなかった場合に対応することにより、SLB20で不要なメッセージを保存することによる資源の浪費を抑えることができる。削除完了通知、或いは削除中止通知が振分対象サーバ30から受信できた場合には、その通知に対応するレコードをタイマー管理テーブル461から削除すれば良い。生成イベントとして削除中止通知を想定しているのは、クライアント10に対し、エラーの通知を最小限に抑えるのが望ましいと云えるからである。資源の浪費を単に抑えるのであれば、生成イベントは削除完了通知であっても良い。
上記タイマー管理テーブル461を用いた対応は、SLB20で行わせても良い。これは、バッファ開始通知を受信した後、バッファ転送通知、或いはバッファ削除通知を一意性保証情報設定管理装置40からSLB20が受信できない状況も考えられるからである。生成イベントを生成する条件としては、削除予告通知が送信されてから経過した時間の他に、保存されたメッセージの数、そのデータ量(或いは保存したメッセージ全体のデータ量)であっても良い。複数の条件を設定し、何れかの条件が満たされた場合に、生成イベントを生成するようにしても良い。
また、第4の実施形態では、削除予告をするセッションは複数の通信プロトコル間の連携に対応したものであるが、一つの通信プロトコルにのみ対応したものであっても良い。このことから、クライアント10のユーザにサービスを提供するサービス提供システムは、一つ以上のSLB20、及び複数の振分対象サーバ30を備えた構成であっても良い。つまり一意性保証情報設定管理装置40がない構成であっても良い。
以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
(付記1)
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させる一意性保証情報設定管理装置として用いられるコンピュータに、
前記端末装置から第1の通信プロトコルにより前記サービスの提供が要求された場合に、該要求により前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されたセッションを識別するための識別情報を取得する識別情報取得機能と、
前記識別情報取得機能により取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第2の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定機能と、
を実現させるための一意性保証情報設定管理プログラム。
(付記2)
前記保証情報設定機能は、前記一意性保証情報の設定完了が前記負荷分散装置から通知された場合、該一意性保証情報の生成に用いた識別情報を取得したサーバに該設定完了を通知する、
ことを特徴とする付記1記載の一意性保証情報設定管理プログラム。
(付記3)
前記識別情報取得機能は、前記識別情報の他に、前記第1の通信プロトコルを示すプロトコル情報を取得し、
前記保証情報設定機能は、前記プロトコル情報を基に、前記一意性保証情報を設定する第2のプロトコルを選択する、
ことを特徴とする付記1記載の一意性保証情報設定管理プログラム。
(付記4)
前記コンピュータに、
前記サーバからセッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知を前記負荷分散装置に送信する開始通知送信機能、
を更に実現させることを特徴とする付記1記載の一意性保証情報設定管理プログラム。
(付記5)
前記コンピュータに、
前記サーバから予告された前記セッションの削除が通知された場合に、保存された前記対応する要求を転送することなく削除させるバッファ削除通知の送信により、該セッションの削除を前記負荷分散装置に通知し、該サーバから該セッションの削除の中止が通知された場合に、該保存された該対応する要求を転送させるバッファ転送通知の送信により、該セッションの削除の中止を該負荷分散装置に通知する転送管理機能、
を更に実現させることを特徴とする付記4記載の一意性保証情報設定管理プログラム。
(付記6)
前記コンピュータに、
前記開始通知送信機能により前記バッファ開始通知を送信した後、予め定めた条件が満たされた場合に、該バッファ開始通知により保存された前記対応する要求を転送させるためのバッファ転送通知を前記負荷分散装置に送信する転送通知送信機能、
を更に実現させることを特徴とする付記4、または5記載の一意性保証情報設定管理プログラム。
(付記7)
前記転送通知送信機能は、前記サーバからセッションの削除が予告された後、一定時間が経過するまでの間に該サーバから該セッションの削除、及び該セッションの削除の中止のうちの一方が通知されなかった場合に、前記条件が満たされたと判定する、
ことを特徴とする付記6記載の一意性保証情報設定管理プログラム。
(付記8)
複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させる一意性保証情報設定管理装置として用いられるコンピュータに、
前記負荷分散装置の選択によって前記セッションを生成したサーバから該セッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知を該負荷分散装置に送信する開始通知送信機能と、
前記開始通知送信機能により前記バッファ開始通知を送信した後、予め定めた条件が満たされた場合に、該バッファ開始通知により保存された前記対応する要求を転送させるためのバッファ転送通知を前記負荷分散装置に送信する転送通知送信機能と、
を実現させるための一意性保証情報設定管理プログラム。
(付記9)
複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択し、該端末装置からの関連する要求を同じサーバに振り分ける負荷分散装置として用いられるコンピュータに、
前記選択によって前記サーバが生成したセッションの削除が該サーバから予告された場合に、前記端末装置から受信される要求のなかで該セッションに対応する要求を転送せずに記憶装置に保存するバッファ機能と、
前記バッファ機能により前記対応する要求の保存を開始した後、予め定めた条件が満たされた場合に、前記記憶装置に保存した該対応する要求を前記サーバに転送させる転送制御機能と、
を実現させるための負荷分散プログラム。
(付記10)
前記転送制御機能は、前記サーバからセッションの削除が予告された後、一定時間が経過するまでの間に該サーバから該セッションの削除、及び該セッションの削除の中止のうちの一方が通知されなかった場合に、前記条件が満たされたと判定する、
ことを特徴とする付記9記載の負荷分散プログラム。
(付記11)
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを負荷分散装置に選択させる場合に、複数の通信プロトコル間の連携に対応した一意性保証を実現させる方法であって、
前記端末装置から第1の通信プロトコルを用いた前記サービスの提供の要求により、前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されるセッションを識別するための識別情報を取得する識別情報取得工程と、
前記識別情報取得工程により取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第2の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定工程と、
前記端末装置から前記第2の通信プロトコルを用いた前記サービスの提供が要求された場合に、前記保証情報設定工程により設定された前記一意性保証情報を前記負荷分散装置に参照させて、該サービスを提供させるサーバを前記複数のサーバのなかから選択させる振分工程と、
を含むことを特徴とする一意性保証実現方法。
(付記12)
前記保証情報設定工程では、前記負荷分散装置に設定する一意性保証情報の生成に用いた識別情報を取得したサーバに対し、前記第1の通信プロトコルを用いた要求に対する応答を送信するタイミングを制御する、
ことを特徴とする付記11記載の一意性保証実現方法。
(付記13)
複数の通信プロトコルでそれぞれサービスを提供可能な複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置に対し、該端末装置からの関連する要求を同じサーバに振り分ける一意性保証を実現させるための一意性保証情報の設定を管理する一意性保証情報設定管理装置において、
前記端末装置から第1の通信プロトコルにより前記サービスの提供が要求された場合に、該要求により前記負荷分散装置が前記複数のサーバのなかから選択したサーバ内で生成されたセッションを識別するための識別情報を取得する識別情報取得手段と、
前記識別情報取得手段が取得した識別情報と該識別情報に対応するセッションを生成したサーバとの対応関係を第2の通信プロトコルによるサービスで前記一意性保証用の一意性保証情報として前記負荷分散装置に設定する保証情報設定手段と、
を具備することを特徴とする一意性保証情報設定管理装置。
(付記14)
負荷分散装置により、端末装置の要求の振分先として選択されるサーバとして用いられるコンピュータに、
前記端末装置の要求が振り分けられたことにより生成したセッションを削除する場合に、該削除を前記負荷分散装置に予告する削除予告機能と、
前記削除予告機能により予告を行ってから前記セッションを実際に削除すべきタイミングとなるまでの間に、前記端末装置から該セッションに対応する要求が送信されたか否か監視する監視機能と、
前記監視機能により前記対応する要求の送信が確認された場合に、前記予告を行った前記セッションの削除を中止させる削除管理機能と、
を実現させるためのアプリケーション・プログラム。
(付記15)
前記サーバは複数の通信プロトコルを連携させたサービスを提供可能であり、該複数の通信プロトコル間の連携に対応した一意性保証を実現させるための一意性保証情報の前記負荷分散装置への設定を管理する一意性保証情報管理装置が存在する場合、前記削除予告機能は、該一意性保証情報設定管理装置に前記予告を行うことにより、該一意性保証情報設定管理装置を介して該予告を該負荷分散装置に通知させる、
ことを特徴とする付記14記載のアプリケーション・プログラム。
(付記16)
前記削除管理機能は、前記監視機能により前記対応する要求の送信が確認されなかった場合に、前記予告を行った前記セッションを削除すると共に、前記一意性保証情報設定管理装置を介して、該セッションに対応する一意性保証情報を前記負荷分散装置に削除させる、
ことを特徴とする付記15記載のアプリケーション・プログラム。
(付記17)
複数のサーバのなかから端末装置が要求するサービスを提供させるサーバを負荷分散装置に選択させる場合に、該負荷分散装置が選択のサーバに該サービスの提供用に生成されたセッションを管理するための方法であって、
前記端末装置の要求が振り分けられたことにより生成したセッションの削除を前記サーバから前記負荷分散装置に予告する削除予告工程と、
前記削除予告工程により予告を行ってから前記セッションを実際に削除すべきタイミングとなるまでの間に、前記端末装置から該セッションに対応する要求が送信されたか否か監視する監視工程と、
前記監視工程で前記対応する要求の送信が確認された場合に、前記予告を行った前記セッションの削除を前記サーバに中止させる削除管理工程と、
を含むことを特徴とするセッション管理方法。
(付記18)
端末装置が要求するサービスを提供するサービス提供システムにおいて、
前記サービス提供システムは、前記サービスを提供可能な複数のサーバ、及び該複数のサーバのなかから前記端末装置が要求するサービスを提供させるサーバを選択する負荷分散装置、を備え、
前記複数のサーバのうちの少なくとも一つは、
前記端末装置の要求が振り分けられたことにより生成したセッションの削除を前記負荷分散装置に予告する削除予告手段と、
前記削除予告手段による予告を行ってから前記セッションを実際に削除すべきタイミングとなるまでの間に、前記端末装置から該セッションに対応する要求が送信されたか否か監視する監視手段と、
前記監視手段により前記対応する要求の送信が確認された場合に、前記予告を行った前記セッションの削除を中止させる削除管理手段と、
前記削除管理手段による前記セッションの削除、及び該セッションの削除の中止をしたか否かを前記負荷分散装置に通知するための通知手段と、を備え、
前記負荷分散装置は、
前記端末装置からの要求を格納する要求格納手段と、
前記サーバと該サーバで生成されたセッションを識別するための識別情報の対応関係を示す一意性保証情報を格納する保証情報格納手段と、
前記削除が予告されたセッションに対応する要求を前記端末装置から受信した場合に、該受信した要求を前記要求格納手段に格納するバッファ制御手段と、
前記サーバから前記セッションの削除が通知された場合に、前記バッファ制御手段により前記要求格納手段に格納された前記対応する要求を転送することなく、該セッションに対応する一意性保証情報を前記保証情報格納手段から削除し、該サーバから該セッションの削除の中止が通知された場合に、該保証情報格納手段に格納されている前記一意性保証情報を参照して、該要求格納手段に格納された該対応する要求を転送する転送制御手段と、を備えている、
ことを特徴とするサービス提供システム。
(付記19)
前記サービス提供システムは、複数の通信プロトコルを連携させたサービスに対応した一意性保証を実現させるための一意性保証情報の前記負荷分散装置への設定を管理する一意性保証情報管理装置、を備え、
前記一意性保証情報設定管理装置は、
前記サーバから前記セッションの削除が予告された場合に、前記端末装置から送信される要求のなかで該セッションに対応する要求を転送させずに保存させるためのバッファ開始通知の送信により、該予告を該負荷分散装置に通知する開始通知送信手段と、
前記サーバから前記セッションの削除が通知された場合に、該セッションに対応する要求を転送することなく前記要求格納手段から削除させるバッファ削除通知の送信により、該セッションの削除を前記負荷分散装置に通知し、該サーバから該セッションの削除の中止が通知された場合に、該要求格納手段に格納されている前記対応する要求を転送させるバッファ転送通知の送信により、該セッションの削除の中止を該負荷分散装置に通知する転送管理手段と、を備えている、
ことを特徴とする付記18記載のサービス提供システム。