Sun Java System Application Server 9.1 高可用性管理指南

第 1 章應用程式伺服器的高可用性

本章說明叢集設定檔及企業設定檔提供的 Sun Java System Application Server 高可用性功能。

備註 –

Sun Java System Application Server 的 Application Server 獨立發行版本隨附了 HADB 軟體。如需有關 Sun Java System Application Server 的可用發行軟體資訊，請參閱「Sun Java System Application Server 9.1 Installation Guide」中的「Distribution Types and Their Components」。只有企業設定檔才提供 HADB 功能。如需有關設定檔的更多資訊，請參閱「Sun Java System Application Server 9.1 管理指南」中的「用法設定檔」。

本章包含以下主題。

高可用性簡介

高可用性應用程式和服務可持續提供其功能，而不考量硬體和軟體故障。這類應用程式有時亦稱為提供五個九的可靠性，因為開發這類產品的目的就是在 99.999% 的時間內都能供人使用。

Application Server 提供下列高可用性功能：

高可用性階段作業持續性
高可用性 Java 訊息服務
RMI-IIOP 負載平衡和容錯移轉

高可用性階段作業持續性

Application Server 可為 HTTP 請求和階段作業資料 (HTTP 階段作業資料和有狀態階段作業 Bean 資料) 提供高可用性。

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

對於一般使用者而言，在伺服器故障時保留階段作業狀態是很重要的。為了提供高可用性功能，Application Server 為階段作業狀態資料提供下列類型的儲存方式：

叢集內其他伺服器上的記憶體中複製
高可用性資料庫 (HADB)

如果主控使用者階段作業的 Application Server 實例故障，則可回復階段作業狀態，且階段作業可以繼續而無資訊遺失。

如需有關如何設定高可用性階段作業持續性的詳細說明，請參閱第 9 章, 配置高可用性階段作業持續性和容錯移轉。

高可用性 Java 訊息服務

Java 訊息服務 (JMS) API 是一種允許 Java EE 應用程式和元件建立、傳送、接收以及讀取郵件的郵件傳送標準。它可啟用可靠的非同步鬆耦合分散式通訊。實作 JMS 的 Sun Java System Message Queue (MQ) 與 Application Server 緊密整合在一起，可讓您建立諸如訊息驅動 Bean (MDB) 之類依賴 JMS 的元件。

JMS 透過連線池儲存和容錯移轉及 MQ 叢集來提供高可用性功能。如需更多資訊，請參閱第 10 章, Java 訊息服務的負載平衡和容錯移轉。

連線池儲存和容錯移轉

Application Server 支援 JMS 連線池儲存和容錯移轉。Application Server 可自動將 JMS 連線儲存在池中。依預設，Application Server 會從指定的主機清單中隨機選取其主要的 MQ 代理程式。發生容錯移轉時，MQ 不需設定即可將負載傳輸至其他代理程式並可保持 JMS 語義不變。

如需有關 JMS 連線池儲存和容錯移轉的更多資訊，請參閱連線池儲存和容錯移轉。

MQ 叢集

MQ Enterprise Edition 支援多個互連的代理程式實例 (稱為代理程式叢集)。對於代理程式叢集，用戶端連線會分散至叢集中的所有代理程式。叢集可提供水平可延伸性並可提高可用性。

如需有關 MQ 叢集的更多資訊，請參閱將 MQ 叢集與應用程式伺服器配合使用。

RMI-IIOP 負載平衡和容錯移轉

使用 RMI-IIOP 負載平衡時，IIOP 用戶端請求會分散至不同的伺服器實例或名稱伺服器，以便在叢集內平均分散負載，因而提高延伸性。結合了 EJB 叢集和可用性的 IIOP 負載平衡還可提供 EJB 容錯移轉。

當用戶端以 JNDI 查找物件時，命名服務會將請求連結到特定的伺服器實例。從這時開始，來自該用戶端的所有查找請求都會傳送至同一伺服器實例，因此所有 EJBHome 物件都會放在相同的目標伺服器上。之後取得的所有 Bean 參照也會建立在相同的目標主機上。這可以提供有效的負載平衡，因為所有用戶端在執行 JNDI 查找時，都會隨機製作目標伺服器清單。如果目標伺服器實例當機，則查詢或 EJB 方法呼叫將容錯移轉至其他伺服器實例。

