JP2007156569A - クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム - Google Patents

クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム Download PDF

Info

Publication number
JP2007156569A
JP2007156569A JP2005347071A JP2005347071A JP2007156569A JP 2007156569 A JP2007156569 A JP 2007156569A JP 2005347071 A JP2005347071 A JP 2005347071A JP 2005347071 A JP2005347071 A JP 2005347071A JP 2007156569 A JP2007156569 A JP 2007156569A
Authority
JP
Japan
Prior art keywords
node
session
server
node server
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2005347071A
Other languages
English (en)
Other versions
JP4616159B2 (ja
Inventor
Akinori Iwakawa
明則 岩川
Satoshi Okuyama
敏 奥山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2005347071A priority Critical patent/JP4616159B2/ja
Priority to US11/391,368 priority patent/US20070121490A1/en
Publication of JP2007156569A publication Critical patent/JP2007156569A/ja
Application granted granted Critical
Publication of JP4616159B2 publication Critical patent/JP4616159B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1019—Random or heuristic server selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034—Reaction to server failures by a load balancer

Abstract

【課題】ノードサーバが正常に動作しなくなった場合にも効率よく複数のロードバランサからのメッセージを処理することがクラスタシステムを提供する。
【解決手段】ロードバランサ５ａ、５ｂに接続されたクラスタシステム１が有するノードサーバ２ａ、２ｂ、２ｃのそれぞれは、セッションＩＤと担当ノードサーバとを対応付けるセッション担当ノード情報と、ノード生死情報とを記憶する記憶部３ａと、いずれか１つのロードバランサから送信されたメッセージを受け取った場合、メッセージのセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、前記セッションの担当ノードサーバを代替ノードサーバに変更するようにセッション担当ノード情報を更新し、メッセージを送信したロードバランサ以外のロードバランサに、代替ノードサーバを示すデータを送信するノード振替部とを備える。
【選択図】図１

Description

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

Claims (7)

  1. 複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からのメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、
    前記複数のノードサーバのそれぞれは、
    同一ユーザ端末の一連のデータ通信であるセッションを識別するセッションＩＤと前記セッションＩＤで示されるセッションに属するメッセージの処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、
    前記複数のロードバランサのうちいずれか１つのロードバランサからセッションＩＤを含むメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージに含まれる前記セッションＩＤのセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、
    前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションを示すデータと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備えるクラスタシステム。
  2. 前記ノード振替部は、前記メッセージを送信したロードバランサ以外のロードバランサから前記ノードサーバに対して前記セッションに関するアクセスがあった後に、前記アクセスがあったロードバランサに前記セッションのセッションＩＤと、前記代替ノードサーバを示すデータとを送信する請求項１に記載のクラスタシステム。
  3. 異なる通信プロトコルでデータ通信を行う複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする、通信プロトコルの異なる複数のユーザ端末からのメッセージの処理することにより、通信プロトコルの異なる前記複数のユーザ端末間のデータ通信を可能にするノードサーバを複数有するクラスタシステムであって、
    前記複数のノードサーバのそれぞれは、
    通信プロトコルの異なるユーザ端末同士の一連のデータ通信であるセッションを識別するセッションＩＤと前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する記憶部にアクセス可能であり、
    前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージが属するセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認部と、
    前記ノード確認部が、前記セッションを担当するノードサーバの機能が正常に動作していないと判断した場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記メッセージを送信したロードバランサとは通信プロトコルが異なる他のロードバランサに、前記セッションを示すデータと、前記代替ノードサーバを示すデータとを送信するノード振替部とを備えるクラスタシステム。
  4. 前記複数のロードバランサは、ＨＴＴＰプロトコルでデータ通信を行うロードバランサと、ＳＩＰプロトコルでデータ通信を行うロードバランサとを含む請求項３に記載のクラスタシステム。
  5. 請求項１に記載のクラスタシステムに接続された前記ロードバランサであって、
    セッションＩＤと、当該セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報を記憶する記憶部と、
    前記複数のユーザ端末からのメッセージを受信して、前記メッセージからセッションＩＤを取得し、前記セッションＩＤおよび前記セッション担当ノード情報に基づいて決定されるノードサーバへ前記メッセージを割り当てる負荷分散部と、
    前記ノードサーバが備える前記ノード振替部から前記セッションを示すデータと、前記代替ノードサーバを示すデータが送信された場合に、前記送信されたデータに基づいて、前記記憶部に記憶された担当セッションノード情報を更新する更新部とを備えるロードバランサ。
  6. 複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバによって行われるノード振替方法であって、
    前記複数のノードサーバのそれぞれが、同一ユーザ端末の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する工程と、
    前記複数のノードサーバのいずれか１つのノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージが属する記セッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認工程と、
    前記ノードサーバが、前記ノード確認工程で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションを示すデータと、前記代替ノードサーバを示すデータを送信するノード振替工程とを有するノード振替方法。
  7. 複数のロードバランサに接続され、前記複数のロードバランサそれぞれにアクセスする複数のユーザ端末からメッセージを処理することにより、前記複数のユーザ端末のデータ通信を可能にするノードサーバを複数有するクラスタシステムにおいて、前記ノードサーバに処理を実行させるノード振替プログラムであって、
    前記ノードサーバの記憶部に、同一ユーザ端末間の一連のデータ通信であるセッションを識別するセッションＩＤと、前記セッションＩＤで示されるセッションに関する処理を行う担当ノードサーバとを対応付けるセッション担当ノード情報と、前記複数のノードサーバそれぞれの機能が正常に動作しているか否かを示すノード生死情報とを記憶する処理と、
    前記ノードサーバが、前記複数のロードバランサのうちいずれか１つのロードバランサから送信されたメッセージを受け取った場合、前記セッション担当ノード情報および前記ノード生死情報を用いて、前記メッセージが属するセッションを担当するノードサーバの機能が正常に動作しているか否かを判断するノード確認処理と、
    前記ノード確認処理で、前記セッションを担当するノードサーバの機能が正常に動作していないと判断された場合、前記セッションの担当ノードサーバを代替ノードサーバに変更するように前記セッション担当ノード情報を更新し、前記複数のロードバランサに、前記セッションを示す情報と、前記代替ノードサーバを示すデータとを送信するノード振替処理と前記ノードサーバに実行させるノード振替プログラム。
JP2005347071A 2005-11-30 2005-11-30 クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム Expired - Fee Related JP4616159B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2005347071A JP4616159B2 (ja) 2005-11-30 2005-11-30 クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム
US11/391,368 US20070121490A1 (en) 2005-11-30 2006-03-29 Cluster system, load balancer, node reassigning method and recording medium storing node reassigning program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005347071A JP4616159B2 (ja) 2005-11-30 2005-11-30 クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム

Publications (2)

Publication Number Publication Date
JP2007156569A true JP2007156569A (ja) 2007-06-21
JP4616159B2 JP4616159B2 (ja) 2011-01-19

Family

ID=38087330

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005347071A Expired - Fee Related JP4616159B2 (ja) 2005-11-30 2005-11-30 クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム

Country Status (2)

Country Link
US (1) US20070121490A1 (ja)
JP (1) JP4616159B2 (ja)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012060276A1 (ja) * 2010-11-01 2012-05-10 かもめエンジニアリング株式会社 アクセス制御方法、アクセス制御装置およびアクセス制御プログラム
JP2013206083A (ja) * 2012-03-28 2013-10-07 Nippon Telegraph & Telephone East Corp 運用サイト切り替えシステム、運用サイト切り替え装置、運用サイト切り替え方法及び運用サイト切り替えプログラム
JP2013206082A (ja) * 2012-03-28 2013-10-07 Nippon Telegraph & Telephone East Corp 運用システム切り替え装置、運用システム切り替え方法及び運用システム切り替えプログラム
WO2013168465A1 (ja) * 2012-05-08 2013-11-14 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
US9521586B2 (en) 2012-03-02 2016-12-13 Ntt Docomo, Inc. Mobile communication system, communication system, node, flow-control network, and communication-control method
JP2017183888A (ja) * 2016-03-29 2017-10-05 日本電信電話株式会社 信号振り分けシステム及び信号振り分け方法

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100514940C (zh) * 2006-10-23 2009-07-15 华为技术有限公司 对网络通信端口重定向的方法和网络通信系统
US8929360B2 (en) * 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
US8775641B2 (en) * 2007-01-31 2014-07-08 Oracle International Corporation Self invitation to initiate sessions, start processes, or generate outbound messages
US7969991B2 (en) * 2007-04-23 2011-06-28 Mcafee, Inc. Session announcement system and method
CN101127766B (zh) * 2007-09-24 2010-06-09 中兴通讯股份有限公司 基于sip协议的消息处理方法、装置及ip通信系统
CN101562784B (zh) * 2008-04-14 2012-06-06 华为技术有限公司 报文分发方法、设备及系统
WO2012070155A1 (ja) * 2010-11-26 2012-05-31 富士通株式会社 管理システム、管理装置、管理方法および管理プログラム
CN103262046A (zh) * 2010-12-10 2013-08-21 日本电气株式会社 服务器管理装置、服务器管理方法和程序
US9065831B2 (en) * 2011-03-01 2015-06-23 Cisco Technology, Inc. Active load distribution for control plane traffic using a messaging and presence protocol
US9235447B2 (en) 2011-03-03 2016-01-12 Cisco Technology, Inc. Extensible attribute summarization
US8775628B2 (en) 2011-08-31 2014-07-08 Metaswitch Networks Ltd. Load balancing for SIP services
KR101609812B1 (ko) 2012-04-09 2016-04-20 엠파이어 테크놀로지 디벨롭먼트 엘엘씨 프로세싱 로드 분배
US9167041B2 (en) * 2012-06-01 2015-10-20 International Business Machines Corporation Maintaining session initiation protocol application session affinity in SIP container cluster environments
US9197546B2 (en) * 2013-08-06 2015-11-24 Oracle International Corporation System and method for providing a messaging cluster with hybrid partitions
US9444735B2 (en) 2014-02-27 2016-09-13 Cisco Technology, Inc. Contextual summarization tag and type match using network subnetting
US9680818B2 (en) * 2014-10-15 2017-06-13 Barracuda Network, Inc. Method and apparatus for bulk authentication and load balancing of networked appliances
US11165868B2 (en) * 2017-03-30 2021-11-02 Microsoft Technology Licensing, Llc Systems and methods for achieving session stickiness for stateful cloud services with non-sticky load balancers
CN111491007B (zh) * 2020-03-04 2023-08-18 北京中盾安全技术开发公司 Sip中心信令控制服务负载均衡方法及其负载均衡器

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05346868A (ja) * 1992-04-07 1993-12-27 Nec Corp オンライン業務切り換え方式
JPH1027146A (ja) * 1996-07-11 1998-01-27 Kyushu Nippon Denki Software Kk 通信処理装置及び通信処理方法
JP2003174473A (ja) * 2001-12-06 2003-06-20 Fujitsu Ltd サーバ負荷分散システム
JP2004030204A (ja) * 2002-06-25 2004-01-29 Jmnet Inc 負荷分散装置及びそれに接続するノードコンピュータ
JP2005135125A (ja) * 2003-10-30 2005-05-26 Hitachi Ltd フェイルオーバ処理方法

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5329578A (en) * 1992-05-26 1994-07-12 Northern Telecom Limited Personal communication service with mobility manager
US5742905A (en) * 1994-09-19 1998-04-21 Bell Communications Research, Inc. Personal communications internetworking
US6167261A (en) * 1997-02-27 2000-12-26 At&T Wireless Svcs. Inc. Wireless communication service management
US5978568A (en) * 1997-03-11 1999-11-02 Sequel Technology Corporation Method and apparatus for resolving network users to network computers
US6310889B1 (en) * 1998-03-12 2001-10-30 Nortel Networks Limited Method of servicing data access requests from users
AU8440998A (en) * 1998-06-29 2000-01-17 Nokia Networks Oy Method and system of providing a service to a subscriber
US6470378B1 (en) * 1999-03-31 2002-10-22 Intel Corporation Dynamic content customization in a clientserver environment
US6775267B1 (en) * 1999-12-30 2004-08-10 At&T Corp Method for billing IP broadband subscribers
US7047301B2 (en) * 2000-01-31 2006-05-16 F5 Networks, Inc. Method and system for enabling persistent access to virtual servers by an LDNS server
US7031951B2 (en) * 2000-07-19 2006-04-18 Convergys Information Management Group, Inc. Expert system adapted dedicated internet access guidance engine
US20020103873A1 (en) * 2001-02-01 2002-08-01 Kumaresan Ramanathan Automating communication and information exchange
US7243351B2 (en) * 2002-12-17 2007-07-10 International Business Machines Corporation System and method for task scheduling based upon the classification value and probability
US20050086306A1 (en) * 2003-03-14 2005-04-21 Lemke Ralph E. Providing background delivery of messages over a network
JP4190455B2 (ja) * 2004-05-11 2008-12-03 富士通株式会社 負荷分散装置及びプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05346868A (ja) * 1992-04-07 1993-12-27 Nec Corp オンライン業務切り換え方式
JPH1027146A (ja) * 1996-07-11 1998-01-27 Kyushu Nippon Denki Software Kk 通信処理装置及び通信処理方法
JP2003174473A (ja) * 2001-12-06 2003-06-20 Fujitsu Ltd サーバ負荷分散システム
JP2004030204A (ja) * 2002-06-25 2004-01-29 Jmnet Inc 負荷分散装置及びそれに接続するノードコンピュータ
JP2005135125A (ja) * 2003-10-30 2005-05-26 Hitachi Ltd フェイルオーバ処理方法

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012060276A1 (ja) * 2010-11-01 2012-05-10 かもめエンジニアリング株式会社 アクセス制御方法、アクセス制御装置およびアクセス制御プログラム
JPWO2012060276A1 (ja) * 2010-11-01 2014-05-12 かもめエンジニアリング株式会社 アクセス制御方法、アクセス制御装置およびアクセス制御プログラム
JP5538560B2 (ja) * 2010-11-01 2014-07-02 かもめエンジニアリング株式会社 アクセス制御方法、アクセス制御装置およびアクセス制御プログラム
US8850047B2 (en) 2010-11-01 2014-09-30 Kamome Engineering, Inc. Access control method, access control apparatus, and access control program
US9521586B2 (en) 2012-03-02 2016-12-13 Ntt Docomo, Inc. Mobile communication system, communication system, node, flow-control network, and communication-control method
JP2013206083A (ja) * 2012-03-28 2013-10-07 Nippon Telegraph & Telephone East Corp 運用サイト切り替えシステム、運用サイト切り替え装置、運用サイト切り替え方法及び運用サイト切り替えプログラム
JP2013206082A (ja) * 2012-03-28 2013-10-07 Nippon Telegraph & Telephone East Corp 運用システム切り替え装置、運用システム切り替え方法及び運用システム切り替えプログラム
WO2013168465A1 (ja) * 2012-05-08 2013-11-14 ソニー株式会社 情報処理装置、情報処理方法およびプログラム
JP2017183888A (ja) * 2016-03-29 2017-10-05 日本電信電話株式会社 信号振り分けシステム及び信号振り分け方法

Also Published As

Publication number Publication date
US20070121490A1 (en) 2007-05-31
JP4616159B2 (ja) 2011-01-19

Similar Documents

Publication Publication Date Title
JP4616159B2 (ja) クラスタシステム、ロードバランサ、ノード振替方法およびノード振替プログラム
US10673938B2 (en) Method and system for load balancing over a cluster of authentication, authorization and accounting (AAA) servers
US7844851B2 (en) System and method for protecting against failure through geo-redundancy in a SIP server
US7225356B2 (en) System for managing operational failure occurrences in processing devices
US7739391B2 (en) Gateway for wireless mobile clients
CN110311983B (zh) 服务请求的处理方法、装置、系统、电子设备及存储介质
JP5863942B2 (ja) ウィットネスサービスの提供
US9058213B2 (en) Cloud-based mainframe integration system and method
EP1987657B1 (en) Scalable wireless messaging system
US20070150602A1 (en) Distributed and Replicated Sessions on Computing Grids
US20060212532A1 (en) Method and Apparatus for Proxying Initial Client Requests to Support Asynchronous Resource Initialization
CN108369608A (zh) 幂等服务器群集
CN112671554A (zh) 一种节点故障处理方法及相关装置
KR100788631B1 (ko) 인터넷 프로토콜-기반 통신 시스템에서 리소스 풀링
JP6036380B2 (ja) 通信システム
JPWO2009034994A1 (ja) 負荷分散システム、サービス処理サーバ、負荷分散方法及び負荷分散プログラム
JP2007249659A (ja) システム切替方法、その計算機システム及びプログラム
KR101382177B1 (ko) 동적 메시지 라우팅 시스템 및 방법
JP5658621B2 (ja) 信号振分複製先決定システム、信号振分複製先決定方法およびプログラム
JP4123440B2 (ja) オブジェクト指向のネットワーク分散型コンピューティングシステム、その負荷分散装置及びサーバ
WO2024023962A1 (ja) プロトコル中継装置、プロトコル中継システム、プロトコル中継方法、及びプロトコル中継プログラム
JP4038406B2 (ja) イベント共有システム、ホスト、イベント共有方法及びイベント共有プログラム
JP6631300B2 (ja) 通信制御システム、通信制御方法、通信制御プログラム、および、通信制御装置
JP2004248228A (ja) サービス切替え装置、サービス提供ノード、通信システム、プログラムおよび該プログラムを格納した記録媒体
CN117857610A (zh) 数据通信方法和装置、计算机可读存储介质、电子设备

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20080411

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100203

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100803

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101001

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101019

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101021

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131029

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees