1 项目背景
1.1 项目概述
随着银行信息化程度的不断提高,信息系统在金融行业的关键业务中扮演着越来越重要的角色,企业对信息系统的依赖程度越来越高,业务中断会造成巨大的经济损失、影响品牌形象并且还可能会造成重要数据的丢失。因此,保证业务连续性是信息系统建设的关键。同时业务系统的高可用和灾难保护的重要性也越来越突出,在我行目前的业务系统中,正在逐渐建设&完善深圳、上海两地三中心架构。考虑到Dell EMC存储经过多年的发展,处于行业领先水平,具备安全承载金融行业核心业务的能力,本次项目将在原深圳、上海数据中心部署多台Dell EMC PowerMax 8000系列高端全闪存以满足在深圳生产中心、同城双活中心及上海数据中心老旧应用项目的生产替换改造、满足业务的高可用及灾备需求。
1.2 现网存储架构情况
现网存储配置 目前行内基于SAN架构的存储业务相关设备,有交换机和存储共计100多套,涉及业界常见的博科、Dell EMC、HDS等,有常规的SAN架构,也有基于存储SAN网关的异构虚拟化架构。
现网存储架构的痛难点
为配合我行的应用系统整体架构升级,存储架构由传统的集中式及镜像双活逐渐向业务层面双活改造完善中,我行有如下痛点待解决
1.前期的规划基于SAN网关架构 , 虽然解决了当时很多管理和数据迁移等问题,但近年来随着公司业务的不断壮大, 扩展能力及性能瓶颈等管理难题逐渐凸显 ,无法跟上前端业务增长的步伐,同时较为复杂SAN链路环境给日常故障快速定位诊断也带来挑战。
2.同时部分数据中心镜像双活存储架构方案也有不少隐患及缺陷 ,比如同数据中心无法严格提供物理级别保护,存储因镜像带来更多的管理压力等等。
3.应用单中心部署,业务层面无法做到严格的快速切换恢复,RTO及RPO离理性值还比较远。
4.冷备中心不工作,关键时候不能切,成本也存在严重浪费。
5.容灾、资源灵活扩展未得到解决。
1.3 建设要求
1) 业务连续性要求
作为一家大型银行来讲,一旦业务系统所使用计算及存储等资源,出现故障 宕机,将导致公司业务的完全瘫痪,进而造成巨大的经济损失和对信誉度的影响。因此在存储的选择与架构设计上,我们需要充分考虑存储的稳定性,以保证业务的连续性。设计要求如下
确保核心业务系统所使用的存储高可用;
确保业务系统所选用的存储设备,在相关行业内有大量的案例,并为稳定产品;
确保从存储、到主机乃至光纤链路,均为全冗余架构模式。
2) 存储处理能力要求
随着业务的不断发展,对存储设备性能要求也越来越高,部分重要业务需提高存储层面处理能力,以满足未来3-5年的发展需要。
3) 高效的运营与管理要求
IT技术的迅猛发展正在重新定义我们工作和生活方式,而且正在带来应用领域的革命。同时随着业务的不断扩大,数据散落在各个应用系统。数据集成度低,分布于不同存储、不同主机,数据质量参差不齐,数据整合性差,管理重复度高、难度大、数据可控性不够高,相应数据安全得不到很好的保障。为了构建新一代的数据中心,存储的运营与管理显得越来越重要,因此企业需要构建高效便捷的存储环境,以满足业务需求。
4 合规性要求
银行核心存储项目,属于国内大型商业银行的重要IT 基础设施建设,意义和影响重大,必须满足国家及行业监管机构的合规性要求,本次项目建设需满足包括但不限于以下国家和行业规范
银监会《商业银行业务连续性监管指引》
银监会《商业银行数据中心监管指引》
银监会《商业银行信息科技风险管理指引》
银监会《银行业重要信息系统突发事件应急管理规范(试行 》
银监会《银行业金融机构信息科技外包风险监管指引》
人民银行《银行业信息系统灾难恢复管理规范》
人民银行《关于进一步加强银行业金融机构信息安全保障工作的指导意见》
人民银行《关于加强银行数据集中安全工作的指导意见》
国家质量监督检验检疫总局《信息系统灾难恢复规范》(GB/T 20988-2007
国务院信息化工作办公室《信息系统灾难恢复规范指南》
中办发27 号文《国家信息化领导小组关于加强信息安全保障工作的意见》
工信部《2006-2020 年国家信息化发展战略》【 2006 年 5 月 8 日】
2 设计原则
基本原则
通过对我行本次存储资源池建设需求的了解,结合金融行业业务系统的应用特点,本次方案设计建设过程遵循如下原则进行
1 可用性原则
灾备系统的故障不影响生产系统的运行,不会大幅度影响业务处理能力。
系统器件选择要考虑能支持7×24 小时连续长时间大压力下工作。
系统具有充分的冗余能力、容错能力,如支持双活控制器,满足高可靠性需求,至少达到99.999% 可用性。
系统具有专业的技术保障体系以及数据可靠性保证机制。
确保系统具有高度的安全性,提供安全的登录和访问措施,防止系统被攻击。
异常掉电后不丢失数据,供电恢复后自动重新启动并自动恢复正常连接。
系统支持运行状态管理和技术保障体系。
2 先进性原则
系统必须严格遵循国际标准、国家标准、国内信息行业和金融行业的规范要求。
需符合存储技术以及IT行业的发展趋势,所选用的产品型号已规模上量。
所有的系统处于先进的技术水平,确保较长时间内技术上不落伍。
系统的处理能力要达到业内领先,对于业务的使用要留有一定的余量,以满足后续升级的需求。
对工作环境要求较低,环境适应能力强。
3 开放性原则
系统必须支持国际上通用的标准网络存储协议、国际标准的应用开放协议。
与主流服务器之间保持良好的兼容性。
兼容各主流操作系统、卷管理软件及应用程序。
可以与第三方管理平台、云平台集成,提供给用户定制化的管理维护手段。
与现有IT系统、软硬件系统兼容并可无缝替换和升级。
系统必须支持国际上通用的标准管理协议。
4 易维护性原则
系统支持简体中文,通俗易懂,操作方便、简单。
系统具有充分的权限管理,日志管理、故障管理,并能够实现故障自动报警。
系统设备安装使用简单,无需专业人员维护。
系统容量可按需要在线扩展,无需停止业务。
系统功能扩充需要升级时,支持不中断业务升级。
支持WEB管理方式 集中管理方式。
5 扩展性原则
考虑银行未来三至五年数据中心、业务系统和存储系统的整体规划,既能满足短期建设需求,又能满足该银行中远期规划方向。
系统易于扩充。
系统选择标准化的部件,利于灵活替换和容量扩展。
系统设计遵守各种标准规定、规范。
可以与第三方管理平台集成,提供给用户定制化的管理维护手段。
具备各主流厂家设备的扩展接入能力。
6 经济性原则
综合考虑集中存储系统的性能和价格,最经济最有效地进行建设,性能价格比在同类系统和条件下达到最优。
7 绿色性原则
满足环保与节能的要求,噪声低、能耗低、无污染。
必须选用无铅器件。
有节能降耗的技术手段。
具备环境管理认证,符合环保规定,包材可回收,支持重复利用。
3 设计方案
两地三中心的容灾方式是当前金融行业容灾建设的最高配置和主流方案。
通过建设近距离的数据中心(同城双活数据中心 获得接近于零数据丢失的数据保护,通过建设较远距离的数据中心(异地数据中心 获得远距离的数据保护,避免区域性的灾难导致业务无法恢复。在出现小概率的大范围的灾难时,如自然灾害地震,造成同城双活中心与生产中心同时不可用,应用可以切换到异地灾难备份中心。通过实施日常灾难双活演练的步骤,应用可在业务容许的时间内,在异地的灾难备份中心恢复,保证业务连续运行。但异地恢复通常会丢失少量的数据。
下图是同城双活架构三层图
支持双活场景
1 IDC故障转移
2 LB(负载均衡)故障转移
3 应用集群故障转移
4 分布式应用集群故障转移
5 数据库存储级故障转移
3.1 方案概述
根据我行现有两地三中心容灾解决方案现状 一个生产中心、一个同城双活备份中心、一个异地灾难备份中心 。生产中心的数据从业务层面同步地复制到同城双活中心,同时,双活中心的数据异步地复制到异地灾难备份中心。
相比仅建立同城灾难备份中心 异地灾难备份中心, “ 两地三中心 ” 的方式结合两者的优点,能够适应更大范围的灾难场景,对于小范围的区域性灾难和较大范围的自然灾害,都能够通过灾难备份系统较快地响应,尽可能保全业务数据不丢失,实现更优的RPO 和 RTO 。因此 ,两地三中心容灾解决方案得到了广泛的应用。
为配合我行信息系统整体架构,为了达到业务的高连续性要求, 结合目前数据中心间网络现状,本次设计在前期对市面上常见的EMC、HDS及华为等品牌进行严格的POC测试,基于EMC存储满足我行业务实际需求的测试结果,并且经过各项指标的综合考虑后, 采购EMC PowerMax8000高端全闪存储 ,采用同城双活+异地灾备的两地三中心方案 。如此设计有如下优势
1 深圳同城双活机房和异地上海数据中心的故障 者演练 者计划内停机等操作,不会影响另一个数据中心的容灾能力。
2 深圳本地双活中心根据业务流量入口控制,可以将业务无缝在同城两数据中心切换,便于日常维护及单数据中心故障应急
3 深圳同城 双活 的容灾能力可以达到RPO=0的最高水平
4 异地上海数据中心既可以节省远距离网络带宽,又可以尽量减少对深圳生产机房性能的影响
5 与现网运维能力相匹配,兼容目前 前端业务流量 切换流程框架,方案稳健且未来扩展性好。
6 支持标准API接口,能与本行自动化日常运维平台集成,完成日常运维工作(zone配置、存储初始分配、扩容、回收等自动化
其中,同城双活+异地灾备可以将同城双活切换RTO 缩短为“ 零 ”,可以大大提高业务连续性能力。
3.2 方案架构
本次建设基于Dell EMC高端全闪存PowerMax 8000存储 ,采用业务层面同城双活的两地三中心架构,
具体拓扑如下
双活概述
a. 单个应用 两个生产中心部署相同的业务系统,结合网络层、主机层 及 应用的负载均衡技术,实现业务系统在两个数据中心并行工作和负载分担 ,其中数据在数据库层面采用热备技术(即主库-从库之间实时ADG同步),通过负载均衡技术实现ADG从库日常提供类如查询、抽数、备份等读取操作,实现部分读操作从主库分离,大大分担主库的压力,写仍然在主库,从库分担主库的部分读操作 。
b. 应用集群 两个生产中心部署不同的业务系统,互相实时灾备接管 就绪,即部 分业务以数据中心A为主,数据中心 B 为热备,而部分业务则以数据中心B为主,数据中心 A 为热备,以达到近似双活的效果 。一旦主站点出现问题,热备数据中心自动接管主数据中心的业务,对前端业务无感知, 用户的业务不会中断 。
c. 本行目前已有部分应用以同城双活中心作为主站点,随着业务量的增加,生产数据中心的承载压力会变大,届时将会有更多的新上应用会优先安放在同城双活中心,以当前生产中心作为热备站点,均衡两中心资源使用效率,充分利用同城2个数据中心的各类资源。
4 实践亮点及难点
Dell EMC PowerMax系列高端全闪存结合本行的本地双活+异地容灾的三中心解决方案的应用亮点如下
(1 标准化API助力银行存储资源端到端分配全流程闭环自动化
通过标准化API接口串联主机-交换机-存储,通过标准化梳理后,实现全流程自动化资源上线、扩容、回收、下线等常规运维场景,减少了大量的重复人工操作(自动化完成日常资源类操作占比已经超97%,而且持续在提升中)。
另外人为错误大幅度减少,近一年来未发生因变更导致的人为故障(原来随着业务量增长需求变多经常出现人为的配置错误,人为变更异常也是时有发生 ;
可根据业务窗口,定制时间段执行相应的资源分配,完成后自动将执行结果通知资源需求部门。
数据采集
服务器,交换机,存储各端所有数据从设备接口获取,不依赖于任何excel表,并及时更新。
操作 支持系统上线和扩容、回收、下线。
操作流程
说明
1 对上游工具的请求,不做任何数据层面的判断,直接落库。
2 操作前先对请求的数据做检查,如果检查通过,则生成和前端提交的端到端操作一样的单子,即存储分配,扫盘。如果检查失败,会在单子中记录失败原因,这个时候需要人介入判断是否支持手动操作。
3 对于生成单子失败的操作,如果不支持手动操作,则由管理员根据上游传来的信息手动操作,操作完成后手动修改单子状态,修改保存后会自动通知上游。
4 对于生成单子失败的操作,如果由于数据不一致(实例名有偏差 ,申请的量超过自动执行的设置(2T 等原因导致的,可以先检查更新数据,然后再尝试转换成可执行的端到端操作单子(强制执行 。
5 目前支持 OVMNewCluster,和 AddVolume,AddOSVolume等操作类型。
6 手动操作记录对应的操作记录
7 手动操作的单子状态
(2 基于Dell EMC全闪存端到端NVMe能力和RoCE网络的NOF+高性能解决方案方面,初步达到一定的利用参考价值,经过前期的2轮针对16/32GB SAN环境下NOF+方案测试,了解到NVMe协议整个生态的发展方向,给我行后续向NOF+新型存储应用组网规划,提供了宝贵参考。
测试模型
存储配置
服务器
(3) 支持数据高压缩比(达到3倍压缩比以上),相比非压缩存储,在性能无碍的前提下,节省了宝贵的机柜空间和减轻了本就紧张的机房用电力,同等空间使用效率大幅提高,间接节省了采购成本。
(4 全链路自动化故障诊断及告警
通过Rest API 收集主机-交换机-存储等对象的相关数据,预先设定阀值及植入算法(详细日志在右边点击展开显示 ,在下图中整体显示全链路状态,一旦有告警会通过红-黄-灰三种颜色分等级(critical、warning、采数异常)直观展示,便于快速定位故障。
结合上层应用实践亮点
1、满足业务超流控实施,但不影响业务体验
每逢来自前端入口业务异常增高的情况(比如各平台集中活动等),前端负责均衡会自动进行超流量控制,对超过设定阀值的流量进行排队 负载均衡到另外数据中心,确保后端基础架构不被动受牵连,保证前端业务能访问。
2、满足业务服务能力快速弹性切流扩容
在上述紧急情况下(主节点中心已满负荷),按照提前配置规则,实现自动 者手动切流量到双活中心分担来自前端额外流量,确保用户访问正常。
3、实现全链路故障快速隔离,容灾能力大幅提升
基础架构在日常运营过程中,虽然有各种高可用,但难免会出现一些极端情况,在双活中心按照1:1配置资源的情况下,一旦双活中心内部 者整体故障,均能实现全链路快速自动隔离,相比一般的主从站点架构,容灾能力得到大幅提升和更有力保障。
4、便于敏捷开发、灰度发布、不停机维护、提升业务试错能力
因为有双活的全链路冗余隔离及切换条件,我们平时在维护、开发、测试过程中就比较方便,大大给敏捷开发、灰度发布、不停机维护、业务试错能力提供了便利。
结合上层应用实践难点
1、整体架构需要重新评估及较多的人力、物力 入, 入和产出比是否符合企业需求有待评估。
2、一些关键技术的储备,比如访问对象池化,双活中心对外统一入口,对内CNAME访问,满足切换过程无感知,业务自动连接。
3、相关切换工具选型。
4、流量分配的原则等。
5 总结
对于银行核心业务来说,对数据中心的要求也不再只停留在生产中心瘫痪时启动灾备中心,保证关键数据的绝对可靠还远远不够,业务连续运行已经成为普遍性的诉求。双活容灾系统凭借其站点冗余、自动接管的优势应运而生。
本行基于业务层面的“同城双活两地三中心”架构简洁易运营, 目前已经稳定运行一年有余,完全能够满足我行核心业务的应用需求, 针对常见故障及前端业务流量超限等事件,能够及时通过入口流量切换 调整平稳度过,未对前端业务层面造成影响,相较过去基于存储底层复制等传统复杂架构, 大大提升了业务的连续性 。希望对同行相同建设需求可以有所帮助。
【作者】Andy,就职于平安银行总行信息科技中心,存储工程师。14年SAN&NAS等存储及周边环境项目实施和运营经验,擅长传统各厂商高端存储、存储虚拟化、存储复制技术、存储架构方案规划、基于存储cli、restAPI自动化运维,对分布式存储等开源技术感兴趣。
点击文末 ,可以到原文下留言交流
觉得本文有用,请转发、点赞 点击“在看”,让更多同行看到
欢迎关注社区 “双活”技术主题 ,将会不断更新优质 、文章。地址 https://www..com/Topic/71
长按二维码关注
*本 所发布内容仅代表作者观点,不代表社区立场;封面图片由版权图授权使用
Powered by 小羊羔外链网 8.3.10
©2015 - 2024 小羊羔外链网
您的IP:18.191.21.86,2024-04-18 05:03:09,Processed in 0.04879 second(s).