一种同城双活容灾系统设计与实现

2018-10-29金安

软件导刊 2018年8期

金安

摘要：随着互联网企业业务的持续增长，为降低运营风险，容灾系统建设势在必行。在阐述容灾系统概念的基础上，针对企业业务与生产环境现状，充分考虑到容灾系统的目标与范围，设计并实现了一套同城双活容灾系统，并对事务冲突机制、高可用服务架构、注册发现与内网DNS等关键技术要点进行了阐述。3次演练结果证明，该方案在设计的规定指标内，当生产机房出现整体故障时，容灾系统可以在很短时间内接管原机房的所有服务，有效保障了数据一致性及业务持续性。

关键词：

容灾；RTO；PRO；NRO；软件事务存储

DOIDOI：10.11907/rjdk.181946

中图分类号：TP319

文献标识码：A 文章编号文章编号：1672-7800（2018）008-0149-04

英文摘要Abstract：With the continuous growth of an Internet business， the disaster recovery system construction is imperative to reduce the risk of operations. Based on the concept of disaster system， according to current situation of the enterprise business and production environment， and fully considering the goal and scope of the system， we design and implement a suitable set of dual city disaster recovery system for the company. In this paper， key technical points such as transaction conflict mechanism， HA service architecture， registration discovery and Intranet DNS are also explained. Three disaster recovery drill results prove that the scheme ensures the business continuity and data consistency effectively within the design indexes. The system can take over all services in a very short time when faults occur.

英文關键词Key Words：disaster recovery system；RTO；RPO；NRO；software transactional memory

0 引言

随着移动互联网技术的发展，数据本身已成为企业生存与竞争的核心价值所在。据IDC报告预测，2020年全球数据量将从目前的8.6ZB增长到40ZB，其中我国占比为13%。因此，一个国家拥有的数据规模与数据分析能力将成为综合国力的重要部分，对数据的存储、处理、分析及使用也成为国家间、企业间新的竞争焦点[1]。

不可抗力与人为失误等原因都会给企业带来毁灭性打击，从一份安盛公司的报告得出，80%以上的中小企业在遭受重大灾难后的18个月内都面临破产或业务难以为继的困境，同时伴随着巨额的财产和名誉损失，所以保障数据安全性与业务连续性已成为信息化工作的重中之重。文献[2]-[3]基于IOE架构设计并实现了容灾系统；文献[5]-[6]采用CDP实时数据保护技术有效保障了业务的连续性。然而，对于大型互联网系统，完全基于SAN网络架构已不能满足大数据同步的需求。文献[7]-[8]分别提出一种缓存写操作重放技术与基于RS编码技术的数据存储方式，为本文容灾系统的数据同步与存储提供了很好的参考；文献[9]-[10]分析了国内信息系统演练中存在的问题，从理论上完善了容灾演练建设制度。

本文以某互联网公司为例，针对该企业业务特点，并考虑TCO因素，在规范化系统等级制度的基础上，设计一种基于事务冲突机制与高可用架构等技术特点的同城双活容灾系统，并建立了一套良好的演练机制，以保障业务的连续性需求。

1 容灾系统概述

1.1 容灾系统定义与分类

容灾系统定义为：建立至少两套以上功能相同的系统，相互之间可以进行健康状态检查与功能切换[11]。根据对系统的保护程度，容灾系统可分为数据级别与业务级别容灾。从地域建设模式来看，可分为同城容灾、异地容灾和两地三中心容灾3种模式。

数据层容灾是业务层容灾的基础，业务层容灾是数据层容灾的终极目标，容灾建设应以数据容灾为根本，以业务持续性为目标，最终实现灾难发生时业务的平稳过渡，并保证企业的安全生产[12]。

1.2 容灾系统恢复能力指标

容灾系统恢复能力主要采用RTO、RPO、NRO 3个指标作为评判依据[13]。RTO是容灾恢复的时间指标，RTO越小，意味着容灾能力越强；RPO是指针对数据而言，恢复业务后所能容忍的数据丢失量；NRO是指灾难发生后，最终用户通过备用网络访问灾备中心所需的时间[11]。三者时序关系如图1所示。

