近幾年來，互聯網行業處于一個快速發展的快車道，一個又一個風口不斷地涌向周邊行業。共享單車的出現解決了人們出行最后一公里的問題；新零售概念的提出，無人貨柜的出現，更是將線上和線下的數據打通，優化了人們的購物體驗；以抖音為首的短視頻應用，在一夜間爆紅，成為當下社交與宣傳的重要載體。
而數據中心作為支撐這些業務的基礎設施，其規模也隨著業務的激增逐漸擴大，單集群內超過數萬臺服務器的情況已不再罕見。面對如此龐大的服務器數量，在網絡建設之初的交換機網絡開局已成為網工的夢魘。
一、數據中心開局現狀
聚焦于數據中心場景，我們先來回顧一下傳統的交換機網絡開局流程。
圖1 傳統網絡設備開局流程
Step 1: 提前準備交換機的版本文件；
Step 2: 根據部署的架構場景選擇對應的配置模板；
Step 3: 開始"搬磚"，到達現場，設備拆箱集中堆放，加電啟動；
Step 4: 使用U盤插到交換機，串口線連接設備，逐臺進行版本升級（若需要）；
Step 5: 根據配置模板結合實際設備的情況進行VLAN、IP、路由以及其他基本信息的修訂，然后開始刷配置（另外按照各公司要求，還會協助收集設備的SN用于資產管理）；
Step 6: 協調弱電同學幫忙搬到機房上架；
Step 7: 基于Checklist完成連通性的測試工作。
整套流程下來，既耗人力，又耗時間。據實際項目經驗來看，在不堆疊的前提下完成一臺設備的升級和配置大約在10分鐘，堆疊情況下由于設備需要重啟，需要30分鐘才能完成。
總結來看，對于支撐數萬臺服務器集群的數據中心網絡場景，如果按照這種傳統的開局模式來部署，會存在以下幾點不足：
效率低下：靠手工方式進行設備的版本升級、刷腳本，效率非常低；
出錯率高：重復性的工作會導致網工疲于思考，稍有不慎出現失誤，需要額外的時間用于排查錯誤更正，產生一定的時間損耗。
對此，各廠家做了許多的探索，比如零配置上線技術。
二、數據中心自動化開局
隨著數據中心規模的不斷增大，標準化的建設方式已經成為主流。每個集群內的服務器以及網絡設備的規模都是固定的，對應到網絡設備的配置策略也是一致的（當然IP等基礎信息會略有不同）。因此，在這樣標準化、規范化的場景下，我們可以將這些重復性的、機械性的工作編成處理邏輯，交給網絡設備自己去完成上線工作，進而解放人力，同時也降低了人們出錯的風險。
廠商對于自動化上線技術的開發，主要是利用編程語言（比如Python、Go等）進行邏輯處理，讓網絡設備自行加載，完成上線，例如ZAM技術（Zero-configure Automatic Manage）。
交換機自動化上線的思路：新出廠或空配置的設備上電啟動后自動向文件服務器中獲取文件并加載（包括版本文件、配置文件、補丁文件等），實現設備的免現場配置、部署，從而避免了運維人員重復地執行刷腳本、升級等機械性操作，提升開局效率。
以ZAM技術為例，首先要在運維端搭建統一的DHCP服務器和TFTP服務器（可以是同一臺服務器），基于架構標準化設計和項目信息提前生成每臺設備的完整配置文件以及版本文件，同時這些文件的文件名需要與設備的SN關聯起來，確保每個配置文件可以對應唯一一臺具體的物理設備。
圖2 零配置上線方案架構
交換機加電起機后會主動發起DHCP請求，通過Option拿到TFTP服務器的地址以及腳本名稱。通過TFTP的方式下載到腳本文件后，解析并執行。然后自動進行版本的升級以及配置文件的加載，重啟后完成設備開局。主要流程如下：
圖3 零配置上線流程
細節可以分拆成幾個階段來理解：
1. DHCP&TFTP獲取階段
1） 設備加電后，首先判斷自身是否存在配置文件，如果不存在則進入ZAM模式；如果存在則正常加載現有配置文件啟動；
2） 進入ZAM模式后，會先嘗試從MGMT口上發起DHCP請求，無應答后會從業務口上廣播該請求報文。DHCP Server在回應報文中通過Option66（或者150）、67選項，將TFTP Server的IP以及Python腳本名稱同步給設備；
圖4 典型的DHCP配置
3） 交換機設備（需要支持Python的運行環境）進行Python腳本的下載。
2. 自動化執行階段
1） 初始化：
首先要進行初始化，與此同時要清空之前運行過的本地文件，目的是為了避免那些通過錯誤邏輯模塊到達該處時文件錯亂的情況，因此需要執行初始化操作；
2） 上傳SN：
初始化完成后需要上傳設備自身的SN到指定的目錄下，目的是提示TFTP Server該設備已經開始啟動。即上傳 [sn]. ZAM到 /ZAM_STARTUP/, 若上傳失敗則寫"0"到/etc/zam.txt （通告zam執行失�。顺�；
3） 配置參數文件下載：
上傳SN之后，會基于SN去下載對應的配置參數文件（.PARAM格式），下載路徑在代碼中已經寫好，若下載失敗則跳到錯誤處理；
4） 配置參數文件解析：
下載成功后解析該文件，判斷是否需要升級版本，若解析失敗則跳到錯誤處理；
5） 配置文件下載：
通常情況下，腳本中會默認寫好配置文件的下載路徑，設備會基于SN到該路徑下載配置文件 [sn].CFG, 若下載失敗跳到錯誤處理；
6） 版本文件下載：
如果配置參數文件中存在bin文件的標識，則到指定的路徑去進行bin文件的下載，若下載失敗則跳到錯誤處理；
7） 版本文件升級：
如果存在bin的文件，則進行升級bin文件，若升級失敗則跳到錯誤處理；
8） 配置文件重命名：
執行代碼做配置文件的重命名，更改成config.txt的格式后重啟（不同廠家配置文件命名不同，這里以銳捷為例）；
9） 設備重啟加載：
重啟設備后則再次進行配置文件的判斷，發現此時存在配置文件，則不進入ZAM模式，正常加載配置文件并啟動。
3. 信息同步校驗階段
1） 成功處理：
設備成功上線后
A. 上傳 [sn].log 到 /ZAM_LOG/
B. 上傳 [sn].ok 到 /ZAM_STATUS/
C. 寫"1"到/etc/zam.txt （通告zam執行成功）
D. 清空本地本次執行相關文件（[sn].CFG, [sn].ZAM, [sn].params, [sn].ok, [sn].error）
圖5 ZAM文件夾目錄
圖6 成功執行ZAM流程
2） 失敗處理
主邏輯任意一個節點發生故障，跳到故障處理時，執行下列動作
A. 上傳 [sn].log 到 /ZAM_LOG/
B. 上傳 [sn].error 到 /ZAM_STATUS/
C. 寫"0"到/etc/zam.txt（通告zam執行失�。�
D. 清空本地本次執行相關文件（[sn].CFG, [sn].ZAM, [sn].params, [sn].ok, [sn].error）
三、探索創新
隨著網絡設備對于類似Python的高級編程語言環境的支持愈加成熟，零配置上線技術在IDC場景中得到了普遍的應用。一方面加快了設備的開局速度，降低了人為操作失誤的風險，節省人力投入；另一方面，對于后期設備的運維工作（比如擴容、故障替換等），只需要上報或者替換SN就可以自動完成加載，也不需要人工的參與。
那么，除了IDC場景有這樣的需求之外，對于其他場景，是否也存在類似的運維痛呢？
銳捷網絡秉承著創新、探索與實踐的思路，在新零售門店場景，也做了深入的市場調研與分析。
最近火爆的新零售門店，其特點就是數量眾多，業務的激增導致開店速度尤其快。但是門店不會有專業的運維同學駐場，所以網絡開局時需要網工四處出差；日常遇到故障，如果遠程不能解決也需要網工到現場處理，人力投入極大。
對此，聚焦于新零售門店場景，我們基于數據中心零配置開局的思路進行創新，致力于打造全新的自動化門店網絡解決方案，提升新零售門店網絡開局和運維的效率，減少人力服務成本。
圖7 自動化門店網絡解決方案封面
目前我們正在和新零售客戶積極的探索和實踐中，敬請期待。如果有相關建議和思路，也歡迎留言互動，共同探討。
本期作者：劉洋
銳捷網絡互聯網系統部行業咨詢
感謝您關注銳捷網絡技術干貨文章！現誠邀您參與有獎調研，您寶貴的意見和建議將幫助我們在技術探索與分享上持續精進。
點擊下方鏈接參與調研。
http://survey.ruijie.com.cn/jq/26535756.aspx 
