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

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

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

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

數(shù)訊SDS VDC：一種功能強(qiáng)大的企業(yè)級(jí)混合云平臺(tái)，將為企業(yè)云能力開(kāi)啟新的水平。

數(shù)訊SDS VDC，可以幫助企業(yè)靈活地連接成為一個(gè)數(shù)字化業(yè)務(wù)所需的智能功能平臺(tái)，為敏捷性和云計(jì)算的經(jīng)濟(jì)性與內(nèi)部部署的IT環(huán)境提供可靠性和安全性。

• 數(shù)訊云計(jì)算，掌握云計(jì)算核心技術(shù)，擁有完全自主知識(shí)產(chǎn)權(quán)

• 數(shù)訊云計(jì)算，核心研發(fā)團(tuán)隊(duì)自2014年就一直致力于云計(jì)算技術(shù)的研究和開(kāi)發(fā)工作

對(duì)比所有的Portal去看，不管是OpenStack還是原生的K8s，基本都是以運(yùn)維視角出發(fā)的，不是一個(gè)對(duì)外提供業(yè)務(wù)的一個(gè)case。所以從使用者來(lái)看的話，是一件非常痛苦的事情，當(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è)問(wèn)題，K8s不是一個(gè)PaaS平臺(tái)，只是解決了一個(gè)docker管理的問(wèn)題。如果是小環(huán)境的話，用不用都無(wú)所謂，不一定非要搞SDN，包括OpenStack也一樣，如果業(yè)務(wù)環(huán)境不是過(guò)于復(fù)雜的話，其實(shí)跑傳統(tǒng)的VLAN，只要控制量，沒(méi)有廣播風(fēng)暴，沒(méi)有任何問(wèn)題。

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

TungstenFabric（以下簡(jiǎn)稱TF）的確非常優(yōu)秀，但也有一些問(wèn)題存在，完全支持OVSDB的交換機(jī)，對(duì)TF的兼容會(huì)更好一點(diǎn)。也不是說(shuō)Openflow不行，用流表的方式也能做，但那就比較折騰了。

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

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

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

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

開(kāi)發(fā)及調(diào)研中碰到的8類網(wǎng)絡(luò)問(wèn)題

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

1、OpenstackNeutron OVS 擴(kuò)展差，穩(wěn)定性低。Neutron穩(wěn)定性比較差，我們?cè)?jīng)實(shí)測(cè)過(guò)，開(kāi)到2500個(gè)虛擬機(jī)會(huì)出現(xiàn)莫名其妙的抖動(dòng)，導(dǎo)致全部崩潰，對(duì)于原生的Neutron，我們還是比較謹(jǐn)慎的。

2、K8S的Fannel&Calcio并不完全適應(yīng)User Case場(chǎng)景及多region的設(shè)計(jì)。如果K8s只是實(shí)現(xiàn)單一業(yè)務(wù)，基本原生的Flannel或Calico都能解決，Calico對(duì)于多數(shù)據(jù)中心多任務(wù)的方式是不提供支持的，Calico是目前K8s開(kāi)源環(huán)境使用最多的。

3、OKD（openshift Origin）的OVS能否與Openstack互通存疑，VNF和CNF是否能共存未知。OpenShift雖然是有OVS，能不能和OpenStack互通是存疑的，最后驗(yàn)證下來(lái)也是不能通的，完全是兩個(gè)體系。

4、虛擬機(jī)網(wǎng)絡(luò)與容器網(wǎng)絡(luò)如何進(jìn)行二層互訪，使得效率更高？另外VNF和CNF是否能夠共存，也是未知。為什么虛擬機(jī)要去訪問(wèn)容器？在我們看來(lái)極其不合理，但在金融行業(yè)或電商行業(yè)，某些業(yè)務(wù)可以跑虛擬機(jī)，某些已經(jīng)買了商業(yè)軟件，或者有些用戶自己有開(kāi)發(fā)能力，已經(jīng)把一部分東西放到容器里了。

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

