Tungsten Fabric：连接CMP的金钥匙( 四 ) “我们找了差不多10个S

　　吐槽一下,Tungsten Fabric确实解决了OpenStack网络拓展和稳定性问题,但对网卡有点挑,在一些特殊的应用场景里,比如跑VDI的IDP协议,我们发现Intel和Broadcom的网卡不那么友善。

　　相比OpenStack,目前为止Tungsten Fabric和OpenShift的对接难度更大一点。 OpenShift开源的OKD本身就有一些问题,另外只是把Tungsten Fabric和OpenShift或K8s装在一起,简单应用看不出问题,但如果跑几个业务链,比如标签、应用、路由网关、业务编排等,整个流程走下去会有问题。

　　TF中文社区3月Meetup活动,将聚焦Tungsten Fabric与K8s的集成,由重量级嘉宾分享Tungsten Fabric与K8s的部署和实践,详细演示操作过程,并解答关于Tungsten Fabric和K8s的一切问题。关注“TF中文社区”公众号,后台点击“会议活动-Meetup”参与。

　　的确我们看下来,Tungsten Fabric就像文档上面所说的,对OpenShift的支持,还是比其它开源软件或商业软件要好很多,至少还能看到用Tungsten Fabric做二次开发的曙光。

　　关于服务链,如果能够和端口去做匹配,可能更好一点,不要干预整条网络的属性,在某些特定场景里面会比较复杂。

　　多云环境我们目前适配下来,只有AWS和Azure是可以的,不过还是根据实际的应用场景出发,也没必要把所有的公有云平台对接一遍,业务也没有那么复杂。

　　支持DPDK及smartNIC我们实测过,在OpenStack默认的kernel环境下,达到安全厂商他们的软件标准,基本达不到,只有使用DPDK的方式才能达到标称值,但DPDK又是Intel的专属,在实际场景中碰到了一些问题,有的应用能跑起来,有的就不行。所以,要使用DPDK方式的话,还是要根据自己的使用场景去看一下。

　　Tungsten Fabric提供类似REST的API,所以即使自己要做CMP的话,去调用后端的参数,相对还是比较容易的,但针对API的文档有点乱。

----Tungsten Fabric：连接CMP的金钥匙//----

　　到现在,我们做云计算是非常认真的,从2014年到现在一直在不断打磨自己的平台,所有的视角都是以用户实例去呈现,包括把Tungsten Fabric后端的API腾挪到前端,针对某个租户他就能根据自己的策略去调。进入CMP的时代,如果一个应用场景在15分钟内开不起来的话,那它就失败了,更不要说借助第三方外力。把很多权限都开放给用户。