一种通信方法和系统的制作方法

专利名称：一种通信方法和系统的制作方法
技术领域：
本发明涉及一种通信技术，尤其涉及一种互联网领域内的通信方法和系统。
背景技术：
随着互联网技术的快速发展，使用互联网通信的人数也在飞速地攀升，这时，在互 联网领域中的通信中，常常有许多不确定因素会导致通信故障，如，服务器故障等。为确保 通信的安全可靠，在现有技术中，有如下几种方案。方案一、基于DNS (Domain Name System,域名系统)轮询的负载均衡如图1所示，在该方案中，服务器池中的每一个服务器都是用一个独立的 IPdnternet Protocol,网际协议)地址提供服务，客户机经由互联网、核心L2/L3交换机 向DNS服务器请求解析所访问的服务的域名时，DNS服务器将服务器池中的全部服务器的 IP地址都返回给用户。不同的客户端软件会按照自身的规则选择一个IP地址作为本次访 问请求的目标服务器地址。之后，客户机和这台服务器作点对点通信。然而，在该方案中存在以下缺点1、没有一个用于检查服务器服务健康状态的设备或主机，服务器发生故障后，网 络管理者无法得知这一情况。2、服务器与DNS服务之间没有通信协调。某个服务器发生故障时，用户仍然可以 从DNS服务中得到故障服务器的IP地址。因此，该用户无法获得正常的服务。3、在正常的维护工作中，从服务器池中撤出服务器会对用户产生短期的影响。因 为DNS服务的数据更新和同步需要一个较长的时间过程，此时用户可能会访问到已经撤下 的服务器的IP地址上。方案二、商业四层交换方案之inline (带内工作)模式如图2所示，在该方案中，商用四层交换解决方案中的inline模式是采用“网关” 式的网络结构。服务器使用两个四层(L4)交换机，其中，一台交换机作为主用，假设为L4 交换机A;另一台交换机作为备用，假设为L4交换机B。在两台四层交换机(即L4交换机 A和L4交换机B)之间需要一条专用的线缆连接用来同步更新用户终端和服务器之间的网 络连接状态。四层交换机的IP地址为自身的默认网关。客户机通过互联网、核心L2/L3交 换机对服务器的访问被DNS服务器定向到四层交换机的IP地址，四层交换机接到访问请求 后，将按照一定的轮换算法从服务器池中选择某个服务器。以该服务器的IP地址为目标地 址，以用户的IP地址为源地址，将用户的访问请求转发给该服务器。服务器想要将结果数 据回传给用户，就必须传送给服务器的默认网关(四层交换机)。四层交换机收到服务器要 回传给用户的数据后，以自己的IP地址为源地址，用户的IP地址为目标地址，将数据回传 给用户。这样，在用户端看来，四层交换机就是服务器。四层交换机会定期模拟用户的访问请求发送给每一台服务器池中的服务器，故障 的服务器会由此被四层交换机发现。四层交换机只会将真实用户的请求转发到正常的服务 器上，并可以按照网络管理者的配置报告每个服务器的健康状态。
然而，在该方案中存在以下缺点1.四层交换机必须处理用户和服务器之间的全部网络流量，这要求四层交换机具 有很高的性能，也意味着很高的成本。2.四层交换机的性能必须随着用户和服务器的增加而增加，也意味着成本随之增 加。3.由于四层交换机A本身的单点故障风险，所以四层交换机B必须时刻保留有足 够的空余性能以应对四层交换机A可能发生的故障。而如果四层交换机B上本身有承载其 它的四层交换服务，那么四层交换机A也必须时刻保留足够的空余性能以应对四层交换机 B可能发生的故障。也就是说四层交换机A和四层交换机B的总承载量之和不能超过四层 交换机A和四层交换机B性能之和的一半。4.用户终端和服务器之间的网络流量需要两次经过交换机，这使得交换机的负载 加倍。方案三、商业四层交换方案之单臂模式如图2所示，商用四层交换解决方案中的单臂模式是采用类似于“单向网关”的网 络结构。用户对服务器的访问被DNS服务器定向到四层交换机的IP地址。四层交换机接到 访问请求后，将按照一定的轮换算法从服务器池中选择某个服务器，然后以用户的IP地址 为源IP地址，仍然以原始的目的IP地址(四层交换机本身的IP)为目的IP地址，但是以目 标服务器的MAC地址为目的地址转发此以太网帧(frame)。服务器端的特殊设置是将四层 交换机本身的IP地址(数据报文中的目的IP)绑定在自身的一个非广播型的网络设备上， 比如Ioopback (回环网络设备)或dummy(哑网络设备)类设备。这样，由于用户请求中的 目的IP地址在服务器本身上也存在，服务器在收到四层交换机转发过来的以太网帧后，将 按照普通的正常流程来处理。由于服务器看到的用户请求中的源IP地址是真实的用户本 身的IP地址，所以服务器将要返回的结果数据按照默认路由返给核心的三层交换机，而三 层交换机按照路由表将数据直接回传给用户。这样，就实现了“单臂模式”的四层交换负载 均衡。四层交换机会定期模拟用户的访问请求发送给每一台服务器池中的服务器，存在 故障的服务器会由此被四层交换机发现。四层交换机只会将用户的请求转发到正常工作的 服务器上，并可以按照网络管理者的配置报告每个服务器的健康状态。由于在这种网络结构中，四层交换机A本身存在单点故障风险，所以需要另一台 同样性能规格的四层交换机B来做后备，四层交换机A和四层交换机B之间还需要一条专 用的线缆连接用来同步更新用户和服务器之间的网络连接状态。然而，在该方案中存在以下缺点1.四层交换机仍然必须处理用户到服务器方向的全部网络流量，这仍然要求四层 交换机具有很高的性能。2.四层交换机的性能仍然必须随着用户和服务器的增加而增加，也意味着成本也 随之增加。3.四层交换机A本身仍然存在单点故障风险，四层交换机B必须时刻保留有足够 的空余性能以应对四层交换机A可能发生的故障。而如果四层交换机B上本身承载其他的 四层交换服务，那么四层交换机A也必须时刻保留有足够的空余性能以应对四层交换机B可能发生的故障。也就是说四层交换机A和四层交换机B的总承载量之和不能超过四层交 换机A和四层交换机B性能之和的一半。4.如图2所示，用户到服务器方向的网络流量需要两次经过交换机，仍然使得交 换机的负载增加。总之，现有的通信系统存在通信效率低、成本高的问题。