IIOP 負載平衡與容錯移轉不需設定即可執行。在部署應用程式期間，無需特殊的步驟。如果部署應用程式用戶端的 Application Server 實例加入叢集，則此 Application Server 會自動在叢集中尋找目前所有使用中的 IIOP 端點。不過，用戶端至少應該為啟動程序指定兩個端點，以便在一個端點故障時使用另外一個端點。

如需有關 RMI-IIOP 負載平衡和容錯移轉的更多資訊，請參閱第 11 章, RMI-IIOP 負載平衡和容錯移轉。

Application Server 如何提供高可用性

Application Server 經由以下子元件和功能提供高可用性：

負載平衡外掛程式

負載平衡外掛程式接受 HTTP / HTTPS 請求，然後將這些請求轉寄至叢集中的 Application Server 實例。如果實例出現故障，變得不可用 (因為網路故障) 或無回應，負載平衡器即會將請求重新導向至現有的可用機器。負載平衡器還可以識別出現故障的實例是否回復，並相應地重新分配負載。Application Server 為 Sun Java System Web Server、Apache Web Server 和 Microsoft Internet Information Server 提供了負載平衡器外掛程式。

透過在多台實體機器間分配工作負荷量，負載平衡器會提昇整體系統流量。負載平衡器還透過 HTTP 請求的容錯移轉提供更高的可用性。若要使 HTTP 階段作業資訊具有持續性，必須配置HTTP 階段作業持續性。

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

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

如需有關配置負載平衡和容錯移轉的資訊，請參閱第 5 章, 配置 HTTP 負載平衡

階段作業狀態資料的儲存方式

儲存階段作業狀態資料後，即可在叢集的伺服器實例容錯移轉後回復階段作業狀態。回復階段作業狀態可繼續執行階段作業而不會遺失資訊。Application Server 為 HTTP 階段作業及有狀態的階段作業 Bean 資料提供了下列類型的高可用性儲存裝置：

叢集內其他伺服器上的記憶體中複製
高可用性資料庫

叢集內其他伺服器上的記憶體中複製

其他伺服器上的記憶體中複製可讓您輕鬆儲存階段作業狀態資料，而無需取得獨立的資料庫，例如 HADB。此類複製使用了其他伺器上的記憶體，為 HTTP 階段作業及有狀態的階段作業 Bean 資料提供高可用性的儲存裝置。叢集伺服器實例可複製環狀拓樸的階段作業狀態。每個備份實例會在記憶體中儲存複製的資料。在其他伺服器的記憶體中複製階段作業狀態資料，即可分配階段作業。

如需使用記憶體中複製功能，需要啟用群組管理服務 (GMS)。如需有關 GMS 的更多資訊，請參閱群組管理服務。

如果叢集中的各伺服器實例位於不同機器上，請確定符合下列必要條件：

為了確保 GMS 和記憶體中複寫均能正確運作，各機器必須位於相同的子網路。
為了確保記憶體中複製正確運作，必須儘可能使叢集中所有機器的系統時鐘同步。

高可用性資料庫

備註 –

Application Server 提供高可用性資料庫 (HADB)，用於為 HTTP 階段作業和有狀態的階段作業 Bean 資料提供高可用性儲存機制。HADB 旨在使用負載平衡、容錯移轉和狀態回復功能，支援高達 99.999% 的服務和資料可用性。通常必須獨立於應用程式伺服器來配置和管理 HADB。

Application Server 不負責管理狀態的好處極多。Application Server 實例的所有時間都在充當可延伸的高效能應用程式容器，將狀態複製工作委託給外部高可用性狀態服務。由於採用此鬆耦合架構，因此可以非常輕鬆地將 Application Server 實例增加至叢集或從叢集中刪除。HADB 狀態複製服務可以獨立延伸，以取得最佳可用性和效能。如果 Application Server 實例還執行複製，Java EE 應用程式的效能可能會降低，並且資源回收暫停時間也可能會變長。

如需有關規劃和設定 Application Server 安裝，以透過 HADB 實現高可用性 (包括決定硬體配置、調整大小和拓樸) 的資訊，請參閱「Sun Java System Application Server 9.1 部署規劃指南」中的「Planning for Availability」和「Sun Java System Application Server 9.1 部署規劃指南」中的第 3 章「選取拓樸」。

高可用性叢集

