本文主要分享核心存储在使用过程中遇到的压力与架构优化经验。文章从核心存储选型前的需求分析与选型策略开篇，再到数年的核心存储使用过程中遇到的性能问题，进行了两次架构优化，优化的思路供业内同事参考，最后分享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 等等，这样才能在配置过滤的时候不会把关键告警信息漏掉。

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