如何在雲中運行計算密集型任務？

公有雲的出現將大規模的HPC資源帶到了普通公司的身邊。 在很多情況下，尤其是對於臨時性HPC專案來說，和內部購買必要的計算資源相比，雲解決方案在成本上更加行之有效。 在公有雲出現之前，只有少數公司，比如大型金融服務公司才有經費購買進行高性能計算所必需的資源。

在去年，可以看到在市場上有相當多的顧客需求，很多行業的許多公司針對大規模的HPC集群對軟體平臺進行測試。 當我們首先向傳統的HPC供應商描述需求時，經常被問到是哪個行業財團或是政府機關在謀求進行此項工作，因為這關係到HPC環境的規模。 當我們告訴他們這是針對個體公司而非大型組織機構時，我們遭到了對方善意的質疑。 最後，我們決定親自構建集群軟體，目標是能夠在公有雲和私有雲上運行該集群軟體。

當開發軟體面對眾多的商業和開源選擇時，我們發現多數選項都針對同時運行在集群上不同的通用應用進行了優化。 為了適應這類需求，集群依據安裝在單個計算節點上不同的作業系統進行了硬分區，而且不管應用實際上需要多少計算資源，每台機器都提前預留給了特定的應用。 這導致了計算資源的利用率相當低，平均利用率只有30%左右。 對於想創建HPC集群並作為一般資源然後將其租用給公眾使用的人來說，這綽綽有餘。 然而，這卻不是滿足典型的商業使用者需求的最佳策略。

HPC 解決方案

我們決定基於不同的原則構建HPC軟體。 最初由對該解決方案極為感興趣的某些使用者從事該專案。 這類使用者尋求降低成本並縮短時間。 完成這項工作他們不想花費超過一百萬美元，而且如果花費數周才能得到結果，那麼他們也會認為該解決方案將不會在對應的市場上具有競爭力。

當和使用HPC資源的使用者進行交流時，我們注意到公司通常圍繞一個通用的計算平臺構建單一的HPC應用，或者是相關應用的集合，而且這些使用者都希望能夠擁有一個能夠將計算時間最小化並將可用資源的使用率最大化的軟體平臺。

HPC集群設計的不同之處在于圍繞一個原則，那就是能夠動態編排單個核以確保最大化資源的利用率。 集群運行單個計算平臺並處理來自單個供應商的相關需求。 這考慮到了寬鬆的安全模型，而且來自不同計算任務的代碼能夠共用作業系統，允許我們近乎即時地在工作任務之間切換核心。

該集群設計用來解決HPC領域相關問題的一個子集，而不是試圖構建一個通用的，無所不包的計算解決方案。 我們選擇處理的問題的子集從本質上說是高度並行。 單個計算需求的計算時間至少要比分發時間高一個數量級，而且問題集合和解決方案結果足夠小能夠在網路拓撲中有效地傳輸而且分發時間要比整個任務的執行時間低上幾個數量級。 集群軟體被設計為在代碼級別整合進計算密集型應用中，而不是提供一系列通用的遠端介面。

集群架構

該集群設計用來將工作任務劃分為多個計算任務，在可用的硬體資源上高效率地執行計算任務，並將計算結果返回給用戶端應用。 該集群對裸機，運行在OpenStack的私有雲以及公有雲有效。 不同的部署場景被設計用來解決一系列的可用資源問題。 當使用者能夠支付為單個應用分配固定計算資源的費用時，裸機是最有效的。 私有雲能夠很好地應用於在應用程式之間分配公司內部硬體資源的場景，而且很容易部署一個不同的計算節點或者將HPC集群可用的計算資源轉移給其他需要計算資源的請求。 當突發的負載級別以及臨時的需求使購買硬體變得不切實際時，公有雲就是一個很好的部署場景。

HPC軟體使用Apache Libcloud在多個硬體平臺之間進行部署。 我們已經成為Libcloud專案的主要貢獻者，而且已經在很多軟體專案中使用了Libcloud專案。 HPC軟體的頂層是HPC集群元件：調度程式，工作任務介面節點，通信交換架構以及計算節點，用於高效率地控制工作任務的執行。

元件

通信交換架構由一組RabbitMQ節點構成。 為方便重新配置以及狀態資訊，單個實例被分配給控制台或者是資料面板，資料面板用來將任務傳送給計算節點並接收結果。 沒有聚合RabbitMQ實例因為我們發現這會嚴重降低用戶端重新連接的速度。 相反，客戶通信庫用於在相關的RabbitMQ實例之間分配請求，這提供了有效的可擴展機制。 通常情況下問題以及結果有效負載在帶內發送。 然而，為了增強RabbitMQ針對大型有效負載的可擴充性，已經預先部署了分散式緩存集群。 分散式緩存配置的優勢在於問題集合大於幾十KB，單個任務解決方案集合大於數百KB。

調度程式用來給單個計算任務分配計算資源。 調度程式由一系列訊息佇列和不同RabbitMQ實例的結果交付構成，它通過控制台通知計算節點的一個子集加入到佇列中。 調度程式是一個複雜策略的集合，允許客戶為不同的使用者預留計算資源，並說明資源失敗的原因，而且還處理需要特定硬體比如GPU(GPU可能會出現在節點的子集當中)的工作任務。 當集群地理位置相對接近，考慮到低延遲通信，調度決策的速率是100-200毫秒。

工作任務介面節點通過REST和WSDL介面提供了在集群中提交任務並檢索結果的方法。 通過重新提交失敗的任務，工作任務介面節點提供了冗余性。 工作任務通過資料面板通信交換架構提交給計算節點。 在計算節點上用戶端應用代碼能夠將工作任務劃分為計算任務並提交給由調度程式所構建的工作任務佇列，或者通過一系列的步驟繼續劃分為子任務。 使用HPC資源進行工作任務分解為計算成本昂貴的工作步驟在很短的時間內完成提供了可能。 最終使用者提供的用戶端代碼經過優化以最有效的方式被分解為各種任務類型，經由類庫集合和經過良好定義的API通過HPC軟體的介面。 分解鏈條和結果積累是相反的，直到最終的結果集合被分發給介面主機供客戶獲取。 工作任務鏈中的元件控制了任務並行程度而且可以告知資源需求的時程表，如果策略允許的話，調度程式可以轉移預先保留但未被充分使用的資源給其他的任務。

計算節點從指定的訊息佇列取出單個任務，獲取任務執行所必須的帶外資料，而且可以進行最終的計算或者將任務分解為其他任務，重新提交回佇列中。 實際的計算軟體由用戶端應用提供並通過編排層分發給單個節點。 計算節點監控分配給單個工作任務佇列的核心的使用率，如果分配的佇列空閒比較久或策略控制超時，計算節點將從其他的佇列抓取任務。 累積的計算結果將返回給結果佇列或者上載至分散式緩存集群並通過資料面板進行通知。

(責任編輯：蒙遺善)