写在前面：
下面对比hadoop1.x和hadoop2.x。目前搭建的是3.x
进入主题：
1.Hadoop1的困境：
- 单点故障
- 每个群集只有一个NameNode，NameNode存在单点故障（SPOF）。
- 如果该计算机或进程不可用，则整个群集在整个NameNode重新启动或在另一台计算机上启动之前将不可用如果发生意外事件（例如机器崩溃），则在操作员重新启动NameNode之前，群集将不可用。
- 计划内的维护事件，例如NameNode计算机上的软件或硬件升级，将导致群集停机时间的延长。
- 水平扩展
- 将来服务器启动的时候，启动速度慢
- namenode随着业务的增多，内存占用也会越来越多
- 如果namenode内存占满，将无法继续提供服务
- 业务隔离性差
- 存储：有可能我们需要存储不同部门的数据
- 计算：有可能存在不同业务的计算流程
- 项目后期namenode的吞吐量将会是集群的瓶颈
- 客户端所有的请求都会先访问NameNode
- Hadoop2.x
- NameNode节点的高可用
- HA--high availability
- NameNode业余的水平扩展
- Federation
- NameNode节点的高可用
2.Hadoop-HA
- ?2.1.设计思想
- hadoop2.x启用了主备节点切换模式（1主1备）
- 当主节点出现异常的时候，集群直接将备用节点切换成主节点
- 要求备用节点马上就要工作
- 主备节点内存几乎同步
- 有独立的线程对主备节点进行监控健康状态
- 需要有一定的选举机制，帮助我们确定主从关系
- 我们需要实时存储日志的中间件
- 2.2. ANN
- Active NameNode的功能和原理的NN的功能是一样的
- 接受客户端请求，查询数据块DN信息
- 存储数据的元数据信息
- 数据文件：Block：DN的映射关系
- 工作
- 启动时：接受DN的block汇报
- 运行时：和DN保持心跳(3s,10m30s)
- 存储介质
- 完全基于内存
- 优点：数据处理效率高
- 缺点：数据的持久化(日志edits+快照fsimage)
- 2.3. SNN
- Standby NameNode：NN的备用节点
- 他和主节点做同样的工作，但是它不会发出任何指令
- 存储：数据的元数据信息
- 数据文件：Block：DN的映射关系
- 它的内存数据和主节点内存数据几乎是一致的
- 工作：
- 启动时：
- 接受DN的block汇报
- 运行时：
- 和DN保持心跳(3s,10m30s)
- 启动时：
- 存储介质
- 完全基于内存
- 优点：数据处理效率高
- 缺点：数据的持久化
- 合并日志文件和镜像
- 当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会会默认创建????????
- fsimage_000000000000000
- 当我们操作HDFS的时候ANN会产生日志信息
- edits_inprogress_0000000000001
- 主节点会将日志文件中新增的数据同步到JournalNode集群上
- 所以只需要snn有操作的日志信息，就可以合并fsImage与edits信息,理论上是一直在合并数据
- fsimage -->初始化创建
- edits-->从JournalNode集群上定时同步
- 只要同步到edits文件，就开始于fsimage合并
- 当达到阈值的时候，直接拍摄快照即可
- SNN将合并好的Fsimage发送给ANN,ANN验证无误后，存放到自己的目录中
- 当搭建好集群的时候，格式化主备节点的时候，ANN和SNN都会会默认创建????????
- 2.4. DataNode(DN)
- 存储
- 文件的Block数据
- 介质
- 硬盘
- 启动时：
- 同时向两个NN汇报Block信息
- 运行中
- 同时和两个NN节点保持心跳机制
- 存储
- 2.5. QJM
- Quorum JournalNode Manager共享存储系统，NameNode通过共享存储系统实现日志数据同步。JournalNode是一个独立的小集群，它的实现原理和Zookeeper的一致( Paxos)
- ANN产生日志文件的时候，就会同时发送到JournalNode的集群中每个节点上
- JournalNode不要求所有的jn节点都接收到日志，只要有半数以上的（n/2+1）节点接受收到日志，那么本条日志就生效
- SNN每间隔一段时间就去QJM上面取回最新的日志
- SNN上的日志有可能不是最新的
- HA集群的状态正确至关重要，一次只能有一个NameNode处于活动状态。
- JournalNode只允许单个NameNode成为作者。在故障转移期间，将变为活动状态的NameNode将承担写入JournalNodes的角色，这将有效地防止另一个NameNode继续处于活动状态，从而使新的Active节点可以安全地进行故障转移。
- 2.6. ZKFC
- Failover Controller(故障转移控制器)
- 对NameNode的主备切换进行总体控制，能及时检测到NameNode的健康状况
- 在主NameNode故障时借助Zookeeper实现自动的主备选举和切换
- 为了防止因为NN的GC失败导致心跳受影响，ZKFC作为一个deamon进程从NN分离出来?
- ?启动时：
- 当集群启动时，主备节点的概念是很模糊的
- 当ZKFC只检查到一个节点是健康状态，直接将其设置为主节点
- 当zkfc检查到两个NN节点是的健康状态，发起投票机制
- 选出一个主节点，一个备用节点，并修改主备节点的状态
- 运行时：
- 由ZKFailoverController、HealthMonitor和ActiveStandbyElector这3个组件来协同实现主备切换
- ZKFailoverController启动的时候会创建HealthMonitor和ActiveStandbyElector这两个主要的内部组件
- HealthMonitor主要负责检测NameNode的健康状态
- ActiveStandbyElector主要负责完成自动的主备选举，内部封装了Zookeeper的处理逻辑
- 由ZKFailoverController、HealthMonitor和ActiveStandbyElector这3个组件来协同实现主备切换
- ?主备节点正常切换
- 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状态。
- 2.7. Zookeeper
- 为主备切换控制器提供主备选举支持。
- 辅助投票
- 和ZKFC保持心跳机制，确定ZKFC的存活
- 2.8.脑裂brain-split
- 定义
- 脑裂是Hadoop2.X版本后出现的全新问题，实际运行过程中很有可能出现两个namenode同时服务于整个集群的情况，这种情况称之为脑裂。
- 原因
- 脑裂通常发生在主从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。
- (c)如果这时原来的active（比如GC）恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。
- 解决方案
- ActiveStandbyElector为了实现fencing，当NN成为ANN之后创建Zookeeper临时节点ActiveStandbyElectorLock，创建ActiveBreadCrumb的持久节点，这个节点里面保存了这个Active NameNode的地址信息(node-01)
- Active NameNode的ActiveStandbyElector在正常的状态下关闭Zookeeper Session的时候，会一起删除这个持久节点
- 但如果ActiveStandbyElector在异常的状态下关闭，那么由于/hadoopha/${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状态，开始对外提供服务。
- 定义
3. Hadoop-Federation? ? ? ??
- HDFS Federation就是使得HDFS支持多个命名空间，并且允许在HDFS中同时存在多个NameNode。
- 3.1.单NN局限性
- Namespace（命名空间）的限制
- NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。
- 50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，12PB的存储
- DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。
- 性能的瓶颈
- 整个HDFS文件系统的吞吐量受限于单个Namenode的吞吐量
- 隔离问题
- HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序
- 集群的可用性?
- Namenode的宕机无疑会导致整个集群不可用。
- Namespace和Block Management的紧密耦合
- 纵向扩展目前的Namenode不可行
- 将Namenode的Heap空间扩大到512GB启动花费的时间太长
- Namenode在Full GC时，如果发生错误将会导致整个集群宕机
- Namespace（命名空间）的限制
- 3.2. Federation
- ?块池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/namespace把元数据的存储和管理分散到多个节点中
- 降低单个节点数据压力,计算压力
- namenode/namespace可以通过增加机器来进行水平扩展
- 可以让更多的节点参与到运算
- namespace命名空间，通过这种方式确定要处理数据的路径
- 我们可以通过namenode和namespace组合使用
- 所有的nn共享dn
- 但是每一个namespace会单独管理自己的块
- 会创建一个管理块的机制：blocks pool
完毕。?
