本來這個名稱是不會被刪除的，不過看樣子最近由於管理的學弟們及系上這個維護伺服器的組織要解散了，我想我也不得不搬家。

新的網址將會搬到

http://kiwi-grid.blogspot.com

資料轉移後將會設置好自動轉址，一直會持續到這個名稱被拿走為止，在那之前希望google的搜尋會慢慢抓到新的位置。

為啥要一直「格網」用這個名字呢？或許是對這個名字有點特殊的感情吧，儘管這個名稱現在已經落寞了。但我想我還是會持續地寫相關的文章的。

最近我是在一個休息的狀態。

之前的工作讓我學到很多東西，但也讓我瞭解我並不適合待在那個環境。而身體的損傷來自於精神，當自己的想法無法在工作上實踐時，再加上所處於環境的特殊性，實在是雙重打擊。或許我的年紀，大家都認為是實做性質的，「做就對了，你不要問那樣多」。但我自己卻不是這樣想，我認為我是需要真正去嘗試新東西的，只要給我時間那我一定會想出新的辦法來解決問題。但現實是殘酷的，人人都說好的大公司其實並不會給一個員工那樣大的權限這樣做，而小公司又得顧慮到前瞻性。這幾個月我跑了不少地方和人去談，也遇到了幾間在業界裡很少見的公司，但大家對於我的問題都是我綁著兵役，所以我想我還是先去當兵好了。

經過這樣多年，我依然還是相信真正要發展深入的技術在於瞭解技術的本質，如果不瞭解其本質那終究也只能抄過來用而已。而如今我又瞭解到光有技術不行，也要有目的，需求。或許我接下來該思考的是我到底該從事怎樣的事業，要把我的技術應用在什麼領域上。

根據google analytics，我寫的技術文章每天還有固定平均100次多點閱率，真是謝謝大家。

教學部落格

http://www.wretch.cc/blog/trendnop09

其實我放這個並沒有啥意思，我已經不可能有參賽資格了
但實際上從這個比賽的規劃看起來確實跟以往有所不同
此外竟然還有教學

我只有一個感想，「要比什麼？」
比演算法？比效能？
比應用？比服務設計？
比文件撰寫？比夢想與遠景？

說起來現在很多包裝化，公式化的東西可能在我的眼裡都會解讀成不同的看法。
我還是想要說，學習一個新技術，該學的是這個技術的精髓，本質。
「取之有道」

雲端運算在做啥？想做個Amazon雲端平台該怎麼做？

可是其實培育並不是照本宣科，如果真的十年後要賭在雲端計算上，我想應該深入地討論基本的知識。
而這些知識必須建築在業界的普遍狀況，不然就別做了。

1. 為何你需要Map Reduce，話句話說你可能不太需要？
2. 高效能計算理論，程式如何平行化？為啥會加速？
3. Divide and Conquer 與 Map Reduce 適用的題型
4. 要做一個可以平行擴充的系統需要什麼？如何在Cost / Scale之間取得平衡？
5. 如何有效地管理好硬體或軟體上可能發生的錯誤？
6. 為啥我不能讓用戶來分享我的計算負載，成為真正的雲？

如何將電腦更有效地組合起來變成更好的服務，如何在組合的時候讓電腦去配合你的服務規劃，才是重要的。
不光只是做，而是要思考其本質後，再運用其本質來設計。

所以最近思考過後，上述問題的答案是這樣的方向

1. 為何需要Map Reduce？

我認為，其實並不是所有人都需要用到這個。Map Reduce最典型的兩個誤用是，1. 把Map Reduce當作是另一種Grid，或是聽信Google的廣告台詞以為這是取之不盡用之不竭。2. 把Map Reduce當作是可以解決所有平行化的問題（甚至是資訊問題）的工具。

Map Reduce被設計成依賴在高效能的檔案系統上，在去進行資料分析，轉換，處理的Framework。也就是說，一個很好的鍋子，也需要配上一個不錯的蓋子。如果鍋子不好，蓋子在怎樣好也沒用。如果你確定你的問題是要做大量的資料處理，資料分析，甚至資料探勘，Map Reduce這個蓋子才對你有用。對此我認為現在應該進展到資料處理階段，也就是資料處理語言，這樣才能讓比較低階的Map Reduce能跟前端實做高階資料探勘的人員接上。

但問題是，你願意把錢砸在鍋子上嗎？

2. 為啥需要平行化？

對於控制成本的Project Manager而言，如果說有個東西可以花一定數量的金錢就有等效的成長，那誰不願意呢？例如說，從2核心到4核心，如果更快的話，那我當然買4核心。甚至換個想法，我可不可以要用的時候才加核心呢？

那麼，你就需要讓你的平台擁有平行化的觀念。

平行化的平台擁有的優點，就像是你的電話系統可以同時允許多條線路電話打進來，你可以每一線雇用一個客服人員，或是當你覺得客服品質不好，需要更多客服人員，可以在去加線路，或者雇用人。在平行化的同時，更要允許既有資源的共用。如果這些客服人員都用同一套客服系統，並且定期地彙整資料給高層主管評估績效，那更好了。

如果配置得當，那從一個角度就像是你的系統能夠加速或是擴大。如果客服人員的績效能有個評估的單位叫做「通/小時」而你發現增加當增加硬體的數量，能夠線性地增加這個數字，那表示成本是有效地轉換到績效上。而這個數字的斜率是多少，那還是得看工作的性質了。

對於運算也是如此，大家都是希望能用最少的成本，做到最多的事情。

3. Map Reduce為啥適用這些特定的題型？

Map Reduce能解的問題是一般的Device and Conqure問題，表示如果你的問題能拆解成獨立的小問題，那Map Reduce就能解。所以凡舉字串操作(包括binary)，數值運算(不包括矩陣)都可以。如果你的資料探勘是建築在字串形式的資料上，那就沒問題。

如果你想把未知的問題拿來實做看看，也要確定你的問題不是任何形式的遞迴問題。

此外MapReduce在架構上繼承自Functional programming的性質，mapper與reducer可以管線化，但這個就是視架構上的需求而調整的。

4. 一個可以平行擴充的系統需要什麼硬體條件？

可以想像的是，跟Google當初的初衷一樣，每樣東西要小，簡單，便宜。然後以非常大的數量作螞蟻雄兵。

記得在Google的Paper裡提到，要能夠達到這種計算量，電力是一個大問題。需要多少監控及機房管理的人員又是一個問題。所以有些中小企業，為了「趕快」解決問題，往往會被硬體廠商「晃點」，說他們的東西都不用人管，都可以自動化。

決策者往往弄不清楚自己在面對的是什麼，等到東西買下去才開始頭痛。

所有格網計算或雲端計算的硬體問題，都是「這麼多機器要怎麼管」，因為你的機器只會變多不會變少。當客戶數量成長時，需要更多機器，帶來麻煩的往往是越大台越複雜的機器。到時候管理的成本還是逃避不了。

硬體調整不好，雲端絕對快不了。
這些硬體就包括了管理人員以及電力，網路。

5.  如何有效地管理或防止軟硬體錯誤？

我認為這個問題的解答是在專案管理，以及開發的過程中有沒有在各個環節上符合軟體工程的「精神」。
還沒通過完整測試的東西？何以能上線？
如何將測試自動化？
而硬體錯誤是無法防止的，只能夠說任何Centralized failure point都應該要有備品，連人也是。

6. 我想讓我的使用者也加入雲端計算…

這個大概是最後的問題了，我想一旦成功的話，就是肥了這些廠商吧？
對於使用者來說，原本要花上千塊的軟體，因為他肯加入運算行列，他打了對折(應該要採取使用者越多降價越多的噱頭)，太便宜了。
對於廠商來說，電力機房都省了，他賺得更多。

難度在於：

• Active resource pre-allocated scheduling：這個已經有實做
• Resource classfication：如何確保這些遠端的運算資源用的是最少的IO？

我想一開始如果就將這些想法加入雲端或傳統的格網計算的話，或許有一天真的能走向大家都能貢獻自己的CPU的路吧。

Keynote Speech III

Chair:
Simon C. Lin,
Academia Sinica, TW

