tech 2026年03月17日 · 阅读

在 Proxmox VE (PVE) HA 集群上部署数据库等关键业务，要实现“不中断”或“极高可用性”，不能只依赖 PVE 的基础 HA 开关，还需要结合应用层的策略。

因为 PVE 的 HA 属于 “冷跳转”：当宿主机宕机时，虚拟机需要在另一个节点上“重启”。这会导致几分钟的服务中断。如果要实现真正的“不中断”，需要按照以下架构进行部署：

1. 存储层：解决数据的“实时性”

HA 的前提是：当 A 节点挂了，B 节点必须有最新的数据。

  • 推荐方案：ZFS Replication (异步复制)

    • 在虚拟机设置中开启 Replication，每 1 分钟同步一次。
    • 优点：不需要昂贵的外部存储。
    • 缺点：如果故障发生在两次同步之间，会丢失最后 1 分钟的数据。对于数据库来说，这可能导致数据不一致。

  • 进阶方案：分布式存储 (Ceph / DRBD)

    • 数据实时写入多个节点。但考虑到你的环境（150ms 延迟），禁止使用。

2. 应用层：实现“不中断”的核心（数据库冗余）

不要把所有希望寄托在 PVE 把虚拟机拉起来，而是在多个虚拟机内做集群/主从。

  • 数据库方案（如 MySQL/PostgreSQL）：

    1. 在 节点 A (8C) 和 节点 B (16C) 上各建一个虚拟机。
    2. 配置 主从同步 (Replication) 或 多主集群 (Galera/Patroni)。
    3. 配合 Keepalived/VIP：通过虚拟 IP 指向当前主库。

  • 高可用策略：

    • 当节点 A 挂了，运行在节点 B 上的数据库实例依然在线。
    • 此时前端应用几乎感觉不到中断（仅有秒级的 TCP 重连）。
    • PVE 的 HA 此时作为“后手”：它会自动在节点 B 或 C 上重启原来在 A 上的虚拟机，作为冗余节点的补充。

3. 创建虚拟机时的关键配置（实现冗余的关键）

在创建用于数据库高可用的 VM 时，务必注意以下设置：

  1. CPU 与内存限制：

    • CPU Type：务必选 x86-64-v2-AES（跨 Intel/AMD 兼容）。
    • 内存：禁用 Ballooning（气球驱动），为数据库分配固定内存。数据库对内存抖动非常敏感。

  2. 设置“反亲和性”规则 (Affinity Groups)：

    • 核心操作：你绝对不能让“主数据库 VM”和“从数据库 VM”运行在同一个物理节点上。
    • 在 Datacenter -> HA -> Groups 中创建规则，强制这两个虚拟机分散在不同节点。

  3. 开启 HA 保护：

    • 在 Datacenter -> HA -> Resources 中添加该 VM。
    • Recovery Policy：设为 Request State: Started。

4. 针对你 150ms 延迟环境的特殊优化

由于节点 B（16C）距离很远，数据库同步会面临“延迟抖动”：

  • 不要做同步复制：数据库主从请使用 “异步复制”。如果用“同步复制”，主库的每一次写入都要等待 150ms 后的远端确认，你的数据库性能会下降 90% 以上。
  • Quorum 仲裁：确保你的 1C/2G 仲裁机在线。否则网络波动导致 A 和 B 互相看不见时，它们会因为争夺虚拟 IP 导致“脑裂”，彻底损坏数据库文件。

5. 管理建议：分层部署

  • 第一层：负载均衡/反向代理 (LXC)：部署在节点 A 和 C（本地低延迟区），使用 Keepalived 做高可用。
  • 第二层：应用服务 (K8s/Docker)：分散在 A、B、C 上。
  • 第三层：数据库 (VM)：主库放在 A (8C Intel)，从库放在 B (16C AMD)，并在 C 上放一个轻量级的投票节点。

总结：
在 PVE 上实现数据库不中断高可用的最佳实践是：PVE HA 提供底层的“故障自动重启”保障，而数据库主从架构提供业务层的“无缝切换”保障。

pve zfs 经验