JP5278677B2 - クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法 - Google Patents

クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法 Download PDF

Info

Publication number
JP5278677B2
JP5278677B2 JP2008523702A JP2008523702A JP5278677B2 JP 5278677 B2 JP5278677 B2 JP 5278677B2 JP 2008523702 A JP2008523702 A JP 2008523702A JP 2008523702 A JP2008523702 A JP 2008523702A JP 5278677 B2 JP5278677 B2 JP 5278677B2
Authority
JP
Japan
Prior art keywords
unit
cluster member
data
packet
protocol processing
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.)
Active
Application number
JP2008523702A
Other languages
English (en)
Other versions
JPWO2008004569A1 (ja
Inventor
秀一 狩野
昌弘 地引
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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Priority to JP2008523702A priority Critical patent/JP5278677B2/ja
Publication of JPWO2008004569A1 publication Critical patent/JPWO2008004569A1/ja
Application granted granted Critical
Publication of JP5278677B2 publication Critical patent/JP5278677B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level

Description

本発明は、ネットワーク機器として機能するクラスタシステムに関し、特に、内部でアプリケーションプログラムが稼働するネットワーク機器として機能するクラスタシステムに関する。
クラスタシステムは
（ａ） 単一の機能を提供する大規模な装置を構築する手段
（ｂ） 可用性の高い装置を構築する手段
として従来から利用されている。
通常、クラスタシステムは、単一でも所定の機能を実現する装置（クラスタメンバ）を複数設けると共に、各クラスタメンバを協調して動作させるための付加機構を設けることにより構成される。
〔ロードバランサを利用したクラスタシステム〕
クラスタシステムの構成法としては種々の方法が知られているが、ロードバランサを他のシステムとの境界に置く構成が比較的広く利用されている。図３０に、ロードバランサを利用したクラスタシステム１の構成例を示す。クラスタシステム１は、複数のクラスタメンバ１１−１〜１１−ｎと、ロードバランサ１２を備えている。ネットワーク２を介して各ノード３１〜３ｍから送られてきたＩＰパケット（通信データ）は、ロードバランサ１２によって各クラスタメンバ１１−１〜１１−ｎに分配される。
図３０に示したクラスタシステム１は、ロードバランサ１２によって、後段の装置構成やフェイルオーバなどの事象を他のシステムに対して隠蔽でき、負荷バランスなどの制御をしやすい利点がある。一方で、ロードバランサ１２がボトルネックになる可能性があるという問題点がある。また、ロードバランサ１２が単一障害点になるのを避けるために、ロードバランサ１２を冗長化した場合には、構成が複雑になるという問題が生じる。
〔ブロードキャスト・ディスパッチ方式のクラスタシステム〕
これらを解決するため、ロードバランサを置かない方式（ブロードキャスト・ディスパッチ方式）のクラスタシステムが提案されている（例えば特表２００３−５１７２２１号公報参照）。
図３１は、ブロードキャスト・ディスパッチ方式のクラスタシステム１ａの構成例を示すブロック図である。クラスタシステム１ａは、ｎ台のクラスタメンバ１３−１〜１３−ｎから構成される。各クラスタメンバ１３−１〜１３−ｎは、同報通信が可能なデータリンク４に並列につながれている。各クラスタメンバ１３−１〜１３−ｎは、それぞれ振り分けフィルタ１４−１〜１４−ｎを備えている。
他のノード３１〜３ｍからクラスタシステム１ａに送られてきたＩＰパケットは、データリンク４を介して各クラスタメンバ１３−１〜１３−ｎに同報通信される。各クラスタメンバ１３−１〜１３−ｎは、振り分けフィルタ１４−１〜１４−ｎを利用して同報通信されたＩＰパケットのハッシュ値（例えば、ヘッダ部に含まれている送信元アドレスに対するハッシュ値）を計算し、計算したハッシュ値と自クラスタメンバに割り当てられている担当ハッシュ値とが等しい場合のみ、受信したＩＰパケットに対する受信処理を行う。このように、ブロードキャスト・ディスパッチ方式のクラスタシステム１ａでは、他のノード３１〜３ｍから送られてきたＩＰパケットは全クラスタメンバ１３−１〜１３−ｎへ同報通信される。各クラスタメンバ１３−１〜１３−ｎはそれぞれ自クラスタメンバに割り当てられている担当ハッシュ値に対応するＩＰパケットのみを処理する。これにより負荷分散が実現される。
更に、ブロードキャスト・ディスパッチ方式のクラスタシステムにおいて、２台以上のクラスタメンバに同一の担当ハッシュ値を割り当てれば、複数のクラスタメンバで同一のＩＰパケットを冗長に処理することになる。そのため、明示的に状態コピーを行うことなしに、通信の冗長処理を行うことが可能になる。これらにより、スケーラビリティと可用性を高めることができる。
ところで、ブロードキャスト・ディスパッチ方式のクラスタシステムは、パケットを中継するルータなどの装置を対象として開発されてきた。これらの装置では、パケットに対する処理が、比較的低いプロトコル階層までにとどまることが特徴で、パケット内のアプリケーション層の処理などは行わないことにより比較的単純な処理で高速にパケットを中継できるようにしている装置が多い。
図３２は、図３１に示したクラスタメンバ１３−１の構成例を示すブロック図、図３３Ａ、３３Ｂは、図３１に示したクラスタシステム１ａの動作を説明するための図である。
図３２を参照すると、クラスタメンバ１３−１は、隣接ノードと通信するデータリンク４に接続するための受信インタフェース１４１および送信インタフェース１４２と、パケットの処理および転送を行うプロトコル処理部１２１、１２２、…、１２ｋと、受信側振り分けフィルタ１３１と、送信側振り分けフィルタ１３２との２つのパケットフィルタと、フィルタ１３１、１３２の設定を行うフィルタ制御部１３３を備えている。
各々のフィルタ１３１、１３２は、パケットのヘッダ等からハッシュ関数により整数値を計算し、フィルタ制御部１３３によって該当フィルタ１３１、１３２に割り当てられた整数値と、計算結果の整数値が等しい場合のみ、パケットを通過させる。図３３Ａ、３３Ｂの例では４台のクラスタメンバがあり、ハッシュ値は簡単のため１〜４の４種類を用いている。
この仕組みを利用すると、異なるクラスタメンバの受信側振り分けフィルタに同一のハッシュ値を設定すれば、それらのクラスタメンバでは同一のパケットを冗長に処理することになる。そのため、該当ハッシュ値に対応するトラフィックは冗長に処理される。さらに、同一パケットが複数個系外に送出されるのを防ぐために、上記クラスタメンバのうち１台のみについて、該当ハッシュ値が送信側振り分けフィルタに設定される。たとえば、図３３Ａの例では、ハッシュ値２に相当するトラフィックは、左端とその右隣のクラスタメンバにて冗長に処理され、フロー状態が複製されていることが分かる。
また、ハッシュ関数の値域にあたる値の集合を、各クラスタメンバがすきまなく、かつ重複なく担当するように、受信側振り分けフィルタに割り当てれば、トラフィックの負荷分散が実現できる。たとえば、図３３Ａと３３Ｂは構成が同一であるが、処理対象パケットから計算されるハッシュ値により、処理クラスタメンバが切り替わり、負荷分散が実現される。これらを組み合わせて利用することで、ブロードキャスト・ルータクラスタが実現できる。
その他、関連技術として以下の文献を挙げる。特開２０００−８３０４５号公報には、ネットワークの大規模化によるルータの回線増強のニーズに対応した、拡張性の高いルータ構成技術を提供するための経路制御技術が記載されている。特開平３−３６８５３号公報には、アプリケーション部のソフトウェア構成を簡略化し、かつ高性能な発呼および着呼の呼制御を可能とすることを目的としたＩＳＤＮ端末装置及びＩＳＤＮ端末の呼制御方法が記載されている。特開平７−８７５３６号公報には、交換機の集線仮想化システムが記載されている。このシステムは、同一交換機内或いは交換機外にある加入者集線装置の制御機能を共通機能内に隠蔽して、呼制御アプリケーションに集線機能の有無を意識させないように構成される。
一方で、ホストノードとして通信を終端するサーバ等の装置では、普通アプリケーションプログラムが送受信するパケットを処理する。即ち、図３４に示すようなホストノードＨでは、受信インタフェース１４１、送信インタフェース１４２、プロトコル処理部１２１、１２２、…、１２ｋ、読込みＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）部１５１、書込みＡＰＩ部１５２を介して送受信するパケットは、アプリケーションプログラム１１０によって処理される。従来、このようなアプリケーションプログラム１１０が稼働する装置をクラスタ化する場合は、ロードバランサにてアプリケーションプログラム１１０のポリシーに従って負荷分散を行い、アプリケーションプログラム１１０が状態の冗長化を独自に行うような方式が採用されている。しかし、ロードバランサを使用したのでは、前述したように、ロードバランサがボトルネックになる等の問題が発生する。
そこで、ブロードキャスト・ディスパッチ方式により、アプリケーションプログラムが稼働する装置をクラスタ化することが考えられる。しかし、アプリケーションプログラムが稼働する装置を、ブロードキャスト・ディスパッチ方式によりクラスタ化する場合には、次のような課題が生じる。
（１）アプリケーション処理とプロトコル処理では、負荷分散や冗長化ポリシーが異なることがある。
（２）アプリケーションがもつ複雑な状態を、一貫性を保ちつつ冗長化する必要がある。
すなわち、ブロードキャスト・ディスパッチ方式では、ＩＰパケットの受信直後にそのヘッダ部に対してハッシュをかけるため、上位層のデータをトラフィックの振り分けに利用できない場合がある。たとえば、ＴＬＳ［ＲＦＣ ２２４６， Ｔｈｅ ＴＬＳ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．０． Ｔ． Ｄｉｅｒｋｓ， Ｃ． Ａｌｌｅｎ． Ｊａｎｕａｒｙ １９９９．参照］や、ＩＰｓｅｃ ＥＳＰ［ＲＦＣ ４３０３， ＩＰ Ｅｎｃａｐｓｕｌａｔｉｎｇ Ｓｅｃｕｒｉｔｙ Ｐａｙｌｏａｄ （ＥＳＰ）． Ｓ． Ｋｅｎｔ． Ｄｅｃｅｍｂｅｒ ２００５．参照］によりデータが暗号化されていたり、ＩＰフラグメンテーションにより上位層データが分割されていたりするためである。このような場合、上位層のデータに従って、トラフィックを振り分けたくても、その実現が難しい場合がある。
例えば、ブロードキャスト・ディスパッチ方式のクラスタシステムによりＷｅｂサーバ（ＨＴＴＰ）を構成した場合、全てのクラスタメンバに全てのコンテンツを保持させたのでは、多くの資源が必要になる。この問題に対する対策として、コンテンツの識別情報によって各クラスタメンバにコンテンツを振り分けるようにすることが考えられる。しかし、コンテンツの識別情報は、ＨＴＴＰリクエスト内にＵＲＬとして記述されているため、コンテンツの識別情報によってトラフィックを振り分けることはできない。このため、各クラスタメンバに全てのコンテンツを保持させておくことが必要になってしまう。
また、プロトコル処理においては、伝送路におけるデータの損失などを考慮して送達確認や再送が行われている。そのため、同報されたパケットを異なるクラスタメンバで独立に処理しても、各々のクラスタメンバのプロトコル状態には大きな齟齬が生じない場合が多い。このようなことから、ブロードキャスト・ディスパッチ方式はプロトコル処理と親和性が良い。
これに対して、アプリケーション処理は状態が複雑であり、またＵＮＩＸ（登録商標）等のマルチプロセス実行環境ではプロセススケジューリング等による処理タイミングのずれが生じやすい。そのため、同一のデータを入力しても、状態の齟齬が生じやすい。また、一般にプロトコル処理よりもアプリケーション処理のほうが実装が複雑で、特定の受信データが発端となって不具合を生じる可能性が高い。このような場合、同報されたデータを冗長系で処理しても、信頼性が高まらないため、ブロードキャスト・ディスパッチ方式は不適切である。
そこで、アプリケーション処理もプロトコル処理も効率的にサポート可能なブロードキスト・ディスパッチ方式のクラスタシステムの実現が要望されている。
ところで、図３２、図３４に示したプロトコル処理部１２１、１２２、…、１２ｋ、受信側振り分けフィルタ１３１などは、一般にＯＳ（オペレーティングシステム）のカーネルによって実現されており、また、アプリケーションプログラム１１０もシステムコールによりＯＳに対してＩＰパケットの送受信を要求している。このため、上記した要望をかなえるためには、例えば、ＯＳに上記要望をかなえるための新たな機能を組み込むことが必要になる。しかし、ＯＳに新たな機能を組み込むとなると、大規模な変更が必要になるという問題が生じる。
そこで、本発明の目的は、ＯＳに大規模な変更を加えることなく、アプリケーション処理もプロトコル処理も効率的にサポート可能なブロードキャスト・ディスパッチ方式のクラスタシステムを提供することにある。
本発明の一実施例のクラスタシステム又はサーバクラスタは、複数のクラスタメンバを備え、且つ、複数のクラスタメンバが、それぞれ、プロトコル処理を行うプロトコル処理部と、呼出しの種類に応じてプロトコル処理部からデータを読込むか或いはプロトコル処理部にデータを書込む通信ＡＰＩ部と、自クラスタメンバ上で動作するアプリケーションプログラムからの通信ＡＰＩ部に対する呼出しを捕捉してアプリケーションプログラムに代わって通信ＡＰＩ部を呼出し、その呼出しに従って通信ＡＰＩ部がプロトコル処理部から読込んだデータ或いは呼出しに従って通信ＡＰＩ部がプロトコル処理部に書込むデータに対して呼出しの種類に応じた処理を行うと共に、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う捕捉部とを備える。
本発明の他の実施例のクラスタシステム又はサーバクラスタは、複数のクラスタメンバを備え、且つ、複数のクラスタメンバの内の現用系として動作するクラスタメンバが、プロトコル処理を行う現用系プロトコル処理部と、読込み呼出しに応答して現用系プロトコル処理部からデータを読込み、書込み呼出しに応答してその書込み呼出しによって書込みが指示されているデータを現用系プロトコル処理部に書込む現用系通信ＡＰＩ部と、自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合にはアプリケーションプログラムに代わって現用系通信ＡＰＩ部に対して読込み呼出しを行い、その読込み呼出しに応答して現用系通信ＡＰＩ部が現用系プロトコル処理部から読込んだデータをアプリケーションプログラムに渡し、書込み呼出しを捕捉した場合にはアプリケーションプログラムに代わって現用系通信ＡＰＩ部に対して書込み呼出しを行う現用系呼出し捕捉部と、現用系呼出し捕捉部が書込み呼出しを捕捉した場合、自クラスタメンバの予備系となるクラスタメンバに対して、書込みデータの複製データを転送する現用系転送部とを備える。複数のクラスタメンバの内の、予備系として動作するクラスタメンバが、プロトコル処理を行う予備系プロトコル処理部と、読込み呼出しに応答して予備系プロトコル処理部からデータを読み出し、書込み呼出しに応答して予備系プロトコル処理部にデータを書込む予備系通信ＡＰＩ部と、現用系転送部から複製データが転送されてきたとき、予備系通信ＡＰＩ部に対して書込み呼出しを行い、複製データを予備系プロトコル処理部に書込ませる予備系書込み部と、予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する破棄部とを備える。
本発明のさらに他の実施例のクラスタシステム又はサーバクラスタは、複数のクラスタメンバを備える。複数のクラスタメンバが、それぞれ、プロトコル処理を行うプロトコル処理部と、予め定められているプロトコル処理用振り分け規則に基づいて、受信パケットが自クラスタメンバで処理すべき受信パケットであると判断した場合、受信パケットをプロトコル処理部に渡す受信側振り分けフィルタと、読込み呼出しに応答してプロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータをプロトコル処理部に書込む通信ＡＰＩ部と、自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合にはアプリケーションプログラムに代わって通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して通信ＡＰＩ部がプロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、該受信データをアプリケーションプログラムに渡し、他のクラスタメンバから送られてきた送信データである場合には、その送信データをプロトコル処理部に渡し、それ以外である場合には、データをアプリケーション処理振り分け部に渡し、書込み呼出しを捕捉した場合は、捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分け部に渡す呼出し捕捉部と、呼出し捕捉部から渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定し、決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムにデータを渡し、決定したクラスタメンバが他のクラスタメンバである場合には、データを転送部に渡すアプリケーション処理振り分け部と、呼出し捕捉部から渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定し、決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部にデータを渡し、決定したクラスタメンバが他のクラスタメンバである場合には、データを転送部に渡すプロトコル処理振り分け部と、アプリケーション処理振り分け部及びプロトコル処理振り分け部から渡されたデータを該当するクラスタメンバへ転送する転送部とを備える。
本発明のさらに他の実施例のクラスタシステム又はサーバクラスタは、複数のクラスタメンバを備え、全クラスタメンバに同報されたトラフィックから、自身の担当部分を各クラスタメンバが拾得し、それ以外は破棄することによりトラフィックを振り分けるクラスタシステム又はサーバクラスタである。クラスタシステム又はサーバクラスタは、（ａ）各クラスタメンバの受信インタフェースとプロトコル処理部との間に、パケットのヘッダ等から整数値を計算する計算規則と自身に割り当てられた整数値とを保持する受信側振り分けフィルタを備える。受信側振り分けフィルタでは、パケットごとに計算規則により整数値を計算し、計算結果が自身に割り当てられた整数値と等しい場合のみ、プロトコル処理部の受信処理にパケットを受け渡し、さらに、受信側振り分けフィルタに、現用系と予備系で同一数値を割り当て、さらに、計算規則により得られる計算結果の整数値の集合を各クラスタメンバですきまなく分担するように整数値を割り当てることで、トラフィックの振り分けとプロトコルの冗長処理を可能とする。クラスタシステム又はサーバクラスタは（ｂ）さらに、各クラスタメンバのプロトコル処理部とアプリケーションプログラムとの間に、受信パケットが含むアプリケーションデータから整数値を計算する計算規則と、各クラスタメンバに割り当てられた整数値の一覧による振り分け規則とを保持する振り分け・冗長処理部を備える。振り分け・冗長処理部では、振り分け規則に従って受信データから計算した整数値を割り当てられたクラスタメンバに該当データを転送し、転送先クラスタメンバのアプリケーションプログラムが読み込み処理を実行したときに該当データの読み込み処理を実行させる。クラスタシステム又はサーバクラスタはさらに、振り分け・冗長処理部は、アプリケーションプログラムが書き込んだデータに対して、その送信処理に利用されるヘッダ情報から、受信側振り分けフィルタと同一の規則にて整数値を計算する計算規則と、各クラスタメンバに割り当てられた整数値の一覧とを保持し、アプリケーションプログラムが書き込んだデータに対して、計算規則に従って整数値を計算し、整数値を割り当てられた複数のクラスタメンバに対して書き込みデータを転送することで、アプリケーション処理と冗長化されたプロトコル処理メンバの割り当てを独立に制御可能とする。クラスタシステム又はサーバクラスタは（ｃ）さらに、各クラスタメンバの送信側インタフェースとプロトコル処理部との間に、予備メンバとして処理されたパケットを破棄する送信側パケットフィルタとを備える。
本発明のさらに他の実施例のクラスタシステム又はサーバクラスタは、複数のクラスタメンバを備え、全クラスタメンバに同報されたトラフィックから、自身の担当部分を各メンバが拾得し、それ以外は破棄することによりトラフィックを振り分けるクラスタシステム又はサーバクラスタである。クラスタシステム又は、各クラスタメンバの送受信インタフェースとプロトコル処理部の間に、パケットのヘッダ等から整数値を計算する計算規則と自身に割り当てられた整数値とを保持する送信側振り分けフィルタおよび受信側振り分けフィルタを備える。受信側振り分けフィルタでは、パケットごとに計算規則により整数値を計算し、計算結果が自身に割り当てられた整数値と等しい場合のみ、プロトコル処理部の受信処理に該パケットを受け渡す。送信側振り分けフィルタでは、プロトコル処理部から受け渡された送信パケットごとに、計算規則により整数値を計算し、計算結果が自身に割り当てられた整数値と等しい場合のみ、パケットを送信インタフェースから送出し、さらに、受信側振り分けフィルタに、現用系と予備系で同一数値を割り当て、送信側振り分けフィルタに、現用系のみで数値を割り当てることで冗長処理を可能とし、さらに、計算規則により得られる計算結果の整数値の集合を各クラスタメンバですきまなく分担するように整数値を割り当てることで、トラフィックの振り分けと冗長処理を可能とする。
〔作用〕
クラスタメンバには、自クラスタメンバ上で動作するアプリケーションプログラムからの通信ＡＰＩ部に対する呼出しを捕捉する捕捉部が設けられている。この捕捉部は、呼出しを捕捉すると、アプリケーションプログラムに代わって通信ＡＰＩ部を呼び出す。捕捉部は、この呼出しに従って通信ＡＰＩ部がプロトコル処理部から読込んだデータまたはこの呼出しに従って通信ＡＰＩ部がプロトコル処理部に書込むデータに対して、呼出しの種類に応じた処理を行う。捕捉部はさらに、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う。捕捉部は、プロトコル処理部を構成するＯＳの外部に設けることができる。そのため、ＯＳに大規模な変更を加えることなく、アプリケーション処理もプロトコル処理も効率的にサポート可能なブロードキャスト・ディスパッチ方式のクラスタシステムを提供することが可能になる。
例えば、クラスタメンバを冗長化する場合、上述の処理をする捕捉部として、現用系のクラスタメンバ上に現用系呼出し捕捉部と現用系転送部とが設けられる。現用系呼出し捕捉部は、自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉する。読込み呼出しが捕捉された場合には、現用系呼出し捕捉部は、アプリケーションプログラムに代わって現用系通信ＡＰＩ部に対して読込み呼出しを行い、この読込み呼出しに応答して現用系通信ＡＰＩ部が現用系プロトコル処理部から読込んだデータをアプリケーションプログラムに渡す。書込み呼出しが捕捉された場合には、現用系呼出し捕捉部は、アプリケーションプログラムに代わって現用系通信ＡＰＩ部に対して書込み呼出しを行う。現用系呼出し捕捉部は、書込み呼出しを捕捉した場合さらに、自クラスタメンバの予備系であるクラスタメンバに対して、現用系転送部を利用して書込みデータの複製データを転送する。
一方、予備系のクラスタメンバ上には、捕捉部として、予備系書込み部と、破棄部とを設ける。予備系書込み部は、現用系転送部から複製データが転送されてきたとき、予備系通信ＡＰＩ部に対して書込み呼出しを行い、複製データを予備系プロトコル処理部に書込ませる。破棄部は、予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する。
このような構成を取ることにより、図２９Ａに示すように、現用系、予備系のプロトコル処理部において、同一の送信トラフィック、受信トラフィックが処理され、且つ、現用系のクラスタメンバにおいてのみ、データの送出及び受信データのアプリケーションプログラムへの受け渡しが行われることになる。現用系のプロトコル処理部と予備系のプロトコル処理部は、同一の受信トラフィック、送信トラフィックを処理するので、その状態は同一になる。
なお、アプリケーションプログラムが持つ複雑な状態の冗長化は、アプリケーションプログラムが独自の方法で行うことができる。例えば、次の方法で、冗長化することができる。
１．現用系アプリケーションプログラムが通信相手から何らかのデータを受信する。
２．現用系アプリケーションプログラムは、受信データから管理データの更新内容を決定し、プロセス間通信や共有メモリなどを用いて、該当更新内容を予備系アプリケーションプログラムへ通知する。
３．予備系アプリケーションプログラムは、現用系からの通知に従って自身の管理データを更新し、更新の成否を現用系アプリケーションプログラムへ応答する。
４．現用系アプリケーションプログラムは、予備系アプリケーションプログラムのデータ更新が成功したら、自身の管理データを更新する。
５．以上の処理が正しく行われたら、通信相手に応答を返す。
一方、負荷分散が行われる場合には、クラスタメンバ上に、捕捉部として、呼出し捕捉部と、アプリケーション処理振り分け部と、プロトコル処理振り分け部と、転送部とが設けられる。
呼出し捕捉部は、自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉する。
読込み呼出しを捕捉した場合、呼出し捕捉部はアプリケーションプログラムに代わって通信ＡＰＩ部に対して読込み呼出しを行う。この読込み呼出しに応答して通信ＡＰＩ部がプロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、呼出し捕捉部は、読込んだデータをアプリケーションプログラムに渡す。通信ＡＰＩ部が読込んだデータが他のクラスタから送られてきた送信データである場合には、呼出し捕捉部は、読込んだデータをプロトコル処理部に渡す。それ以外である場合には、呼出し捕捉部は、上記データをアプリケーション処理振り分け部に渡す。
また、書込み呼出しを捕捉した場合は、捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分け部に渡す。
アプリケーション処理振り分け部は、呼出し捕捉部から渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定する。そして、決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムにデータを渡し、決定したクラスタメンバが他のクラスタメンバである場合には、データを転送部に渡す。
また、プロトコル処理振り分け部は、呼出し捕捉部から渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定する。そして、決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部にデータを渡し、決定したクラスタメンバが他のクラスタメンバである場合には、データを転送部に渡す。
転送部は、アプリケーション処理振り分け部及びプロトコル処理振り分け部から渡されたデータを該当するクラスタメンバへ転送する。
このような構成を取ることにより、図２９Ｂに示すように、トラフィックに対するプロトコル処理とアプリケーション処理とを異なるクラスタメンバで行うことが可能になる。
本発明によれば、ＯＳに大規模な変更を加えることなく、アプリケーション処理もプロトコル処理も効率的にサポート可能なブロードキャスト・ディスパッチ方式のクラスタシステムを提供することできるという効果を得ることができる。その理由は以下の通りである。クラスタメンバが備える捕捉部は、自クラスタメンバ上で動作するアプリケーションプログラムからの通信ＡＰＩ部に対する呼出しを捕捉して、そのアプリケーションプログラムに代わって通信ＡＰＩ部を呼出す。捕捉部は、この呼出しに従って通信ＡＰＩ部がプロトコル処理部から読込んだデータ或いは上記呼出しに従って通信ＡＰＩ部がプロトコル処理部に書込むデータに対して上記呼出しの種類に応じた処理を行う。捕捉部はさらに、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う。この捕捉部は、プロトコル処理部を構成するＯＳの外部に設けることができるので、ＯＳに大規模な変更を加えることなく、アプリケーション処理もプロトコル処理も効率的にサポート可能なブロードキャスト・ディスパッチ方式のクラスタシステムを提供することが可能になる。
本発明によれば、高度な信頼性が求められるような基幹業務用のサーバ装置や、ネットワーク上でトラフィックが集中するアプリケーションレベルゲートウエイ装置を冗長化できる。また、例えば、通信キャリアで電話の呼制御をおこなうサーバ装置などについて、単一の装置としても動作する上記サーバ装置を用いて、それを任意の台数増設して負荷分散を行わせるようなクラスタ装置とし、非常に大規模で処理能力の大きなサーバを構築できる。
本発明にかかる実施例１で使用するクラスタメンバ１００の構成例を示す。 実施例１の現用系、予備系を説明するための図である。 比較例のホストノードＨの受信読込み処理（プロトコル処理）を示す流れ図である。 比較例のホストノードＨの受信読込み処理（アプリケーション処理）を示す流れ図である。 実施例１における現用系の受信読込み処理（プロトコル処理）の一例を示す流れ図である。 実施例１における現用系の受信読込み処理（アプリケーション処理）の一例を示す流れ図である。 実施例１における予備系の受信読込み処理の一例を示す流れ図である。 実施例１における予備系の受信読込み処理の一例を示す流れ図である。 実施例１の受信読込みシーケンスを示す図である。 比較例のホストノードＨの書込み送信処理を示す図である。 実施例１における現用系の書込み送信処理の一例を示す図である。 実施例１における現用系の書込み送信処理の一例を示す図である。 実施例１における予備系の書込み送信処理の一例を示す図である。 実施例１における書込み送信シーケンスを示す図である。 実施例１におけるサーバ側のセッション開設シーケンスを示す図である。 実施例１におけるクライアント側のセッション開設シーケンスを示す図である。 本発明の実施例２の概要を説明するための図である。 本発明の実施例２の概要を説明するための図である。 本発明にかかるクラスタシステムの実施例２の構成例を示すブロック図である。 実施例２で使用するクラスタメンバ１００ａ−１の構成例を示すブロック図である。 実施例２における受信読込み処理の一例を示す図である。 実施例２における受信読込み処理の一例を示す図である。 実施例２における読込みリダイレクト処理の一例を示す図である。 実施例２における読込みリダイレクト処理の一例を示す図である。 実施例２における書込み送信処理の一例を示す流れ図である。 実施例２における書込み送信処理の一例を示す流れ図である。 実施例２におけるサーバ側のセッション開設シーケンスを示す図である。 実施例２におけるサーバ側のセッション開設シーケンスを示す図である。 実施例２におけるクライアント側のセッション開設シーケンスを示す図である。 本発明にかかるクラスタシステムの実施例３の概要を説明するための図である。 本発明にかかるクラスタシステムの実施例３の概要を説明するための図である。 実施例３で使用するクラスタメンバ１００ｂの構成例を示すブロック図である。 実施例３における受信読込み処理の一例を示す流れ図である。 実施例３における受信読込み処理の一例を示す流れ図である。 実施例３における読込み処理の一例を示す流れ図である。 実施例３における読込み処理の一例を示す流れ図である。 実施例３における読込み処理の一例を示す流れ図である。 実施例３における読込み処理の一例を示す流れ図である。 実施例３におけるＡＰＩ側の書込み送信処理の一例を示す流れ図である。 実施例３におけるＡＰＩ側の書込み送信処理の一例を示す流れ図である。 実施例３におけるプロトコル処理側の書込み送信処理の一例を示すフローチャートである。 本発明の作用を説明するための図である。 本発明の作用を説明するための図である。 ロードバランサを用いた技術を説明するための図である。 ブロードキャスト・ディスパッチ方式のクラスタシステムのブロック図である。 ブロードキャスト・ディスパッチ方式のクラスタメンバ１３−１の構成を示すブロック図である。 ブロードキャスト・ディスパッチ方式のクラスタシステムの動作を説明するための図である。 ブロードキャスト・ディスパッチ方式のクラスタシステムの動作を説明するための図である。 アプリケーションプログラムが動作するホストノードＨの構成を示すブロック図である。 本発明の実施例４で使用するクラスタメンバ１００ｃの構成例を示すブロック図である。 実施例４で使用する予備系の受信振り分けフィルタ１０３１及び送信側振り分けフィルタ１０３２の構成例を示すブロック図である。 実施例４で使用する現用系の受信側振り分けフィルタ１０２１の構成例を示すブロック図である。 実施例４の予備系の処理例を示すフローチャートである。 実施例４の現用系の処理例を示すフローチャートである。 実施例４の現用系の処理例を示すフローチャートである。 実施例４の現用系の処理例を示すフローチャートである。 本発明にかかる実施例５で解決する問題点を説明するための図である。 実施例５で使用するクラスタメンバの構成例を示すブロック図である。 実施例５の処理例を示すフローチャートである。 実施例５の処理例を示すフローチャートである。
次に、発明を実施するための最良の形態について図面を参照して詳細に説明する。
〔本発明の実施例１〕
本発明の実施例１においては、ブロードキャスト・ディスパッチ方式のクラスタシステムにおいて、アプリケーションプログラムを搭載したクラスタメンバの冗長化が行われる。本実施例は、図３１に示すようなブロードキャスト・ディスパッチ方式のクラスタシステムにおいて、クラスタメンバ１３−１〜１３−ｎの代わりに、図１に示すクラスタメンバ１００を用いることにより実現される。本実施例のクラスタシステムは、例えば、サーバ（サーバクラスタ）として機能する。
図１を参照すると、本実施例にかかるクラスタメンバ１００は、アプリケーションプログラム１１０と、プロトコル処理部１２１、１２２、…、１２ｋと、受信側振り分けフィルタ１３１と、送信側振り分けフィルタ１３２と、フィルタ制御部１３３と、受信インタフェース１４１と、送信インタフェース１４２と、通信ＡＰＩ部としての読込みＡＰＩ部１５１と、通信ＡＰＩ部としての書込みＡＰＩ部１５２と、読込みＡＰＩ呼出し捕捉部１６１と、書込みＡＰＩ呼出し捕捉部１６２と、複製部／照合部１７１と、複製部／書込み部１７２と、制御部１７３と、転送部１７４とを備えている。
クラスタメンバ１００は、以下に例示されるように、コンピュータによって実現可能である。コンピュータをクラスタメンバ１００として機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体が用意される。コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、プロトコル処理部１２１、１２２、…、１２ｋと、受信側振り分けフィルタ１３１と、送信側振り分けフィルタ１３２と、フィルタ制御部１３３と、受信インタフェース１４１と、送信インタフェース１４２と、読込みＡＰＩ部１５１と、書込みＡＰＩ部１５２と、読込みＡＰＩ呼出し捕捉部１６１と、書込みＡＰＩ呼出し捕捉部１６２と、複製部／照合部１７１と、複製部／書込み部１７２と、制御部１７３と、転送部１７４とを実現する。
クラスタメンバ１００は、現用クラスタメンバ、予備クラスタメンバの何れとしても機能することができる。図２にクラスタメンバ１００を現用クラスタメンバ、予備クラスタメンバとして機能させたときの構成と、送受信データの流れを示す。図２は、本発明の主要部分のみを抜き出して示している。プロトコル処理部１２１、１２２、…、１２ｋ、受信側振り分けフィルタ１３１、送信側振り分けフィルタ１３２、フィルタ制御部１３３、受信インタフェース１４１、送信インタフェース１４２は図示を省略している。
〔現用クラスタメンバの構成〕
図２を参照すると、現用クラスタメンバは、読込みＡＰＩ部１５１および書込みＡＰＩ部１５２と、アプリケーションプログラム１１０との間に、複製部１７１（現用クラスタメンバとして機能させた場合には、図１の複製部／照合部１７１が図２の複製部１７１として機能する）と、複製部１７２（現用クラスタメンバとして機能させた場合には、図１の複製部／書込み部１７２が複製部１７２として機能する）と、制御部１７３と、転送部１７４と、読込みＡＰＩ呼出し捕捉部１６１と、書込みＡＰＩ呼出し捕捉部１６２とを備える。
読込みＡＰＩ呼出し捕捉部１６１は、アプリケーションプログラム１１０がシステムコール等により読込み処理を呼出す際に、その呼出しを捕捉して、読込み処理の前後にクラスタ化処理を挟み込むために利用される。書込みＡＰＩ呼出し捕捉部１６２についても同様である。
複製部１７１、１７２は、読込みおよび書込みされる送受信データを複製して、転送部１７４に受け渡す処理を行う。
転送部１７４は、複製部１７１、１７２からデータを受け取り、予備クラスタメンバに該当データを転送する。また転送部１７４は、予備クラスタメンバによるそのデータの処理結果を受け取って複製部１７１、１７２へ受け渡す。
読込みＡＰＩ部１５１、書込みＡＰＩ部１５２は、各々実際の通信を行うためのＡＰＩを提供する。これらは、図３４に示したホストノードＨにも備わっている。読込みＡＰＩ部１５１、書込みＡＰＩ部１５２と共に設けられているプロトコル処理部１２１、１２２、…、１２ｋ、受信側振り分けフィルタ１３１、送信側振り分けフィルタ１３２、フィルタ制御部１３３、受信インタフェース１４１、送信インタフェース１４２は、図２では省略されている。
アプリケーションプログラム１１０は、読込みＡＰＩ部１５１および書込みＡＰＩ部１５２を呼び出して通信処理を行う。
制御部１７３は、セッション管理など、通信の制御処理のクラスタ化を担当する。
〔予備クラスタメンバの構成〕
予備クラスタメンバは、読込みＡＰＩ部１５１および書込みＡＰＩ部１５２と、アプリケーションプログラム１１０との間に、照合部１７１（予備クラスタメンバとして機能させた場合には、図１の複製部／照合部１７１が図２の照合部１７１として機能する）と、書込み部１７２（予備クラスタメンバとして機能させた場合には、図１の複製部／書込み部１７２が図２の書込み部１７２として機能する）と、読込みＡＰＩ呼出し捕捉部１６１と、書込みＡＰＩ呼出し捕捉部１６２と、制御部１７３と、転送部１７４とを備える。制御部１７３は、その内部に切替通知部１７３１、切替制御部１７３２、現用監視部１７３３を備える。
読込みＡＰＩ呼出し捕捉部１６１、書込みＡＰＩ呼出し捕捉部１６２、転送部１７４の機能は、現用クラスタメンバのところで説明した通りである。
複製部／書込み部１７２は、現用クラスタメンバから転送されてきた書込み用データを予備クラスタメンバの書込みＡＰＩ部１５２を経由して、予備クラスタメンバの送信処理に回すために使われる。
照合部１７１は、現用クラスタメンバで読込まれた受信データを受け取って、予備クラスタメンバ自身の読込みＡＰＩ部１５１経由で読込み処理を行い、同一内容が読込まれているかどうか照合する処理を行う。
制御部１７３は、セッション管理など通信の制御処理のクラスタ化と、現用系との系切り替えの操作を担当する。
切替通知部１７３１は、現用クラスタメンバの死活監視を行うプログラム（図示せず）から現用クラスタメンバの故障検知の情報を受け取り、それを必要に応じてアプリケーションプログラム１１０と切替制御部１７３２へ伝達するために使う。
切替制御部１７３２は、現用クラスタメンバが故障して予備クラスタメンバがフェイルオーバを行う際に、照合部１７１、書込みＡＰＩ部１５２の動作を切り替えて、予備系のアプリケーションプログラム１１０が送受信を行えるようにするための機能を備える。
現用監視部１７３３は、現用系（現用クラスタメンバ）の死活を、別途定められた手順に従って監視する機能を持つ。ただし、この機能はアプリケーションプログラム等が独自に実装しても良く、その場合は、現用監視部１７３３は省いても良い。
〔マルチプロセス環境におけるライブラリによる実現〕
ここで、クラスタメンバが、マルチプロセス用オペレーティングシステムで実現されている場合には、一般的には次のような対応によって実現される。読込みＡＰＩ部１５１、書込みＡＰＩ部１５２は、典型的にはシステムコールのＡＰＩとして実現される。プロトコル処理部１２１、１２２、…、１２ｋ以下はＯＳのカーネル等の一部として実現される。アプリケーションプログラムは、ユーザープロセスとして実現される。
このような構成において、読込みＡＰＩ呼出し捕捉部１６１および書込みＡＰＩ呼出し捕捉部１６２と、読込みＡＰＩ部１５１および書込みＡＰＩ部１５２との間に挟まれている部分は、ライブラリとして実現することができる。このようにすることで、本発明のクラスタ機能を追加する場合に、従来から存在しているＯＳのカーネル部分とアプリケーションの実装への変更を小さくすることができる。ＯＳのカーネル部分とアプリケーションプログラムは、通常各々独立したファイルとして管理されていて、ライブラリはアプリケーションプログラムを実行する際に動的にリンクできるようになっているシステムが多いためである。
〔アプリケーションプログラムが複数動作する場合の構成〕
ここまで、簡単のため、クラスタメンバ内ではアプリケーションプログラムは一つだけ動作しているように説明してきたが、アプリケーションプログラムは、複数稼働していても良い。この場合、アプリケーションプログラムごとに、先に説明した構成部分を別々に用意する。
現用系と予備系の転送部１７４が冗長化のために通信するために、転送部１７４には、現用系のどのアプリケーションプログラムと予備系のどのアプリケーションプログラムとが対応しているかが予め設定されている。具体的には、互いの冗長化通信用セッションのポート番号などを設定等により予め知っているものとする。
〔実施例１の動作の説明〕
次に、本実施例の動作について詳細に説明する。
〔読込み処理〕
まず、本実施例の特徴を説明するため、読込みＡＰＩ呼出し捕捉部１６１、書込みＡＰＩ呼出し捕捉部１６２等を備えておらずクラスタ化されていないホストノードＨ（図３４参照）の受信読込み処理を図３Ａ、３Ｂの流れ図を参照して説明する。
図３Ａ、３Ｂを参照すると、読込み処理は、２つの一連の処理から構成されている。一つは図３Ａに示されたパケット受信を契機とする処理（プロトコル処理）である。もう一つは図３Ｂに示されたアプリケーションプログラムの読込み処理を契機とする処理（アプリケーション処理）である。
前者と後者は、同一の受信データを扱うが、処理の流れがいったん途切れるため、このように分けてある。
データリンク４からホストノードＨ宛のＩＰパケットが到着すると、受信インタフェース１４１がそれを受信する（ステップＳ３０１）。受信データは、低レイヤのプロトコル処理部１２１から高レイヤのプロトコル処理部１２ｋまで順に処理されながら受け渡される（ステップＳ３０２、Ｓ３０３）。例えば、ＴＣＰ／ＩＰネットワークでは、レイヤは典型的にはイーサネット（登録商標）、ＩＰ、 ＴＣＰなどの組合わせである。
最上位層のプロトコル処理部１２ｋは、自層のプロトコル処理が完了すると、読込みＡＰＩ部１５１に対して読込み可能であることを通知する（ステップＳ３０４）。この通知は、例えば、プロトコル処理部１２ｋと読込みＡＰＩ部１５１とにより共有される状態変数を用意しておき、状態変数の値を読込み可能であることを示す値に変更することにより行う。
アプリケーションプログラム１１０が、読込みＡＰＩ部１５１に対して受信データの読込みを要求すると（ステップＳ３０５）、読込みＡＰＩ部１５１は、プロトコル処理部１２ｋから読込み可能であることが通知されている場合（ステップＳ３０６がＹＥＳ）は、受信データを読込み、アプリケーションプログラム１１０に渡す（ステップＳ３０７、Ｓ３０８）。これに対して、読込み可能であることが通知されていない場合（ステップＳ３０６がＮＯ）は、読込み可能が通知されるまで、読込み処理をブロックする（ステップＳ３０９）。
次に、本実施例の処理を説明する。図４Ａ、４Ｂは、本実施例における受信読込み処理のうち、現用系側の動作を示した流れ図である。
受信読込み処理は、比較のために説明したホストノードＨの場合と同様に、図４Ａに示されたプロトコル処理（ステップＳ４０１〜Ｓ４０４）と図４Ｂに示されたアプリケーション処理（Ｓ４０５〜Ｓ４１６）とに別れている。このうち、プロトコル処理（ステップＳ４０１〜Ｓ４０４）では、ステップＳ４０１で行う処理が図３ＡのステップＳ３０１で行う処理と多少異なっており、ステップＳ４０２〜Ｓ４０４で行う処理は、図３ＡのステップＳ３０２〜Ｓ３０４で行う処理と同じである。ステップＳ４０１では、受信側振り分けフィルタ１３１で計算したハッシュ値が担当ハッシュ値と等しいパケットのみを受信するようにしている点がステップＳ３０１で行う処理と相違している。
次に、アプリケーション処理を説明する。本実施例では、アプリケーションプログラム１１０による読込みＡＰＩ部１５１の呼出しを、読込みＡＰＩ呼出し捕捉部１６１が捕捉する（ステップＳ４０５、Ｓ４０６）。読込みＡＰＩ呼出し捕捉部１６１は、上記呼出しを捕捉すると、アプリケーションプログラム１１０に代わって読込みＡＰＩ部１５１を呼出す（ステップＳ４０７）。これにより、読込みＡＰＩ部１５１は、プロトコル処理部１２ｋに受信データが用意されていればそれを読込み、用意されていなければ、受信データが用意できるまで読込み処理をブロックする（ステップＳ４０８〜Ｓ４０９）。
次に、読込みＡＰＩ部１５１が読込んだ受信データを、複製部１７１で複製して転送部１７４に渡し、転送部１７４が渡されたデータを予備クラスタメンバへ送る（ステップＳ４１１）。この複製データの送信は、クラスタメンバ間の専用の通信機構、共有メモリ、あるいはアプリケーションプログラムが通信に用いる読み書き用のＡＰＩ部を利用して行う。
さらに、予備クラスタメンバから、データを照合した結果が送られてくるため、読込みＡＰＩ部１５１からの読込み処理を行い、該当データの受信を待つ（ステップＳ４１２）。照合結果が送られてくると、転送部１７４は、読込みＡＰＩ部１５１から該当データを読み取り、それを複製部１７１に渡す（ステップＳ４１３）。複製部１７１は、照合結果が照合成功を示している場合（ステップＳ４１４がＹＥＳ）は、ステップＳ４１０で読込んだデータを読込みＡＰＩ呼出し捕捉部１６１を介してアプリケーションプログラム１１０に受け渡し（ステップＳ４１５）、照合結果が照合失敗を示している場合（ステップＳ４１４がＮＯ）は、ステップＳ４１０で読込んだデータを破棄して、アプリケーションプログラム１１０にエラーを返す（ステップＳ４１６）。
次に予備系での動作を説明する。図５Ａ、５Ｂは、本実施例における受信読込み処理の内、予備系側の動作を示した流れ図である。
同図を参照すると、現用系と同様に、予備系の読込み処理も、２つの一連の処理から構成されている。
本実施例では、受信データは全クラスタメンバへ同報されるため、現用クラスタメンバと同一のパケットが、予備クラスタメンバにも届く。なお、予備クラスタメンバの担当ハッシュ値は、現用クラスタメンバの担当ハッシュ値と同じになっている。
ステップＳ５０１〜Ｓ５０４では、図４Ａに示したステップＳ４０１〜４０４と同様の受信処理が行われる。
一方、予備系では、読込み処理はアプリケーションプログラムが駆動するのではなく、クラスタ処理自身が駆動する。
予備系のクラスタメンバ内部では、照合部１７１が、転送部１７４を経由して、現用系からの受信データ（複製データ）の読込を行う。転送部１７４は、現用系からの複製データの到着を待っており、複製データが到着すると、それを照合部１７１へ渡す（ステップＳ５０５、Ｓ５０６）。これを契機として、照合部１７１は、読込みＡＰＩ部１５１経由で受信データを読込む（ステップＳ５０７〜Ｓ５１０）。このとき、読込む受信データ長を指定できる場合には、現用系から受け取った受信データの複製と同一の長さだけを読込むようにする。
その後、照合部１７１は、ステップＳ５１０で読込んだ受信データと、現用系から受け取った受信データの複製データとを比較し、内容が一致する場合には照合成功を示す照合結果を現用系に送信し、内容が不一致の場合には、照合失敗を示す照合結果を現用系へ送信する（ステップＳ５１１）。その後、照合部１７１は、受信データを破棄する（ステップＳ５１２）。なお、現用系から受け取った受信データの複製データよりも、ステップＳ５１０において自身が読込んだデータの方が少ない場合は、同じだけデータが揃うまで、読込みを続ける。ただし、予め指定された時間読込みを続けても、データが揃わないときは、読込みをとりやめて照合を失敗としてもよい。予備系自身の受信データは、以上の処理の終了後に破棄する。
なお、照合結果の送信は、複製データの送信と同様に、クラスタメンバ間の専用の通信機構、共有メモリ、あるいはアプリケーションプログラムが通信に用いる読み書き用のＡＰＩを利用して行う。但し、アプリケーションプログラムが通信に用いる読み書き用のＡＰＩを利用する場合には、後述の書込み処理の結果として、ＩＰパケットが、予備系からの送出直前に破棄されてしまうため、現用系との通信ができないことになる。このため、現用系宛てのパケットについては、破棄せずに実際に送出させるよう、例外処理を行う。
図６は、以上の現用系と予備系の動作をまとめてシーケンス図にしたものである。現用系と予備系に同報されたパケットは、両方の系のプロトコル処理部を通って冗長に処理される。現用系と予備系の受信データは予備系で照合される。同一のデータが受信された場合に限り、現用系のアプリケーションに受け渡される。これにより、プロトコルの冗長処理が実現される。
また、現用系と予備系で、データの読込みが終わるまで、アプリケーションの読込み処理は終了しない。このようにすることで、現用系あるいは予備系の片系だけで読込み処理が進んでしまうような、処理の同期のずれを防ぐことができる。
〔書込み処理〕
まず、本実施例の特徴を説明するための比較例として、読込みＡＰＩ呼出し捕捉部１６１、書込みＡＰＩ呼出し捕捉部１６２等を備えておらずクラスタ化されていないホストノードＨ（図３４参照）の書込み送信処理を図７に示す。
図７を参照すると、クラスタ化されていないホストノードＨでは、アプリケーションプログラム１１０が書込みＡＰＩ部１５２を呼出し、書込みＡＰＩ部１５２内のバッファに送信データを書込む（ステップＳ７０１）。書込みＡＰＩ部１５２は、送信データが内部のバッファに書込まれると、上記送信データを最上位のプロトコル処理部１２ｋに渡すことができるか否かを調べる（ステップＳ７０２）。そして、送信データを渡せる場合（ステップＳ７０２がＹＥＳ）には、送信データを最上位層のプロトコル処理部１２ｋに渡し（ステップＳ７０４）す。プロトコル処理部１２ｋ内のバッファが満杯である等の理由によりデータをプロトコル処理部１２ｋに渡せない場合（ステップＳ７０２がＮＯ）、送信データを渡せる状態になるまで、書込み処理がブロックされる（ステップＳ７０３）。
書込みＡＰＩ部１５２から出力された送信データは、高レイヤのプロトコル処理部１２ｋから低レイヤのプロトコル処理部１２１まで順に処理されながら受け渡される（ステップＳ７０５、Ｓ７０６）。そして、最終的に送信インタフェース１４２からデータリンク４へ送出される（ステップＳ７０７）。以上がホストノードＨにおける書込み送信処理である。
次に本実施例の書込み送信処理を説明する。図８Ａ、８Ｂは、本実施例における書込み送信処理の内、現用系側の動作を示した流れ図である。
同図を参照すると、書込み送信処理は、比較例のホストノードＨと同様に、アプリケーションプログラム１１０が書込みＡＰＩ部１５２をコールする（呼出す）ことで駆動される（ステップＳ８０１）。
本実施例の構成では、書込みＡＰＩ部１５２の呼出しを、書込みＡＰＩ呼出し捕捉部１６２により捕捉して（ステップＳ８０２）、書込み送信処理として次の処理を行う。
まず、複製部１７２が送信データを複製して、複製データを転送部１７４に渡す。転送部１７４は、渡されたデータを、予備クラスタメンバへ送る（ステップＳ８０３）。この複製データの送信は、クラスタメンバ間の専用の通信機構、共有メモリ、あるいはアプリケーションプログラム１１０が通信に用いる読み書き用のＡＰＩを利用して行う。さらに、予備クラスタメンバから、データの書込み結果が送られてくるため、その結果の受信を待つ（ステップＳ８０４、Ｓ８０５）。書込み結果は、クラスタメンバ間の専用の通信機構、共有メモリ、あるいはアプリケーションプログラム１１０が通信に用いる読み書き用のＡＰＩ（図示せず）を利用して送られてくる。
転送部１７４は、書込み結果を受信すると、それを複製部１７２に渡す。複製部１７２は、書込み結果が書込み失敗を示している場合（ステップＳ８０６がＮＯ）は、送信データを破棄してアプリケーションプログラム１１０にそのことを通知する（ステップＳ８０７）。これに対して、書込み成功を示している場合（ステップＳ８０６がＹＥＳ）は、プロトコル処理部１２ｋ内のバッファにデータが書込み可能であれば直ちに、書込み不可能であれば書込み可能になるのを待って、送信データをプロトコル処理部１２ｋに渡す（ステップＳ８０８〜Ｓ８１０）。これ以降は、プロトコル処理部１２１、１２２、…、１２ｋにおいて、ステップＳ７０５、Ｓ７０６と同様の処理が行われ（ステップＳ８１１、Ｓ８１２）、最終的に、送信インタフェース１４２からデータリンク４へ送信データが送出される（ステップＳ８１３）。
次に予備系での動作を説明する。図９は、本実施例における書込み送信処理の内、予備系側の動作を示した流れ図である。予備系では、読込み処理の場合と同様に、書込み送信処理はアプリケーションプログラムが駆動するのではなく、クラスタ処理自身が駆動する。
転送部１７４は、現用系からの送信データ（複製データ）の到着を待っており、送信データが到着すると、それを書込み部１７２へ渡す（ステップＳ９０１）。
書込み部１７２は、書込みＡＰＩ部１５２を呼出して送信データを渡す。これにより、書込みＡＰＩ部１５２は、プロトコル処理部１２ｋ内のバッファが書込み可能か否かを調べ、書込み可能であれば直ちに、書込み不可能であれば書込み可能となるのを待って、プロトコル処理部１２ｋに送信データを渡す（ステップＳ９０２〜Ｓ９０４）。
これによりプロトコル処理部１２１、１２２、…、１２ｋにおいて送信データの書込み処理（プロトコル処理）が行われる（ステップＳ９０５）。その後、書込み部１７２が、プロトコル処理部１２１、１２２、…、１２ｋからの応答（関数コールからのリターンや、コールバックルーティンの呼出しなど）に基づいて、送信データの書込みが成功したか否かを示す書込み結果を作成し、現用クラスタメンバへ送信する（ステップＳ９０６）。この書込み結果の送信は、クラスタメンバ間の専用の通信機構、共有メモリ、あるいはアプリケーションプログラム１１０が通信に用いる読み書き用のＡＰＩ等を利用して行う。
なお、上記読み書き用のＡＰＩを利用して書込み結果を現用系に通知する場合には、その宛先を現用系のＩＰ／ＭＡＣアドレスとし、送信インタフェース１４２において、書込み結果が破棄されないようにする。即ち、予備系の送信側振り分けフィルタ１３２は、現用系宛のパケットは、送信インタフェース１４２を介してデータリンク４へ送出し、それ以外のパケットは、破棄するように構成されている。また、ステップＳ９０５では、現用系から受け取った送信データの複製データの内、一部しか書込めなかった場合には、すべてのデータが書込めるまで、書込み処理を続ける。ただし、予め指定された時間書込み処理を続けても、書込み処理が終わらないときは、該処理とりやめて、結果を失敗としても良い。
図１０は、以上の現用系と予備系の動作をまとめたシーケンス図である。現用系のアプリケーションプログラムが書込んだ送信データは、書込みＡＰＩ部１５２の直下で複製され、両方の系のプロトコル処理部を通って冗長に処理される。同一のデータが正常に送信処理された場合に限り、現用系のアプリケーションに成功が通知される。これにより、冗長処理が実現される。
また、現用系の書込み処理よりも、予備系の書込み処理を先に行うのは、次に説明するような、本実施例の冗長処理の特徴と、ＴＣＰなどのプロトコル動作のためである。
本発明の冗長化方式では、現用系で送出処理を行った送信データは、実際に送出されるが、予備系で送出処理を行った送信データは、送出直前に破棄する。これにより、データの重複した送出を防いでいる。
一方、ＴＣＰやＳＣＴＰなどの、データの伝送を保証するプロトコルでは、送信データに対して、送達確認応答が対向ノードから送られてくる。この応答の受信により、送信データが到達したことがわかるため、該プロトコルは送信バッファに保持していたデータを削除できる。一方、応答が到達しなければ、送信データを再送し続ける必要がある。
本実施例の予備系で送信処理を行うと、予備系の動作により、パケットはプロトコルでは処理されるものの実際には送出されないため、対向ノードから確認応答が到着することはない。
一方、現用系で送信処理を行ってしまうと、実際に送信データが対向ノードに送られるため、応答が返ってくることになる。
ここで、応答メッセージはクラスタシステム宛てに送信されるため、現用系と予備系の両方に到達する。
現用系で先に送信処理を行えば、予備系で送信処理を行う前に、予備系に応答が到達する可能性がある。送信していないデータに対する応答は破棄されるため、この場合、予備系は該当応答を破棄する。
その後予備系が送信処理を行っても、送信データは実際には送出されず、従って該当データには応答も到達しないため、いつまでも送達確認が行えないことになる。以上のことから、現用系よりも先に予備系で送信処理が行われる機会を増やすため、現用系よりも先に予備系で書き込み処理を行う。
〔その他の処理〕
読込み、書込みに加えて、通信のＡＰＩ群には、エンドポイントの生成やセッションの開設などの通信の制御用ＡＰＩが用意されている。
ここでは、主要な通信用ＡＰＩの一つであるバークレイソケットＡＰＩにおける、上記制御用ＡＰＩの冗長化方法を説明する。ｓｏｃｋｅｔ ＡＰＩのうち、エンドポイント生成とセッションの開設に使われる主要なシステムコールを示す。
“ｃｏｎｎｅｃｔ”
“ｂｉｎｄ”
“ｌｉｓｔｅｎ”
“ａｃｃｅｐｔ”
この内、特にセッションの待ち受けを行うサーバ側は、ｂｉｎｄ、 ｌｉｓｔｅｎ、 ａｃｃｅｐｔを、セッションを主体的に開設するクライアント側は、ｃｏｎｎｅｃｔを利用する。これらのＡＰＩを用いた通信プログラムの作成方法は、たとえば「Ｗ．リチャード スティーヴンス （著）、 Ｗ．Ｒｉｃｈａｒｄ Ｓｔｅｖｅｎｓ （原著）、 篠田 陽一 （翻訳）、ＵＮＩＸ（登録商標）ネットワークプログラミング〈Ｖｏｌ．１〉ネットワークＡＰＩ：ソケットとＸＴＩ、ピアソンエデュケーション、 ２０００．」に詳しく説明されている。
以下では、これらの用途に注目して、クライアント側とサーバ側のセッション開設の手順をシーケンス図に基づいて説明する。
以下で説明されている以外のＡＰＩについては、基本的に現用側のＡＰＩがコールされると、そのコール内容が複製されて、予備側でも同一のＡＰＩがコールされ、現用、予備両方でのＡＰＩ呼出しが成功した場合に限って、アプリケーションにはＡＰＩ呼出しの成功が通知される。
〔サーバ側のセッション開設〕
サーバ側では、典型的には、セッション開設手順は次のようになる。
（１） ｂｉｎｄにより自ノードの端点を固定する。
（２） 該当端点で受信待ちができるよう、ｌｉｓｔｅｎシステムコールを発行する。
（３） ａｃｃｅｐｔシステムコールで、クライアントとの間にセッションが確立されるのを待つ。クライアントとのセッションが確立されると、ソケット記述子がセッションごとに新たにつくられて呼出し側へ戻される。以降（３）で得られたソケット記述子で通信を行う。
ここで、アプリケーションは、典型的には、上記３つの手順のためにシステムコールを各々発行する。本発明の方式では、この呼出し手順はそのままにして、各システムコールの呼出しを、読み書きの場合と同様に捕捉して、冗長化のための追加処理を行う。
図１１は、サーバ側のセッション開設シーケンスを示したシーケンス図である。同図を参照すると、先ず、ｂｉｎｄ、 ｌｉｓｔｅｎシステムコールについては、現用系のアプリケーションが呼出しを行うと、制御部が捕捉して予備系へ同処理を依頼する。予備系で同様のシステムコールを発行し、結果を受け取る。ここで、予備系で該当処理が正常に完了した場合には、現用系でも同一のシステムコールを発行する。もし、現用系か予備系のどちらかのシステムコールが異常終了した場合は、現用系でのアプリケーションからの該当システムコールに対して、失敗したことを通知する。以上の処理で、現用／予備両方の系でクライアントノードからのセッション開設要求を受信できるようになる。
次に、ａｃｃｅｐｔシステムコールについては、現用系のアプリケーションが呼出しを行うと、制御部が捕捉してまず現用系で該システムコールを発行する。すると、現用系では、セッションが確立され次第、待ち受け用とは別の通信用ソケット記述子がつくられて呼出し元（この場合は制御部）に戻される。
上記が成功した場合に限り、制御部は予備系に該当処理を行うよう依頼する。予備系でも、該システムコールを発行し、同様に通信用ソケット記述子を受け取って、結果を現用系に伝達する。以上により、現用、予備系ともに、クライアントとの通信用のソケットが作成できた。最後にアプリケーションプログラムに、現用側の通信用ソケット記述子を、システムコールの結果として通知して、セッション開設の処理を終わる。
ここでａｃｃｅｐｔのみ現用系で先にシステムコールを発行するのは、予備系で、現用系の通信用ソケット記述子と、自身の通信用ソケット記述子の対応を記録するためである。
またプロトコルが行うセッション開設は、ａｃｃｅｐｔの発行前であっても行えるようになっている。もし、ａｃｃｅｐｔがコールされる前にセッションが確立されていれば、ｌｉｓｔｅｎにより作成した待ち受けキューにセッションの情報が保持される。この場合、ａｃｃｅｐｔを発行すると直ちに通信用ソケット記述子が得られる。また、ａｃｃｅｐｔを発行した時点でまだセッションが開設されていなければ、セッションが開設されるまで、ａｃｃｅｐｔの呼出しはブロックされる。
このようにすることにより、複数のソケット記述子を利用するアプリケーションであっても、現用系と予備系の通信時に、処理対象のソケットＡＰＩを受け渡すことで、混乱なく冗長処理を行うことができ、さらに、予備系でａｃｃｅｐｔの呼出しが遅くなることがあっても、現用／予備両方でセッションを確立することができる。
また、上記手順はＴＣＰ〔ＲＦＣ ７９３、 Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ． Ｊ． Ｐｏｓｔｅｌ． Ｓｅｐｔ， １９８１．参照〕やＳＣＴＰ〔ＲＦＣ ２９６０、 Ｓｔｒｅａｍ Ｃｏｎｔｒｏｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｐｒｏｔｏｃｏｌ． Ｒ． Ｓｔｅｗａｒｔ， Ｑ． Ｘｉｅ、 Ｋ． Ｍｏｒｎｅａｕｌｔ， Ｃ． Ｓｈａｒｐ、 Ｈ． Ｓｃｈｗａｒｚｂａｕｅｒ， Ｔ． Ｔａｙｌｏｒ， Ｉ． Ｒｙｔｉｎａ， Ｍ． Ｋａｌｌａ， Ｌ． Ｚｈａｎｇ， Ｖ． Ｐａｘｓｏｎ． Ｏｃｔｏｂｅｒ ２０００．参照〕等のコネクション指向プロトコルでのセッションの確立の場合で、ＵＤＰ〔ＲＦＣ ７６８， Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ． Ｊ． Ｐｏｓｔｅｌ． Ａｕｇ， １９８０．参照〕等のコネクションレスプロトコルの場合には、上記（１）の手順を行った直後から読込み処理が開始される。この場合は、ｂｉｎｄの処理のみ上記の手順で冗長化される。
〔クライアント側のセッション開設〕
クライアント側では、典型的には、セッション開設はｃｏｎｎｅｃｔシステムコールの発行により行う。同システムコールを発行すると、自ノード側端点を固定して、対向端点との間でセッション確立を行うようプロトコルに依頼し、セッション確立の結果をもって呼出しが戻るようになっている。
クライアント側のセッション開設を冗長化するには、ｃｏｎｎｅｃｔシステムコールの処理を冗長化する。
図１２は、クライアント側のセッション開設シーケンスを示したシーケンス図である。同図を参照すると、先ず、現用系のアプリケーションプログラムがｃｏｎｎｅｃｔシステムコールの呼出しを行うと、制御部がそれを捕捉する。
ここで、まず自ノード側の端点を固定する処理を行う。これは、通常のｃｏｎｎｅｃｔ呼出しでは、自ノード側の端点を指定せず、プロトコル側で適宜端点のポート番号が選ばれるが、本実施例の冗長構成の場合は、現用系と予備系で、同一の端点をつくるために同じポート番号の割り当てを要するためである。
自ノード側端点の固定には、サーバ側で説明したｂｉｎｄシステムコールを使う。このため、ｂｉｎｄシステムコールの冗長化処理と同様の処理を先ず行って、現用、予備両方の自ノード側端点を同一の状態にする。
上記が成功したら、続いて対向端点に対してセッションを確立する。先ず、予備系側で、非同期モードでｃｏｎｎｅｃｔシステムコールを発行する。非同期モードでは、コネクションの確立が終了しなくても、ｃｏｎｎｅｃｔシステムコールの処理は一旦終了する。これによって、予備系のプロトコルはセッション開設中の状態になり、プロトコルがＴＣＰの場合にはＳＹＮフラグを設定したセグメントの送出処理などが行われる（ただしパケットは送出される前に破棄される）。非同期モードにするのは、予備系では実際にはパケットが送出されないために、セッション確立処理が進行せず、ｃｏｎｎｅｃｔシステムコールが通常では終了しなくなるためである。
次に、現用系側でｃｏｎｎｅｃｔシステムコールを発行して、セッション確立処理を実際に行う。現用系でセッション確立処理を行うと、実際にパケットが送出され、セッションが確立される。このとき、予備系では対向端点からの応答待ちの状態のため、対向端点から応答が来れば、予備系のセッション確立処理が進行する。以上により、現用／予備両方の系でセッションが冗長に確立される。
〔系切り替え処理〕
現用系が故障した場合に、処理を予備系に切り替えるフェイルオーバ処理を説明する。
現用系の死活を、別途定められた手順にしたがって監視する。監視手順の具体例としては、たとえば次のような方式が考えられる。なお次に説明する方式は、実現の一例であって、これ以外にも現用系の稼働を監視できる方式があれば、それを採用しても良い。
まず、現用系装置内部に、現用系の各部分の動作が正常かどうか監視する現用監視部を設ける。次に、該当監視部が、該動作情報を、一定間隔で予備クラスタメンバの現用監視部へ送信するようにする。
現用監視部は、該当動作情報に異常を検知したことが示されているか、または、最後に該動作情報を受信してから、所定の時間だけ経過しても次の該動作情報が届かないときなどは、現用が故障したと判断する。
次に、現用監視部が故障を検知すると、切替通知部が、予備系のアプリケーションプログラムと切替制御部へ故障の発生を通知する。これにより、待機していた予備系のアプリケーションプログラムは、現用系のアプリケーションプログラムに代わって動作を開始する。
また、切替制御部は、書込み部と照合部の動作を変更する。書込み部は、書込みＡＰＩ呼出し捕捉部を経由してアプリケーションプログラムが発行する書込みＡＰＩ呼出しを、書込みＡＰＩにそのまま伝達するように動作する。照合部も、読込みについて同様の処理を行う。以上により、予備系はスタンドアロンのホストノードと同様の動作をするようになる。
また、現用監視部の機能はアプリケーションプログラム等が独自に実装してもよい。この場合は、現用監視部は省いて、切替通知部には、アプリケーションプログラムから現用の故障を通知するように動作する。
〔実施例１の効果〕
本実施例によれば、ＯＳを大幅に変更することなく、アプリケーションプログラムが動作するブロードキャスト・ディスパッチ方式のクラスタメンバを冗長化し、信頼性を向上させることができる。その理由は、アプリケーションプログラム１１０と読込み、書込みＡＰＩ部１５１、１５２との間に、読込みＡＰＩ呼出し捕捉部１６１、書込みＡＰＩ呼出し捕捉部１６２、複製部／照合部１７１、複製部／書込み部１７２、制御部１７３、転送部１７４を備える構成を採用したからである。即ち、上記各部は、ＯＳの外部に設けることができるので、ＯＳを変更することなく、アプリケーションプログラムが動作するクラスタメンバを冗長化することが可能になる。
〔本発明の実施例２〕
本発明の実施例２は、アプリケーションプログラムが稼働するクラスタメンバを複数備えたブロードキャスト・ディスパッチ方式のクラスタシステムにおいて、プロトコル処理に対する負荷分散とアプリケーション処理に対する負荷分散とを異なるポリシーで行えるようにしたことを特徴とする。
本実施例のおおまかな構成と、動作の一例を図１３Ａ、１３Ｂに示す。同図１３Ａ、１３Ｂを参照すると、クラスタシステムは、４台のクラスタメンバにより構成され、各々、従来のブロードキャスト・ディスパッチ方式のクラスタメンバと同様にハッシュを利用したフィルタを備えている。更に、各々のクラスタメンバはアプリケーションプログラムを備えており、プロトコル処理部とアプリケーションプログラムの間に、ハッシュを用いた振り分け部を備えている。
振り分け部では、プロトコル処理用と、アプリケーション処理用の、二つのハッシュ関数を用いて、送信方向、受信方向のトラフィックを処理すべきクラスタメンバを再計算し、必要に応じて他のクラスタメンバにトラフィックを送り直す作業を行う。これにより、プロトコル処理部とアプリケーションプログラムが異なる分散方法で分散されたトラフィックを処理できるようになる。
受信側については、プロトコル処理部までは、従来のブロードキャスト・ディスパッチ方式のクラスタシステムと同様に処理を行う。アプリケーションプログラムに受信データが受け渡される前に、振り分け部がアプリケーション処理の担当クラスタメンバを決める。これは、パケットに含まれていたアプリケーション用データ（通常、ペイロードとして含まれている）に、アプリケーション処理用の、プロトコル用とは別のハッシュ関数を適用して、ハッシュ値を算出し、該当ハッシュ値が割り当てられているクラスタメンバを判定することにより行う。
図１３Ａの例では、パケット受信クラスタメンバとアプリケーション処理クラスタメンバが異なるため、振り分け部で受信データを転送して、アプリケーションプログラムに受け渡している。これにより、プロトコル処理がどのクラスタメンバで行われているか、アプリケーションプログラムは意識することなく、パケットを受信できる。
送信方向については、アプリケーションプログラムが送信したデータを、正しいプロトコル担当クラスタメンバに通すようにする処理を行う。振り分け部は、プロトコル処理担当クラスタメンバを決めるため、パケット受信直後に使っている受信側フィルタと同様のハッシュ関数を用いて、処理クラスタメンバを計算する。図１３Ｂの例では、アプリケーションプログラムが送信データを書込み、プロトコル処理部に渡る前に、振り分け部で受信データを転送している。このため、プロトコル処理部では、他のクラスタメンバのアプリケーションプログラムと通信していることを意識せずに送信処理を行うことができる。
〔実施例２の構成の説明〕
図１４は本発明にかかるクラスタシステムの実施例２を示すブロック図である。同図を参照すると、本実施例のクラスタシステム１ａは、複数のデータリンク４１、４２、…、４ｍに接続された複数台のクラスタメンバ１００ａ−１〜１００ａ−ｎにより構成されている。各データリンク４１、４２、…、４ｍにはクラスタシステム１ａの全クラスタメンバ１００ａ−１〜１００ａ−ｎと、複数台のノード３１−１〜３ｍ−ｚとが接続されている。
ここで、同一データリンクに接続する全クラスタメンバには、同一の代表ＭＡＣアドレスが割り当てられている。このＭＡＣアドレス宛てに隣接ノードがパケットを送信すれば、全クラスタメンバに到達するよう、各クラスタメンバの受信インタフェースが設定されている。一方、クラスタメンバ間の通信などのために、各クラスタメンバに一意なＭＡＣアドレスも割り当てられている。このアドレスを利用すれば、クラスタシステム１ａの中のクラスタメンバを特定して１対１の通信を行うこともできる。
図１５にクラスタメンバ１００ａ−１の構成例を示す。本実施例のクラスタメンバ１００ａ−１と、図１に示した実施例１のクラスタメンバ１００との相違点は、複製部／照合部１７１の代わりにアプリケーション処理振り分け部１８１を備えている点と、複製部／書込み部１７２の代わりにプロトコル処理振り分け部１８２を備えている点である。なお、他のクラスタメンバ１００ａ−２〜１００ａ−ｎもクラスタメンバ１００ａ−１と同様の構成を有している。
このうち、プロトコル処理振り分け部１８２は、送信データの処理対象クラスタメンバを、プロトコルデータの内容に基づいて判定する処理を行う。プロトコル処理振り分け部１８２は、その内部に、受信側振り分けフィルタと同様の振り分け規則により、送信データのハッシュ値を計算する手段（図示せず）を備えている。さらに加えて、ハッシュ値の各クラスタメンバへの割り振り表（図示せず）も備えている。すなわち、単に自身に割り振られたハッシュ値だけではなく、他のクラスタメンバにどのようなハッシュ値が割り振られているかをも判定できる。
アプリケーション処理振り分け部１８１は、受信データの処理対象クラスタメンバを、アプリケーションデータ（最上位のプロトコル処理部１２ｋによる処理が済んだ、アプリケーションプログラム１１０に渡すデータ）の内容に基づいて判定する処理を行う。プロトコル処理振り分け部１８２と同様に、アプリケーション処理振り分け部１８１も、その内部に、アプリケーション用振り分け規則に基づいて受信データがどのクラスタメンバで処理されるべきか判定できる手段を備えている。
このような機能を有するクラスタメンバ１００ａ−１は、コンピュータによって実現可能であり、コンピュータによって実現する場合には、例えば次のようにする。コンピュータとクラスタメンバ１００ａ−１として機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って、自身の動作を制御することにより、自コンピュータ上に、プロトコル処理部１２１、１２２、…、１２ｋと、受信側振り分けフィルタ１３１と、送信側振り分けフィルタ１３２と、フィルタ制御部１３３と、受信インタフェース１４１と、送信インタフェース１４２と、読込みＡＰＩ部１５１と、書込みＡＰＩ部１５２と、読込みＡＰＩ呼出し捕捉部１６１と、書込みＡＰＩ呼出し捕捉部１６２と、制御部１７３と、転送部１７４と、アプリケーション処理振り分け部１８１と、プロトコル処理振り分け部１８２とを実現する。
〔実施例２の動作の説明〕
次に、本実施例の動作について詳細に説明する。
〔受信と読込みの処理〕
先ず、図１６Ａ、１６Ｂを参照してプロトコルのパケット受信処理と、アプリケーションプログラムの受信データ読込み処理について説明する。読込みのクラスタ処理部分は後述する。
本実施例では、受信データは全クラスタメンバ１００ａ−１〜１００ａ−ｎへ同報されるため、処理対象か否かによらず、全クラスタメンバ１００ａ−１〜１００ａ−ｎにクラスタシステム１ａの処理対象パケットが届く。
図１６Ａを参照すると、受信側振り分けフィルタ１３１は、受信インタフェース１４１を介してパケットを受信すると、先ず、パケットをクラスタシステム１ａの代表ＭＡＣアドレス宛か否かにより振り分ける（ステップＳ１６０１、Ｓ１６０２）。ここで、受信する可能性があるパケットは、次の３種類である。
・通信先から直接受信した、宛先がクラスタシステム１ａの代表ＭＡＣアドレスになっているパケット。
・他のクラスタメンバから送られてきた、宛先が自クラスタメンバのＭＡＣアドレスになっている、受信データを含むパケット。
・他のクラスタメンバから送られてきた、宛先が自クラスタメンバのＭＡＣアドレスになっている、送信データを含むパケット。
そして、クラスタシステム１ａの代表ＭＡＣアドレス宛てでないパケットは、クラスタ処理が不要であるため、ステップＳ１６０３、Ｓ１６０４の振り分け処理を飛ばしてプロトコル処理に回す（ステップＳ１６０５〜１６０７）。
クラスタシステム１ａの代表ＭＡＣアドレス宛てのパケットについては、受信側振り分けフィルタ１３１において、パケットのヘッダ等に所定のハッシュ関数を適用することにより、ハッシュ値を計算する（ステップＳ１６０３）。
ハッシュ関数は、たとえば、ＩＰヘッダの送信元と宛先のアドレスを各々４バイト整数値とみなして、それらの和を取り、さらに所定の正数の剰余を計算するような処理が典型的である。ただし、全トラフィックをクラスタの各クラスタメンバにすきまなく分配できるような計算方法であれば、ハッシュ関数はどんなものであっても良い。
次に、受信側振り分けフィルタ１３１にて、上記で計算したハッシュ値が、予めこのクラスタメンバに割り当てられた整数値と等しいかどうかを判定する（ステップＳ１６０４）。この整数値の割り当ては、従来のブロードキャスト・ルータクラスタと同様である。割り当てハッシュ値と異なる計算結果になったパケットは破棄し（ステップＳ１６０８）、割り当てハッシュ値と計算結果が一致したパケットのみ受信側振り分けフィルタ１３１を通過させる（ステップＳ１６０５）。
受信側振り分けフィルタ１３１を通過したパケットは、低レイヤのプロトコル処理部１２１から高レイヤのプロトコル処理部１２ｋまで順に処理されながら受け渡される（ステップＳ１６０５、Ｓ１６０６）。
最上位層のプロトコル処理部１２ｋは、プロトコル処理が終わると、読込みＡＰＩ部１５１経由でアプリケーションプログラム１１０が受信データを受け取れるようにするため、読込みＡＰＩ部１５１に対して読込み可能になったことを通知する（ステップＳ１６０７）。
一方、図１６Ｂに示したように、アプリケーションプログラム１１０は、読込みＡＰＩ部１５１を経由して受信データを読込むため読込みＡＰＩ部１５１を呼出す。本実施例では、この呼出しを、読込みＡＰＩ呼出し捕捉部１６１により捕捉して（ステップＳ１６０９、Ｓ１６１０）、読込み・リダイレクト処理を行う（ステップＳ１６１１）。
ここで、ステップＳ１６１１で行う読込み・リダイレクト処理について図１７Ａ、１７Ｂの流れ図を参照して詳しく説明する。まず、読込みＡＰＩ呼出し捕捉部１６１は、読込みＡＰＩ部１５１から受信データを読込む。ただし、受信データがなければ、これも従来と同様に受信データが用意できるまで読込み処理をブロックする（ステップＳ１７０１、Ｓ１７０２）。
受信データが読込めたら、それをアプリケーション処理振り分け部１８１に渡す。アプリケーション処理振り分け部１８１は、それが他のクラスタメンバからリダイレクトされて送られてきたデータかどうかを、データの送信元等から判別する（ステップＳ１７０３）。
リダイレクトされたデータでなければ、アプリケーションプログラム１１０の通信相手から直接受け取った受信データである。このデータは、プロトコルの処理が終わってそのまま読込みＡＰＩ部１５１を通して上がってきたものであり、アプリケーションプログラムに対する分散方法としてプロトコルとは別の分配方法を適用するため、アプリケーション処理振り分け部１８１は、アプリケーションプログラム１１０から与えられたハッシュ関数を使って、受信データのハッシュ値を計算し直す（ステップＳ１７０５）。
計算結果が自クラスタメンバに割り当てられたハッシュ値と等しければ、処理対象アプリケーションプログラムは、自クラスタメンバで動作していることになるため、読込みＡＰＩ呼出し捕捉部１６１を経由して、パケットをアプリケーションプログラム１１０に渡す（ステップＳ１７０６がＹＥＳ、Ｓ１７０７）。
計算結果が割り当て値と異なれば、処理対象アプリケーションプログラムは他のクラスタメンバで動作していることになる。ハッシュ値がどのクラスタメンバに割り当てられているかは予め与えられており、その割り当てを参照して、処理対象クラスタメンバへ該当受信データを送り直す（ステップＳ１７０６がＮＯ、Ｓ１７０８）。
このために、受信データを転送部１７４に渡し、転送部１７４は、処理対象アプリケーションプログラムが動作しているクラスタメンバを宛先として、受信データをＵＤＰデータグラムなどにカプセル化し、さらに、受信データである旨の情報を添付して、該当データの書込み処理を行う（ステップＳ１７０９〜Ｓ１７１４）。そして、最終的には、受信データを含むパケットが、送信インタフェース１４２からデータリンクに送出される（ステップＳ１７１５）。以上で、アプリケーションプログラム１１０の通信相手から直接受け取った受信データの処理ができる。
受信データが他のクラスタメンバからリダイレクトされてきたものである場合は、さらに、それが元々受信データであった場合と、送信データであった場合に分けられる。受信データであるかどうかは、リダイレクト時に受信データである旨の情報が添付されていることで判別できる。
受信データであれば（ステップＳ１７０４がＹＥＳ）、他のクラスタメンバが該データに対するハッシュ値を計算した結果、このクラスタメンバがアプリケーション処理を担当していると判断したことになるため、読込みＡＰＩ呼出し捕捉部１６１を経由して、受け取った受信データをアプリケーションプログラム１１０に渡す（ステップＳ１７０７）。
送信データである場合（ステップＳ１７０４がＮＯ）は、前述したステップＳ１７０９〜Ｓ１７１５の処理を行う。なお、後述するように、リダイレクトされた送信データには、リダイレクト時に送信データである旨の情報が付加されているので、この情報に基づいて送信データであるか否かを判別することができる。
〔書込み送信処理〕
次に、書込み送信処理について図１８Ａ、１８Ｂの流れ図を参照して説明する。アプリケーションプログラム１１０が書込みＡＰＩ部１５２を呼出すと、書込みＡＰＩ呼出し捕捉部１６２がこの呼出しを捕捉して、アプリケーションプログラム１１０からの送信データをプロトコル処理振り分け部１８２に渡す（ステップＳ１８０１、Ｓ１８０２）。
これにより、プロトコル処理振り分け部１８２は、書込みＡＰＩ呼出し捕捉部１６２から渡された送信データに対してプロトコル処理用のハッシュ関数を適用し、ハッシュ値を計算する（ステップＳ１８０３）。
そして、計算結果が、自クラスタメンバに割り当てられた値と等しければ、送信データのプロトコル処理担当クラスタメンバは自クラスタメンバであるため、書込みＡＰＩ部１５２を経由して、送信データをプロトコル処理部１２ｋに渡す（ステップＳ１８０４がＹＥＳ、Ｓ１８０６〜Ｓ１８０８）。なお、プロトコル処理部１２ｋが書込み可能な状態になっていない場合は、書込み可能な状態になるのを待ってから送信データを渡す。その後、最上位層のプロトコル処理部１２ｋから順にプロトコル処理が行われ、最終的には、送信インタフェース１４２を介してパケットがデータリンクに送出される（ステップＳ１８０９〜Ｓ１８１２）。
これに対して、計算結果が割り当て値と異なれば（ステップＳ１８０４がＮＯ）、送信プロトコル処理の担当クラスタメンバはこのクラスタメンバ自身ではない。受信の場合と同様に、ハッシュ値がどのクラスタメンバに割り当てられているかは予め与えられており、その割り当てを参照して、処理対象クラスタメンバへ該当送信データを送る。
そのために、プロトコル処理振り分け部１８２は、送信データを転送部１７４に渡し、転送部１７４は、処理対象クラスタメンバを宛先として、送信データをＵＤＰデータグラムなどにカプセル化し、更に、送信データである旨の情報を添付して、該当データの書込み処理を行う（ステップＳ１８０５〜Ｓ１８１１）。そして、最終的には、送信インタフェース１４２を介してパケットがデータリンクへ送出される（ステップＳ１８１２）。
〔その他の処理〕
実施例１と同様、読込み、書込み以外のＡＰＩについての動作を説明する。ここでは、主要な通信用ＡＰＩの一つであるバークレイソケットＡＰＩにおける、上記制御用ＡＰＩを、本実施例の方法でクラスタ化する方法を説明する。実施例１と同様に、バークレイソケットＡＰＩの、サーバ側およびクライアント側での典型的な用法に基づいてセッション開設処理のシーケンス図に基づいて手順を説明する。
〔サーバ側のセッション開設〕
サーバ側のセッション開設には、ｂｉｎｄ、 ｌｉｓｔｅｎ、 ａｃｃｅｐｔの三つのシステムコールが主に使われる。これらのシステムコールのクラスタ化処理を順に説明する。
図１９は、サーバ側のセッション開設処理のうち、ｂｉｎｄ、 ｌｉｓｔｅｎまでの処理の流れを示したシーケンス図である。同図を参照すると、ｂｉｎｄ、 ｌｉｓｔｅｎとも、いずれかのクラスタメンバのアプリケーションプログラムが最初に呼出しを行うと、その呼出しが全クラスタメンバに伝達され、システムコールが発行される（図１９では、クラスタメンバ１が最初にｂｉｎｄ、 ｌｉｓｔｅｎを発行している）。これにより、全クラスタメンバに端点が作成され、クライアントからのセッション開設要求を受け付けられるようになる。２番目以降にＡＰＩ呼出しを行ったアプリケーションプログラムには、単に成功した旨の結果が通知される。これは、他のアプリケーションプログラムからの指示で、すでに該処理が行われているためである。
図２０は、サーバ側のセッション開設処理のうち、ａｃｃｅｐｔの処理の流れを示したシーケンス図である。同図を参照すると、ａｃｃｅｐｔシステムコールは、いずれかのクラスタメンバのアプリケーションプログラムが最初に呼出しを行うと、その呼出しが全クラスタメンバに伝達され、システムコールが発行される。（図２０ではクラスタメンバ１が最初にａｃｃｅｐｔを呼出している）これにより、どのクラスタメンバのプロトコル処理部でセッションが開設されても、通信用のソケット記述子が作成されて、該当クラスタメンバのプロトコル処理部で通信ができる状態になる。
通信が可能になると、実際に受信データが到着するので、到着したトラフィックを各クラスタメンバのアプリケーションプログラムへ振り分ける、読込み処理が行われることになる。
ただし、この時点では、クラスタメンバによっては、まだアプリケーションプログラムがａｃｃｅｐｔを呼出していない場合がある。アプリケーションプログラムは、互いに異なるマシンで動作しており、処理の進捗が一致しない場合があるためである。ａｃｃｅｐｔを呼出していないアプリケーションプログラムは、セッション開設の待ち受けをまだしていないため、そのクラスタメンバへ受信データ処理を振り分けても、読込み処理を行うことができない。
これを避けるために、ハッシュ値のクラスタメンバへの割り振り表には、アプリケーションプログラムがａｃｃｅｐｔを実行した時点で、該アプリケーションプログラムが動作しているクラスタメンバのエントリを追加するようにする。
他のクラスタメンバのアプリケーションプログラムが２番目以降にａｃｃｅｐｔの呼出しを行うと、単に、このハッシュ値割り振り表へのエントリの追加のために、他のクラスタメンバに該呼出しが通知される（図２０では、クラスタメンバ２やクラスタメンバＮがａｃｃｅｐｔを呼出した場合が該当する）。以上により、セッションが開設されれば、待ち受けしているアプリケーションプログラムの中から処理担当クラスタメンバが選択され、トラフィックが該当クラスタメンバへ送られる。
また、上記手順はコネクション指向プロトコルでのセッションの確立の場合で、コネクションレスプロトコルの場合には、ｂｉｎｄの処理のみ上記の手順で冗長化される。ｂｉｎｄが終了したアプリケーションプログラムは直ちにデータを受信可能となるため、コネクションレスプロトコルを使うアプリケーションプログラムでは、ｂｉｎｄ終了直後に、ハッシュ値のクラスタメンバ割り振り表へ該アプリケーションプログラムが動作しているクラスタメンバのエントリを追加する。
〔クライアント側のセッション開設〕
クライアント側では、典型的には、セッション開設はｃｏｎｎｅｃｔシステムコールの発行により行う。同システムコールを発行すると、自ノード側端点を固定して、対向端点との間でセッション確立を行うようプロトコルに依頼し、セッション確立の結果をもって呼出しが戻るようになっている。
図２１は、クライアント側のセッション開設シーケンスを示したシーケンス図である。同図を参照すると、まず、セッション開設を行うアプリケーションプログラムがｃｏｎｎｅｃｔシステムコールの呼出しを行うと、制御部がそれを捕捉する。
ここで、まず自ノード側の端点を固定する処理を行う。これは、通常のｃｏｎｎｅｃｔ呼出しでは、自ノード側の端点を指定せず、プロトコル側で適宜端点のポート番号が選ばれるが、本実施例の場合は、端点が固定されていないと、プロトコル処理の担当クラスタメンバの計算に必要な、ハッシュ関数の引数がそろわない可能性があるためである。
プロトコル処理振り分け用のハッシュ関数は、典型的には、プロトコルヘッダ等に含まれるアドレスやポート番号を利用する。対向端点は、ｃｏｎｎｅｃｔ呼出しの引数としてアプリケーションプログラムから与えられるが、端点を固定しないと、上記の情報が得られないため、まず自ノード側端点を制御部が決定する。
次に、プロトコル処理担当クラスタメンバを決定し、該当クラスタメンバにセッション開設要求を伝達する。図２１の例では、クラスタメンバ１のアプリケーションプログラムがｃｏｎｎｅｃｔを呼出し、プロトコル処理の担当はクラスタメンバ２に決定された。プロトコル処理担当クラスタメンバでは、まず自ノード側端点をｂｉｎｄシステムコールにより固定し、続いてｃｏｎｎｅｃｔシステムコールを発行して、実際にセッションの開設を行う。上記処理の結果をｃｏｎｎｅｃｔ呼出し元のクラスタメンバに通知して、セッション開設の処理が終わる。
〔実施例２の効果〕
本実施例によれば、アプリケーションプログラムが動作するブロードキャスト・ディスパッチ方式のクラスタシステムにおいて、負荷分散を行う際に、同一トラフィックに対するアプリケーション処理とプロトコル処理とを異なるクラスタメンバに行わせることが可能になる。その理由は、アプリケーションプログラム１１０と読込み、書込みＡＰＩ部１５１、１５２との間に、読込みＡＰＩ呼出し捕捉部１６１、書込みＡＰＩ呼出し捕捉部１６２、制御部１７３、転送部１７４、アプリケーション処理振り分け部１８１、プロトコル処理振り分け部１８２を備える構成を採用したからである。
〔本発明の実施例３〕
本実施例は、実施例１と２を組み合わせて、トラフィックによる処理負荷を複数のクラスタメンバに分散させることでシステム全体の性能を高め、さらに、トラフィックを冗長に処理することで信頼性をも高めたことを特徴とする。
本実施例のおおまかな構成と、動作の一例を図２２及び図２３に示す。図２２は受信動作、図２３は送信動作の例である。
図２２を参照すると、実施例２の場合と同様に、クラスタメンバはパケットフィルタと振り分け・冗長処理部を備えている。ただし、振り分け・冗長処理部は単にハッシュ値を用いてアプリケーション処理の担当クラスタメンバを決めるだけでなく、冗長処理も行う。
プロトコル処理の担当を決めるハッシュ値の割り当ては、本実施例ではクラスタメンバ当たり２個になっている。片方は現用処理用のハッシュ値、他方は予備処理用である。あるハッシュ値について、現用処理担当と予備処理担当のクラスタメンバが１台ずつ存在する。
ブロードキャストされたトラフィックは、全クラスタメンバで受信された後、ヘッダ等から計算されるハッシュ値に従って現用と予備の２台のクラスタメンバで処理される。プロトコル処理が冗長に行われた後、アプリケーションプログラムに受信データが渡る前にデータの照合処理が行われる。その後アプリケーションプログラムが定義したハッシュ関数に従ってアプリケーション処理クラスタメンバが決定され、必要であれば担当クラスタメンバへ受信データがリダイレクトされる。これにより、アプリケーションプログラムは、プロトコル処理がどのクラスタメンバで行われたか、さらに、プロトコル処理が冗長化されているかどうかも意識せずにデータを受信できる。
図２３の構成は図２２の場合と同じであり、トラフィックの向きだけが異なっている。アプリケーションプログラムが送信データをＡＰＩを通して書込むと、まず振り分け処理においてプロトコル処理担当のクラスタメンバを決めるためにハッシュ値が計算される。ここで、一つのハッシュ値をもつクラスタメンバは２台ある（現用担当と予備担当）ため、パケットは複製されて各々のクラスタメンバに必要に応じてリダイレクトされる。以上により、アプリケーションプログラムは送信データがどのクラスタメンバでプロトコル処理されるか、さらに、プロトコル処理が冗長化されているかどうかも意識せずにデータを送信できる。
〔実施例３の構成の説明〕
本実施例は、図１４に示すようなクラスタシステムにおいて、図１５に示す構成を有するクラスタメンバ１００ａ−１〜１００−ｎの代わりに、図２４に示す構成を有するクラスタメンバ１００ｂを用いることにより実現される。
本実施例で使用するクラスタメンバ１００ｂと、図１５に示したクラスタメンバ１００ａ−１との相違点は、アプリケーション処理振り分け部１８１の代わりにアプリケーション処理振り分け及び複製照合部１９１を備えた点と、プロトコル処理振り分け部１８２の代わりにプロトコル処理振り分け及び複製書込み部１９２を備えた点である。
アプリケーション処理振り分け及び複製照合部１９１は、実施例１における受信側冗長処理と、実施例２における受信側振り分け処理に相当する処理を行う。
また、プロトコル処理振り分け及び複製書込み部１９２は、実施例１における送信側冗長処理と、実施例２における送信側振り分け処理に相当する処理を行う。
アプリケーション処理の予備処理は次のような割り当て方法がある。
（１） 全クラスタメンバがアプリケーション処理について現用として動作し、全クラスタメンバがいずれか他のクラスタメンバの予備を担当する。いずれかのクラスタメンバが故障した場合、予備担当クラスタメンバが故障クラスタメンバのアプリケーション処理を引き継ぐ。
（２） 予備担当クラスタメンバを現用クラスタメンバとは別に用意する。このクラスタメンバは、全てのアプリケーション処理の予備クラスタメンバとして振る舞う。通常、予備処理に必要な状態の待避等以外は処理を行わない。
上記の構成部分以外の機能は、第１および実施例２と同様なので説明を略す。
なお、クラスタメンバ１００ｂは、コンピュータによって実現可能であり、コンピュータによって実現する場合は、例えば、次のようにする。コンピュータをクラスタメンバ１００ｂとして機能させるためのプログラムを記録したディスク、半導体メモリ、その他の記録媒体を用意し、コンピュータに上記プログラムを読み取らせる。コンピュータは、読み取ったプログラムに従って自身の動作を制御することにより、自コンピュータ上に、プロトコル処理部１２１、１２２、…、１２ｋと、受信側振り分けフィルタ１３１と、送信側振り分けフィルタ１３２と、フィルタ制御部１３３と、受信インタフェース１４１と、送信インタフェース１４２と、読込みＡＰＩ部１５１と、書込みＡＰＩ部１５２と、読込みＡＰＩ呼出し捕捉部１６１と、書込みＡＰＩ呼出し捕捉部１６２と、アプリケーション処理振り分け及び複製照合部１９１と、プロトコル処理振り分け及び複製書込み部１９２と、制御部１７３と、転送部１７４とを実現する。
〔実施例３の動作の説明〕
次に、本実施例の動作について詳細に説明する。
［受信と読込みの処理］
図２５Ａ、２５Ｂは、本実施例における、プロトコルのパケット受信処理と、アプリケーションプログラムの受信データ読込み処理の動作を示した流れ図である。読込のクラスタ処理部分は後述する。
先ず、図２５ＡのステップＳ２５０１〜Ｓ２５０９について説明する。図２５ＡのステップＳ２５０１〜Ｓ２５０４では、実施例２における図１６ＡのステップＳ１６０１〜Ｓ１６０４と同様の処理が行われ、ステップＳ２５０６〜Ｓ２５０９では、図１６ＡのステップＳ１６０５〜１６０８と同様の処理が行われる。図１６Ａとの相違点は、受信したパケットが、クラスタシステムの代表ＭＡＣアドレス宛のパケットで、且つ受信側振り分けフィルタ１３１で求めたハッシュ値が自クラスタメンバの担当ハッシュ値と等しい場合（ステップＳ２５０２、Ｓ２５０４が共にＹＥＳ）に、ステップＳ２５０５の処理を行う点である。ステップＳ２５０５では、一つのハッシュ値が、現用処理担当クラスタメンバと予備処理担当クラスタメンバとに割り当てられているため、受信パケットがそのどちらに該当するか、ハッシュ値割り当て表から判断して、その情報をパケットに添付する処理を行う。
一方、図２５Ｂに示したように、アプリケーションプログラム１１０は、読込みＡＰＩ部１５１を経由して受信データを読込むため読込みＡＰＩ部１５１を呼出す。本実施例では、この呼出しを、読込みＡＰＩ呼出し捕捉部１６１により捕捉して（ステップＳ２５１０、Ｓ２５１１）、読込み・リダイレクト処理を行う（ステップＳ２５１２）。
図２６Ａ−２６Ｄは、読込時のクラスタ追加処理の動作を示した流れ図である。まず、従来の読込み処理と同様に、読込みＡＰＩ部１５１から受信データを読込む処理を行う。ただし、受信データがなければ、これも従来と同様に受信データが用意できるまで読込み処理をブロックする（ステップＳ２６０１、Ｓ２６０２）。
受信データが読込めたら、まず、それがどの処理に該当するデータかを判別する（ステップＳ２６０３）。本実施例では、受信データは次の７種類ある。
１． 通信相手から直接した受信データ
１．１ 現用処理対象の受信データ
１．２ 予備処理対象の受信データ
２ 照合処理のデータ
２．１ 現用担当クラスタメンバが予備担当クラスタメンバへ送る照合用データ
２．２ 予備担当クラスタメンバが現用担当クラスタメンバへ送る照合結果
３ リダイレクトされたデータ
３．１ プロトコル処理担当クラスタメンバがアプリケーション処理担当クラスタメンバへ送る受信データ
３．２ アプリケーション処理担当クラスタメンバがプロトコル処理担当クラスタメンバへ送る送信データ
３．３ プロトコル処理担当クラスタメンバがアプリケーション処理担当クラスタメンバへ送る書込み通知
パケットがＵＤＰ等でカプセル化されており、照合用データまたはリダイレクトデータを示すフラグがついていれば、それらのデータであることが判別できる。それ以外のデータであれば、通信相手から直接受信したデータであり、予備処理対象データであればそれを示す情報が添付されている。以上により、上記７種類を判別することができる。
以下、各々の場合の処理を説明する。
通信相手から直接受信したデータのうち、現用処理対象であれば、予備処理担当クラスタメンバと受信データを照合する処理を行う。具体的には、まず受信データを複製して（ステップＳ２６０８）、複製データを照合用データとして、転送部１７４経由で予備処理担当クラスタメンバへ送る（ステップＳ２６０９）。ここで、受信データは、照合結果を受け取るまで現用担当クラスタメンバが保持しておく。
通信相手から直接受信したデータのうち、予備処理対象であれば、現用クラスタメンバが送ってくる照合データと受信データの照合を行う。具体的には、受信データを先に受け取った場合（ステップＳ２６１３がＮＯ）、それを保持したまま、照合用データが到着するまで待つ（ステップＳ２６１４）。受信データと照合用データは、該当データが伝送されるコネクションの端点の情報（送信元および宛先のアドレスとポート番号等）により対応付けできるので、その情報も共に保持しておく。データが揃ったら、内容を照合し（ステップＳ２６１５）、照合結果を転送部１７４を用いて現用系へ送り返す（ステップＳ２６１６）。
照合処理用のデータのうち、照合用データを受け取った場合は、それに対応する予備処理対象データが受信されるはずである。もし、すでに受信されていれば（ステップＳ２６１３がＹＥＳ）、ステップＳ２６１５、Ｓ２６１６の処理を行い、まだ受信されていなければ、受信されるまで待ってから、同処理を行う。
照合処理用のデータのうち、照合結果を受け取った場合は、その成否を確認する。照合が失敗した場合は、受信データを破棄して処理を終える（図示せず。ステップＳ２６０４の前に行う）。照合が成功した場合は、保存してあった受信データを処理すべきアプリケーションプログラムが動作しているクラスタメンバをきめるため、アプリケーションプログラムから与えられたハッシュ関数を使って、受信データのハッシュ値を計算し直す（ステップＳ２６０４）。
計算結果がこのクラスタメンバに割り当てられた値と等しければ（ステップＳ２６０５がＹＥＳ）、処理対象アプリケーションプログラムはこのクラスタメンバで動作していることになるため、読込みＡＰＩ呼出し捕捉部１６１を経由して、パケットをアプリケーションプログラム１１０に渡す（ステップＳ２６０６）。
計算結果が割り当て値と異なれば（ステップＳ２６０５がＮＯ）、処理対象アプリケーションプログラムは他のクラスタメンバで動作していることになる。ハッシュ値がどのクラスタメンバに割り当てられているかは予め与えられており、その割り当てを参照して、処理対象クラスタメンバへ該当受信データを送り直す（ステップＳ２６０７）。このために、受信データを転送部１７４に渡し、転送部１７４は、処理対象アプリケーションが動作しているクラスタメンバを宛先として、受信データをＵＤＰデータグラムなどにカプセル化し、さらに、受信データである旨の情報を添付して、該当データの書込み処理を行う。
他のクラスタメンバからリダイレクトされたデータが受信データであれば、他のクラスタメンバが該データに対するハッシュ値を計算した結果、このクラスタメンバがアプリケーション処理を担当していると判断したことになるため、読込みＡＰＩ呼出し捕捉部１６１を経由して、受け取った受信データをアプリケーションプログラムに渡す（ステップＳ２６０６）。
送信データおよび書込み通知である場合の処理は書込み処理の項で説明する。
〔書込みと送信処理〕
図２７Ａ、２７Ｂは、本実施例における書込み処理の動作を示した流れ図である。同図を参照すると、書込み処理は、アプリケーションプログラム１１０が書込みＡＰＩ部１５２をコールすることで駆動される（ステップＳ２７０１）。
本発明の構成では、書込みＡＰＩ部１５２の呼出しを、書込みＡＰＩ呼出し捕捉部１６２により捕捉して、書込み処理として次の処理を行う（ステップＳ２７０２）。
まず、アプリケーションプログラム１１０から書込まれた送信データにプロトコル処理用のハッシュ関数を適用して受信データのハッシュ値を計算し直す。該当ハッシュ値を用いてハッシュ値割り当て表を検索し、該当ハッシュ値の担当クラスタメンバを決定する（ステップＳ２７０３）。
プロトコル処理では、一つのハッシュ値につき現用、予備の２台のクラスタメンバが割り当てられているため、それらにパケットを受け渡すため、まずパケットを複製する（ステップＳ２７０４）。
ついで、冗長にプロトコル処理を行うため、現用／予備各々の担当クラスタメンバで送信処理を行う。実施例１と同様、まず予備処理クラスタメンバが送信処理を行う。自クラスタメンバ自身が予備処理担当クラスタメンバであれば（ステップＳ２７０５がＹＥＳ）、書込みＡＰＩ部１５２経由で直接送信データを書込む（ステップＳ２７０６）。書込み／送信処理の詳細は図２８に基づいて後述する。書込みが成功したらば、現用担当クラスタメンバ（必ず自クラスタメンバ以外が割り当てられている）に複製した送信データを送る（ステップＳ２７０７、Ｓ２７０８）。
自クラスタメンバが予備担当クラスタメンバでなければ（ステップＳ２７０５がＹＥＳ）、まず予備担当クラスタメンバに対して送信処理を実行させるため、同クラスタメンバへ複製データをリダイレクトする（ステップＳ２７０９）。
複製データが他のクラスタメンバにリダイレクトされると、それを受け取ったクラスタメンバは、リダイレクトデータ受信処理の延長で送信処理を行う（図２６Ａ−Ｄの、リダイレクトされた送信データを受信した場合）。この場合、送信データは該当クラスタメンバがプロトコル処理することがすでに決まっているので、単に書込みＡＰＩ部１５２経由で送信データを書込む（ステップＳ２６１０）。書込みが終わったら、その結果を書込み通知として、リダイレクト元（アプリケーションプログラムが書込みＡＰＩ部１５２を呼出したクラスタメンバ）へ送り返す（ステップＳ２６１１）。
次に、書込み通知受信契機の処理を説明する。まず、書込み通知の結果を見て、もし失敗していれば（図２７ＢのステップＳ２７１０がＮＯ）、このデータの書込みは失敗としてアプリケーションプログラムの書込み処理にエラーを返す（ステップＳ２７１５）。
次に、書込みが成功した場合（ステップＳ２７１０がＹＥＳ）は、現用処理の必要性を判別する（ステップＳ２７１１）。リダイレクト元が予備処理担当でない場合は、予備処理の後、さらに現用側の送信処理が必要となるが、それがすでに行われたかどうかを判別して、未着手ならば（ステップＳ２７１１がＹＥＳ）、実行する。これに着手済みなら（ステップＳ２７１１がＮＯ）、送信データを破棄してエラーをアプリケーションプログラム１１０に通知する（ステップＳ２７１６）。
自クラスタメンバが現用担当であれば（ステップＳ２７１２がＹＥＳ）、書込みＡＰＩを呼出して直接書込む（ステップＳ２７１４）。ここで書込みが成功すれば、アプリケーションプログラム１１０が呼出した書込みＡＰＩ部１５２の処理は正常に終了する。
他のクラスタメンバが現用担当であれば（ステップＳ２７１２がＮＯ）、送信データを該当クラスタメンバへリダイレクトする（ステップＳ２７１３）。さらに、その書込み通知を受け取ったら、成否を確認し、アプリケーションプログラム１１０に結果を通知して、書込み処理を終える。
プロトコル送信処理は、図２８の手順で行う。ステップＳ２８０１〜ステップＳ２８０５では、実施例１で説明した書込み処理（例えば、図７のステップＳ７０２〜Ｓ７０６）と同様の処理が行われる。ステップＳ２８０６では、予備処理対象のパケットか否かを判断する。そして、予備処理対象のパケットである場合（ステップＳ２８０６がＹＥＳ）は、パケットを破棄し、そうでない場合（ステップＳ２８０６がＮＯ）は、送信インタフェース１４２を介してパケットを送出する。
ここで、ステップＳ２８０６〜Ｓ２００８の処理は、次のように実現することができる。送信データに、図２７ＡのステップＳ２７０４において、複製したパケットに予備処理用であることを示す付加情報を付けておき、送信側振り分けフィルタ１３２では、予備処理用である場合のみ、パケットを破棄する。
あるいは、次のようにしても良い。送信側振り分けフィルタ１３２で、自クラスタメンバが現用プロトコル処理を担当しているハッシュ値と、予備処理を担当しているハッシュ値とを各々保持しておく。プロトコル処理部１２１から送信側振り分けフィルタ１３２に渡されたパケットについて、まず発信元アドレスが代表アドレスであるかどうか検査する。クラスタの代表アドレスが発信元でないパケットは、クラスタメンバ間の通信など、冗長処理の対象でないパケットのため、そのまま送出する。クラスタの代表アドレスが発信元アドレスであるパケットについては、受信側振り分けフィルタ１３１における処理（ステップＳ２５０３〜Ｓ２５０５）と同様にパケットのヘッダ等からハッシュ値を計算し、パケットに現用、予備処理用のフラグを付ける。もし、予備処理用のフラグが付いていれば、該当パケットを破棄する。
〔その他の処理〕
その他の処理は、大きく分けてセッション管理と死活監視がある。セッション開設は、基本的に実施例２の場合のシーケンスのうち、ａｃｃｅｐｔおよびｃｏｎｎｅｃｔの実行クラスタメンバが現用／予備の２台になるだけなので、詳細な説明は省略する。
死活監視については、次のように処理する。各クラスタメンバは、プロトコル処理用とアプリケーション処理用のハッシュ値割り当て表を共有している。同割り当て表には、ハッシュ値毎に担当クラスタメンバが割り当てられている。各クラスタメンバの死活状況を稼働確認通信により管理し、同割り当て表に稼働状況を反映させることで、クラスタ処理に死活状況を反映させる。
まず稼働確認手順の一例を説明する。各クラスタメンバは、所定の間隔（ｔ１とする）で稼働通知メッセージをデータリンク上でブロードキャストする。各クラスタメンバは他のクラスタメンバからの稼働通知を、発信元のクラスタメンバをキーとして管理し、所定の時間（ｔ２とする。ただしｔ２＞ｔ１）、新規の稼働通知を受信できなかったクラスタメンバについては、故障と判断する。
次に、ハッシュ値割り当て表の更新方法を説明する。ハッシュ値割り当て表には、ハッシュ値をキーとして、ハッシュ値毎に稼働クラスタメンバが割り当てられている。あるクラスタメンバが故障したと判断された場合、割り当て表から該当クラスタメンバを削除する。
上記の手順により、割り当て表は次のようになる。プロトコル処理用のハッシュ値割り当て表には、現用、予備２台のクラスタメンバが割り当てられているので、故障クラスタメンバが１台のみであれば、担当クラスタメンバの欠落が生じることはない。一方、アプリケーション処理用の割り当て表には通常現用クラスタメンバしか登録されていない。故障クラスタメンバがでた場合は、予め割り当てられている予備クラスタメンバを、該当するハッシュ値のエントリに登録する。
〔実施例３の変形例〕
本実施例の読込み処理は、次のような手順で実行しても良い。本実施例の説明ではプロトコルの予備処理担当クラスタメンバがデータを受信した場合、照合が終わると受信データを破棄するようになっていた。しかし、もし該当クラスタメンバがアプリケーション処理担当であれば、ここでデータを破棄せず、直接アプリケーションプログラムへ渡すほうが効率が良い。このため、予備処理担当クラスタメンバは、照合が成功した時にはデータを破棄せず、自身でもアプリケーションプログラムから与えられたハッシュ関数によってハッシュ値を計算し、もしアプリケーション処理担当が自クラスタメンバであれば、そのままアプリケーションプログラムにデータを受け渡すようにしても良い。この場合、現用クラスタメンバでは、ハッシュ値を計算し、アプリケーション処理担当クラスタメンバが、プロトコル処理担当の予備クラスタメンバと等しければ、受信データをリダイレクトせずに破棄して処理を終える。
また、次のようにしても良い。前記の手順は、無意味なデータの転送がないという意味では効率が良いが、照合が成功したすべてのデータに対して、２回ハッシュ値が計算される点では無駄がある。このため、現用クラスタメンバがハッシュ値を計算して、アプリケーション処理担当クラスタメンバが、プロトコル処理の予備クラスタメンバと等しい場合には、それを予備クラスタメンバに通知するようにしても良い。プロトコル処理の予備担当クラスタメンバは、照合が成功した受信データを、ハッシュ値は計算せず単に保持しておき、現用クラスタメンバからの上記通知に従って、自クラスタメンバがアプリケーション処理担当ならアプリケーションプログラムにデータを渡し、処理クラスタメンバが異なればデータを破棄する。これにより、受信データの無駄な転送はなくなり、ハッシュ値の計算は１回で済む。
〔実施例３の効果〕
本実施例によれば、トラフィックによる処理負荷を複数のクラスタメンバに分散させることでシステム全体の性能を高め、更に、トラフィックを冗長に処理することで信頼性を高めることができる。その理由は、アプリケーションプログラム１１０と読込み、書込みＡＰＩ部１５１、１５２との間に、読込みＡＰＩ呼出し捕捉部１６１、書込みＡＰＩ呼出し捕捉部１６２、制御部１７３、転送部１７４、アプリケーション処理振り分け及び複製照合部１９１、プロトコル処理振り分け及び複製書込み部１９２を備える構成を採用したからである。
〔本発明の実施例４〕
次に、本発明の実施例４について詳細に説明する。本実施例は、現用系および予備系のクラスタメンバの内の一方のクラスタメンバにおいて送信処理に著しい遅れが発生した場合や、現用系および予備系のクラスタメンバの内の一方のクラスタメンバが対向装置から送られてきたパケットを受信できなかった場合においても、両系のクラスタメンバにおいて同一のプロトコル処理を行えるようにしたことを特徴とする。
前述した実施例１によれば、現用系および予備系の２台のクラスタメンバを用いてプロトコル処理を冗長化し、その信頼性を高めることができる。その際、現用系および予備系のクラスタメンバにおいて、同一のプロトコル処理が行われる必要がある。しかし、現実的には、次のような現象により、同一のプロトコル処理が実行されない状態が継続し、プロトコル状態の冗長性が失われる場合がある。
すなわち、送達確認を行うプロトコル処理（ＴＣＰ等）を冗長化している場合において、
（１）現用系／予備系の片系のみにパケットが到達し、他系には同一パケットが到達しない場合。あるいは、片系で上記パケットを何らかの不具合のために取りこぼした場合。
（２）現用系／予備系の片系の送信処理に著しい遅延が発生し、送達確認パケットの受信がパケット送信前に実行される場合。
の各場合に片系でプロトコル処理を継続できなくなる。
この内、（１）については、
（１−ａ） 現用系にのみパケットが到達する。
（１−ｂ） 予備系にのみパケットが到達する。
の２つの場合がある。
（１−ａ） 現用系にのみパケットが到達した場合には現用系のプロトコル処理部がパケットを受け取り、確認応答パケットを送出する。予備系は、該当受信パケットを取りこぼしたことを意味する確認応答パケットを生成するが、系外には送出されない。このため、対向装置には現用系からの確認応答パケットのみが到達し、対向装置は後続のパケットを送出してしまう。これを続けると、予備系は取りこぼしたパケットを受信できないため、現用系と同一の状態を永久に回復できなくなる。
（１−ｂ） 予備系にのみパケットが到達した場合には予備系のプロトコル処理部がパケットを受け取り、確認応答パケットを生成する。但し、この確認応答パケットは系外には送出されない。現用系が、上記受信パケットを取りこぼしたことを意味する確認応答を送出するため、対向装置は送信パケットが消失したものと判断し、該当パケットを再送する。再送パケットは予備系に到達しても単に破棄され、現用系のみで受け取られる。これにより、（１−ｂ）の場合にはパケットの消失は問題にならない。
次に、（２）については、
（２−ａ） 現用系で送信処理が遅れる。
（２−ｂ） 予備系で送信処理が遅れる。
の２つの場合がある。
（２−ａ） 現用系で送信処理が遅れた場合には不具合は発生しない。予備系が先に送出処理を行ったとしても、実際にはパケットは系外に送出されず、従って対向装置からの確認応答パケットが、現用系の未送信パケットに対して到達することはないためである。
（２−ｂ） 予備系で送信処理が遅れた場合には、予備系が送信処理を開始する前に、現用系が送信処理を行うことになる。更に、現用系から送出されたパケットが対向装置に到達すると、対向装置からは直ちに確認応答パケットが送出される。実際に確認応答パケットが対向装置から届くと、現用だけでなく予備系にも到達する。予備系では、未送信パケットについての確認応答パケットが到達するが、通常そのような確認応答パケットは破棄される。以降、予備系がパケットの送信処理を実行しても、系外に送出されないことから、対向装置からの確認応答パケットを受け取る機会は得られず、予備系は上記パケットを再送し続けなければならなくなり、やがて再送タイマがタイムアウトしてコネクションが切断される。
本実施例では、上記した予備系のパケット取りこぼし及び送信時刻ずれに起因する不具合を解決できる追加機能を持った冗長化機能について説明する。
〔実施例４の構成の説明〕
本実施例は、図３１に示すようなブロードキャスト・ディスパッチ方式のクラスタシステムにおいて、クラスタメンバ１３−１〜１３−ｎの代わりに、図３５に示すクラスタメンバ１００ｃを用いることにより実現される。本実施例のクラスタシステムは、例えば、サーバ（サーバクラスタ）として機能する。
図３５に示した本実施例のクラスタメンバ１００ｃと、図１に示した実施例１のクラスタメンバ１００との相違点は、受信側振り分けフィルタ１３１及び送信側振り分けフィルタ１３２の代わりに、受信側振り分けフィルタ１３１ｃ及び送信側振り分けフィルタ１３２ｃを備えている点である。ここで、クラスタメンバ１００ｃを現用系として動作させる場合と予備系として動作させる場合とでは、受信側振り分けフィルタ１３１ｃ及び送信側振り分けフィルタ１３２ｃの構成が異なるものとなる。なお、本実施例のクラスタメンバ１００ｃも実施例１のクラスタメンバと同様に、コンピュータによって実現可能である。
〔予備系のフィルタの構成〕
クラスタメンバ１００ｃを予備系として動作させる場合、受信側振り分けフィルタ１３１ｃおよび送信側振り分けフィルタ１３２ｃは、それぞれ図３６に示す受信側振り分けフィルタ１０３１および送信側振り分けフィルタ１０３２と同一構成となる。
図３６を参照すると、受信側振り分けフィルタ１０３１は、振り分け部１０３１１と、受信通知送信部１０３１２と、フィルタ処理部１０３１３とを備えている。
振り分け部１０３１１は、受信インタフェース１４１を介して受信したパケットがクラスタシステムの代表アドレス宛のパケットである場合（同報通信されたパケットである場合）は、受信通知送信部１０３１２に振り分け、そうでない場合は、プロトコル処理部１２１に振り分ける機能を有する。
受信通知送信部１０３１２は、振り分け部１０３１１からパケットが渡される毎に、そのパケットを識別するための識別子を生成し、更に生成した識別子を含む受信通知パケットを現用系のクラスタメンバに送信する機能を持つ。
フィルタ処理部１０３１３は、フィルタ処理を行う。
送信側振り分けフィルタ１０３２は、振り分け処理部１０３２１と、送信通知送信部１０３２２と、フィルタ処理部１０３２３とを備えている。
振り分け部１０３２１は、プロトコル処理部１２１から渡されたパケットが、冗長化対象となるパケットの場合は、送信通知送信部１０３２２に振り分け、それ以外のパケットは、送信インタフェース１４２に振り分ける機能を持つ。
送信通知送信部１０３２２は、振り分け部１０３２１からパケットが渡される毎に、そのパケットに含まれる送信データのシーケンス番号を取得して、シーケンス番号を含む送信通知パケットを現用系のクラスタメンバに送信する機能を持つ。
フィルタ処理部１０３２３は、フィルタ処理を行う。
〔現用系のフィルタの構成〕
クラスタメンバ１００ｃを現用系として動作させる場合、送信側振り分けフィルタ１３２ｃの構成は、実施例１で使用した送信側振り分けフィルタ１３２と同一構成となり、受信側振り分けフィルタ１３１ｃの構成は、図３７に示す受信側振り分けフィルタ１０２１と同一構成となる。
図３７を参照すると、現用系のクラスタメンバで使用する受信側振り分けフィルタ１０２１は、振り分け部１０２１１と、受信パケット制御部１０２１２と、受信パケットバッファ１０２１３と、予備系受信履歴記憶部１０２１４と、受信通知受信部１０２１５と、確認応答バッファ１０２１６と、予備系送信履歴記憶部１０２１７と、送信通知受信部１０２１８とを備えている。
振り分け部１０２１１は、受信インタフェース１４１を介して受信した対向装置からのパケット、予備系からの受信通知パケットおよび送信通知パケットを、受信パケット制御部１０２１２、受信通知受信部１０２１５および送信通知受信部１０２１８に振り分ける機能を持つ。
受信通知受信部１０２１５は、予備系から送られてきた受信通知パケットに含まれている識別子を予備系受信履歴記憶部１０２１４に格納する機能を有する。
送信通知受信部１０２１８は、予備系から送られてきた送信通知パケットに含まれているシーケンス番号を予備系送信履歴記憶部１０２１７に格納する機能を有する。
受信パケット制御部１０２１２は、データを含む通常のパケットを受信パケットバッファ１０２１３に格納する機能や、確認応答データを含む確認応答パケットを確認応答バッファ１０２１６に格納する機能や、受信したパケットをプロトコル処理部１２１に渡す機能や、受信パケットバッファ１０２１３に格納されているパケットを予備系のクラスタメンバへ送信する機能や、確認応答バッファ１０２１６に格納されている確認応答パケットを予備系のクラスタメンバへ送信する機能などを有する。
〔実施例４の動作の説明〕
次に、本実施例の動作を現用系と予備系とに分けて説明する。なお、冗長化自体の動作は実施例１と同一であるため、ここでは、冗長化処理については説明を省略する。
〔予備系の動作〕
先ず、予備系の動作を説明する。予備系における動作の流れを図３８に示す。
先ず、予備系のパケット受信時の動作を説明する。受信インタフェース１４１を介して対向装置からのパケットを受信すると、振り分け部１０３１１は、そのパケットが代表アドレス宛であるか否かを（現用系、予備系の双方に同報通信されるパケットであるか否かを）、パケットの宛先ＭＡＣアドレスに基づいて判断する（ステップＳ１０４８、Ｓ１０４９）。
そして、代表アドレス宛でないと判断した場合（ステップＳ１０４９がＮＯ）は、振り分け部１０３１１は、受信パケットをプロトコル処理部１２１に引き渡す。これにより、プロトコル受信処理が行われる。
これに対して、代表アドレス宛であると判断した場合（ステップＳ１０４９がＹＥＳ）は、受信パケットを受信通知送信部１０３１２に渡す。
これにより、受信通知送信部１０３１２が、受信パケットを識別するための識別子を生成する（ステップＳ１０４Ａ）。識別子は、他のパケットから該当パケットを区別することが可能な情報で、ここではパケットのチェックサムを用いる。但し、チェックサムでなくとも、パケットを識別できる情報であれば他の値を識別子として用いても良い。例えば、パケットをハッシュ関数にかけてハッシュ値を算出し、それを識別子としても良い。
その後、受信通知送信部１０３１２は、上記識別子を含む受信通知パケットを作成し、現用系のクラスタメンバのアドレス宛に送信する（ステップＳ１０４Ｂ）。この処理は通常プロトコル送信処理を含むため、同図ではプロトコル送信処理（ステップＳ１０４２）に引き継がれている。上記処理の後、受信パケットは、フィルタ処理部１０３１３によるフィルタ処理が行われた後（ステップＳ１０４Ｃ）、プロトコル処理部１２１に引き渡され、受信処理が行われる（ステップＳ１０４Ｄ）。
次に、予備系における送信処理を説明する。送信側振り分けフィルタ１０３２内の振り分け部１０３２１は、プロトコル処理部１２１から送信パケットが渡されると、そのパケットが冗長化対象のパケットであるか否かを判定する（ステップＳ１０４２、Ｓ１０４３）。この判定は、例えば、パケットのヘッダ部の内容や、発信元アドレスに基づいて行う。なお、プロトコル処理部１２１から振り分け部１０３２１には、書込みＡＰＩ部１５２の書込みＡＰＩ呼出し（ステップＳ１０４１）に起因したパケットや、受信通知パケットや、送信通知パケットが渡される。
そして、冗長化対象の送信パケットでない場合（ステップＳ１０４３がＮＯ）は、振り分け部１０３２１は、送信パケットを送信インタフェース１４２を介して送信する（ステップＳ１０４７）。
これに対して、冗長化対象の送信パケットである場合（ステップＳ１０４３がＹＥＳ）は、振り分け部１０３２１は、送信パケットを送信通知送信部１０３２２に渡す。
これにより、送信通知送信部１０３２２は、先ず、送信パケットのヘッダ部からシーケンス番号（送信シーケンス番号）を取得する（ステップＳ１０４４）。次に、上記シーケンス番号を含む送信通知パケットを作成し、現用系のクラスタメンバのアドレス宛に送信する（ステップＳ１０４５）。この処理も受信通知パケットの場合と同様、プロトコル送信処理（ステップＳ１０４２）に引き継がれている。
上記処理の後、フィルタ処理部１０３２３において、送信側振り分けフィルタ１０３２で定義されているフィルタ処理が行われる（ステップＳ１０４６）。予備系における上記フィルタ処理では、少なくとも、冗長化対象の送信パケットを破棄する処理が行われる。
以上により、冗長化対象の送信／受信パケットの送信／受信処理が実行される都度、その通知が現用系のクラスタメンバへ送られる。
〔現用系の動作〕
次に現用系の動作を説明する。現用系における動作の流れを図３９Ａ、３９Ｂ、３９Ｃに示す。
図３７に示す受信側振り分けフィルタ１０２１内の振り分け部１０２１１は、受信インタフェース１４１を介してパケットを受信すると、代表アドレス宛であるか否かを宛先ＭＡＣアドレスに基づいて判断する（ステップＳ１０５１）。
そして、代表アドレス宛のパケットであれば（ステップＳ１０５１がＹＥＳ）は、振り分け部１０２１１は、受信パケットを受信パケット制御部１０２１２に渡す。これにより、受信パケット制御部１０２１２は、必要に応じて受信側振り分けフィルタ１０２１で定義されているフィルタ処理を行う（ステップＳ１０５２）。
その後、受信パケット制御部１０２１２は、受信パケットが確認応答データを含む対向装置からの確認応答パケットであるか否かを判断する（ステップＳ１０５３）。
そして、対向装置からの確認応答パケットであれば（ステップＳ１０５３がＹＥＳ）は、そのヘッダ部から確認応答番号（正常受信したパケットのシーケンス番号）を取り出し、この確認応答番号をキーにして予備系送信履歴記憶部１０２１７を検索することにより、上記確認応答パケットに相当するパケットを、予備系が送信済か否かを調べる（ステップＳ１０５４）。即ち、予備系送信履歴記憶部１０２１７に、確認応答番号と同一のシーケンス番号が格納されている場合は、送信済みと判定し、格納されていなければ、未送信と判定する。
そして、予備系が未送信のパケットに対する確認応答パケットであると判定した場合（ステップＳ１０５５がＹＥＳ）は、上記確認応答パケットを確認応答バッファ１０２１６に格納し、それ以降の受信処理は保留にする（ステップＳ１０５６）。
これに対して、予備系が送信済みのパケットに対する確認応答パケットであると判定した場合（ステップＳ１０５５がＮＯ）は、確認応答パケットをプロトコル処理部１２１に渡す（ステップＳ１０５Ａ）。
また、上記したステップＳ１０５３において、振り分け部１０２１１から渡されたパケットが、対向装置からのデータを含む通常のパケットであると判断した場合（判断結果がＮＯ）は、受信パケット制御部１０２１２は、予備系受信履歴記憶部１０２１４を検索することにより、予備系が同一のパケットを受信済みであるか否かを判定する（ステップＳ１０５７）。即ち、予備系送信履歴記憶部１０２１４に、受信パケットの識別子と同一の識別子が格納されている場合は、予備系が同一のパケットを受信済みと判定し、格納されていない場合は未受信と判定する。
そして、予備系で受信済みであると判定した場合（ステップＳ１０５８がＹＥＳ）は、受信パケット制御部１０２１２は、受信したパケットをプロトコル処理部１２１に渡し、更に、予備系受信履歴記憶部１０２１４から上記パケットの識別子を削除する（ステップＳ１０５Ａ）。
これに対して、予備系で未受信であると判定した場合（ステップＳ１０５８がＮＯ）は、上記パケットを予備系に送信することが必要になる場合があるので、その複製を受信パケットバッファ１０２１３に格納し、更に上記パケットをプロトコル処理部１２１に渡す（ステップＳ１０５９、Ｓ１０５Ａ）。
以上が冗長化対象にするパケット（代表アドレス宛のパケット）の受信処理である。
次に、受信パケットが代表アドレス宛でない場合を説明する。
振り分け部１０２１１は、受信インタフェース１４１を介して受信したパケットが代表アドレス宛のものでない場合（ステップＳ１０５１がＮＯ）は、上記パケットが、予備系からの送信通知パケットであるか否かを調べる（ステップＳ１０５Ｃ）。
そして、送信通知パケットである場合（ステップＳ１０５ＣがＹＥＳ）は、上記パケットを送信通知受信部１０２１８に渡す。これにより、送信通知受信部１０２１８は、上記送信通知パケットからシーケンス番号を取り出し、予備系送信履歴記憶部１０２１７に格納する（ステップＳ１０５Ｄ）。通常、シーケンス番号は連続しているため、予備系送信履歴記憶部１０２１７には最後に送信したパケットのシーケンス番号のみ保持させても良い。
予備系送信履歴記憶部１０２１７にシーケンス番号が格納されると、受信パケット制御部１０２１２は、上記新たに格納されたシーケンス番号と同一のシーケンス番号を持つ確認応答パケットを確認応答バッファ１０２１６から検索する（ステップＳ１０５Ｅ）。即ち、予備系が上記シーケンス番号のパケットを未送信であったために、ステップＳ１０５６において確認応答バッファ１０２１６に格納（保留）された確認応答パケットを検索する。
そして、そのような確認応答パケットを検索できなかった場合は、受信パケット制御部１０２１２は、その処理を終了する。これに対して、該当する確認応答パケットを検索できた場合には、検索した確認応答パケットをプロトコル処理部１２１に渡して現用系の受信処理を行わせると共に、予備系のクラスタメンバに上記確認応答パケットを、プロトコル処理部１２１、１２２、…、１２ｋ、読込みＡＰＩ部１５１、複製部／照合部１７１、転送部１７４を介して送信する（ステップＳ１０５Ｆ、Ｓ１０５Ａ、Ｓ１０５Ｂ）。ここで、予備系のクラスタメンバに確認応答パケットを送信するのは、仮に予備系がこの確認応答パケットを受信していたとしても、未送信パケットに対する確認応答パケットであるので、破棄している可能性が高いためである。
このようにすると、予備系が未送信のパケットに対する確認応答パケットは、現用系では必ず確認応答バッファ１０２１６に滞留し、プロトコル処理部１２１まで上がることがない。更に、予備系から送信通知パケットが到着すれば、確認応答バッファ１０２１６に滞留させておいた確認応答パケットがプロトコル処理部１２１へ送られる。以上により、予備系において、未送信パケットに対する確認応答パケットの受信が失敗することにより発生する問題（２−ｂ）を解決できる。
以上が、予備系からの送信通知パケットを受信したときの動作である。
次に、予備系からの受信通知パケットを受信したときの動作を説明する。
振り分け部１０２１１は、受信インタフェース１４１を介して受信したパケットが、予備系からの受信通知パケットであると判断すると（ステップＳ１０５ＧがＹＥＳ）、それを受信通知受信部１０２１５及び受信パケット制御部１０２１２に渡す。
これにより、受信パケット制御部１０２１２は、予備系受信履歴記憶部１０２１４及び受信パケットバッファ１０２１３を参照し（ステップＳ１０５Ｈ、Ｓ１０５Ｉ）、その状態が、下記の（ｘ−１）、（ｘ−２）、（ｙ−１）、（ｙ−２）、（ｚ）の何れの状態になっているかを調べる。
（ｘ−１）予備系受信履歴記憶部１０２１４に、受信通知パケットに含まれている識別子が格納されており、且つ、受信パケットバッファ１０２１３に上記識別子に対応するパケットが格納されている状態。
（ｘ−２）予備系受信履歴記憶部１０２１４に、受信通知パケットに含まれている識別子が格納されており、且つ、受信パケットバッファ１０２１３に上記識別子に対応するパケットが格納されていない状態。
（ｙ−１）予備系受信履歴記憶部１０２１４に、受信通知パケットに含まれている識別子が格納されておらず、且つ、受信パケットバッファ１０２１３に、上記識別子に対応するパケット（パケットＰ１とする）と、パケットＰ１よりも受信順が前のパケットとが格納されており、受信順が前のパケットの中に予備系受信履歴記憶部１０２１４には該当する識別子が格納されていないパケット（パケットＰ２とする）が存在する状態。
（ｙ−２）予備系受信履歴記憶部１０２１４に、受信通知パケットに含まれている識別子が格納されておらず、且つ、受信パケットバッファ１０２１３に、上記識別子に対応するパケットＰ１と、パケットＰ１よりも受信順が前のパケットとが格納されており、受信順が前のパケットは、全て予備系受信履歴記憶部１０２１４に該当する識別子が格納されている状態。
（ｚ） 予備系受信履歴記憶部１０２１４に、受信通知パケットに含まれている識別子が格納されておらず、且つ、受信パケットバッファ１０２１３に、上記識別子に対応するパケット（パケットＰ３とする）が格納されていない状態。
その後、受信パケット制御部１０２１２は、現在の予備系受信履歴記憶部１０２１４及び受信パケットバッファ１０２１３の状態に応じて、ステップＳ１０５Ｊ〜Ｓ１０５Ｌの処理を行う。
（ｘ−１）の状態である場合は、予備系がパケットを受信しているので、再送は不要と判断する（ステップＳ１０５ＪがＮＯ）。また、この状態では、現用系も同一パケットを受信しているので、受信パケットバッファ１０２１３及び予備系受信履歴記憶部１０２１４から該当パケットのエントリを削除する（ステップＳ１０５Ｌ）。
（ｘ−２）の状態である場合は、予備系がパケットを受信しているので、再送は不要と判断する（ステップＳ１０５ＪがＮＯ）。また、この状態では、現用系が該当パケットをまだ受け取っていないか、パケットをとりこぼしている可能性があるため、予備系受信履歴記憶部１０２１４の内容はそのままとする。ただし、一定時間経過しても該当パケットが到達しなければ、メモリリークを防ぐために該当識別子を削除するよう、該当識別子にフラグを付けておく。
（ｙ−１）の状態の場合は、パケットＰ２は現用系では受信したが、予備系では取りこぼした可能性が高い。これは、現用系と予備系は同一データリンクからパケットを受信するため、順序が入れ替わることは稀と考えられるためである。そこで、この場合には、再送が必要と判断し（ステップＳ１０５ＪがＹＥＳ）、受信パケットバッファ１０２１３に格納されているパケットＰ２を予備系に送信する（ステップＳ１０５Ｋ、Ｓ１０５Ｂ）。また、この場合は、ステップＳ１０５Ｌにおいて、受信通知受信部１０２１５に対して識別子の格納を指示する。これにより、受信通知受信部１０２１５は、前述したステップＳ１０５Ｇにおいて振り分け部１０２１１から渡された受信通知パケットに含まれている識別子を予備系受信履歴記憶部１０２１４に格納する。
（ｙ−２）の状態である場合は、現用と予備でパケットの受信履歴は一致しているため、再送は不要と判断し（ステップＳ１０５ＪがＮＯ）、更に、予備系受信履歴記憶部１０２１４及び受信パケットバッファ１０２１３から全エントリを削除する（ステップＳ１０５Ｌ）。
（ｚ）の状態である場合は、予備系では、パケットを受信しているので、再送不要と判断する（ステップＳ１０５ＪがＮＯ）。また、予備系が受信したパケットを現用系が受信していない可能性があるため、ステップＳ１０５Ｌにおいて、受信通知受信部１０２１５に対して識別子の格納を指示する。これにより、受信通知受信部１０２１５は、前述したステップＳ１０５Ｇにおいて振り分け部１０２１１から渡された受信通知パケットに含まれている識別子を予備系受信履歴記憶部１０２１４に格納する。ただし、一定時間経過しても該当パケットが到達しなければ、メモリリークを防ぐために該当識別子を削除するよう、該当識別子にフラグを付けておく。
以上の処理により、現用系には到達したが、予備系には到達していないパケットがあれば、予備系受信履歴記憶部１０２１４の確認により現用系から再送される。よって予備系のみで受信パケットを取りこぼすことにより発生する問題（１−ａ）を解決できる。
〔実施例４の効果〕
以上説明したように、本実施例によれば、パケットの取りこぼしと送信遅延に起因するプロトコル状態ずれの継続を回避することができる。その理由は、予備系のクラスタメンバが、プロトコル処理部１２１、１２２、…、１２ｋによるプロトコル処理が済んだ送信パケットを示す送信通知パケットを現用系のクラスタメンバへ送信する送信通知送信部１０３２２を備え、現用系のクラスタメンバが、確認応答バッファ１０２１６と、送信パケットの宛先の対向装置から上記送信パケットに対する確認応答パケットが送られてきたとき、予備系のクラスタメンバから上記送信パケットを示す送信通知パケットが送られてきていないことを条件にして、確認応答パケットを確認応答バッファ１０２１６に格納し、予備系のクラスタメンバから、送信通知パケットが送られてきたとき、この送信通知パケットが示す送信パケットに対する確認応答パケットが確認応答バッファ１０２１６に格納されていることを条件にして、上記確認応答パケットを予備系のクラスタメンバへ送信する受信パケット制御部１０２１２とを備えているからである。
〔本発明の実施例５〕
実施例１及び４では、現用系と予備系で、少なくとも同一の送信データが生成され、同一データを含むパケットの送信処理が実行されることを前提としていた。
ＳＣＴＰのようなメッセージ境界が保存されるプロトコルでは、アプリケーションプログラムが同一データを書込めば、同一のパケットが生成されるが、ＴＣＰのようなメッセージ境界が保存されないプロトコルでは、同一データを書込んでも、送信タイミングが異なると、メッセージの切目がずれて異なるパケットが生成される場合がある。
図４０に具体例を示す。同図は自系と他系のプロトコル送信バッファ内容の時間変化を示している。最初は両系ともプロトコル送信バッファが空である（Ｓ１０８１）。
例えば、パケットに含まれるデータ長が１４６０バイトのとき、アプリケーションプログラムが３０００バイトのデータを書込むとする（Ｓ１０８２）。この場合、後続データがなければ１４６０バイトのデータを含む２個のパケットと、８０バイトのデータを含む１個のパケットが送出されることになる（Ｓ１０８３〜Ｓ１０８５）。送信データは、対向装置からの確認応答パケットが到着するまでプロトコル送信バッファに保持される。
ここで、自系のみで最後のデータ（８０バイト）のみ確認応答がされていない状態で、次の送信データの書込み処理が実行され、他系ではその書込み処理が実行される前に最後のパケットに対する確認応答パケットが到着すると、自系のプロトコル送信バッファは２回分の書込みデータが混ざった状態になり、他系のプロトコル送信バッファは２回目の書込みデータのみが保持されていることになる（Ｓ１０８６）。
この状態で次のパケットの送出処理が行われると、自系では古いデータ８０バイトと新しいデータ１３８０バイトが繋がったものが、他系では新しいデータのみ１４６０バイトが送出される（Ｓ１０８７）。このようにしてパケットに含まれる送信データの境界がずれることがある。
このような場合も、プロトコル送信バッファに置かれた送信データが全て確認応答されれば、プロトコル送信バッファが空になるため、次回書込み時には再びプロトコル送信バッファ内に同一データが置かれ、パケット毎の送信データの切目がそろうため、通常は不具合は起きない。
但し、実施例４のように、送信パケットのシーケンス番号と確認応答番号を対応付けて確認応答の受信時期の制御を行っている場合は、送信データの境界がずれると確認応答と送信データの対応付けが難しくなる。このような問題を解決するため、本実施例では、異なる書込みで送信バッファのデータが混ざらないようにする。
〔実施例５の構成の説明〕
図４１は本実施例にかかるクラスタメンバの構成例を示すブロック図である。本実施例のクラスタメンバと、図３５に示した実施例４のクラスタメンバ１００ｃとの相違点は、複製部／書込み部１７２と書込みＡＰＩ部１５２との間に、書込み制御部１０６５と、送信バッファ監視部１０６６と、全量応答通知受信部１０６３と、書込み量通知部１０６４とを備えている点と、受信側振り分けフィルタ１３１ｃ及び送信側振り分けフィルタ１３２ｃの代わりに受信側振り分けフィルタ１０６１及び送信側振り分けフィルタ１０６２を備えている点である。なお、図４１では、読込みＡＰＩ呼出し捕捉部１６１、複製部／照合部１７１、読込みＡＰＩ部１５１、制御部１７３、及び転送部１７４は図示を省略している。また、図３５と同一符号は、同一部分を表している。また、本実施例のクラスタメンバも、実施例４のクラスタメンバと同様にプログラムにより実現可能である。
書込み制御部１０６５は、送信データの書込みを必要に応じて遅延させる機能を持つ。
送信バッファ監視部１０６６は、プロトコル処理部１２１、１２２、…、１２ｋのプロトコル送信バッファ１０２０が空かどうかを検査する機能を持つ。
全量応答通知受信部１０６３は、送信側振り分けフィルタ１０６２が発行する全量応答通知を受け取る機能を有する。
書込み量通知部１０６４は、送信データとして書込まれるデータの量を送信側振り分けフィルタ１０６２に通知する機能を持つ。
送信側振り分けフィルタ１０６２は、書込み量通知受信部１０６２４、送信量計測部１０６２２及び、全量応答通知部を１０６２３を備えている点を特徴とする。なお、図４１では、送信側振り分けフィルタ１３２、１３２ｃが備えている他の構成要素の内、フィルタ処理部１０６２１のみを図示し、それ以外は図示を省略している。
また、受信側振り分けフィルタ１０６１は、応答捕捉部１０６１２を備えていることを特徴としている。図４１では、受信側振り分けフィルタ１３１、１３１ｃが備えている他の構成要素の内、フィルタ処理部１０６１１のみを図示し、それ以外は図示を省略している。
書込み量通知受信部１０６２４は、書込み時に書込み量通知部１０６４から発行される書込み量通知を受け取る機能を有する。
送信量計測部１０６２２は、自フィルタ１０６２から送信したパケットに含まれるデータの量を計測する機能を持つ。
全量応答通知部１０６２３は、書込みデータの全量が送信、応答されたことをＡＰＩ側の全量応答通知受信部１０６３へ通知する機能を持つ。
応答捕捉部１０６１２は、所定のシーケンス番号を持つ確認応答パケットを捕捉する機能を持つ。
〔実施例５の動作の説明〕
本実施例の動作を図４２Ａ、４２Ｂに示す。
アプリケーションプログラム１１０が書込みＡＰＩ部１５２を呼び出すと、書込みＡＰＩ呼出し捕捉部１６２が、実際の書込みＡＰＩ部１５２を呼ぶ前に冗長化処理を行う（ステップＳ１０７１）。その冗長化処理の後、書込み処理の前に、更に次の処理を行う。
先ず、書込みＡＰＩ呼出し捕捉部１６２が、送信バッファ監視部１０６６を利用して、プロトコル送信バッファ１０２０に残データが存在するか否か、即ちプロトコル送信バッファ１０２０が空であるか否かを調べる（ステップＳ１０７２）。そして、残データがあれば（ステップＳ１０７２がＮＯ）、その送信が終わり、残データが無くなるまで待機する（ステップＳ１０７３）。
残データの検査は、通常、プロトコル送信バッファ１０２０に対する一定間隔のポーリングにより行うが、性能向上のために上記一定間隔を短くすると、頻繁な検査が必要になり、計算資源を浪費する。プロトコル送信バッファ１０２０が空になるまでには長い時間がかかる場合があるため、このように監視するのは非効率である。よって、本実施例では、残データの検査は全量応答通知を受け取るまで行わない。
書込みＡＰＩ呼出し捕捉部１６２は、全量応答通知受信部１０６３が全量応答通知を受信すると（ステップＳ１０７４）、送信バッファ監視部１０６６に検査開始を指示し、これにより送信バッファ監視部１０６６は、残データが無くなるまでプロトコル送信バッファ１０２０の検査を行う（ステップＳ１０７５、Ｓ１０７６）。
そして、送信バッファ監視部１０６６によって残データ無しが検出されると（ステップＳ１０７５がＹＥＳ）、書込みＡＰＩ呼出し捕捉部１６２は、書込み量通知部１０６４を介して送信側振り分けフィルタ１０６２に書き込み対象データのデータ量（書込み量）を伝え（ステップＳ１０７７）、その後、書込みＡＰＩ部１５２を呼出し、書込みを実行する（ステップＳ１０７８、Ｓ１０７Ｂ）。
送信側振り分けフィルタ１０６２内の送信量計測部１０６２２は、書込み量通知受信部１０６２４が書込み量を受信すると（ステップＳ１０７９）、その時点から送信データ量の計測を開始する（ステップＳ１０７Ａ）。
送信量計測部１０６２２は、最下位層のプロトコル処理部１２１から冗長化対象のパケットが渡される毎に、それに含まれているデータ量を送信量に積算する（ステップＳ１０７Ｃ、Ｓ１０７Ｄ）。
その後、送信量計測部１０６２２は、積算した送信量が書込み量通知受信部１０６２４で受信した書込み量となったか否かを調べることにより、今回、プロトコル処理部１２１から渡された送信パケットが、書込み対象データを送信する最後の送信パケットであるか否かを判断する（ステップＳ１０７Ｅ）。
そして、書込み対象データを送信する最後の送信パケットでない場合（ステップＳ１０７ＥがＮＯ）は、送信量計測部１０６２２は、上記送信パケットをフィルタ処理部１０６２１に渡す。これにより、フィルタ処理部１０６１２は、必要に応じて上記送信パケットに対してフィルタ処理を行い、その後、送信インタフェース１４２を介して送信する（ステップＳ１０７Ｈ、Ｓ１０７Ｉ）。
これに対して、書込み対象データを送信する最後の送信パケットであった場合（ステップＳ１０７ＥがＹＥＳ）は、送信量計測部１０６２２は、応答捕捉部１０６１２に対して、上記最後の送信パケットに対する対向装置からの確認応答パケットの捕捉を指示する確認応答監視指示を出力する（ステップＳ１０７Ｆ）。なお、確認応答監視指示には、上記最後のパケットのシーケンス番号が含まれている。その後、送信量計測部１０６２２は、送信量の計測処理を終了し、上記最後のパケットをフィルタ処理部１０６２１に渡す（ステップＳ１０７Ｇ）。これにより、フィルタ処理部１０６２１は、必要に応じてフィルタ処理を行い、その後、最後の送信パケットを送信インタフェース１４２を介して送信する（ステップＳ１０７Ｈ、Ｓ１０７Ｉ）。
一方、応答捕捉部１０６１２は、送信量計測部１０６２２から確認応答監視指示が入力されると、送信量を計測しているコネクションの確認応答パケットを受信する毎に、受信した確認応答パケットが、最後の送信パケットに対する確認応答パケットであるか否かを調べる（ステップＳ１０７Ｊ、Ｓ１０７Ｋ）。具体的には、受信した確認応答パケットに含まれている確認応答番号と、確認応答監視指示に含まれているシーケンス番号とが一致するか否かを調べることにより、最後の送信パケットに対する確認応答パケットであるか否かを判断する。
そして、最後の送信パケットに対する確認応答パケットでなかった場合（ステップＳ１０７ＫがＮＯ）は、応答捕捉部１０６１２は、次の確認応答パケットを受信するのを待って、前述した処理と同様の処理を行う（ステップＳ１０７Ｊ）。
これに対して、最後の送信パケットに対する確認応答パケットであった場合（ステップＳ１０７ＫがＹＥＳ）は、プロトコル送信バッファ１０２０に格納されていた全ての送信対象データが対向装置によって確認応答されたことになり、プロトコル送信バッファ１０２０は空になるはずであるので、応答捕捉部１０６１２は、全量応答通知部１０６２３へその旨を通知する。これにより全量応答通知部１０６２３は、全量応答通知受信部１０６３に対して全量応答通知を発行する（ステップＳ１０７Ｌ）。
書込みＡＰＩ呼出し捕捉部１６２は、全量応答通知受信部１０６３が全量応答通知を受信すると（ステップＳ１０７４）、プロトコル送信バッファ１０２０が空になるまで待ち（ステップＳ１０７５、Ｓ１０７６）、プロトコル送信バッファ１０２０が空になると、前述したステップＳ１０７７以降の処理を行う。
以上説明したように、本実施例では、必ずプロトコル送信バッファ１０２０が空になってから書き込みが行われるため、複数回の書き込み分の送信データが一つのパケットに入って送信されることはなく、送信データのパケット化時の境界が現用と予備でずれることはなくなる。

Claims (62)

  1. 複数のクラスタメンバを備え、且つ、
    前記複数のクラスタメンバが、それぞれ、
    プロトコル処理を行うプロトコル処理部と、
    呼出しの種類に応じて前記プロトコル処理部からデータを読込むか或いは前記プロトコル処理部にデータを書込む通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの前記通信ＡＰＩ部に対する呼出しを捕捉して前記アプリケーションプログラムに代わって前記通信ＡＰＩ部を呼出し、該呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータ或いは前記呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部に書込むデータに対して前記呼出しの種類に応じた処理を行うと共に、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う捕捉部とを備えたことを特徴とするクラスタシステム。
  2. 複数のクラスタメンバを備え、且つ、
    前記複数のクラスタメンバの内の現用系として動作するクラスタメンバが、
    プロトコル処理を行う現用系プロトコル処理部と、
    読込み呼出しに応答して前記現用系プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記現用系プロトコル処理部に書込む現用系通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを前記アプリケーションプログラムに渡し、書込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して書込み呼出しを行う現用系呼出し捕捉部と、
    該現用系呼出し捕捉部が書込み呼出しを捕捉した場合、自クラスタメンバの予備系となるクラスタメンバに対して、書込みデータの複製データを転送する現用系転送部とを備え、
    前記複数のクラスタメンバの内の予備系として動作するクラスタメンバが、
    プロトコル処理を行う予備系プロトコル処理部と、
    読込み呼出しに応答して前記予備系プロトコル処理部からデータを読み出し、書込み呼出しに応答して前記予備系プロトコル処理部にデータを書込む予備系通信ＡＰＩ部と、
    前記現用系転送部から複製データが転送されてきたとき、前記予備系通信ＡＰＩ部に対して書込み呼出しを行い、前記複製データを前記予備系プロトコル処理部に書込ませる予備系書込み部と、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する破棄部とを備えたことを特徴とするクラスタシステム。
  3. 請求の範囲２記載のクラスタシステムにおいて、
    前記現用系転送部が、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだ読込みデータの複製データを、自クラスタメンバの予備系となるクラスタメンバへ送信し、
    前記予備系として動作するクラスタメンバが、前記現用系から送られてきた読込みデータの複製データと前記予備系プロトコル処理部を介して受信したデータとを照合し、照合結果を前記複製データの転送元のクラスタメンバに対して通知する予備系照合部を備え、且つ、
    前記現用系呼出し捕捉部が、前記予備系照合部から通知された照合結果が不一致を示している場合は、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを破棄することを特徴とするクラスタシステム。
  4. 請求の範囲３記載のクラスタシステムにおいて、
    前記予備系書込み部が、前記予備系プロトコル処理部において前記書込みデータの複製データに対するプロトコル処理が正常終了したか否かを示す書込み結果を、前記複製データの転送元のクラスタメンバに対して通知し、
    前記現用系呼出し捕捉部が、前記予備系書込み部から通知された書込み結果が異常終了を示している場合は、書込み呼出しにより書込みが指示されているデータを破棄することを特徴とするクラスタシステム。
  5. 請求の範囲２記載のクラスタシステムにおいて、
    前記予備系のクラスタメンバが、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットを示す送信通知を前記現用系のクラスタメンバへ送信する送信通知送信部を備え、
    前記現用系のクラスタメンバが、
    確認応答バッファと、
    送信パケットの宛先の対向装置から前記送信パケットに対する確認応答が送られてきたとき、前記予備系のクラスタメンバから前記送信パケットを示す送信通知が送られてきていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系のクラスタメンバから送信通知が送られてきたとき、該送信通知が示す送信パケットに対する確認応答が前記確認応答バッファに格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするクラスタシステム。
  6. 請求の範囲５記載のクラスタシステムにおいて、
    前記送信通知が、前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットのシーケンス番号を含み、
    前記現用系のクラスタメンバが、
    予備系送信履歴記憶部と、
    前記予備系のクラスタメンバから送られてきた送信通知に含まれているシーケンス番号を前記予備系送信履歴記憶部に格納する送信通知受信部とを備え、
    前記受信パケット制御部が、送信パケットの宛先の対向装置から前記送信パケットのシーケンス番号を含んだ確認応答が送られてきたとき、前記予備系通信履歴記憶部に前記シーケンス番号が格納されていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系送信履歴記憶部にシーケンス番号が登録されたとき、前記確認応答バッファに前記シーケンス番号に対応する確認応答が格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信することを特徴とするクラスタシステム。
  7. 請求の範囲２記載のクラスタシステムにおいて、
    前記予備系のクラスタメンバが、
    受信したパケットを示す受信通知を前記現用系のクラスタメンバへ送信する受信通知送信部を備え、
    前記現用系のクラスタメンバが、
    受信パケットバッファと、
    パケットを受信したとき、前記予備系のクラスタメンバから前記パケットを示す受信通知が送られてきていないことを条件にして、前記パケットを前記受信パケットバッファに登録し、前記予備系のクラスタメンバから受信通知が送られてきたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするクラスタシステム。
  8. 請求の範囲７記載のクラスタシステムにおいて、
    前記受信通知が、受信したパケットの識別子を含み、
    前記現用系のクラスタメンバが、
    予備系受信履歴記憶部と、
    前記予備系のクラスタメンバから送られてきた受信通知に含まれている識別子を前記予備系受信履歴記憶部に登録する受信通知受信部とを備え、
    前記受信パケット制御部が、パケットを受信したとき、前記予備系受信履歴記憶部に前記パケットの識別子が格納されていないことを条件にして、前記パケットを前記受信パケットバッファに格納し、前記予備系受信履歴記憶部にパケットの識別子が格納されたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信することを特徴とするクラスタシステム。
  9. 請求の範囲５記載のクラスタシステムにおいて、
    前記現用系のクラスタメンバ及び前記予備系のクラスタメンバが、
    プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる構成を有することを特徴とするクラスタシステム。
  10. 複数のクラスタメンバを備え、且つ、
    前記複数のクラスタメンバが、それぞれ、
    プロトコル処理を行うプロトコル処理部と、
    予め定められているプロトコル処理用振り分け規則に基づいて、受信パケットが自クラスタメンバで処理すべき受信パケットであると判断した場合、前記受信パケットを前記プロトコル処理部に渡す受信側振り分けフィルタと、
    読込み呼出しに応答して前記プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記プロトコル処理部に書込む通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、該受信データを前記アプリケーションプログラムに渡し、他のクラスタメンバから送られてきた送信データである場合には、該送信データを前記プロトコル処理部に渡し、それ以外である場合には、前記データをアプリケーション処理振り分け部に渡し、書込み呼出しを捕捉した場合は、該捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分け部に渡す呼出し捕捉部と、
    該呼出し捕捉部から渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムに前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すアプリケーション処理振り分け部と、
    前記呼出し捕捉部から渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部に前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すプロトコル処理振り分け部と、
    前記アプリケーション処理振り分け部及びプロトコル処理振り分け部から渡されたデータを該当するクラスタメンバへ転送する転送部とを備えたことを特徴とするクラスタシステム。
  11. 請求の範囲１０記載のクラスタシステムにおいて、
    前記アプリケーション処理用振り分け規則が、アプリケーションデータに対するハッシュ値に基づいて振り分け先を決定し、
    前記プロトコル処理用振り分け規則が、パケットのヘッダを構成するパラメータから計算されるハッシュ値に基づいて振り分け先を決定するものであることを特徴とするクラスタシステム。
  12. 複数のクラスタメンバを備え、全クラスタメンバに同報されたトラフィックから、自身の担当部分を各クラスタメンバが拾得し、それ以外は破棄することによりトラフィックを振り分けるクラスタシステムであって、
    （ａ）各クラスタメンバの受信インタフェースとプロトコル処理部との間に、パケットの所定部分から整数値を計算する計算規則と自身に割り当てられた整数値とを保持する受信側振り分けフィルタを備え、
    前記受信側振り分けフィルタでは、パケットごとに前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、プロトコル処理部の受信処理に該パケットを受け渡し、
    さらに、前記受信側振り分けフィルタに、現用系と予備系で同一数値を割り当て、
    さらに、計算規則により得られる計算結果の整数値の集合を各クラスタメンバですきまなく分担するように整数値を割り当てることで、トラフィックの振り分けとプロトコルの冗長処理を可能とし、
    （ｂ）さらに、各クラスタメンバのプロトコル処理部とアプリケーションプログラムとの間に、受信パケットが含むアプリケーションデータから整数値を計算する計算規則と、各クラスタメンバに割り当てられた整数値の一覧による振り分け規則とを保持する振り分け・冗長処理部を備え、
    前記振り分け・冗長処理部では、前記振り分け規則に従って受信データから計算した整数値を割り当てられたクラスタメンバに該当データを転送し、転送先クラスタメンバのアプリケーションプログラムが読み込み処理を実行したときに該当データの読み込み処理を実行させ、
    さらに、前記振り分け・冗長処理部は、アプリケーションプログラムが書き込んだデータに対して、その送信処理に利用されるヘッダ情報から、受信側振り分けフィルタと同一の規則にて整数値を計算する計算規則と、各クラスタメンバに割り当てられた整数値の一覧とを保持し、アプリケーションプログラムが書き込んだデータに対して、前記計算規則に従って整数値を計算し、該当整数値を割り当てられた複数のクラスタメンバに対して書き込みデータを転送することで、アプリケーション処理と冗長化されたプロトコル処理メンバの割り当てを独立に制御可能とし、
    （ｃ）さらに、各クラスタメンバの送信側インタフェースとプロトコル処理部との間に、予備メンバとして処理されたパケットを破棄する送信側パケットフィルタとを備えることを特徴とするクラスタシステム。
  13. 複数のクラスタメンバを備え、且つ、
    前記複数のクラスタメンバが、それぞれ、
    プロトコル処理を行うプロトコル処理部と、
    呼出しの種類に応じて前記プロトコル処理部からデータを読込むか或いは前記プロトコル処理部にデータを書込む通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの前記通信ＡＰＩ部に対する呼出しを捕捉して前記アプリケーションプログラムに代わって前記通信ＡＰＩ部を呼出し、該呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータ或いは前記呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部に書込むデータに対して前記呼出しの種類に応じた処理を行うと共に、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う捕捉部とを備えたことを特徴とするサーバクラスタ。
  14. 複数のクラスタメンバを備え、且つ、
    前記複数のクラスタメンバの内の現用系として動作するクラスタメンバが、
    プロトコル処理を行う現用系プロトコル処理部と、
    読込み呼出しに応答して前記現用系プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記現用系プロトコル処理部に書込む現用系通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを前記アプリケーションプログラムに渡し、書込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して書込み呼出しを行う現用系呼出し捕捉部と、
    該現用系呼出し捕捉部が書込み呼出しを捕捉した場合、自クラスタメンバの予備系となるクラスタメンバに対して、書込みデータの複製データを転送する現用系転送部とを備え、
    前記複数のクラスタメンバの内の、予備系として動作するクラスタメンバが、
    プロトコル処理を行う予備系プロトコル処理部と、
    読込み呼出しに応答して前記予備系プロトコル処理部からデータを読み出し、書込み呼出しに応答して前記予備系プロトコル処理部にデータを書込む予備系通信ＡＰＩ部と、
    前記現用系転送部から複製データが転送されてきたとき、前記予備系通信ＡＰＩ部に対して書込み呼出しを行い、前記複製データを前記予備系プロトコル処理部に書込ませる予備系書込み部と、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する破棄部とを備えたことを特徴とするサーバクラスタ。
  15. 請求の範囲１４記載のサーバクラスタにおいて、
    前記現用系転送部が、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだ読込みデータの複製データを、自クラスタメンバの予備系となるクラスタメンバへ送信し、
    前記予備系として動作するクラスタメンバが、前記現用系から送られてきた読込みデータの複製データと前記予備系プロトコル処理部を介して受信したデータとを照合し、照合結果を前記複製データの転送元のクラスタメンバに対して通知する予備系照合部を備え、且つ、
    前記現用系呼出し捕捉部が、前記予備系照合部から通知された照合結果が不一致を示している場合は、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを破棄することを特徴とするサーバクラスタ。
  16. 請求の範囲１５記載のサーバクラスタにおいて、
    前記予備系書込み部が、前記予備系プロトコル処理部において前記書込みデータの複製データに対するプロトコル処理が正常終了したか否かを示す書込み結果を、前記複製データの転送元のクラスタメンバに対して通知し、
    前記現用系呼出し捕捉部が、前記予備系書込み部から通知された書込み結果が異常終了を示している場合は、書込み呼出しにより書込みが指示されているデータを破棄することを特徴とするサーバクラスタ。
  17. 請求の範囲１４記載のサーバクラスタにおいて、
    前記予備系のクラスタメンバが、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットを示す送信通知を前記現用系のクラスタメンバへ送信する送信通知送信部を備え、
    前記現用系のクラスタメンバが、
    確認応答バッファと、
    送信パケットの宛先の対向装置から前記送信パケットに対する確認応答が送られてきたとき、前記予備系のクラスタメンバから前記送信パケットを示す送信通知が送られてきていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系のクラスタメンバから送信通知が送られてきたとき、該送信通知が示す送信パケットに対する確認応答が前記確認応答バッファに格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするサーバクラスタ。
  18. 請求の範囲１７記載のサーバクラスタにおいて、
    前記送信通知が、前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットのシーケンス番号を含み、
    前記現用系のクラスタメンバが、
    予備系送信履歴記憶部と、
    前記予備系のクラスタメンバから送られてきた送信通知に含まれているシーケンス番号を前記予備系送信履歴記憶部に格納する送信通知受信部とを備え、
    前記受信パケット制御部が、送信パケットの宛先の対向装置から前記送信パケットのシーケンス番号を含んだ確認応答が送られてきたとき、前記予備系通信履歴記憶部に前記シーケンス番号が格納されていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系送信履歴記憶部にシーケンス番号が登録されたとき、前記確認応答バッファに前記シーケンス番号に対応する確認応答が格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信することを特徴とするサーバクラスタ。
  19. 請求の範囲１４記載のサーバクラスタにおいて、
    前記予備系のクラスタメンバが、
    受信したパケットを示す受信通知を前記現用系のクラスタメンバへ送信する受信通知送信部を備え、
    前記現用系のクラスタメンバが、
    受信パケットバッファと、
    パケットを受信したとき、前記予備系のクラスタメンバから前記パケットを示す受信通知が送られてきていないことを条件にして、前記パケットを前記受信パケットバッファに登録し、前記予備系のクラスタメンバから受信通知が送られてきたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするサーバクラスタ。
  20. 請求の範囲１９記載のサーバクラスタにおいて、
    前記受信通知が、受信したパケットの識別子を含み、
    前記現用系のクラスタメンバが、
    予備系受信履歴記憶部と、
    前記予備系のクラスタメンバから送られてきた受信通知に含まれている識別子を前記予備系受信履歴記憶部に登録する受信通知受信部とを備え、
    前記受信パケット制御部が、パケットを受信したとき、前記予備系受信履歴記憶部に前記パケットの識別子が格納されていないことを条件にして、前記パケットを前記受信パケットバッファに格納し、前記予備系受信履歴記憶部にパケットの識別子が格納されたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信することを特徴とするサーバクラスタ。
  21. 請求の範囲１７記載のサーバクラスタにおいて、
    前記現用系のクラスタメンバ及び前記予備系のクラスタメンバが、
    プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる構成を有することを特徴とするサーバクラスタ。
  22. 複数のクラスタメンバを備え、且つ、
    前記複数のクラスタメンバが、それぞれ、
    プロトコル処理を行うプロトコル処理部と、
    予め定められているプロトコル処理用振り分け規則に基づいて、受信パケットが自クラスタメンバで処理すべき受信パケットであると判断した場合、前記受信パケットを前記プロトコル処理部に渡す受信側振り分けフィルタと、
    読込み呼出しに応答して前記プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記プロトコル処理部に書込む通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、該受信データを前記アプリケーションプログラムに渡し、他のクラスタメンバから送られてきた送信データである場合には、該送信データを前記プロトコル処理部に渡し、それ以外である場合には、前記データをアプリケーション処理振り分け部に渡し、書込み呼出しを捕捉した場合は、該捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分け部に渡す呼出し捕捉部と、
    該呼出し捕捉部から渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムに前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すアプリケーション処理振り分け部と、
    前記呼出し捕捉部から渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部に前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すプロトコル処理振り分け部と、
    前記アプリケーション処理振り分け部及びプロトコル処理振り分け部から渡されたデータを該当するクラスタメンバへ転送する転送部とを備えたことを特徴とするサーバクラスタ。
  23. 請求の範囲２２記載のサーバクラスタにおいて、
    前記アプリケーション処理用振り分け規則が、アプリケーションデータに対するハッシュ値に基づいて振り分け先を決定し、
    前記プロトコル処理用振り分け規則が、パケットのヘッダを構成するパラメータから計算されるハッシュ値に基づいて振り分け先を決定するものであることを特徴とするサーバクラスタ。
  24. 複数のクラスタメンバを備え、全クラスタメンバに同報されたトラフィックから、自身の担当部分を各メンバが拾得し、それ以外は破棄することによりトラフィックを振り分けるサーバクラスタであって、
    各クラスタメンバの送受信インタフェースとプロトコル処理部の間に、パケットの所定部分から整数値を計算する計算規則と自身に割り当てられた整数値とを保持する送信側振り分けフィルタおよび受信側振り分けフィルタを備え、
    前記受信側振り分けフィルタでは、パケットごとに前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、プロトコル処理部の受信処理に該パケットを受け渡し、
    前記送信側振り分けフィルタでは、プロトコル処理部から受け渡された送信パケットごとに、前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、パケットを送信インタフェースから送出し、
    さらに、前記受信側振り分けフィルタに、現用系と予備系で同一数値を割り当て、前記送信側振り分けフィルタに、現用系のみで上記数値を割り当てることで冗長処理を可能とし、
    さらに、計算規則により得られる計算結果の整数値の集合を各クラスタメンバですきまなく分担するように整数値を割り当てることで、トラフィックの振り分けと冗長処理を可能とすることを特徴とするサーバクラスタ。
  25. プロトコル処理を行うプロトコル処理部と、
    呼出しの種類に応じて前記プロトコル処理部からデータを読込むか或いは前記プロトコル処理部にデータを書込む通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの前記通信ＡＰＩ部に対する呼出しを捕捉して前記アプリケーションプログラムに代わって前記通信ＡＰＩ部を呼出し、該呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータ或いは前記呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部に書込むデータに対して前記呼出しの種類に応じた処理を行うと共に、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う捕捉部とを備えたことを特徴とするクラスタメンバ。
  26. プロトコル処理を行う現用系プロトコル処理部と、
    読込み呼出しに応答して前記現用系プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記現用系プロトコル処理部に書込む現用系通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを前記アプリケーションプログラムに渡し、書込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して書込み呼出しを行う現用系呼出し捕捉部と、
    該現用系呼出し捕捉部が書込み呼出しを捕捉した場合、自クラスタメンバの予備系となるクラスタメンバに対して、書込みデータの複製データを転送する現用系転送部とを備えたことを特徴とするクラスタメンバ。
  27. 請求の範囲２６記載のクラスタメンバにおいて、
    前記現用系転送部が、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだ読込みデータの複製データを、自クラスタメンバの予備系となるクラスタメンバへ送信し、前記現用系呼出し捕捉部が、予備系照合部から通知された照合結果が不一致を示している場合は、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを破棄することを特徴とするクラスタメンバ。
  28. 請求の範囲２７記載のクラスタメンバにおいて、
    前記現用系呼出し捕捉部が、予備系書込み部から通知された書込み結果が異常終了を示している場合は、書込み呼出しにより書込みが指示されているデータを破棄することを特徴とするクラスタメンバ。
  29. 請求の範囲２６記載のクラスタメンバにおいて、
    確認応答バッファと、
    送信パケットの宛先の対向装置から前記送信パケットに対する確認応答が送られてきたとき、前記予備系のクラスタメンバから前記送信パケットを示す送信通知が送られてきていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系のクラスタメンバから送信通知が送られてきたとき、該送信通知が示す送信パケットに対する確認応答が前記確認応答バッファに格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするクラスタメンバ。
  30. 請求の範囲２６記載のクラスタメンバにおいて、
    予備系送信履歴記憶部と、
    確認応答バッファと、
    前記予備系のクラスタメンバから送られてきた送信通知に含まれているシーケンス番号を前記予備系送信履歴記憶部に格納する送信通知受信部と、
    送信パケットの宛先の対向装置から前記送信パケットのシーケンス番号を含んだ確認応答が送られてきたとき、前記予備系通信履歴記憶部に前記シーケンス番号が格納されていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系送信履歴記憶部にシーケンス番号が登録されたとき、前記確認応答バッファに前記シーケンス番号に対応する確認応答が格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするクラスタメンバ。
  31. 請求の範囲２６記載のクラスタメンバにおいて、
    受信パケットバッファと、
    パケットを受信したとき、前記予備系のクラスタメンバから前記パケットを示す受信通知が送られてきていないことを条件にして、前記パケットを前記受信パケットバッファに登録し、前記予備系のクラスタメンバから受信通知が送られてきたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするクラスタメンバ。
  32. 請求の範囲２６記載のクラスタメンバにおいて、
    予備系受信履歴記憶部と、
    受信パケットバッファと、
    前記予備系のクラスタメンバから送られてきた受信通知に含まれている識別子を前記予備系受信履歴記憶部に登録する受信通知受信部と、
    パケットを受信したとき、前記予備系受信履歴記憶部に前記パケットの識別子が格納されていないことを条件にして、前記パケットを前記受信パケットバッファに格納し、前記予備系受信履歴記憶部にパケットの識別子が格納されたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信する受信パケット制御部とを備えたことを特徴とするクラスタメンバ。
  33. 請求の範囲２９記載のクラスタメンバにおいて、
    プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる構成を有することを特徴とするクラスタメンバ。
  34. プロトコル処理を行う予備系プロトコル処理部と、
    読込み呼出しに応答して前記予備系プロトコル処理部からデータを読込み、書込み呼出しに応答して前記予備系プロトコル処理部にデータを書込む予備系通信ＡＰＩ部と、
    現用系のクラスタメンバから複製データが転送されてきたとき、前記予備系通信ＡＰＩ部に対して書込み呼出しを行い、前記複製データを前記予備系プロトコル処理部に書込ませる予備系書込み部と、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する破棄部とを備えたことを特徴とするクラスタメンバ。
  35. 請求の範囲３４記載のクラスタメンバにおいて、
    現用系のクラスタメンバから送られてきた読込みデータの複製データと前記予備系プロトコル処理部を介して受信したデータとを照合し、照合結果を前記複製データの転送元のクラスタメンバに対して通知する予備系照合部を備えたことを特徴とするクラスタメンバ。
  36. 請求の範囲３５記載のクラスタメンバにおいて、
    前記予備系書込み部が、前記予備系プロトコル処理部において前記書込みデータの複製データに対するプロトコル処理が正常終了したか否かを示す書込み結果を、前記複製データの転送元のクラスタメンバに対して通知することを特徴とするクラスタメンバ。
  37. 請求の範囲３４記載のクラスタメンバにおいて、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットを示す送信通知を前記現用系のクラスタメンバへ送信する送信通知送信部を備えたことを特徴とするクラスタメンバ。
  38. 請求の範囲３４記載のクラスタメンバにおいて、
    受信したパケットを示す受信通知を前記現用系のクラスタメンバへ送信する受信通知送信部を備えたことを特徴とするクラスタメンバ。
  39. 請求の範囲３７記載のクラスタメンバにおいて、
    前記予備系のクラスタメンバが、
    プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる構成を有することを特徴とするクラスタメンバ。
  40. プロトコル処理を行うプロトコル処理部と、
    予め定められているプロトコル処理用振り分け規則に基づいて、受信パケットが自クラスタメンバで処理すべき受信パケットであると判断した場合、前記受信パケットを前記プロトコル処理部に渡す受信側振り分けフィルタと、
    読込み呼出しに応答して前記プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記プロトコル処理部に書込む通信ＡＰＩ部と、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、該受信データを前記アプリケーションプログラムに渡し、他のクラスタメンバから送られてきた送信データである場合には、該送信データを前記プロトコル処理部に渡し、それ以外である場合には、前記データをアプリケーション処理振り分け部に渡し、書込み呼出しを捕捉した場合は、該捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分け部に渡す呼出し捕捉部と、
    該呼出し捕捉部から渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムに前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すアプリケーション処理振り分け部と、
    前記呼出し捕捉部から渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部に前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すプロトコル処理振り分け部と、
    前記アプリケーション処理振り分け部及びプロトコル処理振り分け部から渡されたデータを該当するクラスタメンバへ転送する転送部とを備えたことを特徴とするクラスタメンバ。
  41. 請求の範囲４０記載のクラスタメンバにおいて、
    前記アプリケーション処理用振り分け規則が、アプリケーションデータに対するハッシュ値に基づいて振り分け先を決定し、
    前記プロトコル処理用振り分け規則が、パケットのヘッダを構成するパラメータから計算されるハッシュ値に基づいて振り分け先を決定するものであることを特徴とするクラスタメンバ。
  42. 送受信インタフェースとプロトコル処理部の間に、パケットの所定部分から整数値を計算する計算規則と自身に割り当てられた整数値とを保持する送信側振り分けフィルタおよび受信側振り分けフィルタを備え、
    前記受信側振り分けフィルタでは、パケットごとに前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、プロトコル処理部の受
    信処理に該パケットを受け渡し、
    前記送信側振り分けフィルタでは、プロトコル処理部から受け渡された送信パケットごとに、前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、パケットを送信インタフェースから送出し、
    さらに、前記受信側振り分けフィルタに、現用系と予備系で同一数値を割り当て、前記送信側振り分けフィルタに、現用系のみで上記数値を割り当てることで冗長処理を可能とし、
    さらに、計算規則により得られる計算結果の整数値の集合を各クラスタメンバですきまなく分担するように整数値を割り当てることで、トラフィックの振り分けと冗長処理を可能とすることを特徴とするクラスタメンバ。
  43. 現用系として動作する現用系クラスタメンバが、自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって現用系通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記現用系通信ＡＰＩ部が現用系プロトコル処理部から読込んだデータを前記アプリケーションプログラムに渡し、書込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して書込み呼出しを行う現用系呼出し捕捉ステップと、
    前記現用系クラスタメンバが、前記現用系呼出し捕捉ステップで書込み呼出しを捕捉した場合、自クラスタメンバの予備系となるクラスタメンバに対して、書込みデータの複製データを転送する現用系転送ステップと、
    予備系として動作する予備系クラスタメンバが、前記現用系クラスタメンバから複製データが転送されてきたとき、予備系通信ＡＰＩ部に対して書込み呼出しを行い、前記複製データを予備系プロトコル処理部に書込ませる予備系書込みステップと、
    前記予備系クラスタメンバが、前記予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する破棄ステップとを含むことを特徴とするクラスタメンバの冗長化方法。
  44. 請求の範囲４３記載のクラスタメンバの冗長化方法において、
    前記予備系クラスタメンバが、前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットを示す送信通知を前記現用系のクラスタメンバへ送信する送信通知送信ステップと、
    前記現用系クラスタメンバが、送信パケットの宛先の対向装置から前記送信パケットに対する確認応答が送られてきたとき、前記予備系クラスタメンバから前記送信パケットを示す送信通知が送られてきていないことを条件にして、前記確認応答を確認応答バッファに格納し、前記予備系クラスタメンバから送信通知が送られてきたとき、該送信通知が示す送信パケットに対する確認応答が前記確認応答バッファに格納されていることを条件にして、前記確認応答を前記予備系クラスタメンバへ送信する受信パケット制御ステップとを含むことを特徴とするクラスタメンバの冗長化方法。
  45. 請求の範囲４３記載のクラスタメンバの冗長化方法において、
    前記予備系クラスタメンバが、受信したパケットを示す受信通知を前記現用系のクラスタメンバへ送信する受信通知送信ステップと、
    前記現用系クラスタメンバが、パケットを受信したとき、前記予備系クラスタメンバから前記パケットを示す受信通知が送られてきていないことを条件にして、前記パケットを受信パケットバッファに登録し、前記予備系クラスタメンバから受信通知が送られてきたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信する受信パケット制御ステップとを含むことを特徴とするクラスタメンバの冗長化方法。
  46. 請求の範囲４４記載のクラスタメンバの冗長化方法において、
    前記現用系のクラスタメンバが、プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる現用系側遅延ステップと、
    前記予備系のクラスタメンバが、プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる予備系側遅延ステップとを含むことを特徴とするクラスタメンバの冗長化方法。
  47. クラスタメンバが、予め定められているプロトコル処理用振り分け規則に基づいて、受信パケットが自クラスタメンバで処理すべき受信パケットであると判断した場合、前記受信パケットをプロトコル処理部に渡す受信側振り分けステップと、
    前記クラスタメンバが、自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記通信ＡＰＩ部がプロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、該受信データを前記アプリケーションプログラムに渡し、他のクラスタメンバから送られてきた送信データである場合には、該送信データを前記プロトコル処理部に渡し、それ以外である場合には、前記データをアプリケーション処理振り分けステップに渡し、書込み呼出しを捕捉した場合は、該捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分けステップに渡す呼出し捕捉ステップと、
    前記クラスタメンバが、呼出し捕捉ステップから渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムに前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送ステップに渡すアプリケーション処理振り分けステップと、
    前記クラスタメンバが、前記呼出し捕捉ステップから渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部に前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送ステップに渡すプロトコル処理振り分けステップと、
    前記アプリケーション処理振り分けステップ及びプロトコル処理振り分けステップから渡されたデータを該当するクラスタメンバへ転送する転送ステップとを含むことを特徴とする負荷分散方法。
  48. 複数のクラスタメンバを備え、全クラスタメンバに同報されたトラフィックから、自身の担当部分を各メンバが拾得し、それ以外は破棄することによりトラフィックを振り分けるクラスタシステムにおける冗長化負荷分散方法であって、
    各クラスタメンバの送受信インタフェースとプロトコル処理部の間に、パケットの所定部分から整数値を計算する計算規則と自身に割り当てられた整数値とを保持する送信側振り分けフィルタおよび受信側振り分けフィルタが設けられ、
    前記受信側振り分けフィルタでは、パケットごとに前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、プロトコル処理部の受信処理に該パケットを受け渡し、
    前記送信側振り分けフィルタでは、プロトコル処理部から受け渡された送信パケットごとに、前記計算規則により整数値を計算し、計算結果が前記自身に割り当てられた整数値と等しい場合のみ、パケットを送信インタフェースから送出し、
    さらに、前記受信側振り分けフィルタに、現用系と予備系で同一数値を割り当て、前記送信側振り分けフィルタに、現用系のみで上記数値を割り当てることで冗長処理を可能とし、
    さらに、計算規則により得られる計算結果の整数値の集合を各クラスタメンバですきまなく分担するように整数値を割り当てることで、トラフィックの振り分けと冗長処理を可能とすることを特徴とする冗長化負荷分散方法。
  49. コンピュータを、
    プロトコル処理を行うプロトコル処理部、
    呼出しの種類に応じて前記プロトコル処理部からデータを読込むか或いは前記プロトコル処理部にデータを書込む通信ＡＰＩ部、
    自クラスタメンバ上で動作するアプリケーションプログラムからの前記通信ＡＰＩ部に対する呼出しを捕捉して前記アプリケーションプログラムに代わって前記通信ＡＰＩ部を呼出し、該呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータ或いは前記呼出しに従って前記通信ＡＰＩ部が前記プロトコル処理部に書込むデータに対して前記呼出しの種類に応じた処理を行うと共に、他のクラスタメンバから送られてきたデータに対して、そのデータの種類に応じた処理を行う捕捉部として機能させるためのプログラム。
  50. コンピュータを、
    プロトコル処理を行う現用系プロトコル処理部、
    読込み呼出しに応答して前記現用系プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記現用系プロトコル処理部に書込む現用系通信ＡＰＩ部、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを前記アプリケーションプログラムに渡し、書込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記現用系通信ＡＰＩ部に対して書込み呼出しを行う現用系呼出し捕捉部、
    該現用系呼出し捕捉部が書込み呼出しを捕捉した場合、自クラスタメンバの予備系となるクラスタメンバに対して、書込みデータの複製データを転送する現用系転送部として機能させるプログラム。
  51. 請求の範囲５０記載のプログラムにおいて、
    前記現用系転送部が、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだ読込みデータの複製データを、自クラスタメンバの予備系となるクラスタメンバへ送信し、
    前記現用系呼出し捕捉部が、予備系照合部から通知された照合結果が、不一致を示している場合は、前記現用系通信ＡＰＩ部が前記現用系プロトコル処理部から読込んだデータを破棄することを特徴とするプログラム。
  52. 請求の範囲５１記載のプログラムにおいて、
    前記現用系呼出し捕捉部が、予備系書込み部から通知された書込み結果が異常終了を示している場合は、書込み呼出しにより書込みが指示されているデータを破棄することを特徴とするプログラム。
  53. 請求の範囲５０記載のプログラムにおいて、
    前記コンピュータが確認応答バッファを備え、且つ、
    前記コンピュータを、送信パケットの宛先の対向装置から前記送信パケットに対する確認応答が送られてきたとき、前記予備系のクラスタメンバから前記送信パケットを示す送信通知が送られてきていないことを条件にして、前記確認応答を前記確認応答バッファに格納し、前記予備系のクラスタメンバから送信通知が送られてきたとき、該送信通知が示す送信パケットに対する確認応答が前記確認応答バッファに格納されていることを条件にして、前記確認応答を前記予備系のクラスタメンバへ送信する受信パケット制御部として機能させるためのプログラム。
  54. 請求の範囲５０記載のプログラムにおいて、
    前記コンピュータが、受信パケットバッファを備え、且つ、
    前記コンピュータを、パケットを受信したとき、前記予備系のクラスタメンバから前記パケットを示す受信通知が送られてきていないことを条件にして、前記パケットを前記受信パケットバッファに登録し、前記予備系のクラスタメンバから受信通知が送られてきたとき、前記受信パケットバッファに前記受信通知が示すパケットよりも以前に受信したパケットが登録されていることを条件にして前記以前に受信したパケットを前記予備系のクラスタメンバへ送信する受信パケット制御部として機能させるためのプログラム。
  55. 請求の範囲５３記載のプログラムにおいて、
    前記コンピュータを、
    プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる遅延部として機能させるためのプログラム。
  56. コンピュータを、
    プロトコル処理を行う予備系プロトコル処理部、
    読込み呼出しに応答して前記予備系プロトコル処理部からデータを読込み、書込み呼出しに応答して前記予備系プロトコル処理部にデータを書込む予備系通信ＡＰＩ部、
    現用系のクラスタメンバから複製データが転送されてきたとき、前記予備系通信ＡＰＩ部に対して書込み呼出しを行い、前記複製データを前記予備系プロトコル処理部に書込ませる予備系書込み部、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ受信データ及び送信データを破棄する破棄部として機能させるためのプログラム。
  57. 請求の範囲５６記載のプログラムにおいて、
    前記コンピュータを、
    現用系のクラスタメンバから送られてきた読込みデータの複製データと前記予備系プロトコル処理部を介して受信したデータとを照合し、照合結果を前記複製データの転送元のクラスタメンバに対して通知する予備系照合部として機能させるためのプログラム。
  58. 請求の範囲５７記載のプログラムにおいて、
    前記予備系書込み部が、前記予備系プロトコル処理部において前記書込みデータの複製データに対するプロトコル処理が正常終了したか否かを示す書込み結果を、前記複製データの転送元のクラスタメンバに対して通知することを特徴とするプログラム。
  59. 請求の範囲５６記載のプログラムにおいて、
    前記コンピュータを、
    前記予備系プロトコル処理部によるプロトコル処理が済んだ送信パケットを示す送信通知を前記現用系のクラスタメンバへ送信する送信通知送信部として機能させるためのプログラム。
  60. 請求の範囲５６記載のプログラムにおいて、
    前記コンピュータを、
    受信したパケットを示す受信通知を前記現用系のクラスタメンバへ送信する受信通知送信部として機能させるためのプログラム。
  61. 請求の範囲５９記載のプログラムにおいて、
    前記コンピュータを、
    プロトコル処理の送信バッファを監視し、送信バッファが空になるまで次の書き込み処理を遅延させる遅延部として機能させるためのプログラム。
  62. コンピュータを、
    プロトコル処理を行うプロトコル処理部、
    予め定められているプロトコル処理用振り分け規則に基づいて、受信パケットが自クラスタメンバで処理すべき受信パケットであると判断した場合、前記受信パケットを前記プロトコル処理部に渡す受信側振り分けフィルタ、
    読込み呼出しに応答して前記プロトコル処理部からデータを読込み、書込み呼出しに応答して該書込み呼出しによって書込みが指示されているデータを前記プロトコル処理部に書込む通信ＡＰＩ部、
    自クラスタメンバ上で動作するアプリケーションプログラムからの読込み呼出し或いは書込み呼出しを捕捉し、読込み呼出しを捕捉した場合には前記アプリケーションプログラムに代わって前記通信ＡＰＩ部に対して読込み呼出しを行い、該読込み呼出しに応答して前記通信ＡＰＩ部が前記プロトコル処理部から読込んだデータが、他のクラスタメンバから送られてきた受信データである場合には、該受信データを前記アプリケーションプログラムに渡し、他のクラスタメンバから送られてきた送信データである場合には、該送信データを前記プロトコル処理部に渡し、それ以外である場合には、前記データをアプリケーション処理振り分け部に渡し、書込み呼出しを捕捉した場合は、該捕捉した書込み呼出しによって書込みが指示されている送信データをプロトコル処理振り分け部に渡す呼出し捕捉部、
    該呼出し捕捉部から渡されたデータに対するアプリケーション処理を担当するクラスタメンバを、予め定められているアプリケーション処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には、自クラスタメンバ上のアプリケーションプログラムに前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すアプリケーション処理振り分け部、 前記呼出し捕捉部から渡されたデータに対するプロトコル処理を担当するクラスタメンバを、予め定められているプロトコル処理用振り分け規則に従って決定し、該決定したクラスタメンバが自クラスタメンバである場合には自クラスタメンバ上のプロトコル処理部に前記データを渡し、前記決定したクラスタメンバが他のクラスタメンバである場合には、前記データを転送部に渡すプロトコル処理振り分け部、
    前記アプリケーション処理振り分け部及びプロトコル処理振り分け部から渡されたデータを該当するクラスタメンバへ転送する転送部として機能させるためのプログラム。
JP2008523702A 2006-07-06 2007-07-04 クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法 Active JP5278677B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008523702A JP5278677B2 (ja) 2006-07-06 2007-07-04 クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2006186503 2006-07-06
JP2006186503 2006-07-06
JP2006331798 2006-12-08
JP2006331798 2006-12-08
PCT/JP2007/063346 WO2008004569A1 (fr) 2006-07-06 2007-07-04 Système à configuration en grappe, grappe pour serveur, élément de grappe, procédé permettant de rendre un élément de grappe redondant, et procédé de distribution de la charge
JP2008523702A JP5278677B2 (ja) 2006-07-06 2007-07-04 クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法

Publications (2)

Publication Number Publication Date
JPWO2008004569A1 JPWO2008004569A1 (ja) 2009-12-03
JP5278677B2 true JP5278677B2 (ja) 2013-09-04

Family

ID=38894536

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008523702A Active JP5278677B2 (ja) 2006-07-06 2007-07-04 クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法

Country Status (4)

Country Link
US (1) US8555295B2 (ja)
JP (1) JP5278677B2 (ja)
CN (1) CN101484879B (ja)
WO (1) WO2008004569A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8549487B2 (en) * 2008-10-29 2013-10-01 International Business Machines Corporation Automated identification of redundant method calls
JP5556086B2 (ja) * 2009-08-25 2014-07-23 日本電気株式会社 二重化システム、及び、二重化方法
JP5532849B2 (ja) * 2009-11-20 2014-06-25 富士通株式会社 コンピュータ、プロセス間通信プログラム、およびプロセス間通信方法
CN101714916B (zh) * 2009-11-26 2013-06-05 华为数字技术（成都）有限公司 一种备份方法、设备和系统
JP5553425B2 (ja) * 2010-06-08 2014-07-16 日本電信電話株式会社 マルチキャスト配信システム、配信ルータ、および、マルチキャスト配信方法
WO2012042607A1 (ja) * 2010-09-29 2012-04-05 株式会社トライテック 分散コンピューティングシステム
EP2645261B1 (en) * 2010-11-26 2018-09-26 Fujitsu Limited Management apparatus, management system, management method and set of an application source program, a first program and a second program
US8776207B2 (en) * 2011-02-16 2014-07-08 Fortinet, Inc. Load balancing in a network with session information
US8589480B2 (en) * 2011-05-24 2013-11-19 Sony Computer Entertainment America Llc Automatic performance and capacity measurement for networked servers
US8763018B2 (en) * 2011-08-22 2014-06-24 Solarflare Communications, Inc. Modifying application behaviour
JP2013088826A (ja) * 2011-10-13 2013-05-13 Hitachi Ltd 冗長系システムにおけるデータ入力方式
JP5863383B2 (ja) * 2011-10-21 2016-02-16 株式会社日立製作所 通信ノード装置、システム、及び方法
JP6011109B2 (ja) * 2012-07-26 2016-10-19 日本電気株式会社 情報処理システム及び情報処理方法
US9106542B2 (en) * 2012-08-24 2015-08-11 Qualcomm Innovation Center, Inc. System and method for network traffic aggregation and analysis of mobile devices using socket wrappers
KR102066843B1 (ko) * 2013-07-15 2020-01-16 삼성전자 주식회사 통신 기록 정보를 이용한 그룹 형성 방법 및 장치
CN104424034A (zh) * 2013-09-04 2015-03-18 华为技术有限公司 硬件资源访问方法及装置
US9516108B1 (en) 2014-10-31 2016-12-06 Servicenow, Inc. Distributed backup system
CA2980196A1 (en) * 2015-03-20 2016-09-29 Royal Bank Of Canada System and methods for message redundancy
US10776385B2 (en) 2016-12-02 2020-09-15 Vmware, Inc. Methods and apparatus for transparent database switching using master-replica high availability setup in relational databases
US10873501B2 (en) * 2016-12-09 2020-12-22 Vmware, Inc. Methods, systems and apparatus to propagate node configuration changes to services in a distributed environment
CN110650059B (zh) * 2019-10-12 2022-06-10 未鲲(上海)科技服务有限公司 故障群集检测方法、装置、计算机设备和存储介质
US20240031288A1 (en) * 2022-07-19 2024-01-25 Cisco Technology, Inc. Systems and Methods for Stateless Symmetric Forwarding

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6139656A (ja) * 1984-07-30 1986-02-25 Hitachi Ltd 分散形ネツトワ−クデ−タ処理システム
JPS63238655A (ja) * 1987-03-26 1988-10-04 Nec Corp 情報処理装置
JPH0336853A (ja) * 1989-07-04 1991-02-18 Kokusai Denshin Denwa Co Ltd <Kdd> Ｉｓｄｎ端末装置及びｉｓｄｎ端末の呼制御方法
JPH08180030A (ja) * 1994-12-26 1996-07-12 Mitsubishi Electric Corp 複合計算機システムのメモリ装置
JP2003517221A (ja) * 1998-11-20 2003-05-20 ネットワーク アルケミー インク． ネットワークにおける負荷分配のための方法および装置

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS58189745A (ja) * 1982-04-30 1983-11-05 Nippon Signal Co Ltd:The 多重系装置における故障検知方法
JPH0752763B2 (ja) 1986-04-09 1995-06-05 日本電気株式会社 樹脂封止型半導体装置
JPH0787536A (ja) 1993-09-13 1995-03-31 Fujitsu Ltd 集線段仮想化システム
US5961606A (en) * 1997-06-30 1999-10-05 Sun Microsystems, Inc. System and method for remote buffer allocation in exported memory segments and message passing between network nodes
JP3487197B2 (ja) 1997-11-14 2004-01-13 株式会社日立製作所 クラスタ型ルータ装置
US20020194340A1 (en) * 2001-06-16 2002-12-19 Ebstyne Bryan D. Enterprise storage resource management system
US6918013B2 (en) * 2001-07-16 2005-07-12 Bea Systems, Inc. System and method for flushing bean cache
US7751327B2 (en) * 2004-02-25 2010-07-06 Nec Corporation Communication processing system, packet processing load balancing device and packet processing load balancing method therefor
US7685131B2 (en) * 2006-02-28 2010-03-23 International Business Machines Corporation Web services database cluster architecture

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6139656A (ja) * 1984-07-30 1986-02-25 Hitachi Ltd 分散形ネツトワ−クデ−タ処理システム
JPS63238655A (ja) * 1987-03-26 1988-10-04 Nec Corp 情報処理装置
JPH0336853A (ja) * 1989-07-04 1991-02-18 Kokusai Denshin Denwa Co Ltd <Kdd> Ｉｓｄｎ端末装置及びｉｓｄｎ端末の呼制御方法
JPH08180030A (ja) * 1994-12-26 1996-07-12 Mitsubishi Electric Corp 複合計算機システムのメモリ装置
JP2003517221A (ja) * 1998-11-20 2003-05-20 ネットワーク アルケミー インク． ネットワークにおける負荷分配のための方法および装置

Also Published As

Publication number Publication date
JPWO2008004569A1 (ja) 2009-12-03
CN101484879A (zh) 2009-07-15
US8555295B2 (en) 2013-10-08
US20090204981A1 (en) 2009-08-13
WO2008004569A1 (fr) 2008-01-10
CN101484879B (zh) 2012-11-28

Similar Documents

Publication Publication Date Title
JP5278677B2 (ja) クラスタシステム、サーバクラスタ、クラスタメンバ、クラスタメンバの冗長化方法、負荷分散方法
US6665304B2 (en) Method and apparatus for providing an integrated cluster alias address
JP6988511B2 (ja) 障害検知方法、ノード装置、通信システム
US7346682B2 (en) System for creating and distributing prioritized list of computer nodes selected as participants in a distribution job
US6993587B1 (en) Method and apparatus for election of group leaders in a distributed network
US6934875B2 (en) Connection cache for highly available TCP systems with fail over connections
US6718361B1 (en) Method and apparatus for reliable and scalable distribution of data files in distributed networks
US6928577B2 (en) Consistent message ordering for semi-active and passive replication
Marwah et al. TCP server fault tolerance using connection migration to a backup server
US7761609B1 (en) Socket level packet scheduling for connectionless protocols
US20060164974A1 (en) Method of moving a transport connection among network hosts
CN1881944B (zh) 改进型分布式核心操作系统
US20030212738A1 (en) Remote services system message system to support redundancy of data flow
CN106134144A (zh) 可靠性组播数据传送系统以及方法
JP2002517857A (ja) 二方向的なプロセス対プロセスのバイトストリームのプロトコル
US20150082412A1 (en) Application state sharing in a firewall cluster
US7536468B2 (en) Interface method, system, and program product for facilitating layering of a data communications protocol over an active message layer protocol
EP1305924B1 (en) Method and apparatus for reliable and scalable distribution of data files in distributed networks
JP6606032B2 (ja) 輻輳通知装置、および、輻輳通知方法
JPH09186718A (ja) ネットワークの経路を制御する経路制御装置および方法
JP5630070B2 (ja) 中継装置、プログラム及び方法
WO2022180690A1 (ja) 通信システム、通信装置、データ配信方法、及びプログラム
WO2022180691A1 (ja) 通信システム、通信装置、不正判定方法、及びプログラム
JP7279388B2 (ja) ルータシステムおよびパケット送信判定方法
CN102624753A (zh) 企业服务总线的分布式文件传输方法和设备

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100615

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120824

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: 20130424

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130507

R150 Certificate of patent or registration of utility model

Ref document number: 5278677

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350