0
| 本文作者： 張帥 | 2020-03-21 08:21 |
本文為該系列的第二篇文章，第一篇文章點擊此處。
作者：Daniel Gruber，Burak Yenier和Wolfgang Gentzsch，UberCloud。
該公司成立于2013年，致力于開發(fā)HPC容器技術(shù)和容器化工程應(yīng)用程序，以促進(jìn)在共享的本地或按需云環(huán)境中訪問和使用工程HPC工作負(fù)載。本文及上一篇文章中，他們描述了過去12個月在Kubernetes上使用UberCloud HPC容器的經(jīng)驗。
隨著云服務(wù)的興起，CIO意識到在各種計算環(huán)境中運行的應(yīng)用程序，中間件和基礎(chǔ)架構(gòu)需要通用的管理和操作模型。通過為每個云提供商使用不同的專用基礎(chǔ)架構(gòu)和應(yīng)用程序管理解決方案，在本地和云環(huán)境中維護(hù)不同的應(yīng)用程序和中間件堆棧，會在動態(tài)分配，使用和管理這些資源時增加很多麻煩。
混合云環(huán)境中缺乏通用的管理和運營模型可能導(dǎo)致：
不均勻，分散的環(huán)境給管理人員，操作人員和安全性帶來了額外的復(fù)雜性。
由于沒有通用管理的混合環(huán)境，創(chuàng)新速度降低了。
當(dāng)依賴于云提供商的特定服務(wù)時，很難更改或關(guān)閉云資源。
當(dāng)綁定到特定的云環(huán)境設(shè)置時，工作負(fù)載不容易遷移回本地環(huán)境，反之亦然。
正如上一篇文章中指出的那樣，Kubernetes已成為事實上的標(biāo)準(zhǔn)容器編排器。所有主要公司都在隨處可用的標(biāo)準(zhǔn)化API之上提供并構(gòu)建解決方案。CIO現(xiàn)在正在研究Kubernetes在混合云中對HPC的適用性，因為它為每種環(huán)境提供了通用的管理和操作模型。
Kubernetes促進(jìn)了服務(wù)器隊列中運行的無數(shù)容器的使用和管理，它是由許多IT供應(yīng)商和云提供商支持的用于混合環(huán)境的新標(biāo)準(zhǔn)平臺。現(xiàn)在，CIO可以分配一個完全配置并受支持的容器編排器，作為其所有應(yīng)用程序工作負(fù)載的基礎(chǔ)。
與專有基礎(chǔ)架構(gòu)解決方案不同，Kubernetes具有可移植性，易于管理，高可用性，可集成性和監(jiān)視功能。在Kubernetes上管理資源時，CIO不再綁定到特定的基礎(chǔ)架構(gòu)。他們可以使用相同的應(yīng)用程序堆棧為用戶提供相同的功能集，無論是本地還是在任何云中。用戶甚至不知道自己的應(yīng)用程序正在Kubernetes上運行，也不知道它們在哪個基礎(chǔ)架構(gòu)上運行：是在自己的數(shù)據(jù)中心還是在特定的云提供商（例如Google，Microsoft或Amazon）上。
通過使用像Kubernetes這樣的標(biāo)準(zhǔn)化軟件棧來降低混合云環(huán)境的復(fù)雜性具有許多優(yōu)點：對一個平臺進(jìn)行的改進(jìn)可以自動在其他平臺上使用；部署和運營方面可以簡化；安全審核更容易，更嚴(yán)格地執(zhí)行。
Kubernetes已經(jīng)是AI和ML的事實平臺，但是，當(dāng)涉及到傳統(tǒng)的高性能計算時，仍然存在一些挑戰(zhàn)。HPC工作負(fù)載管理器中內(nèi)置了一組功能，Kubernetes中尚不可用。我們之前在第一篇文章已經(jīng)討論了主要差異，Kubernetes在HPC方面的主要差距是：對分布式內(nèi)存作業(yè)（即MPI應(yīng)用程序）的本機支持，以及與現(xiàn)有HPC應(yīng)用程序兼容的缺少的作業(yè)排隊系統(tǒng)。
Kubernetes在許多層上都內(nèi)置了高可用性。但是，對于HPC作業(yè)，僅重啟一個失敗的容器是不夠的，因為整個分布式作業(yè)本身可能已經(jīng)失敗了。在這種情況下，需要對整個分布式內(nèi)存作業(yè)進(jìn)行自動重新計劃。這是Kubernetes無法處理的。
除了這些挑戰(zhàn)之外，Kubernetes還為HPC帶來了許多好處：例如，工程師和容器化HPC應(yīng)用程序的環(huán)境始終是相同的，無論是本地部署還是在基于云的環(huán)境中運行；快速從一種基礎(chǔ)架構(gòu)轉(zhuǎn)換為另一種基礎(chǔ)架構(gòu)的能力使HPC團(tuán)隊能夠與其公司的云路線圖保持一致。在基于通用API（Kubernetes API）的基礎(chǔ)架構(gòu)之間移動工作負(fù)載的自由變得很有價值。
在過去的五年中，已經(jīng)將數(shù)十種HPC應(yīng)用程序進(jìn)行了容器化，無論是商業(yè)化的，例如ANSYS，COMSOL，STAR-CCM +，還是開源軟件包（如OpenFOAM和GROMACS），以及HPC集群調(diào)度程序，例如Univa Grid Engine和Slurm。由于采用了容器技術(shù)，因此可以提供持續(xù)不斷的更新和改進(jìn)，客戶可以快速，無縫地對其進(jìn)行更新。此外，容器映像允許用戶隨時返回到先前的應(yīng)用程序版本，以便他們始終可以重現(xiàn)其先前的結(jié)果。
在托管Kubernetes上運行的示例HPC應(yīng)用程序集群架構(gòu)
同時，通過使用諸如Terraform和Puppet之類的基礎(chǔ)架構(gòu)和配置管理工具或通過將特定于云的HPC集成構(gòu)建到現(xiàn)有門戶中，已經(jīng)實現(xiàn)了許多容器環(huán)境。但是隨著Kubernetes的到來，容器環(huán)境變得更易于維護(hù)并且更加動態(tài)?？刂破鞑粩囹?qū)動集群，從而將集群推出，重新調(diào)整工作節(jié)點的規(guī)模，使用一組恒定的可搶占實例以及高可用性。
因此，Kubernetes和HPC主要差距已被消除。這樣，今天，任何Kubernetes環(huán)境都可以支持分布式內(nèi)存/ MPI作業(yè)，該環(huán)境提供了在HPC容器內(nèi)運行的內(nèi)置HPC工作負(fù)載管理器集成。這使傳統(tǒng)的HPC應(yīng)用程序無需任何更改即可運行。同時，通過在內(nèi)部運行的高性能支持GPU的Pod，已成功啟動了基于Ansys和COMSOL的GPU和未支持GPU的應(yīng)用程序。登錄到桌面后，工程師可以開始提交批處理作業(yè)或單個MPI應(yīng)用程序，這些應(yīng)用程序分布在多個節(jié)點上分配的一組Pod中。
Kubernetes不僅支持基于微服務(wù)的企業(yè)應(yīng)用程序，而且還支持自助服務(wù)工程HPC應(yīng)用程序?？偠灾缭撗芯勘砻鞯哪菢?，使用Kubernetes作為運行容器化工程應(yīng)用程序的基礎(chǔ)的主要優(yōu)點是：
幾乎所有基礎(chǔ)架構(gòu)上均可使用統(tǒng)一應(yīng)用程序堆棧；
真正的混合云使用方案，可滿足工程負(fù)載的需求。對于工程師而言，無論在本地還是在云中運行應(yīng)用程序，它都是透明的；
通過始終分配云中可用的最新和最快的機器，從而為運行工程應(yīng)用程序提供最佳性能；
作為工程師的自助服務(wù)，構(gòu)建并調(diào)整獨立的HPC應(yīng)用程序和計算集群的大小，并且僅受每個時間段的云配額和預(yù)算限制；
強大的管理堆棧，得到許多云提供商的支持；
僅通過支付使用費用來優(yōu)化成本。不需要閑置資源，這些閑置資源將在使用前被分配；
通過獨立的專用計算集群實現(xiàn)高安全性；
通過自我配置和一次性組件（將更新簡單地銷毀并重新創(chuàng)建命令），將操作開銷降至最低；
基于Kubernetes的工作負(fù)載更易于集成到廣泛采用的持續(xù)集成和部署解決方案中（例如Tekton，Concourse或Jenkins的未來版本）。
在這項研究中，基于容器的HPC應(yīng)用程序環(huán)境已在Kubernetes之上實現(xiàn)（例如，在Google GCP和Amazon AWS上），并且還用作自助服務(wù)測試環(huán)境，可由HPC應(yīng)用程序?qū)＜叶沁\營商從頭開始部署。它也已用于CI / CD管道中，以自動構(gòu)建測試環(huán)境，以針對現(xiàn)有容器解決方案運行測試并隨后關(guān)閉基礎(chǔ)架構(gòu)。在客戶環(huán)境中，IT部門受益于使用受支持的托管Kubernetes易于維護(hù)的系統(tǒng)，該系統(tǒng)可以在幾分鐘之內(nèi)增加，調(diào)整大小和刪除計算資源。
雷鋒網(wǎng)編譯，viahpcwire.com（雷鋒網(wǎng)雷鋒網(wǎng)）
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
