基本上，我必须查看存储的主要原因是将监视虚拟机从主机的本地磁盘转移到存储。 因此，在进行任何迁移之前，我使用iometer安装了一个新VM，并在夜间运行testing，此时集群中没有运行重要的作业。 从这个虚拟机只有1个发电机工作者线程。
Access Specification Name IOps Read IOps Write IOps MBps Read MBps Write MBps Transactions per Second Average Response Time Average Read Response Time 512B; 100% Read; 0% random 5617.191059 5617.191059 0.000000 2.742769 2.742769 0.000000 5617.191059 0.176979 0.176979 512B; 75% Read; 0% random 3190.524306 2369.761725 820.762581 1.557873 1.157110 0.400763 3190.524306 0.312244 0.321925 512B; 50% Read; 0% random 1055.807449 524.819993 530.987456 0.515531 0.256260 0.259271 1055.807449 0.946000 0.421600 512B; 25% Read; 0% random 1006.956966 239.414257 767.542709 0.491678 0.116901 0.374777 1006.956966 0.853556 0.687116 512B; 0% Read; 0% random 35.123065 0.000000 35.123065 0.017150 0.000000 0.017150 35.123065 28.349538 0.000000 4K; 75% Read; 0% random 3034.296095 2247.847150 786.448945 11.852719 8.780653 3.072066 3034.296095 0.328614 0.333793 4K; 25% Read; 0% random 2237.793260 587.671309 1650.121951 8.741380 2.295591 6.445789 2237.793260 0.445755 0.636275 16K; 75% Read; 0% random 627.852712 474.796322 153.056389 9.810199 7.418693 2.391506 627.852712 1.591288 1.840213 16K; 25% Read; 0% random 478.619741 116.666329 361.953412 7.478433 1.822911 5.655522 478.619741 2.086953 1.281547 32K; 75% Read; 0% random 848.266506 649.372846 198.893660 26.508328 20.292901 6.215427 848.266506 1.176316 1.334378 32K; 25% Read; 0% random 443.441341 117.275291 326.166050 13.857542 3.664853 10.192689 443.441341 2.253707 7.158792 hdparm读取testing（用hdparm -t / dev / sda）给了300MB / s。
我们的监控系统从+ – 40个虚拟机和30个设备获取信息，每个主机至less有10个服务，但实际上这是产生大部分IOPS的cacti。 它每分钟同时大量更新RRD数据。 尽pipe如此，我决定将虚拟机迁移到存储。 迁移之后，我测量了由监视产生的IOPS – 平均值为800，但是在每个虚拟机上进行任何读取操作之后的响应时间是可怕的–5-10秒 ，监视实际上杀死了一些虚拟机，因为内核超时IO操作。 hdparm给了1,4MB /秒。 我closures了cacti RRD处理，运行良好，但我们没有图表。
我的问题：
1）您对这个设置的iometer性能有什么看法？ 它应该更好，没关系，或者我应该search一些错误configuration？
2）您是否build议使用独立的物理主机与监控软件，并且不要使用这种IOPS来“打扰”存储？
3）这个问题更一般。 存储testing后，我们可以获得不同块大小的IOPS / mbps。 但是，我怎样才能评估一个应用程序主要使用的块大小呢？ 例如，数据库系统通常使用75％的读取操作，但块大小是多less，以便将其与我的结果进行比较？ 不知道这些信息，我的iometertesting只是数字。
更新1：谢谢你的答案。
那么我们做了什么，就是我们为rrd处理创build了ramdisk，并且所有的rrds每小时同步到监视磁盘。 一切工作都很快，但是我们会考虑为这种需要良好写入性能的IOPS创build另一个RAID 10 RAID组。
所描述的设置并不像它可能的那样快。 这是一个受支持的安排，因为您最多可以连接四台主机（如果您放弃SAS多path）。
你的观点：
性能不好，但适合你的configuration。 我将参考服务器故障规范RAID后 ，基本上说，RAID 6是穷人的随机写入工作负载。 虚拟机和监控系统因这种访问模式而臭名昭着。 如果可能，RAID 1 + 0是更好的select。
我虚拟化了我的监控主机，但是构build存储以适应这种情况（偏向于更大的写入caching，在VM中设置适当的I / O升降机选项）。 这是其他基于RRD的工具（ orca和OpenNMS ），但肯定适用于Cacti。
就testing而言，我不认为跟踪平均交易量/区块大小是非常重要的，因为更大的架构问题可以带来更大的收益。 但是，您可以跟踪应用程序。 另外，考虑通过vCenter或esxtop / resxtop检查VM存储性能。
我会诚实地说，虽然我确信这种设置是受支持的，但我从来没有见过> 2主机直接连接SAS VMWare集群。 我知道它适用于2个主机，但3个或更多使用此方法的专业知识范围之外。
也就是说你的数据对我来说看起来不错，最终你在R6arrays中有一些非常慢的磁盘，所以有多快的速度是有限制的，443 IOPS在那里或者是我所期望的那种性能。
至于你的第二个问题，如果负载不好，那么你可以考虑在R1000上用一对专用磁盘在P2000上创build另一个逻辑磁盘，然后把虚拟机放在那个虚拟机上，或者也可以把它移动到本地DAS vMotion / DRS / HAfunction。
第三个问题 – 也许iotop？