·2020-09-23 10:46

系统架构师·金融

某银行核心系统同城双活建设方案及难点分析

字数 6736阅读 9847评论 3赞 9

## 【文章摘要】

对于每一个银行信息系统的建设和维护人员，永远绕不开的是如何保障业务的持续稳定无间断运行，最关注的是系统的稳定性，可靠性和高可用性。而“双活”技术，则是构建一个7*24小时稳定运行系统必不可少的技术手段，本文从双活系统的技术选型出发，对双活技术的重点难点进行了深入分析，详细阐述了基于Dell EMC VPLEX双活方案的实现机制和原理以及系统构建，尤其分享了长期运维总结出来的宝贵实战经验。对于想要构建双活系统，又不知从何入手，期望从理论和实践得到指导的IT从业人员来说，是非常有借鉴意义的！

## 1. 项目背景

银行的信息系统是关系国计民生的重要系统，一旦发生火灾、地震、台风、主机故障、电源故障、存储故障等突发灾难，造成金融行业信息系统中断，将会直接影响到国家财产安全、社会生活稳定和国民经济正常运转。

因此，为了保证金融行业信息系统的安全稳定运行，人民银行、银监会、保监会及相关行业协会在信息系统灾难恢复标准制定方面制定了多个管理规范和指引，以加强金融行业信息安全保障体系建设，规范金融领域信息系统灾难恢复工作。

- 2006年4月，中国人民银行颁布了《关于进一步加强银行业金融机构信息安全保障工作的指导意见》（银发[2006]123号文），要求全国性大型银行，原则上应同时采用同城和异地灾难备份和恢复策略；区域性银行可采用同城或异地灾难备份和恢复策略。

- 2006年8月，银监会发布的《银行业金融机构信息系统风险管理指引》（银监发[2006]63号），明确地提出金融机构应制定信息系统应急预案，并定期演练、评审和修订，省域以下数据中心至少实现数据备份异地保存，省域数据中心至少实现异地数据实时备份，全国性数据中心实现异地灾备。

- 2008年2月，中国人民银行正式发布和实施《银行业信息系统灾难恢复管理规范》（JR/T0044-2008）。其中要求：短时间中断对国家、外部机构和社会产生重大影响或影响单位关键业务功能并造成重大经济损失的系统：RTO（恢复时间目标）<6小时，RPO（恢复点目标）<15分钟；短时间中断会影响单位部分关键业务功能并造成较大经济损失的系统：RTO<24小时，RPO<120分钟；短时间中断会影响单位非关键业务功能并造成较大一定经济损失的系统：RTO<7天。

-  2011年12月28日，中国银监会正式发布了《商业银行业务连续性监管指引》，对商业银行及相关金融机构的业务连续性管理工作提出了明确的要求：
    ◆要求商业银行至少每三年要开展一次全面业务影响分析
    ◆识别重要业务，明确重要业务归口管理部门，所需关键资源及对应的信息系统，识别重要业务的相互依赖关系，分析评估各项重要业务在运营中断事件发生时可能造成的经济损失和非经济损失
    ◆原则上：重要业务恢复时间目标（RTO）不得大于4小时，重要业务恢复点目标（RPO）不得大于半小时
    ◆通过业务影响分析，确定信息系统RTO、信息系统RPO，明确信息系统重要程度和恢复优先级别，并识别信息系统恢复所需的必要资源

## 2. 需求分析

我单位信息技术部门在遵守国家相关标准及银行业的相关规范的基础上，依据本行的发展战略，结合新一代银行系统的建设规范和要求，对各个业务系统进行梳理，通过对业务影响的分析，明确不同业务系统灾难恢复等级，如RTO、RPO的要求，信息系统重要程度和恢复优先级别等，按照这些要求，将整个业务系统分为了三大类：核心系统、关键系统和一般系统。明确对于银行核心系统按照国际最高容灾标准进行建设，达到RPO=0，RTO≈0，保证业务的连续性。

## 3. 双活技术选型

