HDFS 高可用与高扩展性机制分析 ｜ 青训营笔记

团鱼
335 阅读5分钟

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

HDFS通过将文件分块来存储大文件，HDFS的组件有NameNode和DataNode，分别负责提供元数据和数据服务。

在读/写数据时，HDFS客户端需要先从NameNode上获取数据读取/写入的DataNode地址，然后和DataNode交互来完成数据读/写

1. 元数据高可用

1.1 高可用的需求

  • 故障类型：硬件/软件/人为
  • 灾难：数据中心级别不可用；比如机房断电，空调停机，机房之间的网络故障或者拥塞

故障不可避免，灾难时有发生

  • 服务可用性指标：

    • MTTR：故障恢复时间
    • MTTF：平均无故障时间
    • MTBF：两次故障时间

  • 可用性:A=MTBF(MTBF+MTTR)\frac{MTBF}{(MTBF+MTTR)}

  • 形式：热备份/冷备份；一般故障恢复是人工切换和自动切换

1.2 HDFS 的高可用架构

组件介绍：

  • Active NameNode：提供服务的 NameNode 主节点，提供服务，生产 editlog。
  • Standby NameNode：不提供服务，起备份作用的 NameNode 备节点，消费 editlog
  • editlog：用户变更操作的记录，具有全局顺序，是 HDFS 的变更日志。
  • ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。为自动选主提供统一协调服务
  • BookKeeper：开源的日志存储组件，存储 editlog
  • ZKFC：和 ZK、NN 通信，进行 NN 探活和自动主备切换。
  • HA Client：处理 StandbyException，在主备节点间挑选到提供服务的主节点。

三个问题

  1. 节点状态如何更新
  2. 操作日志如何同步
  3. 如何做到自动切换

理论基础

  • 状态机复制和日志：实现容错的常规方法

    • 状态机及其副本，变更日志，共识协议

  • 操作日志的生产消费：active生产，standy消费

  • 块状态维护：active既接收也发起变更；standy消费只接受，不发起变更；

    • Content State状态：主备切换后避免DN的不确定状态

1.3 自动主备切换——zooKeeper

一般提供选主，协调、元数据

  • watch：允许多个 client 一起监听一个 znode 的状态变更，并在状态变化时收到一条消息回调（callback）

  • server侧：ZKFailoverController作为外部组件，驱动HDFS NameNode的主备切换

    • 处理方式：轮训探活，避免脑裂，fence机制（阻止多个节点写同样的日志）

  • client侧：StandbyException，Client自动处理

1.4 高可用日志系统 BookKeeper 简介

Apache bookkeeper是一个分布式，可扩展，容错（多副本），低延迟的存储系统，其提供了高性能，高吞吐的存储能力。Bookkeeper实现了append方式的写操作。

  • Quorum协议：多副本一致性读写，基于鸽巢原理（读和写的数目加起来超过副本数），在多个副本间确保高可用、高性能的多副本变更协议。

    • 场景：多副本对象存储，用版本号表示数据新旧；鸽巢原理

  • Ensemble机制：轮询机制，为了维护数据的均衡

2. 数据高可用

2.1 单机存储的数据高可用机制

  • RAID 0 ：将数据分块后按条带化的形式分别存储在多个磁盘上，提供大容量、高性能。
  • RAID 1：将数据副本存储在多个磁盘上，提供高可靠。
  • RAID 3：在数据分块存储的基础上，将数据的校验码存储在独立的磁盘上，提供高可靠、高性能。

2.2 HDFS 的数据高可用机制

  1. 多副本：将数据块存储在多个 DN 上
    • 优点：读写路径简单，副本修复简单，高可用
  2. Erasure Coding 方案（纠删码）：将数据分段，通过特殊的编码方式存储额外的校验块，并条带化的组成块，存储在 DN 上。

2.3 考虑网络架构的数据高可用

机架感知：只产生一份跨rack（机架）的流量

2.4 案例：字节跳动的 HDFS 多机房实践

多机房能够解决容量问题和容灾问题

3.元数据扩展性

3.1 元数据扩展性的挑战

  • 扩容单个服务器的能力 Scale up
  • 部署多个服务器来服务 Scale out
    • kv模型可以使用分区partition
  • 挑战：名字空间分裂；DN回报；目录树结构本身复杂

3.2 社区解决方案

  • BlockPool:解决DN同时服务多组NN的问题;同一个block id在不同的NN出现
    • 文件服务分层：Namespace；Block Storage
    • 用blockpool来区分DN的服务：数据块存储；心跳和块上报
  • viewfs：将多个不同集群组合起来，对外表现得像一个集群一样；指定不同的目录访问不同的NameNode

3.3 Proxy 方案介绍

NNProxy实现路由管理和RPC转发，以及鉴权，限流，查询缓存等额外能力

  • 路由转发实现：使用路由树功能

3.4 案例：小文件问题

  • 定义：大小不到一个HDFS Block大小的文件过多,会成为NN的瓶颈，I/O变成小的随机IO，数据访问变慢；计算任务启动慢
  • 引发：MapREduce的worker数量过多
  • 解决方案：后台任务合并小文件；shuffle service

4. 数据扩展性（P46-P59）

超大集群的长尾问题

  • p95的延迟为1s：95%的请求延迟要低于1ms
  • 长尾延迟：尾部的延迟，衡量系统最差请求的情况
  • 木桶原理，访问的服务变多，尾部的请求就会越发地慢
  • 表现：慢节点 超大集群的可靠性问题
  • 必然会有部分数据全部副本在损坏的数据上，发生数据丢失，再叠加长尾延迟，问题加剧
  • 解决方法：copyset将DN分为若干个Copyset选快，减少副本防止的组合数，减少数据丢失的概率。 超大集群的不均匀问题
  • 意义：避免热点，可靠性，降低成本
  • 数据分布不均导致慢节点问题
  • 解决方式：数据迁移工具
    • DistCopy
    • FastCopy
    • Balancer
avatar
文章
阅读
粉丝