本文從一名網工從業者的角度出發,探討了在企業網運維過程中,網路工程師可以用什麼樣的工具讓網路更加透明高效。
引言
“網路就像wifi,沒有故障的時候,就沒有人意識到它的存在”,這句話有無數的翻版,但是對於網路工程師來說這就是現身說法。由於網路工程師的人數即便是在上千人的公司,也僅僅是個位數,所以他們的工作也鮮為人知 。“網路是不是有問題?”這句話幾乎成了所有SRE排錯時的口頭禪,如果這個時候網路工程師表示沉默,或者無法拿出足夠的證據,那背鍋幾乎是無疑的,如何讓網路環境的執行狀態更加透明,如何在每次業務故障的時候自證清白,這不僅是基礎服務團隊要關心的內容,更是整個技術團隊想要了解的黑匣子。
1、監控
1.1網路裝置存活監控
對於SRE來說需要監控程式是否正常,對於主機組來說需要監控伺服器硬體是否正常,對於網路來說我們首先需要關心網路裝置是否可達。當一臺TOR不可達時,基本上預示著會有一片伺服器不可達,業務的痛感是相當強烈的。
網路裝置的監控最好和業務監控系統儘量解藕,因為網路故障極有可能引發業務系統異常,如果恰巧導致的是業務的監控系統異常,那網路裝置的告警將失去可靠性,“監控不準”且不說這個鍋是誰的,這種局面會讓網路工程師Trouble Shooting時陷入被動,延長了故障時間。
每一個網工在走出校門的那一刻,都已經具備基本的程式設計基礎, 況且交換機的數量和伺服器的數量有著量級上的差別,所以如果你能看懂幾句python,100+的python程式碼即可搞定一個簡易的裝置存活監控的程式,Github中可搜尋 NodePingManage 就是一個很好的例子,還可以通過多點部署來消除單點故障。有了這類工具, 從此全網的各個角落的可達性終於明瞭, 漆黑的網路環境,似乎反射出了一絲光明。
1.2裝置日誌監控
裝置存活告警雖然可以預警很多異常,並且準確度很高,但是對於冗餘性做的比較好的網路,能Ping通並不代表完全沒問題,此時,細心的網路工程師會去看日誌,這裡可以反映出更多細節。對於萬臺伺服器規模,網路裝置的數量也就千臺,但是逐臺檢視日誌,人肉判斷是否有異常,那簡直是場噩夢。
《日誌告警》程式就成為網路工程師們居家旅行必備之良品,只需要一臺Syslog伺服器,部署一個日誌監控程式,當發現日誌中出現特殊關鍵字,觸發郵件+簡訊告警即可。這麼高大上的工具當然需要更多的程式設計技巧,150+ python程式碼才能搞定。Github中類似的解決方法有很多,搜尋 LogScanWarning 即可得到一個示範案例。
從此你可以在業務無感的情況下,發現網路中的異常, 例如:風扇轉速異常/電源模組故障/ospf鄰居狀態抖動/埠flapping/有黑客在爆破我的裝置/裝置硬體parity error/模組收發光異常/Kernel報錯等等。優秀的網路工程師可以在故障發生時快速定位,牛X的網路工程師可以在故障發生前就消除隱患,防範於未然。
1.3流量監控
高速公路鋪的再好,也架不住車多人多。確保網路順暢,品質優良,沒有丟包,延時穩定也是網路工程師的職責 ,此時流量監控就成了剛需。業務的飛速發展體現在網路層面就是DC內流量上漲/DCI流量上漲/IDC出口流量上漲/專線流量上漲,流量監控可以準確掌握業務的高峰和低谷,當線路需要擴容時,頻寬使用率是老闆參考的重要資料。一般情況下線路中的流量超過50%即可發起擴容,因為這意味著當備份鏈路down之後,主線路將出現擁塞。
1.4介面error監控
介面的Error包監控和流量監控一樣,均可以通過snmp採集,OID:ifOutErrors,ifInErrors , Error包出現增量會直接影響業務的服務質量,一旦發現需要優先處理,否則業務會拎著一堆TcpTimeOut指標找上門來。當然,可以通過snmp採集的資訊還有很多,例如:裝置的CPU/記憶體/溫度/防火牆的Session等,掌握這些資訊對了解裝置的工作環境也頗有益處,如果你要做一個自動化巡檢工具,那麼這些指標必不可少。市面上提供網路監控的軟體有很多,例如:Falcon/Zabbix/Solarwinds/Cacti/Nigos 等,有開源的也有收費的,功能類似,此處不加贅述。
2、製造自動化運維工具
第一章中的組合拳打完之後,基本上不會出現“意料之外的故障”,所有的異常都應該有據可查,當SRE莫名其妙提出對網路環境的質疑時,你應該早已心中有譜。但是網路工程師的工作並非只有救火,日常運維工作中,經常需要配合業務發展做一些線上變更/ 機房擴建/業務類故障排查等。作為一名“懶惰”的網路工程師,程式可以幫忙點什麼忙呢?
2.1UserDevice Tracker
這個名詞借用於Solarwinds套裝中的一個元件,直譯為“使用者裝置追蹤器” , 在中小型企業網運維中,經常會有這樣的需求:
知道伺服器的IP,請問連線在交換機的哪個口?
知道交換機的某個埠,請問連線的伺服器的IP是多少?
給你一臺伺服器的MAC地址,怎麼知道在哪個交換機的哪個口?
大型網際網路公司一般會有CMDB或者網路管理平臺來記錄這些資訊, 但是如果你是一家中小型企業的網管,沒有運維研發團隊做支援,並且還在沿用二層的環境(伺服器閘道器在核心裝置),那就比較費勁了。以上幾個問題其實歸根到底是要捋清楚三個要素的對應關係: PORT<>MAC<>IP
舉個例子:
一臺交換機有多個物理介面,一個物理介面下可以有多個MAC,一個MAC可以對應多個IP,或者不對應任何IP。 有了這個基本的模型,只需要做兩件事情即可找到全網裝置這三元素的對應關係。首先去伺服器直連的交換機獲取MAC表(即MAC<->PORT), 然後再去伺服器的閘道器裝置獲取ARP表(即IP<->MAC),這兩張表根據MAC地址作為唯一主鍵即可得到 PORT <->MAC<->IP 的對應關係。 資訊的獲取可以通過模擬登陸或者OID採集均可,Github中也有很多類似的程式碼可供參考,有了這個對應關係,即便沒有CMDB,你依然可以快速定位想要的資訊, 普通網工查詢這個資訊需要5分鐘, 而你只需要5秒鐘。
2.2網路裝置北向介面的二次封裝
日常網路運維工作中,經常會有一些 “簡單重複勞動”,例如:為某個介面劃分Vlan/給某臺裝置新增一條指向主機的路由等, 這些操作即沒有科技含量,還佔用了工程師寶貴的時間,更要命的是再簡單的人肉操作,重複的次數只要足夠多,總有失誤的時候,正所謂“常在河邊走,哪有不溼鞋”,但是在這種問題上犯錯誤簡直是對職業生涯的抹黑,如此“雞肋”的工作怎麼才能乾的漂亮?
以《自動劃分交換機介面Vlan》的功能為例, 如果有一個工具只需要你提供三個引數:裝置IP/埠/vlan編號, 就能自動登陸裝置把特定介面劃分到指定Vlan,那豈不是美哉。沒錯!你需要的是一個對裝置封裝後的介面, 現在多數網路裝置廠商都會提供自己的API,無論是NETCONF還是RESTful,只要讀懂了使用手冊,即可通過程式輕鬆變更裝置的配置,甚至你可以用更加”接地氣”的方法,用程式“模擬登陸”裝置 ,雖然這個方法在效率上比不過NETCONF和RESTful API,但是在通用性上那簡直無敵,因為沒有哪個廠商的裝置不支援SSH或者TELNET的。
有了這個理論基礎,一些簡單的網路上的操作就可以通過自己封裝的介面來實現變更,甚至可以把變更的許可權交給業務,只要業務提交的請求是合法的,變更可立即上線生效。此時,肯定會有人大驚失色!把網路裝置的許可權交給業務,這樣真的好麼?萬一改壞了怎麼辦…所有的疑惑都是正常的,同時也都是有解的。還以《自動劃分交換機介面Vlan》舉例子,你可以限制程式執行的內容,你可以規定交換機只能是TOR不能是CSW,你可以約束介面只能是Access不能是Trunk,你可以限定被操作的介面下流量必須為0bps,以避免誤操作影響到業務,你可以通過動態Token保證介面的安全,你可以要求必須提供介面下現存的MAC以定位介面的位置,你還可以對呼叫者加白名單,另外,操作成功後還需要有簡訊+郵件反饋操作後的結果,等等…
所有的考量都可以固化為程式碼規則,只有程式是最忠實的執行者。介面可以提供7*24 小時全年無休的服務,而人的精力是有限的,用程式去應對業務那些簡單有規律的需求,節省出工程師寶貴的時間來思考人生,這才是網路工程師自動化運維之路的正道。
總結
以上,是筆者結合自身工作經歷總結的一些心法,寫程式碼對於網路工程師來說確實有些難度,但是隻要跨過這道坎,你會得到更多富裕的時間來擴充套件自己的專業道路,謹以此文,希望能拋磚引玉為自動化網路運維盡綿薄之力。
本文首發於公眾號”小米運維“,點選檢視原文。