test

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

第 1 章 產品概念

Sun Java System Application Server 提供強大的平台，可供開發、部署及管理 J2EE 應用程式之用。主要功能包括具延伸性的作業事件管理、容器管理式的持續性執行階段、Web 服務效能、叢集、高可用性階段作業狀態、安全性以及整合等功能。

本小節包含以下主題：

J2EE 平台簡介

Application Server 實作 Java 2 Enterprise Edition (J2EE) 1.4 技術。J2EE 平台是一組標準規格，旨在說明應用程式伺服器的應用程式元件、API，以及執行階段容器與服務。

J2EE 應用程式

J2EE 應用程式由 JavaServer Pages (JSP)、Java servlet 與 Enterprise JavaBeans (EJB) 模組等元件所組成。這些元件可供軟體開發人員建立大型之分散式應用程式。開發人員可將 J2EE 應用程式封裝為 Java 歸檔 (JAR) 檔案 (類似壓縮檔案)，然後發行至各生產站點。管理員透過將 J2EE JAR 檔案部署在一或多個伺服器實例 (或實例叢集)，可將 J2EE 應用程式安裝在 Application Server 上。

下圖說明將於以下章節討論的 J2EE 平台元件。

抱歉：目前尚未提供此圖。

容器

每個伺服器實例包含兩個容器：Web 和 EJB。容器是指提供 J2EE 元件安全性與作業事件管理等服務的執行階段環境。Web 元件 (例如 JSP 和 servlet) 執行於 Web 容器內。Enterprise JavaBeans 執行於 EJB 容器內。

J2EE 服務

J2EE 平台提供應用程式服務，包括：

Web 服務

用戶端除了可透過 HTTP、RMI/IIOP 與 JMS 存取 J2EE 1.4 應用程式外，還可以遠端 Web 服務的方式加以存取 。Web 服務的實作是使用 Java API for XML-based RPC (JAX-RPC)。J2EE 應用程式也可當作 Web 服務的用戶端，這在網路應用裡極為常見。

Web 服務描述語言 (WSDL) 是說明 Web 服務介面的 XML 格式。Web 服務用戶可動態剖析 WSDL 文件，以判斷 Web 服務所提供的作業以及執行的方式。Application Server 使用其他應用程式可透過 Java API for XML Registries (JAXR) 存取的登錄，以發行 Web 服務介面說明。

用戶端存取

用戶端存取 J2EE 應用程式的方式有幾種。瀏覽器用戶端使用超文字傳輸協定 (HTTP) 存取 Web 應用程式。如需安全通訊，瀏覽器會採用使用安全通訊端層 (SSL) 的 HTTP 安全 (HTTPS) 通訊協定。

在應用程式用戶端容器中執行的豐富型用戶端應用程式，可使用 Object Request Broker (ORB)、遠端方法呼叫 (RMI) 與網際網路 ORB 交換協定 (IIOP)，或 IIOP/SSL (安全 IIOP)，直接查找及存取 Enterprise JavaBeans。它們可使用 HTTP/HTTPS、JMS 與 JAX-RPC 存取應用程式與 Web 服務，還可使用 JMS 將訊息傳送至應用程式與訊息驅動 Bean，並從之接收訊息。

符合 Web 服務互通性 (WS-I) 基本設定檔的用戶端，可存取 J2EE Web 服務。WS-I 是 J2EE 標準不可或缺的一部分，用於定義可互通的 Web 服務。它可讓使用任何支援語言編寫的用戶端，存取部署到 Application Server 上的 Web 服務。

最佳的存取機制視特定應用程式與預期流量而定。Application Server 支援可個別配置的 HTTP、HTTPS、JMS、IIOP 與 IIOP/SSL 偵聽程式。您可以為每個通訊協定設定多個偵聽程式，以增加延展性與穩定性。

J2EE 應用程式也可視作 J2EE 元件的用戶端 (例如部署在其他伺服器上的 Enterprise JavaBeans 模組)，且可使用任何一種存取機制。

外部系統與資源

在 J2EE 平台上，外部系統稱為資源。例如，資料庫管理系統是 JDBC 資源。每個資源是獨一無二的，並由 Java Naming and Directory Interface (JNDI) 名稱識別。應用程式透過下列 API 與元件，存取外部系統：

Application Server 元件

本節說明 Sun Java System Application Server 中的元件：

下圖描述這些 Application Server 元件如何使用提供高可用性的簡易拓樸範例進行互動。在此拓樸範例中，一位管理員管理兩部組織為叢集的機器。HADB 與 Application Server 程序位於相同的機器上。Domain Administration Server 可能在另一台機器上由本身代管，或在任何一部代管應用程式伺服器實例的機器上。圖中的線條表示通訊或控制。

瀏覽器型的管理主控台等管理工具會與 Domain Administration Server (DAS) 通訊，再由其與節點代理程式和伺服器實例通訊。

伺服器實例

伺服器實例是在單一 Java 虛擬機器 (JVM) 程序中執行的 Application Server。Application Server 經 Java 2 Standard Edition (J2SE) 5.0 與 1.4 認證。建議的 J2SE 發行軟體隨附於 Application Server 安裝中。

由於 Application Server 與伴隨的 JVM 皆設計為可擴充為多顆處理器，因此在一部機器上建立一個伺服器實例通常已足夠。但是，在一部機器上建立多個實例有助於應用程式隔離與輪替升級。在某些情況下，具有多項實例的大型伺服器可用在管理網域以外的地方。管理工具可簡化在多部機器之間建立、刪除及管理伺服器實例的作業。

管理網域

管理網域 (或簡稱網域) 是一組共同管理的伺服器實例。伺服器實例屬於單一管理網域。網域中的實例可於不同實體主機上執行。

您可以從一個 Application Server 安裝建立多個網域。不同的組織和管理員可將所有伺服器實例分組為個別的網域，以共用單一的 Application Server 安裝。每個網域都有自己的獨立於其他網域的配置、記錄檔和應用程式部署區域。變更一個網域的配置並不會影響其他網域的配置。同理，在一個網域上部署應用程式，並不會將其部署至其他網域或使其顯示於其他網域中。管理員無論何時都只能向一個網域認證，因而僅能執行該網域的管理作業。

Domain Administration Server (DAS)

網域具有一個 Domain Administration Server (DAS)，此為特別指定用於代管管理應用程式的應用程式伺服器實例。DAS 將認證管理員、接受來自管理工具的請求，並與網域中的伺服器實例進行通訊以執行請求。

管理工具包含 asadmin 指令行工具與瀏覽器型的管理主控台。Application Server 也提供 JMX 型的 API 以進行伺服器管理。管理員一次可檢視並管理一個網域，從而強制執行安全隔離。

DAS 有時也稱為管理伺服器或預設伺服器。稱為預設伺服器是因為它是某些管理作業的預設目標。

由於 DAS 是應用程式伺服器實例，因此也可因測試目的而代管 J2EE 應用程式。但是，請勿用於代管生產應用程式。例如，若尚未建立將代管生產應用程式的叢集與實例，最好將應用程式部署至 DAS。

DAS 會保留一個儲存庫，內含網域與所有已部署的應用程式配置。若 DAS 停用或關機，不會影響使用中的伺服器實例之效能或可用性，但會無法進行管理變更。在某些情況下，基於安全的考量，刻意停止 DAS 程序相當有助益；例如可用於固定生產環境的配置。

管理指令的功能是備份與復原網域配置與應用程式。透過標準備份與復原程序，您可以快速復原有效配置。若 DAS 主機故障，您必須建立新的 DAS 安裝以復原先前的網域配置。如需相關指示，請參閱「Sun Java System Application Server 9.1 管理指南」中的「重新建立網域管理伺服器」。

Sun Cluster Data Services 透過容錯移轉 DAS 主機 IP 位址及使用全域檔案系統，提供高可用性的 DAS。 此解決方案在面對許多失敗類型時，幾乎可不間斷地使用 DAS 與儲存庫。Sun Cluster Data Services 隨附於 Sun Java Enterprise System 中，或隨 Sun Cluster 另外購買。如需更多資訊，請參閱 Sun Cluster Data Services 的文件。

叢集

叢集是共用相同的應用程式、資源與配置資訊之已命名的伺服器實例集合。可以將不同機器上的伺服器實例分組為一個邏輯叢集，然後將其做為一個單位來管理。可以使用 DAS 輕鬆控制多機器叢集的生命週期。

叢集可啟用水平可延伸性、負載平衡和容錯移轉保護。根據定義，叢集中的所有實例均具有相同的資源和應用程式配置。叢集中的伺服器實例或機器故障時，負載平衡器會偵測到該故障，並將通訊從出現故障的實例重新導向至叢集中的其他實例，然後回復使用者階段作業狀態。因為相同應用程式和資源均位於叢集中的所有實例上，因此實例可以容錯移轉至叢集中的任何其他實例。

叢集、網域和實例的相互關係如下：

節點代理程式

節點代理程式是在每部代管伺服器實例的機器上執行的簡易程序，包括代管 DAS 的機器。節點代理程式：

每個實體主機必須為其所屬的每個網域設定至少一個節點代理程式。若實體主機有來自多個網域的實例，則該實例需要在每個網域各有一個節點代理程式。雖然可以在主機上為每個網域設定多個節點代理程式，但這樣做並沒有好處。

因為伺服器實例由節點代理程式啟動與停止，所以節點代理程式必須一直執行。因此，它會隨著作業系統啟動時啟動。在 Solaris 與其他 Unix 平台上，節點代理程式可由 inetd 程序啟動。在 Windows 上，節點代理程式可設定為 Windows 服務。

如需有關節點代理程式的更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 8 章「配置節點代理程式」。

已命名的配置

已命名的 配置是封裝 Application Server 特性設定的抽象概念。叢集與獨立伺服器實例會參照已命名的配置取得其特性設定。透過已命名的配置，J2EE 容器的配置與其所在的實體機器無關，僅與 IP 位址、連接埠號碼與堆疊記憶體容量等特定項目相關。使用已命名的配置可使 Application Server 的管理更強大且更具彈性。

若要套用配置變更，只要變更已命名配置的特性設定，所有參照此配置的叢集與獨立實例便會獲得變更。當所有參照皆移除後，才能刪除已命名的配置。一個網域可包含多個已命名的配置。

Application Server 隨附預設配置，稱為 default-config。預設配置已針對 Application Server Platform Edition 中的開發人員生產力，以及 Application Server Enterprise Edition 中的安全性與高可用性進行最佳化。

您可以根據可因自己的用途進行自訂之預設配置，建立自己命名的配置。使用管理主控台與 asadmin 指令行公用程式，建立及管理已命名的配置。

HTTP 負載平衡器外掛程式

負載平衡器會將工作負荷量分散至多部實體機器，因而增加系統的整體流量。Application Server Enterprise Edition 包含 Sun Java System Web Server、Apache Web Server 與 Microsoft Internet Information Server 的負載平衡器外掛程式。

負載平衡器外掛程式會接受 HTTP 與 HTTPS 請求，然後將這些請求轉寄至叢集中的其中一個應用程式伺服器實例。若實例出現故障而無法使用 (因為網路故障) 或無回應，請求會重新導向至現有的可用機器。負載平衡器還可以識別出現故障的實例是否回復，並相應地重新分配負載。

對於簡單且無狀態的應用程式，負載平衡的叢集即已足夠。但是，對於具有階段作業狀態的任務關鍵性應用程式，請將負載平衡叢集與 HADB 配合使用。

