CNDBA社区
1 HDFS 架构背景说明
HDFS 采用主从(Master/Slave)架构模型,分为NameNode、SecondaryNameNode、DataNode 。
(1) NameNode ：主要负责文件系统命名空间的管理、存储文件目录 Metadata 元数据信息，主要包括文件目录、 lock 块和文件对应关系，以及 block 块和 DataNode 数据节点的对应关系。
(2) SecondaryNameNode ：是 NameNode 的冷备份，用来减少 NameNode 的工作量。
(3) DataNode ：负责存储客户端（ Client ）发来的 Block 数据块，执行数据块的读写操作
1.1 NameNode
HDFS 的命名空间包含目录、文件和块。在HDFS 1.0架构中，在整个 HDFS 集群中只有一个命名空间，并且只有唯一一个NameNode负责对这个命名空间进行管理。HDFS2.0 新特性 federation 联邦功能支持多个命名空间，并且允许在 HDFS中同时存在多个 NameNode。
HDFS 集群的命名空间由 NameNode 来存储。NameNode有两个核心的数据结构：Fslmage和EditLog。EditLog 事务日志文件记录每一个对文件系统元数据的改变，如在HDFS 中创建一个新的文件，名称节点将会在EditLog中插入一条记录来记录这个改变。整个命名空间的信息包括文件块的映射等都存放在Fslmage文件中。
名称节点启动时，它将从磁盘中读取 Fslmage和EditLog ，将 EditLog 中的所有事务应用到Fslmage ，然后将新的 Fslmage 刷新到本地磁盘中，因为事务己经被处理并已经持久化到 Fslmage中，然后就可以截去旧的EditLog。这个过程叫作检查点。
Fslmage和Editlog HDFS 非常重要的数据结构，如果这些文件损坏，就会导致整个集群的失效，因此可以配置成复制多个Fslmage和 EditLog 的副本。
1.2 SecondaryNameNode
SecondaryNameNode 是HDFS 架构中的一个组成部分，它用来保存名称节点中对 HDFS 元数据信息的备份，减小 Editlog 文件大小，从而缩短名称节点重启的时间一般是单独运行在机器上。
SecondaryNameNode让EditLog 变小的工作流程如下：
(1) SecondaryNameNode 会定期和 NameNode 通信，请求其停止使用 EditLog 文件，暂时将新的操作写到一个新的文件 edit.new 中，这个操作是瞬间完成的，上层写日志的函数完全感觉不到差别。
(2) SecondaryNameNode 通过 HTTP GET 方式从 NameNode 上获取到 Fslmage和EditLog件，井下载到本地的相应目录下。
(3) SecondaryNameNode 将下载下来的 Fslmage 载入到内存，然后逐条地执行 EditLog
文件中的各项更新操作，使内存中的 Fslmage 保持最新。这个过程就是 EditLog和Fslmage 文件合井。
(4) SecondaryNameNode 执行完（3）操作之后，会通过 post 方式将新的 Fslmage 文件发送NameNode 节点上。
(5) NameNode 将从 SecondaryNameNode 接收到的新的 Fslmage 替换旧的 Fslmage 文件，同时将 Edit.new 替换 EditLog 文件，从而减小EditLog 文件大小。
2 启用HDFS 高可用
2.1 HA介绍
HDFS 1.0中虽然存在一个第二名称节点（Secondary NameNode），但第二名称节点无法提供“热备份”功能，一旦名称节点发生故障，系统需要停机恢复。HDFS 2.0 采用HA(High Availability)架构,解决了NameNode 单点故障的问题。HA特性通过热备份的方式为主 NameNode 提供个备用，一旦主 NameNode 出现故障，可以迅速切换至备用 NameNode，从而实现不间断对外提供服务。
典型的 HDFS HA 架构如上图所示，它通常由两个 Nam Node 组成：一个处于 Active状态，另一个处于 Standby 状态。Active NameNode 对外提供服务，比如处理来自客户端的请求，Standby NameNode 则不对外提供服务，仅同步 Active NameNode 的状态，以便能够在它失败时快速进行切换。
HA 中的两个 NameNode 属于同一个命名空间，两个 NameNode为了能够实时同步元数据信息（实际上是共享 EditLog），会通过一组JoumalNodes独立进程通信。每个 Journal 暴露－个简单的 RPC 接口，允许 NameNode 读取和写入数据，数据存放在Journal 节点的本地磁盘。当Active NameNode 写入 EditLog 时，它向集群的所有 JoumalNode 发送写入请求，当多数节点回复确认成功写入之后， EditLog 就认为是成功写入。
Standby NameNode 负责监听， 一旦发现有新数据写入，就读取这些数据，并加载到自己内存中，以保证自己内存状态与 Active NameNode 保持基本一致。
Hadoop 使用 ZooKeeper 支持自动故障转移， ZooKeeper 的任务包括 NameNode 失败检测和NameNode 选举。
HDFSHA 集群的配置如下：
(1) NameNode机器： 运行 Active NameNode和 Standby NameNode 的机器配置应保持一样。
(2) 当 Active 状态的 NameNode 宕机后，需要手动切换Standby 状态的 NameNode 来继提供服务。如果要实现自动故障转移，必须依赖 ZooKeeper。
(3) JournalNode 机器：这些守护进程比较轻量级，可以部署在其他服务器上。至少需要部署 3个JoumalNode 节点， 便容忍一个节点故障。通常配置成奇数。
(4) 配置NameNode HA后，客户端可以通过HA的逻辑名称去访问数据，而不用指定某一台NameNode，当某一台 NameNode 失效自动切换后，客户端不必更改 HDFS的连接地址 ，仍通过逻辑名称去访问。
需要注意的是， Standby NameNode 同时完成了原来 SecondaryNameNode checkpoint （检查点）功能，因此不需要再独立部署 SecondaryNameNode。
2.2 CDH中启用HA步骤
3 测试HDFS 高可用
手工切换HA的步骤如下图：
