Bendi新闻
>
Ceph:实现 1 TiB/s 性能实践

Ceph:实现 1 TiB/s 性能实践

8月前

 新钛云服已累计为您分享794篇技术干货





早在 2023 年,就有一家相当前沿的公司找到Clyso,希望将他们支持 HDD的Ceph集群过渡到10PB的NVMe集群。他们对此非常感兴趣。他们对RBD、RGW或CephFS没有特殊需求。同时,他们也有自己的硬件设计规范,但在实际购买之前,他们主动向我们寻求⼀些建议。他们的要求稍微略有不同。集群必须分布在 17 个机架上,每个机架有4U的可用空间。电源、冷却、密度和供应商等等都是影响因素。新节点需要在不中断服务的情况下迁移到现有的新集群中。然而,目前的网络已经建成,而且是⼀个比较大型的网络。这是我见过的速度最快的网络之一,在本次测试的环境中,不存在任何的网络瓶颈。我们也非常希望协助对方完成集群的建设。另外,在正式上生产之前,我们也需要进行充分的测试以及试运行。这对我们而言,这将是一个特别好的机会来在这样的一个物理环境下去充分优化 Ceph 集群。接下来的内容描述了我们如何构建和测试该集群,以及我们能够将其优化到何种程度。


集群配置







当客户第一次与 Clyso 接触时,他们提出了一种在17个机架上分布 34 个双插槽2U节点的配置。我们提供了多个供应商的几种备选配置,特点是配置相对小一些。最终,他们决定采用我们设计的基于戴尔的架构,该架构不但拥有几个比较关键的优势,同时报价也比原始配置便宜了大约13%。新配置的每个OSD的内存容量更小(每个OSD的内存容量仍为12GiB),但内存吞吐量更快。它还提供了更多的CPU资源、更大的网络总吞吐量、更简单的单插槽配置,并使用了最新一代的 AMD 处理器和DDR5内存。通过使用更小的节点,我们将节点故障对集群恢复的影响减小了一半。


客户表示,他们希望将每个机架的新增功耗限制在1000-1500瓦左右。如果每个机架有4个这样的节点,那么总TDP估计至少为1120瓦,再加上基本用电量、CPU超负荷峰值和低电源效率。虽然在负载情况下,我们可能会有点超负荷,但预计不会超出可接受的范围。如果情况更糟,我们估计通过降低处理器的CTDP,每个机架可以减少,大约100 瓦。

该系统的规格如下所示:


使用1U 戴尔服务器的另一个好处是,它们基本上是 David Galloway 和我们为上游 Ceph性能实验室设计的系统的更新换代产品。在过去的几年中,这些系统已经在各种文章中进行过测试。结果发现,在测试过程中出现了一个影响性能的重大问题,该问题并未影响上游实验室的上一代硬件,但却影响了这⼀新硬件。我们稍后会详细讨论这个问题。

在不涉及太多细节的情况下,我们想重申的是,客户的网络配置设计得非常好,速度也相当快。所有17个机架的总吞吐量足以让这么大规模的集群真正发挥其作用,从而无须考虑网络的瓶颈。


测试设置







为了进行机测试,部署了临时Ceph集群并使用CBT启动了FIO 测试。

我们同时对 CBT 进行了如下配置,以便在部署Ceph时修改默认配置。OSD被分配为8GB osd_memory_target 。在生产中,可以接受更高的osd_memory_target  配置参数。客户不需要测试块或 S3 工作负载,因此可能会认为 RADOS bench 是推荐的基准测试工具。

但是,根据我们的经验,使用 RADOS bench 进行大规模测试非常困 难。在给定线程数的情况下,很难确定需要多少实例才能使集群达到饱和。过去我们曾遇到过需要多个 并发池来扩展性能的问题。但我们手头也没有任何现有的RADOS基准测试可供比较。相反,我们选择使用与上游实验室相同的librbd支持 FIO 测试来进行测试。这样,我们就可以将集群划分为更小的块, 并将结果与之前公布的结果进行比较。FIO也是众所周知、值得信赖的⼀款存储性能测试软件。在 FIO中使用 librbd 引擎(与使用内核RBD的FIO相比)的一个主要好处是,不会出现挂载点超时可能需要重启系统的问题。我们没有 IPMI 访问该集群的权限,而且完成测试的时间很紧。因此,我们最 终跳过了内核 RBD 测试。不过,根据之前的测试结果,如果有足够的客户端,我们预计总体性能会大致相同。不过,我们还是测试了3X副本和6+2擦除编码。我们还使用以下Ceph选项在未加密和安全模式 下测试了 msgr V2:

