三台物理机搭建Proxmox+Ceph高可用虚拟化集群实践指南

简介一份针对三台物理机的VMware服务器虚拟化完整解决方案面向需要改造老旧IT基础设施、整合服务器资源并实现业务平滑迁移的系统运维与规划人员。文档以某公司8台物理服务器超低资源利用率的真实环境为背景详细拆解了从现状评估、虚拟化集群架构设计、双链路共享存储接入到利用迁移工具将现有业务系统平滑迁入虚拟化平台的过程并给出硬件与软件配置清单、许可管理思路、单节点高可用保障及后续1-3年横向、纵向扩展路径。资源包内仅1个docx文件体积约87KB便于离线查阅与二次编辑。文档目前已有88人学习。文档既说明了虚拟机对CPU、内存、存储的分配策略也列出了降低能耗、节省机房空间、简化运维等收益适合直接参考或改写成企业服务器虚拟化改造方案。1. 三台物理机做虚拟化先想清楚这三点再动手手头有三台物理机想做成虚拟化平台这大概是很多运维和实验环境都会遇到的需求。别看只有三台机器把它当单机装个Hypervisor跑几个虚拟机是浪费真正把它做成服务器虚拟化解决方案要解决的是三件事虚拟机怎么在物理机之间迁移、物理机挂了虚拟机怎么自动恢复、以及共享存储从哪来。我见过太多人装完系统就宣告完成结果一拔网线、一拔电源整个平台跟着瘫掉。这个方案适合两类人一类是机房里有三五台旧服务器想整合资源的中小团队另一类是准备搞OpenStack或K8s底层虚拟化想先用三台物理机搭一套最小高可用集群的研发。本文按最常见也最可靠的做法展开以Proxmox VE作为虚拟化平台配合Ceph分布式存储用三台物理机构建一套能扛单节点故障的集群。下面从选型、网络、存储、实施到避坑一步步讲清楚。2. 三台物理机虚拟化的选型从Hypervisor、共享存储到高可用2.1 选型理由为什么优先考虑KVM/Proxmox而非vSphere三台物理机做虚拟化市面上能选的方案大致分三类VMware vSphereESXi、基于KVM的Proxmox VE、以及纯命令行KVMlibvirt。vSphere确实是企业级标杆但问题在于vSphere的共享存储和高可用需要额外组件vCenter要单独装共享存储要么买商业SAN/NAS要么用vSAN而vSAN至少需要四台主机才合规。三台机器上vSAN不是不能跑但兼容性和授权都是坑对预算敏感的中小团队不值当。我一般首选Proxmox VE理由是它把所有痛点一次性解决了它本身基于Debian和KVMLinux内核虚拟化成熟稳定高可用HA和在线迁移是内置功能不需要额外装管理服务器自带Ceph存储集成三台机器就能组一个分布式块存储实现真正的共享存储Web管理界面在同类开源方案里算好用API也齐全后续想自动化省事。如果你执意用纯KVMlibvirt当然也可以但你就得自己写集群管理、存储复制、故障切换那一大套东西。三台机器的场景把精力放在业务虚拟机上别重复造轮子。这不是偷懒是务实。2.2 网络规划管理网、业务网、存储网怎么分开很多虚拟化方案翻车不是CPU不够而是网络从根上就画错了。三台物理机每台至少要规划三张逻辑网络管理网访问Proxmox Web界面和SSH用的IP网段独立建议用千兆或更高带宽但流量不大业务网虚拟机对外提供服务的网络通常直接桥接到物理交换机让虚拟机和物理机在同一个二层里互通存储网跑Ceph复制流量和数据流量这个网络最容易被忽略但它直接决定集群性能。有人图省事把管理网和业务网共用一张物理网卡结果内网广播风暴一起管理界面卡到怀疑人生。还有人把Ceph存储流量也丢在业务网里三台机器之间的OSD复制数据把交换机端口塞满业务时延直接飙升。我的划分建议是至少两张物理网卡起步一张做管理业务用VLAN隔离也行物理机没有VLAN功能就用不同的IP子网加防火墙规则另一张专跑存储。有条件的话存储网用万兆网卡配万兆交换机没有万兆就做链路聚合。注意不要让Ceph的public网络和cluster网络混在一起这两种流量要分开不然某台物理机网卡故障时集群心跳和数据同步争抢带宽整个集群会陷入不可用。2.3 存储方案三台机器怎么共享存储Ceph vs 分布式块设备三台物理机组集群最关键的存储选型。传统做法是搞一个NAS或者SAN用NFS/iSCSI共享出去然后虚拟机磁盘放在共享存储上。但是对于三台独立物理机再配一台存储服务器就把三台变成四台了硬件成本和维护复杂度都上去了。更贴合标题的做法是直接用三台物理机自身的磁盘组成分布式存储。常见选项是Ceph和GlusterFS。在这个场景下我选Ceph原因有三Ceph的RBD块设备天然支持QEMU/KVMProxmox做了深度集成创建虚拟机时可以直接选Ceph存储作为磁盘位置Ceph副本数设为2或3时数据会分散在三台物理机上任何一台物理机宕机数据副本仍然完整Ceph的故障域能感知物理机级别不像某些分布式存储只能感知磁盘级别。这里要强调一个参数Ceph的size副本数和min_size最小可用副本数。三节点集群我通常设置size3min_size2。意思是每份数据存三份但只要有任意两台机器活着就能正常读写。如果设成size2、min_size1虽然省了一半空间但一旦一台机器宕机剩下的单副本随时可能因为磁盘坏道而丢数据没有冗余可言。三台物理机本来就是奔着高可用去的副本数这块别抠。另外如果机器上有SSD和HDD可以考虑Ceph的混合存储配置把OSD的journal或DB放在SSD上数据盘用HDD性能能高不少。不过这个配置细节多新手还是规规矩矩用统一类型磁盘等跑熟了再优化。2.4 高可用与迁移HA和在线迁移的前提高可用是三台物理机虚拟化解决方案的核心价值。Proxmox的HA原理不复杂一个虚拟机被标记为HA受管后集群会监控它所在物理机的健康状态。如果物理机宕机等一个重启超时时间后虚拟机会在另一台物理机上自动启动。这个过程依赖两方面Corosync集群心跳三台物理机之间必须能实时通信心跳网络不稳定会直接触发误切换共享存储虚拟机磁盘必须放在Ceph/NFS这种所有节点都能访问的存储上如果虚拟机磁盘留在本机物理机挂了迁移和HA都是空话。在线迁移Live Migration的前提同样是共享存储。迁移期间虚拟机内存状态通过TCP传输到目标节点磁盘因为是共享的不需要拷贝。你可以在虚拟机运行的情况下把它从物理机A迁到物理机B业务中断时间通常在秒级甚至亚秒级这是很实用的能力。这里有一个常见误解有人把本地磁盘上的虚拟机加入HA以为有保护其实Proxmox会拒绝或警告。HA要求虚拟机存储必须是集群共享存储所以再次强调存储规划是三台物理机虚拟化的地基。3. 用Proxmox VE在三台物理机上搭集群安装与初始化3.1 安装前检查CPU虚拟化、固件、磁盘布局正式开始前别急着装系统先花十分钟确认物理机状态。以下是我装机前必做的检查每台机器都执行# 检查CPU是否支持硬件虚拟化 grep -E (vmx|svm) /proc/cpuinfo # 检查内核是否加载KVM模块 ls /dev/kvm # 查看内存和磁盘信息 free -h lsblk输出里有vmxIntel或svmAMD说明CPU虚拟化指令集可用/dev/kvm存在说明KVM能正常工作。如果没有要么CPU太老要么BIOS里没开虚拟化。另外注意如果你是在一个虚拟机里再装Proxmox做嵌套虚拟化同样会报此平台不支持虚拟化的AMD-V/RVI之类的问题这种环境只能用来测试功能别拿来跑生产。磁盘布局上建议系统盘和数据盘分开。比如有两块硬盘一块装系统和Proxmox另一块留给Ceph OSD。如果只有一块盘也可以分区装但一旦系统盘崩溃Ceph数据和系统一起丢恢复成本很高。三台物理机尽量保持硬件配置一致尤其是CPU型号、内存大小、磁盘数量和容量不一致的配置会导致Ceph数据分布不均迁移时也会出现CPU兼容性问题。3.2 三节点集群初始化命令与配置三台机器分别装好Proxmox VE后下面把它们组成集群。以节点名pve1、pve2、pve3为例IP分别为192.168.1.11、192.168.1.12、192.168.1.13。在第一个节点上执行创建集群# 在pve1上创建集群集群名为pve-cluster pvecm create pve-cluster然后在第二个和第三个节点上加入集群。加入集群前需要先获取第一个节点的验证指纹虽然pvecm add会自动提示但最好提前确认网络互通# 在pve2上执行加入集群提示输入pve1的root密码 pvecm add 192.168.1.11 # 在pve3上执行加入集群 pvecm add 192.168.1.11加入完成后查看集群状态pvecm status预期输出里应该有三个节点都在线且Quorate状态为Yes。如果某个节点加入失败先检查防火墙是否放行集群端口。Proxmox安装时默认会有iptables规则如果自定义过防火墙需要放行Corosync使用的端口通常是5404/5405 UDP以及SSH端口。另外确保所有节点的/etc/hosts里都写清楚各节点的IP和主机名不要只靠DNS解析因为Corosync对主机名解析很敏感。这里说一个常见坑三台机器如果原本在同一个局域网它们可能会用机器网卡上的IPv6地址做通信导致集群状态能起来但很不稳定。建议在/etc/hosts里强制绑定IPV4地址或在安装时让网络配置只用IPv4。3.3 创建Ceph存储池的步骤与参数集群建好之后接下来给Ceph做准备。Proxmox有个很省心的功能可以直接在Web界面上安装Ceph但命令行方式更可控也方便排查。首先把三台物理机的空数据盘交给Ceph做OSD# 在每台物理机上把/dev/sdb初始化为Ceph OSD pveceph init --network 192.168.1.0/24 pveceph createmon pveceph createosd /dev/sdb参数说明pveceph init初始化Ceph配置--network指定Ceph的public网络网段如果你的存储网是单独的192.168.2.0/24应该在init时用--cluster-network指定存储网段。createmon会在本机创建一个Monitor节点三台机器都执行后就有三个Monitor够用了。createosd把整块磁盘做成OSD注意Proxmox默认会直接使用整块盘不要指定分区除非你知道自己在干什么。OSD创建完成后创建一个虚拟机磁盘用的存储池# 创建名为vm-storage的RBD池PG数量设为128两个副本 ceph osd pool create vm-storage 128 128 rbd pool init vm-storagePG数量的计算有个粗略公式对于三台物理机、每台少量OSD的场景128或256就够。PG太多会导致OSD间通信开销大太少则数据分布不均匀。如果以后磁盘数量增加再调PG数比较麻烦所以一开始就预留到256也行。副本默认是三副本如果你的数据量不大、且接受两副本可以在存储池创建后修改# 把副本数改为2min_size改为1不推荐或者保持3副本min_size保持2 ceph osd pool set vm-storage size 3 ceph osd pool set vm-storage min_size 2修改完要执行ceph osd pool apply vm-storage让配置生效。然后回到Proxmox添加Ceph存储类型为RBD存储ID填vm-storage内容类型勾上磁盘镜像这样创建虚拟机时就能选择这个存储了。3.4 创建虚拟机并配置迁移/HA的要点存储就绪后创建虚拟机有两个关键选择磁盘放哪、是否开机自启。磁盘一定要放到Ceph存储上而不是本地。Proxmox创建虚拟机的命令如下# 创建一台虚拟机ID为100磁盘放在vm-storage分配2核2G内存 qm create 100 --name test-vm --memory 2048 --cores 2 --net0 virtio,bridgevmbr0 --scsihw virtio-scsi-pci --virtio0 vm-storage:32 # 安装系统时启动一个VNC控制台 qm start 100参数说明virtio0 vm-storage:32表示创建一个32GB的虚拟磁盘并放在vm-storage这个Ceph池里bridgevmbr0是Proxmox默认的Linux网桥它会接宿主机物理网卡虚拟机通过它和物理机网络互通。如果虚拟机需要和物理机上其他服务互通在同一个网桥下默认就能互通无需额外设置。HA配置如果不是在创建时执行也可以在虚拟机创建好之后把虚拟机加入HA管理# 给虚拟机100添加HA ha-manager add vm:100这样Proxmox集群会监控这台虚拟机一旦物理机宕机它会在另一台物理机上自动拉起。注意HA资源在节点故障后默认有一个等待时间可以在Web界面的HA设置里调整重启超时我一般设为120秒给故障节点一个恢复的机会。如果是意外的硬件宕机120秒足够触发切换如果是人为重启节点可以手动把虚拟机迁移走了再重启避免HA误判。4. 虚拟化集群的常见问题排查与避坑指南4.1 此平台不支持虚拟化 AMD-V/RVI 报错现象与解决很多人在物理机上装好Proxmox或别的虚拟化平台后启动虚拟机时直接报此平台不支持虚拟化的AMD-V/RVI或者VMX/SVM未开启。这个报错的典型场景有两种一种是CPU太老不支持硬件虚拟化另一种更常见——BIOS里的虚拟化选项被关了。现象启动虚拟机瞬间失败qm status看到虚拟机处于paused或stopped系统日志里出现KVM entry failed。原因BIOS中Intel VT-x/AMD-V未开启或安全启动/可信平台模块TPM设置阻挡了虚拟机管理程序的加载。解决重启物理机进BIOS找到Virtualization TechnologyIntel/SVM ModeAMD设为Enabled。对于较新的机器还需要在BIOS里关闭Trusted Execution或Secure Boot的干扰项某些OEM主板会默认禁用虚拟化。改完后在Linux里确认kvm-ok或ls /dev/kvm是否正常。如果还是不行检查内核是否加载了引起冲突的模块比如kvm_intel没加载可以用modprobe kvm_intel手动加载。注意如果你是在一个已经虚拟化的环境里嵌套跑虚拟机除了开启物理机BIOS的虚拟化还要在宿主虚拟机的CPU设置里选择将主机CPU透传给虚拟机host-passthrough这样嵌套虚拟化才能生效。Proxmox里就是编辑虚拟机CPU类型为host。4.2 嵌套虚拟化模块 hv 启动失败原因与处理这条和热词里vmware hv 嵌套虚拟化很像但不止VMwareKVM嵌套虚拟化也会翻车。现象是虚拟机内部再装一个Hyper-V或KVM时报模块hv启动失败或hypervisor未启用。原因外层虚拟机没有把CPU的虚拟化指令透传给内层虚拟机。比如物理机上的KVM虚拟机默认CPU模式是kvm64或qemu64这种模拟CPU不暴露vmx/svm指令内层虚拟机自然起不来。解决编辑外层虚拟机配置把CPU类型改为host这样内层虚拟机能看到物理CPU的全部特性。Proxmox下修改qm set 100 --cpu host改完之后需要重启虚拟机。如果还不行检查物理机的KVM模块是否允许嵌套# 查看嵌套虚拟化是否开启1为开启 cat /sys/module/kvm_intel/parameters/nested如果是0执行echo options kvm_intel nested1 /etc/modprobe.d/kvm.conf modprobe -r kvm_intel modprobe kvm_intel这个操作只在当前节点生效三台物理机都要做。还有一些特殊场景物理机BIOS里开启了SMEP/SMAP安全特性也可能导致嵌套虚拟化失败这类问题多发生于Intel的某些CPU型号上可以尝试在BIOS中关闭这些特性但不建议为一两次嵌套测试而降低物理机安全性。4.3 虚拟机与物理机怎么互通的网络坑虚拟机和物理机互通听起来简单但经常有人栽在这儿。现象是虚拟机可以上外网但就是ping不通物理机或者反过来。原因最常见的坑是物理机上有多块网卡Proxmox默认把vmbr0桥接在第一个物理网卡上而你的管理IP可能配置在第二块网卡上。虚拟机桥接的是vmbr0和物理机的第一块网卡在同一二层所以能通但物理机管理IP走的是另一块网卡两个网段不通互相看不到。解决如果你希望虚拟机和物理机管理IP互通在创建网桥时就要把物理机的管理网卡桥接进去。Proxmox默认安装时会让用户选择网卡通常会生成vmbr0并桥接管理网卡但后续新增物理网卡时需要手动创建网桥# 将enp2s0这项物理网卡创建为vmbr1 nmcli connection add type bridge ifname vmbr1 ifname enp2s0然后编辑/etc/network/interfaces把桥接配置写明白。这个操作在网络变化后极易出问题所以改之前先保存原配置并且保留一个能直接物理接入的终端万一网络断了还能救回来。另外虚拟机里如果启用了防火墙也会造成互通失败排查时先临时关掉虚拟机内防火墙和Proxmox节点防火墙确认是策略问题还是链路问题。4.4 Ceph OSD性能不均与网络抖动排查三个节点的Ceph集群运行一段时间后可能会出现某些虚拟机磁盘IO慢、集群状态降级degraded的问题。现象ceph -s显示有OSD down或PG状态卡在degraded/recovering且集群网络流量异常。原因三台物理机的磁盘型号和转速不一致某台机器的磁盘故障率高导致该OSD频繁被标记为down或者存储网不稳OSD之间的心跳超时集群误判OSD离线触发数据重分布重分布又压垮了网络形成恶性循环。解决先从硬件层排查执行ceph osd tree看所有OSD状态。若某个OSD反复flapping检查对应物理机的硬盘SMART信息smartctl -a /dev/sdb如果是硬盘老化直接更换然后执行# 把故障OSD踢出集群 ceph osd out osd.3 ceph osd crush remove osd.3再物理更换磁盘后pveceph createosd重新加回。网络抖动问题则要调整OSD的heartbeat参数但不要轻易改先确认交换机端口协商速率、网线是不是有松动。三台物理机的存储网建议用直连或者专门的一台千兆交换机避免和业务网共用一台老旧交换机。若网络确实不稳可以考虑把Ceph mon和OSD的端口通过防火墙限制只允许三台机器互相访问减少广播干扰。5. 性能调优与备份恢复让三台物理机集群更稳5.1 CPU/内存/磁盘IO调优参数三台物理机虚拟化平台稳定运行之后性能调优是下一件值得做的事。不要一上来就追求极致先关注几个对虚拟化影响最大的参数。CPU方面虚拟机CPU类型尽量选host这样虚拟机能直接使用物理机的CPU指令集性能损失最小代价是虚拟机不能迁移到CPU型号不同的物理机上。如果你的三台机器CPU一致直接选host没问题如果混合了Intel和AMD只能选kvm64这类通用型号否则迁移时会报CPU不兼容。这里有个两全方案创建虚拟机时选host同时开启兼容迁移模式-cpu host,kvm_pv_unhalt之类但这需要你对QEMU参数很熟新手不建议碰。内存方面Proxmox默认允许ballooning内存气球它会根据虚拟机负载动态调整内存。但某些高负载应用如数据库、Java服务一旦内存被回收会频繁触发GC和swap性能反而下降。我通常关闭ballooningqm set 100 --balloon 0磁盘IO方面虚拟磁盘的Cache模式默认是none这对Ceph存储来说是正确的因为Ceph自己有缓存机制QEMU再缓存一层反而容易造成数据不一致。但如果你对单个虚拟机的随机读写要求特别高可以在Ceph层面开启rbd cache然后设置较大的rbd cache size。不过这只在客户端缓存如果虚拟机宕机未落盘的数据可能丢失所以只适合跑临时任务。三台物理机的Ceph集群本身以下几个参数对性能影响显著# 增大OSD的recovery并发加快数据恢复但要控制对业务的影响 ceph config set osd osd_max_backfills 4 # 调整PG的恢复线程数 ceph config set osd osd_recovery_max_active 5这些参数不要调得太大否则单台OSD盘容易一直满负荷跑另一台节点故障时恢复时间可能会缩短但业务IO也会被拖慢。建议观察ceph -w的恢复速率再决定是否继续加大。5.2 备份策略与恢复演练三台物理机虚拟化的高可用解决的是硬件故障但解决不了逻辑故障——误删虚拟机、勒索病毒、或者Ceph集群本身配置错误导致的数据损坏。所以备份和恢复演练必须安排上。Proxmox内置了备份功能可以把虚拟机备份到本地或NFS。我建议备份到独立的NFS存储不要备份到同一个Ceph集群里否则集群坏了备份也跟着没。备份时间窗口选择业务低峰例如凌晨2点。备份模式建议选择快照模式snapshot它利用Ceph RBD的快照能力对虚拟机的IO影响很小。备份命令示例# 备份虚拟机100到挂载的NFS目录 vzdump 100 --storage /backup --mode snapshot --compress zstd如果你想把整个集群的虚拟机都定期备份可以写一个脚本用循环遍历虚拟机ID。但不要把所有虚拟机集中在同一时刻备份三台物理机的IO会被同时打满建议错开时间每小时备份1-2台。更重要的是恢复演练。很多人备份完了从来没恢复过一次等真出问题时发现备份文件损坏或者恢复流程不对。我每季度会选一台不重要的虚拟机删除它然后从备份恢复确认能正常启动、数据完整。恢复命令# 从备份文件恢复为新的虚拟机ID 200 qmrestore /backup/dump/vzdump-qemu-100-*.vma.zst 200恢复后启动虚拟机检查最关键的业务数据和网络连通性。做这个演练能暴露两类问题一是备份文件是否可读二是恢复出来的虚拟机磁盘是否正确挂载、网络配置对不对。别嫌麻烦等你真的依赖备份救命的那一天你会感谢这个习惯的。5.3 升级与维护窗口操作三台物理机集群的维护升级最怕的就是把版本升挂了导致整个平台不可用。我踩过一次坑某次直接把Proxmox从老版本升到新版本结果Ceph和QEMU的版本兼容性出问题虚拟机磁盘变成只读差点回不来。从此我整理了一套安全升级流程。升级前首先确认集群里所有虚拟机正常没有正在进行的备份或迁移任务。然后查看当前版本和可用版本pveversion -v apt update apt list --upgradable这里要特别留意Proxmox的仓库类型如果是企业版仓库没有订阅是拉不到更新的需要切换到no-subscription仓库。但这些属于基础操作真正的关键步骤是升级顺序先升级一台物理机升级完成后让它跑一两天观察Ceph集群是否正常、虚拟机是否正常迁移。如果没问题再升级另外两台。不要三台一起升万一新内核和Ceph不兼容三台同时挂掉集群直接停摆。升级过程中会重启物理机重启前务必确认虚拟机已经迁移到其他节点# 把物理机上的所有虚拟机迁移到pve2 qm list | awk NR1 $2!- {print $1} | while read vmid; do pvesh create /nodes/pve1/qemu/$vmid/migrate --target pve2 --online done然后重启该物理机。升级后检查内核版本和Ceph状态uname -r ceph -s如果Ceph报错查看是否出现mon无法连接或OSD版本不匹配的情况。常见做法是升级前做一次整个集群的配置备份用Proxmox的/etc/pve目录整体打包这个目录是集群配置文件包含所有节点、存储、虚拟机配置恢复的时候直接覆盖回/etc/pve即可。6. 最后送你一个验证HA的实用技巧手动制造故障看切换很多集群做完HA配置后看起来一切正常但等到真正断电才暴露问题。与其赌运气不如自己主动制造一次故障来验证。我常用的方法是用ip link set eth0 down或者直接断掉某台物理机的网络看集群会不会把上面的虚拟机切走。操作前先选一台不重要的测试虚拟机确保它启用了HA且磁盘在Ceph存储上。然后SSH登录到虚拟机所在的物理机关停它的网络接口# 在pve1上模拟网络故障注意这会断掉所有网卡 ip link set eno1 down等待30秒到2分钟观察虚拟机的状态变化# 在pve2上查看集群状态和HA资源 pvecm status ha-manager status正常情况下你会在pve2或pve3上看到那台虚拟机被重新启动。这个过程有几个值得检查的细节虚拟机的磁盘是否正常挂载有没有触发文件系统检查如果挂载超时会导致系统启动变慢业务是否有明显中断。男人看了沉默女人看了流泪——很多兜底方案就是在这一刻才发现失效的。验证完成后把物理机网络恢复等集群重新同步。如果一切正常你才算是真正验证了HA的能力。我个人习惯是在每次变更后做一次这样的故障演练费用不高花十分钟换来的安心是值的。实话说三台物理机虚拟化方案本身不复杂但它在生产环境里能不能扛住事靠的不是安装时的一鼓作气而是后来一次次升级、演练、纠错中磨出来的细节。希望这篇文章能帮你绕开我踩过的那些坑把这个方案平稳落地也希望你们的平台和我的一样跑个几年都不需要半夜爬起来救火。愿三台物理机真正成为你脚下稳定的地基而不是新的麻烦。希望帮到你。本文还有配套的精品资源点击获取