城商行核心业务系统存储跨中心双活建设方案Word格式.docx

上传人:b****4 文档编号:6649975 上传时间:2023-05-07 格式:DOCX 页数:15 大小:376.35KB
下载 相关 举报
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第1页
第1页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第2页
第2页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第3页
第3页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第4页
第4页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第5页
第5页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第6页
第6页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第7页
第7页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第8页
第8页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第9页
第9页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第10页
第10页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第11页
第11页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第12页
第12页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第13页
第13页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第14页
第14页 / 共15页
城商行核心业务系统存储跨中心双活建设方案Word格式.docx_第15页
第15页 / 共15页
亲,该文档总共15页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

城商行核心业务系统存储跨中心双活建设方案Word格式.docx

《城商行核心业务系统存储跨中心双活建设方案Word格式.docx》由会员分享,可在线阅读,更多相关《城商行核心业务系统存储跨中心双活建设方案Word格式.docx(15页珍藏版)》请在冰点文库上搜索。

城商行核心业务系统存储跨中心双活建设方案Word格式.docx

@alphaaries 

华为数据存储解决方案中心 

技术总监:

要做读写分离首先要明确为什么要做读写分离。

读写分离是一种技术手段,而单纯的依赖技术手段是无法解决所有问题的,如果应用的读写比例严重失调,那么需要和应用开发部门相互协调。

读写分离的重点和本质,其实就是数据的同步。

为了实现数据的实时同步,现有的技术可以在多个层面实现读写分离。

例如,基于操作系统层、基于存储层进行复制或者基于应用分发或者基于数据库自身的能力的技术,都可以实现数据的读写分离。

由于在数据同步的过程中,通常会涉及业务数据选择以及源端多种类型整合的问题,因此通常不建议使用操作系统层和存储层的复制来实现,在金融行业,比较多的是用数据库来实现读分离。

例如Oracle基于日志的复制技术等等。

2、两个数据中心间数据同步逻辑错误问题如何有效避免呢?

【问题描述】存储层面的复制技术基本以存储块为单位进行的数据复制,假设数据块发生了逻辑错误,那么存储是无法检测到的,它会继续将坏的数据块儿同步到灾备端,如果因此数据库发生宕机,那么灾备端的数据库也同样无法正常启动。

虽然发生几率比较小,但这个问题确实存在。

个人建议是采用磁带库或者CDP进行再次备份,若真的遇到逻辑问题还是重新恢复数据。

或者干脆采用分布式存储。

无论复制方式是同步、异步、双活还是连续性数据保护,都是基于存储数据块级别的复制技术,复制源端在可读时,会将块中的数据原样的拷贝一份至目标端,当源端数据出现误删、误改、磁区退化数据异变、数据库事物层逻辑错误等数据逻辑性错误时,复制目标端无法检测到这些错误,依旧复制“错误”的数据,导致两份副本都无法正常使用。

所以要设置多层次的防范机制,保障数据的可靠性和安全性,存储双活技术只是其中的一个层次,要辅以备份技术、数据库复制技术,连续性数据保护,建立了完善的数据保障体系。

(1)备份系统按照一定的时间频率对数据库做全量和增量备份,在遇到数据逻辑错误时,通过恢复将数据回退到最后一个备份版本。

如TSM、NBU、COMMVAULT。

(2)数据库复制技术有实时同步、准同步、异步等方式,保障主数据库逻辑错误无法正常运行时,切至备数据库,回退到备库前一个日志COMMIT后的版本。

如DB2HADR、ORACLEADG、MYSQL主从复制等。

(3)连续性数据保护技术也是准/实时对存储数据块做快照,源端数据无法继续使用时,通过快照回退至前一个数据可用版本。

如CDP。

为了不影响源端数据的访问性能或者单个系统无法满足需求时,可以考虑多种方式结合,比如备份系统在备份超大数据库时,没有充足的带宽或者备份时间窗口,可以用数据库的异步复制方式来做为备份方式的补充;

连续性数据保护技术需要通过LVM镜像源端数据,增加了写延迟,可以通过数据库准实时同步或者异步的方式复制数据到备库节点,备库节点的后端存储为连续性数据保护的存储节点,如DB2HADR+CDP的组合。

无论是adg数据库复制技术还是存储复制技术都无法预防逻辑错误,预防逻辑错误最好的办法就只能是通过备份,当出现逻辑错误的时候,通过备份数据及备份的日志文件进行数据回滚,回滚到逻辑错误前的时间段数据。

@zzy3620 

北部湾银行系统环境管理:

