Hadoop HANFS高可集群性主备配置Word格式文档下载.docx
《Hadoop HANFS高可集群性主备配置Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《Hadoop HANFS高可集群性主备配置Word格式文档下载.docx（9页珍藏版）》请在冰豆网上搜索。
2.
背景
CDH4
之前，在HDFS
集群中NameNode
存在单点故障SPOF（singlepointoffailure）。
对于只有一个NameNode
的集群，如果NameNode
机器出现故障，那么整个集群将无法使用，直到NameNode
重新启动。
NameNode
主要在以下两个方面影响HDFS
集群:
（1）.NameNode
机器发生意外，比如宕机，集群将无法使用，直到管理员重启NameNode
（2）.NameNode
机器需要升级，包括软件、硬件升级，此时集群也将无法使用
对于7×
24生产环境，是具有极大的风险。
HDFS
的HA
功能通过配置Active/Standby
两个NameNodes
实现在集群中对NameNode
的热备来解决上述问题。
如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode
很快的切换到另外一台机器。
3.
架构
在一个典型的HDFS（HA）
集群中，使用两台单独的机器配置为NameNodes
。
在任何时间点，确保NameNodes
中只有一个处于Active
状态，其他的处在Standby
状态。
其中ActiveNameNode
负责集群中的所有客户端操作，StandbyNameNode
仅仅充当备机，保证一旦ActiveNameNode
出现问题能够快速切换。
为了保证Standby
节点与Active
节点的状态保持同步，目前是通过两个节点同时访问一个共享的存储设备（
如NFS）
来实现的，在以后的版本中可能会做进一步的改进。
当Active
节点的namespace
发生改变时，存储在共享目录中的日志文件也会被修改，Standby
节点监测到日志变化后，将其作用到自身的namespace
节点发生故障需要进行切换时，Standby
节点由Standby
状态转换为Active
状态前将会把所有未读日志作用到自身的namespace
以确保自身的namespace
与主节点的namespace
保持一致。
为了实现快速切换，Standby
节点获取集群的最新文件块信息也是很有必要的。
为了实现这一目标，DataNode
需要配置NameNodes
的位置，并同时给他们发送文件块信息以及心跳检测。
任意时间只有一个ActiveNameNode
对于HDFS（HA）
集群的正常运行至关重要，否则两者的namespace
将不能保持同步，面临数据丢失和其它问题的危险性。
为了防止出现这种情况，管理员必须为共享存储配置至少一个安全机制。
这种机制应该保证:
在切换期间，如果不能证实当前Active
节点已经改变了状态，那么此机制应切断当前Active
节点对共享存储的访问，这样可以防止在切换期间当前Active
节点继续对namespace
进行修改，确保新的Active
节点能够安全的切换。
注意:
此版本只支持手动切换，这意味着集群并不能自动检测Active
节点发生故障。
二、常见的HA方案
1、常见HA方案
目前社区版的做法是有两种保障机制，第一种是可以设置一个NFS的目录，存储fsimage和editlog，存储的是实时数据，这样当namenode挂掉后能够通过fsimage和editlog进行完全恢复。
第二种是设置secondarynamenode，名称很迷惑，但其作用是对fsimage和editlog进行定期的merge，默认是5分钟，所以获得的数据是过期的，存在数据丢失，但是能够恢复大部分数据。
Hadoop本身提供了可利用secondarynamenode的备份数据来恢复namenode的元数据的方案，但因为checkpoint（在每次checkpoint的时候secondarynamenode才会合并并同步namenode的数据）的问题，secondarynamenode的备份数据并不能时刻保持与namenode同步，也就是说在namenode宕机的时候secondarynamenode可能会丢失一段时间的数据，这段时间取决于checkpoint的周期。
我们可以减小checkpoint的周期来减少数据的丢失量，但由于每次checkpoint很耗性能，而且这种方案也不能从根本上解决数据丢失的问题。
所以如果需求上不允许这种数据的丢失，这种方案可直接不予考虑。
2、存在的问题
对于生产集群来说，很多操作不能够停止太长时间。
而对于上面两种方式，即使能够恢复数据，重新将namenode上线，在经过datanode的blockReport过程，需要很长时间。
相同的问题也出现在打patch上，如果对datanode打patch影响还不是很大，可以一台一台打patch，即使下线一台datanode，数据的多份拷贝不会丢失，client可以通过与namenode通信获得其它的副本对应的datanode的位置，整体的服务没有停止。
但是如果对于namenode打patch，就需要停止整体服务，重新上线后会等待大量时间在datanode的blockReport上。
根据facebook的一篇文章，他们重新启动12PB的数据的集群需要大概半个小时。
3、FaceBook的HA做法
Facebook的做法是在不改变namenode和datanode整体逻辑的基础上，在其上层开发出AvaterNode，AvatarNode的意思就是支持互相切换，就像人可以切换Na'
vi族人，也可以切换过来一样。
他们的做法是提供一个PrimaryAvatar和一个StandbyAvatar，通过virualIP来设置IP地址。
PrimaryAvatar对外提供服务，设置了NFS目录，将FSImage和EditLog远程存储。
StandbyAvatar将NFS目录中的FSImage和EditLog读取过来进行同步，并且设置StandbyAvatar一直处于safemode状态，不影响正常操作。
这样StandbyAvatar相当于一个热拷贝，获得了所有的实时数据。
在Datanode部分也进行了封装，所有Datanode都像两个Namenode汇报，保证数据的实时性。
这样，当PrimaryAvatar下线后，通过操作可以迅速让StandbyAvatar切换为PrimaryAvatra上线。
时间在分钟级，并且不需要重启。
中移动写的他们的NNC集群，采用的是在一个Namenode上插入Deamon，将每个操作同步到slavenamenode中。
看起来性能应该会下降很多，他们也没有提供数据。
三、Hadoop的HA
提供2台机器做双机热备。
一台为Active
节点，一台为StandBy节点。
同时只有Active节点对外提供服务。
源数据存储在共享存储。
StandBy会时刻到共享存储拿Meta信息，以保证切换时不会丢掉数据。
DataNode会向2台机器汇报自己的信息。
仍需要配置SencondaryNameNode接解决Editslog变大问题。
注：
NFS配置参见另一篇文档
三、
HDFS（HA）
的软件配置
配置概述
对于使用一个NameNode
的集群，HA
的配置与HDFS
的Federation
机制是兼容的，新的配置项被设计用在集群中的所有相同类型的节点具有相同的配置，不需要为相同类型节点的不同机器部署不同的配置文件。
集群使用NameServiceID
来标示NameNode
，作为NameNode
的编号。
现有的配置参数
下面的配置参数发生了变化：
core-site.xml
（1）fs.defaultFS-
如果没有配置则使用fs.default.name
Xml代码
<
property>
<
name>
fs.defaultFS<
/name>
value>
hdfs:
//mycluster<
/value>
/property>
新增的配置参数
hdfs-site.xml
（1）dfs.federation.nameservices---federation
服务名
dfs.federation.nameservices<
mycluster<
（2）
如果同时还使用HDFS
机制，则应该使用逗号分隔nameservices
列表
mycluster,mycluster1<
（3）dfs.ha.namenodes.[nameserviceID]---
每个NameNode
在名称服务中的唯一标识,
此版本最大只支持两个NameNode
dfs.ha.namenodes.mycluster<
nn1,nn2<
（4）dfs.namenode.rpc-address.[nameserviceID]---rpc
通信地址
dfs.namenode.rpc-address.mycluster.nn1<
:
8020<
dfs.namenode.rpc-address.mycluster.nn2<
（5）dfs.namenode.http-address.[nameserviceID]---http
dfs.namenode.http-address.mycluster.nn1<
50070<
dfs.namenode.http-address.mycluster.nn2<
（6）dfs.namenode.shared.edits.dir---
共享存储目录位置
dfs.namenode.shared.edits.dir<
升级会员 