围绕核心业务系统RPO=0，RTO≈0的建设需求，从应用层、网络层、数据层等多方面进行不同方案的比较分析，综合考虑了同城灾备、异地灾备、两地三中心、双活、云灾备等解决方案。经过对恢复指标要求、技术成熟可靠、成本效益高等多方面的综合考量， 确定采用同城双活的总体方案技术架构。相对于传统的主备容灾中心，双活数据中心最大的特点是：一、充分利用资源，避免了一个数据中心常年处于闲置状态而造成浪费。通过资源整合，双活数据中心的服务能力是双倍的。二、双活数据中心如果断了一个数据中心，另外一个数据中心还在运行，对用户来说是不可感知的，保证了业务的连续性。

要实现数据中心的双活，需要保证包括存储层、数据库层、网络层、应用层等都能实现双活，其中，最核心的技术是存储双活技术，各大存储存储厂商都有非常成熟的存储双活技术，如基于存储控制器实现双活的厂商有NetApp、华为、HDS，基于虚拟化网关实现存储双活的厂商有：IBM的SVC和Dell EMC的VPLEX，不同厂商的产品和技术各有优劣势，综合考虑各方面因素，我们的核心系统选用的是Dell EMC公司的双活技术。

## 4. 双活数据中心难点分析
建设同城双活数据中心，包含几方面的难点：

## 1) 技术方面：

**- 性能影响问题**
性能影响问题是存储双活方案的突出问题，因为双活系统在写入数据时，会写两次数据，尤其是通过复制功能写到远端存储的过程，传输链路的性能也会影响整体性能。因此，存储双活不可避免要遇到性能问题。因为存储是跨两个不同数据中心的，随着距离的增加，理论上每增加 100KM ，会增加 1MS 的 RTT （往返延迟时间）。所以我们在选型存储双活方案时，需要考虑如何尽量降低双活的存储所带来的性能降低影响。从我们使用来和监控来看，链路延时基本控制住5MS内。下图为我单位实际存储写I/O延时情况：
![](/home/attachment/202009/23/1243539_160082861298938.png)

**- 数据库和存储集群之间仲裁一致性问题**
另外双活数据中心设计中，另外一个关键问题是数据库和存储集群之间配合问题，也就是所谓的仲裁一致性问题，是指双中心之间的VPLEX存储集群和数据库RAC集群的仲裁结果是否能保证一致性。VPLEX集群通过第三方网络仲裁和Winner（静态优先）策略判定站点故障。而数据库集群是通过以太网心跳和OCR仲裁盘来做数据库仲裁。而数据库的OCR仲裁盘是存储集群提供的分布式共享卷。在这个问题上，风险发生主要有两点：一是数据库和集群的仲裁触发以及仲裁过程的时间顺序发生紊乱，默认仲裁策略不一致。在这个问题上通过实际测试和调整参数是可以避免的。实际上存储集群的默认仲裁触发时间会是15秒左右，而数据库仲裁触发的控制参数由misscount这个参数来决定，所以只要我们将misscount这个参数调整到45秒之后，也就是说理论上绝对保障存储集群仲裁在前，而数据库仲裁在后，那么第一个引发点就没有了。二是假设两站点节点资源对等，仲裁选票同样对等的情况下，存储集群会有一个默认的Winner（静态优先）策略，同样在这种情况下数据库集群也有一个默认仲裁策略：选择实例号小的集群存活。只要我们保证这两个策略结果的一致性，那么这个风险点也就不存在了。

**- 链路问题**
主要两个方面：链路稳定状况不可控；IO延时指标不可控。双中心之间的链路是通过租用运营商的裸光纤链路实现的，中间经历很多的中继设备及运营商局级节点。无论从管理上还是从技术把控上都是使用者自身不可控制的因素。假设双中心间链路延时指标不稳定，会导致数据库节点之间心跳网络传输的延时加倍。由于数据库集群之间的数据传输量非常大（缓存、锁、心跳等），在读写热点相对突出的业务上，轻则导致数据库读写性能灾难，重则导致数据库节点直接处于僵死状态。因此在设计上要避免同一应用双连两个中心数据库节点，减少数据库集群内存缓存区交互的情况。另外，链路的不稳定会导致存储链路频繁切换，甚至会导致集群仲裁频繁发生，这对于业务连续性更是一个灾难。

