由于混合云和container（容器）技術(shù)的出現(xiàn)，數(shù)據(jù)中心網(wǎng)絡(luò)架構(gòu)比以往任何時候都更加難以被攻破。

當然，這個技術(shù)再好，還是有法可循，如果我們遵循一種簡單的方法，還是可以破解的。

在不太遠的過去，數(shù)據(jù)中心內(nèi)的流量轉(zhuǎn)發(fā)很簡單。 一個IP地址與另一個IP地址通話。 這些地址屬于端點 - 裸機主機或虛擬機與其他裸機主機或虛擬機通話。 這些IP地址之間的路徑是數(shù)據(jù)中心交換機已知的路由和橋接表中的條目。

如果工程師需要排除兩個IP端點之間性能不佳或奇怪的行為，一個好的起點就是通過查看這些表來構(gòu)建兩者之間的路徑。 同等成本的多路徑和多機架鏈路聚合增加了此過程的復雜性，但總的來說，運營商可以確定任何給定的數(shù)據(jù)中心會話遍歷的路徑。

在端點之間的通信流并沒有什么太復雜的。網(wǎng)絡(luò)地址轉(zhuǎn)換、加密或隧道傳播中很少出現(xiàn)。這些功能往往位于數(shù)據(jù)中心邊緣，與受信任外圍設(shè)備進行通信。

現(xiàn)代數(shù)據(jù)中心

隨著業(yè)務(wù)需求的變化，現(xiàn)代數(shù)據(jù)中心的網(wǎng)絡(luò)架構(gòu)已經(jīng)和以前的完全不一樣啦。曾經(jīng)相對簡單的數(shù)據(jù)中心，通訊簡單，現(xiàn)在的數(shù)據(jù)中心可以看做是一個統(tǒng)一基礎(chǔ)設(shè)施的平臺，在這個平臺上運行各種應用程序。數(shù)據(jù)中心作為一個整體運行；它是應用程序交付的引擎。

越來越多的基礎(chǔ)設(shè)施對開發(fā)人員和他們的應用程序是透明的。一個徹底的現(xiàn)代基礎(chǔ)設(shè)施是開發(fā)人員應用程序的抽象。資源池是按需分配的，而開發(fā)人員不必擔心基礎(chǔ)設(shè)施。相反，基礎(chǔ)設(shè)施是有效的。

現(xiàn)代數(shù)據(jù)中心還以一種分布式的方式處理安全問題，它與動態(tài)站立和拆除工作負載相協(xié)調(diào)。不再需要通過一個中央的物理防火墻來強制執(zhí)行安全策略。相反，構(gòu)建一個中央安全策略，一個安全管理器將該策略的相關(guān)部分安裝到受影響的主機、vm或container中。沒有基礎(chǔ)設(shè)施的選擇，也沒有晦澀的路由需求來強制執(zhí)行這樣的政策。

在更高的級別，我們在構(gòu)建私有云架構(gòu)。同錯采用這種抽象物理基礎(chǔ)結(jié)構(gòu)的方式，可以與公有云進行更簡單的協(xié)作。因此，混合云架構(gòu)越來越受歡迎，人們期望公共云工作負載與私有云工作負載具有相同的安全性和連接性。

層

隨著混合云架構(gòu)成為新的標準，重要的是要注意這些趨勢對網(wǎng)絡(luò)的影響。數(shù)據(jù)中心不再像一個IP地址那樣簡單地與另一個IP地址交談，在遇到麻煩時，需要通過路由和橋的聯(lián)絡(luò)，進行協(xié)商。

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

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

然而，底層本身并不能提供混合云所需的一切。一個日益增長的需求是隔離，被稱為多租戶。租戶可以是應用程序、業(yè)務(wù)單元或客戶。

租戶的流量通過虛擬可擴展LAN（VXLAN）封裝技術(shù)與其他流量隔離。來自一個段的流量被封裝在一個VXLAN包中，它通過這個包裝器在網(wǎng)絡(luò)中傳輸，并在另一端被斬首。VXLAN是另一層——覆蓋層——在我們的基礎(chǔ)底層之上。

它不僅提供了流量隔離，而且VXLAN還可以通過網(wǎng)絡(luò)中的特定路徑來路由流量。假設(shè)數(shù)據(jù)中心需要通過特定的防火墻和負載平衡器來進行傳輸。在現(xiàn)代網(wǎng)絡(luò)中，防火墻和負載平衡器很可能作為虛擬網(wǎng)絡(luò)功能存在，駐留在數(shù)據(jù)中心的任何位置。為了將流量送到它需要去的設(shè)備，VXLAN封裝可以用于隧道從設(shè)備到設(shè)備的通信流，直到它們遍歷所有需要的設(shè)備。

