Azure 服务总线异地灾难恢复

可以使用服务总线地理灾难恢复功能来保护 Azure 服务总线应用程序免受中断和灾祸的影响。 它有助于保持复合应用程序配置的完整性。

注意

此功能适用于 Azure 服务总线的高级层级。

Geo-Disaster 恢复功能持续将主命名空间的整个配置（实体、配置、属性）复制到辅助配对命名空间。 您可以在任何时候启动一次性故障转移，将主数据库切换到辅助数据库。 故障切换操作会将命名空间的所选别名重新指向辅助命名空间，然后中断配对。 故障转移几乎是启动后立即发生的。

与 Geo-Replication 的比较

Azure 服务总线为地理复原能力提供两种功能：异地复制和异地灾难恢复。 主要区别在于，Geo-Replication 复制元数据和数据（消息、消息状态、属性更改），而 Geo-Disaster 恢复仅复制元数据。 对于大多数灾难恢复方案，建议选择 Geo-Replication。 有关详细比较，请参阅 Azure 服务总线的可靠性 - 对区域范围的故障的复原能力。

考虑的要点

• 此功能可实现相同配置的操作的即时连续性，但不会复制在队列或主题订阅中保存的消息，也不会复制死信队列中的消息。 为了保留队列语义，此类复制不仅需要复制消息数据，还需要中转站中的每个状态更改。 此复制在 Geo-Replication 功能中提供。
• 对主命名空间中的服务总线实体进行的 Microsoft Entra 基于角色的访问控制 (RBAC) 分配不会复制到辅助命名空间。 在辅助命名空间中手动创建角色分配，以保护对它们的访问。
• 不会复制以下配置：
  • 虚拟网络配置
  • 专用终结点连接
  • 已启用所有网络访问
  • 已启用受信任的服务访问
  • 公用网络访问
  • 默认网络操作
  • 标识和加密设置（客户管理的密钥加密，或自带密钥 (BYOK) 加密）
  • 启用自动缩放
  • 禁用本地身份验证
  • Azure 事件网格订阅
• 不支持将 分区命名空间 与非分区命名空间配对。
• 如果为实体启用 AutoDeleteOnIdle ，则发生故障转移时，该实体可能不存在于辅助命名空间中。 当辅助数据库成为主要副本时，最后一个访问状态（不是元数据的一部分）对新主数据库不可用，并且实体可能会作为清理的 AutoDeleteOnIdle 一部分删除。

提示

若要在主动/主动配置中复制队列和主题订阅的内容，并操作相应的命名空间，以应对中断和灾难，请不要依赖于此 Geo-Disaster Recovery 功能集。 请改用 Geo-Replication 功能 或遵循 复制指南。

基本概念和术语

Geo-Disaster 恢复功能实现元数据灾难恢复，并依赖于主要和辅助灾难恢复命名空间。 异地灾难恢复功能仅适用于高级 SKU。 无需进行任何连接字符串更改，因为连接是通过别名进行的。

本文涉及以下术语：

• 别名：所设置的灾难恢复配置的名称。 别名提供单个稳定的完全限定域名 (FQDN) 连接字符串。 应用程序使用此别名连接字符串连接到命名空间。 使用别名时，连接字符串在故障转移启动时保持不变。

• 主要/次要命名空间：别名所对应的命名空间。 主命名空间 处于活动状态 并接收消息（可以是现有命名空间或新命名空间）。 辅助命名空间是 被动 的，不会接收消息。 这两者之间的元数据保持同步，因此这两者可以无缝接受消息，而不必更改任何应用程序代码或连接字符串。 若要确保只有主动命名空间接收消息，必须使用别名。

• 元数据：队列、主题、订阅等实体及其与命名空间关联的服务的属性。 仅自动复制实体及其设置。 不会复制消息。

• 故障转移：激活辅助命名空间的过程。

设置

以下部分概述了如何在命名空间之间设置配对。

首先，创建或使用现有的主命名空间并创建新的辅助命名空间。 然后，将两个命名空间配对。 此配对提供可用于连接的别名。 由于使用别名，因此，无需更改连接字符串。 只能向您的故障转移配对添加新命名空间。

1. 创建主高级层命名空间。

2. 在另一区域中创建辅助高级层命名空间。 此步骤是可选的。 可以在下一步中创建配对时创建辅助命名空间。

3. 在 Azure 门户中，转到主命名空间。

4. 在左侧菜单中选择 “异地恢复 ”，然后在工具栏中选择“ 启动配对 ”。

   

