徐偉杰 余曉穎 周振勇 章建聰

（華信咨詢設(shè)計(jì)研究院有限公司 浙江省杭州市 310051）

多年來，電信運(yùn)營商一直在網(wǎng)絡(luò)建設(shè)和業(yè)務(wù)發(fā)展方面受到專用硬件的制約。隨著云計(jì)算技術(shù)從IT 領(lǐng)域向電信領(lǐng)域的滲透，業(yè)界開始推動(dòng)傳統(tǒng)網(wǎng)元的網(wǎng)絡(luò)功能虛擬化(Network Function Virtualization, NFV)。最初的ETSI NFV 架構(gòu)里將虛擬化網(wǎng)絡(luò)功能（Virtualised Network Function, VNF）部署在虛擬機(jī)上，但是虛擬機(jī)資源消耗大，初始化速度慢，逐步被輕量化容器取代，同時(shí)VNF 被進(jìn)一步拆分為輕量化的虛擬化網(wǎng)絡(luò)功能組件（Virtualised Network Function Component,VNFC）。云原生作為云計(jì)算的最新技術(shù)成果，能夠?yàn)檫\(yùn)營商的網(wǎng)絡(luò)提供更加經(jīng)濟(jì)、便捷的部署和運(yùn)營方法。ETSI從網(wǎng)絡(luò)運(yùn)營角度定義云原生網(wǎng)絡(luò)功能（Cloud-native Network Function, CNF）是完全云原生的VNF，或者是正在過渡到云原生的VNF，并分析電信網(wǎng)絡(luò)云原生應(yīng)用的特性以及在架構(gòu)設(shè)計(jì)、冗余容錯(cuò)、自動(dòng)管理等方面需求的具備程度。

寬帶遠(yuǎn)程接入服務(wù)器（Broadband Remote Access Server,BRAS）位于城域網(wǎng)邊緣，是用戶實(shí)現(xiàn)各種互聯(lián)網(wǎng)業(yè)務(wù)的入口及運(yùn)營商網(wǎng)絡(luò)策略的執(zhí)行點(diǎn)，是運(yùn)營商迫切進(jìn)行NFV 改造關(guān)鍵網(wǎng)元。目前，運(yùn)營商、設(shè)備廠商已在vBRAS 采用轉(zhuǎn)控分離架構(gòu)(Control and User Plane Separation, CUPS)方面達(dá)成了一致意見。vBRAS 分為控制面（Control Plane, CP）和用戶面（User Plane, UP），UP 進(jìn)一步分為虛擬UP 和實(shí)體UP。網(wǎng)絡(luò)設(shè)備廠商把CP 和虛擬UP 作為VNF 部署在虛擬機(jī)上，把傳統(tǒng)BRAS 設(shè)備軟件改造作為實(shí)體UP 使用?，F(xiàn)有vBRAS 仍是NFV，做到了云就緒（cloud ready），但是不滿足ETSI 對CNF 要求的具備程度，無法取得云原生技術(shù)優(yōu)勢。本文在分析現(xiàn)有vBRAS 方案的基礎(chǔ)上，提出了一種云原生vBRAS 方案。該方案在架構(gòu)設(shè)計(jì)方面采用服務(wù)化架構(gòu)重構(gòu)了vBRAS 控制面, 并無狀態(tài)化實(shí)現(xiàn)VNFC 來滿足彈性縮放需求，在冗余容錯(cuò)方面分別給出了控制面和用戶面的容災(zāi)方案。

1 云就緒vBRAS方案現(xiàn)狀

轉(zhuǎn)控分離架構(gòu)的vBRAS 包括控制面vBRAS-CP、用戶面vBRAS-UP、CP-UP 接口、管理和編排（MANO, Management and Orchestration）等功能組件，外部系統(tǒng)包括業(yè)務(wù)系統(tǒng)和網(wǎng)管系統(tǒng)等，如圖1 所示。

圖1：vBRAS 邏輯架構(gòu)示意圖

1.1 vBRAS-CP

vBRAS-CP 作為VNF，軟件運(yùn)行在網(wǎng)絡(luò)功能虛擬化基礎(chǔ)設(shè)施（NFV Infrastructure, NFVI）上，主要實(shí)現(xiàn)以下功能：

（1）地址管理，vBRAS-CP 對其擁有的IP 地址資源進(jìn)行統(tǒng)一的管理，與DHCP Server 配合或使用本地地址池模式，完成用戶地址分配。

（2）接入管理，用于處理vBRAS-UP 上送的用戶PPPoE 或IPoE 等接入?yún)f(xié)議報(bào)文，完成用戶接入控制。

（3）認(rèn)證授權(quán)計(jì)費(fèi)（AAA），vBRAS-CP 和外部AAA服務(wù)器配合，共同完成對接入用戶的認(rèn)證、授權(quán)和計(jì)費(fèi)。

（4）用戶管理，包含用戶表項(xiàng)管理功能和用戶策略管理功能。其中，用戶表項(xiàng)管理是指控制面生成用戶session表項(xiàng)并下發(fā)給vBRAS-UP，vBRAS-UP 基于session 表項(xiàng)指導(dǎo)用戶側(cè)流量轉(zhuǎn)發(fā)。用戶策略管理是指對用戶的認(rèn)證、計(jì)費(fèi)、授權(quán)、地址分配、QoS 等相關(guān)策略的管理。

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

此外，vBRAS-CP 還需要實(shí)現(xiàn)如合法偵聽等功能。

1.2 vBRAS-UP

vBRAS-UP 分為運(yùn)行在x86 服務(wù)器上的虛擬UP，以及運(yùn)行在ASIC 和NP 高性能轉(zhuǎn)發(fā)硬件上的實(shí)體UP，主要實(shí)現(xiàn)以下功能：

（1）負(fù)責(zé)傳統(tǒng)BRAS 設(shè)備流量轉(zhuǎn)發(fā)面功能，包括流量轉(zhuǎn)發(fā)、QoS、流量統(tǒng)計(jì)等。

（2）負(fù)責(zé)傳統(tǒng)BRAS 設(shè)備路由控制面功能，包括路由、組播及MPLS 等。

1.3 CP-UP接口

vBRAS-CP 和vBRAS-UP 之間需要使用以下三種類型的接口（通信通道）：

（1） 管理接口（Management Interface）， 使用NETCONF 連接作為vBRAS-CP 和vBRAS-UP 之間的管理通道，實(shí)現(xiàn)vBRAS-CP 向vBRAS-UP 查詢數(shù)據(jù)、下發(fā)配置等功能。例如，創(chuàng)建子接口、下發(fā)BRAS 業(yè)務(wù)配置等。

（2）控制接口（Control Interface），使用控制與轉(zhuǎn)發(fā)分離協(xié)議作為vBRAS-CP 和vBRAS-UP 之間的控制通道，實(shí)現(xiàn)業(yè)務(wù)表項(xiàng)下發(fā)、查詢以及接口資源信息上報(bào)等功能。

（3）服務(wù)接口（Service Interface）,也稱為控制報(bào)文重定向接口（Control Packet Redirect Interface）或協(xié)議接口（Protocol Interfaces），使用通用協(xié)議擴(kuò)展類型的VXLAN隧道作為vBRAS-CP 和vBRAS-UP 之間的協(xié)議通道，實(shí)現(xiàn)PPPoE、IPoE、ARP 等協(xié)議報(bào)文交互。

網(wǎng)絡(luò)運(yùn)營商、網(wǎng)絡(luò)設(shè)備廠商采用相似的控制與轉(zhuǎn)發(fā)分離協(xié)議，但是并沒有形成統(tǒng)一標(biāo)準(zhǔn)。中國移動(dòng)聯(lián)合華為、中興在RFC8772中提出一種簡單控制與轉(zhuǎn)發(fā)分離協(xié)議(S-CUSP)。

1.4 MANO

MANO 負(fù)責(zé)NFVI 的軟硬件資源的生命周期管理和編排，以及對VNF 的生命周期管理和編排。MANO 包括以下組件：

（1）虛擬化資源管理（Virtualised infrastructure manager,VIM）負(fù)責(zé)對物理硬件虛擬化資源進(jìn)行統(tǒng)一管理、監(jiān)控和優(yōu)化。

（2）VNF 管理器（VNF Manager, VNFM）負(fù)責(zé)VNF的生命周期管理。

