Neutron的学习都是参照大神CloudMan的博客，然后针对自己的情况整理的一些需要记录的信息，当然有不少资料可能会原封不动的搬过来。
Neutron功能
- 二层交换，一般使用Linux Bridge或者OpenvSwitch作为虚拟交换机，创建简单的VLAN网络，或者是overlay网络(VXLAN、GRE、Geneve或者STT等)。
- 三层路由，通过namespace中使用ip route或者iptables实现路由或者NAT，也可以通过openflow给OpenvSwitch下发流表实现。
- 负载均衡，通过namespace中使用lvs和haproxy实现负载均衡，应该也是可以通过openflow给OpenvSwitch下发bundle action的流表实现，这块我还不熟悉。
- 防火墙，桥环境使用iptables实现，也可以通过openflow给OpenvSwitch下发流表均可实现安全组和防火墙。
Neutron网络基本概念
Project(Tenant租户)，Network，Subnet，Port和VIF之间的关系
Project 1:m Network 1:m Subnet 1:m Port 1:1 VIF m:1 Instance
Network
Network是一个隔离的二层广播域，类型有Local、Flat、VLAN、VxLAN和GRE。每个Network有一个VNI，进行隔离。租户可以创建多个Network。
- Local 网络，本地的一个Linux Bridge，除了虚拟机的虚拟网卡不连接其他的网络设备，实际场景很少使用，可以忽略。
- Flat 网络，没有VLAN tagging的网络，相当于Local网络的Linux Bridge连接到一个物理网卡，实际场景也很少使用。
- VLAN 网络，进行隔离，目前应该是私有云网络用的多一些。
- VxLAN 网络，基于隧道的网络，克服了VLAN规模限制和物理网络限制，规模由4k升级到16M，物理网络从2层可达的要求到3层可达。
- GRE 也是隧道网络，基于IP的封装。
Subnet
Subnet就是一个网段，网段之间需要通过router来进行通信。
Port
Port可以看做是虚拟交换机上的一个端口，定义了MAC和IP，当虚拟网卡VIF(Virtual Interface)绑定到port时，port会将MAC和IP分配给VIF。
Neutron架构
Neutron采用分布式架构，由多个组件共同对外提供网络服务，如下图所示：
由上图可以看到Neutron有以下组件构成：
- Neutron Server：对外提供OpenStack网络API，接收请求，并调用Plugin处理请求。
- Plugin：处理Neutron Server发来的请求，维护OpenStack逻辑网络的状态，并调用Agent处理请求。
- Agent：处理Plugin的请求，负责在Network Provider上真正实现各种网络功能。
- Network Provider：提供网络服务的虚拟或者物理网络设备，比如Linux Bridge，OpenVSwitch或者其他支持Neutron的物理交换机。
- Queue：Neutron Server，Plugin和Agent之间通过Messaging Queue通信和调用。
- Database：存放OpenStack的网络状态信息，包括Network，Subnet，Port，Router等。
为了了解他们之间的关系，我们举个例子进行说明，创建一个VLAN100的Network，Network Provider是Linux Bridge：
- Neutron Server接收到创建Network的请求，通过Message Queue(RabbitMQ)通知已注册的Linux Bridge Plugin。
- Plugin将要创建的Network的信息(例如名称、VLAN ID等)保存到数据库中，并通过Message Queue通知运行在各节点上的Agent。
- Agent收到消息后会在节点上的物理网卡(比如eth2)上创建VLAN设备(比如eth2.100)，并创建Bridge(比如brqXXX)桥接VLAN设备。
这里进行几点说明：
- Plugin确定的是网络要配置成什么样子，而至于如何配置，则交由Agent完成。
- Plugin，Agent和Network Provider是配套使用的，比如上例中Network Provider是Linux Bridge，那么就得使用Linux Bridge的Plugin和Agent；如果Network Provider换成了OVS或者物理交换机，Plugin和Agent也得替换。
- Plugin的一个主要的职责是在数据库中维护Neutron网络的状态信息，这就造成一个问题：所有Network Provider的Plugin都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron在Havana版本实现了一个 ML2(Modular Layer 2) Plugin，对Plugin的功能进行抽象和封装。有了ML2 Plugin，各种Network Provider无需开发自己的Plugin，只需要针对ML2开发相应的Driver就可以了，工作量和难度都大大减少。ML2会在后面详细讨论。
- Plugin按照功能分为两类：Core Plugin和Service Plugin。Core Plugin维护Neutron的Netowrk, Subnet和Port相关资源的信息，与Core Plugin对应的Agent包括Linux Bridge,OVS等；Service Plugin提供Routing, Firewall, Load Balance等服务，也有相应的Agent。
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。
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，这样存在两个问题：
- 无法同时使用多种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。
- 开发新的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，大大减少了要编写和维护的代码。
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，那么：
- VLAN Type Driver会确保将VLAN100的信息保存到Neutron数据库中，包括Network的名称，VLAN ID等。
- Linux Bridge Mechanism Driver会确保各节点上的Linux Brige Agent在物理网卡上创建ID为100的VLAN设备和Brige设备，并将两者进行桥接。
Mechanism Driver有三种类型：
- Agent-based: 包括Linux Bridge，OpenvSwitch等。
- Controller-based: 包括OpenDaylight，VMWare NSX等。
- 基于物理交换机: 包括Cisco Nexus，Arista，Mellanox等。
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服务。
总结
前面我们详细讨论了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等。
示例
我们以Type Driver为VxLAN，Mechanism Driver为OpenvSwitch为例进行配置说明。后续其他模块的配置我们也会以此为基础。
在/etc/neutron/neutron.conf配置ML2 Core Plugin。
core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin在/etc/neutron/plugins/ml2/ml2_conf.ini配置Mechanism Driver。
[ml2]
tenant_network_types = vxlan
type_drivers = local,flat,vlan,gre,vxlan
mechanism_drivers=openvswitch,l2population
[ml2_type_vxlan]
vni_ranges = 1001:2000
[agent]
tunnel_types = vxlan
l2_population = True
[ovs]
bridge_mapping =
tunnel_bridge = br-tun
local_ip = x.x.x.x最终创建VxLAN100之后的如图所示：
上图是一种很经典方案，vm通过bridge连接ovs的br-int，bridge中可以做Security Group等一些工作。br-int作为一个典型的2层交换机，通过patch口和br-tun进行连接，br-tun主要负责VxLAN的封装和解封装。
如果我们有了controller之后，比如OVN，那么vm可以直接连接ovs的br-int，bridge就可以去掉了，封装和解封装也会直接放在br-int，也就是只剩下vm和ovs的br-int，而诸如Security Group、DVR等等一系列的功能都可以用openflow流表去实现，这样就大大增加了流表的数量，减少了桥的使用。