​ ​​ ​

​ ​

​转载请在文首保留原文出处：​​EMC​​中文支持论坛​​https://community.emc.com/go/chinese​

​ ​​ ​

​ ​

​ 本文整理了专家问答“​​Symmetrix​​的性能监控和分析”精华问题。原问答贴地址：​​【专家问答第十期】Symmetrix的性能监控和分析​

​ ​​ ​

​ ​

​问题​​1​​：对于​​Symmetrix​​的性能监控和分析，通常我们会使用什么工具？ ​

​ ​

​ ​

​回答：​​一般监控​​ Symmetrix​​的性能，我们常用的工具有​​Symmetrix Performance Analyzer ​​以及​​ Performance Manager​​。​

​ ​

​ ​

​ Symmetrix Performance Analyzer ​​和​​Symmetrix Management Console ​​（​​SMC​​） 相连，用来监控 ​​Symmetrix​​的历史状态，可以对数据进行长时间的归档，通过不同的图表来监控不同的状态信息。要安装​​Symmetrix performance analyzer​​（​​SPA​​）​​, ​​必须先安装​​Symmetrix Management Console​​（​​SMC​​），需要再添加​​SPA​​的​​license​​。​​SPA​​的安装包是包含在​​SMC​​里的。在​​SMC​​中可以添加​​SPA​​的​​license​​。可以根据​​Symmetrix​​的序列号（​​SID​​）来管理​​license​​。​

​ ​

​ ​

​1.​​平均值或最大值的柱状图用来显示负载平衡的比较信息​

​ ​

​2.​​“​​Heat Map​​”热点柱状图用来显示热点部件所占的比例。通过不同的颜色来显示性能较差的部件所占的比例。​

​ ​

​3.​​长期和短期时间的针点型图表用来显示一个事件的发生时间​

​ ​

​4.​​趋势预测图用来预测长期的性能增长情况。​

​ ​

​ ​

​ Performance Manager​​是​​ControlCenter (ECC/Ionix)​​主要的性能分析工具， 可以显示历史图表信息，通过​​Managed Object​​来收集到以下部件的性能信息：​

​ ​

​1. Symmetrix​​、​​CLARiion​​、​​HDS​​、​​Celerra​​。​

​ ​

​2.​​主机。​

​ ​

​3.​​光纤通道的链接。​

​ ​

​4. Orcacle​​数据库。​

​ ​

​ ​

​ ​

​ Unisphere​​来管理​​VMAX​​的性能。在​​Unisphere​​中有一个专门的性能管理栏目。用户可以监控图表，对实时以及历史的性能信息进行分析，还可以设置告警， 报告等。​

​ ​

​监控：可以监控​​EMC​​预先设置的面板，用户也可以自行设置面板。所有的面板都会实时更新。​

​ ​

​分析功能：用户可以选择实时报告（一小时），​​7​​天报告，和长达​​36​​个月的历史报告信息。​

​ ​

​设置功能：用户可以注册​​Symmetrix​​阵列，设置阀值和告警，设置度量值和​​KPI​​，查看和管理报告以及实时跟踪（​​trace​​），和管理性能数据库等操作。​

​ ​

​ ​

​问题​​2​​：请问一下如何根据主机，存储，网络的配置去评估存储的读写性能有没达到要求呢？例如我与一台​​dmx4 ​​用的是​​15k​​的​​FC​​盘。​​8gb​​的​​san​​网络速率，主机用两个​​hba​​卡造成双通路。那我用​​dd​​做读写压力测试。应该达到什么速度才符合这个配置的速度水准呢？还有请问现今存储技术环境下，限制最高速度的瓶颈是什么环节呢？​

​ ​

​ ​

​回答：​​影响性能大致有三种情况：​

​ ​

​ ​

​1.​​不平衡的使用：对于物理硬盘的不平衡工作负载，或者是对​​Symmetrix​​前端口的不平衡负载。对于前一种情况，在后端可以通过​​Symmetrix Optimizer​​，或者是​​FAST​​等来实现磁盘的负载均衡，也可以通过在主机端进行​​striping​​，或者设置​​Meta Volume​​等。对于后一种情况，可以通过​​PowerPath​​软件等方法来帮助负载均衡。​

