Hotdry.
归档
ai-systems

用Rust重写云控制平面：硬件定义云与零信任隔离的工程实践

深入解析Oxide如何用98.4% Rust代码构建Omicron控制平面，实现硬件定义云的机架级资源编排与零信任隔离，探讨工程实现路径与性能权衡。

在云计算基础设施领域，硬件定义云（Hardware-Defined Cloud）正成为新一代架构范式。Oxide Computer Company 通过其 Omicron 控制平面，展示了如何用 Rust 语言重写传统云控制平面，实现从 PCB 到 API 的垂直集成，同时融入零信任隔离原则。本文将深入解析这一工程实践的技术细节、实现路径与性能权衡。

硬件定义云的架构革命

硬件定义云的核心思想是将云基础设施视为一个完整的、垂直集成的系统，而非传统服务器、网络和存储的松散组合。Oxide 的云计算机机架重达 1.15 吨，每机架集成 2048 个核心、32TB 内存、近 1PB NVMe 存储和 12Tbps 吞吐量。这种机架级集成消除了传统组件如 BIOS 和 PCIe 插槽，实现了预定义的优化硬件配置。

这种架构的关键优势在于：

  1. 动态电源编排：通过精细的电源管理，相比传统服务器实现 55% 的能效提升
  2. 快速部署：从开箱到资源供应仅需数小时，而非数天或数周
  3. 可预测性能：硬件配置的确定性确保了性能的一致性和可预测性

Omicron：98.4% Rust 的控制平面

Oxide 的控制平面 Omicron 是一个开源项目，代码库中 98.4% 为 Rust 语言编写。这一选择基于 Rust 在系统编程中的独特优势：内存安全、无数据竞争的并发模型和零成本抽象。

核心组件架构

Omicron 采用分布式服务架构，主要组件包括：

Nexus：作为控制平面的核心，Nexus 是一个单体程序，提供所有用户面向的 API（包括操作员和客户 API），同时为机架内其他组件提供内部 API，用于报告故障、生成警报等。Nexus 还负责后台控制平面活动，包括利用率管理、服务器故障检测和恢复。

sled-agent：在每个服务器（包括作为交换机的服务器）上运行的代理，负责创建、更新和销毁实例、存储资源和网络资源。它还负责硬件清单、向 Nexus 报告故障和其他事件，以及管理服务器上的软件更新。

bootstrap-agent：在机架和服务器初始化期间在每个服务器上运行的代理，用于建立机架级信任、解锁存储、启动 sled-agent 和配置新设备。

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

dendrite：在每个与 Sidecar 交换机相邻的两个服务器上运行。它是管理数据平面代码（包括用 P4 开发的程序）在 Tofino ASIC 上的驱动程序。

数据存储与遥测

控制平面数据存储系统采用分布式 CockroachDB 数据库，通过共识提供强一致性和高可用性。指标数据存储基于 ClickHouse，从机架组件捕获遥测数据。

oximeter：遥测服务从其他组件收集指标数据并存储到 ClickHouse。Oximeter 提供两个特质（trait）来描述数据：Target 和 Metric。目标可以是 HTTP 服务或硬件组件（如风扇），而指标描述目标在定期间隔测量的特征。每个目标和指标组合在 ClickHouse 数据库中形成一个唯一可识别的时间序列。

Rust 在系统编程中的优势实践

内存安全与并发模型

Rust 的所有权系统在编译时强制执行内存安全规则，消除了 70% 以上的常见漏洞枚举（CVE），这些漏洞通常源于 C/C++ 中的内存安全问题。在控制平面中，这意味着：

  1. 无数据竞争：Rust 的类型系统保证并发访问的安全性，无需锁的开销
  2. 生命周期管理：编译器确保资源在不再需要时被正确释放
  3. 错误处理：Result 和 Option 类型强制显式错误处理

零成本抽象

Rust 的零成本抽象允许高级编程概念（如迭代器、闭包）在编译时被优化掉，运行时性能接近手写 C 代码。在 Omicron 中，这意味着：

  • 异步编程通过 async/await 语法实现，无需回调地狱
  • 泛型允许代码重用，同时保持类型安全
  • 模式匹配简化了复杂的状态处理

机架级资源编排的实现

硬件抽象层设计

Oxide 的硬件抽象层（HAL）采用类似 embedded-hal 的设计理念，为不同硬件组件提供统一的接口。这一层的关键设计原则包括：

  1. 单次使用外围设备：确保硬件资源不被意外共享
  2. 基于特质的接口：允许驱动程序在不同硬件间移植
  3. 编译时约束：通过类型系统强制执行硬件访问规则

资源调度器实现

资源调度器负责在机架内的服务器间分配计算、存储和网络资源。其核心算法包括：

// 简化的资源调度逻辑示意
struct ResourceScheduler {
    available_cores: HashMap<ServerId, u32>,
    available_memory: HashMap<ServerId, u64>,
    network_topology: Graph<ServerId, LinkCapacity>,
}

impl ResourceScheduler {
    fn allocate_instance(&mut self, request: &InstanceRequest) -> Result<Allocation> {
        // 基于约束的调度算法
        // 1. 过滤满足硬件要求的服务器
        // 2. 考虑亲和性和反亲和性规则
        // 3. 优化资源碎片和能效
        // 4. 确保零信任隔离边界
    }
}

