第 15 章 高可用（HA）

15.高可用High Availability

现代社会对计算机网络提供的信息高度依赖 —— 移动设备又放大了这种依赖。提供此类服务时 ， 大多数时间可用至关重要。

可用性可数学定义为 ：(A) 服务在一段时间内可用的总时长 / (B) 该时间段长度 ， 通常以年度正常运行时间的百分比表示：

提升可用性的方式很多 —— 最优雅的是重写软件让它能同时在多台主机上运行并自带错误检测与故障转移；但这通常复杂 ， 且软件往往你改不了。不改软件也可做：

• 用可靠的「服务器级」组件 —— 相同功能的组件在品质上可能差别很大 ， 大多数厂商以更高价出售可靠性更高的「服务器级」组件。
• 消除单点故障（冗余组件）：UPS、冗余电源、 ECC-RAM、冗余网络硬件、本地 RAID、分布式冗余存储等。
• 减少停机时间：可随时响应的管理员（7×24）、备件（PVE 集群里其他节点）、自动错误检测与故障转移（ha-manager）。

Proxmox VE 这类虚拟化环境去除了「硬件」依赖 ， 便于实现高可用 —— 支持冗余存储与网络 ， 一台主机故障时可在集群其他节点启动服务。更好的是 ， PVE 提供 ha-manager 软件栈自动完成这一切 ， 可自动检测错误并做故障转移。

ha-manager 像一个「自动化」的管理员 ：先配好它要管哪些资源（VM、容器……）， 然后它会观察运行并在出错时把服务转移到其他节点；也能响应用户的起停 / 重定位 / 迁移请求。

15.1.要求Requirements

• 至少 3 个集群节点（以获取可靠 quorum）
• VM / 容器用 共享存储
• 处处硬件冗余
• 使用可靠「服务器级」组件

可选 ：使用硬件 watchdog —— 无可用硬件时回退到 Linux 内核软 watchdog（softdog）。

15.2.资源Resources

ha-manager 管理的主要单元称作 资源（也叫「服务」）， 以服务 ID（SID）唯一标识 —— 形如 <type>:<id>， 例如 vm:100 是 ID 为 100 的 VM 类型资源。目前两种主要类型 ：虚拟机与容器。我们的基本思路是把相关软件打包进一个 VM / 容器 ， 而不是像 rgmanager 那样把大服务由若干小服务组合 —— 一般 HA 管理的资源 不应 依赖其他资源。

15.3.管理任务Management Tasks

GUI 或命令行均可。为资源启用 HA：

# ha-manager add vm:100

HA 栈会尝试启动并保持它运行。可配置「请求状态」：

# ha-manager set vm:100 --state stopped   # 停
# ha-manager set vm:100 --state started   # 启

普通的 qm / pct 命令会自动转发到 HA 栈 —— 例如 qm start 100 即把请求状态改为 started。

查看当前配置：

# ha-manager config
vm:100
  state stopped

查看当前管理器与资源状态：

# ha-manager status
quorum OK
master node1 (active, Wed Nov 23 11:07:23 2016)
lrm elsa (active, Wed Nov 23 11:07:19 2016)
service vm:100 (node1, started)

迁移到其他节点（在线迁移）：

# ha-manager migrate vm:100 node2

在线迁移要把全部已用内存过网络 —— 有时先停再启更快（relocate）：

# ha-manager relocate vm:100 node2

从 HA 配置移除：

# ha-manager remove vm:100

默认还会从任意引用它的规则中移除该资源 ， 并删除仅剩此一资源的规则。可用 --purge 0 覆盖。

15.4.工作原理How It Works

每节点两个守护进程：

pve-ha-lrm（LRM， 本地资源管理器）

控制本节点上的服务 —— 从 manager status 文件读请求状态并执行相应命令。

pve-ha-crm（CRM， 集群资源管理器）

做集群级决策 —— 向 LRM 下发命令、处理结果、故障时迁资源到其他节点 ， 也负责节点 fencing。

LRM / CRM 锁：锁由 pmxcfs 提供 ， 保证每个 LRM 只激活一次。 LRM 仅在持锁时执行动作 —— 若我们能取到某故障节点的锁 ， 就可以安全认定它已 fenced， 从而无后顾之忧地恢复其 HA 服务。这由持有 master 锁的 CRM 监督。

15.4.1.服务状态

CRM 用枚举记录当前服务状态 —— GUI 显示、 ha-manager status 可查。可能的状态：

