CephFS和GlusterFS

作为云平台开发团队的基础架构工程师，我有机会使用许多分布式存储系统，包括标题中指示的那些。 似乎对他们的优缺点有所了解，我将尽力与您分享关于该主题的想法。 可以这么说，让我们看看谁拥有哈希函数的时间更长。

免责声明：在此博客的前面，您可以看到有关GlusterFS的文章。 我与这些文章无关。 这是我们云项目团队的作者博客，每个成员都可以讲述他们的故事。 这些文章的作者是我们运营团队的工程师，他分享了自己的任务和经验。 如果您突然发现意见分歧，请考虑到这一点。 我借此机会向那些文章的作者表达我的问候！

将讨论什么

让我们谈谈可以基于GlusterFS和CephFS构建的文件系统。 我们将讨论这两个系统的体系结构，以不同的角度来看它们，最后我什至要冒任何结论的风险。 其他Ceph功能，如RBD和RGW，将不受影响。

术语学

为了使本文完整并为所有人所理解，让我们看一下两个系统的基本术语：

Ceph术语：

RADOS （可靠的自治分布式对象存储）是一个独立的对象存储，它是Ceph项目的基础。
CephFS ， RBD （RADOS块设备）， RGW （RADOS网关）-用于RADOS的高级小工具，可为最终用户提供与RADOS的各种接口。
具体来说，CephFS提供了POSIX兼容的文件系统接口。 实际上，CephFS数据存储在RADOS中。
OSD （对象存储守护程序）是在RADOS群集中为单独的磁盘/对象存储提供服务的进程。
RADOS池 （池）-由一组通用规则（例如复制策略）组合在一起的多个OSD 。 从数据层次结构的角度来看，池是对象的目录或单独的名称空间（平坦的，没有子目录）。
PG （展示位置小组）-我将在稍后的背景中介绍PG的概念，以使您更好地理解。

由于RADOS是构建CephFS的基础，因此我经常会谈论它，这将自动应用于CephFS。

GlusterFS术语（以下简称gl）：

Brick是一个服务于单个磁盘的进程，在RADOS术语中类似于OSD。
体积 -砖合并成的体积。 Tom是RADOS中的一个池类似物，它在砖之间也具有特定的复制拓扑。

资料分配

为了更加清楚，请考虑一个可以由两个系统实现的简单示例。

以设置为例：

• 2个服务器（S1，S2），每个服务器中有3个等容量的磁盘（sda，sdb，sdc）；
• 具有复制功能的卷/池2。

这两个系统至少需要3台服务器才能正常运行。 但是我们对此视而不见，因为这只是文章的一个示例。

在gl的情况下，这将是一个由3个复制组组成的Distributed-Replicated卷：

每个复制组是不同服务器上的两个模块。
实际上，事实证明，结合了三个RAID-1的卷。
挂载它时，获取所需的文件系统并开始向其中写入文件，您会发现写入的每个文件总体上属于这些复制组之一。
这些分布式组之间的文件分配由DHT （分布式哈希表）处理， DHT本质上是一个哈希函数（我们稍后会再讨论）。

在“关系图”上将如下所示：

好像第一个体系结构特征已经显现：

• 成组放置不均，取决于文件大小；
• 写入一个文件时，IO仅进入一组，其余则处于空闲状态；
• 写入单个文件时，您无法获取整个卷的IO；
• 如果该组中没有足够的空间来写入文件，则会出现错误，该文件将不会被写入，也不会重新分配给另一个组。

如果使用其他类型的卷，例如Distributed-Striped-Replicated甚至Dispersed（擦除编码），则只有在一组内分发数据的机制会发生根本变化。 DHT还将文件完全分解为这些组，最终，我们将遇到所有相同的问题。 是的，如果该卷仅由一个组组成，或者如果您拥有的所有文件大小都大致相同，则不会有问题。 但是，我们所谈论的是普通系统，其数据包括数百兆字节的数据，包括大小不同的文件，因此我们认为存在问题。

