在公有云成本不断攀升、数据主权要求日益严格的背景下，将云原生架构与 on-premises 部署相结合的需求变得愈发迫切。Oxide Computer Company 提出的 “硬件定义云” 理念，正是对这一挑战的回应：将整个机架视为一个原子化的云计算机单元，通过深度集成的硬件与软件栈，在客户自有数据中心内提供可与公有云媲美的弹性、效率与安全隔离能力。本文将从其 Rust 编写的控制平面架构入手，深入剖析 Oxide 如何实现机架级资源编排，并构建基于硬件信任根与信任仲裁的零信任隔离机制。
硬件定义云的核心：机架作为原子单元
Oxide 的设计哲学始于一个根本性转变：不再将服务器、交换机、存储设备视为独立组件，而是将整个机架作为一个不可分割的计算单元进行设计、制造与管理。这一决策带来了多项工程优势：
首先，物理连接上采用盲插背板（blind-mate backplane）彻底消除了机架内数公里长的电缆。所有扩展通过背板完成，不仅减少了故障点，更将部署时间从数天缩短至数小时。电源系统同样进行了重构，采用机架级直流供电，由少量大型电源集中供电，相比传统分布式电源方案提升能效达 55%，同时将噪音控制在 15kW 功率下仍可 “耳语般安静” 的水平。
其次，软件栈从最底层开始重新设计。Oxide 移除了传统的 BIOS/UEFI 固件层，代之以自定义的固件初始化流程。这一举措不仅简化了启动链，更从根本上消除了遗留固件中常见的安全漏洞与复杂性。正如 Oxide 工程师在逆向工程 LPC55S69 微控制器时发现的，即便是硬件信任根芯片中也存在未文档化的 ROM 修补器（ROM patcher）区块，而自定义固件允许他们完全掌控从第一指令开始的安全状态。
Rust 控制平面：Omicron 的架构与编排机制
硬件创新需要同等先进的软件来驱动。Oxide 的控制平面项目 Omicron 几乎完全采用 Rust 编写，其设计目标是在机架尺度上协调计算、存储与网络资源，同时暴露云风格的 API。Omicron 并非简单的集群管理软件，而是一个真正的分布式系统，其核心组件包括：
- Nexus：作为中央协调器，它承载所有用户面 API（包括操作员与租户）以及机架内部组件报告故障、生成警报的内部 API。Nexus 还负责后台控制平面活动，如利用率管理、服务器故障检测与恢复等。
- sled-agent：运行在每个服务器（包括作为交换机的服务器）上的代理，负责创建、更新和销毁实例、存储资源与网络资源。它还负责硬件盘点、向 Nexus 报告故障与其他事件，以及管理服务器上的软件更新。
- bootstrap-agent：在机架与服务器初始化期间运行，用于建立机架级信任、解锁存储、启动 sled-agent 并配置新设备。
- 管理网关服务（MGS）：作为服务处理器（SP）与控制平面其余部分之间的桥梁，运行在靠近交换机的 sled 上，将请求从 Nexus 转发到管理网络。
资源编排的核心在于状态管理与工作流引擎。Omicron 使用 CockroachDB 作为分布式数据库，通过共识协议提供强一致性与高可用性，确保机架库存、sled 容量与实例放置等状态的准确追踪。操作被建模为 Saga—— 多步骤工作流，任何步骤失败都能干净地回滚。这种模式使得系统能够安全地编排复杂的机架级变更，如实例迁移或机架扩展。
在并发模型上，Oxide 团队经过深入评估后选择了基于 async/await 的事件驱动系统。在 RFD 79 中，他们详细比较了异步与同步线程池方案的权衡：异步系统在内存使用（任务栈远小于线程栈）、线程池 sizing（只需匹配逻辑 CPU 数）以及病理情况下的行为（更晚达到资源耗尽点）上具有优势，但代价是更陡峭的学习曲线和更复杂的调试体验。团队最终决定坚持异步路线，前提是投入足够资源构建可调试性基础设施。
零信任隔离：从硬件信任根到信任仲裁
安全是 Oxide 设计中的首要原则，其零信任架构贯穿从硬件启动到多租户隔离的每一个环节。
硬件信任根（RoT）与安全启动链 Oxide 在每个服务器 sled、交换机和电源架控制器上嵌入了一个专用的 RoT 微控制器（如 NXP LPC55S69）。从通电开始，RoT 使用安全启动验证固件完整性，防止被篡改的代码执行。RoT 持有不可提取的秘密，用于证明正版 Oxide 固件，拒绝任何外来或已被利用的代码。这种证明并非孤立进行，而是形成一条证明链：RoT 证明服务处理器，服务处理器证明主机 CPU，最终实现机架级的证明验证。
信任仲裁（Trust Quorum）与机架秘密 这是 Oxide 零信任架构中最精妙的机制之一。在机架初始化期间，Rack Setup Service (RSS) 指示 sled-agent 生成一个 “机架秘密”，并将其加密分片后分发到不同 sled 的引导网络上。这个秘密用于存储加密方案。此后，每当一个 sled 启动时，它必须从其他 sled 恢复足够数量的秘密分片（达到 “信任仲裁” 阈值）才能重建机架秘密并解锁其本地存储。解锁过程完成后，机架秘密会从内存中安全擦除。
这种设计意味着，单个 sled 甚至少数 sled 被攻陷不会危及整个机架的安全。攻击者需要同时控制超过阈值的 sled 数量（具体阈值可配置）才能重构秘密，这极大地提高了横向移动的难度。同时，数据静态加密与机架秘密绑定，即使物理磁盘被移出机架，在没有足够分片的情况下也无法解密。
多租户隔离与网络分段 在软件层面，Oxide 通过项目、虚拟私有云（VPC）、防火墙和配额实现逻辑隔离。每个 VPC 使用 Geneve 封装提供独立的网络命名空间，防火墙规则在硬件交换机上通过 P4 编程的 Tofino ASIC 强制执行，确保租户间流量完全隔离。资源配额系统提供细粒度的利用率控制，防止任何单一租户耗尽机架资源。
工程权衡与可落地参数
构建如此深度集成的系统必然伴随着一系列工程权衡。理解这些权衡对于评估 Oxide 方案的适用性至关重要。
性能与安全的平衡 硬件信任根和加密证明引入了启动延迟。Oxide 的测量显示，从通电到所有 sled 完成证明并建立信任仲裁通常需要 2-3 分钟。这对于需要极速扩展的场景可能是一个考虑因素，但对于大多数企业工作负载而言，这种一次性成本换来的安全保证是可接受的。
运维复杂性与可见性 自定义硬件和软件栈意味着运维工具链需要重新学习。Oxide 提供了统一的控制台、CLI 和 API，并集成了 OpenTelemetry 用于遥测收集。Oximeter 系统定义了两个特质（Trait）来描述数据：Target（如 HTTP 服务或风扇硬件组件）和 Metric（如服务生成的 500 级响应数量或风扇当前速度）。每个 Target 和 Metric 组合在 ClickHouse 数据库中形成一个唯一可识别的时间序列，为监控与调试提供基础。
可扩展性与锁定风险 机架作为原子单元既是优势也是限制。它提供了极佳的密度与能效，但最小部署单元就是一个机架（半机架配置为 16 个 sled）。对于需要更细粒度扩展或混合不同世代硬件的场景，这可能不够灵活。同时，深度定制的硬件和固件带来了供应商锁定风险，尽管 Oxide 承诺提供透明的供应链和可审计的固件。
可落地的配置参数 对于计划部署 Oxide 的团队，以下关键参数值得关注：
- 信任仲裁阈值：默认配置需要多数 sled 参与秘密恢复，可根据安全要求调整。
- 资源配额默认值：CPU、内存、存储和网络带宽的默认配额应基于典型工作负载进行校准。
- 网络上行链路配置：在初始机架设置中，需要准确配置上行链路端口速度（如 40G、100G）、FEC（前向纠错）模式以及 BGP 对等参数。
- 内部服务 IP 池范围：必须预留至少 16 个 IP 地址用于控制平面 DNS 和 API 服务。
结论：硬件定义云的未来路径
Oxide 的硬件定义云架构代表了一种回归工程本质的尝试：通过垂直整合硬件与软件，在 on-premises 环境中实现公有云级别的弹性、效率与安全隔离。其 Rust 控制平面展示了现代系统语言在构建可靠、并发密集型分布式系统方面的优势，而基于硬件信任根和信任仲裁的零信任机制则为敏感工作负载提供了前所未有的安全基础。
然而，这种深度集成路径并非没有代价。它要求组织接受一种新的运维范式，并投资于相应的技能建设。对于那些受成本、合规性或数据主权驱动，迫切需要将云原生能力引入自有数据中心的组织而言，Oxide 提供了一条值得认真评估的路径。随着更多部署案例的出现，我们也将更清楚地看到这种架构在规模化运维、异构环境集成以及长期技术演进方面的实际表现。
资料来源
- Oxide Computer Company 官方文档与架构指南
- RFD 79: Rust approaches to concurrency in the control plane
- Oxide 博客：Exploiting Undocumented Hardware Blocks in the LPC55S69
- 初始机架设置指南与联邦解决方案页面