發行日：2000 年 9 月

作者：Chris Rees

本文主旨為說明 Microsoft Application Center 2000 (Application Center) 元件負載平衡 (CLB) 技術。

簡介

Microsoft Application Center 2000 (Application Center) 為 Enterprise Server 的功能之一，而 Microsoft 就是使用 Enterprise Server 來建立 .NET 的基礎架構。Enterprise Server 還提供許多功能，包括 Commerce Server 2000、BizTalk Server 2000、SQL Server 2000 等。若需更多有關 .NET 的資訊，請參閱 http://www.microsoft.com/taiwan/net/。

Application Center 在 .NET 中，是負責為建立在 Windows 2000 及 Internet Information Server 5.0 之下的網站，提供內容佈署與各項管理工具。Application Center 讓網站更具擴充性、穩定性、容易管理和安全性。其中心架構是一個網站伺服器叢集，而這個叢集對於用戶端而言只是一個獨立的網站。除此之外，再加上一個複寫至所有叢集成員的獨立應用程式影像。此應用程式影像包含商務解決方案中所需的一切功能。其中包括網站、登錄設定值、檔案、COM+ 元件等等。管理者可透過事件、效能計數器 (Performance Counter)、以及顯示目前叢集狀態的監控程式，輕易監控叢集的狀態。

TOP

Application Center 叢集

使用 Application Center 可建立使用各種負載平衡 (Load Balance) 技術的多層叢集。負載平衡技術協助 Application Center 提供擴充性以及強固性。Application Center 支援的負載平衡技術有二：

• 網路負載平衡 (Network Load Balancing, NLB)

• 元件負載平衡 (Component Load Balancing, CLB)

Application Center 叢集的拓樸是決定負載平衡支援狀況的基礎。標準的 Application Center 叢集拓樸是以 n 層 (n-tier) 解決方案為基礎，其中包含將內容送至用戶端的網站層 (Web-tier) 叢集。而網站層叢集就是使用 IIS 和網路負載平衡 (NLB) 來滿足進入系統的 IP 要求。

圖 1 標準 Application Center 叢集拓樸

網站層的軟體 (ASP 網頁等) 可在本機電腦上建立並使用 COM+ 元件；或是利用 DCOM 功能，在遠端電腦上建立並使用 COM+ 元件。如果沒有 CLB，遠端的啟用動作將是靜態的，因為它並沒有將遠端伺服器上的工作量計算在內。這就是 CLB 的目的-為安裝在個別伺服器叢集中的 COM+ 元件，提供可自動防止故障、擴充且具負載平衡能力的啟用方式。

TOP

網路負載平衡

網路負載平衡 (NLB) 是 Windows 2000 Advanced Server 以及 Windows 2000 Data Center 所提供的 IP 負載平衡功能。使用 NLB 功能之後，不論是進入系統的 TCP 流量、使用者資料包通訊協定 (User Datagram Protocol，UDP) 流量、或是通用路由壓縮 (Generic Routing Encapsulation ,GRE) 流量等要求，都會分散到叢集的成員中。系統透過伺服器負載百分比設定值為基礎的統計演算法，來決定分散的方式。NLB 提供了動態的擴充能力，可自動協調叢集中伺服器的加入與移除，而不會對用戶端造成任何影響。NLB 的功能相當健全，它可以偵測到伺服器故障並以很輕鬆的方式，將它由運作中的叢集移除。

Application Center 大幅簡化 NLB 為基礎的叢集管理工作。Application Center 叢集建立精靈可自動的組態 NLB 設定值。相較於單獨使用 Windows 2000 而言，這簡易許多。使用 Application Center，便可輕易在叢集之中新增或移除伺服器，並使伺服器連線或離線。

TOP

元件負載平衡

元件負載平衡允許對 COM+ 元件執行負載平衡。COM+ 元件是一種經過編譯的可用軟體物件，其來自各種不同的程式語言包括 VBS、ASP、Visual Basic、以及 C++ 等。這類元件可將軟體製作成方便與可重覆使用的實體。在 CLB 中，系統將 COM+ 元件維護於不同的 COM+ 叢集的伺服器之中。系統會執行負載平衡，將啟用 COM+ 元件的呼叫分散至 COM+ 叢集的各個伺服器中。如圖 1，CLB 軟體的決策元件是在網站層中執行。而某些負責蒐集資訊的 CLB 軟體則是在 COM+ 叢集上執行的。

元件物件模型

