一种服务化架构和无状态实现的云原生vBRAS 方案

徐伟杰 余晓颖 周振勇 章建聪

（华信咨询设计研究院有限公司 浙江省杭州市 310051）

多年来，电信运营商一直在网络建设和业务发展方面受到专用硬件的制约。随着云计算技术从IT 领域向电信领域的渗透，业界开始推动传统网元的网络功能虚拟化(Network Function Virtualization, NFV)。最初的ETSI NFV 架构里将虚拟化网络功能（Virtualised Network Function, VNF）部署在虚拟机上，但是虚拟机资源消耗大，初始化速度慢，逐步被轻量化容器取代，同时VNF 被进一步拆分为轻量化的虚拟化网络功能组件（Virtualised Network Function Component,VNFC）。云原生作为云计算的最新技术成果，能够为运营商的网络提供更加经济、便捷的部署和运营方法。ETSI从网络运营角度定义云原生网络功能（Cloud-native Network Function, CNF）是完全云原生的VNF，或者是正在过渡到云原生的VNF，并分析电信网络云原生应用的特性以及在架构设计、冗余容错、自动管理等方面需求的具备程度。

宽带远程接入服务器（Broadband Remote Access Server,BRAS）位于城域网边缘，是用户实现各种互联网业务的入口及运营商网络策略的执行点，是运营商迫切进行NFV 改造关键网元。目前，运营商、设备厂商已在vBRAS 采用转控分离架构(Control and User Plane Separation, CUPS)方面达成了一致意见。vBRAS 分为控制面（Control Plane, CP）和用户面（User Plane, UP），UP 进一步分为虚拟UP 和实体UP。网络设备厂商把CP 和虚拟UP 作为VNF 部署在虚拟机上，把传统BRAS 设备软件改造作为实体UP 使用。现有vBRAS 仍是NFV，做到了云就绪（cloud ready），但是不满足ETSI 对CNF 要求的具备程度，无法取得云原生技术优势。本文在分析现有vBRAS 方案的基础上，提出了一种云原生vBRAS 方案。该方案在架构设计方面采用服务化架构重构了vBRAS 控制面, 并无状态化实现VNFC 来满足弹性缩放需求，在冗余容错方面分别给出了控制面和用户面的容灾方案。

1 云就绪vBRAS方案现状

转控分离架构的vBRAS 包括控制面vBRAS-CP、用户面vBRAS-UP、CP-UP 接口、管理和编排（MANO, Management and Orchestration）等功能组件，外部系统包括业务系统和网管系统等，如图1 所示。

图1：vBRAS 逻辑架构示意图

1.1 vBRAS-CP

vBRAS-CP 作为VNF，软件运行在网络功能虚拟化基础设施（NFV Infrastructure, NFVI）上，主要实现以下功能：

（1）地址管理，vBRAS-CP 对其拥有的IP 地址资源进行统一的管理，与DHCP Server 配合或使用本地地址池模式，完成用户地址分配。

（2）接入管理，用于处理vBRAS-UP 上送的用户PPPoE 或IPoE 等接入协议报文，完成用户接入控制。

（3）认证授权计费（AAA），vBRAS-CP 和外部AAA服务器配合，共同完成对接入用户的认证、授权和计费。

（4）用户管理，包含用户表项管理功能和用户策略管理功能。其中，用户表项管理是指控制面生成用户session表项并下发给vBRAS-UP，vBRAS-UP 基于session 表项指导用户侧流量转发。用户策略管理是指对用户的认证、计费、授权、地址分配、QoS 等相关策略的管理。

（5）UP 管理， 包括对vBRAS-UP 的管理， 以及vBRAS-CP 和vBRAS-UP 间通信接口的管理。

此外，vBRAS-CP 还需要实现如合法侦听等功能。

1.2 vBRAS-UP

vBRAS-UP 分为运行在x86 服务器上的虚拟UP，以及运行在ASIC 和NP 高性能转发硬件上的实体UP，主要实现以下功能：

（1）负责传统BRAS 设备流量转发面功能，包括流量转发、QoS、流量统计等。

（2）负责传统BRAS 设备路由控制面功能，包括路由、组播及MPLS 等。

1.3 CP-UP接口

vBRAS-CP 和vBRAS-UP 之间需要使用以下三种类型的接口（通信通道）：

（1） 管理接口（Management Interface）， 使用NETCONF 连接作为vBRAS-CP 和vBRAS-UP 之间的管理通道，实现vBRAS-CP 向vBRAS-UP 查询数据、下发配置等功能。例如，创建子接口、下发BRAS 业务配置等。

（2）控制接口（Control Interface），使用控制与转发分离协议作为vBRAS-CP 和vBRAS-UP 之间的控制通道，实现业务表项下发、查询以及接口资源信息上报等功能。

（3）服务接口（Service Interface）,也称为控制报文重定向接口（Control Packet Redirect Interface）或协议接口（Protocol Interfaces），使用通用协议扩展类型的VXLAN隧道作为vBRAS-CP 和vBRAS-UP 之间的协议通道，实现PPPoE、IPoE、ARP 等协议报文交互。

网络运营商、网络设备厂商采用相似的控制与转发分离协议，但是并没有形成统一标准。中国移动联合华为、中兴在RFC8772中提出一种简单控制与转发分离协议(S-CUSP)。

1.4 MANO

MANO 负责NFVI 的软硬件资源的生命周期管理和编排，以及对VNF 的生命周期管理和编排。MANO 包括以下组件：

（1）虚拟化资源管理（Virtualised infrastructure manager,VIM）负责对物理硬件虚拟化资源进行统一管理、监控和优化。

（2）VNF 管理器（VNF Manager, VNFM）负责VNF的生命周期管理。

（3）NFV 编排器（NFV Orchestrator, NFVO）负责基础资源和上层软件资源的编排和管理，实现网络服务。

2 云原生vBRAS架构设计

本文在现有转控分离的vBRAS 方案基础上，提出了一种结合服务化架构以及无状态实现技术的云原生vBRAS 架构设计方案，其主要特点是采用服务化架构重构控制面，无状态化实现网络功能。

2.1 服务化架构重构CP

vBRAS-CP 作为一个VNF，其内部包括地址管理、接入管理、AAA、用户管理、UP 管理等网络管理功能。参考ETSI 规范，本文方案将vBRAS-CP（VNF）拆解成多个网络管理功能微服务（VNFC）。

vBRAS-CP 的VNFC 之间需要进行信息交互。以PPPoE IPv4 接入为例，用户上线业务流程如图2 所示。实际运营商网络中用户还会采用PPPoE IPv6、PPPoE 双栈、DHCPv4、DHCPv6、DHCP 双栈、IPv6 SLAAC 等多种接入方式，因此VNFC 之间信息交互非常复杂。

图2：PPPoE IPv4 用户上线的业务流程

在传统参考点架构中，网络功能之间的接口需预先定义和配置，且定义的接口只能用于特定的两个网络功能间使用。如果vBRAS-CP 采用该架构，则需要在所有存在信息交互关系的VNFC 之间定义和配置接口，VNFC 之间信息交互的复杂性会使得定义和配置接口的工作量剧增，而且开发新业务时，需要重新定义和配置已有接口或者增加新的接口，灵活性不强。

相对的，在服务化架构（Service-Based Architecture，SBA）中，每个网络功能对外呈现通用的服务化接口，可以被授权的网络功能调用，网络功能之间通过服务调用实现交互。服务化架构对于云原生网络应用的价值体现在敏捷性、易扩展性、灵活性、开放性。

本文方案的云原生vBRAS 控制面采用服务化架构，如图3 所示。地址管理、接入管理、用户管理、AAA、UP 管理等网络管理功能VNFC 应参照服务化架构的自包含、可重用、独立管理原则重新设计，同时增加网络功能仓库（NF Repository Function）等其他VNFC。网络功能仓库支持网络管理功能VNFC 实例的服务管理、服务发现和服务授权，从VNFC 实例接收VNFC 发现请求，并将被发现的VNFC实例的信息提供给VNFC 实例。

图3：vBRAS-CP 服务化架构示意图

2.2 无状态实现VNFC

网络功能的状态分为静态和动态两类。静态是指不随网络功能处理数据过程而改变的状态，动态是指随着网络功能处理过程持续更新的状态，进而可以分为实例状态和网络状态。本文中状态是指动态的网络状态。

ETSI 在GS NFV-SWA 001中定义，不需要处理状态信息的VNFC 是无状态的VNFC，需要处理状态信息的VNFC可以是有状态的VNFC，或者是状态数据存储在外部的无状态VNFC。vBRAS-CP 的网络管理功能VNFC 都是有状态的。

云原生VNF 需要弹性缩放实例和快速恢复故障来保证应用的弹性（Resiliency）。云原生NFV 根据网络功能负载的变化进行实例弹性缩放，可以通过改变实例数量来实现横向缩放（Scale out/in），或者通过改变现有实例资源分配数量来实现纵向缩放（Scale up/down）。考虑到纵向缩放时需要重启实例，且资源缩放到达限值后还是需要横向缩放，因此实际应用采用横向缩放。云原生NFV 对实例进行故障监测和检测，检测到失效实例后，生成新的实例替换故障实例来实现故障恢复。

有状态VNFC 使实例缩放和故障恢复变得复杂。以用户管理VNFC 为例，实例在处理用户表项管理同时需要在用户上线到下线期间保存用户会话状态信息，其用户表项处理能力与单位时间内上下线用户数量有关，用户表项保存能力则与一段时间内累计在线用户数量有关。用户表项的处理能力与保存能力紧耦合会产生以下问题：

（1）现有实例超负荷，如图4（a）所示系统启动新实例，UP 到现有实例的针对用户U2 表项查询请求被负载均衡分流到新实例，新实例中没有用户U2 表项的状态S2，导致查询失败。

图4：有状态影响实例缩放及故障恢复

（2）现有实例负荷低，如图4（b）所示系统关闭某个实例，UP 到被关闭实例的针对用户U3 表项查询请求被重定向到其他实例，其他实例中没有用户U3 表项的状态S3，导致查询失败。

（3）现有实例故障失效，如图4（c）所示系统启动新实例，UP 到失效实例的用户U1、U2 表项查询请求被重定向到新实例，新实例中没有用户表项的状态信息，导致查询失败。

为确保实例缩放和故障恢复能够正常运行，VNF 需要对VNFC 的状态数据进行处理，包括在对VNFC 实例进行扩展时将VNFC 内部状态进行复制迁移，以及在进行故障恢复时将一段时间内记录下的日志进行回放以重建VNFC状态等。但是，VNFC 实例间的状态迁移或恢复实现机制复杂、延迟大，限制了弹性缩放和快速恢复能力。

解决方法是将VNFC 从有状态变成无状态。本文方案将地址管理、接入管理、用户管理、AAA、UP 管理等网络管理功能VNFC 进行无状态化设计，具体包括业务逻辑处理和业务状态数据解耦，状态数据统一保存在VNFC 外部，同时引入统一数据存储用于存储和管理VNFC 的外部状态数据。

VNFC 实例在进行业务处理时，仅在本地轻量级上下文中缓存状态数据，在完成处理后把状态数据存储在统一数据存储的上下文中，删除本地数据。将同一VNFC 的实例作为一个组，组内实例彼此共享在线业务的上下文数据，如图5 所示。横向扩容时，新增实例直接从统一数据存储获取所需处理的业务上下文，在线业务不中断，新建业务不受影响。横向缩容或者故障发生时，其他实例从数据存储服务获取所需处理的业务上下文，可以瞬间接管被关闭实例的业务处理。某个VNFC 升级时，各实例可采用不同版本运行，实现平滑升级。

图5：VNFC 无状态化/统一数据存储示意图

建议统一数据存储采用分布式技术存储架构，采用数据库多实例对不同VNFC 组的外部组状态数据进行安全隔离，支持数据供1+M 的多副本冗余，以及跨资源池、跨DC 的异地部署机制，为数据提供超高可靠的冗余容灾能力。

3 云原生vBRAS容灾方案

云原生vBRAS 需要降低故障发生的可能性，延长系统无故障的工作时间，同时缩短修复故障的时间，尽快使系统恢复正常工作。本文针对云原生vBRAS 的控制面和用户面分别制定容灾方案。

3.1 控制面容灾方案

控制面处于云原生vBRAS 的核心层面，单套控制面设备容量可以处理的用户规模少则百万用户级别，多则达到千万用户级别，覆盖数个地市甚至全省/区的用户范围。所以不管是从用户量还是从覆盖的范围，控制面设备的安全运营都至关重要。

在实际网络运营中，由于人为操作失误、设备故障、自然灾害等原因，通信网络节点的故障无法避免，且故障恢复需要较长的时间，这就需要在控制面建设过程中提前考虑跨机房的设备容灾、网络的容灾，将通信网络节点故障的影响降低到最低程度。

控制面设备涉及NFV 系统的MANO 层、NFVI 层以及运行在VNF 层的控制面VNF 软件。控制面容灾方案需要考虑MANO 层、NFVI 层和VNF 层的容灾，其中重点是VNF层控制面各VNFC 的容灾。

3.1.1 MANO 层

MANO 故障不直接引起VNF 业务中断，但是在MANO异常期间部分虚拟化特性（如VNF/VNFC 缩放和恢复等）会无法正常使用。因此，MANO 应具有高可靠性，不存在单点故障，在软件上支持跨节点容灾。MANO 通常采用1+1主备双机方式配置，在主备双机间实现状态和数据的主备同步。当主用节点故障时，备用节点会自动成为主用节点接管业务，不中断服务。

3.1.2 NFVI 层

NFVI 硬件层包括计算资源、存储资源和网络资源，均需要采用冗余配置：

（1）计算资源采用N+M 冗余配置，所有服务器组件采用1+1 或N+M 冗余配置；

（2）存储资源采用磁阵RAID 存储，提供数据的1+1或1+M 备份；

（3）网络资源采用1+1 冗余配置，网络设备、链路、路由均采用冗余和负载分担。

硬件层应跨节点容灾，且部署在同一节点的同一类硬件资源至少从两个不同的供电分区引电。

虚拟化层实现硬件资源池的虚拟化，并协同MANO 节点实现虚拟资源池的管理和调度，为VNF 层提供高可靠的部署和恢复机制。当NFV 网络采用虚拟机部署时有以下要求：

（1）支持虚拟机的反亲和性部署。冗余备份的多个虚拟机需要部署在两个以上不同的服务器上，以便在主用虚拟机所在的服务器故障时，其他服务器上的冗余虚拟机能够接管业务。且主备关系的两个虚机需要部署在分属不同供电分区的服务器上。

（2）支持虚拟机状态的检测和自愈功能。当虚拟化层检测到虚拟机故障或物理硬件故障时，需要能在本机恢复或迁移至其他服务器上重生。

NFV 采用容器部署时也需要支持反亲和性部署、检测和自愈。

3.1.3 VNF 层

为提高控制面软件的可用性，要求所有VNFC 都需冗余以避免单点风险，并配备可靠的监控与故障检测机制，使得发现故障的时间需最小化，从发生异常到业务恢复时间需最小化，任何故障对连接、用户、会话等影响需最小化。

不同类型VNFC 采用不同容灾方式，大致分为以下三类：

3.1.3.1 功能管理类

网络功能仓库建议采用1+1 主备的容灾方式，主备实例分别部署在不同DC，容灾组网如图6 所示。主备实例关系通过对实例地址设置不同的访问优先级来实现，假设实例1 设置高优先级，即实例1 为主用、实例2 为备用。正常情况下，各VNFC 实例配置主备网络功能仓库实例地址，向主用实例1 发起注册、发现等请求。VNFC 实例向主用实例1 注册后，两者建立心跳检测，用于检测对方的工作状态。主用实例1 与备用实例2 实时同步数据，保证两边数据的一致性。正常情况下VNFC 实例不需要向备用实例2 注册，备用实例2 也不需要向VNFC 实例提供服务。

图6：网络功能仓库容灾方案

当主用实例1 故障失效时，备用实例2 通过同步信息判断主用实例1 故障，并接管业务。各VNFC 实例通过心跳检测消息发现主用实例1 故障失效，将备用实例2 设为高优先级。备用实例2 已经同步了原主用实例1 的信息，各VNFC实例不需要重新向备用实例2 注册，后续业务由备用实例2提供服务，即使主用实例1 故障恢复，也仍然由备用实例2提供服务。

3.1.3.2 会话管理类

用户管理、接入管理、地址管理、AAA 建议采用N+1负荷分担方式多DC 部署。UP 管理建议采用POOL 容灾方式多DC 部署。

以用户管理采用N+1 负荷分担的容灾方式（N ≥2）为例，其容灾组网如图7 所示。正常情况下，所有业务由N+1个业务负荷分担。用户管理实例在进入工作状态后，主动向网络功能仓库进行注册，并根据配置周期定时向网络功能仓库发送心跳消息，网络功能仓库通过心跳消息检测以及维护此实例的工作状态。

图7：用户管理容灾方案

当实例1 故障失效时，其新业务由其他实例共同分担，原承担的会话通过会话迁移的方式由其他实例继续处理。网络功能仓库将实例1 的状态置为不可用，并向订阅了实例1状态的其他VNFC 发送状态通知消息，触发它们选择其备份实例继续处理会话。用户管理实例的上下文等状态数据存储在统一数据存储中，统一数据存储负责对状态数据进行备份。在实例1 故障后，由其备份实例从统一数据存储获取上下文状态数据并继续处理业务。

UP 管理采用POOL 容灾方式，其容灾组网如图8 所示。将UP 管理实例划分为多个组，一组UP 管理实例组成一个POOL，为一个区域或一类业务的UP 提供服务。正常情况下，所有业务由POOL/组内的所有实例共同承担。UP 管理实例在进入工作状态后，主动向网络功能仓库进行注册，并根据配置周期定时向网络功能仓库、用户面UP 发送心跳消息。网络功能仓库通过心跳消息检测以及维护此实例的工作状态，用户面UP 通过心跳消息检测此实例是否正常工作。

图8：UP 管理容灾方案

当实例1 故障失效时，其新业务由POOL/组内其他实例共同分担，原承担的会话通过会话迁移的方式由其他实例继续处理。网络功能仓库将实例1 的状态置为不可用，并向订阅了实例1 状态的其他VNFC 发送状态通知消息，触发它们选择其备份实例继续处理会话。实例1 管理的UP 去活原会话，在接收到其备份实例发起的会话恢复请求后，根据其备份实例提供的会话信息执行本地会话重建流程，并与其备份实例进行后续交互。UP 管理实例的上下文等状态数据存储在统一数据存储中，统一数据存储负责对状态数据进行备份。在实例1 故障后，由其备份实例从统一数据存储获取上下文状态数据并继续处理业务。

3.1.3.3 数据存储类

统一数据存储建议采用分布式技术存储架构，对数据提供1+M 的多副本数据冗余，并跨多个DC 部署。

3.2 用户面容灾方案

UP 采用POOL 容灾方式，其容灾组网如图9 所示。一组UP 组成一个POOL，负责一个区域或一类业务。正常情况下，所有话务由POOL 内所有UP 共同承担。UP 管理通过CP-UP 接口进行UP 状态的检测与维护，按一定规则分担选择UP 执行会话流程。

图9：UP 容灾方案

当POOL 内UP 实例1 故障失效时，UP 管理在当一定时间未正常接收到此UP 心跳响应后，将其状态置为故障，同时根据配置启动UP 的故障处理流程，选择POOL 内其他的UP 执行会话流程。

4 总结

目前，运营商的网络面临着云化转型和重构的挑战，以数据中心为核心，基于软件定义网络、网络功能虚拟化的云化网络是通信网络演进的基本方向。与5G 核心网这类云原生网络应用技术不同，BRAS 从传统网元逐步向转变成云就绪vBRAS，并最终演进成为云原生vBRAS。本文提出的云原生vBRAS 方案采用服务化架构重构vBRAS 控制面，无状态化实现网络功能，能够满足云原生动态按需弹性缩放需求，并且具备较全面的容灾方案。