test

Sun Java Enterprise System 2005Q4 部署規劃指南

第 5 章 部署設計

在解決方案生命週期的部署設計階段期間，您設計高階部署架構和低階實作規格，以及準備實作解決方案需要的一系列規劃和規格。專案核准會在部署設計階段發生。

本章包含以下各節：

關於部署設計

部署設計以部署方案開始，而部署方案是在解決方案生命週期的邏輯設計和技術需求階段期間所設計的。 部署方案包含一個邏輯架構及解決方案的服務品質 (QoS) 需求。您對應邏輯架構 (跨實體伺服器和其他網路裝置) 中識別的元件以建立部署架構。需求提供效能、可用性、延展性和其他相關規格之硬體配置的指導。

設計部署架構是一個反覆式程序。通常需要重新審視 QoS 需求並重新檢查初步設計。需要考慮 QoS 需求的相互關係，透過平衡利弊和所有權成本問題找出一個能夠達到專案最終業務目標的最佳化解決方案。

專案核准

專案核准會在部署設計階段期間發生，通常是在您建立部署架構之後。使用部署架構和以下所述的實作規格 (若有可能)，則可估計部署的實際成本並將結果提交給利害關係人以進行核准。一旦核准專案後，則會簽訂部署完成的合約並取得及分配實作專案的資源。

部署設計輸出資料

在部署設計階段期間，您可能準備下列任何規格和規劃：

影響部署設計的因素

有數個因素會影響您在部署設計期間所做的決定。請考慮下列關鍵因素：

部署設計方法

如同部署規劃的其他層面，部署設計同時兼具藝術與科學的特性，無法以特定的程序和過程來詳細說明。成功部署設計的因素包含了過去的設計經驗、系統架構的知識、網域知識和實用的創意思考。

部署設計通常以達成效能需求為中心並同時滿足其他 QoS 需求。您所使用的策略必須能平衡設計決定的利弊，才能最佳化解決方案。您使用的方法通常會包含下列作業：

估計處理器需求

本節會討論評估支援部署系統中服務需要的 CPU 處理器數目和對應記憶體的過程。本節也會為您說明評估過程，並以通訊部署方案為範例說明。

評估 CPU 計算能力是一項反覆式過程，需要考慮到下列項目：

評估過程包括下列步驟。這些步驟的順序並不是關鍵這只是提供一個考慮影響最後結果之因素的方法。

  1. 對於被識別為系統的使用者進入點之元件必須決定其基準 CPU 估計。

    其中一項是決定要完整載入或部分載入 CPU。完整載入的 CPU 可將系統的容量最大化。若要增加容量，可能會因為增加額外的 CPU 而產生維護成本和可能的當機時間。在某些情況下，您可以選擇增加額外的機器以符合增加的效能需求。

    部份載入的 CPU 可允許處理額外效能需求的空間，而不會立即產生維護成本。不過，未充分利用的系統會有額外的前置成本費用。

  2. 調整 CPU 估計以因應元件之間的互動。

    研究邏輯架構中元件彼此間的互動，以判定因為獨立元件而產生的額外負載。

  3. 研究特定使用實例的使用分析，以判定系統的尖峰負載，然後再對處理尖峰負載的元件進行調整。

    從權重最高的使用實例 (亦即需要最多負載) 開始，再繼續研究每個使用實例，確實考慮所有的預期使用方案。

  4. 調整 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 

路由外送的電子郵件給收件者。 

Messaging Server MMP

1 

存取 Messaging Server 的電子郵件用戶端訊息儲存區。 

Messaging Server STR (Message Store)

1 

擷取和儲存電子郵件。 

Access Manager

2 

提供授權與認證服務。 

Calendar Server (後端)

2 

擷取和儲存 Communications Express (Calendar Server 前端) 的行事曆資料。 

Directory Server

2 

提供 LDAP 目錄服務。 

Web Server

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 應有 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 

估計安全作業事件的處理器需求

資料的安全傳輸包括通過安全通訊端層 (SSL) 或傳輸層加密 (TLS) 這樣的安全傳輸協定處理作業事件。通過安全傳輸處理的交易通常需要額外的計算能力，首先要建立安全階段作業 (稱為訊號交換)，然後再加密和解密傳輸資料。根據使用的加密演算法 (如 40 位元或 128 位元加密演算法)，可能額外需要大量計算能力。

