本章說明 Sun Java SystemApplication Server Enterprise Edition 中的高可用性功能,包含以下主題:
高可用性應用程式和服務可持續提供其功能,而不考量硬體和軟體故障。這類應用程式有時亦稱為提供五個九的可靠性,因為開發這類產品的目的就是在 99.999% 的時間內都能供人使用。
Application Server 提供下列高可用性功能:
高可用性階段作業持續性
高可用性 Java 訊息服務
RMI-IIOP 負載平衡和容錯移轉
Application Server 可為 HTTP 請求和階段作業資料 (HTTP 階段作業資料和有狀態階段作業 Bean 資料) 提供高可用性。
J2EE 應用程式通常具有大量階段作業狀態資料。Web 購物車即為階段作業狀態的經典範例。而且,應用程式可以快取頻繁需要的階段作業物件資料。實際上,幾乎所有需要進行大量使用者互動活動的應用程式均需要維護階段作業狀態。HTTP 階段作業和有狀態階段作業 Bean (SFSB) 均具有階段作業狀態資料。
對於一般使用者而言,在伺服器故障時保留階段作業狀態是很重要的。為了取得高可用性,Application Server 提供在 HADB 中持續階段作業狀態的功能。如果託管使用者階段作業的 Application Server 實例出現故障,階段作業狀態是可以回復的,且階段作業可以繼續而無資訊遺失。
如需有關如何設定高可用性階段作業持續性的詳細說明,請參閱第 9 章, 配置高可用性階段作業持續性和容錯移轉。
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 Enterprise Edition 支援多個互連的代理程式實例 (稱為代理程式叢集)。對於代理程式叢集,用戶端連線會分散至叢集中的所有代理程式。叢集可提供水平可延伸性並可提高可用性。
如需有關 MQ 叢集的更多資訊,請參閱將 MQ 叢集與 Application Server 配合使用。
使用 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」。此手冊還提供以下概念的高階簡介:
Application Server 元件,例如節點代理程式、網域和叢集
叢集中的 IIOP 負載平衡
HADB 架構
訊息佇列容錯移轉
如需有關開發應用程式以運用高可用性功能優點的更多資訊,請參閱「Sun Java System Application Server Enterprise Edition 8.2 Developer’s Guide」。
如需有關如何配置和調校應用程式及應用程式伺服器以取得高可用性最佳效能的資訊,請參閱「Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide」,本書說明以下主題:
調校持續性頻率和持續性範圍
對有狀態階段作業 Bean 進行檢查點操作
配置 JDBC 連線池
階段作業大小
調校 HADB 磁碟使用、記憶體分配、效能和作業系統配置
配置負載平衡器以取得最佳效能
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 應用程式提供了執行階段環境。高可用性叢集將狀態複製服務與叢集和負載平衡器整合。
使用叢集可提供以下優勢:
高可用性 (透過允許為叢集中的伺服器實例提供容錯移轉保護來實現)。如果一個伺服器實例當機,其他伺服器實例將接管該伺服器實例正在服務的請求。
可延伸性 (透過允許向叢集中增加伺服器實例,從而增加系統的容量來實現)。負載平衡外掛程式將請求分配給叢集中可用的伺服器實例。當管理員向叢集中新增更多伺服器實例時,無需中斷服務。
叢集中的所有實例:
參照相同的配置。
具有相同的已部署應用程式集 (例如,J2EE 應用程式 EAR 檔案、Web 模組 WAR 檔案或 EJB JAR 檔案)。
具有相同的資源集,從而產生相同的 JNDI 名稱空間。
網域中的每一個叢集都具有唯一的名稱;此外,該名稱在所有節點代理程式名稱、伺服器實例名稱、叢集名稱和配置名稱中也必須是唯一的。此名稱不能為 domain。您在叢集上執行的作業 (例如,部署應用程式和建立資源) 與在非叢集伺服器實例上執行之作業相同。
叢集的設定取自已命名的配置 (可能能夠與其他叢集共用)。不與其他伺服器實例或叢集共用配置的叢集稱之為具有獨立配置。依預設,此配置的名稱為 cluster_name -config,其中,cluster_name 為叢集的名稱。
與其他叢集或實例共用配置的叢集稱之為具有共用配置。
叢集、伺服器實例、負載平衡器和階段作業相互關係如下:
伺服器實例不一定是叢集的一部分。但是,不屬於叢集的實例無法通過將階段作業狀態從一個實例傳送到其他實例來利用高可用性。
可以將叢集中的伺服器實例託管在一台或多台機器上。可以將不同機器上的伺服器實例群組為一個叢集。
特定負載平衡器可以向多個叢集中的伺服器實例轉寄請求。您可以使用負載平衡器的此功能來執行線上升級,而不使服務受到損失。如需更多資訊,請參閱升級元件而不會使服務受到損失。
單一叢集可以從多個負載平衡器接收請求。如果叢集由多個負載平衡器提供服務,則必須以完全相同的方式在每個負載平衡器上配置叢集。
每個階段作業都與特定的叢集連結在一起。因此,雖然您可以在多個叢集上部署一個應用程式,但階段作業容錯移轉仍僅在一個叢集內發生。
因此,對於叢集中的伺服器實例,叢集充當的是階段作業容錯移轉的安全邊界。在 Application Server 中,可以使用負載平衡器和升級元件,而不使服務受到任何損失。
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 備份指令就能取得定期快照。於發生硬體故障之後,在擁有相同網路識別的新機器上安裝 Application Server 並執行 asadmin,以從先前建立的備份進行復原。如需更多資訊,請參閱重新建立網域管理伺服器。
將網域安裝和配置放在共用且牢固的檔案系統上 (例如 NFS)。若主要 DAS 機器故障,擁有相同 IP 位址的第二部機器就會啟動,並以手動操作或使用者提供的自動化程序接手運作。Sun Cluster 採用類似的方式讓 DAS 有容錯移轉功能。
壓縮 Application Server 安裝及網域根目錄。將壓縮檔復原到新機器上,並為其指定相同的網路識別。如果您是採用檔案型的安裝,這可能是最簡單的做法。
以 DAS 備份進行復原。請參閱 AS8.1 UR2 修補程式 4 指示。
節點代理程式和伺服器實例有兩種回復方式。
保存備份壓縮檔案。目前沒有針對節點代理程式和伺服器實例提供專屬的備份指令。只要建立一個壓縮檔,其中包含節點代理程式目錄的內容即可。發生故障之後,可將儲存的備份解壓縮至擁有相同主機名稱和 IP 位址的新機器上,並且使用相同的安裝目錄位置、作業系統等等。該機器上必須擁有檔案型安裝、套裝軟體型安裝或復原的備份影像。
手動回復。使用的新主機必須擁有相同的 IP 位址。
在該機器上安裝應用程式伺服器節點代理程式位元。
請參閱 AS8.1 UR2 修補程式 4 安裝指示。
重新建立節點代理程式。您不需要建立任何伺服器實例。
同步化處理會從 DAS 複製配置及資料,並做更新。
目前沒有單獨針對 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 可能會復原到舊的階段作業。
如需有關建立含有備用節點資料庫的資訊,請參閱建立資料庫。如需有關對資料庫增加備援節點的資訊,請參閱增加節點。如果回復及自我修復都失敗,備用節點即會自動接手。
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 的機器 (machine1)。
一台包含叢集的機器 (machine2),該叢集具有執行應用程式並滿足用戶端需要的伺服器實例。該叢集是使用第一台機器上的 DAS 配置的。
一台備份機器 (machine3),當第一台機器當機時,需要在該備份電腦上重新建立 DAS。
必須保留一份第一台機器上的 DAS 的備份。使用 asadmin backup-domain 來備份目前網域。
若要將 DAS 從第一台機器 (machine1) 遷移至第三台機器 (machine3),請遵循下列步驟:
將 Application Server 安裝在第三台機器上,方法與在第一台機器上安裝時相同。
為了可以在第三台機器上正確地復原 DAS 並且不會發生路徑衝突,您必須執行此操作。
將第一台機器上的備份 ZIP 檔案複製到第三台機器上的 domain-root-dir 目錄中。
也可以透過 FTP 方式複製檔案。
執行 asadmin restore-domain 指令,以將 ZIP 檔案復原到第三台機器:
asadmin restore-domain --filename domain-root-dir/sjsas_backup_v00001.zip domain1 |
可以備份任何網域。但是,在重新建立網域時,網域名稱應與原始網域名稱相同。
變更第三台機器上的 domain-root-dir/domain1/generated/tmp 目錄的權限,以與第一台機器上相同目錄的權限相符。
該目錄的預設許可權為:drwx------ (or 700).
例如︰
chmod 700 domain-root-dir/domain1/generated/tmp
以上範例假定您備份的是 domain1。如果備份的是其他名稱的網域,則應使用要備份網域的名稱取代上述的 domain1。
變更第三台機器的 domain.xml 檔案中的主機特性值:
更新第三台機器上的 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/>...
將:
<jms-service... host=machine1.../>
變更為:
<jms-service... host=machine3.../>
在 machine3 上啟動復原的網域:
asadmin start-domain --user admin-user --password admin-password domain1 |
在 machine2 上變更節點代理程式下的 DAS 主機特性值。
在 machine2 上變更 install-dir/nodeagents/nodeagent/agent/config/das.properties 中的 agent.das.host 特性值。
在 machine2 上重新啟動節點代理程式。
使用 asadmin start-instance 指令啟動叢集實例,以使這些實例與復原網域同步。