WAS叢集系列(8):叢集搭建:步驟6:建立概要檔案,叢集概要
(1)、主機解析地址修改
WAS節點1、WAS節點2、資料庫伺服器下修改hosts檔案
將所有主機的IP映射到各個hosts檔案中,舉例方法如下:
例:WAS節點WINDOWS環境下
WINDOWS修改:C:\Windows\System32\drivers\etc\hosts
LINUX修改:
[root@hyldbsoft]# vi /etc/hosts
# Do notremove the following line, or various programs
# thatrequire network functionality will fail.
127.0.0.1 xckydb localhost.localdomainlocalhost
::1 localhost6.locaUldomain6localhost6
10.53.105.65 hyldb
10.53.105.66 WIN-IRS49CN78FE
10.53.105.63 WIN-PLDC49NNSAA
(2)、關閉防火牆
確認關閉了應用伺服器、資料庫伺服器的防火牆。
(3)、節點1,建立DM概要檔案命令
節點1:
建立DM概要檔案:主機名稱為節點1主機名稱(節點1作為DM伺服器)
參考指令:
manageprofiles-create -profileName Dmgr01 -profilePath “D:/IBM/WebSphere/Appserver/profiles/Dmgr01”-templatePath “D:/IBM/WebSphere/AppServer/profileTemplates/dmgr” -hostnameWIN-PLDC49NNSAA
(4)、節點1,建立應用概要檔案
建立應用概要檔案:主機名稱為節點1主機名稱(節點1作為DM伺服器同時也作為應用伺服器)
參考指令:
manageprofiles-create -profileName AppSrv01 -profilePath “D:/IBM/WebSphere/AppServer/profiles/AppSrv01”-templatePath “D:/IBM/WebSphere/AppServer/profileTemplates/default” -hostnameWIN-PLDC49NNSAA
(5)、啟動節點1相應服務
啟動DM(進入到Dmgr路徑下執行)
啟動server1(進入到AppSrv01路徑下執行)
(6)、節點2,建立應用概要檔案
建立應用概要檔案:主機名稱為節點2主機名稱(節點2作為其中一個應用伺服器)
參考指令:
manageprofiles-create -profileName AppSrv01 -profilePath “D:/IBM/WebSphere/AppServer/profiles/AppSrv01”-templatePath “D:/IBM/WebSphere/AppServer/profileTemplates/default” -hostnameWIN-IRS49CN78FE
(7)、啟動節點2的服務
啟動server1:(進入到AppSrv01路徑下執行)
補充:如果添加第3個節點
如果需要添加新的節點的概要檔案,設定參考本文的第2個節點設定即可。
最近中秋臨近,小酒小吃倒是接連不斷,迷瞪的狀態有點懶惰了,
恰好今日倒是閑暇無事,來把這“was叢集的搭建”做個階段性的瞭解吧,
哈哈。
***********************************************聲明************************************************
原創作品,出自 “深藍的blog” 部落格,歡迎轉載,轉載時請務必註明出處(http://blog.csdn.net/huangyanlong)。
表述有錯誤之處,請您留言或郵件(hyldba@163.com)指明,不勝感激。
***********************************************待續************************************************
問WAS v70BASE 版有叢集功可以?為何在它下面建立概要檔案後,在控制台系統管理中沒有添加節點項?
沒有叢集;base版就一個app server,不支援添加node
資料中心怎搭建叢集檔案系統
希望這能讓你們對這類技術有一個初步的認識,以便更好地滿足高使用率儲存的需求。 建立叢集和使用率高的資料存放區解決方案有很多選擇,但是要想弄清每種選擇的優劣則要花點時間進行研究。儲存架構和檔案系統的選擇至關重要,因為大部分的儲存解決方案都有嚴格的限制條件,需要仔細設計工作環境。 基礎架構 有些讀者也許希望裝配一組可以並行訪問同一個檔案系統的伺服器,而另一些讀者可能想複製儲存空間並提供並行訪問和冗餘。有兩種方法可以實現多伺服器訪問同一個磁碟,一種方法是讓那些伺服器都可以看到那個磁碟,另一種方法則是通過複製。 共用磁碟結構在光纖通道SAN和iSCSI領域是最常見的結構。配置儲存系統相當簡單,這樣多個伺服器就可以看到同一個邏輯塊裝置或LUN,但是如果沒有群集檔案系統,那麼當多個伺服器同時想使用那個邏輯塊裝置時就會出現混亂。這個問題與使用群集檔案系統有關,我們將在下文中詳細介紹。 一般而言,共用磁碟系統有個弱點,那就是儲存系統。但是情況也並非總是如此,因為利用現在的技術是很難理解共用盤的概念的。SAN、NAS裝置和基於Linux系統的商品硬體可以將所有的基礎磁碟即時複製到另一個儲存節點,從而提供一個類比共用盤環境。基礎模組裝置被複製之後,那些節點就可以訪問相同的資料,也可以運行同一個群集檔案系統了,但是這種複製超出了傳統共用盤的定義。 相反,不共用才是共用盤的問題所在。串連著不同存放裝置的節點會在每個模組被寫入資料時將變化通知給主伺服器。現在,不共用架構仍存在於Hadoop那樣的檔案系統之中,那些檔案系統可以在許多節點故意建立多個資料副本,從而提高效能和冗餘。而且,在不同存放裝置或節點之間利用自己的存放裝置進行複製的群集也可以做到不共用。 設計選擇 正如我們所說的,你不能通過多個伺服器訪問同一個模組裝置。你聽說過檔案系統鎖定,因此普通的檔案系統並不能實現這一點就有些奇怪了。 在檔案系統層級上,檔案系統本身會將檔案鎖定以保證資料不會出錯。但是在作業系統層級上,檔案系統啟動程式完全可以訪問基礎模組裝置,它們可以在基層模組裝置之間自由的漫遊。大部分檔案系統都會認為它們被分配了一個模組裝置,而且那個模組裝置也只是它們自己所有。 為瞭解決這個問題,叢集檔案系統採用了一種並行控制機制。有些叢集檔案系統將把中繼資料儲存在共用裝置的一個分區裡,另一些叢集檔案系統則會使用集中式中繼資料服務器來儲存中繼資料。不管採用哪種方案,叢集中的所有節點都可以看到檔案系統的狀態,從而保證安全的並行訪問。然而,如果你想保證系統的高利用率和消除單點故障問題,那麼採用集中式中繼資料服務器的解決方案就要略遜一籌了。 另一個注意事項:叢集檔案系統要求在節點發生故障時迅速做出反應。如果某個節點寫入錯誤資料或由於某種原因停止關於中繼資料變化的通訊,其他節點必須能夠將它隔離出去。隔離可以通過多種方式來實現,最常用的方法是利用斷電管理來實現。