stopped

已停（LRM 确认）。若 LRM 发现已「停」的服务其实还在跑 ， 会再次停止它。

request_stop

应停。 CRM 正等待 LRM 确认。

stopping

待停请求 —— CRM 目前尚未收到该请求。

started

活动中 —— 未运行则 LRM 应尽快启动；失败后检测到未运行 ， LRM 会按 失败策略 重启。

starting

待启请求 —— CRM 尚未收到 LRM 的运行确认。

fence

等待节点 fencing（所在节点不在法定人数分区 ， 见 Fencing）。 fencing 成功即进入 recovery。

recovery

等待恢复 —— HA 管理器找一个新节点运行服务。选择依据在线 quorate 节点列表与亲和规则（若有）。找到后先置为 stopped， 若配置为运行则在新节点启动。

freeze

保持状态不动 —— 节点重启或 LRM 重启期间使用（见 升级）。

ignored

视同未被 HA 管理 —— 想临时完全接管某服务 ， 又不想从 HA 配置删除时用。

migrate

在线迁移到其他节点。

error

因 LRM 错误被禁用 —— 需人工介入（见 错误恢复）。

queued

新加入 —— CRM 尚未见过。

disabled

已停并标记 disabled。

15.4.2.本地资源管理器 LRM

pve-ha-lrm 开机以守护进程启动 ， 等集群 quorate 后集群锁可用。三种状态：

• wait for agent lock：等待独占锁 —— 无服务时也作闲置态。
• active：已持锁且有服务。
• lost agent lock：锁丢了 —— 意味着发生故障或失了 quorum。

进入 active 后 ， LRM 读 /etc/pve/ha/manager_status 决定要执行的命令。每条命令起一个 worker ， 并发上限默认 4（数据中心 max_worker 可调）。完成后收集 worker 并把结果存给 CRM。

CRM 的每条命令都有唯一 UID， worker 完成后结果写入 /etc/pve/nodes/<nodename>/lrm_status， CRM 据此推进状态机。 CRM 与 LRM 之间的动作通常同步 —— CRM 以 UID 标记请求状态 ， LRM 执行一次并回写同 UID 结果 ， 避免 LRM 执行过期命令。例外 ：stop 与 error 命令 —— 不依赖返回结果 ， 停止态总是执行 ， 错误态执行一次。

15.4.3.集群资源管理器 CRM

pve-ha-crm 在每个节点启动并等待 manager 锁 —— 集群内一次只允许一个节点持有 ， 成功持有者升为 CRM master。三种状态同 LRM。

主要任务 ：管理 HA 服务 ， 始终尝试执行请求状态 —— 例如「started」服务若未运行则启动它 ， 崩溃也会自动再启；从而 CRM 决定 LRM 要执行的动作。

当某节点离开 quorum 时 ， 其状态变 unknown —— 当前 CRM 若能取到该失败节点的锁 ， 其服务会被「偷走」并在其他节点重启。

当集群成员发现自己不再处于集群 quorum 时 ， LRM 等待新 quorum 形成。在此之前节点无法复位 watchdog —— 如节点上有活跃服务 ， 或 LRM / CRM 进程未被调度 / 被杀 ， watchdog 超时（60 秒）后会重启本节点。

注意 ：若节点有 active CRM 但 LRM 闲置 ， 失 quorum 不会 触发自体 fence 复位。原因 ：CRM 访问的所有状态与配置都由集群文件系统兜底 ， 失 quorum 后变只读 —— 所以 CRM 只需防自己被调度过久 ， 否则另一 CRM 可能接管而不自知 ， 造成 HA 状态损坏；已开的 watchdog 保证这不会发生。

若超过 15 分钟仍无服务配置 ， CRM 会自动回到闲置态并完全关闭 watchdog。

15.5.HA SimulatorHA Simulator

用 HA Simulator 可测试和学习 PVE HA 的各项能力 —— 默认模拟 3 节点集群 + 6 VM， 也可增删。无需真集群即可开箱使用。安装：

apt install pve-ha-simulator

也可装到任何 Debian 派生系统（无需其他 PVE 包）—— 下载包到目标系统 ， 用 apt 从本地文件安装会自动解依赖。远端机启动需 X11 转发 ， Linux 下可用 ssh root@<IP> -Y， Windows 下可用 MobaXterm。先建工作目录供模拟器存状态与默认配置 ， 然后将目录传给模拟器：

mkdir working
pve-ha-simulator working/

