目前，城商行现有业务系统大多是传统架构。为了满足银行各类新产品业务发展需求，建设可信 IT ，面向双活或者多活数据中心改造以及核心改造成为各中小银行的重点项目。双活数据中心建设，需要从应用层、网络层、数据库层、存储层等多方面进行考虑，数据库和存储的双活实现息息相关，均是双活数据中心建设的重点与难点，其中存储双活无疑是双活数据中心建设的基石。

本次交流，我们主要针对城商行如何实现同城数据中心存储双活以及对数据库双活的支持，邀请专家进行问诊及交流，主要围绕以下几个方面：

(1) 存储双活对同城数据中心的选址要求，如何选择同城两地数据中心的距离？监管部门对同城双活的有哪些要求？
(2) 如何在当前主流存储产品（ EMC 、 IBM 、日立、华为、 Netapp 等）中进行选择？不同存储厂家的如何实现双活？各有什么特点？不同存储产品对异构、横向、纵向扩展的支持能力如何？不同存储与其他存储的兼容性如何？对虚拟环境的支持能力如何？对数据库双活的支持能力如何？
(3) 按照什么原则梳理现有应用业务系统，降低对双活的要求，减少投资？如何按照功能区规划存储独立或共享使用？
(4) 各品牌存储产品还有那些特性可以节约存储使用空间、提高工作效率、减轻维护工作量等？
(5) 有没有较成熟的 NAS 同城双活存储？需要注意哪些内容？
(6) 分布式存储与集中式存储分别适用于什么场景？各应注意哪些风险点及注意事项？

本次线上同行交流，欢迎大家提出目前遇到的各种关于存储双活建设中的难题。通过本次活动，社区希望能够给大家带来一些参考思路，以助大家能够理清头绪、合理决策以及科学做好各企业存储双活方面的规划建设工作。

1、存储双活后，备份的数据如何有效的开展定期的恢复验证工作？

吕老师：
备份和存储双活是相辅相成的两条线，备份数据主要是聚焦在逻辑故障的恢复。恢复验证需要根据不同的场景指定不同的应对措施，数据库可以通过脚本配合备份软件拉起验证。非结构化数只有人去验证。 DELLEMC 的 Datadomain 自身具备数据有效性的算法，内部自动检备份数据是否有效。

夏老师：
上双活了，建议配套上备份系统，从备份系统抽取数据来循环恢复验证，若没有备份系统，我只能告诉你，你们得自己写脚本来热备或者冷备，这个工程太大了，亏人力。我们使用备份系统，然后配置了数据库自动恢复环境，一键恢复到验证环境，虚拟机及也采用自动恢复，或者立即拉起。大大减少人力，效率大大提高。

2、 双活中心一般建议存储异步还是同步，两种模式对于双中心距离要求为多少？

夏老师：
结合非重要业务与重要业务来看，不然领导觉得你是单纯谈技术，脱离了实际。
两种模式各有特色，性价比与安全性各有特色。

某 XX ：
1 、双活分应用级双活还是数据库也实现双活，如果是全双活的话，建议双中心距离不要超过 100KM ，保障裸光纤链路质量不要超过 5ms 延迟。裸光纤链路质量是双活的关键。
2 、如果只是应用级双活的话，存储和数据库的架构决定你采用什么应的复制关系。如果采用 ADG ，一般采用最大性能方式，存储复制的话一般同步和异步都可以，如果裸光纤质量不好就采用异步复制方式。同步方式如果裸光纤发生抖动可能造成 IO 的短暂 hung ，会对业务造成影响。 3 、存储复制异步和同步主要依据你双活的实现方式。