发明内容
本发明的实施例提供了一种通信方法和装置，可解决现有通信系统通信效率低、 成本高的问题。本发明的实施例提供了一种通信系统，包括交换机、应用服务器和管理服务器。所 述应用服务器，用于接收交换机和/或管理服务器转发的用户请求，并处理该请求，将处理 结果发给交换机；所述交换机，用于将应用服务器的处理结果转发给用户，并在管理服务器 的控制下将用户请求转发至目的地址对应的应用服务器或管理服务器；所述管理服务器， 用于监控应用服务器的状态，并根据应用服务器的状态和预定规则控制交换机的数据转 发，以便在应用服务器故障时，使交换机将发往该故障应用服务器的用户请求转发给管理 服务器。本发明实施例还提供了一种通信方法，包括步骤交换机接收用户请求，并在管理 服务器的控制下将用户请求转发至目的地址对应的应用服务器或管理服务器；管理服务 器监控应用服务器的状态，并根据应用服务器的状态和预定规则控制交换机的数据转发， 以便在应用服务器故障时，使交换机将发往该故障应用服务器的用户请求转发给管理服务 器；应用服务器接收交换机和/或管理服务器转发的用户请求，并处理该请求，将处理结果 发给交换机，并由交换机将应用服务器的处理结果转发给用户。本发明的实施例通过管理服务器监控应用服务器的状态，并根据应用服务器的状 态和预定规则控制交换机的数据转发，以便在应用服务器故障时，使交换机将发往该故障 应用服务器的用户请求转发给管理服务器，可实现服务器的负载均衡、服务器故障屏蔽、自 身故障屏蔽、用户透明模式访问、故障恢复自愈合五项功能；由于在本发明的通信系统中， 在正常通信过程中，管理服务器不参与用户终端与应用服务器之间通信过程，只有在应用 服务器故障时才参与通信系统的管理工作，因此，本发明的通信系统自身的负载，与用户的 数量、访问量无关，与应用服务器的数量无关，只与服务器的故障率和故障恢复时间有关； 这样就彻底解决了交换性能的提升与日益增长的网络流量之间的矛盾，开辟了一个新型的 应用模式。


