test

Sun Java System Application Server 9.1 部署規劃指南

第 2 章 規劃部署

部署 Application Server 之前，首先要決定效能及可用性目標，然後據此決定硬體、網路及儲存需求。

本章包含以下各節：

建立效能目標

簡單來說，高效能是指增加流量並縮短回應時間。除了這些基本目標，還可以透過決定下列項目以建立特定的目標：

您可以使用模擬預期應用程式活動的遠端瀏覽器模擬器 (RBE) 工具或網站效能與基準軟體，計算部分度量。一般來說，RBE 與基準產品會產生同步運作的 HTTP 請求，然後報告指定的每分鐘請求數之回應時間。然後，您可以使用這些數據計算伺服器活動。

本章所述的計算結果並非絕對。由於您需要微調 Application Server 與應用程式的效能，因此請將結果當作工作時的參考點。

本節論述以下主題︰

估計流量

廣義來說，流量可用來測量 Application Server 執行的工作量。對於 Application Server 而言，流量可定義為每個伺服器實例每分鐘處理的請求數。高可用性應用程式也會使 HADB 有更高的流量需求，以定期儲存階段作業狀態資料。對於 HADB，流量可定義為每分鐘儲存的階段作業資料量，這是每分鐘 HADB 請求數與每個請求平均階段作業大小的乘積。

如下一節所述，Application Server 流量是由許多因素決定的函數，這些因素包含使用者請求的特性與大小、使用者數目，以及應用程式伺服器實例與後端資料庫的效能。您可以模擬的工作負荷量為基準，估計單一機器上的流量。

高可用性應用程式因為會定期將資料儲存至 HADB，因此會造成額外的經常性耗用時間。額外的經常性耗用時間量取決於資料量、資料量變更頻率及資料儲存頻率。前兩項因素與討論的應用程式相關，最後一個也會受到伺服器設定所影響。

HADB 流量可定義為每分鐘 HADB 請求數乘以每個請求的平均資料量。HADB 流量愈大表示需要愈多的 HADB 節點，以及愈大的存放區。

估計應用程式伺服器實例的負載

請考慮下列因素以估計應用程式伺服器實例的負載：

同步運作使用者人數上限

使用者透過 Web 瀏覽器或 Java 程式等用戶端，與應用程式互動。視使用者動作之不同，用戶端會定期將請求傳送至 Application Server。只要使用者的階段作業尚未到期或終止，該名使用者即會視為目前的使用者。估計同步運作使用者人數時，請納入所有目前的使用者。

下圖描述每分鐘處理的請求數 (流量) 與使用者人數的典型圖形。最初，當使用者人數增加時，流量會相對增加。但是，當同步運作請求數目增加時，伺服器效能會開始飽和，且流量會開始降低。

找出增加同步運作使用者會降低每分鐘可處理的請求數之時間點。此時間點表示達到最佳效能的時候，在此時間點之後流量會開始降低。一般會儘可能地以最佳流量來運作系統。您可能需要增加處理能力，以處理額外的負載並增加流量。

考慮時間

使用者不會無間斷地送出請求。使用者送出請求，伺服器接收並處理請求，然後傳回結果，此時使用者會花些時間才會再送出新的請求。一個請求與下一個請求之間的時間稱為考慮時間。

考慮時間取決於使用者的類型而定。例如，機器對機器的互動 (如 Web 服務的互動) 一般需要比人類使用者的互動更短的考慮時間。您在估計考慮時間時，必須將機器與人類的混合互動列入考量。

判斷平均考慮時間很重要。您可以使用此持續時間計算每分鐘必須完成的請求數，以及系統可支援的同步運作使用者人數。

平均回應時間

回應時間是指 Application Server 將請求結果傳回給使用者所需的時間。回應時間受到網路頻寬、使用者人數、送出的請求數目與類型，以及平均考慮時間等因素的影響。

在本節中，回應時間是指平均回應時間。每種請求類型各有其最短回應時間。但是，評估系統效能時，請根據所有請求的平均回應時間分析。

回應時間愈快，每分鐘處理的請求數愈多。但是，如下圖所述，當系統上的使用者人數增加時，回應時間也會開始增加，即使每分鐘請求數減少亦然：

抱歉：本版手冊尚未提供此圖。

類似此圖的系統效能圖會指出在過了特定時間點後，每分鐘請求數會與回應時間呈反比。每分鐘請求數減少幅度越大，回應時間的增加幅度就越大 (以虛線箭頭表示)。

在圖中，尖峰負載點是每分鐘請求數開始減少的時間點。在此時間點之前，回應時間的計算不一定正確，因為未在公式中使用尖峰數目。在此時間點之後，由於每分鐘請求數與回應時間呈反比關係，所以管理員可以透過使用者人數上限及最大每分鐘請求數，更精準地計算回應時間。

使用下列公式判斷 T回應，亦即尖峰負載時的回應時間 (以秒為單位)：

T回應 = n/r - T考慮

其中

範例 2–1 回應時間的計算

假設存在下列條件：

平均考慮時間 T考慮為每個請求三秒。

回應時間的計算如下：

T回應 = n/r - T考慮 = (5000/ 1000) - 3 秒= 5 - 3 秒

因此，回應時間為兩秒。

計算系統的回應時間之後 (特別是在尖峰負載時)，請與應用程式可接受的回應時間做比較。回應時間及流量是決定 Application Server 效能的主要因素。

每分鐘請求數

若隨時知道同步運作使用者人數、這些使用者請求的回應時間，以及使用者平均考慮時間，即可計算每分鐘的請求數。一般會從估計系統上的同步運作使用者人數開始。

例如，執行網站效能軟體之後，管理員得知同時在網路銀行網站送出請求的使用者平均人數為 3,000 人。此人數取決於已登記成為網路銀行會員的使用者人數、使用者的銀行交易行為、使用者選擇送出請求的日期時間...等等。

因此，瞭解此資訊可讓您使用本節所述的每分鐘請求數公式，計算系統根據此使用者人數每分鐘可處理的請求數。由於每分鐘請求數與回應時間在尖峰負載時會形成反比，因此請決定是要接受較少的每分鐘請求數以換取較佳的回應時間，還是要接受較慢的回應時間以換取每分鐘更多的請求數。

實驗不同的可接受每分鐘請求數與回應時間臨界值，作為微調系統效能的起點。接著決定需要調整的系統區域。

求解上一節方程式中的 r 得出：

r = n/(T回應 + T考慮)

範例 2–2 每秒請求數的計算

假設下列值：

每秒請求數的計算如下：

r = 2800 / (1+3) = 700

因此，每秒請求數為 700，而每分鐘請求數為 42000。

估計 HADB 的負載

若要計算 HADB 的負載，請考慮下列因素：

如需有關配置階段作業持續性的指示，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 9 章「配置高可用性階段作業持續性和容錯移轉」。

HTTP 階段作業持續性頻率

HADB 接收的每分鐘請求數取決於持續性頻率。持續性頻率會決定 Application Server 將 HTTP 階段作業資料儲存至 HADB 的頻率。

持續性頻率選項包括：

下表是持續性頻率選項的優缺點摘要。

表 2–1 持續性頻率選項的比較

持續性頻率選項 

優點 

缺點 

Web 方法 

保證可提供最新的階段作業資訊。 

可能增加回應時間並降低流量。 

以時間為基礎 

改善回應時間，並有可能增加流量。 

較無法保證可在應用程式伺服器實例故障之後仍能提供最新的階段作業資訊。 

HTTP 階段作業大小與範圍

每個請求的階段作業大小取決於階段作業中所儲存的階段作業資訊量。

提示 –

若要改善整體效能，請儘可能降低階段作業中的資訊量。

可透過 持續性範圍設定，微調每個請求的階段作業大小。請從 HTTP 階段作業持續性範圍的下列選項中選擇：

若要使用此選項，應用程式必須：

表 2–2 持續性範圍選項的比較

持續性範圍選項 

優點 

缺點 

modified-session 

當請求不修改階段作業狀態時，提供較優良之請求回應時間。 

執行 Web 方法期間 (一般是 doGet() 或 doPost())，應用程式必須呼叫階段作業方法：

  • setAttribute()，若已變更屬性。

  • removeAttribute()，若已移除屬性。

session 

應用程式沒有限制。 

與 modified-session 和 modified-attribute 選項相較下，可能使流量及回應時間更差。

modified-attribute 

在請求的階段作業狀態修改比例很低的情況下，改善請求的流量與回應時間。 

當指定請求的階段作業狀態修改比例接近 60% 時，流量會降低且回應時間會變慢。在這類情況下的效能是所有選項中最差的，因為將屬性分割成個別的記錄會造成額外的經常性耗用時間。 

有狀態的階段作業 Bean 檢查點檢查

對於 SFSB 階段作業持續性，HADB 的負載與下列項目相關：

檢查點檢查一般會在完成 SFSB 的任何作業事件之後發生，即使作業事件回復亦然。

如需更佳的效能，請指定一小組方法進行檢查點檢查。進行檢查點檢查的資料大小與檢查點檢查的頻率，會決定指定用戶端互動之回應時間的額外經常性耗用時間。

規劃網路配置

規劃如何將 Application Server 整合到網路時，請估計頻寬需求，並將網路規劃成可符合使用者的效能需求。

本節包含以下主題：

估計頻寬需求

若要決定所需的網路大小與頻寬，請先判斷網路流量並找出其尖峰時段。檢查整體流量是否只在特定時刻、一週或一個月內的特定日子達到尖峰，然後判斷該尖峰的持續時間。

在尖峰負載期間，網路中的封包數會達到最高。一般來說，若要進行尖峰負載設計，請依照處理 100% 尖峰量的目標來延伸系統規模。但是請記住，當網路運作異常時，即使您已經延伸規模，可能還是不一定能處理 100% 的尖峰量。

例如，假設在尖峰負載時，5% 的使用者在存取 Application Server 上部署的應用程式時，偶爾會無法立刻存取網路。在 5% 的使用者中，估計有多少使用者在第一次嘗試之後重試存取。重試之後，並非所有使用者皆能成功存取，在這些不成功的部分中，又會有另外比例的人數進行重試。因此，顯示的尖峰時間會比較長，因為使用者會不斷嘗試存取，而造成尖峰使用的時間拉長。

計算所需的頻寬

根據建立效能目標中計算的結果，判斷在網站上部署 Application Server 時所需的額外頻寬。

根據存取方法 (T1 專線、ADSL、纜線數據機...等等)，計算處理估計的負載所需增加的頻寬量。例如，假設您的網站使用 T1 或更高速的 T3 專線。根據網站每秒所產生的平均請求數及最大尖峰負載，在指定頻寬下估計所需的網路線路數目。使用網站分析與監視工具計算這些數據。

範例 2–3 所需頻寬的計算

一條 T1 專線可處理 1.544 Mbps。因此，四條 T1 專線的網路可處理約 6 Mbps 的資料。假設傳送回用戶端的平均 HTML 網頁為 30 KB，此內含四條 T1 專線的網路每秒可處理下列流量：

6,176,000 位元/8 位元 = 每秒 772,000 個位元組

每秒 772,000 位元組/30 KB = 約每秒 25 頁同步運作回應頁面。

假設一整天的負載很平均，在每秒 25 頁的流量下，此系統每小時可處理 90,000 頁 (25 x 60 秒 x 60 分鐘)，因此每天最多可處理 2,160,000 頁。若最大尖峰負載大於此負載，請隨之增加頻寬。

估計尖峰負載

在現實情況下，一整天的負載不可能很平均。您必須判斷何時會發生尖峰負載、尖峰負載持續的時間，以及尖峰負載佔總負載的比例。

範例 2–4 尖峰負載的計算

若尖峰負載持續兩小時，並佔 2,160,000 頁面總負載的 30%，表示必須在一天兩小時內在 T1 專線上傳送 648,000 個頁面。

因此，若要在這兩小時內容納尖峰負載，請根據下列計算增加 T1 專線的數目：

648,000 頁/120 分鐘 = 每分鐘 5,400 頁

每分鐘 5,400 頁/60 秒 = 每秒 90 頁

如果四條網路線每秒可處理 25 頁，90 頁近似於 25 的四倍，因此需要四倍的網路線，亦即 16 條網路線。這 16 條網路線的用途，是處理實際上最多 30% 的尖峰負荷。其他 70% 的負載毫無疑問可在一天的其他時間由這些數目的網路線處理。

配置子網路

如果使用個別層級拓樸，其中應用程式伺服器實例與 HADB 節點位於不同的主機機器上，您可以透過使所有 HADB 節點位於不同的子網路，以改善效能。這是因為 HADB 使用使用者資料封協定 (UDP)。使用不同的子網路可降低子網路外部機器上的 UDP 流量。但請注意，所有 HADB 節點必須位於相同的子網路上。

只要所有節點與管理代理程式位於相同的子網路上，您仍可從不同的子網路執行管理用戶端。所有節點代理程式內應該皆可存取所有主機與連接埠，且防火牆、UDP 的封鎖功能...等等都不得封鎖此節點。

HADB 使用 UDP 多重播送，因此內含 HADB 節點的所有子網路皆須配置為可進行多重播送。

選擇網路卡

若要取得更佳的頻寬及理想的網路效能，請在代管 Application Server 與 HADB 節點的伺服器之間，至少使用 100 Mbps 的乙太網路卡，最好是 1 Gbps 的乙太網路卡。

HADB 的網路設定

備註 –

HADB 使用 UDP 多重播送，因此您必須啟用系統路由器與主機網路介面卡的多重播送。若 HADB 跨多個子網路，則也必須啟用子網路之間路由器的多重播送。為取得最佳結果，請將所有 HADB 節點置於相同的網路。應用程式伺服器實例可在不同的子網路上。

下列建議可讓 HADB 在網路中的運作最佳。

規劃可用性

本小節包含下列主題：

最佳化可用性

若要規劃系統與應用程式的可用性，請評估存取不同應用程式之使用者群組的可用性需求。例如，付費的外部使用者與企業夥伴常比內部使用者有更高的服務品質 (QoS) 期望。因此，內部使用者可能比付費的外部用戶較能接受應用程式功能、應用程式或伺服器無法使用。

下圖描述為了減少可能發生的事件，成本與複雜度會如何增加。在此連續曲線的一端，簡易負載平衡的叢集即可容許本土化應用程式、中介軟體與硬體故障。在圖表的另一端，位置不同的叢集可降低影響整個資料中心的重大災難。

若要實現理想的投資報酬率，通常最好找出應用程式內各功能的可用性需求。例如，保險報價系統絕對不能無法使用 (可能會失去新業務)，但是帳號管理功能 (現有用戶可由此檢視其目前的保險項目) 暫時無法使用則不太可能會失去現有的用戶。

使用叢集改善可用性

在最基本的層級中，叢集是一組應用程式伺服器實例 (通常代管於多個實體伺服器上)，並讓用戶端以為是單一實例。如此可提供水平延展性，以及比單一機器上的單一實例更高的可用性。此基本叢集層級結合 Application Server 的 HTTP 負載平衡器外掛程式使用，該外掛程式接受 HTTP 與 HTTPS 請求，並會轉寄給叢集中其中一個應用程式伺服器實例。ORB 與整合的 JMS 代理程式也會對應用程式伺服器叢集執行負載平衡。若實例出現故障而無法使用 (因為網路故障) 或無回應，請求僅會重新導向至現有的可用機器。負載平衡器還可以識別出現故障的實例是否已回復，並會隨之重新分配負載。

HTTP 負載平衡器也提供運作狀態檢查程式，該程式可監視伺服器與特定 URL，以判斷其是否可用。您必須謹慎管理運作狀態檢查的經常性耗用時間，使其本身不會成為龐大的處理負擔。

對於無狀態應用程式或價值不高、僅需簡單使用者作業事件的應用程式，通常只需要簡易負載平衡的叢集。對於有狀態的關鍵性應用程式，請考慮使用 HADB 取得階段作業持續性。如需 HADB 的簡介，請參閱「Application Server Administration Guide」第 1 章, 產品概念中高可用性資料庫。

若要執行應用程式的線上升級，最好將一應用程式伺服器實例分組為多個叢集。Application Server 可同時靜止應用程式與實例。靜止是以控制的方式讓實例 (或實例群組) 或特定應用程式離線的功能，而且其不會影響實例或應用程式目前提供服務的使用者。當一個實例靜止時，新的使用者會由其他實例上已升級的應用程式提供服務。此應用程式升級類型稱為輪替式升級。如需有關升級即時應用程式的更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的「在維持可用性的情況下升級應用程式」。

增加系統的備援

達成高可用性的一個方式是增加系統的軟硬體備援。當一個單元故障時，備援單元會接管。這又稱為容錯。一般來說，若要有最佳的高可用性，請判斷並移除系統中每個可能的故障點。

找出故障類別

備援層級取決於系統需要容許的故障類別 (故障的類型)。以下是一些故障類別範例：

複製系統程序可容許單一系統程序故障，以及單一機器故障。將複製的鏡像 (成對) 機器接到不同的電源供應，即可容許單一電源故障。透過將鏡像機器保留在不同的建築物中，可容許單一建築物失火。透過將鏡像機器保留在不同的地理位置，可容許地震等天災。

