写点什么

数千台设备的软件和操作系统,每两周升级一次,这是怎么做到的

  • 2019 年 9 月 25 日
  • 本文字数:6016 字

    阅读完需:约 20 分钟

数千台设备的软件和操作系统,每两周升级一次,这是怎么做到的

任何曾经管理过几十上百台物理服务器的人都知道:确保所有服务器始终安装最新安全更新,或者保证所有服务器的配置和状态相一致,这始终是一件很难完成的任务。为了解决这个问题,系统管理员通常会使用PuppetSalt等工具,或将应用程序部署到容器中。如果整个环境都能由你控制,这些当然都是很棒的方法,但如果你使用了类似BCDR一体机之类的设备(或者任何未部署在自己基础架构内的一体机/服务器设施),这些方法往往就不怎么实用了。除此之外,替换系统内核、安装大型系统升级,或安装其他需要重启的大型补丁,此时也无法适用这些方法。


当我们使用的 BCDR 设备面临这些问题后,我们开始寻找其他更可行的方法,并且真的有所收获。近两年来,我们为超过 80,000 台设备使用了这种方法,效果一直很稳定。本文我将谈谈我们是如何通过镜像、回环设备(Loop device)以及大量和 Grub 有关的“魔法”解决这个问题的。如果对此话题感兴趣,欢迎继续阅读下去。


从头到尾使用 Debian 软件包?

我们的 BCDR 一体机始终运行了 Ubuntu,因此在更新软件时,最自然的方法就是使用 Debian 软件包。过去很长时间以来都是这样做的:每两周,我们会为 Ubuntu 10.04/12.04(没错,我知道你有疑问,请继续读下去!)构建所需的发布,经过全面测试后将其正式部署出去。


很长时间以来这样做完全没问题,但这种做法有一些很明显的不足之处:


第三方依赖项的更新:使用少量 Debian 软件包,这容易让人觉得只需要为自己的软件负责,而不需要为一体机中运行的其他软件负责。如果你只使用了自己的 datto.deb,但此时 Apache、Samba、libc 甚至 PHP 的更新管理工作其实同样重要。鉴于我们作为 Datto,本身所销售的就是完整的一体机,当然也就需要负责管理整个栈,尤其是第三方软件的安全补丁等内容。


服务重启动/重引导:对于一些需要重启动服务甚至重引导计算机的大型更新,依赖项问题也会变得异常棘手。当然,Debian 软件包自己就应该能处理服务重启动问题,但实际上并非所有软件包都能妥善搞定。并且一旦需要重引导(例如需要升级系统内核),还需要确保不会打断重要的设备任务(例如备份、虚拟化……),此外还要保证设备最终能引导成功(这事情并不像你想的那么容易,下文将会详细介绍!)。


发行版升级:如果整个操作系统的版本需要升级,这才是最麻烦的地方。举例来说,如果只使用 apt-get dist-upgrade 命令以及 reboot 命令将 Ubuntu 10.04 升级到 16.04,整个过程将变得漫长无比,并且很多时候可能会升级失败(只要你用过 usedapt-get dist-upgrade,那么肯定会明白)。


数千个版本和状态:在 Debian 的升级模型中,“设备”的实际行为其实和普通计算机无异:刚刚创建好镜像并部署后,一切都是崭新的,一切都可以正常运转。但随着镜像越来越老,操作系统退化的问题就变得越严峻,导致不同设备的状态产生巨大差异。能严重到什么程度?我们的设备(在切换到 KVM 前)曾经使用了 40 个不同版本的 VirtualBox、25 个不同的 ZFS 版本,以及超过 80 个不同的 Linux 内核!


其实,实际遇到的问题远比上面列出的更多,不过这里就不拿更多问题来给大家添堵了。快速开始介绍最有趣的内容:如何解决!


使用镜像,而非软件包!

鉴于会遇到这么多问题,很明显,我们需要用更好的解决方案来管理设备状态和配置。产品中不同的设备配置/软件包/版本数量不仅要降至最低,并且在每次升级时必需能保证能够升级整个栈:不仅要能升级我们自己的软件,还要能升级第三方软件,甚至诸如 Libc 或系统内核等系统库。


