企业官网建设流程全解析

简介：一份记录 Proxmox VE 超融合项目完整落地过程的技术方案文档，面向虚拟化运维人员、系统架构师以及有互联网数据中心整合需求的团队。文档从业务量萎缩、成本压力增大的实际背景出发，讲述如何挑选几台大容量服务器，构建超融合集群并将存量业务迁移到集群之上，以同时实现降低成本、提升可用性、统一管控、去中心化、在线扩容等目标。实施部分详细记录了真实的机房部署经历：从制作 Proxmox VE 5.4 安装启动盘、排查动态主机配置协议（DHCP）问题，到创建去中心化的 Ceph 分布式存储、验证强制关机后虚拟机自动漂移等关键环节，并给出了可复现的经验与排错思路。整套内容以一个 docx 文档交付，文件大小约 3.17MB。目前已有 269 人学习下载，适合具备一定虚拟化基础、正在评估超融合方案或准备开展相关项目的读者直接参考。 最近把手里那套 Proxmox VE 超融合集群从测试环境一路折腾到了生产业务承载，整个过程走了不少弯路，也把 Ceph、HA、备份、网络规划这些关键环节挨个摸了一遍。Proxmox VE（后面统一叫 PVE）这套东西，说到底就是用开源方案把计算、存储、网络揉到一个集群里，用软件定义的方式干掉传统架构里“服务器是一台一台的、存储是一台专门的机器”这种割裂状态。如果你也在考虑用 PVE 做超融合，或者已经装好了 PVE 但不知道怎么设计存储和网络，这篇实践记录应该能帮你省掉不少试错时间。

1. 项目背景与方案选型思路

1.1 为什么在自己的机房折腾超融合

先说需求来源。我们这边机房里有十几台老旧的物理服务器，每台上面跑着不同时期的业务，有的是 Windows 虚拟机，有的是 Linux 容器，还有两台物理机直接承载数据库。时间一长问题就暴露了：单台服务器故障就要停机维护，资源利用率低得可怜，有的机器 CPU 长期 5% 以下，有的磁盘却快满了，想迁移业务还得考虑兼容性，完全动弹不得。

超融合解决的就是这个核心矛盾：把多台通用 x86 服务器的计算和存储资源通过软件统一池化，上层通过虚拟化平台动态分配资源，下层通过分布式存储保证数据冗余和自动重建。用大白话说，以前存储是存储、计算是计算，超融合让一台台普通服务器既提供 CPU 内存，又贡献磁盘容量，故障了数据自动在其他节点恢复，业务继续跑，不需要专门搬数据。

选择 PVE 超融合的另一个关键原因，是它把虚拟化和分布式存储的管理整合在同一个 Web 界面里，业内叫超融合基础设施，本质上是把 Ceph 这个软件定义存储和 KVM/LXC 虚拟化做了深度集成。你不需要单独去学一套商业超融合的复杂管理平台，也不需要额外购买商业授权，一套开源方案就能把虚拟化和存储统一纳管，这对预算有限但又想获得企业级能力的团队来说非常友好。

1.2 为什么选 Proxmox VE 而不是其他方案

市面上做超融合的路径不少，商业方案有深信服超融合平台、VMware vSAN、Nutanix 这类，开源方案里 PVE、oVirt、OpenStack 也各有拥趸。我之前也专门对比过，简单说说选型逻辑。

商业超融合平台的优势是开箱即用和厂商兜底，但劣势也很明显：授权费用高，硬件兼容性锁定，想扩容节点还得看厂商脸色。我们的场景是机房自管、业务不太复杂、希望保留硬件选型自由度，商业方案显然不太合适。OpenStack 功能全但部署运维成本极高，我们这种小团队根本养不起。oVirt 在虚拟化层面不错，但存储这块还是习惯依赖外部存储或者 GlusterFS，超融合的“融合”程度不如 PVE+Ceph 来得纯粹。

PVE 最打动我的几个点：第一，基于 Debian 系统，底层稳，社区活跃，遇到问题几乎都能搜到解决方案；第二，虚拟化内核 KVM 的性能表现和成熟度经过大规模验证，生产环境完全可信；第三，Ceph 集成深度好，图形界面直接管理 OSD、存储池、PG，不需要像裸 Ceph 那样全命令行操作；第四，许可证是 GNU AGPL，开源免费，只需要为商业订阅付费，但你不订阅也完全不影响使用。综合下来，PVE 成了性价比和功能之间的最优解。

2. 整体架构设计与硬件规划

2.1 超融合架构的核心逻辑

