[关闭]
@songlaf 2016-05-29T04:20:09.000000Z 字数 7813 阅读 888

HDFS HA 和 Federation 安装

Hadoop


HDFS HA 和 Federation 安装

1.HDFS 2.0 基本概念

相比于 Hadoop 1.0,Hadoop 2.0 中的 HDFS 增加了两个重大特性,HA 和 Federaion。HA 即为 High Availability,用于解决 NameNode 单点故障问题,该特性通过热备的方式为主 NameNode 提供一个备用者,一旦主 NameNode 出现故障,可以迅速切换至备 NameNode,从而实现不间断对外提供服务。Federation 即为“联邦”,该特性允许一个 HDFS 集群中存在多个 NameNode 同时对外提供服务,这些 NameNode 分管一部分目录(水平切分),彼此之间相互隔离,但共享底层的 DataNode 存储资源。本文档重点介绍 HDFS HA 和 Federation 的安装部署方法。 

2.HDFS HA 配置部署

2.1 HDFS HA 架构

       在一个典型的 HDFS HA 场景中,通常由两个 NameNode 组成,一个处于 active 状态,另一个处于 standby 状态。Active NameNode对外提供服务,比如处理来自客户端的 RPC 请求,而 Standby NameNode 则不对外提供服务,仅同步 active namenode的状态,以便能够在它失败时快速进行切换。
       为了能够实时同步 Active 和 Standby 两个 NameNode 的元数据信息(实际上 editlog),
需提供一个共享存储系统,可以是 NFS、QJM(Quorum Journal Manager)或者 Bookeeper, Active Namenode 将数据写入共享存储系统,而 Standby 监听该系统,一旦发现有新数据写入,则读取这些数据,并加载到自己内存中,以保证自己内存状态与 Active NameNode 保持基本一致,如此这般,在紧急情况下 standby 便可快速切为 active namenode。
       注意,在 Hadoop 2.0 中,不再需要 secondary namenode 或者 backup namenode,它们的工作由 Standby namenode 承担。
       本文将重点介绍基于 QJM 的 HA 解决方案。在该方案中,主备 NameNode 之间通过一组 JournalNode 同步元数据信息,一条数据只要成功写入多数 JournalNode 即认为写入成功。通常配置奇数个(2N+1)个 JournalNode,这样,只要 N+1 个写入成功就认为数据写入成功,此时最多容忍 N-1 个 JournalNode 挂掉,比如 3 个 JournalNode 时,最多允许 1 个 JournalNode 挂掉,5 个 JournalNode 时,最多允许 2 个 JournalNode 挂掉。
       基于 QJM 的 HDFS 架构如下所示:
                     1111.jpg-23.1kB

2.2 硬件选择及软件准备

(1)硬件选择

(2)软件准备

2.3 修改配置文件

       HDFS相关的配置文件是${HADOOP_HOME}/etc/hadoop/下的hdfs-site.xml,为了便于管理,通常让 HDFS 上各个节点上的 hdfs-site.xml 一致。
配置 HDFS HA,需对一下参数设置:

(1)dfs.nameservices

       HDFS 命名服务的逻辑名称,可用户自己定义,比如 mycluster,注意,该名称将被基于 HDFS 的系统使用,比如 Hbase 等,此外,需要你想启用 HDFS Federation,可以通过该参数指定多个逻辑名称,并用“,”分割。

  1. <property>
  2. <name>dfs.nameservices</name>
  3. <value>mycluster</value>
  4. <description>Logical name for this new nameservice</description>
  5. </property>

(2)dfs.ha.namenodes.[$nameservice ID]:

       某个命名服务下包含的 NameNode 列表,可为每个 NameNode 指定一个自定义的 ID 名
称,比如命名服务 mycluster 下有两个 NameNode,分别命名为 nn1 和 nn2,则配置如下:

  1. <property>
  2. <name>dfs.ha.namenodes.mycluster</name>
  3. <value>nn1,nn2</value>
  4. <description>Unique identifiers for each NameNode in the nameservice
  5. </description>
  6. </property>

注意,目前每个命名服务最多配置两个 NameNode

(3) dfs.namenode.rpc-address.[$nameservice ID].[$name node ID]

为每个 NameNode 设置 RPC 地址,以前面的实例为例,可进行如下配置:

  1. <property>
  2. <name>dfs.namenode.rpc-address.mycluster.nn1</name>
  3. <value>machine1.example.com:8020</value>
  4. </property>
  5. <property>
  6. <name>dfs.namenode.rpc-address.mycluster.nn2</name>
  7. <value>machine2.example.com:8020</value>
  8. </property>

(4)dfs.namenode.http-address.[$nameservice ID].[$name node ID]

