CN108595616A - 一种面向分布式文件系统的统一命名空间管理的方法 - Google Patents

Abstract

本发明公开了一种面向分布式文件系统的统一命名空间管理的方法，包括以下步骤：将第一挂载表放置在统一命名空间服务端，统一命名空间客户端启动时从服务端获取挂载表，服务端挂载表支持挂载表项的动态添加和删除，客户端通过心跳线程定期从服务端获取更新的挂载表。本发明解决已有系统中挂载表分散难以管理，引入统一命名空间后元数据访问性能下降严重等问题。

Description

一种面向分布式文件系统的统一命名空间管理的方法

技术领域

本发明涉及分布式存储领域，具体是一种面向分布式文件系统的统一命名空间管理的方法，尤其涉及底层有多个分布式文件系统的情况下，向上层提供一个统一的命名空间的方法。

背景技术

在大数据生态环境中，分布式文件系统支撑着上层运行的大数据计算框架及结构化存储系统，是大数据软件栈的重要组成部分。一方面，海量数据的增长使得数据常常存储在多个分布式文件系统中，形成多个独立的命名空间。另一方面，分布式文件系统普遍采用主从式架构，元数据存储在主节点的内存中，系统元数据承载量有限，常用的水平扩展方案是增加系统中的主节点数量，每个主节点管理各自独立的命名空间。为了简化上层应用对多个独立的命名空间的访问，通常向上层应用提供一层统一命名空间，应用只需与统一命名空间交互，由统一命名空间将上层应用的数据访问请求转化为具体的文件系统数据访问请求。

挂载表是统一命名空间中的一个重要的数据结构，挂载表保存了统一命名空间URI(统一资源标识符，Uniform Resource Identifier)到分布式文件系统URI的映射关系，上层应用使用统一命名空间URI请求数据，由统一命名空间查询挂载表，并转化为具体的文件系统数据请求。挂载表可以由上层应用在客户端配置，也可以统一放置在服务端，由系统管理员配置，上层应用与服务端交互获取所需的挂载表项。

已有的统一命名空间实现方案有viewFS，Alluxio Unified Namespace等。viewFS是访问多个HDFS namenode的统一命名空间解决方案，上层应用在客户端配置挂载表，viewFS通过挂载表完成viewFS URI到HDFS URI的映射，访问相应的HDFS namenode，其特点是实现简单，配置灵活，无须添加额外的服务端，缺点是上层应用需要知道底层分布式文件系统的具体情况，如果出现底层分布式文件系统增加或修改，所有相关的上层应用都需要重新配置挂载表，增加了上层应用的使用负担。进一步地，由于挂载表分散在各个上层应用中，对文件系统中任意挂载点目录的更改都需要通知对应的上层应用，增加了分布式文件系统管理的负担。

Alluxio Unified Namespace是访问多个分布式文件系统的统一命名空间解决方案。其挂载表配置在Alluxio Master端配置，上层应用无须在客户端进行配置，直接使用Alluxio URI访问多个底层分布式文件系统，由Alluxio Master完成对相应的分布式文件系统的映射，其优点是上层应用无须关心底层分布式文件系统的具体位置，甚至可以挂载不同类型的存储系统(HDFS，S3等)。缺点是Alluxio访问底层多个分布式文件系统需要将其元数据加载进自己的Master进程中，在面对底层元数据量较大的情况下容易造成元数据访问性能下降，Alluxio也提供了不加载底层分布式文件系统元数据的配置项，此时应用客户端只需从Alluxio Master端获取所需的挂载项，并在客户端完成URI的映射，有效缓解了Master端的元数据压力，缺点是上层应用每次访问底层分布式文件系统需要增加一次客户端到Alluxio Master端的RPC，对元数据IO密集型应用有较大的影响。

发明内容

发明目的：针对上述现有技术存在的问题和不足，本发明的目的是提供一种一种面向分布式文件系统的统一命名空间管理的方法，解决现有系统中挂载表分散难以管理，引入统一命名空间后元数据访问性能下降等问题。

技术方案：为了实现上述发明目的，本发明采用的技术方案是提供一种面向分布式文件系统的统一命名空间管理的方法，包括以下步骤：

(1)将第一挂载表放置在服务端；

(2)服务端将UGI(用户和组信息，User Group Information)引入挂载表项，无UGI的挂载表项为公共挂载点，所有用户都能获取和使用，包含UGI的挂载表项为私有挂载点，只有特定用户能够获取和使用；

