使用 Microsoft Windows 2000 群集服务的高可用性解决方案

使用 Microsoft Windows 2000 群集服务的高可用性解决方案

适用于：
     Microsoft® BizTalk® Server 2002
     Microsoft Windows® 2000 群集服务

摘要：学习如何使用 Microsoft Windows 2000 的群集服务组件来设计和部署 Microsoft BizTalk Server 2002 的高可用性实现方案。

第一部分包含群集的重要性以及部署群集需要考虑的软件、硬件和成本等问题的一般信息。
　　◆简介：保障数据的传递和正常运行时间
　　◆群集服务的工作原理
　　◆在 BizTalk Server 中使用群集服务
　　◆故障转移的工作原理
　　◆确定正确的群集配置
　　◆在服务器组中使用多个群集的较高级别保护

第二部分包含设置群集的详细步骤。
　　◆简介
　　◆群集资源和 BizTalk Server
　　◆规划 BizTalk Server 的群集配置
　　◆BizTalk Server 群集设置要求
　　◆群集设置
　　◆升级到 Biztalk Server 2002
　　◆疑难解答
　　◆参考书目


第一部分

简介：保障数据的传递和正常运行时间

　　许多公司都使用 Microsoft® BizTalk® Server 来处理其业务所依赖的核心数据。这些业务丝毫不能出错，一个简单的硬件故障所造成的停机延误就意味着大量的金钱损失。BizTalk Server 利用强大的事务支持来保障数据传递，该事务支持包含以下 ACID 属性：可分性、一致性、隔离性和持久性。此外，还应使用 Microsoft Windows® 2000 群集服务以避免用于将数据永久保存在本地磁盘的任何服务器发生硬件故障。Windows 2000 Advanced Server 和 Windows 2000 Datacenter Server 都包含此组件。利用 Microsoft Windows 2000 群集服务，BizTalk Server 可以支持主动/被动群集，从而在 Orchestration 方案中提供高可用性。

　　群集服务允许将两台或多台服务器组合在一起并作为一个服务器群集共同工作，从而确保关键任务应用程序和资源对客户端始终可用。服务器群集允许用户和管理员在访问服务器或节点上的某些资源时将这些服务器或节点当作单个系统，而不是一个个独立的计算机。

　　高可用性解决方案的设计着重在可用的预算内尽量减少故障。通过结合强大的存储系统（独立磁盘冗余阵列 [RAID]），群集服务利用冗余服务器故障转移功能为在本地永久保存数据的服务器提供可靠性找到了一种经济而有效的方法。

　　冗余服务器不会在本地硬盘永久保存任何数据，而服务器将永久保存数据，必须对这两类服务器加以区分。BizTalk Server 允许组中的所有服务器通过网络访问单个 BizTalk Server 数据库服务器，这已经提供了相当程度的冗余和可伸缩性。如果组中的任何一台服务器出现故障，其他服务器将接管其工作并继续访问数据库服务器。这是可以实现的，因为组中的任何一台服务器都不会将工作数据永久地保存在其本地磁盘上。但是，如果远程数据库服务器由于任何原因而变得不可用，那么组中的所有服务器都将表现为非活动状态。而群集服务可以确保即使在服务器出现全面故障的情况下中央数据库服务器仍然可以响应服务数据库的访问请求，从而解决了这一单点故障问题。

　　是否使用群集服务取决于以下两个因素：

　　◆当将重要数据保存在本地磁盘的服务器变得不可用时，业务所能允许的停机时间。

　　◆为提供满意冗余所需的附加硬件和软件的可用预算。

　　一个简单的冗余也至少需要两台服务器。

 

群集服务的工作原理

　　图 1 所示为一个包含两个节点的群集，显示了称为“无共享”结构的群集的基本实现方案。这里需要注意一个基本概念，即两台服务器都连接在同一个物理磁盘子系统上。但是在任何特定时间内，只有其中一台服务器能够“拥有”和控制磁盘存储。由两台服务器（节点）所共享的磁盘子系统部分称为共享存储。

图 1：无共享群集，服务器 A 处于主动状态

　　服务器 A 当前处于主动状态，也就是说它享有对共享存储的完全控制权。服务器 B 正在运行但处于被动状态，并且准备在另一个节点出现故障时接管共享存储。Microsoft SQL Server™ 的实例在主动节点上运行，并且（作为一项规定）始终在拥有共享存储的群集节点上运行。本例中，磁盘包含了支持 SQL Server 数据库所需的所有必要的物理文件，必须具备这些数据库，BizTalk Server 才能正常运行。该实现方案称为主动/被动 SQL Server 群集。

　　SQL Server 的实例和包含数据库的共享存储称为“虚拟”资源，因为它们并不永久属于任何特定服务器。这意味着其他计算机可以访问 SQL Server 数据库，而不必知道这两台服务器哪一台处于主动状态。群集服务将处理所有必要的进程以使此过程完全透明。要连接到数据库服务器，用户和应用程序需要使用一个“虚拟服务器”名称，该名称必须是唯一的并且要与群集中两个节点的服务器名称区分开来。

　　如果服务器 A 出现硬件故障，所有虚拟资源（即 SQL Server 实例和磁盘存储）将自动作为一个组转移到服务器 B 并继续运行。此过程不会导致数据丢失。图 2 所示为新配置，称为主动/被动。要在正常运行期间充分利用这两台服务器，一个经济而有效的方法是在每台服务器上运行不同的虚拟资源。在这种配置下，每台服务器都作为另一台服务器的故障转移节点。

图 2：主动/被动群集，服务器 B 处于主动状态

　　大多数经 Microsoft 认证其硬件与 Windows 2000 Advanced Server 操作系统兼容的主要硬件提供商都支持群集服务。如今，许多业务都实现了功能强大的企业级服务器的群集，使用 Windows 2000 Advanced Server 的服务器可以包含多达 8 个处理器，使用 Windows 2000 Datacenter Server 的服务器可以包含多达 32 个处理器。
在 BizTalk Server 中使用群集服务

　　使用群集服务的主要目的是保障用于在其磁盘子系统上永久保存数据的服务器的正常运行时间。要彻底防止 BizTalk Server 出现硬件故障，应在以下四个区域实现群集：

　　◆SQL Server 数据库。BizTalk Server 需要四个数据库才能正常运行：Message Management、Shared Queue、Tracking 和 Orchestration。至少应该使用群集服务保护这些数据库以免出现服务器故障。

　　◆消息队列。BizTalk Server 可以使用消息排队（Windows 2000 Server 操作系统的一项功能，也称为 MSMQ）来接收或发送数据。队列通常用于应用程序之间的集成，其中需要很大的吞吐量，并且事务处理的读写非常关键。可以按照与 SQL Server 基本相同的方法将消息排队群集为一个虚拟资源。

　　◆文件共享。BizTalk Server 可以接收或发送标准的文本文件格式（逗号分隔值或固定宽度）的数据。如果用于存储这些文件的服务器出现故障，BizTalk Server 将无法处理数据。当较长的停机时间威胁到业务的运转时，可以使用群集来保护文件共享。

　　◆Web 分布式创作和版本控制 (WebDAV) 储备库（可选）。为防止包含 BizTalk Server 储备库信息的节点的本地驱动器出现故障，可以将文件放在共享群集磁盘资源中。此外，这一配置还允许从任何群集节点方便地访问储备库文件。

　　在查看典型 BizTalk Server 实现中的数据流时，保护这些数据存储显然是非常重要的。图 3 所示为公开的区域。

图 3：实现群集故障保护的区域

　　通过保护接收函数来保证进入 BizTalk Server 的数据流

　　每个入站数据源都通过接收函数传递到 BizTalk Server 中。BizTalk Server 在事务相关环境中读取所有数据，以确保不会丢失任何数据。将数据传递到 BizTalk Server 的方法很多，但有两种特别的数据（即平面文件和消息排队队列）在被传入之前将被永久保存在数据存储区中。当 BizTalk Server 完全群集时，只需从虚拟消息排队实例或虚拟文件共享中读取这些数据即可。

　　注意：如果不打算使用平面文件或消息排队队列，则不必群集这些资源。

在 BizTalk Server 处理数据时保护数据

　　在 BizTalk Server 成功接收数据后，它会立即将这些数据保存到 SQL Server 数据库中。这将当作全是全非型事务的一部分来完成，也用于确保不会丢失数据。如果如前面所述使用了 SQL Server 群集实例，则数据库服务器出现故障将不会影响 BizTalk Server 继续进行处理。

　　为执行 XML 文档的常规处理操作，BizTalk Server 使用 WebDAV 向磁盘读取和写入 XML 储备库数据。这一重要的数据储备库包含 XML 文档规范、映射规范和平面文件转换规范（称为“信封”）等文件的目录。WebDAV 是作为 Internet 信息服务 (IIS) 的一部分而提供的一项功能。

　　虽然在读取储备库数据时使用了一些缓存，但 BizTalk Server 最终还是需要直接从磁盘上获取全新的副本。可以使用群集来确保即使在 IIS 及其所依赖的磁盘存储不可用时，处理过程也不会受到影响。

保护来自 BizTalk Server 的出站数据

　　BizTalk Server 完成对 XML 数据的处理后，将使用出站端口将数据发送到目的地。从 BizTalk Server 发送数据的方法很多，但只有平面文件和消息排队队列在很大程度上依赖于永久保存的数据存储的可用性。与 BizTalk Server 中所有其他数据处理操作一样，写入数据的过程也是在全是全非型事务环境中进行的，以确保不会丢失数据。

　　默认情况下，当目标服务器不可用时，BizTalk Server 将使用重试机制。然而，如果吞吐量的要求很高并且停机会造成严重问题，则采用群集不失为一个明智的选择。从群集中获益最明显的出站 BizTalk Server 端口是消息排队队列和平面文件。

保护 BizTalk Orchestration

　　当需要更复杂的业务规则时，可以使用 BizTalk Orchestration 这一强大功能来确保长时间运行或进行复杂的事务处理。

　　如果使用了 BizTalk Orchestration 并且为满足吞吐量要求需要稳定的正常运行时间，则应采用群集来保护 BizTalk Server 储备库数据文件、Orchestration 数据库和消息排队队列。图 4 所示为 BizTalk Orchestration 在群集中的角色，以及它与其他组件之间的交互。

