为什么要用集群?
企业里面,多台机器 伪分布式 每一个角色都是一个进程
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状态是不行的.
