Panda Research Reports/
OpenStack 集群规划与部署设计
Home

OpenStack 集群规划与部署设计

陈兴源@panda，2025-09
本文档为初始阶段版本（完成度：3/10），可能存在很多不完善甚至错误的地方，仅供参考。
面向 3000 节点算力中心的 OpenStack 集群架构规划、设计与实施方案执行摘要I. 基础架构：为超大规模而设计A. 多-Cell（Nova Cells v2）架构的战略必要性B. 分离式架构 vs. 超融合基础设施（HCI）II. 控制平面：设计、部署与高可用性A. 控制平面部署框架分析B. 推荐框架：使用 Kolla-Ansible 进行容器化部署C. 保障控制平面弹性（高可用性）III. 网络架构：从物理交换矩阵到虚拟化服务A. 物理网络设计：叶脊（Spine-Leaf）交换矩阵B. 逻辑网络分段C. 使用 ML2/OVN 实现虚拟网络IV. 统一存储架构：CephA. Ceph 作为软件定义存储基石B. 专用存储节点设计与数据弹性C. 强制执行“从卷启动”V. 节点角色与推荐硬件配置A. 控制节点（最少 3 台）B. 通用计算节点（初始扩展）C. GPU 计算节点与虚拟化D. Ceph 存储节点（最少 5 台，按需扩展）VI. 容器服务交付框架A. 共生模型：Kubernetes on OpenStackB. 使用 OpenStack Magnum 进行编排（Kubernetes 即服务）C. 备选方案：使用 Zun 直接调配容器VII. 分阶段实施与运营策略A. 分阶段推广计划B. 使用 OpenStack Ironic 实现自动化裸金属部署引用文献

面向 3000 节点算力中心的 OpenStack 集群架构规划、设计与实施方案

执行摘要

本项目旨在为管理约 3000 台 x86-64 物理裸金属服务器的算力中心，设计并规划一个全面、可扩展且高度可靠的 OpenStack 私有云平台。该平台的核心目标是提供企业级的虚拟化计算、网络、存储服务（IaaS），并在此基础上构建强大的容器即服务（CaaS）能力，以满足现代应用开发与部署的需求。本报告将提供一个详尽的技术蓝图，涵盖从底层物理架构到上层服务交付的每一个关键环节。
本方案的核心架构决策基于应对超大规模部署所面临的挑战，并采纳了业界领先的最佳实践。关键建议总结如下：
  • 核心架构模式： 采用 Nova Cells v2 多-Cell 架构，将庞大的计算资源池切分为多个独立的、可水平扩展的故障域，从根本上解决了单体架构在超大规模下的性能瓶颈与稳定性问题。同时，基础设施将遵循分离式（Disaggregated）模型，将控制、计算和存储节点部署在专用的、物理隔离的硬件上，以确保性能的可预测性和运维的简便性。
  • 控制平面部署： 强烈推荐采用 Kolla-Ansible 进行容器化部署。这种方法将所有 OpenStack 服务封装在独立的容器中，极大地简化了部署、升级和维护的复杂性，同时提供了卓越的服务隔离性。控制平面的高可用性将通过 HAProxy 负载均衡、MariaDB Galera 同步复制集群以及 RabbitMQ 镜像队列集群来保障。
  • 网络与存储方案： 物理网络将构建于高性能的叶脊（Spine-Leaf）网络交换矩阵之上。虚拟网络将采用现代化的 ML2/OVN 后端，以其原生的分布式虚拟路由能力和简化的架构，提供卓越的性能和可扩展性。存储层将由一个统一的 Ceph 软件定义存储集群提供支持，为虚拟机块存储（Cinder）、镜像服务（Glance）和对象存储（S3/Swift 兼容）提供一个统一、高可用的后端。平台将强制推行“从卷启动”（Boot from Volume）策略，以确保所有虚拟机数据的持久性和可管理性。
  • 容器服务交付： 平台将遵循**“Kubernetes on OpenStack”**的行业标准模型。通过部署 OpenStack Magnum 项目，为租户提供自动化的“Kubernetes 即服务”（KaaS），使其能够通过简单的 API 调用或 UI 操作，快速部署和管理生产级的 Kubernetes 集群。
本方案的实施将采用分阶段策略，从一个功能完备的小规模试点集群开始，逐步通过自动化的方式分批次扩大规模，最终实现对全部 3000 台节点的纳管。这种方法旨在最大限度地降低风险，确保平台在每个阶段的稳定性和可靠性，最终交付一个能够支撑未来业务增长、具备卓越运营效率和技术前瞻性的世界级算力中心。

I. 基础架构：为超大规模而设计

在 3000 节点这一量级，基础架构的选择对平台的性能、稳定性及运营复杂性具有深远且不可逆转的影响。本章节将确立指导整个部署过程的高层架构原则。

A. 多-Cell（Nova Cells v2）架构的战略必要性

  • 核心建议： 本次部署必须从第一天起就基于 Nova Cells v2 多-Cell 架构进行设计与实施。对于 3000 个计算节点的规模，单-Cell 设计在根本上无法满足性能和稳定性的要求，并且会形成一个大到无法接受的单一故障域。
  • 技术论证：
    • 可扩展性瓶颈： 单-Cell 架构将所有计算节点的状态更新、调度请求和数据库事务集中到一个单一的消息队列（RabbitMQ）集群和一个单一的 Nova 数据库（MariaDB） 1。在 3000 个节点的规模下，海量的 RPC 通信和数据库 I/O 将会压垮这些核心服务，导致 API 延迟飙升、实例创建缓慢，甚至引发系统性的不稳定 2。
    • 故障隔离： Nova Cells v2 将计算基础设施划分为多个逻辑上独立的单元（即“Cell”），每个 Cell 都拥有自己专用的数据库和消息队列 1。这种设计创造了坚固的故障域。某个 Cell 内部的故障（例如数据库崩溃或消息队列异常）将被限制在该 Cell 内部，不会影响其他 Cell 的正常运行，从而极大地提升了整个云平台的弹性 5。
    • 统一的 API 端点： 尽管后端是分布式的，Cells v2 依然为用户提供了单一、统一的 Nova API 端点。这意味着底层的分片架构对最终用户是透明的，用户交互的对象是一个逻辑上统一的云 1。这是相较于多区域（Multi-Region）方案在单一数据中心部署场景下的一个关键优势 6。
    • 现代标准： 所有现代的 OpenStack 部署本质上都是 Cells v2 部署。该架构已不再是可选的附加功能，而是 Nova 的基础组成部分 4。对于任何超过数百个节点的部署，从一开始就规划多个 Cell 是一项不容商榷的最佳实践 1。
  • 实施策略： 计划在初始部署时设立一个全局的“API Cell”（包含顶层 API 服务和用于存放创建失败实例的特殊 cell0 数据库），以及两个计算 Cell，每个 Cell 设计容量为 1500 个节点。这种设计不仅能立即实现故障隔离，还为未来的扩展提供了清晰的路径——只需简单地增加新的 Cell 即可 8。
采用多-Cell 架构不仅仅是一项技术配置，它代表着一种从管理单体系统到管理分布式系统的根本性运营范式转变。在单-Cell 部署中，所有的计算状态和消息都集中处理，运维监控的焦点是一组单一的数据库和消息队列服务。而多-Cell 架构将这些状态分散到各个 Cell，每个 Cell 都有独立的数据库和消息队列集群 5。这就直接要求监控系统必须具备“Cell 感知”能力。监控仪表盘必须能够独立展示每个 Cell 控制平面的健康状况和性能指标。例如，一个“消息队列深度过高”的告警必须明确指出是
哪个 Cell 出现了问题。同样，排查实例启动失败的流程也变得更加复杂：首先，需要确定 Nova 调度器将实例调度到了哪个 Cell；然后，必须在该特定 Cell 的范围内调查日志和服务健康状况。这对运维团队的诊断能力提出了更高的要求。此外，该架构也引入了一些已知的操作限制，例如无法在不同 Cell 之间进行实时迁移（Live Migration） 4。这是一个关键的服务级别约束，必须进行有效管理并向用户清晰传达，这可能会影响用户设计其应用层高可用性的方式。因此，采用多-Cell 的决定直接影响了工具（监控、日志）、运维流程（故障排查工作流）和服务目录（实例迁移限制）等多个方面，是一项需要对运维能力进行相应提升的战略性选择。

B. 分离式架构 vs. 超融合基础设施（HCI）

  • 核心建议： 强烈推荐采用分离式（Disaggregated）基础设施模型。控制、计算和存储功能将被部署在物理上独立的、为特定目的而构建的服务器上。
  • 技术论证：
    • 避免资源争用： 对于任何超过约 30 个节点的集群，让节点同时承担计算、存储和网络功能的超融合模型（HCI）会导致严重的“邻居噪音”问题 10。来自 Ceph 的密集存储 I/O 会消耗大量的 CPU 周期和网络带宽，从而降低在同一硬件上运行的租户虚拟机的性能。分离式模型通过隔离这些工作负载，提供了可预测的性能 11。
    • 简化的扩展与维护： 分离式模型允许对不同类型的资源进行独立扩展。如果需要更多存储容量，只需增加存储节点；如果需要更强的计算能力，只需增加计算节点。这简化了容量规划和采购流程。此外，对存储集群的维护（例如升级 Ceph）可以独立进行，对正在运行的计算工作负载的影响降至最低。
    • 增强的稳定性： 角色的分离简化了故障排查。性能问题可以更容易地被定位到计算层或存储层。而在 HCI 环境中，问题的根源常常被同一硬件上不同服务之间复杂的相互作用所掩盖 10。
选择分离式模型而非 HCI，是在规模化场景下，优先考虑性能可预测性和运营稳定性，而非初始硬件成本效益的一种权衡。HCI 的主要吸引力在于成本节约，因为它可以用更少的物理服务器提供相同的功能集（计算+存储）。然而，随着规模的增长，管理 HCI 节点上资源争用的运营复杂性呈指数级增长 10。在每个节点上精细调整 Ceph 的 CPU 和内存使用，使其与 Nova 虚拟机共存，会成为一项巨大的运维负担。在 3000 个节点的规模下，“邻居噪音”事件导致生产环境受到影响的概率极高。诊断和解决此类事件所花费的成本（包括工程师工时和潜在的服务中断）可能迅速超过最初节省的硬件成本。相比之下，分离式模型虽然前期硬件成本更高（需要专用的存储服务器），但它创建了一个在根本上更易于管理、监控和扩展的系统。性能特征更可预测，故障域更清晰。因此，对于一个任务关键型的大规模部署，分离式模型所带来的长期运营优势和风险降低，使其总拥有成本（TCO）优于 HCI 模式下看似可观的初期节省。

II. 控制平面：设计、部署与高可用性

控制平面是云平台的大脑，其设计直接决定了平台的可靠性、可管理性和演进能力。

A. 控制平面部署框架分析

本节对部署 OpenStack 控制平面服务的三种主要方法进行比较分析，为选择推荐框架提供清晰、数据驱动的依据。
  • 表：控制平面部署方法比较
特性
裸金属部署（手动/自定义脚本）
容器化部署（Kolla-Ansible）
基于 Kubernetes 的部署（如 OpenStack-Helm）
部署过程
极其复杂，手动操作，易出错
通过 Ansible 剧本自动化，可重复
初始 K8s 设置复杂，后续使用 Helm charts
升级过程
“巨大的麻烦”，高风险，需长时间停机
滚动升级，基于容器，过程简化
由 Kubernetes 管理，可能存在复杂性
服务隔离
无隔离，服务共享操作系统和库
极佳，每个服务在独立的容器中
极佳，每个服务在独立的 Pod 中
配置管理
手动编辑文件或自定义自动化
集中化的 globals.yml 和覆盖文件
通过 Helm values 文件管理
可扩展性
难以独立扩展单个服务
易于扩展服务（如 API 工作进程）
通过 Kubernetes 原生扩展
成熟度
传统方法，不推荐
生产环境验证，广泛采用 12
新兴技术，功能强大但生态系统更复杂
推荐度
不推荐
强烈推荐
可行，但运营开销更高

B. 推荐框架：使用 Kolla-Ansible 进行容器化部署

  • 核心建议： OpenStack 控制平面服务必须部署在容器中，并使用 Kolla-Ansible 进行编排。
  • 技术论证：
    • 简化的管理与升级： Kolla-Ansible 将部署和配置每个 OpenStack 服务的复杂性抽象为一组 Ansible 剧本。这使得部署过程可重复、可预测，并且远比手动安装更不容易出错 12。历史上作为 OpenStack 主要痛点的升级过程，通过用新容器替换旧容器的方式得到了极大的简化。
    • 服务隔离： 每个 OpenStack 服务（如 Nova-API、Keystone、Neutron-server）都运行在自己专用的容器中。这可以防止服务之间的依赖冲突，并提高安全性和稳定性。一个出现故障或被攻破的服务被隔离在其容器内，不太可能影响其他服务 12。
    • 可扩展性与灵活性： Kolla-Ansible 提供了一个可扩展且灵活的框架。通过部署更多容器来横向扩展特定服务的 API 工作进程数量变得非常简单。它也非常适合分离式模型，允许在指定的控制节点上精确地放置服务。
    • 社区采纳度与成熟度： Kolla-Ansible 是 OpenStack 社区内一个成熟、支持良好的项目，被广泛认为是生产部署的最佳实践 12。

C. 保障控制平面弹性（高可用性）

  • 核心建议： 为所有核心控制平面服务构建一个健壮的、主-主模式（active-active）的高可用架构是强制性要求。
  • 高可用架构蓝图：
    • 控制节点： 至少部署三台物理控制节点。
    • API 端点负载均衡： 部署一对专用节点运行 HAProxy 和 Keepalived，为所有面向用户的 OpenStack API 端点提供一个虚拟 IP（VIP）。这确保了单个控制节点的故障不会导致 API 访问中断。
    • 数据库集群： MariaDB 数据库将部署为三节点的 Galera 集群。Galera 提供同步复制，确保所有节点都拥有数据的相同副本，从而消除了数据库的单点故障 3。
    • 消息队列集群： RabbitMQ 将部署为带有镜像队列的三节点集群。这确保了消息在所有节点之间进行复制，防止因单个节点故障而导致消息丢失 3。必须配置适当的隔离（fencing）机制（如 pause_minority 模式）以防止“脑裂”（split-brain）情况的发生。
控制平面的高可用性不仅仅是关于冗余，更重要的是在故障事件中确保云平台状态的完整性和一致性。OpenStack 服务本身是无状态的，但数据库和消息队列是状态的载体，它们是整个云平台的“事实之源”。对于数据库而言，简单的主-备（active-passive）故障切换是不够的。在检测到故障并提升备用节点为主节点的这段时间内，云平台的状态可能变得不一致，导致出现孤儿资源或配额计算错误等问题。由 Galera 集群提供的同步复制机制 3 至关重要，因为它保证了一个写操作在被确认为成功之前，必须已经提交到集群中的多数节点。这从根本上消除了在故障切换期间数据丢失或状态不一致的可能性。同样，对于 RabbitMQ，非镜像队列意味着节点故障将导致该节点上所有消息的丢失。这可能意味着丢失实例创建请求或关键的状态更新，使云平台处于不确定状态。而镜像队列 3 则确保了这些瞬时但至关重要的消息能够在节点故障中幸存下来。因此，为状态化服务选择同步、集群化的解决方案，是一个经过深思熟虑的设计决策，其目的在于保护云平台状态的一致性，这是一个比单纯维持服务在线更深层次、更关键的要求。

III. 网络架构：从物理交换矩阵到虚拟化服务

网络是云平台的中央神经系统。一个设计拙劣的网络将严重影响所有其他服务的性能。对于 3000 个节点，一个现代、可扩展、高性能的网络交换矩阵是必不可少的。

A. 物理网络设计：叶脊（Spine-Leaf）交换矩阵

  • 核心建议： 必须采用两层的叶脊（Spine-Leaf）物理网络架构。
  • 架构蓝图：
    • 叶交换机（机架顶部）： 每个服务器机架将连接到一对冗余的叶交换机。服务器将使用 25GbE 或 50GbE 链路连接到这些交换机。
    • 脊交换机： 所有的叶交换机都将连接到每一台脊交换机。这在机架之间创建了一个无阻塞、全网状的交换矩阵。脊交换机到叶交换机的链路应为 100GbE 或更高。
    • 优势： 这种架构为集群中任意两个节点之间提供了可预测的、低延迟的性能，无论它们的物理机架位置如何。它通过简单地增加叶交换机（以支持更多机架）或脊交换机（以增加机架间带宽）即可实现水平扩展。

B. 逻辑网络分段

  • 核心建议： 所有流量必须使用 VLAN 隔离到逻辑上独立的网络中，以确保安全性、性能和可管理性。在此规模下，扁平网络是不可接受的 10。
  • 表：网络分段规划
网络名称
VLAN ID
子网示例
MTU
用途与流量类型
物理网卡
管理网络
10
10.10.10.0/24
1500
OpenStack 内部 API 通信、SSH、监控
绑定 25GbE (1)
存储网络
20
10.10.20.0/24
9000
Ceph 集群复制和客户端流量
绑定 25GbE (2)
租户覆盖网络
30
10.10.30.0/24
9000
Geneve/VXLAN 封装的租户流量（东西向）
绑定 25GbE (1)
外部网络
40
192.0.2.0/24
1500
南北向流量、浮动 IP
绑定 25GbE (1)
部署网络(IPMI)
50
10.10.50.0/24
1500
裸金属部署（Ironic）、IPMI/BMC 访问
专用 1GbE

C. 使用 ML2/OVN 实现虚拟网络

  • 核心建议： OpenStack Neutron 必须配置为使用 ML2 插件和 Open Virtual Network (OVN) 后端。明确不推荐使用传统的基于 ML2/OVS 代理的架构。
  • 技术论证：
    • 现代化的集中式架构： OVN 用一个集中式的控制平面和一个部署在每个计算节点上的 ovn-controller 代理，取代了传统 Neutron 架构中复杂的代理网络（L3 代理、DHCP 代理、元数据代理）。这极大地简化了架构，减少了运营开销，并使系统更易于调试 10。
    • 卓越的性能与可扩展性： OVN 原生支持分布式虚拟路由（DVR）。这意味着东西向（VM 到 VM）的流量直接在源宿主机上进行路由，无需经过一个集中的网络节点，从而显著提升性能并减少网络瓶颈。这对于大规模部署至关重要 10。
    • 增强的稳定性： 传统的基于代理的模型容易出现同步问题和竞争条件，这些问题难以排查 10。OVN 的集中式架构使用一个高度一致的 OVN 数据库，其内在稳定性与弹性更强。
    • 活跃的开发： OVN 是 OpenStack 社区网络开发的焦点，而 ML2/OVS 已被视为弃用，并处于维护模式 10。选择 OVN 可确保项目与 OpenStack 网络的未来发展方向保持一致。
  • 性能调优： 对于大规模 OVN 部署，调整不活动探测（inactivity probe）间隔至关重要，以减少控制器与中央数据库之间不必要的通信，防止在高负载下出现连接超时 13。

IV. 统一存储架构：Ceph

一个可扩展、有弹性且高性能的存储基础是不可或缺的。在此规模下，软件定义存储是唯一可行的方案。

A. Ceph 作为软件定义存储基石

  • 核心建议： 部署 Ceph，为所有 OpenStack 服务提供单一、统一的存储后端。
  • 服务集成：
    • Cinder (块存储): Ceph 的 RADOS 块设备（RBD）将为虚拟机提供持久化块存储卷。
    • Glance (镜像服务): 虚拟机镜像将直接存储在 Ceph 中，从而实现快速的、写时复制（copy-on-write）的实例创建（“从镜像启动”）。
    • Nova (临时存储): 虚拟机的临时磁盘也将存储在 Ceph 中，这使得具有本地存储的实例也能支持实时迁移等功能。
    • 对象存储 (S3/Swift): 将部署 Ceph RADOS 网关（RGW），为租户提供与 S3 和 Swift 兼容的对象存储服务。

B. 专用存储节点设计与数据弹性

  • 核心建议： 使用一个由专用物理节点组成的集群来运行 Ceph OSDs (对象存储守护进程)。
  • 节点设计： 硬件将针对 I/O 进行优化，具有高存储设备与 CPU/RAM 的比例，以及高带宽网络（例如，双 25GbE 或 50GbE 绑定接口） 10。采用 NVMe SSD 作为日志（journals/WAL/DB）盘，并搭配 HDD 或 SSD 作为数据盘，可以在成本和性能之间取得良好平衡 11。
  • 使用 CRUSH 实现数据弹性： Ceph 的 CRUSH map 将配置为“机架感知”。这确保了数据的副本会被放置在位于不同物理机架的 OSD 上。这种配置使得集群能够在整个机架发生故障（例如，由于断电或机架顶部交换机故障）时，依然不会丢失数据或中断服务。

C. 强制执行“从卷启动”

  • 核心建议： 所有租户虚拟机必须配置为从一个由 Ceph 支持的 Cinder 卷启动。将禁用或强烈不鼓励使用临时存储作为根磁盘。
  • 技术论证：
    • 数据持久性： 这是最关键的好处。如果一个实例被删除或其宿主机发生故障，根卷仍然存在，从而防止了数据丢失。这对于任何生产工作负载都是必不可少的 10。
    • 运营灵活性： 从卷启动使得一些关键的运营功能成为可能，如实例快照、备份以及调整根磁盘大小。它也是实现可靠实时迁移的先决条件。
    • 简化的恢复： 在宿主机故障的情况下，一个从卷启动的实例可以很容易地被疏散（evacuate）并在另一台健康的计算节点上重启，这极大地缩短了平均恢复时间（MTTR）。
将“从卷启动”标准化，意味着将虚拟机从临时的、可丢弃的资产转变为持久的、可管理的实体，这从根本上改变了云平台的服务承诺。在 Nova 的默认行为中，根磁盘是宿主机本地磁盘上的一个文件，当虚拟机被终止时，该文件即被删除 10。这种模式适用于为故障而设计的云原生应用，但对传统的、有状态的应用非常不友好，数据丢失是虚拟机删除或宿主机故障的默认结果。通过强制从卷启动，根磁盘不再与虚拟机的生命周期或单个宿主机的健康状况绑定。它变成了一个独立的、持久的 Cinder 卷，被弹性地存储在 Ceph 集群中。这一转变使云平台能够提供传统虚拟化用户所期望的服务，例如可靠的备份和灾难恢复，从而使其适用于更广泛的工作负载。从运营角度看，这也简化了整个集群的管理流程。运维团队不再需要管理数千个独立宿主机磁盘上的数据，而是在 Ceph 存储集群中集中管理数据。这是一个可扩展性与健壮性远超前者的运营模型。因此，这个看似简单的策略改变带来了深远的影响：它将云平台的服务水平从一个基础的计算网格提升为一个能够承载持久化、任务关键型应用的真正企业级 IaaS 平台。

V. 节点角色与推荐硬件配置

