在不久的將來(lái)，數(shù)據(jù)中心內(nèi)的流量轉(zhuǎn)發(fā)將會(huì)變得很簡(jiǎn)單。一個(gè)IP地址將會(huì)與另一個(gè)IP地址通話(huà)。這些地址都屬于端點(diǎn)（結(jié)束點(diǎn)） ——裸機(jī)主機(jī)或虛擬機(jī)與其他裸機(jī)主機(jī)或虛擬機(jī)進(jìn)行通信。

　　這些IP地址之間的路徑被數(shù)據(jù)中心交換機(jī)知道為路由和橋接表中的條目。

　　如果一位工程師需要尋找兩個(gè)IP端點(diǎn)之間的故障或一些異常的行為，最好是從查看構(gòu)造這兩條路徑之間的一些表格查起。等成本多路徑與multichassis鏈路聚合增加了這一過(guò)程的復(fù)雜性，但就整體而言，運(yùn)營(yíng)商還是可以找出合適的路徑讓任何數(shù)據(jù)中心之間都能建立路徑，彼此對(duì)話(huà)。

　　備注：Equal-cost multipath （ECMP）：等成本多路徑路由是一種路由策略，其中下一跳數(shù)據(jù)包轉(zhuǎn)發(fā)到單個(gè)目的地可以發(fā)生在多個(gè)“最佳路徑”上，這些路徑在路由度量計(jì)算中位居榜首。多路徑路由可以與大多數(shù)路由協(xié)議一起使用，因?yàn)樗�是一個(gè)限于單個(gè)路由器的每跳決策。它可以通過(guò)負(fù)載平衡多條路徑上的流量來(lái)顯著增加帶寬。但是，在實(shí)際應(yīng)用中可能會(huì)遇到重大問(wèn)題。一般來(lái)說(shuō)RFC 2991討論了多路徑路由。2014年，電氣和電子工程師協(xié)會(huì)（IEEE）將等價(jià)多路徑（ECMP）或IEEE標(biāo)準(zhǔn)802.1Qbp合并到IEEE 802.1Q-2014中以實(shí)現(xiàn)最短路徑橋接。將最短路徑橋接中用于單播和多播流量的前向和反向路徑指定為確定性路徑上的對(duì)稱(chēng)保險(xiǎn)流，解決原始標(biāo)準(zhǔn)實(shí)施中的配置復(fù)雜性，管理功能和性能問(wèn)題。

　　事實(shí)上，端點(diǎn)與端點(diǎn)之間的通信并沒(méi)有什么復(fù)雜的。網(wǎng)絡(luò)地址之間的轉(zhuǎn)換、加密或數(shù)據(jù)挖掘很少出現(xiàn)。這些功能往往位于數(shù)據(jù)中心的邊緣位置，與受信任范圍之外的設(shè)備進(jìn)行通信。

　　隨著業(yè)務(wù)需求的變化，現(xiàn)代數(shù)據(jù)中心的網(wǎng)絡(luò)架構(gòu)看起來(lái)跟以往的有些不同。比起過(guò)去設(shè)施相對(duì)單一的數(shù)據(jù)中心，現(xiàn)代的數(shù)據(jù)中心則是完整的、統(tǒng)一的基礎(chǔ)設(shè)架構(gòu)平臺(tái)，在這個(gè)平臺(tái)上運(yùn)行著各種應(yīng)用程序。數(shù)據(jù)中心被視為一個(gè)整體；它是應(yīng)用程序交付的引擎。

　　越來(lái)越多的基礎(chǔ)設(shè)施都在對(duì)應(yīng)用程序的開(kāi)發(fā)人員透明化。 完全現(xiàn)代化的基礎(chǔ)設(shè)施對(duì)開(kāi)發(fā)人員以及應(yīng)用程序而言，似乎有些抽象，不夠具體。 不過(guò)開(kāi)發(fā)人員不必為此擔(dān)憂(yōu)，數(shù)據(jù)中心資源都是按需分配，平臺(tái)會(huì)智能分配資源。

