CN105635199B - 一种支持负载均衡的自组织集群服务器 - Google Patents

一种支持负载均衡的自组织集群服务器 Download PDF

Info

Publication number
CN105635199B
CN105635199B CN201410586235.3A CN201410586235A CN105635199B CN 105635199 B CN105635199 B CN 105635199B CN 201410586235 A CN201410586235 A CN 201410586235A CN 105635199 B CN105635199 B CN 105635199B
Authority
CN
China
Prior art keywords
node
access point
management
service
business
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
CN201410586235.3A
Other languages
English (en)
Other versions
CN105635199A (zh
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.)
Rui Zhe Polytron Technologies Inc
Original Assignee
Rui Zhe Polytron Technologies Inc
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 Rui Zhe Polytron Technologies Inc filed Critical Rui Zhe Polytron Technologies Inc
Priority to CN201410586235.3A priority Critical patent/CN105635199B/zh
Publication of CN105635199A publication Critical patent/CN105635199A/zh
Application granted granted Critical
Publication of CN105635199B publication Critical patent/CN105635199B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

一种支持负载均衡的自组织集群服务器
技术领域
本发明涉及一种运行大型互联网应用程序的服务器装置,尤其是同时运行多个互联网应用,自动实现负载均衡和节点管理的集群服务器。
背景技术
集群服务器主要用于运行大型互联网应用,如大型网站、邮件***、视频服务等。这些应用计算量很大,单台物理服务器难以承担,需要采用集群服务器。目前,集群服务器由两台互为备份的负载均衡设备和多台物理服务器组成。用户业务请求全部发给负载均衡设备,再由负载均衡设备分派给物理服务器处理。这种架构不适合超大型的集群服务器,因为负载均衡设备将成为集群服务器的瓶颈,制约了集群服务器规模的扩展,同时也不适合小型集群服务器,因为负载均衡设备不参与业务处理,备用的负载均衡设备更是处于空闲状态,对一个只有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 链路中断工作流程。
图18 ARP报文处理工作流程。
图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开始;
第三步,以第(i mod n)个节点作为第i个业务IP对应的业务节点;
第四步,按带宽和IP从大到小分别排序每个业务节点的所有有效链路,每个业务节点上的链路序号分别是0~(m-1);
第五步,按从大到小排序每个业务节点所对应的业务IP,每个业务节点上的业务IP序号j从0开始;
第四步,以第(j mod m)条链路作为该业务节点第j个业务IP绑定的业务接入点。
如图16所示,节点收到业务请求报文时将根据自己的角色决定如何调度业务,确保业务请求在自组织集群服务器内部得到均匀分布。具体业务调度工作流程如下所述:
第一步,收到业务请求报文时首先查找对应的业务接入点,如果对应的业务接入点不在本地节点则直接跳到第三步;
第二步,把所有活跃节点的有效链路构成一个连续的一维空间,每条链路在一维空间中的长度与链路带宽成正比,再通过一定的Hash算法把业务请求报文的源+目的IP映射到链路空间上,如果映射到的链路不在本地节点则直接跳到第四步;
第三步,把业务请求报文转交本地应用层处理并返回用户后结束;
第四步,查询映射链路的MAC地址,并通过二层网络把业务请求报文转发给映射链路所在节点,然后结束。
节点链路状态变化包括链路启动和链路中断两种。为抑制链路状态频繁翻转,节点实时处理链路中断,忽略链路启动,由节点状态通报子模块完成新链路的检查。如图17所示,当链路发生中断情况时,节点需要快速切换故障链路上的管理/业务接入点,并通告其它节点。具体链路中断工作流程如下所述:
第一步,删除故障链路的记录,如果节点完全脱网,则直接跳到第四步,如果故障链路不是管理/业务接入点,则直接跳到第三步;
第二步,在本地有效链路中重新选举管理/业务接入点,并通知ARP模块广播新管理/业务接入点的ARP响应报文和响应新管理/业务接入点的ARP请求;
第三步,通过节点状态报文通报本地有效链路、管理/业务接入点的信息,让其它节点马上停止向故障链路继续发送业务请求,然后结束;
第四步,删除所有邻居节点记录和管理/业务接入点记录,迫使节点进入初始化状态,等待节点重新联网。
如图18所示,节点需要响应关于本地管理/业务接入点的ARP请求。ARP报文处理具体工作流程如下所述:
第一步,读取ARP报文的请求内容,如果非本地管理/业务接入点,则转操作***处理并结束;
第二步,读取相应管理/业务接入点绑定的链路的MAC地址,并通过ARP响应报文广播。
节点上电或从脱网状态重新联网都会启动初始化进程。如图19所示,节点需要初始化各个软件模块,并发现邻居和选举管理/业务接入点。具体初始化工作流程如下所述:
第一步,启动链路监测和ARP处理模块,确保本地有效链路信息准确;
第二步,启动业务调度和邻居发现模块,确保不丢弃邻居节点转发过来的业务请求;
第三步,在本地节点联网后继续等待一段时间,让本地节点和邻居节点通过定期发送节点状态报文充分同步邻居状态信息;
第四步,启动管理/业务接入点选举模块,选举管理/业务接入点;
第五步,通过组播通报本地有效链路、管理/业务接入点信息。
本发明的描述是为了示例和描述起见而给出的,而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用,并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。