## 2)  人员、规划和流程方面：
 除了技术层面的支撑外，还有人员、规划和流程等非技术决策层面支撑。养兵千日，用在一时。只有技术和规划通力配合，才能在真正发生灾难时保证业务连续性。

业务连续性规划是进行灾备建设的大前提。没有业务连续性规划，灾备建设就没有意义，充其量只能做到数据不丢失，不能及时恢复业务运行，而保障业务连续性运行才是真正核心。通过业务连续性规划，分析梳理出各项业务的恢复优先级及其恢复要求(RTO、RPO 以及恢复业务所需的资源等)。

灾备方案的实施是确保所设计的灾备方案真正有效的重要环节，需要制定详细的工作计划，包括场地选址、产品选型、服务商选择、资源保障、项目管理、验收评审、演练测试等内容。同时还应该根据灾备设计方案，结合业务连续性规划要求，制定出完整的灾备计划(包括灾难应急响应总体预案、危机沟计划、各系统的专项应急预案等)，确保各部门在灾难发生时能够统一协调地行动。
 
## 5. 同城双活方案
基于以上各方面的考虑，核心系统采用的是基于Dell EMC VPLEX技术实现的双活技术。
![](/home/attachment/202009/23/1243539_160082875282537.png)

## 1)  存储层
Dell EMC VPLEX存储双活方案是基于VPLEX网关产品实现，能够将Dell EMC和其他厂商存储异构整合，虚拟化为统一的存储资源池，实现异构存储双活。VPLEX双活方案由两个站点的两套VPLEX集群系统组成，每个站点的VPLEX集群都有自己专属的本地存储阵列，通过创建分布式镜像卷为跨集群的镜像卷，提供VPLEX Access Anywhere功能，两个站点的VPLEX集群各有一个卷，两个卷的ID一样。

下图为VPLEX Metro双活方案主机跨集群连接组网架构。主机与VPLEX集群间访问、VPLEX集群与后端存储数据传输、VPLEX集群间通信网络全部隔离，为保证最高级别的高可用性，每个VPLEX Director前端I/O模块和一对SAN光纤交换机之间必须保证2个以上的物理连接，每个主机和每个VPLEX引擎的A Director和B Director都需要保持一个以上的路径连接，因此主机和一个VPLEX引擎间具有8条逻辑路径。对于每个站点2个、4个引擎的VPLEX集群来说，主机连接需要覆盖所有引擎；另外，当主机与本地VPLEX集群连接中断时，为保证主机能够跨站点访问另一端VPLEX集群，主机需要和其他站点的VPLEX集群建立连接，可通过PowerPath多路软件来配置ACTIVE/PASSIVE路径来保证主机优先访问本地的VPLEX集群；后端存储阵列通过SAN交换机或者直接连接VPLEX引擎的后端IO模块，不需要配置到其他VPLEX集群的跨站点连接路径；根据需要选用Witness作仲裁，Witness需部署于两个VPLEX集群不同的故障域中(第三方站点)。
![](/home/attachment/202009/23/1243539_160082879437506.png)

分布式一致性缓存技术：Dell EMC VPLEX是一个集群系统，提供分布式缓存一致性保证，能够将两个或多个VPLEX的缓存进行统一管理，从而使主机访问到一个整体的缓存系统。当主机向VPLEX的一个缓存区域写I/O时，VPLEX缓存将锁定这个缓存区域，同一时刻其他主机是无法向这个缓存区域写入I/O的。但是，当主机读取I/O时，VPLEX缓存允许多个主机访问一个缓存区域，尤其是主机访问其他VPLEX集群中其他VPLEX节点所管理的数据时，统一缓存管理会将这个I/O的具体缓存位置告知主机，主机直接跨VPLEX集群访问。分布式一致性缓存技术在实现上面，并没有强求所有的Cache都保持统一，而是基于卷缓存目录的形式来跟踪细小的内存块，并通过锁的粒度来保证数据一致性。每个引擎的cache分为本地Cache(Cache Local)和全局Cache(Cache Global)，每引擎的本地Cache只有26GB，其余为全局Cache，见下图：
![](/home/attachment/202009/23/1243539_160082882847558.png)

