群集系统、服务器群集、群集成员、群集成员的冗余化方法、负荷分散方法

摘要

本发明提供一种群集系统，利用现用系统和备用系统双方的群集成员进行对接收通信量的协议处理。备用系统废弃完成协议处理的接收通信量，只有现用系统将接收通信量提交给AP。AP以自己的方法进行应用业务处理的冗余化。使用下位层的数据决定担当对接收通信量的协议处理的群集成员，使用完成协议处理后的上位层的数据，决定进行应用业务处理的群集成员。

说明书

技术领域

本发明涉及一种作为网络设备起作用的群集(cluster)系统，特别地涉及一种作为在内部运行应用程序的网络设备起作用的群集系统。

背景技术

到目前为止，群集系统一直被利用为：

(a)构筑提供单一功能的大规模装置的手段

(b)构筑可用性高的装置的手段。

通常，群集系统即使是单一系统，也通过设置多个实现规定功能的装置(群集成员)、同时设置用于协调各群集成员使其工作的附加机构来构成。

(利用负荷平衡器的群集系统)

虽然作为群集系统结构法已知有各种各样的方法，但比较广泛地利用在与其它系统的边界处设置负荷平衡器的结构。在图30中示出了利用负荷平衡器的群集系统1的结构实例。群集系统1包括多个群集成员11-1～11-n、和负荷平衡器12。利用负荷平衡器12将通过网络2从各节点(node)31～3m传送过来的IP包(packet)(通信数据)，分配给各群集成员11-1～11-n。

图30所示的群集系统1，具有利用负荷平衡器12，能够相对其它的系统隐蔽后段的装置结构和跳过故障(フエイルオ—バ，fail over)等的事件、容易进行负荷平衡等控制的优点。另一方面，存在所谓负荷平衡器12有可能成为瓶颈(bottleneck)的问题点。此外，为了避免负荷平衡器12成为单一障碍点，在冗余化负荷平衡器12的情况下，产生所谓结构变复杂的问题。

(广播·调度方式(broadcast·dispatch)的群集系统)

为了解决这些问题，提出一种不设置负荷平衡器的方式(广播·调度方式)的群集系统(例如参照特表2003-517221号公报)。

图31是表示广播·调度方式的群集系统1a的结构实例的方框图。群集系统1a由n台群集成员13-1～13-n构成。各群集成员13-1～13-n并列连接到可多址通信的数据链路(data link)4。各群集成员13-1～13-n分别包括分配滤波器(filter)14-1～14-n。

从其它节点31～3m向群集系统1a传送过来的IP包，通过数据链路4对各群集成员13-1～13-n进行多址通信。各群集系统13-1～13-n利用分配滤波器14-1～14-n，计算多址通信的IP包的哈希(hash)值(例如，相对于首(head)部中所含的发送源地址的哈希值)，仅在计算出的哈希值与分配给自群集成员的运行哈希值相等的情况下进行对已接收的IP包的接收处理。像这样，在广播·调度方式的群集系统1a中，向全部群集成员13-1～13-n多址通信从其它节点31～3m传送过来的IP包。各群集成员13-1～13-n仅处理对应于分配给自群集成员的运行哈希值的IP包。由此实现负荷分散。

并且，在广播·调度方式的群集系统中，如果对2台以上的群集成员分配相同的运行哈希值，则将会利用多个群集成员冗余地处理相同的IP包。由此，不明示地进行状态复制就能进行通信的冗余处理。由此，能够提高可量测性(scalability)和可用性。

可是，广播·调度方式的群集系统以转接包的路由器等的装置作为开发对象。这些装置中，大多是如下这种装置，特点是对包的处理一直都停留在比较低的协议(protocol)阶段，由于不进行包内的应用层的处理等，所以通过比较单纯的处理能够高速地转接包。

图32是表示图31所示的群集成员13-1的结构实例的方框图，图33A、图33B是用于说明图31所示的群集系统1a的动作的图。

参照图32，群集成员13-1包括：用于连接到与邻接节点通信的数据链路4的接收接口141及发送接口142；进行包的处理及传输的协议处理部121、122、…、12k；两个包滤波器，即接收侧分配滤波器131和发送侧分配滤波器132；以及设定滤波器131、132的滤波器控制部133。

各个滤波器131、132，基于包首等利用哈希函数计算整数值，仅在通过滤波器控制部133分配给相应的滤波器131、132的整数值与计算结果的整数值相等的情况下，使包通过。在图33A、33B的例子中，有4台群集成员，为了简便，使用1～4四种哈希值。

当利用此结构时，如果对不同的群集成员的接收侧分配滤波器设定相同哈希值的话，则在这些群集成员中会冗余地处理相同的包。由此，冗余地处理对应于相应哈希值的通信量(traffic)。并且，为了防止将相同的包传送到多个系统外，仅就上述群集成员中的1台群集成员对发送侧分配滤波器设定相应哈希值。例如，在图33A的例子中，应当清楚，利用左端及其右边相邻的群集成员冗余地处理相当于哈希值2的通信量，复制流动(flow)状态。

此外，如果将符合哈希函数数值范围的值的集合分配给接收侧分配滤波器以使各群集成员无空隙、不重复地运行，就能够实现通信量的负荷分散。例如，虽然图33A和33B的结构相同，但利用基于处理对象包所计算出的哈希值，切换处理群集成员，实现负荷分散。通过组合利用它们，就能够实现广播·路由群集。

另外，作为相关技术，列举以下文献。在日本特开2000-83045号公报中，记载了一种用于提供对应于因网络的大规模化而导致的路由器线路增强的需求、扩张性高的路由器构成技术的路径控制技术。在日本特开平3-36853号公报中，记载了一种以简化应用业务部的软件结构并且能进行高性能的调出及调入的呼叫控制为目的的ISDN终端装置及ISDN终端的呼叫控制方法。在日本特开平7-87536号公报中，记载了一种交换机的集线虚拟化系统。此系统结构为：将处于同一交换机内或交换机外的加入者集线装置的控制功能隐蔽在公用功能内，不会感觉到在呼叫控制应用中有无集线功能。

发明内容

另一方面，在作为主节点(host node)进行终端通信的服务器等装置中，处理普通应用程序发送接收的包。即，在如图34所示的主节点H中，利用应用程序110，处理通过接收接口141、发送接口142、协议处理部121、122、…、12k、读取API(Application Programming Interface)部151、写入API部152收发的包。过去，在群集化运行这种应用程序110的装置的情况下，采用以下这种方式，即利用负载平衡器按照应用程序110的策略(policy)进行负荷分散，应用程序110独自地进行状态的冗余化。但是，如果使用负载平衡器，就会如上所述，发生负载平衡器变成瓶颈等的问题。

因此，应当考虑，利用广播·调度方式群集化运行应用程序的装置。但是，在利用广播·调度方式群集化运行应用程序的装置的情况下，会产生以下课题。

(1)在应用业务处理和协议处理中存在负荷分散、冗余化策略不同的情况。

(2)应用业务必须一面保证一致性、一面冗余化其具有的复杂状态。

即，在广播·调度方式中，由于在接收IP包之后对其首部附加哈希值，所以存在不能将上位层的数据利用在通信量的分配中的情形。原因在于，例如，通过TLS(参照RFC 2246，The TLS Protocol Version 1.0.T.Dierks，C.Allen.January 1999.)、和IPsec ESP(参照RFC 4303，IPEncapsulating Security Payload(ESP).S.Kent.December 2005.)加密数据，通过IP碎片(fragmentation)分割上位层数据。因此，在这种情况下，存在即使想按照上位层的数据分配通信量，其实现也困难的情形。

例如，利用广播·调度方式的群集系统构成Web服务器(HTTP)的情况下，如果在所有群集成员中保持所有的内容，就需要大量的资源。作为此问题的对策，应当考虑根据内容的识别信息向各群集成员分配内容。但是，由于在HTTP请求内内容的识别信息被描述为URL，所以根据内容的识别信息就不能分配通信量。由此，就必须在各群集成员中事先保持所有的内容。

此外，在协议处理中，考虑传送通路中的数据的损失等，进行送达确认和再发送。由此，即使用不同的群集成员独立地处理多址的包，多数情况下在各个群集成员的协议状态中也不会产生大的差错。基于这种事实，广播·调度方式与协议处理的兼容性好。

相对于此，应用业务处理状态复杂，此外，在UNIX(登记商标)等的多处理(multiprocess)执行环境中，因进程调度等而容易产生处理时钟的偏移。由此，即使输入相同的数据，也容易产生状态错误。此外，一般来说，与协议处理相比，应用业务处理的执行更复杂，很有可能以特定的接收数据为起因而产生不适合。这种情况下，即便利用冗余系统处理多址的数据，因为不能提高可靠性，所以广播·调度方式也是不合适的。

因此，希望实现可有效支持应用业务处理和协议处理的广播·调度方式的群集系统。

可是，图32、图34所示的协议处理部121、122、…、12k，接收侧分配滤波器131等，通常由OS(operating system，操作系统)的核心(kemel)来实现，此外，应用程序110也需要通过系统调用对OS收发IP包。由此，为了满足上述愿望，例如，就需要在OS中组装用于满足上述愿望的新功能。但是，假如在OS中组装新的功能，就会产生需要进行大规模变更这样的问题。

因此，本发明的目的在于，提供一种不对OS增加大规模的变更、且能有效支持应用业务处理和协议处理的广播·调度方式的群集系统。

本发明的一实施例的群集系统或服务器群集，包括多个群集成员，并且，多个群集成员分别包括：执行协议处理的协议处理部；按照呼叫的种类从协议处理部读取数据或在协议处理部中写入数据的通信API部；以及捕捉部，捕捉来自在本群集成员上动作的应用程序的对通信API部的呼叫、替代应用程序呼叫通信API部，对根据此呼叫、通信API部从协议处理部读取的数据或根据此呼叫、通信API部在协议处理部中写入的数据进行对应于呼叫的种类的处理，同时，对从其它的群集成员传送过来的数据进行对应于此数据的种类的处理。

本发明的其它实施例的群集系统或服务器群集包括多个群集成员，并且，多个群集成员之内的作为现用系统进行工作的群集成员包括：执行协议处理的现用系统协议处理部；现用系统通信API部，对读取呼叫进行应答、从现用系统协议处理部读取数据，对写入呼叫进行应答、将按照此写入呼叫指示写入的数据写入现用系统协议处理部中；现用系统呼叫捕捉部，捕捉来自在本群集成员上动作的应用程序的读取呼叫或写入呼叫，在捕捉到读取呼叫的情况下替代应用程序对现用系统通信API部进行读取呼叫，将对此读取呼叫进行应答、现用系统通信API部从现用系统协议处理部读取的数据提交给应用程序，在捕捉到写入呼叫的情况下替代应用程序对现用系统通信API部进行写入呼叫；以及现用系统传输部，在现用系统呼叫捕捉部捕捉到写入呼叫的情况下，对成为本群集成员的备用系统的群集成员传输写入数据的复制数据。多个群集成员之内作为备用系统进行工作的群集成员包括：执行协议处理的备用系统协议处理部；备用系统通信API部，对读取呼叫进行应答、从备用系统协议处理部中读取数据，对写入呼叫进行应答、将数据写入备用系统协议处理部中；备用系统写入部，当从现用系统传输部传送过来复制数据时，对备用系统通信API部进行写入呼叫，将复制数据写入备用系统协议处理部中；以及废弃部，废弃由备用系统协议处理部已完成协议处理的接收数据及发送数据。

本发明的另一个实施例的群集系统或服务器群集包括多个群集成员。多个群集成员分别包括：执行协议处理的协议处理部；接收侧分配滤波器，根据预定的协议处理用分配规则，在判断为接收包是需要由本群集成员处理的接收包的情况下，将接收包提交给协议处理部；通信API部，应答读取呼叫、从协议处理部读取数据，对写入呼叫进行应答、将按照该写入呼叫指示写入的数据写入协议处理部中；呼叫捕捉部，捕捉来自在本群集成员上动作的应用程序的读取呼叫或写入呼叫，在捕捉到读取呼叫的情况下替代应用程序对通信API部进行读取呼叫，在对该读取呼叫进行应答、通信API部从协议处理部读取的数据是从其它的群集成员发送过来的接收数据的情况下，将该接收数据提交给应用程序，在对该读取呼叫进行应答、通信API部从协议处理部读取的数据是从其它的群集成员送过来的发送数据的情况下，将此发送数据提交给协议处理部，除此之外的情况下，将数据提交给应用业务处理分配部，在捕捉到写入呼叫的情况下，将按照捕捉到的写入呼叫而指示写入的发送数据提交给协议处理分配部；应用业务处理分配部，按照预定的应用业务处理用分配规则决定担当对呼叫捕捉部提交的数据的应用业务处理的群集成员，在决定的群集成员是本群集成员的情况下、将数据提交给本群集成员上的应用程序，在决定的群集成员是其它的群集成员的情况下、将数据提交给传输部；协议处理分配部，按照预定的协议处理用分配规则决定担当对呼叫捕捉部提交的数据的协议处理的群集成员，在决定的群集成员是本群集成员的情况下、将数据提交给本群集成员上的协议处理部，在决定的群集成员是其它的群集成员的情况下、将数据提交给传输部；以及传输部，将应用业务处理分配部及协议处理分配部提交的数据向相应的群集成员进行传送。

本发明的另一个实施例的群集系统或服务器群集包括多个群集成员，其中从在所有群集成员中多址通信的通信量中，各群集成员筛选自己的运行部分，除此之外进行废弃，由此分配通信量。群集系统或服务器群集(a)在各群集成员的接收接口和协议处理部之间包括接收侧分配滤波器，其保持根据包首等计算整数值的计算规则和分配给自己的整数值。在接收侧分配滤波器中，按照计算规则对每一包计算整数值，仅在计算结果等于分配给自己的整数值的情况下，将包接交给协议处理部的接收处理，并且在现用系统和备用系统将相同数值分配给接收侧分配滤波器，并且分配整数值以便在各群集成员中无缝分担根据计算规则得到的计算结果的整数值的集合，由此就能够进行通信量的分配和协议的冗余处理。群集系统或服务器群集(b)在各群集成员的协议处理部和应用程序之间还包括分配·冗余处理部，其保持根据含接收包的应用业务数据计算整数值的计算规则、和根据分配给各群集成员的整数值的整体的分配规则。在分配·冗余处理部中，将相应数据传送给按照分配规则分配了基于接收数据计算出的整数值的群集成员，传送对象群集成员的应用程序执行读取处理时，执行相应数据的读取处理。并且，分配·冗余处理部，对于应用程序写入的数据，保持基于在其发送处理中利用的首信息、以与接收侧分配滤波器相同的规则计算整数值的计算规则、和分配给各群集成员的整数值的整体，对于应用程序写入的数据按照计算规则计算整数值，对分配了整数值的多个群集成员传送写入数据，由此群集系统或服务器群集就能够独立地控制应用业务处理和冗余化的协议处理成员的分配。群集系统或服务器群集(c)在各群集成员的发送侧接口和协议处理部之间还包括发送侧包滤波器，废弃作为备用成员处理了的包。

本发明的另一个实施例的群集系统或服务器群集包括多个群集成员，其中从在所有群集成员中多址通信的通信量中，各群集成员筛选自己的担当部分，除此之外进行废弃，由此分配通信量。在群集系统、或各群集成员的收发接口和协议处理部之间包括发送侧分配滤波器和接收侧分配滤波器，它们保持根据包首等计算整数值的计算规则和分配给自己的整数值。在接收侧分配滤波器中，按照计算规则对每一包计算整数值，仅在计算结果等于分配给自己的整数值的情况下，将该包接交给协议处理部的接收处理。在发送侧分配滤波器中，通过对协议处理部接交的每一发送包按照计算规则计算整数值，仅在计算结果与分配给自己的整数值相等的情况下，从发送接口输出包，并且对现用系统和备用系统分配给接收侧分配滤波器相同数值，仅在现用系统内分配给发送侧分配滤波器数值，就能进行冗余处理；并且，通过分配整数值以便在各群集成员中无缝分担根据计算规则得到的计算结果的整数值的集合，就能够进行通信量的分配和冗余处理。

(作用)

在群集成员中设置有捕捉部，捕捉来自在本群集成员上进行工作的应用程序的对通信API部的呼叫。此捕捉部捕捉到呼叫时，就替代应用程序呼叫通信API部。捕捉部针对按照此呼叫、通信API部从协议处理部读取的数据或按照此呼叫、通信API部在协议处理部中写入的数据，进行对应呼叫的种类的处理。捕捉部还针对从其它群集成员发送过来的数据进行对应此数据的种类的处理。捕捉部能够设置在构成协议处理部的OS的外部。由此，能够提供一种不对OS增加大规模的变更、可有效地支持应用业务处理和协议处理的广播·调度方式的群集系统。

例如，在冗余化群集成员的情况下，作为进行上述处理的捕捉部，可在现用系统的群集成员上设置现用系统呼叫捕捉部和现用系统传输部。现用系统呼叫捕捉部捕捉来自在本群集成员上进行工作的应用程序的读取呼叫或写入呼叫。在捕捉到读取呼叫的情况下，现用系统呼叫捕捉部，替代应用程序对现用系统通信API部进行读取呼叫，对此读取呼叫进行应答，将现用系统通信API部从现用系统协议处理部读取的数据提交给应用程序。在捕捉到写入呼叫的情况下，现用系统呼叫捕捉部就替代应用程序对现用系统通信API部进行写入呼叫。现用系统呼叫捕捉部还在捕捉到写入呼叫的情况下，针对作为本群集成员的备用系统的群集成员，利用现用系统传输部传送写入数据的复制数据。

另一方面，在备用系统的群集成员上，作为捕捉部设置备用系统写入部和废弃部。备用系统写入部在现用系统传输部传送来复制数据时，对备用系统通信API部进行写入呼叫，将复制数据写入备用系统协议处理部。废弃部废弃通过备用系统协议处理部已完成协议处理的接收数据及发送数据。

通过采取这种结构，就会如图29A所示，在现用系统、备用系统的协议处理部中处理相同的发送通信量、接收通信量，并且仅在现用系统的群集成员中，进行数据发送并向应用程序接收并提交接收数据。由于现用系统的协议处理部和备用系统的协议处理部处理相同的接收通信量、发送通信量，所以其状态也就相同。

再有，应用程序能够以独自的方法进行应用程序所具有的复杂的状态的冗余化。例如，可以用以下方法进行冗余化。

1、现用系统应用程序从通信对方接收任何数据

2、现用系统应用程序基于接收数据决定管理数据的更新内容，使用进程(process)间通信和公用存储器等将相应更新内容通知给备用系统应用程序。

3、备用系统应用程序，根据来自现用系统的通知更新自己的管理数据，向现用系统应用程序应答更新成功与否。

4、现用系统应用处理程序，在备用系统应用程序的数据更新成功之后，更新自己的管理数据。

5、在正确进行以上处理后，向通信对方反馈应答。

另一方面，在进行负荷分散的情况下，在群集成员上作为捕捉部设置呼叫捕捉部、应用业务处理分配部、协议处理分配部和传输部。

呼叫捕捉部，捕捉来自在本群集成员上进行工作的应用程序的读取呼叫或写入呼叫。

在捕捉到读取呼叫的情况下，呼叫捕捉部替代应用程序对通信API部进行读取呼叫。在应答此读取呼叫通信API部从协议处理部读取的数据是从其它的群集成员发送过来的接收数据的情况下，呼叫捕捉部将读取的数据提交给应用程序。在通信API部读取的数据是从其它的群集发送过来的发送数据的情况下，呼叫捕捉部将读取的数据提交给协议处理部。除此之外的情况下，呼叫捕捉部将上述数据提交给应用业务处理分配部。

此外，在捕捉到写入呼叫的情况下，将按照捕捉到的写入呼叫而指示写入的发送数据提供给协议处理分配部。

应用业务处理分配部按照预定的应用业务处理用分配规则决定担当对从呼叫捕捉部提交的数据的应用业务处理的群集成员。而且，在决定的群集成员是本群集成员的情况下，将数据提交给本群集成员上的应用程序，在决定的群集成员是其它的群集成员的情况下，将数据提交给传输部。

此外，协议处理分配部按照预定的协议处理用分配规则决定担当对从呼叫捕捉部提交的数据的协议处理的群集成员。而且，在决定的群集成员是本群集成员的情况下，将数据提交给本群集成员上的协议处理部，在决定的群集成员是其它的群集成员的情况下，将数据提交给传输部。

传输部将从应用业务处理分配部及协议处理分配部提交的数据传送给相应的群集成员。

通过采用这种结构，就如图29B所示，能够用不同的群集成员进行对通信量的协议处理和应用业务处理。

根据本发明能够得到这种效果，即能够提供一种不对OS增加大规模的变更、可有效地支持应用业务处理和协议处理的广播·调度方式的群集系统。其理由如下。群集成员所包括的捕捉部，捕捉来自在本群集成员上进行工作的应用程序的对通信API部的呼叫，替代此应用程序呼叫通信API部。捕捉部针对按照此呼叫、通信API部从协议处理部读取的数据或按照上述呼叫、通信API部在协议处理部中写入的数据，进行对应上述呼叫的种类的处理。捕捉部还针对从其它群集成员发送过来的数据进行对应此数据的种类的处理。由于此捕捉部能够设置在构成协议处理部的OS的外部，所以能够提供一种不对OS增加大规模的变更、可有效地支持应用业务处理和协议处理的广播·调度方式的群集系统。

根据本发明，能够冗余化要求高度可靠性的基础业务用服务器装置和在网络上通信量集中的应用业务级网关(application level gateway)装置。此外，例如，关于用通信载体进行电话的呼叫控制的服务器装置等，使用即使作为单一装置也进行动作的上述服务器装置，作为增设任意台数的服务器装置进行负荷分散的群集装置，能够非常大规模地构筑处理能力大的服务器。

附图说明

图1示出在本发明相关的实施例1中使用的群集成员100的结构实例。

图2是用于说明实施例1的现用系统、备用系统的图。

图3A示出比较例的主节点H的接收读取处理(协议处理)的流程图。

图3B示出比较例的主节点H的接收读取处理(应用业务处理)的流程图。

图4A示出实施例1中的现用系统的接收读取处理(协议处理)的一个实例的流程图。

图4B示出实施例1中的现用系统的接收读取处理(应用业务处理)的一个实例的流程图。

图5A示出实施例1中的备用系统的接收读取处理的一个实例的流程图。

图5B示出实施例1中的备用系统的接收读取处理的一个实例的流程图。

图6示出实施例1的接收读取指令序列(sequence)图。

图7示出比较例的主节点H的写入发送处理的图。

图8A示出实施例1中的现用系统的写入发送处理的一个实例的图。

图8B示出实施例1中的现用系统的写入发送处理的一个实例的图。

图9是实施例1中的备用系统的写入发送处理的一个实例的图。

图10示出实施例1中的写入发送指令序列图。

图11示出实施例1中的服务器侧的通话(session)建立指令序列图。

图12示出实施例1中的客户侧的通话建立指令序列图。

图13A是用于说明本发明的实施例2的概况图。

图13B是用于说明本发明的实施例2的概况图。

图14示出本发明相关的群集系统的实施例2的结构实例的方框图。

图15示出在实施例2中使用的群集成员100a-1的结构实例的方框图。

图16A示出实施例2中的接收读取处理的一个实例的图。

图16B示出实施例2中的接收读取处理的一个实例的图。

图17A示出实施例2中的读取改址(redirect)处理的一个实例的图。

图17B示出实施例2中的读取改址处理的一个实例的图。

图18A示出实施例2中的写入发送处理的一个实例的图。

图18B示出实施例2中的写入发送处理的一个实例的图。

图19示出实施例2中的服务器侧的通话建立指令序列图。

图20示出实施例2中的服务器侧的通话建立指令序列图。

图21示出实施例2中的客户侧的通话建立指令序列图。

图22是用于说明本发明相关的群集系统的实施例3的概况图。

图23是用于说明本发明相关的群集系统的实施例3的概况图。

图24示出在实施例3中使用的群集成员100b的结构实例的方框图。

图25A示出实施例3中的接收读取处理的一个实例的流程图。

图25B示出实施例3中的接收读取处理的一个实例的流程图。

图26A示出实施例3中的读取处理的一个实例的流程图。

图26B示出实施例3中的读取处理的一个实例的流程图。

图26C示出实施例3中的读取处理的一个实例的流程图。

图26D示出实施例3中的读取处理的一个实例的流程图。

图27A示出实施例3中的API侧的写入发送处理的一个实例的流程图。

图27B示出实施例3中的API侧的写入发送处理的一个实例的流程图。

图28示出实施例3中的协议处理侧的写入发送处理的一个实例的流程图。

图29A是用于说明本发明的作用的图。

图29B是用于说明本发明的作用的图。

图30是用于说明使用负荷平衡器的技术的图。

图31是广播·调度方式的群集系统的方框图。

图32示出广播·调度方式的群集成员13-1结构的方框图。

图33A是用于说明广播·调度方式的群集系统的工作的图。

图33B是用于说明广播·调度方式的群集系统的工作的图。

图34示出应用程序工作的主节点H的结构的方框图。

图35示出在本发明的实施例4中使用的群集成员100c的结构实例的方框图。

图36示出在本发明的实施例4中使用的备用系统的接收分配滤波器1031及发送侧分配滤波器1032的结构实例的方框图。

图37示出在本发明的实施例4中使用的现用系统的接收侧分配滤波器1021的结构实例的方框图。

图38示出实施例4的备用系统的处理例的流程表。

图39A示出实施例4的现用系统的处理例的流程表。

图39B示出实施例4的现用系统的处理例的流程表。

图39C示出实施例4的现用系统的处理例的流程表。

图40是用于说明本发明相关的实施例5中所解决的问题点的图。

图41示出在实施例5中使用的群集成员的结构实例的方框图。

图42A示出实施例5的处理例的流程图。

图42B示出实施例5的处理例的流程图。

具体实施方式

接着，参照附图，详细地说明用于实施发明的最佳方式。

[本发明的实施例1]

在本发明的实施例1中，其中广播·调度方式的群集系统进行搭载了应用程序的群集成员的冗余化。通过在图31示出的这种广播·调度方式的群集系统中，替代群集成员13-1～13-n，使用图1所示的群集成员100来实现本实施例。例如，本实施例的群集系统具有服务器(服务器群集)的功能。

参照图1，本实施例相关的群集成员100包括：应用程序110，协议处理部121、122、…、12k，接收侧分配滤波器131，发送侧分配滤波器132，滤波器控制部133，接收接口141，发送接口142，作为通信API部的读取API部151，作为通信API部的写入API部152，读取API呼叫捕捉部161，写入API呼叫捕捉部162，复制部/核对部171，复制部/写入部172，控制部173，和传输部174。

如以下所示，群集成员100能够用计算机来实现。准备记录用于使计算机作为群集成员100起作用的程序的磁盘(disk)、半导体存储器、其它的记录介质。使计算机上读取上述程序。计算机通过根据读取的程序来控制自身的动作，就在本计算机上实现：协议处理部121、122、…、12k，接收侧分配滤波器131，发送侧分配滤波器132，滤波器控制部133，接收接口141，发送接口142，读取API部151，写入API部152，读取API呼叫捕捉部161，写入API呼叫捕捉部162，复制部/核对部171，复制部/写入部172，控制部173，和传输部174。

群集成员100能够具有现用群集成员、备用群集成员的任意一种功能。图2示出了群集成员100具有现用群集成员、备用群集成员的功能时的结构和收发数据的流程。图2仅抽取示出本发明的主要部分。附图中省略了：协议处理部121、122、…、12k，接收侧分配滤波器131，发送侧分配滤波器132，滤波器控制部133，接收接口141，发送接口142。

[现用群集成员结构]

参照图2，现用群集成员在读取API部151及写入API部152与应用程序110之间包括：复制部171(在具有现用群集成员功能的情况下，图1的复制部/核对部171具有图2的复制部171的功能)、复制部172(在具有现用群集成员功能的情况下，图1的复制部/写入部172具有复制部172的功能)、控制部173、传输部174、读取API呼叫捕捉部161、和写入API呼叫捕捉部162。

当应用程序110通过系统调用等呼叫读取处理时，读取API呼叫捕捉部161就捕捉此呼叫，为了在读取处理前后插入群集化处理而加以利用。关于写入API呼叫捕捉部162也进行相同操作。

复制部171、172复制读取及写入的收发数据，进行向传输部174的提交处理。

传输部174从复制部171、172收取数据，向备用群集成员传送相应数据。此外，传输部174收取通过备用群集系统的其数据的处理结果并提交给复制部171、172。

读取API部151、写入API部152提供用于进行各个实际通信的API。在图34所示的主节点H中也包括这些部件。在图2中省略了：与读取API部151、写入API部152一起设置的协议处理部121、122、…、12k，接收侧分配滤波器131，发送侧分配滤波器132，滤波器控制部133，接收接口141，发送接口142。

应用程序110呼叫读取API部151和写入API部152，进行通信处理。

控制部173执行通话(session)管理等、通信的控制处理的群集化。

[备用群集成员的结构]

备用群集成员在读取API部151及写入API部152与应用程序110之间包括：核对部171(在具有备用群集成员功能的情况下，图1的复制部/核对部171具有图2的核对部171的功能)、写入部172(在具有备用群集成员功能的情况下，图1的复制部/写入部172具有图2的写入部172的功能)、读取API呼叫捕捉部161、写入API呼叫捕捉部162、控制部173、和传输部174。控制部173在其内部包括切换通知部1731、切换控制部1732、现用监视部1733。

读取API呼叫捕捉部161、写入API呼叫捕捉部162、传输部174的功能按现用群集成员时的说明。

使用复制部/写入部172是为了使从现用群集成员传送来的写入用数据经过备用群集成员的写入API部152而返回到备用群集成员的发送处理。

核对部171收取在由现用群集成员读取的接收数据，通过经过备用群集成员自身的读取API部151进行读取处理，并进行是否读取相同内容的核对处理。

控制部173执行通话管理等通信的控制处理的群集化、与现用系统的系统切换的操作。

使用切换通知部1731是为了从进行现用群集成员的死活监视的程序(未图示)中收取现用群集成员的故障检测的信息、并根据需要将其与应用程序110一起向切换控制部1732传送。

切换控制部1732包括在现用群集成员发生故障、备用成员跳过故障(fail over)时，切换核对部171、写入API部152的动作、备用系统的应用程序110进行发送接收的功能。

现用监视部1733具有根据另外决定的顺序监视现有系统(现用群集成员)死活的功能。但是，此功能可以独自地安装应用程序等，此情况下也可以省略现用监视部1733。

[根据多处理环境中的库(library)实现]

在此，群集成员由多处理用操作系统实现的情况下，通常按以下这种对应来实现。读取API部151、写入API部152典型地作为系统调用的API实现。协议处理部121、122、…、12k以下作为OS的核心等的一部分实现。应用程序作为客户处理(user process)实现。

在这种结构中，夹在读取API呼叫捕捉部161及写入API呼叫捕捉部162、读取API部151及写入API部152之间的部分，能够作为库实现。如此这样，在追加本发明的群集功能的情况下，能够减少到目前为止安装存在的OS的核心部分和应用业务的变更。OS的核心部分和应用程序，通常作为各自独立的文件(file)被管理，原因在于，在执行应用程序时，库多数是能动态地链接的系统。

[多个应用程序工作的情形的结构]

到此为止，为了方便，虽然说明了在群集成员中仅一个应用程序工作的情形，但也可以运行多个应用程序。此情况下，按每一应用程序分别准备前面已说明的结构部分。

由于为了冗余化现用系统和备用系统的传输部174而进行通信，所以在传输部174中预先设定现用系统的哪一个应用程序与备用系统的哪一个应用程序对应。具体地，假设通过设定等预知相互冗余化通信用通话的端口(port)号码等。

[实施例1的动作说明]

接着，详细地说明本实施例的动作。

[读取处理]

首先，为了说明本实施例的特征，参照图3A、3B的流程图，说明不包括读取API呼叫捕捉部161、写入API呼叫捕捉部162等、未群集化的主节点H(参照图34)的接收读取处理。

参照图3A、3B，读取处理由2组一系列处理构成。一个是图3A所示的以包接收为契机的处理(协议处理)。另一个是图3B所示的以应用程序的读取处理为契机的处理(应用业务处理)。

虽然前者和后者使用相同的接收数据，但由于一度处理流程中断，所以如此划分。

一旦从数据链路4给主节点H的IP包到达，接收接口141就接收该IP包(步骤S301)。一面按从低层(layer)的协议处理部121到高层的协议处理部12k的顺序处理接收数据，一面进行提交(步骤S302、S303)。例如在TCP/IP网络中，层是典型的以太网(登记商标)、IP、TCP等的组合。

最上位层的协议处理部12k，在本层的协议处理结束时，就通知可对读取API部151进行读取(步骤S304)。此通知通过事先准备例如由协议处理部12k和读取API部151公用的状态变量，将状态变量的值变更为表示是可读取的值。

当应用程序110对读取API部151请求接收数据的读取时(步骤S305)，读取API部151就通知可以从协议处理部12k读取的情况下(步骤S306YES)，读取接收数据、提交给应用程序110(步骤S307、S308)。相对于此，在没有通知可以读取的情况下(步骤S306NO)，直到通知可被读取为止，停止(block)读取处理(步骤S309)。

接着，说明本实施例的处理。图4A、4B示出本实施例中的接收读取处理中的现用系统侧的动作流程图。

接收读取处理与用于比较而说明的主节点H的情形相同，分为图4A所示的协议处理(步骤S401～S404)和图4B所示的应用业务处理(S405～S416)。其中，协议处理(步骤S401～S404)中，由步骤S401进行的处理与由图3A的步骤S301进行的处理有一些不同，由步骤S402～S404进行的处理与由图3A的步骤S302～S304进行的处理相同。在步骤S401中，与由步骤S301进行的处理的不同之处在于，仅接收用接收侧分配滤波器131计算出的哈希值等于执行哈希值的包。

接着，说明应用业务处理。在本实施例中，读取API呼叫捕捉部161捕捉根据应用程序110的读取API部151的呼叫(步骤S405、S406)。读取API呼叫捕捉部161一旦捕捉到上述呼叫，就替代应用程序110呼叫读取API部151(步骤S407)。由此，如果在协议处理部12k中准备有接收数据的话，读取API部151就读取它，如果没有准备，就直到完成接收数据的准备之前，停止读取处理(步骤S408～S409)。

接着，用复制部171复制读取API部151读取的接收数据并提交给传输部174，传输部174将提交的数据传送给备用群集成员(步骤S411)。利用群集成员间的专用通信机构、公用存储器、或应用程序在通信中使用的读写用API部来进行此复制数据的发送。

并且，为了从备用群集成员把核对数据的结果发送过来，所以进行来自读取API部151的读取处理，等待相应数据的接收(步骤S412)。一旦核对结果发送过来，传输部174就从读取API部151中读取相应数据，将其提交给复制部171(步骤S413)。复制部171在核对结果显示核对成功的情况下(步骤S414，YES)，通过读取API呼叫捕捉部161将由步骤S410读取的数据提交给应用程序110(步骤S415)，在核对结果表示核对失败的情况下(步骤S414，NO)，废弃由步骤S410读取的数据，将错误反馈给应用程序110(步骤S416)。

接着，说明备用系统中的动作。图5A、5B示出本实施例中的接收读取处理内的备用系统侧的动作流程图。

参照同一附图，与现用系统相同，备用系统的读取处理也由2组一系列处理构成。

在本实施例中，由于接收数据向所有群集成员进行多址通信，所以与现用群集相同的包也被传送到备用群集成员。再有，规定备用群集成员的执行哈希值与现用群集成员的执行哈希值相同。

在步骤S501～S504中，进行与图4A所示的步骤S401～S404相同的接收处理。

另一方面，在备用系统中，读取处理不由应用程序驱动，而由群集处理自身驱动。

在备用系统的群集成员内部，核对部171经过传输部174读取来自现用系统的接收数据(复制数据)。传输部174等待来自现用系统的复制数据的到达，一旦复制数据到达，就将其向核对部171提交(步骤S505、S506)。以此为契机，核对部171经过读取API部151读取接收数据(步骤S507～S510)。此时，在能够指定读取的接收数据长度的情况下，读取仅与从现用系统收取的接收数据的复制相同的长度。

此后，核对部171比较由步骤S510读取的接收数据、和自现用系统收取的接收数据的复制数据，在内容一致的情况下，将表示核对成功的核对结果发送给现用系统；在内容不一致的情况下，将表示核对失败的核对结果发送给现用系统(步骤S511)。此后，核对部171废弃接收数据(步骤S512)。再有，在步骤S510自己读取的数据比从现用系统收取的接收数据的复制数据少的情况下，仅直到使数据一致为止，持续读取。但是，即使持续预先指定的时间的读取，数据也能不一致时，也可以停止读取并假设核对失败。在以上的处理结束后，废弃备用系统自己的接收数据。

再有，核对结果的发送与复制数据的发送一样，利用群集成员间的专用通信机构、公用存储器、或应用程序在通信中使用的读写用的API来进行。但是，在利用应用程序在通信中使用的读写用API的情况下，作为后述的写入处理结果，由于在从备用系统输出之前就废弃了IP包，所以就不能与现用系统进行通信。由此，针对给现用系统的包，进行不废弃而实际输出这样的例外处理。

图6示出汇总以上的现用系统和备用系统的动作的指令序列的图。在现用系统和备用系统中进行多址通信的包，通过双方系统的协议处理部，被进行冗余处理。在备用系统中核对现用系统和备用系统的接收数据。仅在接收了相同的数据的情况下，提交给现用系统的应用业务。由此，实现协议的冗余处理。

此外，在现用系统和备用系统中，直到数据的读取结束为止，都不结束应用业务的读取处理。如此这样，就能够防止仅在现用系统或备用系统的单方面系统读取处理前进这种处理的同步差异。

[写入处理]

首先，作为用于说明本实施例的特征的比较例，在图7中示出不包括读取API呼叫捕捉部161、写入API呼叫捕捉部162等并且未群集化的主节点H(参照图34)的写入发送处理。

参照图7，在未群集化的主节点H中，应用程序110呼叫写入API部152，在写入API部152内的缓冲器(buffer)中写入发送数据(步骤S701)。当发送数据被写入内部缓冲器中时，写入API部152就核查是否可以将上述发送数据提交给最上位的协议处理部12k(步骤S702)。然后，在可提交发送数据的情况下(步骤S702，YES)，将发送数据提交给最上位层的协议处理部12k(步骤S704)。在因协议处理部12k内的缓冲器已满等理由而不能将数据提交给协议处理部12k的情况下(步骤S702，NO)，直到变为可提交发送数据为止，停止写入处理(步骤S703)。

一面按从高层的协议处理部12k到低层的协议处理部121的顺序处理从写入API部152输出的发送数据，一面进行提交(步骤S705、S706)。然后，最终从发送接口142向数据链路4输出(步骤S707)。上述说明是主节点H中的写入发送处理。

接着，说明本实施例的写入发送处理。图8A、8B示出本实施例中的写入发送处理内的现用系统侧的动作流程图。

参照同一附图，写入发送处理与比较例的主节点H相同，通过应用程序110呼叫(呼出)写入API部152来进行驱动(步骤S801)。

在本实施例的结构中，利用写入API呼叫捕捉部162捕捉写入API部152的呼叫(步骤S802)，作为写入发送处理进行下一处理。

首先，复制部172复制发送数据，并将复制数据提交给传输部174。传输部174将提交的数据送给备用群集成员(步骤S803)。利用群集成员间的专用通信机构、公用存储器、或应用程序110在通信中使用的读写用的API来发送此复制数据。并且，为了从备用群集成员把数据的写入结果发送过来，所以等待此结果的接收(步骤S804、S805)。利用群集成员间的专用通信机构、公用存储器、或应用程序110在通信中使用的读写用的API(未图示)将写入结果发送过来。

一旦接收写入结果，传输部174就将其提交给复制部172。复制部172在写入结果显示写入失败的情况下(步骤S806，NO)，废弃发送数据，对应用程序110通知此情况(步骤S807)。相对于此，在表示写入成功的情况下(步骤S806，YES)，如果能够在协议处理部12k内的缓冲器中写入数据，就立即将发送数据提交给协议处理部12k，如果在不能写入的情况下，就等待其变为可写入，将发送数据提交给协议处理部12k(步骤S808～S810)。在此之后，在协议处理部121、122、…、12k中，执行与步骤S705、S706相同的处理(步骤S811、S812)，最终，从发送接口142向数据链路4输出发送数据(步骤S813)。

接着，说明备用系统中的动作。图9是表示本实施例中的写入发送处理内的备用系统侧的动作流程图。在备用系统中，与读取处理的情形相同，写入发送处理不是由应用程序驱动，而是由群集处理自己驱动。

传输部174等待来自现用系统的发送数据(复制数据)的到达，一旦发送数据到达，就将其提交给写入部172(步骤S901)。

写入部172呼叫写入API部152提交发送数据。由此，写入API部152核查协议处理部12k内的缓冲器是否可写入，如果可写入，就立即将发送数据提交给协议处理部12k；如果不可写入，就等待其变为可写入，将发送数据提交给协议处理部12k(步骤S902～S904)。

由此，在协议处理部121、122、…、12k中进行发送数据的写入处理(协议处理)(步骤S905)。此后，写入部172根据来自协议处理部121、122、…、12k的应答(来自函数调用的返回、回呼路径(call back routine)的呼叫等)，形成表示发送数据的写入是否成功的写入结果，并向现用群集成员发送(步骤S906)。利用群集成员间的专用的通信机构、公用存储器、或应用程序110在通信中使用的读写用的API部等来发送此写入结果。

再有，在利用上述读写用API向现用系统通知写入结果的情况下，以其地址为现用系统的IP/MAC地址，在发送接口142中，不废弃写入结果。即，备用系统的发送侧分配滤波器132被构成为：通过发送接口142向数据链路4输出给现用系统的包，废弃除此之外的包。此外，在步骤S905中，在从现用系统收取的发送数据的复制数据之内，仅一部分未写入的情况下，直到全部数据写入为止，持续写入处理。但是，即使持续预先指定的时间的写入处理，也不能结束写入处理时，停止该处理并假设结果为失败。

图10是汇总以上的现用系统和备用系统的动作的指令序列图。现用系统应用程序写入的发送数据在写入API部152之下被复制，通过双方系统的协议处理部，被进行冗余处理。仅在正常地发送处理相同的数据的情况下，对现用系统的应用业务通知成功。由此，实现冗余处理。

此外，比现用系统的写入处理更优先地进行备用系统的写入处理的原因在于，如下文中所述的、本实施例的冗余处理的特征和TCP等的协议动作。

在本发明的冗余化方式中，虽然由现用系统进行输出处理的发送数据，实际被输出，但由备用系统进行输出处理的发送数据却在输出之前被废弃。由此，可以防止数据的重复输出。

一方面，在TCP和SCTP等的、保证数据的传送的协议中，针对发送数据，从对方节点发送过来送达确认应答。由于根据此应答的接收，可知发送数据到达，所以该协议能够删除保持在发送缓冲器中的数据。另一方面，如果应答未到达，就需要继续再传送发送数据。

在本实施例的备用系统中进行发送处理时，由于按照备用系统的动作，虽然在协议中处理包，但实际上没有输出包，所以从对方节点没有确认应答的到达。

另一方面，在现用系统中进行发送处理时，由于实际中将发送数据传送到对方节点，所以就可以返回应答。

在此，由于应答信息被发送给群集系统，所以就到达现用系统和备用系统双方。

如果先由现用系统进行发送处理，则在由备用系统进行发送处理之前，存在应答到达备用系统的可能性。为了废弃对未发送的数据的应答，在此情况下，备用系统废弃相应应答。

此后，即使备用系统进行发送处理，实际上也不会输出发送数据，因此，由于相应数据的应答也没有到达，所以就永远不进行送达确认了。基于以上情况，为了增加与现用系统相比首先由备用系统进行发送处理的机会，所以与现用系统相比，优先由备用系统进行写入处理。

[其它处理]

除读取、写入外，在通信API群中，准备有终点(endpoint)产生和通话建立等通信控制用API。

在此，说明作为主要的通信用API之一的巴克利(バ—クレイ，Berkeley)端口(socket)API中的、上述控制用API的冗余化方法。socketAPI当中、示出在终点产生和通话建立所使用的主要的系统调用。

“connect”

“bind”

“listen”

“accept”

其中，特别地，进行通话等待的服务器侧利用bind、listen、accept，主动建立通话的客户侧利用connect。使用这些API的通信程序的产生方法，例如，在“W.リチャ—ドステイ—ヴンス(著)，W.Richard Stevens(原著)，篠田陽一(翻译)、UNIX(登记商标)网络编程<Vol.1>网络API：端口和XTI，ピアソンエデユケ—シヨン，2000.”中进行了详细地说明。

在下文中，关注它们的用途，根据指令序列图说明客户侧和服务器侧的通话建立的顺序。

就除以下说明以外的API而言，基本上当调用现用侧的API时，就复制此调用内容，在备用侧也调用相同的API，仅在现用、备用两方中的API呼叫成功的情况下，在应用业务中通知API呼叫成功。

[服务器侧的通话建立]

在服务器侧，典型地，通话建立顺序如下。

(1)通过bind固定本节点的端点。

(2)发行listen系统调用，表示在相应端点准备好等待接收。

(3)由accept系统调用，等待在与客户端(client)之间确立通话。当确立与客户端的通话时，就按每一通话新生成端口描述符并向呼叫侧返回。以后用由(3)得到的端口描述符进行通信。

在此，应用业务典型地分别发行用于上述三个顺序的系统调用。在本发明的方式中，此呼叫顺序保持原样不变，与读写的情形相同，捕捉各系统调用的呼叫，进行用于冗余化的追加处理。

图11示出服务器侧的通话建立的指令序列的指令序列图。参照同一附图，首先就bind、listen系统调用而言，进行现用系统的应用业务呼叫时，控制部进行捕捉并委托向备用系统的相同处理。在备用系统中也发行同样的系统调用，收取结果。在此，在由备用系统正常地完成了相应处理的情况下，在现用系统也发行相同的系统调用。假如现用系统、备用系统的任何一个系统的系统调用异常结束的情况下，就对来自现用系统中的应用业务的相应调用通知已经失败的情况。通过以上的处理，就能由现用/备用双方的系统接收来自客户端节点的通话建立请求。

接着，就accept系统调用而言，现用系统的应用业务进行呼叫时，控制部进行捕捉并首先由现用系统发行该系统调用。于是，在现用系统中，确立通话之后接着赋予与等待用不同的另一通信用端口描述符，返回呼叫源(此情况为控制部)。

仅限于上述处理成功了的情形，控制部向备用系统委托进行相应处理。在备用系统，也发行该系统调用，同样地收取通信用端口描述符，将结果传达给现用系统。由此，现用、备用系统都能形成与客户端的通信用的端口。最后，向应用程序通知现用侧的通信用端口描述符作为系统调用的结果，结束通话建立的处理。

在此，仅accept由现用系统首先发行系统调用的原因在于，由备用系统记录现用系统的通信端口描述符与自身通信用端口描述符的对应。

此外，协议进行的通话建立，即使在accept的发行前也能进行通话建立。假如accept被调用前确立通话，则在通过listen形成的等待队列(queue)中保持通话信息。此情况下，一旦发行accept就能立即得到通信用端口描述符。此外，如果在发行accept的时刻还未建立通话，则直到建立通话为止，停止accept的呼叫。

通过这种方式，即使是利用多个端口描述符的应用业务，在现用系统和备用系统进行通信时，也能通过提交处理对象的端口API来进行无混乱的冗余处理。而且，即使在备用系统accept的呼叫存在延迟，也能够在现用/备用双方确立通话。

此外，上述顺序是在TCP(参照RFC 793、Transmission Control Protocol.J.Postel.Sept，1981.)和SCTP(参照RFC 2960、Stream Control TransmissionProtocol.R.Stewart，Q.Xie、K.Momeault，C.Sharp、H.Schwarzbauer，T.Taylor，I.Rytina，M.Kalla，L.Zhang，V.Paxson.October 2000.)等的连接取向协议下的通话确立的情形，在UDP(参照RFC 768，User Datagram Protocol.J.Postel.Aug，1980.)等的无连接协议(connectionless protocol)的情况下，在进行上述(1)的顺序后开始读取处理。此情况下，仅bind的处理按上述的顺序冗余化。

[客户端侧的通话建立]

在客户端侧，典型地，通过connect系统调用的发行来进行通话建立。当发行同一系统调用时，固定本节点侧端点，向协议委托在与对方端点之间进行通话确立，就能保持通话建立的结果并返回呼叫。

要冗余化客户端侧的通话建立，就要冗余化connect系统调用的处理。

图12是表示客户端侧的通话建立指令序列的序列图。参照同一附图，首先，当现用系统的应用程序进行connect系统调用的呼叫时，控制部就捕捉此呼叫。

在此，首先进行固定本节点侧的端点的处理。这是因为，在常规connect的调用中，虽然不指定本节点侧的端点，由协议侧选择适当端点的端口号码，但本实施例的冗余结构的情形，为了在现用系统和备用系统中，形成相同的端点，所以需要分配相同的端口号码。

在本节点侧端点的固定中，使用在服务器侧说明过的bind系统调用。由此，先进行于bind系统调用的冗余化处理相同的处理，使现用、备用双方的本节点侧端点的状态相同。

当上述固定成功后，接着针对对方端点确立通话。首先，在备用系统侧以非同步模式发行connect系统调用。在非同步模式中，即使没有结束连接的确立，也一度结束connect系统调用的处理。由此，备用系统的协议变为通话建立中的状态，在协议是TCP的情况下，进行设定了SYN标识(flag)的段(segment)的输出处理等(但是，输出前废弃包)。设为非同步模式是因为在备用系统中由于实际中不输出包，所以不进行通话确立处理，connect系统调用通常不结束。

接着，在现用系统侧发行connect系统调用，实际进行通话确立处理。当在现用系统中进行通话确立处理时，实际上就输出包，并确立通话。此时，由于在备用系统中是等待来自对方端点的应答的状态，所以如果从对方端点有应答的话，就进行备用系统的通话确立处理。根据以上方式，就在现用/备用双方的系统中冗余地确立通话。

[系统切换处理]

说明在现有系统故障的情况下，将处理切换到备用系统的跳过故障处理。

按照另外设定的顺序监视现用系统的死活。作为监视顺序的具体例，考虑例如以下这种方式。再有，下面说明的方式是实现的一个实例，除此之外，只要是能够监视现用系统的运行的方式，则也可以采用。

首先，在现有系统装置内部，设置监视现用系统的各部分的动作是否正常的现用监视部。接着，相应监视部按固定间隔向备用群集成员的现用监视部发送该动作信息。

现用监视部在相应动作信息中表示出检测到异常、或最后接收该动作信息后，即使仅经过规定的时间也没有下一该动作信息到达时等情形下，判断为现用系统发生了故障。

接着，当现用监视部检测到故障时，切换通知部就通知备用系统的应用程序和切换控制部发生了故障。由此，正待机的备用系统的应用程序替代现用系统的应用程序而开始工作。

此外，切换控制部改变写入部和核对部的动作。写入部进行动作，以便将经过写入API呼叫捕捉部应用程序发行的写入API呼叫原样传送给写入API。核对部也针对读入进行相同的处理。根据以上方式，备用系统就会进行与独立(stand alone)的主节点相同的动作。

此外，现用监视部的功能也可以独立地安装应用程序等。此情况下，就可以省略现用监视部，在切换通知部中，进行通知来自应用程序的当前使用故障的动作。

[实施例1的效果]

根据本实施例，就能够不用大幅度地变更OS，冗余化应用程序工作的广播·调度方式的群集成员，提高可靠性。其理由在于，因为采用了在应用程序110和读取、写入API部151、152之间包括读取API呼叫捕捉部161、写入API呼叫捕捉部162，复制部/核对部171、复制部/写入部172、控制部173、传输部174的结构。即，由于上述各部能够设置在OS的外部，所以不用变更OS，就能冗余化应用程序工作的群集成员。

[本发明的实施例2]

本发明的实施例2的特征在于，在包括多个应用程序运行的群集成员的广播·调度方式的群集系统中，能以不同的策略进行对协议处理的负荷分散和对应用业务处理的负荷分散。

在图13A、13B中示出本实施例的概况结构和动作的一个实例。参照图13A、13B，群集系统由4台群集成员构成，分别包括与现有的广播·调度方式的群集成员相同的利用哈希的滤波器。并且，各个群集成员包括应用程序，在协议处理部和应用程序之间包括使用哈希的分配部。

在分配部中，使用协议处理用和应用业务处理用的2个哈希函数，再次计算应该处理发送方向、接收方向的通信量的群集成员，根据需要对其它的群集成员进行发送修正通信量的作业。由此，协议处理部和应用程序就能管理用不同的分散方法所分散的通信量。

就接收侧而言，到协议处理为止，进行与现有的广播·调度方式的群集系统相同的处理。在将接收数据提交给应用程序前，分配部决定应用业务处理的执行群集成员。这通过将应用业务处理用的、不同于协议用的另一哈希函数应用在包中所含的应用业务用数据(通常以有效负荷(payload)的方式含有)中，计算出哈希值，判断相应哈希值被分配的群集成员来执行动作。

在图13A的例子中，由于包接收群集成员和应用业务处理群集成员不同，所以用分配部传送接收数据，并提交给应用程序。由此，应用程序能够对由哪个群集成员执行协议处理无意识地接收包。

关于发送方向，进行处理以便使应用程序发送的数据直达正确的协议执行群集成员。由于分配部决定协议处理执行群集成员，所以使用与在包接收之后使用的接收侧滤波器相同的哈希函数，计算处理群集成员。在图13B的例子中，应用程序写入发送数据，在提交给协议处理部之前，由分配部传送接收数据。由此，在协议处理部中，能够执行对与其它群集成员的应用程序进行通信无意识地的发送处理。

[说明实施例2的结构]

图14示出本发明相关的群集系统的实施例2的方框图。参照同一附图，本实施例的群集系统1a由与多个数据链路41、42、…、4m连接的多台群集成员100a-1～100a-n构成。在各数据链路41、42、…、4m上连接有群集系统1a的所有群集成员100a-1～100a-n和多台节点31-1～3m-z。

在此，在连接到同一数据链路的所有群集成员中分配有同一代表MAC地址。如果邻接节点给此MAC地址发送包的话，则设定到达所有群集成员方式的各群集成员的接收接口。另一方面，为了在群集成员间进行通信等，还分配给各群集成员唯一的MAC地址。如果利用此地址，确定群集系统1a之中的群集成员也能够进行一对一的通信。

在图15中示出了群集成员100a-1的结构实例。本实施例的群集成员100a-1与图1所示的实施例1的群集成员100的不同之处在于，包括替代复制部/核对部171的应用业务处理分配部181，以及包括替代复制部/写入部172的协议处理分配部182。再有，其它群集成员100a-2～100a-n也具有与群集成员100a-1同样的结构。

其中，协议处理分配部182根据协议数据的内容进行判定发送数据的处理对象群集成员的处理。在协议处理分配部182内部，包括按照与接收侧分配滤波器同样的分配规则来计算发送数据的哈希值的单元(未图示)。而且除此之外，还包括向哈希值的各群集成员的分配表(未图示)。即，不仅能够判定单独分配给自己的哈希值，而且也能够判定分配给其它群集成员中任意一个群集成员的哈希值。

应用业务处理分配部181根据应用业务数据(完成根据最上位的协议处理部12k的处理的、提交给应用程序110的数据)的内容，进行判定接收数据的处理对象群集成员的处理。与协议处理分配部182相同，应用业务处理分别配部181在其内部也包括能够根据应用业务用分配规则判定应该用哪个群集成员处理接收数据的装置。

具有这种功能的群集成员100a-1，可由计算机来实现，在由计算机实现的情况下，例如按如下方式进行。准备计算机和记录具有群集成员100a-1功能的程序的磁盘、半导体存储器、以及其它记录介质，在计算机中读取上述程序。计算机根据读取的程序，通过控制自己的动作，就在本计算机上实现协议处理部121、122、…、12k，接收侧分配滤波器131，发送侧分配滤波器132，滤波器控制部133，接收接口141，发送接口142，读取API部151，写入API部152，读取API呼叫捕捉部161，写入API呼叫捕捉部162，控制部173，传输部174、应用业务处理分配部181，和协议处理分配部182。

[说明实施例2的动作]

接着，详细地说明本实施例的动作。

[接收和读取的处理]

首先，参照图16A、16B说明协议的包接收处理和应用程序的接收数据读取处理。将在此后描述读取的群集处理部分。

在本实施例中，由于接收数据向所有群集成员100a-1～100a-n多址通信，所以无论是不是处理对象，群集系统1a的处理对象包都到达所有群集成员100a-1～100a-n。

参照图16A，接收侧分配滤波器131通过接收接口141接收包时，首先按照是否为群集系统1a的代表MAC地址来分配包(步骤S1601、S1602)。在此，有接收可能性的包是以下3种。

·从通信对象直接接收的、地址为群集系统1a的代表MAC地址的包。

·从其它群集成员发送过来的、地址为本群集成员的MAC地址且含接收数据的包。

·从其它群集成员发送过来的、地址为本群集成员的MAC地址且含发送数据的包。

并且，由于不是给群集系统1a的代表MAC地址的包不需要进行群集处理，所以跳过步骤S1603、S1604的分配处理，而转到协议处理(步骤S1605～1607)。

关于给群集系统1a的代表MAC地址的包，在接收侧分配滤波器131中，通过在包首等中使用规定的哈希函数，来计算哈希值(步骤S1603)。

典型地，哈希函数为以下处理：例如，将IP首的发送源和目的地址分别看作4字节(byte)整数值，取它们的和，并计算规定的正数的余数。但是，如果是在群集的各群集成员中可以无缝分配所有通信量的这样的计算方法，哈希函数就可以是任意的。

接着，利用接收侧分配滤波器131，判定通过上述计算出的哈希值是否等于预先分配给此群集成员的整数值(步骤S1604)。此整数值的分配与现有的广播·路由器群集相同。废弃成为与分配哈希值不同的计算结果的包(步骤S1608)，仅使分配哈希值和计算结果一致的包通过接收侧分配滤波器131(步骤S1605)。

一面从低层的协议处理部121到高层的协议处理部12k按顺序处理通过接收侧分配滤波器131的包，一面进行提交(步骤S1605、S1606)。

最上位层的协议处理部12k结束协议处理时，为了经过读取API部151应用程序110收取接收数据，通知可以对读取API部151进行读取(步骤S1607)。

另一方面，如图16B所示，应用程序110为了经过读取API部151读取接收数据而呼叫读取API部151。在本实施例中，通过读取API呼叫捕捉部161捕捉此呼叫(步骤S1609、S1610)，进行读取·改址处理(步骤S1611)。

在此，参照图17A、17B的流程图，详细说明由步骤S1611进行的读取·改址处理。首先，读取API呼叫捕捉部161从读取API部151读取接收数据。但是，如果没有接收数据，则也与从前一样直到能够准备接收数据为止，停止读取处理(步骤S1701、S1702)。

读取接收数据后，就将其提交给应用业务处理分配部181。应用业务处理分配部181根据数据的发送源等判断其是不是从其它的群集成员经改址发送过来的数据(步骤S1703)。

如果不是已被改址的数据，则就是从应用程序110的通信对方直接收取的接收数据。此数据是协议处理结束、原样通过读取API部151提升的值，由于作为对应用程序的分散方法使用不同于协议的其它分配方法，所以应用业务处理分配部181就使用自应用程序110赋予的哈希函数，计算、修改接收数据的哈希值(步骤S1705)。

如果计算结果与分配给本群集成员的哈希值相等，则会成为处理对象应用程序在本群集成员中进行动作，所以就经过读取API呼叫捕捉部161，将包提交给应用程序110(步骤S1706YES、步骤S1707)。

如果计算结果与分配值不同，则会成为处理对象应用程序在其它的群集成员中进行动作。哈希值分配给哪个群集成员被预先赋予，参照此分配，向处理对象群集成员发送、修改相应的接收数据(步骤S1706NO，S1708)。

为此，将接收数据提交给传输部174，传输部174以处理对象应用程序进行动作的群集成员为地址，在UDP数据群集等中打包(capsule)接收数据，并且添加是接收数据意思的信息，进行相应数据的写入处理(步骤S1709～S1714)。并且，最终，将含接收数据的包从发送接口142输出给数据链路(步骤S1715)。通过以上方式，就能够进行从应用程序110的通信对方直接收取接收数据的处理。

在接收数据是从其它群集成员改址过来的情况下，进一步分为其原是接收数据的情形和原是发送数据的情形。能够用在改址时添加有接收数据意思的信息来判断是不是接收数据。

如果是接收数据(步骤S1704，YES)，则其它群集成员计算的对该数据的哈希值的结果、由于会判断为此群集成员执行应用业务处理，所以经过读取API呼叫捕捉部161，将收取的接收数据提交给应用程序100(步骤S1707)。

在是发送数据的情况下(步骤S1704，NO)，执行上述步骤S1709～S1715。再有，如后所述，由于改址的发送数据中，附加改址时是发送数据意思的信息，所以能够根据此信息来判断是不是发送数据。

[写入发送处理]

接着，参照图18A、18B的流程图，说明写入发送处理。当应用程序110呼叫写入API部152，写入API呼叫捕捉部162捕捉此呼叫，将来自应用程序110的发送数据提交给协议处理分配部182(步骤S1801、S1802)。

由此，协议处理分配部182针对从写入API呼叫捕捉部162提交的发送数据适用协议处理用的哈希函数，计算哈希值(步骤S1803)。

而且，如果计算结果与分配给本群集成员的值相等的话，则由于发送数据的协议处理执行群集成员是本群集成员，所以经过写入API部152，将发送数据提交给协议处理部12k(步骤S1804YES、S1806～S1808)。再有，在协议处理部12k为未变为可写入状态的情况下，等待变为可写入状态后提交发送数据。此后，从最上位层的协议处理部12k起顺序执行协议处理，最终，通过发送接口142将包输出给数据链路(步骤S1809～S1812)。

相对于此，如果计算结果与分配值不同(步骤S1804NO)，则发送协议处理的执行群集成员不是此群集成员自己。与接收的情形相同，哈希值分配给哪个群集成员被预先赋予，参照此分配，向处理对象群集成员发送相应的分送数据。

为此，协议处理分配部182将发送数据提交给传输部174，传输部174以处理对象群集成员为地址，在UDP数据群集等中打包(capsule)发送数据，并且添加是发送数据意思的信息，进行相应数据的写入处理(步骤S1805～S1811)。并且，最终，通过发送接口142向数据链路输出包(步骤S1812)。

[其它处理]

与实施例1相同，说明读取、写入外的API的动作。在此，说明用本实施例的方法群集化作为主要的通信用API之一的巴克利端口API中的、上述控制用API的方法。与实施例1相同，根据巴克利端口API的、服务器侧及客户端侧中的典型用法、根据通话建立处理的指令序列图说明顺序。

[服务器侧的通话建立]

在服务器侧的通话建立中，主要使用bind、listen、accept三个系统调用。按顺序说明这些系统调用的群集化处理。

图19是表示服务器侧的通话建立处理中、到bind、listen止的处理流程的指令序列图。参照同一附图，无论bind、listen，当任意群集成员的应用程序最初进行呼叫时，此呼叫就被传达给所有群集成员，发行系统调用(在图19中，群集成员1最初发行bind、listen)。由此，就能在所有群集成员中形成端点，接受来自客户端的通话建立请求。在第2以后进行API呼叫的应用程序中，只通知成功意思的结果。这是因为来自其它的应用程序的指示中已经进行了该处理。

图20是表示服务器侧的通话建立处理中accepte处理的流程的指令序列图。参照同一附图，accept系统调用，当任意群集成员的应用程序最初进行呼叫时，此呼叫就被传达给所有群集成员，发行系统调用。(在图20中，群集成员1最初呼叫accept)由此，无论在哪一个群集成员的协议处理部建立通话，都能形成通信用的端口描述符，成为由相应群集成员的协议处理部能够通信的状态。

由于一旦可以进行通信、实际上接收数据就已到达，所以就向各群集成员的应用程序分配已到达的通信量、并进行读取处理。

但是此时刻，对于群集成员而言，存在应用程序还未呼叫accept的情形。这是因为应用程序在互不相同的机器中工作，存在处理进度不一致的情形。由于未呼叫accept的应用程序还没有进行通话建立的等待，所以即使向此群集成员分配接收数据处理，也不能进行读取处理。

为了避免此情况，在哈希值的向群集成员的分配表中，在应用程序执行accept的时刻，追加该应用程序进行动作的群集成员的项目(entry)。

其它群集成员的应用程序进行第2个以后的accept呼叫时，为了只向此哈希值分配表追加项目，则对其它群集成员通知该呼叫(在图20中，相当于群集成员2和群集成员N呼叫accept的情形)。根据以上方式，如果建立了通话，则从等待的应用程序中选择处理执行群集成员，向相应群集成员传送通信量。

此外，上述顺序是在连接取向协议下的通话确立的情形，在无连接协议的情况下，仅bind的处理按上述顺序冗余化。由于Bind结束后的应用程序变为可直接接收数据，所以在使用无连接协议的应用程序中，在bind结束之后，向哈希值的群集成员分配表追加该应用程序进行动作的群集成员的项目。

[客户端侧的通话建立]

在客户端侧，典型地，通过connect系统调用的发行来进行通话建立。当发行同一系统调用时，固定本节点侧端点，依赖于协议以在与对方端点之间进行通话确立，从而保持通话建立的结果、并返回呼叫。

图21是表示客户端侧的通话建立指令序列的序列图。参照同一附图，首先，当进行通话建立的应用程序进行connect系统调用的呼叫时，控制部就捕捉此呼叫。

在此，首先进行固定本节点侧端点的处理。这是因为，在常规connect呼叫中，虽然不指定本节点侧的端点，由协议侧选择适当端点的端口号码，但本实施例的情形下，如果不固定端点，就会存在执行计算协议处理的执行群集成员时所需的哈希函数的自变量不一致的可能性。

典型地，协议处理分配用的哈希函数利用协议首(protocol head)等中含有的地址和端口号码。虽然作为connect呼叫的自变量从应用程序赋予对方端点，但由于如果不固定端点，就不能获得上述信息，所以首先由控制部决定本节点侧端点。

接着，决定协议处理执行群集成员，向相应群集成员传达通话建立请求。在图21的例子中，群集成员1的应用程序呼叫connect，在群集成员2中决定协议处理的执行。在协议处理执行群集成员中，首先通过bind系统调用固定本节点侧端点，接着发行connect系统调用，实际中进行通话建立。把上述处理结果通知给connect呼叫源的群集成员，结束通话建立的处理。

[实施例2的效果]

根据本实施例，在应用程序进行动作的广播·调度方式的群集系统中，进行负荷分散时，就能在不同的群集成员中进行对相同通信量的应用业务处理和协议处理。其理由在于，采用在应用程序110和读取、写入API部151、152之间包括读取API呼叫捕捉部161、写入API呼叫捕捉部162、控制部173、传输部174、应用业务处理分配部181、协议处理分配部182的结构。

[本发明的实施例3]

本实施例的特征在于，组合实施例1和2，通过根据通信量使处理负荷分散给多个群集成员来提高系统整体的性能，并且通过冗余地处理通信量还提高了可靠性。

在图22、23中示出了本实施例的概况结构和动作的一个实例。图22是接收动作、图23是发送动作的例子。

参照图22，与实施例2的情形相同，群集成员包括包滤波器和分配·冗余处理部。但是，分配·冗余处理部只使用哈希值，不仅决定应用业务处理的执行群集成员，还进行冗余处理。

当分配决定协议处理执行的哈希值时，在本实施例中每个群集成员为2个。一方是现用处理用的哈希值，另一方是备用处理用的哈希值。关于某一哈希值，现用处理执行和备用处理执行的群集成员各存在一台群集成员。

广播的通信量由所有群集成员接收后，根据由首等计算的哈希值，由现用和备用2台群集成员进行处理。冗余地执行协议处理后，在向应用程序提交接收数据之前进行数据的核对处理。此后，应用程序根据定义的哈希函数来决定应用业务处理群集成员，如果必要，则向执行群集成员改址接收数据。由此，应用程序就能够不会注意到协议处理由哪个群集成员进行、且是否进行冗余化协议处理，都能够接收数据。

图23的结构与图22的情形相同，仅通信量的方向不同。应用程序通过API写入发送数据时，首先为了在分配处理中决定协议处理执行的群集成员而计算哈希值。在此，由于具有一个哈希值的群集成员有2台群集成员(现用执行和备用执行)，所以包被复制并按照请求对各个群集成员改址。通过以上方式，应用程序就不会注意到发送数据由哪个群集成员执行协议处理、且是否进行冗余化协议处理，都能够发送数据。

[说明实施例3的结构]

在图14所示的群集系统中，通过替代具有图15所示结构的群集成员100a-1～100-n，使用具有图24所示结构的群集成员100b来实现本实施例。

本实施例中使用的群集成员100b和图15中示出的群集成员100a-1的不同点在于，替代应用业务处理分配部181，包括应用业务处理分配及复制核对部191；以及替代协议处理分配部182，而包括协议处理分配及复制写入部192。

应用业务处理分配及复制核对部191进行相当于实施例1中的接收侧冗余处理、和实施例2中的接收侧分配处理的处理。

此外，协议处理分配及复制写入部192进行相当于实施例1中的发送侧冗余处理、和实施例2中的发送侧分配处理的处理。

应用业务处理的备用处理具有如下所述的分配方法。

(1)所有群集成员作为应用业务处理的现用来工作，所有群集成员执行任意的其它群集成员的备用。任意群集成员产生故障的情况下，备用执行群集成员接管故障群集成员的应用业务处理。

(2)准备与现用群集成员不同的备用执行群集成员。此群集成员作为所有应用业务处理的备用群集成员进行工作。通常，除备用处理所需的状态的等待等之外，不进行处理。

由于上述结构部分以外的功能与第1及实施例2相同，所以省略其说明。

再有，群集成员100b是可用计算机来实现，在由计算机实现的情况下，例如，按如下方式进行。准备记录其具有使计算机作为群集成员100b功能的程序的磁盘、半导体存储器、其它记录介质。在计算机上读取上述程序。计算机通过根据读取的程序来控制自己的动作，就在本计算机上实现协议处理部121、122、…、12k，接收侧分配滤波器131，发送侧分配滤波器132，滤波器控制部133，接收接口141，发送接口142，读取API部151，写入API部152，读取API呼叫捕捉部161，写入API呼叫捕捉部162，应用业务处理分配复制核对部191，协议处理分配复制写入部192，控制部173，和传输部174。

[说明实施例3的动作]

接着，详细地说明本实施例的动作。

[接收和读取的处理]

图25A、25B是表示本实施例中的、协议的包接收处理，和应用程序的接收数据读取处理的动作流程图。在后面说明读取的群集处理部分。

首先，说明图25A的步骤S2501～S2509。在图25A的步骤S2501～S2504中，进行与实施例2中的图16A的步骤S1601～S1604相同的处理。在步骤S2506～S2509中，进行与图16A的步骤S1605～S1608相同的处理。与图16A的不同点在于在给群集系统的代表MAC地址的包中、且由接收侧分配部滤波器131求出的哈希值与本群集成员的运行哈希值相等的情况下(步骤S2502、S2504同时YES)，接收的包进行步骤S2505的处理。在步骤S2505中，为了将一个哈希值分配给现用处理得当群集成员和备用处理执行群集成员，而基于哈希值分配表来判断接收包对应于哪一方，并将此信息添加到包中进行处理。

另一方面，如图25B所示，应用程序110为了经过读取API部151读取接收数据而呼叫读取API部151。在本实施例中，由读取API呼叫捕捉部161捕捉此呼叫(步骤S2510、S2511)，进行读取·改址处理(步骤S2512)。

图26A-26D是表示读取时的群集追加处理的动作的流程图。首先，与现有的读取处理相同，进行从读取API部151读取接收数据的处理。但是，如果无接收数据，也与原来一样，直到能够准备接收数据为止，停止读取处理(步骤S2601、S2602)。

读取接收数据后，首先，判断其是与哪一处理对应的数据(步骤S2603)。在本实施例中，接收数据有以下7种数据。

1.直接来自通信对方的接收数据

1.1 现用处理对象的接收数据

1.2 备用处理对象的接收数据

2.核对处理的数据

2.1 现用执行群集成员向备用执行群集成员发送的核对用数据

2.2 备用执行群集成员向现用执行群集成员发送的核对结果

3.改址的数据

3.1 协议处理执行群集成员向应用业务处理执行群集成员发送的接收数据

3.2 应用业务处理执行群集成员向协议处理执行群集成员发送的发送数据

3.3 协议处理执行群集成员向应用业务处理执行群集成员发送的写入通知

包在UDP等中被打包，如果附加表示核对用数据或改址数据的标识，就能够判断是哪种数据。如果是除此以外的数据的话，则是直接从通信对方接收的数据，如果是备用处理对象数据的话，则添加表示该备用处理对象数据的信息。根据以上方式，就能够判断上述7类数据。

在下文中，说明各种情形的处理。

从通信对方直接接收的数据中，如果是现用处理对象，则进行核对备用处理执行群集成员和接收数据的处理。具体地，首先复制接收数据(步骤S2608)，以复制数据为核对用数据，经过传输部174向备用处理执行群集成员传送(步骤S2609)。在此，直到收取核对结果为止，现用执行群集成员都保持接收数据。

从通信对方直接接收的数据中，如果是备用处理对象，则核对现用群集成员发送过来的核对数据和接收数据。具体地，首先收取接收数据的情况下(步骤S2613，NO)，仍旧保持该接收数据不变，在核对用数据到达之前执行等待(步骤S1624)。由于接收数据和核对用数据能够按照传送相应数据的连接的端点的信息(发送源及目的的地址和端口号码等)来对应，所以也同时保持此信息。如果数据一致了，就核对内容(步骤S2615)，使用传输部174向现用系统反馈核对结果(步骤S2616)。

核对处理用的数据中，收取核对用数据的情况下，应该接收对应其的备用处理对象数据。如果已经接收了的话(步骤S2613，YES)，则进行步骤S2615、S2616的处理，如果还未接收的话，则一直等到被接收后，进行相同处理。

核对处理用的数据中，收取核对结果的情况下，确认其是否成功核对。在核对失败的情况下，废弃接收数据，结束处理(未图示。在步骤S2604前进行)。在核对成功的情况下，为了决定需要处理保存的接收数据的应用程序进行动作的群集成员，使用自应用程序赋予的哈希函数，计算并修正接收数据的哈希值(步骤S2604)。

如果计算结果等于分配给此群集成员的值(步骤S2605YES)，则变成处理对象应用程序在此群集成员中的动作，因此经过读取API呼叫捕捉部161将包提交给应用程序110(步骤S2606)。

如果计算结果与分配值不同(步骤S2605 NO)，则变成处理对象应用程序在其它的群集成员中的动作。预先确定哈希值分配给哪个群集成员，参照此分配，向处理对象群集成员发送、修改相应的接收数据(步骤S2607)。由此，将接收数据提交给传输部174，传输部174以处理对象应用业务进行动作的群集成员为地址，在UDP数据群集等中打包接收数据，并且添加是接收数据意思的信息，进行相应数据的写入处理。

如果从其它群集成员改址的数据是接收数据，则其它群集成员计算对该数据的哈希值的结果、由于判断为此群集成员执行应用业务处理，所以经过读取API呼叫捕捉部161，将收取的接收数据提交给应用程序(步骤S2606)。

在写入处理的项目，说明发送数据及写入通知的情形的处理。

[写入和发送处理]

图27A、27B是表示本实施例中的写入处理的动作的流程图。参照同一附图，写入处理通过应用程序110调用写入API部152来进行驱动(步骤S2701)。

在本发明的结构中，由写入API呼叫捕捉部162捕捉写入API部152的呼叫，作为写入处理进行以下的处理(步骤S2702)。

首先，在从应用程序110写入的发送数据中应用协议处理用的哈希函数计算修改接收数据的哈希值。使用相应哈希值检索哈希值分配表，决定相应哈希值的执行群集成员(步骤S2703)。

在协议处理中，由于每一个哈希值分配现用、备用2台群集成员，所以为向它们提交包，首先复制包(步骤S2704)。

接着，为了冗余地执行协议处理，由现用/备用各自的执行群集成员进行发送处理。与实施例1相同，首先备用处理群集成员进行发送处理。如果本群集成员自己是备用处理执行群集成员的话(步骤S2705 YES)，则经过写入API部152直接写入发送数据(步骤S2706)。写入/发送处理的详情根据图28后述。如果写入成功的话，则向现用执行群集成员(必须在本群集成员外分配)发送复制的发送数据(步骤S2707、S2708)。

如果本群集成员不是备用群集成员的话(步骤S2705 YES)，则由于首先对备用执行群集成员执行发送处理，所以向同一群集成员改址复制数据(步骤S2709)。

一旦复制数据改址到其它群集成员，则收取该复制数据的群集成员作为改址数据接收处理的延伸进行发送处理(图26A-D的、接收了改址的发送数据的情形)。此情况下，由于已经决定相应群集处理协议处理发送数据，所以只经过写入API部152写入发送数据(步骤S2610)。如果完成写入，就将此结果作为写入通知，向改址源(应用程序呼叫写入API部152的群集成员)反馈(步骤S2611)。

接着，说明写入通知接收契机的处理。首先，看写入通知的结果，如果写入通知失败的话(图27B，步骤S2710，NO)，则作为此数据的写入失败向应用程序的写入处理反馈错误(步骤S2715)。

接着，在写入成功的情况下(步骤S2710，YES)，判断现用处理的必要性(步骤S2711)。在改址源不是备用处理执行的情况下，虽然备用处理后还需要现用侧的发送处理，但判断此发送处理是否已经进行，如果还未进行(步骤S2711，YES)则执行发送处理。如果已经达到这里(步骤S2711，NO)，则废弃发送数据，向应用程序110通知错误(步骤S2716)。

如果本群集成员是现用执行的话(步骤S1712YES)，则呼叫写入API直接进行写入(步骤S2714)。在此，如果写入成功，则正常结束应用程序110呼叫写入API部152的处理。

如果其它群集成员是现用执行的话(步骤S2712NO)，则向相应群集成员改址发送数据(步骤S2713)。并且，如果收取此写入通知，就确认是否成功，将结果通知给应用程序110，结束写入处理。

按图28的顺序进行协议发送处理。在步骤S2801～步骤S2805中，进行与实施例1中说明的写入处理(例如图7的步骤S702～S706)相同的处理。在步骤S2806种，判断是不是备用处理对象的包。而且，在是备用处理对象的包的情况下(步骤S2806，YES)，废弃包，在不是备用处理对象的包的情况下(步骤S2806，NO)，通过发送接口142输出包。

在此，按如下方式就能够实现步骤S2806～S2008的处理。在发送数据中，在图27A的步骤S2704，在复制的包上附加表示是备用处理用的附加信息，在发送侧分配滤波器132中，仅在是备用处理用的情况下，废弃包。

或者，也可以按如下方式。利用发送侧分配滤波器132，分别事先保持本群集成员执行现用协议处理的哈希值和执行备用处理的哈希值。针对从协议处理部121提交给发送侧分配滤波器132的包，首先检查发送源地址是不是代表地址。由于群集的代表地址不是发送源的包，不是群集成员间的通信等、冗余处理对象的包，所以保持原样不变进行输出。对于群集的代表地址是发送源地址的包，与接收侧分配滤波器131中处理(步骤S2503～S2505)相同，基于包首等计算哈希值，给包附加上现用、备用处理用的标识。如果附加有备用处理用的标识的话，就废弃相应包。

[其它处理]

其它处理大致分为通话管理和死活监视。由于通话建立基本上仅是实施例2的情形的指令序列中accept及connect的执行群集成员成为现用/备用2台，所以省略其详细说明。

就死活监视而言，按如下方式处理。各群集成员公用协议处理用和应用业务处理用的哈希值分配表。在同一分配表中，按每一哈希值分配执行群集成员。通过运行确认通信管理各群集成员的死活状况，在同一分配表中反映运行状况，由此就在群集处理中反映死活状况。

首先，说明运行确认顺序的一个实例。各群集成员按规定的间隔(设为t1)在数据链路上广播运行确认通知信息。各群集成员以发送源的群集成员为关键字(key)管理来自其它的群集成员的运行通知，对于规定的时间(设为t2。但是t2>t1)，未能接收到新的运行通知的群集成员判断为故障。

接着，说明哈希值分配表的更新方法。在哈希值分配表中，以哈希值为关键字，按每一哈希值分配运行群集成员。在判断为某个群集成员故障的情况下，从分配表中删除相应群集成员。

按照上述的顺序，分配表可以为以下方式。在协议处理用哈希值分配表中，由于分配有现用、备用2台群集成员，所以如果故障群集成员仅为1台，则不会产生执行群集成员的缺失。另一方面，在应用业务处理用的分配表中通常仅登记现用群集成员。在出现故障群集成员的情况下，在相应的哈希值的项目中登记预先分配的备用群集成员。

[实施例3的变化例]

本实施例的读取处理也可以按以下这种顺序执行。在本实施例的说明中，在协议的备用处理执行群集成员接收数据的情况下，结束核对时就会废弃接收数据。但是，如果相应群集成员是应用业务处理执行的话，则在此就不废弃数据，直接向应用程序提交效率更好。因此，备用处理执行群集成员在核对成功时不废弃数据，即使自己也根据从应用程序赋予的哈希函数计算哈希值，如果应用业务处理执行是本群集成员的话，则也可以照原样不变，将数据提交给应用程序。此情况下，在现用群集成员中，计算哈希值，应用业务处理执行群集成员如果等于协议处理执行的备用群集成员，则不改址而废弃接收数据，结束处理。

此外，也可以按如下方式。虽然上述顺序在所谓不传送无意义的数据的意义上效率好，但在对核对成功的所有数据计算2次哈希值这点上存在浪费。为此，现用群集成员计算哈希值，在应用业务处理执行群集成员等于协议处理的备用群集成员的情况下，可以将其通知给备用群集成员。协议处理的备用执行群集成员，不计算哈希值只保持核对成功的接收数据，根据来自现用群集成员的上述通知，本群集成员如果是应用业务处理执行的话，则将数据提交给应用程序，如果处理群集成员不同的话，则废弃数据。由此，没有接收数据的无用的传送，仅1次就完成哈希值的计算。

[实施例3的效果]

根据本实施例，通过根据通信量使处理负荷分散在多个群集成员中，来提高系统整体的性能，并且，通过冗余地处理通信量，就能够提高可靠性。其理由在于，采用了在应用程序110和读取API部151、写入API部152之间包括读取API呼叫捕捉部161、写入API呼叫捕捉部162、控制部173、传输部174、应用业务处理分配及复制核对部191、协议处理分配及复制写入部192的结构。

[本发明的实施例4]

接着，详细地说明本发明的实施例4。本实施例4特征在于，即使在现用系统及备用系统的群集成员内的一个群集成员中，在发送处理发生显著延迟的情形、和/或现用系统及备用系统的群集成员内的一个群集成员不能接收从对方装置传送过来的包的情形下，在两系统的群集成员中也能进行相同的协议处理。

根据前述的实施例1，使用现用系统及备用系统2台群集成员冗余化协议处理，就能够提高其可靠性。此时，在现用系统和备用系统的群集成员中，必须进行相同的协议处理。但是，现实中，由于以下这种现象，存在继续不执行相同的协议处理的状态、并失去协议状态的冗余性的情形。

即，在冗余化进行送达确认的协议处理(TCP等)的情况下，在以下各情形下就不能在一个系统中继续协议处理

(1)包仅到达现用系统/备用系统的一个系统，同一包没有达到另一个系统的情形。或在一个系统中由于任意的不适合而漏掉上述包的情形。

(2)在现用系统/备用系统的一个系统的发送处理中产生显著延迟，包发送前执行送达确认包的接收的情形。

其中，关于(1)情形存在2种情形：

(1-a)包仅到达现用系统。

(1-b)包仅到达备用系统。

在(1-a)包仅到达现用系统的情况下，现用系统的协议处理部收取包，输出确认应答包。虽然备用系统产生漏掉相应接收包意思的确认应答包，但没有输出到系统外。由此，在对方装置中仅有来自现用系统的确认应答包到达，对方装置会输出后续的包。当继续此动作时，由于备用系统不能接收漏掉的包，所以就永远不能恢复成与现用系统相同的状态。

在(1-b)包仅到达备用系统的情况下，备用系统的协议处理部收取包，产生确认应答包。但是，此应答包不输出到系统外。由于先用系统输出漏掉上述接收包意思的确认应答，所以对方装置判断为发送包消失，再次发送相应包。再送包即使达到备用系统也只能废弃，仅在现用系统收取。由此，在(1-b)的情况下就没有包的消失的问题。

接着，关于(2)情形存在2种情形：

(2-a)在现用系统中发送处理延迟。

(2-b)在备用系统中发送处理延迟。

在(2-a)在现用系统中发送处理延迟的情况下没有产生不适合。这是因为，即使假设备用系统先进行输出处理，实际中包也不输出到系统外，因此相对于现用系统的未发送包，来自对方装置的确认应答包就没有达到。

在(2-b)在备用系统发送处理延迟的情况下，就成为在备用系统开始发送处理之前，现用系统进行发送处理。并且，当从现用系统输出的包到达对方装置时，就从对方装置直接输出确认应答包。实际中，确认应答包从对发放装置送到时，不仅到达现用系统还到达备用系统。在备用系统中，虽然有关未发送包的确认应答包到达，但通常却废弃这种确认应答包。以后，由于即使备用系统执行包的发送处理，也不输出到系统外，所以得不到收取来自对方的确认应答包的机会，备用系统必须继续再次发送上述包，不久再次发送计时器超时(time out)，从而切断连接。

在本实施例中，说明具有能够解决上述备用系统的包漏掉及发送时刻偏移引起的不适合的附加功能的冗余化功能。

[说明实施例4的结构]

在图31所示的广播·调度方式的群集系统中，替代群集成员13-1～13-n，通过使用图35所示结构的群集成员100c来实现本实施例。本实施例的群集系统，例如具有服务器(服务器群集)的功能。

图35所示的本实施例的群集成员100c和图1中示出的实施例1的群集成员100的不同点在于，替代接收侧分配滤波器131及发送侧分配滤波器132包括接收侧分配滤波器131c及发送侧滤波器132c。在此，在使群集成员100c作为现用系统而工作的情况下和作为备用系统而工作的情况下，规定接收侧分配滤波器131c及发送侧滤波器132c结构不同。再有，本实施例的群集成员100c也与实施例1的群集成员相同，能用计算机来实现。

[备用系统的滤波器的结构]

在使群集成员100c作为备用系统而工作的情况下，接收侧分配滤波器131c及发送侧分配滤波器132c，分别为与图36所示的接收侧分配滤波器1031及发送侧分配滤波器1032相同的结构。

参照图36，接收侧分配滤波器1031包括分配部10311、接收通知发送部10312、和滤波器处理部10313。

分配部10311具有如下功能，在通过接收接口141接收的包是给群集系统的代表地址的包的情况下(是多址通信的包的情形)，将其分配给接收通知部10312，在不是这种情况下，将其分配给协议处理部121。

接收通知发送部10312具有在每当从分配部10311提交包时产生用于识别此包的标识符、并且将含已产生的标识符的接收通知包发送给现用系统的群集成员的功能。

滤波器处理部10313进行滤波处理。

发送侧分配滤波器1032包括分配处理部10321、发送通知发送部10322和滤波器处理部10323。

分配部10321具有在从协议处理部121提交的包为冗余化对象的包的情况下将其分配给发送通知发送部10322、将除此之外的包分配给发送接口142的功能。

发送通知发送部10322具有在每当从分配部10321提交包时获取此包中所含的发送数据的序列号码并将含序列号码的发送通知包发送给现用系统的群集成员的功能。

滤波器处理部10323进行滤波处理。

[现有系统的滤波器的结构]

在使群集成员100c作为现用系统而工作的情况下，发送侧分配滤波器132c结构为与实施例1中使用的发送侧分配滤波器132相同结构，接收侧分配滤波器131c结构为图37所示的接收侧分配滤波器1021相同结构。

参照图37，在现用系统的群集成员中使用的接收侧分配滤波器1021包括分配部10211、接收包控制部10212、接收包缓冲器10213、备用系统接收履历存储部10214、接收通知接收部10215、确认应答缓冲器10216、备用系统发送履历存储部10217、和发送通知接收部10218。

分配部10211具有将通过接收接口141接收的来自对方装置的包、来自备用系统的接收通知包及发送通知包分配给接收包控制部10212、接收通知接收部10215及发送通知接收部10218的功能。

接收通知接收部10215具有在备用系统接收履历存储部10214中保存从备用系统发送过来的接收通知包中所含的标识符的功能。

发送通知接收部10218具有在备用系统发送履历存储部10217中保存从备用系统发送过来的发送通知包中所含的序列号码的功能。

接收包控制部10212具有以下功能：将含数据的常规包保存在接收包缓冲器10213中的功能，将含确认应答数据的确认应答包保存在确认应答缓冲器10216中的功能，将接收的包提交给协议处理部121的功能，将保存在接收包缓冲器10213中的包发送给备用系统的群集成员的功能，和将保存在确认应答缓冲器10216中的确认应答包发送给备用系统的群集成员的功能等。

[说明实施例4的动作]

接着，分为现用系统和备用系统来说明本实施例的动作。再有，由于冗余化本体的动作与实施例1相同，所以省略关于冗余化处理的说明。

[备用系统的动作]

首先，说明备用系统的动作。图38示出备用系统中的动作的流程图。

首先，说明备用系统的包接收时的动作。通过接收接口141接收来自对方装置的包时，分配部10311，根据包的地址MAC地址判断此包是否给代表地址(是不是对现用系统、备用系统双方多址通信的包)(步骤S1048、S1049)。

而且，在判断为不是给代表地址的情况下(步骤S1049 NO)，分配部10311将接收包提交给协议处理部121。由此，进行协议接收处理。

相对于此，在判断为是给代表地址的情况下(步骤S1049 YES)，将接收包提交给接收通知发送部10312。

由此，接收通知发送部10312产生用于识别接收包的标识符(步骤S104A)。标识符是可将相应包与其它包区别开来的信息，在此，使用包的校验和(checksum)。但是，即使不是校验和，如果是能够识别包的信息的话也可以使用其它值作为标识符。例如，也可以对包使用哈希函数计算出哈希值，以此为标识符。

此后，接收通知发送部10312形成含上述标识符的接收通知包，发送到现用系统的群集成员的地址(步骤S104B)。由于此处理含通常协议发送处理，在同一附图中，在协议发送处理(步骤S1042)后继续。上述处理之后，接收包通过滤波器处理部10313进行滤波器处理后(步骤S104C)，提交给协议处理部121，进行接收处理(步骤S104D)。

接着，说明备用系统中的发送处理。发送侧分配滤波器1032内的分配部10321，当从协议处理部121提交发送包时，就判定此包是不是冗余化对象包(步骤1042、S1043)。例如，根据包的首部的内容和/或发送源地址来进行此判定。再有，从协议处理部121向分配部10321中提交写入API部152的写入API呼叫(步骤S1041)所产生的包、接收通知包或发送通知包。

然后，在不是冗余化对象的发送包的情况下(步骤S1043，NO)，分配部10321通过发送接口142发送发送包(步骤S1047)。

相对于此，在是冗余化对象的发送包的情况下(步骤S1043，YES)，分配部10321将发送包提交给发送通知发送部10322。

由此，发送通知发送部10322首先从发送包的首部取得序列号码(发送序列号码)(步骤S1044)。接着，形成含上述序列号码的发送通知包，发送给现用系统的群集成员地址(步骤S1045)。此处理也与接收通知包的情形相同，在协议发送处理(步骤S1042)后继续。

上述处理后，在滤波器处理部10323中，进行由发送侧分配滤波器1032定义的滤波处理(步骤S1046)。在备用系统的上述滤波器处理中，至少进行废弃冗余化对象的发送包的处理。

由此，每次执行冗余化对象的发送/接收包的发送/接收处理，都向现用系统的群集成员发送此通知。

[现用系统的动作]

接着，说明现用系统的动作。在图39A、39B、39C中示出现用系统中的动作的流程。

通过图37示出的接收侧分配滤波器1021内的分配部10211，当通过接收接收141接收包时，就根据目的MAC地址判断是不是代表地址(步骤S1051)。

然后，如果是给代表地址的包(步骤S1051，YES)，则分配部10211将接收包提交给接收部控制部10212。由此，接收包控制部10212按照请求进行由接收侧分配滤波器1021定义的滤波处理(步骤S1052)。

此后，接收包控制部10212判断接收包是不是含确认应答数据的来自对方装置的确认应答包(步骤S1053)。

然后，如果是来自对方装置的确认应答包(步骤S1053，YES)，则从此首部取出确认应答号码(正常接收的包的序列号码)，以此确认应答号码为关键字检索备用系统发送履历存储部10217，由此核查备用系统是否完成相当于上述确认应答包的包的发送(步骤S1054)。即，在备用系统发送履历存储部10217中保存有与确认应答号码相同的序列号码的情况下，判断为已完成发送，如果未保存，则判定为未发送。

然后，在判定为备用系统是对未发送的包的确认应答包的情况下(步骤S1055，YES)，将上述确认应答包保存在确认应答缓冲器10216中，保留这以后的接收处理(步骤S1056)。

相对于此，在判定为备用系统是对已完成发送的包的确认应答包的情况下(步骤S1055，NO)，将确认应答包提交给协议处理部121(步骤S105A)。

此外，在上述步骤S1053中，在判断为由分配部10211提交的包是含来自对方装置的数据的常规包的情况下(判断结果NO)，接收包控制部10212通过检索备用系统接收履历存储部10214，来判定备用系统是否已经接收相同的包(步骤S1057)。即，在备用系统发送履历存储部10214中保存有与接收包的标识符相同的标识符的情况下，判定为备用系统已经接收相同的包，在未保存的情况下判定为未接收。

然后，在判定为备用系统已完成接收的情况下(步骤S1058，YES)，接收包控制部10212，将接收的包提交给协议处理部121，并且从备用系统接收履历存储部10214中删除上述包的标识符(步骤S105A)。

相对于此，在判定为备用系统未接收的情况下(步骤S1058，NO)，由于存在必须向备用系统发送上述包的情形，所以将其复制保存在接收包缓冲器10213中，并且将上述包提交给协议处理部121(步骤S1059、S105A)。

以上说明是成为冗余化对象的包(给代表地址的包)的接收处理。

接着，说明接收包不是给代表地址的情形。

分配部10211在通过接收接口141接收的包不是给代表地址的包的情况下(步骤S1051NO)，核查上述包是不是来自备用系统的发送通知包(步骤S105C)。

然后，在是发送通知包的情况下(步骤S105C YES)，将上述包提交给发送通知接收部10218。由此，发送通知接收部10218从上述发送通知包中取出序列号码，保存在备用系统发送履历存储部10217中(步骤S105D)。通常，由于序列号码是连续的，所以可以在备用系统发送履历存储部10217中仅保持最后发送的包的序列号码。

一旦在备用系统发送履历存储部10217中保存序列号码，接收包控制部10212就从确认应答缓冲器10216中检索带有与上述新保存的系列号码相同序列号码的确认应答包(步骤S105E)。即，由于备用系统是未发送上述序列号码的包，所以在步骤S1056中检索保存(保留)在确认应答缓冲器10216中的确认应答包。

然后，在不能检索这种确认应答包的情况下，接收包控制部10212就结束此处理。相对于此，在能够检索相应的确认应答包的情况下，将检索出的确认应答包提交给协议处理部121并进行现用相同的接收处理，同时通过协议处理部121、122、…、12k，读取API部151、复制部/核对部171，传输部174向备用群集成员发送上述确认应答包(步骤S105F、S105A、S105B)。在此，向备用系统的群集成员发送确认应答包的原因在于，假设备用系统接收此确认应答包，由于是对未发送包的确认应答包，所以进行废弃的可能性就高。

如此这样，对备用系未发送的包的确认应答包，在现用系统中必定滞留在确认应答缓冲器10216中，一直未提升到协议处理部121。并且，如果从备用系统发送通知包到达的话，滞留在确认应答缓冲器10216中的确认应答包则向协议处理部121传送。通过以上处理，在备用系统中，就能够解决因对未发送包的确认应答包的发送失败而产生的问题(2-b)。

如上所述处理是接收来自备用系统的发送通知包时的动作。

接着，说明接收来自备用系统的接收通知包时的动作。

分配部10211在判断为通过接收接口141接收的包是来自备用系统的接收通知包的情况下(步骤S105G YES)，将其提交给接收通知接收部10215及接收包控制部10212。

由此，接收包控制部10212参照备用系统接收履历存储部10214及接收包缓冲器10213(步骤S105H、S105I)，核查此状态是否成为下述的(x-1)、(x-2)、(y-1)、(y-2)、(z)的任何一个状态。

(x-1)在备用系统接收履历存储部10214中保存有接收通知包中所含的标识符，并且在接收包缓冲器10213中保存有对应上述标识符的包的状态。

(x-2)在备用系统接收履历存储部10214中保存有接收通知包中所含的标识符，并且在接收包缓冲器10213中未保存有对应上述标识符的包的状态。

(y-1)在备用系统接收履历存储部10214中未保存有接收通知包中所含的标识符，并且在接收包缓冲器10213中保存有对应上述标识符的包(设为包P1)、和相比于包P1接收顺序在前的包，在接收顺序在前的包之中存在在备用系统接收履历存储部10214中未保存着相应的标识符的包(设为包P2)的状态。

(y-2)在备用系统接收履历存储部10214中未保存有接收通知包中所含的标识符，并且在接收包缓冲器10213中保存有对应上述标识符的包P1、和相比于包P1接收顺序在前的包，接收顺序在前的包在所有备用系统接收履历存储部10214中保存着相应的标识符的状态。

(z)在备用系统接收履历存储部10214中未保存有接收通知包中所含的标识符，并且在接收包缓冲器10213中未保存有对应上述标识符的包(设为P3)的状态。

此后，接收包控制部10212根据当前的备用系统接收履历存储部10214及接收包缓冲器10213的状态，进行步骤S105J～105L的处理。

在是(x-1)状态的情况下，由于备用系统接收包，所以判断为不需要再发送(步骤S105J，NO)。此外，在此状态下，由于现用系统也接收同一包，所以从接收包缓冲器10213及备用接收履历存储部10214中删除相应包的项目(步骤S105L)。

在是(x-2)状态的情况下，由于备用系统接收包，所以判断为不需要再发送(步骤S105J，NO)。此外，在此状态下，由于存在现用系统还未收取相应包、或漏掉包的可能性，所以保持备用系统接收履历存储部10214的内容不变。但是，如果即使经过一定时间相应包也未到达，则为了防止存储器泄漏(memory leak)，而要删除相应标识符，给相应标识符加标识。

在(y-1)状态的情况下，虽然包P2由现有系统接收，但在备用系统中漏掉的可能性高。这是因为，由于现用系统和备用系统从同一数据链路接收包，所以认为交换顺序罕见。因此，此情况下判断为需要再发送(步骤S105J，YES)，将保存在接收包缓冲器10213中的包P2发送给备用系统(步骤S105K、S105B)。此外，此情况下，在步骤S105L，指示接收通知接收部10215保存标识符。由此，接受通知接收部10215，将在上述步骤S105G中由分配部10211提交的接收通知包中所含的标识符保存在备用接收履历存储部10214中。

在(y-2)状态的情况下，由于现用和备用中包的接收履历一致，所以判断为不需要再发送(步骤S105J NO)。而且，从接收履历存储部10214及接收包缓冲器10213中删除所有项目(步骤S105L)。

在(z)状态的情况下，由于在备用系统接收包，所以判断为不需要再发送(步骤S105J，NO)。此外，由于存在现用系统还未接收备用系统已接收了的包的可能性，所以在步骤S105L，对接收通知接收部10215指示保存标识符。由此，接受通知接收部10215，将在上述步骤S105G中由分配部10211提交的接收通知包中所含的标识符保存在备用接收履历存储部10214中。但是，如果即使经过一定时间相应包也未到达，则为了防止存储器泄漏，而要删除相应标识符，给相应标识符加标识。

根据上述的理由，如果包虽然已到达现用系统、却未到达备用系统，则根据备用系统接收履历存储部10214的确认从现用系统再次进行发送。因此，就能够解决因仅在备用系统中漏掉接收包而产生的问题(1-a)。

[实施例4的效果]

如上所述，根据本实施例，就能够避免包的漏掉和发送延迟引起的协议状态偏移的继续。其理由在于，备用系统的群集成员包括发送通知发送部10322，向现用系统的群集成员发送表示根据协议处理部121、122、…、12k完成协议处理的发送包；现用系统的群集成员包括确认应答缓冲器10216和接收包控制部10212，当从发送包的地址的对方装置发送过来相对于上述发送包的确认应答包时，以没有从备用系统的群集成员中发送过来表示上述发送包的发送通知包为条件，将确认应答包保存在确认应答缓冲器10216中；当从备用系统的群集成员中发送过来发送通知包时，以在确认应答缓冲器10216中保存有相对于此发送通知包表示发送包的确认应答包为条件，向备用系统的群集成员发送上述确认应答包。

[本发明的实施例5]

实施例1及实施例4中，前提在于，在现用系统和备用系统中，至少产生相同的发送数据，进行含相同数据的包的发送处理。

在SCTP这种保存信息境界的协议中，虽然应用程序写入相同数据，则产生相同数据，但在TCP这种未保存信息境界的协议中，即使写入相同数据，如果发送时钟不同，就存在信息的切痕偏移产生不同的包的情形。

图40中示出具体例。同一附图示出了本系统和它系统的协议发送缓冲器内容的时间变化。最初两系统协议发送缓冲器都是空的(S1081)。

例如，假设包中所含的数据长为1460字节时，应用程序写入3000字节的数据(S1082)。此情况下，如果没有后续的数据，则会输出含1460字节的数据的2个包、和含80字节的数据的1个包(S1083～S1085)。直到来自对方装置的确认应答包达到为止，都在协议发送缓冲器中保持发送数据。

在此，仅在本系统仅最后的数据(80字节)未进行确认应答的状态下，执行下一发送数据的写入处理，在它系统中执行此写入处理之前如果对最后的包的确认应答包达到，则本系统的协议发送缓冲器成为混有2次的写入数据的状态，它系统的协议发送缓冲器成为仅保持第2次写入数据的情形(S1086)。

此状态下，进行下一包的输出处理时，虽然本系统中旧的数据80字节和新的数据1380字节相加，但其它系统中仅输出新的数据1460字节(S1087)。这样一来，包中所含的发送数据的境界就会发生偏移。

这种情况下，如果全部确认应答放置在协议发送缓冲器中的发送数据的话，则由于协议发送缓冲器变空，而在下次写入时再次将相同数据放置在协议发送缓冲器中，由于每一包的发送数据的分割块一致，所以通常不会引起不适合。

但是，如实施例4所述，在发送包的序列号码和确认应答号码相对应进行确认应答的发送时期的控制的情况下，如果发送数据的境界偏移，就难于确认应答和发送数据的相对应。为了解决这种问题，在本实施例中，在不同写入中不混有发送缓冲器的数据。

[说明实施例5的结构]

图41是表示本实施例相关的群集成员的结构实例的方框图。本实施例的群集成员和图35所示的实施例4的群集成员100c的不同点在于，在复制部/写入部172和写入API部152之间包括写入控制部1065、发送缓冲器监视部1066、总量应答通知接收部1063、和写入量通知部1064这点，以及替代接收侧分配滤波器131c及发送侧分配滤波器132c包括接收侧分配滤波器1061及发送侧分配滤波器1062。再有，在图41中，省略读取API呼叫捕捉部161、复制部/核对部171、读取API部151、控制部173及传输部174的图示。此外，与图35相同的符号表示相同部分。此外，本实施例的群集成员也与实施例4的群集成员一样能由程序来实现。

写入控制部1065具有按照请求使发送数据的写入延迟的功能。

发送缓冲器监视部1066具有检查协议处理部121、122、…、12k的协议发送缓冲器1020是不是空的的功能。

总量应答通知接收部1063具有收取发送侧分配滤波器1062发行的总量应答通知的功能。

写入量通知部1064具有向发送侧分配滤波器1062通知作为发送数据写入的数据的量的功能。

发送侧分配滤波器1062特征为包括写入量通知接收部10624、发送量计量部10622及总量应答通知部10623。再有，在图41中，示出发送侧分配滤波器132、132c所包括的其它构成要素内、仅滤波器处理部10621，除此之外省略图示。

此外，接收侧分配滤波器1061特征在于，包括应答捕捉部10612。在图41中，示出接收侧分配滤波器131、131c所包括的其它构成要素内、滤波器处理部10611，除此以外省略图示。

写入量通知接收部10624具有收取写入时从写入量通知部1064发行的写入量通知的功能。

发送量计量部10622具有计量从滤波器1062发送的包中所含的数据的量的功能。

总量应答通知部10623具有向API侧的总量应答通知接收部1063通知写入数据的总量发送、应答的情形的功能。

应答捕捉部10612具有捕捉带规定的序列号码的确认应答包的功能。

[说明实施例5的动作]

在图42A、42B中示出了本实施例的动作。

应用程序110呼叫写入API部152时，写入API呼叫捕捉部162就在实际的呼叫写入API部152前进行冗余化处理(步骤S1071)。此冗余化处理后，在写入处理前还进行以下处理。

首先，写入API呼叫捕捉部162利用发送缓冲器监视部1066核查在协议发送缓冲器1020中是否存在剩余数据，即协议发送缓冲器1020是不是空的(步骤S1072)。然后，如果有剩余数据(步骤S1072，NO)，就结束此发送，一直到无剩余数据为止进行待机(步骤S1073)。

虽然通常通过对协议发送缓冲器1020的固定间隔的轮询(polling)来进行剩余数据的检查，但为了提高性能而缩短上述固定间隔时，就需要频繁地进行检查，而浪费计算资源。由于存在等到协议发送缓冲器1020变空花费长时间的情形，所以这种监视不是有效的。因此，在本发明中，直到收取总量应答通知前都不进行剩余数据的检查。

当总量应答通知部1063接收总量应答通知时(步骤S1074)，写入API呼叫捕捉部162就指示发送缓冲器监视部1066开始检查，由此，发送缓冲器监视部1066一直到无剩余数据为止，进行协议发送缓冲器1020的检查(步骤S1075、S1076)。

然后，当由发送缓冲器监视部1066检测出无剩余数据时(步骤S1075，YES)，写入API呼叫捕捉部162就通过写入量通知部1064将写入对象数据的数据量(写入量)传递给发送侧分配滤波器1062(步骤S1077)。此后，呼叫写入API部152，执行写入(步骤S1078、S107B)。

当写入量通知接收部10624接收写入量时(步骤S1079)，发送侧分配滤波器1062内的发送量计量部10622，就从此刻起开始发送数据量的计量(步骤S107A)。

每当从最下位层的协议处理部121提交冗余化对象的包时，发送量计量部10622，就将其所含的数据量累计在发送量中(步骤S107C、S107D)。

此后，发送量计量部10622通过核查累计的发送量是否为由写入量通知接收部10624接收的写入量，来判断本次从协议处理部121提交的发送包是不是发送写入对象数据的最后的发送包(步骤S107E)。

然后，在不是发送写入对象数据的最后发送包的情况下(步骤S107E，NO)，发送量计量部10622将上述发送包提交给滤波器处理部10621。由此，滤波器处理部10612则按照请求对上述发送包进行滤波处理，此后，通过发送接口142进行发送(步骤S107H、S107I)。

相对于此，在是发送写入对象数据的最后发送包的情况下(步骤S107E，YES)，发送量计量部10622对应答捕捉部10612输出指示对上述最后发送包捕捉来自对方装置的确认应答包的确认应答监视指示(步骤S107F)。再有，在确认应答监视指示中，含有上述最后的包的序列号码。此后，发送量计量部10622结束发送量的计量处理，将上述最后的包提交给滤波器处理部10621(步骤S107G)。由此，滤波器处理部10621按照请求进行滤波处理，此后，通过发送接口142发送最后的发送包(步骤S107H、S107I)。

另一方面，当从发送量计量部10622输入确认应答监视指示时，应答捕捉部10612，每接收计量发送量的连接(connection)的确认应答包，都核查接收的确认应答包是不是对最后的发送包的确认应答包(步骤S107J、S107K)。具体地，通过核查接收的确认应答包中所含的确认应答号码和确认应答监视指示中所含的序列号码是否一致，来判断是不是对最后的发送包的确认应答包。

然后，在不是对最后的发送包的确认应答包的情况下(步骤S107K，NO)，应答捕捉部10612，等待接收下一确认应答包，进行与上述处理相同的处理(步骤S107J)。

相对于此，在是对最后的发送包的确认应答包的情况下(步骤S107K，YES)，就成为保存在协议发送缓冲器1020中的所有发送对象数据由对方装置确认了应答，由于协议发送缓冲器1020应该是空的，所以应答捕捉部10612向总量应答通知部10623通知此意思。由此，总量应答通知部10623对总量应答通知接收部1063发行总量应答通知(步骤S107L)。

当总量应答通知接收部1063接收总量应答通知时(步骤S1074)，写入API呼叫捕捉部162则直到协议发送缓冲器1020变空为止进行等待(步骤S1075、S1076)，一旦协议发送缓冲器1020变空，就进行上述的步骤S1077以后的处理。

如上所述，在本实施例中，由于必须在协议发送缓冲器1020变空后进行写入处理，所以多次写入的发送数据不发送进一个包中，发送数据的包化时的境界在现用和备用中没有偏移。