银行同城双活存储方案设计中这些难点问题怎么解决？| 多位高手分享

导读：存储层面的双活架构，是整个双活架构当中相对比较难解决的。社区组织“城商行同城双活存储方案设计探讨”，来自20余家银行企业的同仁提出了很多难点，本文总结了多位高手针对30多个问题的分享，包含很多经验和知识点，值得参考。

前  言

近年来，随着互联网金融的快速发展，城商银行数据中心建设面临着新的挑战。那就是对RTO和RPO的极限追求。从而也就诞生了近年来的热点话题——双活数据中心建设。

从科技工作层面来讲，其实双活数据中心并不是一个行业标准或者规范。行业的标准是对RTO和RPO约束，银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO=15分钟，RTO=30分钟。而根据国际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。双活的概念也就由此而来，大家都是为了达到最高标准。从业务层面来讲，能够实现业务在双中心进行分发并且自动切换从而保障业务的连续性。那么我们认为这样的目标就实现了应用级别的双活。

基本上能够达到6级标准或是我们所述的应用级双活，其中需要基础架构层面很多关键技术体系的支撑，同样也会有很多的关键问题需要解决：

1、如何实现网络层面的双中心引流架构？故障场合下如何将客户端访问切换到另外的数据中心？

2、如何实现数据层面的跨数据中心保护？包括访问连续性的保护和数据本身的保护？

3、如何实现存储层面的跨中心复制？采用什么样的复制模式？采用什么样的复制技术等？

尤其是在存储层面的双活架构，它是整个双活架构当中相对比较难解决的问题。虽然有存储网关技术、存储级复制技术等可以帮我们去实现这样的架构。但是其中的风险也是我们必须考虑的问题，针对存储网关技术会有仲裁、延时等严重风险点。针对存储复制技术会有IO返回延时、高概率的逻辑错误等等风险点。同样如果存储架构设计安全合理会带给数据库层面的简单和安全。

因此，TWT召集了各路存储专家、数据中心双活专家齐聚一堂，针对20余家银行企业同仁的犀利提问展开深度交流，下面由社区专家邓毓对本次活动有参考价值的内容进行详尽总结。

分以下七个章节进行总结：

一、存储双活解决方案的部分难点问题

二、全闪存阵列的引入对存储双活的帮助

三、数据同步与复制相关问题

四、数据库双活解决方案的问题

五、网络层及应用层双活解决方案的问题

六、同城双活建设规划、规模、模式与运维等问题

七、国内华为存储双活解决方案

一、存储双活解决方案的部分难点解读

1、双活存储脑裂风险

【Q】存储双活的脑裂问题有好的解决方案吗？

【A】

@libisheng：

通过第三方仲裁即仲裁服务器来解决，当脑裂发生时候，系统进入仲裁流程，两台存储分别开启抢占“仲裁服务器”，抢占成功的接管业务，默认是优先站点具备抢占优先级。

当前华为存储支持双仲裁，主备模式，当一个仲裁故障后，还有另外一个仲裁设备参与仲裁。

@woshishui072612：

双活中，包含两台生产存储+仲裁服务器/存储，三个设备间至少保障两个设备状态是正常的，链路是OK的。双活考虑中须重点保障链路的通畅性。

链路正常时，仲裁即使挂掉也不会出现脑裂情况

链路不正常时，同时仲裁挂掉，那么就会出现脑裂的情况。

@邓毓：

这个问题分两个方面来理解：

如何防止脑裂发生:脑裂的发生，也就是两个双活存储间链路中断导致的，加强链路可靠性，提升链路/波分设备冗余度是办法。

脑裂发生了，脑裂仲裁机制是怎样的:（1）第三仲裁站点+2个站点的存储组成三个仲裁成员，脑裂时，存储站点都认为自己是活的，这时就要靠这个第三站点来投票了，通常第三站点优先探测到了那个存储站点，这个站点获胜率高，或者这个存储站点是集群配置所在的站点，那获胜概率也高。（2）设定偏好模式来仲裁，就是按照用户的设定，偏好谁优先获胜。

【Q】双活存储实现高可用的方式，如何防止仲裁脑裂？

【A】

@fuwangrong：

@liuyusheng：

仲裁就是防止脑裂的解决方案。没有防止仲裁脑裂的概念。

@libisheng：

当两个站点间的链路和心跳出现故障的时候，两站点存储与仲裁设备协同开始仲裁，仲裁成功的站点接管业务，另外一个站点存储挂起，不能提供服务。

【Q】存储双活的第三方仲裁是否需要重点考虑？

【A】

@王军：

@libisheng：

第三方仲裁要考虑，如果有第三方机房，仲裁设备建议放在此，如果没有，建议放在优先站点，比如生产中心。现在技术成熟，仲裁设备一般采用一台服务器或者虚拟机来仲裁，通过IP 网络来通信。为了更可靠，部分厂家支持两个仲裁服务器，一主一备，主故障，备仲裁顶上去。

@邓毓：

存储双活是对称式部署架构，一定需要重点考虑第三站点仲裁的问题。

有条件的，在两个站点之外的第三站点设置仲裁节点，通过FC或者IP都可，看存储双活的要求

无条件的，在主生产站点做，优先保证主站点的优先级。

@liuyusheng：

双活场景部署仲裁，就是防止脑裂。这也是厂家推荐的部署组件。原因就是保障多种故障共同发生的情况下，保障业务的持续运行。尤其是存储层的双活方案中，仲裁需要重点考虑。

2、双活存储数据一致性与多路径策略

【Q】跨站点双活的两个存储，如何保证两端存储数据读写的一致性？

【A】

@l00245741：

写是两端存储均写成功才默认返回主机信息，通过锁机制避免写冲突。对于写异常场景，存储会记录差异，待异常恢复后，再进行差异数据同步。读采取就近读的原则，减少时延影响。

@libisheng：

双活技术要保证RPO=0，也就是两个站点的存储数据是完全一致的，比如，存储A收到的写请求，会同步写到远端存储B，同时本地存储A也写成功后，才会返回给主机，确保数据完全一致。

【Q】存储跨站点双活，主机多路径策略如何设定？

存储跨站点双活，主机多路径策略如何设定，既避免主机跨站点访问存储节点，提升本地存储亲和性，又能够在本地站点存储路径失效时，无缝切换至跨站点的存储？

【A】

@张文正：

这种情况建议上虚拟机存储化网关，ibm svc 或者emc 的vplex，如果是同一家厂商的产品建议用厂商自带的多路径软件，在存储多路径软件里可以设置策略！

@libisheng：

存储双活方案，一般建议采用厂商多路径，双活技术和多路径结合来实现，经过双活关联的两台存储的LUN，多路径会虚拟成一个逻辑设备，而多一倍的路径，当有本地路径都失效时候，业务通过多路径自动切换到跨站点存储对应。多路径上会配置对应的优先站点存储，识别为优先路径，业务优先从高优先级路径下发。

另外，双活也支持采用操作系统自带多路径比如NMP，MPIO等，经过厂商认证测试通过的也可以达成双活功能。

3、双活存储应用场景

【Q】存储双活和应用双活的业务各自适用场景在哪里？

存储双活和应用双活的业务各自适用场景在哪里？？如ORACLE数据解决方案中如果有 EXTEND RAC是否就可以不需要存储双活呢？

哪些场景适合使用存储双活？哪些场景适合应用层双活？

【A】

@王军：

双活是一套完整的解决方案，不是局限于某一层的技术，需要存储、网络、数据库、应用各专业配合形成，最终的目标是RPO=0&RTO=0的业务连续性。

存储双活是把两个站点的盘机上的卷形成一个虚拟卷，写到这个虚拟卷的数据会自动在两个盘机各写一份，确保数据不丢失。双活的关键点是两个站点的数据可同时对外读写。

存储是由上层应用挂接使用的，上层应用必须也要有配套的双活技术，如Oracle RAC，否则A机房的服务器挂了，在B机房再启一台怎么才能自动挂接上这个卷，因此上层必须要能组成一个Cluster，共同对外提供服务。

无论是存储层双活，还是数据库的双活，还有配套的网络技术，目标都是达到应用层双活，即一个站点出了故障，另一个站点可接管业务。根据RTO要求不同，可以做成Active-Active模式，也可以做成Active-Query模式，也可以做成Active-Standby模式，AA级别最高，可以无缝接管，AS最低，需要人工干预切换。不同级别，投入也是不同的。

如果不使用系统层的双活技术也是可以的，那就是应用层来做双活，由应用来控制双写。不过应用的复杂度非常高，对应用开发人员的挑战也很大，此类案例很少，仅用于比较特殊的环境。

@徐治国：

存储双活和应用双活是密不可分的，存储的双活主要是保障业务或应用的双活，如果应用不是双活的，存储做了双活，又有何用？其实需要存储双活的其实就就两个场景：（1）Oracle RAC类（2）VMware 集群类

其他应用没有双活的，存储即使做了双活，也就是数据保护。

【Q】银行企业的背景下，存储双活解决方案适用的应用范围？哪些应用或者需求不适宜存储双活解决方案？

【A】

@l00245741：

基于业务连续性要求来确定，包括监管要求。对RPO/RTO要求高的业务，可以考虑建双活。双活可以做到RPO=0，RTO≈0的业务连续性保障。银行企业，诸如关键的核心应用、渠道前置等系统均可以构建双活系统。

4、双活存储的部署模式与优劣势对比

【Q】采用双活存储后，是单中心部署还是可以同城双中心部署？

同城双中心部署，是否再考虑主中心的存储高可用。双中心部署下，SAN网络需要注意些什么？

【A】

@王军：

本地高可用、同城双活、异地灾备这些不同的方案要综合考虑形成完整的业务连续性保障方案，哪种方案应对的是哪种故障，什么条件启动应急，都要有明确的场景。

做了同城双活后是否要保留本地的高可用，要结合实际情况，综合应急时间、成本等因素进行评估。如果同城双活的方案满足业务恢复的要求，那么本地高可用就可以不需要了。

@libisheng：

同城数据中心光纤链路有条件的，存储层100km距离，光纤链路好，可以考虑同城存储层双活，存储的双活其实对链路的要求没有RAC集群拉远要求高，但是结合RAC拉远集群，一般建议30km左右。

同城数据中心，可以考虑存储层做同城双活结合数据库层主备技术实现，应用层通过数据库热切，存储层通过双活切。

从业界的实施来看，本地双活部署多些，3DC采用本地两台存储做双活-同城复制-异地复制技术。

@qiuhaoshu1：

双活存储现在可以在本中心（类似宏杉的），同城双中心也可以，现在实施比较多是在单中心

【Q】HDS GAD/IBM SVC在双活方案中的对比优劣？

HDS GAD是存储级双活，IBM SVC需要借助网关做双活，这两种方案优劣对比，在未来同城扩展哪种方案更适合金融行业？

【A】

@邓毓：

其实技术都是相通的，无论是存储双活还是存储网关双活，其技术原理都类似，存储网关双活只不过是把存储双活的控制器种的一部分功能上移了，另外还具备一部分异构存储的虚拟化功能，能够兼容不同存储的双活实现。

存储双活/网关双活无非是解决写IO如何在多控制器或者节点间同步的问题，这就是软件层面的东西，看谁家的软件做得好而已，顺带来点增值功能，像压缩，虚拟化，重删，快照等等。

如果需要多类异构存储都要实现双活的功能，像SVC这类虚拟化网关双活的方案，肯定是不二之选。

如果是仅仅做HDS高端存储的双活，用HDS GAD那就是不二之选。

@liuyusheng：

IBM SVC和EMC VPLEX都属于网关，都能提供双活功能。HDS GAD，HW HyperMetro，EMC SRDF-Metro等都是阵列双活方案。

在核心业务中，越来越多的用户选择全闪存，以提高性能、降低TCO。但，网关就限制了全闪存的性能优势。银行客户当前使用网关的越来越少。

@徐治国：

HDS GAD属于阵列双活，IBM SVC属于网关双活，目前双活的趋势走向无网关形式，主要有以下几点：

1、免网关双活，组网更加简单，相比网关，连线及zone简单，少，

2、网关双活相比阵列双活，要增加1.2-1.6ms的时延，这对一些关键的业务是有很大影响的，

3、降低TCO

4、即使是网关具备一些异构等功能，也不能接太多设备，多了，也会成为瓶颈或单点。

@libisheng：

前者是存储阵列双活，包含HDS和华为存储都支持阵列AA架构双活，不需要网关设备，相比IBM SVC做双活，阵列双活技术已经成熟而且规模商用。技术优势如下：

1、阵列集成了早年前的网关的功能：双活、异构整合功能(存储再外挂外置存储)和数据迁移功能，功能层面一致；

2、统一了硬件，不需要专用的网关设备，不需要采购额外的网关软件，降低了成本；

3、组网层面，SAN网络降低了组网复杂度，更简单；

4、存储阵列可以实现SAN和NAS一体化双活，同时支持配置SAN双活(AA架构)和NAS双活；

5、仲裁设备采用服务器/虚拟机，不需要存储来仲裁；

从未来发展演进看，存储阵列双活已经成为趋势，建议采用存储级双活。

二、全闪存阵列的引入对存储双活的帮助

【Q】全闪存储的可靠性及安全性问题？

全闪存储适不适合做银行核心等一些关键系统的数据库存储？相对普通机械硬盘，在可靠性、闪盘故障后数据可恢复性方面能否有保证，会不会导致数据永久丢失？目前有同行将核心等关键系统数据库数据放在全闪上吗？

【A】

@邓毓：

全闪的数据保护方面，现在各厂商都有相关技术的，像闪存模块间的RAID保护，闪存芯片间的RAID保护，ECC校验保护，全闪主控的高可用等。核心系统要上闪存，可考虑高端存储的全闪系列，稳定性可靠性，高端存储是没话说的，加上闪存模块，性能也上了一个层次，再加上同城数据容灾，异地容灾，数据备份等数据保护措施，数据可靠性已经不是以前的时代了。

目前应该很多银行核心用到了高端全闪。

@libisheng：

全闪存开始商用已经超过5年，从SSD盘的故障率看，SSD返回率只有0.2%,远远低于HDD的2%的返回率，此其一，

第二，端到端来看，SSD盘内部也有RAID技术，存储系统也有RAID2.0技术，方案层面有容灾、双活确保可靠。

第三，SSD盘是电子器件，颗粒寿命是可以通过算法测算出来的，有磨损率、预估周期，未来能用多长时间是确定性的，而HDD是机电一体化精密设备，其实很容易损坏，有可能抖动就坏了，是不可预估的，存在偶然的损坏可能，反而是不确定性的。这样全闪存就可以通过提前制定算法策略来规避风险。

从业界发展来看，未来的数据中心一定是全闪存的数据中心，美国、欧洲已经大规模商用，超过50%用全闪存，国内金融行业也从证券、保险规模商用，比如中国人寿、中国人保、平安科技、太保等都大量应用于核心生产，现在银行也开始使用，比如建行采用高端全闪存应用于生产系统，邮储、中信银行、招商银行、民生银行、兰州银行等都规模应用全闪存替换传统SAS盘。

【Q】闪存技术的引入，对存储双活解决方案带来了什么？解决了哪些问题？依旧留存哪些问题需要解决或者用户仍需注意哪些问题？

【A】

@libisheng：

