CN107147697A - 应用组切换方法及装置 - Google Patents
应用组切换方法及装置 Download PDFInfo
- Publication number
- CN107147697A CN107147697A CN201710226813.6A CN201710226813A CN107147697A CN 107147697 A CN107147697 A CN 107147697A CN 201710226813 A CN201710226813 A CN 201710226813A CN 107147697 A CN107147697 A CN 107147697A
- Authority
- CN
- China
- Prior art keywords
- group
- application group
- main frame
- cluster
- standby host
- 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
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0659—Management of faults, events, alarms or notifications using network fault recovery by isolating or reconfiguring faulty entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Hardware Redundancy (AREA)
Abstract
本发明公开了一种应用组切换方法,应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述方法包括:集群中的主控设备将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机;在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。本发明还公开了一种应用组切换装置。本发明不会导致硬件资源的浪费,还有利于集群中业务服务的拓展。
Description
技术领域
本发明涉及计算机技术领域,尤其涉及一种应用组切换方法及装置。
背景技术
目前,在负载均衡厂商中,为了防止设备单点故障导致用户业务瘫痪,都会提供一种设备容灾方案。常见的容灾方案主要是双机模型(如图1所述),在双机模型中,一台设备作为主机(图1中的AD1)提供服务,另一台设备作为备机(图1中的AD2)不提供服务,只备份主机的配置与业务,当主机发生故障时,备机切换为主机,接替原主机的服务。
但随着用户的业务不断发展,传统的双机模型逐渐暴露出以下缺点:
1、备机长时间处于不工作状态,导致其硬件资源白白被浪费掉;
2、由于所有业务服务都只在主机设备上提供,那么整体的服务性能与业务扩展都受限于主机的单机性能,不利于用户扩展自身的业务。
发明内容
本发明的主要目的在于提出一种应用组切换方法及装置,旨在解决传统的业务切换采用双机模型,容易导致备机的硬件资源浪费以及不利于拓展业务的技术问题。
为实现上述目的,本发明提供的一种应用组切换方法,所述方法应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述应用组切换方法包括:
集群中的主控设备将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机;
在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
优选地,所述集群包括管理口和心跳HA口,所述集群中的各个设备通过所述管理口和所述HA口提供的心跳线互相发送心跳包,以检测各个设备的健康状态,并根据心跳包携带主控设备的选举信息以选择主控设备。
优选地,对集群中的应用组分配主机及/或备机的方式包括:
所述主控设备确定集群中是否存在默认的主机及/或备机;
若存在,将默认的主机及/或备机作为应用组的主机及/或备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的主机及/或备机。
优选地,所述对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机的步骤之后,所述应用组切换方法还包括:
所述主控设备将主机中的服务连接信息及/或会话记录批量同步至同一个应用组的备机中,以使同一个应用组的主机和备机保持连接同步和会话同步;
在同一个应用组的主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中。
优选地,所述在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中的步骤之前,所述应用组切换方法还包括:
所述主控设备实时监测各个主机上报的链路状态信息和节点状态信息;
若所述主控设备监测到应用组的主机上报链路离线或者节点离线时,认为所述应用组的主机故障。
优选地,所述集群中的各个应用组使用虚拟物理地址,所述在检测到有应用组的主机故障时,所述应用组切换方法还包括:
所述主控设备将应用组的虚拟物理地址从主机迁移至备机中,以使切换前后的应用组的地址保持不变。
此外,为实现上述目的,本发明还提出一种应用组切换装置,所述装置应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述应用组切换装置包括:
分配模块,用于将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
选择模块,用于对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机;
切换模块,用于在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
优选地,所述集群包括管理口和心跳HA口,所述集群中的各个设备通过所述管理口和所述HA口提供的心跳线互相发送心跳包,以检测各个设备的健康状态,并根据心跳包携带主控设备的选举信息以选择主控设备。
优选地,对集群中的应用组分配主机及/或备机的方式包括:
确定集群中是否存在默认的主机及/或备机;
若存在,将默认的主机及/或备机作为应用组的主机及/或备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的主机及/或备机。
优选地,所述应用组切换装置还包括:
同步模块,用于将主机中的服务连接信息及/或会话记录批量同步至同一个应用组的备机中,以使同一个应用组的主机和备机保持连接同步和会话同步;
启动模块,用于在同一个应用组的主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中。
优选地,所述应用组切换装置还包括:
监测模块,用于实时监测各个主机上报的链路状态信息和节点状态信息;
处理模块,用于若监测到应用组的主机上报链路离线或者节点离线时,认为所述应用组的主机故障。
优选地,所述集群中的各个应用组使用虚拟物理地址,所述在检测到有应用组的主机故障时,所述应用组切换装置还包括:
迁移模块,用于将应用组的虚拟物理地址从主机迁移至备机中,以使切换前后的应用组的地址保持不变。
本发明提出的应用组切换方法及装置,集群中的主控设备先将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机,然后对对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,后续在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。本方案中,充分利用集群中的每台设备发布不同的应用服务,同时各台设备能互为备机,当某个应用组的备机在主机故障的情况下,能接替主机继续提供服务,而在主机没有故障的情况下,备机自己作为另一个应用组的主机也能继续提供服务,不会导致硬件资源的浪费,此外,集群中的各个设备都能提供服务,不限于主机提供服务,有利于集群中业务服务的拓展。
附图说明
图1为现有的业务切换架构图;
图2为本发明应用组切换方法第一实施例的流程示意图;
图3为本发明的集群架构图;
图4为应用组切换的示意图;
图5为本发明应用组切换方法第二实施例的流程示意图;
图6a-6b为主备机连接跟踪同步和会话同步的示意图;
图7为本发明应用组切换方法第三实施例的流程示意图;
图8为本发明应用组切换装置第一实施例的功能模块示意图;
图9为本发明应用组切换装置第二实施例的功能模块示意图;
图10为本发明应用组切换装置第三实施例的功能模块示意图。
具体实施方式
应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
本发明实施例的解决方案主要是:集群中的主控设备先将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机,然后对分配有主机的应用组,在集群中选择除所述主机以外的任一设备作为应用组的备机,后续在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。以解决传统的业务切换采用双机模型,容易导致备机的硬件资源浪费,以及不利于拓展业务的技术问题。
专业术语介绍:
高可用集群:将多台负载均衡设备组合起来为用户提供服务,充分利用集群中的每一台设备,发布不同的服务,同时能互为备份,保证故障发生时的最小业务中断。
主机:集群中真正提供服务的负载均衡设备。
备机:集群中用于备份主机业务的设备,在主机故障的情况下,接替主机对外提供服务。
故障切换:主机故障后,由备机接替主机所承担的业务,对外提供服务。
链路检测:目前主要依靠指定协议数据包探测,通过判断能否正常发送数据并且能够正常收到对端主机的应答,则认为这条链路是健康的,否则是故障链路。
应用组:集群故障切换的基本单位,一个应用组含有多个具有关联关系的服务,在同一时刻只在集群中的某一台设备上发布。
浮动IP:同一时刻只在集群中的某一台设备上生效的IP地址,可通过应用组切换来迁移到另一台设备。
基于现有技术存在的问题,本发明提供一种应用组切换方法。
参照图2,图2为本发明应用组切换方法第一实施例的流程示意图。
在本实施例中,所述方法应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述应用组切换方法包括:
步骤S10,集群中的主控设备将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
步骤S20,对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机,还可以是集群中的空闲设备;
步骤S30,在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
在本实施例中,先根据多台负载均衡设备组建一个高可用集群,优选是使用相同型号的设备组建高可用集群。该集群中有多台设备,其中一台是主控设备,一台是备控设备,其余的是负载设备(也称为候选设备),主控设备在集群中负责维护与管理配置、自动同步数据给其它设备、实时监控其它设备的健康状态,并且还负责给所有设备分配业务服务;备控设备在主控设备故障时,切换为主控设备进行服务;候选设备是在备控设备故障时,作为新的备控设备以接替主机继续服务的设备。主控设备是集群中的各个设备共同选取出来的,主控设备的具体选取方式如下:
集群包括管理口和心跳HA口,所述集群中的各个设备通过所述管理口和所述HA口提供的心跳线互相发送心跳包,以检测各个设备的健康状态,并根据心跳包携带主控设备的选举信息以选择主控设备。
即,集群中各个设备会相互发送心跳包,心跳包中携带主控设备的选举信息,当超过一半的设备选择一台设备作为主控设备时,被选择的设备就成为该集群中的主控设备。
此外,需要说明的是,本实施例中的集群包括管理口和心跳HA口,是一种双网络接口,即使其中一个网络口出现故障,另一个网络口也可以继续被集群的各个设备使用,即各个设备通过一个网络口的心跳线继续进行相互发送心跳包,以检测各个设备的健康状态,进行主控设备的选举。即使主控设备出现故障,其它各设备也可以通过心跳线快速确定出新的主控设备,提高了集群心跳的健壮性,并且可以提高集群的使用率。
应当理解,本实施例中集群具有双网络心跳检测功能,通过将设备管理网络作为冗余的心跳网络,减小设备故障所带来的影响,在很大程度地加强集群心跳的健壮性。
在确定主控设备之后,进一步确定该集群中的备控设备,备控设备的确定方式包括两种:用户确定或主控设备确定,即,该备控设备可以是用户在界面中设置的默认设备,若用户未在界面设置默认设备,则主控设备根据各个设备通过心跳线发送的心跳包,以确定集群中各个设备的健康状态。即,集群包括的管理口和心跳HA口,还便于主控设备确定各个设备的健康状态,即使备控设备故障,或者是一个网络接口故障,主控设备也可根据另一个网络口快速确定新的备控设备,同样也提高了集群心跳的健壮性,并且可以提高集群的使用率。
当主控设备确定集群中各个设备都是健康设备时,可将负载分数最低的设备作为备控设备。
此外,传统的备机出现故障时不易被检测出来,往往等到主机故障切换后,才发现备机已经不可用了,此时两台设备都已不可用,用户业务随之瘫痪。而本实施例中,通过双网络心跳检测功能,对主控设备以及备控设备都通实时检测功能,可以快速的更换备控设备,防止备控设备故障时导致整个集群系统的瘫痪,提高了集群中设备使用的高可用性。
在本实施例中,在集群中确定主控设备和备控设备之后,所述主控设备开始对集群中的各个应用服务进行分组,具体的分组方式是根据业务类型进行划分,以得到各个应用组,例如集群中有三个服务业务vs1、vs2和vs3,其中,vs1、vs2的业务类型一致,vs3与前两个的业务类型不一致,则可将vs1、vs2划分为一个应用组,将vs3划分为一个应用组。
以下是本实施例中实现应用组切换的各个步骤:
其中,步骤S10,集群中的主控设备将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
在本实施例中,在确定主机之后,即可将应用组分配给主机,以使配有应用组的设备作为应用组的主机。所述主控设备对集群中的应用组分配主机的方式包括:
方式一:将所有健康的设备构成一个子集;
若集群中存在角色为主机的设备,所述主控设备确定角色为主机的设备中是否存在默认的主机;
若存在,将默认的主机作为应用组的主机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的主机。
也就是说,主控设备在对各个应用组分组之后,先将各个应用组分配给相应的主机,在集群中存在角色为主机的设备的情况下,所述主控设备确定集群里所有角色为主机的设备中是否存在默认的主机,若存在默认的主机,即可将默认的主机选作为应用组的主机;若没有,则根据各个角色为主机的设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,以确定各个角色为主机的设备的负载分数,即负载分数=sum(生效应用组权值)/sum(所有应用组权值),再将负载分数最小的设备作为应用组的主机。可以理解,分数衡量设备间的相对负载情况,负载分数越低表示设备越空闲。
方式二:将所有健康的设备构成一个子集;
若集群中不存在角色为主机的设备,选择新选举出的备机为主机。
即,在集群中不存在主机的情况下,选择新选举出来的备机作为主机。
其中,步骤S20,对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机,还可以是集群中的空闲设备;
在对应用组分配主机之后,所述主控设备进一步对分配有主机的应用组选择备机,备机的选择方式包括:
方式一:将所有健康的设备构成一个子集;
若集群中存在角色为备机的设备,所述主控设备确定角色为备机的设备中是否存在默认的备机;
若存在,将默认的备机作为应用组的备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权重值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的备机。
即,在角色为备机的设备中,确定是否存在默认设备,若有,则直接将其选为备机,否则在角色为备机的设备中选择一台负载分数最低的设备为备机;
方式二:将所有健康的设备构成一个子集;
若集群中不存在角色为备机的设备,所述主控设备确定集群中是否存在默认的备机;
若存在,将默认的备机作为应用组的备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权重值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的备机。
方式三:在没有健康设备时,将所有故障但在线的设备构成一个子集,在故障的设备中,所述主控设备确定是否存在默认的备机,若存在,将默认的备机作为应用组的备机,若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的备机。
其中,步骤S30,在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
在确定应用组的主机和备机之后,主控设备可监测各个应用组的主机工作状态,在检测到有应用组的主机故障时,即可将主机故障的应用组切换至所述应用组的备机中,由备机对应用组继续提供服务。
可以理解,本实施例中,每个应用组都有一台设备作为主机,另外的设备作为备机,提供灵活有效的应用切换机制,即使主机故障,也可将应用组切换至备机中继续提供服务,降低整个系统的故障概率。
本实施例中,集群的架构如图3所示,集群中包括管理口和HA口,集群中的各个设备通过心跳线相互发包,以根据各个心跳包确定出主控设备,在确定出主控设备后,再确定出备控设备以及AD设备。后续,主控设备在集群中对各个应用组分配主机和备机,本实施例中,主控设备为应用组分配主机时,保证不同的应用组分配到不同的设备作为主机,例如,集群中当前分了两个应用组,两个应用组均分配至不同的AD设备中。
为了更清楚理解本实施例,举例详述之:参照图4,现有两个应用组,应用组1和应用组2,如图4所示,通过高可用集群系统的应用组选举算法,将应用组均衡地分布在不同设备上,选举结果为:
应用组1的主机为AD1,其备机为AD2;应用组2的主机为AD2,其备机为AD3;应用组1含有虚拟服务(vs1和vs2)、浮动IP(IP1和IP2)、源地址转换(SNAT1);应用组2含有虚拟服务(vs3和vs4)、浮动IP(IP3和IP4)、源地址转换(SNAT2);此时AD1对外提供vs1和vs2服务,AD2对外提供vs3和vs4服务。
若AD1发生故障,首先应用组1会立刻切换至AD2,AD2角色由备机升级为主机,接着应用组1在可用设备里重新选举AD3作为备机,最终结果是AD2对外提供vs1、vs2、vs3、vs4服务。
若AD2发生故障,首先应用组2会立刻切换至AD3,AD3角色由备机升级为主机,接着应用组2在可用设备里重新选举AD1作为备机,而应用组1的备机失效,于是在可用设备里重新选举AD3作为备机,最终结果是AD1对外提供vs1和vs2服务,AD3对外提供vs3和vs4服务。
若AD1和AD2都发生故障了,此时对于应用组1来说,其主机和备机都不可用了,那么将会触发应用组选举,在所有设备中找到AD3是可用的,即选举AD3作为应用组1的主机。对于应用组2来说,其主机故障了,业务便立刻切换至AD3,AD3角色由备机升级为主机。最终结果是AD3对外提供vs1、vs2、vs3、vs4服务。
通过上述方式,即可完成集群中各个应用组的切换。
可以理解,本实施例中,集群中的设备以应用组为单位可以各自发布不同的服务,然后由其它设备对此服务形成备份,在主机故障时,将应用组切换至备机中继续服务,保证故障发生时的最小业务中断。而且只要集群中有一台设备可用,就不会导致任何一个服务故障无法使用,在此基础上,实现均衡的应用组分配和故障切换机制。通过应用组的分配,实现不同业务在不同的设备上生效,并提供应用组的切换能力。
本实施例提出的应用组切换方法,集群中的主控设备先将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机,然后对对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,后续在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。本方案中,充分利用集群中的每台设备发布不同的应用服务,同时各台设备能互为备机,当某个应用组的备机在主机故障的情况下,能接替主机继续提供服务,而在主机没有故障的情况下,备机自己作为另一个应用组的主机也能继续提供服务,不会导致硬件资源的浪费,此外,集群中的各个设备都能提供服务,不限于主机提供服务,有利于集群中业务服务的拓展。
进一步地,基于第一实施例提出本发明应用组切换方法的第二实施例。
本实施例与第一实施例的区别在于:参照图5,所述步骤S20之后,所述应用组切换方法还包括:
步骤S40,所述主控设备将主机中的服务连接信息及/或会话记录批量同步至同一个应用组的备机中,以使同一个应用组的主机和备机保持连接同步和会话同步;
步骤S50,在同一个应用组的主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中。
在本实施例中,当应用组发生故障切换时,为防止用户已有连接被中断或者新连接调度到其它服务器上面,这里引入了连接跟踪同步和会话保持同步机制。以应用组为单位,在主备机之间同步连接跟踪和会话保持信息,可以减少设备需要同步的数据量。同步分为批量同步和增量同步,当应用组的主备机刚建立起来时,所述主控设备将主机中的服务连接信息及/或会话记录批量同步至备机中,以使主机和备机保持连接同步和会话同步;而在主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中即可,具体流程如下:
连接跟踪同步:如图6a所示,应用组1主备机分别为AD1和AD2,客户端C与AD1创建连接,AD1向AD2同步服务相关连接跟踪信息,当AD1发生故障,AD2成为应用组1的主机,客户端C可与AD2在已有的连接上继续通讯。
会话保持同步:如图6b所示,应用组1主备机分别为AD1和AD2,客户端C向AD1发起请求,AD1将客户端C的请求调度到服务器N,AD1向AD2同步VS相关会话会话保持信息,当AD1发生故障,AD2成为应用组1的主机,客户端C再次向AD2发起请求,AD2可将客户端C的请求调度到相同的服务器N。
应当理解,若是按照传统的双机模型方案,若要保证主备切换后,原有连接服务和会话记录不发生改变,那么主机必须同步所有连接跟踪和会话保持到备机上,当业务扩展导致同步的数据量增加时,将给主机带来更多的性能损耗。
在本实施例中,每个应用组的主机会向首选备机实时同步连接跟踪和会话记录,确保主备切换时用户连接和会话保持不中断,并且同步数据的方式是协同批量同步和增量同步,先批量同步之前的数据,在服务连接和会话记录同步之后,后续新的内容增量同步即可,无须再将主机中所有数据同步至备机中,对主机的损耗降低了,并且数据的同步效率更高,更加智能。
进一步地,基于第一或第二实施例提出本发明应用组切换方法的第三实施例。
本实施例与第一或第二实施例的区别在于:参照图7,所述步骤S30之前,所述应用组切换方法还包括:
步骤S60,所述主控设备实时监测各个主机上报的链路状态信息和节点状态信息;
步骤S70,若所述主控设备监测到应用组的主机上报链路离线或者节点离线时,认为所述应用组的主机故障。
在本实施例中,集群中每台设备都可以监视自身的链路状态和节点状态,并上报给集群主控设备,主控设备当检测到链路或者节点故障时,涉及到该链路和节点的应用组将被切换到备机上,保证服务持续可靠。
值得注意的是,在引用第二实施例时,所述步骤S60优选位于所述步骤S50之后。
在本实施例中,集群中的各个主机通过心跳线定时向主控设备上报链路状态信息和节点状态信息,以便于主控设备监控各个主机的运行状态,主控设备监测到应用组的主机上报链路离线或者节点离线时,即可开始将应用组进行切换,提高了应用组切换的及时性。
进一步地,基于第一至第三实施例提出本发明应用组切换方法的第四实施例。
本实施例与第一至第三实施例的区别在于:所述集群中的各个应用组使用虚拟物理地址,所述在检测到有应用组的主机故障时,所述应用组切换方法还包括:
所述主控设备将应用组的虚拟物理地址从主机迁移至备机中,以使切换前后的应用组的地址保持不变。
应当理解,传统的网络环境中,上游设备开启了ARP(Address ResolutionProtocol,地址解析协议)绑定,会导致应用组切换后无法使用新MAC(Media AccessControl,介质访问控制)物理地址。那么切换前后的应用组的地址不同,会导致业务中断。
而本实施例中,通过MAC地址伪装,可保证切换后服务IP正常使用,应用组1包含虚拟服务VS1,VS1引用浮动IP1,IP1配置了虚拟MAC地址MAC1。当AD1发生故障,应用组1主机切换至AD2,IP1在AD2上生效,AD2使用MAC1广播IP1的ARP,若AD2收到对于IP1的ARP请求广播,使用MAC1返回ARP应答。通过MAC地址伪装,当应用组发生故障切换时,IP地址转移至其他设备,可使IP地址使用的MAC地址不变,以达到最小切换时间,也可以满足上游设备的ARP绑定需求。
本实施例中,通过使用虚拟的MAC地址伪装,应用组切换时浮动IP对应的MAC地址跟随应用组一起切换到备机,这样切换后应用组的MAC地址保持不变,以达到最快的切换速度,将客户业务的中断时间减少到最短,保证了业务的正常进行。
本发明进一步提供一种应用组切换装置。
参照图8,图8为本发明应用调试装置较佳实施例的功能模块示意图。
需要强调的是,对本领域的技术人员来说,图8所示功能模块图仅仅是一个较佳实施例的示例图,本领域的技术人员围绕图8所示的应用组切换装置的功能模块,可轻易进行新的功能模块的补充;各功能模块的名称是自定义名称,仅用于辅助理解该应用组切换装置的各个程序功能块,不用于限定本发明的技术方案,本发明技术方案的核心是,各自定义名称的功能模块所要达成的功能。
本实施例提出一种应用组切换装置,所述装置应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述应用组切换装置包括:
分配模块10,用于将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
选择模块20,用于对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机,还可以是集群中的空闲设备;
切换模块30,用于在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
在本实施例中,先根据多台负载均衡设备组建一个高可用集群,优选是使用相同型号的设备组建高可用集群。该集群中有多台设备,其中一台是主控设备,一台是备控设备,其余的是负载设备(也称为候选设备),主控设备在集群中负责维护与管理配置、自动同步数据给其它设备、实时监控其它设备的健康状态,并且还负责给所有设备分配业务服务;备控设备在主控设备故障时,切换为主控设备进行服务;候选设备是在备控设备故障时,作为新的备控设备以接替主机继续服务的设备。主控设备是集群中的各个设备共同选取出来的,主控设备的具体选取方式如下:
集群包括管理口和心跳HA口,所述集群中的各个设备通过所述管理口和所述HA口提供的心跳线互相发送心跳包,以检测各个设备的健康状态,并根据心跳包携带主控设备的选举信息以选择主控设备。
即,集群中各个设备会相互发送心跳包,心跳包中携带主控设备的选举信息,当超过一半的设备选择一台设备作为主控设备时,被选择的设备就成为该集群中的主控设备。
此外,需要说明的是,本实施例中的集群包括管理口和心跳HA口,是一种双网络接口,即使其中一个网络口出现故障,另一个网络口也可以继续被集群的各个设备使用,即各个设备通过一个网络口的心跳线继续进行相互发送心跳包,以检测各个设备的健康状态,进行主控设备的选举。即使主控设备出现故障,其它各设备也可以通过心跳线快速确定出新的主控设备,提高了集群心跳的健壮性,并且可以提高集群的使用率。
应当理解,本实施例中集群具有双网络心跳检测功能,通过将设备管理网络作为冗余的心跳网络,减小设备故障所带来的影响,在很大程度地加强集群心跳的健壮性。
在确定主控设备之后,进一步确定该集群中的备控设备,备控设备的确定方式包括两种:用户确定或主控设备确定,即,该备控设备可以是用户在界面中设置的默认设备,若用户未在界面设置默认设备,则主控设备根据各个设备通过心跳线发送的心跳包,以确定集群中各个设备的健康状态。即,集群包括的管理口和心跳HA口,还便于主控设备确定各个设备的健康状态,即使备控设备故障,或者是一个网络接口故障,主控设备也可根据另一个网络口快速确定新的备控设备,同样也提高了集群心跳的健壮性,并且可以提高集群的使用率。
当主控设备确定集群中各个设备都是健康设备时,可将负载分数最低的设备作为备控设备。
此外,传统的备机出现故障时不易被检测出来,往往等到主机故障切换后,才发现备机已经不可用了,此时两台设备都已不可用,用户业务随之瘫痪。而本实施例中,通过双网络心跳检测功能,对主控设备以及备控设备都通实时检测功能,可以快速的更换备控设备,防止备控设备故障时导致整个集群系统的瘫痪,提高了集群中设备使用的高可用性。
在本实施例中,在集群中确定主控设备和备控设备之后,所述主控设备开始对集群中的各个应用服务进行分组,具体的分组方式是根据业务类型进行划分,以得到各个应用组,例如集群中有三个服务业务vs1、vs2和vs3,其中,vs1、vs2的业务类型一致,vs3与前两个的业务类型不一致,则可将vs1、vs2划分为一个应用组,将vs3划分为一个应用组。
以下是本实施例中实现应用组切换的各个模块,以及模块功能介绍:
其中,分配模块10,用于将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
在本实施例中,在确定主机之后,分配模块10即可将应用组分配给主机,以使配有应用组的设备作为应用组的主机。分配模块10对集群中的应用组分配主机的方式包括:
方式一:将所有健康的设备构成一个子集;
若集群中存在角色为主机的设备,所述主控设备确定角色为主机的设备中是否存在默认的主机;
若存在,将默认的主机作为应用组的主机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的主机。
也就是说,主控设备在对各个应用组分组之后,先将各个应用组分配给相应的主机,在集群中存在角色为主机的设备的情况下,所述主控设备确定集群里所有角色为主机的设备中是否存在默认的主机,若存在默认的主机,即可将默认的主机选作为应用组的主机;若没有,则根据各个角色为主机的设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,以确定各个角色为主机的设备的负载分数,即负载分数=sum(生效应用组权值)/sum(所有应用组权值),再将负载分数最小的设备作为应用组的主机。可以理解,分数衡量设备间的相对负载情况,负载分数越低表示设备越空闲。
方式二:将所有健康的设备构成一个子集;
若集群中不存在角色为主机的设备,选择新选举出的备机为主机。
即,在集群中不存在主机的情况下,选择新选举出来的备机作为主机。
其中,选择模块20,用于对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机,还可以是集群中的空闲设备;
在对应用组分配主机之后,选择模块20进一步对分配有主机的应用组选择备机,备机的选择方式包括:
方式一:将所有健康的设备构成一个子集;
若集群中存在角色为备机的设备,所述主控设备确定角色为备机的设备中是否存在默认的备机;
若存在,将默认的备机作为应用组的备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权重值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的备机。
即,在角色为备机的设备中,确定是否存在默认设备,若有,则直接将其选为备机,否则在角色为备机的设备中选择一台负载分数最低的设备为备机;
方式二:将所有健康的设备构成一个子集;
若集群中不存在角色为备机的设备,所述主控设备确定集群中是否存在默认的备机;
若存在,将默认的备机作为应用组的备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权重值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的备机。
方式三:在没有健康设备时,将所有故障但在线的设备构成一个子集,在故障的设备中,所述主控设备确定是否存在默认的备机,若存在,将默认的备机作为应用组的备机,若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的备机。
其中,切换模块30,用于在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
在确定应用组的主机和备机之后,切换模块30可监测各个应用组的主机工作状态,在检测到有应用组的主机故障时,即可将主机故障的应用组切换至所述应用组的备机中,由备机对应用组继续提供服务。
可以理解,本实施例中,每个应用组都有一台设备作为主机,另外的设备作为备机,提供灵活有效的应用切换机制,即使主机故障,也可将应用组切换至备机中继续提供服务,降低整个系统的故障概率。
本实施例中,集群的架构如图3所示,集群中包括管理口和HA口,集群中的各个设备通过心跳线相互发包,以根据各个心跳包确定出主控设备,在确定出主控设备后,再确定出备控设备以及AD设备。后续,主控设备在集群中对各个应用组分配主机和备机,本实施例中,主控设备为应用组分配主机时,保证不同的应用组分配到不同的设备作为主机,例如,集群中当前分了两个应用组,两个应用组均分配至不同的AD设备中。
为了更清楚理解本实施例,举例详述之:参照图4,现有两个应用组,应用组1和应用组2,如图4所示,通过高可用集群系统的应用组选举算法,将应用组均衡地分布在不同设备上,选举结果为:
应用组1的主机为AD1,其备机为AD2;应用组2的主机为AD2,其备机为AD3;应用组1含有虚拟服务(vs1和vs2)、浮动IP(IP1和IP2)、源地址转换(SNAT1);应用组2含有虚拟服务(vs3和vs4)、浮动IP(IP3和IP4)、源地址转换(SNAT2);此时AD1对外提供vs1和vs2服务,AD2对外提供vs3和vs4服务。
若AD1发生故障,首先应用组1会立刻切换至AD2,AD2角色由备机升级为主机,接着应用组1在可用设备里重新选举AD3作为备机,最终结果是AD2对外提供vs1、vs2、vs3、vs4服务。
若AD2发生故障,首先应用组2会立刻切换至AD3,AD3角色由备机升级为主机,接着应用组2在可用设备里重新选举AD1作为备机,而应用组1的备机失效,于是在可用设备里重新选举AD3作为备机,最终结果是AD1对外提供vs1和vs2服务,AD3对外提供vs3和vs4服务。
若AD1和AD2都发生故障了,此时对于应用组1来说,其主机和备机都不可用了,那么将会触发应用组选举,在所有设备中找到AD3是可用的,即选举AD3作为应用组1的主机。对于应用组2来说,其主机故障了,业务便立刻切换至AD3,AD3角色由备机升级为主机。最终结果是AD3对外提供vs1、vs2、vs3、vs4服务。
通过上述方式,即可完成集群中各个应用组的切换。
可以理解,本实施例中,集群中的设备以应用组为单位可以各自发布不同的服务,然后由其它设备对此服务形成备份,在主机故障时,将应用组切换至备机中继续服务,保证故障发生时的最小业务中断。而且只要集群中有一台设备可用,就不会导致任何一个服务故障无法使用,在此基础上,实现均衡的应用组分配和故障切换机制。通过应用组的分配,实现不同业务在不同的设备上生效,并提供应用组的切换能力。
本实施例提出的应用组切换装置,集群中的主控设备先将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机,然后对对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,后续在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。本方案中,充分利用集群中的每台设备发布不同的应用服务,同时各台设备能互为备机,当某个应用组的备机在主机故障的情况下,能接替主机继续提供服务,而在主机没有故障的情况下,备机自己作为另一个应用组的主机也能继续提供服务,不会导致硬件资源的浪费,此外,集群中的各个设备都能提供服务,不限于主机提供服务,有利于集群中业务服务的拓展。
进一步地,基于第一实施例提出本发明应用组切换装置的第二实施例。
本实施例与第一实施例的区别在于:参照图9,所述应用组切换装置还包括:
同步模块40,用于将主机中的服务连接信息及/或会话记录批量同步至同一个应用组的备机中,以使同一个应用组的主机和备机保持连接同步和会话同步;
启动模块50,用于在同一个应用组的主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中。
本实施例中,同步模块和启动模块可统称为数据同步模块。
在本实施例中,当应用组发生故障切换时,为防止用户已有连接被中断或者新连接调度到其它服务器上面,这里引入了连接跟踪同步和会话保持同步机制。以应用组为单位,在主备机之间同步连接跟踪和会话保持信息,可以减少设备需要同步的数据量。同步分为批量同步和增量同步,当应用组的主备机刚建立起来时,同步模块40将主机中的服务连接信息及/或会话记录批量同步至备机中,以使主机和备机保持连接同步和会话同步;而在主机和备机保持连接同步和会话同步的情况下,启动模块50启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中即可,具体流程如下:
连接跟踪同步:如图6a所示,应用组1主备机分别为AD1和AD2,客户端C与AD1创建连接,AD1向AD2同步服务相关连接跟踪信息,当AD1发生故障,AD2成为应用组1的主机,客户端C可与AD2在已有的连接上继续通讯。
会话保持同步:如图6b所示,应用组1主备机分别为AD1和AD2,客户端C向AD1发起请求,AD1将客户端C的请求调度到服务器N,AD1向AD2同步VS相关会话会话保持信息,当AD1发生故障,AD2成为应用组1的主机,客户端C再次向AD2发起请求,AD2可将客户端C的请求调度到相同的服务器N。
应当理解,若是按照传统的双机模型方案,若要保证主备切换后,原有连接服务和会话记录不发生改变,那么主机必须同步所有连接跟踪和会话保持到备机上,当业务扩展导致同步的数据量增加时,将给主机带来更多的性能损耗。
在本实施例中,每个应用组的主机会向首选备机实时同步连接跟踪和会话记录,确保主备切换时用户连接和会话保持不中断,并且同步数据的方式是协同批量同步和增量同步,先批量同步之前的数据,在服务连接和会话记录同步之后,后续新的内容增量同步即可,无须再将主机中所有数据同步至备机中,对主机的损耗降低了,并且数据的同步效率更高,更加智能。
进一步地,基于第一或第二实施例提出本发明应用组切换装置的第三实施例。
本实施例与第一或第二实施例的区别在于:参照图10,所述应用组切换装置还包括:
监测模块60,用于实时监测各个主机上报的链路状态信息和节点状态信息;
处理模块70,用于若监测到应用组的主机上报链路离线或者节点离线时,认为所述应用组的主机故障。
在本实施例中,集群中每台设备都可以监视自身的链路状态和节点状态,并上报给集群主控设备,监测模块60检测到链路或者节点故障时,处理模块70将涉及到该链路和节点的应用组切换到备机上,保证服务持续可靠。
在本实施例中,集群中的各个主机通过心跳线定时向主控设备上报链路状态信息和节点状态信息,以便于主控设备监控各个主机的运行状态,主控设备监测到应用组的主机上报链路离线或者节点离线时,即可开始将应用组进行切换,提高了应用组切换的及时性。
进一步地,基于第一至第三实施例提出本发明应用组切换装置的第四实施例。
本实施例与第一至第三实施例的区别在于:所述集群中的各个应用组使用虚拟物理地址,所述在检测到有应用组的主机故障时,所述应用组切换装置还包括:
迁移模块,用于将应用组的虚拟物理地址从主机迁移至备机中,以使切换前后的应用组的地址保持不变。
应当理解,传统的网络环境中,上游设备开启了ARP(Address ResolutionProtocol,地址解析协议)绑定,会导致应用组切换后无法使用新MAC地址。那么切换前后的应用组的地址不同,会导致业务中断。
而本实施例中,通过MAC地址伪装,可保证切换后服务IP正常使用,应用组1包含虚拟服务VS1,VS1引用浮动IP1,IP1配置了虚拟MAC地址MAC1。当AD1发生故障,应用组1主机切换至AD2,IP1在AD2上生效,AD2使用MAC1广播IP1的ARP,若AD2收到对于IP1的ARP请求广播,使用MAC1返回ARP应答。通过MAC地址伪装,当应用组发生故障切换时,迁移模块将IP地址转移至其他设备,可使IP地址使用的MAC地址不变,以达到最小切换时间,也可以满足上游设备的ARP绑定需求。
本实施例中,通过使用虚拟的MAC地址伪装,应用组切换时浮动IP对应的MAC地址跟随应用组一起切换到备机,这样切换后应用组的MAC地址保持不变,以达到最快的切换速度,将客户业务的中断时间减少到最短,保证了业务的正常进行。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其它变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素,而且还包括没有明确列出的其它要素,或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其它相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (12)
1.一种应用组切换方法,其特征在于,所述方法应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述应用组切换方法包括:
集群中的主控设备将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机;
在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
2.如权利要求1所述的应用组切换方法,其特征在于,所述集群包括管理口和心跳HA口,所述集群中的各个设备通过所述管理口和所述HA口提供的心跳线互相发送心跳包,以检测各个设备的健康状态,并根据心跳包携带主控设备的选举信息以选择主控设备。
3.如权利要求1所述的应用组切换方法,其特征在于,对集群中的应用组分配主机及/或备机的方式包括:
所述主控设备确定集群中是否存在默认的主机及/或备机;
若存在,将默认的主机及/或备机作为应用组的主机及/或备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的主机及/或备机。
4.如权利要求1所述的应用组切换方法,其特征在于,所述对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机的步骤之后,所述应用组切换方法还包括:
所述主控设备将主机中的服务连接信息及/或会话记录批量同步至同一个应用组的备机中,以使同一个应用组的主机和备机保持连接同步和会话同步;
在同一个应用组的主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中。
5.如权利要求1所述的应用组切换方法,其特征在于,所述在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中的步骤之前,所述应用组切换方法还包括:
所述主控设备实时监测各个主机上报的链路状态信息和节点状态信息;
若所述主控设备监测到应用组的主机上报链路离线或者节点离线时,认为所述应用组的主机故障。
6.如权利要求1-5任一项所述的应用组切换方法,其特征在于,所述集群中的各个应用组使用虚拟物理地址,所述在检测到有应用组的主机故障时,所述应用组切换方法还包括:
所述主控设备将应用组的虚拟物理地址从主机迁移至备机中,以使切换前后的应用组的地址保持不变。
7.一种应用组切换装置,其特征在于,所述装置应用于包括多个设备的集群中,所述集群中的应用服务根据业务类型被分成不同的应用组,所述应用组切换装置包括:
分配模块,用于将各个应用组分配至所述集群的各个设备,以将分配有应用组的设备作为应用组的主机;
选择模块,用于对分配有主机的每一个应用组,在集群中选择除当前应用组的所述主机以外的任一设备作为当前应用组的备机,其中,当前应用组的备机可以是其它应用组的主机或备机;
切换模块,用于在检测到有应用组的主机故障时,将主机故障的应用组切换至所述应用组的备机中,由备机对应用组提供服务。
8.如权利要求7所述的应用组切换装置,其特征在于,所述集群包括管理口和心跳HA口,所述集群中的各个设备通过所述管理口和所述HA口提供的心跳线互相发送心跳包,以检测各个设备的健康状态,并根据心跳包携带主控设备的选举信息以选择主控设备。
9.如权利要求7所述的应用组切换装置,其特征在于,对集群中的应用组分配主机及/或备机的方式包括:
确定集群中是否存在默认的主机及/或备机;
若存在,将默认的主机及/或备机作为应用组的主机及/或备机;
若不存在,根据各个设备中已生效的应用组的权值和,与集群中所有应用组的权值和的比值,确定各个设备的负载分数,再将负载分数最小的设备作为应用组的主机及/或备机。
10.如权利要求7所述的应用组切换装置,其特征在于,所述应用组切换装置还包括:
同步模块,用于将主机中的服务连接信息及/或会话记录批量同步至同一个应用组的备机中,以使同一个应用组的主机和备机保持连接同步和会话同步;
启动模块,用于在同一个应用组的主机和备机保持连接同步和会话同步的情况下,启动增量同步方式,以将主机中新的服务连接信息及/或会话记录同步至备机中。
11.如权利要求7所述的应用组切换装置,其特征在于,所述应用组切换装置还包括:
监测模块,用于实时监测各个主机上报的链路状态信息和节点状态信息;
处理模块,用于若监测到应用组的主机上报链路离线或者节点离线时,认为所述应用组的主机故障。
12.如权利要求7-11任一项所述的应用组切换装置,其特征在于,所述集群中的各个应用组使用虚拟物理地址,所述在检测到有应用组的主机故障时,所述应用组切换装置还包括:
迁移模块,用于将应用组的虚拟物理地址从主机迁移至备机中,以使切换前后的应用组的地址保持不变。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710226813.6A CN107147697A (zh) | 2017-04-07 | 2017-04-07 | 应用组切换方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710226813.6A CN107147697A (zh) | 2017-04-07 | 2017-04-07 | 应用组切换方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107147697A true CN107147697A (zh) | 2017-09-08 |
Family
ID=59773541
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710226813.6A Pending CN107147697A (zh) | 2017-04-07 | 2017-04-07 | 应用组切换方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107147697A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109474465A (zh) * | 2018-11-13 | 2019-03-15 | 上海英方软件股份有限公司 | 一种基于服务器集群的可动态流转的高可用性的实现方法和系统 |
CN109839041A (zh) * | 2018-12-28 | 2019-06-04 | 北京航天测控技术有限公司 | 一种基于去中心化集群计算架构的免维护测控方法 |
CN110166524A (zh) * | 2019-04-12 | 2019-08-23 | 陆金所(上海)科技服务有限公司 | 数据中心的切换方法、装置、设备及存储介质 |
CN113055427A (zh) * | 2019-12-28 | 2021-06-29 | 浙江宇视科技有限公司 | 一种基于业务的服务器集群接入方法及装置 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070213906A1 (en) * | 2006-03-13 | 2007-09-13 | Deere & Company, A Delaware Corporation | Work vehicle software application display management system and associated method |
CN101119242A (zh) * | 2007-09-03 | 2008-02-06 | 中兴通讯股份有限公司 | 通讯系统集群方法、装置及应用其的集群服务系统 |
CN102629906A (zh) * | 2012-03-30 | 2012-08-08 | 浪潮电子信息产业股份有限公司 | 一种将集群管理节点做双机实现提高集群业务可用性的设计办法 |
CN103257350A (zh) * | 2012-05-07 | 2013-08-21 | 中国交通通信信息中心 | 一种双机双工自动切换方法 |
CN104679907A (zh) * | 2015-03-24 | 2015-06-03 | 新余兴邦信息产业有限公司 | 高可用高性能数据库集群的实现方法及系统 |
-
2017
- 2017-04-07 CN CN201710226813.6A patent/CN107147697A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070213906A1 (en) * | 2006-03-13 | 2007-09-13 | Deere & Company, A Delaware Corporation | Work vehicle software application display management system and associated method |
CN101119242A (zh) * | 2007-09-03 | 2008-02-06 | 中兴通讯股份有限公司 | 通讯系统集群方法、装置及应用其的集群服务系统 |
CN102629906A (zh) * | 2012-03-30 | 2012-08-08 | 浪潮电子信息产业股份有限公司 | 一种将集群管理节点做双机实现提高集群业务可用性的设计办法 |
CN103257350A (zh) * | 2012-05-07 | 2013-08-21 | 中国交通通信信息中心 | 一种双机双工自动切换方法 |
CN104679907A (zh) * | 2015-03-24 | 2015-06-03 | 新余兴邦信息产业有限公司 | 高可用高性能数据库集群的实现方法及系统 |
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109474465A (zh) * | 2018-11-13 | 2019-03-15 | 上海英方软件股份有限公司 | 一种基于服务器集群的可动态流转的高可用性的实现方法和系统 |
CN109839041A (zh) * | 2018-12-28 | 2019-06-04 | 北京航天测控技术有限公司 | 一种基于去中心化集群计算架构的免维护测控方法 |
CN109839041B (zh) * | 2018-12-28 | 2021-05-28 | 北京航天测控技术有限公司 | 一种基于去中心化集群计算架构的免维护测控方法 |
CN110166524A (zh) * | 2019-04-12 | 2019-08-23 | 陆金所(上海)科技服务有限公司 | 数据中心的切换方法、装置、设备及存储介质 |
CN113055427A (zh) * | 2019-12-28 | 2021-06-29 | 浙江宇视科技有限公司 | 一种基于业务的服务器集群接入方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
TWI724106B (zh) | 資料中心間的業務流量控制方法、裝置及系統 | |
CN1554055B (zh) | 高可用性集群虚拟服务器系统 | |
CN107147697A (zh) | 应用组切换方法及装置 | |
US11307943B2 (en) | Disaster recovery deployment method, apparatus, and system | |
JP4509346B2 (ja) | 無線通信ネットワークにおけるダイナミック負荷バランスの実行方法及び実行システム並びに無線通信ネットワークにおけるメッセージ処理システム | |
CN101136900B (zh) | 一种面向服务的快速透明故障转移装置及实现方法 | |
CN101571813B (zh) | 一种多机集群中主从调度方法 | |
CN100407671C (zh) | 实现网络负载分担功能的网络通信方法 | |
CN100499507C (zh) | 一种容灾系统、方法和网络设备 | |
CN102025790B (zh) | 地址分配方法、装置和系统 | |
CN104468151B (zh) | 一种集群切换时保持tcp会话的系统和方法 | |
CN104854575A (zh) | 集群会话管理 | |
CN101179432A (zh) | 一种多机环境中实现系统高可用的方法 | |
CN107465721A (zh) | 基于双活架构的全局负载均衡方法和系统及调度服务器 | |
CN103546315B (zh) | 一种dhcp服务器的备份系统、方法及设备 | |
CN101110776A (zh) | 数据业务的备份方法、备份装置与备份系统 | |
CN102098201A (zh) | 一种实现l2tp用户接入备份的方法及网络系统 | |
CN102255633B (zh) | 一种多机架用户备份的方法及系统 | |
CN102388570B (zh) | 一种主备模式下的单板运行方法及系统 | |
CN104080132A (zh) | 一种数据处理方法和设备 | |
CN104506372A (zh) | 一种实现主备服务器切换的方法及系统 | |
CN106658559B (zh) | 一种基于上下文预测的移动服务质量保持方法 | |
CN106385330B (zh) | 一种网络功能虚拟化编排器的实现方法及装置 | |
WO2012155629A1 (zh) | 网络容灾方法和系统 | |
CN104243304A (zh) | 非全连通拓扑结构的数据处理方法、设备和系统 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170908 |