做私有云交付这些年，我见过太多团队被 OpenStack 拖垮。倒不是 OpenStack 不好，而是它被用错了地方——三台机器、两个运维、一个业务系统，硬要上一整套 Nova + Neutron + Cinder + Ceph，最后每天的工作就是修 RabbitMQ、追赶数据库同步、查哪块 OSD 又黄了。业务没跑起来，人先跑了两个。
这篇文章不讲虚的，只讲四件事：节点该怎么拆、网络该怎么分、Ceph 该怎么配、以及到底多少节点以下别碰 OpenStack。硬件配比我给具体档位，网络规划我给地址段示例，容量换算我给算例。所有规模与性能指标我都写成区间，并注明以实际环境压测为准，因为不同机房、不同盘型、不同内核版本，跑出来的数差别可以翻倍。
核心结论一：物理节点少于 8 台、虚拟机少于 50 台，别上 OpenStack。一套虚拟化集群加个备份软件，能解决你九成的问题，运维成本只有十分之一。
核心结论二：控制节点必须三副本，且必须独立。把 Keystone、MariaDB Galera、RabbitMQ 塞进一台机器跑生产，等于把整个云的命门放在单点上。
核心结论三：网络至少分四个平面——管理网、业务（隧道）网、存储网、带外网。四个平面挤一个网段，是私有云交付里最常见、也最难回头的一个坑。
核心结论四：Ceph 可用容量 ≈ 裸容量 ÷ 副本数 × 损耗系数（0.7 左右）。买盘前先按这个公式倒推，别等上线了才发现三副本吃掉三分之二。
核心结论五：OpenStack 的真实门槛不在硬件，在人。至少一个能读懂 Neutron 流表、能手动恢复 Galera 集群的专职工程师，否则出故障只能等厂商。
OpenStack 的价值集中在"统一管理平面"这几个字上。说白了，它不是一套虚拟化软件，而是一套把计算、网络、存储三类资源抽象出来、再通过 API 和租户体系分发出去的调度框架。如果你的诉求只是"开几台虚拟机"，那它肯定不划算；但如果你的诉求是下面这几条，它的价值就出来了。
第一类是多租户。集团型企业里，十几个子公司、几十个项目组都要用资源，你得给每家划配额、划网络、划权限，还得能按用量出账单。Keystone 的域与项目体系、Nova 的配额、Neutron 的租户网络隔离，天然就是为这件事设计的。用 vSphere 也能做，但二次开发和自动化对接的成本要高一截。
第二类是资源池化与自助服务。研发要机器，走工单等一天，还是自己在门户上点两分钟就拿一台？OpenStack 加一层自研门户或者现成的管理面板，能把交付周期从"天"压到"分钟"。这对迭代频繁的团队是实打实的效率提升。
第三类是强内网合规。政务、金融、医疗、能源这些行业，数据出不了内网，又要求资源弹性，公有云直接排除。自建私有云是唯一路径，而 OpenStack 是这条路径上生态最完整、国产化替代最成熟的开源选择。
第四类是异构纳管。机房里既有 x86，又有 ARM，还可能掺着几台国产化服务器，外加存量的一套 VMware。OpenStack 可以通过不同的驱动把这些资源统一纳进一个资源池，上层业务只看 API，不看底层是什么。这种"混池"能力是它相对商业虚拟化软件的一个明显优势。
反过来讲，下面这些情况我一般直接劝退。
规模太小是最典型的。三五台物理机、二十来台虚拟机，运维还兼着网络和存储，上一套 OpenStack 纯属自找麻烦。这类场景用一套成熟的虚拟化集群（KVM + libvirt 自己管，或者商业虚拟化软件），配个定时备份和监控告警，一年到头不用管，出了问题重启就行。OpenStack 的组件数量是这套东西的十倍以上，故障面也跟着放大十倍。
纯 GPU 训练集群也是典型误用。训练任务要的是裸机性能和 RDMA 低延迟网络，中间夹一层虚拟化和 Neutron 只会添乱。这种场景直接上裸金属加作业调度系统（Slurm、Kubernetes 之类），别走 OpenStack 这条路——你要的是算力，不是虚拟机。
还有一个容易踩的：没有专职运维团队，指望外包交付完就"自动化运行"。私有云不是装完就完事的软件，版本升级、组件调优、故障恢复、容量规划，每一项都需要持续投入。外包团队撤了之后没人接手，集群会在半年内逐渐劣化，最后变成谁都不敢动的"祖传系统"。
另外，如果你的业务只需要对象存储或者只需要 Kubernetes，那也没必要上 OpenStack。单独的 Ceph 集群、单独的 K8s 集群，都比全栈 OpenStack 轻量得多。别为了"统一"而统一。
硬件的钱是明面上的，人的钱是隐性的，但后者往往更大。我给一个参考区间，具体以团队实际能力为准：一套 20 到 50 台物理节点的生产 OpenStack 集群，至少需要 1 到 2 名专职云平台工程师，其中至少 1 人要具备独立排查 Neutron 网络问题和恢复 Galera 集群的能力。规模到 100 节点以上，通常需要 2 到 4 人，并且要分成计算、网络、存储三个方向各有人懂。
再往上算，还要考虑 7×24 值班。生产集群半夜出问题没人接，第二天业务就炸了。三个人的团队做轮值，意味着每人每周都要有一两天处于待命状态，这是实打实的人力成本，做预算时必须写进去。很多团队算 TCO 时只算服务器和交换机，算漏了这部分，等到第二年续保才发现账对不上。
一个折中思路是"托管式私有云"：硬件和底层云平台交给有交付能力的服务商托管，自己的团队只管上层业务和资源申请。这样人力门槛从"三个资深工程师"降到"一个懂业务的对接人"，代价是每年多付一笔服务费。对绝大多数中型政企来说，这条路的总成本其实更低。
控制节点跑的是 API 与调度层。Keystone 管认证与授权，所有组件调用前都要先找它拿 token；Glance 管镜像；Nova 的 API 与 Scheduler 负责接单和挑宿主机；Neutron Server 负责网络 API；Cinder API 负责卷；Placement 负责资源追踪与调度打分；Horizon 是那套 Web 面板。支撑这些服务的是两个关键底座：MariaDB Galera（或 MySQL 组复制）存元数据，RabbitMQ 做组件间异步消息。
控制节点对 CPU 和内存的要求其实不高，但对稳定性和磁盘 IO 有要求。数据库和消息队列都是 IO 敏感型，系统盘建议 SSD 起步并且做 RAID 1。生产环境控制节点必须三台起，Galera 三副本才能容忍单节点故障并保持法定票数，两台会出现脑裂风险。数据库和消息队列如果放在同一组机器上，注意给它们各自独立的目录和足够的内存配额，别让 RabbitMQ 把内存吃干导致数据库被 OOM 掉。
计算节点上跑的是 Nova Compute 服务，底下是 libvirt + QEMU/KVM。CPU 支持硬件虚拟化（Intel VT-x / AMD-V）并开启，内存建议 ECC，超线程根据实际负载决定是否开启——虚拟化场景下超线程通常能带来正的收益，但如果跑的是延迟敏感型业务，可以考虑关闭以换取确定性。
内存配比是计算节点最容易配错的地方。虚拟机的内存是硬占用，超卖要非常谨慎，一般生产环境不建议做内存超卖，或者只做很轻微的比值。磁盘方面，如果用本地盘存虚拟机，建议 SSD 或 NVMe；如果走 Ceph 统一存储，计算节点本地只需要系统盘，虚拟机的块设备由 Ceph 提供，这是目前中大型集群的主流做法。
网卡是计算节点的关键。虚拟机流量、隧道封装流量、存储流量都要走网卡，单口万兆在规模稍大的集群里很快会成为瓶颈。生产环境建议至少双口万兆或双口 25G，并且做绑定。要不要在计算节点上跑 Ceph OSD，这个问题我放到存储那一节专门讲。
网络节点承担的是虚拟网络的三层转发、DHCP、元数据服务，以及虚拟路由器。用 OVS 或 OVN 做底层转发，L3 agent 负责路由命名空间，DHCP agent 给租户网络发地址，metadata agent 让虚拟机能拿到自己的元数据（注入密钥、执行脚本全靠它）。
小规模集群里，网络节点可以和控制节点合并部署，能省两台机器。但规模上来之后一定要独立出来，因为南北向流量的转发是 CPU 密集型的，跟控制面的 API 抢资源会互相拖累。网络节点同样要做高可用，通常用 VRRP 或者分布式路由（DVR）的方式，DVR 把三层转发下放到计算节点，能显著降低网络节点的压力，但配置复杂度也更高，小团队慎用。
存储节点主要跑 Ceph。MON 负责维护集群地图，数量必须是奇数（3 或 5），通常和控制节点混部或者单独用三台小规格机器；MGR 提供监控与管理接口；OSD 是真正存数据的进程，一块盘一个 OSD；如果用 CephFS 还要加 MDS；如果用对象存储还要加 RGW。
Cinder 本身不存数据，它是块存储的控制面，后端接 Ceph RBD 是最常见的组合。Glance 的镜像、Nova 的虚拟机系统盘、Cinder 的云硬盘，三者都可以落在同一个 Ceph 池里（分成不同的 pool），这也是 OpenStack + Ceph 成为事实标准搭配的原因——一份存储同时服务三个组件，利用率最高。
存储节点的硬件几乎是整朵云里最贵的部分，因为盘多。CPU 要求中等，内存有明确公式（见后文），网卡要求最高，存储网建议 25G 起步，规模大的直接上 100G。这一层的钱不能省，省了后面扩容时会非常痛苦。
三节点方案是每家做 PoC 的起点：三台机器，每台都跑控制面 + 计算 + Ceph OSD，做成全对称结构。它的好处是便宜，三台就能把整套流程走通——建镜像、开虚拟机、挂云硬盘、配租户网络，全都能演示。
但三节点绝不能上生产，原因有三个。第一是控制面没有真正的高可用，三台里挂一台，Galera 还剩两票能撑住，但同时你失去了三分之一的算力和三分之一的存储，性能直接掉一大截；挂两台基本就废了。第二是资源竞争，控制面的数据库、计算面的虚拟机、存储面的 OSD 在同一台机器上抢 CPU、抢内存、抢 IO，任何一个组件跑满了都会拖累另外两个。第三是无法滚动升级，生产集群升级要一台一台来，三节点结构下你摘掉任意一台，剩下的压力都会翻倍。
所以三节点的定位就是验证和培训：验证你的部署脚本、验证业务流程、让团队熟悉组件。真要上线，至少从五节点起步。
五节点的标准拆法是 3 控制 + 2 计算，Ceph 的 MON 放在三台控制节点上，OSD 盘放在两台计算节点上（也就是计算存储混部），共三台 MON 满足奇数要求。这是能接受的最小生产形态，容得下控制面单点故障，计算侧挂一台还剩一台。
另一种拆法是 3 控制 + 2 存储 + 计算按需扩展，把 Ceph OSD 从计算节点剥离出来独立成池。这种拆法更干净，混部带来的一系列问题（资源争抢、故障域耦合、扩容不同步）都能规避，代价是多两台机器。如果预算允许，我更推荐这种。
五节点集群的容量天花板比较明显。两台计算节点，每台按 256G 内存、扣除系统预留后能给虚拟机的可能只有 200G 出头，按每台虚拟机 8G 算，也就五十来台。这个规模对中小型政企来说其实够用了，很多单位的私有云就是这么大。
真正的生产集群结构很固定：控制节点三台（控制面组件 + MON + MGR），网络节点两台（做高可用），存储节点按容量需求横向扩（奇数台起步，3 台起），计算节点按算力需求横向扩，想加就加。这个结构的好处是每一层的扩容互不影响——算力不够加计算节点，容量不够加存储节点，控制面压力大了才动控制节点。
控制节点三台之后一般不再增加，因为 Galera 和 RabbitMQ 的同步开销会随节点数上升。如果 API 压力真的很大，正确的做法是在前面加负载均衡，而不是把控制节点扩到五台七台。存储节点扩到一定规模后要引入机架级故障域划分，副本要跨机架甚至跨机房放置，否则一个机柜掉电就可能让三副本里的两份同时失效。
我把话说死一点：物理节点 8 台以下、虚拟机需求 50 台以下、且没有专职云平台工程师的团队，不要碰 OpenStack。这条线不是拍脑袋定的，是按运维复杂度倒推的——OpenStack 的组件数量决定了它的日常维护量有一个基础门槛，这个门槛跟集群规模关系不大，你三台机器要维护的组件数量跟十台机器几乎一样。规模越小，摊到每台机器上的运维成本就越高，越不划算。
10 台到 30 台这个区间是 OpenStack 的舒适区，此时自动化运维的收益开始显现，资源池化的价值也体现出来了。30 台以上，OpenStack 的优势会非常明显，尤其是多租户和自助服务这块，商业虚拟化软件很难做到同等灵活度。
还有一条更重要的判断标准：你的业务是否需要"频繁创建销毁资源"。如果一年就开十台虚拟机，然后不动了，那用什么都一样；如果研发每周要几十台测试机，那 OpenStack 的自助门户和配额体系会立刻产生价值。
网络规划是私有云交付里最容易做错、也最难返工的一环。很多团队一开始图省事，所有网口全塞一个网段，跑半年发现管理流量和存储流量互相踩，虚拟机一做迁移数据库就抖，这时候再想拆网，得停机改配置改到怀疑人生。
正确的做法是从第一天就分四个平面。
管理网（Management / API 网）：承载组件间的 API 调用、数据库连接、消息队列通信，以及运维 SSH 与监控采集。这个网段的稳定性直接决定控制面的健康度，流量不大但对丢包和延迟非常敏感——RabbitMQ 一丢包就会引发组件失联和重试风暴。
业务网 / 隧道网（Tenant / Tunnel 网）：承载虚拟机之间的东西向流量。如果用 VXLAN 或 GRE 封装，这一层跑的是封装后的隧道流量，也是南北向出口流量的汇聚点。这个平面带宽压力最大，虚拟机之间的数据拷贝、备份、迁移全走这里。
存储网（Storage 网）：专门给 Ceph 用，承载 OSD 之间的数据复制、恢复、再平衡流量。Ceph 在数据恢复和扩容再平衡时会产生海量突发流量，如果不隔离，能瞬间把业务网打满。这个平面必须独立，而且带宽要给足。
带外管理网（IPMI / BMC 网）：独立于所有业务网络，专门接服务器的 BMC 口。它的作用是当机器系统挂死、SSH 进不去的时候，你还能远程看到 console、重启、重装。这一层平时没人注意，出事的时候是救命的。
VLAN 和 VXLAN 的选择，本质上是"交换机能不能扛住"和"租户数量会不会超"两个问题的权衡。
VLAN 模式（Neutron 里叫 provider network 或 VLAN tenant network）的好处是简单、性能好、没有封装开销，虚拟机流量直接打 VLAN 标签出物理网，交换机做三层。缺点很致命：VLAN ID 只有 4096 个，实际可用更少；而且每新增一个网络都要在交换机上配置 trunk，网络变更要靠改交换机，自动化程度低。租户数量在几十个以内、网络变更不频繁的场景，VLAN 完全够用，而且是更省心的选择。
VXLAN 模式解决了这两个问题：24 位的 VNI 提供上千万个隔离网络，网络创建完全在软件层完成，不用动交换机。代价是封装开销——每个包多 50 字节左右的头部，而且封装解封装要吃 CPU（好在现在网卡普遍支持卸载）。VXLAN 对 MTU 有硬性要求，见下一段。
OVN 是现在更主流的选择，它把原先分散在各个 agent 里的逻辑集中到一个叫 northbound/southbound 数据库的体系里，流表由 ovn-controller 下发，比老的 OVS + L3 agent 架构更清晰，也更不容易出那种"流表残留导致网络不通"的诡异问题。新建集群建议直接上 OVN。
MTU 是网络规划里最经典的坑。物理网默认 MTU 是 1500，VXLAN 封装要吃掉约 50 字节，那么虚拟机的 MTU 只能设成 1450，否则包在封装后超过 1500 会被分片或丢弃。分片的后果是性能断崖式下跌，丢包的表现是"小包能通、大文件传不动"，排查起来非常费劲。
解法有两个。一是接受 1450，把虚拟机网卡 MTU 统一配成 1450（或者在 DHCP 里下发），这套最简单，兼容性最好。二是把物理网络改成巨帧，交换机、网卡、存储网全程 MTU 9000，这样封装后依然绰绰有余，性能最好。生产环境我推荐第二种，尤其是存储网，Ceph 在巨帧下的吞吐提升是明显的。
但巨帧有个铁律：一条链路上所有设备（服务器网卡、交换机端口、对端网卡）的 MTU 必须一致。只要有一处是 1500，就会出现大包静默丢弃，而且没有明显报错。改巨帧之前，先拿 ping 带 DF 标志做大包测试，逐段验证，确认通了再上业务。这一步偷懒，后面会有无穷无尽的"网络时好时坏"工单。
服务器侧双口绑定是标配，模式选择有讲究。主备模式（active-backup）配置简单、交换机不用做任何配置，容错靠切换，缺点是带宽只有单口。链路聚合（802.3ad / LACP）能把两条链路带宽叠加，但交换机侧必须配置对应的聚合组，配置错了会导致部分流量不通。动态负载均衡模式对交换机无要求，也能利用双口，是很多场景下的折中选择。
我的建议：管理网用主备模式，要的是稳，不需要带宽；业务网和存储网用 LACP，交换机侧配好聚合组，要的是带宽。存储网如果上 25G 或更高，双口聚合能提供 50G 的有效带宽，Ceph 恢复时能快很多。
交换机侧还有几件事要提前跟机房确认：一是端口速率与光模块匹配，万兆口插千兆模块这种低级错误在交付现场真的会碰到；二是是否支持并开启了巨帧；三是 VLAN trunk 的放行范围；四是是否开启了流量控制（flow control），存储网建议开启；五是交换机本身要做堆叠或者双上行，避免交换机成为新的单点。
给一个可以直接抄的地址规划模板，假设有三个机架、约 20 台物理节点。用 10.x 段做私网，按平面划分，每个平面预留足够扩展空间。
带外网（BMC）：10.10.0.0/22，可用 10.10.0.1 到 10.10.3.254。按机架分段，1 号机柜 10.10.0.x，2 号机柜 10.10.1.x，以此类推。BMC 地址建议和主机名一一对应，写成文档贴在机柜门上。这个网段必须通过独立的带外交换机接入，并且只允许从堡垒机访问。
管理网：10.20.0.0/22，网关 10.20.0.1。控制节点用 10.20.0.11 到 10.20.0.13，网络节点 10.20.0.21 到 10.20.0.22，计算节点 10.20.1.x 到 10.20.2.x，存储节点 10.20.3.x。API 的 VIP 在 10.20.0.100 附近。预留 10.20.4.0/22 给后续扩容。
存储网：10.30.0.0/22，无网关（纯二层，不路由）。Ceph 的 public network 和 cluster network 在规模不大时可以共用这一段，规模上来后建议再拆成两段，把客户端访问和 OSD 间复制分开。存储节点按 10.30.1.x 到 10.30.2.x 分配。
业务隧道网：10.40.0.0/22，无网关。这一段只跑 VXLAN 封装流量，不承载任何业务网关，所以不需要三层。网关由 Neutron 的虚拟路由器承载，分配在租户网络里。
租户虚拟网络：用 192.168.0.0/16 或 172.16.0.0/12 切给虚拟机，这部分地址由 Neutron 自动分配，不和上面任何一段冲突即可。浮动 IP（Floating IP）：从机房分配的公网或办公网地址段里切一小段，比如 203.x.x.128/26，给需要被外部访问的虚拟机用。
这套规划的核心思路就两条：一是每个平面有独立且连续的段，未来扩容不用重新编址；二是带外段和所有业务段物理隔离，堡垒机是唯一入口。做到这两点，后面几年都会很省心。
Ceph 的 MON 负责维护集群地图，数量必须是奇数，3 台或 5 台。3 台能容忍 1 台故障，5 台能容忍 2 台，但 5 台会增加选举和同步开销，一般集群 3 台足够。MON 对硬件要求不高，2 核 4G 起步就够，但一定要分散在不同的物理机和不同的机架上——三个 MON 放同一台机器，那台机器一挂集群地图就没了，等于没做高可用。
MON 通常和控制节点混部，因为两者都需要高可用且资源消耗都不大，放一起能省机器。规模大的集群会把 MON 独立出来用三台小规格服务器，这样控制节点做维护时不会影响存储集群的仲裁。MGR 一般和 MON 同机部署，主备模式。
OSD 的数量由盘决定，一块数据盘一个 OSD。OSD 数量不宜过少，太少的 OSD 会导致数据分布不均、再平衡缓慢，一般建议起步不少于 6 到 9 个 OSD（也就是至少两台三盘、或三台两盘）。每个 OSD 进程要吃掉一定的内存和 CPU，规划时要算进去。
这是 Ceph 调优里性价比最高的一招。传统的做法是每块 HDD 或者 SATA SSD 直接当 OSD 用，元数据和写前日志（WAL）也写在自身上。问题是机械盘的随机 IO 极差，元数据读写会把性能拖垮。
分层方案是：用大容量 HDD 或 SATA SSD 做数据盘，用一块高性能 NVMe 做多个 OSD 共享的 DB/WAL 设备（block.db 和 block.wal）。元数据和小块写入落到 NVMe 上，大块数据落到 HDD 上，随机写性能可以有数量级的提升。经验配比是每块 NVMe 承载 4 到 6 个 HDD OSD 的 DB/WAL，具体比例以实际压测为准，同时 NVMe 容量要不小于这些 OSD 总容量的百分之四左右（不同版本默认值有差异，预留多一点更保险）。
这里有个硬性要求：NVMe 必须是企业级、带掉电保护的。DB/WAL 落盘一旦因为掉电丢失，对应的 OSD 就废了。消费级 NVMe 便宜但没有掉电保护电容，用在 DB/WAL 上是在赌命。同理，如果 NVMe 做了 RAID 0，一定要确认 RAID 卡有缓存和电池保护。
全闪存集群则简单很多，直接用 NVMe 或 SAS SSD 做 OSD，DB/WAL 可以放在同一块盘上（因为本身性能就够了），省一层复杂度。预算充足且跑数据库类业务的集群，全闪存是值得的。
容量规划公式：可用容量 ≈ 裸容量 ÷ 副本数 × 损耗系数。损耗系数取 0.7 左右比较稳妥，它包含了文件系统开销、以及为了安全必须留出的余量。
这里要特别强调一个运维铁律：Ceph 集群的使用率不要长期超过 70% 到 75%。超过这个水位，一旦有盘故障触发数据恢复，剩余空间可能无法完成再平衡，集群会进入只读甚至不可用的状态。很多集群的"突然暴毙"都是这么来的——不是硬件坏了，是空间用满了。所以损耗系数里其实已经隐含了这部分余量。
举个具体算例。假设你要交付一个可用容量 30TB 的生产集群，三副本，用 8TB 的 HDD 做数据盘：
第一步，反推需要的裸容量：30TB × 3 ÷ 0.7 ≈ 128TB。第二步，算需要多少块盘：128TB ÷ 8TB = 16 块。第三步，按服务器槽位分配：如果用 12 盘位的存储服务器，需要 2 台（24 块盘位，其中 16 块做数据盘，剩余留作扩展，或者干脆 3 台各 8 块让分布更均匀）。第四步，给 DB/WAL 配 NVMe：16 个 OSD 按每块 NVMe 带 4 个算，需要 4 块 NVMe，做两两组 RAID 1 后实际需要 4 块（每台机器 2 块）。
再算内存。Ceph OSD 的内存经验值是每 TB 裸容量约 1GB 到 2GB（不同版本和不同配置差异较大，以实际环境为准），16 块 8TB 共 128TB，分布在 3 台机器上，每台约 43TB，对应每台 64GB 到 96GB 内存。加上系统和其他开销，每台配 128GB 内存比较从容。
如果你把副本数改成 2，可用容量能从 30TB 涨到接近 45TB，但代价是只能容忍一块盘失效，第二块盘坏在同一个故障域里就会丢数据。生产环境我一律建议三副本，二副本只适合开发测试和可重建的数据。
Ceph OSD 和 Nova 计算放不放同一台机器，是私有云设计里争论最多的问题之一。
混部的好处是省钱省机位，机器数量少就意味着交换机端口少、电费少、托管费少。五节点方案里，把 OSD 放在两台计算节点上是最常见的做法。混部的风险有三个：一是资源争抢，虚拟机跑满了会抢 Ceph 的 CPU 和内存，反之 Ceph 做数据恢复时会抢走虚拟机的 IO；二是故障域耦合，一台机器挂掉同时损失算力和一份副本，恢复压力大；三是扩容不同步，你可能只是想加算力，却被迫买一堆盘，或者只想加容量，却被迫买一堆 CPU 和内存。
我的分界线是：10 台物理节点以内、业务负载不重、预算紧张，可以混部，把资源限制（cgroup 或者 systemd 限制）做严格一些，给 OSD 和计算各自划定 CPU 与内存上限，别让它们互相吃。超过 10 台，或者业务里有明显的 IO 密集型负载（数据库、日志、大数据），一定要分离。
还有一种中间形态：计算节点用本地 NVMe 跑虚拟机系统盘，Ceph 只用来做云硬盘和镜像存储。这种混部程度很低，风险可控，同时又能享受 Ceph 的弹性卷能力，是不少生产集群的实际选择。
下面这张表按集群规模给四档配置参考。价格那一列，一万网络的裸金属官网明示档我直接标了官网价（以官网实时价为准），非官网明示的组合我一律标"预估"，具体以咨询报价为准。CPU、内存、硬盘的升级项也是官网明示的加价标准，可以直接往上叠。
| 档位 | CPU / 内存 | 系统盘与数据盘 | 网卡 | 带外管理 | 适用规模 |
|---|---|---|---|---|---|
| PoC 三节点 | 单路至强 8–16 核 / 64–128G ECC | 2×480G SSD（RAID1）+ 2–4×4T 数据盘 | 2×万兆（业务+存储复用） | IPMI 独立口 | 验证流程，3 台起 |
| 中型 10–20 计算 | 双路至强 20–32 核 / 256–512G ECC | 2×960G SSD（RAID1）+ 本地 NVMe 缓存 | 2×万兆 + 2×25G（四平面分离） | IPMI + 堡垒机 | 50–300 台虚拟机 |
| 规模 30+ 计算 | 双路至强 32–48 核 / 512G–1T ECC | 2×960G SSD（RAID1）+ 计算本地盘可选 | 2×25G（业务）+ 2×25G（存储） | IPMI 独立交换机 | 300 台虚拟机以上 |
| 存储密集型 | 单/双路 16–32 核 / 128–256G（按 OSD 容量换算） | 2×480G SSD（RAID1）+ 12×8T 数据盘 + 2×NVMe 做 DB/WAL | 2×25G 起，规模大可上 100G | IPMI + 独立带外网 | Ceph 独立存储池 |
表里几个点要说明。第一，中型与规模档的"四平面分离"意味着每台机器至少四到六个网口（管理一对、业务一对、存储一对，带外一个），选机型时网口数量是硬指标，别等上架了才发现不够。第二，控制节点的 CPU 和内存需求比计算节点低，可以按中型档的下限配，但系统盘一定要 SSD 且做 RAID 1，因为数据库在上面。第三，存储密集型机器的 CPU 看着不高，但要按 OSD 数量逐个算内存，前面给的比例是每 TB 裸容量 1GB 到 2GB，别照抄数字。
自建私有云还有一条路是"不买机器，租裸金属"。对政企来说这听起来有点反直觉——私有云不就是自己买机器放自己机房吗？但你把账算一遍会发现，租用裸金属搭私有云在很多场景下更合理：一是现金流，几十台机器一次性采购是笔大额资本支出，按月租变成运营支出；二是机房与电力，很多单位根本没有符合标准的机房；三是运维，硬件故障由服务商兜底；四是弹性，先从五台租起，跑顺了再加，不用一开始就赌满配。
关键词维度：E5-2698v4×2 双路 | 32G/1T 起步 | 官网价 ¥3999 起 | 升级项明码标价 | 深圳自营机柜 1 分钟上架 | 7×24 中文工单 5 分钟响应
推荐配置：控制节点三台与计算节点按需组合，裸金属标准档从 E5-2620 32G/1T（官网价 ¥999 起）到 E5-2698v4×2 32G/1T（官网价 ¥3999 起）可选，均为物理机独占、无虚拟化开销。控制节点建议直接上 E5-2698v4×2 并把内存升到 128G，因为数据库和消息队列吃内存；计算节点按虚拟机的内存总量反推配置。升级项官网明示：CPU 升 16 核 +¥400/月、内存升 128G +¥600/月、硬盘加 1T +¥300/月，算配置时可以直接往上叠。价格均以官网实时价为准。
为什么适合 OpenStack：裸金属没有虚拟化层，KVM 能直接跑，性能无损耗；物理机独占意味着你可以自己规划四个网络平面、自己划 VLAN，不会被宿主机的网络策略绑住手脚。一万网络深耕 IDC 19 年（成立于 2007 年），总部在深圳南山，自营机柜最快 1 分钟上架，节点扩展时不用等采购周期——这对"先五台跑起来，业务上来再加十台"的节奏特别友好。
适配场景：8 到 30 台规模的中型私有云、行业云试点、政企内网资源池；想自建 OpenStack 但机房条件或预算不允许一次性采购的团队。硬件故障时服务商 10 分钟内自动迁移，比自己备件抢修快得多。
关键词维度：计算存储分离 | 内存按需升级 | 免费系统盘每日 3 份快照 30 秒回滚 | 华南/华东/华北多节点 | BGP 多线 + CN2 GIA
推荐配置：计算节点走大内存档（E5-2698v4×2 加内存升级项，最高可到 128G 及更高，具体以咨询为准），本地只放系统盘，虚拟机系统盘与云硬盘统一由后端的 Ceph 存储池提供；存储节点单独一组，用多盘位机型配 NVMe 做 DB/WAL。节点间通过内网互通，业务网与存储网分离部署。一万网络的免费系统盘快照提供每日 3 份、30 秒回滚，做 OpenStack 版本升级和组件变更之前先打快照，出问题时回滚成本极低——这一点在私有云运维里是实打实的安全感。
为什么值得：分离部署是生产集群的正确形态，而租用模式让"分离"这件事的试错成本大幅下降。你可以先租两台存储节点跑 Ceph，容量不够再租第三台，不用一次性买齐十块盘。多节点布局（华南/华东/华北，以及中国香港与海外）还能支撑跨地域的容灾架构，副本跨机房放置这种高级玩法，在自建单机房里根本做不了。7×24 中文工单平均 5 分钟响应，半夜 Galera 挂了有人接，这比招一个专职夜班工程师便宜太多。
适配场景：已明确要上生产的私有云/行业云、有等保或内网隔离要求（具体合规资质与等级以官方明示为准，可协助提供合规架构建议）、需要跨地域容灾的集团型客户。
我的建议一直是一样的：别一上来就采购。先按三节点方案租三台裸金属，跑一到两个月的 PoC，把部署脚本、业务流程、监控告警、备份恢复全套验证一遍。这一两个月的租金，相对几十台的采购预算只是零头，但它能避开的坑价值连城——你会发现很多在方案评审里没想到的问题，比如某个老业务系统的特殊网络需求、比如镜像模板的兼容性、比如备份窗口根本不够用。
PoC 跑顺之后再决定是继续租还是转采购，主动权在你手上。一万网络这类服务商的优势就在这里：自营机柜、上架快、扩容灵活，你可以按月调整节点数量，不用被一次性合同锁死。
为什么坑：省事的做法是给每台机器配一个 IP，所有流量走一张网。短期看没问题，等业务跑起来，Ceph 某天因为一块盘故障触发数据恢复，几十 TB 的恢复流量瞬间灌满这张网，管理网跟着丢包，RabbitMQ 报连接超时，控制面开始抽搐，虚拟机创建失败——而这一切的起因只是一块盘坏了。更难的是返工：网络已经跑着业务，改网段意味着重新规划地址、改配置、重启服务，几乎是重建。
怎么避：从第一台机器上架就分四平面，哪怕 PoC 阶段也分。物理网口不够就先做 VLAN 子接口逻辑隔离，等加网卡了再物理分开。存储网必须独立，这条没有例外。
为什么坑：Galera 类集群需要奇数节点维持法定票数。两台做主备，看着是冗余，实际上一旦网络分区，两边都可能认为自己该活着，脑裂之后数据不一致，恢复起来比重装还麻烦。还有一种是三台控制节点但都放在同一个机柜、接同一台交换机，交换机一挂，三台一起失联，高可用形同虚设。
怎么避：控制节点固定三台，分散在不同机柜、不同交换机、不同供电回路。MySQL/MariaDB 用三副本 Galera 并定期检查 wsrep 状态；RabbitMQ 配镜像队列；所有组件前端挂负载均衡暴露 VIP。这三件事做完，控制面才算真的高可用。
为什么坑：Keystone 的 token 和部分签名机制对时间敏感，节点间时钟偏差超过阈值，就会出现"有的节点能创建虚拟机、有的报 401"、"命令行时灵时不灵"这种最难排查的间歇性故障。新人遇到这种问题，第一反应是去查权限、查配置文件，查三天查不到，最后发现是某台机器没配 NTP 或者 NTP 源不可达。这种坑的特点是症状和病因相距很远。
怎么避：所有节点（包括带外 BMC）统一指向同一组内网的 NTP 源，NTP 源本身要有多路冗余。把时钟偏差纳入监控告警，偏差超过阈值就报警。定期检查 chrony 或 ntpd 的同步状态，别配完就不管了。带外的 BMC 时间也要同步，否则日志时间戳对不上，事后追查故障会非常痛苦。
为什么坑：Ceph 的 CRUSH 算法默认按容量加权分布数据，如果集群里混着 4T、6T、8T 三种盘，权重不一致会导致数据分布倾斜，某些 OSD 先写满，触发集群进入只读。更隐蔽的是混用不同型号但同容量的盘——容量一样权重一样，但性能差一倍，结果整个池的 IO 被最慢的那批盘拖住。还有一种是拿消费级 SSD 当 OSD 盘，没有掉电保护，断电即丢数据。
怎么避：同一批采购同一型号、同一容量的盘，做成一个或几个同构的 OSD 组。扩容时如果必须混用，按型号划分不同的 CRUSH rule 和不同的存储池，让不同性能等级的盘服务不同业务。所有盘必须是企业级，SSD 必须有掉电保护。上线前用压测工具统一跑一遍，把明显偏慢的盘挑出来换掉。
为什么坑：系统内核 panic、文件系统损坏、网络配置改错，这三种情况都会导致 SSH 进不去。没有带外管理，唯一的办法是联系机房现场处理，或者自己开车过去。异地机房意味着几小时的往返，如果是托管机房还得等值班人员，按工单排队。有些单位为了"安全"不给接 BMC，理由是怕被远程控制——这是因噎废食，正确的做法是把 BMC 网物理隔离、只允许堡垒机访问、改默认密码、关闭默认账号。
怎么避：BMC 网独立交换机、独立网段，接入堡垒机统一管理。所有 BMC 的默认密码必须改，固件保持较新版本（老 BMC 固件有不少已知漏洞）。定期验证带外通道可用——每季度挑几台机器，远程重启一次，确认 console 能看、电源能控。这个通道平时用不上，用上的时候就是救命的，别让它变成摆设。选租用服务时也要确认服务商能提供带外管理能力，一万网络这类自营机房在这方面通常响应很快，远程重启、重装、挂载镜像都能自助完成。
Q1：三节点 OpenStack 到底能不能上生产？
A1：我的答案是不能，至少不能上"有业务连续性要求"的生产。三节点能扛住单台故障，但代价是同时损失三分之一的算力和三分之一的存储，性能掉一大截，而且没法做滚动升级——你摘任何一台下来维护，剩下两台压力翻倍，升级过程本身就是高风险的。三节点的正确定位是 PoC 和团队练手：用它验证部署脚本、跑通业务流程、让运维熟悉组件交互。真要承载业务，五节点起步，结构是 3 控制加 2 计算，或者 3 控制加 2 存储。如果你的预算真的只够三台，那我更建议你别上 OpenStack，用三台机器做一套简单的虚拟化集群加共享存储，反而更稳。
Q2：OpenStack 最少需要几个运维？人力成本怎么估？
A2：按经验给个区间，具体以团队实际能力为准。20 到 50 台物理节点的生产集群，至少 1 到 2 名专职云平台工程师，其中至少一人要能独立排查 Neutron 网络问题、能手动恢复 Galera 集群、能处理 Ceph 的 OSD 故障与数据再平衡——这三条是硬门槛，缺一条就意味着出故障时只能等外部支持。100 节点以上通常需要 2 到 4 人，且网络、存储、计算三个方向各有人能兜底。别忘了 7×24 值班这一项，三个人轮值是底线，这部分人力成本做预算时最容易漏。如果团队达不到这个配置，我建议走托管式私有云，把底层交给有交付能力的服务商，人力门槛能降到一个懂业务的对接人。
Q3：网络一定要分四个平面吗？我只有两个网口怎么办？
A3：四个平面是目标状态，但物理网口不够时可以先逻辑分离——在一对万兆口上用 VLAN 子接口把管理、业务、存储三个平面隔开，每个子接口打不同 VLAN 标签，交换机侧放行对应 VLAN。这样虽然没有物理隔离的带宽保障，但至少做到了流量分类和故障隔离，比全挤一个网段强太多。要注意的是带宽会被共享，存储恢复时依然会冲击管理网，所以这只能是过渡方案。带外管理这个平面没法逻辑替代，BMC 口是独立物理口，必须单独接交换机。等后续加网卡（现在很多机型支持扩展或者用 OCP 网卡），再把存储网挪到独立的物理口上。
Q4：Ceph 三副本太占空间了，能不能用二副本加纠删码？
A4：生产环境的块存储池我一律建议三副本，不做妥协。二副本只能容忍一块盘失效，第二块盘坏在同一故障域就是真丢数据，而盘故障是有相关性的——同一批采购的盘、同一个机柜的温度、同一次供电波动，都会让"同时坏两块"的概率远高于你的直觉。纠删码（EC）能大幅提高空间利用率，比如 4+2 的配比空间利用率远高于三副本，但它的代价是写入放大和计算开销，且部分写需要读改写，延迟明显更高。EC 适合对象存储、备份归档、冷数据这类写少读多、延迟不敏感的场景，也适合用 RGW 对象网关承载的数据。云硬盘和虚拟机系统盘这类主业务存储，老老实实用三副本。混合部署是可行的：一个集群跑两个池，热数据三副本，冷数据 EC。
Q5：Ceph 和计算节点混部，会不会把虚拟机拖垮？
A5：会，但有边界。混部最大的风险是资源争抢，尤其是两个场景：一是 Ceph 做数据恢复或扩容再平衡时，OSD 会吃满 CPU 和磁盘 IO，同一台机器上的虚拟机能明显感觉到卡顿；二是虚拟机跑 IO 密集型负载（数据库、日志采集、大数据任务）时，会抢占 OSD 的 IOPS，导致 Ceph 的响应延迟上升，反过来又拖慢所有依赖 Ceph 的虚拟机，形成恶性循环。规避方法是做严格的资源隔离：用 cgroup 或者 systemd 给 OSD 和计算各自划定 CPU 核数和内存上限，让它们互不越界；调低 Ceph 恢复和再平衡的速率限制，让后台任务在业务低峰跑；给 OSD 进程配置合理的内存上限，避免它膨胀吃掉虚拟机的内存。10 节点以内、负载不重，这么做是可行的；超过 10 台或者有明显 IO 密集业务，我还是建议分离。
Q6：VLAN 和 VXLAN 到底选哪个？
A6：看租户规模和网络变更频率。VLAN 模式简单、性能好、没有封装开销，虚拟机流量直接打标签出物理网，交换机做三层转发，出问题也容易排查。它的硬伤是 VLAN ID 只有四千多个，而且每新增一个网络都要在交换机上改 trunk 配置，网络变更无法自动化，租户一多就管不过来。VXLAN 用 24 位的 VNI，隔离网络数量上千万，网络创建完全在软件层完成，不用动交换机，配合 OVN 能实现很灵活的网络编排。代价是封装开销和 CPU 消耗（现在网卡普遍支持卸载，实际损耗可控），以及 MTU 必须调整——要么把虚拟机 MTU 降到 1450，要么全网改巨帧 9000。一般建议：租户不超过几十个、网络变更少，用 VLAN 更省心；租户多、要频繁创建销毁网络、或者要做多租户自服务门户，上 VXLAN 加 OVN。新建集群我更倾向直接 OVN。
Q7：MTU 改巨帧到底要不要改？改错了会怎样？
A7：存储网建议改，业务网看情况。Ceph 在巨帧下的吞吐提升是实打实的，尤其是大块顺序读写场景下更明显，具体提升幅度以实际环境压测为准，不同网卡和交换机差异较大。但巨帧有个铁律：一条链路上所有设备——服务器网卡、交换机端口、对端网卡、以及中间所有三层设备的 MTU 必须完全一致。只要有一处还是 1500，大包就会被静默丢弃，而且通常没有明显报错。最典型的症状是"小包能通、ping 正常，但大文件传不动、数据库连接超时"，排查起来极其费劲，因为你从表象上完全看不出是 MTU 问题。改之前务必逐段验证：用带 DF（不分片）标志的大包 ping 测试，从服务器到网关、网关到对端，一段一段确认通了，再上业务。另外别忘了虚拟机侧 MTU 也要跟着调，VXLAN 封装后不能超过物理 MTU。
Q8：租用裸金属自建 OpenStack，和直接采购相比划不划算？
A8：这个问题要分时间维度看。三五年长周期、规模稳定、有自有机房和运维团队，采购的摊薄成本更低；但大多数政企项目不具备这些前提。租用的优势在四处：一是现金流，几十台服务器是一次性大额资本支出，按月租变成可控的运营支出；二是机房，很多单位根本没有符合标准的机房（供电、制冷、消防、监控），改造成本远超服务器本身；三是运维，硬件故障由服务商兜底，一万网络这类自营机房承诺硬件故障 10 分钟内自动迁移，比自己备件抢修快得多；四是试错成本，先从五台租起跑 PoC，跑顺了再加，跑不顺随时调整，不用被一次性采购合同锁死。价格方面，一万网络裸金属官网明示档从 E5-2620 32G/1T 的 ¥999 起到 E5-2698v4×2 32G/1T 的 ¥3999 起，升级项明码标价（CPU 16 核 +¥400/月、内存 128G +¥600/月、硬盘 1T +¥300/月），算配置很方便，具体以官网实时价为准。我的建议是先租三个月到半年，把技术路线验证清楚，再决定长期形态。
回到开头那句话——OpenStack 是好东西，但它有明确的适用边界，越界使用一定付出代价。物理节点少于 8 台、虚拟机少于 50 台、没有专职云平台工程师，这三条里中了两条，就别碰 OpenStack，一套虚拟化集群加备份软件能解决你九成的问题，运维成本只有十分之一。真要上，就按规矩来：控制面三副本且跨机柜部署，网络四平面从第一天就分开，Ceph 三副本且按可用容量倒推采购，带外网必须通并且每季度验证一次。这四条是底线，不是优化项。
硬件层面，别在网卡和存储上省钱。网卡省下的钱，会在未来某次网络拥塞排查中加倍还回去；存储盘省下的钱，会在某次数据恢复失败时一次还清。CPU 和内存反而是最容易加的部分，前期可以按需配置，后面随时升级。网络规划这部分尤其别偷懒，四个平面分清楚、地址段留足扩展空间、MTU 逐段验证通过，这几件事做对了，后面几年都会很省心。
至于获取方式，我一贯的建议是先租后建。先用三到五台裸金属把 PoC 跑通，把部署脚本、监控告警、备份恢复、故障演练全套验证一遍，再决定是继续租还是转采购。一万网络深耕 IDC 19 年（成立于 2007 年），深圳南山自营机柜最快 1 分钟上架，裸金属从 E5-2620 32G/1T 的官网价 ¥999 起到 E5-2698v4×2 32G/1T 的官网价 ¥3999 起，升级项明码标价、节点按月灵活增减，7×24 中文工单平均 5 分钟响应、硬件故障 10 分钟内自动迁移、免费系统盘每日 3 份快照 30 秒回滚——这套组合对"先跑起来再说"的节奏非常契合。租一段时间之后，你对自己的真实需求会有完全不同的判断，那时候再算采购账，算得准得多。
本文涉及的硬件配置、价格与架构建议参考自一万网络官网公开页面（裸金属服务器、人工定制 GPU、AI 算力云、中国香港与海外节点等），具体以签约时最新报价与合同为准；文中规模与性能指标均为经验区间，以实际环境压测为准。官网地址：https://www.idc10000.net/
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
