医院私有云存储的规划、配置、调优工程实例

青旅半醒 2022-06-16 06:29 242阅读 0赞

一、项目背景介绍

二、建设目标

三、IBM 解决方案

3.1 方案架构

3.1.1 物理拓扑图

3.1.2 逻辑图

3.1.3 存储规划建议

3.2 方案特点

3.2.1 实现存储资源池化

3.2.2 优化应用运行效率

3.2.3 精简配置

3.2.4 通过复制服务保护数据

四、针对 HIS（采用数据库 DB2）的优化，采用 Flashsystem

4.1 I/O 等待时间的问题

4.2 旨在提高 IBM DB2 性能的传统方法

4.3 闪速存储简介

4.4 全闪存存储系统

4.5 了解 I/O 等待时间

4.5.1 系统层面

4.5.2 数据层面

4.6 预测性能改进情况

4.7 估算 DB2 的性能改进程度

4.8 估算端到端的总体改进程度

4.9 可以迁移到闪速存储系统的组件

4.10 案例分析

4.10.1 工作负载：IBM InfoSphere Identity Insight

4.10.2 环境配置

4.10.3 迁移到闪速存储系统

4.10.4 结语

五、总结

一、项目背景介绍

某人民医院（以下简称医院）是集医疗、教学、科研、预防为一体的现代化国家三级甲等综合医院。医院现有 A、B、C 三个主体院区，编制床位 1500 张，开放病床 3000 张。在领导班子的带领下，医院全面实施“数字化医院”建设，首创医疗质量管理信息系统、建立城乡协同医疗服务网络，依托国内顶尖医院推动学科建设，聘请国内一流专家定期来院工作，打造一流医疗团队。医院作为某市的龙头医院，其整体业务呈现快速增长的态势，当前医院正在扩建新的住院病区，随着住院床位数的增加，医院的业务必然会有一个明显的增长，而医院的存储基础架构已经相对老化，其现有的 EVA 系列存储已经表现出性能瓶颈，医院当前的核心数据库存在性能不均衡的情况，如果要求应用软件开发商进行性能调优，可能需要花费大量人力物力，但却不能保证调优的效果。

目前，医院的核心业务包含 HIS、CIS、LIS、EMR、PACS 等，另外还有几十个小的边缘业务模块，多年的业务建设带来的结果是——基础架构相对各自独立，存储、服务器等数据中心资源各自割裂，无法共享；而更为严重的是，由于系统各自独立，很难在平台层面上进行系统优化，当需要对资源做任何一点点调整的时候，往往都需要非常复杂的变更，而且需要较长的停机时间，而随着业务的发展，能够留给信息部门做系统变更的计划停机时间也越来越短。

另一方面，用户的数据保护相对比较薄弱，之前采用了一套华为赛门铁克备份一体机做传统的数据备份，但这种传统备份架构备份的时间间隔相对比较长，通常至少是 24 小时。面对这么长的备份间隔，用户实际上很难接受 24 小时的数据丢失量。一旦存储发生故障，用户将面临一个艰难的抉择：要么从备份系统恢复数据，但可能丢失一整天的数据；要么等待生产存储的修复，但停机时间不可控（维修人员、备件能在多长时间内到医院现场？） 。因此，医院迫切需要采用更加先进的数据保护方式，来规避这个潜在的风险。

二、建设目标

医院综合各方面因素，提出了构建医院“私有云存储”平台的建设目标，具体如下：

➢ 构建一套安全、稳固的私有云存储平台，集中统一承载医院所有业务数据；

➢ 为 HIS、CIS、LIS、EMR、PACS 等核心业务数据库提供高性能、稳定可霏，并具有足够弹性的存储平台；

➢ 为 PACS 影像类数据提供大量低成本的存储空间并具有足够的扩展能力；

➢ 未来扩容应该可以基本做到不停机（停机时间在可接受范围内） ；

➢ 扩容应不受某个厂家的技术限制；

三、 IBM 解决方案

医院此次项目将为包括 HIS、CIS、LIS、EMR、PACS 等核心业务，以及其他几十个边缘小业务在内的所有应用系统提供集中统一的存储平台。这就要求这个存储平台必须在性能、稳定性、扩展能力，以及优化、管理和数据保护等方面具有更高层次的能力和特性。

3.1 方案架构

IBM 结合市场主流技术发展方向为医院提出了对所有块级别的数据进行集中，构建统一存储平台的建议。

3.1.1 物理拓扑图

![1a67805c724f4eed847edae41bb1ed9f_th.jpeg][]

3.1.2 逻辑图

![8610b6fb30484f1e9c259b68c173a448_th.jpeg][]

3.1.3 存储规划建议

![9ab40b5de04347ea83b640ff090ac249_th.jpeg][]

通过 IBM SVC 可以实现更灵活且更加与应用相适应的存储分级规划。以下规划供参考：根据业务的特点分层 5 类存储卷的特性，分别从 4 个存储池中分配空间。

A 类卷和 B 类卷为双存储镜像的高可靠性，并且具有高性能的属性，其中 A 类卷的性能更高。

C 类卷、D 类卷和 E 类卷都为单存储卷，但是他们的存储性能有高低之分。

当然根据不同的业务系统需求，还可以有其它方式的数据分级规划。

3.2 方案特点

3.2.1 实现存储资源池化

SVC 先进的存储虚拟化技术能够统一管理所有主流品牌光纤存储，利用存储虚拟化功能，医院可以将现有的 EVA 存储融合到一个统一的存储池当中，充分实现存储的利旧，而未来扩容的时候，医院仍然具有选择的主动权，可以选择任何高性价比的存储设备进行空间扩容。

通过配置超高性能的 Flashsystem（闪存阵列）存储介质，为核心业务（如 HIS、CIS、LIS 等数据库）提供超过 SSD 固态硬盘 5 至 10 倍的读写性能，将存倍 I/O延迟缩短至 1 毫秒以下，从而最大限度解决存储 I/O 性能的问题。同时，将存储系统按照容量与性能最优化配比的方式，把整个存储池进行合理优化，并自动分层，将热数据保持在超高性能的 Flashsystem 层级上，而将冷数据自动转移到二级存储（如 NLSAS 磁盘） ，甚至三级存储（如利旧的 EVA 存储）空间，从而在提升整体存储 I/O 性能的同时，降低总体存储成本。

3.2.2 优化应用运行效率

SVC 提供了有效的 QoS(Quality of Service)机制。QoS 是一种保证和控制主机I/O 流量和带宽的机制。例如，一个 140MB 每秒的影像流必须精确地以 140MB 每秒的传输率传输到存储中，否则，影像文件会无法使用。SVC 可通过 QoS 机制，使得对主机的 I/O 可以得到严格的控制。 在一个 SAN 的共享环境中， 通过使用 QoS机制，可以防止一些应用程序过多地占用共享带宽，从而保证了需要高带宽服务的应用程序正常工作。根据业务应用的需要，进行合理分配，如，可以为 HIS、CIS 等关键业务保留更多的资源，从而提升其访问性能。反之，限制边缘业务模块的资源，从而防止其在做备份等批量操作的时候影响核心业务应用的性能。

3.2.3 精简配置

可以为主机提供虚拟的存储容量，即使当前物理磁盘容量不足，仍然可以按照业务主机需要的空间进行分配。未来物理磁盘空间需要扩容时，将不再需要对主机进行重新调整，而只要将新增加的磁盘加入到存储资源池即可。这就大大减轻了扩容的工作量、降低了工作难度，并且为不停机扩容提供了可能性。

![d0d9837c6326496ea709325213f81909.jpeg][]

3.2.4 通过复制服务保护数据

1）丰富的闪速拷贝(FlashCopy)功能，可创建即时的活动数据拷贝，以便顺利开展备份工作或者并行处理活动。

2）支持增量闪速拷贝操作，只拷贝自闪速拷贝功能上次运行以来发生变化的部分源或目标卷，并且支持“拷贝的拷贝”功能 — 对副本进行拷贝 — 从而提高效率。这些功能可用于帮助公司基于生产数据来维护和更新测试环境。此功能可以与精简调配功能配合使用，实现只使用完整物理拷贝所需的部分存储资源来创建拷贝。 这项功能名为 “空间高效型闪速拷贝” (Space Efficient FlashCopy)，更好地提高存储资源的总体利用率。

3）逆向闪速拷贝(Reverse FlashCopy)功能可令闪速拷贝目标变成源卷的恢复点，但不会破坏闪速拷贝的关系，也无需您等待最初的拷贝操作完成后才能采取行动。这项新功能将帮助您立刻使用磁盘备份拷贝来恢复受损数据，从而加快应用恢复速度。

4）闪速拷贝功能可以与 IBM Tivoli Storage FlashCopy Manager 配合，支持应用服务器 24 小时全天候运行 — 并且全面保护数据。例如公司拥有一个 24x7全天候运行的环境，将无法容忍丢失任何数据，也不能接受为了充分保护数据而数小时中断关键系统的正常运行。但是，随着需要保护的数据量继续呈现指数增长，企业也日益需要将备份数据导致的故障中断控制在绝对最低水平，但 IT 流程已经接近断点。Tivoli Storage FlashCopy Manager 利用存储系统闪速拷贝可以帮助企业基于 SVC 的备份和恢复功能对备份工作进行调整，从而最大限度地降低备份影响。该产品可将备份与恢复时间从几小时缩短为几分钟---通过简化管理工作以及自动执行存储管理任务来提高生产力。

5）需要异地容灾时，可增加 SVC 存储系统。在存储系统之间通过城域镜像和全局镜像功能实现系统的异地容灾，以便在数据中心发生灾难性事件时确保数据安全。城域镜像设计用于在“城市”距离(最长 300 千米)维护完全同步拷贝，而全局镜像则设计用于异步运行，以便帮助维持更长距离的拷贝(最长 8000 千米)。这两项功能均支持 VMware vCenter Site Recovery Manager，以便快速实现灾难恢复。

![ed0f7f9a80654cceb06f02db73ec42e7_th.jpeg][]

![bba42228e78f4889b82540f23ed6e9a2_th.jpeg][]

四、针对 HIS （采用数据库 DB2 ）的优化，采用 Flashsystem

HIS 系统是医疗行业最为关键的生产系统，其数据类型主要为数据库数据。保证性能就是保证用户体验，减少医患的发生。

下面将配合用例来讨论，通过将 IBM DB2 组件迁移到闪存来帮助您减少瓶颈、优化应用、并且将性能提高 6 倍。（与普通硬盘相比，可将机柜空间需求降低 24 倍）

4.1 I/O 等待时间的问题

运行 IBM DB2 数据库的应用经常会因为使用机械的磁盘存储设备而遭遇存储 I/O 瓶颈。这种情况下，提高处理能力或者增加网络带宽根本无济于事。添加低价内存的做法虽然看似可行，但存储器最终还是会成为大多数工作负载的主要瓶颈，只不过是迟早的问题。

处理器速度在最近 20 几年呈现出指数增长；然而，传统的存储系统存取速度却没有随之增加，导致 I/O 事务处理负载通常远远高于其他系统的数据库服务器出现巨大的性能缺口。

与普通硬盘(HDD)相比，闪速存储系统可将 I/O 响应速度提升 200 倍(经 IBM测试，可从 5,000 微秒缩短为 25 微秒)、将每秒 I/O 事务处理数量增加 1,000倍(从原来的 300 次提升至 30 万次)，从而显著缩短等待时间。不可否认，您可以通过堆叠大量 HDD 来获得数千的 IOPS 吞吐量，但同时也会增加电力、机柜、场地和冷却的成本。据一家 SAN 制造商测试，他们需要使用 496 个 HDD 才能达到 RAID0 配置中大约 10 万的 IOPS 性能。

4.2 旨在提高 IBM DB2 性能的传统方法

数据量以及以数据库为中心的应用性能问题会随新用户的添加出现爆炸性增长，这对企业而言并不是什么新问题。但是，存储需求的增长以及越来越复杂的业务分析需求，给数据库服务器及其存储子系统带来了沉重压力。为了与业务增长保持同步，企业通常采用以下方法来处理数据库性能问题：

➢ 服务器和处理器性能：IT 部门最初会努力添加更多的处理器及内存或者尽量扩展数据库服务器。

➢ SQL 语句：企业投入巨资来提高 SQL 语句的效率。他们会认真规划模式开发、索引选择、以及 SQL 语句的优调与修改活动，从而减少存储器的物理存取数量。

➢ 数据库服务器特性：DB2 采用极为高级的压缩方法，能够在每个数据页中装载更多信息，从而减少存储 IO 数量。采用 BLU 加速技术的最新一代 DB2 还能提供列式存储功能，从而提高 CPU 和内存利用率--将数兆兆字节的数据保存在小容量内存和磁盘中，同时减少存储 I/O 瓶颈数量。

上述每种方法都具有巨大的短期性能改进优势，尽管有时只适用于特殊工作负载并且成本可能会很高。此外，处理器性能与存储器性能之间的差距依然存在，对于任何指定的工作负载及数据库设计而言，存储器接入仍将是性能限制因素。虽然 SQL 优调能够提供帮助，但存储 I/O 仍然是常见的主要瓶颈。扩大数据库缓冲池虽然能够减少物理 I/O 数量，但内存局限性却令此类调整困难重重。

系统管理员经常采用三种不同方法来解决存储性能问题：

➢ 增加磁盘数量：向 RAID 存储控制器中添加磁盘是提高存储性能的方法之一。添加磁盘后，您可将数据库服务器的 I/O 负载分摊给更多的物理设备，从而提高总体性能。然而，电力、场地、冷却和经济因素都会限制性能改进程度。

➢ 将频繁存取的数据隔离在它们自己的磁盘上：这种方法可以消除干扰用户访问最热门数据的不重要的 I/O，从而优化磁盘或阵列并且针对频繁存取的数据提高某些方面的服务质量。然而，若使用吞吐量仅为每秒300 I/O 的硬盘产品，即便在优化之后，性能也会远远低于 1U 闪速存储系统高达每秒几十万的 I/O 性能。

➢ 迁移到基于大容量缓存的 RAID 存储控制器：RAID 存储控制器能够跨越多个磁盘对数据实施条带处理并且将大容量缓存控制器放置在硬盘前面，从而提高性能。这些额外的缓存容量将能够创造额外的优势，尤其是在缓存命中率较高时。然而，为了满足性能目标，您将需要使用大容量缓存及大量硬盘，从而导致瓶颈问题很快便会再次出现。

4.3 闪速存储简介

固态硬盘(SSD)是指不依赖机械部件来执行数据输入/输出任务的任何存储设备。然而，SSD 也意味着封装式固态设备(form-factor)即将取代现有的 HDD。闪速存储系统不同于封装技术。封装式 SSD 与 HDD 使用相同的传统基础架 构连接线与控制器，因此具有取代 HDD 的优势。相比之下，闪速存储系统则采 用快闪芯片设计，使用快速 FPGA 控制器技术来最大限度地缩短延迟和提高带宽。

IBM FlashSystem 只使用目前市场上最高质量的闪存--单阶存储单元(SLC)及企业级多阶存储单元(eMLC)。而大多数 SSD 使用的都是不太可靠的低耐久性MLC 闪存。eMLC 闪存的使用寿命是 MLC 的 10 倍，SLC 闪存的使用寿命是 MLC 的33 倍。在整个生命周期中，MLC 闪存中的每个闪速存储单元平均可执行 3,000次写操作；而 eMLC 及 SLC 则分别是 3 万次及超过 10 万次。

4.4 全闪存存储系统

全闪存存储系统的容量高于早期版本的存储器。全闪存存储系统在断电期间无需使用更多电池便可冲洗双倍数据速率(DDR)缓存并且不包含大量的高价DDR 内存，而是使用少量的 DDR 来缓冲闪存写操作并且发挥元数据仓库的作用。全闪存存储系统可在断电期间通过小型电池来供电，以便冲洗小规模缓存以及闪存的元数据区。例如，通过全闪存解决方案，您可将 20 兆兆字节的可寻址高可用性存储容量压缩到一个 1U 设备中。

4.5 了解 I/O 等待时间

4.5.1 系统层面

