一种基于多GPU管理分布式文件系统元数据的方法

一种基于多gpu管理分布式文件系统元数据的方法
技术领域
1.本发明涉及大规模存储的文件系统领域，尤其涉及一种基于多gpu管理分布式文件系统元数据的方法。


背景技术：

2.近几十年来，高性能计算应用蓬勃发展，其依托的超级计算机的计算节点不断增多，这对底层分布式文件系统的性能，尤其是元数据处理的性能造成了巨大的挑战。运行在数以万计计算节点上的并行进程在运行过程中，会在短时间内向底层分布式文件系统发送海量的i/o请求，而在这些i/o请求中，针对元数据的请求(如创建文件、打开文件、查看文件属性等)占了50％以上。当前的分布式文件系统多采用单独的元数据服务器来管理整个文件系统的名字空间并处理所有的元数据请求，短时间内大量的元数据请求使得元数据服务器成为了整个系统的瓶颈，制约着文件系统以及上层应用的整体性能的提升。


技术实现要素：

3.为了解决上述技术问题，本发明的目的是提供一种基于多gpu管理分布式文件系统元数据的方法，能够有效提升分布式文件系统元数据服务的性能。
4.本发明所采用的第一技术方案是：一种基于多gpu管理分布式文件系统元数据的方法，包括以下步骤：
5.构建异构元数据服务器架构；
6.所述异构元数据服务器架构包括cpu控制器、gpu加速器和持久化存储介质；
7.将文件系统的元数据存储在gpu加速器的显存中并选用level哈希组织目录存储结构；
8.基于目录存储结构，完成元数据请求。
9.进一步，还包括：
10.cpu控制器，用于接收元数据请求、将预设时间间隔内的元数据请求打包发送至gpu端；
11.gpu加速器，用于进行元数据存储与元数据请求的处理；
12.持久化存储介质，用于元数据以及元数据请求进行持久化。
13.进一步，所述目录存储结构包括顶层和底层，所述顶层和底层均由哈希桶构成，所述哈希桶中设有槽位。
14.进一步，所述元数据请求包括查找、删除和插入。
15.进一步，查找步骤包括：
16.根据元数据请求获取父目录的索引节点(inode)编号、子目录路径名称、第一哈希值和第二哈希值；
17.启动线程束(warp)进行查找，以线程束(warp)中的线程作为通道对哈希桶的槽位进行查找；
18.根据父目录的索引节点(inode)编号在索引节点(inode)映射中找到对应的level哈希结构；
19.判断到该通道属于前16个通道，根据第一哈希值计算在顶层中需要查找的哈希桶编号，判断到该通道属于后16个通道，根据第二哈希值计算在顶层中需要查找的哈希桶编号；
20.根据该通道对应的槽位编号，读取槽位对应存储信息；
21.判断到输入的哈希值以及路径名称均与槽位对应存储信息相同，确定该请求在本通道中查找成功并将查找结果写入本请求在输出缓冲中对应的位置；
22.将查找成功的信息同步至所有通道，若某个通道查找成功，则查找结束，否则进行下一步；
23.判断到该通道属于前16个通道，根据第一哈希值计算在底层中需要查找的哈希桶编号，判断到该通道属于后16个通道，根据第二哈希值计算在底层中需要查找的哈希桶编号；
24.根据该通道对应的槽位编号，读取槽位对应存储信息；
25.判断到输入的哈希值以及路径名称均与槽位对应存储信息相同，确定该请求在本通道中查找成功并将查找结果写入本请求在输出缓冲中对应的位置；
26.将查找成功的信息同步至所有通道，若某个通道查找成功，则查找结束，否则本次请求查找失败。
27.进一步，删除步骤包括：
28.基于通道查找子目录，查找到需要删除的子目录，确认该子目录是否为空；
29.确认到该子目录为空进行删除；
30.在父目录对应的level哈希结构中将该子目录的元数据删除；
31.将该子目录对应的level哈希结构归还至目录池中，并解除该子目录索引节点(inode)与对应level哈希结构的映射。
32.进一步，插入步骤包括：
33.根据元数据请求获取父目录的索引节点(inode)编号、子目录路径名称、第一哈希值、第二哈希值和子目录的元数据；
34.启动线程束(warp)进行查找，以线程束(warp)中的线程作为通道对哈希桶的槽位进行插入；
35.根据父目录的索引节点(inode)编号在索引节点(inode)映射中找到对应的level哈希结构；
36.判断到该通道属于前16个通道，根据第一哈希值计算在level哈希顶层中需要查找的桶编号，判断到该通道属于后16个通道，根据第二哈希值计算在level哈希顶层中需要查找的桶编号。
37.根据该通道对应的槽位编号，读取对应的槽位，得到槽位是否为空的信息。
38.将该通道对应的槽位是否为空的信息同步至所有通道中，判断到顶层两个哈希桶中存在空槽位，随机选择一个负责的槽位为空的通道进行插入操作；
39.若本通道被选为执行插入操作的通道并且对本槽位上锁成功，检查本槽位是否依然为空；
40.判断到本槽位为空，将请求插入的子目录元数据信息写入槽位中，同时增加本请求对应父目录的子文件或子目录的数量，插入请求执行成功；
41.将插入是否成功的信息同步至所有通道；
42.判断到顶层两个哈希桶中不存在空槽位，在底层中尝试进行插入操作。
43.本发明方法的有益效果是：本发明通过异构的元数据服务器纵向扩展元数据服务性，避免了使用横向扩展时的网络通信开销和分布式一致性问题，充分利用了gpu众核处理器的访存和计算性能来提高元数据处理的性能，另外，选用了面向gpu友好的数据结构以及设计了面向gpu优化的元数据处理算法，能够保证查找和删除请求的性能的稳定。
附图说明
44.图1是本发明一种基于多gpu管理分布式文件系统元数据的方法的步骤流程图；
45.图2是本发明具体实施例元数据服务器架构图；
46.图3是本发明具体实施例选用level哈希组织目录存储结构图；
47.图4是本发明具体实施例完成元数据请求的算法示意图；
48.图5是本发明具体实施例目录并行扩容示意图；
具体实施方式
49.下面结合附图和具体实施例对本发明做进一步的详细说明。对于以下实施例中的步骤编号，其仅为了便于阐述说明而设置，对步骤之间的顺序不做任何限定，实施例中的各步骤的执行顺序均可根据本领域技术人员的理解来进行适应性调整。
50.本发明设计了一种基于多gpu管理分布式文件系统元数据的方法，使用异构的元数据服务器架构，选用面向gpu优化的数据结构组织文件系统的名字空间，设计了面向gpu加速的算法优化元数据处理的吞吐量；并充分利用元数据服务器中多块gpu的计算和存储能力。
51.如图1所示，本发明提供了一种基于多gpu管理分布式文件系统元数据的方法，该方法包括以下步骤：
52.s1、构建异构元数据服务器架构；
53.所述异构元数据服务器架构包括cpu控制器、gpu加速器和持久化存储介质；
54.具体地，为了充分利用gpu的硬件特性来达到加速元数据处理性能的目的，本发明使用一种异构的元数据服务器架构。通过纵向扩展单台元数据服务器的性能来突破整个系统的元数据处理瓶颈。参照图2，展示了本发明中元数据服务器的整体架构，从图中可以看到，元数据服务器包含三个组成部分：第一个是cpu控制器，第二个是gpu加速器，第三个是持久化存储介质，比如这里我们使用ssd。
55.s2、将文件系统的元数据存储在gpu加速器的显存中并选用level哈希组织目录存储结构；
56.具体地，本发明将文件系统的元数据存储在gpu的显存中，选用一种对gpu友好的哈希结构组织一个目录。这样，对于一个父目录下子目录或子文件的查找、创建和删除就转化成了对于哈希表的查找、插入和删除操作。其中，哈希表的键是子目录或子文件路径名称的哈希值，值是该子文件或子目录的元数据，比如inode号，访问权限等等。
57.本发明选用的对gpu友好的目录存储结构是level哈希。其具体结构如图3所示，它分为两层，称为顶层和底层，每个具有4个槽位的矩形代表一个哈希桶，而每个哈希桶旁的数字代表该哈希桶存储的数据项哈希值的最低几位。level哈希的顶层有2^n个哈希桶，而底层有2^(n-1)个哈希桶，n为正整数。如图3所示，顶层中的两个桶与底层中的一个桶用直线连接，代表它们共同来解决一个数据项插入时的哈希冲突。每个哈希桶中具有多个槽位，比如图3中每个桶中有4个槽位。每个槽位可以存放一个子文件或子目录的元数据。level哈希使用两个哈希函数hash1(x)和hash2(x)来确定一个数据项的候选位置，这样，当有新的子目录需要创建时，首先根据两个哈希函数计算出子目录名称的两个哈希值h1和h2，然后根据哈希值计算出顶层中两个插入的候选桶的位置loct1＝h1％(2^n),loct2＝h2％(2^n)。比如这里要在图3所示的目录下创建新的子目录，根据计算其在顶层中的候选桶是标号为001和110的两个桶，若两个桶中有空的槽位可以插入，子目录便创建成功；否则，计算该子目录在底层中的两个候选桶位置locb1＝h1％(2^(n-1)),locb2＝h2％(2^(n-1))，即底层中标号为01和10的两个桶，若这两个桶中有空槽位可以插入，子目录也创建成功。对于查找和删除操作，只需要到顶层和底层中的共四个候选桶中查找是否存在查找和删除的数据项并进行相应操作即可。
58.在插入一个新的数据项时，若四个候选桶中的槽位都已经满，就需要对哈希表进行扩容。扩容时，若顶层有2^n个哈希桶，则分配一块新的空间作为新的顶层，其具有2^(n+1)个哈希桶；此时，原来的底层(有2^(n-1)个哈希桶)被称为过渡层，原来的顶层(有2^n个哈希桶)便成为了新的底层，只需要把过渡层的所有数据项都重哈希到新的顶层和新的底层即可，当完成过渡层所有数据项的重哈希后便可将过渡层的空间释放，此时新的顶层和新的底层便构成了扩容后新的哈希表。采用这种扩容方式扩容后的哈希表容量是扩容前的两倍，需要重哈希的数据项是原底层中的所有数据项，它占整个原哈希表数据项总数的比重是三分之一。若扩容倍数大于2时，则需要分配新的顶层以及新的底层，然后将所有数据项进行重哈希，最后释放原顶层和原底层；此时重哈希的数据项是原哈希表中所有的数据项。
59.在gpu上使用level哈希来组织目录结构的好处有以下几点：第一，单个哈希桶中有多个槽位，使得查找、插入和删除操作有了并行的可能；第二，由于使用了多槽位的哈希桶以及双层结构处理哈希冲突，level哈希的空间利用率能够保持在较高的水平，适合于内存容量相对有限的gpu；第三，单个哈希桶的多个槽位在内存中是紧密排布的，这对于gpu的并行访存模式来说十分友好。第四，level哈希在进行两倍扩容时只需要重哈希三分之一的数据项，这个特性对于大目录(如包含百万级别子文件数量的目录)的扩容性能来说是十分重要的。因为大目录本身包含的子目录和子文件数量已经很多，每次扩容只需要扩大两倍就足够，每次对大目录进行扩容时要尽量保证重哈希的数据项比重不要太大。
60.s3、基于目录存储结构，完成元数据请求；
61.面向gpu优化的元数据处理算法，这里首先说明gpu处理的一批元数据请求在cpu端是如何打包的，即元数据处理算法的输入是什么。cpu会收集一个时间间隔t内的所有元数据请求，并根据请求类型进行分类。比如创建文件、查找文件和删除文件分为不同的三类请求。当一个时间间隔t结束时，cpu将打包好的同类型请求一并发送到gpu端并启动gpu核函数进行处理。每个核函数只处理一种类型的请求，当一类请求处理完成后，cpu再将另一
种类型的请求打包发送至gpu并启动核函数进行处理。以上过程中，数据的传输和计算的过程经过优化可以并行。在输入的请求中，使用父目录的inode编号表示一个元数据请求是在哪一个父目录下进行的。在gpu内部可以使用一个简易的哈希表，如链式哈希将父目录的inode编号与对应目录的level哈希结构进行映射，该映射被称为inode映射。图4是面向gpu优化的算法示意，其中warp是gpu调度时的最小执行单元，一个warp中有32个线程，它们总是并行执行相同的指令，并且具有高效的同步与通信机制。一个warp中的多个线程可以并行参与数据项的搜索、查找和插入过程。与图4中略有区别的是，本发明中每个哈希桶的槽位数量是16，这样每一层中的两个候选桶中的槽位数量刚好是32，即gpu中一个warp下的线程数量。为了提升创建目录的性能，本发明使用了预先分配好的目录池，池中有许多初始化好的level哈希结构。当创建新的子目录时可以从目录池中直接获取预先初始化完毕的level哈希结构，在删除子目录时也要将对应的level哈希结构归还至目录池中。
62.s4、cpu请求调度与负载均衡。
63.具体地，为了充分利用元数据服务器中多台gpu的计算和存储性能，本发明在目录扩大到一定阈值时，会将目录分裂到多个gpu中，在插入阶段结束后，需要进行分裂的目录会记录自己的inode编号，并将对应的目录结构记录下来传输给cpu，cpu根据不同gpu中需要分裂的目录记录，结合不同gpu的计算和存储负载进行分裂，使得分裂能够在保持多个gpu负载均衡的前提下尽量移动少的数据。不同gpu之间的通信可以使用nvlink，它对比传统的pcie有着更大的带宽，能够使得目录分裂的过程尽量不会影响正常的请求处理。
64.目录分裂后，需要cpu端对客户端到来的请求进行正确的转发，使得元数据请求能够被传送到存储该元数据的gpu中执行。鉴于文件系统中文件的特性，即绝大部分目录都是小目录，它们对应的目录结构不会分布在多个gpu中；所以大目录的分裂对于cpu端请求转发增加的压力不会太大，但是却可以充分利用多台gpu的计算和存储能力，提高系统处理大目录的性能。此外，在cpu调度请求到gpu执行的过程中，应当使得不同gpu核函数之间的数据传输和计算的过程并行来达到最佳的性能。
65.对于cpu调度的周期t的选取，应当注意，它的具体值的设置是吞吐量和时延之间的一个平衡。t较大时，cpu在一个调度周期内可以积累更多的元数据请求，能取得更高的吞吐量，但是对于每个元数据请求来说，等待的延迟都会增大。相反若t较小，每个元数据请求的延迟都相应地减小，但是每一批次的请求数量会很少，导致难以高效利用gpu的硬件特性；同时，cpu与gpu之间的数据传输的时间在整个处理过程中会占较大的比重。对于t的具体数值的选取，应依赖于元数据服务器本身的性能与其所配备gpu的硬件配置，以及具体的应用场景。可以根据实验进行调优。
66.进一步作为本方法的优选实施例：
67.元数据服务器的三个部分角色各不相同。其中，cpu端负责从网络接收文件系统客户端发送的元数据请求，将请求转发到gpu端并启动gpu核函数进行处理；当处理结果从gpu端传送回cpu端之后，cpu再通过网络将结果回复给对应的文件系统客户端。为了充分利用cpu与gpu之间的pcie的传输特性，cpu会将一个时间间隔内的元数据请求打包发送到gpu端，这个时间间隔称为t，也叫cpu的调度周期。gpu负责具体的元数据存储与元数据请求的处理，比如创建文件、查找文件和删除文件等等。当gpu接收到cpu转发而来的一批元数据请求后，启动的大量gpu线程会并行地处理这批元数据请求，这样便可以充分利用gpu的并行
性，达到加速元数据处理请求的目的。ssd负责对元数据以及元数据请求进行持久化。尽管元数据已经被全部存储在了gpu端，但是为了防止系统崩溃造成数据丢失，大部分分布式文件系统还是会在一些周期性的检查点将元数据整体存储到持久化存储介质中，并且将所有的元数据请求以日志的方式写入存储介质；这样当系统发生崩溃时，只需要将最近检查点的元数据转发至gpu端，并按照时间顺序重做最近检查点之后的所有元数据请求，便可以恢复出整个系统崩溃前的元数据。本发明也采用这种方式来保证系统的崩溃一致性。
68.进一步作为本方法的优选实施例，查找步骤包括如下：
69.对于查找算法来说，每一个请求的输入包含一个父目录的inode编号i，子目录或子文件路径名称p，以及对应的两个哈希值：第一哈希值h1与第二哈希值h2，查找结果是对应子目录或子文件的元数据信息。对于一批查找请求中的每个请求，启动一个warp来进行并行查找；一批请求中的不同查找请求之间也是并行的。在gpu中，warp中的每个线程被称为一个通道，每个warp有32个通道，每个通道负责一层两个候选桶中的一个槽位，该槽位在桶中的编号称为槽位编号。其中前16个通道共同负责一个哈希桶的查找，后16个通道负责同层中另一个哈希桶的查找。对于一个通道来说，其搜索的整体流程如下：
70.(1)根据父目录的inode编号i在inode映射中找到对应的level哈希结构。
71.(2)若本通道属于前16个通道，根据h1计算在level哈希顶层中需要查找的桶编号；否则本通道属于后16个通道，根据h2计算在level哈希顶层中需要查找的桶编号。
72.(3)根据本通道负责的槽位编号，读取本通道负责的桶中对应的槽位。若输入的哈希值以及路径名称都与本槽位存储的相同，则请求在本通道中查找成功，将查找结果写入本请求在输出缓冲中对应的位置。
73.(4)将查找是否成功的信息同步到所有通道中，若某个通道查找成功，则查找结束。否则继续下一步。
74.(5)若本通道属于前16个通道，根据h1计算在level哈希底层中需要查找的桶编号；否则本通道属于后16个通道，根据h2计算在level哈希底层中需要查找的桶编号。
75.(6)根据本通道负责的槽位编号，读取本通道负责的桶中对应的槽位。若输入的哈希值以及路径名称都与本槽位存储的相同，则请求在本通道中查找成功，将查找结果写入本请求在输出缓冲中对应的位置。
76.(7)同步查找是否成功的信息到所有通道中，若有某个通道查找成功，则查找结束；否则本次请求查找失败。
77.进一步作为本方法优选实施例，删除步骤具体包括：
78.处理删除请求与处理查找请求类似，唯一不同之处在于某通道若查找到需要删除的子目录时，需先确认该子目录为空，若该子目录不为空则删除失败。此外，不仅需要在父目录对应的level哈希结构中将该子目录的元数据删除，也要将该子目录对应的level哈希结构归还至目录池中，并解除该子目录inode与对应level哈希结构的映射。若该level哈希结构已经扩容过，则需要释放该level哈希结构，经过重新初始化之后再归还该level哈希结构至目录池。
79.进一步作为本方法优选实施例，插入步骤包括：
80.对于插入算法来说，每一个请求的输入包含一个父目录的inode编号i，子目录或子文件路径名称p，对应的两个哈希值h1与h2，以及子目录或子文件的元数据。对于同一批
次的插入请求来说，可能其中的部分插入请求可以成功，但是另一部分插入请求由于父目录下的四个候选桶全满会导致插入失败，这时需要对相应的父目录进行扩容。所以对于同一批插入请求，本发明将其插入的过程分为三个阶段：第一阶段是初次插入阶段，第二阶段是目录扩容阶段，第三阶段是再次插入阶段。为了减少gpu启动核函数的开销，这三个阶段都在同一个核函数中完成，每完成一个阶段之后所有gpu线程都要进行同步操作。在初次插入阶段插入失败的请求会在再次插入阶段第二次尝试插入，为了使所有在初次插入阶段失败的请求在再次插入阶段都能插入成功，本发明在初次插入时需要统计某个父目录下插入失败的数量，并结合该父目录已经插入的数量以及该父目录的容量决定扩容的倍数。初次插入阶段会将所有本批次需要扩容的目录上报至一个扩容任务池中，该池中的每一个任务包含需要扩容的目录以及扩容该目录需要的warp数量，这样在第二阶段，所有warp就可以从扩容任务池中拉取扩容任务进行扩容。这种做法的好处是在扩容阶段可以充分复用所有的插入线程，合作完成该批次插入请求的所有扩容任务，提高扩容的效率。
81.由于可能存在有不同的请求向相同的槽位并发插入的情况，所以在向某个槽位插入之前需要先将该槽位上锁，插入完成后再将该槽位解锁。在初次插入阶段需要先对该请求插入的四个候选桶进行查重操作，查重的流程与查找的流程相同。若存在重复，则插入失败。下面对初次插入和扩容阶段的流程进行说明，再次插入阶段和初次插入阶段的流程类似。
82.对于负责插入的warp的其中一个通道来说，初次插入阶段的流程如下：
83.(1)根据父目录的inode编号i在inode映射中找到对应的level哈希结构。
84.(2)若本通道属于前16个通道，根据h1计算在level哈希顶层中需要查找的桶编号；否则本通道属于后16个通道，根据h2计算在level哈希顶层中需要查找的桶编号。
85.(3)根据本通道负责的槽位编号，读取本通道负责的桶中对应的槽位，若本通道负责槽位为空，则在该桶中找到了一个可以插入的空槽位。
86.(4)将本通道负责的槽位是否为空的信息同步到本warp的所有通道中，若顶层两个桶中存在空槽位，随机选择一个负责的槽位为空的通道进行插入操作；若顶层两个桶中不存在空槽位，则跳至第(7)步。
87.(5)若本通道被选为执行插入操作的通道并且对本槽位上锁成功，检查本槽位是否依然为空(防止本槽位被上锁前已被其他线程插入)。若本槽位为空，将本请求插入的子目录或子文件元数据信息写入槽位中，同时增加本请求对应父目录的子文件或子目录的数量；如果插入的是子目录，还需要从目录池中获取一个新的目录结构，并在inode映射中建立映射，插入操作全部完成后可解锁本槽位，此时插入请求执行成功，插入结束。若上锁失败或上锁成功后发现本槽位不为空(上锁成功后发现本槽位不为空也要进行解锁操作)，则插入请求失败。
88.(6)同步插入是否成功的信息到所有通道；若本warp对应的请求插入失败，跳至ii。
89.(7)在底层中尝试进行插入操作。
90.以上是插入的整体流程，若在顶层中插入失败，则进入底层进行插入，在底层中插入的流程与在顶层中相同。若在底层中也插入失败，则增加本请求对应的父目录的插入失败的计数器，并向重哈希任务池中添加该父目录以及重哈希该父目录需要的warp数量。对
于需要扩容的父目录，从所有向该父目录插入的warp中挑选一个主warp，再从主warp中随机挑选出一个主通道，由该通道结合统计量(父目录的插入失败数量、已插入成功的数量和目录容量等)计算目录需要扩容的倍数，并对父目录对应的level哈希结构进行扩容所需要的内存空间分配。
91.第一阶段结束后所有gpu线程需要进行一轮同步操作。之后进入重哈希阶段。此时所有线程都会从任务池中拉取重哈希任务，并根据自己的warp编号计算本warp需要重哈希哪两个哈希桶中的数据项。每个通道会根据自己负责的槽位进行数据项的重哈希。
92.对于某一个哈希桶来说，对其扩容操作也是并行的。比如图5中的桶中有4个槽位，每个槽位数据项的重哈希由warp中的一个线程负责。进行两倍扩容时若要将数据项从过渡层的某个桶重哈希到新的顶层中，该槽位的数据项在新的顶层中会有四个候选桶，为了保证同一个过渡层桶中不同的数据项在重哈希时不会在新的桶中发生写的冲突，重哈希的数据项在新桶中的槽位编号需与原桶中的槽位编号相同。如图5中过渡层桶中第三个槽位的数据项重哈希时在新的桶中槽位编号也是第三个。
93.第二阶段，即扩容阶段结束前，之前负责扩容前内存空间分配的通道将对应父目录level哈希结构中的过渡层空间进行释放；扩容阶段结束后所有gpu线程要进行一轮同步，之后进入第三阶段，第三阶段与第一阶段过程类似。三个阶段结束后，在gpu内存空间充足的情况下应能保证所有该批次的插入请求都执行成功。
94.以上是对本发明的较佳实施进行了具体说明，但本发明创造并不限于所述实施例，熟悉本领域的技术人员在不违背本发明精神的前提下还可做作出种种的等同变形或替换，这些等同的变形或替换均包含在本技术权利要求所限定的范围内。