使用SQL Server Always On可用性组实现高可用性 - BizTalk Server

  • 项目

使用 SQL Server AlwaysOn 可用性组配置高可用性。

提示

使用可用性组 LAB 设置 BizTalk Server 2016 提供了 Microsoft 现场工程师编写的分步指南。 它基于实验室环境，包括一些观察结果。 请查看它。

重要

  • 从 SQL Server 2016 及更新版本开始，BizTalk Server支持Always On可用性组。 如果你使用的是以前的SQL Server版本，本文不适用于你。
  • BizTalk Server支持同步提交模式;不支持异步提交模式。 对于灾难恢复，建议配置备份BizTalk Server作业，并使用日志传送。 有关具体的详细信息，请参阅备份和还原BizTalk Server数据库。

可用性模式详细介绍了Always On可用性组的提交选项。

背景和历史记录

BizTalk Server严重依赖SQL Server进行数据暂留。 BizTalk Server中的其他组件和主机在集成不同的业务应用程序（例如接收、处理或路由消息）时具有特定角色。 数据库计算机捕获此工作，并将其保存到磁盘。

BizTalk 使用SQL Server故障转移群集和日志传送为其数据库提供高可用性、备份和还原以及灾难恢复。 在 Azure IaaS (Azure 虚拟机) ，以前，BizTalk (Windows 和 SQL) 不支持故障转移群集实例，因为没有受支持的共享磁盘，这是聚类分析 SQL 和 MSDTC 所必需的。 因此，使用 Azure VM 时，BizTalk 没有 HA 解决方案。 由于 Azure 共享磁盘现已推出，因此可以在 Azure VM 中群集 SQL 和 MSDTC。 使用 Azure 共享磁盘的 SQL 故障转移群集实例是最高可用性的解决方案。

从 2016 SQL Server 开始，SQL Server AlwaysOn 可用性组支持用于本地和使用 Azure VM 的 MSDTC。 因此，本地或 Azure IaaS 方案中的 BizTalk 数据库支持 SQL Server 2016 (或更高版本) AlwaysOn 功能。 由于在故障转移期间使用 存储空间直通 (S2D) 时同步磁盘同步会产生额外的开销，因此与 SQL 故障转移群集实例相比，同步磁盘的高可用性较低。

SQL Server 2016 AlwaysOn 可用性组

部署 AlwaysOn 可用性组需要 Windows Server 故障转移群集 (WSFC) 群集。 给定可用性组的每个可用性副本必须位于相同 WSFC 群集的不同节点上。 为您创建的每个可用性组创建一个 WSFC 资源组。 WSFC 群集将监视此资源组，以便评估主副本的运行状况。

下图显示的是一个包含一个主要副本和四个次要副本的可用性组。

SQL AlwaysOn 可用性组中具有BizTalk Server的主副本 (replica)

客户端可以使用可用性组侦听器连接到给定可用性组的主副本 (replica) 。 可用性组侦听器提供一组附加到给定可用性组的资源，以将客户端连接定向到适当的可用性副本 (replica) 。

重要

SQL Server 2016 支持在 Windows Server 2016 和 Windows Server 2012 R2 上使用 AlwaysOn 可用性组 (AG) 的 MSDTC。 Windows Server 2012 R2 需要安装 3090973 Windows 修补程序。 Windows Server 2016要求启用 RemoteAccessEnabled 注册表项。

对于 2016 年以前的任何版本，SQL Server不支持具有 AlwaysOn AG 的 MSDTC。 SQL Server 2016 SP2 改进了 MSDTC 事务处理，因此建议使用 SP2 或更高版本。

使用 AlwaysOn 可用性组为 BizTalk 数据库提供高可用性

在 BizTalk Server 的基本配置中，至少创建了 9 个数据库，包括规则和 BAM 数据库。

