文章来源：字节跳动新型网络装机方案HTTPBOOT(Linux)，轻松解决运维困扰

HTTPBOOT 是由字节跳动 STE 团队和 ICS 团队合作开发的新型网络装机方案，用于解决日常字节服务器装机运维中出现的一系列问题，目前已在字节机房大批量上线使用，帮助节省了大量的运维人力。

本文主要分为三个部分：HTTPBOOT Overview，HTTPBOOT 实践和 HTTPBOOT 成果与规划。通过阅读此文，能够对 HTTPBOOT 的需求背景，原理优势，发展现状以及未来方向有更清晰的了解。

HTTPBOOT Overview

在本节中，将介绍目前装机上存在的问题与需求，为什么选择 HTTPBOOT，以及 HTTPBOOT 和其他装机方案相比有哪些优势。

一、目前存在的装机问题和需求

在使用 HTTPBOOT 装机之前，装机大多采用 UEFI+PXE 方式，其 IPV4 和 IPV6 装机方式流程图如下：

暂时无法在飞书文档外展示此内容

该方式存在两个不足：

对 MAC 地址存在强依赖： 在 PXE 方式下，如果运维团队想要识别一台服务器的身份，只能通过 MAC 地址和 DUID 实现，但是使用 MAC 地址作为身份识别 ID 来对服务器装机进行管控不仅不可靠，还会带来一些问题。例如：如果手动更改 MAC 地址，或者更换网卡后，会使机器无法被正确的识别，导致装机失败。运维一般会有专门的人力去维护 MAC 地址和机器的对应关系，但人工有时也会出现错漏，还会占用更多人力去处理问题，这是一个痛点。
基于 TFTP / UDP 的传输不稳定： PXE 使用基于 UDP 的 TFTP 协议进行装机程序传输，由于装机网络的环境复杂，网络波动较大。在程序下载的过程中经常由于网络质量差导致传输失败，十分影响整体的机器交付时效。

同时，UEFI 的生态模式还带来了另一个问题：

部分装机问题依赖厂商发版解决： 如果发现问题出现在 UEFI 固件上，比如网卡驱动有问题，或者需要做驱动适配，往往需要等厂商去解决，但是受厂商解决问题发布版本的时效影响，这些问题往往不能很快得到响应和及时解决。

除此之外，ICS 团队也在积极改善和优化服务器装机交付流程，以提高效率，这些改造也带来了新的需求：

支持服务器自由上架： 以往我们在采购服务器时，会提前为每台机器在机房预留固定的机位和IP，并在服务器到货后需要把机器安装到固定的位置上。不仅流程繁琐且需要人力去维护与核对机位状态。于是我们设计了自由上架规则，无需预先对机位进行预留，机器在上架后线上进行动态绑定，启用该规则需要固件侧进行适配。
定制化引导 API 接口兼容： 为了加强对服务器装机行为的管控，以及灵活适配不同的机型，支持多种装机方案，我们开发了一个引导 API，支持根据机型和状态下发不同的指令或装机配置，但该API 需要固件支持。

而现有的 UEFI+PXE 装机方案不能解决上述问题和需求，我们迫切需要一款高稳定性、高兼容度、高可靠性、高灵活度的装机引导程序。

二、为什么选择 HTTPBOOT

1. HTTPBOOT 合作背景

（1）HTTPBOOT 由来

HTTPBOOT 最初为 STE 自研固件 CloudFirmware 中的一个规划功能。因为 PXE 装机问题一直存在。在自研服务器交付或者重装到时候，常因为装机问题影响交付，所以在开发自研固件时，将装机问题作为一个重点关注的问题去解决，进行了一些先验合作。后来 CloudFirmware 上线后，装机问题得到了有效解决；ICS 团队同学也在寻找更好的装机解决方案。于是在这些基础上开展了后续的合作。

（2）HTTPBOOT 是什么？

上文提到 HTTPBOOT 来源于 CloudFirmware，那么 CloudFirmware 又是什么？HTTPBOOT 和它有哪些联系？这里简单介绍一下。

CloudFirmware 是字节跳动STE团队自定义的适用于云厂商的固件解决方案，目前已经被 OCP，OSFF 等社区接受并推广。它将整个固件分为三层：Silicon 代码，coreboot 和 LinuxBoot。其中 Silicon 代码是 Vendor 提供的，用于 Silicon 初始化的代码。coreboot 则是平台相关的，它会调用 Silicon 代码做初始化工作，同时也对外提供一些抽象硬件接口如 ACPI，SMBIOS。coreboot 追求轻量化，希望程序越小越好，有些类似嵌入式使用的 Uboot，这点和 UEFI 是不一样的。LinuxBoot 则是一个小型的 Linux 系统，由 Kernel 和 U-ROOT 文件系统组成。

对于互联网云厂商而言，整个解决方案中，主要的交互方集中在 LinuxBoot 这一层，这样架构也具有更好的灵活性、定制性、可控性，也更适合。为什么这么说？Silicon 代码层由供应商提供，无需操心，coreboot 结构简单，大多是一些流程和框架，操作空间有限。如果需要解决固件问题或者对自研机器提供更好的底层支持，大多在 LinuxBoot 中进行开发工作。而这也是我们的优势所在，因为我们的 Linux 工程师数量远远多于 UEFI 工程师，可以又快又好的在 LinuxBoot 上解决固件问题。

而 HTTPBOOT，其实就是 CloudFirmware 将 LinuxBoot 抽离出来，只保留装机相关功能形成的工具。它不但继承了 CloudFirmware 的优点，还是一个跨平台的工具，得益于 Linux 的开源生态和 GO 语言的 U-ROOT，这使得 HTTPBOOT 在移植到不同架构和型号的机器时十分容易。

回归到装机本身来说，HTTPBOOT 的这种做法和其他装机方案以及开源装机工具相比，有哪些优势？

2.HTTPBOOT 优势

这里我们从技术方案和开源产品两个层面来进行对比，首先目前主流的几种装机技术方案如下图所示：

该图上下部分，分别是选择 UEFI 和 Linux 作为载体的方案。两者相比，从产品角度来看，使用 Linux 可以直接基于开源技术产品化，而采用 UEFI 则需要通过 IBV，很难进行产品化。从技术角度来看，Linux 拥有更强大的网络驱动和更健壮的代码，更重要的是 Linux 的开源生态可以让我们不必依赖其他厂商，直接入手解决问题。从左右对比，分别是使用 PXE 和使用 HTTP 的方法，这个更不必说，PXE 从诞生至今近20年了，它使用的 TFTP 协议相比当下主流的HTTP协议，并不能提供类似断点续传，安全加密，灵活拓展等特性。

所以综上所述，HTTPBOOT 采用的基于 Linux 平台的 HTTP 启动方案是当下最好的技术方案。同时我们也调研了其他的开源装机产品，和其他开源装机工具对比：

装机工具	支持HTTP	代码维护	健壮度
syslinux	否	依赖厂商	低
bootnet64	否	依赖厂商	低
ipxe	是	依赖厂商	低
HTTPBOOT	是	开源社区，无依赖	高

其中 ICS 同学对 ipxe 工具做过灰度测试，发现存在问题： 1. 开源版本对 IPV6 网络的支持不够好 2. 部分机型上存在适配问题。而和原有 PXE 方案对比，HTTPBOOT 在稳定性，可靠性，灵活性和兼容性上都更加出色。

毫无疑问的，HTTPBOOT 成为了我们选择的最终装机方案。

HTTPBOOT 实践

在本小节中将介绍 HTTPBOOT 的发展历程及工作原理，并结合较为实际的例子说明 HTTPBOOT 是如何解决第一节提出的装机问题和需求。

一、HTTPBOOT Journey in Bytedance

