[大数据]HDFS高可用

其他资料：

• hadoop中的JournalNode的作用
• https://hadoop.apache.org/docs/r3.1.3/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
• 基于ZooKeeper搭建Hadoop高可用集群

注意要点：

• 注意备份之前的hadoop配置文件，方便回溯
• 部署 Zookeeper，可参考《zookeeper内部原理和API操作》
• 尚硅谷的视频hadoop版本是2.7.4，之前部署的版本是3.1.3，瞄了一眼官方文档基本差不多，对照官方来配置，hadoop2.x和hadoop3.x的端口发生了变化需要调整
• 文档应该是采用QJM方式配置的，参考https://hadoop.apache.org/docs/r3.1.3/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html
• 查了下资料（https://blog.csdn.net/zuotengseven/article/details/108218696），fsimage存在本地，edits存在journalnode（共享存储），高可用没有secondnn，而是standby承担了2nn的工作
• 参考https://blog.csdn.net/yokirin/article/details/104834169，HA启动时报错检查文件权限和路径是否正确

实现高可用最关键的策略是消除单点故障。 HA 严格来说应该分成各个组件的 HA 机制：HDFS 的 HA 和 YARN 的 HA

NameNode 主要在以下两个方面影响 HDFS 集群

• NameNode 机器发生意外，如宕机，集群将无法使用，直到管理员重启

• NameNode 机器需要升级，包括软件、硬件升级，此时集群也将无法使用

HDFS HA 功能通过配置 Active/Standby 两个 NameNodes 实现在集群中对 NameNode 的热备来解决上述问题

hadoop高可用要点

（1）元数据管理

• 内存中各自保存一份元数据；
• Edits 日志只有 Active 状态的 NameNode 节点可以做写操作；
• 两个 NameNode 都可以读取 Edits；
• 共享的 Edits 放在一个共享存储中管理**（qjournal 和 NFS 两个主流实现）**

（2）状态管理模块

实现了一个 zkfailover，常驻在每一个 namenode 所在的节点，每一个 zkfailover 负责监控自己所在 NameNode 节点，利用 zk 进行状态标识，当需要进行状态切换时，由 zkfailover来负责切换，切换时需要防止 brain split 现象的发生

（3）免密登录

必须保证两个 NameNode 之间能够 ssh 无密码登录

（4）隔离（Fence）

即同一时刻仅仅有一个 NameNode 对外提供服务

HDFS-HA 自动故障转移工作机制

自动故障转移为 HDFS 部署增加了两个新组件：ZooKeeper 和 ZKFailoverController（ZKFC）进程

ZooKeeper 是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。 HA 的自动故障转移依赖于 ZooKeeper 的以下功能

• 故障检测： 集群中的每个 NameNode 在 ZooKeeper 中维护了一个持久会话，如果机器崩溃， ZooKeeper 中的会话将终止， ZooKeeper 通知另一个 NameNode 需要触发故障转移。
• 现役 NameNode 选择： ZooKeeper 提供了一个简单的机制用于唯一的选择一个节点为 active 状态。如果目前现役 NameNode 崩溃，另一个节点可能从 ZooKeeper 获得特殊的排外锁以表明它应该成为现役 NameNode。ZKFC 是自动故障转移中的另一个新组件，是 ZooKeeper 的客户端，也监视和管理NameNode 的状态。每个运行 NameNode 的主机也运行了一个 ZKFC 进程， ZKFC 负责：
  • 健康监测： ZKFC 使用一个健康检查命令定期地 ping 与之在相同主机的 NameNode，只要该 NameNode 及时地回复健康状态， ZKFC 认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。
  • ZooKeeper 会话管理： 当本地 NameNode 是健康的， ZKFC 保持一个在 ZooKeeper中打开的会话。如果本地 NameNode 处于 active 状态， ZKFC 也保持一个特殊的 znode 锁，该锁使用了 ZooKeeper 对短暂节点的支持，如果会话终止，锁节点将自动删除。
  • 基于 ZooKeeper 的选择： 如果本地 NameNode 是健康的，且 ZKFC 发现没有其它的节点当前持有 znode 锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地 NameNode 为 Active。故障转移进程与前面描述的手动故障转移相似，首先如果必要保护之前的现役 NameNode，然后本地 NameNode 转换为 Active 状态。

在 hadoop26、 hadoop58 和 hadoop100三个节点上部署 Zookeeper，可参考《zookeeper内部原理和API操作》

启动zookeeper

配置HDFS-HA

集群规划

配置 core-site.xml

<configuration>    
    <!-- 把两个 NameNode）的地址组装成一个集群 mycluster -->
    <property>
        <name>fs.defaultFS</name>
        <value>hdfs://mycluster</value>
    </property>    
    <!-- 指定 hadoop 运行时产生文件的存储目录 -->
    <property>
        <name>hadoop.tmp.dir</name>
        <value>/opt/ha/hadoop-2.7.2/data/tmp</value>
    </property>
</configuration>

配置 hdfs-site.xml

