??

針對光網絡故障實時定位這個挑戰，現有的光網絡管控系統是否最優？針對硬件設備的異構性，能否實現統一并直接的管控？針對光層瞬發事件，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個數量級以上。

?

?

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的业界首创，腾讯网络平台部实现大规模光网络实时管控系统TOOP的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。