超融合最核心的设计理念就是把“计算”和“存储”从物理设备中解耦，再通过软件重新聚合。想象一下，传统架构里存储是一口大锅，所有服务器都从锅里舀水，锅坏了全员没水喝；而超融合架构里，每台服务器既是厨房又是储水罐，多个储水罐之间通过管道实时互相备份，任何一个罐子破了，其他罐子自动把水补上。

落到 PVE 这个项目里，架构分三层。最底层是硬件节点，负责提供 CPU、内存、磁盘和网卡资源；中间层是虚拟化层，PVE 跑在 Debian 系统上，通过 QEMU/KVM 提供虚拟机运行环境，通过 LXC 提供轻量级容器；最上层是存储层，Ceph 作为分布式存储横跨所有节点，把每台节点上的磁盘汇聚成统一的存储池，再通过 RBD 协议提供给虚拟机作为块设备。这样虚拟机数据可以根据策略分布在多个节点上，单节点宕机不影响数据可用性。

这里要特别强调一下 PVE 集群和 Ceph 集群的关系。PVE 集群负责虚拟机的调度和高可用判断，Ceph 集群负责数据分布和冗余，两者独立运作又相互协作。你把一台 PVE 节点的 corosync 集群服务停了，虚拟机可能因为群集配额丢失而被标记为不可用，但 Ceph 数据还在其他节点上，只要恢复集群通信，业务马上回来。理解这个分离的逻辑，排障时就不会手忙脚乱。

2.2 网络规划是超融合的第一生命线

如果让我排一个超融合项目的关键度优先级，网络绝对排第一，超过 CPU 和内存。原因很简单：超融合的每一次 I/O 写入都涉及网络传输，虚拟机的每次迁移也依赖网络，Ceph 副本的实时同步更是完全靠网络支撑。网络规划不好，后面所有性能调优都是白搭。

我在这个项目里规划了三套独立的物理网络。管理网络用于访问 PVE Web 界面和 SSH，跑普通千兆就够；Ceph public 网络承载虚拟机存储 I/O，建议至少万兆起步；Ceph cluster 网络用于副本同步和 OSD 心跳，同样万兆。如果条件允许，cluster 网络最好再独立物理隔离，因为 OSD 之间的数据同步量非常大，一旦和业务网络混跑，互相争抢带宽会让存储延迟直接飙升。

实际部署时我用了每个节点双万兆网口加双千兆网口，万兆口分别接两个不同的交换机做冗余，千兆口各接一台管理交换机。VLAN 划分上，Ceph public 和 cluster 分在不同 VLAN，配合交换机的链路聚合配置，相当于给存储流量修了一条双向八车道。这样做的好处是，某台交换机故障或者某根网线松动，流量自动切换，业务几乎无感知。

2.3 存储层：Ceph 还是 ZFS

PVE 官方支持的存储方案里，ZFS 和 Ceph 是两条主力路线。ZFS 是本地文件系统加软 RAID 的思路，单机性能强、配置简单，适合两三个节点的小规模场景；Ceph 是分布式存储的思路，数据跨节点冗余，适合真正需要横向扩展和多节点高可用的场景。

我这个项目一共凑了三台服务器，每台配置两颗 E5-2680 v4 CPU、256GB 内存、两块 480GB SSD 做系统盘和虚拟机热数据缓存、四块 8TB 企业级 HDD 做 Ceph OSD。这个规模不上不下，用 ZFS 的话数据只能在本机冗余，节点挂了虚拟机恢复要手动处理；用 Ceph 的话三节点可以容忍任意一台宕机，业务自动切换到其他节点。我最终选了 Ceph，因为超融合追求的就是节点级的故障自愈，Ceph 的原生机制和我想要的效果完全吻合。

Ceph 的另一个优势是它支持不同的数据冗余策略。副本模式（replicated）简单可靠，三副本意味着每份数据存三份，磁盘利用率是 1/3；纠删码模式（erasure coded）空间利用率高，但 CPU 开销大、维修重建复杂。作为入门实践，我用了默认的三副本模式，三节点每节点一个 OSD 对应一份副本，任何一种节点故障数据都不会丢失。等后期扩容到五节点、六节点，再逐步引入纠删码池给冷数据用。

3. 落地实施：安装配置与参数调优

3.1 基础环境安装与集群初始化

安装 PVE 本身不复杂，官方 ISO 写盘启动，按提示选磁盘、配网络就完成了。但有几个细节会影响后面集群的稳定性，值得单独拎出来说。第一，安装时磁盘建议用 RAID 1 镜像做系统盘，避免系统盘单点故障导致节点无法启动；第二，主机名和网络配置一定要提前规划好，PVE 对主机名解析很敏感，尽量不要用 DHCP，直接配置静态 IP 并写入 /etc/hosts；第三，时区统一设置为 UTC 或同一时区，避免时间偏差引发集群通信问题。

