高陸云

江蘇省通信管理局

0 引言

隨著云計(jì)算技術(shù)的不斷發(fā)展，無論是Openstack、Cloudstack等原生態(tài)開源云計(jì)算平臺(tái)，還是VMWare Cloud等非開源云平臺(tái)，亦或是基于開源云平臺(tái)開發(fā)的適應(yīng)各種特定場景需要的云平臺(tái)，不斷被應(yīng)用到當(dāng)前數(shù)據(jù)中心的建設(shè)方案中。傳統(tǒng)數(shù)據(jù)中心以設(shè)備為中心，存在將IT技術(shù)與業(yè)務(wù)分離看待、無彈性、不靈活等缺點(diǎn)，已經(jīng)無法滿足日益復(fù)雜的業(yè)務(wù)需要。而云計(jì)算將整個(gè)IT體系架構(gòu)從底層的基礎(chǔ)設(shè)施、應(yīng)用開發(fā)和平臺(tái)，到業(yè)務(wù)軟件均作為一種服務(wù)，彈性按需交付。云計(jì)算的多租戶（Muti tenancy）概念要求不同租戶間網(wǎng)絡(luò)隔離，形成虛擬數(shù)據(jù)中心（VDC），極大地滿足了數(shù)據(jù)中心運(yùn)營商的現(xiàn)實(shí)需要，VDC已成為當(dāng)前數(shù)據(jù)中心的主要建設(shè)形式。

此外，與傳統(tǒng)數(shù)據(jù)中心不同，通信服務(wù)正向著寬帶化、融合化、智能化和云化的方向發(fā)展。傳統(tǒng)數(shù)據(jù)中心在架構(gòu)上控制與轉(zhuǎn)發(fā)不分離，控制功能與轉(zhuǎn)發(fā)功能集中在同一網(wǎng)絡(luò)設(shè)備中，整個(gè)網(wǎng)絡(luò)是固定、不便于調(diào)整、無法集中控制的。而軟件定義網(wǎng)絡(luò)（SDN）將控制與轉(zhuǎn)發(fā)分離，控制功能集中到控制器上，網(wǎng)絡(luò)設(shè)備瘦身為轉(zhuǎn)發(fā)設(shè)備，這種架構(gòu)正在驅(qū)動(dòng)網(wǎng)絡(luò)和信息服務(wù)基礎(chǔ)設(shè)施新一輪的變革。數(shù)據(jù)中心集中網(wǎng)絡(luò)管理的現(xiàn)實(shí)需要，更使得SDN技術(shù)在VDC建設(shè)中得以廣泛使用。

因此，基于SDN技術(shù)的云平臺(tái)虛擬數(shù)據(jù)中心方案逐漸成為一種較為常見的數(shù)據(jù)中心建設(shè)方案。新技術(shù)的不斷涌入和發(fā)展，特別是云架構(gòu)的普遍使用，加上虛擬化對傳統(tǒng)IT和CT的影響，給運(yùn)維故障定位帶來了新的挑戰(zhàn)。

1 基于SDN技術(shù)的云平臺(tái)、虛擬化數(shù)據(jù)中心

1.1 SDN體系架構(gòu)介紹

2008年，美國斯坦福大學(xué)提出了OpenFlow技術(shù)，并以此技術(shù)為基礎(chǔ)，實(shí)現(xiàn)了SDN控制轉(zhuǎn)發(fā)分離架構(gòu)（見圖1）。OpenFlow技術(shù)以流表達(dá)方式抽象了數(shù)據(jù)平面轉(zhuǎn)發(fā)行為，并作為SDN體系中數(shù)據(jù)平面與控制平面之間通信接口的標(biāo)準(zhǔn)。OpenFlow協(xié)議使得設(shè)備內(nèi)OpenFlow通道與外部控制器之間互通。

圖1 OpenFlow基本架構(gòu)

