算网操作系统白皮书 2023

本白皮书版权属于网络通信与安全紫金山实验室及其合作单位：网络通信与安全紫金山实验室、北京邮电大学：江苏省未来网络创新研究院：张晨、黄韬、周俊、谢人超、汪硕、霍如、刘韵洁参与编写人员(排名不分先后)：罗曙晖、汪年、张玉军、夏令明、潘凤薇、孙蝉娟、高新平、肖玉明、高松、李伟、赵芷晴、吴海乔I前言制体系相互独立，难以实现协同。自于各种非技术层面的客观约束。用间通信的流量传输，因此也无法实现有机协同。前言 I录 III 1.1云原生/Serverless 1 2.1定义推演 72.2物理结构 102.3逻辑功能 12 资源抽象与建模 15业务抽象与建模 19调度框架与建模 23 4.1资源统一管控 284.2需求联合声明 314.3算网协同调度 33 同调度模式 38域拓扑结构 42域调度流程 47 算愿景与挑战 55统核心能力 56业务场景分析 61典型用例介绍 67运营模式分析 70产业政策建议 73 7.1后续演进 767.2长期挑战 79 参考文献 851云原生/Serverless地构建和运行可弹性扩展的应用[1]。云原生的雏形早在2008年就已。研发门槛。2(物理机或虚拟机)上构建云原生环境。支付服务器的费用，无法实现真正的按实际用量付费。而Serverless速地进行函数发布与在线运行，并首次提出了FaaS(Functionasa了全面解读与未来展望[5]，并认为Serverless能够克服一切障碍并主。其中基础设施不单指服务器上的计算资源(物理机或虚拟机)，同时Serverless的形态。Serverless的应用实例可以运行在包括函数、，并不局限于函数代码片段这一形态。除了用户的业务应用以外，系统的中间件(如数据库、消息队列)甚3，即可按需获得相应的资源能力。s比非Serverless的云原生更低，但从用户总体拥有成本(包括架构规分布式云/算力网有云、私有云、雾计算、边缘计算、4商将自身核心云上的技术体系以新的产品形态和全局统一的管理架等级协议(SLA)即可。源调度，使这些集群形成了一个逻辑上的算力网；2)在第一种基础52)通过在路由器上引入确定性传输能力，以保证算力间的高通量、地提升网络连接的扩展性和业务的灵活性，解决了光连接中的N平方问题，同时还能够满足应用服务/任务间灵活的流量传输需求；3)适用于在单一主体内部的小规模组网场景。是纯的网络上下行传输时间短或云端渲染时间短都可能无法满足用户6础设施的理想形态就是算力资源在全网任意分布并为用户统一呈现户无需感知应用/内容在广域网中的具体分布位置，同时应用/内容可7需求到资源侧的算力/网络资源的调度。算网操作系统在设计之初就2.1定义推演上述概念体现了两个方面的含义：1)从硬件角度来看，这些独 8无需开发者对此进行显式地编程。在分布式操作系统的技术发展史上，Google公司做出了巨大的车S9有别于K8S等集群内部的分布式操作系统，算网操作系统不仅2.2物理结构分离的问题，通常云和网的对接都是双方各自拥有网关设备(云PEI均衡、流量工程等。端口号。相比于IP/端口号对于主机(接口)地址/本地服务监听句柄因为云中的各类中间件(如FW/LB/NAT)的处理而发生变化。类算网协同策略(访问控制/负载均衡/流量工程等)。同时，当应用被角连接对于网络的需求(如时延/带宽)，然后基于算网协同网关所组织用同时运行时对带宽资源进行灵活、细致的调配，3)网络资源的无2.3逻辑功能2)闭环监控判断当前应用程序/应用间连接的运行状态；5)协同调度对运行状态背离用户需求的应用或流量重新调度。操作系统的核心功能在于管理底层硬件资源以便上层应用使用。算网操作系统基础理论体系。3.1资源抽象与建模资源建模抽象，3.1.1算力资源建模节点描述方法，实现了对于核心云、边缘云、零散节点、边缘网关、私有云、终端等的统一抽象。算力资源模型如图3-1所示。 GPU型号/片数作为算力资源节点“资源量”的度量标准，以此建模源量>零散节点资源量。 的地理位置，以及其时断时续的在线状态。 3.1.2网络资源建模网络资源模型如图3-2所示。 “资源数量”维度从网络资源所能提供的“带宽、时延、抖动”蔽底层网络层复杂逻辑把网络资源抽象为一组可量化服务能力的虚 3.1.3算网拓扑建模通，并形成一个独立的算网协同平面。3.2业务抽象与建模业务建模旨在通过构建一种通用的模型来描绘业务系统的自身3.2.1业务应用建模如图3-4所示，业务应用模型由负载描述、部署要求、预期状态三大要素构成：1)负载描述用以表征应用本身的属性信息，包括运性需求。定量需求(如单实例最小资源需求为<1核，2GB>)用于限资源的剩余资源量进行扣减。而定性资源需求(如应用需部署在公有云上、部署位置需包含南京等)同样用于筛选应用部署需求的资源，与定性资源需求的不同点在于不需要对资源的剩余量进行扣减；3)量的上下3.2.2业务流量建模如图3-5所示，业务流量建模描述了应用访问/被访问的流量的2)部署要求则是描述承载该流量的网络资源需求。这些描述信息旨在量化访问路径上流量的需求特征，同样分为定量需求与定性需求。访问路径对网络资源供应商、地理位置的限定；3)预期状态则是描期服务质量阈值与扩缩规则。3.2.3业务拓扑建模系并进一步描述了应用与流量的关系，以此构成业务系统的拓扑结构。3.3调度框架与建模3.3.1应用调度模型度模型旨在完成应用的资源需求特征与算力资源的匹配，如图3-7所定量调度模型则是根据应用的定量资源需求匹配合适的算力资量资源需求的算力资源的同时，需要扣减该算力资源的可用资源量。3.3.2流量调度模型源标识，目的标识>为单元描述该流量传输中对网络资源需求与预期成，如图3-8所示。3.3.3协同调度模型上述应用调度建模与流量调度建模仅能实现应用和流量各自独图模型与算网拓扑模型的匹配，如图3-9所示。用调度与流量调度并行模式：适合流量触发应用动态加载或扩缩的场景。4.1资源统一管控册纳管与资源组织管理两大功能模块完成。4.1.1资源注册纳管资源和网络资源的接入与退出提供服务入口。资源注册流程如图4-1信息的录入，时空属性(地理位置、网络环境、在线时间等)以及供需关系，对于4.1.2资源组织管理结构。如图4-2所示。4.2需求联合声明4.2.1业务部署接口流量的算力资源与网络资源需求。用间服务访问的网络时延/带宽需求。协同调度引擎会根据用户蓝图4.2.2服务访问接口4.3算网协同调度算网协同调度的核心任务是实现业务蓝图与算网拓扑之间的匹4.3.1典型示例问关系1为P协同调度将对业务蓝图的需求进行分解并与相应的资源进行匹边缘云A之间访问路径4将由确定性网络-FlexE承载；核心云与4.3.2抽象模型服务质量需求。4.3.3实现机制为实现应用/流量在初始部署时的分发/转发，以及在运行状态下有机融合的整体，量的重新转发。业务部署需求，同调度；度功能模块分别从算网拓扑中筛选出符合部署要求的算力资源与网5.1算网协同调度模式此小节将重点描述算网协同调度中三种典型的算网协同调度联5.1.1先应用调度后流量SDN式SDN开图访问的场景。如图5-1所示，其主要流程如下：05.1.2先流量调度后应用种模式可用于业务蓝图内访问场景或跨业务蓝图访问场景。如图5-2型1(3)在触发流量调度后先完成流量路径的部署，再由流量触发应5.1.3应用流量联合保障仅当算力和网络资源能够同时满足应用和流量需求时才视为一次成2(2)业务蓝图触发应用与流量的协同调度，产生即满足应用需求用模式。5.2分级跨域拓扑结构35.2.1对等式结构在对等式结构中集群是Peer-to-Peer的关系，如图5-5所示。该4对等式结构常见于多个业务关系紧密但运营耦合程度较低的主5.2.2级联式结构如图5-6所示。父集群可获取子集群的算力资源状态与业务运行状态5以作为其子集群的父集群，如此迭代即可形成一个树状的分层形态，持这种父子关系在各个层次之间的可传递性以及调用接口的幂等性。协作能力较弱。5.2.3混合式结构675.3分级跨域调度流程5.3.1面向对等式结构的调度流程业务蓝图触发其流程如图5-8所示。8(1)用户向系统提交业务蓝图，对应步骤1；(2)全局业务入口接收到业务蓝图，将原始业务蓝图同步给区域(3)区域1调度接收到业务蓝图，经其协同调度得出APP1可部(5)区域2协同调度接收到子业务蓝图，得出APP2可部署在核服务访问触发缩的场景。其流程如图5-9所示。APP务质量需求，对应步骤1；(3)在无用户访问时，边缘云上还未部署APP1，此时通过流量APP完成后，发起向APP2的访问请求，由此通过5.3.2面向级联式结构的调度流程业务蓝图触发局协同调度进行指标分拆，如蓝图中声明的应用总副本数约束需求。调度与部署。其流程如图5-10所示。(1)用户向系统提交业务蓝图，如步骤1；(3)在全局协同调度完成后，将相应的子业务蓝图分别传递给其(5)区域2协同调度接收到子业务蓝图，得出APP2可部署在核服务访问触发量、以及应用流量联合保障模式。其流程如图5-11所示。APP务质量需求，对应步骤1；(3)在无用户访问时，边缘云上还未部署APP1，此时通过流量APP完成后，发起向APP2的访问请求，由此通过(5)通过全局协同调度将流量②部署在广域网(SR)上，实现满骤4；5.3.3面向混合式结构的调度流程业务蓝图触发在全局入口提交业务蓝图时，如图5-12所示。其流程小节类服务访问触发算网操作系统在设计之初就旨在解决东数西算将面临的挑战和6.1东数西算愿景与挑战资源就近地接入到主板上面；2)需要有一个“新型桌面”为用户提跨集群的情况需要分配相应的路由器队列/光通道等广域网资源，以一抽象，并进行“计算+网络”的协同调度，同时能够为用户提供多6.2算网操作系统核心能力6.2.1资源使用方要用户提前在有意向的公有云或其他资源供应方分别进行账号与权服务可达，并不支持提出网络的SLA需求，因此跨集群通信的网络图同时声明应用对于算力(如CPU/内存/GPU)的需求和应用间通信对于网络的需求(如带宽/时延)，在具体操作上可通过直观的拖拽或虽然它们能够通过容器/扩缩容的形式将应用自动地跑在物理机或者serverless实现应用程序随流量访问的触发6.2.2资源提供方力自身的资源量纲，系统可以根据应用在测试环境中的运行效果来判断其在实际部署运6.2.3平台调度方传统只能在终端侧实现的实时处理能力与云端的并发处理能力相结6.3业务场景分析6.3.1需求分析IA100GPU约71296片。天气预报、气候模拟、基因组学研究、药物研发等科学计算领域需要进行复杂的数值模拟和大规模数据处理，Nature的文章表明10亿个分子的虚拟筛选慧园区场景要求跨域协作来实现跨多个地理位置的设备互联和数据用户进行超低延迟的实时交互，多种感官信号需要高精度同步传输。6.3.2技术挑战GPU支持。6.3.3业务建模通算业务建模云边端架构。CPU/内存大小力集群内部也可能发生在核心云和边缘云的算力集群之间并对网络智算业务建模GPU聚已实现胀以及高端算力芯片的零散分布，分布式训练有必要从“多机多卡”任务/模型部署、任务/模型间通信的结构显得更加固定。以数据并行r超算业务建模超算业务场通常依赖于专用的超级计算或高性能计算进群来处计算进行数据文件和任务程序的切割并调度到空闲集群上实现协同式因而更加固定，相比于智算业务(以数据并行为例)，超算业务的务程序间需要通过专用的集合通信来实现高性能的并行计算。延迟能够控制在us量级，因此需要尽量避免跨广域网进行并行计算的内部协同，防止算力资源的等待甚至空转。6.4典型用例介绍6.4.1通算典型用例6.4.2智算典型用例6.4.3超算典型用例6.5运营模式分析6.5.1中立平台模式之间的桥梁，平台自身并不以任何形式直接提供算力与网络资源。上能够实现责任判定是算网调度中心在该模式下面临的一个挑战。6.5.2自营平台模式。响应速度往往并不尽如人意。某种形式的入口，因此在平台的渠道垄断也受到了一定程度的制约。资源。6.6产业政策建议6.6.1统一资源并网建议：1)制定“逻辑并网”标准，减轻算网平台与算力集群间6.6.2统一用户入口在此进行单点的账号登录即可由入口在后台自动打通用户在多区域、建议：1)制定用户身份认证与授权标准，以实现跨算力集群间宣贯与市场引导，6.6.3统一效用定价效用定价机制，。术路线的扶持力度，逐步将云服务模式“以IaaS为主”转变为“以6.6.4统一多方交易的商业闭环；2)加强对于数字人民币、开放许可链等技术路线在算力交易中的试验示范，实现算力交易从“下单、计费、分账、付费”7.1后续演进7.1.1系统调用识、权限、性能等方面的设计中都隐式地植入了这种假设，而在其TCP/IP的设计中则显式地区分了本地与网络，这些都与分布式操作操作系统。7.1.2存算分离关系存在。图7-2从“存算耦合”到“存算分离”务器(ServerlessDataCenter)。7.1.3光电融合连接时，遇到的新挑战是，应用/任务间通信的时延不必准时但需要及时，带宽则需要随应用弹上述光电融合的广域网将传统路由器和光的松散结合变为紧密务(NetworkasaService，NaaS)。7.2长期挑战7.2.1异构算力驱动异构算力驱动的目标是解决不同算力芯片使用接口的多样性和(1)制定算力驱动程序的接口标准。制定一套统一的算力资源程序编译成中间指令集或WASM，并由驱动程序将其翻译成特定硬 (2)研制异构算力芯片驱动程序和标准化运行时环境。针对不7.2.2统一数据建模数据具有不同的数据读写接口和存储格式(如块存储、文件存储和对象存储)。不同的数据读写接口增加应用程序编码的复杂性，而了数据的流动性和互操作性。 (1)制定统一的数据读写与格式标准。在制定标准时，应重点并实现不同存储类型之间数据的互操作性。 (2)研制跨集群的数据存储中间件。在设计中间件时，需要重动和共享。7.2.3智能代码编译传统的通用编译器无法适应异构算力并生成高效的跨平台代码。式改进代码生成过程。：(1)静态推断式优化。通过对源代码进行静态分析，识别潜在 (2)动态自适应优化。利用机器学习算法，根据程序的实际运\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