由于混合云和container(容器)技術的出現,數據中心網絡架構比以往任何時候都更加難以被攻破。
當然,這個技術再好,還是有法可循,如果我們遵循一種簡單的方法,還是可以破解的。
在不太遠的過去,數據中心內的流量轉發很簡單。 一個IP地址與另一個IP地址通話。 這些地址屬于端點 - 裸機主機或虛擬機與其他裸機主機或虛擬機通話。 這些IP地址之間的路徑是數據中心交換機已知的路由和橋接表中的條目。
如果工程師需要排除兩個IP端點之間性能不佳或奇怪的行為,一個好的起點就是通過查看這些表來構建兩者之間的路徑。 同等成本的多路徑和多機架鏈路聚合增加了此過程的復雜性,但總的來說,運營商可以確定任何給定的數據中心會話遍歷的路徑。
在端點之間的通信流并沒有什么太復雜的。網絡地址轉換、加密或隧道傳播中很少出現。這些功能往往位于數據中心邊緣,與受信任外圍設備進行通信。
現代數據中心
隨著業務需求的變化,現代數據中心的網絡架構已經和以前的完全不一樣啦。曾經相對簡單的數據中心,通訊簡單,現在的數據中心可以看做是一個統一基礎設施的平臺,在這個平臺上運行各種應用程序。數據中心作為一個整體運行;它是應用程序交付的引擎。
越來越多的基礎設施對開發人員和他們的應用程序是透明的。一個徹底的現代基礎設施是開發人員應用程序的抽象。資源池是按需分配的,而開發人員不必擔心基礎設施。相反,基礎設施是有效的。
現代數據中心還以一種分布式的方式處理安全問題,它與動態站立和拆除工作負載相協調。不再需要通過一個中央的物理防火墻來強制執行安全策略。相反,構建一個中央安全策略,一個安全管理器將該策略的相關部分安裝到受影響的主機、vm或container中。沒有基礎設施的選擇,也沒有晦澀的路由需求來強制執行這樣的政策。
在更高的級別,我們在構建私有云架構。同錯采用這種抽象物理基礎結構的方式,可以與公有云進行更簡單的協作。因此,混合云架構越來越受歡迎,人們期望公共云工作負載與私有云工作負載具有相同的安全性和連接性。
層
隨著混合云架構成為新的標準,重要的是要注意這些趨勢對網絡的影響。數據中心不再像一個IP地址那樣簡單地與另一個IP地址交談,在遇到麻煩時,需要通過路由和橋的聯絡,進行協商。
提供現代數據中心靈活性的基礎設施機制依賴于復雜的網絡。推動這種復雜性的是工作負載隔離、服務策略實施和安全性的需要。因此,與其說數據中心是IP地址的海洋,倒不如更像是一塊有層次的蛋糕。
在這塊”有層次的蛋糕”底部是底層網絡。這個網絡是所有其他網絡服務的基礎。這也是網絡工程師最熟悉的網絡。當他們查看他們的路由和橋接表時,他們看到的是底層網絡——數據中心的基礎。
然而,底層本身并不能提供混合云所需的一切。一個日益增長的需求是隔離,被稱為多租戶。租戶可以是應用程序、業務單元或客戶。
租戶的流量通過虛擬可擴展LAN(VXLAN)封裝技術與其他流量隔離。來自一個段的流量被封裝在一個VXLAN包中,它通過這個包裝器在網絡中傳輸,并在另一端被斬首。VXLAN是另一層——覆蓋層——在我們的基礎底層之上。
它不僅提供了流量隔離,而且VXLAN還可以通過網絡中的特定路徑來路由流量。假設數據中心需要通過特定的防火墻和負載平衡器來進行傳輸。在現代網絡中,防火墻和負載平衡器很可能作為虛擬網絡功能存在,駐留在數據中心的任何位置。為了將流量送到它需要去的設備,VXLAN封裝可以用于隧道從設備到設備的通信流,直到它們遍歷所有需要的設備。
防火墻規則在我們的覆蓋層和底層蛋糕中形成另一層。一個中央策略管理器會在主機上插入防火墻規則。每個主機最終都有自己的一套規則,這些規則控制著設備的進出。這是一種用于確保可伸縮數據中心安全性的實用方法。
一個添加了更多網絡復雜性的通配符是container(容器技術)。container網絡是一種新興的技術,由名稱空間、代理服務器和網絡地址轉換管理,使container能夠相互通信,以及與外部工作連接——這是另一層。
在去年,Docker是最火爆的技術之一(不相信的人可以查一下google trends的引用量),Docker是什么呢?白話點說,就是一個Container的管理工具。那Container是什么呢,白話點說,就是一個更輕量級的虛擬機,但是這個虛擬機沒有操作系統和設備(操作系統可以共享的)。
一個沒有操作系統和設備的虛擬機怎么會如此火爆呢?不是因為container技術本身有多厲害,而是因為container技術目前解決了軟件行業的最大問題之一:應用的共享,配置管理和維護(還有應用的隔離,效率等等),不管是在物理機環境還是云環境。
通俗一點兒說,就是container技術,你無論在云環境,還是其它環境安裝一個SAP系統都和在app store上安裝一個微信差不多簡單。這個很吸引人吧。所以不管你是軟件開發公司,集成公司,服務公司,電商,還是云計算公司,都跑來跟風(包括google,亞馬遜,易貝,微軟,IBM。。。)。大公司里,不跟風的,也就剩HP等為數不多的公司。
那Container如何做到實現應用的部署和隔離呢?它把應用和應用關聯的lib庫都裝在container里面,這個container可以在某個操作系統上跑,而container內的東西和container外的東西是隔離的。大家很快會想到,這不就是虛擬機嗎?Container和虛擬機看上去差不多,但是還是有些不同的。
和虛擬機相比,container不僅更輕量,而且配置簡化了很多(不用考慮操作系統和設備的配置)。這樣做有2個好處。
一個是寫應用的人不用管操作系統的事了(我只會寫Java,不懂Linux,沒關系,你把JAVA相關的配置搞好就好了),因為應用都在container里面。另一個好處是,你的container既可以部署在筆記本的操作系統上,也可以部署到云環境,只要操作系統一樣,其它區別都沒關系。并且不需要安裝,解壓等等(這個類似于虛擬機,但是虛擬機要考慮虛擬機容器的不同,而對于container,只要操作系統一樣就行了)。從配置管理來看,Container可以做增量的管理。
剛才是從應用共享和部署的角度看container技術。從更大的影響來講,container技術會影響我們整個軟件的開發和管理方式,我拿汽車做一個類比,我們過去的企業級軟件(或者叫復雜軟件),軟件生產的很多工作都是裝配和調試,由于IT系統配置相關的復雜性(和汽車相似,一大堆零部件),軟件的管理和維護也非常復雜,軟件的發布會牽涉到一大堆部門,軟件的開發,集成,和其它工具的集成,還有運維,測試等等。由于軟件本身是需要改進和升級的,在這種基于裝配和調試的生產方式下,軟件的管理和維護工作不僅復雜而且工作量大。而基于container和Docker技術,未來應用軟件的主要工作會轉變為整個部件的替換,裝配工作在開發階段就一次完成了。管理工作的復雜性必然大大降低。軟件產品的工業化水平也會大大提高。
另一方面,站在程序員的角度,過去軟件的管理和共享,主要是在代碼層面,例如github,未來的管理和共享,是在應用層面,類似于google app store。程序員和最終用戶的距離會非常近。最終用戶也有可能自己搭建SAP這樣的系統,這種變化的影響會非常深遠。
另外,從效率的角度,container也可以更有效地利用機器資源,這對于云計算的服務商來說,是至關重要的。
運營商的困擾
現代數據中心網絡體系結構的復雜性,對于運營商來說是一個潛在的問題。大多數網絡問題都與連接性能有關。兩個能夠連接的斷電,卻不能相互連接,是一類問題。還有就是,兩個端點能夠連接,但卻沒有像預期的那樣快速地進行連接,這又是問題。
可以通過檢索數據包的方法,查詢網絡的連通性,從而進行故障排除。從一個網絡設備到另一個網絡設備,跟蹤數據包到達目的地的路徑。當實際的IP端點已知時,查詢起來就相對簡單。
在現代數據中心,底層是用來傳輸VXLAN或其他覆蓋包的。除此之外,我們還添加了防火墻規則,然后可能是網絡地址轉換或代理服務;包走變得更加困難,充滿了細微的差別。要診斷連接問題,操作人員需要知道數據包的起點和終點——包括容器技術、虛擬機或裸機主機、管理數據包、封裝包以及要遵循的服務鏈的防火墻策略。
假設操作人員能夠理解應用程序流,并且在一個平面的、無豎井的IT組織中工作,看起來還不是那么糟糕,但也不容易。在橋接和路由表中查找媒體訪問控制和IP地址只是排除更復雜的故障過程中很小的一部分。 事實上,增加現代化的基礎設施的步伐永遠跟不上技術發展的步伐,運營商總在解決過去發生的問題,而過去發生的問題,恰恰很難改造。
性能挑戰更難診斷。 觸摸給定會話的網絡設備的數量可能涉及虛擬操作系統,虛擬機管理程序軟交換機,虛擬防火墻,機架頂交換機,脊柱交換機,然后一直到另一端點。
當一些工作負載在公共云中時,事情就變得更加復雜了。將基礎設施或平臺作為服務的一個服務,意味著為我們的故障排除方程添加高延遲和額外的隧道。
業界的反應是我們被IP所困。由于我們在同時需要額外的功能的同時又被困在IP里,所以覆蓋在這里。覆蓋層使我們能夠引導和隔離流量,這種功能是很重要的。有了它,我們就可以將我們的基礎設施看作是資源池,隨意地添加和減去容量。然后,這個問題就變成了管理我們在環境中添加的網絡復雜度的一個問題。
網絡行業已經從幾個方面對這個挑戰進行了挑戰。第一個是接受。如果我們同意復雜性將繼續存在,那么我們將提供一些工具,讓我們能夠發現或可視化網絡上正在發生的事情。
例如,Cisco為操作人員提供了增強的工具,以解決其以應用程序為中心的基礎設施平臺上的端到端連接問題。VMware最近收購了Arkin,這是一種可視化工具,它將工作負載與防火墻策略和VXLAN分割相關聯,并與自然語言搜索引擎相結合。
在現代數據中心平臺中,有效的故障排除和可視化工具是越來越多的優點。然而,一些人通過創建轉發方案來避免這種復雜性,如果可能的話,避免覆蓋。
例如,Romana.io開源項目依賴于分層IP尋址方案,結合基于主機的防火墻規則來創建分段和中央安全策略。 開源項目Calico是類似的。 Romana.io和Project Calico都非常有趣,因為它們提供了擴展到大數據中心的轉發方案,同時仍然處理安全性和分段要求,而且它們沒有覆蓋。
也許最大的問題不在于如何處理網絡復雜性,而是關于人們支持解決方案。 有一個想法,自動化將允許IT人員變薄。 作為一個20年IT基礎設施的老將,我看不到這樣的。 極大的復雜性需要很大的支持。 當魔術變得側面時,組織不會想要與供應商保持聯系。 他們會希望讓那些知道系統的專業人士準備好解決什么壞事。