网络虚拟化

近期在调试问题时，遇到了一个从配置上看openvswitch无任何问题，但却导致转发不通的问题，特此记录下说，说明在openvswitch在大规模部署时，仍需要有较多调优之处。 设想如下openstack场景，大量tenant router通过linux namespace即仿真vrouter访问外网，此namespace中通过openvswitch internal port（或veth，如果不追求转发性能）连接到另一公网namespace，此时如果公网namespace中接口数量过多，比如说2000个（比如openstack中的qg-*接口），将有可能面临转发不通的情况。 从openvswitch的角度，我们知道openvswitch在内核态存在一个datapath，负责生成内核流表，实现高性能转发，对于一个拥有上千个port的ovs bridge来说，比如对应于上面的公网namespace，收到一个arp请求报文，由于是广播，报文通守openvswitch在userspace命中默认的normal流表后将推送广播至其他所有成员端口的内核流表，此后arp报文广播复制逻辑将在内核datapath模块处执行，最终命中以下内核代码： :::c /* * enqueue_to_backlog is called to queue an skb to a per CPU backlog * queue (may be a remote CPU queue). */ static int enqueue_to_backlog(struct sk_buff *skb, int cpu, unsigned int *qtail) { struct softnet_data *sd; unsigned long flags; sd = &per_cpu(softnet_data, cpu); local_irq_save(flags); rps_lock(sd); if (skb_queue_len(&sd->input_pkt_queue) <= netdev_max_backlog) { if (skb_queue_len(&sd->input_pkt_queue)) { enqueue: __skb_queue_tail(&sd->input_pkt_queue, skb); input_queue_tail_incr_save(sd, qtail); rps_unlock(sd); local_irq_restore(flags); return NET_RX_SUCCESS; } /* Schedule NAPI for backlog device * We can use non atomic operation since we own the queue lock */ if (!__test_and_set_bit(NAPI_STATE_SCHED, &sd->backlog.state)) { if (!rps_ipi_queued(sd)) ____napi_schedule(sd, &sd->backlog); } goto enqueue; } sd->dropped++; rps_unlock(sd); local_irq_restore(flags); atomic_long_inc(&skb->dev->rx_dropped); kfree_skb(skb); return NET_RX_DROP; } 可以注意到在上面的代码中有一个对sd->input_pkt_queue的检查过程，而sd是每个cpu核心net rx soft irq用于维护待处理报文的队列，netdev_max_backlog则是内核所提供的一个配置选项，默认为1000。 ...

目前OpenStack网络方案存在有较多的选择，liberty发布已经有大半多时间，mikata版本也快要发布，有必要比较一下近期各种openstack网络方案的状态。 主流方案介绍 当前，比较主流的方案有如下几种： ovs-agent ofagent ovn dragonflow midonet/opencontrail 除此之外，还有一些闭源的商业方案，如nsx、plumgrid，以及一些试验性的开源方案如networking-odl等，本次分析暂不考虑。 现有网络方案特性集及特点 ovs-agent 功能点支持情况备注L2 isolation using overlayY支持vlan/vxlan/grearp responderY要求ovs 2.1 + l2pop使能L3 DVRY要求每台计算节点都需要安装l3-agent，通过netns及linux协议栈实现ovsdb nativeY独立功能，与openflow native无关，可单独开启，有一定的性能提升openflow nativeYovs-agent将内置ryu，运行一个of app用来处理与本地ovs的交互，基本逻辑与原ovs-agent相似，通过driver机制实现不同方式的bridge操作，目前仍处于实验阶段security groupY目前仍基于iptables，随着ovs conntrack功能的完善，可以演进至基于ovs conntrack实现dhcpY仍采用dhcp agentnorth-sourth流量Y仍采用l3agent进行集中式转发，即便在dvr模式下 ofagent 如同ofagent在openstack上的wiki所述： OFAgent is a neutron core-plugin, implemented as ML2 mechanism driver. It aims to support pure OpenFlow1.3 switches. ofagent关注的更多是指向向设备（如vswitch/pswitch）可移植性，因此基于纯openflow协议进行实现，而纵观业界，基本上没有基于纯openflow的openstack网络方案（目前仍成功商用的则是bigswitch的big fabric，但其采用了深度修改的openflow），因此这种方式可能是过于理想化的方案，可能并不一定能够容易落地。 从ovs的状态来看，ovs 2.5中为支持conntrack，引入了ct_state/ct这样的match/atction，这些nicira扩展落入openflow spec的时间点可能还比较长，而为了实现dv足够多的功能，ovs将会继续引入扩展，如果基于纯openflow实现的话，这些功能都将难以利用。 从wiki上的比较来看，ofagent也不支持dvr，实现上同样基于ryu，而部署模式上与ovs-agent相似，在compute/network节点都需部署。 ovn ovn是由vmware所主导的新项目，其介绍如下所示： OVN, the Open Virtual Network, is a system to support virtual network abstraction. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Services such as DHCP are also desirable features. Just like OVS, OVN’s design goal is to have a production-quality implementation that can operate at significant scale. ...

网络技术这个行业里，厂商通常会对一些技术做出高大上的包装，像网卡VXLAN offload这种技术，就是一个典型的例子，然而其底层技术，也许并不像想象中的那么神秘。 做为网络交换机的开发人员，近年来一直从事数据中心网络虚拟化的相关工作，最近读取一篇关于青云SDN 2.0的文章，里面提到了采用网卡VXLAN offload这种技术后overlay情形下的虚拟网络性能得到了较大规模的提升，考虑到后续我亦将加入云计算公司进行网络虚拟化相关的研发，自然也十分想了解这种技术的底层实现如何，以便从理论上分析其性能是否具有较大的价值。 分析之前，稍微VXLAN的封装格式进行简单的说明，本质上VXLAN类似于一种l2vpn技术，即将二层以太报文封装在udp报文里，从而跨越underlay L3网络，实现不同服务器或不同数据中心间的互联，其格式总结如下： |ETH_HEADER|IP_HEADER|UDP_HEADER|VXLAN_HEADER|INNER_ETH_HEADER|INNER_IP_HEADER|…| 在采用VXLAN技术后，由于vm/docker的报文被封装于外层的UDP报文中予以传输，使得以往的TCP SEGMENT OPTIMIZATION、TCP CHECKSUM OFFLOAD等功能对于内层VM的TCP数据收发失效，较大地影响了VM间通信的性能，给最终用户带来了很差的用户体验。 下面我们来看看不同的方案都是如何实现的： 支持Overlay的交换机 目前较新的万兆交换机大多支持Overlay功能，即支持将以太报文封装在VXLAN报文中予以转发，也即将VXLAN封装功能放在专用的网络设备上，来提供确定性的线速转发性能，但这很明显增加了交换机与服务器之间的耦合，给管理维护带来了一定的复杂度。 NIC VXLAN OFFLOAD 而网卡VXLAN offload则不像Overlay交换机那样要求对组网方案进行较大的变更，而是对于网卡的能力进行了增加，与网卡驱动配合，使得网卡能够知晓VXLAN内部以太报文的位置，从而使得TSO、TCP CHECKSUM OFFLOAD这些技术能够对内部以太报文生效，从而提升TCP性能。 以TSO为例，内核封装出的TCP报文如下： |ETH_HEADER|IP_HEADER|UDP_HEADER|VXLAN_HEADER|INNER_ETH_HEADER|INNER_IP_HEADER|INNER_TCP_HEADER|INNER_TCP_DATA_NEED_TSO| 该报文的内部TCP数据需要进行TSO处理，即切成满足网卡MTU的报文，内核驱动将报文通过DMA送给网卡后（同时要提供一些元信息，如VXLAN头位置等），网卡负责将内部的TCP报文转换为多个内部TCP报文，封装相同的外层VXLAN头后进行转发，从而减少CPU的干预，大规模提升性能。 小结 个人认为VXLAN OFFLOAD这个名字不如用VXLAN-AWARE OPTIMIZATION比较直观，但厂商为了吸引眼球，自然是需要适当的包装，可以理解。 从实现的角度来说，万兆甚至更高性能的网卡本来就比较贵，这样的优化可能并不一定导致过高的复杂度，但在实现上却能够不依赖于OVERLAY交换机更实现性能的提升，应该是做为优化OVERLAY性能的首选方案。