15.4工作原理
本节将详细描述HA管理器的内部工作原理，包括所有服务进程及其协同工作过程。HA在每个节点上都有两个服务进程：
pve-ha-lrm
该服务称为本地资源管理器（LRM），其主要任务是控制本地节点的资源运行状态，首先从当前管理器状态文件读取资源的指定工作状态，然后执行相应的操作命令。
pve-ha-crm
该服务称为集群资源管理器（CRM），其主要任务是负责集群节点之间的协同决策工作，具体包括向LRM发送命令，处理命令执行结果，在出现故障时将资源转移到其他节点运行，此外还负责故障节点隔离。
注意
HA服务利用了集群文件系统提供的锁机制。通过锁机制，确保了每次只有一个LRM被激活并处于工作状态。由于LRM只在获取锁之后才能执行HA任务，我们可以在获取锁之后将故障节点标记为隔离，然后可以在其他节点安全地恢复原来在故障节点运行的HA资源，而无须担心故障节点的干扰。整个过程都在拥有HA管理器主锁的CRM监督下进行。
15.4.1资源状态
CRM使用一个枚举变量来记录当前资源的状态。不仅WebGUI界面有显示当前资源状态，并且你可以运行ha-manager命令行工具获取该状态。
# ha-manager status
quorum OK
master elsa (active, Mon Nov 21 07:23:29 2016)
lrm elsa (active, Mon Nov 21 07:23:22 2016)
service ct:100 (elsa, stopped)
service ct:102 (elsa, started)
service vm:501 (elsa, started)
以下是可能的状态
stopped
资源已停止（LRM确认）。如果LRM检测到应处于停止状态的资源仍然在运行，它将再次停止该资源。
request_stop
资源应被停止。该状态下，CRM将等待LRM确认资源已停止。
stopping
正在挂起的停止请求。表示CRM仍未接到该停止请求。
started
资源处于运行状态，并且LRM应该在发现资源未运行时立刻启动该资源。如果资源因故停止运行，LRM会在检测到后立刻重启它（查看14.8节启动失败策略）。
starting
正在挂起的启动请求。表示CRM未得到LRM对该资源正在运行的确认。
fence
等待节点完成隔离（将节点从集群投票范围内隔离出去）。一旦完成隔离，资源将在其他节点恢复（查看14.7节隔离）。
recovery
等待服务恢复。HA管理器将搜寻可用的节点。此搜索不仅取决于在线的节点和仲裁节点，还要看此服务是否为组成员，以及这个组是否有限制。一旦新的可用节点被发现，服务将移动到此处，并开始置于停止状态。如果被配置为运行在新节点，则会执行这个操作。
freeze
表示禁止访问资源。该状态用于节点重启过程，或LRM重启过程（查看14.10节软件包升级）。
ignored
将虚拟机暂时脱离HA管理。可用于临时人工管控虚拟机，同时保留HA配置不变。
migrate
将资源迁移（在线）到其他节点。
error
因LRM错误，资源被禁用。该状态往往意味着需要手工干预（查看14.9节错误恢复）。
queued
表示资源刚被添加到HA，而CRM尚未确认已看到该资源。
disabled
资源被停止运行，并被标记为disabled。
15.4.2本地资源管理器
本地资源管理器（pve-ha-lrm）以系统服务形式启动。启动后，该服务将等待集群进入多数票状态，以确保集群锁机制正常工作。 该服务有3种状态：
wait for agent lock
表示LRM在等待获取的独占锁。如果未配置任何HA资源，该状态就相当于空闲状态。
active
表示配置了HA资源，并且LRM获得了独占锁。
lost agent lock
表示LRM失去了独占锁，一般意味着有错误发生，并且节点失去了多数票。
LRM进入active状态后，将读取配置文件/etc/pve/ha/manager_status，并根据它所管理的资源判断应该执行的管理命令。每条命令都由一个独立工作进程执行，因此可以并发执行多条命令，但默认最多同时并发执行4条命令。可以修改数据中心配置项max_worker来调整默认并发数。当命令执行完后，工作进程将被回收，执行结果也会被CRM记录保存。
注意： 最大并发调整提示
默认的并发数4不一定适用于所有环境。例如，同时执行4个在线迁移操作可能会导致对网络的竞争使用，特别在物理网络速度较慢或配置了大内存资源时。在任何情况下必须确保避免发生竞争的情况，必要时可以降低max_worker的值。相反，如果你的硬件配置极端牛逼，也可以考虑增加max_worker的值。
CRM发出的每条命令都由一个UID标识，当工作进程完成命令执行后，执行结果将被写入LRM状态文件/etc/pve/nodes/
通常，CRM和LRM对每一个资源的操作都是同步进行的。也就是说，CRM发出一个唯一UID标识的命令，LRM则执行一次该命令并将执行结果写回文件，而执行结果用同一个UID标识。这确保了LRM不会执行过期的命令。但stop命令和error命令是两个例外，这两个命令不依赖于处理结果，并总是在stopped或error状态执行。
注意
HA组件会记录每个操作的日志。这有助于理解集群中发生的事以及发生的原因。这对于了解两个服务进程LRM和CRM干了什么尤为重要。你可以用命令journalctl -u pve-ha-lrm查看资源所在节点的本地资源管理器日志，并用同样命令查看当前主节点的pve-ha-crm服务日志。
15.4.3集群资源管理器
集群资源管理器（pve-ha-crm）在每个节点启动后，将进入等待状态直到获取管理器锁。管理器锁每次只能由一个节点获取，而成功获取该锁的节点将被提升为CRM主节点。
该服务有3种状态：
wait for agent lock
表示CRM在等待获取的独占锁。如果未配置任何HA资源，该状态就相当于空闲状态。
active
表示配置了HA资源，并且CRM获得了独占锁。
lost agent lock
表示CRM失去了独占锁，一般意味着有错误发生，并且节点失去了多数票。
CRM的主要任务是管理那些纳入HA管理的资源，并尽力确保资源处于指定的状态。例如，对于一个指定状态为started的资源，一旦被发现未运行就会立刻被启动，如果资源意外崩溃，也会被自动重启。而CRM将负责告诉LRM具体进行哪些操作。
一个节点失去集群多数票后，会进入unknown状态。此时，如果CRM能够安全释放故障节点的锁，相关资源将会被转移到其他节点重新启动。
当集群节点判定自己不再拥有集群多数票后，LRM将等待新的多数票形成。只要没能形成多数票，节点就无法重置看门狗，最终看门狗超时后会触发节点重启，看门狗默认超时时间为60秒。