分布式文件系统元数据服务方式总结(HDFS、CephFS、CurveFS)

上一篇文章https://blog.csdn.net/qq_58034031/article/details/129518612分享了一篇20222论文，讲述在大型分布式文件系统中高效元数据服务，以此为启发总结了目前主流分布式文件系统它们是如何管理元数据的。

一、元数据分区方式

        常用的元数据分区方式分为子树分区和hash分区，其中子树分区又分为静态子树分区和动态子树分区。

二、常见分布式文件系统元数据管理方式

        本文主要从经典的中心化分布式文件系统、非中心化分布式文件系统和网易2021年发布的CurveFS(目前还在完善中)三个方面对它们元数据管理方案进行总结。

2.1 HDFS

 （1）单组Namenode架构

•  HDFS主要有两大模块：
  • Namespace（命名空间）：由目录、文件和块组成，它支持所有命名空间相关的文件操作，如创建、删除、修改，查看所有文件和目录。
  • Block Storage Service（块存储服务）：包括Block 管理和存储两部分
    • Block管理 通过控制注册以及阶段性的心跳，来保证Datanode的正常运行
      • 处理Block的报告信息和维护块的位置信息; 支持Block相关的操作，如创建、删除、修改、获取Block的位置信息；
      • 管理Block的冗余信息、创建副本、删除多余的副本等。
    • 存储
• 单组Namenode只允许整个集群有一个活动的Namenode，管理所有的命名空间。当集群中数据增长到一定规模后，NameNode 进程占用的内存可能会达到成百上千 GB，此时，单组NameNode 成了集群的性能瓶颈。
• 为了提高 HDFS 的水平扩展能力，提出了Federation（联邦）机制。HDFS Federation 是用来解决 NameNode 内存瓶颈问题的横向扩展方案。

(2) HDFS 联邦架构

• Federation架构与单组Namenode架构相比，主要是Namespace被拆分成了多个独立的部分，分别由独立的Namenode进行管理。
• Block Pool（块池）
  • Block Pool允许一个命名空间在不通知其他命名空间的情况下为一个新的block创建Block ID。同时一个Namenode失效不会影响其下Datanode为其他Namenode服务。
  • 每个Block Pool内部自治，也就是说各自管理各自的block，不会与其他Block Pool交流。一个Namenode挂掉了，不会影响其他NameNode。
• Federation优点：
  • 通过在集群中增加Namenode来扩展Namespace,以达到大规模部署。
  • 增加更多的Namenode能增大文件系统读写操作的吞吐量。
  • 不同类型的程序和用户可以通过不同的Namespace来进行隔离。

(3) HDFS 联邦元数据管理

• Federation 元数据采用了基于静态子树分区方案。
  • 所谓静态子树分区，就是管理员手动指定某颗子树，由某个元数据服务器负责；通过将一个子目录关联到另外一个分区上去，从而实现减轻当前文件系统的负载；
  • 意味着在集群中将会有多个 NameNode，这些 NameNode 相互独立且不需要协调，它们只需要管理自己所属的数据块即可。
    • 各NameNode负责自己所属的目录。此时每个NameNode只负责整个hdfs集群中部分目录。
    • 各NameNode间元数据不共享，每个NameNode都有对应的standby，防止单点故障。
    • 各 NameNode 共用一个集群里的所有存储资源，每个 NameNode 都可以单独对外提供服务。
• 为了方便管理多个命名空间，HDFS 联邦架构采用了经典的Client Side Mount Table
  • 如下图所示，下面四个蓝色三角形代表一个独立的命名空间，上方灰色的三角形代表从客户角度去访问的子命名空间。各个蓝色的命名空间Mount到灰色的表中，客户可以访问不同的挂载点来访问不同的命名空间，这就如同在Linux系统中访问不同挂载点一样。

（4）HDFS 联邦局限 

• 单点故障问题
  • HDFS Federation并没有完全解决单点故障问题。虽然namenode/namespace存在多个，但是从单个namenode/namespace看，仍然存在单点故障。
  • Federation中每个namenode仍然像之前HDFS上实现一样，配有一个secondary namenode，以便主namenode挂掉一下，用于还原元数据信息。
