SDSM結束了，但無法控制的寫作慾望依然存在。

多年來，我們的兄弟一直在做例行公事，在上班前交叉手指，並且由於夜間回滾而缺乏睡眠。
但黑暗時代即將結束。

透過這篇文章，我將開始一系列關於如何 我 可見自動化。
在此過程中，我們將了解自動化、儲存變數、形式化設計、RestAPI、NETCONF、YANG、YDK 的各個階段，並且我們將進行大量程式設計。
對我來說 意味著a）它不是一個客觀事實，b）它不是無條件的最佳方法，c）我的觀點，即使在從第一篇文章到最後一篇文章的過程中，也可以改變- 說實話，從草案階段到出版後，我將所有內容完全重寫了兩次。

Содержание

1. 目標
   1. 網路就像一個單一的有機體
   2. 配置測試
   3. 版本控制
   4. 服務的監控和自我修復

2. 資金
   1. 庫存系統
   2. IP空間管理系統
   3. 網路服務描述系統
   4. 設備初始化機制
   5. 與供應商無關的配置模型
   6. 供應商特定的驅動程式接口
   7. 向設備下發配置的機制
   8. CI / CD
   9. 備份和搜尋偏差的機制
   10. 監視系統

3. 結論

我將嘗試以與 SDSM 略有不同的格式進行 ADSM。 大型、詳細、編號的文章將繼續出現，在它們之間我將發表日常經驗的小筆記。 我會在這裡努力與完美主義作鬥爭，而不是舔他們每一個人。

多麼有趣的是，第二次你還要走同樣的路。

起初我必須自己寫一些關於網路的文章，因為它們不在 RuNet 上。

現在我找不到一個全面的文件來系統化自動化方法並使用簡單的實際範例來分析上述技術。

我可能是錯的，所以請提供有用資源的連結。 不過，這不會改變我寫作的決心，因為主要目標是自己學習一些東西，讓別人的生活更輕鬆是一個令人愉快的獎勵，撫摸著分享經驗的基因。

我們會嘗試以一個中型LAN DC資料中心為例，制定整個自動化方案。
我幾乎是第一次和你一起做一些事情。

我不會在此處描述的想法和工具中具有原創性。 德米特里·菲戈爾有著出色的表現 有關此主題的頻道.
這些文章在很多方面都會與它們重疊。

LAN DC 有 4 個 DC、大約 250 個交換器、六個路由器和幾個防火牆。
不是 Facebook，但足以讓你深入思考自動化。
然而，有一種觀點認為，如果您擁有超過 1 台設備，則已經需要自動化。
事實上，很難想像現在任何人都可以在沒有至少一套膝蓋腳本的情況下生活。
雖然我聽說有些辦公室的IP位址保存在Excel中，並且成千上萬的網路設備中的每一個都是手動配置的，並且都有自己獨特的配置。 這當然可以被冒充為現代藝術，但工程師的感情肯定會受到冒犯。

目標

現在我們將設定最抽象的目標：

• 網路就像一個單一的有機體
• 配置測試
• 網路狀態版本控制
• 服務的監控和自我修復

在本文後面，我們將討論我們將使用什麼手段，在下文中，我們將詳細介紹目標和手段。

網路就像一個單一的有機體

該系列的定義短語，儘管乍看之下似乎不那麼重要： 我們將配置網絡，而不是單一設備.
近年來，我們看到重點轉向將網路視為單一實體，因此 軟件定義的網絡, 意圖驅動網路 и 自治網絡.
畢竟，應用程式在全域範圍內需要網路提供什麼：A 點和 B 點（有時是 +B-Z）之間的連接以及與其他應用程式和用戶的隔離。

所以我們這個系列的任務是 建立一個系統，維持目前配置 全網，它已經根據其角色和位置分解為每個設備上的實際配置。
系統 網路管理意味著要進行更改，我們需要聯繫它，而它反過來計算每個設備的所需狀態並對其進行配置。
透過這種方式，我們將對 CLI 的手動存取降至幾乎為零 - 設備設定或網路設計的任何更改都必須正式化和記錄 - 然後才推廣到必要的網路元素。

也就是說，例如，如果我們決定從現在開始喀山的機架交換機應該宣布兩個網路而不是一個，我們

1. 首先我們記錄系統的變化
2. 產生所有網路設備的目標配置
3. 我們啟動網路配置更新程序，該程式計算每個節點上需要刪除的內容、新增的內容，並使節點達到所需的狀態。

同時，我們只在第一步手動進行更改。

配置測試