ms_client_mode = securems_cluster_mode = securems_service_mode = securems_mon_client_mode = securems_mon_cluster_mode = securems_mon_service_mode = secure

OSD 允许使用节点上的所有 CPU 内核资源。FIO 被配置为首先使用大量写⼊预填充 RBD 卷,然后进行4MB 和 4KB IO 测试,每个测试持续 300 秒(调试运行期间为 60 秒)。禁用了某些后台进程,如刷新、深度刷新、PG自动扩展和 PG 平衡。



PG数量说明

在本文稍后部分,您将看到一些令人惊讶的 PG 数值测试。这是有意为之。我们从以前的上游实验室测试 中了解到,PG 数量会对性能产生巨大影响。其中部分原因是由于 PG 数量较低时随机分布的结果。这种 情况可以通过额外的平衡得到部分缓解。另外,较少的原因是 OSD 内部的 PG 锁争用问题。


我们观察到,在速度非常快的集群上,PG 锁争用会对整体性能产生重大影响。遗憾的是,在不增加 PG 数量的情况下,这种情况不太容易缓解。PG 数量到底有多重要?



只需 60 个 OSD,随机读取性能就可在使用 3X 的 RBD 池上扩展到 16384 个 PG。写入的峰值要早得 多,但仍可从高达 2048 个 PG 中获得较大的好处。


有一点很明确:我们不应该盲目地将生产的Ceph集群配置为使用像我们在这里测试的那样高的PG数量。当考虑到Ceph中对PG日志长度和PG统计更新等⼀些其他默认设置时候,这会显示的尤其重要。

不过,在此,我们确实想鼓励社区思考每个OSD100个PG是否仍有意义。

在控制开销和内存使用量的 同时,我们需要做些什么来提高每个OSD的PG数量。在未来,每个OSD拥有1000个PG并不是什么 稀罕事,PG日志会根据每个池自动缩放,而PG自动缩放则是⼀种较少使用的操作。


开 始







我们在感恩节后一周首次登录了新硬件。我们的计划是用一两周时间进行烧机验证测试,然后将新硬件 集成到现有集群中。如果一切按计划进行,我们希望能在新年前完成迁移。遗憾的是,我们一开始就遇 到了麻烦。最初的底层性能测试看起来不错。

Iperf网络测试表明,每个节点的速度略低于200Gb/s。对几个节点的随机抽样显示,NVMe硬盘的基线性能还算合理。我们很快发现的⼀个问题是,所有68个节点上的操作系统都地部署在2个OSD硬盘上,而不是内部的戴尔BOSSm.2 启动硬盘上。我们原计划将30个OSD 配置(3个节点,每个节点10个OSD)的结果与上游实验室的结果(5个节点,每个节点6个OSD)进行比较。但我们最终测试了每个节点8个NVMe 驱动器。即使减少了OSD 数量,第一批Ceph结果也远远低于我们的预期。




唯一可以接受的结果是随机读取,但仍然不是很好。显然,这里面有问题。我们停止了 3 节点测试,开始研究单节点甚至单 OSD 配置。 


就在这时,事情开始变得异常起来。


异常现象







当我们在集群中的单个节点上运行8-OSD 和 1-OSD 测试的不同组合时,我们看到了截然不同的行为, 但经过几天的测试,我们才真正了解了我们所看到的模式。最初在单OSD测试中表现良好的系统,在多 OSD 测试后不再表现良好,几个小时后才又开始正常工作。8-OSD 测试偶尔会出现性能良好的迹象,但 随后的所有测试都表现糟糕,直到系统重新启动。最终,我们发现了⼀种新启动模式,可以在集群的不 同节点上重复:


最初的单OSD测试在大型读取和写入方面表现出色,其吞吐量几乎与我们直接针对硬盘运行FIO测试时 看到的相同。然而,我们一开始运行8-OSD测试,就发现性能有所下降。随后的单OSD测试性能继续下降,直到几个小时后才恢复正常。只要不进行多OSD测试,性能就能保持较高水平。 