现在让我们看一下CephFS。 上面提到的RADOS进入了场景。 在RADOS中，每个磁盘由一个单独的进程-OSD提供服务。 根据我们的设置，我们只能得到其中的6个，每台服务器3个。 接下来，我们需要为数据创建一个池，并在该池中设置PG的数量和数据复制因子-在我们的示例2中。
假设我们创建了一个8 PG的池。 这些PG将大致均匀地分布在OSD上：

现在该阐明PG是结合了许多对象的逻辑组。 由于我们设置了复制事实2，因此每个PG在另一台服务器上的其他OSD上都有一个副本（默认情况下）。 例如，服务器S1上OSD-1上的PG1在OSD-6上S2上有一个双胞胎。 在每对PG中（如果复制3，则为三对）是正在记录的PRIMARY PG。 例如，PG4的PRIMARY位于S1上，而PG3的PRIMARY位于S2上。

现在您知道了RADOS的工作原理，我们可以继续将文件写入新的池中。 尽管RADOS是完整的存储，但是无法将其作为文件系统挂载或用作块设备。 要直接向其中写入数据，您需要使用特殊的实用程序或库。

我们编写与上面的示例相同的三个文件：

同意RADOS的情况，一切都变得更加复杂。

然后CRUSH（可伸缩散列下的受控复制）出现在链中。 CRUSH是RADOS依赖的算法（我们稍后会再讨论）。 在这种特定情况下，使用此算法，可以确定文件应写入哪个PG。 在这里，CRUSH执行与gl中的DHT相同的功能。 由于PG上文件的这种伪随机分布，我们只在一个更复杂的方案上遇到了与gl相同的所有问题。

但是我特意对一个重要点保持沉默。 几乎没有人使用RADOS的纯形式。 为了方便使用RADOS，开发了以下层：RBD，CephFS，RGW，我已经提到过。

所有这些翻译器（RADOS客户端）提供了不同的客户端界面，但是它们与RADOS的工作相似。 最重要的相似之处是，将通过它们的所有数据切成小块，并作为单独的RADOS对象放入RADOS。 默认情况下，官方客户将输入流切成4MB的片段。 对于RBD，可以在创建卷时设置条带大小。 对于CephFS，这是文件的属性（xattr），可以在单个文件级别或所有目录文件级别进行管理。 嗯，RGW也有一个对应的参数。

现在，假设我们将CephFS堆在上一个示例中介绍的RADOS池上。 现在，所讨论的系统完全平等，并提供相同的文件访问界面。

如果将测试文件写回到全新的CephFS，我们将在OSD上发现完全不同，几乎统一的数据分布。 例如，将2GB大小的file2分为512个片段，这些片段将分布在不同的PG之间，结果，几乎均匀地分布在不同的OSD之间，这实际上解决了上述数据分布的问题。

在我们的示例中，虽然建议在一个OSD上使用〜100 PG，但仅使用8 PG。 而且，您需要2个池才能使CephFS正常工作，还需要一些服务守护程序才能使RADOS正常工作。 不要以为一切都那么简单，我特意省略了很多，以免背离本质。

所以现在CephFS似乎更有趣了，对吧？ 但是我没有提到另一个要点，这次是关于gl。 GL还具有一种将文件切成块并通过DHT运行这些块的机制。 所谓分片（ Sharding ）。

五分钟的历史

2016年4月21日，Ceph开发团队发布了“ Jewel”，这是CephFS稳定的首个Ceph版本。

现在这一切都是关于CephFS的左右喊！ 3-4年前使用它至少是一个可疑的决定。 我们正在寻找其他解决方案，并且对上述架构的不满意。 但是我们比CephFS更相信它，并等待分片，而分片正在为发布做准备。

这是X天：

2015年6月4日-Gluster社区今天宣布GlusterFS 3.7开放软件定义存储软件的全面上市。

3.7-gl的第一个版本，其中分片被宣布为实验性机会。 为了稳定登上领奖台，他们距离CephFS的稳定发布已经快一年了。

因此分片意味着。 像gl中的所有内容一样，这是在单独的转换器中实现的，该转换器位于堆栈上DHT（也称为转换器）的上方。 由于它比DHT高，因此DHT在输入处接收现成的碎片，并将它们作为常规文件分布在复制组中。 在各个卷级别启用分片。 可以默认设置碎片的大小-4MB，就像Ceph乳液一样。

当我进行第一次测试时，我很高兴！ 我告诉所有人，gl现在是头等大事，现在我们将生活！ 启用分片后，一个文件的记录并行于不同的复制组。 “写”压缩之后的解压缩可以递增到分片级别。 同样，如果在这里进行缓存射击，一切都会变得很好，并且将单独的碎片移到缓存中，而不是整个文件中。 总的来说，我很高兴，因为 看来他手中有一把很酷的乐器。

等待最初的错误修正和“准备生产”状态仍然是它。 但是，结果似乎并不那么乐观。为了不让本文中出现与分片有关的关键错误列表，这些问题在下一个版本中会不时出现，我只能说最后一个“主要问题”，并带有以下描述：

扩展分片的gluster卷可能会导致文件损坏。 分片的卷通常用于VM映像，如果此类卷被扩展或可能收缩（即添加/删除砖块和重新平衡），则有VM映像损坏的报告。

已在2018年1月20日的版本3.13.2中关闭...也许这不是最后一个？

可以这么说，第一篇关于我们的文章的评论 。

RedHat在其有关当前RedHat Gluster Storage 3.4的文档中指出，它们支持的唯一分片情况是存储VM磁盘。

分片有一个受支持的用例：在提供Red Hat Gluster Storage作为Red Hat Enterprise Virtualization的存储域的上下文中，为实时虚拟机映像提供存储。 注意，分片也是该用例的要求，因为与以前的实现相比，分片提供了显着的性能改进。

我不知道为什么会有这样的限制，但您必须承认，这令人震惊。

现在我在这里为您准备了一切

两种系统都使用哈希函数在磁盘之间伪随机地分配数据。

对于RADOS，它看起来像这样：

PG = pool_id + "." + jenkins_hash(object_name) % pg_coun # eg pool id=5 => pg = 5.1f OSD = crush_hash_based_on_jenkins(PG) # eg pg=5.1f => OSD = 12 

GL使用所谓的一致性哈希 。 每个砖块都有一个“ 32位哈希空间内的范围”。 也就是说，所有积木共享整个线性地址哈希空间，而不会相交范围或空洞。 客户端通过哈希函数运行文件名，然后确定接收到的哈希属于哪个哈希范围。 因此选择了砖。 如果复制组中有多个块，那么它们都具有相同的哈希范围。 像这样：

如果将两个系统的工作以某种逻辑形式进行，结果将是这样的：

 file -> HASH -> placement_unit 

其中对于RADOS，placement_unit是PG；对于gl，则是几个砖的复制组。

因此，使用一个哈希函数，然后该哈希函数分发，分发文件，然后突然发现，一个placement_unit的利用率高于另一个。 这是哈希分配系统的基本特征。 我们面临一个非常普通的任务-平衡数据。

GL具有重建的能力，但是由于具有上述哈希范围的体系结构，您可以根据需要运行任意数量的重建，但是哈希范围（因此，数据）将不会发生变化。 重新分配哈希范围的唯一标准是卷容量的变化。 您还有一个选择-添加积木。 而且，如果我们谈论的是带有复制的卷，那么我们必须添加一个完整的复制组，即在我们的设置中添加了两个新的模块。 扩展卷后，您可以开始重建-将考虑新组的情况重新分配哈希范围，并分配数据。 删除复制组后，将自动分配哈希范围。

RADOS具有无限的可能性。 在Ceph的文章中 ，我对PG的概念抱怨很多，但是在这里，与gl相比，当然是骑马的RADOS。 每个OSD都有自己的权重，通常是根据磁盘的大小来设置的。 依次由OSD根据PG的权重分配PG。 一切，然后我们只需向上或向下更改OSD的权重，PG（以及数据）便开始移至其他OSD。 另外，每个OSD都有一个附加的调整权重，使您可以在一个服务器的磁盘之间平衡数据。 所有这些都是CRUSH中固有的。 主要优点是不必为了更好地平衡数据而扩展池容量。 并且不必成组添加磁盘，您只能添加一个OSD，并且一部分PG将被传输到其中。