　　現(xiàn)代數(shù)據(jù)中心以一種分布式的方式處理安全問(wèn)題，協(xié)調(diào)動(dòng)態(tài)管理資源與卸載工作負(fù)載問(wèn)題。而不再需要通過(guò)中央物理防火墻來(lái)強(qiáng)制執(zhí)行安全策略。

　　比起構(gòu)建中央安全策略，安全管理人員將該套軟件的相關(guān)部分安裝到受與之有關(guān)的主機(jī)、VM上，似乎是更容易操作、管理。不需要基礎(chǔ)設(shè)施，也不需要路由需求來(lái)強(qiáng)制執(zhí)行這樣的政策。

　　在高層級(jí)上，我們一直在規(guī)劃私有云架構(gòu)，在這種方式下的物理基礎(chǔ)設(shè)施，可以與公共云進(jìn)行更簡(jiǎn)單的協(xié)作。因此，混合云架構(gòu)越來(lái)越受歡迎，人們期望公共云工作與私有云能夠具有相同的安全性和連接性。

　　隨著混合云架構(gòu)成為新的常態(tài)，重要的是要注意這些趨勢(shì)對(duì)網(wǎng)絡(luò)的影響。數(shù)據(jù)中心不再像之前簡(jiǎn)單地一個(gè)IP地址與地與另一個(gè)IP地址進(jìn)行對(duì)話(huà)，在遇到麻煩時(shí)，路由和橋接表可以進(jìn)行協(xié)商。

　　現(xiàn)代數(shù)據(jù)中心靈活性的基礎(chǔ)設(shè)施更加依賴(lài)于復(fù)雜的網(wǎng)絡(luò)。推動(dòng)這種復(fù)雜性的是工作負(fù)載隔離、服務(wù)策略實(shí)施和安全性的需要。因此，與其說(shuō)是IP地址的海洋，倒不如說(shuō)現(xiàn)代數(shù)據(jù)中心更像是一層蛋糕。

　　蛋糕底部是底層網(wǎng)絡(luò)。這層網(wǎng)絡(luò)是所有其他網(wǎng)絡(luò)服務(wù)的基礎(chǔ)。這也是網(wǎng)絡(luò)工程師最熟悉的網(wǎng)絡(luò)。當(dāng)他們查看他們的路由和橋接表時(shí)，他們看到的是底層網(wǎng)絡(luò)——數(shù)據(jù)中心的基礎(chǔ)。

　　然而，底層網(wǎng)絡(luò)本身不能提供混合云所需的一切。日益增長(zhǎng)對(duì)網(wǎng)絡(luò)的要求是將負(fù)載進(jìn)行隔離，稱(chēng)為多租戶(hù)。租戶(hù)可以是應(yīng)用程序、業(yè)務(wù)單元或者是客戶(hù)。

　　租戶(hù)的流量可以通過(guò)虛擬LAN（VXLAN）進(jìn)行擴(kuò)展，通過(guò)封裝技術(shù)與其他流量隔離。 來(lái)自一個(gè)網(wǎng)段的流量被封裝在一個(gè)VXLAN數(shù)據(jù)包中，通過(guò)網(wǎng)絡(luò)傳送到另一邊的解封裝。 VXLAN是第二層 - 覆蓋層 - 位于底層之上。

　　它不僅可以提供流量分離，還可以通過(guò)VXLAN通過(guò)網(wǎng)絡(luò)上的特定路徑來(lái)路由流量。 假設(shè)數(shù)據(jù)中心需要通過(guò)特定的防火墻和負(fù)載均衡器轉(zhuǎn)發(fā)流量。 在現(xiàn)代網(wǎng)絡(luò)中，防火墻和負(fù)載均衡器可能作為虛擬化網(wǎng)絡(luò)功能存在，可能位于數(shù)據(jù)中心的任何位置。 為了將流量精確地路由到需要去的地方，可以使用VXLAN封裝將設(shè)備之間的流量通過(guò)隧道，直到遍歷所有需要的設(shè)備。

　　防火墻規(guī)則在我們的覆蓋底層蛋糕中形成另一層。 中央策略管理器按主機(jī)插入防火墻規(guī)則主機(jī)。 每個(gè)主機(jī)都有自己的一組規(guī)則來(lái)管理進(jìn)出設(shè)備。 對(duì)已知負(fù)載進(jìn)行分割，這是確�？蓴U(kuò)展數(shù)據(jù)中心安全性的一種實(shí)用方法。

