韋國(guó)銳，陳立棟，于秋思，楊 曉（中國(guó)聯(lián)通廣東分公司，廣東廣州510000）

1 概述

近年來(lái)，基于自建云網(wǎng)絡(luò)部署虛擬化電信核心網(wǎng)已經(jīng)成為當(dāng)前進(jìn)行4G核心網(wǎng)以及后續(xù)5G核心網(wǎng)部署的必然選擇。2015年2月中國(guó)移動(dòng)提出了NovoNet計(jì)劃作為其未來(lái)網(wǎng)絡(luò)演進(jìn)的基礎(chǔ)，2015年9月中國(guó)聯(lián)通提出了基于SDN、NFV和云技術(shù)的網(wǎng)絡(luò)重構(gòu)基礎(chǔ)架構(gòu)CubeNet2.0，2016年6月中國(guó)電信提出了CTNet2025，為未來(lái)10年網(wǎng)絡(luò)重構(gòu)制定了相關(guān)規(guī)劃。各家電信運(yùn)營(yíng)商的網(wǎng)絡(luò)重構(gòu)計(jì)劃都是基于NFV和云化網(wǎng)絡(luò)。以CUBE-Net 2.0例，其核心技術(shù)是SDN、NFV和Cloud，它以超寬網(wǎng)絡(luò)和數(shù)據(jù)中心為載體，通過(guò)云化的服務(wù)平面，實(shí)現(xiàn)網(wǎng)絡(luò)集約化運(yùn)營(yíng)，適用于多種應(yīng)用服務(wù)場(chǎng)景。

從3GPP協(xié)議的發(fā)展來(lái)看，移動(dòng)網(wǎng)絡(luò)從Rel13的4G核心網(wǎng)，演進(jìn)到Rel14的EPC轉(zhuǎn)控分離，再到Rel15的5G NAS體系架構(gòu)，最終演進(jìn)到Rel16的5G SA體系架構(gòu)，從Rel14轉(zhuǎn)控分離開始，移動(dòng)網(wǎng)絡(luò)基本都是以通信云（DC）為基礎(chǔ)，而目前可選的災(zāi)備方案中，池組化災(zāi)備已經(jīng)成為大部分運(yùn)營(yíng)商及廠家的選擇。以某廠家在通信云上的虛擬化移動(dòng)分組網(wǎng)為例，采用了2套MME組成一個(gè)容災(zāi)池組，實(shí)現(xiàn)多DC間MME的主備容災(zāi)部署。

池組化容災(zāi)模式是在2個(gè)不同DC上分別部署MME網(wǎng)元，一個(gè)為主網(wǎng)元，另一個(gè)是備網(wǎng)元（冷備方式工作）。主備MME對(duì)周邊網(wǎng)元發(fā)布高低優(yōu)先級(jí)不同的相同業(yè)務(wù)路由，由于同一時(shí)刻只有發(fā)布高優(yōu)先級(jí)路由的網(wǎng)元可以和周邊網(wǎng)元互通，低優(yōu)先級(jí)路由不會(huì)進(jìn)入路由表，且主備MME業(yè)務(wù)邏輯地址相同，因此相對(duì)于周邊網(wǎng)元主備MME整體呈現(xiàn)為一個(gè)邏輯網(wǎng)元。

2個(gè)DC間的MME通過(guò)協(xié)商確定各自的主備身份，并基于多通道（容災(zāi)控制通道、容災(zāi)業(yè)務(wù)通道）的檢測(cè)結(jié)果進(jìn)行故障仲裁，主網(wǎng)元故障后，路由收斂到備網(wǎng)元，業(yè)務(wù)在備網(wǎng)元上重新接入。

在虛擬機(jī)出現(xiàn)故障時(shí)，雖然上述容災(zāi)方案可以將用戶業(yè)務(wù)倒換至冷備DC中的虛擬核心網(wǎng)網(wǎng)元上，但還是存在以下問(wèn)題。

a）用戶業(yè)務(wù)被中斷后會(huì)不斷嘗試在冷備核心網(wǎng)網(wǎng)元中重新建立連接狀態(tài)。

b）冷備DC中也需要建立一套虛擬化核心網(wǎng)網(wǎng)元，并保持對(duì)外連接，在計(jì)算資源、存儲(chǔ)資源、鏈路資源、動(dòng)力等方面存在一定的浪費(fèi)。

c）在5G時(shí)代，隨著網(wǎng)絡(luò)切片技術(shù)的應(yīng)用普及，同一個(gè)通信云內(nèi)的VNF網(wǎng)元數(shù)量會(huì)增多，網(wǎng)絡(luò)環(huán)境變得更加復(fù)雜，每個(gè)虛擬網(wǎng)元承載的業(yè)務(wù)量會(huì)減少，同時(shí)當(dāng)前標(biāo)準(zhǔn)定義的eMBB、uRLLC、mIoT 3類切片將承載在不同的虛擬網(wǎng)元上，與現(xiàn)有網(wǎng)絡(luò)承載模式不同。如果保持現(xiàn)有的池組化容災(zāi)體系，會(huì)增加網(wǎng)絡(luò)配置復(fù)雜度，降低管理效率。

