Amazon EBS Intro

概述

Amazon Elastic Block Store（EBS）是 AWS 的核心存储基础设施之一，为 EC2 实例提供持久、高可用、低延迟的块存储能力

1. 系统整体架构

EBS 的架构可大致划分为三层：

1. 服务器堆栈（Server Stack）：负责网络入口、块设备虚拟化、数据分发与存储协调。
2. Droplet 软件栈（Droplet Software Stack）：EBS 内部执行引擎，包括缓存、镜像、日志、元数据管理等核心组件。
3. 底层持久化存储（Backing Store）：用于数据最终持久化，通常为多副本分布式存储系统与 S3 快照存储。

EBS 的设计核心是“分布式块设备服务”，通过网络访问提供近似本地盘的性能，同时带来云原生的弹性与耐久性。

2. 服务器堆栈（Server Stack）详解

EBS 服务器层主要由以下组件组成：

2.1 GNBD（Global Network Block Device）入口

作为块设备的网络入口，GNBD 具有以下职责：

• 接收来自 Dom0/EC2 的读/写请求
• 解析 I/O 协议与请求头
• 将请求标准化成 Droplet 可处理的内部格式

其强调低延迟处理，通常优化网络路径并采用零拷贝（Zero-copy）设计。

2.2 RPC & Control Plane

控制平面组件用于：

• 请求路由与调度
• 元数据查询
• 节点健康与负载情况监控
• 卷状态管理（创建、挂载、拆卸、快照）

控制平面与数据平面（I/O）严格隔离，以保证性能稳定性与可扩展性。

3. Droplet 软件堆栈（Droplet Stack）

Droplet 是 EBS 的存储执行引擎，负责实际 I/O 操作。堆栈内包含多个关键模块：

3.1 Mirror Backend（镜像后端）

镜像后端是 EBS 的高可用核心。

• 所有写请求在 Primary（Master）节点处理后，会同步复制到 Secondary（Slave）节点
• 采用写前日志（WAL）或复制协议确保一致性
• 保证数据在节点故障时可快速无损恢复

3.2 Cache Backend（缓存后端）

通常基于内存页缓存（Page Cache）构建：

• 对热点块进行读缓存
• 对写请求进行暂存与合并
• 用于提升低延迟与吞吐能力

缓存对于降低 S3 或持久化介质的压力非常关键。

3.3 Async IO Manager（异步 I/O 管理器）

管理缓存中的脏数据刷盘过程：

• 异步写入后端存储（S3 or other persistent store）
• 合并小写请求
• 避免阻塞 I/O 热路径
• 提供写压力缓冲

3.4 S3 Backing Store（S3 持久化层）

用于最终数据存储与快照功能：

• 定期与 Volume 同步脏数据
• 作为卷快照（Snapshot）的底层实现
• 提供区域级持久化，跨机架容灾

此设计使 EBS 不仅具备高可靠性，也能以低成本实现历史版本、复制与恢复。

4. EC2 → EBS I/O 请求生命周期

以下流程描述典型的 Read 或 Write 请求生命周期。

4.1 客户端发起阶段

应用程序在 EC2（DomU）中发起系统调用：

• read()
• write()
• 文件系统产生的 fsync()、flush() 等操作

4.2 虚拟化转发阶段

I/O 请求经历虚拟化层：

1. DomU → Hypervisor（Xen/Nitro）
2. Hypervisor 将操作转为虚拟块设备（/dev/xvd* / /dev/nvme*）
3. 设备驱动将请求转发至 Dom0 或 Nitro I/O path

Nitro 架构中，该路径被极大简化以提升性能与带宽上限。

4.3 客户端堆栈转发（Dom0 / Nitro Controller）

操作系统将 I/O 请求包装为网络块请求：

• 进行队列管理、I/O 合并（merge）与排队
• 发送到 EBS 后端（GNBD）

此步骤确保网络延迟和块大小最优。

4.4 EBS Master 节点处理

Master 节点执行以下动作：

读请求（Read Path）

1. 查询 Cache Backend 是否命中
2. 若命中，直接返回缓存数据
3. 若未命中，从后端存储（Mirror/S3 Data）读取
4. 更新缓存以提升后续访问性能

写请求（Write Path）

