文件系统管理工具设计与实现

1研究背景

1．1Robinhood策略引擎

Robinhood是一款非常优秀的开源软件，它通过遍历文件系统目录树收集元数据信息，将收集到的元数据信息保存到数据库。通过统计分析数据库中存储的文件信息，实现文件系统的管理与监视功能。Robinhood的架构如图1所示。信息采集器的功能是收集文件系统的元数据信息。它运用多线程技术，深度优先遍历文件系统。在Linux操作系统中，单个目录下文件的数量没有限制，如果广度优先会有内存溢出风险;但是Linux系统对文件目录树的最大深度做了规定，一般不超过256，所以，采用深度优先遍历可以规避这个问题。文件清单管理器实现了对MySQL数据库的基本操作，比如查询、插入、删除、更新等。它接受来自信息采集器、资源监视器和基于Web监视模块的服务请求，提供数据服务。资源监视器根据用户提供的“清理策略”配置条件，通过文件清单管理器查询数据库进行匹配。在“清理策略”中，以文件的过期时间、文件归属等信息为条件，实现对文件系统的自动管理。例如，管理员可以设定将文件最后更新时间在2000年以前且属于用户Jack的文件删除。基于Web的监视模块调用文件清单管理器提供的数据库访问接口，对数据库中文件元数据信息进行分析统计后生成图形报表，并以Web网页形式展示。由于数据库保存文件系统的元数据信息存在一定的滞后性，如果信息过于滞后，将无法正确有效地管理文件系统。目前Robinhood的架构只能运行于单台计算机，单台计算机的有限的计算能力，制约了Robinhood的快速遍历文件树的性能，无法保证数据库信息及时更新。经过测试，Robinhood遍历一次大型文件系统需要耗费数天时间，比如，对于一个拥有17000000文件数量的文件系统，一次遍历需要耗时31h。这使得数据库中存储的文件元数据信息过于滞后而无法使用。

1．2集群管理调度器

TORQUETORQUE作业管理系统是Clustering公司接管了开源软件OpenPBS，提供后续支持的一个开源版本。TORQUE作业管理系统架构如图2所示。如图2所示，TORQUE作业管理系统包含一个主节点(HeadNode)和多个计算节点(ComputeNode)。在主节点上运行着PBS_Server进程，而在计算节点上运行PBS_Mom进程。客户端的命令(Command)可以安装到任意节点上(包括没有运行PBS_Server或者PBS_Mom的节点)。在主节点上还运行着Scheduler进程。Scheduler与PBS_Server共同管理集群计算资源的使用以及作业的分配。目前，多数TORQUE的使用者选择更加高级Maui［7］或者Moab［8］替代内置FIFO(先入先出)策略的Scheduler。用户通过qsub命令向PBS_Server提交作业。当PBS_Server接收到作业后，先将作业排入等待执行队列，然后由Scheduler负责从PBS_Server中获取作业、队列、计算资源信息，并将作业与可用计算资源进行匹配，PBS_Server根据资源匹配的结果将作业分配给PBS_Mom。PBS_Mom接收PBS_Server分发的作业，并管理作业在本地执行。TORQUE作业管理系统周期性地向空闲计算节点推送作业。当作业在计算节点执行完毕后，由PBS_Mom向PBS_Server报告该节点资源使用情况，PBS_Server收到信息后将该节点的计算资源标示为空闲，并等待下一调度周期的到来。如果一个作业的执行时间过短，即远小于一个调度周期时间，则计算节点在执行完该作业后将处于饥饿状态，使得集群的计算资源利用率过低，因此，TORQUE作业管理系统更适合运行时间长于调度周期的作业。

2文件管理工具的设计与实现

为了解决单台计算机遍历文件系统的性能瓶颈，本文根据分布式计算的要求对Robinhood进行改进，下文简称为改进的Robinhood。图3展示了本文工具的拓扑结构，各个节点通过网络相互连接。在每个计算节点上部署了改进的Robinhood，它根据目录切分算法实现了文件系统目录树的自动切分，并将符合条件的目录树以作业的形式向PBS_Server提交，从而实现了对文件系统的多任务并行遍历。MulticastServer基于TCP/IP网络编程技术实现。它通过调用TORQUE提供的命令接口，获取PBS_Server上的作业队列信息(作业排队数，作业运行数等)，然后将信息发送到改进版的Robinhood。数据库(Database)部署在一台专用计算机上，改进的Robinhood收集的元数据信息最终汇总到数据库中。

