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

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

​

一、元数据高可用

高可用的需求

故障类型：硬件故障、软件故障、人为操作不当、机房断电、机房空调停机、机房网络拥塞

可用性：99.9%，全年8.76小时不可用；99.99%，全年52.6分钟不可用；99.999%，全年5.26分钟不可用（难度高）

HDFS高可用架构

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

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 的进程。

日志系统BookKeeper简介

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

二、数据存储高可用

RAID方案

多副本方案

数据中心架构

机架/机柜：将几个服务器统一供电、提供对外网络的固定的物理设备。TOR top of rack：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信。机房和数据中心都是指大量服务器集中放置的场所。

机房：强调的基础设施建设，例如物理承重、空调、防水、消防。数据中心：强调机房的业务属性。

网络拓扑：按数据中心->机架->机器的顺序，描述进程在网络空间中所处的位置。跨机房专线：由网络服务商提供，连接机房的专用网络。

稳定性和安全性好于公网。相比于数据中心内网络，吞吐更为有限、延迟更高、成本更高。

三、元数据高扩展性

扩展性方案

scale up：通过单机的 CPU、内存、磁盘、网卡能力的提升来提升系统服务能力，受到机器成本和物理定律的限制。scale out：通过让多台机器组成集群，共同对外提供服务来提升系统服务能力。一般也称为高扩展、水平扩展。

partition 方法

水平分区和垂直分区：水平分区指按 key 来将数据划分到不同的存储上；垂直分区指将一份数据的不同部分拆开存储，用 key 关联起来。partition 一般都水平分区，又称 shard。常用于 KV 模型，通过 hash 或者分段的手段，将不同类型 key 的访问、存储能力分配到不同的服务器上，实现了 scale out。重点：不同单元之间不能有关联和依赖，不然访问就难以在一个节点内完成。例如 MySQL 的分库分表方案，难以应对复杂跨库 join。

federation 架构

使得多个集群像一个集群一样提供服务的架构方法，提供了统一的服务视图，提高了服务的扩展性。文件系统的目录树比 kv 模型更复杂，划分更困难。邦联架构的难点一般在于跨多个集群的请求，例如 HDFS 的 rename 操作就可能跨多个集群。

blockpool

将文件系统分为文件层和块存储层，对于块存储层，DN 集群对不同的 NN 提供不同的标识符，称为 block pool。解决了多个 NN 可能生成同一个 block id，DN 无法区分的问题。

viewfs

邦联架构的一种实现，通过客户端配置决定某个路径的访问要发送给哪个 NN 集群。缺点：客户端配置难以更新、本身配置方式存在设计（例如，只能在同一级目录区分；已经划分的子树不能再划分）。

NNProxy

ByteDance 自研的 HDFS 代理层，于 2016 年开源，项目地址：​​github.com/bytedance/n…​​主要提供了路由管理、RPC 转发，额外提供了鉴权、限流、查询缓存等能力。开源社区有类似的方案 Router Based Federation，主要实现了路由管理和转发。

小文件问题

HDFS 设计上是面向大文件的，小于一个 HDFS Block 的文件称为小文件。元数据问题：多个小文件相对于一个大文件，使用了更多元数据服务的内存空间。数据访问问题：多个小文件相对于一个大文件，I/O 更加的随机，无法顺序扫描磁盘。计算任务启动慢：计算任务在启动时，一般会获得所有文件的地址来进行 MapReduce 的任务分配，小文件会使得这一流程变长。典型的 MR 流程中，中间数据的文件数和数据量与 mapper*reducer 的数量成线性，而为了扩展性，一般 mapper 和 reducer 的数量和数据量成线性。于是，中间数据的文件数和数据量与原始的数据量成平方关系。小文件合并任务：计算框架的数据访问模式确定，可以直接将小文件合并成大文件而任务读取不受影响。通过后台运行任务来合并小文件，可以有效缓解小文件问题。通过 MapReduce/Spark 框架，可以利用起大量的机器来进行小文件合并任务。Shuffle service：shuffle 流程的中间文件数是平方级的，shuffle service 将 shuffle 的中间数据存储在独立的服务上，通过聚合后再写成 HDFS 文件，可以有效地缓解中间数据的小文件问题。

四、数据存储高扩展性

长尾问题

尾部延迟放大+集群规模变大，使得大集群中，尾部延迟对于整个服务的质量极为重要。慢节点问题：网络不会直接断联，而是不能在预期的时间内返回。会导致最终请求不符合预期，而多副本机制无法直接应对这种问题。高负载：单个节点处理的请求超过了其服务能力，会引发请求排队，导致响应速度慢。是常见的一个慢节点原因。

数据可靠性

超大集群下，一定有部分机器是损坏的，来不及修理的。随机的副本放置策略，所有的放置组合都会出现。而 DN 容量够大，足够三副本，单个 DN 视角：容量一百万，机器数量一万。那么另外两个副本的排列组合有一亿种，容量比放置方案大约百分之一。三副本，全局视角：一万台机器，每台一百万副本，损坏 1%（100 台）。根据排列组合原理，大约有 1009998/(1000099999998)(100000010000)=9704 个坏块callback 一下，叠加长尾问题。每个任务都要访问大量的块，只要一个块丢失就整个任务收到影响。导致任务层面的丢块频发，服务质量变差。

copyset

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

负载均衡的意义

避免热点

机器热点会叠加长尾问题，少数的不均衡的热点会影响大量的任务。

成本：

数据越均衡，CPU、磁盘、网络的利用率越高，成本更低。集群需要为数据腾挪预留的空间、带宽更少，降低了成本。

可靠性

全速运行的机器和空置的机器，以及一会全速运行一会空置的机器，可靠性表现都有不同。负载均衡可以降低机器故障的发生。同一批机器容易一起故障，数据腾挪快，机器下线快，可以提升可靠性。

\

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。