基于VPLEX的农商银行双活数据中心方案设计.docx

基于VPLEX的农商银行双活数据中心方案设计.docx

《基于VPLEX的农商银行双活数据中心方案设计.docx》由会员分享，可在线阅读，更多相关《基于VPLEX的农商银行双活数据中心方案设计.docx（12页珍藏版）》请在冰豆网上搜索。

基于VPLEX的农商银行双活数据中心方案设计

基于VPLEX的农商银行双活数据中心方案设计

【摘要】数据作为金融行业的生命基石，追求其安全是一个长期的课题，因此衍生出同城灾备、两地三中心，多地多中心等等，技术发展也日新月异。

作为中小规模的农商银行，按照监管要求需要建立同城灾备中心。

基于这样的监管要求，农商行的科技规划者一般都会选择“同城双活”的灾备方案，这种方案可以保持较低的RPO、RTO，切实达成监管要求，能够让备中心真正使用起来，分散主中心负载，降低资源浪费，降低企业成本。

目前“同城双活”整体方案已经较为成熟，各层的解决技术也有很多，本文中将重点介绍存储的双活解决方案。

目前可以选用的存储双活方案较多，比如华为HyperMetro、DellEMCVPLEX、IBMSVC、HDSGAD、NetAppMetroCluster等，各方案均有其优缺点，根据业务场景的不同可以选择不同的方案使用，在我行中我们选择了DellEMCVPLEX作为存储双活方案。

1.背景及综述

按照《商业银行业务连续性监管指引》第二十五条要求，我行的重要业务恢复时间目标（RPO）不得大于4小时，重要业务恢复点目标（RTO）不得大于半小时。

为实现这一目标我们将采用业界通用做法，建立同城双活灾备中心。

应用双活主要通过动态DNS解析+GTM+LTM的架构实现，数据层的双活则通过OracleExtendRAC+DellEMCVPLEX来实现，除主备中心外增加了一个仲裁中心，部署Witness，与主备中心实现以太网高可用，具体架构如下：

2.方案分析

个人认为同城双活的实现是基于两个层面：

其一是网络引流，其二是数据引流，通过正确的负载配置将业务请求分配到正确的应用服务器处理，应用服务器又能将数据读写合理分配，最终满足业务要求的响应时间，那么这个双活方案就是可以落地的。

而在大部分业务交易中，数据的处理更加消耗时间，因此合理的数据处理方案是大部分方案的重点，本文将结合我行采用的存储双活方案介绍数据的处理。

2.1存储双活需求分析

双活中心的字面意思是两个“活着”的中心，也就是说两个中心都能处理业务请求，那么两个中心的应用服务器处理请求时如何获取数据或者存储数据？

在相同条件下，传输距离越短，数据传输越快基本是我们的共识，基于这个共识我们都想将存储和服务器放在一起，这样获取数据或者存储数据的时间最短，但是现实中，灾备中心的服务器与主中心的存储必然存在着一定的距离，那么由于传输距离的拉长，存储数据势必会产生较长的处理时间，但是如果双数据中心各自存储数据，那么又与数据一致性的原则相背离，如何平衡这种需求是存储双活的重点。

目前市场主要有以DellEMCVPLEX为代表的分布式全局读缓存的存储双活；以华为HyperMetro为代表的使用Vdiskmirror技术的存储双活；以IBMSVC为代表的MDG技术的存储双活等等，如何选取适合自己的双活方案？

首先考虑业务的响应容忍性，传统银行业务仍然以线下业务为主，也就是柜面业务为主，对业务响应时间有严格要求，核心的响应时间要在100MS以内；

其次考虑业务的对重要业务的中断容忍性，银行业关系国计民生，业务中断会引起普通民众恐慌，会造成国家秩序的混乱，因此业务系统的稳定性是银行业首要注重的，推及银行科技方面，银行业的科技发展也是最注重安全性与稳定性的；

再次考虑本行的科技能力，我行维护人员较少，因此尽量减少变更，设备故障时尽量避免手工切换动作；科技发展成本较少，因此尽量减少资源浪费；

再次行内近年来发展速度较快，业务种类较多，设备的可扩展性尤为重要；

最后，大部分存储双活技术都与其存储产品相绑定，是否接受被厂商绑架成为我们选择技术时一个非常重要的指标。

基于以上这些考虑，我行选择DellEMCVPLEX产品为我行实现存储双活。

DellEMCVPLEX具有哪些优劣势，又是如何和我们的需求相结合的呢？

·DellEMCVPLEX是透写，同时在传输路径中增加存储网关设备，拉长了传输路径，所以其在写操作中不占据优势，影响一定的写I/O，但是仍然能够达到RTT<5ms的要求，完全满足业务对于写交易类操作对响应时间的要求；

·其读I/O加速功能较为优秀，能够有效提升读交易类操作的响应时间；

·DellEMC存储设备销量世界前三，其稳定性、安全性均超越同行业大多数产品，与我行发展首重稳定的原则相适应；

·磁盘镜像功能完全下放到存储层面，主机仅需要安装一个多路径软件，大大降低主机配置复杂性与主机消耗的同时，能够自动进行路径的智能选择，减少变更操作，而且扩容时也降低主机操作的风险。

·使用存储网关，可以支持异构存储的使用，避免被厂家绑定，同时存储设备的扩容工作也相对简单。

2.2存储双活架构设计

对于双活存储架构的讲解主要从物理架构、存储逻辑以及分布式缓存一致性逻辑三个方面。

物理架构

1、双中心分别部署两台VMAX10K、1台VPLEX、多台SANSwitch、以及两台DWDM；

2、双中心的SAN网络传输通过DWDM+裸光纤完成，既能对链路稳定性有所保障，DWDM的渠道分层能力也能承载业务数据按重要程度进行传输；

3、两台VPLEX组成Metrocluster，通过AccessAnywhere能力实现双中心读写，通过mirrorvolume功能实现双中心的数据一致性；

4、第三方仲裁站点的使用，保证双中心连接网络故障时的主存储判断。

存储逻辑

1、VMAX10K存储提供出LUN交给VPLEX，VPLEX将其claim,纳管到VPLEX形成storagevolume;

2、Storagevolume经过一层封装形成extend；

3、各中心的两个extend再次封装成localdevice；

4、两个中心的localdevice组成跨集群的distributeddevice；

5、distributeddevice再次经过封装成virtualvolume通过storageview让主机识别到，识别到的盘相当于主机的一个dev。

分布式缓存一致性逻辑

VPLEX的关键能力AccessAnywhere是通过分布式一致性缓存技术（DistributedCacheCoherenece）来实现，在集群内及跨区域的另一集群间完成缓存数据的一致性；实现跨主机、跨集群、跨数据中心的访问和在节点之间同步镜像。

VPLEX通过把控制器的单个内存系统进行合并以形成分布式缓存。

分布式设计可以跨VPLEXMetro系统进行扩展，以提供全局系统的缓存连贯性和一致性，单一控制器或引擎出现故障时，其负载会转移到其他引擎和控制器中。

分布式一致性缓存技术在实现上面，并没有强求所有的Cache都保持统一，而是基于目录形式来跟踪细小的内存块通过锁的粒度来加强扩展能力。

每个引擎的cache分为本地Cache（Cachelocal）和全局Cache（Cacheglobal）。

如上表：

VPLEX把数据块和引擎的关系抽象为一张目录称之为cachecoherencydirectory,它是属于全局目录，每次I/O都会更新这个目录，这个目录在所有引擎之间共享。

这个目录使用少量的metadata来告诉其他引擎哪一个数据块在哪个时候属于哪个引擎。

每个Director都有一份该目录的copy。

除此之外，每个director中都有本地cacheDirectory，同时在remoteDirector中也会有一份镜像，如图中DirectorA中就有directorC的mirror。

写逻辑

·VPLEX采用了“write-through”（透写）的缓存模式，即VPLEX并没有实际意义上的写缓存，数据不并在VPLEX缓存，而是写到后端存储的cache。

只有后端存储返回写确认后，主机端的本次写操作才算完成。

·具体操作如下：

·假如主机发出一个NewWrite，该请求将被分配到DirectorA，DirectorA会去检查一致性缓存表（cachecoherencytable也就是cachecoherencydirectory，每个Director都有一份相同的）确认该写操作要求修改的是哪个block，从图中我们可以看到是要对CacheA的3号block以及CacheC的5号block进行修改，同时要看是否有其他主机对CacheA的3号block以及CacheC的5号block有锁定。

·若有，则等锁被释放后，在cachecoherencydirectory进行更新标记在DirectorA的localcache的3号block和在DirectorC的localcache的5号block是dirty的并通告Metro-Plex中的其他Director说这个全局目录有变更了。

