深入解析vEPC MANO架构：虚拟核心网的生命周期管理

1. 虚拟核心网与MANO架构的诞生背景记得我第一次接触电信核心网还是在2014年那时候机房里的设备清一色都是黑乎乎的机柜每个机柜里插满了各种专用板卡。每次扩容都要等上好几个月的硬件采购周期运维人员得带着防静电手环在机房里小心翼翼地插拔板卡。这种传统架构不仅部署周期长而且资源利用率经常不到30%。直到NFV网络功能虚拟化技术出现情况才开始改变。简单来说NFV就是把原来跑在专用硬件上的核心网功能比如MME、SGW、PGW这些网元全部用软件实现并跑在通用服务器上。这就好比我们把家里的DVD播放器、收音机、游戏机都换成了一个智能手机想用哪个功能就装哪个APP。但问题来了这么多虚拟化网元VNF要怎么管理它们的资源怎么分配版本怎么升级这时候就需要MANO管理和编排架构出场了。我第一次部署vEPC时最头疼的就是要同时管理OpenStack集群、VMware环境还有各种网元的生命周期。后来发现爱立信的CEE平台把这些问题都打包解决了特别是他们的Atlas组件让资源调度变得像搭积木一样简单。2. vEPC MANO架构深度拆解2.1 标准三件套NFVOVNFMVIMETSI定义的MANO标准架构就像是个三层蛋糕最上层是NFV编排器NFVO相当于乐团指挥负责整体资源调度和服务编排。我在项目里经常用它的API来批量创建几百个vEPC实例。中间层是VNF管理器VNFM专门管理单个网元的生命周期。比如MME网元的扩容操作就是由它向底层要资源。底层是虚拟设施管理器VIM直接管着计算、存储、网络资源。OpenStack和VMware vCenter都属于这一层。但实际部署时你会发现这个标准架构还缺了关键拼图。有次我们给运营商部署vEPC他们坚持要用现有的OSS系统这就需要在架构里加入网元管理系统EMS。爱立信的解决方案是用ENM作为适配层既符合标准架构又能对接老系统。2.2 爱立信的增强设计在真实项目中纯标准架构往往不够用。爱立信在vEPC MANO里加入了几个关键组件ECM增强型编排器处理跨数据中心的复杂编排。去年我们在某省核心网项目里就用它同时管理了3个地域的资源池。VNF-LCM应用这个藏在ENM里的神器可以统一管理不同厂家的VNF。有次我们需要把华为的PGW和爱立信MME混搭部署就靠它搞定生命周期管理。Atlas控制台对于运维人员来说这个基于Web的界面比命令行友好多了。我团队的新人培训时间因此缩短了60%。3. 生命周期管理的五个关键动作3.1 OnboardVNF的上户口过程第一次把vEPC软件包上传到平台时我踩过个大坑。标准流程应该是准备CSAR格式的软件包就是个加了元数据的zip包用CCR-Tool生成部署描述文件通过ECM的REST API上传但有次我漏了检查软件包的签名证书导致整个流程卡在验证环节。后来养成了习惯上传前先用这个命令检查openssl pkcs7 -in Metadata/signature.p7s -inform DER -print_certs3.2 Instantiate从图纸到实例实例化过程最考验MANO平台的功底。好的平台应该做到资源预估CANDI工具会根据预测流量自动计算需要多少vCPU依赖检查比如创建SGW前要先确认PGW已经就绪参数注入通过BCAT-Tool自动配置3GPP接口参数有个实用技巧在Atlas里创建部署模板时记得把变量参数化。比如把vCPU数量设为${cpu_count}这样后期调整规格时就不用重新打包镜像。3.3 Scale弹性扩容的魔法凌晨三点被告警电话吵醒的经历让我对自动扩缩容特别执着。vEPC MANO支持两种扩容模式水平扩展增加MME实例数量适合突发信令流量垂直扩展给PGW增加vCPU适合持续吞吐量增长在爱立信方案里CNOM会实时监控KPI当会话数超过阈值时自动触发扩容流程。有次春节红包活动我们的系统在10分钟内自动扩容了8次。3.4 Upgrade不停服更新给在线vEPC升级版本就像给飞行中的飞机换引擎。我们的标准操作是用AAT工具在新版本上跑自动化测试通过蓝绿部署逐步迁移流量用PDC-Tool对比新旧版本性能数据最惊险的一次是紧急安全补丁更新从下发升级指令到全部节点更新完成只用了7分半钟期间用户完全无感知。3.5 Terminate优雅退役删除VNF实例不是简单关机了事。规范流程包括将业务流量切换到其他节点执行数据持久化比如把计费记录存到外部数据库释放资源前用TMA工具确认没有残留会话有次我们漏了第二步结果丢了200多个用户的通话详单这个教训让我在后来每个终止流程都加了双重确认。4. 爱立信工具链实战解析4.1 CEE云执行的瑞士军刀爱立信的Cloud Execution Environment最让我欣赏的是它的多云适配层。无论是OpenStack还是VMware环境都能通过统一接口操作。上周刚用它完成了一个混合云部署核心网控制面跑在私有云基于OpenStack用户面网关部署在公有云AWS EC2通过Atlas统一展示拓扑关系关键配置在/etc/cee/adapters.conf文件里[openstack] auth_url https://controlplane.example.com:5000/v3 region_name RegionOne [aws] access_key_id AKIAXXXXXXXXXXXXXXXX secret_access_key xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx4.2 ECM的大规模编排秘诀在省级核心网项目里ECM的这三个功能特别实用批量操作可以同时给500个基站网关下发配置依赖图谱可视化展示网元间的依赖关系回滚引擎当部署失败时自动恢复到上个稳定版本记得有次误操作差点引发全省断网多亏ECM的秒级回滚功能救场。它的秘密在于每个变更都会生成快照保存在/var/ecm/snapshots目录下。4.3 监控三剑客CNOMTMAOSS Navigator运维团队最喜欢这套组合CNOM做实时健康检查它的心脏骤停检测能提前5分钟预测节点故障TMA分析信令风暴曾经帮我们定位出某款手机的异常频繁附着问题OSS Navigator的定制仪表板可以把KPI投射到办公室的大屏幕上这是我们的标准监控配置模板monitoring_profile kpi nameCPU_Usage threshold85% interval10s/ kpi nameActive_Sessions threshold50000 interval30s/ event nameLink_Failure severitycritical/ /monitoring_profile5. 实际部署中的经验之谈去年部署某运营商vEPC时我们总结出这些黄金法则资源预留千万别把VIM资源用满至少保留20%给紧急扩容。有次某厂商没遵守这条结果半夜扩容失败。标签管理给每个VNF打上业务标签比如voice_epcproduction这样在Atlas里可以快速过滤。灰度发布新版本先在5%的节点上线用AIT验证没问题再全量。文档同步每次变更都要更新CMDB里的/opt/ericsson/documentation目录。还有个血泪教训一定要定期测试灾备流程。我们曾经假设存储双活是正常的直到真正故障时才发现同步延迟有问题。现在每个季度都会做破坏性测试主动断掉某个AZ的链路来验证恢复流程。