• 负载均衡问题 ​
  • HDFS Federation采用了Client Side Mount Table分摊文件和负载，该方法更多的需要人工介入已达到理想的负载均衡。
  • Federation是改造了客户端的解决方案，重度依赖客户端行为。如果对路径进行了namespace拆分后，如果因为代码中的路径或客户端配置没有及时更新，导致流程数据写入老数据路径，那么请求依然是合法但不符合预期的。
• 交叉访问问题
  • 由于Namespace被拆分成多个，且互相独立，一个文件路径只允许存在一个Namespace中。如果应用程序要访问多个文件路径，那么不可避免的会产生交叉访问Namespace的情况。比如Spark任务，都会存在此类问题。

2.2 CephFS

（1）CephFS架构

• 文件系统整体架构并没有太大的差异，其底层依赖的还是RADOS集群的对象存储。文件系统最大的特点在于对维护文件系统的目录结构，因此在Ceph中通过一个元数据集群（MDS）实现对文件元数据的管理。
• CephFS需要在rados存储集群上启动一个mds的守护进程来帮忙管理文件系统的元数据信息。
• 客户端的每一次存取操作，都会先联系mds，mds再去元数据存储池读取数据，然后返回给客户端。
  • 以写数据为例，首先需要与MDS交互确认文件存在，并且获得访问权。
  • 如果文件不存在，则需要在MDS创建文件。同时再MDS上还维护这文件的元数据，包括文件创建时间、大小和扩展属性等等内容。
  • MDS它自身不存储任何元数据信息，文件系统的元数据信息都会存储到rados的一个存储池（MetaData Pool）当中，而文件本身的数据存储到另一个存储池（Data Pool）当中。 

（2）单活MDS

• MDS全称Ceph Metadata Server，是CephFS服务依赖的元数据服务。
  • 对外提供服务只有一个active mds。
    • 元数据的内存缓存，为了加快元数据的访问。
  • 所有用户的请求都只落在一个active mds上。
• MDS高可用
  • active mds挂掉，standby mds会立马接替，保证集群高可用。
• 如果ceph集群上只有一个mds进程，很多个客户端来访问cephfs，那么mds肯定会成为瓶颈。
  • mds它自身不存储任何元数据信息，这也意味着msd是一个无状态服务。意味着可以有多个mds同时提供服务，相比传统文件存储系统来讲metadata server成为瓶颈的可能也就不复存在。
  • 由于文件系统元数据的工作特性，不能随意扩展mds守护进程。比如，在ceph集群上有两个mds，他们同时操作一个存储池中的一个文件，那么最后合并时发现，一个删除文件，一个修改了文件，合并文件系统崩溃了。

 （3）多活MDS

• 每个 CephFS 文件系统默认情况下都只配置一个活跃 MDS 守护进程。在大型系统中，为了扩展元数据性能可以配置多个活跃的 MDS 守护进程，它们会共同承担元数据负载。
• 多活MDS优势
  • 当元数据默认的单个 MDS 成为瓶颈时，配置多个活跃的 MDS 守护进程，提升集群性能。
  • 多个活跃的 MDS 有利于性能提升。
  • 多个活跃的MDS 可以实现MDS负载均衡。
  • 多个活跃的MDS 可以实现多租户资源隔离。

 （4）多活MDS元数据管理

• 基于以上问题，Cephfs元数据信息采用了基于动态子树分区方案。简单讲就是一个mds只负责一个子目录的元数据信息，从而实现元数据信息的读写分散负载。随着元数据服务器数量的增加，集群性能线性地扩展。
• 动态子树分区就是根据文件系统的负载能力动态调整对应子树。
  • 子树分区和迁移的决策是一个同步过程，各MDS每10秒钟做一次独立的迁移决策，每个MDS并不存在一个一致的名称空间视图，且MDS集群也不存在一个全局调度器负责统一的调度决策；
  • 各MDS彼此间通过交换心跳信息及负载状态来确定是否要进行迁移、如何分区命名空间，以及是否需要目录切分为子树等；
  • 管理员也可以配置CephFS负载的计算方式从而影响MDS的负载决策，目前，CephFS支持基于CPU负载、文件系统负载及混合此两种的决策机制。

       (5) 多活MDS局限

        为了解决子树分区带来的负载均衡问题，CephFS检测到负载不均衡时，它会跨元数据服务器迁移热子树。但是工作负载多样且频繁变化时，会遭受频繁的元数据迁移的高开销。

2.3 CurveFS

(1)CurveFS架构

• CurveFS由三个部分组成：
  • 客户端curve-fuse，和元数据集群交互处理文件元数据增删改查请求，和数据集群交互处理文件数据的增删改查请求。
  • 元数据集群metaserver cluster，用于接收和处理元数据(inode和dentry)的增删改查请求。架构类似于CurveBS。
    • mds 用于管理集群拓扑、集群调度、文件系统实例、文件元数据分片管理；基于 etcd 存储集群拓扑、用户和文件系统信息；基于 etcd 实现 mds 的高可用。
    • metaserver用于存储文件的元数据( inode 和 dentry )，通过 multi-raft 实现高可用和高可靠。每个 raft 复制组管理多组元数据分片。
  • 数据集群data cluster，CurveFS 的数据服务集群。当前支持S3标准接口的对象存储以及 CurveBS；

         官网给出Curve 文件系统的重要特点之一就是适用于海量文件存储。那么作为一个中心化的元数据管理服务，Curve 文件系统如何保证可以支撑百亿级规模？如何保证在百亿级规模下的性能？

（2）CurveFS规模

• MDS 管理文件系统实例及文件系统的元数据的分布。
  • 一个文件系统实例由多个元数据分片 partition组成
  • 每个partition管理指定范围的 inode，文件系统根目录的 inode 固定为1; dentry 存放在父目录所在的元数据分片上;
  • 对于文件 /A/B
    • 首先找到根目录所在的元数据分片，在该元数据分片上查询 dentry(/A)；
    • 从 dentry(/A) 中获得 /A 的 inodeid，根据 inodeid 获取对应的元数据分片查询dentry(/A/B)；
    • 从 dentry(/A/B) 中获得 /A/B 的 inodeid，从而定位到元数据分片，获取 /A/B 的 inode 信息。
  • copyset和partition是一对多的关系；
  • partition由copyset管理，copyset是raft复制组；
  • copyset和partition都是动态创建的，可以弹性扩容。当前的创建策略比较简单：在满足copyset的多个副本在不同的server的前提下，按照metaserver的管理磁盘的剩余容量进行选择；partition同样按照copyset所在metaserver的剩余容量进行选择；
  • Partition 分布在不同的 CopySet中，一组 CopySet 是一个 Raft Group，保证数据的高可用和高可靠。
• 如果文件数量增多，可以进行存储节点的扩充，所以理论上规模是没有上限的。

 （3）CurveFS性能

• 当文件数量很多时，对于单个文件的操作是没有什么差别的，但对于一些需要元数据的聚合操作会出现性能问题，比如 ls (获取目录下所有文件信息) 等操作，需要做一定的优化来保障性能。
  • 首先，MDS上元数据都会全部缓存在内存里，加速其查找。
  • 其次，在fs创建之后，MDS会为fs分配用来保存inode、dentry信息的分片。完成partition分配之后，fs的元数据操作会由client直接发向metaserver。此后的fs的inode、dentry的元数据管理并不经过MDS。
• 可靠性：
  • MDS的元数据持久化到etcd中，依靠3副本的etcd保证元数据的可靠性。可以选择部署多个MDS服务，但是同时之后有一个MDS对外提供服务，当主MDS因为特殊原因挂掉之后，会在自动的在剩下的MDS中，通过选主算法选择一个新的主MDS继续提供服务。
  • Metaserver高可用基于 raft 实现，2N+1 个副本允许 N 个副本异常。

 三、元数据管理总结

name	元数据管理	优点	局限
HDFS联邦	静态子树分区	可扩展Namespace 增大读写操作的吞吐量 不同程序和用户隔离	负载均衡问题 交叉访问问题 单点故障问题
CephFS	动态子树分区	多个活跃的 MDS 有利于性能提升。 实现MDS负载均衡 多租户资源隔离	可能会遭受频繁的元数据迁移的高开销。
CurveFS	元数据分片(inode)	元数据集群高可用、高可扩、高可靠	性能待优化