hadoopcore1.9.28詳細設計HDFS2一期詳細設計

1、hdfs2 详细设计文档名称hdfs2 详细设计作者孙桂林版本0.8文档提交日期2010-09-1319hdfs2 详细设计11 背景32 设计目标33 设计方案33.1 整体架构33.2 命名空间管理43.2.1 树状命名空间43.2.2 平坦命名空间63.3 文件管理服务（fms）63.3.1 元数据存储73.3.2 元数据加载73.3.3 元数据访问83.3.4 pool信息管理93.3.5 全局信息管理103.3.6 集群管理103.3.7 副本状态维护133.3.8 心跳机制143.4 权限管理143.5 配额管理143.6 文件操作场景153.6.1 文件创建153.6.2 文件读

2、取163.6.3 文件写入173.6.4 文件拷贝173.6.5 文件删除183.6.6 目录删除183.6.7 目录拷贝191 背景项目先期已经形成了分离文件管理和命名空间管理的设计方案，通过分离可以做到文件管理服务（fms）的水平可扩展，并大幅度降低namenode的内存和负载压力，预计可以承载10亿的文件规模。后续暂时挂起了fms水平扩展的设计，在本期只考虑单命名空间单fms的情况。demo版本的设计开发已经结束，从目前的验证结果来看，分离文件管理和命名空间管理的设计方向具备可行性，但fms相比原namenode并不具备内存优势，因此当前的单fms+namenode的组合实用价值不大，不

3、适合投入稳定版本的开发。hdfs2的主要思想是用类似hbase的分布式共享存储来解决scalability的问题，尤其是文件管理的scalability问题。它也建立在文件管理和命名空间管理分离的基础之上，可能需要对hdfs的块管理做完全重新的设计。2 设计目标hdfs2的设计目标包括可扩展的海量存储；良好的系统容错性；大规模流式读写良好支持；小数据量随机读的良好支持；更好的客户端容错和持久化记录追加。其中一期的主要目标仍然是scalability，以支撑更大规模的数据存储。相对于namenode分布式化项目，hdfs2可以提供统一的元数据分布式化存储。3 设计方案3.1 整体架构如下图所示，

4、hdfs2将对hdfs做大范围的修改，其中一方面基于namenode分布式化的成果，将文件管理服务（fms）与命名空间剥离，这样，命名空间只负责目录树管理，fms只记录平坦的文件inode信息，相当于所有文件都在根目录下的namenode。如此命名空间管理所需的内存和职责都大幅度减少，甚至在96gb内存的服务器上，已经可以承载1万节点、10亿文件的集群规模。而fms由于数据已经平坦化，可以很容易地做到水平扩展。另一方面，对文件管理服务基于hbase共享存储重新设计，通过hbase来存储元数据信息，以取代fsimage和editlog，这样有利于保证元数据的可靠性和一致性。3.2 命名空间管理3

5、.2.1 树状命名空间fms之上可以构建多种命名空间，包括树状的命名空间、类似于s3的平坦式命名空间，或者其它的定制化命名空间。这是独立出fms的最大好处之一，未来s3式的命名空间，可以提供非常大规模的数据存储服务。剥离了fms的namenode，其主要职责只剩下了目录树管理，其中要为文件节点记录其基本块列表信息，这部分的实现可以大量重用现有的设施。3.2.1.1 数据结构namenode中需要维护完整的目录树，主要是inodefile和inodedirectory两类对象，其中，inodefile信息如下表所示：名称类型说明namebyte名称poolidshort指示对应的块、文件管理服务

6、fidlong唯一标识的inodeid经验证，上述结构的inodefile对象的浅内存占用为24个字节，另外，先前的集群统计中，发现文件名的byte数组平均占用内存为47个字节，经yjp对照分析，在byte数组平均长度为30的时候内存占用和此比较吻合，因此，一个inodefile对象的内存占用为71个字节。在10亿文件的数据规模下，inodefile所占的内存总和将达到66gb。这些数据可以在单机的内存进行存储。从当前的inodefile里移除的数据包括parent、modificationtime、accesstime、blockreplication、permission、blocks和p

7、erferredblocksize：名称类型移除原因parentinodedirectory经代码分析，parent的作用主要是为了某些操作需要addchild和removechild，可以通过改编少量api来节省此处内存占用。modificationtimelong移至文件管理层accesstimelong移至文件管理层blockreplicationshort移至文件管理层permissionlong命名空间中只保存目录的权限，文件的permission移至文件管理层blocksblockinfo块列表信息移至文件管理层perferredblocksizelong移至文件管理层inoded

