城商银行双活容灾建设方案设计三大难点

为帮助同业在双活容灾建设项目规划和建设过程中提供一些启示和帮助，TWT社区近期组织了银行业双活领域的数位专家，就系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面详细探讨了同城双活与容灾规划思路以及建设过程。下面由社区专家邓毓对整个活动的主要内容进行总结，方便更多读者参考。主要分为以下三个方面：

1、同城双活架构与容灾架构改造方面

2、双活数据中心应用交互与流量分发方面

3、双活上线的标准、监控及自动化运维工具等方面

一、同城双活架构与容灾架构改造方面

Q1、针对存储级复制实现主备中心数据同步的架构，如何改造成双活的模式？

@邓毓 某农信系统工程师：

这个双活范畴比较大，看您是想实现的什么样的双活，双活的节点有没有共享存储数据等。

最简单的应用双活，不共享数据的话，主备数据中心的架构，打通了大二层网络，将应用节点部署于两个站点，通过负载将请求分发到这些应用节点，实现应用节点的跨数据中心多活。

其次是存储双活，这时需要专门的双活存储作为必要条件，或者通过能够实现双活的虚拟化网关来帮助原有的存储实现双活，存储双活后，对应用节点需要跨数据中心共享数据，有很大的便利。当然也可以作为数据库双活的后端存储。

最后是数据库双活，对能够实现双活的数据库方案，跨两个数据中心拉开的方案，如ORACLE EXTEND RAC、DB2 GDPC等，数据库实现事务级的双活

Q2、Oracle RAC+ADG的方式实现双活是否有相关案例？灾备从AS转换到AA的建设有什么建议？

@邓毓 某农信系统工程师：

oracle rac+dg是本地数据库双活+同城容灾的架构，灾备端只读，真正的跨中心oracle数据库双活方案还是oracle extend rac+存储双活方案，存储双活要么采用两套可双活的存储实现，要么基于不同存储，搭建例如gpfs跨中心的并行文件系统实现。灾备从ad到aa，在不改变底层存储架构的基础之上，最简单的还是引入操作系统之上的并行文件系统和数据库双活技术

Q3、银行的容灾架构，如何在保障业务高可用的前提下保障系统安全性？

@赵海 技术经理：

我理解的这个安全是系统和数据的长久安全。如果我们能保障业务的连续性前提下，底层基础架构的选择就要以系统的安全性为主要目标，不要盲目追求基础架构的完美而卖下安全的风险，架构越复杂系统整体面临的风险就越高。

Q4、同城双活架构当中，最关键的几个技术点以及思路？

@pangluck 中鼎系统工程师：

1、网络层面，两数据中心要实现二层打通。

2、应用层面，虚拟化。

3、数据层面，存储复制+ADG。

Q5、同城双活架构当中，关于网络二层打通的技术选型，VxLAN技术可行性？

@asdf-asdf cloudstone 研究学者：

大二层并不是必须vxlan，使用pvlan技术一样完成大二层打通，但安装技术vxlan是可行的。

Q6、30km同城双数据中心之间的网络延迟大致是多少？是否存在抖动？对双活稳定性可有影响？

@邓毓 某农信系统工程师：

通常理论上，每100KM距离，RTT往返延迟为1MS，但通常一次通讯，可能涉及多次RTT，加上并发，所产生的延迟已经可以和存储的IO响应时间相比较，性能较好的存储通常IO响应时间都控制在5MS以下，所以距离带来的延迟已经是不可忽略的了。抖动取决于链路质量，通常而言，我们都是租用的运营商的裸光纤，抖动或多或少是存在的，偶尔抖动一两次，是可以接受的，延迟陡增，不至于引起网络长时间超时，属于可控范畴，真正要关注的无非是长时间，频率较高的抖动，对于网络和数据传输是致命的。目前防范抖动最好的方式还是通过TCP协议的数据同步，利用TCP的重传机制，保证数据的在一定时间窗口还是能够传输过去。

二、双活数据中心应用交互与流量分发方面

