Hadoop HA 架构

为什么要用集群?
企业里面,多台机器 伪分布式 每一个角色都是一个进程

HDFS:
NN
SNN
DN

YARN:
RM
NM

大数据所有组件, 都是主从架构 master-slave
HDFS读写请求都是先到NN节点,
但是,HBase 读写请求不是经过master, 建表和删除表是需要经过master

NN节点挂了,就不能提供对外服务  (-put,-get)
需要配置两个NN节点(实时的,任何时刻只有一台active对外,
另外一台是standby,做实时备份,
随时准备着从standby切换到active状态,对外服务)
NN1 active     11:00点,挂了    hdfs://ip1:8020/   代码,shell脚本
NN2 standby    active         hdfs://ip2:8020/
当前对外提供服务的只有一台机器提供,另外一台机器随时准备着
SNN 1h checkpoint  提供备份(fsimage+editlog)

如果有了HA,就不需要SNN了
假设11:00点,NN1挂了,NN2会在一刹那间,切换成active,对外服务.

无感知的
命名空间    nameservice1    CDH
           dw

NN节点有两个文件: fsimage editlog(读写请求记录)
SNN 用于checkpoint,合并fsimage+editlog

HA进程:  3 台机器
hadoop001:  ZK   NN     ZJFC    JN   DN

hadoop002:  ZK   NN     ZKFC    JN   DN

hadoop003:  ZK          ZKFC    JN    DN

JounalNode(实时日志记录): HDFS数据量及请求量
HDFS请求比较频繁,就要记录数据, 几十T,就搞多一点
HDFS很悠闲,搞个 7台即可. 如果机器20台,和ZK保持一致

ZKFC  手动切换

ZK集群: 做选举 (leader(active), follower(standby))

生产上节点部署:
20台节点: 5台ZK (2n+1)  奇数
20~~100台节点:  7/9/11台ZK
>100台节点:  11台ZK
但是:
1.不是说ZK节点越多越好
2.zk越多,当我们选举的时候,性能很慢

几百台节点,ZK部署的机器就它一个进程,任务很重,还有其他进程,会消耗资源,会影响ZK选举的性能.
32G / 256G
ZK是最底层的,如果ZK进程繁忙,导致不能进行选举,就不能对外提供服务
standby 如果 不能切换到 active 状态,就是ZK的问题

进程: ps -ef
线程: 存在于进程中

ZKFC: Zookeeper Failover Control (Zookeeper故障转移控制)

当我们通过Cliecnt提交我们的请求的时候,读写,通过ruozeg6 命名空间进行找去找active,找到后,在那个机器上面进行真正的请求. 读写, 此时就是HDFS的读写流程. editlog自己写一份,同时写一份都JounalNode,同时standby的NN节点,会进行重演, 此时DN会向相隔NN发送心跳和快报告.
参数和时间是多少  可以去官网找配置文件 (这两个参数去找,进行整理)

ZKFC,当一台机器挂了,通过zk进行选举,zk会通知ZKFC,切换成active状态.
ZKFC会定期向zk发送心跳.

-------------------------------------

HA是为了解决单点问题
通过JN集群共享状态
通过ZKFC选举active
监控状态,自动备援
DN: 同时向NN1 NN2发送心跳和快报告
ACTIVE NN:  操作记录写到自己的editlog,
            同时写到JN集群
            接收DN的心跳和快报告
STANDBY NN: 同时接受JN集群的日志,显式读取执行log操作(重演)
            使得自己的元数据和ACTIVE NN节点保持一致 (备份元数据)
            同时接收心跳和快报告

JounalNode: 用于ACTIVE NN 与STANDBY NN节点的 数据同步
            一般部署2n+1

ZKFC: 单独的进程
        监控NN健康状态
        向zk集群定期发送心跳,使得自己可以被选举;随时准备着
        当自己被zk选举为active的时候,zkfc进程通过RPC协议调用,使NN节点的状态变为active. 只有active状态,才能对外提供实时服务. 它是无感知的 standby状态是不行的.