高陸云
江蘇省通信管理局
隨著云計算技術的不斷發展,無論是Openstack、Cloudstack等原生態開源云計算平臺,還是VMWare Cloud等非開源云平臺,亦或是基于開源云平臺開發的適應各種特定場景需要的云平臺,不斷被應用到當前數據中心的建設方案中。傳統數據中心以設備為中心,存在將IT技術與業務分離看待、無彈性、不靈活等缺點,已經無法滿足日益復雜的業務需要。而云計算將整個IT體系架構從底層的基礎設施、應用開發和平臺,到業務軟件均作為一種服務,彈性按需交付。云計算的多租戶(Muti tenancy)概念要求不同租戶間網絡隔離,形成虛擬數據中心(VDC),極大地滿足了數據中心運營商的現實需要,VDC已成為當前數據中心的主要建設形式。
此外,與傳統數據中心不同,通信服務正向著寬帶化、融合化、智能化和云化的方向發展。傳統數據中心在架構上控制與轉發不分離,控制功能與轉發功能集中在同一網絡設備中,整個網絡是固定、不便于調整、無法集中控制的。而軟件定義網絡(SDN)將控制與轉發分離,控制功能集中到控制器上,網絡設備瘦身為轉發設備,這種架構正在驅動網絡和信息服務基礎設施新一輪的變革。數據中心集中網絡管理的現實需要,更使得SDN技術在VDC建設中得以廣泛使用。
因此,基于SDN技術的云平臺虛擬數據中心方案逐漸成為一種較為常見的數據中心建設方案。新技術的不斷涌入和發展,特別是云架構的普遍使用,加上虛擬化對傳統IT和CT的影響,給運維故障定位帶來了新的挑戰。
2008年,美國斯坦福大學提出了OpenFlow技術,并以此技術為基礎,實現了SDN控制轉發分離架構(見圖1)。OpenFlow技術以流表達方式抽象了數據平面轉發行為,并作為SDN體系中數據平面與控制平面之間通信接口的標準。OpenFlow協議使得設備內OpenFlow通道與外部控制器之間互通。

圖1 OpenFlow基本架構
2012年,ONF(開放網絡基金會)在軟件定義網絡的白皮書中首次提出了軟件定義網絡的體系框架(見圖2):基礎設施層、控制層、應用層。其中控制層是核心,由SDN控制軟件組成,基礎設施層由簡化了的去除控制等功能后的網絡設備組成,應用層由業務應用組成。控制層與基礎設施層通過控制數據平面接口(如OpenFlow)交互,控制層與應用層之間通過API接口交互網絡狀態信息。

圖2 SDN體系框架圖
在虛擬數據中心(VDC)應用SDN后的網絡體系架構如圖3所示,包含應用層、編排層、控制層和轉發層。
應用層:包括云化管理平臺、SDN應用程序、SDN管理程序、網管等。
編排層:包括SDN編排器等。負責分配資源、冗余管理、錯誤管理和彈性調整,實現云業務中網絡資源的自動開通與部署。
控制層:主要包括SDN控制器。負責流量控制來確保智能網絡,滿足云業務對網絡資源的需求。
轉發層:包括SDN轉發設備等。可為軟件設備或傳統網絡轉發設備。
圖4是一個典型的基于SDN技術的數據中心組網架構,采用SDN+VXLAN(虛擬擴展局域網)組網,SDN網絡控制器處于核心地位,通過OpenFlow協議控制網絡中的設備,包括虛擬的vSwitch(虛擬交換機),物理的TOR交換機等。其中vSwitch作為VTEP(VXLAN隧道終端)。