图 4：BizTalk Orchestration 在群集中的角色

 

故障转移的工作原理

故障转移有两种类型：计划的（手动）故障转移和那些由于服务器硬件或软件问题所引起的故障转移。

计划的故障转移

　　当服务器需要进行维护或升级时，可以执行手动故障转移。手动故障转移需要指示群集服务将所有资源从一个节点移至另一个节点。在前面介绍的两节点示例中，这一操作包括移动共享存储和 SQL Server 实例。故障转移的速度很快，因此当一台服务器完成升级或维护任务后，可以将群集资源恢复到该服务器，然后在第二台服务器上执行升级或维护任务。如果没有群集服务，则在执行维护工作时，服务器可能在很长一段时间内都无法使用。

服务器硬件出现故障时的自动故障转移

　　群集服务始终在两个群集节点上运行，并不断监视每台服务器以确保所有资源均工作正常。如果发生严重的硬件故障或意外错误，所有资源都将自动转移到另一个节点而无需人工干预。

　　在结构良好的服务器配置中，监视工具（例如由 Microsoft Operations Manager 2000 提供的监视工具）将立即检测到此类故障转移。并且这些工具将通知相应的操作人员，服务器出现了故障需要引起注意。如有必要，可以将监视工具配置为自动运行其他脚本。

使故障转移完全透明

　　ACID 属性被认为是确保数据不会丢失的关键因素。如果 BizTalk Server 位于发送数据过程的中间环节，则表示它处于事务环境中。当出现硬件故障时，事务将被回滚。群集资源被成功转移到另一个节点之后，BizTalk Server 将自动重试该事务。如果向 BizTalk Server 传递数据的应用程序在编写时符合标准事务处理规则并且具有自动重试机制，则在故障转移过程中应该不会造成太大的影响。

　　在考虑高可用性 BizTalk Server 实现方案的初始设计时，消息排队提供的技术非常有用。即使目标服务器暂时不可用，消息排队也可以启用松散耦合的消息模型，并确保 XML 消息的传递。

　　作为如何通过消息排队使故障转移完全透明的一个示例，图 5 显示了一个通过网络将多个 XML 消息发送到虚拟消息排队队列的源应用程序。虚拟队列作为一个群集实例运行，并且当前在服务器 A 上处于主动状态。源服务器将消息排队安装为独立的客户端，这表示在同一服务器上有一个消息排队的本地实例在运行。

图 5：将 XML 消息发送到消息排队队列的源应用程序

　　如果服务器 A 崩溃并进行故障转移，则当共享存储从服务器 A 转移到服务器 B 时，消息排队的虚拟实例将暂时不可用。在此期间，源应用程序可以继续向消息队列发送 XML 消息而不会被中断。这是可以实现的，因为消息排队能够截取消息并自动将其收集到本地出站队列中。应用程序并不需要了解有关故障转移的任何信息。

图 6：故障转移期间消息缓存在本地的出站队列中

　　在成功完成故障转移并且虚拟消息排队实例恢复联机后，源服务器上的消息排队服务会将中断期间收集的所有消息发送到目标服务器。一切都继续正常进行，所有消息都会得到处理。

图 7：故障转移后，缓存的消息被发送到目标服务器

确定正确的群集配置

需要对 BizTalk Server 配置中的哪些服务器进行群集最终取决于业务所允许的停机时间和可用的服务器预算。如果容量很小，则可以只使用两台较高性能的服务器（两节点群集），来设计一个包括所有公开区域的完整 BizTalk Server 群集实现方案。

许多业务都需要使用 BizTalk Server 来处理大量的文档，这时可以选择使用 BizTalk Server 的扩展功能来分担负载。下面将介绍这两种方案的配置选项。

　　警告：BizTalk Server 支持主动/被动群集配置，也就是说，在一个群集中不能同时存在两个 BizTalk Messaging Service 主动实例或两个 BizTalk Orchestration 主动实例。如果在一个群集中，BizTalk Messaging Service 实例和 BizTalk Orchestration 实例运行在两个不同的群集节点上，则该群集仍属于主动/被动配置。还支持 SQL Server、消息排队和 Internet 信息服务 (IIS) 的主动/主动配置。

BizTalk Server 两节点群集配置

使用包含两台服务器的群集配置可以为 BizTalk Server 配置一个完整的故障转移解决方案。这可以保护前面介绍的所有公开区域免受服务器故障的影响。

　　重要信息：如果 BizTalk Server 需要处理的文档量非常大，则不适合采用这种解决方案。在确定群集设计之前，必须先确定数据量和峰值吞吐量要求。

在确定群集中服务器的大小时，需假定所有虚拟资源在某一时刻都只能在一个节点上运行。服务器大小的示例将在稍后的大小设置原则中介绍，但那只是一个指导性信息，对于特定的实现，只有通过充分的强度测试才能准确评估服务器要求。

对于此处介绍的 BizTalk Server 实现，我们假定将存储用于以下元素：

　　◆用于将文件传入和传出 BizTalk Server 的文件共享

　　◆消息排队队列

　　◆SQL Server

　　◆WebDAV 储备库

