HDFS元数据的独立服务和独立持久化存储

上传人:蜀歌 文档编号:147634477 上传时间:2020-10-11 格式:PDF 页数:17 大小:625.73KB
返回 下载 相关 举报
HDFS元数据的独立服务和独立持久化存储_第1页
第1页 / 共17页
HDFS元数据的独立服务和独立持久化存储_第2页
第2页 / 共17页
HDFS元数据的独立服务和独立持久化存储_第3页
第3页 / 共17页
HDFS元数据的独立服务和独立持久化存储_第4页
第4页 / 共17页
HDFS元数据的独立服务和独立持久化存储_第5页
第5页 / 共17页
点击查看更多>>
资源描述

《HDFS元数据的独立服务和独立持久化存储》由会员分享,可在线阅读,更多相关《HDFS元数据的独立服务和独立持久化存储(17页珍藏版)》请在金锄头文库上搜索。

1、HDFS元数据的独立服务和 独立持久化存储 2009-8-22 罗李 主要内容 起因起因 现状现状 我们的想法我们的想法 我们的实现我们的实现 后续的发展后续的发展 起因 数据的急剧膨胀 文件数的不断增多 Block随之成倍的增长 内存的急剧上涨 内存数据结构 一致性保证造成的性能瓶颈 Meta服务依靠namenode的启停 部分meta数据没有持久化(block-dn) 现状 集群 单个集群1900台机器 1T12(2T6) 数据量 22.28 PB/36.98 PB 60% 文件数 1亿左右 Block数 1.3亿左右 Meta存储 只持久化了namespace的信息到fsimage 现状

2、 内存 60G / 80G 75% 数据结构 BlockMap靠内存中ref来维护block-dn的信息 响应 删除文件个数1100万,每天的删除操作为240万 创建文件操作900万1200万 重命名文件数量为1050万 通过文件名获取block及其位置的操作getBlockLocations有近3亿 类似“ls”的操作有700万 新的架构 Stateless Namenode Stateless Namenode Stateless Namenode (Innodb on FusionIO) State Manager (Innodb on FusionIO) State Manager Z

3、ookeeper DatanodeDatanodeDatanodeDatanode DatanodeBlockFile BlockChecker Zookeeper 7 Namenode的改进 无状态NN: 针对HDFS中Namenode单点瓶颈的问题,TBFS通过无状态方式 实现Namenode的水平扩展。为了实现无状态Namenode,需要将以前保留 在Namenode内存中的关键数据结构部分或全部挪到第三方,并持久化保存。 数据结构名称数据结构名称描述描述 dir保存HDFS目录结构的数据结构FSDirectory(文件-块的对应关系) blocksMap保存块与文件、块与datanod

4、e和datanode与块的对应关系 datanodemap保存datanode的storageID和对应DatanodeDescriptor的Map容器 heartbeats保存拥有心跳的Datanode的DatanodeDescriptor的容器 corruptReplicas保存损坏块的Map容器,key为Block,value为对应Datanode的DatanodeDescriptor集合 recentInvalidateSets保存即将删除的块的Map容器,key为Datanode的StorageID,value是块的Block集合 excessReplicateMap保存多余块的Ma

5、p容器,key为Datanode的storageID,value是块的Block集合 neededReplications 保存少于replication数的块的数据结构,其内部维护了一个ListTreeSet 类型的优先级队列 pendingReplications保存处于replication pending状态的block,如果超时则放入TimeoutItems列表中 leaseManager维护写操作和追加操作租约的数据结构 Stateless Namenode 8 Namenode的改进(续1) Stateless Namenode (Innodb on FusionIO) Stat

6、e Manager (Innodb on FusionIO) State Manager DatanodeBlockFile Zookeeper blocksMap dir datanodeMap heartbeats 将BlocksMap和FSDirectory在数 据库中实现持久化保存 datanodeMap和heartbeats的数据从数据 库中读取,Namenode中只是缓存 ZooKeeper namenode lease pendin g underexcesscorruptinvalidategroup datanodeblockchecker / 为LeaseManager保