HTTPBOOT的实践发展历程分为四个阶段。

2021年：HTTPBOOT 作为 CloudFirmware 的 Feature，随 CloudFirmware 一同上线。在装机方面取得突出表现，和ICS进行了一些合作测试。
2022年：HTTPBOOT 除了在 CloudFirmware 机器上使用之外，在小部分机房进行使用。多数情况下作为UEFI 装机失败后的修复工具。
2023年：ICS 对装机网络进行改造，HTTPBOOT 作为主推装机方案在内场机房大批量上线使用，给运维节省了大量的人力。
2024年：一些非服务器形态的板卡项目开始使用 HTTPBOOT 作为他们的装机解决方案。

经过四年的实践运行，HTTPBOOT 积累了大量的经验和好评，成为字节内场主推的装机解决方案。

二、HTTPBOOT 工作原理

1. HTTPBOOT 装机流程

引入 HTTPBOOT 后，新装机方案流程如下：

其中，对于UDP装机不稳定的问题，在搭载 CloudFirmware 的机器上得到了完全解决。对于搭载 UEFI 的机器，仍然需要通过 TFTP/UDP 下载一个 HTTPBOOT 工具到本地，问题依旧存在，但是相比于之前同 PXE 下载一个接近40M的最小镜像，下载一个5.8M的 HTTPBOOT 大大减少了下载失败的概率。

HTTPBOOT在本地运行流程如下：

2. HTTPBOOT 关键步骤

下面将通过一些关键步骤展示 HTTPBOOT 是如何适配和解决问题的：

对自定义 API 适配分为两部分：接入和执行。接入部分的适配如下：DHCP 服务端通过识别 DHCP 请求中的Option 61 判断客户端是否为HTTPBOOT，如果是，则将 API 的 URL 回发给客户端。

图1 接入自定义API

HTTPBOOT 收到 DHCP 返回的 API 后，会附上本机的产品序列号 SN，通过 API 上传到远端服务器，服务器根据 SN 号进行一个 IP 地址的动态的绑定。如此一来，解除了对 MAC 地址强依赖，也无需预先对服务器进行 IP 和机位的分配，实现了服务器的自由上架，节省了大量的人力。

图2 解决对MAC地址依赖，支持自由上架

同时后台接收到上传的机器 SN 号信息后，根据后台记录的机器状态下发不同的指令，若机器为非装机设备，则会返回如下命令，机器从本地磁盘启动。

css 复制代码

#!ipxe
sanboot --no-describe --drive 0x80

而在正常状态下，会返回装机配置文件的 URL ，里面包含需要安装的 OS 文件地址，HTTPBOOT 会下载相应的 OS 文件并启动。

ini 复制代码

#!ipxe
http://[XXXX:XXXX::X:X:X:XX]:88/httpboot.cfg/?IP=fdbddc01002b0f1c0000000000000028

HTTPBOOT 可以支持多种指令来对不同的机型和情况进行灵活处理，至此完成对自定义 API 执行部分的适配。

HTTPBOOT成果和规划

上一小节讲述了 HTTPBOOT 的工作原理及如何解决问题，本节讲述 HTTPBOOT 成果规划。

目前 HTTPBOOT 已经在系统研发阶段闭环了相关使能和测试流程。并在字节内场被广泛应用，完成了十万次数量级的装机交付，其直观收益体现在以下几个方面：

在未来 HTTPBOOT 将在字节内部进行进一步的推广和应用，特别感谢 OPC 、OSFF 、LinuxBoot 、U-ROOT 等开源社区及字节跳动相关部门同学在项目过程中提供的帮助及付出的努力，未来将继续和大家并肩携手，共同成长，收获共赢。最后欢迎对 LinuxBoot 开源项目感兴趣的小伙伴一起交流：github.com/linuxboot/l...

字节跳动新型网络装机方案HTTPBOOT(Linux)，轻松解决运维困扰