wiki:jazz/09-06-26

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 顯示卡的主機供計算。但國網中心有做這方面的實驗,可參考我們實驗網站的 Xen GPU 相關筆記,並且預計會提供一套這一類的虛擬叢集供外界使用。當然我們一直還在思考這樣的使用模式是否恰當。
    • Q6: 為什麼採用 Hadoop 存取速度會比較快呢??其主因為何??
    • A6: 主要影響在於檔案系統。試想你有一份 2T 的資料,該如何儲存呢?去買一個 2T 的硬碟嗎?那也只有一條 SATA 排線的傳輸速度。假設你把 2T 的資料分散在 1000 台機器,那就會有 1000 條 SATA 排線的傳輸速度,可以隨機地去取得你想要的部分。因此相較之下,存取速度會比較快。
    • Q7: 可否簡介 DRBL 的運作原理?
    • A7: 詳附件投影片
    • Q8: 那 DRBL 不使用 Client 的硬碟是否有點浪費?
    • A8: 實際上 DRBL Client 是可以掛載硬碟的,只是需要一些步驟,我們目前還沒把這部分變成功能選項之一。畢竟過去 DRBL 是以電腦教室管理為主要應用,真正應用在上線使用的叢集上,比例還是偏低,因此這方面的軟體支援跟技術文件較少。
    • Q9: DRBL 未來可能會提供監控 Client CPU 或 Disk 使用量的機制嗎?
    • A9: 目前有文件(如Ganglia),但未撰寫軟體套件,未來會考慮整合成新的套件。
Last modified 15 years ago Last modified on Sep 14, 2009, 1:17:08 AM

Attachments (4)