·这样在cache中拥有这个块的local和remoteDirector将更新各自的目录拷贝以示在其cache中的数据是无效的了，即DirectorA的cachedirectoryA和其在DirectorC中的cachedirectoryA_mirror，DirectoC的cachedirectoryC和其在DirectorA中的cachedirectoryC_mirror更新各自的目录，宣告在DirectorA的localcache中的3号block的数据以及DirectorC的localcache的5号block是无效的。

·然后DirectorA、DirectorC分别将数据写入各自对应的存储的Cache中，然后分别返回ACK信息，只有两个存储中的数据均落盘以后，才给HOST返回ACK信息，通知HOST，NewWrite完成。

读逻辑

VPLEX的分布式缓存一致性功能主要是对读操作进行加速。

读的时候先读LocalCache，如命中直接读取；如在Global中命中，则从对应的引擎Cache中将其读取到CacheLocal，再反馈主机；如没有命中，则从本地后端的存储中读取到Local中，并同时修改Local和CacheGlobal中的信息与索引信息。

具体操作如下：

·假如HOST发出一个Read，该请求将被分配到DirectorD，首先搜索DirectorD的CacheLocal，如果hit，则直接读取，返回信息给HOST。

分布式缓存一致性起到最好的加速作用；

·如果DirectorD的CacheLocal是miss，那么搜索CacheGlobal，如果确认数据在DirectorC的CacheLocal中，那么直接从DirectorC的CacheLocal中读取，返回信息给HOST。

分布式缓存一致性起到较好的加速作用；

·如果都没有hit，那么需要到本地后端的存储中读取信息到DirectorD的CacheLocal中，返回信息给HOST，同时更新CacheLocal和CacheGlobal中的信息与索引信息。

分布式缓存一致性不起加速作用。

3.重点难题

VPLEX在使用中遇到的难题以及如何解决？

下面我们将从几个方面进行讲解。

首先我将常见难点总结绘表如下，并根据该表的情况逐一分析：

关键难点

主要风险

解决策略

如何解决集群（RAC&VPLEX）仲裁一致性问题？

数据库和存储仲裁不一致；

RAC集群无法对外提供服务，系统夯死；

集群发生脑裂现象；

VPLEX：

PreferWinner=LowestClusterID。

WitnessSite：

保证站点间的以太网络高可用。

Rac：

PreferWinner&RAC'slowestinstance=同一站点；CSSmisscount>Witnessdetachtime。

如何解决写IO延时扩大化问题？

如何解决双中心链路不稳问题？

数据库热点急剧扩大；存储链路频繁切换；集群仲裁事件频繁被触发；

跨中心通讯：

保证VPLEX同步及Rac私网为第一优先级。

跨中心带宽：

根据功能区分，实现具体限制。

读写规则：

批量&联机区别对待。

如何解决SAN网络中的故障无限扩展问题？

计算节点的存储接入点故障导致整个存储网络发生面积性故障；

计算网络：

每个中心建立自己的核心SAN计算网络。

存储网络：

存储设备间单独建设自己的SAN网络，并整合双中心为统一存储SAN网络。

3.1集群仲裁一致性问题

我们建设系统的目的是什么，是给予业务发展以强有力的支撑，是为业务服务的，如果业务做不了，要数据中心就没有意义。

RAC&VPLEX仲裁一致性有多么重要，我们举例说明，比如两中心发生通讯故障时，数据库判断A中心的节点为活的节点，对外提供服务，存储判断B中心的节点为活的节点对外提供服务，这个事情A中心数据库接受到的数据无法落盘，B中心的存储启用着却没有数据请求，最终导致数据库无法对外提供服务，应用也最终夯死。

第二种情况，RAC&VPLEX仲裁一致性导致脑裂的出现，这种事件是一种非常小的几率性事件，但是这种事件导致的结果却是会产生非常恶劣影响的。

假设RAC&VPLEX仲裁结果并不一定一致，双中心的链路不稳定，链路的传输抖动会引起RTT时间超时，那么此时RAC与VPLEX都会发生仲裁，第一次仲裁时，RAC判定A中心节点可用，存储判断A中心节点可用，RAC与VPLEX都要阻断B中心的节点可用性，所有的数据存储动作都要向A落盘，然后链路稳定，B中心的节点恢复正常使用。

