這是叢集(clustering),負載平衡(load balancing), 和備援(failover)的功能, 提供了橫向拓展(scaling-out), 同時好幾台主機一起跑, 也可以臨時加主機進來, 關鍵是在交談複製(session replication). 在雲端運算, 系統可以搬移到不同的虛擬主機或主機實體. 現代的ERP的應用程式部份都應該可以做到叢集, 對其資料庫部份就比較複雜了, 牽涉到是用多重主機(multiple masters), 高可用性主機(High Availability), 或單向複製(master-slaves)的作法了. 現代的資料庫也都可以支援.
感謝您的回答,因為您講到了很多關鍵字,請問若我要了解的話,有何相關書籍或者是網路上的資源,可供參考的呢??
另外是,現在很多erp應用程式應都可以做到叢集,可舉幾個產品來供我參考嗎?
現在很多erp應用程式應都可以做到叢集,可舉幾個產品來供我參考嗎
叢集應是系統間的溝通設定問題,與前端執行程式無關...
叢集可分僅伺服器間溝通與整個區域網路的【叢集】...
叢集有共同分配運算的能力,這通常會是超大型的ERP才會用的上,一般中小型的ERP,使用【叢集】可能反而造成資源的浪費。
ERP上Colud??不建議...
太貴而且不會有實質的價值與義意...
共同分配運算的能力
是網格運算(grid computing), 通常用在海量資料或海量運算, 把同一組"程序"分拆給跑不同主機(實體或虛擬)來跑, 再把結果整合.
應用程式端的"叢集", 或"負載平衡"可以被看做是反向代理(reverse proxy), 一般的中小企業都可以用, 也不貴. 舉個2007年的例子:
http://www.openfoundry.org/index.php?option=com_docman&task=doc_download&gid=373&Itemid=112
像我最近在研究的ofbiz.apache.org
https://cwiki.apache.org/confluence/display/OFBIZ/Load+balance+across+multiple+instances+of+OFBiz
或者google: <您要用的ERP> clustering, 例如我上週四去參加的微軟發表會所介紹的Dynamics AX:
google: Dynamics AX clustering
您都可以得到其做法.
我目前在做的案子每一個也都可以做到clustering/load balancing, 用的也不是早期那種一個頭兩個大的叢集設定.
使用VMware中的VMotion技術,可以達到,A機轉B機,服務不中斷,
PS.VMDK需要放到Storage
現在都虛擬化了
你哪邊缺資源,就買那部分資源就好了
你不用管主機在哪?資料在哪?網路什麼架設...
以Cloud來說,可能好幾台主機,好幾個Proxy在跑
對你來說就只給你一組Url入口,你進去管理,部署...感覺就是一台電腦而已
klm2242提到:
最近看了一些Cloud Computing 的東西,有了一點小想法,再請問一下,現在的ERP就只能放單台Server嗎?
我可以資料另外放一個空間,程式的部份,就可能我用幾台電腦下去跑!A Server loading 太高,就會跑到B設備去執行?
目前有這種類似的ERP產品嗎?
貴方 : [現在的ERP就只能放單台Server] 是說 [土產]ERP 嗎?
貴方 : [資料另外放一個空間] ? ERP 負擔最重的是 [資料庫]跟[資料傳輸量]
ERP 最常卡住的是 [資料庫] 統計 或 傳出
..........................
我們目前就是在幫台灣最大電腦廠商
重新改寫原廠 [資料庫] 統計效率
..........................
再一般公司都是用快取裝置暴力解決
..........................
但台灣最大電腦廠商已經用最高等級16顆 CPU 512G RAM....
..........................
因此一定要將原廠[懶散]的寫作方式重整
.................................
我們是 SAP / Oracle 超越原廠的國際團隊
SAP / Oracle 最佳外圍系統
.................................
技術轉移顧問
Albert
Skype: Adempiere/Compiere
畫虎爛的一堆..
ERP!=資料庫..
ERP可大可小...
如果要做統計分析決策...
請囀歷史資料庫去慢慢算
Key單...進交易資料庫
全球企業,行動交易...資料遞送,比你在單一主機幾百顆CPU運算有用
感謝回應
線上先進棑程 [運算]
(統計:未交訂單,未生產工單,未領料工單....)
不適合離線到歷史資料去
都是要線上抓到 Snapshot
才能[運算] (統計:未交訂單,未生產工單,未領料工單....)
....
有些土產ERP 對 [統計][運算] 有很多自認意含...
....
除了感謝你的回應還是感謝
常感恩別人沒敢追上來,讓我們領袖群倫!!!
土產 ERP 都是[畫地自限][自認很厲害][因此一直都很厲害]!!!
這回,我要贊成阿伯大的說法了。
感謝 賽大 蒞臨指導
albertachen提到:
蒞臨指導
嗯哼....
今天, 很高興來到阿伯大的場子, 承蒙阿伯大不棄, 上台來講兩句話...
首先, 阿伯大先進的ERP技術, 實為台灣之光, 連外國ERP大廠都派員前來學習. (鼓掌)
阿伯大在iT邦一直發表ERP相關言論, 雖千萬人, 吾往矣! 多次受到邦友圍剿, 仍堅守ERP陣營領導位置, 實難能可貴....(鼓掌)
可惜, 阿伯大一直對參與iT邦鐵人賽沒興趣, 這實在是邦友們的福氣....>>>>下台一躹躬
重新改寫原廠 [資料庫] 統計效率
再一般公司都是用快取裝置暴力解決
但台灣最大電腦廠商已經用最高等級16顆 CPU 512G RAM....
在資料庫上做scaling-up, 卻稱資料庫快取為暴力, 那512G都沒用來做
快取(caching)? 在資料庫上有scaling-out嗎? 就請說明吧. 只聞樓梯響, 不見人下來.
感謝 bizpro 蒞臨指導
albertachen提到:
52
我們公司(製造業)也買了,鼎X,鉅X的系統,但是庫存準確率,越來越差,因為系統越來越嚴謹,一關卡一關,很多單據卡住,數量越不準,大部份都是人為問題,不管系統多好多強,還是沒用
我們請了(中國生產力中心,自行車A-TEAM,日本JUST-TIME)共同的的建議,就是增加"庶務人員",我們買新系統沒有減少人力,卻要請更多人力,請大家批批理
super747提到:
庫存準確率,越來越差,因為系統越來越嚴謹,一關卡一關,很多單據卡住,數量越不準,
庫存精確率, 越來越差 ==> 是交易過中用了不該用的 如nolock , SET LOCK_TIMEOUT, 影響交易準確度.
一關卡一關,很多單據卡住,數量越不準 ==> 這個是作業SQL效能出現問題, 產生互卡的現象了...
曾看過朋友客戶的 鼎X erp資料庫, 發現許許多多表格沒建叢集索引(尤其是大型表格), 以及索引數量不足, 導致許多作業效能不佳, 而且資料庫僅是預設, 使用久了會出問題; 其實許多軟體商對資料庫維護是2266, 反正剛上線可動就行了, 資料庫維護建議好好找人專業維護, 最好可協助你們做資料庫系統設定, 檔案配置, 索引調整及SQL調校.
charmmih提到:
索引數量不足
指一些單據編號, 商品編號, 日期, 這些在SQL上有決定性影響的欄位該建未建.
super747提到:
我們公司(製造業)也買了,鼎X,鉅X的系統,但是庫存準確率,越來越差,因為系統越來越嚴謹,一關卡一關,很多單據卡住,數量越不準,大部份都是人為問題,不管系統多好多強,還是沒用
我們請了(中國生產力中心,自行車A-TEAM,日本JUST-TIME)共同的的建議,就是增加"庶務人員"...(恕刪)
庫存準確率,越來越差==> 來自[交易單據] 與 [計畫單據] 層層關卡
已入庫,才能出貨....
多次加工前工站,領料入庫後,下一工站才能領用....
多次加工後如果要退回就會更複雜...
這就是 [用人工] 幫電腦補資料的後果...
這我們都是用 [自動產生] 所有底稿方式去追蹤...
我們一直尊守上級指示(未領料先發料、未發完料就報工、未報工先入庫、未入庫先出貨)所以單據常常卡住,我們是接單式生產,量小樣式多;主管及業務只要求準時出貨,庫存不準,是基層員工的人”無能”(老板都這樣認為)
我們的資料量不大,並不是SQL效能問題,我有說明是"人為因素",最近資材主管又升官了,搞不懂連”庫存數量”都搞不定,也可以升官(平均1-2年就榮升)又來個新主管,但庫存越來越不準,我們公司的盤點卡是用EXCEL印在80行紙,因為系統無此功能,我們要印在80行紙,一張印4個品項,ERP廠商開價3萬元,我們不接受,只好我接下,但主管又被記功
super747提到:
我有說明是"人為因素",
瞭解...這確實是身在火坑中...
方法一.
一個好修行的地方, 修鍊系統流程和現實流程中的折衝處理協調能力...
關鍵應是如何請領老闆的尚方寶劍(信賴)進行協調處理....
呵呵...小咖人物就要點點滴滴累積協調能力, 成大咖人物...
方法二.
祈求老闆聘任像 albert大 等級的顧問,
跟著顧問來做折衝協調的工作,
包準功力速速提昇~~
庫存準確率,越來越差==> 來自[交易單據] 與 [計畫單據] 層層關卡
犀利...albert 大實務經驗豐富, 一眼就看出, 呵呵....顧問級的高手...
bizpro提到:
在資料庫上做scaling-up, 卻稱資料庫快取為暴力
首先看一個數據 快取命中率, (Buffer Cache Hit Ratio, BCHR)
BCHR=((LOGIC READS)xdata pages)/((Logic Reads+Physical Reads)x data page)
Logic Reads: Read from Memory(邏輯讀取, 讀自記憶體次數)
Physical Reads: Read from Disk(實體讀取, 讀自磁碟次數)
資料快取, 是提昇Logic Reads ; 例如 900K/1000K=0.9 => 950K/1000K=0.95
SQL調校, 是降低(Logic Reads+Physical Reads); 例如 900K/1000K=0.9 => 92K/100K=0.92
增加資料快取, 是暫時少量舒緩記憶體壓力, 並不是長久之道
進行SQL調校, 降低資料讀取量, 縮短交易時間
以OLTP 記憶體方面:
2G => 4G : 感受明顯
4G => 8G : 稍有感受
8G => 16G : 無感
我家客戶資料庫100G資料量, 記憶體4G, 4Core , 平均CPU使用量不及20%
感謝 charmmih 回應
謝謝蒞臨指教
今天破例要嘉許阿伯大的精神,您才是當之無愧的"鐵"人,雖千萬人吾往矣..
現在windows介面下的ERP,我想大都能支援多台Application Server對應到一台DB Server上. 而若要實現 'A Server loading 太高,就會跑到B設備去執行',其實只要加裝Loading Balance設備, 即可自動去loading較低的Application Server上執行ERP應用程式.