介绍
在未来几年，大型粒子对撞机获取的大量数据将对CERN的存储吞吐量、容量和存储的耐久性提出更高的要求。开源存储系统的最新状态展示了令人信服的功能和成熟度。同时，我们也关注这些组件是否以及如何在未来的物理存储系统中发挥作用的问题。
现成的软件缺少重要的高级功能，而且对LHC物理项目至关重要的成本优化硬件的效率证据有限;然而，一个完整的解决方案可以通过在开源产品的基础上分层HEP特定的网关来构建。在本文中，我们描述并评估了一种新的开源集群存储系统CEPFS与EOS的组合，EOS是CERN为LHC数据采集设计的高性能低成本存储解决方案。
CephFS 及其在 CERN 的应用
CephFS 是一个现代集群文件系统，在单个数据中心的典型计算场景中充当 NFS 替代品，包括主目录、HPC 暂存区或其他分布式应用程序的共享存储。该软件为数据和元数据 IOPS 实现了横向扩展架构：数据和元数据被持久保存在分布式对象存储 RADOS ，并且元数据由少量可替换的 MDS 服务器进行管理。
容量和性能可以在不停机的情况下动态增加：通过将服务器添加到 RADOS 后端来扩展原始容量和 IOPS，通过将文件系统子树重新分配给新的 MDS 服务器来扩展元数据。RADOS 使用副本(通常是 3 个副本)或纠错码提供持久对象存储，例如使用四个数据条带和两个奇偶校验条带 (EC4,2)。RADOS 使用 CRUSH 将对象放置在故障域中：通过这种方式，系统可以设计为基于磁盘、主机、机架、电源或交换机级别容忍故障。
CephFS 旨在提供与本地文件系统相同的一致性保证。为了实现这一点，MDS 将一系列 IO 功能委托给客户端，这些功能根据对目录和文件的并行访问的实时需求，授予同步或异步执行不同的 POSIX 操作。例如，由一个没有其他客户端的写入器打开的文件可以通过客户端缓冲快速写入并仅定期持久化，而具有并发写入/读取的文件必须同步持久化，并且不允许客户端缓存其读取。
自 2017 年以来，CERN 在生产中运行了多个 CephFS 集群，截至 2021 年，我们在三种环境中使用 CephFS：
- HPC Scratch使用位于 SLURM 计算节点上的 Ceph OSD 构建的全闪存集群，使用本地空闲节点作为 MDS；3 副本，可用容量约为 110 TiB；
- OpenStack Manila 混合 HDD/SSD 集群，为 IT 和科学应用提供通用共享存储；3 副本，可用容量约为 1 PiB；
- 企业群件：一个全闪存集群，位于 OpenStack 管理程序上，专门为 CERN 社区提供新的集群解决方案；EC2,2 可用容量约为 100 TiB。
在这些环境中，CephFS已在多年的运行中证明了其健壮性和性能。CERN的这些和其他Ceph集群经历了几次外部中断，并经历了三个硬件采购周期：在此期间，我们注意到与数据可用性、丢失或损坏相关的事件很少。
尽管有这些优势，CephFS 目前在 CERN 仅限于之前列出的用例，因为缺少一些对高能物理社区至关重要的功能：
- 身份验证机制和用户/组管理：SciTokens 、X.509、Kerberos、配额和通过 eGroups 进行的访问控制；
- 存储协议和特性：HTTPS、XRootD、第三方拷贝；
此外，CephFS 尚未在 CERN 进行广泛的高吞吐量 LHC 数据采集测试，例如写入速率超过 20GiB/s。
EOS简介
EOS 是 CERN 开发的一个大规模存储系统，目前为物理实验和 CERN 基础设施的普通用户提供 350 PB 的容量。自 2010 年首次部署以来，EOS 已经发展并适应了不断增长的存储容量要求所带来的挑战。
EOS 作为 XRootD 框架的插件实现。文件使用复制或纠错码存储，并使用 QuarkDB 作为持久性后端。前端 MGM 服务提供对命名空间和其他元数据的缓存访问。存储节点运行一个或多个 FST 服务来提供对存储在本地安装的文件系统(FileIO[posix])或远程存储(XrdIo[root protocol]、DavixIo[Webdav/S3])上的数据的访问。对于 Linux 文件系统，文件都被组织为 inode。
MGM 服务将逻辑路径名称转换为 inode，FST 服务器按 inode 名称存储所有数据。本地或远程 FST 文件系统上的命名空间使用简单的 inode 哈希前缀目录和十六进制 inode 名称来组织，以构建给定 inode 编号的物理路径。FST 本地文件系统唯一需要的特性是基本的 POSIX 语义和扩展属性。
因此，用 CephFS 替换本地 FST 文件系统很简单。在这种情况下，通过 FST 访问的数据会使用远程 CephFS 文件系统。在这样的部署模型中，冗余和数据高可用性被委托给 CephFS 层，并且 EOS 被配置为存储具有单副本布局的文件。
系统架构
Ceph 后端存储
后端由八个磁盘服务器构成，每个磁盘服务器具有以下规格：
- 双 Intel Xeon Silver 4216 CPU 和 192 GiB RAM；
- Mellanox ConnectX-5 网络接口支持 100Gb/s 以太网；
- 通过单个 SAS3616 主机总线适配器连接 60 个 14 TB 企业级 SATA HDD；
- 1××1 TB 固态硬盘。
这些高密度磁盘服务器尚未在 CERN 用于生产。目前，EOS 使用具有四个 24 磁盘机箱的服务器，这些机箱连接到具有 192 GiB 内存的前端。由于每个 Ceph OSD 需要大量内存，这些 96 磁盘 EOS 系统需要磁盘集群或额外内存。相反，在我们的 PoC 中评估的高密度服务器是理想的，因为它们为每个 OSD 提供 3 GiB 的内存。
在这个硬件上，我们使用 Octopus 15.2.8 版安装了 Ceph。每台服务器的磁盘都准备好运行 61 个 Ceph OSD：HDD 和 SSD 分别用于托管 CephFS 数据和元数据池。单个非本地磁盘服务器的虚拟机充当集群的 MON、MGR 和 MDS。CephFS 配置了顶级目录，每个目录由不同的 RADOS 池支持，擦除编码和 CRUSH 配置如下：
- /ec42：Reed-Solomon 编码，k = 4，m = 2;每个主机最多有一个对象块；4096 个归置组，每个 OSD 51.2 个；
- /ec82：Reed-Solomon 编码，k = 8，m = 2;每个主机最多有两个对象块；2048 个归置组，每个 OSD 42.6 个；
- /ec162：Reed-Solomon 编码，k = 16，m = 2;每个主机最多有三个对象块；1024 个归置组，每个 OSD 38.4 个。
此外，我们还使用 CephFS 的文件布局扩展属性评估了对象大小对性能的影响。RADOS 放置组被平衡到每个 OSD 的最大偏差。
图一
使用八个运行 Ceph OSD 的后端磁盘服务器(块 1-8)和运行 EOS FST 和 CephFS 内核挂载的八个前端(块 9-16)测试设置。MGM 和 MDS 分别处理 EOS 和 CephFS 的元数据。CephFS 元数据存储在 SSD 上，而数据对象存储在 HDD 上。
EOS 前端服务器
我们使用另外八台相同的机器作为 EOS FST 节点，使用 CentOS 8.2 附带的内核客户端安装 CephFS。对于每个 FST，我们在 CephFS 挂载目录中创建了一个单独的数据目录，并将它们配置为八个 EOS 文件系统。设置如图1所示，而图 图2和图3显示了 EOS 空间和文件系统配置。
图二
八个 CephFS 挂载提供的 ceph 空间的配置：
图三
EOS ceph 空间内 8 个 CephFS 挂载的文件系统配置。
测试和结果
我们执行了两组基准测试来评估 CephFS 后端和 EOS 前端服务的性能：
- 后端直接在客户端内核挂载上使用dd命令，以研究 CephFS 后端的流式传输性能；
- 前端通过 EOS FST使用 XRootD 协议eoscp复制客户端，以研究它们对整体性能的影响。
基准设置
每个基准测试使用每个ceph挂载的 10 个并行流(总共 80 个)来创建/写入或读取每个 2 GB 大小的文件。基准测试通常执行几个小时以观察稳定的运行情况;为了测试性能下降，我们还测试了支持 CephFS 何时填充到 95%。在前端基准测试中，并发流的数量可能会因设计而波动。每个客户端挂载的平均流数再次配置为 10 个。我们还调整了 RADOS 对象大小参数，以提高每个纠删码布局的写入性能。
我们对原始控制器和网络速度进行了基准测试。在最佳负载条件下，两条 IO 路径均达到设计规范 12 GiB/s。此外，我们测量了单个 CephFS 内核客户端的限制;读写速度最高可达 6 GiB/s。图4显示写入吞吐量与客户端数量呈线性关系，直到 8 个客户端节点中有 6 个达到最大集群写入性能。图5同样显示，当足够多的并发工作时，读取吞吐量不受客户端限制：读取扩展以线性方式开始，然后显示一条阻尼曲线，这很可能是由于盘片寻道时间随着并发流的数量而增加。
图四
使用 EC16,2;64M 随客户端节点数量进行写入的性能扩展。写入吞吐量随客户端数量而变化，直到 8 个客户端中有 6 个同时运行：
图五
使用 EC16,2;64M 读取客户端节点数量的性能扩展。读取性能开始线性扩展，但在 3 个并发流以上时衰减。
结果
图6显示了相对写入性能对硬盘卷使用量的依赖性：100% 性能相当于 31 GiB/s。降级与观察到的 OSD 节点上的 IO 等待增加一致。
图六
写入性能与 CephFS 总使用量的相关性。当后端 CephFS 在 0 到 50% 满时达到峰值性能，但超过 75% 的使用率会降低性能。
表1，如图 7和8总结了在空间使用率低于 10% 的情况下测量的各种纠错码布局和对象大小的写入性能。表2，如图 9和10总结了在空间使用率低于 10% 的情况下测量的各种纠删码布局、对象大小和读取块大小的读取性能。两个表都显示了在 8 个客户端节点上运行 80 个并行 dd 命令上传或下载 2 GiB 文件的平均时间。每个基准测试使用 8000 个文件和 16 TiB 的数据量。此外，还显示了标准偏差、平均流率、第 99 个百分位数和 IO 时间的最大值。
很明显，高性能流有利于大块大小。EC16,2 提供最高的写入吞吐量，因为与 EC8,2 或 EC4,2 配置相比，它具有最小的奇偶校验负载;然而，由于对象分布的方差增加，这些大块大小显示出长尾。阅读时块大小的影响更加明显。内核挂载的默认预读设置为 8 MiB;大于此的块大小有助于提高读取吞吐量。对象大小的影响也会在读取时表现出来，因为每提供服务的 GiB 预计会有更多的磁盘寻道。
表 1 各种纠删码布局 (ECk,m) 和对象大小 (; s M) 的写入性能。IO 时间和速率显示为每 2 GiB 文件流和 80 个并发 IO 流：
图七
写入性能尾部：红线显示平均上传时间，方框限制显示 99 个百分位数，错误限制显示给定纠删码布局观察到的最大上传时间。基于表1中的数据：
图八
基于表1中的数据，各种纠删码布局的平均写入流速度和标准偏差。
表2各种纠删码布局 (ECk,m)、对象大小 (; s M) 和dd blocksize (, b M)的读取性能测量：
IO时间和速率显示为每2 GiB文件流80个并行流。使用默认的内核预读设置8 MiB。
图九
读取性能尾部：红线显示平均下载时间，框限制显示 99 个百分位数，错误限制为给定纠删码布局观察到的最大下载时间。基于表2中的数据。
图十
基于表2中数据的各种纠删码布局的平均读取流速度和标准偏差。
图11中可视化的表3显示了通过 EOS 作为前端服务访问 CephFS 的影响。整体性能没有变化，但由于写入时流调度不公平，XRootD 协议的使用增加了尾部效应。这些尾部效应可以通过将每个流限制到标称 325/350 MiB/s 客户端来消除。读取性能实际上受益于前端，因为 EOS 传输中使用的块大小大于原生 CephFS 后端的基线比较。
表3 原生 CephFS 后端性能和通过 EOS 前端服务访问的比较，用于各种纠删码布局 (ECk,m)、对象大小 (; s M) 和 IO 块大小 (, b M)：
使用EOSaa 和 EOSbb，我们分别将客户端限制为325 MiB/s和350 MiB/s。
图十一
根据表3中的数据可视化将 EOS 前端添加到 CephFS 后端的影响。
调整 Ceph
在我们的性能评估过程中，我们遇到了几个问题，默认 Ceph 配置和警告并不理想：
客户端限制传输中的字节默认情况下，librados 客户端将运行中写入的数量限制为 100MiB。我们观察到经常会达到这个限制，从而限制了可实现的写入性能。将objecter_inflight_op_bytes设置为10485760000消除了这种人为限制。
MDS caps回调调整EOS fsck过程用于检查EOS命名空间与后端CEPFS存储的一致性。这一过程对MDS持续施加压力，要求其尽快统计所有文件，这可能会导致这样一种情况，即客户获取CAP的速度比MDS要求召回的速度更快，从而导致MDS出现内存不足错误。改进了默认上限召回设置，有效地将上限授予/召回率提高了5倍以上，并得到了上游社区的建议和接受。此外，EOS fsck现在可以被限制，以便在可配置的时间间隔内扫描名称空间。
单个高延迟 OSD 造成了严重影响： 在我们的测试中，集群范围的写入性能从标称的 25 GiB/s 下降到 5 GiB/s 以下。故障排除后发现是单个 HDD 的物理 SATA 连接不佳，最小 IO 请求平均耗时超过 2 秒 。一旦从集群中移除该磁盘，预期的性能就会恢复。此类问题以前在 CERN 的生产中从未见过。由于 Ceph 目前没有检测到此类问题并发出警告，因此我们目前正在开发一个外部探针，该探针会在检测到异常 OSD 延迟时发出警告，如果证明有用，将向上游提供。
结论与讨论
经过评估的基于高密度磁盘服务器的设置在各种擦除编码方案下提供了优异的性能，并允许每个节点为流式访问提供高达4 GiB/s的读写数据负载。在规划服务时，必须考虑到随着 CephFS 使用量的增加而导致的性能大幅下降，而在硬件故障期间不存在操作风险的安全最大可用空间阈值需要更多的实际经验。我们已经测试了使用upmap数据平衡将备份CEPFS填充到高达95%的空间，以实现统一的磁盘利用率。
在接近网络连接极限时执行的纠错码写入性能;CPU 和磁盘在这些峰值吞吐量下均未饱和。读的瓶颈更明显;它们很可能由磁盘盘片寻道延迟控制。CephFS 纠错码IO模型的读写通信量大致翻了一番。在使用大数据块进行写测试时，单个节点上的网络输入达到令人印象深刻的 9 GiB/s，而传出流量为5 GiB/s，磁盘输出为5 GiB/s。
要利用每台服务器的总可用磁盘IO带宽(10 GiB/s)，必须将网络连接增加一倍。此外，除了报告的结果，我们还调查了并发读写用例。CephFS 优先考虑写入的可用带宽，留给读剩余的带宽;writer-preferred IO调度确实是大多数用例的理想行为。
EOS 前端对整体 IO 性能的影响很小。应该针对 XRootD 服务器内部的不平衡流调度实现来调查写入时增加的尾部。
从理论上讲，可以将 EOS FST 和 Ceph OSD 放在同一台服务器上，但是这需要在 OSD 节点上安装 CephFS：如果出现内存压力，这种安装会导致内核死锁。超聚合存储/网关模型需要在高负载情况下进行一些额外的测试。
CEPFS+EOS 混合设置是将 CephFS 的高性能并行 IO 功能与 EOS 提供的高级功能相结合的简单方法。这包括强大的安全性、使用 XRootD 和 HTTP(S)协议的高效 WAN 访问、扩展配额和权限管理、第三方传输、令牌授权、校验和支持、可选磁带后端等。
在设计采用 100Gig-E 技术的混合服务时，必须特别注意后端 OSD 中的网络，以及每个前端节点的IO限制。我们设法用一个带有一个CephFS内核挂载的单网关FST最多写4.5 GiB/s，读6 GiB/s。在 CERN 的 LHC 存储使用中，我们观察到典型的 10:1 读取与写入比率。因此，在 CephFS 可以以开放访问方式挂载以在客户端节点上读取的情况下，将重定向到本地功能添加到 EOS 可能是一个有趣的选项。
本地重定向可能取决于每个目录的权限设置。CephFS 挂载本身也可以在 XRootD 插件内根据包含所需 CephFS 只读挂载的 cephx 身份验证密钥的重定向响应触发。当文件访问稀疏时，网关 FST 模型提供了一个额外的缓存层来将客户端稀疏访问转换为流式后端流量。这需要适当调整 CephFS 装载预读设置。
所提出的服务模型允许在单个管理域后面将多个具有独立故障域和不同服务质量的独立 CephFS 设置集群化。它使运营商能够使用 EOS 管理工具和第三方传输在 CephFS 系统之间从旧后端到新后端进行透明的硬件迁移，而不会中断生产使用。
我们已经为IO流操作验证了此设置。稀疏物理分析用例的可用性将是验证的下一步。此外，经过几个填充/删除周期老化后的预期碎片惩罚尚未评估。我们演示了 CephFS 可以用于高吞吐量流式 IO，而无需为 BlueStore 元数据block.db指定 SSD。运行大容量服务器的主要要求是每个OSD(HDD)至少提供3 GiB的内存。
总之，CephFS + EOS 是一个可行的解决方案，它以非常简单的方式结合了 Ceph 的对象存储概念和 EOS 的高级服务功能。我们需要综合平衡复杂性和服务成本以及带来的好处。
原文：https://link.springer.com/article/10.1007/s41781-021-00071-1
作者：祝祥
资深云计算架构师，OpenStack官方特邀讲师。上万台云主机和几十PB分布式存储的建设管理经验。
