<b>摘要：</b>從傳統it部署到雲，人肉運維已經是過去式，雲上運維該怎麼開展？人工智能對于運維“威脅論”也随之襲來，如何去做更智能的活，當下很多運維人在不斷思考和探尋答案。在2017雲栖社群運維/devops線上技術峰會上，阿裡雲專家雲登就為大家分享了雲計算網絡基礎架構的實踐和演進，精彩不容錯過。
<b>以下内容根據演講視訊以及ppt整理而成。</b>
衆所周知，雲計算是以計算、存儲和網絡作為基礎的。網絡作為雲計算的重要基石之一，其架構設計和演進是雲計算發展的重要一環，而網絡架構涉及可靠性、性能、可擴充性等多方面内容。架構是從理論設計開始的，理論設計和實踐碰撞到一起，能否經得住考驗，是否能夠符合預期呢？廠商所提供的網絡裝置的進階特性真的是解決問題的銀彈麼？如何通過經典網絡和vpc建構混合雲，打通雲上和雲下呢？阿裡雲在以往的實踐以及與使用者的互動碰撞中遇到的問題又是如何解決的呢？本次分享中将與大家一起進行探讨。
<b>本次分享的目錄</b>
一、常見的雲計算網絡架構
二、雲計算網絡的可靠性和故障定界
三、專有雲網絡的子產品化
四、混合雲建構的并網案例
五、雲網絡架構的演進趨勢
<b></b>
下圖所展示是一種常見的雲計算網絡叢集架構。傳統情況下雲計算網絡架構會分為三層：接入層、彙聚層和核心層。如下圖所示，在接入層下面的兩台交換機會進行堆疊，再下面會連接配接伺服器，伺服器一般會選擇使用兩個網卡進行bond之後以雙上連的方式連接配接到2台接入交換機。在接入交換機和彙聚交換機之間也會有多條線路的連接配接，一般而言會存在二層或者三層的接入。對于帶寬收斂比的設計而言，對于千兆叢集可以采用1:1無收斂的方式，而對于萬兆叢集則可以使用收斂比為1:3或者1:2的方案，也可能使用無收斂的設計。從彙聚層再向上連接配接到核心層，一般情況會使用三層連接配接。
下圖是另外一種比較常見的雲計算網絡叢集架構，在spine節點和leaf節點之間可能會存在三層連接配接，而spine節點和core節點之間也可能會存在三層連接配接，這種網絡架構相比于前面提到的架構而言，其擴充粒度要更細，可以細化到一組或者多組進行接入。
想必大家對于overlay以及underlay網絡都有所了解，實體網絡被稱為underlay網絡，實體網絡搭建完成之後應該盡量保證網絡拓撲是固定的；而對于overlay的網絡而言，可以基于vxlan技術建構vpc網絡，通過軟體定義和控制器的方式可以動态地建構虛拟的網絡。所建構的網絡可以是一個或多個虛拟的網絡，可以通過雲上不同的租戶去定義位址規劃以及路由的規劃，甚至還可以提供類似于高速通道這樣跨vpc之間的互通。underlay網絡的設計基本上就是前面所提到的接入-彙聚-核心架構以及spine-leaf架構，而對于overlay的網絡則描述的是虛拟的層面，提供的實際上是虛拟的路由器和虛拟的交換機，包括其建構出來的可以接入像slb、rds、ecs、ocs等雲産品的vpc容器。為什麼叫做overlay呢？其實因為overlay網絡是通過vxlan隧道的封裝運作在underlay實體網絡之上的。通過overlay邏輯網關去組織業務進行資源編排就可以建構出非常豐富的基于overlay網絡的産品。
前面主要介紹了雲計算網絡的一些基礎概念，接下來将會針對雲計算網絡的可靠性以及故障定位的方式進行分享。
對于雲計算平台的實體網絡而言，其可靠性可以分為以下的幾類：
<b>多線路，</b>常見二層的lacp，也就是鍊路聚合，對于三層則使用等價路由。
<b>裝置ha，</b>從體系結構來講，分布式的多框、多插槽的裝置能夠提供多主要、多接口闆這樣的方式，還可以提供類似于堆疊技術和多機之間的雙機熱備以及多機的備份或者多機堆疊的方式，還可以提供vrrp的鍊路切換。
<b>探測和切換機制，</b>實際上在網絡配置傳遞之後，如果遠端出現了問題，為了解決鍊路上的負載均衡以及主備切換的問題，可以引入比如nqa+track這樣的探測技術，這樣可以針對靜态路由的配置通過不同的優先級和nqa探測方式發現遠端節點不可達的時候進行路由切換。除此之外，在探索到某台裝置出現故障的時候就可以進行故障隔離，可以實作端口級或者裝置級的故障隔離，保證流量可以走備份或者備援鍊路進而避免流量中斷，當然，這種情況下可能對于流量帶寬造成一定的損失。
<b>巡檢和監測，</b>針對于overlay和underlay的網絡會提供主動探測的機制，還有對于裝置的日常日志告警的分析。裝置在運作中往往會報很多的日志和告警，将這些資訊收集起來之後結合雲平台的業務流量可以挖掘出很多故障的可能性、已經出現的故障還有對于未來可能出現故障的預判。還可以進行流量分析，并且基于此判斷雲平台的網絡是否出現了一些問題。
如下圖所示的是常見的網絡叢集故障點分布圖，雲計算平台的網絡故障點主要集中在下圖中标号的幾個位置：
<b>标号1：線路故障，</b>比如伺服器上連到tor交換機，也就是伺服器上的接入網卡接入到交換機上時出現了網卡、線路或者是接入端口損壞導緻線路上出現故障。同樣的，從接入層到彙聚層，從彙聚層到核心層也會出現這樣的線路故障。
<b>标号2：核心裝置的故障，</b>核心裝置的故障可能導緻跨網絡端口之間的流量損失，由此造成的影響範圍往往比較大。對圖中所示的網絡架構而言，如果流量需要跨端口進行傳輸，就一定需要從接入層到彙聚層再到核心層再轉入另外一個pod的彙聚層。
<b>标号3：彙聚交換機的故障，</b>一般情況下彙聚交換機采用堆疊的方式，可能會出現堆疊的分裂以及單台裝置的故障，也可能出現整個端口流量上行的帶寬減半或者是分裂以後導緻等一些不可預期的後果，是以需要及時檢測出一些故障并且及時進行隔離以及對于裝置進行下線維修進而排除此類故障。
<b>标号4：接入交換機的故障，</b>接入交換機也會發生類似于彙聚交換機的故障，堆疊分裂或者單機故障則會導緻下面連接配接的伺服器出現問題。
<b>标号5：伺服器故障。</b>
<b>标号6和7：像上述提到的堆疊出現問題造成的故障，</b>這樣的故障需要通過日常的巡檢以及網絡裝置自身報告故障的日志告警來發現問題并及時去進行相應的處理。
<b>以下是對于常見的網絡叢集故障點的較長的描述：</b>
<b>線路故障。</b>展現為帶寬的損失，一般通過多條線路保障，三層網絡裝置間通常用ecmp等價路由，二層網絡裝置間通常采用聚合lacp，提高可靠性。在實際情況下，在公有雲環境中會發現：一旦網絡叢集規模大了之後，堆疊出現問題的機率就會變大，與此同時，二層的廣播風暴和環路出現的機率也會變大，阿裡雲目前在逐漸地考慮去掉堆疊并且去掉二層，這也可能是未來的發展方向。這樣的目的是為了簡化網絡并提高網絡叢集的可靠性。
<b>dsw故障。</b>dsw是對于核心裝置的稱呼，由于所有的dsw之間不直接互聯，它本身的可靠性隻能依靠硬體框式分布式，多主要闆（主備ha）、多接口闆（上面說的多線路跨闆連接配接）來保證單點可靠性，使用多台dsw，平時負載均衡，單台故障時互為備份鍊路。如果是單台dsw故障，将會影響帶寬損失。
<b>psw故障。</b>也就是彙聚裝置的故障，拓撲中有psw堆疊和去堆疊兩種情況，如果是堆疊的，單台故障，上下連線依靠跨堆疊裝置的lacp或者ecmp實作業務不中斷（但帶寬有損失），如果不是堆疊的，參考（2）的場景。如果是單台psw故障，影響的是下連的多組asw帶寬損失一半。
<b>asw故障。</b>線上很多的asw都是堆疊的，目前阿裡雲也開始去堆疊，如果是堆疊的，asw下連伺服器，伺服器雙網卡bond接入（lacp），如果是去堆疊的asw，伺服器雙網卡等價路由負載均衡。如果單台asw故障，影響的是下連的48台伺服器的帶寬損失一半。未來，阿裡雲新建構的叢集會逐漸減少對于堆疊的使用，進而提高網絡裝置的可靠性。其實對于網絡廠商而言，他們也會對于堆疊特性進行大量的測試，但是實際上由于堆疊特性十分複雜，因為其涉及到硬體、軟體、内部檢測以及協定的傳輸備份，也就是會涉及到很多跨框、跨裝置的同步以及選舉機制。由于堆疊特性實作本身就非常複雜，就會導緻出現問題的可能性比像路由轉發這樣其他簡單特性更高。而在雲計算場景下海量的網絡裝置同時運作，就進一步提升了堆疊特性出現問題的可能性，基本上就會導緻出現存在堆疊的場景下可能經常會出現問題。為了解決這樣的問題就需要逐漸地去除堆疊和二層。
<b>伺服器故障。</b>可能展現在伺服器網卡或者本身内部的應用系統的問題，伺服器故障一般隻會影響自己，範圍比較小。
<b>psw堆疊分裂。</b>各自認為自己是主裝置，為了減小影響，一般會配置dad雙主檢測，禁掉一邊，影響為整個pod的上聯帶寬和跨asw之間轉發帶寬損失一半。如果psw堆疊整體故障，整個pod挂掉（各組asw下的48台伺服器之間仍可互通），上連不通，跨asw的互連不通。
<b>asw堆疊分裂。</b>類似于（6），影響為一組asw下挂的48台伺服器的互聯或者上聯帶寬損失一半。如果asw堆疊整體故障，該組asw下連的48台伺服器全部不通。對于（6）（7）的堆疊故障，由于廠商堆疊技術本身複雜，導緻故障機率提升，再加上公共雲使用的網絡裝置規模大，基數上去了就進一步放大出故障的機率，且影響範圍大。是以網絡本身的可靠性和故障位置，對于雲産品來說影響的範圍也是不同的，ecs之類的雲産品能夠打散到不同的asw、pod甚至az（跨網絡叢集），其可靠性名額也是不同的。基本上是打散的網絡裝置之間的層級越高，可靠性保證越高，但同樣的網絡延遲也越高。
那麼怎樣才能夠及早地發現這些故障呢？其實可以使用故障主動探測的模型。在網絡叢集裡面，可能會選擇特定的接入裝置比如像伺服器，将其作為主動探測的機器，其探測的目标就是網絡裝置下面的其他伺服器。
<b>建立的第一個簡單故障主動探測的模型如下：</b>
一個tor下面所有實體伺服器（例如48台）都同時出現大量丢包 --> tor交換機故障。
個别實體伺服器出現丢包 --> 伺服器負載問題/tor交換機端口隊列打滿。
到某個機房的大量實體伺服器同時出現大量丢包-->彙聚交換機/核心交換機故障。
到某個機房的大量實體伺服器出現少量機率丢包->彙聚交換機/核心交換機的個别端口問題。
每個機房最少隻需要1台機器作為探測源，部署對業務網絡影響小，icmp ping之類的隻能做layer3的探測。
依照上述的故障主動探測模型就可以簡單地判斷網絡出現故障的範圍。
<b>建立的第二個簡單故障主動探測的模型如下：</b>
通過選擇不同位置的伺服器作為探測源或者探測目标，發現不同層次的故障位置，多輪次組合。
要求每台伺服器運作agent，并接受外部控制器指令，動态調整探測政策，可建立tcp連接配接并測試。
可以針對overlay和underlay網絡進行探測，更容易模拟實際應用的業務流量特征，支援layer 4探測、時延計算。
第二個故障主動探測模型在伺服器内部會增加一些代理agent，安裝代理之後可以做到對于4到7層的探測，可以探測出tcp連接配接的情況以及其延遲和性能速率。同樣的，探測模型也可以組合出不同的探測方式，在了解網絡架構的拓撲之後就可以探測位于同一組接入交換機下面的兩台或者多台伺服器，也可以探測位于不同的核心交換機或者彙聚交換機下面的多台伺服器。通過這種模組化方式就可以知道目前延遲高或者丢包的場景下，網絡的問題到底出現在什麼位置。
<b>三、專有雲網絡的子產品化</b>
上述提到的是網絡展現在本身體系結構上的可靠性，比如分布式裝置、支援主備ha、支援雙機熱備或者多機堆疊以及其他一些進階特性，這些都是從網絡裝置本身的角度而言的。除此之外，通過線路帶寬的設計保證收斂比以及負載均衡，以此來保證雲計算網絡的可靠性。而通過日常的巡檢和探測能夠及時地發現故障，并在故障發生之後及時了解故障發生的具體原因并提供故障定位的方式，進而提高雲平台網絡的可靠性。
上述這些都是在公有雲網絡上的實踐，對于專有雲而言，又會存在什麼樣的差别呢？其實對于專有雲而言，更多地會對其進行子產品化的設計。公有雲一般而言是可規劃的，可以對于未來叢集的規模、建設的地域以及網絡架構的選擇等進行規劃。而對于專有雲而言，客戶的需求往往不能夠規劃出來，不同的客戶所需要的業務的場景和訴求往往是不同的，這些在網絡裝置的選型、已有裝置的利舊使用以及對于雲平台功能的裁剪上都會有所展現，是以專有雲與公有雲上的的網絡設計就存在較大的差别。
下圖是專有雲網絡架構圖，一個很明顯的特點就是專有雲網絡會分成幾個區域，最上面的是外部接入區，外部接入區包含了阿裡雲和isp或者使用者骨幹網出口的連結以及在其上進行安全防護的雲盾。專有雲網絡架構圖中間的dsw和下部的psw則屬于dc區，也就是網絡架構的核心區域。圖中右面的綜合接入區分為了兩個部分，一部分是阿裡雲所提供的負載均衡、vpc網關以及ops相關的接入，另外一部分則是csw，實際上就是客戶的vpc專線接入區，阿裡雲的專有雲客戶會有一些原來的實體網絡需要與雲上的vpc進行網絡打通，一般會通過vpc的專線接入交換機的綜合交換機接入進來。也就是說專有雲網絡的每一個子產品都有一個相對獨立的設計，所有的子產品實際上都是作為半獨立的部分，所謂半獨立就是意味着可以進行獨立的裁剪或者進行局部調整。專有雲網絡進行子產品化之後能夠帶來的好處就是可以進行随意地裁剪，比如很多專有雲客戶沒有連接配接網際網路的需求，隻需要一個完全的孤島環境，這樣就可以将外部接入區全部裁減掉。這樣做所帶來的優點就是首先簡化了不必要的功能，其次減少了裝置的采購，也就減少了使用者不必要的網絡成本。
<b>專有雲網絡架構其他方面的一些考慮與公有雲存在哪些差别呢？</b>
<b>（1）專有雲的網絡架構源于公有雲</b>
專有雲基于公有雲已驗證輸出的架構版本，進行裁剪和變更。既保證雲網絡架構是同構的，又引入靈活性和降低成本。
<b>（2）公有雲的建設是可規劃的，專有雲則是按項目走的</b>
公有雲的網絡架構一旦确定，建設就有了标準，在架構整個生命周期内建設都需要按照架構設計進行實作，而且完全可以提前規劃。專有雲更強調的是可以進行細粒度的調整，其可定制化要求會更高一些。專有雲的網絡架構确定後，每個項目的客戶需求不同，常常要求變更，最常見的是網絡裝置選型變更，網絡拓撲也常有變更，例如拉專線、利舊原有網絡裝置等的需求，對于這些情況大多是case by case進行解決。
<b>（3）公有雲的硬體和配置可定制化，專有雲的硬體和配置盡量通用化</b>
根據架構演進設計，公有雲啟用的硬體可定制，且規劃是一脈相承的。專有雲由于面對的是不同的客戶，需求不同，重口難調，架構設計往往需要考慮相容性，要能利舊，客戶常常要求将其已有的交換機資産用在雲網絡建設上。是以專有雲的網絡裝置往往要求需要通用化，便于不同使用者了解，降低使用者後期運維的複雜性和學習的成本。
（4）架構支援的伺服器規模
公有雲的網絡拓撲，一開始的考慮就是中、大規模的。專有雲的需求規模各項目不一緻，伺服器少的項目隻有幾十台，而伺服器多的項目又需要超過幾千台以上，是以專有雲的網絡架構設計需要考慮s/m/l等不同規模，甚至要劃分的更細粒度，以便兼顧雲平台的穩定性和客戶采購的硬體成本的均衡。
<b>四、混合雲建構的并網案例</b>
一般而言，客戶在建設專有雲之後，可能也會對于自己的租戶提供服務，或者自身也會存在部門的劃分，希望每個部門也有自己的專有網絡，并希望雲上的專有網絡能夠和原有的雲下實體網絡進行打通。
<b>案例1：傳統idc接入阿裡雲vpc</b>
下圖是一個常見的傳統idc接入阿裡雲并網的網絡拓撲。圖中左半部分是雲平台的網絡，圖上的示例劃分了三個vpc，每個vpc内部都包含了自己的雲産品，也會有自己的虛拟交換機和虛拟路由器。圖中右半部分表示的是客戶原有的網絡，這個網絡可能會基于業務或者基于部門進行劃分。那麼如何将使用者原有的網絡接入到雲上的網絡，實作将業務從雲下遷移到雲上呢？阿裡雲會提供vpc的專線接入方案幫助實作傳統idc與阿裡雲的并網接入。
<b>案例2：傳統idc接入阿裡雲vpc--單租戶多vpc</b>
下圖中展現的是單租戶多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的網絡打通。
<b>案例3：傳統idc接入阿裡雲vpc--多租戶</b>
下圖中展現的是另外一個例子：多租戶的傳統idc接入阿裡雲vpc的情況。這與公有雲的接入方式比較類似，上一個例子實際上是專有雲客戶内部網絡不同部門或者不同應用的劃分并通過vlan的方式接入，而下圖中例子則是專有雲客戶自己還有很多個租戶需要接入，這樣接入方式其實與公有雲比較相似，多個租戶可以通過三層的專線直接接入到vpc的接入點csw，後面的邏輯其實與上面的案例是一樣的，通過入端口确定vrf之後，在csw内部可以将流量引入到不同的vpc中去來實作雲下的網絡和雲上vpc網絡的打通。
上述的實作方式在專有雲的實踐中經常遇到使用者使用靜态位址進行接入的情況，是以會需要靜态路由配置，比如流量回包時會需要通過vpc到客戶網絡那一側進行靜态路由的指回。以下圖為例，配置靜态路由的csw是一個堆疊的裝置，如果遠端客戶的網絡出現了問題，比如光纖被挖斷或者出現了裝置故障問題，怎樣去實作流量的切換呢？其實需要使用nqa + track的方式，需要定義兩種具有不同優先級的路由，正常情況下會通過高優先級的路由傳回客戶的租戶網絡，當nqa探測到遠端的裝置不可達的時候則會通過track方式将路由切換到備用專線上來傳回給租戶的網絡，這樣就實作了遠端故障時的流量切換。當遠端網絡主鍊路恢複之後流量還可以重新切換回來。這樣就實作了雲上和雲下多鍊路vpc專線接入的情況下的靜态路由鍊路。
<b>五、雲網絡架構的演進趨勢</b>
未來，雲計算平台網絡架構演進的趨勢主要如下圖所示：
未來雲計算平台上的網絡會發生從經典網絡到vpc網絡進行切換；逐漸去除堆疊，從堆疊環境切換到獨立裝置，在一個比較大範圍的網絡使用場景裡面減少堆疊帶來的故障，整體提高雲平台網絡的可靠性；在underlay實體網絡中逐漸去掉二層，因為二層經常會出現廣播風暴或者環路問題，去掉二層則可以提高網絡的可靠性；對于端口而言，會從原來的支援千兆和萬兆逐漸過渡到支援25g和100g；對于實體網絡的複雜度而言，會逐漸降低對于實體網絡的依賴，逐漸将其複雜度下沉到伺服器端，無論是vpc網關還是普通雲産品的宿主伺服器，都會将其對網絡的依賴進行逐漸解耦，盡量減少因為網絡故障給雲平台帶來的不穩定。