guoli0813 的BLOG
用户名：guoli0813
文章数：53
评论数：119
访问量：172902
注册日期：
阅读量：5863
阅读量：12276
阅读量：394855
阅读量：1085751
[匿名]Jay：
51CTO推荐博文
经过几天的测试，hadoop分布式系统搭建完毕。首先说一下这几天对hadoop理论知识的理解，然后说一下安装及碰到的问题。有图有真相
第一：理论知识：
&&&&什么是hadoop：
&&&&&&&&由三部分组成：HDFS，MapReduce和Hbase。
&&&&&&&&维基百科这样说：一个分布式系统基础架构，由Apache基金会开发。用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力高速运算和存储。这里面关键就是高速运算和海量存储。我们首先讲海量存储，这个比较有意思，一会儿再说高速运算。
&&&&&&&&海量存储：&HDFS&Hadoop Distributed File
System&&&&&&&&&
&&&&&&&&前身来自google的一篇博文，所以自身带有浓厚的互联网色彩，比如读多于写的特性，高度的扩展性。&&具体说一下他的特性：
图1：HDFS结构示意图
&&抄自 岑文初&
上图中展现了整个HDFS三个重要角色：NameNode、DataNode和Client。NameNode可以看作是分布式文件系统中的管理者，主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Meta-data存储在内存中，这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。DataNode是文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Meta-data，同时周期性地将所有存在的Block信息发送给NameNode。Client就是需要获取分布式文件系统文件的应用程序。这里通过三个操作来说明他们之间的交互关系。
文件写入：
Client向NameNode发起文件写入的请求。
NameNode根据文件大小和文件块配置情况，返回给Client它所管理部分DataNode的信息。
Client将文件划分为多个Block，根据DataNode的地址信息，按顺序写入到每一个DataNode块中。
文件读取：
Client向NameNode发起文件读取的请求。
NameNode返回文件存储的DataNode的信息。
Client读取文件信息。
文件Block复制：
NameNode发现部分文件的Block不符合最小复制数或者部分DataNode失效。
通知DataNode相互复制Block。
DataNode开始直接相互复制。
HDFS的几个设计特点：
Block的放置：默认不配置。一个Block会有三份备份，一份放在NameNode指定的DataNode，另一份放在与指定
DataNode非同一Rack上的DataNode，最后一份放在与指定DataNode同一Rack上的DataNode上。备份无非就是为了数据安全，考虑同一Rack的失败情况以及不同Rack之间数据拷贝性能问题就采用这种配置方式。
心跳检测DataNode的健康状况，如果发现问题就采取数据备份的方式来保证数据的安全性。
数据复制（场景为DataNode失败、需要平衡DataNode的存储利用率和需要平衡DataNode数据交互压力等情况）：这里先说一下，使用HDFS的balancer命令，可以配置一个Threshold来平衡每一个DataNode磁盘利用率。例如设置了Threshold为
10%，那么执行balancer命令的时候，首先统计所有DataNode的磁盘利用率的均值，然后判断如果某一个DataNode的磁盘利用率超过这个均值Threshold以上，那么将会把这个DataNode的block转移到磁盘利用率低的DataNode，这对于新节点的加入来说十分有用。
数据交验：采用CRC32作数据交验。在文件Block写入的时候除了写入数据还会写入交验信息，在读取的时候需要交验后再读入。
NameNode是单点：如果失败的话，任务处理信息将会纪录在本地文件系统和远端的文件系统中。
数据管道性的写入：当客户端要写入文件到DataNode上，首先客户端读取一个Block然后写到第一个DataNode上，然后由第一个DataNode传递到备份的DataNode上，一直到所有需要写入这个Block的NataNode都成功写入，客户端才会继续开始写下一个
安全模式：在分布式文件系统启动的时候，开始的时候会有安全模式，当分布式文件系统处于安全模式的情况下，文件系统中的内容不允许修改也不允许删除，直到安全模式结束。安全模式主要是为了系统启动的时候检查各个DataNode上数据块的有效性，同时根据策略必要的复制或者删除部分数据块。运行期通过命令也可以进入安全模式。在实践过程中，系统启动的时候去修改和删除文件也会有安全模式不允许修改的出错提示，只需要等待一会儿即可。
下面说高速计算：
上面的图片是计算这个文件中每个单词出现的次数，这个任务被分裂成三个子任务，然后映射到集群中JobTracker指定的TaskTracker上运行子任务，每个子任务都可以在指定的TaskTracker上运行，然后把运行的结果保存在当地，然后reduce程序被调用。然后进行的是结果的整合，整合完毕，就是最终结果了。这是计算向数据靠拢的计算方式。
好了，我们开始说安装，好多都在讲0.17和0.18的安装，hadoop这玩意儿因为最近很火，所以变动很厉害，变动的速度估计和nginx有一拼，所以在安装的时候得批判的继承他们安装过程。
首先：在这几台机器上安装CentOS5.4（最简化安装）并升级完毕。
保证计算机名的全局唯一性：
.cn-----192.168.0.3
.cn-----192.168.0.4
.cn-----192.168.0.5
.cn-----192.168.0.18
.cn-----192.168.0.20
修改方式：（5台服务器都设置）
[root@hadoop5 ~]# hostname
[root@hadoop5 ~]# cat /etc/hosts
# Do not remove the
following line, or various programs
# that require network functionality will
127.0.0.1&&&&&&&&&&&&&& localhost.localdomain
::1&&&&&&&&&&&&&&&&&&&& localhost6.localdomain6
localhost6
192.168.0.20&&&&&&&&&&& .cn hadoop5
[root@hadoop5 ~]# cat
/etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=.cn
GATEWAY=192.168.0.1
[root@hadoop5
为了方便，关闭防火墙：（5台服务器都设置）
[root@hadoop5 ~]# service iptables
[root@hadoop5 ~]# chkconfig iptables off
方便起见，创建hadoop用户
[root@hadoop5 ~]# useradd
下载hadoop最新版：
下载JDK最新版：
全部放入/home/hadoop目录。
[root@hadoop5 ~]# cp jdk-6u19-linux-i586.bin
/usr/local/
[root@hadoop5 ~]# cd /usr/local/
[root@hadoop5 ~]#
./jdk-6u19-linux-i586.bin
[root@hadoop5 ~]# rm -rf
jdk-6u19-linux-i586.bin
[root@hadoop5 ~]# cd& /home/hadoop/
[root@hadoop5 hadoop]# tar zxvf
hadoop-0.20.2.tar.gz
[root@hadoop5 ~]# cat /etc/profile ##放入如下信息
export JAVA_HOME=/usr/local/jdk1.6.0_19
CLASSPATH=$CLASSPATH:$JAVA_HOME/lib:$JAVA_HOME/jre/lib
PATH=$JAVA_HOME/lib:$JAVA_HOME/jre/bin:$PATH
export HADOOP_HOME=/home/hadoop/hadoop-0.20.2
PATH=$PATH:$HADOOP_HOME/bin
然后执行如下命令：
[root@hadoop5 ~]# source
/etc/profile
现在我们修改hadoop的配置文件：0.20以上的配置和以前的配置有些是不同的，我们以0.20.2为例做东西
[root@hadoop5 conf]# cat
core-site.xml
&?xml version=&1.0&?&
&?xml-stylesheet
type=&text/xsl& href=&configuration.xsl&?&
&!-- Put site-specific property overrides in
this file. --&
&configuration&
&property&
&name&fs.default.name&/name&
&value&hdfs://192.168.0.20:54310/&/value&
&/property&
&property&
&name&hadoop.tmp.dir&/name&
&value&/home/hadoop/tmp/&/value&
&/property&
&/configuration&
===========================================================================
[root@hadoop5
conf]# echo &export JAVA_HOME=/usr/local/jdk1.6.0_19& &&&
hadoop-env.sh
===========================================================================
[root@hadoop5 conf]# cat
hdfs-site.xml
&?xml version=&1.0&?&
&?xml-stylesheet
type=&text/xsl& href=&configuration.xsl&?&
&!-- Put site-specific property overrides in
this file. --&
&configuration&
&property&
&name&dfs.replication&/name&
&value&3&/value&
&/property&
&/configuration&
===========================================================================
[root@hadoop5 conf]# cat
mapred-site.xml
&?xml version=&1.0&?&
&?xml-stylesheet
type=&text/xsl& href=&configuration.xsl&?&
&!-- Put site-specific property overrides in
this file. --&
&configuration&
&property&
&name&mapred.job.tracker&/name&
&value&hdfs://192.168.0.20:54311/&/value&
&/property&
&/configuration&
[root@hadoop5
===========================================================================
[root@hadoop5
conf]# cat masters
192.168.0.20
[root@hadoop5 conf]# cat
192.168.0.3
192.168.0.4
192.168.0.5
192.168.0.18
[root@hadoop5
==========================================================================
现在我们做无密码的ssh登录：
建立Master到每一台Slave的SSH受信证书。由于Master将会通过SSH启动所有Slave的Hadoop，所以需要建立单向或者双向证书保证命令执行时不需要再输入密码。在Master和所有的Slave机器上执行：ssh-keygen -t
rsa。执行此命令的时候，看到提示只需要回车。然后就会在/root/.ssh/下面产生id_rsa.pub的证书文件，通过scp将Master机器上的这个文件拷贝到Slave上（记得修改名称），例如：scp root@masterIP:/root/.ssh/id_rsa.pub
/root/.ssh/46_rsa.pub，然后执行cat
/root/.ssh/46_rsa.pub
&&/root/.ssh/authorized_keys，建立authorized_keys文件即可，可以打开这个文件看看，也就是rsa的公钥作为key，user@IP作为value。此时可以试验一下，从master
ssh到slave已经不需要密码了。由slave反向建立也是同样。为什么要反向呢？其实如果一直都是Master启动和关闭的话那么没有必要建立反向，只是如果想在Slave也可以关闭Hadoop就需要建立反向。
然后每台服务器上都修改ssh的配置文件：/etc/ssh/sshd_config
把GSSAPIAuthentication的值设置为no，然后：
[root@hadoop5 conf]# service sshd
[root@hadoop5 conf]#
我们从master向slave依次登录
[root@hadoop5 conf]#ssh
[root@hadoop5 conf]#ssh
[root@hadoop5 conf]#ssh
[root@hadoop5 conf]#ssh
然后压缩hadoop文件夹成为一个压缩包
[root@hadoop5 hadoop]# tar zcvf hadoop-0.20.2.tar.gz
hadoop-0.20.2
然后在每台slave上执行如下命令
[root@hadoop1 hadoop]# cd /home/hadoop
[root@hadoop1
hadoop]# scp -r
/home/hadoop/
[root@hadoop1 hadoop]# tar zxvf
hadoop-0.20.2.tar.gz
好，我们现在可以在master上执行如下命令：
[root@hadoop5 hadoop]# hadoop namenode
[root@hadoop5 hadoop]# cd
/home/hadoop/hadoop-0.20.2/bin/
[root@hadoop5 bin]#
./start-all.sh
然后在地址栏输入：可以查看master和slave的状态。
手写的有点木，不多写了
参考文献：
Hadoop官方文档：（读晕拉倒）
百度百科：
大家如有问题，可以一起交流：本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)
本文收录至博客专题：《》
15:23:33 17:33:23 21:01:55 10:05:24 10:07:40 14:16:12 17:22:40 08:04:34 16:51:45 11:43:15 13:58:26 21:12:07 21:13:54我都改了几次hostName ，为什么 使用
hadoop namenode -format
还是会告诉我 &，名字不对，我也根据这博客修改了
http://blog.csdn.net/shirdrn/article/details/6562292
39 INFO util.GSet: Computing capacity for map NameNodeRetryCache
15/07/28 19:20:39 INFO util.GSet: VM type
15/07/28 19:20:39 INFO util.GSet: 0.447746% max memory 966.7 MB = 297.0 KB
15/07/28 19:20:39 INFO util.GSet: capacity
= 2^15 = 32768 entries
15/07/28 19:20:39 INFO namenode.NNConf: ACLs enabled? false
15/07/28 19:20:39 INFO namenode.NNConf: XAttrs enabled? true
15/07/28 19:20:39 INFO namenode.NNConf: Maximum size of an xattr: 16384
15/07/28 19:20:49 WARN net.DNS: Unable to determine local hostname -falling back to "localhost"
java.net.UnknownHostException: master: master
at java.net.InetAddress.getLocalHost(InetAddress.java:1475)
at org.apache.hadoop.net.DNS.resolveLocalHostname(DNS.java:264)
at org.apache.hadoop.net.DNS.&clinit&(DNS.java:57)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.newBlockPoolID(NNStorage.java:966)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.newNamespaceInfo(NNStorage.java:575)
at org.apache.hadoop.hdfs.server.namenode.FSImage.format(FSImage.java:144)
at org.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:941)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1379)
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1504)
Caused by: java.net.UnknownHostException: master
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1295)
at java.net.InetAddress.getLocalHost(InetAddress.java:1471)
... 8 more
15/07/28 19:20:59 WARN net.DNS: Unable to determine address of the host-falling back to "localhost" address
java.net.UnknownHostException: master: master
at java.net.InetAddress.getLocalHost(InetAddress.java:1475)
at org.apache.hadoop.net.DNS.resolveLocalHostIPAddress(DNS.java:287)
at org.apache.hadoop.net.DNS.&clinit&(DNS.java:58)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.newBlockPoolID(NNStorage.java:966)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.newNamespaceInfo(NNStorage.java:575)
at org.apache.hadoop.hdfs.server.namenode.FSImage.format(FSImage.java:144)
at org.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:941)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1379)
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1504)
Caused by: java.net.UnknownHostException: master
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:901)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1295)
at java.net.InetAddress.getLocalHost(InetAddress.java:1471)
... 8 more
15/07/28 19:20:59 INFO namenode.FSImage: Allocated new BlockPoolId: BP-7.0.0.1-8
15/07/28 19:20:59 WARN namenode.NameNode: Encountered exception during format:
java.io.IOException: Cannot create directory /usr/local/hadoop/hdfs/name/current
at org.apache.hadoop.mon.Storage$StorageDirectory.clearDirectory(Storage.java:337)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.format(NNStorage.java:548)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.format(NNStorage.java:569)
at org.apache.hadoop.hdfs.server.namenode.FSImage.format(FSImage.java:148)
at org.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:941)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1379)
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1504)
15/07/28 19:20:59 FATAL namenode.NameNode: Failed to start namenode.
java.io.IOException: Cannot create directory /usr/local/hadoop/hdfs/name/current
at org.apache.hadoop.mon.Storage$StorageDirectory.clearDirectory(Storage.java:337)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.format(NNStorage.java:548)
at org.apache.hadoop.hdfs.server.namenode.NNStorage.format(NNStorage.java:569)
at org.apache.hadoop.hdfs.server.namenode.FSImage.format(FSImage.java:148)
at org.apache.hadoop.hdfs.server.namenode.NameNode.format(NameNode.java:941)
at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1379)
at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1504)
15/07/28 19:20:59 INFO util.ExitUtil: Exiting with status 1
15/07/28 19:20:59 INFO namenode.NameNode: SHUTDOWN_MSG:
/************************************************************
SHUTDOWN_MSG: Shutting down NameNode at java.net.UnknownHostException: master: master
************************************************************/
[hadoop@master ~]$ hostname
[hadoop@master ~]$ cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=master
NTPSERVERARGS=iburst
RKING_IPV6=yes
修改&/etc/hosts &，追加 &master&
hosts里少了ip与主机名对应的关系
192.168.1.1 master
192.168.1.2 slave您所在的位置： &
Hadoop 2.0 NameNode HA和Federation实践
Hadoop 2.0 NameNode HA和Federation实践
sizeofvoid.net
天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案，由于行业的特殊性，客户对服务的可用性有着非常高的要求，而HDFS长久以来都被单点故障的问题所困扰，直到Apache Hadoop在2012年5月发布了2.0的alpha版本，其中MRv2还很不成熟，可HDFS的新功能已经基本可用，尤其是其中的的High Availability(以下简称HA)和Federation。Cloudera也于7月制作了CDH4.0.1，包含了Hadoop 2.0的诸多新功能和组件，于是我们就基于CDH4.0.1进行了HA和Federation的测试。此工作由我和同事张军、钱兴会共同完成。
为什么需要HA和Federation
在Hadoop 2.0之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结
1.Secondary NameNode。它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NameNode(以下简称NN)失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。
2.Backup NameNode ()。它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。它同样是阶段性的做checkpoint，也无法保证数据完整性。手动把name.dir指向NFS。这是安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。
3.。Facebook有强大的运维做后盾，所以Avatarnode只是Hot Standby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop 2.0里的HA非常相似，从时间上来看，Hadoop 2.0应该是借鉴了Facebook的做法。
4.还有若干解决方案，基本都是依赖外部的HA机制，譬如，，等等。
集群容量和集群性能
单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。Hadoop 2.0里的HDFS Federation就是为了解决这两个问题而开发的。
Hadoop 2.0里HA的实现方式
498)this.width=498;' onmousewheel = 'javascript:return big(this)' src="/wyfs01/M00/0B/9D/wKioOVGkB7nyN7HZAACVbK70qFM017.jpg" alt="HDFS HA arch" />
图片来源：&&设计文档
图片作者： Sanjay Radia, Suresh Srinivas
在这个图里，我们可以看出HA的大致架构，其设计上的考虑包括：
利用共享存储来在两个NN间同步edits信息。
以前的HDFS是share nothing but NN，现在NN又share storage，这样其实是转移了单点故障的位置，但中高端的存储设备内部都有各种RAID以及冗余硬件包括电源以及网卡等，比服务器的可靠性还是略有提高。通过NN内部每次元数据变动后的flush操作，加上NFS的close-to-open，数据的一致性得到了保证。社区现在也试图把元数据存储放到上，以去除对共享存储的依赖，Cloudera也提供了Quorum Journal Manager的实现和代码，这篇中文的blog有详尽分析：
DataNode(以下简称DN)同时向两个NN汇报块信息。
这是让Standby NN保持集群最新状态的必需步骤，不赘述。
用于监视和控制NN进程的FailoverController进程
显然，我们不能在NN进程内进行心跳等信息同步，最简单的原因，一次FullGC就可以让NN挂起十几分钟，所以，必须要有一个独立的短小精悍的watchdog来专门负责监控。这也是一个松耦合的设计，便于扩展或更改，目前版本里是用ZooKeeper(以下简称ZK)来做同步锁，但用户可以方便的把这个ZooKeeper FailoverController(以下简称ZKFC)替换为其他的HA方案或leader选举方案。
，防止，就是保证在任何时候只有一个主NN，包括三个方面：
共享存储fencing，确保只有一个NN可以写入edits。
客户端fencing，确保只有一个NN可以响应客户端的请求。
DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。
Hadoop 2.0里Federation的实现方式
498)this.width=498;' onmousewheel = 'javascript:return big(this)' src="/wyfs01/M00/0B/9D/wKioOVGkB9aDouu9AACWZqDvhTQ002.jpg" alt="HDFS Federation arch" />
图片来源：&&设计文档
图片作者： Sanjay Radia, Suresh Srinivas
这个图过于简明，许多设计上的考虑并不那么直观，我们稍微总结一下
多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务
每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储
DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况
如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录
这样设计的好处大致有：
改动最小，向前兼容
现有的NN无需任何配置改动.
如果现有的客户端只连某台NN的话，代码和配置也无需改动。
分离命名空间管理和块存储管理
提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池
统一的块存储管理保证了资源利用率
可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证
客户端挂载表
通过路径自动对应NN
使Federation的配置改动对应用透明
以上是HA和Federation的简介，对于已经比较熟悉HDFS的朋友，这些信息应该已经可以帮助你快速理解其架构和实现，如果还需要深入了解细节的话，可以去详细阅读设计文档或是代码。这篇文章的主要目的是总结我们的测试结果，所以现在才算是正文开始。
为了彻底搞清HA和Federation的配置，我们直接一步到位，选择了如下的测试场景，结合了HA和Federation：
498)this.width=498;' onmousewheel = 'javascript:return big(this)' src="/wyfs01/M01/0B/9D/wKioOVGkB9ijYqC3AABob4y9J6U152.jpg" alt="HDFS测试场景" />
这张图里有个概念是前面没有说明的，就是NameService。Hadoop 2.0里对NN进行了一层抽象，提供服务的不再是NN本身，而是NameService(以下简称NS)。Federation是由多个NS组成的，每个NS又是由一个或两个(HA)NN组成的。在接下里的测试配置里会有更直观的例子。
图中DN-1到DN-6是六个DataNode，NN-1到NN-4是四个NameNode，分别组成两个HA的NS，再通过Federation组合对外提供服务。Storage Pool 1和Storage Pool 2分别对应这两个NS。我们在客户端进行了挂载表的映射，把/share映射到NS1，把/user映射到NS2，这个映射其实不光是要指定NS，还需要指定到其上的某个目录，稍后的配置中大家可以看到。
下面我们来看看配置文件里需要做哪些改动，为了便于理解，我们先把HA和Federation分别介绍，然后再介绍同时使用HA和Federation时的配置方式，首先我们来看HA的配置：
对于HA中的所有节点，包括NN和DN和客户端，需要做如下更改：
HA，所有节点，hdfs-site.xml
&&&&&dfs.nameservices&&&&&ns1&&&&&提供服务的NS逻辑名称，与core-site.xml里的对应&&&&&&&&&&&&&&dfs.ha.namenodes.${NS_ID}&&&&&nn1,nn3&&&&&列出该逻辑名称下的NameNode逻辑名称&&&&&&&&&&&&&&dfs.namenode.rpc-address.${NS_ID}.${NN_ID}&&&&&host-nn1:9000&&&&&指定NameNode的RPC位置&&&&&&&&&&&&&&dfs.namenode.http-address.${NS_ID}.${NN_ID}&&&&&host-nn1:50070&&&&&指定NameNode的Web&Server位置&&&&&&&&
以上的示例里，我们用了${}来表示变量值，其展开后的内容大致如下：
&&&&&dfs.ha.namenodes.ns1&&&&&nn1,nn3&&&&&&&&dfs.namenode.rpc-address.ns1.nn1&&&&&host-nn1:9000&&&&&&&&dfs.namenode.http-address.ns1.nn1&&&&&host-nn1:50070&&&&&&&&dfs.namenode.rpc-address.ns1.nn3&&&&&host-nn3:9000&&&&&&&&dfs.namenode.http-address.ns1.nn3&&&&&host-nn3:50070&&
与此同时，在HA集群的NameNode或客户端还需要做如下配置的改动：
HA，NameNode，hdfs-site.xml
&&&&&dfs.namenode.shared.edits.dir&&&&&file:///nfs/ha-edits&&&&&指定用于HA存放edits的共享存储，通常是NFS挂载点&&&&&&&&ha.zookeeper.quorum&&&&&host-zk1:2181,host-zk2:2181,host-zk3:2181,&&&&&指定用于HA的ZooKeeper集群机器列表&&&&&&&&ha.zookeeper.session-timeout.ms&&&&&5000&&&&&指定ZooKeeper超时间隔，单位毫秒&&&&&&&&dfs.ha.fencing.methods&&&&&sshfence&&&&&指定HA做隔离的方法，缺省是ssh，可设为shell，稍后详述&&
HA，客户端，hdfs-site.xml
&&&&&dfs.ha.automatic-failover.enabled&&&&&true&&&&&或者false&&&&&&&&dfs.client.failover.proxy.provider.${NS_ID}&&&&&org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider&&&&&指定客户端用于HA切换的代理类，不同的NS可以用不同的代理类&&&&&&&&&以上示例为Hadoop&2.0自带的缺省代理类&&
最后，为了方便使用相对路径，而不是每次都使用hdfs://ns1作为文件路径的前缀，我们还需要在各角色节点上修改core-site.xml：
HA，所有节点，core-site.xml
&&&&&fs.defaultFS&&&&&hdfs://ns1&&&&&缺省文件服务的协议和NS逻辑名称，和hdfs-site里的对应&&&&&&&&&此配置替代了1.0里的fs.default.name&&&&&&&&
接下来我们看一下如果单独使用Federation，应该如何配置，这里我们假设没有使用HA，而是直接使用nn1和nn2组成了Federation集群，他们对应的NS的逻辑名称分别是ns1和ns2。为了便于理解，我们从客户端使用的core-site.xml和挂载表入手：
Federation，所有节点，core-site.xml
&href=&cmt.xml&&&&&&&fs.defaultFS&&&&&viewfs://nsX&&&&&整个Federation集群对外提供服务的NS逻辑名称，&&&&&&&&&注意，这里的协议不再是hdfs，而是新引入的viewfs&&&&&&&&&这个逻辑名称会在下面的挂载表中用到&&
我们在上面的core-site中包含了一个cmt.xml文件，也就是Client Mount Table，客户端挂载表，其内容就是虚拟路径到具体某个NS及其物理子目录的映射关系，譬如/share映射到ns1的/real_share，/user映射到ns2的/real_user，示例如下：
Federation，所有节点，cmt.xml
&&&&&&&&&&&&&&fs.viewfs.mounttable.nsX.link./share&&&&&&&&&hdfs://ns1/real_share&&&&&&&&&&&&&&&&&&&fs.viewfs.mounttable.nsX.link./user&&&&&&&&&hdfs://ns2/real_user&&&&&&&
注意，这里面的nsX与core-site.xml中的nsX对应。而且对每个NS，你都可以建立多个虚拟路径，映射到不同的物理路径。与此同时，hdfs-site.xml中需要给出每个NS的具体信息：
Federation，所有节点，hdfs-site.xml
&&&&&dfs.nameservices&&&&&ns1,ns2&&&&&提供服务的NS逻辑名称，与core-site.xml或cmt.xml里的对应&&&&&&&&&&&&&&dfs.namenode.rpc-address.ns1&&&&&host-nn1:9000&&&&&&&&dfs.namenode.http-address.ns1&&&&&host-nn1:50070&&&&&&&&dfs.namenode.rpc-address.ns2&&&&&host-nn2:9000&&&&&&&&dfs.namenode.http-address.ns2&&&&&host-nn2:50070&&
可以看到，在只有Federation且没有HA的情况下，配置的name里只需要直接给出${NS_ID}，然后value就是实际的机器名和端口号，不需要再.${NN_ID}。
这里有一个情况，就是NN本身的配置。从上面的内容里大家可以知道，NN上是需要事先建立好客户端挂载表映射的目标物理路径，譬如/real_share，之后才能通过以上的映射进行访问，可是，如果不指定全路径，而是通过映射+相对路径的话，客户端只能在挂载点的虚拟目录之下进行操作，从而无法创建映射目录本身的物理目录。所以，为了在NN上建立挂载点映射目录，我们就必须在命令行里使用hdfs协议和绝对路径：
hdfs dfs -mkdir hdfs://ns1/real_share
上面这个问题，我在EasyHadoop的聚会上没有讲清楚，只是简单的说在NN上不要使用viewfs://来配置，而是使用hdfs://，那样是可以解决问题，但是是并不是最好的方案，也没有把问题的根本说清楚。
最后，我们来组合HA和Federation，真正搭建出和本节开始处的测试环境示意图一样的实例。通过前面的描述，有经验的朋友应该已经猜到了，其实HA+Federation配置的关键，就是组合hdfs-site.xml里的dfs.nameservices以及dfs.ha.namenodes.${NS_ID}，然后按照${NS_ID}和${NN_ID}来组合name，列出所有NN的信息即可。其余配置一样。
HA + Federation，所有节点，hdfs-site.xml
&&&&&dfs.nameservices&&&&&ns1,&ns2&&&&&&&&dfs.ha.namenodes.ns1&&&&&nn1,nn3&&&&&&&&dfs.ha.namenodes.ns2&&&&&nn2,nn4&&&&&&&&dfs.namenode.rpc-address.ns1.nn1&&&&&host-nn1:9000&&&&&&&&dfs.namenode.http-address.ns1.nn1&&&&&host-nn1:50070&&&&&&&&dfs.namenode.rpc-address.ns1.nn3&&&&&host-nn3:9000&&&&&&&&dfs.namenode.http-address.ns1.nn3&&&&&host-nn3:50070&&&&&&&&dfs.namenode.rpc-address.ns2.nn2&&&&&host-nn2:9000&&&&&&&&dfs.namenode.http-address.ns2.nn2&&&&&host-nn2:50070&&&&&&&&dfs.namenode.rpc-address.ns2.nn4&&&&&host-nn4:9000&&&&&&&&dfs.namenode.http-address.ns2.nn4&&&&&host-nn4:50070&&
对于没有.${NS_ID}，也就是未区分NS的项目，需要在每台NN上分别使用不同的值单独配置，尤其是NFS位置(dfs.namenode.shared.edits.dir)，因为不同NS必定要使用不同的NFS目录来做各自内部的HA (除非mount到本地是相同的，只是在NFS服务器端是不同的，但这样是非常不好的实践)；而像ZK位置和隔离方式等其实大可使用一样的配置。
除了配置以外，集群的初始化也有一些额外的步骤，譬如，创建HA环境的时候，需要先格式化一台NN，然后同步其name.dir下面的数据到第二台，然后再启动集群 (我们没有测试从单台升级为HA的情况，但道理应该一样)。在创建Federation环境的时候，需要注意保持${CLUSTER_ID}的值，以确保所有NN能共享同一个集群的存储资源，具体做法是在格式化第一台NN之后，取得其${CLUSTER_ID}的值，然后用如下命令格式化其他NN：
hadoop namenode -format -clusterid ${CLUSTER_ID}
当然，你也可以从第一台开始就使用自己定义的${CLUSTER_ID}值。
如果是HA + Federation的场景，则需要用Federation的格式化方式初始化两台，每个HA环境一台，保证${CLUSTER_ID}一致，然后分别同步name.dir下的元数据到HA环境里的另一台上，再启动集群。
Hadoop 2.0中的HDFS客户端和API也有些许更改，命令行引入了新的hdfs命令，hdfs dfs就等同于以前的hadoop fs命令。API里引入了新的ViewFileSystem类，可以通过它来获取挂载表的内容，如果你不需要读取挂载表内容，而只是使用文件系统的话，可以无视挂载表，直接通过路径来打开或创建文件。代码示例如下：
ViewFileSystem&fsView&=&(ViewFileSystem)&ViewFileSystem.get(conf);&MountPoint[]&m&=&fsView.getMountPoints();&for&(MountPoint&m1&:&m)&&&&&System.out.println(&m1.getSrc()&);&&//&直接使用/share/test.txt创建文件&//&如果按照之前的配置，客户端会自动根据挂载表找到是ns1&//&然后再通过failover&proxy类知道nn1是Active&NN并与其通信&Path&p&=&new&Path(&/share/test.txt&);&FSDataOutputStream&fos&=&fsView.create(p);&
HA测试方案和结果
Federation的测试主要是功能性上的，能用就OK了，这里的测试方案只是针对HA而言。我们设计了两个维度的测试矩阵：系统失效方式，客户端连接模型
系统失效有两种：
1.终止NameNode进程：ZKFC主动释放锁
模拟机器OOM、死锁、硬件性能骤降等故障
2.NN机器掉电：ZK锁超时
模拟网络和交换机故障、以及掉电本身
客户端连接也是两种：
1.已连接的客户端(持续拷贝96M的文件，1M每块)
通过增加块的数目，我们希望客户端会不断的向NN去申请新的块；一般是在第一个文件快结束或第二个文件刚开始拷贝的时候使系统失效。
2.新发起连接的客户端(持续拷贝96M的文件，100M每块)
因为只有一个块，所以在实际拷贝过程中失效并不会立刻导致客户端或DN报错，但下一次新发起连接的客户端会一开始就没有NN可连；一般是在第一个文件快结束拷贝时使系统失效。
针对每一种组合，我们反复测试10－30次，每次拷贝5个文件进入HDFS，因为时间不一定掐的很准，所以有时候也会是在第三或第四个文件的时候才使系统失效，不管如何，我们会在结束后从HDFS里取出所有文件，并挨个检查文件MD5，以确保数据的完整性。
测试结果如下：
ZKFC主动释放锁
5-8秒切换(需同步edits)
客户端偶尔会有重试(~10%)
但从未失败
15-20s切换(超时设置为10s)
客户端重试几率变大(~75%)
且偶有失败(~15%)，但仅见于已连接客户端
可确保数据完整性
MD5校验从未出错
失败时客户端有Exception
我们的结论是：Hadoop 2.0里的HDFS HA基本可满足高可用性
我们另外还(试图)测试Append时候NN失效的情形，因为Append的代码逻辑非常复杂，所以期望可以有新的发现，但是由于复杂的那一段只是在补足最尾部块的时候，所以必须在测试程序一运行起来就关掉NN，测了几次，没发现异常情况。另外我们还使用HBase进行了测试，由于WAL只是append，而且HFile的compaction操作又并不频繁，所以也没有遇到问题。
HA推荐配置及其他
HA推荐配置
ha.zookeeper.session-timeout.ms ＝ 10000
ZK心跳是2000
缺省的5000很容易因为网络拥塞或NN GC等导致误判
为避免电源闪断，不要把start-dfs.sh放在init.d里
dfs.ha.fencing.methods ＝ shell(/path/to/the/script)
STONITH (Shoot The Other Node In The Head)不一定可行，当没有网络或掉电的时候，是没法shoot的
缺省的隔离手段是sshfence，在掉电情况下就无法成功完成，从而切换失败
唯一能保证不发生脑裂的方案就是确保原Active无法访问NFS
通过script修改NFS上的iptables，禁止另一台NN访问
管理员及时介入，恢复原Active，使其成为Standby。恢复iptables
客户端重试机制
代码可在org.apache.hadoop.io.retry.RetryPolicies.FailoverOnNetworkExceptionRetry里找到。目前的客户端在遇到以下Exception时启动重试：
//&连接失败&ConnectException&NoRouteToHostException&UnKnownHostException&//&连到了Standby而不是Active&StandbyException&
其重试时间间隔的计算公式为：
RAND(0.5~1.5) * min (2^retryies * baseMillis, maxMillis)
baseMillis = dfs.client.failover.sleep.base.millis，缺省500
maxMillis = dfs.client.failover.sleep.max.millis，缺省15000
最大重试次数：dfs.client.failover.max.attempts，缺省15
关于那15%失败的情况，我们从日志和代码分析，基本确认是HA里的问题，就是Standby NN在变为Active NN的过程中，会试图重置文件的lease的owner，从而导致LeaseExpiredException: Lease mismatch，客户端遇到这个异常不会重试，导致操作失败。这是一个非常容易重现的问题，相信作者也知道，可能是为了lease安全性也就是数据完整性做的一个取舍吧：宁可客户端失败千次，不可lease分配错一次，毕竟，客户端失败再重新创建文件是一个很廉价且安全的过程。另外，与MapReduce 2.0 (YARN)的整合测试我们也没来得及做，原因是我们觉得YARN本身各个组件的HA还不完善，用它来测HDFS的HA有点本末倒置。
原文链接：
【责任编辑： TEL：（010）】
关于的更多文章
Hadoop 2.0，为克服Hadoop 1.0中HDFS和MapReduce存在的各种问题
随着云计算、物联网、大数据、移动互联网的大发展，你应该知道这些。
这周Windows8.1正式版发布了，不知道各位有没有去更新
十一长假归来上班，好像更累了；早上也越来越堵了。小
数据结构课程，貌似是大学计算机、网络、软件等专业的
本书是关于如何使用已有的密码技术和算法对数据库中存储的信息进行保护的书，书中所关注的内容主要是如何设计、建立（或者挑选、
51CTO旗下网站