本文最初发布于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

创作场景

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