18.1 概述 #
虚拟机在 High Availability 群集中可以充当不同的角色：
虚拟机可作为资源由群集进行管理，群集无需管理虚拟机上运行的服务。在这种情况下，VM 对于群集是不透明的。本文中所述的便是这种场景。
虚拟机可以是群集资源并运行
pacemaker_remote，这样群集便能管理虚拟机上运行的服务。在这种情况下，VM 是 guest 节点，对群集是透明的。对于这种场景，请参见第 4 节 “用例 2：设置包含 Guest 节点的群集”。虚拟机可以运行完整的群集堆栈。在这种情况下，VM 是常规群集节点，不是受群集管理的资源。对于这种场景，请参见安装和设置快速入门。
以下过程介绍了如何在块存储设备上设置高度可用的虚拟机，并将另一个块设备用作 OCFS2 卷来存储 VM 锁文件和 XML 配置文件。虚拟机和 OCFS2 卷配置为由群集管理的资源，并具有资源约束，以确保虚拟机在任何节点上启动之前，锁文件目录始终可用。这样可以防止虚拟机在多个节点上启动。
18.2 要求 #
一个正在运行的 High Availability 群集，该群集至少包含两个节点和一个隔离设备（如 SBD）。
群集节点之间采用无口令
rootSSH 登录方式。每个群集节点上都设置了网桥，用于安装和运行 VM。网桥必须与用于群集通讯和管理的网络分开。
两个或多个共享存储设备（或单个共享设备上的多个分区），以便所有群集节点都可以访问 VM 所需的文件和存储空间：
用作 OCFS2 卷的设备，用于存储 VM 锁文件和 XML 配置文件。下面的过程介绍了如何创建和挂载 OCFS2 卷。
包含 VM 安装源（例如 ISO 文件或磁盘映像）的设备。
根据安装源的不同，可能还需要另一个设备作为 VM 存储磁盘。
为避免 I/O 速度过慢，这些设备必须与用于 SBD 的共享设备分开。
所有存储路径的稳定设备名称，例如
/dev/disk/by-id/DEVICE_ID。同一个共享存储设备在不同的节点上可能会使用不一致的/dev/sdX名称，这会导致 VM 迁移失败。
18.3 配置群集资源以管理锁文件 #
按照下面的过程配置群集以管理虚拟机锁文件。在所有节点上都必须可以使用锁文件目录，这样无论 VM 在哪个节点上运行，群集都能识别锁文件。
您只需在其中一个群集节点上运行以下命令。
在其中一个共享存储设备上创建 OCFS2 卷：
#mkfs.ocfs2 /dev/disk/by-id/DEVICE_ID运行
crm configure启动crm交互式外壳。为 DLM 创建原始资源：
crm(live)configure#primitive dlm ocf:pacemaker:controld \ op monitor interval=60 timeout=60为 OCFS2 卷创建原始资源：
crm(live)configure#primitive ocfs2 Filesystem \ params device="/dev/disk/by-id/DEVICE_ID" directory="/mnt/shared" fstype=ocfs2 \ op monitor interval=20 timeout=40为 DLM 和 OCFS2 资源创建组：
crm(live)configure#group g-virt-lock dlm ocfs2克隆该组，使它在所有节点上运行：
crm(live)configure#clone cl-virt-lock g-virt-lock \ meta interleave=true使用
show查看所做的更改。如果所有设置均正确无误，请使用
commit提交更改，然后使用quit退出 crm 实时配置。检查组克隆的状态。它在所有节点上都应处于运行状态：
#crm status[...] Full List of Resources: [...] * Clone Set: cl-virt-lock [g-virt-lock]: * Started: [ alice bob ]
18.4 准备群集节点以托管虚拟机 #
按照下面的过程安装和启动所需的虚拟化服务，并将节点配置为将 VM 锁文件存储在共享的 OCFS2 卷上。
此过程使用 crm cluster run 同时在所有节点上运行命令。如果您更喜欢单独管理每个节点，可以省略命令的 crm cluster run 部分。
在群集中的所有节点上安装虚拟化软件包：
#crm cluster run "zypper install -y -t pattern kvm_server kvm_tools"在一个节点上的
/etc/libvirt/qemu.conf文件中，找到并启用lock_manager设置：lock_manager = "lockd"
在同一节点上的
/etc/libvirt/qemu-lockd.conf文件中，找到并启用file_lockspace_dir设置，然后将值更改为指向 OCFS2 卷上的目录：file_lockspace_dir = "/mnt/shared/lockd"
将这些文件复制到群集中的其他节点：
#crm cluster copy /etc/libvirt/qemu.conf#crm cluster copy /etc/libvirt/qemu-lockd.conf在群集中的所有节点上启用并启动
libvirtd服务：#crm cluster run "systemctl enable --now libvirtd"这也会启动
virtlockd服务。
18.5 将虚拟机添加为群集资源 #
按照下面的过程将虚拟机作为群集资源添加到群集，并设置资源限制，以确保 VM 始终可以访问锁文件。锁文件由组 g-virt-lock 中的资源管理，通过克隆 cl-virt-lock 可在所有节点上使用该组。
在其中一个群集节点上安装虚拟机，但需符合以下限制：
安装源和存储区必须位于共享设备上。
不要将 VM 配置为在主机引导时启动。
有关详细信息，请参见 Virtualization Guide for SUSE Linux Enterprise Server。
如果虚拟机正在运行，请将其关闭。将 VM 添加为资源后，群集将启动 VM。
将 XML 配置转储到 OCFS2 卷。对每个 VM 重复此步骤：
#virsh dumpxml VM1 > /mnt/shared/VM1.xml
确保 XML 文件不包含对未共享本地路径的任何引用。
运行
crm configure启动crm交互式外壳。创建原始资源来管理虚拟机。对每个 VM 重复此步骤：
crm(live)configure#primitive VM1 VirtualDomain \ params config="/mnt/shared/VM1.xml" remoteuri="qemu+ssh://%n/system" \ meta allow-migrate=true \ op monitor timeout=30s interval=10s选项
allow-migrate=true可启用实时迁移。如果其值设置为false，群集会迁移 VM，具体做法是在一个节点上关闭 VM，然后在另一个节点上重启动该 VM。如果需要设置利用率属性，以帮助系统根据 VM 的负载影响放置 VM，请参见第 7.10 节 “根据资源负载影响放置资源”。
创建共置约束，使虚拟机只能在正在运行
cl-virt-lock的节点上启动：crm(live)configure#colocation col-fs-virt inf: ( VM1 VM2 VMX ) cl-virt-lock创建顺序约束，使
cl-virt-lock始终先于虚拟机启动：crm(live)configure#order o-fs-virt Mandatory: cl-virt-lock ( VM1 VM2 VMX )使用
show查看所做的更改。如果所有设置均正确无误，请使用
commit提交更改，然后使用quit退出 crm 实时配置。检查虚拟机的状态：
#crm status[...] Full List of Resources: [...] * Clone Set: cl-virt-lock [g-virt-lock]: * Started: [ alice bob ] * VM1 (ocf::heartbeat:VirtualDomain): Started alice * VM2 (ocf::heartbeat:VirtualDomain): Started alice * VMX (ocf::heartbeat:VirtualDomain): Started alice
虚拟机现在由 High Availability 群集管理，并且可以在群集节点之间迁移。
将虚拟机添加为群集资源后，请勿手动管理它们，应仅使用第 8 章 “管理群集资源”中所述的群集工具来管理。
要在群集管理的 VM 上执行维护任务，请参见第 28.2 节 “用于维护任务的不同选项”。
18.6 测试设置 #
执行以下测试来确认虚拟机 High Availability 设置是否按预期工作。
请在测试环境而非生产环境中执行这些测试。
虚拟机
VM1正在节点alice上运行在节点
bob上，尝试使用virsh start VM1手动启动该 VM。预期结果：
virsh命令会失败。当VM1正在alice上运行时，无法在bob上手动启动该 VM。
虚拟机
VM1正在节点alice上运行打开两个终端。
在第一个终端中，通过 SSH 连接到
VM1。在第二个终端中，尝试使用
crm resource move VM1 bob将VM1迁移到节点bob。运行
crm_mon -r监控群集状态，直到其稳定为止。这可能需要一点时间。在第一个终端中，检查与
VM1的 SSH 连接是否仍处于活动状态。预期结果：群集状态会显示
VM1已在bob上启动。与VM1的 SSH 连接在整个迁移过程中都会保持活动状态。
虚拟机
VM1正在节点bob上运行重引导
bob。在节点
alice上，运行crm_mon -r监控群集状态，直到其稳定为止。这可能需要一点时间。预期结果：群集状态会显示
VM1已在alice上启动。
虚拟机
VM1正在节点alice上运行在
alice上，通过强制关机或拔下电源线来模拟崩溃。在节点
bob上，运行crm_mon -r监控群集状态，直到其稳定为止。与节点重引导后发生的 VM 迁移相比，节点崩溃后发生的 VM 故障转移通常需要更长的时间。预期结果：不久之后，群集状态会显示
VM1已在bob上启动。