某农商行基于华为中端全闪存储架构设计及应用实践

字数 6454阅读 4969评论 4赞 12

# 文章摘要 
本文章主要分享了作者进入银行科技部门至今的银行基础架构的演进，从IBM小型机加DB2加高端双活SAN存储的架构，到基于PC服务器虚拟化加中端SAN存储的大规模应用，再到如今分布式数据库、容器化、国产化等新技术栈的崛起。在IT架构不断升级迭代的过程中，自身也积累了不少经验也踩过不少坑，本文主要分享了在现阶段大规模使用虚拟化平台的基础环境中如何保障存储的可用性。 在此分享给TWT社区的各位同仁，全文手动码字，满满的干货与经验之谈，希望大家可以喜欢。

技术关键字：虚拟化、SAN存储、国产化、方案设计。

# 一、建设背景
我行自2018年开展新一代信息工程以来，始终贯彻"大中台，轻核心"的建设理念，推翻重构原有基于传统小型机加高端存储架构下集中式架构应用，规划建设基于分布式、微服务架构的新一代应用系统，并将其视为近年来基础平台建设的首要目标。同时，在拥抱新架构新基础平台的过程中，如何在银行这个强监管环境下保障保证业务连续性成为近几年来我行在基础平台系统建设方面的关键所在。

# 二、架构演进路线
目前我行生产环境部署6台华为OceanStor Dorado 5500 V6全闪存储，均置于我行VMWARE虚拟化平台的SAN网络中，4台带有华为存储双活HyperMetro的Licsense，两台无存储双活Licsense，同城主备机房之间两对SAN交换机使用运营商裸光纤进行级联，中间无波分设备，两数据中心距离10公里。

我行2013年引进VMWARE虚拟化平台，当时主要用于构建非核心业务类的APP应用，采用vSphere 5.x版本构建，存储使用IBM V7000存储，主备存储之间无双活功能，宿主机首先根据物理主备机房位置划分主备虚拟机数据中心后，再在主备机房对于虚拟数据中心内根据业务网络区域划分为外联区、互联网区及一般业务区等集群。

外联区主要运行我行对接的第三方业务，如财政、供电等业务，一般此区域无法做到以主备中心负载均衡来访问的部署架构，大部分应用采用主中心单机运行的模式部署，故初期为保障应用可用性，存储层使用SAN存储加上远程拷贝功能将主机数据同步至同城灾备中心存储。在发生外联区集群主机房不可用时，拉起同城灾备中心存储上远程同步卷，将无法使用的虚拟机重新注册至备机房运行。

一般业务区主要运行行内主要应用系统如柜面、ESB等系统的应用环境及内管类的应用，主备机房宿主机1比1部署，存储对接SAN存储，应用两边同时运行，同城主备数据中心采用F5做负载均衡来保障应用高可用，数据库层多数使用db2  HADR技术来实现主备机数据同步。

互联网区主要运行我行面向互联网业务，如个人网银、手机银行等应用系统的前端Web及应用，主备机房宿主机2比1部署（备机房为灰度发布环境），服务器采用本地存储磁盘，主中心采用F5做负载均衡来保障应用高可用，由于采用非共享存储环境，虚拟机无法实现在同集群内HA功能。

此架构运行至2018年，vSphere升级至 6.x版本，由于IBM V7000存储容量有限（单边只有20T），已无法满足新增业务需求，我行采购两套EMC Unity 400存储，单边容量60T，也仅带有replication存储复制功能，并没有使用当时EMC推荐vplex双活存储网关的方案，故我行虚拟化环境的存储架构本质上并没有变换，只是从存储容量上来说变大了。

# 三、建设方案设计
随着分布式、微服务等新架构，开源数据库、中间件等新技术名词慢慢地进入了我们的视线，新应用架构的建设设计也提上了日程。

