某银行正面临现有的文件存储设施不能适应业务增长、系统管理复杂、扩展能力差、访问能力差等问题，期望通过使用分布式对象存储架构替换传统的SAN存储架构， 能够解决海量非结构化数据的集中存储及访问问题，提升非结构化文件存取效率，解决地市影像和总行影像存储单点问题，并尽可能的精简现有非结构化数据的存储架构。为此，对IBM Cleversafe进行了7方面性能（共14个案例）的测试。本文对企业非结构化数据存储痛点和优化思路进行了分析，并记录测试内容和测试过程如下。

一、企业非结构化数据存储的现状及痛点

随着本行数字化业务的持续开展和监管要求的不断提高，其中影像系统、呼叫中心系统，以及已经上线的后督系统等各类应用系统产生的影像文件、音频、视频等非结构化数据急速增加， 本行正面临现有的文件存储设施不能适应业务增长、系统管理复杂、扩展能力差、访问能力差等问题。因此需要启动开放式海量非结构化数据的存储平台项目，满足本行海量的非结构化数据存储、读取、管理需求。

目前我行的影像数据主要分两块，一块是地市影像数据，主要承载着事后督查业务， 一块是总行影像数据， 主要是柜面和信贷的影像数据。 11 个地市的影像数据目前分别存放于 11 个 SAN 存储当中，根据地市的业务规模不一，存储容量也不一， 平均每个 SAN 存储约 50TB。 总行影像数据通过存储分层架构实现在线、近线和离线数据的存储和隔离。在线存储存放于闪存（FS900）当中，约 5T，保存了近 7 天的影像数据，并通过 IBM 的 ECM 客户端定期迁移至 ECM 系统所在的近线存储（DS8870）当中，约 20T，保存了近 30 天的影像数据，最后再通过 TSM备份软件每日将近线存储中的影像数据备份至华为（5300V3）离线存储当中，约200TB，当信贷或者柜面业务需要调取 7 天的影像数据时，直接读取在线存储，调取 30 天的数据时，先通过 ECM 客户端将 ECM 中数据抽取至影像平台，再传给业务系统，调取 30 天以上的数据时，需先通过 TSM 备份软件抽取备份的影像数据至ECM 系统，再传给影像平台，最终传给相关业务系统。

此架构通过存储的分层，不同性能的存储提供不同的 IO 服务，确实也在项目上线后的 3、4 年内，提供了比较高效非结构化数据存取能力。然而随着近两年存储的影像数据量的暴增，新增了多类业务的影像业务和数据，像互联网影像数据、手机银行及人脸识别影像数据、银企业务影像数据等等，这样就导致影像系统尤其是 ECM 系统压力的陡增，目前遇到的痛点主要在于 ECM 系统，无论是近线数据还是离线数据，影像数据的位置与影像数据间的关系等信息均存放于 ECM数据库当中，该数据库为联机型关系数据库，随着数据量的剧增，ECM 数据库的数据量已达到近 5TB，7 天以上的数据调阅均需要访问先 ECM 数据库，来获取数据位置，然而目前庞大 ECM 的数据库，并发读取性能已经越来越不满足业务的需求， 因此数据调阅响应时间也越来越长。因此迫切需要对现有影像以及 ECM 的数据存储架构进行转型，精简该存储架构，全面提升影像数据的存储效率。

二、企业非结构化数据存储优化思路

鉴于我行目前非结构化数据主要存放在 SAN 集中式存储上，而传统存储采用集中式的元数据处理方式，因此，当我行影像系统在处理千万、亿级的文件量时就会出现陡峭的性能骤降拐点，直接表现就是前端影像平台处理效率降低，柜面、信贷、事后督查等涉及影像的业务效率的下降，最终导致客户满意度的下降，这显然不利于我行的健康持久发展。因此我行需要对现有存储中的海量数据进行整合、精简存储架构。