调度器考虑多个维度：

  • 硬件约束：CPU 架构、内存容量、存储类型
  • 性能要求：延迟敏感型、吞吐量密集型
  • 能效目标：动态电压频率调整（DVFS）、电源门控
  • 故障域隔离：确保相关故障不会同时影响关键工作负载

零信任隔离的工程实现

多租户隔离架构

零信任原则在 Omicron 中通过多层隔离实现：

网络隔离：使用可编程 P4 栈实现微隔离，每个租户获得独立的虚拟网络，流量在硬件层面隔离。

存储隔离：通过加密和访问控制列表（ACL）确保租户数据隔离，即使在同一物理存储设备上。

计算隔离：利用 Rust 的内存安全特性，在进程内实现隔离，防止侧信道攻击。

安全边界实施

  1. 最小权限原则：每个组件仅获得完成其任务所需的最小权限
  2. 持续验证：所有 API 调用都经过身份验证和授权检查
  3. 审计追踪：所有操作记录到不可变的审计日志中

性能权衡分析

实现零信任隔离不可避免地带来性能开销。Oxide 的工程团队在以下方面进行了权衡：

安全机制 性能开销 缓解策略
内存加密 5-15% 内存访问延迟 使用硬件加速的 AES 指令集
细粒度访问控制 额外的权限检查开销 缓存授权决策，批处理检查
审计日志记录 I/O 和存储开销 异步写入，压缩存储
网络加密 加密 / 解密 CPU 开销 使用硬件 TLS 加速卡

实际部署参数与监控要点

关键配置参数

在生产环境中部署 Oxide 云计算机时，需要关注以下关键参数：

资源预留比例：

  • 控制平面资源：预留 10-15% 的 CPU 和内存供 Omicron 组件使用
  • 故障恢复缓冲：为故障转移预留 20% 的冗余资源
  • 升级缓冲区：为滚动升级保留至少一个服务器的容量

超时与重试策略：

  • API 调用超时：根据操作类型设置 30 秒到 5 分钟不等的超时
  • 数据库事务重试：使用指数退避算法，最大重试次数 5 次
  • 网络连接保持：TCP 保持连接时间设置为 300 秒

监控指标体系

有效的监控是确保系统可靠性的关键。Omicron 通过 oximeter 收集以下关键指标：

资源利用率：

  • CPU 使用率（按核心、按服务器、按机架聚合）
  • 内存使用率（包括缓存和缓冲区）
  • 存储 IOPS 和吞吐量
  • 网络带宽使用率

服务质量指标：

  • API 响应时间（P50、P95、P99）
  • 请求成功率（按 API 端点细分）
  • 资源分配延迟
  • 故障恢复时间

安全监控：

  • 身份验证失败次数
  • 权限检查失败率
  • 异常访问模式检测
  • 审计日志完整性检查

告警阈值建议

基于生产经验，建议设置以下告警阈值：

  1. 关键告警（立即响应）：

    • API 成功率低于 99.9%
    • 任何控制平面组件不可用超过 1 分钟
    • 存储空间使用率超过 90%

  2. 警告告警（24 小时内处理）：

    • CPU 使用率持续超过 80% 超过 1 小时
    • 内存使用率超过 85%
    • 网络丢包率超过 0.1%

工程挑战与未来展望

当前挑战

  1. Rust 生态系统成熟度：虽然 Rust 在系统编程中表现出色，但某些领域的库和工具仍在发展中
  2. 硬件兼容性：垂直集成架构需要与特定硬件深度集成，限制了硬件选择的灵活性
  3. 运维复杂性：硬件定义云需要新的运维模式和技能集

未来发展方向

  1. AI 驱动的资源调度：利用机器学习预测工作负载模式，优化资源分配
  2. 跨机架编排：扩展 Omicron 以管理多个机架，实现真正的数据中心级云
  3. 量子安全加密：为后量子计算时代准备加密算法
  4. 边缘计算扩展：将硬件定义云架构适配到边缘环境

结论

Oxide 通过 Omicron 控制平面展示了 Rust 在云基础设施中的强大能力。98.4% 的 Rust 代码库不仅提供了内存安全和并发安全，还通过零成本抽象保持了高性能。硬件定义云架构通过垂直集成实现了显著的能效和性能优势，而零信任隔离原则则确保了多租户环境的安全性。

这一工程实践为云基础设施的未来发展提供了重要参考：系统编程语言的选择直接影响系统的可靠性、安全性和性能；硬件与软件的深度协同设计能够释放更大的潜力；安全不应是事后考虑，而应是架构的核心原则。

随着 Rust 生态系统的成熟和硬件定义云概念的普及，我们有理由相信，这种架构模式将在未来的云基础设施中扮演越来越重要的角色。

资料来源：

  1. Oxide 官方文档：https://docs.oxide.computer/guides/architecture/control-plane
  2. Omicron GitHub 仓库：https://github.com/oxidecomputer/omicron
  3. Edera 关于 Rust 重写 Xen 控制平面的经验分享
  4. Rust 嵌入式硬件抽象层设计模式
查看归档