考慮在非安全交易的同層級上執行安全交易時，您必須規劃額外的計算能力。根據作業事件的特性以及處理作業事件的 Sun JavaTM Enterprise System 服務，安全作業事件需要的計算能力最多可能是非安全作業事件的四倍。

當評估處理安全交易的處理能力時，請分析使用實例來判定需要安全傳輸的交易百分比。如果安全交易的效能需求與非安全交易相同，則需修改 CPU 數量的估計值，將安全交易所需的額外計算能力考慮在內。

在某些使用方案中，安全傳輸可能只需要用來認證。一旦使用者經由系統認證，就不需要額外的資料傳輸安全性評量。在其他方案中，所有的交易可能都需要安全傳輸。

例如，瀏覽線上電子商務網站的產品目錄時，客戶在結束選擇並準備「結帳」以購買產品前的所有作業事件都可以是不安全的。不過，某些使用方案 (像是針對銀行或證券經紀商的部署) 卻需要大部分或全部作業事件都是安全的，它們為安全和非安全作業事件都套用同一效能標準。

安全交易的 CPU 估計

本節繼續以範例部署說明如何計算既包括安全作業事件又包括非安全作業事件的理論性使用實例的 CPU 需求。

若要估計安全作業事件的 CPU 需求，請進行以下計算：

  1. 先計算 CPU 估計的基準數字 (如上一節處理器需求估計範例中所述)。

  2. 計算需要安全傳輸的作業事件的百分比，然後計算安全作業事件的 CPU 估計。

  3. 計算非安全交易已減少的 CPU 估計。

  4. 將安全估計與非安全估計相加以計算總 CPU 估計。

  5. 將總 CPU 估計增訂為偶數。

安全交易的 CPU 估計顯示以 Portal Server 的使用實例和使用分析為基礎的範例計算，該計算有如下假設：

表 5–5 修改安全作業事件的 CPU 估計

步驟 

說明 

計算 

結果 

1 

先計算所有 Portal Server 作業事件的基準估計。 

來自研究尖峰負載使用的使用實例的基準估計是 4 個 CPU。

- - - - - 

2 

計算安全交易的額外 CPU 估計。假設安全作業事件需要的 CPU 能力是非安全作業事件的四倍。 

10% 的基準估計需要安全傳輸： 

 

0.10 x 4 CPU = 0.4 CPU

 

增加安全交易的 CPU 能力 4 倍： 

 

4 x 0.4 = 1.6 CPU

1.6 CPU 

3 

計算非安全交易已減少的 CPU 估計。 

90% 的基準估計是不安全的： 

 

0.9 x 4 CPU = 3.6 CPU

3.6 CPU 

4 

計算安全和非安全交易的已調整總 CPU 估計。 

安全估計 + 非安全估計 = 總計： 

 

1.6 CPU + 3.6 CPU = 5.2 CPU

5.2 CPU 

5 

增訂為偶數。 

5.2 CPU ==> 6 CPU

6 CPU 

依據本範例中的安全作業事件計算，可以對安全交易的 CPU 估計中的總 CPU 估計進行修改，額外增加 2 個 CPU 和四十億位元組的記憶體，得到 Portal Server 的下列總計。

元件 

CPU 

記憶體 

Portal Server 

6 

12 GB 

處理 SSL 作業事件的專用硬體

專用硬體裝置，例如 SSL 加速卡和其他裝置，可用來提供處理安全階段作業建立的計算能力，和資料的加密和解密。使用專用硬體來進行 SSL 作業時，計算能力專供 SSL 計算的某一部份使用，這部份通常是建立安全階段作業的「訊號交換」作業。

此硬體可能對您最後的部署架構有益。不過，鑒於硬體的專門化特性，請先估計 CPU 能力層面的安全作業事件效能需求，然後再考慮使用專用硬體處理額外負載的利益。

當使用專用硬體時要考慮的一些因素是使用實例是否支援使用硬體 (例如，需要大量「SSL訊號交換作業」作業的使用實例)，以及此類硬體帶給設計的複雜性附加層面。該複雜性包括安裝、配置、測試和裝置管理。

判定可用性策略

