Ceph分布式存储在扩展性、可靠性、性能上具备独特的优势，可以实现快速扩展多台服务器，动态伸缩到PB级容量，多副本机制保障数据高可靠，数据均衡分布，并发性能高等场景。目前广泛应用于互联网、科研、教育、制造业、政府等诸多领域。ZStack云平台目前支持对接Ceph分布式存储，使用的是分布式块存储，即使用librbd的块设备接口提供给Qemu访问，进行云主机、云盘的IO读写。

虽然Ceph分布式存储具备上述的优势特点，但在实践中，对硬件的选择及配置均存在特别要求，尤其是硬盘、网络上，如果配置不当，存储的可靠性和性能均会受到影响。
最近在日常巡检一套ZStack生产环境的Ceph分布式存储时，我们发现客户新购的五台服务器的SSD寿命损耗存在异常。具体的现象是使用半年后，服务器带外管理界面看到SSD的寿命损耗只剩下89%，但使用smartctl读取介质损耗参数依然显示为100%。

此时会很疑惑，到底哪个数据更可靠，如果SSD寿命只剩下89%，那么如何去调整优化Ceph分布式存储？

问题回顾

针对这个问题，我们回顾一下这套分布式存储的架构。当时采用了新购+利旧的方案来部署分布式存储。

相应的配置信息如下：

其中，新购的5台机器采用了Intel Xeon E5-2660 v4的CPU，内存为256G，机器整体可插入8块3.5寸硬盘，采用了两块480G SSD硬盘配置RAID1安装系统，采用一块960G SSD做Ceph分布式存储的缓存盘，每个缓存盘对应了5个OSD数据盘，每个缓存分区约160G的容量，每个OSD容量4T。存储采用万兆网络，做链路聚合 LACP Mode 4。

利旧的4台机器采用了Intel Xeon E5-2697 V3的CPU，内存为256G，机器整体可以插入可插入8块2.5寸硬盘，采用了两块480G SSD硬盘配置RAID1安装系统，采用两块480G SSD做Ceph分布式存储的缓存盘，每个缓存盘对应了2个OSD数据盘，每个缓存分区约240G容量，每个OSD容量600G。存储采用万兆网络，做链路聚合 LACP Mode 4。

前五台机器，每台机器配置5块4T硬盘容量，总存储容量100T，后4台，每台机器4块600G容量，总量9.6T。

初期将所有容量规划到同一个存储池中，总裸容量约109T，配置三副本后，容量约36T。

环境主要运行了MySQL，Redis，ELK，Zabbix，Web服务，App服务等业务，合计业务类型主要偏向IOPS密集型业务。业务运行前两个月，整体系统没有任何问题。

SSD寿命参数分析诊断

针对SSD寿命损耗的不一致性，参考SSD的寿命参数，我们进行了以下分析：

Endurance Rating (Lifetime Writes)： 生命周期内总写入容量，客户环境使用的960G SSD生命周期内总写入量为1.86 PBW，即较多可写入1.86PB的数据。

DWPD：Device Writes Per Day，硬盘每天写入次数，全盘写入，写满算一次，用于评估硬盘的耐久度。此款960G SSD的官网标称耐久度为1 DWPD，即每天可全盘写入一次。

所以从SSD生命周期总写入量的角度来看，服务器带外管理界面看到的寿命损耗更为合理一些。
结合此硬盘的生命周期总写入量和每天可擦写一次，可了解此硬盘在1.86PB/960G/每天=1860000B/960G=1937天，约5年多的使用时间，与厂商承诺的5年质保的时间一致。

在使用ZStack云平台的IO监控工具及smartctl工具去排查分析960G SSD硬盘的每天写入量，发现每天硬盘的写入量在2.5T以上，接近SSD硬盘容量960G的三倍。
同时分析后4台服务器的SSD缓存盘的硬盘写入量很少，相应的硬盘总寿命未受过多影响。

测试发现，前五台服务器的SSD，IOPS 95%都在3000以上，读写比在15:85，平均读IO块大小为16K左右，写IO块大小为18K左右。而针对前五台服务器的OSD数据盘，IOPS 95%在30左右，读写比为86:14，平均读IO块大小为30K左右，写IO块大小为180K左右。

所以前五台物理机的SSD缓存盘每天写入量接近官网标称值的三倍，按照生命周期总写入量的损耗预估，前五台服务器的SSD缓存盘寿命可能不到两年。

但后面4台服务器SSD的使用率为何没有提上去，对前五台服务器的SSD进行均衡使用呢。

我们再来了解一下Ceph数据分布的基本原理。Ceph的CRUSH MAP算法，可以实现数据能够均匀地分布在不同容量硬盘的存储节点，Ceph会根据OSD数据盘容量进行权重的计算，并基于存储集群的映射和数据分布策略的placement rules进行哈希计算。同一存储池中，OSD数据盘容量大的，IO请求多，OSD数据盘容量小的，IO请求少。IO请求经由数据的哈希到PG的映射过程，再由PG根据副本数映射到不同的OSD中。如果OSD硬盘不同，那么容量大的硬盘可以处理更多的PG。相应的IO处理就更多。根据相应的IO均衡策略，如果存储池内总容量109T，使用30%的容量，则会在所有的数据盘均平均存储30%的容量，相对于前五台节点采用的4T的数据盘，每个盘存储约1.2T的数据，后四台采用的600G的数据盘，每个盘存储约180G的数据。