1. 写入 Cache Backend
2. 写前日志写入以保证一致性
3. 通过 Mirror Backend 复制写请求到 Secondary 节点
4. 返回写入成功（异步刷盘）

4.5 请求返回路径

数据沿原路径返回：

• Master → Dom0 / Nitro → DomU 应用程序
• 系统调用完成

EBS 通过优化请求批处理、网络路径与缓存保证整个链路的低延迟。

5. 卷生命周期（Volume Lifecycle）

5.1 创建（Create Volume）

• 控制平面为卷分配元数据与节点
• 初始化 Droplet 实例
• 建立 Primary/Secondary 复制关系
• 可基于 Snapshot 初始化

5.2 附加（Attach）

绑定到 EC2 实例：

• Xen Hypervisor 使用虚拟块设备（/dev/xvdX）
• Nitro 使用 NVMe 命名空间映射（nvmeXnY）
• 控制平面更新卷状态（In-use）

5.3 使用（I/O Serving）

卷进入运行期：

• 缓存、复制、持久化全面工作
• 性能维持由 gp2/io1/st1 等类型决定
• CloudWatch 实时监控吞吐、IOPS、延迟、burst credits

5.4 快照（Snapshot）

快照存储在 S3：

• 增量快照（仅存储变更块）
• 可从任何快照恢复新卷
• 适用于 Backup / Restore / Clone / Region Replication

5.5 分离（Detach）

卷从 EC2 上卸载：

• 刷写缓存并同步落盘
• 更新内部状态为 available

5.6 删除（Delete）

清理卷元数据与存储占用，但快照不会被自动删除。

6. 关键组件之间的交互模型

下列交互构成了 EBS 的核心可靠性与性能基础：

6.1 Master ↔ Slave（镜像复制）

• 所有写请求必须复制到 Slave
• 采用同步复制以保证强一致性
• 利用日志结构减少磁盘写放大

该机制确保卷可以在节点故障后快速接管。

6.2 Memory Cache ↔ Persistent Store

缓存层负责：

• 热点数据读缓存
• 写入合并与延迟写盘
• 随机写转顺序写，改善吞吐

后端持久层（S3 / 本地 SSD）则确保耐久性。

6.3 Control Plane ↔ Data Plane

• 控制平面负责“卷的管理”
• 数据平面负责“I/O 的执行”

此架构保证了在大规模下仍能保持性能隔离与线性扩展能力。

7. 性能机制与工程设计亮点

EBS 的性能依赖以下设计：

7.1 I/O 合并（I/O Merging）

• SSD 可合并至 256 KiB
• HDD 可合并至 1 MiB
• 减少计费 I/O 数量
• 提升吞吐能力

7.2 I/O 信用系统（Burst Credits）

如 gp2、st1、sc1 会通过信用系统允许短时突发性能。

7.3 Nitro Hypervisor NVMe Path

在 Nitro 架构中：

• 延迟大幅降低
• CPU 开销减少
• 映射为 NVMe，提高并行度

7.4 异步刷盘（Async Flush）

• 保证写操作低延迟
• 异步落盘于 S3 或后端介质

8. 最佳实践

1. EBS 卷类型对比：性能、成本和适用场景

Amazon EBS 卷分为 SSD 支持的卷（io1, gp2）和 HDD 支持的卷（st1, sc1）。选择正确的 EBS 卷类型，需要权衡 IOPS、Throughput (吞吐量)、延迟 (Latency) 和 成本 (Cost)。

稳定性/可靠性

Amazon EBS 旨在实现 99.999% 的服务可用性，年故障率 (AFR) 设计为 0.1–0.2%。

卷类型对比表（性能与成本）

注: 以上价格是截至 2018 年 4 月，在 us-west-2 (俄勒冈) 区域每月每 GiB 的价格，按秒计费。

性能和成本权衡

• IOPS (SSD 卷): 如果工作负载主要关注 IOPS 性能，并且延迟要求极低（亚毫秒），或者需要超过 80,000 IOPS，则 io1 卷是首选。如果 IOPS 要求在可突发范围内（不高于 3,000 IOPS），且对成本较为敏感，gp2 是更好的选择。
• Throughput (吞吐量/HDD 卷): st1 和 sc1 适用于大块顺序 I/O (Large, sequential I/O)。对于需要更高吞吐量的工作负载，st1 提供了比 sc1 更高的基准和突发性能，但成本也更高。

