HDFS HA与Federation实践.pptx

HDFS HA和Federation实践 天云趋势 孙振南 张军 钱兴会 议程 为什么需要HA和Federation Hadoop 2.0中HA和Federation的实现方式 HA和Federation配置 HA测试方案和结果 HA推荐配置 未尽事宜 附：趋势科技如何使用Hadoop 为什么需要HA和Federation NameNode 单点故障 Secondary NN不是HA，SNN甚至无法保证数据完整性 Backup NN (HADOOP-4539)也一样不安全，但略有一点Warm Standby 手动把name.dir/edits.dir指向NFS 是安全的Cold Standby Facebook AvatarNode是Hot Standby，但只有手动切换 还有若干解决方案，基本都是依赖外部的HA机制 NameNode内存限制了文件数目和集群的存储容量 1G ≈ 1M block ≈ 64T NameNode的性能瓶颈 Client: addBlock, getBlockLocations DataNode: blockRecieved, sendHeartbeat, blockReport Hadoop 2.0里HA的实现方式 来源： HDFS-1623 设计文档 作者： Sanjay
Radia, Suresh
Srinivas HA设计上的考虑 共享存储 不再是share nothing，转移了单点故障的位置 利用NFS的close-to-open来保证一致性 未来可能替换为BookKeeper FailOverController 独立的，短小精悍的watchdog 避免NN GC时的心跳暂停 可替换为其他的HA方案或leader选举方案，目前是ZKFC Fencing 防止脑裂 只能有一个NN响应请求，下发命令，写入edits 客户端fencing, DataNode fencing, 共享存储fencing Hadoop 2.0里Federation的实现方式 来源： HDFS-1052 设计文档 作者： Sanjay
Radia, Suresh
Srinivas Federation设计上的考虑 改动最小，向前兼容 现有的NN无需任何配置改动 如果客户端只连某台NN的话，配置也无需改动 分离命名空间管理和块存储管理 提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池 统一的块存储管理保证了资源利用率 可以只通过防火墙配置达到一定的文件访问隔离 客户端挂载表 通过路径自动对应NN 使Federation对现有应用完全透明 测试环境 DN-1 DN-2 DN-3 DN-4 DN-5 DN-6 NN-1 NN-3 NN-2 NN-4 Storage Pool 1 Storage Pool 2 Name Service 1 /share/ Name Service 2 /user/ Client Side Mount Table HA HA Federation HA配置: 所有节点 core-site.xml fs.defaultFS 逻辑名称，替代之前的 hdfs://ns1 hdfs-site.xml services 逻辑名称，与core-site里的对应 nodes.${NS_ID} 列出该逻辑名称下的NameNode逻辑名称 nn1,nn3 node.${NS_ID}.${NN_ID} 指定NameNode的RPC位置 nodes.ns1.nn1=host-nn1:9000 nodes.ns1.nn3=host-nn3:9000 node.http-address.${NS_ID}.${NN_ID} 指定NameNode的Web位置，50070 HA配置: NameNode和客户端 NameNode: hdfs-site.xml node.shared.edits.dir 指定NFS挂载点，HA共享存储 file:///nfs-host/hdfsha ha.zookeeper.quorum host-zk:2181 ha.zookeeper.session-timeout.ms 单位毫秒 dfs.ha.fencing.methods sshfence, shell() 客户端: hdfs-site.xml dfs.ha.automatic-failover.enabled true/false vider.${NS_ID} 客户端用于自动切换的代理类 node.ha.ConfiguredFailoverProxyProvider Federation配置: 所有节点 core-site.xml xi:include href=“cmt.xml/ fs.defaultFS 逻辑名称