理解OpenStack中OpenvSwitch的几个要点

OpenvSwitch是实现虚拟化网络的重要基础组件，在OpenStack中利用OpenvSwitch作为底层部件来完成虚拟网络提供和租户网络管理。
在部署和应用OpenStack的过程中，可能会碰到网络相关的一些问题，能够准确的理解OpenStack中OpenvSwitch的角色和网络的理念，会有助于解决问题和快速部署。

OpenvSwitch可以认为是一种Linux Bridge的实现，只不过功能更多一些。因此，它完全可以替代Bridge。原先Bridge可以实现的功能在OpenvSwitch中都可以实现。

OpenvSwitch不等于OpenFlow Switch，恰恰相反，支持OpenFlow只是它的一个feature而已，可能还没有支持OvsDB协议更重要。因此，它在实现上自定义了很多地方，只是兼容OpenFlow协议。比如在OpenvSwitch中用户态的vswitchd和内核态的datapath。vswitchd会总管流表，而datapath中有精确匹配的部分流表，类似cache架构。

正因为OpenvSwitch不仅仅是一个OpenFlow Switch，它的流表组成除了of流表外，还有其他一些（隐藏）流表。这些隐藏流表是由于默认交换机和控制器在同一网络中（in-band），因此要保证两者互通。要关闭默认的inband可以通过“ovs-vsctl set controller br0 connection-mode=out-of-band”。

检查所有流表信息可以通过ovs-appctl bridge/dump-flows br0，这往往要比ovs-vsctl dump-flows br0打印出更多的信息来。ovs-dpctl dump-flows [dp]可以打印出datapath的流表信息。ovs-appctl dpif/dump-flows <br>可以打印出指定bridge上的datapath流。

OpenvSwitch可以实现访问控制功能，通过转发规则，可以实现简单的安全行为，包括通过、禁止等。现在OpenStack中的安全组是由iptables实现的，造成在节点上多了好几级的Bridge。理论上，以后都可以统一由OpenvSwitch来管理。

支持VLan（eth0为trunk口，创建vlan 1的tap0口）：
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
ovs-vsctl add-port br0 tap0 tag=1

OpenvSwitch 在无法连接到控制器时候（fail mode）可以选择两种fail状态，一种是standalone，一种是secure状态。如果是配置了standalone（或者未设置fail mode）mode，在三次探测控制器连接不成功后，此时ovs-vswitchd将会接管转发逻辑（后台仍然尝试连接到控制器，一旦连接则退出fail状态），OpenvSwitch将作为一个正常的mac 学习的二层交换机。如果是配置了secure mode，则ovs-vswitchd将不会自动配置新的转发流表，OpenvSwitch将按照原先有的流表转发。可以通过下面命令进行管理。

ovs-vsctl get-fail-mode bridge
ovs-vsctl del-fail-mode bridge
ovs-vsctl set-fail-mode bridge standalone|secure

LSO, TSO, GSO和网络虚拟化

先来看三个缩写到底具体代表什么：Large Segment Offload (LSO)，TCP segmentation offload (TSO)， 以及Generic Segmentation Offload (GSO)。

首先来看LSO。我们知道计算机网络上传输的数据基本单位是离散的网包，既然是网包，就有大小限制，这个限制就是MTU（Maximum Transmission Unit）的大小，一般是1518字节。比如我们想发送很多数据出去，经过os协议栈的时候，会自动帮你拆分成几个不超过MTU的网包。然而，这个拆分是比较费计算资源的（比如很多时候还要计算分别的checksum），由CPU来做的话，往往会造成使用率过高。那可不可以把这些简单重复的操作offload到网卡上呢？

于是就有了LSO，在发送数据超过MTU限制的时候（太容易发生了），os只需要提交一次传输请求给网卡，网卡会自动的把数据拿过来，然后进行切，并封包发出，发出的网包不超过MTU限制。

反过来，当网卡收到很多碎片包的时候，也可以辅助自动组合成一段较大的数据，一次性提交给os处理。

很典型的，TCP协议中就考虑了分片存在的情况，往往是切分TCP的数据包，叫做TSO。而一般的情况，则称为LSO或者GSO。
对于其他不支持切片的协议例如UDP，则只能进行IP层上的切片。

这样做，一方面大大降低了CPU利用率，又增强了网卡等转发设备的feature，所以说有时候适当的进行offload很重要！

那么，这三个SO，跟虚拟化有什么联系呢？

在网络虚拟化中，一个最常见的技术就是隧道，这是实现overlay的通用手段。而实现隧道无非就两种思路，一种是把转发信息放到包头上，即封装/解封装（无论VXLAN还是STT都是这个思路）；另外一种是由额外的数据库管理，转发时候进行查询。这两种思路各有利弊，这里不细说，如果我们采用封装/解封装的作法，那么可能原来网包并没有超过MTU限制，加上封装包头就超了，这就需要进行切片了。

所以VMware在其旗舰产品NVP中强调可以通过TSO来提高转发性能。

但是显然，前提是网卡能够支持，并且在os中配置打开。

可以通过ethtool -k eth0来查看当前状态

通过ethtool -K eth0 gso off/on 这样的命令来开关