对于 UNIX 操作系统，您可使用 vmstat、iostat 和 sar 命令及 nmon 实用工具。每个命令都会生成不同的输出，从而针对存储子系统性能提供极为宝贵的信息。您首先应该运行 vmstat –t 2 等 vmstat 命令。

这个命令每隔 2 秒为您显示一次带时戳的 CPU 及内存统计数据。相关字段“wa”将为您显示在系统拥有需要处理的存储 I/O 请求时，处理器闲置多长时间。如果因为等待存储作业完成而导致处理器闲置频率过高，那么，您可能需要将应用数据迁移到闪速存储系统中。

iostat 命令能够针对整个系统提供 I/O 统计数据。这个命令适用于多类不同的操作系统，如：

AIX: iostat –DRTVl 2

Linux: iostat –ktxz 2

上述命令都会报告扩展统计数据，包括每隔两秒提供一次带时戳的报告(仅限活动设备)，以便为您提供活动简图。在主标题 xfers 下面，您可以看到 tps、bread 及 bwrtn 等列标题。这些列将为您显示每秒 I/O 事务处理数量(IOPS)以及读操作和写操作的字节数。数值越高表示操作对磁盘 I/O 的依赖性越强。此外，您还应检查 avg serv(平均服务时间)及 serv qfull(服务队列已满)等其他至关重要的竖列，以便了解 I/O 运行情况。系统的平均服务时间应该在 1.0 毫秒以下，最好是 0.1 毫秒左右。如果 serv qfull 比 0.0 高很多，则说明面向I/O 的服务队列已满，操作系统正在等待磁盘接受更多的服务请求。这预示着存储子系统不再能够与工作负载保持同步。当您迁移到闪速存储子系统时，所有这些指标都将得到显著改善。

4.5.2 数据层面

DB2 提供广泛的监视表函数及视图，允许您快速深入地查看主要性能特征。为配合开展本次调查工作，我们选择了查看数据库应用的 I/O 等待时间。

![3489ba851fca4c1897e069c607134316_th.jpeg][]

从这里，您将能够看到数据库服务器请求在 I/O 等待时间方面的总体信息。

➢ BP\_HIT\_RATIO：数据库经理无需从磁盘装载页面便可处理数据或索引页面请求的时间与总时间的百分比。如果这个百分比数值接近 100%，则意味着您的应用基本上不会写入磁盘。如果远远低于 100%，尤其是上例中显示的71.26%，则意味着您的应用经常被写入磁盘，因此能够受益于闪存产品。

➢ IO\_WAIT\_TIME\_PERCENT：因 I/O 操作问题而导致应用在 DB2 服务器中的等待时间与总时间的百分比。如果这个数值很高，如上例中所示的 90%以上，则表示服务器将大部分时间都用在了等待存储 I/O 完成上面。

➢ RQST\_WAIT\_TIME\_PERCENT：系统在执行请求处理任务时在 DB2 数据库服务器中的等待时间与总时间的百分比。这个等待时间中包括系统在等待例行程序、锁定、存储 IO、收发数据及其他进程执行时所花费的时间。

➢ OVERALL\_IO\_WAIT\_TIME\_PERC：DB2 服务器因为 I/O 操作问题而浪费的等待时间与总时间的百分比。

➢ OVERALL\_IO\_WAIT\_TIME\_PERC：DB2 服务器因为 I/O 操作问题而浪费的等待时 间与总时间的百分比。

您还可以通过 MON\_GET\_BUFFERPOOL 等许多其他的监视视图和表函数来获得大量的具体信息并且开始深入了解数据库服务器的 I/O 等待时间。

4.6 预测性能改进情况

使用 DB2 监视表函数，您将能够通过升级到 FlashSystem 而轻松预测潜在性能增益。DB2 监视器提供端到端监视功能，包括深入洞悉 I/O 响应时间。由此而提供的细粒度指标将允许您详细了解数据库系统性能。

建立基准线

我们首先要建立基准线，以便量化应用的当前存储 I/O 性能。下面的查询示例(DB2 v10.5 及更高版本)显示了已被读写的缓冲池页面总数 2 及其处理每个 I/O 请求所用的平均时间(毫秒)。

sql 语句：

![2f58e46dc295443dab9e7fb9a3b2b1ce_th.jpeg][]

输出信息：

![7bd43e72a37245178062eff95f5886b1.png][]

下面的查询示例计算出了系统写入的事务日志记录数量以及每次操作所用的时间(毫秒)。

![75ce6361ff334eb29dc5b388402bf8be_th.jpeg][]

通过将 FlashSystem I/O 响应时间与当前系统的响应时间进行比较，我们可以计算出升级到 FlashSystem 存储系统之后的 I/O 响应时间改进程度。

![2d56cdb1f8e142368271105dc0af9fdb.jpeg][]

说明: 如想制作基准线样本，您可以标出系统对数据库页面读/写操作的响应时间及日志文件 I/O。

根据下面的计算结果，我们可以看出 FlashSystem 能够显著缩短 I/O 响应时间：

Current average IO response time =

79.21% x 8795 (db file reads)

+ 19.86% x 1342 (db file writes)

+ 0.94% x 15722 (log file IO)

= 7380 usec

FlashSystem estimated average IO response time =

79.21% x 160 (db file read projected)

+ 19.86% x 80 (db file writes projected)

+ 0.94% x 80 (log file IO projected)

= 143 usec

根据预测结果，对于 I/O 响应时间，您可将性能提高 7380/143=51 倍(刚好超过51 倍)或者节省 98%的 I/O 处理时间。 然而，这并不意味着您的应用在处理工作负载时真能取得这样的进步。下面， 我们将阐述如何在开展估算活动时将其他相关指标考虑在内。

4.7 估算 DB2 的性能改进程度

对于服务器处理的指定 DB2 请求而言，存储 I/O 只不过是决定服务器请求处理总时长的诸多因素之一。处理段、编译语句、等待锁定及排序等都是相关影响因素。因此，您在估算用于每个数据库请求的性能改进程度时，应了解应用在处理每个请求时执行存储 I/O 任务所用的时间与总时间的百分比。 在上文中，我们已经介绍了如何使用 SYSIBMADM.MON\_ CONNECTION\_SUMMARY 视图来深入洞悉面向指定连接的 I/O 等待时间与总时间的百分比。然而，属于指定 DB2 工作负载的应用可能与数据库之间存在多条连接。通过使用 DB2 表函数，您将能够获得统一视图来了解执行存储 I/O 任务的时间与 DB2 请求处理总时间的百分比：

![0f5fd7c509f74919bbbc21b0724c54ac_th.jpeg][]

这个计算假设响应时间能够改进 98%，并且假设只有 20%的 DB2 服务器请求存在I/O 等待时间问题：

98 (Improvement of FlashSystem response time for each storage I/O request)

x 20.53% (Percentage of time DB2 server spends in storage I/O for 17

each DB2 request)

= 20.11% (Projected performance improvement for each DB2 request)

在这个示例中，从 DB2 服务器的角度看，与传统 HDD 相比，使用闪存可将 DB2 请求的平均处理时间加快 20.11%。然而，您在决定总体改进程度时还需考虑另一个因素。我们将在下一节进行讨论。

4.8 估算端到端的总体改进程度

最后，为了决定您可能获得的总体应用收益，我们还要考虑客户端闲置时间，换句话说，就是 DB2 服务器等待客户端发送下一个请求时渡过的时间。我们可以将这段时间理解成客户端用于“思考”应用的时间，您在制作全盘系统视图时不应遗漏这个元素。如果您发现系统一点都不繁忙，则属于最糟糕的状况，意味着系统将大部分时间浪费在等待客户端做出响应上面，而不是执行存储I/O 操作任务。

例如，下面的表函数查询显示了 I/O 等待时间与服务器处理时间及应用思考时间的百分比：

![3d26ab48650b4d218894ad170b6e1895_th.png][]

这个查询对上面的查询进行了扩展，在开展计算时将客户端闲置等待时间包含在内。

在这个示例中，预计通过升级到 FlashSystem 可以实现的端到端改进程度是：

98 (Improvement of FlashSystem response time for each storage I/O request)

x 3.88% (storage I/O wait percentage for each DB2 request including client wait time)

= 3.80% (Overall projected performance improvement)

因此，我们预计如果通过闪速存储系统来替换传统的 HDD 存储系统，将能够实 现 3.80%的性能改进。

4.9 可以迁移到闪速存储系统的组件

在您确定系统遇到了 I/O 子系统问题之后，接下来应该决定哪些 DB2 数据库组件 I/O 最高，从而找到造成 I/O 等待时间过长的根源。您应评估下面几个数据库组件：

◆ 整个数据库

有些数据库的文件可以悉数迁移到闪速存储系统中。这些数据库至少具备以下特征之一：

➢ 并发存取程度高：当数据索引页面不在缓冲池中时，每条用户连接至少会通过一个代理从磁盘中读取数据。当多个并发的引擎可调度单元(EDU)同时从磁盘读取数据时，您将能够大大受益于闪速存储系统。

➢ 随机存取表：闪速存储系统擅长处理内含可以随机检索或更新的记录的表格。

➢ 中小型数据库：鉴于购买 RAID 系统的相关固定成本极高，因此，购买闪速存储系统更具经济性。例如，FlashSystem 710 可通过低于大多数企业级RAID 系统的价格提供 1 太字节的数据库存储容量。

➢ 大规模的读操作密集型数据库：您可降低与传统 RAID 系统相关的成本，此类系统经常需要大容量缓存及多个转子才能提供可以接受的性能，并且经常要求您提供多个宝贵的机柜空间来安装 HDD；而FlashSystem 820 却能通过扩展功能而在 1U 机柜中支持 24 TB 的存储容量并且具有极快的速度，尤其适合处理读操作密集型工作负载。

➢ 性能及可盈利性：当他们依赖的数据库以最高性能运转时，某些公司也许能够在更短时间内处理更多业务。但是，闪速存储系统却能够在不影响可靠性的情况下显著提高数据库性能，从而直接提高系统 ROI。

◆ DB2 日志

数据库中每一次的事务插入/更新/删除操作都会生成事务日志文件。系统在执行事务处理任务时会对这些文件实施连续写操作，导致数据变化在这里被标记出来，甚至在缓冲池中的脏页面写入到磁盘之前。在群集式 IBM DB2 pureScale 环境中，每个群集成员都会对它们自己的事务日志文件执行连续写操作，因此与普通的非 pureScale DB2 相比，对缩短日志写入的延迟时间要求更加严格。将事务日志文件迁移到闪速存储系统能够立即产生性能优势，尤其是当 HDD 的平均日志写操作时间超过 2-3 毫秒时。

◆ 索引

