WebSphere 反向投資者: 解決 WebSphere Application Server 的配置衝突

Tom Alcott, IT 諮詢專家, IBM Software Group, Worldwide Sales

簡介： 任何時候，只要 IBM® WebSphere® Application Sever cell 有多個管理員，就會有管理操作相互衝突的可能性。WebSphere 反向投資者的這一期文章討論瞭如何檢測和解決相互衝突的配置更改。本文來自於 IBM WebSphere Developer Technical Journal 中文版。

在每篇專欄文章中，WebSphere® 反向投資者將回答問題、提供指導並討論與 WebSphere 產品使用相關的基礎主題，經常會給出與流行的看法相悖的經過實踐驗證的建議。

配置療法

讓我先來向您解釋一下，儘管我在本專欄的標題中使用了 “解決衝突” 的字樣，但我並沒有改變職業，而投身於調停或有關的行業。此外，雖然有關各種 WebSphere Application Server 主題的討論可能會導致所謂的 “精神辯論”，但本專欄並不想涉及如何解決可導致這類辯論的觀點的根本差異。相反，這裡的焦點是如何檢測和解決因並行更新 WebSphere Application Server 配置而產生的 WebSphere Application Server 配置衝突。

過去，我曾寫過一個專欄，這個專欄討論瞭如何加速 WebSphere Application Server 內的應用程式部署，以避免在系統維護視窗期間進行並行應用程式部署的需求 — 而這會導致本專欄主題內所指的這類衝突。並且，在上一篇 WebSphere 反向投資者文章中，我推薦使用一個用於執行維護的雙 cell 方法 — 軟體和硬體 — 作為最小化甚至消除維護視窗中斷的機制。我之前提到的兩種方法仍然是在一個給定的時間框架內執行應用程式維護的建議方法，如果出於某種原因，您發現一個或兩個或多個選項不適合您的具體環境，那麼您可以將並行應用程式部署用作另外一個選項，具體步驟在本文中會給出。

在深入探究具體的過程之前，讓我們先來簡要討論一下 WebSphere Application Server 提供的用於阻止配置衝突的嵌入功能。

每當有使用者登入到一個管理員客戶端（admin 控制檯或 wsadmin）時，就會用一個不同的工作空間會話來跟蹤變化。與每個工作空間相對應的是一個用於儲存此使用者接觸過的所有檔案的臨時目錄。此工作空間內的檔案最初提取自 WebSphere Application Server 單元配置儲存庫並且此使用者所做的所有更改都只反映在工作空間的副本，直到發生一次儲存。當儲存發生時，WebSphere Application Server 配置管理執行時會將來自此工作空間的已更改檔案複製回這個主儲存庫，但首先會進行檢查以確保已更改檔案沒有被另一個工作空間會話修改或儲存過。只要兩個工作空間會話修改了不同的檔案，就不會有儲存衝突。當有衝突時，只有第一個工作空間會話的更改會反映在 WebSphere Application Server 單元配置儲存庫中，而具有衝突文件的後續會話則會在儲存期間收到一個儲存衝突異常。在一個具有多使用者的共享環境中，雖然總是可以讀取這個配置，但是如果另一個工作空間會話試圖儲存已經由第一個工作空間修改的相同的檔案時，那麼儲存這個工作空間會話可能不會成功。

對於應用程式部署，為了支援應用程式的併發部署，對其進行了一個特殊配置。由不同的工作空間會話初始化的應用程式部署可以修改相同的 serverindex.xml 檔案，在這種情況下，WebSphere Application Server 配置管理執行時為 serverindex.xml 檔案採用了一個合併演算法，它支援：

向不同的應用程式伺服器或不同的應用程式伺服器群集併發部署不同的應用程式。
向相同的應用程式伺服器或相同的應用程式伺服器群集併發部署不同的應用程式。

結果，大多數典型的併發或並行應用程式部署場景都可安全執行，無需系統管理員方面的任何額外努力。不過，還有其他的應用程式部署場景（比如向相同的應用程式、相同的群集或伺服器的併發部署，目前尚不能由 serverindex.xml 合併演算法處理）以及其他的併發管理動作涉及的不只是應用程式部署，因此有可能發生配置衝突。有一些簡單的措施可用來確保不會有配置衝突併為一些受支援的場景或在使用 wsadmin 時的其他一些場景解決所有衝突。

為配置衝突檢測和解決所採用的 wsadmin 命令依賴於獲得對 ConfigService MBean 的引用，然後呼叫由該 MBean 提供的 getConflictDocuments 方法來決定是否有相互衝突的變更發生自另一個管理會話。

獲得所需物件引用以及構造此呼叫所需的引數列表的步驟如清單 1 所示。

清單 1

				
// get ConfigService MBean reference

wsadmin>cs = AdminControl.queryNames('WebSphere:*,type=ConfigService')

// obtain ObjectName for ConfigService MBean

wsadmin>import javax.management as mgmt

wsadmin>csName=mgmt.ObjectName(cs)

// get session object for the current administrative user session 

wsadmin>session=AdminConfig.getCurrentSession()

// manipulate and prepare the administrative session object and 

// MBean operation arguments for use

wsadmin>from com.ibm.websphere.management import Session

wsadmin>from jarray import array

wsadmin>parms=array([session], java.lang.Object)

wsadmin>ptype=array(['com.ibm.websphere.management.Session'], java.lang.String)

如果您熟悉 MBean 方法的呼叫操作的使用，就會奇怪為何使用 invoke_jmx 操作而非呼叫。這是因為呼叫主要用來處理字串且只能管理字串的格式型別。為了使用標準 Java™ 型別陣列和其他的非字串，invoke_jmx 操作就提供了所需的函式。

在初始化變數和引數列表之後，就會呼叫 getConflictDocuments 方法。如果沒有衝突，這個方法返回的結果將如清單 2 所示。否則，如果配置衝突的存在是因為在另一個管理會話中的更改，那麼結果將會如清單 3 所示，它列出了更改了的 XML 檔案。

清單 2

				
// invoke MBean getConflictDocuments method to obtain a list of any document conflicts 

wsadmin>AdminControl.invoke_jmx(csName,'getConflictDocuments', parms, ptype)
{}
wsadmin>

清單 3

				
wsadmin>AdminControl.invoke_jmx(csName,' getConflictDocuments', parms, ptype)
{['cells/ojaiCell01/nodes/ojaiNode01/serverindex.xml',cells/ojaiCell01/applications/
DefaultApplication.ear.ear/deltas/DefaultApplication.ear/delta-1278791909117', 
...  ...} 
	
	wsadmin>

如果發生這種情況，就可以通過 AdminConfig.reset() 呼叫丟棄自上一次 AdminConfig.save() 呼叫後在會話內所做的更改：

wsadmin>AdminConfig.reset()

若在儲存前呼叫 getConflictDocuments 方法後發現沒有衝突文件，這並不能保證儲存一定會成功 — 即便是被立即呼叫 — 因為其他的一些會話有可能在呼叫 getConflictDocuments 與進行實際的儲存這段時間內修改了相同的文件。不過，如果向主儲存庫的儲存不成功，那麼就會出現一個 ConfigServiceException 異常，類似於在更新主儲存庫內的文件時出現的異常，如下所示：

WASX7015E: Exception running command: "AdminConfig.save()"; exception information: com.ibm.websphere.management.exception.ConfigServiceException java.security.PrivilegedActionException: java.security.PrivilegedActionException : com.ibm.ws.sm.workspace.WorkSpaceException: RepositoryException

如果發生這種情況，可以呼叫 getConflictDocuments 方法來決定哪些文件已經由其他會話儲存。然後可以通過呼叫 AdminConfig.reset() 丟棄所做的更改。丟棄後，就可以重新應用您的修改。假設修改相同檔案的併發程度並不很高（多少依賴一點運氣），那麼後續的重試應該會成功，沒有衝突。

結束語

遵循這些步驟能夠幫助您新增所需的函式來檢測由部署多個併發管理動作可能引起的配置衝突，在需要的時候丟棄更新，進而避免配置衝突。

致謝

感謝 Ajay Apte、Michael Cheng、Amy Lin 和 Vish Venkataramappa 為本專欄的準備給予的協助。

原文連結：http://www.ibm.com/developerworks/cn/websphere/techjournal/1007_webcon/1007_webcon.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14789789/viewspace-675110/，如需轉載，請註明出處，否則將追究法律責任。

WebSphere 反向投資者: 解決 WebSphere Application Server 的配置衝突

相關文章