CN111953808B - 一种双机双活架构的数据传输切换方法及架构构建系统 - Google Patents

Abstract

本发明公开了一种双机双活架构的数据传输切换方法及架构构建系统。所述方法包括：本机房的流量管理服务器将接收到的数据进行域名解析后传输至本机房的负载均衡服务器；本机房的负载均衡服务器判断本机房的应用服务器是否出现故障，若否，则将接收到的数据传输至本机房的应用服务器，若是，则将接收到的数据传输至远程机房的应用服务器；本机房的应用服务器将接收到的数据传输至本机房的缓存服务器和/或数据库服务器；本机房的数据库服务器通过OTV网络将数据传输至远程机房的数据库服务器。本发明通过在数据层构建OTV网络环境实现机房间数据库的信息同步，降低了机房级数据传输成本。

Description

一种双机双活架构的数据传输切换方法及架构构建系统

技术领域

本发明涉及计算机技术领域，特别涉及一种双机双活架构的数据传输切换方法及架构构建系统。

背景技术

双机双活是目前企业保持业务连续性方案的主要架构模式，主要指设置两个数据中心，两个数据中心均承担业务且互为对方的备份，当一个数据中心出现机房断电、机柜断电、光纤异常等机房级的故障时，可以及时将数据传输切换至另一个数据中心，保证业务数据传输的连续性，不影响业务的正常运转。

常见的双机双活架构包括：数据层、应用层、网络层，由于双机双活架构涉及到的硬件和软件较多，其运行时出现的问题往往也体现在多个层级上。本申请技术人员在架构运行过程中发现如下技术问题：

数据层：租用DDN、SDH、SONET等二层中间链路实现数据中心之间数据库的数据同步费用较高；

应用层：当出现机房级故障导致组件异常无法使用时，组件恢复时间较长，影响企业业务的连续性；

网络层：跨机房引流过程中传输速率不稳定，用户感知明显，对三方负载均衡服务商依赖程度较高。

发明内容

为了解决现有技术的问题，本发明实施例提供了一种双机双活架构的数据传输切换方法及架构构建系统。所述技术方案如下：

一方面，提供了一种双机双活架构的数据传输切换方法，所述方法包括：

本机房的流量管理服务器将接收到的数据进行域名解析后传输至本机房的负载均衡服务器；

本机房的负载均衡服务器判断本机房的应用服务器是否出现故障，若否，则将接收到的数据传输至本机房的应用服务器，若是，则将接收到的数据传输至远程机房的应用服务器；

本机房的应用服务器将接收到的数据传输至本机房的缓存服务器和/或数据库服务器；

本机房的数据库服务器通过OTV网络将数据传输至远程机房的数据库服务器。

进一步地，当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器还接收远程机房的应用服务器传输的数据；

本机房的缓存服务器将状态信息发送至云服务器，以便当云服务器判断本机房缓存服务器出现故障时重新选出主缓存节点，主缓存节点用于接收本机房和远程机房的应用服务器传输的缓存数据。

进一步地，本机房的流量管理服务器接收到的数据还包括：本机房的负载均衡服务器判断数据中包含外网域名后返回的数据，

包含外网域名的数据是域名解析服务器判断本机房的负载均衡服务器没有故障并在域名解析后传输至本机房的负载均衡服务器的数据。

进一步地，本机房的备用负载均衡服务器接收域名解析服务器传输的域名解析后的数据；

本机房的备用负载均衡服务器将数据传输至本机房或者远程机房的负载均衡服务器。

进一步地，所述本机房的负载均衡服务器将数据传输至应用服务器包括：

本机房的负载均衡服务器将核心数据传输至本机房或者远程机房的核心应用服务器，将非核心数据传输至本机房的非核心应用服务器；

本机房的应用服务器将接收到的数据传输至本机房的缓存服务器和/或数据库服务器，包括：

本机房的核心应用服务器分别将数据传输至数据库服务器和缓存服务器；非核心应用服务器将数据传输至缓存服务器。

另一方面，提供了一种双机双活架构的构建系统，所述系统包括：

流量管理服务器，布置在本机房，用于将接收到的数据进行域名解析后传输至本机房的负载均衡服务器；

