Ceph Virtual 2022

为了提高产品的可观测性和稳健性，Ceph 的遥测模块允许用户自动报告匿名崩溃转储。Ceph 的遥测后端运行工具，用于检测这些报告的崩溃事件之间的相似性，然后将它们反馈到 Ceph 的错误跟踪系统。在本次会议中，我们将探讨 Ceph 崩溃遥测的整个流程，以及它如何帮助开发社区检测生产系统中遇到的新兴和频繁问题。我们将分享我们迄今为止的见解，并了解用户如何从该模块中受益，以及他们如何做出贡献。

本次演示将介绍创建环境以使用 librados 进行编程所需的条件，并详细探讨其核心功能，包括键值存储、原子事务、对象克隆和快照支持。然后，我们将探讨如何使用存储节点上的任意代码扩展对象接口。我们的目标是向您展示如何将代码带到数据中，以实现高价值、高容量和后台数据处理任务，从而颠覆行业标准的先检索数据再将其带到代码的路径。我们将演示自动对新上传的数据执行操作，真正实现无服务器方式。

Ceph 实现了对各种工作负载的非结构化数据的灵活且可扩展的对象存储。RGW (RADOS GateWay) 部署会遇到各种对象大小，并且必须平衡工作负载、成本和性能要求。S3 存储类是一种成熟的方法，可以将数据引导到满足特定弹性、成本和性能要求的底层介质上。例如，可以为 SSD 或 HDD 介质、非冗余与复制或擦除编码池定义 RGW 后端存储类等。将单个对象或整个存储桶转移到非默认存储类通常需要特定的客户端操作。但是，合规性可能难以请求且无法强制执行，尤其是在包含付费客户和内部用户的多租户部署中。这项工作使 RGW 后端能够根据特定标准强制执行上传对象上的存储类，而无需客户端操作。例如，可以为资源密集型小 S3 对象定义性能 TLC 或 Optane 介质上的默认存储类，同时将较大对象分配给 Matt Vandermeulendense 和具有成本效益的 QLC SSD 介质。

Anthony D'Atri

随着集群规模和数量的增长，操作人员的工作量不应以相同的速度增长。在本讲座中，Matt Vandermeulen 将讨论在快速增长的环境中运行不同规模集群的策略和挑战，这些集群基于 DigitalOcean 的经验，用于 RBD 和对象存储工作负载。

Ceph 一直是 5G 存储要求的有希望的解决方案和边缘数据中心。那么接下来呢？本次讲座将向听众提供对未来 6G 技术挑战的简明而全面的概述，以及 Ceph 如何为这些挑战做好准备。

下一代存储设备需要策略上的改变，因此社区一直在开发 Crimson，作为 ceph-osd 的最终替代品，旨在最大限度地减少 CPU 开销并提高吞吐量和延迟。Seastore 是 Crimson-osd 的新型后端存储，面向新兴存储技术，包括持久性内存和 ZNS 设备。本次讲座将解释 Crimson 项目和 Seastore 的最新进展。

SeaStore 是为补充 Crimson OSD 而设计的新的 ObjectStore，旨在支持新一代存储接口/技术（NVMe、ZNS、持久性内存等）。随着 SeaStore 的成熟，分析变得越来越重要，以了解设计选择的全面性能影响，并为后端走向主流设定方向。分析基础设施还将帮助新贡献者了解 SeaStore 的内部工作原理。在本次会议中，我们将讨论 SeaStore 对性能分析的支持、基于初步分析进行的优化、当前状态或与 BlueStore 相比的差距以及性能数据。

随着越来越多的快速设备（尤其是持久性内存）配备在数据中心，CPU 承受的压力很大，需要驱动这些设备（例如 Intel Optane DC 持久性内存）以实现持久性目的，尤其是在重负载下。由于与 HDD 和 SSD 相比，持久性内存不提供与 DMA 相关的能力。并且 Ceph 在使用持久性内存时也存在相同的问题。我们希望通过利用内存卸载设备（例如 DSA）来解决这些痛点。因此，通常在本讲座中，我们将讨论：1) 为什么持久性内存集成在 Ceph 中并不成功，因为在持久性设备上执行 I/O 操作时 CPU 开销很高；2) 我们引入了内存卸载设备（例如 DSA）以卸载 CPU 压力，同时执行 I/O；3) 我们将描述 pmem 设备（即 src/blk/pmemdevice.cc）中的主要更改，以及如何实现卸载，包括挑战。4) 如果 Intel 的 SPR 平台公开可用，我们希望提供一些初步的性能结果。

