一、Neutron概述
Neutron是 OpenStack项目中负责提供网络服务的组件,它基于软件定义网络的思想,实现了网络虚拟化下的资源管理。Neutron 的设计目标是实现“网络即服务(Networking as a Service)”,在设计上遵循了基于 SDN 实现网络虚拟化的原则,在实现上充分利用了 Linux 系统上的各种网络相关的技术。
二、Neutron功能
1. 二层交换
Neutron支持多种虚拟交换机,一般使用Linux Bridge和Open vSwitch创建传统的VLAN网络,以及基于隧道技术的Overlay网络,如VxLAN和GRE(Linux Bridge 目前只支持 VxLAN)。
2. 三层路由
Neutron从Juno版开始正式加入的DVR(Distributed Virtual Router)服务,它将原本集中在网络节点的部分服务分散到了计算节点上。可以通过namespace中使用ip route或者iptables实现路由或NAT,也可以通过openflow给OpenvSwitch下发流表来实现。
3. 负载均衡
LBaaS 支持多种负载均衡产品和方案,不同的实现以 Plugin 的形式集成到 Neutron,通过HAProxy来实现。
4. 防火墙
Neutron有两种方式来保障instance和网络的安全性,分别是安全组以及防火墙功能,均可以通过iptables来实现,前者是限制进出instance的网络包,后者是进出虚拟路由器的网络包。
三、Network
1. Local
Local网络,本地的一个Linux Bridge,除了虚拟机的虚拟网卡不连接其他的网络设备,实际场景很少使用,可以忽略。
2. Flat
Flat网络,不带vlan tag的网络,相当于Local网络的Linux Bridge连接到一个物理网卡,该网络中的instance能与同网络的instance通信,且可以跨多个节点,实际场景也很少用到。
3. VLAN
VlAN网络,可以跨节点,目前是私有云网络应用较多。
4. VXALN
VXLAN网络,是基于隧道技术的 overlay 网络,通过唯一的VNI区分于其他 vxlan 网络。vxlan中数据包通过VNI封装成UPD包进行传输,因为二层的包通过封装在三层传输,能够克服vlan和物理网络基础设施的限制。
5. GRE
GRE网络,与vxlan类似的一种overlay网络,使用IP包进行封装。
四、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:
(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,如下图
- 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,这样存在两个问题:
(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,大大减少了要编写和维护的代码。
七、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等。
八、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等。
如果我们有了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/
参考资料:http://www.cnblogs.com/CloudMan6/
感谢各位大神们~