Hotdry.
归档
systems

用 Rust 重写硬件定义云控制平面：Oxide Omicron 的机架级资源编排架构

分析 Oxide 如何用 Rust 重写硬件定义云的控制平面 Omicron，实现从单体控制器到分布式状态机的架构演进，以及机架级资源编排与零信任隔离的工程实现。

在硬件定义云（Hardware-Defined Cloud）的浪潮中，Oxide Computer Company 通过全栈整合重新定义了数据中心基础设施。其核心创新之一，是用 Rust 语言重写的控制平面 Omicron，实现了从传统单体控制器到分布式状态机的根本性架构演进。这一技术决策不仅关乎编程语言的选择，更触及了机架级资源编排、零信任隔离和弹性扩展的系统工程本质。

架构演进：从单体控制器到分布式状态机

传统云控制平面往往采用单体架构或微服务拆分，但在硬件定义云的语境下，这两种模式都面临挑战：单体架构难以应对机架级硬件的异构性和规模扩展，而微服务间的网络延迟和协调开销则会损害资源调度的实时性。Oxide 的解决方案是构建一个基于分布式状态机的控制平面 Omicron，其中 98.4% 的代码由 Rust 编写。Rust 的内存安全特性、零成本抽象和并发模型，使其能够同时满足从底层固件（如 Hubris OS）到上层 API 服务的全栈需求。

Omicron 的设计哲学是 “状态即真理”—— 所有硬件资源（计算、存储、网络）和软件服务（实例、卷、网络策略）都被建模为状态机，通过共识算法确保跨节点的一致性。这种架构允许控制平面在服务器故障、网络分区或软件升级时，仍能保持系统的最终一致性，并为运维人员提供确定性的故障恢复路径。

核心组件：Nexus、Sled Agent 与分布式协调

Omicron 控制平面由多个核心组件构成，每个组件承担特定的职责并通过定义良好的接口交互：

  • Nexus：作为控制平面的 “大脑”，Nexus 是一个单体程序（但以分布式集群形式运行），负责暴露所有用户面向的 API（包括操作员和租户 API）。它处理机架级的资源编排、利用率管理、服务器故障检测与恢复等后台任务。Nexus 的设计体现了 “胖控制器” 理念，将核心调度逻辑集中化，以避免分布式决策的复杂性。

  • Sled Agent：运行在每个服务器（包括交换机服务器）上的代理，负责创建、更新和销毁实例、存储资源和网络资源。Sled Agent 还负责硬件清点、向 Nexus 报告故障事件，以及管理服务器上的软件更新。每个 Sled Agent 都维护着本地资源的状态视图，并与 Nexus 保持心跳同步。

  • Bootstrap Agent：在机架和服务器初始化期间运行，负责建立机架级信任、解锁存储、启动 Sled Agent 并配置新设备。Bootstrap Agent 是系统从 “裸金属” 到 “可管理状态” 的关键桥梁，其安全性直接决定了整个机架的信任根。

  • Management Gateway Service (MGS)：作为服务处理器（SP）与控制平面其他部分之间的桥梁，MGS 运行在每个与 Sidecar 交换机相邻的服务器上，将来自 Nexus 的请求转发到管理网络。

  • Dendrite：运行在两个与 Sidecar 交换机相邻的服务器上，是管理数据平面代码（包括用 P4 开发的程序）的驱动程序，针对 Tofino ASIC 进行优化。

这些组件共同构成了一个层次化的控制架构：Nexus 提供全局视图和决策，Sled Agent 执行本地操作，而 Bootstrap Agent 和 MGS 则处理硬件初始化和底层通信。

数据存储：CockroachDB 的强一致性与 ClickHouse 的时序数据处理

控制平面的状态持久化是分布式系统的经典难题。Omicron 采用双存储策略来平衡一致性与性能需求：

  • CockroachDB：作为控制平面的主要数据存储，CockroachDB 提供强一致性、高可用性和横向扩展能力。所有资源元数据（实例规格、网络配置、用户权限等）都存储在 CockroachDB 中，通过 Raft 共识算法确保跨副本的一致性。这种设计使得控制平面能够在节点故障时自动故障转移，而不会丢失已提交的状态变更。

  • ClickHouse：用于存储遥测数据（指标、日志、性能计数器）。Oximeter 服务负责从各个组件收集指标数据，并将其写入 ClickHouse。ClickHouse 的列式存储和向量化查询引擎，非常适合时间序列数据的聚合分析和实时监控。

存储分离的设计体现了关注点分离原则：CockroachDB 处理需要强一致性的控制数据，而 ClickHouse 处理允许最终一致性的观测数据。这种分离也简化了容量规划和性能调优，因为两种工作负载的资源需求模式截然不同。

资源编排机制：机架级弹性与硬件抽象