为每个 NameNode 设置对外的 HTTP 地址,以前面的实例为例,可进行如下配置:

  1. <property>
  2. <name>dfs.namenode.http-address.mycluster.nn1</name>
  3. <value>machine1.example.com:50070</value>
  4. </property>
  5. <property>
  6. <name>dfs.namenode.http-address.mycluster.nn2</name>
  7. <value>machine2.example.com:50070</value>
  8. </property>

(5)dfs.namenode.shared.edits.dir

       设置一组 journalNode 的 URI 地址,active NameNode 将 edit log 写入这些
JournalNode,而 standby NameNode 读取这些 edit log,并作用在内存中的目录树中,该属性
值应符合以下格式:

  1. qjournal://host1:port1;host2:port2;host3:port3/journalId

       其中,journalId 是该命名空间的唯一 ID。假设你有三台 journalNode,即
node1.example.com, node2.example.com 和 node3.example.com,
则可进行如下配置:

  1. <property>
  2. <name>dfs.namenode.shared.edits.dir</name>
  3. <value>qjournal://node1.example.com:8485;node2.example.com:8485; node3.example.com:8485/mycluster</value>
  4. </property>

注意,JournalNode 默认端口号为 8485

(6) dfs.client.failover.proxy.provider.[$nameservice ID]

       设置客户端与 active NameNode 进行交互的 Java 实现类,DFS 客户端通过该类寻找当前的 active NameNode。该类可由用户自己实现,默认实现为 ConfiguredFailoverProxyProvider。

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

(7)dfs.ha.fencing.methods

       主备架构解决单点故障问题时,必须要认真解决的是脑裂问题,即出现两个 master 同
时对外提供服务,导致系统处于不一致状态,可能导致数据丢失等潜在问题。在 HDFS HA
中,JournalNode 只允许一个 NameNode 写数据,不会出现两个 active NameNode 的问题,但是,当主备切换时,之前的 active NameNode 可能仍在处理客户端的 RPC 请求,为此,需要增加隔离机制(fencing)将之前的 active NameNode 杀死。
HDFS 允许用户配置多个隔离机制,当发生主备切换时,将顺次执行这些隔离机制,直到一个返回成功。Hadoop 2.0 内部打包了两种类型的隔离机制,分别是 shell 和 sshfence。

7.1) sshfence

       sshfence通过ssh登录到前一个active NameNode并将其杀死。为了让该机制成功执行,
需配置免密码 ssh 登陆,这可通过参数 dfs.ha.fencing.ssh.private-key-files 设置一个私钥文件。

  1. <property>
  2. <name>dfs.ha.fencing.methods</name>
  3. <value>sshfence</value>
  4. </property>
  5. <property>
  6. <name>dfs.ha.fencing.ssh.private-key-files</name>
  7. <value>/home/exampleuser/.ssh/id_rsa</value>
  8. </property>

你可以配置一个 ssh 用户和端口号,并设置一个超时时间,一旦 ssh超过该时间,则认为执行失败。

  1. <property>
  2. <name>dfs.ha.fencing.methods</name>
  3. <value>sshfence([[username][:port]])</value>
  4. </property>
  5. <property>
  6. <name>dfs.ha.fencing.ssh.connect-timeout</name>
  7. <value>30000</value>
  8. </property>
7.2) shell

执行任意一个 shell 命令隔离旧的 active NameNode,配置方法如下:

  1. <property>
  2. <name>dfs.ha.fencing.methods</name>
  3. <value>shell(/path/to/my/script.sh arg1 arg2 ...)</value>
  4. </property>
  5. /*注意,Hadoop 中所有参数将以环境变量的形似提供给该 shell,但所有的“.”被替换成了“_”,
  6. 比如“dfs.namenode.rpc-address.ns1.nn1”变为“dfs_namenode_rpc-address”
  7. */

(8) fs.defaultFS

       设置缺省的目录前缀,需在 core-site.xml 中设置,比如命名服务的 ID 为 mycluster(参数dfs.nameservices 指定的),则配置如下:

  1. <property>
  2. <name>fs.defaultFS</name>
  3. <value>hdfs://mycluster</value>
  4. </property>

(9) dfs.journalnode.edits.dir

JournalNode 所在节点上的一个目录,用于存放 editlog和其他状态信息。该参数只能设置一个目录,你可以对磁盘做 RIAD 提高数据可靠性。

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

2.4启动服务

假设 NN1 和 NN2 两个节点是主备 NameNode,则 HDFS 集群启动顺序如下:
(1) 启动所有 JournalNode
(2) 启动 NN1 和 NN2
(3) 启动所有 DataNode
步骤 1:启动所有 JournalNode 在所有 JournalNode 节点上,进入 Hadoop 安装目录下,运行以下命令启动

  1. JournalNode sbin/hdfs-daemon.sh start journalnode

步骤 2:初始化 JournalNode 在 NN1 上,执行以下命令:

  1. hdfs namenode -initializeSharedEdits [-force | -nonInteractive]

该命令将格式化各个 JournalNode,默认情况下是交互式执行的,要求用户输入“Y/N”进行确认,可以使用参数-force 或者 –nonInteractive 跳过交互式过程,直接强制格式化。
步骤 3:启动 NN1 和 NN2
(1) 启动 NN1
bin/hadoop namenode –format
启动 NN1:
hadoop-daemon.sh start namenode
(2)启动 NN2 让 NN2 从 NN1 上拉取最新的 FSimage:
bin/hdfs namenode -bootstrapStandby [-force | -nonInteractive]
启动 NN2:
sbin/hadoop-daemon.sh start namenode
步骤 4:启动所有 DataNode 在各个 DataNode 节点上执行以下命令:
sbin/hadoop-daemon.sh start datanode
或者,直接在 NN1 上执行一条命令:
sbin/hadoop-daemons.sh start datanode
在 Web 界面上查看是否启动成功,如果界面显示如下(standby namenode 的界面),则启动成功:

步骤 5:将 NN1 状态切换为 Active
(1) 人工切换
NN1 和 NN2 启动后,都处于 Standby 状态,此时均不能对外提供服务,在 NN1 节点上输入以下命令将它切换为 active:
hdfs haadmin -failover --forcefence --forceactive
其中,serviceId 为“dfs.nameservices”配置的命名服务,namenodeId 为 namenode ID,在此,
可以是 NN1
hdfs haadmin -failover --forcefence --forceactive mycluster NN1
(2) 自动切换当 active namenode 发生故障时,人工切换模式不能自动完成主备切换,因此推荐使用
自动切换,这是基于 zookeeper 实现的,具体配置可参考下一节。
2.5 配置自动切换模式
HDFS NameNode 自动切换由以下两个组件构成:
 Zookeeper 实例(3 个或 5 个或 7 个节点)
 ZKFailoverController(简称“ZKFC”)
ZKFC 是一个 Zookeeper 客户端,负责监控和管理 NameNode 的状态,每台运行 NameNode 的机器上也会运行一个 ZKFC 进程。
 健康状况监控:ZKFC周期性地与本地的NameNode交互,执行一些健康状况监测命令。
 Zookeeper session管理:如果本地NameNode是健康的,则会持有Zookeeper上一个znode,如果它是active的,会持有zookeeper的仅有的一个特殊znode,该znode类型为ephemeral,
一旦 namenode 挂掉后,会自动消失。
 基于 zookeeper 的选举:如果本地 NameNode 是活的,而没有其他 namenode 持有特殊的 znode, ZKFC 将尝试获取这个 znode,一旦获取成功后,则认为它“赢得了选举”,进而隔离之前的 active namenode,自己转换为新的 active namenode。

具体步骤如下:注:以下操作在集群关闭情况下进行步骤 1:修改配置文件
(1) 开启自动切换模式
在 hdfs-site.xml 增加以下配置:

dfs.ha.automatic-failover.enabled
true

(2) 配置 zookeeper 实例地址在 core-site.xml 中,增加以下配置:

ha.zookeeper.quorum
zk1.example.com:2181,zk2.example.com:2181, zk3.example.com:2181
步骤 2:初始化 zookeeper
bin/hdfs zkfc -formatZK
步骤 3:启动 JournalNode、NameNode 和 DataNode 步骤 4:启动 ZKFC
在各个 NameNode 上,依次输入以下命令启动 ZKFC:
sbin/hadoop-daemon.sh start zkfc
第一个启动的 NN 将成为 active NameNode
步骤 5:验证自动切换功能是否生效可人工将 active namenode 进程杀死,看是够自动切换到另一个 namenode。
- HDFS Federation 配置部署
为了启用 federation,我们需再增加 N 个 namenode,并为每个 namenode 添加一个 standby
namenode,以解决每个 namenode 的单点故障问题。本文介绍 N=1 的情况,其他情况类似。再增加一个 namenode 和 standby namenode 后,部署架构如下:

该结构的配置方法可参考“Hadoop 2.0 NameNode HA 和 Federation 实践”一文。
当启用 HDFS Federation 功能时,由于存在多个 namenode 视图,可能会给用户使用带来不便,为此,可通过配置 client-side mount table 为用户提供一个统一 HDFS 访问视图,具体如下:

同样,配置方法可参考“Hadoop 2.0 NameNode HA 和 Federation 实践”一文。
- HDFS 1.0 升级到 2.0
参考:http://dongxicheng.org/mapreduce-nextgen/hadoop-upgrade-to-version-2/

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注