5. 在 启动配对时，请执行以下步骤：

   1. 选择现有的辅助命名空间，或在不同区域中创建一个。 在此示例中，现有命名空间用作辅助命名空间。

   2. 对于“别名”，请输入异地灾难恢复配对的别名。

   3. 选择 创建。

      

6. 应会看到“服务总线异地灾难恢复别名”页，如下图所示。 还可以通过在左侧菜单中选择“地理恢复”，从主命名空间页导航到“地理灾难恢复别名”页。

   

7. 在 “Geo-DR 别名 ”页上，选择左侧菜单中 的“共享访问策略 ”以访问别名的主连接字符串。 请使用此连接字符串，而不是直接使用连接到主命名空间或辅助命名空间的连接字符串。 最初，别名指向主要命名空间。

8. 切换到“概览”页。 可执行以下操作：

   1. 中断主命名空间和辅助命名空间之间的配对。 在工具栏中选择 “中断配对 ”。
   2. 手动故障转移到辅助命名空间。

      1. 在工具栏中选择 “故障转移 ”。

      2. 通过键入别名来确认要故障转移到辅助命名空间。

      3. 启用“安全故障转移”选项以安全地故障转移到辅助命名空间。

         注意

         • 安全故障转移可确保在切换到辅助命名空间之前完成挂起的异地灾难恢复复制。 而强制或手动故障转移不会等到挂起的复制完成后再切换到辅助命名空间。
         • 目前，如果主命名空间和辅助命名空间不在同一 Azure 订阅中，安全故障转移将失败。

      4. 选择“故障转移”。

         

         重要说明

         故障转移会激活辅助命名空间，并会从异地灾难恢复配对中删除主命名空间。 创建另一个命名空间，以创建新的异地灾难恢复配对。

9. 最后，添加一些监控，以检测是否需要故障转移。 在大多数情况下，该服务是大型生态系统的一部分，因此很少可能自动故障转移，因为通常必须与剩余子系统或基础结构同步执行故障转移。

服务总线标准到高级

如果将 Azure 服务总线标准命名空间迁移到 Azure 服务总线高级版，则必须使用预先存在的别名（服务总线标准命名空间连接字符串）通过 PS/CLI 或 REST API 创建灾难恢复配置。

在迁移期间，Azure 服务总线标准命名空间连接字符串和 DNS 名称将成为 Azure 服务总线高级命名空间的别名。

客户端应用程序必须使用此别名（Azure 服务总线标准命名空间连接字符串）连接到在其中设置灾难恢复配对的高级命名空间。

如果使用 Azure 门户设置灾难恢复配置，门户会为你处理此详细信息。

故障转移流程

客户可以手动触发故障转移（通过显式命令或通过客户端自有的业务逻辑来触发命令）。 Azure 永远不会触发故障转移。 此方法为客户提供对 Azure 主干中断解决的完全所有权和可见性。

故障转移触发后-

1. “别名”连接字符串更新为指向次要高级命名空间。

2. 客户端（发送方和接收方）会自动连接到辅助命名空间。

3. 主要高级命名空间与次要高级命名空间之间的现有配对将被破坏。

在故障转移启动后 -

1. 如果又出现其他中断，则需要能够再次进行故障转移。 因此，请设置另一个辅助命名空间，并更新配对。

2. 一旦以前的主要命名空间恢复可用，请从该命名空间拉取消息。 在此之后，请使用该命名空间在异地灾难恢复设置之外进行常规消息传送，或删除旧的主要命名空间。

注意

仅支持失败转发语义。 使用异地灾难恢复启动故障转移时，可以在故障转移完成后与新命名空间重新配对。 你无法故障恢复到之前的主副本。 这些语义可能与用于的其他数据存储不同，例如Microsoft SQL Server 群集。

可以通过监控系统或自定义监控解决方案来实现自动故障转移。 但是，这种自动执行需要额外的规划和工作，它超出了本文的讨论范围。

管理

如果犯了错误（例如在初始设置期间配对错误区域），可以随时中断两个命名空间的配对。 如果想要使用配对命名空间作为常规命名空间，请删除别名。

使用现有的命名空间作为别名

如果遇到不能更改生产者和使用者连接的情况，则可将命名空间名称作为别名重用。 请参阅此处提供的 GitHub 上的示例代码。

示例

GitHub 上的示例演示如何设置和启动故障转移。 这些示例演示以下概念：

