一种支持负载均衡的自组织集群服务器实现方法和装置

摘要

本发明提出的自组织集群服务器采用分布式架构，由多个物理服务器组成一个虚拟服务器，用于运行单一服务器难以承载的大型业务。该集群服务器通过自组织方式，自动发现邻居节点的加入和离开，动态选举管理接入点和业务接入点，由管理接入点向网管系统提供统一的系统管理接口，由业务接入点向用户提供统一的业务访问接口，并把业务均匀分配到每个活跃的物理节点上，从而实现集群服务器内部的负载均衡和冗余备份，解决传统集群服务器需要部署专用负载均衡设备和心跳软件等问题，减少系统的设备投资，提升系统的可靠性和可扩展性，降低系统部署和维护的复杂性。

说明书

技术领域

本发明涉及一种运行大型互联网应用程序的服务器装置，尤其是同时运行多个互联网应用，自动实现负载均衡和节点管理的集群服务器。

背景技术

集群服务器主要用于运行大型互联网应用，如大型网站、邮件系统、视频服务等。这些应用计算量很大，单台物理服务器难以承担，需要采用集群服务器。目前，集群服务器由两台互为备份的负载均衡设备和多台物理服务器组成。用户业务请求全部发给负载均衡设备，再由负载均衡设备分派给物理服务器处理。这种架构不适合超大型的集群服务器，因为负载均衡设备将成为集群服务器的瓶颈，制约了集群服务器规模的扩展，同时也不适合小型集群服务器，因为负载均衡设备不参与业务处理，备用的负载均衡设备更是处于空闲状态，对一个只有2-3台物理服务器的集群服务器来说，负载均衡设备投资偏大。

两台互为备份的负载均衡设备上需要运行心跳软件，备用负载均衡设备实时检测主设备的运行状态，一旦发现主设备故障，马上启动本地进程，接管业务调度职能。还有，负载均衡设备也需要运行物理服务器检测程序，一旦发现故障，马上停止向故障服务器分派业务。可见，一般的集群服务器需要多套工具软件配合，实施部署难度较大。

负载均衡设备不能自动发现物理服务器，需要事前把所有物理服务器参数配置到负载均衡设备上。如果业务运行中需要增加物理服务器，必须修改和测试负载均衡设备的相应配置，难以实现在线快速业务扩容，运行维护复杂度较高。

发明内容

为了克服现有集群服务器需要集成负载均衡设备，心跳软件和节点检测程序而导致的投资大，扩展性差，实施和维护困难等不足，本发明提供一种自组织集群服务器，自组织集群服务器不仅仅能自动发现节点的加入和离开，不需要其它心跳软件和节点检测程序的配合，而且能实现内部的负载均衡和冗余备份，不需要专用负载均衡设备配合。

本发明解决其技术问题所采用的技术方案是：自组织集群服务器自动发现邻居节点的加入、离开和状态变化，动态选举管理接入点和业务接入点，由管理接入点向网管系统提供统一的系统管理接口，由业务接入点向用户提供统一的业务访问接口，并把业务均匀分配到每个节点上，从而实现集群服务器内部的负载均衡和冗余备份，解决现有集群服务器需要部署专用负载均衡设备和心跳软件的问题，简化系统的安装和维护。

如图1所示，自组织集群服务器以节点形式管理物理服务器，并分为管理节点、业务节点、从动节点等不同角色。管理节点是负责自组织集群服务器系统管理的节点。管理节点上用于收发网管信息的网络端口叫管理接入点，用于收发网管信息的IP地址叫集群IP，同时也对应自组织集群服务器域名IP地址。自组织集群服务器只有一个管理节点和一个管理接入点。业务节点是负责接收业务请求的节点。业务节点上用于接收业务请求的网络端口叫业务接入点，用于接收业务请求的IP地址叫业务IP，同时也对应业务域名IP地址。自组织集群服务器有一个或多个业务节点，业务节点有一个或多个业务接入点。从动节点是协助业务节点处理业务请求的节点。如果没有选举为管理节点或业务节点的节点自动成为从动节点。

如图2所示，自组织集群服务器通过主动发送和监听节点状态报文来发现邻居节点的加入、离开以及节点状态的变化。节点通过组播方式定期发送本地节点的状态信息，包括节点名字、业务负载情况和有效网络链路参数等，以此向其它节点宣告本地节点的存在。同时节点监听其它节点发出的状态报文，从而发现邻居节点的存在，并掌握邻居节点的加入、离开、业务负载变化、链路状态变化的动态信息。为减少邻居节点发现程序的性能开销，自组织集群服务器不采用握手方式建立邻居关系，而通过连续监听方式确保所有节点状态信息的同步。

