Tungsten Fabric：连接CMP的金钥匙( 三 ) “我们找了差不多10个S

　　这里就解决了VLAN映射的问题,不可能为用户提供专线,还要改变他的VLAN网络,这是不现实的,所以在这上面做了大量的二次开发。包括OpenStack和OpenShift,开源社区的版本都是单节点,到真正地应用到场景的话,最起码要保证多节点,社区版的东西要落到生产环境,包括和Tungsten Fabric对接,还是有很多二次开发要做。

Tungsten Fabric：连接CMP的金钥匙。

----Tungsten Fabric：连接CMP的金钥匙//----

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

　　Neutron稳定性比较差,我们曾经实测过,开到2500个虚拟机会出现莫名其妙的抖动,导致全部崩溃,对于原生的Neutron,我们还是比较谨慎的。

　　如果K8s只是实现单一业务,基本原生的Flannel或Calico都能解决,Calico对于多数据中心多任务的方式是不提供支持的,Calico是目前K8s开源环境使用最多的。

　　OpenShift虽然是有OVS,能不能和OpenStack互通是存疑的,最后验证下来也是不能通的,完全是两个体系。

　　另外VNF和CNF是否能够共存,也是未知。为什么虚拟机要去访问容器?在我们看来极其不合理,但在金融行业或电商行业,某些业务可以跑虚拟机,某些已经买了商业软件,或者有些用户自己有开发能力,已经把一部分东西放到容器里了。

　　以前我们在虚拟机开一堆负载均衡,但在容器里直接一个Node无数port就解决了,包括很多注册机机制不能portal,总不能把网络做分段再做代理转接,他们觉得非常难,看有没有可能解决这个问题。我们最后试错下来,在最近解决了VNF和CNF在OpenStack虚拟机层面的互通问题,要用到管理网去做互通。

　　虚拟机网络与容器网络二层互访,在Tungsten Fabric 4.0版本的时候是基于标签的方式,能用,但是用起来不方便。到现在5.1版本的时候,整个Portal也没有把这个拉出来作为一个选项,每次都要去翻虚拟机和容器去做对应,这个操作比较麻烦,我们也试过做二次开发,比较累。如果有可能的话,把这两个东西放在一起,管理起来就会非常方便。

　　软件定义的FW、LB如何在跨场景中业务落地?大部分用户场景里,都是用商业软件,各种品牌都有,自己本身提供image,放到虚拟机都有自己的feature,怎么和Tungsten Fabric互通,肯定是要做二次开发的,但目前看来也就Tungsten Fabric有可能去做,其它的比较困难。

　　VPC的问题,在我们的理解里,Tungsten Fabric的VPC可以理解为现在国内SDN web更合理,两段VPN建立隧道。至于你要管到公有云的虚拟机,好像不太可能。即使是给到你,可能最后也会放弃,光是版本迭代问题就没法解决。没人做这样的事情。好处是有Portal,能够看到整个业务的实际情况。