圖4 基于SDN技術的數據中心組網架構圖
基于SDN技術的虛擬數據中心運維實踐中,網絡故障定位面臨新的挑戰。從技術實現角度看,IT和網絡的虛擬化帶來了動態性、易變性、開放性、多元性,因此,給故障定位帶來的挑戰是多方面的。
1.3.1 傳統網管的挑戰
傳統網管是對網絡中的物理設備進行監控和管理的重要手段。常見的功能有告警監控、性能任務監控、拓撲展示、設備配置等。然而在SDN場景下,控制和轉發功能分離,控
制功能被集中到SDN控制器上,轉發功能可由傳統物理設備實現或軟件實現(如Open vSwitch等)。傳統網管無法實現對SDN場景下控制和轉發功能的完整監控管理。此外,在OpenStack等云化管理場景下,IT虛擬化技術的廣泛使用使得原先針對物理服務器的監控管理方案更顯得力不從心。
1.3.2 巡檢工具的挑戰
巡檢工具對于網絡運維是必不可少的,可以將預先設定的檢查項進行定期周期性核實,然而亦存在許多弊端。首先,巡檢工具的執行需人工觸發,執行頻率較低,半年甚至一年才執行一次,即使1個月或者幾個星期執行一次,對于故障定位來說,實時性仍不夠;其次,巡檢是預置的、固定的,是不靈活的,無法研判未知故障,只能對已有故障進行巡檢核實;再次,巡檢工具按照固定的模式核查網絡中是否存在異常,發生故障時無法有針對性地快速查找原因。
1.3.3 運維人員學習的挑戰
虛擬化、特別是云化技術的發展,以及新概念、新技術的涌入和迭代,使得領域間不斷整合、融合,以往按照網絡所承擔的功能分工運維的模式不再適用。運維人員需打破現有知識結構,學習并融會貫通各領域知識技能,才能適應當前的運維工作需要。
SDN組網架構下,數據中心核心協議就是OpenFlow協議。此外,VXLAN組網亦是最常用的技術。相較VLAN組網,VXLAN組網突破了4000+子網的限制,且由于VXLAN協議架設在UDP協議之上,具備較高的擴展性。因此,在基于SDN技術的VDC故障定位中,基于OpenFlow與VXLAN的協議分析是首選方案。基于協議分析的故障定位技術將故障排查重點放在OpenFlow交換機和VXLAN VTEP兩個協議載體上。
OpenFlow交換機,即支持OpenFlow協議的交換機,其內包含流表、組表以及連接SDN控制器的OpenFlow通道。在現有商用產品中,OpenFlow交換機可以是Open vSwitch,也可以是傳統交換機改造后的混合物理OpenFlow交換機。故障排查定位以OpenFlow交換機流表分析為主線,核查數據包走向和丟失問題。
VXLAN VTEP就是封裝和解封裝VXLAN包圍的網絡設備。在數據中心組網中,一般有三種角色:VXLAN VTEP、VXLAN GW、VXLAN IP GW。VTEP是直接與虛機(VM)連接的設備,負責原始以太網包圍的VXLAN封裝與解封裝。VXLAN GW將VXLAN報文轉換成對應的傳統二層網絡送到傳統以太網,適用于VXLAN網絡內服務器與遠端服務器的二層互聯。VXLAN IP GW將VXLAN報文轉換成傳統三層報文送至IP網絡,適用于VXLAN網絡內服務器與遠端終端之間的三層互訪,同時也用作不同VXLAN網絡互通。VTEP故障排查以VXLAN報文流向為主線,核查數據包走向及丟失問題。
OpenFlow交換機支持OpenFlow協議,按照流表規則對流量進行處理(轉發、丟失、緩存)。流表分三個部分:頭域、統計域、動作域。其中統計域保存了該條流表項所匹配報文的基本統計信息,包含流表、流、接口、隊列統計信息,統計項的值在OpenFlow交換機運行時自動更新。故障定位可以從負載、時延、丟包率、流量分布等維度分析。
在當前基于SDN技術的VDC網絡組網中,存在物理網絡設備,例如物理OpenFlow交換機、用于接入或者匯聚的交換機、VXLAN網關等。站在物理設備的角度,排查接口數據包的實際狀況,以及包轉發路由狀態,也是故障定位的一個方向,一般可以確定物理設備硬件或者軟件故障。
在傳統網絡管理架構下,網元設備通過SNMP等協議上報告警信息,這些告警信息實時告知維護人員設備上的異常。然而這些告警都是以設備為單位組織上報的,設備間的告警是割裂開來的,缺乏統一分析。此外,設備上的告警信息往往無法涵蓋發生問題的具體原因。現實維護場景下常出現這樣的狀況:上報告警與本次故障無關,花費人力解決了一些非緊急的故障,而急需解決的故障卻被耽擱;或者告警量過大,無法精確快速篩選哪條或者哪些告警與本次故障相關。因此,告警的只能融合分析是很有必要的,特別是在虛擬化場景下。
系統可集成在傳統網管中,作為傳統網管的深層次功能對外整體展現,開發架構上采用BS架構,客戶端只需要安裝瀏覽器即可使用。
系統可以部署在物理服務器上或者虛機上,網絡上需打通與SDN網絡的網絡通道,或者直接部署在SDN網絡中,外部網絡遠程訪問系統需要通過防火墻隔離(見圖5)。系統還可以通過支持的協議向第三方管理系統上報信息。在部署形態上,支持單機或者冗余備份部署。

圖5 故障定位系統網絡部署架構圖
系統實現架構如圖6所示。管理網絡接入適配接口負責接入適配SDN網絡中的所有管理設備(包括Open vSwitch),接口包括SNMP、Netconf、FTP等。在管理網絡接入適配接口之上是故障定位核心模塊,包括協議分析模塊、流量分析模塊、設備分析模塊、告警智能綜合分析模塊,從4個維度(第2章節介紹的4類故障定位技術)綜合定位分析網絡故障。而安全鑒權模塊、日志記錄模塊、系統監控模塊是系統基本模塊,上報第三方適配接口主要用于對接第三方系統,支持SNMP、FTP等協議。

圖6 故障定位系統實現架構圖
基于SDN技術的虛擬數據中心網絡故障定位系統通過協議、流量、設備、告警智能綜合分析開展多維度的網絡故障定位分析,在當前SDN網絡數據中心實際場景下具備較高的應用價值。系統以端到端的概念代替網絡設備端點的割裂分析,加快了網絡故障定位的速率,可以較好地緩解運維故障定位壓力。在某虛擬數據中心為期一年的運維實踐中,系統故障定位有效性達85%以上,效率提升近50%。
本文以分析當前流行的基于SDN技術的虛擬數據中心網絡架構為切入點,介紹了虛擬化和云化后的數據中心采用SDN技術后的整體架構及應用,研究了虛擬數據中心運維故障定位技術,并基于技術方案提出了虛擬數據中心網絡故障定位系統設計和實現架構。實踐效果表明,該系統對于輔助運維人員快速定位、分析和研判虛擬數據中心網絡故障,提升工作效率具備較高的應用價值。然而,在具體實踐過程中,網絡故障的定位仍有諸多難點,部分網絡故障定位采用預置知識尚無法自動研判,還需人力輔助,有待進一步研究。