2012年，ONF（開放網(wǎng)絡(luò)基金會(huì)）在軟件定義網(wǎng)絡(luò)的白皮書中首次提出了軟件定義網(wǎng)絡(luò)的體系框架（見圖2）：基礎(chǔ)設(shè)施層、控制層、應(yīng)用層。其中控制層是核心，由SDN控制軟件組成，基礎(chǔ)設(shè)施層由簡化了的去除控制等功能后的網(wǎng)絡(luò)設(shè)備組成，應(yīng)用層由業(yè)務(wù)應(yīng)用組成?？刂茖优c基礎(chǔ)設(shè)施層通過控制數(shù)據(jù)平面接口（如OpenFlow）交互，控制層與應(yīng)用層之間通過API接口交互網(wǎng)絡(luò)狀態(tài)信息。

圖2 SDN體系框架圖

1.2 SDN在數(shù)據(jù)中心的應(yīng)用

在虛擬數(shù)據(jù)中心（VDC）應(yīng)用SDN后的網(wǎng)絡(luò)體系架構(gòu)如圖3所示，包含應(yīng)用層、編排層、控制層和轉(zhuǎn)發(fā)層。

應(yīng)用層：包括云化管理平臺(tái)、SDN應(yīng)用程序、SDN管理程序、網(wǎng)管等。

編排層：包括SDN編排器等。負(fù)責(zé)分配資源、冗余管理、錯(cuò)誤管理和彈性調(diào)整，實(shí)現(xiàn)云業(yè)務(wù)中網(wǎng)絡(luò)資源的自動(dòng)開通與部署。

控制層：主要包括SDN控制器。負(fù)責(zé)流量控制來確保智能網(wǎng)絡(luò)，滿足云業(yè)務(wù)對網(wǎng)絡(luò)資源的需求。

轉(zhuǎn)發(fā)層：包括SDN轉(zhuǎn)發(fā)設(shè)備等。可為軟件設(shè)備或傳統(tǒng)網(wǎng)絡(luò)轉(zhuǎn)發(fā)設(shè)備。

圖4是一個(gè)典型的基于SDN技術(shù)的數(shù)據(jù)中心組網(wǎng)架構(gòu)，采用SDN+VXLAN（虛擬擴(kuò)展局域網(wǎng)）組網(wǎng)，SDN網(wǎng)絡(luò)控制器處于核心地位，通過OpenFlow協(xié)議控制網(wǎng)絡(luò)中的設(shè)備，包括虛擬的vSwitch（虛擬交換機(jī)），物理的TOR交換機(jī)等。其中vSwitch作為VTEP（VXLAN隧道終端）。

圖4 基于SDN技術(shù)的數(shù)據(jù)中心組網(wǎng)架構(gòu)圖

1.3 網(wǎng)絡(luò)故障定位面臨的新挑戰(zhàn)

基于SDN技術(shù)的虛擬數(shù)據(jù)中心運(yùn)維實(shí)踐中，網(wǎng)絡(luò)故障定位面臨新的挑戰(zhàn)。從技術(shù)實(shí)現(xiàn)角度看，IT和網(wǎng)絡(luò)的虛擬化帶來了動(dòng)態(tài)性、易變性、開放性、多元性，因此，給故障定位帶來的挑戰(zhàn)是多方面的。

1.3.1 傳統(tǒng)網(wǎng)管的挑戰(zhàn)

傳統(tǒng)網(wǎng)管是對網(wǎng)絡(luò)中的物理設(shè)備進(jìn)行監(jiān)控和管理的重要手段。常見的功能有告警監(jiān)控、性能任務(wù)監(jiān)控、拓?fù)湔故?、設(shè)備配置等。然而在SDN場景下，控制和轉(zhuǎn)發(fā)功能分離，控