事实证明，快速收敛聚合的网络可以为业务与数据迁移提供可靠的传输路径[14]。除DNS解析生效外，NRO都要做到超前于RTO，这点在本文的容灾演练中可以得到验证。

2 同城双活容灾系统方案设计与实现

2.1 业务与生产环境现状

该互联网企业平台系统注册账号为5亿以上，每天的活跃登录用户3 000万左右，登录TPS峰值20 000次以上，平均响应时间40ms，登录成功率为90%左右，业务涵盖注册、认证、登录、风控、计费、支付、客服与短信等系统，每天新增业务数据50G左右，日志量500T以上。该系统生产环境部署在A机房，其中有生产机器1 000台以上，包括四七层代理转发、业务、缓存、数据库、消息队列、日志流分析等集群。

虽然系统符合业界SOA规范，架构可以横向扩展，但是随着业务增长需要不断叠加模块与机器的做法，机房一旦发生灾难，对业务和系统将带来毁灭性打击[15]。

2.2 容灾系统目标与范围

依据灾难恢复等级标准，结合该企业互联网业务量特点，对系统恢复的优先级作出分类，将不可绕过服务均定义为核心系统，根据顺序等级进行恢复。对于可绕过服务，可进行柔性降级处理或低等级容灾恢复。关键服务灾难恢复能力需达到6级，对应RTO<30min，RPO=0，NRO

考虑到TCO与ROI指标，决定采用同城双活模式，按照业务策略比例共同对外提供服务，以避免系统闲置造成浪费，必要时可将对外服务能力提高到双倍。在提高利用率的同时，可以降低系统切换时间，以减少灾难影响程度并降低用户感知度[16]。

2.3 容灾系统方案设计

一个完整的容灾系统由数据备份、备用数据处理、备用网络、备用基础设施、技术支持、运行维护支持与灾难恢复预案7大技术管理要素组成[13]。对于大型互联网系统而言，业务级容灾还涉及到业务监控、配套安全、日志采集分析、权限控制与业务授权等，容灾设计难度远大于传统行业。

根据系统工程方法论，容灾可分为图2中所描述的7大步骤。本文仅对方案设计、关键技术实现与容灾演练进行阐述。

该互联网企业在上海有10大机房，平台系统部署在生产A机房，为实现同城双活容灾系统，除新建容灾B机房外，需将各大机房间的网络形成环状，机房之间用双路裸光纤连接，即使AB机房两路光纤中断，网络也可自动通过反向路由到达。由于机房数据同步量大，为保证数据同步的实时性，专线带宽为4万兆。

通过GSLB和SmartDNS系统对业务访问流量进行AB机房双活导入。LB和四七层代理可进行业务规则分流与逻辑控制，系统根据最小化功能特点细分为接入层、逻辑层、原子层、数据层与存储层等集群。数据层涵盖了缓存与落地数据，存储介质分为传统/分布式存储、HDFS集群与本地文件系统等。架构设计如图3所示。

3 容灾系统实现关键技术

3.1 数据同步备份与事务冲突算法

对于容灾系统而言，数据的一致性与延迟性问题是必须解决的技术问题。根据业务场景不同，数据同步分为两种，双机房读写分离与双机房实时读写。为达到最佳同步效果，对于峰值压力，在业务层将数据操作频率放入队列进行控制，以做到平滑过渡。另外，可以通过DB层透传打标事务的方式避免数据循环复制。除常用的同步技术外，借鉴业界经验，还实现了一种基于事务冲突的检查方法，可较好地处理事务的并发逻辑同步[17]。

事务冲突机制借鉴Bloom Filter的原理，使用k个Hash函数，每个字符串与k个bit对应，当前位串中存储元素超过一定误判率下能够容纳的个数时，增加新的相同长度位串，并将新元素加入到新位串中[18]。根据布隆过滤器原理与算法，经过推导的最终公式如下：

