在追求极致性能与安全的新一代云基础设施中，硬件与软件的界限正变得模糊。Oxide Computer 提出的 “机架即计算机” 愿景，并非简单地将服务器堆叠，而是通过深度集成的 Rust 控制平面 Omicron，将计算、存储、网络乃至安全策略统一为可编程的硬件资源。传统云架构中，控制平面往往运行在虚机或容器中，通过软件抽象管理硬件，但 Oxide 反其道而行之：让控制平面直接扎根于硬件信任根，通过 P4 可编程数据面实现微秒级资源调度，并通过启动仲裁机制在硬件层面验证整个机架的完整性。这不仅是对 “零信任” 概念的硬件级实践，更是对云基础设施弹性与安全的一次重新定义。
硬件定义的资源编排：从 “软件定义” 到 “硬件可编程”
机架级弹性的核心挑战在于，如何将数十台服务器、数百个存储设备与高速交换网络视为一个统一的资源池，并能以亚秒级粒度进行动态分配与故障恢复。Oxide 的答案是硬件定义的资源编排：每个服务器单元（sled）支持热插拔，控制平面通过 sled-agent 实时监控硬件状态；电源管理系统可按负载动态调整各 sled 的功耗预算；而数据面则交由定制的 Tofino ASIC 处理，支持 P4 编程，允许运维人员通过代码定义网络转发逻辑、安全策略与流量工程。
这种硬件可编程性带来了两个关键优势：一是性能确定性，P4 流水线在硬件中固定延迟，避免了内核网络栈的抖动；二是策略一致性，安全规则在数据面统一执行，而非分散在多个软件层。然而，硬件定义也引入了新的工程参数需求：sled 发现超时应设置在 30 秒以内，以确保新设备能快速纳入资源池；电源预算需保留 10% 的缓冲，以应对突发负载；P4 流水线深度通常设计为 12 级，在满足功能需求的同时保持低延迟。这些参数并非随意设定，而是基于硬件特性与业务 SLA 的平衡。
零信任隔离：从 “网络边界” 到 “硬件信任链”
零信任架构常被理解为 “永不信任，始终验证”，但在传统实现中，验证多发生在网络层或应用层，硬件往往被视为可信底座。Oxide 将零信任推向极致：每个 sled 和交换机都嵌入硬件信任根（RoT）模块，从第一条指令开始建立可验证的启动链；机架启动时，多个 RoT 模块通过 “信任仲裁” 协议交互，只有当足够数量的组件（例如 3/5）验证通过后，机架秘密才会被解锁，存储系统方能访问。这种机制确保了即使单个硬件被篡改，整个机架也不会泄露敏感数据。
在运行时，隔离通过 VPC（虚拟私有云）实现，但与传统 overlay 网络不同，Oxide 使用 Geneve 封装，并将 VNI（虚拟网络标识符）范围严格限定在 0x1000 至 0xFFFF，避免与系统保留标识冲突。每个项目的资源（计算、存储、网络）都在硬件层面划分，sled-agent 负责执行隔离策略，确保跨租户数据不会在内存或缓存中混杂。可落地的安全参数包括：RoT 证书更新周期建议为 90 天，以平衡安全性与运维负担；仲裁阈值应根据机架规模动态调整，小型机架可采用 2/3，大型机架则需 4/7 等；Geneve VNI 的分配应集中管理，避免冲突与泄露。
Rust 控制平面：内存安全与状态一致性的基石
Omicron 控制平面全部由 Rust 编写，这并非偶然。机架级系统要求控制平面具备极高的可靠性与并发处理能力，而 Rust 的所有权系统与无畏并发特性正好契合。核心组件 Nexus 被设计为单体式服务，统一暴露用户 API 并处理后台编排任务，这种设计简化了分布式事务，但要求 Nexus 本身必须足够健壮。 sled-agent 运行在每个 sled 上，负责本地资源创建、销毁与监控，并通过心跳机制（间隔建议 10 秒）向 Nexus 报告状态。所有持久化状态存储在分布式 CockroachDB 中，默认副本数为 3，确保强一致性与高可用。
Rust 的内存安全保证了控制平面在长时间运行下不会出现内存泄漏或数据竞争，这对于 7x24 小时服务的机架至关重要。工程实践中，需要为每个关键操作设置超时：Nexus API 调用超时建议 5 秒，避免客户端长时间等待；sled-agent 操作（如实例创建）超时可设为 30 秒，兼顾资源准备时间；CockroachDB 的读写超时则应根据网络延迟调整，通常为 2-3 秒。此外，控制平面的日志与指标必须标准化，以便与 Oximeter 遥测系统集成。
监控与运维清单：从硬件健康到安全事件
硬件定义的系统需要更细粒度的监控。运维团队应建立以下清单：
-
硬件健康监控：
- RoT 状态：证书有效期、签名验证成功率。
- 电源轨电压：各 sled 的 12V/5V/3.3V 电压波动应在 ±5% 以内。
- ASIC 温度：Tofino 芯片温度应低于 85°C，否则触发风控降频。
-
软件指标监控：
- Oximeter 遥测目标与指标：确保每个 sled、服务、网络端口都有对应的 Target 与 Metric 定义。
- ClickHouse 写入延迟：P95 应低于 100 毫秒，避免指标堆积。
- Nexus 任务队列深度：长期运行任务数应小于 10，否则需扩容或优化。
-
安全事件监控：
- 启动仲裁失败：立即告警并阻止机架启动，需人工介入检查硬件完整性。
- VPC 策略冲突：当两个项目的网络规则重叠时记录警告，并自动应用优先级更高的规则。
- 证书过期预警：在 RoT 证书到期前 30 天、7 天、1 天发送多级告警。
风险与限制
尽管硬件定义的系统提供了卓越的性能与安全，但也带来两大挑战：一是供应商锁定，Oxide 的深度集成使得客户难以迁移到其他硬件平台，长期可能受制于单一供应商；二是系统复杂性，硬件信任链、P4 编程、机架级仲裁等概念需要运维团队具备跨硬件、网络、安全的多领域技能，学习曲线陡峭。
结论
Oxide 的 Rust 控制平面与硬件定义架构，为云基础设施的未来提供了一种可能的方向：将零信任从软件策略下沉为硬件属性，将资源编排从虚拟抽象提升为物理可编程。这不仅仅是技术的迭代，更是设计哲学的转变 —— 云不再是运行在硬件之上的软件层，而是硬件与软件共同构成的有机整体。对于试图构建类似系统的团队，关键在于平衡创新与实用：从硬件信任根开始设计安全边界，用可编程数据面实现灵活策略，并通过 Rust 控制平面确保整个系统的可靠与一致。最终，机架级云的价值不在于单点性能的提升，而在于提供一种确定性的、安全的、可全面编程的计算基础。
资料来源
- Oxide 控制平面架构指南：https://docs.oxide.computer/guides/architecture/control-plane
- Omicron GitHub 仓库：https://github.com/oxidecomputer/omicron