分布式缓存模式：VPLEX Local和VPLEX Metro采用了写直通缓存模式，当VPLEX集群的虚拟卷接收到了主机的写请求时，写I/O直接透写到该卷映射的后端存储LUN（VPLEX Metro包含两套后端存储LUN）中，后端阵列确认写I/O完成后，VPLEX将返回确认信号至主机，完成本次写I/O周期。写直通缓存模式需要等待后端存储阵列落盘完成，对写I/O时延要求较高。当出现电源故障时，VPLEX引擎自带的备用电源能够保证缓存中的所有未持久化的数据暂存到本地存储上。为了提升读I/O性能，写I/O的时候先判断是否在Local、Global Cache中有对应的旧数据，如没有直接写入本地Local Cache；如有旧数据，先废除旧数据再写入Local；再通过写直通缓存模式将写I/O刷入两套后端存储阵列；最后反馈主机写I/O周期完成，同时Global Cache中的索引做相应修改，并在所有引擎上共享该信息，实现分布式缓存一致性。

双中心采用双引擎VPLEX 存储虚拟化，每个数据中心外挂1台Dell EMC VMAX和1台VNX，实现本地双存储镜像，双中心实现4台存储双活架构，实现4份数据高可靠性冗余架构。

## 2)  网络层
网络层主要设备为思科的N7K核心交换机和OTV设备，N7K交换机实现虚拟网络交换层，双中心之间通过OTV设备的联通实现光纤传输协议的以太转换最终实现网层的联通（L2&L3）。

## 3)  数据库层
主要实现方式两中心部署4节点ORACLE RAC或者DB2 pureScale实现数据读写的跨数据中心均衡负载。

## 4)  应用层
主要实现方式F5负载均衡、vMotion自动切换、中间件应用集群、PowerHA等方式实现双中心多节点部署。

## 5)  链路层
这一层通过GTM和动态DNS解析技术来实现跨数据中心负载，数据中心内部通过F5 GTM实现内部DNS解析，广域网通过F5 GTM实现双数据中心动态DNS解析。

## 6. 存储双活测试和故障解析
自2012年开始从双活架构选型、存储双活测试到最终业务上线，作为Dell EMC VPLEX 双活架构行业内最早使用者，使用过程中出现各种各样的硬件故障，都确保了业务连续性，从根本上构建了一个7*24小时稳定运行的高可靠性技术方案。

2012年上线前VPLEX +ORACLE RAC 测试报告如下：
![](/home/attachment/202009/23/1243539_160082894095058.png)

当然了，存储在使用过程中，也由于存储使用年限较长，没有及时对硬件进行替换升级，当时我单位也出现了VPLEX外挂一台存储2块磁盘同时故障的现象，造成主机端写I/O缓慢，果断将故障存储下电，主机端I/O恢复正常，后续又将VPLEX 集群中存放配置信息的磁盘从故障存储中转移到了正常存储中，确保了业务连续性。从这件事件上，VPLEX双活方案作为使用者，还是比较让人信服的。

## 7. 运维经验分享
主要从以下几个方面：
1)  增加线缆监控，确保运营商裸光纤故障及时告警处理；
2)  网络层面心跳和业务OTV VLAN分开，确保在网络层面相互影响；
3)  核心区域两中心互联与其它DMZ等区域通过网络层面层次化设计，防止突发流量交叉影响；
4)  合理解决跨中心两端网关路由问题，路由过滤等相关问题；
5)  跨中心防火墙集群检测时长加长，防止脑裂问题；
6)  要避免同一应用双连两个中心数据库节点，减少数据库集群内（缓存、锁、心跳等）交互的情况；
7)  光纤延时制约双活运行模式，可采用差异化的双活运行策略。
8)  存储到一定的使用年限，一定要及时更换，防止电子设备老化带来数据丢失和性能下降的风险。

## 8. 总结
VPLEX+VMAX双活已在核心业务运行5年，一直稳定运行，期间多次组织双活数据中心演练，整个双活体系做到了采用层次化和组件化设计，使接管更具备灵活性。既可以中心级接管，也可以按业务系统和IT组件模块进行接管。RPO=0，RTO≈0，保证业务的连续性。

同城双活存储双活 VPLEX

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论3 条评论

zhuqibs软件开发工程师Adidas
2020-09-25 16:30

首先5ms确实太多了，我们的idc和公有云的延时要求小于3ms，而且我们还不是要求双活。其次，这个业务涉及的组件太少了，好像除了数据库就是存储了，实际上对于互联网企业，还有redis、kafka、elasticsearch等等，而且kubenetes逐步成为行业主流，双活方案也要向之靠拢。再次，Oracle Rac如何跨地部署，极端依赖光纤的带宽和低延时。

guwenkuan： @zhuqibs 关于延时的情况，在这里解释以下，实际上我们的物理裸光纤链路在存储交换机上fcping 是1.2ms（这个是真实的线路延时），网络层面ping是0.9ms, 写I/O在存储和主机层面要至少2个来回交互，写I/O延时在跨中心层面基本要3-5ms，我上面VPLXE 性能截图反映的是存储的前端写I/O延时，是2个来回交互的延时，ORACLE 远程RAC官方文档明确要求的是小于100KM 延时小于5ms，实际上我们的延时是1.2ms，远远小于官方的5ms延时。 “idc和公有云的延时要求小于3ms” 这个要求应该对应的是物理链路实际的延时，而不是存储对应的实际写1/O延时，如果实际链路真是5ms，数据库远程部署肯定是有问题的。另外，上述文章主要是传统架构的双活，是金融行业的案例，开源组件没包含在内，欢迎继续交流，谢谢。

2020-09-29 12:41

添加新回复

ZhuJun2014存储工程师IBM
2020-09-25 14:31

1.站点间的响应延时怎么到了5ms。这个值太高了。一般双活的距离不超过100公里，运营商提供的链路延时一般不超过1ms。 2.写IO延时都到了4-10ms，传递到数据库的日志上，肯定会放大到更高的延时。数据库的性能是否有很大的影响。 3.存储仲裁winner设置导致的io pending是15秒，把misscount调整到45秒是否太激进。类似案例在某些客户的生产，碰到过io pending超过60秒的。这个时候，45秒的misscount肯定会导致数据库挂掉。

guwenkuan： @ZhuJun2014 1、关于延时的情况，在这里解释以下，实际上我们的物理裸光纤链路在存储交换机上fcping 是1.2ms（这个是真实的线路延时），网络层面ping是0.9ms, 写I/O在存储和主机层面要至少2个来回交互，写I/O延时在跨中心层面基本要3-5ms，我上面VPLXE 性能截图反映的是存储的前端写I/O延时，是2个来回交互的延时，ORACLE 远程RAC官方文档明确要求的是小于100KM 延时小于5ms，实际上我们的延时是1.2ms，远远小于官方的5ms延时。 “idc和公有云的延时要求小于3ms” 这个要求应该对应的是物理链路实际的延时，而不是存储对应的实际写1/O延时，如果实际链路真是5ms，数据库远程部署肯定是有问题的。 2、我们在使用过程中没有问题，写I/O受距离限制，要2的来回交互，反映到存储上基本要3ms以上，这值没有问题,读1/O基本在1-2ms。 3、存储仲裁winner设置的是5秒，存储集群的默认仲裁触发时间会是15秒，这也是EMC官方建议的值，经过测试和论证过的。oracle层面我们经过测试，拔掉主机光纤30秒内，数据库没有问题，超过30秒数据库就会宕机，反映到主机层面就不是30秒了，肯定是远大于30秒这个数值。不知道您碰到的io pending超过60秒具体什么情况，欢迎继续交流学习，谢谢!

2020-09-29 12:57

添加新回复

lishappy项目经理山东泰山钢铁集团
2020-09-25 10:09

感谢作者分享，非常宝贵且实用的经验。提到写两次数据性能影响以及数据库和存储集群之间仲裁一致性问题，并从各个层次和参数配置调整上讲解了如何解决及避免和很多感悟分享，可以让我们少走很多弯路，点赞。

guwenkuan： @lishappy 谢谢，欢迎互相交流学习。

2020-09-29 12:57

添加新回复

Ctrl+Enter 发表

匿名评论

某银行核心系统同城双活建设方案及难点分析

添加新评论3 条评论

作者其他文章

相关文章

相关问题

相关资料