Let it Recover!

原创
01/04 17:45
阅读数 17

许多用户问我们:RisingWave 如何容忍故障和保证高可用?这篇文章是对该问题的回应。

我的上一份工作是开发分布式 OLTP 数据库,当谈论起高可用、故障容忍这些 buzzword 的时候,我总会不由自主地联想到多副本、Paxos、WAL(Write-Ahead Log)等名词。或许你也一样如此?看来我们都是合格的系统设计者。

但是,今天我正想说的是,流计算真的与数据库有很大不同。流计算的全部意义在于计算,如果数据的流动停止了,那便失去了意义。在“高可用”这个主题下,数据库希望每一个写入的字节都被持久化而不丢失,而流计算的目标则是尽快恢复任务,让数据流水线再次流动起来。

不幸的是,我们无法用 Paxos 来保障流计算的高可用,而且也不值得为计算任务分配冗余的节点。那么,该怎么做呢?在揭晓答案之前,请允许我聊聊Apollo Guidance Computer 的故事。

The Apollo Guidance Computer (AGC)

你可能在互联网上看过许多有关 AGC 的 Meme,比如:Your smartphone is millions of times more powerful than the Apollo 11 guidance computers。这是真的。下面的图的就是 AGC。这个大铁盒子重达 70 磅(32kg),每秒能够执行 43,000 条指令,用今天的话说,0.043 MHz,并配有手工打造的 2K word RAM 和 36K word ROM(word 长度为 15 比特)。今天的 iPhone 15 Pro 拥有 3.78GHz 6 核 CPU,大约是它的 53 万倍,而我们只用它玩原神。

 

The Apollo Guidance Computer (AGC). Photo by Ken Shirriff, righto.com.

但是受限于篇幅,今天我们将专注在它的软件或者说操作系统的设计上。这可能是世界上最著名也是最早的实时操作系统,它拥有

  • 数码管用户界面(图中的黑白色盒子)
  • 外围 IO 设备,包括控制按钮、各种雷达和传感器
  • 为实时系统设计的调度器,基于优先队列,最大长度为 8
  • 检查点机制, Restart on failure to recover——这是今天的主角

将登月从失败中拯救的设计

AGC 的设计者认为,软件故障大多数是短暂性的。其实,不仅是 AGC、你的家庭路由器和各式各样的嵌入式设备,都面临同样的问题。网络抖动、磁盘坏道或是内存比特反转,这样的故障每天都在数据中心里发生。AGC 工作在宇宙空间中,更是如此。

与其期望每个异常都被正确处理,还不如重启整个程序,没错,这被无数次证明是最有效的方式。但是重启会丢失当前的状态,这就是为什么需要 checkpoint。程序在运行中,时常在存储中记录下“好的状态”,一旦发生故障,则重启并恢复到最后的检查点。

在 Apollo 11 号飞船的登月过程的刹车阶段(braking phase,Phase 63),AGC多次报 1201 和 1202 错误并短暂地停止工作。但所幸的是,最后飞船平稳降落在了月球上。这期间究竟发生了什么?

刹车阶段是计算最密集的阶段之一。AGC 通过导航算法不断修正飞船的姿态,从而平稳地落在月球上。这个程序消耗了 80% 的 CPU。这在预期之中。(图 a)

但意想不到的事情发生了。原本被设计为在返回阶段才会使用的 rendezvous rader 发生了硬件 bug,每秒向 AGC 发送 1000 次中断,但实际上没有输入任何信息。AGC 可怜的 CPU 被这个 bug 用掉了 15%,于是仅剩下 5% 的冗余。幸好,它依然能正常工作,没人知道雷达的问题。(图 b)

Buzz Aldrin,登月的宇航员之一,在屏幕上执行了 V16N68 号程序,这个程序用来监控登月的进程,包括显示当前离月球的距离、速度等,并且实时更新。这个程序大约消耗 10% 的 CPU。Buzz 在过去的模拟训练中已经重复了许多次这样的操作。(图 c)

但是,AGC 剩余的 5% CPU 不足以支撑这个程序,任务队列逐渐变得拥挤,直到新任务的入队请求超时,触发重启。Buzz 最不愿看到的事情发生了,PROG(program error)指示灯闪烁,紧接着,RESTART 指示灯亮起,AGC 重启了。(图 d&e)

幸运的是,重启后系统根据 checkpoint 恢复到 Phase 63 并继续执行引导程序。Buzz 手动运行的 V16N68 不在其中,毕竟它只是一个无关紧要的、无状态的监控 UI。CPU load 恢复到了 95%,可以继续正常工作。(图 a)

起初,Buzz 并不知道问题在哪里,于是他重复了上述过程几次,直到他感觉到,程序的异常似乎与他启动 V16N68 有关。当然,幸好在每一次尝试中,AGC 都正确的恢复了。这都要感谢 checkpoint-restart 机制!

回到 2023 年

今天,相比于许多闪亮的新概念,checkpoint-restart 机制称得上默默无闻,甚至连一个权威的名字都没有。但是它的灵魂又存在于许多地方,例如 erlang 以及 actor 系统所提倡的 “let-it-crash”,只不过他们没有强调保存状态的重要性,而是期待开发者将状态放在数据库中。

我尝试 Google 了这个关键词,得到的结果涉及到 HPC、MPI、Simulation 等等,它们的共同点是,都是长时间的计算密集型任务,就像流计算一样。

据我所知,Apache Flink 是第一个引入 Checkpoint 的流计算系统。Apache Flink 创新性地将 Chandy-Lamport 算法用于 checkpoint streaming jobs,我认为这一设计是它取得成功的重要原因之一。Chandy-Lamport 算法能够在分布式系统中取得全局一致的快照,这允许我们用它来恢复一个 job 而不丢失或重复任何事件(所谓的 exactly-once)。

