如今的電子商務及電子政務應用系統的發展已經到了一個新的階段，應用系統的成熟度和可用性都達到了更高的水準。因此龐大的部署規模和海量的用戶訪問成爲目前大型電子商務及電子政務應用系統的顯著特徵。在這樣的情況下，企業對系統關鍵業務：如金融信息，通信，交通等要求確保系統24*7*365不停歇運行業務的分佈式部署結構和負載抗壓能力，以及高可用性都提出了更高的要求。IBM WAS ND產品可以幫助我們在多應用服務器分佈式部署環境下實現集羣，確保系統的負載能力和高可用性。
下面按照邏輯概念的層次關係，由大到小依次瞭解IBM WAS ND產品定義的分佈式網絡環境中的相關概念。
單元是整個分佈式網絡中一個或多個節點的邏輯分組。單元是一個配置概念，是管理員將節點間邏輯關聯起來的實現方法。管理員根據具體的業務環境，制定對其整體系統集成環境有意義的條件來定義和組織構成單元的節點。如圖1所示，就一般情況來說，可以將單元看作是最大的作用域。
在IBM WAS ND產品中，管理配置數據都存儲在 XML 文件中。單元保留了它每個節點中每臺服務器的主配置文件。同時每個節點和服務器也有其自己的本地配置文件。如果服務器已經屬於單元，則對於本地節點或服務器配置文件的更改都是臨時的，通過在本地提交更改生效時，本地更改覆蓋單元配置，但是當執行單元配置文檔同步到節點的操作時，在單元級別上對主控服務器和主節點配置文件所作的更改將會替換對該節點所作的任何臨時更改。
同步操作在指定的事件發生時進行，例如服務器啓動時等很多操作。也就是說，通過對本地節點或服務器配置文件進行修改而達到調整節點或服務器配置的做法不是安全的，臨時修改很容易被同步操作所覆蓋。
圖 1. 單元的作用域
Deployment Manager 是管理代理程序，它提供集中式管理單元中所有節點的可視化人機交互管理視圖。之前提到單元是一個邏輯上的配置概念，那麼Deployment Manager 就爲單元中所有元素提供了單一的管理控制中心點。每個單元都會包含一個 Deployment Manager，由Deployment Manager提供管理功能來修改單元的主配置文件。在最新的v6.x版本中還提供集羣管理以及在一個或多個節點作用域內進行應用程序服務器工作負載平衡。
圖 2. 由Deployment Manager提供管理功能來修改單元的主配置文件
節點是受管服務器（Server）的邏輯分組。節點通常與具有唯一 IP主機地址的邏輯或物理計算機系統對應，節點不能跨多臺計算機。節點分爲受管節點與非受管節點。
IBM WAS ND 拓撲中的節點可能是受管的，也可能是非受管的。受管節點有相應的 Node Agent 進程來管理它的配置和服務器。非受管節點沒有 Node Agent。Node Agent 表示管理單元中的節點並負責保持配置始終處於最新狀態。非受管節點對於單元來說是未知的，所以 Deployment Manager 無法對其進行管理。
分佈式網絡環境中的非受管節點可以有服務器定義（例如 Web 服務器），但不能有應用程序服務器定義，並且非受管節點無法添加 Node Agent，因此它不能成爲受管節點。另外一種情況在獨立應用程序服務器環境中，節點尚且沒有 Node Agent，它們也可以暫時被視爲非受管節點，但是這類節點可以通過聯合獨立應用程序服務器而變爲單元中的受管節點。通過調整獨立應用程序服務器概要文件，將單獨的Server節點添加到單元，這個過程稱爲聯合。在聯合獨立應用程序服務器時，節點將自動創建 Node Agent，該節點就可以被Deployment Manager 管理。
圖 3. IBM WAS ND 拓撲中的受管節點與非受管節點
Node Agent 是將管理請求路由至服務器的管理代理程序。Node Agent 是服務器，是一個管理代理程序，並不涉及應用程序服務功能。Node Agent 進程在每個受管節點上運行，並專門執行特定於節點的管理功能，如服務器進程監視、配置同步、文件傳輸和請求路由。Deployment Manager通過與Node Agent的交互完成對單元內節點的控制。
圖 4. Node Agent
在前面的章節我們討論過受管節點是通過Node Agent進程與Deployment Manager交互。而非受管節點，最常見的是web服務器節點（如IBM HTTP Server），則是通過Web 服務器插件方式來接受Deployment Manager管理，加入到單元當中來的。IBM WAS ND產品支持所有符合規範的Web 服務器的基本管理功能，可以爲所有支持的 Web 服務器生成插件配置。插件生成之後，對於非受管節點，可以通過“傳播給遠程 Web 服務器”完成插件配置；如果定義在受管節點上，則直接通過節點間同步即可完成插件配置的傳播。
Web 服務器插件允許 Web 服務器將動態內容的請求發送到應用程序服務器。Web 服務器插件與每個 Web 服務器定義關聯。爲每個插件生成的配置文件（plugin-cfg.xml）基於通過關聯的 Web 服務器路由的應用程序。Web 服務器插件幫助面向的網絡中的應用程序服務器之間的工作負載平衡，改進請求響應時間。
圖 5. 非受管節點通過插件接受管理
概要文件定義一個獨立應用程序服務器（Server）的運行時環境，包括服務器在運行時環境中處理的所有文件。創建獨立應用程序服務器時應該使用概要文件而不是多個產品安裝，這樣只需要保留一組產品核心文件即可，管理能力將得到極大的增強。不僅節省了磁盤空間，而且簡化了產品的更新，只需要保留一組產品核心文件即可。而且與完整產品安裝相比，創建新概要文件更快速，而且減少了出錯的可能性，這允許開發者創建單獨的產品概要文件以進行開發和測試。核心產品文件是由所有概要文件共享的產品二進制文件,如果希望二進制文件位於不同服務級別，在應用安裝時設置。概要文件管理工具未提供刪除功能，所以必須使用 manageprofiles 命令來刪除概要文件。
使用概要文件創建獨立應用程序服務器，則每個定義的應用程序服務器進程都在 profiles 目錄內，除非在創建概要文件時指定新目錄。如果將概要文件放在安裝根目錄中，則存在概要文件可能被例行系統維護破壞的風險。這些文件在隨創建新的概要文件、重新配置現有的概要文件或刪除概要文件等操作而更改。
IBM WAS ND提供了多種類型的概要文件，以下是最常用的三種：
- 單元概要文件
基本功能是在 Deployment Manager的管理下將應用程序提供給因特網或內部網。創建單元概要文件其實就是同時創建Deployment Manager 概要文件和已聯合到單元的節點概要文件，構建一個最簡單的單元環境。在創建初始單元概要文件後，可單獨創建定製概要文件或獨立概要文件，再通過聯合操作將他們添加到 Deployment Manager管理的單元環境中。 - Deployment Manager 概要文件
基本功能是將應用程序部署到WAS的管理單元。每個屬於該單元的Server都作爲受管節點引用。 - Application Server 概要文件
基本功能是將應用程序提供給因特網或內部網。IBM WAS ND 產品的重要功能就是通過將 Server 節點添加到單元，調整獨立應用程序服務器概要文件。單元中的多個應用程序服務器進程可以部署它需要的應用程序。也可以從單元除去 Server 節點以將節點返回到獨立應用程序服務器的狀態。每個獨立應用程序服務器都具有其自己的管理控制檯應用程序，可以使用它來管理Server。
圖 6. 一個節點對應一個概要文件，一個節點內可以有多個Server
集羣是一起進行管理並參與工作負載管理的多個服務器集合。作爲集羣成員的服務器可以位於不同的主機上，與此相對的是作爲同一節點下的服務器必須位於同一臺主機上。單元可以沒有集羣，也可以有一個或多個集羣。集羣負責平衡服務器之間的工作負載。作爲集羣一部分的服務器稱爲集羣成員。當在集羣上安裝應用程序時，會在每個集羣成員上自動安裝此應用程序。當刪除集羣時，也就同時刪除了該集羣的成員的任何應用程序服務器。沒有辦法保存任何集羣的成員。除去集羣成員的僅有方法就是刪除應用程序服務器。如果希望保留要刪除的集羣中的應用程序或模塊，則應該先將這些模塊重新映射至另一集羣。
圖 7. 由兩個節點內的三個Server組成的集羣
這三個概念比較容易混淆，我們拿出來對比說明：Node=Profile。Node是管理上使用的概念，Profile是實際的概要文件，它們代表同一事物。Server 就是所謂的 Application Server Instance , 這是我們實際要佈署 Application 的地方。在IBM WAS ND 產品中受管節點的Node Agent 目的就是讓 Deployment Manager Server 可以透過 Node Agent 來管 Node (Profile) 中的 Application Server Instance，一個 Node (Profile) 中可以有多個 Application Server Instance。
如果是非ND版本 , 則屬於 Single Server 版本，那麼一個 Node (Profile) 中只能有一個 Application Server Instance，如果你希望在一臺機器上有多個 Application Server Instance，那就只能透過創建多個 Profile (Node) 來達成，但這些 Node (Porfile) 彼此獨立沒有管理上的關係 (RelationShip)，只要使用的 TCP/IP Port 不要衝突即可。
在完成了對IBM WAS ND 產品中相關概念的理解之後，我們通過一個較爲複雜的實例來了解一個集羣的構建過程。此次搭建的集羣環境使用了三臺測試服務器：
Table 1. 測試服務器情況
| 服務器地址 | 安裝節點 | 其他資源 |
|---|---|---|
| 192.9.100.14 | 一個非受管節點 | 獨立環境安裝IBM HttpServer v6.1 |
| 192.9.100.17 | 一個DM節點和兩個受管的應用服務器節點 | / |
| 192.9.100.19 | 一個受管節點，一個應用服務器節點 | IBM DB2 v9.0數據庫 |
客戶端直接訪問192.9.100.14上的IBM HttpServer，由IBM HttpServer根據節點本身設置的負載權重，分發訪問請求。
圖 8. 集羣拓撲結構圖
以下是該集羣拓撲結構的安裝步驟，只描述需要提示的關鍵步驟。
首先創建運行時環境。打開Profile Management Tool概要文件管理工具創建概要文件。選擇創建單元概要文件，即同時創建一個Deployment Manager 概要文件和一個已經被聯合的應用服務器節點概要文件，也可以創建DM概要文件再聯合已存在節點。
圖 9.
創建成功後在Deployment Manager 概要文件環境中登錄到管理控制檯，可以在“系統管理”中看見DM相關資源。
圖 10.
節點列表。可以看見各種類型的節點：應用服務器節點、單元節點、HttpServer非受管節點。可以在此添加新的節點或聯合已有非受管節點。各節點與單元主配置文件的同步操作也可以在這裏完成。
圖 11.
Node Agent列表。可以看見3個應用服務器節點被聯合到單元之後，成爲受管節點，開啓了Node Agent進程。Node Agent在這裏只能停止和重新啓動。停止了之後就不能在此啓動，需要回到Node下的概要文件中使用命令行去啓動Node Agent。
圖 12.
在“服務器”中選擇“集羣”，新建。一般來說，如果創建了集羣，那麼對各個單獨節點的操作都應該在集羣或DM中操作，而不應該去“服務器”中的“應用程序服務器”中單獨操作。
圖 13.
爲集羣添加成員（節點），並且在添加成員的同時重命名一個短名稱。分配負載權重。指定分配給應用程序服務器的工作量。值的範圍是 0 到 20。權重值越大表明將分得越多的工作量。
圖 14.
可以對集羣進行啓動和停止操作。對集羣進行啓動停止，就是對集羣內的成員節點進行啓動停止。
圖 15.
接下來安裝web服務器，本例中採用IBM HTTP SERVER（IHS）。安裝IHS的過程中注意在安裝WAS IHS插件，填寫Application Server主機名或IP時，如果是在集羣環境下，就填寫DM所在節點的主機名或IP地址。其他步驟沒有困難。
圖 16.
安裝IHS結束之後會有Admin Server和HTTP Server兩個Server。HTTPServer是通常意義上的Web Server。Admin Server是IHS用來配合IBM WAS ND產品提供遠程管理服務的。啓動Admin Server則可以在遠程節點加入該Web Server節點，並對其進行啓動、停止等管理。也可以直接將插件配置文件傳播到這個節點上。
圖 17.
安裝插件，選擇要配置的web服務器
圖 18.
主要的生產配置是一臺機器上的應用程序服務器和另一臺機器上的 Web 服務器。此配置稱爲遠程配置。與遠程配置相對的是本地配置，其中應用程序服務器和 Web 服務器在同一臺機器上。
圖 19.
指明web服務器插件在IBM WAS ND中安裝的位置。默認位置即可。
圖 20.
指明IHS配置文件httpd.conf的位置和Web服務器的端口。在IHS那一端。
圖 21.
接下來設置IHS中plugin-cfg.xml文件的位置，默認位置即可。IBM WAS ND上也有這樣一個文件，可以通過手工COPY或“遠程傳播”的方式使二者保持一致。然後指明標示應用程序服務器的主機名或IP地址，推薦使用DM所在機器的主機名或IP地址。連續“下一步”至安裝結束。
接下來需要將安裝好的IHS及WAS插件加入到集羣中去。可以通過管理控制檯添加，也可以通過命令行形式添加，通過管理控制檯添加比較簡明，但步驟很多。下面描述一下快速命令行加入的方式：
1. 開啓IHS的admin管理，在{IHS-install}/bin目錄下運行
httpasswd -cm {install_dir}\conf\admin.passwd admin (admin 是管理IHS的用戶名). 接着輸入兩次密碼.
|
2. 在IHS節點中啓動IBM HTTP Server 和 IBM HTTP Admin Server.
3. 將IHS節點的{plunin-install}/bin/configurewebserver1.bat文件拷貝到安裝時填寫的WAS服務器的{was-install}/bin目錄.當時推薦的是DM所在服務器。
4. 在DM所在服務器上啓動DM服務
5. 在DM所在服務器上打開一個命令行窗口,運行
{was-intall}/bin/configurewebserver1.bat
|
6. 如下圖所示在配置管理控制檯確認Web Server被成功加入。由於啓動了Admin Server，所以這個Web Server 還可以在WAS的管理控制檯被管理。版本處寫的“不適用”是因爲這個Web Server 節點是一個非受管節點。
圖 22.
全部安裝配置完畢後，還需要爲每一個server設置一個端口號爲80的虛擬主機，以便接收來自IHS的請求 。
圖 23.
部署應用則按照常規方式安裝應用即可。注意在映射至服務器時，需要將該應用同時映射到集羣和HttpServer上去。如果不是web模塊則不必映射到HttpServer上去，如EJB。這樣應用會同時安裝在集羣環境中的所有Node下的所有Server中。安裝後需要重啓Cluster和重新生成、傳播WAS Plug-in。
圖 23.
爲了讓發佈在Cluster上的應用能連接到數據庫, 我們需要在所有的受管節點上創建相同的數據源。創建數據源的過程與普通過程無異，需要注意的是創建Jdbc Provider時作用域應該選擇在節點範圍。如果在Cluster級別，某些版本的ND可能出現問題。重啓DM服務,並且重啓所有受管節點的NodeAgent服務。
圖 24.
至此，集羣的全部搭建步驟就完成了，重新啓動Deployment Manager、NodeAgent以及集羣的服務。如拓撲結構中所示，可以通過訪問WEB服務器來訪問應用，即：http://192.9.100.14 或 http://192.9.100.14:80。也可以嘗試將其中的一個或兩個Node停止，以確認是否能繼續訪問。
越來越多的企業及政府應用系統提出了對集羣環境的要求，本文的主要目的是想闡述清楚IBM WAS ND產品對集羣及整個分佈式網絡環境的理解和定義。只有理解這些定義和架構，纔可以在實際工程的集成與部署工作中拿出好的設計方案來，並最大程度的發揮IBM WAS ND產品的能力。