CLB 的基本是由元件物件模型 (Component Object Model，COM) 所構成的元件架構。若某個以物件為基礎的軟體是以此規格寫成，則 COM 會提供一種通用的機制，透過這個機制，就可提供軟體服務。COM 允許使用不同的作業系統與語言來撰寫軟體。之所以能提供這樣的彈性，關鍵就在 COM 介面。

COM 元件是透過一或多個介面，將功能展露在外。要使用 COM 元件，用戶端軟體必須要採用瞭解如何與介面溝通的語言所寫成的。Visual Basic、ASP、VBS、JavaScript、Visual C++ 這幾些語言都做得到這點。介面本身只是一個數值資料表，它儲放著介面所支援的方法的所在位址。

Figure 2 COM 元件上的介面

COM 元件通常存在於動態連結程式庫 (DLL) 或是執行 (.exe) 檔中。它們可安裝在用戶端或遠端電腦上。遠端使用時，則是透過一種稱為分散式 COM (Distributed COM, DCOM) 的機制來進行呼叫，這種機制是以遠端程序呼叫 (Remote Procedure Calls, RPC) 為基礎。

COM+ 服務

COM+ 服務是 Windows 2000 作業系統的一部份，並且提供一套以 COM 及 Microsoft Transaction Server (MTS) 為基礎的服務。COM+ 服務提供了交易支援、物件存留時間服務、安全性服務、事件、佇列元件等企業版功能。

COM+ 元件

COM+ 元件即是可以使用 COM+ 服務各項功能的 COM 元件。COM+ 元件的必要條件之一是必須攜帶設定資訊。設定資訊是一組屬性，基本的 COM 架構可運用這組屬性，瞭解系統是否支援某項特定的 COM+ 服務，例如交易支援或是負載平衡等。

系統將 COM+ 元件聚集在一起，變成稱為「應用程式 (Application)」的各項套件，這種應用程式與 Application Center 應用程式並不相同。COM+ 應用程式是一群 COM+ 元件；而 Application Center 應用程式則是一種用於商務解決方案的資源清單，範例有網站、檔案、COM+ 元件、登錄機碼等。

TOP

元件負載平衡如何運作

CLB 主要有兩個部分：

• 用來對 COM+ 叢集執行負載平衡的 CLB 軟體。

• COM+ 叢集。(由 Application Center 管理的伺服器叢集，負責啟用及執行 COM+ 元件。)

CLB 軟體

CLB 軟體負責在啟用 COM+ 元件時，決定要以何種順序使用 COM+ 叢集成員。

由商業邏輯所組成的 COM+ 元件執行在網站層叢集中。當需要 COM+ 元件時，通常呼叫 Visual Basic ASP 的 CreateObject 指令。(系統內部會轉換成呼叫 CoCreateInstance)。在 CLB 中，系統會使用路由清單以及回應時間表，來協助將啟動 COM+ 元件的要求傳送到負載平衡的 COM+ 叢集，而不會直接在本機伺服器上建立元件。接下來，COM+ 叢集成員會建立元件，並將介面傳回用戶端。當元件建立完成後，CLB 與該元件就不會再有進一步的牽連了。

路由清單

路由清單存在於網站層叢集的每個成員中，並且包含參與行負載平衡的 COM+ 叢集成員的清單。請見圖 3。另外，還有另一個位置有路由清單的存在，即 COM+ 路由叢集。此叢集僅作路由之用，不具備網站層的功能。本文將重點放在網站層的各種案例。

圖 3 路由清單與回應時間

路由清單起初由網站層叢集控制站的管理員所建立，建立完後會自動同步化到每個叢集成員。因此，叢集成員的路由清單中不可能包含不同的 COM+ 叢集成員。每個網站層叢集成員都擁有路由清單有一個很大的好處，就是不會有單點故障的情形發生。如果某個網站層叢集成員停止作業 (不論是人為的與否)，其他成員透過路由清單仍會繼續對 COM+ 叢集執行負載平衡。

回應時間表

每隔 200 毫秒，執行在各個網站層叢集成員的 CLB 軟體就會輪詢所有成員的路由清單。系統依 COM+ 叢集成員的回應時間排名並在記憶體中建立一個資料表 - 也就是回應時間越快的成員在表中的位置越高。網站層成員按 round robin 方式使用回應時間表，將新進的啟動要求傳送給 COM+ 叢集成員。這表示當系統收到啟動要求時，會優先使用最快、最不忙碌的 COM+ 叢集成員，接下來的要求則分配給下一個速度略慢的叢集成員。資料表用完之後，下一個新進的要求將輪回到資料表中的第一個叢集成員。接下來的程序就和先前一樣了。這樣的程序會一直持續，直到下一次回應時間表的更新產生，更新完成後，系統就會依新的負載平衡表，重設啟動要求。

每一個網站層叢集成員都會維護自己的 COM+ 叢集成員回應時間表。系統並不會透過網站層叢集將這些值同步，因為複寫清單的速度趕不上 COM+ 叢集負載變化的速度。

COM+ 叢集

如同網站層叢集，管理員也是利用 Application Center 叢集建立精靈來建立 COM+ 叢集。叢集的所有成員都必須安裝相同的 COM+ 元件。您可使用佈署精靈來安裝元件。當建立完成後，元件必須知道它存在於 CLB 叢集之中。

叢集感知 COM+ 元件

要使用 CLB，COM+ 元件就必須瞭解其所在的狀況。 問題的關鍵就在於元件狀態。在 COM+ 中，元件無法保有每一個元件的狀態資訊，因為這會影響擴充性以及交易管理。擴充性會受影響是因為除非元件為無狀態，否則元件無法再使用。而交易管理則會變得更複雜，因為每一個元件的狀態無法穿越交易的界限。在使用 CLB 時需要更進一步的考慮。基本上，不要假定成員節點的所在位置，因為元件可能在 CLB 叢集中的任一個成員上建立。例如在 COM+ 中，整個行程的儲存體可用來儲存在伺服器上執行多個元件的有用資訊。在 COM+ 叢集中使用此功能時必須小心管理，因為我們無法確定元件會被建立在哪一個叢集成員中。因此，元件例項的後續重新啟動，就可能發生在不同的叢集成員身上。這會使得元件無法存取先前成員的整個行程的儲存體。

您必須儲存元件的狀態，有兩種方式可儲存元件的狀態：其一是可以使用永久性的狀態 (如 DBMS)，這樣所有叢集成員都可存取此資料；或者也可以儲存在用戶端，如儲存於 Internet 用戶端電腦的 cookie 資訊。

TOP

設定元件負載平衡

以下是設定 COM+ 叢集所需的步驟。下列說明皆是以 Application Center Beta 2 版本中的功能為準。

1. 設定叢集.

   執行 CLB 需要兩個叢集。一個叢集負責保存路由清單。就像先前所描述的，基本上這是位於網站層叢集上。另一個叢集則是 COM+ 叢集。請參閱線上說明的＜建立叢集＞這部分。

2. 將 COM+ 元件佈署至 COM+ 叢集。

   您可以使用佈署精靈，將 Application Center 應用程式佈署至其他叢集中。對用來將更新的內容佈署到產品叢集的 staging 叢集而言，這個功能就相當實用。請見圖 4. 通常您會由 Stager 執行佈署精靈，此 Stager 含有包含在 Application Center 應用程式中的 COM+ 元件。請參閱線上說明中的＜內容的佈署與同步＞。

   

   圖 4 Application Center 中的 Stager

   注意 在預設狀況下，系統並未佈署 COM+ 元件，這是因為元件佈署必須重新啟動 IIS 服務，且可能造成電腦重新啟動。然而，佈署精靈提供強制佈署 COM+ 元件的選項。

   因此，在佈署元件時如何避免整個叢集當機就相當重要。要達成這一點，就必須採用分階段的佈署方式：先使叢集成員離線、更新、再讓叢集成員連線。請參閱 Microsoft Application Center 2000 Resource Kit 以獲得關於此問題的進一步資訊。

3. 將 COM+ 元件佈署到網站層叢集

   若要使用 CLB，所有網站層叢集成員都必須安裝 COM+ 元件。同樣的，您也可以使用佈署精靈來執行這項工作。COM+ 元件可以包含在正被佈署到網站的 Application Center 應用程式中。請記得，佈署 COM+ 元件時，必須重新啟動 IIS 服務。因此，為確保網站仍可使用，就必須分階段佈署元件。另一個必須注意的地方是，網站層叢集元件的佈署必須與 COM+ 叢集同步。否則在網站中的網站層及 COM+ 叢集可能會分別安裝不同版本的元件。請參閱 Microsoft Application Center 2000 Resource Kit 以獲得進一步資訊。

4. 將網站層 COM+ 元件標記為支援 CLB。

   網站層叢集上的 COM+ 元件必須被標記為支援 CLB。要完成此工作，請由 Application Center 的嵌入式管理單元執行 Component Services Explorer。透過元件包含 COM+ 的應用程式展開並標記元件，請選擇 [屬性] 頁上的 [啟動] 標籤，再選擇 [支援動態負載平衡的元件] 核取方塊。

5. 建立路由清單

   路由清單是建立在網站層叢集控制站上，並且會自動的對整個網站層叢集做同步。您可使用 Application Center 中，網站層叢集 [內容] 頁中的元件 [服務] 標籤來新增 COM+ 叢集成員清單。

這樣就可以了。當所有的安裝完成之後，在 COM+ 叢集中所有以用戶端形式執行的網站層軟體，都會使用其所在位置的 COM+ 元件。

TOP

執行元件負載平衡

依照本節的指示，就可以很快看到 CLB 的執行狀況。本節假設您使用 Stager 將內容佈署至網站層及 COM+ 叢集。且假設您擁有 Visual Basic、ASP、以及 HTML 的操作知識。

1. 在 Stager 上使用 Visual Basic，建立一個匯出下列函數的 COM+ 元件。

   Public Function GetName() As String
Set WS = CreateObject("wscript.network")
GetName = WS.Computername
Set WS=nothing

End Function


2. 使用 COM+ Services Explorer 將此元件包含在 COM+ 應用程式之中。

3. 在 Stager 上建立包含此 COM+ 元件的 Application Center 應用程式。

4. 將 COM+ 元件佈署至 COM+ 叢集中。切記在佈署精靈中選擇[佈署 COM+ 應用程式] ，否則系統不會佈署此元件。

5. 請按下列的指令建立一個名稱為 Default.asp 的 ASP 檔。

   <script language=vbscript runat="server">

for n=1 to 50
set x=createobject ("YourComponent.YourClass")
Response.Write "Component created on:"
Response.Write x.GetName
Response.write "<br>"
set x=nothing
next

</script>


6. 將ProgID "YourComponent.YourClass" 以步驟 1 中所建立的元件的 ProgID 取代。

7. 在 Stager 建立一個 Application Center 應用程式，其中包含步驟 5 建立的 Default.asp 檔以及步驟 1 建立的 COM+ 元件。

8. 將應用程式佈署至網站層叢集。

9. 請確定已設定網站層路由清單，並將 COM+ 元件標記為支援負載平衡。

10. 在用戶端電腦上執行 Default.asp。假如沒有執行成功，可能是 IIS 服務在元件佈署過程中被重新啟動。請稍候再重試一次。

假如執行成功，您應該可以看到先前在建立元件例項時，所使用的 COM+ 叢集成員的清單。

TOP

何時使用 CLB

要建立分散式解決方案時，CLB 是一個很棒的技術。但是，有時候 CLB 不見得是最好的辦法。問題的關鍵在效能、擴充性和安全性。若能對這些問題有深入的了解，就能建立更好的叢集拓樸。

效能

不論網站有多吸引人或是功能有多強，如果使用者對網站的效能不滿意，那麼這個網站決無法成功。效能方面有兩個重要的問題：

• 輸送量 (Throughput) - 網站完成的工作。

• 回應時間 (Response time)- 回應使用者所需的時間。

這兩者彼此互有關聯，而 CLB 與它們也有關係。

輸送量

當系統跨越網路執行任何形式的呼叫時，輸送量效能便會降低。這是使用 CLB 必須付出的代價，而在決定任何叢集架構時，都必須把這一點考慮在內。為了使您獲得更深入的了解，下列資料顯示單一執行緒的 Visual Basic 6 COM 元件每秒的呼叫數，此 COM 元件以字串屬性傳回 "Hello, world"。用戶端執行早期連結，在呼叫間並且不會釋放所參考到的資源以取得屬性。

案例	每秒呼叫數	相對速度
COM+ 伺服器應用程式，執行在 10BaseT 網路上	625	1.0x
COM+ 伺服器應用程式，Out Proc，相同主機	1923	3.08x
COM+ 程式庫應用程式，In Proc，相同主機	3333	5.33x

很明顯的，經由網路呼叫所產生的輸送量比呼叫安裝在相同電腦上的軟體所產生的輸送量還低。所有的軟體通訊都是如此，不論是透過 Microsoft 的軟體或其他軟體皆然。因此，在決對考量輸送量的狀況下，CLB 就不是最佳的解決方案了。在這種情況下，最好在所有網站層叢集成員中安裝 COM+ 元件，如此就可以避免跨越網路的呼叫。這樣會失去對 CLB 的支援，然而仍能透過 NLB 執行負載平衡。

圖 5 網站層上的 COM+ 元件

回應時間