k为Hash函数个数，m为位串长度，f为可以接受的错误率，n为f下长度为m的位串至多可容纳的元素个数[19-20]。例如，如果错误率为8*10-5，则此时m应大约为n的20倍，k大约为10个。为了比较事务读写集合是否存在交集，通常通过事务的Signature（简称Sig）取交集加以判定。目前开源STM中实现的是RingSTM SW算法，其是基于Sig监测事务冲突的，但系统中同时只允许一个事务写Sig运行[21-22]。在本文中，事务每读取或写入一个共享变量时，将该变量写入读或写Sig中，当进行冲突检测时，调用比较Sig函数对事务间读写集合的Sig进行比较，便可迅速判定二者是否冲突。该优化检测算法将采用更有效的Hash函数与动态长度Sig降低误判率，尽可能降低对存储的需求，提高检测效率，对于该算法本文不再赘述。

对于数据传输的有序与完整性，分别采用管道技术与基于Hash算法快速定位时间戳的最早日志方式加以确保。为保证数据的正确性，也使用了本地回放机制与多重校验机制。

为安全起见，数据库采用安全协议SSHFS，通过备份中转机备份数据到HDFS，中转机与HDFS之间采用FUSE-DFS进行挂载。另外，定期将数据自动导入数据库，用自动化工具自动校验数据的正确性，并以报告的方式给出结果。

3.2 高可用服务架构

为提高容灾系统的可靠性与灵活性，运维在汇聚层、机柜与电源等方面对相同服务的集群硬件进行容错放置。软件层次上应对程序设置超时策略，以快速转移故障并进行资源释放，并使用消息队列集群对服务进行异步调用。在访问高峰期，为避免大量并发调用影响其它核心服务使用，采取柔性降级处理，以保证核心服务对外不中断。对于业务调用失败或重复调用的情况，业务层应保证服务必须拥有幂等性属性。对于TCP服务集群，只需在调用端配置几个VIP即可做到双机房之间的自动漂移，调用方只要嵌入调用SDK的相关接口即可。

3.3 注册发现框架

容灾建设前，各个服务具有独立的自我描述文件，在线上更新时除更新描述业务配置外，还需更新IP与端口等运维信息，导致维护时较为困难。为提高效率并實现容灾切换的便捷性，设计服务注册发现系统如图4所示。

注册发现系统由注册中心SRC、服务消费者SC与服务提供者SP 3部分组成，SRC管理各个服务与服务上下线策略等，SC需要向SRC获取各注册服务的信息，SP需要向SRC汇报自身服务的IP、域名与所在域等关键信息。域根据机房进行划分，根据IP判断所在的域。同一个IP既可以是SC，也可以是SP。SP可以属于多个域，SC只能属于一个域，SC通过SRC获取某个域的服务及IP域名对应列表。SC可以周期性地去SRC获取配置文件，或根据被动通知完成配置文件更新，使配置文件可动态生成。

3.4 SmartDNS技术

为实现内网域名的解析功能，需在双机房搭建内网域名服务器。对于内网分配设置的子域，只能由内网DNS进行权威解析，非约定的子域通过内网DNS向外网权威服务器进行递归查询，内网DNS映射关系由平台增加域名后推送更新。

为保证业务DNS客户端的容错性，业务模块启动时需备份当前的配置文件，如果下拉配置失败，以备份为准进行运行；对于大流量、短连接业务，开启NSCD服务以减轻查询压力；当机房灾难发生，根据定制好的域名切换场景策略，比如单域名、发布业务集、域名类别、业务策略等；在平台中更新域名映射记录并重启业务服务，使域名新映射生效。解析流程如图5所示。

4 容灾系统维护与切换演练

根据同城容灾场景与故障经验统计，本容灾切换可分为公网故障、专线故障与整体机房故障3种。对于公网故障而言，只需根据预先准备好的域名一键切换后等待权威和各级域名提供商更新即可，若涉及到CDN需回源操作；对于专线故障，需将容灾B机房的流量切换至生产A机房，同时停止B机房的VIP服务。对于整体机房故障而言，除需要按照外网故障时的步骤进行操作，还需将两者机房交叉访问的业务集群进行内网域名的重新指向生效切换，以确保所有路由都在同一机房。

