锐单电子商城 , 一站式电子元器件采购平台!
  • 电话:400-990-0325

【重识云原生】第四章云网络4.8.3.1节——Open vSwitch简介

时间:2023-04-23 17:07:01 ax400系列变送器二极管模块mee75

1 Open vSwitch诞生背景

1.1 虚拟化催生vSwitch技术

在过去十几年中,虚拟化已经改变了应用、数据、服务的实现部署方式。虚拟化服务器给数据中心网络带来了根本性的变化。在传统数据中心网络架构的基础上,物理服务器中出现了新的接入层。新接入层中包含的设备正在运行x86服务器中的vSwitch,而这些vSwitch多个服务器连接到一个服务器workload(包括容器和虚机)。

vSwitch早期代表是Linuxbridge,在设计之初,它只是模拟了基本的网络连接ToR交换机的行为,并将自己连接到现有的物理网络。现有物理网络的理论和协议可以直接应用,无需重复设计。缺点是虚拟作为物理网络的延伸workload网络与物理网络紧密耦合,影响虚拟化本身带来的灵活快速上线等优势。

网络虚拟化(network virtualization)为了连接虚拟技术的出现workload网络提供了另一种可能性。物理网络仍然由物理网络设备管理workload网络,单独由vSwitch管理,现有物理网络(underlay)在此基础上,定义一个独立的overlay网络(例如VxLAN)。这个overlay网络完全由物理网络设备控制vSwitch控制。

OpenvSwitch基于这一设计理念。OpenVSwitch多层开源虚拟交换机。但到目前为止,LinuxBridge也支持了VxLAN,OpenVSwitch它还可以支持相应的物理网络VLAN、FLAT网络。

1.2 OpenFlow技术的驱动

除了基于overlay除了网络的思想设计,OpenVSwitch的另一大特点就是基于OpenFlow。

传统的交换机,无论是硬件还是软件,都具有预先内置的功能。当需要使用某个功能时,需要提前进行相应的配置。而Open vSwitch通过OpenFlow实现了交换机的可编程性。OpenFlow网络包在交换机中的处理过程可以定义(pipeline),因此支持OpenFlow通过OpenFlow可定义软件OpenVSwitch功能。

OpenFlow以多个Table如下图所示,串行处理网络数据包。

OpenFlow实现灵活性SDN但在一些实际场景中,由于涉及的功能多而复杂,相应的OpenFlow pipeline会变长。直观地看,pipeline越长,处理一个网络包需要的时间也越长。这是OpenFlow从理论到实践,Open vSwitch为此尝试了很多优化。

对于一个Linux系统可分为用户空间(user space)和内核空间(kernel space),网络设备连接到核心空间。如果需要将数据传输到用户程序,则需要通过核心空间将数据发送到用户空间。如果需要在网络设备之间转发数据,可以直接在核心空间完成。

作为运行在x直观地说,86服务器中的软件交换机应该在核心空间转发。因此,Open vSwitch在最早的时期,是Linux内核模块实现了所有内核模块OpenFlow的处理。当时的OpenvSwitch根据内核模块处理流程,接收网络数据包OpenFlow规则一步一步Match,并根据Action修改网络数据包,最后从网络设备发送。

但这种方法很快就被认为不能实际应用。首先,虽然内核实现可以缩短网络数据包在操作系统中的路径,但在内核中更难开发和更新程序OpenvSwitch在内核中完全实现更新速度将变得不切实际。其次,完全按照OpenFlow pipeline要处理网络包,必然会消耗很多CPU,然后降低网络性能。

所以最新版本(2.x版本)的OpenVSwitch避免这些问题的方法非常不同。

1.3 Open vSwitch(OVS)简介

Open vSwitch(下文简称 OvS)就是一个开源的虚拟交换机实现。广泛应用于云计算行业,为网络管理员提供流量可见性和可控性。Open vSwitch 以虚拟化解决网络问题为目标,与控制器软件一起实现分布式虚拟交换技术。这意味着交换机和控制器软件可以在多个服务器之间创建集群网络配置,而无需在每个云主机和物理主机上单独配置网络。该交换机也支持 VLAN 中继,通过 NetFlow、sFlow 和 RSPAN 通过实现可见性 OpenFlow 协议管理。它还有其他一些特点:严格的流量控制 OpenFlow 实现交换协议;远程管理功能,通过网络策略实现更多控制;支持各种虚拟平台(Xen,KVM, Proxmox VE and VirtualBox)以及交换机芯片。支持各种虚拟化管理平台( OpenStack,openQRM, OpenNebula and oVirt)。

虚拟交换机 Flow 控制器或管理工具,OvS 复杂的转发策略需要使用第三方控制器或管理工具。例如 OvS 支持 OpenFlow 我们可以使用任何支持协议 OpenFlow 协议的控制器是正确的 OvS 远程管理。但这并不意味着 OvS 工作必须有控制器。在不连接外部控制器的情况下,OvS 可以依靠自己 MAC 地址学习实现二层数据包转发功能,就像 Linux Bridge。

Open vSwitch 特性清单:

  • 支持通过 NetFlow、sFlow、IPFIX、SPAN、RSPAN 和 GRE-tunneled 镜像可以监控虚拟机通信;
  • 支持 LACP(IEEE 802.1AX-多端口绑定协议2008;
  • 支持标准的 802.1Q VLAN 模型以及 Trunk 模式;
  • 支持 BFD 和 802.1ag 链路状态监测;
  • 支持 STP(IEEE 802.1D-1998);
  • 支持细粒度 Qos;
  • 支持 HFSC 系统级流量控制队列;
  • 支持每个虚拟机网卡的流量控制策略;
  • 支持基于源 MAC 负载平衡模式,主备模式,L4 多端口绑定哈希模式;
  • 支持 OpenFlow 协议(包括许多虚拟化的增强特性);
  • 支持IPV6
  • 支持各种隧道协议(GRE, VXLAN, IPsec, GRE and VXLAN over IPsec)
  • 支持通过 C 或者 Python 接口远程配置;
  • 转发引擎设置支持内核态和用户态;
  • 发送缓存引擎支持多列表转发;
  • 支持转发层抽象硬件平台抽象转发层;

1.4 OVS概念

以使用OpenStack neutron vxlan网络节点在部署模式下OVS以网桥为例

1.4.1 Bridge

Bridge代表以太网交换机(Switch),一台或多一个或多个主机Bridge。Bridge根据一定的规则,将从端口收到的数据包转发到另一个或多个端口上述三个例子Bridge,br-tun,br-int,br-ext

加网桥br0

1.4.2 Port

端口Port类似于物理交换机的端口概念,Port是OVS Bridge创建的虚拟端口,每个Port都属于一个Bridge。Port有以下几种类型:

  • Normal

操作系统中现有的网卡(物理网卡)em1/eth0,或虚拟机虚拟网卡tapxxx)挂载到ovs上,ovs会生一个同名Port处理这块网卡进出的数据包。此时端口类型为Normal。

        如下,主机中有一块物理网卡eth1,把其挂载到OVS网桥br-ext上,OVS会自动创建同名Port eth1。

         有一点要注意的是,挂载到OVS上的网卡设备不支持分配IP地址,因此若之前eth1配置有IP地址,挂载到OVS之后IP地址将不可访问。这里的网卡设备不只包括物理网卡,也包括主机上创建的虚拟网卡。

  • Internal

        Internal类型是OVS内部创建的虚拟网卡接口,每创建一个Port,OVS会自动创建一个同名接口(Interface)挂载到新创建的Port上。接口的概念下面会提到。

        下面创建一个网桥br0,并创建一个Internal类型的Port p0。

         可以看到有两个Port。当ovs创建一个新网桥时,默认会创建一个与网桥同名的Internal Port。在OVS中,只有”internal”类型的设备才支持配置IP地址信息,因此我们可以为br0接口配置一个IP地址,当然p0也可以配置IP地址。

         上面两种Port类型区别在于,Internal类型会自动创建接口(Interface),而Normal类型是把主机中已有的网卡接口添加到OVS中。

  • Patch

        当主机中有多个ovs网桥时,可以使用Patch Port把两个网桥连起来。Patch Port总是成对出现,分别连接在两个网桥上,从一个Patch Port收到的数据包会被转发到另一个Patch Port,类似于Linux系统中的veth。使用Patch连接的两个网桥跟一个网桥没什么区别,OpenStack Neutron中使用到了Patch Port。上面网桥br-ext中的Port phy-br-ext与br-int中的Port int-br-ext是一对Patch Port。

        可以使用ovs-vsctl创建patch设备,如下创建两个网桥br0,br1,然后使用一对Patch Port连接它们。

         连接两个网桥不止上面一种方法,linux中支持创建Veth设备对,我们可以首先创建一对Veth设备对,然后把这两个Veth分别添加到两个网桥上,其效果跟OVS中创建Patch Port一样,只是性能会有差别。

  • Tunnel

        OVS中支持添加隧道(Tunnel)端口,常见隧道技术有两种gre或vxlan。隧道技术是在现有的物理网络之上构建一层虚拟网络,上层应用只与虚拟网络相关,以此实现的虚拟网络比物理网络配置更加灵活,并能够实现跨主机的L2通信以及必要的租户隔离。不同隧道技术其大体思路均是将以太网报文使用隧道协议封装,然后使用底层IP网络转发封装后的数据包,其差异性在于选择和构造隧道的协议不同。Tunnel在OpenStack中用作实现大二层网络以及租户隔离,以应对公有云大规模,多租户的复杂网络环境。

        OpenStack是多节点结构,同一子网的虚拟机可能被调度到不同计算节点上,因此需要有隧道技术来保证这些同子网不同节点上的虚拟机能够二层互通,就像他们连接在同一个交换机上,同时也要保证能与其它子网隔离。

        OVS在计算和网络节点上建立隧道Port来连接各节点上的网桥br-int,这样所有网络和计算节点上的br-int互联形成了一个大的虚拟的跨所有节点的逻辑网桥(内部靠tunnel id或VNI隔离不同子网),这个逻辑网桥对虚拟机和qrouter是透明的,它们觉得自己连接到了一个大的br-int上。从某个计算节点虚拟机发出的数据包会被封装进隧道通过底层网络传输到目的主机然后解封装。

        上面网桥br-tun中Port "vxlan-080058ca"就是一个vxlan类型tunnel端口。下面使用两台主机测试创建vxlan隧道。

        然后,两个主机上桥接到br-vxlan的虚拟机就像连接到同一个交换机一样,可以实现跨主机的L2连接,同时又完全与物理网络隔离。

1.4.3 Interface

        Interface是连接到Port的网络接口设备,是OVS与外部交换数据包的组件,在通常情况下,Port和Interface是一对一的关系,只有在配置Port为 bond模式后,Port和Interface是一对多的关系。这个网络接口设备可能是创建Internal类型Port时OVS自动生成的虚拟网卡,也可能是系统的物理网卡或虚拟网卡(TUN/TAP)挂载在ovs上。 OVS中只有”Internal”类型的网卡接口才支持配置IP地址。

        Interface是一块网络接口设备,负责接收或发送数据包,Port是OVS网桥上建立的一个虚拟端口,Interface挂载在Port上。

1.4.4 Controller

        OpenFlow控制器。OVS可以同时接受一个或者多个OpenFlow控制器的管理。主要作用是下发流表(Flow Tables)到OVS,控制OVS数据包转发规则。控制器与OVS通过网络连接,不一定要在同一主机上。

        可以看到上面实例中三个网桥br-int,br-ext,br-tun都连接到控制器Controller "tcp:127.0.0.1:6633上。

1.4.5 datapath

        OVS内核模块,负责执行数据交换。其内部有作为缓存使用的flows,上面已经介绍过。

1.5 OVS中的各种流(flows)

        flows是OVS进行数据转发策略控制的核心数据结构,区别于Linux Bridge是个单纯基于MAC地址学习的二层交换机,flows的存在使OVS作为一款SDN交换机成为云平台网络虚拟机化主要组件

        OVS中有多种flows存在,用于不同目的,但最主要的还是OpenFlow flows这种,文中未明确说明的flows都是指OpenFlow flows

1.5.1 OpenFlow flows

        OVS中最重要的一种flows,Controller控制器下发的就是这种flows。

1.5.2 “hidden” flows

        OVS在使用OpenFlow flow时,需要与OpenFlow控制器建立TCP连接,若此TCP连接不依赖OVS,即没有OVS依然可以建立连接,此时就是out-of-band control模式,这种模式下不需要”hidden” flows。

        但是在in-band control模式下,TCP连接的建立依赖OVS控制的网络,但此时OVS依赖OpenFLow控制器下发的flows才能正常工作,没法建立TCP连接也就无法下发flows,这就产生矛盾了,因此需要存在一些”hidden” flows,这些”hidden” flows保证了TCP连接能够正常建立。关于in-band control详细介绍,参考OVS官方文档Design Decisions In Open vSwitch 中In-Band Control部分。

        “hidden” flows优先级高于OpenFlow flows,它们不需要手动设置。可以使用ovs-appctl查看这些flows,下面命令输出内容包括OpenFlow flows,"hidden" flows。

1.5.3 datapath flows

        datapath flows是datapath内核模块维护的flows,由内核模块维护意味着我们并不需要去修改管理它。与OpenFlow flows不同的是,它不支持优先级,并且只有一个表,这些特点使它非常适合做缓存。与OpenFlow一样的是它支持通配符,也支持指令集(多个action)

        datapath flows可以来自用户空间ovs-vswitchd缓存,也可以是datapath内核模块进行MAC地址学习到的flows,这取决与OVS是作为SDN交换机,还是像Linux Bridge那样只是一个简单基于MAC地址学习的二层交换机

1.6 管理flows的命令行工具

        我们可以修改和配置的是OpenFlow flows。datapath flow和”hidden” flows由OVS自身管理,我们不必去修改它。当然,调试场景下还是可以使用工具修改的。

        介绍下上面三种flows管理工具,不具体说明,具体使用可以查看相关man手册。

  • ovs-ofctl dump-flows
     打印指定网桥内的所有OpenFlow flows,可以存在多个流表(flow tables),按表顺序显示。不包括”hidden” flows。这是最常用的查看flows命令,当然这条命令对所有OpenFlow交换机都有效,不单单是OVS;
  • ovs-appctl bridge/dump-flows
     打印指定网桥内所有OpenFlow flows,包括”hidden” flows,in-band control模式下排错可以用到;
  • ovs-dpctl dump-flows [dp] 打印内核模块中datapath flows,[dp]可以省略,默认主机中只有一个datapath system@ovs-systemman手册可以找到非常详细的用法说明,注意ovs-ofctl管理的是OpenFlow flows;

参考链接

OVS那些事儿之基础功能篇_Kenelite的博客-CSDN博客_ovs和dvs

软件定义网络

OpenVSwitch实现浅谈(一) - 知乎

OpenVSwitch实现浅谈(二) - 知乎

OpenVSwitch实现浅谈(三) - 知乎

OpenvSwitch(OVS)全面解读_造夢先森的博客-CSDN博客_open vswitch

OpenvSwitch概念和原理_Mr. Sun_的博客-CSDN博客_openvswitch

OpenVSwitch 硬件加速浅谈 | SDNLAB | 专注网络创新技术

SDN私享汇(十一):OvS 架构介绍及开发实践 | SDNLAB | 专注网络创新技术

Open vSwitch之QoS的实现 | SDNLAB | 专注网络创新技术

OpenvSwitch 解读

OpenvSwitch 解读 - SegmentFault 思否

Openvswitch总体架构与代码结构_慕课手记

OpenvSwitch 架构解析与功能实践_qq_0105的博客-CSDN博客

Openvswitch手册(1): 架构,SSL, Manager, Bridge - popsuper1982 - 博客园

Openvswitch手册(2): OpenFlow Controller - popsuper1982 - 博客园

OpenvSwitch完全使用手册_Better_Mee的博客-CSDN博客_openvswitch完全使用手册

云计算底层技术-使用openvswitch | opengers

 《重识云原生系列》专题索引: 

  1. 第一章——不谋全局不足以谋一域
  2. 第二章计算第1节——计算虚拟化技术总述
  3. 第三章云存储第1节——分布式云存储总述
  4. 第四章云网络第一节——云网络技术发展简述
  5. 第四章云网络4.2节——相关基础知识准备
  6. 第四章云网络4.3节——重要网络协议
  7. 第四章云网络4.3.1节——路由技术简述
  8. 第四章云网络4.3.2节——VLAN技术
  9. 第四章云网络4.3.3节——RIP协议
  10. 第四章云网络4.3.4节——OSPF协议
  11. 第四章云网络4.3.5节——EIGRP协议
  12. 第四章云网络4.3.6节——IS-IS协议
  13. 第四章云网络4.3.7节——BGP协议
  14. 第四章云网络4.3.7.2节——BGP协议概述
  15. 第四章云网络4.3.7.3节——BGP协议实现原理
  16. 第四章云网络4.3.7.4节——高级特性
  17. 第四章云网络4.3.7.5节——实操
  18. 第四章云网络4.3.7.6节——MP-BGP协议
  19. 第四章云网络4.3.8节——策略路由
  20. 第四章云网络4.3.9节——Graceful Restart(平滑重启)技术
  21. 第四章云网络4.3.10节——VXLAN技术
  22. 第四章云网络4.3.10.2节——VXLAN Overlay网络方案设计
  23. 第四章云网络4.3.10.3节——VXLAN隧道机制
  24. 第四章云网络4.3.10.4节——VXLAN报文转发过程
  25. 第四章云网络4.3.10.5节——VXlan组网架构
  26. 第四章云网络4.3.10.6节——VXLAN应用部署方案
  27. 第四章云网络4.4节——Spine-Leaf网络架构
  28. 第四章云网络4.5节——大二层网络
  29. 第四章云网络4.6节——Underlay 和 Overlay概念
  30. 第四章云网络4.7.1节——网络虚拟化与卸载加速技术的演进简述
  31. 第四章云网络4.7.2节——virtio网络半虚拟化简介
  32. 第四章云网络4.7.3节——Vhost-net方案
  33. 第四章云网络4.7.4节vhost-user方案——virtio的DPDK卸载方案
  34. 第四章云网络4.7.5节vDPA方案——virtio的半硬件虚拟化实现
  35. 第四章云网络4.7.6节——virtio-blk存储虚拟化方案
  36. 第四章云网络4.7.8节——SR-IOV方案
  37. 第四章云网络4.7.9节——NFV
  38. 第四章云网络4.8.1节——SDN总述
  39. 第四章云网络4.8.2.1节——OpenFlow概述
  40. 第四章云网络4.8.2.2节——OpenFlow协议详解
  41. 第四章云网络4.8.2.3节——OpenFlow运行机制
  42. 第四章云网络4.8.3.1节——Open vSwitch简介
  43. 第四章云网络4.8.3.2节——Open vSwitch工作原理详解
  44. 第四章云网络4.8.4节——OpenStack与SDN的集成
  45. 第四章云网络4.8.5节——OpenDayLight
  46. 第四章云网络4.8.6节——Dragonflow
锐单商城拥有海量元器件数据手册IC替代型号,打造电子元器件IC百科大全!

相关文章