Tungsten Fabric：连接CMP的金钥匙

至顶网网络与安全频道 02月26日 综合消息： 

“我们找了差不多10个SDN技术,从商用的到开源的,再到国产小范围应用的。”

“对比所有的Portal去看,不管是OpenStack还是原生的K8s,基本都是以运维视角出发的,不是一个对外提供业务的case。”

“K8s不是一个PaaS平台,只是解决了一个docker管理的问题。”

“在云网络环境里,可能一个租户下面无数虚拟机,里面跑了无数不同的应用方式,所有流的走向又是乱七八糟的。”

“OpenShift虽然是有OVS,能不能和OpenStack互通是存疑的,最后验证下来也是不能通的,完全是两个体系。”

“进入CMP的时代,如果一个应用场景在15分钟内开不起来的话,那它就失败了,更不要说借助第三方外力。”

本文整理自上海数讯CIO钱誉在TF中文社区“2020第一次Meetup”上的演讲,分享早期云网络实际应用和二次开发过程中的经验教训。

在TF中文社区1月7日的“2020第一次Meetup”活动上,来自Tungsten Fabric技术研发和一线使用者、关注多云互联的从业者、开源SDN的爱好者们互相切磋、支招,现场气氛热烈,精彩内容不断。Tungsten Fabric在中国的广泛应用正在越来越真切地走来。

本次演讲及TF中文社区“2020第一次Meetup”活动资料,请在“TF中文社区”公众号后台点击“会议活动-Meetup”领取。

上海数讯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,只要控制量,没有广播风暴,没有任何问题。

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

但如果你的业务场景非常复杂,以前收纳在虚拟机,现在收纳在容器里,这种业务的出现,会对网络造成非常大的困境,不可能对每个线的业务去做策略。一旦出现业务迁移或trouble shooting的时候,后端运维人员是崩溃的,没法调。以前写个PBR,写个静态路由,最多是挂几个交换机路由。在云网络环境里完全不是这样,可能一个租户下面无数虚拟机,里面跑了无数不同的应用方式,所有流的走向又是乱七八糟的,这种情况下,如果用传统的方式,基本就不用做了,因为看不到头。所以要采用SDN的方式。

Tungsten Fabric的确非常优秀,但也有一些问题存在,完全支持OVSDB的交换机,对Tungsten Fabric的兼容会更好一点。也不是说Openflow不行,用流表的方式也能做,但那就比较折腾了。

数讯的底层Port,就是底层通过Tungsten Fabric的SDN技术支持线。当时2015年OpenContrail时代的时候,K8s刚开放,我们提出要采用基于容器的方式,因为虚拟机的方式对运维、扩容、迁移有弊端的话,后面业务是很难有保证的。那个时候OpenStack也比较早期,基本上都是自己统一部署,和Juniper networks联合开发的时候,把OpenContrail放在一起部署。

另外,数讯作为数据中心运营商,提供的是传统的hosting,大家都在考虑上云的问题。在云计算中我们已经使用了SDN技术,非传统VLAN的方式,那么用户上云的时候怎么接呢,不可能再开个VLAN做个什么映射,比较困难。

还有,怎么把用户实际在机房里的一堆业务场景,跟云计算的overlay网络去连接,而不是以某个独立的服务去试。

这里就解决了VLAN映射的问题,不可能为用户提供专线,还要改变他的VLAN网络,这是不现实的,所以在这上面做了大量的二次开发。包括OpenStack和OpenShift,开源社区的版本都是单节点,到真正地应用到场景的话,最起码要保证多节点,社区版的东西要落到生产环境,包括和Tungsten Fabric对接,还是有很多二次开发要做。

这是在开发和调研中碰到的实际用例的问题,有些是我们自己的,有些是用户应用场景中的。

Neutron稳定性比较差,我们曾经实测过,开到2500个虚拟机会出现莫名其妙的抖动,导致全部崩溃,对于原生的Neutron,我们还是比较谨慎的。

如果K8s只是实现单一业务,基本原生的Flannel或Calico都能解决,Calico对于多数据中心多任务的方式是不提供支持的,Calico是目前K8s开源环境使用最多的。

OpenShift虽然是有OVS,能不能和OpenStack互通是存疑的,最后验证下来也是不能通的,完全是两个体系。

（编辑：衡阳站长网）

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