Oxide 硬件定义云的核心价值之一是提供机架级的弹性资源池。Omicron 控制平面通过以下机制实现这一目标：

  1. 统一资源模型：所有硬件资源（CPU、内存、存储、网络带宽）都被抽象为可量化的配额，并通过项目（Project）和租户（Silo）进行隔离。资源模型支持预留、限制和突发，允许租户根据工作负载特征灵活配置。

  2. 动态功率编排：针对 AI 和高性能计算工作负载，Omicron 与硬件服务处理器协同，实现基于负载的功率动态分配。这种 “功率感知调度” 可以在保证服务等级协议（SLA）的前提下，最大化能效比。

  3. 存储虚拟化：通过 Crucible 存储引擎，Omicron 将物理 NVMe 驱动器聚合为逻辑卷，并提供快照、克隆和异地复制功能。Crucible 的设计强调数据局部性和低延迟，避免传统存储区域网络（SAN）的额外跳数。

  4. 网络可编程性：利用 P4 可编程交换机和 Tofino ASIC，Omicron 能够动态配置数据平面转发规则，实现微秒级的网络策略更新。这种能力对于多租户隔离和流量工程至关重要。

零信任隔离：从 API 到硬件的安全边界

在硬件定义云中，多租户隔离不能仅依赖软件层面的虚拟化，必须延伸到硬件边界。Omicron 实现零信任隔离的层次包括：

  • API 级隔离：每个租户通过独立的 API 端点访问资源，认证和授权在 Nexus 层面统一处理。租户间的资源访问遵循最小权限原则，默认拒绝所有跨租户操作。

  • 网络隔离：通过虚拟路由和转发（VRF）实例，每个租户拥有逻辑独立的网络栈。数据平面编程确保租户流量在硬件交换机层面就被隔离，即使控制平面被攻破，也无法绕过硬件实施的策略。

  • 存储加密：所有租户数据在静止时加密，加密密钥由硬件安全模块（HSM）或可信平台模块（TPM）保护。Crucible 存储引擎支持端到端加密，确保即使物理驱动器被移除，数据也无法被读取。

  • 硬件信任根：从 Bootstrap Agent 开始，每个服务器都通过硬件唯一标识符和证书链建立信任。服务处理器（SP）作为硬件监控点，持续验证固件完整性和运行时行为。

可落地参数与运维清单

对于考虑部署或集成 Oxide 硬件定义云的团队，以下工程参数和运维要点值得关注：

部署配置参数

  • 控制平面副本数：Nexus 和 CockroachDB 建议至少 3 副本以实现高可用，5 副本可容忍双节点同时故障。
  • 资源预留比例：控制平面组件（Nexus、数据库、遥测服务）应预留机架总资源的 10-15%，具体取决于规模和工作负载特征。
  • 网络带宽分配：管理网络（控制平面通信）与数据网络（租户流量）应物理隔离，管理网络建议 25 GbE 起步。

监控指标阈值

  • 控制平面延迟：Nexus API 的 P99 延迟应低于 100 毫秒，超过此阈值可能影响实例启动和资源调配。
  • 共识算法性能：CockroachDB 的 Raft 心跳间隔默认 1 秒，选举超时 2 秒，网络往返时间（RTT）应稳定在 10 毫秒以内。
  • 硬件健康度：服务处理器的传感器数据（温度、电压、风扇转速）应纳入监控，异常波动可能预示硬件故障。

故障恢复策略

  • 渐进式重启：更新控制平面组件时，采用滚动重启策略，每次仅影响一个副本，确保服务连续性。
  • 状态一致性检查：定期运行 oxide db validate 命令验证 CockroachDB 的数据一致性，并备份到外部存储。
  • 故障域隔离：将控制平面副本分布在不同的电源域和网络交换机上，避免单点故障导致全机架不可用。

总结与展望

Oxide 用 Rust 重写控制平面的决策，超越了单纯的技术选型，反映了硬件定义云时代对系统软件的新要求：安全性、性能和确定性必须从最底层开始设计。Omicron 的分布式状态机架构、强一致数据存储和硬件级隔离机制，为机架级资源编排提供了可验证的基础。

然而，这一架构也带来了新的挑战：分布式系统的调试复杂性、Rust 生态的成熟度、以及与传统基础设施的集成成本。未来的演进方向可能包括：更细粒度的资源调度策略（如基于 QoS 的功率分配）、与 Kubernetes 等编排器的深度集成、以及面向边缘计算场景的轻量化变体。

无论硬件定义云的最终形态如何，Oxide Omicron 控制平面的实践已经证明：在追求极致效率与安全性的道路上，从编程语言到系统架构的全栈重新思考，不仅是可能的，而且是必要的。

资料来源

查看归档