在不太遙遠(yuǎn)的過去，數(shù)據(jù)中心內(nèi)的流量轉(zhuǎn)發(fā)是簡單的。一個IP地址將與另一個IP地址實現(xiàn)通訊。這些地址屬于端點——裸金屬主機或虛擬機與其他裸露的金屬主機或虛擬機實現(xiàn)通訊。這些IP地址之間的路徑被稱為數(shù)據(jù)中心交換機，就像路由和橋接表中的入口。

如果某位工程師需要解決兩個IP端點之間的性能低下或異常問題時，一種很好的辦法就是觀察兩者之間的這些表單。等價多路徑與多機架鏈路聚合為這一過程增加了復(fù)雜性，但總的來說，運行維護人員可以精確地找出任何指定的數(shù)據(jù)中心會話的路徑。

多個端點之間的通訊流會有些復(fù)雜。網(wǎng)絡(luò)地址轉(zhuǎn)換，加密或打通是很少存在的。這些類型的功能往往位于數(shù)據(jù)中心的邊緣，與可信邊界外部的設(shè)備進行聯(lián)系。

這個時代流行簡單，是因為需求簡單。

由于商業(yè)需求的變化，現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)已經(jīng)變得不一樣。曾經(jīng)相對簡單的數(shù)據(jù)中心，現(xiàn)在已成為運行的應(yīng)用程序的統(tǒng)一的基礎(chǔ)設(shè)施平臺。數(shù)據(jù)中心作為一個整體運行；它是應(yīng)用程序交付的引擎。

越來越多的基礎(chǔ)設(shè)施面向開發(fā)者和他們的應(yīng)用程序透明。某一完整意義上的現(xiàn)代基礎(chǔ)設(shè)施應(yīng)該是開發(fā)人員所部署應(yīng)用程序的抽象。資源池按需分配，而開發(fā)者不必?fù)?dān)心基礎(chǔ)設(shè)施的問題。基礎(chǔ)設(shè)施不僅只是運行那么簡單。

現(xiàn)代數(shù)據(jù)中心還需要用分布式的辦法處理安全問題，采取通過工作負(fù)載的創(chuàng)建和取消相結(jié)合的方式。不再需要通過某一集中的、物理防火墻來執(zhí)行增強的安全策略。相反，某一集中的安全策略是結(jié)構(gòu)化的，并且安全管理人員將有關(guān)的策略安裝到受影響的主機、虛擬機或容器上。增強這樣的策略沒有基礎(chǔ)設(shè)施檢查的要求，也沒有難懂的路由需求。

站在更高的視角上，我們一直在描述私有云架構(gòu)。以這種方式分散物理基礎(chǔ)設(shè)施使得與公有云的協(xié)同變得更加簡便。因此，混合云架構(gòu)越來越受歡迎，大家期待著公有云工作負(fù)載能像私有云工作負(fù)載那樣擁有相同的安全性和連通性。

隨著混合云架構(gòu)成為新的常態(tài)，最需要注意的是這些趨勢對網(wǎng)絡(luò)的影響。數(shù)據(jù)中心不再是簡單的實現(xiàn)某一IP與另一IP的通訊，當(dāng)遇到問題是使用路由和橋接表進行協(xié)調(diào)這么簡單。

基礎(chǔ)設(shè)施建設(shè)機制是借助復(fù)雜的網(wǎng)絡(luò)賦予現(xiàn)代中心的靈活性。驅(qū)動這種復(fù)雜性的是工作負(fù)載的分離、服務(wù)策略增強以及安全性等需求。因此，現(xiàn)代數(shù)據(jù)中心看起來更像是一份多層蛋糕，而并非只是IP地址的海洋。

在我們多層蛋糕的底端是服務(wù)承載網(wǎng)絡(luò)。這一網(wǎng)絡(luò)是所有其他網(wǎng)絡(luò)服務(wù)所需承載的基礎(chǔ)。這也是廣大網(wǎng)絡(luò)工程師最為熟悉的網(wǎng)絡(luò)。當(dāng)他們仔細(xì)檢查著自己的路由和橋接表，他們就會看到服務(wù)承載網(wǎng)絡(luò)，也是數(shù)據(jù)中心的基礎(chǔ)。

憑借服務(wù)承載網(wǎng)絡(luò)本身，并不能滿足混合云的所有需求。不斷增長的需求是分離，主要針對多租戶的情況。單一租戶可能是某一應(yīng)用程序，或者某一業(yè)務(wù)單元或某一客戶。

某一租戶的通信與其他租戶的通信是通過虛擬可擴展局域網(wǎng)隔離（Virtual Extensible LAN，VXLAN）封裝技術(shù)進行分離的。同一段通信是封裝在某一VXLAN包中，以封裝的形式在網(wǎng)絡(luò)中傳輸，并在到達傳輸目的地后解除封裝。VXLAN是一種二層覆蓋方式，它位于服務(wù)承載網(wǎng)絡(luò)的頂端。

它不僅提供分離的流量，VXLAN同時還可以用來在特定網(wǎng)絡(luò)間進行流量的路由規(guī)劃。讓我們來討論下，數(shù)據(jù)中心需要在特定的防火墻和負(fù)載均衡器間推送流量的問題吧。在現(xiàn)代網(wǎng)絡(luò)中，防火墻和負(fù)載平衡器很可能以虛擬網(wǎng)絡(luò)功能方式工作，可能集成在數(shù)據(jù)中心的任意地區(qū)。為了到達目的地而精確地規(guī)劃，VXLAN封裝還能夠用來打通設(shè)備與設(shè)備之間的通信流，直到聯(lián)通所有需要的設(shè)備。

防火墻規(guī)則在我們的覆蓋和底層蛋糕中形成另外一層。中央策略管理器為每一臺主機插入防火墻策略。每個主機都會有自己的一套策略來管理和轉(zhuǎn)發(fā)設(shè)備中的信息。這被稱為微分段，這是一種在規(guī)模化數(shù)據(jù)中心環(huán)境下能夠保證安全的可行辦法。

容器是增加網(wǎng)絡(luò)復(fù)雜性的又一通配符。容器網(wǎng)絡(luò)是一項新興的技術(shù)，由命名空間、代理服務(wù)器和網(wǎng)絡(luò)地址轉(zhuǎn)換所管理，使不同容器之間的通訊就像與外界一樣容易進行，即使對方并不在相同網(wǎng)絡(luò)層級上。

運維人員的麻煩

對于運行維護人員來說，伴隨著數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)而來的復(fù)雜性是一大潛在問題。大多數(shù)網(wǎng)絡(luò)問題都涉及到連通性或網(wǎng)絡(luò)性能。本應(yīng)該連通的兩個端點卻因為某種問題無法實現(xiàn)，或者兩個端點雖然是連通狀態(tài)，但訊通性能遠(yuǎn)不如預(yù)期則是另外一類問題。

用數(shù)據(jù)包走查方法(the packet walk method)來解決連接問題。從某臺網(wǎng)絡(luò)設(shè)備到另一臺網(wǎng)絡(luò)設(shè)備，按照數(shù)據(jù)包達到目的地的路徑實際發(fā)送數(shù)據(jù)。當(dāng)實際的IP端點已知時，這一方法將直抵關(guān)鍵。

在現(xiàn)代數(shù)據(jù)中心領(lǐng)域，底層網(wǎng)絡(luò)用來傳輸VXLAN或其他覆蓋包。最重要的是，我們追加防火墻的策略，也許網(wǎng)絡(luò)地址轉(zhuǎn)換或代理服務(wù)，數(shù)據(jù)包走查方法變得更加困難，并解決細(xì)節(jié)問題。要診斷一個連通性問題，運維人員需要知道的數(shù)據(jù)包的源頭和目的地，包括容器，虛擬機或裸金屬主機、防火墻的策略管理、數(shù)據(jù)包、數(shù)據(jù)包封裝以及所遵循的服務(wù)鏈條。

