ceph的设计支持异构硬件，即不绑定底层物理设备，所以可以混用回收的现存硬件来降低成本，但是通过本次测试华为存储，发现事实并非如此，硬件存在很明显的木桶原理，即最差的硬件设备会成为整个集群的短板，影响性能

具体对比测试场景如下：

硬件差异及性能差异：

• storage4：新换4T希捷SATA盘*22

• storage5：新换4T希捷SATA盘*22

• storage6：旧的4T日立SATA盘*22

经过fio同时4KB随机写压测22块硬盘，storage6的整体IOPS在9500 左右，而其他两台设备的IOPS在10300左右，大概7.8%左右的差距

测试用例：

1.storage4、storage5组合2副本、2节点的ceph集群

通过12台openstack虚拟机，4KB随机写1TB文件压测，整体的IOPS在1.5W-3.0W之间波动，数据很好看

2.storage5、storage6组合2副本、2节点的ceph集群

通过12台openstack虚拟机，4KB随机写1TB文件压测，整体的IOPS在1200-4500之间波动，ceph有明显的request block，通过"ceph osd perf"查看性能，发现storage6上的所有OSD的延迟在1100左右，出现高IOPS的时候，storage5的磁盘负载很明显上来了

集群的搭建并非我们生产的配置，但从现象来看，性能差的设备似乎严重影响了IOPS的数据，具体原因还需要深入分析ceph落盘与数据同步原理，也给我们换盘、硬件策略提供参考

可能原因分析：

由于ceph写操作的设计是偏强一致性，2节点2副本的设置，要求master OSD写完数据，并且replicate OSD也反馈写成功时才真正标记这个写操作成功了。ceph的数据分布也是伪随机的，所以这样的大并发下，数据是均匀分布在两个节点，所以storage6落盘慢，所有压力堆积在这里，而storage5会饿死。所以2节点2副本（min_size=2）的block现象比3节点3副本（min_size=2）更严重，毕竟如果数据分布在storage4、storage5会更快完成写操作，而ceph本身的设计并不会针对落盘的快慢反馈重新计算落盘的位置