目前非结构化海量数据存储较好的方案主要有传统分布式 NAS 方案和对象存储方案。传统 NAS 存储方案由于和现有 SAN 存储方案类似，都是基于文件系统的方案，均为树形目录组织结构，随着数据量的增大，同样存在文件寻址越来越慢的瓶颈。另外如果将现有 SAN 方案改为NAS 存储方案，IOPS 和 IO 响应时间还有所降低，尤其是在线储存目前所用的为闪存阵列，近线存储为 DS8870，地市后督影像存储为华为 5300V3，NAS 方案显然不适合对现有架构进行改造，且存在越改越差的情况，并且对 NAS 存储的容灾备份方案，依旧是两套 NAS 镜像的方式，副本数较少，备份效率低，数据一致性校验困难。因此我行在非结构化存储架构转型偏向于对象存储方案。

（1） 采用对象存储方案思路

我行期望通过使用分布式对象存储架构替换传统的 SAN 存储架构， 能够解决海量非结构化数据的集中存储及访问问题，提升非结构化文件存取效率，解决地市影像和总行影像存储单点问题， 并尽可能的精简现有非结构化数据的存储架构。而分布式对象存储能够保证不丢失数据、不中断服务、提供良好的用户体验，解决存储扩容复杂问题。由于分布式对象存储采用扁平化的数据组织方式，所以目录架构扩展性强，耦合性低，增删节点时所需迁移的数据少。整体而言，在业务系统、 IT 性能以及运维方面都带了本质的提升。 因此利用对象存储的方案， 可以解决我行三个方面的问题：

1、精简非结构化数据存储架构。对总行而言，之前我行的存储架构为闪存-DS8870-华为 5300V3，三层存储架构，且存储和现有生产交易类存储闪存和DS8870 共用。一来非结构化数据不适合放于 IO 响应时间优异的存储当中，性能浪费严重，占用过多的存储空间，其他对 IO 响应时间要求较高的交易类系统，可能反而得不到高性能的存储。二来该存储架构过于冗余，数据存储具有大量迁移过程，如 7 天以上的数据由闪存迁移至 DS8870,30 天以上的数据由 DS8870 迁移至 5300V3，历史数据调阅的过程又反向，虽然均通过 ECM 系统和 TSM 软件实现该过程， 但效率较低， 相当于， 存储性能比较优异， 但整体数据存取效率不高，尤其是历史数据的存储方面。对地市分行而言，11 个地市分别部署了一套华为存储，独立使用，数据来源于事后监督系统通过抽取总行 ECM 的历史数据而来，数据和总行数据重合，却并不是总行数据的副本。而采用对象存储方案，可以通过总行和地市部署存储节点和访问节点的方式， 将所有存储打通成一个大存储资源池，所有影像数据均放在该存储池，形成二层精简架构，所有数据的存取，包括柜面、信贷、后督系统对影像数据的存储，均通过本地的访问节点访问，大大提升了访问效率。

2、提升非结构化数据的副本数和冗余度。相较于现有存储架构中的单副本数据， 由于对象存储池中的数据可划分为多个副本，且每份影像数据也通过切片的方式分布于所有存储节点当中，因此数据的冗余度也大大提升，即使某一个或者多个存储节点发生故障，或者访问节点发生故障，均可以通过其他存储节点和访问节点获取数据。

3、提升非结构化数据的存取性能。虽然目前的方案中闪存的引入，对于 7天的影像数据的存取效率大大提升，但历史影像数据的调阅性能较差，导致该问题的一个主要原因在于历史影像数据调阅需要通过 ECM 客户端访问 ECM 系统中的存储数据，而该访问的过程首先要读取 ECM 数据库，获取存储数据的位置和地址， 才能获取存储当中的数据， 这样的弊端在于随着 ECM 数据库中数据量的增大，数据库访问效率大大降低，30 天历史影像数据的调阅也就越来越慢，无法满足柜面及信贷对影像数据的需求，至于 30 天以上的历史数据就更加如此，除了需要访问 ECM 数据库之外，还需要访问 TSM 备份系统，通过 TSM 备份系统自动将要调阅的数据恢复至 ECM 系统中，再上传给影像平台，供其他系统调阅。因此整个过程实际上耗费了大量时间在数据查找和数据传输上，即使底层存储采用了 SAN存储，性能较对象存储强，但加上这些时间，总体调阅时间大大提高。因此倘若采用了对象存储， 访问时间就仅仅为对象存储的寻址时间， 没有其他时间的消耗，这样性能也就大大提升。

因此，对本行的非结构化数据存储架构的改造而言，采用对象存储方案是最优的方案。 但同时， 另一方面， 采用对象存储， 也将给我行带来两个方面的问题：

1、传统的文件系统读取的方式将改为对象存储 API 的方式。需要对应用进行改造，增加接口，修改程序代码。

2、原闪存、DS8870、5300V3 中的存储数据需要通过调阅的方式迁移至对象存储当中，涉及的数据量较多，耗时较长，且影像系统在数据迁移过程中，不能有中断现象，迁移时也要对其他业务系统提供影像服务，因此，整个平滑迁移与过渡的方案要理清。

（2）对象存储方案与传统分布式 NAS 方案的对比及总结

我行在对非结构化数据改造过程中，也考虑过传统 NAS 方案，对经过对比，发现传统 NAS 方案并不能满足我们的实际需求， 下面一张图为对象存储与分布式NAS 方案的对比：

该图总结而言，相对于传统的 SAN 存和 NAS 存储，对象存储具有以下优点：

对象存储可以使用低廉的 X86 服务器+对象存储软件实现，存储成本比较低。

RAID，当一个 RAID 磁盘出现故障，系统会慢如蜗牛需要数小时或数天来重建阵列。大多数对象存储使用纠删码技术存储数据，经过合理设施后，可以以较低的副标数量保证数据的可用性。而数据恢复只需要数分钟便可以完成，而且数据可用性不会中断，性能也不会明显退化。

对象存储系统中，没有目录层次结构(树)，对象的存储位置可以存储在不同的目录路径中易变检索。这就使得对象存储系统可以精准到每个字节，而且不受文件(对象)数量、 文件大小和文件系统容量的限制。 对象存储系统可以不需要文件名、日期和其他文件属性就可以查找文件。 他们还可以使用元数据应用服务水平协议(SLA),路由协议，备灾和灾难恢复，备份和数据删除删除以及自动存储管理。这些是文件系统所不能解决的问题。

对象存储系统如果设计合理，并不需要备份。多个副本可以确保数据始终保持可用状态，而且异地灾难恢复备份也可以被自动创建。

利用分布式实现大规模 I/O 并行读写。每个节点都是独立的，提供了集群的切入点，并运行相同的代码。这使得工作量可以平均分配到集群中的所有节点上， 避免 NAS 和集群文件系统中常见的热节点问题的出现。自动负载均衡可以让I/O 自动选择合理的节点，保证系统性能最大化。

因此，在现有 SAN 存储架构、传统 NAS 存储架构方案和对象存储方案中，我们最终决定选择采用对象存储方案来对现有 SAN 分层存储架构进行改造。

为了充分了解对象存储方案的优势， 帮助我们且为了将来更好的利用好对象存储，我们采用线上和线下两种方式对 IBM 的 Cleversafe 对象存储进行测试，经过充分的测试内容、 方案的准备和测试中详尽的过程记录，发现这款对象存储软件十分优异，下面将整个测试内容和测试过程汇总如下：

通过对如下内容的测试来验证 IBM Cleversafe 产品是否满足业务需求：

1、  产品基本功能，如对非结构化数据的上传、修改、删除

2、  产品的部署可行性和灵活性。包括部署的复杂度，模拟跨站点等场景

3、  产品的接口可用性。和应用系统的对接开发可行性，对应用系统的改造可行性。

4、  产品的可靠性。是否有完善的性能保障方案，保障系统稳定可靠运行。

5、  产品的易用性。包括图形化的前端界面，方便日常的维护操作管理。

6、  产品的可维护性。包括硬件更换，系统升级，监控管理和日志管理。

A、 案例编号：001

B、 案例名称：产品功能的基本展现

C、 案例场景描述：创建对应的存储池（storage pool）、访问池（access）、库（vault）。

D、 案例实现描述： 系统初始化完毕后， 在管理界面实现对应配置， 存储池选取生成的六台 slicestor，访问池选取配置 Cloud Storage 链接方式，即 S3，创建一个 IDA 为 4/5/6 的 Vault，即读阈值为 4，写阈值为 5，宽度为 6。意味着此库会将写入的数据通过纠删码计算为 6 片，当获取其中 4 片时，即完成读操作，当成功写入

第一个红框表明此 access pool 是使用何种 API 进行调用访问

创建库（vault=bucket），即逻辑上的存储空间。

