test

Sun Java System Application Server 9.1 部署規劃指南

規劃可用性

本小節包含下列主題：

最佳化可用性

若要規劃系統與應用程式的可用性，請評估存取不同應用程式之使用者群組的可用性需求。例如，付費的外部使用者與企業夥伴常比內部使用者有更高的服務品質 (QoS) 期望。因此，內部使用者可能比付費的外部用戶較能接受應用程式功能、應用程式或伺服器無法使用。

下圖描述為了減少可能發生的事件，成本與複雜度會如何增加。在此連續曲線的一端，簡易負載平衡的叢集即可容許本土化應用程式、中介軟體與硬體故障。在圖表的另一端，位置不同的叢集可降低影響整個資料中心的重大災難。

若要實現理想的投資報酬率，通常最好找出應用程式內各功能的可用性需求。例如，保險報價系統絕對不能無法使用 (可能會失去新業務)，但是帳號管理功能 (現有用戶可由此檢視其目前的保險項目) 暫時無法使用則不太可能會失去現有的用戶。

使用叢集改善可用性

在最基本的層級中，叢集是一組應用程式伺服器實例 (通常代管於多個實體伺服器上)，並讓用戶端以為是單一實例。如此可提供水平延展性，以及比單一機器上的單一實例更高的可用性。此基本叢集層級結合 Application Server 的 HTTP 負載平衡器外掛程式使用，該外掛程式接受 HTTP 與 HTTPS 請求，並會轉寄給叢集中其中一個應用程式伺服器實例。ORB 與整合的 JMS 代理程式也會對應用程式伺服器叢集執行負載平衡。若實例出現故障而無法使用 (因為網路故障) 或無回應，請求僅會重新導向至現有的可用機器。負載平衡器還可以識別出現故障的實例是否已回復，並會隨之重新分配負載。

HTTP 負載平衡器也提供運作狀態檢查程式，該程式可監視伺服器與特定 URL，以判斷其是否可用。您必須謹慎管理運作狀態檢查的經常性耗用時間，使其本身不會成為龐大的處理負擔。

對於無狀態應用程式或價值不高、僅需簡單使用者作業事件的應用程式，通常只需要簡易負載平衡的叢集。對於有狀態的關鍵性應用程式，請考慮使用 HADB 取得階段作業持續性。如需 HADB 的簡介，請參閱「Application Server Administration Guide」第 1 章, 產品概念中高可用性資料庫。

若要執行應用程式的線上升級，最好將一應用程式伺服器實例分組為多個叢集。Application Server 可同時靜止應用程式與實例。靜止是以控制的方式讓實例 (或實例群組) 或特定應用程式離線的功能，而且其不會影響實例或應用程式目前提供服務的使用者。當一個實例靜止時，新的使用者會由其他實例上已升級的應用程式提供服務。此應用程式升級類型稱為輪替式升級。如需有關升級即時應用程式的更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的「在維持可用性的情況下升級應用程式」。

增加系統的備援

達成高可用性的一個方式是增加系統的軟硬體備援。當一個單元故障時，備援單元會接管。這又稱為容錯。一般來說，若要有最佳的高可用性，請判斷並移除系統中每個可能的故障點。

找出故障類別

備援層級取決於系統需要容許的故障類別 (故障的類型)。以下是一些故障類別範例：

複製系統程序可容許單一系統程序故障，以及單一機器故障。將複製的鏡像 (成對) 機器接到不同的電源供應，即可容許單一電源故障。透過將鏡像機器保留在不同的建築物中，可容許單一建築物失火。透過將鏡像機器保留在不同的地理位置，可容許地震等天災。

使用 HADB 備援單元改善可用性

若要改善可用性，一律請如建立效能目標中所述，在資料備援單元 (DRU) 中使用 HADB 節點。

使用 HADB 備用節點改善容錯

使用備用節點改善容錯。雖然備用節點不是必要項目，但可提供最佳的可用性。

規劃容錯移轉容量

容錯移轉容量規劃是指決定需要額外增加至 Application Server 部署的伺服器與程序數目，如此一來，當伺服器或程序故障時，系統可緊密地回復資料並繼續處理。若系統超載，可能會產生程序或伺服器故障，造成回應時間變慢或甚至失去整個服務。為這類事件做足準備對於成功部署非常重要。

若要維持容量，特別是在尖峰負載時，請將執行應用程式伺服器實例的備用機器增加至現有的部署中。

例如，假設某部系統有兩部機器，各執行一個應用程式伺服器實例。這些機器在尖峰負載時每秒總共可處理 300 個請求。如果一部機器無法使用，系統將只能處理 150 個請求 (假設機器之間平均分散負載)。因此將會無法處理尖峰負載期間的一半請求。