负载均衡服务器，布置在本机房，用于判断本机房的应用服务器是否出现故障，当没有出现故障时，将接收到的数据传输至本机房的应用服务器，当出现故障时，将接收到的数据传输至远程机房的应用服务器；

应用服务器，布置在本机房，用于将接收到的数据传输至本机房的缓存服务器和/或数据库服务器；

缓存服务器，布置在本机房，用于缓存接收到的由应用服务器发出的数据；

数据库服务器，布置在本机房，用于存储接收到的由应用服务器发出的数据，以及将数据通过OTV网络同步至远程机房的数据库服务器。

进一步地，当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器，还用于接收远程机房的应用服务器传输的数据，以及

将状态信息发送至云服务器，以便当云服务器判断本机房缓存服务器出现故障时重新选出主缓存节点，主缓存节点用于接收本机房和远程机房的应用服务器传输的缓存数据。

进一步地，本机房的流量管理服务器接收到的数据为本机房的负载均衡服务器判断数据中包含外网域名后返回的数据，

包含外网域名的数据是域名解析服务器判断本机房的负载均衡服务器没有故障并将进行域名解析后传输至本机房的负载均衡服务器的数据。

进一步地，本机房的备用负载均衡服务器，用于接收域名解析服务器传输的域名解析后的数据，以及

将数据传输至本机房或者远程机房的负载均衡服务器。

进一步地，本机房的应用服务器包括：核心应用服务器和非核心应用服务器；

核心应用服务器，用于接收本机房的负载均衡服务器传输的核心数据，以及用于将核心数据分别发送至缓存服务器和数据库服务器；

非核心应用服务器，用于接收本机房的负载均衡服务器传输的非核心数据，以及用于将核心数据发送至缓存服务器。

本发明实施例提供的技术方案带来的有益效果是：

数据层：通过在数据层构建OTV网络环境实现机房间数据库的信息同步，降低了机房级数据传输成本；

应用层：通过设置核心应用服务器和非核心应用服务器，将核心数据和非核心数据分开处理，减少了组件故障后恢复的时间；

网络层：通过设置备用负载均衡服务器作为域名解析服务器的备用设备，降低了对三方负载均衡服务器上的依赖程度，将内网数据和外网数据分别解析，保证了引流过程中数据传输的稳定性。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的一种双机双活架构的数据传输切换方法流程图；

图2是本发明实施例提供的一种双机双活架构的构建系统结构示意图；

图3是本发明实施例提供的一种双机双活架构的构建系统结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在系统架构搭建中，为了避免系统架构仅部署在一个机房中存在机房故障造成业务被切断的风险，本领域技术人员通常会采取双机双活架构设计，双机房可以分别负责不同的电信运营商的数据，或者就近负责附近地域的数据。然而如背景技术所述，现有的双机双活架构存在：双机房数据层的数据库之间数据同步费用较高，应用层组件恢复时间较长，网络层对三方负载均衡服务上依赖程度较高的问题。因此为了解决上述技术问题，本发明实施例提出了一种双机双活架构的数据传输切换方法，具体技术方案如下：

如图1所示，一种双机双活架构的数据传输切换方法，包括：

S1、本机房的流量管理服务器将接收到的数据进行域名解析后传输至本机房的负载均衡服务器。

上述，流量管理服务器一般选用GTM，GTM是全局流量管理，其集成了DNS的域名智能解析功能、流量调度功能、云监控的应用服务监控功能。因此步骤S1中采用GTM解析内网域名，流量管理服务器接收到的数据包括内网系统的数据。

在一个实施例中，流量管理服务器接收到的数据还包括：本机房的负载均衡服务器判断数据中包含外网域名后返回的数据。所述包含外网域名的数据为域名解析服务器判断本机房的负载均衡服务器没有故障并在域名解析后传输至本机房的负载均衡服务器的数据，包含外网域名的数据为外网用户发出的数据。

上述，域名解析服务器可以采用DNSPOD，DNSPOD可以对下层设备进行4层探活，判断本机房的设备是否出现故障，若本机房出现故障，则将数据切换发送至远程机房，本机房没有出现故障时，将数据发送至本机房的流量管理服务器。