闪存技术的引入，减少了IO的时延，对双活来说也减少了盘的访问时延，双活是两个站点都要写完成，是需要耗时的，因此闪存引入，其实是好事。

对于关键交易业务，现在高端存储全闪存双活方案已经成为主流方案。很多城商行农信客户都考虑此方案，一方面闪存替换，性能更好，时延更低，节省机柜空间、能耗，可靠性相比HDD更高，而且闪存价格相对于2年前也下降很多，性价比更高，另一方面，通过双活技术对存储进行加固，确保高可用，数据是企业的关键资产，对可靠稳定的追求是极致的。

@谢丰：

带来的是更高的性能，解决了机械盘故障率高和慢盘等问题。

仍需关注的问题的逻辑保护问题，这是双活无法解决的，但是这一块华为正在做性能无损的秒级快照能力，解决这部分问题。

三、数据同步与复制相关问题

【Q】请专家分享一下实时性要求极高的账务交易如何实现同城双活的数据同步问题？

目前，大多数机构实现的同城双活都只在应用部署及运行层面上，而数据库的访问基本是访问一个中心的数据库，无法做到各数据中心访问各自中心的数据库。

多活数据面临多个写入点，极有可能会错乱、会冲突、循环复制、数据环路环路等问题，这些情况下怎么保障数据一致性成为极大的挑战。因此，多数机构都采用了只使用生产中心的数据库，将生产中心的数据实时向同城中心同步的方法，一旦生产中心数据库故障，再切换至同城中心的数据库，同时将交易比例向同城中心倾斜。

请有经验的专家分享一下经验。

【A】

@王军：

做双活的目的是提升业务连续性运作能力，如果为了双活连正常业务都受影响了，那就本末倒置了。

按银行业务系统的要求，技术架构首先要保证数据一致性，其次是RPO=0，最后才是RTO=0。所谓双活，本质上就是满足前两条的前提下看如何才能做到第三条。这也是绝大多数机构的双活只是AS模式或AQ模式的原因。

在双站点距离较近的情况下，采用Oracle Extended RAC加存储双活技术是可以做到双活的，但是对距离、网络质量有非常严苛的要求，方案好设计，后期运维的坑较大。

对于业务连续性要求非常高（必须要双活）的应用，建议从应用架构层面解决。

@liuyusheng：

安全性和性能，就像是鱼和熊掌。

数据实时性要求极高，可以考虑选择类似跨数据中心的Oracle RAC技术，既能够实现数据库的双活，也能实现严格同步。缺点是，对链路质量要求极高！（参考oracle最佳实践）

基于存储层的双活技术，是有很多技术来避免错乱和冲突的。EMC VPLEX是分布式Cache，华为是分布式锁。这些技术都是解决这类问题的。

@徐治国：

时间换空间，空间换时间，这是一个有争议的命题，想保证性能，一定程度上牺牲可靠性，想保证可靠性，一定程度上会损失性能，主要看业务场景的重要性。

目前闪存的趋势越来越明显，对于性能和可靠性都有要求的账务系统，可以采用全闪存阵列双活或同步解决方案，来实同城双活的架构。

@邓毓：

应用双活也就是应用节点的双活，应用可能不用到存储，自然没有存储双活的事，用到了存储，也就要考虑应用节点间数据同步的问题，可用存储双活来解决。实现了存储双活，必然要用到数据库和应用上面去，否则一个空壳子也起不到作用，应用和数据库需要对底层存储双读写的必然要用到存储双活，只不过这个存储双活的实现技术可以不一样，比如通过软件层的方式或者底层存储层的方式都可以。

EXTEND RAC是跨站点多数据库节点的双活，是事务层的解决方案，底层存储当然需要，否则落存储的数据如何同步，同步又包括AS和AA方案，AA也就是实现存储双活，前面说的软件层解决方案和底层存储解决方案都可，AS也就是存储主备，可以用操作系统的GLVM方案，也可以用存储底层的数据容灾方案。

通常应用双活不需要考虑所用存储或者不用存储的同步的话，就不需要存储双活。数据库如果仅仅是要求底层存储是主备，那也不需要存储双活。如果需要数据库和底层存储都是双活的，可读写的，那存储双活就是必须的。

@qiuhaoshu：

双活是一套完整的方案，需要考虑多种需求。 oracle的extend RAC如果应用可以做存储的双活的，存储双活可以做这样是原先存储支持。但是可以加SVC、vplex等

【Q】数据同步复制应该从哪几方面入手解决？应用层？还是存储层？还是二者有机结合？

【A】

@DylanIT：

建议对数据源应用分类入手

结构化应用，数据库库类，强应用一致型，使用数据库自带同步套件处理。确保数据库在可用时间点的拉起

非结构化，散列数据。建议直接从存储侧数据流动，原因是效率高，可靠性有保障

@liuyusheng：

这是个复合型问题，我的观点是取决于业务规模和自身的运维技术能力。

当前，对数据库运维管理经验丰富的架构师团队，倾向于应用层解决问题。依靠ORACLE RAC及ORACLE ASM和相关容灾技术，来实现数据复制和容灾切换等。

对本身核心业务还在用Informix的，对存储本身也比较熟悉的客户，还在规划采用存储层复制来解决问题。

@libisheng：

