Openstack Core Service

竹子开花的时

目录

• 
  Neutron 功能
  
• 
  Neutron 组件
  
• 
  Ml2 Core Plugin
  
• 
  Service Plugin
  
• 
  Open vSwitch 二层网络实现
  
• 
  VXLAN vs GRE
  
• 
  L2 Population
  
• 
  Open vSwitch 三层网络实现
  
• 
  SDN
  
• 
  Linux Network Namespace
  
• 未完待续
  

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、linuxbridge、OpenvSwitch

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。
　　
　　　　type driver 负责维护网络类型的状态，执行验证，创建网络等。
　　　　mechanism driver 负责获取由 type driver 维护的网络状态，并确保在相应的网络设备（物理或虚拟）上正确实现这些状态。

Service Plugin

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 地址是多少？”

　　　　如果 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:~#