在一个实施例中，域名解析服务器还将解析后的数据发送至本机房的备用负载均衡服务器。本机房的备用负载均衡服务器接收域名解析服务器传输的域名解析后的数据；本机房的备用负载均衡服务器将数据传输至本机房或者远程机房的负载均衡服务器。

上述，备用负载均衡服务器可以采用SLB，SLB为企业自有负载均衡服务器，其和DNSPOP采用相同配置，当DNSPOP服务器出现故障时，可以快速把域名切换到SLB设备来保障服务正常运行。

需要说明的是，步骤S1中的域名解析服务器、流量管理服务器、负载均衡服务器、备用负载均衡服务器，均属于架构中的网络层。通过上述网络层涉及，能够解决网络层数据传输速率不稳定，对三方负载均衡服务商依赖程度较高的问题。

S2、本机房的负载均衡服务器判断本机房的应用服务器是否出现故障，若否，则将接收到的数据传输至本机房的应用服务器，若是，则将接收到的数据传输至远程机房的应用服务器。

上述，负载均衡服务器一般选用F5或者Nginx，其中F5可以实现基于单边大部分节点故障下跨机房业务数据引流，以及双活非对称部署下的跨机房业务数据引流，Nginx仅能实现双活非对称部署下的跨机房业务数据引流。F5和Nginx均能实现架构的健康检查及故障切换，因此采用F5或者Nginx可以实现上述步骤S2中公开的方法。需要说明的是：当数据为内网数据时，负载均衡服务器仅能是F5。进一步地，本机房部署的F5或者Nginx为进行了4层探活的服务器。应用服务器通常选用Jboss，Jboss是一种web服务器。进一步地，应用服务器为进行了7层探活的服务器。进一步地，本机房的应用服务器和远程机房的应用服务器可以通过NAS实现核心链路解耦。

在一个实施例中，本机房中设置核心应用服务器和非核心应用服务器，远程机房中仅设置核心应用服务器。因此步骤S2本机房的负载均衡服务器将数据传输至应用服务器包括：

本机房的负载均衡服务器将核心数据传输至本机房或者远程机房的核心应用服务器，将非核心数据传输至本机房的非核心应用服务器。

对于远程机房，若远程机房的负载均衡服务器判断接收到的数据为非核心数据，则将非核心数据跨机房传输至本机房的非核心应用服务器。

上述，采用的是应用服务器的非对称部署。核心数据和非核心数据分开传输，能够有效降低应用服务器的处理压力，核心数据双机房处理，保证了当出现故障时核心数据的可切换，跨机房数据传输的延迟对非数据来说无关紧要，因此仅在本机房部署非核心应用服务器，将非核心数据跨机房传输，节约了成本。

S3、本机房的应用服务器将接收到的数据传输至本机房的缓存服务器和/或数据库服务器。

在一个实施例中，步骤S3包括：本机房的核心应用服务器分别将数据传输至数据库服务器和缓存服务器；非核心应用服务器将数据传输至缓存服务器。

上述，核心数据和非核心数据分别存储，非核心数据仅存储在缓存数据库中，节省了数据库的存储空间，当需要访问非核心数据时，无需访问数据服务器，也提高了数据的访问速度。

在一个实施例中，当本机房运行正常时，本机房的缓存服务器为主缓存节点，本机房的应用服务器和远程机房的应用服务器均将数据传输至主缓存节点缓存。为了实现出现机房级故障时，数据的跨机房切换，本发明实施例设置云服务器(zookeeper)参与主节点选举。因此，当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器还接收远程机房的应用服务器传输的数据；

本机房的缓存服务器将状态信息发送至云服务器，以便当云服务器判断本机房缓存服务器出现故障时重新选出主缓存节点，主缓存节点用于接收本机房和/或远程机房的应用服务器传输的缓存数据。

上述，云服务器仅参与主缓存节点的选举，并不提供业务服务。

需要说明的是，步骤S2和步骤S3中涉及到的应用服务器和缓存服务器均属于架构中的应用层，通过应用服务器的非对称布置，将核心数据和非核心数据分开存储，能够减小组件的恢复时间。

S4、本机房的数据库服务器通过OTV网络将数据传输至远程机房的数据库服务器。

上述，OTV网络是一种能够将多个数据中心互联，并将互联的三层网络模拟成二层网络的技术，也称为二层扩展技术。相对于传统的二层的数据传输链路，其费用要便宜很多。

需要说明的是，步骤S4中数据库服务器数据架构中的数据层。数据层通过构建OTV网络环境降低机房之间数据库数据同步的成本。

需要说明的是：在步骤S2中，本机房的负载均衡服务器判断本机房出现故障后，将数据传输到远程机房的应用服务器后数据在远程机房中的传输过程，同步骤S3、S4，但其步骤中所述的本机房实质指远程机房。

基于上述双机双活架构的数据传输方法，本发明实施例还提供一种双机双活架构的构建系统，具体技术方案如下：

如图2所示，一种双机双活架构的构建系统，包括：

流量管理服务器，布置在本机房，用于将接收到的数据进行域名解析后传输至本机房的负载均衡服务器。

上述，流量管理服务器采用GTM。

如图3所示，在一个实施例中，流量管理服务器接收到的数据包括：内网数据和外网数据，对于内网数据直接将其传输至本机房的负载均衡服务器。对于外网数据，由域名服务器接收，进行域名解析，流量管理服务器接收到的数据为本机房的负载均衡服务器判断数据中包含外网域名后返回的数据，包含外网域名的数据是域名解析服务器判断本机房的负载均衡服务器没有故障并将进行域名解析后传输至本机房的负载均衡服务器的数据。

上述域名解析服务器采用DNSPOD。

如图3所示，在一个实施例中，上述系统还包括：备用负载均衡服务器。本机房的备用负载均衡服务器，用于接收域名解析服务器传输的域名解析后的数据，以及将数据传输至本机房或者远程机房的负载均衡服务器。

上述，备用负载均衡服务器采用SLB，SLB为企业自有负载均衡服务器。

负载均衡服务器，布置在本机房，用于判断本机房的应用服务器是否出现故障，当没有出现故障时，将接收到的数据传输至本机房的应用服务器，当出现故障时，将接收到的数据传输至远程机房的应用服务器。

上述，负载均衡服务器采用F5或者Nginx。F5和Nginx均能实现架构的健康检查及故障切换。需要说明的是：当故障时，采用F5实现跨机房自动引流。

应用服务器，布置在本机房，用于将接收到的数据传输至本机房的缓存服务器和/或数据库服务器。进一步地，本机房的应用服务器和远程机房的应用服务器可以通过NAS作为附件服务器，通过异步复制的方式保证本机房和远程机房的数据同步。

上述应用服务器采用Jboss(web服务器)。

在一个实施例中，本机房的应用服务器包括：核心应用服务器和非核心应用服务器。远程机房的应用服务器仅包括：核心应用服务器。

核心应用服务器(Jboss(A))，用于接收本机房的负载均衡服务器传输的核心数据，以及用于将核心数据分别发送至缓存服务器和数据库服务器；

非核心应用服务器(Jboss(B))，用于接收本机房的负载均衡服务器传输的非核心数据，以及用于将核心数据发送至缓存服务器。

缓存服务器，布置在本机房，用于缓存接收到的由应用服务器发出的数据。

上述，缓存服务器采用Redis-Cluster。

在一个实施例中，当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器，用于接收本机房的核心应用服务器传输的核心数据，以及本机房的非核心应用服务器传输的非核心数据。

在一个实施例中，当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器，还用于接收远程机房的应用服务器传输的数据，以及将状态信息发送至云服务器，以便当云服务器判断本机房缓存服务器出现故障时重新选出主缓存节点，主缓存节点用于接收本机房和远程机房的应用服务器传输的缓存数据。

数据库服务器，布置在本机房，用于存储接收到的由应用服务器发出的数据，以及将数据通过OTV网络同步至远程机房的数据库服务器。

上述，数据库服务器采用DB服务器。

本发明实施例提供的技术方案带来的有益效果是：

数据层：通过在数据层构建OTV网络环境实现机房间数据库的信息同步，降低了机房级数据传输成本；

应用层：通过设置核心应用服务器和非核心应用服务器，将核心数据和非核心数据分开处理，减少了组件故障后恢复的时间；

网络层：通过设置备用负载均衡服务器作为域名解析服务器的备用设备，降低了对三方负载均衡服务器上的依赖程度，将内网数据和外网数据分别解析，保证了引流过程中数据传输的稳定性。

上述所有可选技术方案，可以采用任意结合形成本发明的可选实施例，在此不再一一赘述。

以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (7)

1.一种双机双活架构的数据传输切换方法，其特征在于，包括：

本机房的流量管理服务器将接收到的数据进行域名解析后传输至本机房的负载均衡服务器；

本机房的负载均衡服务器判断本机房的应用服务器是否出现故障，若否，则将接收到的数据传输至本机房的应用服务器，若是，则将接收到的数据传输至远程机房的应用服务器；

本机房的应用服务器将接收到的数据传输至本机房的缓存服务器和/或数据库服务器；

本机房的数据库服务器通过OTV网络将数据传输至远程机房的数据库服务器；

当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器还接收远程机房的应用服务器传输的数据；

本机房的缓存服务器将状态信息发送至云服务器，以便当云服务器判断本机房缓存服务器出现故障时重新选出主缓存节点，主缓存节点用于接收本机房和远程机房的应用服务器传输的缓存数据；

所述本机房的负载均衡服务器将数据传输至应用服务器包括：

本机房的负载均衡服务器将核心数据传输至本机房或者远程机房的核心应用服务器，将非核心数据传输至本机房的非核心应用服务器；

本机房的应用服务器将接收到的数据传输至本机房的缓存服务器和/或数据库服务器，包括：

本机房的核心应用服务器分别将数据传输至数据库服务器和缓存服务器；非核心应用服务器将数据传输至缓存服务器。

2.如权利要求1所述的方法，其特征在于，

本机房的流量管理服务器接收到的数据还包括：本机房的负载均衡服务器判断数据中包含外网域名后返回的数据，

包含外网域名的数据是域名解析服务器判断本机房的负载均衡服务器没有故障并在域名解析后传输至本机房的负载均衡服务器的数据。

3.如权利要求2所述的方法，其特征在于，所述方法还包括：

本机房的备用负载均衡服务器接收域名解析服务器传输的域名解析后的数据；

本机房的备用负载均衡服务器将数据传输至本机房或者远程机房的负载均衡服务器。

4.一种实现如权利要求1所述双机双活架构的数据传输切换方法的双机双活架构的构建系统，其特征在于，包括：

流量管理服务器，布置在本机房，用于将接收到的数据进行域名解析后传输至本机房的负载均衡服务器；

负载均衡服务器，布置在本机房，用于判断本机房的应用服务器是否出现故障，当没有出现故障时，将接收到的数据传输至本机房的应用服务器，当出现故障时，将接收到的数据传输至远程机房的应用服务器；

应用服务器，布置在本机房，用于将接收到的数据传输至本机房的缓存服务器和/或数据库服务器；

缓存服务器，布置在本机房，用于缓存接收到的由应用服务器发出的数据；

数据库服务器，布置在本机房，用于存储接收到的由应用服务器发出的数据，以及将数据通过OTV网络同步至远程机房的数据库服务器；

当本机房的缓存服务器为主缓存节点时，本机房的缓存服务器，还用于接收远程机房的应用服务器传输的数据，以及

将状态信息发送至云服务器，以便当云服务器判断本机房缓存服务器出现故障时重新选出主缓存节点，主缓存节点用于接收本机房和远程机房的应用服务器传输的缓存数据。

5.如权利要求4所述的系统，其特征在于，本机房的流量管理服务器接收到的数据为本机房的负载均衡服务器判断数据中包含外网域名后返回的数据，

包含外网域名的数据是域名解析服务器判断本机房的负载均衡服务器没有故障并将进行域名解析后传输至本机房的负载均衡服务器的数据。

6.如权利要求5所述的系统，其特征在于，本机房的备用负载均衡服务器，用于接收域名解析服务器传输的域名解析后的数据，以及

将数据传输至本机房或者远程机房的负载均衡服务器。

7.如权利要求4～6所述的系统，其特征在于，本机房的应用服务器包括：核心应用服务器和非核心应用服务器；

核心应用服务器，用于接收本机房的负载均衡服务器传输的核心数据，以及用于将核心数据分别发送至缓存服务器和数据库服务器；

非核心应用服务器，用于接收本机房的负载均衡服务器传输的非核心数据，以及用于将核心数据发送至缓存服务器。