因此需要进行多个层面的备份,在存储备份之外,通过数据库软件例如goldengate,adg等方式,进行实时或者准实时的逻辑备份,避免存储块错误的同步导致数据丢失。

3、双活数据中心如何保证各个业务系统之间访问路径最短?

【问题描述】双活数据中心如何保证各个业务系统之间访问路径最短?

银行系统中有可以建立双活的业务系统,也有不适合双活的业务系统,当某一个业务系统同城切换演练,需要考虑那些因素而决定需要配合切换的业务系统?

一般来说,双活数据中心架构下,一旦业务访问流量进入以后就只在当前数据中心内部系统间进行交互,尽量不要跨数据中心进行系统间交互访问,这样能确保访问路径最短且把跨数据中心间业务影响降到最低。

当单系统进行切换演练的时候,根据业务优先级,把保开门的业务所涉及的重要系统实现跨数据中心访问即可,其他非关键业务所涉及的业务系统保持关闭不提供服务。

一般来说,核心业务系统相关的数据内容是优先作为双活的,其他业务系统如渠道、客户、交易结算、供应链金融、票据等根据业务优先级由科技统一规划。

具体要综合考虑本行数据中心机房基础环境、网络、系统的特点以及分批次业务系统的相关特性,综合新一代核心业务系统建设目标和项目要求,设计相对应多层业务调度框架,使用纯IP访问、动态分配负载方式的应用级双活建设部署方案。

多层业务调度框架,就是在同城两个数据中心的核心网络层部署专用的全局调度负载均衡设备来专门处理跨数据中心的交易数据调度;

在每个数据中心内的各业务生产区域,同样部署了区域负载均衡设备,用于对应用服务的负载均衡交付服务。

4、在存储双活设计初期,如何合理的规划双活架构,使之成为一个健康高效的架构?

@潘延晟 

系统工程师:

所谓合理,其实是根据企业的自身情况而定的,业务量,技术储备,资金能力,还有双活的实际环境都决定了整体架构的不同,

目前的双活技术都比较成熟,不过却并不一定适应所有的环境。

设计初期,一定要考虑企业自身实际的情况。

现有的存储环境如何,上层业务采用的技术是虚拟化,容器还是其他,是考虑搭建全新环境还是要考虑旧的业务系统,对比不同的技术方案的资金和技术需求,是否是企业所能承受的,是同城双活还是异地双活,双活之间的数据传输采用的运营商线路带宽的稳定性和性价比。

所以并不能简单的用一套方案来作为企业存储双活的建设依据。

存储双活的规划一定要依从数据中心的整体规划而实现,通常的规划分为业务规划、应用规划、数据规划和基础设施规划,存储的规划隶属于基础设施的整体规划。

在实现基础设施规划的时候,要依据自下而上、自外而内的规则来实现,即首先需要规划机房、网络,然后才会是存储产品和计算资源的规划。

所以在规划之初,需要首先了解整个业务的关联性,并需要考虑网络的整体规划,是采用边缘核心的网络设计还是边缘核心边缘的网络设计?

如果是边缘核心的网络设计,将相互之间有关联的应用尽可能的部署在相邻或者相同的资源池里;

如果是边缘核心边缘的网络设计,组网可以灵活调配网络资源。

除此之外还需要考虑数据中心之间的网络,距离、延时等等都是需要考虑的问题。

因此存储双活需要有非常详细的规划设计,华为在存储双活规划设计方面有大量的解决方案和交付案例。

@chenmingfu 

宁夏银行股份有限公司 

基础架构组长:

其实如果就存储双活来看,相对较为简单,目前主流存储厂商就那么几家,几乎每家都有成熟经验且使用案例也多,所以根据业界使用情况采用厂商的方法即可,唯一要做好的就是选择好合适的第三站点仲裁及通讯线路。

5、如何有效保证存储层双活和数据一致性,以及发生故障时如何保证前端业务的正常运行?

【问题描述】1、存储双活双活依赖的的必要条件有哪些,如发生发生故障故障或中断时的应急方案。

2、故障发生时如何保证业务业务连续性和数据数据的一致性?

@chenmingfu宁夏银行股份有限公司 

1.针对存储的双活,两台存储中的不同的LUN构成双活LUN,提供给上层的主机使用,数据是从主机侧同时写入两个存储的LUN内,双活平台没有故障的时候,两端的数据始终是一致的。

