通过

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

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

小窍门

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

重要

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

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

背景和历史记录

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 故障转移群集实例是最高可用性的解决方案。

从 SQL Server 2016 开始，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 群集监视此资源组以评估主要副本的运行状况。

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

使用 BizTalk Server 的 SQL AlwaysOn 可用性组中的主要副本

客户端可以使用可用性组侦听器连接到给定可用性组的主副本。 可用性组侦听器提供一组资源，这些资源与特定的可用性组关联，用于将客户端连接引导到合适的可用性副本。

重要

SQL Server 2016 支持在 Windows Server 2016 和 Windows Server 2012 R2 上使用 MSDTC 的“AlwaysOn”可用性组（AG）。 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 实例。 出于性能原因（例如，将 MessageBox 放在其他 SQL 实例上），仍可能考虑使用多个 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 实例）：

在 BizTalk Server 2016 及更早版本上推荐的 SQL Server Always On 配置

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

BizTalk Server 2020 及更高版本上的推荐 SQL Server Always On 配置

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

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

  1. BizTalk 应用程序用户（一个或多个对应于每个代理主机）
  2. BizTalk 独立主机用户（一个或多个对应于每个独立主机）
  3. BizTalk Server 管理员
  4. BizTalk Server B2B 运营者
  5. BizTalk Server 操作员
  6. SSO 管理员
  7. BAM 警报用户
  8. BAM 管理 Web 服务用户
  9. 规则引擎更新服务帐户

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

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

  • BizTalkMgmtDb 作业：
    • 备份 BizTalk Server （BizTalkMgmtDb）
    • 清理BTF过期条目任务_BizTalk管理数据库
    • 监视 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
  • 在其他消息框上的作业
  • BizTalkDTADb 作业：
    • DTA 清除与存档（BizTalkDTADb）
  • BizTalkRulesEngineDb 的作业：
    • Rules_Database_Cleanup_BizTalkRuleEngineDb
  • BAMAlertsApplication 任务：
    • 0 个 DelAlertHistJob 或更多

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

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

用相应的数据库名称替换 ‘dbname’，以便配置该作业的运行。 以下示例显示了 TrackedMessages_Copy_BizTalkMsgBoxDb 在 BizTalkMsgBoxDb 上的此更改：

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

在已设置可用性组的情况下配置 BizTalk

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

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

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

  1. 检查你的操作系统要求：

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

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

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

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

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

  7. 在 BizTalk 计算机上，按照以下步骤运行 UpdateDatabase.vbs 和 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 实例上的 BAM 警报的 SQL DBMail 配置文件和帐户。

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

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

要求

  • BizTalk Server：
    • BizTalk Server 2020 Enterprise
    • BizTalk Server 2016 Enterprise CU5
  • Sqlserver：

    • SQL Server 2019 Enterprise 或 Standard

    • SQL Server 2017 Enterprise 或 Standard

    • SQL Server 2016 Enterprise 或 Standard。

      有关 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 的只读路由是指能够将传入连接通过可用性组侦听器路由到已配置为允许只读负载的辅助副本。

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 日志传送的方式可确保始终针对每个数据库的当前主副本执行备份。 BizTalk Server 日志传送作业不遵循可用性组的备份首选项设置。

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

References

已知的限制

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

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

  • 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 备份作业将始终以主副本为目标，而不考虑可用性组上设置的备份首选项。

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

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

后续步骤

规划容错。

  • Last updated on