第一个红框即为 IDA 的配置，第二个红框是一些可选功能，依次为加密、版本管理、防删除，第三个红框为是否需要 S3 header 来构建索引。

【 对象读写删操作 】

A、 案例编号：002

B、 案例名称：存储系统的上传，下载，删除

C、 案例场景描述：通过 S3 Browser 工具，完成文件的上传、下载及删除D、 案例实现描述： 通过 S3 Browser 连接到已经创建好的 Vault，上传一个实例文件， 确认存储系统对应的空间被消耗， 下载此文件， 确认可以被访问后，删除此文件。

S3 Browser 中的存储类型选择 S3 兼容存储，endpoint 即为 accesserIP（生产部署后对应的是负载均衡器的服务 IP），access key ID 需要在管理界面中生成获取，如下截图：

第一步：进入 security tag，点击进入需要连接存储的账户（此账户可能对应的是某应用或某管理员）

第二步：进入特定某用户，如果已经生成密钥，即可直接拷贝，如果没有生成过密钥，则点击右边 Generate Key

S3 Browser 可以查看到对应的 vault 和执行的上传下载操作。

2 、 部署灵活性测试

A、 案例编号：003

B、 案例名称：各节点的灵活部署

C、 案例场景描述：在管理界面展现各站点机器的部署情况

D、 案例实现描述： 模拟六台 slicestor 分布在不同的三个城市的机房，其中accesser、manager 在分散在这三个机房中。

在系统中逻辑部署成三个站点：九江、萍乡、南昌，存储系统可以做到灵活部署和配置，一方面满足我行组网需求、一方面提升运维效率。

A、 案例编号：004

B、 案例名称：接口调用及可用性

C、 案例场景描述：展现具体的 S3 API 的调用方式

A、 案例编号：005

B、 案例名称：系统可靠性-manager 失效

C、 案例场景描述：当 manager 失效时，系统能够正常运作

D、 案例实现描述： 暂停 manager 的虚机，通过 S3 Browser 对存储系统进行正常上传测试

所有正常运作的虚机节点

A、 案例编号：006

B、 案例名称：系统可靠性-accesser 失效

C、 案例场景描述：当 accesser 失效时，只要还有在线 accesser，系统就能够正常运作

D、 案例实现描述： 暂停两台 accesser 当中的一台虚机，在 CloudBerry 中配置两个 endpoint 的对象存储，可以看到一个 endpoint 无法访问，但是另外一个 endpoint 正常使用，并测试文件上传，以及之前上传文件的下载

在 CloudBerry 中，当两台 accesser 都正常的时候，可以同时读取 vault 中的文件，而当其中一台 accesser 失效是，第二台已经可以获得所有数据。

A、 案例编号：007

B、 案例名称：系统可靠性-slicestor 失效，测试不同 IDA 的系统能力

C、 案例场景描述：当 slicestor 失效时，在满足 IDA 设置的极限值内，系统能够正常运作

D、 案例实现描述： 在 IDA 为 4/5/6 的情况下，失效一台可以正常读写，失效两台可以正常读，失效三台系统失效；在 IDA 为 3/4/6 的情况下，失效一台或两台均可正常读写，失效三台可以正常读，失效四台系统失效。

配置两种不同的 IDA 从而观察当 slicestor 一台台失效时，系统的行为。

读操作正常，可以看到所有 vault 当中的文件，写操作正常，可以新添加图片

IDA456 已经无法写入，报 internal error，读正常，可以展示之前所有的图片。而 IDA346 则读写正常

IDA456 无法进行读写，IDA346 依然可读，但是不可执行写操作。

A、 案例编号：008

B、 案例名称：系统后台扫描及重构的验证

C、 案例场景描述： 正常写入某对象文件， 强行进入后台破坏某slicestor数据，通过 Rebuild 方式获取原数据

D、 案例实现描述： 在 IDA 为 4/5/6 的桶下，写入部分数据，在某台 slicestor中找到对应的数据盘， 删除上面的切片数据， 监控管理界面的 Rebuild 程序，当发现 Rebuild 完成后，暂停另外两部没有改动的机器，测试读取刚刚写入的文件，从而验证刚刚坏损的数据获得 Rebuild。

在未写入数据时，先使用 root 权限，进入 slicestor6，查到到最底层，无切片数据。从 CloudBerry 工具也是零数据

