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

判定可用性策略

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

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

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

可用性策略

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,內送) 

4 GB 

Messaging Server (MTA,外傳) 

4 GB 

Messaging Server (MMP) 

4 GB 

Messaging Server (Message Store) 

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 多重主機複製範例

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

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