Q1、如何从整体规划设计应用节点同城双活的请求分发与请求引流？

@邓毓 某农信系统工程师：

目前而言，主流应用负载有以下两种：

软件负载：HAProxy、IHS、Zookeeper、Apache、Nginx等

硬件负载：F5、信安世纪负载、深信服等

如果是应用节点同城双活，那么需要考虑应用访问请求如何如何引流至两个数据中心的应用节点的问题：

有两种方式：

生产请求，生产和同城应用节点均衡响应，请求从单数据中心进，响应从单数据中心出（本地负载，跨中心分发）的方式，应用负载部署于主数据中心，将请求均衡/优先级、权重等方式分发至两个数据中心的多个应用节点，多适用于内网业务系统。

生产和同城请求，生产或同城应用节点分别均衡响应，请求从两个数据中心进，响应从两个数据中心出，例如通过智能DNS域名解析，将公网请求按运营商/地域的不同进行引流，两个数据中心的应用节点处理不同类型的流量，这种方式多适用于互联网类的业务系统。内网业务系统也可以采用全局DNS的方式进行流量分发。

Q2、业务系统的整体同城双活建设方案之外，如何考虑与其他业务系统的互联互通，尤其是跨中心的业务间访问？

@赵海 技术经理：

这个问题其实可以这么看，业务没有中心之分，只有业务接口之分。每一个业务接口对应的是相应的域名和端口，至于域名解析到哪一个地址，落到哪个数据中心，完全是基础架构的设计。所以我们在做双活方案的时候，以具体应用为粒度在应用负载均衡设计当中形成独立的跨中心应用资源池就可以了。

Q3、如何进行同城主备中心的流量分担？

@赵海 技术经理：

一个非常重要的判断标准就是基础架构的配置，同配置情况下，我们希望是完全的均衡模式。如果配置不一样，那么我们希望可以按照基础架构配置来调整流量比例，这个可以在负载分发层来定制策略。

另外一个非常重要的标准是以业务点的分布为基准，以不同数据中心对业务点响应的时间来作为客户端引流的标准，这个需要通过域名解析与业务点相关属性定制化相关策略来实现。

三、双活上线的标准、监控及自动化运维工具等问题

Q1、做双活的标准怎么判断？比如做过的企业，哪些业务做了，哪些业务没有做，原因是什么？

@赵海 技术经理：

直接关系到柜面渠道、电子渠道等这些对客户业务系统，要做双活必须把它们列在其中。

一起内部业务，跟对客户业务关系不是非常密切的，可以考虑不做或者降级。

核心系统不仅要做而且要考虑到双重保险。

个人观点，参考。

Q2、为了实现双活，对于自动化运维监控，运维工具双活的要求和实施方案？

@赵海 技术经理：

如果实现了双活架构，那么对于运维最大的挑战就是跨数据中心级的部署，包括应用的发版以及运维变更及工具部署等等。如何保障版本的一致性和工作的自动化高效化是我们应该考虑的首要问题。

从两个方面发来考虑，第一个方面就是我们建设的时候需要考虑基础架构本身，变更对象在变更、测试、上线之间可以通过自动化脚本去调用负载均衡资源池的接口完成这些动作，而不是手工去进行操作。第二个方面就是运维工具的设计，人工的操作就会产生差异，同一个业务不同节点上的变更有可能存在差异，为了避免这个风险我们可能需要投入很多人力在晚上去做测试和确认。但是如果是自动化工具去做这些事儿，最起码可以保障这个差异会没有或者概率很小。唯一需要保障的就是编写在自动化工具里面的任务是否正确。

Q3、应用层同城双活中，自动化运维工具、监控工具的实施方案有没有什么推荐？

@赵海 技术经理：

数据库方面，感觉maxgauge不错，不仅仅监控，而且可以做优化解决方案。可以研究研究。

OEM如果加上DBA的精心设计，也不错，可以实现很多个性化的解决方案。

更多难点和应对之道可以参考此资料：

城商银行同城双数据中心建设技术手册

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