Tungsten Fabric：連接CMP的金鑰匙

作者:錢譽(yù)

“我們找了差不多10個(gè)SDN技術(shù),從商用的到開源的,再到國產(chǎn)小范圍應(yīng)用的。”

“對比所有的Portal去看,不管是OpenStack還是原生的K8s,基本都是以運(yùn)維視角出發(fā)的,不是一個(gè)對外提供業(yè)務(wù)的case。”

“K8s不是一個(gè)PaaS平臺(tái),只是解決了一個(gè)docker管理的問題。”

“在云網(wǎng)絡(luò)環(huán)境里,可能一個(gè)租戶下面無數(shù)虛擬機(jī),里面跑了無數(shù)不同的應(yīng)用方式,所有流的走向又是亂七八糟的。”

“OpenShift雖然是有OVS,能不能和OpenStack互通是存疑的,最后驗(yàn)證下來也是不能通的,完全是兩個(gè)體系。”

“進(jìn)入CMP的時(shí)代,如果一個(gè)應(yīng)用場景在15分鐘內(nèi)開不起來的話,那它就失敗了,更不要說借助第三方外力。”

本文整理自上海數(shù)訊CIO錢譽(yù)在TF中文社區(qū)“2020第一次Meetup”上的演講,分享早期云網(wǎng)絡(luò)實(shí)際應(yīng)用和二次開發(fā)過程中的經(jīng)驗(yàn)教訓(xùn)。XXX作為合作方,經(jīng)主辦方和演講者審閱授權(quán)發(fā)布。

在TF中文社區(qū)1月7日的“2020第一次Meetup”活動(dòng)上,來自Tungsten Fabric技術(shù)研發(fā)和一線使用者、關(guān)注多云互聯(lián)的從業(yè)者、開源SDN的愛好者們互相切磋、支招,現(xiàn)場氣氛熱烈,精彩內(nèi)容不斷。Tungsten Fabric在中國的廣泛應(yīng)用正在越來越真切地走來。

本次演講及TF中文社區(qū)“2020第一次Meetup”活動(dòng)資料,請?jiān)?ldquo;TF中文社區(qū)”公眾號(hào)后臺(tái)點(diǎn)擊“會(huì)議活動(dòng)-Meetup”領(lǐng)取。

上海數(shù)訊CIO錢譽(yù)

上海數(shù)訊是一家以傳統(tǒng)數(shù)據(jù)中心業(yè)務(wù)為主的公司,為什么會(huì)轉(zhuǎn)到云計(jì)算呢?在2011年以后,整個(gè)數(shù)據(jù)中心行業(yè)越來越像房地產(chǎn)了,數(shù)據(jù)中心這種業(yè)務(wù)可復(fù)制性比較強(qiáng),競爭激烈。到2013年的時(shí)候,有一些新的技術(shù)出來,包括OpenStack的爆發(fā)式增長,于是2014年開始決定去做云計(jì)算這個(gè)事情。

當(dāng)初的定義是多平臺(tái),從實(shí)際應(yīng)用場景來看的話,不是說虛擬機(jī)和容器哪個(gè)好,它們兩個(gè)應(yīng)用在不同的場景,沒有誰替代誰的問題,要做兩個(gè)平臺(tái)的時(shí)候,又碰到一個(gè)很尷尬的問題,虛擬機(jī)的網(wǎng)絡(luò)和容器的網(wǎng)絡(luò),完全是兩回事。

中間我們找了差不多10個(gè)SDN技術(shù),從商用的到開源的,再到國產(chǎn)小范圍應(yīng)用的,那個(gè)時(shí)候Tungsten Fabric還叫OpenContrail,當(dāng)時(shí)的版本還只支持OpenStack。

CMP是這幾年提出來的,但剛開始做的時(shí)候,已經(jīng)有CMP的理念了。

對比所有的Portal去看,不管是OpenStack還是原生的K8s,基本都是以運(yùn)維視角出發(fā)的,不是一個(gè)對外提供業(yè)務(wù)的一個(gè)case。所以從使用者來看的話,是一件非常痛苦的事情,當(dāng)時(shí)我們就決定把兩個(gè)平臺(tái)統(tǒng)一,在Web上做一個(gè)完整的、基于用戶自己界面的平臺(tái)。

在那個(gè)時(shí)候,確定了數(shù)訊云平臺(tái)和SDN的方向,當(dāng)時(shí)主要是OpenStack和K8s。我們發(fā)現(xiàn)一個(gè)問題,K8s不是一個(gè)PaaS平臺(tái),只是解決了一個(gè)docker管理的問題。如果是小環(huán)境的話,用不用都無所謂,不一定非要搞SDN,包括OpenStack也一樣,如果業(yè)務(wù)環(huán)境不是過于復(fù)雜的話,其實(shí)跑傳統(tǒng)的VLAN,只要控制量,沒有廣播風(fēng)暴,沒有任何問題。

TF中文社區(qū)3月Meetup活動(dòng),將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實(shí)踐,詳細(xì)演示操作過程,并解答關(guān)于Tungsten Fabric和K8s的一切問題。關(guān)注“TF中文社區(qū)”公眾號(hào),后臺(tái)點(diǎn)擊“會(huì)議活動(dòng)-Meetup”參與。

但如果你的業(yè)務(wù)場景非常復(fù)雜,以前收納在虛擬機(jī),現(xiàn)在收納在容器里,這種業(yè)務(wù)的出現(xiàn),會(huì)對網(wǎng)絡(luò)造成非常大的困境,不可能對每個(gè)線的業(yè)務(wù)去做策略。一旦出現(xiàn)業(yè)務(wù)遷移或trouble shooting的時(shí)候,后端運(yùn)維人員是崩潰的,沒法調(diào)。以前寫個(gè)PBR,寫個(gè)靜態(tài)路由,最多是掛幾個(gè)交換機(jī)路由。在云網(wǎng)絡(luò)環(huán)境里完全不是這樣,可能一個(gè)租戶下面無數(shù)虛擬機(jī),里面跑了無數(shù)不同的應(yīng)用方式,所有流的走向又是亂七八糟的,這種情況下,如果用傳統(tǒng)的方式,基本就不用做了,因?yàn)榭床坏筋^。所以要采用SDN的方式。

Tungsten Fabric的確非常優(yōu)秀,但也有一些問題存在,完全支持OVSDB的交換機(jī),對Tungsten Fabric的兼容會(huì)更好一點(diǎn)。也不是說Openflow不行,用流表的方式也能做,但那就比較折騰了。

數(shù)訊的底層Port,就是底層通過Tungsten Fabric的SDN技術(shù)支持線。當(dāng)時(shí)2015年OpenContrail時(shí)代的時(shí)候,K8s剛開放,我們提出要采用基于容器的方式,因?yàn)樘摂M機(jī)的方式對運(yùn)維、擴(kuò)容、遷移有弊端的話,后面業(yè)務(wù)是很難有保證的。那個(gè)時(shí)候OpenStack也比較早期,基本上都是自己統(tǒng)一部署,和Juniper networks聯(lián)合開發(fā)的時(shí)候,把OpenContrail放在一起部署。

另外,數(shù)訊作為數(shù)據(jù)中心運(yùn)營商,提供的是傳統(tǒng)的hosting,大家都在考慮上云的問題。在云計(jì)算中我們已經(jīng)使用了SDN技術(shù),非傳統(tǒng)VLAN的方式,那么用戶上云的時(shí)候怎么接呢,不可能再開個(gè)VLAN做個(gè)什么映射,比較困難。

還有,怎么把用戶實(shí)際在機(jī)房里的一堆業(yè)務(wù)場景,跟云計(jì)算的overlay網(wǎng)絡(luò)去連接,而不是以某個(gè)獨(dú)立的服務(wù)去試。

這里就解決了VLAN映射的問題,不可能為用戶提供專線,還要改變他的VLAN網(wǎng)絡(luò),這是不現(xiàn)實(shí)的,所以在這上面做了大量的二次開發(fā)。包括OpenStack和OpenShift,開源社區(qū)的版本都是單節(jié)點(diǎn),到真正地應(yīng)用到場景的話,最起碼要保證多節(jié)點(diǎn),社區(qū)版的東西要落到生產(chǎn)環(huán)境,包括和Tungsten Fabric對接,還是有很多二次開發(fā)要做。

這是在開發(fā)和調(diào)研中碰到的實(shí)際用例的問題,有些是我們自己的,有些是用戶應(yīng)用場景中的。

Neutron穩(wěn)定性比較差,我們曾經(jīng)實(shí)測過,開到2500個(gè)虛擬機(jī)會(huì)出現(xiàn)莫名其妙的抖動(dòng),導(dǎo)致全部崩潰,對于原生的Neutron,我們還是比較謹(jǐn)慎的。

如果K8s只是實(shí)現(xiàn)單一業(yè)務(wù),基本原生的Flannel或Calico都能解決,Calico對于多數(shù)據(jù)中心多任務(wù)的方式是不提供支持的,Calico是目前K8s開源環(huán)境使用最多的。

OpenShift雖然是有OVS,能不能和OpenStack互通是存疑的,最后驗(yàn)證下來也是不能通的,完全是兩個(gè)體系。

