受水母启发的数据库：AWS 不会开源这个数据库，但是他们发表了一篇论文

本文最初发布于 The Next Platform，经原作者授权由 InfoQ 中文站翻译并分享。

如果你想要获得超大规模、弹性、分布式块存储服务的灵感，水母显然是一个开始寻找架构特性的好对象。

这正是 Amazon Web Services 为创建 Physalia 所做的事情。Physalia 是一种大型分布式数据库服务，它存储着弹性块存储（Elastic Block Store）服务的元数据。顾名思义，弹性块存储服务为运行在公有云上的应用程序提供块存储。

在去年12月举行的re:Invent大会上，亚马逊首席技术官 Werner Vogels 介绍了 Physalia（它得名于僧帽水母）。Physalia 产品背后的技术人员发表了一篇论文，介绍它是什么以及它与其他高速数据库和数据存储有什么不同。虽然 AWS 将 Physalia 开源的可能性很小，但它有可能鼓励其他人以开源的方式重新创建其架构元素，就像过去许多超大规模的云构建科技公司所做的那样。

数以百万计的数据库，而不是一个或几个

在任何类型的分布式系统中，组件迟早会出现故障，随着组件数量在聚合系统中不断增加，故障数量及其影响也会随之增大。因此，系统架构师必须非常谨慎，尤其是当涉及到连接组件的网络故障时，这通常被称为网络分区，集群两边的系统都可以正常运行，但是应用程序和数据存储的两个部分基本无法通信，这会导致各种各样的问题。

关键是要非常精确地知道会发生什么，预测这些问题，并找到在这种情况下可能的最佳解决方法。没有一种方法是完美的，特别是在数据库方面。但是，当你创建一个元数据数据库构成 Amazon Web Services 弹性块存储的基础时——很可能是这个星球上最大的单数据块存储设备的最大集合——你需要尽可能接近完美的方法，否则，人们会丢失数据，失去耐心，或两者兼而有之。这意味着 AWS 将失去业务。获得新客户的难度是保持现有客户的十倍，因此，让使用基础设施服务的客户满意是 AWS 收入增长的关键。

在详细介绍 AWS 为管理 EBS 服务元数据而创建的大型分布式数据库 Physalia 之前，需要做一些准备。正如 Vogels 在他的主题演讲中所指出的那样，在超大规模云构建的世界中，“任何事情都可能随时失败。”这意味着，大规模的企业不能仅仅特别关注单个组件的可用性以及当系统以巨大的规模运行时可能的可用性变化，还要最小化波及范围，如设备的数量以及因此受到某种故障影响的客户的数量。

最小化波及范围是一件很棘手的事情。正如 Vogels 提醒大家的那样，你可以跨区域（跨 AWS 区域内的多个可用性区域）分配工作负载，这是有帮助的，然后，你还可以将这些区域分解为容量更小的单元格，从而使停机范围可以更小。同样地，对于区域内的架构（一次只存在于一个可用性区域），你也可以将它们划分为单元格，这样就可以减少客户受到任何潜在中断的影响。

“我们总是希望缩小波及范围，但我们如何选择单元格的大小呢？”Vogels 反问道。“如果你的单元格较小，就可以真正地缩小波及范围，这很容易测试，也很容易操作。但如果你的单元格较大，就更经济，也可以减少分裂，所以整个系统更容易操作。所以问题总是在于如何很好地划分你的系统，这样你才能真正地利用基于单元格的架构。”

EBS 是 AWS 上的分区服务，它不仅仅是运行在一堆磁盘驱动器上的磁盘卷的集合。数据被分割成许多块（由于许多不同的原因），并且每个分片复制一个副本以确保可用性。配置管理器（它位于一个单独的、与连接 EBS 和弹性计算服务的网络不同的网络上）控制这些分片的访问——如果一个活跃的分片失败，它知道在哪里打开非活动副本并保持块服务中的数据流，非常重要的是开始重新复制分片到另一个存储位置，这样，EBS 很快就可以承受另一次打击而不丢失数据。这种情况并不多见，但是如果很多服务同时出现故障，那么跟踪所有活动和非活动的所有状态并复制 EBS 卷分片的数据库必须具有超快的速度和超高的弹性。因为 AWS 处理数百万卷，所以在 EBS 下的配置管理器很容易在大范围停机期间不堪重负。

像谷歌的人（如 Eric Brewer，是这家搜索引擎巨头的基础设施副总裁，早在 1998 年，他就正式提出了分布式数据库和数据存储的CAP定理）、亚马逊的人，他们都清楚地意识到有三件事需要考虑——一致性、可用性和分区容错性，所以缩写为 CAPT 是不是更好呢？——你只能把这三个事中的任意两个做好。在实践中，分布式数据库和数据存储设计师会设法将三件事都尽可能做到 100%，谷歌的全球性关系数据库 Spanner 就通过一个巨大的核时钟同步控制平面，这是一种方法，支撑 EBS 的 Physalia 数据库需要一个非常不同的方法，创建一个大规模并行并智能地存放随实际的 EBS 存储块一起迁移的元数据，因此，从根本上缩小存储服务中断的波及范围。

构建块

亚马逊的弹性计算云虚拟机计算服务（或称为 EC2）及其伴侣简单存储服务对象存储服务（或称为 S3）都是在 2006 年 3 月首次露面，亚马逊在恰当的时间（刚好在“大衰退”之前）推出的恰当的产品引发了已经进行了将近 10 年的效用计算的第二波浪潮，并最终取得了成功。S3 适合于很多场景，有很多有状态的应用程序都需要比 EC2 实例中当时可用的临时存储更大一些的东西，还需要块存储来运行数据库之类的东西，数据库需要块存储，而且还需要其具备相当的规模。EBS 于 2008 年 8 月推出，它允许客户直接访问原始存储，或者使用自己选择的文件系统对其格式化，然后从 EC2 实例挂载。

在 EBS 设计上，你可能会认为亚马逊所做的就是创建一种巨大的虚拟化的集群存储区域网络，利用商用服务器和存储附件，开始时是磁盘，后来搭配使用了磁盘和闪存，所有链接都是通过公共云和超大型数据中心使用的巨大的 Clos 网络 。但亚马逊并没有这么做。相反，EBS 是一组较小的虚拟块存储设备，最初，卷大小可以从1GB调整到1TB，最多仅为每个客户分配 20 个卷。

现在，使用 gp2 实例的基于闪存的 EBS 服务可以从 1GB 扩展到 16TB，每个卷的最大吞吐量为 250 MB/秒，每个 EC2 实例的最大吞吐量为 2375MB/秒；每秒 I/O 操作可多达到 80000 次。io1 实例的 IOPS 和吞吐量是其四倍，成本仅高出 25%外加增加的 IOPS 费用。使用 st1 实例的基于磁盘的 EBS 服务可以从 500GB 扩展到 16TB，每个卷的最大吞吐量为 500MB/秒，最大 IOPS 为 500。卷可以组合在一起跨应用程序提供 PB 级的容量。基于 EBS 磁盘的 sc1 实例只有一半的 IOPS 和吞吐量，成本略高于 st1 实例的一半。这四种不同的 EBS 实例类型允许客户针对不同的工作负载调整其 EBS 性能（在带宽和延迟方面）和容量。

EBS 本身并不是一个单独的、巨大的虚拟 SAN，这是一件好事，因为它使得这个块服务更容易管理，而且，由于 Physalia 数据库的发明，它也更容易从失败中恢复过来。这也是为什么 AWS 可以承诺在其某个区域的可用性区域内实现 EBS 服务 99.999%的可用性。多个数据中心组成一个可用性区域，其中每个可用性区域各有自己的电源、冷却系统和设施，外加一个非常粗粒度的波及范围，这些可用性区域一起组成一个 AWS 区域。我们知道 AWS 有 22 个区域，总共 69 个可用性区域，但是，我们不知道每个区域有多少个数据中心，因此，我们无法轻易地估计出 AWS 可能有多少个计算和存储服务器。可能是数百万台服务器和数千万个 EC2 实例，以及数百万到数千万个 EBS 卷。我们有一种感觉，EBS 的卷是以百万计的，因为 Vogels 说有“数百万个”小型的 Physalia 数据库。

题外话：AWS 说的是僧帽水母——一个准独立的生物群作为一个整体运作，我们视为一个水母——准确地说，EBS 服务本身就是受到这种基于单元格的架构的启发，实际上，大多数具有弹性的云服务都是如此。

当突然遇到麻烦

根据 AWS 的 Marc Brooker、Tao Chen 和 Fan Ping 等人撰写的Physalia论文，2011 年 4 月，发生了一件非常糟糕的事情，让这个云巨头重新思考了 EBS 的控制平面数据本身的存储方式。对于正在使用 EBS 的 EC2 实例，EBS 控制平面必须跟踪连接到该实例卷中的所有副本分片，然后将所有这些配置数据存储在一个数据库中，该数据库也存储了 EBS API 通信流。它工作得很好，直到有一次有人修改了网络，意外导致了网络分区，致使一个可用性区域中 13%的 EBS 卷变暗。随之而来的是一场网络风暴，在查找数据的 EC2 实例、存储数据副本的 EBS 节点和可以将备份指定为主节点并将数据提供给那些 EC2 实例的 EBS 控制平面之间。但是随后出现了竞争条件，EC2 实例阻塞了 EBS 控制平面，导致它无法重新映射数据，EBS 服务进入了衰退状态，影响了所有 EBS API 的性能和可用性区域内的可用性。

他们花了好一段时间才弄清 EBS 那天发生了什么事。在 2013 年，AWS 着手创建一个新的数据库，用于处理故障期间出现峰值负载的情况。这时，需要将 EBS 卷中的所有分片从主副本转移到备份，新的备份会被创建并分配，这样就可以提供高可用性，以及强一致性，最大限度地减少停机的波及范围。