開發可用性需求的策略時，請研究元件互動和使用分析來判定要考慮哪個可用性解決方案。以基於元件的方式來進行分析，判定最能符合可用性和容錯移轉需求的解決方案。

下列項目是您蒐集的資訊類型範例，可用來判定可用性策略：

所選的可用性策略還必須考慮服務性需求，如設計最佳化資源使用中所討論的。避免需要大量管理和維護的複雜型解決方案。

可用性策略

Java Enterprise System 部署的可用性策略包括下列項目：

下列章節提供數個可用性解決方案的範例，這些解決方案會提供數個層級的負載平衡、容錯移轉和複製服務。

單一伺服器系統

將所有服務的計算資源放置在單一伺服器上。如果伺服器發生錯誤，則整個服務會失敗。

圖 5–2 單一伺服器系統

顯示使用 10 個 CPU 來滿足效能需求的單一伺服器。

Sun 提供可帶來以下利益的高階伺服器：

高階伺服器通常比相較的多伺服器系統花費更大。然而，單一伺服器提供管理上的節約、監視和控管資料中心內伺服器的成本。負載平衡、容錯移轉和單一失敗點的移除比多伺服器系統更有彈性。

水平備援系統

有數種方式可使用平行備援伺服器同時提供負載平衡和容錯移轉增加可用性。下圖說明兩個重複伺服器提供 N+1 容錯移轉系統。N+1 系統在一個伺服器發生故障時由另一個伺服器提供 100% 的容量。

圖 5–3 N+1 容錯移轉系統和兩個伺服器

顯示各使用 10 個 CPU 來滿足 10 個 CPU 效能需求的兩個重複伺服器。

上述水平備援系統中每個伺服器的計算能力是完全相同的。一個伺服器單獨處理效能需求。另一個伺服器在作為備援啟用時提供100% 的效能。

N+1 容錯移轉設計的優點是在容錯移轉情況下還能擁有 100% 的效能。缺點包括增加硬體成本而沒有獲得對應的整體效能 (因為有一個作為備用的伺服器，僅限在容錯移轉情況中使用)。

下圖說明一個實作負載平衡和容錯移轉的系統，它在兩個伺服器之間分配效能。

圖 5–4 兩個伺服器之間的負載平衡和容錯移轉

顯示各使用 6 個 CPU 來滿足 10 個 CPU 效能需求的兩個伺服器。

在以上水平備援系統所描述的系統中，如果一個伺服器發生故障，所有服務仍然可用，只是容量達不到完整容量而已。剩餘的伺服器提供 6 個 CPU 的計算能力，為 10 個 CPU 需求的 60%。

此設計的優點是當兩個伺服器都可用時將帶來額外的 2 個 CPU 的潛在容量。

下圖說明在一些伺服器之間的效能和負載平衡的分配。

圖 5–5 在 n 個伺服器之間分配負載

顯示分別使用 2 個 CPU 來滿足 10 個 CPU 效能需求的五個伺服器。

因為水平備援系統所描述的設計中有五個伺服器，如果一個伺服器發生故障， 剩餘伺服器合計可提供 8 個 CPU 的計算能力，為 10 個 CPU 效能需求的 80%。如果在設計中額外增加一個具有 2 個 CPU 容量的伺服器，實際上便實現了 N+1 設計。如果一個伺服器發生故障，剩餘的伺服器可滿足 100% 的效能需求。

本設計包含以下優點：

然而，使用額外的伺服器會明顯地增加管理和維護費用。您也必須考慮在資料中心中控管這些伺服器的成本。在某些時候您會遇到新增額外伺服器造成的利潤縮減。

Sun Cluster 軟體

在需要高度可用性的情況下 (像是四或五個「九」的可用性)，可以考慮將 Sun Cluster 軟體作為可用性設計的一部份。叢集系統是備援伺服器、儲存裝置和其他網路資源的結合。叢集中的伺服器保持互相通訊。如果一個伺服器離線，叢集中剩餘的裝置會隔離該伺服器，並將任何應用程式或資料從錯誤節點故障轉移到其他節點。容錯移轉過程相對上會快速的完成，並且只對使用者的系統造成極小的服務中斷。

Sun Cluster 軟體需要額外的專用硬體和專門化技術來配置、管理和維護。

