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

鳄鱼儿
181 阅读7分钟

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

HDFS 高可用和高扩展机制分析

上一文章中，我们了解了HDFS的架构和读写流程。 HDFS通过将文件分块来存储大文件，HDFS的组件有NameNode和DataNode,分别负责提供元数据和数据服务 在读/写数据时，HDFS客户端需要先从NameNode上获取数据读取/写入的DataNode地址，然后和DataNode交互来完成数据读/写。

一个可以用的系统和好用的系统，差距就是高可用和高扩展性

元数据高可用

在大数据运帷中，故障是不可避免，灾难是时有发生的，如果HDFS系统不可用，那么可能无法核算广告账单，直接引发收入损失、无法生产数据报表，数据驱动无从谈起、无法进行模型训练，引起用户体验下滑等。业务停止，带来的损失极大，所以HDFS系统的高可用性就至关重要。

故障类型包括硬件故障、软件故障、人为故障

灾难是指数据中心级别不可用，如：机房断电、机房空调停机、机房网络故障或阻塞

高可用的衡量

服务可用性指标：

  • MTTR：多久恢复
  • MTTF：故障多长时间
  • MTBF：多久一次故障

可用性年化：A = MTBF/(MTBF + MTTR)

比如全年不可用时间：可用性99.9%，全年8.76小时不可用；可用性99.99% ,全年52.6分钟不可用；可用性99.999%，全年5.26分钟不可用

image-20220816110528879

高可用的形式

服务高可用：热备份、冷备份

故障恢复操作：人工切换、自动切换。

人工的反应、决策时间都更长，高可用需要让系统自动决策。HDFS的设计中，采用了中心化的元数据管理节点NameNode.NameNode容易成为故障中的单点（single point of failure）

HDFS NameNode 高可用架构

image-20220816110859335 组件介绍

  • ActiveNamenode:主节点，提供服务，生产日志。
  • StandbyNamenode:备节点，消费日志
  • Zookeeper:为自动选主提供统一协调服务
  • BookKeeper: 提供日志存储服务
  • ZKFC：NameNode探活、触发主备切换
  • HA Client：提供了自动切换的客户端
  • edit log:操作的日志

围绕三个问题来看高可用

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

状态机复制和日志

状态机复制时实现容错的常规方法

组件：状态机以及其副本、变更日志、共识协议

NameNode操作日志的生产消费

目录树和文件信息的更新

Active生产，Standby消费

物理日志与逻辑日志

  • 日志系统：高可用、高扩展性、高性能、强一致(有序) image-20220816111154977

NameNode块状态维护

DataNode向active和standby同时发送Heartbeat和Block Report。active既接收，也发起变更；standby只接收，不发起变更。

Content Stale状态：主备切换后，避免DN的不确定状态。切换后的active不能要求处于此状态的节点删除信息，需等该节点进行完一次block report后解除该状态。 image-20220816111411933

分布式协调组件 -Zookeeper

Zookeeper一般用于提供选主、协调、元数据存储

使用它的组件： HDFS、YARN、HBase Kafka、ClickHouse

HA核心机制：Watch

自动主备切换流程-Server侧

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

  • 注册节点，监控节点状态
  • 轮询探活：每个ZKFC与一个NameNode绑在一起，探知该NameNode状态
  • 脑裂问题：多节点写同一日志，导致数据不一致
  • Fence机制：阻止多节点写同一日志

image-20220816111747407

自动主备切换流程-Client侧

核心机制：StandbyException，standby节点收到client请求时，返回standbyException，节点收到该异常后给其他节点发送请求，直到发送给active

Client自动处理

BookKeeper架构

BookKeeper存储日志：

  • 低延时
  • 持久性
  • 强一致性
  • 读写高可用

对比：日志系统和文件系统的复杂度

image-20220816113018762

Quorum机制

Quorum机制就是多副本一致性读写，一般应用在多副本对象存储，用版本号标识数据新旧

BookKeeper Quorum