​ ​

​2.​​局限：​

​ ​

​1​​）物理局限：包括硬盘局限和端口局限等，可通过扩容等方法解决。​

​ ​

​2​​）微码局限：​​device write Pending ​​局限 和​​System Write Pending​​局限。可通过增加内存和设置​​MetaVolume​​来解决。​

​ ​

​3.​​不现实的性能期望：解决的方法是增加硬件设备，以及更好的理解需求和负载等。​

​ ​

​读写的速度由很多因素决定， 很难说有一个绝对的性能标准，可以通过您的配置来获得最大的读写性能，比如是否将物理硬盘分布在更多的后端​​DA​​端口，或者是否有更多的物理硬盘，以及不同的​​RAID​​保护类型等等，都可以优化​​Symmetrix​​的性能。​

​ ​

​例如您说的​​15k​​的​​FC​​盘的性能，就要取决于您的硬盘是否平均分配在了​​DMX-4​​的各个后端​​DA​​口，逻辑卷做了如何的​​STRIPE​​和​​RAID​​保护等等很多方面；而​​HBA​​的双通路所带来的性能，也要取决于您把这些​​HBA​​端口在​​Symmetrix​​前端​​FA​​端口的配置等。​

​ ​

​ ​

​ 总的来说，优化性能的配置方法就是，配置足够的资源，并且尽可能的让所有的资源能够均衡使用，另外就是不要把配置弄得过于复杂。​

​ ​

​首先，我始终建议客户使用自己的业务数据，模拟交易来进行压力测试，可惜能有这种测试环境的客户不多。那么，我们只能使用一些​​IO​​测试软件，来模拟客户的​​IO​​情况，​​Windows​​平台有​​IOMeter​​，​​Unix​​平台有​​IORate​​，都是免费软件，在网上可以下载。这些​​IO​​测试软件的好处是用户可以控制并发的进程数，指定​​IO​​的组成（即​​IO size, ​​读​​IO​​的比率、多大比例的随机​​IO​​等等）。​​dd​​的问题是只能产生顺序的​​IO​​，即使并发多个​​dd​​进程，并发数还是有限，无法模仿客户应用的​​IO​​情况。另外，性能是个综合指标，很多客户只看一个指标，有的客户很看重​​IOPS (IO per second)​​，有的客户很看重响应时间，其实这些指标都很重要，另外，还要综合考虑​​ IO Size​​，读写比例、随机​​/​​顺序比例等等，才能比较客观的评价一台存储的​​IO​​性能。由于​​ Symmetrix ​​结构比较复杂，低负载时单个​​IO​​的响应时间肯定不及一些结构简单的存储，因此​​dd​​的成绩也不会很好，但是在大量的、并发的​​IO​​情况下，​​Symmetrix ​​的性能才能充分发挥出来，因此，应该为适当的需求选择适当的存储。​

​ ​

​ ​

​ ​

​ 蓝军在​​dd​​大战中肯定能打败红军，如果总体​​IOPS​​的需求在​​20000​​以下，那么蓝军是个务实的选择，不一定非要红军不可。​​相似的道理，​​PC​​机上​​Windows​​的操作体验明显好于​​Unix​​上的​​GUI​​，也不能说明​​PC​​机的性能好于​​Unix Server​​。​

​ ​

​ ​

​问题​​3​​：​​Symmetrix DMX​​的​​hypervolume​​和​​VMAX​​的​​disk pool​​这些架构相对于中低端的产品有什么优势吗？​

​ ​

​ ​

​回答：​​前几代的​​Symmetrix​​一直使用​​Hypervolume​​，我想主要有几点考虑。​

​ ​

​ ​

​1.​​性能：把物理硬盘分成​​Hyper volume​​后，主机上可见的卷就可以更多，可以产生更多并发的​​IO​​。​

​ ​

​2.​​功能：可以在同样的物理硬盘上根据客户的需求使用不同的保护方式，镜像或​​Raid5​​等等，也方便扩展各种功能：容灾、克隆、快照等等。​

​ ​