是的，有可能在创建一个池时它们没有创建足够的PG，事实证明每个PG的体积都很大，无论它们移动到哪里，都将保持不平衡。 在这种情况下，您可以增加PG的数量，并将它们分成较小的PG。 是的，如果集群中充满了数据，那么它会很痛苦，但是我们进行比较时最主要的是有这样的机会。 现在只允许增加PG的数量，对此您需要格外小心，但是在下一个Ceph-Nautilus版本中，将支持减少PG的数量（pg合并）。

资料复制

我们的测试池和卷的复制因子为2。有趣的是，所讨论的系统使用不同的方法来实现此数量的副本。

对于RADOS，记录方案如下所示：

客户端知道整个集群的拓扑，使用CRUSH（步骤0）选择要写入的特定PG，在OSD-0上写入PRIMARY PG（步骤1），然后OSD-0将数据同步复制到SECONDARY PG（步骤2），并且只有在成功/不成功的步骤2，OSD向客户端确认/不确认操作（步骤3）。 两个OSD之间的数据复制对客户端是透明的。 OSD通常可以使用单独的“集群”，更快的网络进行数据复制。

如果配置了三重复制，那么它也将与两个SECONDARY上的PRIMARY OSD同步运行，这对客户端是透明的……好吧，只有这样的情况才高。

GL的工作方式有所不同：

客户端知道该卷的拓扑，使用DHT（步骤0）确定所需的砖，然后对其进行写入（步骤1）。 一切都简单明了。 但是在这里我们记得复制组中的所有砖块都具有相同的哈希范围。 这个小功能使整个假期变得更加轻松。 客户端并行写入具有合适哈希范围的所有砖块。

在我们的情况下，使用双重复制，客户端将在两个不同的模块上并行执行双重记录。 在三重复制期间，将分别执行三重记录，并且从客户端到gl服务器端的1MB数据将大致变成3MB的网络流量。 同意，系统的概念是垂直的。

在这样的方案中，将更多的工作分配给gl客户端，结果，他需要更多的CPU，好吧，我已经说过网络了。

复制由AFP转换程序（自动文件复制）完成-执行同步复制的客户端xlator。 复制到副本的所有块的写入→使用事务模型。

如有必要，可以同步组中的副本（进行修复）（例如，修复），例如在暂时无法使用一个砖块之后，gl守护进程可以使用内置的AFP自行执行此操作，对客户端透明，并且无需客户端参与。

有趣的是，如果您不是通过本地gl客户端来工作，而是通过gl中的内置NFS服务器进行写操作，那么我们将获得与RADOS相同的行为。 在这种情况下，将在gl守护程序中使用AFP复制数据，而无需客户端干预。 但是内置的NFS在gl v4中是受保护的，如果您想要这种行为，建议使用NFS-Ganesha。

顺便说一句，由于在使用NFS和本机客户端时行为不同，因此可以看到完全不同的性能指标。

您是否具有相同的集群，只是“在膝盖上”？

我经常在Internet上看到各种膝关节设置的讨论，其中的数据集群是根据手头上的内容构建的。 在这种情况下，基于RADOS的解决方案可以为您提供更多选择驱动器的自由。 在RADOS中，您可以添加几乎任何大小的驱动器。 每个磁盘的重量通常对应于其大小，并且数据将几乎按其重量成比例地分布在磁盘上。 在gl的情况下，复制卷中没有“分离磁盘”的概念。 磁盘以两次复制成对添加，或以三次复制成三倍添加。 如果一个复制组中有不同大小的磁盘，则您将遇到该组中最小磁盘的位置，并取消部署大型磁盘的容量。 在这种方案中，gl将假定一个复制组的容量等于该组中最小磁盘的容量，这是合乎逻辑的。 同时，允许具有由不同大小的磁盘组成的复制组-不同大小的组。 相对于其他组，较大的组可以接收更大的哈希范围，因此，可以接收更多数据。