使用 HADB 備援單元改善可用性

若要改善可用性，一律請如建立效能目標中所述，在資料備援單元 (DRU) 中使用 HADB 節點。

使用 HADB 備用節點改善容錯

使用備用節點改善容錯。雖然備用節點不是必要項目，但可提供最佳的可用性。

規劃容錯移轉容量

容錯移轉容量規劃是指決定需要額外增加至 Application Server 部署的伺服器與程序數目，如此一來，當伺服器或程序故障時，系統可緊密地回復資料並繼續處理。若系統超載，可能會產生程序或伺服器故障，造成回應時間變慢或甚至失去整個服務。為這類事件做足準備對於成功部署非常重要。

若要維持容量，特別是在尖峰負載時，請將執行應用程式伺服器實例的備用機器增加至現有的部署中。

例如，假設某部系統有兩部機器，各執行一個應用程式伺服器實例。這些機器在尖峰負載時每秒總共可處理 300 個請求。如果一部機器無法使用，系統將只能處理 150 個請求 (假設機器之間平均分散負載)。因此將會無法處理尖峰負載期間的一半請求。

設計決策

設計決策包含您是為尖峰負載還是持續狀態負載設計系統、不同角色的機器數目及其大小。

為尖峰負載或持續狀態負載設計

在一般部署中，持續狀態工作負荷量與尖峰工作負荷量不同。

系統預期處理尖峰負載的頻率，將決定您要為尖峰負載還是持續性狀態進行設計。

若尖峰負載經常發生 (例如每天多次)，便有必要擴充容量以處理負載。若系統 90% 的時間以持續狀態運作，10% 的時間在尖峰，則適合部署依照持續狀態負載所設計的系統。這表示系統的回應時間僅會在 10% 的時間內變慢。決定系統在尖峰運作時的頻率或持續時間是否有必要增加系統資源。

調整系統大小

根據應用程式伺服器實例的負載、HADB 的負載及容錯移轉需求，您可以判斷：

應用程式伺服器實例的數目

若要判斷所需的應用程式伺服器實例 (主機) 數目，請根據估計應用程式伺服器實例的負載中所述的因素，針對每個應用程式伺服器實例評估您的環境，但是每個實例可使用多個中央處理器 (CPU)。

HADB 節點的數目

一般來說，請為系統的每個 CPU 規劃一個 HADB 節點。例如，為具有兩個 CPU 的機器使用兩個 HADB 節點。

備註 –

若每部機器有多個 HADB 節點 (例如，如果您使用較大型的機器)，則必須確定這些機器上有足夠的備援與延展性；例如，多個不斷電系統及獨立的磁碟控制器。

或者使用下列程序。

Procedure判斷所需的 HADB 節點數目

  1. 判斷下列參數：

    • 同步運作使用者人數上限 n使用者。

    • 平均 BLOB 大小 s。

    • 每位使用者的最大作業事件率，稱為 NTPS。

  2. 判斷主要資料量大小上限 (以 GB 為單位) V 資料。

    使用下列公式：

    V資料 = n使用者.s

  3. 判斷最大 HADB 資料傳輸速率 R dt。

    這會反映從應用程式端傳送至 HADB 中的資料量。使用下列公式：

    Rdt = n使用者 .s .NTPS

  4. 判斷節點數目 N 節點。

    使用下列公式：

    N節點 = V資料 /5GB

    由於節點是成對運作，因此請將此值無條件進入成偶數。

HADB 主機的數目

根據資料傳輸需求判斷 HADB 主機的數目。此計算假設所有主機皆具有類似的硬體配置與作業系統，並有必要的資源可容納主機執行的節點。

Procedure計算主機的數目

  1. 判斷最大主機資料傳輸速率 R max.。

    由於此值與網路及主機硬體相關，因此請憑經驗判斷此值。請注意，此值與上一節中所判斷的最大 HADB 資料傳輸速率 R dt 不同。

  2. 判斷容納此資料所需的主機數目。

    更新分散至數個主機 N 主機的資料量 V，會造成每個主機接收約 4V/N 主機的資料。使用下列公式判斷容納此資料量所需的主機數目：

    N主機 = 4 .Rdt / Rmax

    將此值無條件進入成最接近的偶數，以針對每個 DRU 取得相同的主機數目。

  3. 在每個 DRU 上為備用節點增加一個主機。

    如果其他主機各執行 N 個資料節點，請讓此主機執行 N 個備用節點。如此可允許單一機器故障關閉 N 個資料節點。

    每個主機至少需要執行一個節點，因此如果節點的數目小於主機的數目 (N節點 < N主機)，請調整 N節點，使其等於 N主機。如果節點的數目大於主機的數目 (N節點 \> N主機)，則相同主機上可執行數個節點。

HADB 儲存容量

HADB 以近乎直線的比例遞增更多節點，直到超過網路容量為止。您必須在專屬磁碟上配置每個節點的儲存裝置。所有節點必須在儲存裝置上配置相等的空間。請務必於本機磁碟上配置儲存裝置。

假設預期的階段作業資料大小是 x MB。HADB 會在鏡像節點上複製資料，因此需要 2x MB 的儲存容量。此外，HADB 使用索引加速存取資料。兩個節點需要額外的 2x MB 供索引使用，因此所需的總儲存容量為 4x。因此，HADB 的預期儲存容量需求是預期資料量的四倍。

為了日後擴充而不失去 HADB 資料，您必須提供線上升級的額外儲存容量，因為您可能需要在增加新節點後重新分段資料。在這種情況下，資料裝置上需要類似的額外空間量 (4x)。因此，預期儲存容量是預期資料量的八倍。

此外，HADB 會如下使用磁碟空間：

下表是階段作業資料為 x MB 的 HADB 儲存空間需求摘要。

表 2–3 階段作業大小為 X MB 的 HADB 儲存空間需求

條件 

所需的 HADB 儲存空間 

不需要在線上時，HADB 節點的增加或移除。

4x MB + (4*記錄緩衝區大小) + 1% 的裝置大小

需要在線上時，HADB 節點的增加或移除。 

8x MB + (4*記錄緩衝區大小) + 1% 的裝置大小

若 HADB 的裝置空間不足，即不會接受插入或更新資料的用戶端請求。但會接受刪除作業。若 HADB 的裝置空間不足，則會傳回錯誤碼 4593 或 4592，並將對應的錯誤訊息寫入歷史檔案。如需有關這些訊息的更多資訊，請參閱「Sun Java System Application Server 9.1 Error Message Reference 」中的第 14 章「HADB Error Messages」。

規劃 Message Queue 代理程式部署

Java Message Service (JMS) API 是一種允許 J2EE 應用程式和元件建立、傳送、接收以及讀取郵件的訊息傳送標準。它可啟用可靠的非同步鬆耦合分散式通訊。實作 JMS 的 Sun Java System Message Queue 與 Application Server 整合在一起，可讓您建立諸如訊息驅動 Bean (MDB) 之類的元件。

Sun Java System Message Queue (MQ) 使用由 J2EE 連接器架構規格 (JCA) 1.5 定義的連接器模組 (亦稱為資源配接卡) 與 Application Server 整合在一起。連接器模組是增加 Application Server 功能的標準化方式。部署至 Application Server 的 J2EE 元件使用透過連接器模組整合的 JMS 提供者，交換 JMS 訊息。依預設，JMS 提供者是 Sun Java System Message Queue，但是如果需要使用不同的 JMS 提供者，則只要是實作 JCA 1.5 的提供者皆可。

在 Application Server 中建立 JMS 資源會在背景中建立連接器資源。因此，每個 JMS 作業均會在背景中呼叫連接器執行階段並使用 MQ 資源介面。

除了使用資源配接卡 API 之外，Application Server 還使用其他 MQ API 提供與 MQ 的更佳整合。此緊密的整合可啟用連接器容錯移轉、外送連線的負載平衡，以及內送訊息至 MDB 的負載平衡等功能。這些功能可讓您使訊息傳送流量容錯且高度可用。

多個代理程式叢集

MQ Enterprise Edition 支援使用多個互連的代理程式實例，稱為代理程式叢集。對於代理程式叢集，用戶端連線會分散至叢集中的所有代理程式。叢集可提供水平可延伸性並可提高可用性。

單一訊息代理程式可延伸至約八個 CPU，並為一般應用程式提供足夠的流量。若代理程式程序故障，則會自動重新啟動。但是，隨著連線至代理程式的用戶端數目增加，以及提供的訊息數目增加，代理程式終會超過檔案描述元的數目與記憶體等限制。

