| | 1 | = 2009-06-26 = |
| | 2 | |
| | 3 | * 時間： 2009-06-26 12:10~13:10 |
| | 4 | * 地點： 陽明大學生物藥學資訊所 412 教室 |
| | 5 | * 講者： 王耀聰 副研究員 |
| | 6 | * 講題： 『高速運算於生物資訊之應用』 |
| | 7 | * 討論： |
| | 8 | * Q1: mpiBLAST-G2 是否僅合適使用在格網合作雙方的資源夠多的情形下才合適？ |
| | 9 | * A1: 是的。也因此過去格網計算的重點在於洽談資源共享的政策，也就是虛擬組織的建立。 |
| | 10 | * A1.1: 以下是我個人的觀點：格網計算要整合的資源不僅該是異質系統，更應該是異質產業，才能有效達成負載分攤的目的。若同樣都是學術單位，資源巔峰使用率都會出現在畢業季前，每個單位都不夠用，那又如何做跨單位負載平衡呢？ |
| | 11 | * Q2: 目前採用雲端運算划算嗎？ |
| | 12 | * A2: 看應用。根據 Amazon EC2 與 S3 的計費方式，計算、儲存與網路傳輸都要計費，因此以生物資訊的應用不合適。目前合適的規模以中小企業為主， |
| | 13 | * A2-1: 以下是我個人的觀點：生物資訊相關應用應該建立私人雲端(Private Cloud)，因為生物資訊的應用必須上傳大的資料集(Dataset)，儲存那麼大的資料，又是高計算量的應用，因此以使用量來計算，或許建置自己的私有雲端會比較恰當。 |
| | 14 | * Q3: 為何說雲端運算是『計算就資料』，格網運算是『資料就計算』呢？ |
| | 15 | * A3: 這是目前我們的觀察，以及技術實作上的差異(格網的 Globus 技術特性，雲端的 Hadoop 技術特性)。格網過去會採用 GridFTP 來搬運資料，因此縱使 Meta-Schedule 幫你找到計算資源，而你也已經排到排程，但還是要等資料搬好才可以作運算。而雲端運算是一開始資料上傳就被切割成細塊，同時備份三份隨機分布在不同主機上，因此排程器較容易地找到資料所在的計算節點進行運算。 |
| | 16 | * Q4: 為何說雲端運算是『即時性差』？ |
| | 17 | * A4: 這是相較於過去一些分散式運算(特別是分散式物件)的特性而言。因為目前雲端運算的技術(特別是Hadoop)主要還是以批次作業(Batch)為主，如果是串流式(Stream)的運算，或 Online Simulation 的模擬就不合適採用雲端運算。 |
| | 18 | * Q5: 請問雲端運算可以跑 CUDA 嗎？ |
| | 19 | * A5: 如果是目前 Amazon EC2 的服務，答案是不行，因為他們目前並沒有提供有 CUDA 顯示卡的主機供計算。但國網中心有做這方面的實驗，可參考[grid:wiki:Xen_GPU 我們實驗網站的 Xen GPU 相關筆記]，並且預計會提供一套這一類的虛擬叢集供外界使用。當然我們一直還在思考這樣的使用模式是否恰當。 |
| | 20 | * Q6: 可否簡介 DRBL 的運作原理？ |
| | 21 | * A6: 詳附件投影片。 |
| | 22 | * Q7: 那 DRBL 不使用 Client 的硬碟是否有點浪費？ |
| | 23 | * A7: 實際上 DRBL Client 是可以掛載硬碟的，只是需要一些步驟，我們目前還沒把這部分變成功能選項之一。畢竟過去 DRBL 是以電腦教室管理為主要應用，真正應用在上線使用的叢集上，比例還是偏低，因此這方面的軟體支援跟技術文件較少。 |
| | 24 | * Q8: DRBL 未來可能會提供監控 Client CPU 或 Disk 使用量的機制嗎？ |
| | 25 | * A8: 目前有文件（如[grid:wiki:ceasar/ganglia Ganglia]），但未撰寫軟體套件，未來會考慮整合成新的套件。 |