制功能被集中到SDN控制器上，轉(zhuǎn)發(fā)功能可由傳統(tǒng)物理設(shè)備實(shí)現(xiàn)或軟件實(shí)現(xiàn)（如Open vSwitch等）。傳統(tǒng)網(wǎng)管無法實(shí)現(xiàn)對SDN場景下控制和轉(zhuǎn)發(fā)功能的完整監(jiān)控管理。此外，在OpenStack等云化管理場景下，IT虛擬化技術(shù)的廣泛使用使得原先針對物理服務(wù)器的監(jiān)控管理方案更顯得力不從心。

1.3.2 巡檢工具的挑戰(zhàn)

巡檢工具對于網(wǎng)絡(luò)運(yùn)維是必不可少的，可以將預(yù)先設(shè)定的檢查項(xiàng)進(jìn)行定期周期性核實(shí)，然而亦存在許多弊端。首先，巡檢工具的執(zhí)行需人工觸發(fā)，執(zhí)行頻率較低，半年甚至一年才執(zhí)行一次，即使1個(gè)月或者幾個(gè)星期執(zhí)行一次，對于故障定位來說，實(shí)時(shí)性仍不夠；其次，巡檢是預(yù)置的、固定的，是不靈活的，無法研判未知故障，只能對已有故障進(jìn)行巡檢核實(shí)；再次，巡檢工具按照固定的模式核查網(wǎng)絡(luò)中是否存在異常，發(fā)生故障時(shí)無法有針對性地快速查找原因。

1.3.3 運(yùn)維人員學(xué)習(xí)的挑戰(zhàn)

虛擬化、特別是云化技術(shù)的發(fā)展，以及新概念、新技術(shù)的涌入和迭代，使得領(lǐng)域間不斷整合、融合，以往按照網(wǎng)絡(luò)所承擔(dān)的功能分工運(yùn)維的模式不再適用。運(yùn)維人員需打破現(xiàn)有知識結(jié)構(gòu)，學(xué)習(xí)并融會(huì)貫通各領(lǐng)域知識技能，才能適應(yīng)當(dāng)前的運(yùn)維工作需要。

2 基于云計(jì)算技術(shù)的虛擬數(shù)據(jù)中心運(yùn)維故障定位技術(shù)研究

2.1 基于協(xié)議分析的故障定位技術(shù)

SDN組網(wǎng)架構(gòu)下，數(shù)據(jù)中心核心協(xié)議就是OpenFlow協(xié)議。此外，VXLAN組網(wǎng)亦是最常用的技術(shù)。相較VLAN組網(wǎng)，VXLAN組網(wǎng)突破了4000+子網(wǎng)的限制，且由于VXLAN協(xié)議架設(shè)在UDP協(xié)議之上，具備較高的擴(kuò)展性。因此，在基于SDN技術(shù)的VDC故障定位中，基于OpenFlow與VXLAN的協(xié)議分析是首選方案。基于協(xié)議分析的故障定位技術(shù)將故障排查重點(diǎn)放在OpenFlow交換機(jī)和VXLAN VTEP兩個(gè)協(xié)議載體上。

OpenFlow交換機(jī)，即支持OpenFlow協(xié)議的交換機(jī)，其內(nèi)包含流表、組表以及連接SDN控制器的OpenFlow通道。在現(xiàn)有商用產(chǎn)品中，OpenFlow交換機(jī)可以是Open vSwitch，也可以是傳統(tǒng)交換機(jī)改造后的混合物理OpenFlow交換機(jī)。故障排查定位以O(shè)penFlow交換機(jī)流表分析為主線，核查數(shù)據(jù)包走向和丟失問題。

