作者簡介

Lightworker，攜程網(wǎng)絡(luò)技術(shù)專家，關(guān)注光纖通信、DCI傳輸技術(shù)領(lǐng)域。

一、背景

光傳輸網(wǎng)絡(luò)（簡稱OTN）是一種基于光纖技術(shù)的通信網(wǎng)絡(luò)。它利用光纖作為傳輸介質(zhì)，將信息以光的形式進(jìn)行傳輸。其憑借DWDM（密集型波分復(fù)用）技術(shù)以及保護(hù)倒換技術(shù)，可以實現(xiàn)大帶寬、低延遲、高可靠的數(shù)據(jù)傳輸，因此廣泛應(yīng)用于多個數(shù)據(jù)中心互聯(lián)場景。國內(nèi)外大型互聯(lián)網(wǎng)公司通過租用運營商光纖自建傳輸網(wǎng)絡(luò)，能夠大大降低IDC之間數(shù)據(jù)傳輸?shù)某杀尽Ｍ瑯樱瑪y程也擁有自建的光傳輸網(wǎng)絡(luò)（簡稱TOTN），主要用于承載骨干網(wǎng)跨數(shù)據(jù)中心流量以及IT辦公上網(wǎng)流量。

作為底層物理網(wǎng)絡(luò)，TOTN直接面對運營商光纜，需應(yīng)對頻繁出現(xiàn)的光纜故障。眾所周知，國內(nèi)基建仍處于發(fā)展階段，運營商光纜經(jīng)常被施工挖斷。據(jù)美國運營商Level3的統(tǒng)計，其光纖網(wǎng)絡(luò)大概每年每千公里就會中斷1次；中國電信大概每年會發(fā)生50次以上干線光纜中斷；而在印度，幾乎每天都會中斷幾次甚至十幾次。可見，光纜中斷的次數(shù)與當(dāng)?shù)厣鐣?jīng)濟(jì)的發(fā)展程度密切相關(guān)。

攜程TOTN自建成以來，平均每年監(jiān)測到20余次光纜中斷。因此在提供大容量傳輸?shù)耐瑫r，如果能夠在發(fā)生光纜故障的時候，光網(wǎng)絡(luò)可以自動切換，使業(yè)務(wù)帶寬不受影響，甚至不感知故障，將極大的提升網(wǎng)絡(luò)可靠性。

圖1 光纜挖斷現(xiàn)場

二、整體架構(gòu)

攜程傳輸網(wǎng)絡(luò)為雙平面帶保護(hù)設(shè)計，每個IDC部署完全獨立的2套傳輸設(shè)備，分別連接2條不同路由的光纖，組成完全獨立的2個傳輸平面。

圖2 TOTN拓?fù)鋱D

正常狀態(tài)下，業(yè)務(wù)走在直達(dá)鏈路上，當(dāng)主用光纜中斷時，傳輸系統(tǒng)會將業(yè)務(wù)切換至備用通道繞行。主備通道切換時間遵循ITU-TG.783和ITU-TG.841標(biāo)準(zhǔn)，小于50ms。

圖3 光網(wǎng)絡(luò)保護(hù)

圖4 光纜故障時業(yè)務(wù)流向

通過上述保護(hù)機(jī)制，能夠解決光纜中斷時業(yè)務(wù)自動切換，帶寬不損失，并且抵御同時發(fā)生2處光纜中斷的極端情況。

但與此同時，有一個問題一直困擾我們，就是傳輸切換的時候兩端網(wǎng)絡(luò)設(shè)備端口存在flapping的情況，導(dǎo)致業(yè)務(wù)有相應(yīng)的報錯產(chǎn)生。

三、問題分析

