|
| |
| Sun Java Enterprise System 部署規劃白皮書 | |
第 5 章
設計部署架構本章提供如何設計一個具有效能、安全性、可用性和其他系統品質的部署的資訊。本章也提供最佳化部署設計的資訊。
一個部署架構描述邏輯架構到實體環境的對映。實體環境包括企業內部網路或是網際網路環境中的計算機節點、CPU、記憶體、儲存裝置和其他硬體及網路裝置。
設計部署架構包含調整部署大小 來決定必要的實體資源以符合技術需求階段中指定的系統需求。您也要透過分析調整部署大小的結果來最佳化資源，以便在商業限制內建立可提供最佳資源使用的設計。
在完成部署架構設計後，實際的部署成本會在專案核准 期間評估。一旦核准專案後，需簽訂部署完成的合約並取得實施專案的資源。
詳細設計規格 會在專案核准之前或之後產生。詳細設計規格用在實施階段建立設計時。
本章繼續使用第 4 章中的範例部署，圖解設計部署架構的過程中各種步驟。
本章包含以下各節：
調整規劃部署大小調整規劃部署的大小是決定硬體資源 (滿足系統需求所需要的，最終滿足商業目標) 組合的過程。由於要配合其他規劃和設計部署的層面，調整大小不是一項精密科學，也無法以公式或處方來規定。成功的調整大小是過去設計經驗、系統架構的知識、領域知識，和應用創造性思惟的組合結果。
調整大小以您之前為以下系統品質所決定的系統需求為中心，如系統需求中所述。來自部署設計早期階段的商業需求、使用分析以及使用實例也在調整系統大小中扮演重要的角色。
當執行調整大小練習時，使用實例和使用分析可幫助決定支援使用實例需要的資源。您通常會從加權最重的使用實例開始 (代表最常見的交易)，然後繼續下去到加權最輕的。加權使用實例的使用可根據預期的系統重點來幫助分配資源。
以下章節提供如何為以下系統品質調整部署大小的一般指南：
調整效能大小
調整效能和負載需求大小是一項反覆的過程，其評估支援部署系統中服務需要的 CPU 的數目和對應記憶體。當評估支援服務需要的 CPU 數目時，考慮以下幾點：
調整效能的過程通常包含下列步驟。這些步驟的順序並不是關鍵 — 這只是提供一個考慮會影響最後結果的因素的方法。
決定使用者進入點的基線 CPU 估計
從估計需要的 CPU 數量開始來處理每個作為使用者進入點的元件上預期的負載。注意您邏輯架構的佈局設計上的估計。
下圖使用部署規劃範例中介紹的範例部署，描述作為使用者進入點的元件之初步 CPU 估計。這些估計代表可能從系統需求、使用實例和使用分析產生的數量。
圖 5-1 提供使用者進入點的元件的基線 CPU 估計
調整服務依賴性的 CPU 估計
提供使用者進入點的元件需要 Java Enterprise System 服務的支援。若要繼續指定效能需求，調整效能估計以考慮其他元件需要的支援。
在範例中，檢查資料的邏輯流程，如圖 4-4 中的圖解，並調整提供支援到其他元件的元件。下表總結對 CPU 估計的調整。在您的估計中，可以指定部分的 CPU。當完成效能估計時，將合計並集中 CPU 計數。
如同前一節使用的估計，下表中的效能估計為任意值，僅限於圖解使用。
表 5-1 支援服務的 CPU 估計
服務
估計
描述
Portal Server
無
未提供支援到其他服務。
Calendar Server
1 CPU
提供支援到：
Messaging Server
1.5 CPU
提供支援到：
Identity Server
3 CPU
提供支援到：
Directory Server
5 CPU
提供支援到：
下圖根據表 5-1 中的資訊更新效能的估計。
圖 5-2 為支援服務調整的 CPU 估計
調整潛在容量、延展性和可用性的 CPU 估計
一旦您完成效能的估計，集中 CPU 的數量。通常您要將 CPU 集中到下一個偶數。當集中 CPU 估計時，考慮以下的因素：
下圖調整範例部署的 CPU 估計。圖例也指出每個 CPU 的記憶體需求。範例假定每個 CPU 需要 2GB 記憶體。這些範例的記憶體規格為任意值，只限於圖解使用。計算每個 CPU 的記憶體需求已經超過本白皮書的範圍。
圖 5-3 效能圖例包括記憶體需求
調整安全性大小
當調整部署大小時，安全性問題變成下列方式中的一項因素：
資料的安全傳輸包括通過安全傳輸協定處理交易，例如 Secure Sockets Layer (SSL)。使用者的認證也需要處理通過安全傳輸的交易。
通過安全傳輸處理的交易通常需要額外的計算能力，首先要建立安全作業階段 (稱為訊號交換)，其次加密和解密傳輸資料。根據使用的加密演算法 (例如 40 位元或 128 位元加密演算法)，可能另外需要充足的計算能力。
考慮在非安全交易的同層級上執行安全交易時，您必須規劃額外的計算能力。根據交易的特性以及處理交易的 Java Enterprise System 服務而定，安全交易可能需要四倍 (或更高) 的計算能力。
當評估處理安全交易的效能需求時，首先分析使用實例來決定需要安全傳輸的交易百分比。如果安全交易的效能需求與非安全交易相同，修改 CPU 估計為安全交易需要的額外計算能力。
在某些使用方案中，安全傳輸可能只需要用來認證。一旦使用者經由系統認證，就不需要額外的資料傳輸安全性評量。在其他方案中，所有的交易可能都需要安全傳輸。在許多實例中合理估計約有百分之五到十的交易需要安全傳輸。
例如，在線上電子商務網站瀏覽產品目錄時，直到客戶完成選擇並準備「結帳」前，所有的交易可能都是不安全的。同時許多這類的電子商務網站放鬆安全交易的潛在反應需求。然而有些使用方案，例如銀行或證券經濟商的部署則非常需要安全交易，並非全部的交易都能安全並應用相同的效能標準到安全和非安全交易。
計算安全交易的效能
本節繼續以範例部署圖解使用實例的計算 CPU 需求，實例包括安全和非安全交易。
若要計算 CPU 需求，在試算表中建立以下計算：
- 從 CPU 需求的基礎計算開始，如同您在前一節 (調整效能大小) 所計算的。
- 計算需要 SSL 的交易百分比，並計算 SSL 交易的 CPU 需求。
- 調整非安全交易的 CPU 計算。
- 清點安全和非安全需求以計算總 CPU 需求。
圖 5-4 中的試算表是根據 Portal Server 的額外使用實例和使用分析。額外使用實例和使用分析假定如下：
此範例的目的為，考量到計算處理 SSL 交易所需要的額外計算能力，處理交易的 CPU 數量將增加五倍。如同範例中其他的 CPU 計算，這是一個只限於圖例說明使用的隨意計算。
圖 5-4 計算安全交易的 CPU 估計的試算表
處理 SSL 交易的專門硬體
專門硬體裝置，例如 SSL 加速卡和其他裝置，可用來提供處理安全作業階段建立的計算能力，和/或資料的加密或解密。在使用專門的 SSL 作業硬體時，計算能力專用於 SSL 計算的某一部份，這部份通常是建立安全作業階段的「訊號交換」作業。
此硬體可能對您最後的部署架構有益。然而，因為硬體的專門特性，最好先評估 CPU 能力方面的安全交易效能需求，然後再考慮使用專門硬體處理額外負載的利益。
當使用專門硬體時要考慮的一些因素是使用實例是否支援使用硬體 (例如，需要大量「訊號交換」作業的使用實例)，以及此類硬體帶給設計的複雜性附加層面。該複雜性包括安裝、配置、測試和裝置管理。
調整可用性大小
在您完成調整效能的大小後，您可以開始調整您系統的可用性大小。這是您指定特定伺服器主控邏輯架構中的元件之處，以及設計各種 Java Enterprise System 元件的負載平衡、冗位和故障轉移策略之處。
研究使用實例和使用分析來決定應該考慮何種可用性解決方案。下列項目是您蒐集的資訊類型範例，可用來決定可用性策略：
對每個元件，分析使用實例來決定故障轉移和負載平衡需求的最佳解決方案。同時，考慮使用實例和使用分析來決定負載平衡服務的最佳方式。
您選擇的可用性策略也要考慮服務性需求，如可服務性問題中所討論。試著避免需要大量管理和維護的複雜解決方案，這樣有利於簡化管理系統。
複雜系統的目錄設計
大量使用者的複雜部署可能需要可以影響可用性策略的 Directory Server 目錄設計。這是因為 LDAP 目錄設計可能影響 Identity Server 和 Messaging Server 的可用性策略，依次影響到其他系統品質。
如果您設計的是複雜的部署，請考慮建立一個預備的目錄設計來協助可用性設計。之後，在詳細設計規格或開發階段期間，提供完整目錄設計。
硬體和軟體錯誤
您的可用性設計應該提供硬體和軟體錯誤的保護。軟體錯誤通常比硬體錯誤具有較高的成本。軟體錯誤之間比起硬體錯誤之間有較高的平均時間。此外，軟體錯誤較難診斷和修復並且需要較高的管理和維護成本來預防。
可用性的一般方式
本節提供您可以為可用性需求設計的某些一般方式。特定的可用性設計超過本白書的範圍。
單一伺服器系統
將您所有服務的計算資源放置在單一伺服器上。如果伺服器發生錯誤，則整個服務會失敗。
圖 5-5 單一伺服器
Sun 提供高階伺服器，其提供下列效益：
高階伺服器通常比相較的多伺服器系統花費更大。然而，單一伺服器可以節約管理，監控和控管資料中心內伺服器的成本。然而，負載平衡、故障轉移和單一失敗點的移除比多伺服器系統更有彈性。
水平冗餘系統
有數種方式可使用平行冗餘伺服器 (同時提供負載平衡和故障轉移) 增加可用性。下圖說明兩個重複伺服器提供 N +1 可用性系統。N+1 系統在一個伺服器錯誤時有額外的元件可提供 100% 的容量。
圖 5-6 兩個重複伺服器
在上述圖 5-6 當中每個伺服器的計算能力是相同的。一個伺服器單獨處理效能需求。其他伺服器在呼叫服務做為備份時提供 100% 的效能。
重複伺服器設計的優點在於故障轉移狀況期間為 100% 的效能。缺點包括增加硬體成本而沒有獲得對應的整體效能。
下圖說明在兩個負載平衡和故障轉移的伺服器之間分配效能的方案。
圖 5-7 在兩個伺服器之間分配負載
在上述圖 5-7 中，如果一個伺服器錯誤，所有服務仍然可使用，儘管只是全部容量的一部分百分比。剩餘的伺服器提供計算能力的 6 CPU，其為 10 CPU 需求的 60%。
此設計的優點為兩個伺服器都可使用時有額外的 2 CPU 潛在容量。同時如果一個伺服器錯誤，所有的服務都可使用，但是可能會減低效能。
下圖說明在一些伺服器之間的效能和負載平衡的分配。
圖 5-8 在 n 個伺服器之間分配負載
因為在圖 5-8 中的設計圖解說明有五個伺服器，如果一個伺服器錯誤，剩餘的伺服器提供的計算能力合計為 8 CPU，其為 10 CPU 效能需求的 80%。如果您增加 2 CPU 容量的額外伺服器到設計中，實際上您已具有一個 N+1 設計。如果一個伺服器錯誤，100% 的效能需求會由剩餘的伺服器達成。
本設計包含以下優點：
然而，使用額外的伺服器會明顯地增加管理和維護費用。資料中心內的伺服器也有主控成本。在某些時候您會遇到新增額外伺服器造成的利潤縮減。
Sun Cluster
在需要高度可用性的情況 (例如四或五個「九」)，您可能會考慮 Sun Cluster 作為您的可用性設計的一部份。叢集系統是伺服器、儲存裝置和其他網路資源的結合。叢集中的伺服器保持互相通訊。如果一個伺服器離線，叢集中剩餘的裝置會隔離該伺服器，並將任何應用程式或資料從錯誤節點故障轉移到其他節點。錯誤轉移過程相對上會快速的完成，並且只對使用者的系統造成極小的服務中斷。
Sun Cluster 需要額外的專用硬體和專門技術來配置、管理和維護。
範例部署的可用性設計
下圖顯示範例部署的行事曆服務部分的可用性設計，說明在第 4 章，「設計邏輯架構」圖例描述範例部署的邏輯架構的 Calendar Server 部分的可用性解決方案。範例部署的完整可用性解決方案分析已經超過本白皮書的範圍。
本章前面的調整大小練習決定 Calendar Server 需要 6 CPU 和 12 GB 的記憶體，如圖 5-3 中所述。下圖顯示部署在兩個伺服器上的 Calendar Server 的前端用於負載平衡進出的要求。Calendar Server 的後端部署在獨立的伺服器上，並複製在 Sun Cluster 3.1 4/04 當中作為故障轉移用。為了故障轉移使用，Calendar Server 後端需要的 CPU 和記憶體複製在 Sun Cluster 3.1 4/04 當中。
圖 5-9 範例部署中的 Calendar Server 的可用性設計
可服務性問題
在設計可用性時，您也必須考慮解決方案的管理和維護成本。這些成本在設計中經常被忽略，因為並不會明確地與硬體採購綁在一起。當然，這些可能會被隱藏，花費的成長反映出您設計的複雜性。
例如，您的設計可能包括大量的可提供高度可用性的水平冗餘伺服器。但是如果您不將安裝和配置伺服器、持續升級軟體和監控系統運作狀態的成本列入重要因素，可能會危及可用性的取得。
在設計可服務性時，考慮下列管理和維護成本：
調整延展性大小
延展性形容增加容量到您系統的能力，通常是系統資源的附加，但是不變更部署架構。本節討論設計延展性時考量的主題。
在需求分析期間，您通常會根據商業需求和之後的使用分析來建立系統預期成長的設計。這些系統使用者數目的設計，以及符合其需求的系統容量，經常是與實際部署系統的數目會有顯著差異的評估。您的設計應該有足夠的彈性容許規劃中的差異。
潛在容量
潛在容量是您可以將額外的效能和可用性資源容納進系統中的延展性層面，以便於處理不尋常的尖峰負載。潛在容量是將安全性帶入您設計中的一種方式。
仔細分析使用實例能夠幫助確認可建立不尋常尖峰負載的方案 (例如，一個可排程強制網路廣播的企業對員工的部署)。使用這項不尋常尖峰負載的分析，加上容納非預期成長的因素，設計出可將安全性帶入系統的潛在容量。
您也可以監控在部署的系統中如何使用潛在容量，協助決定何時需要增加資源來調整系統。
升級系統容量
您的系統設計應該能夠處理計畫容量的前 6 到 12 個月的作業。維護週期可在需要時用來增加資源或增加容量。理想狀況下，您應該可以定期排程系統的升級，但是預測需要的容量增加通常會很困難。依靠資源的仔細監控以及業務設計來決定何時要升級系統。
如果您執行的是增量式的部署，其中因為業務或技術原因而延遲的系統部分部署，可以將系統容量的升級排程與其他包含系統新功能的升級同時發生。
最佳化資源調整部署大小不只是符合系統需求的資源評估。調整規模也是風險管理和資源管理的練習。一項設計如何處理風險管理和資源管理經常是達成商業目標的關鍵。
風險管理
調整大小所根據的大部分資訊，例如商業需求和使用分析，並非經驗資料而是基於評估和規劃。在完成規劃部署的調整前，重新檢視資料並確定您的調整設計考慮到任何來自評估或規劃的合理誤差。
例如，如果商業需求的設計低估系統的實際使用，您會擔負建立起一個無法應付流量的系統風險。在表現水準下的設計無疑將被視為失敗。
另一方面，如果您建立一個超出需要的多層級系統，則會將可用於別處的資源分散掉。關鍵在於將安全性的極限包含於需求之上，但避免浪費資源。
浪費資源可能也會導致設計失敗，因為沒利用到的資源原本應該應用在其他成功關鍵的領域。此外，浪費的解決方案可能會被視為不良的合約履行。
管理資源
管理資源是分析所有可用調整選項的過程，以及選擇成本最小化但仍滿足系統需求的最佳解決方案。這包括了瞭解每個設計決定的交易，以確保一個領域中的獲利不會被另一個領域中的成本抵銷。
例如，可用性的水平調整可能會增加整體可用性，然而代價是增加維護和服務。效能的垂直調整可能會廉價地增加計算能力，但是額外的能力可能會被某些裝置沒有效率地使用。
在完成調整策略之前，檢查您的決定確認您已經從設計的整體利益平衡資源的使用。這通常包含檢查一個區域的系統品質如何影響其他的系統品質。下表列出某些您可能要為資源管理考慮的主題。
範例部署架構下圖表示本白皮書稍早介紹的範例部署的完整部署架構。本圖提供一個表現部署架構的概念。.
圖 5-10 範例部署架構
詳細設計規格在部署架構完成後，有一段客戶審核的期間，接著是期待專案的核准。有時候客戶可能會在同意核准之前再要求您修改部署架構。
在專案核准後，您建立一個做為部署實施起始點的詳細設計規格。設計規格包括特定硬體資源和網路裝置的細節，以及詳細的 LDAP 目錄規格。
