在 IBM CAMP 服务器上实现开源 Hadoop HDFS 的高可用性-1

look_w

开源 Hadoop HDFS 的高可用性介绍Hadoop 是目前最热门的大数据计算系统，它实现了一个可扩展的分布式文件系统 HDFS 作为海量数据的存储系统。HDFS 是主从式的分布式系统（如图 1），NameNode 管理整个文件系统的元数据，负责数据的分配，并管理着 DataNode；而 DataNode 负责存储数据块，按块（用户可设置，默认是 64MB）提供数据存取服务。
HDFS 的客户端进行读写操作都需要通过 NameNode。在读操作时，客户端需要连接 NameNode，获取数据块所在的 DataNode，再连接 DataNode    进行数据块的读取；在写操作时，客户端需要连接 NameNode，得到 NameNode 分配的数据写入位置后，连接相应的 DataNode    写入数据；在进行元数据操作时，客户端需要连接 NameNode 进行修改（如图 1）。在早前的 Hadoop 集群中，NameNode 只有一个，它是否正常运行，直接决定了整个 Hadoop 集群能否正常运转，进而会影响工作于 Hadoop 集群之上的 HBase、Hive、Pig 等服务的工作。 因此 NameNode 也就成为了系统的一个单一故障点，NameNode 的可用性关系到集群系统的可用性。如果 NameNode 的元信息由于故障损坏，更会导致整个分布式文件系统损坏。
图 1.HDFS 的架构及读写流程HDFS 高可用性的种类以及优缺点为了提高整个集群的可靠性与可维护性，各大公司与社区提出了许多改进 HDFS 的方案，主要有如下几种：
NameNode 多目录存储：通过配置 dfs.name.dir，可以將 NameNode 维护的元数据保存到多个目录，进而可以备份一份到远程的 NFS 目录，当 NameNode 故障或停机时，可以通过另外一台 NameNode 读取 NFS 目录中的备份进行恢复工作。不足之处在于写入 NFS 增加了系统开销，不利于 NameNode 高效工作；并且需要管理员手工进行操作。由于在恢复过程中存在一段系统不可用的时间，该方案只是一种备份方案，并不是真正意义上的 HA 方案。
Secondary NameNode：Secondary NameNode 通过定期下载 NameNode 的元数据和日志文件，并进行合并更新，来对 NameNode 进行备份。当 NameNode 故障时，可以通过 Secondary NameNode 进行恢复。不足之处在于 Secondary NameNode 的备份只是 NameNode 的 Checkpoint，并没有与 NameNode 实时同步，恢复后的数据存在一定的元信息丢失。由于在恢复过程中存在一段系统不可用的时间，该方案只是一种备份方案，并不是真正意义上的 HA 方案。
Checkpoint Node：与 Secondary NameNode 的原理基本相同，利用了 HDFS 的 Checkpoint 机制进行备份，通过一个 Checkpoint Node，定期从 Primary NameNode 中下载元数据信息进行合并，形成最新的 Checkpoint，并上传到 NameNode 进行更新不足之处在于 Checkpoint 的备份没有与 NameNode 实时同步，恢复后的数据存在一定的元信息丢失。由于在恢复过程中存在一段系统不可用的时间，该方案只是一种备份方案，并不是真正意义上的 HA 方案。
Backup Node：Backup Node 在内存和磁盘保存了 NameNode 最新的元数据。当 NameNode 发生故障，可用读取 Backup Node 中最新的元数据信息进行恢复。 该方案只是的不足在于当 NameNode 发生故障，目前还只能通过重启 NameNode 的方式来恢复服务，系统会出现一段不可用时间。
FaceBook 的 AvatarNode：存在两个 NameNode，分别为 Active Node 和 Standby Node，Active Node 对外提供服务。Standby Node 处于 Safe mode，在内存中保存 Active Node 最新的元数据信息。Active Node 和 Standby Node 通过共享的 NFS 进行交互，DataNode 同时向 Active Node 和 Standby Node 汇报数据块信息。当 Active Node 故障时，管理员通过一条命令进行切换，Standby Node 转换为 Active Node 后立刻就可以工作，大大减少了系统不可用的时间，是一种真正的 HA 方案。不足之处在于该方案最终没有被社区接受。
社区开发的 HDFS HA：与 AvatarNode 类似，存在 Active Node 和 Standby Node 两个 NameNode， 管理员通过一条命令进行切换。针对 Active Node 和 Standby Node 的共享日志，社区又提供三种解决方案：

• 两个 Node 共享 NAS 上的 NFS，是社区最初的解决方案，该方案需要专用存储设备，在使用上有一定限制。
• 基于 Bookkeeper 的日志存储方案，该方案主要依靠 Zookeeper 的子项目 Bookkeeper 实现日志的高可靠共享存储，该方案对 Zookeeper 依赖较大，配置比较复杂。
• 基于 QJM（Qurom Journal Manager）的共享日志方案。QJM 的基本原理就是用 2N+1 台 Journal Node 存储日志，每次写数据操作有大多数（W>=N+1）返回成功时，就认为该次写入日志成功。该方案独立性好，配置比较简单，是社区目前主推的方案。在手动切换的基础上，社区又开发了基于 Zookeeper 的 ZKFC（Zookeeper Failover Controller）自动切换解决方案，每个 Active Node 和 Standby Node 各有一个 ZKFC 进程监控 NameNode 的健康状况，当 Active Node 出现问题时，自动將 Standby Node 切换为 Active Node。

PLinux 对于 Hadoop 的支持随着开源开发平台的迅猛发展，Linux 用户正面临着企业转型升级所带来的 IT 挑战。作为服务器领域创新的引领者，IBM 推出了"Project CAMP"。它通过将 VAD(增值分销商)合作伙伴的软件预装在 PowerLinux 服务器上，帮助用户降低 Power 平台的使用成本以及 PowerVM 虚拟化的技术门槛。
当前 IBM CAMP 服务器上安装 PLinux 操作系统，在 PLinux 上使用 IBM JDK1.6 或者 JDK1.7，开源 Hadoop 对其支持。本文将详细描述基于 PRedhat6.4，IBM JKD1.7 上配置 Hadoop HDFS 的 HA。
PLinux 系统上 Hadoop HDFS HA 的配置PLinux 的环境准备硬件信息列表：
主机主机名系统 ip 地址 1配置调整后 CPU硬盘CAMP_1CAMP_1_vios10.10.10.238C/64G1C2*900plinux910.10.10.243.5C2*900plinux1010.10.10.253.5C2*900CAMP_2CAMP_2_vios10.10.10.268C/64G1C2*900plinux1110.10.10.273.5C2*900plinux1210.10.10.283.5C2*900两台 IBM CAMP 服务器，每台服务器上各有两个 PLinux 分区。
软件信息列表：
软件版本号操作系统Red Hat Enterprise Linux Server release 6.4 (Santiago)HadoopVersion 2.2.0HbaseVersion 0.96JAVAibm-java-sdk-7.0-4.2-ppc64-archiveZooKeeperVersion 3.3.0HiveVersion 0.12
图 2 .Hadoop 开源组件结构图本文使用了以上开源组件: Hadoop、HBase、Hive 以及 ZooKeeper。
图 3.HDFS HA 系统结构图四个 PLinux 分区分别是 plinux09、plinux10、plinux11、plinux12.
NameNode: plinux09、plinux10
DataNode: plinux09、plinux10、plinux11、plinux12
ZooKeeper: plinux09、plinux10、plinux11
HBase: plinux10
Hive: plinux09