吕老师：
存储双活有三种块、文件和对象。块和文件双活都是以数据同步为前提的，对象通常是保证 metadata 的同步，底层文件数据做异步传输。
同步模式下主要是看业务对延迟的最大容忍度是多少，通常存储要求往返 5ms 延迟是做块存储双活的底线，距离如果按照光速计算就很远了。实际距离来说，欧洲有超过 500km 的 SAN 双活实施，国内基本都是 50km 以内。主要受制于光纤链路的皮质，包括跳数、熔纤的质量、光纤的摆放等等。
异步模式下，对距离理论上没有限制，因为对象存储大多是存放非结构化数据，通常数据量较大，带宽需要根据写入数据量的规模和能够容忍的 RPO 进行计算。

3 、 两地三中心双活系统灾备切换场景和数据补录问题？

夏老师：
数据的 RPO0 应考考虑一份存储级别的双活数据，或者异步复制的数据；不能全部依赖数据库软件高可用（物理 + 逻辑冗余）
双活测试场景太多了，不同思路不同考虑，运营商链路，单点物理设备，系统级别，站点级别故障都要拉通测试，（分行、网点部分及全面故障）；应用系统分依赖关系（比如加密平台，短信平台失效）；还得同时考虑双中心故障引起东西流量过大的风险。
综合网络链路；各个区域路由；系统隔离级别；应用交付调度策略，从底层一层一层来解决吧！这个太广泛了，几句说不完。
建议数据层： Vplex 双活存储 +OracleExtendRAC+ADG ；应用 F5+DNS 或者 vsphere+ 双活存储 + 网络大二层；双活存储解决了你的数据补录问题。

某农信：
根据我们江苏农信多年的灾备建设和切换经验，向您提出一些建议，如果说的不好请别介意。 1 ，灾备的目的：灾备的目的不是为了备份，更不是为了实现技术上的成就，花这么多的钱根本上是实现银行的业务连续性管理目标。 2 ，双活的目的：有次我参加一次讲座，还没讲完，有家银行的领导就问我： “ 切换？你们都双活了还切换个啥？ ” 这个问题能代表很多人的疑惑。双活这个技术手段为了实现的目标是更快的恢复业务，也就是说为实现更小的 RTO 和 RPO 而已。冷备切换要 2 个小时，双活只需 10 分钟。假如你不演练的话，怎么说明你的双活建设的牛呢？你没有在 10 分钟内切换到灾备接管业务，怎么说明你们银行的钱花的值呢？冷备摆在那不是蛮好的嘛，还省钱。您想想是不是？ 3 ，双活怎么切：双活的系统，演练的时候优先切换数据库，再切换应用系统。切换数据库是重点，如果失败就不用再往下切换应用系统了。 Oracle 数据库的 ADG 切换效率很高，两三分钟的事情，但是你们要花 10 分钟进行检查（检查工作远比调度切换脚本更重要）。数据库切换没问题的话，再用 DNS 切换流量到灾备中心，生产端的应用根本不用停。如果检查没有问题的话，就把生产端和灾备端的应用交易日志取下来，留作监管单位来审计用。到时候你可以给他们看看， “ 领导您看，这个时候生产端的日志已经不滚动了，灾备端的交易日志还在滚动，灾备还在承接业务，说明我们交易已经成功切换到了灾备中心 ” 。你就这样讲就行了，所以生产端的应用你没有必要停到，正好用来做日志对比说明你们的战果。 4 ，数据补录问题：我能熟练背诵很多监管文件，人行、银监、省金融办的文件里只是要求我们演练要以真实业务场景为前提进行切换（杜绝一些银行用桌面演练应付监管审计），从来没有哪一家监管单位要求我们非要做计划外的切换。计划外的切换，我建议你们千万不要做，就算你想做，你们行长同意吗？真出了问题，太严重，尤其现在很多交易都是 24 小时交易，通过自助设备接入完成的。如果数据真的有损失，后果不堪设想，补录非常非常麻烦。

4 、存储双活仲裁架构设计的关键点有哪些？

夏老师：
采用 第三站点仲裁最佳；方式有 Ip 网路与 FC 网络；

吕老师：
主要是两个问题：
1 、仲裁位置的摆放，最好是第三站点，这在极端故障情况下更能够最大限度保障存储可用；
2 、网络问题，双活仲裁有些是通过管理网络实现的，比如 DELLEMC 的双活，只要 IP 网络通就行了，但是有一些是通过存储虚拟化的方式来实现，这就需要 SAN 网络通，当然可以采用 IPSAN 的这折中方式，但是从实际经验看，存储虚拟化方式对带宽的需求略大。有客户处有 DELLEMC 和友商的双活同时跑的情况，同样的带宽大小， DELLEMC 的双活仲裁正常进行，友商的就不断报错，最后通过升级带宽解决了问题。

5 、 双活环境下，银行夜间批量任务（含数据库全表更新步骤）对交易成功率有较大直接影响，如何调优？

夏老师：
批量属于 OLAP 业务处理，交易属于 OLTP 业务处理。在跑批期间影响交易，这个从底层 OS 、 DB 是无法完美解决，需要软件的开发来设计，应对高峰的批量业务保障业务进行，很多跑批结算日是自定义日结切换时间，比如核心切换是每天 11 ： 30 分，其他业务也随之同步切换日切记账。通过应用逻辑设计来规避数据表竞争，解决表竞争就能很好解决交易业务问题。这个涉及的业务改造就比较大，跑批涉及表可以适当引入分区表适当解决表竞争。

吕老师：
个人理解交易成功率降低大概率是数据写入出现了问题，首先采集数据库、主机、网络（主要是双活同步网络）和底层存储的日志，然后分析跑批期间的有没有出现资源利用率过高导致写入受到严重影响的环节，具体分析后才能进行有效的调整。
所有的双活和同步复制都要求写数据在两个设备的一致写入，跑批期间有大量的过程数据写入，都会面临比较大的挑战。我曾经碰到过一家行因为复制链路带宽过低导致大量 IO 拥塞导致出现问题，通过带宽扩容解决了问题。但是，前提还是前面说的，找到问题的原因才能优化。

6 、双中心二层网络必要性？

银行同城应用级灾备或同城双活级灾备的场景下，在暂时不考虑多活数据中心的前提下，使用网络大二层打通的架构是否合适？这种场景下网络大二层打通是否还是架构的趋势？

夏老师：
没有全局负载均衡均衡调度的话，大二层还是可以的，双活存储 + 大二层 +vsphere 虚拟化方案，是一种解决方案。
但是网络压力较大，最好还是建设居于 DNS 的双活应用调度。大二层不是趋势，是一种解决方案。

7 、跨中心应用双活 web/app 的具体部署模式？

夏老师：
你这有 GSLB 实现跨中心分发，应用减少东西流量，尽量保持都是南北流量。双中心间减少 web 与 app 的交叉访问。除非系统故障出现。跨中心交叉访问对跨中心流量堆叠太高，不利与网络管理。

8 、目前主流的双活技术有哪些？双活建设中主要遇到哪些难点？

网络层、应用层、数据库层、存储层目前主流的双活技术有哪些？双活建设中主要遇到的难点有哪些，同行一般能实施到哪一层了？

夏老师：
网络层、存储层最好做（有运营商裸纤就好做），其次是应用层有虚拟化的 vsphereHA ，也可以基于 GSLB 全局调度应用；最难是数据库层 oracleExtendRAC （对于距离要求太难了，每多 1ms 延时，就是巨大的风险）说白了最大难点就是链路延时与抖动是最大隐患，一旦脑裂数据灾难不可想象啊； oracleExtendRAC 双中心距离很近比如 3-5KM 可以同时使用，若大于 10KM 则主机房 active ，备机房 standy 不打开实例，都能保障数据绝对 RPO ， RTO 也是分钟级别我们测试过 10 分钟。其他技术都很很成熟了。

9 、同城双活数据中心对 IP 网络和 SAN 网络有哪些要求？通过哪些指标进行评估？

如果想实现 oracle 数据库同城双活和存储同城双活，对 IP 网络和 SAN 网络有哪些硬性要求？通过哪些指标进行评估？

夏老师：
存储同城双活，硬性要求， 1 、建议五大厂商选，（推荐带虚拟网关方案例如 vplex,SVC ）； 2 机房选址不宜过远（ 20KM 以内可保证光延时约 1ms ）， 3 建设需要裸光纤（强烈建议） 4 最好自购波分设备， san 网络交换机带光衰检查判断。
oracle 数据库同城双活，这是个大难题主要受限于网络延时要越低越好，数据库 TPS 小可以双中心并行跑 RAC ， TPS 高的又要双中心并行跑 RAC 对环境极为苛刻（心跳通信压力很大）这种适合 3-5KM 以内（国外很多这种案例），这种建议选高端成熟解决方案（ Vplex 、 SVC ），推荐全闪存。
若建设 ExtendRAC ，实现主中心 Active ，另一中心 RAC 节点 standby ，这个是一个折中选择方案。可以保证 RPO 为 0 ， RTO 分钟级别。

10 存储双活如何管控，如何制定匹配制度？

夏老师：
双活管理的确是个难题，我们也存人手不够，通过补充对口技术人才，执行 AB 角互备，数据库、存储、主机、应用负载、网路、安全各司其职；同时我上了一套容灾切换软件专门解决 oracleExtendRAC 切换及 AIX 个别应用容灾切换；释放 DBA 排错压力，专注监控定位，提供指引；
应用切换基于 DNS 不需要太多人工干预；存储双活建有第三站点来保障仲裁；减少疑难场景仲裁人工分析。但也只能紧紧满足现状，无法应对互联网金融业务发展，这个要上 devops ，推行 IAAS 解决方案来释放人力压力

吕老师：
灾备建设是一个系统工程，这个工程中最难的不是技术问题，是管理和沟通问题，特别是与非科技背景的高级别领导展示、解释的问题。
就像您说的管理问题，很多行采用了类似的技术架构但是采用了不同的管理方法，为什么？因为每个行的情况都不相同，管理很大程度是跟领导风格相挂钩的，要形成有效的管理不能简单看别人穿什么衣服的问题，大多数时候是需要量体裁衣。这也是为什么很多行在做灾备咨询。除了专业技能，咨询更多的是帮助沟通。

11 、当双活存储间的广域网线路抖动或者一些链路报错时。

如何降低同城双活存储对广域网的依赖性？当双活存储间的广域网线路抖动或者一些链路报错时，如何排查原因？由于双活存储的延时，如何判断哪些业务支持双活存储应用环境？

夏老师：
第一问：双活存储主要依赖裸纤 SAN 级联网络， 仲裁网依赖 广域网，也有的双活仲裁采用 fc 网络；仲裁建议部署第三站点来降低依赖与风险。
第二问：广域网线路抖动，也是运管上光纤不稳定吧；一是采用多级光纤线路，二是需要 san 交换机支持 光衰大，不稳定时 自动屏蔽； 思科的 san 支持。 排查原因主要交给网路链路监控；以及 san FC 监控告警；
第三问：双活存储的延时 一般 2-3ms 以内 业务都可用吧， 要是你的
存储延时很高，恐怕距离太远，或者集成质量很差；这种场景一般要避免； 既然存储双活了。理论业务都可以用。

吕老师：
DWDM 设备能够检测到链路抖动并自动报警
SAN 光纤交换机配置 “ Port Fencing ” 功能，自动检测链路抖动并关闭 FC 端口，从而隔离链路抖动
IP 网络设备应用 “ 快速收敛实现检测（ BFD ） ” 技术，自动检测并关闭抖动链路口，从而隔离链路抖动
存储虚拟化网关的 WAN COM I/O 模块能够自动检测链路抖动并关闭端口，从而隔离链路抖动