HDFS(3):Hadoop优化与发展_hdfs ha为什么无法解决可扩展性和隔离性-CSDN博客

本文链接：https://blog.csdn.net/weixin_43660536/article/details/118357722

7、hadoop的优化与发展

7.1、HDFS1.x的局限与不足

单点故障
- 每个群集只有一个NameNode，NameNode存在单点故障（SPOF）。
- 如果该计算机或进程不可用，则整个群集在整个NameNode重新启动或在另一台计算机上启动之前将不可用
- 如果发生意外事件（例如机器崩溃），则在操作员重新启动NameNode之前，群集将不可用。
- 计划内的维护事件，例如NameNode计算机上的软件或硬件升级，将导致群集停机时间的延长。
内存占用过多（OOM）
- namenode随着业务的增多，内存占用也会越来越多
- 如果namenode内存占满，将无法继续提供服务
水平扩展不行
- 将来服务器启动的时候，启动速度慢
业务隔离性差
- 存储：有可能我们需要存储不同部门的数据
  - 计算：有可能存在不同业务的计算流程
- 项目后期namenode的吞吐量将会是集群的瓶颈
- 客户端所有的请求都会先访问NameNode
日志文件存放
- 如果NameNode出现不能回复情况，导致数据丢失。

7.2、Hadoop2.x的优化

组件	Hadoop1.0的问题	Hadoop2.0的改进
HDFS	单一名称节点，存在单点失效问题	设计了HDFS HA，提供名称节点热备机制
HDFS	业务隔离性差水平扩展不行	设计了HDFS Federation（HDFS联邦），管理多个命名空间
HDFS	日志文件存放	设计了共享存储系统QJM（仲裁日志管理器），第三方存储日志
MapReduce	资源管理效率低	设计了新的资源管理框架YARN

HDFS2.x
- NameNode节点的高可用
  - HA–high availability
- NameNode业余的水平扩展
  - Federation 联邦

8、HDFS 2.x组件----即HDFS HA

在这里插入图片描述

设计思想

HDFS 2.x启用了主备节点切换模式（1主1备）
- HA集群设置两个名称节点，“活跃（Active）”和“待命（Standby）”
当主节点出现异常的时候，集群直接将备用节点切换成主节点
- 要求备用节点马上就要工作
- 主备节点内存几乎同步
有独立的线程HealthMonitor对主备节点进行监控健康状态
- Failover Controller Active 故障转移控制器
需要有一定的选举机制，帮助我们确定主从关系
- Zookeeper确保一个名称节点在对外服务
我们需要实时存储日志的中间件

8.1、详情

在这里插入图片描述

NameNode Active(ANN):主节点
1. 与原Namenode功能一致；记录数据信息，保持与DN心跳；记录日志；
NameNode Standby（SNN）：备节点
1. 同ANN功能且多了合并日志Edits和FsImage功能
DateNode（DN）：数据结点
1. 与原DN功能一样，存储数据；
2. 同时两个结点保持心跳和汇报
Quorum Journal Manager（QJM）：仲裁（一致性）日志管理系统， JN*3=QJM
1. 实现日志管理与日志数据同步
2. 日志有ANN生成，同时发送到所有的JN的每个结点上，半数以上收到则日志生效
3. 日志在QJM上存储成功后，ANN开始执行命令
4. SNN每隔一定时间去QJM上获取日志，同步数据。
Failover Controller（ZKFC）：(故障转移控制器)
1. 对 NameNode 的主备切换进行总体控制，能及时检测到 NameNode 的健康状况
2. 在ANN 故障时借助 Zookeeper 实现自动的主备选举和切换
3. 为了防止因为NN的GC失败导致心跳受影响，ZKFC作为一个deamon（守护）进程从NN分离出来
4. 每次启动时可以发动主备节点的竞选
ZooKeeper
1. 为主备切换控制器提供主备选举支持。
2. 辅助投票
3. 和ZKFC保持心跳机制，确定ZKFC的存活

8.2、ZKFC工作流程

启动时：
- 当集群启动时，主备节点的概念是很模糊的
- 当ZKFC只检查到一个节点是健康状态，直接将其设置为主节点
- 当zkfc检查到两个NN节点是的健康状态，发起投票机制
- 选出一个主节点，一个备用节点，并修改主备节点的状态
运行时：
- 由 ZKFailoverController、HealthMonitor 和 ActiveStandbyElector 这 3 个组件来协同实现主备切换
  - ZKFailoverController启动的时候会创建 HealthMonitor 和 ActiveStandbyElector 这两个主要的内部组件
  - HealthMonitor 主要负责检测 NameNode 的健康状态
  - ActiveStandbyElector 主要负责完成自动的主备选举，内部封装了 Zookeeper 的处理逻辑

