【云駐共創】基礎設施感知業務需求，AI業務基于Volcano的實踐

和大家進行華為云在基礎設施感知業務需求，AI業務基于Volcano的落地實踐的分享。AI是屬于批量計算的一個領域，今天會按照以下結構來和大家分享

批量計算發展歷程

Volcano項目介紹與關鍵特性

Volcano助力客戶構建AI平臺

Volcano社區發展介紹

批量計算發展歷程

HPC、大數據、AI批量計算的發展歷程和趨勢

如上圖有三條主線，代表了批量計算的三個主要場景，

最早是在HPC這個領域，這個領域從90年代誕生到現在，主要的公司基本都是以B原為主的。在2018年的時候，HPC和AI開始進行了一定的融合，一些AI領域的應用可以應用到HPC領域中去。HPC的一些技術也可以給AI領域提供幫助。隨著K8s的發展和成熟，HPC也開始擁抱K8s。在2020年的vhpc大會上，也在研討如何把HPC應用更好的部署到k8s上去運行。

另外在大數據領域，2012年和2014年是兩個重要的時間節點，2012年Hadoop將資源管理層和上面的領域框架進行了解耦，上層的領域框架就有機會發展自己的生態。目前Spark和Flink對K8s都提供了一些官方的支持。

AI領域的框架，像Tensorflow、Caffe2這些誕生的比較晚。所以目前來看，主要的AI框架對接的資源管理平臺都是K8s。K8s憑借它的一些優勢，比如環境的標準化、開放的生態、模塊化與擴展等等，讓越來越多的用戶比較認可K8s，也有越來越多的用戶希望將他們的批量計算任務對接到K8s平臺上面來，集中統一的管理。

這個趨勢將會帶來兩個主要的收益。

在技術站方面可以得到統一，不需要同時維護多個技術站，降低了公司維護和學習的成本。

可以將多種業務類型和資源池進行歸一，大大提升資源的整體利用率。

Kubernetes容器平臺已成為批量計算場景的主流

從各個領域的頭部公司的發展動態中可以看出，他們在逐漸的擁抱K8s ，K8s也成為HPC管理層的主流選擇。像歐洲原子能機構，歐洲生物學實驗室，他們已經基于容器和K8s來構建他們的批量計算平臺，云原生基金會也專門成立了興趣小組，來討論如何基于K8s讓批量計算任務運行得更好。

云原生批量計算面臨的關鍵挑戰

用戶把批量計算運行在K8s平臺上，還是會遇到很多挑戰，這里列出了主要幾方面的挑戰。

1. 作業管理缺失：

Pod級別調度，無法感知上層應用。

缺少作業概念、缺少完善的生命周期的管理。

缺少任務依賴、作業依賴支持。

2. 調度策略局限

不支持Gang-Scheduling、Fairshaing scheduling。

不支持多場景的Resource reservation，backfill。

不支持CPU/IO topology based scheduling。

3. 領域計算框架支持不足

1:1的operator部署運維復雜。

不同框架對作業管理、并行計算等要求不同。

計算密集，資源波動大，需要高級調度能力。

4. 資源規劃復用、異構計算支持不足

缺少隊列概念。

不支持集群資源的動態規劃以及資源復用。

對異構資源支持不足

Volcano幫助批量計算面對云原生的各種挑戰

針對上面遇到的這些挑戰，希望Volcano基于K8s做最好的云原生批量計算平臺。Volcano在2019年6月份的時候正式進行了開源，在去年4月份捐獻給了云原生基金會，成為了CNCF的官方項目。Volcano社區大概每3個月發布一個版本，社區的活躍度上面貢獻者已經超過了120人。

Volcano幫助批量計算面對云原生的各種挑戰

Volcano和上游領域的框架進行了充分的合作，目前已經支持了主流的計算平臺，比如大數據領域的Spark和Flink，AI領域的像TensorFlow、mxnet等都和Volcano進行了完美的結合。另外像OPEN MPI、argo也都和Volcano進行了集成。

上圖可以看到，Volcano不只是一個調度器，除了scheduler還有job、Queue這種controller來進行豐富的作業生命周期管理。

Volcano項目介紹與關鍵特性

Volcano總體架構和優勢

Volcano不僅有調度器，還有控制器。在調度器層面，提供了很多子系統，比如調度策略子系統，可以以插件的方式支持用戶熱插拔各種的調度策略；資源規劃子系統，可以提供級聯的隊列能力，資源共享和隔離功能；性能子系統，包含了資源和作業的catch信息；還擴展聯邦調度子系統，支持多集群的作業調度。