2.如果存储的双活出现的故障,此时,双活平台内部有仲裁机制,从两端中会重新选举一端的存储平台作为主存储给前端的主机继续提供服务,待存储的双活修复好了后,双活两端的存储内部会自行比对,将存在的差异、增量的数据进行同步,待两端的数据一致后,继续双活对外提供服务。

3.对于双活架构下,会包含很多的层面,比如应用层,数据库层,服务器层,存储层等等,要实现真正的业务双活,必须做到每个层面都是活的,而每个层面都会有各自的技术来实现,数据的一致性也是通过这些层面采用的技术来保证的,比如数据层面采用oracleRAC,那么RAC需要解决的关键问题就是多节点进行数据访问时如何保证数据的一致性,Oracle是通过各节点间的私有连接进行内存融合(cachefusion)来保证各节点数据访问的一致性。

对于存储层面,如果采用了svc来搭建双活架构,那么其数据一致性是通过svc节点之间的缓存数据同步来完成;

当双活架构发生故障的时候,最主要的是避免集群的脑裂,避免脑裂的方式是一定要部署第三站点的仲裁机制,仲裁站点可以采用存储仲裁或者ip仲裁等不同的方式,避免集群发生脑裂,从而导致业务数据的不一致性发生。

@crazierspore华为 

产品总监:

一般来讲,需要考虑如下几方面内容:

6、双活存储性能影响问题如何避免?

【问题描述】双活存储系统在写入数据时,会写两次数据,尤其是通过复制功能写到远端存储的过程,传输链路的性能也会影响整体性能。

无法避免,肯定会影响一定的性能。

这是双活存储机制必然带来的。

只能尽量减少性能影响,比如减少距离,提升链路稳定性,降低写I/O频率,提升读写比例,适合写I/O时延敏感度不太高的应用等等。

租用多家运营商裸光纤加购买独立dwdm波分设备提升链路的冗余性及链路质量,从底层通讯链路层保障跨中心通讯的稳定性,从操作系统及数据库参数层面优化存储相关参数,尽量降低性能带来的风险,无法彻底避免。

双活在保证数据可靠性的同时势必会造成一定程度的性能影响,为了保证两个数据中心存储的数据实时一致,写操作都需要等待两端存储写成功之后再返回主机“写成功”。

双活I/O性能因为实时双写导致一定的时延增加。

双活容灾解决方案提升了站点级的冗余保护,把本地的双机双柜的硬件冗余方案跨站点建设,无论是传统的集群系统、虚拟化主机平台Vmware,还是OracleRAC等,跨站点建设都会无形中在业务平台中增添几分不稳定的因素。

在性能方案,站点间的监测、业务会话的同步确认等的网络延迟数,加上数据同步双写的光纤延迟,都或多或少的影响了整体业务处理的性能。

距离越远影响越明显,如果距离较近,也会失去建设双活容灾数据中心的意义。

针对以上对性能的挑战,华为主要从数据零拷贝、FastWrite功能、地域优化访问三方面来克服相应的挑战。

零数据拷贝:

在双活镜像数据的初始同步或者恢复过程中的增量同步过程中,差异数据块通常有大量的零数据块,无需逐块复制,该功能叫数据零拷贝。

例如,虚拟化场景下,新建虚拟机时会产生大量的零数据块,一个数十GB的操作系统盘,实际非零数据块仅2-3GB。

FastWrite功能:

对阵列间数据传输进行了协议级优化,应用SCSI协议的FirstBurstEnabled功能,将写数据的链路传输交互次数减少一半。

正常的SCSI流程中,写I/O在传输的双端要经历“写命令”、“写分配完成”、“写数据”和“写执行状态”等多次交互。

利用FastWrite功能,优化写I/O交互过程,将“写命令”和“写数据”合并为一次发送,并取消“写分配完成”交互过程,将跨站点写I/O交互次数减少一半。

地域优化访问:

双活数据业务场景,两站点的距离远近,是影响I/O访问性能的关键因素。

HyperMetro特性通过与华为OceanStorUltraPath多路径配合,根据双活站点部署距离,提供了两种I/O访问策略供用户选择。

负载均衡模式+优选阵列模式。

7、双活方案中的NAS复制及切换问题?

【问题描述】在同城双活的建设过程中,很多负载均衡的应用需要用到NAS来实现文件的共享,满足负载均衡的需求。

1、一般的NAS都采取网络复制到同城的方案,复制的内容一般没有办法实时同步,有一定的滞后,没有办法保证数据的完全一致,一旦生产发生问题,遇到需要切换的场景,可能会丢失一些数据。

有些对于数据一致要求较高的应用可能因为文件的不一致造成异常(比如一些批量作业)。

