简介：面向虚拟化运维、系统集成及技术管理者的 ProxmoxVE 超融合项目实践记录。此方案源于将两个机柜的传统服务器整合为 3~4 台节点的超融合集群，围绕成本敏感、统一管控、去中心化和在线扩容等现实诉求，给出从现状评估到落地的完整路径。文档共 1 个 docx 文件，压缩包大小 3.17MB，详细记录了服务器选型、系统安装过程中遇到的 DHCP 问题及改用 PVE 5.4 U 盘安装的排错思路、网络配置、集群创建、Ceph 分布式存储配置，以及暴力关机后虚拟机自动漂移等高可用验证。已有 269 人学习下载。读者可据此了解超融合改造的整体步骤和关键细节，特别适合正在规划 ProxmoxVE 集群、想规避同类安装与配置坑位的工程师参考；文档还穿插了实际机房操作中的经验细节，便于边看边对照实践。
1. 为什么我会用 Proxmox VE 做超融合
先说结论：我在一个 50 人左右的研发团队里做基础设施运维，手上有 6 台旧服务器——都是前几年采购的 2U 机架式设备，配置不算差，但单台跑虚拟化又浪费，全堆着吃灰更浪费。当时面临的需求很实际：要跑约 20 台研发测试虚拟机，要存持续增长的 CI 构建产物，还要保证服务不因单台宿主机宕机而中断。预算有限，商用超融合动辄几十万授权费根本不在考虑范围内，于是我把目光投向了 Proxmox VE（以下简称 PVE）。
PVE 是开源的服务器虚拟化管理平台，底层基于 Debian 和 KVM，自带 Web 管理界面，最核心的一点是它内建了 Ceph 分布式存储支持。Ceph 可以把多台服务器的本地磁盘聚合成一个统一存储池，再和 PVE 的计算能力组合，就构成了典型的超融合架构——计算和存储跑在同一个节点池里，通过软件定义方式横向扩展。这套方案不需要额外购买共享存储（比如 SAN 或 NAS），也不用单独为存储节点付费，几台普通 x86 服务器就能起步，对预算敏感的中小团队来说非常友好。
写这篇文章，是想把这次从零搭建 PVE 超融合环境的完整过程记录下来，包括硬件规划、Ceph 配置、网络调优、HA 设置以及我踩过的坑。内容更适合有一定 Linux 基础、打算自建私有云或超融合环境的朋友参考。如果你正在商业超融合和开源方案之间犹豫，本文也能提供一个真实可对照的样本。
2. 超融合整体方案设计与硬件规划
2.1 为什么选择 Ceph 而非内置 ZFS 复制
PVE 本身支持两种常见的高可用存储方案：ZFS 复制和 Ceph。我最初试过 ZFS 复制模式——它实现简单，在两台节点间做 ZFS 快照定期同步，但存在几个问题：一是数据只能在一个副本上，故障切换依赖另一节点的同步进度，数据丢失窗口较大；二是仅支持两节点场景，扩展性有限；三是同步频率越高，对磁盘 IO 消耗越大。对比之后，Ceph 的优势很明显：数据默认多副本（通常是三副本），任何一个节点宕机都不会丢失数据；支持任意节点数横向扩展；天然集成在 PVE 的集群栈里，创建虚拟机时直接选择 Ceph 存储即可。
Ceph 的原理可以这样理解：它把每台服务器的磁盘（OSD）组织成一个大数据池，数据写入时被切分成多个对象，每个对象按照 CRUSH 算法分布到不同的 OSD 上，同时写入多个副本。读取时也从多个副本并行读取，这样既保证了数据冗余，又分散了 IO 压力。
2.2 硬件选型与网络拓扑设计
超融合的硬件配置直接决定了最终性能和可用性，我在这块花的精力最多。先说节点数：Ceph 官方建议生产环境至少 3 个节点，为了凑出 3 节点我也把原本吃灰的 6 台机器做了筛选，最终留下 3 台配置接近的服务器作为集群节点，配置如下：
| 部件 | 配置 | 说明 |
|---|---|---|
| CPU | 双路 Xeon Silver 4114（10 核 20 线程） | 足够支撑计算虚拟化，开启超线程 |
| 内存 | 128GB DDR4 ECC | 虚拟机内存占用大头，Ceph 也会用部分内存做缓存 |
| 系统盘 | 240GB SATA SSD x1 | 安装 PVE 系统，不做存储池 |
| 数据盘 | 480GB SATA SSD x1 + 4TB SATA HDD x3 | SSD 做 Ceph 的 DB/WAL 加速盘，HDD 做数据盘 |
| 网卡 | 板载千兆 x2 + 双口万兆光口 x1 | 千兆做管理网络，万兆做 Ceph 数据网络 |
这里有一个关键设计：Ceph 的数据网络必须和管理网络物理隔离。Ceph 的同步流量非常大，如果和管理流量共用千兆网络，一个节点宕机触发数据重均衡时，整个集群的管理页面都会卡死，虚拟机网络也会剧烈抖动。我采用了双网卡绑定方案：两个万兆口分别连接到独立交换机（或同一交换机不同 VLAN），一个用于 Ceph public 网络，一个用于 Ceph cluster 网络；管理流量走千兆。
关于磁盘规划，我要特别提醒一点：Ceph 的 OSD 数据盘不一定要全 SSD，机械盘 + SSD 做 WAL/DB 是性价比很高的组合。Ceph 写入数据时先写 WAL（预写日志）再落盘，WAL 和 DB 放在 SSD 上可以极大降低机械盘的随机写入压力，把小文件随机写转换为顺序写。我在每个节点上把 480GB SSD 分出 60GB 给 Ceph 的 DB，20GB 给 WAL，具体大小可以根据 OSD 数量调整，通常建议 DB 大小是数据盘容量的 1% 到 2%。
2.3 资源估算与容量规划
在正式动手前，我先做了容量和性能估算。假设每台虚拟机平均分配 4 核 8GB 内存，20 台虚拟机总需求是 80 核 160GB 内存——单节点内存 128GB 明显不够，所以我将虚拟机规格降到 2 核 4GB（研发测试环境足够用），总需求变为 40 核 80GB，3 个节点内存总量 384GB，可以满足并留有 40% 余量。
存储容量方面，我按 Ceph 三副本策略算：每个节点 3 块 4TB HDD，总原始容量 36TB，三副本后可用容量约为 12TB，再减去 Ceph 默认的 min_size（允许最少副本数）和防水满阈值（默认 85%），实际可用大约 9TB。这个容量对 CI 产物和测试环境数据来说很充裕。
这些计算看似简单，但很多人会忽略副本开销，等到存储写满才发现可用容量远低于预期，所以我建议在开局就把"原始容量 / 副本数 * 0.85"这个公式刻在脑子里。
3. 核心实施细节与 Ceph 集群搭建
3.1 PVE 基础安装与集群初始化
PVE 安装本身不复杂，从官网下载 ISO 写入 U 盘启动，按照向导配置时区、网卡 IP、root 密码即可。一个容易忽略的点是安装时选择的文件系统：建议系统盘使用 ext4 而非 ZFS，因为 ZFS 会吃掉大量内存做 ARC 缓存，在超融合场景下内存要优先保证虚拟机和 Ceph。
三台节点安装完成后，我在第一台节点上执行：
pveceph init --network 10.10.10.0/24这个命令会初始化 Ceph 并指定 public 网络为 10.10.10.0/24。紧接着把另外两个节点加入集群：
pvecm add 10.10.10.1需要注意的是，节点加入集群时必须能通过主机名互相解析，我在 /etc/hosts 中手动添加了三台节点的 IP 和主机名映射，否则加入集群时会报"unable to resolve host"错误。集群创建完成后，再通过 pveceph 命令添加 Monitor、Manager 和 OSD。
3.2 Ceph 存储池创建与 PG 数量计算
Ceph 存储池（Pool）是虚拟机磁盘镜像存放的地方，创建前最关键的是确定 PG 数量。PG（Placement Group）是 Ceph 管理数据分布的最小单位，PG 数量过少会导致数据分布不均，过多则消耗大量内存和 CPU。行业经验公式是：
PG 总数 = (OSD 总数 × 100) / 副本数
本例中 OSD 有 9 个（三节点 × 3 块 HDD），副本数 3，所以 PG 总数 = (9 × 100) / 3 = 300。如果做一个池，建议取 256 或 512（2 的幂次）。我给虚拟机磁盘池设置了 512 个 PG，给块设备池设置了 128 个 PG（因为块设备 IOPS 要求高，不建议太多 PG）。
创建命令如下：
ceph osd pool create vm-images 512 ceph osd pool application enable vm-images rbd这里强调一下，PVE 6.x 以上版本要求每个 pool 必须设置 application 类型（rbd/cephfs/rgw），不设置的话健康检查会一直告警。
3.3 OSD 添加与磁盘分组策略
添加 OSD 时，我采用了手动指定方式，把 HDD 和 SSD 分开处理。对于每块 4TB HDD：
pveceph osd create /dev/sdb对于 SSD，我先把磁盘分区，分出 db 和 wal 分区，再创建 OSD 时指定 db 和 wal 设备：
sgdisk -n 1:0:+20G -n 2:0:+60G -n 3:0:0 /dev/sdc pvcreate /dev/sdc3 vgcreate ceph-db /dev/sdc3 lvcreate -L 20G -n wal ceph-db lvcreate -L 60G -n db ceph-db ceph-volume lvm create --data /dev/sdd --db /dev/ceph-db/db --wal /dev/ceph-db/wal这样每个节点的 3 个 OSD 都共享 SSD 上的 WAL 和 DB 空间，机械盘顺序写的优势就能发挥出来。需要提醒的是，SSD 使用寿命与写入量强相关，WAL/DB 分区不建议太小，否则空间不足会导致 OSD flapping。
4. 网络调优与虚拟机高可用配置
4.1 万兆网络参数调优实战
Ceph 对网络延迟和丢包非常敏感，我在部署完基础集群后做了一次详细压测，发现默认内核参数下万兆网卡跑不满，延迟也偏高。问题主要出在默认的 TCP 缓冲区大小和中断合并策略上。
调整方案如下（三台节点都要执行，写入 /etc/sysctl.conf）：
net.core.rmem_max = 134217728 net.core.wmem_max = 134217728 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 net.ipv4.tcp_rmem = 4096 87380 134217728 net.ipv4.tcp_wmem = 4096 65536 134217728此外，我关闭了网卡的内核节能模式（如 coalesce 和 adaptive-rx），因为它在高吞吐下会引入微秒级延迟，对 Ceph 同步影响明显。执行ethtool -C enp1s0f0 rx-usecs 0 adaptive-rx off后，Ceph 的写入延迟从之前的 5ms 降到了 1ms 以内。
4.2 磁盘性能测试与 Ceph 读写验证
集群配置完成，我用自带的 rados bench 做了读写压测：
rados bench -p vm-images 120 write --no-cleanup rados bench -p vm-images 120 rand第一次测试结果很不理想，4K 随机读 IOPS 只有 3000 左右。排查后发现是 HDD 的 OSD 没有设置独立的 journal（WAL），所有随机写都直接落在机械盘上。虽然我前面已经加了 SSD 分区作为 WAL/DB，但 Ceph 的 LVM 方式下，WAL 和 DB 必须显式绑定到每个 OSD，否则默认走数据盘自身。重新调整后随机读 IOPS 提升到 2.2 万，写 IOPS 到 1.3 万，符合预期。
这里我想强调一个测试技巧：rados bench 的数字只能反映底层存储能力，不能代表虚拟机内的真实磁盘性能，因为虚拟机层还有文件系统缓存和虚拟磁盘格式（raw/qcow2）的开销。我在完成虚拟机磁盘创建后，又在虚拟机内用 fio 做了测试，才得到最终参考值。
4.3 启用 HA 实现虚拟机故障自动迁移
超融合的"融合"不只是存储和计算的融合，还包括高可用。PVE 内置了 HA 管理器，可以把虚拟机或容器纳入 HA 组，当某个节点宕机超过设定阈值时，虚拟机在集群内其他节点自动拉起。
启用 HA 的前提是：
- 至少 3 个节点（用于仲裁）
- 使用 Ceph 或者共享存储（本地存储无法做漂移）
- 每个节点时间同步（我配置了 chrony）
我通过 Web 界面将 20 台虚拟机全部加入 HA 组，并设置：
- 启动延迟（startup delay）：10 秒
- 宕机迁移阈次数：3 次
- 恢复策略：尽可能恢复到原节点（默认）
实际操作中我发现一个容易踩坑的点：虚拟机如果使用了 PCI 直通设备（比如 GPU），HA 迁移会失败，因为 PCI 设备无法随虚拟机漂移。如果业务必须直通设备，就不要把它加入 HA 组，否则故障时反而会产生误迁移和不必要的告警。
5. 常见问题与故障排查记录
5.1 Ceph 数据重均衡导致线上业务卡顿
超融合上线运行一个月后，一次拔盘维护引发了大规模数据重均衡，结果所有虚拟机磁盘 IO 明显变慢，业务侧监控出现毛刺。原因是 Ceph 默认的重均衡速度参数没有做限制，数据恢复抢占大量磁盘和网络资源。
解决办法：在 ceph.conf 中设置以下参数并重启 Ceph 服务（或在线生效）：
osd_max_backfills = 1 osd_recovery_max_active = 1 osd_recovery_max_single_start = 1 osd_backfill_scan_bucket_max = 64这样可以把恢复速度限制住，保证业务 IO 优先。运维上建议把维护窗口安排在业务低峰期，并在操作前主动调低恢复优先级。
5.2 PVE 集群出现 split-brain（脑裂）
有一次因为误操作导致两个节点之间的万兆网络断开了几秒，PVE 集群出现 fencing 和脑裂现象，Ceph 的健康状态变成 HEALTH_ERR，部分虚拟机被误重启。
排查路径是这样的：
- 我先用
pvecm status检查集群成员和 quorum 状态 - 发现丢了一个节点，quorum 只有 2/3
- 检查网络，恢复后使用
pvecm expected 3临时指定期望成员数，让集群恢复 quorum
Ceph 侧，OSD 因为网络抖动被标记为 down，用以下命令强制恢复：
ceph mon enable_session_authentication ceph osd down 0 1 2 ceph osd in 0 1 2这类问题的深层教训是：超融合集群的网络稳定性是整个系统的生命线，管理网和数据网必须冗余，且交换机开启 STP（生成树协议）快速收敛。生产环境建议至少用双万兆网卡绑定（bond mode 4）连接两台不同的交换机，避免单点网络故障。
5.3 虚拟机磁盘空间未立即释放
删除虚拟机后，Ceph 的 RBD 磁盘空间不会立刻归还给存储池，这其实是正常现象——Ceph 在后台异步回收。但如果删除大量虚拟机，空间一直不释放，可以手动触发清理：
ceph osd pool ls ceph pg deep-scrub all或者检查是否有快照残留：
rbd snap ls vm-images实战中发现，快照是空间占用的大头。团队成员习惯在给虚拟机打快照后从不清理，几个月下来积累了几百个快照。我写了一个定时任务，自动清理超过 30 天的虚拟机快照，释放了几 TB 空间。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查/解决 |
|---|---|---|
| Ceph HEALTH_WARN 提示 pgs stuck unclean | 网络抖动或 OSD 异常 | ceph health detail 定位，恢复 OSD 或等待 peering |
| 虚拟机性能忽高忽低 | 存储池 PG 不均或磁盘故障 | 使用 ceph osd perf 查看慢 OSD，逐一替换 |
| PVE Web 界面 502 错误 | pveproxy 服务异常 | systemctl restart pveproxy；检查 /var/log/pveproxy/access.log |
| 节点重启后 OSD 不自动挂载 | LVM 配置丢失或磁盘顺序变化 | 检查 /etc/ceph/ceph.conf 的 osd crush location，重新激活 OSD |
| 虚拟机无法迁移 | 本地存储上存在磁盘 | 将磁盘迁移至共享存储后再迁移虚拟机 |
| Ceph 认证失败 | 密钥环过期或权限错误 | ceph auth get-or-create 重新生成 keyring |
6. 写在最后的实操体会
这套 PVE 超融合环境从规划到上线大约花了三周时间，运行半年多来整体稳定，只有两次因网络抖动触发过告警，没有出现过数据丢失或不可恢复故障。
我个人最大的体会是：超融合并不是简单地在 PVE 里点几个按钮装个 Ceph 就完事，最难的部分是网络设计和容量规划。网络只要有一个环节是单点，高可用就是空中楼阁；容量规划如果不算副本和快照开销，迟早被空间打脸。另外，日常运维中不要把 Ceph 当成黑盒，至少要学会看ceph -s、ceph osd tree、ceph df这三板斧，出问题的时候能少走很多弯路。
如果后续再扩展，我会考虑加入 CephFS 来跑有状态容器的持久化存储，或者用 PVE 的备份插件把虚拟机备份到远端对象存储，这套架构继续演进的空间还很大。希望这篇实践记录能给正在选型或搭建超融合的你一些参考。
本文还有配套的精品资源，点击获取