另外VNF和CNF是否能夠共存,也是未知。為什么虛擬機(jī)要去訪問容器?在我們看來極其不合理,但在金融行業(yè)或電商行業(yè),某些業(yè)務(wù)可以跑虛擬機(jī),某些已經(jīng)買了商業(yè)軟件,或者有些用戶自己有開發(fā)能力,已經(jīng)把一部分東西放到容器里了。

以前我們在虛擬機(jī)開一堆負(fù)載均衡,但在容器里直接一個(gè)Node無數(shù)port就解決了,包括很多注冊機(jī)機(jī)制不能portal,總不能把網(wǎng)絡(luò)做分段再做代理轉(zhuǎn)接,他們覺得非常難,看有沒有可能解決這個(gè)問題。我們最后試錯(cuò)下來,在最近解決了VNF和CNF在OpenStack虛擬機(jī)層面的互通問題,要用到管理網(wǎng)去做互通。

虛擬機(jī)網(wǎng)絡(luò)與容器網(wǎng)絡(luò)二層互訪,在Tungsten Fabric 4.0版本的時(shí)候是基于標(biāo)簽的方式,能用,但是用起來不方便。到現(xiàn)在5.1版本的時(shí)候,整個(gè)Portal也沒有把這個(gè)拉出來作為一個(gè)選項(xiàng),每次都要去翻虛擬機(jī)和容器去做對應(yīng),這個(gè)操作比較麻煩,我們也試過做二次開發(fā),比較累。如果有可能的話,把這兩個(gè)東西放在一起,管理起來就會(huì)非常方便。

軟件定義的FW、LB如何在跨場景中業(yè)務(wù)落地?大部分用戶場景里,都是用商業(yè)軟件,各種品牌都有,自己本身提供image,放到虛擬機(jī)都有自己的feature,怎么和Tungsten Fabric互通,肯定是要做二次開發(fā)的,但目前看來也就Tungsten Fabric有可能去做,其它的比較困難。

VPC的問題,在我們的理解里,Tungsten Fabric的VPC可以理解為現(xiàn)在國內(nèi)SDN web更合理,兩段VPN建立隧道。至于你要管到公有云的虛擬機(jī),好像不太可能。即使是給到你,可能最后也會(huì)放棄,光是版本迭代問題就沒法解決。沒人做這樣的事情。好處是有Portal,能夠看到整個(gè)業(yè)務(wù)的實(shí)際情況。

吐槽一下,Tungsten Fabric確實(shí)解決了OpenStack網(wǎng)絡(luò)拓展和穩(wěn)定性問題,但對網(wǎng)卡有點(diǎn)挑,在一些特殊的應(yīng)用場景里,比如跑VDI的IDP協(xié)議,我們發(fā)現(xiàn)Intel和Broadcom的網(wǎng)卡不那么友善。

相比OpenStack,目前為止Tungsten Fabric和OpenShift的對接難度更大一點(diǎn)。OpenShift開源的OKD本身就有一些問題,另外只是把Tungsten Fabric和OpenShift或K8s裝在一起,簡單應(yīng)用看不出問題,但如果跑幾個(gè)業(yè)務(wù)鏈,比如標(biāo)簽、應(yīng)用、路由網(wǎng)關(guān)、業(yè)務(wù)編排等,整個(gè)流程走下去會(huì)有問題。

TF中文社區(qū)3月Meetup活動(dòng),將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實(shí)踐,詳細(xì)演示操作過程,并解答關(guān)于Tungsten Fabric和K8s的一切問題。關(guān)注“TF中文社區(qū)”公眾號(hào),后臺(tái)點(diǎn)擊“會(huì)議活動(dòng)-Meetup”參與。

的確我們看下來,Tungsten Fabric就像文檔上面所說的,對OpenShift的支持,還是比其它開源軟件或商業(yè)軟件要好很多,至少還能看到用Tungsten Fabric做二次開發(fā)的曙光。

關(guān)于服務(wù)鏈,如果能夠和端口去做匹配,可能更好一點(diǎn),不要干預(yù)整條網(wǎng)絡(luò)的屬性,在某些特定場景里面會(huì)比較復(fù)雜。

多云環(huán)境我們目前適配下來,只有AWS和Azure是可以的,不過還是根據(jù)實(shí)際的應(yīng)用場景出發(fā),也沒必要把所有的公有云平臺(tái)對接一遍,業(yè)務(wù)也沒有那么復(fù)雜。