启停、迁移模拟的 HA 服务 ， 也能看节点故障时的表现。

15.6.配置Configuration

HA 栈深度集成 PVE API —— 可用 ha-manager CLI 或 Web 界面配置 ， 自动化工具可直接用 API。所有 HA 配置位于 /etc/pve/ha/， 自动分发到集群各节点 ， 所有节点共享同一份配置。

15.6.1.资源

资源配置文件 /etc/pve/ha/resources.cfg。条目格式：

<type>: <name>
  <property> <value>
  ...

类型 + 冒号 + 资源名即 HA 资源 ID（如 vm:100、 ct:101）。属性：

comment

描述。

failback（默认 1）

若更高优先级节点上线 ， 按节点亲和规则自动迁回。

group

HA group 标识。

max_relocate（默认 1）

服务启动失败时的重定位尝试上限。

max_restart（默认 1）

同一节点上服务启动失败后的重启尝试上限。

state（默认 started）

请求状态 ：

• started：CRM 尝试启动；成功后标为 started；节点故障或启失败时尝试恢复；全失败即 error。 enabled 是其别名。
• stopped：CRM 保持停止状态 ， 但节点故障时仍会重定位。
• disabled：CRM 保持停止 ， 故障时 不 重定位 —— 主要用于错误恢复（是把资源移出 error 的唯一办法）。
• ignored：从 manager status 移除 —— CRM / LRM 不再碰它；所有 PVE API 调用绕过 HA 栈直达资源；节点故障也不重定位。

示例 /etc/pve/ha/resources.cfg：

vm: 501
  state started
  max_relocate 2

ct: 102
  # 其他全部默认

对应 CLI：

# ha-manager add vm:501 --state started --max_relocate 2
# ha-manager add ct:102

15.6.2.Groups

/etc/pve/ha/groups.cfg 用于定义节点组 —— 资源可被限定只在组成员上运行。配置格式：

group: <group>
  nodes <node_list>
  <property> <value>

comment

描述。

nodes（<node>[:<pri>]{,<node>[:<pri>]}*）

集群节点列表 ， 每节点可带优先级。资源会运行于 在线且优先级最高 的节点上；有多台同最高优先级则在它们间分布。优先级只表相对大小 ， 数字越大越优先。

nofailback（默认 0）

CRM 默认会把服务迁到当前在线的最高优先级节点；开启它可阻止这种迁移。

restricted（默认 0）

绑定到 restricted 组的资源只能运行于组内节点 —— 全部离线时资源置 stopped；非 restricted 组则可跑到任意节点 ， 组成员回来后迁回。用只含一个成员的非 restricted 组可实现「偏好节点」行为。

常见场景与命令：

# 偏好 node1
ha-manager groupadd prefer_node1 --nodes node1

# 优先 node1；其次在 node2 与 node3 平均分布；最后到 node4
ha-manager groupadd mygroup1 -nodes "node1:2,node2:1,node3:1,node4"

# 限制只能运行于 node1 / node2
ha-manager groupadd mygroup2 -nodes "node1,node2" -restricted

对应 /etc/pve/ha/groups.cfg：

group: prefer_node1
  nodes node1

group: mygroup1
  nodes node2:1,node4,node1:2,node3:1

group: mygroup2
  nodes node2,node1
  restricted 1

nofailback 主要用于避免维护期间不必要的资源迁移 —— 例如把服务迁到非最高优先级节点时 ， 希望 HA 管理器别马上把它迁回。另一个场景 ：被 fence 过并已恢复到其他节点的服务 ， 管理员正修原节点 ， 打开 nofailback 可阻止服务立刻迁回 ， 以便观察节点是否稳定。

15.6.3.规则

HA 规则定义在 /etc/pve/ha/rules.cfg， 用以对 HA 管理的资源施加约束：

<type>: <rule>
  resources <resources_list>
  <property> <value>

comment

描述。

disable

是否禁用本规则。

resources

HA 资源 ID 列表（如 vm:100,ct:101）。

节点亲和规则

默认 HA 资源可运行于任意节点 —— 若要偏好某节点 ， 建节点亲和规则：

# ha-manager rules add node-affinity ha-rule-vm100 \
  --resources vm:100 --nodes node1

默认非严格 —— 指定节点全不可用时仍会迁去其他节点。如要严格限制 ， 加 --strict：

# ha-manager rules set node-affinity ha-rule-vm100 --strict 1