（3）NFV 編排器（NFV Orchestrator, NFVO）負(fù)責(zé)基礎(chǔ)資源和上層軟件資源的編排和管理，實(shí)現(xiàn)網(wǎng)絡(luò)服務(wù)。

2 云原生vBRAS架構(gòu)設(shè)計(jì)

本文在現(xiàn)有轉(zhuǎn)控分離的vBRAS 方案基礎(chǔ)上，提出了一種結(jié)合服務(wù)化架構(gòu)以及無狀態(tài)實(shí)現(xiàn)技術(shù)的云原生vBRAS 架構(gòu)設(shè)計(jì)方案，其主要特點(diǎn)是采用服務(wù)化架構(gòu)重構(gòu)控制面，無狀態(tài)化實(shí)現(xiàn)網(wǎng)絡(luò)功能。

2.1 服務(wù)化架構(gòu)重構(gòu)CP

vBRAS-CP 作為一個(gè)VNF，其內(nèi)部包括地址管理、接入管理、AAA、用戶管理、UP 管理等網(wǎng)絡(luò)管理功能。參考ETSI 規(guī)范，本文方案將vBRAS-CP（VNF）拆解成多個(gè)網(wǎng)絡(luò)管理功能微服務(wù)（VNFC）。

vBRAS-CP 的VNFC 之間需要進(jìn)行信息交互。以PPPoE IPv4 接入為例，用戶上線業(yè)務(wù)流程如圖2 所示。實(shí)際運(yùn)營商網(wǎng)絡(luò)中用戶還會采用PPPoE IPv6、PPPoE 雙棧、DHCPv4、DHCPv6、DHCP 雙棧、IPv6 SLAAC 等多種接入方式，因此VNFC 之間信息交互非常復(fù)雜。

圖2：PPPoE IPv4 用戶上線的業(yè)務(wù)流程

在傳統(tǒng)參考點(diǎn)架構(gòu)中，網(wǎng)絡(luò)功能之間的接口需預(yù)先定義和配置，且定義的接口只能用于特定的兩個(gè)網(wǎng)絡(luò)功能間使用。如果vBRAS-CP 采用該架構(gòu)，則需要在所有存在信息交互關(guān)系的VNFC 之間定義和配置接口，VNFC 之間信息交互的復(fù)雜性會使得定義和配置接口的工作量劇增，而且開發(fā)新業(yè)務(wù)時(shí)，需要重新定義和配置已有接口或者增加新的接口，靈活性不強(qiáng)。

相對的，在服務(wù)化架構(gòu)（Service-Based Architecture，SBA）中，每個(gè)網(wǎng)絡(luò)功能對外呈現(xiàn)通用的服務(wù)化接口，可以被授權(quán)的網(wǎng)絡(luò)功能調(diào)用，網(wǎng)絡(luò)功能之間通過服務(wù)調(diào)用實(shí)現(xiàn)交互。服務(wù)化架構(gòu)對于云原生網(wǎng)絡(luò)應(yīng)用的價(jià)值體現(xiàn)在敏捷性、易擴(kuò)展性、靈活性、開放性。

本文方案的云原生vBRAS 控制面采用服務(wù)化架構(gòu)，如圖3 所示。地址管理、接入管理、用戶管理、AAA、UP 管理等網(wǎng)絡(luò)管理功能VNFC 應(yīng)參照服務(wù)化架構(gòu)的自包含、可重用、獨(dú)立管理原則重新設(shè)計(jì)，同時(shí)增加網(wǎng)絡(luò)功能倉庫（NF Repository Function）等其他VNFC。網(wǎng)絡(luò)功能倉庫支持網(wǎng)絡(luò)管理功能VNFC 實(shí)例的服務(wù)管理、服務(wù)發(fā)現(xiàn)和服務(wù)授權(quán)，從VNFC 實(shí)例接收VNFC 發(fā)現(xiàn)請求，并將被發(fā)現(xiàn)的VNFC實(shí)例的信息提供給VNFC 實(shí)例。

圖3：vBRAS-CP 服務(wù)化架構(gòu)示意圖

2.2 無狀態(tài)實(shí)現(xiàn)VNFC

網(wǎng)絡(luò)功能的狀態(tài)分為靜態(tài)和動(dòng)態(tài)兩類。靜態(tài)是指不隨網(wǎng)絡(luò)功能處理數(shù)據(jù)過程而改變的狀態(tài)，動(dòng)態(tài)是指隨著網(wǎng)絡(luò)功能處理過程持續(xù)更新的狀態(tài)，進(jìn)而可以分為實(shí)例狀態(tài)和網(wǎng)絡(luò)狀態(tài)。本文中狀態(tài)是指動(dòng)態(tài)的網(wǎng)絡(luò)狀態(tài)。

ETSI 在GS NFV-SWA 001中定義，不需要處理狀態(tài)信息的VNFC 是無狀態(tài)的VNFC，需要處理狀態(tài)信息的VNFC可以是有狀態(tài)的VNFC，或者是狀態(tài)數(shù)據(jù)存儲在外部的無狀態(tài)VNFC。vBRAS-CP 的網(wǎng)絡(luò)管理功能VNFC 都是有狀態(tài)的。

云原生VNF 需要彈性縮放實(shí)例和快速恢復(fù)故障來保證應(yīng)用的彈性（Resiliency）。云原生NFV 根據(jù)網(wǎng)絡(luò)功能負(fù)載的變化進(jìn)行實(shí)例彈性縮放，可以通過改變實(shí)例數(shù)量來實(shí)現(xiàn)橫向縮放（Scale out/in），或者通過改變現(xiàn)有實(shí)例資源分配數(shù)量來實(shí)現(xiàn)縱向縮放（Scale up/down）。考慮到縱向縮放時(shí)需要重啟實(shí)例，且資源縮放到達(dá)限值后還是需要橫向縮放，因此實(shí)際應(yīng)用采用橫向縮放。云原生NFV 對實(shí)例進(jìn)行故障監(jiān)測和檢測，檢測到失效實(shí)例后，生成新的實(shí)例替換故障實(shí)例來實(shí)現(xiàn)故障恢復(fù)。

有狀態(tài)VNFC 使實(shí)例縮放和故障恢復(fù)變得復(fù)雜。以用戶管理VNFC 為例，實(shí)例在處理用戶表項(xiàng)管理同時(shí)需要在用戶上線到下線期間保存用戶會話狀態(tài)信息，其用戶表項(xiàng)處理能力與單位時(shí)間內(nèi)上下線用戶數(shù)量有關(guān)，用戶表項(xiàng)保存能力則與一段時(shí)間內(nèi)累計(jì)在線用戶數(shù)量有關(guān)。用戶表項(xiàng)的處理能力與保存能力緊耦合會產(chǎn)生以下問題：

（1）現(xiàn)有實(shí)例超負(fù)荷，如圖4（a）所示系統(tǒng)啟動(dòng)新實(shí)例，UP 到現(xiàn)有實(shí)例的針對用戶U2 表項(xiàng)查詢請求被負(fù)載均衡分流到新實(shí)例，新實(shí)例中沒有用戶U2 表項(xiàng)的狀態(tài)S2，導(dǎo)致查詢失敗。

圖4：有狀態(tài)影響實(shí)例縮放及故障恢復(fù)

（2）現(xiàn)有實(shí)例負(fù)荷低，如圖4（b）所示系統(tǒng)關(guān)閉某個(gè)實(shí)例，UP 到被關(guān)閉實(shí)例的針對用戶U3 表項(xiàng)查詢請求被重定向到其他實(shí)例，其他實(shí)例中沒有用戶U3 表項(xiàng)的狀態(tài)S3，導(dǎo)致查詢失敗。

（3）現(xiàn)有實(shí)例故障失效，如圖4（c）所示系統(tǒng)啟動(dòng)新實(shí)例，UP 到失效實(shí)例的用戶U1、U2 表項(xiàng)查詢請求被重定向到新實(shí)例，新實(shí)例中沒有用戶表項(xiàng)的狀態(tài)信息，導(dǎo)致查詢失敗。

為確保實(shí)例縮放和故障恢復(fù)能夠正常運(yùn)行，VNF 需要對VNFC 的狀態(tài)數(shù)據(jù)進(jìn)行處理，包括在對VNFC 實(shí)例進(jìn)行擴(kuò)展時(shí)將VNFC 內(nèi)部狀態(tài)進(jìn)行復(fù)制遷移，以及在進(jìn)行故障恢復(fù)時(shí)將一段時(shí)間內(nèi)記錄下的日志進(jìn)行回放以重建VNFC狀態(tài)等。但是，VNFC 實(shí)例間的狀態(tài)遷移或恢復(fù)實(shí)現(xiàn)機(jī)制復(fù)雜、延遲大，限制了彈性縮放和快速恢復(fù)能力。