数据同步复制技术，有存储层复制、网关层、数据库层，越往底层存储走，容灾实施难度、管理难度越容易，同步复制切换时间越长，越靠近应用、数据库容灾，容灾效果好些，切换容易，资金投入也越大。

而存储双活技术从复制技术升级而来，解决了切换时间问题，高效。

【Q】多中心架构下的双活，如何做到对数据同步和交易响应时效的处理？

多中心架构下的双活，如何做到对数据同步延迟的处理，提高时效性。以及如何对双向同步后的数据进行一致性检查。对于银行内类金融企业时效性要求非常高的交易能不能真正做到存储双活的无感知对接。还有就是交易的横向流量控制问题，对超时要求非常高的交易（例如15秒超时）如何提高多中心交易横向引流后的处理速度。

【A】

@libisheng：

同城双活链路时延建议要求2ms,采用存储双活两边响应时间，数据库写日志小于 5ms认为优

@liuyusheng：

多中心做双活，那就是挑个别业务来做啦。理论上讲，业务支持双活，业务对延迟的容忍度，再去要求基础设施提供相应的性能和功能。从规划设计角度看，业务不报错（延迟要求参数设置相关），基础架构就成功了。存储复制本身，中间环节越少，延迟损耗越小。

目前，还没有哪种技术做到无感知.（基于存储复制技术）

四、数据库双活解决方案

【Q】基于oracle rac数据库，选用哪种存储双活方案更适合？

【A】

@huijx：

如果做同城双活，关键是心跳链路带宽和延时能否满足RAC要求

@王军：

基于Oracle RAC数据库的话，IBM、EMC、HW、HDS等各厂的存储方案虽然实现机制有所不同，但都是可行的。

基于存储网关的模式，如IBM SVC、EMC VPLEX等，优点是对接服务器侧是统一的（比如存储多路径软件只需要部署存储网关的那家即可），两侧耦合度低，缺点是IO链路比较长，有时延损耗，增加了故障点。

基于存储盘机的模式，如HW HyperMetro、HDS GAD等，优点是架构复杂度低，可节省一点时延，缺点是两侧耦合度高，一般来讲，要求两个站点同一品牌型号的盘机。

结合业务的情况，实际测试后再选型。根据我的经验，最终的焦点可能不在存储双活上，而是在Oracle RAC上。

@liuyusheng：

当前存储厂商提供的双活方案基本都能满足RAC的部署需求。这根本还取决于RAC本身的部署模式。部分城商行对链路质量没有信心的情况下，将RAC群集独立部署，也就是主中心一套RAC，备中心一套RAC。通常备中心RAC为只读。在灾难发生的情况下，再切换到备中心。

存储双活方案中，华为HyperMetro、EMC SRDF-Metro等都能满足。但是，银行客户当前倾向于架构简单、运维简单、性能损耗小的解决方案。

@qiuhaoshu：

存储级别的存储双活（很多存储支持，华为、日立、DELLEMC、宏杉、IBM、oracle）

网关级别的双活（SVC等）

Oracle 的RAC里也同样有high模式，也支持双存储。

【Q】数据强一直性要求的数据库，如何实现数据数据库的双活？

关于数据强一直性要求的数据库，在两个中心距离较远（约70KM）的情况下，如何实现数据库的双活？

【A】

@王军：

金融行业的数据库一般都要求强一致性或实时一致性，可以使用数据库层的复制技术（如Oracle DG的最大保护模式），也可以使用存储层的双活或者复制技术，也可以结合起来使用。

@邓毓：

强一致性是可以保证的，看你对并发要求和响应时间的要求。

实现的方式也多种多样，其中数据库双活必然要利用到两个层面的双活

数据库本身事务级别的双活，也就是多数据库节点间的内存数据如何融合和同步，如何解决锁竞争，ORACLE EXTEND RAC和DB2 GDPC都是成熟的方案，解决数据库事务层面的双活问题

数据库所用存储的双活，也就是数据库数据落盘后，保证两个存储的数据同步问题，像类似于GPFS并行文件系统、存储（或存储网关）双活也都是目前流行的方案。

两个层面的双活要协同起来配合，才能实现真正的数据库双活，否则简单的数据库节点双活，底层存储主备，或者数据库节点主备，底层存储双活，都是伪双活。

距离越远，同步带来的时延越大，数据库节点间缓存同步或者锁竞争的开销越大，这就与业务的并发和要求成反比，所以归根到底，一句话，实现都是可以的，就是看业务的性能要求。

【Q】如何做异地oracle rac双活？

有一套系统部署在北京机房，想在广州做异地双活，数据库是rac，请问需要考虑哪些？

【A】

@王军：

Oracle Extended RAC集群中的节点之间距离不能太远，20公里以内效果还可以，超过100公里就没法用了。业界很少有超过50公里的案例。

北京和广州异地直接做双活，必须要从应用层考虑补偿机制，异地直接不可能使用同步复制机制，RPO不会为0。

@徐治国：

异地双活，主要受距离和时延的限制，存储级别，通常25KM以上，需要DWDM,最大100KM，超过100KM，双活基本无法实现，只能靠应用层面，来实现，理想状况，如果能保证时延，没问题，也看应用切换的时间到底是多少

另外，如果仔细看Oracle RAC的手册或者最佳实践的话，Oracle RAC也是有距离限制的，甚至有些推荐，比如最好在同一机房或同一园区，再远，也不推荐，真正的Oracle RAC主要受限于距离或网络时延。

@liuyusheng：

这种超远距离，只有考虑应用层，而且还得考虑数据改变量。怎么做，RPO都不能为0

@邓毓 ：

异地纵跨中国地图的ORACLE数据库双活？别开玩笑了，我们还是聊聊ORACLE数据库灾备吧

@libisheng：

异地双活，受限距离和时延，只能做异步复制，RAC同城双活还可以考虑，而且距离也有限。

五、网络层及应用层双活解决方案的问题

1、网络层方面

【Q】网络层的双活技术方案应如何实现？

【A】

@libisheng：

同城双活，需要两个数据中心2层网络打通，SAN网络也要通。也就是DC A的主机能识别DC B的存储，DC B的主机能识别DC A 的存储。

@l00245741：

采用大二层网络，双链路冗余。

【Q】同城双活如何解决网络延迟，数据库心跳，存储延迟问题？

【A】

@王军：

光在光纤的传输速率为20万公里每秒，100公里的网络传输一个来回需要1ms，这是物理规律，解决不了的。

剩下的事就是如何设计方案来接受这个延迟。

网络延迟问题不是太大，应用层设计到可接受的程度即可，毕竟新疆访问上海机房的数据跨着几千公里都能忍受，何况再加个几十公里。

数据库心跳受影响会比较大，这儿不仅有网络延时的问题，更重要的网络抖动的问题，毕竟隔着几十公里，网络质量不可能太好，很容易对心跳造成影响，把集群中的节点踢出去。对于跨双中心的数据库，100公里的距离，估计能支撑100左右的TPS。如果需要10000以上的TPS,那么两个站点的距离得在20公里以内。

存储对延迟最为敏感，这也是大量存储双活技术存在的原因所在，通过存储双活技术，可以实现本地读，但写惩罚是免不了的。

@huijx：

如果硬件链路环境不具备，就不要考虑双活了。

@邓毓：

缩短距离，网络延迟就小，增大双活存储的写缓存，减少写缓存不足直接物理落盘带来的同步延迟概率。

@qiuhaoshu：

尽量缩短中心之间的距离

硬件环境，线路供应商要好

【Q】如何避免网络质量和数据库热点之间的矛盾？

【A】

@XINGOU：

如果双活两个中心之间距离比较远，为了避免数据库的热点迁移造成的跨中心流量，建议在Oracle RAC层创建不同的service，不同的service访问不同站点的RAC节点，以实现业务分离。

通过Oracle RAC透明应用程序故障切换（TAF）的PREFERRED功能设置应用只访问本地实例；同时设置远端数据中心的实例为AVAILABLE，只有本地实例都故障才切换到远端实例。

【Q】双中心存储双活网络如何设计？

双中心存储双活网络如何设计，才能缩小故障域，不会因为局部的存储网络故障波及到全网，又可以实现双中心存储网络的互联互通?

【A】

@邓毓：

那就得网络大二层打通，二层通了，一个站点某三层网络安全分区故障了，其他三层，或者另一站点的这个三层网络安全分区，都不受影响。

如果仅仅是存储双活，如果是FC网络同步，可以只做三层的互联，但两个站点的三层间就必然有关联和影响。

@l00245741：

大二层网络，双链路冗余，光纤链路，25公里光纤距离需要增加波分设备

【Q】如何实现网络层面的双中心引流架构？故障场合下如何将客户端访问切换到另外的数据中心？

【A】

@邓毓：

用智能DNS，或者全局性负载均衡。像F5就有专门的智能DNS设备，可以按照网络层面的流量按照一定策略就行流量引流，比如按照运营商、客户端区域，IP地址等进行解析，通过规则分发到不同的数据中心。

另外还具备探测下一层的链路负载的连通情况，不通，就自动将流量引至其他数据中心。

@libisheng：

F5本身就可以实现业务负载分流。

@liuyusheng：

再结合DNS群集。

@lxk215313951：

首先数据中心采用域名化改造，app服务的访问全部用域名，部署智能DNS硬件设备做DNS智能调度、故障检测与负载均衡。

2、应用层方面

【Q】应用访问数据库推荐使用IP还是DNS方式？

何种方式便于故障时切换访问，有没有最近银行的相关案例。

【A】

@刘诚杰：

应用访问数据库建议时候dns模式，方便后端的迁移（另外，应该还有中间层，而非直接连接数据库）

@王军：

强烈推荐DNS！

主备切换的时候，一般需要备库接管主库的IP地址，那么两个站点的二层网络需要打通（同一网段的IP地址需要同时存在于两个站点），网络设计非常复杂，且两个站点耦合度太高。

如果网络二层不打通，那么切换时备库就无法使用主库的IP地址，这时所有应用服务器访问数据库的配置都需要修改，不说有恢复时间RTO的限制了，光改配置就是一项不可能完成的任务。

不要问我怎么知道的。。。。

@libisheng：

肯定建议采用DNS。

【Q】双活的时候，应用切换是怎么个流程？负载均衡应该怎么做？

【A】

