Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄


Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄
關注微信:TF華文社區
Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

關於TF華文社區:
TF華文社區由中國的一群關注和熱愛SDN的志願者自發發起,有技術老鳥,市場老炮,也有行業專家,資深用戶。將作為連署社區與中國的橋梁,傳布資訊,提交問題,幫會活動,聯手一切對多雲互聯網絡有興致的力氣,切實解決雲網絡建設過程中遇到的問題。


關於Tungsten Fabric:
Tungsten Fabric項目是一個開源項目協議,它基於標准協議開發,而且提供網絡虛擬化和網絡安全所必需的所有組件。項目標組件涵蓋:SDN扼制器,虛擬路由器,剖析引擎,北向API的發布,硬件集成功能,雲編排軟件和廣泛的REST API。

十分拜謝大家!

以上,我從實際的應用場景,到開發居中遇到的各種情況,拋出了一點問題。?

我們應用TF比較早,從3.2版本就起始搞,4.0版本正式對接。我信任假如有自個兒的業務邏輯,有一定的開發能力,基於TF能打造出歸屬自個兒的好的產品,TF可編程型比較強,通用性也比較強。滿分100的話,我打80分,餘下的20分是支持方面。?

這幾年比較苦痛的是支持比較少,無論開源社區仍然官方,主要側重於安裝,有一局部trouble shooting,但針對於實際的應用場景部署相對比較缺失。做雲計算不是開虛擬機,用無須OpenStack無所謂,KVM就解決了。所以說雲計算不是虛擬化,它有一定的業務邏輯在裡面,意味著平臺要能對實際墜地用戶的業務提供眾多支持。?

從囫圇TF去看的話,基本上把不一樣的平臺、不一樣的網絡特性都統管起來了,只是器皿和虛擬機仍然有一定手動的辦公量,假如TF把這個問題解決掉會更好。額外,TF在OpenStack和OpenShift認證機制上不太相符。?

談到VXLAN的問題,實際用下來,假如用kernel形式,假如量巨大傷耗仍然巨大,出奇針對VXLAN沒有做出奇優化的交換機或網卡,直接性能虧折約略在30百分之百左右。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄
現下為止,數訊的平臺做到達這個程度。取捨TF是因為協議相對標准,BGP ***就能解決,我比較抵觸私有協議,某些友商總想搞個大一統,最終也不太可能,仍然開放式大家比較能接納。?

我們的PaaS後端是OpenShift,基於PaaS平臺的所有業務都在前端重做,涵蓋TF針對OpenShift的功能,都放在前端,涵蓋TF內部都可以監控,無須十分原始的SNMP的形式做采集,純粹不必。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

迄今,我們做雲計算是十分認實在,從2014年迄今一直在不斷打磨自個兒的平臺,所有的視角都是以用戶范例去閃現,涵蓋把TF後端的API騰挪到前端,針對某個租戶他就能依據自個兒的策略去調。步入CMP的時世,假如一個應用場景在15分鍾內開不起來的話,那它就敗績了,更別說借助第三方外力。把眾多權限都開放給用戶。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

TF提供類似REST的API,所以縱然自個兒要做CMP的話,去調用後端的參變量,相對仍然比較容易的,但針對API的文檔長處亂。?

支持DPDK及smartNIC我們實測過,在OpenStack默認的kernel背景下,達到安全廠商它們的軟件標准,基本達不到,只有使役DPDK的形式能力達到標稱值,但DPDK又是Intel的專屬,在實際場景中遇到了一點問題,有的應用能跑起來,有的就不成。所以,要使役DPDK形式的話,仍然要依據自個兒的使役場景去看一下。?

多雲背景我們現下適配下來,只有AWS和Azure是可以的,然而仍然依據實際的應用場景起航,也沒必要把所有的公有雲平臺對接一遍,業務也沒有那麼復雜。?

關於服務鏈,假如能夠和端口去做般配,可能更好一點兒,不要乾預整條網絡的屬性,在某些特定場景裡面會比較復雜。?

確實我們看下來,TF就像文檔上述,對OpenShift的支持,仍然比其他開源軟件或商業軟件要好眾多,至少還能看見用TF做二次開發的曙光。?

相形OpenStack,現下為止TF和OpenShift的對接難度更大一點兒。OpenShift開源的OKD本身就有一點問題,額外只是把TF和OpenShift或K8s裝在一起,簡單應用看不出問題,但假如跑幾個業務鏈,譬如標簽、應用、路由網關、業務編排等,囫圇流程走下去會有問題。?

吐槽一下,TF委實解決了OpenStack網絡拓展和安定性問題,但對網卡長處挑,在一點特別的應用場景裡,譬如跑VDI的IDP協議,我們發現Intel和Broadcom的網卡不那麼友善。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

VPC的問題,在我們的明白裡,TF的VPC可以明白為如今國內SDN web更合理,兩段***開辦隧道。至於你要管到公有雲的虛擬機,好似不太可能。縱然是給到你,可能最終也會讓步,光是版本迭代問題就沒法解決。沒人做這麼的事體。益處是有Portal,能夠看見囫圇業務的實況。?

軟件定義的FW、LB若何在跨場景中業務墜地?大多用戶場景裡,都是用商業軟件,各種品牌都有,自個兒本身提供image,放到虛擬機都有自個兒的feature,怎麼和TF互通,肯定是要做二次開發的,但現下看來也就TF可能去做,其他的比較艱難。?

虛擬機網絡與器皿網絡二層互訪,在TF 4.0版本的時分是基於標簽的形式,能用,不過用起來不便。迄今5.1版本的時分,囫圇Portal也沒有把這個拉出來作為一個選項,每每都要去翻虛擬機和器皿去做對應,這個操作比較麻煩,我們也試過做二次開發,比較累。假如可能的話,把這兩個物品放在一起,管理起來便會十分便捷。?