確保使用者在參觀網站時，能獲得最快的回應顯然是相當重要的，而且網站架構對回應時間的影響則相當明顯。在網站層中執行的 COM+ 元件可能會執行某些降低網站回應能力的作業。如果非 COM+ 元件作業的回應時間比元件輸送量更重要，則解決方法之一是將 COM+ 元件移到 COM+ 叢集層。這樣可以減輕網站層叢集的工作量，如此沒有使用 COM+ 元件的用戶端其服務時間將獲得改善。例如，用戶端存取靜態網頁時。很明顯，當系統需要執行 COM+ 元件的作業時，將看不見回應時間的改善。事實上，由於系統可能會執行某些跨網路的呼叫動作，因此效能還有可能降低。另一個解決方法則是將路由清單移到其他 COM+ 路由叢集。這麼一來，由於網站層不需執行任何有關 CLB 的工作，因此可降低網站層的工作量。同樣的，這對於在網站層中的非 COM+ 元件來說相當好；但由於會產生跨網路呼叫，因此對 COM+ 元件效能的影響更大。

很明顯的高效能與 CLB 這兩者是魚與熊掌不可兼得，而網站設計者必須要瞭解這些限制。

管理能力

使用個別的 COM+ 叢集可協助改善系統的管理能力。它使網站 COM+ 元件及 IP 的要求更容易管理與區分。例如，許多組織將 COM+ 元件儲存在不同地理位置的伺服器中。若使用個別的 COM+ 叢集，則可獨立管理該叢集。另外，也可以建立一個由多個網站層叢集共用的 COM+ 叢集，反之亦然。

安全性

CLB 也常用於增強網站的安全性。當使用 COM+ 元件作為存取資料的方式時，COM+ 元件可使用本身以角色為基礎的，或程式性的安全性機制來保護資料。假如元件位於網站層叢集，就有潛在的危險性。網站層叢集接收到的呼叫可能來自未經授信的用戶端，其目的可能是要非法使用安裝在叢集成員上的 COM+ 元件。CLB 將 COM+ 元件由網站層叢集移往 COM+ 叢集，以避免這類問題的發生。COM+ 叢集通常會有防火牆保護 (圖 6 的防火牆 B)，而且僅允許網站層叢集內部的呼叫來建立元件，而不允許來自用戶端的呼叫。圖 6 也顯示 DMZ (Demilitarized Zone) 透過兩個圍繞的防火牆來保護網站層

圖 6 防火牆之後的 COM+ 叢集

TOP

結論

CLB 是建立分散式解決方案的最佳技術，但是在使用此技術仍有必須要注意之處。使用 CLB 會對輸送量的效能產生負面的影響，然而其他的優點如安全性、擴充性、容易設定和負載平衡等，使 CLB 仍是一個相當有價值的工具。若能善用這個工具，對於建立完善的 .NET 解決方案會有莫大的幫助。

TOP

資源

http://www.microsoft.com/taiwan/ApplicationCenter/- Application Center 的最新資訊。

Microsoft Application Center 2000 Resource Kit - 包含 Application Center 的深入解析。提供有關 CLB 的進一步資訊，特別是在佈署方面的資訊。即將上市。

http://www.microsoft.com/com - COM 以及 COM+ 的相關資訊。

http://www.microsoft.com/net - 有關 .NET 的各項授權資訊。

http://www.microsoft.com/windows2000/techinfo/howitworks/cluster/nlb.asp - 關於 網路負載平衡的進一步資訊。

TOP

本文件為初稿，在最後商業的訂稿之前，皆有修改。本文件僅供參考用，Microsoft 公司對這份文件沒有保證、也不在這份文件中提供明示或暗示。本公司得不經通知，變更本文件中的任何資訊。使用此文件中的資訊所造成的結果或風險應由使用者自行承擔。文件中出現的公司、組織、產品、人物及事件皆屬虛構。與真實世界的任何公司、組織、產品、人物或事件無關，且無任何影射之意。遵守所有適當的版權法律是使用者的責任。不止是著作權法，這份文件的任何一部分都不能在未經 Microsoft 公司書面認可前，被檢索系統重製、儲存及介紹，或以任何形式或方式散佈 (電子形式、機械形式、影印、錄音或其他方式)，或用於任何用途。

Microsoft 公司也許有其他與這份文件相關的專利、專利應用程式、商標、著作權或其他智慧財產權，除非 Microsoft 公司提供的許可證明所載的項目之外，這份文件不提供任何有關這些專利、商標、著作權權或其他智慧財產權的許可證明。

未發行作品。© 1998 Microsoft Corporation.版權所有

Microsoft, <在此插入以字母順序排列的產品名稱或頭銜> 是已註冊的商標或 Microsoft 公司在美國及 / 或其他國家的註冊商標。