openstack 网络Neutron知识点《openstack》

1.Neutron概述

Neutron是 OpenStack项目中负责提供网络服务的组件，它基于软件定义网络的思想，实现了网络虚拟化下的资源管理。Neutron 的设计目标是实现“网络即服务（Networking as a Service）”，在设计上遵循了基于 SDN 实现网络虚拟化的原则，在实现上充分利用了 Linux 系统上的各种网络相关的技术。

2. Neutron功能

2.1. 二层交换

Neutron支持多种虚拟交换机，一般使用Linux Bridge和Open vSwitch创建传统的VLAN网络，以及基于隧道技术的Overlay网络，如VxLAN和GRE（Linux Bridge 目前只支持 VxLAN）。

2.2. 三层路由

Neutron从Juno版开始正式加入的DVR(Distributed Virtual Router)服务，它将原本集中在网络节点的部分服务分散到了计算节点上。
可以通过namespace中使用ip route或者iptables实现路由或NAT，也可以通过openflow给OpenvSwitch下发流表来实现。

2.3. 负载均衡

LBaaS 支持多种负载均衡产品和方案，不同的实现以 Plugin 的形式集成到 Neutron，通过HAProxy来实现。

2.4. 防火墙

Neutron有两种方式来保障instance和网络的安全性，分别是安全组以及防火墙功能，均可以通过iptables来实现，前者是限制进出instance的网络包，后者是进出虚拟路由器的网络包。

2.5 网络虚拟化

网络（network）是一个隔离的二层网段，类似于物理网络中的LAN（VLAN）。
具体一点，它是为创建它的租户保留的一个广播域。
端口和子网始终被分配给某个特定的网络。

跨网络的子网之间的流量必须走L3 Vritual Router。
每个网络使用自己的DHCP Agent，每个DHCP Agent在一个Network namespace内。
不同网络内的IP可以重复。

根据创建网络的用户，Neutron L2 network 可以分为：

• Provider network： 管理员创建的和物理网络有直接映射关系的虚拟网络。
• Tenant network： 租户（普通用户）创建的网络，物理网络对创建者透明，配置由 Neutron 的配置决定。

Provider Network 是由 OpenStack 管理员创建的，直接对应于数据中心的已有物理网络的一个网段。这种网络有三个和物理网络有关属性：

• provider:network_type (网络类型，包括 vxlan, gre, vlan, flat, local)
• provider:segmentation_id (网段 ID， 比如 VLAN 的 802.1q tag, GRE 网络的 Tunnel ID, VXLAN 网络的 VNI)
• provider:physical_network (物理网络的逻辑名称，比如 physnet1, ph-eth1, etc)

3.Network 类型

3.1 Local

Local网络，本地的一个Linux Bridge，除了虚拟机的虚拟网卡不连接其他的网络设备，实际场景很少使用，可以忽略。

3.2. Flat

Flat网络，不带vlan tag的网络，相当于Local网络的Linux Bridge连接到一个物理网卡，该网络中的instance能与同网络的instance通信，且可以跨多个节点，实际场景也很少用到。

所有的租户都在同一个网络内，没有进行网络隔离，容易产生广播风暴。可以跨节点，实际场景也较少。

neutron net-create NAME --provider:network_type flat \
  --provider:physical_network PHYS_NET_NAME

3.3. VLAN

VLAN网络，可以跨节点，目前是私有云网络应用较多。

基于物理Vlan网络实现，共享同一个物理网络的多个Vlan网络是相互隔离的，甚至可以使用重叠的IP空间。

每个支持VLAN network的物理网络可以被视为一个分离的VLAN trunk，使用一组独占的vlan id。（有效段为1~4096）

neutron net-create NAME --provider:network_type vlan \

        --provider:physical_network PHYS_NET_NAME \

        --provider:segmentation_id VID

3.4. VXALN

VXLAN网络，是基于隧道技术的 overlay 网络，通过唯一的VNI区分于其他 vxlan 网络。vxlan中数据包通过VNI封装成UPD包进行传输，因为二层的包通过封装在三层传输，能够克服vlan和物理网络基础设施的限制。

neutron net-create NAME --provider:network_type vxlan \

        --provider:segmentation_id TUNNEL_ID

3.5. GRE

GRE网络，与vxlan类似的一种overlay网络，使用IP包进行封装。
GRE 封装的数据包基于 IP 路由表来进行路由，因此 GRE network 不和具体的物理网络绑定。(基于隧道)

neutron net-create NAME --provider:network_type gre \

        --provider:segmentation_id TUNNEL_ID

3.6 虚拟网络类型特点以及应用场景