8、irectory结构和当前基本保持不变。在这种数据结构下，我们可以估算出，达到1万个节点，10亿文件的集群规模时，inodefile将耗费66gb的内存，inodedirectory耗费1gb左右的内存，因此在目标集群规模下，单节点内存可以存放所有的命名空间数据。3.2.1.2 请求负载下表中给出了当前namenode中耗费cpu时间最多的操作在本方案下的情况：操作req/s说明耗费cpu比例blockreceived72下放39.13%addblock30下放21.78%complete27下放12.46%mkdirs24不变5.23%create24更简单4.67%rename15不变2.

9、27%blockreport0.16下放1.69%getfileinfo253不变1.53%sum13.7%可以看出，最耗cpu资源的若干操作中，仍需要经过命名空间管理的只有13.7%，同时，由于剥离了块管理的职责，大部分命名空间操作都不用再加全局锁，使操作可以更好地利用到多核cpu的资源，因此可以估计，在本方案下命名空间的性能是可以满足要求的。3.2.2 平坦命名空间平坦的命名空间基于hbase进行设计，在hbase稳定的前提下，可以轻松支持百亿以上的文件规模。一期暂时不予实现。3.3 文件管理服务（fms）fms管理文件对象的全部信息并独立进行文件块副本维护。多个文件对象管理服务共享底层的

10、datanode。对象管理层非常类似于ceph中的rados，区别是，rados在数据节点内部通过p2p维护状态一致和数据安全，我们的设计里这部分职责由fms来提供。fms需要管理的内容：l inodefile包含的块列表l 写入控制（lease管理）l 文件权限管理fms中我们引入了filepool的概念，一个fms可以维护多个filepool，每一个filepool拥有一个可配且唯一的poolid。一个文件、块隶属于一个唯一的filepool，文件用二元组唯一标识，块使用二元组唯一标识。datanode向多个文件管理服务注册，发送心跳和块汇报，并可将不同的filepool下的物理块用独立的

11、目录存储，并独立进行块检查发送块汇报。引入filepool的好处是在物理的datanode和fms之间加入一层抽象，filepool和fms的映射管理可以改变，集群的扩展等操作都会更加灵活。3.3.1 元数据存储所有的文件及逻辑块相关信息都会存储到hbase中来，包括文件大小、修改时间、权限等基本信息，和块列表信息，其中块列表的当前平均为1.1，以256m的blocksize计算，100g的文件也只需要400个块，因此文件信息大小一般都在kb以内。filedescriptorrow keyattributesdescfileidmodificationtime修改时间accesstime访问时

12、间blockreplication期望副本数permission权限位preferredblocksize期望块大小length文件大小underconstruction是否还在构建中clientname仅当underconstruction时存在clientmachine仅当unserconstruction时存在blockid 1key：“blockno”value：blockid#numbyes#generationstampblockid 2blockid n3.3.2 元数据加载hbase存储了所有的元数据信息，但在fms启动时，块副本信息需要通过blockreport来构建，由于需

13、要验证blockreport数据的合法性和确认副本数要求，因此，在blockreport前，需要从hbase里scan加载所需要的元数据信息，包括所有块的blockid、numbytes、generationstamp以及所属文件的fileid和replication，这些信息用于构建初始状态的blockmap。#blockid递增当前值保存在hbase的某个全局表里。3.3.3 元数据访问除启动时外，元数据访问主要是对hbase随机读、写，因此需要hbase提供足够的随机读写性能。对元数据信息的主要访问途径如下，其中访问频度按照集群10000台规模预估：operationreq/sdescc

14、reate400create是对hbase的写操作，但写入前需要检查条目是否已经存在，当前hbase不支持insert-if-not-exist语义，因此客户端，即fms需要来实现这一语义，由于对于同一个key(fileid)只会由一个唯一的fms来完成，因此，不会有数据同步的问题。getfileinfo5000一次对hbase的随机读getblocklocations1000一次对hbase的随机读addblock2600一次对hbase的写操作，增加一列更新filepool表中的nextblockidgetlistingnamespace165相当于对目录下的所有children都进行一次

15、hbase的随机读，按照当前集群目录和文件的比例为1:100，这样可以预计getlisting带来的随机读次数可能超过10000次/s。deletenamespace160无法区分目录删除还是文件删除，但从集群数据增长规模来看，映射到的文件delete个数应该小于create个数。元数据的访问往往存在很大的热点分布，因此可以在fms层增加对元数据的缓存。同时也可以看到，对于元数据表的随机访问非常密集，尤其是getlisting这样的操作，当目录很大时，很可能会带来很高的峰值调用，因此一期fms可以在内存中缓存其管辖的所有元数据信息，缓存过程可以在元数据加载阶段完成。元数据加载完成时，内存和hb

