公司网站的维护,西安哪个公司做网站,网站更新后 为什么不显示,c2c模式的优势和劣势背景
随着物理硬件的不断发展#xff0c;存储软件所使用的硬件的情况也一直在不断变化。
一方面#xff0c;内存和 IO 技术一直在快速发展#xff0c;硬件的性能在极速增加。在最初设计 Ceph 的时候#xff0c;通常情况下#xff0c;Ceph 都是被部署到机械硬盘上#x… 背景
随着物理硬件的不断发展存储软件所使用的硬件的情况也一直在不断变化。
一方面内存和 IO 技术一直在快速发展硬件的性能在极速增加。在最初设计 Ceph 的时候通常情况下Ceph 都是被部署到机械硬盘上能够提供数百 IOPS 的读写和数十 G 的磁盘容量。但是目前最新的 NVMe 设备可以提供数百万的 IOPS 读写并支持 TB 级的磁盘容量。DRAM 的容量在大约20年的时间内增加了128倍。对于网络 IO 来说网卡设备现在能够提供超过 400Gbps 的速度而几年前只有 10Gbps。 另一方面在大约十年的时间内CPU 频率和 CPU 内核的单线程性能一直处于稳定的状态增长不明显。相比之下逻辑核心的数量随着晶体管规模的增加而迅速增长。 Ceph 的性能要跟上硬件发展的速度一直很有挑战的因为 Ceph 的架构是十年前的——它对单核 CPU 性能的依赖使它无法充分利用不断增长的 IO。特别是当 Ceph 对象存储守护程序OSD依赖线程池来处理不同的 IO 时跨 CPU 核心通信会产生了大量的延迟开销。减少或消除这些开销成本是 Crimson 项目的核心目标。
Crimson 项目使用 shared-nothing 设计和 run-to-completion 模型来重写 Ceph OSD以满足苛刻的硬件与软件系统的扩展要求同时也与现有的客户端和组件兼容。
为了理解 Crimson OSD 如何针对 CPU 扩展进行重新设计的我们比较了 传统 OSD 和 Crimson OSD 之间的架构差异来解释架构怎么以及为何这样设计。然后我们讨论了 Crimson 为什么建立在 Seastar 框架之上以及每个核心组件是如何实现扩展的。
最后我们分享了实现这一目标的最新情况同时还提供了一个我们最终希望达到的性能结果。 Crimson 与传统 OSD 架构
Ceph OSD 是 Ceph 集群的一部分主要负责通过网络来提供对象的访问、维护数据冗余和高可用性以及将对象持久化到本地存储设备。作为传统 OSD 的重写版本Crimson OSD 从客户端和 OSD 的角度来看是与现有的 RADOS 协议兼容的它提供相同的接口和功能。Messenger、OSD 服务和 ObjectStore 等 Ceph OSD 模块化的功能没有太大改变但跨组件交互和内部资源管理的形式进行了大幅重构以使用 shared-nothing 设计和自下而上的用户空间任务调度。
传统 OSD 的架构中每个组件中都有线程池针对多 CPU 核心场景下使用共享队列处理任务效率很低。在一个简单的例子中一个 PG 操作需要先由一个messenger worker 线程处理将原始数据流组装或解码成一条消息然后放入消息队列中进行调度。之后由一个PG worker thread 来获取消息经过必要的处理后将请求以事务的形式交给 ObjectStore。
事务提交后PG 会完成操作再次通过发送队列和 messenger worker 线程发送回复。尽管可以通过向池中添加更多线程来将工作负载扩展到多个 CPU但这些线程默认共享资源因此需要锁这会引入争用问题。 传统架构的一个主要挑战是锁竞争开销随着任务数和 CPU 核数的增加而迅速扩大在某些场景下每个锁点都可能成为扩展瓶颈。此外这些锁和队列即使在没有争用的情况下也会产生延迟开销。多年来社区在分析和优化更细粒度的资源管理和快速路径实现以跳过队列方面做了大量工作。未来这类优化的成果会越来越少可扩展性似乎会在当前的设计架构下达到了某个瓶颈。也还有其他挑战。随着在工作线程之间分配任务延迟问题将随着线程池和任务队列而恶化。锁可以强制上下文切换这会使事情变得更糟。
Crimson 项目希望通过 shared-nothing 设计和 run-to-completion 模型来解决 CPU 可扩展性问题。该设计的重点是强制每个内核或 CPU 运行一个固定线程并在用户空间中分配非阻塞任务。因为请求以及它们的资源可以被分配到各个核心所以它们可以在同一个核心中被处理直到处理完成。理想情况下我们不再需要所有的锁和上下文切换因为每个正在运行的非阻塞任务都使用到 CPU一直到它完成任务。没有其他线程可以在同一时间抢占任务。如果不需要与数据路径中的其他分片通信理想情况下性能将随着内核数量线性扩展直到 IO 设备达到其极限。这种设计非常适合 Ceph OSD因为在 OSD 层面所有 IO 都已经被 PG 分片了。 虽然跨区通信不能完全消除但那通常是用于 OSD 全局状态的维护而不是用于数据路径中。这里的一个主要挑战是最重要的改变是对 OSD 操作的基本要求——相当一部分现有的锁或线程代码无法重用需要重新设计同时保持向后的兼容性。
重新设计需要对代码的整体理解以及相关的注意事项。使用 shared-nothing 架构实现底层的one-thread-per-core和用户空间调度是另一个挑战。
Crimson 试图在 Seastar 的基础上重新设计 OSDSeastar 是一个异步编程框架具有满足上述目标的所有理想特性。 Seastar Framework
Seastar 是 Crimson 项目的理想选择因为它不仅在 C 中实现了 one-thread-per-core 的 shared-nothing 架构而且还提供了一套全面的功能和模型这些功能和模型已被证明在其它应用程序中对性能和扩展有效。资源默认情况下不在分片之间共享Seastar 实现了自己的内存分配器以进行无锁分配。该分配器还利用了 NUMA 拓扑结构的优势将最近的内存分配给分片。对于一些不可避免的跨核资源共享和通信Seastar 强制要求明确地处理它们。如果一个分片拥有另一个核心的资源它必须通过外部指针指向这些资源如果一个分片需要与其他分片通信它必须提交并转发任务给他们。这就迫使程序限制其跨核的需求并有助于减少对 CPU 扩展性问题的分析范围。Seastar 还为跨核通信实现了高性能的非阻塞通信。 传统的带有异步事件和回调的程序在实现、理解和调试方面是非常困难的。用户空间的非阻塞任务调度需要实现普遍的异步性。Seastar 将 futures、promises 和 continuations (f/p/c) 作为构建块来组织逻辑。futures 和 promises 通过将逻辑上连接的异步结构组合在一起而不是将它们分散用于普通的回调中这使代码更更容易实现以及更好的可读性。Seastar 还为循环、计时器以及基于未来控制生命周期甚至 CPU 份额提供了更高级别的工具。为了进一步简化应用程序Seastar 将网络和磁盘访问封装到 shared-nothing 和基于 f/p/c 设计的模式中。采用不同 I/O 堆栈如 epoll、linux-aio、io-uring、DPDK 等的复杂性和细微控制对应用程序代码是透明的。 Run-to-completion performance
Crimson 团队已经为 RBD 客户端的读写工作负载实现了 OSD 的大部分关键特性。当前完成的任务包括重新实现 messenger V2 (msgr2) heartbeat PG peering backfill recovery object-classes watch-notify etc等并不断努力的增加一些 CI 测试组件。Crimson 已经达到了一个里程碑我们可以在具有足够稳定的单个分片中验证run-to-completion设计。
综合考虑现实条件在相同的随机 4KB RBD 工作负载下在没有复制的情况下通过将传统和 Crimson OSD 与 BlueStore 后端进行比较来验证 single-shard run-to-completion。两个 OSD 都分配了 2 个 CPU 资源。Crimson OSD 很特别因为 Seastar 需要一个独占 CPU 核心来运行 single-shard OSD 逻辑。这意味着 BlueStore 线程必须固定到另一个核心引入 AlienStore 来弥合 Seastar 线程和 BlueStore 线程之间的边界并在两个边界之间提交 IO 任务。相比之下传统 OSD 没有限制使用分配的 2 个 CPU。 性能结果显示使用 BlueStore 时Crimson OSD 的随机读取性能大约提高了 25%随机写入情况下的 IOPS 大约比传统 OSD 高 24%。进一步的分析显示在随机写的情况下CPU 的利用率很低因为大约 20% 的 CPU 被消耗在频繁的查询中这表明 Crimson OSD 应该不是是当前的瓶颈。 Crimson OSD 提交和完成 IO 任务以及在 Seastar 和 BlueStore 线程之间进行同步也有额外的开销。因此我们针对 MemStore 后台重复了同一组实验两个 OSD 都分配了 1 个 CPU。如下图所示Crimson OSD 在随机读取中提供了大约 70% 的 IOPS在随机写入中比 传统 OSD 高 25%这与之前实验中的结论一致即 Crimson OSD 可以做得更好。 尽管上述场景仅涵盖实验性 single-shard 案例但结果表明使用 Seastar 框架具有性能优势——消除锁、通过用户空间任务调度删除上下文切换、分配更靠近 CPU 的内存。此外重要的是要重申run-to-completion 模型的目标是更好地扩展 CPU 并消除软件使用高性能硬件而引起的性能瓶颈。 Multi-shard Implementation
实现多分片的路径很明确。由于每个PG中的 IO 已经在逻辑上被分片所以对IO路径没有太大改变。主要的挑战是确定无法避免的跨核通信并设计新的解决方案以尽量减少其对IO路径的影响这需要根据具体情况进行分析。一般来说当从 Messenger 接收到一个 IO 操作时它会根据 PG-core 映射被定向到 OSD 分片并在同一分片/CPU的上下文中运行直到完成。请注意在当前阶段为了简单起见设计上选择不修改RADOS协议。 Messenger
Messenger 在确保解决方案可扩展方面发挥着重要作用。有一些限制需要认真考虑。一个限制来自 RADOS 协议它只为每个客户端或 OSD 定义一个连接。连接必须存在于特定核心上才能根据其状态高效且无锁地解码和编码消息。与 OSD 对等体的共享连接意味着在当前阶段跨核消息传递到多个 PG 分片是不可避免的除非可以调整协议以允许到每个分片的独占连接。
Seastar 框架的另一个限制是它不允许在 Seastar 套接字被 accept()ed 或 connect()ed 之后移动到另一个核心。这对无损连接 (msgr2) 来说是一个挑战因为它会影响 Messenger 和 OSD 服务之间的交互在这种情况下由于网络故障重新连接连接可能会预先跳转到另一个核心。
扩展 Messenger 的大部分工作是在将 IO 操作分派到 PG 分片之前将消息传递工作负载编码、解码、压缩、加密、缓冲区管理等优化扩展到多个内核并最小化跨内核消息沿 IO 路径传递理想情况下在上述约束下对于每个消息发送和接收操作它最多保持 1 跳。
OSD
OSD 负责维护 PG 分片之间共享的全局状态和活动包括心跳、身份验证、客户端管理、osdmap、PG 维护、访问 Messenger 和 ObjectStore 等。
多核 Crimson OSD 的一个简单原则是将所有与共享状态相关的处理保持在专用内核上。如果一个 IO 操作要访问共享资源要么按顺序访问专用核要么访问保持同步的共享信息的独占副本。
实现这一目标有两个主要步骤。第一步是让 IO 操作根据 PG 分片策略运行在多个 OSD 分片中包括 PG 状态在内的所有全局信息都维护在第一个分片中。此步骤在 OSD 中启用分片但需要在第一个分片中做出有关 IO 调度的所有决策。即使这一步 Messenger 可以在多核中运行消息仍然需要传递到第一个分片进行准备例如 PG peering并在提交到该分片之前确定正确的 PG 分片。这会导致额外的开销和不平衡的 CPU 使用第一个 OSD 分片使用率高其他分片很低等等。因此下一步是将 PG-core 映射扩展到所有 OSD 分片。
ObjectStore
Crimson 支持三种 ObjectStore 后端AlienStore、CyanStore 和 SeaStore。AlienStore 提供与 BlueStore 的向后兼容性。CyanStore 是用于测试的虚拟后端由易失性内存实现。SeaStore 是一种新的对象存储专为 Crimson OSD 设计采用 shared-nothing 设计。根据后端的具体目标实现多分片支持的路径是不同的。
1AlienStore
AlienStore 是 Seastar 线程中的一个瘦代理用于与使用 POSIX 线程的 BlueStore 进行通信。对于多个 OSD 分片没有特别的工作要做因为 IO 任务通信同步了。BlueStore 中没有为 Crimson 定制其他内容因为不可能真正将 BlueStore 扩展到 shared-nothing 设计因为它依赖于第 三 方 RocksDB 项目而 RocksDB 仍然是线程的。但是在 Crimson 能够拿出一个足够优化和足够稳定的原生存储后端解决方案SeaStore之前合理的开销来换取复杂的存储后端解决方案是可以接受的。
2CyanStore
Crimson OSD 中的 CyanStore 与传统 OSD 中的 MemStore 相对应。对多分片支持的唯一改变是为每个分片创建独立的 CyanStore 实例。一个目标是确保虚拟 IO 操作能够在同一个内核中完成以帮助识别 OSD 级别的可扩展性问题如果有的话。另一个目标是在 OSD 层面上与传统 OSD 做直接的性能比较而不受 ObjectStore 的复杂因数影响。
3SeaStore
SeaStore 是 Crimson OSD 原生的 ObjectStore 解决方案采用 Seastar 框架开发采用相同的设计原则。
虽然很有挑战性但是 Crimson 必须建立一个新的本地存储引擎这有多种原因。存储后端是主要的 CPU 资源消耗者如果 Crimson OSD 的存储后端不改变那么它就不能真正地随核心扩展。我们的实验也证明了 Crimson OSD 不是随机写入场景中的瓶颈。
其次BlueStore 中具有事务支持的 CPU 密集型元数据管理基本上由 RocksDB 提供如果不重新实现它无法在原生的 Seastar 线程中运行。与其为 BlueStore 重新实现通用的键值事务存储不如在更高的层次上重新思考和定制相应的架构——ObjectStore。问题在原生的解决方案中比在 第三方项目中更容易解决因为第三方项目必须保证使用与通用的场景。
第三个考虑是为异构存储设备和硬件加速器提供原生支持让用户可以根据自己的需求平衡成本和性能。如果 Crimson 能够更好地控制整个存储堆栈那么 Crimson 将更灵活地简化部署硬件组合的解决方案。
SeaStore 在单分片读写方面已经可以正常使用尽管在稳定性和性能改进方面仍有待努力。目前的努力仍然集中在架构上而不是极端情况下的优化。它针对多分片 OSD 的设计很明确。与 CyanStore 一样第一步是为每个 OSD 分片创建独立的 SeaStore 实例每个实例都在存储设备的静态分区上运行。第二步是实现一个共享磁盘空间平衡器来动态调整分区它应该可以在后台异步运行因为 PG 已经以伪随机方式分配了用户 IO。SeaStore 实例可能不需要等于 OSD 分片的数量根据性能分析调整这个比例是后期工作的第三步。 摘要和测试配置
在这篇文章中我们介绍了为什么以及如何对 Ceph OSD 进行重构以跟上硬件的发展。另外我们也给出了我们所做的详细设计、 一个简单的性能测试结果。也提供了 Crimson OSD 真正实现多核可扩展的所要考虑的大部分因素。
测试结果可能会根据不同的 commit 版本、软件和硬件配置而有所变化。为了确保我们的测试是可重复的可复现的并可在以后场景中作为参考我们列出了所有可能产生影响的设置和注意事项。
我们为 Crimson 和 传统 OSD 部署了本地 Ceph 集群并使用 CBT 执行了 FIO 测试。Crimson 在使用 tcmalloc 时仍然存在问题因此为了公平起见我们将两个 OSD 配置为使用 libc*。我们使用 BlueStore。RBD 缓存被禁用。BlueStore 线程数设置为 4 以获得更好的结果。部署 Crimson 时需要指定*ceph-osd_cmd ( crimson-osd )。CPU 绑定通过 CBT 配置文件中的 crimson_cpusets 指定BlueStore 线程通过 crimson_alien_thread_cpu_cores 和 crimson_alien_op_num_threads配置。要部署传统 OSDnumactl 用于控制 CPU 绑定。根据 CBT 存储库部署过程的其余部分没有变化。
测试场景
Client: 4 FIO clientsIO mode: random write and then random readBlock size: 4KBTime: 300s X 5 times to get the average resultsIO-depth: 32 X 4 clientsCreate 1 pool using 1 replica1 RBD image X 4 clientsThe size of each image is 256GB
测试环境
Ceph 版本 (SHA1)7803eb186d02bb852b95efd1a1f61f32618761d9Ubuntu 20.04GCC-121TB NVMe SSD 作为 BlueStore 块设备50GB 内存用于 MemStore 和 CyanStore
