使用QJM实现HDFS的HA配置

使用QJM实现HDFS的HA配置

1、背景

hadoop 2.0.0之前，namenode存在单点故障问题（SPOF，single point of failure），如果主机或进程不可用时，整个集群就变得不可用，直到namenode进行重启或产生新的namenode。主要有两种方式会影响到HDFS集群：

• 不可预期事件比如机器宕机，集群变得不可用直到操作人员重启namenode。
• 可预期事件比如软硬件升级也会导致集群的下线。

HDFS的高可用特性解决了以上两个问题，通过在一个集群中运行两个冗余的Namenode，分别以active/passiave配置方式实现一个热备处理。这允许namenode宕机后能够快速容灾到新节点，或者管理员以优雅的方式进行计划性运维容灾处理。

2、架构

在电信的HA集群中，配置两台独立的主机为namenode。任何时刻，只有一台主机处于active状态，另一台为standby状态。active节点负责集群中所有客户端的操作，standby节点只是扮演一个从属的角色，他会维护足够多的状态信息进行必要条件下的快速容灾处理。

为了让standby节点同active节点保持状态同步，两个节点都需要同一组称之为“JournalNode”的进程通信。当active节点对名字空间进行了修改后，都会记录这条修改记录到JN节点的半数以上节点。Standby节点即可从JN节点上读取这些编辑日志，Standby节点不断观察编辑日志的修改行为，如果有修改动作发生，便会立刻应用到自己的名字空间中。容灾发生时，standby节点在切换到active状态前要确保从JN上读取了所有的修改动作。这可以保证在容灾发生前，名字空间的状态是完全同步的。

为了提供快速容灾，让Standby节点拥有最新的block位置信息也是非常有必要的。为了做到这一点，需要使用两个namenode位置对Datanode进行配置，并且datanode会同时发送block信息和心跳信息给两个namenode。

正确操作HA集群的一个重点事项就是同一时刻只有一个namenode处于active状态，否则，名字空间状态很快在两者之间产生偏差，从而导致数据丢失或不一致的风险。为了确保这一属性并防止所谓的“脑裂场景”，JournalNode节点只允许同一时刻一个namenode进行写入。容灾期间，成为active的namenode只是接管journalNode的写操作，有效防止其他的namenode节点，允许新的active节点安全处理容灾工作。

3、硬件资源

为了部署HA集群，需要做如下准备：

• namenode主机

  运行active和standby的namenode主机，他们具有相同的硬件配置，这种相同的硬件配置也会用在非HA集群下。

• Journalnode主机

  运行journalnode节点的主机。journalnode进程是轻量级进程，因此可以和他其他hadoop守护进程并存，例如namenode、resourcemanager等。注意：必须至少配置3个Journalnode守护进程，因为编辑日志必须要写入JN的半数以上。这允许系统容忍一台journalnode节点挂掉。为增加系统的容灾能力，应该运行奇数个journalnode节点，例如3,5,7台。当运行n个journalnode节点时，最多容忍（n - 1）/ 2节点故障。

注意，在HA集群模式下，standby节点也会对名字空间状态进行检查点操作，因此没有必要运行secondary namenode，checkpointnode或BackupNode。实际上，这样做会导致错误，这也运行通过改造非HA模式下的secondaryNode成为HA模式。

4、部署

4.1 配置概览

HA配置是向后兼容的，允许现有的namenode配置不做修改就可以工作。集群中所有节点具有相同的配置，而不需要个不同主机依据节点类型进行不同的配置。

HA集群使用nameservice id区分一个HDFS实例，他可以包含多个HA的namenode节点。集群中的Namenode使用唯一的namenode ID进行区分。为了对所有节点使用一个配置文件，配置可以使用nameservice ID和namenode ID作为后缀。

4.2 配置细节

配置HA Namenode，需要添加几个选项给hdfs-site.xml配置文件。

这些选项的顺序并不重要，但是dfs.nameservices 和dfs.ha.namenodes.[nameservice ID]值很关键，因此配置前需要确定这些值的内容。

• dfs.nameservices

  名称服务的逻辑名，该名称是任意的，将会用于配置和HDFS路径的授权。

  <property>
  	<name>dfs.nameservices</name>
  	<value>mycluster</value>
  </property>
  

• dfs.ha.namenodes.[nameservice ID]

  名称服务中每个namenode的唯一标识。使用“,”号分割的名称列表，datanode通过他来检测集群中的所有namenode。

  <property>
  	<name>dfs.ha.namenodes.mycluster</name>
  	<value>nn1,nn2</value>
  </property>
  
  

  注意：目前最多只支持两个名称节点。

• dfs.namenode.rpc-address.[nameservice ID].[name node ID]

  配置每个名称节点的IPC端口，需要在单独的元素进行配置。

  <property>
  	<name>dfs.namenode.rpc-address.mycluster.nn1</name>
  	<value>s101:8020</value>
  </property>
  <property>
  	<name>dfs.namenode.rpc-address.mycluster.nn2</name>
  	<value>s102:8020</value>
  </property>
  

  ​

• dfs.namenode.http-address.[nameservice ID].[name node ID]

  配置每个namenode的http监听地址。

  <property>
  	<name>dfs.namenode.http-address.mycluster.nn1</name>
  	<value>s101:50070</value>
  </property>
  <property>
  	<name>dfs.namenode.http-address.mycluster.nn2</name>
  	<value>s102:50070</value>
  </property>
  

  ​

• dfs.namenode.shared.edits.dir

  namenode从JNs集合上读写日志的uri地址。

  <property>
  	<name>dfs.namenode.shared.edits.dir</name>
  	<value>qjournal://s102:8485;s103:8485;s104:8485/mycluster</value>
  </property>
  

  ​

• dfs.client.failover.proxy.provider.[nameservice ID]

  容灾代理提供商类，用来检测哪个namenode是active状态，哪个namenode用来服务于客户端请求。当前hadoop只有一个实现。

  <property>
  	<name>dfs.client.failover.proxy.provider.mycluster</name>
  	<value>org.apache.hadoop.hdfs.server.namenode.ha
        .ConfiguredFailoverProxyProvider</value>
  </property>
  

  ​

• dfs.ha.fencing.methods

  容灾期间防护namenode的java类或者脚本列表。使用QJM（Quorum journal manager）时只允许一个namenode向journalnodes写入数据，因此不存在因为脑裂损坏系统元数据的可能。但是，容灾发生时，依然有可能的是上一个active节点向客户端提供读请求服务，直到向JN节点写入数据失败造成namenode停止后导致的时间过期。基于这一原因，使用QJM时仍有必要配置一些防护方法。为提升系统在防护事件失败时的可用性，建议配置防护方法确保列表中最后一个防护方法返回成功。注意如果选择使用并无实际的防护方法，也要进行一些配置，比如“shell(bin/true)”等。

  防护方法可以配置成列表，然后按序调用直到防护方法成功为止。hadoop给出了两种方式：shell和sshfence。自定义防护方法可以实现org.apache.hadoop.ha.NodeFencer类。

  ​

  防护方法配置成多行列表的形式，容灾时按顺序进行调用直到防护方法返回成功为止。hadoop有两种方式：shell和sshfence。自定义的话可以实现org.apache.hadoop.ha.NodeFencer类。

  ​

  sshfence方式是ssh到active的namenode节点并将进程杀死，该中方式必须能够无密登录到目标节点，因此必须要配置私钥（dfs.ha.fencing.ssh.private-key-files ）选项，可以配置成逗号分隔的多个私钥列表，配置方式如下：

  <property>
  	<name>dfs.ha.fencing.methods</name>
  	<value>sshfence</value>
  </property>
  
  <property>
  	<name>dfs.ha.fencing.ssh.private-key-files</name>
  	<value>/home/centos/.ssh/id_rsa</value>
  </property>
  

  shell方式是运行一个shell脚本来防护active namenode。配置方式如下：

  <property>
  	<name>dfs.ha.fencing.methods</name>
  	<value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
  </property>
  

  ​

• fs.defaultFS

  hadoop文件系统客户端没有指定前缀时使用的默认路径前缀。

  <property>
  	<name>fs.defaultFS</name>
  	<value>hdfs://mycluster</value>
  </property>
  

  ​

• dfs.journalnode.edits.dir

  Journanode守护进程存放本地状态的路径，该路径使用绝对路径，使用一个路径即可。

  <property>
  	<name>dfs.journalnode.edits.dir</name>
  	<value>/path/to/journal/node/local/data</value>
  </property>
  

4.3 部署细节

配置完成后，必须在JN节点启动所有的JN守护进程，可使用如下命令完成：

hadoop-daemon.sh start journalnode

一旦JN进程启动完成，必须要对两个HA的namenode节点的磁盘元数据进行初始同步

• 如果搭建的是全新的hdfs集群，应该在其中的一个namenode上运行如下命令进行格式化

  hdfs namenode -format
  

• 如果已经格式化过namenode或者转换非HA模式到HA模式下，需要复制namenode的元数据目录到另一个namenode相同目录下，未格式化的namenode节点运行如下命令,完成待命状态引导。该命令还会保证jn节点包含足够多了编辑动作，以便能够启动两个namenode节点。

  hdfs namenode -bootstrapStandby
  

• 如果正在将非HA模式转换成HA，你应该运行如下命令，将会从本地namenode的编辑日志初始化JN节点的编辑数据。

  hdfs namenode -initializeSharedEdits
  

此时可以像以往启动namenode一样启动两个namenode。同时，可以分别使用两个namenode各自的webui地址查看各自的状态。你会发现两台namenode的状态都是standby。

http://s101:50070
http://s105:50070

4.4 管理命令

配置并启动namenode后，就可以进行管理工作，可以使用如下管理命令对namenode进行管理：

Usage: haadmin
    [-transitionToActive <serviceId>]
    [-transitionToStandby <serviceId>]
    [-failover [--forcefence] [--forceactive] <serviceId> <serviceId>]
    [-getServiceState <serviceId>]
    [-checkHealth <serviceId>]
    [-help <command>]

• transitionToActive和transitionToStandby

  切换状态到active或standby状态，这些命令不会进行防护处理，尽量少使用，而是用使用failover代替。

• failover

  在两个namenode间进行容灾演练，从第一个nn到第二个nn进行容灾处理，如果第一个nn是standby，就将第二个nn变换成active态。如果第一个是active，首先尝试优雅变换到standby状态。如果这一个过程失败，就按序执行防护方法直到成功，此过程过后，第二个nn才会变成active态。如果防护方法都没有成功，则第二个nn就不会变成active态并返回一个错误。

• getServiceState

  检测指定的nn的状态，连接到namenode检测其状态，打印active或standby字样。

• checkHealty

  检查给定namenode的健康状况，namenode本省能够执行一个诊断工作，包括检查是否内部服务在进行，如果健康返回0，否则返回非0。

  注意该命令还未实现，始终返回0，除非namenode完全停止。

5、自动容灾

5.1 介绍

以上部分描述了如何配置手动容灾，在该模式下，系统无法自动触发容灾处理，哪怕是active挂掉。本章描述如何配置自动容灾。

5.2 组件

自动容灾引入两个新组件：一个是Zookeeper的quorum，一个是ZKFailoverController进程（简称zkfc）。

apache zookeeper是高可用服务用于维护少量协同数据，通知客户端数据变更、监控客户端故障。自动容灾依赖zookeeper一下内容：

• 故障检测

  集群中每个namenode主机都在zookeeper中维护了永久session。如果机器宕机，session就会超时，通知其他namenode触发容灾。

• active namenode选举

  zookeeper提供一种简单机制能够以独占方式选举一个node为active。如果当前active节点宕机，另一个namenode就会接管一个排他锁表明自己将成为下一个active。

zkfc是zookeeper客户端管理监控namenode状态的新组件。每个运行namenode主机都会运行一个zkfc进程。zkfc进程负责如下工作：

• 监控检查

  zkfc周期性ping本地namenode的状态，如果namenode能够及时响应，则认为namenode是健康的。如果node宕机或进入某种不监控状态，监控器就标记其位不健康状态。

• zk session管理

  如果本地namenode是健康的，zkfc会持有zk的session。如果namenode是健康的，zkfc还会持有一把临时锁。若session过期，lock节点将会被删除。

• 基于zk的选举

  如果namenode是健康的，zkfc就会知道不会有其他人持有lock节点，自己就会尝试上锁。如若成功就赢得选举，并运行容灾程序，本地namenode就成为active状态。

5.3 部署zookeeper

典型配置zookeeper模式是使用3或5个节点，由于zookeeper是轻量级的，因此可以和其他进程位于同一主机，例如namenode或datanode。许多人选择部署第三节点在ResourceManager主机上。建议配置zookeeper在单独的磁盘驱动器上存储数据，同hdfs元数据分开，以获得更好的性能和隔离处理。搭建zookeeper集群请参考相关文章，这里不做介绍。

5.4 开始前准备工作

停止hdfs集群。

5.5 配置自动容灾

在hdfs-site.xml文件中添加如下配置启用自动容灾。

 <property>
	<name>dfs.ha.automatic-failover.enabled</name>
 	<value>true</value>
 </property>

在core-site.xml文件中添加zk节点地址。

<property>
	<name>ha.zookeeper.quorum</name>
	<value>s102:2181,s103:2181,s104:2181</value>
 </property>

5.6 在zk中初始化HA状态

在其中的一个namenode节点上运行如下命令：

hdfs zkfc -formatZK

该命令会在zk中创建相应节点存储用于容灾的数据。

5.7 使用start-dfs.sh启动集群

由于已经启用了自动容灾，因此启动namenode时，会自动启动zkfc进程，并自动选举一个namenode为active节点。

5.8 手动启动zkfc进程

也可以手动启动zkfc进程，运行如下命令：

hadoop-daemon.sh start zkfc