董文英:中國移動數據中心SDN產品研發(fā)探索
2017-08-22 17:51:35 來源:中國IDC圈 熱度:
我今天分享的主題是中國移動SDN研發(fā)探索和思考。中國移動從2015年提出了NovoNet下一代革新網絡,大家會很關注NovoNet究竟是什么,為什么是一個革新的網絡。NovoNet可以拆出兩個詞,一個是創(chuàng)新、一個是網絡。在創(chuàng)新方面,NovoNet提出了三個概念,新架構、新運營、新服務。我們可能在傳統(tǒng)的理念認為運營商更多是封閉性的,廠家提供資源和設備。但是現在互聯網的沖擊之后,越來越多的人發(fā)現傳統(tǒng)的模式有些low,我們需要新的變革來改變原來的這種網絡運營方式。新架構里面我們要改變原來都是硬件化的、固定化的網絡模式,要轉向軟件化、虛擬化、可編程的新結構。讓整個架構可以更靈活的、更快捷的去適應用戶的需求,提高用戶的體驗。在運營方面,我們會去側重于把控制做集中化,把調度做得更靈活,把資源的利用化更大化。服務上我們會推薦開放、敏捷。NovoNet的網絡層面我們會涉及到移動網絡、IP網絡、傳輸網絡、數據中心四個場景。
NovoNet的核心技術是SDN/NFV,NFV就是把傳統(tǒng)的硬件東西做軟件化、做虛擬化。SDN則側重于網絡的流量調度、流量的控制。NovoDC就是NovoNet里面的數據中心場景,我們整個的架構會分成四層,最上面是SDN的應用層,是面向于用戶的,然后中間有一個云操作系統(tǒng)層,就是云的數據中心平臺。再往下是SDN的控制層,就包含了控制器,還有廠商的VNFM,是用來控制NFV網元資源,最下層是傳統(tǒng)的轉發(fā)設備層,有硬件和軟件的,還有不同廠家的增值網元。整個架構里面除了我們這主要的四層,還有一些輔助模塊來幫助。
移動的NovoDC里面是面向用戶,我們不是單一的用戶,而是多租戶的場景。我們可以有更多的企業(yè)去共享網絡,每一個用戶在移動云網絡里面自己的網絡服務都是互相隔離的,不用擔心自己的網絡資源會被別人攻擊,或者被別人共享掉,或者有不應該有的方式。
中國移動其實還有一個變革,不僅僅在架構上,也在研發(fā)方式上。原來都是廠商提供完整的產品給運營商:運營商提供需求,廠商來實現?,F在我們更關注的是自己去實踐,當然這個實踐并不是說我們要搶奪廠商的市場,我們只是說希望以一種更開放的方式理解廠商的產品、廠商的架構,去接納廠商之間的合作方式,所以我們也建設了移動自己的SDN資源體系。SDN資源體系跟NovoNet的整體架構類似,也分成四個層次。最上面是應用層,移動有自己的SDN-O產品,中間是openstack,我們有自己的云平臺,在SDN控制層,移動有自己的SDN控制器的產品體系,而針對增值網元的網絡功能控制方面,更多的是依賴廠商的VNFM產品。最下面是轉發(fā)層,在移動自研的SDN產品體系,包括軟件和硬件,在NFV增值網元,我們更多會依賴于廠商的產品支撐。在座的廠商如果愿意跟移動合作,歡迎跟我們聯系。
SDN-O這層移動的產品叫SDN APP,特點是我們希望去提高用戶體驗,所以我們在設計這個SDN APP產品的時候,我們希望它更友好、更便捷,所以操作是采用圖形化、拖拉式的操作,而不是表單的方式,這是很大的變化。在SDN-O它的南向會跟移動的云平臺,會跟移動的SDN控制器,以及VNFM之間分別有接口,這些接口已經做了標準化的定義。SDN控制器這層,是整個DC里面的控制核心,移動的SDN控制器跟openstack有緊密的結合,主要管理云網絡里面二層和三層流量,另外,會在與增值網元的連通性方面做控制。SDN控制器在云平臺里提供了定制化的插件和驅動,用戶的請求達到openstack之后、經過這些插件和驅動會到達控制器,然后SDN控制器針對請求分析出控制指令通過南向的接口下發(fā)到轉發(fā)層資源,實現把具體的網絡配置下發(fā)到轉發(fā)設備。第三方網元的配合上面,我們是采用一種相對解耦的控制方式,增值網元自身的服務功能是由openstack里面的插件提供。但是數據中心里面二三層的流量是由控制器接管的,需要把流量正常的導向到所需要的提供服務的增值網元上。控制器在跟第三方增值網源之間有接口,這個接口的作用就是控制什么樣的流量該到哪一個用戶的哪一個增值網絡上。
移動的SDN控制器,目前是對資源的管理和控制,主要包括兩個方面:轉發(fā)設備的網絡配置,和增值網元的網絡互通性接口控制。目前SDN控制器在功能上實現二三層的轉發(fā),實現控制管理,還有安全控制,線速。在北向是標準的openstack的接口,跟SDN APP之間有標準的接口。南向目前支持的是openflow.這張圖是中國移動SDN控制器的架構圖,移動的SDN控制器是基于開源OpenDayLight平臺研發(fā)的,架構上會有很大的相似,但是我們最大的改進可能是在SAL層的處理。不知道在座有多少人對開源的SDN控制器有多少了解,這些平臺是在南向的插件這層實現了很多,在功能上我們覺得是相對完善的,但是在性能上還是有很大得空間,這是移動在做SDN產品的研發(fā)過程中面對的最大的挑戰(zhàn),因為畢竟移動要面對的網絡不是10臺或者20臺,或者幾十臺的小部署,我們要面對的是上百臺甚至上萬臺的產品。SDN控制器的性能方面,是否穩(wěn)定,高可靠性,這些都是我們要面對的挑戰(zhàn)。
中國移動的SDN控制器除了我們在使用基于這種開源平臺擴展之外,我們會定義很多的接口。這頁是SDN控制器跟第三方的增值網元之間的接口,我們目前支持的第三方增值網元包括網關設備,負載均衡,防火墻設備,我們定義的標準接口涵蓋SW、SDN網關、FW/NAT,負載均衡器等。這些接口已經跟一些廠家做了對接,在移動省公司也做了試點。除了增值網元的接口標準化之外,針對數據中心內的轉發(fā)設備我們也定義了標準的接口,其中,針對硬件交換機我們定義了標準的TTP模型,這組TTP模型要求硬件轉發(fā)設備支持OpenFlow的方式實現轉發(fā),這跟傳統(tǒng)的硬件設備是有差異的,傳統(tǒng)的交換設備的二、三層轉發(fā)功能是基于配置實現的,并且這些配置相對是固定的、少變化的,最好是一次配置、永遠不變。但是這種特點在SDN的場景下,是不滿足要求的,因為當SDN部署上之后用戶對你提出的要求和需求會變的更多,而且允許你響應的時間更短。這時候要面對的是經常性的變化,而且是精準性的變化,用戶需要控制的流量,不再是一個網段,很可能就是很詳細的一個特定的MAC、IP,甚至是源、目的端口。所以當這種需求被提出來的時候,openflow這種靈活控制協(xié)議的價值就會凸顯出來,我們也覺得它更適合控制性要求非常強的場景。所以移動的SDN里面在控制硬件交換機上,我們首先選擇的是在openflow上的嘗試,我們定義了標準的模型,我們會要求在硬件交換機支持openflow,要遵循這種移動定義好的pipeline.目前移動針對硬件交換機的TTP規(guī)范是以白皮書的形式對外公布。
除了SDN控制器以外,中國移動在SDN領域另外一個嘗試就是定制化交換機。移動的定制化交換機的方式是采用通用的硬件和定制化軟件開發(fā)相結合的方式,到目前已經經歷了三個版本,第一個版本還是傳統(tǒng)的二三層,第二個版本會增加上一個支持VTEP能力,第三個版本就是支持openflow.目前基于OpenFlow的定制化交換機已經內部發(fā)布了第一個版本,在實驗室已經跟SDN控制器進行了對接測試。目前我們已經能夠二三層已經互通,我們基于openflow去控制硬件交換機,然后來實現物理之間的流量打通,目前在移動內的SDN產品就實現了。
關于定制化交換機,移動定義的TTP白皮書也在ODCC里面推出了,如果大家有興趣可以下載。另外,如果大家對TTP或者硬件交換機感興趣,也可以聯系我們,我們可以做進一步合作探討和嘗試。關于TTP的測試,大家有興趣可以聽一下另外一位同事講的。
還有一個就是研發(fā)思考。因為我自己本身是做開發(fā)的,所以可能我更關注的是我們在SDN開發(fā)過程中面對的問題,和我們被提出的一些需求。首先就是說SDN控制器這個層面,SDN我們都知道控制和轉發(fā)分離了,在控制層面上我們會面對的挑戰(zhàn)有哪些。其實SDN控制器有很多的產品,有商業(yè)化也有開源的。SDN控制器每一家實現的方式不一樣,有人會推薦分布式控制的方式,認為SDN控制器不能集中,因為都集中到一起的話就是單點,當成為一個單點的話可擴展性就會受到限制。另外一種觀點,如果都分散的話,沒有一個集中控制的點就無法做統(tǒng)一的分析和調度,這可能是一個矛盾的問題。所以從開發(fā)的角度我更傾向于把集中式的控制跟分布控制做整合,我們會把一些比較抽象的東西放在集中式的控制平臺上做,但是當更關注細節(jié)的控制指令,比如說細分領域的控制產品,針對特定的轉發(fā)控制會放在分布式的子控制器上做,這樣會做一個平衡。
第二個挑戰(zhàn),網絡資源部署對SDN適配能力的挑戰(zhàn)。我不知道其他的公司會不會遇到,可能移動面對這個需求會更多一些,因為移動所面對的廠家太多了。移動不會被某個單一廠家綁定。當我們面對這么多廠家的時候,如何做統(tǒng)一的調度和控制。因為每個廠家不一樣,不可能做一個大而全的東西,這個東西把所有產品都涵蓋了,都囊括了,沒有任何一個廠家可以在這兒說能做到這一點。從運營商的角度上來說,我們需要去兼容所有的廠家,這個需求是我們繞不開的。但是每個廠家都是不同的,這個現實也是真實存在的。這時候我們怎么做?從移動的角度來說希望推動一個解耦的方案,我們希望各個廠家來配合移動做一個統(tǒng)一的接口,廠家可以保持自己的優(yōu)勢,自己可以在內部做性能上的改進,提供一些特色功能題。但是同時需要能夠跟其他廠家配合部署,需要跟控制器的廠家去配合調用,這個時候大家就需要一個統(tǒng)一的接口,所有人都適配這個接口。從控制層來說,用這個接口去面對所有不同的、現在已知的、和未來未知的一些廠家,從設備的層面上說,要提供這種接口來面對可能有的,或者已有的SDN控制器產品。所以我們希望云開放接口是業(yè)界一起參與進來的。
第三個是網絡資源虛擬化對SDN轉發(fā)效率的挑戰(zhàn)。我們知道很多的網絡轉發(fā)設備,或者說增值網元設備,其實都不是簡單拿傳統(tǒng)的方式就OK,很多人要做網卡驅動的改進和規(guī)劃,才能達到他真正想達到的效果。比如說防火墻設備,當我們在一個SDN場景下,我們希望網絡的轉發(fā)設備是更標準化的,最好X86的服務器就可以替代,但是NFV的應用廠家會說X86的設備的網卡不足以滿足我們的需求。所以移動會在SDN產品架構中,去做一套軟件的控制,跟硬件加速的結合。我們歡迎專注于網絡加速的解決方案的廠家參與進來,可以在轉發(fā)設備本身層面上提高轉發(fā)性和轉發(fā)能力,同時在控制層面上可以要有一種更靈活的SDN控制器。
第四個挑戰(zhàn)就是不同的應用挑戰(zhàn)對SDN控制器可擴展性的挑戰(zhàn),我們習慣的開發(fā)方式是先明確需求,但是當需求變化越來越快的時候,會發(fā)現原來的傳統(tǒng)的開發(fā)模式趕不上市場和用戶的要求。尤其在SDN的場景里,比方說僅僅是一個數據中心的場景,今天用戶可能告訴你這兩個是通的,明天可能就不通了。你說拿防火墻的控制,但是當有一天告訴你這個控制也不夠了,要增加一種流量,這時候怎么辦?我們覺得是這樣的,做SDN的話,尤其在控制器層我們要考慮有一個高性能、強可擴展性的平臺,同時提供的應用開發(fā)能力卻是更快捷的,我們希望當用戶提出一個需求的時候可以快速的響應,但是我響應它而開發(fā)出來一個功能,并不需要推翻原來開發(fā)的產品,而是可以在原來的產品上快速的迭代、快速的更新、快速的部署,這可能是我們更理想的一種SDN的,尤其是控制層面的應用開發(fā)場景。所以說我們希望SDN的控制器是更傾向于平臺化的發(fā)展,而不是說一個應用化的發(fā)展。
另外,移動的SDN里面不僅有數據中心的場景,還有傳輸網絡,每個場景里面對控制性的性能要求不一樣。比方說到傳輸網絡里,關注的更多的是時延性,響應的速度,網絡控制的快捷性。但是在數據中心里面,稍微晚幾百毫秒,感覺影響并沒有那么大。但是SDN更關注數據會不會丟,這兩個場景完全不一樣。歸結到一起,我們希望SDN平臺化和應用化都很重要,我們可以用統(tǒng)一的平臺,但是每一個場景可以通過應用來更好的適配。每個應用去適配,分別控制具體的場景,這可能是我覺得比較好的去滿足不同業(yè)務場景混雜模式下的挑戰(zhàn)。謝謝大家。
責任編輯:吳昊