OPED 是 (我自己发起的) One Paper Each Day 挑战, 即每天(偶尔)读一篇 Paper, 领域不限.

这是 OPED 挑战的第十一篇, 论文为 Millions of Tiny Databases

今天介绍的这一篇论文是 AWS 发表的. 它描述了 AWS 为了保证 EBS (大概可以翻译成云盘?) 正确地做 replication 和 fail over 而实现的一个兼顾 C 和 A 的系统.

名字的由来

Physalia 中文名叫僧帽水母。

虽然僧帽水母像水母，但其实是一个包含水螅体及水母体的群落。

今天介绍的 Physalia 这个系统，某种意义上来说和 Physalia 这个生物有点相似.

另外, Physalia, 又被称为 Man-Of-War. 虽然我知道没有什么关系，但我还是不由自主地联想到了人民战争的汪洋大海，以及集中力量办大事的优越性。

要解决的问题

熟悉 AWS 的朋友想必都知道，EBS 为 EC2 提供了块设备 (block device)，EC2 可以像挂载普通硬盘一样挂载它。然而，EBS 在实现上并不是一个真的本地硬盘，而是通过网络访问的。为了不让使用者操心这些，同时也是为了保证高可用，EBS 会做 Replication 和自动的 Fail Over，保证一个 EBS 节点挂了或者网络分区了，EC2 仍然可以不受影响。

为了做到这一点，我们就需要有一种强一致的方式，获取一个 EBS 到底有哪些备份，以及到底哪一个备份是当前的 Primary。这个问题在分布式场景中很常见，我们往往是通过某个实现了共识算法的组件来解决这个问题，例如使用 etcd，zookeeper等等。然而这种系统的一个问题是，如果出现了网络分区，分区中较小的一块中的所有节点，都无法工作了（i.e. 这是一个 CP 系统）。

Physalia 的目的，就是实现一个配置服务，在保证强一致的情况下，尽可能保证高可用。

核心思路

核心概念

为了解决上面提出的问题，Physalia 提出了两个核心概念:

  1. Blast Radius: 一个 Failure 波及的用户数量。像 zookeeper 这种服务，Blast Radius 就相对比较大。
  2. Correlation of Failure: 我们经常听到两地三中心这种说法，它的意思是在两个空间上分割的地点部署三个数据中心。这样做的目的是为了提高数据中心出现问题这种事件的独立性。

思路

Physalia 解决问题的核心思路就是

利用对网络拓扑的理解，构造更细粒度的 Paxos Group，每一个 Group 只负责处理一小部分节点，从而减少 Blast Radius

具体做法

Physalia 将一个配置服务中的所有节点（Colony），分成若干个 Cell。每一个 Cell 包含了 7 个 Node。每一个 Cell 构成了一个 Paxos Group，并且 Cell 之间都完全独立，不互相依赖。每一个 Cell 都只负责一小部分 EBS 的配置，保证了如果一个 Cell 中的网络不通，或者节点挂了，只会有一小部分 EBS 收到影响，从而减小了 Blast Radius。

Cell 和 EBS 的分配

上面的思路已经比较明确了，需要注意的一点是怎么来决定哪一个 Cell 负责保存哪一个 EBS 的配置信息。这里就需要 Physalia 对网络拓扑有了解，保证每一个 Cell 和 EBS 的距离不会很远，否则”路上”任一一段网络出了问题，就会波及更多的节点，做不到减小 Blast Radius。

Reconfiguration

除了 EBS 和负责它的 Cell 之间的距离不能太大之外，Cell 和使用它的客户（EC2）也不能太远。因此 Physalia 中包含了一个 control-plane 不断的优化 Cell 的放置，优化网络距离。由于每一个 Cell 中保存的数据（只保存了它负责的少量的 EBS 的配置数据）很小，数据迁移的开销也很小。

总结

我感觉 Physalia 的思路就和我标题了说的一样，分散力量办大事。它将一个大问题拆解成了独立的小问题，然后再独立地解决这些小问题。它的思路很有意思，但是这样做的代价就是让整个系统变得更加复杂。尤其是在引入了 Cell 的动态分配之后，整个系统的可预测性似乎也受到了影响，要是出了什么问题，感觉很难查错。