模式	原理	优点	缺点
VLAN	划分vlan，使用vlan_id隔离广播域	划分vlan，使用vlan_id隔离广播域	必须和物理交换机的vlan_id绑定, 最多只能有4096个;存在二层通讯的广播风暴问题;基于IP地址的子网划分问题
GRE	和vlan模式不同的.是vlan id 会被转换成gre id,外面在封IP.通过隧道转发出去.;2层的包,通过IP来转发.物理层的3层通信,虚拟上的2层通信.	gre id 可以有1600W个没有广播风暴;没有mac地址表过大的问题，物理交换机，只需要记住一个eth0的mac地址3层网络的通信	两个阶段需要建隧道，方案不成熟
VXLAN	相比较于gre，不使用隧道本质: 2层的包+封装vxlan id + 组播地址+ + udp报头 + ip 报头+数据包	不需要建隧道，使用udp方便的安全策略和gre id一样，也有1600W可以使用	缺点

4.Neutron架构

Neutron采用分布式架构，由多个组件共同对外提供网络服务，如下图所示：

由上图可以看到Neutron有以下组件构成：

• Neutron Server：对外提供OpenStack网络API，接收请求，并调用Plugin处理请求。
• Neutron Plugin：处理Neutron Server发来的请求，维护OpenStack逻辑网络的状态，并调用Agent处理请求。
• Neutron Agent：处理Plugin的请求，负责在Network Provider上真正实现各种网络功能。
• Network Provider：提供网络服务的虚拟或者物理网络设备，比如Linux Bridge，OpenVSwitch或者其他支持Neutron的物理交换机。
• Queue：Neutron Server，Plugin和Agent之间通过Messaging Queue通信和调用。
• Neutron Database：存放OpenStack的网络状态信息，包括Network，Subnet，Port，Router等。

举例说明
为了了解他们之间的关系，我们举个例子进行说明，创建一个VLAN100的Network，Network Provider是Linux Bridge：

1. Neutron Server接收到创建Network的请求，通过Message Queue(RabbitMQ)通知已注册的Linux Bridge Plugin。
2. Neutron Plugin将要创建的Network的信息(例如名称、VLAN ID等)保存到数据库中，并通过Message Queue通知运行在各节点上的Agent。
3. Neutron Agent收到消息后会在节点上的物理网卡(比如eth2)上创建VLAN设备(比如eth2.100)，并创建Bridge(比如brqXXX)桥接VLAN设备。

这里进行几点说明：

1. Neutron Plugin确定的是网络要配置成什么样子，而至于如何配置，则交由Neutron Agent完成。
2. Plugin，Agent和Network Provider是配套使用的，比如上例中Network Provider是Linux Bridge，那么就得使用Linux Bridge的Plugin和Agent；如果Network Provider换成了OVS或者物理交换机，Plugin和Agent也得替换。
3. Plugin的一个主要的职责是在数据库中维护Neutron网络的状态信息，这就造成一个问题：所有Network Provider的Plugin都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron在Havana版本实现了一个 ML2(Modular Layer 2) Plugin，对Plugin的功能进行抽象和封装。有了ML2 Plugin，各种Network Provider无需开发自己的Plugin，只需要针对ML2开发相应的Driver就可以了，工作量和难度都大大减少。ML2会在后面详细讨论。
4. Plugin按照功能分为两类：Core Plugin和Service Plugin。Core Plugin维护Neutron的Netowrk, Subnet和Port相关资源的信息，与Core Plugin对应的Agent包括Linux Bridge,OVS等；Service Plugin提供Routing, Firewall, Load Balance等服务，也有相应的Agent。

5.Neutron Server

由之前得知，Neutron Server向上提供API，向下调用Plugin，如下图

• Core API: 对外提供管理Network, Subnet和Port的RESTful API。
• Extension API: 对外提供管理Router, Load Balance, Firewall等资源的RESTful API。
• Commnon Service: 认证和校验 API 请求。
• Neutron Core: Neutron Server的核心处理程序，通过调用相应的Plugin处理请求。
• Core Plugin API: 定义了Core Plgin的抽象功能集合，Neutron Core通过该API调用相应的Core Plugin。
• Extension Plugin API: 定义了Service Plugin的抽象功能集合，Neutron Core通过该API调用相应的- Service Plugin。
• Core Plugin: 实现了Core Plugin API，在数据库中维护network, Subnet和Port的状态，并负责调用相应的Agent在Network Provider上执行相关操作，比如创建Network。
• Service Plugin: 实现了Extension Plugin API，在数据库中维护Router, Load Balance, Security Group等资源的状态，并负责调用相应的Agent在Network Provider上执行相关操作，比如创建Router。

6.Network Provider

由之前得知，Plugin，Agent和Network Provider的类型必须是配套的，常见的就是Linux Bridge和OVS的，分别如下图所示：

我们以Linux Bridge为例进行说明，介绍一下Plugin和Agent的工作。

Linux Bridge Core Plugin
实现Core Plugin API。
负责维护数据库信息。
通知Linux Bridge Agent实现具体的网络功能。


Linux Bridge Agent
接收来自Plugin的请求。
通过配置本节点上的Linux Bridge实现Neutron网络功能。

问题：
由上可知，需要添加Network Provider类型的时候，需要有配套的Plugin和Agent，这样存在两个问题：