網(wǎng)絡(luò)設(shè)備接口從down到up的時間因為不同設(shè)備不同光模塊有差異，且網(wǎng)絡(luò)層的二層及三層收斂時間因網(wǎng)絡(luò)架構(gòu)的不同存在不確定因素（通常認(rèn)為是秒級中斷），因此每次傳輸切換都會造成一定時間的業(yè)務(wù)不可用。通常表現(xiàn)在敏感業(yè)務(wù)的報錯，如Redis。Redis作為內(nèi)存數(shù)據(jù)庫，對網(wǎng)絡(luò)抖動非常敏感，幾乎每次光纜中斷切換都有感知。

比如3月17日12:00 傳輸A平面，光纖發(fā)生閃斷，骨干網(wǎng)CSR in方向錯包。

圖5 骨干網(wǎng)報錯

比如9月11日19:44 B平面光纜中斷，傳輸切換時Redis大量報錯，如下圖：

圖6 Redis報錯

要解決傳輸切換導(dǎo)致網(wǎng)絡(luò)設(shè)備端口flapping問題，業(yè)界一直沒有成熟的標(biāo)準(zhǔn)方案。通過對其它互聯(lián)網(wǎng)公司的調(diào)研，比較常用的方案是在交換機(jī)接口上配置link-delay，即路由器收到鏈路中斷的信號后，延時一段時間將鏈路狀態(tài)置為down，在這段時間里，如果鏈路恢復(fù)，即保持鏈路up狀態(tài)，不產(chǎn)生down狀態(tài)，避免了鏈路的頻繁抖動。

我們也嘗試了這種方式，但發(fā)現(xiàn)有諸如設(shè)備不支持、配置不生效等問題，一直無法達(dá)到預(yù)期的效果。原因是link delay不是IEEE標(biāo)準(zhǔn)，不同廠商的網(wǎng)絡(luò)設(shè)備對該功能的支持不盡相同。為此，傳輸業(yè)務(wù)的分配只能分?jǐn)傇诓煌墓饫|路由，確保光纜中斷時至少有一半業(yè)務(wù)不受影響，但這始終無法解決業(yè)務(wù)有感知的問題。例如A端至Z端需開通200G業(yè)務(wù)，必須分?jǐn)偟絻蓚€不同平面，每個100G業(yè)務(wù)參與各自平面的倒換。

圖7 業(yè)務(wù)分?jǐn)偸疽鈭D

另外我們在調(diào)研中發(fā)現(xiàn)，有些公司為了使link-delay生效，將延時設(shè)置成2s。這樣的設(shè)置雖然使傳輸保護(hù)倒換生效，但一旦保護(hù)機(jī)制出現(xiàn)故障，路由層面的切換將因此損失2s的寶貴時間。

四、技術(shù)研究

2023年，TOTN引入了支持5ms倒換的DCI產(chǎn)品，該產(chǎn)品通過二個方面的改進(jìn)將傳輸50ms的倒換時間提升至5ms。一是應(yīng)用了磁光開關(guān)，磁光開關(guān)原理是利用法拉第旋光效應(yīng), 通過外加磁場的變化來改變磁光晶體對入射偏振光偏振面的作用, 從而達(dá)到切換光路的作用。由于無機(jī)械移動部件, 可靠性高, 并且開關(guān)速度快；二是通過預(yù)先將備用通道的光纜參數(shù)錄入DSP芯片，在倒換時節(jié)省了重新計算參數(shù)的時間。

圖8 光開關(guān)原理

我們希望通過縮短光開關(guān)切換的時間，解決網(wǎng)絡(luò)設(shè)備端口flapping的問題。但在實際應(yīng)用中，即使傳輸?shù)箵Q時間已經(jīng)壓縮到5ms，網(wǎng)絡(luò)設(shè)備的端口仍然會flapping。通過對產(chǎn)品參數(shù)的研究和調(diào)試后，我們發(fā)現(xiàn)，當(dāng)光纜中斷時，傳輸光層會向兩端電層板卡發(fā)送AIS信號，電層板卡收到AIS信號后會向網(wǎng)絡(luò)設(shè)備發(fā)送Local_Fault告警，當(dāng)網(wǎng)絡(luò)設(shè)備收到該告警后，端口即變?yōu)閐own（IEEE 802.3ae）。通過設(shè)置傳輸系統(tǒng)延時發(fā)送該信號（默認(rèn)4*50ms），只要傳輸切換在該時間段內(nèi)完成，即不會向網(wǎng)絡(luò)設(shè)備發(fā)送該信號，因此端口就不會flapping。

