运营商容灾备份研究及其关键技术应用

2019-10-21孙淳晔

互联网天地 2019年8期

□ 文孙淳晔梁杨

运营商业务支撑系统主要面向客户服务和业务管理，随着近年来的不断建设、发展、完善，已从企业内部IT系统转型为开放的移动互联网节点，成为客户运营的核心和连接数字化服务的纽带，新形势下的竞争环境、业务、客户、产品和网络的变化都对现有的系统架构带来巨大挑战，实现系统架构的稳定可靠性，保证业务连续性，以便更好地支撑市场拓展及客户服务的发挥显得极为必要。

为实现业务的连续性保障，制度上应建立风险防控手段、应急管理办法措施进行规避，技术上通过建立容灾、备份等应急保障实现。本文通过调研部分省份的容灾技术选择，详细分析了技术原理及特点，针对某省公司现网单中心的现状提出了双中心建设方案。

应急保障措施按照由低到高程度主要分为双机、集群、备份、应急、容灾几个层次。

1、建设目的

运营商进行容灾备份建设主要出于以下目的：

系统安全运行需求

单生产环境做到的应急保障程度有限，一旦发生自然灾害，大面积且长时间停电等不可抗拒因素会造成系统瘫痪，影响公司整体收入，造成严重社会影响。

运营、运维连续性需求

单生产环境进行业务升级时为避免可能造成的日常营业影响，通常会采用较短的上线窗口，造成上线范围有限，此外部分升级还需中断业务，影响业务连续性。对于系统的升级无法快速响应，难以满足市场快速支撑响应。

此模式下的升级多采用夜间上线升级，以人工操作为主，效率不高且易出错，不具备可视化运维能力，对支撑人员造成严重压力。

系统架构演进需求

云化时代，工程投资精细化，投入产出数字化，保持系统的稳定、安全、可扩展性显得至关重要，容灾建设模式架构合理，符合演进趋势，正常状态负荷分担，资源复用，降低系统压力，提高设备利用率；发生系统重大故障或灾难时实现应用接管，起到容灾作用。

2、应急保障分类

应急保障措施按照由低到高程度主要分为双机、集群、备份、应急、容灾几个层次。双机、集群涉及范围最小，主要为单个业务或应用模块的保障，其中双机又分为双机HA，负载均衡模式，集群主要指集群主机共同完成某项任务并能自动化实现宕机的业务接管。

备份保障直接面向基础数据，主要是在单个数据中心内实现关键数据的备份，承载介质多为带库，虚拟带库以及各类分布式存储等，备份为粒度最小的应急保障，也是最易实现、投资最少的方式，常用的备份工具有Networker、NBU等商业备份软件等。

应急面向对象为系统级或平台级，目的在于故障发生时通过主备系统快速切换，实现业务的连续性保障、达到客户无感知的目的，应急的范围一般局限于单个数据中心内的核心系统，覆盖底层数据库至应用层，需单独的设备物理隔离部署，应充分考虑与生产设备在机房、供电等配套资源的区分，以实现保障程度的最大化。

容灾为最高级的应急保障机制，也是投资最高的建设模式。容灾建设在物理格局上可分为多地多中心模式、同城多中心模式，运营模式上有冷备、热备、双活、多活等方式，功能架构上划分全量和降级容灾模式建设，进行容灾建设最为关键的是解决了风、火、雷、电等自然灾害带来的风险，在灾难发生时实现业务的快速切换，并尽量缩短RPO和RTO，以保证业务连续性、减少经济损失、保障客户利益为最终目的。本文仅就保障级别最高的容灾技术进行研究分析，并以双中心双活模式进行说明。

3、建设模式

进行双中心容灾建设首先考虑第二中心的配套问题，具备数据中心机房的各类资源保障条件，具备良好的扩展性，连续的空调制冷环境，独立冗余的电力保障以及中心间可靠的传输条件等。除物理配套因素外，系统的技术选型、业务逻辑也至关重要，目前双中心建设功能上存在两种分类：

垂直划分

垂直划分是以业务功能为单位进行划分，根据业务功能的特性，按业务耦合程度在生产中心和容灾中心分别运行不同的应用，同时向另一中心同步数据，如图1、图2所示。

在实现数据级容灾的基础上，任一中心出现灾难时，另一个中心接管全部业务，相应的双中心数据复制以应用维度进行复制。

水平划分

水平划分是以地域为单位进行划分，根据用户归属，分别在生产中心和容灾中心运行完整的系统，正常情况下某一中心只负责处理归属用户的业务（跨地区业务除外），同时向另一中心同步数据，如图3、图4所示。

当任一中心出现灾难时，另一个中心接管全部业务，相应的双中心数据复制以地市维度进行复制。

4、关键技术研究