SQL Server 2016 SP2 之前，可用性组不支持同一 SQL 实例上的数据库之间的 MSDTC，因此 BizTalk 数据库必须分布在至少 4 个 SQL 实例中。 由于此限制，建议使用 SQL Server 2016 SP2 (或更高版本) 和 BizTalk Server 2016 CU5 (或更高版本) ，以便所有 BizTalk 数据库都可以使用相同的SQL Server实例。 出于性能原因，仍可以考虑使用多个 SQL 实例， (例如，将 MessageBox 放在其他 SQL 实例上) 。

在横向扩展的 MessageBox 方案中， (具有多个 MessageBox) 的配置中，有多个 MessageBox 数据库，并且必须将每个 MessageBox 数据库添加到可用性组。

BizTalk Server还依赖于用于 BAM 分析和存档的 SQL Server Analysis Services 和 SQL Server Integration Services。 SQL Server不提供 Azure IaaS 中的 Integration Services 或 Analysis Services 的高可用性解决方案。 因此，建议对 BAMArchive 和 BAMAnalysis Analysis Services 数据库使用另一个独立的SQL Server实例。 对于本地安装，SQL 故障转移群集实例可用于设置高可用性配置。

对于 BizTalk Server 2016，下图中显示了此配置，建议对可用性组 (中的 BizTalk 数据库使用，从 SQL 2016 SP2 和 BizTalk 2016 CU5 开始，) 不再需要 4 个 SQL 实例：

建议SQL Server始终在 BizTalk Server 2016 和更早版本上配置

从 2020 BizTalk Server开始，SSIS 目录支持 BAM DTS 包的高可用性。 将 SSISDB 数据库添加到与 BizTalk Server 数据库相同的可用性组。 下图中显示了此配置，建议对可用性组中的 BizTalk 数据库 (如上所述，) 不再需要 4 个 SQL 实例：

建议SQL Server始终在 BizTalk Server 2020 及更新版本上配置

除了SQL Server数据库外，BizTalk Server配置还创建SQL Server安全登录名和 SQL 代理作业。 AlwaysOn 可用性组仅提供管理可用性组中的数据库的功能。 在所有可用性副本上，需要手动创建和更新BizTalk Server登录名和 SQL 代理作业。

以下SQL Server安全登录名列表与BizTalk Server相关联。 你可能为BizTalk Server应用程序创建了其他登录名。 如果是这样，则需要在托管 BizTalk 数据库副本 (replica) 的每个SQL Server实例上复制它们。

  1. BizTalk 应用程序用户 (一个或多个对应于每个中级主机)
  2. BizTalk 独立主机用户 (一个或多个对应于每个独立主机)
  3. BizTalk Server Administrators
  4. BizTalk Server B2B Operators
  5. BizTalk Server Operators
  6. SSO Administrators
  7. BAM 警报用户
  8. BAM 管理 Web Services 用户
  9. 规则引擎更新服务帐户

如果已创建其他主机或稍后将创建其他主机，则在此过程中将创建新的 SQL 登录名。 必须确保在相应的副本上手动创建这些 SQL 登录名。

以下 SQL Server 代理作业与 BizTalk Server 相关联。 每个服务器上安装的作业有所不同，具体视安装和配置的功能而定。 其中大多数作业是在BizTalk Server配置期间创建的。 部分作业是在配置日志传送时创建的。 需要在托管其相应 BizTalk 数据库的副本 (replica) 的每个SQL Server实例上复制这些作业。 必须手动执行此操作。

  • BizTalkMgmtDb 作业：
    • 备份 BizTalk Server (BizTalkMgmtDb)
    • CleanupBTFExpiredEntriesJob_BizTalkMgmtDb
    • 监视 BizTalk Server (BizTalkMgmtDb)
  • BizTalkMsgBoxDb 作业：
    • MessageBox_DeadProcesses_Cleanup_BizTalkMsgBoxDb
    • MessageBox_Message_Cleanup_BizTalkMsgBoxDb
    • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
    • MessageBox_Parts_Cleanup_BizTalkMsgBoxDb
    • MessageBox_UpdateStats_BizTalkMsgBoxDb
    • Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb
    • PurgeSubscriptionsJob_BizTalkMsgBoxDb
    • TrackedMessages_Copy_BizTalkMsgBoxDb
  • 其他 msgbox 上的作业
  • BizTalkDTADb 作业：
    • DTA 清除和存档 (BizTalkDTADb)
  • BizTalkRulesEngineDb 作业：
    • Rules_Database_Cleanup_BizTalkRuleEngineDb
  • BAMAlertsApplication 作业：
    • 0 或更多 DelAlertHistJob