已知80% 的問題發生在配置變更期間 - 間接證據是新年假期期間一切通常都很平靜。
我親眼目睹了數十起因人為錯誤導致的全球宕機：錯誤的命令、在錯誤的分支執行配置、社區忘記、MPLS在路由器上被全局拆除、配置了五塊硬件，但錯誤卻沒有第六天注意到，另一個人所做的舊更改被進行了。 有很多場景。

自動化將使我們能夠減少犯錯，但犯的錯誤規模會更大。 透過這種方式，您不僅可以對一台設備進行磚塊化，還可以一次將整個網路進行磚塊化。

從遠古時代開始，我們的祖父們就用敏銳的眼光、鋼球和網路推出後的功能來檢查所做的更改的正確性。
那些因工作導致停機和災難性損失的祖父留下的後代更少，並且應該隨著時間的推移而滅絕，但進化是一個緩慢的過程，因此並不是每個人都首先在實驗室中測試變化。
然而，處於進步前沿的是那些自動化測試配置及其在網路中的進一步應用的過程的人。 換句話說，我借用了 CI/CD 程式（持續整合、持續部署）來自開發商。
在其中一個部分中，我們將研究如何使用版本控制系統（可能是 Github）來實現這一點。

一旦你習慣了網路 CI/CD 的想法，一夜之間，透過將配置應用於生產網路來檢查配置的方法就會顯得像是中世紀早期的無知。 有點像用鐵鎚敲擊彈頭。

理念的有機延續 系統 網路管理和 CI/CD 成為配置的完整版本。

版本控制

我們假設，隨著任何變化，即使是最微小的變化，即使是在一台不引人注目的設備上，整個網路也會從一種狀態轉變為另一種狀態。
我們總是不在設備上執行命令，而是在更改網路狀態。
那我們稱這些狀態為版本嗎？

假設目前版本是 1.0.0。
其中一台 ToR 上的 Loopback 介面的 IP 位址是否已更改？ 這是一個次要版本，編號為 1.0.1。
我們修改了將路由匯入 BGP 的策略 - 更認真一點 - 已經是 1.1.0
我們決定擺脫 IGP 並僅改用 BGP - 這已經是一個根本性的設計變更 - 2.0.0。

同時，不同的DC可能有不同的版本——網路正在開發，新設備正在安裝，新級別的主幹正在某處添加，而不是在其他地方添加，等等。

Про 語意版本控制 我們將在另一篇文章中討論。

我重複一遍 - 任何更改（調試命令除外）都是版本更新。 必須通知管理員與目前版本的任何偏差。

這同樣適用於回滾更改 - 這不是取消最後的命令，這不是使用設備作業系統的回滾 - 這是將整個網路帶到新（舊）版本。

服務的監控和自我修復

這個不言而喻的任務在現代網路中已經達到了一個新的水平。
通常，大型服務提供者採取的方法是需要快速修復失敗的服務並提出新的服務，而不是弄清楚發生了什麼事。
「非常」意味著你需要在各方面進行大量的監控，幾秒鐘之內就能檢測到與標準最輕微的偏差。
在這裡，通常的指標，例如介面載入或節點可用性，已經不夠了。 由值班人員進行手動監控也是不夠的。
對於很多事情來說應該有 自我修復 ——監視器燈變紅了，我們自己去把車前草塗在受傷的地方。

而這裡我們監控的不僅是單一設備，還有整個網路的健康狀況，既有相對容易理解的白盒，也有比較複雜的黑盒。

實施如此雄心勃勃的計劃我們需要什麼？

• 擁有網路上所有裝置及其位置、角色、型號、軟體版本的清單。
  kazan-leaf-1.lmu.net，喀山，葉，瞻博網路 QFX 5120，R18.3。
• 擁有一個描述網路服務的系統。
  IGP、BGP、L2/3VPN、政策、ACL、NTP、SSH。
• 能夠初始化設備。
  主機名稱、管理 IP、管理路由、使用者、RSA 金鑰、LLDP、NETCONF
• 配置設備並將配置設定為所需的（包括舊的）版本。
• 測試配置
• 定期檢查所有設備的狀態是否與目前狀態有偏差，並向相關人員報告。
  一夜之間，有人悄悄為ACL增加了一條規則.
• 監控效能。

資金

聽起來很複雜，需要開始將專案分解為組件。

其中將有十個：

1. 庫存系統
2. IP空間管理系統
3. 網路服務描述系統
4. 設備初始化機制
5. 與供應商無關的配置模型
6. 供應商特定的驅動程式接口
7. 向設備下發配置的機制
8. CI / CD
9. 備份和搜尋偏差的機制
10. 監視系統

