5.HDFS集群—HA下单点故障、压力内存问题

CAP原则

强一致性会破坏可用性
Consistency:一致性
是指在同一时刻,分布式系统中NameNode主备节点里元数据始终是相同值。
Availability:可用性
不会因为NameNode备节点网络延迟导致主节点等待卡顿。
或指NameNode中的某一个节点故障宕机后,集群还能响应客户端请求,并且数据不丢失。
Partition  tolerance:分区容忍性
能不能尽量保证一致性的情况下,将数据拆分开来,分散存储。
例如:
   1.DataNode节点。
   2.系统中一部分节点无法和其他节点进行通信情况下,系统也能够正常运行。
CA
单机情况,很容易满足
CP
两台服务器,分别存储一部分数据。如果一台服务器宕机,一部分数据丢失。
AP
分区容忍性结合一致性会使,数据库数据分散存储,并且要求各个节点数据始终相同。这样就会造成较高的网络延迟等卡顿情况,降低可用性。

Paxos 算法

  1. Paxos算法是莱斯利·兰伯特于1990年提出的一种基于消息传递的一致性算法。
  2. 这个算法被认为是类似算法中最有效的。
  3. 该算法覆盖全部场景的一致性。
  4. 每种技术会根据自己技术的特征选择简化算法实现。
  5. 传递:NN之间通过一个可靠的传输技术,最终数据能同步就可以
  6. 我们一般假设网络等因素是稳定的
  7. 类似一种带存储能力的消息队列

简化思路:

1. 分布式节点数量是否明确
2. 节点权重是否明确
例如按照主机名计算权重(条件约束清晰)。
3. 强一致性破坏可用性
4. 过半通过可以中和一致性和可用性
只要集群中过半节点都通过既是真通过,会使集群更可靠。

每一次读取写入数据,都会检查是否过半节点都成功。

否则会导致数据读取写入不一致问题:例如写入到A节点还没来得及复制到B节点,这时备NodeName就去B节点读取数据。
5. 最简单的自我协调实现方式:主从
6. 主的选举:明确节点数量和权重
在条件清晰时可以快速选出主节点。
7. 主从的职能:
主:增删改查
从:查询,如想增删改要将请求传递给主
主与从:过半数同步数据

分布式集群

主从集群
结构相对简单,主与从协作
单点主机
#优点
数据一致好掌握

#缺点
单点故障,集群整体不可用
压力过大,内存受限

HDFS针对不同场景解决方案

单点故障时
#HADOOP 2.x 只支持HA的一主一备
#官方建议:一主三备

高可用方案:HA(High Available)
多个NN,主备切换
压力过大,内存受限时
联帮机制: Federation(元数据分片)
多个NN,分别管理不同的元数据

详细解决方案——单点故障时

JournalNode 元数据共享节点

集群启动时,可以同时启动2个NameNode。

这些NameNode只有一个是active的,另一个属于standby状态。

active状态意味着提供服务也称主节点,standby状态意味着处于休眠状态也称副节点,只进行数据同步,时刻准备着提供服务。

主备NameNode为了数据同步,会通过一组称作JournalNode的独立进程进行相互通信。

当active状态的NameNode有任何添加修改时,会告知一半以上的JournalNodes进程。

standby状态的NameNode可以读取JNs中的数据变更信息,并且一直监控editLog的变化,把变化应用于自己的节点内。

standby可以确保在集群出错时,主节点状态已经被完全同步了。

节点数应大于3台,并且为奇数个。
副节点读取JournalNode日志恢复数据

NameNode如何产生元数据

client客户端交互产生的数据
例如:mkdir /a

DataNode提交的block数据

ZooKeeper(ZK)

可以为我们提供配置管理,名字服务,提供分布式应用程序协调以及集群管理等服务
只同步状态,不同步数据

#配置管理
例如在集群中使用数据库连接等配置文件,多服务器都需要这个配置,这时就需要使用ZK服务来保证这些配置文件的一致性。

#名字服务
同步每台机器里都备的hosts文件

#分布式锁
利用Zookeeper来协调多个分布式进程之间的活动,一台服务器宕机,另一台要顶上去,利用leader选举制。

#集群管理
集群中时常有新的节点加入进来,也有老的节点退出集群,要保证这些节点服务一致性。

ZKFailoverController(ZKFC)

监控某一NameNode节点状态,因为要可靠的监控服务,通常和NameNode在同一主机下。

ZK — ZKFC — NameNode同步流程

ZKFC抢锁竞争
ZK有一个目录树,两个ZKFC向这个节点下创建锁,谁创建成功谁就是NameNode主节点,其他的是NameNode副节点。

创建锁时会自动添加两者ZKFC的回调函数(call back),
主节点宕机
随着时间推移,如果主节点宕机了,同主机的ZKFC进程会把锁删掉,而后触发删除事件,调用回调方法,通知ZKFC进入新一轮抢锁环节。

副ZKFC节点抢锁成功后,他首先会去对方主节点确认是否真的宕机。
ZKFC异常退出
如果ZKFC异常退出了,TCP通信链接会和ZK断开,自动将锁删除。

而后副ZKFC节点抢锁成功后,同样会向主节点确认是否真的宕机,发现主ZKFC进程退出了,会将主节点降级为副节点,自身副节点升级为主节点。
极端情况
主ZKFC节点无法和ZK通信,并且副ZKFC节点也无法连通主节点,然而副节点可以和其他所有节点例如NN,DN成功连接。

这样就无法判断是主节点宕机,还是自己网络延迟,就会无限的报错。

不过发生几率极低。
极端情况解决方案
两台ZKFC利用串口相互连接对方电源,如果副节点抢锁成功后,就将对方主节点电源断电,这样副节点就可以放心升级为主节点。
ZooKeeper JournalNode DataNode ZK1 ZK2 ZK3 JN1 JN2 JN3 DN1 DN2 DN3 NameNode
Active
NameNode
Standby
FailoverControllerActive FailoverControllerStandby Client

详细解决方案——压力过大,内存受限时

思路

解决方案
NNa和NNb的元数据是相互独立的,分别存储相同的文件也不会产生冲突。

但是他们共享一个DataNode集群,元数据隔离,DN统一负责存储。
产生的问题
可是问题也随之而来,数据共享度差。

相互之间无法互通数据。
增加抽象层
可以在之上搭建一个"虚拟文件系统代理层",挂载三个NN的目录,通过三个节点代理分别访问到他们三个的元数据。

客户端直接连接抽象的代理层,使用起来根本感受不到是三个节点。

虚拟文件系统甚至可以访问FTP等各种文件系统。你可以将多种文件系统封装在一个虚拟文件系统里,使用起来感觉就像是一体的。

联邦机制

对于client客户端来说,访问的是虚拟文件系统这个抽象层,用起来就好像a、b、c都在一个节点上一样。

虚拟文件系统这个抽象层不仅可以挂在NameNode,其他文件系统例如FTP都可以挂载,可以更好的整合抽象数据。
1000台DataNode集群 虚拟文件系统-代理层 DataNode<a><其中500台> DataNode<b><其中500台> 挂载目录a 挂载目录b c client NameNode<a> NameNode<b> FTP

题外话

计算机的所有问题都可以加一个抽象层来解决,如果不行就加两层。
操作内核只暴露两百多个接口,而C语言却暴露N多个库
上一篇:ORA-17629: Cannot connect to the remote database server


下一篇:HDFS的⼯作机制及动态上下线