Heim  >  Artikel  >  Datenbank  >  hadoop1.0 高可靠性(HA)安装与总结

hadoop1.0 高可靠性(HA)安装与总结

WBOY
WBOYOriginal
2016-06-07 16:41:091397Durchsuche

继上次安装完Kerberos安全认证后,现在我在这基础上,又给CDH加上了HA(high availability),也就是高可靠性,具体来讲就是双NameNode,双Jobtracker(我还是在MRv1模式下),有了HA后,这下集群的健壮性就能够得到很好的保证了。 我还是按照官方文档来操作

继上次安装完Kerberos安全认证后,现在我在这基础上,又给CDH加上了HA(high availability),也就是高可靠性,具体来讲就是双NameNode,双Jobtracker(我还是在MRv1模式下),有了HA后,这下集群的健壮性就能够得到很好的保证了。

我还是按照官方文档来操作的,有了上次的经验,建议大家在具体操作实施前,先快速阅读一遍,做到心中有数,我还阅读了Apache官方的说明,也不用怎么详细,大概知道怎么回事就行了。

首先说明一点的就是,CDH5 只支持Quorum Journal Manager(QJM)模式下的HA,不支持NFS模式的,这点和Apache官方的不一样,大家要留意下。

下面说说我遇到的坑:

  • 按照software_config上面说的配置一步步来,如果要实现自动的Failover,需要安装zookeeper,安装也很简单,从http://archive.cloudera.com/cdh5/cdh/5/下载zookeeper-3.4.5-cdh5.0.2.tar.gz,然后按照zookeeper的安装说明安装即可,官方推荐zookeeper的集群数目为奇数,推荐值为3,我这样也配置了3台,zookeeper服务在在启动时会向集群内其他服务器发送认证数据,但是在第一次启动时难免有个先后顺序,所以先启动的节点向还没有启动的服务器发生数据时会报错,类型下面的错误信息
2014-07-17 14:49:06,151 [myid:1] - INFO  [WorkerReceiver[myid=1]:FastLeaderElection@542] - Notification: 1 (n.leader), 0x100000106 (n.zxid), 0x1 (n.round), LOOKING (n.state), 1 (n.sid), 0x2 (n.peerEPoch), LOOKING (my state)2014-07-17 14:49:06,153 [myid:1] - WARN  [WorkerSender[myid=1]:QuorumCnxManager@368] - Cannot open channel to 2 at election address node1/10.4.13.63:3888java.net.ConnectException: Connection refused    at java.net.PlainSocketImpl.socketConnect(Native Method)    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)    at java.net.Socket.connect(Socket.java:579)    at org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:354)    at org.apache.zookeeper.server.quorum.QuorumCnxManager.toSend(QuorumCnxManager.java:327)    at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.process(FastLeaderElection.java:393)    at org.apache.zookeeper.server.quorum.FastLeaderElection$Messenger$WorkerSender.run(FastLeaderElection.java:365)    at java.lang.Thread.run(Thread.java:745)

这个是正常的,等3台全部启动后,有如下日志就证明没问题了

2014-07-17 11:26:44,425 [myid:3] - INFO  [WorkerReceiver[myid=3]:FastLeaderElection@542] - Notification: 3 (n.leader), 0x0 (n.zxid), 0x1 (n.round), LOOKING (n.state), 3 (n.sid), 0x0 (n.peerEPoch), LOOKING (my state)2014-07-17 11:26:44,426 [myid:3] - INFO  [WorkerReceiver[myid=3]:FastLeaderElection@542] - Notification: 2 (n.leader), 0x0 (n.zxid), 0x1 (n.round), LOOKING (n.state), 1 (n.sid), 0x0 (n.peerEPoch), LOOKING (my state)
  • 在配置Securing access to ZooKeeper这步时,我也能得到像官方教程上说的
digest:hdfs-zkfcs:vlUvLnd8MlacsE80rDuu6ONESbM=:rwcda

