算網操作系統(tǒng)白皮書 2023

本白皮書版權屬于網絡通信與安全紫金山實驗室及其合作單位：網絡通信與安全紫金山實驗室、北京郵電大學：江蘇省未來網絡創(chuàng)新研究院：張晨、黃韜、周俊、謝人超、汪碩、霍如、劉韻潔參與編寫人員(排名不分先后)：羅曙暉、汪年、張玉軍、夏令明、潘鳳薇、孫蟬娟、高新平、肖玉明、高松、李偉、趙芷晴、吳海喬I前言制體系相互獨立，難以實現協(xié)同。自于各種非技術層面的客觀約束。用間通信的流量傳輸，因此也無法實現有機協(xié)同。前言 I錄 III 1.1云原生/Serverless 1 2.1定義推演 72.2物理結構 102.3邏輯功能 12 資源抽象與建模 15業(yè)務抽象與建模 19調度框架與建模 23 4.1資源統(tǒng)一管控 284.2需求聯合聲明 314.3算網協(xié)同調度 33 同調度模式 38域拓撲結構 42域調度流程 47 算愿景與挑戰(zhàn) 55統(tǒng)核心能力 56業(yè)務場景分析 61典型用例介紹 67運營模式分析 70產業(yè)政策建議 73 7.1后續(xù)演進 767.2長期挑戰(zhàn) 79 參考文獻 851云原生/Serverless地構建和運行可彈性擴展的應用[1]。云原生的雛形早在2008年就已。研發(fā)門檻。2(物理機或虛擬機)上構建云原生環(huán)境。支付服務器的費用，無法實現真正的按實際用量付費。而Serverless速地進行函數發(fā)布與在線運行，并首次提出了FaaS(Functionasa了全面解讀與未來展望[5]，并認為Serverless能夠克服一切障礙并主。其中基礎設施不單指服務器上的計算資源(物理機或虛擬機)，同時Serverless的形態(tài)。Serverless的應用實例可以運行在包括函數、，并不局限于函數代碼片段這一形態(tài)。除了用戶的業(yè)務應用以外，系統(tǒng)的中間件(如數據庫、消息隊列)甚3，即可按需獲得相應的資源能力。s比非Serverless的云原生更低，但從用戶總體擁有成本(包括架構規(guī)分布式云/算力網有云、私有云、霧計算、邊緣計算、4商將自身核心云上的技術體系以新的產品形態(tài)和全局統(tǒng)一的管理架等級協(xié)議(SLA)即可。源調度，使這些集群形成了一個邏輯上的算力網；2)在第一種基礎52)通過在路由器上引入確定性傳輸能力，以保證算力間的高通量、地提升網絡連接的擴展性和業(yè)務的靈活性，解決了光連接中的N平方問題，同時還能夠滿足應用服務/任務間靈活的流量傳輸需求；3)適用于在單一主體內部的小規(guī)模組網場景。是純的網絡上下行傳輸時間短或云端渲染時間短都可能無法滿足用戶6礎設施的理想形態(tài)就是算力資源在全網任意分布并為用戶統(tǒng)一呈現戶無需感知應用/內容在廣域網中的具體分布位置，同時應用/內容可7需求到資源側的算力/網絡資源的調度。算網操作系統(tǒng)在設計之初就2.1定義推演上述概念體現了兩個方面的含義：1)從硬件角度來看，這些獨 8無需開發(fā)者對此進行顯式地編程。在分布式操作系統(tǒng)的技術發(fā)展史上，Google公司做出了巨大的車S9有別于K8S等集群內部的分布式操作系統(tǒng)，算網操作系統(tǒng)不僅2.2物理結構分離的問題，通常云和網的對接都是雙方各自擁有網關設備(云PEI均衡、流量工程等。端口號。相比于IP/端口號對于主機(接口)地址/本地服務監(jiān)聽句柄因為云中的各類中間件(如FW/LB/NAT)的處理而發(fā)生變化。類算網協(xié)同策略(訪問控制/負載均衡/流量工程等)。同時，當應用被角連接對于網絡的需求(如時延/帶寬)，然后基于算網協(xié)同網關所組織用同時運行時對帶寬資源進行靈活、細致的調配，3)網絡資源的無2.3邏輯功能2)閉環(huán)監(jiān)控判斷當前應用程序/應用間連接的運行狀態(tài)；5)協(xié)同調度對運行狀態(tài)背離用戶需求的應用或流量重新調度。操作系統(tǒng)的核心功能在于管理底層硬件資源以便上層應用使用。算網操作系統(tǒng)基礎理論體系。3.1資源抽象與建模資源建模抽象，3.1.1算力資源建模節(jié)點描述方法，實現了對于核心云、邊緣云、零散節(jié)點、邊緣網關、私有云、終端等的統(tǒng)一抽象。算力資源模型如圖3-1所示。 GPU型號/片數作為算力資源節(jié)點“資源量”的度量標準，以此建模源量>零散節(jié)點資源量。 的地理位置，以及其時斷時續(xù)的在線狀態(tài)。 3.1.2網絡資源建模網絡資源模型如圖3-2所示。 “資源數量”維度從網絡資源所能提供的“帶寬、時延、抖動”蔽底層網絡層復雜邏輯把網絡資源抽象為一組可量化服務能力的虛 3.1.3算網拓撲建模通，并形成一個獨立的算網協(xié)同平面。3.2業(yè)務抽象與建模業(yè)務建模旨在通過構建一種通用的模型來描繪業(yè)務系統(tǒng)的自身3.2.1業(yè)務應用建模如圖3-4所示，業(yè)務應用模型由負載描述、部署要求、預期狀態(tài)三大要素構成：1)負載描述用以表征應用本身的屬性信息，包括運性需求。定量需求(如單實例最小資源需求為<1核，2GB>)用于限資源的剩余資源量進行扣減。而定性資源需求(如應用需部署在公有云上、部署位置需包含南京等)同樣用于篩選應用部署需求的資源，與定性資源需求的不同點在于不需要對資源的剩余量進行扣減；3)量的上下3.2.2業(yè)務流量建模如圖3-5所示，業(yè)務流量建模描述了應用訪問/被訪問的流量的2)部署要求則是描述承載該流量的網絡資源需求。這些描述信息旨在量化訪問路徑上流量的需求特征，同樣分為定量需求與定性需求。訪問路徑對網絡資源供應商、地理位置的限定；3)預期狀態(tài)則是描期服務質量閾值與擴縮規(guī)則。3.2.3業(yè)務拓撲建模系并進一步描述了應用與流量的關系，以此構成業(yè)務系統(tǒng)的拓撲結構。3.3調度框架與建模3.3.1應用調度模型度模型旨在完成應用的資源需求特征與算力資源的匹配，如圖3-7所定量調度模型則是根據應用的定量資源需求匹配合適的算力資量資源需求的算力資源的同時，需要扣減該算力資源的可用資源量。3.3.2流量調度模型源標識，目的標識>為單元描述該流量傳輸中對網絡資源需求與預期成，如圖3-8所示。3.3.3協(xié)同調度模型上述應用調度建模與流量調度建模僅能實現應用和流量各自獨圖模型與算網拓撲模型的匹配，如圖3-9所示。用調度與流量調度并行模式：適合流量觸發(fā)應用動態(tài)加載或擴縮的場景。4.1資源統(tǒng)一管控冊納管與資源組織管理兩大功能模塊完成。4.1.1資源注冊納管資源和網絡資源的接入與退出提供服務入口。資源注冊流程如圖4-1信息的錄入，時空屬性(地理位置、網絡環(huán)境、在線時間等)以及供需關系，對于4.1.2資源組織管理結構。如圖4-2所示。4.2需求聯合聲明4.2.1業(yè)務部署接口流量的算力資源與網絡資源需求。用間服務訪問的網絡時延/帶寬需求。協(xié)同調度引擎會根據用戶藍圖4.2.2服務訪問接口4.3算網協(xié)同調度算網協(xié)同調度的核心任務是實現業(yè)務藍圖與算網拓撲之間的匹4.3.1典型示例問關系1為P協(xié)同調度將對業(yè)務藍圖的需求進行分解并與相應的資源進行匹邊緣云A之間訪問路徑4將由確定性網絡-FlexE承載；核心云與4.3.2抽象模型服務質量需求。4.3.3實現機制為實現應用/流量在初始部署時的分發(fā)/轉發(fā)，以及在運行狀態(tài)下有機融合的整體，量的重新轉發(fā)。業(yè)務部署需求，同調度；度功能模塊分別從算網拓撲中篩選出符合部署要求的算力資源與網5.1算網協(xié)同調度模式此小節(jié)將重點描述算網協(xié)同調度中三種典型的算網協(xié)同調度聯5.1.1先應用調度后流量SDN式SDN開圖訪問的場景。如圖5-1所示，其主要流程如下：05.1.2先流量調度后應用種模式可用于業(yè)務藍圖內訪問場景或跨業(yè)務藍圖訪問場景。如圖5-2型1(3)在觸發(fā)流量調度后先完成流量路徑的部署，再由流量觸發(fā)應5.1.3應用流量聯合保障僅當算力和網絡資源能夠同時滿足應用和流量需求時才視為一次成2(2)業(yè)務藍圖觸發(fā)應用與流量的協(xié)同調度，產生即滿足應用需求用模式。5.2分級跨域拓撲結構35.2.1對等式結構在對等式結構中集群是Peer-to-Peer的關系，如圖5-5所示。該4對等式結構常見于多個業(yè)務關系緊密但運營耦合程度較低的主5.2.2級聯式結構如圖5-6所示。父集群可獲取子集群的算力資源狀態(tài)與業(yè)務運行狀態(tài)5以作為其子集群的父集群，如此迭代即可形成一個樹狀的分層形態(tài)，持這種父子關系在各個層次之間的可傳遞性以及調用接口的冪等性。協(xié)作能力較弱。5.2.3混合式結構675.3分級跨域調度流程5.3.1面向對等式結構的調度流程業(yè)務藍圖觸發(fā)其流程如圖5-8所示。8(1)用戶向系統(tǒng)提交業(yè)務藍圖，對應步驟1；(2)全局業(yè)務入口接收到業(yè)務藍圖，將原始業(yè)務藍圖同步給區(qū)域(3)區(qū)域1調度接收到業(yè)務藍圖，經其協(xié)同調度得出APP1可部(5)區(qū)域2協(xié)同調度接收到子業(yè)務藍圖，得出APP2可部署在核服務訪問觸發(fā)縮的場景。其流程如圖5-9所示。APP務質量需求，對應步驟1；(3)在無用戶訪問時，邊緣云上還未部署APP1，此時通過流量APP完成后，發(fā)起向APP2的訪問請求，由此通過5.3.2面向級聯式結構的調度流程業(yè)務藍圖觸發(fā)局協(xié)同調度進行指標分拆，如藍圖中聲明的應用總副本數約束需求。調度與部署。其流程如圖5-10所示。(1)用戶向系統(tǒng)提交業(yè)務藍圖，如步驟1；(3)在全局協(xié)同調度完成后，將相應的子業(yè)務藍圖分別傳遞給其(5)區(qū)域2協(xié)同調度接收到子業(yè)務藍圖，得出APP2可部署在核服務訪問觸發(fā)量、以及應用流量聯合保障模式。其流程如圖5-11所示。APP務質量需求，對應步驟1；(3)在無用戶訪問時，邊緣云上還未部署APP1，此時通過流量APP完成后，發(fā)起向APP2的訪問請求，由此通過(5)通過全局協(xié)同調度將流量②部署在廣域網(SR)上，實現滿驟4；5.3.3面向混合式結構的調度流程業(yè)務藍圖觸發(fā)在全局入口提交業(yè)務藍圖時，如圖5-12所示。其流程小節(jié)類服務訪問觸發(fā)算網操作系統(tǒng)在設計之初就旨在解決東數西算將面臨的挑戰(zhàn)和6.1東數西算愿景與挑戰(zhàn)資源就近地接入到主板上面；2)需要有一個“新型桌面”為用戶提跨集群的情況需要分配相應的路由器隊列/光通道等廣域網資源，以一抽象，并進行“計算+網絡”的協(xié)同調度，同時能夠為用戶提供多6.2算網操作系統(tǒng)核心能力6.2.1資源使用方要用戶提前在有意向的公有云或其他資源供應方分別進行賬號與權服務可達，并不支持提出網絡的SLA需求，因此跨集群通信的網絡圖同時聲明應用對于算力(如CPU/內存/GPU)的需求和應用間通信對于網絡的需求(如帶寬/時延)，在具體操作上可通過直觀的拖拽或雖然它們能夠通過容器/擴縮容的形式將應用自動地跑在物理機或者serverless實現應用程序隨流量訪問的觸發(fā)6.2.2資源提供方力自身的資源量綱，系統(tǒng)可以根據應用在測試環(huán)境中的運行效果來判斷其在實際部署運6.2.3平臺調度方傳統(tǒng)只能在終端側實現的實時處理能力與云端的并發(fā)處理能力相結6.3業(yè)務場景分析6.3.1需求分析IA100GPU約71296片。天氣預報、氣候模擬、基因組學研究、藥物研發(fā)等科學計算領域需要進行復雜的數值模擬和大規(guī)模數據處理，Nature的文章表明10億個分子的虛擬篩選慧園區(qū)場景要求跨域協(xié)作來實現跨多個地理位置的設備互聯和數據用戶進行超低延遲的實時交互，多種感官信號需要高精度同步傳輸。6.3.2技術挑戰(zhàn)GPU支持。6.3.3業(yè)務建模通算業(yè)務建模云邊端架構。CPU/內存大小力集群內部也可能發(fā)生在核心云和邊緣云的算力集群之間并對網絡智算業(yè)務建模GPU聚已實現脹以及高端算力芯片的零散分布，分布式訓練有必要從“多機多卡”任務/模型部署、任務/模型間通信的結構顯得更加固定。以數據并行r超算業(yè)務建模超算業(yè)務場通常依賴于專用的超級計算或高性能計算進群來處計算進行數據文件和任務程序的切割并調度到空閑集群上實現協(xié)同式因而更加固定，相比于智算業(yè)務(以數據并行為例)，超算業(yè)務的務程序間需要通過專用的集合通信來實現高性能的并行計算。延遲能夠控制在us量級，因此需要盡量避免跨廣域網進行并行計算的內部協(xié)同，防止算力資源的等待甚至空轉。6.4典型用例介紹6.4.1通算典型用例6.4.2智算典型用例6.4.3超算典型用例6.5運營模式分析6.5.1中立平臺模式之間的橋梁，平臺自身并不以任何形式直接提供算力與網絡資源。上能夠實現責任判定是算網調度中心在該模式下面臨的一個挑戰(zhàn)。6.5.2自營平臺模式。響應速度往往并不盡如人意。某種形式的入口，因此在平臺的渠道壟斷也受到了一定程度的制約。資源。6.6產業(yè)政策建議6.6.1統(tǒng)一資源并網建議：1)制定“邏輯并網”標準，減輕算網平臺與算力集群間6.6.2統(tǒng)一用戶入口在此進行單點的賬號登錄即可由入口在后臺自動打通用戶在多區(qū)域、建議：1)制定用戶身份認證與授權標準，以實現跨算力集群間宣貫與市場引導，6.6.3統(tǒng)一效用定價效用定價機制，。術路線的扶持力度，逐步將云服務模式“以IaaS為主”轉變?yōu)椤耙?.6.4統(tǒng)一多方交易的商業(yè)閉環(huán)；2)加強對于數字人民幣、開放許可鏈等技術路線在算力交易中的試驗示范，實現算力交易從“下單、計費、分賬、付費”7.1后續(xù)演進7.1.1系統(tǒng)調用識、權限、性能等方面的設計中都隱式地植入了這種假設，而在其TCP/IP的設計中則顯式地區(qū)分了本地與網絡，這些都與分布式操作操作系統(tǒng)。7.1.2存算分離關系存在。圖7-2從“存算耦合”到“存算分離”務器(ServerlessDataCenter)。7.1.3光電融合連接時，遇到的新挑戰(zhàn)是，應用/任務間通信的時延不必準時但需要及時，帶寬則需要隨應用彈上述光電融合的廣域網將傳統(tǒng)路由器和光的松散結合變?yōu)榫o密務(NetworkasaService，NaaS)。7.2長期挑戰(zhàn)7.2.1異構算力驅動異構算力驅動的目標是解決不同算力芯片使用接口的多樣性和(1)制定算力驅動程序的接口標準。制定一套統(tǒng)一的算力資源程序編譯成中間指令集或WASM，并由驅動程序將其翻譯成特定硬 (2)研制異構算力芯片驅動程序和標準化運行時環(huán)境。針對不7.2.2統(tǒng)一數據建模數據具有不同的數據讀寫接口和存儲格式(如塊存儲、文件存儲和對象存儲)。不同的數據讀寫接口增加應用程序編碼的復雜性，而了數據的流動性和互操作性。 (1)制定統(tǒng)一的數據讀寫與格式標準。在制定標準時，應重點并實現不同存儲類型之間數據的互操作性。 (2)研制跨集群的數據存儲中間件。在設計中間件時，需要重動和共享。7.2.3智能代碼編譯傳統(tǒng)的通用編譯器無法適應異構算力并生成高效的跨平臺代碼。式改進代碼生成過程。：(1)靜態(tài)推斷式優(yōu)化。通過對源代碼進行靜態(tài)分析，識別潛在 (2)動態(tài)自適應優(yōu)化。利用機器學習算法，根據程序的實際運\ive\\tributedClouduousIntegrationandnuousDeliverySFunctionasaServicetDeliveryNetworkpplicationprogrammingacemationandCommunications\ernetesgleCloudPlatformloudrastructureasaServicePlatformasaserviceroviderEdgeIUserNetworkInterfaceNNINetworktoNetworkInterfaceewalladBalanceeAccessNBMAdcastMultipleAccessxEexibleEthernetltiprotocolLabelSwitchingpecifiedQueueingandardingPeertoPeercationyofServiceParameterServerFloatingPointOperationsPerutoscalertivePretrainedediateRepresentationNaaSNetworkasaService[1]CNCF.cf.io/about/who-we-are/[2]GoogleBlog./2008/04/introducing-google-app-ml[3]AWSEC2Post./cn/about-aws/whats-new/2006/08/24/announcingamazonel