补遗：柏林演讲，背后的技术故事

Date: 14th, Mar, 2020

引子

前些天，整理手机照片的时候，又看到了柏林，结果当晚就梦到又去演讲了。。今天睡醒，想想还是整理下，也算个记录。其实当年应公司要求，写过一篇柏林峰会的记录稿，主要用于展示峰会内容本身，后续简单修改后也发出来了。

而今天，想写写峰会演讲背后的技术故事。

故事

我的演讲题目为：《A Better VM HA Solution: Split-brain Solving & Host Network Fault Awareness》，OpenStack 官网链接里有现场视频（注：U2B，需要科学上网）。40分钟的完整演讲（25min 演讲 + 15min 提问），其实展示的是当时我们从0开始，完整预研落地的一套 VM HA 系统。方案本身的内容，就不赘述了，直接看我的峰会视频即可。下文重点聊聊，技术落地前的一系列工作。

背景

HA，全名 High Availability，作为虚拟化/云计算领域的重要功能，与传统设备/服务器应用相比，是常被用来彰显 “上云” 可靠性&可运维性优势的切入点。而原生 OpenStack 在这一领域并没特别重视，相关 Masakari 项目其实进展也不算快。所以当时部门决定，要自主来实现这个重要功能，这一部分工作也全部交给了我。所以，首要问题是分析清场景。

HA，说简单点，就是当出现影响 VM 的异常后，将受影响的 VM 及时转移到其他主机来尽快恢复业务。听上去似乎没多复杂。但如果细致想下，其实过程中有很多要点，比如：

VM 常见异常包括哪些？如何感知？哪些故障点能覆盖到？
发生异常了如何快速恢复？
如何保证在各种异常（叠加）态下，恢复过程可靠？如何解决 HA 领域著名的“脑裂”问题？
恢复中如果再次失败，又该如何处理？

以上各点都会影响到方案构成。在调研了业界各方案后，我确定了大致方向。在完成前期各种项目/方案汇报后，从17年底，我开始和几位同事投入预研工作。

预研

说是预研，其实也没多么正式。也就我带了几位同事，分三个方向做了相关的原型验证和技术选型。

1. 共享存储

实现全局资源保证，必然得有汇集点来提供唯一性保证。引入读写锁，自然就离不开共享存储。在最初立项时，目标其实很明确。由于产品主攻私有云方向，默认存储为 Ceph。所以我们第一个需要支持的场景就是 Ceph。当时其实有多种想法，最后还是直接选定了 CephFS。我们当时并没有存储虚拟化产品，所以没法借助存储虚拟化的能力来构建共享存储+读写锁。而如果引入其他存储（如 NFS 等），会带来两个问题：

相当于引入了一个可能故障点，还需要额外保证它的可靠性；
需要额外处理存储不同源的问题。

而 CephFS，之前确实还处于不那么成熟的阶段，直到 Jewel 才首次被置为 “stable and production ready”。通过对搜集的数据进行分析研读，加上我们自主测试及异常验证，认为 CephFS 是可用的：

对于本场景来说，只需要 CephFS 提供基础的文件系统功能即可；
高级的快照、容灾恢复等功能，暂不需要；
MDS 部署支持 A-A 模式，也并非必不可少——后续实际采用的就是 A-S 部署。

至此，我们确定了 CephFS 来提供共享文件系统能力。

P.S. 关于 CephFS，其实在后续数次技术交流中，被多次问到。感觉不少人还是不太放心它啊。。：）

2. 读写锁

读写锁，用于保证资源互斥。在本场景下，用于解决该领域著名的 “HA脑裂” 问题，即避免异常下的 “磁盘双写”。这一部分工作，其实是与共享存储的预研，同时开展的。

首个测试对象是 Sanlock，它基于 Delta Lease 和 Paxos Lease 来实现。前者用来保证主机 ID 唯一，而后者用来保证资源的租约锁。

测试中，我们从最初的安装配置开始，从简单场景出发，到各种异常场景下的表现，算是先摸了个底。其中发现 Sanlock 的某些行为/逻辑，和我们期望的还有些差异。比如配合 wdmd（watchdog multiplexing daemon）来 Fencing 主机等默认行为，相对来说就会比较危险。

功能测试之外，我们也大致测试了下性能。说”大致”，是由于当时实验环境有限，只分到了两三台主机，没条件协调足量物理机来做实机测试。。没办法，这一部分也得测试下不是？后面我们想办法，专门定做了个镜像，通过 VM 方式，模拟了 Sanlock 在多主机场景下的表现：

采用 VM 的方式来模拟主机 Delta Lease；
然后通过进程的方式来模拟 VM 来获取租约。

当时两台计算节点，每台启动 40-50 台 VM，整体响应还在可接受范围内。后续还结合 CephFS 进行了专门的异常验证。

以上这些经验，都为后续我们实现底层锁，积累了不少经验。

3. 数据通道

数据通道，在系统功能定位中起了承上启下的作用。我对它有三点诉求：

记录关键数据；
- 下层：通过客户端，将各节点信息汇总上来；
- 上层：读取数据来决策。
需要保证性能、可靠性与一致性；
尽量简单。

最开始想到的，就是 OpenStack 组件中默认使用的 DB+MQ 方式。简单试了下，觉得有些过于复杂了。先不提复杂配置，就这个客户端写起来用起来就要花些时间。

所以，后续考察的重点，放到了当前容器领域用的很多的 Consul 和 Etcd。两者都基于 Raft 协议，提供了一致性 k-v 存储能力，使用简单，在服务发现领域用的很多。我们当时分别用 Consul 和 Etcd 构建集群，测试了下相关表现，技术方面两者能力其实差不多：

Etcd 简单但功能足够；
Consul 多了健康检查与多数据中心支持等。但有些功能我用不上。

此外，我对比了下社区应用度，加之部门有容器团队维护 Etcd，所以最终选择了 Etcd 作为 HA 系统的数据存储源。

为什么没选用 Masakari 项目使用的 Zookeeper 呢？—— 来自与 Masakari 项目 PTL S.Priyankara 及 SIG 技术 Leader A.Spiers 的会后交流。

这个问题，其实在预研阶段，我就考虑过。主要是因为 Java 编写的 Zookeeper，对我们来说复杂度太大了。我前东家之前的系统管理系统，就是基于 Zookeeper 来构建的，在当时最初开发联调时遇到/攻关了不少问题。。而我们当前团队也不具备相关经验，所以之前就排除了。

就后续系统表现看，我还是认为 Etcd 是更适合我们的选择。

实现

在完成预研工作及正式立项汇报后，就进入了忙碌的开发流程。从文档撰写、团队组建、方案串讲、迭代开发

、交付验证，一步步走来，有了HA系统最终的模样。也才有了柏林峰会上的 40分钟演讲，和这篇回顾。

结语

整篇故事写下来，其实没多么精彩，不含波澜壮阔的背景和曲折的情节，只有一个个人与事的连接。但正如恢弘的教堂从一瓦一砖而来，技术也需要日积月累。成品背后，其实蕴涵着很多人的心血和多个日夜的努力。

谨以此篇，记录技术背后的故事，以及那段日子。