索引是指依据直接引用表中行项的一个或多个键值进行逻辑排序的数据结构。按键值来查找行项是极为快速的操作，只需读取极少数 I/O 页面即可，即便在表规模极大的情况下也不例外。接下来，查询优化器将通过直接接入表格或者使用索引来明智地决定哪种方法最适合处理指定查询。将索引保存在闪速存储系统上能够提高性能，尤其是在大规模 OLTP 系统中 一 在此类环境中，索引存取操作高度密集，并且索引查找活动仍会引发物理磁盘读操作。

◆ 临时表

如果服务器没有足够的内存来完成复杂排序、散列或其他操作，您可通过创建临时表来帮助排序这些中间结果。这些复杂的操作随后可能因为与临时表进行频繁互动而成为瓶颈，尤其是当这些表从缓冲池溢流到磁盘时。因此，将临时表保存在闪速存储系统中将能够帮助您提高时间更长、结构更复杂的查询性能。

◆ 频繁存取的表

在拥有大量并发用户的大型 OLTP 环境中，不同的用户很可能会在同一时间在不同的数据集上查找数据。某些表可能作为核心应用组件而极其炙手可热。即便提供最大的可用缓冲池容量，用户对这些表的随机存取最终也经常在磁盘中完成。旋转硬盘在处理大规模随机数据请求方面一直不尽人意。实际上，在处理随机事务时，硬盘性能可能会降低高达 95%。因此，将频繁存取的表迁移到闪速存储系统乃是明智之举。

◆ 随机存取对闪速存储系统的影响远远低于普通硬盘，这也是造成二者之间存在性能差距的最重要的原因。

4.10 案例分析

4.10.1 工作负载： IBM InfoSphere Identity Insight

IBM 提供一系列的实体分析解决方案(EAS)来帮助您跨越稀疏分布的多个不同的大规模数据。这些解决方案可对事件、人、事物、交易和关联性进行分析，从而给决策人提供敏锐的洞察力。

IBM InfoSphere Identity Insight 进程可运行在远程客户端，首先摄取原始的源数据，然后再将这些数据注入到数据库中，并且通过执行查询来了解哪些现有数据可能与全新信息片段存在关联性。InfoSphere Identity Insight 接下来将决定是将这些新数据与现有数据链接在一起、还是在数据库中另辟一个位置来保存它们。 从数据库的角度看，在存储子系统层，数据正被快速随机读取着，正被更新或 写入的数据只占到工作负载的一小部分。随着数据库规模越来越大， InfoSphere Identity Insight 为了做出决策以及执行适当统计任务而开展的 读操作数量也变得越来越多。工作负载分配情况大约是 90%的随机读工作负载 与 10% 的随机写工作负载。基于上文所述，包含大量随机读工作负载及并发用 户的环境将能够受益于闪速存储系统。

4.10.2 环境配置

我们在配合本文开展的调查中使用了运行在 p740 上面的 DB2 Version 10.5 数据服务器以及运行 IBM AIX 7.1 的 IBM Power7 系统，然后将它们与带有 HDD 的IBM Storwize v7000 存储控制器及 FlashSystem 820 闪速存储子系统相连接，以便开展比较活动。InfoSphere Identity Insight 远程客户端是运行在 IBMPureFlex 机箱中的 3 个计算节点。

• Storwize V7000：32 个 900GB 10 K SAS HDD，分布在 4 个 RAID5 (7+1)阵列之间。

• FlashSystem 820：12 个 1TB 闪存模块、RAID5 及 32 个 LUN。性能比较低级的性能基准测试经常只能显示存储控制器或闪存系统在合成环境中的运行速度。这并不是真正的测试，真正有意义的测试是将这些控制器与真实应用进行比较，然后决定您能够获得哪些可观收益。

图 1 显示了在 HDD 上面运行 2 个多小时的 InfoSphere Identity Insight(在控制器缓存开启及关闭情况下)与在 FlashSystem 上面开展类似操作存在怎样的性能差距。

![6b2b242e83214d99a8d193575e6b8107_th.jpeg][]

图 1

比较 HDD、V7000 闪速存储系统及 IBM FlashSystem 820 的 IBM InfoSphere Identity Insight 处理性能(每分钟事务处理数量)

v7000 处理器缓存开启之后，因为工作负载尚未成为存储 I/O 瓶颈，因此前 15分钟的性能基本相同。一旦瓶颈转移到存储 I/O，v7000 控制器缓存的利用率便会升高，此时，您将看到闪存能够多处理许多额外事务。

图 2 更加具体地显示了上述运行情况，从这里，我们可以看到闪存的优势一目了然。

![eeb9ce49c14d4a02a91a3115cff724f7_th.jpeg][]

图 2

HDD、V7000 闪速存储系统及 IBM FlashSystem 820 的 IBM InfoSphere Identity Insight 处理性能(每分钟事务处理数量)的具体比较视图

使用 InfoSphere Identity Insight 摄取最初的数据集对于最大限度地增强这项优势极为至关重要。如想更加清晰地了解这种情况，您需要知道FlashSystem 820 摄取前 420 万个记录需要多长时间。在此期间，尤其是前几分钟，v7000 控制器缓存将会隐藏 HDD 的性能缺陷。尽管如此，我们从“表 2”中还是可以看出通过从 HDD 切换到基于快速控制器缓存的闪速存储系统， 您可在 1/3 时间内处理相同数量的事务。如果关闭这个缓存， 则 FlashSystem 的性能将是 HDD 的 8 倍以上。

对这个工作负载而言，存储 I/O 的响应时间是关键要素。因为这两类存储控制器都具有很高的 IOPS 性能，尤其是在 v7000 使用快速控制器缓存的情况下。如果我们在工作负载进一步成为 I/O 瓶颈时再次观察这些数据的话，将会发现使用闪存能够获得更多优势。

