这是我参与「第四届青训营」笔记创作活动的第9天。
课程目录
1.元数据高可用
2.数据存储高可用
3.元数据高扩展性
4.数据存储高扩展性
1.元数据服务高可用
1.1 高可用的需求
1.1.1 服务高可用的需求
故障类型
- 硬件故障
- 软件故障
- 人为故障
灾难：数据中心级别不可用
- 机房断电
- 机房空调停机
- 机房间网络故障、拥塞
1.1.2 高可用的衡量
服务可用性指标
- MTTR
- MTTF
- MTBF
1.1.3 可用性的年化
1.1.4 高可用的形式
服务高可用
- 热备份
- 冷备份
故障恢复操作
- 人工切换
- 自动切换
1.2 HDFS主备同步实现
1.2.1 HDFS NameNode高可用架构
组件介绍
- AcliveNamenode：主节点，提供服务，生成日志
- StandbyNamenode：备节点，消费日志
- ZooKeeper：为自动选主提供统一协调服务
- BookKeeper：提供日志存储服务
- ZKFC：NameNode探活、触发主备切换
- HA Client：提供了自动切换的客户端
- edit log：操作的日志
围绕三个问题来看高可用
- 节点状态如何保存
- 操作日志如何同步
- 如何做到自动切换
1.2.2 理论基础-状态机复制和日志
状态机复制是实现容错的常规方法
组件
- 状态机以及其副本
- 变更日志
- 共识协议
1.2.3 NameNode状态持久化
FSlmage和EditLog
Checkpoint机制
1.2.4 NameNode操作日志的生产消费
- Active生产，Standby（可能有多个）消费
- 物理日志与逻辑日志
日志系统
- 高可用
- 高扩展性
- 高性能
- 强一致（有序）
1.2.5 NameNode块状态维护
回顾
- DataNode Heartbeat
- DataNode Block Report
区别
- Aclive即接收，也发起变更
- Standby只接收，不发起变更
Content Stale状态
- 主备切换后，避免DN的不确定状态
1.3 HDFS自动主备切换
1.3.1 分布式协调组件-ZooKeeper
一般用于提供选主、协调、元数据存储。
- HA核心机制：Watch
1.3.2 自动主备切换流程-Server侧
ZKFailoverController
作为外部组件，驱动HDFS NameNode的主备切换
- 轮询探活
- 脑裂问题
- Fence机制
1.3.3 自动主备切换流程-Client侧
- 核心机制：StandbyException
- Client自动处理
1.4 日志系统BookKeeper简介
1.4.1 BookKeeper架构
BookKeeper
- 低延时
- 持久性
- 强一致性
- 读写高可用 对比：日志系统和文件系统的复杂度
1.4.2 Quorum机制
- Quorum机制：多副本一致性读写
- 场景：多副本对象存储，用版本号标识数据新旧
- 规则
- 思考：日志场景比对象保存更简单
1.4.3 BookKeeper Quorum
Sloppy Quorum机制
日志场景：顺序追加、只写
- Write Quorum：写入副本数
- Ack Quorum：响应副本数
1.4.4 BookKeeper Ensemble
Ensemble机制
Round-Robin Load Balancer
- 第一轮：1，2，3
- 第二轮：2，3，4
- 第三轮：3，4，1
- 第四轮：4，1，2 优势：数据均衡
2.数据存储高可用
2.1 单机存储的数据高可用机制
2.1.1 回到单机存储-RAID
特点
- 廉价
- 高性能
- 大容量
- 高可用
2.1.2 RAID方案讲解
- RAID 0：条带化
- RAID 1：冗余
- RAID 3：容错校验
2.2 HDFS的数据高可用机制
2.2.1 HDFS多副本
优点
- 读写路径简单
- 副本修复简单
- 高可用
2.2.2 Erasure Coding原理
- HDFS版本的RAID 2/3
- 业界常用的Reed Solomon算法
2.2.3 HDFS Erasure Coding
和多副本比较
- 读写速度
- 成本
- 修复速度
- 读写路径的实现
2.3 考虑网络架构的数据高可用
2.3.1 网络架构
- 机架（Rack）：放服务器的架子
- TOR（Top of Rack）：机架顶部的交换机
- 数据中心（Data Center）：集中部署服务器的场所
2.3.2 副本放置策略-机架感知
trade-off：一个本地、一个远端
2.4 案例：字节跳动的HDFS多机房容灾方案简介
2.4.1 案例：字节跳动的HDFS多机房实践
多机房解决的问题
- 容量问题
- 容灾问题
2.4.2 多机房容灾实践
多机房部署的组件
- ZooKeeper
- BookKeeper
- NameNode
- DataNode
容灾期间的策略
- 容灾期间，限制跨机房写入
- 容灾期间，限制跨机房副本复制
3.元数据高扩展性
3.1 元数据扩展性挑战
3.1.1 元数据节点扩展性的挑战
scale up vs scale out
- 扩容单个服务器的能力
- 部署多个服务器来服务
挑战
- 名字空间分裂
- DataNode汇报
- 目录树结构本身复杂
3.1.2 常见的Scale Out方案
3.2 社区的解决方案
3.2.1 社区解决方案-BlockPool
解决DN同时服务多组NN的问题
文件服务分层
- NameNode
- Block Storage
用blockpool来区分DN的服务
- 数据块存储
- 心跳和块上报
3.2.2 社区解决方案-viewfs
Federation架构：将多个不同集群组合起来，对外表现像一个集群一样
- 局限性：运维复杂
3.3 字节跳动的NNProxy方案
3.3.1 字节跳动的NNProxy
NNProxy是ByteSance自研的HDFS代理层，提供了路由服务。
- NNProxy所在系统上下游
3.3.2 NNProxy路由规则保存
回顾：三种数据路由方式
- 服务端侧
- 路由层
- 客户端侧
考虑点
- 扩展性
- 运维性
3.3.3 NNProxy路由转发实现
路径最长的匹配规则
- /
- /home
- /user/bob
- /user/tiger/warehouse
- /user/tiger/dump
3.4 案例：小文件问题
4.存储数据高扩展性
4.1 超大集群的长尾问题
4.1.1 延迟的发布和长尾延迟
4.1.2 尾部延迟放大
木桶原理
尾部延迟放大：访问的服务变多，尾部的请求就会越发的慢。
如何变慢
- 固定延迟阈值
- 固定延迟百分位
4.1.3 长尾问题的表现-慢节点
- 慢节点：读取速度过慢，导致客户端阻塞。
- 集群扩大10倍，问题扩大N（>10）倍
4.2 超大集群的可靠性问题
4.2.1 超大集群下的数据可靠性
- 推论：必然有部分数据全部副本在损坏的机器上，发生数据丢失
4.2.2 Copyset
原理：减少了副本放置的组合数，从而降低副本丢失的概率。
4.3 超大集群的不均匀问题
4.3.1 超大集群的负载均衡和数据迁移
4.3.2 数据写入不均
数据的不均匀
- 节点容量不均匀
- 数据新旧不均匀
- 访问类型不均匀
- 资源负载不均匀
4.3.3 DN冷热不均
数据的不均匀
- 节点容量不均匀
- 数据新旧不均匀
- 访问类型不均匀
- 资源负载不均匀
