【摘要】本文主要分享核心存储在使用过程中遇到的压力与架构优化经验。文章从核心存储选型前的需求分析与选型策略开篇，再到数年的核心存储使用过程中遇到的性能问题，进行了两次架构优化，优化的思路供业内同事参考，最后分享D ell EMC VMAX系列存储的日常维护方法。

1、项目背景

我行核心系统（应用和数据库）以及数据抽取所需的镜像数据库均使用IBM的DS8700存储。但DS8700存储的可用空间不足，无法为核心数据库提供扩容空间，急需扩容。而该存储已经达到强制更新年限，建议进行更换。

2、容量需求分析

我行的核心存储需同时为核心数据库、核心镜像和核心应用程序提供数据存储空间，业务数据的增加会同步增加核心数据库、核心镜像和核心应用程序所需的存储空间。为较为准确地估算出满足未来 数 年核心系统稳定运行的核心存储的容量需求，我们选择数据库的数据量为计算依据，估算 未来 核心系统数据库的数据量，再参考我行DS8700存储的实际使用情况，最终计算出核心存储的容量需求。

因数据库空间存在定期清理等操作，实际数据增长量难以进行趋势分析。根据和系统管理员、数据管理员沟通，数据库的空间容量和交易量有关，而交易量又和用户数相关。其中用户可分为线上用户和线下用户。

我们拉取了过去几年的数据进行相关拟合计算，可分别拟合出线上用户和线下用户的增长函数。再将线上用户、线下用户、交易量进行多元回归分析，得出三者的函数关系。而线上用户的回归系数为负数，不符合现实规律。经过与数据库管理员沟通确认，线上用户的交易在核心端处理逻辑与线下不同，数量相比总交易量可忽略不计。因此总交易量可视为线下用户的交易量。

得出用户数和交易量的关系后，我们又找出了交易量和数据库存储空间的关系，这样便可参考我行未来的业务规划、发展目标，由用户数推出数据库存储空间需求。

3、核心数据库存储选型

DS8700存储 是 IBM 于2010年10月份推出的DS8000系列存储产品，经过市场迭代升级，更新的产品为DS8880系列的存储产品，具体产品型号有DS8884（混合存储）、DS8886（混合存储）、DS8888（全闪存存储）。由于 当时 我行数据中心机房空间有限，无法摆放IBM DS8880系列存储产品。因此，核心存储采购选择与DS8880存储在市场定位以及稳定性、可靠性相当的其他存储厂商的存储产品。 我们选取了I BM 、H P 、H DS 、D ell E MC 的相关产品系列做参考，有混闪存储也有全闪存储。经过多方面分析考量，初步建议使用H DS 和D ell E MC 的产品。 根据对国内同业使用HDS和 D ell EMC存储的不完全调查统计， 当时 大部分银行的核心系统及两地三中心存储选型，基本以混合存储为主 。 虽然，全闪存存储产品在2016年前后进入市场全面推广期，技术已趋于稳定，性能较传统存储有较大的提升，但产品的整体价格仍然高于传统存储，且银行业核心系统相关软硬件的更新周期普遍较长，全闪存存储的核心系统金融同业案例较少。因此，建议核心存储采购仍然主要考虑较为传统的混合存储，适当配置一些固态硬盘来提升存储的性能 。

根据业务需要，我行数据服务总线在核心系统每天COB跑批的两个阶段需要对核心系统数据库进行数据抽取，由于在数据抽取期间COB仍需继续进行，同时核心系统对外业务不能中断，因此需要采用存储的同步及快照技术，获取两个时间点的数据，供抽数使用。

经过与HDS及 D ell EMC工程师充分沟通和论证，HDS VSP系列和 D ell EMC VMAX系列存储产品均能实现我行DSB抽数所需的镜像快照功能，并提供数据一致性保护。HDS和 Dell EMC提供的同步镜像和快照功能如下：

经过 综合考量以及竞标，最后决定使用 D ell EMC VMAX 100K 混闪存储 。

4、整体方案设计

在最开始的架构中，快照是直接在数据库使用的主LUN上做的 ，数据库主L UN 上做了四份快照。 然而随着数据量增加以及 读写 压力增大，数据库主LUN的响应 时间 受到了较大的影响。经分析，在主LUN上读、写，还承载镜像 服务器 的读写，容易存在卷热点，特别是当时还是使用机械硬盘的存储。

