Tungsten Fabric：连接CMP的金钥匙

其它VNF和CNF是否可以或许共存,也是未知。为什么假造神秘去会见容器?在我们看来极其不公道,但在金融行业或电商行业,某些营业可以跑假造机,某些已经买了贸易软件,可能有些用户本身有开拓手段,已经把一部门对象放到容器里了。

早年我们在假造机开一堆负载平衡,但在容器里直接一个Node无数port就办理了,包罗许多注册机机制不能portal,总不能把收集做分段再做署理转接,他们认为很是难,看有没有也许办理这个题目。我们最后试错下来,在最近办理了VNF和CNF在OpenStack假造机层面的互通题目,要用到打点网去做互通。

假造机收集与容器收集二层互访,在Tungsten Fabric 4.0版本的时辰是基于标签的方法,能用,可是用起来不利便。到此刻5.1版本的时辰,整个Portal也没有把这个拉出来作为一个选项,每次都要去翻假造机和容器去做对应,这个操纵较量贫困,我们也试过做二次开拓,较量累。假若有也许的话,把这两个对象放在一路,打点起来就会很是利便。

软件界说的FW、LB如安在跨场景中营业落地?大部门用户场景里,都是用贸易软件,各类品牌都有,本身自己提供image,放到假造机都有本身的feature,怎么和Tungsten Fabric互通,必定是要做二次开拓的,但今朝看来也就Tungsten Fabric有也许去做,其余的较量坚苦。

VPC的题目,在我们的领略里,Tungsten Fabric的VPC可以领略为此刻海内SDN web更公道,两段VPN成立地道。至于你要管到公有云的假造机,仿佛不太也许。纵然是给到你,也许最后也会放弃,光是版本迭代题目就没法办理。没人做这样的工作。甜头是有Portal,可以或许看到整个营业的现实环境。

吐槽一下,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的文档有点乱。

到此刻,我们做云计较长短常当真的,从2014年到此刻一向在不绝打磨本身的平台,全部的视角都是以用户实例去泛起,包罗把Tungsten Fabric后端的API腾挪到前端,针对某个租户他就能按照本身的计策去调。进入CMP的期间,假如一个应用场景在15分钟内开不起来的话,那它就失败了,更不要说借助第三方外力。把许多权限都开放给用户。

我们的PaaS后端是OpenShift,基于PaaS平台的全部营业都在前端重做,包罗Tungsten Fabric针对OpenShift的成果,都放在前端,包罗Tungsten Fabric内部都可以监控,不消很是原始的SNMP的方法做收罗,完全不必要。

今朝为止,数讯的平台做到了这个水平。选择Tungsten Fabric是由于协议相对尺度,BGP VPN就能办理,我较量抵触私有协议,某些友商总想搞个大一统,最后也不太也许,照旧开放式各人较量能接管。

谈到VXLAN的题目,现适用下来,假如用kernel方法,假如量很大消费照旧很大,出格针对VXLAN没有做出格优化的互换机或网卡,直接机能丧失或许在30%阁下。

从整个Tungsten Fabric去看的话,根基上把差异的平台、差异的收集特征都同一打点起来了,只是容器和假造机照旧有必然手动的事变量,假如Tungsten Fabric把这个题目办理掉会更好。其它,Tungsten Fabric在OpenStack和OpenShift认证机制上不太同等。

这几年较量疾苦的是支持较量少,不管开源社区照旧官方,首要偏重于安装,有一部门trouble shooting,但针对付现实的应用场景陈设相比拟力缺失。做云计较不是开假造机,用不消OpenStack无所谓,KVM就办理了。以是说云计较不是假造化,它有必然的营业逻辑在内里,意味着平台要能对现实落地用户的营业提供许多支持。

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!