S3 Select 是 Amazon 于 2018 年推出的 S3 操作，它实现了一种推送下压范例，仅从对象中提取您需要的数据，这可以显着提高性能并降低应用程序访问 S3 中数据的成本。本次讲座将介绍 s3select 操作和架构。它将描述什么是推送下压技术，为什么以及在哪里对用户有益。它将涵盖 s3select 支持的功能及其与分析应用程序的集成。它将讨论列式和非列式格式（CSV 与 Parquet）之间的主要区别。我们还将讨论 ceph/s3select 的最新进展。本次演示将展示如何轻松使用 ceph/s3select。

1. 使用 NIC SR-IOV。每个 OSD 使用独占的 VF NIC。2. 添加 DPDK 中断模式。3. 实现单 CPU 核心和多个 NIC 队列以提高性能。4. 添加管理套接字命令以获取 NIC 状态、收集统计信息和定位故障。5. 调整 CEPH 节流参数、TCP 和 DPDK 数据包发送和接收缓冲区大小，以防止数据包丢失和重传。6. Crimson 消息组件使用 Seastar DPDK。

RGW 旨在为 Ceph 集群提供对象访问（S3/Swift）。Zipper 抽象 API 将 RGW 分为上半部分，包含 S3 和 Swift 的操作 (Ops)，以及下半部分，称为存储 (Store)，包含有关如何在存储中存储数据和元数据的详细信息。这使得相同的 Ops 代码可以通过各种存储平台提供正确的 S3 和 Swift 语义。主要的存储是当前的 RadosStore，它通过 RADOS 提供对 Ceph 集群的访问。但是，新的存储是可能的，这些存储可以将数据存储在任何所需的平台上。其中一种存储，称为 DBStore，已经开发出来，它将数据存储在 SQL 中，特别是本地 SQLite 数据库中。计划开发其他存储，例如 S3，以提供额外的灵活性。Zipper 还允许中间的过滤器层，这些层可以转换 Ops、执行策略（例如将不同的对象定向到不同的存储）或为数据和元数据执行缓存。第一个计划的过滤器是 LuaFilter，它将允许快速原型设计和测试其他过滤器。RGW 的单个实例将由过滤器堆栈以及一个或多个提供实际数据的存储组成。本次演示将涵盖有关 Zipper、现有 DBStore 以及未来计划的信息。

Cybozu 已经运行和测试他们的 Rook/Ceph 集群两年了。在此期间，他们遭受了一堆 BlueStore 损坏（例如 #51034 和 #53184）。大多数损坏发生在 OSD 创建或重新启动 OSD 之后。他们能够检测到这些问题，因为他们的集群中的节点经常重新启动，并且每次集成测试都会发生大量的 OSD 创建。这些场景在传统的 Ceph 集群中并不常见，但在容器化 Ceph 集群中很常见。他们将详细分享已知的问题以及他们如何与 Ceph 社区克服这些问题。此外，他们还将提出改进 QA 流程的建议，以防止将来出现类似的问题。

我们探索 Rook 与 Ceph 暴露的安全模型，Ceph 是开源世界领先的软件定义存储平台。深入堆栈，我们研究适用于各种威胁模型的 Ceph 存储强化选项。这些选项包括定义威胁模型、通过实施单独的安全区域来限制攻击的爆炸半径、使用静态和传输中的加密以及符合 FIPS 140-2 认证的密码、强化构建和默认配置，以及用户访问控制和密钥管理。数据保留和安全删除也得到了解决。容器化过程本身通过轻量级的域分离创造了额外的安全优势。Rook 使应用强化选项的过程更容易，因为这变成了简单地修改创建时带有适当安全上下文的 .yaml 文件，从而可以轻松地将 Ceph 的标准强化选项应用于基于容器的存储系统。