Sloppy Quorum机制，应用在日志场景中，顺序追加、只写

  • Write Quorum：写入副本数
  • Ack Quorum：响应副本数

BookKeeper Ensemble机制

选择策略

  • Round-Robin Load Balancer
  • 优势：数据均衡

数据存储高可用

单机存储

RAID ，即Redundant Array of Independent Disks,独立磁盘冗余阵列,具有廉价、高性能、大容量、高可用等特点 RAID有三个方案：RAID 0：条带化、RAID 1:冗余、RAID 3：容错校验

image-20220816113457463

HDFS的数据高可用

HDFS多副本- HDFS版本的RAID 1

多副本放置，同一个块数据放在多个datanode上

优势：使用checksum进行校验、读写路径简单、副本修复简单、高可用

image-20220816113719369

Erasure Coding原理-HDFS版本的RAID 2/3

业界常用Reed Solomon算法

image-20220816113919094

HDFS Erasure Coding - HDFS版本的RAID 2

image-20220816114058441 将数据划分为条带，按照条带保存EC

和多副本比较：读写速度、成本、修复速度、读写路径的实现

网络架构

Server：一台服务器

机架（Rack）：放服务器的架子

TOR（Top of Rack）:机架顶部的交换机

POD(Point Of Delivery)：数据中心中一个物理区域

数据中心（Data Center）:集中部署服务器的场所

多机房容灾

多机房解决的问题：容量问题、容灾问题

HDFS双机房放置的设计

  • 写入时，每个数据块在两个机房至少各有一个副本，数据实时写入到两个机房
  • 读取时，优先读本地的副本，避免了大量的跨机房读取

元数据高扩展性

元数据节点扩展性的挑战

HDFS NameNode是个集中式服务，部署在单个机器上，内存和磁盘的容量、CPU的计算力都不能无限扩展。

scale up：扩容单个服务器的能力

scale out：部署多个服务器来服务

存在挑战：NameSpace分裂、DataNode汇报、目录树结构本身复杂

常见的Scale Out方案

image-20220816114504597 上图的三种数据路由方式：服务器侧、路由侧、客户端侧

KV模型的系统可以使用partition，如：Redis、Kafka、MySQL(分库分表)

存储数据高扩展性

超大集群的长尾问题

延迟的分布一般用百分数来表示访问的延迟的统计特征，例如p95延迟为1ms，代表95%的请求延迟要低于1ms,但后5%的请求延迟会大于1ms

长尾延迟：尾部（p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值

木桶原理：尾部延迟放大，即访问的服务变多，尾部的请求就会越发的慢

长尾问题的表现为慢节点，即读取速度过慢，导致客户端阻塞。 慢节点的发生难以避免和预测。如在共享资源、后台维护活动、请求多级排队、功率限制；固定的损耗、机器损坏；混沌现象；下都可能发生慢结点。

离线任务也会遇到长尾问题：全部任务完成时间取决于最慢的任务什么时候完成；集群规模变大，任务的数据量变大；只要任何数据块的读取受到长尾影响，整个任务就会因此停滞

超大集群下的数据可靠性

在超大集群下，有一部分机器是损坏来不及修理的；副本放置策略完全随机；DN的容器足够大的条件下，必然有部分数据全部副本在损坏的机器上，发生数据丢失。且叠加长尾问题，容易导致整个任务无法执行下去。

Copyset方案

将DataNode分为若干个Copyset选块在copyset内部选择，减少了副本放置的组合数，从而降低副本丢失的概率

负载均衡和数据迁移

不均匀问题

  • 避免热点
  • 降低成本
  • 可靠性
  • 数据读取/写入不均匀：节点容量不均匀、数据新旧不均匀、访问类型不均匀
  • 资源负载不均匀

HDFS作为大数据离线分析场景的核心组件，高可用和高扩展性是架构设计的重中之重，高可用确保了业务能稳定运行，HDFS上存储的数据随时可用访问。高扩展性确保了HDFS能存储的数据流能随着资源投入无限扩展下去，业务发展不被基础组件拖累

avatar
文章
阅读
粉丝