HDFS：HA模式

写的不到位的地方，欢迎评论指出不足之处

 主从集群

• 优点
  • 结构相对简单、主与从协作
  • 主：单点、数据一致好掌握
•  缺点
  • 两个独立的问题
    •  问题一：单点故障、集群整体不可用
      • 主只有一个，当主出现故障后，从将不可用，导致整个集群无法工作
    •  问题二：主压力过大、内存受限
      • 主只有一个，从有数百台之多，都需要主来维持工作时，压力就过大。如果自身内存小，将无法按时工作（如延迟），只能排队工作，导致某些工作不能实时传送

---

HDFS 解决方案分析

• 分析一：单点故障
  •  HA 模式：High Availablity （高可用）
    • 多个 NameNode、主备切换
    •  Hadoop 2.X 只支持 HA 的一主一备
    •  Hadoop 3.X 支持上限5个备，官方推荐3个备
• 分析二：主压力过大、内存受限
  • 联邦机制：Federation （元数据分片）
  •  多个 NameNode、管理不同的元数据 
• 注：
  • 两个解决方案都涉及到多个 NameNode ，但其作用不一样，所以不能混肴

---

图解

• HDFS Client 上传文件
• NameNodeActive（主）存储了文件的元数据，并指定文件真实数据应存到哪个 DataNode 中，并决定切割多少块以及多少副本
• DataNode 处理后会向 NameNodeActive 和 NameNodeStandby 传送 Block 的相关信息
• 但是 NameNodeStandby 中没有相关的元数据信息，因此就涉及到 NameNode 主从之间的数据同步问题
• 旧方案（仍存在问题）
  • 同步且阻塞

    • HDFS Client 上传文件到 NameNodeActive(主) 处理成功后，再由主传递给 NameNodeStandby（从）处理成功后，再告知主，NameNodeStandby（从）已处理完毕，最后再由 NameNodeActive(主)  告知 HDFS Client 处理完毕

    • 问题

      • 当 NameNodeActive(主) 处理成功后，传递给 NameNodeStandby（从）时，从此时的状态为延迟或是挂掉，导致主长时间无响应时。其结果为，主从并没有同步成功，主处理成功但却传递客户端是未成功，破坏了对外的可用性（强一致性）

  • 民步且阻塞
    • HDFS Client 上传文件到 NameNodeActive(主) 处理成功后，再由主传递给 NameNodeStandby（从），主直接传递给客户端处理成功，至于从自行处理
    • 问题
      • 当主无法运行时，需要切换从的时候，但从之前因某种原因并没有进行处理。其结果为，HDFS Client  所获得的数据信息是不准确的
• 新方案（追加新技术）
  • JournalNode （为了同步数据）
    • 多台 JournalNode 在正常运行的情况下，存储数据的版本号为最新，或多台版本号都是最新，则通过自身的随机ID进行比较，最后决定哪一台是主
    • HDFS Client 上传文件到 NameNode(主) 处理成功后 ，向 JNode（主）传递数据
    • JNode（主）向 JNode（从）传递数据
    • 当多台 JNode 正常接收数据占一半以上时，NameNode（主）向 HDFS Client 发送处理完毕
      • 如选举，大于等于3台，负责同步 NameNode 的 Editlog，最终一致性
    • NameNode（从）可随时向 JNode（主）获取数据 
    • 若此时 JNode（主）挂掉，则剩余（正常存活） JNode 重新决定哪一台是主
    • 以保证 NameNode 主从之间的数据同步
  • ZooKeeper  （ZK）（为了自动切换 NameNode 的主从角色）
    • NameNode （主/从）的节点上，都会在本机当中存在一个 ZKFailoverController （ZKFC），独立的进程
    • 四种处理情况
      • 一
        • ZKFC的第一作用：实时监控本机的 NameNode 是否存活
        • ZKFC的第二作用：在 ZK 中进行抢锁，抢到锁即哪台是 NameNode（主）
      • 二
        • 当 NameNode（主） 挂掉后，ZKFC 会在 ZK 中把自己抢的锁删掉
        • ZK 会触发事件机制，回调机制
          • 由于之前 ZKFC 在抢锁时都注册了自己的回调信息，所以向 ZKFC（其它） 发送可以进行抢锁，ZKFC（原）不再抢锁，因为 NameNode 已经挂掉了
        • ZKFC的第三作用：抢到锁的 ZKFC 会先向之前的 NameNode（主）进行访问，若无法请问，才会将 NameNode（从）改变成主，主要为了严谨防止异常情况
      • 三
        • 当 NameNode（主）正常运行，但是本机的 ZKFC（主）进程挂掉了
        • 抢到的锁属于临时锁，ZKFC 与 ZK 有连接，锁一直存在，若连接中断，则锁会自行删除
        • ZK 会触发事件机制，ZKFC（其它）抢到锁后，为防止 NameNode（主）挂掉，从而将主切换为从
      • 四
        • 出现概率低，通常运维问题
        • NameNode、JNode、DataNode、本机的 ZKFC 互相能都通信，ZKFC 与 ZK 能通信，但其它节点的 ZKFC 无法与其它 NameNode 通信
          • ZKFC的第三作用，向之前的 NameNode（主）进行通信，其结果失败
          • ZKFC（从）访问 NameNode（主）是否正常，此时就无法连接访问

        • 此时无法判定 NameNode（主）是否正常 、还是自身网络问题，因此 NameNode（主\从）就无法进行切换，其结果就是循环报错

        • 解决（例如）

          • 每台机子安装了九针串口，连接到其它机子的电源模块上

          • ZKFC（从）不再通过网络进行访问，而是直接通过串口，发送命令将目标机直接关机

          • 此时 ZKFC（从）就可放心的将 NameNode（从）改为主

• 注

  • 通过 ZK 集群协调 NN 的主从选举和切换事件回调机制

  • DataNode 同时向 NameNode（从） 汇报 Block 清单

  • 在HA模式中没有 SecondaryNameNode 角色（日志合并）

  • NameNodeStandby 角色不对外提供服务， 从 JNode 获取最新数据后，周期性生成 FsImage，将生成后的 FsImage 推送给 Active 角色，使 NameNodeActive 角色将来启动时更有效率

  • HA 模式 NameNodeStandby 实时取回数据，非HA模式下每间隔一段时间发送64MB

  • SNN（非HA模式）与版本无关

HDFS-Federation（联邦机制）

• 元数据分治，复用 DataNode 存储

  • 多个 NameNode 存储元数据，都会存储在 DataNode

• 元数据访问隔离性

  • 每个 NameNode 存储的元数据都不同（如：A：人事部、B：财务部、C：业务部）

• DataNode 目录隔离 Block

  •  对于多个 NameNode 存储不同元数据后，Block 存储在 DataNode 中时，会针对 NameNode 创建对应的目录，实现隔离

    • 相当于在 DataNode 中创建了多个对应 NameNode 的目录，然后在相应的目录下，存储相应的 Block

标签：HDFS,NameNodeStandby,JNode,模式,DataNode,NameNode,HA,ZKFC
来源： https://blog.csdn.net/lian582796149/article/details/118343140