AWS Re:cap 09: 深入探讨 Amazon S3（STG407）

简介

● 服务器级故障处理策略

● 本系列重点介绍 S3 操作的底层细节

● 今年的重点：可用性设计方法

● 两个视角：系统级视角和服务器级视角

● 从系统级视角了解故障架构、写后读一致性和故障实现

● 术语定义

● 可用性：应对故障

● 故障：可能发生故障的组件（驱动器、服务器、机架、建筑物）

● 故障类型：永久丢失或暂时不可用（电力、网络、过载）

● 设计目标：系统围绕目标进行设计（例如 99.99% 可用性、11 个 9 的持久性、写后读一致性）

● S3 的设计目标

● 专为高可用性和持久性而设计

● 写后读一致性于 2020 年推出

● 2020 年以前，可接受的故障处理方式包括违反一致性保证

S3 在一致性功能发布之前：故障处理与索引子系统

一致性的定义

● 一致性：对某个对象执行 GET 时，结果会反映最近一次对该对象执行 PUT 后的状态

● 索引子系统

● 保存对象元数据（名称、标签、创建时间）

● 每个数据平面请求（GET、PUT、LIST、HEAD、DELETE）都会访问该系统

● 发往索引的请求比发往存储子系统的更多

● 索引系统的核心：用于持久保存索引条目的专用存储

● 基于仲裁的算法

● 使用基于仲裁的算法将数据存储在多个副本中

● 能够容忍故障

● 服务器运行在不同的可用区（AZ）中，以避免故障集中在单一故障域

● 任何单个磁盘、服务器、机架或可用区发生故障时，仅会影响一小部分数据

● 索引中的仲裁实现

● 读写操作必须访问大多数服务器

● 示例：写入值 A 在所有节点上均成功

● 写入值 B：一个节点发生故障，但 B 在大多数服务器上写入成功（不影响可用性）

● 读取方发起读取：一个服务器发生故障，但另外两个服务器返回值 B

● 通过关联的时间戳解决冲突（B 胜过 A）

● 即使服务器在请求处理中发生故障，读写操作仍能成功

● 由于存在多个节点且允许发生故障，系统具备可用性

分布式系统中基于仲裁的算法

概述

● 基于仲裁的算法要求最少数量的节点（仲裁节点数）就读取或写入数据等操作达成一致，从而确保一致性和容错能力。

● 防止部分节点发生故障时数据损坏。

关键概念

仲裁

● 定义节点总数（N）、写仲裁数（W）和读仲裁数（R）。

● 读取操作：

● 读取请求会发送到一组节点；如果收到 R 个节点的响应，操作即成功。

● 写入操作：

● 写入请求会发送到一组节点；如果 W 个节点确认，写入即提交。

● 一致性：

● 规则 R + W > N 可确保任何读取都能看到最新写入的数据，因为读取集合与写入集合必须至少有一个重叠节点。

● 容错能力：

● 如果一个节点发生故障，系统仍可形成仲裁（例如，一个 3-out-of-5 系统可以容忍 2 个节点发生故障）。

示例和应用

数据复制

● 确保集群中的所有数据副本保持一致（例如 Cassandra 等数据库）。

● 互斥（Maekawa 算法）：

● 节点向其仲裁节点请求访问共享资源（临界区）的权限，以确保每次只有一个节点进入。

● 共识（Paxos）：

● 分布式系统就单一值达成一致的基础协议，对于领导者选举和状态机复制至关重要。

关键参数（URW 模型）

● N：数据副本（节点）总数。

● W：写仲裁数（确认写入所需的节点数）。

● R：读仲裁数（确认读取所需的节点数）。

S3 基于仲裁的系统：确保高可用性和一致性

S3 兼容系统中的仲裁原则

● 利用仲裁原则（大多数节点达成一致）实现高可用性和一致性

● 适用于集群或边缘环境（例如 Snowball Edge 上的 Amazon S3）

S3 类系统的工作原理

分布式共识

● 监视器或管理器形成仲裁组（通常为 3 个或更多），以跟踪节点运行状况

● 将可用的存储节点告知客户端

● 写入操作：

● 只有大多数存储节点（仲裁节点）确认后，写入才会成功

● 确保整个集群的数据持久性和一致性

● 读取操作：

● 读取以达到仲裁数量的副本为目标，以保证获取最新数据

● 容错能力：

● 在总共有 2f+1 个副本时，可以容忍 f 个节点发生故障

● 只要仍能形成仲裁，就可以选出新的领导者，并继续执行操作