如“表 2”所示，DB2 在刚开始处理记录时缓冲池命中率为 99.99%，这意味着DB2 无需经常访问磁盘。随着缓冲池命中率跌至 80%左右，DB2 工作负载向存储系统发送的物理 I/O 请求数量越来越多。此时，如“表 3”所示，使用FlashSystem 820 可取得 6.2 倍的性能优势。在关闭 HDD 存储控制器缓存之后，我们看到性能可提高 16 倍。这无疑可以证明面向 HDD 提供快速控制器缓存的确有所帮助，但是，随着这些缓存逐渐失效，闪速存储系统与 HDD 之间的性能差距会逐渐扩大。

![f40313cd76a24413babf4b6ad70c8d38.jpeg][]

表 2

与 HDD 相比，使用闪速存储系统可将应用的记录处理数量增加近 3 倍，在关闭存储器缓存之后甚至能够超过 8 倍

![0505cc6cd1c844b4a3156809e1816a25.jpeg][]

表 3

随着越来越多的事务处理成为 I/O 瓶颈，使用闪存可将性能提高 6.1 倍。

除上述指标外，系统对已经摄入的 InfoSphere Identity Insight 记录的处理速度也是一个重要指标。当您查看率先问鼎 1000 万个记录大关的第一个环境时，将会发现 FlashSystem 的高级持续 IOPS 与低延迟特征能够创造巨大的性能优势。“图 3”明确显示了随着时间的流逝，HDD 环境将不再能够维持最初的吞吐量水平，问鼎 1000 万个记录大关至少还需要另外 6 个小时。而 FlashSystem则能够继续以相对稳定的速度来处理记录，可在 2 小时内达到 100 万个记录的水平。

![d507cf1b1c774508b823d561875ddd3e_th.jpeg][]

图 3

HDD、带 HDD 的 V7000 闪速存储系统及 IBM FlashSystem 820 达到 1000 万个

IBM InfoSphere Identity Insight 记录处理吞吐量水平所需的时间 在这个特殊的测试中， 我们的 v7000 存储控制器在开启缓存之后峰值可达到106,737 IOPS，平均响应时间是 0.5 毫秒。产品在开始运行之后仅 16 分钟便进入高峰期，此时，存储控制器的缓存仍然能够将抢手的页面(sought-after)保存在内存中。大约两小时之后，随着数据库规模的增长，性能峰值降至大约17,000 IOPS，说明控制器缓存已经不够用了。

当我们对关闭了缓存的 v7000 开展比较测试时，发现 HDD 同样能够在投入运行初期达到峰值，此时的页面局部性依然良好并且 HDD 本地缓存(并非控制器缓存)仍然能够创造优势。这一点从 0.3 毫秒响应时间下 26,586 IOPS 的峰值可以得到证明；然而，随着数据库规模的增长及页面局部性的消失，HDD 在 8-10 毫秒响应时间下吞吐量跌至 6,300-10,500 IOPS 之间，大约相当于每个 HDD 195-330 IOPS 的性能。相比之下，FlashSystem 控制器可在 0.3 毫秒的响应时间下达到 174,796 IOPS 的性能。经工作负载测试，我们可以证明 FlashSystem 控制器能够达到 400K IOPS 以上的运行速度。即便 IOPS 并未达到控制器极限值，FlashSystem 的超低延迟也能帮助您显著提高应用的总体性能。

“图 4”显示了存储 I/O 性能随数据库规模增长的变化趋势。

![94b610238be64c38a3cf4f3ffbd1171c_th.jpeg][]

图 4

比较带有 HDD 的 V7000 与 IBM FlashSystem 820 在处理 IBM InfoSphere Identity Insight 工作负载时的存储 IOPS 性能

这次测试再次证明了我们对 HDD 存储控制器的早期测试结果：在工作负载处理初期，即数据库规模仍然较小时，HDD 存储控制器能够受益于控制器缓存。然而，随着页面存取数量逐渐增多，HDD 的 IOPS 性能将呈现出下降趋势，最终将跌破 20K IOPS 关口，由此可见 HDD 的高峰期性能是每个转子 330 IOPS。

另一方面，FlashSystem 似乎还远远没有发挥全部潜能，IOPS 呈现出不断的上升趋势。虽然“图 4”似乎呈现出性能逐渐降低的趋势，但我们实际上只显示了前两个小时的运行情况。这段时间过后，我们看到该系统在处理相关工作负载时性能高达 175,000 IOPS。我们由此推断，如果添加更多的 InfoSphereIdentity Insight 管线，此类工作负载将会进一步增强对存储 IOPS 的性能需求，因此给 HDD 环境带来更加沉重的压力，从而进一步拉大两个环境间的性能差距。

4.10.3 迁移到闪速存储系统

当您使用闪速存储子系统来迁移现有环境或者构建下一个系统时，所能获得的不仅仅是原始性能优势。在举例说明中，我们将闪速存储系统在处理特定工作负载时的高峰期性能设定为 175,000 IOPS，并且证实我们的 HDD 的确能够提供每个 HDD 大约 330 IOPS 的吞吐量。若想使用 HDD 提供这个 IOPS 吞吐量，我们将需要 530 个 HDD 转子，鉴于一个普通 I/O 抽屉通常在 2U 机柜空间中支持 24个 HDD，因此， 我们将需要 23 个 I/O 抽屉，总共占用 46U 机柜空间。诚然，HDD 环境能够受益于存储控制器缓存，将每个 HDD 转子的性能提升至大约 625IOPS，此时您将只需要 280 个 HDD，将它们安装在 24U 机柜空间中即可。即便如此，FlashSystem 820 却能轻松安装在 1U 机柜空间中,在 IOPS 吞吐量不到峰值一半的情况下,因此能够显著节省电力和场地，机柜空间需求至少比传统 HDD降低 24 倍。

