《集中式元数据模型和无元数据模型对比》由会员分享，可在线阅读，更多相关《集中式元数据模型和无元数据模型对比（3页珍藏版）》请在金锄头文库上搜索。
1、集中式元数据模型和无元数据模型对比随着非结构化数据的爆炸，分布式文件系统进入了发展的黄金时期，从高性能计 算到数据中心，从数据共享到互联网应用，已经渗透到数据应用的各方各面。对于大 多数分布式文件系统而言，通常将元数据与数据两者独立开来，即控制流与数据流进 行分离，从而获得更高的系统扩展性和I/O并发性。因而，元数据管理模型显得至关 重要，直接影响到系统的扩展性、性能、可靠性和稳定性等。存储系统要具有很高的 Scale-Out特性，最大的挑战之一就是记录数据逻辑与物理位置的映像关系即数据元数 据，还包括诸如属性和访问权限等信息。元数据问题是个非常大的挑战。总体来说， 分布式文件系统的元数据管理
2、方式大致可以分为三种模型，即集中式元数据服务模 型、分布式元数据服务模型和无元数据服务模型。本文将集中式元数据服务模型和无 元数据服务模型进行详细比较。集中式元数据服务模型分布式文件系统中，数据和I/O访问负载被分散到多个物理独立的存储和计算节 点，从而实现系统的高扩展性和高性能。通常一个文件会分成多个块存储在不同的节 点中。我们面临的一个关键问题就是如何确保对数据进行正确定位和访问，元数据服 务正是用来解决这个问题的。元数据服务记录数据逻辑名字与物理信息的映射关系， 包含文件访问控制所需要的所有元数据，对文件进行访问时，先向元数据服务请求查 询对应的元数据，然后通过获得的元数据进行后续的文件
3、读写等I/O操作。目前大多数商用分布式文件系统都采用了集中式的元数据服务模型，如 cStor,Lustre, GFS,HDFS，华为OceanStor等。集中式元数据服务模型，通常提供一个 中央元数据服务器负责元数据的存储和客户端查询请求，它提供统一的文件系统命名 空间，并处理名字解析和数据定位等访问控制功能。传统的NAS/SAN系统中，I/O数据 流需要经过服务器，而分布式文件系统中，I/O数据流不需要经过元数据服务器，由客 户端与存储节点直接交互。这个架构上的变革，使得控制流与数据流分离开来，元数 据服务器和存储服务器各司其职，系统扩展性和性能上获得了极大的提升。显而易 见，集中式元数据服
4、务模型的最大优点就是设计实现简单，对外提供网络访问接口即 可，如 POSIX、NFS、CIFS、HTTP REST 或 SOAP 等。集中式元数据服务模型最关键的问题是元数据单点故障和海量小文件应用中元数 据容量问题。目前，单点故障(SPOF，Single Point of Failure)问题主要是采用HA机制来解 决，根据可用性要求的高低，镜像一个或多个元数据服务器(逻辑的或物理的均可)， 构成一个元数据服务HA集群。集群中一台作为主元数据服务器，接受和处理来自客户 端的请求，并与其他服务器保持同步。当主元数据服务器发生问题时，自动选择一台 可用服务器作为新的主服务器，这一过程对上层应用是
5、透明的，不会产生业务中断。 HA机制能够解决SPOF问题，目前cStor采用主备元数据服务器双机热备解决了这一 问题，已经不存在元数据单点故障问题。每个文件都对应有一条元数据来记录逻辑名字和物理信息的映射关系，集中式元 数据服务模型中，通常会将元数据保存在内存中来提高元数据的访问效率，然而服务 器的内存数量有限，所以当应用场景为海量小文件时，元数据服务器内存会成为一个 瓶颈。实际上这个问题没有想象的那么严重，单条元数据记录一般为几百个字节，64G 内存的元数据服务器可以支持1亿个以上文件。目前业界已经有服务器可以支持1TB 内存，可以支持10亿个以上文件。cStor通过固态硬盘用作虚拟内存的方
6、式来解决 这一问题，目前单个集群可以支持100亿以上文件。cStor系统还支持异地多系统的 虚拟化，最大容量可扩展到100万EB量级，几乎是无限空间。无元数据服务模型目前，基于无元数据服务模型的分布式文件系统可谓凤毛麟角，在开源社区比较 流行的GlusterFS是其中最为典型的代表，无元数据服务模型在商用系统中并无应 用。对于分布式系统而言，元数据处理是决定系统扩展性、性能以及稳定性的关键。 GlusterFS另辟蹊径，彻底摒弃了元数据服务，使用弹性哈希算法代替传统分布式文件 系统中的集中或分布式元数据服务。这根本性解决了元数据这一难题，从而获得了接 近线性的高扩展性，同时也提高了系统性能和可
7、靠性。GlusterFS使用算法进行数据定 位，集群中的任何服务器和客户端只需根据路径和文件名就可以对数据进行定位和读 写访问。换句话说，GlusterFS不需要将元数据与数据进行分离，因为文件定位可独立 并行化进行。GlusterFS独特地采用无元数据服务的设计，取而代之使用算法来定位文 件，元数据和数据没有分离而是一起存储。集群中的所有存储系统服务器都可以智能 地对文件数据分片进行定位，仅仅根据文件名和路径并运用算法即可，而不需要查询 索引或者其他服务器。GlusterFS中数据访问流程如下：1、计算hash值，输入参数为文件路径和文件名；2、根据hash值在集群中选择子卷（存储服务器），
8、进行文件定位；3、对所选择的子卷进行数据访问。无元数据服务器模型设计的好处是没有单点故障，可提高系统扩展性。对于海量 小文件应用，这种设计能够有效解决元数据的难点问题。它的负面影响是，数据一致 问题更加复杂，文件目录遍历操作效率低下，缺乏全局监控管理功能。同时也导致客 户端承担了更多的职能，比如文件定位、名字空间缓存、逻辑卷视图维护等等，这些 都增加了客户端的负载，占用相当的CPU和内存。GlusterFS目前对存储节点删除支持有限，还无法做到完全无人干预的程度。如果 直接删除节点，那么所在存储服务器上的文件将无法浏览和访问，创建文件目录也会 失败。当前人工解决方法有两个，一是将节点上的数据重
9、新复制到GlusterFS中，二 是使用新的节点来替换删除节点并保持原有数据。GlusterFS目前的代码实现不够好，系统不够稳定，BUGS数量相对还比较多。从 其官方网站的部署情况来看，测试用户非常多，但是真正在生产环境中的应用较少， 存储部署容量几TB 一几十TB的占很大比率，数百TB-PB级案例非常少。这也可以从 另一个方面说明，GlusterFS目前还不够稳定，需要更长的时间来检验。GlusterFS比较明显的缺点如下:1）有副本的模式下，写的性能会下降为单副本的N倍（N=副本因子），因为它是完全 的同步写N份数据的。2）在压力比较大的时候，ls会非常之慢，难以忍受。原因是它在客户端没有文件信息 的缓存，每次都要去遍历brick，如果brick有几百个，其速度之慢可以想象，所以其 宣称的线性扩展性要大打折扣了。当然如果知道文件名，直接访问另当别论。华创ZeCloud为了解决这个问题，采用了索引服务器的概念。无元数据服务模型是为 了解决单点故障而设计的，采用索引服务器又引入了新的单点问题，并且访问文件又 多了一个流程，要先访问索引服务器。3）由于没有元数据服务器，其访问控制、信息统计实现都特别复杂4）虽然多服务器多客户端能够观察到线性，但是单客户端（单个mount点）的性能却 非常有限，连接超过3个服务器节点后，性能基本上就平了，就看不到线性了。