在叢集中有多個代理程式而非只有一個代理程式，可讓您：

但是，具有多個代理程式並不保證代理程式故障時，進行中的作業事件會繼續在替代代理程式上執行。當 MQ 使用叢集中不同的代理程式重新建立故障的連線時，會失去作業事件訊息傳送並回復進行中的作業事件。除了無法完成作業事件之外，使用者應用程式將不會受到影響。由於可繼續使用連線，因此確認了服務容錯移轉功能。

因此，MQ 不支援在叢集中的高可用持續性訊息傳送。若代理程式在故障後重新啟動，則將自動回復並完成持續性訊息的傳遞。持續性訊息可儲存在資料庫中或儲存於檔案系統上。但是，若代管代理程式的機器未從硬體故障中回復，則可能遺失訊息。

內含適用於 Sun Message Queue 之 Sun Cluster Data Service 的 Solaris 平台，支援不需設定即可針對持續性訊息進行容錯移轉。此配置運用 Sun Cluster 的全域檔案系統及 IP 容錯移轉，提供實在的高可用性並隨附於 Java Enterprise System 中。

主代理程式與用戶端同步化

在多個代理程式配置中，每個目標會在叢集中所有代理程式上遭到複製。每個代理程式知道在所有其他代理程式上的目標註冊之訊息用戶。因此，每個代理程式可從其自己的直接連線訊息生產者，將訊息路由至遠端的訊息用戶，並從遠端生產者將訊息傳遞至自己的直接連線用戶。

在叢集配置中，每個訊息生產者直接連線的代理程式會為該生產者傳送的訊息執行路由。由此，持續性訊息會再透過訊息的主代理程式進行儲存與路由。

當管理員建立或銷毀代理程式上的目標時，此資訊會自動傳播至叢集中的所有其他代理程式。同理，當訊息用戶向主代理程式註冊，或從其主代理程式中斷連線時 (明確指定、由於用戶端或網路故障，或由於其主代理程式關閉)，有關此用戶的資訊會在整個叢集中傳播。有關長期訂閱的資訊也會以類似的方式傳播至叢集中的所有代理程式。

配置 Application Server 以使用 Message Queue 代理程式

Application Server 的 Java 訊息服務表示 Message Queue 的連接器模組 (資源配接卡)。您可以透過管理主控台或 asadmin 指令行公用程式來管理 Java 訊息服務。

MQ 代理程式 (JMS 主機) 會在與 Application Server 程序不同的 JVM 中執行。如此可讓多個應用程式伺服器實例或叢集共用同一組 MQ 代理程式。

在 Application Server 中，JMS 主機是指 MQ 代理程式。Application Server 的 Java 訊息服務配置內含 JMS 主機清單 (亦稱為 AddressList)，其中包括所有即將使用的 JMS 主機。

使用管理主控台管理 JMS

在管理主控台中，您可以使用 Java 訊息服務節點為特定的配置設定 JMS 特性。您可以設定 [重新連線間隔] 與 [重新連線嘗試] 等特性。如需更多資訊，請參閱「Sun Java System Application Server 9.1 管理指南」中的第 4 章「配置 Java 訊息服務資源」。

Java 訊息服務節點下的 JMS 主機節點包含 JMS 主機的清單。您可以在清單中增加及移除主機。對於每個主機，您可以設定主機名稱、連接埠號碼，以及管理使用者名稱與密碼。依預設，JMS 主機清單包含一個稱為 default_JMS_host 的 MQ 代理程式，其表示與 Application Server 整合的本機 MQ 代理程式。

配置 JMS 主機清單以納入叢集中所有的 MQ 代理程式。例如，若要設定包含三個 MQ 代理程式的叢集，請在 Java 訊息服務內為每個代理程式增加一個 JMS 主機。Message Queue 用戶端使用 Java 訊息服務中的配置資訊，與 MQ 代理程式通訊。

使用 asadmin 管理 JMS

除了管理主控台，還可以使用 asadmin 指令行公用程式管理 Java 訊息服務與 JMS 主機。使用下列 asadmin 指令：

Java 訊息服務類型

Application Server 與 MQ 代理程式之間的整合有兩種類型：LOCAL 與 REMOTE。您可以在管理主控台的 Java 訊息服務頁面上設定此 Type 屬性。

LOCAL Java 訊息服務