更细粒度 ：用优先级排序节点偏好 —— 相同优先级的节点可随意选。例 ：vm:200 与 ct:300 最优先在 node1， 其次平摊到 node2 / node3， 最后 node4（0 可省略）：

# ha-manager rules add node-affinity priority-cascade \
  --resources vm:200,ct:300 --nodes "node1:2,node2:1,node3:1,node4"

生成的 /etc/pve/ha/rules.cfg：

node-affinity: ha-rule-vm100
  resources vm:100
  nodes node1
  strict 1

node-affinity: priority-cascade
  resources vm:200,ct:300
  nodes node1:2,node2:1,node3:1,node4

节点亲和规则属性

nodes

节点列表 ， 各节点可带优先级。

resources

HA 资源 ID 列表。

strict（默认 0）

非严格时只是「偏好」， 指定节点不可用时可迁他处；严格时只允指定节点 ， 否则服务被停。

资源亲和规则

常见需求 ：两个或多个资源必须同节点共驻 ， 或必须分离到不同节点（即「亲和 / 反亲和」约束）。例如 Web 服务 + 数据库通信多 ， 放一起降延迟：

# ha-manager rules add resource-affinity keep-together \
  --affinity positive --resources vm:100,vm:200

反之 ， 计算密集或分布式程序（如分片数据库）放同节点会相互挤压 ， 应分离：

# ha-manager rules add resource-affinity keep-separate \
  --affinity negative --resources vm:200,ct:300

资源亲和规则与节点亲和不同 —— 默认严格：约束无法满足时 ， HA 管理器在故障转移时把资源置 recovery 态 ， 否则置 error 态。

生成的 /etc/pve/ha/rules.cfg：

resource-affinity: keep-together
  resources vm:100,vm:200
  affinity positive

resource-affinity: keep-separate
  resources vm:200,ct:300
  affinity negative

正 / 负资源亲和之间的相互作用

若某资源同时在正亲和与负亲和规则里 ， 则 正亲和里的其他资源 也会与该负亲和里的那些资源保持负亲和。例如 vm:100 / vm:101 / vm:102 在一条正亲和里 ， 而 vm:100 与 ct:200 在负亲和里 ， 则 vm:101 与 vm:102 也与 ct:200 互为负亲和。

注意 ：若两或多个资源同时处于一对冲突的正亲和与负亲和 ， 两条规则都会被禁用 —— 无法同时做到「同节点共驻」又「分离」。详见 §15.6.4。

节点亲和与正资源亲和之间

正亲和里的所有资源会 继承 组内任一资源的节点亲和。例如 vm:100 / vm:101 / vm:102 在正亲和 ， vm:102 有节点亲和要求只在 node3 ， 则 vm:100 与 vm:101 也被限制到 node3。

若正亲和里不同资源分别关联到 不同的 节点亲和规则 ， 这组规则会报错并被禁用（目前不支持此组合）。

资源亲和规则属性

affinity（positive / negative）

同节点 vs. 分离到不同节点。

resources

HA 资源 ID 列表。

15.6.4.规则冲突与错误

新建 / 修改规则时会先跑可行性检查 ， 失败则禁用规则直到冲突解决。当前检查：

• 一个 HA 资源只能出现在一条节点亲和规则里。
• 资源亲和规则至少要两个资源。
• 负资源亲和的资源数不能超过集群节点数（否则没足够节点分离）。
• 正亲和与负亲和 不能 指定相同的两个或更多资源（不能同时要求同居又分离）。
• 资源同时存在于节点亲和与资源亲和规则时 ， 该节点亲和 仅限单一优先级类。
• 正亲和里的资源最多只能在一条节点亲和规则里。
• 负亲和里的资源 ， 其节点亲和允许的节点数不能少于资源数（否则分不开）。

15.7.FencingFencing

节点故障时 ， Fencing 确保故障节点肯定离线 —— 避免同一资源在恢复后同时运行两份。这很关键 —— 若不能 fence， 故障节点可能仍在访问共享资源（设想只剩存储网可达 ， VM 仍在写共享存储）， 此时在别的节点再启该 VM 会引发双写竞态 ， 可能毁掉全部数据；存储若保护多重挂载 ， 恢复也会失败。

15.7.1.Proxmox VE 的 Fencing 方式

可行方式 ：电源切断 / 交换机隔离 / 自 fence（watchdog 定时器）。前两者依赖额外昂贵硬件 ， 一旦这些硬件故障会让故障不可恢复。我们整合更简单的基于 watchdog 的方式 —— 不需额外外部硬件。