關于Volcano的8大優勢，在用戶實際生產環境中得到了充分的驗證：

高性能：提供隊列調度、優先級調度、搶占、裝箱、資源預留、拓撲調度等豐富的調度策略，在多種場景下提升應用性能。

智能混合調度：支持在線、離線混合部署調度，提高整體資源利用效率。

應用感知：應用感知類型和特點，針對大數據、AI、HPC負載提供完善的生命周期管理。

集群聯邦調度：支持多集群調度和作業分發，滿足效率優先、成本優先等不同的場景訴求。

大規模：支持大規模集群調度，單集群規模支持1萬節點，100萬容器。

高擴展：插件化算法集成框架，提供兩級插件擴展，方便二次開發，滿足不同場景訴求。

易運維：Volcano作業提供統一接口，避免過多Operator帶來的繁雜管理。

社區成熟：CNCF收個批量計算平臺，已支持眾多的主流AI、大數據、高性能計算框架，眾多用戶已用于生產環境。

分布式訓練場景、大數據場景性能提升30%

下面結合一些使用場景和案例來介紹一下，Volcano在用戶的生產環境中所帶來的好處。

第一個場景就是在AI分布式和大數據中最普遍遇到的場景，也就是Volcano首先要解決的批量調度的問題。在AI的分布式訓練和大數據場景下，需要調度器以作業為單位進行整體的調度，而K8s默認的調度器目前只能以 Pod的方式去進行調度的。Pod的只是作業的一部分，在資源緊張的多作業調度情況下，K8s的調度很容易出現多個AI訓練作業或者Spark作業都只有一部分Pod的成功調度了。部分Pod由于缺少資源判定，在AI訓練作業和Spark作業這種場景下面，就是作業之間的盲導和思索。

AI分布式訓練場景

Volcano特有的Gang-Scheduling，這種調度策略可以使調度器以作業為力度，整體的去申請資源，從而達到作業可以整體的運行的效果。解決了由于資源不足而導致作業之間盲道和死鎖的這種情況。

上圖可以看出，紅色的是kubeflow加k8s的默認調度器運行case的執行時間，藍色的是使用Volcano調度器來執行的時間。在最壞的情況下，看到 volcano和K8s默認調度器執行作業都是24分鐘，而在資源不足的像k12和k13當中，Volcano相比較K8s的默認調度器有了30%的性能提升。

上圖是Volcano提供的作業拓撲和IO感知的調度策略。使用作業拓撲和IO感知，可以極大的降低作業的整體運行時間。

大數據場景

上圖是大數據TPC-DS性能測試，由于minResource的策略可以解決在高并發場景下Spark driver和executor資源的競爭問題，合理的規劃并行動，從而使整個作業的執行時間提升30%。可以看到紅色的圓點代表Volcano運行的作業，藍色的是K8s默認調度器運行的作業，橫坐標是作業的啟動時間，縱坐標是運行時間，可以看出Volcano作業啟動的時間更早，整體運行時間更快。

關鍵特性：基于Volcano Job運行MPI

上圖左邊是MPI的Volcano Job的一個定義，右邊展示了Volcano創建這個作業時候所做的工作。

Kind是一個job類型的，它的apiVersion是batch.volcano.sh，是k8s自定義的一種CRD，區別于k8s自帶的這種Job類型。在Spark里定義了minAvailable這個字段，這個字段意味著Job至少要得到三個pod的資源才會去調度下發，體現了這種作業的Gang的這種特性。再往下是schedulerName，這個作業使用的是Volcano來進行調度的，Volcano提供了三種內置的plugins，在這個例子里使用了其中的兩種ssh和svc。

ssh插件提供了作業內部Pod之間的ssh互信，如果這個工作交由用戶來做的話就會比較麻煩。需要在Pod啟動之后，邏輯運行之前去配置Pod的ssh互信。現在Volcano提供了sss插件，來幫助用戶在平臺層面做了這件事，這對于MPI的作業來說是非常必要的。

svc插件會為每個作業創建一個highly service，用來幫助pod之間使用pod名字來進行訪問。同時Volcano也提供了作業級別的和task級別的policies，來進行job和task的生命周期管理。比如用戶可以定義在什么事件觸發的時候，啟動job重啟的這個策略，什么事件觸發了叫做結束的這個策略。另外一個比較重要的就是tasks，這個字段的描述。Volcano job是支持多pod模板的，所以在tasks里邊可以定義多種類型的task，每一種類型的task就是一種Pod，多種task共同構成了一個完整的job。