当写入一个 9.1MB 的文件时，我们可以发现有三个切片文件出现，按照每4MB 一个切段的原理，因此一台 slicestor 会存有 3 个切段数据的六分之一的切片数据，如下截图

在第三块磁盘中找到切片数据

将其中第一个切片数据进行 DD 篡改，只修改其中的一个字节，count=1，15:43 启动篡改。

此时关闭另外两台没有更改过切片数据的 slicestor4&5，发现下载对象。

重启两台刚刚关闭的机器，观察 slicestor6 的 Rebuild 情况（注：UI 显示界面与实际物理机操作有三分钟左右延时。）

大约在 3 分钟后开始扫描程序。

同时，在 log 中，也能够获取对应重构的信息，时间戳也能匹配。

【系统监控、报警、报告】

A、 案例编号：009

B、 案例名称：系统监控、报警及报告配置

C、 案例场景描述：观测之前系统测试中，所出现的异常

D、 案例实现描述： 在管理中控界面， 观察之前一系列异常动作， 展现告警数据、性能数据、告警提示配置、日志配置界面、报表配置界面等

6 、系统可维护性测试

A、 案例编号：010

C、 案例场景描述：在管理界面中实现 terminal 界面的 debug 指令

在 web UI 中，能够对在线的机器进行简单的 debug，发送一些常用指令，检测其结果。

A、 案例编号：011

B、 案例名称：简易在线升级

C、 案例场景描述：在管理界面中上传升级包，实现全自动化系统升级

D、 案例实现描述：实现一键点击，系统各部件完成自动升级的过程

一键升级系统， Cleversafe 采取滚动式升级， 先升级 manager， 再由 manager升级其他部件，系统会自己控制每次升级的台数，从而保证系统始终可用。

A、 案例编号：012

B、 案例名称：在线硬件更换

C、 案例场景描述：在管理界面中简单步骤实现一台机器的替换

D、 案例实现描述：额外生成一台 slicestor7 虚拟机，实现硬件替换功能

第二步，确认源机器和目的机器

当数据迁移完成后，会显示对应状态

注意：替换下来的机器需要重新安装后才可以继续使用。

A、 案例编号：013

B、 案例名称：存储池扩容

C、 案例场景描述：在管理界面中简单步骤实现存储池的扩容

D、 案例实现描述： 展示存储池扩容界面

在普通模式下， 测试环境允许最小宽度为 6， 生产为 9， 需要通过工程模式设置宽度为 3 的 storage pool，在此仅作功能演示，不作为以后配置参考。

总体容量增加，从而获得两倍的容量

A、 案例编号：014

B、 案例名称：系统安全性测试

C、 案例场景描述：系统各个环节保障存储数据安全性

D、 案例实现描述： 加密一共分为两个层面，一块是网络层，包括网络传输（TLS/SSL/SNMPv3 with AES）和设备 CA 认证，另外一块是数据加密，包括本身纠删码（Erasure Coding）的运算和 SecureSlice 可选功能，在系统访问方面，有对 vault 的权限控制，每个用户也有对应权限的配置，通过密钥的方式访问。

在创建 access pool 的时候，可以选择 API 类型，已经支持的 HTTP 协议，是否包括 SSL 等，而在 manger 到各个其他部件之间，采取私有的 SNMPv3 的协议，并通过 AES256 的加密算法

如果有新的机器要加入到系统中时，主控界面会提示有新的机器加入，当点击 approve 之后才可以进入整套系统，避免非法的伪装机器进入。

本身纠删码的计算就是将原数据按照系统算法预生成的某个矩阵，进行重新编码计算。切片数据对外已经是乱码，不可读状态。而在纠删码之前，通过 ANOT编码的机制，进一步通过随机生成的密钥加密数据，并将加密后的数据和密钥异或后的值，打包密文，形成一个完整的 AONT 包。

从而将一个切片数据进行了三层的加密包裹，而一个对象文件 1GB 举例，将有 250 个 segment（切段，每个 4MB），而破解数据则需要从众多节点、磁盘上精准获取对应对象的离散切片数据中的读阀值，反向破解三层，重复此流程 250次后，方可获取原对象。

而每个用户可以对应的分配不同权限、角色

每个用户可以按照应用需求，生成多对密钥