close

‍‍

針對光網絡故障實時定位這個挑戰,現有的光網絡管控系統是否最優?針對硬件設備的異構性,能否實現統一併直接的管控?針對光層瞬發事件,SNMP技術是否還有用武之地?針對大規模故障實時定位,傳統的管控軟件是否還能應對?本文展示了一個全新的系統,來解答上述幾個問題。

在即將舉行的計算機網絡頂會 NSDI 2022 上,騰訊網絡平台部設計並實現大規模光網絡實時管控系統TOOP(又名OpTel),通過開放解耦合實現設備統一管控,光層流式遙測實現高精度數據採集,騰訊雲平台實現海量數據分析和故障實時定位。該系統不僅能發現光層瞬發事件,而且將故障定位效率提升2個數量級以上,相關成果已被 NSDI2022 接收為 Oral 論文。

論文地址:
https://www.usenix.org/conference/nsdi22/presentation/miao

01 / 背景介紹
雲服務提供商(如騰訊、谷歌和微軟等)通過在多個區域建立儘可能多的數據中心從而支持具有不同帶寬和延遲需求的應用程序。數據中心光網絡作為連接各個數據中心的基礎設施,對數據中心間數據傳輸的可靠性起着至關重要的作用。在底層,光網絡基礎架構主要由光學硬件(如光轉發設備、放大器、波分復用設備等)和光纖組成。任何組件的故障(即光層事件)都會影響數據中心間的連接性,影響雲服務的SLA。因此,提高光網絡的可靠性和可用性,及時發現並定位光層事件至關重要。

圖1 (a)現有guang kong系統;(b)TOOP

不幸的是,現有的光網絡管控系統並不是為實時檢測和定位的光層事件而設計的。具體而言,現有系統從光學硬件中採集採樣或聚合的光層性能數據,但這種粗粒度的數據既無法檢測光層瞬發事件,也不適合雲租戶快速定位光層事件。圖1(a)說明了現有管控系統的局限性。舉例而言,持續幾十秒的瞬發光層事件造成客戶側視頻體驗質量下降(如視頻卡頓等)。現有雲提供商通過管控系統採集15分鐘粒度的光層數據,無法檢測或定位這種瞬發的光層事件。另外,現有系統在檢測和定位長期事件也很慢。雲提供商構建多層管控架構從各個供應商特定的控制器查詢數據來拼接底層光網絡的整體視圖,該方式既複雜又容易出錯。我們對故障工單數據集的分析表明,對光學硬件故障進行故障定位往往需要花費數小時到數天的時間。

現有管控系統的局限性可歸因於三個關鍵因素。
01
首先,光網絡碎片化的管控設計。構建光網絡的設備出自於多家供應商,現有管控系統通過結構連接各家供應商管控軟件的北向接口實現光層數據訪問。儘管供應商的多樣性對於雲提供商阻止壟斷和避免並發性故障至關重要,但這種碎片化的管控設計並不可取,容易造成光層數據無法直接訪問以及很難拼湊出同一時刻的網絡視圖。
02
其次,SNMP協議的局限性。現有管控系統依賴於SNMP協議從設備收集數據。SNMP通過在設備側執行各種數據管理任務,如創建本地 MIB 數據庫,支持對數據庫的讀寫操作等。更快的讀寫會導致設備側更高的CPU使用率,影響設備性能。鑑於設備側有限的資源,基於SNMP 協議很難實現高精度的數據輪詢。
03
最後,管控軟件的局限性。供應商提供的管控軟件往往為管理設計的,並不一定適用於大規模高精度的數據採集。同時,這類管控軟件往往部署在固定計算和內存資源的單服務器端。隨着光網絡規模的擴大或數據採集頻率的增加,現有軟件會遭遇諸多瓶頸。

本研究採用的方案:我們設計並實現基於光層流式遙測的TOOP系統。該系統可以通過設備模型標準化實現對異構設備性能數據的直接訪問,通過光層流式遙測實現高精度數據採集,最後基於騰訊雲平台實現海量數據分析和光層故障實時定位(圖 1(b))。

02 / 技術創新
TOOP系統的核心創新:

01
與供應商無關的集中控制。TOOP 將光網絡的多層控制架構簡化為單層控制架構,實現對廠商異構設備的性能數據直接訪問。為了實現這種設計,我們為光學設備構建標準化模型,使得廠商異構設備能夠完成統一抽象。該標準化模型由兩個基本部分組成:邏輯模型和數據模型。
02
簡化設備側遙測管道。TOOP採用「基於推送」的光層流式遙測取代了「基於拉取」SNMP方式,將計算密集型的數據管理任務從光學設備側卸載到基於雲的控制器側,實現更高頻率性能數據數據。具體而言,光層流式遙測主要由以下關鍵部分組成:Telemetry Manager、Telemetry Agent、Cache和Aggregator。其中,Telemetry Manager模塊與集中控制器交互,負責從控制器接收配置並配置其他組件。Telemetry Agent模塊從不同的模塊讀取數據並將它們存儲到本地Cache,Aggregator負責將緩存中的數據推送至集中控制器。

03 / 實現細節
圖2: TOOP系統架構圖

圖 2 展示了 TOOP的系統架構。
01
與供應商無關的集中控制(Vendor-agnostic Centralized Control):在開放解耦合系統中,通過構建光層標準化模型以抽象供應商的實現細節,實現與供應商無關的方式直接管控光學設備。

光學設備標準化模型(Standardized Model for Optical Devices)

在多供應商光網絡中,不同光學設備在功能上是相似的,但其具體實現邏輯和工作流程卻因供應商而異,這種異構性使得對不同供應商提供的設備管控變得複雜。因此,我們通過構建光層標準化模型,以抽象出供應商特定的實現細節。該模型主要由兩部分組成:邏輯模型和數據模型。
邏輯模型(Logic model)。第一個挑戰是每個供應商的物理組件及其工作流程都是不同的。為了應對這一挑戰,組件邏輯模型首先確定一組邏輯組件,這些組件在不同的供應商設備之間是通用的,然後模型進一步標準化這些組件之間的工作流程。
數據模型(data model)。第二個挑戰是設備內部物理組件在功能相同的情況下提供的能力因供應商而異。例如,供應商 1 提供的光放大器的增益範圍為 15-25 dB,而供應商 2 可能為 20-30 dB。這種異質性使得設備管理變得複雜。組件數據模型包含每個組件可配置參數的具體描述。當每個設備連接到控制器時,控制器從設備獲取數據表並初始化相應的可配置參數值。

集中式數據收集(Centralized Data Collection)

標準化模型允許集中控制器直接訪問異構設備,實現對各廠商設備的統一管控。TOOP的集中控制器由三個關鍵模塊組成:全局管理組件、彈性數據採集組件和實時分析組件,用於及時大規模地檢測和排除光學事件。
全局管理組件(Global manager)由兩部分組成:設備管理器(DevMgr)和拓撲管理器(TopoMgr)。DevMgr 負責配置光學設備,利用相關的標準化模型以與供應商無關的方式配置設備。這個過程是通過Netconf協議向設備發送 Yang 文件實現。TopoMgr 維護光設備的物理拓撲,以提供全局光網絡視圖。
彈性數據採集組件(Scalable collector)由多個採集器節點組成的集群,旨在彈性地提供計算和存儲資源以適應不同的採集頻率和網絡規模。藉助騰訊雲的彈性資源池,該組件可按需進行性能擴展。同時,該方式依靠負載均衡器在集群內各個採集器之間分配負載,有效應對單點故障問題。

實時分析組件(Real-time analytics)結合來自採集組件的光層數據和來自全局管理組件的拓撲信息來實現光層事件快速檢測和定位的任務。實時分析組件的工作流程由兩部分組成:事件檢測和故障定位。為了檢測劣化或故障事件,該組件實時監控光層性能指標的值,並在該值超過閾值時發出警報。同時,它會啟動故障定位過程,該過程是基於預先採集的故障指紋來進行的。

圖3: 光層流式遙測

02
流線型遙測管道(Streamlined Telemetry Pipeline)實時光層事件檢測和定位需要從光學設備採集細粒度的數據。SNMP由於在資源受限的光學設備本地執行各種數據管理任務,無法實現細粒度的數據採集。相比之下,TOOP 通過基於推送的遙測管道將計算密集型數據操作從光學設備卸載到集中控制器,實現以更高頻率收集光層數據。圖 3 描述了基於推送的光層流式遙測架構。該流程主要由以下關鍵部分組成:遙測管理器、遙測代理、緩存組件和聚合組件。下面,我們將詳細介紹它們。

遙測管理器(Telemetry manager):將計算密集型數據管理任務從光學設備卸載到控制器往往需要在設備上進行初步配置。遙測管理器首先從集中控制器獲取 YANG 文件,解析該文件以配置遙測代理和聚合器。聚合器配置為周期性地發起連接以將光層數據從本地緩存推送到控制器。遙測代理側主要有三個部分配置:數據的目的地(即緩存),數據源(即線卡中的模塊)和遙測代理應該推送的周期數據。