叢集是 Application Server 實例集合，以一個邏輯實體形式一起運作。叢集為一個或多個 Java EE 應用程式提供了執行階段環境。高可用性叢集將狀態複製服務與叢集和負載平衡器整合。

使用叢集可提供以下優勢：

高可用性 (透過允許為叢集中的伺服器實例提供容錯移轉保護來實現)。如果一個伺服器實例當機，其他伺服器實例將接管該伺服器實例正在服務的請求。
可延伸性 (透過允許向叢集中增加伺服器實例，從而增加系統的容量來實現)。負載平衡器外掛程式會將請求分散到叢集中的可用伺服器實例。當管理員向叢集中新增更多伺服器實例時，無需中斷服務。

叢集中的所有實例：

參照相同的配置。
具有相同的已部署應用程式集 (例如，Java EE 應用程式 EAR 檔案、Web 模組 WAR 檔案或 EJB JAR 檔案)。
具有相同的資源集，從而產生相同的 JNDI 名稱空間。

網域中的每一個叢集都具有唯一的名稱；此外，該名稱與所有節點代理程式名稱、伺服器實例名稱、叢集名稱和配置名稱都不重複。此名稱不能為 domain。您在叢集上執行的作業與在非叢集伺服器實例上執行之作業相同 (例如，部署應用程式和建立資源)。

叢集和配置

叢集的設定取自已命名的配置 (可能能夠與其他叢集共用)。不與其他伺服器實例或叢集共用配置的叢集稱之為具有獨立配置。依預設，此配置的名稱為 cluster_name -config，其中，cluster_name 為叢集的名稱。

與其他叢集或實例共用配置的叢集稱之為具有共用配置。

叢集、實例、階段作業和負載平衡

叢集、伺服器實例、負載平衡器和階段作業的相互關係如下：

伺服器實例不一定是叢集的一部分。但是，不屬於叢集的實例無法通過將階段作業狀態從一個實例傳送到其他實例來利用高可用性。
可以將叢集中的伺服器實例託管在一台或多台機器上。您可以將不同機器上的伺服器實例集合為一個叢集。
特定負載平衡器可以向多個叢集中的伺服器實例轉寄請求。您可以使用負載平衡器的此功能來執行線上升級，而不使服務受到損失。如需更多資訊，請參閱「Configuring Clusters」一章中的「Using Multiple Clusters for Online Upgrades Without Loss of Service」。
單一叢集可以從多個負載平衡器接收請求。如果叢集由多個負載平衡器提供服務，則必須以完全相同的方式在每個負載平衡器上配置叢集。
每個階段作業都與特定的叢集連結在一起。因此，雖然您可以在多個叢集上部署一個應用程式，但階段作業容錯移轉仍僅在一個叢集內發生。

因此，對於叢集中的伺服器實例，叢集可充當階段作業容錯移轉的安全邊界。在 Application Server 中，您可以使用負載平衡器並升級元件，而不會使服務受到任何損失。

故障後回復

使用 Sun Cluster

Sun Cluster 可為網域管理伺服器、節點代理程式、Application Server 實例、訊息佇列及 HADB 提供自動化的容錯移轉。如需更多資訊，請參閱「Sun Cluster Data Service for Sun Java System Application Server Guide for Solaris OS」。

使用標準乙太網路互連及部分的 Sun Cluster 產品。Java ES 包含這項功能。

手動回復

您可以使用各種技術手動回復個別子元件：

回復網域管理伺服器

失去網域管理伺服器 (DAS) 只會影響到管理作業。即使無法連線至 DAS，Application Server 叢集和應用程式仍會如常地繼續運作。

可用下列任意方法回復 DAS：

定期執行 asadmin 備份指令就能取得定期快照。於發生硬體故障之後，在擁有相同網路識別的新機器上安裝應用程式伺服器並執行 asadmin，以從先前建立的備份進行復原。如需更多資訊，請參閱重新建立網域管理伺服器。
將網域安裝和配置放在共用且牢固的檔案系統上 (例如 NFS)。若主要 DAS 機器故障，擁有相同 IP 位址的第二部機器就會啟動，並以手動操作或使用者提供的自動化程序接手運作。Sun Cluster 採用類似的方式讓 DAS 有容錯移轉功能。
壓縮 Application Server 安裝及網域根目錄。將壓縮檔復原到新機器上，並為其指定相同的網路識別。如果您是採用檔案型的安裝，這可能是最簡單的做法。
以 DAS 備份進行復原。請參閱 AS8.1 UR2 修補程式 4 指示。

回復節點代理程式和伺服器實例

節點代理程式和伺服器實例有兩種回復方式。

保存備份壓縮檔案。目前沒有針對節點代理程式和伺服器實例提供專屬的備份指令。只要建立一個壓縮檔，其中包含節點代理程式目錄的內容即可。發生故障之後，可將儲存的備份解壓縮至擁有相同主機名稱和 IP 位址的新機器上，並且使用相同的安裝目錄位置、作業系統等等。該機器上必須擁有檔案型安裝、套裝軟體型安裝或復原的備份影像。

手動回復。使用的新主機必須擁有相同的 IP 位址。

在該機器上安裝 Application Server 節點代理程式位元。
請參閱 AS8.1 UR2 修補程式 4 安裝指示。
重新建立節點代理程式。您不需要建立任何伺服器實例。
同步化處理會從 DAS 複製配置及資料，並做更新。

回復負載平衡器及 Web 伺服器

目前沒有單獨針對 Web 伺服器配置提供專屬備份指令。只要壓縮 Web 伺服器安裝目錄即可。發生故障之後，將儲存的備份解壓縮至擁有相同網路識別的新機器上。若新機器擁有不同的 IP 位址，則更新 DNS 伺服器或路由器。

備註 –

這裡假設您已經事先重新安裝 Web 伺服器或從影像復原 Web 伺服器。

負載平衡器外掛程式 (plugins 目錄) 及配置位於 Web 伺服器安裝目錄中，此目錄通常是 /opt/SUNWwbsvr。web-install/web-instance/config 目錄包含 loadbalancer.xml 檔案。

回復訊息佇列

訊息佇列 (MQ) 配置和資源儲存於 DAS，並且可和實例同步化。任何其他資料和配置資訊則位於 MQ 目錄中，這些目錄通常位於 /var/imq 下，因此請視需求備份及復原這些目錄。新機器上必須已經有 MQ 安裝。復原機器時，務必依常態啟動 MQ 代理程式。

回復 HADB

備註 –

如果您有兩個使用中 HADB 節點，則可以 (在別的機器上) 配置兩個備用節點，以便在發生故障時能夠接手。這種方式比較簡潔，因為備份及復原 HADB 可能會復原到舊的階段作業。

如需有關建立含有備用節點資料庫的資訊，請參閱建立資料庫。如需有關對資料庫增加備援節點的資訊，請參閱增加節點。如果回復及自我修復都失敗，備用節點即會自動接手。

使用 Netbackup

備註 –

Sun QA 尚未測試過此程序。

使用 Veritas Netbackup 儲存每部機器的影像。若是 BPIP，則備份含有 Web 伺服器和應用程式伺服器的四部機器。

每部復原的機器都和原來機器使用相同配置，例如相同的主機名稱、IP 位址等等。

若是如應用程式伺服器之類的檔案型產品，只需備份及復原相關目錄。但是如 Web 伺服器影像之類的套裝軟體型安裝，則必須備份及復原整部機器。套裝軟體會安裝至 Solaris 套裝軟體資料庫。因此，若只備份目錄並於稍後復原至新系統，將會造成套裝軟體資料庫中沒有「已部署」Web 伺服器的資料。這會導致未來無法安裝修補程式或進行升級。

請勿手動複製及復原 Solaris 套裝軟體資料庫。別的可行做法是在安裝如 Web 伺服器之類的元件後，備份機器的影像。此影像稱為基準線 tar 檔案。當您變更 Web 伺服器時，只需備份如 /opt/SUNWwbsvr 下的這些目錄。復原時，先復原基準線 tar 檔案，再覆蓋做過修改的 Web 伺服器目錄。您也同樣可以對 MQ (BPIP 的套裝軟體型安裝) 使用這個程序。如果您在原始機器上進行升級或安裝修補程式，務必要建立新的基準線 tar 檔案。

若包含 DAS 的機器發生故障，在機器復原之前將無法使用 DAS。

DAS 是中央儲存庫。當您復原伺服器實例並重新啟動伺服器實例時，伺服器實例只會和 DAS 中的資訊同步化。因此，所有變更都必須透過 asadmin 或管理主控台執行。

HADB 的每日備份影像不一定可以用，因為這類影像可能包含舊的應用程式階段作業狀態。

重新建立網域管理伺服器

若主控網域管理伺服器 (DAS) 的機器發生故障，且先前已備份 DAS，則可重建 DAS。若要重新建立 DAS 的有效副本，您必須擁有：

一台包含原始 DAS 的機器 (machine1)。
一台包含叢集的機器 (machine2)，該叢集具有執行應用程式並滿足用戶端需要的伺服器實例。該叢集是使用第一台機器上的 DAS 配置的。
一台備份機器 (machine3)，當第一台機器當機時，需要在該備份電腦上重新建立 DAS。

備註 –

必須保留一份第一台機器上的 DAS 的備份。使用 asadmin backup-domain 來備份目前網域。

遷移 DAS

以下步驟用於將 Domain Administration Server 從第一台機器 (machine1) 遷移到第三台機器 (machine3)：

將 Application Server 安裝在第三台機器上，方法與在第一台機器上安裝時相同。

為了可以在第三台機器上正確地復原 DAS 並且不會發生路徑衝突，您必須執行此操作。
1. 使用指令行 (互動) 模式來安裝 Application Server 管理套裝軟體。
  
  若要啟動指令行互動模式，請使用 console 選項呼叫安裝程式：
  ./bundle-filename -console
  若要使用指令行介面進行安裝，您必須具有 root 許可權。
2. 若要安裝預設網域，請取消選取該選項。
  
  兩台機器的架構與安裝路徑完全相同時 (即兩台機器使用相同的 as-install 和 domain-root-dir)，才支援復原備份的網域。

將第一台機器上的備份 ZIP 檔案複製到第三台機器上的 domain-root-dir 目錄中。

也可以透過 FTP 方式複製檔案。

將 ZIP 檔案復原到第三台機器。
asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip --clienthostname machine3 domain1
備註 –
只要指定 --clienthostname 選項，就不需要修改 jmx-connector 元素在 domain.xml 檔案中的 client-hostname 特性。

可以備份任何網域。但是，在重新建立網域時，網域名稱應與原始網域名稱相同。

變更第三台機器上的 domain-root-dir/domain1/generated/tmp 目錄的權限，以與第一台機器上相同目錄的權限相符。

該目錄的預設許可權為：drwx------ (or 700).

例如︰
chmod 700 domain-root-dir/domain1/generated/tmp
以上範例假定您備份的是 domain1。如果備份的是其他名稱的網域，則應使用要備份網域的名稱取代上述的 domain1。

在第三台機器的 domain-root-dir/domain1/config/domain.xml 檔案中，更新 jms-service 元素的 host 屬性值。

以下是此屬性的原始設定：
```
<jms-service... host=machine1.../>
```
依下列方式修改此屬性的設定：
```
<jms-service... host=machine3.../>
```

在 machine3 上啟動復原的網域：
asadmin start-domain --user admin-user --password admin-password domain1
DAS 會連絡所有執行中的節點代理程式，並為節點代理程式提供 DAS 的連絡資訊。節點代理程式會使用此資訊連絡 DAS。

對於重新啟動 DAS 時未執行的任何節點代理程式，請在 machine2 上變更 as-install /nodeagents/nodeagent/agent/config/das.properties 中的 agent.das.host 特性值。

重新啟動 DAS 時，正在執行的節點代理程式不需要執行此步驟。

在 machine2 上重新啟動節點代理程式。

備註 –
使用 asadmin start-instance 指令啟動叢集實例，以使這些實例與復原網域同步。

第 1 章 應用程式伺服器的高可用性

高可用性簡介

高可用性階段作業持續性

高可用性 Java 訊息服務

連線池儲存和容錯移轉

MQ 叢集

RMI-IIOP 負載平衡和容錯移轉

更多資訊

調校高可用性伺服器和應用程式

Application Server 如何提供高可用性

負載平衡外掛程式

階段作業狀態資料的儲存方式

叢集內其他伺服器上的記憶體中複製

高可用性資料庫

高可用性叢集

叢集和配置

叢集、實例、階段作業和負載平衡

故障後回復

使用 Sun Cluster

手動回復

回復網域管理伺服器

回復節點代理程式和伺服器實例

回復負載平衡器及 Web 伺服器

回復訊息佇列

回復 HADB

使用 Netbackup

重新建立網域管理伺服器

遷移 DAS

第 1 章應用程式伺服器的高可用性