在这里插入图片描述

主备节点正常切换

NameNode 在选举成功后，ActiveStandbyElector会在 zk 上创建一个ActiveStandbyElectorLock 临时节点，而没有选举成功的备 NameNode 中的 ActiveStandbyElector会监控这个节点
如果 Active NameNode 对应的 HealthMonitor 检测到 NameNode 的状态异常时， ZKFailoverController 会主动删除当前在 Zookeeper 上建立的临时节点ActiveStandbyElectorLock
如果是 Active NameNode 的机器整个宕掉的话，那么跟zookeeper连接的客户端线程也挂了,会话结束,那么根据 Zookeepe的临时节点特性，ActiveStandbyElectorLock 节点会自动被删除，从而也会自动进行一次主备切换
处于 Standby 状态的 NameNode 的 ActiveStandbyElector 注册的监听器就会收到这个节点的 NodeDeleted 事件，并创建 ActiveStandbyElectorLock 临时节点，本来处于 Standby 状态的 NameNode 就选举为Active NameNode 并随后开始切换为 Active 状态。

在这里插入图片描述

8.3、脑裂brain-split

定义
- 脑裂是Hadoop2.X版本后出现的全新问题，实际运行过程中很有可能出现两个namenode Active同时服务于整个集群的情况，这种情况称之为脑裂。
原因
- 脑裂通常发生在主从namenode切换时，由于ActiveNameNode的网络延迟、设备故障等问题，另一个NameNode会认为活跃的NameNode成为失效状态，此时StandbyNameNode会转换成活跃状态，此时集群中将会出现两个活跃的namenode。因此，可能出现的因素有网络延迟、心跳故障、设备故障等。
脑裂场景
- NameNode 可能会出现这种情况，NameNode 在垃圾回收（GC）时，可能会在长时间内整个系统无响应
- zkfc客户端也就无法向 zk 写入心跳信息，这样的话可能会导致临时节点掉线，备 NameNode 会切换到 Active 状态
- 这种情况可能会导致整个集群会有同时有两个Active NameNode
脑裂问题的解决方案是隔离（Fencing）
- 1.第三方共享存储：任一时刻，只有一个 NN 可以写入；
- 2.DataNode：需要保证只有一个 NN 发出与管理数据副本有关的命令；
- 3.Client需要保证同一时刻只有一个 NN 能够对 Client 的请求发出正确的响应。
  - (a) 每个NN改变状态的时候，向DN发送自己的状态和一个序列号。
  - (b) DN在运行过程中维护此序列号，**当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。**DN接收到这个返回是认为该NN为新的active。
  - © 如果这时原来的active（比如GC）恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。
解决方案
- ActiveStandbyElector为了实现 fencing，当NN成为ANN之后创建Zookeeper临时节点ActiveStandbyElectorLock，创建ActiveBreadCrumb 的持久节点，这个节点里面保存了这个 Active NameNode的地址信息(node-01)
- Active NameNode的 ActiveStandbyElector在正常的状态下关闭 Zookeeper Session 的时候，会一起删除这个持久节点
- 但如果 ActiveStandbyElector在异常的状态下关闭，那么由于 /hadoop-ha/${dfs.nameservices}/ActiveBreadCrumb 是持久节点，会一直保留下来，后面当另一个 NameNode 选主成功之后，会注意到上一个 Active NameNode 遗留下来的这个节点，从而会回调 ZKFailoverController的方法对旧的 Active NameNode 进行 fencing。
  - 首先尝试调用这个旧 Active NameNode 的 HAServiceProtocol RPC 接口的 transitionToStandby 方法，看能不能把它转换为 Standby 状态；
  - 如果 transitionToStandby 方法调用失败，那么就执行 Hadoop 配置文件之中预定义的隔离措施。
    1. sshfence：通过 SSH 登录到目标机器上，执行命令 fuser 将对应的进程杀死
    2. shellfence：执行一个用户自定义的 shell 脚本来将对应的进程隔离
- 在成功地执行完成 fencing 之后，选主成功的 ActiveStandbyElector 才会回调 ZKFailoverController 的 becomeActive 方法将对应的 NameNode 转换为 Active 状态，开始对外提供服务。
- 新的主创建临时节点ActiveStandbyElectorLock，创建持久化节点ActiveBreadCrumb ，并将自己的主机地址Node02赋值给初始化节点

9、HDFS Federation(HDFS 联邦)

HDFS Federation就是使得HDFS支持多个命名空间，并且允许在HDFS中同时存在多个Name Node。

在这里插入图片描述

9.1、HDFS 1.x 问题