应该是采用QJM方式配置的，参考https://hadoop.apache.org/docs/r3.1.3/hadoop-project-dist/hadoop-hdfs/HDFSHighAvailabilityWithQJM.html

查了下资料（https://blog.csdn.net/zuotengseven/article/details/108218696），fsimage存在本地，edits存在journalnode（共享存储），高可用没有secondnn，而是standby承担了2nn的工作

一般认为journalnode有2n+1台，如果大于等于n+1台成功写入，就算写入jn成功。
standby-nn 会定时拉取3台jn节点（假设有3台jn）的edits_log（只拉取处于finalized状态的edits_log，in-progress并不会拉取因为他可能会改变），再与本地的fsimage元数据镜像文件做merge操作（ s-nn 并不会同时把edits_log 写入到本地磁盘上。下图中磁盘有edits_log是因为他之前是active-nn(从最后修改时间也可以看出来)。合并操作是在standby-nn内存中完成，完成后会落地新fsimage文件如下图）。
当standby-nn merge完毕后，旧的fsimage不会立即删除而会保留一段时间等待被roll掉，当然版本号会比新merge的fsimage要小。与此同时standby-nn会把新merge的镜像文件推给active-nn ，active-nn旧的镜像也不会立即删除，也是等待被roll掉，新推过来的fsimage镜像也是要比旧的镜像编号要大。

hadoop2.x和hadoop3.x的端口发生了变化需要调整

<configuration>
    <!-- 完全分布式集群名称 -->
    <property>
        <name>dfs.nameservices</name>
        <value>mycluster</value>
    </property>
    <!-- 集群中 NameNode 节点都有哪些 -->
    <property>
        <name>dfs.ha.namenodes.mycluster</name>
        <value>nn1,nn2</value>
    </property>
    <!-- nn1 的 RPC 通信地址 -->
    <property>
        <name>dfs.namenode.rpc-address.mycluster.nn1</name>
        <value>hadoop26:8020</value>
    </property>
    <!-- nn2 的 RPC 通信地址 -->
    <property>
        <name>dfs.namenode.rpc-address.mycluster.nn2</name>
        <value>hadoop58:8020</value>
    </property>
    <!-- nn1 的 http 通信地址 -->
    <property>
        <name>dfs.namenode.http-address.mycluster.nn1</name>
        <value>hadoop26:9870</value>
    </property>
    <!-- nn2 的 http 通信地址 -->
    <property>
        <name>dfs.namenode.http-address.mycluster.nn2</name>
        <value>hadoop58:9870</value>
    </property>
    <!-- 指定 NameNode 元数据在 JournalNode 上的存放位置 这个地方路径没有错误-->
    <property>
        <name>dfs.namenode.shared.edits.dir</name>
        <value>qjournal://hadoop26:8485;hadoop58:8485;hadoop100:8485/mycluster</value>
    </property>
    <!-- 配置隔离机制，即同一时刻只能有一台服务器对外响应 -->
    <property>
        <name>dfs.ha.fencing.methods</name>
        <value>sshfence</value>
    </property>
    <!-- 使用隔离机制时需要 ssh 无秘钥登录-->
    <property>
        <name>dfs.ha.fencing.ssh.private-key-files</name>
        <value>/home/ec2-user/.ssh/id_rsa</value>
    </property>
    <!-- 声明 journalnode 服务器存储目录-->
    <property>
        <name>dfs.journalnode.edits.dir</name>
        <value>/opt/module/hadoop-3.1.3/data/jn</value>
    </property>
    <!-- 关闭权限检查-->
    <property>
        <name>dfs.permissions.enable</name>
        <value>false</value>
    </property>
    <!-- 访问代理类： client， mycluster， active 配置失败自动切换实现方式-->
    <property>
        <name>dfs.client.failover.proxy.provider.mycluster</name>
        <value>org.apache.hadoop.hdfs.server.namenode.ha.Configu
redFailoverProxyProvider</value>
    </property>
</configuration>

xsync同步脚本

启动集群

在各个 JournalNode 节点上，输入以下命令启动 journalnode 服务

sbin/hadoop-daemon.sh start journalnode  

jpsall.sh
jpsall.sh
=============== hadoop26 ===============
26243 JournalNode
25365 QuorumPeerMain
26317 Jps
=============== hadoop58 ===============
22963 QuorumPeerMain
23428 JournalNode
23500 Jps
=============== hadoop100 ===============
6912 JournalNode
6503 QuorumPeerMain
6972 Jps

在nn1格式化namenode

bin/hdfs namenode -format
sbin/hadoop-daemon.sh start namenode  

注意：需要先启动nn1

在nn2上同步nn1元数据

bin/hdfs namenode -bootstrapStandby  

启动nn2

sbin/hadoop-daemon.sh start namenode

启动所有 datanode

sbin/hadoop-daemons.sh start datanode

jpsall.sh
=============== hadoop26 ===============
26945 Jps
26243 JournalNode
26723 DataNode
25365 QuorumPeerMain
26474 NameNode
=============== hadoop58 ===============
23712 NameNode
22963 QuorumPeerMain
23428 JournalNode
23880 DataNode
24153 Jps
=============== hadoop100 ===============
6912 JournalNode
6503 QuorumPeerMain
7096 DataNode
7370 Jps