2．1改进的Robinhood

改进的Robinhood实现分布式计算需要2个必要条件:(1)将一棵大的目录树切分成多棵独立的小目录树;(2)与TORQUE作业管理系统集成:将切分好的目录树以作业的形式提交给TORQUE作业管理系统，实现分布式计算。2．1．1基于组播通信的队列信息获取遍历文件系统的作业在运行期间，需要根据PBS_Server的当前作业队列信息对文件系统目录树进行切分，提交新的遍历作业。如果所有运行Robinhood的计算节点都向PBS_Server查询当前作业信息，将会对PBS_Server造成严重的额外负担，影响它的服务质量。为了解决这个问题，本文采用一个独立组播服务器(MulticastServer)向PBS_Server查询队列状态信息，并以组播方式将消息推送给改进的Robinhood。2．1．2文件系统目录树的切分算法运行时间过短的小作业会造成集群的作业调度效率低下，本文在实现上应尽量避免产生过多的小作业。对于一棵目录树来说，最大的目录是根目录，最小的目录是包含文件数最少的叶子目录，某个目录在文件树中所处的层次(即深度)在一定程度上决定了该目录的大小。基于此，本文提出以下假设:目录的大小与目录的深度有关:目录深度越小，则该目录是大目录的可能性越大;目录深度越大，则该目录是大目录的可能性越小。在算法的设计过程中，首先要考虑的是大目录的定义标准，即当前目录的深度是小于多少才算大目录。规定一个确切的数字显然是不合理的，因为不同的文件系统目录树的形状会有很大差异，所以需要设计一个动态调整算法，自适应不同形状的目录树。对目录进行合理切分并按切分结果提交作业，使得每个作业运行的时间合适是保证改进的Robinhood高效运行的关键。如果切分的目录过大，会造成PBS_Server上排队作业数目极少，甚至没有;但是，如果切分的目录过小，则导致排队的作业数增多，作业运行时间过短。所以，大目录判定的阈值越小，产生的作业数越少;大目录判定阈值越大，产生作业数越多。由此，本文提出了动态调整目录切分与排队作业数量的算法，通过获取的实时作业排队数，动态调整判定大目录的阈值。基于目录切分与作业排队数的算法流程如图4所示。算法涉及的变量如表1所示。算法描述如下:(1)初始化阈值(DNum)。DNum的初始值不应设置过大，对于千万级别文件数量的文件系统，缺省值为5，这是一个经验值，在算法的运行过程中自动调整大小。(2)比较当前作业排队数(Queue_num)和最大作业排队数(QMaxNum)。如果Queue_num小于QMaxNum，则跳到第(3)步;如果Queue_num不小于QMaxNum，则跳到第(6)步。(3)调用函数获取当前目录的深度，跳到第(4)步。(4)比较当前目录深度(depth)和阈值(DNum)。如果depth小于DNum，则跳到第(5)步;如果depth不小于DNum，则跳到第(6)步。(5)调用相关接口，生成作业，并向TORQUE提交作业。(6)比较当前作业排队数(Queue_num)和最小作业排队数(QMinNum)。如果Queue_num小于QMinNum，则跳到第(7)步;如果Queue_num不小于QMinNum，则跳到第(9)步。(7)PBS_Server上的排队作业数过少，说明大作业的要求太严苛了，需要放松要求，增大阈值DNum，增大的步长为1。接着跳到第(10)步。(8)比较当前作业排队数(Queue_num)和最大作业排队数(QMaxNum)以及判定DNum。如果Queue_num大于QMaxNum而且DNum大于1，则跳到第(9)步;反之，跳到第(10)步。(9)PBS_Server上排队作业数过多，说明DNum数值过大，产生了过多作业;或者文件系统即将遍历结束。此时需要减小DNum，减小的步长为1。接着跳到第(10)步。(10)当前目录本地遍历，直至结束。

2．2工具的扩展性

文件系统数据保存到数据库后，使得文件系统信息的获取更加方便快捷。利用数据库的特性，可以对系统的功能进行扩展。例如:(1)生成特定格式的文件列表，供相关备份软件进行文件备份;(2)通过Web形式，对系统信息进行可视化展示，实现系统监控;(3)实时分析数据库中文件系统元数据信息，动态调整用户使用文件系统策略，对文件系统进行更细粒度的管理等。2．2．1系统备份功能扩展马里兰高级自动网络磁盘存档工具(Amanda)［9］通过系统管理员配置主备份服务器，对网络上主机的文件系统实施备份。Amanda本身并不是备份程序，它其实只是管理其他备份软件的封装软件，比如，对于Linux操作系统，Amanda通过调用系统命令tar或dump对本地文件进行打包备份。本文工具集成了Amanda，提供快速备份功能。对于同一个文件系统，Amanda只能以单任务的形式对文件进行备份，即使有富余的计算资源也无法使用。由于数据库中保存着文件系统的元数据信息，通过对数据库的查询可以分析出文件系统的目录结构，那么可以事先对文件进行切分，实现Amanda在多台计算设备同时备份同一文件系统的不同部分，从而提高文件系统的备份效率。2．2．2Web监视功能扩展根据数据库中的信息，可以进行相关的统计归类工作，得出系统中每个用户、每个组的文件数目等信息。通过PHP［10］和HTML5［11］技术，将这类信息很直观地以图形的方式在网页上展示。除了网页上固定显示的信息，管理员还可以在网页上通过搜索功能自定义查询数据库中的数据。2．2．3文件系统管理本文通过用户自定义管理策略，定期查询数据库中的文件元数据信息，与管理员自定义策略进行匹配，并执行相关的管理操作。基于数据库的文件系统管理，能快速获取系统状态，及时响应管理员的管理需求。

3系统评估测试

系统所使用的软件版本为Robinhood2．4．0，TORQUE2．5．5，MySQL．x86_64。计算节点的操作系统版本为ScientificLinux5．5。各个计算节点的配置为:8×2．67GHz的CPU，24GB内存，千兆以太网卡。部署MySQL数据库的节点配置为:8×2．67GHz的CPU，24GB内存，千兆以太网卡。网络上的计算设备通过千兆光纤相连。

3．1遍历速率与最大作业运行数的关系

测试的是AFS文件系统［12］，文件系统中保存了17000000左右的用户数据文件。通过设置不同最大作业运行数分别进行测试。如图5所示，最大作业运行数与遍历速率成正相关。在最大作业运行数为16时是一个转折点，在此之前它基本是一个线性上升的态势，当最大作业运行数大于16以后，曲线趋于平稳。图6展示了最大作业运行数与数据库负载关系，可以看到数据库负载和最大作业运行数成正相关。当最大作业运行数达到24时，数据库服务器负载达到满负荷状态。

3．2实验结果分析

图5结果显示，当最大作业运行数小于16时，遍历速率以线性方式增长，以后趋于平稳，说明随着并发作业数的增加，遍历速率在前期有一个线性增长的过程，后期趋于一个极限值。图6显示的数据库负载与最大作业运行数成正相关，当最大作业数大于16时，数据库的负载接近满负载状态。通过对比图5和图6可以发现，当数据库的负载在达到满负载之前，遍历的速率会随着最大作业运行的增加而增大;而当数据库达到满负载之后，遍历速率基本也不再上升。

3．3实验结论

通过以上分析结果，可以得出以下结论:(1)本文设计的系统表现出了良好的文件遍历性能，当数据库的负载达到峰值的时候，本文工具的遍历速率约为每秒2600个，是单作业(速率约为每秒530个)的4．9倍。(2)当前MySQL数据库性能是本文系统的瓶颈，它的性能决定了系统遍历速率的上限。

4结束语

本文针对目前集群系统海量数据管理的需求，提出了基于TORQUE作业管理系统和策略引擎Robinhood的文件系统管理方案，并基于此方案开发部署管理工具。实际测试表明，该工具能有效地提高文件遍历以及备份速率，同时以Web的形式直观展示数据，给系统监视带来便利。但当遍历文件目录树的作业数量达到一定数量后，MySQL数据库的I/O效率将成为瓶颈，造成数据的I/O等待。因此，改变数据存储架构、提高数据库的I/O效率是下一步的研究方向。

作者：石京燕 陈德清 单位：中国科学院高能物理研究所 中国科学院大学