前提要求

随后我们开始确定这个解决方案的前提要求,其实这些要求并不多:


所有设备沿用相同的升级路径,并且只存在一个升级路径。


所有设备均可通过这种方式升级(哪怕操作系统盘较小的老设备)。


从一个版本切换到另一个版本的过程必需满足原子性要求(或尽可能满足这种要求)。


(如果升级失败)能够回滚到上一个版本。


而这些要求还暗含了一个最重要的前提条件:不能继续使用基于软件包的升级方法了,并且(从字里行间也能体会到)在升级过程中重引导一体机,这是可以接受的。


这些都是很大胆的念头。我们确实做出了一个重大决定!


那么镜像到底是什么?

为了减少配置的数量,我们决定不再将我们的软件及其所有依赖项看作不同个体,而是将所有这一切组合成一个统一的可交付物:镜像。


那么镜像到底是什么?镜像(在我们的环境中)是指一种EXT4文件系统,其中包含了引导和运行 BCDR 一体机所需的一切,例如:


Ubuntu 基础操作系统(内核、系统库……)


必需的第三方工具和库(Apache、KVM、ZFS……)


Datto 设备软件(我们的营销团队将其称之为 IRIS)


下图就显示了一个这种镜像所包含的内容:



我们对这种想法非常激动,因为通过使用镜像,只需要一个数字,也就是镜像的版本号(例如上图中的“415”)就可以定义所安装的每个软件的具体版本。再也不用针对多种 ZFS 版本测试我们的软件,更不用暗自祈祷我们的软件能兼容所有 KVM 版本。太棒了!


基于镜像的升级

做出所有这些重要决定后,我们依然需要通过某种方法来构建、分发,并在设备上引导这些镜像。具体怎么做呢?


构建镜像

通常来说,每次标记了一个新的发布(或发布候选)后,我们会自动构建镜像:每次在 Git 中推送标签后,一个 CI 工作进程会开始构建镜像。构建过程本身也挺有趣,不过已经超出了本文的范围,但为了不吊大家胃口,下文将简单介绍这个过程:


我们首先会为自己的软件构建 Debian 软件包,并将其发布至一个 Debian 仓库。随后使用aptly(参阅“Datto packages”一图)为这个 Debian 仓库创建快照,同时还会定期对一个上游 Ubuntu 仓库(“Upstream packages”)执行类似操作。随后使用debootstrap创建一个 Ubuntu 基准系统,并将我们的所有软件及其依赖项安装到一个Chroot中。一旦完成这些操作,会对其创建 Tar 归档并 Rsync 到我们自己的镜像服务器。在镜像服务器上,我们会提取出 Tarball 并 Rsync 给最新镜像,这个最新镜像位于一个格式化为 EXT4 文件系统的ZFS卷(zvol)中。在将所有未使用的 EXT4 块归零后,会对包含该文件系统的 zvol 创建最终快照。


因此在镜像服务器上可以看到类似下图所示的内容:



上述 zvol 包含了我们 BCDR 一体机的 EXT4 文件系统。这就是一个镜像,也是我们唯一需要交付的东西。它可以作为一个整体进行测试,一旦通过了 QA 流程,就可以分发到客户的 BCDR 设备中了。


分发镜像

在成功构建镜像后,又该如何将其从我们的数据中心发送给超过 8 万台设备?很简单,我们使用了ZFS send/recv


我们的所有设备都具备 ZFS 池,其中存储了设备的镜像备份,并且之前我们就在大量使用 ZFS send/recv 为这些备份提供离场保存能力。而此时只不过是换种方向使用这种技术。


我们是这样做的:需要升级时,会让一部设备通过 HTTPS 下载 ZFS sendfile diff(之前曾经尝试过直接通过 SSH 使用 ZFS send/recv,但这种方式无法进行缓存):



从上图中可以看到,通常并不需要下载完整镜像,因为设备以前就升级过,已经在本地池中保存了镜像的一个版本。这就很棒了:通过这种技术,我们可以进行差异化的操作系统升级,也就是说,设备只需要下载镜像中有变化的块。