如图3所示，自组织集群服务器根据一定的管理接入点选举算法确定本地节点是否管理节点，如果是则通过组播方式主动向其它节点宣告本地节点是管理节点，以及管理接入点对应哪条网络链路，如果管理节点不是本地节点，则不作任何处理。当有新节点加入或故障节点离开时，每个节点所掌握的邻居状态不完全同步，计算出来的管理节点可能不一样，导致多个节点争相成为管理节点。为避免冲突，同时选择最优管理节点，每个节点采用退让方式，即使节点认为本地节点是管理节点，但监听到其它节点主动申请成为管理节点时，均主动放弃管理节点角色。

如图4所示，在本地节点和所有邻居节点之间选举带宽最小的节点作为管理节点，并在管理节点中选举带宽最小的链路作为管理接入点。该选举算法主要避免系统管理开销占用高性能节点的资源。管理接入点的具体选举算法如下所述：

第一步，在所有节点中选择有效总带宽最小的节点，如果只有一个符合条件的节点则直接跳到第三步；

第二步，在选出节点中进一步选择网络链路IP最小的节点，如果节点存在多个有效链路IP，则以最小链路IP比较；

第三步，以选中节点作为管理节点；

第四步，在管理节点中选择带宽最小的有效链路，如果只有一条符合条件的链路则直接跳到第六步；

第五步，在选出链路中进一步选择IP最小的链路，如果链路存在多个有效链路IP，则以最小IP比较；

第六步，以选中链路作为管理接入点。

如图5所示，自组织集群服务器可以同时运行多个业务，每个业务绑定一个业务接入点。节点根据一定的业务接入点选举算法为每个业务选举对应的业务接入点，并确定本地节点是否业务节点，如果是则通过组播方式主动向其它节点宣告本地节点拥有哪几个业务的业务接入点，以及业务接入点对应哪条链路，如果本地节点没有业务接入点，则不作任何处理。当有新节点加入或故障节点离开时，每个节点所掌握的邻居状态不完全同步，计算出来的业务接入点可能不一样，导致多个节点争相成为同一个业务的业务节点。为避免冲突，同时选择最优业务节点，每个节点采用退让方式，即使节点认为本地节点是某个业务的业务节点，但监听到其它节点主动申请成为该业务的业务节点时，均主动放弃该业务的业务节点角色。

如图6所示，在本地节点和所有邻居节点（包括已经成为管理节点的节点）之间为每一个业务选举负载最轻、带宽最大的节点作为业务节点，并在业务节点中选举负载最轻、带宽最大的链路作为业务接入点。该选举算法主要让业务均匀分布在所有节点中，并充分发挥高性能节点的作用。业务接入点的具体选举算法如下所述：

第一步，在所有节点中选择已有业务接入点最少的节点，如果只有一个符合条件的节点则直接跳到第四步；

第二步，在选中节点中进一步选择有效总带宽最大的节点，如果只有一个符合条件的节点则直接跳到第四步；

第三步，在选出节点中进一步选择网络链路IP最大的节点，如果节点存在多个有效链路IP，则以最大链路IP比较；

第四步，以选中节点作为业务节点；

第五步，在业务节点中选择绑定业务接入点最少的可用链路，如果只有一条符合条件的链路则直接跳到第八步；

第六步，在选出链路中进一步选择带宽最大的链路，如果只有一条符合条件的链路则直接跳到第八步；

第七步，在选出链路中进一步选择IP最大的链路，如果链路存在多个有效链路IP，则以最大IP比较；

第八步，以选中链路作为业务接入点。

如图7所示，自组织集群服务器可以在各节点之间实现负载分担。负载分担算法采用无状态散列算法，既确保同一用户的业务请求分配到同一节点处理，又减少查找状态表的开销，提高整个自组织集群服务器的性能。某个业务的所有业务请求均由与该业务绑定的业务接入点接收。当业务节点通过业务接入点收到业务请求的报文，首先根据报文的目的IP地址和源IP地址进行散列计算，并映射到活跃节点列表上。如果映射结果是本地节点，那么业务请求直接转交给本地业务层处理，处理结果直接返回给用户。如果映射结果是其它节点，那么首先解析选中节点的MAC地址，再以此MAC地址为链路层报文的目标地址，通过二层链路把业务请求报文转发给选中的节点。非业务节点收到业务请求报文，直接转交给本地业务层处理，处理结果直接返回给用户。业务节点和从动节点返回的业务响应报文均以业务IP为报文的源IP地址。