　　容器增加了更多網(wǎng)絡(luò)復(fù)雜性的通配符。 容器網(wǎng)絡(luò)是一種新興的技術(shù)，受名稱(chēng)空間，代理服務(wù)器和網(wǎng)絡(luò)地址轉(zhuǎn)換的控制，使得容器能夠相互通信，而外部工作又是另一層。

　　容器是一個(gè)簡(jiǎn)潔操作系統(tǒng)虛擬化方法，用于從其他服務(wù)在同一容器主機(jī)上運(yùn)行的分隔應(yīng)用程序或服務(wù)。 若要啟用此功能，每個(gè)容器具有操作系統(tǒng)、 進(jìn)程，文件系統(tǒng)、 注冊(cè)表以及 IP 地址的視圖。

　　容器類(lèi)似于網(wǎng)絡(luò)關(guān)于希望在虛擬機(jī)的功能。 每個(gè)容器已連接到哪些傳入和傳出的通信的虛擬交換機(jī)虛擬網(wǎng)絡(luò)適配器。 強(qiáng)制容器同一臺(tái)主機(jī)上的分隔，為每個(gè) Windows Server 和 HYPER-V 容器容器該網(wǎng)絡(luò)適配器安裝到其中創(chuàng)建網(wǎng)絡(luò)盒。 Windows Server 容器使用主機(jī) vNIC 吸附到虛擬交換機(jī)用來(lái)。 HYPER-V 容器使用綜合 VM NIC （不會(huì)受到實(shí)用程序 VM） 連接到虛擬交換機(jī)用來(lái)。

　　容器端點(diǎn)可以將附加到主機(jī)本地網(wǎng)絡(luò) （如 NAT）、 物理網(wǎng)絡(luò)或通過(guò) Microsoft 軟件定義網(wǎng)絡(luò) （SDN） 堆棧創(chuàng)建覆蓋虛擬網(wǎng)絡(luò)。

　　現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)所帶來(lái)的復(fù)雜性是運(yùn)營(yíng)商面臨的潛在問(wèn)題。 大多數(shù)網(wǎng)絡(luò)問(wèn)題都與連接或性能有關(guān)。 應(yīng)該能夠連接但不能的兩個(gè)端點(diǎn)是一種問(wèn)題。 兩個(gè)端點(diǎn)連接，但沒(méi)有如預(yù)期的那樣快速通信是另一個(gè)問(wèn)題。

　　使用分組漫游方法解決連接問(wèn)題。 從一個(gè)網(wǎng)絡(luò)設(shè)備到另一個(gè)網(wǎng)絡(luò)設(shè)備，遵循數(shù)據(jù)包到達(dá)目的地的路徑。 當(dāng)知道實(shí)際的IP端點(diǎn)時(shí)，這很簡(jiǎn)單。

　　在現(xiàn)代數(shù)據(jù)中心，底層用于傳輸VXLAN或其他覆蓋數(shù)據(jù)包。最重要的是，我們添加防火墻規(guī)則，然后可能是網(wǎng)絡(luò)地址轉(zhuǎn)換或代理服務(wù)； 數(shù)據(jù)包丟失變得更加困難，充滿(mǎn)細(xì)微差別。

　　為了診斷連接問(wèn)題，運(yùn)營(yíng)商需要知道數(shù)據(jù)包的來(lái)源和目的地 - 包括容器，虛擬機(jī)或裸機(jī)主機(jī)，管理該數(shù)據(jù)包的防火墻策略，數(shù)據(jù)包封裝和要遵循的服務(wù)鏈。

　　假設(shè)運(yùn)營(yíng)商了解應(yīng)用程序流，并在沒(méi)有任何障礙的IT組織中運(yùn)行，看起來(lái)，這并不是那么糟糕。 當(dāng)然，在實(shí)際條件下，這種情況并不多見(jiàn)。在橋接和路由表中查找媒體訪(fǎng)問(wèn)控制和IP地址只是更復(fù)雜的故障排除過(guò)程的一小部分。 加上現(xiàn)代基礎(chǔ)設(shè)施往往是短暫的事實(shí)，運(yùn)營(yíng)商可以解決過(guò)去發(fā)生的，但不能重建問(wèn)題。

