邓毓
作者邓毓2019-01-02 18:09
系统工程师, 江西农信

城商银行双活容灾建设方案设计难点总结

字数 6630阅读 3791评论 1赞 6

前言

近年来,随着互联网金融的快速发展,金融企业数据中心建设面临着新的挑战。那就是对RTO和RPO的极限追求。从而也就诞生了近年来的热点话题-双活数据中心建设。
那么我们为什么要建设双活数据中心,它能给我们带来什么样的价值?什么样的数据中心架构叫做双活数据中心?如何认识适合自己业务模式的双活模式?建设阶段我们应该以什么样的原则来指导我们的建设工作?具体的建设思路以及具体的建设方案应该如何把握?基于这些问题本文进行深入研究并展开探讨。
从科技工作层面来讲,其实双活数据中心并不是一个行业标准或者规范。行业的标准是对RTO和RPO约束,银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准,RPO=15分钟,RTO=30分钟。而根据国际标准share78,六级容灾标准是RPO=0,RTO=分钟级;七级容灾标准是RPO=0,RTO近似为0。双活的概念也就由此而来,为了达到国际最高标准。
那么决策是否建设双活数据中心的依据也就在于此,首先确定自己企业合适的目标,是不是要必须追求7级标准?是不是所有业务都必须追求这个目标?如果不是那么首先要对企业业务进行细分并详细规划每一个业务的容灾目标。这将决定要不要建设双活数据中心以及建设什么样的双活数据中心。
为帮助同业在双活容灾建设项目规划和建设过程中提供一些启示和帮助,TWT社区于12月26日至27日,组织了银行业双活领域的数位专家,就系统架构集成、资源云化、存储整合以及数据容灾等多个关键方面详细探讨了同城双活与容灾规划思路以及建设过程。下面将整个活动的主要内容进行总结,主要分为以下四个方面。如有遗漏之处,还请见谅。
1、同城双活架构与容灾架构改造方面
2、双活数据中心应用交互与流量分发方面
3、存储、数据库、应用、资源池等不同维度的容灾和双活技术方面
4、双活上线的标准、监控及自动化运维工具等方面


公共问题:

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

【Q1】针对存储级复制实现主备中心数据同步的架构,如何改造成双活的模式?
邓毓  系统工程师 , 江西农信

这个双活范畴比较大,看您是想实现的什么样的双活,双活的节点有没有共享存储数据等。
最简单的应用双活,不共享数据的话,主备数据中心的架构,打通了大二层网络,将应用节点部署于两个站点,通过负载将请求分发到这些应用节点,实现应用节点的跨数据中心多活。
其次是存储双活,这时需要专门的双活存储作为必要条件,或者通过能够实现双活的虚拟化网关来帮助原有的存储实现双活,存储双活后,对应用节点需要跨数据中心共享数据,有很大的便利。当然也可以作为数据库双活的后端存储。
最后是数据库双活,对能够实现双活的数据库方案,跨两个数据中心拉开的方案,如ORACLE EXTEND RAC、DB2 GDPC等,数据库实现事务级的双活

【Q2】Oracle RAC+ADG的方式实现双活是否有相关案例?灾备从AS转换到AA的建设有什么建议?
邓毓  系统工程师 , 江西农信

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

赵海  技术经理 , 大连

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

【Q3】同城双活架构当中,最关键的几个技术点以及思路?
pangluck  系统工程师 , 中鼎

1、网络层面,两数据中心要实现二层打通。
2、应用层面,虚拟化。
3、数据层面,存储复制+ADG。

【Q4】同城双活架构当中,关于网络二层打通的技术选型,VxLAN技术可行性?
asdf-asdf  研究学者 , cloudstone

大二层并不是必须vxlan, 更严格规划好当前的 vlan网络使用pvlan技术 一样完成大二层打通,
但 安装技术可行行 vxlan是可行的

【Q5】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的精心设计,也不错,可以实现很多个性化的解决方案。

技术难点问题:

【Q1】如何从存储层,数据库层,应用层的角度切入思考业务系统整体双活与容灾方案?
赵海  技术经理 , 大连

对于业务的整体双活,我是这么理解的:只要同一项业务能同时在两个数据中心完成,并且在发生数据中心级别的灾难的时候,业务可以无缝切换,这就是业务上的双活,不必关心应用如何访问数据库,数据库如何访问存储并最终将数据持久化。
如果我们的容灾目标如上所述,那么从系统架构层面去设计的化,可选的方案就会相对宽松。应用的切换可以靠网络、负载均衡、DNS结合起来去完成切换,二层网络的方案也有很多,Vxlan、OTV。至于数据库,也就没有必要去强调非得是两个数据中心都能去写,可以选择跨中心做写SQL。存储层也没有必要同时两边都去写,跨中心写也不是问题。总而言之,只要保障业务上的活,下面如何做,取决于我们关注的决策点和实际业务量级。

【Q2】同城数据库双活与存储双活方案如何理解与选择,是兼容并蓄还是舍异存己?
赵海  技术经理 , 大连

其实这个问题还是看我们的目标是什么,如果是业务上的双活目标。那么纵向保障可以支撑业务的双活就成。至于数据库和存储是否全部要双活,我觉得看你双中心之间的掌控力有多强,可以承受的风险有多大,再有就是业务的量级。因为无论是数据库双活还是存储双活,致命的地方就在于两边节点之间的通讯质量。

【Q3】做数据库同城灾备,对于同城和异地的灾备都有哪些方案?每个方案适合的条件是什么呢?
邓毓  系统工程师 , 江西农信

数据库同城灾备目前两种比较好的方案
第一种是数据库本身的数据库复制技术实现,ORACLE DG、DB2 HADR、MYSQL主从等,通过活动日志的同步和重做,让同城端和异地端的数据库数据保持一致,试距离和对RPO的要求不同,通过不同的同步间隔,来保证数据的RPO要求,同时也不至于因同步导致主库的性能压力,比如同步、准同步、异步和超异步等。这种数据库本身的复制技术,对两个数据中心的存储型号、品牌是否一致没有要求,尽量保证性能能够相近即可。也就是说不需要两个存储要通过存储级的复制技术来同步底层数据,所有数据同步都走的大二层TCPIP网络进行。这种方案还有一个好处,灾备端可以读数据,进行一些查询功能。
第二种是存储级的复制技术实现数据级灾备。像METRO MIRROR、TURE COPY、SRDF等存储级的复制技术,通过数据块的同步来实现底层存储数据的一致,对RPO的要求不同,可选择实时同步和异步两种方式进行,对两个数据中心的存储型号和品牌要求较高,能够搭建起远程复制关系。数据复制到灾备端之后,数据是不可读取和写入的,只有对灾备端的这份数据做快照在映射给其他机器时,才能使用这份数据做测试,当然整个快照和映射过程也可以脚本化,方便使用。

【Q4】oracle extend rac在实施中有哪些需要注意事项,对网络延迟要求如何?
赵海  技术经理 , 大连

理论上5ms之内,但是还得看具体业务负载如何,根据自己环境自己的业务来看,可控的范围内尽量小。

【Q5】跨中心的存储集群和数据库集群叠加的场合,如何保障系统整体协同一致?
赵海  技术经理 , 大连

存储集群和数据库集群叠加的场合,要保障系统整体协同一致性最关键的是如何保障纵向上的动作一致性,也就是仲裁的一致性,假设上层和底层判断的标准不一致最终得出的结果也不一致,那么系统整体上就出现了瘫痪。数据库的仲裁以网络心跳和存储心跳为基准,存储一般回以网络探测为准。所以时间顺序上必须保障数据库在存储之后做仲裁,这个理论上可以从仲裁时间参数ctssout上来做调整,第二方面,存储链路上是有切换时间参数设置的,这个时间参数设置必须要与仲裁时间参数ctssout保障一致。假设链路切换延后,那么就会出现抖动问题,这个比直接的故障更可怕,很多案例都是因为这个原因导致的。第三方面,存储的仲裁究竟是以固定算法为基准还是以第三方仲裁点为基准必须考虑到数据库层的仲裁机制,不能单方面做设置。

