公有云的出現將大規模的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軟件的接口。分解鏈條和結果積累是相反的，直到最終的結果集合被分發給接口主機供客戶獲取。工作任務鏈中的組件控制了任務并行程度而且可以告知資源需求的時間表，如果策略允許的話，調度程序可以轉移預先保留但未被充分使用的資源給其他的任務。

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

　　性能

　　總體設計的結果就是從單個任務到數百個并行任務，硬件資源的使用率都大大提高了。只要工作任務分解導致大量的并發任務多于總的可用計算核心，硬件資源的使用率達到95%是有可能的。

　　安全性

　　對公有云的安全性考慮是通過對連接到通信互聯架構的類庫中的可選的有效負載加密以及限制節點通過分布式防火墻訪問實現的。

　　結論

　　在開始安裝時，我們發現該解決方案顯著減少了常規時間，非常重要的工作在任務時間表上消除了數個星期。正式由于我們所做的工作，該集群令人注目，很多公司已經準備部署了。通過將之前在本地硬件上花費一個月完成的工作整合到云中后只需要運行三個小時，公司不僅降低了成本而且建立了新的競爭優勢，而且幫助他們更好、更快地服務客戶。

　　最后的內容和公有云vs.私有云有關。很多廠商都提供了高密度，低成本的計算刀片，按照每個核心集群的成本是1萬美元，那么總的費用是400萬美元，粗略計算使用亞馬遜的成本是6萬美元/月，盡管通過預訂或者按需購買成本可能更低。然而，通常來講，如果你需要持續使用計算資源，那么和購買硬件的成本相比，在一年之內你可能要給亞馬遜支付更多的費用。

　　然而，對于突發的、高度可擴展計算問題，對許多公司來說，在云中運行計算密集型任務是一個相當棒的而且能夠支付得起的替代選擇。

　　英文原文出處：http://www.hpcinthecloud.com/hpccloud/2011-10-25/running_compute_intensive_tasks_in_the_cloud.html

原文鏈接：http://cloud.it168.com/a2011/1109/1270/000001270844.shtml