令人困惑的是,在直接针对硬盘运行FIO 测试时,我们无法调用相同的行为。同样令人困惑的是,在 8 OSD 测试中,单个 OSD 的 CPU 占用率明显高于其他 OSD:



4BM随机读取
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND511067 root 20 0 9360000 7.2g 33792 S 1180 3.8 15:24.32 ceph-osd515664 root 20 0 9357488 7.2g 34560 S 523.6 3.8 13:43.86 ceph-osd513323 root 20 0 9145820 6.4g 34560 S 460.0 3.4 13:01.12 ceph-osd514147 root 20 0 9026592 6.6g 33792 S 378.7 3.5 9:56.59 ceph-osd516488 root 20 0 9188244 6.8g 34560 S 378.4 3.6 10:29.23 ceph-osd518236 root 20 0 9390772 6.9g 33792 S 361.0 3.7 9:45.85 ceph-osd511779 root 20 0 8329696 6.1g 33024 S 331.1 3.3 10:07.18 ceph-osd516974 root 20 0 8984584 6.7g 34560 S 301.6 3.6 9:26.60 ceph-osd

OSD 在负载情况下的时间曲线显示,在 io_submit 阶段花费了大量时间,这就是我们通常看到的内核 因驱动器队列已满而开始阻塞的情况。