本节提供具体、可操作的硬件规格，以指导采购过程。使用标准化的、针对角色优化的硬件是高效运营大规模云平台的关键原则 11。

A. 控制节点（最少 3 台）

  • CPU: 2x 高主频 CPU (例如, Intel Xeon Gold 6xxx 系列)，每颗 16-24 核。为数据库和调度器等服务的单线程性能进行优化。
  • 内存: 512 GB 或更高。充足的内存对于数据库缓存 (MariaDB/Galera) 和 RabbitMQ 至关重要。
  • 存储: 2x 1.92TB 企业级 NVMe SSD (RAID-1)，用于操作系统和数据库存储。
  • 网络: 2x 双端口 25GbE 网卡 (绑定)，为所有网络提供冗余和带宽。

B. 通用计算节点（初始扩展）

  • CPU: 2x 高核心数 CPU (例如, AMD EPYC 或 Intel Xeon Platinum)，每颗 32-64 核。为虚拟机密度进行优化。
  • 内存: 1 TB 至 2 TB。高内存核心比对于支持多种规格的虚拟机至关重要。
  • 存储: 2x 960GB 企业级 SSD (RAID-1)，用于宿主机操作系统。由于采用“从卷启动”策略，无需为虚拟机配置本地存储。
  • 网络: 2x 双端口 25GbE 网卡 (绑定)。
  • CPU 分配比例: 默认配置 8:1 的 CPU 超分比，并能够通过主机聚合（host aggregate）为不同的工作负载配置文件进行调整 14。

C. GPU 计算节点与虚拟化

  • 基础硬件: 与通用计算节点相同，额外增加 2-4 块高端 GPU (例如, NVIDIA A100 或 H100)。
  • 虚拟化策略分析:
    • GPU 直通 (PCI-Passthrough): 此方法将一整块物理 GPU 专用于单个虚拟机。它提供最高的性能，但缺乏灵活性，因为 GPU 无法共享。适用于高性能计算（HPC）或单用户 AI 训练工作负载。
    • 中介设备直通 (vGPU): 此方法使用 NVIDIA vGPU 等技术，将一块物理 GPU 分割为多个虚拟 GPU (vGPUs)，这些 vGPU 可以分配给不同的虚拟机。它允许共享和更高的密度，但需要特定的 NVIDIA 许可和驱动程序。是 VDI、AI 推理或多租户模型开发环境的理想选择。
  • 建议： 平台将通过不同的主机聚合来支持这两种模式。将创建一个 gpu-passthrough 聚合，供需要专用性能的用户使用；同时创建一个 vgpu 聚合，用于共享用例，从而灵活地满足多样化的用户需求。

D. Ceph 存储节点（最少 5 台，按需扩展）

  • CPU: 2x 中等核心数 CPU (例如, Intel Xeon Silver/Gold)，每颗 12-16 核。Ceph OSD 进程可能会占用大量 CPU，尤其是在全闪存配置下 11。
  • 内存: 256 GB 或更高。更多的内存有助于缓存和恢复操作。
  • 存储:
    • 操作系统: 2x 480GB SSD (RAID-1)。
    • 日志/WAL: 2-4x 1.92TB 高耐用性 NVMe SSD。
    • OSD (数据): 12-24x 大容量 HDD (例如, 16TB) 或 QLC/TLC SSD，取决于所需的性能层级。
  • 网络: 2x 双端口 25GbE 或 50GbE 网卡 (绑定)。高网络吞吐量对于 Ceph 的性能和恢复速度至关重要 10。

VI. 容器服务交付框架

提供容器和 Kubernetes 服务是本项目的核心要求之一。架构必须以可扩展、安全且用户友好的方式支持此功能。

A. 共生模型：Kubernetes on OpenStack

  • 核心原则： OpenStack 和 Kubernetes 不是竞争对手，而是功能强大、相辅相成的技术。全球广泛采纳的蓝图是使用 OpenStack 提供坚固的 IaaS 层，Kubernetes 集群则部署在该层之上 15。OpenStack 负责管理基础架构（虚拟机、网络、存储），而 Kubernetes 则负责编排运行在该基础架构之上的容器化应用。
  • 集成点：
    • Kubernetes 工作节点是 OpenStack Nova 虚拟机。
    • Kubernetes 持久卷 (PV) 由 OpenStack Cinder 卷提供支持。
    • Kubernetes Type: LoadBalancer 类型的服务由 OpenStack Octavia 负载均衡器实现。
    • 这种深度集成由 OpenStack Cloud Provider 支持，它允许 Kubernetes 动态地调配和管理 OpenStack 资源。

