最新Hadoop HANFS高可集群性主备配置.docx
《最新Hadoop HANFS高可集群性主备配置.docx》由会员分享,可在线阅读,更多相关《最新Hadoop HANFS高可集群性主备配置.docx(10页珍藏版)》请在冰豆网上搜索。
最新HadoopHANFS高可集群性主备配置
HadoopHA高可集群性主备配置
一、 Hadoop 的高可用性
1. 概论
本指南提供了一个HDFS 的高可用性(HA )功能的概述,以及如何配置和管理HDFS 高可用性(HA) 集群。
本文档假定读者具有对HDFS 集群的组件和节点类型具有一定理解。
有关详情,请参阅Apache 的HDFS 的架构指南。
http:
//hadoop.apache.org/common/docs/current/hdfs_design.html
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 。
当Active 节点发生故障需要进行切换时,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) 的软件配置
1. 配置概述
对于使用一个NameNode 的集群,HA 的配置与HDFS 的Federation 机制是兼容的,新的配置项被设计用在集群中的所有相同类型的节点具有相同的配置,不需要为相同类型节点的不同机器部署不同的配置文件。
HDFS(HA) 集群使用NameServiceID 来标示NameNode ,作为NameNode 的编号。
2. 现有的配置参数
下面的配置参数发生了变化:
core-site.xml
(1)fs.defaultFS- 如果没有配置则使用fs.default.name
Xml代码
fs.defaultFS
hdfs:
//mycluster
3. 新增的配置参数
hdfs-site.xml
(1)dfs.federation.nameservices---federation 服务名
Xml代码
dfs.federation.nameservices
mycluster
(2) 如果同时还使用HDFS 的Federation 机制,则应该使用逗号分隔nameservices 列表
Xml代码
dfs.federation.nameservices
mycluster,mycluster1
(3)dfs.ha.namenodes.[nameserviceID]--- 每个NameNode 在名称服务中的唯一标识, 此版本最大只支持两个NameNode
Xml代码
dfs.ha.namenodes.mycluster
nn1,nn2
(4)dfs.namenode.rpc-address.[nameserviceID]---rpc 通信地址
Xml代码
dfs.namenode.rpc-address.mycluster.nn1
:
8020
dfs.namenode.rpc-address.mycluster.nn2
:
8020
(5)dfs.namenode.http-address.[nameserviceID]---http 通信地址
Xml代码
dfs.namenode.http-address.mycluster.nn1
:
50070
dfs.namenode.http-address.mycluster.nn2
:
50070
(6)dfs.namenode.shared.edits.dir--- 共享存储目录位置
Xml代码
dfs.namenode.shared.edits.dir
file:
///hadoop/nfs/ha-name-dir-shared
4. 客户端故障转移配置
(1)dfs.client.failover.proxy.provider.[nameserviceID]---HDFS 客户端与Active 节点通信的java 类,使用其确定Active 节点是否活跃
Xml代码
dfs.client.failover.proxy.provider.mycluster org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
5. 安全配置
dfs.ha.fencing.methods--- 用于在Active 节点切换期间的安全机制,确保在任何时间都只有一个NameNode 处于活跃状态。
在故障切换期间,haadmin 命令确保在将其它NameNode 转换为Active 状态之前Active 节点处在Standby 状态,或其进程已被终止。
至少应该配置一个,因为没有默认配置,因此如果配置则HA 机制将会失效。
如果要实现自定义的安全机制,参照org.apache.hadoop.ha.NodeFencer
(1)sshfence 方式
通过SSH 连接到ActiveNameNode 杀死监听服务端TCP 监听的进程
Xml代码
dfs.ha.fencing.methods
sshfence
dfs.ha.fencing.ssh.private-key-files
/root/.ssh/id_rsa
或者配置非标准的用户名和端口以及超时时间
Xml代码
dfs.ha.fencing.methods
sshfence([[username][:
port]])
dfs.ha.fencing.ssh.connect-timeout
60000
(2)shell 方式
运行脚本实现安全机制
Xml代码
dfs.ha.fencing.methods
shell(/path/to/my/script.sharg1arg2...)
四、 HDFS(HA) 的初始化
设定所有的必要配置项后,必须首先同步两个NameNode 上的元数据。
如果是新建的HDFS 集群,则应首先格式化一个NameNode(两个NameNode中的一个,一个即可)。
如果是想把非HA 集群转换为HA 集群,按照dfs.namenode.name.dir 、dfs.namenode.edits.dir 的配置把当前NameNode 节点的元数据目录复制到另一个NameNode。
还应该确保共享存储目录下(dfs.namenode.shared.edits.dir) 包含NameNode 所有的元数据。
注:
当格式化一个NameNode后,必须将元数据拷贝到另一个NameNode上,否则开启进程后,无法连接。
五、 HDFS(HA) 的管理
格式化完成后,开始启动进程
#sbin/start-all.sh
默认以HA 方式启动集群,启动后默认都为Standby 状态。
使用如下命令设置Active 节点
#bin/hdfshaadmin–DFSHAadmin–transitionToActivenn1
如果让nn2 成为变为activenn1 变为standby ,则
#bin/hdfshaadmin-DfSHAadmin-failovernn1nn2
如果失败(isnotreadytobecomeactive) 则
#bin/hdfshaadmin-DfSHAadmin-failover--forceactivenn1nn2
Usage:
DFSHAAdmin[-ns]
[-transitionToActive]
[-transitionToStandby]
[-failover[--forcefence][--forceactive]]
[-getServiceState]
[-checkHealth]
[-help]
注:
StandbyNameNode节点上的Mapreduce没有启动(本来就没有该进程)
HA测试:
nn1为active,nn2为standby。
运行一个测试用例。
在Client客户端可查看到数据结果
把nn1和nn2互换,nn1为standby,nn2为active
在client继续查看。
依然可以查看到数据结果
当把nn1机器关掉后,(表示该机器坏掉,进程丢失)
再在client查看,此时无法查看到结果。
然后到nn2机器上,进行切换。
将nn2设置为active
注:
此时不能用hdfshaadmin-DFSHAadmin-failovernn1nn2
或者
hdfshaadmin-DFSHAadmin-failover--forceactivenn1nn2
命令。
因为nn1已经坏掉了。
故只能将nn2设置为active,即可正常运行。
把nn1启动。
先在nn2上关闭NameNode,再在nn1上开启。
注:
重启nn1之前,要把nn2上的active变为standby。
否则在nn1上执行start-all.sh时,无法开启nn1的namenode,只开启了nn2上的namenode。
此时nn1上的namenode无法启动。
故先把nn2上的active变为standby,然后stop-all.sh,再star-all.sh。
再将nn1变为active。
(前提,NFS目录要挂载一下)
mount-tnfs4192.168.75.102:
/nfs_hadoop/hadoop/nfs/ha-name-dir-shared/
stop-all.sh
star-all.sh
hdfshaadmin-DFSHAadmin-transitionToActivenn1
再在client查看
“腾飞计划”培训学习心得
“腾飞计划”一期训练营的举办让我学到了很多东西,使我受益匪浅。
光阴似箭,时间飞快地旋转。
五天的时间对我们来说简直太短暂了,当我们还在兴头上时,培训已经走向了尾声,当伙伴们依依不舍地道别时,我们说下次提升班时还可以再见。
毕竟每个人都肩负着重任来到了这里,其实学习并不是我们的最终目的,最终目的是提升技能服务营销团队。
我们带着无比激动的心情,回到自己的团队,回到伙伴们的身边。
心里一直在想这么长时间家里不知怎么样了,并且急于把学到的东西一下子展现出来,用到我们的团队中。
让我们的团队与我们一起快速的成长起来!
这次培训我的压力很大,不是因为我什么都不会,而是因为优秀的伙伴太多太多。
他们每个人都有闪光的地方,每个人都是我的老师,我很庆幸可以跟这些优秀的伙伴一起学习。
非常感谢公司给我这个机会!
以下是我在本次培训班中的一些感受:
一、刚到北京,从火车上下来就匆匆忙忙往国家教育行政学院赶,刚去报到,吃完晚饭就开始了第一天的培训科目,晚上zz老师给我们讲解了公司的一些规定和培训的相关内容,然后来个训前考试,面对考试题那是考的一塌糊涂啊,新人嘛,不会是难免的,最后连徐艳老师也说这个题不简单,主要是多选题太要命……,我们彼此分成不同小组,进行小组间的比赛,这主要锻炼了大家的团队合作精神,在以后的工作中,我们综拓的团队精神是非常重要的,我们小组的排名是“巅峰”排,排呼是“齐心协力,勇创佳绩,耶!
!
!
,就这几个字我们小组想了N久才决定好了,第一天的培训结束,晚上12点以后睡觉的历程正式开始。
二、早上6点多起床,每天的训练就这样拉开了序幕。
早上起来跑操,做游戏,好久没锻炼一锻炼还真有点不适应。
上午胡总来给我们讲了不少知识,让我受益匪浅,接下来开始每个老师的课程都很精彩,通过学习让我了解了我们泰康的企业文化,发展战略,辉煌的历史和光明的未来。
对于我们综拓而言了解我们的产品是我们应该掌握的最基础的东西,通过产品知识的学习,使我对产品有了更丰富得了解,学习了企业年金还有核保的基础知识,让我们每一个人成为了公司最基层的核保人,对于基本的单子核保能不能过我们自己能做到心中有数。
通过各位老师的经验分享,让我学到了非常多的东西,只能说每个老师的课程都非常精彩!
!
三、为了练舞蹈,我们曾夜战到半夜12点,真辛苦呀,最让人感动的是大着肚子的王媛媛老师,怀着孕还那么辛苦,真令人感动。