​ Hyper Volume​​有一个特点就是要求用户的数据分布要比较均衡，这可以通过存储、操作系统或数据库层面做条带化来实现。如果数据分布不合理，就可能产生热点盘，无法充分发挥整个存储的性能。​

​ ​

​VMAX​​推出了​​FAST VP​​的技术，使用​​ Storage Pool​​，把机柜内的存储分层，一方面存储在同一层存储内部，存储可以自己更均衡地分布数据，另一方面，存储可以根据不同数据块的​​IO​​特性，把合适的数据放到合适的存储层上去，例如把经常读的数据放到闪存盘上，把归档的数据放到​​SATA​​盘上。​

​ ​

​ ​

​问题​​4​​：请教 ＶＭＡＸ系列使用Ｓｔｏｒａｇｅ　ｐｏｏｌ会不会出现需要把数据分布在更多硬盘上这样的性能建议呢？　还有，例如我的一个　ｖｍａｘ有５０个一样的硬盘，不可能把这５０块硬盘都做成一个​​Storage Pool ​​吧？​

​ ​

​ ​

​回答：​​从性能角度上来说，如果后台硬盘​​pool​​里的物理磁盘越多的话，前端绑定的逻辑​​lun​​上的数据就会自动平均的分散到各个磁盘上，那么就更容易避免热点盘，同时也有一定的潜在性能提升。当然，这样配置也会存在不同的应用共享相同的物理磁盘​​pool​​的情况。客户可以根据自己的需求来看，因为不同的应用分享一个​​pool​​可能会造成对后端硬盘资源的竞争，包括磁盘的容量竞争，可以根据一个应用，或者一组应用，或者​​FAST​​中的一个​​tier​​来设计​​pool​​。​

​ ​

​ ​

​问题​​5​​：如果对存储性能分析比较感兴趣，专家们有什么推荐读物或者技术资料介绍吗？​

​ ​

​ ​

​回答：​​做为自学，可以先在网上找一些有关性能分析的文章来看（建议找英文资料，系统性更好一些），其实性能分析需要的基本知识非常少，例如前面提到的​​IO​​类型，性能指标​​(​​主要是​​IOPS​​，​​Thoughput, Response time ​​等​​) ​​等等，然后具体产品的性能分析就要使用特殊的工具软件。 ​

​ ​

​每个厂家都会有一些性能分析的课程，如果工作确实需要，可以报名去学一下，这些课程在前面也会讲一些基本知识，然后再讲针对具体产品的工具软件的使用方法。 ​​EMC​​对外公开的资料很少，但是你可以找一找其它厂商的网站，例如服务器厂商或数据库厂商，都会找到一些很好的资料。再有，可以利用一些搜索引擎，例如，百度一下​​"DMX-4 Oracle"​​就可以得到一篇很好的文档。 个人觉得学习最好的办法就是办干办学，如果对这方面感兴趣，向自己的老板多申请这方面的工作来干，相信老板都愿意培养技术人员的。刚开始时有问题多问问有经验的人，干得多了自然就能积累经验了。​

​ ​

​ ​

​问题​​5​​：​​James Liu​​分享实际中工作性能分析步骤与总结​

​ ​

​ ​

​ 主机上的性能工具一般主要关注在​​CPU​​，内存，​​Paging (or Swap)​​，​​ IOPS​​，​​IO​​平均响应时间等等方面，对于​​IO​​平均响应时间，一般的主机并没有区分读​​IO​​和写​​IO​​。​

​ ​

​ 存储上专注于​​IO​​的监控，看得更细，从存储的角度讲，分析​​IO​​，至少要注意到以下几点：​

​ ​

​ ​

​1​​，读​​/​​写：​​“​​正确描述IO类型​​”一文中指出，由于​​Raid​​保护的关系，“写通常需要比读更多的资源”，这是对的，但是忽略了另一点，由于现代存储阵列都有缓存，写​​IO​​的响应时间往往比读​​IO​​的响应时间小。即使​​Cache​​算法再好，也无法避免​​Read Miss​​，因此，负载较轻时，​​Random Read​​的平均响应时间一般在几毫秒级，而写​​IO​​的响应时间一般在零点几毫秒级，随机读和写​​IO​​的响应时间往往相差十几倍。看到这里，大家应该明白案例一的原因了吧？​