tp_osd_tp 线程 io_submit Wallclock 配置文件示例
+ 31.00% BlueStore::readv(boost::intrusive_ptr<ObjectStore::CollectionImpl>&,g... + 31.00% BlueStore::_do_readv(BlueStore::Collection*,boost::intrusive_ptr<Blu...  + 24.00% KernelDevice::aio_submit(IOContext*)  |+ 24.00% aio_queue_t::submit_batch(std::_List_iterator<aio_t>,std::_List_it...  | + 24.00% io_submit  | + 24.00% syscall


为什么运行8OSD测试会导致内核在以后的单OSD测试中开始阻塞 io_submit?这说不通。起初,我们 怀疑是节流。我们看到,在BIOS 中的默认冷却配置文件下,CPU上的几个核心复合温度高达96摄氏度。我们推测,可能是在8-OSD测试过程中,CPUNVMe驱动器达到了热极限。这可能会使系统在一段时间内处于降级状态,然后才能恢复。遗憾的是,这⼀理论并未得到证实。AMD/Dell 确认,即使在 这样的温度下,我们也不应该遇到节流问题,而且我们还通过让风扇以 100% 的速度运行系统和降低处 理器的 CTDP 来推翻了这一理论。这些改变使系统在负载情况下始终保持在70摄氏度左右,但问题依然 并未得到解决。


在一个多星期的时间里,我们检查了所有配置,包括BIOS设置、NVMe多路径、底层 NVMe 调试、更 改内核/Ubuntu版本,以及检查我们能想到的所有内核、操作系统和 Ceph 设置。但这些都没能完全解 决问题。


我们甚至在 "good "和 "bad "单OSD测试中执行了blktrace 和 iowatcher分析,可以直接观察到缓慢的 IO 完成行为:



Blkparse 输出 - Good vs Bad OSD


修 复







这时,我们开始让硬件供应商参与进来。但最终证明没有必要。经过⼀次小修和两次大修,一切都回到了正轨。



修复一

第一个修复方法很简单,但只能让我们的性能提高 10-20%。很多年前,有人发现(我记得是 Nick Fisk 还是 Stephen Blinick 发现的),Ceph 对 CPU c 状态转换带来的延迟非常敏感。对这些节点的 BIOS 进行快速检查后发现,它们并没有运行在禁用 C 状态的最高性能模式下。这是一个很好的结果,但还不足 以达到我们想要的结果。



修复二

当我们深入研究上图所示的blktrace结果时,我们有95%的把握认为,要么是 NVMe 硬盘出了问题,要么是与PCIe root complex 有关,因为这些系统中没有PCIe交换机。我们翻阅了大量的技术手册, 试图找到调试/配置该硬件的方法。此时,一位工程师主动提供了帮助。我们为他搭建了一个测试环境, 这样他就可以在一组备用节点上重复一些相同的测试,最后,直接得到了我们最想要的结果。


我们之前主要关注的是 wallclock 配置文件,同时也在深入调试硬件,而他则是想了解内核方面是否有些问题(现在回想起来,这显然是正确的!)。他在一次异常的运行过程中运行了一个性能分析,发现 了一个非常敏锐的问题:

   77.37% tp_osd_tp [kernel.kallsyms] [k]native_queued_spin_lock_slowpath            |            ---native_queued_spin_lock_slowpath               |                --77.36%--_raw_spin_lock_irqsave                          |                          |--61.10%--alloc_iova                          |          alloc_iova_fast                          |          iommu_dma_alloc_iova.isra.0                          |          iommu_dma_map_sg                          |          __dma_map_sg_attrs                          |          dma_map_sg_attrs                          |          nvme_map_data                          |          nvme_queue_rq                          |          __blk_mq_try_issue_directly                          |          blk_mq_request_issue_directly                          |          blk_mq_try_issue_list_directly                          |          blk_mq_sched_insert_requests                          |          blk_mq_flush_plug_list                          |          blk_flush_plug_list                          |          |                          |          |--56.54%--blk_mq_submit_bio


在更新IOMMU映射时,内核会花费⼤量时间争夺spin lock。

他禁用了内核中的IOMMU,在8节点测试中立即看到性能大幅提升。我们多次重复这些测试,发现4MB读/写性能大大提高。不过,4KB随机写入仍然存在问题。



修复三

经过其他人协助后, IOMMU 问题得到了解决。经过前两次修复后,4K 随机写入性能有所改善,但仍明 显低于上游实验室(即使节点/驱动器数量减少)。我们还注意到,RocksDB 的压缩速度比预期的要慢得 多。之前有两个重要的案例呈现出类似的情况,似乎与此有关:


 1. 如果没有正确编译 TCMalloc 支持,Ceph 的运行速度会非常慢。 

 2. 如果不使用正确的 cmake 标志和编译器优化编译,Ceph 的运行速度会非常慢。


这位客户一直使用Ceph Ubuntu 软件包,我们在这里也同样使用它们(而不是自编译或使用容器中的 cephadm)。我们检查了 TCMalloc 的编译情况。这就排除了第一个问题。接下来,我们查看了 17.2.7 Ubuntu 软件包的上游构建日志。这时我们才注意到,事实上,我们在编译 RocksDB 时并没有使用正确 的编译标志。虽然不清楚这种情况持续了多久,但我们早在 2018 年就遇到过⼀般的编译性能问题。


事实证明,Canonical 和 Gentoo 在看到我们 6 年前在 do_cmake .sh 中写下的说明后,都为自己的构建 修复了这个问题。很遗憾,我们的上游 Deb 构建一直以来都受到这个问题的困扰,不过,它至少不会影 响在 Debian/Ubuntu 上使用 cephadm 和上游容器的用户。在了解了问题所在之后,我们构建了定制的 17.2.7 软件包并进行了修复。压缩时间缩短了约 3 倍,4K 随机写入性能提高了一倍(虽然从图中很难看 出来):




4KB 随机写入性能仍然低于我们的预期,但鉴于我们的 OSD 数量较少,节点数量只有原来的 3/5,每个 OSD 的内核数量也较少(但速度更快),至少现在我们的性能大致处于合理的范围内。此时,我们已临近假期。客户希望将操作系统重新部署到正确的启动驱动器上,并使用我们发现的所有修复和调整功能 更新部署。我们的计划是利用假期休息,然后在新年的第⼀周完成烧机测试。希望我们能在下周开始迁 移集群。



第一次测试







我们重新部署了CBT并重新创建了我们之前运行的测试。这一次,我们可以使用每个节点的全部10块硬盘。我还增加了客户端的数量,使每个 OSD的 io_depth 为128,平均保持大约1个FIO客户端。第一个3节点测试结果不错。在每个节点有10个OSD的情况下,我们的性能与之前的测试基本成正比(IE 较高)。我们知道没有太多时间进行适当的扩展测试,所以我们立即将3节点提升到10节点。还同 时增加了PG数量,并使用CBT 部署了一个新的集群。在3节点时,我们看到 4MB随机读取的速度为 63GiB/s。在10个节点时,则看到了213.5GiB/s。这几乎是 98.4% 的线性扩展。此时,事情终于有了转 机。在这个集群的 68 个节点中,只有63个在运行。其余的节点都处于停机维护状态,以修复各种问 题。我们将集群大致分成两半,一半有 32 个节点(320个 OSD),另一半有31个客户端节点,每个节点运行10 个FIO进程。我们观察了CBT 在大约7-8分钟的时间内构建集群的过程。最初的写入预填充 看起来非常好。我们以635GiB/s的速度读取数据。我们的4k随机读取IOPS突破了1500万。虽然与 单个 NVMe 驱动器相比,结果是否并不是异常高,但这是我们所见过的约 300 OSD Ceph 集群的最高数据。




我们还绘制了缩放测试的平均延迟和尾部延迟图。两者看起来一致。这可能是由于在缩放OSD的同时缩 放了PG数量和FIO客户端数量。不过,这些测试的IO量非常大。我们有如此多的客户端流量,以至于 我们很可能已经进入了⼀个拐点,即随着IO的增加,性能不会再提高,而延迟却会继续增加。




副本测试







我们没有额外的客户机节点来测试集群的满负荷运行,因此唯⼀的选择就是将FIO进程与OSD放在同一个节点上。一方面,这提供了非常小的网络优势。客户端将有1/63的时间可以与本地OSD通信。另一方面,我们从以前的测试中了解到,在OSD节点上共用FIO客户端并不是没有影响的。这通常会对性能 造成影响,而我们还并不清楚这种规模的集群会受到多大的影响。


我们利用现有的63个节点构建了一个新的CBT配置。使用CBT部署集群只用了大约15分钟就启动了 所有 630 个OSD并建立了池。然后,观察结果。




大约 950GiB/s。非常非常接近我们想要的理想值。周六早上,我登录并对集群进行了一些调整:降低OSD分片和异步信使线程,同时应用Reef RocksDB 调整。正如大家所看到的,我们在提高写入性能的 同时,也略微降低了读取性能。事实上,随机写入性能提高了近 20%。进一步测试后发现, reef tunings 虽然只对写入测试有一点帮助,但似乎是良性的。更大的影响似乎来自于分片/线程的变化。此 时,我们先暂停休息一下,直到周日晚上才能再次恢复集群工作。


之前提到过,我们知道 PG 数量会影响性能。因此决定保留之前的“调整”配置,但将 PG 数量增加了一倍。

在第一组测试中,考虑到我们将客户端与 OSD 共同定位在 OSD 节点上,我降低了客户端与 OSD 的比率。现在我再次尝试扩大它们的规模。随着客户端数量的增长,4MB 随机读性能略有提升,而小随机 读 IOPS 则有所下降。一旦我们达到每个节点 8 个 FIO 进程(总共 504 个),顺序写入性能就会下降。




为了了解发生了什么,我们重新执行了写入测试,并查看了 "ceph -s "输出:

services:  mon: 3 daemons, quorum a,b,c (age 42m)  mgr: a(active, since 42m)  osd: 630 osds: 630 up (since 24m), 630 in (since 25m)       flags noscrub,nodeep-scrubdata:  pools:   2 pools, 131073 pgs  objects: 4.13M objects, 16 TiB  usage:   48 TiB used, 8.2 PiB / 8.2 PiB avail  pgs:     129422 active+clean           1651 active+clean+laggyio:  client: 0 B/s rd, 1.7 GiB/s wr, 1 op/s rd, 446 op/s wr

当我们向集群发送504个4MB写入的 FIO 进程时,一些PG就开始处于 active+clean+laggy 。

性能 急剧下降,直到工作负载完成,集群才从这种状态中恢复过来。更糟糕的是,随着时间的推移,更多的PG开始变得滞后,即使吞吐量只是集群能力的一小部分。从那时起,我们在邮件列表中发现了一些关于PG滞后的报告,以及一些可以解决这些问题的建议。目前还不清楚这些建议是否会对此处有所帮助。我们确实知道,当PG进入滞后状态时,IO会暂时中止,而发生这种情况的原因是副本没有及时确认来自主服务器的新租约。

在与其他Ceph开发人员讨论这个问题后,我们认为这可能是OSD中的锁问题,或者是租约消息与同/异步msgr 线程中的工作竞争的问题。


尽管被延迟的PG问题分散了注意力,但我们还是想重新回到如何达到 1.0TiB/s 这一目标上。我们又把PG数量增加了一倍,达到了256K,想看看这对PG滞后问题是否有任何影响。这让我们的速度稳稳地 达到了我们之前展示的曲线的上端,不过老实说,我不认为这有什么关系。我决定换回默认的OSD分区数量,并继续使用504 个FIO客户端进程进行测试。不过,我还是增加了异步消息线程的数量。有两大收获。

首先,减少到1个异步消息线程可以避免PG出现滞后,并在504个客户端的情况下实现 "OK "的 写吞吐量。但这也大大降低了4MB读取的性能。第二点:Ceph的默认设置实际上非常适合4MB读取。通过8个分片、每个分片2个线程和3个 msgr 线程,我们最终突破了 1TiB/s。下⾯是最后⼀组测 试时看到的景象:

services:  mon: 3 daemons, quorum a,b,c (age 30m)  mgr: a(active, since 30m)  osd: 630 osds: 630 up (since 12m), 630 in (since 12m)       flags noscrub,nodeep-scrub
data: pools: 2 pools, 262145 pgs objects: 4.13M objects, 16 TiB usage: 48 TiB used, 8.2 PiB / 8.2 PiB avail pgs: 262145 active+cleanio: client: 1.0 TiB/s rd, 6.1 KiB/s wr, 266.15k op/s rd, 6 op/s wr


以及 FIO 结果图:






纠删码测试







还有很多工作要做。到目前为止,我们所做的所有测试都是使用3X 副本,但客户会将此硬件迁移到部署 有 6+2 纠删码的现有集群中。我们需要了解一下该集群在他们将要使用的配置中的性能。


我们再次重新配置了群集,并进行了新的测试。我从之前的测试中挑选了看起来运行良好的PG/shard/client 值。性能还不错,但我们发现异步消息线程工作得非常困难。我们决定在默认值的基 础上增加线程数,看看在网络流量增加的情况下是否会有帮助。



使用4-5个异步msgr线程,我们的读取速度远远超过500GiB/s,

写入速度接近400GiB/s。但为什么使用EC时的读取速度比使用复制时慢得多?使用复制时,PG的PrimaryOSD只需读取本地数据并将其发 送到客户端。网络开销基本上是1倍。使用6+2 消除编码时,Primary OSD必须从副本中读取6个数据 块中的5个,然后才能将构建的对象发送给客户端。请求的总体网络开销大致为 (1+5/6)X*。这就是为 什么我们看到的读取性能略高于3倍复制性能的一半。写入的情况正好相反。使用3倍复制时,客户端将对象发送到主服务器,然后 Primary OSD 节点再通过网络将副本发送到两个Secondary OSD 。这将 导致3倍的总网络开销。在EC情况下,我们只需向Secondary OSD节点发送 7/8 个数据块(几乎与读取情况相同,但不完全相同)。对于大容量写入,性能实际上更快。


本文最初指出读取时必须获取7/8个数据块。但正确的值是5/6块,除非启用了快速读取。在这种情况下,应该是7/6块。


然而,IOPS则是另一回事。对于非常小的读取和写入,Ceph会联系PG 中所有参与该对象的OSD,即 使它们存储的数据与操作无关。例如,如果您正在进行4K读取,而数据完全存储在其中一个OSD的单个块中,Cep 仍会从参与条带的所有OSD抓取数据。2023年,Clyso引入了来自Xiaofei Cui的PR, 该PR为擦除编码实现了部分条带读取,从而避免了这些额外工作。效果非常显著:


虽然 Ceph 项目的核新负责人 Radoslaw Zarzynski 表示愿意帮助我们完成这项工作,但目前还不清楚我 们是否能够为 Squid 合并这项工作。


Msgr 加密测试







最后,我们希望让客户大致了解如果他们决定使用msgr级加密会对他们的集群产生多大影响。我们成功 地在启用了msgr v2加密的情况下运行了 3X 副本和 6+2 擦除编码测试,并将其与我们之前的测试结果 进行了比较。




影响最大的是大容量读取。它们从~1 TiB/s降⾄约750 GiB/s。其他方面的影响虽然持续存在,但幅度 较小。此时,因时间有限,我们不得不停止测试。我们希望做一些PG扩展测试,甚至内核RBD测试。不过,只能到此为止了。


最 后







测试结束后,这个集群发生了什么变化?我们对所有硬件进行了重新安装,并将新的 OSD 部署到客户现 有的硬盘集群中。Dan的 upmap 重映射脚本用于控制迁移过程,我们已经将大约 80% 的现有数据迁移 到了 NVMe 支持的 OSD。预计到下周,集群将完全迁移到基于 NVMe 的新节点上。我们选择不采用我 们在这里所做的所有调整,至少一开始不会。起初,我们将确保集群在现有配置(主要是默认配置)下 运行良好。如果客户遇到任何性能问题,我们现在就可以利用大量数据进一步调整系统。


由于本次测试过程中有大量的数据和图,因此,我们只是总结了一下其中的最重点的部分。


以下是我们在该集群上取得的最佳结果概要表:


下⼀步是什么?我们需要想办法解决写入过程中PG滞后的问题。我们不能让 Ceph 在写入操作量增加时崩溃。除此之外,我们还通过这次测试了解到,Ceph 完全能够让 2x 100GbE NIC 达到饱和。如果要进一步提高吞吐量,在每个节点使用10 个或更多 NVMe 驱动器时,我们将需要 200GbE 以上的网络。


一步提高吞吐量,在每个节点使用10个或更多 NVMe 驱动器时,我们将需要 200GbE 以上的网络。IOPS 的影响更为细微。我们知道,PG 数量会产生很大影响。我们还知道,一般 OSD 线程模型也有很大影响。每个节点的随机读取 IOPS 在 40-600K 左右时,我们总是会越到各种问题,我们在多个部署环境 中都看到过这种情况。部分原因可能是异步 msgr 与内核的交互方式,部分原因可能是 OSD 线程如何在 新工作进入分片队列时唤醒。我们过去修改过 OSD 代码,以便在重负载下取得更好的效果,但代价是低 负载延迟。最终,我们认为提高IOPS 需要多管齐下,并重写部分 OSD 线程代码。


目前,这是迄今为止公布的速度最快的单集群 Ceph,也是 Ceph 集群首次达到 1 TiB/s 的性能。同时, 我们认为 Ceph 还能做得更好。如果你有更快更好的的集群环境,我们也希望能够你们能够在自身的环 境中进行验证,然后发布相应的测试结果,同时也欢迎共享到社区。


如有相关问题,请在文章后面给小编留言,小编安排作者第一时间和您联系,为您答疑解惑。


原文:https://ceph.io/en/news/blog/2024/ceph-a-journey-to-1tibps


    推荐阅读   




    推荐视频    



微信扫码关注该文公众号作者

来源:新钛云服

相关新闻

Redis最佳实践:系统性能提升了10倍,真香!【研究方法】1. 科学实践:对研究方法的介绍文末送书 | 陆奇、韦青等力荐!Chatbot从0到1:对话式交互实践指南易点天下:从0到1精益创新-AIGC产品应用及商业化落地实践报告一位中产爸爸的亲身实践:普通家庭,请不遗余力完成原始积累探索 Copilot 创新实践:腾讯、字节跳动、PingCAP 与第四范式共聚 AICon探索 Copilot 创新实践:腾讯、字节跳动、PingCAP 与第四范式共聚 AICon利用 Istio 强化微服务安全:最佳实践与实战案例Ceph RocksDB 性能改进说明公开讲座|研究型硕士 vs. 实践型硕士:以哥大心理项目为例Ceph Reef 测试:RGW 的Throughput 和ecRovery安省免费新手钓鱼课开放报名:知识课+实践课,大人、小孩都可参加!PBL全系统培训 | 从0到1的创新实践之旅大模型时代的工业质检:技术革新与实践探讨LeCun新作:神经网络在实践中的灵活性到底有多大?广州数据交易所:数据资产化实践指南报告(2024年)Ceph 提供 NFS 服务:高效存储解决方案的终极指南大数据技术标准推进委员会:2024年DataOps 实践指南2.0如何从学术研究转行临床实践?华丽转身:认知申请科学到舞动治疗拥抱数据驱动:Java 企业测试实践新趋势陈界仁 × 邹德怀 × 祁天娇:档案、艺术实践与历史叙事大数据技术标准推进委员会:2023数据运营实践白皮书Docker实战教程:全套学习笔记+项目实践,一站式掌握!探索 IT 架构治理之道:微众银行的实践与思考
logo
联系我们隐私协议©2024 bendi.news
Bendi新闻
Bendi.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Bendi.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。