1. 无法同时使用多种Network Provider，Core Plugin负责管理和维护Neutron的Network, Subnet和Port的状态信息，这些信息是全局的，只需要也只能由一个Core Plugin管理。只使用一个Core Plugin本身没有问题。但问题在于传统的Core Plugin与Core Plugin Agent是一一对应的。也就是说，如果选择了Linux Bridge Plugin，那么Linux Bridge Agent将是唯一选择，就必须在OpenStack的所有节点上使用Linux Bridge作为虚拟交换机（即Network Provider）。同样的，如果选择OpenvSwitch Plugin，所有节点上只能使用OpenvSwitch，而不能使用其他的Network Provider。
2. 开发新的Core Plugin工作量大，所有传统的Core Plugin都需要编写大量重复和类似的数据库访问的代码，大大增加了Plugin开发和维护的工作量。
   ML2作为新一代的Core Plugin，提供了一个框架，允许在OpenStack网络中同时使用多种Layer 2网络技术，不同的节点可以使用不同的网络实现机制。

如上图所示，采用ML2 Plugin后，可以在不同节点上分别部署Linux Bridge Agent, OpenvSwitch Agent, Hyper-V Agent以及其他第三方Agent。

ML2 不但支持异构部署方案，同时能够与现有的Agent无缝集成：以前用的Agent不需要变，只需要将Neutron Server上的传统Core Plugin替换为ML2。有了ML2，要支持新的Network Provider就变得简单多了：无需从头开发Core Plugin，只需要开发相应的Mechanism Driver，大大减少了要编写和维护的代码。

7.ML2 Core Plugin

ML2对二层网络进行抽象和建模，引入了Type Driver和Mechanism Driver。
   这两类Driver解耦了Neutron所支持的网络类型(Type)与访问这些网络类型的机制(Mechanism)，其结果就是使得ML2具有非常好的弹性，易于扩展，能够灵活支持多种Type和Mechanism

• Type Driver
  Neutron支持的每一种网络类型都有一个对应的ML2 Type Driver。Type Driver负责维护网络类型的状态，执行验证，创建网络等。ML2支持的网络类型包括Local, Flat, VLAN, VxLAN和GRE。
• Mechanism Driver
  Neutron支持的每一种网络机制都有一个对应的ML2 Mechanism Driver。Mechanism Driver负责获取由Type Driver维护的网络状态，并确保在相应的网络设备(物理或虚拟)上正确实现这些状态。

举例说明

Type和Mechanisim都太抽象，现在我们举一个具体的例子：Type Driver为Vlan，Mechanism Driver为Linux Bridge，我们要完成的操作是创建Network VLAN100，那么：

（1）VLAN Type Driver会确保将VLAN100的信息保存到Neutron数据库中，包括Network的名称，VLAN ID等。

（2）Linux Bridge Mechanism Driver会确保各节点上的Linux Brige Agent在物理网卡上创建ID为100的VLAN设备和Brige设备，并将两者进行桥接。

• Mechanism Driver有三种类型：
  （1）Agent-based: 包括Linux Bridge，OpenvSwitch等。
  （2）Controller-based: 包括OpenDaylight，VMWare NSX等。
  （3）基于物理交换机: 包括Cisco Nexus，Arista，Mellanox等。

8.Service Plugin/Agent

Core Plugin/Agent负责管理核心实体：Net, Subnet和Port。而对于更高级的网络服务，则由Service Plugin/Agent管理。

Service Plugin及其Agent提供更丰富的扩展功能，包括路由，Load Balancer，Firewall等，如图所示：

• DHCP: DHCP Agent通过dnsmasq为Instance提供DHCP服务。
• Routing: L3 Agent可以为Project(租户)创建Router，提供Neutron Subnet之间的路由服务。路由功能默认通过IPtables实现。
• Firewall: L3 Agent可以在Router上配置防火墙策略，提供网络安全防护。
• Load Balancer: Neutron默认通过HAProxy为Project中的多个Instance提供Load Balancer服务。

9.总结

前面我们详细讨论了Neutron架构，包括Neutron Server，Core/Service Agent。现在用两张图做个总结：

• Neutron通过Plugin和Agent提供的网络服务。
• Plugin位于Neutron Server，包括Core Plugin和Service Plugin。
• Agent位于各个节点，负责实现网络服务。
• Core Plugin提供L2功能，ML2是推荐的plugin。
• 使用最广泛的L2 Agent是Linux Bridage和OpenvSwitch。
• Service Plugin和Agent提供扩展功能，包括DHCP, Routing, Load Balancer, Firewall, VPN等。

如果我们有了controller之后，比如OVN，那么vm可以直接连接ovs的br-int，bridge就可以去掉了，封装和解封装也会直接放在br-int，也就是只剩下vm和ovs的br-int，而诸如Security Group、DVR等等一系列的功能都可以用openflow流表去实现，这样就大大增加了流表的数量，减少了桥的使用。

参考文档

​​https://zhaozhanxu.com/index.php/archives/131/​​