三台节点装好系统后，创建集群。在第一台节点上执行：

pvecm create pve-cluster

其他节点加进来：

pvecm add 192.168.10.11

加入集群后检查状态：

pvecm status pvecm nodes

这里有个容易踩的坑：如果节点时间不同步，corosync 集群会反复抖动，节点状态时好时坏。我当时就遇到第二台节点的时钟慢了 30 秒，集群里总是出现“Expected downtime”的告警。解决方法是所有节点统一配置 NTP 服务，我这里用的是系统自带的 chrony，指向内网时间服务器，并写进 crontab 里定期同步校准。PVE 的 Web 界面里可以直接看各个节点的时间差，建议部署完成后多观察几天。

3.2 Ceph 存储集群配置实操

PVE 7 以上版本集成了 Ceph Pacific 和 Quincy，图形界面操作很顺畅。我的步骤是先确认所有节点的 Ceph 网络配置无误，然后逐个节点执行 pveceph 命令安装 Ceph 相关包。

pveceph install --version quincy

等待安装完成后，创建 Monitor 服务。Monitor 是 Ceph 的大脑，至少需要三个才能保证高可用，我这里三个节点各自部署一个：

pveceph init --network 192.168.20.0/24 --cluster-network 192.168.30.0/24 pveceph createmon

这里重点看一下这两个网段参数。--network 指定的是 Ceph public 网络，也就是虚拟机数据读写走的网段；--cluster-network 指定的是 OSD 之间同步数据的专用网段。如果你的环境没有独立 cluster 网络，后面 OSD 之间的复制流量会和虚拟机 I/O 抢带宽，性能会明显下降，所以务必在规划设计阶段就把这两个网段区分开。

接下来创建 OSD。每个节点四块 HDD，一共 12 块 HDD，全部做成 OSD。磁盘在创建前可以先用擦除工具清理分区表，避免旧的文件系统数据干扰 Ceph 初始化。我的操作是在 Web 界面选中节点 -> Ceph -> OSD -> Create，逐块添加，磁盘类型选 HDD。如果你有 NVMe 盘，建议把 WAL/DB 分离到 NVMe 上，这对随机写性能提升非常明显，但当时我手上的机器没有多余的 NVMe 盘位，只能先把 HDD 用起来。

创建完 OSD 后，再创建一个存储池。PVE 里存储池（Pool）对应 Ceph 的 Pool，是虚拟机镜像存放的地方。我创建了一个名为 vm-storage 的池，大小设置为 3 副本，PG 数按公式计算。

Ceph PG 数量的经验公式是：

PG 数量 = (OSD 总数 × 100) / 副本数 取最接近的 2 的幂次方

我这边 OSD 总数是 12，副本数是 3，计算结果是 12 × 100 / 3 = 400，取接近的 2 的幂是 512。PG 数量不能太大也不能太小，太小会导致单个 PG 数据量过大，故障恢复慢；太大则占用大量内存，影响 Ceph 性能。512 对于 12 个 OSD 的三副本池已经是很合理的配置。创建完成后，在 Web 界面的数据中心 -> 存储里添加 Ceph 存储，类型选 RBD，命名和池对应即可。

3.3 关键性能参数与优化

存储池建好只是开始，让虚拟机真正跑得流畅还需要调几个参数。第一，虚拟机磁盘缓存模式。在 PVE 里创建虚拟机时，磁盘总线建议选 VirtIO Block 或 SCSI，缓存模式选 Write Back 或 None。Ceph RBD 本身有缓存机制，虚拟机侧再用 Write Back 会导致两层写缓存叠加，意外断电时数据一致性风险增加。我的经验是生产虚拟机用 VirtIO SCSI 加 IO Thread 开启，缓存模式设为 None，让 Ceph 端统一处理刷盘逻辑。

第二，内存和 CPU 的 NUMA 绑定。超融合节点上虚拟机多，内存带宽和 CPU 亲和性直接影响性能。PVE 里每台虚拟机可以手动指定 CPU 类型为 host，让虚拟机直接使用宿主机 CPU 指令集，避免因 CPU 型号差异导致性能损失。同时打开 NUMA 选项，确保虚拟机的内存分配尽量在本节点物理内存范围内，减少跨 NUMA 节点的访问延迟。

第三，Ceph 的 OSD 内存和线程参数调优。每个 OSD 进程默认会占用一定内存，如果节点内存不够，OSD 频繁换页会拖垮性能。我的节点 256GB 内存，分了 4GB 给系统缓存，其余大部分交给 Ceph 使用。通过修改 /etc/ceph/ceph.conf，可以设置 osd_memory_target 和 osd_op_threads 等参数，但这些属于进阶玩法，初期保持默认值就能获得不错的性能。