解決方法是將VNFC 從有狀態(tài)變成無狀態(tài)。本文方案將地址管理、接入管理、用戶管理、AAA、UP 管理等網(wǎng)絡(luò)管理功能VNFC 進(jìn)行無狀態(tài)化設(shè)計(jì)，具體包括業(yè)務(wù)邏輯處理和業(yè)務(wù)狀態(tài)數(shù)據(jù)解耦，狀態(tài)數(shù)據(jù)統(tǒng)一保存在VNFC 外部，同時(shí)引入統(tǒng)一數(shù)據(jù)存儲用于存儲和管理VNFC 的外部狀態(tài)數(shù)據(jù)。

VNFC 實(shí)例在進(jìn)行業(yè)務(wù)處理時(shí)，僅在本地輕量級上下文中緩存狀態(tài)數(shù)據(jù)，在完成處理后把狀態(tài)數(shù)據(jù)存儲在統(tǒng)一數(shù)據(jù)存儲的上下文中，刪除本地?cái)?shù)據(jù)。將同一VNFC 的實(shí)例作為一個(gè)組，組內(nèi)實(shí)例彼此共享在線業(yè)務(wù)的上下文數(shù)據(jù)，如圖5 所示。橫向擴(kuò)容時(shí)，新增實(shí)例直接從統(tǒng)一數(shù)據(jù)存儲獲取所需處理的業(yè)務(wù)上下文，在線業(yè)務(wù)不中斷，新建業(yè)務(wù)不受影響。橫向縮容或者故障發(fā)生時(shí)，其他實(shí)例從數(shù)據(jù)存儲服務(wù)獲取所需處理的業(yè)務(wù)上下文，可以瞬間接管被關(guān)閉實(shí)例的業(yè)務(wù)處理。某個(gè)VNFC 升級時(shí)，各實(shí)例可采用不同版本運(yùn)行，實(shí)現(xiàn)平滑升級。

圖5：VNFC 無狀態(tài)化/統(tǒng)一數(shù)據(jù)存儲示意圖

建議統(tǒng)一數(shù)據(jù)存儲采用分布式技術(shù)存儲架構(gòu)，采用數(shù)據(jù)庫多實(shí)例對不同VNFC 組的外部組狀態(tài)數(shù)據(jù)進(jìn)行安全隔離，支持?jǐn)?shù)據(jù)供1+M 的多副本冗余，以及跨資源池、跨DC 的異地部署機(jī)制，為數(shù)據(jù)提供超高可靠的冗余容災(zāi)能力。

3 云原生vBRAS容災(zāi)方案

云原生vBRAS 需要降低故障發(fā)生的可能性，延長系統(tǒng)無故障的工作時(shí)間，同時(shí)縮短修復(fù)故障的時(shí)間，盡快使系統(tǒng)恢復(fù)正常工作。本文針對云原生vBRAS 的控制面和用戶面分別制定容災(zāi)方案。

3.1 控制面容災(zāi)方案

控制面處于云原生vBRAS 的核心層面，單套控制面設(shè)備容量可以處理的用戶規(guī)模少則百萬用戶級別，多則達(dá)到千萬用戶級別，覆蓋數(shù)個(gè)地市甚至全省/區(qū)的用戶范圍。所以不管是從用戶量還是從覆蓋的范圍，控制面設(shè)備的安全運(yùn)營都至關(guān)重要。

在實(shí)際網(wǎng)絡(luò)運(yùn)營中，由于人為操作失誤、設(shè)備故障、自然災(zāi)害等原因，通信網(wǎng)絡(luò)節(jié)點(diǎn)的故障無法避免，且故障恢復(fù)需要較長的時(shí)間，這就需要在控制面建設(shè)過程中提前考慮跨機(jī)房的設(shè)備容災(zāi)、網(wǎng)絡(luò)的容災(zāi)，將通信網(wǎng)絡(luò)節(jié)點(diǎn)故障的影響降低到最低程度。