在新存储采购后，我们调整了架构。存储A、B分配相同的LUN映射给数据库，数据库上层使用RAC技术。在这里将数据库使用的LUN成为R1。存储A、B的R1分别使用SRDF/S同步到对端存储，同步LUN称为R2。 每个R 2 创建两份快照， 供镜像服务器使用。 架构图如下：

V MAX 通过服务级别的设置，可以让S G(Storage Group) 以相应服务级别的响应时间为目标，自动安排数据选择合适的存储介质存放，其实也就是分层。但并不是将S G 的服务级别设高，这个S G 就会将数据迁移到响应快的存储介质上，而是会综合使用情况、响应时间等因素考量。我们将R1设置较高的服务级别，尽量使用S SD 的存储空间。

一般来说，快照有两种机制：
ROW：不写到源卷，写到快照空间，删除快照时有合并IO操作
COW：写到源卷，源卷内容拷贝到快照空间，写入时候写IO*2。

Dell EMC存储快照的机制 ：
对于源卷和目的卷使用相同层级存储，采用ROW；
对于源卷和目的卷使用不同层级存储，采用ACOFW（Asynchronous Copy On First Writre） 。因为 ROW之后源卷的内容包括不同层级存储，无法提供源卷应用 的服务级别 。

这种架构降低了R1卷热点读写的可能性，但是对于存储的压力是增加的。部署在核心存储上的有核心应用、数据库和镜像节点，其中主要是数据库的读写较高，占用了存储较高的性能资源。因为核心数据库盘在底层做了R1到R2卷的同步，数据库写入存储R1卷会同步写入到R2卷，跑批期间再通过R2卷做快照，这就使得核心存储的压力大大增加。

核心镜像是通过对数据库存储镜像卷R2做快照的方式分配使用。跑批共需要四份，每台存储各分配两份快照。因快照需占用较多控制器CPU资源，在夜间跑批时间，控制器的CPU使用率达到近100%，整体存储达到了性能瓶颈。因核心数据库和核心镜像库共用存储，镜像跑批时的存储压力也导致了核心数据库在该段时间内IO延时增高，影响实时交易处理速度。

除了 性能 压力， 这种四份数据镜像架构的 容量利用率也较低。高端存储每TB的成本 高 。在 性能 以及容量的双重压力下，我们目前改造成了下图所示的方案 ，将核心存储和核心镜像分散部署：

之前运行的两台D ell E MC VMAX 通过对容灾镜像（R 2 ）做快照，跑批高峰期控制器性能压力较大，进而导致存储延迟增高。通过将核心镜像库独立部署后，现有两台E MC VMAX 只承担核心数据库的压力，不仅减少了空间需求，达到容量扩容目标，还减少了镜像卷R 2 和镜像库使用的快照的压力，压力大幅减小，有利于核心整体性能的提升。

之前核心及核心镜像均部署在两台核心存储上，不仅空间占用高，在跑批期间也存在相互争抢性能情况，对实时交易性能存在一定影响。通过将核心镜像独立一台V MAX 全闪存储部署，与现有核心系统部署在不同的存储上，将有效避免相互抢占性能问题，并降低存储集中度风险。

在这个架构下，存储C的资源基本上全供快照功能消耗， 由于全闪存储性能上的高吞吐和低延迟， 目前看 在跑批时对四个R 2 快照的读写压力下显得 游刃有余。 这个 高端全闪存储的上线使用效果和架构优化实践，也为我行日后核心系统存储架构选型积累了经验。

在三台的架构中，若其中一台故障，均有备用方案确保镜像服务器的可用性。考虑到高端存储出现可用性问题的几率较低，此兼顾成本的方案我们是能接受的。

5、日常维护

VMAX 的 管理软件主要有 Unisphere 以及 Solution Enabler ，需独立部署。 Unisphere 是图形化管理工具，可进行日常变更操作，查看性能数据以及较为简单的健康检查、告警配置等。 Solution Enabler 是命令行管理工具，可以进行更全面的维护。

