如今的電子商務及電子政務應用系統的發展已經到了一個新的階段,應用系統的成熟度和可用性都達到了更高的水準。因此龐大的部署規模和海量的用戶訪問成為目
前大型電子商務及電子政務應用系統的顯著特征。在這樣的情況下,企業對系統關鍵業務:如金融信息,通信,交通等要求確保系統24*7*365不停歇運行業
務的分布式部署結構和負載抗壓能力,以及高可用性都提出了更高的要求。IBM WAS
ND產品可以幫助我們在多應用服務器分布式部署環境下實現集群,確保系統的負載能力和高可用性。
下面按照邏輯概念的層次關系,由大到小依次了解IBM WAS ND產品定義的分布式網絡環境中的相關概念。
單元(Cell)
單元是整個分布式網絡中一個或多個節點的邏輯分組。單元是一個配置概念,是管理員將節點間邏輯關聯起來的實現方法。管理員根據具體的業務環境,制定對其整體系統集成環境有意義的條件來定義和組織構成單元的節點。如圖1所示,就一般情況來說,可以將單元看作是最大的作用域。
在IBM
WAS ND產品中,管理配置數據都存儲在 XML
文件中。單元保留了它每個節點中每臺服務器的主配置文件。同時每個節點和服務器也有其自己的本地配置文件。如果服務器已經屬于單元,則對于本地節點或服務
器配置文件的更改都是臨時的,通過在本地提交更改生效時,本地更改覆蓋單元配置,但是當執行單元配置文檔同步到節點的操作時,在單元級別上對主控服務器和
主節點配置文件所作的更改將會替換對該節點所作的任何臨時更改。
同步操作在指定的事件發生時進行,例如服務器啟動時等很多操作。也就是說,通過對本地節點或服務器配置文件進行修改而達到調整節點或服務器配置的做法不是安全的,臨時修改很容易被同步操作所覆蓋。
圖 1. 單元的作用域
Deployment Manager
Deployment
Manager
是管理代理程序,它提供集中式管理單元中所有節點的可視化人機交互管理視圖。之前提到單元是一個邏輯上的配置概念,那么Deployment
Manager 就為單元中所有元素提供了單一的管理控制中心點。每個單元都會包含一個 Deployment
Manager,由Deployment
Manager提供管理功能來修改單元的主配置文件。在最新的v6.x版本中還提供集群管理以及在一個或多個節點作用域內進行應用程序服務器工作負載平
衡。
圖 2. 由Deployment Manager提供管理功能來修改單元的主配置文件
節點(Node)
節點是受管服務器(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 是服務器,是一個管理代理程序,并不涉及應用程序服務功能。Node
Agent 進程在每個受管節點上運行,并專門執行特定于節點的管理功能,如服務器進程監視、配置同步、文件傳輸和請求路由。Deployment
Manager通過與Node Agent的交互完成對單元內節點的控制。
圖 4. Node Agent
WAS Plug-in
在
前面的章節我們討論過受管節點是通過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. 非受管節點通過插件接受管理
概要文件(Profile)
概
要文件定義一個獨立應用程序服務器(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
集群(Cluster)
集
群是一起進行管理并參與工作負載管理的多個服務器集合。作為集群成員的服務器可以位于不同的主機上,與此相對的是作為同一節點下的服務器必須位于同一臺主
機上。單元可以沒有集群,也可以有一個或多個集群。集群負責平衡服務器之間的工作負載。作為集群一部分的服務器稱為集群成員。當在集群上安裝應用程序時,
會在每個集群成員上自動安裝此應用程序。當刪除集群時,也就同時刪除了該集群的成員的任何應用程序服務器。沒有辦法保存任何集群的成員。除去集群成員的僅
有方法就是刪除應用程序服務器。如果希望保留要刪除的集群中的應用程序或模塊,則應該先將這些模塊重新映射至另一集群。
圖 7. 由兩個節點內的三個Server組成的集群
關于Node、Profile與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.
節點列表??梢钥匆姼鞣N類型的節點:應用服務器節點、單元節點、HttpServer非受管節點。可以在此添加新的節點或聯合已有非受管節點。各節點與單元主配置文件的同步操作也可以在這里完成。
圖 11.
Node Agent列表??梢钥匆?個應用服務器節點被聯合到單元之后,成為受管節點,開啟了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產品的能力。
參考資料
posted on 2007-11-02 11:12
前方的路 閱讀(1621)
評論(3) 編輯 收藏 所屬分類:
Web應用服務器