• 在 Microsoft Entra ID 中将 Azure 资源管理器与服务总线配合使用，以及设置和启用异地灾难恢复所需的 .NET 示例和设置。
• 执行示例代码所需的步骤。
• 如何使用现有的命名空间作为别名。
• 改用 PowerShell 或 CLI 启用异地灾难恢复的步骤。
• 使用别名从当前的主要或次要命名空间进行发送和接收。

注意事项

在此版本中，请记住以下注意事项：

• 在故障转移规划中，请考虑时间因素。 例如，如果失去连接的时间超过 15 到 20 分钟，你可能会决定启动故障转移。
• 由于未复制任何数据，因此当前活动会话也不会被复制。 此外，重复检测和计划消息可能无法正常工作。 新会话、新计划消息和新的重复项可以正常工作。
• 应至少对复杂的分布式基础结构进行一次故障转移演练。
• 同步实体可能需要一些时间，每分钟大约 50-100 个实体。 订阅和规则也计为实体。

专用终结点

本部分针对使用专用终结点的命名空间执行异地灾难恢复，提供了更多注意事项。 若要总体了解有关将专用终结点与服务总线一起使用的信息，请参阅将 Azure 服务总线与 Azure 专用链接集成。

新建配对

如果尝试在具有专用终结点的主命名空间与没有专用终结点的辅助命名空间之间创建配对，则配对会失败。 仅当主命名空间和辅助命名空间都具有专用终结点时，配对才会成功。 在主命名空间和辅助命名空间以及在其中创建专用终结点的虚拟网络上使用相同的配置。

注意

尝试将具有专用终结点的主命名空间与某个辅助命名空间配对时，验证过程仅检查辅助命名空间上是否存在专用终结点。 它不会检查在故障转移后终结点是否正常工作或是否将正常工作。 你需要负责确保在故障转移后，具有专用终结点的辅助命名空间能够按预期工作。

若要测试专用终结点配置是否相同，请从虚拟网络外部向辅助命名空间发送获取队列请求，并验证是否收到来自服务的错误消息。

现有配对

如果主命名空间和辅助命名空间之间已存在配对，则主命名空间上的专用终结点创建会失败。 若要解决此错误，请先在辅助命名空间上创建专用终结点，然后为主命名空间创建一个专用终结点。

注意

虽然您可以以只读方式访问辅助命名空间，但可以更新专用终结点配置。

建议的配置

在为应用程序和服务总线创建灾难恢复配置时，必须针对承载应用程序的主实例和辅助实例的虚拟网络，为主要和辅助服务总线命名空间创建专用终结点。

假设有两个虚拟网络：VNET-1 和 VNET-2，以及以下主要命名空间和辅助命名空间。 ServiceBus-Namespace1-PrimaryServiceBus-Namespace2-Secondary 完成以下步骤：

• 打开 ServiceBus-Namespace1-Primary，创建两个专用终结点，该终结点使用 VNET-1 和 VNET-2 中的子网。
• 打开 ServiceBus-Namespace2-Secondary时，创建两个专用终结点，这些终结点使用 VNET-1 和 VNET-2 中的相同子网。

此方法的优点是，故障转移可能发生在独立于服务总线命名空间的应用程序层上。 请考虑下列情形：

仅限应用程序的故障转移：在这里，应用程序不会在 VNET-1 中，而是会移到 VNET-2 中。 由于主命名空间和辅助命名空间的 VNET-1 和 VNET 2 上都同时配置了这两个专用终结点，因此该应用程序将正常工作。

仅限服务总线命名空间的故障转移：此处再次说明，因为在主命名空间和辅助命名空间的两个虚拟网络上都同时配置了这两个专用终结点，因此该应用程序将正常工作。

注意

如需虚拟网络异地灾难恢复的相关指导，请参阅虚拟网络 - 业务连续性。

基于角色的访问控制

对主命名空间中的服务总线实体进行的 Microsoft Entra 基于角色的访问控制 (RBAC) 分配不会复制到辅助命名空间。 在辅助命名空间中手动创建角色分配，以保护对它们的访问。

后续步骤

• 请参阅此处的异地灾难恢复 REST API 参考。
• 在 GitHub 上运行异地灾难恢复示例。
• 请参阅异地灾难恢复将消息发送到别名的示例。

若要了解有关服务总线消息传送的详细信息，请参阅以下文章：

• 服务总线队列、主题和订阅
• 服务总线队列入门
• 如何使用服务总线主题和订阅
• REST API