原文地址：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 群集簡單地稱為群集。）

為 Microsoft 平臺設計的端到端系統大多包含這兩種技術。正如您在圖 1 中所看到的，Microsoft 群集服務用于數據服務器，而 Application Center 2000 群集則用于 Web 和 COM+ 負載平衡。（為了清晰起見，這里省略了防火墻及其他的網絡設備。）

這里有三種類型的群集能夠使用 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 ）。

最頂層是用戶界面。有三個用戶界面：Microsoft 管理控制臺 (MMC) 管理單元（參見圖 4 ），Web 瀏覽器界面（主要是用于查看狀態的只讀），以及命令行接口。在中間層，功能組負責大部分的產品功能。Application Center 群集服務負責維護群集成員以及狀態信息。同步和部署服務負責維護群集成員使其與群集控制器同步，既包括配置（網絡設置）方面也包括內容方面（Application Center 應用程序）。另外，部署模塊提供了群集內和群集間應用程序的分段和部署服務。負載平衡子系統使群集中每一臺計算機上的 NLB 設置（以及其他網絡設置）同步。

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，您將需要兩個網絡適配器。

管理員通過 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 或者從命令行工具來完成這一任務。

把 COM+ 應用程序放到與 Web 服務器不同的群集中并不總是最佳的方案。這樣做的優勢在于，多個 Web 群集能共享單個 COM+ 群集，而且您可以把 Web 應用程序與 COM+ 應用程序分開。不利方面是，您將經歷較長的滯后時間，對于管理員來說這樣的解決方案更為復雜，而且您必須事先決定如何在兩個層之間劃分硬件。在做出決定之前，請仔細審視一下您的應用程序以及您在運行多個群集方面的經驗。

監視您的群集

雖然本文集中討論由 Application Center 提供的在部署應用程序方面的功能，但我將快速地介紹一下它強大的監視功能。我最喜歡的功能是在一個顯示界面上監視來自所有計算機的事件，如圖 7 所示。操作員能夠根據事件來自哪臺機器、事件的嚴重程度或產生它們的應用程序來篩選事件。另外，操作員能夠監視很多計數器（參見圖 4 ）。.

最后，系統管理員可以把性能計數器與特定的閾值相關聯。閾值能在全局的（整個群集）或局部的（特定的計算機）基礎上設置。當超過某個閾值時，將產生一個操作。圖 8 顯示了許多可能的操作。注意，Application Center 提供在群集中復制監視器、閾值和操作的能力 — 這意味著您能夠在控制器上定義這樣的概念并自動將它們應用到所有的成員上。

編寫 Application Center 2000 腳本

我喜愛圖形用戶界面，因為它們使您能夠快速瀏覽一個產品的功能。另一方面，我不喜歡反復做同樣的事，從發展群集到階段群集以及產品群集。幸運的是，在過去的幾年里，大部分從 Redmond 出來的產品（包括 Application Center），既提供了圖形界面又提供了編程管理界面。

當我第一次試用該產品時，我希望找到一個基于自動控制的 API，那樣我就能夠用我喜歡的腳本語言編寫腳本。結果并非如此。取而代之的是，Microsoft 提供了一個叫做 Application Center 的命令行程序，可以直接從一個基于 MS-DOS 的批處理文件或者間接地通過 Windows 腳本宿主 (WSH) 對象從 JScript 或 VBScript 來使用。
命令行允許您執行 GUI 也提供的大多數功能。例如，圖 9 中所示的代碼顯示了如何創建一個新的群集、加入幾臺機器、創建一個應用程序并部署它。

小結

使用普通的硬件構建高可用和可伸縮的計算工具在相當一段時間里只是一個幻想。使之可以實現的硬件都已存在了，但是管理這種群集的花費相當可觀，還有全部所有權的花費。現在，Application Center 2000 提供了能簡化這種群集管理的軟件層。