如果 Type 屬性是 LOCAL，Application Server 會啟動與停止 MQ 代理程式。當 Application Server 啟動時，會隨即啟動指定為預設 JMS 主機的 MQ 代理程式。同理，當應用程式伺服器實例關閉時，會隨即關閉 MQ 代理程式。LOCAL 類型最適合於獨立的應用程式伺服器實例。

對於 LOCAL 類型，請使用 Start Arguments 屬性指定 MQ 代理程式的啟動參數。

REMOTE Java 訊息服務

如果 Type 屬性是 REMOTE，Application Server 會使用外部配置的代理程式或代理程式叢集。在此情況下，您必須從 Application Server 分別啟動與停止 MQ 代理程式，並使用 MQ 工具配置與調校代理程式或代理程式叢集。REMOTE 類型最適合於應用程式伺服器叢集。

對於 REMOTE 類型，您必須使用 MQ 工具指定 MQ 代理程式啟動參數。可忽略 Start Arguments 屬性。

預設 JMS 主機

您可以在管理主控台的 Java 訊息服務頁面上指定預設 JMS 主機。若 Java 訊息服務的類型為 LOCAL，則 Application Server 會在應用程式伺服器實例啟動時啟動預設的 JMS 主機。

若要使用 MQ 代理程式叢集，請刪除預設的 JMS 主機，然後增加叢集中的所有 MQ 代理程式作為 JMS 主機。在此情況下，預設 JMS 主機會成為 JMS 主機清單中的第一個 JMS 主機。

您也可以明確地將預設 JMS 主機設定為其中一個 JMS 主機。當 Application Server 使用 Message Queue 叢集時，預設 JMS 主機會執行 MQ 專屬的指令。例如，為 MQ 代理程式叢集建立實體目標時，預設 JMS 主機會執行指令以建立實體目標，但叢集中的所有代理程式會使用實體目標。

部署方案範例

若要符合您的訊息傳送需求，請修改 Java 訊息服務與 JMS 主機清單，以滿足您的部署、效能與可用性需求。以下各節說明一些典型的方案。

為取得最佳的可用性，若訊息傳送需求不單只是為了 Application Server，請在不同的機器上部署 MQ 代理程式與 Application Server。或在每部機器上執行一個應用程式伺服器實例與一個 MQ 代理程式實例，直到訊息傳送能力足夠為止。

預設部署

自動安裝 Application Server 會建立 Domain Administration Server (DAS)。依預設，DAS 的 Java 訊息服務類型是 LOCAL。因此，啟動 DAS 也會啟動其預設 MQ 代理程式。

建立新的網域也會建立新的代理程式。依預設，當您將獨立的伺服器實例或叢集增加至網域時，其 Java 訊息服務會配置為 REMOTE，而其預設 JMS 主機會是 DAS 所啟動的代理程式。

預設部署說明使用包含三個實例的應用程式伺服器叢集之預設部署範例。

搭配使用 MQ 代理程式叢集與應用程式伺服器叢集

若要配置應用程式伺服器叢集使用 MQ 代理程式叢集，請增加所有 MQ 代理程式作為 Application Server 的 Java 訊息服務中之 JMS 主機。所有建立的 JMS 連線工廠及部署的 MDB 會接著使用指定的 JMS 配置。

下圖描述的部署範例，在代理程式叢集中包含三個 MQ 代理程式，並在叢集中包含三個應用程式伺服器實例。

指定特定應用程式的 MQ 代理程式叢集

在某些情況下，應用程式使用的 MQ 代理程式叢集，可能必須與應用程式伺服器叢集使用的不同。指定特定應用程式的 MQ 代理程式叢集說明此類方案的範例。若要執行此作業，請使用 JMS 連線工廠的 AddressList 特性或 MDB 部署描述元中的 activation-config 元素，指定 MQ 代理程式叢集。

如需有關配置連線工廠的更多資訊，請參閱「Sun Java System Application Server 9.1 管理指南」中的「JMS 連線工廠」。如需有關 MDB 的更多資訊，請參閱「Sun Java System Application Server 9.1 Developer’s Guide」中的「Using Message-Driven Beans」。

應用程式用戶端

當應用程式用戶端或獨立應用程式第一次存取 JMS 管理式物件時，用戶端 JVM 會從伺服器擷取 Java 訊息服務配置。用戶端 JVM 必須重新啟動，才可使用對於 JMS 服務所做的進一步變更。