如何使用 Azure Site Recovery (ASR) 复制使用 SIOS DataKeeper 进行群集存储的 Windows Server 故障转移群集 (WSFC)

介绍

因此，您已经在 Azure 中构建了一个 SQL Server 故障转移集群实例 (FCI)，或者可能是一个 SAP ASCS/ERS 集群。 集群的每个节点都驻留在不同的可用区 (AZ) 中，或者您可能有严格的延迟要求并且正在使用 Placement Proximity Group (PPG) 并且您的节点都驻留在同一个可用性集中。 无论在哪种情况下，您的关键业务应用程序现在都比仅运行单个实例具有更高级别的可用性。

现在你有高可用性 (HA)覆盖，你要做什么灾难恢复? 夺走多个 AZ 的区域性灾难很少见，但正如最近的历史向我们展示的那样，大自然母亲真的可以打出一记重拳。 如果整个区域离线，您需要做好准备。

Azure Site Recovery (ASR) 是 Microsoft 的灾难恢复即服务 (DRaaS) 产品，可让您将整个 VM 从一个区域复制到另一个区域。 它还可以将虚拟机和物理服务器从本地复制到 Azure，但在本博文中，我们将重点介绍 Azure 区域到区域的 DR 功能。

设置 Azure Site Recovery

我们将假设您已经使用SIOS 数据保持器. 如果没有，这里有一些提示可以帮助您入门。

Azure VM 上使用 SQL Server 的故障转移群集实例SAP ASCS/SCS 集群共享磁盘的 SIOS DataKeeper Cluster Edition我们还将假设您熟悉 Azure Site Recovery。 我建议您阅读最新的，而不是另一个关于设置 ASR 的指南文件来自微软。 本文将重点介绍您可能没有考虑过的一些事情，以及在故障转移到不同子网后修复集群所需的具体步骤。

配对区域

在开始 DR 路径之前，您应该了解 Azure 配对区域的概念。 Azure 中的每个区域都有一个首选 DR 区域。 如果您想了解有关配对区域的更多信息，请参阅文件提供了很好的背景。 有一些真的很好好处使用您的配对区域，但实际上由您决定要使用哪个区域来托管您的 DR 站点。

云见证位置

当您最初构建集群时，您必须为您的仲裁选择见证类型。 您可能选择了文件共享见证或云见证。 通常，这些见证类型中的任何一种都应位于与集群节点分开的 AZ 中。

但是，当您考虑到在发生灾难时，您的整个集群将在您的 DR 区域中运行时，有一个更好的选择。 您应该使用云见证，并将其放置在您的 DR 区域中。 通过将云见证放置在 DR 区域中，您不仅可以为本地 AZ 故障提供弹性，还可以在整个区域发生故障并且您必须使用 ASR 来恢复 DR 区域中的集群时为您提供保护。 通过 Dynamic Quorum 和 Dynamic Witness 的魔力，您可以确定即使您的 DR 区域暂时下线，也不会影响您的生产集群。

多虚拟机一致性

使用 ASR 复制集群时，启用多虚拟机一致性确保每个集群节点的恢复点来自同一时间点。 这确保了虚拟机之间发生的 DataKeeper 块级复制将能够在恢复后继续进行，而无需完全重新同步。

崩溃一致性恢复点

复制集群中不支持应用程序一致的恢复点。 配置 ASR 复制选项时，不要启用应用程序一致的恢复点。

故障转移后保留 IP 地址？

使用 ASR 复制到 DR 站点时，有一种方法可以保持 VM 的 IP 地址相同。 微软在题为“在故障转移期间保留 IP 地址. 如果您可以在故障转移后保持 IP 地址不变，它将简化恢复过程，因为您不必修复任何基于 IP 地址的集群 IP 地址或 DataKeeper 镜像端点。

但是，根据我的经验，我从未见过有人真正遵循上述指导，因此在不同子网中恢复集群需要在恢复后执行一些额外步骤，然后才能使集群联机。