在NFV架構(gòu)下，如果計(jì)算節(jié)點(diǎn)同時(shí)存儲(chǔ)用戶的狀態(tài)數(shù)據(jù)（即用戶上下文信息），那么在刪除計(jì)算節(jié)點(diǎn)之前需要將用戶上下文信息（包含IMSI、APN、QoS、速率、PDP類型、PDP地址等）遷移到其他節(jié)點(diǎn)上，否則會(huì)造成業(yè)務(wù)損失；同時(shí)在新增計(jì)算節(jié)點(diǎn)時(shí)需要將用戶上下文信息遷移過(guò)去，否則新增節(jié)點(diǎn)將不具備處理在線用戶數(shù)據(jù)業(yè)務(wù)的功能。

2 跨DC容災(zāi)系統(tǒng)設(shè)計(jì)

為了實(shí)現(xiàn)“彈性、伸縮、業(yè)務(wù)快速遷移”的網(wǎng)絡(luò)特性，基于以下原則重新設(shè)計(jì)NFV系統(tǒng)：前端無(wú)狀態(tài)、橫向可擴(kuò)展、單點(diǎn)失效不影響業(yè)務(wù)，分離業(yè)務(wù)處理單元和存儲(chǔ)節(jié)點(diǎn)。計(jì)算節(jié)點(diǎn)不再保存用戶狀態(tài)信息，只負(fù)責(zé)對(duì)信令進(jìn)行處理。業(yè)務(wù)處理單元在處理用戶消息（信令）時(shí)需要從數(shù)據(jù)庫(kù)中獲取用戶信息，再結(jié)合用戶的狀態(tài)對(duì)消息進(jìn)行處理。這也就是將一個(gè)傳統(tǒng)網(wǎng)元拆成多個(gè)虛擬網(wǎng)絡(luò)功能組件（VNFC——Virtualized Network FunctionComponent），具體的業(yè)務(wù)處理結(jié)構(gòu)如圖1所示。

圖1 業(yè)務(wù)處理結(jié)構(gòu)

基于上述業(yè)務(wù)處理結(jié)構(gòu)，虛擬機(jī)可以在網(wǎng)絡(luò)中不受限遷移，這也就實(shí)現(xiàn)了業(yè)務(wù)的靈活變更。本文采用圖2的方案對(duì)移動(dòng)核心網(wǎng)虛擬網(wǎng)元進(jìn)行業(yè)務(wù)無(wú)損容災(zāi)遷移，方案采用VxLAN和EVPN技術(shù)對(duì)虛擬網(wǎng)元中的計(jì)算資源進(jìn)行大二層容災(zāi)遷移；并基于原有SAN存儲(chǔ)模式的異地容災(zāi)系統(tǒng)，采用實(shí)時(shí)異步復(fù)制數(shù)據(jù)模式，在同一個(gè)地（市）的不同DC間進(jìn)行容災(zāi)。

2.1 虛擬機(jī)（VM）的跨DC遷移

虛擬機(jī)遷移，顧名思義，就是將虛擬機(jī)從一個(gè)物理機(jī)遷移到另一個(gè)物理機(jī)，但是要求在遷移過(guò)程中業(yè)務(wù)不能中斷。要做到這一點(diǎn)，需要保證虛擬機(jī)遷移前后，其IP地址、MAC地址等參數(shù)維持不變。這就決定了，虛擬機(jī)遷移必須發(fā)生在一個(gè)二層域中。所以虛擬機(jī)的跨DC遷移就需要在DC之間建立一個(gè)大二層的連接通道，基于現(xiàn)有技術(shù)和可維護(hù)性，本文采用Vx-LAN和EVPN技術(shù)在DC間建立一個(gè)大二層連接通道，以實(shí)現(xiàn)虛擬機(jī)的跨DC遷移。

2.1.1 VxLAN和EVPN技術(shù)

VxLAN是由IETF定義的NVO3（Network Virtualization over Layer 3）標(biāo)準(zhǔn)技術(shù)之一，采用L2 over L4（MAC-in-UDP）的報(bào)文封裝模式，將二層報(bào)文用三層協(xié)議進(jìn)行封裝，可實(shí)現(xiàn)二層網(wǎng)絡(luò)在三層范圍內(nèi)進(jìn)行擴(kuò)展，同時(shí)滿足數(shù)據(jù)中心大二層虛擬遷移和多租戶的需求。

圖2 業(yè)務(wù)無(wú)損容災(zāi)遷移網(wǎng)絡(luò)結(jié)構(gòu)

最初的VxLAN方案（RFC7348）中沒有定義控制平面，是通過(guò)手工配置VxLAN隧道，然后用流量泛洪的方式進(jìn)行主機(jī)地址的學(xué)習(xí)。這種方式實(shí)現(xiàn)上較為簡(jiǎn)單，但是會(huì)導(dǎo)致網(wǎng)絡(luò)中存在很多泛洪流量，網(wǎng)絡(luò)擴(kuò)展的難度較大。