B. 使用 OpenStack Magnum 进行编排（Kubernetes 即服务）

  • 核心建议： 部署 OpenStack Magnum 项目，为租户提供“Kubernetes 即服务”（KaaS）产品。
  • 功能： Magnum 作为一个编排 API，自动化了 Kubernetes 集群的整个生命周期。用户可以使用 OpenStack API 或 Horizon UI 定义一个集群模板（指定 Kubernetes 版本、节点数量、虚拟机规格等），并在几分钟内调配一个配置齐全、生产就绪的 Kubernetes 集群。
  • 优势：
    • 自动化与简便性： 它为最终用户抽象了部署和配置 Kubernetes 的复杂性。用户无需成为基础架构自动化专家即可获得一个可用的集群。
    • 一致性与治理： Magnum 确保所有部署的集群都遵循一组预定义的、经过测试的模板，从而提高了一致性和安全性。
    • 原生集成： 由 Magnum 调配的集群会自动配置 OpenStack Cloud Provider，确保与存储和负载均衡服务的无缝集成。

C. 备选方案：使用 Zun 直接调配容器

  • 概述： OpenStack Zun 项目提供了一个用于管理单个容器的 API，而无需 Kubernetes 集群的全部开销。它类似于一个托管的 Docker 服务。
  • 用例： Zun 适用于更简单的、小众的用例，例如运行单容器应用或用于不需要完整集群的 CI/CD 任务。
  • 建议： Zun 可以作为补充服务进行部署，但 Magnum 应作为容器编排的主要产品，因为 Kubernetes 已成为事实上的行业标准。
通过 Magnum 提供 Kubernetes 即服务，组织的角色从一个简单的 IaaS 提供商提升为一个平台即服务（PaaS）的赋能者，这具有重大的战略价值。仅仅提供 IaaS（虚拟机、块存储）会将构建和管理容器平台的负担完全推给最终用户，这需要每个租户投入大量的专业知识和精力，为那些只想部署容器化应用的应用团队设置了很高的准入门槛。通过部署 Magnum，云平台提供了一个交钥匙解决方案，它“作为服务”交付了一个经过认证、完全集成的 Kubernetes 环境 15。这极大地加速了租户的应用部署，使他们能够专注于自己的应用而不是基础架构管理——这正是云计算的核心价值主张。从战略上看，这将内部私有云定位为公有云 Kubernetes 服务（如 GKE、EKS、AKS）的一个有竞争力的替代方案。它增加了平台的“粘性”，并推动了现代应用开发团队的采纳，确保了平台对组织的持续 relevance 和价值。这与 CERN 等大型运营商的经验相符，他们已经接受了在 OpenStack 上运行 Kubernetes，以简化部署并加速科研进程 16。

VII. 分阶段实施与运营策略

如此规模的项目不能通过一次性的“大爆炸”式部署来完成。一个有条不紊、分阶段的方法对于降低风险和确保成功至关重要。

A. 分阶段推广计划

  • 第一阶段：试点集群（架构验证）： 部署一个由 3 个控制节点、3 个存储节点和 5-10 个计算节点组成的小规模、功能完备的集群 11。该试点将用于验证所有架构决策，测试 Kolla-Ansible 部署自动化，并建立性能基准。
  • 第二阶段：初步扩展： 试点验证通过后，通过分批次增加节点的方式扩展第一个计算 Cell。建议每批次的规模为 50-100 个节点 11。这使得团队能够在问题影响整个集群之前，识别并解决任何与规模相关的挑战。
  • 第三阶段：全面部署： 在所有规划的 Cell 中继续分批次推广过程，直到全部 3000 个节点都集成到云平台中。
  • 第四阶段：服务上线： 在基础架构大规模稳定运行后，开始接纳初始用户群体，并启用 Magnum 和 GPU 计算等高级服务。

B. 使用 OpenStack Ironic 实现自动化裸金属部署

  • 核心建议： 使用 OpenStack Ironic 服务对全部 3000 台物理服务器进行零接触、自动化的部署。
  • 工作流程：
      1. 节点发现与内省： 当一台新服务器上架并通电后，它将通过 PXE 启动。Ironic 的 inspector 服务将发现该节点并执行硬件内省，收集其 CPU、内存、磁盘和网卡的详细信息 11。
      1. 节点标记： 基于内省的硬件配置文件，节点将被自动标记为其指定的角色（例如，compute、storage）。
      1. 部署： 当特定角色需要新节点时，Ironic 将从可用池中取出一台服务器，部署正确的操作系统镜像，配置网络，并将其交给上层自动化工具（Kolla-Ansible）进行服务部署。
  • 最佳实践：
    • 根磁盘提示： 对于拥有多个磁盘的服务器，将使用全球唯一名称（WWN）作为根磁盘提示，以确保操作系统总是安装在正确的设备上，防止启动失败 11。
    • 自动清理： 将使用 Ironic 的自动清理功能，在两次部署之间安全地擦除磁盘并重置固件设置，确保每个部署周期都有一个一致和干净的状态 13。