这是一种双赢的结果,因为不会过多占用客户网络带宽,而我们自己的数据中心也可以节约一笔带宽费用。


下载好的镜像会被导入本地 ZFS 池。这对于下一次升级很必要(可以确保只需要下载有变化的内容):



引导镜像

拿到镜像后,如何引导至这个新的文件系统?如果我们构建的每个镜像版本都是全新操作系统,又该如何从一个版本引导至下一个版本?


ZFS-on-root、A/B 分区和 A/B 文件夹

毫无疑问,这些问题的答案并不只有一种。我们可以通过多种方法使用镜像生成可引导的系统,因此需要多次实验找出一种最佳方法。


这个过程也很有趣,因此我准备简要介绍每种方法,以及最终未选择这些方法的原因:


ZFS-on-root和 A/B 数据集:我们的镜像备份操作中大量使用了 ZFS,因此一开始很自然就觉得也可以将 ZFS 用作一体机的根文件系统。为此可以将 BCDR 一体机的镜像作为一个 ZFS 数据集(而非上文提到的 zvol)来进行分发,对其进行克隆并直接引导至 ZFS 的克隆副本。由于Grub的新版本已经可以支持读取 ZFS,此外还提供了 ZFS initramfs 模块,ZFS-on-root 绝对是可行的。如果要从一个镜像升级到下一个(例如从一个 ZFS 数据集升级到下一个),只需要更新 Grub 的配置并重引导就行。这种方式可以正常起效,但因为引导至 ZFS,这是一种比较新的做法,我们认为其成熟度还不足以满足我们产品的需求。不予考虑。


简单的 A/B 分区:有些一体机和手机会使用两个分区,其中一个包含当前系统,另一个包含下一个系统。这种思路也很简单:下载新镜像,将其 Rsync 到不活跃分区,更新 Grub,然后重引导。然而这种做法的问题在于,我们的有些设备不具备额外创建一个分区所需的存储空间(或者至少需要重建分区)。我们在实验中尝试过在首次重引导过程中,从 initramfs 内部将活跃根分区拆分为两个并且成功了(挺酷的对吧),但考虑到这将要用于我们的主要产品,该方法风险太大。不予考虑。


引导至 A/B 目录:由于一些设备缺乏备用分区,我们还实验过将镜像的两个副本保存到根分区中的两个文件夹中(例如一个/images/412 和一个/images/415),随后修改 initramfs 引导至/images/415,而非引导至/。不管你信不信,虽然听起来挺疯狂,但这样做竟然也成功了,并且整个方法也超级简单,只要对 initramfs 进行少量修改:mount --bind /images/415 /root 改成这样就行。一切都可以正常运转,不过很多 Linux 工具(df、mount……)会因为根目录不是/而遇到一些问题,所以这个方法也不予考虑。


循环往复,这就够了!

在尝试过用多种方法引导镜像后,我们最终采取的做法似乎感觉有些无趣。不过无趣也是好事对吧!


我们发现,如果要引导一个镜像,最简单可靠的方法是利用 Grub 的回环引导(Loopback booting)机制,并配合initramfs对 Loop 的支持(请参阅 loop=…参数):


众所周知,Grub 是种引导加载器(Boot loader)。它的责任是加载初始的 RAM 磁盘和内核。为此,Grub 内置了对很多文件系统的读取能力,并能通过loopback命令支持稍后将要提到的“文件系统中的文件系统”。loopback 命令可在根分区找到镜像文件并对其进行环回(Loop),这样就可以照常使用 linux 和 initrd 命令找到内核和 RAM 磁盘。例如我们在设备 grub.cfg 文件中(通过/etc/grub.d 中的钩子)生成的菜单项范例如下所示:


menuentry 'Datto OS (v415.0)' {  search --set=root --no-floppy --fs-uuid 8c43bf01-046c-401c-8cb8-97cb658ef698  loopback loop /images/415.0.img  linux (loop)/vmlinuz root=UUID=8c43bf01-046c-401c-8cb8-97cb658ef698 rw loop=/images/415.0.img ...  initrd (loop)/initrd.img}
复制代码


