赵占旭的博客

Neutron初识

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采用分布式架构,由多个组件共同对外提供网络服务,如下图所示:

avatar

由上图可以看到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:

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

这里进行几点说明:

  1. Plugin确定的是网络要配置成什么样子,而至于如何配置,则交由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。

Neutron Server

由之前得知,Neutron Server向上提供API,向下调用Plugin,如下图所示:

avatar

  • 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的,分别如下图所示:

avatar
avatar

我们以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网络技术,不同的节点可以使用不同的网络实现机制。

avatar

如上图所示,采用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。

avatar

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有三种类型:

  • 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等,如图所示:

avatar

  • 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。现在用两张图做个总结。

avatar

avatar

  • 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。

1
core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin

在/etc/neutron/plugins/ml2/ml2_conf.ini配置Mechanism Driver。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[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之后的如图所示:

avatar

上图是一种很经典方案,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流表去实现,这样就大大增加了流表的数量,减少了桥的使用。

注意:所有文章非特别说明皆为原创。为保证信息与源同步,转载时请务必注明文章出处!谢谢合作 :-)

原始链接:http://zhaozhanxu.com/2017/06/10/OPENSTACK/2017-06-10-neutron1/

许可协议: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。