共计 4916 个字符，预计需要花费 13 分钟才能阅读完成。
前言
咱们的 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.git
git 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 阵列保障，数据一致性问题就被人造绕开了。咱们因而也临时不去深刻理解。
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 社区打算来看，他们也思考要解决元数据性能问题和数据一致性问题，但我认为这是两大外围问题，跟外围架构强相干，要致力于很好解决颇有难度。不过技术无止境，咱们颇为期待。
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 也很可能面临性能降级。所以本文并非是对提及的分布式文件系统的“笔伐”，而是站在“元数据和数据一致性”视角，探讨咱们的认识，从而在设计和实现本人的文件系统时，取得更宽泛的思路。
每个零碎都有本人的衡量，都有本人的闪光点，本文不能一一而足，当前有机会再行粗疏探讨，也欢送大家留言探讨。
