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

这是我参与「第四届青训营」笔记创作活动的第5天，笔记的内容是有关青训营课程中的一个分享.

前言

本次的HDFS高可用与高扩展机制的笔记是基于已经了解了HDFS的架构和读写流程，“高可用”和“高扩展机制”就是区分一个可以使用的系统和好用的系统的点。

我的笔记是基于元数据高可用以及元数据高扩展性来进行分享的。

一、元数据高可用

1.1、高可用的需求

高可用的需求在于HDFS系统会发生故障，例如：

• 硬件故障
• 软件故障
• 认为故障

如果HDFS系统不可用的话，会发生以下一些问题：

• 无法核算广告账单，直接引发收入损失
• 无法生产数据报表，数据驱动无从谈起
• 无法进行模型训练，用户体验越来越差

以下是高可用的公式 HDFS的设计中，采用了中心化的元数据管理节点NameNode。

1.2、HDFS NameNode高可用架构

NameNode的组件有：

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

NameNode状态持久化：

1.3、HDFS自动主备切换

1.3.1、自动主备切换流程 -Server侧

ZKFailoverController是外部组件，驱动HDFS NameNode的主备切换 专门是针对以下几个问题：

1. 轮询探活
2. 脑裂问题
3. Fence机制

1.3.2、自动主备切换流程-Client侧

核心机制：StandbyException

Client自动处理

1.4、日志系统BookKeeper简介

BookKeeper存储日志

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

1.41、BookKeeper Quorum

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

二、元数据高可用

2.1 元数据节点扩展性的挑战

• 名字空间分裂
• DataNode汇报
• 目录树结构本身负责

2.2常见的Scale Out方案

KV模型的系统可以使用partition

• Redis
• Kafka
• MySQL

2.3 社区解决方案 - BlockPool

解决DN同时服务多组NN的问题

文件服务分层：

• Namespace
• Block Storage

用blockpool来区分DN的服务

2.4 社区解决方案 - viewfs

Federation架构：将多个不同集群组合起来，对外表现像一个集群一样。

下图：viewfs通过在client-side的配置，指定不同的目录访问不同的NameNode

局限性：运维复杂

结尾

这一次的内容也是有关我在青训营大项目中所做的，例如kafka，对我的帮助是非常大的，了解到了很多的解决方案。