若要設定具有負載平衡的系統，除了 Application Server 之外，還必須安裝 Web 伺服器及負載平衡器外掛程式。然後您必須：

參與負載平衡的伺服器實例和叢集具有同質環境。這通常表示伺服器實例參照相同的伺服器配置，可以存取相同的實體資源，並部署相同的應用程式。同質環境確保故障前後，負載平衡器均始終在叢集使用中的實例間平均分配負載。

使用 asadmin 指令行工具建立負載平衡器配置、將叢集與伺服器實例的參照增加至配置、啟用負載平衡器所參照的叢集、啟用應用程式進行負載平衡、選擇性建立運作狀態檢查程式、產生負載平衡器配置檔案，最後將負載平衡器配置檔案複製到 Web 伺服器的 config 目錄。管理員可建立程序檔自動化此整個程序。

如需更詳細的資訊與完整的配置指示，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 5 章「配置 HTTP 負載平衡」。

階段作業持續性

J2EE 應用程式通常具有大量階段作業狀態資料。Web 購物車即為階段作業狀態的經典範例。而且，應用程式可以快取頻繁需要的階段作業物件資料。實際上，幾乎所有需要進行大量使用者互動活動的應用程式均需要維護階段作業狀態。HTTP 階段作業與有狀態的階段作業 Bean (SFSB) 皆具有階段作業狀態資料。

雖然階段作業狀態不如儲存在資料庫中的作業事件狀態重要，但是在伺服器故障期間能保留階段作業狀態，對一般使用者而言很重要。Application Server 提供在儲存庫中儲存 (或保留) 此階段作業狀態的功能。若代管使用者階段作業的應用程式伺服器實例發生故障，可回復階段作業狀態。階段作業可繼續而不會失去資訊。

Application Server 支援下列階段作業持續性存放區類型：

若是記憶體持續性，狀態一律會保留在記憶體中，在失敗後不會存留。若是 HA 持續性，Application Server 會使用 HADB 作為 HTTP 與 SFSB 階段作業的持續性存放區。若是檔案持續性，Application Server 會序列化階段作業物件，並將其儲存在階段作業管理員特性所指定的檔案系統位置。若是 SFSB 且未指定 HA，Application Server 會將狀態資訊儲存在此位置的階段作業存放區子目錄中。

檢查 SFSB 的狀態是否有變更且需要儲存的動作，稱為檢查點檢查。啟用時，檢查點檢查一般會在完成 SFSB 的所有作業事件之後發生，即使作業事件回復亦然。如需有關開發有狀態的階段作業 Bean 之更多資訊，請參閱「Sun Java System Application Server 9.1 Developer’s Guide」中的「Using Session Beans」。如需有關啟用 SFSB 容錯移轉的更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的「有狀態階段作業 Bean 容錯移轉」。

階段作業持續性配置設定除了影響 Application Server 處理的請求數目外，還會影響 HADB 每分鐘接收的請求數目，以及每個請求中的階段作業資訊。

如需有關配置階段作業持續性的更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 9 章「配置高可用性階段作業持續性和容錯移轉」。

叢集中的 IIOP 負載平衡

透過 IIOP 負載平衡，可將 IIOP 用戶端請求分散至不同的伺服器實例或名稱伺服器中。其目的為在整個叢集上平均分散負載，從而提供可延伸性。IIOP 負載平衡在 Sun Java System Application 中結合 EJB 叢集與可用性功能，不僅提供負載平衡，還提供 EJB 容錯移轉。