遙測代理(Telemetry agent):一旦經過配置完成後,遙測代理會定期通過供應商特定的內部協議執行線卡級數據收集,並將數據推送到本地緩存。數據主要有兩種產生方式:實時值和累積值。

實時值是給定時間間隔內的採樣數據。接收器捕獲物理光信號並將其轉換為模擬電流,模數轉換器用於將模擬電流轉換為電壓的數字值,並進一步存儲在 RAM 中。遙測代理定期讀取 RAM 以通過供應商特定協議收集數據。

累計值是給定時間周期內累積的計數值。數字信號處理器接收到的數字信號並以某種方式進行判定,將結果其累存入至寄存器中。


緩存組件(Cache):該組件存儲從遙測代理接收的性能數據,然後將數據以設備級進行捆綁。緩存組件可以兼容不同遙測代理在不同頻率下推送的性能數據。


聚合組件(Aggregator):該組件定期啟動連接以從本地緩存中獲取批量數據。由於緩存組件提供的數據更細粒度,聚合組件通過合併數據以獲得具有代表性的統計信息,並通過 gRPC 協議將數據推送至控制器。


04 / 實驗效果

綜合評估

01
數據採集開銷評估
圖 4顯示了在不同採集頻率和不同性能指標下設備側的 CPU 使用率。可以看出,採集頻率從 1 秒增加到 0.1 秒,基於 SNMP 的方法會導致設備側 CPU 使用率從 34% 提高到 96%,凸顯了 SNMP 難以應對如此高頻率的數據採集請求。相比之下,基於推送的光層流式遙測Telemetry方法,其導致設備側 CPU的 使用率增長平緩,從 19% 增加到 25%,證明了基於推送的光層流式遙測Telemetry方法有效性。與此類似,對於不同數量的性能指標的採集,其光層流式遙測Telemetry方法依舊有效。
圖4 設備側CPU使用量

02
光層事件檢測的有效性
Ephemeral Degradation (E-D)是短期劣化, Persistent Degradation (P-D)是長期劣化, Ephemeral Interruption (E-I)是短期中斷,Persistent Interruption (P-I) 為長期中斷。圖 5和表1顯示了在不同採集頻率下檢測到的事件數量和基於1秒和15分鐘數據粒度下事件檢測的正確性。從圖5可以看出,隨着採集頻率從 15 分鐘增加到 1 秒,檢測出的事件數量會提升。對於E-I和E-D事件,粗粒度的數據往往無法檢測到短暫光層事件。但對於長期中斷和長期劣化事件,基於1秒粒度的數據檢測出的事件量卻小於15秒粒度數據檢測出的事件量。這是由於基於粗粒度的數據無法檢測出短暫光層事件。如表1所示,基於粗粒度的數據往往會把短暫光層事件誤識別為長期事件。

圖 5:不同採集頻率下檢測到的事件數量
表1:基於1秒和15分鐘數據粒度下事件檢測的正確性

03
光層事件定位的實時性
表 2顯示了傳統系統和TOOP系統定位事件的時間比較。可以看出,TOOP不僅能夠將定位事件時間縮短至1分鐘以內,相比於原來系統有2個數量級的提升。同時,TOOP能夠發現一些抖動和劣化事件,這是傳統系統無法比擬的。
表2:傳統系統和TOOP系統定位事件的時間比較

04
光層事件的可預測性
圖6顯示了光層中斷事件的可預測性。可以看出,對於5秒的窗口,如果該窗口內發生了 E-D 事件,則 P-I事件發生的概率會增加到 20% 左右,而對於1分鐘的窗口,概率會增加到 40%,這表明 E-D 事件與未來的 P-I 事件密切相關。類似地,P-D 事件與未來的 P-I 事件密切相。另一個觀察結果是,過去的 P-I 事件對未來 P-I 事件的預測性較低,這表明 P-I 事件是無記憶的。
圖 6:光層中斷事件的可預測性

05 / 總結
本文介紹了TOOP,通過標準化模型實現多廠商異構設備的集中控制,通過將數據管理任務從設備卸載到控制器實現秒級光層數據採集。通過近半年的部署,與現有系統相比,TOOP可準確檢測出2倍以上光層事件。同時,TOOP實現秒級故障定位,相較原系統提升了2個數量級以上。


arrow
arrow
    全站熱搜
    創作者介紹
    創作者 鑽石舞台 的頭像
    鑽石舞台

    鑽石舞台

    鑽石舞台 發表在 痞客邦 留言(0) 人氣()