HDFS高可用与高扩展机制分析|青训营笔记这是我参与「第四届青训营」笔记创作活动的的第9天，本节课讲述了HDFS高可用

这是我参与「第四届青训营」笔记创作活动的的第9天

元数据高可用
- 故障不可避免，灾难时有发生
  - 故障类型
    - 硬件故障
    - 软件故障
    - 人为故障
  - 灾难:数据中心级别不可用
    - 机房断电
    - 机房空调停机
    - 机房网络故障、阻塞
- 高可用的衡量
  - MTTR
    - 多久恢复
  - MTTF
    - 故障多长时间
  - MTBF
    - 多久一次故障
  - 年化
    - A = MTBF/(MTBF + MTTR)
- 高可用的形式
  - 服务高可用
    - 热备份
      - 有相同服务跑着
    - 冷备份
      - 将数据备份，在其他服务上重启
  - 故障恢复操作
    - 人工切换
    - 自动切换
  - HDFS的设计中，采用了中心化的元数据管理节点NameNode,容易成为故障中的单点
- HDFS NameNode高可用架构
  - 组件介绍
    - ActiveNameNode
      - 主节点，提供服务，生产日志
    - StandbyNameNode
      - 备节点，消费日志
    - ZooKeeper
      - 为自动选主提供统一协调服务
    - BookKeeper
      - 提供日志存储服务
    - ZKFC
      - NameNode探活、触发主备切换
    - HA Client
      - 提供了自动切换的客户端
    - edit log
      - 操作日志
  - 围绕三个问题来看高可用
    - 节点状态如何更新
    - 操作日志如何同步
    - 如何做到自动切换
  - 理论基础
    - 状态机复制和日志
      - 状态机复制时实现容错的常规方法
      - 组件
        
        状态机以及其副本
        
        变更日志
        
        共识协议
  - NameNode操作日志的生产消费
    - 目录树和文件信息的更新
    - Active生产，Standby消费
    - 物理日志与逻辑日志
    - 日志系统
      - 高可用
      - 高扩展性
      - 高性能
      - 强一致(有序)
  - NameNode块状态维护
    - DataNode向active和standby同时发送Heartbeat和Block Report
      - active既接收，也发起变更
      - standby只接收，不发起变更
    - Content Stale状态
      - 主备切换后，避免DN的不确定状态
      - 切换后的active不能要求处于此状态的节点删除信息，需等该节点进行完一次block report后解除该状态
  - 分布式协调组件
    - ZooKeeper
      - 一般用于提供选主、协调、元数据存储等功能
      - 使用它的组件
        
        HDFS、YARN、HBase
        
        Kafka、ClickHouse等
      - HA核心机制
        
        WATCH
        
        多副本存储数据，节点发生改变时通知系统
  - 自动主备切换流程
    - Server侧
      - ZKFailoverController
        
        作为外部组件，驱动HDFS NameNode的主备切换
        
        注册节点，监控节点状态
        
        轮询探活
        
        每个ZKFC与一个NameNode绑在一起，探知该NameNode状态
        
        脑裂问题
        
        多节点写同一日志，导致数据不一致
        
        Fence机制
        
        阻止多节点写同一日志
    - Client侧
      - 核心机制
        
        StandbyException
        
        standby节点收到client请求时，返回standbyException，节点收到该异常后给其他节点发送请求，直到发送给active
      - Client自动处理
- BookKeeper架构
  - BookKeeper存储日志
    - 低延时
    - 持久性
    - 强一致性
    - 读写高可用性
  - Quorum机制
    - 多副本一致性读写
    - 场景
      - 多副本对象存储，用版本号标识数据新旧
  - BookKeeper Quorum
    - Sloppy Quorum
      - 日志场景
        
        顺序追加、只写
      - Write Quorum
        
        写入副本数
      - Read Quorum
        
        响应副本数
  - BookKeeper Ensemble机制
    - 选择策略
    - Round-Robin Load Balancer
    - 优势
      - 数据均衡
数据存储高可用
- 单机存储的数据高可用
  - RAID
    - 廉价、高性能、大容量、高可用
    - RAID 0
      - 条带化
    - RAID 1
      - 冗余
    - RAID 3
      - 容错校验
- HDFS的数据高可用
  - 多副本放置，同一个块数据放在多个datanode上
    - 使用checksum进行校验
    - 读写路径简单
    - 副本修复简单
    - 高可用
  - Erasure Coding原理
    - 业界常用Reed Solomon算法
    - HDFS Erasure Coding
      - 将数据划分为条带，按照条带保存EC
      - 和多副本比较
        
        读写速度
        
        成本
        
        修复速度
        
        读写路径的实现
- 考虑网络架构的数据高可用
  - 基本概念
    - Server
      - 一台服务器
    - 机架(Rack)
      - 放服务器的架子
    - TOR(Top Of Rack)
      - 机架顶部的交换机
    - POD(Point Of Delivery)
      - 数据中心中一个物理区域
    - 数据中心(Data Center)
      - 集中部署服务器的场所
  - 副本放置策略
    - 机架感知
      - 一个TOR故障导致整个机架不可用vs降低跨rack流量
      - trade-off
        
        一个本地、一个远端
- 多机房容灾
  - 多机房解决的问题
    - 容量问题
    - 容灾问题
  - HDFS双机房放置的设计
    - 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房
    - 读取时，优先读本地的副本，避免了大量的跨机房读取
  - 容灾实践
    - 多机房部署的组件
      - ZooKeeper
      - BookKeeper
      - NameNode
      - DataNode
    - 容灾期间的策略
      - 容灾期间，限制跨机房写入
      - 容灾期间，限制跨机房副本复制
元数据高扩展性
- 元数据扩展性挑战
  - HDFS NameNode是集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展
  - scale up vs. scale out
    - 扩容单个服务器的能力
    - 部署多个服务器来服务
  - 挑战
    - NameSpace分裂
    - DataNode汇报
    - 目录树结构本身复杂
  - 常见的scale out方案
    - KV模型的系统可以使用partition
      - Redis
      - Kafka
      - MySQL(分库分表)
    - 三种数据路由方式
      - 服务器侧
      - 路由侧
      - 客户端侧
- 社区解决方案
  - BlockPool
    - 解决DN同时服务多组NN的问题
      - 同一个block id在不同的NN上出现
    - 文件服务分层
      - NameSpace
      - Block Storage
    - 用blockpool来区分DN的服务
      - 数据块存储
      - 心跳和块上报
  - viewfs
    - Federation架构
      - 将多个不同集群组合起来，对外表现像一个集群一样
    - viewfs通过在client-side的配置，指定不同的目录访问不同的NameNode
    - 局限性
      - 运维复杂
- 字节跳动NNProxy
  - 自研的HDFS代理层，提供了路由服务
  - 主要实现了路由管理和PRC转发
    - 以及鉴权、限流、查询缓存等额外能力
  - 路由规则保存
    - 使用zookeeper存储路由信息，每隔一段时间更新信息
  - 路由转发实现
    - 路径最长匹配规则，可以进一步划分目录树
- 案例
  - 小文件问题
    - 大小不到一个HDFS Block大小的文件过多
      - NameNode瓶颈
      - I/O变成小的随机IO，数据访问变慢
      - 计算任务启动慢
    - mapreduce的worker数量过多容易引起小文件问题
    - 解决方案
      - 后台任务合并小文件
      - Shuffle Service
数据存储高扩展性
- 长尾问题
  - 尾部的延迟，衡量系统最差的请求的情况。会显著的差于平均值
  - 木桶原理
    - 尾部延迟放大
      - 访问的服务变多，尾部的请求就会越发的慢
  - 慢节点
    - 读取速度过慢，导致客户端堵塞
  - 慢节点的发生难以避免和预测
    - 共享资源、后台维护活动、请求多级排队、功率限制
    - 固定的损耗、机器损坏
    - 混沌现象
  - 离线任务也会遇到长尾问题
    - 全部任务完成时间取决于最慢的任务什么时候完成
    - 集群规模变大，任务的数据量变大
    - 只要任何数据块的读取受到长尾影响，整个任务就会因此停滞
- 可靠性问题
  - 必然有部分数据全部副本在损坏的机器上，发生数据丢失
  - 叠加长尾问题，容易导致整个任务无法执行下去
  - Copyset
    - 将DataNode分为若干个Copyset选块在copyset内部选择
    - 减少了副本放置的组合数，从而降低副本丢失的概率
- 不均匀问题
  - 避免热点
  - 降低成本
  - 可靠性
  - 数据读取/写入不均匀
    - 数据的不均匀
      - 节点容量不均匀
      - 数据新旧不均匀
      - 访问类型不均匀
    - 资源负载不均匀
- 数据迁移工具
  - 跨NN迁移
    - DistCopy
      - 基于MapReduce，通过一个个任务，将数据从一个NameNode拷贝到另一个NameNode
      - 需要拷贝数据，流量较大，速度较慢
    - FastCopy
      - 开源社区的无需拷贝数据的快速元数据迁移方案
      - 前提条件
        
        新旧集群的DN列表吻合
      - 对于元数据，直接复制目录树的结构和块信息
      - 对于数据块，直接要求DataNode从源Block Pool hardlink到目标Block Pool，没有数据拷贝
      - hardlink
        
        直接让两个路径指向同一块数据
  - Balancer
    - 工具向DataNode发送迁移命令，平衡各个DataNode的容量
    - 场景
      - 单机房使用、多机房使用
      - 限流措施
    - 评价标准
      - 稳定性成本
      - 可运维性
      - 执行效率