(3)服务端支持挂载表项的删除与添加，除原始的第一挂载表外，增加一张增量的第二挂载表，服务端更新挂载表项时，检查第二挂载表，将其中过期的挂载表项删除；

(4)上层应用在初始化客户端的文件系统时，从服务端获取需要的挂载表项，生成一张客户端的第三挂载表；

(5)通过客户端会话心跳线程完成所述第三挂载表的更新，每隔一个心跳周期客户端主动向服务端获取第二挂载表的信息，并作用于第三挂载表的更新。

进一步地，所述步骤(1)中，全局只有一张第一挂载表存储在服务端，由系统管理员进行配置，用户只需使用统一命名空间URI即可访问多个分布式文件系统。

进一步地，所述步骤(2)中，服务端第一挂载表添加URI信息后，单个客户端更新时获取的挂载表项远小于服务端存储的第一挂载表项。

进一步地，所述步骤(3)中，本发明支持服务端添加和删除挂载表项，并不直接支持修改，修改可以通过删除挂载表项，对实际底层文件系统目录进行相关操作后，添加新的挂载表项完成。

进一步地，所述步骤(4)、(5)中，服务端的第一挂载表可能存在更新，客户端和服务端需要进行同步挂载表信息，直接使用客户端工作线程进行同步会降低客户端元数据访问性能，所以使用客户端和服务端的会话心跳线程完成挂载表信息的同步，在实际使用场景中，服务端挂载表的更新也并不频繁，所以服务端额外生成一张增量的第二挂载表，第二挂载表只保存2个心跳周期内的更新的挂载表项信息，客户端会话心跳线程只获取第二挂载表，该表规模比第三挂载表规模小很多，通常是空列表，进一步降低了引入统一命名空间后对上层应用的元数据访问性能的影响。

进一步的，所述步骤(5)中，还包括：客户端使用第三挂载表进行统一命名空间URI到分布式文件系统URI的映射解析，解析时采用最长前缀路径匹配找出相应的挂载点URI，因此，使用树形结构存储第三挂载表，加快客户端的解析过程。

有益效果：本发明实现了一个分布式文件系统的统一命名空间：第一，采用服务端挂载表方案，大大简化客户端配置，客户端无须关心具体的挂载信息。第二，服务端第一挂载表添加UGI后，有效避免客户端对其他用户私有挂载点目录的访问，减小了客户端第三挂载表规模，降低了读取第三挂载表对初始化文件系统客户端的性能影响。第三，支持服务端第一挂载表的更新，允许应用在无须重启的情况下使用新的挂载点目录。第四，基于服务端第一挂载表极少更新的特点，在服务端添加一张增量的第二挂载表，客户端第三挂载表与服务端第一挂载表的信息同步通过传递第二挂载表完成，降低了客户端和服务端的网络开销。

附图说明

图1为本发明的方法总体示意图；

图2为本发明中客户端第三挂载表结构示意图。

具体实施方式

下面结合附图和具体实施例，进一步阐明本发明，应理解这些实施例仅用于说明本发明而不用于限制本发明的范围，在阅读了本发明之后，本领域技术人员对本发明的各种等价形式的修改均落于本申请所附权利要求所限定的范围。

如图1所示，本发明引入一个服务端进程来存储第一挂载表，第一挂载表保存了全局的挂载信息，客户端保存一张第三挂载表，第三挂载表只保留当前用户需要的挂载信息，客户端通过第三挂载表完成统一命名空间URI到底层分布式文件系统URI的转换。服务端挂载表支持动态挂载信息的动态添加和删除，使用一张第二挂载表保存更新的挂载信息，客户端定期与服务端通信获取第二挂载表，并更新本地的第三挂载表。

表1本发明中服务端第一挂载表示意

统一命名空间URI	分布式文件系统URI	UGI
			dfs://hostname:port/hbase	hdfs://namenode1:port/hbase	hbase,hbase
dfs://hostname:port/user/hive	hdfs://namenode2:port/hive	hive,hive
			dfs://hostname:port/tmp	hdfs://namenode2:port/tmp	all,all

如表1所示，服务端第一挂载表中增加一列存储挂载点的UGI(用户和组信息)，统一命名空间客户端与服务端交互时使用原有的分布式文件系统的用户和组信息(如果没有配置，则默认使用客户端节点操作系统的用户和组信息)，系统管理员可以配置初始第一挂载表文件，格式如下：

<统一命名空间URI><分布式文件系统URI><UGI>

…

<统一命名空间URI><分布式文件系统URI><UGI>

其中UGI的格式如下：

username1:group1,username2:group2，…

服务端启动时加载初始第一挂载表，客户端此时可以与服务端交互后生成第三挂载表，透明地访问多个分布式文件系统。

系统管理员可以在服务端运行时动态地将新的分布式文件系统挂载进统一命名空间，挂载命令如下所示:

mount<统一命名空间URI><分布式文件系统URI><UGI>

也可以动态取消某个已存在的挂载表项：

umount<统一命名空间URI>

mount命令不支持重新挂载一个已有的统一命名空间URI，可以通过先删除现有的挂载点，对底层分布式文件系统进行相应操作后，再重新挂载的方式实现，与操作系统中常见的挂载方法是一致的。

挂载命令和取消挂载命令除了修改第一挂载表外，还会在服务端进程生成增量的第二挂载表(如表2所示)，供客户端更新第三挂载表使用，同时删除原有第二挂载表中过期的表项(第二挂载表项生存时间设置为2个心跳周期)，将第二挂载表规模保持在合理范围内。

表2本发明中服务端第二挂载表示意

统一命名空间URI	分布式文件系统URI	UGI	更新类型
				dfs://hostname:port/hbase			DELETE
dfs://hostname:port/staging	hdfs://namenode2:port/staging	hadoop,hadoop	ADD

客户端在任意时刻访问服务端第一挂载表，并每隔1个心跳周期从服务端获取第二挂载表，为了确保所有上一个心跳周期内的第二挂载表的表项都能被客户端获取到，本发明采取冗余获取第二挂载表项的方法，即第二挂载中的表项保留2个心跳周期，当客户端获取第二挂载表更新第三挂载表时，获得的第二挂载表的表项会比需要的挂载表项多，出现重复更新某一挂载表项的情况，这种更新是幂等的，客户端更新时对同一挂载表项进行重复添加和删除时，直接忽略本次挂载表项的更新，使用冗余更新的方式确保第三挂载表项和服务端第一挂载表项总是保持一致的。

针对服务端进程可能存在单点故障的情况，本发明可以同时运行2个服务端进程的实例，使用开源软件Zookeeper选举出一个服务端进程作为主进程对所有上层应用提供服务，另一个服务端进程作为从进程，定期与主进程进行同步，同时向Zookeeper注册监听主进程，当主进程失效后，从进程将自己注册进Zookeeper，变为主进程，向上层应用继续提供服务，确保了服务端进程的高可用性，故障的服务端进程在手动恢复后变为从进程。相应地，客户端此时需要配置容错模式，通过Zookeeper获取主进程地址。

上层应用初始化统一命名空间客户端时通过访问服务端建立第三挂载表，第三挂载表采用树形结构存储，如图2所示，客户端进行统一命名空间URI到分布式文件系统URI的映射解析时通过树形挂载表索引到最底层的匹配到的挂载点目录，即匹配最长前缀路径的挂载点目录。

访问第三挂载表进行URI映射解析大大降低了引入统一命名空间对元数据访问性能的影响。为了进一步提升元数据访问性能，统一命名空间客户端将已访问过的底层分布式文件系统的连接进行缓存，并通过设置缓存连接的个数和生存时间，避免一些上层应用，如键值存储系统长时间占有多个分布式文件系统连接。

客户端URI映射解析完成后，统一命名空间客户端将统一命名空间URI转换为分布式文件系统URI，与相应的分布式文件系统交互，大部分操作直接调用分布式文件系统API完成，少量元数据操作的返回结果中包含路径信息，此时需要将分布式文件系统URI转换为统一命名空间URI并返回给上层应用。

统一命名空间客户端提供的是标准Hadoop FileSystem接口的API，原有运行在HDFS之上的应用可以通过修改配置文件的方式直接使用统一命名空间，在统一命名空间的实现中，支持所有的Hadoop FileSystem定义的文件操作接口，唯一例外的是重命名操作，在单个分布式文件系统中，重命名URI通过修改分布式文件系统的元数据完成，完成时间在毫秒以内，在统一命名空间中，同一个分布式文件系统的重命名操作可以直接调用对应的分布式文件系统API直接完成，对于跨分布式文件系统的重命名操作，涉及到底层相应文件的复制操作，取决于数据的规模，可能需要的时间在小时级别，这对于单个重命名操作而言是难以接受的，本发明在检查分布式文件系统源路径URI和目标路径URI后，如果不是在同一分布式文件系统，直接向上层应用抛出异常，由上层应用决定是否进行数据拷贝，并重新设置目录。