【Q6】类似于资源池层的容灾方案,像powervm,kvm和vmware等虚拟化资源池都有哪些匹配的方案选择?
类似于资源池层的容灾方案,像powervm,kvm和vmware等虚拟化资源池都有哪些匹配的方案选择?资源池层的容灾方案相较于应用层或者操作系统层的解决方案有何异同?

邓毓  系统工程师 , 江西农信

POWERVM的计划性VM迁移有LPM,非计划性的迁移有REMOTE RESTART,灾备方案有GDR
VMWARE的迁移VM有VMOTION,更高级的有FT,灾备方案有SRM
KVM相对来说VM的保护方案很弱,仅仅能离线V TO V
这种基于资源池层的容灾方案,是相对于应用层和操作系统层的解决方案而言的,从虚拟化资源池的角度,给出VM的计划内和计划外的在线迁移、甚至是跨数据中心的在线迁移,从资源池层来实现对VM的保护。
而操作系统层的,比如HACMP、TSA、KEEPALIVE、PACEMAKER等方案,是基于多个VM搭建的高可用架构,实现主备的热保护,用于故障的切换而非迁移方案。应用层的方案是基于多应用节点的集群多活方案。

【Q7】如果主备中心的应用系统IP地址相同,是否一定要改成域名的方式才能进行双活?
是否有不需要修改服务器IP地址的方式?

赵海  技术经理 , 大连

不用域名方式,架构的扩展性和灵活性回受到很大限制,包括运维的复杂度。

邓毓  系统工程师 , 江西农信

主备数据中心应用IP地址相同,平时只能一边对外提供服务,另一边不可以启用,否则就IP冲突了。
另外DNS域名解析是将域名解析为IP地址,是1对1的关系,无法将两个不同的域名解析为同一个IP地址。
如果要双活,主备两个中心的应用必须设置不同的IP地址。

【Q8】双活中心的文件同步,使用FTP方式,是否能保证实时性和一致性?
邓毓  系统工程师 , 江西农信

可能没大看明白您真正的需求,我就尝试着从你的文字上,理解您的问题,尽量解答一下:
您的问题是否是,一个数据中心的文件数据,需要从另一个数据中心通过FTP去读取和更新,能否保证这个数据中心的文件实时性和一致性?
那答案肯定需要结合你FTP读取的频率是否高于文件的存放频率,如果如此,那么文件数据的一致性和实时性是可以得到保证的,如果不如此,那实时性和一致性不能得到保证。
当然仅仅通过FTP的方式去实现跨数据中心的文件共享,我觉得不是一种好的方案,类似于共享文件系统的方案可能更适合您,比如NFS共享,或者跨数据中心的并行文件系统等都是更优的方案。

asdf-asdf  研究学者 , cloudstone

用ftp 你还不如用 rsync + inotify , 或者双向, rsync + sersync 系统, 
真正实现文件完全一致需要强校验系统的文件同步工具.
推荐你研究下 ipfs 应该有启发

【Q9】存储的心跳仲裁?有的建议放在主数据中心,有的建议放在第三方?如何抉择?
赵海  技术经理 , 大连

放在主数据中心,万一主数据中心发生灾难。仲裁有啥用?
所以,必须放在第三个点。

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

6

添加新评论1 条评论

#michael1983技术经理, 某证券
2019-01-09 10:50
这种类似的总结,很好,不错
Ctrl+Enter 发表

本文隶属于专栏

活动总结
活动总结是社区交流活动内容的总结及延伸,为大家提供了社区专家们丰富且高水平的理论知识、实践经验以及常见问题的最佳解决方法,非常值得大家收藏学习。

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30