在这个例子中,Grub 首先会通过 search 以及 UUID 寻找根分区(就像对常规安装的 Ubuntu 做的那样)。随后会发现根分区中的镜像文件/images/415.0.img,最后找到镜像中的内核((loop)/vmlinuz)和 RAM 磁盘((loop)/initrd.img)。


整个过程异常简单,但同时却非常酷:引导加载器竟然能这样做,这一点让我大为惊奇。


当 Grub 找到内核和初始 RAM 磁盘后,会将 RAM 磁盘载入内存(震惊!),随后挂载根文件系统,最后将控制权转交给 init 进程。


在 Ubuntu 中,initramfs-tools 软件包提供了创建和修改初始 RAM 磁盘的工具。幸亏该软件包已经可以支持回环引导机制,因此一般来说除了需要在内核行传递 loop=参数,其他什么都不用做。如果设置了该参数,initramfs 会用回环的方式,使用 mount -o loop(参阅源代码)将根文件系统加载至镜像。考虑到代码中有一条相当吓人的 FIXME 消息(# FIXME This has no error checking),我们认为最好能提高它的弹性,为其增加错误处理和 fsck 能力。不过大部分情况下,使用 initramfs 都可以顺利引导并且不显示任何信息。


就是这样,一个简单的解决方案,洋洋洒洒写了这么多。


这种方法在实践中用起来是这样的。如图所示,该设备的根文件系统位于/dev/loop0,该回环设备在 initramfs 中设置而来,指向了一个镜像文件:



本例中,镜像是位于根分区(如/dev/sda1)下的/images/412.0.img。请注意,如果镜像中存在空的/host 文件夹,initramfs 会将根分区挂载在这里:



镜像间的升级

我们已经可以构建、分发并引导镜像。如果将这一切结合在一起就会发现,从一个镜像到下一个镜像的升级其实一点也不难:


清理老镜像,下载新镜像,导入到池,导出到镜像文件。


将配置从当前镜像迁移到下一个镜像。


更新 Grub 以指向新镜像。


重引导。


我们所做的就是这样。为此还开发了一个名为 upgradectl 的工具:



upgradectl 通常可由我们的签入进程远程触发:在设备正常运转的过程中,它可以下载并导出镜像(第 1 步),借此在后台为升级过程做准备。需要进行升级时(通常是夜间的设备闲置时段),实际的升级过程将非常快速地完成,因为只需要迁移配置,更新 Grub 并重引导(第 2-4 步)即可。一般来说,升级过程中的设备停机时间约为 5-10 分钟,并且这主要取决于重引导所需的时间(大型设备可能需要更久,因为需要IPMI/BMC初始化)。


当然,这一过程中也有数不胜数的问题和边缘案例需要考虑:听起来确实简单,但想要做对其实并不容易,尤其是考虑到我们现有的 8 万台一体机中,有些在生产环境中连续运转已经有超过 7 年时间了。


但这也造就了一些有趣的挑战:我们已经将数千台设备从 Ubuntu 12.04(甚至 10.04)直接升级至 Ubuntu 16.04。如果升级过程因为某些原因失败,会通过一些逻辑来处理老镜像的回滚。我们处理了完整的操作系统盘、有故障的硬件(磁盘、IPMI、RAM……)、配置为 RAID 的操作系统盘以及 Grub 无法向其中写入的问题,当然还有 ZFS 池出错、Linux 进程挂起(D 状态)、重引导挂起等各种问题。


但是你猜怎样:这一切都是值得的。这就好像结束了一场为期 7 年的寒冬之后进行的春季大扫除。我们让这些设备重新焕发了生机,并且这样的工作还将继续,每两周进行一次!


总结

本文介绍了如何将 BCDR 一体机的部署流程由基于 Debian 软件包的方法改为基于镜像的方法。此外还介绍了构建、分发镜像的方法,以及如何使用 Grub 的 loopback 机制引导镜像的做法。


虽然这种基于镜像的升级方法的诞生有我的全程参与,但这其中最让人激动的一点在于:借助这种机制,我们甚至可以在不同内核,以及不同的操作系统大版本之间切换。每次发布升级后,我们都可以有效地引导至一个全新操作系统,这意味着系统不会随着时间的延长而退化,所有手工改动都会被消除,甚至从技术上来看,还可以在愿意的情况下切换使用不同的 Linux 发行版。


并且这一切都是在后台进行的,完全无需用户介入,对用户来说完全透明:每两周对 8 万个操作系统进行升级,这该有多酷啊!


本文最初发布于Datto Engineering博客,原作者 Philipp Heckel,经原作者授权由 InfoQ 中文站翻译并分享


原文链接:


80k operating system upgrades every two weeks


2019 年 9 月 25 日 18:022348
用户头像

发布了 283 篇内容, 共 91.7 次阅读, 收获喜欢 50 次。

关注

评论

发布
暂无评论
发现更多内容

HashData与HDFS的高效数据交换

HashData

万字长文,肝了一下午的线程池详解!

JavaFish

Java 多线程 线程池 线程池工作原理

话说 类加载过程 第一篇

木子的昼夜

Flink SQL CDC 实践以及一致性分析

Apache Flink

flink

终于学完国内算法第一人10年经验总结的数据结构与算法详解文档

Java架构之路

Java 程序员 架构 面试 编程语言

阿里P8亲自教你!2021Android大厂面试知识分享,实战篇

欢喜学安卓

android 程序员 面试 移动开发

我用一个小小的开放设计题,干掉了40%的面试候选人

架构精进之路

Web 安全 软件设计 3月日更

HashData外部表的实现与应用

HashData

【2021 ECUG Con】聚势而来,与你相约花开时

小剑客

区块链 云计算 大数据 开源 Go 语言

Elasticsearch Inverted Index

escray

elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试 3月日更

COPU助力北大研究生开源公选课丨开源PostgreSQL研发课程成功进入北京大学

PostgreSQLChina

数据库 postgresql 开源 开源社区

阿里P8手把手教你!万字Android技术类校招面试题汇总,附赠课程+题库

欢喜学安卓

android 程序员 面试 移动开发

ZooKeeper 的选举机制,你了解多少?

架构 分布式

数字经济时代,区块链能否担当产业数字化转型核心赋能者?

旺链科技

区块链数字经济 区块链发展

2021年爆锤39K月薪Offer!阿里巴巴Java面试(知识点)整理

Java架构之路

Java 程序员 架构 面试 编程语言

大作业

yoki

江苏交通控股打造IT架构云转型下的智慧交通

HashData

2021年4款好用的音乐编曲软件推荐

奈奈的杂社

音乐信息检索:理性解构音乐

阿里云视频云

阿里云 算法 音频

HashData多集群共享统一存储架构

HashData

一周信创舆情观察(3.1~3.7)

统小信uos

最新蚂蚁五面、拼多多三面、字节四面(已入职拼多多),个人面经分享

Java架构之路

Java 程序员 架构 面试 编程语言

如何用一个月的时间啃完英语词典?

wbliu85

[TcaplusDB知识库]键值型数据库TcaplusDB是如何进行数据读写的?

TcaplusDB

数据库 nosql 后端 TcaplusDB Tcaplus

快了何止300%?阿里巴巴Java优化:设计+程序+并行+JVM+工具

Java架构追梦

Java 阿里巴巴 架构 面试 性能优化

《精通比特币》学习笔记(第七章)

棉花糖

区块链 学习 3月日更

大作业

胡益

新的RBAC:基于资源的权限管理(Resource-Based Access Control)

龙归科技

资源 权限管理 rbac

轻量级的接口自动化冒烟框架

小小娃爱吃甜食

自动化 测试 框架 自动化部署

寻找被遗忘的勇气(十一)

Changing Lin

3月日更

KubeNode:阿里巴巴云原生 容器基础设施运维实践

阿里巴巴云原生

阿里巴巴 容器 运维 云原生 k8s

数千台设备的软件和操作系统,每两周升级一次,这是怎么做到的_架构_Philipp Heckel_InfoQ精选文章