请问有什么好的解决办法?

2、请问在双活的建设过程中,关于NAS的双活或者容灾有没有好的成熟的解决方案或者产品?

如果是双活场景的话,可以考虑把nas存储也设置为双活,否则,采用主备复制的方式,nas文件系统在数据同步状态下同城端主机是无法mount这些文件系统的,这将导致nas文件系统无法实时使用,可以根据实际nas文件应用场景区分,没必要同步的就两边分别独立挂载各自数据中心内的nas文件系统,这样也能解耦。

@LX11华为 

高级工程师:

1)当前业界已经具备NAS双活技术,NAS双活采用AP架构,使主机能够将两个存储系统的文件系统视为单个存储系统上的单个文件系统,并保持文件系统的实时双写存放和读取。

2)华为Oceanstor存储具备免网关NAS双活能力,基于多租户(vStorePair)双活机制,可以将主Store的网络资源、协议配置及存储资源实时镜像到远端,保证两端资源实时一致。

同时,该系列存储也具备SAN&

NAS双活一体化能力,推荐使用。

首先看一些NAS的同步双写流程:

①同步双写由SPACE发起,当有主机IO时,SPACE转发给Pair;

②由Pair根据当前状态决定是否双写,如果是同步双写,则将IO拆分成两个IO,一个由源文件系统RIM实际写入SPACE;

③另一个IO通过目标文件系统RIM代理转发到从端;

④由EPL根据链路进行路由,通过TCP或FC或iSCSI链路转发到从端;

⑤当从端EPL接收到主端数据时,找到目标文件系统RIM,并由其写入目标文件系统的SPACE。

因此有关对于数据一致要求较高的应用可能因为文件的不一致造成异常的影响,一般由于切换时间引起。

影响切换时间长短的几个因素:

1、协议类型,推荐使用NFSv3协议,NFSv3属无状态协议,NFS受故障影响小,故障后直接重试直到响应,而CIFS和NFSV4属有状态协议,故障后还需维护自身的状态信息,遇到加锁业务时切换时间会更长甚至断业务,而且CIFS没有锁和句柄同步,对于已经加锁的文件故障恢复后没法恢复锁导致文件冲突,比如打开的文件遇到双活故障场景恢复后只能另存为文件,无法原文件保存。

2、挂载NFS时需要修改协议重试的时间参数:

-otimeo=XX,该参数的单位是1/10秒,默认值为600,建议设置成50,即重试时间5秒。

如果设置时间太短,阵列还没切换完成,会导致重试次数较多,整体时间较长。

举例:

mount-tnfs-overs=3,timeo=50/11.11.11.1/FS/FS

3、主机上运行的业务模型,如果是加锁类业务切换时间会比不加锁类业务时间长(针对NFSv4和CIFS协议),因为故障切换流程还需保障之前加锁的业务锁释放是否完成,是否会有锁冲突,比如VMware或者集群类业务。

为了排除是加锁影响,测试时挂在文件系统是可以加上nolock参数。

mount-tnfs-onolock/11.11.11.1/FS/FS

4、主机业务压力,这个原理很简单,如果主机上业务压力较大,故障切换时间就相对较长,因此测试时需要调小主机的业务压力,减小下IO的并发。

5、故障方式,掉电(拔电源)是非计划内的故障,需要阵列去感知掉电故障然后走仲裁,这里仲裁还需要静默8秒才切换,因此切换时间相对较长,而用下电或者重启的方式进行故障则是计划内的故障,阵列可以主动通知仲裁进行业务切换,会立即进行切换,最终的切换时间只由主机协议倒换时间长短决定,大概在5~10秒。

6、故障不同站点,掉电非优先站点,则无业务切换流程,只有故障处理流程,切换时间大概在5秒左右。

8、双活数据中心考虑哪些因素决定哪些系统适合二层哪些适合三层?

是否一些基础平台适合二层?

还是都建立为三层更好?

从当前趋势来看,不同数据中心间通过三层网络互联是主流技术,如果可能的话尽量不要采用二层互联的方式连接两个数据中心,这样能让两个数据中心间解耦,将影响和风险降到最低。

采用二层还是三层技术主要取决于一些技术储备和容灾需求,比如,引入dns技术以后就可以实现dns技术加三层网络的互联切换容灾。

根据最佳实践,建议以三层互联技术为主,特殊迫不得已的情况下,再考虑采用二层技术互联。

9、存储双活对同城数据中心的选址要求?

双活存储间链路的可靠性和稳定性对系统的影响及应对方案?

1.跨数据中心通讯链路方面