控制面設(shè)備涉及NFV 系統(tǒng)的MANO 層、NFVI 層以及運(yùn)行在VNF 層的控制面VNF 軟件?？刂泼嫒轂?zāi)方案需要考慮MANO 層、NFVI 層和VNF 層的容災(zāi)，其中重點(diǎn)是VNF層控制面各VNFC 的容災(zāi)。

3.1.1 MANO 層

MANO 故障不直接引起VNF 業(yè)務(wù)中斷，但是在MANO異常期間部分虛擬化特性（如VNF/VNFC 縮放和恢復(fù)等）會無法正常使用。因此，MANO 應(yīng)具有高可靠性，不存在單點(diǎn)故障，在軟件上支持跨節(jié)點(diǎn)容災(zāi)。MANO 通常采用1+1主備雙機(jī)方式配置，在主備雙機(jī)間實(shí)現(xiàn)狀態(tài)和數(shù)據(jù)的主備同步。當(dāng)主用節(jié)點(diǎn)故障時(shí)，備用節(jié)點(diǎn)會自動(dòng)成為主用節(jié)點(diǎn)接管業(yè)務(wù)，不中斷服務(wù)。

3.1.2 NFVI 層

NFVI 硬件層包括計(jì)算資源、存儲資源和網(wǎng)絡(luò)資源，均需要采用冗余配置：

（1）計(jì)算資源采用N+M 冗余配置，所有服務(wù)器組件采用1+1 或N+M 冗余配置；

（2）存儲資源采用磁陣RAID 存儲，提供數(shù)據(jù)的1+1或1+M 備份；

（3）網(wǎng)絡(luò)資源采用1+1 冗余配置，網(wǎng)絡(luò)設(shè)備、鏈路、路由均采用冗余和負(fù)載分擔(dān)。

硬件層應(yīng)跨節(jié)點(diǎn)容災(zāi)，且部署在同一節(jié)點(diǎn)的同一類硬件資源至少從兩個(gè)不同的供電分區(qū)引電。

虛擬化層實(shí)現(xiàn)硬件資源池的虛擬化，并協(xié)同MANO 節(jié)點(diǎn)實(shí)現(xiàn)虛擬資源池的管理和調(diào)度，為VNF 層提供高可靠的部署和恢復(fù)機(jī)制。當(dāng)NFV 網(wǎng)絡(luò)采用虛擬機(jī)部署時(shí)有以下要求：

（1）支持虛擬機(jī)的反親和性部署。冗余備份的多個(gè)虛擬機(jī)需要部署在兩個(gè)以上不同的服務(wù)器上，以便在主用虛擬機(jī)所在的服務(wù)器故障時(shí)，其他服務(wù)器上的冗余虛擬機(jī)能夠接管業(yè)務(wù)。且主備關(guān)系的兩個(gè)虛機(jī)需要部署在分屬不同供電分區(qū)的服務(wù)器上。

（2）支持虛擬機(jī)狀態(tài)的檢測和自愈功能。當(dāng)虛擬化層檢測到虛擬機(jī)故障或物理硬件故障時(shí)，需要能在本機(jī)恢復(fù)或遷移至其他服務(wù)器上重生。

NFV 采用容器部署時(shí)也需要支持反親和性部署、檢測和自愈。

3.1.3 VNF 層

為提高控制面軟件的可用性，要求所有VNFC 都需冗余以避免單點(diǎn)風(fēng)險(xiǎn)，并配備可靠的監(jiān)控與故障檢測機(jī)制，使得發(fā)現(xiàn)故障的時(shí)間需最小化，從發(fā)生異常到業(yè)務(wù)恢復(fù)時(shí)間需最小化，任何故障對連接、用戶、會話等影響需最小化。

不同類型VNFC 采用不同容災(zāi)方式，大致分為以下三類：

3.1.3.1 功能管理類