与这个类似的信息,但是在执行zkfc -formatZK时,老是说的我得到的字符串(’->’ 后面的那部分)不对,我也不知道为什么,不知道是不是哪步少了什么,因为zookeeper集群在内网,集群内安全性一般不用考虑,我这里就直接忽略了这步,以后机会再找原因。

  • 在配置Fencing Configuration时,我用了sshfence的方式,这里需要配置ssh的密钥,我直接把hdfs用户的密钥路径给上,后来在我验证双Namenode是否生效(通过kill掉active的NN,看看standby的NN能不能变为active的NN)发现不对,老是报错,连接不上另一个Namenode,后来发现需要用root的密钥,但是hdfs用户又不能读取root的密钥,所以我这里直接把root的.ssh文件下的文件全copy到hdfs用户的$HOME下,并设置为hdfs为其owner(我的root用户在集群内也是可以免密码登录的),这样就没问题了。

  • 需要说明的是,在开启namenode之前,必须先开启journalnode,因为namenode开启时会去连接journalnode

  • 然后就是开启双Namenode的步骤了,下面记录一些需要用到的命令

sudo -u hdfs bin/hdfs zkfc -formatZKsudo -u hdfs sbin/hadoop-daemon.sh start journalnode #开启journalnode进程sudo -u hdfs sbin/hadoop-daemon.sh start zkfc #开启automatic failover进程sudo -u hdfs bin/hdfs namenode -initializeSharedEdits #把一个non-HA的NameNode转为HA时用到sudo -u hdfs bin/hdfs namenode -bootstrapStandby sudo -u hdfs sbin/hadoop-daemon.sh start namenode#上面命这两个命令在运行第二个Namenode服务器上执行,必须先执行-bootstrapStandby 这行命令再开启namenode #下面这些命令之前,需要以hdfs用户用kinit拿到TGT,否则会报错sudo -u hdfs bin/hdfs haadmin -getServiceState nn1 #查看nn1是active的还是standby的
  • 按照jobtracker的HA官方配置进行配置后,使用
sudo -u mapred sbin/hadoop-daemon.sh start jobtrackerha

命令开启jobtrackerha

  • 通过
#运行下面这些命令之前,要先以mapred用户用kinit拿到TGT,否则会报错sudo -u mapred bin/hadoop mrhaadmin -getServiceState jt1

查看jt1是active的还是standby的

  • 最后一个,还是关于HDFS的权限问题,因为mapreduce在执行任务时会向HDFS上写一些临时文件,如果权限不对,肯定就会报错了,不过这种错误也很好该,根据错误信息就能知道那个目录权限不对,然后改过来就行了,我这里进行下总结:

  • 根据官方的教程配置教程,配置了如下选项:

<property>  <name>mapred.job.tracker.persist.jobstatus.dir</name>  <value>/jobtracker/jobsInfo</value></property>

所以需要在HDFS上创建相应目录,并修改其owner为mapred

  • 其次是staging目录,如果没有配置,其默认值从默认配置可以看到mapreduce.jobtracker.staging.root.dir的值为${hadoop.tmp.dir}/mapred/staging,而${hadoop.tmp.dir}的值从这里可以看到值默认是/tmp/hadoop-${user.name},有因为我们使用mapred用户来执行tasktracker进行的,所以需要创建/tmp/hadoop-mapred/mapred/staging文件夹,并且其owner为mapred,权限为1777,可以用下面的命令来实现:
sudo -u hdfs bin/hdfs dfs -mkdir -p /tmp/hadoop-mapred/mapred/stagingsudo -u hdfs bin/hdfs dfs -chown mapred /tmp/hadoop-mapred/mapred/stagingsudo -u hdfs bin/hdfs dfs -chmod 1777 /tmp/hadoop-mapred/mapred/staging

此外,还需要配置mapreduce.jobtracker.system.dir指定的文件,默认为${hadoop.tmp.dir}/mapred/system,所以还需要执行下面的命令:

sudo -u hdfs bin/hdfs dfs -mkdir -p /tmp/hadoop-mapred/mapred/systemsudo -u hdfs bin/hdfs dfs -chown mapred /tmp/hadoop-mapred/mapred/system

这个目录只由mapred用户来写入,所以不用再修改其权限(的755即可)。

总结:这次配置HA的整个过程还是比较顺利的,除了烦人的各种权限问题,我觉得这也是我没有弄明白hadoop各个进程是如何工作导致的,通过支持配置HA,算是对job的运行又有了更深的的认识。

继上次安装完Kerberos安全认证后,现在我在这基础上,又给CDH加上了HA(high availability),也就是高可靠性,具体来讲就是双NameNode,双Jobtracker(我还是在MRv1模式下),有了HA后,这下集群的健壮性就能够得到很好的保证了。

我还是按照官方文档来操作的,有了上次的经验,建议大家在具体操作实施前,先快速阅读一遍,做到心中有数,我还阅读了Apache官方的说明,也不用怎么详细,大概知道怎么回事就行了。

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn