Hotdry.
systems

用 Rust 重写控制平面:Oxide 硬件定义云的机架级资源编排与零信任隔离

剖析 Oxide 如何通过全栈 Rust 实现硬件定义云,从信任根到网络隔离构建机架级零信任安全模型,为工程团队提供可落地的架构参数与监控清单。

在传统的企业数据中心里,构建私有云往往意味着从多家供应商采购服务器、交换机和存储设备,然后在顶层堆叠管理软件。这种拼凑模式带来了不一致的安全模型、复杂的运维负担和难以预测的性能表现。Oxide Computer Company 选择了一条截然不同的路径:他们交付的不是一堆可以任意组装的硬件,而是一个完整的、机架规模的 “云计算机”。

硬件定义云:从离散服务器到集成机架

Oxide 的核心创新在于其 “硬件定义” 的理念。一个 Oxide 机架是一个预先集成好的计算单元,包含约 2,048 个 CPU 核心、数十 TB 的内存、接近 PB 级的 NVMe 存储以及高达两位数 Tbps 的内部网络带宽。电源、冷却、背板和网络都是协同设计的,例如采用盲插线缆背板和共享的高效电源模块。这种深度集成带来了显著的能效提升 —— 相比传统的服务器逐一部署,Oxide 的机架在功耗和散热效率上更具优势。

更重要的是,硬件的 SKU 是固定且受控的。机架内没有随意添加的网卡、主机总线适配器或其他扩展卡。这种确定性使得 Oxide 能够像超大规模云提供商一样,对整个硬件层面进行推理和安全加固。它消除了传统 OEM 服务器中由不透明的第三方组件带来的未知攻击面。正如 Oxide 在技术演示中所强调的,这种控制力是实现高级安全特性的基础。

全栈 Rust:从固件到控制平面的工程重塑

为了实现对这种高度集成硬件的精细控制,Oxide 抛弃了传统的 BIOS/BMC 固件栈,选择用 Rust 语言从头开始编写自己的固件、操作系统、管理程序和分布式控制平面。

其服务处理器操作系统名为 Hubris,完全用 Rust 开发,运行在定制的服务处理器上,用以取代功能繁杂且常存在安全漏洞的传统基板管理控制器。Rust 的所有权系统和内存安全特性,对于构建长期运行且暴露在复杂网络环境中的底层固件至关重要。Hubris 的设计遵循了微内核架构,将不同功能隔离到独立的、内存安全的任务中,从而将单个组件的故障影响范围降至最低。

这种 Rust 优先的策略贯穿了 Oxide 的整个系统软件栈。控制平面作为机架的 “大脑”,负责资源的调配、虚拟机的生命周期管理、块存储的供给以及虚拟私有云的配置。它通过一套完整的 API、Web 门户和 SDK 对外提供服务,让用户获得类似于公有云 IaaS 的体验,但所有资源都位于本地数据中心,且与底层硬件紧密耦合。用 Rust 重写控制平面,不仅提升了系统的安全性和可靠性,也使得开发者能够更自信地对并发操作和资源管理进行建模。

零信任硬件隔离:从硅片开始的安全模型

Oxide 的安全架构始于一个专用的硬件信任根模块。该模块负责强制执行 “第一条指令完整性”,为整个机架的安全启动和状态证明提供信任锚点。这意味着,从按下电源按钮的那一刻起,每一段加载的代码 —— 从信任根到 Hubris 固件,再到控制平面服务 —— 都可以被密码学方式验证和证明。这套机制旨在防御供应链攻击和固件层面的漏洞利用,为平台状态提供了不可篡改的证据。

在硬件信任根之上,Oxide 构建了多层隔离模型。网络隔离通过 Geneve 封装技术实现,为每个租户创建独立的覆盖网络。关键的封装 / 解封装操作并非由软件负载承担,而是由位于机架边缘的、基于 Tofino 2 可编程 ASIC 的边界服务硬件完成。工程师可以使用 P4 语言对这些 ASIC 进行编程,定义数据包的处理流水线,从而在硬件层面实现高效、确定性的网络策略执行。

这种设计将硬件隔离(信任根、受控固件、固定硬件)与软件隔离(管理程序、虚拟私有云、控制平面管理的多租户)结合起来,实现了 “从硅片开始构建零信任” 的目标。对于运维团队而言,可监控的关键参数包括信任根证明日志的完整性、ASIC 流水线规则的同步状态,以及 Geneve 隧道封装的错误率。

可落地的架构参数与运维清单

对于考虑或正在部署类似架构的工程团队,以下清单提供了可落地的关注点:

  1. 硬件规格与密度:评估单机架的核心数(~2048)、内存密度(数十 TB)和存储容量(近 PB 级 NVMe)是否与工作负载匹配。高密度意味着更少的物理故障域,但也需要更精细的资源调度。
  2. 控制平面 API 与集成:测试 Oxide 提供的 REST API 和 SDK 与现有 CI/CD 流水线、监控系统(如 Prometheus)和配置管理工具的集成能力。关注 API 的幂等性和异步操作的状态查询机制。
  3. 安全监控要点
    • 证明服务:建立对硬件信任根证明报告的定期采集与验证流程,确保启动链未被破坏。
    • 网络隔离验证:定期进行跨租户的网络渗透测试,验证 Geneve 封装和 ASIC 规则是否有效阻止了非授权流量。
    • 固件更新:制定无中断的固件(尤其是 Hubris)滚动更新策略,并严格测试更新后的证明链。
  4. 性能基线:建立内部网络带宽(Tbps 级)、存储 IOPS 和虚拟机冷启动时间的性能基线。利用 Oxide 提供的确定性硬件环境,进行可重复的性能测试和容量规划。

总结与权衡

Oxide 的硬件定义云模型代表了一种向超大规模云提供商内部架构看齐的尝试,但将其产品化为企业可部署的机架形式。全栈 Rust 的实现带来了安全性与可靠性的显著提升,而深度集成的硬件则为实现真正的零信任隔离提供了可能。

然而,这种高度集成也伴随着权衡。最大的考量在于供应商锁定。企业将依赖于 Oxide 的整个技术栈进行演进,迁移到其他平台可能极具挑战。此外,尽管长期拥有成本可能具有竞争力,但前期的一次性资本支出可能高于分阶段采购的传统方式。

最终,Oxide 的方案最适合那些将安全性、可预测性和运维一致性置于最高优先级,且愿意接受新型架构范式的组织。它不仅仅是一堆更快的服务器,而是一个重新构思的、从硅片到软件栈的完整计算系统。


资料来源

  1. Oxide 官方文档指南:Introduction / Guides / Oxide
  2. Oxide 在 Cloud Field Day 20 的演示:Scaling Up The Cloud Computer with Oxide Computer
查看归档