順便說一句，這是對週期目標的看法如何改變的一個例子——草案中有 4 個組成部分。

在插圖中，我描繪了所有組件和設備本身。
相交的組件相互作用。
塊越大，這個組件就越需要注意。

組件一：庫存系統

顯然，我們想知道什麼設備位於何處，連接到什麼。
庫存系統是任何企業不可或缺的一部分。
大多數情況下，企業有一個單獨的網路設備庫存系統，可以解決更具體的問題。
作為本系列文章的一部分，我們稱之為 DCIM——資料中心基礎設施管理。 儘管 DCIM 一詞本身嚴格來說包含更多內容。

出於我們的目的，我們將在其中儲存有關設備的以下資訊：

• 庫存編號
• 標題描述
• 模型 （華為CE12800、Juniper QFX5120等)
• 特性參數（闆卡、接口等)
• 角色 （Leaf、Spine、邊界路由器等)
• 地點 （地區、城市、資料中心、機架、單位)
• 設備之間的互連
• 網路拓撲結構

很明顯，我們自己想知道這一切。
但這對自動化有幫助嗎？
當然。
例如，我們知道在Leaf交換器上的給定資料中心中，如果是華為，則應在VLAN上套用過濾某些流量的ACL，如果是Juniper，則應在實體介面的單元0上套用。
或者您需要在該區域的所有邊界部署新的 Syslog 伺服器。

我們將在其中儲存虛擬網路設備，例如虛擬路由器或根反射器。 我們可以新增 DNS 伺服器、NTP、Syslog 以及以某種方式與網路相關的所有內容。

元件2：IP空間管理系統

是的，現在有一些團隊在 Excel 檔案中追蹤前綴和 IP 位址。 但現代方法仍然是資料庫，具有 nginx/apache 前端、API 和用於記錄 IP 位址和劃分為 VRF 的網路的廣泛功能。
IPAM - IP 位址管理。

出於我們的目的，我們將在其中儲存以下資訊：

• VLAN
• 可變射頻
• 網路/子網
• IP 地址
• 將位址綁定到設備、將網路綁定到位置和 VLAN 編號

同樣，很明顯，我們希望確保當我們為 ToR 環回分配新的 IP 位址時，我們不會發現它已經分配給某人了。 或者我們在網路的不同端使用相同的前綴兩次。
但這對自動化有何幫助？
很簡單。
我們在具有 Loopbacks 角色的系統中請求一個前綴，其中包含可用於分配的 IP 位址 - 如果找到，我們分配該位址，如果沒有，我們請求建立一個新的前綴。
或者在建立設備配置時，我們可以從同一系統中找出介面應位於哪個 VRF 中。
當啟動新伺服器時，腳本會登入系統，找出伺服器所在的交換器、指派給該介面的連接埠和子網路 - 並從中指派伺服器位址。

這表示希望將 DCIM 和 IPAM 合併到一個系統中，以免功能重複，也不會為兩個相似的實體提供服務。
這就是我們要做的。

組件 3. 描述網路服務的系統

如果前兩個系統儲存仍需要以某種方式使用的變量，則第三個系統描述了每個設備角色應如何配置。
值得區分兩種不同類型的網路服務：

• 基礎設施
• 客戶。

前者旨在提供基本連接和設備控制。 其中包括 VTY、SNMP、NTP、Syslog、AAA、路由協定、CoPP 等。
後者為客戶端組織服務：MPLS L2/L3VPN、GRE、VXLAN、VLAN、L2TP等。
當然，也有一些邊界情況──哪裡包含MPLS LDP、BGP？ 是的，路由協定可用於客戶端。 但這並不重要。

兩種類型的服務都分解為配置原語：

• 實體和邏輯介面（tag/anteg、mtu）
• IP 位址和 VRF（IP、IPv6、VRF）
• ACL和流量處理策略
• 協定（IGP、BGP、MPLS）
• 路由策略（前綴列表、社群、ASN 過濾器）。
• 實用服務（SSH、NTP、LLDP、Syslog...）
• ETC。

我們具體要如何做到這一點，我還不知道。 我們將在另一篇文章中對此進行研究。

如果貼近生活一點的話，我們可以這樣描述
Leaf 交換器必須與所有連接的 Spine 交換器建立 BGP 會話，將連接的網路匯入到進程中，並且僅接受來自 Spine 交換器的來自特定前綴的網路。 將 CoPP IPv6 ND 限制為 10 pps 等。
反過來，脊椎與所有連接的線索舉行會話，充當根反射器，並只接受來自它們的特定長度和特定社區的路線。

組件4：設備初始化機制

在這個標題下，我結合了許多必須發生的操作，以便設備出現在雷達上並被遠端存取。

1. 在庫存系統中輸入設備。
2. 選擇管理IP位址。
3. 設定對其的基本存取權限：
   主機名稱、管理 IP 位址、管理網路路由、使用者、SSH 金鑰、協定 - telnet/SSH/NETCONF

有以下三種方法：

• 一切都是完全手動的。 該設備被帶到展台上，普通人員將其輸入系統，連接到控制台並進行配置。 可以在小型靜態網路上工作。
• ZTP - 零接觸配置。 硬體到達、啟動、透過 DHCP 接收位址、前往特殊伺服器並自行設定。
• 控制台伺服器的基礎設施，其中初始配置透過控制台連接埠以自動模式進行。

我們將在另一篇文章中討論這三個問題。

組件 5：與供應商無關的配置模型

到目前為止，所有系統都是不同的補丁，提供變數以及我們希望在網路上看到的內容的聲明性描述。 但遲早，你將不得不處理具體細節。
在此階段，對於每個特定設備，原語、服務和變數被組合成一個配置模型，該模型僅以供應商中立的方式實際描述特定設備的完整配置。
這一步有什麼作用呢？ 為什麼不立即創建一個可以簡單上傳的設備配置？
事實上，這解決了三個問題：

1. 不要適應特定的介面來與設備互動。 無論是 CLI、NETCONF、RESTCONF、SNMP，模型都是相同的。
2. 不要根據網路上供應商的數量來保留模板/腳本的數量，如果設計發生變化，請在多個地方更改相同的內容。
3. 從設備（備份）載入配置，將其放入完全相同的模型中，然後直接將目標配置與現有配置進行比較，以計算增量並準備一個配置補丁，該補丁將僅更改那些必要的部分或識別偏差。

此階段的結果是，我們獲得了獨立於供應商的配置。

組件 6. 供應商特定的驅動程式接口

您不應該沾沾自喜地希望有一天能夠以與 Juniper 完全相同的方式配置 ciska，只需向它們發送完全相同的調用即可。 儘管白盒越來越流行，並且出現了對NETCONF、RESTCONF、OpenConfig的支持，但這些協議提供的具體內容因供應商而異，這是他們不會輕易放棄的競爭差異之一。
這與 OpenContrail 和 OpenStack 大致相同，它們以 RestAPI 作為其 NorthBound 接口，期望完全不同的調用。

因此，在第五步驟中，獨立於供應商的模型必須採用進入硬體的形式。
這裡所有的方法都是好的（不是）：CLI、NETCONF、RESTCONF、SNMP。

因此，我們需要一個驅動程序，將上一個步驟的結果轉換為特定供應商所需的格式：一組 CLI 命令、一個 XML 結構。

組件7.向設備下發配置的機制

我們已經產生了配置，但仍然需要將其交付給設備 - 顯然，不是手動交付。
首先，我們面臨著我們將使用什麼交通工具的問題？ 今天的選擇不再小：

• CLI（遠端登入、SSH）
• SNMP
• 網絡會議
• 休息會議
• REST API
• OpenFlow（儘管它是一個異常值，因為它是傳遞 FIB 的一種方式，而不是設定）

讓我們在這裡點 t。 CLI 是遺留的。 SNMP...咳咳。
RESTCONF 仍然是一種未知的動物；幾乎沒有人支援 REST API。 因此，本系列我們將重點放在NETCONF。

事實上，正如讀者已經理解的那樣，此時我們已經決定了介面 - 上一步的結果已經以所選介面的格式呈現。

其次，我們將使用什麼工具來做到這一點？
這裡還有一個很大的選擇：

• 自寫腳本或平台。 讓我們用 ncclient 和 asyncIO 武裝自己，然後自己做所有事情。 從頭開始建置部署系統需要花費多少成本？
• Ansible 擁有豐富的網路模組庫。
• 鹽與網路和凝固汽油彈的連結微薄。
• 實際上是凝固汽油彈，它認識幾個供應商，僅此而已，再見。
• 諾尼爾是我們將來要解剖的另一種動物。

這裡尚未選擇最喜歡的 - 我們將進行搜索。

