以下为转载,供有需要的朋友了解,主要涉及到的虚拟化中虚拟网络的问题,文中只是提到了大概的解决思路,并没有详细解释原理。
嘉宾介绍:
卫平青 中科云巢研发部门负责人
以下为分享实录:
自我介绍 首先很高兴给群里各位同行大拿做这次分享,我叫卫平青,是中科云巢研发部门的负责人,2014入行桌面云行业。中科云巢主打云办公,云教室,共享桌面三款产品,从服务器,终端,以及软件架构本身都填了不少坑,走了不少的路。
个人认为好产品本身的诞生,从工程性上来看其实就是填了多少个应该填的好坑,这里就跟大家分享一个使用Neutron网络虚拟化方面的填坑过程。
Neutron的引入 中科云巢整体桌面云管理系统是基于openstack的icehouse版本进行定制开发,所以很自然选择了neutron作为网络虚拟化的基础组件,一开始只管用,保证虚拟机能够上网可以了,渐渐就了解了一下原理。
关于Netrutron的掰扯 从服务器节点功能划分来说有两种网络节点,一种节点叫网络节点需要两个网卡(eth1,eth2)供Neutron使用,另一种节点叫计算节点需要一个网卡(eth1)。所有计算节点上的虚拟机流量通过eth1传输到网络节点中,网络节点再把数据通过eth2传输到物理网络的交换机上。
网络节点中包含openvswitch,openvswitch-agent,dhcp-agent, l3agent.
计算节点中包含openvswitch,openvswitch-agent.
Openvswitch+openswitch-agent实现了把虚拟机tap设备,eth1,eth2在虚拟链路中连接起来。
dhcp-agent, l3agent分别提供dhcp服务器,以及NAT路由服务。功能如下所示。
图1 Neutron原理
网络节点上虚拟链路如下所示:
注意一下br-tun, br-int, br-ex三个openvswitch虚拟交换机。
br-tun负责把eth1连接起来。
br-int 负责把dhcp端口,虚拟NAT路由LAN口,br-tun连接起来。
br-ex 负责把eth2,虚拟NAT路由的wan口连接起来。
计算节点上的链路
注意一下br-int,br-tun两个虚拟交换机,
br-int负责把虚拟机的tap设备,br-tun连接起来。
br-tun负责把eth1连接起来。
整体的虚拟链路示意图如下:
图当时是我自己做的,可能有点丑,大家将就这看一下,基于我的来举个例子,大家在脑海中过一下。
举个计算节点上链路例子。vm--->tap--->br-int(计算节点)--->br-tun(计算节点)--->eth1-->br-tun(网络节点)--->br-int(网络节点)--->虚拟NAT路由--->br-ex(网络节点)--->eth2。
NAT之殇(坑来了) 到目前为止NAT好像还挺好用,原理上看着也挺好的,但是到项目实际使用中挑战来了。一次是某客户那里采购了上网管控行为,需要监控流量从哪台确定的虚拟机出来的。一次是某客户有个软件要求虚拟机必须跟外部服务器在同一个vlan中的。经过产品侧的评估,虚拟网络组建中,桌面云跟服务器云很大不一样地方应该是要求虚拟机能以二层的方式接入某个屋里vlan中,不能使用NAT功能,以适应客户原先的网络规划。
二层直接接入的解决方案(填坑)
1.网络节点上eth2以(trunk/access)方式接入到客户物理网络中,并根据openvswitch手册修改br-ex上openflow流表规则,让数据包经过eth2时,进行vlan tag报头处理。
2.网络节点上br-ex,br-int直接连接起来(不经过虚拟NAT路由)。
3.虚拟链路中使用vlan tag与客户物理网络中vlan tag号保持一致。
4.目前为止,虚拟机可以直接桥接到客户的实际vlan中了。
Openvswitch手册地址:http://www.pica8.com/document/v2.3/html/ovs-commands-reference/#1081517.
一个小小的填坑经历,让大家见笑了。
分享完毕,谢谢大家阅读!
提问环节摘录
问1:用OpenStack的话也可以直接使用nova-network,为什么一定要neutron呢?
答1:都是机缘,我们选择openstack的时候是icehouse版本,当时neutron是默认的网络组件,就直接使用了,后来发现使用nova-network,后期方案中我们需要多加一组交换机。
问2:第二个问题:你们如何跟进openstack社区的最新发布?
答2:跟进社区没有,只是跟进有什么新功能,其实只是提供一些产品思路,其实底层原理明白了,社区的相同产品功能可以实现的,如果有有必要的话。
问3:你们这个架构中如何处理usb外设?有没有遇到坑?
答3: 桌面架构kvm+spice, usb外设方面有两个坑我比较有印象:1)速度比较慢,修改usbredir代码搞定 ,2)高速usb设备传输受限了网络带宽,网络不稳定直接影响usb外设使用的体验。目前技术上没有什么好办法,只能用方案规避,帮用户解决一下网络问题,如果可行的话。
问4:上项目上openstack怎么保证服务高可用性,所有服务都在一个节点?
答4:有HA方案,基于pacemaker自研了一套规则。openstack官网推荐的HA方案没有使用,因为我之前的从业经历有HA的经验,就硬上了。
问5:监控采用的什么?
答5:目前不监控虚机内部,只看服务器性能指标,方便告警。