提高 CEPH 集群 IOPS 的最佳实践是什么？答案

【问题标题】：What's the best practice of improving IOPS of a CEPH cluster?提高 CEPH 集群 IOPS 的最佳实践是什么？
【发布时间】：2020-06-30 11:02:06
【问题描述】：

我目前正在为一个 KVM 平台构建一个 CEPH 集群，该集群现在产生了灾难性的性能结果。这个数字很可怕。我对物理分布式系统不是很熟悉，是否有任何提高整体性能（即延迟、带宽和 IOPS）的一般建议？

硬件配置目前还不是最理想的，但我仍然想释放我目前所拥有的全部潜力：

1x 10Gbe 华为交换机

3x 机架服务器，带硬件配置：

Intel(R) Xeon(R) CPU E5-2678 v3 @ 2.50GHz x2, totally 48 logical cores, 

128GB DDR3 RAM

Intel 1.84T NVMe SSD x6 as data drive, with 1 OSD per disk (totally 6 OSDs per server)

我现在的/etc/ceph/ceph.conf：

[global]
fsid = f2d6d3a7-0e61-4768-b3f5-b19dd2d8b657
mon initial members = ceph-node1, ceph-node2, ceph-node3
mon allow pool delete = true
mon host = 192.168.16.1, 192.168.16.2, 192.168.16.3
public network = 192.168.16.0/24
cluster network = 192.168.16.0/24
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
osd pool default size = 3
osd pool default min size = 1
osd pool default pg num = 600
osd pool default pgp num = 600
osd memory target = 4294967296
max open files = 131072

[mon]
mon clock drift allowed = 1
mon osd min down reporters = 13
mon osd down out interval = 600

[OSD]
osd journal size = 20000
osd max write size = 512
osd client message size cap = 2147483648
osd deep scrub stride = 131072
osd op threads = 16
osd disk threads = 4
osd map cache size = 1024
osd map cache bl size = 128
osd recovery op priority = 2
osd recovery max active = 10
osd max backfills = 4
osd min pg log entries = 30000
osd max pg log entries = 100000
osd mon heartbeat interval = 40
ms dispatch throttle bytes = 1048576000
objecter inflight ops = 819200
osd op log threshold = 50
osd crush chooseleaf type = 0
journal max write bytes = 1073714824
journal max write entries = 10000
journal queue max ops = 50000
journal queue max bytes = 10485760000

[Client]
rbd cache = True
rbd cache size = 335544320
rbd cache max dirty = 134217728
rbd cache max dirty age = 30
rbd cache writethrough until flush = False
rbd cache max dirty object = 2
rbd cache target dirty = 235544320

IO 基准测试由fio 完成，配置如下： fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/data/testfile -name="CEPH Test" -iodepth=8 -runtime=30

基准测试结果截图： The bench mark result

基准测试是在一台单独的机器上完成的，配置为通过 10Gbe 交换机连接集群，仅安装 MDS。基准机器与构成集群的其他 3 台机器相同，只是没有英特尔 NVMe SSD 驱动器。

感谢您的帮助，

【问题讨论】：

这不是 openstack 问题。 Openstack（至多）仅在外围参与了性能问题的任何潜在原因。

标签： ceph

【解决方案1】：

我假设您 3 是指 3 个刀片服务器，而不是 3 个机架。

您对性能的粗略估计是多少？ 4K 和 2MB 的磁盘硬件（ceph 之外）的性能概况如何？您在这个池中有多少磁盘，复制因子/策略和对象大小是多少？

在客户端，您正在执行小型读取：4K 在服务器端，根据您的预读设置和对象大小，每个 4K 可能会在后台获取更多数据。

您是否检查过您的某个磁盘确实处于其极限并且没有网络/cpu 限制？

【讨论】：

【解决方案2】：

首先，我必须注意，Ceph 不是首字母缩写词，它是 Cephalopod 的缩写，因为有触手。

也就是说，ceph.conf 中有许多让我吃惊的设置，比如你正在缓存的 osdmap 数量之多。线程设置可能很棘手，并且版本之间的适用性不同。如果您要构建的池有 600 个不是很好的 PG，您通常需要 2 的幂，并以每个 OSD 的比率为目标，该比率会考虑驱动器类型和其他池。将 mon 时钟偏差设置为一整秒（相对于默认的 50 毫秒）非常令人担忧，使用 Chrony 甚至是旧版 ntpd 实现亚毫秒级同步并不难。

三个节点可能会限制客户端可以支持的并行度/重叠程度，尤其是因为每台服务器只有 6 个驱动器。那只有 18 个 OSD。

你也有 Filestore 设置，你不是真的在使用 Filestore 是吗？还是比 Nautilus 更早的 Ceph 版本？

最后，作为对所提出问题的更多实际答案，您可以做的一件简单的事情是将每个 NVMe 驱动器拆分为两个 OSD — 为池设置适当的 pgp_num 和 pg_num。

ceph-volume lvm batch –osds-per-device 2

【讨论】：