tech 2026年03月17日 · 阅读

在 Proxmox VE (PVE) 集群中，管理是全对称且统一的。这意味着，只要你登录了集群中任意一台节点的 Web 界面（建议登录延迟最低的那台，比如你的 8C 或 4C 节点），你就可以在任何一台物理节点上创建虚拟机。（以最小一台的配置为4c8G为例）

但在 HA（高可用）环境下，创建过程需要遵循特定的逻辑，否则“高可用”只是空谈。以下是操作指南和核心注意事项：

1. 可以在任何节点创建吗？

是的，但有“物理归属”和“逻辑统一”的区别：

  • 物理归属：在创建 VM 的向导第一步，你需要选择一个 Node。这个 VM 的配置文件虽然全集群可见，但它的 CPU 和内存资源会由你选定的这台机器提供。
  • 逻辑统一：无论你在哪台机器上点击“创建”，该 VM 的配置文件都会存放在 /etc/pve/（这是集群共享的文件系统）。因此，所有节点都能看到这个 VM 的定义。

2. 在 HA 集群上创建 KVM 的标准步骤

如果你想让一个虚拟机具备“挂了自动闪转腾挪”的能力，请按以下流程操作：

第一步：基础创建（关键配置）

在创建向导中，为了兼容你的 Intel/AMD 混合环境：

  1. OS/系统：勾选 Qemu Agent（必选，用于感知虚拟机状态）。
  2. CPU：Type 必须选择 x86-64-v2-AES。不要选 host，否则无法在不同品牌的 CPU 间迁移。
  3. 网络：确保所有节点都有同名的网桥（如 vmbr0）。

第二步：存储选择（HA 的生命线）

这是最容易出错的地方。由于你的 VPS 之间没有真正的物理共享存储：

  1. 磁盘存储：必须选择一个在所有节点都存在且同名的存储 ID（例如 local-zfs）。

  2. 开启复制：VM 创建完成后，点击该 VM -> Replication（复制） -> Add。

    • 设置将数据同步到集群内的其他节点。
    • 建议同步频率设为 1-5 分钟。

第三步：正式开启 HA 保护

注意：创建完 VM 并不代表它就是 HA 的。

  1. 点击左侧菜单的 Datacenter（数据中心）。
  2. 选择 HA -> Resources -> Add。
  3. 选择你刚刚创建的 VM ID。
  4. Max Restarts（最大重启次数）：通常设为 1 或 2。
  5. Group：如果你设置了 HA 分组（比如避开 150ms 延迟的节点），请在这里选择。

3. 管理重心：你应该在哪台节点上操作？

虽然可以在任意节点操作，但根据你的硬件情况（4C/8G 和 16C/16G，且有 150ms 延迟）：

  • 建议入口：始终通过 4C/8G（本地低延迟节点） 登录管理后台。

    • 原因：从本地操作远端 16C 节点，PVE 会在后台处理指令。即便 16C 节点响应慢，你的 UI 界面也不会卡死。

  • 资源规划建议：

    • 创建在 16C 节点上：跑重型任务，通过 HA 备份到 4C 节点。
    • 创建在 4C 节点上：跑延迟敏感任务（Web、DB），通过 HA 备份到 16C 节点。

4. 特别提醒：避免“幽灵虚拟机”

在 HA 集群中，有一个常见的误区：手动在两台机器上创建 ID 相同的虚拟机。

  • 后果：这会导致集群配置冲突，PVE 会锁定该 ID，甚至导致整个集群的文件系统进入只读模式。
  • 正确做法：在一个节点创建，通过 PVE 内置的 Migrate（迁移） 或 Replication（复制） 功能让它“流转”到其他节点。

总结：你的操作清单

  1. 登录 4C 节点 的 Web UI。
  2. 右键点击 16C 节点，选择 Create VM。
  3. 设置 CPU 为 x86-64-v2-AES，内存不超 6GB。
  4. 在 Replication 选项里开启向 4C 节点的定时同步。
  5. 在 Datacenter -> HA 中把这个 VM 加进去。

举例：
在 Proxmox VE (PVE) 的 HA 集群中，实现高可用性的核心逻辑是：“最弱的节点必须能接管最强的节点”。

你的集群由两台 4C/8G 和一台 16C/16G 组成。要实现可靠的 HA（故障自动迁移并重启），虚拟机的规格设计必须遵循以下原则：

1. 确实，4C CPU 是你的“性能硬短板”

在 HA 场景下，你的虚拟机最大规格必须受限于性能最低的节点（即 4C/8G 节点）。

  • vCPU 建议：不要超过 4C，建议设置为 2-3C。

    • 理由：虽然 PVE 允许“超配”（比如在 4C 的物理机上跑 8 vCPU 的虚拟机），但这样会导致严重的 CPU 争抢 (CPU Steal)。如果你的虚拟机刚好分配了 4C 且满载，宿主机 PVE 自身的管理进程（如 Corosync, pvestatd）将抢不到 CPU 时间片。这会导致心跳包延迟，从而误触发 HA 围栏机制（Fencing），导致节点不断重启。
    • 预留空间：为了保证宿主机系统的稳定性，建议每个虚拟机给宿主机留出 1 个物理核心。

2. 真正的“隐藏短板”是 8G 内存

相比 CPU，内存是更刚性的限制。CPU 慢点还能跑，内存不够会直接导致虚拟机启动失败或宿主机 OOM (Out of Memory)。

  • 内存建议：单个虚拟机不要超过 4-5GB。

    • 算一笔账：

      • 4C/8G 节点：PVE 系统占用约 1GB + ZFS 缓存占用约 1GB = 剩余可用约 6GB。
      • 如果你创建一个 6GB 内存的虚拟机，一旦它从 16G 节点迁移到 8G 节点，可能会因为宿主机内存瞬间见底而崩溃。
    • 高可用极限：如果你一定要跑一个大内存业务，那么你在全集群运行的所有虚拟机内存总和，不能超过 6GB。

3. 如何实现“不中断”的高可用性？

正如之前提到的，PVE 的 HA 是“故障重启”级。要实现数据库等业务的“不中断”，建议如下配置：

  • 虚拟机规格建议：

    • CPU: 2 核心 (vCPU)
    • 内存: 4 GB
    • CPU 权重: 设置为 1000 (默认)

  • 部署策略：

    1. 两台 4C/8G 节点作为主力对冲：让它们互相作为备份。
    2. 16C 节点作为“资源池”：它可以轻松接管两个 4C 节点的任务，但反过来不行。
    3. 使用反亲和性 (Affinity Rules)：如果你跑数据库主从，必须强制主库 VM 和从库 VM 运行在不同节点上。

4. 关键点：跨架构兼容性

由于你之前提到有 Intel 和 AMD 的混搭：

  • 必须设置 CPU 型号为 x86-64-v2-AES。
  • 即便 16C 的服务器核心多，如果你在它上面用了 host 模式或分配了 16 个核心，这个虚拟机将永远无法通过 HA 迁移到 4C 节点上。

总结方案：

为了确保 HA 能够百分之百触发成功，建议你创建的单个高可用虚拟机：

  1. vCPU 分配 2 核心（即便在 16C 节点上也是如此）。
  2. 内存分配 4GB。
  3. 开启 QEMU Guest Agent（保证迁移时状态快速同步）。

这样，无论哪台服务器倒下，剩下的节点都能在 60 秒内 稳稳地把虚拟机拉起来。如果你觉得 2C/4G 不够用，那说明你应该把那两台 4C/8G 的机器升级了，因为它们限制了整个集群的上限。

pve selfhosting 经验