OpenStack之Neutron

OpenStack
概念

概述

传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备，而云环境下的网络已经变得非常复杂，特别是在多租户场景里，用户随时都可能需要创建、修改和删除网络，网络的连通性和隔离已经不太可能通过手工配置来保证了。

如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而 软件定义网络（software-defined networking， SDN） 所具有的灵活性和自动化优势使其成为云时代网络管理的主流。

Neutron的设计目的是实现 网路即服务（Networking as a Service）。为了达到这一目标，在设计上遵循了基于SDN实现网络虚拟化的原则，在实现上充分利用了Linux系统上的各种网络相关的技术。

SDN模式服务，NeutronSDN（软件定义网络），通过使用它，网络管理员和云计算操作员可以通过程序来动态定义虚拟网络设备。Openstack网络中的SDN组件就是Quantum，但因为版权问题而改名为Neutron。

Linux网络虚拟化实现技术

物理网络与虚拟化网络

Neutron最为核心的工作是对二层物理网络的抽象与管理，物理服务器虚拟化后，虚拟机的网络功能由虚拟网卡（vNIC）提供，物理交换机（Switch）也被虚拟化为虚拟交换机（vSwitch），各个vNIC连接在vSwitch的端口上，最后这些vSwitch通过物理服务器的物理网卡访问外部的物理服务。

Linux网络虚拟化实现技术

对一个虚拟的二层网络结构而言，主要是完成两种网络设备的虚拟化，即物理网卡和交换设备。在Linux环境下网络设备的虚拟化主要有以下几种形式：

网卡虚拟化

• TAP
• TUN
• VETH

交换机虚拟化

• Linux Bridge
• Open vSwitch

网络隔离

• Network Namespace

TAP/TUN/VETH

提到Neutron的虚拟网络功能实现，不得不先提基于Linux内核级的虚拟设备。

• TAP，工作在二层的网络设备，可以接收和发送二层网包收发的是 MAC 层数据帧；
• TUN，工作在三层的网络设备，可以接收和发送三层网包。
• VETH，虚拟Ethernet接口，通常以pair的方式出现，一端发出的网包，会被另外一端接收，可以形成两个网桥之间的通道。

基于TAP设备，实现的是虚拟网卡的功能，当一个TAP设备被创建时，在Linux的设备文件目录下将会生成一个对应的字符设备文件（/dev/tapX文件），而运行其上的用户程序便可以像使用普通文件一样打开这个文件进行读写。

Linux交换机虚拟化

Linux Bridge

• Linux内核实现的网桥，是工作在二层的虚拟网络设备，功能类似于物理的交换机。
• 当一个设备被绑定到bridge时，就相当于物理交换机端口插入了一条连接着终端的网线。
• 使用brctl命令配置Linux bridge：
  • brctl addbr BRIDGE
  • brctl addif BRIDGE DEVICE

它的实现原理是，通过将其他Linux网络设备绑定到自身的Bridge上，并将这些设备虚拟化为端口。为什么我们已经有了OVS，还要有Linux Bridge 呢？这是因为Linux Bridge实现了qbrxxx设备，提供了OVS无法支持的安全组（Security Group）功能。

Open vSwitch（OVS）

Open vSwitch是产品级的虚拟交换机。

• Linux Bridge更适用于小规模，主机内部间通信场景。
• Open vSwitch更适合于大规模，多主机间通信场景。

OVS也支持包括NetFlow、sFlow等标准的管理接口和协议。通过这些接口可以实现VM流量监控。

Linux网络隔离（Network Namespace）

Network namespace能创建多个隔离的网络空间，它们有独自的网络配置信息，例如网络设备，路由表，iptables等。

不同网络空间中的虚拟机运行的时候仿佛自己就在独立的网络中。

$ ip netns help
Usage: ip netnslist
       ip netns add NAME
       ip netns delete NAME
       ip netns identify PID
       ip netns pids NAME
       ip netns exec NAME cmd ...
       ip netns monitor

Network Namespace通常与VRF（Virtual Routing Forwarding虚拟路由和转发）一起工作，VRF是一种IP技术，允许路由表的多个实例同时在同一路由器上共存。

使用VETH可以连接两个不同网络命名空间，使用bridge可以连接多个不同的网络命名空间。

Neutron概念

Neutron是一种虚拟网络服务，为OpenStack计算提供网络连通和寻址服务。为了便于操作管理，Neutron对网络进行了抽象，有如下基本管理对象：

• Network
• Subnet
• Port
• Router
• Floating IP

Neutron网络资源

• 通过L3虚拟Router提供路由器功能。
• 通过L2虚拟network/subnet/port提供物理二层网络的功能，并且其二层network分别由linux bridge和OpenvSwitch等共同实现。

network

network是一个隔离的、虚拟二层广播域，也可看成一个Virtual Switch，或者Logical Switch

Neutron支持多种类型的Network，包括Local，Flat，VLAN，VXLAN和GRE。

• Local
  与其他网络和节点隔离。Local网络中的虚拟机只能与位于同一节点上同一网络的虚拟机通信，Local网络主要用于单机测试。
• Flat
  无VLAN tagging的网络。Flat网络中虚拟机只能与位于网络的虚拟机通信，并可以跨多个节点。
• VLAN
  802.1q tagging网络。VLAN是一个二层的广播域，同一VLAN中的虚拟机可以通信，不同VLAN只能通过Router通信。VLAN网络可跨节点，是应用最广泛的网络类型。
• VxLAN
  基于隧道技术的overlay网络。VXLAN网络通过唯一的segmentation ID（也叫VNI）与其他VXLAN网络区分。VXLAN中数据包会通过VNI封装成UDP包进行传输。因为二层的包通过封装在三层传输，能够克服VLAN和物理网络基础设施的限制。
• GRE
  与VXLAN类似的一种overlay网络，主要区别在于使用IP包而非UDP进行封装。

Port

在L2中，Neutron还提供了一个重要的网络资源抽象Port，其作为虚拟交换机上的一个虚拟端口。当一个port被创建时，默认情况下，会为它分配其指定subnet中可用的IP。

所以，port可以看作虚拟交换机上的一个端口。port上定义了MAC地址和IP地址，当instance的虚拟网卡VIF（Virtual Interface）绑定到port时，port会将MAC和IP分配给VIF。

port与subnet是1对多关系。一个port必须属于某个subnet；一个subnet可以有多个port。

Subnet

• 一个IPv4或者IPv6地址段。虚拟机的IP从Subnet中分配。每个Subnet需要定义IP的范围和掩码。
• Subnet必须与Network关联。
• Subnet可选属性：DNS，网关IP，静态路由。

Router（路由器）

连接租户内同一Network或不同Network之间的子网，以及连接内外网。

Fixed IP（固定IP）

分配到每个端口上的IP，类似于物理环境中配置到网卡上的IP。

Floating IP（浮动IP）

• Floating IP是从External Network创建的一种特殊Port，可以将Floating IP绑定到任意Network中的port上，底层会做NAT转发，将发送给Floating IP的流量转发到该Port对应的Fixed IP上。
• 外界可以通过Floating IP访问虚拟机，虚拟机也可以通过Floating IP访问外界。
  

Physical Network（物理网络）

在物理网络环境中连接OpenStack不同节点的网络，每个物理网络可以支持Neutron中的一个或多个虚拟网路。

Provider Network

• 由OpenStack管理员创建，直接对应于数据中心现有物理网络的一个网段。
• Provider Network通常使用VLAN或者Flat模式，可以在多个租户之间共享。
  

Self-Service Network

自助服务网络，也叫租户网络或项目网络

• 由OpenStack租户创建的，完全虚拟的，只在本网络内部连通，不能在租户间共享。
• Self-Service Network通常使用VXLAN或者GRE模式，可以通过Virtual Router的SNAT与Provider Network通信。
• 不同Self-Service Network的网段可以相同，类似于物理环境中不同公司的内部网络。
• Self-Service Network如果需要和外部物理网络通信，需要通过Router，类似于物理环境中公司上网需要通过路由器或防火墙。

External Network（外部网络，公共网络）

• 一种特殊的Provider Network，连接的物理网络与数据中心或Internet相通，网络中的Port可以访问外网。
• 一般将租户的Virtual Router连接到该网络，并创建Floating IP绑定虚拟机，实现虚拟机与外网通信。
  

Security Group （安全组）：

• 安全组是作用在neutron port上的一组策略，规定了虚拟机入口和出口流量的规则。
• 安全组基于Linux iptables实现。
• 安全组默认拒绝所有流量，只有添加了放行规则的流量才允许通过。
• 每个OpenStack项目都有一个default默认安全组，默认包含如下规则：
• 拒绝所有入口流量，允许所有出口流量。

Neutron 架构

OpenStack Neutron允许你创建网络接口并接上其他 OpenStack 元件管理的服务 (如 Nova VM)，使其能够连接到网络。可以通过不同的后端插件去适应不同的网络设备和软件，为 OpenStack 架构和部署提供灵活性。

上图层级解释：

• Neutron-server：该模块是一个进程，而且是Neutron唯一主要的服务进程，一般运行于控制节点，作为访问Neutron的入口。
• Neutron plugin：由core plugins和service plugins组成。担任类似接收请求派发任务的角色。
• Neutron Agent：负责接收消息并且执行任务的模块，与neutron plugin对应，扮演的是真正处理工作的角色。
• Neutron Queue：用于Neutron各个模块之间相互的通信，neutron-server通过它和各种agents之间交换路由信息。
• Neutron database：存放网络信息的数据库，默认使用的是Mariadb数据库。
• neutron provider：网络提供者，提供OpenStack网络服务的虚拟机或者物理网络的设备，例如Linux Bridge、OVS（Open vSwitch）或者其他可以正常Neutron的物理交换机。

类似于各个计算、存储节点被虚拟化为计算、存储资源池，Openstack所在的整个物理网络在Neutron中也被虚拟化为网络资源池。通过对网络资源的划分和可扩展性，Neutron能够为每个租户提供独立的虚拟网络环境。

Neutron分别提供了二层（L2）vSwitch交换和三层（L3）Router路由抽象的功能，对应于物理网络环境中的交换机和路由器的实现，具体实现了如下功能：

• Router：为租户提供路由、NAT等服务。
• Network：对应于一个真实物理网络中的二层局域网（VLAN），从租户的的角度而言，是租户私有的。
• Subnet：为网络中的三层概念，指定一段IPV4或IPV6地址并描述其相关的配置信息。它附加在一个二层Network上，指明属于这个network的虚拟机可使用的IP地址范围。

其概念主要跟一般实体设备一样，不过在 OpenStack 中通过软件达成的。

Neutron的工作流程

结合上图，假设现在要创建一个虚拟网络。整个流程是这样的：

1. Neutron-server收到要创建虚拟网络的请求，通过消息队列通知对应的插件，（先不考虑ML2）假设网络提供者（neutron provider）为OVS（Open vSwitch）。

2. OVS插件收到消息后，将需要创建的虚拟网络的信息（名称、ID值等）保存到Neutron database中并通过消息队列通知运行在各个节点上的agent。

3. agent 收到消息后会在节点上创建对应设备，例如vlan设备。

Neutron RPC

RPC是neutron中跨模块进行方法调用很重要的一种方式，client端用于发出rpc消息，server端用于监听消息并进行相应处理。

1. Agent 端 RPC 在 dhcp agent、l3 agent、 firewall agent以及metering agent的main函数中都能找到类似的创建一个Agent rpc服务端的代码。
2. plugin端的rpc。
3. neutron-server端的rpc。

Neutron-server分层模型

自上而下分别是：

Core API 和 Extension API

• Core API：Core API只对应于L2层的network/subnet/port三种抽象的RESTful API；
• Extension API：对外提供管理路由（router）、负载均衡（LB）、防火墙（firewall）等资源的RESTful API；

Neutron API实现的主要代码位于/neutron/api目录。

Common Service

用于认证和校验API请求；

Neutron Core

Neutron-server中的核心处理程序，去调用对应的插件处理请求；

Core Plugin API 和 Extension Plugin API

• Core Plugin API：用于给核心处理程序调用 Core Plugin 的接口；
• Extension Plugin API：与给核心处理程序调用 Extension Plugin 的接口；

Core Plugin 和 Service Plugin

分别对应核心插件和服务插件，核心插件响应核心API，服务插件响应扩展API；

其中，核心插件主要是在数据库中维护network、subnet和port的状态，并负责调用相应的agent在network provider上执行相关操作，比如创建network；服务插件主要是在数据库中维护router、load balance、security group等资源的状态，并负责调用相应的agent在network provider上执行相关操作，比如创建router。

Database

数据库，用于存放对应的数据信息。

补充的知识点

ML2 plugin

ML2 plugin被社区提出来的目的是用于取代所有的Core Plugin，它采用了更加灵活的结构进行实现。作为一个Core plugin，ML2 自然会实现network/subnet/port这三种核心资源，同时它也实现了包括Port Binding等在内的部分扩展资源。

ML2实现了网络拓扑类型（Flat、VLAN、VXLAN、GRE）和底层虚拟网络（linux bridge、OVS）分离的机制，并分别通过Driver的形式进行扩展。其中，不同的网络拓扑类型对应着type driver，由type manager管理，不同的网络实现机制对应着Mechanism Driver（比如Linux bridge、OVS、NSX等），由Mechanism Manager管理。

OpenvSwitch Agent

ML2 Plugin的主要工作是管理虚拟网络资源，保证数据正确无误，具体物理设备的设置则由Agent来完成，这里我们宏观阐述下Neutron项目中的OVS Agent。

基于Plugin rpc提供的信息，OVS Agent负责在计算节点和网络节点上，通过对OVS虚拟交换机的管理将一个Network映射到物理网络，这需要OVS Agent去执行一些linux 网络和OVS相关的配置与操作，Neutron通过如下两个库提供了最为基础的操作接口，从而可以通过Linux Shell命令完成OVS的配置。 比如：

ovs_lib.py

通过shell执行各种ovs-vsctl操作。 代码目录：neutron/agent/common

ip_lib.py

通过linux的br-ctl命令操作Linux的veth、router、namespace等。 代码目录：neutron/agent/linux/

主要是完成如下的一些工作：

1. agent初始化
2. agent和Plugin RPC的通信
3. br-int创建与初始化
4. br-eth初始化
5. br-tun初始化
6. 创建Tunnel Port
7. 分配LVID（Local VLAN ID）
8. L2 population