作者 | Sergio De Simone

译者 | 平川

策划 | Tina

为了确保他们的 Spanner 数据库能够可靠地运行，谷歌工程师使用混沌测试将故障注入到类生产实例中，重点测试系统在遇到意外的故障时保持正常运行的能力。

按照谷歌工程师 James Corbett 的说法，机器、磁盘和网络硬件等为 Spanner 提供了坚实的基础，因此，它的故障率很低。但是，这还不足以保证它在任何情况下都能正常运行，包括内存故障或磁盘数据损坏、网络故障、软件错误等等。

根据 Corbett 的说法，使用容错技术是屏蔽故障、实现高可靠性的关键，其中包括检测受损数据的校验和、数据复制、使用 Paxos 算法达成共识等。但是，为了确保它们都能像预期的那样工作，就需要演练这些技术，并确保它们是有效的。这就是混沌测试发挥作用的地方，包括故意用高于生产环境的频率将错误注入到类似生产环境的实例中。

我们每周运行一千多个系统测试，以验证 Spanner 的设计和实现确实屏蔽了故障，并提供了高度可靠的服务。每个测试都会创建一个类似生产环境的 Spanner 实例，其中包含数百个进程（运行在相同的计算平台上），并使用与生产 Spanner 相同的依赖系统（例如文件系统、锁服务）。

所注入的故障包括服务器崩溃、文件错误、RPC 错误、内存 / 配额故障和云故障等类别。

服务器崩溃可以通过在任何时候发送 SIGABRT 信号以触发恢复逻辑来实现。这种逻辑需要中止所有由崩溃的服务器所协调的分布式事务，迫使访问该服务器的所有客户端故障转移到另一个服务器，并使用所有基于磁盘的操作日志来避免丢失任何仅在内存中存在的数据。

文件错误是通过拦截所有文件系统调用并随机更改其结果来注入的，例如返回错误代码、破坏读或写的内容，或者永远不返回以触发超时。

类似的方法也可以用于在 RPC 进程间通信中注入错误。在这种情况下，他们会拦截 RPC 调用并注入延迟、返回错误代码并模拟网络分区、远程系统崩溃或带宽限流等错误。

关于内存故障，Spanner 团队重点关注两个特定的行为：模拟pushback状态（即服务器过载，客户端开始将请求重定向到不那么繁忙的副本）以及泄漏足够的内存从而终止进程。类似地，他们还会模拟“配额超标”错误，这些错误可能来自任何用户的磁盘空间、内存或是闪存。

注入云故障旨在测试与 Spanner API 前端服务器相关的异常情况。在这种情况下，Spanner API 前端服务器会崩溃，迫使客户端会话迁移到其他 Spanner API 前端服务器，并且要保证，除了一些额外的延迟外不会对客户端造成任何影响。

最后，谷歌工程师还模拟了几种可能导致整个区域无法访问的情况（包括文件系统或网络中断）。在这些情况下，Spanner 会根据 Paxos 算法的仲裁结果提供来自其他区域的数据。

Corbett 总结道，得益于这种基于容错设计和连续混沌测试的方法，谷歌有效地验证了 Spanner 的可靠性。

原文链接：

https://www.infoq.com/news/2024/05/google-spanner-chaos-testing/

禁令再升级！拜登政府已不想让中国人在美从事 AI 工作了，套壳大模型的公司也危险了

德国再次拥抱Linux：数万系统从windows迁出，能否避开二十年前的“坑”？

谷歌刚刚更新了算法，顺便搞毁了几家公司

内测活动出bug损失数百万，京东启动追责；贾扬清评大模型价格战：降价拍脑袋就能做；Kotlin 2.0正式发布 ｜ Q资讯