估計處理器需求
本節會討論評估支援部署系統中服務需要的 CPU 處理器數目和對應記憶體的過程。本節也會為您說明評估過程，並以通訊部署方案為範例說明。
評估 CPU 計算能力是一項反覆式過程，需要考慮到下列項目：
-
邏輯元件及其互動 (如邏輯架構中的元件相依性所列)
-
已識別的使用實例的使用分析
-
服務品質需求
-
過去的部署設計經驗和使用 Java Enterprise System 的經驗
-
向具有各類型部署方案設計和實作經驗的 Sun 專業服務部門諮詢
評估過程包括下列步驟。這些步驟的順序並不是關鍵這只是提供一個考慮影響最後結果之因素的方法。
-
對於被識別為系統的使用者進入點之元件必須決定其基準 CPU 估計。
其中一項是決定要完整載入或部分載入 CPU。完整載入的 CPU 可將系統的容量最大化。若要增加容量，可能會因為增加額外的 CPU 而產生維護成本和可能的當機時間。在某些情況下，您可以選擇增加額外的機器以符合增加的效能需求。
部份載入的 CPU 可允許處理額外效能需求的空間，而不會立即產生維護成本。不過，未充分利用的系統會有額外的前置成本費用。
-
調整 CPU 估計以因應元件之間的互動。
研究邏輯架構中元件彼此間的互動，以判定因為獨立元件而產生的額外負載。
-
研究特定使用實例的使用分析，以判定系統的尖峰負載，然後再對處理尖峰負載的元件進行調整。
從權重最高的使用實例 (亦即需要最多負載) 開始，再繼續研究每個使用實例，確實考慮所有的預期使用方案。
-
調整 CPU 估計來反映安全性、可用性和延展性需求。
此評估過程提供判定您需要的實際處理能力的起點。一般而言，您會先建立以這些評估值為基礎的原型部署，然後再對預期的使用實例執行嚴格的測試。只有在經過反覆的測試之後，您才能判定部署設計的實際處理需求。
處理器需求估計範例
本節說明一個方法，來評估範例部署所需的處理能力。本範例部署基於以識別為基礎的通訊解決方案的邏輯架構，該解決方案適用於員工人數為 1 千至 5 千的中型企業，如以識別為基礎的通訊範例一節中所述。
本範例中使用的和記憶體為隨意估計，僅限為圖解使用。這些圖例以理論性範例所使用的隨意資料為根據。需要徹底分析各種因素才能評估處理器需求。此分析會包括 (但不限於) 下列資訊：
-
以徹底業務分析為基礎的詳細使用實例和使用分析
-
由業務需求分析所判定的服務品質需求
-
處理和網路硬體的特定成本和規格
-
過去實作類似部署的經驗
注意 – 除了描述您在設計系統時可能使用的過程外，這些範例所示的資訊不代表任何特定的實作建議。
判定使用者進入點的基準 CPU 估計
從估計處理每個作為使用者進入點的元件上預期的負載所需的 CPU 數量開始。下圖顯示前面的以識別為基礎的通訊範例中所描述的以識別為基礎之通訊方案的邏輯架構。
圖 5–1 以識別為基礎之通訊方案的邏輯架構
下表列出邏輯架構之表示層中的元件，其會直接與部署的一般使用者聯繫。這個表格包括基準 CPU 估計，這些估計源自於技術需求分析、使用實例、特定使用分析和過去處理此類型部署的經驗。
表 5–1 元件的 CPU 估計包含存取使用者進入點的基線 CPU 估計|
元件 |
CPU 數目 |
說明 |
|---|---|---|
|
Portal Server |
4 |
作為使用者進入點的元件。 |
|
Communications Express |
2 |
向 Portal Server 訊息傳送與行事曆通道路由資料。 |
包括服務相依性的 CPU 估計
提供使用者進入點的元件需要其他 Java Enterprise System 元件的支援。若要繼續指定效能需求，請納入效能估計以考慮其他元件需要的支援。設計邏輯架構時應詳細描述元件間的互動類型，如範例邏輯架構一節的邏輯架構範例中所述。
表 5–2 支援元件的 CPU 估計|
元件 |
CPU |
說明 |
|---|---|---|
|
Messaging Server MTA (內送) |
1 |
路由來自 Communications Express 和電子郵件用戶端的內送郵件訊息。 |
|
Messaging Server MTA (外傳) |
1 |
路由外送的電子郵件給收件者。 |
|
1 |
存取 Messaging Server 的電子郵件用戶端訊息儲存區。 |
|
|
1 |
擷取和儲存電子郵件。 |
|
|
2 |
提供授權與認證服務。 |
|
|
2 |
擷取和儲存 Communications Express (Calendar Server 前端) 的行事曆資料。 |
|
|
2 |
提供 LDAP 目錄服務。 |
|
|
0 |
為 Portal Server 和 Access Manager 提供 Web 容器支援。 (不需要額外的 CPU 循環。) |
研究尖峰負載使用的使用實例
回到使用實例和使用分析，以找出尖峰負載使用的區域，並調整您的 CPU 估計。
例如，在此例中您發現下列的尖峰負載情況：
-
當使用者同時登入時，開始累計使用者
-
在特定的時間範圍內交換電子郵件
若要應付這個尖峰負載使用，請調整提供這些服務的元件。下表會概述您可以針對應付這個尖峰負載所進行的調整。
表 5–3 CPU 估計尖峰負載的調整|
元件 |
CPU (調整後) |
說明 |
|---|---|---|
|
Messaging Server MTA (內送) |
2 |
為尖峰傳入電子郵件增加 1 個 CPU |
|
Messaging Server MTA (外傳) |
2 |
為尖峰外送電子郵件新增 1 個 CPU |
|
Messaging ServerMMP |
2 |
為額外負載新增 1 個 CPU |
|
Messaging Server STR (Message Store) |
2 |
為額外負載新增 1 個 CPU |
|
Directory Server |
3 |
為額外 LDAP 查詢新增 1 個 CPU |
修改其他負載情況的估計
繼續進行 CPU 估計，考慮其他會影響負載的服務品質需求：
-
安全性。在技術需求階段中，判定資料的安全傳輸可能會對負載需求產生的影響，並對估計進行相應的修改。下一節估計安全作業事件的處理器需求描述進行調整的程序。
-
複製服務。調整 CPU 估計以因應可用性、負載平衡及延展性的服務複製需求。下一節判定可用性策略討論確定可用性解決方案的大小。判定延展性策略討論關於目錄服務可用存取的解決方案。
-
潛在容量和延展性。視需要修改 CPU 估計，使其具有可因應部署上意外大型負載的潛在容量。注意調整的預期基準點以及一段期間中預期負載的增加，確定您可以達成調整系統 (不管是以水平或垂直調整的方式) 的所有預期基準點。
更新 CPU 估計
通常將 CPU 數目增訂為偶數。增訂為偶數可在兩個實體伺服器之間平均地分配 CPU 估計，並能為潛在容量增加一點空間。不過，請根據您對複製服務的特定需求進行增訂。
一般的規則是每個 CPU 應有 2 GB 的記憶體。所需的實際記憶體是依您特定的使用為依據，並可在測試時判定。
下表列出身份識別型通訊範例的最終估計。這些估計沒有包含任何專為安全性和可用性增加的額外運算能力。安全性和可用性的總和將新增於下列章節中。
表 5–4 支援元件的 CPU 估計調整|
元件 |
CPU |
記憶體 |
|---|---|---|
|
Portal Server |
4 |
8 GB |
|
Communications Express |
2 |
4 GB |
|
Messaging Server (MTA，內送) |
2 |
4 GB |
|
Messaging Server (MTA，外傳) |
2 |
4 GB |
|
Messaging Server (MMP) |
2 |
4 GB |
|
Messaging Server (Message Store) |
2 |
4 GB |
|
Access Manager |
2 |
4 GB |
|
Calendar Server |
2 |
4 GB |
|
Directory Server |
4 |
8 GB (增訂自 3 個 CPU/6 GB 記憶體) |
|
Web Server |
0 |
0 |
- © 2010, Oracle Corporation and/or its affiliates