深入解析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 标准三件套：NFVO+VNFM+VIM

ETSI定义的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 Onboard：VNF的"上户口"过程

第一次把vEPC软件包上传到平台时，我踩过个大坑。标准流程应该是：

1. 准备CSAR格式的软件包（就是个加了元数据的zip包）
2. 用CCR-Tool生成部署描述文件
3. 通过ECM的REST API上传

但有次我漏了检查软件包的签名证书，导致整个流程卡在验证环节。后来养成了习惯，上传前先用这个命令检查：

openssl pkcs7 -in Metadata/signature.p7s -inform DER -print_certs

3.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升级版本就像给飞行中的飞机换引擎。我们的标准操作是：

1. 用AAT工具在新版本上跑自动化测试
2. 通过蓝绿部署逐步迁移流量
3. 用PDC-Tool对比新旧版本性能数据

最惊险的一次是紧急安全补丁更新，从下发升级指令到全部节点更新完成只用了7分半钟，期间用户完全无感知。

3.5 Terminate：优雅退役

删除VNF实例不是简单关机了事。规范流程包括：

1. 将业务流量切换到其他节点
2. 执行数据持久化（比如把计费记录存到外部数据库）
3. 释放资源前用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 = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

4.2 ECM的大规模编排秘诀

在省级核心网项目里，ECM的这三个功能特别实用：

1. 批量操作：可以同时给500个基站网关下发配置
2. 依赖图谱：可视化展示网元间的依赖关系
3. 回滚引擎：当部署失败时自动恢复到上个稳定版本

记得有次误操作差点引发全省断网，多亏ECM的秒级回滚功能救场。它的秘密在于每个变更都会生成快照，保存在/var/ecm/snapshots目录下。

4.3 监控三剑客：CNOM+TMA+OSS Navigator

运维团队最喜欢这套组合：

• CNOM做实时健康检查，它的"心脏骤停"检测能提前5分钟预测节点故障
• TMA分析信令风暴，曾经帮我们定位出某款手机的异常频繁附着问题
• OSS Navigator的定制仪表板，可以把KPI投射到办公室的大屏幕上

这是我们的标准监控配置模板：

<monitoring_profile> <kpi name="CPU_Usage" threshold="85%" interval="10s"/> <kpi name="Active_Sessions" threshold="50000" interval="30s"/> <event name="Link_Failure" severity="critical"/> </monitoring_profile>

5. 实际部署中的经验之谈

去年部署某运营商vEPC时，我们总结出这些黄金法则：

• 资源预留：千万别把VIM资源用满，至少保留20%给紧急扩容。有次某厂商没遵守这条，结果半夜扩容失败。
• 标签管理：给每个VNF打上业务标签（比如voice_epc=production），这样在Atlas里可以快速过滤。
• 灰度发布：新版本先在5%的节点上线，用AIT验证没问题再全量。
• 文档同步：每次变更都要更新CMDB里的/opt/ericsson/documentation目录。

还有个血泪教训：一定要定期测试灾备流程。我们曾经假设存储双活是正常的，直到真正故障时才发现同步延迟有问题。现在每个季度都会做"破坏性测试"，主动断掉某个AZ的链路来验证恢复流程。