?曾經我們在虛擬機開一堆負載均衡,但在器皿裡直接一個Node無數port就解決了,涵蓋眾多注冊機機制不得portal,總不得把網絡做分段再做攝理轉接,它們感到十分難,看有沒可能解決這個問題。我們最終試錯下來,在近來解決了VNF和CNF在OpenStack虛擬機層面的互通問題,要用到管理網去做互通。?

額外VNF和CNF是否能夠並存,也是未知。為何虛擬機要去過訪器皿?在我們看來萬分睽異理,但在金融行業或電商行業,某些業務可以跑虛擬機,某些已經買了商業軟件,還是有點用戶自個兒有開發能力,已經把一局部物品放到器皿裡了。

OpenShift雖然是有OVS,能不得和OpenStack互通是存疑的,最終驗證下來也是不得通的,純粹是兩個體系。?

假如K8s只是實行純一業務,基本原生的Flannel或Calico都能解決,Calico對於多數據核心多任務的形式是不提供支持的,Calico是現下K8s開源背景使役最多的。?

Neutron安定性比較差,我們曾經實測過,開到2500個虛擬機緣出現莫名其妙的抖動,以致所有解體,對於原生的Neutron,我們仍然比較謹慎的。?

這是在開發和調研中遇到的實際用例的問題,有點是我們自個兒的,有點是用戶應用場景中的。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

這搭就解決了VLAN映射的問題,不可能為用戶提供專線,還要變更他的VLAN網絡,這是不事實的,所以在這上頭做了大量的二次開發。涵蓋OpenStack和OpenShift,開源社區的版本都是單節點,到真正地應用到場景的話,最起碼要保障多節點,社區版的物品要落到生產背景,涵蓋和TF對接,仍然有眾多二次開發要做。?

還有,怎麼把用戶實際在機房裡的一堆業務場景,跟雲計算的overlay網絡去連署,而不是以某個獨立的服務去試。?

額外,數訊作為數據核心運營商,提供的是傳統的hosting,大家都在考量上雲的問題。在雲計算中我們已經使役了SDN技術,非傳統VLAN的形式,那麼用戶上雲的時分怎麼接呢,不可能再開個VLAN做個啥子映射,比較艱難。?

數訊的底層Port,就是底層經過TF的SDN技術支持線。當初2015年OpenContrail時世的時分,K8s剛開放,我們提出要采用基於器皿的形式,因為虛擬機的形式對運維、擴容、搬遷有弊病的話,後面業務是很難有保障的。那個時分OpenStack也比較早期,基本上都是自個兒一統部署,和Juniper networks聯手開發的時分,把OpenContrail放在一起部署。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

Tungsten Fabric(以下略稱TF)確實十分優秀,但也有一點問題存在,純粹支持OVSDB的交換機,對TF的兼容會更好一點兒。也不是說Openflow不成,用流表的形式也能做,但那就比較折騰了。?

但假如你的業務場景十分復雜,曾經收納在虛擬機,如今收納在器皿裡,這種業務的出現,會對網絡導致很大的厄境,不可能對每個線的業務去做策略。一朝出現業務搬遷或trouble shooting的時分,後端運維成員是解體的,沒法調。曾經寫個PBR,寫個靜態路由,最多是掛幾個交換機路由。在雲網絡背景裡純粹不是這麼,可能一個租戶下邊無數虛擬機,裡面跑了無數不一樣的應用形式,所有流的走向又是亂七八糟的,這種情況下,假如用傳統的形式,基本就無須做了,因為看不到頭。所以要采用SDN的形式。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄
在那個時分,確認了數訊雲平臺和SDN的方向,當初主要是OpenStack和K8s。我們發現一個問題,K8s不是一個PaaS平臺,只是解決了一個docker管理的問題。若是小背景的話,用無須都無所謂,不盡然非要搞SDN,涵蓋OpenStack也同樣,假如業務背景不是過於復雜的話,實則跑傳統的VLAN,只要扼制量,沒有廣播風暴,沒有任何問題。?

對比所有的Portal去看,無論是OpenStack仍然原生的K8s,基本都是以運維視角起航的,不是一個對外提供業務的一個case。所以從使役者來看的話,是一件十分苦痛的事體,當初我們就表決把兩個平臺一統,在Web上做一個完整的、基於用戶自個兒界面的平臺。?

CMP是這幾年提出來的,但剛起始做的時分,已經有CMP的理念了。?

半中腰我們找了差不離10個SDN技術,從商用的到開源的,再到國產小范圍應用的,那個時分Tungsten Fabric還叫OpenContrail,當初的版本還只支持OpenStack。
Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄

當初的定義是多平臺,從實際應用場景來看的話,不是說虛擬機和器皿哪個好,它們兩個應用在不一樣的場景,沒有誰替代誰的問題,要做兩個平臺的時分,又遇到一個很難堪的問題,虛擬機的網絡和器皿的網絡,純粹是兩碼事。?

上海數訊是一家以傳統數據核心業務為主的企業,為何會轉到雲計算呢?在2011年之後,囫圇數據核心行業越來越像房地產了,數據核心這種業務可復制性比較強,競爭緊張。到2013年的時分,有一點新的技術出來,涵蓋OpenStack的爆發型增長,於是2014年起始表決去做雲計算這個事體。?

Tungsten Fabric:連署CMP的金鑰匙丨TF Meetup演講實錄
上海數訊CIO錢譽

本文所有相關資料 https://163.53.94.133/assets/uploads/files/cmp-key-shuxun.pdf


發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *