算網融合目標架構和關鍵技術分析

摘 要

為實現算力和網絡資源的統一納管和融合路由調度，業界已經進行了積極的研究和探索，并推動制定了算網融合的整體框架，具體的技術和標準也在研究和制定，但由于涉及到異構算力的統一度量和算力交易等流程，實現復雜度較高，建議基于現有云、算側和網側的調度系統以及SRv6、APN、CFN、RDMA等關鍵技術，采用邊研究邊實踐的策略，分3個階段逐步推進，最終實現算網融合的目標架構。

引 言

“東數西算”工程是我國為促進信息基礎設施優化升級、推動數字經濟加速發展而提出的一項重大戰略工程，而“東數西算”工程要實現算力全國調度，就需要算網融合的支撐。所謂算網融合，是以通信網絡設施和計算設施的融合發展為基礎，通過計算、存儲及網絡資源統一編排管控，滿足業務對網絡和算力靈活泛在、彈性敏捷需求的一種新型業務模式。在此背景下，算網融合的架構和技術成為業界研究熱點。

0 1

算網已有架構和調度技術分析

1.1 算網融合是實現云、算、網資源的統一管理和調度

算網融合本質上希望打破云計算、存儲資源和網絡資源各自獨立、無法協同的現狀。運營主體和服務方式方面，算網融合的運營者除電信運營商之外，還有云廠商和第三方企業；運營者可提供多樣化網絡接入，具備算力感知、一體化管理和編排調度能力，可實現算網服務的彈性供給、自主定制、隨需交易；支撐技術方面，算網融合既需要SDN、NFV以及轉發面的VxLAN、EVPN、SR/SRv6等現有技術的增強，也需要新技術如算網統一度量和交易、編排調度、算力資源發布以及APN6、CFN、RDMA等技術的支撐。

1.2 云、算側資源管理與調度架構

隨著以容器和微服務為代表的云原生技術的發展，算力資源統一管理和調度技術成為目前行業研究熱點，當前應用較多的算力調度系統以超算和HPC的資源調度為主，主要有IBM公司的LFS、Altair公司的PBS pro以及開源的Slurm等。面向大模型訓練等智算場景，微軟在其CycleCloud上將超算算力調度系統和云的Kubernetes進行結合，為用戶提供可專用于AI大模型訓練的環境。此外國內企業也已經開始了對算力調度系統的研究，并推出了如Quick Pool、SkyForm等產品。Slurm在科研機構和院校中應用較多，其架構如圖1所示，采用Slurmctld服務監測資源和作業。各計算節點啟動Slurmd守護進程，被作為遠程shell使用（等待作業、執行作業、返回狀態、再等待更多作業）。

圖1 Slurm架構

SlurmDBD（Slurm DataBase Daemon）數據庫守護進程，將多個Slurm管理的集群的記賬信息記錄在同一個數據庫中。用戶可以使用一系列命令工具如Srun（運行作業）等對作業進行管理。另外還可以通過Slurmrestd（Slurm REST API Daemon）服務，使用REST API與Slurm進行交互。節點是Slurm調度的單位之一，每個節點都有自己的資源，如CPU、內存、GPU等。節點由Slurm自動分配給作業，通常只需要用戶指定數量。但如果有特別的需要，用戶也可以直接給定節點列表或者用參數排除一些節點。

Kubernetes也是一個開源平臺，用于管理容器化的工作負載和服務，在大規模集群的資源管理中應用廣泛（見圖2）。Pod是在Kubernetes集群中運行部署應用或服務的最小單元，可支持多容器。Node節點主要作為計算節點，實現本地Pod的部署運行和相關計算、存儲和網絡資源的納管。在Kubernetes中，通過調度將Pod放置到合適的Node節點上，調度器通過Kubernetes的監測機制來發現集群中尚未被調度到節點上的Pod。它會依據提前設置的調度原則來做出調度選擇。kube-scheduler是Kubernetes集群的默認調度器。

圖2 Kubernetes集群的組件

kube-scheduler給一個Pod做調度選擇時包含過濾和打分2個步驟，其中過濾階段會過濾掉候選節點中不滿足可用資源需求的節點，形成可調度節點列表，而打分階段，調度器會根據預設的打分規則為每一個可調度節點打分，最終選出一個最合適的節點來運行Pod。在做調度決定時需要考慮的因素包括單獨和整體的資源請求、硬件/軟件/策略限制、親和以及反親和要求、數據局部性、負載間的干擾等。

1.3 網側資源管理與調度架構

VxLAN+EVPN方案是數據中心網絡的重要部署方案。VxLAN技術通過將原始報文封裝在UDP報文中，可以將傳統的二層網絡擴展到三層網絡，實現數據中心網絡的虛擬化，提高網絡的可擴展性和靈活性。EVPN技術則是一種基于BGP的以太網虛擬專用網技術，利用EVPN構建VxLAN的控制平面，解決VxLAN需要通過泛洪的方式學習終端主機地址的問題，從而提供跨數據中心的數據傳輸和VPN服務。

同時，VxLAN和SDN聯合部署已經成為智能化云數據中心的必要組件，VxLAN作為數據平面解耦租戶網絡和物理網絡，SDN將租戶的控制能力集成到云管平臺，與計算、存儲資源聯合調度，提升了數據中心內業務承載的靈活性（見圖3）。

圖3 SDN+VxLAN數據中心網絡承載方案

1.4 小結

云、算側算力調度系統實現了集群內算力任務和容器化資源的調度管理，在進行負載均衡時可以考慮CPU、內存和網絡帶寬利用率等因素，并且通過調度算法的不斷優化，使得集群內節點的利用率更高，但是這里的網絡資源信息還相對粗放，沒有精確的帶寬、時延等信息，使得用戶獲取到的算力服務路徑不一定是最優路徑，這個問題同樣存在于DNS域名解析服務器進行終端請求的應答過程中。

在網絡側，VxLAN+EVPN作為Overlay的方案，較好地解決了數據中心間虛機遷移的問題，但同時也存在無法支撐將Underlay網絡資源的信息與算力資源信息融合到一起進行調度的問題，所以為了更好地支撐算網融合，需要SRv6等更具有潛力的網絡技術。另外，針對AI分布式訓練和HPC高性能計算場景，RDMA技術也已經被廣泛應用于智算集群內的互聯。

0 2

算網融合目標架構和關鍵技術分析

2.1 整體目標架構相關標準進展

中國三大運營商、設備商、服務器廠商等在CCSA立項了《算力網絡總體技術要求》，目前已完成報批稿，主要規定了算力網絡的總體技術架構和技術要求，包括算力網絡的總體架構和接口描述，以及算力服務技術要求、算力路由技術要求、算網編排管理技術要求等，其中算力網絡總體功能邏輯架構如圖4所示。

圖4 算力網絡總體功能邏輯架構

為了實現對算力和網絡的感知、互聯和協同調度，算力網絡架構體系從邏輯功能上劃分為算力服務層、算力路由層、算網管理層、算網基礎設施層四大功能模塊，具體如下。

a）算力服務層。提供算力的各類能力及應用，并將用戶對業務SLA的請求（包括算力請求等參數）傳遞給算力路由層。

b）算力路由層?；诔橄蠛蟮挠嬎阗Y源發現，實現對算力節點的資源信息感知；另一方面，通過在用戶請求中攜帶業務需求，實現對用戶業務需求的感知。綜合考慮用戶業務請求、網絡信息和算力資源信息，將業務靈活按需調度到不同的算力節點中，同時將計算結果反饋到算力服務層。算力路由層的部署實現支持集中式方式和分布式方式。

c）算網編排管理層。實現對算力服務的運營與編排管理、對算力路由的管理、對算力資源的管理以及對網絡資源的管理，其中算力資源管理包括基于統一的算力度量衡體系，完成對算力資源的統一抽象描述，進而實現對算力資源的度量與建模、注冊和OAM管理等功能；以支持網絡對算力資源的可感知、可度量、可管理和可控制。