Speaker:

“New Resource Provision Paradigms for Grid Infrastructures: Virtualization and Clouds”Ruben Santiago Montero

Distributed System Architecture Group, ES

Virtualization deal with heterogeneity.

Grid Computing & Cloud Computing I

Chair:
Steven Timm,
Fermi Lab, US

Speakers:

“Grids and Clouds: a Comparison”Francois GREY

UNOSAT, CERN, CH

Above the Clouds: A Berkeley View of Cloud Computing
Michael Armbrust, Armando Fox, Rean Griffith, Anthony D. Joseph, Randy Katz,
Andy Konwinski, Gunho Lee, David Patterson, Ariel Rabkin, Ion Stoica, and Matei Zaharia

這是Francois提到的文章

內 容討論到還有另一種分類，就是public cloud與prvate cloud。從這篇文章的觀點覺得public cloud使用便宜的硬體，建立好的服務，以中小型資料中心的成本，還很有可能獲利。而private cloud還是比較像在講自己建立cluster或grid服務來讓自己用。那想當然爾的當然就是當你發現外包比較省的時候就外包吧，但另一點也是要開發 者開始都有使用cloud服務來節省成本的觀念，此外他們也只考量道維運成本而沒考量到開發成本。

總之cloud未來目前還是偏向1. 賣平台(Platform as a service) 2. 賣軟體服務(Software as a service)，這就是賣硬體（包括OS），賣軟體的進化。

“Virtualized Grid on a Virtualized Network—Magrathea, VirtCloud, and SBF”Ludek MATYSKA

CESNET, CZ

MetaCentrum.

介紹了系統架構，使用PBSPro以及自行開發的plugin來schedule vm。

“Impact of Advanced Virtualization Technologies on Grid Computing”Stefan Freitag

Dortmund University of Technology, DE
介紹了虛擬化架構，以及提到比較常在解決的反而是IO問題。

剛剛與David Anderson聊了一下，真難想像他還記得我。我跟他說接下來我的想法就是把P2P的想法套在BOINC上，但似乎他還無法理解我在想啥。

Grid Computing & Cloud Computing II

Chair:
Ludek MATYSKA,
CESNET, CZ

Speakers:

“Virtual Machines, Volunteer Computing and the CernVM Project”Ben SEGAL

CERN, CH

基本上這跟workshop的內容差不多。

Ben提到他們正努力達成VM與Host之間的通訊，我在想他與simon曾經提出的想法一樣，加上輕量化後，這會是一個真正process migration的方法。

另一個觀念是模組化的虛擬機器。

而 我自己還是想要感謝Ben這一次帶給我的震撼，其實這五年來做Grid也好，研究技術也好，但很多人自始至終都在上打轉。而這位始祖也是感受到相同的狀況 了吧，才會開始研究distributed的想法與觀念。如果沒有他告訴我這些，我可能永遠以為這個世界大家都是喜歡蓋巴別塔的。Grid想要解決的是異 質性平台的問題，但這個問題始終沒有解決。如果BOINC有解決，那也是因為programmmer還是乖乖寫了三個平台的程式。所以表示有些事情還是得 做，因為那是本質，不能只是包裝了來唬人，讓大家以為這些努力都不需要做。而需要有人將這些觀念整理起來，來達成更接近未來的目標。

“A Desktop Grid Computing Service for Connect6 Applications”*I-Chen WU

National Chiao Tung University, TW

Kuo-Chan HUANG, National Taichung University, TW

介紹六子棋（連六棋）

介紹他們開發的NCTU6（有平行化），看起來這個程式是跑在BOINC上？

“Elastic Cloud Computing Infrastructures in the Open Cirrus Testbed Implemented via Eucalyptus”Christian Baun

FZK, DE

最主要是介紹Hardware as a service，也就是說他們希望可以整套硬體環境一起賣，可能是主要提供給研究人員或HPC環境。

介紹Eucalyptus，並且比較EC2與他們自己系統的IO(in VM)。

介紹AppScale，這是AppsEngine的open版。

http://www.geclipse.org/

去醫院後發現，我的肺還是感染了，病菌不明（必宣說可能是金黃葡萄球菌）。以前在新竹都不會在這樣，來台北後還真慘啊。

早上Jozsef跟我提到了他希望我們去參加他們的summer school，這真是個好問題啊…

下午跟清大的學長聊很久，其實在台灣真的很難做什麼啊…來做AV@Home或Anime@Home說不定還比較能夠引起廣大鄉民的回應吧，真正做到citizen science…讓大家Always@Home….XD。但不管怎樣說，能夠將計算發散給群眾去做，那不管怎樣就一定先突破第一步了。接下來第二步是將應用軟體導向非科學計算軟體，而是真正能夠貢獻給大眾使用的程式，或許第一個應用就是轉檔吧！

此外，這是本站的第100篇。

http://event.twgrid.org/isgc2009/irods/

09:00 Introduction to iRODS technology (discussion of basic capabilities) (Reagon Moore, University Of North Carolina At Chapel Hill, US)

Reagon把主題基本上都放在與SRB的差異與功能增加上，他甚至提到了將source公開後，他們希望可以接受廣大社群的意見。另一個重點是RuleEngine，之所以需要這個東西，是因為各個不同的site有他們自己的管理方式，如果能夠將這些管理策略（包括權限，資料處理原則，跨zone原則）利用Rule的方式描述並且執行，那會省去很多事情。

iRods在這一版還有另一個重點就是擴充性，核心的許多元件都是模組化，可以讓更多第三方團體開發他們自己想要的模組。他提到他們在Renci DataGrid及NARA所做的成功案例，其中還有資料每傳遞經過一個DataGrid就備份一次的方式，這些例子都是以前SRB做不到的。

Q: 我認為你的軟體好像不是很穩定，究竟SRB發生啥事了呢？那現在你們做了啥來改進？

A: 目前Mike Wan與Raja正主要負責開發，Mike開發了很多不同的技巧來在不穩定的網路中能夠傳輸，而我們也期望社群給我們一些鼓勵與支持。其實從SRB這樣一路過來，我們也學習了很多。

Q: 你在投影片中提到你們可以有10多個iCAT Server進行Federation，但在台灣的例子可能有50~100個不同的單位需要互相整合，這可以做到嗎？

A: 我認為能不能做到並不是在軟體上的問題，而是當這樣多的DataGrid整合在一起，他們就需要制定更完整的Rule來讓這些site之間可以合作，這個答案之前也提過，就是資料處理原則以及認證原則。

Q: 我很好奇執行這些Rule是否有很多的overhead，畢竟有很多檔案，又有很多Rule，那一定也需要很多cpu去跑，而這個機制也無法叢集化，那檔案增加時要怎麼辦呢？

A: 目前我們所附的rule沒有這樣多，所以不可能有太大的overhead。

Q: 我該怎樣才能將SRB的資料搬移到iRods上？

A: 最簡單的方式是將所有資料倒出來然後再匯入，而我們有一些script來檢查metadata的一致性，如此不管是怎樣的資料都可以利用這種方式遷移。

大家覺得他有正面回答到問題嗎？我覺得沒有，更何況有些問題是我私下問的（例如第一個問題）。

10:00 Open discussion with workshop participants on their data management needs (Reagon Moore, University Of North Carolina At Chapel Hill, US)

10:30 ASGC presentation (Wei-Long Ueng, ASGC, TW)

維瓏介紹了有關我們在Carbon Flux上打算使用iRods（其實是尚未使用），以及之前數位典藏使用SRB的狀況，但我也覺得我們並沒有任何一個計畫真正用到iRods吧。

11:00 Installation of iRODS clients on participant systems (Windows, Mac, Linux) (Reagon Moore, University Of North Carolina At Chapel Hill, US)

我發現他們將安裝的script寫得非常完整，但安裝iCAT還是得乖乖配合他們的postgresql版本。

課程快要結束的時候我們發現yellow這台server掛了，但問題不是出在網路斷線或什麼其他問題，這台server的irods port還是開啟的，應該是irods內部的thread或icat被我們玩壞了。

12:00 Initial demonstration of iRODS client access (Reagon Moore, University Of North Carolina At Chapel Hill, US)

Q: 看起來你提到的parallel I/O並不是真正的平行化IO，這個是multistream。你有打算要加入這個功能嗎？

A: 你可以自己撰寫micro-service，那不管是怎樣的IO你都可以達成。但我認為Resource斷線的時候，該怎樣去偵測，是比較困難的問題。

Q: Resource的剩餘空間可以偵測嗎？

A: 這個我們還在進行

Q: 你有加密的功能嗎？Resource的管理員有權限可以看到本機的檔案，那我該怎樣防止他看？

A: 有一個團隊正在實驗通訊上的加密，透過這個方式就可以減少資料被竊取的機會。（他或許誤會意思了）

14:00 Introduction to iRODS rules and micro-services (Reagon Moore, University Of North Carolina At Chapel Hill, US)

透過簡單的指令可以將zone加入自己的zone，不過本機也要建立與對方的zone相同的帳號，如此對方才能使用我們自己的resource來存檔案。也可以改寫rule讓建立新的zone的時候就將帳號建立。

15:00 Demonstration of federation of data grids (Reagon Moore, University Of North Carolina At Chapel Hill, US)

16:00 Demonstration of WebDav interface to iRODS (Shunde Zhang, Australian Research Collaboration Service (ARCS), AU)

http://projects.arcs.org.au/trac/davis/wiki

Davis是一個iRods的WebDAV Gateway，在很多平台都有WebDAV的client，他也展示了從iPhone上連接iRods並且下載投影片。

ARCS提供了一些檔案服務，所以他們希望使用iRODS作為其平台。

http://projects.arcs.org.au/trac/systems/wiki/DataServices/iRODS

這裡也提到一些資訊，有關如何使用PgPool當做iCAT的備援機制。

16:30 Discussion of KEK use and evaluation of iRODS (Yoshimi Iida, KEK, JP)

這個講者就像日本的小機器人講著不流利的英文一樣，一個字一個字講，但可以看出他的努力。

KEK是日本的大學共同利用機關法人，看起來他們似乎也想整合各個site的儲存資源。

不過目前看起來他們的實作還在調查階段，他們應該沒有太多的資料整合與儲存經驗。他說他們之前是打算用EGEE的GridFtp來做，但似乎失敗了（本來就不適合）。他的老闆還說這個人是他們那邊最聰明的人，看起來他是很努力的樣子。

這邊記錄了兩個問題，不過是講者對Reagon提出的。

Q: 我不是很清楚為啥iget，scp和kerberos-ftp會有這樣的傳輸差距(10MB/s)，你可以解釋一下嗎？

A: iget並沒有作家密，所以比較快。

Q: 為啥collection增加越來越多，效能就越來越慢呢？

A: 這個問題目前沒有任何官方的答案，不過似乎林務所的人也有同樣的問題，看起來當collection或檔案的數量增多，SRB或iRods都會出現這種現象。
但我們還需要更多實驗來驗證並解決。

17:00 Open discussion of iRODS applications (Reagon Moore, University Of North Carolina At Chapel Hill, US)

詳細的資料可以參考：

http://event.twgrid.org/isgc2009/

10:00 Hands-on exercise: Familiarization with the BOINC client Danial

其實用西班牙文我真的看不太懂，Francois希望我找機會介紹一下中文環境。但這件事情後來沒有成功，每個人多講一點時間就不夠了。

11:00 Case study 1: Africa@home Christian PELLEGRINI, University of Geneva, CH

他的簡報介紹了非洲的報紙，表示publicity相當重要。他們也舉辦了Workshop，來讓學生能參與。我覺得最重要的是，他們對學生的態度應該是一同參與，而並不是真正要求大家都要貢獻什麼。

他提到一點Stardust@home，也包含BOSSA of BOINC, Distributed thinking

11:30 Case study 2: LHC@home Ben SEGAL, CERN, CH

這個主題對我們還挺重要，最主要是包含了與VM的協同作業。Cern最主要用的是VMWare，理論上應該是只能使用Player而已，而且應該最早的平台是Linux。Ben介紹了使用BOINC client wrapper來呼叫VMWare Player的方法。

這個分作兩個部分來說，第一個部分是應用程式相依的函式庫要怎樣取得，另一個部分是vm該放在哪。

除了使用JeOS當做底層使用的OS以外，他有提到使用AFS來掛載共用的函式庫，以及使用rPath與rBuilder建立自己的相依套件，這個就像是Virtual Module一樣。

我們談到了到底一個映像檔可以多小？如果使用JeOS的話，Ben說可以到100MB。但後來我跟正欣分析了一下，那個就是他初次下載的大小，還不包括後來他利用rPath下載回來的套件大小。

另一個部分是提到他們時做了自己的HTTP Based FileSystem，叫做CernVMFS，其實我想這個跟我的想法是差不多的。

最後一個部分是提到如何利用VMWare VIX API來取得並且控制VM內部的資料，那就像把Job送進VM裡一樣。

12:30 午餐時間

Ben 跟我聊了很久，他說他是將tcp/ip帶進去CERN的人，而且看起來他應該跟Tim Burners Lee很熟（事實上他就是Tim的老師），他說Web is a miracle。這個人就像非常有智慧的老爺爺一樣，每一句話都妙語如珠，其實我想他長久這樣看著Web，Grid的長進，一定對這種狀況既無奈又煩惱。 他提到學術界以及很多有政治角力的地方，都有所謂的倒三角形權力分布，一堆沒有實質意義的Manager在說著他們如何地將某件工作做得多好，每個人講的 重點都不一樣，但底層開發人員實際上只有四到六個。無論如何，盡量避免顛倒三角形的狀況出現。

我提出一些問題例如像是需要Autodock for BOINC，大家聚在我身邊幫我想辦法，讓我很感動。忽然Jousef跳出來說他們有改好的autodock，看起來似乎有機會解決。明天他們說吳博士會過來，他們要一起討論如何真正地去做Disease@Asia。

14:00 Introduction to the BOINC software David ANDERSON, U.C. Berkeley Space Sciences Laboratory, USA

David有提到Seti@Home有20台以上的Server，看起來由簡單架構組成的東西很容易擴充。

有 關計算結果驗證，實際上這個道理也有很多人發現。如果你想要確定一個詞的解釋，例如說像是「你很機車」，那是因為大家習慣把這個詞當做罵人很笨很討厭的形 容詞，因此這個詞開始有另一種意義。因此很多時候我們必須將計算多跑幾次，來觀察大家跑的結果有怎樣的誤差，這個誤差是不是在自己的容忍範圍內，甚至藉此 發現自己的計算在某些平台還有問題，而並不是堅持只有在某些情況下自己的機器算出來的答案才是對的。我認為一般的Validation就是這個意義，多跑 幾次，就知道答案那個是對的。

我跟信言去找David，確認了在BOINC上確實要靠著application特定的確認方 式，或是特定的技巧來進行驗證。我並不認為這可以靠著任何IT技術達到這件事情，仔細思考會發現事情的本質還是得回歸到問題本身。這也是為啥David有 點無所適從，不知道該怎樣回答這問題，因為並不是每個computer science的研究人員都知道該怎樣去搭配到其他的研究上。所以其實對於科學計算來說，我認為還是那個初衷，「不要將所有事情都用同一種方式來解」。 David解釋說，Security的問題在這種情況下是無解的，因為每個client的狀況都不一樣，花時間在加解密上的時間成本，那不如好好地去看看 自己所需要的答案是不是有解出來。

Grid長久以來一直是用Tightly coupled的觀念在解決事情，但實際上也有人用Loosely coupled的觀念在解決，聚沙城塔。我想我們該去問的是「有沒有效，值不值得」而不是一直將過去的作法強加在新的觀念上，去問對方說「為什麼你沒有用 以前我們用過的方法」。

15:30 Hands-on exercise: Creating a BOINC project, Nicolas

在Francois的解釋下，我們大概看了有關BoincStat的一些情況。如果我們要發起台灣的Boinc運動，首先我們得先找到這些人，跟他們合作，而不是想辦法買機器幹掉他們。

disable server_status caching in the php code.

check log file.

bin/show_shmem

台灣的團隊

http://tw.boincstats.com/stats/boinc_team_stats.php?pr=bo&st=0&or=&co=34

台灣的使用者

http://tw.boincstats.com/stats/boinc_user_stats.php?pr=bo&st=0&co=34

晚宴：福華飯店

其實我跟Francois談了一下有關效能的問題，剛好中間夾著Jozsef。這個人也不太同意boinc的效能問題。但Francois後來就先吃他的杏仁豆腐了，沒太理我們兩個，他說我可以跟David討論這問題。

晚 餐結束後，Christian, Nicolas, Jousef搭我的車回中研院。Christian與他的老婆似乎有打算要退休了，他們討論了另一個人叫做Tom，似乎是他們共同認識的人。此外我一直發 現Nicolas是個非常有禮貌的人，那種感覺像是真正的英國紳士。

10:30 EDGeS: Interconnecting Desktop and Service Grids Peter KACSUK & Jozsef KOVACS, MTA SZTAKI, HU

其實並不是說Jozsef他們做的成果不好，儘管對於Ben的問題Jozsef也並沒有直接回答，但我想我還是會好奇地在信件中提出。我想從他們的經驗去描述，想要完成一件事情不僅是設定目標，想要成功還有很多方法。如果沒有既定的規劃，預期的成果，將資源投入，那或許怎樣也只不過是嘴砲。EDGeS展示了如何花時間慢慢地招集許多學校來進行Volunteer的參與，這個目標是的問題就是在需要人力與時間去跑。Jozsef有提到他們也有提供幫助人將 Application轉成可以在boinc上跑的…想想看這需要多大的team來做這樣的事啊！

但是比較負面的評論，我還是想要強調在這個階段我理解到，如果我想做一件大家都會嚇一跳的事情，真的想要衝第一，那我一定不會去做人家做過的。這個也是我想要去對上層反應的事，從EDGeS的例子可以看見，其實他們不斷地包裝他人的成果，他們發展出很多規格介面，但是最後Ben還是對他提出這個問題「你解決了平台的問題，可是你沒有解決程式的問題，你可能產生了更多的問題」。那我們該怎樣去解決那樣多的問題？還是得靠真正對問題的研究，以及研究成果的擴展。這個我想不是一天兩天的事情，如果兩組人馬都有相同的時間與資源，我相信會是了解本質的那組人馬成功，而並非只是想要包裝他人的東西的那組成功。

而包裝他人的成果的那組人馬，如果真的要能夠推廣他人的東西，那也只不過是強迫他人將程式改成自己的想法罷了。

11:30 Demo

在Jozsef demo之前，Francois拿了自己的MAC出來播放一段FoldIt的短片，簡介了這個從rosetta@home計畫裡出來的好玩東西。透過許多對蛋白質的操作，有許多人正嘗試去找到最低能量，並且累積積分。

Jozsef的Demo其實並不是很順利。在他們的Demo我們只是看見了很典型的操作介面及狀態顯示，我們並沒有見到非常前衛的觀念或是成果。

他有提到他們寫了一個GenWrapper來包裝BOINC的程式，他們認為BOINC的程式不好用，無法符合他們的使用者需求，這個話才剛講出來我就看到Ben想要說點什麼。他們變成只是單純透過BOINC好安裝的特性來取得運算節點，但他們的觀念越做越像Grid，是Tightliy coupled。

他們討論到Workflow，Ben對於真正Large scaled的環境，job是不是像他講的一定會回來感到相當地懷疑。其實EDGeS已經相當龐大了，如果真的每件事情都是緊緊相依，沒有任何的誤差，那是不可能的。所以在他們的環境上實作Workflow就不會有太大的意義。

但這讓我開始覺得漏斗狀的服務還是可行。

13:30 BOINC and Cloud Computing Derrick Kondo, INRIA, FR

我們昨天還在跟Derrick聊說，他很像李連杰，真的很妙！他講的這個主題同樣地也是非常重要。

Derrick給了我們非常詳盡的分析，我想這一點我也非常需要學習。儘管只是一個小小的斜線，可是可以讓人感受到確實有這回事發生。儘管VM Cloud與BOINC都有他們的overhead，但是比較起來「2.8 volunteer => 1 cloud node」還是一個不錯的數字，這個只是一個BOINC計畫的分析，他認為如果全部加起來可能會更好。在這個解說中我逐漸了解到我已經不需要去問David有關效能的問題。

但真正進入實際的數據前，Derrick提到到底有啥計畫需要多少資源，這是有個既有的表格可以參考：

http://www.boinc-wiki.info/Catalog_of_BOINC_Powered_Projects

每個計畫，每個計算需要的量都不一樣。這個表告訴我們，我們設計的程式大概會需要多少天(deadline)才會有結果，或者是如果超出計算的天數，就該結束了。但很可惜的是，這裡並沒有Docking@Home的計畫，也沒有任何有關autodock的資料，我想我們還是得聯絡這個計畫的成員來獲取更多的經驗。

從Derrick的資料來看，boinc真的很省錢，但Francois也在最後問了一個問題有關節能的問題，其實我想他知道這省錢是因為錢都是花在這些參與的人身上吧，畢竟是「Volunteer」啊！當然目前不管是Derrick或者是誰都是沒有任何辦法的，只能夠說花了別人的錢就好好用吧！

討論完Client的效益後，我們要討論Server的使用效益。看起來就是付給Amazon EC2一些錢，然後將BOINC Server放在上面吧，看起來是省了點錢。當然Simon也有想到，或許我們可以找到其他公開的VM Cloud服務，那這樣或許合作後真的可以省下不少錢。

接著Derrick大概有半小時的Demo，但很可惜的也是失敗一半，詳細過程他提供在這：

http://boinc.berkeley.edu/trac/wiki/CloudServer

http://boinc.berkeley.edu/trac/wiki/VmServer

12:30 午餐時間

這個部分大概跟靖雅聊到BOINC的一些觀念，但事實上我也認為他是在思考沒錯，而不是單純地聽誰講究相信什麼。所以其實沒有以前學習過東西的包袱，還比較好學習新的東西。

14:30 Volunteer Thinking and Bossa David ANDERSON, U.C. Berkeley Space Sciences Laboratory, USA

David先提到了BOINC其實有Volunteer組成的Skype Help

http://boinc.berkeley.edu/help.php

http://boinc.berkeley.edu/trac/wiki/BoltIntro

這讓我想起五年前我看攻殼機動隊，有關他們如何將全國的電話聲音分析，灑到正在打彈珠台的老人腦袋裡進行分析。但從那一天開始我就認為，將既有的運算轉換為遊戲，本來就是可能的。但這個重點在於說，遊戲不是為了解題，如果要解題，那不如用人工智慧演算法會更快。遊戲是為了找到「不可能的路徑」，也就是電腦的盲點，很多東西是只有人類才做得出來的。

我講這個想法告訴了David，看起來他相當同意，並且問我說為啥不去國外讀博士。

我不是不想，只是現在還不是時候。

15:15 Case Study 5: Africa Map Ana Gago Da SILVA, UNOSAT, CH

看起來他們利用Bossa提出的觀念，讓人類用看的去將地圖做切割，不過這要做多久呢？

在我換了工作環境之後，我逐漸了解到科學與計算之間的關係。

從以前沒有email的時代大家寄信，直到出現了SMTP及POP3來模擬郵局及郵差的方式來寄信；從還在用打字機打字的時代，直到Word文件，在到線上的Word文件，都顯示出數位化（E化，電子化）是一定的趨勢。當然並不是所有事物數位化都是好事，但至少在工業上，科技上，數位化後的資料以及資訊技術能夠有效地提升效率。

也因此儘管資訊科技在人文上，社會上可能幫不太上忙，但至少E化後的資料也加速了他們傳遞資訊的方便度。

我現在還不太敢說真正了解科學，也因此不敢在部落格上大放闕詞。但至少以我最近能了解到的，例如生物資訊，也還是存在著資訊永遠也幫不上忙的狀態。而另一部分做Docking或者是Protein Analysis的，也總是得在資訊領域的方面提出他們的研究一定有幫助。所以我總是會在我的工作領域聽到，有些人說資訊只能幫小忙；但有一部分的人總是會說他們非常缺資訊人員，而且需要會兩方面的人。

最後，我也開始與ericsk一樣覺得，資訊系是來幫助人的。如果你會資訊技術，而且還有心學習其他領域的話，一定是對自己的將來，以及他人有非常大的幫助。例如資工系，那千萬不要想說只要會寫程式就很強，你還得學習資管系在學的軟體工程，需求分析（其實資工系是選修），才能真正幫助想要寫好軟體的人。例如資管系，千萬別想說光靠理解架構或專案管理就能夠掌握事情，你得了解資工系在學習的計算機結構，資料結構，演算法，才能真正掌握資訊技術的本質，讓你的專案不會人云亦云地誤用資訊技術。

而熟悉這些科系領域的人，就要好好去學習其他領域，如物理，生物，管理科學…等，這樣就可以幫助更多人。

Google AppEngine的好處我們都曉得，尤其對於應用的角度來說，無非就是可以讓很多有想法的網路創業族群能夠以極少的成本自行開發軟體並且供人使用。但從學術角度及高效能計算的觀點，Google的運算資源極為龐大，如果只是單拿來跑應用程式，有點可惜。

於是有了這個HTTPMR。

http://code.google.com/p/httpmr/

介紹

我稍後解說一下一個簡單的範例，先簡介一下MapReduce。

如同我在MapReduce是開技術倒車？所提及的一樣：

MapRedurce是一個parallel data processing framework，根據程式設計師撰寫的Mapper/Reducer Function，搭配合併於framework內的checkpoint技術，而進行平行化的資料分析及處理。

MapReduce其實是支撐Google背後一個重要技術之一。儘管他的作法簡單，但loosily couple能夠達成的可能性，也會在群聚之下發會出很驚人的能量。儘管在學術界對於MapReduce的本質所能做到的也有許多論文爭相討論，但絲毫無法改變這個簡單的技術已經爲Google服務了能以想像的計算量。我在今年初的時候終於回到我的老本行，做高效能計算，也因此MapReduce到底發展成怎樣我也是相當關心。我想未來的運算，應該是要大家互相使用彼此的資源才行，而程式設計師也要更能清楚運算對於資訊領域的價值。

Funcitonal Programming

基本上對於Functional Programming的語言來說，任何function應該要被設計成為管線化(或者也可以說是像filter)。上一個function的輸出，要成回下一個function的輸入。相似的語言如同著名的LISP，及在分散式計算裡會看到的erlang，比較不常見的如F#。這些語言都有一個共同的特徵，就是語法本身具有前接後，上接下的特性。

%% quicksort:quicksort(List)
%% Sort a list of items
-module(quicksort). % This is the file 'quicksort.erl'
-export([quicksort/1]). % A function 'quicksort' with 1 parameter is exported (no type, no name)

quicksort([]) -> []; % If the list [] is empty, return an empty list (nothing to sort)
quicksort([Pivot|Rest]) -> % Compose recursively a list with 'Front'
                           % from 'Rest' and 'Back' from 'Rest'
    quicksort([Front || Front <- Rest, Front < Pivot])
    ++ [Pivot] ++
    quicksort([Back || Back <- Rest, Back >= Pivot]).

上面是一個erlang的quicksort程式，可以看見其極精簡化的語法(從第六行開始才是程式的主體，%是註解)，也就是說一個qsort指需要五行。

管線化的設計，在編譯器的背後，會最佳化成較符合CPU跳躍邏輯的程式，也因此我們可以想像functional programming paradigm的程式語言會較有效能上的優勢。

但另一點這也關係到另一種層面，有某些我們常見的工作，與這種管線化的行為非常相似。在資訊領域的其中一個項目，就叫做「資料處理」。這個並不是指一些高中學習資訊的資料處理科，而是如果有大量資料，如何進行平行化的切割，計算，合併，以便讓資訊研究人員可以直接獲取這些大量資料的總結。相關的領域包括DataGrid，或者是生物，物理，化學等需要計算並求解的領域。而Google使用MapReduce很成功地將它建置成一個大量分析網頁的平台，所以初期MapReduce基本上被利用來跑PageRank。但他們很快就發現合併上一些技巧，MapReduce可以搖身一便成為一個資料儲存的平台，也就是BigTable。BigTable就是現在AppEngine使用作為資料儲存的核心技術。

在GDD2008的時候，我親自問過Pete Koomen(AppEngine的PM)，他們要怎樣讓使用者接受Object-based Storage？有沒有類似像SQL的東西？我得到的答案是"We are working on it, but your know it's very hard"。我想，儘管使用者非常難以理解怎樣在AppEngine的DataStore(BigTable)設計好他們的資料結構，並且得到一定的加速，但AppEngine其他的功能依然非常出色。

使用者並不清楚他們所使用的是資料處理領域的觀念，或是object-base database，column- based database，儘管概念封裝了，但如果將使用者導入致錯誤的觀念，只會更讓他們將來難以接受其本質而使用錯誤，那等到系統擴大(scaled up)了，那就會導致難以想像的災難。所以趕快出書吧！AppEngine！好好教育使用者！(好像有個人已經在寫了？)

Parallel Data Analysis Language

另一方面，在資料處理的領域，也同時地有這個問題。相關領域的程式設計師(例如生物)必須去學習平行處理領域的程式設計方式，直到學成後，又得了解系統的瓶頸所在，來增加計算量。那說真的學這些雜七雜八的還真花時間！

也因此Google及Yahoo很久之前就在開始發展Sawzall及Pig，他們都是parallel data process/analysis language。其中當然也包含了functional language的特色，我想這能夠成為新一代的資料庫設計路線。以往資料庫是從簡單的CRUD，直到複雜的T-SQL來進行資料的分析，後來發現不夠用，所以又有了OLAP(或是Data Mining)。在資訊爆炸的時代，這一塊地可以說是有許多做資料庫的大廠必爭之地。我覺得未來很有可能會被這種分散式且高效能的資料分析方式所取代，而這裡就是最欠缺一個好的語言。

HTTPMR

在官方的範例我們可以體驗到MapReduce輕鬆進行字串分析的特性，這個範例最主要把一連串用空白分隔的字串拆開(等於是call .split(" "))，並且使用字串建立起索引
在這一段

定義了一個Map Function，目的是在拆開字串。
而在這一段，

定義了Reduce Function，目的是在於利用剛剛拆開的字串建立起索引，存回DBStore裡去。
原本還附了一支小程式，讓它看起來有點像是可以在unix shell submit job。
http://code.google.com/p/httpmr/source/browse/trunk/src/construct_document_index.sh
但其實當你deploy到AppEngine後，也就等於隨時可以執行了。

結論

這個HTTPMR工具基本上地實現了MapReduce的可能性；換句話說它把google工程師們本來就在用的功能從內部能還原出來，並且讓大家可以試著去執行看看。

但從高效能計算的角度，這樣還不足以能夠成為一個很好的計算環境。除了改善這個函式庫所提供的功能以外，也必須有更多參考讓科學家們知道怎樣做會比較簡單。

前虛擬化技術的現況有 提到過一些虛擬化技術對個人以及軟體工程師的幫助。大概在2008年初的時候，虛擬化技術因為CPU的支援，而開始了另一波的高峰。而因為全球經濟風暴， 所有企業也在積極尋求節能減碳的方法。對於企業的資訊資源來說，浪費CPU或者是硬碟空間，無非就是浪費電力。有虛擬化技術的幫助，能夠在一個實體機器上 執行多個虛擬機器，以不互相干擾，又能夠互借多餘的CPU時間，記憶體或硬碟空間的方式，讓實體機器的使用度大增。

本篇文章要從建置不中斷的系統服務，以及系統管理者的角度為各位介紹，VMWare究竟是怎樣利用虛擬化來幫助管理者建置高可用(High Availability，HA)的虛擬化叢集。

虛擬化技術名詞解釋

在此先介紹一些共同的名詞及觀念。

Virtual Machine(VM)：虛擬機器

一個虛擬機器要能夠完全地模擬一台實體機器的韌體，硬體結構。也就是說，對於所有的作業系統(軟體)，安裝在實體機器及虛擬機器，要是一模一樣的。虛擬化技術可分成全虛擬化，半虛擬化，而全虛擬化則可以透過CPU的虛擬化支援來加速。

近年來Intel-VT及AMD-V這兩個在CPU裡增加的虛擬化支援，也促使許多虛擬化軟體廠商都開始採用，不僅增加了效能，也增加了對許多 GuestOS的相容性。但對於虛擬化效能最大的幫助，莫過於核心的數量與記憶體的多寡。Intel後期的四核心CPU，以及未來的八核心CPU，讓許多 大廠的伺服器都能夠強打支援虛擬化的銷售策略。而另一個就是像虛擬硬碟(Virtual Disk)的備份方案，也有越來越多軟硬體廠商支援。

Guest OS：VM所使用的作業系統

通 常並不是所有的作業系統都可以支援虛擬化，而對於大部分的管理者來說，Windows 2003 R2及Redhat Enterprise 5這兩套就足以讓企業有穩定的Windows及Linux環境可供使用。但對於開放原碼的OS或是其他沒在相容列表裡的，就無法保證會發生啥事。儘管在實 際情況中，Windows XP以及大多數Linux的版本(如Fedora或CentOS)都可以使用，但對管理者來說有官方承諾的相容度總是比較放心的。

對於企業來說，GuestOS牽扯到部署，備份，還原等問題。虛擬機器要可以轉換成「樣版」來幫助進行部署，而且部署還要快速。此外虛擬機器的硬碟檔當然要能夠線上備份及還原，畢竟有些服務是不允許中斷的。

Virtualization Cluster：虛擬化叢集

對 企業而言一台機器是無法做事情的，而很多關鍵性的服務，不允許關機的機器，更是為許多管理員們所負擔的沈重壓力。因此企業在規劃許多不停機服務的時候，都 會採取備援(Fail-over)或者是高可用度(High Availability, HA)的解決方案。有了虛擬化技術之後，HA變得輕鬆許多，當某個虛擬機器出了問題，只要將他的狀態存起來，然後轉移到能夠執行他的實體機器上就可以了。 就算是實體機器忽然斷電了，只要有一個以上的實體機器還存活，網路設備不斷電，就還有機會可以即時轉移(Migrate)。因此我們將這樣的作法稱做是虛 擬化叢集，意思是說用許多相同的伺服器串連在一起，進行互相備援或是即時支援的協同作業。

Motion Technology：VM動態轉移

上 述的轉移技術，必須要有幾個條件才能運作，一是所有機器必須都使用Storage Area Network(SAN)的架構來掛載共用的儲存。現在SAN的架構，比較常見的就是Fiber或是iSCSI。預算不夠買儲存硬體的話，使用較便宜的 PC伺服器也可以透過軟體的方式來建構iSCSI的儲存網路。二是所有的實體機器都要在同一個網段，而如果所使用的網段較多的話，也要能夠確保所有的實體 機器都能夠要用多張網路卡去連接。

Storage Area Network (SAN)：儲域網路

SAN代表的是 如同LAN(區域網路)的意義，只是功能是用來連接儲存媒體與伺服器。在SAN架構之下的設備通常有iSCSI或是Fiber的NAS儲存裝置，交換機， 區塊裝置卡(HBA)等。這個名詞大家常會與NAS(Network Attached Storage)搞混，NAS代表的是硬碟式的儲存媒體，能夠利用檔案層級(File-Level)的方式，如NFS，CIFS的網路檔案系統讓其他主機 掛載。然而現在有些NAS設備也包含了可以使用區塊層級(Block-Level)來連接的iSCSI或是Fiber連接介面，在效能上更是加倍。至於交 換機的部分，也是視使用的連接介面而定，可以使用Gigabit Ethernet Switch或是Fiber Switch。最後也是根據介面的不同，可以選擇iSCSI HBA或是Fiber HBA，來連接到主機上。

iSCSI Protocol

以 往為了追求高效能的中央控管儲存，使用Fiber(光纖)或是更高檔的Infiniband來連接SCSI設備已經是非常常見的事。但是這些設備造價高 昂，並不是一般的學校單位或中小企業負擔得起。也因此就出現了能夠透過一般的以太網路(Ethernet)來連接的iSCSI及AoE(ATA Over Ethernet)，這些都是將區塊層級(Block-Level)利用網路來存取或共享。而iSCSI對於共享式的儲存也有些限制，必須確定所使用的服 務程式(iSCSI Target Service)能夠支援叢集式的存取。因為不管是哪一家的VM Server，要能更使用VM動態轉移，一定必須使用一個儲存裝置的空間，然後透過iSCSI或是Fiber，加上叢集式存取的機制，讓多台的VM Server去掛載才行。

企業虛擬化方案

在本文章中，是著重在企業化的虛擬機器管理，而考量這些虛擬機器會有 Windows及Linux的GuestOS共存。而綜觀商場上現有的虛擬機器軟體，方案較完整的只有VMWare ESX 3.5及Citrix XenServer 5。至於其他的虛擬機器軟體如Virtual Box或微軟的Virtual Server，由於支援度或功能太過特定，則不在考慮內。

VMWare ESX 3.5

自從EMC買下VMWare 後，許多與高階軟硬體的整合能力就大幅提昇。記得早期還在GSX Server或Workstation時代的時候，也是有很多如同XenServer現在的情況一樣，還在操作介面上或是設定的彈性上有所欠缺。 VMWare經常對產品名稱做改變，而發展出來許多主線副線的產品，其名稱的演進造成的混亂，讓許多在評估產品的管理員們可是大感吃不消。然而自從進入了 3.0的InfraStructure時代，帶給管理員們的是功能更完整，操作性，整合度更高的虛擬系統。現在VMWare的主力產品就是VMWare InfraStructure，分做三大軟體：

• ESX Server 以Linux 2.4為核心，直接以光碟安裝完後，就是一個Linux Server，並且包含以下選項：

• VMFS是作為儲存虛擬硬碟檔案所必須的檔案系統，所有要用來儲存的區塊裝置(無論是本機的硬碟或是iSCSI網路硬碟)都必須使用VMFS來格式化，才能掛載到ESX Server上儲存。
• Virtual SMP是讓虛擬機器能夠選擇以幾個CPU來執行。

• VirtualCenter(VC) 並不是「用戶端程式」，而是為了要串連ESX Server並且啟用HA，Motion功能的「中介軟體」。一旦啟用了，就算VC關閉了也不會影響HA的運作。但連線到VC來進行管裡的時候，可以看見 實體與虛擬機器的全景，是更為合理的管理方式。VC包含了幾個軟體選項：

• VMWare VMotion是能夠將虛擬機器動態地在實體機器間轉移的技術
• VMWare HA利用了vmotion技術，能夠在虛擬機器失效，或是實體機器發生錯誤時，即時地轉移至還存活的實體機器上繼續執行。
• VMWare DRS將vmotion及ha技術融合在一起，根據實體機器的CPU或記憶體資源負載，動態地轉移虛擬機器至較無負載的實體機器上。

• Virtual InfraStructure Client(VIC) 就是能夠直接對ESX及VC進行連線的用戶端軟體，在官方網站也可以免費下載使用。

• 介面觀感
  對於一個能夠進行集合管裡的軟體來說，利用樹狀結構來建立自己的根節點，並且加入主機，這是相當基本的。而右邊的分頁，也會根據目前點到的管理單位(叢 集，實體主機，虛擬主機...等)而有所改變。例如管理某台主機的儲存裝置時，可以發現列出的項目都可以按右鍵，並且可以瀏覽裡面的內容。有時後到底哪個 項目可以右鍵，哪個項目不行，會有點讓使用者感到混淆。而如上圖在最右邊有時後會出現「Property...」表示點選了後會出現新視窗來設定，而有的 功能分頁會有，有的沒有。但通常這些彈出式視窗都是關係到非常重要的設定，如新增網路卡，新增儲存裝置等，管理員們得好好閱讀管理手冊來瞭解每一件工作倒 底要從哪裡點選。而大致上VIC都照著管理員的習慣而設計，這一點能夠感受到VMWare的長期努力，值得讚賞。尤其是Map分頁，直接畫出了目前實體機 器，虛擬機器，網路，儲存的架構圖，這是管理員們都想要的重要功能。
• 效能
  由於VMWare是以自家獨特的全虛擬化技術(Binary Translation)做為基底，早期的VMWare我一直覺得都是非常地慢而不願意使用。然而在3版的時候加入了VMI(Virtual Machine Interface)的半虛擬化支援，使得如Linux核心版本大於2.6.21的Fedora8，能夠讓OS知道自己正在虛擬機器上執行，進而達成最佳 化效能。此外Windows 2008也預計加入VMI的支援。但如果沒有VMI的支援，一旦CPU或是IO的負載量大的時候，常常會出現效能不平衡的狀態，有些機器會變得非常慢，這 個時候就只能請管理員自行限制那些負載量高的虛擬機器資源配置了。從效能圖表上也可以發現，大多數沒有VMI支援的OS(如常用的Windows 2003 R2)，CPU都無法飆上100%，相對的就是效能較差。因此如果有效能考量的管理員們，可以考慮架設叢集化的服務來平衡速度上的差距。
• 支援性
  使用傳統的Binary Translation的方式，缺點就是如果沒在VMWare支援GuestOS的列表下，像是以前的版本還不支援Vista的時候，那真是怎樣灌也灌不 起來。相對起來XenServer在這邊就比較有機會。不過近年來VMWare已經大幅度地改善了支援度，直到現在的3.5連Windows 2008 Server也支援了。
• 授權方式
  VMWare有提供免費的版本稱做ESXi，就基本功能來說與ESX是相同的。但如果要使用VC來進行串連，還是建議使用ESX。VMWare有相當多的 方案可以參考，例如企業HA方案(2ESX+1VC)，價格會比分開買還便宜許多。值得一提的是，比起XenServer比較單純的計費方式及軟體授權方 法，所有功能都是分開授權的。所以管理者們要小心檢視自己購買的方案所含的授權多了哪個或少了哪個。

Citrix XenServer 5

XenServer 給我一個最深的印象，那就是開放原碼起家。如果你想要使用免費的Xen VM，其實它已經附在現在大多數的Linux版本裡了，如Fedora 8，CentOS 5.2。免費版的Xen所使用的管理介面比較簡單，也沒有任何方式支援HA，適合個人使用。

有關使用Xen及Virt-manager可以參考這些文章：

如 果沒有太要求完整的備份方案，或是工程師還有餘力可以解決一些小問題的話，XenServer5確實是一個便宜的方案。估計比起VMWare至少要便宜一 半以上的價格。然而XenServer的半虛擬化(para-virtualization)比起VMWare所支援的Linux核心版本要來得多，對於 需要管理較多Linux機器的管理者們來說，不需使用太昂貴的硬體便能夠運作。此外Windows系列的作業系統使用起來也不會太慢。 XenServer5的主要軟體套件都附在第一張光碟裡，並包含以下：

• XenServer5 以Linux 2.6.18為核心(相當於Redhat Enterprise 5)，與VMWare不同的是開機完成後，也可以直接在console上進行設定。另一點不同的地方是，XenServer只能夠在64位元CPU上執 行，這對於管理員們是一大考量。如果是比較舊的主機，那就只能使用VMWare了。

• XenXerver5 Enterprise 包含了XenMotion，HA及能夠掛載NFS或iSCSI硬碟的能力。

• XenCenter 與VMWare的VC不同，這只是單純的用戶端程式。XenServer的架構並不需要使用到任何中介程式進行串連，因此在管理上雖然少了些彈性，卻比VMWare簡單許多。

• 介面觀感
  在使用介面的觀感上XenServer給人的初次印象就是簡單，但也反映出來他們對於系統管理者的管理方式還不夠熟悉。許多功能都是用精靈的方式來一步一 步增加，並無法讓管理者能夠彈性地新增刪除。對於各個元件的狀態(如儲存媒體或是硬體儲存卡的狀態)也都做了資訊隱藏，除非使用指令介面來操作，不然無法 查詢到。使用Console來顯示Windows畫面的速度比較緩慢，甚至有Lag的狀況。
  但總結起來，比較適合剛入門或是需求單純的管理員。
• 效能
  對於Linux虛擬機器的效能，由於使用了半虛擬化而大增。但Windows機器就相對地效能普通。
• 支援性
  比起VMWare來說，Xen幾乎是可以跑所有以Linux做為核心的OS，而幾乎是不會有太大問題，這個是Xen的天生優勢，在負載很大的情況下也不會輕易當機。
• 授權方式
  XenServer5可以隨時從官方網站下載並安裝，但並不包括HA及Motion的功能，這兩個功能需要啟用Enterprise版本的授權才行。授權檔也可以在官方網站取得，並且有一個月的試用期限。

建置

部署環境

在本文中，我們將使用iSCSI的方式來連接中央的儲存設備。而本文章的主題是VMWare，因此接著在接下來的文章中。所有設備的部署圖如下：

IP清單：

建置iSCSI NAS

準備硬體

建 置iSCSI最低的門檻我想應該都必須要1G的Ethernet。如果要得到更好的效能，無非就是將所有的儲存網路換成10G Ethernet或者是Fiber。而不同家的iSCSI Target的軟體，效能差距應該不會太大。此外網路卡的部分，也請盡量使用Intel，3Com，Broadcom(多半是內建)等大廠牌的，以免影響 最大的出力值。

iSCSI Target 伺服器所需要的CPU及記憶體並不需要太好，一般P4的PC，具備有512M記憶體皆可。但最主要是所採用的磁碟陣列系統，由於一旦中央的儲存系統損毀， 就萬事休矣，另一點是如果要搭配硬體的複寫(replication)系統也非常昂貴。也因此對於管理員來說，也可以選擇市售搭配Windows2003 儲存版的「直立式儲存伺服器」，就大概符合上述需求，然後在自行重新安裝一般的Linux OS即可。

軟體iSCSI的方案並不多，除了 Linux 有Linux iSCSI Enterprise Target (IET)以外，Windows上有StarWind及Windows Storage Server 2003 R2(wintarget)。這些通常都只支援到SendTarget Discovery及Clustering。

如果需要MPIO (Multipath) 的方案，恐怕只有硬體才有支援了，此外也得購買硬體的iSCSI HBA卡。儘管StarWind及WinTarget都有支援MPIO，不過只限定使用Microsoft iSCSI Initiator。

安裝及設定

在此我們使用最簡單的軟體，他支援最基本的send target discovery及建置存及需要的clustering，請在http://iscsitarget.sourceforge.net/下載。

1. tar zxf iscsi-target.{version}.tar.gz
2. make; make install
3. 編輯/etc/ietd.conf，修改iqn及Lun 0 那一行
   iqn的格式是iqn.yyyy-mm.<reversed domain name>[:identifier]
   舉個例子iqn.tw.com.yourdomain:iscsiserver.lun0
   Lun 0 Path={檔案路徑},Type=fileio
   檔案路徑可以是一般的空白檔案(要先用dd寫入空白資料)，裝置檔，或是LVM裝置檔
   舉例 Lun 0 Path=Lun 0 Path=/dev/VolGroup00/lv_iscsi,Type=fileio
4. chmod 700 /etc/init.d/iscsi-target
5. service iscsi-target start
6. chkconfig --level 35 iscsi-target on

你也可測試iSCSI是否正常運作，這樣就必須安裝open-iscsi (iscsi-initiator-utils)。

1. yum install iscsi-initiator-utils
2. service iscsi start
3. iscsiadm -m discovery -t sendtargets -p 10.1.1.22
   對iscsi server進行查詢
4. iscsiadm -m node -l
   如果查詢成功的話，就進行連接(登入)
5. fdisk -l來看看是否有多新的scsi裝置
6. iscsiadm -m node -u
   如果要中斷的話，就登出
7. 如果沒有清除紀錄的話，只要iscsi啟動就會進行登入。請到/var/lib/iscsi/nodes及/var/lib/iscsi/send_targets刪除其目錄下的資料

建置叢集

接著便安裝各兩台ESX伺服器，安裝的方式也非常簡單，與安裝一般的LinuxOS無異。

一 旦安裝完畢，可以使用VIC進入vmware01，建立第一個虛擬機器，這個虛擬機器就是我們用來安裝Virtual Center(VC)所用的，在此我們假定IP是10.1.1.22。安裝完OS及VC後，可以在程式集裡找到「VMWare License Server Tool」，換上你擁有的授權檔，也當作授權伺服器使用。以下安裝的介紹，將會預設使用者已經有ESX Enterprise(SAN Usage選項)，VC，HA，DRS的授權，一旦通過授權，才不會發生未授權的錯誤或者是功能被UI鎖住無法使用。

此外在部署圖中也看到建議自行安裝一般常見的網路服務如DNS及DHCP，來加速未來安裝虛擬機器的便利性。

伺服器設定

在設定之前請務必要熟悉VIC的操作介面。

網路設定

請找到Configuration分頁，點選Networking。

這一張圖片是比較複雜的設定，藉此可以瞭解ESX的網路設定架構。

• vSwitch：一個vSwitch代表至少一張網路卡的連結。也就是說，如果你有一張以上的網路卡，你可以分別建立不同的vSwitch來指向不同的網段。在這個例子中，我們有兩個vSwitch，分別指向10.1及10.3兩個網段。而vSwitch也可以指定兩張以上的網路卡作為備援，完成後如同vSwitch0的設定狀態。如果兩張網路卡所連接的實體Switch支援Trunk的話，也可以採用Bonding，來將兩張網路卡的頻寬合併在一起。
  VM在建立的時候都會新增一個網路卡，你可以修改VM的設定來讓他指向不同的vSwitch，也就是不同的網段。
• VM Network：當你建立vSwitch的時候，也同時會建立VM Network。這裡可以看見有多少VM已經啟動並連接上。
• Service Console：代表著能夠讓VIC或是SSH進行連線的IP，一個實體機器至少要有一個。在這個例子中，我們並沒有在vSwitch1中增加Service Console。
• VM Kernel：代表著實體機器連出的IP，這個IP也作為iscsi client或是vmotion的傳輸通道使用。也就是說，service console並不能作為這些網路功能使用，只能夠連線而已。一旦要啟用上述功能，就必須在該網段使用VM Kernel佔用一個IP才行。

ESX在建立叢集服務的時候，如果沒有事先在DNS裡註冊的話，會出現An error occurred during configuration of the HA Agent on the host。原因只是因為ESX會直接使用你設定的hostname來進行連線，但VC並未設計充當DNS的功能，所以不是安裝一個DNS，那就是直接修改 所有主機的(包括VC的)hosts檔案。詳細請參考http://60.190.88.90/ljf/2008/04/an-error-occurred-during-confi-1.html。如果要修改DNS或是Default Gateway的設定，請點選「Properties...」並編輯Service Console。

在HA啟動的時候，會使用這裡所填寫的hostname與domain進行彼此之間的連線，在這個例子是vmware03.mydomain.com。請記得在DNS裡設定，讓這個名稱可以被查詢。

儲存裝置設定

請在Configuration分頁點選Storage Adapters。

點選Properties，再點選「Configure...」，可以勾選「Enabled」來啟動軟體的iSCSI Initiator。

接著可以點選Dynamic Discovery來加入iscsi server的IP，完成後UI會自動詢問要不要Rescan，選是。

基本上重新掃瞄完後，會出現如同第一張圖一樣，已經有SCSI Target被註冊，這時請注意Canonical Path裡所顯示的vmhba32:n:n的代號。

接著點選Configuration分頁的Storage，在點選「Add Storage...」，依照精靈的提示繼續下去，會看見剛剛所出現的代號，選擇這個HBA後，再進行命名。在這例子我命名為iscsi，之後會進行格式化。

在這個頁面中，任何已經格式化好的儲存裝置都會列出來。接著你可以在項目上按右鍵，選擇「Browse DataStore...」，就會出現像檔案總管般的畫面，可以讓你上傳及管理檔案。

iSCSI的設定大致上是這樣，我們再將步驟整理一下：

1. 點選「Enabled」來啟用iSCSI
2. 新增Dynamic Discovery IP
3. Rescan

而移除的時候，就是移除掉所有的Discovery IP，並且重新Rescan即可。確定沒有任何連接中的iSCSI裝置，就可以將Enabled勾取消，來關閉iSCSI。

用上述步驟，可以避免調重新啟動實體機器的麻煩，儘管UI會提示，不過可以不予理會。

高可用度(HA)叢集設定

這個設定起來非常的簡單。請注意在設定的時候是必須連到VC的，不過一旦設定成功後，即使VC沒有啟動，HA也會運作。

1. 在根目錄上新增資料中心(New DataCenter)，一個資料中心代表最上層的管理組織，但無任何可以設定的項目。就像是Folder一樣，但比較有代表性。
2. 在資料中心下新增叢集(New Cluster)，叢集下可以新增虛擬機器及伺服器(Add a host)，而如果伺服器上已有虛擬機器，就會納入此叢集下管理。新增叢集的時候，可以指定要選用DRS或是HA。
   1. 在AdmissionControl裡提到了一個Cluster最多能夠同時容忍幾個「實體機器」斷線，如果要讓容忍的數目增加，那勢必要有更多實體機器。
   2. Default Cluster Setting可以設定當實體機器斷線時，該機器本身要採取的動作。由於斷線可能是因為網路，當網路回復時可能會讓已經在其他活著的實體機器啟動的VM衝 突。因此在Host Isolation Response裡可以選擇讓離線的實體機器自動關閉所有VM，或是讓VM留著不要關閉。
   3. HA也可以偵測VM的活動，但只針對有安裝VMWare Tools的。這裡可以選擇是否要偵測VM的回應，當VM停止回應時，實體機器會自動重新啟動VM。

虛擬機器的管理

還是一樣請務必要熟悉介面的操作。你可以利用「Edit Virtual Machine Settings」來為你的VM新增或移除硬體，如額外的硬碟，或是調整CPU或記憶體的數量。

Migration

遷移分做兩種狀態。

如果可以Motion，就會自動進行，反之則會要求選擇你要migrate過去的儲存裝置及主機。當然管理員必須先自行判斷，如果你知道自己要做的是migration而不是motion，那就記得要先點「Suspend」來將VM暫停。

步驟如下：

1. 選擇目的地：展開樹狀圖來選擇你想要的主機，如果驗證未通過，那就要看出現的訊息是啥。
2. 選擇Resource Pool：基本上Migration可以跨DataCenter。
3. 選擇儲存裝置：根據你選擇的主機，可以在選擇已經在該主機上設定好的儲存裝置。
4. 完成。依網路速度及VM硬碟大小不同，等待一段時間後，便可以回復VM。此時你會發現如果使用Gigabit Ethernet的時間就會縮短很多。

CPUID Mask

如果你的實體機器不支援SSE3的時候，便無法migrate到這上面，會出現類似這樣的畫面。這個時候要修改VM的CPUID Mask。

點選「Edit setting」，「Options」，「CPUID Mask」，先選擇「Expose the Nx flag to guest」，再點「Advanced...」。

找到Level1 ecx那一排，然後將下列一行複製，並貼上，就可以解決了。

---- ---- ---- ---- ---- ---- ---0 -0-0

參考資料

http://www.vmware.com/support/pubs/vi_pages/vi_pubs_35u2.html

http://60.190.88.90/ljf/2008/04/an-error-occurred-during-confi-1.html

http://searchvmware.techtarget.com/tip/0,289483,sid179_gci1277081,00.html

http://communities.vmware.com/thread/125432

結論

在試用的期間，真的已經逐漸熟悉VIC整體的操作模式，以及貼心的小設計。但無論機器怎樣方便好用，怎樣聰明自動化，還是需要瞭解其技術核心的管理員來輔助，免得出了任何手冊上沒寫的狀況，就無法處理。