為了解決上述問(wèn)題，VxLAN引入了EVPN（Ethernet VPN）作為其控制平面。EVPN參考了BGP/MPLS IP VPN的機(jī)制，通過(guò)擴(kuò)展BGP協(xié)議定義了幾種BGP EVPN路由，通過(guò)在網(wǎng)絡(luò)中發(fā)布路由來(lái)實(shí)現(xiàn)VTEP的自動(dòng)發(fā)現(xiàn)、主機(jī)地址學(xué)習(xí)。

采用EVPN作為控制平面具有以下一些優(yōu)勢(shì)。

a）可實(shí)現(xiàn)VTEP自動(dòng)發(fā)現(xiàn)、VxLAN隧道自動(dòng)建立，從而降低網(wǎng)絡(luò)部署、擴(kuò)展的難度。

b）EVPN可以同時(shí)發(fā)布二層MAC和三層路由信息。

c）可以減少網(wǎng)絡(luò)中泛洪流量。

2.1.2 虛擬機(jī)跨DC遷移的網(wǎng)絡(luò)設(shè)計(jì)

大二層的DCI連接建立時(shí)，VM1和VM2間的通信采用三段式VxLAN的方案，在數(shù)據(jù)中心A和數(shù)據(jù)中心B內(nèi)部分別創(chuàng)建VxLAN隧道，在數(shù)據(jù)中心的出口路由器（Transit Leaf）間也創(chuàng)建VxLAN隧道。同時(shí)在數(shù)據(jù)中心內(nèi)部和跨數(shù)據(jù)中心互聯(lián)鏈路上分別配置BGPEVPN，具體如下。

a）控制平面：Server Leaf 1在學(xué)習(xí)到VM1的MAC地址后，生成BGP EVPN路由發(fā)送給出口路由器1（Transit Leaf 1）；出口路由器1收到BGP EVPN路由后，先交叉到本地EVPN實(shí)例中，并在EVPN實(shí)例中生成VM1的MAC表項(xiàng)，再通過(guò)BGP EVPN方式將VM1的MAC地址更新發(fā)送給出口路由器2（Transit Leaf 2）；出口路由器2再?gòu)V播至Server Leaf 2，在Server Leaf 2中形成VM1的MAC地址項(xiàng)。同時(shí)，VM2的MAC地址經(jīng)由相同的方式轉(zhuǎn)發(fā)到Server Leaf 1，這樣VM1和VM2之間就建立了可以直接進(jìn)行二層數(shù)據(jù)轉(zhuǎn)發(fā)的路徑。

b）數(shù)據(jù)轉(zhuǎn)發(fā)平面：通過(guò)圖3所示的三段式VxLAN隧道，系統(tǒng)利用控制平面生成的MAC地址轉(zhuǎn)發(fā)表，將數(shù)據(jù)逐段轉(zhuǎn)發(fā)至對(duì)端VM。在Transit Leaf 1和Transit Leaf 2間建立端到端的VxLAN隧道時(shí)，需要實(shí)現(xiàn)Vx-LAN Mapping功能，并進(jìn)行一次VNI的轉(zhuǎn)換。

2.2 基于SAN存儲(chǔ)模式的異地容災(zāi)系統(tǒng)設(shè)計(jì)

虛擬機(jī)通過(guò)存儲(chǔ)區(qū)域網(wǎng)絡(luò)（SAN——Storage Aera Network）與存儲(chǔ)設(shè)備相連。隨著以太網(wǎng)技術(shù)的發(fā)展，特別是10GE網(wǎng)絡(luò)的普及，以太網(wǎng)的性能已經(jīng)能滿足存儲(chǔ)的要求。當(dāng)虛擬機(jī)有數(shù)據(jù)存取的需求時(shí)，數(shù)據(jù)可以通過(guò)IP SAN網(wǎng)絡(luò)高速傳輸?；赟AN存儲(chǔ)模式的異地容災(zāi)系統(tǒng)如圖4所示，其采用異步復(fù)制的方式同步主備數(shù)據(jù)中心的數(shù)據(jù)。各個(gè)設(shè)備廠家均有成熟的方案，在此不再贅述。

圖3 數(shù)據(jù)轉(zhuǎn)發(fā)平面

圖4 容災(zāi)備份結(jié)構(gòu)

3 結(jié)束語(yǔ)

傳統(tǒng)的容災(zāi)方案已經(jīng)無(wú)法適應(yīng)不同業(yè)務(wù)的質(zhì)量需求，而且在主備網(wǎng)元切換過(guò)程中用戶業(yè)務(wù)必須中斷。而本文中的跨DC的虛擬化核心網(wǎng)容災(zāi)體系可以利用現(xiàn)有技術(shù)，在不同的通信云之間，近乎無(wú)損地遷移虛擬化網(wǎng)元，新的容災(zāi)體系能更好地適應(yīng)通信云中虛擬機(jī)常態(tài)化遷移的特點(diǎn)，增加了數(shù)據(jù)中心的計(jì)算密度，可以按需啟用數(shù)據(jù)中心服務(wù)器和存儲(chǔ)資源，減少了人工管理的成本，提升了用戶業(yè)務(wù)感知。