@邓毓：

如果是应用双活，那就不存在应用切换的问题，两边都是AA的状态，都可接收到负载的请求。如果平日同城容灾端的应用节点是启动状态，但负载端是禁用状态，那只要将禁用改为启用，流量自然就分发至同城了。

【Q】在应用层，f5或者dns等技术方面，应该怎么进行选择？

【A】

@邓毓：

看你的需求

如果是同站点，两个应用节点需要双活，软负载和硬件负载都是可以满足要求的

如果是跨站点，全局性负载均衡或者智能DNS是必须的，当然站点内部，多应用节点需要负载均衡的，也是需要软负载或者硬负载。

所以不存在怎么选择的问题，两者可以单用，也可以结合。

@liuyusheng：

在网络层，通常需要多种技术结合才能解决网络层的冗余问题。全局负载均衡器是必须的，再结合DNS，共同实现网络层的双活和多活。

六、同城双活建设规划、规模、模式与运维等问题

【Q】如何进行双中心的一体化运维？如双中心系统的统一监控、一键切换等？能否推荐合适的工具？

【A】

@邓毓：

这个就涉及到好几个运维系统，集中监控、自动化运维平台，流程平台，CMDB等，每一个都是个独立的项目，而且这些系统都存在千丝万缕的耦合关系。不是一个工具就能实现的，必然是多系统和多系统间融合才能实现的。不过简单的实现统一监控和切换，那就另当别论，一体化运维可不是这么简单。

@王军：

双中心一体化运维：

监控&性能容量系统：每个中心各自采集性能信息及告警信息，可以在本中心落地做一次汇聚和过滤，将相关信息送到位于某个中心展现层进行告警或展现。展现层也要在同城做双活部署或主备部署，以备在展现层故障时能够切换到备中心。

运维管控平台：双中心对称部署，从某中心的管控平台进入，都要操控本中心和同城中心的任何一个节点。

切换：要能支持一键式跨中心切换，包含三个级别：单节点切换、单应用切换、多应用切换（终极场景中整个中心切换），还要能支持回切（主要用于演练）。

能够实现这些功能的运维自动化平台应该很多，也可以自建。

@cft18：

统一监控：

一体化运维一般只是面向本中心，如与其他中心有互联的系统，择一事一议；但只是停留在服务和线路。

系统监控管理分为4层：

基础设施层

监控信息：硬件损坏、报警等

包括：IDC管理、空调、电力、服务器、存储、交换机等监控

系统层

监控信息：CPU、内存、控件的使用情况；安全防护情况；网络使用情况

包括：操作系统（window、Linux等）、文件系统、安全配置、网络设置等

应用层（软件层）

监控信息：服务运行情况。

包括：数据库（Oracle、MySQL等）、WEB服务（apache、MQ等）、中间件（weblogic、Tomcat等）、软件（JAVA等）

注：在这一层监控其他中心，但只监控网络和服务是否正常。（例：OGG数据库同步）

业务

监控信息：业务压力、业务运行信息

包括：业务功能模块。

注：结合应用层和系统层进行数据分析，给业务层的监控进行数据支撑。

一键切换：

多中心的切换有两种：

应用层切换：

使用软件自己的机制切换；人工切换；

注：单节点切换、单应用切换、多应用切换，主要面对单中心。

业务层切换：

使用CDN、负载均衡

注：主要面对多中心

@libisheng：

兴业银行成立三十年，8月份出了一本书，全面系统的介绍兴业银行 <<数据中心跨区域一体化运营>>，可以参考。

【Q】同城双活优缺点、建设周期、初期规模？

【A】

@邓毓：

看您对同城双活的具体要求，是应用双活、数据库双活还是存储双活，涉及到的业务系统有多少套？

选型的话各大厂商都差不多，每个双活要求都涉及很多不用厂商，选型无非是技术成熟度、功能性、易用性，稳定性，需要亲身POC才能体会。

同城双活建设的风险主要有两个一个是性能影响、一个是脑裂风险

建设周期根据您的具体要求，和业务规模而定

从底层基础架构开始建设，网络-存储-数据库-应用，初期肯定是网络和存储，或者一些主机等建设，存储双活的建设等，再就是在初期的基础之上，把数据库和应用双活做起来，也涉及到一些类似负载均衡设备的建设等。

同城双活非一朝一夕之事，先定位，再长远规划，最后将规划稳步落实

@王军：

首先，要做需求规划，把业务系统进行分类，分别明确每一类系统的RPO、RTO要求。不可能所有的系统都做双活，成本太高，也没有必要。

其次，同城中心选址。距离对技术方案的影响非常大。

第三，技术方案选型。各厂商的技术实现的效果大都差不多，要结合自己的应用特点做POC测试。

第四，测试。搭建实际环境要对选定的方案反复测试，调整，优化。毕竟真实的环境跟机房模拟出来的环境还有差异的。

第五，试点。选择一个合适业务系统进行试点，做好回退方案。

第六，推广。

整个阶段下来差不多得2到3年时间吧，规模取决于要做双活的应用的多少。

【Q】银行同城主备如何向双活转变？

【A】

@王军：

一个应用系统的同城部署有几种模式：

