摘 要
為實現(xiàn)算力和網(wǎng)絡(luò)資源的統(tǒng)一納管和融合路由調(diào)度,業(yè)界已經(jīng)進行了積極的研究和探索,并推動制定了算網(wǎng)融合的整體框架,具體的技術(shù)和標(biāo)準(zhǔn)也在研究和制定,但由于涉及到異構(gòu)算力的統(tǒng)一度量和算力交易等流程,實現(xiàn)復(fù)雜度較高,建議基于現(xiàn)有云、算側(cè)和網(wǎng)側(cè)的調(diào)度系統(tǒng)以及SRv6、APN、CFN、RDMA等關(guān)鍵技術(shù),采用邊研究邊實踐的策略,分3個階段逐步推進,最終實現(xiàn)算網(wǎng)融合的目標(biāo)架構(gòu)。
引 言
“東數(shù)西算”工程是我國為促進信息基礎(chǔ)設(shè)施優(yōu)化升級、推動數(shù)字經(jīng)濟加速發(fā)展而提出的一項重大戰(zhàn)略工程,而“東數(shù)西算”工程要實現(xiàn)算力全國調(diào)度,就需要算網(wǎng)融合的支撐。所謂算網(wǎng)融合,是以通信網(wǎng)絡(luò)設(shè)施和計算設(shè)施的融合發(fā)展為基礎(chǔ),通過計算、存儲及網(wǎng)絡(luò)資源統(tǒng)一編排管控,滿足業(yè)務(wù)對網(wǎng)絡(luò)和算力靈活泛在、彈性敏捷需求的一種新型業(yè)務(wù)模式。在此背景下,算網(wǎng)融合的架構(gòu)和技術(shù)成為業(yè)界研究熱點。
0 1
算網(wǎng)已有架構(gòu)和調(diào)度技術(shù)分析
1.1 算網(wǎng)融合是實現(xiàn)云、算、網(wǎng)資源的統(tǒng)一管理和調(diào)度
算網(wǎng)融合本質(zhì)上希望打破云計算、存儲資源和網(wǎng)絡(luò)資源各自獨立、無法協(xié)同的現(xiàn)狀。運營主體和服務(wù)方式方面,算網(wǎng)融合的運營者除電信運營商之外,還有云廠商和第三方企業(yè);運營者可提供多樣化網(wǎng)絡(luò)接入,具備算力感知、一體化管理和編排調(diào)度能力,可實現(xiàn)算網(wǎng)服務(wù)的彈性供給、自主定制、隨需交易;支撐技術(shù)方面,算網(wǎng)融合既需要SDN、NFV以及轉(zhuǎn)發(fā)面的VxLAN、EVPN、SR/SRv6等現(xiàn)有技術(shù)的增強,也需要新技術(shù)如算網(wǎng)統(tǒng)一度量和交易、編排調(diào)度、算力資源發(fā)布以及APN6、CFN、RDMA等技術(shù)的支撐。
1.2 云、算側(cè)資源管理與調(diào)度架構(gòu)
隨著以容器和微服務(wù)為代表的云原生技術(shù)的發(fā)展,算力資源統(tǒng)一管理和調(diào)度技術(shù)成為目前行業(yè)研究熱點,當(dāng)前應(yīng)用較多的算力調(diào)度系統(tǒng)以超算和HPC的資源調(diào)度為主,主要有IBM公司的LFS、Altair公司的PBS pro以及開源的Slurm等。面向大模型訓(xùn)練等智算場景,微軟在其CycleCloud上將超算算力調(diào)度系統(tǒng)和云的Kubernetes進行結(jié)合,為用戶提供可專用于AI大模型訓(xùn)練的環(huán)境。此外國內(nèi)企業(yè)也已經(jīng)開始了對算力調(diào)度系統(tǒng)的研究,并推出了如Quick Pool、SkyForm等產(chǎn)品。Slurm在科研機構(gòu)和院校中應(yīng)用較多,其架構(gòu)如圖1所示,采用Slurmctld服務(wù)監(jiān)測資源和作業(yè)。各計算節(jié)點啟動Slurmd守護進程,被作為遠(yuǎn)程shell使用(等待作業(yè)、執(zhí)行作業(yè)、返回狀態(tài)、再等待更多作業(yè))。
圖1 Slurm架構(gòu)
SlurmDBD(Slurm DataBase Daemon)數(shù)據(jù)庫守護進程,將多個Slurm管理的集群的記賬信息記錄在同一個數(shù)據(jù)庫中。用戶可以使用一系列命令工具如Srun(運行作業(yè))等對作業(yè)進行管理。另外還可以通過Slurmrestd(Slurm REST API Daemon)服務(wù),使用REST API與Slurm進行交互。節(jié)點是Slurm調(diào)度的單位之一,每個節(jié)點都有自己的資源,如CPU、內(nèi)存、GPU等。節(jié)點由Slurm自動分配給作業(yè),通常只需要用戶指定數(shù)量。但如果有特別的需要,用戶也可以直接給定節(jié)點列表或者用參數(shù)排除一些節(jié)點。
Kubernetes也是一個開源平臺,用于管理容器化的工作負(fù)載和服務(wù),在大規(guī)模集群的資源管理中應(yīng)用廣泛(見圖2)。Pod是在Kubernetes集群中運行部署應(yīng)用或服務(wù)的最小單元,可支持多容器。Node節(jié)點主要作為計算節(jié)點,實現(xiàn)本地Pod的部署運行和相關(guān)計算、存儲和網(wǎng)絡(luò)資源的納管。在Kubernetes中,通過調(diào)度將Pod放置到合適的Node節(jié)點上,調(diào)度器通過Kubernetes的監(jiān)測機制來發(fā)現(xiàn)集群中尚未被調(diào)度到節(jié)點上的Pod。它會依據(jù)提前設(shè)置的調(diào)度原則來做出調(diào)度選擇。kube-scheduler是Kubernetes集群的默認(rèn)調(diào)度器。
圖2 Kubernetes集群的組件
kube-scheduler給一個Pod做調(diào)度選擇時包含過濾和打分2個步驟,其中過濾階段會過濾掉候選節(jié)點中不滿足可用資源需求的節(jié)點,形成可調(diào)度節(jié)點列表,而打分階段,調(diào)度器會根據(jù)預(yù)設(shè)的打分規(guī)則為每一個可調(diào)度節(jié)點打分,最終選出一個最合適的節(jié)點來運行Pod。在做調(diào)度決定時需要考慮的因素包括單獨和整體的資源請求、硬件/軟件/策略限制、親和以及反親和要求、數(shù)據(jù)局部性、負(fù)載間的干擾等。
1.3 網(wǎng)側(cè)資源管理與調(diào)度架構(gòu)
VxLAN+EVPN方案是數(shù)據(jù)中心網(wǎng)絡(luò)的重要部署方案。VxLAN技術(shù)通過將原始報文封裝在UDP報文中,可以將傳統(tǒng)的二層網(wǎng)絡(luò)擴展到三層網(wǎng)絡(luò),實現(xiàn)數(shù)據(jù)中心網(wǎng)絡(luò)的虛擬化,提高網(wǎng)絡(luò)的可擴展性和靈活性。EVPN技術(shù)則是一種基于BGP的以太網(wǎng)虛擬專用網(wǎng)技術(shù),利用EVPN構(gòu)建VxLAN的控制平面,解決VxLAN需要通過泛洪的方式學(xué)習(xí)終端主機地址的問題,從而提供跨數(shù)據(jù)中心的數(shù)據(jù)傳輸和VPN服務(wù)。
同時,VxLAN和SDN聯(lián)合部署已經(jīng)成為智能化云數(shù)據(jù)中心的必要組件,VxLAN作為數(shù)據(jù)平面解耦租戶網(wǎng)絡(luò)和物理網(wǎng)絡(luò),SDN將租戶的控制能力集成到云管平臺,與計算、存儲資源聯(lián)合調(diào)度,提升了數(shù)據(jù)中心內(nèi)業(yè)務(wù)承載的靈活性(見圖3)。
圖3 SDN+VxLAN數(shù)據(jù)中心網(wǎng)絡(luò)承載方案
1.4 小結(jié)
云、算側(cè)算力調(diào)度系統(tǒng)實現(xiàn)了集群內(nèi)算力任務(wù)和容器化資源的調(diào)度管理,在進行負(fù)載均衡時可以考慮CPU、內(nèi)存和網(wǎng)絡(luò)帶寬利用率等因素,并且通過調(diào)度算法的不斷優(yōu)化,使得集群內(nèi)節(jié)點的利用率更高,但是這里的網(wǎng)絡(luò)資源信息還相對粗放,沒有精確的帶寬、時延等信息,使得用戶獲取到的算力服務(wù)路徑不一定是最優(yōu)路徑,這個問題同樣存在于DNS域名解析服務(wù)器進行終端請求的應(yīng)答過程中。
在網(wǎng)絡(luò)側(cè),VxLAN+EVPN作為Overlay的方案,較好地解決了數(shù)據(jù)中心間虛機遷移的問題,但同時也存在無法支撐將Underlay網(wǎng)絡(luò)資源的信息與算力資源信息融合到一起進行調(diào)度的問題,所以為了更好地支撐算網(wǎng)融合,需要SRv6等更具有潛力的網(wǎng)絡(luò)技術(shù)。另外,針對AI分布式訓(xùn)練和HPC高性能計算場景,RDMA技術(shù)也已經(jīng)被廣泛應(yīng)用于智算集群內(nèi)的互聯(lián)。
0 2
算網(wǎng)融合目標(biāo)架構(gòu)和關(guān)鍵技術(shù)分析
2.1 整體目標(biāo)架構(gòu)相關(guān)標(biāo)準(zhǔn)進展
中國三大運營商、設(shè)備商、服務(wù)器廠商等在CCSA立項了《算力網(wǎng)絡(luò)總體技術(shù)要求》,目前已完成報批稿,主要規(guī)定了算力網(wǎng)絡(luò)的總體技術(shù)架構(gòu)和技術(shù)要求,包括算力網(wǎng)絡(luò)的總體架構(gòu)和接口描述,以及算力服務(wù)技術(shù)要求、算力路由技術(shù)要求、算網(wǎng)編排管理技術(shù)要求等,其中算力網(wǎng)絡(luò)總體功能邏輯架構(gòu)如圖4所示。
圖4 算力網(wǎng)絡(luò)總體功能邏輯架構(gòu)
為了實現(xiàn)對算力和網(wǎng)絡(luò)的感知、互聯(lián)和協(xié)同調(diào)度,算力網(wǎng)絡(luò)架構(gòu)體系從邏輯功能上劃分為算力服務(wù)層、算力路由層、算網(wǎng)管理層、算網(wǎng)基礎(chǔ)設(shè)施層四大功能模塊,具體如下。
a)算力服務(wù)層。提供算力的各類能力及應(yīng)用,并將用戶對業(yè)務(wù)SLA的請求(包括算力請求等參數(shù))傳遞給算力路由層。
b)算力路由層?;诔橄蠛蟮挠嬎阗Y源發(fā)現(xiàn),實現(xiàn)對算力節(jié)點的資源信息感知;另一方面,通過在用戶請求中攜帶業(yè)務(wù)需求,實現(xiàn)對用戶業(yè)務(wù)需求的感知。綜合考慮用戶業(yè)務(wù)請求、網(wǎng)絡(luò)信息和算力資源信息,將業(yè)務(wù)靈活按需調(diào)度到不同的算力節(jié)點中,同時將計算結(jié)果反饋到算力服務(wù)層。算力路由層的部署實現(xiàn)支持集中式方式和分布式方式。
c)算網(wǎng)編排管理層。實現(xiàn)對算力服務(wù)的運營與編排管理、對算力路由的管理、對算力資源的管理以及對網(wǎng)絡(luò)資源的管理,其中算力資源管理包括基于統(tǒng)一的算力度量衡體系,完成對算力資源的統(tǒng)一抽象描述,進而實現(xiàn)對算力資源的度量與建模、注冊和OAM管理等功能;以支持網(wǎng)絡(luò)對算力資源的可感知、可度量、可管理和可控制。
d)算網(wǎng)基礎(chǔ)設(shè)施層。為滿足新興業(yè)務(wù)的多樣性計算需求,基于提供信息傳輸?shù)木W(wǎng)絡(luò)基礎(chǔ)設(shè)施,在網(wǎng)絡(luò)中提供泛在異構(gòu)計算資源,包括單核CPU、多核CPU、CPU+GPU+FPGA等多種算力組合。其中算網(wǎng)基礎(chǔ)設(shè)施層作為算力網(wǎng)絡(luò)的新型基礎(chǔ)設(shè)施層,算力服務(wù)層、算力路由層和算網(wǎng)編排管理層作為實現(xiàn)算力網(wǎng)絡(luò)可感、可控、可管的三大核心功能模塊,實現(xiàn)對算力和網(wǎng)絡(luò)資源的感知、控制和管理。
2.2 支撐算力運營和交易的關(guān)鍵技術(shù)
2.2.1 算力資源建模,包含算力度量、算力分級等
算力是設(shè)備或平臺為完成某種業(yè)務(wù)所具備的處理業(yè)務(wù)信息的關(guān)鍵核心能力,根據(jù)所運行算法和所涉及的數(shù)據(jù)計算類型不同,可將算力分為邏輯運算能力、并行計算能力和神經(jīng)網(wǎng)絡(luò)計算能力。算力的統(tǒng)一量化是算力調(diào)度、使用的基礎(chǔ)。對不同的計算類型,不同廠商的芯片有各自不同的設(shè)計,這就涉及異構(gòu)算力的統(tǒng)一度量。不同芯片所提供的算力可通過度量函數(shù)映射到統(tǒng)一的量綱。
算力分級可以供算力提供者設(shè)計業(yè)務(wù)套餐時參考,也可作為算力平臺設(shè)計者在設(shè)計算力網(wǎng)絡(luò)平臺時對算力資源的選型依據(jù)。智能應(yīng)用對算力的訴求主要是浮點計算能力,因此業(yè)務(wù)所需浮點計算能力的大小可作為算力分級的依據(jù)。當(dāng)前算力可分為超大型算力、大型算力、中型算力和小型算力4個等級。
2.2.2 算力交易
泛在計算的算力交易平臺是一套基于區(qū)塊鏈的去中心化、低成本、保護隱私的可信平臺。平臺的計算節(jié)點由多種形態(tài)的算力設(shè)備組成,包含大型GPU設(shè)備或FPGA服務(wù)器集群、中小型企業(yè)閑散的空余服務(wù)器及個人閑置的計算節(jié)點等。平臺可以實現(xiàn)自動算力交易、自動算力匹配、費用結(jié)算功能。在算力賣家向算力買家提供服務(wù)的過程中,后者提出使用請求,算力交易平臺根據(jù)用戶需求自動尋找、匹配算力節(jié)點,并生成相應(yīng)的賬單;在得到買家認(rèn)可后,平臺調(diào)度相應(yīng)的算力資源為買家提供服務(wù),隨后執(zhí)行算力業(yè)務(wù)的節(jié)點根據(jù)提供的算力獲得相應(yīng)的報酬。
2.3 支撐算網(wǎng)資源融合管理調(diào)度的關(guān)鍵技術(shù)
2.3.1 算網(wǎng)轉(zhuǎn)發(fā)技術(shù)——SRv6
SRv6是源路由技術(shù)的一種,它采用現(xiàn)有的IPv6轉(zhuǎn)發(fā)技術(shù),通過靈活的IPv6擴展頭,實現(xiàn)網(wǎng)絡(luò)可編程。
為了實現(xiàn)SRv6轉(zhuǎn)發(fā),需要向IPv6報文中插入一個段路由頭(Segment Routing Header,SRH)的擴展頭,存儲IPv6的Segment List信息。報文轉(zhuǎn)發(fā)時,依靠Segments Left和Segment List字段共同決定IPv6目的地址(IPv6 DA)信息,從而指導(dǎo)報文的轉(zhuǎn)發(fā)路徑和行為。未經(jīng)壓縮的SRv6 SID是128位,主要由標(biāo)識節(jié)點位置的LOC字段(IPv6前綴格式,可路由)、標(biāo)識服務(wù)和功能的FUNC字段(本地識別)以及ARG字段3個部分組成。
SRv6網(wǎng)絡(luò)編程標(biāo)準(zhǔn)中,SRv6節(jié)點(Endpoint)通過本地定義的行為(Behavior)處理SRv6報文。SRv6定義了多種Endpoint Behavior,每個節(jié)點需要實例化它們并分配SID,同時通過路由協(xié)議發(fā)布,以通知其他SRv6節(jié)點本節(jié)點能提供的Behavior。常用的Endpoint Behavior有END、END.X、END.DT4、END.DT6等,實現(xiàn)Underlay選路、Overlay業(yè)務(wù)承載等功能。
2.3.2 算網(wǎng)感知技術(shù)——APN6
APN6是在數(shù)據(jù)平面利用IPv6報文擴展頭(Extension Headers),如逐跳選項頭(Hop-by-Hop Options Header)、段路由頭(Segment Routing Header)的可編程空間,攜帶應(yīng)用的相關(guān)信息(標(biāo)識和需求)到網(wǎng)絡(luò)中,網(wǎng)絡(luò)設(shè)備依據(jù)這些信息為其提供相應(yīng)的網(wǎng)絡(luò)服務(wù),如將報文映射進相應(yīng)的能夠保障其SLA的SRv6路徑等。應(yīng)用感知信息可以由用戶終端設(shè)備或應(yīng)用直接生成,也可以由網(wǎng)絡(luò)邊緣設(shè)備生成,分別對應(yīng)APN6的主機側(cè)方案和網(wǎng)絡(luò)側(cè)方案。
2.3.3 算網(wǎng)融合路由技術(shù)——CFN
為了解決邊緣計算系統(tǒng)中網(wǎng)絡(luò)信息和算力信息割裂,無法統(tǒng)一納管和進行最優(yōu)資源調(diào)度的問題,Yizhou Li等提出了CFN的概念,并在IETF提交了草案:Framework of Compute First Networking(CFN),架構(gòu)和原理如圖5所示。
圖5 CFN網(wǎng)絡(luò)拓?fù)?/strong>
CFN網(wǎng)絡(luò)按角色分為服務(wù)器節(jié)點、CFN節(jié)點和客戶端。CFN通過控制面完成算力資源信息的全網(wǎng)同步。服務(wù)節(jié)點將本地服務(wù)狀態(tài)注冊到CFN節(jié)點的數(shù)據(jù)庫表項中。本地服務(wù)狀態(tài)一般包括服務(wù)的唯一標(biāo)識(Service ID)、服務(wù)IP地址和計算資源情況等。CFN節(jié)點將本地服務(wù)狀態(tài)封裝到CFN路由協(xié)議報文中并擴散到其他CFN節(jié)點。CFN節(jié)點基于CFN路由協(xié)議將本地以及收到的其他CFN節(jié)點擴散的服務(wù)狀態(tài)信息匯總生成服務(wù)信息路由表。CFN數(shù)據(jù)面完成客戶端對服務(wù)節(jié)點Service ID請求的路由轉(zhuǎn)發(fā)。與客戶端距離最近的CFN節(jié)點收到請求后,根據(jù)網(wǎng)絡(luò)資源、計算資源情況進行綜合評估,選擇一個服務(wù)節(jié)點以及相關(guān)聯(lián)的CFN出口節(jié)點,將原請求數(shù)據(jù)包封裝并發(fā)送。
CFN Egress節(jié)點收到數(shù)據(jù)包,根據(jù)Service ID查找對應(yīng)服務(wù)節(jié)點IP,將數(shù)據(jù)封裝并發(fā)送。外層數(shù)據(jù)包源地址為客戶端IP,目的地址為服務(wù)節(jié)點IP。報文封裝的內(nèi)層數(shù)據(jù)包源地址為客戶端IP,目的地址為Service ID。服務(wù)節(jié)點收到數(shù)據(jù)包后在本地查詢與Service ID綁定的服務(wù)地址,調(diào)用對應(yīng)的服務(wù),將結(jié)果返回給客戶端。
0 3
結(jié)束語
在我國提出“東數(shù)西算”的大背景下,我國電信運營商希望借助政策發(fā)展的契機,在售賣網(wǎng)絡(luò)管道和出租數(shù)據(jù)中心基礎(chǔ)資源的同時,釋放更多的管道潛能,所以積極投入算力與網(wǎng)絡(luò)相融合的研究中,并在國際、國內(nèi)標(biāo)準(zhǔn)組織推動制定了一系列算網(wǎng)融合的標(biāo)準(zhǔn)架構(gòu)。但要真正實現(xiàn)算網(wǎng)融合的規(guī)模商用,無論是商業(yè)模式還是技術(shù)實現(xiàn)細(xì)節(jié)上都還存在較大差距。上述標(biāo)準(zhǔn)框架中,目標(biāo)架構(gòu)和業(yè)務(wù)流程都比較完善,但同時這種非常完善的架構(gòu)也會帶來系統(tǒng)復(fù)雜度的大幅增加。由于要將CPU、GPU、FPGA以及內(nèi)存和存儲等異構(gòu)算力資源進行歸一化度量,需要研究算力的度量標(biāo)準(zhǔn);另外,還需要建設(shè)算力交易平臺,解決算力的交易問題并進行標(biāo)準(zhǔn)化。從實現(xiàn)路徑上,建議基于現(xiàn)有云、算側(cè)和網(wǎng)側(cè)的調(diào)度系統(tǒng)和SRv6、APN和CFN、
RDMA等關(guān)鍵技術(shù),采用邊研究邊實踐的策略,分3個階段逐步推進。
第1階段:單運營商場景。運營商內(nèi)部負(fù)責(zé)云和網(wǎng)絡(luò)的運營團隊間不考慮算力資源交易和結(jié)算流程,這樣一方面簡化了算力運營和交易相關(guān)平臺的實現(xiàn),另一方面,從流程上簡化了算力需求者提出需求后,在進行算力資源匹配后交易確認(rèn)環(huán)節(jié)引入的處理時延。算力資源池也限制運營商的自有資源,減少資源種類,更易進行度量。
第2階段:單運營商、單云場景。運營商內(nèi)部負(fù)責(zé)云和網(wǎng)絡(luò)的運營團隊間,以及運營商和第三方云供應(yīng)商之間基于算力運營和交易平臺,實現(xiàn)了算力資源的交易和結(jié)算;算力資源池也拓展至本運營商的自有算力資源和第三方云供應(yīng)商的算力資源。
第3階段:多運營商、多云場景。不同運營商間、運營商與第三方云供應(yīng)商間都實現(xiàn)了算力運營和交易,運營商既可以是算力資源的購買者,也可以是算力資源的售賣者;同時,一些企業(yè)和個人終端的零散算力資源也可以進行交易。
作者簡介
李振文,工程師,主要從事5G承載、分組傳送、算力網(wǎng)絡(luò)等方面的研究工作;
李芳,教授級高級工程師,主要從事5G承載、分組傳送、算力網(wǎng)絡(luò)等方面的技術(shù)與標(biāo)準(zhǔn)研究工作;
趙俊峰,高級工程師,主要從事5G承載、分組傳送、確定性網(wǎng)絡(luò)、算力網(wǎng)絡(luò)等方面的技術(shù)與標(biāo)準(zhǔn)研究工作。
審核編輯:黃飛
-
云計算
+關(guān)注
關(guān)注
39文章
7808瀏覽量
137412 -
數(shù)據(jù)中心
+關(guān)注
關(guān)注
16文章
4778瀏覽量
72129 -
東數(shù)西算
+關(guān)注
關(guān)注
0文章
80瀏覽量
2696
原文標(biāo)題:算網(wǎng)融合關(guān)鍵技術(shù)和發(fā)展路徑研究
文章出處:【微信號:IndustryIOT,微信公眾號:工業(yè)互聯(lián)網(wǎng)前線】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論