我们已经与Ceph一起生活了五年。 我们从相同容量的磁盘开始，现在介绍更多容量的磁盘。 使用Ceph，您可以删除磁盘并将其替换为另一个更大或更小的磁盘，而没有任何架构上的困难。 使用gl，一切都变得更加复杂-取出了2 TB磁盘-请放同一个磁盘。 好吧，还是撤出整个小组，这不是很好，对此表示同意。

故障转移

我们已经对这两个解决方案的体系结构有所了解，现在我们可以讨论如何使用它以及维修时的功能。

假设我们拒绝了s1上的sda-这很常见。

在gl的情况下：

• 组中剩余的活动磁盘上的数据副本不会自动重新分发给其他组；
• 在更换磁盘之前，仅保留一份数据副本；
• 用新磁盘替换发生故障的磁盘时，将从工作磁盘复制到新磁盘（1对1）。

这就像为具有多个RAID-1的机架服务一样。 是的，在三重复制的情况下，如果一个驱动器发生故障，则不会保留一个副本，而是保留两个副本，但是这种方法仍然存在严重的缺陷，我将以RADOS为例向他们展示。

假设我们在S1（OSD-0）上的sda失败-常见的事情：

• 10分钟后（默认），OSD-0上的PG将自动重新映射到其他OSD。 在我们的示例中，在OSD 1和2上。如果有更多服务器，则在更大数量的OSD上。
• 存储数据的第二个幸存副本的PG将自动将它们复制到转移了还原PG的OSD。 事实证明，是多对多复制，而不是像gl这样的一对一复制。
• 当引入新磁盘而不是损坏的磁盘时，将根据其在新OSD中的权重来累积一些PG，并将重新分配来自其他OSD的数据。

我认为解释RADOS的体系结构优势没有任何意义。 当您收到一封信说驱动器发生故障时，您不能抽搐。 当您早上上班时，发现所有丢失的副本已经还原到数十个其他OSD中或正在还原中。 在大型群集中，数百个PG分布在一堆磁盘上，由于涉及数十个OSD（读取和写入），因此一个OSD的数据恢复速度可能比一个磁盘的速度高得多。 好吧，您也不应该忘记负载平衡。

缩放比例

在这种情况下，我可能会介绍一下基座。 在有关Ceph的文章中，我已经写过与PG概念相关的RADOS缩放的一些复杂性。 如果随着集群的增长，PG的增长仍然可以经历，那么关于Ceph MDS的情况还不清楚。 CephFS在RADOS之上运行，并使用一个单独的池来存储元数据和一个特殊的进程ceph元数据服务器（MDS），用于服务文件系统元数据并与FS协调所有操作。 我并不是说拥有MDS可以终结CephFS的可扩展性，不是，尤其是因为您可以在主动-主动模式下运行多个MDS。 我只想指出，gl在架构上没有这一切。 它没有PG副本，没有MDS。 只需通过几乎线性地添加复制组，Gl即可实现完美的伸缩。

在CephFS之前的日子里，我们为数据PB设计了解决方案，并研究了gl。 然后我们对gl的可扩展性表示怀疑，并通过邮件列表找到了。 这是答案之一（问：我的问题）：

我正在使用60台服务器，每台服务器具有26x8TB磁盘，总共1560磁盘16 + 4 EC卷，具有9PB的可用空间。

问：您是否在客户端使用libgfapi或FUSE或NFS？

我使用FUSE，我有近1000个客户端。

问：卷中有多少个文件？
问：文件更大或更小？

我有超过1M个文件，并且使用了群集的13％，这使平均文件大小为1GB。
最小/最大文件大小为100MB / 2GB。 每天有10-20TB的新数据进入该卷。

问：“ ls”的运行速度有多快？

如您所料，元数据操作很慢。 我尽量不要在目录中放置超过2-3K的文件。 我的用例是备份/存档，因此我很少进行元数据操作。

重命名文件

再次回到哈希函数。 我们已经弄清楚了如何将特定文件路由到特定磁盘，现在这个问题变得很重要了，但是重命名文件时会发生什么？