图 8 所示的群集配置充分利用了两个节点，并为所有公开区域提供了故障转移保护，从而使两台服务器互相充当对方的主动/被动故障转移服务器。

图 8：互相充当主动/被动故障转移的两台服务器

在此配置中，SQL Server 正常情况下在服务器 A 上运行，如果服务器 A 出现故障则转移到服务器 B；而 BizTalk Server 正常情况下在服务器 B 上运行，如果服务器 B 出现故障则转移到服务器 A。

上面介绍的将 SQL Server 实例和 BizTalk Server 实例分开的做法对于大多数情况而言在逻辑上都是最好的选择。然而，这并不表示必须一直保持这种配置。任何时候需要优化性能时，都可以使用手动故障转移将各种群集资源从一台服务器转移到另一台服务器上。例如，如果比较注重 BizTalk Orchestration 的性能，则可以将具有虚拟 BizTalk Orchestration 实例的组移到虚拟 SQL Server 实例所在的节点上来运行，这样可以获得更好的性能。

结合 BizTalk Server 组和群集服务

当可伸缩性和高可用性都很重要时，可以使用高性能配置。图 9 就显示了这样的配置，它充分利用了 BizTalk Server 组和群集服务的功能。

图 9：BizTalk Server 组和群集服务的高性能配置

在这种配置中，主要问题是如何获得 BizTalk Server 数据库的高可用性。为此，只有 SQL Server 实例被群集，组中的每个 BizTalk Server 实例都将访问此虚拟实例。有关群集 SQL Server 的详细信息，请参阅SQL Server 2000 Failover Clustering（英文）白皮书。

这里有一个基本假设，即，组中的一个 BizTalk Server 发生故障时并不会造成严重障碍，因为：

　　◆如果组中的一个 BizTalk Server 出现故障，还有其他三个 BizTalk Server 实例在运行并继续处理数据。

　　◆所有 BizTalk Server 都不依赖本地磁盘来接收或发送数据，而是使用其他数据交换方法，例如 HTTP 或应用程序集成组件 (AIC)。

　　- 或者 -

　　数据永久保存在每个 BizTalk Server 本地，但停机的严重性不足以要求增加额外费用以部署更多的群集。在服务器组中使用多个群集的较高级别保护

　　有些客户要求在配置中针对服务器故障提供完整的保护。同时，他们需要 BizTalk Server 组的扩展功能以达到负载平衡。在这些情况下，及时传递数据对业务至关重要，因此额外的硬件成本将成为次要考虑因素。

　　图 10 显示了客户如何使用三个群集来部署高可用性和可伸缩性的 BizTalk Server 实现方案。

图 10：用于高可用性和可伸缩性实现的三个群集

　　群集 1 是主动/主动配置，包含两个 SQL Server 实例。使用最频繁的数据库是 BizTalk Server Tracking 和 Queue 数据库，因此将它们分布在两个节点之间以达到最佳负载平衡。这样可以充分利用群集中的两台服务器，同时获得数据库的最佳性能。有关 SQL Server 群集的详细信息，请参阅 （英文）白皮书。

　　群集 2 是 BizTalk Messaging Service 的主动/被动实现。此 BizTalk 服务的使用最为频繁，它处理所有接收函数并进行处理。在此配置中，被动节点处于非活动状态，以备将来扩展时使用。

　　群集 3 是节点 A 所拥有的 BizTalk Messaging Service 的主动/被动实现。此 BizTalk 服务经过优化，专门处理由群集 2 上的 BizTalk Server 放入数据库工作队列中的项目。为获得最佳性能，BizTalk Orchestration 被分隔开并作为主动/被动配置而独立地在群集 3 的节点 B 上运行，因为它的使用率非常高并且需要调用大量的自定义组件。其单独运行是出于性能和安全两方面的原因。

　　注意，群集 2 上需要消息排队以支持节点 A 上的 BizTalk Messaging。同样在群集 3 上也需要消息排队以支持节点 A 上的 BizTalk Messaging 和节点 B 上的 BizTalk Orchestration。

　　BizTalk Server 的另一个高可用性实现是使用四个节点的群集配置。其中，BizTalk Messaging 在一个节点上处于活动状态，在出现故障时可以转移到其他三个节点中的任何一个；BizTalk Orchestration 在另一个节点上处于活动状态，在出现故障时可以转移到其他三个节点中的任何一个；SQL Server 群集在其余两个节点上。
第二部分

简介

　　第一部分介绍了如何使用 Microsoft® Windows® 2000 的群集服务组件为 Microsoft BizTalk® Server 提供高可用性的各种选择方案。还介绍了群集的一些基本术语和概念。本部分将详细介绍如何在前面介绍的配置中实现 BizTalk Server，包括以下内容：

　　◆硬件和软件要求

　　◆设置 BizTalk Server 资源和资源组

　　◆从 BizTalk Server 2000 SP1A 升级到 BizTalk Server 2002

　　◆疑难解答

　　在本文接下来的部分中，我们将假设群集设置已经完成并且已经安装和测试了群集服务。有关详细信息，请参阅 （英文）、Microsoft Knowledge Base 文章 （Q259267，英文）和 （Q243218，英文），以及 （英文）Web 站点。

群集资源和 BizTalk Server