VXLAN VTEP就是封裝和解封裝VXLAN包圍的網(wǎng)絡(luò)設(shè)備。在數(shù)據(jù)中心組網(wǎng)中，一般有三種角色：VXLAN VTEP、VXLAN GW、VXLAN IP GW。VTEP是直接與虛機(jī)（VM）連接的設(shè)備，負(fù)責(zé)原始以太網(wǎng)包圍的VXLAN封裝與解封裝。VXLAN GW將VXLAN報(bào)文轉(zhuǎn)換成對應(yīng)的傳統(tǒng)二層網(wǎng)絡(luò)送到傳統(tǒng)以太網(wǎng)，適用于VXLAN網(wǎng)絡(luò)內(nèi)服務(wù)器與遠(yuǎn)端服務(wù)器的二層互聯(lián)。VXLAN IP GW將VXLAN報(bào)文轉(zhuǎn)換成傳統(tǒng)三層報(bào)文送至IP網(wǎng)絡(luò)，適用于VXLAN網(wǎng)絡(luò)內(nèi)服務(wù)器與遠(yuǎn)端終端之間的三層互訪，同時(shí)也用作不同VXLAN網(wǎng)絡(luò)互通。VTEP故障排查以VXLAN報(bào)文流向?yàn)橹骶€，核查數(shù)據(jù)包走向及丟失問題。

2.2 基于流量分析的故障定位技術(shù)

OpenFlow交換機(jī)支持OpenFlow協(xié)議，按照流表規(guī)則對流量進(jìn)行處理（轉(zhuǎn)發(fā)、丟失、緩存）。流表分三個(gè)部分：頭域、統(tǒng)計(jì)域、動(dòng)作域。其中統(tǒng)計(jì)域保存了該條流表項(xiàng)所匹配報(bào)文的基本統(tǒng)計(jì)信息，包含流表、流、接口、隊(duì)列統(tǒng)計(jì)信息，統(tǒng)計(jì)項(xiàng)的值在OpenFlow交換機(jī)運(yùn)行時(shí)自動(dòng)更新。故障定位可以從負(fù)載、時(shí)延、丟包率、流量分布等維度分析。

2.3 基于物理網(wǎng)絡(luò)設(shè)備分析的故障定位技術(shù)

在當(dāng)前基于SDN技術(shù)的VDC網(wǎng)絡(luò)組網(wǎng)中，存在物理網(wǎng)絡(luò)設(shè)備，例如物理OpenFlow交換機(jī)、用于接入或者匯聚的交換機(jī)、VXLAN網(wǎng)關(guān)等。站在物理設(shè)備的角度，排查接口數(shù)據(jù)包的實(shí)際狀況，以及包轉(zhuǎn)發(fā)路由狀態(tài)，也是故障定位的一個(gè)方向，一般可以確定物理設(shè)備硬件或者軟件故障。

2.4 基于告警智能融合分析的故障定位技術(shù)

在傳統(tǒng)網(wǎng)絡(luò)管理架構(gòu)下，網(wǎng)元設(shè)備通過SNMP等協(xié)議上報(bào)告警信息，這些告警信息實(shí)時(shí)告知維護(hù)人員設(shè)備上的異常。然而這些告警都是以設(shè)備為單位組織上報(bào)的，設(shè)備間的告警是割裂開來的，缺乏統(tǒng)一分析。此外，設(shè)備上的告警信息往往無法涵蓋發(fā)生問題的具體原因?，F(xiàn)實(shí)維護(hù)場景下常出現(xiàn)這樣的狀況：上報(bào)告警與本次故障無關(guān)，花費(fèi)人力解決了一些非緊急的故障，而急需解決的故障卻被耽擱；或者告警量過大，無法精確快速篩選哪條或者哪些告警與本次故障相關(guān)。因此，告警的只能融合分析是很有必要的，特別是在虛擬化場景下。

3 虛擬數(shù)據(jù)中心網(wǎng)絡(luò)故障定位系統(tǒng)設(shè)計(jì)

系統(tǒng)可集成在傳統(tǒng)網(wǎng)管中，作為傳統(tǒng)網(wǎng)管的深層次功能對外整體展現(xiàn)，開發(fā)架構(gòu)上采用BS架構(gòu)，客戶端只需要安裝瀏覽器即可使用。

