(57)【特許請求の範囲】
【請求項１】
複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からのメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、
前記複数のノードサーバのそれぞれは、
同一ユーザ端末の一連のデータ通信であるセッションを識別するセッションＩＤと前記セッションＩＤで示されるセッションに属するメッセージの処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、
前記複数のロードバランサのうちいずれか１つのロードバランサからセッションＩＤを含むメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージに含まれる前記セッションＩＤのセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、
前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記メッセージを送信したロードバランサとは異なる他のロードバランサに、前記セッションＩＤと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備えるクラスタシステム。
【請求項２】
前記ノード振替部は、前記メッセージを送信したロードバランサ以外のロードバランサから前記ノードサーバに対して前記セッションに関するアクセスがあった後に、前記アクセスがあったロードバランサに前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信する請求項１に記載のクラスタシステム。
【請求項３】
異なる通信プロトコルでデータ通信を行う複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする、通信プロトコルの異なる複数のユーザ端末からのメッセージの処理することにより、通信プロトコルの異なる前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、
前記複数のノードサーバのそれぞれは、
通信プロトコルの異なるユーザ端末同士におけるそれぞれの通信プロトコルのセッションを含む一連のデータ通信を識別する統合セッションＩＤ及びそれぞれの通信プロトコルのセッションＩＤと前記統合セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、
前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージが属するセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、
前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記メッセージを送信したロードバランサとは通信プロトコルが異なる他のロードバランサに、前記統合セッションＩＤまたは前記他のロードバランサの通信プロトコルのセッションＩＤと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備えるクラスタシステム。
【請求項４】
前記複数のロードバランサは、ＨＴＴＰプロトコルでデータ通信を行うロードバランサと、ＳＩＰプロトコルでデータ通信を行うロードバランサとを含む請求項３に記載のクラスタシステム。
【請求項５】
請求項１に記載のクラスタシステムに接続された前記ロードバランサであって、
セッションＩＤと、当該セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報を記憶する記憶部と、
前記複数のユーザ端末からのメッセージを受信して、前記メッセージからセッションＩＤを取得し、前記セッションＩＤおよび前記セッション担当ノード情報に基づいて決定されるノードサーバへ前記メッセージを割り当てる負荷分散部と、
前記ノードサーバが備える前記ノード振替部から前記セッションを示すデータと、前記代替ノードサーバを示すデータが送信された場合に、前記送信されたデータに基づいて、前記記憶部に記憶された担当セッションノード情報を更新する更新部とを備えるロードバランサ。
【請求項６】
複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバによって行われるノード振替方法であって、
前記複数のノードサーバのそれぞれが、同一ユーザ端末の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する工程と、
前記複数のノードサーバのいずれか１つのノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージが属する記セッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認工程と、
前記ノードサーバが、前記ノード確認工程で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記メッセージを送信したロードバランサとは異なる他のロードバランサに、前記セッションＩＤと、前記代替ノードサーバを示すデータを送信するノード振替工程とを有するノード振替方法。
【請求項７】
複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバに処理を実行させるノード振替プログラムであって、
前記ノードサーバの記憶部に、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する処理と、
前記ノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージが属するセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認処理と、
前記ノード確認処理で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記メッセージを送信したロードバランサとは異なる他のロードバランサに、前記セッションＩＤと、前記代替ノードサーバを示すデータとを送信するノード振替処理と前記ノードサーバに実行させるノード振替プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ロードバランサによって分散されたユーザ端末からの要求を処理する複数のノードサーバを有するクラスタシステムに関し、特に、通信プロトコルが異なる複数のロードバランサに接続されたクラスタシステム、ロードバランサ、クラスタシステムで用いられるノード振替方法およびノード振替プログラムに関する。
【背景技術】
【０００２】
経済、社会の基盤を構成するＩＴ（Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ）システムには、安定性、堅ろう性および経済性が求められる。ＩＴシステムにおいて高い安定性を保つための方法として、複数セットのシステムを用意しておき、複数セットのシステムのうち、いずれか１つにトラブルが発生した時やメンテナンスを行う時に、それらをすばやく切り替える方法がある。その方法の１つがクラスタリングである。
【０００３】
図１４は、クラスタリングを利用したＷＷＷシステムの構成の概略を示す図である。図１４に示すＷＷＷシステム９０は、互いに接続されたノードサーバ９１ａ、９１ｂ、９１ｃを備える。ノードサーバ９１ａ、９１ｂ、９１ｃは、それぞれ、記憶部９２ａ、９２ｂ、９２ｃを有する。ノードサーバ９１ａ、９１ｂ、９１ｃには、それぞれＨＴＴＰアプリケーションが実装されている。ＷＷＷシステム９０は、ロードバランサ９３に接続されている。ロードバランサ９３は、ユーザ端末９４ａ、９４ｂからのＨＴＴＰメッセージを受け付けて、ＷＷＷシステム９０の各ノードサーバに振り分ける。
【０００４】
例えば、ロードバランサ９３が、ユーザ端末９４ａからのＨＴＴＰメッセージを、ノードサーバ９１ａに割り当てると、ユーザ端末９４ａが備えるブラウザとノードサーバ９１ａが備えるＨＴＴＰアプリケーションとの間でＨＴＴＰデータ通信が行われる。
【０００５】
ＨＴＴＰデータ通信において、ユーザ端末９４ａにおいてユーザが１つのＷｅｂサイト内で行う操作による一連のデータ通信はセッションという処理単位で扱われる。例えば、電子商取引サイトでは、ログインからログアウトまでを１セッションとして、ユーザ端末９４ａのブラウザおよびノードサーバ９１ａのＨＴＴＰアプリケーションで処理が行われる。セッションの固有の情報は、セッションデータとしてノードサーバ９１ａの記憶部９２ａに記憶される。
【０００６】
ここで、ノードサーバ９１ａとユーザ端末９４ａとのデータ通信におけるセッションデータは、ノードサーバ９１ｂ、９１ｃの記憶部９２ｂ、９２ｃにも複製される。ノードサーバ９１ａの記憶部９２ａのセッションデータが更新されると、自動的にノードサーバ９１ｂ、９１ｃの記憶部９２ｂ、９２ｃのセッションデータも更新される仕組みになっている。
【０００７】
これにより、１つのセッションが終了しないうちに、ノードサーバ９１ａが、障害により機能しなくなり、そのセッションが中断されても、ノードサーバ９１ｂまたはノードサーバ９１ｃが、記憶部９２ｂ、９２ｃのセッションデータを用いて、そのセッションを引き継ぐことができる。このようなセッションデータ複製処理およびロードバランサによる負荷分散処理との組合せによってクラスタリングが実現される。
【０００８】
近年、複数のプロトコルによる通信を連携するサービスを提供するシステムが出現している。例えば、ＳＩＰサーバとＷＷＷサーバを連携する機能を持つＳＩＰ／ＨＴＴＰアプリケーションサーバがある。これは、例えば、ＨＴＴＰプロトコルでユーザ端末から送られてきたメッセージで指定される切断・保留・転送などを実現するＳＩＰプロトコルメッセージを作成して電話機能を持つ端末へ送信する機能を持っている。これにより、ユーザは、例えば、Ｗｅｂページから電話への発呼、Ｗｅｂページから通話の保留、転送、切断操作等を行うことが可能になる。
【０００９】
図１５は、ＳＩＰサーバとＷＷＷサーバを連携する機能を持つＳＩＰ／ＨＴＴＰ連携システム９９におけるクラスタリング構成の概略を示す図である。図１５に示す構成では、２つのロードバランサ９３、９７が設けられている。ロードバランサ９３は、ＨＴＴＰプロトコルによる通信を行い、ロードバランサ９７は、ＳＩＰプロトコルによる通信を行う。ノードサーバ９５ａ、９５ｂ、９５ｃには、ＳＩＰプロトコルメッセージとＨＴＴＰプロトコルメッセージを連携する機能を持つＳＩＰ／ＨＴＴＰアプリケーションが実装されている。
【００１０】
図１５に示すＳＩＰ／ＨＴＴＰ連携システム９９では、例えば、ロードバランサ９３が、ユーザ端末９４ａからＨＴＴＰプロトコルに従ったメッセージを受け取り、ノードサーバ９５ａ、９５ｂ、９５ｃのいずれかに割り当てる。例えば、ＨＴＴＰプロトコルメッセージが、ノードサーバ９５ａに割り当てられると、ノードサーバ９５ａのＳＩＰ／ＨＴＴＰアプリケーションは、受信したＨＴＴＰメッセージに対応する呼処理を実行するＳＩＰメッセージを作成し、ロードバランサ９７に転送する。ロードバランサ９７は、ＳＩＰメッセージを、例えば、送信先のユーザ端末９８ａに転送する。このようにして、ユーザ端末９４ａとユーザ端末９８ａとの間でのデータ通信が行われる。
【００１１】
各ユーザ間のセッションにおける固有の情報は、各セッションデータとしてノードサーバ９５ａ、９５ｂ、９５ｃの記憶部９６ａ、９６ｂ、９６ｃに複製して記憶される。これにより、ノードサーバ９５ａ、９５ｂ、９５ｃのうちいずれかが、セッション処理終了前に停止しても、そのセッションを他のノードサーバで引き継ぐことができる。
【００１２】
図１５に示すように、ロードバランサが複数存在する場合は、セッション複製に伴うオーバーヘッドを最小にするため、同一セッションは、同一のノードサーバで処理されることが好ましい。すなわち、効率的な処理を行うために、複数のロードバランサからの同一のセッションに関するメッセージは、同一のノードサーバに割り当てられることが好ましい。さらに、ノードサーバ９５ａ、９５ｂ、９５ｃいずれかに障害が起きた場合でも、複数のロードバランサが、同一のノードサーバで、同一セッションが処理されるように動作する必要がある。
【００１３】
複数のロードバランサ間で情報をやり取りする例は、いくつか提案されている（例えば、特許文献１および特許文献２参照）。
【特許文献１】特開２００４−１９９６７８号公報
【特許文献２】特開２００３−１７４４７３号公報
【発明の開示】
【発明が解決しようとする課題】
【００１４】
しかしながら、上記特許文献１および２の例では、複数のロードバランサが、関連する複数のセッションに属するメッセージを同一のクラスタノードに分配可能とするための方法は開示されていない。
【００１５】
本発明は、複数のロードバランサを介するデータ通信において、ノードサーバが正常に動作しなくなった場合にも複数のロードバランサが、同一のセッションまたは関連する複数のセッションに属するメッセージを同一のクラスタノードに分配することを可能とし、効率よく複数のロードバランサからのメッセージを処理することができるクラスタシステム、ロードバランサ、ノード振替方法、ノード振替プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１６】
本発明におけるクラスタシステムは、複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からのメッセージを処理することにより、前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、前記複数のノードサーバのそれぞれは、同一ユーザ端末の一連のデータ通信であるセッションを識別するセッションＩＤと前記セッションＩＤで示されるセッションに属するメッセージの処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、前記複数のロードバランサのうちいずれか１つのロードバランサからセッションＩＤを含むメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージに含まれる前記セッションＩＤのセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションを示すデータと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備える。
【００１７】
本発明におけるノード振替方法は、複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバによって行われるノード振替方法であって、前記複数のノードサーバのそれぞれが、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する工程と、前記複数のノードサーバのいずれか１つのノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージの前記セッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認工程と、前記ノードサーバが、前記ノード確認工程で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータを送信するノード振替工程とを有する。
【００１８】
本発明におけるノード振替プログラムは、複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバに処理を実行させるノード振替プログラムであって、前記ノードサーバの記憶部に、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する処理と、前記ノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージの前記セッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認処理と、前記ノード確認処理で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信するノード振替処理と前記ノードサーバに実行させる。
【発明の効果】
【００１９】
本発明によれば、複数のロードバランサを介するデータ通信において、ノードサーバが正常に動作しなくなった場合にも複数のロードバランサが、同一のセッションまたは関連する複数のセッションに属するメッセージを同一のクラスタノードに分配することを可能とし、効率よくメッセージを処理することができるクラスタシステム、ロードバランサ、ノード振替方法、ノード振替プログラムを提供することができる。
【発明を実施するための最良の形態】
【００２０】
本発明におけるクラスタシステムは、複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からのメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、前記複数のノードサーバのそれぞれは、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと前記セッションＩＤで示されるセッションに属するメッセージの処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、前記複数のロードバランサのうちいずれか１つのロードバランサからセッションＩＤを含むメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージに含まれる前記セッションＩＤのセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションを示すデータと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備える。
【００２１】
ロードバランサは、ユーザ端末からのメッセージを一元的に管理し、複数のノードサーバにメッセージを転送する負荷分散サーバである。
【００２２】
セッションは、複数のロードバランサそれぞれにアクセスする複数のユーザ端末間でのデータ通信において、同一ユーザ端末の一連のデータ通信における処理の集合である。
【００２３】
前記記憶部には、各セッションを識別するためのセッションＩＤと、各セッションを担当する担当ノードサーバとを対応付けるセッション担当ノード情報が記憶されている。そのため、前記ノード確認部は、ロードバランサから受け取ったメッセージのセッションの担当ノードサーバを、前記セッション担当ノード情報により特定することができる。さらに、前記ノード確認部は、メッセージのセッションの担当ノードサーバが正常に動作しているか否かを、セッション担当ノード情報に基づいて、判断することができる。その結果、例えば、障害の発生等により、担当ノードサーバが正常に動作していない場合、前記ノード確認部によって、担当ノードサーバの異常が検出される。すなわち、前記セッションを担当するノードサーバを振り替える必要があることが検出される。
【００２４】
ノード振替部は、正常に動作していない担当ノードサーバの替わりに機能する代替ノードサーバと、代替ノードサーバが担当するセッションを示すデータを前記複数のロードバランサに送信するので、前記データを受信したロードバランサは、セッションを担当するノードサーバが変更された旨の情報を得ることができる。すなわち、複数のロードバランサへノードサーバの振替が通知される。そのため、複数のノードサーバのうち１つが正常に動作しなくなって、その機能が代替ノードサーバに切り替えられた場合であっても、複数のロードバランサは切り替え後の代替ノードサーバにアクセスできる。その結果、複数のロードバランサを介するデータ通信において、複数のノードサーバの一部が正常に動作しなくなった場合にも、複数のロードバランサが、同一のセッションまたは関連する複数のセッションに属するメッセージを、同一のノードサーバに分配することが可能となる。すなわち、複数のノードサーバの一部が正常に動作しなくなった場合にも効率よく複数のロードバランサからメッセージを処理することができるクラスタシステムが得られる。  本発明におけるクラスタシステムにおいて、前記ノード振替部は、前記メッセージを送信したロードバランサ以外のロードバランサから前記ノードサーバに対して前記セッションに関するアクセスがあった後に、前記アクセスがあったロードバランサに前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信することが好ましい。
【００２５】
前記ノードサーバに前記セッションに関するアクセスを行うロードバランサは、そのセッションを扱うロードバランサである。したがって、前記ノード振替部は、そのセッションを扱うロードバランサに、そのアクセスのタイミングに合わせて、前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信することができる。その結果、前記セッションを扱うロードバランサに対して効率よく前記セッションＩＤと前記データとを送信することができる。
【００２６】
本発明におけるクラスタシステムは、異なる通信プロトコルでデータ通信を行う複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする、通信プロトコルの異なる複数のユーザ端末からのメッセージの処理することにより、通信プロトコルの異なる前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、前記複数のノードサーバのそれぞれは、通信プロトコルの異なるユーザ端末同士の一連のデータ通信であるセッションを識別するセッションＩＤと前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたセッションＩＤを含むメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージに含まれる前記セッションＩＤのセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記メッセージを送信したロードバランサとは通信プロトコルが異なる他のロードバランサに、前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備える。
【００２７】
ノード振替部は、前記代替ノードサーバと、代替ノードサーバが担当するセッションのセッションＩＤとを示すデータを、前記メッセージを送信したロードバランサとは通信プロトコルが異なる他のロードバランサに送信するので、セッションを担当するノードサーバが代替ノードサーバに振り替えられた場合、異なるプロトコルのロードバランサへ代替ノードサーバを通知することができる。その結果、通信プロトコルの異なる複数のロードバランサを介するデータ通信において、複数のノードサーバの一部が正常に動作しなくなった場合にも、効率よく通信プロトコルの異なる複数のロードバランサからのメッセージを処理することができるクラスタシステムが得られる。
【００２８】
本発明におけるクラスタシステムにおいて、前記複数のロードバランサは、ＨＴＴＰプロトコルでデータ通信を行うロードバランサと、ＳＩＰプロトコルでデータ通信を行うロードバランサとを含む態様とすることができる。
【００２９】
本発明におけるロードバランサは、本発明におけるクラスタシステムに接続された前記ロードバランサであって、セッションＩＤと、当該セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報を記憶する記憶部と、前記複数のユーザ端末からのメッセージを受信して、前記メッセージからセッションＩＤを取得し、前記セッションＩＤおよび前記セッション担当ノード情報に基づいて決定されるノードサーバへ前記メッセージを割り当てる負荷分散部と、前記ノードサーバが備える前記ノード振替部から前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータが送信された場合に、前記送信されたデータに基づいて、前記記憶部に記憶された担当セッションノード情報を更新する更新部とを備える。
【００３０】
前記負荷分散部は、前記セッション担当ノード情報に基づいてメッセージを割り当てるノードサーバを決定するので、同一のセッションのメッセージは、同一のノードサーバに割り当てられる。また、前記記憶部の前記セッション担当ノード情報は、前記ノードサーバが備える前記ノード振替部からの情報に基づいて前記更新部によって更新されるので、セッションを担当する担当ノードサーバが正常に動作しなくなった場合でも、前記クラスタシステムの前記セッションを担当する前記サーバノードを担当する代替ノードサーバを示す情報で前記セッション担当ノード情報が更新される。そのため、前記ロードバランサは、前記クラスタシステムの何れかのノードサーバが正常に動作しなくなった場合でも、代替ノードサーバにアクセスすることができ、同一のセッションを同一のノードサーバに割り当てることができる。
【００３１】
本発明におけるノード振替方法は、複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバによって行われるノード振替方法であって、前記複数のノードサーバのそれぞれが、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する工程と、前記複数のノードサーバのいずれか１つのノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージの前記セッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認工程と、前記ノードサーバが、前記ノード確認工程で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータを送信するノード振替工程とを有する。
【００３２】
本発明におけるノード振替プログラムは、複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバに処理を実行させるノード振替プログラムであって、前記ノードサーバの記憶部に、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する処理と、前記ノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージの前記セッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認処理と、前記ノード確認処理で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信するノード振替処理と前記ノードサーバに実行させる。
【００３３】
以下、図面を参照して、本発明の実施の一形態を詳細に説明する。
【００３４】
（実施の形態１）
図１は、本実施形態におけるクラスタシステムの構成を示す機能ブロック図である。図１に示すクラスタシステム１は、ＳＩＰサーバとＷＷＷサーバを連携する機能を持つＳＩＰ／ＨＴＴＰ連携システムをクラスタリングした構成の例である。
【００３５】
この構成では異なるロードバランサとしてＨＴＴＰロードバランサ、ＳＩＰロードバランサそれぞれ１台づつによる構成としたが、それぞれ複数のロードバランサから構成される構成としてもよいし、またＨＴＴＰのみ、ＳＩＰのみのロードバランサから構成される構成としてもよいし、ＨＴＴＰ、ＳＩＰ以外のプロトコルを扱うロードバランサであってもよい。
【００３６】
図１に示すクラスタシステム１は、互いに接続されたノードサーバ２ａ、２ｂ、２ｃを備える。ノードサーバ２ａ、２ｂ、２ｃは、それぞれ、記憶部３ａ、３ｂ、３ｃを有する。記憶部３ａ、３ｂ、３ｃには、セッションデータおよびクラスタ管理情報が記憶されている。
【００３７】
図２は、ノードサーバ２ａの構成の例を示す機能ブロック図である。なお、ノードサーバ２ｂ、２ｃも図２と同様の構成とすることができる。図２に示すように、ノードサーバ２ａは、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１およびクラスタ管理部１０を備える。クラスタ管理部１０には、データ送受信部１３、ノード監視部１５、ノード確認部１７、ノード振替部１９が含まれている。ノードサーバ２ａは、記憶部３ａにアクセス可能となっている。記憶部３ａに記憶されたクラスタ管理情報には、セッション担当ノード情報、ノード生死情報が含まれている。
【００３８】
再び図１を参照して、クラスタシステム１は、ＨＴＴＰロードバランサ５ａおよびＳＩＰロードバランサ５ｂに接続されている。ＨＴＴＰロードバランサ５ａは、ネットワークを介して、複数のユーザ端末７ａ、７ｂに接続されている。ユーザ端末７ａ、７ｂは、例えば、ＨＴＴＰ通信を行うためのＷｅｂブラウザが実装されたコンピュータ等である。ＳＩＰロードバランサ５ｂは、ネットワークを介して、複数のユーザ端末８ａ、８ｂに接続されている。ユーザ端末８ａ、８ｂは、例えば、ＳＩＰ通信を行うための電話機等である。
【００３９】
図３は、ＨＴＴＰロードバランサ５ａの構成の例を示す機能ブロック図である。図３に示すようにＨＴＴＰロードバランサ５ａは、負荷分散部５１および更新部５２を備える。ＨＴＴＰロードバランサ５ａは、記録部６ａにアクセス可能となっている。記憶部６ａには、セッション担当ノード情報が記憶されている。なお、ＳＩＰロードバランサ５ｂも図３に示す構成と同様である。
【００４０】
ノードサーバ２ａ、２ｂ、２ｃ、ＨＴＴＰロードバランサ５ａ、ＳＩＰロードバランサ５ｂは、例えば、パーソナルコンピュータ、サーバ等のコンピュータにより構成される。ノードサーバ２ａ、２ｂ、２ｃ、ＨＴＴＰロードバランサ５ａのＳＩＰ／ＨＴＴＰアプリケーション実行部１１、クラスタ管理部１０、負荷分散部５１、更新部５２の機能は、コンピュータのＣＰＵまたはＭＰＵが所定のプログラムを実行することで実現することができる。また、記録部３ａ、３ｂ、３ｃ、６ａ、６ｂには、コンピュータが備えるハードディスク、半導体メモリ、フレキシブルディスク、ＤＶＤ等を用いることができる。
【００４１】
ＨＴＴＰロードバランサ５ａの負荷分散部５１は、ユーザ端末７ａ、７ｂからのＨＴＴＰプロトコルに基づくメッセージ（以下、ＨＴＴＰメッセージと称する。）を受け付けて、クラスタシステム１の各ノードサーバ２ａ、２ｂ、２ｃに振り分ける。ＨＴＴＰロードバランサ５ａからＨＴＴＰメッセージを受信した各ノードサーバ２ａ、２ｂ、２ｃのＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、例えば、受信したＨＴＴＰメッセージに対応する呼処理を実行するＳＩＰメッセージを作成し、ＳＩＰロードバランサ５ｂを介して、ユーザ端末８ａまたは８ｂに送信する。
【００４２】
ＳＩＰロードバランサ５ｂの負荷分散部は、ユーザ端末８ａ、８ｂからのＳＩＰプロトコルに基づくメッセージ（以下、ＳＩＰメッセージと称する）を受け付けて、クラスタシステム１の各ノードサーバ２ａ、２ｂ、２ｃに振り分ける。ＳＩＰロードバランサ５ｂからＨＴＴＰメッセージを受信した各ノードサーバ２ａ、２ｂ、２ｃのＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、例えば、受信したＳＩＰメッセージに対応するＨＴＴＰセッションに保存した呼状態情報を更新する。なおＨＴＴＰプロトコルの特性上、ＳＩＰメッセージを受信した時点で、更新された前記呼状態情報はユーザ端末７ａ側へ送信されず、次回ＨＴＴＰメッセージに対するレスポンスとして送信される。
【００４３】
これにより、例えば、異なる通信プロトコルのユーザ端末７ａとユーザ端末８ｂとの間でデータ通信が可能になる。ここでは、例えば、ユーザ端末７ａとユーザ端末８ｂとの間の一連のデータ通信はセッションという処理単位で扱われる。セッションは、同一ユーザ端末間の一連のデータ通信処理を表す概念である。以下、本実施形態におけるセッションについて説明する。
【００４４】
（セッションについての説明）
１つのセッションには、例えば、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１で処理されているユーザ端末間のデータ通信において、それらのユーザ端末からされるアクセスの全ての処理が含まれる。例えば、ユーザ端末７ａのＷｅｂブラウザからユーザ端末８ｂへ発呼がされた場合、発呼の時にセッションが始まり、その通話が切断されるとセッションが終了する。この場合、発呼の時から通話が切断されるまでの、ユーザ端末７ａおよびユーザ端末８ｂからのアクセスは、すべて１つのセッションに含まれる。このセッションを統合セッションと呼称する。
【００４５】
また、統合セッションには、ＨＴＴＰセッションおよびＳＩＰセッションを含んでいる。ＨＴＴＰセッションは、ユーザ端末７ａまたは７ｂと各ノードサーバ２ａ、２ｂまたは２ｃとの間の同一ユーザによる一連のデータ通信、つまりＨＴＴＰプロトコルにおける同一ユーザによる一連のデータ通信であり、ＳＩＰセッションは、ユーザ端末８ａまたは８ｂと各ノードサーバ２ａ、２ｂまたは２ｃとの間の同一ユーザによる一連のデータ通信、つまりＳＩＰプロトコルにおける同一ユーザによる一連のデータ通信である。
【００４６】
ＨＴＴＰセッションＩＤは、例えば、ユーザ端末７ａで、Ｗｅｂサイトへの初回アクセス処理が行われた時に生成され、初回アクセス時にノードサーバ２ａへ送信されるＨＴＴＰメッセージに含まれる。例えば、そのＨＴＴＰメッセージをノードサーバ２ａが受信した場合、ノードサーバ２ａは、ＨＴＴＰセッションＩＤと統合セッションＩＤを対にして生成し、その対応関係をテーブルに記録する。  さらに、ノードサーバ２ａが、例えば、受信したＨＴＴＰメッセージに対応する呼処理を実行するＳＩＰメッセージを作成し、ＳＩＰロードバランサ５ｂを介して、ユーザ端末８ａに送信する場合、ＳＩＰセッションＩＤを生成して、統合セッションＩＤと対応づけて記録し、更にそのＳＩＰセッションＩＤをＳＩＰメッセージに含めて送信する。
【００４７】
以降、ノードサーバ２ａとユーザ端末８ａとの一連のデータ通信において、ＳＩＰロードバランサ５ｂを介してやりとりするＳＩＰメッセージには、ＳＩＰセッションＩＤが含まれる。また、ノードサーバ２ａとユーザ端末７ａとの一連のデータ通信において、ＨＴＴＰロードバランサ５ａを介してやりとりするＨＴＴＰメッセージには、ＨＴＴＰセッションＩＤが含まれる。
このようにして、ノードサーバ２ａで生成された統合セッションＩＤは、ＳＩＰセッションＩＤおよびＨＴＴＰセッションＩＤとを関連付ける役割を果たす。ユーザ端末７ａとユーザ端末８ａとの一連のデータ通信が終了するまで、統合セッションＩＤはノードサーバ２ａで保持される。
【００４８】
ノードサーバ２ａ、２ｂ、２ｃで生成された統合セッションＩＤは、例えば、セッションで使用されるセッション情報とともにセッションデータとして、各ノードサーバ２ａ、２ｂ、２ｃの記憶部３ａに記憶される。
【００４９】
図４は、セッションデータの構成の例を表す図である。図４に示す例では、統合セッションＩＤに、ＨＴＴＰセッションＩＤおよびＳＩＰセッションＩＤが対応付けられている。ＨＴＴＰセッションＩＤには、ＨＴＴＰセッションのセッション情報が、ＳＩＰセッションＩＤには、ＳＩＰセッションのセッション情報がそれぞれ対応づけられている。ＨＴＴＰセッションに設定されるセッション情報には、例えば、ユーザ端末７ａ、７ｂで入力された住所、氏名等があり、ＳＩＰセッションのセッション情報には、例えば、通話元電話番号、通話先電話番号等がある。
【００５０】
セッションデータは、例えば、ノードサーバ２ａ、２ｂ、２ｃのうちいずれか１つが、ユーザ端末からの一連のデータ通信の開始を要求するメッセージを受け取った時にＳＩＰ／ＨＴＴＰアプリケーション実行部によって生成される。セッションデータは、複製されて、ノードサーバ２ａ、２ｂ、２ｃそれぞれの記憶部３ａ、３ｂ、３ｃに記憶される。記憶部３ａ、３ｂ、３ｃに記憶されたセッションデータのうち、いずれか１つのセッションデータが更新されると、他のセッションデータも更新される。これにより、記憶部３ａ、３ｂ、３ｃに記憶されたセッションデータは、常に同じ内容を保たれる。
【００５１】
そのため、ノードサーバ２ａ、２ｂ、２ｃのうちいずれか１つが、あるセッションの処理中にセッション終了前に障害等により停止しても、セッションデータが他のノードサーバの記憶部に残されているので、他のノードサーバがそのセッションを引き継ぐことができる。
【００５２】
以上、セッションについて説明した。図１に示すクラスタシステム１においては、同一の統合セッションは、同一のノードサーバで処理される。すなわち、ＨＴＴＰロードバランサ５ａおよびＳＩＰロードバランサ５ｂは、同一の統合セッションに属するＨＴＴＰセッションおよびＳＩＰセッションを、同一のノードサーバに割り当てる。そのため、例えば、ＨＴＴＰロードバランサ５ａおよびＳＩＰロードバランサ５ｂは、ＨＴＴＰ／ＳＩＰセッションＩＤと、そのＨＴＴＰ／ＳＩＰセッションＩＤで示される統合セッションを担当するノードサーバを表すノードＩＤとが対応付けられたセッション担当ノード情報を記憶部６ａおよび６ｂにそれぞれ記憶する。
【００５３】
ＨＴＴＰロードバランサ５ａおよびＳＩＰロードバランサ５ｂに記憶されているセッション担当ノード情報は、どのセッションをどのノードサーバに割り当てるかを示すデータである。図５（ａ）は、ＨＴＴＰロードバランサ５ａの記憶部６ａに記憶されているセッション担当ノード情報の例を示す図である。
【００５４】
図５（ａ）に示す例では、ＨＴＴＰセッションＩＤと、ノードＩＤが対応付けられて記憶されている。ＨＴＴＰロードバランサ５ａの負荷分散部５１は、例えば、ユーザ端末から受け取ったＨＴＴＰメッセージに含まれるＨＴＴＰセッションＩＤと一致するＨＴＴＰセッションＩＤを、記憶部６ａのセッション担当ノード情報から見つけ出し、そのＨＴＴＰセッションＩＤに対応するノードＩＤを取得する。負荷分散部５１は、取得したノードＩＤが示すノードサーバへＨＴＴＰメッセージを送信する。
【００５５】
図５（ｂ）は、ＳＩＰロードバランサ５ｂの記憶部６ｂに記憶されているセッション担当ノード情報の例を示す図である。図５（ｂ）に示す例では、ＳＩＰセッションＩＤと、ノードＩＤが対応付けられて記憶されている。ＳＩＰロードバランサ５ｂの負荷分散部は、ユーザ端末から受け取ったＳＩＰメッセージに含まれるＳＩＰセッションＩＤと一致するＳＩＰセッションＩＤを、記憶部６ｂのセッション担当ノード情報から見つけ出し、そのＳＩＰセッションＩＤに対応するノードＩＤを取得する。ＳＩＰロードバランサ５ｂの負荷分散部は、取得したノードＩＤが示すノードサーバへＳＩＰメッセージを送信する。
【００５６】
次に、図２に示すクラスタ管理部１０について説明する。データ送受信部１３は、各ノードサーバ２ａ、２ｂ、２ｃの記憶部３ａ、３ｂ、３ｃに記憶されたセッションデータおよびクラスタ管理情報のミラーリングを随時実行する。これにより、各ノードサーバ２ａ、２ｂ、２ｃの記憶部３ａ、３ｂ、３ｃに記憶されたデータの内容の同期を取る。すなわち、各ノードサーバ２ａ、２ｂ、２ｃは常に同じ内容のセッションデータおよびクラスタ管理情報を共有することができる。
【００５７】
なお、各ノードサーバ２ａ、２ｂ、２ｃが常に同じ内容のセッションデータおよびクラスタ管理情報を共有するための構成は、上記のデータ内容の同期を取る方法に限られない。例えば、各ノードサーバ２ａ、２ｂ、２ｃが共有する記憶部を別途設ける方法もある。
【００５８】
ノード監視部１５は、他のノードサーバ２ｂ、２ｃと、ノードサーバの機能が正常に動作しているか否かを互いに監視し合う。例えば、ハートビート（ＨｅａｒｔＢｅａｔ）信号と呼ばれる信号を、各ノードサーバ２ａ、２ｂ、２ｃ間で交換することによって、互いにノードサーバ機能の生存を確認し合うことができる。ノード監視部１５は、他のノードサーバの機能が正常に動作していないこと、すなわち、他のノードサーバの障害を検出すると、ノード生死情報を更新して、障害が起きたノードサーバの機能が正常に動作していないことを記憶部３ａへ記録する。
【００５９】
図６は、ノード生死情報のデータ構造の例を示す図である。図６に示す例では、ノードＩＤごとに生死フラグが記録されている。例えば、ノードＩＤ＝“ｎｏｄｅ０１”のノードサーバの機能が正常に動作していないことを検出したノードサーバは、ノードＩＤ＝“ｎｏｄｅ０１”の生死フラグを“ｆａｌｓｅ”に更新することで、ノードＩＤ＝“ｎｏｄｅ０１”のノードサーバの機能が停止していることを記録することができる。
【００６０】
ノード確認部１７は、記憶部３ａのセッション担当ノード情報およびノード生死情報を参照して、所定のセッションの処理を担当するノードサーバが正常に動作しているか否かを判断する。
【００６１】
例えば、ノードサーバ２ａ、２ｂ、２ｃのうち、ノードサーバ２ｂが障害により停止した場合、ＨＴＴＰロードバランサ５ａは、ノードサーバ２ｂに、ノードサーバ２ｂが担当するセッションのＨＴＴＰメッセージを送信してもエラーの処理結果が返ってくるので、他のノードサーバ（例えば、ノードサーバ２ａ）に送信することになる。このように、ノードサーバ２ａが、自ノードサーバ２ａが担当するセッションでないセッションに関するＨＴＴＰメッセージを受け取る場合がある。例えば、ノードサーバ２ａが、ノードサーバ２ｂが担当するセッションのメッセージを受信した場合、ノードサーバ２ａのノード確認部１７は、ノードサーバ２ｂの機能が正常に動作しているか否かを判断する。
【００６２】
図７は、記憶部３ａに記憶されているセッション担当ノード情報の例を示す図である。図７に示す例では、セション担当ノード情報は、統合セッションＩＤと、ＳＩＰセッションＩＤと、ＨＴＴＰセッションＩＤとが対応付けられたセッションテーブル（図７（ａ））と、統合セッションＩＤとノードＩＤとが対応付けられた担当ノードテーブル（図７（ｂ））から構成されている。これらの情報は、例えば、ノードサーバ２ａが、ユーザ端末からデータ通信を開始する旨のＨＴＴＰメッセージまたはＳＩＰメッセージを受信したときに生成され、記憶される。
【００６３】
ノード確認部１７は、例えば、受信したＨＴＴＰメッセージに含まれるＨＴＴＰセッションＩＤと一致するＨＴＴＰセッションＩＤを図７（ａ）に示すセッション担当ノード情報のセッションテーブルから見つけ出し、そのＨＴＴＰセッションＩＤに対応する統合セションＩＤを取得する。ノード確認部１７は、取得した統合セションＩＤと一致する統合セションＩＤを図７（ｂ）に示すセション担当ノード情報の担当ノードテーブルから見つけ出し、その統合セションＩＤに対応するノードＩＤを取得する。さらに、ノード確認部１７は、取得したノードＩＤと一致するノードＩＤをノード生死情報（図６）から見つけ出し、そのノードＩＤに対応する生死フラグを参照することにより、受け取ったＨＴＴＰメッセージのセッションを担当するノードサーバの生死を判断することができる。
【００６４】
ノード振替部１９は、記憶部３ａのセッション担当ノード情報の更新およびＨＴＴＰロードバランサ５ａまたはＳＩＰロードバランサ５ｂへの更新したセッション担当ノード情報の送信を行う。ＨＴＴＰロードバランサ５ａまたはＳＩＰロードバランサ５ｂの更新部は、送られてきたセッション担当ノード情報を基に、それぞれの記憶部６ａ、６ｂに記憶されているセッション担当ノード情報を更新する。
【００６５】
ノード振替部１９は、例えば、記憶部３ａのセッション担当ノード情報において、所定のノードＩＤを、代替ノードサーバのノードＩＤに変更することで、セッション担当ノード情報を更新する。その場合、ノード振替部１９は、変更したノードＩＤと、それに対応するＳＩＰセッションまたはＨＴＴＰセッションＩＤとをセッション担当ノード情報としてＳＩＰロードバランサ５ｂまたはＨＴＴＰロードバランサ５ｂへ送信する。
【００６６】
ノード振替部１９によって変更されたノードＩＤと、それに対応するＨＴＴＰセッションＩＤとを受信したＨＴＴＰロードバランサ５ａの更新部５２は、受信したノードＩＤとＨＴＴＰセッションＩＤに基づいて、記憶部６ａに記憶されているセッション担当ノード情報を更新する。例えば、更新部５２は、そのＨＴＴＰセッションＩＤに対応するノードＩＤを、受信したノードＩＤに変更する。
【００６７】
ノード振替部１９によって変更されたノードＩＤと、それに対応するＳＩＰセッションＩＤとを受信したＳＩＰロードバランサ５ｂの更新部も同様に、受信したノードＩＤとＳＩＰセッションＩＤとに基づいて、記憶部６ｂに記憶されているセッション担当ノード情報を更新する。例えば、前記更新部は、受信したＳＩＰセッションＩＤに対応するノードＩＤを、受信したノードＩＤに変更する。
【００６８】
なお、図１に示すクラスタシステムが有するノードサーバは３台であるが、ノードサーバの台数はこれに限られない。また、図１に示すユーザ端末の数は、説明のため、実際よにも少なく描かれている。
【００６９】
（ノードサーバ２ａの動作の例）
次に、ノードサーバ２ａの動作について説明する。図８は、ノードサーバ２ａの動作の例を示すフローチャートである。なお、ノードサーバ２ｂ、２ｃの動作も図８と同様である。
【００７０】
図８に示すように、ノードサーバ２ａが起動する（ステップＳ１）と、データ送受信部１３が、ノード情報通信チャネルをオープンする（ステップＳ２）。ノード情報通信チャネルは、例えば、ノードサーバ２ａ、２ｂ、２ｃの記憶部３ａ、３ｂ、３ｃに記憶されたデータの同期を取るためのチャネルである。ノードサーバ２ａ、２ｂ、２ｃのデータ送受信部１３は、ノード情報通信チャネルを用いて、ノードサーバ２ａ、２ｂ、２ｃ間でデータを送受信する。
【００７１】
データ送受信部１３は、他のノードサーバ２ｂ、２ｃとノード生死情報の送受信を行い、記憶部３ａのノード生死情報を更新する（ステップＳ３）。また、データ送受信部１３は、他のノードサーバ２ｂ、２ｃとセッション複製チャネル情報の送受信を行う（ステップＳ４）。なお、セッション複製チャネル情報は、定期的に送受信されることが好ましい。
【００７２】
ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、ＨＴＴＰロードバランサ５ａまたはＳＩＰロードバランサ５ｂ（図８では、ＬＢと記載している。）からのメッセージを受信するまで待機する（ステップＳ５）。メッセージを受信すると、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、受信したメッセージからＳＩＰセッションＩＤまたはＨＴＴＰセッションＩＤを抽出し、セッション担当ノードのセッションテーブル（図７（ａ））を参照してセッションＩＤを取得する。（ステップＳ６）。データ送受信部１３は、他のノードサーバ２ｂ、２ｃとセッション担当ノード情報の送受信を行い、記憶部３ａのセッション担当ノード情報を最新の情報に更新する（ステップＳ７）。
【００７３】
ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、受信したメッセージがセッションの初回のメッセージか否かを判断し（ステップＳ８）、初回である場合は、受信したメッセージのセッションの担当を自ノードサーバ２ａにするように記憶部３ａのセッション担当ノード情報を更新し、更新したセッション担当ノード情報を、他のノードサーバ２ｂ、２ｃに送信する（ステップＳ１０）。その後、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、受信したメッセージに従ってアプリケーション処理を開始する（ステップＳ１４）。
【００７４】
アプリケーション処理の一例として、Ｗｅｂページからの発呼機能を実現するための処理がある。例えば、ＨＴＴＰメッセージを受信した場合の転送・保留の実行、ＳＩＰメッセージを受信した場合の呼状態情報の更新等がアプリケーション処理として行われる。
【００７５】
受信したメッセージがセッションの初回のメッセージでない場合（ステップＳ８でＮｏの場合）、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、受信したメッセージのセッションが、自ノードサーバ２ａの担当のセッションか否かを、記憶部３ａのセッション担当ノード情報を参照して判断する（ステップＳ９）。
【００７６】
受信したメッセージのセッションが自ノードサーバ２ａの担当である場合は、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１がアプリケーション処理を開始する（ステップＳ１４）。受信したメッセージのセッションが自ノードサーバ２ａの担当でないと判断されるのは、例えば、以下のような場合である。
【００７７】
ＨＴＴＰロードバランサ５ａは、通常、ＨＴＴＰメッセージが属する統合セッションを担当するノードサーバにＨＴＴＰメッセージを送信するので、ノードサーバが受信するＨＴＴＰメッセージは、自ノードサーバ２ａが担当する統合セッションのＨＴＴＰメッセージである。しかし、例えば、ＨＴＴＰロードバランサ５ａがＨＴＴＰメッセージを送信した先のノードサーバが障害により停止していた場合、ＨＴＴＰロードバランサ５ａは、別のノードサーバに再度、ＨＴＴＰメッセージを送信する。このＨＴＴＰメッセージを受信したノードサーバは、自ノードサーバの担当でない統合セッションのＨＴＴＰメッセージを受信することになる。このような場合に、ステップＳ９において、受信したメッセージの統合セッションが自ノードサーバ２ａの担当でないと判断されることになる。
【００７８】
受信したＨＴＴＰメッセージの統合セッションが自ノードサーバ２ａの担当でない場合（ステップＳ９でＮｏの場合）は、ノード確認部１７が、前記セッションの担当ノードサーバの機能が正常に動作しているか否かを判断する（ステップＳ１１）。これにより、統合セッションの担当ノードサーバが停止したために、自ノードサーバ２ａの担当でない統合セッションのＨＴＴＰメッセージが送られてきたか否かが判断される。
【００７９】
担当ノードサーバが正常に動作していない場合は、ノード振替部１９が、ノード振替処理を行う（ステップＳ１２）。すなわち、担当ノードサーバが障害等により、停止していると判断されるので、前記統合セッションの担当ノードサーバを代替のノードサーバに切り替える処理が行われる。ノード振替処理の詳細については、後述する。
【００８０】
担当ノードサーバが正常に動作している場合は、ノード振替部１９は、レスポンスにエラーを設定する（ステップＳ１３）。ＳＩＰ／ＨＴＴＰアプリケーション実行部１１が、エラーが設定されたレスポンスを、ＨＴＴＰメッセージ送信元のＨＴＴＰロードバランサ５ａに返送する。このレスポンスを受信したＨＴＴＰロードバランサ５ａは、ＨＴＴＰメッセージの送信先が、誤っていたと判断することができる。
【００８１】
アプリケーション処理が開始（ステップＳ１４）された後、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１が、統合セッションで使われる情報、すなわち、セッション属性を変更すると、（ステップＳ１５でＹｅｓ）、記憶部３ａのセッションデータが更新される。データ送受信部１３は、更新されたセッションデータを他のノードサーバ２ｂ、２ｃへ送信する（ステップＳ１６）。これにより、ノードサーバ２ｂ、２ｃの記憶部３ｂ、３ｃのセッションデータも記憶部３ａのセッションデータと同様に更新される。
【００８２】
アプリケーション処理が終了すると（ステップＳ１７でＹｅｓ）、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、正常終了のレスポンスをメッセージ送信元のＨＴＴＰロードバランサ５ａへ返送する（ステップＳ１８）。以上の処理が、ノードサーバ２ａでメッセージが受信される度に繰り返される。
【００８３】
なお、ノードサーバ２ａの処理は、図８に示すフローチャートに限られない。例えば、ノード生死情報テーブルの更新（ステップＳ３）、セッションチャネル情報の送受信（ステップＳ４）は、図８に示すタイミングで実行される必要はなく、随時行われてもよい。
【００８４】
（ノード振替処理の例）
ここで、ノード振替処理の例を説明する。図９は、ノード振替処理（図８のステップＳ１２）の詳細な処理を示すフローチャートである。図９に示すノード振替処理は、一例として、ノードサーバ２ａが、ＨＴＴＰロードバランサ５ａからＨＴＴＰメッセージを受信した際に、実行されるノード振替処理である。ここで示すノード振替処理は、障害により停止したノードサーバが処理していた統合セッションを、ノードサーバ２ａに振り替える処理である。
【００８５】
まず、ノードサーバ２ａのノード振替部１９は、記憶部３ａの統合セッション担当ノード情報を更新することによって、受信したＨＴＴＰメッセージの統合セッションを、例えば、自ノードサーバ２ａの担当とする（ステップＳ１２１）。すなわち、自ノードサーバ２ａを代替ノードサーバとする。
【００８６】
ノード振替部１９は、例えば、受信したＨＴＴＰメッセージに含まれるＨＴＴＰセッションＩＤと一致するＨＴＴＰセッションＩＤを記憶部３ａのセッション担当ノード情報のセッションテーブル（図７（ａ））から見つけ出し、そのＨＴＴＰセッションＩＤに対応する統合セッションＩＤを取得する。そして、担当ノードテーブル（図７（ｂ））に記述される前記統合セッションＩＤの担当ノードＩＤを、自ノードサーバ２ａのノードＩＤに更新する。なお、ここでは、代替ノードサーバを自ノードサーバ２ａとする例を説明しているが、自ノードサーバ２ａである必要はなく、他の正常に動作しているノードサーバを代替ノードサーバに用いることもできる。
【００８７】
データ送受信部１３は、更新したノードＩＤおよび更新対象の統合セッションを示す統合セッションＩＤを、他のノードサーバ２ｂ、２ｃに通知する（ステップＳ１２２）。これにより、他のノードサーバ２ｂ、２ｃの記憶部３ｂ、３ｃのうち正常に機能している記憶部に記憶されたセッション担当ノード情報は、統合セッションＩＤのセッションの担当ノードサーバがノードサーバ２ａであることを示すように更新される。
【００８８】
ノード振替部１９は、ＳＩＰロードバランサ５ｂへ、更新したノードＩＤおよび前記ＳＩＰセッションＩＤを送信する（ステップＳ１２３）。すなわち、ノード振替部１９は、ノードサーバ２ａが受信したＨＴＴＰメッセージの送信元であるＨＴＴＰロードバランサ５ａとは異なるプロトコルでデータ通信を行うＳＩＰロードバランサ５ｂに、代替ノードサーバを示すノードＩＤおよびＳＩＰセッションＩＤを送信する。
【００８９】
一方、ＨＴＴＰロードバランサ５ａには、例えば、レスポンスの返送時（図８のステップＳ１８）に、代替ノードサーバを示すノードＩＤと、前記ＨＴＴＰセッションＩＤが送信される。したがって、ＨＴＴＰロードバランサ５ａと、ＳＩＰロードバランサ５ｂの双方に、前記ノードＩＤと前記ＨＴＴＰセッションＩＤまたはＳＩＰセッションＩＤが送信される。送信された前記ノードＩＤと前記ＨＴＴＰセッションＩＤまたはＳＩＰセッションＩＤは、それぞれの記憶部６ａ、６ｂに記憶される。その結果、ＨＴＴＰロードバランサ５ａの記憶部６ａに記憶されているセッション担当ノード情報と、ＳＩＰロードバランサ５ｂの記憶部６ｂに記憶されているセッション担当ノード情報の内容が一致する。
【００９０】
すなわち、同一の統合セッションＩＤに対応するＨＴＴＰセッションＩＤとＳＩＰセッションＩＤは、同一の担当ノードＩＤに対応付けられる。その結果、同一の統合セッションに対応するＨＴＴＰセッションおよびＳＩＰセッションに属するメッセージは、同一のノードサーバに転送される。
【００９１】
これにより、ＨＴＴＰロードバランサ５ａおよびＳＩＰロードバランサ５ｂは、前記統合セッションＩＤで示されるセッションに属するメッセージは、全て前記ノードＩＤのノードサーバ２ａで処理されるように、ＨＴＴＰメッセージまたはＳＩＰメッセージを割り当てることができる。
【００９２】
なお、ここでは、ノード振替部１９は、ロードバランサへ通知するセッション振り替え情報をＳＩＰ／ＨＴＴＰセッションＩＤとノードＩＤをペアにして送信したが、統合セッションＩＤとノードＩＤをペアにして送信してもよい。この構成は、ＳＩＰ／ＨＴＴＰのセッションＩＤの一部に統合セッションＩＤをそのまま記入するなどの方法により、ロードバランサ５ａ、５ｂに統合セッションＩＤをＳＩＰ／ＨＴＴＰプロトコルメッセージから取り出す仕組みを作成しておくことにより可能となる。またこの構成とした場合、ノードサーバで受信したメッセージが属する統合セッションＩＤを図７（ａ）で示したセッションテーブルを参照することなく、直接取得することができる。
【００９３】
（ユーザ端末からのメッセージ受信時におけるＨＴＴＰロードバランサ５ａの動作の例）
次に、ＨＴＴＰロードバランサ５ａがユーザ端末７ａからＨＴＴＰメッセージを受信した場合の動作の例について説明する。図１０は、ＨＴＴＰロードバランサ５ａがユーザ端末７ａからＨＴＴＰメッセージを受信して、ＨＴＴＰメッセージをクラスタシステム１へ送信する処理の例を示すフローチャートである。
【００９４】
ＨＴＴＰロードバランサ５ａの負荷分散部５１は、ユーザ端末７ａからのＨＴＴＰメッセージを受信すると（ステップＳ２１）、ＨＴＴＰメッセージに含まれるＨＴＴＰセッションＩＤを抽出する（ステップＳ２２）。
【００９５】
負荷分散部５１は、抽出したＨＴＴＰセッションＩＤを含むエントリが、例えば、記憶部６ａのセッション担当ノード情報に存在するか否かを判断し（ステップＳ２３）、存在する場合は、そのエントリのノードＩＤが示すノードサーバにＨＴＴＰメッセージを送信する（ステップＳ２６）。このとき、負荷分散部５１は、ＨＴＴＰセッションＩＤに対応する統合セッションＩＤを記憶部６ａのセッション担当ノード情報中から取得してＨＴＴＰメッセージに付加してもよい。
【００９６】
セッション担当ノード情報にステップＳ２２で抽出したＨＴＴＰセッションＩＤを含むエントリが存在しない場合（ステップＳ２３でＮｏの場合）、負荷分散部５１は、送信先のノードサーバを例えば、ランダムに決定する（ステップＳ２４）。負荷分散部５１は、決定したノードサーバのノードＩＤを、ＨＴＴＰセッションＩＤと対応付けて記憶部６ａのセッション担当ノード情報に登録する（ステップＳ２５）。負荷分散部５１は、ステップＳ２４で決定したノードサーバにＨＴＴＰメッセージを送信する（ステップＳ２６）。
【００９７】
負荷分散部５１は、ＨＴＴＰメッセージを送信したノードサーバからのレスポンスを待ち、正常終了を示すレスポンスを受信したら、ユーザ端末７ａへ処理結果を通知し（ステップＳ３１）、再びユーザ端末７ａまたは７ｂからのＨＴＴＰメッセージの到着を待つ。
【００９８】
例えば、ＨＴＴＰメッセージを送信したノードサーバが障害により停止していた場合、負荷分散部５１は、エラーを示すレスポンスを受信する（ステップＳ２７でＮｏ）。この場合、負荷分散部５１は、送信先のノードサーバを変更して、別のノードサーバへＨＴＴＰメッセージを送信する（ステップＳ２８）。負荷分散部５１は、正常終了のレスポンスを受信するまで、送信先のノードサーバを変更してＨＴＴＰメッセージを送信する処理（ステップＳ２８）を繰り返す。負荷分散部５１は、正常終了のレスポンスを受信した場合（ステップＳ２９でＹｅｓの場合）、ＨＴＴＰメッセージを送信したノードサーバのノードＩＤを、ＨＴＴＰセッションＩＤと対応付けて記憶部６ａのセッション担当ノード情報に登録する（ステップＳ３０）。
【００９９】
なお、図示しないが、負荷分散部５１は、所定回数ステップＳ２８の処理を繰り返してもエラーレスポンスしか受信できない場合は、ステップＳ２８の繰り返しを終了し、エラーを示す処理結果をユーザ端末に通知してもよい。また、負荷分散部５１は、ノードサーバが正常に動作しているか否かを示す情報を記憶部６ａに記憶しておき、正常に動作しているノードサーバにのみＨＴＴＰメッセージを送信するようにしてもよい。
【０１００】
また、ＳＩＰロードバランサ５ｂのユーザ端末からのメッセージ受信時における動作も図１０に示した処理と同様とすることができる。
【０１０１】
（ノードサーバ２ａからのメッセージ受信時におけるＨＴＴＰロードバランサ５ａの動作の例）
次に、ＨＴＴＰロードバランサ５ａがノードサーバからメッセージを受信した場合の動作の例について説明する。図１１は、ＨＴＴＰロードバランサ５ａがノードサーバからＨＴＴＰメッセージを受信する処理の例を示すフローチャートである。ＨＴＴＰロードバランサ５ａがノードサーバからメッセージを受信する場合として、例えば、ノードサーバのノード振替部１９が、代替ノードサーバのノードＩＤおよび代替ノードサーバが担当するセッションのＨＴＴＰセッションＩＤをＨＴＴＰロードバランサ５ａへ送信する場合がある（図９のステップＳ１２３）。
【０１０２】
ＨＴＴＰロードバランサ５ａは、ノードサーバからメッセージを受信すると（ステップＳ４１）、メッセージからＨＴＴＰセッションＩＤおよびノードＩＤを抽出する（ステップＳ４２）。また、更新部５２は、抽出したＨＴＴＰセッションＩＤおよびノードＩＤに基づいて、記憶部６ａのセッション担当ノード情報を更新する（ステップＳ４３）。例えば、更新部５２は、ステップＳ４２で抽出されたＨＴＴＰセッションＩＤに対応するノードＩＤを、ステップＳ４２で抽出されたノードＩＤに変更する。
【０１０３】
セッション担当ノード情報に、ステップＳ４２で抽出されたＨＴＴＰセッションＩＤが存在しなければ、ステップＳ４３で抽出されたＨＴＴＰセッションＩＤおよびノードＩＤが新たに登録される。
【０１０４】
ＨＴＴＰロードバランサ５ａは、受信したメッセージが、ノードサーバのノード振替部１９からのノード振替通知でない場合（ステップＳ４４でＮｏの場合）、通常リクエストをクライアントへ送信する。
【０１０５】
なお、ＳＩＰロードバランサ５ｂが、ノードサーバからメッセージを受信した場合も、図１１に示す処理と同様の処理を行うことができる。
【０１０６】
（実施の形態２）
実施の形態１では、ノード振替部１９は、ノード振替処理（図８のステップＳ１２）の時に、メッセージの送信元ロードバランサではないロードバランサへ代替ノードサーバのノードＩＤとＨＴＴＰ／ＳＩＰセッションＩＤを通知していた（図９のステップＳ１２３）。これに対し、本実施形態では、ノード振替部１９は、ノード振替処理の時ではなく、ノード振替処理の後、メッセージの送信元ロードバランサではないロードバランサからアクセスがあった時点で、そのアクセスに対するリダイレクト命令として前記通知を行う。
【０１０７】
図１２は、本実施形態におけるノードサーバ２ａの動作の例を示すフローチャートである。図１２に示す処理が、図８に示す処理と異なる点は、ステップＳ５１とステップＳ５２である。
【０１０８】
ステップＳ１１において、ノード確認部１７が、セッションの担当ノードサーバの機能が正常に動作しているか否かを判断する。その結果、担当ノードサーバの機能が正常に動作していない場合（ステップＳ１１でＮｏの場合）は、ノード振替部１９は、受信したメッセージのセッションを担当するノードサーバが自ノードサーバ２ａになるように、記憶部３ａのセッション担当ノード情報を更新する。また、データ送受信部１３は、更新されたセッション担当ノード情報を、他のノードサーバ２ｂ、２ｃに通知する。すなわち、図９に示すステップＳ１２１およびステップＳ１２２の処理が実行される。
【０１０９】
すなわち、障害等により、担当ノードサーバの機能が停止している場合には、セッション担当ノードサーバを代替ノードサーバに変更する更新が、セッション担当ノード情報に対してなされる。
【０１１０】
担当ノードサーバの機能が正常に動作している場合（ステップＳ１１でＹｅｓの場合）は、ＳＩＰ／ＨＴＴＰアプリケーション実行部１１は、その担当ノードサーバのノードＩＤと前記セッションのＨＴＴＰ／ＳＩＰセッションＩＤとをペアにしたリダイレクト応答を生成し、レスポンスに設定する（ステップＳ５２）。リダイレクト応答が設定されたレスポンスは、メッセージ送信元のロードバランサへ送信される。
【０１１１】
図１３は、本実施形態におけるＳＩＰロードバランサ５ｂがユーザ端末８ａからＳＩＰメッセージを受信して、ＳＩＰメッセージをクラスタシステム１へ送信する処理の例を示すフローチャートである。図１３に示す処理が、図１０に示す処理と異なるステップは、ステップＳ５３である。
【０１１２】
ノードサーバへ送信したＳＩＰメッセージのレスポンスにリダイレクト命令が含まれている場合、ステップＳ２７でＮｏとなる。ＳＩＰロードバランサ５ｂは、リダイレクト応答に含まれるノードＩＤのノードサーバに再度ＳＩＰメッセージを送信する（ステップＳ５３）。リダイレクト応答には、正常に機能しているノードサーバのノードＩＤが含まれているので、再度のＳＩＰメッセージ送信のレスポンスは、正常終了する可能性が高い。
【０１１３】
これにより、例えば、ノードサーバ２ａが、ＨＴＴＰロードバランサ５ａからＨＴＴＰメッセージを受信した際に、図１２のステップＳ５１で統合セッションを担当するノードサーバが代替ノードサーバに変更されるとする。この時点で、ＳＩＰロードバランサ５ｂは、そのセッションの担当ノードサーバが、代替ノードサーバに変更されたことを示す情報を得ていない。その状態で、ノードサーバ２ａが、ＳＩＰロードバランサ５ｂからＳＩＰメッセージを受信すると、その代替ノードサーバのノードＩＤをリダイレクト応答に含めてレスポンスとして、ＳＩＰロードバランサ５ｂへ返信されることになる（図１２のステップＳ５２）。その結果、ノードサーバ２ａは、ＳＩＰロードバランサ５ｂからのメッセージ受信時に、代替ノードサーバへのリダイレクト指示をＳＩＰロードバランサ５ｂへ送信することができる。その結果、効率的なセッション操作が行われる。
【産業上の利用可能性】
【０１１４】
本発明は、複数のノードサーバのうち、一部のノードサーバが障害等により停止しても、複数のロードバランサからのメッセージを効率よく処理することができるクラスタリングシステムとして利用可能である。
【図面の簡単な説明】
【０１１５】
【図１】本実施形態におけるクラスタシステムの構成を示す機能ブロック図である。
【図２】ノードサーバ２ａの構成の例を示す機能ブロック図である。
【図３】ＨＴＴＰロードバランサ５ａの構成の例を示す機能ブロック図である。
【図４】セッションデータの構成の例を表す図である。
【図５】（ａ）は、ＨＴＴＰロードバランサ５ａの記憶部６ａに記憶されているセッション担当ノード情報の例を示す図である。（ｂ）は、ＳＩＰロードバランサ５ｂの記憶部６ｂに記憶されているセッション担当ノード情報の例を示す図である。
【図６】ノード生死情報のデータ構造の例を示す図である。
【図７】（ａ）は、記憶部３ａのセッション担当ノード情報におけるセッションテーブルの例を示す図である。（ｂ）は、記憶部３ａのセッション担当ノード情報における担当ノードテーブルの例を示す図である。
【図８】ノードサーバ２ａの動作の例を示すフローチャートである。
【図９】ノード振替処理の詳細な処理を示すフローチャートである。
【図１０】ＨＴＴＰロードバランサ５ａがユーザ端末７ａからＨＴＴＰメッセージを受信して、ＨＴＴＰメッセージをクラスタシステム１へ送信する処理の例を示すフローチャートである。
【図１１】ＨＴＴＰロードバランサ５ａがノードサーバからＨＴＴＰメッセージを受信する処理の例を示すフローチャートである。
【図１２】本実施形態におけるノードサーバ２ａの動作の例を示すフローチャートである。
【図１３】本実施形態におけるＳＩＰロードバランサ５ｂがユーザ端末８ａからＳＩＰメッセージを受信して、ＳＩＰメッセージをクラスタシステム１へ送信する処理の例を示すフローチャートである。
【図１４】クラスタリングを利用したＷＷＷシステムの構成の概略を示す図である。
【図１５】ＳＩＰサーバとＷＷＷサーバを連携する機能を持つＳＩＰ／ＨＴＴＰ連携システムにおけるクラスタリング構成の概略を示す図である。
【符号の説明】
【０１１６】
１      クラスタシステム
２ａ    ノードサーバ
３ａ、３ｂ、６ａ、６ｂ  記憶部
５ａ、５ｂ      ロードバランサ
７ａ、７ｂ、８ａ、８ｂ  ユーザ端末
１０    クラスタ管理部
１１    アプリケーション
１３    データ送受信部
１５    ノード監視部
１７    ノード確認部
１９    ノード振替部
５１    負荷分散部
５２    更新部
９０    システム
９１ａ、９１ｂ、９１ｃ  ノードサーバ
９２ａ、９２ｂ、９２ｃ  記憶部
９３    ロードバランサ
９４ａ、９４ｂ、９８ａ、９８ｂ  ユーザ端末
９５ａ、９５ｂ、９５ｃ  ノードサーバ
９６ａ、９６ｂ、９６ｃ  記憶部
９７    ロードバランサ
９９    連携システム
【図１】
0004616159.tif 000002
【図２】
0004616159.tif 000003
【図３】
0004616159.tif 000004
【図４】
0004616159.tif 000005
【図５】
0004616159.tif 000006
【図６】
0004616159.tif 000007
【図７】
0004616159.tif 000008
【図８】
0004616159.tif 000009
【図９】
0004616159.tif 000010
【図１０】
0004616159.tif 000011
【図１１】
0004616159.tif 000012
【図１２】
0004616159.tif 000013
【図１３】
0004616159.tif 000014
【図１４】
0004616159.tif 000015
【図１５】
0004616159.tif 000016