Azure 服务总线异地灾难恢复
服务总线异地灾难恢复功能是隔离 Azure 服务总线应用程序免受中断和灾难的选项之一，主要目的是帮助保持复合应用程序配置的完整性。
注意
此功能适用于 Azure 服务总线的高级层级。
异地灾难恢复功能可确保命名空间（事件中心、使用者组和设置）的整个配置在配对后能够从主命名空间连续复制到辅助命名空间，并允许你随时启动从主命名空间到辅助命名空间的一次性故障转移。 故障转移移动会将命名空间的所选别名重新指向辅助命名空间，然后中断配对。 故障转移几乎是启动后立即发生的。
考虑的要点
此功能支持具有相同配置的操作的即时连续性，但不会复制保存在队列或主题订阅或死信队列中的消息。
对主命名空间中的服务总线实体进行的 Microsoft Entra 基于角色的访问控制 (RBAC) 分配不会复制到辅助命名空间。 在次要命名空间中手动创建角色分配，以保护对它们的访问。
不会复制以下配置。
- 虚拟网络配置
- 专用终结点连接
- 已启用所有网络访问
- 已启用受信任的服务访问
- 公用网络访问
- 默认网络操作
- 标识和加密设置（客户管理的密钥加密，或自带密钥 (BYOK) 加密）
- 启用自动缩放
- 禁用本地身份验证
- Azure 事件网格订阅
如果为某个实体启用了
AutoDeleteOnIdle，则当发生故障转移时，该实体可能不会出现在辅助命名空间中。 当辅助数据库成为主数据库时，最后的访问状态（不是元数据的一部分）将不会提供给新的主数据库，并且实体可能会在AutoDeleteOnIdle清理过程中被删除。
提示
若要复制队列和主题订阅的内容，并在主动/主动配置中操作相应的命名空间来应对中断和灾难，请不要依赖此异地灾难恢复功能集，而是要按照复制指南进行操作。
基本概念和术语
异地灾难恢复功能可实现元数据灾难恢复，并且依赖于主要和辅助灾难恢复命名空间。 异地灾难恢复功能仅适用于高级 SKU。 不需要对连接字符串进行任何更改，因为连接是通过别名建立的。
本文涉及以下术语：
别名：所设置的灾难恢复配置的名称。 别名提供单个稳定的完全限定域名 (FQDN) 连接字符串。 应用程序使用此别名连接字符串连接到命名空间。 使用别名可确保连接字符串在触发故障转移后保持不变。
主要/次要命名空间：别名所对应的命名空间。 主要命名空间是“主动”的，会接收消息（它可以是现有的命名空间，也可以是新的命名空间）。 次要命名空间是“被动”的，不接收消息。 这两者之间的元数据保持同步，因此这两者可以无缝接受消息，而不必更改任何应用程序代码或连接字符串。 若要确保只有主动命名空间接收消息，必须使用别名。
元数据：队列、主题、订阅等实体及其与命名空间关联的服务的属性。 仅自动复制实体及其设置。 不会复制消息。
故障转移：激活辅助命名空间的过程。
设置
以下部分概述了命名空间之间的设置配对。
首先，创建一个主要命名空间或使用现有的主要命名空间，并创建一个新的次要命名空间，然后将两者配对。 此配对提供可用于连接的别名。 由于使用别名，因此，无需更改连接字符串。 只有新的命名空间可以添加到故障转移配对。
创建主高级层命名空间。
在另一区域中创建辅助高级层命名空间。 此步骤是可选的。 可以在下一步中创建配对时创建辅助命名空间。
在 Azure 门户中，导航到你的主命名空间。
在左侧菜单中选择“异地恢复”，然后在工具栏中选择“启动配对”。
在“启动配对”页上执行以下步骤：
选择现有的辅助命名空间，或在不同区域中创建一个。 在此示例中，现有命名空间用作辅助命名空间。
对于“别名”，请输入异地灾难恢复配对的别名。
然后选择“创建”。
应会看到“服务总线异地灾难恢复别名”页，如下图所示。 此外，还可以通过在左侧菜单中选择“异地恢复”，从主命名空间页导航到“异地灾难恢复别名”页。
在“异地灾难恢复别名”页上，在左侧菜单上选择“共享访问策略”来访问该别名的主连接字符串。 使用此连接字符串，而不是直接使用主/辅助命名空间的连接字符串。 最初，别名指向主要命名空间。
切换到“概览”页。 可以执行以下操作：
- 中断主命名空间和辅助命名空间之间的配对。 在工具栏上选择“中断配对”。
- 手动故障转移到辅助命名空间。
在工具栏上选择“故障转移”。
通过键入别名来确认要故障转移到辅助命名空间。
启用“安全故障转移”选项以安全地故障转移到辅助命名空间。
注意
- 安全故障转移可确保在切换到辅助命名空间之前完成挂起的异地灾难恢复复制。 而强制或手动故障转移不会等到挂起的复制完成后再切换到辅助命名空间。
- 目前，如果主命名空间和辅助命名空间不在同一 Azure 订阅中，安全故障转移将失败。
然后选择“故障转移”。
重要
故障转移会激活辅助命名空间，并会从异地灾难恢复配对中删除主命名空间。 创建另一个命名空间，以创建新的异地灾难恢复配对。
最后，应添加一些监视功能，以检测是否有必要进行故障转移。 在大多数情况下，服务是一个大型生态系统的一部分，因此很少会发生自动故障转移，因为通常故障转移必须在与剩余子系统或基础结构保持同步的情况下进行。
服务总线标准到高级
如果已将 Azure 服务总线标准命名空间迁移到 Azure 服务总线高级命名空间，则必须使用预先存在的别名（即服务总线标准命名空间连接字符串）通过 PS/CLI 或 REST API 创建灾难恢复配置。
这是因为，在迁移过程中，Azure 服务总线标准命名空间连接字符串/DNS 名称本身会成为 Azure 服务总线高级命名空间的别名。
客户端应用程序必须利用此别名（即 Azure 服务总线标准命名空间连接字符串）连接到已设置灾难恢复配对的高级命名空间。
如果使用 Azure 门户来设置灾难恢复配置，则由你在门户中提供此注意事项。
故障转移流程
故障转移由客户手动触发（通过命令显式触发，或者通过客户拥有的触发了该命令的业务逻辑），从不会由 Azure 触发。 这为客户提供了对 Azure 主干的中断解决方法的完整所有权和可见性。
在故障转移触发后 -
“别名”连接字符串更新为指向次要高级命名空间。
客户端（发送方和接收方）会自动连接到辅助命名空间。
主要高级命名空间与次要高级命名空间之间的现有配对将被破坏。
在故障转移启动后 -
如果又出现其他中断，则需要能够再次进行故障转移。 因此，请设置另一个辅助命名空间，并更新配对。
一旦以前的主要命名空间恢复可用，请从该命名空间拉取消息。 在此之后，请使用该命名空间在异地灾难恢复设置之外进行常规消息传送，或删除旧的主要命名空间。
注意
仅支持失败转发语义。 在此方案中，先进行故障转移，然后与新的命名空间重新配对。 不支持故障后恢复；例如，在 SQL 群集中不支持此功能。
可以使用监视系统或定制监视解决方案自动执行故障转移。 但是，这种自动执行需要额外的规划和工作，它超出了本文的讨论范围。
管理
如果出了错，例如在初始设置过程中将错误的区域配对，则随时可以中断这两个命名空间的配对。 如果想要使用配对命名空间作为常规命名空间，请删除别名。
使用现有的命名空间作为别名
如果遇到不能更改生产者和使用者连接的情况，则可将命名空间名称作为别名重用。 请参阅此处提供的 GitHub 上的示例代码。
示例
GitHub 上的示例演示如何设置和启动故障转移。 这些示例演示以下概念：
- 在 Microsoft Entra ID 中将 Azure 资源管理器与服务总线配合使用，以及设置和启用异地灾难恢复所需的 .NET 示例和设置。
- 执行示例代码所需的步骤。
- 如何使用现有的命名空间作为别名。
- 改用 PowerShell 或 CLI 启用异地灾难恢复的步骤。
- 使用别名从当前的主要或次要命名空间进行发送和接收。
注意事项
此版本需要注意以下事项：
- 在故障转移规划中，还应考虑时间因素。 例如，如果失去连接的时间超过 15 到 20 分钟，你可能会决定启动故障转移。
- 未复制数据是指未复制当前处于活动状态的会话。 此外，重复检测和计划消息可能无法正常工作。 新会话、新计划消息和新的重复项可以正常工作。
- 故障转移复杂的分布式基础结构应至少演练一次。
- 同步实体可能需要一些时间，每分钟大约 50-100 个实体。 订阅和规则也计为实体。
可用性区域
服务总线高级 SKU 支持可用性区域，在同一 Azure 区域内提供故障隔离位置。 服务总线管理消息存储的三个副本（1 个主副本和 2 个辅助副本）。 服务总线使所有这三个副本保持同步，以用于数据和管理操作。 如果主副本发生故障，则可将其中一个辅助副本提升为主副本，而不会产生故障时间。 如果应用程序发现服务总线有暂时性中断，则 SDK 中的重试逻辑将自动重新连接到服务总线。
使用可用性区域时，将在该可用性区域中的数据中心之间复制元数据和数据（消息）。
注意
Azure 服务总线高级版的可用性区域支持仅适用于存在可用性区域的 Azure 区域。
通过门户创建高级层命名空间时，将自动为命名空间启用对可用性区域（如果在所选区域中可用）的支持。 通过其他机制（例如 ARM/Bicep 模板、CLI 或 PowerShell）创建高级层命名空间时，需要将属性 zoneRedundant 显式设置为 true 才能启用可用性区域（如果在所选区域中可用）。 使用此功能不会产生额外费用，在创建命名空间后，你无法禁用或启用此功能。
专用终结点
本部分针对使用专用终结点的命名空间执行异地灾难恢复，提供了更多注意事项。 若要总体了解有关将专用终结点与服务总线一起使用的信息，请参阅将 Azure 服务总线与 Azure 专用链接集成。
新建配对
如果尝试在具有专用终结点的主命名空间与没有专用终结点的辅助命名空间之间创建配对，则配对会失败。 仅当主命名空间和辅助命名空间都具有专用终结点时，配对才会成功。 建议在主命名空间和辅助命名空间以及创建了专用终结点的虚拟网络上使用相同的配置。
注意
尝试将具有专用终结点的主命名空间与某个辅助命名空间配对时，验证过程仅检查辅助命名空间上是否存在专用终结点。 它不会检查在故障转移后终结点是否正常工作或是否将正常工作。 你需要负责确保在故障转移后，具有专用终结点的辅助命名空间能够按预期工作。
若要测试专用终结点配置是否相同，请从虚拟网络外部向辅助命名空间发送获取队列请求，并验证是否收到来自服务的错误消息。
现有配对
如果主命名空间和辅助命名空间之间已存在配对，则在主命名空间中创建专用终结点的操作会失败。 若要解决此问题，请首先在辅助命名空间上创建专用终结点，然后为主命名空间创建专用终结点。
注意
尽管我们允许对辅助命名空间进行只读访问，但也允许对专用终结点配置进行更新。
建议配置
在为应用程序和服务总线创建灾难恢复配置时，必须针对承载应用程序的主实例和辅助实例的虚拟网络，为主要和辅助服务总线命名空间创建专用终结点。
假设你有两个虚拟网络：VNET-1、VNET-2，此外还有以下主命名空间和辅助命名空间：ServiceBus-Namespace1-Primary、ServiceBus-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 上运行异地灾难恢复示例。
- 请参阅异地灾难恢复将消息发送到别名的示例。
若要了解有关服务总线消息传送的详细信息，请参阅以下文章：