16、ase是一致的，随后的更新操作都是先更新hbase，确认更新成功后再更新内存，从而保证内存和hbase的一致。3.3.4 pool信息管理我们在datanode和fms之间引入了虚拟的filepool的概念，一个fms可能管理一个或者多个filepool，系统中维护着filepool到fms的映射关系，这样可以在fms发生变动时，只需要修改映射关系即可，datanode节点不需要任何的配置和数据改变。上述映射关系在以下地方需要访问：l datanode，以便进行blockreport或者blockreceived等操作时找到正确的fms；l namespace，少量操作可能需要namespac

17、e和fms的交互。l client，大部分操作，namespace只会告知client文件的poolid，client需要直接向fms请求完成后续文件操作。hbase可以被用来存储上述映射关系，数据表简单定义如下：filepoolrow keyattributesdescpoolidfmshostname:portnextblockid?对于datanode和namespace，属于长时间运行的服务，可以在启动时将所有映射关系缓存到本地内存。对于client，其生命周期相对短促，比如mapred产生的大量任务，可以由namespace的rpc接口（如getfileinfo）来提供此映射关系。f

18、ilepool表还存储了每个pool的blockid自增位置，此数值每次有新块生成时都需要更新，更新频率预计达到600次每秒。3.3.5 全局信息管理和fsimage一样，有一些全局信息也需要存储进来，表结构如下：globalvariablesrow keyattributesdescvarnamevarvalue需要存储的信息有：l layout_versionl namespaceidl generationstamp其中generationstamp需要在每次create文件或者syncblock时递增，频率预计可达到500次每秒。由于generationstamp的存在，可以考虑不在h

19、base中存储nextblockid记录，只需要在集群启动时对所有pool分别统计出当前的maxblockid，加一后即可作为当前pool的nextpoolid，由于新增文件会递增generationstamp，因此不用担心datanode上未删除的物理块会造成干扰。3.3.6 集群管理节点管理的管理员接口主要包括：l 集群启动、停止脚本，如start/stop-dfs.shl 服务启动、停止脚本，如start/stop-namenode.sh、start/stop-datanode.sh等。l dfsadmin命令，主要操作为refreshnodes等，用于动态的datanode节点增删。本

20、期的hdfs2同样不支持动态增删fms节点，因此不提供此管理员接口。单个的服务启停脚本比较简单，集群整体的启停以及操作在引入了多fms后需要发生一些变化，下面分别予以分析。首先需要选择一个admin server，它可以是随意选择的一个甚至多个fms，配置上和其它fms没有特殊要求，但需要有能够ssh到所有fms的能力。也可以是在namespace或者单独的机器上，拥有ssh到namespace和所有fms的能力。3.3.6.1 集群启停需要提供一个“一键”启、停集群的方式，包括：a. 启、停所有的datanode。b. 启、停所有的fms。a) 在admin server上发起。b) adm

21、in server上需要有一个类似于slaves的配置文件配置所有fms的列表c. 启、停fms+datanode。d. 启、停fms+datanode+namespace。a) 在admin server上发起。b) namespace拥有到主fms的ssh信任关系。3.3.6.2 datanode动态增删由admin server发起，工具自动首先将相关配置文件，如dfs.hosts等scp到所有fms上，然后再通过ssh，对所有的fms调用dfsadmin refreshnodes，相当于对自动对所有的fms调用decommission。fms需要提供rpc接口供查询相应节点的decom

22、mission的状态，只有当所有fms的decommission都结束时，相应节点的状态才可以标记为decommissioned。3.3.6.3 fms线下增删首先为fms初始设置多个filepool，最多可设置216个（short poolid），运行时刻，filepool间的数据是均匀的。扩展后的数据迁移以filepool为最小的颗粒，即文件、块的poolid始终不会变化，这样fms迁移时底层的datanode不需要做任何改动。poolid和fms地址的映射可以由单独的服务或数据库来维护，而fms的节点增加需要重新计算filepool在fms之间的分布，计算和数据搬迁在线下进行。下图给出一

23、个扩展前后的fms及映射关系对比，fms由2台增加到了3台：这里可以看到，为了保证迁移的数据均匀，可以将初始的filepool个数设置得多一些，比如256个。下面给出一个可能的fms扩展操作步骤：1) 停掉集群。2) 按照扩展后的fms节点数重新对filepool的分配进行计算，并更新映射配置到hbase。3) 重启集群由于fms扩展并不会是一个很频繁的操作，因此先期使用线下扩展的方式也是可以接受的。3.3.7 副本状态维护当副本数发生变化，或者当期望副本数发生变化，块副本数都可能发生不足或者超出，这时需要对其安排复制或清除。由于fms维护的是平坦的数据结构，因此各fms之间的数据完全没有交集

