在每篇專欄文章中，“WebSphere® 反向投資者” 將回答問題、提供指導並討論與 WebSphere 產品使用相關的基礎主題，經常會給出與流行的看法相悖的經過實踐驗證的建議。
回到老話題上 —— 以及拉丁文
距離我編寫 implementing a highly available infrastructure for IBM WebSphere Application Server Network Deployment without clustering 一文已經將近 7 年的時間，雖然我當時描述的程序現在仍然廣泛適用於 WebSphere Application Server Network Deployment（此後簡稱為 Network Deployment）V6.x 和 V7.0，但是期間對 Network Deployment 的一些更新改變了一些細節，並且為 Network Deployment 運行時管理高可用性（HA）提供了一些額外選項。因此，我想現在應該翻新一下這個話題。另一個好處是，我總是試圖尋找一個機會來使用我在（很多）很多年前學習的高中拉丁文，而重新翻新一篇早期的文章讓我能夠有機會在標題中使用 redux 一詞！現在重新回顧 Network Deployment 管理運行時功能特別合適，因為這個主題正在復蘇，或者說正在重新流行（我的拉丁文老師將會十分自豪！）。最後一個原因是我經常被問到有關這個主題的內容，因此完全是為了我自己考慮，因為討論這個主題將提供一個更加廣泛可用的資源，再有人問我這樣的問題時，我就可以直接讓他們參考本文。這樣，每個人都皆大歡喜！
在深入討論 Network Deployment 運行時管理 HA 的選項和相關技巧之前，讓我們先快速回顧一下 Network Deployment 應用服務器架構。Network Deployment 應用服務器的設計目標是能夠在管理運行時實現一般程度的自給自足。每個應用服務器擁有自己的：
Web 容器。
EJB 容器。
名稱服務。
安全服務。
事務管理器服務。
JMS 消息傳遞引擎（屬於可選項，取決於具體配置）。
JCA 連接管理器（提供 JDBC 和 EIS 連接）。
Java™ Management Extensions (JMX) 管理服務器。
高可用性管理器服務。
Web 容器實際上是一個 “聚合（converged）容器”，托管通過 HTTP(S) 訪問的組件，比如 servlets、JSP 和 portlet，以及使用 Session Initiation Protocol (SIP) 的組件。
通過使用以上列出的服務，節點代理或部署管理器出現的故障不會影響正在運行的 Network Deployment 應用服務器（受制於幾個問題，我們將稍後討論），這樣即使發生了故障，仍然能夠繼續處理應用程序請求。
如果您曾經體驗過 Network Deployment，那麼您就知道從 V5.x 到 V6.x 的演變去掉了大多數運行時依賴關系，這些依賴關系曾經位於節點代理和部署管理器中。細心的讀者可能已經注意到我剛剛提到在管理運行時實現一般程度的自給自足，這並不等同於完全的自給自足……，因為一些功能仍然存在於節點代理和部署管理器中 —— 但是這些功能不會影響已經運行的應用服務器（或其中運行的應用程序）。當然，如果我不討論這些單獨存在於節點代理和部署管理器的功能，您是不會輕易放過我的，我不會怪您，那麼讓我們來看看這些功能吧。
節點代理功能
雖然可以使用一個選項來禁用 WebSphere Application Server 工作負載管理並提供您自己的靜態工作負載管理路由定義—— 它的一個副作用就是允許 Network Deployment 應用服務器獨立於節點代理啟動，但是，不要使用這個選項。原因是執行修改（比如添加一個集群成員）的惟一方法是：
撤銷所有靜態路由修改。
將整個環境返回到動態路由。
添加成員。
為環境拍攝一個新的快照。
導出工作負載管理路由表（位於一個扁平文件中）。
重新啟用所有屬性，回到靜態路由模式。
這將為 cell 管理帶來巨大的復雜性。還要注意，雖然應用服務器從節點代理 LSD 啟動自檢（bootstrap），但是獨立的應用程序客戶機應當使用 Corbaloc (CORBA Object URL) 從每個應用服務器的名稱服務中啟動自檢。
考慮到節點代理在應用服務器啟動自檢中扮演的角色，您不希望節點代理長時間不可用。這在同時啟動大量服務器期間尤其如此，比如在應用 OS 維護、WebSphere Application Server 維護或應用程序（重）部署之後。
在一個有多個機器運行 Network Deployment 集群的環境中，在出現故障時 OS 監視和重啟節點代理的能力應當滿足節點代理 HA，因為丟失單個節點不應當在多機器環境中引起重大的故障。根據具體的操作系統，有很多種 “OS 進程保護（process nanny）” 功能（Windows 上的 Windows Service，或者 Linux 或 UNIX 上的 initab）可以用來實現此目的，只要物理服務器和 OS 繼續運行，這些功能就能夠起作用 —— 這反過來支持 OS 進程保護功能監視和重啟節點代理。當然，如果 OS 沒有運行，那麼您就無法啟動任何進程，更別說 Network Deployment 進程了！
部署管理器功能
從 Network Deployment V6.x 開始，部署管理器不再成為 IIOP 工作負載管理路由表的單點故障，這和 WebSphere Application Server V5.x 中的情況一樣。在 Network Deployment V6.0 及更新版本中，HA 管理器確保維護這些信息的單獨實例（singleton）始終可用於其中一個 Network Deployment 進程（部署管理器、節點代理、應用服務器等等）。如果托管該單獨實例的進程出現故障，那麼將選擇另一個進程來托管該單獨實例。因此，Network Deployment V6.x 和 V7.0 中的部署管理器只用於執行配置修改和管理 JMX 路由。
雖然您會使用適合自己的操作系統的集群軟件配置高可用性集群中的部署管理器（例如面向 AIX® 的 HACMP、面向 Solaris™ 的 SunCluster、面向 HP-UX 的 MC/Serviceguard，以及用於 Windows® Server 的 Microsoft® Cluster Server），但是這種配置會增加成本和復雜性。我並不是說不應該對部署管理器的恢復或故障轉移進行准備，只是說可以使用一些其他方法來最大程度地保持執行配置修改或路由 JMX 通信（包括由部署管理器提供的性能監視信息）的能力。我們將首先討論可用性技巧，確保管理進程保持持續運行。
OS 進程保護
這項技巧不會提供服務器之間的進程故障轉移，但是它的確提供了一種方法（重申一次，只要 OS 和服務器正常發揮作用），可以確保節點代理或部署管理器進程保持運行狀態。Network Deployment 信息中心 討論了為 Windows 平台創建 Windows 服務以及修改樣例文件 was.rc 以用於創建 Linux® 或 UNIX® OS 進程保護。但是對於 Linux 和 UNIX，還可以使用另外一種方法。
在 Linux 和 UNIX 上，您很可能知道如何使用 startManager.sh 和 startNode.sh 腳本來啟動部署管理器和節點代理。但是您還可以使用一個 -script 選項來創建可由 OS 實現的腳本，以啟動這兩個進程（或在出現故障後執行重啟）。
首先將創建腳本。對於部署管理器：
清單 1
>/wasconfig/OjaiCell01/profiles/Dmgr01/bin # ./startManager.sh
–script OSstartManager.sh
ADMU0116I: Tool information is being logged in file
wasconfig/OjaiCell01/profiles/Dmgr01/Dmgr01/logs/dmgr/startServer.log
ADMU0128I: Starting tool with the Dmgr01 profile
ADMU3100I: Reading configuration for server: dmgr
ADMU3300I: Launch script for server created: OSstartManager.sh
對於節點代理，使用 startNode.sh 而不是 startManager.sh 來從節點代理概要文件 bin 目錄中創建腳本。
接下來，對於剛剛創建的文件，使用下面的內容修改 /etc/inittab 文件：
清單 2
# WAS inittab entry
was:235:respawn:/ wasconfig/OjaiCell01/profiles/Dmgr01/bin/OSstartManager.sh
>/dev/console 2>&1
保存 inittab 文件並運行 init –q 來重新裝載文件。您應當會看到部署管理器正在啟動（除非它已經在運行，這種情況下，您將需要首先停止部署管理器，或者不運行 init –q）。
如果您准備采用這項技巧的話，根據您正在運行的 WebSphere Application Server 的版本，您可能需要了解 這個 APAR。
警告：一旦將 inittab 配置為按這種方式啟動進程，您就無法手動停止節點代理或部署管理器 —— 或者，如果您的確停止了兩者中的任意一者，它將立即重啟。在許多環境中，這將引起更多的問題，因此您應當謹慎使用該選項。
現在您已經提供了進程可用性，讓我們了解一下部署管理器故障轉移選項，這些選項不需要硬件集群功能。
使用多個服務器的 Cell 配置備份和恢復
盡管這裡描述的方法沒有提供完全自動化的故障轉移和恢復，但是這種方法的成本相對較低，而且容易實現，並且考慮到它的簡單性以及對部署管理器宕機的影響較小，因此它應該足夠滿足需求。
一般來講，需要執行下面的步驟：
使用 backupConfig 腳本對 cell 配置執行常規備份。此外，從 <was deployment manager profile>/etc 和 <was deployment manager profile >/ 屬性目錄手動復制關鍵文件。
在備份或備用服務器上安裝 Network Deployment 並創建一個部署管理器概要文件。
使用 restoreConfig 腳本在備份服務器上恢復配置。
在備份服務器上修改 IP 地址（或主機名），以解析為原始服務器的 IP 地址（或主機名）。
在備份服務器上啟動部署管理器。
首先，您必須經常對 cell 執行備份（以防止您無法訪問包含該信息的磁盤）。WebSphere Application Server 為此提供了一個命令行工具，backupConfig.sh/bat，位於所有 Network Deployment 概要文件的 bin 目錄中。然而，如果要備份您的 cell 配置，您應當從部署管理器概要文件中運行它。下面展示了該腳本的執行：
清單 3
>/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin # ./backupConfig.sh
20090801_backup.zip
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/backupConfig.log
ADMU0128I: Starting tool with the Dmgr01 profile
ADMU5001I: Backing up config directory
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config to file
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/20090801_backup.zip
.................................................................................
ADMU5002I: 689 files successfully backed up
默認執行將停止部署管理器。雖然停止部署管理器來防止在運行備份時發生修改是個好主意，但是這個操作是沒有必要的。如果您使用 -nostop 選項運行 backupConfig 腳本，那麼部署管理器將不會被停止，這種情況下，您需要確保在運行備份期間不會執行任何配置修改。並且，您可以選擇指定一個文件名，如上所示，或者省略文件名，這將導致生成以下格式的文件名：WebSphereConfig_YYYY-MM-DD.zip。
同時，如上所述，創建 <was deployment manager profile>/etc 和 <was deployment manager profile>/ 屬性目錄的備份：
來自 <was deployment manager profile>/etc 的簽名者證書；例如，/opt/IBM/WebSphere/ApplicationServer//profiles/Dmgr01/etc。
來自屬性目錄的客戶機安全屬性文件；例如，/opt/IBM/WebSphere/ApplicationServer/profiles/Dmgr01/properties。
屬性目錄需要得到復制，因為您可以修改它們的內容來定制 WebSphere Application Server 客戶機的行為。etc 目錄需要進行復制，因為它包含用於建立客戶機到服務器之間的 SSL 連接的密匙和證書（以及其他內容）。根據您的具體配置，如果不能夠復制這些文件，那麼會導致出現一些小問題（比如錯誤地要求您輸入密碼或導入一個證書）或嚴重的故障。
這種復制應該定期執行或者結合使用 backupConfig，使用普通的 OS 文件系統復制工具（比如 tar），並且需要在機器出現故障之前執行，以確保您可以訪問這些文件。
當您進行備份後，將其副本放到一個高度可用的文件系統中；否則，部署管理器服務器出現磁盤故障會使這些備份變得不可用。
接下來，您必須在備份服務器上安裝 Network Deployment 並創建一個部署管理器概要文件。這一步驟的關鍵在於從原始服務器指定 Profile 名、Node 名、Host 名（或 IP 地址）以及 Cell 名（圖 1）。
圖 1. 概要文件創建期間指定節點、主機和 cell 命名規范
您需要為原始服務器指定這些值，因為您的 cell 配置在構建時需要使用服務器名。
當您的 Network Deployment 安裝完成後，您在備份服務器上創建了一個部署管理器概要文件，並且您從 <was deployment manager profile>/etc 和 <was deployment manager profile>/ 屬性目錄恢復了文件，您現在已經准備好從原始服務器恢復 cell 配置了。您將使用 restoreConfig.sh/bat 腳本實現此目的：
清單 4
>/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin #./restoreConfig.sh
20090801_backup.zip
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/restoreConfig.log
ADMU0128I: Starting tool with the Dmgr01 profile
ADMU0505I: Servers found in configuration:
ADMU0506I: Server name: dmgr
ADMU2010I: Stopping all server processes for node N1CellManager01
ADMU0512I: Server dmgr cannot be reached. It appears to be stopped.
ADMU5502I: The directory /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config
already exists; renaming to
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config.old
ADMU5504I: Restore location successfully renamed
ADMU5505I: Restoring file 20090801.zip to location
/opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config
....................................................................
ADMU5506I: 689 files successfully restored
ADMU6001I: Begin App Preparation -
ADMU6009I: Processing complete.
此時您有以下兩個選擇：
添加或刪除 DNS 條目（或所有機器上的 /etc/hosts 文件），這樣，此前在其上運行部署管理器的故障服務器的名稱現在解析為您剛剛將部署管理器移動到其中的服務器的名稱。
修改備份服務器上的 IP 地址以匹配原始服務器的 IP 地址，或者添加一個網絡接口卡，使用原始服務器的 IP 地址。根據您使用的操作系統，實現上述操作的步驟會有所不同；您只需要對操作系統使用合適的命令或工具。
第一個選項要求您停止並重啟所有節點代理，以清除節點代理 JVM 中的 “陳舊” 緩存，這些緩存指向服務器的舊 IP 地址。之所以出現這些舊緩存，是因為 Java “可以記住” 主機名的 IP 解析。因此，一旦建立起一個連接後，所有運行的節點代理 JVM 都緩存了運行部署管理器的原始服務器的 IP 地址。此外，您可以為每個節點代理配置一個命令行參數，這將強制定期刷新 DNS 緩存。該屬性為：
-Dsun.net.inetaddr.ttl=<time in seconds>
圖 2 顯示了一個例子。
圖 2. 節點代理 JVM 參數
該屬性的一個比較合理的值是 60 秒。停止並啟動節點代理可以確保該操作能夠及時發生，並且適合較小的 cell（小於 10 個節點）。第二個選項不要求您停止並重啟節點代理，因為您已經添加或修改了新服務器的 IP 地址。在使用第一個選項時，還要知道在創建部署管理器概要文件期間，您必須指定服務器的主機名，而第二個選項要求您指定 IP 地址。
最後，通過運行 startManager 腳本啟動部署管理器。如果您收到下面的消息：
ADMU3000I: Server dmgr open for e-business; process id is xxxx
說明您現在就可以開始使用管理控制台或 wsadmin 來對您的 cell 進行管理。您可以一直執行管理操作，直到您的原始服務器恢復正常。
提醒您一下，當您返回到原始服務器時，可能需要停止並重啟所有節點代理，這取決於前面介紹的修改 IP 地址的方式。
具有一個共享文件系統的多個服務器
這個技巧是對前面的技巧稍加變化而來。和前面一樣，這種方法不會提供完全的自動化故障轉移和恢復，但是它同樣具有較低的成本且易於實現，而且它具有簡單性，對部署管理器宕機的影響較小，因此足以滿足需求。但是需要提醒您：確保您的共享文件系統提供了足夠的性能，否則在執行一般操作時會出現性能降低，當您維護 Network Deployment cell 配置時，當出現宕機並需要從備份服務器運行時，都會出現性能下降。
一般來講，需要執行下面的步驟：
掛載一個共享（且高度可用的）文件系統，以用於 cell 配置。
在主機器上安裝 Network Deployment 並創建一個部署管理器概要文件，並在備份機器上安裝 Network Deployment。（不需要在備份機器上創建概要文件）。
在備份服務器上修改 IP 地址（主機名）以解析為原始服務器的 IP 地址（或主機名）。
在備份服務器上啟動部署管理器。
首先，將一個共享文件系統（比如 NFS）或一個 SAN 文件系統掛載到主服務器機器和備份服務器機器。在本例中，我們掛載了一個名為 “wascell” 的共享目錄。
接下來，在兩個機器上安裝 Network Deployment。當您創建部署管理器概要文件時，您需要在圖形 Profile Management Tool (PMT) 中指定 Profile 目錄，如圖 3 所示，或者使用 –dmgrProfilePath 指令，如果使用的是 manageprofiles(bat/sh) 命令的話。如果您使用的是 PMT，那麼使用高級概要文件創建選項，這樣就可以為概要文件指定路徑。
圖 3. PMT 中的概要文件名和目錄
您將注意到我包含了 cell 名 OjaiCell01 作為目錄路徑的一部分，從而能夠為共享文件系統上的多個 cell 存儲配置。
當此時發生服務器故障時，執行上面描述的步驟來修改 DNS 條目或在備用服務器上啟動網卡，該網卡最初與主服務器關聯。
最後，只需要從備份服務器打開一個 OS shell 並導航到部署管理器概要文件的配置目錄，並使用 startManager(sh/bat) 啟動部署管理器：
>/wascell/profiles/Dmgr01/bin #./startManager.sh
和前面一樣，一旦收到下面這條消息：
ADMU3000I: Server dmgr open for e-business; process id is xxxx
說明您現在就可以開始使用管理控制台或 wsadmin 來對您的 cell 進行管理。
使用節點代理的 Cell 配置備份
使用上面所述的 使用多個服務器的 Cell 配置備份和恢復 的過程的變體在 這篇文章 進行了詳細解釋。與使用 backupConfig 進行備份不同，該過程：
將一個節點聯合到 Network Deployment cell。
將節點配置為獲取完整 Network Deployment cell 配置的副本，這不同於特定於節點的 cell 配置，後者是在配置同步期間默認獲得的。
創建一個修改後的部署管理器啟動腳本，用於使用備份節點維護的配置。
盡管這個過程確實替代了對 Network Deployment cell 進行定期備份的需求，但是它的缺點是被限制為備份部署管理器的操作控制，因此您無法使用這種方法來做出配置修改。因此，這個過程只適合在主部署管理器恢復之前的短暫的一段時間，並且沒有提供一種途徑來在出現故障時在部署管理器中恢復 cell 配置。
其他考慮事項
與部署管理器 HA 主題相關的一個問題是部署管理器的位置問題。我建議將您的生產部署管理器放置到一個獨立的服務器中，與運行 Network Deployment 應用服務器的其他服務器區分開。我的依據是在單獨的服務器（或專門用於部署管理器的服務器）上運行部署管理器可以使 OS 和 WebSphere Application Server 上的應用程序維護更加輕松。將部署管理器放到單獨的機器上，這意味著在部署管理器服務器上執行維護不會影響任何運行中的應用服務器，如果部署管理器和應用服務器位於相同的機器上，那麼就會對應用服務器產生影響。當您在這種場景下應用維護時，您不會同時處理部署管理器和部分應用服務器基礎設施中出現的宕機，因此您不會同時影響管理運行時和應用程序運行時。
盡管您需要對部署管理器服務器（或者您選擇的節點）使用單獨的許可，但是如果高可用性對您的企業至關重要的話，那麼購買許可的費用要比意外宕機引起的開銷更加重要。此外，雖然將部署管理器放在單獨的虛擬映像（比如 LPAR、Zone 等等）確實解決了 OS 或 WebSphere Application Server 維護引起宕機的問題，但是它不能夠避免機器成為單點故障。因此，如果您使用了 LPAR 或相關技術，那麼需要做好准備，因為在另一個物理機器上啟動部署管理器虛擬映像可能會出現機器故障。
結束語
雖然本文介紹的選項不能夠確保在所有情況下實現完全的自動化故障轉移和恢復，但是它們確實提供了一些更合理的方法來替代那些成本高昂的自動化解決方案 —— 在當今不景氣的經濟環境下，企業管理者可能非常歡迎這些新的替代方法。
現在讓我好好想一想 reducere 一詞的詞形變化，reduco、reducere、reduxi……
