云計算最初是聚焦于為參與系統(tǒng)提高進(jìn)應(yīng)用架構(gòu)，但在高性能計算方面卻提供不了什么?，F(xiàn)在，領(lǐng)先的云提供商正在對自己的產(chǎn)品及相關(guān)基礎(chǔ)設(shè)施進(jìn)行重構(gòu)，以便讓計算密集型應(yīng)用具備實用性和成本效率。

傳統(tǒng)上，云在架構(gòu)上被設(shè)計為與Dropbox之類的存儲、Gmail、iTunes以及Evernote等應(yīng)用結(jié)合的服務(wù)交付。“集群的架構(gòu)則是為了暴露存儲以外的資源，比方說，那些需要在定制化網(wǎng)絡(luò)執(zhí)行供應(yīng)商提供或用戶開發(fā)的應(yīng)用，” Bright Computing的CEO Matthijs Van Leeuwen說。

跟運行在專門硬件上的傳統(tǒng)集群很像的是，基于云的集群出于某種目的也包含了獨特的分布式資源的整合。這種云包括為能感知集群的數(shù)據(jù)庫管理系統(tǒng)(DBMS)、高性能計算(HPC)或大數(shù)據(jù)分析應(yīng)用提供平臺。像Amazon、Rackspace這樣的公有云提供商會把可用于在其云基礎(chǔ)設(shè)施上開發(fā)集群的預(yù)定義資源實例暴露出來。

OpenStack允許組織定義自己的資源實例，然后用這些實例來在自己的私有云開發(fā)集群。物理服務(wù)器或者利用物理服務(wù)器上的超級管理程序的虛擬機器(VM)通常都是處在專門的本地集群里面的。對于開發(fā)者來說，關(guān)鍵的不同是云和專門集群之間的資源實例抽象有所不同。

集群常用情況

Leeuwen說云集群可用于替代或補充專門資源。對于專門硬件最小化的應(yīng)用，如筆記本，云可用于集群的實例化、使用以及去實例化。在這一用例中，筆記本不再是一臺訪問基于云的集群的最終用戶設(shè)備。它并不提供任何被用于執(zhí)行計算或打造網(wǎng)絡(luò)的實例化資源。

在第二種常見的用例中，基于云的資源可被用來作為專門資源的補充。這種情況下，本地資源通過哪些云資源的云爆發(fā)過程得到擴(kuò)展?；谠频馁Y源只需像專門資源一樣被實例化、使用然后去實例化。本地與云端資源的區(qū)別對于最終用戶以及許多類型的應(yīng)用來說可以是透明的。

這兩種情況都可以應(yīng)用到公有云或者私有云上。組織可以將自己的應(yīng)用架設(shè)來直接做這件事情，或者利用像Bright Cluster Manager之類的工具，在AWS或OpenStack私有云建立集群，從而減少前端開發(fā)和配置工作。

減少抽象的差別

開發(fā)者面臨的最大挑戰(zhàn)是提供像網(wǎng)絡(luò)、CPU及存儲等云資源與專門資源之間不同的抽象模型。云需要依賴實例化的資源。除了存儲以外，基于云的CPU實例的暴露無論是公有云還是私有云產(chǎn)品都已經(jīng)相當(dāng)成熟。最新的云產(chǎn)品一般會伴隨著針對InfiniBand網(wǎng)絡(luò)連接、GPU加速以及自定義IP網(wǎng)絡(luò)等特殊外部需求的服務(wù)和鉤子一起提供。

任何需要經(jīng)過這相同的到達(dá)路徑的資源都可以暴露出來供任何類型的云內(nèi)開發(fā)利用。因為集群通常利用了低時延、高帶寬的內(nèi)部互聯(lián)結(jié)構(gòu)，以及加速器和協(xié)處理器等特殊資源，在基于云的集群情況下，這些東西既代表了機遇，又會成為挑戰(zhàn)。

組織得聽?wèi){云供應(yīng)商來支持存儲與計算以外資源的實例化，Leeuwen說。比如AWS，就通過Amazon VPC以及NVIDIA GPU實例支持定制的IP網(wǎng)絡(luò)。一個好的做法是建立標(biāo)準(zhǔn)配置或利用第三方云管理來管理存儲、計算、網(wǎng)絡(luò)及加速器資源，無論它們是在本地的還是與AWS配合的。

時延是集群的關(guān)鍵

通信時延是建設(shè)可伸縮集群應(yīng)用最大的挑戰(zhàn)之一。好的做法是智能地為HPC籌劃階段數(shù)據(jù)。在數(shù)據(jù)端，這涉及到考慮使用更具成本效率、持久性更慢的存儲服務(wù)，如AWS S3，以及利用AWS Glacier這樣的歸檔服務(wù)，而不是更昂貴的RAM實例。

但一項甚至比這還大的網(wǎng)絡(luò)挑戰(zhàn)是將計算期間節(jié)點之間的通信時延最小化。在處理期間利用了消息傳遞的HPC應(yīng)用是最容易受到瓶頸影響的。廣泛利用MPI這樣接口的應(yīng)用將會錯亂，除非開發(fā)者和運營團(tuán)隊確保節(jié)點之間的時延極低。

如果在集群中運行的MPI應(yīng)用是封閉在私有云或者公有云范圍之內(nèi)的話，情況會更容易處理一些。但這個如果在運行于獨立公有云或私有云的不同節(jié)點之間存在大量MPI流量的話會成為一個更大的問題。

同樣的考慮也適用于在云端運行大數(shù)據(jù)分析。這對于跨本地和云基礎(chǔ)設(shè)施之間有Hadoop分布式文件系統(tǒng)(HDFS)來說并沒有太大意義。“不過HDFS完全位于本地或在云端的話在實踐上還是工作得相當(dāng)好的，” Leeuwen說。

擴(kuò)充時維持性能的關(guān)鍵是分布式架構(gòu)，敏捷云集成解決方案提供商Jitterbit的CTO Ilan Sehayek說。“讓用戶來選擇在哪里運行API，以及在哪里運行支持該API的服務(wù)。”

還得確保所有通信都是由可伸縮的消息傳遞基礎(chǔ)設(shè)施來提供的，這樣才能提供API網(wǎng)關(guān)與服務(wù)之間快速、有保證的API請求交付。面向集群的服務(wù)也需要高效緩存技術(shù)來提供對API的快速響應(yīng)，Sehayek補充道。