　　在群集服务实现中，通过组合以下核心群集资源可以创建“虚拟服务器”：

　　◆网络 IP 地址。在网络上标识此虚拟服务器的唯一 IP 地址。

　　◆网络名称。客户端可以通过一个唯一的网络名称访问此虚拟服务器。

　　◆物理磁盘。将被视为虚拟服务器的本地磁盘存储。

　　设置完这些资源后，它们可以作为一个组一起进行故障转移。这些资源必须按照上面列出的顺序联机。该组构成了任何虚拟服务器的基础，在单个群集上可以运行多个这样的组。

　　在 BizTalk Server 实现中，我们将按照所显示的顺序向虚拟服务器组添加以下附加资源：


　　◆Microsoft 分布式事务协调器 (MS DTC)。BizTalk Messaging 要求该组中包含 MS DTC 以确保数据的传递。它必须属于 BizTalk Messaging 所在的组。

　　◆消息排队。BizTalk Server 将执行消息排队队列的“事务性”读取操作。为此，必须将该队列视为 BizTalk Server 所在服务器的本地队列。本例中，BizTalk Server 在虚拟服务器上运行，因此此虚拟消息排队实例被视为虚拟服务器的本地实例。

　　◆IIS WebDAV 储备库（可选）。默认情况下，IIS WebDAV 储备库存储在安装了 BizTalk Messaging 的群集的第一个节点的本地驱动器上。在该节点出现故障时为确保运行，可将 IIS 实例设置为虚拟实例并将文件存放在共享磁盘上。有关详细信息，请参阅 Microsoft KB 文章 （Q248025，英文）。

　　◆BizTalk Messaging。当前面所述的所有资源都按照列出的顺序联机后，BizTalk Messaging 便已作好联机所需的所有准备了，并且可以开始运行。

　　◆XLANG Scheduler Engine（可选）。此资源可以在与 BizTalk Messaging 相同的组中运行，或在运行于其他节点的单独的虚拟服务器上运行。

　　◆XLANG Schedule Restart Service（可选）。此资源必须在与 XLANG Scheduler Engine 相同的组中运行。它确保在群集上以受控的方式启动和终止 Orchestration 计划。

规划 BizTalk Server 的群集配置

　　在规划群集实现之前，有必要先了解特定环境的性能特征。弄清楚最有可能出现瓶颈的位置并反映到全局结构中，这将有助于您确定最佳的配置。基于所需解决方案的独特性能特征和要求，选择在不同的计算机上部署不同的解决方案组件，然后确定群集这些资源的最佳配置。有关规划群集的详细要求列表，请参阅 （英文）和 Microsoft KB 文章 （Q259267，英文）。

重要的决策因素

　　在确定群集配置之前，应考虑有关群集元素的以下信息。

BizTalk Messaging

　　可以将 BizTalk Server 的实例配置为执行接收函数、处理/发送函数或两者兼顾。本文主要讨论接收消息排队消息。在初始设置之后，您只需添加独立的服务器以帮助分担负载即可方便地进行扩展，以便进行更多的处理。如果计划在执行接收函数过程中频繁使用消息排队，则最好选择至少一个群集节点来专门负责此类接收活动。

　　可以调整 BizTalk Server 和消息排队以获取快速读取和存储消息排队消息的性能。花些时间执行一个小型的模拟测试将有助于评估此活动的服务器负载。

SQL Server

如果数据库负载并非是关键问题，则可以将 Microsoft SQL Server 安装在与 BizTalk Server 相同的群集节点上，以优化性能。服务器的大小需要进行相应调整，并且在这种情况下每个群集通常至少需要两个处理器。

但在以下情况下，则需要将 SQL Server 安装在其自己专用的群集节点上：

　　◆将有很多处理服务器访问 BizTalk Server 数据库，从而大大增加了 SQL Server 实例的负载。

　　◆将频繁使用 BizTalk Server 的跟踪功能。

　　◆消息排队和 BizTalk Messaging 的模拟测试结果表明，有必要专门使用一台服务器执行 BizTalk Messaging 并将数据库活动移到单独的服务器上。

　　◆需要很大的空间以备将来扩展使用。

BizTalk Orchestration

如果 BizTalk Orchestration 功能的使用较少，则可以在与 BizTalk Messaging 相同的组中运行 XLANG Scheduling Engine。由于 BizTalk Orchestration 要频繁使用消息排队，通过限制全局配置中组和磁盘资源的数量，可以使群集配置变得更简单。

然而，由于并发运行多个计划，频繁使用 BizTalk Orchestration 会导致 CPU 的使用率较高并增加内存消耗。在这些情况下，必须使用缓冲机制来防止并发运行的计划数量超出服务器的处理能力。也可以在单独的计算机上运行 XLANG Scheduler Engine。可以选择将其放在 Biztalk Messaging 的被动节点上，即，BizTalk Messaging 正常情况下在节点 A 上运行，而 BizTalk Orchestration 正常情况下在节点 B 上运行。

以这种方式将 BizTalk Server 的两个基本组件分开还可以简化稍后进行的优化各节点性能的操作。

为确保 BizTalk Orchestration 能提供容错能力，需要确保永久保存了存储在内存中的数据。这可以通过使用事务控制来完成。有关 BizTalk Orchestration 事务控制的详细信息，请参阅 Orchestration Part 2:Transactions, Exceptions, Debugging（英文）。

　　重要信息：注意，有时所有资源组可能需要在同一个群集节点上运行一段时间。因此，每个节点都应该具有足够的内存和足够的 CPU 资源以处理上述情况。

硬件因素

规划群集配置时需要考虑的一个主要因素就是硬件成本。各大硬件厂商提供了很多可供选择的硬件产品，从基本的共享小型计算机系统接口 (SCSI) 磁盘阵列到完整的存储区域网络 (SAN) 解决方案都有。

对于 SCSI 磁盘阵列，组中的磁盘资源通常相当于单独的物理磁盘驱动器阵列。每个阵列均配置为 RAID 5（使用奇偶校验进行拆分），或者有时候配置为 RAID 10 （同时使用拆分和镜像）。像 SAN 这样的比较昂贵的解决方案则提供了更加灵活的方法，包括使用光纤信道交换。不管选择何种硬件，都请确保它在 Microsoft Windows Hardware Compatibility List（英文）范围之内。

从简单性角度来讲，最简单的群集配置就是主动/被动配置，其中所有必要的 BizTalk Server 资源都属于一个组。

图 11 显示的就是这样一个配置。建议选择一个单独的磁盘作为仲裁磁盘。在这类配置中，磁盘子系统具有两个单独的磁盘阵列。

　　注意： 在整篇文章中都将涉及到仲裁磁盘，它是一个共享磁盘，群集服务使用它来存储有关群集配置和群集资源状态的重要信息。因此，建议使用大约具有 500 MB（最少 100 MB）磁盘资源的单独组作为仲裁磁盘。

图 11：简单的主动/被动配置

如果性能是至关重要的因素，则可能需要附加组以使 SQL Server 和/或 BizTalk Orchestration 可以在另一个群集节点上运行，如下图所示。这种情况需要使用三组磁盘阵列。此配置使得两个节点互相作为对方的主动/被动备用节点。

图 12：两个节点都处于主动状态并且互为对方的被动备用节点

BizTalk Server 群集设置要求

　　有关确保您的硬件与 Windows 群集服务兼容以及有关设置和安装群集服务的详细信息，请参阅 Microsoft KB 文章 （Q259267，英文）和 （英文）中的核对表。将要加入群集的每台计算机还要考虑以下针对 BizTalk Server 的特定要求。

大小设置原则

每台计算机都需要有足够的 CPU、内存和磁盘空间，以便在故障转移到单个节点上时能处理所有的群集资源。只有对预计的吞吐量进行分析并进行负载模拟测试，才能得出准确的服务器要求。不过，这里也有一些设置服务器大小的通用原则：

　　◆CPU。在低容量的情况下可以允许每个节点配备一个 CPU，但在故障转移群集中则可能行不通。无论是所有资源都在单个节点上运行，还是将组分到两个节点上，都需要具有足够的容量以处理高峰期间的负载。由于要接管发生故障的节点的资源，故障转移可能会大大降低该节点上 CPU 的处理能力。因此，建议至少使用两个 CPU，并且需要使用随本文提供的工具通过负载模拟测试来加以验证。

　　◆内存。确保所有节点都具有足够的内存，以便在发生故障转移时执行所有的处理任务。作为通用原则，如果 BizTalk Messaging、BizTalk Orchestration 或 SQL Server 三者只有一个位于群集节点上，则服务器的最低内存配置可为 1 GB。如果 BizTalk Messaging、BizTalk Orchestration 或 SQL Server 三者中的任何两个位于同一个节点上，则每个节点（将 SQL Server 的最大内存使用量设置为 1 GB）至少需要 2 GB，如果三者都位于同一个群集节点上，则至少需要 3 GB。

　　◆磁盘存储要求。最好为消息排队保留 2 GB（最多），至少为 BizTalk Server 数据库保留 50 GB。Tracking 数据库消耗的空间最多，并且会根据容量和所选择的跟踪选项而迅速增长。如果对跟踪没有什么要求（这不太可能），或者吞吐量很小，则磁盘空间的要求要小得多。

软件要求

需要以下软件产品和相应的许可证：

　　◆Windows 2000 Advanced Server 或具有 SP2 或更高版本的 Windows 2000 Datacenter Server

　　◆具有 SP1 或更高版本的 Microsoft SQL Server 2000 Enterprise Edition

　　　　注意：不管是在与 BizTalk Server 相同的群集上还是在单独的群集上，这里都假设 SQL Server 被群集为 BizTalk Server 的任何高可用性解决方案的一部分。

　　◆具有 SP1A 或更高版本的 BizTalk Server 2000 Enterprise Edition，或者包含 BizTalk Orchestration（可选）的 BizTalk Server 2002 Enterprise Edition

　　◆Microsoft Visio® 2000 标准版 SR-1A（可选，仅在针对 BizTalk Orchestration 节点的设计时体验时才会需要）

群集设置



升级到 Biztalk Server 2002

以下步骤假设您已经按照本文所介绍的那样配置了 BizTalk Server 2000，并且 BizTalk Server 2000 能在群集环境下正确运行。
　　　注意：请阅读光盘附带的 BizTalk Server 2002 安装说明，确保已执行了所有预备安装步骤。

　　1.启动 Cluster Administrator（群集管理器），将 BizTalk Messaging Group（BizTalk Messaging 组）和 BizTalk Orchestration Group（BizTalk Orchestration 组）移到节点 1。

　　2.将所有与 BizTalk Server 相关的资源脱机：BizTalk Messaging Service、IInterchange 应用程序、XLANG Scheduler 和 XLANG Schedule Restart Service。

　　3.将 BizTalk Server 2002 光盘放入节点 1 的 CD-ROM 驱动器，然后从根文件夹下运行 Setup.exe。

　　4.在警告对话框中，单击 OK（确定）。

　　5.在 Customer Information（客户信息）页上，在 User name（用户名）框中键入您的姓名，在 Organization（单位）框中键入您的公司名，然后单击 Next（下一步）。

　　6.在 Destination Folder（目标文件夹）页上，单击 Next（下一步）以升级安装在默认目录中的 BizTalk Server。

　　7.在 Setup Type（安装类型）页上，选择 Complete（完整），并单击 Next（下一步）。

　　　　注意：所有现有的 BizTalk Server 文件在升级过程中都将被删除。并且只安装选定的功能。

　　8.在 Configure BizTalk Server Administrative Access（配置 BizTalk Server 管理权限）页上，保留默认信息并单击 Next（下一步）。

　　9.在 Microsoft BizTalk Server Service Log On Properties（Microsoft BizTalk Server Service 登录属性）页上，接受默认设置 This account（本帐户），然后键入将用于启动 BizTalk 服务的帐户。

　　　　注意：建议使用与群集服务相同的帐户。

　　10.在 Ready to Install the Program（准备安装程序）页上，单击 Install（安装）。

　　11.当屏幕显示 Welcome to Microsoft BizTalk Server 2002 Messaging Database Setup Wizard（欢迎使用 Microsoft BizTalk Server 2002 Messaging 数据库安装向导）页时，单击 Next（下一步）。

　　12.在 Configure a BizTalk Messaging Management Database（配置 BizTalk Messaging Management 数据库）页上，单击 Select an existing database（选择现有数据库），然后在 SQL Server connection parameters（SQL Server 连接参数）下，键入 SQL Server 虚拟服务器的名称并单击 Next（下一步）。

　　13.在警告对话框中，单击 Yes（是）。

　　14.在 Configure a BizTalk Server Group（配置 BizTalk Server 组）页上，单击 Select an existing BizTalk Server group（选择现有 BizTalk Server 组），然后单击 Next（下一步）。

　　15.在警告对话框中，单击 Yes（是）。

　　16.在 Verify BizTalk Server Group（验证 BizTalk Server 组）页上，单击 Next（下一步）。

　　17.在 Completing the Microsoft BizTalk Server 2002 Messaging Database Setup Wizard（完成 Microsoft BizTalk Server 2002 Messaging 数据库安装向导）页上，单击 Finish（完成）。

　　18.在 Welcome to the Microsoft BizTalk Server 2002 Orchestration Persistence Database Setup Wizard（欢迎使用 Microsoft BizTalk Server 2002 Orchestration Persistence 数据库安装向导）页上，单击 Next（下一步）。

　　19.在 Configure a Default Orchestration Persistence Database（配置默认 Orchestration Persistence 数据库）页上，单击 Select an existing database（选择现有数据库），然后在 SQL Server connection parameters（SQL Server 连接参数）下，键入 SQL Server 虚拟服务器的名称并单击 Finish（完成）。

　　20.在 Completing the Microsoft BizTalk Server 2002 Setup Wizard（完成 Microsoft BizTalk Server 2002 安装向导）页上，单击 Finish（完成）。

　　21.在“开始”菜单上，指向“设置”，然后单击“控制面板”。双击“管理工具”，然后双击“服务”。屏幕将显示“服务”窗口。

　　22.双击“管理工具”，然后双击“服务”。屏幕将显示“服务”窗口。

　　23.单击 Log On（登录）选项卡。验证启动帐户是一个具有足够权限的域帐户。此帐户必须是群集中每个节点的本地管理员。此外，如果 BizTalk Server 需要在其他网络服务器上写入消息排队或文件共享，则需要具有足够的域级权限。

　　24.单击 General（常规）选项卡。在 Startup type（启动类型）中选择 Manual（手动）。在 Service Status（服务状态）区域，单击 Stop（停止）。

　　25.单击 OK（确定）。

　　26.双击 XLANG Schedule Restart Service。屏幕将显示 XLANG Schedule Restart Service Properties（XLANG Schedule Restart Service 属性）窗口。

　　27.单击 Log On（登录）选项卡。将启动帐户设置为一个具有足够权限的域帐户。此帐户必须是群集中每个节点的本地管理员。此外，如果 BizTalk Server 需要在其他网络服务器上写入消息排队或文件共享，则需要具有足够的域级权限。

　　28.单击 General（常规）选项卡。在 Startup type（启动类型）中选择 Manual（手动）。在 Service Status（服务状态）区域，单击 Stop（停止）。

　　29.单击 OK（确定）。

　　30.在节点 2 上重复步骤 3 到 29。