網(wǎng)絡(luò)功能倉庫建議采用1+1 主備的容災(zāi)方式，主備實(shí)例分別部署在不同DC，容災(zāi)組網(wǎng)如圖6 所示。主備實(shí)例關(guān)系通過對實(shí)例地址設(shè)置不同的訪問優(yōu)先級來實(shí)現(xiàn)，假設(shè)實(shí)例1 設(shè)置高優(yōu)先級，即實(shí)例1 為主用、實(shí)例2 為備用。正常情況下，各VNFC 實(shí)例配置主備網(wǎng)絡(luò)功能倉庫實(shí)例地址，向主用實(shí)例1 發(fā)起注冊、發(fā)現(xiàn)等請求。VNFC 實(shí)例向主用實(shí)例1 注冊后，兩者建立心跳檢測，用于檢測對方的工作狀態(tài)。主用實(shí)例1 與備用實(shí)例2 實(shí)時(shí)同步數(shù)據(jù)，保證兩邊數(shù)據(jù)的一致性。正常情況下VNFC 實(shí)例不需要向備用實(shí)例2 注冊，備用實(shí)例2 也不需要向VNFC 實(shí)例提供服務(wù)。

圖6：網(wǎng)絡(luò)功能倉庫容災(zāi)方案

當(dāng)主用實(shí)例1 故障失效時(shí)，備用實(shí)例2 通過同步信息判斷主用實(shí)例1 故障，并接管業(yè)務(wù)。各VNFC 實(shí)例通過心跳檢測消息發(fā)現(xiàn)主用實(shí)例1 故障失效，將備用實(shí)例2 設(shè)為高優(yōu)先級。備用實(shí)例2 已經(jīng)同步了原主用實(shí)例1 的信息，各VNFC實(shí)例不需要重新向備用實(shí)例2 注冊，后續(xù)業(yè)務(wù)由備用實(shí)例2提供服務(wù)，即使主用實(shí)例1 故障恢復(fù)，也仍然由備用實(shí)例2提供服務(wù)。

3.1.3.2 會話管理類

用戶管理、接入管理、地址管理、AAA 建議采用N+1負(fù)荷分擔(dān)方式多DC 部署。UP 管理建議采用POOL 容災(zāi)方式多DC 部署。

以用戶管理采用N+1 負(fù)荷分擔(dān)的容災(zāi)方式（N ≥2）為例，其容災(zāi)組網(wǎng)如圖7 所示。正常情況下，所有業(yè)務(wù)由N+1個(gè)業(yè)務(wù)負(fù)荷分擔(dān)。用戶管理實(shí)例在進(jìn)入工作狀態(tài)后，主動(dòng)向網(wǎng)絡(luò)功能倉庫進(jìn)行注冊，并根據(jù)配置周期定時(shí)向網(wǎng)絡(luò)功能倉庫發(fā)送心跳消息，網(wǎng)絡(luò)功能倉庫通過心跳消息檢測以及維護(hù)此實(shí)例的工作狀態(tài)。

圖7：用戶管理容災(zāi)方案

當(dāng)實(shí)例1 故障失效時(shí)，其新業(yè)務(wù)由其他實(shí)例共同分擔(dān)，原承擔(dān)的會話通過會話遷移的方式由其他實(shí)例繼續(xù)處理。網(wǎng)絡(luò)功能倉庫將實(shí)例1 的狀態(tài)置為不可用，并向訂閱了實(shí)例1狀態(tài)的其他VNFC 發(fā)送狀態(tài)通知消息，觸發(fā)它們選擇其備份實(shí)例繼續(xù)處理會話。用戶管理實(shí)例的上下文等狀態(tài)數(shù)據(jù)存儲在統(tǒng)一數(shù)據(jù)存儲中，統(tǒng)一數(shù)據(jù)存儲負(fù)責(zé)對狀態(tài)數(shù)據(jù)進(jìn)行備份。在實(shí)例1 故障后，由其備份實(shí)例從統(tǒng)一數(shù)據(jù)存儲獲取上下文狀態(tài)數(shù)據(jù)并繼續(xù)處理業(yè)務(wù)。

UP 管理采用POOL 容災(zāi)方式，其容災(zāi)組網(wǎng)如圖8 所示。將UP 管理實(shí)例劃分為多個(gè)組，一組UP 管理實(shí)例組成一個(gè)POOL，為一個(gè)區(qū)域或一類業(yè)務(wù)的UP 提供服務(wù)。正常情況下，所有業(yè)務(wù)由POOL/組內(nèi)的所有實(shí)例共同承擔(dān)。UP 管理實(shí)例在進(jìn)入工作狀態(tài)后，主動(dòng)向網(wǎng)絡(luò)功能倉庫進(jìn)行注冊，并根據(jù)配置周期定時(shí)向網(wǎng)絡(luò)功能倉庫、用戶面UP 發(fā)送心跳消息。網(wǎng)絡(luò)功能倉庫通過心跳消息檢測以及維護(hù)此實(shí)例的工作狀態(tài)，用戶面UP 通過心跳消息檢測此實(shí)例是否正常工作。

