·2019-08-21 13:10

系统架构师·银行

中小银行基于Vmax全闪架构实现存储双活实践经验分享

字数 5649阅读 8087评论 4赞 13

## 摘要：
原来的存储双活架构面临着严峻的挑战。主要表现以下几方面：老核心引发系统性问题；架构层面的需要；数据管理层面的需要；运营安全层面的需要；性能层面的需要。为此本次结合新核心建设从集成度、兼容性、统一性、安全性考虑建立一套集中全闪存双活存储架构，彻底解决数据安全问题。

## 一、银行双活存储建设的背景，以及重要性

**1.1 企业 IT 系统现状情况**

行内于 2014 年开展同城灾备项目的建设，并确立了通过VPLEX来构建同城双活存储的架构，逐步完成了将重要系统改造接入到VPLEX的管理之下。目前系统架构虽然进行了一定的划分，具有一定的层次和规划。分为行内生产区、外联前置区和管理办公区，但上述架构对支撑我行未来业务的快速发展存在诸多不足主要表现，多种不同类型的存储设备规划不够接入难度大，存储架构也变得较为复杂，原来的VPLEX存储双活架构面临着严峻的挑战。各个区域资源配置不合理，部分区域复用混用严重，从系统的扩展性、易用性、灵活性以及支持互联网金融业务的发展等方面均难以适应。

**1.2本次存储架构规划分五个重要因素**

**1.老核心引发系统性问题**

核心承载了过多的业务功能，成为架构瓶颈，规划没有清晰的界限；

核心系统过于臃肿，二次开发难度大，版本更新频繁，性能瓶颈明显；

前置系统未进行整合，所有的渠道类、中间业务类、支付类业务基本处于各自为政的状态，资源复用混用严重。各业务系统发展程度各异与预期发展有较大变化，出现不同程度性能瓶颈。整体情况需要重新进行存储架构规划。

**2. 银行IT架构层面的需要**

各系统使用存储、主机代差大，操作系统中间件版本多跨度大，缺少统一的标准，应用维护性不便，系统性能问题难于及时定位。

全行缺少统一的架构标准；重要系统接入Vplex+VNX管理之下，外围等系统使用来各种存储没有很好的有效统一规划实施。

大部分系统采用HA或冷备策略，业务系统连续性管理存在风险压力，同城容灾切换能力大打折扣。少部分业务能够全部切换，部分业务仅能且切换APP应用层，数据区与前置区难以实现。

**3．银行数据管理层面的需要**

数据散落在各个应用系统，数据集成度低分布于不同存储、不同主机，数据质量参差不齐，数据整合性差，管理重复度高难度大、数据可控性不够高，相应数据安全得不到很好的保障。

现有和计划在建的系统和业务模块 60 多个，随着业务的发展，架构复杂情形急需改善，重新部署合理的数据层架构，数据管理规划将对后续我行系统建设至关重要。

面对以上情况结合运营成本考虑，将业务系统按系统等级来进行资源池化分 1 、 2 、 3 个等级，按等级分层投入力财力。统一整合规划既要提高系统可用性又要提高科技人力资源使用效率。双向切实发挥最佳组合效益。

**4.运营安全层面的需要**

金融系统基于数据运行，无数据则无生产力，对数据安全可控尤为重要。生产现状存储品牌众多，面临产品缺陷与 bug 管理维护升级，运维疲于应付，真正深入底层做到精细化管理少之又少。金融数据宜选择 高端品牌并做统一规划有利于数据扩展，数据迁移，精细化管理，更利于企业系统运行安全可控。

**5.性能层面的需要**

各系统发展差异较大，现有系统跑批出现了性能瓶颈，给业务稳定运行带来严峻考验。部分重要业务需提高存储层面处理能力，满足近 3-5 年的发展需要。由于互联网渠道增多，各个系统日交易流水增加明显，夜间核心与信贷等跑批压力日益突出，由于业务逻辑复杂性应用与 sql 优化空间很狭窄只能依托存储及主机层面的升级提升性能，使用闪存是最直接的方式。

## 二、存储双活存储选型需求与难点

**2.1  项目建设目标**

本次新机房建设目标之一是建成双中心高性能双活存储，满足应用双活，数据库双活需求，为业务系连续性提供可靠的基石。同时又能易于维护或能快速上手。 双活架构选型异常重要。金融业界常见双活方案有 EMC VPLEX 方案， IBM SVC 方案及 HDS GAD 方案。以上三家都分别有其高端存储 EMC 有 Vmax 系列， IBM 有 DS8000 系列， HDS 有 VSP 系列。

**结合我行实际运行情况以及存储架构调整需满足以下目标**

1 、 IO 性能高，故障率低，故障可隔离。