7、存全局lease信息 维护replication pending相关的 持久化数据 LeaseManger 维护under replication 相关的持久 化数据 维护excess replication 相关的持久 化数据 维护corrupt 块相关的持 久化数据 维护 invalidate 块相关的持 久化数据 维护TBFS 集群中 namenode 成员信息 基于树状结构来描述Map和Set,比 较直观,操作方便 提供了ephemeral和sequence znode的机制,方便做成员管理和提 供分布式锁服务 提供了Watcher机制,提供对数据变 化的通知 Stateless Na

8、menode 9 Namenode的改进(续2) Namenode与非心跳Datanode进行通信。Datanode实现了 ExternalNamenodeProtocol协议,Namenode可以通过该协议与非心跳 Datanode进行通信,即Namenode主动调用该协议提供的方法。 Datanode A Datanode B Namenode 1 Namenode 2 sendHeartbeat ExternalNamenode Protocol ExternalNamenode Protocol ExternalDatanode CommandsHandle r ExternalDat

9、anode CommandsHandle r Datanode Protocol offerSerivce sendHeartbeat Datanode Protocol offerSerivce Namenode 2是Datanode A的External Namenode 与原有方式一致,External Namenode向External Datanode发送三种命令: replication命令,invalidate 命令和recover命令 10 BlockChecker的引入 BlockChecker解决Namenode无法判断出的数据不一致的情况,主要是检测 Block副本数是否

10、满足期望,类似于社区版中离开安全模式(SafeMode.leave)时 processMisReplicatedBlocks机制。为了不影响Namenode的核心逻辑,它只和 数据库和Zookeeper交互。 运行方式:1. 每隔一段时间运行一次;2. 手动执行;3. Namenode下线时执行 典型场景: 某个block的副本数小于期望值,在数据库中增加一条伪记录,触发Namenode进行检查 某个block的副本数大于期望值,综合zookeeper中的记录,决定是否删除一条记录,触发 Namenode进行检查 (Innodb on FusionIO) State Manager (Inno

11、db on FusionIO) State Manager Zookeeper DatanodeBlockFile BlockChecker Zookeeper 11 Datanode的改进 提供Namenode的连接/重连机制,从而提高整个系统的可用性。在以下几种 场景下,Datanode会连接/切换目标Namenode: 1. Datanode启动时;2. 当 前Namenode失效(异常)并超过一定时限和重试次数;3. 管理员调用切换 命令。同一时刻一个Datanode只汇报给一个Namenode。 Namenode选择策略实现: AbsNameNodeSelector作为选择Namen

12、ode策略 的接口,ConfNameNodeSelector实现了该接口。 + selectNextNameNodeAddress() + refreshNameNodeList() DataNode 调用 Private AbsNameNodeSelector namenodeSelector; ConfNameNodeSelector + selectNextNameNodeAddress() + refreshNameNodeList() 实现 selectNextNameNodeAddress : 从Name Node列表中随机选 取一个Name Node返回给调用者,并记录下来。注意

13、,每次调 用时会将上次使用的Name Node从列表中删除,这样就避免再 次选择失效的Name Node refreshNameNodeList: 按照策略更新Name Node列表 12 Datanode的改进(续1) 目前已实现的Namenode选择策略ConfNameNodeSelector需要在配置文件中做如下配 置: Datanode在线辅助判断机制。Datanode上线后,在zookeeper中创建一个Ephemeral Node,用以给Namenode判断该Datanode是否在线。该类型的Node会在Datanode下 线后(会话失效)自动删除。如果Namenode通过data

14、node表中的lastupdate判断已经下 线,但是zookeeper中还有对应的node,会将其列入怀疑对象。造成这种现象一般在 TBFS重启初期,Namenode信息更新不及时。怀疑对象一般会在下一次更新时自动排 除,否则就认为它已经下线。 dfs.namenode.selector mon.ConfNameNodeSelector The policy of looking for and selecting name node dfs.namenode.selector.timeout 180000 The timeout value for retrying connection to a namenode dfs.namenode.rpcaddr.list hdfs:/dw30.kgb.sqa.cm4:51199,hdfs:/dw39.kgb.sqa.cm4:51199 The list of name nodes RPC addr list, separated with comma ConfNameNodeSelector的 类路径 一个Namenode失效后重连 的超时时间 Namenode的列表 开始 设置策 略 结束 Y N N Y 连接成 功 Y 移除NN N 获得 NN列 表

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 商业/管理/HR > 经营企划

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号