一個轉移、穩定和管理大量資料集的雲環境案例分析

在本文的應用科學調查中，作者講述了他們將基於高性能計算的商業基因重組應用程式移植到雲環境中的經驗；簡要介紹了他們制定的關鍵基礎架構決策，以及將這些決策從純粹的 HPC 類型設計變成他們喜愛的大資料設計的歷程。

該專案的目標是為了實現一個商業基因分析應用程式，可以獲得極大的可擴充性並控制相關成本。 該應用程式已被設計出來，內部運行在高性能計算 (HPC) 類的基礎架構上，而且該基礎架構的容量即將達到其限制。 同時，分析量預計會迅速增加。 因此，人們希望嘗試將應用程式移植到雲環境中。

另外，時間限制阻止了我們重新設計原始應用程式的可能，只允許我們對應用程式的組織方式進行較小的改變。 我們首先將從 IT 角度簡要概述計算基因組學產生的問題。

瞭解生物體基因組序列的常規方法涉及到以下步驟：

將原始基因組的多個副本（通常為 30-60 個）分解成大量隨機重疊的片段 (fragment)，每個片段都有固定的長度（例如，30-200 個堿基對）。 讀取每個短片段的序列，這會產生大量的小檔。 使用之前已瞭解的生物體基因組（「參照基因組」），對參照基因組上每個序列片段的位置進行最佳猜測。 這似乎是一種合理的方法，因為每個物種的基因組通常沒有太大區別。 使用統計方法確定重組基因組每個位置上最有可能的堿基對。 鑒於資料壓縮之目的，可以採用 deltas 的形式表達該方法：單核苷酸多態性（表示給定位置的基因突變），或者插入或缺失（indels），表示整個基因組長度發生了變化。

因為基因組非常巨大（例如，人類基因組的長度為 33 億個堿基對），所以二級分析意味著大量的計算和資料挑戰。 在考慮使用讀品質資料 (read-quality data) 時，每個傳入的堿基對都是通過 1 位元組的資訊進行編碼的。 因此，包含 60 個碎片（完整 DNA 分子）的傳入資料集大約將包含 3.3*109 * 60 或 200GB 左右的資料，假設在 CPU 和存儲媒介之間有大量聚合的 I/O 連線性，內核計算時間大約是 500 到 2,500 個小時。

過去，處理這類問題屬於超級電腦或 HPC 範圍內的事。 需要使用一個快速的大型中心檔案系統；輸入資料集也應放在該系統中；而參與其中的大型無狀態伺服器場將執行此項計算。

雖然處理這樣一個資料集看上去像是很容易管理，但在合理的時間範圍內處理成千上萬這樣的資料集卻是一個挑戰。 其中的一個限制因素是：隨著基因組序列成本的不斷下降而導致的需求增長，構建和運營大量處理系統所需的資本投資將持續增長。

出於這個原因，雲計算成為一個極具吸引力的模式。 它能夠提供大量具有可變定價的計算能力，並且可以根據需要來租用伺服器，不需要的時候將其返還。 但是，要充分利用雲，必須克服以下難題：

資料需要高效地通過 WAN 在雲上往返傳遞，並且需要使用適當的工具集。 需要選擇雲存儲產品類型的恰當組合，因為雲不可能提供快速的、昂貴的 HPC 類型存儲。 作業編排需考慮存儲結構和相應的擴展。 基本的水準雲擴展模式須體現在基礎架構中。 如果可能的話，必須選擇雲硬體、軟體和虛擬化的最佳組合。

本文其餘部分的結構如下：

簡介：提供相關工作的概況並介紹其他背景知識。 第 2 部分：介紹 IBM® SmartCloud™ Enterprise 的基礎知識。 第 3 部分：介紹我們為移植系統選擇的系統基礎架構。 第 4 部分：介紹結果並提供現狀基礎架構與可替代物之間的比較。 第 5 部分：討論結果並汲取教訓。 結束語：描述潛在的未來工作方向並總結本文要點。

目前，一些雲供應商可以採用即付即用的模式提供大量計算功能。 在某些情況下，為了確保與工作負載的一致性，客戶可以選擇使用底層硬體。

所以，最近幾年也有一些被設計為在雲中運行的基因組工作流的成功示例。 這些研究人員選擇使用的方法是：選擇一個雲系統（如，Amazon Elastic Compute Cloud, Amazon EC2），按 「原樣」 處理它，並對應用程式進行深入改進，以便利用雲計算的強大功能。

我們的工作實質上在以下幾個方面有所不同：

我們在工作時間範圍內改變原始應用程式的能力是有限的。 雖然這種限制肯定會產生設計瑕疵，但我們認為這很常見。 由於主要關注點是總成本，所以通過追蹤資料位元組，試圖確保它們以最短的距離進行傳輸，並關注性能，識別和消除所有瓶頸，我們可以進行近乎全面的設計。 我們在 IBM SmartCloud Enterprise 中處理本文提出的所有工作。 因為我們與支援和開發 IBM SmartCloud Enterprise 的團隊保持密切聯繫，所以我們有一個將雲的基礎架構視為白盒子 (white box) 的特殊機會，並使用這些資訊作為操作指南。 我們能夠進行調優雲配置的試驗，以便將來更好地支援這類資料密集型工作負載。

總而言之，在我們的腦海中，許多資料密集型應用程式都是使用自訂的昂貴的超級電腦或 HPC 集群編寫的。 希望我們的體驗和決策制定過程對那些試圖增加穩定性並降低應用程式所支援的任務的處理成本的人們有所説明。

介紹雲環境

IBM SmartCloud Enterprise 是一個虛擬化的基礎架構即服務 (IaaS) 產品，支援使用者在即付即用模式下借用資源，並以小時為單位給大部分資源進行定價。 其計算節點將 Kernel Virtual Machine (KVM) 用作虛擬機器管理程式和直接附加硬碟，為其虛擬機器 (VM) 提供具有最佳性價比的臨時存儲。 此外，IBM SmartCloud Enterprise 提供了每次可以附加到某個 VM 的網路連接存儲塊儲存體。 VM 以 1Gbps 的速度與塊儲存體和虛擬機器進行連接。

IBM SmartCloud Enterprise 由多個位於世界各地的資料中心（稱為：pod）組成。 在許多情況下，只需要在一個 pod（即離資料資源最近的 pod）上安裝可部署拓撲。 但是，多 pod 拓撲並不常見，因為資料可能來自世界各地，而且 pod 的有效容量也有所不同。

IBM SmartCloud Enterprise 提供了幾種 VM，從 32 位 Copper 到 64 位 Platinum，並且每種類型都有按小時收費的不同臨時存儲分配。 持久性（塊）雲存儲在多個增量中也是可用的，並且可以按容量以及 I/O 每秒的操作次數來計費。 IBM SmartCloud Enterprise 內外的資料傳輸也會根據流量產生費用。