HDFS 高可用和高扩展机制分析 | 青训营笔记

阿韩很菜
87 阅读9分钟

HDFS 高可用和高扩展机制分析 | 青训营笔记

这是我参与「第四届青训营 」笔记创作活动的的第9天，本篇笔记主要是关于第九次大数据课程《HDFS 高可用和高扩展机制分析》的课堂笔记

元数据服务高可用

高可用：系统在困境（adversity，比如硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）

故障度量的指标

  • MTTR（Mean Time To Repair）：平均修复时间，系统能多快恢复。
  • MTTF（Mean Time To Failure）：平均失效时间，运行到故障间的时间，一般用于不可修复的系统（制造业）。

  • MTBF（Mean Time Between Failures）：平均无故障时间，两次故障间的间隔，一般用于可修复的系统（软件）。 备份方式：

  • 冷备份：备份服务的数据，可以和数据归档相结合。在主服务故障时，利用备份的数据重启。

  • 热备份：主服务和备服务同时运行，在主服务故障时，随时可以切换到备服务。

切换方式：

  • 人工切换：在故障发生时，运维人员接收报警后，手动执行服务切主操作。一般较慢，难以满足全年不可用时间的目标。
  • 自动切换：通过探活组件、分布式共识协议等手段，系统能自动发现主服务的故障，并切换到备份不符。

HDFS高可用架构：

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

image.png 整体流程：Active NameNode为主备中的主，负责处理client发来的请求，处理的结果信息会放到edit log里，放在日志系统BooKeeper上，Standby会消费保存的这个日志信息，目的是与Active NameNode保持同步，在Active NameNode出问题时才能切换，DataNode与两边NameNode都要上报。

状态机复制模型： 实现容错服务的一种常规方法，主要通过复制服务器，并协调客户端和这些服务器镜像间的交互来达到目标。这个方法也同时提供了理解和设计复制管理协议的一套基本框架。

NameNode操作日志的生产消费

image.png 日志系统： 1. 高可用 2. 高扩展性 3. 高性能 4. 强一致(有序)

物理日志：存储了物理单元（一般是磁盘的 page）变更的日志形式。

逻辑日志：存储了逻辑变更（例如 rename /a to /b）的日志形式。

HDFS 主备切换

  • DataNode 心跳与块汇报需要同时向 active NN 和 standby NN 上报，让两者可以同时维护块信息。但只有 active NN 会下发 DN 的副本操作命令。

  • content stale 状态：在发生主备切换后，新 active NN 会标记所有 DN 为 content stale 状态，代表该 DN 上的副本是不确定的，某些操作不能执行。直到一个 DN 完成一次全量块上报，新 active NN 才标记它退出了 content stale 状态。

    • 例子，多余块的删除：NN 发现某个块的副本数过多，会挑选其中一个 DN 来删除数据。在主备切换后，新 active NN 不知道旧 active NN 挑选了哪个副本进行删除，就可能触发多个 DN 的副本删除，极端情况下导致数据丢失。content stale 状态的引入解决了这个问题。
  • 脑裂问题：因为网络隔离、进程夯住（例如 Java GC）等原因，旧的 active NN 没有完成下主，新的 active NN 就已经上主，此时会存在双主。client 的请求发给两者都可能成功，但不能保证一致性（两个 NN 状态不再同步）和持久化（只能保留一个 NN 状态）。
  • fence 机制：在新 active NN 上主并正式处理请求之前，先要确保旧 active NN 已经退出主节点的状态。一般做法是先用 RPC 状态检测，发现超时或失败则调用系统命令杀死旧 active NN 的进程。

分布式协调组件——ZooKeeper： 一般用于提供选主、协调、元数据存储

  • HA核心机制： Watch 机制，允许多个 client 一起监听一个 znode 的状态变更，并在状态变化时收到一条消息回调（callback）。 高可用日志系统 BookKeeper：

image.png

  • 高可靠：数据写入多个存储节点，数据写入就不会丢失。
  • 高可用：日志存储本身是高可用的。因为日志流比文件系统本身的结构更为简单，日志系统高可用的实现也更为简单。
  • 强一致：日志系统是追加写入的形式，Client 和日志系统的元数据可以明确目前已经成功的写入日志的序号（entry-id）。
  • 可扩展：整个集群的读写能力可以随着添加存储节点 Bookie 而扩展。

Quorum机制： 多副本一致性读写

  • 多副本间一般通过 version-id 来描述状态的新旧。
  • 高可用：多个副本确保了高可用。
  • 高性能：不用等所有副本写入成功，降低了的长尾延迟。 BookKeeper Quorum 协议：基于 Quorum 的多数派思想来提供高可用、高性能写入的日志写入
  • 日志写入是追加，不是状态变更，只需要确认目前的 entry-id，相对更简单。
  • Ensemble：通过轮询（Round-Robin）来确认 write quorum（一次写入需要写入到的存储节点数） 实际对应的存储节点实例，可以比较简单的完成副本放置和扩展。

数据存储高可用

RAID： 将多个廉价、不可靠、低性能、容量小的磁盘组装在一起，提供高可靠、高性能、大容量逻辑磁盘服务的一组磁盘列阵方案。

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

image.png HDFS多副本方案： 将数据块存储在多个 DN 上

Erasure Coding 方案： 将数据分段，通过特殊的编码方式存储额外的校验块，并条带化的组成块，存储在 DN 上。

  • 读写速度更快：并行读取几个DataNode
  • 条带化：原本块对应文件内连续的一大段数据。条带化后，连续的数据按条带（远小于整个块的单位）间隔交错的分布在不同的块中。
  • 成本更低：多副本方案需要冗余存储整个块，EC 方案需要冗余存储的数据一般更少。

image.png

初识网络架构

Server：一台服务器
机架(Rack)：放服务器的架子。
TOR(Top of Rack)：机架顶部的交换机。
POD(Point of Delivery)：数据中心中的一个物理区域
数据中心(Data Center)：集中部署服务器的场所

多机房容灾：服务和数据需要存放在多个机房，并配合合理的架构。使得发生机房故障时依然可以提供服务。

元数据高扩展性：

扩展性方案：

  • scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。
  • scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。 federation 架构：
  • 使得多个集群像一个集群一样提供服务的架构方法，提供了统一的服务视图，提高了服务的扩展性。
  • 文件系统的目录树比 kv 模型更复杂，划分更困难。
  • 邦联架构的难点一般在于跨多个集群的请求，例如 HDFS 的 rename 操作就可能跨多个集群。 viewfs：
  • 邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。
  • 缺点：客户端配置难以更新（需要重启多个集群）、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）。 小文件问题
  • HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。
  • 数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。
  • 计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。
  • 解决措施：

    1. 小文件合并任务：计算框架的数据访问模式确定，可以直接将小文件合并成大文件而任务读取不受影响。通过后台运行任务来合并小文件，可以有效缓解小文件问题。通过 MapReduce/Spark 框架，可以利用起大量的机器来进行小文件合并任务。

    2. Shuffle service：shuffle 流程的中间文件数是平方级的，shuffle service 将 shuffle 的中间数据存储在独立的服务上，通过聚合后再写成 HDFS 文件，可以有效地缓解中间数据的小文件问题。

存储数据高扩展性

尾部延迟放大

  • 木桶原理：并行执行的任务的耗时取决于最慢的一个子任务。
  • 尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢。一个请求或任务需要访问多个数据节点，只要其中有一个慢，则整个请求或任务的响应就会变慢。 长尾问题的表现-慢节点：读取速度过慢，导致客户端阳墨。

copyset

  • 降低副本放置的组合数，降低副本丢失的发生概率。
  • 缺点：DN 机器故障时，只能从少量的一些其他 DN 上拷贝数据修复副本。

数据均衡：避免热点

  • 机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。
avatar
文章
阅读
粉丝