支持DPDK及smartNIC我們實(shí)測過,在OpenStack默認(rèn)的kernel環(huán)境下,達(dá)到安全廠商他們的軟件標(biāo)準(zhǔn),基本達(dá)不到,只有使用DPDK的方式才能達(dá)到標(biāo)稱值,但DPDK又是Intel的專屬,在實(shí)際場景中碰到了一些問題,有的應(yīng)用能跑起來,有的就不行。所以,要使用DPDK方式的話,還是要根據(jù)自己的使用場景去看一下。

Tungsten Fabric提供類似REST的API,所以即使自己要做CMP的話,去調(diào)用后端的參數(shù),相對還是比較容易的,但針對API的文檔有點(diǎn)亂。

到現(xiàn)在,我們做云計(jì)算是非常認(rèn)真的,從2014年到現(xiàn)在一直在不斷打磨自己的平臺(tái),所有的視角都是以用戶實(shí)例去呈現(xiàn),包括把Tungsten Fabric后端的API騰挪到前端,針對某個(gè)租戶他就能根據(jù)自己的策略去調(diào)。進(jìn)入CMP的時(shí)代,如果一個(gè)應(yīng)用場景在15分鐘內(nèi)開不起來的話,那它就失敗了,更不要說借助第三方外力。把很多權(quán)限都開放給用戶。

我們的PaaS后端是OpenShift,基于PaaS平臺(tái)的所有業(yè)務(wù)都在前端重做,包括Tungsten Fabric針對OpenShift的功能,都放在前端,包括Tungsten Fabric內(nèi)部都可以監(jiān)控,不用非常原始的SNMP的方式做采集,完全不需要。

目前為止,數(shù)訊的平臺(tái)做到了這個(gè)程度。選擇Tungsten Fabric是因?yàn)閰f(xié)議相對標(biāo)準(zhǔn),BGP VPN就能解決,我比較抵觸私有協(xié)議,某些友商總想搞個(gè)大一統(tǒng),最后也不太可能,還是開放式大家比較能接受。

談到VXLAN的問題,實(shí)際用下來,如果用kernel方式,如果量很大損耗還是很大,特別針對VXLAN沒有做特別優(yōu)化的交換機(jī)或網(wǎng)卡,直接性能損失大概在30%左右。

從整個(gè)Tungsten Fabric去看的話,基本上把不同的平臺(tái)、不同的網(wǎng)絡(luò)特性都統(tǒng)一管理起來了,只是容器和虛擬機(jī)還是有一定手動(dòng)的工作量,如果Tungsten Fabric把這個(gè)問題解決掉會(huì)更好。另外,Tungsten Fabric在OpenStack和OpenShift認(rèn)證機(jī)制上不太一致。

這幾年比較痛苦的是支持比較少,不管開源社區(qū)還是官方,主要側(cè)重于安裝,有一部分trouble shooting,但針對于實(shí)際的應(yīng)用場景部署相對比較缺失。做云計(jì)算不是開虛擬機(jī),用不用OpenStack無所謂,KVM就解決了。所以說云計(jì)算不是虛擬化,它有一定的業(yè)務(wù)邏輯在里面,意味著平臺(tái)要能對實(shí)際落地用戶的業(yè)務(wù)提供很多支持。

我們應(yīng)用Tungsten Fabric比較早,從3.2版本就開始搞,4.0版本正式對接。我相信如果有自己的業(yè)務(wù)邏輯,有一定的開發(fā)能力,基于Tungsten Fabric能打造出屬于自己的好的產(chǎn)品,Tungsten Fabric可編程型比較強(qiáng),通用性也比較強(qiáng)。滿分100的話,我打80分,剩下的20分是支持方面。

以上,我從實(shí)際的應(yīng)用場景,到開發(fā)當(dāng)中遇到的各種情況,拋出了一些問題。

非常感謝大家!

本次演講及TF中文社區(qū)“2020第一次Meetup”活動(dòng)資料,請?jiān)?ldquo;TF中文社區(qū)”公眾號(hào)后臺(tái)點(diǎn)擊“會(huì)議活動(dòng)-Meetup”參與。

生成海報(bào)

免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進(jìn)一步核實(shí)，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯(cuò)誤、不確或遺漏，概不負(fù)任何法律責(zé)任。任何單位或個(gè)人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識(shí)產(chǎn)權(quán)或存在不實(shí)內(nèi)容時(shí)，應(yīng)及時(shí)向本網(wǎng)站提出書面權(quán)利通知或不實(shí)情況說明，并提供身份證明、權(quán)屬證明及詳細(xì)侵權(quán)或不實(shí)情況證明。本網(wǎng)站在收到上述法律文件后，將會(huì)依法盡快聯(lián)系相關(guān)文章源頭核實(shí)，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。