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