新应用架构对基础架构的挑战首先就是存储的容量，原来传统APP+DB的传统应用方式逐渐被集群的概念所取代，原来上线一个系统可能几台虚拟机就能满足应用运行需求，现在使用分布式微服务架构取代之后，上线一个应用可能需要十几甚至几十个虚拟机来组成应用集群，这对存储容量提出了前所未有的挑战，存储需求几乎是成倍的往上增长。第二个挑战就是存储的性能，由于分布式微服务架构的应用与应用之间的调用、交互量远超传统架构的应用，因此对存储的IO性能也提出了不小的挑战。

在容量与性能两个挑战的压力下，我行于2020年引进了首套华为OceanStor Dorado 5500 V6全闪存储，用于面对容量与性能两个挑战。

首先是容量，华为OceanStor Dorado 5500 V6全闪存储使用NVMe SSD，单盘7.68T，单个存储2U，满配36槽位做完raid及分配热备盘后可用空间200TiB，对比早期的V7000，一个2U控制器加三个2U拓展柜的20T容量，中期的Unity 400，一个2U控制器加一个2U拓展柜的60T容量，OceanStor Dorado 5500 V6在容量上大幅度领先虚拟化平台存储上的前两任‘前辈’，且OceanStor Dorado 5500 V6为全闪存存储，本身就有极高的重删率，进一步提升存储池的实际可用容量。

在性能上，OceanStor Dorado 5500 V6由于采用的是NVMe协议的SSD，跟传统SAS盘加SSD缓存的存储对标起来那更是不可同日而语，日常小块文件的随机读写性能已经不是能用原来的几倍来对比了，从根本上解决了应用架构的变更对虚拟化平台带来的挑战。

时间推进到了2022年，我行vSphere升级至 7.x版本，虚拟化平台本身也对NVMe SSD的卷有了原生的支持，虚拟化平台的运行日趋稳定，性能优异。但中间的一件‘小插曲’，促使了我们生产环境在本年新采购4台华为OceanStor Dorado 5500 V6全闪存储。因为本年我行新一代新核心账务系统投产上线，在上半年上线前经历了5轮的投产演练工作，投产演练过程中除了原有少量AIX操作系统使用了PowerVM环境，其余所有核心应用环境、配套业务系统使用了我们开发测试环境的一套OceanStor Dorado 5500 V6，30余台虚拟化宿主机上承载了近2000台虚拟机，在演练及跑批的过程中，期间由于核心数据移植工作也在同步进行，中端全闪存存储的性能支撑不住如此大的IO并发，进而出现了大量虚拟机IO闪断，导致文件系统触发保护机制，将文件系统置为只读状态，需要人工介入进入救援模式使用FSCK检查文件系统才能恢复系统。虽然这个问题后来通过OceanStor Dorado 5500 V6的Smart QoS功能来限制住了某些大流量宿主机的带宽，但是这个问题也暴露了虚拟化平台存储不分层的隐患，即我行所有网络区域的宿主机均使用了同一套存储，长此以往下去，性能再好的存储最后也会被压垮，如果在生产环境如果出现了投产演练中类似的文件系统故障，那对银行生产系统来说将是致命的。所以在新核心上线后，我行也加紧推进新存储的采购、部署工作，目前我行虚拟化平台中的存储分层工作已完成搭建，两台OceanStor Dorado 5500 V6上运行核心账务区应用，所有存储卷开启HyperMetro存储卷双活功能，两台OceanStor Dorado 5500 V6上运行一般交易区应用、外联区应用，存储卷按需开启HyperMetro存储卷双活功能，两台OceanStor Dorado 5500 V6上运行一般非交易区、互联网区应用，存储卷不开启远程拷贝或双活功能，至于前文提到的V7000、Unity400两位‘老将’，则制定了一个长期通过宿主机集群中的storage vMotion功能，逐步将运行在老存储上的虚拟机迁移至新存储上，完成迁移计划后存储下线。至此我行虚拟化平台存储全部替换为华为OceanStor Dorado 5500 V6全闪存存储。

# 四、实践经验与替换效果
在存储更新迭代的过程中，有三个重要的特性我认为是在用到华为OceanStor Dorado 5500 V6全闪存储后相较于之前IBM、EMC的存储有提升的，我将其总结为“一保护，两提升”。其中的“一保护”是：HyperMetro存储卷双活功能，“两提升”一是存储卷组与主机卷组管理功能提升，二是存储性能的告警、监控、回溯。具体如下：

## 1、HyperMetro双活功能（保障存储高可用）
之前在本人传统印象中，存储双活是一个高大上的功能，但也伴随着两个缺点，第一个是价格昂贵，一般只有对接核心账务类的小型机才会去考虑存储双活的解决方案，第二个是架构复杂，主备两机房内需要在SAN交换机上划分多个Zone用于保障存储的双活功能，如果再叠加之前的需要双活网关设备的方案，复杂度更是成倍上升。所以在使用OceanStor Dorado 5500 V6之前，我对存储双活技术一直持一个仰望态度，但在我接触了华为全闪存后，发现存储双活其实也是可以走入常规应用里的，目前我行6台华为Dorado 5500 V6全闪存储中，核心业务区与一般交易业务区的4台带HyperMetro双活功能，我行对于HyperMetro具体设计架构如下：

**1.1存储整体组网拓扑图**
为了保证业务的连续性、数据的可靠性和可用性，我行华为OceanStor Dorado 5500 V6全闪存储方案采用总行主机房数据中心至档案楼同城灾备机房双活存储方案，实现以下目标：

主生产中心，业务运行所在的数据中心。同城灾备中心，在与我行生产中心同城建立可独立承担业务运行的灾备中心。整体容灾架构图，如下图所示：
![图1](/home/attachment/202211/26/926745_166946398523203.png)
通过数据双写和DCL机制实现存储层数据的双活，两个数据中心同时对主机提供数据读写能力。HyperMetro双活站点间使用FC互联，可直接通过存储端配置完成初始同步。值得一提的是在双活存储的实施规划中有两个需要注意事项。

注意事项1：存储间复制链路和主机与存储间业务链路分开，走不同的FC端口，即我每台存储的每个控制器上使用两个口作为主机存储业务口。

注意事项2：针对FC复制链路，本端存储阵列的每个象限都与对端存储阵列的相同象限有物理或逻辑链路。即本端存储象限A与远端存储象限A有连接、本端存储象限B与远端存储象限B有连接、本端存储象限C与远端存储象限C有连接、本端存储象限D与远端存储象限D有连接。

**具体链接方式，如下图所示：**
![图2](/home/attachment/202211/26/926745_166946402283005.png)
## 1.2双活场景

**1.2.1正常状态处理，如下图所示：**
![](/home/attachment/202211/26/926745_166946406164813.png)

**HyperMetro双活的写I/O流程如下：**
1）主机下发写I/O到双活I/O处理模块；
2）双活LUN将写请求双写到两中心的双活数据LUN；
3）双活数据LUN返回写操作完成；
4）双活数据LUN返回写I/O操作完成

通过SAN双活解决方案可以满足业务RTO=0，RPO=0的业务需求。

**1.2.2灾难切换处理**
生产中心A故障时双活的切换处理。
1）生产主中心故障，当一个数据中心发生设备故障，甚至数据中心整体故障时，业务自动切换到另一个数据中心，解决了传统灾备业务无法自动切换的问题。提供给用户高级别的数据可靠性以及业务连续性的同时，提高存储系统的资源利用率。

**1.2.3灾难恢复处理**
1）生产主中心故障恢复，在一个数据中心故障时，DCL可以记录业务运行中数据中心的数据变更。待故障恢复后，同时跟踪变更数据同步到该数据中心的存储设备中，以防止变更的数据在同步过程中出现遗漏；根据存储系统记录的DCL，进行后台数据同步，待本端LUN和远端LUN的数据一致时，双活业务恢复

**1.2.4链路和灾备端故障**
1）当生产中心A与灾备中心的复制链路故障或者灾备中心设备故障，则远程复制自动断开，不影响生产系统的正常运行。远程复制自动断开后，阵列A将记录故障期间的差量数据，待故障恢复后，自动将差量数据同步到灾备中心。

