ceph 代码分析读_几个 Ceph 性能优化的新方法和思路

最新推荐文章于 2024-06-19 09:41:35 发布

方仁野

最新推荐文章于 2024-06-19 09:41:35 发布

阅读量425

点赞数

文章标签： ceph 代码分析读

本文链接：https://blog.csdn.net/weixin_36475420/article/details/112373671

版权

一周前，由 Intel 与 Redhat 在10月18日联合举办了 Shanghai Ceph Day。在这次会议上，多位专家做了十几场非常精彩的演讲。本文就这些演讲中提到的 Ceph性能优化方面的知识和方法，试着就自己的理解做个总结。

0. 常规的 Ceph 性能优化方法

(1). 硬件层面

(2). 软件层面

Linux OS：MTU、read_ahead 等
Ceph Configurations 和 PG Number 调整：使用 PG 计算公式(Total PGs = (Total_number_of_OSD * 100) / max_replication_count)计算。
CRUSH Map

更多信息，可以参考下面的文章(请自行搜索)：

显然这不是一个 Ceph 的新特性，在会议上有这方面的专家详细地介绍了该特性的原理及用法，以及与纠错码方式结合的细节。

简单概括：

每一个缓存层次(tiered cache)使用一个 RADOS pool，其中 cache pool 必须是拷贝(replicated)类型，而 backing pool 可以是拷贝类型也可以是纠错码类型。
在不同的缓存层次，使用不同的硬件介质，cache pool 使用的介质必须比 backing pool 使用的介质速度快：比如，在 backing pool 使用一般的存储介质，比如常规的HDD或者 SATA SDD；在 cache pool 使用快速介质，比如 PCIe SDD。
每一个 tiered cache 使用自己的 CRUSH rules，使得数据会被写入到指定的不同存储介质。
librados 内在支持 tiered cache，大多数情况下它会知道客户端数据需要被放到哪一层，因此不需要在 RDB，CephFS，RGW 客户端上做改动。
OSD 独立地处理数据在两个层次之间的流动：promotion(HDD->SDD)和 eviction(SDD -> HDD)，但是，这种数据流动是代价昂贵(expensive)和耗时的(take long time to “warm up”)。

在 Ceph 集群中，往往使用 SSD 来作为 Journal(日志)和 Caching(缓存)介质，来提高集群的性能。下图中，使用 SSD 作为 Journal 的集群比全 HDD

关注