“数讯云VDC: 多云管理的金钥匙”

以下稿件选自数信新闻云事业部总经理钱誉先生的演讲实录，叙述了数年来数信vdc开发的创立历史和成果。 数字云vdc为应用场景众多、复杂的公司做好技术落地和服务管理。 演讲带来了开源sdn的技术风暴。 / br// h /

上海数字新闻是一家一直流传的以数据中心业务为主的企业，为什么会转向云计算？ 年以来，整个数据中心领域越来越像房地产，数据中心这类业务的可复制性越来越高，竞争也越来越激烈。 到了2010年，由于出现了包括openstack爆炸性增长在内的新技术，2010年开始决定云计算这一事件。

当初的定义是多平台。 从实际的APP场景来看，并不是虚拟机和容器哪个好。 这两个APP在不同的场合使用，没有谁代替谁使用的问题。 在尝试搭建两个平台的时候，又遇到了不自然的问题。 虚拟机的互联网和集装箱的互联网是完全不同的。

途中，从商用的到开源的，从国产的小范围使用的，找了10个左右的sdn技术。 那个时候，Tungsten结构也被称为开放控制。 当时的版本还只支持开放堆栈。

虽然cmp是在这几年被提出来的，但是最初制作的时候，就已经有了cmp的理念。

数字sds vdc:一个强大的公司级混合云平台，为公司的云功能打开新的层面。

数字sdsvdc灵活地连接到企业数字业务所需的智能功能平台，为敏捷、云计算的经济性和内部部署的it环境提供可靠性和安全性

掌握云计算的核心技术，拥有完整的自主知识产权

云计算表示，核心研发团队多年来一直致力于云计算技术的研究与开发

再去看所有门户网站，无论是openstack还是原生k8s，基本上都不是从运维的角度出发，对外提供业务的case。 所以在招聘者看来，这是一个很痛苦的事件，当时我们决定统一两个平台，在网上建立一个完美的基于顾客独特界面的平台。

/ br// h /

那个时候，明确了数字云平台和sdn的方向性。 当时openstack和k8s是第一。 发现了某个问题。 k8s不是paas平台，它只是解决了docker管理的问题。 只要是小环境，使用和不使用都没关系。 并不一定必须做sdn。 包括openstack在内也是如此。 如果业务环境太多不复杂的话，实际上即使运行自古以来流传的vlan，只要控制了流量，没有广播风暴，就没有任何问题。

但是，如果你的业务场景非常多、复杂，以前存放在虚拟机里，现在存放在集装箱里，这样的业务的出现，会给互联网带来非常大的困境，无法为各条线的业务制定战略。 如果发生业务迁移或故障诊断，后端承运人将崩溃，无法进行调整。 以前写pbr，写静态路由，最多挂几个交换路由。 在云互联网环境中完全不是这样。 一个租户下面有无数虚拟机，里面有无数不同的应用方法在跑，整个流程可能又一塌糊涂了。 那种情况下，如果使用以前传下来的方法，就几乎没有必要做。 因为看不见头。 所以使用sdn的方法。

tungstenfabric (以下简称tf )确实很好，但有点问题。 完全支持ovsdb的交换机与tf具有更高的兼容性。 并不是不能说openflow不行，也可以用流表的方法，但是那样比较辛苦。

/ br// h /

数量的openstack和k8s是基础通过tf的sdn技术支持线路。 当时opencontrail时代的时候，k8s刚开放，提出使用基于集装箱的方法。 因为如果虚拟机的方法在运输、扩展和迁移方面存在缺陷，则以后的业务将难以保证。 那个时候openstack也是比较初期的，基本上是自己统一导入的。 在与juniper networks共同开发时，我们一起部署了opencontrail。

另外，数字信息作为数据中心运营商，提供了以前流传下来的hosting，考虑了云上的问题。 云计算已经采用了sdn技术，而不是vlan以前流传的方法。 那么，当客户上传到云中时，如何进行连接呢？ 不能打开vlan进行任何映射。 很难。

此外，还有将客户实际在机房的许多业务场景连接到云计算overlay互联网的方法。 不是独立的服务。

这里处理了vlan映射的问题。 不能给顾客提供专线。 另外，改变vlan互联网是不现实的，所以在此基础上进行了大量的二次开发。 包括openstack和openshift在内，开源社区的版本都是单节点，要真正应用于场景，最少也要确保多节点，社区版的是生产环境

开发和调查中遇到的8种互联网问题

这是在开发和调查中遇到的实际用例问题，一部分是我们自己的，一部分是客户APP场景的。

1、openstackneutron ovs的扩展性差，稳定性低。 neutron的稳定性很差，甚至达到2500个虚拟机都曾实测过会产生莫名的抖动，导致所有崩溃。 关于母语neutron，我们正在仔细研究。

2/S2// S2// S2 /，k8s的漏斗和地图； calcio不完全支持user case场景和多区域设计。 如果k8s只实现单一业务，则可以使用基本本机flannel或calico进行处理。 calico不支持目前k8s开源环境中使用最多的多数据中心多任务处理方法。

3，okd (开放式堆栈)的ovs是否能够与开放式堆栈互通，vnf和cnf是否能够共存尚不清楚。 openshift虽然有ovs，但是否可以与openstack进行互操作还是值得怀疑的。 最后验证也不通。 完全是双人系。

4，虚拟机互联网和集装箱互联网如何进行两层互访，效率会提高吗？ 另外，vnf和cnf是否能够共存也不清楚。 为什么虚拟机要访问集装箱？ 虽然在我们看来极其不合理，但在金融领域和电子商务领域，有些业务可以让虚拟机运行。 一部分已经购买了商业软件。 或者，一些顾客有自己的开发能力，把一些东西放在容器里。

以前，我们在虚拟机上进行了很多负载平衡，但是我们直接在容器中放入节点的无数端口进行处理。 他们觉得非常困难，包括许多注册机的结构不能入口，不能将互联网分段后进行代理转发。 让我们看看能不能处理这个问题。 我们最后试错了一下，最近处理了vnf和cnf在openstack虚拟机层面的互通问题，并使用管理网络进行互通。

5，对于数据中心中的客户，云服务如何在互联网的平面上访问和管理以前流传的主机和bms？ 虚拟机互联网和集装箱互联网的双层互访在tf 4.0版本时可以通过基于标签的方法使用，但很难使用。 直到现在5.1版的时候，整个门户网站才引出这个做出一个选择。 每次都要翻虚拟机和集装箱来应对。 这个操作很麻烦。 我们也尝试了二次开发，但是累了。 如果可能的话，把这两个东西放在一起，管理起来会非常方便。

6，软件定义的前锋、lb如何在交叉场景中获得业务落地？ (特别是作为统一互联网出口。 软件中定义的fw、lb如何在交叉场景下落地业务？ 在大多数客户的场景中，我们都使用了商业软件。 有各种各样的企业品牌。 自己提供image或放入虚拟机有自己的功能。 如何与tf互通，一定要进行二次开发，但目前只有tf有可能做到，其他方面似乎很难。

7，与不同云厂商提供的多种多样的vpc进行比较，如何进行统一访问管理？ vpc的问题，我们的理解是，tf的vpc可以理解为现在国内的sdnweb更合理，两级vpn建立了隧道。 关于要管理在公共云中的虚拟机，似乎不太可能。 就算给你了，最后也有可能放弃。 光靠版本迭代问题是无法解决的。 没有人发生这样的事件。 利润是有门户的，能够看到整个业务的现实的状况。

8，每一个阵列的互联网如何能够比较有效地运营和排除故障？ 吐槽一下，tf确实处理了openstack的互联网扩展和稳定性问题，但是对于网卡来说有点挑，有点特殊的应用场景，比如跑vdi的idp协议，intel和broadd

/ br// h// br// h /

比起openstack，迄今为止tf和openshift的对接更难。 openshift的开源okd本身有点问题。 另外，只是tf和openshift、k8s的组合，用简单的APP是不知道问题的，但是如果你跑几个业务链，比如标签、APP、路由网关、业务编排等，整个过程就会有问题。

确实，正如文档上面所说，tf对openshift的支持远胜于其他开源软件和商业软件，至少也可以看到使用tf进行二次开发的希望。

关于服务链，如果能与端口匹配，也许会更好。 不要介入整个互联网的属性。 在特定的场景中，会变得更加复杂。

雾霾环境目前符合aws和azure，能够很好地适应国际化公司的实际APP场景，同时也符合拥有vpc虚拟私有云通道的国内公共云。 取得了这个进步，在业界是独创的！

支持dpdk和智能网卡。 在openstack的默认kernel环境中，几乎无法达到安全制造商的软件标准。 虽然只有采用dpdk的方法才能达到标称值，但dpdk是intel的专属，在实际场景中会出现一点问题，根据APP的不同，有时会跑，有时也不会跑。 所以，要采用dpdk法，还是要结合自己的招聘场景来看。

因为tf提供了类似rest的api，所以如果自己要做cmp的话，去调用后端的参数比较容易，但是比较api的文档有点混乱。

/ br// h /

迄今为止，我们一直在认真致力于云计算。 从去年开始到现在不断地磨练。 sds vdc云平台的所有视点在客户实例中均为 :

将tf后端的api移动到前端。

所有客户都可以根据自己的战略进行调整。

进入雾霾管理cmp时代，一个APP场景必须在15分钟内打开才能失败，更不要说借助了第三者的外力。

向客户开放更多权限。

/ br// h /

我们的paas后端是openshift，所有基于paas平台的业务都在前端重做。 包括比较tf和openshift的功能在内，可以放置在前端，包括tf内部进行监视。 即使不用非常原始的snmp方法进行采集，也完全没有必要。

/ br// h /

到目前为止，数字信息的平台已经到了这个程度。 之所以选择tf，是因为协议相对标准，bgp vpn可以处理。 我抵制私有协议，有些友商总是试图大一统，但最后不可能。 还是开放的，大家都能接受。

关于vxlan的问题，实际使用后，如果使用kernel方式，量大的话损失还是很大的，特别是与没有特别针对vxlan进行优化的开关和网卡相比，直接性能损失约为30%左右。

从整个tf来看，基本上统一管理着不同的平台、不同的互联网特征。 不过，集装箱和虚拟机仍有一定的手动工作量。 如果tf能帮我处理这个问题就更好了。 另外，tf在openstack和openshift的认证机制上不太一致。

这几年很痛苦的是支持太少。 开源社区和官方都以安装为重点，有些trouble shooting，但与实际的APP场景部署相比存在不足。 搞云计算不是运行虚拟机，和是否使用开放堆栈无关。 kvm会处理的。 云计算不是虚拟化，而是嵌入了业务逻辑，因此平台实际上必须能够为您的业务提供更多支持。

我们应用tf很早，从3.2版开始，4.0版正式对接。 如果有自己的商业逻辑，有一定的开发能力，能够基于tf制作出属于自己的好产品，我相信tf是可以编程的，通用性也很高。 100分满分的话，我就打80分。 剩下的20分是支持方面。

以上，从实际的应用场景，到开发中遇到的各种情况，都提出了一点问题。

谢谢你！ (演讲结束)