Proxmox VE 使用指南

外观

深入数据丢失风险PVE 9.x

资料核查：2026-09-29T00:00:00.000Z；尚无本站实机验证记录，请按文中的检查步骤确认本机结果。

三节点 Ceph 超融合集群设计 ​

三节点是 Ceph 超融合（hyper-converged）集群能稳定运行的最小规模，也是家庭实验室和小团队最常见的目标形态。官方管理指南《Deploy Hyper-Converged Ceph Cluster》给出的硬件建议只是「粗略参考」（rough guidance），但网络带宽、独立网络、磁盘类型这几条不是可选项。这篇把选型决策和实施顺序理顺，具体部署步骤见 Ceph 相关章节。

方案总览 ​

维度官方建议三节点场景的取舍
节点数量至少 3 台，最好配置相同三节点是能跑 3 个 Monitor（MON）保证仲裁（quorum）的最小规模
CPU每个 Ceph 服务至少预留 1 个核心/线程1 MON + 1 MGR + 6 OSD 的节点建议预留 8 核心给 Ceph
内存每个 OSD 至少 8 GiB3 节点 × 每节点若干 OSD，内存预算要在虚拟机之外单独留出
网络至少 10 Gbps 专供 Ceph，公共网络和集群网络分离没有 10G+ 交换机时，3～5 节点可以用全网状（full mesh）网络省掉交换机
磁盘企业级 SSD，带掉电保护（PLP），不推荐消费级 SSD；用 HBA 而非硬件 RAID 卡每节点磁盘容量和数量尽量均衡，例如都用 4 块 500 GB 而不是混搭大小盘
副本size 3 / min_size 2（默认）三节点场景不建议往下调，否则失去「任一节点故障不丢数据」的保证

需要用到的章节 ​

Ceph 部署与运维

集群基础

网络

高可用（可选，锦上添花）

实施顺序 ​

  1. 硬件选型：按上表确认三台节点配置尽量一致、磁盘全部用带 PLP 的企业级 SSD、通过 HBA 而非硬件 RAID 卡直通给 Ceph，网卡数量满足「corosync、Ceph 公共网络、Ceph 集群网络」三者分离的需求（预算有限时至少保证 corosync 独立）。
  2. 规划网络拓扑：三节点且没有 10G+ 交换机时，评估用全网状（full mesh）网络直连三台节点；有交换机时按「Ceph 集群网络 25+ Gbps、Ceph 公共网络 10+ Gbps、corosync 独立网络 1 Gbps」的思路分配网卡，见corosync 冗余链路规划。
  3. 组建集群：三台节点先按组建集群完成 corosync 集群，确认三节点都能维持仲裁（quorum）再继续。
  4. 部署 Ceph：按Ceph 超融合入门与部署在每个节点创建 MON、MGR，并把预留给 Ceph 的磁盘逐块加为 OSD。
  5. 规划 Pool 与副本：创建 Pool 时确认 size/min_size（默认 3/2），并理解三节点场景下的故障域是「节点」——一个节点整体下线时，剩下两个节点仍能维持数据完整和可读写。
  6. 压测与容量规划：正式迁移数据前，用小规模测试负载验证网络带宽是否够用、恢复（recovery）期间对业务的影响有多大，再决定实际能承载多少虚拟机。
  7. 可选：接入 HA：容量和网络确认稳定后，再考虑接入高可用，让虚拟机在节点故障时自动迁移。

风险评估 ​

单点故障 ​

三节点是 Ceph 能维持仲裁的最小规模，但也意味着没有冗余的冗余：一旦有一个节点长时间下线（不只是重启），集群会处于「仅剩两个 MON」的临界状态，此时如果再丢失一个节点或者一块关键磁盘，会直接失去仲裁或者触发数据不完整。三节点集群做维护（比如升级、加硬件）时应当一次只操作一台，并等集群恢复健康（HEALTH_OK）再操作下一台。

如果 corosync 和 Ceph 流量共用同一张网卡且没有做流量隔离，Ceph 恢复期间的大流量会挤占 corosync 的心跳，可能导致节点被误判离线并自我隔离（fence）重启——这是官方文档明确提到的风险，corosync 必须有独立或至少能保证低延迟的网络。

同一故障域 ​

三节点里的任何一台如果同时承担 Ceph 存储和运行大量虚拟机计算负载（超融合的本质），存储压力和计算压力会相互影响：某个节点计算负载过高，可能拖慢它上面的 OSD 响应，进而影响整个 Ceph 集群的写入延迟，而不只是这台机器自己的虚拟机变慢。

不要把 min_size 设为 1，也不要用消费级 SSD

min_size 为 1 的影响范围：允许只有一个副本在线时也能写入，一旦这个副本所在的 OSD 随后也故障，数据永久丢失或对象找不到，官方文档明确写明「do not set a min_size of 1」。回退：保持默认的 size 3 / min_size 2，只有明确理解并接受风险的临时排障场景才短暂调整，事后立刻改回。

消费级 SSD 的影响范围：Ceph 和 ZFS 一样会产生大量同步写入，没有掉电保护（PLP）的消费级 SSD 每次同步写都要落到较慢的闪存介质确认，导致延迟骤增、IOPS 大幅下降，官方管理指南的推荐系统需求里明确写「不推荐使用消费级 SSD」。前置条件：采购磁盘前确认型号带 PLP（通常是数据中心/企业级产品线）。回退：已经用了消费级 SSD 的集群，短期内没有立刻更换条件时，应把它当作性能受限的既成事实，不要指望靠软件配置弥补，中长期规划更换。

验收清单 ​

  • [ ] ceph -s 或 Web UI 的 Ceph 面板显示 HEALTH_OK，三个 MON 都在线
  • [ ] Ceph 公共网络与集群网络（如果做了分离）、corosync 网络三者互不挤占，做过恢复期间的带宽压测
  • [ ] Pool 的 size/min_size 符合预期（默认 3/2），没有为了「省空间」而下调
  • [ ] 手动关闭一个节点（模拟故障），集群在预期时间内恢复到 HEALTH_OK，且虚拟机数据可正常读写
  • [ ] 磁盘均为企业级 SSD（或已知情接受消费级 SSD 的性能代价），通过 HBA 而非硬件 RAID 卡直通
  • [ ] 三个节点的磁盘容量和数量均衡，容量规划留有恢复期间的缓冲余量

常见问题 ​

三节点够用吗，要不要一开始就上更多节点。 三节点是能维持仲裁的最小规模，能跑但容错空间小；如果预算和机位允许，4 节点起步能在一个节点下线维护时依然保留冗余余量，规划见Ceph 运维里关于故障域的部分。

没有 10G 交换机，Ceph 还能不能用千兆网络。 官方建议至少 10 Gbps 专供 Ceph；千兆网络能跑起来，但恢复速度和虚拟机的写入延迟都会明显受限，只适合对性能要求很低的测试场景，不建议用于承载正式业务。

Ceph 集群里某个节点自己重启了。 常见原因是 corosync 心跳被其他流量挤占导致误判离线，见节点自己重启了和corosync 冗余链路规划。

参考资料 ​

Proxmox VE 非官方中文使用指南，与 Proxmox Server Solutions GmbH 无隶属关系。