使用统一命名空间URI访问多个分布式文件系统时，客户端只能访问挂载点之后的目录，如“/tmp”为挂载点目录，则客户端只能访问“/tmp/staging”,“/tmp/intermediate”等目录，无法对挂载点目录的前缀路径进行操作，如“/”，在分布式文件系统的权限检查中，通常是从当前路径检查到根路径，即“/”,所在目录的操作权限受挂载点之前的目录影响可能出现和预设不符的情况，甚至前缀路径并无对应的挂载点，导致上层应用报错的情况。本发明采取的做法是在统一命名空间层分目录类型进行权限检查，对统一命名空间的某个目录进行权限检查时，先查询树形挂载表，找出该目录所在的挂载点目录，对挂载点之后的目录权限信息通过访问对应的分布式文件系统获取，对挂载点之前的目录直接返回完整权限，这样对目录的权限检查结果完全取决于挂载点目录之后的目录，不影响权限检查的正确性。

本发明基于已有的开源软件实现了一个原型系统。并进行了详细的功能测试和性能测试，包括NoSql数据库HBase，数据仓库Hive都已经成功运行在本发明的统一命名空间之上，通过使用开源软件

dfs-perf(https://github.com/PasaLab/dfs-perf)对本发明的元数据访问性能进行测试，表3给出的是本发明的统一命名空间和已有的viewFS、Alluxio在每秒钟元数据的操作个数对比，每秒的元数据操作数越高，代表元数据性能越好。表4给出的本发明和已有的viewFS，Alluxio在挂载表配置上的对比，本发明无须用户配置挂载表，减轻了上层应用的使用难度。本发明实现的原型系统的元数据访问性能非常接近viewFS的客户端静态挂载表方案，优于Alluxio服务端挂载表方案，同时在挂载表的配置管理上优于ViewFS，结合了两者的优点。

表3本发明与现有两种方法在元数据操作性能上的对比

(单位：元数据操作数/秒)

用户数量	10	20	30	40	50
						本发明	68.2	94.5	124.2	153.4	185.2
viewFS	70.2	95.2	125.5	154.3	186.2
						Alluxio	64.6	90.4	105.4	112.4	123.6

表4本发明与viewFS在挂载表配置管理上的对比

本发明	无须用户配置挂载表，支持挂载表动态更新
		viewFS	需要用户配置挂载表，更新挂载表需要重启上层应用
Alluxio	无须用户配置挂载表，支持挂载表动态更新

Claims (6)

1.一种面向分布式文件系统的统一命名空间管理的方法，包括以下步骤：

(1)将第一挂载表放置在服务端；

(2)服务端将UGI引入挂载表项，无UGI的挂载表项为公共挂载点，所有用户都能获取和使用，包含UGI的挂载表项为私有挂载点，只有特定用户能够获取和使用；

(3)服务端支持挂载表项的删除与添加，除原始的第一挂载表外，增加一张增量的第二挂载表，服务端更新挂载表项时，检查第二挂载表，将其中过期的挂载表项删除；

(4)上层应用在初始化客户端的文件系统时，从服务端获取需要的挂载表项，生成一张客户端的第三挂载表；

(5)通过客户端会话心跳线程完成所述第三挂载表的更新，每隔一个心跳周期客户端主动向服务端获取第二挂载表的信息，并作用于第三挂载表的更新。

2.根据权利要求1所述一种面向分布式文件系统的统一命名空间管理的方法，其特征在于：将第一挂载表放置在服务端，无须上层应用在客户端配置。

3.根据权利要求2所述一种面向分布式文件系统的统一命名空间管理的方法，其特征在于：所述步骤(3)中，服务端在增加和删除挂载表项时同时会生成增量挂载表项，第二挂载表的规模远小于第一挂载表，客户端获取第二挂载表以更新第三挂载表。

4.根据权利要求1所述一种面向分布式文件系统的统一命名空间管理的方法，其特征在于：所述步骤(5)中，使用心跳线程更新第三挂载表，所述心跳线程直接访问第三挂载表。

5.根据权利要求1所述一种面向分布式文件系统的统一命名空间管理的方法，其特征在于：所述步骤(5)中，还包括：客户端使用第三挂载表进行统一命名空间URI到分布式文件系统URI的映射解析，解析时采用最长前缀路径匹配找出相应的挂载点URI。

6.根据权利要求5所述一种面向分布式文件系统的统一命名空间管理的方法，其特征在于：使用树形结构存储第三挂载表。