2007年10月17日 星期三

Alchemi:小型 Windows Grid 的 middleware 首選

由於研究內容與 Grid 有所相關,因此之前想用 GT4 或 gLite 去架設 Grid 環境。

不過後來發現,用上面兩個實在是沒必要....

一來這兩個是蠻龐大的 middleware,有的沒的要搞一堆,例如:certificate。

二來研究的重心並不是在 Grid 環境的架設與運作,而是要證明 Grid 是不是可以協助我改善某些工作的處理效率。

再加上最近看了 80/20 相關法則的書,所以.......決定還是找一套輕巧好用的 Grid middleware 就行啦! (其實是我有點懶.....@_@)

之後在 google 發現了 Alchemi,以下是 Alchemi 官方網站的介紹與架構圖:
Alchemi is a .NET grid computing framework that allows you to painlessly aggregate the computing power of intranet and Internet-connected machines into a virtual supercomputer (computational grid) and to develop applications to run on the grid.


乍看之下,哇~號稱 painless 耶! 真的有這麼好嗎?

接著仔細研究了一下,發現他幾乎都把底層的部分做完了,說實在省了 developer 不少的工,因此 developer 只要專注於程式要做什麼就好,不太需要瞭解 job 是怎麼丟出去或是成功回傳....等等太細節的東西;不過基本上還是要瞭解一下在 Grid 環境中程式的寫法,因為跟一般的程式差異頗大。

但說到底,還真是感謝有如此好物出現....讓我省了好多麻煩阿....雖然架構看起來很簡單,不過實在是足夠滿足我研究要做的東西了!

Alchemi 運作的基本概念如下:
  1. 是以 Manager 為中心,由 User 送出 Grid Application
  2. Application 中包含許多 Threads,每個 Thread 有其需要負責的工作,由 Manager 將每個 Thread 送到各 Executor 去執行
  3. 最後由 Executor 回傳處理結果,再由 Manager 整合

上面所介紹的僅僅是基本概念,當然按照此基本概念去寫程式,就會有一些侷限,例如:
  • Thread Job 無法使用非 .NET Framework 所提供的 library (這個真的很麻煩,許多好用的 third party library 就無法使用了)
  • Manager 僅能被動的等待 Executor 回傳處理結果再進行整合 (如此一來無法主導整個程式的運作,也不是很方便)


這是目前所遇見的問題,後來去找教授討論後,他要求程式要修改的更完善,後來思考很久,在原本的運作模式下根本無法達成要求,因此又回來重新仔細翻翻 Alchemi 的文件,發現了一件事情......原來我疏忽了很多東西阿!! 原來 Alchemi 提供了許多我需要的功能.....(此時要再次向作者跪拜....Orz)


當然以上所提只是基本概念,其中 Alchemi 還提供了幾個很重要的功能: (後來仔細翻文件才發現....)
  1. 在 run-time 期間,Application 與 Thread 其實都是可以控制的,Manager 並非只能被動等待 Thread 工作完成。(前提是權限足夠的情況下)
  2. 透過設定 module dependency 後,就可以使用 third party library,如此一來還可以減少 Manager 與 Executor 之間資料的傳輸 (這真是令人振奮的發現!!)
  3. 由於在某些情況下,不能保證剛開始就可以確定所有執行的相關資訊,因此可以在 run-time 期間增加 Thread 到 Application 中

最後,當然也是有美中不足之處,就是目前 Thread 之間沒有辦法作訊息的交換,因此在開發程式時需要注意到有此問題! 因此在 concurrency control 就無法非常精確(不過在大多數情況下,這並無傷大雅....)。

之後預計要推出 Java API,不過目前還沒看到,看樣子作者似乎也很忙,短時間內大概也不會出現吧! 不過沒關係,這套 middleware 基本上還可以算是麻雀雖小,五臟俱全啦!

沒有留言:

張貼留言