4.10.4 结语

数据中心处理日常工作的能力已经接近临界点，因此要求存储容量和性能不断实现突破。通过将 DB2 从 HDD 迁移到 FlashSystem，我们为您演示了如何估算以及准确测量性能改进程度，以便从多方面实现巨幅性能增益。此外，降低机柜空间需求及冷却和管理成本也能帮助您提高数据中心效率，同时增加数据中心服务器容量并且提高性能。

五、总结

✓ 高性能

利用 IBM 专利技术的 Flashsystem 全闪存介质，IBM 构建了医院私有云存储最高性能的第一层存储空间， 为核心业务提供了低于 1 毫秒的 I/O 响应时延。 采用 IBMFlashsystem 全闪存实现 I/O 性能的大幅度提升，其效果是非常明显的，也是可预期的；

✓ 成本与性能的最佳平衡

通过采用 easy tier 动态分层技术，医院充分利用 Flashsystem 全闪存介质的优势，让更多的业务应用享受到 I/O 性能提升的好处，easy tier 独特的数据迁移篥略优化功能、智能化场景 I/O 特性采集，让医院核心数据库数据自动分层得以真正实现;

✓ 极短的计划停机时间

通过 IBM 成熟的存储虚拟化技术，医院在极短的时间内完成了对 EVA 中几十 TB数据的在线迁移。考虑到医院已经越来越短的夜间停机窗口，这一优势也是医院对 IBM 私有云平台最初认可的重要原因之一；

✓ 可回退、无风险的数据迁移

相比于其他厂商的解决方案，由于 IBM 在虚拟化外部存储的时候并不需要修改其数据格式，因而可以在虚拟化意外失败的情况下直接回退到原始的存储架构，这就有效避免了数据迁移的风险；

✓ 平台延展性更高

基于 IBM 的私有云存储平台， 医院可以无缝扩展到对海量 PACS 影像文件的支持，以及未来 DICOM、CDA 等对象数据的支持，而其他厂商的产品往往都不具有类似的高整合度和统一性：另一方面，IBM 可以横向扩展为双活同步容灾，以及“三中心”容灾架构，而其他厂商的私有云存储平台往往不能同时兼备这些功能。

[1a67805c724f4eed847edae41bb1ed9f_th.jpeg]: /images/20220616/7582efdd378140b2976704a94e5b3215.png
[8610b6fb30484f1e9c259b68c173a448_th.jpeg]: /images/20220616/c712f6fc56d0485ba61670749b4c83a9.png
[9ab40b5de04347ea83b640ff090ac249_th.jpeg]: /images/20220616/031f515815034cc897392798856804bc.png
[d0d9837c6326496ea709325213f81909.jpeg]: /images/20220616/f3389ae5325c4fc08c899c4f2109c22f.png
[ed0f7f9a80654cceb06f02db73ec42e7_th.jpeg]: /images/20220616/034eaf5597c64aabbb744927b369793e.png
[bba42228e78f4889b82540f23ed6e9a2_th.jpeg]: /images/20220616/4cee18e334254bb7b9b2f1e79c720480.png
[3489ba851fca4c1897e069c607134316_th.jpeg]: /images/20220616/619fb5b6e9b543d0bf68ac3230e86a73.png
[2f58e46dc295443dab9e7fb9a3b2b1ce_th.jpeg]: /images/20220616/1205e46240e344b0b53ac52917200fd9.png
[7bd43e72a37245178062eff95f5886b1.png]: /images/20220616/b73db3d353f64b9ca73cb2af82584a27.png
[75ce6361ff334eb29dc5b388402bf8be_th.jpeg]: /images/20220616/9e0586ed8ba240dd9e581b8d89081214.png
[2d56cdb1f8e142368271105dc0af9fdb.jpeg]: /images/20220616/b1506d235d704dd5a9dc0fab7a511653.png
[0f5fd7c509f74919bbbc21b0724c54ac_th.jpeg]: /images/20220616/46b37fdefb1f420bab2c03bcee3a8b10.png
[3d26ab48650b4d218894ad170b6e1895_th.png]: /images/20220616/b06594847e83425fb99dd31b7db1de4d.png
[6b2b242e83214d99a8d193575e6b8107_th.jpeg]: /images/20220616/bcc5337165a1444eaaed052bb40dfc38.png
[eeb9ce49c14d4a02a91a3115cff724f7_th.jpeg]: /images/20220616/de854a7bcb0d47e2808324e09395b388.png
[f40313cd76a24413babf4b6ad70c8d38.jpeg]: /images/20220616/90ade06feb9040c29bd6fd2639452a99.png
[0505cc6cd1c844b4a3156809e1816a25.jpeg]: /images/20220616/aa044babb23a4d1d8c1f9362edf8a65e.png
[d507cf1b1c774508b823d561875ddd3e_th.jpeg]: /images/20220616/4e57e594150140e896563d02e7c808c4.png
[94b610238be64c38a3cf4f3ffbd1171c_th.jpeg]: /images/20220616/416f24d3cd7940feafb2473fdf9a2ce1.png