Hadoop：使用QJM搭建HDFS高可用性(HA)集群及使用zookeeper自动故障转移

目录

高可靠性与高可用性

日志管理器QJM

搭建HA集群

ZooKeeper简介

自动故障转移

---

高可靠性与高可用性

高可靠性也可以称为高容错性，体现在一份数据以多份副本的形式存储在datanode中，并且通过自身持续的状态监控快速检测到冗余错误，并且能够快速、自动恢复失效的组件。

可以说高可靠性是保证了datanode上的数据可靠，而普通集群中只有一个namenode，如果唯一namenode失效了，此时任何与集群有关的操作都失效了，因为namenode是唯一存储元数据与块地址映射的地方。这样的话，必须要启动一个新的namenode，并且需要拥有原namenode的文件系统元数据。所以新的namenode需要将命令空间的镜像导入到内存中，重演编辑日志文件，接受足够多的的来自datanode的数据块报告并退出安全模式。而高可靠性解决了集群中的namenode存在的单点故障。

影响集群的可用性主要在于两方面：对于计划外事件（例如计算机崩溃），在操作员重新启动NameNode之前，群集将不可用；计划维护事件（如NameNode计算机上的软件或硬件升级）将导致群集停机。

高可用性是通过在同一集群中运行两个冗余namenode，实际上这是一对活动-备用namenode，当活动namenode失效时，备用namenode会接管它的任务并开始服务来自客户端的请求，期间没有明显的中断，允许机器在崩溃时快速故障转移，解决了集群中的namenode存在的单点故障。

日志管理器QJM

为了达到高可靠性：

• 两个namenode之间需要通过日志管理器(Quorum Journal Manager)实现编辑日志文件的共享；也就是说namenode需要将客户端操作写到QJM(共享编辑日志)上而不是${hadoop.tmp.dir}/dfs/name/current下。QJM以一组日志节点(journal node)的形式运行，活动namenode的每一次编辑需要写入大多数的日志节点，同时备用namenode也不断从日志节点中读取编辑操作，并且会应用到自己的命令空间中。并且在进行故障转移时，备用namenode会重演共享编辑日志(包括了由之前活动namenode写入的条目)，以实现与活动namenode的快速状态同步。
• 为了提供快速故障转移，由于块映射信息存储在namenode的内存中，所以datanode需要同时向两个namenode发送数据块处理报告和心跳
• 为了正确操作HA集群，日志节点一次只运行一个namenode(活动namenode)进行写入，否则会发生"脑裂情景"，命名空间状态将在两者之间发生分歧。
• 备用namenode会为活动namenode的命名空间设置周期性检查点，也就是说辅助namenode的角色被备用namenode包含，无需再HA集群中配置Secondary NameNode。

搭建HA集群

硬件要求

• 运行Active NameNode和Standby NameNode的计算机应具有彼此相同的硬件条件
• JournalNode守护程序相对轻量级，可以运行在从节点上，必须至少有3个JournalNode守护进程，且应该运行奇数个，当使用N JournalNodes运行时，系统最多可以容忍（N-1）/ 2个故障并继续正常运行。

配置文件

hdfs-site.xml

配置名称服务的昵称

	dfs.nameservices 
	mycluster

为名称服务配置相应的ID唯一标识符，每个名称服务最多只能配置两个NameNode

	dfs.ha.namenodes.mycluster
	nn1,nn2

为名称服务的唯一标识符配置独立完整的rpc地址

	dfs.namenode.rpc-address.mycluster.nn1
	master1:9000



	dfs.namenode.rpc-address.mycluster.nn2
	slave1:9000

为名称服务的唯一标识符配置独立完整的http地址

	  dfs.namenode.http-address.mycluster.nn1
	  master1:50070



	  dfs.namenode.http-address.mycluster.nn2
	  slave1:50070

指定journalnode守护进程所在的机器，及其指定目录；JournalNode的默认端口为8485

	dfs.namenode.shared.edits.dir
	qjournal://master1:8485;slave2:8485;slave3:8485/mycluster