當用戶端執行 JNDI 物件查找時，命名服務會建立與特定伺服器實例相關聯的 InitialContext (IC) 物件。從那時起，使用該 IC 物件進行的所有查找請求均會傳送至相同的伺服器實例。使用該 InitialContext 查找的所有 EJBHome 物件均會在相同的目標伺服器上託管。之後取得的所有 Bean 參照也會建立在相同的目標主機上。由於建立 InitialContext 物件時，所有用戶端會隨機建立即時目標伺服器的清單，因此，此作業可有效地提供負載平衡。如果目標伺服器實例當機，則查找或 EJB 方法呼叫將容錯移轉至其他伺服器實例。

例如，如此圖所述，ic1、ic2 與 ic3 是使用 Client2 的程式碼所建立的三個不同的 InitialContext 實例。這些實例會發行至叢集中的三個伺服器實例。接著，此用戶端所建立的 Enterprise JavaBeans 會分配至此三個實例。Client1 僅建立一個 InitialContext 物件，且來自此用戶端的 Bean 參照僅會在伺服器實例 1 上。若伺服器實例 2 當機，ic2 上的查找請求會容錯移轉至其他伺服器實例 (不一定是伺服器實例 3)。任何對伺服器實例 2 上先前代管之 Bean 的 Bean 方法呼叫，也會在安全無虞的前提下自動重新導向至其他實例 。當查找容錯移轉自動化時，Enterprise JavaBeans 模組僅會在安全無虞的前提下重試方法呼叫。

IIOP 負載平衡與容錯移轉不需設定即可執行。在部署應用程式期間，無需特殊的步驟。對叢集增加新實例或從叢集中刪除實例，將不會更新該叢集的現有用戶端檢視。您必須在用戶端手動更新端點清單。

Message Queue 與 JMS 資源

Sun Java System Message Queue (MQ) 提供可靠且非同步的分散式應用程式訊息傳送。MQ 是實作 Java Message Service (JMS) 標準的企業訊息傳送系統。MQ 提供 J2EE 應用程式元件的訊息傳送，例如訊息驅動 Bean (MDB)。

Application Server 將 Sun Java System Message Queue 整合至 Application Server，以實作 Java Message Service (JMS) API。Application Server Enterprise Edition 包含 MQ 的企業版，該版具有容錯移轉、叢集與負載平衡等功能。

對於基本 JMS 管理作業，請使用 Application Server 管理主控台與 asadmin 指令行公用程式。

對於進階作業 (包含管理 Message Queue 叢集)，請使用 install_dir/imq/bin 目錄中所提供的工具。如需有關管理 Message Queue 的詳細資訊，請參閱「Sun Java System Message Queue Administration Guide」。

如需有關部署 JMS 應用程式與 MQ 叢集以進行訊息容錯移轉的資訊，請參閱規劃 Message Queue 代理程式部署。

高可用性資料庫

本節論述以下主題︰

簡介

J2EE 應用程式對階段作業持續性的需求先前於階段作業持續性中已有說明。Application Server 使用高可用性資料庫 (HADB) 作為高可用性階段作業存放區。HADB 隨附於 Application Server Enterprise Edition 中，但可在不同的主機上執行部署。HADB 為 HTTP 階段作業與有狀態的階段作業 Bean 資料提供高可用性資料存放區。

此分離性架構的優點包含：

備註 –

我們已針對 Application Server 用途最佳化 HADB，HADB 不適合讓應用程式當作一般用途的資料庫。

如需 HADB 硬體與網路系統需求的資訊，請參閱「Sun Java System Application Server 9.1 版本說明」中的「硬體和軟體需求」。如需 HADB 所需的其他系統配置步驟，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 2 章「安裝和設定高可用性資料庫」。

系統需求

HADB 主機的系統需求包含：

如需網路配置需求的資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 2 章「安裝和設定高可用性資料庫」。如需非常高可用性的其他需求，請參閱減少雙重故障的機會。

HADB 架構

HADB 是包含成對節點的分散式系統。節點會分成兩個資料備援單元 (DRU)，每個節點來自每個 DRU 的每對節點，如資料備援單元中所述。

每個節點包含：