圖9 故障信號傳遞示意圖

在DCI產(chǎn)品成功實現(xiàn)了切換無感知后，我們希望在現(xiàn)網(wǎng)傳統(tǒng)產(chǎn)品中也找到類似的參數(shù)進(jìn)行調(diào)整。因為告警延時傳遞與5ms倒換時間無關(guān)，即使是50ms的倒換時間，如果能讓網(wǎng)絡(luò)設(shè)備端口不感知光纜抖動，也會對業(yè)務(wù)穩(wěn)定性帶來極大的提升。

五、 優(yōu)化方案

為了實現(xiàn)網(wǎng)絡(luò)傳統(tǒng)產(chǎn)品支持無感切換，通過與廠商技術(shù)溝通，得出的結(jié)論是需要將100GE業(yè)務(wù)映射方式由BIT透明映射調(diào)整為MAC透明映射（會中斷業(yè)務(wù)），然后再設(shè)置告警參數(shù)延時200ms傳遞。

由于TOTN從來沒有使用過MAC透明映射方式，對此，我們協(xié)調(diào)設(shè)備廠商在實驗室專門做了MAC映射和BIT映射的測試驗證。結(jié)論是兩種方式吞吐量沒有區(qū)別，延時有差異，BIT映射時對64-9600Byte的幀都是24us，MAC映射時隨幀長增大而增大，但最大9600時，也就25us，可以忽略不計。

圖10 實驗環(huán)境拓?fù)?/span>

圖11 RFC2544測試結(jié)果

因此我們制定了優(yōu)化方案，先調(diào)整傳輸A平面，灰度運行一段時間后再調(diào)整B平面。

六、 驗證效果

8月18日對傳輸A平面進(jìn)行優(yōu)化：100GE業(yè)務(wù)映射方式采用MAC透明映射，告警參數(shù)延時傳遞200ms。經(jīng)測試驗證，可實現(xiàn)傳輸光纜主備切換對網(wǎng)絡(luò)設(shè)備端口無感知，Redis無感知。

在真實的故障場景下也同樣得到了驗證。如9月7日15:13傳輸A平面發(fā)生光纜中斷故障，Redis報錯無異常尖峰。

圖12 優(yōu)化后Redis報錯

經(jīng)過經(jīng)一個月的灰度驗證后，我們于9月15日對傳輸B平面進(jìn)行優(yōu)化，并且將告警參數(shù)延時傳遞時間在200ms的基礎(chǔ)進(jìn)一步縮短至100ms，同樣經(jīng)測試驗證Redis無感知。

七、 未來規(guī)劃

為保持架構(gòu)的統(tǒng)一性，我們將重新定義攜程光網(wǎng)絡(luò)設(shè)備技術(shù)標(biāo)準(zhǔn)，要求新入網(wǎng)的OTN設(shè)備必須支持BIT映射的告警延遲下插。同時，推動各供應(yīng)商全面支持該功能，使之成為光纜故障場景下的一種最佳實踐。

抵御光纜故障是個業(yè)界公認(rèn)的難題，頭部互聯(lián)網(wǎng)公司都在此栽過跟頭。通過上述一系列實踐，我們在抵御光纜故障方面已經(jīng)做到了領(lǐng)先水平。光網(wǎng)絡(luò)運維是個長期過程，無感知切換只是其中一小部分，更多的是告警發(fā)現(xiàn)、性能監(jiān)測以及光纜路由識別，避免同路由情況的發(fā)生。