此时nn1和nn2都是standby

将nn1切换为 Active

bin/hdfs haadmin -transitionToActive nn1

查看是否 Active

bin/hdfs haadmin -getServiceState nn1  
active

配置 HDFS-HA 自动故障转移

在 hdfs-site.xml 中增加

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

在 core-site.xml 文件中增加

<property>
	<name>ha.zookeeper.quorum</name>
	<value>hadoop26:2181,hadoop58:2181,hadoop100:2181</value>
</property>  

关闭所有 HDFS 服务：

sbin/stop-dfs.sh

启动 Zookeeper 集群：

bin/zkServer.sh start

初始化 HA 在 Zookeeper 中状态：

bin/hdfs zkfc -formatZK启动 HDFS 服务：

sbin/start-dfs.sh

在各个 NameNode 节点上启动 DFSZK Failover Controller， 先在哪台机器启动，哪个机器的 NameNode 就是 Active NameNode

sbin/hadoop-daemin.sh start zkfc  

测试

将 Active NameNode 进程 kill

kill -9 namenode 的进程 id

将 Active NameNode 机器断开网络

service network stop  

配置YARN-HA

集群规划

yarn-site.xml

<configuration>
    <property>
        <name>yarn.nodemanager.aux-services</name>
        <value>mapreduce_shuffle</value>
    </property>
    <!--启用 resourcemanager ha-->
    <property>
        <name>yarn.resourcemanager.ha.enabled</name>
        <value>true</value>
    </property>
    <!--声明两台 resourcemanager 的地址-->
    <property>
        <name>yarn.resourcemanager.cluster-id</name>
        <value>cluster-yarn1</value>
    </property>
    <property>
        <name>yarn.resourcemanager.ha.rm-ids</name>
        <value>rm1,rm2</value>
    </property>
    <property>
        <name>yarn.resourcemanager.hostname.rm1</name>
        <value>hadoop26</value>
    </property>
    <property>
        <name>yarn.resourcemanager.hostname.rm2</name>
        <value>hadoop58</value>
    </property>
    <!--指定 zookeeper 集群的地址-->
    <property>
        <name>yarn.resourcemanager.zk-address</name>
        <value>hadoop26:2181,hadoop58:2181,hadoop100:2181</value>
    </property>
    <!--启用自动恢复-->
    <property>
        <name>yarn.resourcemanager.recovery.enabled</name>
        <value>true</value>
    </property>
    <!--指定 resourcemanager 的状态信息存储在 zookeeper 集群-->
    <property>
        <name>yarn.resourcemanager.store.class</name>
        <value>org.apache.hadoop.yarn.server.resourcemanager.recov
ery.ZKRMStateStore</value>
    </property>
</configuration>

同步更新其他节点的配置信息

在各个 JournalNode 节点上，输入以下命令启动 journalnode 服务

sbin/hadoop-daemon.sh start journalnode  

在nn1格式化namenode

bin/hdfs namenode -format
sbin/hadoop-daemon.sh start namenode  

在nn2上同步nn1元数据

bin/hdfs namenode -bootstrapStandby  

启动nn2

sbin/hadoop-daemon.sh start namenode

启动所有 datanode

sbin/hadoop-daemons.sh start datanode

将nn1切换为 Active

bin/hdfs haadmin -transitionToActive nn1

启动 YARN

在 hadoop26中执行：

sbin/start-yarn.sh

在 hadoop58 中执行：

sbin/yarn-daemon.sh start resourcemanager

查看服务状态

bin/yarn rmadmin -getServiceState rm1  

HDFS Federation 架构设计

（1）NameNode 架构的局限性

Namespace（命名空间） 的限制。由于 NameNode 在内存中存储所有的元数据（metadata） ， 因此单个 NameNode 所能存
储的对象（文件+块） 数目受到 NameNode 所在 JVM 的 heap size 的限制。 50G 的 heap 能够存储 20 亿（200million） 个对象，这 20 亿个对象支持 4000 个 DataNode， 12PB 的存储（假设文件平均大小为 40MB） 。 随着数据的飞速增长，存储的需求也随之增长。单个 DataNode从 4T 增长到 36T，集群的尺寸增长到 8000 个 DataNode。存储的需求从 12PB 增长到大于100PB。

（2）隔离问题

由于 HDFS 仅有一个 NameNode，无法隔离各个程序， 因此 HDFS 上的一个实验程序就很有可能影响整个 HDFS 上运行的程序。

（3）性能的瓶颈

由于是单个 NameNode 的 HDFS 架构，因此整个 HDFS 文件系统的吞吐量受限于单个NameNode 的吞吐量。

HDFS Federation 架构设计存在多个namenode

不同应用可以使用不同 NameNode 进行数据管理

Hadoop 生态系统中，不同的框架使用不同的 NameNode 进行管理 NameSpace

阅读世界，共赴山海

423全民读书节，邀你共读