可代管一或多個階段作業資料庫的一組 HADB 節點。 每個階段作業資料庫與不同的應用程式伺服器叢集相關聯。刪除叢集也會刪除相關聯的階段作業資料庫。

如需 HADB 硬體需求的資訊，請參閱「Sun Java System Application Server 9.1 版本說明」中的「硬體和軟體需求」。

節點與節點程序

HADB 節點有兩種類型：

每個節點皆有一個父程序和數個子程序。父程序又稱為節點監督員 (NSUP)，由管理代理程式啟動。父程序負責建立子程序並將其保持在執行狀態。

子程序包含：

資料備援單元

如前所述，每個 HADB 實例包含一對 DRU。每個 DRU 與配對中另一個 DRU 有相同數目的使用中節點及備用節點。DRU 中的每個使用中節點在另一個 DRU 中有 鏡像節點。由於鏡像的原因，每個 DRU 會包含完整的資料庫複本。

下圖顯示內含六個節點的 HADB 架構範例：四個使用中節點與兩個備用節點。節點 0 與 1、2 與 3 是鏡像組。在此範例中，每個主機有一個節點。一般來說，若主機有足夠的系統資源，便可有多個節點 (請參閱系統需求)。

備註 –

您必須增加代管成對 HADB 節點的機器，每個 DRU 中有一部機器。

HADB 透過複製資料與服務可達成高可用性。鏡像節點上的資料複本會指定為主要複本與緊急待命複本。主要複本會執行插入、刪除、更新與讀取等作業。緊急待命複本會接收主要複本作業的記錄，並在作業事件存留時間內加以重做。僅有主要節點可執行讀取作業，因此不會記錄。每個節點皆包含主要複本與緊急待命複本，並扮演這兩個角色。資料庫會分段並分散至 DRU 中的使用中節點。鏡像組中的各節點包含相同的一組資料片段。複製鏡像節點中的資料稱為複製。複製可讓 HADB 提供高可用性：當節點故障時，鏡像節點幾乎會立即接管 (幾秒內)。複製可確保可用性並使人無法察覺節點故障或 DRU 故障，而不致失去資料或無法提供服務。

當鏡像節點接管故障節點的功能時，必須執行雙份工作：也就是自己的工作以及故障節點的工作。若鏡像節點的資源不足，超載情況會降低節點的效能並增加節點故障的可能性。當節點故障時，HADB 會嘗試重新啟動節點。若故障的節點無法重新啟動 (例如由於硬體故障)，系統會繼續運作但可用性會降低。

HADB 可容許一個節點、整個 DRU 或多個節點故障，但無法容許節點與鏡像節點同時故障的「雙重故障」。如需有關如何降低雙重故障可能性的資訊，請參閱減少雙重故障的機會。

備用節點

當節點故障時，其鏡像節點會接管故障的節點。若故障的節點沒有備用節點，則此時故障的節點將無鏡像節點。備用節點會自動取代故障節點的鏡像節點。擁有備用節點可降低系統沒有鏡像節點的運作時間。

備用節點一般不含資料，但會不斷監視 DRU 中使用中節點是否故障。當節點故障且在指定逾時期間未回復時，備用節點會從鏡像節點複製資料並與之同步化。所需的時間視複製的資料量及系統與網路能力而定。進行同步化之後，備用節點會無須手動介入而自動取代鏡像節點，從而解除鏡像節點的超載情況，而平衡鏡像節點的負載。這又稱為故障回復或自我修復。

修復故障的主機 (透過更換硬體或升級軟體) 並重新啟動時，由於原始備用節點現在變成使用中，因此在此主機上執行的一或多個節點，會加入系統成為備用節點。

備用節點不是必要項目，但這些節點可讓系統即使在機器故障時，也可維持其服務整體水準。備用節點亦可簡化在代管使用中節點的機器上，執行規劃維護的作業。為每個 DRU 配置一部機器作為備用機器，如此一來，若其中一部機器故障，HADB 系統便可繼續，而不會對效能與可用性造成不良影響。