单点故障问题
Namespace（命名空间）的限制
- NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。
- 50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，12PB的存储
- DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。
不可以水平扩展（是否可以通过纵向扩展来解决？）
系统整体性能受限于单个名称节点的吞吐量
单个名称节点难以提供不同程序之间的隔离性
HDFS HA是热备份，提供高可用性，但是无法解决可扩展性、系统性能和隔离性

9.2 、HDFS 联邦

在这里插入图片描述

NameNode提供了命名空间（NameSpace）和块（Block）管理功能。
HDFS 联邦拥有多个独立的命名空间，每个空间管理属于自己的一组块，这些同组的块构成了“块池”（Block Pool）。
所有的NameNode 会共享底层的数据节点的存储资源。数据节点是一个物理概念，块池则属于逻辑概念。

块池Block Pool
- Block pool(块池)就是属于单个命名空间的一组block(块)管理区域
- 每一个datanode为所有的block pool存储
- Datanode是一个物理概念，而block pool是一个重新将block划分的逻辑概念
- 一个Namenode失效不会影响其下的datanode为其他Namenode的服务
- datanode与Namenode建立联系并开始会话后自动建立Block pool
Namespace Volume（命名空间卷）
- 一个Namespace和它的Block Pool合在一起称作Namespace Volume
- Namespace Volume是一个独立完整的管理单元。当一个Namenode/Namespace被删除，与之相对应的Block Pool也也被删除。
通过多个namenode把元数据的存储和管理分散到多个节点中
- 降低单个NN节点数据压力,计算压力
命名空间卷可以通过增加机器来进行横向水平扩展
- 可以让更多的节点参与到运算
- namespace命名空间，通过这种方式确定要处理数据的路径
我们可以通过namenode和namespace组合使用
- 所有的nn共享dn
- 但是每一个namespace会单独管理自己的块
- 会创建一个管理块的机制：blocks pool

9.3、HDFS Federation的访问方式

对于Federation中的多个命名空间，可以采用客户端挂载表（Client Side Mount Table）方式进行数据共享和访问。
客户可以访问不同的挂载点来访问不同的子命名空间。
把各个命名空间挂载到全局“挂载表”（mount-table）中，实现数据全局共享。
同样的命名空间挂载到个人的挂载表中，就成为应用程序可见的命名空间。

在这里插入图片描述

9.4、HDFS Federation优势

HDFS Federation设计可解决单名称节点存在的以下几个问题：

（1）HDFS集群扩展性。多个名称节点各自分管一部分目录，使得一个集群可以扩展到更多节点，不再像HDFS1.0中那样由于内存的限制制约文件存储数目。
（2）性能更高效。多个名称节点管理不同的数据，且同时对外提供服务，将为用户提供更高的读写吞吐率。
（3）良好的隔离性。用户可根据需要将不同业务数据交由不同名称节点管理，这样不同业务之间影响很小。

需要注意的，HDFS Federation并不能解决单点故障问题，也就是说，每个名称节点都存在在单点故障问题，需要为每个名称节点部署一个后备名称节点，以应对名称节点挂掉对业务产生的影响。

10、Hadoop3.x新特性

10.1、Erasure Encoding 技术

简介
- HDFS默认情况下，Block的备份系数是3，一个原始数据块和其他2个副本。
- 其中2个副本所需要的存储开销各站100%，这样使得200%的存储开销
- 正常操作中很少访问具有低IO活动的冷数据集的副本，但是仍然消耗与原始数据集相同的资源量。
EC技术
- EC(擦除编码)和HDFS的整合可以保持与提供存储效率相同的容错。
  - HDFS:一个副本系数为3，要复制文件的6个块，需要消耗6*3=18个块的磁盘空间
  - EC:6个数据块，3个奇偶校验块
- 擦除编码需要在执行远程读取时，对数据重建带来额外的开销，因此他通常用于存储不太频繁访问的数据

10.2、NameNode多个备用

在Hadoop3中允许用户运行多个备用的NameNode。
- 例如，通过配置三个NameNode（1个Active NameNode和2个Standby NameNode）和5个JournalNodes节点
- 集群可以容忍2个NameNode节点故障。

在这里插入图片描述

10.3、服务器端口更改

早些时候，多个Hadoop服务的默认端口位于Linux端口范围以内。
因此，具有临时范围冲突端口已经被移除该范围

10.4、DataNode 负载均匀

单个数据节点配置多个数据磁盘，在正常写入操作期间，数据被均匀的划分，因此，磁盘被均匀填充。
在维护磁盘时，添加或者替换磁盘会导致DataNode节点存储出现偏移
这种情况在早期的HDFS文件系统中，是没有被处理的。
Hadoop3通过新的内部DataNode平衡功能来处理这种情况，这是通过hdfs diskbalancer CLI来进行调用的。执行之后，DataNode会进行均衡处理