一、背景 天云趋势在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 1. 单点故障 Secondary NameNode。它不是HA，它只是阶段性的合并edits和fsimage，以缩短集群启动的时间。当NameNode(以下简称NN)失效的时候，Secondary NN并无法立刻提供服务，Secondary NN甚至无法保证数据完整性：如果NN数据丢失的话，在上一次合并后的文件系统的改动会丢失。 Backup NameNode (HADOOP-4539)。它在内存中复制了NN的当前状态，算是Warm Standby，可也就仅限于此，并没有failover等。它同样是阶段性的做checkpoint，也无法保证数据完整性。 手动把name.dir指向NFS。这是安全的Cold Standby，可以保证元数据不丢失，但集群的恢复则完全靠手动。 Facebook AvatarNode。Facebook有强大的运维做后盾，所以Avatarnode只是Hot Standby，并没有自动切换，当主NN失效的时候，需要管理员确认，然后手动把对外提供服务的虚拟IP映射到Standby NN，这样做的好处是确保不会发生脑裂的场景。其某些设计思想和Hadoop 2.0里的HA非常相似，从时间上来看，Hadoop 2.0应该是借鉴了Facebook的做法。 还有若干解决方案，基本都是依赖外部的HA机制，譬如DRBD，Linux HA，VMware的FT等等。 2. 集群容量和集群性能 三、Hadoop 2.0里HA的实现方式
利用共享存储来在两个NN间同步edits信息。 DataNode(以下简称DN)同时向两个NN汇报块信息。 用于监视和控制NN进程的FailoverController进程 隔离(Fencing))，防止脑裂)，就是保证在任何时候只有一个主NN，包括三个方面：共享存储fencing，确保只有一个NN可以写入edits。 客户端fencing，确保只有一个NN可以响应客户端的请求。 DataNode fencing，确保只有一个NN可以向DN下发命令，譬如删除块，复制块，等等。 四、Hadoop 2.0里Federation的实现方式
多个NN共用一个集群里DN上的存储资源，每个NN都可以单独对外提供服务 每个NN都会定义一个存储池，有单独的id，每个DN都为所有存储池提供存储 DN会按照存储池id向其对应的NN汇报块信息，同时，DN会向所有NN汇报本地存储可用资源情况 如果需要在客户端方便的访问若干个NN上的资源，可以使用客户端挂载表，把不同的目录映射到不同的NN，但NN上必须存在相应的目录 改动最小，向前兼容现有的NN无需任何配置改动. 如果现有的客户端只连某台NN的话，代码和配置也无需改动。 分离命名空间管理和块存储管理提供良好扩展性的同时允许其他文件系统或应用直接使用块存储池 统一的块存储管理保证了资源利用率 可以只通过防火墙配置达到一定的文件访问隔离，而无需使用复杂的Kerberos认证 客户端挂载表通过路径自动对应NN 使Federation的配置改动对应用透明 五、测试环境 以上是HA和Federation的简介，对于已经比较熟悉HDFS的朋友，这些信息应该已经可以帮助你快速理解其架构和实现，如果还需要深入了解细节的话，可以去详细阅读设计文档或是代码。这篇文章的主要目的是总结我们的测试结果，所以现在才算是正文开始。
<P><property>
<name>dfs.namenode.shared.edits.dir</name>
<value>file:///nfs/ha-edits</value>
<description>指定用于HA存放edits的共享存储，通常是NFS挂载点</description>
</property>
<property>
<name>ha.zookeeper.quorum</name>
<value>host-zk1:2181,host-zk2:2181,host-zk3:2181,</value>
<description>指定用于HA的ZooKeeper集群机器列表</description>
</property>
<property>
<name>ha.zookeeper.session-timeout.ms</name>
<value>5000</value>
<description>指定ZooKeeper超时间隔，单位毫秒</description>
</property>
<property>
<name>dfs.ha.fencing.methods</name>
<value>sshfence</value>
<description>指定HA做隔离的方法，缺省是ssh，可设为shell，稍后详述</description>
</property>
HA，客户端，hdfs-site.xml
<property>
<name>dfs.ha.automatic-failover.enabled</name>
<value>true</value>
<description>或者false</description>
</property>
<property>
<name>dfs.client.failover.proxy.provider.${NS_ID}</name>
<value>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider</value>
<description>指定客户端用于HA切换的代理类，不同的NS可以用不同的代理类
以上示例为Hadoop 2.0自带的缺省代理类</description>
</property>
</P><P></:PROPERTY></P> 复制代码 <property>
<name>fs.defaultFS</name>
<value>hdfs://ns1</value>
<description>缺省文件服务的协议和NS逻辑名称，和hdfs-site里的对应
此配置替代了1.0里的fs.default.name</description>
</property>
复制代码 <xi:include href=“cmt.xml"/>
<property>
<name>fs.defaultFS</name>
<value>viewfs://nsX</value>
<description>整个Federation集群对外提供服务的NS逻辑名称，
注意，这里的协议不再是hdfs，而是新引入的viewfs
这个逻辑名称会在下面的挂载表中用到</description>
</property>
复制代码 <configuration>
<property>
<name>fs.viewfs.mounttable.nsX.link./share</name>
<value>hdfs://ns1/real_share</value>
</property>
<property>
<name>fs.viewfs.mounttable.nsX.link./user</name>
<value>hdfs://ns2/real_user</value>
</property>
</configuration>
复制代码 <property>
<name>dfs.nameservices</name>
<value>ns1,ns2</value>
<description>提供服务的NS逻辑名称，与core-site.xml或cmt.xml里的对应</description>
</property>
<property>
<name>dfs.namenode.rpc-address.ns1</name>
<value>host-nn1:9000</value>
</property>
<property>
<name>dfs.namenode.http-address.ns1</name>
<value>host-nn1:50070</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns2</name>
<value>host-nn2:9000</value>
</property>
<property>
<name>dfs.namenode.http-address.ns2</name>
<value>host-nn2:50070</value>
</property>
</:PROPERTY> 复制代码 <PRE>hdfs dfs -mkdir hdfs://ns1/real_share
</PRE> 复制代码 <property>
<name>dfs.nameservices</name>
<value>ns1, ns2</value>
</property>
<property>
<name>dfs.ha.namenodes.ns1</name>
<value>nn1,nn3</value>
</property>
<property>
<name>dfs.ha.namenodes.ns2</name>
<value>nn2,nn4</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns1.nn1</name>
<value>host-nn1:9000</value>
</property>
<property>
<name>dfs.namenode.http-address.ns1.nn1</name>
<value>host-nn1:50070</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns1.nn3</name>
<value>host-nn3:9000</value>
</property>
<property>
<name>dfs.namenode.http-address.ns1.nn3</name>
<value>host-nn3:50070</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns2.nn2</name>
<value>host-nn2:9000</value>
</property>
<property>
<name>dfs.namenode.http-address.ns2.nn2</name>
<value>host-nn2:50070</value>
</property>
<property>
<name>dfs.namenode.rpc-address.ns2.nn4</name>
<value>host-nn4:9000</value>
</property>
<property>
<name>dfs.namenode.http-address.ns2.nn4</name>
<value>host-nn4:50070</value>
</property>
复制代码 hadoop namenode -format -clusterid ${CLUSTER_ID}
复制代码 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);
复制代码 终止NameNode进程：ZKFC主动释放锁 NN机器掉电：ZK锁超时 已连接的客户端(持续拷贝96M的文件，1M每块) 新发起连接的客户端(持续拷贝96M的文件，100M每块) ZKFC主动释放锁5-8秒切换(需同步edits) 客户端偶尔会有重试(~10%) 但从未失败 ZK锁超时15-20s切换(超时设置为10s) 客户端重试几率变大(~75%) 且偶有失败(~15%)，但仅见于已连接客户端 可确保数据完整性MD5校验从未出错 +失败时客户端有Exception Hadoop 2.0里的HDFS HA基本可满足高可用性 扩展测试 七、HA推荐配置及其他 HA推荐配置 ha.zookeeper.session-timeout.ms ＝ 10000ZK心跳是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 客户端重试机制 // 连接失败
ConnectException
NoRouteToHostException
UnKnownHostException
// 连到了Standby而不是Active
StandbyException
复制代码 未尽事宜 
/2 
京ICP备2020039040号
简书网举报电话：021-34700000
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
