文件系统是计算机中非常重要的组件，可为存储设备提供一致的访问和管理方法。在不同的操作系统中，文件系统中会有一些差异，但是数十年来有一些共同的特征并没有太大变化：
文件系统提供的访问和管理方法支持绝大多数计算机应用程序。Unix的“一切文件”的概念突出了其重要位置。文件系统的复杂性使其可伸缩性无法跟上Internet的高速度开发，并且它具有极大的简化对象存储，可以及时填充空缺以开发空缺由于对象存储缺乏树结构，并且不支持原子的命名操作，因此它与文件系统大不相同。暂时不会讨论本文。
大多数文件系统都是站立的，可为支架中的一个或多个存储设备提供访问和管理。随着Internet的快速开发，单个机器文件系统面临许多挑战：
随着互联网的快速发展，这些问题变得越来越突出，并且已经出现了一些分布式文件系统以应对这些挑战。
这是我知道的几个分布式文件系统的基本架构，并比较了不同体系结构的优点和局限性。
Glusterfs是由Gluster在美国（带GPL开源）开发的POSIX分布式文件系统。它于2007年发布了第一个公共版本，并于2011年被Redhat收购。
它的基本思想是通过无状态的中间件将多个单位的文件系统集成到用户为统一的名称空间中。此中间部分由一系列超级可行的转换器实现。每个转换器都解决了一个问题，例如数据分布，复制，拆卸，缓存，锁等。
server1和server2具有2个副本，server3和server4的卷0卷，然后将其融合到具有较大空间的分布式卷中。
优点：最终将数据文件保存在具有相同目录结构的单元文件系统上。不必担心使用GlusterF会导致数据丢失。
没有明显的单点问题，线性扩展。
据估计，对大量小文件的支持非常好。
挑战：这种结构相对静态，并且不容易调整。还需要对每个存储节点具有相同的配置。当数据或访问不均匀时，没有空间或负载调整。故障恢复能力也相对较弱。例如，当Server1失败时，Server2上的文件无法增加健康3或4上的副本保证数据的副本。
由于缺乏独立的元数据服务，所有存储节点都必须具有完整的数据目录结构。在遍历目录或进行目录结构调整时，需要访问所有节点才能获得正确的结果。当节点时，这是可以的，并且很难有效地管理数百个节点。
CEPHFS始于Sage Weil的博士学位论文研究，目的是实现分布式元数据管理以支持EB级别的数据量表。在2012年，Sage Weil建立的Inktank继续支持CEPHFS的发展，并在2014年被Redhat收购。直到2016年，CEPHFS发布了可用于生产环境的稳定版本（Cephfs的元数据部分仍然是站立的）。CEPHF的分布式元数据仍然不成熟。
Ceph是一个分层的建筑。底层是基于Crush（Hash）的分布式对象存储。
使用一组存储系统来满足多种不同方案的存储要求（虚拟机镜，大型小文件和通用文件存储）仍然非常有吸引力，但是由于系统的复杂性需要强大的操作和维护功能才能支持它。实际上，只有块存储是相对成熟的。对象存储和文件系统不是理想的。在听到某些用例案件后，它在一段时间后就放弃了。
CEPHF的架构如下图所示：
CEPHFS由MDS（元数据守护程序）实施。它是一个或多个无状态元数据服务，从基础OSD加载了元信息并缓存到内存以提高访问速度。由于MDS不状态，可以配置多个备用节点以实现HA，这是相对容易。但是，备份节点没有缓存，需要重新加热。可能的故障恢复时间将相对较长。
由于从存储层的加载或编写数据将很慢，因此MDS必须使用多线程来增加吞吐量。各种并发的文件系统操作会导致复杂性大大增加，并且很容易发生。decline.ind.为了获得更好的性能，MDS通常需要足够的内存来缓存大多数元数据，这也限制了其实际支持能力。
当有多个活动MD时，目录结构的一部分（子树）可以动态分配到某个MDS并完全处理相关请求，以实现水平扩展的目的。在多个主动活动之前，他们自己的锁定机制不可避免地需要协商副品的所有权，并通过分布式交易来实现当时的-Cross -Child树的重新命名。这些非常复杂。目前，仍然不建议使用最新的官方文件使用多个MD（作为备份）。
Google的GFS是从早期BigFiles开发的分布式文件系统中的先驱和典型的代表。设计概念和细节在2003年发表的论文中详细阐述了，这对行业产生了很大的影响。后来，设计了许多分布式文件系统。
顾名思义，BigFiles/GFS专为大型文件而设计，不适合在1MB中平均文件的场景。GFS的体系结构如下：
GFS有一个主节点可以管理元数据（全部加载到内存，快照和更新日志到磁盘），并且将文件分为64MB的块，以将其存储在几个块状服务器上（直接使用单个机器文件系统）。文件CAN可以仅添加，因此不必担心块的版本和一致性问题（可以用作版本）。这种使用完全不同的技术来求解元数据和数据的设计以极大地简化系统的复杂性，并且还具有足够的扩展功能（如果平均文件大小大于256MB，则主节点可以支持每个GB的主节点约1％的数据量）。启动一些支持POSIX文件系统的功能（例如随机写入，扩展，扩展，扩展属性，硬链路等）进一步简化了系统复杂性，以换取更好的系统性能，鲁棒性和可扩展性。
由于GFS的成熟度和稳定性，Google可以更容易构建 - 级别的应用程序（MapReduce，Bigtable等）。后来，Google开发了具有更强可扩展性的下一个形式存储系统巨像，该系统完全分离了元数据和数据存储，意识到元数据的分布（自动碎片），并使用芦苇所罗门编码成本。
Yahoo的Hadoop是Google的GFS，MapReduce等的开源Java实现版本。HDFS基本上也是GFS的设计。它不会在这里重复。下图是HDFS的建筑图：
HDF的可靠性和可伸缩性仍然非常好。有数千个节点和100pb级的部署。支持大数据应用程序性能仍然非常好。
HDFS HA解决方案后来得到了补充，并且相对复杂，因此该HA解决方案的第一个Facebook是手动切换（至少3年）（至少3年）。
由于Namenode由Java实现，因此取决于预先分配的堆内存大小。分配不足可以轻松触发完整的GC并影响整个系统的性能。一些团队试图用C ++重写，但他们没有看到成熟的开源解决方案。
HDFS还缺乏成熟的非java客户端，这使得除了大数据（例如Deepoop）以外的其他场景并不方便使用。
Moosefs是来自波兰的开源分布式POSIX文件系统。它还指GFS架构，并意识到绝大多数POSIX语义和API。使用非常成熟的保险丝客户端安装后，可以像本地文件系统一样访问它。
Moosefs支持快照，该快照很容易通过数据备份或备份恢复。
Moosefs由C实施C. Master是一个由异步事件驱动的单个线程，类似于Redis。
开源社区版本没有HA，该版本用于通过Metalogger实现异步寒冷。封闭的源充电版本具有HA。
为了支持随机写作操作，可以修改Moosef中的块。通过一组版本管理机制以确保数据一致性，这种机制更加复杂，容易出现奇怪的问题（例如，预期）。
上面提到的GFS，HDFS和MOOSEFS是为自行车室的软件和硬件环境而设计的。数据的可靠性和节点可用性通过多机械和多副本来解决。如果通过多机械和多拷贝完成，它将导致数据成本高（事实上是9份）。
因此，我们为公共云设计了HDFS和Moosefs的架构，并设计Juicefs。该体系结构如下图所示：
Juicefs使用公共云中的现有对象来替换数据座和块构架，以实现完全灵活的无服务器存储系统。公共云的对象存储已经很好地解决了大规模数据的安全有效存储。Juicefs只需要专注于元数据的管理，这也大大降低了元数据服务的复杂性（GFS和Moosefs MasterStorage和数据块健康管理）。
我们还对元数据部分进行了许多改进，并从一开始就取得了高可用性。为真正提供高性能服务，元数据的管理和操作和维护仍然非常具有挑战性。元数据以服务形式提供给用户。由于POSIX文件系统API是最广泛使用的API，因此我们基于FUSE实现了高度POSIX的客户端。用户可以通过命令行工具通过命令行工具将Juicefs安装到Linux或MacOS中。
上图右侧的虚线是数据存储和访问的一部分。它涉及用户的数据隐私。他们正好在客户自己的帐户和网络环境中，并且不会与元数据服务联系。
我简要介绍了我学到的几个分布式文件系统的体系结构，并按照它们出现的时间顺序将它们放在下面的图中（请参阅箭头代表后的前者或新一代版本）：
上图中的几个蓝色文件主要用于大数据方案。实现了POSIX的子集，下面的绿色是POSIX兼容文件系统。
GFS代表的元数据的系统设计和数据分离可以有效地平衡系统的复杂性，并有效地解决大型数据的存储问题（通常是大文件），该问题具有更好的可扩展性。支持元数据，具有无限的可伸缩功能。
作为后来的Juicefs，学习了Moosefs实施分布式POSIX文件系统的方式，还学会了将Facebook Harmstorage的数据和数据完全分开的想法。我希望在场景中提供最好的分布式存储，例如公共或私有云和其他场景。上述分布式文件系统。JUICEFS还支持所有公共云。不必担心云服务锁定，但也可以在公共云或地区之间顺利移动数据。
最后，如果您手中有一个公共云帐户，请到Juicefs注册，并且可以在5分钟内将PB -Level -Level文件系统安装在您自己的Mac上。
推荐阅读：
如何使用Juicefs加快7次AI模型培训