24、，副本状态的维护也是由各fms独立地进行。副本数或者期望副本数的变化都会触发副本数的检查，对于不足或者超出的副本安排补足或者清理。通常会触发副本检查的事件包括blockreport、blockreceived、reportbadblock和心跳检查等，如下表所示：操作&组件 描述 副本发生变化blockreport l 用于同步master端记录的块信息和slave实际存储的块信息 l 当前还用来master块信息的初始化 l 缺省每个slave6小时一次，代价取决于master和slave数据的差异 blockreceived l slave写完了一个块，告知master知晓 l 当前72次

25、/s reportbadblock l 发现一个坏块告知master知晓 heartbeatmonitor l 发现一个slave宕机，需要找到其下属所有块，并检查副本数 l 一个slave可能包含数十万个块 l 一天可能十余次 decommission l 下线一个slave，需要找到其下属所有块，并检查副本数 l 类似heartbeatmonitor l 需要有进度检查 副本要求变化setreplication l 用户触发，频率较低 以上事件均由各fms独立处理，datanode只将block信息汇报给其所属的fms，并向所有注册的fms发送心跳，当datanode超过期限未发出心跳，会

26、被各fms分别识别并做出相应处理，处理方式和当前namenode一致。3.3.8 心跳机制心跳机制用来剔除长期不活跃的节点，节点超时后，会触发节点下属块的检查和副本复制操作。心跳机制除了向fms汇报状态外，fms还会向datanode分配块副本的复制、清除等任务。复制任务的分配需要考虑节点的当前负载，保证一个节点同时打开的复制流不超过指定的数目，策略和当前任务调度逻辑一致。但由于datanode需要向多个fms注册和发送心跳，如果想严格地控制同时打开的复制流个数，需要保证datanode向多个fms的心跳是一个串行操作。3.4 权限管理目录权限由namenode继续负责，一方面目录个数少，权限

27、信息数据单机内存放得下，另一方面这样使得回溯目录树进行权限检查更加高效。文件的权限由fms负责，检查文件的权限需要最终请求文件管理服务。这主要是为了节省namenode端的内存占用，按8bytes/file计算，10亿文件下可以节省8个gb的内存。同时这也依赖于目录的移动、删除不需要检查文件的权限，否则目录移动、删除等操作需要通过rpc递归检查下属文件的权限信息，就会非常的低效。文件权限由fms负责的另外好处是，未来fms直接对外提供服务时，可以更好地保证文件数据的安全。当然，上层的命名空间也可以选择忽略fms的权限管理。3.5 配额管理配额管理分为两种，一种是当前已有的基于目录的配额管理，另

28、一方面现在已经出现了一些基于用户、组来进行配额管理的需求。下面分别说明：l 基于目录n 文件数限制：和当前namenode一致n 磁盘空间限制n 设置时目录遍历根据块信息估算n 收到块和路径rename、删除时做相应增减n 当前设计下得到文件的大小信息需要向fms发起rpc调用，可以考虑批量请求以减少rpc调用次数l 基于用户、组n 设置一个用户、组配额限制表n 初次设置时，由各fms分别统计汇报回namespace合并n 收到块和路径删除、chown时做动态增减3.6 文件操作场景在用户看来，对于集群的使用方式没有特别的变化，原有的客户端api继续被支持，只是文件操作的内部实现将发生变化。纯

29、粹元数据操作不会发生太大的变化，这些操作诸如mv、rename等等，全部工作都只在namenode里完成。另一些操作则需要涉及到块的读写，如cp、cat等，这时客户端需要和额外的块管理层进行通信。命名空间分别以平坦和树状结构来存放文件和目录的inode信息，其中文件inode即inodefile记录了文件对应的filepool信息，这样就可以定位到相应的fms。这里倾向于让客户端直接和定位到的fms通信，以使命名空间管理的设计更加简单。下面会挑选列出若干涉及块读写的文件操作场景。3.6.1 文件创建文件创建分为两个独立的步骤进行，首先，dfsclient请求namespace创建文件的inod

30、e ，并在namespace端加入到其父目录的children列表里。随后，dfsclient根据namespace返回的inode，向相应的文件管理服务发起创建文件的请求。如下图所示：namespace的rpc请求会在向文件管理服务发起请求前结束，这样一方面是简化namespace的职责，另一方面最重要的是降低namespace的负载。这样的调用顺序必然会带来状态不一致的可能，当namespace的rpc调用已经结束返回时，实际上，文件管理服务一端可能还没有执行实际的操作，或者客户端的异常退出根本就没有执行后续对于文件管理服务的操作。但是这种不一致并不会造成客户端的歧义或者错误：1. 对于第一种情况，其它的客户端发起读请求时，会通过文件管理服务，发现文件实际上还未创建，由于inode已经在namespace端创建，因此不会出现多个客户端写一个文件的情况。2. 对于第二种情况，客户端异常，会在namespace端留下inode的记录，这个可以