数讯云VDC：多云管理的金钥匙

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互通是存疑的，最后验证下来也是不能通的，完全是两个体系。

（编辑：52刷机网）

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