Claims (5)

1.一种支持负载均衡的自组织集群服务器,由多台物理服务器组成一台自组织集群服务器,其特征是:所述自组织集群服务器以节点形式管理所述物理服务器,各节点自动发现邻居节点的加入和离开,动态选举管理接入点和业务接入点,由管理接入点向网管***提供统一的***管理接口,由业务接入点向用户提供统一的业务访问接口,并把业务均匀分配到每个活跃的物理节点上,无需专用负载均衡设备和心跳软件配合,实现集群内部的负载均衡和冗余备份;
节点通过组播方式定期发送本地节点的状态信息,同时监听其它节点发出的状态报文,掌握邻居节点加入、离开的动态信息,并通过连续监听方式确保所有节点状态信息的同步。
2.根据权利要求1所述的支持负载均衡的自组织集群服务器,其特征是:以节点形式管理物理服务器,并分为管理节点、业务节点、从动节点;从管理节点上的管理接入点接收***管理请求,由管理节点负责管理***运行,从业务节点上的业务接入点接收业务请求,由业务节点负责业务调度和业务处理,由从动节点分担业务节点的业务负载;只有一个管理节点和一个管理接入点,有一个或多个业务节点,业务节点有一个或多个业务接入点。
3.根据权利要求1所述的支持负载均衡的自组织集群服务器,其特征是:所有节点根据相同的管理接入点选举算法和业务接入点选举算法自行确定本地节点是否管理节点和业务节点,哪条链路是管理接入点和业务接入点;节点主动向其它节点宣告本地管理接入点和业务接入点信息;节点加入时,仅加入节点重新选举和宣告管理和业务接入点,节点离开时,其它所有节点重新选举和宣告管理接入点和业务接入点;采用退让模式避免冲突,只要监听到其它节点宣告拥有管理接入点或业务接入点,则主动解除原管理接入点和业务接入点的绑定关系。
4.根据权利要求1所述的支持负载均衡的自组织集群服务器,其特征是:节点间负载分担算法采用无状态散列算法,无需查找状态表,确保同一用户的业务请求由同一节点处理。
5.根据权利要求1所述的支持负载均衡的自组织集群服务器,其特征是:采用完全对等模式,每个节点的软件结构一样,任何节点都有1:N的冗余备份,即使只剩一个节点,***的所有功能仍然有效。
CN201410586235.3A 2014-10-28 2014-10-28 一种支持负载均衡的自组织集群服务器 Active CN105635199B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201410586235.3A CN105635199B (zh) 2014-10-28 2014-10-28 一种支持负载均衡的自组织集群服务器

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410586235.3A CN105635199B (zh) 2014-10-28 2014-10-28 一种支持负载均衡的自组织集群服务器

Publications (2)

Publication Number Publication Date
CN105635199A CN105635199A (zh) 2016-06-01
CN105635199B true CN105635199B (zh) 2019-03-15

Family

ID=56049685

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410586235.3A Active CN105635199B (zh) 2014-10-28 2014-10-28 一种支持负载均衡的自组织集群服务器

Country Status (1)

