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

10年積累的成都網(wǎng)站制作、做網(wǎng)站經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站制作后付款的網(wǎng)站建設(shè)流程，更有平果免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

上海數(shù)訊CIO錢譽

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

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

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

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

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

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

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

Tungsten Fabric（以下簡稱TF）的確非常優(yōu)秀，但也有一些問題存在，完全支持OVSDB的交換機，對TF的兼容會更好一點。也不是說Openflow不行，用流表的方式也能做，但那就比較折騰了。?

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

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

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

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

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

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

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

OpenShift雖然是有OVS，能不能和OpenStack互通是存疑的，最后驗證下來也是不能通的，完全是兩個體系。?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目前為止，數(shù)訊的平臺做到了這個程度。選擇TF是因為協(xié)議相對標準，BGP ***就能解決，我比較抵觸私有協(xié)議，某些友商總想搞個大一統(tǒng)，最后也不太可能，還是開放式大家比較能接受。?

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

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

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

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

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

非常感謝大家！

---

關(guān)于Tungsten Fabric：
Tungsten Fabric項目是一個開源項目協(xié)議，它基于標準協(xié)議開發(fā)，并且提供網(wǎng)絡(luò)虛擬化和網(wǎng)絡(luò)安全所必需的所有組件。項目的組件包括：SDN控制器，虛擬路由器，分析引擎，北向API的發(fā)布，硬件集成功能，云編排軟件和廣泛的REST API。

關(guān)于TF中文社區(qū)：
TF中文社區(qū)由中國的一群關(guān)注和熱愛SDN的志愿者自發(fā)發(fā)起，有技術(shù)老鳥，市場老炮，也有行業(yè)專家，資深用戶。將作為連接社區(qū)與中國的橋梁，傳播資訊，提交問題，組織活動，聯(lián)合一切對多云互聯(lián)網(wǎng)絡(luò)有興趣的力量，切實解決云網(wǎng)絡(luò)建設(shè)過程中遇到的問題。

---

關(guān)注微信：TF中文社區(qū)

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

文章標題：TungstenFabric：連接CMP的金鑰匙丨TFM-創(chuàng)新互聯(lián)
分享網(wǎng)址：http://chinadenli.net/article48/edehp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供虛擬主機、品牌網(wǎng)站制作、搜索引擎優(yōu)化、Google、手機網(wǎng)站建設(shè)、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)