作者:錢譽
“我們找了差不多10個SDN技術,從商用的到開源的,再到國產小范圍應用的。”
“對比所有的Portal去看,不管是OpenStack還是原生的K8s,基本都是以運維視角出發(fā)的,不是一個對外提供業(yè)務的case。”
“K8s不是一個PaaS平臺,只是解決了一個docker管理的問題。”
“在云網絡環(huán)境里,可能一個租戶下面無數(shù)虛擬機,里面跑了無數(shù)不同的應用方式,所有流的走向又是亂七八糟的。”
“OpenShift雖然是有OVS,能不能和OpenStack互通是存疑的,最后驗證下來也是不能通的,完全是兩個體系。”
“進入CMP的時代,如果一個應用場景在15分鐘內開不起來的話,那它就失敗了,更不要說借助第三方外力。”
本文整理自上海數(shù)訊CIO錢譽在TF中文社區(qū)“2020第一次Meetup”上的演講,分享早期云網絡實際應用和二次開發(fā)過程中的經驗教訓。XXX作為合作方,經主辦方和演講者審閱授權發(fā)布。
在TF中文社區(qū)1月7日的“2020第一次Meetup”活動上,來自Tungsten Fabric技術研發(fā)和一線使用者、關注多云互聯(lián)的從業(yè)者、開源SDN的愛好者們互相切磋、支招,現(xiàn)場氣氛熱烈,精彩內容不斷。Tungsten Fabric在中國的廣泛應用正在越來越真切地走來。
本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領取。
上海數(shù)訊CIO錢譽
上海數(shù)訊是一家以傳統(tǒng)數(shù)據中心業(yè)務為主的公司,為什么會轉到云計算呢?在2011年以后,整個數(shù)據中心行業(yè)越來越像房地產了,數(shù)據中心這種業(yè)務可復制性比較強,競爭激烈。到2013年的時候,有一些新的技術出來,包括OpenStack的爆發(fā)式增長,于是2014年開始決定去做云計算這個事情。
當初的定義是多平臺,從實際應用場景來看的話,不是說虛擬機和容器哪個好,它們兩個應用在不同的場景,沒有誰替代誰的問題,要做兩個平臺的時候,又碰到一個很尷尬的問題,虛擬機的網絡和容器的網絡,完全是兩回事。
中間我們找了差不多10個SDN技術,從商用的到開源的,再到國產小范圍應用的,那個時候Tungsten Fabric還叫OpenContrail,當時的版本還只支持OpenStack。
CMP是這幾年提出來的,但剛開始做的時候,已經有CMP的理念了。
對比所有的Portal去看,不管是OpenStack還是原生的K8s,基本都是以運維視角出發(fā)的,不是一個對外提供業(yè)務的一個case。所以從使用者來看的話,是一件非常痛苦的事情,當時我們就決定把兩個平臺統(tǒng)一,在Web上做一個完整的、基于用戶自己界面的平臺。
在那個時候,確定了數(shù)訊云平臺和SDN的方向,當時主要是OpenStack和K8s。我們發(fā)現(xiàn)一個問題,K8s不是一個PaaS平臺,只是解決了一個docker管理的問題。如果是小環(huán)境的話,用不用都無所謂,不一定非要搞SDN,包括OpenStack也一樣,如果業(yè)務環(huán)境不是過于復雜的話,其實跑傳統(tǒng)的VLAN,只要控制量,沒有廣播風暴,沒有任何問題。
TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細演示操作過程,并解答關于Tungsten Fabric和K8s的一切問題。關注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”參與。
但如果你的業(yè)務場景非常復雜,以前收納在虛擬機,現(xiàn)在收納在容器里,這種業(yè)務的出現(xiàn),會對網絡造成非常大的困境,不可能對每個線的業(yè)務去做策略。一旦出現(xiàn)業(yè)務遷移或trouble shooting的時候,后端運維人員是崩潰的,沒法調。以前寫個PBR,寫個靜態(tài)路由,最多是掛幾個交換機路由。在云網絡環(huán)境里完全不是這樣,可能一個租戶下面無數(shù)虛擬機,里面跑了無數(shù)不同的應用方式,所有流的走向又是亂七八糟的,這種情況下,如果用傳統(tǒng)的方式,基本就不用做了,因為看不到頭。所以要采用SDN的方式。
Tungsten Fabric的確非常優(yōu)秀,但也有一些問題存在,完全支持OVSDB的交換機,對Tungsten Fabric的兼容會更好一點。也不是說Openflow不行,用流表的方式也能做,但那就比較折騰了。
數(shù)訊的底層Port,就是底層通過Tungsten Fabric的SDN技術支持線。當時2015年OpenContrail時代的時候,K8s剛開放,我們提出要采用基于容器的方式,因為虛擬機的方式對運維、擴容、遷移有弊端的話,后面業(yè)務是很難有保證的。那個時候OpenStack也比較早期,基本上都是自己統(tǒng)一部署,和Juniper networks聯(lián)合開發(fā)的時候,把OpenContrail放在一起部署。
另外,數(shù)訊作為數(shù)據中心運營商,提供的是傳統(tǒng)的hosting,大家都在考慮上云的問題。在云計算中我們已經使用了SDN技術,非傳統(tǒng)VLAN的方式,那么用戶上云的時候怎么接呢,不可能再開個VLAN做個什么映射,比較困難。
還有,怎么把用戶實際在機房里的一堆業(yè)務場景,跟云計算的overlay網絡去連接,而不是以某個獨立的服務去試。
這里就解決了VLAN映射的問題,不可能為用戶提供專線,還要改變他的VLAN網絡,這是不現(xiàn)實的,所以在這上面做了大量的二次開發(fā)。包括OpenStack和OpenShift,開源社區(qū)的版本都是單節(jié)點,到真正地應用到場景的話,最起碼要保證多節(jié)點,社區(qū)版的東西要落到生產環(huán)境,包括和Tungsten Fabric對接,還是有很多二次開發(fā)要做。
這是在開發(fā)和調研中碰到的實際用例的問題,有些是我們自己的,有些是用戶應用場景中的。
Neutron穩(wěn)定性比較差,我們曾經實測過,開到2500個虛擬機會出現(xiàn)莫名其妙的抖動,導致全部崩潰,對于原生的Neutron,我們還是比較謹慎的。
如果K8s只是實現(xiàn)單一業(yè)務,基本原生的Flannel或Calico都能解決,Calico對于多數(shù)據中心多任務的方式是不提供支持的,Calico是目前K8s開源環(huán)境使用最多的。
OpenShift雖然是有OVS,能不能和OpenStack互通是存疑的,最后驗證下來也是不能通的,完全是兩個體系。
另外VNF和CNF是否能夠共存,也是未知。為什么虛擬機要去訪問容器?在我們看來極其不合理,但在金融行業(yè)或電商行業(yè),某些業(yè)務可以跑虛擬機,某些已經買了商業(yè)軟件,或者有些用戶自己有開發(fā)能力,已經把一部分東西放到容器里了。
以前我們在虛擬機開一堆負載均衡,但在容器里直接一個Node無數(shù)port就解決了,包括很多注冊機機制不能portal,總不能把網絡做分段再做代理轉接,他們覺得非常難,看有沒有可能解決這個問題。我們最后試錯下來,在最近解決了VNF和CNF在OpenStack虛擬機層面的互通問題,要用到管理網去做互通。
虛擬機網絡與容器網絡二層互訪,在Tungsten Fabric 4.0版本的時候是基于標簽的方式,能用,但是用起來不方便。到現(xiàn)在5.1版本的時候,整個Portal也沒有把這個拉出來作為一個選項,每次都要去翻虛擬機和容器去做對應,這個操作比較麻煩,我們也試過做二次開發(fā),比較累。如果有可能的話,把這兩個東西放在一起,管理起來就會非常方便。
軟件定義的FW、LB如何在跨場景中業(yè)務落地?大部分用戶場景里,都是用商業(yè)軟件,各種品牌都有,自己本身提供image,放到虛擬機都有自己的feature,怎么和Tungsten Fabric互通,肯定是要做二次開發(fā)的,但目前看來也就Tungsten Fabric有可能去做,其它的比較困難。
VPC的問題,在我們的理解里,Tungsten Fabric的VPC可以理解為現(xiàn)在國內SDN web更合理,兩段VPN建立隧道。至于你要管到公有云的虛擬機,好像不太可能。即使是給到你,可能最后也會放棄,光是版本迭代問題就沒法解決。沒人做這樣的事情。好處是有Portal,能夠看到整個業(yè)務的實際情況。
吐槽一下,Tungsten Fabric確實解決了OpenStack網絡拓展和穩(wěn)定性問題,但對網卡有點挑,在一些特殊的應用場景里,比如跑VDI的IDP協(xié)議,我們發(fā)現(xiàn)Intel和Broadcom的網卡不那么友善。
相比OpenStack,目前為止Tungsten Fabric和OpenShift的對接難度更大一點。OpenShift開源的OKD本身就有一些問題,另外只是把Tungsten Fabric和OpenShift或K8s裝在一起,簡單應用看不出問題,但如果跑幾個業(yè)務鏈,比如標簽、應用、路由網關、業(yè)務編排等,整個流程走下去會有問題。
TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細演示操作過程,并解答關于Tungsten Fabric和K8s的一切問題。關注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”參與。
的確我們看下來,Tungsten Fabric就像文檔上面所說的,對OpenShift的支持,還是比其它開源軟件或商業(yè)軟件要好很多,至少還能看到用Tungsten Fabric做二次開發(fā)的曙光。
關于服務鏈,如果能夠和端口去做匹配,可能更好一點,不要干預整條網絡的屬性,在某些特定場景里面會比較復雜。
多云環(huán)境我們目前適配下來,只有AWS和Azure是可以的,不過還是根據實際的應用場景出發(fā),也沒必要把所有的公有云平臺對接一遍,業(yè)務也沒有那么復雜。
支持DPDK及smartNIC我們實測過,在OpenStack默認的kernel環(huán)境下,達到安全廠商他們的軟件標準,基本達不到,只有使用DPDK的方式才能達到標稱值,但DPDK又是Intel的專屬,在實際場景中碰到了一些問題,有的應用能跑起來,有的就不行。所以,要使用DPDK方式的話,還是要根據自己的使用場景去看一下。
Tungsten Fabric提供類似REST的API,所以即使自己要做CMP的話,去調用后端的參數(shù),相對還是比較容易的,但針對API的文檔有點亂。
到現(xiàn)在,我們做云計算是非常認真的,從2014年到現(xiàn)在一直在不斷打磨自己的平臺,所有的視角都是以用戶實例去呈現(xiàn),包括把Tungsten Fabric后端的API騰挪到前端,針對某個租戶他就能根據自己的策略去調。進入CMP的時代,如果一個應用場景在15分鐘內開不起來的話,那它就失敗了,更不要說借助第三方外力。把很多權限都開放給用戶。
我們的PaaS后端是OpenShift,基于PaaS平臺的所有業(yè)務都在前端重做,包括Tungsten Fabric針對OpenShift的功能,都放在前端,包括Tungsten Fabric內部都可以監(jiān)控,不用非常原始的SNMP的方式做采集,完全不需要。
目前為止,數(shù)訊的平臺做到了這個程度。選擇Tungsten Fabric是因為協(xié)議相對標準,BGP VPN就能解決,我比較抵觸私有協(xié)議,某些友商總想搞個大一統(tǒng),最后也不太可能,還是開放式大家比較能接受。
談到VXLAN的問題,實際用下來,如果用kernel方式,如果量很大損耗還是很大,特別針對VXLAN沒有做特別優(yōu)化的交換機或網卡,直接性能損失大概在30%左右。
從整個Tungsten Fabric去看的話,基本上把不同的平臺、不同的網絡特性都統(tǒng)一管理起來了,只是容器和虛擬機還是有一定手動的工作量,如果Tungsten Fabric把這個問題解決掉會更好。另外,Tungsten Fabric在OpenStack和OpenShift認證機制上不太一致。
這幾年比較痛苦的是支持比較少,不管開源社區(qū)還是官方,主要側重于安裝,有一部分trouble shooting,但針對于實際的應用場景部署相對比較缺失。做云計算不是開虛擬機,用不用OpenStack無所謂,KVM就解決了。所以說云計算不是虛擬化,它有一定的業(yè)務邏輯在里面,意味著平臺要能對實際落地用戶的業(yè)務提供很多支持。
我們應用Tungsten Fabric比較早,從3.2版本就開始搞,4.0版本正式對接。我相信如果有自己的業(yè)務邏輯,有一定的開發(fā)能力,基于Tungsten Fabric能打造出屬于自己的好的產品,Tungsten Fabric可編程型比較強,通用性也比較強。滿分100的話,我打80分,剩下的20分是支持方面。
以上,我從實際的應用場景,到開發(fā)當中遇到的各種情況,拋出了一些問題。
非常感謝大家!
本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”參與。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
