CN1423197A - 基于多tcp连接映像的高可用系统 - Google Patents
基于多tcp连接映像的高可用系统 Download PDFInfo
- Publication number
- CN1423197A CN1423197A CN02147870A CN02147870A CN1423197A CN 1423197 A CN1423197 A CN 1423197A CN 02147870 A CN02147870 A CN 02147870A CN 02147870 A CN02147870 A CN 02147870A CN 1423197 A CN1423197 A CN 1423197A
- Authority
- CN
- China
- Prior art keywords
- server
- tcp
- module
- address
- submodule
- 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.)
- Pending
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种基于多TCP连接映像的高可用系统。该系统中各个服务器均包含有心跳监测模块、IP抢占模块和TCP连接容错模块。其工作流程和方法中运用了状态检测技术、IP地址抢占技术、TCP连接容错技术、选举主服务器技术以及TCP初始连接同步技术。所发明的基于多TCP连接映像的高可用系统与现有的系统相比,不需要做日志,恢复时间更短,可用性更高,同步机制不需要额外的通信开销,能真正做到无缝接管且不需要修改客户端的任何软件。
Description
技术领域
本发明属于计算机网络技术领域,具体涉及一种基于多TCP连接映像的高可用系统。
背景技术
随着Internet的飞速发展,网络服务已经成为计算机应用领域中一个重要的组成部分,并且大多数网络服务是基于传输控制协议TCP连接,如:文件传输服务、远程登录服务、WEB服务等。一旦这些服务在运行中出错,比如机器掉电、系统死机、服务程序出错,那么原有的连接信息就会丢失。如果只是简单的在备份服务器上抢占主服务器的IP地址,并重新启动该服务,那么原来已经建立的连接就会中断,客户程序同样会发现服务程序出错。但是,传统的TCP协议由于本身设计的原因,不能给这些已断掉的连接提供容错功能,从而无法使这些服务器系统具有高可用性。
国外已经针对上述问题对基于TCP连接容错的高可用系统做了初步的研究,但都面临以下三个问题:一是有些系统对TCP连接状态做日志,开销太大;二是有些系统需要修改客户端的应用程序,而通常客户端是不受控制的;三是有些系统只能保证故障发生后的连接能正常工作,而原来建立的连接就会中断,这样不能保证对客户端透明。如:FT_TCP(见Texas大学计算机科学系2001年7月技术报告)在服务器端围绕TCP加入一层包装器wrapper(如图1所示)。Wrapper由三个部分组成(1)日志器(Logger):专门负责做日志。除此之外,它还要检测原服务器的状态,在发现服务器失效后接管它的工作,重新启动服务器服务程序,并利用日志信息与服务器进行假通讯,即重新向服务器请求一个TCP连接,把客户失效前传出的数据包重新传给服务器,使得恢复后的连接与原连接状态一致。(2)南桥(South Side Wrap):处于IP层和TCP层之间。它一方面接收从IP层传往TCP层的数据包,将它传往Logger和TCP层;另一方面接收从上层TCP来的数据包,并根据从Logger过来的确认信息对这些数据包做相应的修改,然后发给下层的IP层传送给客户。保证错误发生后对客户端透明。(3)北桥(North Side Wrap):处于TCP层之上,用户程序之下。主要是记录服务器端建立的套接口Socket读数据的长度(通过Logger保存),以便在恢复时也读到这个长度,保证恢复前后状态的一致性。这种方案的缺点:对每个经过TCP层和IP层的包都要做日志,系统开销过大并且恢复的时间过长。
发明内容
本发明针对现有的高可用系统的不足,提出了一种新的基于多TCP连接映像的高可用系统。此系统不需要对连接状态作日志及修改客户端的软件,只要有一台服务器没有失效,客户端与服务器的TCP连接就不会被中断。
为实现上述发明目的,一种基于多TCP连接映像的高可用系统,客户通过网关与服务器通信,其特征在于:该系统包括N(N≥2)个服务器,N个服务器均包括心跳监测模块、IP抢占模块和TCP连接容错模块;心跳监测模块用于故障检测,当出现故障时,将故障状态通知其它模块;IP抢占模块通过发送免费ARP包来通告系统对外的虚拟IP地址,当主服务器失效时,负责无冲突地选举出一个新的主服务器,并把对外的虚拟IP地址绑定在这个新的主服务器的网卡上;TCP连接容错模块负责将用户的一个TCP连接能够同时与几个服务器通信。
上述心跳监测模块包括状态监测子模块、接收子模块和选举子模块;状态监测子模块负责每隔一段时间向多播组发送自己的心跳信息,以表明自己还处于激活状态;接收子模块负责接收其它服务器发来的心跳信息;选举子模块负责在系统初启时通过配置文件决定谁是主服务器。
上述TCP连接容错模块包括TCP初始连接的同步子模块、分发器和聚合器;TCP初始连接的同步子模块负责对每个TCP初始连接进行同步;分发器负责将从客户来的TCP数据包分发到各个处于激活状态的服务器;聚合器负责收集各个服务器应答的TCP数据包进行处理,做成一个统一的应答数据包发送给客户端程序,让客户端程序感觉自己只是与一个服务器在通信。
本发明所述的基于多TCP连接映像的高可用系统,具有如下优点:
1)不需要做日志。在本系统中,TCP的连接信息不是通过做日志来进行备份的,而是通过在其它的备份服务器建立同步的TCP连接(多个TCP连接映像)达到备份效果的;
2)连接的恢复时间更短。由于主服务器和备份服务器上相应的TCP连接在通信的过程中一直保持着同步,所以主服务器失效,从某个备份服务器上恢复这些连接信息就会变得容易些,不用根据日志从头开始恢复,从而缩短了连接信息的恢复时间;
3)可用性更高。N台服务器只要有一台没有失效,就可以保证服务不会被中断。但是,N台服务器同时失效的可能性是很小的。
4)同步机制不需要额外的通信开销。在TCP连接信息同步中,我们借用了TCP本身实现上的一些特征(如超时重发,对重传数据包的自我消化能力)来达到同步的效果;
5)当主服务器失效时,备份服务器能以与主服务器一致的状态进行故障接管,真正做到无缝(seamless)接管,且对用户透明;
6)不需要修改客户端的任何软件;
7)在多机系统中避免了对开机先后次序的约束。
附图说明
图1为现有技术中的FT_TCP结构示意图;
图2为本发明基于多TCP连接映像的高可用系统结构示意图;
图3为基于多TCP连接映像的高可用系统的工作流程示意图;
图4为无失效服务器时,基于多TCP连接映像的高可用系统的工作流程示意图;
图5为服务器状态监测结构示意图;
图6为浮动的虚拟IP示意图;
图7为分发器实现的软件示意图;
图8为聚合器实现的软件示意图。
具体实施方式1体系结构
基于多TCP连接映像的高可用系统的系统结构示意图如图2所示。在这种结构中,N个服务器(41、42、43、……、4n)都有机会成为主服务器。但任何时候只会有一个主服务器,其它处于激活状态的服务器都作为备份服务器存在。一旦当前的主服务器因故失效,系统会自动通过一个选举算法从备份服务器中选出一个新的服务器作为新的主服务器,继续提供服务。这期间,原有的TCP连接将通过同步信息恢复,不会被中断。
在该系统中,主服务器和备份服务器都运行着相同的服务程序。其中,主服务器和备份服务器分担着不同的工作:
主服务器:对客户而言,主服务器绑定整个系统对外的虚拟IP地址,负责截获从客户来的TCP数据包并分发到所有处于激活状态下的服务器;对局域网中的服务器而言,主服务器绑定内部局域网的网关地址,截获所有备份服务器的应答包并通过一定的同步机制做成一个统一的应答包回送给客户。
备份服务器:记录从主服务器转过来的连接。
该系统每个服务器包括三个模块:心跳监测模块1、IP抢占模块2和TCP连接容错模块3,模块间的关系如图2所示。各模块的功能如下:
心跳监测模块(1):该模块的主要功能是在系统启动时通过读取配置文件从所有服务器中第一次推举出一个主服务器并且在以后的过程中进行故障检测。检测系统中服务器是否失效、服务是否失效、网络是否失效。当出现故障时,它将故障状态通知其它模块,以便其它模块能够及时做出相应的处理。如果失效的是备份服务器,本模块仅将其从服务器链表中删除;如果失效的是主服务器,则所有备份服务器的此模块进行合作选举出一个新的主服务器。
IP抢占模块(2):当主服务器失效时,心跳监测模块按照一定的算法无冲突地选举出一个新的主服务器后,本模块通过发送免费ARP包来通告系统对外的虚拟IP地址,并把对外的虚拟IP地址绑定在这个新的主服务器的网卡上。
TCP连接容错模块(3):该模块由TCP初始连接的同步、分发器和聚合器三个子模块组成,使得用户的每个TCP连接同时在多个服务器上保存有同步的映象。
TCP初始连接的同步子模块:对每个第一次到达主服务器的TCP连接进行初始同步。
分发器:将从客户来的TCP数据包分发到各个处于激活状态的服务器。
聚合器:收集各个服务器应答的TCP数据包,对其进行一定的处理,做成一个统一的应答数据包发送给客户端程序,让客户端程序感觉自己只是与一个服务器在通信。2工作流程描述2.1正常工作流程
正常工作流程如图4所示。
1)客户以虚拟IP地址发送请求;
2)拥有虚拟IP地址的主服务器收到请求后,通过IP层的分发器,发往各备份服务器;
3)主服务器和备份服务器分别根据收到的请求进行处理;
4)请求处理完毕后,将返回的数据传给各自的IP层;
5)备份服务器在IP层收到来自本机的数据包后,将此数据包的目的地址修改为主服务器的地址并重新计算校验和,所有返回给主服务器的数据包通过聚合器进行聚合处理;
6)将聚合后的数据发往客户。2.2主服务器失效后的处理
主服务器失效后处理流程如图3所示。
1)运行在备份服务器上的心跳监测模块1检测到主服务器失效;
2)备份服务器启动选举算法选举出新的主服务器。如果备份服务器发现选举出来的主服务器是自身,则将自己状态变量g_node_state的值由BACKUP变为PRIMARY;
3)新的主服务器从hostlist链表中删除失效的服务器,并且遍历连接哈希表,将相关数据项的状态置为INACTIVE,将连接哈希表中所有未完成的连接的状态置为RECOVERY;
4)启动IP抢占模块2,对外宣告接管了虚拟IP地址和内部网关地址;
5)启动分发器和聚合器;
6)分发器接收客户转来的数据包并将它发给处于激活状态的服务器;
7)聚合器收集从各个服务器发来的应答包,每来一个应答包,就将相应连接的所有服务器的状态从RECOVERY变为ESTABLISHED;
8)对于某个连接来说,当它的各个激活服务器的状态都从RECOVERY变为ESTABLISHED后,则该连接的状态从RECOVERY状态变为ESTABLISHED。此后,该连接就处于正常传输状态。2.3备份服务器失效后的处理
备份服务器失效后处理流程如图3所示。
1)备份服务器失效;
2)经过给定时间之后,主服务器发现备份服务器失效,将其从hostlist链表中删除,另外,锁住当前连接哈希表,将其中每个活动连接的该服务器状态置为INACTIVE,然后释放连接哈希表;
3)将数据包分发给那些处于激活的服务器。此时分发器在分发的过程中不会再将数据包分发给这个失效的备份服务器;
4)聚合器聚合所有处于激活服务器的应答包。此时聚合器不再等待失效的备份服务器的应答包。3、各模块的实现3.1心跳监测模块
为了对整个系统中各个服务器的状态进行监测,本发明在心跳监测模块中包含了三个核心子模块,它们的功能分别如下:
1)状态监测子模块:每隔一段时间,就向多播组发送自己的心跳信息,以表明自己还处于激活状态。
如图5所示,心跳信息是以多播的形式发给系统中的其它服务器机的,每个服务器在发送自己的心跳信息的同时也在接收其它各个服务器传来的心跳信息。一旦某个服务器失效,其它任何服务器就无法收到来自它的心跳信息,当这个时间超过一定的间隔时间(我们是以四个心跳信息的间隔时间为准,可以进行设置)后,其它服务器就将它的状态标记为INACTIVE。
心跳信息的报文格式:
syncaddr | id | primary |
syncaddr:用来传送心跳信息的网卡接口的内部IP地址。
id: 该服务器的编号。
Primary: 表示该服务器是否为主服务器(0——备份服务器,
1——主服务器)。
hostlist在整个系统中是一个很重要的数据结构,用来记录当前处于激活状态下的服务器,它是心跳监测模块和TCP连接容错模块的一个公共数据集。心跳监测模块要根据hostlist进行正确的选举,TCP连接容错模块也要根据hostlist把数据包分发给那些处于激活状态的服务器。hostlist的管理主要由心跳监测模块完成。
2)接收子模块RcvThread:接收其它服务器发来的心跳信息。
3)选举子模块VotingThread:系统初启时此子模块通过配置文件决定谁是主服务器。具体方法如下:服务器初启,读配置文件,发现自己被配置为主服务器,这时候不是立刻把自己推举为主服务器,而是监听心跳信息的接收端口一段时间(至少要大于心跳信息的间隔时间,这样才能保证收到已启动的服务器的心跳信息),根据接收到的心跳信息判断系统中是否已经存在一个主服务器,如果存在,则不推举自己为主服务器,以避免冲突;如果不存在,才将自己推举为主服务器。这样处理避免了对开机先后次序的约束。
在以后的过程中,此子模块还每隔一段时间(可以设置)就检查当前系统中服务器的状态:当发现主服务器失效时,则重新从处于激活的备份服务器中选举出一个新的主服务器;当发现某个备份服务器失效时,则将该服务器从记录服务器的链表中删除。选举机制:根据各个服务器的id号来判断谁来担当主服务器,其基本思想就是看谁的id号最小。其中,id号在每个服务器的配置文件中给出。当系统初启后一段时间,每个服务器的状态信息(hostlist_head)都建立起来了,其中保存着每个服务器的id号,而且hostlist_head在每个服务器上都是相同的。当某个服务器失效时,其它服务器将从各自的hostlist_head中删除此失效服务器,因此,对每个仍处于激活状态的服务器来说都有一个由所有处于激活状态服务器的id号组成的集合,那么在这个相同的集合中找一个最小id,其结果必然相同,这就保证了选举的一致性。选举结果出来后,每个服务器将这个结果与自己的id号相比较,如果与自己的id号相同,则启动IP抢占线程,将系统对外的虚拟IP地址抢过来绑定在自己的外部网卡上,同时也要把内部局域网的网关地址抢过来绑定在自己的内部网卡上。
服务器失效的判断方法:
RcvThread每收到一个服务器传来的心跳信息(心跳监测Thread发出),就根据自己的时钟,将该服务器的LastUpdateTime变量更新一次,VotingThread核心线程就是通过检测每个服务器的LastUpdateTime来判断服务器状态的。服务器失效条件为:CurrentTim-LastUpdateTime > DEATHVERDICTTIME3.2IP抢占模块
当一台主机把以太网数据帧发送到位于同一局域网上的另一台主机时,是根据48位的以太网地址而不是根据IP地址来确定目的接口的。地址解析为这两种不同的地址形式提供了映射:32bit的IP地址和数据链路层使用的地址(如MAC地址)。
地址转换协议ARP为IP地址到对应的硬件地址之间提供了动态映射。每个主机都有一个ARP高速缓存。它存放了最近Internet地址到硬件地址之间的映射记录。当一个IP包经过路由选择后,就可得到下一站路由器地址或目的主机的地址,然后在ARP高速缓存中去寻找与之对应的MAC地址,如果未找到,则在局域网内广播一个ARP请求分组,该分组携带下一站的IP地址或目的主机的IP地址,该局域网内的其它主机收到这个ARP分组后就会将分组中携带的IP地址与自己的地址进行比较,如果相同,则将自己的MAC地址包装在ARP应答包中,回送给请求的主机。发出请求的主机收到应答包后,就将这个新的IP地址与MAC地址映射关系添加到自己的ARP缓存中,然后根据这个MAC地址发送IP数据包。
在本发明中,引入了一个浮动的虚拟IP地址,模块示意图如图6所示。这里的浮动是指这个虚拟IP地址可以转移。它被绑定在主服务器的一个网络接口上。当主服务器失效时,这个虚拟IP地址可以移动到新的主服务器的一个网络接口上。
在主机上设置一个虚拟IP地址需要通过相应的内核函数创建一个逻辑网络接口。虚拟IP地址与主机的某个实际的物理网卡具有相同的MAC地址。向外广播携带虚拟IP地址和主机外部网卡MAC地址的ARP应答包,可以更新同一子网内其它主机的ARP缓存。由于ARP高速缓存中每一项的生存时间一般为20分钟,所以需要每隔一段时间发送一次ARP应答包,这样才能保证其它主机都会将发往虚拟IP地址的IP包正确的发到拥有虚拟IP地址的主机上。
当主服务器失效时,为了让新的主服务器接管这个虚拟IP地址,需要立即在新的主服务器的外部网卡上创建一个同样的逻辑网络接口,广播带有自己的MAC地址的ARP应答包到其它主机,使得其它主机的ARP缓存得到更新,以便将传给虚拟IP地址的IP包定向到这个新的MAC地址。3.3TCP连接容错模块
TCP连接容错模块位于IP层与TCP层之间,一方面它要截获送往IP层的数据包,并把它分发给所有处于激活状态的服务器(由分发器完成);另一方面,服务器的应答数据包也要通过主服务器发送出去,聚合器要对这些应答的数据包进行处理,以达到同步的效果(由聚合器完成)。本模块由以下三个子模块构成:1)TCP初始连接的同步子模块
聚合器正常工作的前提是每个TCP连接的初始序列号要一致。因此,需要设置一个TCP初始连接的同步子模块负责对每个TCP初始连接进行同步。同步过程如下:
在主服务器IP层的NF_IP_PRE_ROUTING处,对进来的syn包,首先调用HA_Init_tcp_v4_sequence计算一个初始序列号,将结果放入tcph->ack_seq中,且将tcph->res1置为1;将修改过的syn包传到TCP层,TCP收到包,首先检查tcph->res1,如果为1,取出tcph->ack_seq中的值作为第二次握手信息的初始序列号,同时在IP层将此包复制一份转发给所有激活的备份服务器,备份服务器收到此包后,检测tcph->res1的值,如果tcph->res1等于1,取出tcph->ack_seq的值作为第二次握手信息的初始序列号。从而使得主服务器和备份服务器产生的第二次握手信息的初始序列号相同,这是聚合器正常运转的首要条件。2)分发器
分发器是在NF_IP_PRE_ROUTING处注册一个钩子函数,它负责截获客户端发来的数据包并进行分发。分发就是在IP层复制经过的数据包skb,然后修改其目的地址为各服务器机的地址,重新计算TCP和IP层的校验和,然后转发出去。分发器用到一个很关键的数据结构ha_conn,该结构记录与当前连接有关的所有服务器的状态信息(node_info),包括IP地址。从客户端发往服务端的每个数据包都会被分发给所有服务器。具体的分发过程如图7所示。
(1)判断目的IP地址是否为服务器端对外的虚拟IP地址,协议类型是否为TCP,不是则将此包丢弃,是则转(2);
(2)连接哈希表(ha_conn_table[])中查找相应的连接;
(3)找出该连接(ha_conn)中的所有服务器(head_node_list),为它们分别发一份数据包,分发过程如下:
(a)skb_copy得到一份拷贝;
(b)修改目的地址;
(c)为TCP首部重新计算校验和;
(d)用ip_send_check(struct iphdr*)为IP首部重新计算校验和;
(e)调用ip_rcv_finish(struct skb_buff*)对该数据包进行路由和转发。
需要说明的是,虽然这里没有修改TCP首部的数据,但对TCP进行校验和的重新计算仍然是有必要的。因为TCP包含一个12字节长的伪首部,它是为了计算校验和而设置的。伪首部包含IP首部的一些字段,其目的是让TCP两次检查数据是否已经正确到达目的地:第一次确保IP没有接受到地址不是本服务器的数据包;第二次确保IP层没有把应该传给另一高层协议的数据包错传给TCP层。TCP校验和的计算包括了伪首部,所以,修改了IP首部的目的地址之后,需要重新更新TCP校验和。3)聚合器
各个服务器处理请求之后,产生的应答消息可能会由于各自资源的不同,产生数据不一致的情况。为了同步各服务器间的状态,本方案在NF_IP_POST_ROUTING处插入了聚合器。聚合器的主要工作是完成数据的聚合应答,形成一个能使各服务器状态同步的应答发往客户端。聚合应答的基本思想就是让应答快的服务器等待应答慢的服务器。本方案并不是对所有的应答包进行转发,而是有选择的转发。对于一段新的数据包,只有当确认所有的服务器都已经发送过此包之后才会被转发出去。
在实现中用到如下数据结构:
对于每个连接,在主服务器中都有一个这样的结构。Node_info记录了每个服务器发送序号、确认序号和窗口大小,ha_conn中的相关数据结构是根据各个服务器记录信息推导出来的。
node_info中的数据项:
send_seq:表示该服务器的连接数据要发送的下一个序
列号。
ack_seq: 表示该服务器希望收到的从客户传来的数据
的序列号。
window: 表示该服务器接收窗口的大小。
ha_conn中的数据项:
min_send_seq:用于输出流的处理。表示发送最慢的服
务器发送到什么地方,它之前的数据已
经被所有的服务器发出。其值等于各个
服务器中send_seq的最小值,可以保证
输出流的同步。
min_ack_seq:用于输入流的处理。表示最小的应答序
号,它之前的数据已经被所有的服务器
正确的收到并确认。其值等于各个服务
器中ack_seq的最小值可以保证输入流
的同步。
min_window:表示各个服务器最小的接收窗口大小。
具体的聚合过程如图8所示。
(a)分发器在连接请求建立后将各数据结构初始化;
(b)对于所有来自服务器的数据包,先更新此服务器的(node_info)的记录信息send_seq和ack_seq,并重新计算ha_conn中的min_send_seq和min_ack_seq;
(c)假如此数据包是不带数据的纯ACK应答包则直接发送出去,否则转d);
(d)假如是重传的数据包也需要直接发送,以防止聚合器发出去的数据包在中途丢失,否则转e);
(e)假如是失序的数据包,则直接丢掉,等待按序到达的数据包,而这些被丢弃的失序包因为没有被应答,会由该服务器重传,否则转f);
(f)假如是按序到来的带有数据的应答包,则继续判断min_send_seq是否被更新。如果min_send_seq得到更新,则说明该服务器的数据是最后到达的一个,之前其它服务器已经传出了这个数据段。在这种情况下,聚合器会把这段各服务器都已经发送过的数据选择一个最短的发送出去;
(g)聚合器会把每个出去的数据包中TCP首部的window字段改为min_window,ack_seq字段改min_ack_seq,源IP电址改为虚拟IP地址;
(h)重新计算要发送出去的数据包的TCP校验和,IP校验和,然后调用ip_finish_output2(struct sk_buff*skb)函数把数据包发送出去。
在具有4个(2个或2个以上服务器均可)服务器上构建一个TCP连接容错系统,其基本配置如表1、表2所示,各服务器上的配置文件如表3所示。
CPU | Memory | NIC | PCI BUS | OS | Connection | |
服务器 | 奔41.4GHZ | 256MPC100SDRAM | 3Com3c905B100BaseTX | 32-BIT33MHZ | Redhat7.1KernelVersion2.4.2 | 双绞线 |
表1各服务器的硬件配置
机器名 | NIC A | NIC B | Netmask | Gateway |
服务器A | 10.0.0.1 | 192.168.0.201 | 255.255.255.0 | 10.0.0.100 |
服务器B | 10.0.0.2 | 192.168.0.202 | 255.255.255.0 | 10.0.0.100 |
服务器C | 10.0.0.3 | 192.168.0.203 | 255.255.255.0 | 10.0.0.100 |
服务器D | 10.0.0.4 | 192.168.0.204 | 255.255.255.0 | 10.0.0.100 |
表2各服务器的网络配置
#server ip primary
192.168.0.201 1
192.168.0.202 0
192.168.0.203 0
192.168.0.204 0
表3各服务器中的配置文件
其中,一台作为主服务器,其余的服务器均作为备份服务器。具体实施如下:主服务器启动本发明底模块后将内部网关地址10.0.0.100绑定在自己的内部网卡NIC A上,作为一个内部的可浮动的IP地址;另外,主服务器还要将外部虚拟地址211.69.0.150绑在自己的外部网卡NIC B上,客户端程序就是通过这个外部虚拟地址地址来与服务器进行TCP连接通信。每台机器均需要装载本发明的模块(3个子模块),但系统初始化时,只在主服务器上启动心跳监测模块及分发器、聚合器;在备份服务器上启动心跳监测模块。
Claims (3)
1、一种基于多TCP连接映像的高可用系统,客户通过网关与服务器通信,其特征在于:该系统包括N(N≥2)个服务器,N个服务器均包括心跳监测模块、IP抢占模块和TCP连接容错模块;
所述心跳监测模块用于故障检测,当出现故障时,将故障状态通知其它模块;
所述IP抢占模块通过发送免费ARP包来通告系统对外的虚拟IP地址,当主服务器失效时,负责无冲突地选举出一个新的主服务器,并把对外的虚拟IP地址绑定在这个新的主服务器的网卡上;
所述TCP连接容错模块负责将用户的一个TCP连接能够同时与几个服务器通信。
2.根据权利要求1所述的高可用系统,其特征在于:所述心跳监测模块包括状态监测子模块、接收子模块和选举子模块;
所述状态监测子模块负责每隔一段时间向多播组发送自己的心跳信息,以表明自己还处于激活状态;
所述接收子模块负责接收其它服务器发来的心跳信息;
所述选举子模块负责在系统初启时此子模块通过配置文件决定谁是主服务器。
3.根据权利要求1或2所述的高可用系统,其特征在于:所述TCP连接容错模块包括TCP初始连接的同步子模块、分发器和聚合器;
所述TCP初始连接的同步子模块负责对每个TCP初始连接进行同步;
所述分发器负责将从客户来的TCP数据包分发到各个处于激活状态的服务器;
所述聚合器负责收集各个服务器应答的TCP数据包进行处理,做成一个统一的应答数据包发送给客户端程序,让客户端程序感觉自己只是与一个服务器在通信。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN02147870A CN1423197A (zh) | 2002-12-16 | 2002-12-16 | 基于多tcp连接映像的高可用系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN02147870A CN1423197A (zh) | 2002-12-16 | 2002-12-16 | 基于多tcp连接映像的高可用系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1423197A true CN1423197A (zh) | 2003-06-11 |
Family
ID=4751350
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN02147870A Pending CN1423197A (zh) | 2002-12-16 | 2002-12-16 | 基于多tcp连接映像的高可用系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN1423197A (zh) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100367714C (zh) * | 2004-02-27 | 2008-02-06 | 联想(北京)有限公司 | 基于网络和主机负载的变速心跳机制的实现方法 |
CN100420251C (zh) * | 2005-02-01 | 2008-09-17 | 北京北方烽火科技有限公司 | 一种集群中主控节点自适应选举算法 |
CN1905472B (zh) * | 2005-07-27 | 2010-05-05 | 华为技术有限公司 | 一种ims网络可靠性实现方法 |
CN1770733B (zh) * | 2004-10-27 | 2010-08-25 | 摩根士丹利公司 | 容错网络构架 |
CN101916217A (zh) * | 2010-08-04 | 2010-12-15 | 中兴通讯股份有限公司 | 多控制器切换的方法、控制装置及系统 |
CN1921369B (zh) * | 2006-08-08 | 2011-02-09 | 华为技术有限公司 | 一种网络连接的接管方法 |
CN103580915A (zh) * | 2013-09-26 | 2014-02-12 | 东软集团股份有限公司 | 集群系统中确定主控节点的方法及装置 |
CN103856443A (zh) * | 2012-11-29 | 2014-06-11 | 台众计算机股份有限公司 | 网点的判断与阻挡的方法 |
CN103944745A (zh) * | 2013-01-22 | 2014-07-23 | 腾讯科技(深圳)有限公司 | 一种计算机容灾方法及系统 |
CN105391574A (zh) * | 2015-10-28 | 2016-03-09 | 曙光云计算技术有限公司 | 一种服务器地址设置方法及装置 |
CN107919994A (zh) * | 2017-12-13 | 2018-04-17 | 南京熊猫电子股份有限公司 | 实现网络服务双机热备的方法及服务器 |
CN110474797A (zh) * | 2019-07-25 | 2019-11-19 | 北京旷视科技有限公司 | Api业务系统、主备切换的方法及装置 |
CN110838935A (zh) * | 2018-08-15 | 2020-02-25 | 上海宽带技术及应用工程研究中心 | 高可用sdn控制器集群方法、系统、存储介质及设备 |
CN113709004A (zh) * | 2021-09-03 | 2021-11-26 | 天津津航计算技术研究所 | 一种Linux系统下主从模式网口绑定时接收流量的监控方法 |
-
2002
- 2002-12-16 CN CN02147870A patent/CN1423197A/zh active Pending
Cited By (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN100367714C (zh) * | 2004-02-27 | 2008-02-06 | 联想(北京)有限公司 | 基于网络和主机负载的变速心跳机制的实现方法 |
CN1770733B (zh) * | 2004-10-27 | 2010-08-25 | 摩根士丹利公司 | 容错网络构架 |
CN100420251C (zh) * | 2005-02-01 | 2008-09-17 | 北京北方烽火科技有限公司 | 一种集群中主控节点自适应选举算法 |
CN1905472B (zh) * | 2005-07-27 | 2010-05-05 | 华为技术有限公司 | 一种ims网络可靠性实现方法 |
CN1921369B (zh) * | 2006-08-08 | 2011-02-09 | 华为技术有限公司 | 一种网络连接的接管方法 |
CN101916217A (zh) * | 2010-08-04 | 2010-12-15 | 中兴通讯股份有限公司 | 多控制器切换的方法、控制装置及系统 |
CN101916217B (zh) * | 2010-08-04 | 2014-08-13 | 中兴通讯股份有限公司 | 多控制器切换的方法、控制装置及系统 |
CN103856443A (zh) * | 2012-11-29 | 2014-06-11 | 台众计算机股份有限公司 | 网点的判断与阻挡的方法 |
CN103944745A (zh) * | 2013-01-22 | 2014-07-23 | 腾讯科技(深圳)有限公司 | 一种计算机容灾方法及系统 |
CN103944745B (zh) * | 2013-01-22 | 2018-10-02 | 腾讯科技(深圳)有限公司 | 一种计算机容灾方法及系统 |
CN103580915A (zh) * | 2013-09-26 | 2014-02-12 | 东软集团股份有限公司 | 集群系统中确定主控节点的方法及装置 |
CN103580915B (zh) * | 2013-09-26 | 2017-01-11 | 东软集团股份有限公司 | 集群系统中确定主控节点的方法及装置 |
CN105391574A (zh) * | 2015-10-28 | 2016-03-09 | 曙光云计算技术有限公司 | 一种服务器地址设置方法及装置 |
CN107919994A (zh) * | 2017-12-13 | 2018-04-17 | 南京熊猫电子股份有限公司 | 实现网络服务双机热备的方法及服务器 |
CN110838935A (zh) * | 2018-08-15 | 2020-02-25 | 上海宽带技术及应用工程研究中心 | 高可用sdn控制器集群方法、系统、存储介质及设备 |
CN110474797A (zh) * | 2019-07-25 | 2019-11-19 | 北京旷视科技有限公司 | Api业务系统、主备切换的方法及装置 |
CN113709004A (zh) * | 2021-09-03 | 2021-11-26 | 天津津航计算技术研究所 | 一种Linux系统下主从模式网口绑定时接收流量的监控方法 |
CN113709004B (zh) * | 2021-09-03 | 2023-06-06 | 天津津航计算技术研究所 | 一种Linux系统下主从模式网口绑定时接收流量的监控方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1086531C (zh) | 多处理器环境运行的进程间的数据包传送方法 | |
CN1423197A (zh) | 基于多tcp连接映像的高可用系统 | |
CN106878166B (zh) | 路由通告方法及装置 | |
CN101136926B (zh) | 非对称路由情况下的报文转发方法及网络地址转换网关 | |
CN1679282A (zh) | Tcp卸载的系统和方法 | |
US20030014684A1 (en) | Connection cache for highly available TCP systems with fail over connections | |
CN1969267A (zh) | 用户级栈 | |
CN1791064A (zh) | 具备自动建立机制的堆叠管理器协议 | |
CN101051951A (zh) | 一种保证服务器接入可靠性的方法及装置 | |
CN1739098A (zh) | 智能网络适配器的状态恢复及故障修复 | |
CN105721315A (zh) | 一种集中式mac地址学习的控制方法 | |
CN1855916A (zh) | 一种实现虚拟网际协议的方法及系统 | |
CN102035751A (zh) | 一种数据的传输方法和设备 | |
CN1497902A (zh) | 路由控制系统、路由控制装置,以及路由控制方法 | |
WO2014000698A1 (zh) | 基于ip层的网络拓扑识别方法和设备 | |
CN1741505A (zh) | 组播静态组备份的方法及组播报文转发的方法 | |
CN101056195A (zh) | 通信系统中主板与备板的数据同步方法 | |
US7814182B2 (en) | Ethernet virtualization using automatic self-configuration of logic | |
WO2008106879A1 (fr) | Procédé et dispositif de traitement de transfert de données | |
CN104184729A (zh) | 一种报文处理方法和装置 | |
JP5029685B2 (ja) | バックアップ装置 | |
CN100423514C (zh) | 分布式设备中地址解析协议数据同步的方法 | |
CN102123049A (zh) | 一种基于MAC地址传输的Cache同步方法 | |
WO2015101026A1 (zh) | 分布式流处理系统的容错方法、节点及系统 | |
CN1203427C (zh) | 一种具有tcp连接容错功能的负载平衡调度方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C12 | Rejection of a patent application after its publication | ||
RJ01 | Rejection of invention patent application after publication |