所以基于这种硬盘容量的不均衡，导致相应的IO请求也会不均衡，在业务压力大时，后4台机器无法均衡处理整体的IO请求，在分布式规划时，需配置各机器的硬盘配置、网络配置一致。

分布式存储优化方案

针对以上情况，考虑进行以下调整：

检查当前业务使用情况，调整业务的使用方式，将部分非重要业务关闭，降低IO的使用方式，调整后，再监控相应IO的使用情况，发现960G SSD的每天写入量已降低至1.8T，此时业务已无法持续调整。

在业务无法调整的情况下，只能考虑扩容及硬盘调整，在考虑扩容的过程中，还需要考虑后续业务量的增长。

因为当前的存储容量，可以提供当前业务的存储量，但在缓存盘性能上，不足以支撑相应业务的需求，此款960G SSD的每天硬盘写入次数DWPD为1，只能全盘刷入一遍。考虑到硬盘的每天写入量，建议新缓存盘采用新款的960GB SSD，官网的标称值其在生命周期的总写入量在为5.26PBW，每天硬盘的写入量为3DWPD，即每天可擦写三遍。

基于可靠与经济的基本原则，我们考虑以下硬件扩容方案进行扩容：

1. 再新增3台服务器，采用总写入量更高的960GB SSD，480G SSD系统盘，其他配置与原本前五台配置相同；

2. 前五台服务器，也采用总写入量更高的960GB SSD替换原本的960GB SSD，将前五台机器扩容成8台相同配置的机器；

3. 后4台服务器，将缓存盘替换成步骤二移除下来的960GB SSD，此时每台机器可以插入5块数据盘；

4. 后4台服务器，将原本的2.5寸 600G SAS硬盘，变更为2.4T企业版SAS硬盘，目前2.5寸企业级硬盘较大容量受限于2.4T；

5. 存储规划，8台E5-2660的服务器提供5x4Tx8的存储容量，约160T。后4台服务器提供5X2.4Tx4的存储容量，约48T。

6. 前8台单独一个存储池，后4台单独一个存储池，均配置三副本。

具体的调整方案步骤，可参考以下步骤：

1. 从存储池，移除后4台服务器的硬盘，并关闭这4台机器；

2. 在新购入的三台服务器上，安装部署Ceph存储节点，加入到分布式存储集群的存储池中；

3. 将原本的前五台机器的一台服务器，移除硬盘，移除服务器，等待Ceph存储数据平衡恢复；

4. Ceph平衡完毕后，关闭此服务器，将其上的960G SSD变更为耐久度更高的960G SSD；

5. 重复步骤3-4，完成前五台机器的变更；

6. 变更后4台服务器的硬件，将前五台机器中原本的960G SSD各分配一块到后4台服务器，将每台机器上的600G SAS硬盘更换成5块2.4T的SATA硬盘，添加到Ceph存储，针对这些2.4T硬盘，单独规划一个Ceph存储池；

7. 添加步骤6创建的新存储池到ZStack的Ceph主存储作为数据云盘池，创建数据云盘时使用，在业务使用时，可将部分业务，部署在后4台机器的存储池中；

8. 添加新购入的三台服务器到ZStack的计算节点集群中，同时用于提供计算资源。

使用上述方案变更，可以解决当前业务场景下，针对原本前5台服务器的每天硬盘写入量3遍，导致SSD寿命加速衰减的情况，又新增了三台服务器进行了计算存储的超融合扩容。针对Ceph容量存储IO请求不均衡的场景，也使用单独的存储池，进行规划，相同容量的硬盘规划到同一存储池，可以实现IO请求的均衡，IO数据的均衡，各SSD的使用也相对均衡，即8台服务器的使用损耗一致，后4台服务器的使用损耗也一致。

结语

综上所述，分布式存储在规划部署时，需要考虑以下方面：

1. 同一存储池的硬盘型号容量应一致，否则不同容量的硬盘在同一存储池，会导致IO请求的不均衡，导致存储分布不均衡，在使用SSD缓存盘的场景会导致使用大容量硬盘对应的SSD IO请求更多，损耗会更快；

2. 业务规划需提前做好评估，针对IOPS，带宽写入进行提前规划，高IO的业务需进行评估，准备的硬件是否可满足业务需求，如果业务需求较高，需使用更高配置硬件或进行相应的硬件扩容；

3. 分布式存储选择SSD时，建议关注SSD的PBW(生命周期总写入量)和DWPD(每天硬盘可写入量)，SSD寿命的损耗与其总写入量需要规划考虑业务类型，IO密集型业务应选择更高DWPD的SSD。