常见方法：

• 外部电源开关
• 交换机上完全禁用网络来隔离节点
• 用 watchdog 定时器做自 fence

Watchdog 定时器在关键与可靠系统中广泛使用 —— 通常是简单、独立的 IC， 用以检测并从计算机故障中恢复。正常工作时 ha-manager 周期性复位它；如硬件故障或程序错误致使复位失败 ， 定时器将超时触发整机重置（重启）。现代服务器主板常内置硬件 watchdog ， 但需显式配置；不可用时回退 softdog —— 仍可靠 ， 但不独立于服务器硬件 ， 可靠性低于硬件 watchdog。

15.7.2.配置硬件 Watchdog

出于安全考虑 ， 默认屏蔽所有硬件 watchdog 模块 —— 未正确初始化时它们就像「上了膛的枪」。启用硬件 watchdog 在 /etc/default/pve-ha-manager 指定要加载的模块：

# 默认 softdog
WATCHDOG_MODULE=iTCO_wdt

此配置由 watchdog-mux 服务读取 ， 启动时加载指定模块。

15.7.3.恢复被 fence 的服务

节点故障且 fencing 成功后 ， CRM 会把服务从故障节点迁到仍在线的节点。选择取决于当前活动节点、其负载（取决于所用调度器）以及服务参与的亲和规则（若有）：

• 先构造服务可用节点集合。
• 若服务在节点亲和规则中 ， 集合缩减为规则中最高优先级的节点。
• 若在资源亲和规则中 ， 进一步按约束（与某些服务同节点或不同节点）缩减。
• 最后 CRM 按所用调度器选负载最低的节点 ， 以降低过载概率。

15.8.启动失败策略Start Failure Policy

服务在某节点多次启动失败时生效。用于配置在同节点重启次数与迁至其他节点的次数 —— 以绕过某节点的临时不可用（如共享存储暂时不通）。每个资源可独立配：

max_restart

同节点重启失败服务的最大次数 ， 默认 1。

max_relocate

迁至其他节点的最大次数 ， 仅在同节点 max_restart 超限后触发 ， 默认 1。

15.9.错误恢复Error Recovery

所有尝试均失败后 ， 服务进入 error 态 —— HA 栈不再碰它。唯一出路是禁用：

# ha-manager set vm:100 --state disabled

Web 界面也可。从 error 恢复的步骤：

1. 把资源弄回安全一致状态（如服务停不下来就把进程杀掉）。
2. 禁用资源以清除 error 标志。
3. 修复造成失败的根因。
4. 修好后请求重新启动。

15.10.软件包升级Package Updates

升级 ha-manager 时应 一个节点一个节点 做 ， 不要一次全升：首先 ， 即便我们充分测试 ， 也无法完全排除影响你特定部署的 bug；逐个更新并每次验证功能 ， 便于从潜在问题中恢复；一次升全可能弄坏整个集群。

此外 ， HA 栈在集群与 LRM 间用请求确认协议。重启时 LRM 会请求 CRM 冻结其全部服务 ， 以免 LRM 重启的短时间里被集群碰 —— LRM 之后才能在重启时安全关闭 watchdog。包升级通常触发这种重启 ， 需要活动 master CRM 来确认 LRM 请求；否则升级可能时间过长 ， 最坏触发 watchdog 复位。

15.11.节点维护Node Maintenance

有时需要对节点做维护（换硬件、升内核等）， HA 栈也要工作。两类支持：

• 常规关机 / 重启 ：由 关机策略 控制。
• 不需关机 / 重启 ， 或只重启一次后不想自动退出维护状态 ：启用手动维护模式。

15.11.1.维护模式

手动维护模式把节点标记为 HA 不可用 —— 所有 HA 管理的服务都会迁到其他节点。目标节点由 HA 规则与 CRS 模式决定；迁移时记录原节点 ， 维护结束且节点上线后服务会自动迁回。

目前通过 ha-manager CLI 开 / 关。启用：

# ha-manager crm-command node-maintenance enable NODENAME

这会排队一条 CRM 命令 —— 被处理后在 manager status 记录维护请求。命令可在 任意 节点发起 ， 不必在那个要进 / 出维护的节点。

相应节点 LRM 接到后会把自己标记为不可用 ， 但继续处理迁移命令 —— 即 LRM 的自 fence watchdog 会保持激活 ， 直到所有活跃服务迁走、所有运行 worker 完成。