Country Link
CN (1) CN105635199B (zh)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106302721A (zh) * 2016-08-15 2017-01-04 博识峰云(深圳)信息技术有限公司 一种基于Openfire服务器的业务分离***和分离方法
CN106790502B (zh) * 2016-12-16 2020-04-24 睿哲科技股份有限公司 一种基于NAT64前缀的IPv4终端、IPv6服务互通业务的负载均衡***
CN106790692A (zh) * 2017-02-20 2017-05-31 郑州云海信息技术有限公司 一种多集群的负载均衡方法和装置
CN107148065A (zh) * 2017-04-12 2017-09-08 上海斐讯数据通信技术有限公司 一种基于无线分布式***桥接功能的关联数限制方法及***
CN107528777A (zh) * 2017-09-25 2017-12-29 广东电网有限责任公司电力调度控制中心 一种负载均衡的软交换网络故障恢复方法
CN109714223B (zh) * 2018-09-17 2022-03-22 赛特斯信息科技股份有限公司 Nfv架构下实现网络业务接入动态负载分担功能的***及其方法
CN110287045A (zh) * 2019-07-02 2019-09-27 北京谷数科技有限公司 一种基于solaris操作***的存储服务接口管理框架
CN112565475B (zh) * 2020-12-01 2023-07-11 成都精灵云科技有限公司 容器集群业务层添加新节点的ip地址分配方法
CN113364633B (zh) * 2021-06-18 2022-09-06 中国电子科技集团公司第二十八研究所 一种面向高机动环境的容器集群动态构建方法
CN113505001B (zh) * 2021-09-10 2022-05-31 阿里云计算有限公司 服务器管理方法和服务器、电子设备及计算机可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101753558A (zh) * 2009-12-11 2010-06-23 安徽科大讯飞信息科技股份有限公司 一种分布式mrcp服务器负载均衡***及其均衡方法
CN101834897A (zh) * 2010-04-23 2010-09-15 哈尔滨工程大学 一种dht网络负载均衡装置及虚节点划分的方法
CN101883113A (zh) * 2010-06-25 2010-11-10 中兴通讯股份有限公司 一种实现重叠网络负载均衡的方法和物理节点

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101753558A (zh) * 2009-12-11 2010-06-23 安徽科大讯飞信息科技股份有限公司 一种分布式mrcp服务器负载均衡***及其均衡方法
CN101834897A (zh) * 2010-04-23 2010-09-15 哈尔滨工程大学 一种dht网络负载均衡装置及虚节点划分的方法
CN101883113A (zh) * 2010-06-25 2010-11-10 中兴通讯股份有限公司 一种实现重叠网络负载均衡的方法和物理节点

Also Published As

Publication number Publication date
CN105635199A (zh) 2016-06-01

Similar Documents

Publication Publication Date Title
CN105635199B (zh) 一种支持负载均衡的自组织集群服务器
Fife et al. Research issues for data communication in mobile ad-hoc network database systems
CN104461740B (zh) 一种跨域集群计算资源聚合和分配的方法
CN113079218A (zh) 一种面向服务的算力网络***、工作方法及存储介质
CN103188345B (zh) 分布式动态负载管理***和方法
CN104468236B (zh) Sdn控制器集群、sdn交换机及其连接控制方法
CN103077082B (zh) 一种数据中心负载分配及虚拟机迁移节能方法及***
CN109617992A (zh) 一种基于区块链的边缘计算节点动态选举方法
US20120066371A1 (en) Server Load Balancer Scaling for Virtual Servers
CN108536539B (zh) 一种工业分布式数据采集***中的任务调度方法
CN105491138A (zh) 一种基于负载率分级触发的分布式负载调度方法
CN103428103A (zh) 一种链路负载控制方法和堆叠设备
CN104301417B (zh) 一种负载均衡方法及装置
CN102970242A (zh) 一种实现负载均衡的方法
CN108282526B (zh) 双集群间服务器动态分配方法及***
CN103401951B (zh) 基于对等架构的弹性云分发方法
Fan et al. Game balanced multi-factor multicast routing in sensor grid networks
CN103152420B (zh) 一种避免Ovirt虚拟管理平台单点失效的方法
CN108322525A (zh) 一种工业多核心网络构建方法
Srivastava et al. A dominance of the channel capacity in load balancing of software defined network
CN103580957B (zh) 一种无中心网络的节点状态快速监测方法
CN203951500U (zh) 一种基于p2p技术的无线传感器网络
CN102724193A (zh) 针对IP网络环境中Streaming业务生存性进行控制的方法
CN102984296B (zh) 一种网络地址配置及网络合并的方法
Xia et al. Heterogeneity and load balance in structured P2P system

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information

Address after: 510630 room 701, B building, 89 Zhongshan Avenue West, Tianhe District, Guangzhou, Guangdong.

Applicant after: REYZAR TECHNOLOGY CO.,LTD.

Address before: 510630 room 701, B building, 89 Zhongshan Avenue West, Tianhe District, Guangzhou, Guangdong.

Applicant before: GUANGDONG REYZAR TECHNOLOGY CO.,LTD.

Address after: 510630 room 701, B building, 89 Zhongshan Avenue West, Tianhe District, Guangzhou, Guangdong.

Applicant after: GUANGDONG REYZAR TECHNOLOGY CO.,LTD.

Address before: 510630 room 701, B building, 89 Zhongshan Avenue West, Tianhe District, Guangzhou, Guangdong.

Applicant before: Guangdong Rui zhe Network Technology Co.,Ltd.

Address after: 510630 room 701, B building, 89 Zhongshan Avenue West, Tianhe District, Guangzhou, Guangdong.

Applicant after: Guangdong Rui zhe Network Technology Co.,Ltd.

Address before: 510630 room 701, B building, 89 Zhongshan Avenue West, Tianhe District, Guangzhou, Guangdong.

Applicant before: GUANGZHOU REYZAR NETWORK TECHNOLOGY CO.,LTD.

CB02 Change of applicant information
GR01 Patent grant
GR01 Patent grant