開發可用性需求的策略時,請研究元件互動和使用分析來判定要考慮哪個可用性解決方案。以基於元件的方式來進行分析,判定最能符合可用性和容錯移轉需求的解決方案。
下列項目是您蒐集的資訊類型範例,可用來判定可用性策略:
可用性中指定了多少個「九」?
哪些是與容錯移轉狀況相關的效能規格 (例如在容錯移轉期間最少為效能的 50%)?
使用分析是否區分尖峰和非尖峰使用的時間?
地理考量為何?
所選的可用性策略還必須考慮服務性需求,如設計最佳化資源使用中所討論的。避免需要大量管理和維護的複雜型解決方案。
Java Enterprise System 部署的可用性策略包括下列項目:
負載平衡。使用備援硬體和軟體元件來共擔處理負載。負載平衡器會將服務的任何要求導向到該服務的其中一個多重對稱式實例。如果任何一個實例失敗,還可以使用其他實例繼續較大量的負載。
容錯移轉。包含對備援硬體和軟體進行管理,以在任何元件發生故障時能繼續存取服務及繼續保持關鍵資料的安全性。
Sun Cluster 軟體提供針對由後端元件管理的關鍵資料的容錯移轉解決方案,像是 Messaging Server 的訊息儲存和 Calendar Server 的行事曆資料便是這樣的關鍵資料。
複製服務。複製服務提供可存取相同資料的數個來源。Directory Server 提供眾多針對 LDAP 目錄存取的複製和同步化策略。
下列章節提供數個可用性解決方案的範例,這些解決方案會提供數個層級的負載平衡、容錯移轉和複製服務。
將所有服務的計算資源放置在單一伺服器上。如果伺服器發生錯誤,則整個服務會失敗。
Sun 提供可帶來以下利益的高階伺服器:
在系統執行時硬體元件可取代和重新裝配
在伺服器上的錯誤隔離網域中執行多個應用程式的能力
無須重新啟動系統即可升級容量、效能速度和 I/O 配置的能力
高階伺服器通常比相較的多伺服器系統花費更大。然而,單一伺服器提供管理上的節約、監視和控管資料中心內伺服器的成本。負載平衡、容錯移轉和單一失敗點的移除比多伺服器系統更有彈性。
有數種方式可使用平行備援伺服器同時提供負載平衡和容錯移轉增加可用性。下圖說明兩個重複伺服器提供 N+1 容錯移轉系統。N+1 系統在一個伺服器發生故障時由另一個伺服器提供 100% 的容量。
上述水平備援系統中每個伺服器的計算能力是完全相同的。一個伺服器單獨處理效能需求。另一個伺服器在作為備援啟用時提供100% 的效能。
N+1 容錯移轉設計的優點是在容錯移轉情況下還能擁有 100% 的效能。缺點包括增加硬體成本而沒有獲得對應的整體效能 (因為有一個作為備用的伺服器,僅限在容錯移轉情況中使用)。
下圖說明一個實作負載平衡和容錯移轉的系統,它在兩個伺服器之間分配效能。
在以上水平備援系統所描述的系統中,如果一個伺服器發生故障,所有服務仍然可用,只是容量達不到完整容量而已。剩餘的伺服器提供 6 個 CPU 的計算能力,為 10 個 CPU 需求的 60%。
此設計的優點是當兩個伺服器都可用時將帶來額外的 2 個 CPU 的潛在容量。
下圖說明在一些伺服器之間的效能和負載平衡的分配。
因為水平備援系統所描述的設計中有五個伺服器,如果一個伺服器發生故障, 剩餘伺服器合計可提供 8 個 CPU 的計算能力,為 10 個 CPU 效能需求的 80%。如果在設計中額外增加一個具有 2 個 CPU 容量的伺服器,實際上便實現了 N+1 設計。如果一個伺服器發生故障,剩餘的伺服器可滿足 100% 的效能需求。
本設計包含以下優點:
增加單一伺服器錯誤時的效能
當一個以上的伺服器當機時依然可用
伺服器可轉出服務以便維護和升級
多個低階伺服器通常花費低於單一高階伺服器
然而,使用額外的伺服器會明顯地增加管理和維護費用。您也必須考慮在資料中心中控管這些伺服器的成本。在某些時候您會遇到新增額外伺服器造成的利潤縮減。
在需要高度可用性的情況下 (像是四或五個「九」的可用性),可以考慮將 Sun Cluster 軟體作為可用性設計的一部份。叢集系統是備援伺服器、儲存裝置和其他網路資源的結合。叢集中的伺服器保持互相通訊。如果一個伺服器離線,叢集中剩餘的裝置會隔離該伺服器,並將任何應用程式或資料從錯誤節點故障轉移到其他節點。容錯移轉過程相對上會快速的完成,並且只對使用者的系統造成極小的服務中斷。
Sun Cluster 軟體需要額外的專用硬體和專門化技術來配置、管理和維護。
本節包含兩個可用性策略範例,它們基於以識別為基礎的通訊解決方案,該解決方案適用於員工人數為 1 千至 5 千的中型企業,如之前在以識別為基礎的通訊範例中所述。第一個可用性策略說明 Messaging Server 的負載平衡。第二個可用性策略說明使用 Sun Cluster 軟體的容錯移轉解決方案。
下表列出邏輯架構中 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 |
對此範例而言,假設在技術需求階段期間,您已經指定下列的服務品質需求:
可用性。整體系統的可用性應為 99.99% (不含排程當機時間)。個別電腦系統的失敗應該不會導致服務失敗。
延展性。在每日尖峰負載下,不應讓任何伺服器的容量使用率超過 80%,且系統必須能夠長期地因應每年 10% 的負載增長。
若要滿足可用性需求,為每個 Messaging Server 元件提供兩個實例,每個元件有一個實例位於不同的硬體伺服器上。如果一個元件的伺服器失敗,其他伺服器會繼續提供服務。下表說明此可用性策略的網路圖表。
在之前的圖表中,CPU 的數目已經比原本的估計增加了一倍。CPU 增加一倍的理由如下:
在一個伺服器失敗的情況下,其餘的伺服器會繼續提供處理負載的 CPU 能力。
對於在尖峰負載下單一伺服器的容量使用率不能超過 80% 的延展性需求,增加的 CPU 能力可以滿足這個安全性界限。
對於延展性需求 (系統必須容納每年 10% 的成長),新增的 CPU 能力會增加潛在容量,以便在需要額外調整時能夠處理增加的負載。
下圖顯示 Calendar Server 後端和 Messaging Server 訊息傳送儲存區的容錯移轉策略範例。Calendar Server 後端和訊息傳送儲存區會複製到不同的硬體伺服器上並使用 Sun Cluster 軟體對它們進行容錯移轉配置。在 Sun Cluster 的每個伺服器上複製 CPU 數目和對應的記憶體。
可以複製目錄服務以將作業事件分配到不同的伺服器上,從而提高可用性。Directory Server 提供針對複製服務的各種策略,其中包括以下項目:
多個資料庫。在不同的資料庫中儲存同一目錄樹狀結構的不同部分。
鏈接和參照。將分散式資料連結到單一的目錄樹狀結構。
單一主伺服器複製。提供主資料庫的集中來源,之後再分配給用戶副本。
多重主伺服器複製。將主資料庫分散在數個伺服器之上。每個主要資料庫接著都會將他們的資料庫分散到用戶的副本。
Directory Server 的可用性策略是一個複雜的主題,不在本指南的討論範圍內。以下章節 (單一主機複製和多重主伺服器複製) 提供對基礎複製策略的高階檢視。如需詳細資訊,請參閱「Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide」第 12 章「Designing a Highly Available Deployment」。
下圖顯示說明基本複製概念的單一主機複製策略。
在單一主伺服器複製中,Directory Server 中的一個實例管理主目錄資料庫,並記錄所有變更。主要資料庫會複製到所有的用戶資料庫中。針對讀取和搜尋作業將 Directory Server 的用戶實例最佳化。用戶接收的任何寫入作業將會被導回主要資料庫中。主要資料庫會定期更新用戶資料庫。
單一主機複製的優點包括:
針對資料庫讀取和寫入作業將 Directory Server 的單一實例最佳化
針對讀取和搜尋作業將 Directory Server 的任意數量用戶實例最佳化
Directory Server 用戶實例的水平延展性
下圖顯示多重主機複製策略,可用來全域分散目錄存取。
在多重主伺服器複製中,Directory Server 的一或多個實例管理主目錄資料庫。每個主要資料庫都有複製協定,指定同步化主要資料庫的程序。每個主要資料庫複製為所有的用戶資料庫。與單一主伺服器複製一樣,也會針對讀取和搜尋存取將 Directory Server 的用戶實例最佳化。用戶接收的任何寫入作業將會被導回主要資料庫中。主要資料庫會定期更新用戶資料庫。
多重主機複製策略擁有單一主機複製的所有優點,並具有可提供更新主要資料庫負載平衡的可用性策略。您也可以實作可用性策略,提供目錄作業的本端控制,這對資料中心分佈於全世界的企業而言是一個很重要的考量。