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

SunriseXue
95 阅读4分钟

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

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

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

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

元数据高可用

服务高可用的需求

在我们的日常大数据服务器维护中，故障是不可能避免的，如果HDFS系统不可用，那么就无法核算广告账单、无法生产数据报表、无法进行模型训练等，业务停止的损失极大，所以HDFS系统的高可用性就至关重要

高可用的衡量

可以直接用一张表说明

image.png

高可用的形式

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

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

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

HDFS NameNode 高可用架构

组件介绍：

  • ActiveNamenode:主节点，提供服务，生产日志。

  • StandbyNamenode:备节点，消费日志

  • Zookeeper:为自动选主提供统一协调服务

  • BookKeeper: 提供日志存储服务

  • ZKFC：NameNode探活、触发主备切换

  • HA Client：提供了自动切换的客户端

  • edit log:操作的日志

image.png

NameNode块状态维护

ACtive 即接收，也发起变更 Standby只接收，不发起变更

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

image.png

分布式协调组件 -Zookeeper

Zookeeper一般用于提供选主、协调、元数据存储 使用它的组件： HDFS、YARN、HBase Kafka、ClickHouse

HA核心机制：Watch

BookKeeper架构

BookKeeper存储日志：

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

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

image.png

Quorum机制

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

数据存储高可用

回到单机存储

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

网络架构

机架（Rack）：放服务器的架子 TOR（Top of Rack）:机架顶部的加环己 数据中心（Data Center）:集中部署服务器的场所

元数据高扩展性

元数据节点扩展性的挑战

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

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

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

常见的Scale Out方案：

image.png

存储数据高扩展性

超大集群的长尾问题

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

长尾延迟：尾部（p99/p999/p999)的延迟，衡量系统最差的请求的情况。会显著的要差于平均值 由于木桶原理，会发生尾部延迟放大，即访问的服务变多，尾部的请求就会越发的慢

具体表现为慢节点，即读取速度过慢，导致客户端阻塞。 满节点的发生难以避免和预测，同样的，离线任务也会遇到长尾问题

Copyset

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

负载均衡和数据迁移的典型场景

image.png

结语

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

avatar
文章
阅读
粉丝