本文所有相关资料 https://163.53.94.133/assets/uploads/files/cmp-key-shuxun.pdf
10年积累的成都网站制作、做网站经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先
网站制作后付款的网站建设流程，更有
平果免费网站建设让你可以放心的选择与我们合作。
上海数讯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，只要控制量，没有广播风暴，没有任何问题。
但如果你的业务场景非常复杂，以前收纳在虚拟机，现在收纳在容器里，这种业务的出现，会对网络造成非常大的困境，不可能对每个线的业务去做策略。一旦出现业务迁移或trouble shooting的时候，后端运维人员是崩溃的，没法调。以前写个PBR，写个静态路由，最多是挂几个交换机路由。在云网络环境里完全不是这样，可能一个租户下面无数虚拟机，里面跑了无数不同的应用方式，所有流的走向又是乱七八糟的，这种情况下，如果用传统的方式，基本就不用做了，因为看不到头。所以要采用SDN的方式。
Tungsten Fabric（以下简称TF）的确非常优秀，但也有一些问题存在，完全支持OVSDB的交换机，对TF的兼容会更好一点。也不是说Openflow不行，用流表的方式也能做，但那就比较折腾了。
数讯的底层Port，就是底层通过TF的SDN技术支持线。当时2015年OpenContrail时代的时候，K8s刚开放，我们提出要采用基于容器的方式，因为虚拟机的方式对运维、扩容、迁移有弊端的话，后面业务是很难有保证的。那个时候OpenStack也比较早期，基本上都是自己统一部署，和Juniper networks联合开发的时候，把OpenContrail放在一起部署。
另外，数讯作为数据中心运营商，提供的是传统的hosting，大家都在考虑上云的问题。在云计算中我们已经使用了SDN技术，非传统VLAN的方式，那么用户上云的时候怎么接呢，不可能再开个VLAN做个什么映射，比较困难。
还有，怎么把用户实际在机房里的一堆业务场景，跟云计算的overlay网络去连接，而不是以某个独立的服务去试。
这里就解决了VLAN映射的问题，不可能为用户提供专线，还要改变他的VLAN网络，这是不现实的，所以在这上面做了大量的二次开发。包括OpenStack和OpenShift，开源社区的版本都是单节点，到真正地应用到场景的话，最起码要保证多节点，社区版的东西要落到生产环境，包括和TF对接，还是有很多二次开发要做。
这是在开发和调研中碰到的实际用例的问题，有些是我们自己的，有些是用户应用场景中的。
Neutron稳定性比较差，我们曾经实测过，开到2500个虚拟机会出现莫名其妙的抖动，导致全部崩溃，对于原生的Neutron，我们还是比较谨慎的。
如果K8s只是实现单一业务，基本原生的Flannel或Calico都能解决，Calico对于多数据中心多任务的方式是不提供支持的，Calico是目前K8s开源环境使用最多的。
OpenShift虽然是有OVS，能不能和OpenStack互通是存疑的，最后验证下来也是不能通的，完全是两个体系。
另外VNF和CNF是否能够共存，也是未知。为什么虚拟机要去访问容器？在我们看来极其不合理，但在金融行业或电商行业，某些业务可以跑虚拟机，某些已经买了商业软件，或者有些用户自己有开发能力，已经把一部分东西放到容器里了。
以前我们在虚拟机开一堆负载均衡，但在容器里直接一个Node无数port就解决了，包括很多注册机机制不能portal，总不能把网络做分段再做代理转接，他们觉得非常难，看有没有可能解决这个问题。我们最后试错下来，在最近解决了VNF和CNF在OpenStack虚拟机层面的互通问题，要用到管理网去做互通。
虚拟机网络与容器网络二层互访，在TF 4.0版本的时候是基于标签的方式，能用，但是用起来不方便。到现在5.1版本的时候，整个Portal也没有把这个拉出来作为一个选项，每次都要去翻虚拟机和容器去做对应，这个操作比较麻烦，我们也试过做二次开发，比较累。如果有可能的话，把这两个东西放在一起，管理起来就会非常方便。
软件定义的FW、LB如何在跨场景中业务落地？大部分用户场景里，都是用商业软件，各种品牌都有，自己本身提供image，放到虚拟机都有自己的feature，怎么和TF互通，肯定是要做二次开发的，但目前看来也就TF有可能去做，其它的比较困难。
VPC的问题，在我们的理解里，TF的VPC可以理解为现在国内SDN web更合理，两段***建立隧道。至于你要管到公有云的虚拟机，好像不太可能。即使是给到你，可能最后也会放弃，光是版本迭代问题就没法解决。没人做这样的事情。好处是有Portal，能够看到整个业务的实际情况。
吐槽一下，TF确实解决了OpenStack网络拓展和稳定性问题，但对网卡有点挑，在一些特殊的应用场景里，比如跑VDI的IDP协议，我们发现Intel和Broadcom的网卡不那么友善。
相比OpenStack，目前为止TF和OpenShift的对接难度更大一点。OpenShift开源的OKD本身就有一些问题，另外只是把TF和OpenShift或K8s装在一起，简单应用看不出问题，但如果跑几个业务链，比如标签、应用、路由网关、业务编排等，整个流程走下去会有问题。
的确我们看下来，TF就像文档上面所说的，对OpenShift的支持，还是比其它开源软件或商业软件要好很多，至少还能看到用TF做二次开发的曙光。
关于服务链，如果能够和端口去做匹配，可能更好一点，不要干预整条网络的属性，在某些特定场景里面会比较复杂。
多云环境我们目前适配下来，只有AWS和Azure是可以的，不过还是根据实际的应用场景出发，也没必要把所有的公有云平台对接一遍，业务也没有那么复杂。
支持DPDK及smartNIC我们实测过，在OpenStack默认的kernel环境下，达到安全厂商他们的软件标准，基本达不到，只有使用DPDK的方式才能达到标称值，但DPDK又是Intel的专属，在实际场景中碰到了一些问题，有的应用能跑起来，有的就不行。所以，要使用DPDK方式的话，还是要根据自己的使用场景去看一下。
TF提供类似REST的API，所以即使自己要做CMP的话，去调用后端的参数，相对还是比较容易的，但针对API的文档有点乱。
到现在，我们做云计算是非常认真的，从2014年到现在一直在不断打磨自己的平台，所有的视角都是以用户实例去呈现，包括把TF后端的API腾挪到前端，针对某个租户他就能根据自己的策略去调。进入CMP的时代，如果一个应用场景在15分钟内开不起来的话，那它就失败了，更不要说借助第三方外力。把很多权限都开放给用户。
我们的PaaS后端是OpenShift，基于PaaS平台的所有业务都在前端重做，包括TF针对OpenShift的功能，都放在前端，包括TF内部都可以监控，不用非常原始的SNMP的方式做采集，完全不需要。
目前为止，数讯的平台做到了这个程度。选择TF是因为协议相对标准，BGP ***就能解决，我比较抵触私有协议，某些友商总想搞个大一统，最后也不太可能，还是开放式大家比较能接受。
谈到VXLAN的问题，实际用下来，如果用kernel方式，如果量很大损耗还是很大，特别针对VXLAN没有做特别优化的交换机或网卡，直接性能损失大概在30%左右。
从整个TF去看的话，基本上把不同的平台、不同的网络特性都统一管理起来了，只是容器和虚拟机还是有一定手动的工作量，如果TF把这个问题解决掉会更好。另外，TF在OpenStack和OpenShift认证机制上不太一致。
这几年比较痛苦的是支持比较少，不管开源社区还是官方，主要侧重于安装，有一部分trouble shooting，但针对于实际的应用场景部署相对比较缺失。做云计算不是开虚拟机，用不用OpenStack无所谓，KVM就解决了。所以说云计算不是虚拟化，它有一定的业务逻辑在里面，意味着平台要能对实际落地用户的业务提供很多支持。
我们应用TF比较早，从3.2版本就开始搞，4.0版本正式对接。我相信如果有自己的业务逻辑，有一定的开发能力，基于TF能打造出属于自己的好的产品，TF可编程型比较强，通用性也比较强。满分100的话，我打80分，剩下的20分是支持方面。
以上，我从实际的应用场景，到开发当中遇到的各种情况，抛出了一些问题。
非常感谢大家！
关于Tungsten Fabric：
Tungsten Fabric项目是一个开源项目协议，它基于标准协议开发，并且提供网络虚拟化和网络安全所必需的所有组件。项目的组件包括：SDN控制器，虚拟路由器，分析引擎，北向API的发布，硬件集成功能，云编排软件和广泛的REST API。
关于TF中文社区：
TF中文社区由中国的一群关注和热爱SDN的志愿者自发发起，有技术老鸟，市场老炮，也有行业专家，资深用户。将作为连接社区与中国的桥梁，传播资讯，提交问题，组织活动，联合一切对多云互联网络有兴趣的力量，切实解决云网络建设过程中遇到的问题。
关注微信：TF中文社区
另外有需要云服务器可以了解下创新互联scvps.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
新闻名称：TungstenFabric：连接CMP的金钥匙丨TFM-创新互联
文章分享：
http://cdkjz.cn/article/edehp.html
