HDFS HA 部署安装

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 架构如下 所示:

2.2 硬件选择及软件准备

(1) 硬件选择

 NameNode 机器:推荐主备 NameNode 具有相同的硬件配置,且内存要足够大。

 JournalNode:通常准备 3 或 5 个 JournalNode,考虑到 JournalNode 非常轻量级,可以与 Hadoop 其他服务共用机器,比如 ResourceManager,TaskTracker 等。

 Zookeeper:由于 Hadoop 多个服务用到了 Zookeeper,可搭建一个 3 或者 5 个节点的Zookeeper 实例作为公共服务。Zookeeper 实例也可以与其他服务共用机器。

(2) 软件准备

  Apache Hadoop 2.2.0 或者更高版本,或 cdh4 以及更高版本

 

  JDK 1.6 或者更高版本,注意,cdh5 需要 jdk 7

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,可以通过该 参数指定多个逻辑名称,并用“,”分割。


 dfs.nameservices 
nn
Logical name for this new nameservice 

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

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


dfs.ha.namenodes.nn 
nn1,nn2
Unique identifiers for each NameNode in the nameservice 

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

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

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

 
dfs.namenode.rpc-address.nn.nn1
 nn1:9000

 
dfs.namenode.rpc-address.nn.nn2
nn2:9000 

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

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

 
dfs.namenode.http-address.nn.nn1 
192.168.10.110:50070


dfs.namenode.http-address.nn.nn2
192.168.10.111:50070


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

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

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

其中,journalId 是该命名空间的唯一 ID。假设你有三台 journalNode,即 dn1, dn2 和 dn3,则可进行如下配置:


dfs.namenode.shared.edits.dir
qjournal://dn1:8485;dn2:8485; dn3:8485;dn4:8485;dn6:8485/nn

注意,JournalNode 默认端口号为 8485

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

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

dfs.client.failover.proxy.provider.nn
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。

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


dfs.ha.fencing.methods
sshfence


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

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


dfs.ha.fencing.methods
sshfence([[username][:port]])


dfs.ha.fencing.ssh.connect-timeout
30000

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

dfs.ha.fencing.methods

shell(/path/to/my/script.sh arg1 arg2 ...)  (这里没搞懂)

注意,Hadoop 中所有参数将以环境变量的形似提供给该 shell,但所有的“.”被替换成了“_”, 比如“dfs.namenode.rpc-address.ns1.nn1”变为“dfs_namenode_rpc-address”

(8) fs.defaultFS

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


fs.defaultFS
hdfs://nn


(9) dfs.journalnode.edits.dir

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

dfs.journalnode.edits.dir
/opt/journal/node/local/data

2.4 启动服务

假设 nn1 和 nn2 两个节点是主备 NameNode,则 HDFS 集群启动顺序如下:
(1) 启动所有 JournalNode
(2) 启动 nn1 和 nn2
(3) 启动所有 DataNode

步骤 1:启动所有 JournalNode
在所有 JournalNode 节点上,进入 Hadoop 安装目录下,运行以下命令启动

sbin/hadoop-daemon.sh start journalnode

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

hdfs namenode -initializeSharedEdits [-force | -nonInteractive]

该命令将格式化各个 JournalNode,默认情况下是交互式执行的,要求用户输入“Y/N”进行确 认,可以使用参数-force 或者 –nonInteractive 跳过交互式过程,直接强制格式化。

步骤 3:启动 nn1 和 nn2

(1) 启动nn1

ps:新的hdfs集群记得 hdfs  namenode  -format 格式化

sbin/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  

就会把NameNode的状态进行安全的切换。其中后面一个会变为active状态。这时候再通过web页面观察就能看到正确结果了。

hdfs haadmin -failover --forcefence --forceactive nn1 nn2

执行命令“hdfs  haadmin”，会显示子命令列表，如下



Usage: DFSHAAdmin [-ns ]

    [-transitionToActive ]

    [-transitionToStandby ]

    [-failover [--forcefence] [--forceactive]  ]

    [-getServiceState ]

    [-checkHealth ]

    [-help ]																														        通过help可以看到，也可以用hdfs  haadmin  -transitionToActive  nn1 进行切换namenode到active状态																						

(2) 自动切换
当 active namenode 发生故障时,人工切换模式不能自动完成主备切换,因此推荐使用自动切换,这是基于 zookeeper 实现的,具体配置可参考下一节2.5。

2.5 配置自动切换模式

HDFS NameNode 自动切换由以下两个组件构成:
 Zookeeper 实例(3 个或 5 个或 7 个节点)
 ZKFailoverController(简称“ZKFC”)
ZKFC 是一个 Zookeeper 客户端,负责监控和管理 NameNode 的状态,每台运行 NameNode 的机器上也会运行一个 ZKFC 进程。
 健康状况监控:ZKFC周期性地与本地的NameNode交互,执行一些健康状况监测命令。  Zookeepersession管理:如果本地NameNode是健康的,则会持有Zookeeper上一个znode, 如果它是 active 的,会持有 zookeeper 的仅有的一个特殊 znode,该 znode 类型为 ephemeral,一旦 namenode 挂掉后,会自动消失。
 基于zookeeper的选举:如果本地NameNode是活的,而没有其他namenode持有特殊的znode,
ZKFC 将尝试获取这个 znode,一旦获取成功后,则认为它“赢得了选举”,进而隔离之前的 active namenode,自己转换为新的 active namenode。

具体步骤如下: 注:以下操作在集群关闭情况下进行

 步骤 1:修改配置文件

(1) 开启自动切换模式
在 hdfs-site.xml 增加以下配置:
(2) 配置 zookeeper 实例地址
在 core-site.xml 中,增加以下配置:


 dfs.ha.automatic-failover.enabled 

true



ha.zookeeper.quorum
dn1:2181,dn2:2181, dn3:2181, dn4:2181,dn6: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。

原文地址:http://pan.baidu.com/share/link?shareid=3918641874&uk=2248644272