频道栏目
首页 > 资讯 > 虚拟机 > 正文

VLANawareVM引发的问题和解决方法

18-05-25        来源:[db:作者]  
收藏   我要投稿

VM能够发送和接收带有VLAN Tag的报文,这种情况叫VLAN aware VM。一个可以VLAN aware 的VM,意味着它可以接入多个Network(VLAN),如下图所示。

在Neutron模型中并没有VM的概念,而是以Port指代。我们先这样简单的理解port,Port是VM的虚拟网口。在没有引入Trunk Networking特性之前,Neutron的模型设计中有这样的约束:一个Port只能属于一个Network。假设一个VM只有一个Port,如果想让VM具备VLAN aware特性,这就意味着这个Port必须要属于多个network,

这与Neutron的约束是矛盾的,如下图:

那么这个问题怎样解决呢?这里先引入几种不太合适的方案,以此引出TrunkNetworking的设计。一 一个VM多个Port一个VM具有多个Port,这个很正常,而且这个方案还不打破Neutron原来的模型和实现方案。如下图:

这个方案几乎完美,但是如果考虑到这样的需求:一个VM需要对接到几百个Network,那么一个VM就需要几百个Port,也就是说需要几百个虚拟网卡,这是不现实的。

二 一个Port对应多个Network

既然需要那么多network,那么我们可以修改一下模型,就让一个Port对应多个Network,而且将VM的虚拟网口(port)设置为“Trunk”模式。如下图所示:

这个方案表面上看没问题,但是还是要考虑具体的实现模型。如果实现模型不改变,还是有一点问题,如下图所示。

计算节点的实现模型中涉及内外VLAN的转换。我们假设这个计算节点中,一开始只有VM1、VM2两个虚拟机。这两个虚拟机的内外VLAN ID如下表:

如果我们不考虑VLAN aware VM特性,这一切都是正常的。内部VLAN只会在Host内局部有效,br-int会保证这些内部VLAN ID不冲突。此时,如果一个租户创建一个虚拟机VM3,他要求这个VM是VLAN aware的,并且要求这个aware的VLAN ID是:10、11。这样VLAN ID=10就与VM1的内部VLAN ID冲突了,而且这个冲突还非常严重。

1 冲突无法避免:租户并不知道计算节点的内部实现,并不知道他选择的VLAN ID冲突了。而且就算知道了,也可能没办法,他就是需要这个VLAN ID,你说怎么办。

2 冲突难以解决:租户VLAN ID不能更改,只能修改VM1的内部VLAN了,这个修改好像不太可取。

三 VLAN透传

出于各种各样的原因,OVS(Open vSwitch)就不支持VLAN透传特性。Openstack对OVS有很强的依赖性,OVS如果不支持VLAN透传特性,那意味着Neutron试图通过VLAN透传方案解决VLAN aware VM的问题基本宣告失败。

相关TAG标签
上一篇:大数据Hadoop基础MapReduce详解
下一篇:如何在CentOS7系统下修改数据库的编码?
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站