2 、新的存储需要无缝对接存储双活架构，既要易维护又要高可用性。

3 、存储满足更好纵向及横向扩展、存储分层和性能需求；可以任意 2 台存储建立双活。

4 、双活业务与非双活业务的存储访十字交叉访问链路如何控制。

5 、 支持小型机、 x86 、大型机及主流虚拟化平台。

6 、支持超额分配、快照、镜像及 Qos 等功能。

7、完备的售后技术支持，快速响应处理。

**2.2存储选型需求**

**结合前期整体规划各项选型测试需求，存储选型需要与其匹配。**

机房选址，机房距离10公里，机房已租用两家运营商裸纤组网。在网络层已经满足各种场景使用，具备建设双活存储。

主机选型，重点在数据库服务器选型，核心采用传统小型机，外围数据库选择整合度更高的基于Linux的大型机将外围数据库整合在一起，应用服务器统一采用x86 部署vmware虚拟化，需要选择主流高端存储。

数据库架构，规划采用Oracle Extend RAC承载重要系统及核心系统，在两个机房核心采用2+1方式部署RAC节点，外围数据库也是采用2+1方式部署RAC节点实现双中心数据库双活。

其他存储测试及交流，实验室测试其方案，是采用2台存储直接做数据同步双活，不利于横向扩展，应对存储级灾难不能灵活调整，且受license控制严格，只能同构，不能异构。

从以上出发结合新机房建设需求，底层双活存储异常重要，所运行的双活数据库要求底层绝对稳定可靠。从三家主流双活技术特性与科技部技术储备能力选择有存储网关方案 便于横向扩展。EMC网关支持已购存储双活，svc也有相同特点，但在高端存储可选型号没有EMC丰富，高端存储异构可选性不强。因我行使用过VPLEX结合VNX+CX2系列的异构方案，所有本次选择Vplex结合250F+100K高端闪存进行异构，更适合我行本次项目建设。本次机房投入2套VPLEX+6台Vmax存储对等模式部署在两个机房。VPLEX可以实现任意两个存储建立双活卷，同城双活与同站点双活均可灵活实现；同时又可应对任意2台存储级彻底故障，而再次建立双活保护。

2.3  **存储双活建设难点**

1、管理运维能否自主可控，存储架构选型变化带来维护管理挑战。技术储备与接管能力至关重要，虽然存储设备有原厂维护，很多时候是远水救不了近火，重大故障发生时原厂一线、二线工程师都是事后补救措施，但也有补救失败血淋淋的案例。日常运行维护提早判断力较为重要，这就需要较深厚的技术储备能力。

2、单台存储与双活存储性能测试对比分析，单台存储性能测试指标往往十分诱人，但集成到双活环境受各种因素干扰性能测试不尽人意。单台存储性能测试SAN网络结构简单清晰排除故障因素简单，拓扑图简单直接通过SAN交换机串联。跨机房双活存储性能测试受波分、导向器、VPLEX端口分配、路径配置、路劲选择、SAN延时等因素干扰。

**跨机房双活存储性能测试案例分为双活卷与非双活卷场景来测试。**

**测试案例从上至下，并对比结果：**
![](/home/attachment/201908/21/915687_156636312535050.jpg)

3 、高端存储与高性能主机兼容性测试。从我行 VMax 存储将会接入小型机与大型机使用。小型机使用案例众多较成熟。大型机行业使用较少，测试难度大，重点关注分区 SAN 负载模式， SAN boot 引导方式，以及多路径选择，配置方式。尤其是各种存储故障，对大型机的影响性测试，测试效果为后期维护提供参考指南。在测试过程中发现系统盘稳定性较差，后主要优化 HBA 通道配置及多路径参数，经过 2 轮优化测试提高了大型机系统稳定性。前期发现系统偶尔有系统盘丢失导致系统只读现象，经过上报，原厂紧急对 DPM 版本升级。

4 、波分及其 san 网络稳定性是双活的基石，双活存储运行使用对光纤 san 要求极高，理想的距离是光纤长度不超过 20 公里，且 san 网络链路延时小于 1ms 一下，若波分设备稳定性把控不好将会导致 san 抖动双活卷不稳定，双活数据库脑裂。对底层物理链路层的监控及应急方案要求较为严格，因此波分监控既要准确又要及时，有任何链路问题，系统层需协同应对处理，针对抖动的波分链路应及时抛弃，待链路稳定后方可恢复 san 级联网络。

5 、对运营商相关线路维护及市政施工公告要及时了解，做好应急处置方案，保障链路稳定，系统才可持续性运行。

## 三、项目建设的架构设计，实践应用

**双中心存储架构图如下：**

![](/home/attachment/201908/21/915687_156636332143127.jpg)
 同城双机房通过4台cisco mds9706级联组建跨机房SAN网络，6台EMC VMAX存储通过VPLEX虚拟化网关构建了一套双活存储池。

