neutron— 网络服务

 

一. neutron 介绍

1. Neutron 概述

传统的网络管理方式很大程度上依赖于管理员手工配置和维护各种网络硬件设备；而云环境下的网络已经变得非常复杂，特别是在多租户场景里，用户随时都可能需要创建、修改和删除网络，网络的连通性和隔离不已经太可能通过手工配置来保证了。

 

如何快速响应业务的需求对网络管理提出了更高的要求。传统的网络管理方式已经很难胜任这项工作，而“软件定义网络（software-defined networking, SDN）”所具有的灵活性和自动化优势使其成为云时代网络管理的主流。

 

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

 

SDN 模式服务— NeutronSDN( 软件定义网络 ), 通过使用它，网络管理员和云计算操作员可以通过程序来动态定义虚拟网络设备。Openstack 网络中的 SDN 组件就是 Quantum.但因为版权问题而改名为Neutron 。

2.Neutron 网络基本概念

1.network

network 是一个隔离的二层广播域。Neutron 支持多种类型的 network，包括 local, flat, VLAN, VxLAN 和 GRE。

 

local

local 网络与其他网络和节点隔离。local 网络中的 instance 只能与位于同一节点上同一网络的 instance 通信，local 网络主要用于单机测试。

 

flat

flat 网络是无 vlan tagging 的网络。flat 网络中的 instance 能与位于同一网络的 instance 通信，并且可以跨多个节点。  (tagging 标记）

 

vlan

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

 

vxlan

vxlan 是基于隧道技术的 overlay 网络。vxlan 网络通过唯一的 segmentation ID（也叫 VNI）与其他 vxlan 网络区分。vxlan 中数据包会通过 VNI 封装成 UDP 包进行传输。因为二层的包通过封装在三层传输，能够克服 vlan 和物理网络基础设施的限制。

 

gre

gre 是与 vxlan 类似的一种 overlay 网络。主要区别在于使用 IP 包而非 UDP 进行封装。

 

不同 network 之间在二层上是隔离的。

 

以 vlan 网络为例，network A 和 network B 会分配不同的 VLAN ID，这样就保证了 network A 中的广播包不会跑到 network B 中。当然，这里的隔离是指二层上的隔离，借助路由器不同 network 是可能在三层上通信的。

 

network 必须属于某个 Project（ Tenant 租户），Project 中可以创建多个 network。 network 与 Project 之间是 1对多 关系。  （project  项目）

2.subnet （子网）

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

 

network 与 subnet 是 1对多 关系。一个 subnet 只能属于某个 network；一个 network 可以有多个 subnet，这些 subnet 可以是不同的 IP 段，但不能重叠。下面的配置是有效的

但下面的配置则无效，因为 subnet 有重叠

这里不是判断 IP 是否有重叠，而是 subnet 的 CIDR 重叠（都是 10.10.1.0/24）。但是，如果 subnet 在不同的 network 中，CIDR 和 IP 都是可以重叠的，比如

这里大家不免会疑惑： 如果上面的IP地址是可以重叠的，那么就可能存在具有相同 IP 的两个 instance，这样会不会冲突？ 简单的回答是：不会！

 

具体原因： 因为 Neutron 的 router 是通过 Linux network namespace 实现的。network namespace 是一种网络的隔离机制。通过它，每个 router 有自己独立的路由表。上面的配置有两种结果：

1. 如果两个 subnet 是通过同一个 router 路由，根据 router 的配置，只有指定的一个 subnet 可被路由。

 

2. 如果上面的两个 subnet 是通过不同 router 路由，因为 router 的路由表是独立的，所以两个 subnet 都可以被路由。

3. port

port 可以看做虚拟交换机上的一个端口。port 上定义了 MAC 地址和 IP 地址，当 instance 的虚拟网卡 VIF（Virtual Interface） 绑定到 port 时，port 会将 MAC 和 IP 分配给 VIF。

 

subnet 与 port 是 1对多 关系。一个 port 必须属于某个 subnet；一个 subnet 可以有多个 port。

3.小结：

 

下面总结了 Project，Network，Subnet，Port 和 VIF 之间关系。

Project 1 : m Network 1 : m Subnet 1 : m Port 1 : 1 VIF m : 1 Instance

二. Neutron 功能

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

1.二层交换机 Switching

Nova 的 Instance（实列，个体） 是通过虚拟交换机连接到虚拟二层网络的。Neutron 支持多种虚拟交换机，包括 Linux 原生的 Linux Bridge 和 Open vSwitch。 Open vSwitch（OVS）是一个开源的虚拟交换机，它支持标准的管理接口和协议。

 

利用 Linux Bridge 和 OVS，Neutron 除了可以创建传统的 VLAN 网络，还可以创建基于隧道技术的 Overlay 网络，比如 VxLAN 和 GRE（Linux Bridge 目前只支持 VxLAN）。在后面章节我们会学习如何使用和配置 Linux Bridge 和 Open vSwitch。

2. 三层路由 Routing

Instance 可以配置不同网段的 IP，Neutron 的 router（虚拟路由器）实现 instance 跨网段通信。router 通过 IP forwarding，iptables 等技术来实现路由和 NAT。我们将在后面章节讨论如何在 Neutron 中配置 router 来实现 instance 之间，以及与外部网络的通信。

3.负载均衡 Load Balancing

Openstack 在 Grizzly 版本第一次引入了 Load-Balancing-as-a-Service（LBaaS），提供了将负载分发到多个 instance 的能力。LBaaS 支持多种负载均衡产品和方案，不同的实现以 Plugin 的形式集成到 Neutron，目前默认的 Plugin 是 HAProxy。我们会在后面章节学习 LBaaS 的使用和配置。

4.防火墙 Firewalling

Neutron 通过下面两种方式来保障 instance 和网络的安全性。

 

Security Group

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

 

Firewall-as-a-Service

FWaaS，限制进出虚拟路由器的网络包，也是通过 iptables 实现。

 

 

Neutron 优点：

Openstack 中的 SDN 组件架构也属于可插拔类型。通过各种插件可以管控不同种类的交换机、路由器、防火墙、负载均衡器并实现 firewall as a service 等许多功能。通过软件来定义的网络，可以对整个云计算设施进行更为精细的掌控。

三 Neutron 部署方案

案1：控制节点 + 计算节点：

 

控制节点：部署的服务包括：neutron server, core plugin 的 agent 和 service plugin 的 agent。

 

计算节点：部署 core plugin 的agent，负责提供二层网络功能。

 

这里有几点需要说明： 

1. core plugin 和 service plugin 已经集成到 neutron server，不需要运行独立的 plugin 服务。

2. 控制节点和计算节点都需要部署 core plugin 的 agent，因为通过该 agent 控制节点与计算节点才能建立二层连接。

 

3. 可以部署多个控制节点和计算节点

 

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

在这个部署方案中，OpenStack 由控制节点，网络节点和计算节点组成。

 

控制节点：部署 neutron server 服务。

 

网络节点：部署的服务包括：core plugin 的 agent 和 service plugin 的 agent。

 

计算节点：部署 core plugin 的agent，负责提供二层网络功能。

 

这个方案的要点是将所有的 agent 从控制节点分离出来，部署到独立的网络节点上。

1. 控制节点只负责通过 neutron server 响应 API 请求。
    
2. 由独立的网络节点实现数据的交换，路由以及 load balance等高级网络服务。
    
3. 可以通过增加网络节点承担更大的负载。
    
4. 可以部署多个控制节点、网络节点和计算节点。

该方案特别适合规模较大的 OpenStack 环境。

 

四.配置多个网卡区分不同类型的网络数据

OpenStack 至少包含下面几类网络流量

Management

API

VM

External

 

Management 网络

用于节点之间 message queue 内部通信以及访问 database 服务，所有的节点都需要连接到 management 网络。

 

API 网络

OpenStack 各组件通过该网络向用户暴露 API 服务。Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 网络上。通常，管理员也通过 API 网络 SSH 管理各个节点。

 

VM 网络

VM 网络也叫 tenant 网络，用于 instance 之间通信。

VM 网络可以选择的类型包括 local, flat, vlan, vxlan 和 gre。

VM 网络由 Neutron 配置和管理。

 

External 网络

External 网络指的是 VM 网络之外的网络，该网络不由 Neutron 管理。 Neutron 可以将 router attach 到 External 网络，为 instance 提供访问外部网络的能力。 External 网络可能是企业的 intranet，也可能是 internet。

 

这几类网络只是逻辑上的划分，物理实现上有非常大的自由度。

 

我们可以为每种网络分配单独的网卡；也可以多种网络共同使用一个网卡；为提高带宽和硬件冗余，可以使用 bonding 技术将多个物理网卡绑定成一个逻辑的网卡

 

我们的实验环境采用下面的网卡分配方式：

 

1. 控制节点 3 网卡（eth0, eth1, eth2），计算节点 2 网卡（eth0, eth1）。

2. 合并 Management 和 API 网络，使用 eth0

3. VM 网络使用 eht1。

4. 控制节点的 eth2 与 External 网络连接

分割线上方的网络由网络管理员（就是我们啦）配置。 主要涉及 Management, API 和 external 网络。 配置的内容包括节点上的物理网卡，物理交换机和外部路由器，防火墙以及物理连线等

 

分割线下方是 VM 网络，由 Neutron 管理。 我们只需要通过 Web GUI 或者 CLI 操作，Neutron 会负责实现。

五. Neutron 架构

与 OpenStack 的其他服务的设计思路一样，Neutron 也是采用分布式架构，由多个组件（子服务）共同对外提供网络服务。

agent :代理  plugin : 插件目录 provider 提供商

Neutron 由如下组件构成：

 

Neutron Server

对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求。

 

Plugin

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

 

Agent

处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能。

 

network provider

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

 

Queue

Neutron Server，Plugin 和 Agent 之间通过 Messaging Queue 通信和调用。

 

Database

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

Neutron 架构非常灵活，层次较多，目的是：

1. 为了支持各种现有或者将来会出现的优秀网络技术。

    
2. 支持分布式部署，获得足够的扩展性。

通常鱼和熊掌不能兼得，虽然获得了这些优势，但这样使得 Neutron 更加复杂，更不容易理解。 后面我们会详细讨论 Neutron 的各个组件，但在这之前，非常有必要先通过一个例子了解这些组件各自的职责以及是如何协同工作。

 

以创建一个 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 解决的是 What 的问题，即网络要配置成什么样子？而至于如何配置 How 的工作则交由 agent 完成。

    
2. plugin，agent 和 network provider 是配套使用的，比如上例中 network provider 是 linux bridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 换成了 OVS 或者物理交换机，plugin 和 agent 也得替换。

    
3. plugin 的一个主要的职责是在数据库中维护 Neutron 网络的状态信息，这就造成一个问题：所有 network provider 的 plugin 都要编写一套非常类似的数据库访问代码。为了解决这个问题，Neutron 在 Havana 版本实现了一个 ML2（Modular Layer 2）plugin，对 plgin 的功能进行抽象和封装。有了 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  组件详解

1.Neutron server 分层模型

extension ：延期。外延 common：共同

图是 Neutron Server 的分层结构，至上而下依次为：

 

Core API：对外提供管理 network, subnet 和 port 的 RESTful API。 （Restful：平静的）

restful api ：轻量级的接口

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

extension api 扩展API

Commnon 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：实现了 Core Plugin API，在数据库中维护 network, subnet 和 port 的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 network。

 

Service Plugin：实现了 Extension Plugin API，在数据库中维护 router, load balance, security group 等资源的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 router。

 

归纳起来，Neutron Server 包括两部分：

1. 提供 API 服务。

2. 运行 Plugin。

 

即 Neutron Server = API + Plugins

 

明白了 Neutron Server 的分层模型，我们就更容易理解 Neutron 是如何支持多种 network provider。

2. ML2 CORE Plugin  详解

 

上节提到 Core Plugin，其功能是维护数据库中 network, subnet 和 port 的状态，并负责调用相应的 agent 在 network provider 上执行相关操作，比如创建 network。

openstack中有两大常见 Core Plugin： linux bridge plugin 和 open vswitch plugin。

Neutron 可以通过开发不同的 plugin 和 agent 支持不同的网络技术。这是一种相当开放的架构。不过随着支持的 network provider 数量的增加，开发人员发现了两个突出的问题：

      1. 只能在 OpenStack 中使用一种 core plugin，多种 network provider 无法共存。            只使用一个 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. 不同 plugin 之间存在大量重复代码，开发新的 plugin 工作量大。

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

 解决传统 core plugin 的问题

Moduler Layer 2（ML2）：是 Neutron 在 Havana 版本实现的一个新的 core plugin，用于替代原有的 linux bridge plugin 和 open vswitch plugin。 作为新一代的 core plugin，提供了一个框架，允许在 OpenStack 网络中同时使用多种 Layer 2 网络技术，不同的节点可以使用不同的网络实现机制。

如上图所示，采用 ML2 plugin 后，可以在不同节点上分别部署 linux bridge agent, open vswitch 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 和 mechansim driver。这两类 driver 解耦了 Neutron 所支持的网络类型（type）与访问这些网络类型的机制（mechanism），其结果就是使得 ML2 具有非常好的弹性，易于扩展，能够灵活支持多种 type 和 mechanism

 

（1） Type Driver  

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

type driver 负责维护网络类型的状态，执行验证，创建网络等。 ML2 支持的网络类型包括 local, flat, vlan, vxlan 和 gre。 我们将在后面章节详细讨论每种 type。

 

（2） Mechansim Driver

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

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

type 和 mechanisim 都太抽象，现在我们举一个具体的例子： type driver 为 vlan，mechansim 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, open vswitch 等。

 

Controller-based

包括 OpenDaylight, VMWare NSX 等。

 

基于物理交换机

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

 

 

本教程讨论的 mechanism driver 将涉及 linux bridge, open vswitch 和 L2 population。

 

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

 

Core Plugin/Agent 负责管理核心实体：net, subnet 和 port。而对于更高级的网络服务，则由 Service Plugin/Agent 管理。

 

Service Plugin 及其 Agent 提供更丰富的扩展功能，包括路由，load balance，firewall等，如图所示

 

DHCP

dhcp agent 通过 dnsmasq 为 instance 提供 dhcp 服务。

 

Routing

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

 

Firewall

l3 agent 可以在 router 上配置防火墙策略，提供网络安全防护。另一个与安全相关的功能是 Security Group，也是通过 IPtables 实现。 Firewall 与 Security Group 的区别在于：

1. Firewall 安全策略位于 router，保护的是某个 project 的所有 network。
2. Security Group 安全策略位于 instance，保护的是单个 instance。

Firewall 与 Security Group 后面会详细分析。

 

Load Balance

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

 

后面的章节会结合 linux bridge 和 open vswitch 详细讨论每一种 service。

七. Neutron 框架总结

前面我们详细讨论了 Neutron 架构，包括 Neutron Server，Core 和 Service Agent。现在用两张图做个总结。

 

与 OpenStack 其他服务一样，Neutron 采用的是分布式架构，包括 Neutorn Server、各种 plugin/agent、database 和 message queue。

1. Neutron server 接收 api 请求。

2. plugin/agent 实现请求。

3. database 保存 neutron 网络状态。

4. message queue 实现组件之间通信。

 

metadata-agent 之前没有讲到，这里做个补充：

         instance 在启动时需要访问 nova-metadata-api 服务获取 metadata 和 userdata，这些 data 是该 instance 的定制化信息，比如 hostname, ip， public key 等。

 

但 instance 启动时并没有 ip，那如何通过网络访问到 nova-metadata-api 服务呢？

 

答案就是 neutron-metadata-agent 该 agent 让 instance 能够通过 dhcp-agent 或者 l3-agent 与 nova-metadata-api 通信

 

 

 

如果我们将 Neutron 架构展开，则会得到下面第二张图

 

 

1. Neutron 通过 plugin 和 agent 提供的网络服务。
2. plugin 位于 Neutron server，包括 core plugin 和 service plugin。
3. agent 位于各个节点，负责实现网络服务。
4. core plugin 提供 L2 功能，ML2 是推荐的 plugin。
5. 使用最广泛的 L2 agent 是 linux bridage 和 open vswitch。
6. service plugin 和 agent 提供扩展功能，包括 dhcp, routing, load balance, firewall, vpn 等。

至此，Neutron 架构已经讨论完，希望大家已经理解。

八  Neutron - 网络实践

1. 用namspace 隔离 DHCP 服务

Neutron 通过 dnsmasq 提供 DHCP 服务，而 dnsmasq 通过 Linux Network Namespace 独立的为每个 network 服务隔离

在二层网络上，VLAN 可以将一个物理交换机分割成几个独立的虚拟交换机。类似地，在三层网络上，Linux network namespace 可以将一个物理三层网络分割成几个独立的虚拟三层网络。

每个 namespace 都有自己独立的网络栈，包括 route table，firewall rule，network interface device 等。

Neutron 通过 namespace 为每个 network 提供独立的 DHCP 和路由服务，从而允许租户创建重叠的网络。如果没有 namespace，网络就不能重叠，这样就失去了很多灵活性。

每个 dnsmasq 进程都位于独立的 namespace, 命名为 qdhcp-<network id>，例如 flat_net：

ip netns list         命令列出所有的 namespace

ip netns exec <network namespace name> <command>        管理 namespace

root namespace：

其实，宿主机本身也有一个 namespace，叫 root namespace，拥有所有物理和虚拟 interface device。物理 interface 只能位于 root namespace。

新创建的 namespace 默认只有一个 loopback device。管理员可以将虚拟 interface，例如 bridge，tap 等设备添加到某个 namespace。

对于 flat_net 的 DHCP 设备 tap19a0ed3d-fe，需要将其放到 namespace qdhcp-7bf09be4-8653-4869-84f0-33494f238627 中，但这样会带来一个问题：tap19a0ed3d-fe 将无法直接与 root namespace 中的 bridge 设备 brqf153b42f-c3 连接。

 

Neutron 使用 veth pair 解决了这个问题。

veth pair 是一种成对出现的特殊网络设备，它们象一根虚拟的网线，可用于连接两个 namespace。向 veth pair 一端输入数据，在另一端就能读到此数据。

tap19a0ed3d-fe 与 ns-19a0ed3d-fe 就是一对 veth pair，它们将 qdhcp-f153b42f-c3a1-4b6c-8865-c09b5b2aa274 连接到 brqf153b42f-c3。

如下图所示：

可以通过 ip netns exec qdhcp-7bf09be4-8653-4869-84f0-33494f238627 ip a命令查看ns-ba07bb93配置：

2. 获取 DHCP ＩＰ过程解析　

在创建 instance 时，Neutron 会为其分配一个 port，里面包含了 MAC 和 IP 地址信息。这些信息会同步更新到 dnsmasq 的 host 文件。如下图所示：

同时 nova-compute 会设置虚机VIF 的 MAC 地址。

一切准备就绪，instance 获取 IP 的过程如下：

 

1. vm 开机启动，发出 DHCPDISCOVER 广播，该广播消息在整个 net 中都可以被收到。

 

2. 广播到达 veth tap19a0ed3d-fe，然后传送给 veth pair 的另一端 ns-19a0ed3d-fe。dnsmasq 在它上面监听，dnsmasq 检查其 host 文件，发现有对应项，于是dnsmasq 以  DHCPOFFER 消息将 IP（192.168.254.18）、子网掩码（255.255.255.0）、地址租用期限等信息发送给 vm。

 

3. vm 发送 DHCPREQUEST 消息确认接受此 DHCPOFFER。

 

4. dnsmasq 发送确认消息 DHCPACK，整个过程结束。

 

九．Vxlan　简介

１.ｏverlay network　概念

overlay network 是指建立在其他网络上的网络。overlay network 中的节点可以看作通过虚拟（或逻辑）链路连接起来的。overlay network 在底层可能由若干物理链路组成，但对于节点，不需要关心这些底层实现。

 

例如 P2P 网络就是 overlay network，隧道也是。vxlan 和 gre 都是基于隧道技术实现的，它们也都是 overlay network。

 

目前 linux bridge 只支持 vxlan，不支持 gre；

open vswitch 两者都支持。vxlan 与 gre 实现非常类似，而且 vxlan 用得较多，所以本教程只介绍 vxlan。

２.　简介

VXLAN 为 Virtual eXtensible Local Area Network。正如名字所描述的，VXLAN 提供与 VLAN 相同的以太网二层服务，但拥有更强的扩展性和灵活性。与 VLAN 相比，

VXLAN 有下面几个优势：

1. 支持更多的二层网段。

VLAN 使用 12-bit 标记 VLAN ID，最多支持 4094 个 VLAN，这对大型云部署会成为瓶颈。VXLAN 的 ID （VNI 或者 VNID）则用 24-bit 标记，支持 16777216 个二层网段。

2. 能更好地利用已有的网络路径。

VLAN 使用 Spanning Tree Protocol 避免环路，这会导致有一半的网络路径被 block 掉。VXLAN 的数据包是封装到 UDP 通过三层传输和转发的，可以使用所有的路径。

3. 避免物理交换机 MAC 表耗尽。

由于采用隧道机制，TOR (Top on Rack) 交换机无需在 MAC 表中记录虚拟机的信息。

 

 

VXLAN 封装和包格式：

VXLAN 是将二层建立在三层上的网络。通过将二层数据封装到 UDP 的方式来扩展数据中心的二层网段数量。

VXLAN 是一种在现有物理网络设施中支持大规模多租户网络环境的解决方案。VXLAN 的传输协议是 IP + UDP。

VXLAN 定义了一个 MAC-in-UDP 的封装格式。在原始的 Layer 2 网络包前加上 VXLAN header，然后放到 UDP 和 IP 包中。通过 MAC-in-UDP 封装，VXLAN 能够在 Layer 3 网络上建立起了一条 Layer 2 的隧道。

 

VXLAN 包的格式如下：

如上图所示，VXLAN 引入了 8-byte VXLAN header，其中 VNI 占 24-bit。VXLAN 和原始的 L2 frame 被封装到 UDP 包中。这 24-bit 的 VNI 用于标示不同的二层网段，能够支持 16777216 个 LAN。

VXLAN Tunnel Endpoint

VXLAN 使用 VXLAN tunnel endpoint (VTEP) 设备处理 VXLAN 的封装和解封。每个 VTEP 有一个 IP interface，配置了一个 IP 地址。VTEP 使用该 IP 封装 Layer 2 frame，并通过该 IP interface 传输和接收封装后的 VXLAN 数据包。

下面是 VTEP 的示意图：

VXLAN 独立于底层的网络拓扑；反过来，两个 VTEP 之间的底层 IP 网络也独立于 VXLAN。VXLAN 数据包是根据外层的 IP header 路由的，该 header 将两端的 VTEP IP 作为源和目标 IP。

３.vxlan　封装和转发的过程，及linux　对vxlan的原生支持

VXLAN 包转发流程

VXLAN 在 VTEP 间建立隧道，通过 Layer 3 网络传输封装后的 Layer 2 数据。下面例子演示了数据如何在 VXLAN 上传输：

 

图中 Host-A 和 Host-B 位于 VNI 10 的 VXLAN，通过 VTEP-1 和 VTEP-2 之间建立的 VXLAN 隧道通信。数据传输过程如下：

1. Host-A 向 Host-B 发送数据时，Host-B 的 MAC 和 IP 作为数据包的目标 MAC 和 IP，Host-A 的 MAC 作为数据包的源 MAC 和 IP，然后通过 VTEP-1 将数据发送出去。

2. VTEP-1 从自己维护的映射表中找到 MAC-B 对应的 VTEP-2，然后执行 VXLAN 封装，加上 VXLAN 头，UDP 头，以及外层 IP 和 MAC 头。此时的外层 IP 头，目标地址为 VTEP-2 的 IP，源地址为 VTEP-1 的 IP。同时由于下一跳是 Router-1，所以外层 MAC 头中目标地址为 Router-1 的 MAC。

3. 数据包从 VTEP-1 发送出后，外部网络的路由器会依据外层 IP 头进行路由，最后到达与 VTEP-2 连接的路由器 Router-2。

4. Router-2 将数据包发送给 VTEP-2。VTEP-2 负责解封数据包，依次去掉外层 MAC 头，外层 IP 头，UDP 头 和 VXLAN 头。VTEP-2 依据目标 MAC 地址将数据包发送给 Host-B。

上面的流程我们看到 VTEP 是 VXLAN 的最核心组件，负责数据的封装和解封。隧道也是建立在 VTEP 之间的，VTEP 负责数据的传送。

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 的相关信息。

VTEP 可以根据这些信息判断出其他 Host 上都有哪些 VM，以及它们的 MAC 地址，这样就能直接与之通信，从而避免了不必要的隧道连接和广播。

 

Linux 对 VXLAN 的支持

VTEP 可以由专有硬件来实现，也可以使用纯软件实现。目前比较成熟的 VTEP 软件实现包括：

1. 带 VXLAN 内核模块的 Linux

2. Open vSwitch

我们先来看 Linux 如何支持 VXLAN

 

实现方式：

1. Linux vxlan 创建一个 UDP Socket，默认在 8472 端口监听。

 

2. Linux vxlan 在 UDP socket 上接收到 vxlan 包后，解包，然后根据其中的 vxlan ID 将它转给某个 vxlan interface，然后再通过它所连接的 linux bridge 转给虚机。

 

3. Linux vxlan 在收到虚机发来的数据包后，将其封装为多播 UDP 包，从网卡发出。

 

 

４.ML2 mechanism driver： Linux Bridge 和 Open vSwitch

1. 控制节点三个网卡（eth0, eth1, eth2），计算节点两网卡（eth0, eth1）。
2. 合并 Management 和 API 网络，使用 eth0，IP 段为 192.168.104.0/24。
3. VM 网络使用 eht1。
4. 控制节点的 eth2 与 External 网络连接，IP 段为 10.10.10.0/24。

Linux Bridge ：

 

 

Open vSwitch 中的网络设备：

 

br-ex：连接外部（external）网络的网桥。

br-int：集成（integration）网桥，所有 instance 的虚拟网卡和其他虚拟网络设备都将连接到该网桥。

br-tun：隧道（tunnel）网桥，基于隧道技术的 VxLAN 和 GRE 网络将使用该网桥进行通信。

tap interface：命名为 tapXXXX。

linux bridge：命名为 qbrXXXX。

veth pair：命名为 qvbXXXX, qvoXXXX

OVS integration bridge：命名为 br-int。

OVS patch ports：命名为 int-br-ethX 和 phy-br-ethX（X 为 interface 的序号）。

OVS provider bridge：命名为 br-ethX（X 为 interface 的序号）。

物理 interface：命名为 ethX（X 为 interface 的序号）。

OVS tunnel bridge：命名为 br-tun。

十．neutron_网络服务的搭建

进入数据库

mysql -uroot -p123

创建属于neutron的数据库

MariaDB [(none)] CREATE DATABASE neutron;

宣告权限

MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'localhost' \

  IDENTIFIED BY 'NEUTRON_DBPASS';

MariaDB [(none)]> GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@'%' \

  IDENTIFIED BY 'NEUTRON_DBPASS';

exit退出

 

创建neutron的用户，并设置密码

openstack user create --domain default --password-prompt neutron

密码设置为neutron

 

设置密码也可以直接输入：openstack user create --domain default --password=neutron neutron

查看一下是否添加成功

openstack user list

 

设置为管理员

openstack role add --project service --user neutron admin

 

然后再创建一个属于neutron的服务

openstack service create --name neutron \

  --description "OpenStack Networking" network

查询一下

openstack service list

创建neutron的服务端点

openstack service list

 

openstack endpoint create --region RegionOne \

  network internal http://yun:9696

 

openstack endpoint create --region RegionOne \

  network admin http://yun:9696

 

选择安装三层服务

安装neutron的主服务与核心插件ml2，和ovs网桥

yum install openstack-neutron openstack-neutron-ml2 openstack-neutron-openvswitch

 

配置neutron服务的主配置文件

cd /etc/neutron/

mv neutron.conf neutron.conf.copy

vim /etc/neutron/neutron.conf

[DEFAULT]

state_path = /var/lib/neutron

auth_strategy = keystone

core_plugin = ml2

service_plugins = router

dhcp_agent_notification = true

allow_overlapping_ips = True

notify_nova_on_port_status_changes = true

notify_nova_on_port_data_changes = true

transport_url = rabbit://openstack:admin@controller

 

[agent]

 

[cors]

 

[cors.subdomain]

 

[database]

connection = mysql+pymysql://neutron:NEUTRON_DBPASS@controller/neutron

 

[keystone_authtoken]

auth_uri = http://controller:5000

auth_url = http://controller:35357

memcached_servers = controller:11211

auth_type = password

project_domain_name = default

user_domain_name = default

project_name = service

username = neutron

password = neutron

 

[matchmaker_redis]

 

[nova]

region_name = RegionOne

auth_url = http://controller:35357

auth_type = password

project_domain_name = default

project_name = service

user_domain_name = default

username = nova

password = nova

 

[oslo_concurrency]

lock_path = $state_path/lock

 

[oslo_messaging_amqp]

 

[oslo_messaging_kafka]

 

[oslo_messaging_notifications]

 

[oslo_messaging_rabbit]

 

[oslo_messaging_zmq]

 

[oslo_middleware]

 

[oslo_policy]

 

[qos]

 

[quotas]

 

[ssl]

末行模式更改主机名：%s/controller/yun/g

core_plugin = ml2     ml2是提供neutron网络环境的主要成员

service_plugins = router     开启路由功能

 

配置核心插件ml2的配置文件

/etc/neutron/plugins/ml2/ml2_conf.ini

cd /etc/neutron/plugins/ml2/

mv ml2_conf.ini ml2_conf.ini.copy

vim ml2_conf.ini

[DEFAULT]

 

[ml2]

type_drivers = flat,vxlan

tenant_network_types = vxlan

mechanism_drivers = openvswitch,l2population

extension_drivers = port_security

 

[ml2_type_flat]

 

[ml2_type_geneve]

 

[ml2_type_gre]

 

[ml2_type_vlan]

 

[ml2_type_vxlan]

vni_ranges = 1:1000

 

[securitygroup]

enable_ipset = true

type_drivers = 类型驱动 = flat,vxlan

tenant_network_types = 租户网络类型 = vxlan

mechanism_drivers = 机制驱动 = openvswitch,l2population（注意自己用的ovs，还是Linuxbirdge）

extension_drivers = port_security     开启端口安全功能

vni_ranges =vxlan的标记范围

 

编辑openvswitch代理配置文件

mv  openvswitch_agent.ini openvswitch_agent.ini.copy

vim openvswitch_agent.ini

[DEFAULT]

 

[agent]

tunnel_types = vxlan

l2_population = True

 

[ovs]

tunnel_bridge = br-tun

local_ip = 192.168.41.128

bridge_mappings =

 

[securitygroup]

firewall_driver = iptables_hybrid

enable_security_group = true

 

[xenapi]

 

注意更改自己的租户网地址IP

 

编辑agent.ini配置文件

cd /etc/neutron

mv l3_agent.ini l3_agent.ini.copy

vim l3_agent.ini

[DEFAULT]

interface_driver = openvswitch

external_network_bridge = br-ex

 

[agent]

 

[ovs]

interface_driver = 网口驱动 = ovs

external_network_bridge = 外部网络网桥链接 = br-ex

 

编辑元数据的agent.ini配置文件

mv metadata_agent.ini metadata_agent.ini.copy

vim metadata_agent.ini

[DEFAULT]

nova_metadata_ip = controller

metadata_proxy_shared_secret = METADATA_SECRET

 

[agent]

 

[cache]

注意更改IP

这里的密码要跟nova服务配置文件里的密码相同

 

编辑dhcp的agent.ini配置文件

mv dhcp_agent.ini dhcp_agent.ini。copy

vim dhcp_agent.ini

[DEFAULT]

interface_driver = openvswitch

dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq

enable_isolated_metadata = true

 

[agent]

 

[ovs]

interface_driver = 网口驱动 = openvswitch

dhcp_driver = dhcp的驱动 = neutron.agent.linux.dhcp.Dnsmasq

 

建立ml2的一个快速链接

ln -s /etc/neutron/plugins/ml2/ml2_conf.ini /etc/neutron/plugin.ini

 

导入数据库

su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf \

  --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron

完成后进入数据库查看一下neutron数据库下的表

 

重启nova-api，让它找到neutron

systemctl restart openstack-nova-api.service

 

启动neutron服务和子服务

systemctl enable neutron-server.service \

  neutron-openvswitch-agent.service neutron-dhcp-agent.service \

  neutron-metadata-agent.service

  

systemctl start neutron-server.service \

  neutron-openvswitch-agent.service neutron-dhcp-agent.service \

  neutron-metadata-agent.service

 

查看一下

openstack network agent list

 

添加一个网桥，网桥叫br-ex

# ovs-vsctl add-br br-ex

查看网桥服务

# ovs-vsctl show

 

添加一块外网网卡

把br-ex绑定在这块外网网卡上

ovs-vsctl add-port br-ex ens39

再查看一下

# ovs-vsctl show

查看一下linux bridge

brctl show

 

启动l3-agent服务（负责开启路由）

systemctl enable neutron-l3-agent.service

systemctl start neutron-l3-agent.service

 

查看一下网络服务

openstack network agent list

 

部署compute node节点

需要部署 openstack-neutron-linuxbridge ebtables ipset三个服务

但是由于我们用的是ovs，所以不装openstack-neutron-linuxbridge

并且，我们采用的是all in one的形式，所以只需要安装ebtables ipset两个服务

 

进入主配置文件配置

vim /etc/neutron/neutron.conf

[DEFAULT]

transport_url = rabbit://openstack:RABBIT_PASS@controller

[DEFAULT]

auth_strategy = keystone

 

[keystone_authtoken]

# ...

auth_uri = http://yun:5000

auth_url = http://yun:35357

memcached_servers = yunr:11211

auth_type = password

project_domain_name = default

user_domain_name = default

project_name = service

username = neutron

password = NEUTRON_PASS

 

[oslo_concurrency]

lock_path = /var/lib/neutron/tmp

 

需要编辑/etc/neutron/plugins/ml2/linuxbridge_agent.ini文件，由于用了ovs

所以改为编辑/etc/neutron/plugins/ml2/openvswitch_agent.ini文件

把之前配置好的openvswitch_agent.ini，拷贝到计算节点上即可

因为我们是all in one 形式，所以不用在配置了

 

配置计算节点上nova的使用neutron的信息

vim /etc/nova/nova.conf

[neutron]

# ...

url = http://yun:9696

auth_url = http://yun:35357

auth_type = password

project_domain_name = default

user_domain_name = default

region_name = RegionOne

project_name = service

username = neutron

password = NEUTRON_PASS

 

重启nova-compute服务

systemctl restart openstack-nova-compute.service

 

systemctl enable neutron-openvswitch-agent.service

systemctl start neutron-openvswitch-agent.service

 

查看一下

neutron agent-list