14.3. 灾难恢复
OpenShift Virtualization 支持使用灾难恢复 (DR) 解决方案来确保您的环境可在站点中断后恢复。要使用这些方法，您必须提前规划 OpenShift Virtualization 部署。
14.3.1. 关于灾难恢复方法
有关灾难恢复(DR)概念、架构和规划注意事项的概述，请参阅红帽知识库中的 Red Hat OpenShift Virtualization 灾难恢复指南。
OpenShift Virtualization 两种主要 DR 方法是 Metropolitan Disaster Recovery (Metro-DR) 和 Regional-DR。
14.3.1.1. Metro-DR
Metro-DR 使用同步复制。它会在主站点和次站点写入存储，以便数据始终在站点间同步。由于存储提供程序负责确保同步成功，环境必须满足存储提供程序的吞吐量和延迟要求。
14.3.1.2. Regional-DR
Regional-DR 使用异步复制。主站点中的数据会定期与二级站点同步。对于这种类型的复制，您可以在主站点和次站点之间具有更高的延迟连接。
14.3.2. 为灾难恢复定义应用程序
使用 Red Hat Advanced Cluster Management (RHACM) 管理或发现的虚拟机为灾难恢复定义应用程序。
14.3.2.1. 定义 RHACM 管理的虚拟机时的最佳实践
必须使用 GitOps 工作流和创建 RHACM 应用程序或 ApplicationSet 来创建包含虚拟机的 RHACM 管理的应用程序。
在定义 RHACM 管理虚拟机时，您可以采取几个操作来改进您的体验和成功的机会。
使用 PVC 和填充器为虚拟机定义存储
因为数据卷隐式创建持久性卷声明 (PVC)，所以带有数据卷模板的数据卷和虚拟机不适合 GitOps 模型。
在为您的虚拟机磁盘选择填充源时使用导入方法
从软件目录中选择一个 RHEL 镜像以使用导入方法。红帽建议使用特定版本的镜像而不是浮动标签来获得一致的结果。KubeVirt 社区为 Quay 存储库中的其他操作系统维护容器磁盘。
使用 pullMethod: node
从 registry 源创建数据卷时使用 pod pullMethod: node，以利用 OpenShift Container Platform pull secret，这是从 Red Hat registry 中拉取容器镜像所必需的。
14.3.2.2. 定义 RHACM 发现的虚拟机时的最佳实践
您可以将不是 RHACM 管理的应用程序的任何虚拟机配置为 RHACM 发现的应用程序。这包括使用 Migration Toolkit for Virtualization (MTV)、使用 OpenShift Virtualization web 控制台创建的虚拟机或由任何其他方法创建的虚拟机（如 CLI）导入的虚拟机。
在定义 RHACM 发现的虚拟机时，您可以采取几个操作来改进您的体验和成功的机会。
在使用 MTV、OpenShift Virtualization web 控制台或自定义虚拟机时保护虚拟机
因为当前还不可用自动标记，应用程序所有者必须在使用 MTV、OpenShift Virtualization web 控制台或自定义虚拟机时手动标记虚拟机应用程序的组件。
创建虚拟机后，将 common 标签应用到与虚拟机关联的以下资源： VirtualMachine,DataVolume,PersistentVolumeClaim,Service,Route,Secret,ConfigMap,VirtualMachinePreference, 和 VirtualMachineInstancetype。不要标记虚拟机实例(VMI)或 pod；OpenShift Virtualization 会自动创建和管理它们。
您必须将 common 标签应用到您要保护的命名空间中的所有内容，包括添加到此处未列出的虚拟机的对象。
在虚拟机中包含多于 VirtualMachine 对象
工作虚拟机通常还包含数据卷、持久性卷声明(PVC)、服务、路由、secret、ConfigMap 对象和 VirtualMachineSnapshot 对象。
将虚拟机作为较大逻辑应用程序的一部分包含
这包括其他基于 pod 的工作负载和虚拟机。
14.3.3. 在灾难恢复场景中虚拟机行为
在重新定位和故障转移灾难恢复流程中，虚拟机通常会与基于 pod 的工作负载类似。
重新定位
当主环境仍可访问时，使用重新定位将应用程序从主环境移到二级环境中。在重新定位过程中，虚拟机可以安全地终止，任何未复制的数据都会同步到二级环境中，虚拟机在二级环境中启动。
由于虚拟机安全终止，因此没有数据丢失。因此，虚拟机操作系统不会执行崩溃恢复。
故障切换
当主环境中出现关键故障时，请使用故障转移，使其不现实或使用重新定位将工作负载移到二级环境中。当执行故障转移时，存储从主环境中隔离，到虚拟机磁盘的 I/O 会完全停止，虚拟机使用复制的数据在次要环境中重新启动。
您应该预期因为故障转移而造成的数据丢失。丢失的程度取决于您是否使用 Metro-DR，它使用同步复制，或 Regional-DR （使用异步复制）。因为 Regional-DR 使用基于快照的复制间隔，所以数据丢失的窗口与复制间隔长度成比例。当虚拟机重启时，操作系统可能会执行崩溃恢复。
14.3.4. 红帽受管集群的灾难恢复解决方案
以下 DR 解决方案组合 Red Hat Advanced Cluster Management (RHACM)、Red Hat Ceph Storage 和 OpenShift Data Foundation 组件。您可以使用它们将应用程序从主站点故障转移到次要站点，并在恢复灾难恢复站点后将应用程序重新重新定位到主站点。
14.3.4.1. Red Hat OpenShift Data Foundation 的 Metro-DR
OpenShift Virtualization 支持 OpenShift Data Foundation 的 Metro-DR 解决方案，它在主站点和次要站点上安装的受管 OpenShift Virtualization 集群之间提供双向数据复制。
Metro-DR 的不同
- 此同步解决方案仅适用于满足时钟数据中心，网络往返延迟为 10 毫秒或更小。
- 支持多个磁盘虚拟机。
要防止数据崩溃，您必须确保在故障切换过程中隔离存储。
提示隔离意味着隔离节点，以便工作负载不会在其上运行。
有关在 OpenShift Virtualization 中使用 OpenShift Data Foundation 的 Metro-DR 解决方案的更多信息，请参阅 IBM 的 OpenShift Data Foundation Metro-DR 文档。
14.3.4.2. 用于 Red Hat OpenShift Data Foundation 的 Region-DR
OpenShift Virtualization 支持 OpenShift Data Foundation 的 Regional-DR 解决方案，它会在主站点和次要站点上安装的受管 OpenShift Virtualization 集群之间定期提供异步数据复制。
Regional-DR 的不同
- Regional-DR 支持主站点和次要站点之间的更高的网络延迟。
- Regional-DR 使用 RBD 快照异步复制数据。目前，您的应用程序必须可以应对虚拟机磁盘之间的小差异。您可以使用单个磁盘虚拟机来防止这些差异。
-
建议使用导入方法为您的虚拟机磁盘选择填充源。但是，如果您选择一个启用了镜像扁平化的
VolumeReplicationClass，您可以保护使用克隆的 PVC 的虚拟机。如需更多信息，请参阅 OpenShift Data Foundation 文档。
有关在 OpenShift Virtualization 中使用 OpenShift Data Foundation 的 Regional-DR 解决方案的更多信息，请参阅 IBM 的 OpenShift Data Foundation Regional-DR 文档。