關鍵特性：資源共享、多種級別的公平調度

隊列廣泛用于共享彈性工作負載和批處理工作負載資源池中。隊列的主要目的：

對于不同的租戶或者資源池之間的共享資源。

為不同的租戶和資源支持不同的調度策略。

這些功能其實還可以通過層級隊列的方式進一步擴展。隊列在Volcano中是一個集群范圍的CRD，當前版本還不支持層級隊列這個功能，預計會在未來的1~2個版本中就會提供。

它的特點如下：

相比于Namespace來說，隊列更加靈活，它不僅支持靜態配置capacity，還支持著多隊列之間的動態的比例配置。

動態配置可以支持隊列之間的資源租借與共享。當一個隊列的workload比較低的時候，可以把應得的資源進行借出，當隊列的workload漲上來的時候，可以把借出的資源進行回收。

Volcano還提供了多維度的公平調度，補齊了現在亞爾和麥克斯中都有的DRF調度策略，提供了namespace級別的工程調度。

關鍵特性：IOAware降低分布式訓練傳輸時延

K8s的調度器并沒有lO感知的能力，對于1個包含2ps+4workers的tensflow作業來說，可能會出現上圖中的三種節點的Pod分布方式。對于ps和worker有大量數據傳輸的訓練作業來說， 第三種ps和worker的均勻分布的調度結構是比較好的，因為這樣可以最大化使用節點內部的帶寬來進行數據傳輸。

上圖是在一個Vgg16模型上測試的案例。多次的測試結果中顯示前兩種調度策略作業的運行波動時間比較大，就是因為想要調度出最佳的pod分布。當采用IOAware這種調度策略之后，它就會比較穩定，作業運行的時間也會整體的會更短。

關鍵特性：NUMA Aware調度策略

首先來講一講場景和訴求：

針對一些計算密集型的對性能要求比較高的AI訓練任務，用戶希望容器可以獨占CPU來減少CPU共享導致的上下文的切換的這種損耗。

對于運行在NUMA架構上處理器的任務，也希望容器獨占多個位于同一個NUMA node上的CPU盒，減少通訊之間的損耗，來提升整體的一個訓練的一個性能。

K8s引入了 topology manager和CPU manager等組件提供節點上面的資源分配和拓撲調動。

但是這種特性都是工作在節點上面的，存在一些局限性。比如調度器不支持拓撲感知的能力，不支持這個節點的CPU topology和資源分配。因此容器可能會由于節點資源不滿足topology manager這種調度策略，導致在節點上被攔截，最終導致調度失敗。另外一個是上述描述的管理器都是運行在節點上面的，并不能為作業提供優選的服務。為了解決這些局限性，Volcano新增了NUMA Aware這種插件，以及NUMA info組建，提供了Pod的級別的拓撲策略，便于用戶靈活的結合自身的使用場景進行不同的客戶配置，具體關鍵技術如下：

NUMA info通過為節點創建CRD來上報更新節點NUMA的拓撲信息。

Volcano依據這些NUMA信息以及作業Pod需求來進行NUMA的親和性調度，避免了默認調度器調度Pod之后被攔截的問題。

關鍵特性：在線、離線混合調度、資源超賣

多種業務類型的混合部署在近些年是非常熱門的一個話題。在線的web服務和離線的分析業務有著各自不同的特點。在線業務需要的資源相對較少，但是對時延有嚴格的要求。比如推薦業務、廣告業務等，同時又有波峰波谷的特性。離線分析的業務計算量比較大，占用的資源比較多，使用的資源比較穩定，但是不需要對任務進行迅速的響應。

如果可以把在線業務和離線業務進行混合部署，就可以充分的實現資源的復用，削峰填谷，提升整體的資源使用率。另外一個就是資源超賣，在真實的使用場景中，用戶往往為了業務的穩定性，會為Pod申請過多的資源，而K8s調度器是依賴于用戶的靜態request輸入來進行調度的，這樣會造成集群的分配率比較高，使用率低， CPU平均資源使用率不到15%，造成了巨大的資源浪費。

Volcano在資源超賣和業務穩步這兩個方面進行了相應的研究。

QoS-feature：歐拉OS對QoS場景支持能力。

