日安,
对不起,我的英语不是我的母语,最近我的分析性写作练习不足。
我有一个ESXi 6.0.0更新2安装在一个裸金属HP Proliant服务器上。它的操作足够好与两个外部硬盘外壳,通过两个P411 RAID控制器连接。最重要的是,服务器内部的2.5“槽中,有一些是由HP的集成P410 RAID控制器(是的,我知道这很糟糕)服务的SSD (其中几个)。所有HDD和SSD根据其大小和RPM被分成几个数据存储区,所有数据存储被配置为RAID10。
自然有几个VM,每天输入大量生产数据,突然就有了一个备份解决方案,利用安装了适当软件的专用VM,还有一个运行在廉价的8 SATA 5400 RPM上的专用数据存储,每个驱动3TB,从而使第一层现场备份的可用12 3TB总计。
还有/有第二层现场备份,即对位于外部电源外壳中的4TB ST4000NM0055执行的最关键VM的备份副本,通过PCIpass身PCI-USB3.1卡连接到备份VM。
最近,PCI-USB3.1卡失败了(它不是VMWare批准的,但工作了一年左右),我决定将备份副本移动到一个更稳定和更安全的路径上。这是通过利用现有的未占用的SATA端口来完成的,该端口直接位于HP服务器的主板上。SATA端口是供电的,它被记录为SATA,似乎通过另一个控制器工作,与上述P410和P411s无关。
因此,我获得了适当的电缆和连接的希捷ST8000NM0055到SATA端口。在通过7TB的瘦配置数据存储将新驱动器连接到备份VM之后,我注意到文件移动性能还有很多需要改进的地方:从旧USB3.0驱动器开始的备份移动速度为70-80 80MBps(每秒7TB),但在10到15分钟内下降到10 80MBps,并在该级别上停留数小时。3TB文件移动操作的结束预计将在80至90小时内开始。
我假设为瘦配置的VMDK进行的大规模文件移动和底层磁盘空间分配基本上是对同一个数据卷的2个繁重操作,所以这可能是数据传输速率如此之低的原因。为了加速这一过程,我决定将瘦配置的VMDK从当时的300 at提高到目标7TB。因此,我关闭了备份VM,并在VMWare vCenter操作web接口中右击充气。
这件事发生在6天前开车还在膨胀..。服务器没有受到任何沉重的CPU或磁盘负载,它的利用率在15 %到25%之间的各种容量。所以我认为这一次是超乎寻常的,但是我别无选择,只能等待,好像取消了我就会失去已经转移了300 So的不重要但感伤的数据。
在检查每天的情况时,我注意到不仅写IOPS相当低,而且在运行3-4天之后,它们突然增加了近两倍。使用该媒体进行的唯一操作是磁盘膨胀。
在ESXi主机设置中,很少发现和尝试过开关数据存储硬件接入法,即: DataMover.HardwareAcceleratedInit从1到0- DataMover.HardwareAcceleratedMove从1到0,硬件加速锁定从1到0,它们对SATA或SAS数据存储没有影响。
我错过了什么才能在这个驱动器上有好的表现?从家庭个人电脑的经验,我预计它有至少100 hours的操作容易,所以充分膨胀应该需要20个小时,而不是多达180小时,我们目前的目标。
发布于 2019-02-26 19:56:48
性能如此糟糕的原因是默认设置为禁用的HP BIOS驱动器写缓存。
在更改到已启用(显然是这里需要的动力周期)之后,性能从这个Enterprise模型恢复到正常状态。
https://serverfault.com/questions/955327
复制相似问题