HDFS3核心特性之Router-Balance(三)
接着上一篇, 在HDFS2.x时代, Federation虽然有了, 但是不同的子集群/NS之间是不能直接互相有数据访问的, 也不能跨NS做mv操作, 这篇是对小米HDFS-15097和HDFS-15294提出的两个基于RBF的跨NS搬数据方案的简单解读.
此文暂未完成, 请慎重参考
0x00. 简介
小米的这两个patch, 核心都是跨NS搬运数据:
- 前者(HFR)是基于硬链接设计, 只能用于共享DN的Federation集群, 速度快 (参考FastCopy以及HDFS-11573, 做了进一步的完善和改进)
- 后一个是基于
distcp和snapshot的, 更为通用, 命名为federation-balance
在说HFR(Hadoop-Federation-Rename)之前, 先说一下社区关于跨子集群/NS移动文件的已有几个方案:
- FastCopy:
写块 --> FastCopy --> 更新router的路由表- 优点: 速度很快, 不占存储空间/IO, 核心应用了硬链的原理, 尽量不做数据搬运, 业内有改进版.
- 缺点: 单独组件, 无人继续稳定维护合并, 拷贝后文件缺失文件权限/属主信息, 需要从oldNS读再写到newNS
- 增量的distcp:
多次distcp --> 写块 --> 最终一次distcp --> 更新router的路由表- 优点: 信息完整, 通用(跨大集群/不共享DN的拷贝可用), 社区长期维护, 不需要锁定源目录只读
- 缺点: 所有数据走网络I/O, 很慢, 不支持跨NS直接重命名
- snapshot:
使用snapshot-diff比较区别- 优点: snapshot-diff 可以对比两个NS之间某个dir的变动情况?
- 缺点: 应该不能单独使用, 待看
然后这两个patch其实也对应了这三个方案, 做了改进和合并, 值得对比和学习, 分开来说 (后续拆分为两篇)
补充: 去哪儿也分享过优化FastCopy的方案-Qfastcopy, 暂不细看.
0x01. HFR的主要思想
1. 大体步骤
简述:
- 把元信息(inodes & blockInfo等) 从oldNS –> newNS
- 把数据块从oldBlockPool转移到newBlockPool中 (how?)
- 完成后更新存储Router信息, 使得客户端可以访问迁移后的数据
为了简化实现, 当一个目录开始准备迁移时, 它会变为只读状态(允许读么?).
具体:
- Prepare: 对待迁移目录进行权限/Quota等检查, 检查完毕变为只读状态
- SaveTree: 给oldNS发送
saveTree()-RPC, 然后oldNS会把目录对应的所有元信息(inodes/blockInfo)落盘到指定的外置存储上 (比如NFS?) - GraftTree(嫁接Tree): 给newNS发送
graftTree()-RPC, 然后它读取#2中oldNS导出的元数据信息, 然后与自身的namespace合并 - HardLink: 由于oldNS和newNS同属一个大集群, 它们默认共享所有的DN, 借助Unix硬链接, 可以让oldBlockPoolFile —link–> newBlockPoolFile, 从而避免数据的搬迁
- 首先从oldNS上收集所有的副本位置信息
- 生成hardlink计划并开始执行
- 最后发送
addBlksToNewPool()-RPC给相关联的DN
- Finish: 最后, 做检查和收尾工作, 并更新router的挂载表信息
- 目录/文件完整性检查
- 删除oldNS的数据 (回收站)
- 移除oldNS原有路径的只读状态
- 更新路由挂载表信息
然后为了实现上述的HFR(HDFS Federation Rename)操作, 设计了一个状态机, 一次mv操作就对应一个非确定性的有限状态机(NFA). 每一步对应状态机的一个状态, 任一步失败, 都会进入错误状态 , 有一个调度器(Scheduler)管控迁移任务的生命周期(开始/结束/重试/恢复..), 然后下面会主要介绍2~4对应的状态机, 以及调度器和性能测试结果, 1和5因为存在不同需求和实现, 就不单独说了. (后面用src代表oldNS, 用dst代表newNS)
2.
0x02. HFR的实现
未完待续
0x04. HFR相关问题
1. 如何确保源目录不会更新?
目前方法: 去掉源目录和子孙的所有写权限, router/实际NS上都设置为只读, 强制触发租约恢复关闭所有打开的文件
2. 是否可以支持EC文件
正在开发, 后续会发布
3. HDR的性能如何, 怎么保证目录只读时不影响业务
和FastCopy最大的区别就在于, HFR可以很轻量/快速的较小的文件夹做搬运, 就算有写请求, 等整个流程完成后, 也不容易超时 (秒级)
小米给出的测试结果中:
- 11万个文件(同等块), 耗时只有18s,
- 近500万个文件(块), 耗时10分钟
- 通过调度器, 可以把一个大的目录拆成多个小目录, 近乎不影响业务的去实现迁移
其中耗时最大的比重在Hardlink阶段, 可能高达50~80%的比例,
小米2019年10月上线, 两个月内迁移了3100万个文件, 节省了10G的NN内存使用, 下一步考虑把这个功能集成到Router内部, 那样使用就更加方便.
当然, 实际情况会比理论复杂许多, 如果使用不当仍然存在影响业务使用的风险, 所以这个方案目前社区还持保留意见, 在探讨中, 不过个人觉得比起裸用0.2的FastCopy, 这个至少显得完备许多, 作为一个可选方案
0x05. Federation balance
今天准备写的时候, 发现社区作者已经更新了一篇文章介绍了, 可以先看看. 我就先不细说了.
未完待续
参考资料: