ovs

https://opengers.github.io/openstack/openstack-base-use-openvswitch/ Posted on January 23, 2017 by opengers in openstack Open vSwitch介绍 OVS架构 ovs-vswitchd ovsdb-server OpenFlow Controller Kernel Datapath OVS概念 Bridge Port Interface Controller datapath OVS中的各种流(flows) OpenFlow flows “hidden” flows datapath flows 管理flows的命令行工具 ovs-*工具的使用及区别 Open vSwitch介绍 在过去，数据中心的服务器是直接连在硬件交换机上，后来VMware实现了服务器虚拟化技术，使虚拟服务器(VMs)能够连接在虚拟交换机上，借助这个虚拟交换机，可以为服务器上运行的VMs或容器提供逻辑的虚拟的以太网接口，这些逻辑接口都连接到虚拟交换机上，有三种比较流行的虚拟交换机: VMware virtual switch, Cisco Nexus 1000V,和Open vSwitch Open vSwitch(OVS)是运行在虚拟化平台上的虚拟交换机，其支持OpenFlow协议

下图所示是Open vSwitch的组成(摘自Open vSwitch官网): 它分为Kernel部分和User部分。 安装驱动 Kerenl部分是从Linux 2.6.32开始何如内核，默认是编译为一个KO，位于/lib/modules/`uname –r`/kernel/net/openvswitch/openvswitch.ko。 应用open vswitch首先要做的就是install这个kernel module。需要注意，GRE Tunneling的支持需要gre.ko, VXLAN的支持需要vxlan.ko, 这两个KO都位于/lib/modules/`uname –r`/kernel/路径下。 user部分是有两个daemon，一个是ovs-vswitchd，用来管理datapath，另外一个是ovsdb-server，用来维护一个数据库。 初始化dbserver 在install好openvswitch.ko后，我们接着需要初始化这个ovsdb-server： 123 opendb - server -- remote = punix :/ usr / local / var / run / openvswitch / db.sock \ -- remote = Open_vSwitch,Open_vSwitch,manager_option \ --

先看下OVS整体架构，用户空间主要组件有数据库服务ovsdb-server和守护进程ovs-vswitchd。kernel中是datapath内核模块。最上面的Controller表示OpenFlow控制器，控制器与OVS是通过OpenFlow协议进行连接，控制器不一定位于OVS主机上，下面分别介绍图中各组件 ovs1 ovs-vswitchd ovs-vswitchd 守护进程是OVS的核心部件，它和 datapath 内核模块一起实现OVS基于流的数据交换。作为核心组件，它使用openflow协议与上层OpenFlow控制器通信，使用OVSDB协议与 ovsdb-server 通信，使用 netlink 和 datapath 内核模块通信。 ovs-vswitchd 在启动时会读取 ovsdb-server 中配置信息，然后配置内核中的 datapaths 和所有OVS switches，当ovsdb中的配置信息改变时(例如使用ovs-vsctl工具)， ovs-vswitchd 也会自动更新其配置以保持与数据库同步 # ps -ef |grep ovs-vs root 22176 22175 0 Jan17 ? 00:16:56 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vconsole:emer -vsyslog:err

ovs-vswitchd.c的main函数最终会进入一个while循环，在这个无限循环中，里面最重要的两个函数是bridge_run()和netdev_run()。 Openvswitch主要管理两种类型的设备，一个是创建的虚拟网桥，一个是连接到虚拟网桥上的设备。 其中bridge_run就是初始化数据库中已经创建的虚拟网桥。 一、虚拟网桥的初始化bridge_run bridge_run会调用bridge_run__，bridge_run__中最重要的是对于所有的网桥，都调用ofproto_run static void bridge_run__(void) { …… /* Let each bridge do the work that it needs to do. */ HMAP_FOR_EACH (br, node, &all_bridges) { ofproto_run(br->ofproto); } } Int ofproto_run(struct ofproto *p)会调用error = p->ofproto_class->run(p); ofproto_class的定义在ofproto-provider.h中，它的实现定义在ofproto-dpif.c中，这里面的所有的函数，在这个文件中都有定义。 const struct ofproto_class

上一节我们讲了ovs-vswitchd，其中虚拟网桥初始化的时候，对调用内核模块来添加虚拟网卡。 我们从openvswitch内核模块的加载过程，来看这个过程。 在datapath/datapath.c中会调用module_init(dp_init);来初始化内核模块。 static int __init dp_init(void) { int err; BUILD_BUG_ON(sizeof(struct ovs_skb_cb) > FIELD_SIZEOF(struct sk_buff, cb)); pr_info("Open vSwitch switching datapath %s\n", VERSION); err = compat_init(); if (err) goto error; err = action_fifos_init(); if (err) goto error_compat_exit; err = ovs_internal_dev_rtnl_link_register(); if (err) goto error_action_fifos_exit; err = ovs_flow_init(); if (err) goto error_unreg_rtnl_link; err = ovs_vport_init(); if (err) goto

Open vSwitch 概述 Open vSwitch（下面简称为 OVS）是由 Nicira Networks 主导的，运行在虚拟化平台（例如 KVM，Xen）上的虚拟交换机。在虚拟化平台上，OVS 可以为动态变化的端点提供 2 层交换功能，很好的控制虚拟网络中的访问策略、网络隔离、流量监控等等。 OVS 遵循 Apache 2.0 许可证, 能同时支持多种标准的管理接口和协议。OVS 也提供了对 OpenFlow 协议的支持，用户可以使用任何支持 OpenFlow 协议的控制器对 OVS 进行远程管理控制。 Open vSwitch 概述 在 OVS 中, 有几个非常重要的概念： Bridge: Bridge 代表一个以太网交换机（Switch），一个主机中可以创建一个或者多个 Bridge 设备。 Port: 端口与物理交换机的端口概念类似，每个 Port 都隶属于一个 Bridge。 Interface: 连接到 Port 的网络接口设备。在通常情况下，Port 和 Interface 是一对一的关系, 只有在配置 Port 为 bond 模式后，Port 和 Interface 是一对多的关系。 Controller: OpenFlow 控制器。OVS 可以同时接受一个或者多个 OpenFlow 控制器的管理。 datapath: 在 OVS 中，datapath

和三层外面再套三层的GRE不同，VXLAN则是从二层外面就套了一个VXLAN的头，这里面包含的VXLAN ID为24位，也够用了。在VXLAN头外面还封装了 UDP、IP，以及外层的MAC头 VXLAN作为扩展性协议，也需要一个地方对VXLAN的包进行 封装 和 解封装 ，实现这个功能的点称为 VTEP （VXLAN Tunnel Endpoint）。 VTEP相当于虚拟机网络的管家。每台物理机上都可以有一个VTEP。每个虚拟机启动的时候，都需要向这个VTEP管家注册，每个VTEP都知道自己上面注册了多少个虚拟机。当虚拟机要跨VTEP进行通信的时候，需要通过VTEP代理进行，由VTEP进行包的封装和解封装。 和GRE端到端的隧道不同，VXLAN不是点对点的，而是支持通过组播的来定位目标机器的，而非一定是这一端发出，另一端接收。当一个VTEP启动的时候，它们都需要通过IGMP协议。加入一个组播组，就像加入一个邮件列表，或者加入一个微信群一样，所有发到这个邮件列表里面的邮件，或者发送到微信群里面的消息，大家都能收到。而当每个物理机上的虚拟机启动之后，VTEP就知道，有一个新的VM上线了，它归我管。 虚拟机1、2、3属于云中同一个用户的虚拟机，因而需要分配相同的VXLAN ID=101。在云的界面上，就可以知道它们的IP地址，于是可以在虚拟机1上ping虚拟机2。 虚拟机1发现

本文根据博云在dockerone社区微信群分享内容整理 过去几年博云在企业中落地容器云平台遇到了很多痛点，其中一个比较典型的痛点来自网络方面，今天很高兴跟大家聊聊这个话题并介绍下我们基于OVS自研的CNI插件——内部称之为fabric项目。 01 容器平台落地时网络方面的需求 从2013年左右Docker技术在开发者中流行起来，到如今kubernetes已经成为事实上的容器编排引擎，容器、微服务、DevOps互相支持互相促进，容器云平台的实际落地案例开始越来越多。特别是2018年以来，越来越多的企业开始思考如何利用容器云平台支持其生产场景最终提高生产效率。 不同于开发测试场景，生产场景上线一套平台或系统要求会严格很多。安全、监控、流程、现有系统集成、业务暴露等等的建设要求都要匹配上，否则不可能上线。在这个过程中，特别是在传统的金融类企业对监管要求严格的情况下，容器云平台落地时会碰到很多问题，这其中，最典型的一个需求就是容器云平台的网络建设，必须同时满足业务方，运维人员，安全人员，网络人员的诉求。 现在容器云平台大部分都是基于Kubernetes构建，市面上的CNI插件也非常多，各个企业现网的需求也有很大的不同，所以几乎不可能出现一种网络模型适配所有客户场景的情况。现在主流的比较成熟稳定的CNI比如calico在扩展性、稳定性等方面表现优秀，但在传统金融类企业落地时非常困难