图1示出了现有技术的一种通信系统；图2示出了现有技术的另一种通信系统；图3示出了本发明实施例的主/备关系协商选举模块的流程；图4示出了本发明实施例的以太网数据帧转发模块的流程；图5示出了本发明实施例的ARP代理模块的流程；图6为本发明实施例的健康检查模块的流程；
图7为本发明实施例的通信系统；图8为本发明实施例的通信方法。
具体实施例方式为了便于本领域一般技术人员理解和实现本发明，现结合附图描绘本发明的实施 例。实施例一本实施例提供了一种通信系统，其包括应用服务器、交换机和管理服务器，下面分 别介绍它们的结构和逻辑关系。应用服务器，用于接收交换机和/或管理服务器转发的用户请求，并处理该请求， 将处理结果发给交换机。应用服务器至少为一台，优选地，在本发明实施例中，应用服务器为多台，这些服 务器的功能是相同的，即为网络用户提供服务。而具体服务的功能可以根据安装部署相应 的应用程序去实现。应用服务器经由交换机连接到其它网络，比如INTERNET互联网)，本 文以下皆以INTERNET为例。来自INTERNET上的网络用户发起的用户请求被交换机转发给 应用服务器，服务器返回的数据结果也经由交换机回传给远端INTERNET上的用户。在软件层次上，应用服务器的配置分成两部分，一部分是服务配置，另一部分是管 理配置。服务配置是指服务器响应用户发出的请求返回结果数据的软件配置。在本发明通 信系统中，用户仍然需要从DNS服务获得相应服务的应用服务器的IP地址列表。我们在此 将这些IP取名为ServicelPs，简称SVCIP，SVCIP与应用服务器并不是一一对应的，例如， 多个或一个SVCIP可以对应一个应用服务器。当DNS服务中仅指配了一个SVCIP时，在服 务器池中的每一台应用服务器上都要配置该IP地址；当DNS服务中指配了多个SVCIP时， 每一台应用服务器都要配置上全部的SVCIP。需要说明的是，为了避免IP地址冲突，应用 服务器将SVCIP (—个或多个)绑定在其非广播型的网络接口上，比如Ioopback设备或是 dummy设备。这样，每一台应用服务器都能对以任意SVCIP为目的的请求做出响应。每一 台应用服务器上配置的SVCIP都是一样的，无论有多少个SVCIP，为了区别每一台应用服务 器，就每一台应用服务器而言，必须再配置上一个不同与其他应用服务器的IP用于定位某 一台应用服务器。我们在此将这些个IP取名叫krverlPs，简称SVRIP。每个应用服务器 都有自己独立的SVRIP，并且只有一个。SVRIP负担着全部的管理工作，必须绑定在应用服 务器的广播型的物理网络接口上，应用服务器使用这个网络接口连接到交换机，SVRIP和 SVCIP必须处于不同的子网(广播域)中。交换机，用于将应用服务器的处理结果转发给用户，并在管理服务器的控制下将 用户请求转发至目的地址对应的应用服务器或管理服务器。交换机是具有网络数据交换功能的专用网络设备。交换机一方面将各种网络服务 器连接在一起，另一方面又和其它网络(比如INTERNET)互联。在本发明的通信系统中，交 换机将应用服务器和管理服务器以及INTERNET连通，使得三者可以在“受控”的前提下相 互通信。受控是指信息传输的目的地可以被交换机改变，而具体的改变策略又是根据初始 配置和各个设备的具体工作状态共同确定的。在软件技术层次上，所有应用服务器的网络接入都最终划归到交换机上的同一个
6VLAN(Virtual Local Area Network，虚拟局域网)中。这个VLAN上绑有两个IP地址，根 据它们相应的掩码，划定出了两个IP子网。这两个子网用于分别覆盖SVRIP和SVCIP，我们 把覆盖SVRIP的子网叫做krver subnet，简称SVRNET ；把覆盖SVCIP的子网叫做Service subnet,简称SVCNET。VLAN上的两个IP也就成为了这两个子网的默认网关地址，分别取名 叫作krver GateWay和krv ice GateWay，简称SVRGW和SVCGW。需要说明的是，虽然是在 同一个VLAN上，SVRNET和SVCNET没有任何的重叠部分，它们是两个独立的广播域。总结 一下，SVRIP属于SVRNET，其默认网关IP是SVRGW ；SVCIP属于SVCNET，其默认网关IP是 SVCGff ；这两个IP子网都在同一个VLAN上。管理服务器，用于监控应用服务器的状态，并根据应用服务器的状态和预定规则 控制交换机的数据转发，以便在应用服务器故障时，使交换机将发往该故障应用服务器的 用户请求转发给管理服务器。管理服务器是一个或多个独立于应用服务器的服务器设备，管理服务器是整个系 统的核心部分，它们对整个系统的工作进行指挥调度。在任何时刻，管理服务器都在监控整 个系统各个设备的工作状况。当某个设备发生故障时，管理服务器会在第一时间发现这个 故障，对系统的整体配置进行修改，并利用自身的承载力弥补这一故障造成的性能和功能 上的损失，使得整体系统的应用服务连续可用。在用户看来，应用服务没有发生故障或中 断，而对于系统管理维护者，可以有足够的时间更换或修复故障的设备。根据本发明实施例，优选地，管理服务器的数量可以在2台到254台之间任意选 择，典型的配置为4台。构成管理服务器的硬件可以是普通的X86架构的微型电子计算机。 操作系统软件方面，管理服务器需要安装提供公开的核心源代码的操作系统，这一要求是 源于部分管理服务器应用逻辑的代码需要工作在操作系统的核心态，也就是说作为操作系 统核心的一部分来运行。这需要在现有的操作系统核心代码的部分功能实现上作扩充修 改，在下文中会详细描述。在物理连接方面，管理服务器使用一个网络接口连接到交换机。其所处的VLAN与 应用服务器相同。管理服务器上按照功能模块划分如下1、多台管理服务器之间的主/备关系协商选举模块2、以太网数据帧转发模块3、ARP代理模块4、健康检查模块下面参照附图描述各个功能模块的过程。如图3所示，当系统采用多台管理服务器时，管理服务器包括主/备关系协商选举 模块，其用于向其它管理服务器组播本管理服务器上每个工作资源的优先级，并通过组播 数据获得其它管理服务器上每个工作资源的优先级，根据各个管理服务器的每个工作资源 的优先级的高低来决定本管理服务器上每个工作资源的工作状态。主/备关系协商选举模 块的工作步骤如下步骤301、各个管理服务器组播自己的每个工作资源的优先级。所述工作资源包 括BCIP、VSIP。步骤302、各个管理服务器由组播信息获取其它管理服务器的每个工作资源的优
7先级。步骤303、各个管理服务器判断自己的工作资源的优先级是否最高，若是，执行步 骤304，否则，执行步骤305。步骤304、设置本管理服务器的该工作资源为工作状态，以便本管理服务器通过该 工作资源收发信息。步骤305、设置本管理服务器的该工作资源为待机状态。如图4所示，数据帧转发模块用于获取并转发包含有用户请求的以太网帧。首先 是按照系统正常工作状态构建转发向量表和连接状态表，而后实时接收健康检查模块对转 发向量表的更新数据并实时接受其它管理服务其对连接状态表的更新数据，并根据本管理 服务器的工作资源状态确定是否进行数据帧转发操作，同时还要组播自身在连接状态表产 生的变化信息。本发明的数据转发机制同样适用其它类型的网络，所述转发向量表的更新 数据包括BSVCIP、SVCIP、SVRIP和转发规则(即，SVCIP与SVRIP之间的对应关系)，所述 连接状态表的更新数据包括UDP会话状态、ICMP消息问答状态和用户和应用服务器之间的 TCP连接状态。数据帧转发模块工作步骤如下步骤401、读取SVCIP、SVRIP和转发表，所述转发表包括正常工作的应用服务器的 SVRIP。并建立转发向量表和连接状态表。步骤402、实时接收本管理服务器健康检查模块对转发向量表的更新数据，并实时 接收其它管理服务其对连接状态表的更新数据。步骤403、判断本管理服务器的工作资源是否为工作状态，若是，则执行步骤404， 否则执行步骤402。步骤404、接收交换机转发的用户请求，并按照某种算法，如轮询、随机、哈希映射 等算法，根据转发向量表对用户的请求数据帧执行转发操作，以便将本应由故障应用服务 器承担的用户请求转发给正常的应用服务器。用户请求可根据SVCIP来确定。步骤405、组播连接状态表的更新变化数据，以便在本管理服务器故障时其它管理 服务器接管转发工作过程中不会导致网络连接(比如tcp连接)中断。如图5所示，ARP代理模块接收其它网络设备对某IP地址的ARP查询请求，并将 该IP地址对应的MAC地址返回该网络设备，所述ARP查询用于获得与SVCIP对应的MAC地 址，所述网络设备包括交换机，ARP代理模块的工作步骤如下步骤501、读取SVRIP列表，利用ARP协议获得SVRIP对应的MAC列表。步骤502、构建SVCIP与MAC的对应表(SVCIP-MAC表)。步骤503、接收健康检查模块的消息实时更新SVCIP-MAC表。如，当SVCIP发生变 化时，SVCIP-MAC表也要发生变化。步骤504、判断本管理服务器的工作资源是否为工作状态，若是，则执行步骤505， 否则执行步骤503。步骤505、接收其它网络设备用于获得与SVCIP对应的MAC地址的ARP查询，并将 该MAC地址返回该网络设备。所述网络设备包括交换机。如图6所示，健康检查模块用于检查应用服务器的状态，以甄别故障应用服务器 和正常工作的应用服务器，借助ARP代理模块，将SVCIP中原来被对应到故障应用服务器的 MAC地址的部分IP用管理服务器的VSIP所对应的MAC地址替换，该替换结果最终表达在交换机的ARP表中，其工作步骤如下步骤601、读取SVRIP列表，并模拟用户访问应用服务器，以发现故障应用服务器 及正常工作的应用服务器。步骤602、将故障应用服务器的IP按照某种算法，如轮询、随机、哈希映射等算法， 用管理服务器的VSIP替换，以构建出新的SVRIP列表。步骤603、利用ARP协议获得新的SVRIP对应的MAC列表。步骤604、将正常工作的应用服务器的SVRIP发送给数据帧转发模块。
步骤605、将SVCIP对应的MAC地址发送给ARP代理模块。步骤606、发送报警信息，并返回步骤601。下面对系统的整个运作原理进行说明在正常的(optimal)工作状态下，管理服务器并不转发用户与应用服务器之间的 通信数据。在前面讲到过，任何一台应用服务器都能以任意SVCIP的身份提供服务，那么管 理服务器在这个情形下只需要按照一定的轮询算法将用户请求引导致某一台应用服务器 即可，而不用关心用户请求中的目标IP地址。管理服务器使用标准ARP协议完成这个工 作。当用户对某一 SVCIP的访问请求抵达交换机时，遵照RFC拟6，交换机会在该SVCIP的可 直达路由端口所在的VLAN内广播一条ARP解析请求。由于SVCIP绑定在应用服务器的非 广播型的网络接口上，该接口不会收到任何广播信息，所以任何应用服务器都不会对此ARP 解析请求做出回应。然而，管理服务器上设有一个广播型的网络接口与该VLAN连接，这样， 管理服务器就能够接收到该ARP解析请求。然后管理服务器上的“ARP代理模块”开始工 作，遵照RFC1027，按照预先人工配置的对应关系(SVCIP与应用服务器之间的关系)，选取 应用服务器的SVRIP所在的网络接口的MAC地址回应给交换机。交换机在得到结果后，将 用户的请求传送到该应用服务器的SVRIP所在的网络接口上。由于用户请求中的目的IP 地址(某个SVCIP)在应用服务器本身上也存在，应用服务器在收到该以太网帧后，将按照 普通的正常流程来处理。由于应用服务器看到的用户请求中的源IP地址是真实的用户本 身的IP，所以应用服务器将要返回的结果数据按照默认路由返给交换机，而交换机按照路 由表将数据直接回传给用户。这样，就实现了在管理服务器不参与转发的情形下的网络通需要进一步说明的是，交换机会缓存ARP地址对照表一段时间，例如本发明的交 换机缓存ARP地址对照表4小时，在这一期间内，交换机不会再广播询问而是直接使用自己 的缓存数据。也就是说，管理服务器在回应ARP询问这一工作上的资源消耗极少，可以忽略 不计。每个管理服务器上的一个广播型的网络接口都连接到SVCNET所在的VLAN，该网络 接口上绑定的IP属于SVCNET。由于该IP的作用是接收和回应ARP广播请求，我们称之为 Broadcast IP简称BCIP。各个管理服务器的BCIP可以相同也可以不同，在下文中有解释。当多台管理服务器协同工作时，为了避免ARP回应冲突，同一时刻只能由一台管 理服务器来处理来自交换机的ARP询问请求。此时管理服务器靠“主/备选举协商模块”来 解决这个问题。主/备选举协商模块每隔一段时间组播(Multicast) —个以太网帧，其接收 者被配置为全部的管理服务器，同时也就能接收来自其它管理服务器的此类以太网帧。这 种机制实现了多台管理服务器之间“工作资源”所有权的选举协商，该以太网帧中包含有两 部分信息，一部分是工作资源，另一部分是优先级。典型的工作资源如IP地址，工作资源可
9以是包含一个IP地址，也可以是包含多个IP地址。各台管理服务器在同一工作资源对应 的优先级被配置为不同的数值。这样，对于某一个工作资源，通过使本管理服务器的优先级 与收到的其它管理服务器组播的在的优先级进行比较，管理服务器可以得知自己是否是对 该工作资源具有最高优先级的管理服务器。如果是，管理服务器会将该工作资源置为活动 状态，同时处理与该资源有关的一切工作任务；如果不是最高的优先级，管理服务器会将该 工作资源置为休眠状态，同时不处理任何与该资源有关的工作任务。在响应ARP询问请求这一工作上，管理服务器的工作资源就是BCIP。每个管理服 务器上都配有BCIP，BCIP可以相同也可以不同。只有优先级最高的管理服务器才会“使用” 它的BCIP，进入工作状态，既回应ARP询问请求。而其它的低优先级的管理服务器会将各自 的BCIP保持在“休眠”状态，既不处理任何与之相关的网络信息，包括单播、组播和广播。这 样既不会出现IP冲突，也不会产生工作冲突。当然最高优先级的管理服务器发生故障时， 它已经不能再向其它管理服务器组播自己的优先级，原来的在BCIP这个资源上是次高优 先级的管理服务器通过组播(multicast)方式发现它自己现在已经是最高的优先级了，于 是它激活自己的BCIP，进入工作状态，在组播方式，管理服务器交流选举信息，一段时间内， 可能是几秒钟，对于某个工作资源，F8服务器收到其它管理服务器组播过来的优先级数值， 如果都小于其自身对于该工作资源的优先级设定值，管理服务器就会激活或保持该工作资 源为工作状态。需要进一步说明的是，主/备选举协商模块工作在操作系统的内核态，其实现代 码与操作系统的网络功能模块代码是一体的。这样做的目的是为了保证当管理服务器发生 部分软件故障时，其应用功能部分(例如回应ARP)和选举功能部分能够保持一致的状态， 既“能用都能用，不能用都不能用”。从而避免了出现管理服务器进入“选举优胜”却功能失 效的状态。如前文所述，在每一台管理服务器的上，BCIP所在的网络接口连接到SVCNET所在 的VLAN。而在这个网络接口上，除了 BCIP和该网口自身固件中的MAC地址外，还绑定有额 外的IP地址和MAC地址；这些额外的IP地址属于SVRNET，取名叫做Virtual Server IP，简 称VSIP ；而额外的MAC地址的取名叫做Virtual Server MAC，简称VSMAC。VSIP和VSMAC是 一一对应的关系，每一对都构成了一个工作资源。每一台管理服务器都拥有“自己的” VSIP 和VSMAC，同时也必须拥有其它管理服务器的全部VSIP和VSMAC。管理服务器之间仍然是 使用“主/备选举协商模决”来分载这些工作资源，上句话中的“自己的”的意思就是该资 源在默认配置中对应在“主/备选举协商模块”中的优先级与其它管理服务器比是最高的。每一台管理服务器都关注每一台应用服务器的工作状态，这个功能称作“健康检 查”。管理服务器通过设置健康检查模块来实现这一功能，管理服务器的健康检查模块可 以被配置为定期地将模拟用户的访问请求发送给每一台应用服务器，具体的访问请求用例 可由系统管理者自行定义。对于能够正常回应健康检查测试的应用服务器，健康检查模 块将应用服务器在当前配置中对应SVCIP汇总成一个列表，名字叫做Active SVCIP，简称 ASVCIP。对于有故障的应用服务器，健康检查模块也将应用服务器在当前配置中对应SVCIP 汇总成一个列表，名字叫做Bad SVCIP,简称BSVCIP。显然e ASVCIP U e BSVCIP = e SVCIP依照前文，“管理服务器上的ARP代理模块按照预先人工配置的对应关系，选取应用服务器的SVRIP所在的网络接口的MAC地址来回应交换机对SVCIP的ARP解析请求。”。但 是，当BSVCIP出现时，意味着该应用服务器发生故障不能提供服务，也意味着访问BSVCIP 用户即将遇到一个“无法连接服务器”的错误。为了避免用户遇到这种状况，管理服务器的 健康检查模块必须在第一时间处理这个问题，具体处理方法是按照一个预定的、尽可能均 衡的分配顺序，将BSVCIP依次对应到VSMAC，其效果趋向于每个VSMAC对应的BSVCIP数量 一样；之后，将这组新的对应关系信息发送给ARP代理模块；与此同时，将ASVCIP列表发送 给数据帧转发模块。ARP代理模块收到更新信息后，立即将其覆盖合并到默认的SVCIP-MAC 对应表中，并以ARP Advertising的形式广播全部的新SVCIP-MAC对应表，其目的是通知交 换机将访问目标地址为BSVCIP的网络流量转向到管理服务器本身。与此同时，管理服务器 的数据帧转发模块收到了新的ASVCIP列表，随即用它覆盖原有的可用应用服务器列表，按 照其自身的转发规则继续转发工作。至此，健康检查模块完成了一个完整工作周期，并循环 开始下一个工作周期。数据帧转发模块的工作内容是将所有的目标MAC是自己本机上拥有的(通常是 VSMAC)并且目标IP是SVCIP(通常是BSVCIP)的以太网帧，轮询转发给ASVCIP所对应的 MAC地址所在的服务器(应用服务器)。这句话比较难以理解，通俗的说就是“把本应由故 障应用服务器承担的网络服务请求转发给正常的应用服务器”。如前文所述，每个应用服务 器都被配置成了能够以任意一个SVCIP服务的状态，所以应用服务器不会“在意”网络访问 请求是来自用户还是来自管理服务器，也不会“在意”其目标IP是哪个SVCIP。而返回的 网络流量则是根据用户的来源IP走默认路由直接送给了交换机，并不经过管理服务器。这 样，数据帧转发模块只需要机械地转发，而不需要记录每一个网络连接的状态(如TCP的 状态)，也不需要处理返回的网络流量，所以管理服务器的性能开销很少。需要进一步说明 的是，数据帧转发模块一直处于工作状态，其要转发的来源网络流量是否存在完全是由ARP 代理模块控制的。这样一来，用户访问到BSVCIP的网络流量被均勻地转发到了 ASVCIP的服务器上， 对用户的服务得到了保证，而管理服务器自身也始终保持着最低的负载——只处理故障服 务器的进入方向的网络流量。如图7所示，下面再完整地解说一下各个工作状态的变迁。假设预定规则为预设四台管理服务器遇到若干个应用服务器故障时的工作接手顺序为D > C > B > A > D > C...方向循环，以达到尽可能的负载均衡；预设四台管理服务器遇到自身故障时，对于总体调度这项工作的交接顺序(选举 优先级)为A接D，B接A，C接B，D接C ；预设四台管理服务器遇到自身故障时，对于原先承担着的处理应用服务器故障的 工作，其交接顺序(选举优先级)为A接B，B接C，C接D，D接A。在上述预定规则中，尽可能做到处理服务器故障的工作要尽可能分配均勻，而自 身故障时，总体调度工作向后交接，处理应用服务器故障的工作则向前交接。下面完整地解 说一下各个工作状态的变迁。一、正常状态设初始状态为全部设备工作正常。本发明实施例的通信系统工作过程如下管理服务器A响应交换机的工作调度询问；
交换机把用户终端的网络流量直接转发给应用服务器；应用服务器把返回的网络流量经由交换机回传给用户；管理服务器B，C，D处于空闲状态。二、故障状态1设初始状态为应用服务器1发生故障。本发明实施例的通信系统工作过程如下四台管理服务器均监测到应用服务器1发生故障；根据预定规则管理服务器A负责整体工作调度；管理服务器A在网络上广播相应的以太网地址变更信息，按照预定规则，交换机 随即将用户对故障应用服务器1的访问请求转发到管理服务器D ；交换机把用户访问到正常应用服务器的来源网络流量直接转发给正常工作的应 用服务器；管理服务器D将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器；正常工作的应用服务器把返回的网络流量经由交换机回传给用户；管理服务器B，C处于空闲状态。三、故障状态2设初始状态为应用服务器1发生故障；管理服务器A发生故障。本发明实施例的 通信系统工作过程如下管理服务器B，C，D均监测到应用服务器1发生故障；根据预定规则管理服务器B取代管理服务器A接手整体工作调度；根据预定规则管理服务器D接手管理服务器A上的处理故障应用服务器的工作， 该工作包括原来存在的以及今后可能被分配过来的工作；管理服务器D在网络上广播相应 的以太网地址变更信息，交换机随即将用户访问故障应用服务器的网络流量转发给管理服 务器D;交换机仍旧将用户访问故障应用服务器1的网络流量转发到管理服务器D ；交换机把用户访问正常应用服务器的流量直接转发给正常工作的应用服务器；管理服务器D将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器正常工作的应用服务器把返回的网络流量经由交换机回传给用户；管理服务器C处于空闲状态；四、故障状态3设初始状态为应用服务器1，2发生故障；管理服务器A发生故障。本发明实施例 的通信系统工作过程如下管理服务器B，C，D均监测到应用服务器1，2发生故障；根据预定规则管理服务器B继续负责整体工作调度；根据预定规则管理服务器D接手管理服务器A来处理故障应用服务器的工作，虽 然目前没有工作负载；交换机将用户访问故障应用服务器1的网络流量转发到管理服务器D ；管理服务器B在网络上广播相应的以太网地址变更信息，交换机随即将用户访问故障应用服务器2的网络流量转发到空闲的管理服务器C ；交换机把用户访问到正常应用服务器的来源网络流量直接转发给正常工作的应 用服务器；管理服务器D将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器；管理服务器C将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器；正常工作的应用服务器把返回的网络流量经由交换机回传给用户；非故障的管理服务器全部处于有工作负载状态，但是管理服务器B的负载很轻。五、故障状态4:设初始状态为应用服务器1，2，3发生故障；管理服务器A发生故障。本发明实施 例的通信系统工作过程如下管理服务器B，C，D均监测到应用服务器1，2，3发生故障；根据预定规则管理服务器B继续负责整体工作调度；根据预定规则管理服务器D接手管理服务器A来处理故障应用服务器的工作，虽 然目前没有工作负载；交换机将用户访问故障应用服务器1的网络流量转发到管理服务器D ；交换机将用户访问故障应用服务器2的网络流量转发到管理服务器C ；管理服务器B在网络上广播相应的以太网地址变更信息，交换机随即将用户访问 故障应用服务器3的网络流量转发给相对负载很低的管理服务器B上；交换机把用户访问到正常应用服务器的流量直接转发给正常工作的应用服务 器；管理服务器D将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器；管理服务器C将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器；管理服务器B的另外一项工作是将交换机转来的用户的网络访问流量再次经由 交换机转发给其它的正常工作的应用服务器；正常工作的应用服务器把返回的网络流量经由交换机回传给用户；非故障的管理服务器全部处于有工作负载状态；六、故障状态5设初始状态为应用服务器1，2，3，4发生故障；管理服务器A发生故障。本发明实 施例的通信系统工作过程如下管理服务器B，C，D均监测到应用服务器1，2，3，4发生故障；根据预定规则管理服务器B继续负责整体工作调度；根据预定规则交换机将用户访问故障应用服务器1的网络流量转发到管理服务 器D;交换机将用户访问故障应用服务器2的网络流量转发到管理服务器C ；交换机将用户访问故障应用服务器3的网络流量转发到管理服务器B ；
13
管理服务器B在网络上广播相应的以太网地址变更信息，交换机随即将用户访问 故障应用服务器4的网络流量转发向管理服务器A ；但是由于管理服务器A处于故障状态， 并且其处理应用服务器故障这部分工作早已被管理服务器D接手，所以最终交换机将用户 访问故障应用服务器4的网络流量转发给管理服务器D ；交换机把用户访问到正常应用服务器的流量直接转发给正常工作的应用服务 器；管理服务器D将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器管理服务器C将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器管理服务器B的另外一项工作是将交换机转来的用户的网络访问流量再次经由 交换机转发给其它的正常工作的应用服务器正常工作的应用服务器把返回的网络流量经由交换机回传给用户；非故障的管理服务器全部处于有工作负载状态，其中管理服务器D的负载相对较 尚；七、故障状态6设初始状态为某四台应用服务器1，2，3，4发生故障；管理服务器A，B发生故障。 本发明实施例的通信系统工作过程如下管理服务器C，D均监测到应用服务器1，2，3，4发生故障；根据预定规则管理服务器C取代管理服务器B接手总体工作调度；根据预定规则管理服务器D接手管理服务器B上的处理故障应用服务器的工作， 包括原来存在的以及今后可能被分配过来的工作；根据预定规则交换机将用户访问故障应用服务器1、4的网络流量转发到管理服 务器D;交换机将用户访问故障应用服务器2的网络流量转发到管理服务器C ；管理服务器D在网络上广播相应的以太网地址变更信息，交换机随即将用户访问 故障应用服务器3的网络流量由原先的转发给管理服务器B改为转发给管理服务器D ；交换机把用户访问到正常应用服务器的来源网络流量直接转发给正常工作的应 用服务器；管理服务器D将交换机转来的用户的网络访问流量再次经由交换机转发给其它 的正常工作的应用服务器；管理服务器C的另外一项工作是将交换机转来的用户的网络访问流量再次经由 交换机转发给其它的正常工作的应用服务器；正常工作的应用服务器把返回的网络流量经由交换机回传给用户；非故障的管理服务器全部处于有工作负载状态，管理服务器D的负载相对较高；以上是各个故障状态的工作调度的举例描述。需要指出的是，故障发生的情况是 随机出现的，并不一定是按照上文中的“故障状态1、2、3、4、5、6”的顺序发生。对于其它情 况的故障发生顺序，整个管理系统仍然按照预设的规则调度工作。对于故障恢复后的设备， 管理系统通过健康检查机制和工作资源选举机制确认其能够正常工作后，会将原先属于该设备的工作负载“返还”，最终在所有故障设备都恢复正常工作后，使得整体系统也还原到 了初始工作状态。实施例二如图8所示，本实施例提供了一种通信方法，包括步骤步骤801、交换机接收用户请求，并在管理服务器的控制下将用户请求转发至目的 地址对应的应用服务器或管理服务器。步骤802、管理服务器监控应用服务器的状态，并根据应用服务器的状态和预定规 则控制交换机的数据转发，以便在应用服务器故障时，使交换机将发往该故障应用服务器 的用户请求转发给管理服务器。步骤803、应用服务器接收交换机和/或管理服务器转发的用户请求，并处理该请 求，将处理结果发给交换机，并由交换机将应用服务器的处理结果转发给用户。由于管理服务器自身的主/备选举协商模块的功效，无论是健康检查、网络转发 还是ARP代理，这些工作都会随着对工作资源的选举协商在多台管理服务器上动态迁移， 直至最后一台管理服务器发生故障，任何工作都不会收到影响。而且，当管理服务器由故障 状态恢复时，主/备选举协商模块即可自动重新分配工作资源，以达成管理服务器之间的 负载均衡。本发明的通信系统实现了服务器的负载均衡、服务器故障屏蔽、自身故障屏蔽、用 户透明模式访问、故障恢复自愈合五项功能；由于在本发明的通信系统中，在正常通信过程 中，管理服务器不参与用户终端与应用服务器之间通信过程，只有在应用服务器故障时才 参与通信系统的管理工作，这种工作方式称作“带外监控、故障介入”工作模式，因此，本发 明的通信系统自身的负载，与用户的数量、访问量无关，与应用服务器的数量无关，只与服 务器的故障率和故障恢复时间有关；这样就彻底解决了交换性能的提升与日益增长的网络 流量之间的矛盾，开辟了 一个新型的应用模式。由于本发明的通信系统采用了“带外监控、故障介入”的工作方式，管理服务器无 须处理用户和正常应用服务器之间的网络通信数据，对于故障时的应用服务器，管理服务 器也只需要处理用户发送过来的网络通信数据。所以对管理服务器自身的硬件性能要求很 低，管理服务器可以使用与应用服务器同档次的硬件，其自身的硬件成本远远低于“带内工 作”形式的交换系统的硬件成本。由于本发明的通信系统采用“带外监控、故障介入”的工作方式，用户和正常应用 服务器之间的网络通信数据只需被交换机处理一次。相对于“商业四层交换方案之inline 模式”节省了 50%的交换机的网络资源；相对于“商业四层交换方案之单臂模式”节省了 25%的交换机的网络资源。由于本发明的通信系统采用“带外监控、故障介入”的工作方式，所以管理服务器 自身的性能无须随用户或应用服务器的增加而增加，对管理服务器的性能需求只与应用服 务器的故障量和故障恢复时间相关。这使得本发明的交换服务在性能上从应用服务中剥离 开来。所以，理论上，本发明通信系统可以承载任意大小的网络流量而不增加四层交换部分 的硬件成本投入。虽然通过实施例描绘了本发明，但本领域普通技术人员知道，在不脱离本发明的 精神和实质的情况下，就可使本发明有许多变形和变化，本发明的范围由所附的权利要求来限定。
权利要求
1.一种通信系统，其特征在于，包括交换机、应用服务器和管理服务器，所述应用服务器，用于接收交换机和/或管理服务器转发的用户请求，并处理该请求， 将处理结果发给交换机；所述交换机，用于将应用服务器的处理结果转发给用户，并在管理服务器的控制下将 用户请求转发至目的地址对应的应用服务器或管理服务器；所述管理服务器，用于监控应用服务器的状态，并根据应用服务器的状态和预定规则 控制交换机的数据转发，以便在应用服务器故障时，使交换机将发往该故障应用服务器的 用户请求转发给管理服务器。
2.根据权利要求1所述的系统，其特征在于，所述管理服务器为2至254台。
3.根据权利要求2所述的系统，其特征在于，所述管理服务器为4台。
4.根据权利要求2或3所述的系统，其特征在于，所述管理服务器包括主/备关系协商 选举模块，其用于向其它管理服务器组播本管理服务器的工作资源的优先级，并获得其它 管理服务器的工作资源的优先级，根据各个管理服务器的优先级确定本管理服务器工作资 源的工作状态。
5.根据权利要求4所述的系统，其特征在于，所述主/备选举协商模块工作在操作系统 的内核态。
6.根据权利要求1至3其中任一项所述的系统，其特征在于，所述管理服务器具体包括数据帧转发模块，用于接收交换机转发的用户请求，并根据转发表对所述用户请求执 行数据帧转发操作，以便将本应由故障应用服务器承担的用户请求转发给正常的应用服务ο
7.根据权利要求1至3其中任一项所述的系统，其特征在于，所述管理服务器具体包括地址解析协议代理模块用于接收网络设备的ARP查询，该ARP查询用于获得与SVCIP 对应的MAC地址，并将该MAC地址返回该网络设备。
8.根据权利要求7所述的系统，其特征在于，所述网络设备包括交换机。
9.根据权利要求1至3其中任一项所述的系统，其特征在于，所述管理服务器具体包括健康检查模块，用于检查应用服务器的状态，以发现故障应用服务器及正常工作的应 用服务器，将故障应用服务器的IP用管理服务器的VSIP替换。
10.一种通信方法，其特征在于，包括步骤交换机接收用户请求，并在管理服务器的控制下将用户请求转发至目的地址对应的应 用服务器或管理服务器；管理服务器监控应用服务器的状态，并根据应用服务器的状态和预定规则控制交换机 的数据转发，以便在应用服务器故障时，使交换机将发往该故障应用服务器的用户请求转 发给管理服务器；应用服务器接收交换机和/或管理服务器转发的用户请求，并处理该请求，将处理结 果发给交换机，并由交换机将应用服务器的处理结果转发给用户。
全文摘要
本发明的实施例提供了一种通信方法和装置，可解决现有通信系统通信效率低、成本高的问题。所述通信系统包括交换机、应用服务器和管理服务器。所述应用服务器，用于接收交换机和/或管理服务器转发的用户请求，并处理该请求，将处理结果发给交换机；所述交换机，用于交换数据；所述管理服务器，用于监控应用服务器的状态，并根据应用服务器的状态和预定规则控制交换机的数据转发，以便在应用服务器故障时，使交换机将发往该故障应用服务器的用户请求转发给管理服务器。根据本发明，可实现服务器的负载均衡、服务器故障屏蔽、自身故障屏蔽、用户透明模式访问、故障恢复自愈合五项功能；并彻底解决了交换性能的提升与日益增长的网络流量之间的矛盾。
文档编号H04L29/12GK102130776SQ201010002599
公开日2011年7月20日 申请日期2010年1月19日 优先权日2010年1月19日
发明者王乃超 申请人:新浪网技术(中国)有限公司