2023算网操作系统白皮书

版权声明 本白皮书版权属于网络通信与安全紫金山实验室及其合作单位所有并受法律保护，任何个人或是组织在转载、摘编或以其他方式引用本白皮书中的文字、数据、图片或者观点时，应注明“来源：网络通信与安全紫金山实验室等”。否则将可能违反中国有关知识产权的相关法律和法规，对此网络通信与安全紫金山实验室有权追究侵权者的相关法律责任。 编写说明 主要编写单位： 网络通信与安全紫金山实验室、北京邮电大学参与编写单位： 江苏省未来网络创新研究院 主要编写人员： 张晨、黄韬、周俊、谢人超、汪硕、霍如、刘韵洁参与编写人员（排名不分先后）： 罗曙晖、汪年、张玉军、夏令明、潘凤薇、孙蝉娟、高新平、肖玉明、高松、李伟、赵芷晴、吴海乔 前言 如果把数字经济比作一个有机体，把数据比作它的血液，那么算力就好比是心脏，应能够源源不断地迸发出数据，而网络就好比是血管，应能够无阻畅通地传输数据。只有算力和网络形成有机的协同，才能保障数字经济有机体的高效、健康运转。然而在传统技术体系中，算力和网络的管理与控制体系相互独立，难以实现协同。 在此背景下，业界开始广泛探讨如何实现算力和网络两个技术体系的相互融汇。在相关的技术路线中，无论是“算融网”或者“网融算”都往往会出现“貌合神离”、“融而不通”的内伤性问题，这些问题不仅仅来自于技术，更来自于各种非技术层面的客观约束。 为破解上述问题，需要跳出“算融网”或者“网融算”的惯性思维：把算力和网络都视为等同的资源，站在用户视角来实现算力和网络的协同。对于这种思路的实践，以近年来的多云管理平台为典型代表，它能够代表用户分别开通多个云上的虚拟机和多个云间的虚拟网络，以减化用户复杂的配置流程。多云管理平台在一定程度可实现算力和网络的协同，不过其技术本质是自动化的环境配置，并不关注应用的实际运行和应用间通信的流量传输，因此也无法实现有机协同。 算网操作系统的提出，可进一步实现算力和网络的有机协同。算网操作系统从分布式系统的概念逐步推演而来，原生面向国家东数西算工程进行了针对性地构架与设计，并已通过长期的探索与实践中建立起了一套相对完整的理论体系与工程方法。 本白皮书的撰写与发布，以东数西算二期工程建设为锚，值第七届未来网络发展大会为机，希望后续能够与行业同仁多多碰撞，为实现“全国一台超级计算机”的宏伟愿景共同前行！ 目录 前言I 目录III 一、业务侧资源侧发展趋势1 1.1云原生/Serverless1 1.2分布式云/算力网3 二、算网操作系统总体架构7 2.1定义推演7 2.2物理结构10 2.3逻辑功能12 三、算网操作系统基础理论15 3.1资源抽象与建模15 3.2业务抽象与建模19 3.3调度框架与建模23 四、算网操作系统工作原理28 4.1资源统一管控28 4.2需求联合声明31 4.3算网协同调度33 五、算网操作系统调度机制38 5.1算网协同调度模式38 5.2分级跨域拓扑结构42 5.3分级跨域调度流程47 六、东数西算与算网操作系统55 6.1东数西算愿景与挑战55 6.2算网操作系统核心能力56 6.3业务场景分析61 6.4典型用例介绍67 6.5运营模式分析70 6.6产业政策建议73 七、未来发展与展望76 7.1后续演进76 7.2长期挑战79 附录A：术语与缩略语83 参考文献85 一、业务侧资源侧发展趋势 1.1云原生/Serverless 云原生（CloudNative）通过容器、微服务、服务网格等技术，可帮助企业在跨越公有云、私有云和混合云等新型动态环境中，一致性地构建和运行可弹性扩展的应用[1]。云原生的雏形早在2008年就已形成[2]，不过由于当时用户对于云计算的认知尚处于早期阶段，因此以虚拟化为主的产品形态[3]最先得到了市场的接受。随着云计算的大规模普及，云原生正逐步成为业界共识。 目前，云原生已经成为应用部署的行业标准。云原生技术能够构 建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。因此，云原生能够大幅度地降低应用更新、上线和运维的成本，并凭借这一优势在互联网、金融等行业得到了广泛的落地应用。 当下，云原生正发展为软件研发的新型理念。云原生的最佳实践 不仅仅是将已有应用迁移到云上，而是需要重新设计软件的系统架构，以充分发挥出可弹性扩展的优势。以此为基础，传统软件工程的立项、设计、开发、测试等全生命周期都可以在云上进行，实现从OnCloud到InCloud的转变。同时，云原生的CI/CD能力可进一步与低代码/无代码结合，进一步降低研发门槛。 未来，云原生将演进为无服务器的理想形态。云原生的主流使用 方式是用户在已购买的服务器（物理机或虚拟机）上构建云原生环境。这种方式虽然可以发挥云原生应用部署的优势，但用户仍然需要提前支付服务器的费用，无法实现真正的按实际用量付费。而Serverless则无需用户提前购买服务器即可随需随用、用后付费，是云原生尤其是公有云云原生未来演进的必然方向与理想形态。 Serverless起源于2014年AWSLambda[4]的发布，通过云函数用户可直接在云上编写代码片段，并可在未购买任何服务器的情况下快速地进行函数发布与在线运行，并首次提出了FaaS（FunctionasaService，函数即服务）的模式。2019年UC伯克利对Serverless进行了全面解读与未来展望[5]，并认为Serverless能够克服一切障碍并主导云计算的未来。 Serverless的定义。虽然FaaS已成为业界践行Serverless的主流 产品，但Serverless并不局限于FaaS。这里对Serverless的本质进行明确：一是无服务器，开发者无需关注任何基础设施的管理和维护， 其中基础设施不单指服务器上的计算资源（物理机或虚拟机），同时还包括网络和存储资源；二是按需伸缩，业务系统能够在不感知资源 的前提下根据实际用量进行弹性伸缩，且能够支持在没有使用或者访问的情况下将应用实例数收缩至0。 Serverless的形态。Serverless的应用实例可以运行在包括函数、 容器或任何其他的沙箱环境中，并不局限于函数代码片段这一形态。除了用户的业务应用以外，系统的中间件（如数据库、消息队列）甚 至网络/存储的底层实现也都将向Serverless转变，以彻底实现资源层的弹性伸缩能力。与非Serverless云原生相比，Serverless云原生无需用户购买任何的物理机或虚拟机，只需提出应用所需的资源（如CPU核数、网络服务入口），即可按需获得相应的资源能力。 Serverless的优势。相对于非Serverless的云原生，Serverless云 原生的优势体现在免运维与动态伸缩。免运维使得用户无需关注基础架构，从而可释放部署和运维的人力成本。而开发人员则得以专注于业务逻辑，实现产品能力的加速迭代。动态伸缩使系统能根据实际负载情况实现资源的精准匹配，尽管Serverless产品的单位定价不一定比非Serverless的云原生更低，但从用户总体拥有成本（包括架构规划、资源采购、上线维护）的角度来看，Serverless方案无疑具备巨大优势。 1.2分布式云/算力网 在云计算的发展历程中，公有云、私有云、雾计算、边缘计算、混合云、多云等概念层出不穷，但这些从不同角度提出的概念彼此之间存在着大量交叠甚至相互混淆，这导致了业界各方在很长的一段时间内都无法形成合力。2020年Gartner提出了分布式云的概念[6]，将一系列列在网络位置上不同但逻辑层次上连续的云（如本地云、5G边缘云、城域边缘云、PoP边缘云以及核心云）进行了统一。分布式云的概念一经提出，得到了业界的广泛响应并快速地形成了共识。 分布式云发展阶段。Gartner将分布式云的发展分为了两个阶段。 在第一阶段，公有云为主导的分布式云能力得到了提升，公有云提供商将自身核心云上的技术体系以新的产品形态和全局统一的管理架构提供给用户。虽然在技术能力上支持对其他云的能力兼容，但本质上以单个公有云服务为主流目标。在第二阶段，Gartner提出了明确的愿景，即政府机构、行业企业、科研单位等机构和组织都可以将自身算力资源开放提供给用户使用。 分布式云与算力网。分布式云的目标是“用户可以像接入Wi-Fi 热点一样就近接入云”，而算力网[7]旨在“使用算力像使用水和电一样方便”。这两个概念虽然在路线上有所不同，但是两者所提出的愿景是高度一致的。无论是第二阶段的分布式云还是算力网，其本质都在于用户不需要关心计算资源的物理位置和网络位置，只需要提出服务等级协议（SLA）即可。 算力网要解决的问题。为实现第二阶段的分布式云，或者算力网。 主要需要解决两个核心问题：一是跨不同云的API，即实现不同云环境之间的互操作；二是实现不同云环境之间的网络连接，确保应用/数据能够在不同云环境之间任意流动。对此，算力网的概念旨在解决这一问题：1）从算力视角出发，将分布在不同地理位置和网络位置的算力集群注册到一个统一的全局算力管理平台上，实现统一的算力资源调度，使这些集群形成了一个逻辑上的算力网；2）在第一种基础上，通过物理连接将不同的算力集群连接到一个专用网络上，实现高质量的算力互连，从而形成了一个物理上的算力网。 算力互连的实现路径。算力互连可以分为不同的实现方式：1） 通过光通道连接直接连接算力集群，将网络看作算力间的透明连接；2）通过在路由器上引入确定性传输能力，以保证算力间的高通量、低延迟和无丢包传输需求。相比于第一种方式，引入路由器可以极大地提升网络连接的扩展性和业务的灵活性，解决了光连接中的N平方问题，同时还能够满足应用服务/任务间灵活的流量传输需求；3）除此之外还有一种被电信运营商所广泛讨论的思路，即将算力状态引入网络路由中，甚至在路由器本地运行计算任务。这种方式在路由的扩展性和性能方面存在挑战，同时将计算运行在路由器内存在权属争议，因此更适用于在单一主体内部的小规模组网场景。 业务需要算网协同。无论采用何种算力网技术路径，其目标皆是 为业务提供端到端服务质量保障能力，需要计算和网络共同协作。南北向的算网协同关注终端用户与应用/任务之间的交互质量，侧重于网络IO。东西向的算网协作关注不同应用/任务之间的协同，侧重于计算处理。无论是南北向场景还是东西向场景都需要计算和网络共同协作来实现端到端的保障能力：1）在南北向的实时云端渲染场景中，用户终端希望云端在预期时间内返回每一帧的实时云端渲染结果。单纯的网络上下行传输时间短或云端渲染时间短都可能无法满足用户端到端的时间要求，必须实现计算和网络之间的高度协同，才能满足业务需求；2）在东西向的人工智能训练场景中，工作节点需要强大算力，工作节点与参数服务之间需要大量参数快速地更新，同样需要计算和网络之间的高度协同，实现训练模型参数的快速收敛。 算网协同需要确定性。为了满足端到端的业务服务质量，网络和 计算需要提供确定性的服务质量保证能力。网络的确定性需要可以预期地满足用户对网络时延、带宽和丢包的差异化需求。算力确定性则需要可以预期地满足用户对计算处理时延、并发的差异性需求。在算力和网络的确定性能力的基础上，还需要对两者进行高度协同，以满足业务的端到端服务质量需求。 结合业务侧Serverless与资源侧算力网的发展趋势，未来ICT基础设施的理想形态就是算力资源在全网任意分布并为用户统一呈现出一台跨广域的、分布式的超级计算机。在确定性能力的保障下，用户无需感知应用/内容在广域网中的具体分布位置，同时应用/内容可以进行自由流动和缓存，流量访问可以随时随地得到高速实时的连接，就像分布在同一个局域网内，甚至如同分布在同一台服务器中，如图1-1所示。 图1-1跨广域、分布式的超级计算机 二、算网操作系统总体架构 对于这台超级计算机而言，需要通过一个操作系统来管控其中的应用、内容以及应用与内容间的流量访问，实现从业务侧的Serve