　　31.在“开始”菜单上，指向“程序”，指向“Microsoft BizTalk Server 2002”，然后单击 BizTalk Server Administration（BizTalk Server 管理）。屏幕将显示 BizTalk Server Administration（BizTalk Server 管理）窗口。

　　32.在安装 BizTalk Server 资源的群集资源组中单击虚拟网络的名称。网络名称必须处于联机状态才能执行后面的步骤。

　　33.在群集中的一个非活动节点上打开 BizTalk Server Administration（BizTalk Server 管理）。

　　34.删除所有显示在 BizTalk Server 组中的服务器（它们是单个群集节点的名称），只保留 BizTalk Server 虚拟服务器。

　　对服务器组中列出的每台计算机，执行以下步骤：

　　　　a.在 BizTalk Server Group（BizTalk Server 组）中，单击计算机的名称。在 Action（操作）菜单上，单击 Stop（停止）。

　　　　b.要从组中删除服务器，请在 Action（操作）菜单上单击 Delete（删除）。

疑难解答

在设置 BizTalk Server 和配置群集时可能会出现一些已知的问题。下面的疑难解答可以提供一些帮助。

有关升级信息和最新消息，请参阅 （英文）Web 站点和 （英文）Web 站点，并搜索 BizTalk Server Knowledge Base 文章。

BizTalk Server 安装程序无法启动

我们已经发现，如果发生以下事件序列，则会显示一则错误消息：

　　1.BizTalk Server 安装在群集的节点 A 上，而节点 A 是一个主动节点（控制共享驱动器）。

　　2.将群集资源的控制权转移到节点 B。

　　3.从节点 A 卸载 BizTalk Server。

　　4.最后，尝试在节点 A 上重新安装 BizTalk Server。

针对此问题，可以采取避免或更正两种措施。要避免此问题，在安装时请确保该组位于本地。要在问题发生后进行更正，请使用 Microsoft 平台软件开发包 (SDK) 运行命令 msizap.exe 以清除注册表，从而使 BizTalk Server 可以再次安装和卸载。

启动了 XLANG Scheduler 的另一个副本

从“开始”菜单的命令提示符中打开 XLANG Monitor 应用程序时，XLANG Scheduler 的另一个副本被启动。发生这种情况时，BizTalk Server 将无法正常工作，用户需要费很大的周折才能找出要停止的 dllhost.exe 进程。

要避免此问题，请执行以下步骤为 XLANG Monitor 创建群集资源：

　　1.启动 Cluster Administrator（群集管理器）。

　　2.右击 BizTalk Orchestration Group（BizTalk Orchestration 组），指向 New（新建），然后单击 Resource（资源）。

　　3.在 Name（名称）框中，键入 Command Prompt（命令提示）。在 Resource type（资源类型）列表中，选择 Generic Application（一般应用程序），然后单击 Next（下一步）。

　　4.在 Possible Owners（可能的所有者）窗口中，允许资源在群集中的所有服务器上运行。单击 Next（下一步）。

　　5.在 Dependencies（相关性）窗口中，在资源中添加以下相关性：

　　　　◆网络名称

　　6.单击 Next（下一步）。将显示 Generic Application Parameters（一般应用程序参数）屏幕。

　　7.在 Command line（命令行）框中，键入 CMD.exe。

　　　　注意：此命令在每个节点本地运行。如果它们在您的服务器上的位置不同，请更改 Windows 系统路径和驱动器号。

　　8.在 Current directory（当前目录）框中，键入 BizTalk Orchestration 组的共享目录的驱动器号。

　　9.选择 Allow application to interact with desktop（允许应用程序与桌面交互）和 Use Network Name for computer name（将网络名用作计算机名）复选框。单击 Next（下一步）。

　　10.在 Registry Replication（注册表复制）窗口中，单击 Finish（完成）。

　　11.创建资源后，双击 Command Prompt（命令提示）资源以编辑 Properties（属性）。

　　单击 Advanced（高级）选项卡，清除 Restart（重新启动）部分中的 Affect the group（影响组），然后选择 Do not restart（不重新启动）。单击 OK（确定）接受更改。

　　12.要启动 XLANG Monitor，请双击创建的 Command Prompt（命令提示）资源，然后键入 XLANGMon.exe。

启动了 XLANG Monitor 的另一个副本

当从中启动 XLANG Monitor 的节点太慢时，会启动 XLANG Monitor 应用程序的另一个副本。发生这种情况时，BizTalk Server 将无法正常工作，用户需要费很大的周折才能找出要停止的 dllhost.exe 进程。

要避免此问题，建议您从远程非群集计算机上启动 XLANG Monitor 应用程序。

BizTalk Server 2002 上发生致命性问题故障转移时会造成数据丢失

在 BizTalk Server 2002 中，在发生致命性故障（如电源故障）时将造成非事务性传输的数据丢失。在发生致命性故障时，也可能会复制使用非事务性传输方式传输的文档。要避免在这种故障中丢失数据，必须禁用磁盘缓存。但是禁用磁盘缓存会降低 BizTalk Server 2002 的性能。

在 BizTalk Server 2000 中不会出现数据丢失的情况，但仍可能会复制使用非事务性传输方式传输的文档。