Openstack Core Service -- Neutron

目录

 

Neutron 功能

1、二层交换:

  原生支持 Linux Bridge和 Open vSwitch。

2、三层路由:

  通过linux ip_forward实现路由功能,通过linux iptables实现NAT功能,通过Linux network namespace实现租户隔离。

3、Load Balancing:

   默认通过HA Proxy Plugin来实现

4、Firewall :

  SecurityGroup--通过 linux iptables来实现 Instance的安全。

  Firewall-as-a-Serivce -- 通过Router的iptables来实现Network的安全。

 

Neutron 组件

1、Neutron Server

  Neutron Server提供了一些列的北向REST API, Core API 和 Extension API

  对外提供Openstack Neutron API,接收API请求调用相应的Openstack networking plug-in.

2、plug-ins

  Core plugin、Service plugin

  ML2 plugin(Core plugin)

   - type drivers: local、float、vlan、vxlan、gre

   - mechanism drivers: l2 population、linuxbridgeOpenvSwitch

3、agents

  l2 agent、l3 agent、dhcp agent、Metadata agent

 

总结:

  Plugin解决的是What的问题,即网络需要配置成什么样子?

  Agent解决的是How的问题,即如何配置。

  Core plugin和Service plugin已经集成到Neutron Server中,不需要运行独立的plugin服务。

 

ML2 Core Plugin

  Moduler Layer 2(ML2)是 Neutron 在 Havana 版本实现的一个新的 core plugin,用于替代原有的 linux bridge plugin 和 open vswitch plugin.

传统 core plugin 的问题

  之所以要开发 ML2,主要是因为传统 core plugin 存在两个突出的问题。

问题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)。

  同样的,如果选择 open vswitch plugin, 所有节点上只能使用 open vswitch,而不能使用其他的 network provider。

问题2:开发新的 core plugin 工作量大

  所有传统的 core plugin 都需要编写大量重复和类似的数据库访问的代码,大大增加了 plugin 开发和维护的工作量。

ML2 能解决传统 core plugin 的问题

  ML2 作为新一代的 core plugin,提供了一个框架,允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术,不同的节点可以使用不同的网络实现机制。

  如上图所示,采用 ML2 plugin 后,可以在不同节点上分别部署 linux bridge agent, open vswitch agent, hyper-v agent 以及其他第三方 agent。

ML2 的架构

  ML2 对二层网络进行抽象和建模,引入了 type driver 和 mechansim driver。

image509.png

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

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

 

Service Plugin

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20160817-1471386024579053061.jpg

 

Open vSwitch 二层网络的实现

OpenvSwitch中 bridge 有两种模式:

  1、normal

  2、flow

“normal” 模式的 bridge 同普通的L2交换机数据转发模式一样,而 “flow” 模式的 bridge 是根据其流表(flow tables) 来进行转发的。

Neutron 使用了两种 OVS bridge:

  1、br-int

  2、br-tun。

其中,br-int 是一个 “normal” 模式的虚拟网桥,而 br-tun 是 “flow” 模式的,它比 br-int 复杂得多。

 

三层架构:  eth1 ---- br-tun(patch port) ---- (patch port)br-int(veth pair) ---- (veth pair)linux-bridge(port tap) ---- instance

Neutron OVS Bridge 连接方式 (veth pair / ovs peer) 的选型和性能测试

Open vSwitch: Self-service networks architecture

 

VXLAN vs GRE

  GRE有一个缺点,那就是每新增一个计算节点,都需要其和所有其他计算节点以及network控制器建立GRE链接。在计算节点很多的时候会有性能问题。

 

L2 population

  Neutron通过L2pop特性解决了L2层无控制平面的问题,从而让Neutron具备更高的性能,适应更大规模的部署。L2 Population 到底解决了怎样的 Scalability 问题?

请看下图:

  这是一个包含 5 个节点的 VXLAN 网络,每个节点上运行了若干 VM。

  现在假设 Host 1 上的 VM A 想与 Host 4 上的 VM G 通信,VM A 要做的第一步是获知 VM G 的 MAC 地址。
  于是 VM A 需要在整个 VXLAN 网络中广播 APR 报文:“VM G 的 MAC 地址是多少?”

http://7xo6kd.com1.z0.glb.clouddn.com/upload-ueditor-image-20161115-1479163344611003441.jpg?_=6064244

  如果 VXLAN 网络的节点很多,广播的成本会很大,这样 Scalability 就成问题了。幸好 L2 Population 出现了。

L2 Population 的作用是在 VTEP 上提供 Porxy ARP 功能,使得 VTEP 能够预先获知 VXLAN 网络中如下信息:
  1. VM IP – MAC 对应关系
  2. VM – VTEP 的对应关系

当 VM A 需要与 VM G 通信时:
  1. Host 1 上的 VTEP 直接响应 VM A 的 APR 请求,告之 VM G 的 MAC 地址。
  2. 因为 Host 1 上的 VTEP 知道 VM G 位于 Host 4,会将封装好的 VXLAN 数据包直接发送给 Host 4 的 VTEP。

这样就解决了 MAC 地址学习和 APR 广播的问题,从而保证了 VXLAN 的 Scalability。

VTEP 是如何提前获知 IP – MAC – VTEP 相关信息的呢?

答案是:
  1. Neutron 知道每一个 port 的状态和信息;port 保存了 IP,MAC 相关数据。
  2. instance 启动时,其 port 状态变化过程为:down -> build -> active。
  3. 每当 port 状态发生变化时,Neutron 都会通过 RPC 消息通知各节点上的 Neutron agent,使得 VTEP 能够更新 VM 和 port 的相关信息
  4. VTEP 可以根据这些信息判断出其他 Host 上都有哪些 VM,以及它们的 MAC 地址,这样就能直接与之通信,从而避免了不必要的隧道连接和广播。

 

Open vSwitch 三层网络实现

DVR 提出的背景

  在DVR被提出之前, 由于Neutron的legacy router只会部署在网络节点上,因此会造成网络节点的流量过大,从而产生了两个问题,其一是网络节点将成为整个 Neutron 网络的瓶颈,其二是网络节点单点失败的问题。

  在这样的背景下,OpenStack社区在Juno版本里正式引入了 DVR(Distributed Virtual Router)

  DVR,顾名思义就是 Neutron 的 router 将不单单部署在网络节点上,所有启动了 Neutron L3 Agent 的节点,都会在必要时在节点上创建 Neutron router 对应的 namepsace,并更新与 DVR router 相关的 Openflow 规则,从而完成 DVR router 在该节点上的部署。

  在计算节点上部署了 DVR router 后:

  E-W 方向上的流量不再需要将数据包发送到网络节点后再转发,而是有本地的 DVR router 直接进行跨子网的转发;

  N-S 方向上,对于绑定了 floating IP 的虚机,其与外网通信时的数据包也将直接通过本地的 DVR router 进行转发

  从而,Neutron 网络上的一些流量被分摊开,有效地减少了网络节点上的流量;通信不再必须通过网络节点,也提升了 Neutron 网络的抗单点失败的能力。

  DVR配置示例

  Openstack-Newton Networking Guide

 

配置了DVR后需要注意的是 NAT,使用集中式的NAT还是分布式的NAT。

 

软件定义网络(SDN)

定义:

  1、控制平面和数据平面分离。

  2、转发目标的决定基于流表(flow table) 而非目的设备。

  3、集中控制,可编程性。

 

  在控制平面和数据平面分离之后,Openflow交换机很“傻”,对于没有 flow table规则的数据包到来之后,它不知道往哪个端口转发,于是就询问控制器。控制器经过一些计算之后下发流表告诉它往哪里转发。

  Openflow控制器与Openflow交换机之间的南北向协议称之为 Openflow。

  Openflow并不像传统网络那样一层一层剥包抽取出MAC在L2转发,抽取出IP在L3转发。 Openflow是根据端口号、VLAN、L2/L3/L4信息的10个关键字在控制器层通过字符串匹配进行转发的。因此Openflow不仅具备了L2功能,也同时具备L3、L4功能。 但是目前Neutron中的Openflow插件仅仅实现了L2的功能。

  想基于flow table的Openflow具备L2功能,请参考Google B4的架构。

  Neutron针对L2提供了ML2 Plugin,针对L2没有Plugin机制,目前只是使用Linux ipv4 forward特性的L3-agent来实现L3功能。遗憾的是,这种严格的分层思想仅适合传统的网络服务,对于SDN这种不分层偏平的新兴网络技术来说就支持的不好,所以目前Neutron ML2 SDN Plugin仅仅支持L2, 也就是说在Openstack中是将Openflow设备当二层交换机设备来使用的。

 

Linux Network Namespace

  在专业的网络世界中,经常使用到Virtual Routing and Forwarding(VRF),比如Cisco,Alcatel-Lucent, Juniper 等。

  在linux中,VRF被叫做“network namespace”,每个network namespace拥有其对应的路由表(routing table)& 其对应的iptables,并且运行程序运行其中。

network namespace相关命令:

root@server01:~# ip netns help
Usage: ip netns list
       ip netns add NAME
       ip netns set NAME NETNSID
       ip [-all] netns delete [NAME]
       ip netns identify [PID]
       ip netns pids NAME
       ip [-all] netns exec [NAME] cmd ...
       ip netns monitor
       ip netns list-id
root@server01:~# 

 

posted @ 2017-04-08 16:33  Vincen_shen  阅读(340)  评论(0)    收藏  举报