尧图网页设计 
简介一份聚焦ProxmoxVE超融合落地的技术方案文档适合系统运维、虚拟化工程师及正在规划低成本高可用改造的团队参考。文档完整记录某项目从多机柜服务器向3-4台物理机整合的实践先分析成本压力与业务萎缩背景再提出以ProxmoxVE 5.4构建超融合集群的需求与选型思路并逐步展开服务器挑选、U盘安装系统含DHCP卡住问题的排错替代、网络配置、集群及ceph创建、暴力关机验证虚拟机自动漂移等关键操作。同时归纳了降低成本、提高可用性、统一管控、去中心化、在线扩容五大收益结合真实机房环境给出内存升级等评估建议。整套资料仅有1个docx文档容量3.17MB属于高信息密度技术笔记已有269人学习。适用于需要快速掌握ProxmoxVE超融合落地全过程、避免同类踩坑的读者。 很多人一听“超融合”第一反应就是商业一体机一体箱、管理平台、金牌服务价格让人倒吸一口凉气。但如果你手里有三台性能够用的物理服务器又想把计算、存储、网络揉到一个池子里管理ProxmoxVE下文简称PVE加Ceph这套开源组合完全能顶上一套商业超融合方案而且实践下来稳定性并不差。我这边做过一个真实的项目客户机房有三台旧服务器想跑一套生产虚拟化环境包括十几台Web服务、数据库和内部业务系统。预算有限商业超融合平台的授权费直接超标。最后我选了PVE 8 Ceph作为超融合底座把三台机器组成一个统一资源池计算、存储全部软件化跑到现在大半年中间有节点宕机、有磁盘故障业务都没中断过。这篇文章就记录一下我在这个项目里的部分规划、部署和调优过程给准备动手折腾这套方案的朋友一个参考。1. 为什么非要用PVE做超融合——架构选型背后的现实考量1.1 超融合到底“融合”了什么超融合这个概念说白了就是把传统架构里各自独立的服务器、SAN存储、网络交换机揉成一个通过软件定义的资源池。传统架构下计算是计算存储是存储网络交换机还得单独维护超融合则是把三样东西塞进x86服务器的标准硬件里靠软件层把数据冗余、网络转发全部接管。PVE做超融合的核心组合是KVM虚拟化负责计算Ceph负责分布式存储节点之间通过网络同步数据。你看到的管理界面只有一个IP所有虚拟机、存储池、网络配置都能在Web端完成。这意味着你不需要再买昂贵的存储阵列也不需要单独配SAN交换机三台普通服务器插上网线、加上硬盘就能组成一个能自我修复的集群。1.2 和商业超融合方案的对比做这个项目前客户问过我能不能直接上深信服超融合平台毕竟人家界面漂亮、售后省心而且很多地方都在推这套方案。说实话商业超融合的完成度确实高备份、安全组件、一键部署全给你配好。问题在于授权费、硬件绑定、扩容时的溢价算下来往往比硬件本身还贵对预算敏感的中小项目并不友好。PVE走的是另一条路开源免费收费的只是企业版订阅而且只在企业源里限制部分更新社区源完全够用支持在任意兼容x86服务器上搭建不锁硬件。Ceph作为底层分布式存储经历了大规模生产环境验证本身已经非常成熟。如果你是运维经验凑合的团队愿意花时间读文档、做测试PVE这套超融合能省下至少五六位数。1.3 适合什么规模的场景根据我的实践经验三到十台节点的中小规模集群是PVE超融合最舒服的范围。再大也能跑但你得花更多精力在Ceph的监控和优化上运维成本会直线上升。小型开发测试环境、企业办公虚拟化、边缘计算节点、学校或医院的分支机房这类场景用PVE做超融合性价比极高。我之前帮人搭过两节点的PVE集群说实话两节点跑Ceph并不推荐因为osd分布在两台机器上挂掉一台数据就没了。如果只有两台机器建议用ZFS复制方案做数据冗余而不是硬上Ceph。Ceph超融合至少得三台起步这是架构决定的别指望省钱省出个奇迹。2. 规划阶段定生死网络拓扑、存储池与硬件选型2.1 网络规划三网分离这种“老话”还是要听超融合项目最容易忽略的就是网络规划说出来都是泪。Ceph的数据同步是持续产生流量的如果和业务网络挤在同一张网卡同一根线里虚拟机跑高峰时很容易把存储网络挤爆表现就是虚拟机IO延迟忽高忽低、节点CPU莫名飙升。我这个项目里做了三个网络平面管理网络用于PVE Web界面、SSH、corosync心跳千兆足够。业务网络虚拟机对外提供服务走万兆至少双网卡bond。存储网络Ceph内部数据复制和客户端读写这个一定要万兆起步。存储网络我是单独抽出来做VLAN隔离的用了两张独立万兆网卡做Linux bondmode 4即LACP交换机两个口做链路聚合这个冗余级别生产环境必须做到。corosync心跳没走万兆它包量小但对延迟敏感和存储网络分开反而更稳。很多新手图省事把所有流量跑在一个网络上前期数据量小看不出来等到存储写入大了Ceph内部心跳超时、osd被标记down、数据再均衡整个集群就开始抽搐了。所以网络规划这块宁可在交换机上多接两根线也别偷懒。2.2 存储设计副本数、PG数与故障域Ceph存储池设计上我给默认存储池设置了size3三副本。三个节点各存一份副本任意坏一台节点都不丢数据。如果你的集群节点多也可以考虑EC纠删码比如42或82能省一半多的空间但EC对CPU消耗大、重建慢中小项目三副本最省心。PGPlacement Group的数量很多人搞不明白我直接说经验公式总PG数 (OSD数量 × 100) / 副本数比如我有12个OSD、副本数3那总PG数就是400往2的幂次靠就是512。然后按存储池划分如果有两个主要存储池每个池256左右即可。我现在生产上一个池256一个池128跑了大半年PG分布一直均衡。一开始我犯过一个错误PG数拍脑袋设了32导致单个PG里面数据量巨大有个OSD挂了之后数据重均衡慢得让人怀疑人生整个集群IO卡了好一阵。后来把PG数按公式调整后重均衡时间缩短了三分之二。PG太少单点占用过高PG太多集群元数据开销又太大。这个度就在公式附近。2.3 硬件选型清单与建议这套项目里用的硬件如下组件建议配置实践说明CPU双路Xeon Silver级别虚拟化VCPU超分按1:3以内太多会导致CPU steal明显内存256GB起Ceph本身吃内存WAL/Buffer都靠它虚拟机再吃一大份系统盘2块SSD做RAID1装PVE系统和日志Ceph的OSD数据不要放这里OSD盘每节点至少4块数据盘推荐SSD或NVMe机械盘做OSD生产会很痛苦OSD加速盘可选的NVMe/SSD用于Bluestore的WALDB分离能显著提升小IO性能网卡2×10GE业务2×10GE存储有条件上25GECeph网络带宽永远不嫌多带外管理BMC/IPMI故障排查、开机重启必备别省内存上我踩过一个坑一开始按每节点128G配结果虚拟机多开之后Ceph内存吃掉一大块OS又吃掉几个G业务虚拟机内存不够用开始疯狂swap性能掉了一半。后来加到256G才消停。Ceph OSD通常建议至少预留4~8G内存/OSD各位在算内存预算时把这部分算进去。3. 从零搭建PVECeph集群的核心步骤3.1 安装前的BIOS与系统设置这一步看着基础实际影响很大。首先进BIOS确认CPU的虚拟化功能开了Intel开VT-xAMD开AMD-V。如果要用到PCIe直通还得开VT-dAMD是IOMMU。另外把电源管理设为Performance模式Ceph对时钟和延迟敏感省电模式偶尔会导致OSD心跳抖动。系统盘我建议用硬件RAID卡做RAID1或者直接用主板板载的RAID1。但注意OSD数据盘绝不能用RAID卡做阵列必须用直通模式JBOD或者把RAID卡刷成IT模式。因为Ceph自己在每个磁盘上做副本不需要底层RAID的冗余RAID卡反而会缓存写入、Ceph感知不到真实落盘状态。如果用的是HBA卡确保固件支持直通能够把每个物理盘独立透传给系统。这一点做好了后面Ceph识别盘、重新加盘都会非常顺。3.2 PVE安装与集群初始化流程安装PVE本身不复杂官网ISO写入U盘装完系统后第一件事是换更新源。企业订阅源没License会报错换成社区源sed -i s|^deb https://enterprise.proxmox.com/debian/pve|#|g /etc/apt/sources.list.d/pve-enterprise.list echo deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription /etc/apt/sources.list.d/pve-no-subscription.list然后把三台节点的主机名和IP写到 /etc/hosts注意PVE集群不允许主机名变来变去更不允许hostname解析成127.0.1.110.0.0.11 pve1 10.0.0.12 pve2 10.0.0.13 pve3第一台节点执行pvecm create procluster后面的节点执行pvecm add 10.0.0.11这个阶段有个坑corosync配置里会记录节点IP如果hosts文件没配好节点加集群后可能通信不正常。还有防火墙如果开着必须放通corosync的端口5404/5405/5410。生产环境建议直接用物理交换机端口隔离加ACL别靠节点本机防火墙容易给自己挖坑。3.3 Ceph安装与OSD添加PVE对Ceph的集成做得非常舒服直接在Web界面找“Ceph”菜单就能安装。命令行方式也简单pveceph install pveceph init --network 10.10.20.0/24 --cluster-network 10.10.21.0/24 pveceph createmon pveceph createmgr pveceph createosd /dev/sdb pveceph createosd /dev/sdc pveceph createosd /dev/sdd pveceph createosd /dev/sde上面是我各节点的OSD添加命令。这里必须强调“网络参数”的作用public network是客户端访问Ceph用的cluster network是OSD之间复制数据的私网两个网络千万要分开配。Ceph官网和各路实战贴都会反复强调这个确实有道理。cluster network不通数据复制会把业务网络挤垮。第一次我图测试方便把两个网络指到同一个千兆口上结果虚拟机跑fio时整个集群IO延迟飙到几百毫秒Storage网络上的广播风暴甚至导致SSH都连不上。后来把网络拆开同样压力下延迟降到10ms以内。这是整个实施过程中最大的一个性能教训。创建完OSD后到Web界面的“Ceph → Pools”里创建存储池。如果PVE要直接把Ceph作为虚拟机存储还需要创建RBD存储pvesm add rbd ceph-vms --pool vmpool --content images --name admin创建完后创建虚拟机时存储选“ceph-vms”虚拟机磁盘就直接落在Ceph分布式存储上了这就完成了超融合最关键的一步虚拟机跑在节点上数据却均匀分布在所有节点的所有OSD中。3.4 初始虚拟机创建与验证新建虚拟机选择Ceph存储后PVE会自动生成RBD卷。创建完虚拟机我习惯先在每台节点上各创建一台测试虚拟机分别跑一下 gcc 编译、fio 和 iperf确认三台节点的计算、存储、网络都正常。然后再上真实业务。这里有个小经验创建虚拟机时建议把“BIOS”设为OVMF (UEFI)“机器类型”设为q35磁盘总线选用VirtIO Block或SCSI网卡直接用VirtIO。这几种组合在PVE下性能最稳Linux和Windows guest都有驱动支持。Windows需要另外装virtio-win驱动准备Windows镜像时别忘了挂载virtio-win ISO。4. Ceph性能调优与慢盘治理的实战笔记4.1 内核与网络参数调整装完Ceph最开始跑fio测顺序写发现性能只能到理论值的六成左右。第一件事就是去看网络缓冲区大小默认的内核socket缓冲区对万兆网络来说太浅了。调整如下cat /etc/sysctl.conf EOF net.core.rmem_max 134217728 net.core.wmem_max 134217728 net.core.rmem_default 67108864 net.core.wmem_default 67108864 net.ipv4.tcp_rmem 4096 87380 134217728 net.ipv4.tcp_wmem 4096 65536 134217728 EOF sysctl -p这个调整涉及到Ceph的OSD与客户端之间的数据传输socket缓冲区太小数据包在网卡和用户态之间的排队就会丢包、重传直接影响吞吐。改完之后再跑fio顺序读从700MB/s提到接近1100MB/s有点立竿见影的味道。4.2 PG均衡与OSD权重管理Ceph安装后数据默认是均匀分布的但新加盘、坏盘替换、PG数量调整后会出现部分OSD使用率偏高的问题。平时用Ceph Dashboard或ceph osd df可以看到每块盘的占用率。如果某个OSD明显高于平均线可以用reweight做临时调整但更常用的方法是让PG自动回填ceph osd reweight-by-utilization 110这个命令会自动把超过平均利用率110%的OSD权重调低把部分PG挪到空闲盘上。不过要注意它只是调整权重不是真正的数据迁移手段重均衡完成后建议用ceph osd reweight-by-utilization把权重归位。跑一段时间后再观察如果PG分布仍然不均衡就要检查是否存在复制因子不一致、Pool绑定OSD群组之类的配置问题。PVE默认创建pool时不会绑OSD group所以一般不会出这种状况。4.3 慢盘slow OSD识别与处理超融合跑久了最怕慢盘——比坏盘还烦。坏盘直接failout集群会重新均衡慢盘则一直在线但读写延迟巨大拖累整个Ceph的性能。识别慢盘很简单ceph daemon /var/run/ceph/ceph-osd.3.asok perf dump | grep -A5 commit或者用监控工具定期盯ceph osd perf如果某个OSD的commit_latency持续大于几百毫秒基本可以断定是慢盘。处理慢盘我一般是这么做的先看是整块盘的问题还是WAL/DB所在SSD的问题。如果数据盘是机械盘而DB/WAL在SSD上那大概率是数据盘本身老化或不稳定。这种情况把OSD标记out让它回填然后拔掉换新盘。如果只是暂态负载高可以先观察下是否业务峰值别急着拔盘。4.4 Bluestore的WAL/DB分离要不要做Ceph默认Bluestore把WAL、DB和OSD数据放在同一块盘上。如果OSD是机械盘这种混布会让日志写入和小IO性能很难看。有条件就给每个OSD配一块独立的NVMe盘作为WALDB或者一组OSD共用一块。我在这套项目里每节点用了一块960G NVMe专门做DB和WAL。具体的做法是在PVE的pveceph createosd时加参数pveceph createosd /dev/sdX -db_dev /dev/nvme0n1 -db_size 50G -wal_dev /dev/nvme0n1 -wal_size 10G这样配置之后随机写性能大概提升了两到三倍到了几乎能摸到物理SSD上限的水平。如果后续扩容新节点建议OSD盘数量不多时直接把整块NVMe作为所有OSD的DB/WAL共享设备省心且效果好。5. 高可用配置与故障演练实录5.1 HA配置别让虚拟机裸奔超融合只做存储冗余不够虚拟机层面的HA才是业务连续性的最后防线。PVE的HA是基于集群资源管理器的配置不复杂。先把虚拟机配置成HA托管ha-manager add vm:100这样当节点宕机时资源会被自动迁移到其他节点重新启动。除了业务虚拟机我还会把一部分基础设施虚拟机如日志收集也纳入HA保证核心服务不掉线。但这里有个关键前提必须要配置好fencing机制。PVE的fencing可以是硬件watchdogIPMI/BMC或者软件watchdog没有fencing分裂场景下节点会互相抢资源导致脑裂。PVE默认有softdog条件允许的话建议在服务器的BMC里开启硬件watchdog这样宕机后重启的时间更短、更可靠。5.2 在线迁移的注意点超融合集群迁移虚拟机有个前提虚拟机必须跑在共享存储上。Ceph RBD天然满足这个条件所以你的虚拟机从创建开始就放在Ceph存储池上的话在线迁移是完全无缝的。在Web界面右键虚拟机点“迁移”就行或者命令行qm migrate 100 pve2 --online在线迁移技术上是基于QEMU的内存迁移对网络质量要求很高。如果你业务网是千兆理论值实际迁移几十G内存的虚拟机时带宽会打满对线上业务会产生明显抖动。所以迁移大内存虚拟机我习惯错开业务低峰期。另外虚拟机里记得装qemu-guest-agent。没装这个agent迁移前挂起文件系统、做备份前快照时机不对就可能导致文件系统不一致。装了之后PVE能拿到虚拟机内部的应用状态做在线备份时也能正确冻结文件系统。5.3 故障演练拔网线、拔盘、宕节点理论上说超融合很强大但没演练过你敢信吗我的做法是逐项演练第一个场景拔掉某个节点的存储网线。观察Ceph是否很快把该节点的OSD标记为downPG进入降级状态业务虚拟机是否出现卡顿。实测下来只要存储网络冗余做得好客户端几乎无感知但如果单独存储网断了业务流量会走其他网络的兜底延迟短时会高一下过几十秒恢复。第二个场景拔掉数据盘。模拟坏盘。正常配置下Ceph会在几分钟内把该OSD标记out然后自动开始数据回填。我在机械盘环境下测回填期间整个存储池读写有一些波动但虚拟机没中断。真正生产跑着你甚至不需要关机换盘Ceph在换盘完成后会自动加回集群重新均衡整个过程对上层无感知。第三个场景直接拔掉一台节点电源。几秒后PVE的HA会检测到节点失联fencing触发然后把这节点上的HA虚拟机在另一台节点拉起。我跑了两台业务虚拟机一台HA托管、一台未托管。结果HA托管的虚拟机大约40秒后恢复正常未托管的那台就只能等原节点上线。所以生产上重要业务务必全部加HA。5.4 备份策略还是得有超融合不是万能保险。Ceph三副本能防机器故障、能防磁盘损坏但防不了逻辑错误误删除、勒索病毒、手滑改配置。所以Ceph之外的备份仍然必不可少。PVE内置的vzdump支持对运行中的虚拟机做在线备份配合Ceph可以做快照级备份vzdump 100 --mode snapshot --storage local-backup --compress zstd我做这套项目时每天凌晨用vzdump把全部虚拟机备份到一台独立的NAS上保留最近7天。NAS不在超融合集群内这样万一整个集群逻辑损坏还能从离线备份恢复。备份文件我每个月抽一台虚拟机做一次 recovery 演练确保备份不是“假备份”。超融合是把双刃剑它让数据集中在同一套软件层管理方便是真方便但一旦这套软件层出逻辑问题影响范围也是全集群级别的。所以备份、监控、演练缺一不可。6. 经验和教训汇总这套PVE Ceph超融合项目跑下来有几点体会特别深。选型和规划阶段不要图省事网络拆分、存储池规划、PG数量计算这些前置工作做好了后面能少踩80%的坑。尤其是网络Ceph集群对存储网络的带宽和延迟要求非常苛刻千兆网络做Ceph不是不能用但你得接受它的性能上限。生产环境直接万兆起不要犹豫。部署过程中最容易被忽视的是BIOS设置和HBA直通模式RAID卡不转IT模式Ceph性能雪崩而且故障时无从下手。还有Ceph集群的mon节点必须是奇数个我这是3个一旦mon不可用整个Ceph就停摆高可用全靠mon。调优层面先把基础网络和内核参数调到位再考虑WAL/DB分离这些进阶操作。顺序反了的话你可能会在错误的基础上做大量无用优化。最后我建议大家做任何超融合项目前先在小机器上用PVEZFS或PVECeph搭一个最小实验环境跑上一个月把迁移、故障、备份这些操作全部过一遍。虽然前期多花了些时间但生产环境稳定运行给你省下的深夜加班时间绝对值得回票价。本文还有配套的精品资源点击获取 开源超融合实战：PVE+Ceph三节点集群搭建与调优
简介一份聚焦ProxmoxVE超融合落地的技术方案文档适合系统运维、虚拟化工程师及正在规划低成本高可用改造的团队参考。文档完整记录某项目从多机柜服务器向3-4台物理机整合的实践先分析成本压力与业务萎缩背景再提出以ProxmoxVE 5.4构建超融合集群的需求与选型思路并逐步展开服务器挑选、U盘安装系统含DHCP卡住问题的排错替代、网络配置、集群及ceph创建、暴力关机验证虚拟机自动漂移等关键操作。同时归纳了降低成本、提高可用性、统一管控、去中心化、在线扩容五大收益结合真实机房环境给出内存升级等评估建议。整套资料仅有1个docx文档容量3.17MB属于高信息密度技术笔记已有269人学习。适用于需要快速掌握ProxmoxVE超融合落地全过程、避免同类踩坑的读者。 很多人一听“超融合”第一反应就是商业一体机一体箱、管理平台、金牌服务价格让人倒吸一口凉气。但如果你手里有三台性能够用的物理服务器又想把计算、存储、网络揉到一个池子里管理ProxmoxVE下文简称PVE加Ceph这套开源组合完全能顶上一套商业超融合方案而且实践下来稳定性并不差。我这边做过一个真实的项目客户机房有三台旧服务器想跑一套生产虚拟化环境包括十几台Web服务、数据库和内部业务系统。预算有限商业超融合平台的授权费直接超标。最后我选了PVE 8 Ceph作为超融合底座把三台机器组成一个统一资源池计算、存储全部软件化跑到现在大半年中间有节点宕机、有磁盘故障业务都没中断过。这篇文章就记录一下我在这个项目里的部分规划、部署和调优过程给准备动手折腾这套方案的朋友一个参考。1. 为什么非要用PVE做超融合——架构选型背后的现实考量1.1 超融合到底“融合”了什么超融合这个概念说白了就是把传统架构里各自独立的服务器、SAN存储、网络交换机揉成一个通过软件定义的资源池。传统架构下计算是计算存储是存储网络交换机还得单独维护超融合则是把三样东西塞进x86服务器的标准硬件里靠软件层把数据冗余、网络转发全部接管。PVE做超融合的核心组合是KVM虚拟化负责计算Ceph负责分布式存储节点之间通过网络同步数据。你看到的管理界面只有一个IP所有虚拟机、存储池、网络配置都能在Web端完成。这意味着你不需要再买昂贵的存储阵列也不需要单独配SAN交换机三台普通服务器插上网线、加上硬盘就能组成一个能自我修复的集群。1.2 和商业超融合方案的对比做这个项目前客户问过我能不能直接上深信服超融合平台毕竟人家界面漂亮、售后省心而且很多地方都在推这套方案。说实话商业超融合的完成度确实高备份、安全组件、一键部署全给你配好。问题在于授权费、硬件绑定、扩容时的溢价算下来往往比硬件本身还贵对预算敏感的中小项目并不友好。PVE走的是另一条路开源免费收费的只是企业版订阅而且只在企业源里限制部分更新社区源完全够用支持在任意兼容x86服务器上搭建不锁硬件。Ceph作为底层分布式存储经历了大规模生产环境验证本身已经非常成熟。如果你是运维经验凑合的团队愿意花时间读文档、做测试PVE这套超融合能省下至少五六位数。1.3 适合什么规模的场景根据我的实践经验三到十台节点的中小规模集群是PVE超融合最舒服的范围。再大也能跑但你得花更多精力在Ceph的监控和优化上运维成本会直线上升。小型开发测试环境、企业办公虚拟化、边缘计算节点、学校或医院的分支机房这类场景用PVE做超融合性价比极高。我之前帮人搭过两节点的PVE集群说实话两节点跑Ceph并不推荐因为osd分布在两台机器上挂掉一台数据就没了。如果只有两台机器建议用ZFS复制方案做数据冗余而不是硬上Ceph。Ceph超融合至少得三台起步这是架构决定的别指望省钱省出个奇迹。2. 规划阶段定生死网络拓扑、存储池与硬件选型2.1 网络规划三网分离这种“老话”还是要听超融合项目最容易忽略的就是网络规划说出来都是泪。Ceph的数据同步是持续产生流量的如果和业务网络挤在同一张网卡同一根线里虚拟机跑高峰时很容易把存储网络挤爆表现就是虚拟机IO延迟忽高忽低、节点CPU莫名飙升。我这个项目里做了三个网络平面管理网络用于PVE Web界面、SSH、corosync心跳千兆足够。业务网络虚拟机对外提供服务走万兆至少双网卡bond。存储网络Ceph内部数据复制和客户端读写这个一定要万兆起步。存储网络我是单独抽出来做VLAN隔离的用了两张独立万兆网卡做Linux bondmode 4即LACP交换机两个口做链路聚合这个冗余级别生产环境必须做到。corosync心跳没走万兆它包量小但对延迟敏感和存储网络分开反而更稳。很多新手图省事把所有流量跑在一个网络上前期数据量小看不出来等到存储写入大了Ceph内部心跳超时、osd被标记down、数据再均衡整个集群就开始抽搐了。所以网络规划这块宁可在交换机上多接两根线也别偷懒。2.2 存储设计副本数、PG数与故障域Ceph存储池设计上我给默认存储池设置了size3三副本。三个节点各存一份副本任意坏一台节点都不丢数据。如果你的集群节点多也可以考虑EC纠删码比如42或82能省一半多的空间但EC对CPU消耗大、重建慢中小项目三副本最省心。PGPlacement Group的数量很多人搞不明白我直接说经验公式总PG数 (OSD数量 × 100) / 副本数比如我有12个OSD、副本数3那总PG数就是400往2的幂次靠就是512。然后按存储池划分如果有两个主要存储池每个池256左右即可。我现在生产上一个池256一个池128跑了大半年PG分布一直均衡。一开始我犯过一个错误PG数拍脑袋设了32导致单个PG里面数据量巨大有个OSD挂了之后数据重均衡慢得让人怀疑人生整个集群IO卡了好一阵。后来把PG数按公式调整后重均衡时间缩短了三分之二。PG太少单点占用过高PG太多集群元数据开销又太大。这个度就在公式附近。2.3 硬件选型清单与建议这套项目里用的硬件如下组件建议配置实践说明CPU双路Xeon Silver级别虚拟化VCPU超分按1:3以内太多会导致CPU steal明显内存256GB起Ceph本身吃内存WAL/Buffer都靠它虚拟机再吃一大份系统盘2块SSD做RAID1装PVE系统和日志Ceph的OSD数据不要放这里OSD盘每节点至少4块数据盘推荐SSD或NVMe机械盘做OSD生产会很痛苦OSD加速盘可选的NVMe/SSD用于Bluestore的WALDB分离能显著提升小IO性能网卡2×10GE业务2×10GE存储有条件上25GECeph网络带宽永远不嫌多带外管理BMC/IPMI故障排查、开机重启必备别省内存上我踩过一个坑一开始按每节点128G配结果虚拟机多开之后Ceph内存吃掉一大块OS又吃掉几个G业务虚拟机内存不够用开始疯狂swap性能掉了一半。后来加到256G才消停。Ceph OSD通常建议至少预留4~8G内存/OSD各位在算内存预算时把这部分算进去。3. 从零搭建PVECeph集群的核心步骤3.1 安装前的BIOS与系统设置这一步看着基础实际影响很大。首先进BIOS确认CPU的虚拟化功能开了Intel开VT-xAMD开AMD-V。如果要用到PCIe直通还得开VT-dAMD是IOMMU。另外把电源管理设为Performance模式Ceph对时钟和延迟敏感省电模式偶尔会导致OSD心跳抖动。系统盘我建议用硬件RAID卡做RAID1或者直接用主板板载的RAID1。但注意OSD数据盘绝不能用RAID卡做阵列必须用直通模式JBOD或者把RAID卡刷成IT模式。因为Ceph自己在每个磁盘上做副本不需要底层RAID的冗余RAID卡反而会缓存写入、Ceph感知不到真实落盘状态。如果用的是HBA卡确保固件支持直通能够把每个物理盘独立透传给系统。这一点做好了后面Ceph识别盘、重新加盘都会非常顺。3.2 PVE安装与集群初始化流程安装PVE本身不复杂官网ISO写入U盘装完系统后第一件事是换更新源。企业订阅源没License会报错换成社区源sed -i s|^deb https://enterprise.proxmox.com/debian/pve|#|g /etc/apt/sources.list.d/pve-enterprise.list echo deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription /etc/apt/sources.list.d/pve-no-subscription.list然后把三台节点的主机名和IP写到 /etc/hosts注意PVE集群不允许主机名变来变去更不允许hostname解析成127.0.1.110.0.0.11 pve1 10.0.0.12 pve2 10.0.0.13 pve3第一台节点执行pvecm create procluster后面的节点执行pvecm add 10.0.0.11这个阶段有个坑corosync配置里会记录节点IP如果hosts文件没配好节点加集群后可能通信不正常。还有防火墙如果开着必须放通corosync的端口5404/5405/5410。生产环境建议直接用物理交换机端口隔离加ACL别靠节点本机防火墙容易给自己挖坑。3.3 Ceph安装与OSD添加PVE对Ceph的集成做得非常舒服直接在Web界面找“Ceph”菜单就能安装。命令行方式也简单pveceph install pveceph init --network 10.10.20.0/24 --cluster-network 10.10.21.0/24 pveceph createmon pveceph createmgr pveceph createosd /dev/sdb pveceph createosd /dev/sdc pveceph createosd /dev/sdd pveceph createosd /dev/sde上面是我各节点的OSD添加命令。这里必须强调“网络参数”的作用public network是客户端访问Ceph用的cluster network是OSD之间复制数据的私网两个网络千万要分开配。Ceph官网和各路实战贴都会反复强调这个确实有道理。cluster network不通数据复制会把业务网络挤垮。第一次我图测试方便把两个网络指到同一个千兆口上结果虚拟机跑fio时整个集群IO延迟飙到几百毫秒Storage网络上的广播风暴甚至导致SSH都连不上。后来把网络拆开同样压力下延迟降到10ms以内。这是整个实施过程中最大的一个性能教训。创建完OSD后到Web界面的“Ceph → Pools”里创建存储池。如果PVE要直接把Ceph作为虚拟机存储还需要创建RBD存储pvesm add rbd ceph-vms --pool vmpool --content images --name admin创建完后创建虚拟机时存储选“ceph-vms”虚拟机磁盘就直接落在Ceph分布式存储上了这就完成了超融合最关键的一步虚拟机跑在节点上数据却均匀分布在所有节点的所有OSD中。3.4 初始虚拟机创建与验证新建虚拟机选择Ceph存储后PVE会自动生成RBD卷。创建完虚拟机我习惯先在每台节点上各创建一台测试虚拟机分别跑一下 gcc 编译、fio 和 iperf确认三台节点的计算、存储、网络都正常。然后再上真实业务。这里有个小经验创建虚拟机时建议把“BIOS”设为OVMF (UEFI)“机器类型”设为q35磁盘总线选用VirtIO Block或SCSI网卡直接用VirtIO。这几种组合在PVE下性能最稳Linux和Windows guest都有驱动支持。Windows需要另外装virtio-win驱动准备Windows镜像时别忘了挂载virtio-win ISO。4. Ceph性能调优与慢盘治理的实战笔记4.1 内核与网络参数调整装完Ceph最开始跑fio测顺序写发现性能只能到理论值的六成左右。第一件事就是去看网络缓冲区大小默认的内核socket缓冲区对万兆网络来说太浅了。调整如下cat /etc/sysctl.conf EOF net.core.rmem_max 134217728 net.core.wmem_max 134217728 net.core.rmem_default 67108864 net.core.wmem_default 67108864 net.ipv4.tcp_rmem 4096 87380 134217728 net.ipv4.tcp_wmem 4096 65536 134217728 EOF sysctl -p这个调整涉及到Ceph的OSD与客户端之间的数据传输socket缓冲区太小数据包在网卡和用户态之间的排队就会丢包、重传直接影响吞吐。改完之后再跑fio顺序读从700MB/s提到接近1100MB/s有点立竿见影的味道。4.2 PG均衡与OSD权重管理Ceph安装后数据默认是均匀分布的但新加盘、坏盘替换、PG数量调整后会出现部分OSD使用率偏高的问题。平时用Ceph Dashboard或ceph osd df可以看到每块盘的占用率。如果某个OSD明显高于平均线可以用reweight做临时调整但更常用的方法是让PG自动回填ceph osd reweight-by-utilization 110这个命令会自动把超过平均利用率110%的OSD权重调低把部分PG挪到空闲盘上。不过要注意它只是调整权重不是真正的数据迁移手段重均衡完成后建议用ceph osd reweight-by-utilization把权重归位。跑一段时间后再观察如果PG分布仍然不均衡就要检查是否存在复制因子不一致、Pool绑定OSD群组之类的配置问题。PVE默认创建pool时不会绑OSD group所以一般不会出这种状况。4.3 慢盘slow OSD识别与处理超融合跑久了最怕慢盘——比坏盘还烦。坏盘直接failout集群会重新均衡慢盘则一直在线但读写延迟巨大拖累整个Ceph的性能。识别慢盘很简单ceph daemon /var/run/ceph/ceph-osd.3.asok perf dump | grep -A5 commit或者用监控工具定期盯ceph osd perf如果某个OSD的commit_latency持续大于几百毫秒基本可以断定是慢盘。处理慢盘我一般是这么做的先看是整块盘的问题还是WAL/DB所在SSD的问题。如果数据盘是机械盘而DB/WAL在SSD上那大概率是数据盘本身老化或不稳定。这种情况把OSD标记out让它回填然后拔掉换新盘。如果只是暂态负载高可以先观察下是否业务峰值别急着拔盘。4.4 Bluestore的WAL/DB分离要不要做Ceph默认Bluestore把WAL、DB和OSD数据放在同一块盘上。如果OSD是机械盘这种混布会让日志写入和小IO性能很难看。有条件就给每个OSD配一块独立的NVMe盘作为WALDB或者一组OSD共用一块。我在这套项目里每节点用了一块960G NVMe专门做DB和WAL。具体的做法是在PVE的pveceph createosd时加参数pveceph createosd /dev/sdX -db_dev /dev/nvme0n1 -db_size 50G -wal_dev /dev/nvme0n1 -wal_size 10G这样配置之后随机写性能大概提升了两到三倍到了几乎能摸到物理SSD上限的水平。如果后续扩容新节点建议OSD盘数量不多时直接把整块NVMe作为所有OSD的DB/WAL共享设备省心且效果好。5. 高可用配置与故障演练实录5.1 HA配置别让虚拟机裸奔超融合只做存储冗余不够虚拟机层面的HA才是业务连续性的最后防线。PVE的HA是基于集群资源管理器的配置不复杂。先把虚拟机配置成HA托管ha-manager add vm:100这样当节点宕机时资源会被自动迁移到其他节点重新启动。除了业务虚拟机我还会把一部分基础设施虚拟机如日志收集也纳入HA保证核心服务不掉线。但这里有个关键前提必须要配置好fencing机制。PVE的fencing可以是硬件watchdogIPMI/BMC或者软件watchdog没有fencing分裂场景下节点会互相抢资源导致脑裂。PVE默认有softdog条件允许的话建议在服务器的BMC里开启硬件watchdog这样宕机后重启的时间更短、更可靠。5.2 在线迁移的注意点超融合集群迁移虚拟机有个前提虚拟机必须跑在共享存储上。Ceph RBD天然满足这个条件所以你的虚拟机从创建开始就放在Ceph存储池上的话在线迁移是完全无缝的。在Web界面右键虚拟机点“迁移”就行或者命令行qm migrate 100 pve2 --online在线迁移技术上是基于QEMU的内存迁移对网络质量要求很高。如果你业务网是千兆理论值实际迁移几十G内存的虚拟机时带宽会打满对线上业务会产生明显抖动。所以迁移大内存虚拟机我习惯错开业务低峰期。另外虚拟机里记得装qemu-guest-agent。没装这个agent迁移前挂起文件系统、做备份前快照时机不对就可能导致文件系统不一致。装了之后PVE能拿到虚拟机内部的应用状态做在线备份时也能正确冻结文件系统。5.3 故障演练拔网线、拔盘、宕节点理论上说超融合很强大但没演练过你敢信吗我的做法是逐项演练第一个场景拔掉某个节点的存储网线。观察Ceph是否很快把该节点的OSD标记为downPG进入降级状态业务虚拟机是否出现卡顿。实测下来只要存储网络冗余做得好客户端几乎无感知但如果单独存储网断了业务流量会走其他网络的兜底延迟短时会高一下过几十秒恢复。第二个场景拔掉数据盘。模拟坏盘。正常配置下Ceph会在几分钟内把该OSD标记out然后自动开始数据回填。我在机械盘环境下测回填期间整个存储池读写有一些波动但虚拟机没中断。真正生产跑着你甚至不需要关机换盘Ceph在换盘完成后会自动加回集群重新均衡整个过程对上层无感知。第三个场景直接拔掉一台节点电源。几秒后PVE的HA会检测到节点失联fencing触发然后把这节点上的HA虚拟机在另一台节点拉起。我跑了两台业务虚拟机一台HA托管、一台未托管。结果HA托管的虚拟机大约40秒后恢复正常未托管的那台就只能等原节点上线。所以生产上重要业务务必全部加HA。5.4 备份策略还是得有超融合不是万能保险。Ceph三副本能防机器故障、能防磁盘损坏但防不了逻辑错误误删除、勒索病毒、手滑改配置。所以Ceph之外的备份仍然必不可少。PVE内置的vzdump支持对运行中的虚拟机做在线备份配合Ceph可以做快照级备份vzdump 100 --mode snapshot --storage local-backup --compress zstd我做这套项目时每天凌晨用vzdump把全部虚拟机备份到一台独立的NAS上保留最近7天。NAS不在超融合集群内这样万一整个集群逻辑损坏还能从离线备份恢复。备份文件我每个月抽一台虚拟机做一次 recovery 演练确保备份不是“假备份”。超融合是把双刃剑它让数据集中在同一套软件层管理方便是真方便但一旦这套软件层出逻辑问题影响范围也是全集群级别的。所以备份、监控、演练缺一不可。6. 经验和教训汇总这套PVE Ceph超融合项目跑下来有几点体会特别深。选型和规划阶段不要图省事网络拆分、存储池规划、PG数量计算这些前置工作做好了后面能少踩80%的坑。尤其是网络Ceph集群对存储网络的带宽和延迟要求非常苛刻千兆网络做Ceph不是不能用但你得接受它的性能上限。生产环境直接万兆起不要犹豫。部署过程中最容易被忽视的是BIOS设置和HBA直通模式RAID卡不转IT模式Ceph性能雪崩而且故障时无从下手。还有Ceph集群的mon节点必须是奇数个我这是3个一旦mon不可用整个Ceph就停摆高可用全靠mon。调优层面先把基础网络和内核参数调到位再考虑WAL/DB分离这些进阶操作。顺序反了的话你可能会在错误的基础上做大量无用优化。最后我建议大家做任何超融合项目前先在小机器上用PVEZFS或PVECeph搭一个最小实验环境跑上一个月把迁移、故障、备份这些操作全部过一遍。虽然前期多花了些时间但生产环境稳定运行给你省下的深夜加班时间绝对值得回票价。本文还有配套的精品资源点击获取