购买波分设备,波分设备具备冗余高可用性,租用运营商的裸光纤,作为通讯的链路。

裸光纤也冗余。

裸光纤通常租用两家或两家以上的运营商线路,比如电信、联通和移动,电信的裸光纤也需要冗余,联通的裸光纤也需要冗余,防止单根裸光纤意外割断或者损坏。

然而单家运营商的裸纤都通常在一个弱点井中,一起意外割断的事情常有,所以需要两家运营商互相冗余。

这两家运营商裸纤的路线还不能一致,弱电井需要在不同的街道,并且分别走不同的路线到达目的地。

2.通讯链路质量方面

链路质量包括光衰、抖动和带宽等。

一方面,光衰和抖动无法控制,只能靠波分设备去探测,发现光衰和抖动,立即中断该链路,切向备链路,这对后端的SAN网络无感知,但对波分设备的要求很高,需要购买和建设时注意。

至于带宽,可以监测,达到带宽预警阈值后,可向运营商申请提升带宽。

另一方面,对于链路质量的监测机制一定要在建设存储双活或者其他双活之前建立,由于是运营商的链路,链路经过了多少中继、多少设备我们是不得知的,我们只能在波分端建立有效的监测机制,有些波分设备也有专门的监控软件支持。

而且也要要求和运营商建立监测联动机制,运营商监测到链路质量(是质量而不是中断)有问题,也需要第一时间告知,做出合理的决策。

3.存储双活控制器的机制

由于跨中心的双活控制器间的通讯是实时的,完整写周期必须两个站点的控制器都完成写操作。

他们间的通讯又是靠链路完成的,链路质量和链路中断都将导致性能波动甚至超时,对于中断,控制器的处理机制都还不错,对于质量,控制器的处理机制往往不够,需要长时间的尝试,才会做出合理的决策,甚至没有决策,导致上层数据库或者应用磁盘IO超时,而异常挂起甚至宕机。

所以这个机制是决定好的双活体系的重要因素,有时候宁可立即放弃一边,也要保住RTO。

4.存储上层OS、应用和数据库合理的超时参数

OS识别磁盘、应用访问文件系统、数据库访问裸设备或者文件系统,存储IOHANG住,将导致层层超时,尤其是数据库,超时将彻底中断宕机,甚至出现逻辑损坏等莫名奇妙的问题。

有时候超时响应慢是可以等,而不是中止,所以需要OS、数据库层进行合理的超时联动设置。

5.尽量避免跨站点读写频率

没有跨站点读,就意味着本地可读,对链路质量没有要求;

减少跨站点写频率,就意味着,性能影响弱化,被控制器、数据库、操作系统等层层缓存暂存的写数据,会减少跨站点写的次数,进一步弱化链路质量所会带来的影响。

@alphaaries华为数据存储解决方案中心 

技术总监:

基础设施的架构设计取决于上层应用架构的设计,同城数据中心的选址需要结合应用TIMOUT设计和规划,然后选择适当的距离。

双活架构通常会采用仲裁机制,也就是由仲裁盘,如果链路稳定性不好,经常发生超时的现象,就有可能造成双活数据不断地仲裁,严重时可能会发生脑裂的现象。

因此建议双活数据中心之间的距离不要太远,其次选择信号稳定的电信运营商,最好是多家运营商共同来保证链路的冗余。

10、按照什么原则梳理现有应用业务系统,降低对双活的要求,减少投资?

如何按照功能区规划存储独立或共享使用?

应该根据信息系统重要级别分类来梳理定位,比如:

一般金融行业会根据容灾需求及保护投资的原则,把信息系统划分为三个或四个等级(比如ABCD),优先考虑A类系统(如核心系统,柜面系统,支付系统,互联网类系统等保开门系统)双活需求,双活应该重点考虑保开门系统,其余系统看暂时忽略,未来投资允许的情况下再考虑非关键系统的双活需求。

在性能iops满足的情况下,存储设备可考虑充分组合复用,无需考虑单系统使用独立存储,这样既能满足业务需求也能最大化利用设备,一般城商行业务压力不大,存储建议尽量整合使用。

通常的业务系统分析是依照业务等级的重要程度进行分级,大型国有银行通常可以分成A+、A、B、C几大类,其中A+类系统主要是核心系统例如清算结算账务等信息,A类系统主要是跟交易相关的信息,BC类业务主要是管理类的系统等等。

双活数据中心是为了更好的解决业务系统高可用性,因此在规划双活数据中心的时候,可以优

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 自然科学 > 物理

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2