## 2、存储卷组、主机卷组功能（存储管理效率提升，降低操作风险）
随着虚拟化技术的广泛应用，势必会带来主机与卷之间管理的问题。在平台初期使用时，受限于应用场景与存储容量，虚拟化宿主机数量及分配卷的数量是不多的，采用单台主机独立映射卷的模式还是可以管理过来的，但随着虚拟化技术的场景拓宽及单台存储可用容量的增长，主机与卷之间的关系及管理工作日益繁重，超过百台的宿主机及数百条的卷让存储管理员每次在做宿主机、存储变更的时候工作量成倍的增长，同时也带来的错误映射主机卷的操作风险。

我行使用主机组、卷组的管理方式，也是由于运维开发测试环境的同事在日常工作中反馈的一个痛点：我行开发、测试、准生产等非生产环境90%以上均运行于我行开发测试虚拟化平台上，由两台OceanStor Dorado 5500 V6，总计500T提供存储资源给开发测试一百余台宿主机使用，在使用存储卷组、主机卷组功能之前我们一直都是按照单台主机映射所需卷的方式来管理宿主机的存储资源，这样每上线一台宿主机，存储管理员就必须按照宿主机所在集群的存储需求，一条一条的对应映射关系，这些都是机械、重复的工作，且极易出现漏掉卷映射的情况。所以后续我行在反复咨询华为原厂与论证可行性后，在测试先行推行存储卷组、主机卷组的挂历方式，即存储卷组、主机卷是我存储上的两个逻辑关系组，存储管理员将宿主机集群定义为主机组，虚拟化宿主机集群整体需要的存储卷定义为卷组，使用主机组来映射卷组，后续如果需要添加主机或者卷的时候，只需要在对应的主机组或者卷组中添加新增的对象即可完成对于宿主机集群新增宿主机或者对应集群新增卷的变更。此管理方式目前也应用到了我行生产环境6台OceanStor Dorado 5500 V6存储上，大大降低了在我行这种较大规模的虚拟化平台下存储管理的管理难度及降低了日常运维的操作风险。

## 3、     性能告警、监控、回溯（IT整体可视化运维提升）
回顾之前虚拟化平台使用的国外存储，虽说都能做到通过syslog或snmp的方式将坏盘、控制器重启等故障推送到我行的同意告警平台，但是在存储本身性能监控的维度上可能是IBM、EMC等国际品牌的短板，不管是性能监控保存的时间，监控的颗粒度，易用性这几个方面都达不到我们的需求，有时候在出现生产问题时不能精确的回溯当时的性能数据，在替换了OceanStor Dorado 5500 V6后，不仅可以从多维度来回溯存储的曲线，同时还能结合监控数据来给容易带来存储性能风险的宿主机指定QoS策略来限制主机的IO。

除了监控外，OceanStor Dorado 5500 V6或者说是华为产品的运维工具SmartKit也在我行发挥了不小的作用，近两年疫情，经常会出现工程师无法及时到客户现场的情况，SmartKit可以对存储进行例行的询价、性能收集、补丁升级等操作，在遇到特殊情况时完全可以让我行运维人员在原厂的指导下来执行这些工作。

# 五、总结
截至目前，我行虚拟化环境基本已实现全部国产化设备的替换，虚拟化平台运行虚拟机近3000台，包含我行所有生产业务网络区域，承载了我行80%以上业务，虚拟化平台在我行IT基础架构中重要性越来越高，这也对我们IT运维人员提出了新的挑战。很幸运我们选择对了方向，在后续的工作中，我们对于全闪存存储的定位可能也不只虚拟化这一个场景，像给容器的CSI提供卷，给云平台提供以服务化形式提供的块存储以及信创方面的一些需求都将是我们后续会考虑的全闪存存储使用场景。

全闪存储 oceanstor s5500 存储架构设计虚拟化双活建设

著作权归作者所有

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