= 2009-06-26 =

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