這裡還有什麼重要的呢？ 應用配置的後果。
成功與否。 是否仍可存取硬體？
看來提交將有助於確認和驗證下載到裝置的內容。
這與 NETCONF 的正確實現相結合，顯著縮小了適用設備的範圍 - 沒有多少製造商支援正常提交。 但這只是其中的先決條件之一 RFP。 最終，沒有人擔心沒有一家俄羅斯廠商會遵守32*100GE介面條件。 還是他擔心？

組件 8. CI/CD

至此，我們已經準備好所有網路設備的配置。
我寫“適用於一切”是因為我們正在討論網路狀態的版本控制。 即使您只需要更改一台交換器的設置，也會計算整個網路的變更。 顯然，對於大多數節點來說它們可以為零。

但是，正如上面已經說過的，我們並不是想要將所有東西直接投入生產的野蠻人。
產生的配置首先要經過Pipeline CI/CD。

CI/CD 代表持續整合、持續部署。 在這種方法中，團隊不僅每六個月推出一個新的主要版本，完全取代舊版本，而且定期以小部分增量實現（部署）新功能，每個功能都經過兼容性、安全性和兼容性方面的全面測試。性能（整合）。

為此，我們有一個監視配置變更的版本控制系統，一個檢查客戶端服務是否損壞的實驗室，一個檢查這一事實的監視系統，最後一步是將變更推廣到生產網路。

除了調試命令之外，網路上的所有更改絕對必須經過 CI/CD Pipeline - 這是我們平靜的生活和長久、幸福的職業的保證。

組件 9. 備份和異常檢測系統

好了，備份的事就不用再談了。
我們只需根據皇冠或配置更改的事實將它們放入 git 中。

但第二部分更有趣——有人應該關注這些備份。 在某些情況下，這個人必須去扭轉一切，而在其他情況下，必須向某人發出喵喵聲，告訴某人出了什麼問題。
例如，如果出現了未在變數中註冊的新用戶，您需要將其從駭客中刪除。 而如果最好不要碰新的防火牆規則，也許有人剛剛打開了調試，或者也許新服務，一個笨蛋，沒有按照規定註冊，但人們已經加入了。

儘管有自動化系統和鋼鐵般的管理之手，但我們仍然無法逃脫整個網路規模的一些小三角洲。 為了調試問題，無論如何沒有人會為系統添加配置。 而且，它們甚至可能不包含在配置模型中。

例如，用於計算每個特定 IP 的封包數量以定位問題的防火牆規則是完全普通的臨時配置。

組件 10. 監控系統

起初我不打算討論監控這個話題——它仍然是一個浩繁、有爭議且複雜的話題。 但隨著事情的進展，事實證明這是自動化不可或缺的一部分。 即使沒有練習，也不可能繞過它。

不斷發展的想法是 CI/CD 過程的有機組成部分。 將配置部署到網路後，我們需要能夠確定現在是否一切正常。
我們談論的不僅僅是介面使用計劃或節點可用性，而是更多微妙的事情 - 必要路由的存在、路由屬性、BGP 會話數量、OSPF 鄰居、端到端效能的疊加服務。
到外部伺服器的系統日誌是否停止添加，或者 SFlow 代理程式是否崩潰，或者佇列中的丟棄數是否開始成長，或者某些前綴對之間的連線是否中斷？

我們將在另一篇文章中對此進行反思。

結論

作為基礎，我選擇了現代資料中心網路設計 - 以 BGP 作為路由協定的 L3 Clos Fabric。
這次我們將在Juniper上建立網絡，因為現在JunOs介面是vanlove。

讓我們只使用開源工具和多供應商網路來讓我們的生活變得更加困難 - 所以除了瞻博網路之外，我還會選擇一個更幸運的人。

即將出版的出版物的計劃是這樣的：
首先我要談談虛擬網路。 首先是因為我想，其次是因為沒有這個，基礎建設網路的設計就不會很清晰。
然後是網路設計本身：拓樸、路由、策略。
讓我們組裝一個實驗室支架。
讓我們考慮一下，也許練習一下在網路上初始化設備。
然後詳細介紹每個組件。

是的，我不承諾用現成的解決方案優雅地結束這個週期。 🙂

有用的鏈接

• 在深入研究該系列之前，值得閱讀 Natasha Samoilenko 的書 網路工程師的Python。 也許會透過 課程.
• 閱讀也會很有用 RFC 關於 Peter Lapukhov 的 Facebook 資料中心工廠設計。
• 此架構文件將讓您了解 Overlay SDN 的工作原理。 鎢絲布 （以前稱為開放軌跡）。

謝謝

羅馬峽谷。 用於評論和編輯。
阿爾喬姆·切爾諾貝伊。 對於KDPV。

來源： www.habr.com