医院私有云存储规划配置与调优方案.docx
《医院私有云存储规划配置与调优方案.docx》由会员分享，可在线阅读，更多相关《医院私有云存储规划配置与调优方案.docx（21页珍藏版）》请在冰豆网上搜索。
医院私有云存储规划配置与调优方案
医院私有云存储规划配置与调优方案
一、项目背景介绍
某人民医院（以下简称医院）是集医疗、教学、科研、预防为一体的现代化国家三级甲等综合医院。
医院现有A、B、C三个主体院区，编制床位1500张，开放病床3000张。
在领导班子的带领下，医院全面实施“数字化医院”建设，首创医疗质量管理信息系统、建立城乡协同医疗服务网络，依托国内顶尖医院推动学科建设，聘请国内一流专家定期来院工作，打造一流医疗团队。
医院作为某市的龙头医院，其整体业务呈现快速增长的态势，当前医院正在扩建新的住院病区，随着住院床位数的增加，医院的业务必然会有一个明显的增长，而医院的存储基础架构已经相对老化，其现有的EVA系列存储已经表现出性能瓶颈，医院当前的核心数据库存在性能不均衡的情况，如果要求应用软件开发商进行性能调优，可能需要花费大量人力物力，但却不能保证调优的效果。
目前，医院的核心业务包含HIS、CIS、LIS、EMR、PACS等，另外还有几十个小的边缘业务模块，多年的业务建设带来的结果是——基础架构相对各自独立，存储、服务器等数据中心资源各自割裂，无法共享；而更为严重的是，由于系统各自独立，很难在平台层面上进行系统优化，当需要对资源做任何一点点调整的时候，往往都需要非常复杂的变更，而且需要较长的停机时间，而随着业务的发展，能够留给信息部门做系统变更的计划停机时间也越来越短。
另一方面，用户的数据保护相对比较薄弱，之前采用了一套华为赛门铁克备份一体机做传统的数据备份，但这种传统备份架构备份的时间间隔相对比较长，通常至少是24小时。
面对这么长的备份间隔，用户实际上很难接受24小时的数据丢失量。
一旦存储发生故障，用户将面临一个艰难的抉择：
要么从备份系统恢复数据，但可能丢失一整天的数据；要么等待生产存储的修复，但停机时间不可控（维修人员、备件能在多长时间内到医院现场？
）。
因此，医院迫切需要采用更加先进的数据保护方式，来规避这个潜在的风险。
二、建设目标
医院综合各方面因素，提出了构建医院“私有云存储”平台的建设目标，具体如下：
➢ 构建一套安全、稳固的私有云存储平台，集中统一承载医院所有业务数据；
➢ 为HIS、CIS、LIS、EMR、PACS等核心业务数据库提供高性能、稳定可霏，并具有足够弹性的存储平台；
➢ 为PACS影像类数据提供大量低成本的存储空间并具有足够的扩展能力；
➢ 未来扩容应该可以基本做到不停机（停机时间在可接受范围内）；
➢ 扩容应不受某个厂家的技术限制；
三、解决方案
医院此次项目将为包括HIS、CIS、LIS、EMR、PACS等核心业务，以及其他几十个边缘小业务在内的所有应用系统提供集中统一的存储平台。
这就要求这个存储平台必须在性能、稳定性、扩展能力，以及优化、管理和数据保护等方面具有更高层次的能力和特性。
3.1 方案架构
IBM结合市场主流技术发展方向为医院提出了对所有块级别的数据进行集中，构建统一存储平台的建议。
3.1.1 物理拓扑图
3.1.2 逻辑图
3.1.3 存储规划建议
通过IBMSVC可以实现更灵活且更加与应用相适应的存储分级规划。
以下规划供参考：
根据业务的特点分层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（QualityofService）机制。
QoS是一种保证和控制主机I/O流量和带宽的机制。
例如，一个140MB每秒的影像流必须精确地以140MB每秒的传输率传输到存储中，否则，影像文件会无法使用。
SVC可通过QoS机制，使得对主机的I/O可以得到严格的控制。
在一个SAN的共享环境中，通过使用QoS机制，可以防止一些应用程序过多地占用共享带宽，从而保证了需要高带宽服务的应用程序正常工作。
根据业务应用的需要，进行合理分配，如，可以为HIS、CIS等关键业务保留更多的资源，从而提升其访问性能。
反之，限制边缘业务模块的资源，从而防止其在做备份等批量操作的时候影响核心业务应用的性能。
3.2.3 精简配置
可以为主机提供虚拟的存储容量，即使当前物理磁盘容量不足，仍然可以按照业务主机需要的空间进行分配。
未来物理磁盘空间需要扩容时，将不再需要对主机进行重新调整，而只要将新增加的磁盘加入到存储资源池即可。
这就大大减轻了扩容的工作量、降低了工作难度，并且为不停机扩容提供了可能性。
3.2.4 通过复制服务保护数据
1）丰富的闪速拷贝（FlashCopy）功能，可创建即时的活动数据拷贝，以便顺利开展备份工作或者并行处理活动。
2）支持增量闪速拷贝操作，只拷贝自闪速拷贝功能上次运行以来发生变化的部分源或目标卷，并且支持“拷贝的拷贝”功能—对副本进行拷贝—从而提高效率。
这些功能可用于帮助公司基于生产数据来维护和更新测试环境。
此功能可以与精简调配功能配合使用，实现只使用完整物理拷贝所需的部分存储资源来创建拷贝。
这项功能名为“空间高效型闪速拷贝”（SpaceEfficientFlashCopy），更好地提高存储资源的总体利用率。
3）逆向闪速拷贝（ReverseFlashCopy）功能可令闪速拷贝目标变成源卷的恢复点，但不会破坏闪速拷贝的关系，也无需您等待最初的拷贝操作完成后才能采取行动。
这项新功能将帮助您立刻使用磁盘备份拷贝来恢复受损数据，从而加快应用恢复速度。
4）闪速拷贝功能可以与IBMTivoliStorageFlashCopyManager配合，支持应用服务器24小时全天候运行—并且全面保护数据。
例如公司拥有一个24x7全天候运行的环境，将无法容忍丢失任何数据，也不能接受为了充分保护数据而数小时中断关键系统的正常运行。
但是，随着需要保护的数据量继续呈现指数增长，企业也日益需要将备份数据导致的故障中断控制在绝对最低水平，但IT流程已经接近断点。
TivoliStorageFlashCopyManager利用存储系统闪速拷贝可以帮助企业基于SVC的备份和恢复功能对备份工作进行调整，从而最大限度地降低备份影响。
该产品可将备份与恢复时间从几小时缩短为几分钟---通过简化管理工作以及自动执行存储管理任务来提高生产力。
5）需要异地容灾时，可增加SVC存储系统。
在存储系统之间通过城域镜像和全局镜像功能实现系统的异地容灾，以便在数据中心发生灾难性事件时确保数据安全。
城域镜像设计用于在“城市”距离（最长300千米）维护完全同步拷贝，而全局镜像则设计用于异步运行，以便帮助维持更长距离的拷贝（最长8000千米）。
这两项功能均支持VMwarevCenterSiteRecoveryManager，以便快速实现灾难恢复。
四、针对HIS（采用数据库DB2）的优化，采用Flashsystem
HIS系统是医疗行业最为关键的生产系统，其数据类型主要为数据库数据。
保证性能就是保证用户体验，减少医患的发生。
下面将配合用例来讨论，通过将IBMDB2组件迁移到闪存来帮助您减少瓶颈、优化应用、并且将性能提高6倍。
（与普通硬盘相比，可将机柜空间需求降低24倍）
4.1I/O等待时间的问题
运行IBMDB2数据库的应用经常会因为使用机械的磁盘存储设备而遭遇存储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 旨在提高IBMDB2性能的传统方法
数据量以及以数据库为中心的应用性能问题会随新用户的添加出现爆炸性增长，这对企业而言并不是什么新问题。
但是，存储需求的增长以及越来越复杂的业务分析需求，给数据库服务器及其存储子系统带来了沉重压力。
为了与业务增长保持同步，企业通常采用以下方法来处理数据库性能问题：
➢ 服务器和处理器性能：
IT部门最初会努力添加更多的处理器及内存或者尽量扩展数据库服务器。
➢ SQL语句：
企业投入巨资来提高SQL语句的效率。
他们会认真规划模式开发、索引选择、以及SQL语句的优调与修改活动，从而减少存储器的物理存取数量。
➢ 数据库服务器特性：
DB2采用极为高级的压缩方法，能够在每个数据页中装载更多信息，从而减少存储IO数量。
采用BLU加速技术的最新一代DB2还能提供列式存储功能，从而提高CPU和内存利用率--将数兆兆字节的数据保存在小容量内存和磁盘中，同时减少存储I/O瓶颈数量。
上述每种方法都具有巨大的短期性能改进优势，尽管有时只适用于特殊工作负载并且成本可能会很高。
此外，处理器性能与存储器性能之间的差距依然存在，对于任何指定的工作负载及数据库设计而言，存储器接入仍将是性能限制因素。
虽然SQL优调能够提供帮助，但存储I/O仍然是常见的主要瓶颈。
扩大数据库缓冲池虽然能够减少物理I/O数量，但内存局限性却令此类调整困难重重。
系统管理员经常采用三种不同方法来解决存储性能问题：
➢ 增加磁盘数量：
向RAID存储控制器中添加磁盘是提高存储性能的方法之一。
添加磁盘后，您可将数据库服务器的I/O负载分摊给更多的物理设备，从而提高总体性能。
然而，电力、场地、冷却和经济因素都会限制性能改进程度。
➢ 将频繁存取的数据隔离在它们自己的磁盘上：
这种方法可以消除干扰用户访问最热门数据的不重要的I/O，从而优化磁盘或阵列并且针对频繁存取的数据提高某些方面的服务质量。
然而，若使用吞吐量仅为每秒300I/O的硬盘产品，即便在优化之后，性能也会远远低于1U闪速存储系统高达每秒几十万的I/O性能。
➢ 迁移到基于大容量缓存的RAID存储控制器：
RAID存储控制器能够跨越多个磁盘对数据实施条带处理并且将大容量缓存控制器放置在硬盘前面，从而提高性能。
这些额外的缓存容量将能够创造额外的优势，尤其是在缓存命中率较高时。
然而，为了满足性能目标，您将需要使用大容量缓存及大量硬盘，从而导致瓶颈问题很快便会再次出现。
4.3 闪速存储简介
固态硬盘（SSD）是指不依赖机械部件来执行数据输入/输出任务的任何存储设备。
然而，SSD也意味着封装式固态设备（form-factor）即将取代现有的HDD。
闪速存储系统不同于封装技术。
封装式SSD与HDD使用相同的传统基础架构连接线与控制器，因此具有取代HDD的优势。
相比之下，闪速存储系统则采用快闪芯片设计，使用快速FPGA控制器技术来最大限度地缩短延迟和提高带宽。
IBMFlashSystem只使用目前市场上最高质量的闪存--单阶存储单元（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–t2等vmstat命令。
这个命令每隔2秒为您显示一次带时戳的CPU及内存统计数据。
相关字段“wa”将为您显示在系统拥有需要处理的存储I/O请求时，处理器闲置多长时间。
如果因为等待存储作业完成而导致处理器闲置频率过高，那么，您可能需要将应用数据迁移到闪速存储系统中。
iostat命令能够针对整个系统提供I/O统计数据。
这个命令适用于多类不同的操作系统，如：
AIX:
iostat–DRTVl2
Linux:
iostat–ktxz2
上述命令都会报告扩展统计数据，包括每隔两秒提供一次带时戳的报告（仅限活动设备），以便为您提供活动简图。
在主标题xfers下面，您可以看到tps、bread及bwrtn等列标题。
这些列将为您显示每秒I/O事务处理数量（IOPS）以及读操作和写操作的字节数。
数值越高表示操作对磁盘I/O的依赖性越强。
此外，您还应检查avgserv（平均服务时间）及servqfull（服务队列已满）等其他至关重要的竖列，以便了解I/O运行情况。
系统的平均服务时间应该在1.0毫秒以下，最好是0.1毫秒左右。
如果servqfull比0.0高很多，则说明面向I/O的服务队列已满，操作系统正在等待磁盘接受更多的服务请求。
这预示着存储子系统不再能够与工作负载保持同步。
当您迁移到闪速存储子系统时，所有这些指标都将得到显著改善。
4.5.2 数据层面
DB2提供广泛的监视表函数及视图，允许您快速深入地查看主要性能特征。
为配合开展本次调查工作，我们选择了查看数据库应用的I/O等待时间。
从这里，您将能够看到数据库服务器请求在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性能。
下面的查询示例（DB2v10.5及更高版本）显示了已被读写的缓冲池页面总数2及其处理每个I/O请求所用的平均时间（毫秒）。
sql语句：
输出信息：
下面的查询示例计算出了系统写入的事务日志记录数量以及每次操作所用的时间（毫秒）。
通过将FlashSystemI/O响应时间与当前系统的响应时间进行比较，我们可以计算出升级到FlashSystem存储系统之后的I/O响应时间改进程度。
说明:
如想制作基准线样本，您可以标出系统对数据库页面读/写操作的响应时间及日志文件I/O。
根据下面的计算结果，我们可以看出FlashSystem能够显著缩短I/O响应时间：
CurrentaverageIOresponsetime=
79.21%x8795（dbfilereads）
+19.86%x1342（dbfilewrites）
+0.94%x15722（logfileIO）
=7380usec
FlashSystemestimatedaverageIOresponsetime=
79.21%x160（dbfilereadprojected）
16
+19.86%x80（dbfilewritesprojected）
+0.94%x80（logfileIOprojected）
=143usec
根据预测结果，对于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请求处理总时间的百分比：
这个计算假设响应时间能够改进98%，并且假设只有20%的DB2服务器请求存在I/O等待时间问题：
98（ImprovementofFlashSystemresponsetimeforeachstorageI/Orequest）
x20.53%（PercentageoftimeDB2serverspendsinstorageI/Ofor17
eachDB2request）
=20.11%（ProjectedperformanceimprovementforeachDB2request）
在这个示例中，从DB2服务器的角度看，与传统HDD相比，使用闪存可将DB2请求的平均处理时间加快20.11%。
然而，您在决定总体改进程度时还需考虑另一个因素。
我们将在下一节进行讨论。
4.8 估算端到端的总体改进程度
最后，为了决定您可能获得的总体应用收益，我们还要考虑客户端闲置时间，换句话说，就是DB2服务器等待客户端发送下一个请求时渡过的时间。
我们可以将这段时间理解成客户端用于“思考”应用的时间，您在制作全盘系统视图时不应遗漏这个元素。
如果您发现系统一点都不繁忙，则属于最糟糕的状况，意味着系统将大部分时间浪费在等待客户端做出响应上面，而不是执行存储I/O操作任务。
例如，下面的表函数查询显示了I/O等待时间与服务器处理时间及应用思考时间的百分比：
这个查询对上面的查询进行了扩展，在开展计算时将客户端闲置等待时间包含在内。
在这个示例中，预计通过升级到FlashSystem可以实现的端到端改进程度是：
98（ImprovementofFlashSystemresponsetimeforeachstorageI/Orequest）
x3.88%（storageI/OwaitpercentageforeachDB2requestincludingclientwaittime）
=3.80%（Overallprojectedperformanceimprovement）
因此，我们预计如果通过闪速存储系统来替换传统的HDD存储系统，将能够实现3.80%的性能改进。
4.9 可以迁移到闪速存储系统的组件
在您确定系统遇到了I/O子系统问题之后，接下来应该决定哪些DB2数据库组件I/O最高，从而找到造成I/O等待时间过长的根源。
您应评估下面几个数据库组件：
◆ 整个数据库
有些数据库的文件可以悉数迁移到闪速存储系统中。
这些数据库至少具备以下特征之一：
➢ 并发存取程度高：
当数据索引页面不在缓冲池中时，每条用户连接至少会通过一个代理从磁盘中读取数据。
当多个并发的引擎可调度单元（EDU）同时从磁盘读取数据时，您将能够大大受益于闪速存储系统。
➢ 随机存取表：
闪速存储系统擅长处理内含可以随机检索或更新的记录的表格。
➢ 中小型数据库：
鉴于购买RAID系统的相关固定成本极高，因此，购买闪速存储系统更具经济性。
例如，FlashSystem710可通
升级会员 