Kiwi格網技術開發站

程式開發者可記的九大經典名句

2011-08-23T03:29:00.000-07:00

http://www.quora.com/What-distinguishes-a-good-software-engineer-from-a-great-one?__snids__=16428567

http://www.inside.com.tw/2011/04/27/developer-quotes

我將我覺得重要的摘錄如下

"Design is finding the problem, not the solution" -- Leslie Chicoine

設計是找問題，而不是找解答。

而實際上我理解後，我認為設計應該還是尋找問題及適合特定對象的答案。例如說，如果你想要設計一台車，你絕對不會空想一台車，而是你確定這台車是要給誰開的，才會為了那類的人去設計那台車。

"Legacy Code is Code Without Tests" -- Michael Feathers

沒有測試過的程式碼就不能夠使用。

這是千真萬確的，不管是個怎樣強的編程機器，一定會有盲點。不管寫得再完整再漂亮，其實很多都是因為寫程式的人會習慣性地告訴自己，寫這樣多程式已經足夠，其實本來就沒有所謂絕對完美的架構或程式碼。而我自始至終都認為自己剛寫出來的東西「根本就不能信任」，一定要站在使用者的角度，撰寫功能性的測試。測試過了，才能夠「信任」。沒有經過測試到的功能，就要視為不可以使用的功能。

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand" --Martin Fowler

任何人都可以寫出電腦懂的語言，好的程式設計師寫的是人可以看得懂的語言。

其實這是一個非常困難的目標。多年以來，我發現所謂的開發者，是必須經過有一段期間，用自己才能夠理解的邏輯，去把東西做出來。甚至這樣的邏輯，在很多人的心中早就是一種本能，而那樣的本能是無法描述出來的。所以，要寫出自己看得懂的程式很簡單，但要他人看得懂就很非常困難。更何況會去看你的程式的人，有些時候只是單純為了要糾正你的程式而已。

所以我認為這句話，應該是要讓自己朝向一個目標：不要只是把程式寫完，要留一些資料來解釋自己的程式究竟在做什麼。這樣子程式就不再只是一個單純的程式，而是可以讓看的人去瞭解一些「想法」，而這些人他們應該也只是想透過程是來去瞭解想法，而並非對你怎樣做出來的真的有興趣。

還是老話一句，在這個時代，光會寫程式，是無法將自己的想法表達出來的。

"Simplicity does not precede complexity, but follows it" -- Alan Perlis

簡化不可能發生在複雜化之前，一定是之後。

這句話也是驗證很多事情啊。在工作的期間，有注意到幾個狀況：

在設計系統的時候，一定會經過一個階段就是討論「使用者需要什麼？我們究竟該做什麼？」而討論了很多，每個人都有自己的想法，就往往無法收斂。一旦沒有人引導整個討論，就會讓整件事情越來越糟糕。而一旦討論稍微收斂，又有些人會本能地將事情複雜化，而無法理解需求發散了之後需要的是收斂，才能真正進入時程規劃，系統設計及開發的階段。

另一個是很多「聰明」的開發者，會在討論時簡化自己該做的事情，想要藉此來減輕自己的工作量。但實際上，真正在系統實做之後，往往會因為過度的簡化，造成幾個現象：1. 自己設計的東西缺乏彈性，因此對於新的需求往往會很焦躁 2. 會想要反過來去推翻使用者的需求

因此，讓不同特性的人，在同一個討論會議，重複進行思考發散及收斂的動作。這樣的訓練是非常的重要。一旦習慣這樣的週期，如同scrum那樣的模式才能夠真正形成。

"Real developers ship" -- Jeff Attwood

真正的開發者會交出產品。

是的，也因此可以發現很多開發者是不太習慣交出產品，也並不清楚自己的程式到底能不能千錘百鍊。總之還是一句話：「測試」。此外，能夠瞭解使用者需求的，才有可能交出產品。開發者不應該要活在自己「最佳化程式」那樣的夢境裡，反而應該找些時間跳出來聽聽用過你的程式的人的聲音。

"There is no silver bullet" -- Frederick Brooks

沒有什麼是萬靈丹。

最近和一些熟悉硬體開發的人相處，也才知道他們口中的軟體，並不是像我們常聽到的應用軟體。以硬帶軟，始終是會將軟體視作是一種「生產」。他們相信，軟體開發是可以最佳化的，軟體是應該要有生產力的，並不需要太多的創意，也不該因為需要創意而給予時間養分。我當然也認同，軟體應該要有生產力，但終究不可能像是做硬體那樣，一旦規格確立，前因後果研究清楚了，就開始大量生產。會進入那種模式的，我想還是像韌體，或是系統軟體。這些軟體比較有可能在規格確立清楚後，就開始投入人力「寫」。

也因此，寫應用軟體會比較重視創意，以及與使用者互動來磨練，應用軟體絕對是需要這種養分，也絕對需要時間。並不可能使用單一種管理，生產方式或作法就能夠讓全部的人都寫出有價值的東西。會去對任何人強調說自己的公司是使用這樣的管理方式，那無非就是策略而已，並不應該是一間開發應用軟體的公司所為。

"For the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something...almost everything - all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose." -- Steve Jobs

過去33年來，我每天早上看著鏡子問我自己：「如果今天就是生命的最後一天，我會去做今天應該要做的事嗎？」。儘管每次最後答案還是「不會」，我都知道我需要改變...改變所有的事情：不要擔著外在的期望，不要驕傲，不要害怕丟臉或失敗。因為這些事在死神面前都不再存在，而只會留下真正重要的事。提醒自己馬上就要死了，就是可以避免讓自己落入患得患失陷阱的最好方法。

"What distinguishes a good software engineer from a great one? Able to balance pragmatism and perfectionism, Not averse to debugging and bugfixing and Healthy skepticism " -- Russel Simmons

如何區別好的與偉大的軟體工程師？能夠平衡實用主義與完美主義，對於解bug永不厭惡，以及有建設性的懷疑。

重新整理

2011-05-05T00:53:00.000-07:00

近來在工作上有了些新的體驗，算是有個主軸
開始寫些系統的東西，也複習了許多遺忘掉的東西
沒想到我曾經寫過C++，那個大概是七八年前的事情了

我想我果真是有夢想的人，而我也確實感受到在一個環境裡大家逐漸被磨掉的樣子
但我想，我不能夠讓自己的夢想被磨掉

軟體之所以會有品質，是靠努力來的

軟體是一門工程，也是一門藝術
就像上一篇的名言，單純寫出程式碼很多人都會
但為什麼要那樣寫，為什麼要那樣設計
很多人卻不清楚

也有很多人單純覺得這只是一份工作，為什麼一定得這樣拼命
並不是說，想要一份工作，快樂過生活，這樣的態度不對
只是在輕忽軟體品質的同時，你也造成幫你測試的同事及用你的程式的人的困擾
這樣的態度與那些叫你寫Functional Spec卻不做事的人沒有啥不同
也與那些說自己只負責寫prototype的人也沒啥不同
沒有經過自己完整測試的程式便叫做「Legacy Code」，是不能夠使用的
無用的程式片段，就像不斷累積的麻煩
一個用麻煩堆積成的產品，最終就是招來關門大吉

為啥我一定得在軟體工程上朝向卓越？

我想，那是我非常清楚軟體可以做到很多事情

而我想要利用軟體去做很多事情

我更認為，這個世界值得一些好的工程師站出來替大家寫些好用的東西

讓用的人深深覺得「啊～還好有這套軟體」

必須清楚的是，在台灣很多號稱做軟體的公司的資深工程師們，是無視上述的想法的。不能夠說一竿子打翻一條船，但注重這些細節的人真的太少。

分散式軟體過去的失敗

我看到在這一年來opensource這邊對於分散式系統，雲端軟體的開發已經開始有些轉變

許多人都在想要好好地使用大量的機器，也代表他們越來越清楚大量的機器會出現什麼問題
就算有些不清楚的地方，至少他們很認真

而反過來我對這些號稱在做資料中心的人
他們是否真的有大量機器管理，建置直到軟體開發的經驗
而這樣的經驗是否兩三年累積的起來，有沒有不同面向的人在負責不同的經驗
是影響雲端相關軟體產出品質的最大因素

另一個瓶頸是，系統再大下去，便會有許多使用情境
以及層層複雜的設計以求彈性
大家都在嘗試互相整合，以為只要用新名詞封裝舊概念就好，或是換個方式嘗試就好
但多半是概念上越簡單的，越是有重新設計過的，化零為整才可能有足夠的擴展性

簡單地說，現代資訊流通這樣快，概念這樣複雜
想拿別人的東西來改一下就想要上場，已經沒啥用了
還是好好想想別人做的東西到底本質上有啥沒突破的
在這個點上去砸下人力時間成本來突破，會比較有顯著的成果

我必須告訴我自己，未來不要重蹈他們的覆轍

該做的事

跟上時代，善用溝通工具及傳播性網路
建立個人履歷，知識庫，隨時接受審視
隨時改變錯誤的習慣，修正自己的程式（包括舊有的程式）
追求進步與卓越

台灣軟體界的無奈

2011-03-31T03:39:00.000-07:00

http://www.ptt.cc/bbs/Tech_Job/M.1297623784.A.509.html

http://www.ptt.cc/bbs/Tech_Job/M.1297687950.A.F60.html

http://blog.vgod.tw/2011/03/03/research-and-paper/

記得三年前我還在寫「程式設計的"德、智、體、群、美"」的時候，那個時候想法還沒這樣負面，現在想想或許是那時候太年輕了？而如今見到一堆亂象，我也想要一直反省自己，是否可以在這樣的亂象中，盡力告訴自己應該要做好的事，讓事情往好的方向發展，不要被前輩的一句話蒙蔽：「做好事不如做"對"事」。這種做「對」的事乍聽之下好像不錯，在很多情況根本只是推卸責任。記得有位網友在後面回說「無聊」「這是大家都知道的問題」「沒有建設性」，現在想起來，那個陳老師應該也是做過類似的事情，面對整個共犯體系而很無力，或許也是在同樣的心情下寫同樣的文章。

最後我也來個呼籲吧：
台灣的年輕工程師！加油！
別學前輩去玩政治手段，就算你有一天可以凹到85K的月薪，你一定要知道，當你無視手下的健康與合理性亂丟工作時，你的手下也肯定天天在幹樵你！也別想說今天別人這樣對你，你明天就要這樣對別人，這樣只是讓你自己看起來更糟糕而已。上一代的混亂，我們何必全部都要吃下來呢？我們也是可以有自己的作法，去面對這充滿競爭的世界的。
請好好建立自身的價值觀，做「好」的事，不要因應時事當個人云亦云的人！

2010的雲端回顧及未來展望

2011-02-20T00:17:00.000-08:00

為了能讓大家對雲端的發展有所瞭解，這篇文章將從幾個不同的觀點來剖析今年度的雲端技術發展。我會先從國際間的狀況與台灣產業的發展來分析，之後才是實際的雲端技術及Web技術的總和介紹。當然這些都是我個人在2010這一整年的觀察，所以想說整理一下在網路上與大家來討論。

在國際發展的部分，這一整年各大廠併購雲端相關公司的動作相當頻繁，而在併購案的趨勢中可以發現，電視與手機將會是下一代雲端服務整合使用者設備的主軸。換句話說，將來各位的手機或是電視背後也都是連接雲端服務的。最近熱門的壹電視，也只差他沒有硬要說自己是雲端電視盒，但我相信未來這樣的電視盒會很熱門。而在國際上，看起來最先會掀起雲端電視的熱潮恐怕也還是Google與Sony。至於無法從技術上著手進入雲端的企業，就只好放話了...也難怪Google用不屑的態度回應。

國際發展的推薦連結：

英特尔宣布76.8亿美元收购McAfee

與SaaS相關的新聞中，可以逐漸發現線上的office系統並且整合分享，Social Network的應用為大宗。我個人覺得雲端列印的新聞同樣有雷聲大雨點小的情況，目前也僅靠著像ibon這樣的服務為沒有印表機的人進行雲端列印。由於印表機在台灣是很便宜普及的，或許將來雲端列印的服務模式可能要走向特殊化，例如大量列印或是專業列印，才可能有立足之地。有國外公司推出雲端遊戲平台，真的滿有趣的，這可是貨真價實地讓玩家享用雲端上的顯示卡。台灣也有業者跟進，雖然沒那樣厲害，不過可以容納的下十萬人的伺服器也不賴了。至於很多家都想要做的雲端防毒或是系統保護，總感覺起來也還沒有一個實質的成績，也是雷聲大雨點小。隨後Asus也推出了雲端儲存，雖然現在整個服務還在草創的階段，只要能夠細心地提升軟體水準，維持後端系統的上線時間，我覺得也是一個不錯的雲端軟體產品。

SaaS相關的連結：
Q1

PaaS及IaaS相關的新聞比較難分類，因此整合在一起進行介紹。在2010的一整年中，也可以瞭解到各大廠的開發方向都轉向應用層面，相對地也代表這些平台的發展逐漸趨於成熟。VMWare推出的第四代的平台，儘管操作介面與價格沒有太大變化，但自動化及輔助工具變得非常的多樣化。說到線上資料庫以及線上軟體平台，我想恐怕也只有salesforce及oracle有足夠的後盾能夠去開發。

PaaS相關連結：

IaaS相關新聞連結：

在雲端硬體的部分，這邊收集的比較多都是跟硬體廠商的相關連結。儘管有些也不是完全做雲端相關的，但都是對網路發展是有一定的幫助。值得注意到的是，高密度的硬碟，磁碟陣列，以及省電的CPU，將是影響2011雲端發展的幕後主角。

雲端硬體的相關連結：
Q1

對岸的動作之快，連在科技產業也都展現了「中國速度」。北京及上海的雲端基地，及各個地方的科技園區，也都吸引了國際各個企業的駐廠，帶來的產值將難以想像。不過其實台灣到目前也並不是所有的產業都與大陸積極合作，能夠前進大陸的恐怕還是以大企業為主。

大陸發展與台灣合作

在產業的整體方向，雖然還是以電子代工為主，不過有些小眾逐漸走出這個趨勢，政府也積極在「雲端」上投入資金。許多電子代工大廠想要藉著雲端這一個處女地來擺脫國外科技大廠的束縛，但沒有必要的技術人員，可能頂多不會因為專利被告而可以繼續研發下去，但也還是無法有好的獲利。以台灣在雲端科技上的競爭方式，我想可能還需要1～2年的發展才能見誰存活下來。許多大型企業並非採取自行燒錢培育研發人員，反而是與沒有經驗的中小型公司合作，我認為是有可能導致競賽失敗的主因。這些企業也只能自行吸收成本，退回電子代工產業。

台灣產業

Q1

呂學錦：中華電將建國內最大雲端營運中心對下半年營運樂觀

總結

雲端服務的本質

我相信真正好的雲端系統或者是服務的使用，是必須搭配與使用者貼近的設備。這樣的趨勢也勢必會慢慢延伸到家電用品，醫療器材等民生領域。舉例來說，一個雲端的防毒系統，以及一個雲端的老人看護醫療監控系統，各位會覺得哪個有價值呢？儘管來說將設備都連上網路，並不是一個新的想法，但現在有更好的網路環境以及軟體來建設可以服務更多人的系統，這與過去相較確實不同。

要做雲端的事業，是一定需要投入大量資本的。世界各地都有很多公司打著雲端名號，而想要以極少成本搭上順風車，這是行不通的。2011後的使用者，越來越能夠辨別怎樣是一個好的服務，怎樣才能夠利用網路讓自己獲得利益。如同在2008～2010年的狀況一樣，投入資金，讓使用者先享用免費的服務，讓他們覺得自己的需求被滿足後，也才能夠就由使用者互動所創造出的成果，來創造更多服務，來讓便利使用者，這樣使用者才會願意為了更好的服務而付費。

中國速度

自從以及東盟的產生，Google退出中國市場，直到EFCA的簽訂，在在都顯示了中國的策略。中國完成的天河一號，以及接下來的星雲超級電腦，搭配上海的雲端基地，也足以證明中國接著要展現國力。我身為台灣的人民，看著對岸這些新聞，不禁起了雞皮疙瘩。你說台灣電腦不夠多嗎？堆不出一萬五千顆CPU以及相關設備嗎？不，以我所知道的資金及硬體生產量這絕對馬上可行。但台灣除了當初上過top500的國網中心及橘子以外，2010後都已經不在500內了。數量越多，並不是單純錢的問題，而是如何管理整個設施，及更有效地利用所有的資源。進到這個領域，已經是非常需要熟悉高效能計算的軟硬體人員，而並不是組裝就好。

台灣的老闆也好，高官也好，如果不好好改變自己把科技業當製造業的心態，單純只是用仲介，銷售，不實廣告等招數，想說可以繼續混下去，那是不可能的。很快地台灣就會處於純粹做「實驗產品」，「創意產品」的遊樂場了，總是雷聲大雨點小，總有一天也會被世人看穿的。儘管也有人覺得台灣人做這些東西也不錯，甚至沾沾自喜....但試問這個世界有誰會願意將錢投入在實驗性，創意性而無法量產賺錢的東西上呢？我想事實是殘酷的。

台灣科技產業軟硬體的兩難

在這一年中我聽到許多人都問著同樣的問題，「到底台灣為啥要做貨櫃型電腦？做來賣給誰？」直到現在我還是相信，好的硬體要搭配好的軟體，也要搭配瞭解市場的銷售。然而台灣到目前貨櫃型電腦給我的印象，就是沒有好的軟體及銷售。軟體研發問題的核心還是來自於台灣大多數的企業並不重視軟體人才的培育，只重視眼前短暫的利益，而研究所教育能帶給學生的更是有限。這個情況不但沒改善，在金融風暴後為了生存反而越來越嚴重。

一個整合型系統需要的是整合經驗，軟體的人員瞭解硬體的規格與極限，硬體人員瞭解軟體的難處，才能有效地做好系統整合。然而在台灣目前還是可以發現軟硬體人員之間還是有很大的隔閡：軟體的人員覺得除了程式碼以外都不是我的事，硬體人員沒有軟體素養，根本無法理解為啥都可以通電了還要抱怨這個硬體讓他無法工作。這些狀況行之已久，最後造就了許多想要開發軟體卻老是留在電子代工的大廠。先不提那些互相「合作打廣告」卻啥都生不出來的大廠，以及遲遲不降價拿人民血汗錢去買外國產品來做成自己服務再跟民眾收錢的；華碩能弄出自己的雲端儲存，我想這就是台灣在2010年能夠看見雲端的最好成果。然而這樣的成果，能不能有真正的收入，還是稍微有點成果就把資金移到行銷，最後被當作附加價值直到慘遭裁撤，都還是一個未知數。

未來展望

台灣在醫療器材的製造研發，並不輸給日本。雲端不僅可以應用在多媒體終端，行動終端，也可以用在醫療終端。也就是說，與其拿國際科技大廠都可能做到的資訊系統整合與其一較高下，不如拿這些與民生相關的產業，再與資訊整合，這比較像是台灣人的強項。以我所知有關醫療器材，生物科技，音響器材，台灣都有自己的一套，是可以站在世界頂端的。如同我在以前的文章提過，許多中小企業也都是因為卡在自己的系統無法成長到能負擔更大量的使用者，儘管有好的行銷與計畫，但也永遠就是得處理系統的所造成的成本。將軟體硬的架構改善，使得能夠在雲端上擴展，也能夠為自己的產品再殺出一條生路。

闕志克與貨櫃型電腦介紹 / 文茜的世界財經週報 2010.01.10

2010-03-08T00:02:00.000-08:00

花了些時間看完這整段影片，以下是我的一些感想

第一段：

第一段大概介紹了工研院在雲端上的方向，簡單來說就是闕主任提到的「如果能夠有雲端的OS整合台灣現有的硬體」，那就會是完成體了XD

我也說得很簡單...真正的想法還是最後再討論

第二段：

我對於林百里的嘆息覺得非常的有感觸，其實就算到現在政府對於產業發展都還是停在過去。說真的連五都戰都戰不完了，哪還有啥時間去管產業發展呢？

第三段：

看起來鴻海有在代工wii的感應版?
我對代工領域不熟，這個有沒有熟人可以來指導一下XD
不過感覺郭董真的很在意綠色科技，這是一件好事
溫室氣體實驗室...「不讓我們移到大陸去...」哈哈～

第四段：

無人工廠的想法也不是最近才有，不過真的要去實踐的人真的是很厲害
其實Google的Data Center也是一種無人工廠（只是服務的是資訊）
現在大家都朝向這個目標努力

有關溫室氣體實驗室的想法，或許也是一個好方向，但問題還是未來台灣或大陸的政策是不是能夠跟進
我想歐美市場是不用說了，但大陸呢？

有關Google的事情我想大家都可以不用亂猜了，透過這次的節目，證明我說Google有一天會自己蓋核電廠
而且是在月球上，這個政策會與美國在月球上開採HE3是互通的
這真的不是看漫畫之後隨便說說的，我想只是中國沒有Google而已
如果他們做出來了，他們一樣會用同樣的策略

仔細想想這會影響多少人的生活？？
不過別擔心，鋼彈OO裡有關三大國獨占發電生意的事情，我想是不會那樣快發生

第五段：

我發現Ballmer好像老了，雖然從他的頭上看不出來...

大家都說3D電視是下一代看好的
不過我覺得目前還是沒有「民眾」可以接受的應用
實際上大家對3D視覺的接受度還是有限的
更何況那個不需要帶眼鏡的螢幕其實更暈，能當作家用坐在那看幾個小時是不可能的
還是說歐美民眾的眼睛比亞洲民眾還好呢？
反倒是省電高彩度的OLED我想反而是下一代比較適合投資在亞洲市場的

這一塊我真的不懂了，也請網友們指導一下，東盟是在做啥的？
難道OO的世界真的要實現了嗎？

網友有的在影片下面說賣國
我在這裡不是要挑起政治話題（也拜託回文時冷靜一點）
可是這是事實啊
他都說了「差個3％5％，你的產品根本銷不出來...」
這真的不是開玩笑的啊，我想問問看在做出口貿易的網友們是不是真的這個樣子

還是一樣我可沒說我支持「統一」，畢竟要我去配合大陸的資訊政策，對一個台灣土生土長的資訊人員來說更不可能
我很怕我在找Google電廠的資訊被封鎖了（沒事幹嘛要封鎖這個啊XD）
這就是小小工程師的心聲啊...

我不是很清楚說政治上要怎樣解決，留給更有智慧的人們去想吧
但我也算是覺得台灣卡在這上面或許有一天不管怎樣走一定會走到這個問題上
畢竟大海是容不下小川的

--

有關雲端運算的想法：

畢竟我自己現在就是參與其中，我目前還沒有啥言論敢隨便亂說
但我沒有辦法認同影片中提到雲端像是未來發展的關鍵一樣
並不是說我不挺雲端，而是不管是怎樣的東西，沒有應用出來是沒有用的
也因此就如同我以前在「從不同的角度看雲端運算」的個表格中提到的
雲端運算是比較適合商業化的應用
商業化的應用傾向簡單，收支模式及成本能夠受到管理
所以以現在的目標我想真的是做名符其實的「資料中心」
而將來有沒有機會能夠簡化高效能運算的入門門檻，並且提供給中小企業才是真正的問題

如同我說過的不管是哪裡的中小企業都會有「屏障」，如果政府能夠建出一個平台並且以低價提供給中小企業
那太好了，等於說機器成本降低了，讓這些公司專心在發展軟體上
我想第一階段一定是這樣的。
接著廠商們很高興，因為便宜，就像是台灣版的Amazon。

那軟體呢？這下好了，除非他們願意花時間理解，至少一個最低的門檻MapReduce
不然你的軟體要如何用上千百台主機來服務上百萬人？
而且也要開發雲端平台的單位及廠商願意花時間人力成本來「培養」這些中小企業的工程師或是學生
畢竟這個東西不一樣...不是連連MySQL寫些ruby script就會動的
很抱歉上述確實有點悲觀
但反過來想一旦有廠商願意真正投入雲端軟體的開發
並且眼睛是著眼在大陸這樣的大市場（因為你不需要在台灣服務上百萬人，這個時候我又得問問贊成完全獨立的網友們這樣的公司該怎樣生存下去...)
那就很有機會，一個雲端中心就是幫助這樣廠商的好夥伴
我相信這樣的一個廠商相對也救了所有想要開發雲端的單位
因為如果沒有應用去證實的話，光電費就可以讓一堆人收手下台了...

從不同的角度看雲端運算

2009-10-24T18:39:00.000-07:00

這年頭真是有趣，到哪裡都會有不同領域的人問「什麼是雲端運算？」
看樣子廣大媒體的效力真的非常之厲害，但從個人而群聚出的媒體似乎也形成一種效力(Stand Alone Complex)，所以我還是想在這發揮一下個人的效力。

有人說它是「Google」或是「Amazon」。

也有人說它是「MapReduce」或是「Hadoop」。

更有人說它只不過就是「Grid」或是「Cluster」。

或許我的部落格該改成「Kiwi雲端運算開發站」？
Stallman大叔還說雲端運算是蠢事...
(http://www.zdnet.com.tw/news/software/0,2000085678,20132147,00.htm)

觀察一些文章，可以非常清楚大家都是從幾個固定的角度去看他。而並沒有人從發展的角度去看。這些文章有褒有譴，不過多半並沒有全面性地去介紹這個名詞。但是不管是什麼時候的什麼新名詞，大家最關切的是「有沒有發展價值？」

Wikipedia的定義

請參考
http://en.wikipedia.org/wiki/Cloud_computing

Cloud computing is Internet ("cloud") based development and use of computer technology ("computing"). Conceptually it is a paradigm shift whereby details are abstracted from the users who no longer need knowledge of, expertise in, or control over the technology infrastructure "in the cloud" that supports them.

雲端運算是建築在Internet(雲)之上以及應用了資訊科技(計算)而形成的。就概念上而言它只是一種模式的轉移，在這種狀況之下許多技術細節都被隱藏。使用者不再需要相關概念及專業知識，但還是可以「在雲端上」對支援雲端運算的技術平台進行控制。

比起中文版的定義，這個定義非常地清楚。首先他提及了之所以使用「運算」，是因為從資訊科技而來的。總之就是希望使用者瞭解並不是真正計算了什麼數學難題，而是背後有許多電腦來幫助你點了一下的這個動作作了處理，就學理來說這確實是運算。

另一個是這是建築在Internet之上的，當然我想對於年紀比較大一點的讀者來說，從沒有網路到有網路的時代，確實可以感受資訊科技的進步。但對於年輕一輩，打從小時候就一直
接觸網路，根本早就視網路為自來水一樣的東西。也因此，雲端運算本來就是以使用者為導向的，畢竟水龍頭也會從用轉的變成感應的。簡單地來說，就是將原本的網路包裝成更好的服務，並且提供給使用者。只要朝著這個方向走，那不管是誰都可以說自己是雲端運算。

從網路商業的角度來看

許多人認為名詞真正炒熱的主因還是因為有雄厚資金的企業在背後燒錢，除了廣告還是廣告。

但事實上真的也有許多大公司因為這個名詞而一下子推出了許多新產品，其中最明顯地就是這些「虛擬化技術」的廠商都開始推出雲端平台，並且強調自己才是能夠快速協助中小企業發展出「雲端」技術的主力。這有點像是以前還在做網頁網站的時候，許多產品都是打著快速建置的口號，甚至推出證照；但不管如何最後都是得需要人來花時間學習。

從網路商業的角度，大企業的動作，也幫助到許多相關的企業。但到底誰敢舉出自己的財政報告說，他們今年與雲端運算相關的產品賣了多少錢？不是嗎？而如果這些中小企業衝動地想要砸錢挺進而忘記資訊技術的本質還是要自己掌握，不是靠花錢買來的，那如果有一天真的泡沫化了，一定也是這些中小企業先倒楣。

在104人力銀行有關雲端運算的職位，其實也是少的可憐。很明顯是台灣的業界根本不清楚這是什麼，只有少數本來就有關連的企業，如Yahoo或者剛跳進去的趨勢才有類似的職缺。而我相信未來也只有一定財力的公司才有可能選擇投入燒錢。看起來雲端運算對業界的大部分公司來說，有些是在觀望中，但有些是因為根本就不瞭解或是派不上用場。

網路是無遠弗屆的

這些中小企業，如果要在未來的商業殊死戰中求得生存，依賴網路是必須的。而至於要不要將自己的企業服務「雲端化」，也還是得看資金與構想。如果不是大家需要的服務，再怎樣燒錢往雲上爬也沒用。

而使用者往往是最大的贏家，如果資訊傳播的媒介越多，那一定會有更多整合資訊的廠商起來競爭，那使用者就可以用更快的速度接收及分析資訊。廠商在實做時能夠注意資訊的本質，加速使用者之間資訊的流通；能夠注意設計的本質，不要違背使用者共通的需求，專心以服務作為己任，相對的使用者也一定會願意付錢給這樣的廠商。

從資訊技術發展的角度來看

我在「雲端運算、網格運算與P2P運算」中有提到，確實雲端運算早就在很久以前被認定是一種「透過Internet來進行運算」的技術，並且已經實行很久。或許你不是間接享受到提供計算之後的服務，但至少你是直接提供計算資源的人。用個簡單的方式講，雲端運算本來的定義就像是在所有人家的樓頂裝上太陽能板，所蒐集的電力再拉到台電，然後看看台電能不能給所有人免費的電力。

而真正目前可以在定義上被稱做雲端運算的，也就是由所有人家裡的電腦來提供計算能量的BOINC運算平台，其中最知名的就是Seti@HOME，在家尋找外星人計畫。這個構想實現了網格計算裡無法實現的夢想，真正地使用不同作業系統的電腦(異質性)來進行累積性的高效能計算。因為運算資源都來自大家的桌上型電腦(Desktop Computer)，所以也有一個稱呼叫做「桌面運算」(Desktop Computing)。然而現實狀況是，如果真的要靠全國的太陽能板來發電，那台電一定倒掉。不管如何一定還是要靠核電或是傳統的發電廠。而任何BOINC運算計畫真正直接獲利的人，也並不是提供運算資源的各位，而是發起該計畫的少數科學家。而另一個與一般計算不同的代價，當然也是要進行計算的程式必須經過一定的改寫。

但這樣的解釋，我想一定不是由大家所接受。畢竟各位在聽到桌面運算或網格運算之前之前，就已經先聽到了媒體所說的雲端運算。然而事實還是不管大家能不能理解世界怎樣進步，世界都會依照他自己的腳步走。

我相信造就這一次的進步最主要還是大家都有意識地將使用者介面改進了，也就是Web 2.0這個名詞出現的的那前後半年。網路其實已經累積許多能量，最後就剩下有沒有介面能夠將這個能量放出來用。至於另一波網路改變的時機，我相信也是類似現在這樣的模型，等到資料累積久了，那就看看有沒有突破性的使用者介面誕生。畢竟人類不可能總是用鍵盤打字，總是用滑鼠滾輪及瀏覽器看文字圖片。

下一世代的網路傾向讓網路本身來理解人類的意圖，也就是Semantic Web，語義網，也可稱做是Web 3.0。網路本身不僅是要累積人類的文章，知識，還要有能力將這些知識轉變為可以重複利用的東西。從學理的角度來看，一旦搜尋的演算法可行，那接下來一定就是分類了。一旦這個技術成熟，到時候對於Yahoo或者是微軟這些後來才開始做搜尋服務的一定是非常重大的打擊，表示它們離網路的控制權越來越遠了。

有關語義網的相關文章如下連結

http://www.w3.org/2001/sw/

http://www.w3.org/DesignIssues/LinkedData.html

http://linkeddata.org/

從資訊相關領域的人來看

(圖片出處)

其實對於還在學或及將要大學或研究所畢業的學生們反而不用擔心，我想現在正是一個緩和的時間，能讓個人的直接就接觸新的觀念而不被舊有的觀念綁住。熟悉於利用網路尋找及接受新的資訊情報，也往往會對於自己未來的工作有正面的加強。總之還是維持自己的腳步吧！

然而對於已經工作一陣子，或是當兵到一半的，未接受新資訊的人來說，這幾個半年應該是最痛苦的吧。因為跳出來的新名詞實在太多，根本無所適從。加上媒體的炒作，我自己都遇到好幾個社會新鮮人或者是大哥大姊想要瞭解有關雲端運算的意義。相對於這個狀況，年輕一輩的往往是沒那樣擔心。而這些資訊相關領域的人，我想也只能夠建議雜誌看個幾本就夠了，因為內容就是大同小異。而如果能夠回去翻翻以前學習的課本，從計算機概論中想想資訊的發展，就可以讓自己從更高的角度理解這只是進化的其中一環而已，用不著太緊張。

但如果是未來想要從事相關工作或是本來就是相關領域想要跳槽的，那讀讀wikipedia，瞭解一下有哪些相關的技術名詞就很重要，去面試才不會被片面的名詞嚇倒。至於已經收到大老闆指示要衝雲端的人，我認為最先學習的還是分散式計算與網格計算吧。稍微心裡有一些關於眾多電腦如何處理大量資料的印象會很好，再來瞭解MapReduce也才不會怎樣也想不透為啥可以動，或者是以為世界上只有這一種方法可以做雲端運算而已。如果能夠涉獵一些高效能檔案系統相關的知識會更好，畢竟I/O在各種運算中都會是問題。

對於非資訊領域的人來說

(圖片出處)

在這個世代，光會資訊已經沒有啥用了。

其實這個世界上還是有很多人願意分享自己的資訊技術，並且相信與非資訊的人才合作才能真正讓大家都找到共存的出路。雲端聽不懂沒關係，Facebook才剛開帳號也沒關係。會應用這些服務的人並不是就很行，有些想法做資訊的人一定會有盲點。使用者不是多就好，服務也不是快或穩定就好。

資訊的概念往往來自於人類的生活中，例如說一個很龐大的技術架構，像是虛擬化，你也往往能夠在現實生活中找到。從應用的角度我可以舉一個例子，以往很多大企業的客服部都需要很多客服人員，大家都要佔用一台電腦。真的去灌一台電腦，MIS部門沒啥問題，如果新招募了50名客服，需要50台電腦，那MIS部門就會抓狂。此時如果我是MIS部門，我當然希望就用現在有的10台電腦資源，去讓他們當作是50台電腦用。最簡單的方法就是叫那些人排班，以前也有公司買一台電腦可以接第二組螢幕鍵盤滑鼠的東西，但畢竟這也不是真的夠用，於是虛擬化技術就可以在這邊使用。而VMWare後來推出的VDI，以及微軟原本的伺服器虛擬化都是為了解決類似的問題。能夠從生活中去想到解決方法，在問問資訊人員有沒有類似的方法，往往能夠找到不錯的答案。

而這些技術該用在哪，往往資訊人員自身不會想到或發現。

從高效能計算的角度來看

(圖片出處)

另一種說法提到了雲端運算只不過就是分散式計算的一種，其實這也沒有錯，這當然還是把所有電腦串在一起。

如同Mr. Saturday發表的這篇文章
http://mmdays.com/2008/02/14/cloud-computing/
下面的討論就挺有趣的。

而我針對所謂「概念上的區別」不禁想要提出一個觀念。學資訊的人大概都有聽過電腦中儲存裝置的階層架構，例如下圖：

(圖片來源 http://www.cs.sfu.ca/ )

從CPU裡的快取記憶體到主記憶體，然後到磁碟(磁性儲存)，然後才到光碟儲存及磁帶儲存。這個階層代表了不同的速度，記憶體最快。但如果以容量的角度來看，卻是磁帶最大。

我認為這個觀念也同等地對應到分散式計算的這些分支上，如下表。

其中介面友善的比較，預設以網頁的介面，讓使用者還能在上面進行他們想要的工作為最佳，並非只是閱讀文字圖片而已。回應速度的意思是，當使用者下一個指令會進行一個目的(像是程式計算)，這個動作平均要多少時間才能完成，這個評估當然也與平均的邏輯CPU數量還有程式的目的有關。資料量是指一次的計算平均能處理多大的資料，而並不是可以儲存最大的資料；但在P2P運算上，由於沒有計算，所以就直接以儲存量來評估。邏輯CPU數量指的是作業系統所判斷出來的CPU數量，例如一個四核心有HT技術的CPU，那邏輯CPU應該有4x2=8個，而以桌面運算及P2P運算的角度都預設網路上的電腦提供1個邏輯CPU出來進行運算。

異質性指的是從作業系統(Windows, Unix, MacOS)及硬體基本架構(32bit, 64bit)的差異性有多大，相對的名詞就是同質性；用簡單的方式來說就是同規格或是不同規格的電腦。至於使用異質性的階層化或分群混合方法，是不得以的，再怎樣也不可能讓所有電腦的規格相同；相對地也可以想像要建造同質性又高效能的電腦，要花上多少錢打造同樣的東西然後讓它們排排站好。造價成本是從提供服務者的角度來看的，為了建設或利用這些電腦要花上多少成本，包括人力物力電力等等，而並非使用者(使用者都是不花錢的)。在桌面運算中所提到的用戶，是指在網路上提供電腦給科學家進行計算的人，也是BOINC的Client端，而科學家是建立BOINC Server端的人，也才是真正的使用者。應用領域也很簡單地分類了。

	介面友善	回應速度	資料量	邏輯CPU數量	異質性	造價	應用領域
高效能計算	不友善，大多都還是用指令。號稱有Portal的其實都不好用。	最快，多半都還是使用C或C++來撰寫平行化的程式，或是搭配硬體做最佳化	中等，大多數的計算都是數十至數百GB。除非搭配造價高昂的I/O裝置，否則非常少有人能處理超過TB等級的資料	最少，數百至一萬多	幾乎不可能，而且容錯能力也很低	非常昂貴	科學計算，軍事用途
雲端運算	非常友善，幾乎都用瀏覽器	中等，大多數的工作都在背景完成。利用預先產生好的結果讓使用者覺得很快	多，資料量非常龐大，輸出量也大，一次運算都可能是上TB的資料。	中等，以2006年Google公布的主機數量可以推測現在已經累積超過10萬個邏輯CPU	混合型，將同質性的電腦以階層化且異質性的方式組合，容錯度高	機器便宜，但開發及人工昂貴	商業服務
網格運算	不是很友善，儘管有網頁介面但多數還是使用指令	快，與高效能計算類似，但因為一些CPU時間被中介軟體消耗掉，所以比較慢一些	中等，與高效能計算類似	少，可能到5萬個邏輯CPU	混合型，將同質性的電腦以分群且異質性的方式組合，如果錯誤點(Failure Point)損壞的話會造成較嚴重的狀況	就整體而言是貴的，不過以單獨一群的角度來說也會有人使用便宜的機器	商業服務，科學計算都有
桌面運算	中等，指令，視窗程式及網頁都有	很慢，許多時間都花在伺服器及用戶間的資料傳遞	少，通常是幾GB至數十GB的資料。雖然也是能處理上TB的資料，但風險太大，所以通常都是切割成較小的資料。	多，以BOINCstats最近的紀錄都有400多萬的主機	完全異質性，都是不同的作業系統及主機在計算	進行計算的人幾乎不用負擔成本，因為都轉嫁給用戶。他們只需負擔數台伺服器的營運以及公關廣告而已。	目前只有科學計算，而且用戶並未直接享用利益
P2P運算	中等，視窗程式及網頁都有	最慢，許多時間都花在用戶將資料互相傳遞，而目前也只能傳資料	最多，一個伺服器能索引3~5百萬個檔案，雖然有點不公平，但如果以檔案數量去推算容量應該龐大到難以統計	最多，一個中介伺服器裡通常都有30~50萬的主機連結中，而統計伺服器的數量，以及有許多不同的P2P軟體，可以估計全世界有上千萬的人都在用P2P	完全異質性	最便宜，你到現在養小動物都沒花過錢吧？	雖然有商業服務，目前只能做資料傳輸，或許未來有一天能夠讓使用者在上面運行程式

而這篇文章
http://www.blogjava.net/myqiao/archive/2009/05/06/269308.html
也有提到許多反向的思考，但是從文章中可以體認到一般的迷思：就是名詞太多了，所以把各種不同的觀念混在一起了。

結論

我相信從不同的角度看事情會有比較全面性的感受。當然在寫文章的過程中，我也體認到自己的認知也不過就是網路資料中的其中一個而已。但可以觀察網路上的許多說法，其實都沒有太考慮到演進與變化。而且一些人的認知是從教科書來的，所以才會人有認為網格技術「應該是要」解決了異質性的問題，不過真正解決了這個問題是桌面運算，但它又產生了新的問題。

我想人類到現在的資訊科技已經相當進步了，在看表的時候，也可以順便想像成一個金字塔。確實在頂端的高效能計算才是真正花大錢的科技結晶，也可以代表一國的國力。雲端計算在第二層，可以想像為企業的力量。第三及第四層多半是由學術及第三方單位串連構成的。而剩下的就是廣大的網民了。

然而我真正相信金字塔下層也會有其實力，只是這個力量目前是分散的。

我在其中也思考了中文名稱定義的問題，其實除了高效能「計算」之外，其他說真的跟計算沒多大關係。我想畢竟計算這個字眼，還是跟「科學計算」相關的，是真的得算上一些東西的，所以其他就都採用「運算」了。

搬新家

2009-10-11T10:19:00.000-07:00

說實在，kiwi.csie.chu.edu.tw這個網域很明顯地就是和系上「借來」的。用了這樣多年，還真是感謝管理伺服器的學弟們。

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

新的網址將會搬到

http://kiwi-grid.blogspot.com

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

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

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

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

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

維修

2009-09-09T09:49:00.000-07:00

上個星期發現dlink GB switch壽終正寢，真是辛苦他了，趕緊調整一下設備的配置把一台新的換上。近來也發現我的機器有一些怪封包亂跑，看樣子也該是時候花些時間維護一下。

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

趨勢2009騰雲駕霧程式競賽

2009-08-03T09:08:00.000-07:00

http://www.trend.org/contest

教學部落格

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

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

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

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

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

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

為何你需要Map Reduce，話句話說你可能不太需要？

高效能計算理論，程式如何平行化？為啥會加速？

Divide and Conquer 與 Map Reduce 適用的題型

要做一個可以平行擴充的系統需要什麼？如何在Cost / Scale之間取得平衡？

如何有效地管理好硬體或軟體上可能發生的錯誤？

為啥我不能讓用戶來分享我的計算負載，成為真正的雲？

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

##CONTINUE##

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

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的路吧。

ISGC 2009, Symposium Day3

2009-04-24T03:07:00.000-07:00

第三天的重點在Grid & Cloud，雖然有些是與Workshop重複的，不過還是有好玩的東西。

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/

ISGC 2009, Symposium Day2

2009-04-22T10:13:00.000-07:00

很慘的是，第一天我真的掛了。

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

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

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

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

ISCG 2009, iRODS Workshop

2009-04-22T04:41:00.000-07:00

iRods是Reagon Moore帶隊開發的DataGrid中介軟體，他是SRB的下一代。這個Workshop介紹了很多iRods的觀念，並且包含一些實作。

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)

ISGC 2009, BOINC Workshop

2009-04-18T05:34:00.000-07:00

這是我第一次參加ISGC研討會，不過在研討會正式開始之前，有幾個Workshop

詳細的資料可以參考：

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提出的觀念，讓人類用看的去將地圖做切割，不過這要做多久呢？

科學與計算

2009-04-02T04:01:00.000-07:00

最近看了ericsk的文章「資訊系究竟在學什麼？」，我也稍微有感而發。

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

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

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

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

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

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

Google App Engine, MapReduce與資料處理

2009-03-03T06:49:00.000-08:00

去年夏天的時候，Google大肆炒熱AppEngine的平台，讓使用者能夠撰寫自己的程式，並且放在Google的雲端計算環境上執行。

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(" "))，並且使用字串建立起索引
在這一段

def Map(self, document_title, document):
  for token in list(set(document.contents.split(" "))):
    if token:
      yield token, document_title

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

def Reduce(self, token, document_titles):
  yield None, DocumentIndex(token=token,document_titles=document_titles)

定義了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工程師們本來就在用的功能從內部能還原出來，並且讓大家可以試著去執行看看。

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

VMWare虛擬化叢集建置

2009-02-03T09:41:00.000-08:00

介紹

前虛擬化技術的現況有提到過一些虛擬化技術對個人以及軟體工程師的幫助。大概在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清單：

hostname	ip
vmware01	10.1.1.11
vmware02	10.1.1.12
vcserver	10.1.1.21
iscsiserver	10.1.1.22

建置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/下載。

tar zxf iscsi-target.{version}.tar.gz
make; make install
編輯/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
chmod 700 /etc/init.d/iscsi-target
service iscsi-target start
chkconfig --level 35 iscsi-target on

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

yum install iscsi-initiator-utils
service iscsi start
iscsiadm -m discovery -t sendtargets -p 10.1.1.22
對iscsi server進行查詢
iscsiadm -m node -l
如果查詢成功的話，就進行連接(登入)
fdisk -l來看看是否有多新的scsi裝置
iscsiadm -m node -u
如果要中斷的話，就登出
如果沒有清除紀錄的話，只要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的設定大致上是這樣，我們再將步驟整理一下：

點選「Enabled」來啟用iSCSI
新增Dynamic Discovery IP
Rescan

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

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

高可用度(HA)叢集設定

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

在根目錄上新增資料中心(New DataCenter)，一個資料中心代表最上層的管理組織，但無任何可以設定的項目。就像是Folder一樣，但比較有代表性。
在資料中心下新增叢集(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暫停。

步驟如下：

選擇目的地：展開樹狀圖來選擇你想要的主機，如果驗證未通過，那就要看出現的訊息是啥。
選擇Resource Pool：基本上Migration可以跨DataCenter。
選擇儲存裝置：根據你選擇的主機，可以在選擇已經在該主機上設定好的儲存裝置。
完成。依網路速度及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整體的操作模式，以及貼心的小設計。但無論機器怎樣方便好用，怎樣聰明自動化，還是需要瞭解其技術核心的管理員來輔助，免得出了任何手冊上沒寫的狀況，就無法處理。

雲端運算、格網運算與P2P運算

2008-09-20T05:27:00.000-07:00

在6月的Google Developer's Day活動前後，媒體報導了有關雲端運算的事情。有些也冠上了滿誇大的標題，說雲端運算是Google的武器...或是IT的明日之星...等等的。但其實這也和「Web2.0」這個名詞的出現一樣，多半有廠商在後面的推廣，舊酒新瓶裝。但實際上，各位也是從以前到現在就都在「雲」上，只是Google將自己的三個核心技術，與網路的使用者們，一起包裝成新的名詞叫做雲端運算。

9月10號凌晨3點的時候，CERN的大型強子對撞機(LHC)投入了第一個質子束，一個月後就要進行第一次對撞。LHC一年能夠產生15PB(15,000,000GB)的資料量，如果以一張DVD9來算的話，那就是166萬張了。但要怎樣能夠將這些偵測器得到的原始資料進行龐大的運算？這個時候就要靠著分散式運算來得到結果。而其中一種分散式運算的技術，我們稱做格網計算。

我希望透過這篇文章，讓大家了解電腦的運算歷史，以及未來每個人手上的電腦，又會被放在世界的哪裡。

運算(Computing)的歷史

運算(Computing)，又被譯為計算。也因此用來計算的機器，當然就稱做為計算機了。但在台灣的譯名，放在手上輸入數字那種才叫計算機(大陸叫做計算器)，而Computer就是電腦了。計算的意義便是，有一群資料，透過一個流程將這些資料進行加減乘除，或是更複雜的數學運算，來得到想要的結果。

在討論計算的歷史的時候，同樣地也等於討論到計算機及電腦硬體的歷史。從算盤，到巴斯卡計算器，再到真空管電腦，直到現在的IC電腦，電腦計算的速度可以說是指數成長。而在IC電腦已經這樣普及的時候，人們也早就習慣研究數位化的計算方法(演算法)，並且將資料數位化後進行計算，在將這些計算後的數位資料，又轉回人可以理解的圖形或是文字資料。

這個時候CPU的設計也慢慢地開始從一台電腦只有一個CPU，到有多個CPU。在1970年代左右，計算的重心是放在超級電腦(Supercomputer)上。此時所發展出來的平行計算(Parallel Computing)的能力，足夠代表一個國家的科技水平甚至是戰爭科技。在當時也只有擁有超級電腦的國家，才有能力進行精確的彈道計算。換個角度不難可以想像，資訊科技及戰爭是相輔相成的方式互相成長。我們通常以FLOPS(FLoating point Operations Per Second)，也就是每秒能夠進行的浮點數運算數量，來代表電腦的運算能力。今年六月的時候，IBM的Roadrunner以1375.8TFLOPS創造驚人的數字，也就是說這個超級電腦每秒可以進行一千多兆次浮點運算，而其他的超級電腦也有5~600TFLOPS。讀者們還是可以想像，這些超級電腦從以前到現在，大多數都還是在美國。

而我們計算的資料，也與以往大有不同。早期透過人工可以輸入，計算並理解的資料，100KB就已經是龐然大數。然而現在的資料量動則就已經上GB或是TB，已經不可能在透過人工的方式輸入。而這個時候許多自動化的輸入輸出裝置也相當普及，許多公司如IBM早已生產上百萬台磁碟儲存系統，每台都可以儲存上百TB的資料。另一方面像LHC所使用的偵測器，也能夠在很短的時間累積大量的數位資料。

很快地我們就發現，這樣的上TFLOPS的計算能量也無法完全滿足我們想要計算的資料量。

所以從二次世界大戰帶來了網際網路之後，運算開始走向許多台電腦一起進行，而並非以前的單打獨鬥。也因此從平行計算逐漸開始有了不同的分支，一個是利用網路將多台電腦串在一起，我們稱做分散式計算(Distributed Computing)，另一個是原本的多CPU技術(SMP)，逐漸往多核心(Multicore)的技術發展。分散式計算，根據分散及構成方式不同，在分做網際網路運算(Internet Computing)，叢集運算(Cluster Computing)，格網運算(Grid Computing)，P2P運算(P2P Computing)，以下就讓我來介紹這些運算方式。

Internet運算和雲端運算

在我過去的文章曾經討論到，在還沒開始Web 2.0的時代之前，人們的在瀏覽器上的輸入，不管是填寫的表單也好，或者是搜尋的關鍵字也好，都已經是構成大量輸入的動作，但這些資料並沒有啥關連性。在Google還沒成名的時候，很多人就已經投入搜尋引擎的研發。後來Google卻將這個技術建構得非常紮實，讓這些資料有索引，也讓這些資料關連越來越密集。儘管2004的時候尚無網際網路運算這個名詞，卻可以視作現在雲端運算的前身。

由於網際網路實在過於龐大，無法以一般的方式進行測量，只能夠提及這個代表性的計畫，Seti@HOME。Seti@HOME計算的目的是收集宇宙的電波，並進行快速富立葉轉換的演算，來變成電腦可以分析的資料，藉此來發現有沒有外星人的存在。利用BOINC的分散式計算系統，透過全球33萬台電腦，在今年八月的時候達到了528TFLOPS，相當於上述的超級電腦。而LHC也有使用BOINC進行一部份的計算。

可以想像全世界的電腦一定多過於這個數字，就知道未來雲端計算能夠發揮的能量有多大。

而現在不管Yahoo還是微軟，都與Google一起爭奪這個龐大資源。因為雲端運算不僅牽扯到全世界的電腦，也包括全世界的使用者。如果能做出更好的平台，更好的服務，讓更多使用者涉入，那就有更多的商機。

儘管雲端運算看起來像是驚人的科技，但也有缺點。要將世界的電腦組合成有用的資源，除了像BOINC平台去進行特定計算或跑特殊的程式，以目前的科技還無法這樣隨心所欲。我們還無法做到讓使用者想執行的程式，想解決的問題，都變成拿地球上所有電腦去跑。也因此，不管現在這科技三巨頭怎樣做，都還是以自身的經費所建置的運算資源來達成。也因此從這些公司口中所說的「雲端」到底是否有真正運用到網際網路上的電腦，還是一個大問號。但不可否認的是，他們耗盡研發能量，經費構成的運算資源，都會讓全世界的人有機會「使用」，甚至是免費的，這樣就不是一般的中小企業做得到的。此外以一個企業的經費到底能夠產生多少運算能量，也一定有個上限。

儘管如此，雲端運算能夠讓眾人自由甚至免費使用，還是一個相當大的誘因。其使用能夠帶給企業更多的利潤，這也是企業所希望的。人類日常生活的資訊會因為他們手上所持有的裝置(手機，PDA)，或是電腦的規格慢慢提高，而能夠產生更多的輸入，企業能夠去整理分析這些資料，並且創造更好的服務回饋給人類，我想是會讓生活更好。

所以雲端運算，重點並不是在其運算能力，而是應用與服務。這個目的與原本的網際網路是相同的，也因此大家從以前到現在，都一直是在雲上。

當然換個角度，對於學術而言，就不見得是要求服務，而是真正的運算能力。現在的科技能發揮多大，就要讓他能夠多大，是一直以來資訊科學領域的人員都在努力的事。真正在進行運算的是誰？誰願意在雲下呢？

格網運算

格網運算的發展

比較起上面雲端運算，另一個分支就是著重高效能，串連各個CPU的運算能力，而非著重在服務上，我們稱做叢集運算。然而叢集運算也有部分技術，構成現在雲端運算的底層，像是負載平衡或是備援技術，都在我的文章中有說明過。而叢集技術，也已經成為現在超級電腦的核心技術，否則光靠一台電腦也無法達到上TFLOPS的水準。如何榨出CPU的每一分運算能力，如何擠出銅導線的每一分傳輸能力，都是在叢集或是高效能運算的主題中討論。

叢集運算雖然效能強勁，但成本也高昂，並不是一般的民生水平能負擔的起。因此以商用硬體(Commodity Hardware)所組裝的電腦，便慢慢變成另一個主流。這個情況在國內的大學也常見，教授不見得買得起一整組叢集，反而是逐次分批購買小電腦，再以軟體的方式合併在一起使用。而許多應用在叢集電腦上的函式庫或作業系統，也慢慢地改變並且移到這些商用電腦上執行。其中Unix作業系統，就是從大型工作站，慢慢演進成現在一般人都可以使用的最好例子。

另一個叢集運算的缺點，也在於需要完全同規格的硬體。不同的硬體，不同的環境，很難組合在一起運作。軟體上也有同樣問題，為了效能，可能針對作業系統的版本，使用的函式庫來限制，讓不同的站點(Site)之間必須開發許多的轉換程式才能整合。此外，跨網路區域，例如說大學與大學之間，連線與使用的時候都會遇到安全性的問題。為了解決這些問題，於是又衍生了另一個技術，稱做格網技術。

格網這個名詞，在英文中，比較多被用在電力格網(Power Grid)這樣的名詞中。也有人稱為網格。而在格網運算的始祖Ian Foster的論文中，便把格網計算的遠景，形容為就像電力或水力一樣，想要用的時候打開就有。然而格網運算，常會被拿來與叢集運算比較。從叢集運算起家的老教授們，也常常地難以理解既然沒那樣快，又為何需要格網技術。

在格網運算中常常會提到虛擬組織(VO, Virtual Organization)，與W3C的技術規格。其實格網運算就是利用現有的叢集運算以及Web觀念當作底層，也有人說格網技術是下一代的Web 3.0。但格網技術是完全不同的目的，最主要還是增加資源的利用性，而並非只是求一個效能。

也因此，資源的收集，控制，服務，就成了格網中介軟體(Middleware)要完成的事。我們可以試著將這樣的觀念想像為漏斗，漏斗的下方是資源，由中央的中介軟體進行收集，再由更上層的軟體去應用。而這樣的觀念也逐漸擴充到別的領域，包括資料格網(Data Grid)。中間所有的協定，都以W3C所制訂的規格為主，如HTTP，XML等。也因此這樣設計的中介軟體，可以用來管理上萬台甚至數十萬台電腦，並且將其納入運算或儲存資源裡。

不管是美洲，歐洲，東亞都有許多的格網計畫及組織。這些組織各自在物理，化學，生物上都有許多極佳的表現。其中一個就是由現在熱門的大型強子對撞機計畫所發展出的歐盟e化科學格網計畫(EGEE)，目前已經有250個站點，四萬多個CPU同時進行運算，其運算量已經超過一個國家所能夠產生的。台灣也有許多格網計畫，像是中研院的TWGrid，以及清華大學的Unigrid。而國家高速網路計算中心也推動了許多格網計畫，如醫療格網，氣喘格網，超級視訊格網...等。

但談到這邊，我們又不禁感到疑惑，

「這些格網計畫與我何干？」

「我並沒有聽過太多這些東西啊？」

「我的生活並沒有因為格網而變得比較美好。」

格網技術現在都還在研究階段，不管是業界，或是民生，要使用到格網技術帶來的便利，還要相當長的一陣子。

下一代的P2P運算

P2P的重要性

談到P2P大概會有許多人會想到驢子(eMule)與BT(BitTorrent)，而且許多人在用的Foxy，迅雷，甚至使用者也不知道這些是P2P的軟體。在使用上，使用者完全有個直接的想法就是「下載」，即便過多的查詢封包會縮短他們網路設備的壽命。我認為資訊科技能夠讓使用者有這樣大量的需求，並不是在於技術本身，而是使用者能夠透過這些技術獲得什麼。使用者會希望透過P2P技術下載，也不外乎是因為這些網路上有著最多免費或盜版的資源。許多電影，音樂等需要著作權才能生存的組織不斷地與許多反盜版組織合作，甚至利用伺服器散播假檔；但許多P2P技術，分享方式，論壇，鄉民人力不斷投入...雙方的大戰就這樣持續已久。

實際上，現在所有流行的P2P技術，都還是最簡單的Flooding(像洪水一樣擴散訊息)，並不包括任何控制訊息數量的方法。更別提是否使用到哪種很有效的P2P Overlay結構，可以讓關鍵字搜尋更聰明，或者是提高覆蓋度來讓搜尋更快。至今(2008)，許多P2P技術仍在論文的階段，即使有了些成果，也都還是不穩定的技術。

我們所面對的真實問題

舉個例子，如果今天每個人的電腦，都很夠很穩定地儲存自己寫的部落格(而且自家電腦又快，不用等某X小站龜速的回應)，只要你敢寫，永遠不會不見。那再加上如果有個地方，用很簡單的方法訂閱，讓大家可以「看見」自己寫了新的部落格文章，那有多好，是吧！

那對服務提供的業者呢？一來，業者不需要承擔資料消失的風險，因為「有種方法」可以讓資料永續存在，不因用戶重裝電腦而消失。二來，業者只要定期地去分析分類索引，做個首頁讓想要看的人可以快速地連到「某台電腦」並且讀取網頁就好了。這個某台電腦在哪裡，已經是一個大問號。而這個問號的背後，又遇到一個情況，那就是如果一個台灣人想要讀一個在美國的好友的部落格，因為相隔甚遠，勢必要遇到一些讀取緩慢甚至失敗的問題。

而最後的疑問還是，根本無人可以保證上一段話「」裡的那兩點。沒有方法可以保證資料的存在性，也沒有方法可以在提供資料的用戶關機後還能夠確保資料被讀取。

該怎樣解決？這個時候便讓我想起攻殼機動隊電影版第一集裡的一句話：「網路是無遠弗屆的」
我們接下來再來討論這個問題。

群聚性

我個人相信，未來的幾年，P2P技術一定會慢慢地與Web和Mobile技術結合在一起。人們會慢慢開始發現，他們每一個連結並散到網路上的訊息，都會讓他們在各個層面發現與自己類似的人。舉例說，當你在使用Last.FM的播放器，將你聽過的歌曲資訊傳到網路上，雖然只是一個小動作，但其實使用者在聽歌的時候，無非也只是想要認識能夠一起聽歌的人，不然就是希望可以找到更多免費且類似的歌曲。人們不管是使用哪種服務，總是希望可以螞蟻雄兵，藉群眾來獲得更大的效益。

而一間公司是否能有效率地使用用戶端資源，也就變成這間公司的一個最大的命脈。儘管他們有非常多的創意，當服務資訊瞬間累積的時候，他們也會發現根本毫無能力可以儲存，分析，計算。而那些能夠分析的公司，也通常是大企業，因為他們有雄厚的資本額可以建立這些分析的機制。當初Google也是藉著搜尋技術以及廣告而起家，才能有資本；而許多小公司，連技術都不見得可以拼得過，又能夠累積多少用戶來強調他們的廣告能見度，藉此吸引廠商？想要藉著新技術，或是以老鼠會的方式來招攬人頭客戶的方式根本行不通。

我想，真正能夠顧及使用者需求，並讓使用者享受功能的時候也付出，才是歷久不衰的道路。而如今，我認為P2P的網路結構正是符合這種意義，並且有效率的方法之一。在設計服務的同時，不妨也思考一下這些提供資訊的節點互相連結的方式。別用別單純地Flooding的方式，期待使用者的訊息慢慢地傳到分析用的伺服器，或許也可以思考怎樣構成一個有結構的網路(多維度，圓環狀，階層化...等)來加速同類型使用者的群聚性。從另一個角度說，就像是訊息傳遞的更快的社群。

中介資料

一方面讓網路產生群聚性，而另一方面，使用者就要積極地產生資料，來讓網路能夠分析並且群聚。

在我寫到Web2.0有關的幾篇文章裡有提到，Web 2.0便是有這樣的特性，讓使用者不斷地去輸入以便產生資料。這樣的資料我們稱做中介資料(Metadata)，也就是描述資料的資料。

舉例來說，你撰寫了一篇遊記，這篇文章裡有十個關鍵字，都是這篇遊記裡的重點地點，像是「台北」「新竹」。你上傳了一些照片，裡面有這些照片的座標。那麼這個時候，搜尋引擎就分析這些中介資料，來讓大家在搜尋台北和新竹的時候能找到你。而這不僅加速了搜尋引擎的效率，因為他不見得一定要掃瞄整篇文章才能做索引，同時也加速了這篇文章定位的準確性。

在舉個分享檔案的常見例子。假設我是一個喜歡電影的人，而我在我的興趣裡寫說「電影」。如果是以往，我要找到跟我有同樣興趣的人，並且互相交換電影，那就是先在交友網站認識後，剛好也發現對方也在開驢子或BT。但如果分享軟體本身就整合了Social的功能，使用者平常在編輯自己的相關資料的時候，也同樣地更能增加下載軟體的群聚性，增加下載速度。

如何整合

格網的優點是整合，而P2P的優點是搜尋，鬆散。比起以往使用某一種格網使用的傳輸協定，去包裝P2P的傳輸協定，未來整合的方式比較著重在將格網層的資源要求，轉換為P2P層的資源要求。舉例來說，如果有人對格網服務要求一個檔案，那這個服務便馬上要對下層的P2P網路進行搜尋，看誰有這個檔案。也因此P2P網路就比需採用更快的Structured Overlay，並且與上層的格網服務作緊密的整合。整合SuperPeer或許是一個加快網路查詢的方法，但也會給SuperPeer太大的負擔，因此這樣類型的節點，要能夠地轉移。

而檔案要如何保持存在網路上，也是一個問題。目前有相當多的研究都是著重在複寫(Replication)演算法上，許多複寫演算法要能夠探知整個網路的狀況，檔案的存在度，是非常繁瑣的作法。而我相信未來的電腦無論cpu，網路速度都會提昇，將網路的中介資料切割後再逐漸掃描，會是一個趨勢。

結論

在未來，每個人手上都會有一台以上的電腦。大家都會有手機，桌上型電腦，甚至數位相框，電冰箱...等家電也都是電腦。而這些電腦一旦串連起來，將會產生相當龐大的計算能力。你手上的電腦，將是維持世界運轉的一小小動力之一，當你使用一個方便服務的時候，也可以想想有些資料是從你的手機上貢獻出來的。

慘啊

2008-09-12T09:10:00.000-07:00

冷氣壞掉...拖了好一陣子

不過最近剛好也都處理的差不多了，也升級到WP新版了...

一星期的Google Developer Day

2008-06-16T17:36:00.000-07:00

說真的這幾天實在是令人覺得驚奇

打從聽到Jeff發現我的作品也被選上，到公關公司打電話來
星期三過去看見73樓這些令我讚嘆的景色
直到記者會...直到星期六上台這10分鐘
總覺得好像在夢境中

不管怎樣，還是很給感謝Google給我這個機會展示
儘管還有許多功能還要加強，而且ok17go整合apps engine也已經是勢在必行了
我想接下來我有一些重要的任務就是，趕緊多帶一些學弟們一起開發
不然使用者們想要的功能就要等很久了

星期三基本上是去談一些初步的方向，例如說當天該怎樣簡報，也認識到了Caroline，Josie，Jessica，Andy等人。大家一下子就聊開了，其中Jessica一直讓我覺得很像我一個國中同學，大家都叫他奧莉薇XD。Caroline很招待我們，各塞給我們一個冰淇淋，還有一堆零食帶回家。文化是的確不同，但還是有點不好意思。

其實我心裡一直覺得能夠在73樓看風景，就已經不枉此行了吧。

星期五的時候就相當地混亂了，這是我人生第一場參與類似記者會的活動，實在是相當地緊張。儘管好像我們這組收到有關於簡報的內容有點誤解，其他都有DEMO，但我們是透過投影片，但也沒關係啦。雖然林大哥講的很生動，但我心裡想還是未來真的能夠有實質的應用比較重要。

記者進來前十分鐘的小插曲，Jessica走了過來，似乎很緊張的樣子。其實我也感受得到，被邀請的人，當地主的人，都很緊張XD
不過一回生，二回熟啦，我相信未來Google會舉辦更多活動的。

接著也還是去逛了逛，跟著記者排了一堆東西，我好像也是狗仔隊一樣啊XD～
不過其實我心裡真的感受到，他們跟我們公司滿像的。當然資源比起來是截然不同，可是我們也很有那種氣氛。其實在Google工作，並不是見得都是在玩吧，可能網路上有些blog報導地令人誤解。其實躲在會議室，座位上拼的要死的人大有人在。此外大家也是因為有客人，才想說也放鬆一點的。

那我就隨手拍了一下Jessica小姐(旁邊是記者小姐)XD

你知道嗎？我還是愛死這冰箱了XD
冰箱及零食真是工程師拼到半夜不可或缺的東西啊！

據說這次，本來只想要300人參加，沒想到來了1300人，原本預計有啥Party的大概也沒了吧。
星期六的時候，也是大混亂啊...
其實上場前10分鐘我都還在處理網路的問題...orz
Google Earth用虛擬機器跑，實在很不聽話，不過展示還是勉勉強強過去了...

這位是幸運地圖的作者，我還是覺得應用與技術的關連不能說是絕對的，他還是有著相當有趣的應用。我相信他如果遇到更好的技術人員一定能夠將這個有趣的想法發揚光大，台灣很多人都很喜歡算命啊～

MAC遙控器的簡報方式原本是我在學校常用的方式，但是發現在這種大小的場地顯得相當地不好用。我只好乖乖地回到NB前按鍵盤，大多都是拍到我向下看的畫面...orz

總之，獻醜了！

其實我還是覺得技術人員的心情，並不是每個都顧著想要展現技術。這次很可惜的是，我們錯估了到底有多少技術人員會來這裡。因此前一位上場，我就想說糟糕，大多數看起來都不是來聽技術的...orz。然而我毫無經驗，讓大家聽了可能有點乏味，但我想下次會更好的。

在這裡還是要感謝林大哥及許老師在我瀕死邊緣都還幫我很多大忙...謝謝你們！

這位是ericsk，他的揪團網也是很有趣的作品，其實我很喜歡他的網頁設計方式。然而聽他提過系統的部分他很「固力」，還找國外的rails主機。說真的，我很想幫幫他！未來希望有機會能夠一起做這些有趣的東西！也希望大家多給他鼓勵吧！

說真的星期五記者會他狀況很好，可能因為星期六場地很難掌握情況，他很緊張的樣子＠＠

再來是聊聊我聽了四場演講，其中兩場是Apps Engine初階，進階；另兩場是雲端運算及Android進階。

說到為啥我喜歡用google的產品，並不是因為他們大，而是他們真的從完整並且簡單的層面考慮到使用者的需求。或許Yahoo他們可以很明確地像大企業一樣在租CPU，可是其實能夠用的平民老百姓又有多少呢？但Apps Engine講個簡單的例子，像我們學校的學弟妹們，大二大三就可以開始學習，並且撰寫。但你要他們去用EC2？不太可能。

確實在進階的時候Bratt講的挺快的，不過卻很清楚。就像有人說他們其實都盡量用台灣人聽得懂的英文，所以儘管展示尚未了時間而很快，卻讓我瞭解到幾點：

確實以BigTable的特性來說，不適合實做Relational的功能，畢竟資料是以Column-based Database的觀念為基礎，而非Row-based的。在這種情況下，要用MapReduce去scan，並且跑join，那可真是累啊。也因此DataStore的特性就變成純粹是以Distributed Object Storage的觀念來思考了，換句話說，就像DRb(Distribued Ruby)Object一樣，物件輕鬆讀取的時候很爽，同步的時候就頭大了。

既然寫很累，那我們就要更加利用一次寫入的特性來加速。以往我們會依賴SQLServer幫我們管理自動遞增的序列資料，我們會經常使用這個來當作某表格的ID。可是，DataStore可不是表格啊，因此言下之意就是說我們得自己管理serial。當然Bratt也提出說，只要有unique特性一概可當ID，不一定要遞增。那麼，將你要當ID的那個Class(舉例StudentIndex與Student)組合成EntityGroup就可以了，因為組合在一起的時候，他們會一起在後端被序列化並且寫入。但如果沒組合在一起，應該就是分兩次寫入了。

善用內建模組，但這也要他們趕快改好一些模組出來給我們用。並不是我直接把python函式庫放上去就可以的啊...

Pete跟我提到，他們一開始推廣DataStore的觀念也很頭痛，也因此才弄了GQL，不然大部分習慣SQL的工程師根本無法接受。但我心裡覺得GQL不是萬靈丹，還是掌握好物件的讀取寫入原則比較實在。

希望Batch Processing的功能快出現吧，ok17go得用到啊...

提到雲端運算，我個人認為有點媒體噱頭嫌疑。
此外並不是說葉博士講的不好，但我同事真的睡著了，還是覺得這次來的人多半是聽樂趣，聽應用，而非開發者。

為啥說有噱頭呢？因為實際上的內容，還是在介紹Google Infrastructure。那麼雲到底可以為使用者帶來什麼？難道真的只有在Web開發上嗎？從一個角度來看，我相信Google終究希望使用者盡量在Web上發揮的，這也是當初他們從Web反攻回視窗平台的理由吧。為了這個理由，把Internet當作天上的雲，而Google就在雲上，聽起來也確實滿有宣傳效果。

但我相信Internet的應用，儘管實在不能小看瀏覽器及普及應用帶來的威力，但也不完全是在Web上。我想能夠掌握基礎原理，並將其用在使用者所希望的功能上，才是重要的。舉例我到現在還是用Great News而並非Google Reader，那是因為視窗就是反應快嘛。而如果說看網頁...像Foxy那樣嵌IE在他們的程式裡，也是多此一舉了。那麼，對很多人從應用的角度來說，是不是在雲上(是否大量依賴Google或是Web技術)也不見得重要了。

而我們的校務平台也說明此事，就是對許多老師而言Google Docs根本不可能取代Microsoft Office。儘管XXXX的時代來臨，也還是有許多人在用他們覺得習慣的東西。但我必須承認，一開始遇到一個新名詞，新技術，許多工程師就會有非跟不可的衝動。我期許自己在未來更能審慎地辨識這些技術名詞的本質。

這場我很讚嘆啊，我並不是嵌入式系統領域的人，只能單純以計算機組織的的程式執行觀念來聽這場的演講。可以理解，為了節省記憶體，是用盡了各種手段。

我很好奇的是最後耗電量真的有減少嗎？吃空間，與CPU去Dereference哪個耗電呢？

我不知道其他家有沒有也做類似的事，但講實在究竟有哪一家敢大膽以Java當作主要開發的語言，而並非C。這不像以前的手機平台是J2ME，我想他們支援的Java語言完整性，與Android提供的函式庫，無法拿J2ME來比吧？然而他們給了會Java的人這個機會，也提升了Android發展的潛力。

那至於iPhone呢？資策會的記者大哥也有問我，覺得Android與iPhone未來哪個發展潛力大？我還是覺得以Android上的函式庫數量，是比較吃香的。至於他們所採用的是Java，讓開發產能也有競爭力。前一陣子儘管有聽過Sun想要找Dalvik VM的麻煩，不過現在看起來局勢已定，也很難去挑三撿四了。

因此未來ok17go確實是希望往Mobile的方向前進，旅遊整合行動是勢在必然的。

經過這次神奇的體驗，我想我大概是離不開Google了(大誤XD)
其實我發現我的開發任何地方都需要用到他，而且還用得不少。

那時候MMS簡訊上傳，本來是想靠另一家，但後來也還是用了GMail+IMAP。
還是那幾句老話，我是真的覺得他的API寫得很清楚啊，Tutorial也很多，但就是密技太多了XD。

現在我個人的情況就是，我得回到我的論文上，畢竟我還是做Grid Computing起來的，Web及Mobile是興趣，淵源一樣，用法不同啦。未來我會希望好好地去研究Google在他的Infrastructure上的技術貢獻，也會加緊研究Hadoop及HBase，我也希望中華能有機會加入第二次的Academy Program。我覺得Grid把事情講的太大太複雜，但如果能夠在應用面上與使用者透過這些技術連結在一起，那很多學校都能有機會投入並且創造屬於自己的計算平台。

外部連結

http://blog.ericsk.org/archives/999
http://www.lis186.com/?p=1820
http://blog.pixnet.net/nsysumis94/post/18722773
http://sullivan0201.blogspot.com/2008/06/google-developer-day-showcase.html

商業服務的PostgreSQL Database Cluster

2008-05-24T15:05:00.000-07:00

(本文圖片皆引用自PGCluster官方網站，http://pgcluster.projects.postgresql.org)

我在商業服務的Ruby on Rails HTTP Cluster觀念及測試中的第一張圖的前面那一段有提到說，DB的情況有點像是如此，不過實際上情況有點不同。因為有網友的疑問，如今我認為該是時候補完一下。

應用系統如果要能夠真正地服務大量的使用者，與常見裝個MySQL然後跑個PHP論壇程式，是完全的兩回事。因此一個良好的資料庫管理員，必須清楚地知道自己的應用程式與資料庫在單台機器上執行的時候，效能的瓶頸在哪裡。如果不清楚應用程式及資料庫各佔的資源比例，那在切割成叢集的時候，並不見得有顯著的效能提升，因為負載平衡以及複寫管理的程式都會吃CPU。認為1+1就極有可能等於2，這個是一般的管理員錯誤的認知。

舉例來說，許多大型的論壇，擁有上萬使用者，每天流量破10G；這樣的論壇，有些時候一開始因為資金及管理人力的限制，會考慮只買一台效能相當好的伺服器(例如HP ProLiant 380 G5)，並且將Apache+PHP(應用程式)與MySQL(DBMS)擺在同一台主機上。管理員會想說反正這台效能高，一方面省下買另一台伺服器的錢，一方面PHP程式不用透過網路與MySQL連線，理論上應該效能很好。卻沒有考慮到，一般的論壇Web應用程式是以CPU及RAM需要量大的應用，而DBMS是一種I/O裝置(RAM+Disk)需要量大的應用。這是由於，大多數的管理員會誤以為DBMS僅吃CPU與RAM。負載低的時候看起來沒什麼，一旦人數增多，表示應用程式的部分記憶體就會越吃越多。系統用來快取的記憶體不足，很快地瓶頸就會出現在記憶體及硬碟之間，造成資料庫效能低落。這個代價比使用兩台機器跨網路線這樣的部署方式要來的大太多。

叢集化

在DBMS相關議題中，有幾個主題會在叢集化的時候一起討論。

複寫管理(Replication Management)

複寫可以理解為「複製」的意思，不過複寫這個詞更強調的是資料的一致性。在DBMS中進行的複寫，是針對Insert，Update，Delete三個指令，將指令在所有的節點上執行，並且必須檢查這些動作後資料是否一致。目前所有開放原碼的PostgreSQL專案中，比較有名的是PGCluster，PGPool及Slony-I。

PGCutser是一種多服務點(Multi Master)的複寫系統，意指資料會在節點之間全部同步，儘管會有些許時間延遲，但不至於有影響。與Master-Slave不同，並不需要寫入特定某個節點才能複寫至其他節點。PGPool也有相似的作法，也同時允許對多個節點進行複寫，但實做方式可能不同。

(註：儘管PGCluster與PGPool在技術上相似，但有些文章並不認同它們兩個是使用類似的技術)

Slony是一種Msater-Slave的複寫系統，資料只能夠從指定的節點寫入，而複寫至次要節點的時間也會稍微延遲。

複寫儘管能夠在資料庫叢集上發揮作用，也能夠做為備份使用。總之資料庫同步了，就看你要拿去做什麼用途。此外同步的複寫，與延遲的複寫，所影響的也只是被複寫的資料庫是否是要做線上使用。如果是延遲複寫，就要注意最好是當作備份，而非拿來做線上使用。

Statement Level 與 Row Level Replication

Statement Level與Row Level意義上就是，前者是複製SQL指令，後者是複製執行完SQL的一筆記錄。上述所有三套複寫管理的程式，都是採用Statement based。而像MySQL, Oracle等都有提供Row based replication。這兩種複寫的差異在於，一旦你的statement是Procedural Language，有可能在不同的節點上會造成不同的結果(non-deterministic)，那複寫便失敗了。而Row based的好處正是反過來，既然已經知道結果，便不會有任何差異的可能性。

查詢緩衝(Query Pooling)

對於許多應用程式而言，很有可能連續地進行同樣的查詢。例如你將應用程式的功能選項名稱列舉在表格裡，那為了讀取所有選項，都會進行同樣的查詢。這樣的查詢與結果，是不需要再傳回實體資料庫真正進行查詢的，因此就由緩衝區直接將結果傳回。以資料傳輸的角度來說，在Client使用的函式庫裡實做緩衝，就不用再進行網路傳輸，比在Server上實做有意義多。

不過PGPool就是這樣的一套軟體，他也採用了查詢緩衝機制，使得同樣的查詢不會重複地傳給後端的實體資料庫。

負載平衡(Load Balance)

如同字面意思，當有大量連線進入的時候，負載平衡程式要能夠得知所有連線中的資料庫，並且將查詢分散給這些資料庫查詢。當有任何資料庫中斷，負載平衡程式也不能夠傳給已斷線的實體資料庫，以免造成應用程式錯誤。PGCluster與PGPool都有負載平衡能力。

另一種獨特的負載平衡，是將一個資料表格切割，散佈在所有的實體資料庫內。這種不僅做到了負載平衡，更有可能實現平行查詢。PGPool擁有切割表格並且平行查詢的能力。

共享儲存系統(Shared Storage System)與磁碟鎖定管理員(Disk Lock Manager)

如果你的資料庫儲存系統效能相當地好，或許你可以考慮使用共享儲存系統來讓一份資料庫的資料檔，能被多個資料庫系統實體同時讀取。在這種情況之下，當然你就不需要複寫系統來讓資料庫同步了。不過這也延伸一個問題，畢竟多個城市實體要進行寫入的時候，那就可能造成衝突，也因此使用何種磁碟鎖定管理員就有很大的差別。Oracle附了自行開發的鎖定管理員，而其他的開放原碼資料庫就得尋找其他開放原碼的解決方案。

儘管有些檔案系統具有共享的特性(如NFS)，但卻並非相當適合當作資料庫存取的機制使用。另一個著名的檔案系統Global File System(GFS)已經被證實能與PostgreSQL一起運行，GFS本身也帶有DLM。

有網友詢問說資料庫能否建置在這樣的共享儲存系統上？在這裡要說明，即便你有高出力的儲存硬體，但你還是得想清楚，共享檔案系統就是靠網路進行I/O，資料庫是一種依賴I/O的應用程式。如果你只有100Mbps的區域網路，還是打消念頭吧！

SQLServer的部署

這裡要提到部署的作法，是適用在全部的DBMS上。使用不同的部署方法，會影響到建置及維護複雜度，效能，可擴充性。

單服務點(Single Master)

單服務點所要顧慮到的只是上述所說的，「除非真的窒礙難行，不然別輕易地把應用程式與DBMS擺在同一台主機上」。一般來說你的應用程式應該是能完全與單服務點的資料庫一起運作，對於你的應用程式而言，他與一個單機的資料庫沒有啥兩樣。所以，不管你用PGPool或是PGCluster，應該會預設設定為單服務點。如圖：

這樣建置的優點還是較為簡單，但這個作法的極限就在於一旦你發現你的負載平衡程式已經消耗過多的CPU，或是對應用程式的頻寬已經大到明顯拖慢速度，就是該換架構的時候了。

多服務點(Multi Master)

多服務點就相對地複雜，如果你會採用多服務點，一定是因為你的應用程式服務點也相當地多。例如說你的應用程式伺服器有上百個，但怎麼可能上百個都向同一個(單服務點的)負載平衡程式進行連線？不管你用多快的CPU，給多大的記憶體，都一樣會爆掉。

這個時候你也不可能考慮單一的儲存系統，所以你只剩下一個選擇就是進行複寫，並且實做多服務點架構。

參考

http://wiki.postgresql.org/wiki/Replication,_Clustering,_and_Connection_Pooling

http://www.openminds.co.uk/post_gre_sql_mirroring_and_recovery.aspx

http://www.postgresql.org/docs/8.3/interactive/high-availability.html

http://www.openminds.co.uk/post_gre_sql_mirroring_and_recovery.aspx

SRB 3.4.x with CentOS 5

2008-04-22T04:34:00.000-07:00

每次換了個平台都會忘記幾個小步驟，而導致很麻煩的後果
這次我做點詳細的紀錄

需要套件：

SRB 3.4.x

PostgreSQL 7.4/8.2

unixODBC 2.2.11

psqlodbc 07.03.0200/~~08.03.0100~~
修正08.版的psqlodbc並沒有三個需要的.h檔，請不要下載這版本

安裝PostgreSQL：

http://www.postgresql.org/ftp/binary/


rpm --rebuild  postgresql-{version}-PGDG.f8.src.rpm

建置完將libs,client,server,contrib安裝
啟動資料庫，建立好新使用者srb，建立好unigrid mcat資料庫，並將擁有者指向srb
編輯pg_hba.conf
使得localhost使用密碼存取

安裝unixODBC：

yum install unixODBC-devel

根據相依性也會裝unixODBC

安裝psqlodbc：

http://www.postgresql.org/ftp/odbc/versions/src/

根據PostgreSQL版本下載


./configure --with-unixodbc
make  all install

ln /usr/local/lib/psqlodbc.so /usr/local/libpsqlodbc.so

要改成lib開頭的檔案ldconfig -v才會抓得到

編輯/etc/ld.so.conf
加入一行

/usr/local/lib

接著ldconfig -v |grep psql
看有沒有

將iodbc.h isqlext.h isql.h複製到/usr/include裡
這是編譯SRB時所需要的

設定ODBC：

unixODBC根據兩個檔案作為主要設定檔
如果不清楚設定檔的存放位置
odbcinst -j 就會顯示

編輯odbc.ini

[Unigrid]
Description = Unigrid
Driver = /usr/local/lib/psqlodbc.so
Database = unigrid
Servername = localhost
UserName = srb
Password = {password}
Port = 5432

存檔後，切換到srb帳號，執行isql -v unigrid就可以測試連接
不正常的話會有一些錯誤訊息，正常的話會出現connected!
並且可以測試select

isql 指令後面跟著的就是odbc source name，在這裡也就是設定檔第一行[ ]裡的"Unigrid"
ODBC是一種資料中介層，資料來源可以根據不同的驅動程式，來讓不同平台的應用程式可以連接
例如可以讓資料來源指定驅動為excel，如此就可以存取excel檔了

不正常的情況：

[IM002][unixODBC][Driver Manager]Data source name not found, and no default driver specified
輸入給isql的資料來源名稱錯誤，很有可能是設定檔裡的[ ]開頭的項目沒有這一項，或是那一項設定的Driver參數沒有指定

[28000][unixODBC]FATAL: ....
這一種類型的大概都是從資料庫回來的，那就要看postgresql傳回啥訊息了，可能會是帳號，密碼錯誤，無法連線，或是pg_hba.conf設定問題

編譯SRB：

MCAT


./configure --enable-psgmcat --enable-psghome=/usr/local/pgsql --enable-javagui --enable-jdkhome=$JAVA_HOME
make

without MCAT


./configure  --enable-javagui --enable-jdkhome=$JAVA_HOME
make

虛擬化技術的現況

2008-04-11T04:56:00.000-07:00

虛擬機器(Virtual Machine, VM)，用比較白話的方式講，就是「模擬器」。
利用現行的硬體，撰寫系統，模擬另一套系統的整體結構，包括硬體，甚至韌體，就是虛擬機器。

虛擬機器大致上可以分兩種，一種是模擬整個硬體系統，執行環境，我們稱做「虛擬系統」，如最有名的VMWare系列，便是一種用來虛擬IBM x86 PC架構電腦的虛擬機器。另一種稱做「虛擬行程」是利用軟體中介層的方式，模擬出一套執行環境，例如Java的執行環境Java Runtime，就是使用Java Virtual Machine (JVM)作為其執行環境。

本篇文章主要介紹虛擬化技術，及兩個最常見的虛擬化平台，VMWare及Xen。

Virtualization - 虛擬化

舉個例子，很多人可能會有這樣的經驗，Office出了2008新版了，想要裝來玩玩看，可是又發現一旦裝下去，自己的Windows可能會一片混亂；或者，就是刪掉舊版再裝，又相當地浪費時間。當忽然想要用舊版的時候，總不能夠經常刪刪裝裝吧？

另一個情景比較容易發生在軟體工程師身上，軟體工程師經常都需要一個與自己開發用的作業系統不同的乾淨環境來進行軟體測試。可是想要機器的時候，總是要不到。工作還是得做啊，怎麼辦？

為了解決類似的問題，早在很久以前就有人研究虛擬機器的可能性。不過相對以前的電腦硬體效能，想要使用程式模擬執行環境，是相當地不可能的。直到最近CPU的發展，已經邁向多核心的方向，不管是效能，或是應用性，已無法與以往的電腦硬體相比。

所以剛剛的情境，實際上就在你的電腦裡利用VMWare Workstation裝一台虛擬機器便可行了，而安裝上去的作業系統，我們便稱做「Guest OS」。Guest OS基本上可以是與你的作業系統完全不一樣的另一種作業系統。例如說你的實體機器是Linux，而你卻可以在上面灌一個虛擬的Windows。

Full Virtualization - 全虛擬化

在早期還沒有虛擬化技術的時候，本來有一種叫做「硬體虛擬化」技術，當時是藉由安裝額外的擴充卡(上面有鍵盤與滑鼠的介面)，來分享系統資源。當然這種不符合成本的作法很快就被淘汰。

而在歷史上，IBM也在1966年開發過自己的虛擬化技術，而當時的作法，就成為了現在商業化虛擬技術的先驅。VMWare大約在這五年搶下了全虛擬化的市場，其中對於個人用戶最方便的莫過於VMWare Workstation。而VMWare也在2004年被EMC這間全球最大的企業化儲存系統公司併購，搭配了VMWare Server系列產品，全面攻下高階伺服器管理的市場。

全虛擬化的技術，最主要就是完全依賴完全建構的虛擬硬體層，這個虛擬硬體層為了Windows及Linux系統提供了較佳的相容性。換句話說，上面的「Guest OS」所看見的硬體，比較少會是直接延伸自原來實體的電腦硬體，如下圖所示。除了CPU及記憶體，主機板，VMWare幾乎都虛擬化了，有虛擬的BIOS，也有虛擬的顯示卡，而且都必須安裝專屬的驅動程式。這樣的優點是，不管在怎樣的硬體環境中，Guest OS都能夠維持比較統一的相容性。但缺點是，因為有了這龐大複雜的虛擬硬體層，相對的實體機器就得維持比較大的負擔。

(本圖轉載自VMWare官網 )

Para Virtualization - 半虛擬化

半虛擬化是利用Linux/Unix系統核心原本有的 Monitoring Mode，將電腦硬體的使用變得可以讓多個記憶體位置的程式在不同的時間呼叫。這種作法儘管不像全虛擬化一樣，反而是變成你的電腦硬體是什麼，Guest OS就會看到同樣的硬體，也就是說真的好像把你的硬體拿去共享了。當然優點就是，不需要消耗額外的系統資源來模擬硬體層，因此就算是多個Guest OS同時執行，你也不見得會感受到效能下降。但缺點就是，Guest OS的作業系統，必須使用和實體機器的一樣。如同下圖：

(本圖轉載自http://it20.info/blogs/main/archive/2007/06/17/25.aspx )

最好的例子就是Xen。Xen是一個開放原始碼的虛擬系統軟體，相對於VMWare各個版本都需要花不少錢買(儘管有免費下載)，Xen已經被許多開放原始碼的作業系統如Fedora，CentOS，Ubuntu等內建於其中。儘管沒有像VMWare一樣有精美的操作介面，但Xen還是提供了Virtualization Manager，一個簡單的視窗程式來讓使用者快速建立虛擬機器。

但對於半虛擬化的最大限制：無法使用不同作業系統，還是有不少人覺得說比起VMWare來說實在是無法當作一個很好的虛擬平台使用。因此Intel開發出了支援虛擬化的新技術，Pentium 4包括後其的P4 6xx系列, PD系列，及現在最熱門的雙核心及四核心，全部都有支援。此外AMD也在同時開發出一樣的技術，包括後其的Athlon 64, Turion 64, Opteron, Phenom都有支援。這樣的技術，使得Xen可以執行不同的Guest OS，而對於全虛擬化的平台也能夠再加速。

參考資料

網路上都有很好的文章，關於介紹，或者是教學

http://it20.info/blogs/main/archive/2007/06/17/25.aspx

VMWare

http://tw.myblog.yahoo.com/handle1963/article?mid=13350&prev=13477&next=13205

Xen

http://linux.vbird.org/linux_enterprise/xen.php

結論 - 虛擬化的應用

儘管虛擬化技術為個人能夠帶來一些工作上的便利，但其實從企業的角度，虛擬化是不可或缺的。

台灣自從好幾年前，政府積極投入半導體產業以來，已經搖身一變成為名符其實的電腦王國。世界上有四分之三的主機板，都是在台灣生產。而台灣不僅是生產主機板，記憶體的主力，近年來筆記型電腦，網路產品，直到伺服器，也多在台灣生產製造。而這樣大量製造的情況下，伺服器的功能越來越好，價格越來越便宜，一般的中小企業，學校單位，都已經不需要花大錢購買五萬十萬的伺服器，也能夠用一般的PC做一些基本的服務。

但伺服器與PC之間也存在一種迷思，我不買伺服器的話，能夠獲得穩定性嗎？確實伺服器的許多硬體設計都是雙份，兩個CPU，兩個電源供應器...等，來增加穩定性，卻也造成運算效能的浪費。根據統計，拿全世界的伺服器計算能量，與實際產生出的資料量比較，推算這些伺服器的使用量都不到10%。也就是說大部分的時間，你的伺服器的CPU都是閒置的。比起這樣閒置的浪費，安裝虛擬機器，不僅能夠提升CPU的使用量，而在設備的管理上，也不需要如以前負擔龐大數量的購買成本及維修成本。

舉個例，以往公司內的MIS最頭痛也就是最主要的工作，就是有人報修電腦。個人使用的電腦沒辦法，因為會影響工作，還是得修。可是在一些軟體公司，許多員工可能都需要數台額外的機器來做不同的應用或開發，這個時候MIS通常都要準備許多舊電腦供其使用，如果這些電腦也報修，在管理上真的是一大負擔。有了虛擬機器，MIS只要使用管理介面新增一個虛擬機器，並且將磁碟映象檔複製一下，IP抓好，一個新的作業系統就可以使用了。而增加的動作，加上映象檔拷貝的時間，可能花不到10分鐘。尤其在Linux系統上，透過Xen使用虛擬機器的使用者，幾乎不會感受到他們是在使用虛擬機器。

這樣便利的科技，目前也運用在蘋果的Mac上，如Parallel Desktop或是VMWare Fusion，這些都是可以讓你在Mac上使用Windows的方便軟體。

由於多核心CPU的發展，虛擬化技術的應用也跟著成熟，未來我相信還會有許多更有趣的應用。

MapReduce是開技術倒車？

2008-01-21T03:38:00.000-08:00

http://glinden.blogspot.com/2008/01/mapreduce-step-backwards.html

http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html

MapReduce是開技術倒車？實際上這像是當初SQL推出的時候，很多人也認為以語言來描述資料的處理是多餘的事情一樣。而ORM盛行的時候，也有人質疑SQL已經很直觀了，為啥又要轉成物件。

"Ronn Brashear said:
...
A good engineer understands the specific problem space, examines the potential solutions, and picks the right tool for the job. "

所以說，Vertica DB發表這一篇也只是商業競爭而已，其實他們並不如Google能夠理解Column-based DBMS的好處，並經其原理應用在BigTable上，其中一個回應也說的對，根據paper裡所說的結構，BigTable是有index(還有vertica做不到的timestamp based query)。這些教授對RDBMS很熟，可是卻完全不瞭解parallel data processing是怎樣回事，因此誤用，並拿來對照。

當然我在上次的書報討論中，也將這幾個paradigm拿來比，是不太對的。不過當然就是想說先讓同學們瞭解一下觀念。

不管怎樣，在此重新釐清一次觀念。

Google File System(GFS)是一種Global File System，目的是以出力(throughput)為主，並不具備任何的檔案分割能力。他與Redhat推出的GFS功能上相似，但實測的檔案大小及效能差異極為懸殊。GFS本身不具備任何的DLM(Distributed Lock Manager)機制，而是以另一套服務稱為Chubby來提供，這也是跟Redhat GFS不同。簡單地說，把他想像能夠高速傳輸上10TB大小檔案的NFS即可。

MapRedurce是一個parallel data processing framework，根據程式設計師撰寫的Mapper/Reducer Function，搭配合併於framework內的checkpoint技術，而進行平行化的資料分析及處理。首先利用GFS的特性，使得大容量(如上述的10TB)並且為單一檔案的資料，能夠分散在適當的節點群組裡。接著Framework的主程序就會自動地散佈開發好的程式，進行呼叫Map,Reduce兩個函式，最後將結果寫回GFS去。也就是說，就某種角度，他比較像Condor，而跟資料庫一點都扯不上關係。至於說他是不是能夠用在Computation上，paper的說法是「有機會」，但我認為除非你將問題切割成資料處理，不然是很難有機會的。

BigTable是一個利用上述Framework所撰寫成的巨大資料集儲存系統，這裡指的是「資料集」，而表示這些資料彼此之間可能不具有任何的「關連」。因此將關連式資料庫能夠有的功能如transcation，拿來比較是不合適的。換句話說，你應該不會經常拿許多份Excel，將其內容合併(join)後才取出資料(select)進行你的工作(真的已經這樣就會去用DB而不是excel了)，而你也不會將資料庫系統裡就建一個表格，然後把所有欄位都放在同一個資料表裡(坦白說我還是有看過人這樣做@@|||)。BigTable如其名，就是一個巨大的表格，就像Excel一樣，而並不是DBMS。儘管在paper裡也提過他擁有一些與DBMS相同的功能，不過這也不代表他是被定義為DBMS。更何況，在這樣大的系統內，要堅持使用特定的觀念去解決事情是一件很不合理的事。

看完了，大部分人可能也還是無法從定義去對應到腦袋裡可以想像的模樣，而不免心裡會有疑問，這些東西搭在一起又能幹嘛？就未來來說，我們有機會擁有下一代平行資料庫的雛形，也有可能就真的只是一輩子被用在Google的應用服務中了。但就現階段而言，請不要忘記這世界上已經有多少人無時無刻地在使用Google的軟體了。

九型人格分析

2008-01-21T02:16:00.000-08:00

第三型	成就者、事業型、成就型、實踐型 15%
第七型	快樂主義型、豐富型、活躍型、創造可能者、享樂型 15%
第二型	助人者、全愛型、助人型、成就他人者、博愛型 12%
第八型	領袖型、能力型、挑戰者、保護者、權威型 12%
第九型	和平型、和平者、和諧型、維持和諧者 12%
第一型	完美主義者、完美型、改革者、改進型、秩序大使 11%
第四型	藝術型、浪漫者、自我型、憑感覺者 10%
第六型	忠誠型、忠誠型、尋找安全者、謹慎型 6%
第五型	智慧型、觀察者、思想型、理性分析者、思考型 6%

我的九型人格分析？

程式設計的「德、智、體、群、美」

2008-01-14T10:16:00.000-08:00

近來實做過幾個看起來很難成功的專案後，我深深感到
在台灣賣「程式技術」是一點用也沒有的

台灣有多少人會寫程式，現在大學各個系都開始冠上「資訊」
程式語言的門檻越來越低，從php到ruby的發展及差異清晰可見
程式設計師們個個只要稍加訓練，一定都具備相當的能力能夠「寫」出成果來
然而，這些成果是什麼？些成果「該」是什麼？一個能賣的產品嗎？
這些問題總是也沒人去探討。
以往台灣的軟體產業，公司需要的多半還是Coding Machine，也就是「工程師」
資深的工程師或需求人員「想出」設計，搭配美工或是資料庫設計，然後由年輕的工程師們變出來
卻沒有多少人注意到這個產業慢慢需要的不是機器，而是完善的設計流程，及腦袋清楚，身體健康的開發人員
我相信，程式設計有所謂「五育」
台灣的軟體人員，似乎總是有點五育不全

德育，直接指出最重要一個問題：「你寫程式是為了什麼？」
當然不管為了什麼，如果無法賺錢養活自己，那還用說？
但許多工程師心裡完全沒有感受衣食父母—使用者跟他們有啥關係
更不要說能夠「喜歡」他們的使用者，並深入瞭解他們的感受
試想，如果自己寫的東西沒人要用，那到底寫來幹嘛的呢？
而有沒有人要用，會是因為自己能夠實做多難的技術，或是多大規模的程式嗎？

智育，代表著你清楚不清楚程式的本質？以及「資訊」的本質？
我個人認為最直接的關鍵在於，有沒有好好讀過計算機概論
當然程式語言，物件導向，軟體工程，系統分析，資料結構，作業系統等，我相信都對程式設計的智育有很大的影響
不清楚的話，便無法能有機會從程式或模組的撰寫，進步到更整體性的系統設計，或是能夠有效解決使用者問題的需求設計

體育，說起來這個算是硬凹的
不過可以想像，就是看你Coding速度快不快，Library熟不熟悉囉
如同跑步等競技訓練一樣，一天不寫，可能過沒多久就生疏了

群育，說起來現在宅宅工程師可真不少
第一點就是在你工作閒暇的時候，還想辦法學習跟資訊一點關係都沒有的另一項技能
第二點當然就是，多跟異性友人，同事出去玩吧，別到時候娶/嫁不到老婆/老公了
最後，增進自己的修養也挺重要的，「理直，氣和」

美育，說起來也是程式設計師的障礙
說到UI，大部分都是「可看就好」，程式碼的角度，也是「可跑就好」
但實際上，既然是寫程式，也需要一點Art of Programming
UI不僅要能看，操作要順暢，要盡量合乎使用情境，不要總是丟給畫面設計人員
程式碼不僅要能跑，還要能夠快速重構，視需求而進行適度的機制分離或是模組化
適時地套用特定的樣式，或是妥善利用各種演算法來「解決問題」，不是只是單純地去套用
偶而自己做做投影片，以免人家問你怎樣寫的時候答非所問

其實講到最後，小弟我也深感自己也一樣是五育不全
尤其是群育的部分，實在是宅翻了啊...

[2007/08/19 - 2008/01/14] Hemidemi書籤摘要

2008-01-14T08:53:00.000-08:00

:: GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS :: Jester 1.3: Jsonic REST
09/27 18:30, 2007
Jester是一個ActiveResource的Javascript實做，比較主要的還是利用JSON及REST觀念進行CRUD。但這個東西是某能夠獨立運用？我相信未來與其他javascript函式庫整合是勢在必行。
(標籤: javascript)
Juggernaut
10/04 23:44, 2007
Juggernaut是一個Rails的Push Server Plugin，使得Server Side Push成為可能。Request依然還是使用Ajax，但透過Client嵌入的Flash進行回傳javascript的eval。儘管是透過不同的通道傳送資料，但因為push server不需要執行完整的Rails而速度大增，記憶體用量也減少，因此反應變快。
(標籤: rails ruby browser flash javascript)
Lightstreamer :: Live Web Content Delivery
10/04 23:45, 2007
這是一個商用Push Server的展示
(標籤: rails)
How Friends Arrange When and Where - Renkoo
10/04 23:53, 2007
Renkoo是一個整合郵件，IM，時間地點規劃的服務，可以整合朋友的帳號及通訊清單。
(標籤: im email)
vgod’s blog » Comet (Server Push) on Turbogears
10/04 23:54, 2007
vgod寫了一篇有關comet的文章
(標籤: flash)
Rails Code Review PDF | PeepCode Screencasts for Ruby on Rails Developers
10/30 09:26, 2007
介紹許多撰寫Rails及使用ActiveRecord時該注意的事項，相當地實用！
(標籤: ruby rails)
My PostgreSQL performance tests
11/21 18:48, 2007
雖然是比較久以前的測試，不過還是有些參考價值，似乎file system是大問題。
(標籤: postgresql)
Benchmarking BSD and Linux
11/21 20:33, 2007
這也是一篇很好的效能測試，不過時間上比較早一點。此外也沒有針對磁碟IO上的測試。
(標籤: linux freebsd)
Google Internals
12/12 16:43, 2007
雖然是老東西了，不過還是看看吧～
(標籤: google database)
try ruby! (in your browser)
12/24 16:49, 2007
稍微註記一下
(標籤: ruby programming)
JNEXT - JavaScript Native Extensions
12/24 19:47, 2007
jnext是一個擴充javascript的函式庫，讓javascript具有呼叫系統函式的能力，例如開啟socket或是讀取本機檔案。
(標籤: javascript)
High-Performance JavaScript » SlideShare
12/24 20:48, 2007
如何撰寫高速的Javascript？第一個就是要先瞭解它究竟是啥～
(標籤: javascript)
Google推出OpenSocial，重點是在「人人皆可當寄主」 (Mr. 6)
01/04 17:15, 2008
這確實是滿重要的東西，不過看目前絕大多數還是在於共享的應用，也就是說如果要搭上第一順風車的話，許多站都已經具備條件了。但是第二順風車，「Relationship」我認為是中後期的主力應用，畢竟要還原至social的本質。
(標籤: social)
Heroku
01/14 16:43, 2008
這是一個快速線上建立並且熟悉rails環境的服務
(標籤: rails ruby)

我的更多書籤 @ HEMiDEMi - 黑米共享書籤

You are a dog ! (Ultrasonic ringtone)

2007-12-09T15:20:00.000-08:00

You are a dog

Or maybe you are a mosquito, you certainly can't be human.

The highest pitched ultrasonic mosquito ringtone that I can hear is 21.1kHz

Find out which ringtones you can hear!

啊？這是真的嗎？
是我家的喇叭太爛還是太好？
不過真的最後一個是聽不見了...

SRB與Data Grid

2007-11-01T02:37:00.000-07:00

啥是Data Grid，啥又是SRB？這個問題其實也在我的心中困擾很久，由於我自己差不多到了這個階段，該是時候弄清楚並且真正提出解決問題的方案了。有一個前提必須提醒大家瞭解一個想法，Grid這件東西，我個人認為比起研究或是虛幻的夢想或者要解決100％的問題，實際地解決60～80％的人認為的問題，就能夠有貢獻了。而過去的經驗裡，很多事情都讓我體認到，眾多的計畫裡，提出眾多的想法，僅只能夠被歸類在「研究」，就像我聽許多老師說，「這就是做研究嘛」一樣。實際上一個東西是不是能夠被拿來做量產，終究還是該關心的問題。這並不是否定各位前輩們的辛苦研究精神，在不可能裡尋找可能是很累人的。只是對我個人而言，我希望經研究作為是一個過程，而不是做了三四年都還在研究階段。很可惜的是，在我這幾年參與的計畫裡，「研究」還是佔了最主要的目的，而並不是「使用」。這是讓我深感SRB就是一個這樣研究型的middleware，許多的設計是在告訴大家「可能」，但並不是為了要拿來使用而設計。卻實在看過一些文獻後，對於SRB在Machanism Abstraction上的貢獻我覺得相當佩服，對於眾多的儲存媒體，要能夠囊括不是一件簡單的事。但仔細思考，究竟Data Grid希望為大家解決啥問題，會發現路更是長遠。光是metadata abstraction或是machanism abstarction，也不見得能夠解決幾個重要的問題。以下我透過一些問題來帶入Data Grid的需要：

問題

為啥大家需要分散式的儲存？

我個人覺得這是因為硬碟真的太多，看看這個新聞吧

http://www.weblink.com.tw/main/action/getNews.do?did=200611000105&action=getNews

PMR大家都知道，更何況這還是2006年的新聞。一旦東西多了，整合地使用便是一種趨勢。同樣的問題也發生在網路傳輸上，大家的網路變快了，所以不再是依賴高效能伺服器，而能夠整合大家的頻寬也是最好。這個部分，主要是透過P2P技術來達成。我想應用大家閒置的CPU，無用的硬碟空間，閒置的網路，不管在何時一直都是重要的焦點。

為啥大家需要「應用領域中介資料」(Application Metadata)？

現在各種領域都有專門的人才，這個造成兩件決定性的事，一個是這些人通常都不可能用通用的領域知識互相溝通，二是既然不能溝通，更別說有什麼可能共通的「協定」。因此，以往很多人志再開發一些能夠通用的協定，多半是不符合領域需求。當然另一點我所知，背後的許多商業競爭也是問題。沒有協定，無法共通，對使用者並不見得是最好的。但反過來說，如果能夠輕易地定義自己的領域資料，或是領域語言(DSL, Domain Specific Language)，加上這個DSL如果很簡單地可以轉換為XML，不管是誰都能夠有些創意能夠開拓自己的方向，並且也能夠想要交換資料的時候就交換。但Data Grid必須做一件事情，將這些不同領域的數位中介資料都要能夠讀出，並建立索引。

為啥會產生大量資料？

由於探測的技術越來越進步，加上電腦硬體的等級在這10幾年間成長幅度太大。與其用一兩台電腦算上百萬年，不如螞蟻雄兵地用大家的電腦。Computing Grid就是要進行這樣的運算，而Data Grid就是要存著這些運算時進出的資料。

為了這些理由，我相信很需要所謂Data Grid技術的存在。

現在的SRB

接著我就SRB的操作經驗讓大家瞭解一些情況。以下會透過我放在google docs的投影片來說明。

Neutrality指的是「中立」，意思是說不能夠決定性地使用任何一種特定的方式或技術來完成特定的功能。而在程式實做上，通常會給予許多的Interface(介面)來完成這個目標。但在設計上，一個系統是否能夠真正達到這樣的彈性，不僅要考慮這些Programming Interface，包括通訊協定，甚至使用者介面的設計，都得考慮進去，有些狀況得為了效率捨棄彈性，而有些時候反之亦然。我相信這是prototype與production軟體之間使用性的差異。

Mechanism

建置與部署

先討論的是SRB提出的Federation觀念(投影片14~20頁)，圖片展示各個獨立的SRB Server，如何互動，然後再將檔案傳輸給使用者。而能讓SRB運作的最基本元素，在投影片21頁，包括Client，SRB Server(Storage Node)，MCAT Server(SRB Server+MCAT DB)。意思是說，如果管理者要安裝一套SRB系統，至少必須有一個MCAT資料庫與及一個連到此資料庫的SRB Server。此外可以的話，最好要有另一個SRB Server並掛上一個儲存裝置。因為MCAT本身也具有任何SRB Server的功能，以及單一簽入(Single Sign On)，當你連到任何一台SRB Server的時候，也就表示登入到整個SRB系統。由於SRB的單一簽入的功能，是採用委派(Delegation)的方法，在通過認證後，無論任何使用者進行什麼動作，皆會委派給Proxy User(或稱做Ticket User)。目前這個Proxy User，可以是任何一個你所建立的SysAdmin帳號。

這個部分也影響到其安裝與設定，當你建置一個SRB系統，大概會是以下動作：

在MCAT Server機器上，安裝資料庫系統。可以是DB2,Oracle,PostgreSQL,MySQL

將SRB的MCAT功能啟用並編譯(如果你要啟用GSI也是必須這個時候就決定)。

將SQL指令匯入至資料庫系統。

使用ingest系列指令新建立Zone及SysAdmin(在那之前，你必須要用「內建帳號」加上「環境變數」方法登入)

確認啟動SRB的帳號(假設是srb)可以透過ODBC連到資料庫系統，並且編輯MdasConfig，輸入資料庫連線參數。

在srb這個帳號的家目錄(~srb)下新增.srb目錄，並且編輯.MdavEnv及.MdasAuth檔案，將剛剛建立的SysAdmin帳號(就是Proxy User)連線參數填入。

啟動並確認data/log/下的記錄檔內容是否正確，有錯誤的話就排除

而其他的SRB Server，在編譯的時候不用啟用MCAT，也不用做第4，5步。但在第6步後，要編輯mcatHost設定檔，將內容填入MCAT Server的hostname。請注意，在你建置的同時，DNS或IP等網路設定都要先確認好，一旦Domain Name對應錯誤，導致連線失敗，可能會很難發現錯誤並除錯。

詳情請參考

http://kiwi.csie.chu.edu.tw/blog/archives/122

如果只是單純學術研究用，部署(Deployment) 不是一個最優先的考量。可是對於實際運作情況，對管理員而言多餘冗長的安裝或管理動作，是會影響部署進度的。我認為Globus在這一點自從3版之後就有很大的改進，可是SRB在這一點卻相當地糟糕。儘管SRB有附上一個輔助Oracle的自動安裝script，但實際上對於各種情況不見得真正管用。

此外，對於一個必須要安裝Database才能運作的MCAT Server，如果要大量部署成特定的架構(M/S或Hierachical)就相當的困難，這個問題也違反了以下要討論的Metadata機制中立特性。

管理

參考投影片第22頁，當你登入到一個SRB系統的時候，我們會稱做你登入到一個SRB Zone。Zone為SRB最上層的管理單位，形同於一個組織或是一個計畫。而他的下一層是Domain，可以看做一個部門或是一個子單位。最後則是基本的使用者與群組。就現階段而言，這些管理單位的階層結構與Metadata的階層結構是毫無關連的。換句話說，如果一個Zone有過多的Metadata，往往需要視情況將這些Metadata分散給下層管理單位(就如同DNS一樣而構成階層式的資料結構)，但SRB無法簡單地做到這一點。

要管理所有的Zone,Domain,Group,Account，必須透過指令及java GUI管理工具來進行，這個部分SRB提供了還算不錯的使用度。不過這個部分要注意到，管理並非是單純的CRUD，一旦GUI只是按照指令來設計，便失去GUI的意義。指令介面比較適合做精細的單位動作，例如移動一些檔案，修改某個檔案的Metadata。但使用GUI的目的，有些時候是得大量而快速地處理這些東西，否則就不需要GUI了。

儲存

SRB對於儲存機制中立的作法相當地令人稱讚。傳統性的儲存設備包括Windows/Linux File System，Tape，Hierarchical Storage等都可以相容，而非傳統的儲存媒體如Database，FTP/HTTP File System等，也都盡力地支援了。但這些支援的背後，並未注意到幾個問題。

傳統和非傳統儲存媒體間，還是存在著是否可能斷線這樣決定性的不同。在LAN上面或許可以，可是一旦網路不是絕對穩定，或是在WAN上面，那肯定會因為斷線造成檔案的操作緩慢或失敗。

非傳統儲存由於不見得都是為了進行IO動作而設計，因此一旦速度上有差異，就需要有效的快取設計。SRB本身沒有任何的快取設計，因此對於任何媒體的緩慢皆會造成整體的影響。

SRB Server本身持有許多重要的角色，各儲存媒體間的資料移動，必須靠著SRB的Metadata與傳輸速度來達到整體的效能。Metadata的問題在下段討論，但傳輸方面，SRB只做到了點對點的Multi-Section Transfer(在SRB裡為Server/Client Initiated Parallel Transfer)。實際上在分散式的環境，多對一的Parallel Taansfer是必須的，而實際上這也才是一般所認為的平行傳輸。

一個儲存的主機被定義為Location，而儲存媒體被定義為Resource，任何的Physical Resource必須建立在一個Location上。一個SRB系統裡至少要一個Physical Resource，才能明確地傳輸檔案。管理員也可以建立Logical Resource，這個表示多個Physical Resource的集合，當檔案實際進行儲存時，SRB會自動從其中選擇一個，而不需要使用者顧慮要存到哪。實際上挑選的Policy不明，而官方對於這個作法提出的解釋，是希望能夠將resource群組化。要進行儲存的管理，SRB提供了Java,Windows,Web三種管理工具。

Replica管理

Replica(覆寫)管理在DataGrid上一直是一個重要的議題，Replica的意思形同於Copy，因此也產生了管理及同步問題。SRB確實有提供Replicate的功能，也可以透過一個指令在不同的replica之間同步。不過並未提供管理的功能，也因此一般情況下管理者必須自行執行Sreplicate來操作。如果要達到自動化，管理者必須自行撰寫replica meneger，或是設計一些預設的policy。

Metadata

SRB在Metadata上的努力，基本上算是可擴充的這個方向。資料庫的設計，除了一些模糊索引的機制，讓人不要輕易的破解之外，多半是在處理Metadata及ACL。達成的就是任何一個檔案都可以任意修改其Metadata。在Federation的第三個動作(投影片15,16)，其實可以看見Metadata的處理是第一個最重要的動作。實際上Client程式或是使用者，在瀏覽目錄，看檔案名稱，狀態，可能絕大多數的動作都是在讀取Metadata。但問題在於：

SRB並未有任何的Metadata快取，就現階段也並無階層化的架構來分散式地處理Maeatada。

除了所支援的DBMS以外，並無法改變任何Metadata儲存的方式。也就是他的Metadata中立也不是完整的，而是綁在資料庫上，其傳輸協定也綁在自行撰寫的binary protocol上。目前任何一個Metadata動作，都必須透過SRB Client Query <->Binary Data(因為要透過Socket)<-> SRB Server(MDAS) <-> DBMS來完成。一旦使用者想要儲存在SRB尚未支援的metadata儲存方法上(如xml)，就顯得無法擴充。

此外儘管SRB支援多種不同的Metadata Service(MCAT Server)的串接方式，例如 P2P或Master/Slave。其難以安裝的MCAT，無法造成使用者能夠實做多種架構，而來提升容錯度。

對於一個以 Metadata為核心，而需要資料庫的系統而言，有幾點值得討論：

既然任何節點查詢Metadata並不是透過網路來直接對資料庫查詢，那是否需要網路型的資料庫系統？

既然建立索引及搜尋為最常見工作，是否該採用已經最佳化建立索引並搜尋的資料庫系統？

既然Metadata大多數時候是直接讀取，是否該將這些Metadata快取成最後要輸出的格式，而減少資料庫讀取及跑程式轉換格式的時間？

Security

SRB支援三種安全機制，一個是內建最簡單的加密，稱做encrypt1。另一個是GSI，這個使用方式提供很高度的整合性。如果安裝好Globus，並且已經建立好Server,User憑證等相關安全性資料，那SRB就可以直接引入GSI函式庫來編譯，最後就能夠不用設定太多東西，啟用了憑證proxy後就可以連線。另一點是在這種情況下，也能夠透過GSI進行cross zone的資料通訊。

儘管支援了GSI，但是卻只支援Globus 3.0的版本，而與現在Globus推行的4.0是很難搭配的。

Policy

很可惜的是，SRB對於Policy的貢獻並不多，一直到下一代的iRODS才能夠提供給使用者進行一些scripting方式的修改。而我們並不清楚提供這樣子的功能對SRB本身會是多大的系統負擔。

要構成Policy中立，不單是提供良好的API給使用者能夠自行撰寫並override原本的策略，預設的策略也是相當必要。

設計考量

這些問題加上一些經典的文獻，我歸納出幾點重要性：

Mechanism

資料的存在性的控制，必須是基本的動作。

也就是說如果一個data grid middleware如果需要人工去探知資料的內容還在不在，那後面的所有動作都無法完成。Data grid必須克服這個問題，告訴使用者某個檔案的內容是否還在網路上，或是如果不在，便應該要通知使用者該如何處理，或是進行不阻礙使用者觀感的例外處理。另一點重要的是，Data grid必須能夠主動地維持某資料的內容在網路上，直到使用者確認刪除。不是透過使用者的使用態度來配合，而是在軟硬體架構上當初就該如此搭配設計。台灣的學術網路環境，並不見得各學校都是很穩定，維護人員也不見得有一定的素質來想辦法讓機器7x24不斷線。因此某一個資料的實體，自己該去哪，必須讓「它自己」來思考。同樣的這個資料的metadata也應該是如此。

儲存媒體的考量。

由於Storage Abstraction的關係，必須是全天下的都要可以。但一個計畫不可能把時間都花在這裡，一定是最常見的File System如NTFS及EXT2/3，也就是Windows及Linux這兩的作業系統必須完全相容。但至於是某要支援非傳統的儲存媒體，如光碟片，或是資料庫，則必須在儲存媒體上也有Metadata，才能讓資料在思考要去哪的時候能夠決定。

Metadata

索引也必須是分散的。

Web本身是一個龐大的分散式資料庫，而Google就是其索引，各位也知道拜孤狗大神有要技巧，才能心想事成，Data Grid上可不能這樣。Data Grid並沒有那樣龐大的範圍，也沒有複雜的網頁或語意要解析，對於metadata而言，大多都是以key-value構成的配對。Metadata的索引，Metadata Catalog(MCAT)，除了要是階層式的，當然也應該是分散式的。這個方面，DNS的查詢架構就足以解決這個問題，剩下的就是如何利用P2P建立一個可以尋找哪裡有MCAT的網路。

在這裡要提及P2P Grid的基本觀念。以往的作法，可能是把Grid協定改成P2P化，或是反過來修改P2P的服務提供方式，讓他看起來有點像Grid。可是在這裡的P2P DataGrid只會將P2P應用在建立各種類型的索引網路上，包括MCAT網路及Resource網路。當然P2P的通訊將會是這些網路節點的基本功能。

Metadata及其資料的輸出入並需要可以套用任何可能的Domain Specific Model。

不管平台再怎樣好，使用者最後的目的還是在使用這個平台把資料從任意地點輸入，然後從任意地點搜尋並輸出。前面提到的存在性與分散式索引，已經解決任意地點的問題。可是輸出入還是大問題，這個部分我也再加緊尋找各種不同的想法中。目前最原始的方向，還是對開發人員提供類似SQL的語法，對於開發人員來說，Data Grid應該要是像資料庫一樣可以CRUD。這個部分，透過Ruby on rails的activerecord pattern，已經給了我很好的參考。

Security

資料的權限受到控管，動作也該被稽核。通常資料的擁有人(owner)與資料的實體存放位置絕對不會相同，因此也只有當初加密這個資料的人能解開，或是被這個擁有人的上層管理單位委託解開才行。所有資料的寫入或讀取動作應該被紀錄，而相關的人員也該被通知，此為稽核。為了防止過度的運算資源浪費，也應該要提供其他的安全策略，而也應該要可以繼承。既然受到稽核，對於管理者而言，資料的分佈，狀態也應該要是隨時可以取得。此外，該與GSI整合到怎樣的程度，也是問題。

Lightweight

輕量化的設計。

由於上述這些考量，整體設計就勢必如一般的P2P軟體一樣是分散式的，而透過索引來達成實際的搜尋與整體資訊的取得。使用者的運算資源應該盡量地集中在提供所引這個部分，而不是跑程式來進行IO的轉換。

參考資料

http://www.ibm.com/developerworks/cn/grid/gr-srb/

更新至Wordpress 2.3

2007-10-24T08:15:00.000-07:00

似乎終於願意開放tinymce的功能了，原本就有，不知道為啥一直不給用，得自己改。加上這次啟用了多個加速功能，包括mysql query cache，eaccelarator，wordpress 內建快取等，有些頁面的回應速度終於降到了1秒以下，連另一個站的wiki也快很多。老是在寫追求高效能的web application，連自己對秒速的感覺也變得遲鈍。現在都會希望要求東西在1秒內就要出來，1秒以上的也不要在連續的操作裡出現太多次。

加上了Challenge，雖然有點不方便，不過spam真的太猖獗，沒辦法。本來就有裝akismet，後來還換了domain name也沒啥用，一下子又變成一天幾十個。本來是想要換布景主題的，不過看來看去怎麼還是這個最好看。

目前還是持續在寫有關SRB與DataGrid的文章，越來越多學校的同學們(被迫)加入研究datagrid，這是一種趨勢嗎？不過說真的的我是很相信整合是一種趨勢沒錯。但問題還是在於

太少Unix技術訓練，大學以上的教授大多都認為會用這是理所當然的，實際上他們自己都不會用，更何況會教或引導學生？

應用範圍的研究方向偏多。其實這本來就反映出DataGrid的本質，只是在台灣大家不管做啥論文都還是會希望有個演算法，才能「看起來」有點料，所以很多人都還是做Replica問題的，卻又因為這跟datagrid相關而又得乖乖地來接觸SRB。

沒有真正有商業價值的應用。SRB賣給Nirvana之後，這家公司便出了很多「企業」專用方案，乍看之下確實功能強大，而且符合可擴充的需求，實際呢？究竟有多少企業真的選擇SRB做為整體性的解決方案？而其他Grid計畫，某些層面不見得是要拿來賺錢用的，不能夠相提並論。

有資料典藏的方案，可是尚未顯示其價值。很多地方都在做資料典藏，著名的internet archive，收集了自從創立以來網路上所有能夠找到的網頁。這些計畫一定需要大容量可擴充可容錯的儲存，但存了一堆東西，也沒有一個人感受到這與自己生活有啥關係。

這幾點，對我個人看見的現象相當地明顯。有的人希望DataGrid是一個超大FTP，有的人希望他是anywhere access，有的人希望這可以超越世界上任何一種儲存的速度。但沒有一個人真的瞭解DataGrid在做啥，目的又是什麼。正如同很多人也不瞭解Grid是要幹嘛。對Grid來說，整合這件事應該是要同時帶來方便性和速度。但實際上我們也看見很多例子說明，整合只會更慢。

對於長久做Grid計畫的我而言，整合是一種痛苦，代表各校各自表述卻又不得不聚在一起凹出一個東西。整合只會讓權力更大的人握有更多的東西，而並不見得會對民生或是一般人常用帶來啥益處。為什麼整合會成這個樣子？也充分地表現出社會的運作。我想真正的整合是大家一起尋找出眾人都能得到利益，卻能夠維持原本特定型態網路運作的途徑。

舉例說，以前驢子出了很多Mod，有的是為了有趣，有的是為了站方（或站務群）的個人利益。實際上一直到今年，我所看到的還是維持大眾利益的站活了下來。像我常去的m-team這種型態的就是例子，儘管不多，我也依然在用自己的方式貢獻流量或是發個文章。確實，站方說自己辛不辛苦我們不會知道，不過如果正確地找到方向，不輕易違背諾言，不輕易放棄使用者，那又有什麼站會因為人數太少而倒？辛蒂關站的時候，包括我在內不知道有多少人嚷著要捐錢。對很多人來說，使用者便利，習慣是讓他們貢獻自己手上金錢的主因，因為這對他們來說是價值，最後當然還是得稱讚長期努力的站務群。

做了幾年計畫，雖然也沒啥貢獻，也不敢說做了什麼好東西，可是真的還讓我覺得滿無聊的。問題並沒有得到好的解決，可是講的人卻可以講的口沫橫飛，聽的人則多半是在台下說「這也不怎樣」，但也未見其提出好或不好在哪。帶頭的人總是有著太多的理想，底下的學生總是做的半死。直到我開始在軟體公司工作了，雖然以上情境沒啥不同，才發現其實心境有很大的不同。至少我的想法比較接近雙贏，不再是做一個要求使用者改變習慣的東西了，也不會不顧自己總是做白工，而無法思考獲利的方式。

不過套一句我的老師說的話，「研究就是這樣」，可能現在的我也是在夢想與現實中尋找一些路吧。

Single Page Application - 下一代的Web應用程式

2007-09-26T09:11:00.000-07:00

在Web Service, Ajax, Web 2.0, REST等Web應用與技術話題熱潮，帶動許多第二代的Web開發技術成長之後，這些話題也漸漸地消退。不過許多人可能不曾發現，其實這些技術名詞，是在慢慢地顯露一點：Web應用程式逐漸從Server Side轉移到Client Side，也就是瀏覽器身上。

本篇文章要從以往的Server Side Web應用程式，其開發方式與演進來介紹Single Page Application(SPA) 與現今所有主流Web技術。

我在Web 2.0過去，現在與未來及介紹Ruby On Rails都有提到一些Web技術的演進，比較明顯的趨勢就是從靜態到動態頁面，而設計的方式也更程式化。而在http://atedev.wordpress.com/2007/01/09/Web2.0：過去，現在及未來也有讀者在前言提到，技術並不是將一個名詞安上去就好。我相當贊同這句話，因此也在這篇文章中希望來做個總整理，以技術及歷史來看看Web是怎樣成長的。

Web應用程式的演進

動態網頁

儘管Web並不是一個三言兩語能拿個版本號碼來解釋，但實際上Web技術確實有些明顯的分隔點。

最早期我們熟知的就是靜態網頁，這應該沒啥問題。儘管在2000前，php,asp就開始流行，坊間的書上也都稱之為動態網頁。而我在此提及的動態網頁程式，實際上卻是從php4釋出的那一年開始(註釋)。這邊要讓大家瞭解的分界點，其實是php4開始被許多商業公司所採用，而軟體的形式也更為套裝化，而不再像之前大家認定的「動態」網頁僅僅只是拿來完成一些簡單的區塊來與一般的靜態網頁整合。

在2004年的時候，Web Framework的產生，創造了Web應用程式另一個新的高峰。而在這個時候也開始有一些Rich Web Client概念的雛形了。我將Ruby On Rails定為一個分界點是因為，他顛覆了傳統動態網頁還在使用設計方式，而改用MVC。但要注意的是Ruby On Rails儘管整合了Ajax與進階Javascript函式庫，但還是沒有改變回傳完整或部分HTML的方式，意思便是HTML的產生始終在Server Side。

Rich Internet Application

一直到現在，有相當多的Web應用程式，都還是維持使用URL來切換各種功能與畫面。而這些以「頁面」為主的程式，並不太需要控制DOM，就不常遇到跨瀏覽器問題。然而自從Firefox逐漸也在市場佔有一席之地，Javascript的應用普及之後，跨瀏覽器問題也接著發生。為了避開各種不同的瀏覽器所帶來的問題，各大企業都獨力發展自己可以嵌入在瀏覽器的應用程式。早期如Java Applet及微軟的的Active X，算是Rich Internet Application(RIA)的開始，但效能方面還是差強人意。

直到2004年的時候，RIA出現了兩種不同的實做方法：一種是承襲以往需要安裝額外Runtime或是在特定瀏覽器才能執行的方式，稱做Sandbox；另一種是只採用CSS,HTML，並以Javascript控制HTML DOM的Dynamic HTML方式，優點就是只需要瀏覽器就可以執行。而後者也延伸出利用Offline Database或是Ajax+Web Service來傳送與儲存程式資料，並可以儲存成一個獨立頁面的Web應用程式，稱做Single Page Application(SPA)。SPA最典型的例子，就是Gmail。Google盡力克服了跨瀏覽器的問題，將Javascript發揮的淋漓盡致，讓大家驚嘆光靠純粹的Web技術竟能做到如此程度。

而我將2005定為Sandbox RIA真正開始的年代，也是因為Adobe併購Macromedia，而有了較完整的開發環境與資源，並不是以往單純地嵌入Flash。這個契機也促使微軟改變策略，比起效能較差的Asp.Net，而拿Sliverlight作為Web下一代主力軍。

RIA或SPA都是學習歷程長，語言多又複雜的Web應用程式技術，也因此發展速度相當緩慢，但不可小看的是這些優點：

相較以往在Server上產生HTML並回傳至瀏覽器，任何畫面皆利用瀏覽器本身或附加的功能來產生。形同於借用了Client Side CPU的運算資源，減少Server成本。使用者感受到的互動性與回應速度皆有大幅的提升。

由於Server並不是每次都回傳複雜龐大的HTML，而是利用XML或JSON傳輸資料的部分，使用的頻寬也相對變小。

Server Side除了使用傳統XML Web Service，更可以採用REST，讓Client的應用程式可以更快速掌握資料的新增修改刪除(CRUD)並簡化呼叫的服務URL。

能夠快速Mashup其他的Web應用程式資源，又能擁有高速的執行效能。

下表列出了Web技術的演進，要注意到後三種技術集合，其時間是並行的：

	靜態網頁	動態網頁程式	Web應用程式	Rich Internet Application with Sandbox	Single Page Application
時期	2000以前	2000(php4釋出)~2004	2004(Ruby On Rails釋出)以後	2005(macromedia被adobe併購)以後	2004(Gmail釋出beta)以後
表現層	CSS	CSS,HTML,Javascript	CSS,HTML,Javascript	Flash, Sliverlight	CSS,HTML(DOM)
邏輯層	Javascript	Template或自行撰寫	Web Framework	Action Script, C#	Javascript或是撰寫Web Service的語言
資料層	HTML	Database(SQL)	Database(ORM)	Database(ORM)	Offline Database, Web Service
開發方式	網頁編輯程式	整合HTML及Server Side語言的編輯器	整合Web Framework的IDE	整合Sandbox的IDE	整合Server Side與Client Side語言的IDE
運算資源	所有資料直接透過Web Server送出，除了硬碟讀取，幾乎不需要額外的運算	因為使用了Server Side語言來Render表現層，運算多半會消耗在Server	因為使用了Server Side語言來Render表現層，運算多半會消耗在Server	運算資源平均被分散在Server及Client，但Client需要Sandbox去執行，所以會消耗更多CPU資源	運算資源平均被分散在Server及Client
資料格式	傳送完整的HTML	傳送完整的HTML	傳送部分或完整的HTML	只需第一次傳送HTML及內嵌程式(Flash或Sliverlight)，其餘傳送XML	只需第一次傳送HTML及Javascript，其餘可傳送XML或JSON
優點	簡單易學	學習同一種Server Side語言，搭配簡單的HTML,CSS,JS觀念便能夠有成果	整合Ajax或進階Javascript函式庫，REST及MVC。使得設計概念更為物件導向化	使用者介面反應快速，變化多且美觀。兼顧視窗程式的反應速度，且能部分相容傳統HTML應用。	完全相容傳統HTML應用，及任何可能的Web應用程式Mashup。可以採用不同的傳輸方式，併和REST及瀏覽器快取來節省頻寬，使得整體反應相當快速。
缺點	無法讓使用者儲存任何應用程式資料，任何資料必須藉由人工設計	對於龐大的應用程式，便得花上大量的Server成本。程式反應速度受限於伺服器負載，需要叢集架構來彌補。	設計方式更為簡單快速，但相對於傳統的動態網頁程式付出更大的Server成本。	除了CSS,HTML,JS以外還需學習一兩種不同的語言才能進行開發。RIA通常程式資料較大，在開始使用前必須等候一段下載時間。	除了CSS,HTML,JS以外還需學習一種撰寫Web Service的語言。需要相當熟悉DOM及CSS，也需考慮瀏覽器的差異，開發起來相對地困難許多。

表現層的演進可以得知，不管是RIA利用sandbox或者是SPA利用DHTML作為表現層，相較起來傳統以文字HTML拼湊出畫面的作法已經無法符合使用者的需求。更動態，更彈性的作法才能讓使用者獲得操作感。

而在邏輯層上，演進到了SPA則是變得較為複雜。如果是使用Web Service作為Server Side，除了必須撰寫該語言外，也還是得撰寫Javascript來控制畫面的呈現。而這也影響到開發方式，以往的編輯器多半著重一種主要的語言上，但現在的Web IDE多半都可以完整的處理所有瀏覽器的語言，及多種Server Side語言。例如Aptana IDE就是最好的例子。

資料層的演進就比較簡單，直到RIA的時期，還是相當依賴傳統的Database。但SPA的時期，就可以採用Offline Database，這裡指的就是Google Gears。但如果要使用傳統的Online Database，全部都尚未有Javascript的Client，就必須透過Web Service來轉換資料。而在SQL到ORM的演進上，雖然使用物件導向的作法減緩執行速度，但相對降低開發難度，帶來更大的價值。

Single Page Application

定義

請參考 http://www.answers.com/topic/single-page-application?cat=technology

Single Page Application是一種Web Application，完全地在瀏覽器上執行。也就是說，標準的SPA程式是不需要網路連線的。

像這些範例，你可以使用firebug來觀察連線的動作。

TiddlyWiki http://www.tiddlywiki.com/：這個wiki editor，除了整整一萬行的javascript以外，只有一個很簡單的起始頁。就算你拔了網路線，也只是不能夠儲存而已。但他要如何儲存編輯好的wiki內容呢？必須設定外部伺服器進行同步作業。

Protopage http://www.protopage.com/：外型設計得很漂亮，操作感也很順暢。仔細觀察你也會發現在進行網路傳輸的時候都是傳遞JSON。

而畢竟沒有網路連線的程式很難作為應用，所以我在SPA架構一節會提出兩種SPA程式的演進。
在此也必須提出一個概念，SPA並非只是一個「不切換頁面」或是「URL不變」的程式。而SPA所使用的觀念，就如同前言，已經是將瀏覽器當作client端了。
既然是client端，那勢必代表中間是必須傳輸資料，而並非HTML；也因此HTML的產生也會發生在client端，而並非傳統由server產生HTML再由瀏覽器載入。

所依賴的Web技術

Ajax為Asynchorous Javascript And XML，早期Ajax被用作來傳輸單純的HTML或是XML，並且利用DOM的innerHTML屬性來更新部分HTML內容。如今Ajax在SPA中被當作重要的傳輸媒介(Transport)，無論範本資料到應用程式資料，都是利用Ajax在背景傳輸完後，再由Javascript Template來產生HTML。

JSON為Javascript Simple Object Notation，在標準的Javascript語法中，以{ }及[ ]這兩個語法，可以宣告物件與陣列，並可以使用eval函式將他轉換為Javascript物件。例如object=eval("({a:'b'})")，此時object物件便有一個屬性"a"其值為"b"。在SPA中，JSON被運用來作為一種資料格式，藉此取代複雜的XML，以節省頻寬。而傳輸的JSON資料又可以快速還原為javascrip物件，又更節省程式執行的時間。

在SPA中，HTML DOM是一個最重要的元素，尤其是DIV及SPAN等Container的操作更是。由於絕大多數的畫面都不進行任何換頁的動作，程式裡大部分都是在控制DOM及Container。而對於A (Anchor)而言，href裡的URL也沒有太大意義，多半都是在onclick裡寫javascript，或是用Javascript函式庫去bind onclick事件。由於直接呼叫瀏覽器提供的DOM函式庫功能，會遇到像IE一樣不符合W3C規格的問題。要選用一個合適的Javascript擴充函式庫，如Prototype.js或是jQuery，如此才不會有太多跨瀏覽器問題。

CSS在以往的Web應用程式中，多半都拿來當作畫面的修飾，布景主題或是顏色特校。但在SPA中，必須要熟悉CSS的Dimentation(長寬控制)，Classification(顯示行為)，Positioning(定位)。在無法換頁的狀況下，只能靠著移動，隱藏，顯示這些方法來控制畫面的元素。如果要瞭解這些進階CSS的主題，都可以在w3school裡的教學找到。

Trimpath是Google為了SPA而開發出來的一個函式庫集合，也可以說是Rails的Javascript版。如果要撰寫上述第一種SPA，就必須利用到Trimpath的全部，而第二種只需要用到Trimpath Javascript Template即可。Javascript Template(JST)如同PHP的Smarty一樣，是標準的範本技術，只是採用的語言是Javascript。為了撰寫SPA，必須要好好地運用JST。

快取的機制在SPA也相當的重要，為了達到讓使用者感受到程式的反應快速，就必須應用多方面的快取。

View Cache：SPA中的View就是指已經顯示出來的HTML，很多常用，而不需要經常改變的HTML，就可以將放在Container(DIV或SPAN)裡。不用的時候就隱藏，需要的時候就顯示。而另一種方式是可以用z-index將選單或是清單的Container放在最下層，而要回到這個清單的時候就將蓋在其上的container隱藏。

Template Cache：一般來說JST的範本資料只要讀取一次就可以，又因為這些只是字串，可以直接就存在Hash裡。

Javascript Cache：在我提出的SPA實做中，有一個特性是將各個JST的「行為」程式碼分開，就如同sap.net將aspx與cs檔分開的作法一樣。而如果採用這個作法，不需要重複讀取的javascript就必須要快取。

Data Cache：資料快取是最難的一部份，牽扯到了快取一致性的問題。而現在在javascript中並沒有對於XML或JSON的資料快取解決方案，未來如果能夠有這樣的函式庫，就能夠更提升整體的效率。

以上說明的都是Client Side所必須要使用到的技術，而Server Side的技術多半與Service Design息息相關。

REST為Representational State Transfer，他比較像是一種設計樣式(Design Pattern)，而不是Web技術。在以往Web應用程式的規劃中，URL並不完全具有意義，傳輸的內容型態多半是HTML，而HTTP的各種動作也並未完全利用。在SPA中，由於需要在不同時間傳輸各種資料，如HTML範本，JS範本，或是XML及JSON資料。此時REST的設計技巧就可以節省下很多重複的命名，而讓程式碼整體更有意義。支援REST設計樣式的Web Framework如Ruby On Rails，讓整體設計較為簡單。

SPA的架構

SPA就分類而言，算是RIA的一種，只是不採用任何的sandbox而已。典型的SPA是不需要任何的後端的Web Service或是Offline Database，只需要一個htm檔或是一個網頁就能夠運作，如微軟的HyperText Application(HTA)就是，但還是缺乏完善的資料儲存能力。

第一種SPA程式，如同著名的Google Reader離線版，具有一個離線資料庫與一個同步管理程式，在有網路連線的時候，會將資料同步回線上的資料庫。這個最大的優點就是完全利用了Client的CPU資源，使用者雖然看見的是網頁，但卻是在使用在本機執行的獨立應用程式，因此速度是相當流暢。比起一般的動態網頁，這樣子的使用體驗更能夠顛覆一般人對於「網頁」的看法，而逐漸瞭解何謂Web應用程式。另一個例子是使用Trimpath函式庫撰寫成的NextAction，是一個多功能的ToDo List。

另一種就是較簡單的SPA，不具有離線瀏覽的能力，但是承襲了使用javascript的高效能。必須提及的是Server Side並不是採用XML，而是可以快速轉換為Javascript物件的JSON，來當作Web Service。如此Server Side的語言只需要具備能夠快速將物件serialize成JSON的能力即可。

Rails與SPA

這個小節所要說明的是相當技術性的部分，無法說明的太詳細，有興趣的讀者可以寫mail一起討論。為了簡化觀念，我使用Sequence Diagram來說明Rails要如何應用在SPA上：

URLRequester是一個javascript函式，主要的工作就是以REST方式對一個URL進行不同Content-Type的Request，並且將回傳的資料產生HTML，並填到container裡顯示出來。

HTTPRequest在這裡作為進行Ajax呼叫的傳輸媒介。

RailsController表示伺服器端對應至特定URL的程式，在這裡也必須使用REST方式來回應。也因此如果要求content-type為HTML的時候就傳JST範本，要求JSON的時候就傳資料，要求javascript的時候就傳javascript文件。

RailsModel代表伺服器端的資料庫，在要求資料的時候，勢必定要連資料庫來取得資料的。而回傳的時候，就將ruby物件serialize成JSON。

Client呼叫URLRequester函式，例如http://servername/controller/action/id。

HTTPRequest送出一個要求，並指定Content-Type為HTML。

RailsController接到指定的URL，並執行controller#action。我將JST寫在rhtml裡面，JST基本上也是html，不過是範本的標籤換成{}而已。因為REST設計方式會因為指定的content-type回傳對應的型態，此時直接將內容的JST文件傳回。

在前面我有提及快取的重要性，所以這裡就快取住這個JST，下次要求同樣的內容就可以直接使用而不用重複傳輸。

對於同一個URL，使用HTTPRequest送出要求，並指定Content-Type為JSON。

因為REST的特性，這次會執行到content-type為JSON時的程式碼，接著就可以照一般方式使用Rails Model讀取資料庫。

Model傳回的Ruby物件，當然就要轉換成JSON回傳。而在ruby中相當簡單地便是呼叫to_json就可以轉換了。

回傳的JSON，併和剛剛快取的JST，使用trimpath javascript template函式庫產生成HTML，並更新至container裡。

在這裡我採用行為javascript程式碼與範本分離的方式，所以還是以HTTPRequest再次傳送要求，並將Content-Type指定為Javascript。

同樣地根據要求的content-type，會回傳javascript文件。

快取，並呼叫eval執行回傳的javascript。

將container顯示在想要放置的畫面區域。

結論

許多人都在說Web 2.0可能又是另一次的泡沫化，這個熱潮怎樣開始的，又怎樣消退的，也是相當明顯。網路上對於各種新技術名詞的炒作，將不同應用層次的技術，全部攪和在一起說明或稱做是最終解決方案，也模糊了使用者的眼睛。那麼，在這個時代，到底還有什麼可以相信，可以學習的？

唯一能夠做的就是重新審視這些技術，瞭解因果。就可以知道哪些作法是適合用在自己現在的專案，那些是本質相同的，哪些是跨大其詞的。根本的觀念正確，就不需要擔心這些延伸的技術是否會有誤解或誤用。

註釋
在2009年3月的時候，對岸的一位作家周愛民老師有指點了我有關php4在這個時期的定位。周愛民老師最近的大作為「JavaScript语言精髓与编程实践」，其中的第一章的各個第三小節，請各位參考。文章中也提及了那個年代的一些真實的狀況。

但我在這邊還是希望解釋清楚，確實用php,asp來定義「動態網頁」(甚至我還說php4)並不是最正確的說法。但實際上我必須說明這是當時臺灣的書籍普遍描述的名詞與認知，我想台灣的早期的網頁程式設計師們應該對我的描述很有感受吧！

實際上真正的「動態網頁」應該指的是Dynamic HTML (DHTML)，表示使用javascript去控制HTML DOM進而直接在網頁上產生動態效果的作法，而並非是server side的任何技術如php,asp,jsp等。但隨著時間演進，DHTML這個字眼也逐漸被人淡忘，變成是Ajax。當時的DHTML也已經有人嘗試著使用javascript與server通訊，那就是與現在的Ajax沒啥不同。至於說php,asp等的為啥會被說成動態網頁，也只是反映出那個時候台灣普遍對網頁設計的認知而已。

我很感謝周老師對我的指點，特此說明當時寫文章的想法。

Ruby on Rails 與 ruby-postgres

2007-09-02T17:49:00.000-07:00

ruby-postgres

有網友與我提出Rails與PostgreSQL的問題，我就順便寫一下有關PostgreSQL的問題好了。

安裝的方式請參考

http://postgresql-chinese.blogspot.com/2007/08/windowsrailspostgresql.html

不過我在這邊順便補充，其實當初會捨棄postgres-pr還是因為效能的問題，native binding終究是比較快的。

在此先對新手說明一個觀念，如果你想一步一步玩熟Rails，最好還是多善用ruby script/console來進入Console mode。而Console其實也只是呼叫irb去載入environments.rb，這個檔案會陸續載入plugin, model及你指定在environments.rb寫的所有require。Console有兩個用途，一個是測試是否你能正常啟動Rails，第二個是測試你的Model是否正常，例如測試association。而如果console都啟動失敗，或是Model.find出來的都不是想要的，那真正啟動mongrel去跑頁面是一定不可能是對的。

而許多在windows上面安裝的人一定會遇到函式庫載入失敗的問題。要注意的是，安裝任何mswin32的gem都是有可能出現這樣的問題的。這個時候如果你是去看rails的development.log或是看到exception，通常都還是會說是driver有問題(可能會是xxx.so載入失敗之類的)，這樣是看不出來的。此時使用console，一啟動的時候他就會告訴你是啥dll無法載入。

而大家使用ruby-postgres，如果不安裝PostgreSQL Server Win32，有幾個重要的dll是不會被載入到windows裡的。這個使用請先安裝PGAdmin III，然後將他的安裝目錄裡的libpq.dll,iconv.dll,krb5_32.dll,libiconv-2.dll,libintl-2.dll,comerr32.dll至你的ruby安裝目錄下的bin即可，還是一樣先試試console能不能開吧！

Ruby的很多Win32函式庫都是用這種binding的方式，而並非是使用ruby撰寫而成的。所以如果今天是發現gettext不能用，就應該要去尋找gettext win32，然後將缺的dll複製到bin下即可。

該如何發問？

最近在論壇觀察了一下，發現Rails新手的朋友們，應該要接受一些觀念建立，以免回答的人答非所問。既然我遇到人來問問題(還好不是來踢館)，也免不了要提倡一下，這觀念在任何一種程式語言都適用。

詳述問題：想要讓人瞭解問題，就是要說明你的目的，及你在發問之前曾經做了什麼。如果不是技術上的問題，例如是求函式庫，求解法，那更要說明清楚前因後果。

有Exception訊息的要貼exception：Rails當發生任何錯誤的時候，就一定是大家所熟知的畫面，「{ErrorName} in {Controller#action}」。接著就是貼ErrorName，以及下面灰色區塊裡的描述。第二個灰色區塊就是trace，如果可以的話，請複製5~10行，如果是寄信，或發文可以不受篇幅影響，全部貼上來也無所謂。不然可是沒有人知道你在問啥的喔～

有畫面的請貼畫面：如果是ajax，html等其他UI上的疑難雜症，就一定要貼畫面了。然而是複雜難以解的問題，就要請你去用用fiddler了。例如有看過google maps不能用的問題，其實後來深入一看其實就是referer被擋的問題，這種狀況應該要詳細貼出http request及response，才能讓解答的人知道是啥狀況。

我使用過的Ruby Library或Rails Plugin

2007-08-29T09:04:00.000-07:00

Ruby Library：

REXML。寫XML的話也沒有別的更好用了 http://www.germane-software.com/software/rexml/

ROXML。這個可能對我自己的特殊應用比較有意義吧，如果是撰寫standalone rails app而又不想用sqlite的話，其實另一個選擇就是效能更好的XML Database。但是在這個技術尚未真正成熟的情況下，XQuery + ROXML也是不錯的選擇。http://roxml.rubyforge.org/

Gettext。這個真是牌子老信用好的東西，不過我或許還會想要選擇用更簡單語法撰寫語系檔的函式庫。http://manuals.rubyonrails.com/read/chapter/105

Ruport。一剛開始接觸Rails的時候還以為會像php一樣報表函式庫一直都沒有高度整合性的，心裡最想用的大概會是有點像crystal report吧。不過好在有這個，已經相當完整了，pdf，cvs該有的都有，使用上也很方便。http://rubyreports.org/

Chart Director。這個雖然是商業的，圖的顏色也不是挺漂亮的，不過因為想要畫的圖比較複雜只好勉為其難。

UUIDTools。這個也是特殊應用，有可能你對一筆資料所對應的URL想要複雜到讓使用者無法猜，或是想要試試看分散式資料庫，或許你會需要這個。http://www.cnblogs.com/funjackyone/archive/2007/06/01/768275.html

RJB。雖然jruby內建連結java的語法相當直接，不過jmongrel+rails的效能可不敢想像，我看我還是耐心的等到明年好了。可是我的專案還是得整合Java...唉，這個時候還是乖乖靠這個老牌子吧。http://rjb.rubyforge.org/

Rails Plugin：

acts as authenticated。

file column。搭配RMagick來resize或是crop實在是讓圖片很漂亮，速度又很快。

acts as stripped。當初想說只是要清掉一些亂打的html tag，其實用acts as sanitized也是可以。http://offtheline.net/2007/6/14/acts-as-stripped-auto-stripping-html-from-a-field

acts as ferret。本來我是想要用acts as tsearch，不過還要多一些欄位，DB也要有些前置動作。但反過來說acts as ferret有時候還是會有memory leak的情況，我還在嘗試看要怎樣解決。http://projects.jkraemer.net/acts_as_ferret/wiki, http://code.google.com/p/acts-as-tsearch/

Jsonifier。原來的to_json其實是不太能用的，說起來就算是換上jsonifier，也還是得改encoder.rb，加上Time所使用的to_json才行。http://blog.codefront.net/2007/07/11/better-json-output-from-rails-with-the-jsonifier-plugin/

respond to parent。這個要搭配iframe使用，不過看他的javascript程式碼還真覺得虧他想得到。http://sean.treadway.info/articles/2006/05/29/iframe-remoting-made-easy

respond to format。這個其實是kuso，在網路上根本找不到這個plugin~~XD。這是我因為懶惰所使用簡單REST plugin，當然也只是用respond_to do |format| 寫的。對於同一個action，要求html的時候傳回rhtml，js的時候就傳回js，json的時候就執行controller裡寫的程式而已，需要搭配javascript template及自行撰寫的js程序。這是個人專用的，大家看看就好啊XD。

Heartbeat 2.0

2007-08-27T14:50:00.000-07:00

在商業服務的Rails HTTP Cluster觀念及測試中，我提到了failover也是cluster的其中一個觀念。幾年前我用heartbeat，只是單純架設pgcluster的load balancer，那個時候也是簡單的active / standby。在那個時候，有這樣的架構已經減輕大部分人所遇到的問題：有一台掛掉另一台可以馬上取代其服務，讓維護者有時間可以救，使用者不會罵，已經是很偷笑的事情了。不然一般的維護者可能要急得像熱鍋上的螞蟻，拼命地輸入指令試著想要拯救資料或服務，而在數小時的工作後，服務還是救不起來，使用者罵聲四起。但是其實對我而言，這些比起硬體的方案，還是多多少少嫌不方便。

參考這個網頁，可以瞭解有那些failover的方式。
http://www.ukingdom.com.tw/pro/lifekeeper/lifekeeper.htm

先不管後面的階層化或是多方向failover，其中提到的active/active及active/standby，為啥要有這些分別呢？我來一個一個介紹。

Failover的種類

active/standby

對於一般架設LAMP來建置phpbb論壇，或是一些簡單Web服務(如wiki)的管理者，在經費拮据的情況下，通常都是先跑一台，在想辦法生另一台。這時進行active/standby的好處是，原理單純設定簡單，兩台跑同樣的OS同樣的服務，一台掛了另一台頂替。但缺點就會造成standby的那一台會浪費CPU資源，所以在很久以前的小論壇都沒有問題，但是到現在，要應付可能會日漸成長的web 2.0社群式的論壇，可能一開始就不能考量這樣玩了。

active/active

另一種作法是兩台主機都維持上線的狀態，也就是可以說有主站，也有個副站。而一旦任何一方掛了，另一方就可以直接抓下對方的IP，就當作是一樣的服務了。當然這樣還是可以讓管理者有時間可以去處理。然而在商用服務的狀況下，通常使用者會比較難接受有兩個以上的IP或是URL，這個算是缺點之一。但優點就是相對地如果使用者可以接受副站的情況之下，就會有效地疏散流量及CPU負載。

以上就是1.0版的時候提供的功能。有關heartbeat 1.0可以參考舊文章
http://kiwi-grid.blogspot.com/2006/06/heartbeat.html

Cluster Resource Management

而在heartbeat 2.0中已經引進了資源管理的觀念，意思就是將一個服務程式或是一個IP視作一種資源，而這個資源可以任意在cluster裡的任意的node中migrate(遷移)。當然與上述兩種不同的是，在這種情況下node就可以是兩個以上了。這並不是process migration(行程遷移)，還沒有那樣進步連程式或設定檔都可以自己搬走。所有node要拿來當作資源的服務，一開始就必須全部自行建置好在完全正常的狀態。當進行遷移的時候，heartbeat還是會以service {服務名稱} start/stop的方式來完成這樣的工作。其實這個方式基本上是和active/standby一樣，不過重要的是搭配cluster的load balance機制，也就是像下圖一樣。因為本來就要做load balance，每個node預設將apache啟動，而需要遷移的資源也頂多只有ip和haproxy，就不需要浪費時間啟動較慢的apache。

另一點是資源的群組，數量，相依性，啟動順序，甚至限制在哪些node上跑，全部都可以調整。也因此如果要做active/active那樣主站副站的作法也完全可行。

如這兩張圖，假設有一個 cluster有四個node，在正常的情況下，使用者會透過Virtual Server的IP連到Real Server的真實服務，這個我們在之前的文章已經談過。然而套用heartbeat 2.0的觀念，我們將virtual server ip及haproxy設定為資源，接著這個資源就可以進行手動或自動的遷移。手動遷移就像是，當你點下移往第二台的按鈕後，第一台就會停止服務，而第二台就會開啟服務。自動遷移會發生在整個cluster的服務被斷定為無法使用的情況下，其他node自動地挑出下一個Quorum(服務候選人)，並且將該候選人的服務喚起，來完成資源遷移。根據硬體執行完服務的速度，遷移大概會在10秒到30間完成，像haproxy是個小程式，整個遷移的動作在10秒內就完成了。而當cluster上所有node偵測到原本斷線的node回復，又會自動將資源遷移回第一個node，這個是因為heartbeat執行的演算法必須要維持一致性的關係。

儘管heartbeat 2.0多個了這個他稱為CRM(Cluster Resource Management)的技術，卻像是以plugin的方式掛上，核心設定還是沒有啥改變，只要加上crm yes選項就可以啟動了。此外也有附上另一個做的不錯的GUI介面，讓資源建立，監控和操作更為順暢。

此外在閱讀過後heartbeat的wiki後，我確實覺得他們的編排有點「偷懶」，就是提到了2.0版更新的部分，然後讓你把1.0的說明和2.0的說明混在一起看。其實這樣子並沒有辦法好好解釋2.0的觀念。

實做

安裝

在所有linux平台上，包括fedora 6、7， CentOS 5，SuSE Enterprise 10，Ubuntu，Gentoo上都可以找到heartbeat的蹤跡。在這裡就只提到redhat系列平台基本上是採用yum，所以打yum install heartbeat就可以了。不過如果要安裝heartbeat_gui，請確定要有XWindow或是VNC，然後打yum install heartbeat_gui。

兩個設定檔
以下兩個步驟和heartbeat 1.0一樣，先從/usr/share/doc/heartbeat-{version} /複製ha.cf, authkeys兩個檔案至/etc/ha.d/
編輯ha.cf，在node設定的部分，依照你的主機名稱，依序打上。請注意這些名稱一定要符合在該主機上打uname -n所顯示的值

node web01
node web02
node web03
...
crm yes

接著編輯authkeys，使用以下設定即可。如果你的網路環境沒有啥防火牆，建議使用md5或是sha1

auth 1
1 crc

接著在其他主機也依此安裝，也順手裝好你想要當作資源的服務，就可以service heartbeat start來啟動。

與1.0不相同的是，接著可以參考這段影片，瞭解heartbeat gui怎樣操作。

http://www.linux-ha.org/Education/Newbie/IPaddrScreencast

那我稍微解釋各張投影片在說啥：

這邊最主要是介紹，與打指令啟動hb_gui

這邊要提示你，本來在安裝的時候就有新增了一個群組叫haclient，你可以編輯/etc/group然後把你想要的帳號加進去

這邊可以看到主畫面，如果點選linux-ha，也就是cluster的名字，可以看見其設定。Status會顯示with quorum或是without quorum，表示是否能夠找的到服務候選人。記住要是沒有服務候選人的話(通常是只有一台的情形)，是無法儲存設定的，服務基本上也不會啟動。畫面右邊可以看見cluster的屬性，這些都可以在ha.cf修改。

將nodes展開後，可以看見有標著DC的node，這個表示協調者目前是位於哪一個node。以他的設計，協調者也會遷移的，無須擔心。

這邊可以點+圖示來新增資源

資源視窗裡，可以看見現在可以使用資源種類的列表。注意到class/provider會有lsb或是osf，表示是從/etc/init.d讀取到的，或是heartbeat自己提供的。

接著他在名稱裡就打了our_ipaddr，名稱當然是取的看得懂就好。此外旁邊group最好也要填，讓接著要加入的資源也填同一個group的名字。基本上IP當然跟服務綁在同一個群組裡，除非你是想要做active/active。選好填好之後，可以自己刪除或新增parameters，一般來說lsb的通常都可以把parameters全刪了。然後在這裡你可以看見他填入ip address。

如果資源還沒啟動，就按播放圖示吧！

接著因為target_role本來是表示資源啟動的狀態，但因為使用GUI本來就可以看得到，怕會讓自己搞混，就刪了吧

接著只是單純展示資源可以停止，或是可以增加額外的parameters。我在這邊在多解釋一個功能是，可以在任何一個 node上點右選standby來模擬該node斷線，或是點上下的箭頭圖示來遷移資源，這就讓大家自己玩了。

結論

要測試其實很簡單，把網路線拔掉就可以了。不過要注意的是，拔拔插插的動作不要太頻繁，會導致反應很慢；但因為CRM所使用的演算法在node有兩個以上，不修改預設設定的情況下，是不會產生死結的，算是可以放心試。此外也不一定要使用hb_gui來監控，在文字介面下有一個crm_mon指令，可以監控而不會像gui有時候會卡住不更新。

初學者還是要注意，千萬別將load balance和failover所用的程式搞混了。Linux上有名的ip load balance程式為ipvsadm與ldirectord，儘管heartbeat有附資源script來操作ldirectord，但其執行檔還是要自己用RPM裝的。

這一個月來的Google Analytics

2007-08-27T03:58:00.000-07:00

好吧，我承認我有發現，其實大家想要看unix的東西有比rails的還要多。這個呢 ....孤狗大神的分析器有告訴我：

我只能夠說我感謝大家的抬愛，不過很可惜的是，我可能不會再寫有關php的文章了。
讓我驚訝的是，centos及heartbeat竟然是這樣熱門的話題！
最近才剛完成了full-failover的heartbeat 2.0+rails cluster架設，或許趁記憶還新的時候，趕快再來寫一篇吧。

不過其實只要還有人願意看我的文章我就很高興了啦～^^

商業服務的Ruby on Rails HTTP Cluster觀念及測試

2007-08-19T09:14:00.000-07:00

Rails如果運用在正式上線的服務，便是相當需要配置為Cluster(叢集)服務。不過大部分使用Rails來建立Cluster通常都是藉著Apache mod_proxy，但在一些情況之下，他只有好設定的優點而已。另一種方式是利用一些Plugin及設定去模擬Cluster的行為，不過這樣便是消耗CPU的時間。

網路上可以看見許多Cluster的文章，但多半都是介紹單方面的功能，或是許多實做的細節牽扯在一起。這篇文章用商業服務的整體規劃來看Cluster及Rails之間的種種問題與解決方法。文章後面附帶了一節是要解釋如何解讀apache menchmark的數據。而各位如果想要瞭解的是效能，數據上的差異，已經有一篇相當棒的可以參考：
http://blog.kovyrin.net/2006/08/28/ruby-performance-results/

Cluster(叢集)

Cluster中文翻譯為叢集，意指利用多台電腦完成同一工作來達到一般單台電腦不可能負擔的運算量或是穩定度。Cluster基本上分做兩種，一個是純粹作為計算的Computing Cluster目的是進行平行運算。一個是用來提供各種Internet服務的Application Cluster。其中Application Cluster有兩種實做方式，Failover 方式，又可以稱做HA(High Availability)，主要目的是提供不會中斷的服務，而另一個Load Balance方式，就是要提供承受高度負載的服務。一般人難以理解的部分，就是會將承受高負載與不會中斷這兩件事弄混，其實這兩項工作並非有直接相關，管理者可是硬體成本考量是否都要做。

既然是Application Cluster，對於Internet上最主要的服務如HTTP，FTP，Mail等，便有相當成熟的軟體的解決方案。這些解決方案通常是透過Windows
Server或是Unix Server來實做，而在這邊我要推薦Linux。Linux的多工排程效率較Windows好，在高負載的時候核心不會因為過於忙碌而呈現容易當機等不穩定狀態，而Linux本來在很早期就有比Windows更完善的開放原碼專案來解決這些問題，其中最著名的套件就是Linux-HA。

硬體的解決方案也不是沒有，稱做Layer 4 Switch，雖然有較親切的UI讓管理員快速設定，不過價格也昂貴許多。

一般來說HTTP Cluster的架構大概會如下圖，而這裡更加上DB的部分，來說明商業服務是怎樣運作的。在這裡特別標出一個紅色箭頭表示為Failover的架構，當然DB的部分也是可以，不過也是比較複雜所以日後再談。這樣的切割，也會影響到硬體的需求。基本上來說跑Web的東西，不管是用什麼Server的軟硬體，就是吃CPU(關連到一次request的速度)與記憶體(關連到最大負載人數)。而對資料庫而言，CPU就不見得，記憶體的要求會遠比跑Web來得高。我會建議一般的Web Server為一般幾萬塊的PC即可，使用好一點的CPU，記憶體為2G。但資料庫就不能草率，盡量購買高級的伺服器，並具有RAID5或6的硬碟儲存，及4G以上的記憶體。

在這個例子裡面，我們可以看見由四台Real Web Server及三台Real DB Server所組成的Web及DB Cluster。而Virtual Server本身不具備任何的服務資料(如程式碼或圖片...等)，只有一個能力就是將連線重新導向到Real Server，而導向的方式有相當多種，之後會討論。這樣子利用重新導向來將服務負載分散給Real Server的方式就稱做Load Balance。

此外可以注意到 Virtual Server 2，除了上述的功能之外，就是可以偵測Virtual Server 1當機或是無法服務的時候，自動將自己的IP位置取代Virtual Server 1。這樣子的方式就稱做Failover。

IP配置的方式

IP是一個很大的問題，由現今商業服務的環境看來，沒有實體IP根本無法進行任何服務。傳統的作法有三種，NAT，Direct Routing，Tunneling。

IP配置方式	NAT	Direct Routing	Tunneling
伺服器網路功能支援	有NAT功能即可	需支援arp ignore	需支援ip tunneling(設定上較arp ignore複雜)
IP種類	public/private皆可(private ip 就是常說的虛擬IP)	一定要public	一定要public
IP數量	適合少量(100以下)	可以大量	可以大量
Virtual Server負載	高	低	低

整體分析起來商業服務比較適合使用Direct Routing，但缺點也是有多少Real Server就需要多少實體IP。如果只是單純一兩個Real Server，又不太容易弄到很多實體IP，或許較適合NAT。

本篇文章強調商業服務，所以我會使用DR(direct routing)做為例子。

實做

一個簡單的Load Balance環境

接下來的章節，要用一個簡單的實例跟大家說明如何安裝軟體，而這不是文章後面測試所使用的環境。

假設有這些機器，如下：
D1(Director Server 1): P4 2.0G, 768M RAM, 10.1.1.60
R1(Real Server 1): P4 2.0G, 768M RAM, 10.1.1.61
R2(Real Server 2): P4 2.0G, 768M RAM, 10.1.1.62
OS：Fedora 6

Director Server就是要用來做Load Balance的機器，目的也是為了剛剛所說進行連線重新導向。

1. Bind 9實做RRDNS
2. Linux Virtual Server(ldirectord+ipvsadm)
3. Apache mod_proxy
4. HAProxy

Bind是一套相當著名的DNS服務軟體，我想Internet上九成都是使用這個來當作DNS服務，他有一個功能就是可以利用輪替(Round Robin)的方式來讓查詢者找到不同的IP，藉此將連線導向不同的機器。你可以試著下nslookup www.google.com指令，會注意到每次回來的3個IP順序是不太一樣的，而OS會自動以第一個IP作為你這次連線的對象。其實在這裡拿RRDNS來比有點不太適合，因為他並不是針對封包來進行負載平衡，而只是單純切換IP而已。不過這個方式確實是早期進行負載平衡的方式，就連現在都還可以在各處看見。

Linux Virtual Server計畫實行已經相當久遠，目的就是利用ipvsadm這一個以IP為主的負載平衡程式來達到讓所有使用TCP/IP的通訊協定都可以進行負載平衡。由於他是由Linux Kernel所支援，效率相當好，佔用CPU資源相當的低。不過因為ipvsadm並無法針對任何layer 4以上的封包資料進行分析，並不像接下來談到的proxy一樣具有先分析HTTP再傳送的能力，如果將這個功能都寫進去，那要做在Kernel裡就不太可能了。再者ipvsadm要手動設定也是一件難事，所以靠著ldirectord可以進行較簡單的設定。

Apache也是眾所皆知的HTTP Server，自2.0版開始對Proxy的功能大幅度地支援，儘管沒有Squid功能強大，卻整合了Apache，讓他可以進行一些意想不到的作法如Reverse Proxy。以往Proxy都是單向地，從Server到Client，而Reverse Proxy是反過來，可以處理Client HTTP Post到Server的資料。也因此加上一些改善，雙向的Proxy可以完全變成HTTP負載平衡軟體。使用Apache執行其實是有一點浪費效能的，另一個HAProxy就是純粹做負載平衡的，而本身也有簡單的快取能力。

這四種方法其實區別只在於，萬一有任何Real Server掛掉的時候，正要連線的那個人是否會斷線，換句話說就是Director是否有辦法偵測到連線對向是否斷線。結論是mod_proxy與haproxy都可以偵測到，除非機器全部掛掉，或是director自己死掉，不然使用者完全不會感受到任何的中斷。而RRDNS就完全沒有辦法，ipvsadm也是至少會有一次連線會中斷。其實這個結論也是合理的，相對的代價就是使用Proxy方式消耗的CPU會較高。

Director	CPU使用	封包轉送效率	是否會偵測連線	是否會遭遇斷線
RRDNS	低	最高(直接連線)	否	是
ipvsadm	最低	高	是	是
mod_proxy	高	低	是	否
haproxy	中	中	是	否

安裝Bind 9與RRDNS

Bind的安裝已經有很好的文章，請參考
http://turtle.ee.ncku.edu.tw/~tung/dns/bind_conf.html

在FC6上只要yum install bind就可以安裝。

要進行的設定很簡單，首先先修改named.conf，在options區塊裡面加入一行
[bash]
rrset-order {order cyclic;};
[/bash]

接著修改你的正查設定檔(如果你的domain是test.com就應該是test.com.hosts)。根據本例子，我改成：
[bash]
www IN A 10.1.1.61
IN A 10.1.1.62
[/bash]

請注意測試機器的DNS Server當然就要設定成D1了，一旦使用nslookup成功地查到兩個會變動的IP，那接著測試的時候URL就可以使用http://www.test.com。

安裝ipvsadm及ldirectord

參考文章：
http://zh.linuxvirtualserver.org/files/lvs.pdf
http://zh.linuxvirtualserver.org/node/272

基本上安裝了ipvsadm後就可以下指令手動進行負載平衡，而ldirectord只是有比較好看的設定檔。

D1機器：
[bash]
yum install ipvsadm
#清除
ipvsadm -C
#建立Virtual Server IP 及使用演算法
ipvsadm -A -t 10.1.1.60:80 -s rr
#串接兩個Real Server IP
ipvsadm -a -t 10.1.1.60:80 -r 10.1.1.61:80 -g
ipvsadm -a -t 10.1.1.60:80 -r 10.1.1.62:80 -g
[/bash]

接著在R1及R2上，你要設定好一個lo(loopback)的alias並且將IP設定為10.1.1.60，你可以建立/etc/sysconfig/network-scripts/ifcfg-lo:0或是使用xwindow的網路設定來編輯。

R1及R2機器：
[bash]
vim /etc/sysctl.conf
[/bash]

加入

[bash]
net.ipv4.ip_forward = 1
net.ipv4.conf.lo.arp_ignore = 1
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
[/bash]

接著
[bash]
sysctl -p
vi /etc/sysconfig/network-scripts/ifcfg-lo:0
[/bash]

內容為
[bash]
DEVICE=lo:0
IPADDR=10.1.1.60
NETMASK=255.255.255.255
ONBOOT=yes
[/bash]

最後
service network restart

由於request封包是透過ipvsadm轉送過來，real server必須做一件事情就是不要更動封包裡的mac address，而將這個mac address當作response的mac address而送回去，如此client收到的資料才會正常。

安裝apache+mod_proxy

mod_proxy在2.0版後就是預設模組，而FC6上也算是內建的套件。如果你還沒安裝的話，就yum install httpd。
編輯/etc/httpd/conf/httpd.conf
加入
[bash]
BalancerMember http://10.1.1.61:3000

BalancerMember http://10.1.1.62:3000 [/bash]重新啟動之後就可以試試看了，不過要注意這樣的設定就是全部交由後端處理，事實上還可以加一些設定讓apache處理靜態資料的時候直接回傳節省時間。

安裝 haproxy

到了這個小節，你會發現工作越來越簡單，就請各位參考

http://lightyror.wordpress.com/2007/06/04/%e5%9c%a8-centos-%e5%ae%89%e8%a3%9d-ruby-on-rails/

雖然透過rubyworks他會啟動一些不見得是使用者需要的服務監控程式，不過就請各位自行killall吧。
編輯/etc/haproxy.haproxy.conf
global及default區段都不用動，而注意到listen區段，語法是listen {appname} {ip:port}
修改成
[bash]
listen appli1-rewrite 0.0.0.0:80
stats enable
cookie SERVERID rewrite
balance roundrobin
server app1_1 10.1.1.61:3000 cookie app1inst1 check inter 2000 rise 2 fall 5
server app1_2 10.1.1.62:3000 cookie app1inst2 check inter 2000 rise 2 fall 5
[/bash]

之後service haproxy start即可

AB(Apache Benchmark)數據解讀

ab指令的語法是 ab -c {同時進行的request數量} -t {時間} {url} 或是 ab -c {同時進行的request數量} -n {次數} {url}
ab的測試方式有兩種：
1. -t {秒數}
2. -n {request次數}
兩種方式都可以取得可以觀察的數據，不過如果-n太少的話，就沒有意義。我通常都是使用-t 30或是-t 60。而這樣的測試有另一個好處是，在測試的其中，可以找真的人在一定時間內去實際點點看你的程式，如果時間都過去了(先別跟他講已經跑完了)，他還是覺得速度沒有差，那表示效能有到使用者能夠接受的感受。而需要效能數據，其實也是為了使用經驗法則推算出應用程式最多可以容納幾個使用者註冊。

以下舉個一個例子來解讀：


[root@dsa1 ~]# ab -c 20 -t 30 http://some.machine.com/test/
#這裡是版權宣告
This is ApacheBench, Version 2.0.40-dev <$Revision: 1.146 $> apache-2.0
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright 2006 The Apache Software Foundation, http://www.apache.org/

Benchmarking xxx (be patient)
#這裡會將完成的req次數顯示出來，如果每超過5000會再次顯示
Finished 1028 requests

#主機資訊
Server Software:        Apache/2.2.3
Server Hostname:        xxx
Server Port:            80

Document Path:          /test/
#要注意，如果傳輸的資料大小超過1MB，表示使用ADSL的人多少會因為資料量感受到緩慢
#，就可能不會是準確的測試結果
Document Length:        8943 bytes

#這裡表示你下了 -c 20
Concurrency Level:      20
#總測試時間，應該不會跟-t的時間差太遠
Time taken for tests:   30.27095 seconds
Complete requests:      1028
#這裡的Fail表示在TCP階段就連線失敗，如果fail太多次，出來的數據絕對不正確
Failed requests:        0
Write errors:           0
Total transferred:      9478392 bytes
HTML transferred:       9197475 bytes
#每秒鐘的Request次數，可以視為效能的指標。因為這次測試我們使用了-c 20
#表示在20個人同時連線的情況下，還可以保持每秒34個request。
Requests per second:    34.24 [#/sec] (mean)
#表示這20個人裡「平均」每個人感受到的回應時間(不包括瀏覽器顯示出來的時間)
#約是584ms，也就是0.58秒。
Time per request:       584.185 [ms] (mean)
Time per request:       29.209 [ms] (mean, across all concurrent requests)
Transfer rate:          308.25 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   49 382.7      0    3000
Processing:    91  519 1287.7    262   20913
Waiting:       90  518 1287.7    260   20912
Total:         91  569 1542.9    262   21543

#這個曲線圖比較重要，算是ab的數據價值所在。這裡表示了這20個人所感受到的
#回應速度曲線，可以從0.2秒到21秒不等。也就是說，在這裡約有20*90%=18人，
#他們感受到的速度會低於1秒，而其他人會高於1秒。這個比平均數值還要更能表達
#使用者大多都是感受到什麼速度，因為在伺服器很忙碌的情況下，會有像21秒這種
#數值，這是會大大地拖累平均速度及每秒request數。
Percentage of the requests served within a certain time (ms)
  50%    262
  66%    327
  75%    397
  80%    449
  90%    730
  95%   1338
  98%   5224
  99%   8504
 100%  21543 (longest request)

曲線圖繪製出來是這樣：

結論

其實這篇文章寫的滿混亂的，好幾件事情堆在一起講，而無法把每件事情講的比較詳細。不管如何要建議商業用的服務是個大工程，並不是三言兩語可以講的清楚。而我本身的經驗，使用apache真的不管在啥角度來看都是最棒的web server，但是從來也沒有人說他是最棒的director。因此好的管理者心裡總是會構思許多不同的解決方案，而更要瞭解許多方案背後架構，原理，穩定度，效能等問題，而不管哪個是否難做。但讓我覺得可惜的是，網路上大部分文章會誤導比較沒有經驗的管理者，設定簡單或是好裝不見得就是好東西。

儘管我無法一一解釋我曾經測試過了什麼，而直到現在我的綜合感受還是認為haproxy+apache+fastcgi來跑rails是最穩定且效能良好的選擇，但也是設定上稍微繁雜的。

[2007/06/15 - 2007/08/19] Hemidemi書籤摘要

2007-08-19T07:32:00.000-07:00

Streamlined
07/13 10:20, 2007
Streamlined 是一個以meta programming 的方式來撰寫程式碼的rails plugin，而meta programming的意思是說，你只需要「描述」就好，剩下的rails會幫你完成。聽起來很玄，實際上就是他有一個預設的樣版，你只要利用一些簡短的程式碼，如同activerecord撰寫association設定那樣簡單，就可以產生整個app的UI了，基本上不需要動到view。
(標籤: web rails)
Mobile01 打造家用防火牆的需求 by pfSense (一) 簡介篇
08/02 13:55, 2007
這個就是將FreeBSD的網路功能發揮到極限，以前我也曾動手做過，不過覺得Linux上的也不賴啊，只是沒那樣快
(標籤: freebsd 科技)
Ruby 的缺點
08/19 14:28, 2007
有些確實說的很清楚，就是還缺乏編譯器那些的。但是有些我想還是不熟造成的，就算是在javaeye上面的罵一罵，看起來也還像是鄉民的談話。ruby出到現在，廣告到是打了不少，雖然也還是看到有人推出ruby原碼解析(列出)，不過這樣又能學到什麼呢？原本一個能夠進步的東西，感覺起來在亞洲環境下，逐漸變成一種話題般的產物，讓人覺得有點小小可悲啊。

不過我相信還是有人願意去研究pure OO到底是啥，慢不是問題，而是要如何改善。

我的更多書籤 @ HEMiDEMi - 黑米共享書籤

Ruby on Rails的效能低落

2007-08-10T14:44:00.000-07:00

儘管我是寫Rails的，寫了想想也快要一年了。東看西看都覺得這實在是一個好東西，不過反過來，當我們的服務要上線的時候。組長卻說我的benchmark test case不夠好，不能夠測出很準確的數值（或許他心想這太好了，三台準系統可以跑200多個request/sec）。

是的，我是多半隱藏了這個缺點，甚至很不想要去說「對，他就是一個這樣慢的東西」。當一堆文章都在寫說mongrel或是lighttpd cluster有多快，我心裡總是想著apache+mod_fcgid(你知道我在說哪一個blog...XD)，我們的目標是做上萬人使用的系統，總不能真的去跑mongrel吧？那跟跑webrick有啥不同？

我是這樣想的，當然參考是相當必要的。

http://blog.kovyrin.net/2006/08/28/ruby-performance-results/

在這樣的情況之下，不管如何還是決定採用haproxy。而交叉測試的結果，也證明haproxy比apache稍快，而這樣的結果也是合理的。而進行服務的也還是選擇apache+mod_fcgid。

但是在今天的測試，只是稍微從列出2個人，改成列出20個人，就從200 req/s降到35req/s，實在讓我太訝異！我發現問題不是在ActiveRecord連DB要時間，而是render的時間爆衝，之前就聽說partial很吃效能，早就不敢多用，乖乖寫在迴圈裡。但實際上跑完profiler後，我想是沒錯的...

Requests per second: 12.98 [#/sec] (mean)

其實根本整體就很慢，連跑個array.each_index都小吃效能。最後將這個function改回array.each，以ab -t 30 -c 100 跑在intel雙核2.8G，2G RAM，就是這個結果了。與以往在爛p4上測沒啥太大不同。此外也學到一個經驗是ab不要連續跑太多次，apache需要有些時間做GC，那時會很慢。

而將-c 降到10之後，約是可以接受的回應速度：

Percentage of the requests served within a certain time (ms)
50% 634
66% 776
75% 979
80% 1048
90% 1330
95% 1570
98% 1939
99% 2090
100% 3420 (longest request)

如此表示，這樣一台兩萬塊的機器機器只能夠略估服務1000人而已，說起來像黑米這樣就拿來直接做正式服務的勇者們還真是厲害啊...

因為做了cluster，session一定要放在遠端機器，我就開始測試關掉ActiveRecordStore的數值：

Requests per second: 12.60 [#/sec] (mean)

看來也沒比較好@@

在FC6上安裝Ruby on Rails + FastCGI + Apache + mod_fcgid

2007-08-06T02:44:00.000-07:00

參考文章：
http://wiki.rubyonrails.com/rails/pages/Rails+on+CentOS+4.4+with+Apache+and+FastCGI+Simply/versions/13

1. 安裝apache module
[bash]
yum install mod_fcgid
[/bash]

2. 安裝fastcgi
因為ruby-fastcgi建置的時候需要fastcgi的header所以得安裝
下載：
http://www.fastcgi.com/dist/fcgi-2.4.0.tar.gz

[bash]
tar zxf fcgi-2.4.0.tar.gz
cd fcgi-2.4.0
./configure
make all install
[/bash]

3. 安裝ruby-fastcgi
[bash]
gem i fcgi -- --with-fcgi-dir=/usr/local
[/bash]

4. 修改SELinux設定
你可以使用xwindow，或是編輯/etc/sysconfig/selinux，請將SELINUX設定為disabled後重新開機。

5. 編輯/etc/httpd/conf.d/fcgid.conf
加入這幾行
[bash]
SocketPath /tmp/fcgidsock
SharememPath /tmp/fcgidshm
DefaultInitEnv RAILS_ENV production
[/bash]

SocketPath和SharememPath都相當的重要，因為fcgid的問題，所以只能設定為/tmp下，其他目錄都會有問題。

6. 新增專案設定檔

假設你的Rails專案叫做myproject，檔案都在/opt/myproject，就在/etc/httpd/conf.d/新增一個myproject.conf
接著你要考量兩種情況，如果你的專案打算放在URL的根路徑，如http://www.mysite.com，那就一定要用VirtualHost。
但如果你的網頁要放在其他子路徑，如http://www.mysite.com/myproject，使用Alias就可以了。
一般來說如果是想要放在根路徑的檔案是不能夠使用Alias的(例如Alias / /some/dir...)，會造成apache出現recursion error。

使用VirtualHost

<VirtualHost *:80>
SetEnv RAILS_ENV production
DocumentRoot /opt/myproject/public/
ErrorLog /opt/myproject/log/apache.log
<Directory /opt/myproject/public>
Options ExecCGI FollowSymLinks
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>
使用Alias
<VirtualHost *:80>
Alias /myproject /opt/myproject/public
SetEnv RAILS_ENV production
ErrorLog /opt/myproject/log/apache.log
<Directory /opt/myproject/public>
Options ExecCGI FollowSymLinks
Order allow,deny
Allow from all
AllowOverride All
</Directory>
</VirtualHost>
7. 編輯/opt/myproject/public/.htaccess
一樣是兩種情況，如果你的專案是在根路徑，那就啥都不用改。
如果不是的話，要加上RewriteBase /myproject
此外也應該要改
AddHandler fcgid-script .fcgi
RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]
8. 編輯/opt/myproject/public/dispatch.fcgi
注意這一個script的preprocessor，也就是第一行，一個要是一個可以執行的ruby直譯器路徑，如#!/usr/bin/ruby
檢查好了之後，下指令
[bash]
chmod 755 /opt/myproject/public/dispatch.fcgi
chmod -R 777 /opt/myproject/log
chmod -R 777 /opt/myproject/tmp
[/bash]

接著可以執行看看dispatch.fcgi，如果會在log/產生一個fasfcgi.crash.log，表示應該沒有啥太大問題，重新啟動apache後就可以輸入URL試試看了。

PicasaWeb的Flash相簿

2007-08-01T03:57:00.000-07:00

雖然說用Google查一下關鍵字就可以知道，PicasaWeb基本上是英文版才給Flash連接，但這不管怎樣還是Flash的Photo Atom Feed Reader。
所以在你想要的任何網頁貼上這些HTML

<embed src="http://picasaweb.google.com/s/c/bin/slideshow.swf" type="application/x-shockwave-flash" flashvars="host=picasaweb.google.com&RGB=0x000000&feed=http%3A%2F%2Fpicasaweb.google.com%2Fdata%2Ffeed%2Fapi%2Fuser%2Fkiwi0530%3Fkind%3Dphoto%26alt%3Drss" pluginspage="http://www.macromedia.com/go/getflashplayer" height="135" width="180"></embed>

結果就是：
參考這兩篇文章
http://blog.blueshop.com.tw/ajun/archive/2007/03/28/50293.aspx
http://roxytom.bluecircus.net/archives/009894.html如果你要顯示你所有相簿的所有圖片，只需要將feed=後面的數值改成
http%3A%2F%2Fpicasaweb.google.com%2Fdata%2Ffeed%2Fapi%2Fuser%2F{使用者帳號}%3Fkind%3Dphoto%26alt%3Drss

介紹Ruby on Rails

2007-07-16T03:51:00.000-07:00

本篇文章從PHP及Web程式設計師的角度，逐漸帶出Ruby on Rails這個Web Application Framework及其優點，架構觀念。接下來要簡介Ruby及Rails的學習重點。

Web應用程式

記得在上次的的主題，重新探討Cakephp, Ruby on Rails與MVC，我大力地闡述能否實做商業邏輯，或是掌握Model的功用是多麼的重要。而老話一句，這個問題比較會出現在中大型的Web應用程式中，如果說你正在寫的是小小的網頁作業，或許本文對你只有參考的價值。

我會這樣說，是因為我們已經邁向2008年，Web應用程式在Google大神的帶領之下，逐漸開始在放出光芒。

在2005年以前，對於很多使用者而言，瀏覽器只不過是個看網頁的東西。而網頁對大多數設計者而言，製作網頁就像在畫一幅畫。動態網頁設計被分做四大領域，平面設計，結構設計，行為設計，伺服端程式設計，而這些設計可能會各別使用典型的Photoshop(or Flash)，HTML/CSS Editor，Javascript Editor，PHP來完成。然而我舉PHP的例子，大家也應該可以想像的到，它是這五六年間最熱門的伺服端程式語言，如phpbb， phpmyadmin，xoops等高水準，開放原碼的應用程式大家早就耳熟能詳。相較於當時任何可以做出成品的伺服端語言，其直譯式語言的優點，快速編輯，方便佈局(deploy) ...說到要寫動態網頁，PHP真是首選！

而這些東西在2006年之後就起了大變化，主要還是因為使用者比以往需要更多從瀏覽器得到的資訊，不僅只是看個靜態的網頁，更是將資料傳送出去。當人們開始這樣用Web表單不斷地把資料往Internet送，並期待畫面下一瞬間就有符合需求的東西的時候，已經不是在「看網頁」，而是在使用Web應用程式。是的，Web應用程式這個名詞其實還並未真正的深植人心，因為非資訊領域的使用者他們對於Web的認知還是僅僅在於靜態網頁，而資訊領域相關的已經對Web有種使用視窗程式的印象。實際上不管是Google也好，博客來也好，大家都是在用Web應用程式。

從設計者的角度來看，大概在PHP成為主流的時候，重心已經從平面設計逐漸轉移到伺服端程式設計。舉個例來說，你會發現外包網頁製作工作室來製作官方網頁的業者，在快要完工時，針對內容資料性及操作性正確與否的要求，遠比Flash動畫順暢度及效果還要來得優先(以往是剛好反過來，美工優先)。就像你使用Word，先不管他的介面是否如Word 2007般炫麗，可是在程式上看到的的排版，跟列印出來紙張上的排版一定不能不一樣。由於PHP連結資料庫的功能相當穩定，解決了資料及操作性的問題後，設計師們慢慢地就將焦點拉回到Web應用程式的反應速度上。包括平面設計師在內，許多人無一不想讓Web程式像是視窗程式一樣反應快速，也因此將大家遺忘許久的Javascript找了回來。

PHP面對的問題

從2000年到現在，設計的重心大概是依照HTML -> PHP -> JS來演進，語言的特性也從Tag Language -> Script -> Pure OO Script演進。這樣子的演進，不僅說明了伺服端程式碼的彈性相當重要，因為你可以看見大家不再需要靜態的HTML而是可以產生動態HTML的PHP，而更明顯的是，大家開始需要瀏覽器的彈性。

在這時代演進中，PHP程式設計師遇到許多問題像是：

PHP並不是一個很好的物件導向語言，直到PHP5的時候雖然有，不過也不夠完整。

PHP原本附的資料層函式及PDO，或者是Adodb，要進行複雜的關連設計與對應相當困難。能夠做到複雜關連的如Propel，卻又效能太差。

樣版引擎的優點是快速，可是只能稍微簡化畫面的結構問題，並未能解決商業邏輯與控制程式碼混雜問題。

綜合以上原因，如果你要撰寫一個有500個使用案例的大系統，會導致設計複雜化。

Framework如Cakephp解決了不少上述問題，可是因為多數Framework開發週期過長而使得普及率未如想像中高。

Web應用程式因為HTML，CSS等本來就需要打許多程式碼，但PHP也佔了相當多。因此要完成大系統，需要更多人力進行實際程式碼撰寫而無法將時間花在設計上，開發時程也相對拖長。

我們在面對的已經是上百個使用案例這樣的複雜Web應用程式，競爭對手如Adobe已經推出了AIR(前Apollo)，微軟也推出了ASP.Net Ajax與Silverlight。這些強勢的對手們，目標當然是更強的Web Framework。PHP的任何framework甚至函式庫，是否能有效地"Rapid Development"都是一個問題，更何況是要挑戰這些對手。

Ruby on Rails

Ruby on Rails這個Web Application Framework早在2004年7月的時候，就由David Heinemeier Hansson率領著37signals打造了一個專案管理系統叫做Basecamp。先不管Basecamp好不好用，而它帶來的影響力就是大家都會問說「這究竟是怎樣寫的？」，也跟著Web2.0的風潮風光了一陣子，之後Rails才逐漸浮上抬面。一個軟體要有人用，在於設計符合使用者需求，而又讓他們感到習慣的介面。但如果今天所謂的使用者也就是寫程式的人，那他們的希望就是，要能夠有效率地做出或者維護一個系統及其使用案例，有方便的API可以降低反覆打同一行程式碼的動作。

Rails的第一個最大的優點就是，他可以以同一個語言加上簡短的函式呼叫囊括結構(HTML)，行為(Javascript)，及伺服器程式語言(Ruby)設計。

我自己都認為光這一點對很多人來說就是救星了。

至於第二大優點，那就多了～

對於一個有經驗的Web程式設計師而言 Rails具有下列優點：

簡短的函式呼叫，拯救你快殘廢的手指

MVC的設計架構讓你的資料及商業邏輯，控制程式碼，畫面完全分開，"No More Spaghetti Code!"

ActiveRecord讓你不需要撰寫SQL，並使用Object-Relational Mapping(物件-關連資料庫映射)，與Hibernate同等級的關連功能存取資料庫

ActionController讓你有完全控制HTTP Session, Cookie, Request, Response的能力，整合了REST改變以往你對資源控制的想法，幾個基本的method就讓你寫完CRUD(新增修改刪除)。

ActionView讓你可以使用簡單的函式呼叫就產生複雜的HTML表單與Ajax Javascript程式碼。

專業的Web設計師都懂得要先思考整個網站的Layout在去建構各個畫面，使用Layout更能發揮你的專業。

Rails不見得只是讓你Quick'n Dirty弄出個雛形，而且你絕對可以依賴Rails團隊的軟體品質而開發出更棒的產品。不怕你將Rails的功能挖完，只怕你還沒挖完Rails又出新功能！

對於一個Web程式設計新手，Rails帶給你的是：

採用Ruby這個純物件導向直譯式語言，怎樣寫都可以work的程式風格會讓你快速就上手。

Rails在各種平台都有快速開發套件包，Windows是InstantRails，Fedora6上打yum install rubygems即可。隨後在指令模式打上一行 gem install rubyworks -a，啥都幫你裝好。

Aptana IDE(前RadRails)採用Eclipse開發而成，能控制Mongrel伺服器，也能除錯程式碼，將HTML,CSS,JS,Rails整合的相當好。

不會連MySQL，PostgreSQL？沒關係，把帳號密碼等資訊打在database.yml裡，還可以利用除錯Console測試連線。

Rails可以使用Scaffold(鷹架)建立基本的CRUD，甚至還支援漂亮的Ajax，彈指之間你發現你已經寫完了，而還不敢相信自己寫完了。

既然畫面做完了，開始想怎樣修改既有的東西，利用Aptana下方工具列的Generators，你可以產生Model, Controller...等各種Rails程式碼框架，不用一一宣告半天。

嫌功能不夠多嗎？察看Aptana下方工具列的Rails Plugin，看看你想加啥功能！

低坡度的學習曲線讓你相當有成就感，不會像老前輩們以前天天踢鐵板踢到腳酸～

我相信Rails團隊是本持著對設計師們體諒的心，加上未來的夢想在設計整個framework，而不是在展現編程的實力堅強，這也是以往各種函式庫做不出來的，相當值得所有設計師們學習。在撰寫這篇文章的時候，我也想過是否該提提Python及Django，因為他們也做的很好。

Ruby on Rails新手指南

Ruby

要使用Rails，非得學習Ruby不可。Ruby是一個純物件導向的語言，意思是說在裡面任何東西，一個字串，一個數字都是一個物件。相較於其他script語言，ruby提供較多的與該物件相關且符合英文意義的成員函式，我們用ruby附的指令介面irb(interactive ruby)展示一下：

[ruby]
-1.class
# output Fixnum
-1.abs
# output 1
1.succ
# output 2
1.succ.succ
# output 3
[/ruby]

可以看到1.succ會回傳1的successor(下一個數字)也就是2，而2的類別當然是Fixnum，也就是可以繼續呼叫succ，也因此有1.succ.succ這種呼叫法。類似的作法在所有支援物件導向的語言都可見。而ruby不同的地方是他允許不加上"( )"便可以進行呼叫，只不過是沒有傳參數進去，也就是像VB一樣。設計師可以盡量用一行就可以描述一串程式動作，加上所有類別都提供相當實用的成員函式，便產生非常簡潔的程式碼。

[ruby]
say = "I love Ruby"
puts say
# Output "I love Ruby"
# 字串提供"[ ]"成員函式來取得子字串，而下一行的功能就形同於取代
say['love'] = "*love*"
puts say.upcase
# Output "I *LOVE* RUBY"

# 下行程式碼展示了Fixnum的成員函式times，而傳入一個"{ } "，稱作為區塊(物件)，如此這個區塊內的程式碼會被執行五次。
5.times { puts say }
# Output "I *love* Ruby"
# five times

[/ruby]

剛剛有提到，ruby是一個純OO的語言，在程式裡任何東西皆為物件，自然就有物件該有的特性。

如果你想要試試語法，可以使用irb，ruby附的編輯器scite，或者是http://tryruby.hobix.com/。初學者最常見到就是不知道該呼叫啥成員函式，你可以透過http://www.gotapi.com/rubyrails去查，或者是任何物件都有一個methods函式可以呼叫，至少你可以掌握你有什麼。

而目前針對ruby語言個人認為比較值得看的參考，就是下列網址：

http://www.zenspider.com/Languages/Ruby/QuickRef.html

http://www.ruby-doc.org/docs/ProgrammingRuby/

http://willh.org/cfc/wiki/index.php/Programming_Ruby,_1st_Edtion

如果你是熟悉Perl的老手，那Ruby對你而言是再快樂不過的事情了。.Net或是Java的也沒關係，花些時間深度地思考什麼叫做純物件導向，或者去看看Smalltalk，便能從語言面就瞭解Ruby。

Rails

因為Rails終究是一個MVC Framework，深讀MVC的內容是相當重要的，一個不小心你的程式碼就會有許多誤用，造成未來維護困難或效能緩慢。說起來就算是老手，一旦遇上趕專案的狀況，為了要快點寫完，很多時候也難逃誤用的命運。

但是在這裡我不詳述Rails的MVC究竟該怎樣去理解或開發，那是下一篇文章，先推薦Agile Web Development with Rails及Ruby on Rails:Up and running這兩本書好了。第一本書深入淺出，從觀念，目錄結構到撰寫流程解釋地相當詳盡，對於不是寫Rails的人來說，從中學習MVC也是相當棒的，可惜還沒有中文翻譯。第二本書以實做的角度直接切入程式碼，並且有中文翻譯，對於新手可以說是相當適合。

有關Rails的連結，最推薦的是：

http://wiki.rubyonrails.org/rails

http://lightyror.thegiive.net/

不過既然是介紹，免不了還是要說明一下目錄結構。

Rails的目錄結構如上圖，基本上大部分的程式碼都在apps/，也就是代表你的應用程式本身，在此我們僅介紹撰寫過程中一定會碰到的目錄。

所有的Controller類別基本上都繼承自application.rb，程式碼就擺在controllers/，讓你可以在其中寫所有Controller共用的成員函式。Helper就是載入到view裡讓view可以呼叫的成員函式，所以application_helper.rb也是同樣的情況。models/相當單純不用多解釋，而views/除了必須新增和controller同名小寫的目錄來擺rhtml以外，也可以使用所謂的Layout功能。Layout就是讓所有的view可以選擇性地套入一個主樣版，通常我們在畫面設計上都會做成網站的外框。

在Rails專案產生完畢後，最先就是要編輯database.yml來設定好資料庫系統的存取方式。值得注意的是Rails預設提供三種應用程式運作使用的環境設定，有development,test,production，分別代表開發時，進行單元測試時，及正式上線時。這三個設定檔理論上應該分別設定在不同的資料庫，而啟動到底是使用了哪一個設定檔，就是看傳遞給web server怎樣的參數。此外如果有要預先require的函式庫或是include的module，都可以放在environment.rb裡。route.rb負責上述URL的結構，也就是說那個結構是可以改的。

一個Web應用程式一定有靜態資料，包括圖片，css與js，分別擺在public/的images/，stylesheets/，javascripts/，並且在view裡可以透過image_tag, include_javascript_tag, stylesheet_link_tag來呼叫。Rails提供了DB Migration功能，讓你可以輕鬆地撰寫資料庫schema，並且可以視database.yml轉移到不同的資料庫，利用產生器的話，會自動產生在db/。

結論

未來Rails的發展方向，不僅會在REST這個主題，使用JRuby來整合Java，甚至是Offline應用程式都有相當大的可能性。以往我發現，任何視窗上的應用程式，免不了就是一定要遇到作業系統本身帶來的問題，如同Windows，可能他一更新，就封鎖掉你的應用程式。Web是一個開放的平台，提供很多的創意空間，也不見得要用同一種技術解決問題，有多種瀏覽器可以選擇，不會被侷限在一個平台上。

文章到最後，當然還是得跟各位提一下Rails的缺點，畢竟是以純物件導向撰寫的Web應用程式，所需要的代價就是大量的CPU記憶體資源。也因為這一點，有很多Rails的開發者也積極地加入叢集化的支援。但畢竟電腦硬體只會越快不會越慢，Web未來的趨勢還是會以敏捷編程(Agile Programming)的方式來快速開發及佔有市場。

參考連結

http://blog.roodo.com/rocksaying/archives/2680742.html

http://www.lis186.com/?p=1750

http://tw.myblog.yahoo.com/jimwayne-blog/article?mid=28&prev=29&next=27

http://inet6.blogspot.com/2006/12/ruby-on-rails.html

http://www.ibm.com/developerworks/cn/java/j-cb08016/

http://www.ibm.com/developerworks/cn/linux/sdk/php/php_design/index.html

升級至Wordpress 2.2.1

2007-07-06T11:29:00.000-07:00

這一次的升級有點不太一樣，是純手動升級
新裝了另一個wp之後將舊的資料匯出，然後匯出匯入，圖片，主題，plugin一個一個轉移

之所以會這樣，只是因為我的發現我的編輯介面一直沒有visual editor，而別人的確有
看樣子升級還是沒有新裝的乾淨！

PostgreSQL MySQL Firebird 效能比較

2007-06-27T04:10:00.000-07:00

http://postgresql-chinese.blogspot.com/2007/06/postgresqlmysqlfirebird.html

我覺得大家看到這一篇就可以不用再爭了，這已經解釋地相當清楚
以往我經常遭到到底該使用哪個資料庫的挑戰，很可惜的是到最後MSSQL,Oracle我幾乎都沒有考慮
你應該不會有聽過人用裝Oracle只是來架個Blog吧？

不過比起文章中我還要附加一點
相較於mysql，視窗版的postgresql安裝介面比較不人性化，而且同樣地視窗管理介面比較簡單(剛好滿足基本功能)

firebird在資料庫系統的定位中就相當模糊，他既無法承受大量的連線數，又需要啟動服務程序，否則效能就會大減
還是一句話，總不能架blog用firebird吧？

至於單機應用，那當然是選擇sqlite
最佳的範例就是GoogleGears

[2007/06/08 - 2007/06/15] Hemidemi書籤摘要

2007-06-15T08:30:00.000-07:00

高橋メソッド | Jedi's BLOG | Jedi.org
06/15 15:27, 2007
果真是文字，圖案，精神三位一體了。我認為未來的投影片趨勢會比較像這樣(除了研究所書報討論或是公司被老闆定以外)，很多地方都可以用這種強調法，讓聽眾腦中只有幾個關鍵字便足夠。
(標籤: 設計 ruby powerpoint slide)
Mozilla Taiwan 討論區: [轉貼] 高橋流簡報器
06/15 15:28, 2007
跟上面的一樣，只是這是在moztw的介紹
(標籤: 設計 ruby powerpoint slide 高橋流)

我的更多書籤 @ HEMiDEMi - 黑米共享書籤

免費的RSS新聞閱讀器

2007-06-15T07:34:00.000-07:00

2007年是一個Web與P2P大放異彩的時代，我相信大家有要求及使用更方便更迅速軟體的權力，也因此我強烈建議m-team開啟RSS的功能，讓大家一有新文章就可以趕快來看。

什麼是RSS？參考以下連結

http://zh.wikipedia.org/wiki/RSS
http://www.ytower.com.tw/rss/about_rss.htm
http://www.tuzaiz.idv.tw/archives/13

【檔案名稱】: Firefox
【檔案大小】: 5.8MB
【檔案語系】: 多國語言
【檔案下載】: http://download.mozilla.org/?product=firefox-2.0.0.4&os=win&lang=zh-TW
【檔案簡介】:

這個應該不用再介紹了吧XD～～
最主要就是使用他的即時書籤來讀取RSS。
1.5基本上是使用即時書籤，這個對於剛開始接觸RSS的使用者會比較友善。而2.0是可以選擇要用哪一種軟體訂閱的，如果有安裝great news的話，也會出現在軟體清單裡
。

教學：
http://moztw.org/docs/fx/live-bookmarks/

firefox 1.5
http://udn.com/rss/reader3.html
http://www.nikonclub.cc/nikon/index.php?showtopic=4618

firefox 2.0
http://home.books.com.tw/blog/?p=27#02

【檔案名稱】: IE 7.0
【檔案大小】: 14.1MB
【檔案語系】: 多國語言
【檔案下載】: http://www.microsoft.com/taiwan/windows/ie/downloads/default.mspx
【檔案簡介】:

這個也是同樣不用再介紹的東西
不過很機車的是，我只提供網頁連接不提供下載連結。為啥呢？因為一點過去就會進入正版windows驗證啦～～～～！
這也是為啥我鍾愛開放原碼軟體。

教學：
http://home.books.com.tw/blog/?p=27#01

【檔案名稱】: Great News
【檔案大小】: 1.1MB
【檔案語系】: 多國語言
【檔案下載】: http://greatnews.twftp.org/GreatNewsSetup.exe
【檔案簡介】:

轉貼自
http://www.wretch.cc/blog/Nelson&article_id=2255871

GreatNews
http://www.curiostudio.com/

1. 免費
2. 內建多國語言
3. 免安裝
4. 有簡單擋廣告功能
5. 可線上更新程式
6. IE 為核心
7. 支援多種 RSS 格式 (RSS 0.9x, 1.0(rdf), 2.0, Atom 0.30)
8. 頻道管理做得不錯
9. 整合 Bloglines
10 文章搜尋功能
11 Unicode 支援
12 檢查頻道是否有更新的速度很快，就算你有上百個頻道也是一樣
13 透過 CSS 可更改頁面風格 (內建有 Newspaper, Sage, Essay 等風格)
14 介面看起來就像 E-Mail 程式，例如 Outlook Express.

教學(裡面也有其他RSSReader的介紹)：
http://allen080.blogspot.com/2007/04/7rss-readergreatenews.html

也可參考
http://www.m-team.idv.tw/phpBB2/viewtopic.php?t=2028

【檔案名稱】: Google Reader
【檔案大小】: n/a
【檔案語系】: 英文
【檔案下載】: http://www.google.com.tw/reader/
【檔案簡介】:

這是在這裡僅推薦的一個Web Reader。我知道對於某些使用者，還尚未真正去感受Web應用程式的威力，不過如果對於已經有google帳號的使用者，這是Google相當棒的服務其中之一。清爽的介面，大方的圖形與字體配置，讓閱讀新聞變成是相當簡單的事情。然而比起一般視窗的Reader，還有些稍嫌不足的地方(也因此google就將線上最大的rss整合服務feedburner以一億美金買下了XD)。最近他提供了離線瀏覽的功能，只要你的firefox開著，其實他也跟一般的reader沒兩樣了。

教學：
http://www.chweng.idv.tw/googleguide/reader.php

-----------

其他連結：
http://www.neo.com.tw/archives/000515.html

本篇文章也同時發佈在我的Blog

整理後的文章規劃

2007-06-12T20:22:00.000-07:00

我知道我之前那些文章很多很亂，我也忍很久了，終於在今天好好地整理一下
以下是這些分類的簡介

系列文章
Web2.0程式設計系列：與Web2.0，進階php程式設計相關的文章。而目前正將文章轉向MVC與Ruby on Rails，進階Javascript程式設計。
Unix系統管理系列：我曾經撰寫過的Unix教學都放在這了，有些文章有點舊，不過勉強可以參考。
資料格網系列：所有有關SRB的文章，但未來會包括P2P與DataGrid的應用。

分類文章
Unix：有關系統管理的文章，或許未來會考慮加上Windows管理的文章
Web程式設計：有關php,ruby,postgresql的文章都在此
視窗程式設計：這裡的文章有點舊了，因為我現在不寫這些語言了
技術摘要：從Hemidemi上發佈過來的書籤摘要都會放在這

Unigrid Auto Replication Daemon

2007-06-12T19:37:00.000-07:00

前言

Unigrid計畫在今年決定使用SRB，為了補足SRB本來沒有自動複寫檔案的機制，我寫了這個服務。

由於許多因素，暫時不提供套件下載或是原始碼
版本歷史
20060708
初始版本

20060726
修正
會複寫到兩個以上的resource
db.xml不再使用owner屬性，DBConfig.SetPolicy也只需要srbfilepath和policy
config.xml支援多個zone的連線
更快速地跳過不需要進行複寫的檔案

安裝

[code]
[root@gv6db bin]#tar zxf Replicator-$date.tar.gz -C /opt
//如果你要解到別的目錄也可以
//不過你必須編輯bin/replicator
[root@gv6db bin]#vi bin/replicator
//將BASE變數指定到你解開的目錄
//將JAVA_HOME變數指定到系統安裝java的目錄
//如果你想要測試，你可以設定DRYRUN為"true"
[/code]

以下是設定bin/replicator的範例
[code]
#option BASE (required)
# Set application root directory
# Default: /opt/Replicator
BASE=/opt/Replicator

#option JAVA_HOME (required)
# Set java envirement path
JAVA_HOME=/usr/java/jdk1.5.0_06/

#option DRYRUN
# Set to "true" so replicator will not really replicate files
# Default: "false"
DRYRUN="false"

[/code]

設定檔

啟動

[code]
[root@gv6db bin]# ./replicator start
Starting Replicator: [ 確定 ]
[root@gv6db bin]# ./replicator status
java (pid 1346) 正在執行中...
//你可以將replicator script複製到/etc/init.d
//它完全支援service的執行方式
[root@gv6db bin]# cp replicator /etc/init.d/
[root@gv6db bin]# service replicator restart
Shutting down Replicator: [ 確定 ]
Starting Replicator: [ 確定 ]
//要停止也是
[root@gv6db bin]# service replicator stop
Shutting down Replicator: [ 確定 ]
[/code]

測試

SRB 3.x 安裝測試記錄 (Oracle)

2007-06-12T19:36:00.000-07:00

環境

FC3
Oracle 10gR2
SRB 331

Memo

install Oracle 10g R2:

su root
add to /etc/sysctl.conf:
vi /etc/sysctl.conf

kernel.core_uses_pid = 1
kernel.shmmax = 2147483648
kernel.shmall = 2097152
kernel.sem=250 32000 100 128
net.core.rmem_default = 262144
net.core.rmem_max = 262144
net.core.wmem_default = 262144
net.core.wmem_max = 262144
fs.file-max=65536
net.ipv4.ip_local_port_range=1024 65000

sysctl -p

add oracle user:
groupadd oinstall
groupadd dba
useradd -g dba oracle

install jdk:
rpm -ivh jdk-1_5_0_01-linux-i586.rpm

add to /etc/bashrc and ~oracle/.bashrc:
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=orcl

install:
su oracle
cd $ORACLE_SOURCE
./runInstaller

Follow the wizard.

Create a instance \"MCAT\" using DBCA.

Create a table space \"SRBMCAT\" using Enterprise Manager.

Create a user \"SRB\" using Enterprise Manager.

Grant IMP_FULL_DATABASE to SRB

install SRB,MCAT with Oracle 10g:

add srb user:
groupadd srb
useradd -g srb srb

try sqlplus srb@mcat

if there's any error, consider :
1. $ORACLE_HOME directory and child file permission is 755
2. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$ORACLE_HOME/lib
3. $ORACLE_HOME/lib entry in /etc/ld.so.conf
4. username/password error(try it with other oracle account)

install:
cd $SRB_331_SOURCE
./configure --enable-oraver=10g_32bit --enable-oramcat --enable-orahome=/oracledb/oracle/10g/
--enable-accsctrl --enable-javagui --enable-jdkhome=/usr/java/jdk1.5.0_01
make
cd MCAT
make

configure:
cd $SRB/data
edit hostConfig
edit mcatHost
edit MdasConfig
notice that
we create a user named \"SRB\", MDASSCHEMENAME is \"srb.\"
DB2INSTANCE is same as MDASDBNAME

sqlplus srb/password@mcat @{file}
catalog.install.ora: this will create difinitions using default table space of \"SRB\"
account
catalog.index.ora: this will create other indexes using \"MCAT_IDX\" table space
catalog.trigger.ora: this will create triggers using default table space of \"SRB\"
account
catalog.quota.ora: unknown usage

modify internal \"srb\" account:
bash
export srbUser=srb
export srbAuth=CANDO
export mdasDomainName=sdsc
ingestToken Domain nchc home
ingestUser srbadmin srbadmin nchc sysadmin '' '' ''

using McatAdmin:
Modify zone
Add User
Create Location
Create Physical Storage
Create Logical Storage
service srball restart

Test

[kiwi@srb1 kiwi]$ time Sbload 20041203 ./

real 3m43.509s
user 0m0.450s
sys 0m4.310s
[kiwi@srb1 kiwi]$ ./putmeta 20041203
Making metafile...3825
267701 metas, 3825 metafiles
Running metafile...
17 min 45 sec

差太多了吧...這次meta還多很多喔...

SRB 3.x 安裝測試記錄 (PGCluster)

2007-06-12T19:30:00.000-07:00

環境

SRB-3.2.tar.gz
pgcluster-1.0.9.tar.gz(postgresql 7.3.9)

pgcluster

重建postgres帳號known_hosts檔案
不能夠開啟thread-safety！在FC3上會失敗！
mcat1
./configure --prefix=/opt/pgsql
make all install
更改etc/pglb.conf
更改etc/pgreplicate.conf

mcat2,mcat
./configure --with-nls --prefix=/opt/pgsql
initdb
同步檔案 cluster.conf,pg_hba.conf,postgres.conf

啟動順序(這個順序是必要的！)
mcat2 pgsql
pgreplicate
mcat pgsql
pglb

mcat1
psql template1 < odbc.sql //這一步我沒有做好像也沒問題
createdb postgres
createdb srb
createuser srb

srb mcat

mcat1
copy iodbc.h,isqlect.h,isql.h
./configure --enable-psgmcat --enable-psghome=/opt/pgsql --enable-javagui --enable-jdkhome=$JAVA_HOME
make
chown
su srb
測試isql PostgreSQL
修改MdasConfig
修正srb.conf
psql srb < install.catalog.psg //確認兩個db同時有資料寫入
csh
./test.catalog
ingest domain and user
service srb start

srb1,srb2,srb3,srb4
./configure --enable-javagui --enable-jdkhome=$JAVA_HOME
make
chown
su srb
修改mcatConfig
修正srb.conf
service srb start

環境

重建SRB
關閉所有mcat的hyperthreading，使用單CPU kernel
更新成pgcluster 1.0.9a
srb 3.3.1 on port 5544

測試

[kiwi@mcat1 ~]$ du -sh 20041204
279M 20041204
[kiwi@mcat1 ~]$ ls -R 20041204 |wc -l
39552
[kiwi@mcat1 ~]$ time Sbload 20041204 test2
connectPort() -- Connection Error from server: status=-1113
connectSvr: connectPort error. status =-1113

real 10m21.238s
user 0m0.557s
sys 0m6.102s

嗯...有奇怪的錯誤訊息，但不影響

[kiwi@mcat1 ~]$ time ./runmeta
connectPort() -- Connection Error from server: status=-1113
connectSvr: connectPort error. status =-1113
Connection to srbMaster failed.
CLI_ERR_BROKEN_PIPE: broken pipe to server

real 69m11.637s
user 0m5.223s
sys 0m9.099s

File=279MB, 39552筆Meta需要69分鐘
最後的結論還是什麼都不要做...
可能這就是極限了

SRB 3.x 安裝指南 (Oracle)

2007-06-12T19:29:00.000-07:00

前言

在2005年中的時候，我發現了MCAT使用Oracle作為DBMS的效能是相當好的。大概看了10.2的功能，管理介面上有很大的改善，Oracle更是自誇說沒有資料庫可以勝過他們。後來實際搭配SRB的效能測試，其實也真的不錯，讓SRB成為一個可以上線的系統，而非在PostgreSQL下有很不穩定的表現。

對於初學者來說要去熟讀Oracle的書籍比較好，或者你可以參考這篇文章，而SRB的操作及簡介可以參考PostgreSQL那一篇。

安裝Oracle

如果要在Fedora3上面安裝的話，也必須有官方的patch，這些都是你要有Oracle版權才能取得的。
我先假設你已經安裝好了Redhat Enterprise 3 (Update幾都皆可) 。
檢查檔案
以下是必須安裝並版本正確的RPM套件
make-3.79.1
gcc-3.2.3-34
glibc-2.3.2-95.20
compat-db-4.0.14-5
compat-gcc-7.3-2.96.128
compat-gcc-c++-7.3-2.96.128
compat-libstdc++-7.3-2.96.128
compat-libstdc++-devel-7.3-2.96.128
openmotif21-2.1.30-8
setarch-1.3-1
libaio-0.3.96-5
tcl-8.3.5-92.2

以下是必須安裝的RPM套件
binutils

加入至sysctl.conf
kernel.shmmax=2147483648
kernel.sem=250 32000 100 128
net.core.rmem_default=262144
net.core.rmem_max=262144
net.core.wmem_default=262144
net.core.wmem_max=262144
fs.file-max=65536
net.ipv4.ip_local_port_range=1024 65000

執行sysctl -p
新增使用者
groupadd dba # group of users to be granted SYSDBA system privilege
groupadd oinstall # group owner of Oracle files
useradd -c "Oracle software owner" -g oinstall -G dba oracle
passwd oracle

新增目錄
(仔細規劃好你的Oracle安裝目錄)
mkdir -p /u01/app/oracle
chown oracle.oinstall /u01/app/oracle

export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=orcl

在光碟下執行./runinstaller
照著精靈安裝，若是有檢查無法通過的就除錯

設定Oracle

基本上現在已經裝好了，所以如果要使用Oracle的帳號必須設定環境變數至.bashrc
ORACLE_HOME=$ORACLE_BASE/oracle/product/10.2.0/db_1
PATH=$PATH:$ORACLE_HOME/bin
使用dbca建立新資料庫
SID為srb，DBName最好也是和SID一樣，不需要照他說的加上domain
建立好資料庫，他會給你一個網址如http://localhost:5000/em
這個是這個資料庫專屬的網頁管理介面。

接下來你可以使用網頁管理介面來做這些工作。簡單地來說，Oracle將表格儲存在表格空間裡，而一個資料庫使用者便可以在預設表格空間裡建立表格，而資料庫使用者也可稱做Schema。

如果你在Oracle系統帳號已經設定好路徑變數，你就可以輸入

[code lang="php"]
sqlplus user@srb
[/code]

他會提示你輸入密碼。這裡的user指的是帳號名稱，你應該先使用剛剛建立資料庫時所說的system帳號登入。

建立表格空間
[code lang="php"]
sql> create tablespace srbmcat datafile
'$ORACLE_BASE/oradata/mcatdb/mactdb_srbmcat01.dbf'
size 198M autoextend on NEXT 10240K MAXSIZE UNLIMITED
extent management local online;
[/code]

如此我們會建立一個表格空間叫做srbmcat，注意到檔案的路徑，你最好以$ORACLE_BASE/oradata/$sid/$sid_$tablespace這樣的格式來當作這檔案的路徑。建立MCAT資料庫使用者
[code lang="php"]
sql> create user MCAT identified by $mcat_passwd default tablespace srbmcat temporary tablespace temp;
sql> alter user MCAT quota unlimited on srbmcat; sql> grant connect to MCAT;
sql> exit;
[/code]
注意到其中的$mcat_passwd你應該換成自己要的密碼。

你可以先建幾個表格來試試看是否真的能存取。

建置MCAT

這邊的動作請參考PostgreSQL那一篇，我只描述不同的部分。

./configure --enable-oramcat --enable-oraver=10g_32bit --enable-orahome=$ORACLE_HOME --enable-accsctrl --enable-javagui --enable-jdkhome=/usr/java/jdk1.5.0_06/

讀入sql指令檔
sqlplus mcat@srb @catalog.install.ora

編輯data/MdasConfig
注意資料庫使用者若為MCAT
Schema就是MCAT.
此外MDASDBNAME和DB2INSTANCE都是SID

MdasConfig如果最後面有空白或多餘的行的話，可能導致錯誤，記得將他刪除。

SRB 3.x 安裝指南 (PostgreSQL)

2007-06-12T19:28:00.000-07:00

SRB套件：

SRB3.2e.tar

srb3.2.1patch.tar

DBMS套件：

postgresql-7.4.2.tar.gz

unixODBC-2.2.10.tar.gz

psqlodbc-7.2.5.tar.gz

主機：

Redhat Linux(Redhat 8, Redhat 9, Redhat AS 3皆測試過)

測試帳號：

srb.nchc.org.tw:5544 / mcat.nchc.org.tw:5544

srbtest

srbtest

Client Application：

InQ下載頁面

目錄：

前言

準備工作

SRB without MCAT

PostgreSQL and unixODBC Quick Installation Guide

SRB with MCAT

Test

前言

在安裝的過程中，實在歷經千辛萬苦

雖然到了第3版，官方文件卻還是沒有跟著官方測試人員在新版本上的結果而更新，文件的配置潦草隨意

有相當多的堪誤

除了Scommand的設計還算不錯，ClientApp很漂亮也很好用

但Server有些設定及關鍵字的意義難以令人理解，與字面有些與差別

無論如何，我們還是感謝SRB開發人員實現這個想法

但如果是OpenSource，會讓這個想法實現的更完美吧！

可能大部分人都用安裝Oracle解決

Oracle好裝好用，但畢竟不是OpenSource

但是在這裡我用的是PostgreSQL，因為PostgreSQL對於ODBC的支援在幾版前便已經拆開

由非官方的團隊撰寫

ODBC的公用驅動一開始是選擇IODBC，不過似乎對於新版PostgreSQL的相容還是有些許問題

unixODBC有許多好用的設定工具，相容性也完全正常

不過裡面附的PostgreSQL驅動程式，我並沒有使用

MySQL也可能因為Library的關係出現Bus Error，官方沒有任何說明文件

便不在討論範圍內了

準備工作

修正檔

解開兩個.tar檔

基本上從官方下載會經過pgp加密，請依官方指定的解密方式解密

再來依照srb3.2.1patch下的readme複製檔案
root$> tar xf SRB3.2e.tar
root$> tar xf srb3.2.1patch.tar
root$> cd srb3.2.1patch
root$> cp srbObjFunct.c ../SRB3_2/src/back/
...
...
完成之後，或許你可以將他tar起來，因為應該不會只裝一台的

建置Java Client的先前步驟

如果你要使用他的Java Client App，必須做這些動作

你可以到sun官方站去下載Java 2 SDK的RPM來安裝

http://java.sun.com

此外還需要Apache-Ant，這是一個Java的make工具

http://ant.apache.org/

請參考官方文件安裝，如果是下載binary的話就簡單的多，只要解開即可

環境變數

$JAVAHOME=你安裝java的路徑

$ANTHOME=你安裝apache-ant的路徑

$CLASSLIB=$JAVAHOME\lib:$JAVAHOME\jre\lib:$ANTHOME\lib

$PATH=$PATH:$JAVAHOME\bin:$JAVAHOME\jre\bin:$ANTHOME\bin

請務必加到環境變數設定檔去

Shell的問題

SRB有一小部分的script是用c shell寫的

經過測試，MCAT的ingest系列程式也是只抓c shell的變數

當下必須完全使用c shell操作

然而一般Linux使用者預設會使用bash

你必須安裝一個可用的c shell如tcsh

SRB without MCAT

安裝的建議

由於SRB本身是一個Server，許多小程式，API的集合

以及這些程式的配置(Layout)方式

並不建議執行make install來安裝至指定目錄

多人共用的話，可以將整個SRB資料夾擺在/usr/local/下，將Owner改成srb，再設定$PATH

或是擺在srb這個帳號的家目錄，再設定srb自己的$PATH

由於基本上是多人共用，我們採用上面方式

Configure參數說明

--enable-installdir=<path> 安裝路徑(預設： /usr/local/srb)

--enable-javagui 如果你選擇這個，你會需要java2 sdk及apache-ant

--enable-jdkhome=<path> 如果選擇上述參數，你需要指定這個參數至正確的路徑

--enable-gsi-auth 開啟globus GSI認證方式

--enable-globus-location=<path> 如果選擇上述參數，你需要指定這個參數至正確的路徑

--enable-secure-comm 和globus進行安全連線

--enable-openssl-location=<path> 如果要進行安全連線，卻不想使用globus內附的openssl，就指定其他路徑

--enable-project=<name> 如果你要在同一個主機上執行多個SRB，需要指定

Configure & Make

官方說要gmake那是在少數平台上才可能會有的問題，現在大多數的make都是gmake

如果你在Solaris或是其他大型主機的unix上操作請要注意

configure的時候，會自動地寫入mk/mk.common, mk/mk.config，使用者不需更改
root$> mv SRB3_2 /usr/local/SRB
root$> cd /usr/local/SRB
root$> ./configure --enable-javagui --enable-jdkhome=$JAVA_HOME
root$> make
root$> adduser srb
root$> chown -R srb:srb ./
環境變數

以下的路徑要加入至$PATH

/usr/local/SRB/bin
/usr/local/SRB/java/bin
/usr/local/SRB/utilities/bin
/usr/local/SRB/utilities/admin-bin

如果你要的話，可以將下列加入至$MANPATH

/usr/local/SRB/utilities/man

SRB套件附了什麼工具？

admin/

這是一個srb的監控工具

bin/

srbMaster，SRB的服務程式

/bin/commands

給runsrb及killsrb使用的script

data/

SRB主要設定檔的目錄，MCAT/data有部分檔案會做連結

jargon/

Java API

java/

Java Client，即為srbBrowser

matrix/

使用SRB的一個應用

NT/

Windows版的用戶端文字介面程式

readme.dir/

所有主要的說明都放在這裡

tape/

SRB的磁帶管理介面，可以將磁帶也納入MCAT管理

test/

測試程式及範例

unixIO/

libsrbUio.so,srbUio.h，提供的C API

utilities/

Scommand文件介面工具

安全機制

MDAS
(
Massive Data Analysis System ) 為SRB主要的存取控制，排程，中介資料(metadata)控制的子系統

每個SRB服務器需要連接到一個MCAT服務器

進入SRB Source的data目錄

編輯mcatHost 檔案

第一行是mcat主機位置

第二行是加密方式，一般使用ENCRYPT1即可

第三行目前沒有太大影響，不作任何編輯

你可以在SRB Source下的utilities/envFiles目錄找到兩個隱藏檔

.MdasAuth

.MdasEnv

建立~srb/.srb目錄，並且將這兩個檔案複製到其中

編輯這兩個檔案

一個前提是，這裡所使用到的帳號密碼

全部是在mcat中有註冊的帳號密碼，跟主機本身的帳號密碼沒有關連

在.MdasAuth檔案中填入密碼

而.MdasEnv中

在所有欄位填入相對應的值

如果你不是MCAT的管理者，你應該會被主動告知這些資訊

啟動

切換成srb帳號

務必進入bin目錄才能啟動

以下列出一般啟動及停止的情況
srb$> ./runsrb

rm: cannot lstat `./../data/lockDir/.[a-z]*': No such file or directory
rm: cannot remove `./../data/lockDir/CVS': Is a directory
findServerExec: found "/usr/local/SRB/bin/./srbServer" using argv[0]
logFile: ../data/srbLog opened successfully.
initHostWithMCat: mcatHost not defined for zone demozone
LocalHostName: nasyp2, localhost, nasyp2.nchc.org.tw, 127.0.0.1, Port Num: 5544.
Local storage vault conf:
storSysType: 0, vaultPath: /srbVault
NOTICE:Oct 17 15:37:25: srbMaster version SRB-3.2.0&F is up.
initHostWithMCat: mcatHost not defined for zone demozone
findServerExec: found "/usr/local/SRB/bin/./srbServer" using argv[0]
srb 6671 1 0 15:37 ? 00:00:00 ./srbMaster-3.2.0 -d 1 -S
srb 6679 6667 0 15:37 pts/3 00:00:00 grep srbMaster

srb$> ./killsrb

040 S srb 6671 1 0 75 0 - 2890 schedu 15:37 ? 00:00:00 ./srbMaster-3.2.0 -d 1 -S
000 S srb 6674 6671 0 76 0 - 3173 pipe_w 15:37 ? 00:00:00 /usr/local/SRB/bin/./srbServer -Q -p7 -P8
Will kill srbServers with pid = 6674
Will kill srbMaster with pid = 6671
Enter y to do so:
y
kill 1: 6674
kill 2: 6674
kill 1: 6671
kill 2: 6671
kill 6671: No such proces

PostgreSQL and unixODBC Quick Installation Guide

介紹

PostgreSQL是一個以物件導向為基礎的關連式資料庫，以下列出幾個好用的資源

PostgreSQL 7.4 文件

PostgreSQL台灣資訊網

幾乎很多大學的FTP都有PostgreSQL的Mirror

ftp://ftp.isu.edu.tw/pub/Unix/Database/PostgreSQL/

在本文件撰寫的時候，最新版本是7.4.5

你可以在ftp://ftp.isu.edu.tw/pub/Unix/Database/PostgreSQL/odbc/versions/src/

找到最新的ODBC驅動

unixODBC官方站

你可以在下載頁面找到最新版

unixODBC是一套擁有相當高支援性的unix平台ODBC驅動程式，比起iODBC，unixODBC更多了一些好用的工具介面及詳細的說明

你可以在官方站的manual頁面找到許多安裝指南

安裝PostgreSQL

在這裡必須強烈建議使用Source安裝，使用RPM由於會自動加入ptherad功能

就SRB的maillist有提到說可能會引發程式出錯

將下載回來的套件解開之後，進入PostgreSQL source 目錄
root $> ./configure --with-perl --with-nls

root $> make all install

root $> cd /usr/local/pgsql

root $> adduser postgres

root $> mkdir data

root $> chown -R postgres:postgres data

#請自行加入路徑至PATH

root $> initdb ./data

root $> pg_ctl -D ./data -l ./data/pgsol.log start

#要停止的話

root $> pg_ctl -D ./data stop

#重新啟動

root $> pg_ctl -D ./data -l ./data/pgsol.log restart

PostgreSQL與MySQL一樣，預設使用unix domain socket

為了能使ODBC驅動程式正常運作

我們得啟動他的tcp通訊埠

編輯data/postgresql.conf

大概在第30行有個tcpip_socket = false 改成true

下面有個port=5432

這是等會也要在ODBC設定檔設置的

重新啟動PostgreSQL之後可以測試看看
root $> netstat -al

tcp 0 0 *:postgres *:* LISTEN
安裝unixODBC及psqlodbc驅動程式

unixODBC的圖形工具要在kde下跑，如果你沒有安裝kde及libqt，記得加入 --enable-gui=no
root $> ./configure

root $> make all install

由於psqlodbc欠了三個檔案，請從postgresql安裝目錄找到這三個檔案，並複製過去

例如：/usr/local/pgsql/include

這三個檔案是

iodbc.h

isqlext.h

isql.h

#進入psqlodbc source目錄

root $> ./configure --with-unixodbc --enable-static

root $> make all install
在linux中，如果動態函示庫沒有以lib開頭，會無法正確連結

不使用softlink是因為mcat程式會無法正確抓到載入系統的函示庫

不過unixODBC是直接連接的，仍然可以正常運作
root $> cd /usr/local/lib

root $> ln psqlodbc.la libpsqlodbc.la

root $> ln psqlodbc.so libpsqlodbc.so

root $> ldconfig -v
新增odbcinst.ini

建立/usr/local/etc/odbcinst.ini

加入

[PostgreSQL]
Description = PostgreSQL driver for Linux & Win32
Driver = /usr/local/lib/libpsqlodbc.so

root$> odbcinst -i -d -f odbcinst.ini -n PostgreSQL

他會自動做其餘的設定

odbc驅動需要在預設資料庫增加一些function

root $> su postgrespostgres $> psql template1 < /usr/local/share/psqlodbc/odbc.sql

建立預設及mcat所要用的資料庫

我給SRB用的資料庫名稱為srb
root $> su postgres

postgres $> createdb postgres

postgres $> createdb srb

postgres $> createuser srb
切換成srb帳號，進入家目錄

建立.odbc.ini

並增加下列幾行

[PostgreSQL]
Servername = localhost
Database = srb
Username = srb
Password = nchcsrb
Port = 5432
Driver = /usr/local/lib/psqlodbc.so

如果出了問題，想要察看log，可以加入

Trace = Yes
TraceFile = /home/srb/odbc.trace
srb$> odbcinst -i -s -f .odbc.ini

srb$> isql PostgreSQL

+---------------------------------------+
| Connected!
|
| sql-statement
| help [tablename]
| quit
|
+---------------------------------------+
SQL>

表示可以正常連接

SRB with MCAT

前面準備動作都同樣，多了設定MCAT那個部分

root$> ./configure--enable-psgmcat --enable-psghome=/usr/local/pgsql--enable-javagui --enable-jdkhome=$JAVA_HOMEroot$> make

接下來仍然是建立srb帳號

加入環境變數...等

由於我們使用的是PostgreSQL ODBC Driver，而SRB又少了三個.h檔，我們必須將他複製到你安裝PostgreSQL的include

例如：/usr/local/pgsql/include

這三個檔案是

iodbc.h

isqlext.h

isql.h

切換至SRB Source目錄

root$> makeroot$> cd MCATroot$> makeroot$> chown -R srb:srb /usr/local/SRB

編輯設定檔

接著進入data目錄編輯三個檔案

將mcatHost檔案改為你的主機名稱

將MdasConfig.psg複製，覆蓋掉原來的MdasConfig
你只要更動這裡所有的路徑至正確的，此外DB2USER就是剛剛使用createuser在PostgreSQL建立的帳號"srb"

將hostConfig加入你的主機名稱

建立資料庫

切換成srb帳號，進入SRB Source下的MCAT/data目錄

如果有需要觀看結果，輸出重導至任何檔案

install.results.*這些檔案是SDSC他們安裝的結果，可以用diff與你自己的安裝結果比較

srb$> psql srb < catalog.install.psg

將MCAT/bin加入至你的路徑，你可以現在就將這些常用的路徑寫至srb帳號的環境設定檔

之後可以在MCAT/data執行test.catalog這個script

test.reault.*是SDSC測試的結果

srb$> ./test.catalog

使用diff來將你的結果和官方的結果比較後

若是發現錯誤，可以使用utilities/bin底下的Scommand

srb$> Serror -3219
Serror
DATA_SUBCOLLECTION_NOT_UNIQUE: DATA_SUBCOLLECTION_NOT_UNIQUE

你或許可以在SRB的maillist找到一些解釋

isql連線測試沒什麼問題的話，就幾乎都會正常

若是出現Segmentation fault，你應該試著將psqlodbc驅動重新make，或是使用另一個版本

真的有錯誤，為了追蹤，你可以開啟PostgreSQL的Log connection/statement 功能

註冊帳號及區域

MCAT有預先定義一組區域及帳號，我們將使用這組帳號來新增其他帳號

以下的操作，需要一個可用的c shell

以下可能會有一些字元混淆的狀況，例如O和0，1和l

不行的話試著複製貼上吧
srb$> csh

srb%> setenv srbUser srb

srb%> setenv srbAuth CANDO

srb%> setenv mdasDomainName sdsc

srb%> ingestToken Domain nchc gen-lvl4

srb%> ingestUser srbadmin nchcsrb nchc sysadmin '' '' ''

這兩道指令原本的意思

ingestToken Domain $YOURDOMAIN gen-lvl4

ingestUser $YOUR_ADMIN_NAME $YOUR_PASSWD $YOUR_DOMAIN sysadmin '' '' ''

啟動

同樣地，複製並編輯好.MdasAuth及.MdasEnv兩個檔案

便可以依照上面的作法啟動SRB

啟動的訊息應該也會於上面無異

Test

你可以下載InQ，Windows的SRB Client來使用上面的帳號連接看看

一些API，工具的使用在之後的文章會陸續介紹

Kiwi格網技術開發站

程式開發者可記的九大經典名句

重新整理

台灣軟體界的無奈

2010的雲端回顧及未來展望

總結

雲端服務的本質

中國速度

台灣科技產業軟硬體的兩難

未來展望

闕志克與貨櫃型電腦介紹 / 文茜的世界財經週報 2010.01.10

從不同的角度看雲端運算

Wikipedia的定義

從網路商業的角度來看

從資訊技術發展的角度來看

從資訊相關領域的人來看

對於非資訊領域的人來說

從高效能計算的角度來看

結論

搬新家

維修

趨勢2009騰雲駕霧 程式競賽

ISGC 2009, Symposium Day3

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

“Grids and Clouds: a Comparison”Francois GREY

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

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

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

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

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

ISGC 2009, Symposium Day2

ISCG 2009, iRODS Workshop

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

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

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

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

14:00 Introduction to iRODS rules and micro-services (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)

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

ISGC 2009, BOINC Workshop

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

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

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

12:30 午餐時間

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

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

晚宴：福華飯店

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

11:30 Demo

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

12:30 午餐時間

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

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

科學與計算

Google App Engine, MapReduce與資料處理

介紹

Funcitonal Programming

Parallel Data Analysis Language

HTTPMR

結論

VMWare虛擬化叢集建置

介紹

虛擬化技術名詞解釋

Virtual Machine(VM)：虛擬機器

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

Virtualization Cluster：虛擬化叢集

Motion Technology：VM動態轉移

Storage Area Network (SAN)：儲域網路

iSCSI Protocol

企業虛擬化方案

VMWare ESX 3.5

Citrix XenServer 5

建置

部署環境

建置iSCSI NAS

準備硬體

安裝及設定

建置叢集

伺服器設定

網路設定

趨勢2009騰雲駕霧程式競賽

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