防火墻規(guī)則在我們的覆蓋層和底層蛋糕中形成另一層。一個中央策略管理器會在主機上插入防火墻規(guī)則。每個主機最終都有自己的一套規(guī)則，這些規(guī)則控制著設(shè)備的進出。這是一種用于確保可伸縮數(shù)據(jù)中心安全性的實用方法。

一個添加了更多網(wǎng)絡(luò)復雜性的通配符是container（容器技術(shù)）。container網(wǎng)絡(luò)是一種新興的技術(shù)，由名稱空間、代理服務(wù)器和網(wǎng)絡(luò)地址轉(zhuǎn)換管理，使container能夠相互通信，以及與外部工作連接——這是另一層。

在去年，Docker是最火爆的技術(shù)之一（不相信的人可以查一下google trends的引用量），Docker是什么呢？白話點說，就是一個Container的管理工具。那Container是什么呢，白話點說，就是一個更輕量級的虛擬機，但是這個虛擬機沒有操作系統(tǒng)和設(shè)備（操作系統(tǒng)可以共享的）。

一個沒有操作系統(tǒng)和設(shè)備的虛擬機怎么會如此火爆呢？不是因為container技術(shù)本身有多厲害，而是因為container技術(shù)目前解決了軟件行業(yè)的最大問題之一：應用的共享，配置管理和維護（還有應用的隔離，效率等等），不管是在物理機環(huán)境還是云環(huán)境。

通俗一點兒說，就是container技術(shù)，你無論在云環(huán)境，還是其它環(huán)境安裝一個SAP系統(tǒng)都和在app store上安裝一個微信差不多簡單。這個很吸引人吧。所以不管你是軟件開發(fā)公司，集成公司，服務(wù)公司，電商，還是云計算公司，都跑來跟風（包括google，亞馬遜，易貝，微軟，IBM……）。大公司里，不跟風的，也就剩HP等為數(shù)不多的公司。

那Container如何做到實現(xiàn)應用的部署和隔離呢？它把應用和應用關(guān)聯(lián)的lib庫都裝在container里面，這個container可以在某個操作系統(tǒng)上跑，而container內(nèi)的東西和container外的東西是隔離的。大家很快會想到，這不就是虛擬機嗎？Container和虛擬機看上去差不多，但是還是有些不同的。

和虛擬機相比，container不僅更輕量，而且配置簡化了很多（不用考慮操作系統(tǒng)和設(shè)備的配置）。這樣做有2個好處。

一個是寫應用的人不用管操作系統(tǒng)的事了（我只會寫Java，不懂Linux，沒關(guān)系，你把JAVA相關(guān)的配置搞好就好了），因為應用都在container里面。另一個好處是，你的container既可以部署在筆記本的操作系統(tǒng)上，也可以部署到云環(huán)境，只要操作系統(tǒng)一樣，其它區(qū)別都沒關(guān)系。并且不需要安裝，解壓等等（這個類似于虛擬機，但是虛擬機要考慮虛擬機容器的不同，而對于container，只要操作系統(tǒng)一樣就行了）。從配置管理來看，Container可以做增量的管理。

剛才是從應用共享和部署的角度看container技術(shù)。從更大的影響來講，container技術(shù)會影響我們整個軟件的開發(fā)和管理方式，我拿汽車做一個類比，我們過去的企業(yè)級軟件（或者叫復雜軟件），軟件生產(chǎn)的很多工作都是裝配和調(diào)試，由于IT系統(tǒng)配置相關(guān)的復雜性（和汽車相似，一大堆零部件），軟件的管理和維護也非常復雜，軟件的發(fā)布會牽涉到一大堆部門，軟件的開發(fā)，集成，和其它工具的集成，還有運維，測試等等。由于軟件本身是需要改進和升級的，在這種基于裝配和調(diào)試的生產(chǎn)方式下，軟件的管理和維護工作不僅復雜而且工作量大。而基于container和Docker技術(shù)，未來應用軟件的主要工作會轉(zhuǎn)變?yōu)檎麄�部件的替換，裝配工作在開發(fā)階段就一次完成了。管理工作的復雜性必然大大降低。軟件產(chǎn)品的工業(yè)化水平也會大大提高。

另一方面，站在程序員的角度，過去軟件的管理和共享，主要是在代碼層面，例如github，未來的管理和共享，是在應用層面，類似于google app store.程序員和最終用戶的距離會非常近。最終用戶也有可能自己搭建SAP這樣的系統(tǒng)，這種變化的影響會非常深遠。

另外，從效率的角度，container也可以更有效地利用機器資源，這對于云計算的服務(wù)商來說，是至關(guān)重要的。

運營商的困擾