2. 成本管理与快照最佳实践 (Cost Management & Snapshots)

快照成本

• 快照存储成本： 所有卷类型的快照存储成本均为 $0.05/GiB/月。
• 管理快照成本： 推荐使用 Data Lifecycle Manager (DLM) 策略来执行定期备份和自动删除旧快照，从而控制快照成本。

成本可视化

• 标签与成本跟踪： 为 EBS 卷和快照设置标签（Key/Value Pairs），例如 Key = usage。可以激活这些快照标签作为“成本分配”标签 (cost allocation tags)，以便在 Cost Explorer 中按标签值（如 dev 或 backup）查看使用情况和成本细分，提高成本可见性。

3. 安全性最佳实践 (Security)

EBS 加密 (Encryption)

最佳实践是使用加密来保护 EBS 数据卷。

1. KMS 主密钥： 为 Amazon EBS 创建新的 AWS KMS 主密钥 (Master Key)。这包括定义密钥轮换策略、启用 AWS CloudTrail 审计以及控制密钥的使用和管理权限。
2. 默认加密： 可以在账户的特定区域配置 EBS 默认加密，以确保新创建的 EBS 卷自动加密。
3. 灵活启动： 现在可以从未加密的快照或 AMI 启动加密的卷。

4. 可靠性与容灾最佳实践 (Reliability)

数据持久性与恢复

• 卷设计： Amazon EBS 旨在实现 99.999% 的服务可用性。
• 防止意外终止： 对于包含重要数据的卷，应确保设置 DeleteOnTermination = False，防止 EC2 实例被终止时 EBS 卷数据丢失。
• 实例恢复： Amazon EBS 支持 EC2 实例恢复功能，当 CloudWatch 警报触发 StatusCheckFailed_System 时，适用于 VPC 中某些 EBS-only 存储实例类型（如 C3, C4, M3, M4, T2, X1 等）。

5. 性能优化最佳实践 (Performance Optimization)

卷初始化 (Initialization)

• 初始化： 新的 EBS 卷或从快照创建的卷，可能需要初始化 (Initialize) 才能获得最佳性能。
• 方法： 通过在整个卷上执行随机读取 (Random read across volume) 来初始化卷。可以使用 fio 工具来完成此操作。

EBS 优化型实例 (EBS-Optimized Instances)

• 专用带宽： 始终使用 EBS 优化型实例，它为 Amazon EBS I/O 提供专用的网络带宽。
• 默认状态： 在所有当前代实例类型上，EBS 优化通常是默认启用的。

针对 HDD 卷（st1/sc1）的优化

• I/O 模式检查： 使用 CloudWatch 或 iostat (Linux) / Perfmon (Windows) 确认工作负载 I/O 模式。如果平均 I/O 大小低于 64 KiB，则可能是随机 I/O 工作负载，这会降低 st1/sc1 性能。
• 增大 Read-ahead Buffer： 针对高吞吐量读取工作负载，建议增大 read-ahead buffer。

使用 RAID 的指导原则

• 避免冗余： EBS 数据已复制，不应使用 RAID1、RAID5 或 RAID6 来实现冗余。RAID1 会使可用 EBS 带宽减半，而 RAID5/6 会损失 20% 到 30% 的可用 I/O 用于奇偶校验。
• 何时使用 RAID： 仅在需要聚合容量或性能时考虑使用 RAID。例如，当存储需求大于 16 TiB、吞吐量需求大于 1,000 MiB/s 或 IOPS 需求大于 64,000 @ 16K 时，可能需要使用 RAID。

9. 总结

EBS 是一个高度工程化、分布式、低延迟的块存储系统，其内部架构远比“虚拟磁盘”复杂。通过 GNBD 网络入口、Droplet 执行引擎、复制体系、缓存层、持久化存储与快照机制等组件的协作，EBS 实现了：

• 高可靠性（99.999% 可用性）
• 强一致性写复制
• 高性能缓存与 I/O 合并优化
• 灵活的卷与快照生命周期管理
• 云原生的弹性与可扩展性

参考

Deep dive on Amazon EBS

AWS 官方文档