可用性設計範例

本節包含兩個可用性策略範例，它們基於以識別為基礎的通訊解決方案，該解決方案適用於員工人數為 1 千至 5 千的中型企業，如之前在以識別為基礎的通訊範例中所述。第一個可用性策略說明 Messaging Server 的負載平衡。第二個可用性策略說明使用 Sun Cluster 軟體的容錯移轉解決方案。

Messaging Server 的負載平衡範例

下表列出邏輯架構中 Messaging Server 的每個邏輯元件的 CPU 能力估計。此表格重複了更新 CPU 估計一節中計算的最終估計。

表 5–6 支援元件的 CPU 估計調整

元件 

CPU 

記憶體 

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 

對此範例而言，假設在技術需求階段期間，您已經指定下列的服務品質需求：

若要滿足可用性需求，為每個 Messaging Server 元件提供兩個實例，每個元件有一個實例位於不同的硬體伺服器上。如果一個元件的伺服器失敗，其他伺服器會繼續提供服務。下表說明此可用性策略的網路圖表。

架構圖顯示 Messaging Server MMP 和 MTA 元件的可用性。

在之前的圖表中，CPU 的數目已經比原本的估計增加了一倍。CPU 增加一倍的理由如下：

使用 Sun Cluster 軟體的容錯移轉範例

下圖顯示 Calendar Server 後端和 Messaging Server 訊息傳送儲存區的容錯移轉策略範例。Calendar Server 後端和訊息傳送儲存區會複製到不同的硬體伺服器上並使用 Sun Cluster 軟體對它們進行容錯移轉配置。在 Sun Cluster 的每個伺服器上複製 CPU 數目和對應的記憶體。

圖 5–6 使用 Sun Cluster 軟體的容錯移轉設計

顯示使用 Sun Cluster 軟體部署的具有容錯移轉能力的 Calendar Server 和 Message Server 儲存之架構圖。

目錄服務複製的範例

可以複製目錄服務以將作業事件分配到不同的伺服器上，從而提高可用性。Directory Server 提供針對複製服務的各種策略，其中包括以下項目：

Directory Server 的可用性策略是一個複雜的主題，不在本指南的討論範圍內。以下章節 (單一主機複製和多重主伺服器複製) 提供對基礎複製策略的高階檢視。如需詳細資訊，請參閱「Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide」第 12 章「Designing a Highly Available Deployment」。

單一主機複製

下圖顯示說明基本複製概念的單一主機複製策略。

圖 5–7 單一主機複製範例

本圖顯示單一主機複製策略的資料流程。

在單一主伺服器複製中，Directory Server 中的一個實例管理主目錄資料庫，並記錄所有變更。主要資料庫會複製到所有的用戶資料庫中。針對讀取和搜尋作業將 Directory Server 的用戶實例最佳化。用戶接收的任何寫入作業將會被導回主要資料庫中。主要資料庫會定期更新用戶資料庫。

單一主機複製的優點包括：

多重主伺服器複製

下圖顯示多重主機複製策略，可用來全域分散目錄存取。

在多重主伺服器複製中，Directory Server 的一或多個實例管理主目錄資料庫。每個主要資料庫都有複製協定，指定同步化主要資料庫的程序。每個主要資料庫複製為所有的用戶資料庫。與單一主伺服器複製一樣，也會針對讀取和搜尋存取將 Directory Server 的用戶實例最佳化。用戶接收的任何寫入作業將會被導回主要資料庫中。主要資料庫會定期更新用戶資料庫。

圖 5–8 多重主機複製範例

本圖顯示多重主機複製策略的資料流程。

多重主機複製策略擁有單一主機複製的所有優點，並具有可提供更新主要資料庫負載平衡的可用性策略。您也可以實作可用性策略，提供目錄作業的本端控制，這對資料中心分佈於全世界的企業而言是一個很重要的考量。

判定延展性策略

延展性是增加容量到您系統的能力，通常增加系統資源，但是不變更部署架構。在需求分析期間，您通常會根據業務需求和之後的使用分析來建立系統預期成長的設計。這些系統使用者數目的設計，以及符合其需求的系統容量，經常是與實際部署系統的數目會有顯著差異的評估。您的設計應該有足夠的彈性容許規劃中的差異。

