DWDM技術在B站基礎工程的落地實踐之路
來源:嗶哩嗶哩技術
網路管道作為B站影片點、直播穩定運營的重要基礎設施,為保證流暢高畫質的使用者體驗,其無時無刻不在面臨著極為嚴苛的考驗。與此同時,日益增長的使用者和內容稿件體量使業務流量迅速向資料中心集中。對於網際網路資料中心的規模要求也隨之水漲船高。但是,再大的資料中心也是無法避開單一節點的風險因素影響存在,無法在系統的安全冗餘性上提供足夠的保證。因此,多活的資料中心架構叢集概念也隨之浮出水面。這些資料中心叢集要協同運轉,相互之間互動資訊。於是就產生了DCI網路需求,即Data Center Interconnect。目前城域DCI和長途DCI是兩大最主要的DCI應用場景,其中城域DCI市場的發展尤為迅速。
但是,無論城域還是長途,究其底層基礎還是基於DWDM技術來實現光訊號的合理複用。目前光通訊技術的前沿發展分為光層和電層兩個方向。
光層在以不斷探索可用波長視窗為目標的前提下,已經從原先C80擴充套件至C120乃至C+L方案。
在某些特定廠商的技術庫內,
C4T+L4T:1529~1561nm(4THz) + 1572~1606nm(4THz)
C6T+L6T:1524~1572nm(6THz) + 1575~1626nm(6THz)
乃至 Super L Band 也已經整裝待發。
(本文結合實際使用出發,以C96為實際使用方式進行闡述)
電層則在以不斷探索單波長最大可承載通道頻寬為目標的前提下,從原先起步的單波10G 已經跳躍至當下最火熱的400G,乃至已初具規模的800G。目前600G和800G已經有多個廠家釋出相應的模組,特別是在資料中心互聯DCI也有了1.2T模組了,在相干光傳輸的線路側光模組演進也已經規劃到1.2T,採用5nm工藝的130G波特率。
在這裡我們要感謝夏農老爺子~在他老人家的英明領導下~今天各位看官可以安穩的刷到我們的這篇文章。
我們知道,相干600G支援每符號4bit的PM-QPSK,每符號6bit的PM-8QAM和每符號8bit的PM-16QAM。同時相比200G還增加了PM-32QAM(每符號10位)和PM-64QAM(每符號12位)調製。600G的波特率可以從25-72GBaud,各個廠家可能有差異。800G在調製方式上同600G一樣,但據瞭解,其波特率當前固定在96Gbaud,無論採用什麼調製。
(1)200Gb/s:採用PM-QPSK,此場景主要應用於長距傳輸。800G的200G速率波特率為96GBaud。而600G模組下的200G雖然也是採用QPSK,但是其波特率只需64GBaud。在以前文章中我們提到過,波特率越高,所佔用的頻譜寬度就越寬。96GBaud的通道頻寬為112.5GHz,64GBaud的通道頻寬只需要50/75GHz。根據計算同樣波段長度內,系統的總容量800G要比600G模組低。在傳輸距離的效能上,600G模組和800G模組的OSNR效能相差不大。當然從經濟市場的角度來看,無論是800G還是600G模組,應用200G速率,價效比都不划算。
(2)400Gb/s:800G模組採用8QAM,600G模組採用16QAM,波特率為64GBaud,此場景一般應於城域。800G模組使用此速率時,相比600G,其調製等級比600G要低,我們知道,調製等級越高,OSNR訊雜比越低。因此,600G模組在此400G速率下的效能要比800G模組低一些。
(3)600Gbs:在此速率下800G採用,頻譜寬度為112.5GHz,採用8QAM調製。600G模組若使用64QAM,通道間隔為75GHz,或者也可以使用32QAM。從調製等級上看,800G模組在600G速率的效能上要比600G模組好一些。
(4)800Gb/s:採用16QAM或者32QAM,當為800G速率的,在這裡就不對比600G模組了。800G模組可以使相干收發器在雙極化32QAM下以96Gbaud執行或者在雙極化16QAM下以120Gbaud執行。當前主流是在96GBaud波特率,使用4對DAC和ADC,一個鐳射器,一對光發射器和接收器。當前800G模組支援200G-800G速率可調。常用的800G模組只支援單路,且是不可插拔的固定MSA模組,考慮整合度等問題,功耗應該比600G要大得多。另外,在上面不同速率下的800G支援不同速率對比,其波特率是保持不變的。
不過在此過程中我們依然保持儘可能的減少殘餘頻譜。一般來說,為保障未來更高速率的譜寬的要求並考慮相容100G等速率的頻譜。更高速率的頻譜應該以50GHz或者75GHz的整數倍為基準。如下圖所示:
在以上電層和光層各領風騷的大前提下,我們的技術落地經歷了3個階段:
A.基礎設施落地階段
傳輸系統的搭建務必關注於底層系統的前置設計和規劃。因此我們在物理光通道層、裝置光層線路側、裝置電層支路側做了如下規劃和落地。
1.物理光通道層
針對線上環業務採用4線3路由的最低標準完成物理層的搭建工作,離線環業務實現雙路由FULL-MESH結構。
整體拓撲結構為:
2.裝置光層線路側
針對線上和離線的不同場景,我們採用了H廠商和G廠商兩家不同的光層場景裝置。
H廠商採用C80波段全40個偶數波長(單波長間隔100hz,此處有伏筆~後續解釋為什麼在這裡選擇這個配置),波長範圍 1560.61nm--1529.55nm,應用於離線大顆粒業務;
G廠商採用全程C96波段共計96個波長(單波長間隔50hz),波長範圍 1566.72nm–1528.77nm,應用於線上小顆粒業務。
3.裝置電層支路側
針對大顆粒離線和小顆粒線上業務的資料通訊需求。我們分別採用了200G 單波波長和400G 單波波長來解決資源的最大化利用率問題。
200G 波長間隔(50hz)部署於G廠商平面(線上業務),由於200G 波長間隔正好是50hz,因此與G廠商的C96光層完美契合。並且可以根據線上業務的多變靈活性快速部署上線。
光層保護拓撲組如圖所示:
電層部署架構如圖所示:
400G 波長間隔(75hz)部署於H廠商平面(離線業務),由此可以看出,為什麼我們在裝置光層線路側的設計使用了H廠商C80 全40偶波方式,這樣做可以無縫結合400G 單波業務落地。避免了剩餘40個奇波波長的配置硬體浪費。同時節約了光層機框的插槽(後續還有伏筆~)如下圖所示:節省了10,08,07兩個槽位。
同時在電層機框上將使用率提到了最高——即單框工作頻寬為8波 3.2T
至此,DWDM技術在目前的架構初步完成基本落地。
線上業務和離線業務的通道服務正式上線運營之後,不但降低了公司以往在業務通道上的成本支出,而且為提升各源站內伺服器計算效率起到了重要的承壓作用。
B.業務融合上升階段
在以往環境下,通道的質量容易受到外在因素的影響和制約。無論在頻寬還是質量上,還是在運維狀態的執行過程都無法獲得較為直接準確的資訊。這種情況自下而上的影響了整體網路環境的工作效率。在當前DWDM系統初期落地之後,容量和線路質量的問題已經迎刃而解。但是物理層線路發生故障後的原因以及運維響應效率問題始終沒有得到良好的解決。
主要歸結於以下2點。
1.光層通道故障後運維恢復時間過長,
對系統整體穩定有影響。
根據2022年的故障記錄資料顯示,光訊號從中斷開始到明確斷點所需要的時間佔整體運維事件時長的50%。透過針對於H廠商和G廠商兩家廠商的網管系統北向介面文件的解讀分析,在這兩套網管北向介面再做統一收斂。成功實現系統在出現光纜中斷故障後,OTDR隨之自動啟動,得出斷點資料後直接推送至當值人員。
該方案已經於2022年完成相關專利申報。
專利號:CN202211192482.6
專利名:一種基於原生傳輸網管系統的定製化光纜告警推送
原先的處理流程為:
經過最佳化後系統流程為:
北向介面配置示範:
北向介面對接設計和實現
透過管理系統,可以透過告警如表1觸發光纖質量檢測,發現斷纖會向網管主動上報FIBER_BREAK_POS告警如表1,提示光纖中斷位置。
表1 告警資訊詳表
透過北向介面,收集告警資訊,篩選FIBER_BREAK_POS告警資訊中的附加資訊欄位,獲取斷點資訊,同時關聯纖纜名稱,綜合判斷具體中斷哪條光纜以及斷點資訊。
關聯RMS系統-傳輸鏈路資源,獲取供應商聯絡方式,進行斷纖資訊以微信/企業微信/電話推送,通知供應商進行光纜最佳化。
具體的對接過程為:
告警獲取報文如下:
{ "time-created": "2022-03-07T17:21:46.000+08:00", "is-acked": true, "resource-alarm-parameters": { "perceived-severity": "warning", "is-cleared": true, "status-change": [ { "perceived-severity": "warning", "alarm-text": "Alarm cleared.", "time": "2022-03-07T17:22:19.000+08:00" } ], "last-changed": "2022-03-07T17:22:19.000+08:00" }, "x733-alarm-parameters": { "event-type": "equipment-alarm" }, "operator-state-change": [ { "operator": "值班人員", "text": "Alarm acknowledged.", "state": "ack", "time": "2022-03-07T17:47:52.835+08:00" } ], "alarm-parameters": { "repair-action": "", "ne-name": "1OTM", "location-info": "0-TO 2-2-F1DFIU-4(EIN/EOUT)-OTS:1", "native-probable-cause": "FIBER_BREAK_POS", "probable-cause": "光纖發生中斷,智慧光纖管理系統啟動探測,定位到光纖中斷位置後上報此告警", "root-cause-identifier": false, "ems-time": "2022-03-07T17:22:21.000+08:00", "alarm-serial-number": "1241122", "reason-id": 14009, "tenant-id": "default-organization-id", "tenant": "", "alarm-text": "光纖中斷位置提示", "other-info": "POS(斷纖點距離):27.8758km;NENAME(對端網元名稱):9-505-主OLA;ALMID(與此斷纖相關的告警流水號):1241103;DIR(方向):0-傳送; NOTE(異常說明):無; FIBERNAME(光纖名):f-728; SITENAME(對端光網元名):-; ", "ip-address": "127.0.0.1" }, "common-alarm-parameters": { "resource": "201e7860-d3f8-11eb-bfbb-903fea16475f", "resource-url": "/restconf/v2/data/huawei-nce-resource-inventory:network-elements/network-element/201e7860-d3f8-11eb-bfbb-903fea16475f", "related-alarm": [], "alarm-type-qualifier": "268374017-14009", "impacted-resource": [], "alarm-type-id": "equipment-alarm", "layer": "LR_Optical_Transmission_Section", "md-name": "Huawei/NCE", "product-type": "WDM_OTM" } }
經過本次最佳化加持提升後,整體的光通道運維事件時間平均縮短1-2小時。直接將原先的現場定位斷點步驟放在系統中實現。運維隊伍直接前往事故現場進行恢復即可。
2.當光層通道出現雙斷後,沒有可以
及時回補的手段。單一平面在雙斷
情況下造成數通裝置脫網。
在初期階段,某廠商電層裝置必須配合同樣該廠商的光層裝置(如圖1所示),客戶側光模組為廠商配套定製,並且硬體裝置必須配合廠家專有的EMS/NMS軟體進行管理(如圖2所示)。
圖1 DCI傳輸傳統硬體組網模式
圖2 DCI傳輸傳統網管組網模式
這種傳統方式有幾大弊端:
1、技術封閉,理論上光電層面是可以相互解耦的,而傳統廠商故意做成不解耦,以便於控制技術的權威性。
2、DCI傳輸網路的成本主要集中在電層裝置,系統初期建設成本低,但是擴容時候廠商會以技術唯一性為要挾進行提價,擴容成本大大增加。
3、DCI傳輸網路光層面投產後,受限於只能同一廠商的電層裝置使用,裝置資源利用率低(不擴容);
4、多廠商的情況下,存在多套EMS/NMS軟體,上聯介面型別眾多,資料採集效率和網路管理效率低。
這種架構會導致在單一平面光層出現雙斷的極端故障現象時,與該平面對接的數通裝置集體脫網。為了解決這一問題,我們嘗試將不同廠商的電層與光層根據基準波長資料進行相互交叉進行相互彌補使用。如下圖3所示:
圖3 光電解耦模型
客戶側模組解耦說明:
傳統情況下,客戶側模組由傳輸裝置商光電轉發單元配套提供,無法自主選擇客戶側模組供應商。
解耦模式下,我司可以自主選擇客戶側模組供應商,傳輸裝置供應商適配模組供應商的不同型號光模組。
傳輸光模組,可以與交換機模組一同採購,採購成本可以有效降低。
光層解耦說明:
解耦模式下,技術層面上,電層擴容時可以選擇不同供應商電層單元,實現不同廠家電層與光層混合組網;
商務層面上,由於競爭因素,一定程度上可以降低電層單元成本投資;
交付層面上,可以根據交付週期,選擇供貨週期更短的供貨商;
透過這種混合交叉方式,可以在出現單一平面光訊號雙斷髮生時。另一平面可以承載起部分流量,保證業務僅出現容量下降的影響。如果長時間無法恢復時,可以將其他受影響電層統一接入正常工作的平面。快速恢復正常通道流量需求。等故障平面修復完畢後,再次回切。
C.全網效率提升階段——
roadm,flex grid
時間進入道2023年後,隨著公司降本增效的工作持續推進。各源站之間的通道需求從原先的2天要縮短至半天內。同時要靈活排程各方向波長為突發的搬遷資料業務提供有效的保障。
為了解決這些需求,我們按照如下兩個方向去進行交付實現:
1.全網開始進入roadm化交付改造,
以降低手工對FOADM的時間成本,
提升快速交付開通效率。
如上圖所示,在當前架構下。POP-1至POP-5之間如果需要建立業務通道,需要在POP-3站點根據(POP-1 TO POP-3)和(POP-3 TO POP-5)這兩段落的可使用波長找出同一波長的通道進行手工對接。這種方法在資源和交付上都存在著較大的要求。資源上兩端落內使用的波長必須一致,交付上現場操作人員需要用尾纖將規劃的波道一一對應。
為了提升該工作的效率,我們引入了ROADM架構中的CDC 架構直接解決了上溯的兩個問題。
完成了POP-3的CDC改造後,POP-1,POP-2,POP-4,POP-5可以透過POP-3靈活排程各所需波長進行業務調通,從而提升通道的靈活性和工作交付效率。
2.全網通道開始出現400G ,
200G 波長混用現象。
對於目前現有波道產生較大的浪費。
在Roadm架構成功落地後,200G 波長和 400G 波長均開始又POP-3進行靈活交叉。很快將原定的C80 的偶數波長大量消耗。在當前情況下針對光層的擴容改造會對整網業務造成比較大的影響。為此,我們在進行通道波長掃描後發現400G 波長的75hz實際佔用了100hz頻寬。為了將現有波道效率提升至最大可用範圍。
我們再次引入了flex grid 靈活格柵。透過在固定柵格網路中,承載不同速率業務的波長的相鄰通道的間隔固定為50GHz,同時每個波長分配固定50GHz的光頻譜頻寬資源。此時承載不同業務速率的波長只需用ITU-T G.694.1定義的f=193.1+n×C.S的中心頻率來表示(C.S.:channel spacing表示相鄰通道的固定間隔,n為整數,n×C.S.代表了相對於193.1THz的位移量)。而對於靈活柵格的光網路,可以根據實際情況,為高速的業務分配較多的頻譜頻寬資源,對於較低的分配較少並且夠用的光頻譜資源,這樣網路的頻寬利用率會大為增加。此時承載不同速率業務的波長可以用兩個參量來表示:波長中心頻率與光頻譜頻寬。中心頻率計算方式也是f=193.1+n×C.S.但是靈活柵格支援更小的通道間隔粒度,最小可支援6.25GHz。n為整數,兩個相鄰通道波長之間的間隔可以為6.25GHz的任意整數倍(y×6.25GHz,y=n1-n2)。光波長頻譜頻寬為m×SWG(SWG:slot widthgranularity,光頻率隙頻寬粒度。而對於C.S代表的通道間隔粒度為6.25GHz的情況,對應的頻寬粒度SWG為12.5GHz;而對於C.S為12.5GHz的情況,相對的SWG對應為25GHz。即保證靈活網格中SWG是C.S.的兩倍數關係,這樣根據分配不同的n值與m值可以實現光譜資源無縫連線使用。這樣就可以在原先的光層中再次整理出20%的空間來供給業務通道。
光通訊傳輸的技術仍然在向前發展,經過這歷時近3年的應用落地。我們還將繼續在傳輸網管APN接入化,面對資料中心內大顆粒業務場景的通道需求繼續發力。走出屬於適合於自身發展所需要的技術路線。
參考資料
600G還是800G?– 通訊百科(%E8%BF%98%E6%98%AF800g%EF%BC%9F/)
CN102857835B - 靈活柵格光網路節點及節點間的鏈路屬性校驗方法 - Google Patents()
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024924/viewspace-2950164/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 容器技術在企業落地的最佳實踐
- B站雲原生混部技術實踐
- B站基於K8S的雲原生混部技術實踐K8S
- HDFS EC在B站的實踐
- HLS直播協議在B站的實踐協議
- B站資深運維工程師:DCDN在遊戲應用加速中的實踐運維工程師遊戲
- 京東技術中臺的Flutter實踐之路Flutter
- Flink 在 B 站的多元化探索與實踐
- Pytest 實踐:Python 測試技術基礎知識Python
- Apache Hudi 在 B 站構建實時資料湖的實踐Apache
- DataOps for LLM 的資料工程技術架構實踐架構
- 京東技術中臺Flutter實踐之路(二)Flutter
- 乾貨 | 京東技術中臺的Flutter實踐之路Flutter
- 後端技術雜談3:Lucene基礎原理與實踐後端
- Airbnb資料工程師的進階指南:技術基礎AI工程師
- B站基於Iceberg的湖倉一體架構實踐架構
- 教你玩轉微服務--基於DDD的微服務架構落地實踐之路微服務架構
- B站在實時音影片技術領域的探索與實踐
- Kubernetes在宜信落地實踐
- Flink 在米哈遊的落地實踐
- 【主流技術】Redis 在 Spring 框架中的實踐RedisSpring框架
- 智慧安全3.0實踐|SASE技術架構的演進之路架構
- 日均處理萬億資料!Flink在快手的應用實踐與技術演進之路
- 實時數倉在滴滴的實踐和落地
- B站基於Flink的海量使用者行為實時ETL實踐
- Serverless 工程實踐 | 零基礎上手 Knative 應用Server
- Apache Druid 在 Shopee 的工程實踐ApacheUI
- 直播預約丨《實時湖倉實踐五講》第三講:實時湖倉在袋鼠雲的落地實踐之路
- Kafka 負載均衡在 vivo 的落地實踐Kafka負載
- UI自動化技術在高德的實踐UI
- 【主流技術】ElasticSearch 在 Spring 專案中的實踐ElasticsearchSpring
- 創新的力量 天翼雲推動科技創新技術實踐落地
- 【基礎島·第3關】浦語提示詞工程實踐
- Faas在哈囉AI平臺的落地實踐AI
- DevOps 在企業專案中的實踐落地dev
- TDengine 在蔚來能源系統的落地實踐
- Kerberos 身份驗證在 ChunJun 中的落地實踐ROS
- Type Script 在流程設計器的落地實踐