Kubelet：添加對QoS模型的支持，支持實時上報、計算超賣資源，作業驅逐。

Scheduler：集群調度器，添加對QoS模型的支持，在統一資源模型下支持多類型業務場景。

Volcano助力客戶構建AI平臺

某內容電商：Volcano優化AI訓練平臺

這個案例是一個月活數超過1億的內容社區用戶，每天大概有幾十萬篇的筆記投稿，上百億次筆記曝光，用戶是一個比較新的公司，沒有基站的機房，所有的服務器是買云廠商的云服務，而且大多數服務都是通過K8s來進行管理的。用戶有兩個重要的平臺，一個是內部的流量計算平臺，主要是用來管理實時的標簽計算，以及這種在線學習的Flink任務。還有一個是機器學習平臺，它主要的是管理機器學習的任務，他們承載了像TCL開發的一些模型訓練。

那么如何將這些任務呢調度到k8s集群上？其實原生的k8s對這種場景存在一個比較大的問題，它是基于單pod來進行調度的，經常會遇到作業死鎖的問題。用戶基于這個痛點做了一些調研，發現Volcano可以解決這些痛點，用戶最終加入volcano社區當中，客戶在使用Volcano提供了增強了task，托福調度算法，使AI的訓練性能的整體提升了一個20%，同時使用我們提供的srv的調度策略，來避免大作業餓死的這種現象。

某投資公司：基于Volcano構建大規模計算平臺

這個案例是一個金融客戶，隨著公司規模的擴大，公司的策略人員在使用環境也在不斷的變化，對于不同的研究環境促使用戶開始使用容器技術來屏蔽多種環境因素所帶來的這種困擾。隨著k8s社區的成熟與穩定，在計算集群中使用容器技術幾乎就等同于使用k8s，但是原生的k8s調度器并沒有提供批處理任務的調度能力，也缺乏團隊之間的這種資源共享，公平調度的這種機制。

某視屏網站：Volcano構建AI訓練平臺

這是一個國內排名在Top3之內的某視頻網站使用我看到的一個場景，他們構建自己的 Java4的深度學習平臺，支持了TensorfFlow、PyTorch、Caffe、Caffe2，MXNet等框架。其中以TensorfFlow和PyTorch為主，承載了公司的廣告搜索、推薦、NLP等業務。他們的容器平臺因為起步比較早，一開始使用的是MESOS加馬拉松，作為他們的容器平臺，當K8s社區成為云原生應用的編排管理實施標準之后，用戶開始把 AI容器業務呢從MESOS加馬拉松遷移至K8s加Volcano上面來。訓練平臺在遷移到K8s的主要過程中遇到了三方面的挑戰：

原生的Pod/Deployment/Job無法滿足分布式訓練要求。

無隊列管理、配額管理能力。

對于Gang Scheduling這種調度能力的缺失。

實際上Volcano對于用戶來說，最重要的就是這么幾個概念：

提供了Volcano job，可以簡單的理解成是對K8s job的擴展，或者說是對Pod的封裝。

在隊列上可以分配一些配額，可以做一些隊列的管理。

有了Pod集合這種概念，可以做一些更高級的上層的調度策略。

客戶之所以選擇Volcano，是因為Volcano高度符合AI訓練場景，另外Volcano不侵入k8s源碼，符合k8s的開發規范，簡單來說就是方便客戶的二次開發。還有一點就是Volcano項目，加入了CNCF，成熟度相對來說是比較高的。目前Volcano已經在客戶的生產環境中穩定運行了一年以上。

Volcano社區發展變化

眾多企業、機構積極參與社區貢獻

Volcano可以幫助客戶在云原生的環境下更好的運行批量計算任務，同時達到降本增效的目的。使用Volcano的用戶分布在各個領域， Volcano的使用場景變的是越來越多，遍布的行業也越來越廣，這個是Volcano目前發展的一個狀況。項目現在有1900多顆星，120多位的貢獻者。

上圖也可以看出，雖然Volcano是華為捐獻給CNCF基金會的，但是現在獨立的貢獻者已經接近50%了。

社區版本發布

上圖是Volcano社區成立以來呢現在 release的一些主要的版本，希望有更多的開發者和用戶加入到Volcano社區，使用Volcano產品。

本文整理自【內容共創系列】1024，懂你所需，予你溫暖，致敬新時代可愛的程序員們

查看活動詳情：https://bbs.huaweicloud.com/blogs/302011

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。