分布式文件系统设计综述

ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月→→→$分布式文件系统设计选择综述PeterMacko和JASON HENNESSEY，Inc.，美国对分布式文件系统和存储系统的研究已经有几十年了 新的研究人员和工程师有大量的文献可供研究，但在创建分布式文件系统时，只有相对较少的高级设计选择可用。在系统的每个方面，通常使用几种常见的方法因此，本文并不对分布式文件系统进行调查，而是对重要的设计决策以及这些决策中最常用的选项进行它还提出了一个定性的探索他们的权衡。我们包括几个相对较新的设计和它们的变化，说明在设计空间中的其他权衡选择，尽管正在探索。在此过程中，我们提供了分布式文件系统的入门知识，并展示了过度探索和未充分探索的领域，希望能激发新的研究。CCS概念：·信息系统分布式存储;存储管理;·计算机系统组织分布式体系结构;·软件及其工程文件系统管理;分布式系统组织原则;云计算其他关键词和短语：分布式文件系统，分布式存储，设计选项，分类法，调查4ACM参考格式：彼得·马科和杰森·亨尼西。2022年分布式文件系统设计选择概览ACM Trans. 18岁，1，第4条（2022年2月），34页。https://doi.org/10.1145/34654051介绍恭喜您，您刚刚被要求设计下一个分布式文件系统。 但是你应该怎么做呢？您可以找到数十年来对分布式文件系统和对象存储的研究 随着世界继续从纵向扩展转向横向扩展解决方案，以及人们越来越希望跨多个存储端点提供数据管理，而不是将它们视为孤立的孤岛，研究的步伐正在加快。有太多的研究和生产系统需要学习和借鉴。 但是，在设计分布式文件系统的各个方面时，可用的高级设计选项要少得多，并且这些选项中的每一个都会导致不同的权衡。例如，将分布在多个服务器上的文件系统命名空间拼接在一起的高级方法只有这么多，这会影响系统的性能及其分配负载或处理分区的能力。在本文中，我们确定了几个关键的设计决策，作者Macko和J.Hennessey，Inc.，1601 Trapelo Rd.，Waltham，Massachusetts 02451;电子邮件：{peter.macko，jason.hennessey}@ netapp.com。本作品采用知识共享署名-非商业性使用国际4.0许可协议进行许可。© 2022版权归所有者/作者所有1553-3077/2022/02-ART4https://doi.org/10.1145/3465405ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月四：2P. Macko和J. 亨尼西审查最常用的选项及其一些变体，并对相关权衡进行定性分析定量评价超出了这项工作的范围当涉及到设计新的分布式文件系统、定义新的研究项目或出于任何其他原因了解这些文件系统时，重要的是要了解这些选择及其含义。现有的设计中没有一个明显是最适合每种情况的，因此文件系统设计人员应该了解各种选项，并仔细选择最适合要求的选项，例如读写性能，一致性，分区容差和冗余性。 新的研究人员也应该很好地意识到这个设计空间，这样他们就可以把精力集中在未开发的领域或消除现有技术的不良属性上，而不是简单地设计一个新的文件系统。我们的目的是不提出一个详尽的调查所有相关文献，而只是专注于高层次的方法来设计分布式文件系统堆栈的三个关键部分的选项：定位一个inode（或等效）给定的路径，定位数据给定的inode，并选择各种一致性和同步选项，这可以是有一些限制的混合和匹配。尽管我们并不声称要探索所有的设计选择和权衡，但我们的目标是调查最重要的。 我们只在相关的地方提到具体的系统和规范，并从新旧系统、学术界和工业界中汲取实例。 我们不打算列出或检查历史上所有重要的分布式文件系统，其中一个很好的探索起点包括以前对分布式文件系统的调查[56，67]，以及对对等文件系统[22]和分布式文件系统中的分散访问控制[39]的特定主题调查。为了达到本文的目的--这样我们就可以获得更多有趣的设计选项--我们将分布式文件系统定义为跨多个节点存储文件并支持读、写、创建、查找和列出目录等基本操作的系统我们通常还假设一个分层的名称空间，不管它是有一个根还是多个根。许多设计选项也适用于分布式对象存储，它与分布式文件系统有几个共同的要求和约束。在第2节中描述了一个高级的、典型的文件系统架构之后，我们将在第3节中调查文件系统中使用的常见指针类型，例如从目录条目指向inode或从inode指向数据的指针。然后，第4、5和6节将介绍文件系统设计的关键部分：在给定路径的情况下定位inode，在给定inode的情况下定位数据，以及选择处理协调和确保文件系统一致性的最后，我们在第7节中介绍了几个案例研究和一个设计练习。 在案例研究中，我们通过这些设计选择的角度来研究几种已知文件系统的权衡或特征。然后，我们使用这些权衡来设计一个假设的文件系统。我们在第8节结束。2在加密文件系统中在一个非常抽象的层次上，分布式文件系统就像任何其他存储系统一样将路径名映射到数据，以便它可以执行读取和更新。然而，其分布式性质使得更难以协调所有节点上的操作，并且更难以确保系统的足够冗余以充分容忍节点故障，并且如果适用的话，也更难以容忍网络分区。此外，使用分布式文件系统技术在扩展本地文件系统的性能时可能是有利的[28]，即使系统的挑战集较小;例如，我们不会期望在不同核心上运行的文件系统进程之间的网络分区。图1是一个分布式文件系统架构（不是任何特定的文件系统）的示例，它来自几个系统的混搭，出于教学目的，说明了几个重要的概念，包括：分布式文件系统设计选择综述四：3ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月图1. 分布式文件系统架构数据路径的示例，说明路径到inode转换，然后是inode到数据转换。指针类型：分布式文件系统使用不同类型的指针来引用元数据和数据。例如，此图中inode中的块位置列表使用显式间接指针类型，因为inode仅存储卷ID和块编号，需要查阅外部卷到节点映射来确定实际位置。数据和元数据管理粒度：数据和元数据在不同级别以不同粒度进行管理。图1示出了通过子树（即，子树粒度），同时允许文件的不同部分物理地存储在不同节点上（即，子文件粒度）。我们将在第3节中更详细地讨论指针类型和粒度。而且，在高层次上，我们可以将数据路径分为两部分：路径到inode的转换：从路径名开始，系统如何定位文件或目录的inode，其中包含其关键元数据，如数据的位置？图1中的示例文件系统使用前缀表（4.3节）来确定哪个元数据服务器存储名称空间的哪个部分。inode到数据的转换：从inode开始，系统如何定位数据？ 在本例中，inode以子文件粒度引用数据，指针指定卷ID和卷内的偏移量。然后，卷ID被转换为节点ID。我们将在第4节和第5节分别讨论文件系统堆栈的上述层的各种选项····四：4P. Macko和J. 亨尼西ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月表1.指针类型TypeNetwork HopsExamplesLocal0Inode to data in AFS [25]libp2p中的显式、直接1多地址[ 34 ]显式、间接1FlexGroup卷中的远程链接[30]计算（隐式）1CephFS [73]，GlusterFS中的分布式卷[21]Overlay networkO（logn） IPFS中inode的名称[9]与本地文件系统不同，分布式文件系统还必须做出额外的设计选择：冗余和协调：系统如何确保有足够的冗余（无论是复制还是擦除编码）来处理故障，以及如何协调所有这些副本和/或擦除编码片段的访问和更新？我们将在第6节中讨论分布式系统设计的这些方面。出于本文的目的，我们互换使用术语节点和服务器来指代托管文件系统的一部分（如其数据、元数据或两者）的节点文件系统客户端通过标准协议（如NFS）、客户端库或代理向一个或多个服务器发送请求来访问文件系统。客户端不会永久托管文件系统的任何数据或元数据，尽管它可能需要保留少量的状态，如加密密钥或文件句柄以供访问。在某些文件系统中，参与者可以同时是客户端和服务器 集群是指托管文件系统的所有节点的集合，但不包括其客户端，除非另有说明。3指针在讨论分布式文件系统的整体架构之前，我们需要理解三个重要的概念：指针类型、指针粒度和多指针。3.1指针类型分布式文件系统使用几种指针或查找机制来指向Meta数据或数据。表1中总结了这些类型，本节的其余部分将进一步解释这些类型，从最简单的类型到最复杂的类型。3.1.1本地指针 这是一种最简单的指针，它总是引用文件系统的同一节点上的元数据或数据。例如，这种指针用于文件系统的inode中，这些文件系统将inode和相应的数据存储在同一节点上，例如AFS [25]，Coda [57]和ESData antibio® GX [17]以及一些GlusterFS配置[21]。在这种情况下，这些指针完全类似于底层本地文件系统用来引用来自inode的数据的本地指针。3.1.2显式直接指针。最简单的分布式指针显式地命名它引用的节点，例如通过指定其IP地址。这些指针的主要缺点是不灵活。例如，如果节点由于使用DHCP），指针突然停止工作。或者，更重要的是，如果一个节点失败，另一个节点承担了它的角色，那么所有的指针都必须更新。这种类型的指针在分布式系统中非常罕见，但一个设计良好的使用例子是IPFS[9]使用的libp2p [34]：它不仅使用不透明的对等体ID，还可以用对等体的IP地址和端口以其多地址格式来增加它们。因此，只要IP地址不改变，其他人就可以直接联系对等体，而不需要通过覆盖网络进行路由。·分布式文件系统设计选择综述四：5ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月3.1.3显式、间接指针。 这可能是分布式文件系统中最常见的指针类型，因为它既简单又灵活。显式间接指针引用节点、本地卷或节点上的磁盘，而不实际命名节点，例如通过引用虚拟节点ID或本地卷ID。 然后使用表映射这些ID，通常在群集中的所有节点上复制该表，并且还在客户端上缓存或复制该表（具体取决于指针的类型和文件系统的实现）。 这些表通常很小，更新不频繁;更新通常通过一个容错机制（如Paxos）进行协调。这种指针类型的一种特殊类型是前缀表（4.3节），它将路径前缀映射到管理相应子树的节点。这种用法的一个例子是AFS [25]、Coda [57]和Data antibioGX [17]中的卷位置数据库。3.1.4计算（隐式）指针。几个分布式文件系统不是显式地存储指针，而是通过使用关键字（例如文件ID或数据的内容散列）和集群成员列表来计算指针的目标。 也许最著名的例子是CephFS[73]中使用的CRUSH [74]函数，用于在集群中的节点上放置和查找数据。计算（隐式）指针通常通过使用一致性哈希[29]来实现，以最小化节点加入或离开集群时的数据移动，但其他方法也是可能的。例如，Flat Datacenter Storage [45]使用散列函数来定位文件的第一块（称为tract），但其余块的位置相对于它，其方式是在集群中更均匀地分配负载和容量。这种方法可以与显式间接指针类型相结合，方法是让散列函数引用虚拟节点ID或本地卷ID，然后使用在系统中所有节点上复制的表来解析3.1.5覆盖网络。 许多点对点系统使用基于分布式哈希表（DHT）的覆盖网络，例如Chord风格的DHT [61]。覆盖网络的一个优点是，只需使用密钥就可以将请求路由到适当的节点，而无需知道节点的地址、位置或身份，甚至无需知道完整的成员列表。事实上，只有一小部分成员节点必须是已知的路由功能，这使得它有利于大规模集群与高节点流失。 这样的覆盖网络因此对于节点故障是高度鲁棒的，并且许多（但不是全部）对于分区也是鲁棒的。基于DHT的覆盖网络的缺点是它们在网络往返次数方面的成本：基于它托管的对象的ID联系节点花费O（logn）往返，其中n是网络中节点的总数 在每个步骤中，节点将请求转发到另一个节点，该节点的ID通过某种度量更接近所请求的ID，例如图2中所示的共享最低有效位的数量。常见的优化是缓存看到的节点ID及其IP地址。这种网络的例子是Kademlia [38]（IPFS [ 9 ]中使用的变体），Tapestry [23]（OceanStore[31]中使用的）和DHash（CFS [13]的一部分）。这些网络不应该与Dynamo风格的DHT混淆[14]，后者也是分布式哈希表。不同之处在于，Dynamo风格的DHT要求每个节点具有节点成员的全部知识，因此相应地更快，而基于DHT的覆盖网络不需要这样的知识，并且相应地更慢。3.2指针粒度指针引用的目标可以是以下四种粒度之一• 子树（有时称为卷）：整个子树。四：6P. Macko和J. 亨尼西ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月图2. OceanStore[31]中的一个DHT风格的覆盖网络的例子，显示了搜索4598时从节点2207开始的路由路径。每个节点将请求路由到它所知道的下一个节点，该节点至少有一个与搜索关键字（下划线）共享的最低有效位。Bucket（不要与Amazon S3 bucket混淆）：可能不相关的文件或文件部分的集合。• 文件：整个文件，无论是其inode还是其所有内容。• 子文件：文件的一部分，可以是定长的，也可以是变长的。这些粒度通常成为元数据或数据管理的粒度，因为大多数文件系统不能在它们之间切换例如，AFS [25]中的前缀表具有子树粒度，这意味着不可能在不更改文件名的情况下更改文件的位置;我们将在4.3节中进一步讨论这个问题。IPFS [9]是一个值得注意的例外，它可以通过使用整个文件和子文件粒度在引用文件内容之间切换。3.3多指针通常一个指针指向一个目标;多指针将指针的概念推广到指定潜在的多个目标。它可以隐式或显式完成例如，Google文件系统（GFS）[20]中的主服务器有一个显式的服务器列表，存储每个块（即使它只是在内存中维护）;另一个例子是IPFS [9]，它显式地存储副本列表CephFS[ 73 ]中隐式多指针的一个例子是将放置组ID映射到数据节点（称为对象存储设备），它通过使用CRUSH[74]哈希函数从单个键确定节点列表。4路径到索引节点的转换数据路径的第一部分是路径到inode的转换，其中文件系统以路径或缓存的目录对象和文件名开始，并找到相应的inode。此inode包含重要的元数据，如大小、所有者、权限、校验和数据位置。许多分布式文件系统将这组信息称为元数据对象;在本文中，我们可以互换地将其称为inode和元数据。大多数分布式文件系统一次解析一个组件的路径，就像它们的单节点对应物一样。只有少数文件系统，如CalvinFS [68]，采用全路径索引。一次重新求解一个组件可以使目录上的许多操作更快，例如重命名或更改权限。然而，某些其他操作更复杂;例如，移动目录必须正确同步，以避免创建目录循环[7]。·分布式文件系统设计选择综述四：7ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月查找表2.路径到索引节点转换柔性方法延迟（往返）索引节点位置元数据粒度分区公差示例单节点O（1）无子树无HDFS 1.x [60]，Orion [78]复制的空间O（1）无子树依赖GlusterFS [21]复制前缀表O（1）无子树依赖AFS [25]，数据antioGX [17]远程链接O（1） 有子树或文件无Farsite [7]，FlexGroup卷[30]类似于共享磁盘通常O（1）无文件无GPFS [58]，Oracle FSS [32]计算O（1）无文件依赖GlusterFS [21]，Tahoe-LAFS [64]覆盖网络O（logn） 无文件依赖IPFS [9]，OceanStore [31，54]分布式数据库依赖无依赖依赖依赖ADLS [51]，CalvinFS [68]表2总结了常见的设计选项，并根据以下特点对其进行了评估网络延迟（往返）：路径组件查找和更新的延迟，以需要通过网络往返联系的节点数量来衡量（n是指集群中的节点数量）。灵活的inode位置：是否可以在不更改路径名或内部文件ID的情况下更改inode（不一定是数据）在网络中的位置;也就是说，文件系统是否支持命名的位置无关性。即使一种方法被标记为“否”，也可以通过巧妙的解决方案实现一些灵活性，例如用于覆盖网络的Coral分布式松散哈希表（Coral DSHT）[ 19 ]（我们在4.7节简要讨论Coral）。元数据粒度：元数据管理的粒度，即文件的元数据是否按子树分组，或者每个文件的元数据是否独立分布。Partitiontolerance：方法（不一定是所有特定的实现）是否支持少数网络分区中的文件系统可用性;也就是说，当少于一半的节点可达时。可用性有几种可能的定义，但在本文中，我们通常关注的是更强的定义，它描述了系统只有在即使在少数分区中也可以继续执行更新时才可用许多系统支持较弱形式的可用性，其中节点可以读取它们可以在分区的其一侧导航到的任何数据，但可能无法继续写入。我们现在将讨论这些方法中的每一种在下面的小节中，我们首先通过使用示例系统来解释该方法，然后讨论权衡，然后为感兴趣的读者讨论变体和其他值得注意的技术细节。 我们首先讨论最简单但不太常见的方法，然后讨论更常见的方法。一些系统结合了两种或多种方法，我们在本节中指出了几个这样的例子。最后，在4.9节中，我们提出了其他几个重要的设计方法。我们在4.10节中简要讨论了几个有趣的、尚未探索的问题，以此结束第44.1单个节点路径到inode转换的最简单情况是将整个命名空间（目录和文件）存储在集群的单个节点上，可能以主动-被动方式复制到另一个节点上这种方法对于小型集群可能足够了，但是由于其可伸缩性问题，它并不常见。然而，它在历史上很重要;例如，HDFS [60]用于支持····四：8P. Macko和J. 亨尼西ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月图3. GlusterFS [21]中的条带卷的简化示例，它复制所有节点上的整个命名空间，跨节点将数据条带在本例中，分发完全由客户端软件驱动在2.0版中引入HDFS联合之前，只有一个活动名称服务器从2.0版开始，HDFS支持多个名称节点来管理独立的名称空间，即使它们仍然共享同一组数据节点。最近的例子包括Orion [78]和MooseFS [40]，它们在单个元数据服务器上管理整个命名空间的元数据，然后可以复制。将整个名称空间存储在单个节点上的一个优点是，解析路径只需要往返于该节点一次。但是，节点很容易成为瓶颈，因此这种方法仅适用于小型集群或大型文件的情况缓解这个问题的一个选择是使用影子主机，它可以提供只读流量，例如在GFS [20]中。根据文件系统的不同，影子主服务器提供的元数据版本可能会稍微落后于主服务器提供的版本，也可能不会。这种方法的另一个优点是单个服务器成为协调的中心点。4.2复制的空间也许第二个最简单的路径到inode转换的情况是让文件系统在集群中的所有节点这种方法可以比单节点方法更好地扩展，但仍然限于较小的集群，因为尽管可以快速执行元数据读取，但更新较慢。 这种方法虽然不常见，但被一个著名的分布式文件系统GlusterFS [21]使用。复制名称空间的最干净的例子是GlusterFS中的条带卷和分散卷，如图3所示，它在集群的所有节点上复制整个名称空间。在分条的情况下，文件系统跨集群分条文件数据;在分散的情况下，它使用擦除编码。 与许多其他文件系统不同，此过程由客户端上运行的软件驱动。元数据比数据小，因此将整个命名空间存储在每个节点上是可行的，特别是在大文件工作负载中。在分布式配置中，GlusterFS仅将目录结构复制到所有节点上，这允许它扩展到更多节点，但将每个文件存储在单个节点上或将其复制到节点的子集通过使用一种让人想起Dynamo-styleDHT的机制，文件根据其名称的一致散列来放置[14]。它可以被认为是复制的名称空间和基于散列的文件放置的组合，我们在4.6节中描述。这种方法更具有可伸缩性，因为目录通常比文件少得多。分布式文件系统设计选择综述四：9ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月图第四章复制前缀表的示例，类似于AFS中的VLDB，它将路径前缀映射到卷或节点。这种方法的一个优点是，如果复制了整个名称空间，则可以通过使用单个网络往返来如果只复制目录，最多需要两次往返（一次获取包含目录，另一次获取文件（如果文件位于不同的节点上））。这种方法的明显缺点是管理可能大量副本的复制的成本，以及对可伸缩性、存储开销和元数据更新延迟的影响。分区容限取决于系统的实现和/或配置例如，GlusterFS可以被配置为将网络分区的少数侧的副本转换为只读副本，但也可以让分区的两侧独立操作，从而产生裂脑问题，并在以后修复差异。然而，许多类型的差异可能需要手动解决。4.3复制前缀表可以说，最流行的方法是基于前缀对文件系统命名空间进行典型的例子是AFS [25]，如图4所示。文件系统维护一个小型卷位置数据库（VLDB），该数据库将前缀映射到存储相应子树的节点，AFS称之为卷。 更一般地说，为了清楚起见，我们将这样的数据库称为前缀表，因为它是一个非常类似于精灵风格前缀表的概念[75];“卷”这个词也经常被过度用于命名不同的概念。前缀表的概念可以被认为是显式、间接指针的特殊情况，如3.1.3节所述。大多数文件系统都允许嵌套路径前缀，如图4中的示例所示。 这种方法通常与复制的名称空间结合使用，以实现冗余。例如，Coda [57]扩展了AFS，允许每个卷（子树）在多个节点上复制。前缀表通常很小，不经常更新，并且在集群中的所有节点上复制大多数文件系统通过使用可靠的容错机制（如Paxos）来更新它该表是高度复制的，更新它的成本很这种成本会产生压力，使表保持较小且不频繁更新，因此意味着子树应该相对较大。许多实现还将前缀表复制到客户端上，使得客户端可以确定哪个节点存储哪个文件的inode，并且可以在单个网络往返中访问它。文件系统可以允许客户端上的表的副本变得陈旧，在这种情况下，客户端在尝试访问不再主持了。因此，对名称空间进行分区可以保持低延迟访问，同时自然地产生更可伸缩的方法。根据实现，这种方法可以容忍四：10P. Macko和J. 亨尼西ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月图5. FlexGroup卷使用的远程链接的简化示例[30]。只要客户端可以继续访问在分区的其一侧上可用的子树，就可以更新前缀表;然而，在分区期间更新前缀表通常是不安全如果数据与元数据位于同一位置，则前缀表的一个主要缺点是在前缀之间移动（重命名）文件会导致数据移动。一些系统，如GlobalFS [46]，通过创建临时远程链接来解决这个问题在客户端请求移动文件或目录后，系统会在目标卷上创建一个指向文件或目录原始位置的远程链接，同时在后台完成数据移动 文件系统通常避免将这些链接设为永久链接，因为这会增加复杂性，并降低解析路径时的性能。相反，在复制前缀表系统中，通常不可能在不更改文件名的情况下更改文件的位置4.4远程链接跨多个节点划分文件系统命名空间的最灵活的方法是使用永久远程链接（与前面提到的临时远程链接相反），这是从一个节点上的目录条目指向另一个节点上的inode的硬链接这种方法的一个例子是FlexGroup卷[30]，它是一个分布式文件系统，构建在EPWWAFL ® [24]之上，如图5所示。另一个带有远程链接的分布式文件系统的例子是Slice [8]。因此，远程链接避免了在节点之间共享前缀表的需要;节点只需要就哪个节点托管文件系统的根 这些链接通常是显式的间接指针（参见3.1.3节）：它们不直接编码目标节点的IP地址，而是将其指定为节点ID。 或者在FlexGroup卷的情况下，它们对本地卷ID进行编码，因为一个节点可以托管多个参与的本地卷，这允许粗粒度的重新平衡，而无需更新链接。远程链接支持细粒度的文件放置，其中任何文件或目录都可以放置在任何节点上，或者在FlexGroup卷的情况下，可以放置在任何节点上的任何本地文件系统数据放置可能会受到平衡容量和负载的潜在冲突目标的影响，同时理想情况下也会保留局部性[30]。与前缀表不同，移动文件和目录实际上不会导致数据移动。 如果实现支持，通过允许跨节点移动文件和目录并相应地更新链接，细粒度的重新平衡是可能的。与通过复制的前缀表划分命名空间不同，遍历路径可能导致多次网络往返，甚至可能由于遍历远程链路而导致每个路径组件一次或多次往返如果链路跨越WAN级别的距离，特别是如果系统的布局使得解析路径不止一次遇到WAN级别的延迟，则这种方法的成本特别高。幸运的是，在单个文件系统请求中遇到多次网络往返是很少发生的，因为大多数实际系统都维护将前缀映射到位置的分布式文件系统设计选择综述四：11ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月这些路径前缀实际存储在哪里，类似于精灵风格的前缀表[75]。客户端或节点通常从空缓存开始，并随着时间的推移构建缓存。检测陈旧映射的一种有效方法是，当客户端向不再存储文件或目录的节点发送请求时，节点会返回错误[7]。然后，客户端从缓存删除映射，并使用缓存中第二长的前缀匹配重新开始路径遍历。这种方法的另一个缺点是它缺乏分区容差，无论是较弱的形式还是较强的 如果路径的一部分遍历托管在分区另一端的节点，那么该子树上的所有内容都可能变得不可访问-即使该子树的大部分最终存储在与客户端相同的分区端。分区还可能在确保远程链接及其缓存一致性方面造成问题在给定目录中检索多个文件或子目录的属性可能会产生很高的开销，例如在运行ls-l时，它会跨目录中找到的每个远程链接获取inode。解决此问题的一种方法是缓存远程inode（即，远程链路另一侧的inode）本地缓存，这导致了使这些缓存一致的开销远程链接的另一个开销来源是它们的更新，这通常需要执行多节点事务，在某些情况下甚至可能多达三个节点，在不同节点上的目录之间原子地移动文件 由于这些开销，像FlexGroup卷这样的系统选择最小化远程链接的数量和更新频率。Farsite [7]使用远程链接将相对少量的大型子树缝合在一起每个子树上的命名空间由一组7到10个节点管理，其中节点复制相同的元数据并使用Paxos进行协调。Lustre[37]是分布式文件系统的另一个例子，它使用远程链接来缝合相对少量的大型子树。Lustre分布式目录空间阶段I [15]允许管理员在与其父目录不同的元数据节点上创建一个新的目录作为远程目录 然后在新位置创建新目录下的所有新文件和目录。4.4.1CephFS隐含远程链接。CephFS是远程链接的一个独特变体[73]，它在节点之间划分子树，然后使用内存缓存（由日志支持）来获得远程链接的分布式好处，而无需实际拥有远程链接。 每个CephFS元数据服务器管理一组不同的本地子树，并缓存每个本地子树上相邻目录的信息（包括哪个服务器托管它们的授权）：父目录（递归到根目录）和直接子目录。因此，路径解析可以从任何节点开始，并且在每一步中，如果节点的缓存没有关于所请求的缓存的信息，则路径遍历可以在适当的权威节点处继续，直到它到达子树边界。在这一点上，遍历切换到另一个节点[72]。因此，路径遍历可以涉及多个节点，就像远程链接一样。因此，元数据服务器的内存缓存（以及扩展后的持久化日志内容）包含与远程链接等效的信息，即使它们没有显式存储。CephFS和使用远程链接的文件系统之间的另一个区别是，目录inode存储在其父目录中，而不是存储在管理其内容的节点4.5类似共享磁盘的文件系统一类重要的分布式文件系统是围绕共享磁盘抽象构建的，其中集群中的每个节点都具有相对较低级别的访问权限-即，对群集中所有磁盘的块级或区块级这通常假设一种网络形式，在这种网络中，四：12P. Macko和J. 亨尼西ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月同样重要的是（例如，平面数据中心网络[45]），并且还假设没有网络分区，这限制了可以部署这些文件系统的环境最著名的例子之一是GPFS [58]，其中节点以块粒度访问共享存储，并通过使用分布式锁定管理器在它们之间进行协调。这种文件系统通常类似于本地文件系统，除了分布式共享存储和分布式锁定。目录条目只是引用inode ID，就像在本地文件系统中一样但是inode实际上可能存储在集群中的另一个节点上，并且系统通常不会努力保持相关项的共置。事实上，为了最大限度地提高并行性，通常会将同一文件的块均匀地分布在整个集群中。Oracle FSS [32]是一个类似共享磁盘的文件系统的最近的例子，它的架构有些不同，它在支持条件多页写入的分布式直接访问存储设备上构建文件系统 FSS使用这个特性来实现一个B+树，它存储文件系统的所有元数据。类似共享磁盘的文件系统共享远程链接的一些特征，因为许多直接入口到索引节点的链接是远程的。然而，由于这些类似共享盘的文件系统通常以非常可伸缩的方式（例如，考虑一下GPFS [58]对目录使用可扩展散列的方式，在4.9.2节中讨论），它提供了良好的负载分布并允许大型集群。跨多个节点分条数据允许文件系统甚至为单个文件提供高聚合吞吐量，这就是为什么类似共享磁盘的文件系统往往也是并行文件系统的原因。（我们将在5.2节中详细讨论并行文件系统。） 因此，许多类似共享磁盘的文件系统用于服务高性能计算（HPC）工作负载。这些类型的文件系统与Lustre [37]等系统不同，Lustre [37]支持共享（例如，双端口）存储，但通常允许共享存储一次仅由单个服务器访问（我们在第6.1.4节中描述了这种架构。）类似地，这些类似共享磁盘的系统不应与只对数据而不对元数据使用共享磁盘抽象的文件系统混淆例如，Orion [78]是基于NOVA[77]的分布式非易失性存储器文件系统，在单独的元数据服务器上管理元数据，但允许客户端通过使用RDMA直接访问所有数据节点上的存储。4.6已计算（使用群集成员资格列表）一些分布式文件系统不是显式地存储文件和目录索引节点的位置（或者甚至通过前缀表不显式地存储），而是基于文件名或内部索引节点或文件ID以类似于计算（隐式）指针的方式计算位置（第3.1.4节）。也许最简单的例子是GlusterFS [21]中的分布式卷，如图6所示。这种机制在所有节点上复制目录结构，如第4.2节所述，但根据散列将文件放置在单个节点上，类似于Dynamo风格的DHT [14]。每个这样的目录存储散列范围到节点的映射，并且文件系统根据适当的目录放置文件 GlusterFS可以根据需要通过修改哈希范围和相应地移动数据来重新平衡数据，例如响应节点的添加和删除。在GlusterFS的情况下，这个过程完全是客户端驱动的，这意味着客户端可以通过单个网络往返来确定和访问给定节点。文件系统支持两种处理陈旧映射的机制：临时远程链接和查找请求广播。 如果用户重命名了一个文件，并且新的文件名哈希值落在分配给另一个节点的范围内，那么GlusterFS必须将该文件迁移到该节点。但是，为了让用户快速确认操作，GlusterFS会在数据在后台迁移时在新位置如果没有链接文件，例如分布式文件系统设计选择综述四：13ACM Transactions on Storage，Vol.号181、第四条。出版日期：2022年2月图第六章GlusterFS [21]中分布式卷的简化示例，它复制目录结构，但根据文件名的散列将文件放置在各个节点在重新平衡期间，如果客户端没有在预期的地方找到文件，则客户端向集群中的所有节点广播查找请求。显然，这种方法依赖于文件系统知道集群的成员列表它不能优雅地处理成员关系的更改，而且它不能容忍分区4.6.1可能的计算位置。 Tahoe-LAFS [64]使用了一种克服这些问题的独特方法，这是一种分散的点对点文件系统，专门为节点中的高成员流失和低信任度而设计。它使用一种类似于Renminbi散列的算法，也称为最高随机权重散列[65，66]，以概率计算文件位置。为了确定将具有唯一键<$的文件存储在哪里，Tahoe-LAFS客户端首先为每个可能的服务器节点s计算Hash（<$，s），然后对值进行排序然后，客户端将擦除编码的片段存储在前N个节点上，但仅需要k

下载后可阅读完整内容，剩余1页未读，立即下载