d）算網基礎設施層。為滿足新興業務的多樣性計算需求，基于提供信息傳輸的網絡基礎設施，在網絡中提供泛在異構計算資源，包括單核CPU、多核CPU、CPU+GPU+FPGA等多種算力組合。其中算網基礎設施層作為算力網絡的新型基礎設施層，算力服務層、算力路由層和算網編排管理層作為實現算力網絡可感、可控、可管的三大核心功能模塊，實現對算力和網絡資源的感知、控制和管理。

2.2 支撐算力運營和交易的關鍵技術

2.2.1 算力資源建模，包含算力度量、算力分級等

算力是設備或平臺為完成某種業務所具備的處理業務信息的關鍵核心能力，根據所運行算法和所涉及的數據計算類型不同，可將算力分為邏輯運算能力、并行計算能力和神經網絡計算能力。算力的統一量化是算力調度、使用的基礎。對不同的計算類型，不同廠商的芯片有各自不同的設計，這就涉及異構算力的統一度量。不同芯片所提供的算力可通過度量函數映射到統一的量綱。

算力分級可以供算力提供者設計業務套餐時參考，也可作為算力平臺設計者在設計算力網絡平臺時對算力資源的選型依據。智能應用對算力的訴求主要是浮點計算能力，因此業務所需浮點計算能力的大小可作為算力分級的依據。當前算力可分為超大型算力、大型算力、中型算力和小型算力4個等級。

2.2.2 算力交易

泛在計算的算力交易平臺是一套基于區塊鏈的去中心化、低成本、保護隱私的可信平臺。平臺的計算節點由多種形態的算力設備組成，包含大型GPU設備或FPGA服務器集群、中小型企業閑散的空余服務器及個人閑置的計算節點等。平臺可以實現自動算力交易、自動算力匹配、費用結算功能。在算力賣家向算力買家提供服務的過程中，后者提出使用請求，算力交易平臺根據用戶需求自動尋找、匹配算力節點，并生成相應的賬單；在得到買家認可后，平臺調度相應的算力資源為買家提供服務，隨后執行算力業務的節點根據提供的算力獲得相應的報酬。

2.3 支撐算網資源融合管理調度的關鍵技術

2.3.1 算網轉發技術——SRv6

SRv6是源路由技術的一種，它采用現有的IPv6轉發技術，通過靈活的IPv6擴展頭，實現網絡可編程。

為了實現SRv6轉發，需要向IPv6報文中插入一個段路由頭（Segment Routing Header，SRH）的擴展頭，存儲IPv6的Segment List信息。報文轉發時，依靠Segments Left和Segment List字段共同決定IPv6目的地址（IPv6 DA）信息，從而指導報文的轉發路徑和行為。未經壓縮的SRv6 SID是128位，主要由標識節點位置的LOC字段（IPv6前綴格式，可路由）、標識服務和功能的FUNC字段（本地識別）以及ARG字段3個部分組成。

SRv6網絡編程標準中，SRv6節點（Endpoint）通過本地定義的行為（Behavior）處理SRv6報文。SRv6定義了多種Endpoint Behavior，每個節點需要實例化它們并分配SID，同時通過路由協議發布，以通知其他SRv6節點本節點能提供的Behavior。常用的Endpoint Behavior有END、END.X、END.DT4、END.DT6等，實現Underlay選路、Overlay業務承載等功能。

2.3.2 算網感知技術——APN6

APN6是在數據平面利用IPv6報文擴展頭（Extension Headers），如逐跳選項頭（Hop-by-Hop Options Header）、段路由頭（Segment Ｒouting Header）的可編程空間，攜帶應用的相關信息（標識和需求）到網絡中，網絡設備依據這些信息為其提供相應的網絡服務，如將報文映射進相應的能夠保障其SLA的SRv6路徑等。應用感知信息可以由用戶終端設備或應用直接生成，也可以由網絡邊緣設備生成，分別對應APN6的主機側方案和網絡側方案。

2.3.3 算網融合路由技術——CFN

為了解決邊緣計算系統中網絡信息和算力信息割裂，無法統一納管和進行最優資源調度的問題，Yizhou Li等提出了CFN的概念，并在IETF提交了草案：Framework of Compute First Networking（CFN），架構和原理如圖5所示。

圖5 CFN網絡拓撲

CFN網絡按角色分為服務器節點、CFN節點和客戶端。CFN通過控制面完成算力資源信息的全網同步。服務節點將本地服務狀態注冊到CFN節點的數據庫表項中。本地服務狀態一般包括服務的唯一標識（Service ID）、服務IP地址和計算資源情況等。CFN節點將本地服務狀態封裝到CFN路由協議報文中并擴散到其他CFN節點。CFN節點基于CFN路由協議將本地以及收到的其他CFN節點擴散的服務狀態信息匯總生成服務信息路由表。CFN數據面完成客戶端對服務節點Service ID請求的路由轉發。與客戶端距離最近的CFN節點收到請求后，根據網絡資源、計算資源情況進行綜合評估，選擇一個服務節點以及相關聯的CFN出口節點，將原請求數據包封裝并發送。

CFN Egress節點收到數據包，根據Service ID查找對應服務節點IP，將數據封裝并發送。外層數據包源地址為客戶端IP，目的地址為服務節點IP。報文封裝的內層數據包源地址為客戶端IP，目的地址為Service ID。服務節點收到數據包后在本地查詢與Service ID綁定的服務地址，調用對應的服務，將結果返回給客戶端。

0 3

結束語

在我國提出“東數西算”的大背景下，我國電信運營商希望借助政策發展的契機，在售賣網絡管道和出租數據中心基礎資源的同時，釋放更多的管道潛能，所以積極投入算力與網絡相融合的研究中，并在國際、國內標準組織推動制定了一系列算網融合的標準架構。但要真正實現算網融合的規模商用，無論是商業模式還是技術實現細節上都還存在較大差距。上述標準框架中，目標架構和業務流程都比較完善，但同時這種非常完善的架構也會帶來系統復雜度的大幅增加。由于要將CPU、GPU、FPGA以及內存和存儲等異構算力資源進行歸一化度量，需要研究算力的度量標準；另外，還需要建設算力交易平臺，解決算力的交易問題并進行標準化。從實現路徑上，建議基于現有云、算側和網側的調度系統和SRv6、APN和CFN、

RDMA等關鍵技術，采用邊研究邊實踐的策略，分3個階段逐步推進。

第1階段：單運營商場景。運營商內部負責云和網絡的運營團隊間不考慮算力資源交易和結算流程，這樣一方面簡化了算力運營和交易相關平臺的實現，另一方面，從流程上簡化了算力需求者提出需求后，在進行算力資源匹配后交易確認環節引入的處理時延。算力資源池也限制運營商的自有資源，減少資源種類，更易進行度量。

第2階段：單運營商、單云場景。運營商內部負責云和網絡的運營團隊間，以及運營商和第三方云供應商之間基于算力運營和交易平臺，實現了算力資源的交易和結算；算力資源池也拓展至本運營商的自有算力資源和第三方云供應商的算力資源。

第3階段：多運營商、多云場景。不同運營商間、運營商與第三方云供應商間都實現了算力運營和交易，運營商既可以是算力資源的購買者，也可以是算力資源的售賣者；同時，一些企業和個人終端的零散算力資源也可以進行交易。

作者簡介

李振文，工程師，主要從事5G承載、分組傳送、算力網絡等方面的研究工作；

李芳，教授級高級工程師，主要從事5G承載、分組傳送、算力網絡等方面的技術與標準研究工作；

趙俊峰，高級工程師，主要從事5G承載、分組傳送、確定性網絡、算力網絡等方面的技術與標準研究工作。

審核編輯：黃飛