由于混合云與容器網絡的出現(xiàn)，數(shù)據中心網絡比以往任何時候都更加復雜�，F(xiàn)在已經不再是遵循簡單的原則，IT就容易成功的時代�，F(xiàn)代的數(shù)據中心網絡更加復雜，也更加的自動化。
在不久的將來，數(shù)據中心內的流量轉發(fā)將會變得很簡單。一個IP地址將會與另一個IP地址通話。這些地址都屬于端點(結束點) ——裸機主機或虛擬機與其他裸機主機或虛擬機進行通信。
這些IP地址之間的路徑被數(shù)據中心交換機知道為路由和橋接表中的條目。
如果一位工程師需要尋找兩個IP端點之間的故障或一些異常的行為，最好是從查看構造這兩條路徑之間的一些表格查起。等成本多路徑與multichassis鏈路聚合增加了這一過程的復雜性，但就整體而言，運營商還是可以找出合適的路徑讓任何數(shù)據中心之間都能建立路徑，彼此對話。
備注：Equal-cost multipath (ECMP)：等成本多路徑路由是一種路由策略，其中下一跳數(shù)據包轉發(fā)到單個目的地可以發(fā)生在多個“最佳路徑”上，這些路徑在路由度量計算中位居榜首。多路徑路由可以與大多數(shù)路由協(xié)議一起使用，因為它是一個限于單個路由器的每跳決策。它可以通過負載平衡多條路徑上的流量來顯著增加帶寬。但是，在實際應用中可能會遇到重大問題。一般來說RFC 2991討論了多路徑路由。2014年，電氣和電子工程師協(xié)會(IEEE)將等價多路徑(ECMP)或IEEE標準802.1Qbp合并到IEEE 802.1Q-2014中以實現(xiàn)最短路徑橋接。將最短路徑橋接中用于單播和多播流量的前向和反向路徑指定為確定性路徑上的對稱保險流，解決原始標準實施中的配置復雜性，管理功能和性能問題。
事實上，端點與端點之間的通信并沒有什么復雜的。網絡地址之間的轉換、加密或數(shù)據挖掘很少出現(xiàn)。這些功能往往位于數(shù)據中心的邊緣位置，與受信任范圍之外的設備進行通信。
現(xiàn)代數(shù)據中心
隨著業(yè)務需求的變化，現(xiàn)代數(shù)據中心的網絡架構看起來跟以往的有些不同。比起過去設施相對單一的數(shù)據中心，現(xiàn)代的數(shù)據中心則是完整的、統(tǒng)一的基礎設架構平臺，在這個平臺上運行著各種應用程序。數(shù)據中心被視為一個整體;它是應用程序交付的引擎。
越來越多的基礎設施都在對應用程序的開發(fā)人員透明化。 完全現(xiàn)代化的基礎設施對開發(fā)人員以及應用程序而言，似乎有些抽象，不夠具體。 不過開發(fā)人員不必為此擔憂，數(shù)據中心資源都是按需分配，平臺會智能分配資源。
現(xiàn)代數(shù)據中心以一種分布式的方式處理安全問題，協(xié)調動態(tài)管理資源與卸載工作負載問題。而不再需要通過中央物理防火墻來強制執(zhí)行安全策略。
比起構建中央安全策略，安全管理人員將該套軟件的相關部分安裝到受與之有關的主機、VM上，似乎是更容易操作、管理。不需要基礎設施，也不需要路由需求來強制執(zhí)行這樣的政策。
在高層級上，我們一直在規(guī)劃私有云架構，在這種方式下的物理基礎設施，可以與公共云進行更簡單的協(xié)作。因此，混合云架構越來越受歡迎，人們期望公共云工作與私有云能夠具有相同的安全性和連接性。
層級
隨著混合云架構成為新的常態(tài)，重要的是要注意這些趨勢對網絡的影響。數(shù)據中心不再像之前簡單地一個IP地址與地與另一個IP地址進行對話，在遇到麻煩時，路由和橋接表可以進行協(xié)商。
現(xiàn)代數(shù)據中心靈活性的基礎設施更加依賴于復雜的網絡。推動這種復雜性的是工作負載隔離、服務策略實施和安全性的需要。因此，與其說是IP地址的海洋，倒不如說現(xiàn)代數(shù)據中心更像是一層蛋糕。
蛋糕底部是底層網絡。這層網絡是所有其他網絡服務的基礎。這也是網絡工程師最熟悉的網絡。當他們查看他們的路由和橋接表時，他們看到的是底層網絡——數(shù)據中心的基礎。
然而，底層網絡本身不能提供混合云所需的一切。日益增長對網絡的要求是將負載進行隔離，稱為多租戶。租戶可以是應用程序、業(yè)務單元或者是客戶。
租戶的流量可以通過虛擬LAN(VXLAN)進行擴展，通過封裝技術與其他流量隔離。 來自一個網段的流量被封裝在一個VXLAN數(shù)據包中，通過網絡傳送到另一邊的解封裝。 VXLAN是第二層 - 覆蓋層 - 位于底層之上。
它不僅可以提供流量分離，還可以通過VXLAN通過網絡上的特定路徑來路由流量。 假設數(shù)據中心需要通過特定的防火墻和負載均衡器轉發(fā)流量。 在現(xiàn)代網絡中，防火墻和負載均衡器可能作為虛擬化網絡功能存在，可能位于數(shù)據中心的任何位置。 為了將流量精確地路由到需要去的地方，可以使用VXLAN封裝將設備之間的流量通過隧道，直到遍歷所有需要的設備。
防火墻規(guī)則在我們的覆蓋底層蛋糕中形成另一層。 中央策略管理器按主機插入防火墻規(guī)則主機。 每個主機都有自己的一組規(guī)則來管理進出設備。 對已知負載進行分割，這是確�？蓴U展數(shù)據中心安全性的一種實用方法。
容器增加了更多網絡復雜性的通配符。 容器網絡是一種新興的技術，受名稱空間，代理服務器和網絡地址轉換的控制，使得容器能夠相互通信，而外部工作又是另一層。
容器是一個簡潔操作系統(tǒng)虛擬化方法，用于從其他服務在同一容器主機上運行的分隔應用程序或服務。 若要啟用此功能，每個容器具有操作系統(tǒng)、 進程，文件系統(tǒng)、 注冊表以及 IP 地址的視圖。
容器類似于網絡關于希望在虛擬機的功能。 每個容器已連接到哪些傳入和傳出的通信的虛擬交換機虛擬網絡適配器。 強制容器同一臺主機上的分隔，為每個 Windows Server 和 HYPER-V 容器容器該網絡適配器安裝到其中創(chuàng)建網絡盒。 Windows Server 容器使用主機 vNIC 吸附到虛擬交換機用來。 HYPER-V 容器使用綜合 VM NIC (不會受到實用程序 VM) 連接到虛擬交換機用來。
容器端點可以將附加到主機本地網絡 (如 NAT)、 物理網絡或通過 Microsoft 軟件定義網絡 (SDN) 堆棧創(chuàng)建覆蓋虛擬網絡。
運營商的困擾
現(xiàn)代數(shù)據中心網絡架構所帶來的復雜性是運營商面臨的潛在問題。 大多數(shù)網絡問題都與連接或性能有關。 應該能夠連接但不能的兩個端點是一種問題。 兩個端點連接，但沒有如預期的那樣快速通信是另一個問題。
使用分組漫游方法解決連接問題。 從一個網絡設備到另一個網絡設備，遵循數(shù)據包到達目的地的路徑。 當知道實際的IP端點時，這很簡單。
在現(xiàn)代數(shù)據中心，底層用于傳輸VXLAN或其他覆蓋數(shù)據包。最重要的是，我們添加防火墻規(guī)則，然后可能是網絡地址轉換或代理服務; 數(shù)據包丟失變得更加困難，充滿細微差別。
為了診斷連接問題，運營商需要知道數(shù)據包的來源和目的地 - 包括容器，虛擬機或裸機主機，管理該數(shù)據包的防火墻策略，數(shù)據包封裝和要遵循的服務鏈。
假設運營商了解應用程序流，并在沒有任何障礙的IT組織中運行，看起來，這并不是那么糟糕。 當然，在實際條件下，這種情況并不多見。在橋接和路由表中查找媒體訪問控制和IP地址只是更復雜的故障排除過程的一小部分。 加上現(xiàn)代基礎設施往往是短暫的事實，運營商可以解決過去發(fā)生的，但不能重建問題。
事實上，性能方面的問題挑戰(zhàn)更難以診斷。 接觸給定對話的網絡設備的數(shù)量可能涉及虛擬操作系統(tǒng)，管理程序軟交換機，虛擬防火墻，架頂式交換機，主干交換機，然后一直到另一端點。
當一些工作負載在公共云中時，事情變得更加復雜。 將基礎設施或平臺作為服務放在等式中，意味著在我們的故障排除方面，添加高延遲等變量。
行業(yè)反應
我們堅持知識產權。 而且由于我們被困在IP中，同時又需要額外的功能，疊加在這里。 疊加使我們能夠引導和隔離流量，而且功能非常重要。 有了它，我們可以將我們的基礎設施視為資源池，隨意添加和減少容量。 這個問題變成了管理我們添加到環(huán)境中的網絡復雜性的問題之一。
網絡行業(yè)已經在幾個方面接受了這個挑戰(zhàn)。 首先是接受。 如果我們同意復雜性在這里，那么我們將提供工具，使我們能夠發(fā)現(xiàn)或可視化網絡上發(fā)生的事情。 例如，思科為運營商提供增強的工具，以便在其以應用為中心的基礎架構平臺上解決端到端的連接問題。 VMware最近購買了一款可視化工具Arkin，該工具將工作負載與防火墻策略和VXLAN分割相關聯(lián)，并與自然語言搜索引擎配對。
有效的故障排除和可視化工具正日益成為現(xiàn)代數(shù)據中心平臺的優(yōu)勢。 但是，有些人通過創(chuàng)建轉發(fā)方案來避免復雜性，如果可能的話，避免覆蓋。
例如，Romana.io開放源代碼項目依賴于分層IP尋址方案與基于主機的防火墻規(guī)則相結合來創(chuàng)建分段和中央安全策略。 開源項目Calico是相似的。 Romana.io和Project Calico都非常有趣，因為它們提供的轉發(fā)方案可以擴展到大型數(shù)據中心，同時還能處理安全性和分段要求，而且不需要重疊。
也許目前遇到的 最大的問題不是如何處理網絡復雜性問題，而是關于如何提供支持解決方案的工作人員。 有一個想法是，自動化將允許IT人員減少。 作為一名20年的IT基礎設施老手，我不這么認為。 比如，遇到非常復雜網絡問題，就需要經驗豐富的IT人員及時解決問題。當自動化出現(xiàn)故障的時候，企業(yè)、組織不僅僅希望與他們的供應商保持聯(lián)系。他們同時還希望有專業(yè)知識的專業(yè)人士隨時準備解決問題。
