我所看到的下一代社交网络

1. 概况

1.1.  测试目标

1.1.1. 测试在RBD方案和libvirt方案下使用CEPH的性能表现情况

1.1.2. 比较两种方案，哪种方案更加适合现阶段的使用

1.1.3. 测试多种运维场景下的性能表现，对后期线上运维工作做预期

1.2. 测试内容

1.2.1. 在基准测试范畴，osd数量正常情况，分别通过RBD方案和libvirt方案测试连续读写和随机读写性能。

1.2.2. 在基准测试范畴，osd异常情况下，分别通过RBD方案和libvirt方案测试连续读写和随机读写性能。

1.2.3. 在基准测试范畴，在调整crushmap的情况下，分别通过RBD方案和libvirt方案测试连续读写和随机读写性能。

1.2.4. 在基准测试范畴，monitor异常的情况下，分别通过RBD方案和libvirt方案测试连续读写和随机读写性能。

1.2.5. 增加OSD的情况下，分别通过RBD方案和libvirt方案测试连续读写和随机读写性能。

1.3. 测试要求

1.3.1 保证测试数据真实性、完整性与准确性

1.3.1 保证测试环境一致性，需标明可能导致性能差异的各种因素

1.3.3 测试人员必须提供原始数据备查

1.3.4 测试人员必须遵守保密条款

2. 测试工具

1) fio-2.0.9

3. 测试方法与过程

3.1 测试的指标维度包括连续读写和随机读写

3.2 测试的场景

 基准情况（6个OSD全部正常）

 OSD异常情况

 crushmap刷新remap过程

 monitor异常

 增加OSD

3.3 测试的方案

 Libvirt方案

 RBD方案

4. 测试数据

4.1 基准情况数据

基准情况，OSD正常情况下，RBD模式和libvirt模式对比

-> 如果不开启kvm缓存的情况下，libvirt方案的性能和RBD方案的性能基本相当。

-> 在开启kvm缓存的情况下，libvirt方案的性能只是RBD方案的性能的20%左右。（现在怀疑libvirt方案下，kvm缓存开启没生效）

-> RBD方案下，kvm缓存开启跟关闭情况比较，读性能提升4倍（是后者的5倍），写性能提升3倍（是后者的四倍）

-> 两种方案读性能是写性能的四倍。

-> libvirt方案下，kvm缓存和ceph缓存感觉没生效，数据都没什么变化。

4.2 OSD异常情况

OSD异常情况下对比分析

-> osd被标记为down，但是还没被标记为out时，libvirt方案的性能为rbd方案的性能还稍微好点，同时两者跟正常情况的性能相比基本相当。

-> 当osd被标记为out，集群remap过程中，无论是RBD方案还是libvirt方案，性能都比之前下降很多。

4.3 Remap过程性能分析

Remap过程性能分析

-> 调整crushmap带来集群remap时，集群的读写性能都出现严重下降，只为之前集群的读写性能的10%

-> 调crushmap时，libvirt方案的读写性能比RBD方案表现要好些。

4.4 Monitor异常性能分析

Moniter异常性能分析，对比分析：

-> 对集群的读写性能没影响

4.5 OSD增加

在增加OSD的情况下对比分析：

-> 随着OSD的增加，集群相应的读写性能也增加。osd从6个增加到8个，读写性能10%,OSD从6个增加到10个，读写性能分别增加20%左右。

-> 读写性能增加的比例一般低于增加OSD的比例。

5. 测试分析结果

5.1 推荐RBD方案。

5.2 基准测试分析

 在KVM缓存关闭的情况下，从整体测试数据来看，libvirt方案和RBD方案的性能基本相当。

 在KVM缓存开启的情况下，libvirt方案的性能只是RDB方案的性能的20%左右。（现在怀疑livbirt方案下，kvm缓存开启没有成功，因为开启缓存和没开启缓存，libvirt的测试结果没什么变化）。

 RBD方案下，kvm缓存开启跟关闭情况比较，读性能提升4倍（是后者的5倍），写性能提升3倍（是后者的四倍）。

 两种方案读性能基本是写性能的四倍。

5.3 monitor异常对读写性能几乎没影响。

5.4 集群remap过程，读写性能下降较多，livbirt方案下，读写性能不足之前的30%。RBD方案暂时没数据。