圖8：UP 管理容災(zāi)方案

當(dāng)實(shí)例1 故障失效時(shí)，其新業(yè)務(wù)由POOL/組內(nèi)其他實(shí)例共同分擔(dān)，原承擔(dān)的會話通過會話遷移的方式由其他實(shí)例繼續(xù)處理。網(wǎng)絡(luò)功能倉庫將實(shí)例1 的狀態(tài)置為不可用，并向訂閱了實(shí)例1 狀態(tài)的其他VNFC 發(fā)送狀態(tài)通知消息，觸發(fā)它們選擇其備份實(shí)例繼續(xù)處理會話。實(shí)例1 管理的UP 去活原會話，在接收到其備份實(shí)例發(fā)起的會話恢復(fù)請求后，根據(jù)其備份實(shí)例提供的會話信息執(zhí)行本地會話重建流程，并與其備份實(shí)例進(jìn)行后續(xù)交互。UP 管理實(shí)例的上下文等狀態(tài)數(shù)據(jù)存儲在統(tǒng)一數(shù)據(jù)存儲中，統(tǒng)一數(shù)據(jù)存儲負(fù)責(zé)對狀態(tài)數(shù)據(jù)進(jìn)行備份。在實(shí)例1 故障后，由其備份實(shí)例從統(tǒng)一數(shù)據(jù)存儲獲取上下文狀態(tài)數(shù)據(jù)并繼續(xù)處理業(yè)務(wù)。

3.1.3.3 數(shù)據(jù)存儲類

統(tǒng)一數(shù)據(jù)存儲建議采用分布式技術(shù)存儲架構(gòu)，對數(shù)據(jù)提供1+M 的多副本數(shù)據(jù)冗余，并跨多個(gè)DC 部署。

3.2 用戶面容災(zāi)方案

UP 采用POOL 容災(zāi)方式，其容災(zāi)組網(wǎng)如圖9 所示。一組UP 組成一個(gè)POOL，負(fù)責(zé)一個(gè)區(qū)域或一類業(yè)務(wù)。正常情況下，所有話務(wù)由POOL 內(nèi)所有UP 共同承擔(dān)。UP 管理通過CP-UP 接口進(jìn)行UP 狀態(tài)的檢測與維護(hù)，按一定規(guī)則分擔(dān)選擇UP 執(zhí)行會話流程。

圖9：UP 容災(zāi)方案

當(dāng)POOL 內(nèi)UP 實(shí)例1 故障失效時(shí)，UP 管理在當(dāng)一定時(shí)間未正常接收到此UP 心跳響應(yīng)后，將其狀態(tài)置為故障，同時(shí)根據(jù)配置啟動(dòng)UP 的故障處理流程，選擇POOL 內(nèi)其他的UP 執(zhí)行會話流程。

4 總結(jié)

目前，運(yùn)營商的網(wǎng)絡(luò)面臨著云化轉(zhuǎn)型和重構(gòu)的挑戰(zhàn)，以數(shù)據(jù)中心為核心，基于軟件定義網(wǎng)絡(luò)、網(wǎng)絡(luò)功能虛擬化的云化網(wǎng)絡(luò)是通信網(wǎng)絡(luò)演進(jìn)的基本方向。與5G 核心網(wǎng)這類云原生網(wǎng)絡(luò)應(yīng)用技術(shù)不同，BRAS 從傳統(tǒng)網(wǎng)元逐步向轉(zhuǎn)變成云就緒vBRAS，并最終演進(jìn)成為云原生vBRAS。本文提出的云原生vBRAS 方案采用服務(wù)化架構(gòu)重構(gòu)vBRAS 控制面，無狀態(tài)化實(shí)現(xiàn)網(wǎng)絡(luò)功能，能夠滿足云原生動(dòng)態(tài)按需彈性縮放需求，并且具備較全面的容災(zāi)方案。