現(xiàn)代數(shù)據(jù)中心網(wǎng)絡(luò)體系結(jié)構(gòu)的復雜性，對于運營商來說是一個潛在的問題。大多數(shù)網(wǎng)絡(luò)問題都與連接性能有關(guān)。兩個能夠連接的斷電，卻不能相互連接，是一類問題。還有就是，兩個端點能夠連接，但卻沒有像預期的那樣快速地進行連接，這又是問題。

可以通過檢索數(shù)據(jù)包的方法，查詢網(wǎng)絡(luò)的連通性，從而進行故障排除。從一個網(wǎng)絡(luò)設(shè)備到另一個網(wǎng)絡(luò)設(shè)備，跟蹤數(shù)據(jù)包到達目的地的路徑。當實際的IP端點已知時，查詢起來就相對簡單。

在現(xiàn)代數(shù)據(jù)中心，底層是用來傳輸VXLAN或其他覆蓋包的。除此之外，我們還添加了防火墻規(guī)則，然后可能是網(wǎng)絡(luò)地址轉(zhuǎn)換或代理服務(wù)；包走變得更加困難，充滿了細微的差別。要診斷連接問題，操作人員需要知道數(shù)據(jù)包的起點和終點——包括容器技術(shù)、虛擬機或裸機主機、管理數(shù)據(jù)包、封裝包以及要遵循的服務(wù)鏈的防火墻策略。

假設(shè)操作人員能夠理解應用程序流，并且在一個平面的、無豎井的IT組織中工作，看起來還不是那么糟糕，但也不容易。在橋接和路由表中查找媒體訪問控制和IP地址只是排除更復雜的故障過程中很小的一部分。 事實上，增加現(xiàn)代化的基礎(chǔ)設(shè)施的步伐永遠跟不上技術(shù)發(fā)展的步伐，運營商總在解決過去發(fā)生的問題，而過去發(fā)生的問題，恰恰很難改造。

性能挑戰(zhàn)更難診斷。 觸摸給定會話的網(wǎng)絡(luò)設(shè)備的數(shù)量可能涉及虛擬操作系統(tǒng)，虛擬機管理程序軟交換機，虛擬防火墻，機架頂交換機，脊柱交換機，然后一直到另一端點。

當一些工作負載在公共云中時，事情就變得更加復雜了。將基礎(chǔ)設(shè)施或平臺作為服務(wù)的一個服務(wù)，意味著為我們的故障排除方程添加高延遲和額外的隧道。

業(yè)界的反應是我們被IP所困。由于我們在同時需要額外的功能的同時又被困在IP里，所以覆蓋在這里。覆蓋層使我們能夠引導和隔離流量，這種功能是很重要的。有了它，我們就可以將我們的基礎(chǔ)設(shè)施看作是資源池，隨意地添加和減去容量。然后，這個問題就變成了管理我們在環(huán)境中添加的網(wǎng)絡(luò)復雜度的一個問題。

網(wǎng)絡(luò)行業(yè)已經(jīng)從幾個方面對這個挑戰(zhàn)進行了挑戰(zhàn)。第一個是接受。如果我們同意復雜性將繼續(xù)存在，那么我們將提供一些工具，讓我們能夠發(fā)現(xiàn)或可視化網(wǎng)絡(luò)上正在發(fā)生的事情。

例如，Cisco為操作人員提供了增強的工具，以解決其以應用程序為中心的基礎(chǔ)設(shè)施平臺上的端到端連接問題。VMware最近收購了Arkin，這是一種可視化工具，它將工作負載與防火墻策略和VXLAN分割相關(guān)聯(lián)，并與自然語言搜索引擎相結(jié)合。

在現(xiàn)代數(shù)據(jù)中心平臺中，有效的故障排除和可視化工具是越來越多的優(yōu)點。然而，一些人通過創(chuàng)建轉(zhuǎn)發(fā)方案來避免這種復雜性，如果可能的話，避免覆蓋。

例如，Romana.io開源項目依賴于分層IP尋址方案，結(jié)合基于主機的防火墻規(guī)則來創(chuàng)建分段和中央安全策略。 開源項目Calico是類似的。 Romana.io和Project Calico都非常有趣，因為它們提供了擴展到大數(shù)據(jù)中心的轉(zhuǎn)發(fā)方案，同時仍然處理安全性和分段要求，而且它們沒有覆蓋。

也許最大的問題不在于如何處理網(wǎng)絡(luò)復雜性，而是關(guān)于人們支持解決方案。 有一個想法，自動化將允許IT人員變薄。 作為一個20年IT基礎(chǔ)設(shè)施的老將，我看不到這樣的。 極大的復雜性需要很大的支持。 當魔術(shù)變得側(cè)面時，組織不會想要與供應商保持聯(lián)系。 他們會希望讓那些知道系統(tǒng)的專業(yè)人士準備好解決什么壞事。