本文所有相關資料 https://tungstenfabric.org.cn/assets/uploads/files/cmp-key-shuxun.pdf
上海數訊CIO錢譽
上海數訊是一家以傳統數據中心業務爲主的公司，爲什麼會轉到雲計算呢？在2011年以後，整個數據中心行業越來越像房地產了，數據中心這種業務可複製性比較強，競爭激烈。到2013年的時候，有一些新的技術出來，包括OpenStack的爆發式增長，於是2014年開始決定去做雲計算這個事情。
當初的定義是多平臺，從實際應用場景來看的話，不是說虛擬機和容器哪個好，它們兩個應用在不同的場景，沒有誰替代誰的問題，要做兩個平臺的時候，又碰到一個很尷尬的問題，虛擬機的網絡和容器的網絡，完全是兩回事。
中間我們找了差不多10個SDN技術，從商用的到開源的，再到國產小範圍應用的，那個時候Tungsten Fabric還叫OpenContrail，當時的版本還只支持OpenStack。
CMP是這幾年提出來的，但剛開始做的時候，已經有CMP的理念了。
對比所有的Portal去看，不管是OpenStack還是原生的K8s，基本都是以運維視角出發的，不是一個對外提供業務的一個case。所以從使用者來看的話，是一件非常痛苦的事情，當時我們就決定把兩個平臺統一，在Web上做一個完整的、基於用戶自己界面的平臺。
在那個時候，確定了數訊雲平臺和SDN的方向，當時主要是OpenStack和K8s。我們發現一個問題，K8s不是一個PaaS平臺，只是解決了一個docker管理的問題。如果是小環境的話，用不用都無所謂，不一定非要搞SDN，包括OpenStack也一樣，如果業務環境不是過於複雜的話，其實跑傳統的VLAN，只要控制量，沒有廣播風暴，沒有任何問題。
但如果你的業務場景非常複雜，以前收納在虛擬機，現在收納在容器裏，這種業務的出現，會對網絡造成非常大的困境，不可能對每個線的業務去做策略。一旦出現業務遷移或trouble shooting的時候，後端運維人員是崩潰的，沒法調。以前寫個PBR，寫個靜態路由，最多是掛幾個交換機路由。在雲網絡環境裏完全不是這樣，可能一個租戶下面無數虛擬機，裏面跑了無數不同的應用方式，所有流的走向又是亂七八糟的，這種情況下，如果用傳統的方式，基本就不用做了，因爲看不到頭。所以要採用SDN的方式。
Tungsten Fabric（以下簡稱TF）的確非常優秀，但也有一些問題存在，完全支持OVSDB的交換機，對TF的兼容會更好一點。也不是說Openflow不行，用流表的方式也能做，但那就比較折騰了。
數訊的底層Port，就是底層通過TF的SDN技術支持線。當時2015年OpenContrail時代的時候，K8s剛開放，我們提出要採用基於容器的方式，因爲虛擬機的方式對運維、擴容、遷移有弊端的話，後面業務是很難有保證的。那個時候OpenStack也比較早期，基本上都是自己統一部署，和Juniper networks聯合開發的時候，把OpenContrail放在一起部署。
另外，數訊作爲數據中心運營商，提供的是傳統的hosting，大家都在考慮上雲的問題。在雲計算中我們已經使用了SDN技術，非傳統VLAN的方式，那麼用戶上雲的時候怎麼接呢，不可能再開個VLAN做個什麼映射，比較困難。
還有，怎麼把用戶實際在機房裏的一堆業務場景，跟雲計算的overlay網絡去連接，而不是以某個獨立的服務去試。
這裏就解決了VLAN映射的問題，不可能爲用戶提供專線，還要改變他的VLAN網絡，這是不現實的，所以在這上面做了大量的二次開發。包括OpenStack和OpenShift，開源社區的版本都是單節點，到真正地應用到場景的話，最起碼要保證多節點，社區版的東西要落到生產環境，包括和TF對接，還是有很多二次開發要做。
這是在開發和調研中碰到的實際用例的問題，有些是我們自己的，有些是用戶應用場景中的。
Neutron穩定性比較差，我們曾經實測過，開到2500個虛擬機會出現莫名其妙的抖動，導致全部崩潰，對於原生的Neutron，我們還是比較謹慎的。
如果K8s只是實現單一業務，基本原生的Flannel或Calico都能解決，Calico對於多數據中心多任務的方式是不提供支持的，Calico是目前K8s開源環境使用最多的。
OpenShift雖然是有OVS，能不能和OpenStack互通是存疑的，最後驗證下來也是不能通的，完全是兩個體系。
另外VNF和CNF是否能夠共存，也是未知。爲什麼虛擬機要去訪問容器？在我們看來極其不合理，但在金融行業或電商行業，某些業務可以跑虛擬機，某些已經買了商業軟件，或者有些用戶自己有開發能力，已經把一部分東西放到容器裏了。
以前我們在虛擬機開一堆負載均衡，但在容器裏直接一個Node無數port就解決了，包括很多註冊機機制不能portal，總不能把網絡做分段再做代理轉接，他們覺得非常難，看有沒有可能解決這個問題。我們最後試錯下來，在最近解決了VNF和CNF在OpenStack虛擬機層面的互通問題，要用到管理網去做互通。
虛擬機網絡與容器網絡二層互訪，在TF 4.0版本的時候是基於標籤的方式，能用，但是用起來不方便。到現在5.1版本的時候，整個Portal也沒有把這個拉出來作爲一個選項，每次都要去翻虛擬機和容器去做對應，這個操作比較麻煩，我們也試過做二次開發，比較累。如果有可能的話，把這兩個東西放在一起，管理起來就會非常方便。
軟件定義的FW、LB如何在跨場景中業務落地？大部分用戶場景裏，都是用商業軟件，各種品牌都有，自己本身提供image，放到虛擬機都有自己的feature，怎麼和TF互通，肯定是要做二次開發的，但目前看來也就TF有可能去做，其它的比較困難。
VPC的問題，在我們的理解裏，TF的VPC可以理解爲現在國內SDN web更合理，兩段VPN建立隧道。至於你要管到公有云的虛擬機，好像不太可能。即使是給到你，可能最後也會放棄，光是版本迭代問題就沒法解決。沒人做這樣的事情。好處是有Portal，能夠看到整個業務的實際情況。
吐槽一下，TF確實解決了OpenStack網絡拓展和穩定性問題，但對網卡有點挑，在一些特殊的應用場景裏，比如跑VDI的IDP協議，我們發現Intel和Broadcom的網卡不那麼友善。
相比OpenStack，目前爲止TF和OpenShift的對接難度更大一點。OpenShift開源的OKD本身就有一些問題，另外只是把TF和OpenShift或K8s裝在一起，簡單應用看不出問題，但如果跑幾個業務鏈，比如標籤、應用、路由網關、業務編排等，整個流程走下去會有問題。
的確我們看下來，TF就像文檔上面所說的，對OpenShift的支持，還是比其它開源軟件或商業軟件要好很多，至少還能看到用TF做二次開發的曙光。
關於服務鏈，如果能夠和端口去做匹配，可能更好一點，不要干預整條網絡的屬性，在某些特定場景裏面會比較複雜。
多雲環境我們目前適配下來，只有AWS和Azure是可以的，不過還是根據實際的應用場景出發，也沒必要把所有的公有云平臺對接一遍，業務也沒有那麼複雜。
支持DPDK及smartNIC我們實測過，在OpenStack默認的kernel環境下，達到安全廠商他們的軟件標準，基本達不到，只有使用DPDK的方式才能達到標稱值，但DPDK又是Intel的專屬，在實際場景中碰到了一些問題，有的應用能跑起來，有的就不行。所以，要使用DPDK方式的話，還是要根據自己的使用場景去看一下。
TF提供類似REST的API，所以即使自己要做CMP的話，去調用後端的參數，相對還是比較容易的，但針對API的文檔有點亂。
到現在，我們做雲計算是非常認真的，從2014年到現在一直在不斷打磨自己的平臺，所有的視角都是以用戶實例去呈現，包括把TF後端的API騰挪到前端，針對某個租戶他就能根據自己的策略去調。進入CMP的時代，如果一個應用場景在15分鐘內開不起來的話，那它就失敗了，更不要說藉助第三方外力。把很多權限都開放給用戶。
我們的PaaS後端是OpenShift，基於PaaS平臺的所有業務都在前端重做，包括TF針對OpenShift的功能，都放在前端，包括TF內部都可以監控，不用非常原始的SNMP的方式做採集，完全不需要。
目前爲止，數訊的平臺做到了這個程度。選擇TF是因爲協議相對標準，BGP VPN就能解決，我比較牴觸私有協議，某些友商總想搞個大一統，最後也不太可能，還是開放式大家比較能接受。
談到VXLAN的問題，實際用下來，如果用kernel方式，如果量很大損耗還是很大，特別針對VXLAN沒有做特別優化的交換機或網卡，直接性能損失大概在30%左右。
從整個TF去看的話，基本上把不同的平臺、不同的網絡特性都統一管理起來了，只是容器和虛擬機還是有一定手動的工作量，如果TF把這個問題解決掉會更好。另外，TF在OpenStack和OpenShift認證機制上不太一致。
這幾年比較痛苦的是支持比較少，不管開源社區還是官方，主要側重於安裝，有一部分trouble shooting，但針對於實際的應用場景部署相對比較缺失。做雲計算不是開虛擬機，用不用OpenStack無所謂，KVM就解決了。所以說雲計算不是虛擬化，它有一定的業務邏輯在裏面，意味着平臺要能對實際落地用戶的業務提供很多支持。
我們應用TF比較早，從3.2版本就開始搞，4.0版本正式對接。我相信如果有自己的業務邏輯，有一定的開發能力，基於TF能打造出屬於自己的好的產品，TF可編程型比較強，通用性也比較強。滿分100的話，我打80分，剩下的20分是支持方面。
以上，我從實際的應用場景，到開發當中遇到的各種情況，拋出了一些問題。
非常感謝大家！
MORE 更多TF Meetup演講實錄
多雲互聯的現實困境與開源SDN之路丨首場TF Meetup演講實錄
TF中文社區技術代表、瞻博網絡中國區合作伙伴技術經理張建勳
關注微信：TF中文社區
郵箱：[email protected]