​ ​

​另外，存储后端（即磁盘控制部分）对于写​​IO​​更容易做优化。​​Read hit​​的响应时间与​​write​​的响应时间差不多，都是在​​Cache​​中完成。我们重点看一下​​Read miss​​。大家都有网购的经历吧？我们拿快递公司来类比吧，那么读磁盘是收件，写磁盘是派送。这个收件​​(read miss)​​是要求快递公司立即响应的，因此我们一打电话要求快递公司收件，快递员就必须马上上门来取件。而派件（​​write​​）时，快递员可以在他空闲的时候派件，还可以把同一小区的快递都带上，把整个小区的货品一次派完，即存储后端在写磁盘时，会尽量把相邻磁道的数据集中在一起写入磁盘。​

​ ​

​ ​​2​​，随机​​/​​顺序​​IO​​：​​这一点在“​​正确描述IO类型​​”一文中写得很好，我这里要补充的是，一般​​OLTP​​系统的​​IO​​都是随机的小​​IO​​，而数据仓库、数据挖掘、备份​​/​​恢复、归档、流媒体等等应用的​​IO​​是大的顺序​​IO​​。​​OLTP​​系统要求的是​​IOPS​​，数据仓库等应用一般要求的是吞吐量（​​MB/s​​）。​

​ ​

​综合以上两点，随机读未命中（​​Random Read Miss​​）是所有​​IO​​的短板，是所有​​IO​​中响应时间最差的，而这正是闪存盘（​​SSD or Flash Drive​​）的用武之地，​

​ ​

​3,IO Size​​：​​“​​正确描述IO类型​​”一文中写到：“许多存储系统处理大​​I/O​​会更快速一些”。然而实际上正相反，几乎所有的存储处理小​​IO​​都会更快速一些。它这里漏了一个条件，结果产生了误导，应该写成“对于相同的数据量（​​MB​​），许多存储系统处理大​​I/O​​会更快速一些”。​

​ ​

​ ​​4​​，​​IO​​的并发度：​​前面的贴子中提到过，​​dd​​测试无法真正测出存储在实际工作中的性能表现，主要原因是​​dd​​无法产生足够多的并发​​IO​​。降低​​IO​​之间的依赖关系，提高​​IO​​的并发度，一直是现代计算机系统努力的目标。例如，现代的数据库系统在读写一个记录时，不会锁住整个表，而是仅仅锁住那条记录，这样其它的事务才可以同时并发地访问其它的记录。存储也是如此，在没有达到存储的性能瓶颈之前，并发数越多，存储可以完成的​​IOPS​​也越大。​

​ ​

​在实施同步容灾项目时，为了满足客户应用​​IOPS​​的需要，就要保证足够的并发度，可以通过增加光纤端口的数量，增加​​Volume​​数来增加并发度。实施同步容灾时，由于每个写​​IO​​都要写到容灾端，这个​​IO​​才算完成，因此每个写​​IO​​的响应时间都会加长，这个延时是无法避免的，是容灾必须要付出的代价。只要在客户要求的时间里，完成所有的​​IOPS​​，那么这个系统就是符合要求的。还是拿快递公司举例，无容灾的存储相当于负责上海本地业务的快递公司，实施同步容灾后的存储，相当于这个快递公司业务需要覆盖江浙沪。虽然每送一次送货的平均时间延长了，但是如果有足够多的快递员（相当于足够多的并发​​IO​​），还是可以在客户要求的时间内把货品及时送到的。​

​ ​