第四，定期做 Ceph 健康检查和性能监控。Web 界面的 Ceph 状态页会显示整个集群的健康状态、PG 分布、OSD 使用率等。我习惯每周看一次，重点关注 PG 状态是不是都 active+clean，OSD 使用率是否均衡，网络流量是否有异常波动。数据分布越均衡，集群性能越稳定。

4. 踩坑日志与故障排查记录

4.1 时钟不同步引发的集群抖动

这是我最开始遇到的第一个大坑。三节点集群建好后，PVE Web 界面偶尔提示“corosync quorum lost”，虚拟机无法在线迁移，Ceph 的监控服务也时好时坏。排查了一圈，最后发现是第二台节点的时间超前了将近 40 秒，导致 corosync 心跳包被当成无效数据丢弃，集群反复重新选举。

解决方法是配置统一的 NTP 服务器，并确认所有节点时间差保持在 100ms 以内。测试机环境没有内网时间服务器的话，用公网 NTP 服务也可以，但机房生产环境建议搭建本地时间源，因为公网 NTP 有时不稳定。配置完 ntpdate 手动同步一次，再开启 chrony 做定期校准。这个坑提醒我，任何分布式系统第一件事就是时间同步，先后顺序别搞反了。

4.2 网络抖动导致 OSD 被标记 down

有一次机房交换机例行维护，Ceph 集群的 cluster 网络短暂中断了大概两三分钟。恢复后我登录 Web 界面，发现好几个 OSD 状态是 down，PG 变成 degraded，Ceph 开始自动发起数据重建。表面上看问题不大，数据会自动恢复，但问题在于：重建过程会消耗大量的网络带宽和磁盘 I/O，导致正在运行的虚拟机存储延迟明显升高。

后来我在 ceph.conf 里调整了 OSD 心跳相关的参数，把 osd_heartbeat_grace 从默认的 20 秒适当调大，避免短时间网络抖动就触发 OSD 标记 down。另外重要的一点是，尽量使用 bonding 或者多路径方式增强 cluster 网络的可靠性，毕竟存储网络抖动一次，整个集群都要跟着颤抖。Ceph 自身有网络异常后的自动恢复机制，但作为运维者，减少不必要的触发才是更优解。

4.3 误删存储池后的数据恢复教训

这个坑是纯粹的“手滑”事故。某次我在 Web 界面上清理测试用的存储池，本来想删掉一个实验用的旧池，结果点错了按钮，把 vm-storage 池给删掉了。删除确认框弹出来的时候，我想都没想就点了确认，等反应过来，整个池的配置已经没了。

好在 Ceph 删除池后数据并未立即物理清除，只是元数据被标记删除。如果池设置了 --yes-i-really-really-mean-it 参数，新的写入会覆盖旧数据，所以发现误删后第一时间应该停止所有写入操作，然后通过 Ceph 的备份机制恢复。我这里因为之前对池做过 RBD 快照和导出，算是捡回一条命，但整个过程耗时巨大。从那以后我给自己立了规矩：生产环境的任何删除操作都必须经过二次确认，Web 界面里同样需要谨慎操作，最好先在测试环境演练一遍删除流程。

4.4 常见问题速查表

5. 使用体验与扩展建议

这套 PVE 超融合集群从搭建到现在运行了快半年，整体感受是稳定性和灵活性都超出预期。日常维护只需要在 Web 界面上点几下，虚拟机创建、迁移、快照、备份这些操作非常顺手。Ceph 存储的健康状态一目了然，磁盘故障只需要换盘后重新创建 OSD，Ceph 会自动把数据重新均衡回去，整个过程不需要业务停机。三节点的小集群，承载我们十几台虚拟机和若干容器，CPU 和内存资源还有不少富余，后续业务增长直接加节点和磁盘就能平滑扩容。

如果让我给还没入坑的朋友几个实用建议，第一是网络规划一定要舍得投入，万兆网卡和万兆交换机是超融合的底线，千兆环境跑 Ceph 会非常痛苦；第二是不要一开始就追求复杂的纠删码、缓存分层这些高级功能，先用默认的三副本模式跑稳定再说；第三是养成做备份的习惯，PVE 自带的 vzdump 备份、Ceph 的 RBD 快照都要定期演练恢复流程，超融合不是数据安全的保险箱，完善的备份才是。最后再分享一个小技巧，多关注 PVE 官方论坛和 Ceph 社区，很多别人踩过的坑、写过的经验文档，都比你一个人摸索来得快。希望这篇实践记录能帮你在 PVE 超融合的路上少踩几个坑。

本文还有配套的精品资源，点击获取