可延伸的設計包括足夠的潛在容量，以便在系統使用額外資源升級之前，能夠處理增加的負載。可延伸的設計能可輕易調整以應付增加的負載，而無須重新設計系統。

潛在容量

潛在容量是您可以將額外的效能和可用性資源容納進系統中的延展性層面，以便系統可以處理不尋常的尖峰負載。您也可以監視在部署的系統中如何使用潛在容量，協助判定何時增加資源來調整系統。潛在容量是將安全性帶入您設計中的一種方式。

使用實例的分析可協助找出會造成不尋常尖峰負載的方案。使用這項不尋常尖峰負載的分析，加上容納非預期成長的因素，設計出可將安全性帶入系統的潛在容量。

您的系統設計應該能夠處理預期容量一段合理的時間，通常是作業的最初 6 到 12 個月。維護週期可在需要時用來增加資源或增加容量。理想狀況下，您應該可以定期排程系統的升級，但是預測需要的容量增加通常會很困難。依靠資源的仔細監視以及業務設計來判定何時要升級系統。

如果您規劃在遞增式階段中實作解決方案，您必須在每個遞增式階段，將系統容量的增加和其他排程的改善功能排程為同時發生。

延展性範例

本節中的範例說明以水平和垂直方式調整實作 Messaging Server 的解決方案。以垂直方式進行調整是透過為伺服器增加額外的 CPU 來處理增加的負載。 以水平方式進行調整是透過增加額外的伺服器，將負載分散來處理增加的負載。

範例基準假設為由兩個訊息儲存區實例支援 5 萬個使用者基礎，且已分散這些實例以取得負載平衡。每個伺服器有兩個 CPU，所以總共有 4 個 CPU。下圖顯示如何調整這個系統，以便為 250,000 個使用者和 2,000,000 使用者處理增加的負載。

備註 –

延展性範例顯示垂直調整和水平調整之間的差異。這個圖表不會顯示調整時需考慮的其他因素，例如負載平衡、容錯移轉和使用模式中的變更。

圖 5–9 水平和垂直調整的範例

架構圖顯示與基準架構進行比較的垂直和水平調整。

找出效能瓶頸

成功部署設計的其中一個關鍵就是找出潛在的效能瓶頸，以及開發避免瓶頸的策略。當存取的資料速率無法符合指定的系統需求時，效能瓶頸就會發生。

瓶頸可分為不同的硬體類別，如以下系統中資料存取點表格所示。此表也會建議每個硬體類別中瓶頸的潛在解決方法。

表 5–7 資料存取點

硬體類別 

相對的存取速度 

效能改善功能的解決方法 

處理器 

十億分之一秒 

垂直調整：增加更多處理能力，改善處理器快取能力 

水平調整：增加平行的處理能力以進行負載平衡 

系統記憶體 (RAM) 

一百萬分之一秒 

將系統記憶體指定給特定的作業 

垂直調整：增加額外的記憶體 

水平調整：建立額外的實例，以進行平行處理和負載平衡 

磁碟讀取和寫入 

毫秒 

使用磁碟陣列 (RAID) 使磁碟存取最佳化 

將磁碟存取指定給特定功能，例如唯讀或唯寫 

快取系統記憶體中經常存取的資料 

網路介面 

因網路上的頻寬和節點的存取速度而異 

增加頻寬 

傳輸安全資料時，增加加速卡硬體 

改善網路中節點的效能，使得能夠輕鬆隨時使用資料 

備註 –

找出效能瓶頸列出依據相對存取速度的硬體類別，暗指慢速存取點 (像是磁碟) 是瓶頸所在的可能性更高。不過，無法處理大量負載的處理器也可能是造成瓶頸的原因。

一般而言，部署設計通常是從部署中每個元件及其相依性的基準處理能力估計開始。然後，您再判定如何避免與系統記憶體和磁碟存取相關的瓶頸。最後，檢查網路介面以判定潛在的瓶頸，再將焦點放在可以解決瓶頸的策略上。

最佳化磁碟存取

部署設計的關鍵元件是對於時常存取的資料集 (如 LDAP 目錄) 的磁碟存取速度。磁碟存取提供最慢的資料存取，可能是造成效能瓶頸的原因。

最佳化磁碟存取的方法就是將寫入作業和讀取作業分開。不單是因為寫入作業比讀取作業費時，而且讀取作業 (查詢 LDAP 目錄的作業) 發生的機率通常也比寫入作業 (更新 LDAP 目錄中的資料) 來得大。

另一個最佳化磁碟存取的方法是將磁碟指定給不同的 I/O 作業。例如，為 Directory Server 記錄作業 (像是作業事件記錄和事件記錄) 及 LDAP 讀取和寫入作業提供獨立的磁碟存取。

此外，考慮實作一或多個 Directory Server 實例專用於讀取和寫入作業，並使用分配到本機伺服器的複製實例進行讀取和搜尋存取。也可以使用鏈接和連結選項來最佳化目錄服務的存取。

「Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide」第 6 章「Defining System Characteristics」中討論了磁碟存取規劃的各種因素。本章的主題包括：

設計最佳化資源使用

部署設計不只是估計滿足 QoS 需求需要的資源。在部署設計期間，您也要分析所有可用的選項，並選擇最佳的解決方案，這個解決方案必須能將成本降到最低但仍然可以滿足 QoS 需求。您必須分析每個設計決定的利弊，以確保一個領域中的獲利不會被另一個領域中的成本抵銷。

例如，可用性的水平調整可能會增加整體可用性，然而代價是增加維護和服務。效能的垂直調整可能會廉價地增加計算能力，但是額外的能力可能會被某些裝置沒有效率地使用。

在完成設計策略之前，審核決定以確認您已經從提議解決方案的整體利益平衡資源的使用。這個分析通常包含檢查一個區域的系統品質如何影響其他的系統品質。下表列出某些系統品質和資源管理的對應考量。

表 5–8 資源管理考量

系統品質 

說明 

效能

對於將 CPU 集中在個別伺服器上的效能解決方案，服務是否能有效地利用計算能力？(例如，某些裝置對能夠有效使用的 CPU 數目有限制。) 

潛在容量 

您的策略是否能處理超過效能估計的負載？ 

在伺服器上使用垂直調整處理過度的負載，平分負載到其他伺服器，或是兩者同時使用？ 

潛在容量足夠處理不尋常的尖峰負載，一直到您達成調整部署的下一個基準點嗎？ 

安全性

您曾經充分地說明處理安全交易需要的效能費用嗎？ 

可用性

就水平備援解決方案而言，您曾經充分地估計長期維護的費用嗎？ 

您曾經考慮過維護系統必要的排程停工期？ 

您是否平衡過高階伺服器和低階伺服器的成本？ 

延展性

您曾經評估過需調整部署的基準點嗎？ 

您是否有策略可提供足夠的潛在容量處理負載的預期增加，直到您觸及需調整部署的基準點為止？ 

服務性

您有將管理、監視和維護成本考慮到您的可用性設計中嗎？ 

您曾經考慮過委託管理解決方案 (讓一般使用者執行某些管理作業) 來減少管理成本嗎？ 

管理風險

部署設計所根據的大部分資訊，例如服務品質需求和使用分析，並非經驗資料而是基於評估和規劃。可能造成這些設計不正確的原因很多，包括業務環境中未預期的情況、收集資料的方法錯誤或是人為疏失。在完成部署設計前，重新檢視設計所依據的分析，並確定您的設計考慮到任何來自評估或規劃的合理誤差。

例如，如果使用分析低估系統的實際使用，您將面臨無法應付流量的系統風險。在表現水準下的設計無疑將被視為失敗。

另一方面，如果您建立一個超出需要的多層級系統，則會將可用於別處的資源分散掉。關鍵在於將安全性的極限包含於需求之上，但避免浪費資源。

浪費資源可能也會導致設計失敗，因為沒利用到的資源原本應該應用在其他領域。此外，浪費的解決方案可能會被利害關係人視為不良的合約履行。

範例部署架構

下圖表示本白皮書稍早介紹的範例部署的完整部署架構。本圖提供一個表現部署架構的概念。

注意 – 注意 –

下圖中的部署架構只限於圖解說明使用。其並不代表已實際設計、建立或測試過的部署，而且不應視為部署規劃的建議。

圖 5–10 範例部署架構

本圖顯示部署架構的佈局範例。