AS模式（Active-Standby）：也就是主备模式，备库平时不可用，RTO不为0，需要主备切换。可以通过自动化一键式切换等工具尽可能压缩切换时间，使得RTO的尽可能小。

AQ（Active-Query）：备库平时是只读模式，可以将读交易或者备份、报表等业务放到备库执行。RTO不为0，需要主备切换。也可以通过自动化一键式切换等工具尽可能压缩切换时间，使得RTO的尽可能小。

AA模式（Active-Active）：也就是双活模式。需要组合存储、数据库、文件系统等多种技术来实现，架构比较复杂。

可以在应用层实现近似的AA，比如，对数据分组，部分数据部署在A站点，备份在B站点，部分数据部署在B站点，备份在A站点。当某站点出现故障时，至少有一半客户是可以交易的。

一般来说，AA的架构比较复杂，两站点的耦合度较高，需要应用层精心设计。如果RTO可以接受的话，没有必要一定要追求AA。

七、国内华为存储双活解决方案

【Q】国内华为存储双活方案相较于国外存储厂商存储双活方案有何独特之处？产品优势点在哪？

【A】

@libisheng：

华为存储双活技术已经做到极致，主要优点如下：

阵列直接实现双活，不需要SAN或者NAS网关，两套独立的存储系统之间实现双活，两套存储系统之间的软硬件相互独立，两个双活副本保持实时一致，RPO=0，RTO=0。

支持SAN和NAS一体化双活方案，SAN双活是AA架构，双活的两个副本都处于活动状态（非主备模式），可以被主机并发读写访问；NAS双活是AP架构，实现主站点故障后快速切换，10s切换，优于的90s切换时间。

存储阵列做双活，组网更简单。

网络统一，站点间镜像网络采用FC或者IP，仲裁网络采用IP网络。

仲裁设备采用服务器仲裁，而不是存储仲裁。具备独立的第三方仲裁，第三方仲裁故障后，双活系统自动进入预设的优先模式。支持对有业务关联性的多个双活LUN/卷设定相同的仲裁策略，确保数据一致性。

相对于VPLEX、SVC网关双活，少了IO路径的故障节点，节省了IO时延，节省成本。

@DylanIT：

SAN+NAS一体化的，免网关双活。

在单端故障切换短，应用无感

@liuyusheng：

无网关，简化管理，减少性能消耗和性能瓶颈；

Fastwrite降低远距离时延（对时延敏感的业务用途明显）；

SAN+NAS一套方案，一套仲裁；

@wuwenpin：

个人觉得国产产品还得加油

【Q】存储层中的几百TB的NAS能做到双活吗？

NAS为应用提供共享服务，也成为了双活需要考虑的一个方面。

商用的例如EMC ISILONG能做到双中心双活吗？

【A】

@libisheng：

华为OceanStor V5 NAS存储支持NAS双活，实现RPO=0，RTO=0，目前银行渠道类、核心生产类需要共享数据，一般采用NAS存储实现文件共享，业务属于A+类，因此，NAS存储对故障的自动切换提出了高要求。华为NAS双活，在主站点故障后，业务切换到灾备可以做到秒级切换。当前华为V5 NAS双活已经在华夏银行、平安银行等客户应用，客户反馈很好。

@l00245741：

华为OceanStor V5系列存储提供NAS双活方案，切换时间数秒~数十秒。EMC ISILONG个人理解不能做到跨数据中心部署，不支持双活。

@邓毓：

NAS能不能双活与存储容量没必然联系，只可能是NAS存储吞吐量的大小可能会影响NAS双活的数据同步性能。

【Q】华为存储双活解决方案是如何处理与上层数据库双活集群故障场景下，仲裁一致性的问题？

华为存储双活解决方案作为数据库双活整体解决方案中存储选择的一种方式，是如何处理与上层数据库双活集群故障场景下，仲裁一致性的问题？有哪几种仲裁配置方式？

【A】

@谢丰：

整个仲裁由存储底层决定。

以数据中心间链路全中断为例：

链路中断，存储间心跳和RAC集群节点间心跳均同时中断。

存储抢占仲裁，假如存储A侧存活，则B侧停止接受业务。

RAC节点只有存储A侧的节点能继续访问其共享存储，该中心RAC节点抢占仲裁盘成功，继续提供业务。

RAC节点在存储B侧的节点由于抢占仲裁失败，停止提供业务。

只要存储层仲裁时间小于应用集群能等待的时间，业务就不会中断。

本文由邓毓总结。邓毓，某农信社资深骨干工程师，一线实施经验丰富，对双活数据中心及云平台建设和监控有着深入的见解。

本次交流活动特别感谢以下社区会员分享：

王军 工行

cft18  中国电信

huijx 华泰保险

lihui  重庆三峡银行

张文正 神州数码

刘诚杰 平安好房

libisheng  华为

liuyusheng  华为

l00245741  华为

DylanIT 华为

谢丰  华为

徐治国  华为

XINGOU  华为

qiuhaoshu

woshishui072612

wuwenpin

fuwangrong

资料推荐：

某商业银行应用双活架构设计方案

http://www.talkwithtrend.com/Document/detail/tid/418625

华为银行业数据中心容灾解决方案

http://www.talkwithtrend.com/activity/?id=1221

长按二维码关注公众号