如图8所示，管理节点和业务节点具备冗余备份能力，任何一个管理/业务节点出现故障，其它节点马上重新选举新的管理/业务节点，代替故障节点，从而提高整个自组织集群服务器的可靠性。每个节点不断监听邻居节点的状态报文，如果在一定时间内没收到管理/业务节点的状态报文，则认为管理/业务节点出现故障或离开，然后在活跃节点中重新选举管理/业务节点。选中节点在本地有效链路中选举管理/业务接入点，通过状态报文向其它节点宣告成为新管理/业务节点，并广播管理/业务接入点的ARP响应报文，迫使发往故障节点的业务请求快速切换到新管理/业务节点。如果管理/业务节点没有完全脱网，只是管理/业务接入点绑定的链路中断，那么不重新选举管理/业务节点，只在管理/业务节点上的有效链路中重新选举管理/业务接入点，并广播新管理/业务接入点的ARP响应报文，迫使发往原管理/业务接入点的业务请求快速切换到新管理/业务接入点。

如图9所示，从动节点同样具备冗余备份能力，每个节点不断监听邻居节点的状态报文，如果在一定时间内没收到从动节点的状态报文，则认为从动节点出现故障或离开，业务节点将停止向故障节点转发业务请求，相应业务请求由其它活跃节点分担。

附图说明

下面结合附图和实施例对本发明进一步说明。

图1自组织集群服务器节点角色。

图2邻居节点发现和状态同步方法。

图3节点根据选举算法主动宣告本地节点为管理节点。

图4管理接入点选举算法。

图5节点根据选举算法主动宣告本地节点为业务节点。

图6业务接入点选举算法。

图7负载分担工作原理。

图8管理/业务节点冗余备份工作原理。

图9从动节点冗余备份工作原理。

图10节点软件系统架构。

图11状态通报工作流程。

图12监听工作流程。

图13节点超时工作流程。

图14管理接入点选举工作流程。

图15业务接入点选举工作流程。

图16业务调度工作流程。

图17链路中断工作流程。

图18ARP报文处理工作流程。

图19初始化工作流程。

具体实施方式

下面参照附图对本发明的内容进行更全面的描述。请注意，以下描述在本质上仅是解释性和示例性，不作为对本发明及其应用或使用的任何限制。除非另外特别说明，否则，在实施例中阐述的部件和步骤的相对布置以及数字表达式和数值并不限制本发明的范围。另外，本领域技术人员已知的技术、方法和装置可能不被详细讨论，但在适当的情况下也成为说明书的一部分。

如图10所示，自组织集群服务器每个节点的软件结构是一样的，其主要目的是实现完全对等模式，任何节点出现故障，只要还有活跃节点存在，系统的所有功能仍然有效，即系统的任何角色都有1:N的冗余备份。节点的主要软件模块包括网络层的邻居发现、管理接入点选举、业务接入点选举、业务调度模块，链路层的链路监测、ARP处理模块，系统管理的初始化模块。

邻居发现模块又细分为状态通报、监听、节点超时等3个子模块。如图11所示，节点设置时钟中断，定期检查链路状态，通报本地有效链路、管理接入点、业务接入点信息。具体的状态通报工作流程如下所述：

第一步，读取本地链路状态，如果没有新增有效链路，直接跳到第四步；

第二步，如果本地节点是管理节点，那么在本地有效链路范围内重新选举管理接入点，确保管理接入点为最优选择；

第三步，如果本地节点是业务节点，那么在本地有效链路范围内为原本地业务接入点重新选举，确保业务接入点为最优选择；

第四步，构造节点状态报文，封装本地有效链路、管理接入点、业务接入点等信息；

第五步，通过组播方式发送节点状态报文，通报本地节点有效链路信息，以及本地节点是否为管理节点和业务节点。

如图12所示，节点不断监听邻居节点的状态报文，发现新节点的加入、老节点链路的变化，以及管理节点和业务节点的分配等情况。具体节点状态监听工作流程如下所述：

第一步，监听邻居节点状态报文，读取报文中的节点名字、有效链路、管理/业务接入点等信息，如果邻居节点为已有节点，那么直接跳到第三步；

第二步，为新节点增加邻居节点记录，保存新节点有效链路状态，如果新节点与本地节点竞争管理节点则直接跳到第四步，如果新节点与本地节点竞争业务接入点则直接跳到第五步，否则结束监听；

第三步，为原有节点更新有效链路信息，删除没有出现在状态报文中的老链路记录，为新增链路创建新链路记录，并重置节点超时的计数器，如果邻居节点与本地节点竞争管理节点则进入第四步，如果新节点与本地节点竞争业务接入点则直接跳到第五步，否则结束监听；

第四步，本地节点放弃成为管理节点，解除原管理接入点的绑定关系，并通知ARP模块停止响应管理接入点的ARP请求，如果邻居节点不与本地节点竞争业务接入点则结束监听；

第五步，本地节点放弃出现竞争情况的业务接入点，解除原业务接入点的绑定关系，并通知ARP模块停止响应原业务接入点的ARP请求。

如图13所示，经过一定时间没有收到邻居节点的状态报文，则认为该邻居节点超时。当邻居节点超时时，本地节点将删除超时节点的记录，并重新选举管理/业务接入点。具体节点超时工作流程如下所述：