您的第一次故障转移尝试

恢复计划

由于您使用的是多虚拟机一致性，因此您必须使用恢复计划对虚拟机进行故障转移。 这文件提供了关于如何做到这一点的非常简单的指导。 恢复计划将要恢复的 VM 分组在一起，以确保它们一起进行故障转移。 您甚至可以将多组虚拟机添加到同一个恢复计划中，以确保您的整个基础架构以有序的方式进行故障转移。

恢复计划还可以启动恢复后脚本以帮助故障转移成功完成恢复。 我在下面描述的步骤都可以作为您的恢复计划的一部分编写出来，从而使整个恢复过程完全自动化。 我们不会在这篇博文中介绍该过程，但 Microsoft记录这个过程.

静态 IP 地址

作为恢复过程的一部分，您需要确保新 VM 具有静态 IP 地址。 您必须调整 Azure 门户中的接口属性，以便 VM 始终使用相同的地址。 如果您想向接口添加公共 IP 地址，此时您也应该这样做。

网络配置

在 DR 站点中成功恢复复制的 VM 后，您要做的第一件事是验证基本连接。 IP 配置是否正确？ 实例是否使用正确的 DNS 服务器？ 名称解析是否正常运行？ 你能ping通远程服务器吗？

如果网络通信有任何问题，那么下面描述的其余步骤必然会失败。 不要跳过这一步！

负载均衡器

您可能知道，Azure 中的集群需要您配置负载均衡器才能使客户端连接正常工作。 负载平衡器不会作为恢复计划的一部分进行故障转移。 您需要基于现在驻留在这个新 vNet 中的集群构建一个新的负载均衡器。 您可以手动执行此操作，也可以将其作为恢复计划的一部分自动执行。

网络安全组

在这个新子网中运行还意味着您必须指定要应用于这些实例的网络安全组。 您必须确保实例能够通过所需端口进行通信。 同样，您可以手动执行此操作，但最好将其编写为您的恢复计划的一部分。

修复 IP 集群地址

如果您无法进行前面描述的更改以恢复同一子网中的实例，则必须完成以下步骤来更新集群 IP 地址和 DataKeeper 地址以在新子网中使用。

每个集群都有一个核心集群 IP 地址。 如果在故障转移后启动 WSFC UI，您将看到集群将无法连接。 这是因为集群使用的 IP 地址在新子网中无效。

如果您打开该 IP 地址资源的属性，您可以将 IP 地址更改为可在新子网中使用的地址。 确保同时更新网络和子网掩码。

修复该 IP 地址后，您将必须对您在集群资源中使用的任何其他集群地址执行相同的操作。

修复 DataKeeper 镜像地址

SIOS DataKeeper 镜像使用 IP 地址作为镜像端点。 这些存储在镜像和镜像作业中。 如果您在不同的子网中恢复基于 DataKeeper 的集群，您将看到镜像处于 Resync Pending 状态。 您还会注意到源 IP 和目标 IP 反映的是原始子网，而不是 DR 站点的子网。

解决此问题需要从 SIOS 运行一个名为CHANGEMIRRENDPOS . CHANGEMIRRORENDPOINTS 的用法如下。

emcmd <NEW source IP> CHANGEMIRRORENDPOINTS <volume letter> <ORIGINAL target IP> <NEW source IP> <NEW target IP> 在我们的示例中，命令和输出如下所示。

命令运行后，DataKeeper GUI 将更新以反映新的 IP 地址，如下所示。 镜像也将进入镜像状态。

结论

您现在已经成功地配置和测试了关键业务应用程序的灾难恢复，结合使用 SIOS DataKeeper 实现高可用性和 Azure Site Recovery 实现灾难恢复。 如果您有任何疑问，或者想咨询 SIOS 以帮助您为 SQL Server、SAP ASCS 和 ERS、SAP HANA、Oracle 或其他关键业务应用程序等关键业务应用程序设计和实施高可用性和灾难恢复，请联系我们.