HDFS的高可用和高扩容|青训营笔记

Siri33
224 阅读7分钟

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

本次笔记重点内容

  1. HDFS 元数据服务的高可用
  2. HDFS 数据存储高可用
  3. HDFS 元数据服务的高扩展性
  4. HDFS 数据存储的高扩展性

一个“可以用”和“好用”的系统，重点就在“高可用”和“高扩展性”。

元数据服务的高可用

需求

为了应对硬件、软件、人为故障和机房断电、机房空调停机、机房网络故障等灾难的问题而设计。

高可用衡量标准

image.png

  • MTTR：发现一次故障要多久来恢复
  • MTTF：平均一次故障要花费的时间
  • MTBF：多久系统会有一次故障

可用性年化

可用性=一年之中没有故障的时间/总共的时间，可以每周/每小时采集一次数据，灵活变化。 image.png

高可用形式

热备份，过去的服务出现故障可以立刻切到新的服务来处理；冷备份，将服务中关键的数据进行备份，然后在其他服务上面重启。

故障恢复操作

人工切换，人的反应和决策时间过长；自动切换，系统自行决策。

HDFS高可用架构

image.png

  • ActiveNameNode

提供服务的 NameNode 主节点，处理Client发过来的请求，将处理的结果信息存在editlog中，生产日志（目录树和文件信息的更新）保存在高可用、高扩展性、高性能的日志系统上。 DataNode 心跳与块汇报需要同时向 ActiveNameNode 和 StandbyNameNode 上报，让两者可以同时维护块信息，但只有 ActiveNameNode 会下发 DataNode 的副本操作命令。

  • StandbyNameNode

不提供服务，起备份作用的 NameNode 备节点，消费保存的日志信息，和ActiveNameNode保持状态同步，在ActiveNameNode出问题时方便切换到这。为了保证Standby不轻易要求DataNode进行一些操作，因为不能确定ActiveNameNode是什么状况，所以要Content Stale来控制。

  • edit log：用户变更操作的记录，是 HDFS 的变更日志
  • ZooKeeper：开源的分布式协调组件，主要功能有节点注册、主节点选举、元数据存储。
  • BookKeeper：开源的日志存储组件，存储 editlog，低延迟、持久性、强一致性、读写高可用
  • ZKFC：进行 HDFS NameNode 探活和自动的 主备切换
  • HA Client：提供了自动切换的客户端，核心机制是StandbyException
理论基础——状态机复制和日志

状态机复制是实现容错的常规方法 image.png

状态机保存若干状态，随着外部来在内部做一些动作，状态机及其副本分布在不同节点上；变更日志，就如图中xyz值的变化，记录用户的操作对状态机产生怎么样的影响；共识协议就是所有状态机会收到相同的日志。

Quorum 协议——多副本一致性读写

基于鸽巢原理，不用等所有副本写入成功，在多个副本间确保高可用、高性能的多副本变更协议

BookKeeper Quorum 协议

基于 Quorum 的多数派思想来提供高可用、高性能写入的日志写入

image.png

如果希望可用性更好，可以把写入副本数（一次写入需要写入到的存储节点数）调高；如果希望一致性更好，可以把响应副本数（一次写入需要收到的响应数）调高。

数据存储高可用

单机存储——RAID

提高RAID功能的NAS设备，可插6个硬盘，RAID方案成本较低： image.png

RAID方案

  1. RAID 0

image.png

条带化，两块盘对外同时提供服务，数据分别写在两块盘上，容量和读写吞吐量大

  1. RAID 1

image.png

冗余，将数据副本存储在多个磁盘上，提供高可靠

  1. RAID 3

image.png

容错校验，将数据按比特位分割，算出冗余的校验码，将数据的校验码存储在独立的磁盘上，根据校验码还可以反推原来缺失的数据

HDFS多副本方案——将数据块存储在多个 DataNode 上

读写路径简单，副本修复简单，从其他DataNode上拷贝一份即可，提供数据的高可用。

网络架构
  • Server：一台服务器
  • 机架Rack：放服务器的架子
  • TOR top of rack：机架顶部（或底部）的交换机，负责机架内服务器和数据中心的其他服务器的网络通信

副本放置策略——机架感知

若服务器都放置在一个机架上，那这个机架出问题会引出很大麻烦

HDFS多机架放置，一般是三副本，一个写在本地机架，一个在远端（不同机架），一个在同一个远端的机架： image.png

多机房实践

HDFS双机房放置设计，写入时，每个数据块在两个机房至少各有一个副本，读取时，优先读本地的副本，避免大量跨机房读取。

多机房容灾

容灾期间，限制跨机房写入和副本复制。

元数据服务的高扩展性

HDFS NameNode部署在单个机器上，内存、磁盘容量、CPU计算力都不能无限扩展。

scale up：扩容单个服务器能力
scale out：部署多个服务器来服务
  • partition方案——KV模型

通过 hash 或分段的手段，将不同类型 key 的访问、存储能力分配到不同的服务器上，

blockpool——社区解决方案

解决了多个 NameNode 可能生成同一个 block id 导致 DataNode 无法区分的问题。

viewfs——社区解决方案

通过客户端配置决定某个路径的访问要发送给哪个 NameNode拷贝到另一个NameNode 集群。

小文件问题

小于一个 HDFS Block 的文件称为小文件，MapReduce的worker数量过多容易引起小文件问题。多个小文件相对于一个大文件，小文件过多，内存空间是撑不住的；I/O 变成小的随机IO，无法顺序扫描磁盘，数据访问减慢；计算任务的启动变慢。解决方案：后台任务合并小文件；shuffle service 将 shuffle 的中间数据存储在独立的服务上，聚合后再写成 HDFS 文件，可以有效缓解中间数据的小文件问题。

存储数据高扩展性

什么是长尾延迟？

占绝大多数的、重要性低的东西就是长尾，并行执行任务时，其中有一个最慢的，服务得等最慢的请求返回了才能整体响应给客户。

尾部延迟放大

访问的服务变多，尾部的请求就会越慢。

长尾问题——慢节点

读取速度过慢导致客户端阻塞的叫慢节点，其难以避免和预测。

超大集群下的数据可靠性

超大集群下，一定有部分机器是损坏的，来不及修理的，副本放置策略完全随机，每个DataNode容量足够大的情况下产生。

Copyset

image.png

将全随机的副本放置变得有规律，将DataNode分为若干个Copyset，降低了副本放置的组合数，降低副本丢失的概率。

超大集群的负载均衡和数据迁移

意义？

  • 避免热点，避免慢节点问题
  • 可靠性高
  • 成本降低

集群的不均衡

  • 节点容量不均
  • 数据新旧不均
  • 访问类型不均

image.png

数据迁移工具——将数据从一部分节点搬迁到另一部分节点

DistCopy

通过 MapReduce 任务来将数据从一个NameNode拷贝到另一个NameNode，网络流量较大，速度较慢

Balancer

向DataNode发起迁移命令，平衡各个DataNode容量，单机房、多机房使用

avatar
文章
阅读
粉丝