　　事實(shí)上，性能方面的問(wèn)題挑戰(zhàn)更難以診斷。 接觸給定對(duì)話(huà)的網(wǎng)絡(luò)設(shè)備的數(shù)量可能涉及虛擬操作系統(tǒng)，管理程序軟交換機(jī)，虛擬防火墻，架頂式交換機(jī)，主干交換機(jī)，然后一直到另一端點(diǎn)。

　　當(dāng)一些工作負(fù)載在公共云中時(shí)，事情變得更加復(fù)雜。 將基礎(chǔ)設(shè)施或平臺(tái)作為服務(wù)放在等式中，意味著在我們的故障排除方面，添加高延遲等變量。

　　我們堅(jiān)持知識(shí)產(chǎn)權(quán)。 而且由于我們被困在IP中，同時(shí)又需要額外的功能，疊加在這里。 疊加使我們能夠引導(dǎo)和隔離流量，而且功能非常重要。 有了它，我們可以將我們的基礎(chǔ)設(shè)施視為資源池，隨意添加和減少容量。 這個(gè)問(wèn)題變成了管理我們添加到環(huán)境中的網(wǎng)絡(luò)復(fù)雜性的問(wèn)題之一。

　　網(wǎng)絡(luò)行業(yè)已經(jīng)在幾個(gè)方面接受了這個(gè)挑戰(zhàn)。 首先是接受。 如果我們同意復(fù)雜性在這里，那么我們將提供工具，使我們能夠發(fā)現(xiàn)或可視化網(wǎng)絡(luò)上發(fā)生的事情。 例如，思科為運(yùn)營(yíng)商提供增強(qiáng)的工具，以便在其以應(yīng)用為中心的基礎(chǔ)架構(gòu)平臺(tái)上解決端到端的連接問(wèn)題。 VMware最近購(gòu)買(mǎi)了一款可視化工具Arkin，該工具將工作負(fù)載與防火墻策略和VXLAN分割相關(guān)聯(lián)，并與自然語(yǔ)言搜索引擎配對(duì)。

　　有效的故障排除和可視化工具正日益成為現(xiàn)代數(shù)據(jù)中心平臺(tái)的優(yōu)勢(shì)。 但是，有些人通過(guò)創(chuàng)建轉(zhuǎn)發(fā)方案來(lái)避免復(fù)雜性，如果可能的話(huà)，避免覆蓋。

　　例如，Romana.io開(kāi)放源代碼項(xiàng)目依賴(lài)于分層IP尋址方案與基于主機(jī)的防火墻規(guī)則相結(jié)合來(lái)創(chuàng)建分段和中央安全策略。 開(kāi)源項(xiàng)目Calico是相似的。 Romana.io和Project Calico都非常有趣，因?yàn)樗鼈兲峁┑霓D(zhuǎn)發(fā)方案可以擴(kuò)展到大型數(shù)據(jù)中心，同時(shí)還能處理安全性和分段要求，而且不需要重疊。

　　也許目前遇到的 最大的問(wèn)題不是如何處理網(wǎng)絡(luò)復(fù)雜性問(wèn)題，而是關(guān)于如何提供支持解決方案的工作人員。 有一個(gè)想法是，自動(dòng)化將允許IT人員減少。 作為一名20年的IT基礎(chǔ)設(shè)施老手，我不這么認(rèn)為。 比如，遇到非常復(fù)雜網(wǎng)絡(luò)問(wèn)題，就需要經(jīng)驗(yàn)豐富的IT人員及時(shí)解決問(wèn)題。當(dāng)自動(dòng)化出現(xiàn)故障的時(shí)候，企業(yè)、組織不僅僅希望與他們的供應(yīng)商保持聯(lián)系。他們同時(shí)還希望有專(zhuān)業(yè)知識(shí)的專(zhuān)業(yè)人士隨時(shí)準(zhǔn)備解決問(wèn)題。