毕竟，如果我们更改文件名，则代表它的哈希也将发生变化，这意味着该文件在另一个磁盘上（在不同哈希范围内）或在RADOS情况下在另一个PG / OSD上的位置。 是的，我们的想法正确，在这两个系统中，一切都再次垂直。

在gl的情况下，重命名文件时，将通过哈希函数运行新名称，定义新的砖，并在其上创建指向旧砖的特殊链接，文件将像以前一样保留在那里。 托波夫卡，对吗？ 为了使数据真正移动到新位置，并且客户端没有不必要地单击链接，您需要进行重新设置。

但是RADOS通常没有仅仅因为需要随后移动对象而重命名对象的方法。 建议使用公平复制进行重命名，这会导致对象的同步移动。 而运行在RADOS之上的CephFS，则以存储元数据和MDS的池的形式拥有一张王牌。 更改文件名不会影响数据池中文件的内容。

复制2.5

GL具有一个非常酷的功能，我想单独提及。 每个人都知道复制2不是可靠的配置，但是定期进行复制是有道理的。 为了防止在此类方案中出现裂脑并确保数据一致性，gl允许您使用副本2和附加仲裁器来构建卷。 仲裁程序适用于3个或更多的复制。 这是与其他两个组相同的块，只有它实际上仅根据文件和目录创建文件结构。 这样的积木上的文件大小为零，但是它们在文件系统中的扩展属性（扩展属性）与同一副本中的全尺寸文件保持同步状态。 我认为这个主意很明确。 我认为这是一个不错的机会。

唯一的时刻...复制组中该位置的大小由最小块的大小确定，这意味着仲裁者需要滑动至少与该组中其他磁盘大小相同的磁盘。 为此，建议创建虚拟的瘦（薄）LV大尺寸，以免使用实际磁盘。

那客户呢？

这两个系统的本机API以libgfapi（gl）和libcephfs（CephFS）库的形式实现。 也提供流行语言的绑定。 通常，对于库，一切都差不多。 无处不在的NFS-Ganesha将这两个库都作为FSAL支持，这也是规范。 Qemu还通过libgfapi支持本机gl API。

但是fio（Flexible I / O Tester）长期以来已经成功支持libgfapi，但它不支持libcephfs。 这是一个加号，因为 使用fio直接测试gl非常好。 只有从用户空间通过libgfapi进行工作，您才能从gl获得gl的一切。

但是，如果我们谈论的是POSIX文件系统以及如何安装它，那么gl只能在上游内核中提供FUSE客户端和CephFS实现。 显然，在内核模块中，您可以做一些技巧，使FUSE表现出更好的性能。 但是实际上，FUSE始终是上下文切换的开销。 我个人不止一次地看到FUSE如何单独使用CS弯曲双路服务器。
莱纳斯以某种方式说：

用户空间文件系统？ 问题就在那里。 一向如此。 那些认为用户空间文件系统除了玩具以外的任何东西都是现实的人被误导了。

相反，GL开发人员认为FUSE很酷。 据说这可以提供更大的灵活性，并且可以脱离内核版本。 对于我来说，他们使用FUSE是因为gl与速度无关。 它以某种方式编写-很好，这很正常，而困扰内核中的实现确实很奇怪。

性能表现

将不会有任何比较）。

这太复杂了。 即使采用相同的设置，也很难进行客观的测试。 无论如何，评论中会有人提供100500个参数，这些参数“加速”了其中一个系统，并说这些测试是胡说八道。 因此，如果有兴趣，请自我测试。

结论

特别是在理解，设置和维护方面，RADOS和CephFS都是更复杂的解决方案。

但就我个人而言，我更喜欢RADOS的体系结构，并且比GlusterFS更能在CephFS之上运行。 我认为，更多的句柄（PG，OSD权重，CRUSH层次结构等），CephFS元数据增加了复杂性，但提供了更大的灵活性并使此解决方案更有效。

Ceph更适合当前的SDS标准，在我看来似乎更有希望。 但这是我的看法，您怎么看？