前言

咱们的YRCloudFile是一款面向云时代的分布式文件系统，它的次要特点是反对海量小文件的高性能数据拜访，对Kubernetes平台的无缝反对，混合云场景下的数据撑持。咱们在开发YRCloudFile时，也会去理解业界支流的分布式文件系统，学习其长处，防止其毛病。本文探讨几个咱们曾考察过的支流的分布式文件系统，它们都是开源零碎，因为这样能收集到丰盛的材料，能看到代码，使得理解及探讨更为清晰。

咱们在调研一个分布式文件系统时，次要关注其外围架构，包含以下几个方面：

1）它的元数据计划，比方是否有元数据集群，元数据如何组织、元数据的搁置策略等。

2）元数据的正本机制及一致性，是EC还是多正本，正本间是同步写还是异步写，数据一致性如何。

3）数据的正本机制及一致性，即是EC还是多正本，以及正本间数据一致性问题。

围绕这几个外围问题，咱们会做一些扩大剖析，比方零碎的可用性、零碎的性能等。

本文要探讨的分布式文件系统，以及选取它们进行剖析和理解基于以下一些思考：

1) HDFS: 选取理由是经典，场景次要用于大数据分析，材料丰盛，用户数量大。

2) MooseFS:简略、但十分典型的设计，LizardFS是其变种。

3) Lustre:广为人知，被众人当做比拟的对象，背地有商业公司，但代码是凋谢可下载的。

4) GlusterFS: 老牌分布式文件系统，利用泛滥，国内很早开始就有人投入GlusterFS二次研发，其一致性hash的思路也颇为经典。

5) CephFS: 近年来最火的分布式存储Ceph，没有之一，集体认为是在分布式存储实践和实际上的集大成者。

HDFS

全称为The Hadoop Distributed File System，实用于Hadoop大数据生态，次要存储大文件，并定义文件模式是write-once-read-many，来极大简化数据一致性方面的问题。

援用官网其架构图为：

HDFS刚开始是单Namenode（能够了解为HDFS的元数据节点），这成为容量和性能的瓶颈点。起初再去做了多Namenode。

HDFS并不是一个通用型的分布式文件系统，即并不提供残缺的POSIX语义，至多它的设计指标就绝不是，它倒退到起初也不能胜任为通用性文件系统。它特点显著，积年来材料很多，本文也就不过多赘述。

MooseFS

如果你是一个文件系统的狂热爱好者和开发者，打算短期内写一个分布式文件系统，你可能会这么做：

1) 元数据局部

应用独立的元数据服务，为了简单化，并不做成元数据集群，而做成单元数据服务器，就像HDFS Namenode那样。

为了防止这个单点元数据服务离线、数据损毁带来的集群不可用以及数据失落，你会部署另一个或多个元数据服务作为backup，造成一主多从架构。但主从之间如何同步数据，可能是实时同步，也可能是异步同步。

另外，对于为了简单化，元数据服务的存储间接基于本地文件系统，如ext4。

2) 数据局部

为了简单化，数据服务存储也是基于本地文件系统。为了容错，跨服务器存储多个数据正本。

这么做的显著毛病是单元数据服务是瓶颈，既限度了集群反对的最大文件数目，也限度了集群并发拜访的性能。

MooseFS正好是这个架构，如官网示意图所示，它将元数据服务称之为Master Server，将数据服务称之为Chunk Server。

咱们通过剖析MooseFS的读写流程，来剖析它在数据一致性方面是否有问题。这里咱们参考了"MooseFS 3.0 User’s Manual" (https://moosefs.com/Content/Downloads/moosefs-3-0-users-manual.pdf)。

读流程示意图，需特地留神的是MooseFS所有正本都能提供读：

写流程示意图：

从写流程能看出，MooseFS应用的是chain replication形式，这个形式自身没有问题。不过从公开材料看，并未找到MooseFS多正本写有事务处理，且它的任意正本都反对读取，故而猜想MooseFS在故障状况下是存在数据一致性问题的。

git clone https://github.com/moosefs/moosefs.gitgit checkout v3.0.111

拿最新的代码，依据keyword CLTOCS_WRITE_DATA，能够看到写数据的代码流程。会发现两个问题：

1）多正本写，针对故障时正本一致性问题，并未有什么机制来确保统一。

2）本地数据写入调用hdd_write()，它在外部调用pwrite()，数据并未实时落盘，而是落在pagecache，再由pagecache下刷机制去负责落盘。

能够结构一个场景，client写入数据ABC，正本1写入了AB，正本2写入了A，此时集群掉电。在集群重启后，集群中存在不统一的数据。

结构另一个场景，client写入数据ABC，正本1和正本2都写入胜利，但并未下刷，且MooseFS反馈给client说写入胜利。此时集群掉电并重启后，正本1和正本2可能不统一，client读取的数据跟被承诺的可能不同。

实际上咱们在之前工作中，保护过一套线上MooseFS零碎，咱们过后剖析出MooseFS这一问题。明天写这个文章时，咱们从新拿了MooseFS最新的代码，浏览了针对性局部，发现这个数据一致性问题如故。

https://moosefs.com/

Lustre

Lustre在HPC畛域利用很广，肯定有其特别之处。不过咱们仍是次要关注其元数据和数据架构，以及数据一致性方面的问题。

Lustre架构跟MooseFS相似，都是典型的有元数据服务的架构。不过Lustre仿佛并未提供正本机制（两正本机制需被动触发，非同步正本），兴许是它面对的HPC场景，并且数据空间来源于后端的SAN阵列，所以它不须要提供数据冗余。

数据冗余依赖后端SAN阵列保障，数据一致性问题就被人造绕开了。咱们因而也临时不去深刻理解。

http://lustre.org/

GlusterFS

GlusterFS是十分出名的一个分布式文件系统，国内不少公司很早就在做GlusterFS的二次开发，对于GlusterFS最适宜的利用场景，大家探讨的最多的是视频存储和日志存储，其IO特点是大块数据程序读写，这很好了解，个别文件系统都能胜任这一场景。

另一方面，提及GlusterFS，大家探讨最多的概念是“一致性哈希”，“无核心架构”，“堆栈式设计”，本文会简略聊到这几个概念。GlusterFS网上学习材料很多，本文不再赘述，咱们依然次要剖析其元数据设计和数据一致性。

GlusterFS应用无元数据结构，亦即“无核心架构”，或“去中心化”，它应用一致性哈希，或者说是DHT（Distributed Hash Table）来定位数据地位。部署好一个GlusterFS集群，IO节点知悉集群存储节点列表，读写文件时，以文件名和存储节点列表为DHT算法输出，定位出文件存储地位。

在集群无故障时，存储节点列表固定，DHT算法简略无效。但在集群产生节点进出类故障时（比方有存储节点crash等），DHT应答就颇为乏力，应答逻辑简单，且会对业务可用性产生很大影响，因为存储节点列表变动，不少文件依据DHT计算的定位也发生变化，会波及数据移动，会波及业务IO需期待复原IO后行实现。

另一方面，这种无核心元数据结构，应答元数据操作时耗费颇大，比方一个ls，会放大到数个存储节点去做ls。而个别认为，文件系统中元数据操作占比很大，无元构造对这一事实颇为头疼。

数据一致性方面，GlusterFS是不提供数据强一致性的。咱们数年前有过GlusterFS的开发教训，split-brain —— 中文称为“脑裂” —— 对这一名词，咱们至今印象粗浅。

split-brain含意就是数据正本间不统一，比方正本1的内容是ABC，正本2的内容是AB，集群断定不出谁是非法数据。

咱们结构出一个split brain的场景：

  • brick1 down, write fileX
  • brick1 up, brick2 down, write fileX
  • brick1 brick2都up,split brain产生，brick1 brick2互相blame

GlusterFS官网文档是明确提及这一问题的，参见"Heal info and split-brain resolution” (https://docs.gluster.org/en/latest/Troubleshooting/resolving-splitbrain/)。能感觉出GlusterFS的定位并不是强统一的分布式文件系统，至此，咱们也很能了解为什么它次要用于大块程序IO的视频或日志文件存储，因这类数据文件大，总体文件数目少，性能更偏重于吞吐。且并非要害数据，产生split brain之类数据一致性问题后影响较小。

从GlusterFS社区打算来看，他们也思考要解决元数据性能问题和数据一致性问题，但我认为这是两大外围问题，跟外围架构强相干，要致力于很好解决颇有难度。不过技术无止境，咱们颇为期待。

https://www.gluster.org/

CephFS

Ceph是近年来最胜利的分布式存储系统，这里需注意并非说是分布式文件系统，因为Ceph有三大利用场景，别离是块存储Ceph RBD，对象存储Ceph RGW，以及文件存储CephFS。

Ceph RBD置信很多人都比拟相熟，因为在数年前云计算在风口的时候，OpenStack如日中天，Ceph RBD与OpenStack一拍即合，利用颇广。

CephFS、RBD、RGW三者的外围都是RADOS，这个模块负责数据定位，多正本，正本间强统一以及数据恢复等外围性能。RADOS数据定位算法是CRUSH，是反对肯定水平用户可控的哈希算法。RADOS做了多正本写的事务，保障单次写的原子性，并通过pglog等机制保障正本间的数据一致性。

咱们也曾有Ceph RBD的开发教训，咱们综合看来，Ceph是分布式存储实践和实际的集大成者。它实践齐备，实现上虽代码庞杂，但模块比拟清晰，代码品质颇高，十分值得去学习。

实践角度Ceph无可责备，几年前，投入Ceph二次开发的公司颇多，但大浪淘沙，只剩下一些研发实力较强的厂商在这方面保持投入。其起因之一在于Ceph代码过于繁冗，个别难以全面掌控，优化的成果和投入的资源不齐全成正比。

让咱们回归“分布式文件系统”这一主题，回到本文次要探讨元数据和数据一致性的视角。

CephFS是有元数据服务的，它称之为MDS。CephFS的元数据和数据都是存储在RADOS中的，从而CephFS的开发思路跟后面提及的MooseFS就很不雷同，比方MooseFS要做元数据服务的Leader Follower，而CephFS不须要思考这些，它的数据通过RADOS人造就牢靠、统一地冗余存储到集群中了。简略来说，CephFS的元数据管理MDS，更像是基于一个稳固数据搁置和存储层（这一层负责通过正本或EC形式确保数据强统一）之上，即RADOS之上，建设一个元数据服务层。这种架构在充分利用RADOS架构劣势的同时，也带来了一些弊病，咱们之前谈到，分布式文件系统中大量操作都和元数据相干，CephFS先拜访 MDS，最终再拜访RADOS中的数据，IO门路加长，对文件系统性能的影响来看，显得尤为显著。

https://ceph.io/

总结

本文咱们概要地探讨了常见的几个开源的分布式文件系统，次要从元数据和数据一致性两大角度去剖析，咱们认为从实践角度看，目前CephFS是最齐备的。

不过，探讨一个分布式文件系统有多种不同的视角，比方大文件备份的利用场景下，MooseFS就比拟适宜，而如果应用CephFS就太过简单；HPC场景下，Lustre利用很广，但换上CephFS也很可能面临性能降级。所以本文并非是对提及的分布式文件系统的“笔伐”，而是站在“元数据和数据一致性”视角，探讨咱们的认识，从而在设计和实现本人的文件系统时，取得更宽泛的思路。

每个零碎都有本人的衡量，都有本人的闪光点，本文不能一一而足，当前有机会再行粗疏探讨，也欢送大家留言探讨。