​ ​​5​​，​​Cache​​的情况：​​命中率对性能的影响不言自明，还有一点要注意的就是写​​Cache​​的容量，对于​​Symmetrix​​来说，就是​​Write Pending​​的数量，前面也讲过，​​Write Pending ​​就是主机写入存储缓存、存储还没有真正写入物理硬盘的数据。​​Symmetrix​​系统有一个​​Write Pending Limit​​，即缓存中最多可以容纳的数据量。如果存储达到​​Write Pending Limit​​，那么一方面会降低读命中率，一方面会使得存储后端无法从容地做写磁盘的优化，存储后端会忙于写磁盘，导致存储工作效率下降。就像快递公司需要派送的货品积压太多，就要爆仓了，还有货品源源不断地进来，为了尽快给新进的货品腾出空间，逼迫快递员随手拿起一件货品就跑去送货…… 因此，应该尽量使存储系统的​​Write pending​​数量维持在较低的水平，为了保证这一点，仅仅加大​​Cache​​容量是不够的，还要保证有足够的后端性能，就像仅仅加大快递公司的仓库是不行的，还要加快送货的速度。​

​ ​

​ ​

​ 首先，对于性能的要求完全取决于客户应用的需求。有的应用在​​IO​​响应时间在几十毫秒时还可以接受，而以前一个比较大的客户要求响应时间在几毫秒以内，有的应用要在一台​​DMX-4​​上加入​​100​​多块​​SSD​​才能满足它的要求。对响应时间要求越快，那么存储的繁忙程度就要越低才能达到要求。例如，要求响应时间在​​6​​毫秒以内，那么可能存储各部件的繁忙程度不能超过​​30%​​，如果要求响应时间在​​10​​毫秒，那么存储各部件繁忙程度可能可以达到​​50% ​​（注：这个数字只是举个例子，并不是实际数值）。​

​ ​

​ ​

​ ​​对于物理硬盘，目前公认的经验值是：​

​ ​

​ 10k FC​​盘​​ 15k FC​​盘​​ SATA​

​ ​

​MB/s 10MB/s 13MB/s 8MB/s​

​ ​

​IOPS: 100 150 50​

​ ​

​ ​

​ 需要注意的是，这些经验值都是一般情况下的平均值，而且是在不同​​IO​​情况下取最先达到的值，例如，在每分钟​​15000​​转的光纤盘上，小​​IO​​情况下，先达到​​150 IOPS​​，但这时的吞吐量可能远没有达到​​13MB/s​​。​​ ​​即使同一块硬盘，外圈磁道的性能可能是内圈磁道的两倍以上。​

​ ​

​ Symmetrix ​​内存的​​write pending​​应尽可能在​​50%​​以下，在​​IO​​高峰时短时间的超过​​50%​​影响不大。​

​ ​

​ DA​​的​​IOPS​​限制很难说，不同存储​​DA​​的性能不同，而且不同​​IO​​情况，​​DA​​能承受的​​IOPS​​也不同，我一般是看​​DA​​上的​​%busy​​，虽然有时​​DA​​达到​​90% busy ​​客户才会感觉有性能问题，但是正常工作时建议不要超过​​50%​​。​

​ ​

​ Device​​应该是指给主机访问的​​volume​​，由于涉及的情况比较复杂，例如​​Raid-1 ​​还是​​Raid-6​​，是否​​Meta volume​​，命中率等等，​​device​​没有一个限制或是建议值，由于​​IO​​最终会落到物理硬盘上，因此做性能规划时只会考虑物理硬盘是否满足性能要求，但是比较通用的建议是每个应用的各个​​device​​的​​IO​​量尽可能平衡，这样可以避免热点盘的产生。​

​ ​

​ ​

​ 在这里总结一下谈性能最重要的几个方面：​​在最开始我说过，谈性能要考虑多方面的因素，以前我发过一个微博：谈​​ IOPS ​​不谈​​ IO Size ​​就象数钱只数张数不看面额。（​​jamesliu​​ ​​的新浪微博​​http://weibo.com/lzyjames​​也许还要加一句，谈​​ IOPS ​​不谈响应时间就象谈工资只讲数字，不讲是月薪还是周薪。当然，还要考虑读​​/​​写的比例，顺序​​/​​随机的比例，平均值和峰值的要求等等​​....​​ ​​差点儿忘了说最基本的一点，在检查性能之前，一定要先检查整个系统是否兼容，是否健康，有时候，困扰所有人几个月的莫名其妙的问题可能仅仅是因为一根没有插紧的光纤头。​

​ ​

​ ​​ ​

​ ​

​Symmetrix​

​ ​

​ ​