隨著互聯(lián)網(wǎng)業(yè)務(wù)的迅猛發(fā)展，數(shù)據(jù)中心基礎(chǔ)架構(gòu)也在不斷向前快速迭代，隨之而來的問題是如何管理好這張龐大的數(shù)據(jù)中心網(wǎng)絡(luò)。本文立足于新一代的25/100G數(shù)據(jù)中心架構(gòu)之上，分析了目前運維層面的挑戰(zhàn)，提出了面向網(wǎng)絡(luò)運維全流程的技術(shù)升級，針對于流程中的每個環(huán)節(jié)講解了對應(yīng)的運維技術(shù)。希望可以通過本文給讀者一些新的啟發(fā)和靈感。
一、新時代需要新技術(shù)
隨著云計算、AI、大數(shù)據(jù)等技術(shù)的快速發(fā)展，一些新的業(yè)務(wù)形態(tài)呈現(xiàn)在大家的面前，比如今年受疫情影響而爆火的在線教育，直播帶貨等。業(yè)務(wù)應(yīng)用的革新得益于基礎(chǔ)設(shè)施的不斷發(fā)展和完善，上半年“新基建”的概念異?；鸨?，與之相關(guān)幾大領(lǐng)域的股票也都在瘋狂上漲。
2020年4月20日上午，國家發(fā)改委召開4月份例行新聞發(fā)布會，首次就“新基建”概念和內(nèi)涵作出正式的解釋。
“新型基礎(chǔ)設(shè)施是以新發(fā)展理念為引領(lǐng)，以技術(shù)創(chuàng)新為驅(qū)動，以信息網(wǎng)絡(luò)為基礎(chǔ)，面向高質(zhì)量發(fā)展需要，提供數(shù)字轉(zhuǎn)型、智能升級、融合創(chuàng)新等服務(wù)的基礎(chǔ)設(shè)施體系。”這是發(fā)改委給出的“新基建”定義。
新型基礎(chǔ)設(shè)施主要包括3個方面內(nèi)容，即信息基礎(chǔ)設(shè)施、融合基礎(chǔ)設(shè)施以及創(chuàng)新基礎(chǔ)設(shè)施。其中信息基礎(chǔ)設(shè)施中的數(shù)據(jù)中心作為通信網(wǎng)絡(luò)和算力的基礎(chǔ)是我們今天要討論的重點。
在上一期的技術(shù)盛宴直播活動中已經(jīng)跟大家分享了數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)的演進(jìn)歷程，也重點介紹了新一代數(shù)據(jù)中心架構(gòu)的設(shè)計建議，今天我們聚焦在運維層面來聊一聊新一代數(shù)據(jù)中心網(wǎng)絡(luò)運維技術(shù)。
首先作者認(rèn)為運維能力和架構(gòu)一樣也是需要更新迭代的，原因體現(xiàn)在兩個方面：
第一是業(yè)務(wù)驅(qū)動，25/100G時代的數(shù)據(jù)中心承載了一些基于RDMA技術(shù)的業(yè)務(wù)，比如高性能計算、高性能存儲等。這些業(yè)務(wù)對延時和丟包非常敏感，因此要求我們對網(wǎng)絡(luò)設(shè)備要做到更加精細(xì)化的狀態(tài)監(jiān)控，由此可見傳統(tǒng)的SNMP技術(shù)可能將要被新的運維手段所替代。
第二是技術(shù)驅(qū)動，主流的25G數(shù)據(jù)中心架構(gòu)都會采用單芯片的盒式交換機(jī)來進(jìn)行集群內(nèi)的組網(wǎng)，由于芯片選型發(fā)生了變化，因此對應(yīng)的運維技術(shù)也會有一些改變。具體來說就是我們可以享受到新型芯片帶來的技術(shù)紅利，比如基于IFA（IFA，In-band Flow Analyzer）的可視化運維能力等。
綜合以上分析，作者認(rèn)為新一代的數(shù)據(jù)中心需要新的運維技術(shù)來協(xié)助我們管理好這張龐大的數(shù)據(jù)中心網(wǎng)絡(luò)。
二、面向網(wǎng)絡(luò)運維全流程的技術(shù)升級
我們對很多公司的網(wǎng)絡(luò)架構(gòu)以及運維流程做了調(diào)研和分析，總結(jié)了一些通用的問題供大家參考和討論。
標(biāo)準(zhǔn)化的運維流程大概分為五步：網(wǎng)絡(luò)交付，網(wǎng)絡(luò)配置管理，網(wǎng)絡(luò)監(jiān)控，問題定位和故障處理。下面我們來分析一下每個流程中都有哪些問題亟待解決。
網(wǎng)絡(luò)交付
對于配置管理的流程大家并不陌生，SSH、Telnet等基于CLI的配置管理。但面向海量的網(wǎng)絡(luò)設(shè)備如果進(jìn)行重復(fù)性的機(jī)械動作，往往會消耗大家比較多的精力，影響運維的效率。
網(wǎng)絡(luò)監(jiān)控
在部署基于RDMA的業(yè)務(wù)之前，采用SNMP協(xié)議實現(xiàn)對網(wǎng)絡(luò)設(shè)備的監(jiān)控是比較主流的做法；但隨著RDMA的應(yīng)用越來越多，我們對網(wǎng)絡(luò)設(shè)備運行狀態(tài)需要掌握的更加精細(xì)和及時，而SNMP以分鐘為周期的時效性和可監(jiān)控的維度、顆粒度都會顯得有些不足。
問題定位
以丟包問題為例，問題定位就是說我們知道了有丟包事件發(fā)生，需要定位出哪個包丟了，在哪里丟的，為什么丟。這些信息以前都沒有很好的技術(shù)手段來幫助我們識別。基于ECMP的組網(wǎng)，加上網(wǎng)絡(luò)設(shè)備本身又是黑盒，我們連數(shù)據(jù)包真實轉(zhuǎn)發(fā)的物理路徑都無從得知，更何況是問題定位呢。
故障處理
目前大多數(shù)運維模式都屬于救火式的被動響應(yīng)，業(yè)務(wù)先報障，運維團(tuán)隊接到CASE后做對應(yīng)處理，對其處理的方式往往是需要依靠運維工程師的經(jīng)驗。在人工智能快速發(fā)展的時代，如果還一味的依靠人工來解決問題，是不是有些不夠智能呢？
綜合以上的分析，我們在整體運維流程的基礎(chǔ)上進(jìn)行了面向網(wǎng)絡(luò)運維的全方位技術(shù)升級。
在考慮成本和效率的前提下，我們在每個運維流程中都應(yīng)用了新的技術(shù)來解決新時代下的新問題。
圖1 運維全流程與運維新技術(shù)的對應(yīng)關(guān)系
下面我們逐一分析在不同運維流程中，我們應(yīng)當(dāng)采用哪些新的運維技術(shù)來幫助我們更有效地管理好這張龐大的數(shù)據(jù)中心網(wǎng)絡(luò)。
三、網(wǎng)絡(luò)上線交付
零配置自動部署管理（ZAM，Zero-configuration Automatic Manage）
上文提到在網(wǎng)絡(luò)初始化交付環(huán)節(jié)中存在大規(guī)模交付的效率問題，那么應(yīng)用什么技術(shù)可以提高這項工作的效率呢？
ZAM零配置自動部署管理技術(shù)可以很好的解決這個問題。
交換機(jī)到貨安裝上架并加電后，識別到空配置會自動進(jìn)入ZAM模式，通過DHCP的兩個Option字段獲取到TFTP的Server地址以及要下載的腳本文件。基于自身的SN碼獲取到屬于自身的版本、補丁、數(shù)據(jù)配置，自動重啟后，可以分鐘級完成整機(jī)房的網(wǎng)絡(luò)設(shè)備交付。
在網(wǎng)絡(luò)上線交付環(huán)節(jié)應(yīng)用ZAM技術(shù)大大降低了對人的依賴，提高準(zhǔn)確率的同時，節(jié)約了人工刷版本、刷配置的時間，是滿足快速交付的重要手段。
圖2 零配置自動部署管理技術(shù)流程
四、網(wǎng)絡(luò)配置與管理
Ansible
網(wǎng)絡(luò)承載的業(yè)務(wù)不會是一成不變的，為了滿足復(fù)雜多樣的需求可能會進(jìn)行業(yè)務(wù)的調(diào)整變更。面對業(yè)務(wù)變更，往往需要運維工程師同時操作大量的網(wǎng)絡(luò)設(shè)備，此時如果依靠工程師逐臺登陸設(shè)備下發(fā)命令，大量的重復(fù)性工作一方面會導(dǎo)致運維效率低下，另一方面也很難避免產(chǎn)生一些人為配置失誤，因此需要一種便捷的運維管理工具幫助工程師解決批量配置管理網(wǎng)絡(luò)設(shè)備的問題。
社區(qū)中開源的運維管理工具有很多，都可以幫助運維人員批量完成特定任務(wù)，減少重復(fù)性工作，比如Puppet、SaltStack、Ansible等。在對比了這三個運維管理工具之后，我們發(fā)現(xiàn)Ansible更加輕量化，更容易被廣泛應(yīng)用起來。
圖3 運維管理工具對比
從上述對比表中，我們不難發(fā)現(xiàn)Ansible的技術(shù)特點：
無客戶端
這是Ansible被廣泛應(yīng)用的一個最大原因，被管設(shè)備上（如交換機(jī)）只需要支持SSH和Python2.5以上版本即可，不需要額外按照Ansible的客戶端進(jìn)行適配；
模塊化
Ansible也可以視作沒有服務(wù)端，我們可以通過調(diào)用特定模塊，完成特定任務(wù)；
安全
基于OpenSSH的實現(xiàn)，加密遠(yuǎn)程傳輸中的數(shù)據(jù)；
支持Playbooks編排任務(wù)
這個是Ansible的最大特色，Playbooks可以幫助運維人員將復(fù)雜任務(wù)碎片化，且能夠進(jìn)行批量地部署復(fù)雜任務(wù)。Playbooks的編寫也基于易讀的YAML語法，操作容易。
五、網(wǎng)絡(luò)精細(xì)化監(jiān)控
gNMI
（gRPC Network Management Interface）
提到網(wǎng)絡(luò)狀態(tài)監(jiān)控，相信大家腦海中首先涌現(xiàn)的就是SNMP技術(shù)。的確，SNMP作為傳統(tǒng)的網(wǎng)絡(luò)監(jiān)控手段已經(jīng)被大家應(yīng)用了很多年，但面對高性能計算、大數(shù)據(jù)、AI等業(yè)務(wù)就會有些力不從心。
首先從業(yè)務(wù)特征和需求來看，高帶寬業(yè)務(wù)會出現(xiàn)微突發(fā)的現(xiàn)象，因此需要我們能夠?qū)崟r地監(jiān)控設(shè)備的運行狀態(tài)。比如RDMA業(yè)務(wù)，需要對關(guān)鍵信息做監(jiān)控，緩存隊列等實時狀態(tài)數(shù)據(jù)。
因此我們建議采用gRPC框架實現(xiàn)對網(wǎng)絡(luò)設(shè)備的精細(xì)化監(jiān)控。
圖4 gRPC工作流程
gRPC是谷歌發(fā)布的基于HTTP2.0承載的高性能開源軟件框架，提供了支持多種編程語言的管理網(wǎng)絡(luò)配置和納管的方式。開源使大家更專注于業(yè)務(wù)層面內(nèi)容，減少對底層協(xié)議框架的關(guān)注。gRPC采用了ProtoBuffer（PB）來做數(shù)據(jù)的序列化與反序列化封裝，用HTTP 2.0作為數(shù)據(jù)傳輸協(xié)議。
gRPC的傳輸效率非常高，也得益于這兩大核心技術(shù)。
Protocol Buffers：高效的數(shù)據(jù)格式，傳送二進(jìn)制碼，消耗少，傳輸快
HTTP2.0：多路復(fù)用連接，二進(jìn)制幀傳輸，首部壓縮
在網(wǎng)絡(luò)精細(xì)化監(jiān)控這一環(huán)節(jié)中，越來越多的客戶開始應(yīng)用gRPC來統(tǒng)一運維接口，拉齊設(shè)備的能力特性，提升效率，更加主動的感知網(wǎng)絡(luò)狀態(tài)，提早發(fā)現(xiàn)問題，防患于未然。關(guān)于gRPC技術(shù)的更詳細(xì)介紹，可以查閱前幾期的技術(shù)盛宴文章，由于篇幅的原因，作者在此不做深入展開。
六、問題定位
帶內(nèi)流量分析
（IFA，In-band Flow Analyzer）
網(wǎng)絡(luò)運維流程中最棘手環(huán)節(jié)就是故障問題的定位。
以RDMA業(yè)務(wù)為例，該業(yè)務(wù)特征是對延時和丟包極其敏感，一旦發(fā)生了丟包就會大大降低業(yè)務(wù)性能，影響很大。因此我們除了能夠感知端到端的延時，還需要能檢測到異常抖動，知道在哪一跳出現(xiàn)了異常。
而在當(dāng)前的多核心Scale-out（橫向擴(kuò)展）組網(wǎng)架構(gòu)下，網(wǎng)絡(luò)中存在了大量的ECMP（等價多路徑），每個業(yè)務(wù)流在每跳具體轉(zhuǎn)發(fā)到哪個物理端口上，依賴芯片Hash（哈希）的結(jié)果，這個對運維來說是不直觀的，我們希望給定一個業(yè)務(wù)流瞬間就知道每跳選擇了哪個物理接口。
基于上述業(yè)務(wù)訴求，IFA技術(shù)的應(yīng)用給廣大運維同學(xué)帶來了福利。它可以用來精確確定特定流量的路徑及轉(zhuǎn)發(fā)時延等信息，并封裝成UDP報文發(fā)送給服務(wù)器進(jìn)行分析。
圖5 IFA技術(shù)原理
具體實現(xiàn)：
在入口首跳設(shè)備上進(jìn)行指定會話的識別，通過采樣后，開始插入INT頭部；
后續(xù)轉(zhuǎn)發(fā)節(jié)點插入Metadata數(shù)據(jù)，包含設(shè)備id、入出端口、時間戳等；
尾跳設(shè)備重新構(gòu)造UDP報文，并把采樣報文封裝到UDP報文的payload中，然后把UDP報文上送到監(jiān)控服務(wù)器上。輸入文字
最終IFA的部署，可以常規(guī)的日常開啟，但是也可以針對發(fā)生故障時按需調(diào)用。
一些敏銳的讀者看到這里會提出一個疑問，RDMA業(yè)務(wù)既然對于路徑和丟包敏感，那么我們只上送那些路徑發(fā)生變化以及時間超過閾值的報文到服務(wù)器，再加以分析處理不就可以嗎？
圖6網(wǎng)絡(luò)流量分析技術(shù)流程
沒錯，如果將所有的報文上送服務(wù)器確實會額外增加了服務(wù)器成本，不利于整網(wǎng)TCO優(yōu)化，這種本末倒置的做法可能會直接導(dǎo)致IFA技術(shù)無法落地應(yīng)用。
因此我們需要在流量到達(dá)服務(wù)器之前做一級過濾，將那些路徑和延時正常的報文都過濾掉，只上送異常報文到分析服務(wù)器，就可以大大降低了服務(wù)器的壓力。在這個過濾處理環(huán)節(jié)，我們建議采用基于可編程芯片的交換機(jī)來實現(xiàn)，因其強大的硬件處理能力可以獲得更好的價值收益。
圖7 基于可編程網(wǎng)元的網(wǎng)絡(luò)可視化方案
六、故障處理
基于意圖的網(wǎng)絡(luò)
（IBN，Intent-based Network）
談到故障處理，我們需要先分析一下目前的運維模式。一般對于故障的處理流程都是先由業(yè)務(wù)方提交Case報障，運維團(tuán)隊在系統(tǒng)上接到Case再去定位問題，分析原因，解決問題，屬于被動的救火式運維。迫于業(yè)務(wù)的緊急性，有的時候會讓運維工作陷入很大的壓力當(dāng)中。
基于意圖網(wǎng)絡(luò)的智能分析平臺可以很好的幫助我們改變目前的運維模式，化被動為主動。
圖8 智能分析平臺架構(gòu)
該平臺內(nèi)置多個模塊，包括數(shù)據(jù)采集平臺、AI引擎、大數(shù)據(jù)分析平臺以及智能分析器?？梢詫崿F(xiàn)網(wǎng)絡(luò)及應(yīng)用可視化，問題分析，故障預(yù)測等功能。
針對問題分析這一功能，可以幫助我們識別三大類故障，其中包括接入類、應(yīng)用類以及網(wǎng)元類?；趩栴}的分析，該平臺也會提出調(diào)優(yōu)及處理建議，幫助我們快速解決問題，恢復(fù)業(yè)務(wù)。
圖9 基于IBN的故障自動識別
關(guān)于IBN的詳細(xì)內(nèi)容，未來會單獨做一期技術(shù)盛宴和大家一起分享，在這里先拋磚引玉一下，大家敬請期待后續(xù)的專題講解。
七、小結(jié)
看到這里，相信大家對新一代的數(shù)據(jù)中心運維技術(shù)也有所了解了。
銳捷網(wǎng)絡(luò)互聯(lián)網(wǎng)數(shù)據(jù)中心ENA（Easy Network Architecture，簡單網(wǎng)絡(luò)架構(gòu)）解決方案正是基于單核心Box+多平面組網(wǎng)的基礎(chǔ)架構(gòu)，面向運維全流程做升級迭代，從架構(gòu)和運維兩個層面持續(xù)演進(jìn)。
本文中提到的運維特性已經(jīng)在銳捷網(wǎng)絡(luò)數(shù)據(jù)中心交換機(jī)產(chǎn)品中全部體現(xiàn)，這些是銳捷人長期深入業(yè)務(wù)場景、觀察研究、不斷打磨精品的具體呈現(xiàn)。我們深知，看清用戶痛點，以極簡的方式輔助用戶成功，這才是技術(shù)研發(fā)的第一要義。同時也希望每一位技術(shù)盛宴的讀者與我們分享您的真知灼見，我們共同發(fā)現(xiàn)、共同討論、共同成功！
本文作者：墨染塵香
銳捷網(wǎng)絡(luò)互聯(lián)網(wǎng)系統(tǒng)部解決方案架構(gòu)師