关键示例

Snowball Edge 上的 Amazon S3

● Snowball Edge 设备集群使用仲裁机制提供 S3 兼容存储

● 管理设备状态和数据可用性 Ceph：

● 使用监视器和 OSDs（Object Storage Daemons，对象存储守护进程）及仲裁机制。

● 作为 S3 兼容后端维护集群状态和数据可用性。

● Object Storage Daemons（OSDs，对象存储守护进程）是 Ceph 等分布式系统中负责存储数据的核心进程，作为独立存储单元管理本地磁盘（HDDs/SSDs），并处理大量非结构化数据的复制、恢复和分发，因此是构建可扩展且有韧性的对象存储的基础。

● 分布式共识库：

● GitHub 使用 S3 的条件操作（ETags）进行领导者选举和仲裁

● OSD 的关键功能：

● 数据存储：在本地文件系统（如 XFS）上存储实际的数据对象。

● 数据管理：管理整个集群中的数据复制（创建副本）和恢复（重建丢失的数据）。

● 心跳监控：检查其他 OSDs 的运行状况，并向 Ceph Monitors 报告状态。

● 网络访问：为客户端提供对所存储数据的网络访问。

核心 S3 与基于仲裁的系统

Amazon S3（核心）

● 在全球基础设施中原生提供强大的写后读一致性

● 用户无须显式管理仲裁

● S3 基于仲裁的系统（集群/边缘）：

● 在用户管理的 S3 兼容设备集群中应用仲裁概念

● 确保集群内部的一致性和可用性

S3 的系统级可用性设计和缓存层

核心概念

● 提供多个可供路由的节点，并预留故障余量

● 通过配置和容量规划实现 99.99% 的可用性目标

● 2020 年以前的写后读一致性

● 由于读取和写入存在重叠（两者都必须访问大多数服务器），读取方能看到写入方写入的值

● 问题：为什么 S3 在 2020 年以前不具备写后读一致性？

● 答案：缓存层

● 缓存层

● S3 的前端会大量缓存经常访问的对象

● 不一致读取：返回值 B，而不是最后写入的值 C

● 缓存中的读取和写入并不重叠

● 缓存具备关键的可用性属性（多个主机都能接收请求，并允许发生故障）

● 缓存中的读取和写入没有重叠

● 由于 2020 年以前的设计目标不包括一致性，这是当时可接受的故障处理方式

● 缓存层示例：

● 缓存节点为空，存储中的值为 B

● 读取方通过一个缓存节点读取，返回值 B，并将其驻留在缓存中

● 对 C 的写入覆盖对象，并持久化到各副本（C C C）

● 值 B 和 C 缓存在不同的节点上（2020 年以前的设计）

● 读取被路由到先前的缓存节点，返回值 B（不一致读取）

使用缓存一致性协议解决重叠问题

最受期待的功能：一致性

● 一致性是 2020 年以前最受期待的功能

● 目标：解决缓存层中的重叠问题

● 缓存一致性协议

● 必须快速、高效且具备可用性

● 保留允许多个服务器接收请求，同时允许部分服务器发生故障的属性

● 解决方案：复制日志

● 复制日志

● 一种将节点串联起来的分布式数据结构

● 写入按顺序流经各节点

● 每个节点都将写入转发给下一个节点

● 写入通过日志后，会发送到达到仲裁数量的存储节点

● 日志会记录最近的历史，并就顺序达成一致

● 示例：A 在 B 之前

● 基于仲裁的系统无法正确推断顺序

● 日志为变更创建明确定义的顺序

● 序列号和水位线

● 为所有写入分配序列号（随时间递增）

● 示例：A（序列号 1）、B（序列号 2）、C（序列号 3）

● 存储节点在获知值的同时也会获知序列号

● 序列号与值一起存储在缓存中

● 缓存节点可以询问在给定序列号之后是否有任何写入到达

● 见证系统

● 用途：跟踪索引写入的高水位线

● 见证节点无须保存实际数据，只需保存序列号

● 见证节点可以高估最后一个序列号（告知调用方其数据已过期是安全的）

● 如果调用方被告知其数据已过期，它将从存储中读取并获得正确结果

通过动态重新配置确保故障余量和一致性

见证系统

● 位于日志旁的内存数据结构（整数数组）

● 允许缓存节点询问在缓存值之后是否有任何写入到达

● 修改后的读写算法：

● 写入会进入日志

● 读取会与见证节点通信；如果缓存有效，则从缓存返回；如果已过期，则前往存储读取