与 SQL 故障转移群集实例不同，在可用性组中，所有副本都处于活动状态、正在运行且可用。 当 SQL 代理作业在故障转移的每个副本 (replica) 上重复时，它们会针对相应的副本 (replica) 运行，无论它当前是主要角色还是辅助角色。 若要确保这些作业仅在当前主副本 (replica) 执行，每个作业中的每个步骤都必须包含在 IF 块中，如下所示：

IF (sys.fn_hadr_is_primary_replica(‘dbname’) = 1)  
BEGIN  
…  
END

将 替换为 ‘dbname’ 配置为运行作业所针对的相应数据库名称。 以下示例演示 BizTalkMsgBoxDb 上TrackedMessages_Copy_BizTalkMsgBoxDb的此更改：

使用 BizTalk Server 更改 AlwaysOn 可用性组中 SQL 代理作业的名称

在已设置可用性组时配置 BizTalk

  1. 检查 OS 要求：
  2. 创建所需的可用性组。 确保使用 “每个数据库 DTC 支持 ”选项创建可用性组。
  3. 配置BizTalk Server并指定 SQL 服务器名称时，请使用可用性组的侦听器名称，而不是实际的计算机名称。 这会在当前主副本 (replica) 上创建 BizTalk 数据库、登录名和 SQL 代理作业。
  4. ) 停止 BizTalk 处理 (主机实例、SSO 服务、IIS、规则引擎更新服务、BAMAlerts 服务等，并停止 SQL 代理作业。
  5. 现在，将 BizTalk 数据库添加到相应的可用性组。
  6. 将 SQL 代理作业步骤的主体括在IF前面提到的块 () 中，以确保它们仅在目标为主要副本 (replica) 时才运行。
  7. 脚本登录名和 SQL 代理作业，以在相应的副本 (replica) 上复制它们。
  8. 在托管辅助副本 (replica) 的相应 SQL 实例上复制 SQL DBMail 配置文件和帐户 BAM 警报。
  9. 如果要添加其他消息框数据库或稍后部署新的 BAM 活动/视图，则会在当前主副本 (replica) 上为新消息框数据库或 BAM 警报数据库创建新的 SQL 作业。 请确保在主副本 (replica) 上对其进行编辑，然后在相应的辅助副本上手动创建它们。
  10. 从 BizTalk Server 2020 及更新开始，BAM DTS 包将部署到 SSIS 目录。 将 SSISDB 数据库添加到 BizTalk 数据库所在的同一可用性组。 有关详细信息，请参阅 适用于 SSIS 目录的 AlwaysON。

也可以使用托管主副本 (replica) 的 SQL 实例来完成此配置。 在这种情况下，在 BizTalk 配置完成后，在 BizTalk 计算机上运行 UpdateDatabase.vbs 和 UpdateRegistry.vbs 脚本，然后执行上述步骤。 下一部分将对此进行更详细的讨论。

将现有 BizTalk 数据库移动到可用性组

  1. 检查 OS 要求：

  2. 创建所需的可用性组。 确保使用 “每个数据库 DTC 支持 ”选项创建可用性组。

  3. 停止 BizTalk 处理和 SQL 代理作业。

  4. 执行所有 BizTalk 数据库的完整备份。

  5. 在当前处于可用性组中主要角色的 SQL 实例上还原 BizTalk 数据库。

  6. 在可用性组中当前处于主要角色的相应 SQL 实例上编写脚本登录名和 SQL 代理作业。

  7. UpdateDatabase.vbs使用以下步骤在 BizTalk 计算机上运行 和 UpdateRegistry.vbs 脚本。 在输入更新信息 xml 中输入可用性组侦听器作为新服务器名称。

    1. 停止BizTalk Server上的所有 BizTalk 服务和企业 SSO 服务。 在SQL Server停止 SQL 代理服务。

    2. 在BizTalk Server，编辑以下文件夹中的 SampleUpdateInfo.xml：

      32 位计算机： %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64 位计算机： %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      1. 将“SourceServer”替换为托管旧数据库) (旧SQL Server源服务器名称。
      2. 将“DestinationServer”替换为目标服务器的名称，该名称应为可用性组侦听器名称。
      3. 如果有 BAMAnalysis、BAM 数据库或 RuleEngineDB，请取消注释相应的部分。

    3. 打开命令提示符，然后转到：

      32 位计算机： %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64 位计算机： %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      在命令提示符处，运行：
      cscript UpdateDatabase.vbs SampleUpdateInfo.xml

      仅在 BizTalk 组中的一台服务器上运行 UpdateDatabase.vbs。

    4. 将编辑的 SampleUpdateInfo.xml 文件复制到此 BizTalk 组中每台BizTalk Server计算机上的以下文件夹：

      32 位计算机： %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64 位计算机： %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

    5. 在BizTalk Server组中的每台计算机上，打开命令提示符，然后转到：

      32 位计算机： %SystemRoot%\Program Files\Microsoft BizTalk Server 20xx\Schema\Restore

      64 位计算机： %SystemRoot%\Program Files (x86)\Microsoft BizTalk Server 20xx\Bins32\Schema\Restore

      在命令提示符处，运行：
      cscript UpdateRegistry.vbs SampleUpdateInfo.xml

      在 BizTalk 组中的每个服务器上运行 UpdateRegistry.vbs。

  8. 现在，将数据库移动到其各自的可用性组。

  9. 在托管 BAMAlerts 数据库的 SQL 实例上复制 SQL DBMail 配置文件和帐户的 BAM 警报副本 (replica) 。

  10. 将 SQL 代理作业步骤的正文括在 IF 块中，以确保它们仅在目标为主要步骤时才运行。

  11. 脚本登录名和 SQL 代理作业，以在相应的副本 (replica) 上复制它们。 UpdateDatabase 脚本还会更新Operations_OperateOnInstances_OnMaster_BizTalkMsgBoxDb和TrackedMessages_Copy_BizTalkMsgBoxDb作业中的服务器名称。 因此，仅在运行 UpdateDatabase 脚本后编写 SQL 代理作业脚本。

要求

  • BizTalk Server：
    • BizTalk Server 2020 企业版
    • BizTalk Server 2016 企业版 CU5
  • SQL Server:

    • SQL Server 2019 企业版或标准版

    • SQL Server 2017 企业版或标准版

    • SQL Server 2016 企业版或标准版。

      有关 SQL Server Standard Edition 限制，请参阅本文中的已知限制。

  • Windows Server
    • Windows Server 2019
    • Windows Server 2016
    • Windows Server 2012 R2

使用非默认端口配置的可用性组侦听器 (1433)

在BizTalk Server计算机上使用 SQL 别名。

多子网可用性组

BizTalk Server不支持 MultiSubnetFailover (=TRUE) 连接选项。

有关将不支持此选项的 SQL 客户端连接到多子网 SQL 可用性组时可能发生的问题的详细信息，请参阅 SQL 文档。 以下链接中讨论了其中一些问题：

只读路由

只读路由是指SQL Server能够将可用性组侦听器的传入连接路由到配置为允许只读工作负荷的辅助副本 (replica) 。

BizTalk 不对其数据库的任何连接使用 Read-Only 路由。 这意味着可用性组中可用性副本的“可读辅助副本”选项对 BizTalk 数据库连接没有任何影响。

SQL Server故障转移期间 BizTalk 主机实例的行为

如果SQL Server可用性组发生故障转移，可用性组上的BizTalk Server数据库将暂时不可用。

SQL Server 故障转移期间进程内主机实例的行为

如果BizTalk Server数据库不可用，则会回收BizTalk Server主机的进程内实例，直到还原到SQL Server的连接。 还原到SQL Server数据库的连接后，文档处理将正常恢复。

SQL Server 故障转移期间独立主机实例的行为

如果BizTalk Server数据库不可用，则BizTalk Server主机的独立实例将暂停，并在BizTalk Server应用程序日志中生成类似于以下内容的错误：

All receive locations are being temporarily disabled because either the MessageBox or Configuration database is not available. When these databases become available, the receive locations will be automatically enabled.

还原到SQL Server数据库的连接后，会将类似于以下内容的信息性消息写入BizTalk Server应用程序日志，然后正常恢复文档处理：

All receive locations are being enabled because both the MessageBox and Configuration databases are back online.

灾难恢复的日志传送

BizTalk Server通过使用数据库日志传送来实现数据库待机功能。 BizTalk Server日志传送可自动备份和还原数据库及其事务日志文件，使备用服务器能够在生产数据库服务器发生故障时恢复数据库处理。

可用性组中的辅助数据库不是备份。 继续使用 BizTalk Server 日志传送作业备份 BizTalk 数据库及其事务日志。 实现 BizTalk 日志传送的方式可确保始终针对每个数据库的当前主副本 (replica) 执行备份。 BizTalk Server日志传送作业不遵循可用性组上的备份首选项设置。

如果要将其他 BizTalk 数据库添加到 BizTalk 数据库备份作业，请确保在设置备份时使用可用性组侦听器名称作为它们的数据库服务器。

参考

已知的限制

这些限制适用于 BizTalk Server、SQL Server AlwaysOn 可用性组和 Azure 虚拟机。 这些限制将来可能会得到解决，也可能不解决。

  • 登录名、SQL 代理作业、SQL DB 邮件配置文件和帐户不在可用性组中管理。 这需要在作业中手动修改，以确保它们针对主副本 (replica) 运行。

  • SQL Server Analysis Services和 SQL Server Integration Services 不参与可用性组。 如果没有SQL Server的此支持，Azure 虚拟机中就没有针对这些项的 HA 解决方案。 BizTalk Server的 BAM 功能依赖于这些服务。

  • 在 SQL Server 2016 SP2 之前，可用性组不支持同一 SQL 实例上的数据库之间的 MSDTC。

    从 SQL Server 2016 SP2 和 BizTalk Server 2016 CU5 开始，BizTalk 数据库可以使用同一个 SQL Server 实例。

  • BizTalk Server不能使用 Read-Only 路由。

  • BizTalk Server不设置MultiSubnetFailover连接属性。

  • 使用日志传送的 BizTalk 备份作业始终以主副本 (replica) 而不考虑可用性组上设置的备份首选项。

  • SQL Server 2016 Standard 在每个 SQL AlwaysOn AG 中仅支持一个数据库。 由于 BizTalk 使用许多数据库，因此通常建议使用 SQL Server Enterprise 版本。

  • 如果使用 Azure VM，建议对 MSDTC 使用专用固定 TCP/IP 端口。 使用固定 TCP/IP 端口时，不会限制通常用于较旧操作系统的 RPC 端口范围;它有助于简化防火墙和负载均衡器规则。 若要避免与已知的较低端口冲突，请考虑使用更高的固定端口 (，例如 >20000) 。 配置 DTC 单一端口支持 介绍了 ServerTcpPort 注册表项。 除了 MSDTC 的固定端口外，还使用 main RPC 端口 135。

后续步骤

规划容错。