第一步，删除超时节点的记录，包括其链路信息以及与之绑定的管理接入点和业务接入点记录；

第二步，在活跃节点中重新选举管理接入点，确保管理接入点有效而且是最佳选择；

第三步，在活跃节点中重新选举所有的业务接入点，确保所有业务接入点有效而且是最佳选择，如果本地节点不是管理或业务节点，那么结束节点超时工作；

第四步，通过组播方式向所有节点通报本地管理/业务接入点信息，并通知ARP模块响应相应管理/业务接入点的ARP请求。

如图14所示，每个节点自行选举带宽和IP最小的节点作为管理节点，在管理节点中选择带宽和IP最小的链路作为管理接入点。管理接入点的具体选举工作流程如下所述：

第一步，按总带宽和IP从小到大排序所有活跃节点（包括本地节点和邻居节点）；

第二步，以排在第一位的节点作为管理节点；

第三步，按带宽和IP从小到大排序管理节点内部所有有效链路；

第四步，以排在第一位的链路作为管理接入点。

如图15所示，每个节点自行选举带宽和IP最大的节点作为业务节点，在业务节点中选择带宽和IP最大的链路作为业务接入点，并确保业务接入点在所有节点和链路中均匀分布。业务接入点的具体选举工作流程如下所述：

第一步，按总带宽和IP从大到小排序所有活跃节点，节点序号为0～(n-1)；

第二步，按从大到小排序所有业务IP，业务IP序号i从0开始；

第三步，以第(imodn)个节点作为第i个业务IP对应的业务节点；

第四步，按带宽和IP从大到小分别排序每个业务节点的所有有效链路，每个业务节点上的链路序号分别是0～(m-1)；

第五步，按从大到小排序每个业务节点所对应的业务IP，每个业务节点上的业务IP序号j从0开始；

第四步，以第(jmodm)条链路作为该业务节点第j个业务IP绑定的业务接入点。

如图16所示，节点收到业务请求报文时将根据自己的角色决定如何调度业务，确保业务请求在自组织集群服务器内部得到均匀分布。具体业务调度工作流程如下所述：

第一步，收到业务请求报文时首先查找对应的业务接入点，如果对应的业务接入点不在本地节点则直接跳到第三步；

第二步，把所有活跃节点的有效链路构成一个连续的一维空间，每条链路在一维空间中的长度与链路带宽成正比，再通过一定的Hash算法把业务请求报文的源+目的IP映射到链路空间上，如果映射到的链路不在本地节点则直接跳到第四步；

第三步，把业务请求报文转交本地应用层处理并返回用户后结束；

第四步，查询映射链路的MAC地址，并通过二层网络把业务请求报文转发给映射链路所在节点，然后结束。

节点链路状态变化包括链路启动和链路中断两种。为抑制链路状态频繁翻转，节点实时处理链路中断，忽略链路启动，由节点状态通报子模块完成新链路的检查。如图17所示，当链路发生中断情况时，节点需要快速切换故障链路上的管理/业务接入点，并通告其它节点。具体链路中断工作流程如下所述：

第一步，删除故障链路的记录，如果节点完全脱网，则直接跳到第四步，如果故障链路不是管理/业务接入点，则直接跳到第三步；

第二步，在本地有效链路中重新选举管理/业务接入点，并通知ARP模块广播新管理/业务接入点的ARP响应报文和响应新管理/业务接入点的ARP请求；

第三步，通过节点状态报文通报本地有效链路、管理/业务接入点的信息，让其它节点马上停止向故障链路继续发送业务请求，然后结束；

第四步，删除所有邻居节点记录和管理/业务接入点记录，迫使节点进入初始化状态，等待节点重新联网。

如图18所示，节点需要响应关于本地管理/业务接入点的ARP请求。ARP报文处理具体工作流程如下所述：

第一步，读取ARP报文的请求内容，如果非本地管理/业务接入点，则转操作系统处理并结束；

第二步，读取相应管理/业务接入点绑定的链路的MAC地址，并通过ARP响应报文广播。

节点上电或从脱网状态重新联网都会启动初始化进程。如图19所示，节点需要初始化各个软件模块，并发现邻居和选举管理/业务接入点。具体初始化工作流程如下所述：

第一步，启动链路监测和ARP处理模块，确保本地有效链路信息准确；

第二步，启动业务调度和邻居发现模块，确保不丢弃邻居节点转发过来的业务请求；

第三步，在本地节点联网后继续等待一段时间，让本地节点和邻居节点通过定期发送节点状态报文充分同步邻居状态信息；

第四步，启动管理/业务接入点选举模块，选举管理/业务接入点；

第五步，通过组播通报本地有效链路、管理/业务接入点信息。

本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。