A存储向B存储同步数据，在存储还没有将数据同步到B中心节点的时候，链路再次传输抖动，发生仲裁，如果此次仲裁的结果是B中心节点正常，可以接受数据落盘，那么双侧就会数据不一致，形成脑裂。

当脑裂发生时我们无法判断以那边的数据作为基准数据进行恢复，最终可能丢失一部分的数据，数据是企业的生命基石，如果数据都无从保证，灾备中心的意义何在？

综合以上两点，RAC&VPLEX仲裁一致性问题对于灾备中心的建设绝对是影响巨大的，那么我们如何解决这种问题？

·VPLEX：

PreferWinner=LowestClusterID，在VPLEX的仲裁策略中设置仲裁时ClusterID小的为winner，那么仲裁发生时，除非ClusterID小的节点故障，否则都以小节点为优胜者。

·WitnessSite：

保证站点间的以太网络高可用。

·Rac：

PreferWinner&RAC'slowestinstance=同一站点；CSSmisscount>Witnessdetachtime。

RAC集群的仲裁策略也是instanceID小的为winner，并且和VPLEX的ClusterID小的节点在同一中心，同时CSSmisscount时间应该大于VPLEX的Witnessdetachtime，即存储仲裁优先于RAC仲裁。

这样在链路不稳定的情况下，集群总是仲裁节点ID小的那一边为winner，这样恢复数据时就以节点ID小的一边为基准，这样就不会产生数据不一致。

同时因为RAC和VPLEX的仲裁winner都在同一边，也不会产生服务夯死的状态。

3.2双中心链路不稳定问题

我们建设同城灾备时要非常注意这个问题，避免光纤的问题影响我们的双中心运行。

我们是如何做的？

·使用DWDM设备+裸光纤作为双中心链路的传输手段，并且均做到冗余，对于光纤不仅仅要做到链路冗余，还要保证其物理跳接路径的冗余；

·DWDM增加OLP单板，监控链路状况，保障稳定也可以自动进行切换。

3.3I/O延迟扩大化问题

I/O延迟会导致数据库的热点急剧扩大，对设备的性能是一种考验，如果设备性能不足，那么很容易产生宕机的风险，最小的风险也会导致业务上的响应延迟，业务端频繁报错。

对此我们通过以下方式进行一定的保障：

·DWDM上做好通道划分，将VPLEX数据同步以及RAC心跳私网作为第一优先级进行数据传输；

·跨中心带宽按照功能分区实现具体限制；

·对业务系统进行一定的优化，分离读写，区别对待，比如核心系统的批量与联机交易，可在不同节点或者不同中心执行。

·使用VMAX存储的FAST策略，对存储的数据进行分层及二次Cache的保障，重点业务使用SSD盘，次重点使用SAS盘，同时可以使用SSD作为内存Cache下的二次Cache，既能节省成本的投入，又能保障I/O的延迟较小。

3.4SAN网络中的故障无限扩展问题

SAN网络中节点故障很容易引起整个SAN网络的瘫痪，直接影响业务的运行，对此我们需要给SAN网络进行区域划分：

·每个中心建立自己的核心SAN网络；

·主机与VPLEX的SAN网络分区可以按照系统重要性单独建设；

·VPLEX与存储的SAN网络分区也要单独建设；

·整合双中心存储网络为同一SAN网络。

4总结

在双活数据中心中，VPLEX的使用是较为成熟的方案，对读操作有明显的加速效果，VPLEXMetro可以满足RTT<5ms的要求。

我行的数据库最主要等待事件dbfilesequentialread一直维持在5ms左右，完全符合应用响应时间的要求。

同时其纳管异构存储的功能是相对强大的，保证行方不被存储厂商所绑定，同时也可以使用利旧存储设备，避免资源的浪费。

考虑我行当前的业务规模以及未来5年的发展，VPLEX产品的扩容能力已经完全足够，且扩容较为方便。

VPLEX产品稳定性非常好，虽然使用透写技术牺牲了一部分性能，但是却给数据的安全性增加了保障，我们的根本就是要保障数据的安全与准确性，VPLEX在双活中的使用恰恰迎合了我们的需求。

VPLEX的配置相对简单，支持GUI及CLI，分层清楚明确，并且形成的结果可以直接查看MAP界面，直接看到每次封装的结果，对于新员工很友好，上手速度很快。

综上所述，VPLEX产品的稳定性、安全性、高可用性、可扩展性、操作界面友好这些优点让我行选用这个产品作为存储双活的最终方案。