集群

原文地址：http://www.microsoft.com/china/MSDN/library/windev/COMponentdev/CdappCEnter.mspx?mfr=true

本文假设读者熟悉 Windows 2000、COM+、IIS 5.0

摘要 Application Center 2000 简化了从基于 Microsoft .NET 的应用程序到群集的部署，群集是一组无共享、松耦合的计算机，就像一台虚拟计算机一样。它允许 Application Center 2000 群集中的所有计算机同时提供相同的服务或 Web 应用程序。本文阐释了用 Application Center 2000 实现的网络负载平衡和 COM+ 组件的组件负载平衡。同时还包含了 MMC 管理单元接口以及用于批量管理任务的命令行接口以及 Application Center 2000 特性。

当 Web 站点的通信量增加时，必须找到一个处理负载的方法。升级为最新的计算机模型或者甚至去预先估算负载都是几乎不可行的。因此，您需要一个可伸缩的解决方案来管理负载，该方案由一台或两台计算机开始，当负载增加时扩展为多台计算机。大多数高容量的 Web 站点通过 Web 服务器场来处理它们的负载，服务器场是一组自治的计算机，它们共同提供了一个功能强大的单一服务器的假象。这种配置同时也能提供高可用性，如果其中一台计算机由于维护而停机或发生硬件故障，用户将察觉不到。

如果您已经在 Windows 上部署过 Web 服务器场，那么 Microsoft Application Center 2000 正是您曾经希望拥有的产品。Application Center 2000 简化了将基于 Windows 的应用程序部署到一组计算机及其相关的管理工作。另外，它为 COM+ 组件提供了一个负载平衡的解决方案。组件负载平衡 (CLB) 服务对于需要将中间层部署在不同的物理层的计算密集型服务来说十分理想。

在阐述了 Application Center 2000 群集、其应用程序及体系结构之后，我将说明 Application Center 2000 如何为应用程序和 COM+ 组件处理负载平衡。尽管本文的主要目的是阐述用 Application Center 2000 进行应用程序部署，但我还是要简要介绍一下它的监视功能以及为常见管理任务编写脚本的选项。
本文基于 Application Center 2000 的 Beta 2 版。当您阅读这篇文章时，一些细节可能已经有所改变。

Application Center 2000 群集

Windows DNA 最初支持一种类型的群集，即 Microsoft 群集服务 (MSCS) 群集。MSCS 群集是一组计算机，提供了服务器应用程序资源（如数据库或消息队列）的故障转移。在任何时候，服务的实例只能由群集中的一台计算机提供。如果提供该服务的计算机发生故障，群集中的另一台计算机将获取该服务的资源并开始提供服务。运行在群集上的分布式系统服务将这些事件通知给应用程序，并确保每次只有一台计算机拥有资源。MSCS 还要求一个共享的磁盘资源。

.NET 企业级服务器引入（更确切地说，正式推出）了第二种群集类型 — Application Center 2000 群集。Application Center 2000 群集是一组无共享、松散耦合的计算机，就像是一台虚拟的计算机一样。与 MSCS 群集不同，Application Center 2000 群集中的所有计算机同时提供相同的服务（Web 应用程序）。当请求到达时，它们被传送到群集中的任何一台计算机。当一台计算机出现故障时，以后的请求将被送到群集中的其他计算机。这使得 Application Center 2000 群集既提供了服务的可伸缩性又提供了服务高度的可用性。

任何一个从零开始编写的应用程序可以为任何一种模型而编写。然而，如果您想移植一个现有的应用程序以利用多台计算机，情况就不同了。Application Center 群集对于那些不共享任何状态或者共享只读状态的应用程序是非常理想的。例如，一个提供静态或动态内容的 Web 服务器是 Application Center 2000 群集理想的候选者。另一方面，MSCS 群集对于那些共享大量读/写数据的服务来说更为适合。Microsoft SQL Server —— 以及 Exchange Server 就是这类应用程序很好例子。预计 MSCS 的未来版本将提供对负载平衡的支持以及群集中多台计算机的支持，从而模糊了两类群集的差别。（注意，下文中我将把 Application Center 2000 群集简单地称为群集。）

图 1 群集体系结构

为 Microsoft 平台设计的端到端系统大多包含这两种技术。正如您在图 1 中所看到的，Microsoft 群集服务用于数据服务器，而 Application Center 2000 群集则用于 Web 和 COM+ 负载平衡。（为了清晰起见，这里省略了防火墙及其他的网络设备。）

图 2 Application Center 的多功能性

这里有三种类型的群集能够使用 Application Center 技术：Web 群集、COM+ 应用程序群集，以及 COM+ 路由群集（参见图 2 ）。根据应用程序的负载以及使用方法，您可能需要在一个或多个这些方案中使用 Application Center。使用网络负载平衡 (NLB) 服务或其他基于硬件的负载平衡产品，Web 群集将 HTTP 请求分发到一组 Web 服务器。注意 Windows 2000 Advanced Server 并不是必须运行 NLB。Application Center 2000 使 NLB 在 Windows 2000 Server 上也能运行。COM+ 应用程序群集处理 DCOM 通信流量。在大多数情况下，并不需要 COM+ 路由群集。

返回页首

Application Center 2000 应用程序

在早些时候，一个应用程序等同于一个单块的可执行程序。在随 Microsoft 事务服务 (MTS) 引入并用 COM+ 改良了的新的组件领域里，一个应用程序是一组配置组件。Application Center 2000 对于应用程序是什么有着更自由的观点。在 Application Center 2000 里，一个应用程序是下列资源的集合：

•

Web 站点及其相关配置（比如证书）。

•

文件系统层次结构（以及相关的权限中心）。

•

COM+ 应用程序。

•

注册表层次结构。

•

ODBC 数据源 (DSN)。

如果您曾经为了将应用程序部署到数据中心而打包过应用程序，那么您应该很熟悉这些部分了。在下文中，我所提到的应用程序是指 Application Center 2000 应用程序。

返回页首

Application Center 的体系结构

Application Center 的体系结构由三层组成：用户界面、功能集以及操作系统（参见图 3 ）。

图 3 Application Center 2000 体系结构

最顶层是用户界面。有三个用户界面：Microsoft 管理控制台 (MMC) 管理单元（参见图 4 ），Web 浏览器界面（主要是用于查看状态的只读），以及命令行接口。在中间层，功能组负责大部分的产品功能。Application Center 群集服务负责维护群集成员以及状态信息。同步和部署服务负责维护群集成员使其与群集控制器同步，既包括配置（网络设置）方面也包括内容方面（Application Center 应用程序）。另外，部署模块提供了群集内和群集间应用程序的分段和部署服务。负载平衡子系统使群集中每一台计算机上的 NLB 设置（以及其他网络设置）同步。

图 4 用 MMC 管理 Application Center

Application Center 还以 ISAPI 筛选器及扩展的形式提供请求转发服务。这一机制既有助于维护跨群集的会话状态以减轻大量代理的问题，又透明地将 Microsoft FrontPage 和 WebDAV 的发布请求路由到群集控制器。监视、日志记录以及运行状况服务子系统从群集的所有成员汇集信息。

最底层是操作系统及其服务。Microsoft 管理控制台 1.2 和 Microsoft Internet Explorer 技术 (DHTML、VML、XML) 广泛地用于 UI 服务。Windows 管理规范 (WMI) 用于搜集管理信息。Microsoft Internet 信息服务 (IIS) 5.0 中的元数据库用于存储群集和服务器的配置设置。网络负载平衡集成在产品中，但并非必需。最后，Microsoft SQL Server 2000 桌面引擎大量用于存储日志记录和监视信息。

返回页首

群集控制器

每一个群集都需要一台指派为群集控制器的机器。群集控制器通常是加入群集的第一台计算机。这能够在任何时刻被更改以增加增强的可靠性（换句话说，如果控制器因为种种原因而停止了，用户能够立刻选择其他群集成员来接管控制器的角色）。
该原理是，在群集控制器上安装应用程序，并使群集控制器与群集中的其他计算机相一致以使应用程序以及将来的更改同步。

群集中的每一台计算机都需要安装 Application Center 2000。Application Center 2000 要求 Windows 2000 Server 或 Advanced Server 及 Service Pack 1。计算机应该有至少 256MB RAM 以及大约 130MB 的可用磁盘空间。另外，如果您计划使用 NLB，您将需要两个网络适配器。

图 5 Application Center MMC 管理单元

管理员通过 MMC 管理群集，如图 4 所示。您能够通过管理单元控制群集中的成员并定义应用程序（参见图 5 ）。例如，正如您在图 5 中所见，例子包括一个叫做 library 的 Web 应用程序。该应用程序的文件存储在路径 c:/program files/HealtheonWebMD 下。它有一个叫做 library 的 Web 站点并使用 IIS 组件进行了配置。所有的 COM+ 组件通过组件服务管理单元被配置到一个叫做 library 的 COM+ 应用程序中。最后，位于 HKEY_ LOCAL_MACHINE/Software/Healtheon 下的注册表项是 library 应用程序的一部分，因为它包含诸如到数据源的连接字符串这类的设置。当我下一次同步群集时，群集中的所有计算机都将具有相同的键和值。对于 COM+ 应用程序、Web 站点设置以及文件路径同样适用。如果您曾经有一个由 10 台计算机组成的群集，而且您需要修改一个注册表项，该功能将非常合适。

返回页首

IP 负载平衡

那么假定已设置了群集并将内容和应用程序复制到了所有的计算机。您已准备好为客户服务，但请等一下。您想给他们什么 IP 地址呢？如果提供群集中任何一台计算机的 IP 地址，那么该计算机将过载。您想给出一个地址并希望把请求动态分配给群集的成员。传统的 DNS 循环法解决方案将一个 DNS 域名映射到多个 IP 地址。虽然这种解决方案在许多 Web 站点工作良好，不过一旦出现故障就会产生问题，因为从 DNS 名到 DNS 地址的映射都被缓存起来了。

更好的解决方案是基于一个虚拟的 IP 地址，该地址被动态映射到其中一个真实的 IP 地址。例如，假设您有三台服务器，地址分别为 10.4.0.10、10.4.0.11 和 10.4.0.12。使用一个虚拟的 IP 地址（如 10.4.0.15），所有的请求将到达这个虚拟的 IP 地址，然后被路由到其中一个服务器。虚拟 IP 地址可以通过像 NLB 这类的软件或硬件进行设置。如果在产品环境中使用了硬件，您多半应该使用两个这样的硬件以避免出现单一故障点。

在 Windows NT 4.0 和 Windows 2000 中有一个软件解决方案来解决映射问题。网络负载平衡是 Windows 2000 Advanced Server 和 Windows 2000 Datacenter Server 的一部分（也可以通过 Application Center 2000 在 Windows 2000 Server 中使用）。当您使用 Application Center 部署 NLB 时，需要每台机器上有两个网络接口卡 (NIC)。接着 NLB 被绑定到其中一个 NIC 上。当请求发送到虚拟地址时，该请求被传送到群集中所有计算机的网络子系统。不过只有一台计算机处理这个请求。计算机以固定的时间间隔进行通信以确定哪一台计算机将获得哪些包。当群集中的一台机器发生故障，负载将自动在其他机器上重新分配。
NLB 支持每个群集中多达 32 台服务器。在最多 12 个节点的群集上（Application Center 所支持的群集中的最大节点数），测试显示 CPU 的系统开销相当的低。例如，对于一个处理的信息流量为 100MB/s 的四台服务器的群集来说，Microsoft 测得每台服务器的一个处理器上筛选和数据传输的系统开销仅为大约百分之 4 至 7。另外，既然只有一小部分的 NLB CPU 系统开销分配给了滞后时间，那么当群集中服务器数目增加时，吞吐量和响应时间的比例几乎是线性的。有关 NLB 性能的更多详情，请查看http://www.microsoft.com/windows2000/ techinfo/howitworks/cluster/nlb.asp。

返回页首

组件负载平衡

在一个使用 Windows 2000 的多层应用程序中，您可以决定将不同的逻辑层部署到不同的物理群集中。当一个应用程序对计算资源要求很高时，这样做将非常有意义。例如，搜索的核心函数就是一个希望把它放到其自己群集中的应用程序层很好的例子。现在，假设搜索函数被写成一个 COM+ 应用程序，您再次面临负载平衡请求的问题。在 Web 服务器案例中，请求是从 Web 浏览器到 Web 服务器的 HTTP 请求。在本案例中，请求来自 COM/COM+ 客户端（一个激活 COM+ 应用程序的 ASP 页面），发送至 COM+ 服务器。MSDN 及别处的若干文章已经讨论过这一问题，包括 1997 年 7 月 MSJ 中 Don Box 的 ActiveX/COM Q&A。所有这些文章都要求一定程度的自定义编程。

CLB 是作为 Application Center 2000 的一部分发布的，允许 COM+ 负载平衡而不需要进行任何自定义编程。为了使用 CLB，您需要在调用层（通常是 Web 服务器群集）和被调用层上安装 Application Center 2000 和 COM+ 应用程序。在调用层，从组件服务管理单元为负载平衡标识组件（参见图 6 ）。选中 “Component supports dynamic load balancing” 选项，使得对于该组件的调用在 CLB 路由列表中的服务器间进行负载平衡。您将会发现，负载平衡不支持那些支持事件的组件。
另外，您需要创建一个请求将被路由到的计算机的列表。可以从 Application Center 2000 管理单元 MMC 或者从命令行工具来完成这一任务。

图 6 组件服务管理单元

把 COM+ 应用程序放到与 Web 服务器不同的群集中并不总是最佳的方案。这样做的优势在于，多个 Web 群集能共享单个 COM+ 群集，而且您可以把 Web 应用程序与 COM+ 应用程序分开。不利方面是，您将经历较长的滞后时间，对于管理员来说这样的解决方案更为复杂，而且您必须事先决定如何在两个层之间划分硬件。在做出决定之前，请仔细审视一下您的应用程序以及您在运行多个群集方面的经验。

返回页首

监视您的群集

虽然本文集中讨论由 Application Center 提供的在部署应用程序方面的功能，但我将快速地介绍一下它强大的监视功能。我最喜欢的功能是在一个显示界面上监视来自所有计算机的事件，如图 7 所示。操作员能够根据事件来自哪台机器、事件的严重程度或产生它们的应用程序来筛选事件。另外，操作员能够监视很多计数器（参见图 4 ）。.

图 7 一次监视所有机器

最后，系统管理员可以把性能计数器与特定的阈值相关联。阈值能在全局的（整个群集）或局部的（特定的计算机）基础上设置。当超过某个阈值时，将产生一个操作。图 8 显示了许多可能的操作。注意，Application Center 提供在群集中复制监视器、阈值和操作的能力 — 这意味着您能够在控制器上定义这样的概念并自动将它们应用到所有的成员上。

返回页首

编写 Application Center 2000 脚本

我喜爱图形用户界面，因为它们使您能够快速浏览一个产品的功能。另一方面，我不喜欢反复做同样的事，从发展群集到阶段群集以及产品群集。幸运的是，在过去的几年里，大部分从 Redmond 出来的产品（包括 Application Center），既提供了图形界面又提供了编程管理界面。

当我第一次试用该产品时，我希望找到一个基于自动控制的 API，那样我就能够用我喜欢的脚本语言编写脚本。结果并非如此。取而代之的是，Microsoft 提供了一个叫做 Application Center 的命令行程序，可以直接从一个基于 MS-DOS 的批处理文件或者间接地通过 Windows 脚本宿主 (WSH) 对象从 JScript 或 VBScript 来使用。
命令行允许您执行 GUI 也提供的大多数功能。例如，图 9 中所示的代码显示了如何创建一个新的群集、加入几台机器、创建一个应用程序并部署它。

返回页首

小结

使用普通的硬件构建高可用和可伸缩的计算工具在相当一段时间里只是一个幻想。使之可以实现的硬件都已存在了，但是管理这种群集的花费相当可观，还有全部所有权的花费。现在，Application Center 2000 提供了能简化这种群集管理的软件层。