简介面向虚拟化运维、系统集成及技术管理者的 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 411410 核 20 线程足够支撑计算虚拟化开启超线程内存128GB DDR4 ECC虚拟机内存占用大头Ceph 也会用部分内存做缓存系统盘240GB SATA SSD x1安装 PVE 系统不做存储池数据盘480GB SATA SSD x1 4TB SATA HDD x3SSD 做 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 的 DB20GB 给 WAL具体大小可以根据 OSD 数量调整通常建议 DB 大小是数据盘容量的 1% 到 2%。2.3 资源估算与容量规划在正式动手前我先做了容量和性能估算。假设每台虚拟机平均分配 4 核 8GB 内存20 台虚拟机总需求是 80 核 160GB 内存——单节点内存 128GB 明显不够所以我将虚拟机规格降到 2 核 4GB研发测试环境足够用总需求变为 40 核 80GB3 个节点内存总量 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 数量。PGPlacement Group是 Ceph 管理数据分布的最小单位PG 数量过少会导致数据分布不均过多则消耗大量内存和 CPU。行业经验公式是PG 总数 (OSD 总数 × 100) / 副本数本例中 OSD 有 9 个三节点 × 3 块 HDD副本数 3所以 PG 总数 (9 × 100) / 3 300。如果做一个池建议取 256 或 5122 的幂次。我给虚拟机磁盘池设置了 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 HDDpveceph 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.confnet.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 没有设置独立的 journalWAL所有随机写都直接落在机械盘上。虽然我前面已经加了 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 delay10 秒宕机迁移阈次数3 次恢复策略尽可能恢复到原节点默认实际操作中我发现一个容易踩坑的点虚拟机如果使用了 PCI 直通设备比如 GPUHA 迁移会失败因为 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临时指定期望成员数让集群恢复 quorumCeph 侧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 重新生成 keyring6. 写在最后的实操体会这套 PVE 超融合环境从规划到上线大约花了三周时间运行半年多来整体稳定只有两次因网络抖动触发过告警没有出现过数据丢失或不可恢复故障。我个人最大的体会是超融合并不是简单地在 PVE 里点几个按钮装个 Ceph 就完事最难的部分是网络设计和容量规划。网络只要有一个环节是单点高可用就是空中楼阁容量规划如果不算副本和快照开销迟早被空间打脸。另外日常运维中不要把 Ceph 当成黑盒至少要学会看ceph -s、ceph osd tree、ceph df这三板斧出问题的时候能少走很多弯路。如果后续再扩展我会考虑加入 CephFS 来跑有状态容器的持久化存储或者用 PVE 的备份插件把虚拟机备份到远端对象存储这套架构继续演进的空间还很大。希望这篇实践记录能给正在选型或搭建超融合的你一些参考。本文还有配套的精品资源点击获取