OpenvSwitch 是一个高质量的、多层虚拟交换机,使用开源Apache 2.0许可协议。它的目的是让大规模网络自动化可以通过编程扩展,同时仍然支持标准的管理接口和协议(例如NetFlow, sFlow, SPAN, RSPAN, CLI, LACP, 802.1ag)。此外,它被设计位支持跨越多个物理服务器的分布式环境,类似于VMware的vNetwork分布式vswitch或Cisco Nexus 1000 V。
本文根据openvswitch官网openvswitch.org提供的文档,以及其他相关资料进行汇总。
open vswitch整体概述:
> Apache 2.0协议。
> 纯软件多层虚拟化交换机。
>支持openflow协议
>支持多种Hypervisor(XEN、KVM等主流Hypervisor)
>支持以下特性
* Standard 802.1Q VLAN model with trunk and access ports * NIC bonding with or without LACP on upstream switch * NetFlow, sFlow(R), and mirroring for increased visibility * QoS (Quality of Service) configuration, plus policing * GRE, GRE over IPSEC, VXLAN, and LISP tunneling * 802.1ag connectivity fault management * OpenFlow 1.0 plus numerous extensions * Transactional configuration database with C and Python bindings * High-performance forwarding using a Linux kernel module
这么介绍,可能看了没什么概念,接下来从虚拟计算环境下的网络结构从头开始介绍。这样对理解open vswitch比较有用一点。
在计算虚拟化技术推广之前,网卡是host连接到交换机的出口,连接到物理交换机后,由物理交换机根据报文转发规则进行相应的处理。在Host主机部署虚拟化技术之后,允许多个虚拟机同时运行,但网卡只有一个(或数量少于虚拟机),因此会引入网卡虚拟化。早在90年代末,Linux已引入了bridge技术来实现虚拟网卡。
linux中,TAP + bridge在网卡虚拟化中应用得比较普遍。结构如果所示:
该方案实现比较简单,但问题也很明显:bridge本身缺乏流控和网络管理的能力。一个很明显的问题是,同一host内虚拟机间通信,直接通过内存交换即可完成,可不经过网络。对网络管理者来说,这部分流量就变得不可见了。随着数据中心内单机部署虚拟机数量的增加,这一问题变得更加明显。
新型的虚拟交换机解决了内部流量的可视化问题,同时强化了流控、网络功能、QOS等方 面的特性。比较有代表性的虚拟交换机技术有:VMware vswitch、Cisco nexus 1000v和open vswtch。同时,这类交换机还支持中心化管理。中心化管理,使得在众多host上部署的虚拟交换机可以分布式得进行管控。另外,一些得到强化的NIC 卡,还支持对open vswitch进行加速,如TCP分片处理加速、checksum,甚至一些网卡将L2交换机集成在网卡内,极大得加快Open vswitch的报文转发速率。
open vswitch的结构 如下图所示:
上图是open vswitch在XEN上的部署结构,虽然跟KVM上略有差异,但基本是一致的。XEN上最大的差别在于将ovs-mod模块部署于Dom0,而KVM则 不属在HOST os的内核态而已。上图中,Hypervisor给每个虚拟机分配一个虚拟网卡VIF,VIF连接到Dom0的快速转发模块ovs-mod。此外在 Dom0的用户态部署了一系列的管理程序,其中最核心的是ovs-vswitchd。ovs-vswitchd可接受远程控制命令,如openflow控 制器的命令等。
经过上述的介绍,详细应该对open vswitch已经有基本的了解了,总结如下:
1. 针对虚拟网络,部署在hypervisor内的软件虚拟机
2. 解决了传统虚拟网桥所缺失的流量可视性问题,增强了网络管理的能力以及流控能力。
3.支持分布式部署架构
4.支持远程管理
5.支持多种Hypervisor
6.可兼容硬件网卡的加速
下面在详细剖析下open vswitch的重要组件及软件结构,整体结构如下图所示:
【该如引用自网友博客:http://chenpiaoping.blog.51cto.com/5631143/1143097】
上图是对OVS软件结构介绍较好的一张图,先来看看部署在用户态的组件:
1)用户态部署了一系列的守护进程,其中最重要的就是ovs-vswitchd和ovsdb-server。
2)ovs-vswitchd是open vswtich实现最复杂的一部分,也是核心组件,又被称为慢速路径。该组件负责同远程管理器进行通信,如通过openflow协议跟openflow控 制器通信,用sFlow协议同sFlowTrend通信。远程控制器下发流控制规则、流表项等。另外,该组件负责同部署在内核态的ovs快速路径通信,下 发具体的规则和动作到ovs datapath,两者之间通过netlink协议通信。
3)ovsdb-server存储配置数据,ovs-vswitchd通过socket同ovsdb-server通信,读取或写入配置数据。
4)在上述核心模块之外,还有一系列的管理工具,都是围绕上述核心功能提供一些增强服务的。不在赘述。
OVS的内核态相对比较简单,只部署了具体的datapath,负责实际的报文转发处理。
值得注意的是,为了提高虚拟网卡性能,业界出现了很多虚拟机直通网卡,比较典型的就是SRIOV网卡。这类网卡由于虚拟机可直接访问硬件,因此在数据路径中OVS是不会介入的,OVS在这类网卡上的作用,更接近于网络管理工具。
目前业界也出现了一些针对OVS加速的解决方案,如intel DPDK ovs等,netmap EVAL、6windGate等,下次打算就OVS加速技术进行展开。
来源: http://blog.csdn.net/dxq136363/article/details/19353723
-------------------------------
OpenvSwitch简称OVS,官网(http://openvswitch.org/) OVS是一个高质量、多层的虚拟交换软件,即虚拟交换机。
OpenvSwitch的见的相关组件:
ovs-vswitchd:实现switch的daemon功能,包括一个支持流交换的Linux内核模块,实现了交换功能
ovsdb-vswtich: openvswitch的数据库,给ovs-vswitchd提供运行配置信息,即保存了ovs-vswitchd的配置信息,例如vlan、port等信息
ovs-vsctl:查询和更新ovs-vswitchd的配置,即用于修改或查询ovsdb-vswitch的信息
还有些组件此处不做介绍
接下来我们来做一个实验,利用GRE通道搭建一个跨多宿主机的虚拟化网络,环境centos6.7 拓扑图如下
1)修改内核参数(一定要先修改内核参数,若果配置了网络名称空间在配置内核参数,内核参数将不会生效)
net.ipv4.ip_forward = 1 \\启用内核转发功能
net.ipv4.conf.default.rp_filter = 0 \\关闭路由验证
/etc/init.d/iptables stop \\关闭防火墙
setenforce 0 \\关闭Selinux
2)准备yum源
[openswitch]
name= openswitch
baseurl=https:
//repos
.fedorapeople.org
/openstack/EOL/openstack-icehouse/epel-6/
enabled=1
gpgcheck=0
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64
time
=2.66 ms
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64
time
=1.52 ms
[root@node3 ~]
# ip netns exec B1 ping 192.168.10.10
64 bytes from 192.168.10.10: icmp_seq=1 ttl=64
time
=3.59 ms
[root@node4 ~]
# ip netns exec A2 ping 192.168.10.1
64 bytes from 192.168.10.1: icmp_seq=1 ttl=64
time
=6.75 ms
在node4宿主机上
ping
node3宿主机上的网络名称空间,在node3宿主机上抓包分析
[root@node3 ~]
# tcpdump -nn -i eth1
10:15:38.768203 IP 10.10.10.1 > 10.10.10.2: GREv0, length 56: STP 802.1d, Config, Flags [none], bridge-
id
8000.a2:49:24:81:6e:46.8001, length 35
[root@node3 ~]
# ip netns exec A1 tcpdump -nn icmp -i a1.2
10:18:29.352487 IP 192.168.10.10 > 192.168.10.1: ICMP
echo
request,
id
7211,
seq
1, length 64

在node4宿主机上
ping
node3宿主机上的网络名称空间,在node3宿主机上抓包分析
[root@node3 ~]
# tcpdump -nn -i eth1