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