AWS 技术人员的主要观点是，并非所有 EC2 客户端都需要随时访问所有 EBS 数据——实际上，出于数据安全和主权的考虑，对于公有云实用程序来说，这是一件非常糟糕的事情。因此，用于控制 EBS 分片复制的 EBS 卷分区的键可以跨网络分布在多个数据库中，而不是一个。

AWS 高级首席工程师 Marc Brooker 解释说，“很明显，有多种因素可能导致中断，波及范围将根据原因不同而变化。使用 Physalia，我们为每个卷创建一个计算单元格，因此，计算单元格的逻辑故障——不管是由网络分区引起的，还由断电或其他原因引起的——与单个 EBS 卷的故障是隔离的。这与以前的架构差别很大，之前是通过将大量的卷组合在一起来获得规模优势。”

Physalia 是一个键值存储，它不保存客户数据，只保存分区数据的键，这些分区数据控制着数据及其副本的位置。而且，由于它已经知道了数据卷的位置和 AWS 数据中心的拓扑结构，以及 EBS 卷的物理位置，所以它可以移动这个 EBS 控制平面的数据，使其始终靠近使用它的 EC2 客户端。因此，在一个可用性区域或区域里，网络分区或其他类型的故障导致竞态条件（比如当 EBS 控制数据被塞进 API 数据库，而不是像现在这样的独立式和分布式）的可能性会降低，因此，EBS 从这些错误中恢复（或更准确地说不受他们影响）的可能性要高得多。波及范围更小。

这个过程很复杂，这就是水母的角色。僧帽水母实际上是一个独立生物体的集合，它们不能离开这个生物群体而生活。

控制 EBS 分片分区的键被分割并复制到 7 个节点（不是物理服务器节点，而是分布式状态机的逻辑元素），当节点中的数据发生变化时，使用 Paxos 协议在节点之间建立共识；其中一个节点被指定为 Paxos 单元中的主节点，它会一直承担这项工作，直到失败，然后由其他节点接管。这种方法使得分布式 EBS 控制平面数据可以获得极高的一致性。实际上，存储在 Physalia 中的 EBS 控制数据的可用性大约是存储在分片 EBS 卷中的客户数据副本的 5000 倍。

重点是：不再采用 EBS 之前的集中式控制平面，而是一个 Physalia 单元格的集合（包含由 Paxos 连接的数理逻辑数据节点）进行控制，这些微型数据库分布在 AWS 基础设施中的物理服务器节点上，它们的移动方式要保证它们被保存在与 EBS 卷分片相关联的 EC2 实例附近。

这种单元格具身于小型的 Physalia 数据库中，是 AWS 得以减少 EBS 波及范围的原因。节点可以在单元格之间共享，这意味着，随着 EC2 实例的移动，节点数据可以转移到更靠近那个 EC2 节点的另一个 Physalia 数据库，在快速切换到新位置之前，有一个逻辑单元格需要延伸一下，而又不会将 Paxos 节点之间的连接破坏到单元格中的主节点失败，进而导致定位和复制数据方法失效的程度。单元格的位置存储在一个最终一致的缓存（称为发现缓存）里。显然，这并不需要完全一致才能很好地工作。

那么，从集中式数据库转移到面向 EBS 控制平面的 Physalia 会有什么影响呢？请看下面这两个图表：

上面左边的图显示了在 Physalia（绿线的左边）之前的 14 个月和在 Physalia 成为 EBS 控制平面数据存储之后（9 个月稍多点），EBS 卷的主副本试图在系统中获取配置数据的错误率。硬件和软件基础设施的故障以及过载都导致了较高的错误率；在安装了 Physalia 之后，这些问题并没有神奇地消失，但是新的分布式状态机和智能分布式控制数据（使其接近它们控制的 EBS 卷）可以在很大程度上克服这些故障。就 AWS 而言，这就是创建它的全部意义。

上面右边的图显示了每月使用旧的和新的 EBS 控制平面数据存储时错误率大于 0.05%的小时数。同样，几乎看不到。

虽然一切都很好，而且是为了激励系统架构师和站点可靠性工程师，但是 AWS 不太可能开源 Physalia。但是，勇敢的数据库设计者没有理由不模仿它，就像来自雅虎的 Doug Cutting 创建的 Hadoop 及 Hadoop 分布式文件系统，就是克隆了谷歌的 MapReduce 和谷歌文件系统，还有 CockroachDB 的创建方式很像谷歌的分布式全球性关系数据库 Spanner。那么，从理论上讲，所有类型的集中式控制平面数据库和数据存储都可以像它们控制的服务一样进行大规模的分布，并展现出 AWS 正在展现的弹性增强。

原文链接：

THE JELLYFISH-INSPIRED DATABASE UNDER AWS BLOCK STORAGE