Chinaunix首页 | 论坛 | 博客
  • 博客访问: 7845794
  • 博文数量: 594
  • 博客积分: 13065
  • 博客等级: 上将
  • 技术积分: 10323
  • 用 户 组: 普通用户
  • 注册时间: 2008-03-26 16:44
个人简介

推荐: blog.csdn.net/aquester https://github.com/eyjian https://www.cnblogs.com/aquester http://blog.chinaunix.net/uid/20682147.html

文章分类

全部博文(594)

分类: HADOOP

2014-05-15 10:06:54

HDFS Federation.pdf

目录

 

1. 前言

Federation翻译成中文是联盟或联邦的意思,网上有很多介绍HDFS Federation的文章,官网上的也做了专门的介绍。本文试图画蛇添足,以更通俗的方式重复一遍,以帮助对HDFS Federation的理解。

2. 背景

为何需要Federation?众所周知,之前的HDFS存在如下几个缺陷:

1) NameNode存在单点,不具备高可用性

2) 由于受限于单个NameNode,支撑的文件数量有限

3) 同样受限于单个NameNode,吞吐量有限

 

站在运维和高可用性的角度,解决这些问题,系统运行可以省心得多。HDFS Federation因此很自然的诞生了,但请注意它只解决了后两个问题,第一个问题不在它的解决范畴之内。

为何说很自然的诞生,稍加思考即可明白解决这两个问题能有什么手段:无非是升级机器的内存和CPU,也就是纵向升级;另一个就是增加机器,也就是横向升级。

显然升级内存和CPU的手段是非常有限的,不能从根本上解决问题,两个问题仍然存在,因此可行的只有增加机器这个唯一手段了。

3. 解析

没有Federation之前的HDFS架构如下图所示(没有画SecondaryNameNode,是因为SecondaryNameNode是针对单点,而非Federation要解决的两个问题),这是一种非常简洁的架构,很明显压力都集中在单个NameNode上,它成了系统瓶颈:

 

Federation版本的HDFS架构变成如下,显然这里不止一个NameNode,而是存在多个NameNode,并且可以按需要添加新的NameNode进行横向扩展。这里的多个NameNode间地位是平等的,而且互不干涉互不隶属,站在每个NameNode上看,它就是一个独立的HDFS集群:

 

南京全面深化改革工作领导小组成立,由市委书记和市长同时担任改革小组组长,通过前面的描述不难发现HDFS Federation和这个有点类似,那么就会产生一个疑问:听谁的?不乱了么?答案是:都听

俗话曰无规则不成方圆,显然都听就乱序了。如果把这个关系理解成外包,可能更好理解一点,比如同一家外包公司会同时服务于多家公司,如下图所示:

 

可以进一步抽象:一个物理节点被虚拟化成多个虚拟节点,虚拟节点和NameNode是一一对应的,但物理节点和NameNode是一对多的关系。实际上Google Borg/Apache Mesos/Hadoop Yarn就是这样一种行为。进一步可看作:有多少个NameNode,就有多少个物理磁盘一样,Namespace就相当于C:\D:\等:

 

甚至,可以将NameNode看作是DataNode的客户端,而DataNode则是服务端,服务端当然可以服务不同的客户端。
    
HDFS Federation虽然未解决单点问题,但因为多个NameNode的存在,单个NameNode故障的影响就降低了,所以可以说HDFS Federation弱化了单点问题。

 

要从根本上解决单点,有多种可行的手段:

1) Share Storage,主备NameNode共享同一个存储,可保证数据完整性

2) 像SecondaryNamenode一样的备份,但不能保证数据完整性

3) 引入两阶段提交(2PC),可保证一致性,但写性能会下降

4) 引入Quorum NRW,也可保证一致性,可以选择牺牲读性能来提升写性能

 

也许2PC是相对较好的解决方式。

 

阅读(4586) | 评论(1) | 转发(2) |
给主人留下些什么吧!~~

Aquester2016-11-23 14:27:08

Hadoop内置了基于QJM的HA,另外还支持基于BookKeeper的HA