時至今日，云計算已經(jīng)開始將關(guān)注重點轉(zhuǎn)移至應(yīng)用程序架構(gòu)的改進方面，旨在借此提高系統(tǒng)的客戶吸引力，然而這一訴求在高性能計算領(lǐng)域始終拿不出切實的成果。目前，各大領(lǐng)先云服務(wù)供應(yīng)商都在重構(gòu)自己的產(chǎn)品與相關(guān)基礎(chǔ)設(shè)施，旨在以更具實用性及成本效益的方式提供計算密集型應(yīng)用程序。

[[135399]]

從傳統(tǒng)角度看，云技術(shù)已經(jīng)成為一套將應(yīng)用程序與Dropbox、Gmail、iTunes以及Evernote等存儲方案相結(jié)合的綜合性服務(wù)交付架構(gòu)。“集群的架構(gòu)方式旨在超越存儲而帶來其它資源供應(yīng)機制，例如在自定義網(wǎng)絡(luò)之上執(zhí)行來自特定供應(yīng)商或者由用戶自行構(gòu)建的應(yīng)用程序，”Bright Computing公司CEO Matthijs Van Leeuwen表示。

與運行在專用硬件平臺之上的傳統(tǒng)集群方案類似，基于云的集群同樣可以將多種不同類型的分布式資源合并起來以支持特定負載用途。其中可能包含利用一套平臺實現(xiàn)集群化數(shù)據(jù)庫管理系統(tǒng)（或者簡稱為DBMS）、高性能計算應(yīng)用程序或者大數(shù)據(jù)分析應(yīng)用程序。以Amazon以及Rackspace為代表的公有云供應(yīng)商會對自己的資源實例進行預(yù)定義，從而在其自己的云基礎(chǔ)設(shè)施之上構(gòu)建起多種集群體系。

OpenStack允許企業(yè)用戶定義自己的資源實例，而后利用這些實例在自己的私有云環(huán)境內(nèi)實現(xiàn)集群構(gòu)建。物理服務(wù)器或者在物理服務(wù)器之上通過虛擬機管理程序?qū)崿F(xiàn)的虛擬機系統(tǒng)通常適用于構(gòu)建專用型內(nèi)部集群。對于開發(fā)人員而言，各類資源實例之間的最大差別在于抽象化方式的不同，而這也將成為云與專用集群間的本質(zhì)區(qū)別所在。

常見集群使用情況

Leeuwen指出，云集群能夠被用于取代或者補充現(xiàn)有的專用型資源。對于運行在最小化專用型硬件——例如筆記本電腦——上的應(yīng)用程序，云能夠作為其“實例化、使用與去實例化”集群。在這種情況下，筆記本電腦本身僅僅充當最終用戶進行云集群訪問的設(shè)備——具體而言，它并不提供任何用于執(zhí)行計算或者構(gòu)建網(wǎng)絡(luò)體系的實例化資源。

而在第二種常見用例當中，基于云的資源能夠被作為補充性專用資源。在這類情況下，內(nèi)部資源會通過云爆發(fā)流程成為云環(huán)境內(nèi)的擴展資源組成部分。這部分基于云的資源只需要根據(jù)具體需求進行實例化、使用及去實例化。內(nèi)部環(huán)境與云資源之間的這種差別能夠以透明化方式呈現(xiàn)給最終用戶及多種不同類型的應(yīng)用程序。

這兩類用例都能夠應(yīng)用于公有或者私有云環(huán)境當中。企業(yè)用戶能夠建立起自己的應(yīng)用程序架構(gòu)，從而直接或者利用Bright Cluster Manager等工具在AWS公有云或者OpenStack私有云內(nèi)建立集群，這將顯著降低前端開發(fā)及配置任務(wù)的實際工作量。

橋接不同抽象模式的裂隙

[[135400]]

開發(fā)人員所面臨的最大挑戰(zhàn)在于，相對于專用型硬件而言，網(wǎng)絡(luò)、CPU以及存儲等云資源在配置方面采用完全不同的抽象模式。云環(huán)境的運行依托于實例化資源。除了存儲之外，基于云的CPU實例在公有與私有云方案中已經(jīng)相當成熟。最新的云服務(wù)產(chǎn)品一般會提供面向特定外部要求的服務(wù)與鉤子，例如InfiniBand網(wǎng)絡(luò)連接、GPU加速以及自定義IP網(wǎng)絡(luò)等等。

任何一種資源都需要經(jīng)由同樣的路徑才能為任何一類云環(huán)境所使用。由于集群會以路由方式采用具備低延遲與高傳輸帶寬水平的互連體系、加速器與協(xié)助處理器以及其它指定資源，所有這些都會在基于云的集群實例當中同時帶來嚴峻的挑戰(zhàn)與良好的業(yè)務(wù)擴展機遇。

“企業(yè)用戶需要完全依賴于云服務(wù)供應(yīng)商的思路來支持除存儲與計算之外的資源實例化效果，”Leeuwen指出。舉例來說，AWS能夠通過Amazon VPC支持自定義IP網(wǎng)絡(luò)以及英偉達GPU實例。其中一類優(yōu)秀的實踐在于開發(fā)標準化配置或者利用第三方云管理方案來管理存儲、計算、網(wǎng)絡(luò)以及加速器資源，無論它們處于內(nèi)部環(huán)境還是AWS體系之下。

#p#

延遲水平對于集群而言至關(guān)重要

在構(gòu)建可擴展集群應(yīng)用程序的過程當中，保證通信延遲水平處于理想范圍之內(nèi)已經(jīng)成為最大的挑戰(zhàn)之一。其中一項良好實踐就是以智能化方式為高性能計算進行數(shù)據(jù)劃分。在數(shù)據(jù)層面，這需要涉及到考量使用更具成本效益且持久性更好的存儲服務(wù)，例如AWS S3以及歸檔服務(wù)AWS Glacier，而非成本更高的內(nèi)存實例。

但在規(guī)模更為龐大的網(wǎng)絡(luò)體系中，挑戰(zhàn)則主要體現(xiàn)在保證不同節(jié)點之間在處理計算任務(wù)時將通信延遲保持在最低水平。對于需要在處理過程中進行大量信息傳遞的高性能計算應(yīng)用程序而言，傳輸延遲正是其最容易面臨的性能瓶頸。那些采用MPI等通用型接口的應(yīng)用程序往往會因此陷入性能低谷，除非開發(fā)人員與運營團隊能夠確保不同節(jié)點之間的延遲始終處于最低水平。

如果運行在集群當中的MPI應(yīng)用程序處于封閉的私有云或者公有云環(huán)境之內(nèi)，那么這個問題其實并不難解決。然而如果運行在獨立私有或者公有基礎(chǔ)設(shè)施內(nèi)的不同節(jié)點之間存在大量MPI流量，那么這個問題就會變得非常嚴重。

同樣的思路也適用于在云環(huán)境下運行大數(shù)據(jù)分析方案。在內(nèi)部環(huán)境以及云基礎(chǔ)設(shè)施之上部署Hadoop分布式文件系統(tǒng)（簡稱HDFS）實例往往并沒有什么意義。“但如果HDFS實例單獨運行在內(nèi)部或者云環(huán)境下，則將帶來非常出色的實踐效果，”Leeuwen表示。

在對分布式架構(gòu)進行擴展的過程中，保障性能水平的關(guān)鍵在于采用敏捷型云集成解決方案，Jitterbit公司CTO Ilan Sehayek指出。“讓用戶自己選擇在哪里運行API，又在哪里運行用于支持該API的相關(guān)服務(wù)。”

“除此之外，我們還需要確保所有通信流程都由一套可擴展信息傳遞基礎(chǔ)設(shè)施來實現(xiàn)，從而在API網(wǎng)關(guān)與服務(wù)之間帶來快速且可靠的API請求交付效果。面向集群的服務(wù)項目還需要配合高效的緩存技術(shù)，從而為API提供理想的響應(yīng)速度表現(xiàn)”，Sehayek補充道。

[[135401]]

原文標題: High-performance computing with cloud clusters