Hotdry.
systems

Oxide 硬件定义云:机架级设计与 Rust 控制平面解耦

从 Oxide 获 2 亿美元融资切入,深度解析其硬件定义云的工程实现:基于双 Tofino 2 ASIC 的机架交换机设计、用 Rust 编写的管理平面(Hubris)与控制平面(Omicron)解耦架构,并提供可落地的电源监控、网络延迟等工程参数清单。

2026 年 2 月 10 日,硬件定义云(Bare Metal Cloud)先锋 Oxide Computer Company 宣布完成 2 亿美元 C 轮融资,由 Thomas Tull 的 US Innovative Technology Fund (USIT) 领投,投后估值约 16.5 亿美元。这不仅是一笔普通的融资,更是对一种全新云计算范式的背书:将公有云的弹性、API 驱动体验,通过深度定制的硬件与软件栈,完整复刻到企业本地机房。Oxide 的核心产品 Oxide Cloud Computer 并非传统服务器的简单堆叠,而是一个从主板、交换机、固件到控制平面全部自研的机架级(rack-scale)一体化系统。本文将从其最新的融资动态切入,深入剖析其硬件定义云的工程实现,重点聚焦机架交换机的可编程数据平面设计,以及用 Rust 编写的管理平面与控制平面的解耦架构,并最终提炼出一份可落地的工程参数与监控清单。

Rack-scale 一体化设计:打破堆叠,重构网络 Fabric

传统本地云方案往往是在标准服务器、商用交换机和外置存储阵列之上,通过软件层(如 OpenStack)进行集成。这种堆叠模式必然带来集成复杂性、性能损耗和难以根除的 “抽象泄漏”。Oxide 选择了截然不同的路径:将整个机架作为一个不可分割的交付单元,进行硬件与软件的协同设计(co-design)。其核心网络枢纽是名为 “Sidecar” 的机架交换机,设计细节在其公开的 RFD 58 文档中一览无余。

Sidecar 的设计目标是提供可靠、高性能且无单点故障的网络连接,同时作为控制平面和管理流量的基石。其核心是两个基于 Intel Barefoot Networks Tofino 2 可编程交换 ASIC 的独立设备。每个设备通过 100GBASE-CR4 链路(未来可升级至 200G)连接到机架内的每一个计算节点(Gimlet)。在正常运行时,双设备同时提供服务,提供总计 200Gb/s 的非阻塞聚合带宽。单一设备的计划内维护或故障不会中断服务,仅会降至 100Gb/s 容量。这种冗余拓扑确保了网络 Fabric 的高可用性。

选择 Tofino 2 而非 Broadcom Tomahawk 3 等固定功能 ASIC,体现了 Oxide 的长期工程考量。Tofino 2 可通过 P4 编程语言定义数据平面行为,这意味着 Oxide 可以在软件迭代中动态启用新的网络功能(如自定义负载均衡、数据包过滤策略),甚至为特定客户 workload 进行硬件加速。这种灵活性是构建 “定义” 而非 “固定” 云基础设施的关键。ASIC 提供 64 个 200G 端口,为当前 32 个计算节点连接和 32 个网络上行端口留足了扩展空间,支持未来多机架单元(Cell)的灵活组网。

软件架构革新:Rust 筑基,管理平面与控制平面解耦

硬件创新需要同等深刻的软件变革来驱动。Oxide 的软件栈彻底摒弃了传统数据中心中臃肿、脆弱的第三方组件,代之以一系列用 Rust 编写、职责清晰的自研系统。这清晰地分为管理平面(Management Plane)和控制平面(Control Plane)两层,二者解耦是实现安全、可靠和可维护性的基石。

管理平面负责硬件的最底层启动、监控和管理,其核心是名为 Hubris 的微控制器操作系统。Hubris 取代了传统的基板管理控制器(BMC),运行在专门的服务处理器(SP)上。它负责硬件信任根的建立、电源序列控制、温度监控以及带外管理。与之配套,Oxide 开发了自己的平台使能软件,完全取代了传统的 UEFI BIOS 及其伴随的 “漏洞舰队”。此外,自研的主机 Hypervisor 提供了集成的用户体验,并消除了对第三方虚拟化软件及其昂贵许可的依赖。所有这些组件共同构成了一个极简、可控且安全的管理基础。正如 Oxide 在官方博客中所言:“我们做了自己的微控制器操作系统,并用它取代了传统的 BMC。”

控制平面则是云服务的 “大脑”,名为 Omicron。这是一个用 Rust 编写的复杂分布式系统,构建在自研硬件和管理平面组件的基础之上。Omicron 暴露出一组完整的 API,直接提供现代云服务所期望的三大核心能力:弹性计算实例、虚拟网络和虚拟存储。它与管理平面清晰分离:管理平面确保硬件活着且健康,控制平面则在健康的硬件之上编排用户工作负载。这种解耦使得控制平面可以独立演进、滚动升级,而不会危及底层的硬件稳定性。

可落地工程参数与监控清单

基于 Oxide 公开的设计文档,我们可以提炼出一套用于构建或评估类似硬件定义云系统的关键工程参数和监控要点。

1. 硬件信任根与安全启动配置

  • 信任根芯片:选用支持 TrustZone 的微控制器(如 Oxide 使用的 NXP LPC55S69),在芯片出厂时注入或安全生成唯一密钥。
  • 启动链度量:配置 SP 固件,逐级度量引导加载程序、Hubris 内核镜像、设备树 Blob 的哈希值,并与安全存储中的黄金值比对。
  • 失败策略:度量失败时,应记录安全审计日志并 halt 系统,禁止进入降级模式。

2. 电源与热监控阈值

  • 电压轨容差:12V 主电源轨波动应控制在 ±5% 以内;3.3V 待机电源轨波动控制在 ±3% 以内。
  • 功率采样:通过精密电流传感器(如 INA230)对每块主板、每个交换机 ASIC 进行实时功率采样,频率 ≥10Hz。
  • 温度触发点
    • 交换机 ASIC(Tofino 2)结温警告阈值:90°C;严重阈值:100°C;紧急关机阈值:105°C(需通过外部传感器实现硬件互锁)。
    • QSFP28 光模块温度警告阈值:70°C。
  • 风扇策略:基于加权平均温度(ASIC 温度权重 0.6,入口温度权重 0.4)计算 PWM 占空比,响应延迟应 <2 秒。

3. 网络 Fabric 性能指标

  • 端到端延迟:在同一机架内,计算节点间(通过 Sidecar 交换)的单向延迟目标 <1µs(不含应用栈开销)。
  • 丢包率:在持续满带宽压力测试下,24 小时丢包率应为 0。
  • Fabric 带宽:确保双交换机模式下,任意两个计算节点间可同时达到 2x100Gb/s 的聚合带宽。
  • 管理网络:采用 SGMII 背板连接,避免变压器,使用 AC 耦合电容,确保 100Mb/s 管理流量与高速数据平面物理隔离。

4. 系统健康监控与自动化响应

  • 关键心跳:SP(运行 Hubris)应每 5 秒向控制平面(Omicron)发送一次心跳,超时 15 秒标记节点 “可疑”,30 秒标记 “失效”。
  • 链路健康:持续监控 SerDes 误码率(BER),当 BER > 10^-12 时触发警告,> 10^-10 时触发链路降级或隔离操作。
  • ASIC 内存 ECC:监控 Tofino 2 内部存储器 ECC 纠错计数,日增长超过 100 次需预警。
  • 自动化响应清单
    1. 温度超严重阈值:自动提升风扇至 100%,并通知控制平面开始迁移该交换机上的关键控制流量。
    2. 单交换机故障:网络自动收敛至剩余单路径,控制平面标记相关计算节点为 “网络降级”,避免调度高网络吞吐任务。
    3. SP 心跳丢失:控制平面尝试通过边带网络(管理网络)重置 SP,若失败,则标记整个计算节点为需人工干预。

结论

Oxide 的 2 亿美元融资标志着市场对硬件定义云路线的认可。其工程实践的核心价值不在于任何单一的硬件或软件组件,而在于从硅片、电路板、机架到分布式系统的全栈垂直整合与协同设计。通过自研基于 Tofino 2 的可编程机架交换机和用 Rust 构建的解耦式软件栈,Oxide 实现了对性能、安全、可靠性和成本的前所未有的控制力。这为面临数据主权、性能确定性或成本优化挑战的企业提供了一条可行的 “本地云” 路径。虽然其路径依赖深度自研,挑战巨大,但其公开的设计文档(如 RFD 58)已为行业贡献了一份宝贵的、可参考的工程蓝图。未来,硬件与软件的边界将继续模糊,而像 Oxide 这样敢于重新定义堆栈每一层的公司,或许正在勾勒云计算下一个十年的形态。

资料来源

  1. Oxide Computer Company. "Our $100M Series B." Oxide Blog, July 2025. https://oxide.computer/blog/our-100m-series-b
  2. Oxide Computer Company. "RFD 58: Rack Switch." Oxide RFD, 2020-2021. https://rfd.shared.oxide.computer/rfd/0058
  3. PR Newswire. "Oxide Closes $200M Series C to Scale On-Premises Cloud Computing." February 10, 2026.
查看归档