解讀云集群下的高性能計(jì)算
云計(jì)算最初是聚焦于為參與系統(tǒng)提高進(jìn)應(yīng)用架構(gòu)，但在高性能計(jì)算方面卻提供不了什么?，F(xiàn)在，領(lǐng)先的云提供商正在對(duì)自己的產(chǎn)品及相關(guān)基礎(chǔ)設(shè)施進(jìn)行重構(gòu)，以便讓計(jì)算密集型應(yīng)用具備實(shí)用性和成本效率。
傳統(tǒng)上，云在架構(gòu)上被設(shè)計(jì)為與Dropbox之類的存儲(chǔ)、Gmail、iTunes以及Evernote等應(yīng)用結(jié)合的服務(wù)交付。“集群的架構(gòu)則是為了暴露存儲(chǔ)以外的資源，比方說(shuō)，那些需要在定制化網(wǎng)絡(luò)執(zhí)行供應(yīng)商提供或用戶開發(fā)的應(yīng)用，” Bright Computing的CEO Matthijs Van Leeuwen說(shuō)。
跟運(yùn)行在專門硬件上的傳統(tǒng)集群很像的是，基于云的集群出于某種目的也包含了獨(dú)特的分布式資源的整合。這種云包括為能感知集群的數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS)、高性能計(jì)算(HPC)或大數(shù)據(jù)分析應(yīng)用提供平臺(tái)。像Amazon、Rackspace這樣的公有云提供商會(huì)把可用于在其云基礎(chǔ)設(shè)施上開發(fā)集群的預(yù)定義資源實(shí)例暴露出來(lái)。
OpenStack允許組織定義自己的資源實(shí)例，然后用這些實(shí)例來(lái)在自己的私有云開發(fā)集群。物理服務(wù)器或者利用物理服務(wù)器上的超級(jí)管理程序的虛擬機(jī)器(VM)通常都是處在專門的本地集群里面的。對(duì)于開發(fā)者來(lái)說(shuō)，關(guān)鍵的不同是云和專門集群之間的資源實(shí)例抽象有所不同。
集群常用情況
Leeuwen說(shuō)云集群可用于替代或補(bǔ)充專門資源。對(duì)于專門硬件最小化的應(yīng)用，如筆記本，云可用于集群的實(shí)例化、使用以及去實(shí)例化。在這一用例中，筆記本不再是一臺(tái)訪問基于云的集群的最終用戶設(shè)備。它并不提供任何被用于執(zhí)行計(jì)算或打造網(wǎng)絡(luò)的實(shí)例化資源。
在第二種常見的用例中，基于云的資源可被用來(lái)作為專門資源的補(bǔ)充。這種情況下，本地資源通過哪些云資源的云爆發(fā)過程得到擴(kuò)展?；谠频馁Y源只需像專門資源一樣被實(shí)例化、使用然后去實(shí)例化。本地與云端資源的區(qū)別對(duì)于最終用戶以及許多類型的應(yīng)用來(lái)說(shuō)可以是透明的。
這兩種情況都可以應(yīng)用到公有云或者私有云上。組織可以將自己的應(yīng)用架設(shè)來(lái)直接做這件事情，或者利用像Bright Cluster Manager之類的工具，在AWS或OpenStack私有云建立集群，從而減少前端開發(fā)和配置工作。
減少抽象的差別
開發(fā)者面臨的***挑戰(zhàn)是提供像網(wǎng)絡(luò)、CPU及存儲(chǔ)等云資源與專門資源之間不同的抽象模型。云需要依賴實(shí)例化的資源。除了存儲(chǔ)以外，基于云的CPU實(shí)例的暴露無(wú)論是公有云還是私有云產(chǎn)品都已經(jīng)相當(dāng)成熟。***的云產(chǎn)品一般會(huì)伴隨著針對(duì)InfiniBand網(wǎng)絡(luò)連接、GPU加速以及自定義IP網(wǎng)絡(luò)等特殊外部需求的服務(wù)和鉤子一起提供。
任何需要經(jīng)過這相同的到達(dá)路徑的資源都可以暴露出來(lái)供任何類型的云內(nèi)開發(fā)利用。因?yàn)榧和ǔ＠昧说蜁r(shí)延、高帶寬的內(nèi)部互聯(lián)結(jié)構(gòu)，以及加速器和協(xié)處理器等特殊資源，在基于云的集群情況下，這些東西既代表了機(jī)遇，又會(huì)成為挑戰(zhàn)。
組織得聽?wèi){云供應(yīng)商來(lái)支持存儲(chǔ)與計(jì)算以外資源的實(shí)例化，Leeuwen說(shuō)。比如AWS，就通過Amazon VPC以及NVIDIA GPU實(shí)例支持定制的IP網(wǎng)絡(luò)。一個(gè)好的做法是建立標(biāo)準(zhǔn)配置或利用第三方云管理來(lái)管理存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)及加速器資源，無(wú)論它們是在本地的還是與AWS配合的。
時(shí)延是集群的關(guān)鍵
通信時(shí)延是建設(shè)可伸縮集群應(yīng)用***的挑戰(zhàn)之一。好的做法是智能地為HPC籌劃階段數(shù)據(jù)。在數(shù)據(jù)端，這涉及到考慮使用更具成本效率、持久性更慢的存儲(chǔ)服務(wù)，如AWS S3，以及利用AWS Glacier這樣的歸檔服務(wù)，而不是更昂貴的RAM實(shí)例。
但一項(xiàng)甚至比這還大的網(wǎng)絡(luò)挑戰(zhàn)是將計(jì)算期間節(jié)點(diǎn)之間的通信時(shí)延最小化。在處理期間利用了消息傳遞的HPC應(yīng)用是最容易受到瓶頸影響的。廣泛利用MPI這樣接口的應(yīng)用將會(huì)錯(cuò)亂，除非開發(fā)者和運(yùn)營(yíng)團(tuán)隊(duì)確保節(jié)點(diǎn)之間的時(shí)延極低。
如果在集群中運(yùn)行的MPI應(yīng)用是封閉在私有云或者公有云范圍之內(nèi)的話，情況會(huì)更容易處理一些。但這個(gè)如果在運(yùn)行于獨(dú)立公有云或私有云的不同節(jié)點(diǎn)之間存在大量MPI流量的話會(huì)成為一個(gè)更大的問題。
同樣的考慮也適用于在云端運(yùn)行大數(shù)據(jù)分析。這對(duì)于跨本地和云基礎(chǔ)設(shè)施之間有Hadoop分布式文件系統(tǒng)(HDFS)來(lái)說(shuō)并沒有太大意義。“不過HDFS完全位于本地或在云端的話在實(shí)踐上還是工作得相當(dāng)好的，” Leeuwen說(shuō)。
擴(kuò)充時(shí)維持性能的關(guān)鍵是分布式架構(gòu)，敏捷云集成解決方案提供商Jitterbit的CTO Ilan Sehayek說(shuō)。“讓用戶來(lái)選擇在哪里運(yùn)行API，以及在哪里運(yùn)行支持該API的服務(wù)。”
還得確保所有通信都是由可伸縮的消息傳遞基礎(chǔ)設(shè)施來(lái)提供的，這樣才能提供API網(wǎng)關(guān)與服務(wù)之間快速、有保證的API請(qǐng)求交付。面向集群的服務(wù)也需要高效緩存技術(shù)來(lái)提供對(duì)API的快速響應(yīng)，Sehayek補(bǔ)充道。