应急保障是一个系统工程，需要双中心接入层、应用层、数据层、存储层分别设置访问策略及切换机制，同时保证数据的安全备份机制。

接入层、应用层主要依赖IP地址、DNS域名等配置解决，而涉及应用层以下则需要专门的同步复制工具，目前主流方向有三种：基于存储复制、基于数据库日志复制、基于数据库的复制，如图5所示。

图1 垂直划分模式

图3 水平划分模式

图2 垂直划分同步

图4 水平划分同步

图5 双中心总体架构

存储复制：通过存储控制或者虚拟卷控制实现数据在存储设备之间的复制；所有的数据变化在两个站点进行镜像。

数据库日志复制：由数据库系统的辅助程序或第三方工具，逆向解析数据库交易日志并施行于远端数据库完成数据复制。

应急保障是一个系统工程，需要双中心接入层、应用层、数据层、存储层分别设置访问策略及切换机制，同时保证数据的安全备份机制。

数据库复制：由数据库系统软件完成数据复制，复制的粒度是数据库内数据操纵动作，复制涉及的范围为单个数据库。

“’互动性’存在于口语交际的各个环节和话语理解的各个层面”，是指参与语言交流的双方在口语交际中形成听和说的交互作用。

为实现某省公司的容灾建设，充分考虑了兄弟省份的建设经验，调研了部分省份的在用技术，结果如表1所示：

针对上述省份的技术选型，对三类流派技术从以下维度进行了分析，如表2所示：

各类同步复制产品特点差距较大，对现网环境依赖性也不同，而大多数省份已考虑了应急保障的建设，但近年来新的数据中心启用则需要各个省公司情根据现网实际情况及业务读写要求选择适合的同步产品，以下针对各产品的进行了总结建议，如表3所示。

表1 部分省份同步复制技术选择

表2 同步复制技术对比

表3 技术使用场景分析

图6 整体架构图

5、两地双中心建设方案

针对某运营商目前单数据中心的实际情况以及迫切建设第二中心的需求，结合在网在用数据库产品及存储产品，采用基于数据库的同步复制技术进行双中心双活容灾建设，对各层的配置分析如下，如图6所示。

自顶而下划分渠道层、接入层、应用中心层及数据层，分别设置不同的接入方式和切换机制，双中心间提供网络层、存储网络层的双链路、高带宽保障。

主机按等量部署在双中心，单中心内根据不同外部访问入口划分多个集群，在WEB层设置DNS，根据请求源地址与两个中心IP的对应关系，将不同地市的访问请求转发到不同的中心进而访问对应中心的WEB集群。

当WEB集群组1内的一台主机发生故障时，由集群机制保障WEB集群组1内的其他主机承担其负载的访问请求；当WEB集群组1内的主机大面积发生故障时，通过策略调整DNS解析配置，使所有请求切换到第二中心内，确保业务不间断。

应用层

物理上两个机房分别部署主机，应用逻辑上跨机房集群部署形成统一的应用支撑中心。

WEB层通过解析用户属性与归属地市映射关系，归属路由请求通过客户端访问控制机制，执行客户分组的访问策略，将WEB请求指向对应应用中心集群。

原则上客户端访问应用中心集群组采取就近策略访问本局应用中心，当应用集群组内的服务器发生故障时，由集群机制保障应用集群组内的其他服务器能够承担其负载的请求量，当本中心获取不到较近的应用服务器地址，自动将请求指向对端应用中心集群组，确保业务连续性。

数据层

现网一中心某核心系统采用的是Oracle数据库，由于第二中心所购设备按照第一中心同构等量考虑，按照全量1:1考虑全量灾备建设，优先考虑数据库性能影响及数据坏块的处理机制，选用Oracle ADG技术进行双中心同步技术，双中心数据库主备库跨机房交叉部署，一中心部署A主库、B备库，二中心部署A备库、B主库。

每个业务应用存在两个或多个数据库连接。根据访问主备库要求，设定数据库DNS可解析的IP地址；用于优先访问备库的连接将备库IP地址设为首选，用于优先访问主库的连接将主库IP地址设为首选。注册服务与主备优先连接设定关联关系，按照对应策略从对应的连接池中获取数据库连接。数据主库出现故障，可通过人工干预或根据策略进行自动切换。

单中心数据库通过RAC实现高可用，双中心通过第三方数据同步软件保障主库与备库的数据一致性。双中心的数据同时可读写，数据相互备份，并且在其中一个中心出现异常的时候，对端中心可以马上接管。

双活模式下的应用升级：基于分布式中心架构，只要不涉及数据库变更，应用变更或升级可以通过在线方式升级，保证业务不中断。利用双中心的在线切换机制，即便涉及数据库变更的升级，也可以做到在线升级，保障业务不中断。