5、對(duì)于數(shù)據(jù)中心內(nèi)的用戶，如何使得云服務(wù)于傳統(tǒng)的Hosting及BMS在一個(gè)網(wǎng)絡(luò)平面內(nèi)訪問(wèn)管理？虛擬機(jī)網(wǎng)絡(luò)與容器網(wǎng)絡(luò)二層互訪，在TF 4.0版本的時(shí)候是基于標(biāo)簽的方式，能用，但是用起來(lái)不方便。到現(xiàn)在5.1版本的時(shí)候，整個(gè)Portal也沒(méi)有把這個(gè)拉出來(lái)作為一個(gè)選項(xiàng)，每次都要去翻虛擬機(jī)和容器去做對(duì)應(yīng)，這個(gè)操作比較麻煩，我們也試過(guò)做二次開(kāi)發(fā)，比較累。如果有可能的話，把這兩個(gè)東西放在一起，管理起來(lái)就會(huì)非常方便。

6、軟件定義的FW、LB如何在跨場(chǎng)景中得到業(yè)務(wù)落地？（特別是由其作為統(tǒng)一internet出口）。 軟件定義的FW、LB如何在跨場(chǎng)景中業(yè)務(wù)落地？大部分用戶場(chǎng)景里，都是用商業(yè)軟件，各種品牌都有，自己本身提供image，放到虛擬機(jī)都有自己的feature，怎么和TF互通，肯定是要做二次開(kāi)發(fā)的，但目前看來(lái)也就TF有可能去做，其它的比較困難。

7、針對(duì)不同云廠商提供五花八門的VPC，如何進(jìn)行統(tǒng)一接入管理？VPC的問(wèn)題，在我們的理解里，TF的VPC可以理解為現(xiàn)在國(guó)內(nèi)SDNweb更合理，兩段VPN建立隧道。至于你要管到公有云的虛擬機(jī)，好像不太可能。即使是給到你，可能最后也會(huì)放棄，光是版本迭代問(wèn)題就沒(méi)法解決。沒(méi)人做這樣的事情。好處是有Portal，能夠看到整個(gè)業(yè)務(wù)的實(shí)際情況。

8、各自為陣的網(wǎng)絡(luò)如何能有效的進(jìn)行運(yùn)營(yíng)及排障？吐槽一下，TF確實(shí)解決了OpenStack網(wǎng)絡(luò)拓展和穩(wěn)定性問(wèn)題，但對(duì)網(wǎng)卡有點(diǎn)挑，在一些特殊的應(yīng)用場(chǎng)景里，比如跑VDI的IDP協(xié)議，我們發(fā)現(xiàn)Intel和Broadcom的網(wǎng)卡不那么友善。

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

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

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

多云環(huán)境我們目前已經(jīng)適配AWS和Azure，可以很好適配國(guó)際化企業(yè)實(shí)際的應(yīng)用場(chǎng)景，并且對(duì)一些有VPC虛擬私有云通道的國(guó)內(nèi)公有云也適配。取得這項(xiàng)進(jìn)步，在業(yè)界還屬于開(kāi)創(chuàng)性的！

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

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

到現(xiàn)在，我們做云計(jì)算是非常認(rèn)真的，從2014年到現(xiàn)在一直在不斷打磨，SDS VDC云平臺(tái)，所有的視角都是以用戶實(shí)例去呈現(xiàn)：

• 把TF后端的API騰挪到前端。

• 每家用戶都能根據(jù)自己的策略去調(diào)。

• 進(jìn)入多云管理CMP的時(shí)代，如果一個(gè)應(yīng)用場(chǎng)景在15分鐘內(nèi)開(kāi)不起來(lái)的話，那它就失敗了，更不要說(shuō)借助第三方外力。

• 把很多權(quán)限都開(kāi)放給用戶。

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

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

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

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

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

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

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

非常感謝大家！（演講結(jié)束）