● 故障余量丧失

● 原始日志架构：如果一个节点发生故障，写入就无法继续通过系统

● 仲裁系统并发处理写入；日志则让写入按顺序通过

● 日志中的节点故障可能导致整个系统停顿

● 动态重新配置

● 引入该机制是为了解决故障余量问题

● 日志中的节点会监控彼此的可用性

● 持续相互发送 ping；消息不断通过系统

● 节点掌握邻居可用性的最新视图

● 遇到问题时，节点会请求一个基于仲裁的配置系统重新配置日志

● 节点发生故障后，会在数毫秒内完成重新配置

● 配置系统本身也基于仲裁

● 结果

● 缓存具备故障余量，且读写操作相互重叠

● S3 现在既一致又高度可用

● 通过以可用性为目标进行设计，在一致性功能发布时仍保持了高可用性

● 系统级可用性视角

● 需要有许多服务器可供选择

● 只需在其中一部分服务器上成功

● 面对故障时快速重新配置系统的能力

● 即使在日志等系统中，也始终存在基于仲裁的算法

在实现层面应对故障

理解故障

● 问题：哪些方面可能发生故障？

● 相关性故障至关重要：同时发生的故障

● 在思考可用性时，相关性故障至关重要

● 仲裁设计：一个节点发生故障没有问题，但如果所有节点都位于同一 AZ 或机架中，则无法容忍

物理故障

S3 的高层物理视图

● 多个可用区（AZ）

● 每个 AZ 都有多个服务器机架

● 每台服务器有多个硬盘

● 物理故障的类型：

● 单个组件故障：硬盘电机损坏、盘片被划伤

● 相关性故障：

● 服务器故障：所有连接的硬盘看起来都发生了故障

● 机架故障：机架中的所有驱动器都发生故障（例如交换机损坏）

● AZ 故障：整个 AZ 停机（例如断电）

● 逻辑故障

● 示例：向服务器群部署新软件

● 每次部署到少量节点，然后逐步扩大范围

● 运行新软件的一组服务器构成一个故障域

● 如果新软件中存在缺陷，所有这些服务器可能会同时发生故障

● 需要智能的部署策略来容忍潜在故障

围绕相关性故障进行设计

让工作负载跨越多个故障域

● 跨多个位置（例如 AZ）复制对象，以实现持久性和可用性

● 确保即使某个相关性故障域（例如 AZ、机架、服务器）发生故障，数据仍然可用

理解故障类型

故障即停机

● 服务器或组件停止运行（例如电源线被拔掉）

● 在容错系统中易于检测和应对

● AZ 之间交换机的故障即停机：

● 某些请求会继续成功（位于同一 AZ 内）

● 其他请求开始失败（需要经过故障交换机）

● 形成一种模糊故障模式，其中部分请求成功，部分请求失败

围绕模糊故障模式进行设计

● 冗余是关键：在 AZ 之间部署多台交换机

● 每个区域中的 3 个 AZ 以环形方式连接

● 如果一条链路发生故障（例如 AZ1 到 AZ2），则可以绕远路（AZ1 到 AZ3，再到 AZ2）

● 将可用性问题转换为延迟问题，从而保持可用性

● 强大的思维模型：将一种问题转换为另一种问题（例如将可用性问题转换为延迟问题）

有状态系统中故障即停机的挑战

有状态系统中的故障即停机

● 在 S3 等系统中难以进行推理

● 可能导致系统进入原本无法到达的状态

● 崩溃一致性

● 系统应在发生故障即停机后恢复到一致状态

● 示例：向文件写入两行文本

● 正常执行：文件包含两行内容

● 执行期间发生故障即停机：文件可能只包含第一行

● 在没有故障的情况下，系统进入了一种无法到达的状态

● 围绕无法到达的状态进行设计

● 撰写了一篇关于 Shodstor（存储节点软件）的论文来解决此问题

● 重点研究如何在存在故障和并发的情况下推理可到达的状态

处理灰色故障

灰色故障

● 比故障即停机更复杂的故障模式

● 示例：

● S3 中的一个 PUT 请求

● 请求从互联网到达一台 S3 前端服务器

● 前端服务器将数据扇出到多个存储节点

● 灰色故障的定义

● 并非完全故障（例如故障即停机），但会导致系统行为异常的故障

● 示例：前端 Web 服务器接受请求，但由于网络问题而无法访问某些下游主机

● 服务器为失败的请求返回错误，但仍继续接受并响应请求

● 使用重试处理灰色故障

● 一种强大的技术：如果请求失败，则通过不同路径重试（例如不同的前端 Web 服务器）

● AWS SDKs 具有复杂的重试策略，会有意在不同 IP 地址上重试请求

● 重试允许通过系统尝试不同的路径

● 分布式系统中重试的危险

● 如果所有服务都重试失败的请求，重试可能导致工作量大幅放大

● 示例：堆栈底部的故障可能导致重试次数达到原始请求数的 27 倍

● 过多的重试可能使系统过载

● 有意设计重试策略

● 设计重试策略时需要深思熟虑，以避免系统过载

● 示例：在堆栈中越靠下的层级采用更少重试或不重试，因为知道更高层会进行重试

● 在保护系统免受过多重试影响的同时确保可用性

● 负载引起的灰色故障

● Web 服务器因工作量过大而过载，表现为请求缓慢

● 一种强大的机制：超时（客户端让缓慢请求超时，并在其他位置重试）

● 超时的挑战

● 超时并不完美，而且很难围绕它进行设计，尤其是在结合重试时

● 示例：

● 一台请求队列已满的过载 Web 服务器

● 客户端超时并在其他位置重试

● 服务器不知道客户端已重试，因此会继续处理已超时的请求

● 导致服务器对客户端已经放弃的请求执行无用工作

● 拥塞崩溃

● 服务器只处理那些已超时并在其他位置重试的请求时所处的状态

● 连锁反应：过载服务器变得更慢，导致更多重试和队列积压

● 自我强化的循环：服务器将所有时间都用在处理因重试而产生的、已超时失败的请求上

● 解决方法：反向队列处理

● 用于处理队列已满的过载服务器的机制

● 从队列末尾开始处理（后进先出）

● 虽然不公平，但通过牺牲部分客户端的体验来让其他客户端变得非常快

自我修复系统设计

摆脱拥塞崩溃

● 反向队列处理：从队列末尾开始处理（后进先出）

● 使部分请求能够成功，从而减少缓慢且已超时请求的积压

● 退避和重试：客户端执行退避并以更慢的速度重试

● 为服务器留出时间来清理积压

● 元稳定故障模式

● 尽管原始问题已经解决，系统仍将所有时间用于处理已超时请求的状态

● 系统级故障恢复

● 目标：S3 应在无须人工干预的情况下自我修复

● 示例：Web 服务器无法成功响应请求

● 客户端在其他位置重试，但需要将该服务器移出服务

● 健康检查

● 自动修复服务器的必备工具

● 健康检查服务器向 Web 服务器发送请求以检查其功能

● 如果服务器未通过健康检查，可将其移出服务（例如从 DNS 中移除）

● 通过阻止客户端访问故障服务器来缓解故障

● S3 对 AWS 基础设施的使用

● S3 构建在 AWS 上，使用的基础设施与客户可用的基础设施相同

● Web 服务器容量：网络负载均衡器

● DNS：Route 53

● 使用 NLBs 和 Route 53 实现健康检查

确保稳健的健康检查和系统运行状况全局视图

单一健康检查的危险

● 健康检查服务器可能发生故障，从而错误地检测 Web 服务器故障

● 示例：存在网络问题的健康检查服务器将所有 Web 服务器标记为异常

● 需要同时为服务器和健康检查系统的可用性进行设计

● 健康检查的多个视角

● S3 使用来自多个来源的健康检查：

● 同一区域

● 不同区域

● 公共互联网

● 组合这些信号，形成 Web 服务器运行状况的详细视图

● 有助于诊断相关性故障（例如网络问题）

● 避免局部决策

● 一项重要原则：绝不让局部系统就服务运行状况做出局部决策

● 示例：原始健康检查根据自己看到的系统状态做出局部决策

● 分布式系统需要全局视图，以避免局部决策造成错误

● 系统运行状况全局视图

● 示例：检测并修复即将发生故障的硬盘

● 软件检测到即将发生故障的硬盘

● 触发修复措施（例如重新通电、由技术人员更换）

● 健康检查的全局速率限制器

● 健康检查服务必须先咨询全局速率限制器，然后才能更改系统

● 示例：健康检查检测到即将发生故障的硬盘，并希望将其移出服务

● 如果健康检查服务失控，速率限制器会阻止移除过多硬盘

● 可用性设计回顾

● 定义可用性和正确性目标

● 设计整体系统架构以实现目标（例如基于仲裁的架构、强一致性）

● 在实现系统各部分时理解故障模式，并在不做出局部决策的情况下进行修复