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