科学和研究界越来越希望开始使用对象存储来存储和处理其在高能效（HPC）集群中的数据。然而，对象存储不一定为性能而设计，更适合长期存储。因此，用户通常在使用处理数据时会使用高性能文件系统。然而，网络文件系统存在一个问题，即一个用户可能会潜在地使网络崩溃，并影响集群中其他人的数据处理作业的性能。本次演讲介绍了一种解决此问题的方法 DisTRaC - (Dis)tributed (T)raisent (Ra)m (C)eph。DisTRaC 通过提供一种方法让用户将 Ceph 部署到其 HPC 集群中使用 RAM 来解决此问题。它们的中间数据处理现在可以在 RAM 中完成，从而减轻网络文件系统的压力，并通过使用节点互连来传输数据。此外，所有数据都本地化，为作业期间创建一个超融合的 HPC 集群。DisTRaC 减少了网络文件系统的 I/O 开销，并提供了潜在的数据处理性能提升。

Quincy 版本的新功能之一是引入了新的负载均衡器（又名主负载均衡器）。虽然自 upmap 负载均衡器引入以来，容量平衡一直存在并且运行良好，但为了使所有 OSD 上的负载均衡，主负载均衡问题从未得到解决。这被证明是一个性能问题，尤其是在小型集群和 PG 较少的池中。在本演示中，我们将讨论容量平衡和负载平衡之间的区别（有时甚至是矛盾），解释我们为 Quincy 所做的工作，并概述未来改进 Ceph 平衡过程的计划。

NVMe-over-Fabrics (NVMeoF) 是一种开放、广泛采用的、事实上的高性能远程块存储访问标准。越来越多的存储厂商正在引入 NVMeoF 目标支持，并为 NVMeoF 目标和发起者提供硬件卸载。Ceph 不支持 NVMeoF 协议用于块存储访问；它的客户端使用 Ceph RADOS 协议访问 RBD 镜像，这是有充分理由的：RADOS 是一种分布式 m-to-n 协议，它为分片和复制（或纠删编码）的 Ceph 存储提供可靠的对象访问。然而，为 Ceph 启用 NVMeoF 有充分的理由：为了能够在已经利用存储硬件卸载 NVMeoF 功能的数据中心中使用它，并允许现有的 NVMeoF 存储用户轻松迁移到 Ceph。在本演讲中，我们介绍了将本机 NVMeoF 目标集成到 Ceph RBD 的工作。我们讨论了为 Ceph 实现这种支持的一些挑战，包括子系统/命名空间发现、多路径用于容错和性能、身份验证和访问控制（例如，命名空间屏蔽）。此外，我们描述了如何通过利用 Ceph CRUSH 算法 (ADNN) 来扩展 NVMeoF 目标设计，以减少额外的网络跳数。

对于 Kubernetes 中的应用程序，CSI 提供了一种使用文件/块存储的方式。容器对象存储接口背后的主要动机是为对象存储提供类似体验。基本思想是提供一个通用的、动态配置 API 来使用对象存储，应用程序 Pod 可以像使用 PVC 一样访问底层对象存储中的存储桶。此实现的主要挑战是没有为对象定义标准协议，COSI 项目需要与供应商无关。它不会处理对象存储的编排/管理，而是作为另一个客户端提供，代表在 Kubernetes 中运行的应用程序提供存储桶访问权限。ceph-cosi 驱动程序的初始版本可以在 https://github.com/ceph/ceph-cosi 找到。

本次会议概述了 rook-ceph 集群的故障排除，讨论了一些故障排除场景。随后介绍了 kubectl-rook-ceph krew 插件及其如何从故障排除的角度简化容器管理。我们还将讨论我们计划使用它解决的未来问题，以及 rook 项目的简短未来路线图。稍后，我们期待讨论并收集用户关于他们在故障排除集群时遇到的常见和具有挑战性的问题的反馈。