2020年1月7日(周二)下午,北京新云南皇冠假日酒店,在由tf中文社区主办的“多云互联 · 开源开放”tf meetup大会上,上海数讯信息技术有限公司作为社区的创始会员、国内tf应用领先者,现场分享了数讯云vdc多云管理服务(cmp)开发及调研中碰到的问题,和升级完善之道。
以下文稿摘选自数讯信息云事业部总经理钱誉的演讲实录,为您讲述几年来数讯vdc开发创建的历程,及成就!数讯云vdc为应用场景复杂的企业做好技术落地与服务管控。演讲带来了开源sdn的技术风暴。
上海数讯是一家以传统数据中心业务为主的公司,为什么会转到云计算呢在2011年以后,整个数据中心行业越来越像房地产了,数据中心这种业务可复制性比较强,竞争激烈。到2013年的时候,有一些新的技术出来,包括openstack的爆发式增长,于是2014年开始决定去做云计算这个事情。
当初的定义是多平台,从实际应用场景来看的话,不是说虚拟机和容器哪个好,它们两个应用在不同的场景,没有谁替代谁的问题,要做两个平台的时候,又碰到一个很尴尬的问题,虚拟机的网络和容器的网络,完全是两回事。
中间我们找了差不多10个sdn技术,从商用的到开源的,再到国产小范围应用的,那个时候tungsten fabric还叫opencontrail,当时的版本还只支持openstack。
cmp是这几年提出来的,但刚开始做的时候,已经有cmp的理念了。
数讯sds vdc:一种功能强大的企业级混合云平台,将为企业云能力开启新的水平。
数讯sds vdc,可以帮助企业灵活地连接成为一个数字化业务所需的智能功能平台,为敏捷性和云计算的经济性与内部部署的it环境提供可靠性和安全性。
数讯云计算,掌握云计算核心技术,拥有完全自主知识产权
数讯云计算,核心研发团队自2014年就一直致力于云计算技术的研究和开发工作
对比所有的portal去看,不管是openstack还是原生的k8s,基本都是以运维视角出发的,不是一个对外提供业务的一个case。所以从使用者来看的话,是一件非常痛苦的事情,当时我们就决定把两个平台统一,在web上做一个完整的、基于用户自己界面的平台。
在那个时候,确定了数讯云平台和sdn的方向,当时主要是openstack和k8s。我们发现一个问题,k8s不是一个paas平台,只是解决了一个docker管理的问题。如果是小环境的话,用不用都无所谓,不一定非要搞sdn,包括openstack也一样,如果业务环境不是过于复杂的话,其实跑传统的vlan,只要控制量,没有广播风暴,没有任何问题。
但如果你的业务场景非常复杂,以前收纳在虚拟机,现在收纳在容器里,这种业务的出现,会对网络造成非常大的困境,不可能对每个线的业务去做策略。一旦出现业务迁移或trouble shooting的时候,后端运维人员是崩溃的,没法调。以前写个pbr,写个静态路由,最多是挂几个交换机路由。在云网络环境里完全不是这样,可能一个租户下面无数虚拟机,里面跑了无数不同的应用方式,所有流的走向又是乱七八糟的,这种情况下,如果用传统的方式,基本就不用做了,因为看不到头。所以要采用sdn的方式。
tungstenfabric(以下简称tf)的确非常优秀,但也有一些问题存在,完全支持ovsdb的交换机,对tf的兼容会更好一点。也不是说openflow不行,用流表的方式也能做,但那就比较折腾了。
数讯的openstack和k8s,就是底层通过tf的sdn技术支持线。当时2015年opencontrail时代的时候,k8s刚开放,我们提出要采用基于容器的方式,因为虚拟机的方式对运维、扩容、迁移有弊端的话,后面业务是很难有保证的。那个时候openstack也比较早期,基本上都是自己统一部署,和juniper networks联合开发的时候,把opencontrail放在一起部署。
另外,数讯作为数据中心运营商,提供的是传统的hosting,大家都在考虑上云的问题。在云计算中我们已经使用了sdn技术,非传统vlan的方式,那么用户上云的时候怎么接呢,不可能再开个vlan做个什么映射,比较困难。
还有,怎么把用户实际在机房里的一堆业务场景,跟云计算的overlay网络去连接,而不是以某个独立的服务去试。
这里就解决了vlan映射的问题,不可能为用户提供专线,还要改变他的vlan网络,这是不现实的,所以在这上面做了大量的二次开发。包括openstack和openshift,开源社区的版本都是单节点,到真正地应用到场景的话,最起码要保证多节点,社区版的东西要落到生产环境,包括和tf对接,还是有很多二次开发要做。
开发及调研中碰到的8类网络问题
这是在开发和调研中碰到的实际用例的问题,有些是我们自己的,有些是用户应用场景中的。
1、openstackneutron ovs 扩展差,稳定性低。neutron稳定性比较差,我们曾经实测过,开到2500个虚拟机会出现莫名其妙的抖动,导致全部崩溃,对于原生的neutron,我们还是比较谨慎的。
2、k8s的fannel&calcio并不完全适应user case场景及多region的设计。如果k8s只是实现单一业务,基本原生的flannel或calico都能解决,calico对于多数据中心多任务的方式是不提供支持的,calico是目前k8s开源环境使用最多的。
3、okd(openshift origin)的ovs能否与openstack互通存疑,vnf和cnf是否能共存未知。openshift虽然是有ovs,能不能和openstack互通是存疑的,最后验证下来也是不能通的,完全是两个体系。
4、虚拟机网络与容器网络如何进行二层互访,使得效率更高另外vnf和cnf是否能够共存,也是未知。为什么虚拟机要去访问容器在我们看来极其不合理,但在金融行业或电商行业,某些业务可以跑虚拟机,某些已经买了商业软件,或者有些用户自己有开发能力,已经把一部分东西放到容器里了。
以前我们在虚拟机开一堆负载均衡,但在容器里直接一个node无数port就解决了,包括很多注册机机制不能portal,总不能把网络做分段再做代理转接,他们觉得非常难,看有没有可能解决这个问题。我们最后试错下来,在最近解决了vnf和cnf在openstack虚拟机层面的互通问题,要用到管理网去做互通。
5、对于数据中心内的用户,如何使得云服务于传统的hosting及bms在一个网络平面内访问管理虚拟机网络与容器网络二层互访,在tf 4.0版本的时候是基于标签的方式,能用,但是用起来不方便。到现在5.1版本的时候,整个portal也没有把这个拉出来作为一个选项,每次都要去翻虚拟机和容器去做对应,这个操作比较麻烦,我们也试过做二次开发,比较累。如果有可能的话,把这两个东西放在一起,管理起来就会非常方便。
6、软件定义的fw、lb如何在跨场景中得到业务落地(特别是由其作为统一internet出口)。 软件定义的fw、lb如何在跨场景中业务落地大部分用户场景里,都是用商业软件,各种品牌都有,自己本身提供image,放到虚拟机都有自己的feature,怎么和tf互通,肯定是要做二次开发的,但目前看来也就tf有可能去做,其它的比较困难。
7、针对不同云厂商提供五花八门的vpc,如何进行统一接入管理vpc的问题,在我们的理解里,tf的vpc可以理解为现在国内sdnweb更合理,两段vpn建立隧道。至于你要管到公有云的虚拟机,好像不太可能。即使是给到你,可能最后也会放弃,光是版本迭代问题就没法解决。没人做这样的事情。好处是有portal,能够看到整个业务的实际情况。
8、各自为阵的网络如何能有效的进行运营及排障吐槽一下,tf确实解决了openstack网络拓展和稳定性问题,但对网卡有点挑,在一些特殊的应用场景里,比如跑vdi的idp协议,我们发现intel和broadcom的网卡不那么友善。
相比openstack,目前为止tf和openshift的对接难度更大一点。openshift开源的okd本身就有一些问题,另外只是把tf和openshift或k8s装在一起,简单应用看不出问题,但如果跑几个业务链,比如标签、应用、路由网关、业务编排等,整个流程走下去会有问题。
的确我们看下来,tf就像文档上面所说的,对openshift的支持,还是比其它开源软件或商业软件要好很多,至少还能看到用tf做二次开发的曙光。
关于服务链,如果能够和端口去做匹配,可能更好一点,不要干预整条网络的属性,在某些特定场景里面会比较复杂。
多云环境我们目前已经适配aws和azure,可以很好适配国际化企业实际的应用场景,并且对一些有vpc虚拟私有云通道的国内公有云也适配。取得这项进步,在业界还属于开创性的!
支持dpdk及smartnic我们实测过,在openstack默认的kernel环境下,达到安全厂商他们的软件标准,基本达不到,只有使用dpdk的方式才能达到标称值,但dpdk又是intel的专属,在实际场景中碰到了一些问题,有的应用能跑起来,有的就不行。所以,要使用dpdk方式的话,还是要根据自己的使用场景去看一下。
tf提供类似rest的api,所以即使自己要做cmp的话,去调用后端的参数,相对还是比较容易的,但针对api的文档有点乱。
到现在,我们做云计算是非常认真的,从2014年到现在一直在不断打磨,sds vdc云平台,所有的视角都是以用户实例去呈现:
把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分是支持方面。
以上,我从实际的应用场景,到开发当中遇到的各种情况,抛出了一些问题。
非常感谢大家!(演讲结束)