从日常运维的经验来看， VMAX 存储故障处理方面的工作需要比较依赖软件的手段，不是所有故障都会通过设备上的指示灯对外显示，所以不能只靠巡检人员现场观察，更全面的告警信息可以在 Unisphere 图形管理界面或者 Solution Enabler 命令行来查看，也可以设置 Email、SNMP或者Syslog 等告警方式，或者在对接的第三方监控管理软件平台中进行监控；

5.1 Unispehere界面状态查看

1) 登陆Unisphere进入存储Dasboard界面

2) 选择System Health界面，可看到当前系统状态为100分，Run Health Check也是打勾状态（此状态为上一次运行健康检查的结果）

3) 选择Run Health Check，并选择Run Now。

4) 等待Check命令完成

5) 检查状态正常，如有报错则咨询Dell EMC售后。

Health check的初衷是做一个基本的检查，来测试后端存储能否正常工作，会进行以下步骤的检查。需注意的是 一般 硬盘故障并不在health check的检查范围内。

· Vault State Test —Verifies the ability of the system to save data in case of a power failure.
· Spare Drives Test —Verifies that spare drives are available in case of a drive failure.
· Memory Test —Verifies that the memory is reporting no errors or disabled banks.
· Locks Test —Verifies that there are no software locks present.
· Emulations Test —Verifies that all directors are loaded with the same Enginuity release as that on the service processor.
· RDF Test —Verifies that all SRDF links are online.
· Environmentals Test —Verifies that internal environmental components (power supplies, fans, batteries, and so on) are reporting no errors.
· Battery Test —Verifies that the most-recent battery test reported no errors.
· General Test —Checks for any abnormal conditions in the following areas: volume status, director status, hung upgrade, code table integrity, directors running same code.
· Compression And Dedup Test —Verifies that the most-recent data de-duplication test reported no errors.

5.2 存储健康检查常用命令

登录SE管理机，cd /usr/symcli/bin或sudo /usr/symcli/bin/命令

1) 检查存储event日志（mm/dd/yyyy）
#symevent -sid xxx list -start mm/dd/yy （将xxx改为需要检查的存储序列号后3位）

2) 检查存储各部件运行状态(检查状态均为Normal)
# symcfg -sid xxx -v list -env_data
# symcfg -sid xxx -v list -env_data -service_state failed
# symcfg -sid xxx -v list -env_data -service_state degraded

3) 检查是否有坏盘
# symdisk -sid xxx list -failed

4) 检查各个director状态
# symcfg -sid xxx list -dir all(状态应为Online)

5) 检查主机前端口FA状态(状态应为Online)
# symcfg -sid xxx list -fa all -port

6) 检查SRDF复制RA状态(状态应为Online)
# symcfg -sid xxx list -ra all

7) 检查存储空间容量使用
# symcfg list -demand -detail -sid xxx

若存储未做快照，且LUN均为厚置备，则空间使用情况很容易就能观察到是由所有LUN的容量相加。若存储做了快照，或者LUN为瘦分配，则容量分配情况会较复杂。总的来说，可以查看“Usable Capacity”这一栏。

“Total”为存储的物理总容量

“Used”为存储物理总容量已使用的百分比，为“User”+“System”+“Temp”。

6、总结

存储选型，不仅要参考纸面的指标参数，还需结合机房的实际环境进行考量，如空间是否足够，是否能放得下存储自带的非标机柜，电力是否充足等。而容量需求，最好结合产生数据的源端的发展趋势来预测。比如某个时间段增长放缓或加快，可能都是哪个业务引起的，未来是否还会出现类似情况，都可以结合实际拿来参考才有现实意义，而不是干巴巴的数字。

存储在上线前，最好安排做可用性测试。在测试中记录各个部件的故障会造成什么影响，日后若遇到才有针对性的应对方案。比如某个部件故障会导致I O 中断，中断时间若不超出操作系统或数据库的容忍范围，那可以不必大费周章。做可用性测试的过程中，也能熟悉该存储的告警逻辑，如是否会产生告警，有什么方式对接第三方系统，告警级别为w arning 抑或m ajor 等等，这样才能在配置过滤的时候不会把关键告警信息漏掉。

条件允许的话，可以再做性能测试，这样在使用中若发现性能利用率已经达到阈值，就应该考虑进行扩容或优化。

作者简介：施育颖，厦门国际银行资深工程师，负责x86、小型机维护以及存储的规划和管理。