横向扩展 BizTalk Server 数据库
若要为BizTalk Server数据库提供高可用性，请配置两台在 Windows 群集中运行SQL Server的计算机。 这些计算机可以在主动/主动、主动/被动或主动/主动/被动 (需要三台计算机) 冗余配置，并且可以将数据存储在共享驱动器 (上，例如 RAID 1+0 SCSI 磁盘阵列) 或存储区域网络 (SAN) 。
如果 SQL Server 服务由于某种原因不可用，则数据库群集会将资源从主动计算机传输到被动计算机。 在此故障转移过程中，BizTalk Server 服务实例会遇到数据库连接失败，这些实例将自动重新启动以重新连接到数据库。 采用故障转移期间传输的资源后，正在运行的数据库计算机（即前面提到的被动计算机）将开始处理数据库连接。
群集化BizTalk Server数据库 2 中讨论了BizTalk Server数据库的群集。 本部分重点介绍横向扩展BizTalk Server数据库以提供高可用性。
为 BizTalk MessageBox 数据库提供高可用性
本部分提供有关配置 BizTalk MessageBox 数据库以实现高可用性的信息。
运行多个 MessageBox 数据库
若要增强BizTalk Server数据库的可伸缩性，并解决 MessageBox 数据库SQL Server计算机上的 CPU 使用率过高的问题，可以将BizTalk Server配置为跨多个 MessageBox 数据库存储数据。 运行配置向导时创建第一个 MessageBox 数据库。 此 MessageBox 数据库为主 MessageBox 数据库。 BizTalk Server 部署中只能有一个主 MessageBox 数据库。 主 MessageBox 数据库包含主订阅信息，并将消息路由到相应的 MessageBox 数据库。 通常，你想要将主 MessageBox 数据库专用于仅执行路由，并让其他 MessageBox 数据库执行处理。 若要使 MessageBox 数据库仅执行路由，请从 BizTalk 管理控制台中的 MessageBox 属性中选择 “禁用新邮件发布 ”。
MessageBox 数据库处理流的一个示例如下所示：
当主 MessageBox 数据库接收到新的激活消息（业务流程的崭新实例或订阅消息）时，主 MessageBox 数据库会将该激活消息分发给下一个可用的 MessageBox 数据库。 例如，如果您有一个主 MessageBox 数据库和两个 MessageBox 数据库，主 MessageBox 数据库会将第一个激活消息路由到 MessageBox 数据库 1、将第二个激活消息路由到 MessageBox 数据库 2、将第三个激活消息路由到 MessageBox 数据库 1，然后按循环法模式依此类推。 主 MessageBox 数据库使用内置逻辑来提供负载平衡，因此不需要其他的负载平衡机制。
当主 MessageBox 数据库将激活消息路由到特定 MessageBox 数据库（例如，MessageBox 数据库 1）后，业务流程将进入内存并运行。
如果业务流程必须等待消息，并且等待时间超过几秒钟，则业务流程将保留回 MessageBox 数据库 1。 业务流程正在等待相关消息。
当相关消息到达主 MessageBox 数据库时，消息引擎在 MessageBox 数据库的数据库中执行查找操作，该数据库中包含此示例中相关消息的状态 (MessageBox 1) 。 主 MessageBox 数据库将消息传递到包含业务流程的 MessageBox 数据库。
业务流程将返回到内存中，以继续处理，直到它完成或必须等待另一个相关消息。
BizTalk Server 将所有状态存储在 MessageBox 数据库中，其中每个 MessageBox 数据库包含不同业务流程的状态信息。 为实现可靠性，必须群集所有 MessageBox 数据库，包括主 MessageBox 数据库和辅助 MessageBox 数据库。
若要配置多个 MessageBox 数据库，请使用 BizTalk Server 管理控制台添加运行SQL Server的计算机。 从管理角度来看，您只需添加新的 MessageBox 数据库。 BizTalk Server 将自动处理激活消息的循环分发，并将相关消息发送给相应的 MessageBox 数据库。
如果在环境中配置多个 MessageBox 数据库，则应为BizTalk Server组至少创建三个 MessageBox 数据库，并且应在主 MessageBox 数据库上禁用消息发布。 之所以提出此建议，是因为添加其他 MessageBox 数据库会导致主 MessageBox 数据库在 MessageBox 数据库之间路由消息的开销。 如果仅配置两个 MessageBox 数据库，则附加 MessageBox 数据库获得的大部分好处会因主 MessageBox 数据库用于消息路由而消耗的开销所抵消。
重要
BizTalk Server 将所有状态存储在 MessageBox 数据库中，其中每个 MessageBox 数据库包含不同业务流程的状态信息。 为实现可靠性，必须群集所有 MessageBox 数据库，包括主 MessageBox 数据库和辅助 MessageBox 数据库。
取保多个 MessageBox 数据库高度可用
虽然将 MessageBox 数据库添加到BizTalk Server部署可以提高可伸缩性，但它不提供高可用性，因为每个 MessageBox 数据库都是唯一且独立的，并且可能是BizTalk Server环境的单一故障点。 若要添加冗余，则需要为每个 MessageBox 数据库配置一个服务器群集。 BizTalk Server 跨多个 MessageBox 数据库分发数据，因此，这些数据库不共享数据，也不在未进行服务器群集的情况下提供冗余。
确保 BizTalk 跟踪数据库高度可用
根据特定部署的不同要求，您可能希望通过将 BizTalk 跟踪数据库隔离到单独的 SQL Server 计算机上并创建专用于主机跟踪的单独 BizTalk 主机来增强跟踪性能。 下图显示了具有两个主机实例和群集数据库的专用跟踪主机。
如果部署需要高吞吐量并且需要为这些消息跟踪大量数据，则跟踪系统开销可能会消耗运行 SQL Server 的计算机上的大量资源。 如果出现这种情况，并且高速率的传入消息继续，BizTalk Server达到无法处理新邮件的地步，因为跟踪消息所需的资源大于运行其他BizTalk Server组件所需的资源 (，例如接收消息并将其保存到 MessageBox 数据库) 。
为了提高性能和安全性，建议您将一台不包含其他任何项目（例如接收位置、业务流程或管道）的主机专用于跟踪，并且禁止从接收主机、处理主机和发送主机进行跟踪。 若要确保跟踪主机高度可用，请创建跟踪主机的多个主机实例。 请参阅 创建新主机。
对于每个 MessageBox 数据库，BizTalk Server仅使用一个跟踪主机实例将消息从 MessageBox 数据库移动到 BizTalk 跟踪数据库 (BizTalkDTADb) 。 如果其他计算机运行该跟踪主机的实例，则 BizTalk Server 会自动将每个 MessageBox 数据库的处理扩展到该跟踪主机的单独实例。 如果 MessageBox 数据库数大于跟踪主机实例数，则一个或多个跟踪主机实例将为多个 MessageBox 数据库提供服务。
若要确保 BizTalk 跟踪数据库具有高可用性，请使用 Windows 群集来配置两台使用主动/被动配置运行 SQL Server 的数据库计算机。
确保 BAM 数据库高度可用
业务活动监视 (BAM) 提供独立于 IT 实现或跨异类 IT 实现的业务流程的可见性。 BAM SQL Server 数据库（BAM 星型架构数据库、BAM 主导入数据库和 BAM 存档数据库）和 BAM 分析数据库存储了不同于操作监视数据的业务活动数据。 下图显示了 BAM 数据库基础结构。
为确保 BAM 基础结构高度可用，执行以下操作：
群集 BAM 主导入数据库和 BAM 分析数据库。 BAM 主导入数据库是业务活动监视系统的中心。 因此，通过使用 Windows 群集来确保此数据库高度可用并遵循以下两条建议以防止此数据库被填满是十分重要的。 BAM 分析数据库是存储业务分析员用于生成活动聚合和 OLAP 多维数据集的数据的 Analysis Services 数据库。因此，此数据库的任何故障都会影响业务分析员的工作效率。 虽然不必群集 BAM 存档数据库，但我们建议在运行 SQL Server Integration Services (SSIS) 包时监视事件日志中的错误，以确保数据已成功传输，并监视数据库的大小，以便在数据填满之前对其进行替换。
定义联机时段。 为了提高性能并避免停机，BAM 根据活动完成时的时间戳，将 BAM 主导入数据库中的数据分区到表中。 BAM 通过定期将另一个相同格式的空表与已完成的表进行交换来实现此操作。 BAM 完成此操作后，尽管 BAM 会在联机时段中定义的时间内保留旧分区，但其他已完成的活动将进入新分区（表）。 必须定义联机时段以确保 BAM 主导入数据库中的分区数不会变得过大。 有关计划联机窗口的详细信息，请参阅 存档主导入数据库数据。
计划 SSIS 包定期运行。 定义联机时段可确保 BAM 主导入数据库不会被旧活动分区填满。 还必须计划 SSIS 包定期运行，以便为活动数据创建新分区，并将 BAM 主导入数据库中的旧分区中的数据移到 BAM 存档数据库中。 有关计划 SSIS 包的详细信息，请参阅计划SQL Server Integration Services 包。
仔细选择几小组数据项（检查点），并在定义活动时避免包括不必要的数据项。
在设计聚合时，应了解计划聚合与实时聚合之间的权衡关系。 实时聚合由 SQL Server 触发器自动进行维护并且没有延迟。 它们非常适合某些任务关键型低延迟方案，但每当将事件写入 BAM 主导入数据库时，它们都会产生性能成本。 计划的聚合依赖于计划的 cubing SSIS 包来更新其聚合数据。 它们的延迟等于或大于 SSIS 计划间隔，但总体而言，它们对 BAM 主导入数据库的性能影响较小。
如果选择计划的聚合，请确保计划 Cubing SSIS 比存档 SSIS 更频繁地运行。 这是因为存档 SSIS 不会将已为计划聚合处理的活动数据移动到 BAM 存档数据库。
在多台计算机中启用 BAM 事件总线服务以获取故障转移功能。
确保其他 BizTalk Server 数据库高度可用
若要为其他BizTalk Server数据库提供高可用性，请配置两台在 Windows 群集中运行SQL Server的计算机。 这些计算机可以在主动/主动或主动/被动配置中运行，实现冗余，并且可以将数据存储在共享驱动器 (上，例如 RAID 1+0 SCSI 磁盘阵列) 或存储区域网络 (SAN) 。