今天我就跟大家講講我們公司創建一個新的內部網路的想法是如何產生並實施的。管理階層的立場是，你需要為自己和客戶做同樣的成熟專案。如果我們自己做得很好，我們就可以邀請客戶並向他展示我們提供的產品效果如何。因此，我們非常徹底地為莫斯科辦事處開發新網路的概念，並利用整個生產週期：分析部門需求→選擇技術解決方案→設計→實施→測試。那麼就讓我們開始吧。
選擇技術解決方案：突變庇護所
目前，GOST 34.601-90「自動化系統」中對複雜自動化系統的工作流程進行了最好的描述。創造的階段”，所以我們按照它工作。在需求形成和概念開發階段，我們遇到了第一個困難。各種類型的組織（銀行、保險公司、軟體開發人員等）根據其任務和標準，需要特定類型的網絡，其具體細節是明確且標準化的。然而，這對我們不起作用。
為什麼呢？
Jet Infosystems 是一家大型多元化 IT 公司。同時，我們的內部支援部門雖小（但令人自豪），它保證了基本服務和系統的功能。該公司包含許多執行不同職能的部門：這些是幾個強大的外包團隊，以及業務系統和資訊安全的內部開發人員，以及計算系統的架構師 - 一般來說，無論是誰。相應地，它們的任務、系統和安全策略也不同。正如預期的那樣，這給需求分析和標準化過程帶來了困難。
例如，這裡是開發部門：其員工為大量客戶編寫和測試程式碼。經常需要快速組織測試環境，坦白講，並不總是能夠按照所有內部規定為每個項目制定需求、申請資源並建立單獨的測試環境。這就產生了奇怪的情況：有一天，你卑微的僕人查看了開發人員的房間，發現桌子下面有一個正常工作的 Hadoop 集群，由 20 個桌面組成，它莫名其妙地連接到一個公共網絡。我認為沒有必要澄清該公司的 IT 部門並不知道它的存在。與許多其他情況一樣，這種情況導致了在該專案的開發過程中，「突變儲備」一詞誕生，描述了長期遭受苦難的辦公基礎設施的狀況。
或者這是另一個例子。定期在部門內設立測試台。 Jira和Confluence就是這樣，軟體開發中心在某些專案中有限地使用了它們。一段時間後，其他部門了解了這些有用的資源，並對它們進行了評估，2018年底，Jira和Confluence從「本地程式設計師的玩具」狀態轉變為「公司資源」狀態。現在必須為這些系統分配一個所有者、SLA、存取/資訊安全策略、備份策略、監控、用於解決問題的路由請求的規則 - 一般來說，必須存在成熟資訊系統的所有屬性。
我們的每個部門也是一個培育自己產品的孵化器。其中一些在開發階段就消失了，有些我們在專案工作時使用，而有些則紮根並成為我們開始使用並出售給客戶的複製解決方案。對於每個這樣的系統，都希望有自己的網路環境，在其中開發時不會幹擾其他系統，並且在某些時候可以整合到公司的基礎設施中。
除了發展，我們還有非常大的 擁有500多名員工，針對每位客戶組成團隊。他們參與維護網路和其他系統、遠端監控、解決索賠等。也就是說，SC 的基礎設施實際上是他們目前合作的客戶的基礎設施。使用這部分網路的特殊之處在於我們公司的工作站部分是外部的，部分是內部的。因此，對於SC我們採用瞭如下的做法——公司為相應部門提供網路等資源，將這些部門的工作站視為外部連接（類比分支機構和遠端用戶）。
公路設計：我們是營運商（驚喜）
在評估了所有陷阱後，我們意識到我們正在一個辦公室內獲得電信運營商的網絡，因此我們開始採取相應行動。
我們創建了一個核心網絡，借助該網絡，可以為任何內部以及未來的外部消費者提供所需的服務：L2 VPN、L3 VPN 或常規 L3 路由。一些部門需要安全的互聯網訪問，而另一些部門則需要沒有防火牆的乾淨訪問，但同時保護我們的公司資源和核心網路免受其流量的影響。
我們與每個部門非正式地「簽訂了 SLA」。根據該規定，所有發生的事件都必須在一定的、預先商定的時間內消除。事實證明，該公司對其網路的要求非常嚴格。如果電話和電子郵件發生故障，事件的最長回應時間為 5 分鐘。在典型故障期間恢復網路功能的時間不超過一分鐘。
由於我們擁有電信級網絡，您只能嚴格遵守規則連接。服務單位制定政策並提供服務。他們甚至不需要有關特定伺服器、虛擬機器和工作站的連接的資訊。但同時，也需要保護機制，因為單一連線不應停用網路。如果意外地建立了環路，其他使用者不應注意到這一點，即需要來自網路的充分回應。任何電信業者都在其核心網路中不斷解決類似的看似複雜的問題。它為具有不同需求和流量的許多客戶提供服務。同時，不同的訂戶也不應因其他訂戶的流量而感到不便。
在國內，我們是透過以下方式解決這個問題的：我們建立了一個全冗餘的骨幹三層網絡，使用IS-IS協定。基於技術在核心之上建立覆蓋網絡 /，使用路由協定 。為了加快路由協定的收斂速度，採用了BFD技術。
網絡結構
在測試中，該方案表現出了出色的表現——當任何通道或交換機斷開時，收斂時間不超過0.1-0.2秒，丟失的數據包最少（通常沒有），TCP會話不中斷，電話通話不被打擾。
底層 - 路由
覆蓋層-路由
分佈交換器採用具有VXLAN License的華為CE6870交換器。該設備具有最佳的性價比，可讓您以 10 Gbit/s 的速度連接用戶，並以 40–100 Gbit/s 的速度連接到骨幹網，具體取決於所使用的收發器。
華為CE6870交換機
核心交換器採用華為CE8850交換器。目標是快速可靠地傳輸流量。除了分佈交換器之外，沒有任何設備連接到它們，它們對VXLAN 一無所知，因此選擇了具有32 個40/100 Gbps 連接埠的型號，具有提供L3 路由並支援IS-IS 和MP-BGP 的基本許可證協議。
最下面一張是華為CE8850核心交換機
在設計階段，團隊內部就可用於實現核心網路節點容錯連接的技術展開了討論。我們的莫斯科辦事處位於三棟大樓內，有7個配電室，每個配電室安裝了兩台華為CE6870配電交換機（幾個配電室只安裝了接入交換器）。在開發網路概念時，考慮了兩種冗餘選項：
- 將配電交換器合併到每個交叉連接室的容錯堆疊中。優點：簡單且易於設定。缺點：當網路設備的韌體出現錯誤（「記憶體洩漏」等）時，整個堆疊故障的機率較高。
- 應用M-LAG和Anycast閘道技術將裝置連接到分佈交換器。
最後我們選擇了第二種方案。它的配置稍微困難一些，但在實踐中已顯示出其性能和高可靠性。
我們首先考慮將終端設備連接到分配交換器：
叉
兩個分佈交換器包含存取交換器、伺服器或任何其他需要容錯連接的裝置。 M-LAG技術提供資料鏈路層級的冗餘。假設兩個分配交換器對於所連接的設備來說顯示為一台設備。使用 LACP 協定進行冗餘和負載平衡。
任播網關技術提供網路層級的冗餘。每個分佈交換機上都配置了相當多的VRF（每個VRF 都有自己的用途- 單獨用於“常規”用戶、單獨用於電話、單獨用於各種測試和開發環境等），並且在每個分配交換器中都配置了相當多的 VRF。VRF 配置了多個 VLAN。在我們的網路中，分配交換器是與其連接的所有裝置的預設閘道。兩個分佈交換器的 VLAN 介面對應的 IP 位址相同。流量透過最近的交換器進行路由。
現在讓我們看看將分發交換器連接到核心：
使用 IS-IS 協定在網路層級提供容錯。請注意，交換器之間提供單獨的 L3 通訊線路，速度為 100G。從物理上看，這條通訊線是一條 Direct Access 電纜；可以在華為 CE6870 交換器的右側照片中看到。
另一個選擇是組織一個「誠實」的全連接雙星拓撲，但是，如上所述，我們在三棟建築中有 7 個交叉連接的房間。因此，如果我們選擇「雙星」拓撲，我們將需要兩倍數量的「遠端」40G 收發器。這裡的節省非常可觀。
關於 VXLAN 和 Anycast 閘道技術如何協同工作需要多說幾句。 VXLAN，不用贅述，是一種在 UDP 封包內傳輸乙太網路封包的隧道。分佈交換器的Loopback介面作為VXLAN隧道的目的IP位址。每個交叉都有兩個具有相同環回介面位址的交換機，因此封包可以到達其中任何一個，並可以從中提取乙太網路訊框。
如果交換器知道檢索到的訊框的目標 MAC 位址，則該訊框將被正確傳送到其目的地。為了確保安裝在同一交叉連接中的兩台分佈交換器都具有有關從接入交換機「到達」的所有 MAC 位址的最新信息，M-LAG 機制負責同步 MAC 位址表（以及 ARP）表）在兩個交換機M-LAG 對上。
由於底層網路中存在多條通往分佈交換器環回介面的路由，因此可以實現流量平衡。
取而代之的是結論
如上所述，在測試和運行過程中，該網路表現出高可靠性（典型故障恢復時間不超過數百毫秒）和良好的性能——每個交叉連接通過兩個40 Gbit/s通道連接到核心。我們網路中的存取交換器堆疊在一起，並透過具有兩個 10 Gbit/s 通道的 LACP/M-LAG 連接到分配交換器。一個堆疊通常包含 5 個交換機，每個交換器有 48 個端口，每個交叉連接中最多有 10 個接入堆疊連接到分佈。因此，即使在最大理論負載下，主幹網路也能為每個用戶提供約 30 Mbit/s 的速度，在撰寫本文時這足以滿足我們所有的實際應用。
此網路可讓您透過 L2 和 L3 輕鬆組織任意連接裝置的配對，從而提供流量（資訊安全服務喜歡的）和故障域（營運服務喜歡的）的完全隔離。
在下一部分中，我們將告訴您我們如何遷移到新網路。敬請關注！
馬克西姆·克洛奇科夫
網路審計及複雜專案小組資深顧問
網路解決方案中心
“噴射資訊系統”
來源： www.habr.com