首先, 對測試或開發環境而言, 一個Method Server是最常見的, 因為資源通常不如Production來的充足. 例如, 測試或開發環境的RAM通常有個4G可能就偷笑了, 上面又要裝一個更兇的Oracle, 能分給一個Method Server 1.5G的RAM通常就不錯了. 但是, Production則不然! 一來, RAM可能更多. 二來, 通常Production至少由二台機器組成: 一台負責Application, 一台負責Database. 如此一來, 只有一個Method server 是否太可惜了? 更何況, 就Albert手上的資料顯示, 好像某版本之前, Sun的Java Virtual Machine在MS Windows上, 一個JVM Process只能用到1.5G, 超過的部分就用不到. 我想, 這個血淋淋的事實大概能包含PTC在台灣九成的各戶. 所以要養頭猛虎是不可能了, 試試猴群吧...
正巧, Windchill本來就考慮了猴園的架構, ServerManager就是那個耍猴的.
Windchill 裏就有這麼個property: "wt.manager.monitor.start.MethodServer" 用以告知系統要啟動幾個MethodServer, 預設值是1. 所以我們想要2個Method Server, 自然就設成2, 依此類推. 但是有實際維護Windchill系統經驗的人早就知道不能這麼幹. 正確的說, 不能只是設這個Property.
再繼續討論之前, 我們得先了解MethodServer做些什麼? Method server 可以想成是一堆"Method"(Java Method)的集合, 以Java RMI實作, 可供遠端呼叫 , 例如透過Apache與Tomcat, 來自瀏覽器端使用者的指令. 另外, Method server還有一個重要的功能, 也就是處理Queue裡面排隊的工作: 例如工作流程的Robot, Activity裡的Transistions... 都是Method server 先將它們加到 Queue裏, 再一個個拿出來執行.
設定多個Method Servers後, 當系統處理大量來自使用者端的需求時, 效益較明顯. 但是Queue裏的工作呢? 當只有一個Method Server時, 問題不大(這是風涼話...), 因為..嘿嘿嘿...什麼都歸他! 但是, 當有兩個? 那Queue裏的工作怎麼分? 不然同一個工作都執行兩次, 那絕對不是恐怖可以形容的... 所以, 就有了Background Server這個東西. 以程式碼的角度, 它就是Method Server(一樣是由wt.method.MethodServerMain 啟動). 但是它只處理Queue, 不處理 RMI requests. 另外, 還有一個property "wt.queue.executeQueues" 用來告訴所有Method server 要不要碰Queue. 所以, 為了解決爭搶Queue裏工作的問題, 只要超過一個Method Server, wt.queue.executeQueues就須設為 "false". 這表示Queue不干MethodServer的事, 通通交給 Background Server吧!
但是Background server的設定很詭異, 首先, 要設定這個玩意兒: "wt.manager.monitor.start.BackgroundMethodServer". 與wt.manager.monitor.start.MethodServer類似, 一樣是用來表示數量, 也就是要啟動幾個Background server. 大多時候, 我們看到是 "1" 或 "0". 但是, 如果只是"有"與"沒有", "true/false"不是更妥當嗎? 兩個BackgroundServer難道就不會爭搶Queue裏的工作?
所以1或0聽來是合理的數值. 但是, 難道所有的流程與所有Queue裏的工作都須要靠一個最多不超過1.5G的JVM來拖嗎? 所以, 我們可以很合理的懷疑wt.manager.monitor.start.BackgroundMethodServer 定義成">=0"的數字是有道理的. 多個Background Servers的需求有其正當性.
在System Admin Guide 中 提到了Queue-Group的概念. 也就是說系統所有的Queues可以分成幾個群組. 系統安裝之初 所有的Queues都屬於一個叫"default"的群組. 管理員可利用定義在wt.properties中的"wt.queue.queueGroup"這個property來新增群組, 並利用設定Property: "wt.queue.(property name)=" 的方式重新分組. 但是為什麼要分組呢? 從 System Admin Guide 中有關Queue-Group語焉不詳的描述, 似乎暗示一種可能: BackgroundServer可以指定負責的Queue-Group.
wt.manager.monitor.start.BackgroundMethodServer=1
wt.queue.queueGroup.default=appsvr1
wt.queue.queueGroup=localhost
wt.queue.xxx=appsvr2
wt.queue.yyy=appsvr2
wt.queue.zzz=appsvr3
上 述設定基本上在每一台主機的wt.properties裡都是一樣. "localhost"是合法的關鍵字, 而在各台主機上用"wt.queue.queueGroup=localhost"將會產生"appsvr1, appsvr2, 與appsvr3"三個Queue-Group. 但是, 由於此範例是用在Cluster的環境, 感覺上一台機器上只能設一個Background, 真是令人沮喪! 路似乎絕了?
巧的是, 設定多個Method Server這個主題時還牽涉另一個選項: 就是為個別Method server與Background Server設定Log檔. 在尋找資料時意外發現下列屬性:
wt.manager.cmd.BackgroundMethodServer=$(wt.manager.cmd.MethodServer) wt.method.serviceName\=BackgroundMethodServer wt.queue.executeQueues\=true wt.queue.queueGroup\=default wt.adapter.enabled\=false wt.method.minPort\=3000
這個東西要讓我說, 怎麼看都像是指定Background Server負責處理"default"這個queue-group. 這彷彿是山窮水盡後的柳暗花明. 但是高興沒多久, 問題又來了!!! 當我有兩個Background Servers時, 我怎麼讓系統知道每個Background Server需要個別的啟動指令? 無法個別設定啟動指令, 我怎麼讓不同的Background Server處理不同的queue呢?
其實這是非常接近答案的一次探索. 但是萬萬沒想到會栽在一個看似無辜, 理所當然的設定: "wt.manager.monitor.services=MethodServer BackgroundMethodServer", 終究沒辦法再向前跨一步.
沒有留言:
張貼留言