注意 ：LRM 接起请求 那一刻 就显示 maintenance mode ， 而不是等服务全部迁走时（此处 UX 未来会改进）。可查节点是否还有活跃 HA 服务 ， 或盯日志 pve-ha-lrm[PID]: watchdog closed (disabled) 确认进入维护完成。

禁用：

# ha-manager crm-command node-maintenance disable NODENAME

同样排队一条 CRM 命令 —— 处理后对应 LRM 节点重标为可用。此时 ， 进入维护时被迁走的服务会迁回。

15.11.2.关机策略

以下是各种关机 HA 策略 —— 当前 Conditional 为默认（向后兼容）， 部分用户会觉得 Migrate 更符合预期。可在 Datacenter → Options → HA Settings 或直接 /etc/pve/datacenter.cfg 配：

ha: shutdown_policy=<value>

Migrate

LRM 收到关机请求且启用本策略时 ， 自己标不可用 —— 触发该节点全部 HA 服务迁移；并尝试延迟关机过程直到所有服务迁走。前提 ：服务 可 迁到其他节点（即不被本地绑定 ， 如硬件直通）。如严格节点亲和限制服务只能在指定节点上跑 ， 而这些节点全不可用 ， 关机会挂起直到人工介入。节点再上线后 ， 期间未被手工迁走的服务会迁回。

Failover

停止所有服务 ， 但若当前节点短期不上线即做恢复。集群级维护时常用 —— 过多节点关机时在线迁移不可行 ， 但仍希望 HA 服务尽快恢复启动。

Freeze

停止所有服务并冻结 —— 节点再上线前不恢复。

Conditional

自动判断是关机还是重启 ， 并据此调整行为。

Shutdown：一般用于计划性长时间停机。 LRM 会停所有管理的服务 ， 之后其他节点接管。

Reboot：用 reboot 发起 ， 通常是装新内核。它与 shutdown 不同 —— 节点会立刻再启。 LRM 告诉 CRM 要重启 ， 等 CRM 把资源置于 freeze（同包升级机制）防止被迁到其他节点 ， 而是让 CRM 在本节点重启后再启动这些资源。

手动迁移

关 / 重启前也可手动迁移资源 —— 好处是完全可控 ， 可选是否在线迁移。

15.12.集群资源调度Cluster Resource Scheduling

CRS 模式决定 HA 如何为服务挑选恢复 / 迁移目标节点。默认 basic， 可在 Datacenter → Options 或 datacenter.cfg 配：

crs: ha=static

下一轮 manager round（几秒后）生效。对每个待恢复 / 迁移的服务 ， 调度器按 HA 规则从可用节点中迭代选最佳。

15.12.1.Basic 调度器

用每节点活跃 HA 服务的数量挑选恢复节点 —— 非 HA 管理的服务当前不计入。

15.12.2.Static-Load 调度器

用每节点 HA 服务的静态使用信息选恢复节点 —— 非 HA 服务同样不计。选节点时 ， 轮流假设服务已运行在某节点 ， 用其配置中的 CPU / 内存用量 —— 以内存权重更高（真正受限的资源）。 CPU 与内存都同时看 ：最大 —— 越高越好不过没节点应 overcommit 的节点权重（若已有高占用节点时仍能区分）， 以及全集群均值（均衡负载时区分节点）。

15.12.3.CRS 触发点

CRS 不会每轮对每个服务都重新调度 —— 否则会不断迁移。视负载 ， 不断均衡带来的代价可能比不均衡更大。因此 PVE HA 管理器 偏好保留服务在当前节点。当前触发点：

• 服务恢复（始终启用）：节点故障时把其全部 HA 服务分散到剩余节点。
• HA group 配置变更（始终启用）：节点移出组或优先级降低时 ， 重选目标节点以匹配调整后的优先级约束。
• HA 规则配置变更（始终启用）：
  • 节点亲和规则 ：新建或增加资源 / 节点时 ， 按节点与优先级约束重分配。
  • 正资源亲和 ：新建或添加资源时 ， 把相关资源移到同节点。
  • 负资源亲和 ：新建或添加资源时 ， 把相关资源分到不同节点。
• 停止 → 启动 过渡（可选开启）：请求启动已停服务是按 CRS 找最合适节点的好时机 —— 停止状态下移动比运行中移动更便宜（共享存储上尤为如此）。在 datacenter.cfg / Web Datacenter → Options → Cluster Resource Scheduling 开 ha-rebalance-on-start。