OpenStack.004 基本概念之neutron

1  Neutron 概述

      SDN ­­ (software­defined networking)软件定义网络所具有的灵活性和自动化优势使其成为云时代网络管理的主流。

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

2  Neutron 功能

      Neutron 为整个 OpenStack 环境提供网络支持,包括二层交换,三层路由,负载均衡,防火墙和VPN 等。Neutron 提供了一个灵活的框架,通过配置,无论是开源还是商业软件都可以被用来实现这些功能。

1)二层交换 Switching

      Nova 的 Instance 是通过虚拟交换机连接到虚拟二层网络的。

      Neutron 支持多种虚拟交换机,包括 Linux 原生的 Linux Bridge 和 第三方Open vSwitch。

      利用 Linux Bridge 和 OVS,Neutron 除了可以创建传统的 VLAN 网络,还可以创建基于隧道技术的 Overlay 网络,比如 VxLAN 和 GRE(Linux Bridge 目前只支持 VxLAN,此外,由于GRE容易单点故障已经被弃用)。

      Open vSwitch ­­ (OVS)是一个开源的虚拟交换机,它支持标准的管理接口和协议。比Linuxbridge的功能更强大,是为了配合neutron而产生的。

2)三层路由 Routing

      Instance 可以配置不同网段的 IP,Neutron 的 router(虚拟路由器)实现 instance 跨网段通信。router 通过 IP forwarding,iptables 等技术来实现路由和 NAT。dhcp获取的地址一般是私网地址,极个别是公网地址,这取决于使用了哪种通讯方式。

3)负载均衡 Load Balancing

      提供了将负载分发到多个 instance 的能力。LBaaS 支持多种负载均衡产品和方案,不同的实现以 Plugin 的形式集成到 Neutron,目前默认的 Plugin 是 HAProxy。所以不用搭建LVS,直接设置策略就可以。

4)防火墙 Firewalling

      Security Group 通过 iptables 限制进出 instance 的网络包。

      Firewall­as­a­Service FWaaS,限制进出虚拟路由器的网络包,也是通过 iptables 实现。

      防火墙的本质都是使用内核挂载的filter模块,只不过实现的方式有所区别,firewalld是利用分区实现,iptables是利用三表五链实现。

3  Neutron 管理的网络资源

1)network

      local——网络中的 instance 只能与位于同一节点上同一网络的 instance 通信,local 网络主要用于单机测试。

      flat——网络是无 vlan tagging 的网络,其实就是交换机形成的二层网络,和网桥一样。flat 网络中的 instance 能与位于同一网络的 instance通信,并且可以跨多个节点。

      VLAN——网络是具有 802.1q tagging 的网络,一共可以划分4095个子网。vlan 是一个二层的广播域,同一 vlan 中的instance 可以通信,不同 vlan 只能通过 router 通信。vlan 网络可以跨节点,是应用最广泛的网络类型。

      交换机连接的主机都属于同一个子网,但是在云环境中,我们需要分隔每个客户租用的若干虚拟机为单独的子网,但是我们不可能购买那么多交换机来给客户划分子网。这就需要使用VLAN来实现划分子网的功能。那么VLAN是如何分隔子网的呢?

说明:

      究竟哪个端口的VID是几号都是我们自己根据需要定义的,假设定义成如图所示,那么A只能与C通信,B只能与D通信;

      access接口是各个主机连接的接口,当某主机,如A,发送数据包到switch 1时,switch 1 的接口VID 11会给数据包做个VLAN标记,指明A发出的数据包来自于自己——VID 11 。

      trunk口,用于识别VID,并且用于限制哪个VID能够通过自己这条路,并且不会去除VID标记,直接放行到switch 2 ,从而数据包就会从switch 2 的VID 11传给C主机。

      hpport口是用于识别VID并且擦除VID标记,让数据包能够传给server。多以如果有主机想要访问server服务器时,hpport口接收到数据包后发现是发给server的就会擦除数据包上的VID标记以便server能够识别数据包的来源。

      VxLAN——基于隧道技术的 overlay 网络,是VLAN的扩展。VxLAN有1600万个VNI编号,足够在云计算平台使用了。vxlan 网络通过唯一的 segmentation ID(也叫VNI)与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UPD 包进行传输。因为二层的包通过封装在三层传输,能够克服 vlan 和物理网络基础设施的限制。Linuxbridge只支持VxLAN。

      GRE——与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。不同 network 之间在二层上是隔离的。现在已经被弃用了。

      network 必须属于某个 Project( Tenant 租户),Project 中可以创建多个 network。network 与 Project 之间是 多对1的关系。

注意:

      VPN 虚拟专用网络,还没有加到openstack的功能中。VPN的应用场景:总公司A有3个分布在三个省份的分公司A1、A2、A3;总公司租用了一个OA系统,希望分公司也能够使用。但是如果使用iptables端口映射策略设置成外网都能够访问总公司OA系统的话,会很不安全,因为暴露在外网环境下就意味着大家都能访问。所以总公司如果能够让分公司能够像访问局域网一样访问就好了,这就需要VPN。

      VPN就是在总公司的某接口上与分公司某接口上建立一条虚拟的链路,链路的建立需要两端都有互相的ip并且有相应的通信口令与加密方式。这样的话就能够通过该链路进行通信了。而如果分公司的员工不在公司内,也可以通过VPN软件输入用户名与密码进行连接。翻墙就是使用了VPN技术。

2)subnet

      subnet 是一个 IPv4 或者 IPv6 地址段。instance 的 IP 从 subnet 中分配。每个 subnet 需要定义 IP 地址的范围和掩码。

      subnet 与 network 是 1对多 关系。一个 subnet 只能属于某个 network;一个 network 可以有多个 subnet,这些 subnet 可以是不同的 IP 段,但不能重叠。例如,以下这两种设置都是被允许的:

3)port

      port 可以看做虚拟交换机上的一个端口。port 上直接定义了 MAC 地址和 IP 地址,当 instance的虚拟网卡 VIF(Virtual Interface) 绑定到 port 时,port 会将 MAC 和 IP 分配给 VIF。而原来我们做网桥时,是虚拟机的网卡eth0在物理机里对应的是vnet0,vnet0是加在br0上的。

      port 与 subnet 是 1对多 关系。一个 port 必须属于某个 subnet;一个 subnet 可以有多个port。有了port直接定义MAC与IP就不用使用ARP与RARP协议了。

      综上所述,我们可以知道neutron定义的三大网络资源只是二层的网络资源,与三层的没有关系。

4  Neutron 架构

1)说明:

      neutron server:对外提供 OpenStack 网络API,接收请求,并调用Plugin处理请求。

      queue:Neutron Server,Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。

      neutron plugin:处理 Neutron Server 发来的请求,维护 OpenStack 逻辑网络的状态, 并调用 Agent 处理请求。

      neutron agent:处理 Plugin请求,负责在 network provider 上真正实现各种网络功能。

      neutron provider:提供网络服务的虚拟或物理网络设备,例如 Linux Bridge,Open vSwitch或者其他支持 Neutron 的物理交换机。

      neutron database:存放 OpenStack 的网络状态信息,包括 Network, Subnet, Port, Router等。

      综上所述,当访问到neutron的API,也就是neutron server时,如果是核心请求(扩展请求),就又核心插件(扩展插件)如LB、OVS等找到agent代理,agent代理命令network provider执行命令。

      此外,neutron支持分布式部署,获得足够的扩展性,架构非常灵活,层次较多,为了支持各种现有或者将来会出现的优秀网络技术。

2)搭建neutron的理论方案

方案1:控制节点+计算节点

这种方案有一个缺点,从计算节点返回的消息都要让控制节点接收与处理,这无疑加重了控制节点的负载,所以这种方法不推荐。推荐方案2。

方案2:控制节点+网络节点+计算节点

5  neutron 分层结构

core API ——对外提供管理 network, subnet 和 port 的 RESTful API。

extension API —— 对外提供管理 router, load balance, firewall 等资源 的 RESTful API。

common service ——认证和校验 API 请求。

neutron core­­ Neutron server 的核心处理程序,通过调用相应的 Plugin 处理请求。

core plugin API­­ 定义了 Core Plgin 的抽象功能集合,Neutron Core 通过该 API 调用相应的 Core Plgin。

extension plugin API­­ 定义了 Service Plgin 的抽象功能集合,Neutron Core 通过该 API调用相应的 Service Plgin。

core plugin API­­ 实现了 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  Neutron ML2 解决 core plugin 的问题

      Core plugin 负责管理和维护 Neutron 的 network, subnet 和 port 的状态信息,这些信息是全局的,只需要也只能由一个 core plugin 管理。所有传统的 core plugin 都需要编写大量重复和类似的数据库访问的代码,大大增加了 plugin 开发和维护的工作量。所以openstack平台自己编写了完整的core plugin,到时候只是用openstack的core plugin即可

      如上图所示,采用 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,大大减少了要编写和维护的代码。

2)Neutron ML2 的架构

  • Type Driver

Neutron 支持的每一种网络类型都有一个对应的 ML2 type driver。

type driver 负责维护网络类型的状态,执行验证,创建网络等。

ML2 支持的网络类型包括 local, flat, vlan, vxlan 和 gre。

  • Mechansim Driver

Neutron 支持的每一种网络机制都有一个对应的 ML2 mechansim driver。

mechanism driver 负责获取由 type driver 维护的网络状态,并确保在相应的网络设备(物理或虚拟)上正确实现这些状态。

type 和 mechanisim 都太抽象,现在我们举一个具体的例子:

type driver 为 vlan,mechansim 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, open vswitch 等。

controller-based­­ 包括 OpenDaylight, VMWare NSX 等。

基于物理交换机 ­­ 包括 Cisco Nexus, Arista, Mellanox 等。

     

      比如前面那个例子如果换成 Cisco 的 mechanism driver,则会在 Cisco 物理交换机的指定 trunk 端口上添加 vlan100。

      linux bridge 和 open vswitch 的 ML2 mechanism driver 其作用是配置各节点上的虚拟交换机。

      linux bridge driver 支持的 type 包括 local, flat, vlan, and vxlan。

      open vswitch driver 除了这 4 种 type 还支持 gre。

      L2 population driver 作用是优化和限制 overlay 网络中的广播流量。

      vxlan 和 gre 都属于 overlay 网络。

      ML2 core plugin 已经成为 OpenStack Neutron 的首选 plugin,本教程后面会讨论如何在实验环境中配置 ML2 的各种 type 和 mechansim。

7  Neutron Service Plugin/Agent

      core plugin/agent­­ 负责管理核心实体:net, subnet 和 port。将 instance 连接到OpenStack layer 2 虚拟网络

      service plugin/agent­­ 负责管理更高级的网络服务扩展功能,route,load balance,firewall等

      DHCP——dhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务。由dnsmasq分配的网络参数是终身享有的,除非手动删掉或者手动强制回收。

      routing­­ l3 agent 可以为 project(租户)创建 router,提供 Neutron subnet 之间的路由服务。路由功能默认通过 IPtables 实现。

      firewall­­ l3 agent 可以在 router 上配置防火墙策略,提供网络安全防护。

      security group­­ 通过 IPtables 实现。Firewall 安全策略位于 router,保护的是某个 project 的所有 network。Security Group 安全策略位于 instance,保护的是单个 instance。

      load  balance­­ Neutron 默认通过 HAProxy 为 project 中的多个 instance 提供 load balance服务。

8  neutron总结

 

      Neutron 采用的是分布式架构,包括 Neutorn Server、各种 plugin/agent、database 和 message  queue。Neutron server 接收 api 请求。plugin/agent 实现请求。database 保存 neutron 网络状态。message queue 实现组件之间通信。

Neutron 通过 plugin 和 agent 提供的网络服务。

plugin 位于 Neutron server,包括 core plugin 和 service plugin。

agent 位于各个节点,负责实现网络服务。

core plugin 提供 L2 功能,ML2 是推荐的 plugin。

使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。

      service plugin和agent提供扩展功能,包括 dhcp, routing, load balance, firewall, vpn 等。


转载请注明出处,谢谢!

猜你喜欢

转载自blog.csdn.net/qq_35550345/article/details/87855549