赵奇慧：Cloud Native is Good, but How to Apply it in Telecom Network ？

CloudNativeisGood, butHowtoApplyitinTelecomNetwork? QihuiZhaoPengxiangChen Part1：网络云背景 中国移动从2015年起以推动网络转型为目标，建设电信级增强网络云，明确下一代网络整体设计，制定NFV/SDN技术方案体系，通过6+期的试点有效推动网络云的商用进程。截止去年，整体规模已超13万服务器，承载5GC、IMS、EPC等46+类网元，云化比例超85%，其中5G云化比例达100%。 哈尔滨 东北 西北 华北 保定 西安 郑州华东北 南京 西南 成都 华中 金华 华东南 华南广州 编排 5G控制面 网络云 SDN 5G控制面 网络云 第三方APP 5G用户面边缘计算 边缘云 5G用户面边缘计算 边缘云 第三方APP 5G用户面边缘计算 边缘云 第三方APP 总体布局：核心+边缘两级数据中心架构 eNodeB 个人接入 部署应用类型： APPTN 家庭接入集团接入 CMCC网络云现状 •核心：“8+X”大区，物理资源池集中建设，主核心网元逻辑分省 •边缘：率先规划地市，按需下沉 •核心：核心网网元（如4G网元、5G控制面）、VoLTE服务、智能网、彩信中心、网络云管理系统等 3 •边缘：核心网用户面网元（UPF）、MEP、垂直行业业务 3 网络云技术参考架构 VNF包 VNF：虚拟机化网络功能 •运行在虚拟化平台上的网元软件 •最小部署单元是一个或者多个VM OMC：操作维护中心 •网元的配置、告警监控、性能管理等 现网OSS Os-Ma-nfvo 传统北向增强接口 Ve-Vnfm-em Ve-Vnfm-vnf 虚拟层 Nf-Vi Vi-Ha 硬件层 网络设备、安全设备等 存储 服务器 虚拟资源管理(VIM) 虚拟化平台 （Hypervisor） Vi-Vnfm Vn-Nf 虚拟化网元（VNF） 北向接口 虚拟网元 网元层 虚拟化网元管理 （VNFM） OMC Or-Vi Or-Vnfm NFVO(网元FCAPS管理和编排) NFV管理和编排（MANO） 硬件管理接口 SDN控制器 物理资源管理（PIM） NFVO（NFVOrchestration） •负责网络业务的部署，比如5GC网元，以及跨厂家、跨数 据中心的全局资源管理 VNFM（VNFManager） •负责网元生命周期管理，解析VNFD，基本能力包括网元 VM的增、删、改、查 VIM（VirtualInfrastructure Manager） •云平台的管理，负责硬件管理 （由PIM负责）、VM部署、VM协调和调度 •现阶段使用OpenStack提供 虚拟资源管理功能 4 NFVI：NFV基础设施 •包括虚拟机管理软件和硬件 •硬件包含计算、存储、网络、安全等设备 •Hypervisor直接提供虚拟计算、虚拟网络、虚拟存储等能力 NFV+SDN架构示意图 4 Part2：网络云引入云原生分析 IT与CT云原生差异 IT模式：大型互联网企业E2E全栈架构，自建自营模式为主；先实践再总结，持续迭代；更关注弹性和业务敏捷性CT模式：主流运营商多厂商集成，设备采购&交付模式；注重标准化、规范化；更加关注电信级业务的高可靠性 网络云云原生可借鉴IT云原生成功经验，但需要结合CT建设方式及业务特点，综合定义符合CT实际情况的云原生引入技术及方法。 IT模式 业务特征 •Web类业务为主 •短连接，支持故障重试恢复 商业属性 •E2E全栈架构，无规范约束 •自研自建自营 可靠性要求 •数据高可靠 •99.95%可靠性 运维模式 •以业务微服务为对象 •自主DevOps在线运维 共性技术 容器 微服务 无损/灰度升级 持续部署 高效运维 无状态 CT模式 业务特征 •通信类业务为主 •长连接，中断后信令风暴 商业属性 •多厂家集成，依赖标准规范 •采购自建自营 可靠性要求 •业务全程高可靠 •99.999%可靠性 运维模式 •以VNF网元为对象 •联合切割运维 6 6 当前基于虚拟化技术的网络云已进入规模商用阶段，持续向云原生演进可进一步提高网络资源利用率、加速业务创新、提升管理运维效率，推动网络云从易用向好用演进。 云化现状和挑战 网络云引入云原生价值 网络云云原生演进的驱动力 管理提效 •入网敏捷：入网自动化提效 •升级无损：升级自动化提效 •弹性扩容：扩容自动化提效 自动化提升运维效率 现状：网络云自动化测试工具提升测试效率 挑战：版本入网/升级周期长，流程断点多，人工依赖程度高，自动化待提升 基础设施 虚拟化实现资源共享，提升资源利用率现状：虚拟化技术实现底层硬件通用化及资源共享挑战：虚拟化层开销，资源碎片化，可进一步优化 资源利用率提升 •容器颗粒度小，降低资源碎片化 •裸机容器可以节省虚拟层开销 网元业务 云化实现业务敏捷上线 现状：基础设施软硬件集成就绪下，VNF上线及扩缩容加速 挑战：针对新业务场景，部分网管、业务存在敏捷创新需求 业务敏捷 •通过容器+微服务加快新功能上线速度，快速创新探索新空间 •引入公共基础PaaS能力，支持应用快速创新部署 管理运维 7 7 Part3：对一些关键问题的思考 云原生技术引入现状 从全球主要运营商云原生商用情况看，引入云原生是发展趋势，但受限于技术和产品成熟度等情况，目前以容器引入为主，实际规模商用案例少、建设规模相对较小，整体仍处于商用探索阶段。 基础设施及能力平台：虚机容器、裸机容器按需选择，一般选择在新建资源池中引入；部分引入PaaS能力支撑业务功能和管理运维 虚拟层生长容器能力裸机容器池基于公有云部署 虚机 虚机容器 虚拟层 虚拟机容器层 裸机容器层 虚拟层 裸机容器 按需选择 •虚拟机为主、容器为辅，寄居式架构•虚拟层、裸机容器层并跑，维护两套技术栈•直接选择公有云的技术能力和运营模式 网元/业务：多样化微服务设计，多数选择建网时间晚、基于SBA架构实现的5GSA新业务切入，或者灵活性高、影响面小的网管业务切入 移动性管理 鉴权管理 信令处理LB HTTP处理LB 运维管理OMU-主运维管理OMU-备 …… 通信管理 位置管理 业务数据DB 9 AMF微服务实现示例 管理运维：引入设备商→运营商交付中转仓库、自动化测试工具、一致化部署验证环境是主流 9 10 云原生技术引入优先级 对云原生技术按收益、难度评估分为A、B、C三类优先级，可有计划、按需求逐步试验和引入。具体引入场景可遵循先支撑后核心、先2B后2C、先边缘后集中的引入策略。 收益 高 自动化流水线 裸机容器资源池 B A 自动化测试 微服务框架 高 中 低难度 通用PaaS能力 微服务标准化 C 低 云原生要素 执行点 建议优先级 容器技术 裸机容器资源池 A 微服务 微服务框架 B 通用PaaS能力 C 微服务标准化 C 自动化(持续交付+DevOps) 自动化测试 A 自动化流水线 B 10 裸机容器资源池：裸机管理 场景1容器层以虚拟层为底座构建 场景2容器层单独成池 Ironic 使用DPU卸载CLoudAgent 单独使用Ironic方案的缺点，Ironic内部逻辑比较复杂且发放的裸金属实例无法获取性能等信息，同时存在安全问题，配合DPU卸载CLoudAgent方案，可以解决安全问题 DPU+Nova增强完全替换Ironic方案，方案简洁同时解 决了安全问题 如何管理裸机是首要问题。针对不同的场景，业界已经给出了各自的解决方案，比如OpenstackIronic方案、RackShift方案以及Metal3-io方案等 11 RackShift等 Metal3 DPU卸载方案 引入DPU智能网卡，卸载管理、网络、存储等虚拟化任务，配合虚拟层实现裸金属弹性发放、虚拟网络加速以及存储网络安全 单独成池需适配存储、SDN、裸机管理组件，在现阶段不适宜 Metal3源于Ironic，与Ironic有一样的问题RackShift等裸机管理软件同K8S有待结合 11 容器比虚拟机有更好的易用性和更高的性能，但容器在安全性方面存在短板。在工程建设阶段，除了大家所熟知的容器共享宿主机内核的安全问题外，还有很多不容忽视的安全问题 工程阶段的容器安全问题 节点同控制面之间、节点之间节点内的容器之间机密容器 场景1：节点完全交给客户使用可以轻易对控制面或其他节点发起攻击 场景2：节点托管给平台 容器可能越权到节点对控制面 或其他节点发起攻击 gvisor kata 实验室测试数据（基于kata2.5.2） CPU性能损耗约为10%内存性能损耗约为2%网络性能损耗约为30% 安全容器（按需） 容器启停时间增加2秒以上 Nabla InclavareContainers 特点：通过使用基于硬件的可信执行环境（TEE）对使 用中的数据提供保护 问题：方案单一、 有硬件限制，学习 门槛高 裸机容器资源池：容器安全 12 通过网络安全 策略进行管控 安全容器（按需） 12 微服务：网元业务微服务划分 AMF接入管理 SMF会话管理 SMF策略管理 业务类... AMF安全服务移动性管理SMFIP地址分配服务 网元业务微服务化建议遵循五大基本原则。结合设计原则、标准化要求、电信网元现状及发展趋势，网元微服务可分为接口类、业务类、中间件类，每类可包含一个到多个功能性微服务。此外，可辅以微服务治理体系，提供运行态网元微服务管理，降低端到端管理难度。微服务拆分相关公共能力可沉淀为PaaS实现多网元共享。 HTTP服务 GTPU服务 PFCP服务 SDAP服务 接口类 GTPC服务 Diameter服务 TCP服务 …… 业务与平台解耦 单一职责 网元微服务划分基本原则 无状态 高度自治 持续演进 网元微服务划分参考 13 负载均衡服务 通信队列服务 可观测性服务 CI/CD流水线 数据存取服务 服务注册中心 配置管理服务 …… 服务治理体系 服务注册与发现 配置管理 流量治理熔断限流 … 可观测性日志性能 降级 告警 … 13 当前，网元设计已经或多或少考虑无状态化（如将用户数据集中到UDM中、VNF内部使用独立数据库存储业务上下文等），可进一步对网元内部数据进行分类，考虑多种数据状态及处理机制，实现状态管理精细化和优化。 灰度升级可以支撑业务在不浪费过多额外资源的情况下实现升级，依托无状态化设计，灰度升级的优势将进一步显性化。 网元无状态设计方法 •NF将用户业务/策略等稳态数据存储到外置数据网元 （UDSF/UDR），并按照网元可靠性要求对相应数据网元做好备份 •对于无法/不建议从NF内部剥离的状态数据，可首先考虑在网元内部/依托PaaS使用独立的数据库组件进行存储，并对该数据做好备份、一致性管理等 •对于网元内部不重要的状态数据，可默认为无状态，具体场景包括：数据/状态不重要、可随时抛弃并重新生成、具有冗余且切换时间极短等 •对于网元无法消除或忽略的状态/数据，可通过对承载状态/数据的网元模块单独设计可靠性机制（如主备/环状、数据实时镜像等） 14 •无状态的NF模块可采用多副本设计，各副本能力一致，负载均衡 网元内无状态设计/或主备设计，微服务模块升级不影响在线业务 VNF内无状态架构 DB(数据) 数据独立存储，做好读写管理，例如选择Redis多副本数据库+哨兵模式增加数据可靠性 (管理/操作 OAM ) 业务1 业务2业务3 LB（接口/分发） 业务按照服务/微服务独立升级/迁移/扩缩容，更灵活 分发策略灵活自动调控，多类电信级协议增强（PFCP、GTPU、HTTP、HTTPs） 微服务：网元无状态设计及灰度升级 14 自动化：CI-CT-CD流程优化思路 基于网络云建设的实践经验总结，依托云原生理念，建议进一步完善