在步驟 2 中，在節點 TP2 上創建一個名為 clone1 的克隆。設置權重為 2，選擇 Generate Unique Http Ports 和 Create Replication Entry in this Server。使用默認的應用程序服務器模板並單擊 Apply。 圖 17. 創建新的群集的服務器 重復步驟 2，在節點 TP2 上創建一個名為 clone2 的克隆。設置權重為 2，選擇 Generate Unique Http Ports 和 Create Replication Entry in this Server。使用默認的應用程序服務器模板並單擊 Apply。 再次重復步驟 2，在節點 TP2 上創建一個名為 clone3 的克隆。設置權重為 4，選擇 Generate Unique Http Ports 和 Create Replication Entry in this Server。使用默認的應用程序服務器模板並單擊 Next。 檢查總結以確認群集中已經存在三個有正確屬性的克隆。然後單擊 Finish 保存修改。 在群集的創建過程中，您已經為這個群集創建了一個復制域（Replication Domain），可以用它來在克隆之間復制 http 會話以支持故障切換。為此，您需要配置應用程序服務器 clone1 和 clone2 去使用這一服務。在 Administrative Console 中，選擇 Application Servers > clone1 > Web Container > Session Management > Distributed Environment Settings。然後選擇 Memory to Memory Replication 單選按鈕。重復此過程設置 clone2。 現在您已經創建了一個群集定義。下一個步驟是安裝一個企業應用程序。在這個練習中，使用的是位於 WebSphere Application Server 安裝的 /installableApps 目錄下的 DefaultApplication.ear。用 Deployment Manager Administrative Console 來安裝這個應用程序。將一個企業應用程序安裝到群集與安裝到獨立的應用程序服務器的過程相同，只有一點例外：在“將模塊映射到應用程序服務器”步驟中，您必須為所有模塊選擇 cluster1。參見下面圖 18 中的例子。（介紹企業應用程序詳細的安裝步驟不在本文范圍之內。） 圖 18. 將模塊映射到應用程序服務器 在群集的設置過程中，三個克隆創建時各自使用惟一的 HTTP 端口。這就意味著在每個應用程序中運行的內部服務器的 HTTP 監聽器有特定的值。管理進程創建新端口所用的算法，為每個定義的新服務器使用默認值（HTTP 傳輸使用 9080）並遞增到下一個沒有被占用的值。 在這個例子中，當您安裝完 WebSphere Application Server 後，創建了一個名為 server1 的獨立服務器。當這個節點添加到 Deployment Manager 時，server1 也會遷移為托管服務器。Server 1 使用 9080 端口進行 HTTP 傳輸。在 TP2 上，創建的 clone1 使用 9081 端口，clone2 使用 9082 端口。當安裝 DefaultApplication.ear 時，Web 模塊要使用 default_host 虛擬主機。默認情況下，default_host 只接受 9080 端口上的請求，所以您需要配置這個虛擬主機，讓它也可以接受 9081 端口和 9082 端口上的請求。 在 Administrative Console 中通過 Environment > Virtual Hosts > default_host > Host Aliases 來為默認主機添加附加端口的支持。單擊 New 以添加一個新的別名。用 * 作為主機名（* 代表任意主機名)，用 9081 作為端口值。重復這一過程來設置 9082 端口，如圖 19 所示。 圖 19. default_host 的附加端口 確保 Synchronize changes with Nodes 已經被選中，保存配置。 既然您已經在群集中安裝了一個應用程序，現在該測試它了。在我們的運行期中有三種類型的進程：Deployment Manager、Node Agent 和 Application Server。它們每個都是獨立的系統級 Java 進程。 您可以使用 Deployment Manager 的 Administrative Console 來啟動或停止群集。在此之前，每個節點都必須已經在運行 Node Agent。您可以使用表 1 中的命令來控制安裝中的 Deployment Manager 和 Node Agent。 表 1. 控制 Deployment Manager 和 Node Agent 的命令 從先前執行 addNode 命令時起，Node Agent 應該還在運行。在 Administrative Console 中通過 System Administration > Node Agent 來檢查 TP1 和 TP2 的 Node Agent 是否在運行。然後查看節點 TP1 和 TP2 的狀態。如果其中一台計算機上的 Node Agent 不可用，那麼在那台計算機的命令行中啟動它。當所有 Node Agent 都啟動後，您可以通過 Administrative Console 啟動群集，如圖 20 所示。根據您的硬件配置的不同，啟動過程可能需要幾分鐘。 圖 20. 啟動群集 在測試工作負荷管理之前，有必要先分別檢驗一下各個克隆是否在工作。打開一個浏覽器，訪問下面的 URL： http://tp2:9081/hello - 查看 clone1 是否在工作。 http://tp2:9082/hello - 查看 clone2。 http://tp1:9081/hello - 查看 clone3。 圖 21. 確認服務器在運行 如果三個 URL 返回圖 21 中的結果，那麼群集中所有服務器都在工作，而且使用的端口正確無誤。關閉您的浏覽器。
測試工作負荷管理 HTTP 服務器插件提供了對 Web 應用程序工作負荷的管理。在往 TP1 上安裝 WebSphere Application Server 的同時也安裝了 IBM HTTP 服務器。默認情況下，插件使用 /opt/WebSphere/AppServer/config/cells 目錄下的 plugin-cfg.XML 配置文件。通過 Administrative Console 中的 Environment > Update Web Server Plugin 來生成插件的配置。 Administrative Console 生成的文件將放在 /opt/WebSphere/DeploymentManager/config/cells 目錄中。所以，您需要將生成的文件手工拷貝到 HTTP 服務器插件可以找到的目錄，比如 /opt/WebSphere/AppServer/config/cells 目錄。 DefaultApplication.ear 中的 snoop servlet 適合用於測試工作負荷。它顯示用來執行請求的進程名。打開一個浏覽器並輸入這個 URL：http://tp1/snoop（IBM HTTP 服務器安裝在 TP1 上）。 圖 22. 測試工作負荷 多刷新幾次您的浏覽器，查看是哪個克隆執行請求。您應該會得到 1233、1233 等序列，這反映出了配置克隆時指定的相對權重。 注意：如果您總是看到同一個克隆的 id，那麼關閉浏覽器再重新打開。這樣可以刪除被 WebSphere Application Server 用於會話親緣性（session affinity）的 cookie。
