test

Sun Java System Application Server Enterprise Edition 8.2 高可用性管理指南

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

本章說明 Sun Java SystemApplication Server Enterprise Edition 中的高可用性功能，包含以下主題：

高可用性簡介

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

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

高可用性階段作業持續性

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

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

對於一般使用者而言，在伺服器故障時保留階段作業狀態是很重要的。為了取得高可用性，Application Server 提供在 HADB 中持續階段作業狀態的功能。如果託管使用者階段作業的 Application Server 實例出現故障，階段作業狀態是可以回復的，且階段作業可以繼續而無資訊遺失。

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

高可用性 Java 訊息服務

Java 訊息服務 (JMS) API 是一種允許 J2EE 應用程式和元件建立、傳送、接收以及讀取郵件的郵件傳送標準。它可啟用可靠的非同步鬆耦合分散式通訊。實作 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 叢集與 Application Server 配合使用。

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

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

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

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

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

更多資訊

如需有關規劃高可用性部署 (包括評估硬體需求、規劃網路配置和選取拓樸) 的資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 Deployment Planning Guide」。此手冊還提供以下概念的高階簡介：

如需有關開發應用程式以運用高可用性功能優點的更多資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide」。

如需有關如何配置和調校應用程式及應用程式伺服器以取得高可用性最佳效能的資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide」，本書說明以下主題：

應用程式伺服器如何提供高可用性

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

負載平衡外掛程式

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

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

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

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

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

高可用性資料庫

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

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

如需有關規劃和設定應用程式伺服器安裝，以透過 HADB 實現高可用性 (包括決定硬體配置、調整大小和拓樸) 的資訊，請參閱「Sun Java System Application Server Enterprise Edition 8.2 Deployment Planning Guide」中的「Planning for Availability」和「Sun Java System Application Server Enterprise Edition 8.2 Deployment Planning Guide」中的第 3 章「Selecting a Topology」。

高可用性叢集

叢集是 Application Server 實例集合，這些實例共同做為一個邏輯實體工作。叢集為一個或多個 J2EE 應用程式提供了執行階段環境。高可用性叢集將狀態複製服務與叢集和負載平衡器整合。

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

叢集中的所有實例：

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

叢集和配置

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

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

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

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

因此，對於叢集中的伺服器實例，叢集充當的是階段作業容錯移轉的安全邊界。在 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：

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

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

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

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

  1. 在該機器上安裝應用程式伺服器節點代理程式位元。

  2. 請參閱 AS8.1 UR2 修補程式 4 安裝指示。

  3. 重新建立節點代理程式。您不需要建立任何伺服器實例。

  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 的備份。使用 asadmin backup-domain 來備份目前網域。

Procedure遷移網域管理伺服器

若要將 DAS 從第一台機器 (machine1) 遷移至第三台機器 (machine3)，請遵循下列步驟：

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

    為了可以在第三台機器上正確地復原 DAS 並且不會發生路徑衝突，您必須執行此操作。

    1. 使用指令行 (互動) 模式來安裝應用程式伺服器管理套裝軟體。

      若要啟動指令行互動模式，請使用 console 選項呼叫安裝程式：


      ./bundle-filename -console

      若要使用指令行介面進行安裝，您必須具有 root 許可權。

    2. 若要安裝預設網域，請取消選取該選項。

      只有具有相同架構且安裝路徑完全相同 (即兩台機器使用相同的 install-dir 和 domain-root-dir) 的兩台機器，才支援復原備份的網域。

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

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

  3. 執行 asadmin restore-domain 指令，以將 ZIP 檔案復原到第三台機器：


    asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip domain1

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

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

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

    例如︰

    chmod 700 domain-root-dir/domain1/generated/tmp

    以上範例假定您備份的是 domain1。如果備份的是其他名稱的網域，則應使用要備份網域的名稱取代上述的 domain1。

  5. 變更第三台機器的 domain.xml 檔案中的主機特性值：

  6. 更新第三台機器上的 domain-root-dir/domain1/config/domain.xml。

    例如，搜尋 machine1 並將其替代為 machine3。這樣，您就可以將：

    <jmx-connector><property name=client-hostname value=machine1/>...

    變更為：

    <jmx-connector><property name=client-hostname value=machine3/>...

  7. 將：

    <jms-service... host=machine1.../>

    變更為：

    <jms-service... host=machine3.../>

  8. 在 machine3 上啟動復原的網域：


    asadmin start-domain --user admin-user --password admin-password domain1

  9. 在 machine2 上變更節點代理程式下的 DAS 主機特性值。

  10. 在 machine2 上變更 install-dir/nodeagents/nodeagent/agent/config/das.properties 中的 agent.das.host 特性值。

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

    備註 –

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