3.1 系統(tǒng)部署網(wǎng)絡(luò)架構(gòu)

系統(tǒng)可以部署在物理服務(wù)器上或者虛機(jī)上，網(wǎng)絡(luò)上需打通與SDN網(wǎng)絡(luò)的網(wǎng)絡(luò)通道，或者直接部署在SDN網(wǎng)絡(luò)中，外部網(wǎng)絡(luò)遠(yuǎn)程訪問系統(tǒng)需要通過防火墻隔離（見圖5）。系統(tǒng)還可以通過支持的協(xié)議向第三方管理系統(tǒng)上報(bào)信息。在部署形態(tài)上，支持單機(jī)或者冗余備份部署。

3.2 系統(tǒng)實(shí)現(xiàn)架構(gòu)

圖5 故障定位系統(tǒng)網(wǎng)絡(luò)部署架構(gòu)圖

系統(tǒng)實(shí)現(xiàn)架構(gòu)如圖6所示。管理網(wǎng)絡(luò)接入適配接口負(fù)責(zé)接入適配SDN網(wǎng)絡(luò)中的所有管理設(shè)備（包括Open vSwitch），接口包括SNMP、Netconf、FTP等。在管理網(wǎng)絡(luò)接入適配接口之上是故障定位核心模塊，包括協(xié)議分析模塊、流量分析模塊、設(shè)備分析模塊、告警智能綜合分析模塊，從4個(gè)維度（第2章節(jié)介紹的4類故障定位技術(shù)）綜合定位分析網(wǎng)絡(luò)故障。而安全鑒權(quán)模塊、日志記錄模塊、系統(tǒng)監(jiān)控模塊是系統(tǒng)基本模塊，上報(bào)第三方適配接口主要用于對接第三方系統(tǒng)，支持SNMP、FTP等協(xié)議。

圖6 故障定位系統(tǒng)實(shí)現(xiàn)架構(gòu)圖

3.3 預(yù)期成效

基于SDN技術(shù)的虛擬數(shù)據(jù)中心網(wǎng)絡(luò)故障定位系統(tǒng)通過協(xié)議、流量、設(shè)備、告警智能綜合分析開展多維度的網(wǎng)絡(luò)故障定位分析，在當(dāng)前SDN網(wǎng)絡(luò)數(shù)據(jù)中心實(shí)際場景下具備較高的應(yīng)用價(jià)值。系統(tǒng)以端到端的概念代替網(wǎng)絡(luò)設(shè)備端點(diǎn)的割裂分析，加快了網(wǎng)絡(luò)故障定位的速率，可以較好地緩解運(yùn)維故障定位壓力。在某虛擬數(shù)據(jù)中心為期一年的運(yùn)維實(shí)踐中，系統(tǒng)故障定位有效性達(dá)85%以上，效率提升近50%。

4 結(jié)束語

本文以分析當(dāng)前流行的基于SDN技術(shù)的虛擬數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)為切入點(diǎn)，介紹了虛擬化和云化后的數(shù)據(jù)中心采用SDN技術(shù)后的整體架構(gòu)及應(yīng)用，研究了虛擬數(shù)據(jù)中心運(yùn)維故障定位技術(shù)，并基于技術(shù)方案提出了虛擬數(shù)據(jù)中心網(wǎng)絡(luò)故障定位系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)架構(gòu)。實(shí)踐效果表明，該系統(tǒng)對于輔助運(yùn)維人員快速定位、分析和研判虛擬數(shù)據(jù)中心網(wǎng)絡(luò)故障，提升工作效率具備較高的應(yīng)用價(jià)值。然而，在具體實(shí)踐過程中，網(wǎng)絡(luò)故障的定位仍有諸多難點(diǎn)，部分網(wǎng)絡(luò)故障定位采用預(yù)置知識尚無法自動(dòng)研判，還需人力輔助，有待進(jìn)一步研究。