一加Ace2 Pro真機揭曉 鈦空灰配色質感拉滿
終于，在經過了幾波預熱之后，一加Ace2 Pro的外觀真機圖在網上出現了。還是博主數碼閑聊站曝光的，這次的外觀設計還是延續了一加11的方案，只是細節上有了調整，例如新加入了鈦空灰
作者簡介
Lightworker，攜程網絡技術專家，關注光纖通信、DCI傳輸技術領域。
光傳輸網絡（簡稱OTN）是一種基于光纖技術的通信網絡。它利用光纖作為傳輸介質，將信息以光的形式進行傳輸。其憑借DWDM（密集型波分復用）技術以及保護倒換技術，可以實現大帶寬、低延遲、高可靠的數據傳輸，因此廣泛應用于多個數據中心互聯場景。國內外大型互聯網公司通過租用運營商光纖自建傳輸網絡，能夠大大降低IDC之間數據傳輸的成本。同樣，攜程也擁有自建的光傳輸網絡（簡稱TOTN），主要用于承載骨干網跨數據中心流量以及IT辦公上網流量。
作為底層物理網絡，TOTN直接面對運營商光纜，需應對頻繁出現的光纜故障。眾所周知，國內基建仍處于發展階段，運營商光纜經常被施工挖斷。據美國運營商Level3的統計，其光纖網絡大概每年每千公里就會中斷1次；中國電信大概每年會發生50次以上干線光纜中斷；而在印度，幾乎每天都會中斷幾次甚至十幾次?？梢?，光纜中斷的次數與當地社會經濟的發展程度密切相關。
攜程TOTN自建成以來，平均每年監測到20余次光纜中斷。因此在提供大容量傳輸的同時，如果能夠在發生光纜故障的時候，光網絡可以自動切換，使業務帶寬不受影響，甚至不感知故障，將極大的提升網絡可靠性。
圖1 光纜挖斷現場
攜程傳輸網絡為雙平面帶保護設計，每個IDC部署完全獨立的2套傳輸設備，分別連接2條不同路由的光纖，組成完全獨立的2個傳輸平面。
圖2 TOTN拓撲圖
正常狀態下，業務走在直達鏈路上，當主用光纜中斷時，傳輸系統會將業務切換至備用通道繞行。主備通道切換時間遵循ITU-TG.783和ITU-TG.841標準，小于50ms。
圖3 光網絡保護
圖4 光纜故障時業務流向
通過上述保護機制，能夠解決光纜中斷時業務自動切換，帶寬不損失，并且抵御同時發生2處光纜中斷的極端情況。
但與此同時，有一個問題一直困擾我們，就是傳輸切換的時候兩端網絡設備端口存在flapping的情況，導致業務有相應的報錯產生。
網絡設備接口從down到up的時間因為不同設備不同光模塊有差異，且網絡層的二層及三層收斂時間因網絡架構的不同存在不確定因素（通常認為是秒級中斷），因此每次傳輸切換都會造成一定時間的業務不可用。通常表現在敏感業務的報錯，如Redis。Redis作為內存數據庫，對網絡抖動非常敏感，幾乎每次光纜中斷切換都有感知。
比如3月17日12:00 傳輸A平面，光纖發生閃斷，骨干網CSR in方向錯包。
圖5 骨干網報錯
比如9月11日19:44 B平面光纜中斷，傳輸切換時Redis大量報錯，如下圖：
圖6 Redis報錯
要解決傳輸切換導致網絡設備端口flapping問題，業界一直沒有成熟的標準方案。通過對其它互聯網公司的調研，比較常用的方案是在交換機接口上配置link-delay，即路由器收到鏈路中斷的信號后，延時一段時間將鏈路狀態置為down，在這段時間里，如果鏈路恢復，即保持鏈路up狀態，不產生down狀態，避免了鏈路的頻繁抖動。
我們也嘗試了這種方式，但發現有諸如設備不支持、配置不生效等問題，一直無法達到預期的效果。原因是link delay不是IEEE標準，不同廠商的網絡設備對該功能的支持不盡相同。為此，傳輸業務的分配只能分攤在不同的光纜路由，確保光纜中斷時至少有一半業務不受影響，但這始終無法解決業務有感知的問題。例如A端至Z端需開通200G業務，必須分攤到兩個不同平面，每個100G業務參與各自平面的倒換。
圖7 業務分攤示意圖
另外我們在調研中發現，有些公司為了使link-delay生效，將延時設置成2s。這樣的設置雖然使傳輸保護倒換生效，但一旦保護機制出現故障，路由層面的切換將因此損失2s的寶貴時間。
2023年，TOTN引入了支持5ms倒換的DCI產品，該產品通過二個方面的改進將傳輸50ms的倒換時間提升至5ms。一是應用了磁光開關，磁光開關原理是利用法拉第旋光效應, 通過外加磁場的變化來改變磁光晶體對入射偏振光偏振面的作用, 從而達到切換光路的作用。由于無機械移動部件, 可靠性高, 并且開關速度快；二是通過預先將備用通道的光纜參數錄入DSP芯片，在倒換時節省了重新計算參數的時間。
圖8 光開關原理
我們希望通過縮短光開關切換的時間，解決網絡設備端口flapping的問題。但在實際應用中，即使傳輸倒換時間已經壓縮到5ms，網絡設備的端口仍然會flapping。通過對產品參數的研究和調試后，我們發現，當光纜中斷時，傳輸光層會向兩端電層板卡發送AIS信號，電層板卡收到AIS信號后會向網絡設備發送Local_Fault告警，當網絡設備收到該告警后，端口即變為down（IEEE 802.3ae）。通過設置傳輸系統延時發送該信號（默認4*50ms），只要傳輸切換在該時間段內完成，即不會向網絡設備發送該信號，因此端口就不會flapping。
圖9 故障信號傳遞示意圖
在DCI產品成功實現了切換無感知后，我們希望在現網傳統產品中也找到類似的參數進行調整。因為告警延時傳遞與5ms倒換時間無關，即使是50ms的倒換時間，如果能讓網絡設備端口不感知光纜抖動，也會對業務穩定性帶來極大的提升。
為了實現網絡傳統產品支持無感切換，通過與廠商技術溝通，得出的結論是需要將100GE業務映射方式由BIT透明映射調整為MAC透明映射（會中斷業務），然后再設置告警參數延時200ms傳遞。
由于TOTN從來沒有使用過MAC透明映射方式，對此，我們協調設備廠商在實驗室專門做了MAC映射和BIT映射的測試驗證。結論是兩種方式吞吐量沒有區別，延時有差異，BIT映射時對64-9600Byte的幀都是24us，MAC映射時隨幀長增大而增大，但最大9600時，也就25us，可以忽略不計。
圖10 實驗環境拓撲
圖11 RFC2544測試結果
因此我們制定了優化方案，先調整傳輸A平面，灰度運行一段時間后再調整B平面。
8月18日對傳輸A平面進行優化：100GE業務映射方式采用MAC透明映射，告警參數延時傳遞200ms。經測試驗證，可實現傳輸光纜主備切換對網絡設備端口無感知，Redis無感知。
在真實的故障場景下也同樣得到了驗證。如9月7日15:13傳輸A平面發生光纜中斷故障，Redis報錯無異常尖峰。
圖12 優化后Redis報錯
經過經一個月的灰度驗證后，我們于9月15日對傳輸B平面進行優化，并且將告警參數延時傳遞時間在200ms的基礎進一步縮短至100ms，同樣經測試驗證Redis無感知。
為保持架構的統一性，我們將重新定義攜程光網絡設備技術標準，要求新入網的OTN設備必須支持BIT映射的告警延遲下插。同時，推動各供應商全面支持該功能，使之成為光纜故障場景下的一種最佳實踐。
抵御光纜故障是個業界公認的難題，頭部互聯網公司都在此栽過跟頭。通過上述一系列實踐，我們在抵御光纜故障方面已經做到了領先水平。光網絡運維是個長期過程，無感知切換只是其中一小部分，更多的是告警發現、性能監測以及光纜路由識別，避免同路由情況的發生。
本文鏈接：http://www.www897cc.com/showinfo-26-46480-0.html攜程光網絡抵御光纜中斷實踐
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號