備註 –

一般來說，請以具有足夠應用程式伺服器實例與 HADB 節點的備用機器，取代無法使用的任何機器。

備用節點配置範例

下列範例說明如何在 HADB 部署中使用備用節點。可能的部署拓樸有兩種：並置，在此拓樸中，HADB 與 Application Server 位於相同的主機上；以及個別層級，在此拓樸中，HADB 與 Application Server 位於不同的主機上。如需有關部署拓樸的更多資訊，請參閱第 3 章, 選取拓樸。

範例：並置配置

在此備用節點配置範例中，假設您有一個內含四部 Sun FireTM V480 伺服器的並置拓樸，其中每部伺服器有一個應用程式伺服器實例與兩個 HADB 資料節點。

請為備用節點額外配置兩部伺服器 (每個 DRU 一部機器)。每個備用機器執行一個應用程式伺服器實例以及兩個備用 HADB 節點。

範例：個別層級配置

假設您有一個個別層級的拓樸，其中 HADB 層有兩部 Sun FireTM 280R 伺服器，每部伺服器執行兩個 HADB 資料節點。若要在即使一部機器無法使用的情況下，維持此系統的完整能力，請為應用程式伺服器實例層與 HADB 層各配置一部備用機器。

應用程式伺服器實例層的備用機器，必須和應用程式伺服器實例層中其他機器有相同數目的實例。同理，HADB 層的備用機器，必須和 HADB 層中其他機器有相同數目的 HADB 節點。

減少雙重故障的機會

HADB 的內建資料複製可容許單一節點或整個 DRU 故障。依預設，當鏡像節點組或兩個 DRU 皆故障時，HADB 無法承受此雙重故障。在這類情況下，將無法使用HADB。

除了如上節所述使用備用節點外，還可以採取下列步驟降低雙重故障的可能性：

這些步驟為選用步驟，但會增加 HADB 實例的整體可用性。

HADB 管理系統

HADB 管理系統提供內建安全性並協助多平台的管理。如下圖所述，HADB 管理架構包含下列元件：

如圖所示，執行 HADB 服務的每部機器上會執行一個 HADB 管理代理程式。每部機器一般會代管一或多個 HADB 節點。HADB 管理網域類似 Application Server 網域，包含許多機器。一個網域中至少需有兩部機器，資料庫才有容錯能力，且一般來說，機器的數目必須是偶數才可組成 DRU 組。因此，一個網域可包含許多管理代理程式。

如圖所示，一個網域可包含一或多個資料庫實例。一部機器可包含一或多個屬於一或多個資料庫實例的節點。

管理用戶端

HADB 管理用戶端是指令行公用程式 hadbm，用於管理 HADB 網域及其資料庫實例。HADB 服務可持續執行 (即使相關聯的應用程式伺服器叢集停止亦然)，但如果要刪除，則必須小心關閉。如需有關使用 hadbm 的更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 3 章「管理高可用性資料庫」。

您可以使用 asadmin 指令行公用程式建立及刪除與高可用性叢集相關聯的 HADB 實例。如需更多資訊，請參閱「Sun Java System Application Server 9.1 高可用性管理指南」中的第 9 章「配置高可用性階段作業持續性和容錯移轉」。

管理代理程式

管理代理程式是伺服器程序 (名為 ma)，可存取主機上的資源；例如，它可建立裝置並啟動資料庫程序。管理代理程式會協調及執行管理用戶端指令，例如啟動或停止資料庫實例。

管理用戶端透過指定代理程式的位址與連接埠號碼，連線至管理代理程式。連線之後，管理用戶端就會透過管理代理程式將指令傳送至 HADB。代理程式接收到請求後會加以執行。因此，管理代理程式必須執行於主機上，才可對該主機發出任何 hadbm 管理指令。您可將管理代理程式配置為自動啟動的系統服務。

