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