在 3000 个节点的规模下，手动配置服务器不仅效率低下，而且是完全不可能的。通过 Ironic 实现自动化是唯一可行的运营模式，也是在物理层实现云般敏捷性和可扩展性的先决条件。试想一下，手动为 3000 台独立的服务器安装和配置操作系统的任务，这将耗费一个工程师团队数月的时间，且过程重复、极易出错。后续任何重新部署服务器的需求（例如，由于硬件故障或角色变更）都将需要同样的手动流程。Ironic 将物理服务器转变为可通过 API 寻址的资源，就像虚拟机一样。整个生命周期——从发现到部署再到退役——都通过软件进行管理。这使得“基础设施即代码”的原则能够应用于裸金属层，物理集群的状态在代码中定义，并由自动化强制执行。这种能力是变革性的。它将部署时间从几天或几周缩短到几分钟，消除了配置漂移和人为错误，并允许运营团队以管理几十台服务器的效率来管理 3000 台服务器的集群。因此，Ironic 不仅仅是一个部署工具，它是一项基础技术，使得整个硬件集群能够作为一个单一的、弹性的资源池来运营——这正是云在物理层的本质定义。

引用文献

  1. Understanding OpenStack Nova Cells: Scaling Compute Across Data Centers › Cloudification - We build Clouds ☁️, 9月 2, 2025にアクセス、 https://cloudification.io/cloud-blog/understanding-openstack-nova-cells-scaling-compute-across-data-centers/
  1. Large Scale SIG/ScaleUp - OpenStack Wiki, 9月 2, 2025にアクセス、 https://wiki.openstack.org/wiki/Large_Scale_SIG/ScaleUp
  1. OpenStack Reference Architecture For 100, 300 and 500 Nodes - Fuel-ccp's documentation!, 9月 2, 2025にアクセス、 https://fuel-ccp.readthedocs.io/en/latest/design/ref_arch_100_nodes.html
  1. Cells (v2) — nova 31.1.0.dev292 documentation, 9月 2, 2025にアクセス、 https://docs.openstack.org/nova/latest/admin/cells.html
  1. Running Red Hat OpenStack Platform 16 with multiple Cells, 9月 2, 2025にアクセス、 https://www.redhat.com/en/blog/running-red-hat-openstack-platform-16-multiple-cells
  1. Stage 4: Scale Out - OpenStack Documentation, 9月 2, 2025にアクセス、 https://docs.openstack.org/large-scale/journey/scale_out.html
  1. Cells Layout (v2) - OpenStack Docs, 9月 2, 2025にアクセス、 https://docs.openstack.org/nova/queens/user/cellsv2-layout.html
  1. OpenStack Docs: Cells, 9月 2, 2025にアクセス、 https://docs.openstack.org/nova/rocky/user/cells.html
  1. Cells Layout (v2) - OpenStack Docs, 9月 2, 2025にアクセス、 https://docs.openstack.org/nova/rocky/user/cellsv2-layout.html
  1. OpenStack Best Practices for Reliable Cloud Deployments, 9月 2, 2025にアクセス、 https://cloudification.io/cloud-blog/openstack-best-practices-for-reliable-cloud-deployments/
  1. Chapter 3. Red Hat OpenStack deployment best practices, 9月 2, 2025にアクセス、 https://docs.redhat.com/en/documentation/red_hat_openstack_platform/16.2/html/recommendations_for_large_deployments/assembly-openstack-deployment-best-practices_recommendations-large-deployments
  1. Best OpenStack Deployment Method for a 3-Node Setup? Seeking Expert Advice - Reddit, 9月 2, 2025にアクセス、 https://www.reddit.com/r/openstack/comments/1ioexpr/best_openstack_deployment_method_for_a_3node/
  1. Chapter 3. Red Hat OpenStack deployment best practices, 9月 2, 2025にアクセス、 https://docs.redhat.com/en/documentation/red_hat_openstack_platform/17.1/html/deploying_red_hat_openstack_platform_at_scale/assembly-openstack-deployment-best-practices_recommendations-large-deployments
  1. Capacity planning and scaling — operations-guide 2013.2.1.dev1227 documentation, 9月 2, 2025にアクセス、 https://docs.openstack.org/operations-guide/ops-capacity-planning-scaling.html
  1. 5 Best Practices for Kubernetes and OpenStack Integration - OpenMetal, 9月 2, 2025にアクセス、 https://openmetal.io/resources/blog/5-best-practices-for-kubernetes-and-openstack-integration/
  1. CERN Case Study - Kubernetes, 9月 2, 2025にアクセス、 https://kubernetes.io/case-studies/cern/