为了验证预案及切换步骤的准确性、检查组织流程制度的合理性并培训相关操作人员，企业组织了3次有序、全面的容灾切换演练。第一次为外网与专线故障演练，第二次为针对各个DB的单次演练，第三次是整体机房故障切换演练。对于第一次演练，发现1.2%左右的TCP集群客户端SDK未能自动切换，主要由于客户端未能及时更新SDK、部分SDK遗留容灾配置与调用方网络配置等原因造成。对于C类域名，10分钟内生效50%，4小时内生效90%，通过排查发现该现象与域名解析商的TTL有关；对于B类域名，10分钟内生效50%，半小时内生效70%，排查发现该现象多为调用方绑定VIP导致。第二次演练逐步将所有DB切换到容灾机房，即将业务访问的DB内网域名更新至B机房，并将A机房相关的业务模块重启生效，主要发现的问题为一些业务模块需禁写数据库配置才能切换生效、数据库防火墙设置会导致业务模块死锁现象发生。第三次演练时间选择在凌晨5～6点之间，整体回切选择在3天后的同一时间段，以检验B机房能否真正承担A机房的生产任务。演练结果表明，机房整体故障切换，对于关键服务，RTO为28min，RPO为0；对于非关键服务，RTO为36min，RPO几乎没有数据丢失，容灾B机房在A机房故障后完全可以单独运行并提供服务，达到了方案的设计预期值。

5 结语

系统容灾与数据恢复一直是信息技术行业关注的焦点，本文以上海某互联网企业为例，设计并实现了一种面向零数据丢失的容灾系统，基于优化的事务冲突机制，有效保证了业务数据的一致性与较高的事务并发逻辑[23]。在系统建设完成后，按照预案要求与容灾场景进行了3次比较全面的容灾演练，确保了容灾系统预案规划的有效性，规范了容灾组织流程与制度，培养了工作人员处理容灾故障时良好的心理素质与工作能力，并检验了容灾系统的有效性[24]。另外，在发生故障时如何达到更加智能化的一键容灾切换从而降低RTO，以及优化事务冲突机制算法以降低误判率，是今后需要重点关注与研究的方向。

参考文献：

[1] HU H，WEN Y，CHUA T，et al. Towards scalable systems for big data analytics： a technology tutorial[J]. IEEE Access，2014，2：652-687.

[2] 刘郁恒，杨龙刚.业务运营支撑系统双活容灾建设方案研究[J].移动通信，2017，41（4）：88-92.

[3] 欧阳志成.容灾技术在电力企业的研究与应用[J].产业观察，2018（1）：32-34.

[4] 葉虹余.基于NAS架构的数据容灾备份系统的统计与实现[J].软件工程，2018，21（3）：44-46.

[5] 彭晔，刘晓垒，杜敏.CDP异地灾备系统的研究与实现[J].中国管理信息化，2013，16（21）：49-51.

[6] 刘辰，李俊，雷斌，等.大型企业在云网融合下的业务连续性保护研究与实现[J].世界有色金属，2018（3）：199-201.

[7] 刘锦，刘晓洁，李涛，等.一种异地容灾系统的设计与实现[J].计算机应用研究，2007，24（8）：294-296.

[8] 夏红燕.信息网络分布式数据容灾应用研究[J].电脑知识与技术，2018，14（12）：36-38.

[9] 王晖，谢静绮.“互联网+”时代下档案容灾演练问题的思考[J]. 兰台世界，2018（2）：65-67.

[10] 许昌军，孙福国，曹玉龙.面向零数据丢失的滁州烟草数据中心灾备系统实践[J]. 电脑与信息技术，2014，22（4）：33-36.

[11] 姚文斌，赵玲，王真，等.容灾信息系统的建模与仿真[J].北京邮电大学学报，2015，38（3）：50-53.