確保管理代理程式的可用性

管理代理程式程序可在 HADB 節點監督員程序失敗時將其重新啟動，從而確保 HADB 節點監督員程序的可用性。因此，對於部署，您必須確保 ma 程序的可用性，才可維持 HADB 的整體可用性。重新啟動後，管理代理程式會從系統網域的其他代理程式，回復網域與資料庫配置資料。

使用主機作業系統 (OS) 以確保管理代理程式的可用性。在 Solaris 或 Linux 上，init.d 可確保 ma 程序在程序失敗並重新啟動作業系統之後的可用性。在 Windows 上，管理代理程式會以 Windows 服務執行。因此，若代理程式故障或作業系統重新啟動，作業系統便會重新啟動管理代理程式。

管理網域

HADB 管理網域是一組主機，每個主機有在相同連接埠號碼上執行的管理代理程式。網域中的主機可包含一或多個 HADB 資料庫實例。定義管理網域的方法，是依據代理程式所使用的共用連接埠號碼，以及建立網域或增加代理程式至網域時所產生的識別碼 (稱為 domainkey)。domainkey 提供唯一的網域識別碼，這點極為重要，因為管理代理程式使用多重播送進行通訊。您可以設定 HADB 管理網域對應 Application Server 網域。

在一個網域中有多個資料庫實例有助於開發環境，因為如此可讓不同的開發人員群組使用自己的資料庫實例。在某些情況下，也有助於生產環境。

屬於同一個網域的所有代理程式會協調其管理作業。當您透過 hadbm 指令變更資料庫配置時，所有代理程式會隨之變更配置。除非節點的主機上有執行的管理代理程式，否則您無法停止或重新啟動節點。但是，您可以在無法使用某些代理程式的情況下執行 hadbm 指令，以讀取 HADB 狀態或配置變數值。

使用下列管理用戶端指令處理管理網域：

儲存庫

管理代理程式會將資料庫配置儲存在儲存庫。由於儲存庫會在所有管理代理程式之間進行複製，因此容錯能力很高。將配置保留在伺服器上，可讓您從任何安裝管理用戶端的電腦上執行管理作業。

必須執行網域中的大部分管理代理程式，才可對儲存庫進行任何變更。因此，若網域中有 M 個代理程式，至少必須執行 M/2 + 1 個代理程式 (無條件捨去到整數)，才可對儲存庫進行變更。

若網域中有些主機無法使用 (例如由於硬體故障)，且您因為沒有配額而無法執行某些管理指令，請使用 hadbm disablehost 指令從網域移除故障的主機。

設定及配置資訊指南

Procedure設定及配置高可用性的 Application Server

  1. 如第 1 章, 產品概念中所述，決定效能及 QoS 需求與目標。

  2. 如第 1 章, 產品概念的設計決策中所述，調整系統大小。

    • 應用程式伺服器實例的數目

    • HADB 節點與主機的數目

    • HADB 儲存容量

  3. 如第 3 章, 選取拓樸中所述，決定系統拓樸。

    如此會決定您要在與 Application Server 相同或不同的主機機器上安裝 HADB。

  4. 安裝應用程式伺服器實例以及相關子元件，例如 HADB 與 Web 伺服器。

  5. 建立網域與叢集。

  6. 配置 Web 伺服器軟體。

  7. 安裝負載平衡器外掛程式。

  8. 設定並配置負載平衡。

  9. 設定並配置 HADB 節點與 DRU。

  10. 為 HA 階段作業持續性配置 AS Web 容器與 EJB 容器。

  11. 為高可用性與階段作業容錯移轉部署並配置應用程式。

  12. 如果廣泛使用訊息傳送，請配置 JMS 叢集進行容錯移轉。

    如需更多資訊，請參閱「Sun Java System Message Queue Adminstration Guide」。