假設(shè)運維人員工作在某一扁平化的IT公司，并了解應(yīng)用程序數(shù)據(jù)流，可以很大程度上避免問題。然而，這并不容易。在橋接和路由表中查找媒體訪問控制和IP地址只是一個更為詳細(xì)的故障排除過程的某一小部分。再加上，現(xiàn)代基礎(chǔ)設(shè)施(中的工作流信息)往往是短暫的，運維人員可以解決過去發(fā)生的問題但卻無法重建。

性能的挑戰(zhàn)更加難以診斷。網(wǎng)絡(luò)設(shè)備的數(shù)量，接觸特定的會話可能涉及某一虛擬的操作系統(tǒng)、虛擬機管理程序的切換、虛擬防火墻、頂端機架交換機、主干交換機以及然后再反向排查通向另一端點的所有路徑。

當(dāng)某些工作負(fù)載位于公有云，事情會變得更加復(fù)雜。把基礎(chǔ)設(shè)施或平臺當(dāng)作某項服務(wù)等于意味著增加高延遲和額外的通信貫通追加到我們的故障排除方程中。

業(yè)界的回應(yīng)

我們被IP問題困住了。并且因為我們在IP被困住的同時需要額外的功能，我們停留在這里。覆蓋給我們引導(dǎo)和分離通信的能力，這一功能非常重要。有了它，我們可以把自己的基礎(chǔ)設(shè)施看作是只需要增加和降低容量的資源池。然后我們把它加入到環(huán)境中，成為我們解決網(wǎng)絡(luò)復(fù)雜性問題的辦法。

網(wǎng)絡(luò)業(yè)界已經(jīng)開始采取不同的方法來接受這一挑戰(zhàn)。首先是接受。如果我們認(rèn)同復(fù)雜性問題仍然存在，那么我們將提供工具，幫助我們能夠發(fā)現(xiàn)或可視化網(wǎng)絡(luò)上發(fā)生的問題。例如，思科在其應(yīng)用程序為中心基礎(chǔ)設(shè)施平臺上為運維人員提供解決端到端的連通性問題的增強性工具。VMware最近完成了對Arkin的收購，這一可視化工具可將相關(guān)工作負(fù)載對應(yīng)的防火墻策略和VXLAN分離，用圖形化界面(Graphic User Interface，GUI)搭配自然語言搜索引擎的方式進行展示。

越來越多有效的故障排除和可視化工具的出現(xiàn)，有效地支撐了現(xiàn)代數(shù)據(jù)中心平臺。然而，部分人士反對由創(chuàng)建轉(zhuǎn)發(fā)方案所帶來的復(fù)雜性，(他們認(rèn)為)如果有可能，應(yīng)盡力避免覆蓋的發(fā)生。

例如，在Romana.io開源項目依賴于一個分層的IP尋址方案，結(jié)合基于主機的防火墻規(guī)則來創(chuàng)建分割以及中心安全策略。開源Project Calico與Romana.io原理接近。Romana.io Project Calico項目都致力于提供轉(zhuǎn)發(fā)方案，面向大型數(shù)據(jù)中心同時還能兼顧處理安全和分離的需求，而在這一過程中他們不會進行覆蓋。

也許最大的問題并不是關(guān)于如何處理網(wǎng)絡(luò)的復(fù)雜性，而是關(guān)乎誰應(yīng)該如何支持解決方案。有一種想法認(rèn)為，自動化的應(yīng)用將降低人工成本。作為一名從業(yè)20年的IT基礎(chǔ)設(shè)施老司機，我并不同意這種看法。伴隨著巨大的復(fù)雜性而來的是更加迫切的技術(shù)支持需求。當(dāng)魔術(shù)不再有效時，公司并不想與他們的供應(yīng)商那樣暫時擱置問題。他們會希望有了解系統(tǒng)的專業(yè)人士能隨時準(zhǔn)備好解決發(fā)生的各類問題。