配置client用于连接ActiveNamenode的java类型

   dfs.client.failover.proxy.provider.mycluster
   org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

配置防护方式sshfence，防止脑裂的产生，还必须配置无密码登陆

	dfs.ha.fencing.methods
	sshfence



	dfs.ha.fencing.ssh.private-key-files
	/home/jinge/.ssh/id_rsa

core-site.xml

配置默认的namenode的请求路径

	  fs.defaultFS
	  hdfs://mycluster

配置journalnode所产生的目录的具体路径

	dfs.journalnode.edits.dir
	/home/jinge/apps/hadoop/tmp

启动journalnode守护进程

在设置了所有必需的配置选项后，必须在将运行它们的一组计算机上启动JournalNode守护程序，通过以下命令

hadoop-daemon.sh start journalnode

同步元数据

元数据无非是镜像文件和编辑日志

同步镜像文件

1、如果是新搭建的集群，在其中一个namenode中运行格式化命令

hdfs namenode -format

2、如果您已经格式化了NameNode，则需要将已格式化namenode中的元数据目录(镜像文件)复制到另一个未格式化的namenode上，会在未格式化的机器上生成${hadoop.tmp.dir}/dfs/name，并存储最新的镜像文件

首先在已格式化的namenode上开启namenode服务

 hadoop-daemon.sh start namenode

再在未格式化的namenode上同步元数据

hdfs namenode -bootstrapStandby

同步编辑日志

共享编辑日志是存放在journalnode中的

1、首先关闭已格式化namenode中的namenode进程

hadoop-daemon.sh stop namenode

2、journalnode共享日志初始化，同步编辑日志，journalnode故障数需不能＞(n-1/2)，再任一日志节点中运行一下命令

hdfs namenode -initializeSharedEdits

开启HA集群

start-dfs.sh

服务开启顺序：namenode→datanode→journalnode

管理命令

hdfs haadmin
    [-transitionToActive [--forceactive] ]
    [-transitionToStandby ]
    [-failover [--forcefence] [--forceactive]  ]
    [-getServiceState ]
    [-checkHealth ]
    [-help ]

当进行故障转移时，需要手动通过hdfs haadmin -transitionToActive命令将备用namenode激活，而可以通过zookeeper达到自动故障转移。

ZooKeeper简介

zookeeper是hadoop的分布式协调服务。部分失败是分布式系统固有的特征，zookeeper提供了一组工具可在构建分布式应用时能够对部分失败进行正确处理。

zookeeper的特点：

• zookeeper的核心是一个精简的文件系统，提供一些简单的操作例如排序和通知。
• zookeeper的基本操作是一组丰富的构件，可用于实现多种数据结构和协议，例如分布式队列、分布式锁和一组节点中的领导者选举。
• zookeeper具有高可靠性，运行在一组机器上，可以帮助系统避免出现单点故障。
• zookeeper采用松耦合交互方式，在zookeeper支持的交互过程中，参与者不需要彼此了解。一个进程可以在zookeeper中留下一条消息，在该进程结束后，另外一个进程还可以读取这条消息。

不难发现QJM的工作方式与zookeeper相似，但QJM的实现并没有使用zookeeper。而HA集群在选取活动namenode时使用了zookeeper技术中的领导者选举。

自动故障转移

自动故障转移为HDFS部署添加了两个新组件：ZooKeeper仲裁和ZKFailoverController进程（ZKFC）

自动故障转移的实现依赖于ZooKeeper来实现以下功能：

• 故障检测：集群中的每个NameNode计算机都在ZooKeeper中维护一个持久会话。如果计算机崩溃，ZooKeeper会话将过期，通知另一个NameNode应该触发故障转移
• Active NameNode选举：ZooKeeper提供了一种简单的机制，可以将节点专门选为活动节点。如果当前活动的NameNode崩溃，则另一个节点可能在ZooKeeper中采用特殊的独占锁，指示它应该成为下一个活动的namenode

ZKFailoverController是一个ZooKeeper客户端，由它坚实和管理namenode的状态，运行NameNode的每台机器也运行ZKFC，ZKFC负责：

• 运行状况监视：ZKFC定期对其本地NameNode进行ping操作。只要NameNode及时响应健康状态，ZKFC就认为该节点是健康的。如果节点已崩溃，冻结或以其他方式进入不健康状态，则运行状况监视器会将其标记为运行状况不佳
• ZooKeeper会话管理：当本地NameNode运行正常时，ZKFC在ZooKeeper中保持会话打开。如果本地NameNode处于活动状态，它还拥有一个特殊的“锁定”znode。此锁使用ZooKeeper对“短暂”节点的支持; 如果会话过期，将自动删除锁定节点
• 基于ZooKeeper的选举：如果本地NameNode是健康的，并且ZKFC发现没有其他节点当前持有锁znode，它将自己尝试获取锁。如果成功，那么它“赢得了选举”，并负责运行故障转移以使其本地NameNode处于活动状态。故障转移过程类似于上述手动故障转移：首先，必要时对先前的活动进行隔离，然后本地NameNode转换为活动状态

部署

zookeeper的安装

下载zookeeper-3.4.6.tar.gz并上传至虚拟机中，解压并在~/.bash_profile中配置环境变量ZOOKEEPER_HOME及PATH=$ZOOKEEPER_HOME/bin:$PATH

独立模式

在$ZOOKEEPER_HOME/conf下复制一份模板zoo_sample.cfg命名为zoo.cfg，内容如下

tickTime=2000
initLimit=10
syncLimit=5
#dataDir=/tmp/zookeeper  zookeeper持久化数据的存储位置，可更改在$ZOOKEEPER_HOME下
dataDir=/home/jinge/apps/zookeeper/tmp/zookeeper
clientPort=2181

在本地上开启server

zkServer.sh start

此时通过jps可发现多了一个名为QuorumPeerMain的进程

使用客户端连接服务

zkCli.sh [-server] [host]  ->  zkCli.sh -server 127.0.0.1:2181

此时多了一个名为ZooKeeperMain的进程，可通过help查看相关zk命令

集群模式

修改zoo.cfg配置文件内容

tickTime=2000
dataDir=/home/jinge/apps/zookeeper/tmp/zookeeper
clientPort=2181
initLimit=5
syncLimit=2

#zookeeper仲裁进程QuorumPeerMain运行在3台机器上
server.1=master1:2888:3888
server.2=slave2:2888:3888
server.3=slave3:2888:2888

通过scp将zookeeper复制到相应节点

scp ~/apps/zookeeper-3.4.6 jinge@slave2:~/apps/
scp ~/apps/zookeeper-3.4.6 jinge@slave3:~/apps/

在server.n对应的机器上的dataDir指定的目录下添加mymid文件，内容为n

在通过zkServer.sh start启动，此时可以通过zkCli.sh [-server] [host]访问到3个server中任一客户端，并且内容是一致的

配置HA自动故障转移

修改hdfs-site.xml，支持自动故障转移

        dfs.ha.automatic-failover.enabled
	true

修改core-site.xml，配置zookeeper服务器，与zoo.cfg指定的一致

	ha.zookeeper.quorum
	master1:2181,slave2:2181,slave3:2181

在任一namenode上进行格式化zookeeper，这将在ZooKeeper中创建一个znode，其中自动故障转移系统存储其数据

hdfs zkfc -formatZK

开启HA集群

首先开启zkServer，再通过 start-dfs.sh 开启HA集群，启动顺序：namenode→datanode→journalnode→zkfc

手动开启zkfc：

hadoop-daemon.sh start zkfc

zkfc的进程名为DFSZKFailoverController，会运行在2个namenode中

 

此时会在zk中多了一个hadoop-ha结点，并且有一个名为mycluster（名称服务的唯一标识符）的子结点，mycluster下：

[zk: master1(CONNECTED) 4] ls /hadoop-ha/mycluster
[ActiveBreadCrumb, ActiveStandbyElectorLock]