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

一种双机双活架构的数据传输切换方法及架构构建*** Download PDF

Info

Publication number
CN111953808B
CN111953808B CN202010757379.6A CN202010757379A CN111953808B CN 111953808 B CN111953808 B CN 111953808B CN 202010757379 A CN202010757379 A CN 202010757379A CN 111953808 B CN111953808 B CN 111953808B
Authority
CN
China
Prior art keywords
machine room
server
data
load balancing
cache
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
CN202010757379.6A
Other languages
English (en)
Other versions
CN111953808A (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.)
Shanghai Yanxi Software Information Technology Co ltd
Original Assignee
Shanghai Yanxi Software Information Technology Co ltd
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 Shanghai Yanxi Software Information Technology Co ltd filed Critical Shanghai Yanxi Software Information Technology Co ltd
Priority to CN202010757379.6A priority Critical patent/CN111953808B/zh
Publication of CN111953808A publication Critical patent/CN111953808A/zh
Application granted granted Critical
Publication of CN111953808B publication Critical patent/CN111953808B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/45Network directories; Name-to-address mapping
    • H04L61/4505Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/09Mapping addresses
    • H04L61/10Mapping addresses of different types
    • H04L61/103Mapping addresses of different types across network layers, e.g. resolution of network layer into physical layer addresses or address resolution protocol [ARP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Hardware Redundancy (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

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所述的***,其特征在于,本机房的应用服务器包括:核心应用服务器和非核心应用服务器;
核心应用服务器,用于接收本机房的负载均衡服务器传输的核心数据,以及用于将核心数据分别发送至缓存服务器和数据库服务器;
非核心应用服务器,用于接收本机房的负载均衡服务器传输的非核心数据,以及用于将核心数据发送至缓存服务器。
CN202010757379.6A 2020-07-31 2020-07-31 一种双机双活架构的数据传输切换方法及架构构建*** Active CN111953808B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202010757379.6A CN111953808B (zh) 2020-07-31 2020-07-31 一种双机双活架构的数据传输切换方法及架构构建***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010757379.6A CN111953808B (zh) 2020-07-31 2020-07-31 一种双机双活架构的数据传输切换方法及架构构建***

Publications (2)

Publication Number Publication Date
CN111953808A CN111953808A (zh) 2020-11-17
CN111953808B true CN111953808B (zh) 2023-08-15

Family

ID=73338983

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202010757379.6A Active CN111953808B (zh) 2020-07-31 2020-07-31 一种双机双活架构的数据传输切换方法及架构构建***

Country Status (1)

Country Link
CN (1) CN111953808B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11461315B2 (en) 2020-12-03 2022-10-04 International Business Machines Corporation Batch job performance improvement in active-active architecture
CN112929429B (zh) * 2021-01-27 2023-03-24 长沙市到家悠享网络科技有限公司 请求处理方法、装置和设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1905460A (zh) * 2005-07-29 2007-01-31 上海恩梯梯通信工程有限公司 高级隔离区网络***
CN103973788A (zh) * 2014-05-08 2014-08-06 浪潮电子信息产业股份有限公司 一种基于传输遍布式网络架构的负载均衡方法
WO2017162184A1 (zh) * 2016-03-25 2017-09-28 阿里巴巴集团控股有限公司 数据中心间的业务流量控制方法、装置及***
CN107465721A (zh) * 2017-06-27 2017-12-12 国家电网公司 基于双活架构的全局负载均衡方法和***及调度服务器
CN107918570A (zh) * 2017-10-20 2018-04-17 杭州沃趣科技股份有限公司 一种双活***共享仲裁盘的方法
CN110083662A (zh) * 2019-05-15 2019-08-02 国网江西省电力有限公司信息通信分公司 一种基于平台***的双活架构建设方法
CN110175089A (zh) * 2019-05-17 2019-08-27 国电南瑞科技股份有限公司 一种具有读写分离功能的双活灾备***

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1905460A (zh) * 2005-07-29 2007-01-31 上海恩梯梯通信工程有限公司 高级隔离区网络***
CN103973788A (zh) * 2014-05-08 2014-08-06 浪潮电子信息产业股份有限公司 一种基于传输遍布式网络架构的负载均衡方法
WO2017162184A1 (zh) * 2016-03-25 2017-09-28 阿里巴巴集团控股有限公司 数据中心间的业务流量控制方法、装置及***
CN107465721A (zh) * 2017-06-27 2017-12-12 国家电网公司 基于双活架构的全局负载均衡方法和***及调度服务器
CN107918570A (zh) * 2017-10-20 2018-04-17 杭州沃趣科技股份有限公司 一种双活***共享仲裁盘的方法
CN110083662A (zh) * 2019-05-15 2019-08-02 国网江西省电力有限公司信息通信分公司 一种基于平台***的双活架构建设方法
CN110175089A (zh) * 2019-05-17 2019-08-27 国电南瑞科技股份有限公司 一种具有读写分离功能的双活灾备***

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
国网客服中心异地双活***GTM全局负载均衡方法;杨维等;《微型电脑应用》;20200620(第06期);全文 *

Also Published As

Publication number Publication date
CN111953808A (zh) 2020-11-17

Similar Documents

Publication Publication Date Title
CN107465721B (zh) 基于双活架构的全局负载均衡方法和***及调度服务器
US8775589B2 (en) Distributed network management system and method
CN109474465A (zh) 一种基于服务器集群的可动态流转的高可用性的实现方法和***
CN111953808B (zh) 一种双机双活架构的数据传输切换方法及架构构建***
CN102710457B (zh) 一种跨网段的n+1备份方法及装置
CN112583648B (zh) 一种基于dns的智能服务故障处理方法
CN111130835A (zh) 数据中心双活***、切换方法、装置、设备及介质
CN111949444A (zh) 一种基于分布式服务集群的数据备份与恢复***及方法
CN110635950A (zh) 一种双数据中心容灾***
CN107404394A (zh) 一种iptv***容灾方法及iptv容灾***
CN111309515B (zh) 一种容灾控制方法、装置及***
CA2401635A1 (en) Multiple network fault tolerance via redundant network control
US20050234919A1 (en) Cluster system and an error recovery method thereof
AU2001241700A1 (en) Multiple network fault tolerance via redundant network control
CN102487332B (zh) 故障处理方法、装置和***
US20110191626A1 (en) Fault-tolerant network management system
CN111708843A (zh) 一种基于MGR的跨数据中心MySQL多活实现方法
CN111460029A (zh) 数据同步方法和装置
CN110677316A (zh) 一种分布式存储服务器网卡检测方法和***
CN116346582A (zh) 一种实现主备双网冗余方法、装置、设备及存储介质
RU2596999C1 (ru) Способ и устройство для обработки отказов одиночного оптического волокна
CN115549775A (zh) 光信号传输异常的处理方法、光传输设备及***
CN111510336B (zh) 一种网络设备状态管理方法及装置
CN111669452B (zh) 一种基于多主dns架构的高可用方法及装置
CN115348600A (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
GR01 Patent grant
GR01 Patent grant