金钥匙对话

TungstenFabric：连接CMP的金钥匙

作者:钱瑜

“我们发现了差不多10种SDN技术，从商用到开源，再到国内小规模应用。”

“相比所有门户，无论是OpenStack还是原生K8s，基本都是从运维的角度出发。这不是一个向外界提供业务的案例。”

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

“在云网环境下，一个租户下面可能有无数个虚拟机，里面运行着无数种不同的应用方式，所有流的方向都乱七八糟。”

“虽然OpenShift有OVS，但它是否能与OpenStack通信还是个疑问。最后，无法考证。完全是两种制度。”

“在CMP时代，一个应用场景如果不能在15分钟内打开就会失败，更不用说借助第三方外力了。”

本文整理了上海数字报CIO钱瑜在TF中文社区“2020FirstMeetup”上的演讲，分享了早期云网在实际应用和二次开发中的经验和教训。作为XXX的合作伙伴，由主办方和发言人审核并授权发布。

1月7日，TF中文社区“2020FirstMeetup”活动，钨织的技术R&D和一线用户，关注多云互联的从业者，开源SDN的爱好者们相互交流，提出建议。现场气氛热烈，精彩内容不断。gsten面料在中国的广泛应用越来越真实。

请在微信官方账号“TF华人社区”后台点击“会议活动-MeetingUp”领取本次演讲及TF华人社区“2020第一次MeetingUp”信息。

上海数字新闻首席信息官钱瑜

上海数讯是一家专注于传统数据中心业务的公司。为什么转行做云计算？2011年以后，整个数据中心行业越来越像房地产，数据中心这类业务复制性强，竞争激烈。到了2013年，一些新技术出来了，包括OpenStack的爆发式增长，于是我在2014年决定做云计算。

一开始就定义为多平台。从实际应用场景来看，并不意味着虚拟机和容器哪个更好。它们应用于不同的场景，不存在谁取代谁的问题。当我们想做两个平台的时候，又遇到了一个尴尬的问题。虚拟机网络和容器网络完全是两码事。

我们发现中间差不多有10个SDN技术，从商用到开源，再到国内小规模应用。那时候钨Fabric还叫OpenContrail，当时的版本只支持OpenStack。

CMP是近几年提出来的，但在一开始，就已经有了CMP的想法。

对比所有门户，无论是OpenStack还是原生K8s，基本都是从运维的角度出发，而不是对外提供业务的一个案例。所以从用户的角度来说，是一件很痛苦的事情。当时我们决定把两个平台统一起来，在Web上做一个基于用户自己界面的完整平台。

当时就确定了数字云平台和SDN的方向。当时主要是OpenStack和K8s。我们发现了一个问题。K8s不是PaaS平台，只是解决一个docker管理问题。如果是小环境，用不用无所谓。不一定是SDN，包括OpenStack。如果商业环境不是太复杂的话，其实如果你经营一个传统的VLAN，只要控制好音量，就没有广播风暴，没有问题。

3月份的华人社区聚会将重点关注钨织物和K8s的整合。重量级嘉宾将分享钨织物和K8s的部署和实践，详细演示 *** 作流程，解答所有关于钨织物和K8s的问题。关注“TF华人社区”微信官方账号，在后台点击“会议活动-Meetup”即可参与。

但是，如果你的业务场景非常复杂，以前存储在虚拟机中，现在存储在容器中。这种业务的出现会给网络造成很大的困难，无法针对每条业务线制定策略。一旦出现业务迁移或故障排查，后台运维人员就会崩溃，无法调整。以前写个PBR，写个静态路由，最多挂几个交换机路由。在云网环境下，完全不是这样。可能一个租户下面有无数个虚拟机，其中有无数种不同的应用方式，所有流的方向都乱七八糟。这种情况下，如果用传统的方式，基本不用做，因为看不到头。因此，应该采用SDN。

Tunten面料确实很优秀，但是有一些问题。完全支持OVSDB的交换机将与Tuntenfabric更加兼容。不是说Openflow不行，流量表可以，不过那比较折腾。

数据的底层端口是通过钨结构的SDN技术支持线。当时2015年OpenContrail时代，K8s刚刚开放，我们提出采用基于容器的方式，因为如果虚拟机的方式在运维、扩展、迁移等方面有劣势，后面的业务几乎无法保证。当时OpenStack比较早，基本都是自己部署。与Junipernetworks联合开发时，一起部署了OpenContrail。

另外，作为数据中心运营商，Datacom提供传统托管，大家都在考虑上云。在云计算中，我们已经使用了SDN技术，这不是传统的VLAN方法。那么用户如何连接到云呢？不可能为任何映射打开另一个VLAN，这更困难。

还有，如何把用户在机房实际拥有的一堆业务场景和云计算的叠加网络连接起来，而不是用一个独立的服务去尝试。

在这里解决了VLAN测绘的问题，不可能为用户提供专线，改变他的VLAN网络也不现实，所以在上面做了大量的二次开发。包括OpenStack和OpenShift，开源社区的版本都是单节点的。如果真的应用到场景中，最起码必须是多节点的。社区版要落到生产环境还有很多二次开发要做，包括和钨织对接。

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

中子的稳定性相对较差。我们测过，开到2500虚机会出现莫名其妙的抖动，导致全部死机。我们仍然对原生中子持谨慎态度。

如果K8s只实现单一业务，基本的原生法兰绒或者印花布就可以解决。Calico不支持多数据中心多任务处理。Calico是目前应用最广泛的K8s开源环境。

OpenShift虽然有OVS，但能否与OpenStack通信还是存疑，最后无法验证。完全是两个系统。

此外，VNF和CNF能否共存还是未知数。虚拟机为什么要访问容器？在我们看来是极不合理的，但是在金融行业或者电子商务行业，有的商家可以运行虚拟机，有的已经买了商业软件，或者有的用户有自己的开发能力，已经把一些东西装进了容器。

以前我们在虚拟机里面启动了一堆负载均衡，但是直接在容器里面通过单个节点和无数个端口来解决，包括很多注册机制不能门户化，代理转移之前网络不能分段。他们发现这很难，所以让我们看看是否有可能解决这个问题。最后，我们最近尝试在OpenStack虚拟机级别解决VNF和CNF之间的互 *** 作性问题，我们需要使用管理网络来实现互 *** 作性。

虚拟机和容器网络在第二层进行互访。在钨织物版本4.0中，它是基于标签的。可以用，但是用起来不方便。到5.1版本的时候，整个门户都没有把这个拉出来作为选项。每次，我们都必须通过虚拟机和容器来进行通信。这个 *** 作比较麻烦，我们也尝试过做二次开发，比较累。如果可能的话，把这两件事放在一起管理会非常方便。

软件定义的FW和LB如何跨场景工作？在大多数用户场景下，使用的都是商业软件，各种品牌都有。他们提供自己的映像，并将其放入具有自己功能的虚拟机中。如何与钨织物沟通必须重新开发，但目前看来钨织物有可能做到，其他的难度更大。

VPC问题，在我们的理解中，钨织的VPC可以理解为目前国内的SDNweb更合理，建立两条VPN隧道。至于你想在公有云中管理的虚拟机，似乎不太可能。即使给了你，最终也可能放弃，单靠版本迭代问题是解决不了的。没有人做这样的事。好处是有一个入口可以看到整个业务的实际情况。

掖着掖着，钨Fabric确实解决了OpenStack网络扩展和稳定性的问题，但是对网卡有点挑剔。在一些特殊的应用场景下，比如运行VDI的IDP协议，我们发现Intel和Broadcom的网卡并不那么友好。

与OpenStack相比，到目前为止，钨Fabric与OpenShift的对接要稍微困难一些。OpenShift的开源OKD本身也有一些问题。此外，它只安装钨织物与OpenShift或K8s。简单的应用并不能说明什么问题，但是如果你运行几个业务链，比如标签、应用、路由网关、业务编排等。，整个过程都会有问题。

3月份的华人社区聚会将重点关注钨织物和K8s的整合。重量级嘉宾将分享钨织物和K8s的部署和实践，详细演示 *** 作流程，解答所有关于钨织物和K8s的问题。关注“TF华人社区”微信官方账号，在后台点击“会议活动-Meetup”即可参与。

的确，正如文件中所说，钨织物对OpenShift的支持比其他开源软件或商业软件要好得多，至少我们可以看到用钨织物进行二次开发的曙光。

至于服务链，如果能和端口匹配可能会更好。不要干扰全网的属性，在一些特定场景下会比较复杂。

多云的环境。我们目前正在适应它。只有AWS和Azure是可能的。但根据实际应用场景，并不需要连接所有的公有云平台，业务也没有那么复杂。

我们已经测量了对DPDK和smartNIC的支持。在OpenStack默认的内核环境下，无法达到安全厂商的软件标准。只有使用DPDK才能达到标称值。但是DPDK是Intel独占的，在实际场景中遇到了一些问题。有些应用程序可以运行，有些则不能。所以要用DPDK，还是要根据自己的使用场景来看。

钨Fabric提供了类似REST的API，所以即使想自己做CMP，调用后端参数也相对容易，但是API的文档有点乱。

到现在为止，我们对云计算还是很认真的。从2014年到现在，我们一直在不断打磨自己的平台。所有的视角都是通过用户实例来呈现的，包括把钨Fabric后端的API移到前端。对于某个租客，他可以根据自己的策略进行调整。在CMP时代，一个应用场景如果不能在15分钟内打开，就会失败，更不用说借助第三方了。向用户开放许多权限。

我们的PaaS后端是OpenShift，所有基于PaaS平台的服务都在前端重做，包括钨Fabric对于OpenShift的功能都放在前端，包括钨Fabric内部都可以监控，不用通过非常原始的SNMP收集，完全没有必要。

到目前为止，数据通信的平台已经达到了这个水平。选择钨Fabric是因为协议比较标准，BGPVPN可以解决。我和私有协议冲突，有些朋友总想搞个大统一。最后不太可能，还是对大家开放。

说到VXLAN的问题，实际 *** 作中，如果使用内核模式，量大的话损失还是会很大，尤其是对于没有专门针对VXLAN进行优化的交换机或者网卡，直接的性能损失在30%左右。

从整个钨Fabric来看，基本上是统一管理不同的平台和不同的网络特性，但是对于容器和虚拟机还是有一定的人工工作量的。如果钨织物解决了这个问题就更好了。此外，钨结构与OpenStack和OpenShift认证机制不一致。

这几年痛苦的是支持的少了。无论开源社区还是官方，都是以安装为主，有一些故障排除，但针对实际应用场景的部署相对欠缺。云计算不是开一个虚拟机。用不用OpenStack并不重要。KVM会解决的。所以云计算不是虚拟化，它有一定的业务逻辑在里面，也就是说平台要能为实际落地用户的业务提供很多支持。

我们应用钨织物比较早，从3.2版本开始，4.0版本正式对接。我相信，如果我有自己的商业逻辑，有一定的开发能力，我可以创造出自己的基于钨丝面料的好产品，可编程，多用途。如果100分，我打80分，剩下的20分是支持。

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

非常感谢大家！

请在微信官方账号“TF华人社区”后台点击“会议活动-MeetingUp”参与本次演讲及TF华人社区“2020第一次MeetingUp”信息。