结合新核心及外围系统建设情况，结合系统重要程度，数据重要程度，经营成本因素，基础架构扩展性，维护性等因素，将存储池划分成三个存储域分别是核心数据区域、外围系统数据区域、APP虚拟化区域，各个区域存储独立使用一台存储通过虚拟化网关组建既能解决横向扩展又能解决纵向扩展。各个区域根据业务重要级别划分双活卷与非双活卷。互联网与数据仓库数据池因非集中式架构而单独规划选型。

后期扩展考虑，各区域独立使用存储，被网关虚拟化后横向纵向扩展都比较轻松。

![](/home/attachment/201908/21/915687_156636339692941.jpg)

## 四、存储双活项目建设的难点与解决经验

1、数据规模控制，银行各个业务系统数据年增长量预估难以精准。数据库层面容易计算，日志保留较短，写入表数据可预估，本地备份数据1份（其他备份数据统一由备份系统管理。）应用数据往往难以计算，上线DBUG模式，交易日志难以预估，监管要求又严格，保存周期较长，报表与分析类系统数据越来越臃肿。日增量较大，所有系统按日期切片保留短期日志与交互数据。超期数据备份转移，有查询需求在还原。全银行业务系统操作系统约300个在线保留日志较短，充分节约了存储空间，将空间最大化的使用在业务上。该策略可节约30T空间（按300台*100G）。

2、业务数据分层，每个系统均按数据层与应用层分类并使用不同存储，存储异构有利于系统健壮性，有利于IO分流，应服务器与数据库服务器使用不同存储。根据业务重要程度分配金银铜铁不同等级空间，确保各业务IO性能需求，采用精简置备lun可以实现超额分配，提高存储利用率，提高经济效益。

3、双活业务卷监控，双活业务监控重点三方面一是Vplex有无性能瓶颈，二是同城波分的稳定性监控，三是SAN交换机对光衰容忍度。其中后两点是运维中的难点，链路光衰大SAN交换机支持自动监控并down模块；不容忍发生链路抖动，链路监控需要及时报警，人工干预处置需要较强的判断能力。

4、Extend RAC性能与健壮，由于RAC集群ASM管理的共享存储内部通讯机制复杂对网络延时与存储IO延时非常严格，直接关系到RAC健壮性。Extend RAC如何使用必须经过测试选择最稳定方式投产。我行部署的三节点RAC，分别任选2节点运行，以及三节点同时运行进行各种数据导入导出跑批测试，综合对比后，各种场景RAC稳定性稳定一致，但带有跨机房节点时RAC吞吐量性能明显不如同机房运行。综合整体考虑最后选择A机房双节点运行，B机房Extend node处于standby，以好最大发挥RAC吞吐性能。

5、存储坏块，分两个层面，物理坏块VMAX已将所有磁盘池化为一个pool，采用切片方式按块为单位创建raid。只要没有盘柜离线该层面无需过多关注EMC自生健康检查完成。逻辑层面坏块，人为误操作带来是面临最大风险，因此系统工程师与DBA需严格控制其文件系统及裸设备层面操作权限，相关变更必须严格审批且有详细手册。

## 五、项目建设的效果总结

1、系统性能显著提升，核心系统日终跑批30分钟即完成（比老核心日终提高40%），16个小时模拟一月跑完30个日终批处理以及出报表，完全没有性能压力。双活卷同城复制速率超1Gb/s，网络延时小于1Ms。完全满足现有各种业务场景。

2、数据安全性高，数据库采用250F，应用采用100K构建双活卷，整套系统存储是异构，防止单点灾难性故障，为业务系统容灾提供了便利，又保障了数据冗余，每台存储均可超额分配，存储灾难故障可以任意存储划分精简lun进行容灾。

3、集中管理，每套VMAX存储均按默认配置了SRP（存储资源池），SRP系统的优点在于其创建、分配和管理存储的简单性。VMAX3阵列固有的易用性（阵列设计的主要目标之一）在使用单一SRP配置时表现得最明显，并能获得最佳体验。通过单个SRP和由FAST控制的设备，存储管理员可简便地创建所需的设备，并将其添加到具有相应服务级别目标的存储组中。完成后，数据的物理位置由 FAST 决定，无需存储管理员进行进一步的管理来确保最佳的可用性和性能。因此再采用unisphere管理平台集中管理全部VMAX存储，减少了存储维护工作量。

4、架构灵活扩展性强，存储分区域后被Vplex网关虚拟化后提高了扩展性，开放性，纵向扩容横向扩容都简单灵活。其他主流存储均可接入。

vmax 存储双活 VPLEX

著作权归作者所有

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