在故障恢复这个主题上,本质上,无论是 Flink 还是 RisingWave 都遵循和 AGC相同的原则:

  • 在正常运行中,记录下可供恢复的 checkpoint,并保存在持久存储中
  • 一旦系统发生不可继续的问题,从上一次 checkpoint 恢复并尝试继续

不过,RisingWave 的实现要轻量的多

我们希望像 AGC 那样在一秒内完成重启,但是流计算的状态太大了!取决于workload,它可能从几 GB 到几 TB 不等,即便用今天的硬件,也需要一段时间来恢复全部的状态。

自从设计之初,我们就将计算节点看作几乎无状态的节点,具体地说,我们将计算节点内存以及磁盘中的数据看作缓存,有它能达到更好的性能,没有也不会影响 job 的运行。或者换一个说法,它在任务运行时 lazily 加载 checkpoint。该设计让 RisingWave 能够在毫秒级调度起新的任务而不用完整加载状态。

另一个容易被忽视的问题是 checkpoint 的新鲜度,或者说 checkpoint 频率。如果 AGC 重启后恢复到了更早的阶段,那么需要执行更多的步骤才能到达重启前的状态。流计算也是如此。例如,如果最后检查点在半小时前,那么,近半小时的输入就需要被重放,才能真正到达当前状态。

我们的解决方案是每隔 1s 进行一次 checkpoint,这听起来很频繁,不是吗?事实上,对于 S3 这样的对象存储,1 秒一次的put_object是小菜一碟。RisingWave 的存储是从头设计的,基于 LSM-Tree 结构,每次 checkpoint 仅会上传那些新的改动,这使得它能高效地进行高频率的 checkpoint。在基准测试中,在 1s、10s 或是 1min 的 checkpoint 间隔下,性能表现都差不多。

在一些糟糕的案例中,我们观察到集群以每秒约十次的速率尝试恢复。当然,这对用户并不是什么好消息,我只是试图展示恢复机制本身的快速和可靠。作为参考,基于 Paxos 的数据库往往需要更久(例如 10s 或更多)才能从故障中恢复。

 

1) 每隔 1s 写入 checkpoint 到 S3;2) 一旦故障发生,它从上一个检查点继续,但是是以 lazy 的方式——仅在 cache miss 时才会加载数据

Control plane,一般指 Kubernetes,也在这期间发挥了重要的作用。Control plane 有一套独立的 liveness 检测机制,当机器出现问题时,它会将负载即时reschedule;或者当计算节点意外退出时,control plane 会立即将它拉起。大多数情况下,control plane 会保证集群中有指定数量的节点存活。

特别地,当失去节点时,相比于立刻将任务 scale in 到更少的节点上,RisingWave 倾向于等待新的节点加入。考虑到失败很可能与高负载相关,显然,此时 scale in 听上去不是个好主意。

那么,元数据呢?

元数据是一个例外,它是一个真正的数据库,只不过是仅仅用于保存元数据,但是我们对它的要求与一个数据库并没有不同——高可用、高性能、最好还有ACID 事务。

RisingWave 的元数据保存在 etcd(我们正在重构这一部分,未来可能发生变化),一个多副本的 KV 数据库中。Meta Service 几乎是无状态的,这让它可以很容易地重启或迁移。

正如我们在大学学到的,可能出现需要网络分区的情况。Control Plane 并不总能保证 Meta Service 的唯一性,我们也永远不应该这样假设。因此,Meta Service 借助 etcd 实现了租约和 leader election 机制,确保任一时刻最多只有一个 Meta Service 为 primary,为集群提供元数据以及调度服务。

容忍外部系统故障

与内部异常相对的是外部系统的故障。作为一个流计算系统,上下游往往存在两个或更多的系统,例如,从 Apache Kafka 中消费变更,最终输出到 PostgreSQL 中。

Source 端的异常处理简单直接:将它看作“静止”,没有新的数据流入。

Sink 端则更麻烦,RisingWave 的 SQL 接口很灵活,可以容易地创建出复杂的DAG 任务,例如一个任务可能既输出到 Data lake,又将过滤和分组后的数据输出到 Kafka。一旦其中一个下游系统突然变得缓慢或不可用,那么所有连接的任务都将受到影响。RisingWave 计划为 Sink 增加缓冲队列来解决这一问题,1.3 版本中已经支持了 Kafka append-only Sink。

总结

就这样,RisingWave 的故障容忍以及高可用构建在 checkpoint-recovery 机制之上,凭借高效的 checkpoint 和 recovery,流计算任务不断重试,从暂时性的故障中恢复。

数据的持久性被外包给了 S3——一个多副本、高可用的对象存储(或任何与它相似的服务),元数据则是 etcd(一个多副本、高可用的数据库)。

最后,如果你对 Apollo 11 和 AGC 感兴趣,推荐你观看这个视频,本文的中关于 AGC 的图主要来自于这里。


关于 RisingWave

RisingWave 是一款基于 Apache 2.0 协议开源的分布式流数据库,致力于降低流计算使用门槛。RisingWave 采用存算分离架构,实现了高效的复杂查询、瞬时动态扩缩容以及快速故障恢复,帮助用户轻松快速搭建稳定高效的流计算系统。使用 RisingWave 处理流数据的方式类似使用 PostgreSQL,通过创建实时物化视图,让用户能够轻松编写流计算逻辑,并通过访问物化视图来进行即时、一致的查询流计算结果。了解更多:

官网 risingwave.com

文档risingwave.dev

GitHubrisingwave.com/github

Slack risingwave.com/slack

B 站:RisingWave 中文开源社区

微信公众号:RisingWave中文开源社区

社区用户交流群:risingwave_assistant

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部