550
雲計算網絡基礎架構的實踐和演進——打造雲計算網絡基石
摘要：從傳統IT部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？人工智能對於運維“威脅論”也隨之襲來，如何去做更智能的活，當下很多運維人在不斷思考和探尋答案。在2017雲棲社區運維/DevOps在線技術峰會上，阿裏雲專家雲登就為大家分享了雲計算網絡基礎架構的實踐和演進，精彩不容錯過。以下內容根據演講視頻以及PPT整理而成。
眾所周知，雲計算是以計算、存儲和網絡作為基礎的。網絡作為雲計算的重要基石之一，其架構設計和演進是雲計算發展的重要一環，而網絡架構涉及可靠性、性能、可擴展性等多方麵內容。架構是從理論設計開始的，理論設計和實踐碰撞到一起，能否經得住考驗，是否能夠符合預期呢？廠商所提供的網絡設備的高級特性真的是解決問題的銀彈麼？如何通過經典網絡和VPC構建混合雲，打通雲上和雲下呢？阿裏雲在以往的實踐以及與用戶的交互碰撞中遇到的問題又是如何解決的呢？本次分享中將與大家一起進行探討。
本次分享的目錄
一、常見的雲計算網絡架構
二、雲計算網絡的可靠性和故障定界
三、專有雲網絡的模塊化
四、混合雲構建的並網案例
五、雲網絡架構的演進趨勢
一、常見的雲計算網絡架構
下圖所展示是一種常見的雲計算網絡集群架構。傳統情況下雲計算網絡架構會分為三層：接入層、匯聚層和核心層。如下圖所示，在接入層下麵的兩台交換機會進行堆疊，再下麵會連接服務器，服務器一般會選擇使用兩個網卡進行bond之後以雙上連的方式連接到2台接入交換機。在接入交換機和匯聚交換機之間也會有多條線路的連接，一般而言會存在二層或者三層的接入。對於帶寬收斂比的設計而言，對於千兆集群可以采用1:1無收斂的方式，而對於萬兆集群則可以使用收斂比為1:3或者1:2的方案，也可能使用無收斂的設計。從匯聚層再向上連接到核心層，一般情況會使用三層連接。
二、雲計算網絡的可靠性和故障定界
前麵主要介紹了雲計算網絡的一些基礎概念，接下來將會針對雲計算網絡的可靠性以及故障定位的方式進行分享。
對於雲計算平台的物理網絡而言，其可靠性可以分為以下的幾類：
- 多線路，常見二層的LACP，也就是鏈路聚合，對於三層則使用等價路由。
- 設備HA，從體係結構來講，分布式的多框、多插槽的設備能夠提供多主控、多接口板這樣的方式，還可以提供類似於堆疊技術和多機之間的雙機熱備以及多機的備份或者多機堆疊的方式，還可以提供VRRP的鏈路切換。
- 探測和切換機製，實際上在網絡配置交付之後，如果遠端出現了問題，為了解決鏈路上的負載均衡以及主備切換的問題，可以引入比如NQA+Track這樣的探測技術，這樣可以針對靜態路由的配置通過不同的優先級和NQA探測方式發現遠端節點不可達的時候進行路由切換。除此之外，在探索到某台設備出現故障的時候就可以進行故障隔離，可以實現端口級或者設備級的故障隔離，保證流量可以走備份或者冗餘鏈路進而避免流量中斷，當然，這種情況下可能對於流量帶寬造成一定的損失。
- 巡檢和監測，針對於Overlay和Underlay的網絡會提供主動探測的機製，還有對於設備的日常日誌告警的分析。設備在運行中往往會報很多的日誌和告警，將這些信息收集起來之後結合雲平台的業務流量可以挖掘出很多故障的可能性、已經出現的故障還有對於未來可能出現故障的預判。還可以進行流量分析，並且基於此判斷雲平台的網絡是否出現了一些問題。
- 標號1：線路故障，比如服務器上連到TOR交換機，也就是服務器上的接入網卡接入到交換機上時出現了網卡、線路或者是接入端口損壞導致線路上出現故障。同樣的，從接入層到匯聚層，從匯聚層到核心層也會出現這樣的線路故障。
- 標號2：核心設備的故障，核心設備的故障可能導致跨網絡端口之間的流量損失，由此造成的影響範圍往往比較大。對圖中所示的網絡架構而言，如果流量需要跨端口進行傳輸，就一定需要從接入層到匯聚層再到核心層再轉入另外一個POD的匯聚層。
- 標號3：匯聚交換機的故障，一般情況下匯聚交換機采用堆疊的方式，可能會出現堆疊的分裂以及單台設備的故障，也可能出現整個端口流量上行的帶寬減半或者是分裂以後導致等一些不可預期的後果，因此需要及時檢測出一些故障並且及時進行隔離以及對於設備進行下線維修從而排除此類故障。
- 標號4：接入交換機的故障，接入交換機也會發生類似於匯聚交換機的故障，堆疊分裂或者單機故障則會導致下麵連接的服務器出現問題。
- 標號5：服務器故障。
- 標號6和7：像上述提到的堆疊出現問題造成的故障，這樣的故障需要通過日常的巡檢以及網絡設備自身報告故障的日誌告警來發現問題並及時去進行相應的處理。
- 線路故障。體現為帶寬的損失，一般通過多條線路保障，三層網絡設備間通常用ECMP等價路由，二層網絡設備間通常采用聚合LACP，提高可靠性。在實際情況下，在公有雲環境中會發現：一旦網絡集群規模大了之後，堆疊出現問題的概率就會變大，與此同時，二層的廣播風暴和環路出現的概率也會變大，阿裏雲目前在逐步地考慮去掉堆疊並且去掉二層，這也可能是未來的發展方向。這樣的目的是為了簡化網絡並提高網絡集群的可靠性。
- DSW故障。DSW是對於核心設備的稱唿，由於所有的DSW之間不直接互聯，它本身的可靠性隻能依靠硬件框式分布式，多主控板（主備HA）、多接口板（上麵說的多線路跨板連接）來保證單點可靠性，使用多台DSW，平時負載均衡，單台故障時互為備份鏈路。如果是單台DSW故障，將會影響帶寬損失。
- PSW故障。也就是匯聚設備的故障，拓撲中有PSW堆疊和去堆疊兩種情況，如果是堆疊的，單台故障，上下連線依靠跨堆疊設備的LACP或者ECMP實現業務不中斷（但帶寬有損失），如果不是堆疊的，參考（2）的場景。如果是單台PSW故障，影響的是下連的多組ASW帶寬損失一半。
- ASW故障。線上很多的ASW都是堆疊的，目前阿裏雲也開始去堆疊，如果是堆疊的，ASW下連服務器，服務器雙網卡bond接入（LACP），如果是去堆疊的ASW，服務器雙網卡等價路由負載均衡。如果單台ASW故障，影響的是下連的48台服務器的帶寬損失一半。未來，阿裏雲新構建的集群會逐漸減少對於堆疊的使用，進而提高網絡設備的可靠性。其實對於網絡廠商而言，他們也會對於堆疊特性進行大量的測試，但是實際上由於堆疊特性十分複雜，因為其涉及到硬件、軟件、內部檢測以及協議的傳輸備份，也就是會涉及到很多跨框、跨設備的同步以及選舉機製。由於堆疊特性實現本身就非常複雜，就會導致出現問題的可能性比像路由轉發這樣其他簡單特性更高。而在雲計算場景下海量的網絡設備同時運行，就進一步提升了堆疊特性出現問題的可能性，基本上就會導致出現存在堆疊的場景下可能經常會出現問題。為了解決這樣的問題就需要逐步地去除堆疊和二層。
- 服務器故障。可能體現在服務器網卡或者本身內部的應用係統的問題，服務器故障一般隻會影響自己，範圍比較小。
- PSW堆疊分裂。各自認為自己是主設備，為了減小影響，一般會配置DAD雙主檢測，禁掉一邊，影響為整個pod的上聯帶寬和跨asw之間轉發帶寬損失一半。如果PSW堆疊整體故障，整個pod掛掉（各組ASW下的48台服務器之間仍可互通），上連不通，跨asw的互連不通。
- ASW堆疊分裂。類似於（6），影響為一組ASW下掛的48台服務器的互聯或者上聯帶寬損失一半。如果ASW堆疊整體故障，該組ASW下連的48台服務器全部不通。對於（6）（7）的堆疊故障，由於廠商堆疊技術本身複雜，導致故障概率提升，再加上公共雲使用的網絡設備規模大，基數上去了就進一步放大出故障的概率，且影響範圍大。因此網絡本身的可靠性和故障位置，對於雲產品來說影響的範圍也是不同的，ecs之類的雲產品能夠打散到不同的ASW、POD甚至AZ（跨網絡集群），其可靠性指標也是不同的。基本上是打散的網絡設備之間的層級越高，可靠性保證越高，但同樣的網絡延遲也越高。
建立的第一個簡單故障主動探測的模型如下：
- 一個TOR下麵所有物理服務器（例如48台）都同時出現大量丟包 --> TOR交換機故障。
- 個別物理服務器出現丟包 --> 服務器負載問題/TOR交換機端口隊列打滿。
- 到某個機房的大量物理服務器同時出現大量丟包-->匯聚交換機/核心交換機故障。
- 到某個機房的大量物理服務器出現少量概率丟包->匯聚交換機/核心交換機的個別端口問題。
- 每個機房最少隻需要1台機器作為探測源，部署對業務網絡影響小，ICMP ping之類的隻能做Layer3的探測。
建立的第二個簡單故障主動探測的模型如下：
- 通過選擇不同位置的服務器作為探測源或者探測目標，發現不同層次的故障位置，多輪次組合。
- 要求每台服務器運行agent，並接受外部控製器指令，動態調整探測策略，可建立TCP連接並測試。
- 可以針對overlay和underlay網絡進行探測，更容易模擬實際應用的業務流量特征，支持Layer 4探測、時延計算。
三、專有雲網絡的模塊化
上述提到的是網絡體現在本身體係結構上的可靠性，比如分布式設備、支持主備HA、支持雙機熱備或者多機堆疊以及其他一些高級特性，這些都是從網絡設備本身的角度而言的。除此之外，通過線路帶寬的設計保證收斂比以及負載均衡，以此來保證雲計算網絡的可靠性。而通過日常的巡檢和探測能夠及時地發現故障，並在故障發生之後及時了解故障發生的具體原因並提供故障定位的方式，進而提高雲平台網絡的可靠性。
上述這些都是在公有雲網絡上的實踐，對於專有雲而言，又會存在什麼樣的差別呢？其實對於專有雲而言，更多地會對其進行模塊化的設計。公有雲一般而言是可規劃的，可以對於未來集群的規模、建設的地域以及網絡架構的選擇等進行規劃。而對於專有雲而言，客戶的需求往往不能夠規劃出來，不同的客戶所需要的業務的場景和訴求往往是不同的，這些在網絡設備的選型、已有設備的利舊使用以及對於雲平台功能的裁剪上都會有所體現，所以專有雲與公有雲上的的網絡設計就存在較大的差別。
下圖是專有雲網絡架構圖，一個很明顯的特點就是專有雲網絡會分成幾個區域，最上麵的是外部接入區，外部接入區包含了阿裏雲和ISP或者用戶骨幹網出口的鏈接以及在其上進行安全防護的雲盾。專有雲網絡架構圖中間的DSW和下部的PSW則屬於DC區，也就是網絡架構的核心區域。圖中右麵的綜合接入區分為了兩個部分，一部分是阿裏雲所提供的負載均衡、VPC網關以及OPS相關的接入，另外一部分則是CSW，實際上就是客戶的VPC專線接入區，阿裏雲的專有雲客戶會有一些原來的物理網絡需要與雲上的VPC進行網絡打通，一般會通過VPC的專線接入交換機的綜合交換機接入進來。也就是說專有雲網絡的每一個模塊都有一個相對獨立的設計，所有的模塊實際上都是作為半獨立的部分，所謂半獨立就是意味著可以進行獨立的裁剪或者進行局部調整。專有雲網絡進行模塊化之後能夠帶來的好處就是可以進行隨意地裁剪，比如很多專有雲客戶沒有連接互聯網的需求，隻需要一個完全的孤島環境，這樣就可以將外部接入區全部裁減掉。這樣做所帶來的優點就是首先簡化了不必要的功能，其次減少了設備的采購，也就減少了用戶不必要的網絡成本。
專有雲網絡架構其他方麵的一些考慮與公有雲存在哪些差別呢？
（1）專有雲的網絡架構源於公有雲
專有雲基於公有雲已驗證輸出的架構版本，進行裁剪和變更。既保證雲網絡架構是同構的，又引入靈活性和降低成本。
（2）公有雲的建設是可規劃的，專有雲則是按項目走的
公有雲的網絡架構一旦確定，建設就有了標準，在架構整個生命周期內建設都需要按照架構設計進行實現，而且完全可以提前規劃。專有雲更強調的是可以進行細粒度的調整，其可定製化要求會更高一些。專有雲的網絡架構確定後，每個項目的客戶需求不同，常常要求變更，最常見的是網絡設備選型變更，網絡拓撲也常有變更，例如拉專線、利舊原有網絡設備等的需求，對於這些情況大多是case by case進行解決。
（3）公有雲的硬件和配置可定製化，專有雲的硬件和配置盡量通用化
根據架構演進設計，公有雲啟用的硬件可定製，且規劃是一脈相承的。專有雲由於麵對的是不同的客戶，需求不同，重口難調，架構設計往往需要考慮兼容性，要能利舊，客戶常常要求將其已有的交換機資產用在雲網絡建設上。所以專有雲的網絡設備往往要求需要通用化，便於不同用戶理解，降低用戶後期運維的複雜性和學習的成本。
（4）架構支持的服務器規模
公有雲的網絡拓撲，一開始的考慮就是中、大規模的。專有雲的需求規模各項目不一致，服務器少的項目隻有幾十台，而服務器多的項目又需要超過幾千台以上，因此專有雲的網絡架構設計需要考慮S/M/L等不同規模，甚至要劃分的更細粒度，以便兼顧雲平台的穩定性和客戶采購的硬件成本的均衡。
四、混合雲構建的並網案例
一般而言，客戶在建設專有雲之後，可能也會對於自己的租戶提供服務，或者自身也會存在部門的劃分，希望每個部門也有自己的專有網絡，並希望雲上的專有網絡能夠和原有的雲下物理網絡進行打通。
案例1：傳統IDC接入阿裏雲VPC
下圖是一個常見的傳統IDC接入阿裏雲並網的網絡拓撲。圖中左半部分是雲平台的網絡，圖上的示例劃分了三個VPC，每個VPC內部都包含了自己的雲產品，也會有自己的虛擬交換機和虛擬路由器。圖中右半部分表示的是客戶原有的網絡，這個網絡可能會基於業務或者基於部門進行劃分。那麼如何將用戶原有的網絡接入到雲上的網絡，實現將業務從雲下遷移到雲上呢？阿裏雲會提供VPC的專線接入方案幫助實現傳統IDC與阿裏雲的並網接入。
案例2：傳統IDC接入阿裏雲VPC--單租戶多VPC
下圖中展現的是單租戶多VPC的網絡拓撲。圖中左半部分是傳統IDC的網絡區，客戶原來可能是通過VLAN劃分不同部門之間的網絡的，那麼如何接入到阿裏雲的VPC呢？如圖中右半部分所示的其實是一個專線接入設備CSW，可以看到左側的網絡一般而言可以根據VLAN的劃分設計出接入的方式。如圖中所示以VLAN劃分為X、Y、Z三個部門的網絡，右邊在阿裏雲網絡區中也會相應地劃分出三個VLAN IF接口，這三個VLAN IF接口會對應地接收客戶這邊的三部分的報文。客戶IDC中的三個VLAN的報文通過Trunk口上行到CSW上以後，因為VPC網絡可以進行VPC內的路由和地址規劃，因此在CSW交換機上可以劃分三個VRF，每個VRF會根據入端口去確定後麵的路由轉發，比如VLAN X的報文通過Trunk口接收上來之後會終結到三層口VLAN IF X上。VRF一般都是通過入端口進行確定的，因此自然就會在VRF A中進行路由，這樣就可以設計從傳統IDC網絡到VPC上的路由以及從VPC到傳統網絡的回包路由。當報文通過VRF A路由到出接口的時候，VSI會進行虛擬的交換將當前的流量對應到某一個VXLAN Tunnel上去進行封裝和轉發，這樣報文就會通過綜合接入交換機LSW轉發到VPC的XGW網關，之後XGW網關根據VXLAN的ID確定當前的流量需要引入到哪一個VPC中去，這樣就實現了雲下的傳統IDC客戶網絡和雲上的租戶的VPC的網絡打通。
下圖中展現的是另外一個例子：多租戶的傳統IDC接入阿裏雲VPC的情況。這與公有雲的接入方式比較類似，上一個例子實際上是專有雲客戶內部網絡不同部門或者不同應用的劃分並通過VLAN的方式接入，而下圖中例子則是專有雲客戶自己還有很多個租戶需要接入，這樣接入方式其實與公有雲比較相似，多個租戶可以通過三層的專線直接接入到VPC的接入點CSW，後麵的邏輯其實與上麵的案例是一樣的，通過入端口確定VRF之後，在CSW內部可以將流量引入到不同的VPC中去來實現雲下的網絡和雲上VPC網絡的打通。
上述的實現方式在專有雲的實踐中經常遇到用戶使用靜態地址進行接入的情況，因此會需要靜態路由配置，比如流量回包時會需要通過VPC到客戶網絡那一側進行靜態路由的指回。以下圖為例，配置靜態路由的CSW是一個堆疊的設備，如果遠端客戶的網絡出現了問題，比如光纖被挖斷或者出現了設備故障問題，怎樣去實現流量的切換呢？其實需要使用NQA + Track的方式，需要定義兩種具有不同優先級的路由，正常情況下會通過高優先級的路由傳回客戶的租戶網絡，當NQA探測到遠端的設備不可達的時候則會通過Track方式將路由切換到備用專線上來傳回給租戶的網絡，這樣就實現了遠端故障時的流量切換。當遠端網絡主鏈路恢複之後流量還可以重新切換回來。這樣就實現了雲上和雲下多鏈路VPC專線接入的情況下的靜態路由鏈路。
五、雲網絡架構的演進趨勢
未來，雲計算平台網絡架構演進的趨勢主要如下圖所示：
最後更新：2017-04-24 22:00:51