外观
集群与高可用
把几台 PVE 组成集群，能得到：一套界面管所有节点、客户机在节点间迁移、配置自动同步。再加上共享存储和 fencing，还能做高可用。
代价是复杂度显著上升，以及一类新的故障模式：集群本身出问题。
核心概念：quorum（仲裁）
集群靠 corosync 维持成员关系，用 quorum 决定「谁说了算」。
规则很简单：一个分区必须持有超过半数的投票，才有资格继续提供服务。
| 节点数 | 需要的票数 | 能容忍几台故障 |
|---|---|---|
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
两节点集群比单机更脆弱
两节点集群需要 2 票才有 quorum。这意味着任何一台节点故障或网络断开，剩下那台也会失去 quorum——/etc/pve 变成只读，客户机不能启动、不能修改配置。
结果是：两台机器，任何一台出问题，两台都不能正常工作。这比单机还差。
想要两节点，必须加一个 QDevice（一个只投票不跑客户机的轻量仲裁节点，可以是一台树莓派）。或者直接上三节点。
查看当前状态：
sh
pvecm status关注 Quorate: Yes 和 Expected votes / Total votes。
HA 的前提条件
高可用（节点挂了，客户机自动在别的节点上拉起来）需要：
- 至少 3 个节点（或 2 节点 + QDevice）。
- 共享存储。客户机磁盘必须在所有节点都能访问的存储上（Ceph、NFS、iSCSI）。磁盘在本地存储上的客户机，别的节点拉不起来。
- 可靠的 fencing。PVE 用 watchdog 实现：失去 quorum 的节点会自我重启，确保不会出现两个节点同时跑同一台客户机（脑裂）。
「它为什么自己重启了」
这是 HA 最常见的困惑。答案通常是：这个节点失去了 quorum，watchdog 把它重启了。
这是设计如此，不是故障。脑裂导致的数据损坏比一次重启严重得多。
但这也意味着：corosync 的网络必须可靠。网络抖动会被当成节点失联，触发不必要的重启。生产环境建议给 corosync 独立的网络链路。
本章文章
组建与维护集群
- 组建集群：前置条件、创建与加入的步骤，以及加入会怎样覆盖节点的
/etc/pve。 - 给两节点集群加 QDevice：用一台不跑客户机的小设备补上第三票。
- 在线迁移与离线迁移：什么条件下能不停机搬家。
- 安全移除节点：按官方顺序体面地请出一个节点，避免留下幽灵节点。
高可用（HA）
- 高可用入门：fencing 与 watchdog：打开 HA 前要懂的两个后台角色和资源状态。
- HA 资源与 affinity 规则：PVE 9 用 node-affinity/resource-affinity 规则取代了旧的 HA Groups。
- CRS 调度与动态负载均衡：PVE 9.2 新增的持续自动均衡。
- 维护模式与 HA arm/disarm：单节点维护模式，和集群级的一键 disarm。
组集群之前想清楚
集群不是「多台机器的自然升级」。它引入了新的依赖（corosync 网络、时间同步、共享存储）和新的故障模式。
如果你的三台机器各跑各的、互不相关，不组集群更简单。 组集群的理由应该是：需要迁移、需要统一管理、或者需要 HA。
单机也能用的相关知识
即使不组集群，这些也值得知道：
/etc/pve是 pmxcfs，一个由数据库支撑的 FUSE 文件系统。单机时它也在跑。它变成只读通常意味着pve-cluster服务出了问题。- 集群配置在
/etc/corosync/corosync.conf（单机没有这个文件）。 pvecm status在单机上也能跑，会显示这是一个单节点。