注：本文内容均来自网络，我只是在此做了一些摘抄和整理的工作，来源均有注明。
0、简介
可以开发一个不包含任何特定于网络的功能的、可弹性扩展的工作负载管理系统。当然，计算节点需要在彼此之间建立连接，并能访问外部世界，但它也可以利用现有的网络基础架构来分配 IP 地址和在节点之间传输数据。在多租户环境中，这样一种方法的最大问题是，已有的网络管理系统无法高效、安全地在用户之间隔离流量 — 这同时也是构建公共和私有云的组织面临的一个巨大问题。
OpenStack 解决此问题的一种方式是，构建一个详尽的网络管理堆栈，用它来处理所有网络相关请求。此方法面临的挑战是，每个实现都可能拥有一组独特的需求，包括与其他各种各样的工具和软件的集成。
OpenStack 因此采取了创建抽象层的方法，这个抽象层被称为 OpenStack Networking，可容纳大量处理与其他网络服务的集成的插件。它为云租户提供了一个应用编程接口 (API)，租户可使用它配置灵活的策略和构建复杂的网络拓扑结构 — 例如用它来支持多级 Web 应用程序。
OpenStack Networking 支持使用第三方编写插件来引入高级网络功能，比如 L2-in-L3 隧道和端到端服务质量支持。它们还可以创建网络服务，比如负载平衡、虚拟专用网或插入 OpenStack 租户网络中的防火墙。
1、基本概念
Neutron将网络按照三层交换机的概念分为：
- Network：相当于交换机根据vlan创建的一个三层接口；
- Subnet：相当于交换机创建了一个三层接口地址；
- Port：相当于交换机的一个物理端口，但是这个端口有一个MAC地址；
-
网络
在普通人的眼里，网络就是网线和供网线插入的端口，一个盒子会提供这些端口。对于网络工程师来说，网络的盒子指的是交换机和路由器。所以在物理世界中，网络可以简单地被认为包括网线，交换机和路由器。当然，除了物理设备，我们还有软的物件：IP地址，交换机和路由器的配置和管理软件以及各种网络协议。要管理好一个物理网络需要非常深的网络专业知识和经验。
Neutron网络目的是（为OpenStack云更灵活地）划分物理网络，在多租户环境下提供给每个租户独立的网络环境。另外，Neutron提供API来实现这种目标。Neutron中“网络”是一个可以被用户创建的对象，如果要和物理环境下的概念映射的话，这个对象相当于一个巨大的交换机，可以拥有无限多个动态可创建和销毁的虚拟端口。
-
端口
在物理网络环境中，端口是用于连接设备进入网络的地方。Neutron中的端口起着类似的功能，它是路由器和虚拟机挂接网络的着附点。
-
路由器
和物理环境下的路由器类似，Neutron中的路由器也是一个路由选择和转发部件。只不过在Neutron中，它是可以创建和销毁的软部件。
-
子网
简单地说，子网是由一组IP地址组成的地址池。不同子网间的通信需要路由器的支持，这个Neutron和物理网络下是一致的。Neutron中子网隶属于网络。
2、OpenStack网络类型
一个标准的 OpenStack 网络设置有 4 个不同的物理数据中心网络：
- 管理网络：用于 OpenStack 各组件之间的内部通信。
- 数据网络：用于云部署中虚拟数据之间的通信。
- 外部网络：公共网络，外部或 internet 可以访问的网络。
- API 网络：暴露所有的 OpenStack APIs,包括 OpenStack 网络 API 给租户们。
3、OpenStack服务网络管理的三种模式：
Flat 模式
Flat 模式和 FlatDHCP 模式其实区别不大，都是基于网桥网络，只是 FLat 模式需要管理员手动配置（包括配置网桥和外部的 DHCP 设备）。
图 8. Flat 网络拓扑
FlatDHCP 模式
这种模式下与 Flat 模式不同的地方在于有一个 DHCP 进程，每一个运行 nova-network 进程的节点（网络控制节点/nove-network 主机）就是一个单独的网络。Nova 会在 nova-network 主机建立网桥（默认名称 br100，配置项 flat_network_bridge=br100），并给该网桥指定该网络的网关 IP，同时 Nova 在网桥处起一个 DHCP 进程，最后，会建立 iptables 规则（SNAT/DNAT）使虚拟机能够与外界通信，同时与一个 metadata 服务器通信以取得 cloud 内的信息。
计算节点负责创建对应节点的网桥，此时的计算节点网卡可以不需要 IP 地址，因为网桥把虚拟机与 nove-network 主机连接在一个逻辑网络内。虚拟机启动时会发送 dhcpdiscover 以获取 IP 地址。虚拟机通往外界的数据都要通过 nova-network 主机，DHCP 在网桥处监听，分配 fixed_range 指定的 IP 段。如图 9。
图 9. FlatDHCP 网络拓扑
这种部署方式的缺点----单节点故障、无二层隔离（即所有的虚拟机都在一个广播域）。
VLAN 模式
VLAN（Virtual Local Area Network）的中文名为"虚拟局域网"。VLAN 是一种将局域网设备从逻辑上划分成一个个网段，从而实现虚拟工作组的新兴数据交换技术。
VLAN 模式与 Flat 模式的区别
在 Flat 模式下，管理员的工作流程应该是这样的：
- 为所有租户创建一个 IP 池：
nova-manage network create --fixed_range_v4=10.0.0.0/16 –label=public
- 创建租户
- 租户创建虚拟机，为虚拟机分配 IP 池中的可用 IP
DB 中虚拟机信息可能如下图，从图中我们看到 2 个虚拟机处于同一网段。
图 10
在 VLAN 模式下流程如下：
- 创建新的租户，并记下租户的标识
- 为该租户创建独占的 fixed_ip 段：
nova-manage network create --fixed_range_v4=10.0.1.0/24 --vlan=102 --project_id="tenantID"
- 租户创建虚拟机，从租户的私有 IP 段内分配 IP 给虚拟机
因此，与 Flat 模式相比，VLAN 模式为网络增加了：将网络与租户关联和为网络分配一个 VLAN 号。
4、插件
最初的 OpenStack Compute 网络实现采用了一种基本模型，通过 Linux® VLAN 和 IP 表执行所有隔离操作。OpenStack Networking 引入了插件的概念，插件是 OpenStack Networking API 的一种后端实现。插件可使用各种不同的技术来实现逻辑 API 请求。
一些 OpenStack Networking 插件可能使用基本的 Linux VLAN 和 IP 表。这些插件对于小型和简单的网络通常已经足够，但更大型的客户可能拥有更复杂的需求，涉及到多级 Web 应用程序和多个私有网络之间的内部隔离。它们可能需要自己的 IP 地址模式（这可能与其他租户使用的地址重复）— 例如，用来允许应用程序在无需更改 IP 地址的情况下迁移到云中。在这些情况下，可能需要采用更高级的技术，比如 L2-in-L3 隧道或 OpenFlow。
插件架构使云管理员可以非常灵活地自定义网络的功能。第三方可通过 API 扩展提供额外的 API 功能，这些功能最终会成为核心 OpenStack Networking API 的一部分。
Neutron API 向用户和其他服务公开虚拟网络服务接口，但这些网络服务的实际实现位于一个插件中，插件向租户和地址管理等其他服务提供了隔离的虚拟网络。任何人都应该能够通过 Internet 访问 API 网络，而且该网络实际上可能是外部网络的一个子网。前面已经提到过，Neutron API 公开了一个网络连接模型，其中包含网络、子网和端口，但它并不实际执行工作。Neutron 插件负责与底层基础架构交互，以便依据逻辑模型而传送流量。
现在已有大量包含不同功能和性能参数的插件，而且插件数量仍在增长。目前包含以下插件：
- Open vSwitch
- Cisco UCS/Nexus
- Linux Bridge
- Nicira Network Virtualization Platform
- Ryu OpenFlow Controller
- NEC OpenFlow
云管理员可自行选择插件，他们可评估各个选项并根据具体的安装需求而调整它们。
5、架构
neutron-server 是 OpenStack Networking 服务器的主要流程。它是一个 Python 后台进程，将用户请求从 OpenStack Networking API 中继到配置的插件。OpenStack Networking 还包含 3 个代理，它们通过消息队列或标准 OpenStack Networking API 与主要 Neutron 进程交互：
-
neutron-dhcp-agent向所有租户网络提供动态主机配置协议 (Dynamic Host Configuration Protocol, DHCP) 服务。 -
-
neutron-l3-agent执行 L3/网络地址转换 (Network Address Translation) 转发，以支持网络网络访问租户网络上的 VM。 -
- 一个特定于插件的可选代理 (
neutron-*-agent) 在每个虚拟机管理程序上执行本地虚拟交换机配置。
一定要知道 OpenStack Networking 与其他 OpenStack 组件之间的交互方式。与其他 OpenStack 项目一样，OpenStack Dashboard (Horizon) 提供了图形用户界面，以便管理员和租户用户能够访问功能 — 在这里，是访问用来创建和管理网络服务的功能。这些服务也依照 OpenStack Identity (Keystone) 对所有 API 请求执行身份验证和授权。
与 OpenStack Compute (Nova) 的集成更加特殊。Nova 启动了一个虚拟实例时，该服务会与 OpenStack Networking 通信，将每个虚拟网络接口插入到一个特定的端口中。
6、OSI七层模型
从上到下，OSI分七层：
- L7，应用层 Application Layer: Telnet、FTP、HTTP、SNMP, DNS
- L6，表示层 Presentation Layer
- L5，会话层 Session Layer:
- L4，运输层 Transport Layer: TCP, UDP
- L3，网络层 Network Layer： IP，IPX, RIP, OSPF, ICMP, ARP
- L2，数据链路层 Datalink Layer
- L1，物理层 Physical Layer
主要三层：
L2 层主要通过 MAC 地址进行帧转发 L3 层主要通过 IP 地址进行包转发 L4 层再结合端口 PORT 来唯一标志一个应用程序
通信过程：
协议是通信双方对数据的一个理解，例如在 L7 层有我们常用的协议 HTTP 协议，在 HTTP 协议上传输的是通信双方都理解的 HTML 数据；在 L4 层有两大重要协议，无连接的 UDP 和面向连接的 TCP。可靠传输可以通过 TCP 协议来实现，对于下面的 L2，L3 层并不需要实现可靠传输机制，像 L2 层，传输数据帧的过程中出了错误简单丢弃就行，上层的 TCP 自然会控制它重传。socket 不是协议，只是 L4 层传输数据的一个接口定义。 当网卡接收到数据之后，硬件网卡会给 CPU 发中断，CPU 在指令周期内指示操作系统软件从网卡缓冲区取走数据，然后操作系统将数据交给 TCP/IP 栈来处理，到了 L2 层，解析 L2 层数据帧头中的 MAC 地址来决定 L2 中的转发，如需 3 层转发就交给上面的 L3 层解析出数据包头中的 IP 地址来决定 L3 中的转发，依此类推。
展开各层：
L1
L1 是物理层，主要是涉及硬件的一些电气特性，与偏软件的 Neutron 虚拟网络从知识脉络上关系甚少，不展开。
L2
FLAT
L2 数据链路层通过交换机设备进行帧转发。交换机在接收到帧之后(L2 层叫帧，L3 层叫包)先解析出帧头中的 MAC 地址，再在转发表中查找是否有对应 MAC 地址的端口，有的话就从相应端口转发出去。没有，就洪泛（专业术语，即将帧转发到交换机的所有端口），每个端口上的计算机都检查帧头中的 MAC 地址是否与本机网卡的 MAC 地址一致，一致的话就接收数据帧，不一致就直接丢弃。而转发表是通过自学习自动建立的。
这里引出一个重要概念，混杂模式。默认情况下计算机只接收和本机 MAC 地址一致的数据帧，不一致就丢弃，如果要求计算机接受所有帧的话，就要设置网卡为混杂模式（ifconfig eth0 0.0.0.0 promisc up)。所以在虚拟网桥中，如果希望虚机和外部通讯，必须打开桥接到虚拟网桥中物理网卡的混杂模式特性。
VLAN
FLAT 中的洪泛，经常会在一个局域网内产生大量的广播，这也就是所谓的“广播风暴”。为了隔离广播风暴，引入了 VLAN 的概念。即为交换机的每一个端口设置一个 1-4094 的数字，交换机根据 MAC 地址进行转发的同时也要结合 VLAN 号这个数字，不同的话也要丢弃。这样就实现了 L2 层数据帧的物理隔离，避免了广播风暴。
在 Neutron 中，我们知道，截止到笔者写这篇文章之时已经实现了 FLAT、VLAN、GRE、VXLAN 四种网络拓扑。那么如何区分 FLAT 和 VLAN 呢？很简单，结合 VLAN 号和 MAC 地址进行转发的是 VLAN 模式，只根据 MAC 地址进行转发的是 FLAT 模式。
VLAN 的缺点与大 L2 层技术
实际上，遂道技术并不能完全归类于 L2 层。因为有基于 L2 层的遂道协议，例如 PPTP 和 L2TP 等；也有基于 L3 层的遂道，如 GRE、VXLAN、NVGRE 等；但是这些遂道从技术原理上讲差不多，所以笔者将这些技术作为“大 L2 层”放在一块来描述，但希望读者不要误解。
本文只将着重讲 Neutron 中用到的 GRE 和 VXLAN 技术。
L3 层的 GRE 遂道
VLAN 技术能有效隔离广播域，但同时有很多缺点：
- 要求穿越的所有物理交换机都配置允许带有某个 VLAN 号的数据帧通过，因为物理交换机通常只提供 CLI 命令，不提供远程接口可编程调用，所以都需要手工配置它，容易出错且工作量巨大，纯粹的体力劳动，影响了大规模部署。
- VLAN 号只能是 1－4094 中的一个数字，对于小规模的私有云可能不是个问题，但对于租户众多的公有云，可选择的 VLAN 号的范围是不是少了点呢？
为了克服上面的缺点，Neutron 开发了对 GRE 模式的支持。GRE 是 L3 层的遂道技术，本质是在遂道的两端的 L4 层建立 UDP 连接传输重新包装的 L3 层包头，在目的地再取出包装后的包头进行解析。因为直接在遂道两端建立 UDP 连接，所以不需要在遂道两端路径的物理交换机上配置 TRUNK 的操作。
说说 GRE 的缺点吧：
- GRE 将 L2 层的操作上移到 L3 层来做，性能肯定是会下降的。同时，由于遂道只能是点对点的，所以可以想象，如果有 N 个节点，就会有 N*(N-1)条 GRE 遂道，对于宝贵的 L4 层的端口资源也是一个浪费哦。那也是为什么 GRE 遂道使用 UDP 而不使用 TCP 的原因了，因为 UDP 用完后就可以释放，不用老占着端口又不用。
- 在 Neutron 的 GRE 实现中，即使两台物理机上的两台虚机也不是直接建立 GRE 遂道的。而是通过 L3-agent 网络节点进行中转，这样做是基于方便使用 iptables 隔离网络流量的考虑。
利用 L3 层扩展 L2 层的遂道技术 VXLAN 与 SDN 的本质
VXLAN 是 VMware 的技术，可以克服 VLAN 号不足的问题；同时也可以克服 GRE 实质上作为点对点遂道扩展性太差的问题。
如果说 GRE 的本质是将 L3 层的数据包头重新定义后再通过 L4 层的 UDP 进行传输，那么 VXLAN 的本质就是对 L2 层的数据帧头重新定义再通过 L4 层的 UDP 进行传输。也就是笔者说的所谓的利用 L3 层扩展 L2 层.
既然 L2 层的数据帧头要重新定义，那就随便定义啦，是否满足以下三点是笔者从技术角度将一件产是否视为 SDN 的关键因素：
- 可将 L7 层租户 tenant 的概念做到 L2 层。在笔者的前一篇《漫步云中网络》姊妹篇中已经介绍了 IaaS 云的本质就是卖虚机，即将虚机租给多租户使用后收费。所以位于 L7 应用层的 tenant 的概念是云用来对计算、存储、网络资源进行隔离的重要概念。那么将 tenant 的概念从 L7 层下移到 L2 层中意义重大。
- 也可将类似 VLAN 的概念做到 L2 层，并且由于是软件定义的（不像物理交换机那样受硬件限制），那么很容易突破 VLAN 号在 1－4094 之间的限制。
- 是否提供集中式的控制器对外提供北向 API 供第三方调用来动态改变网络拓扑。
清楚了 SDN 的本质，那么 VXLAN 的本质又是什么呢？
- VXLAN 是一种 L2 层帧头的重新封装的数据格式。
- VXLAN 仍然使用 GRE 遂道通过 UDP 传输重新封装帧头后的数据帧。
VXLAN 重新定义的 L2 层帧头格式如下图 1 所示，其中 VNI VXLAN ID 与 VLAN 的从概念上等同，但是因为它是用软件实现的，范围可用 24 bits 来表示，这就比 VLAN 的 1－4094 大多了。
图 1. VXLAN 帧头格式
因为 VXLAN 通过重新定义 L2 层帧头（相当于通过 MAC 地址进行 NAT 的方案）从而让两个跨 L3 层的甚至广域网内的两个子网从 L2 层上互通。所以 VXLAN 的优点很多，能让遗留子网不改变 IP 地址的情况下无缝的迁移到云上来；也可以让虚机跨数据中心进行迁移（以前顶多只能在同一个 VLAN 里迁移）。
当然，VXLAN 也不是没有缺点的，通过上面的学习，大家已经知道 VXLAN 也是通过 GRE 走 UDP 来传输重定义的标准化的 VXLAN 封装格式的帧头的。由于在遂道的两端之间直接建立遂道，那么它是无法与途经的一些物理设备（如 DHCP 服务器）通信的，那么就需要 VXLAN 网关这种物理设备在遂道的中途截获 VXLAN 数据包（网关网关嘛，就是进行数据截获再转换的），解析里面的数据，然后做一些事情（像流量统计，DHCP 信息等等），最后再将数据重新打成 VXLAN 数据包交给遂道继续传输。可以想象，在所有需要与物理设备打交道的地方都是需要 VXLAN 网关的。觉得麻烦了吗？
利用 L2 层扩展 L3 层的标签技术 MPLS
VLAN 是一种标签技术，VLAN 一般用在局域网的交换机上，标签很容易在 L2 层通过硬件来实现转发。
MPLS 也是一种标签技术，原理类似于 VLAN，但一般用在 WAN 上的路由器上，下面我们说道说道。
对于 L3 层的传统路由转发来说一般是在路由表里查找相应的路由来实现。因为路由嘛，不同的 CIDR 之间可长可短，如 10.0.0.0/8 与 10.0.100.0/24 这两个子网首先长度不一样，其次 CIDR 号一个是 8，一个是 24，在路由器中，是通过字符串的按最长匹配算法来匹配路由的，那么应该选择 10.0.100.0/24 这个路由。字符串的按最长匹配算法很难通过硬件来实现，通过软件速度慢啊。那么广域网的路由器能不能也引入标签通过硬件转发的优点，在路由器作转发时，不再在 L3 层的通过软件去查找路由来实现转发，而是直接在 L2 层就通过标签通过硬件转发了呢？答案就是 MPLS。
例如 A 路由器通过 B 路由器给 C 路由器发包时，传统的路由器是根据目的地址进行转发，A 在开始转发时，并不知道去 C 的完整路由，它只知道转给 B，B 再决定转给 C，这种走一步看一步的叫基于目的地址的路由转发。但是 MPLS 的原理完全不同，A 在给 C 发包时，先发个 HELLO 包从 A 到 C 走一遍，在走的过程中就已经知道了 A 到 C 的路由路径并且根据 LDP（标签分发协议）将 A 到 C 的标签序列就事先确定好了。那样 A 再给 C 发数据时，A 就提前知道了在 L2 层怎么根据标签来转发，所以它不用再到 L3 层查找路由信息了，另外它在 L2 层通过标签转发可以很容易通过硬件来实现，这样速度更快了，最后标签的确定是通过 LDP 协议动态分配的这也避免了像 VLAN 的那种标签需要手工去设置的麻烦。
SDN
在 VXLAN 一节中，笔者已经说过了笔者判断一个产品是否是 SDN 产品的核心判断因素，即是否将 tenant 租户的概念做到了 L2 层并且提供了北向 API 供第三方应用调用动态调整网络拓扑。做到了，就是 SDN 产品。目前，SDN 产品主要有三类：
- 基于 Overlay 技术的，如 VMware 的 VxLAN，如 Microsoft 的 NVGRE，如 IBM 的 Dove
- 基于 OpenFlow 技术的
- 基于专有技术的，如 Cisco 的 onePK
基于 Overlay 技术的 VxLAN 已经在上面介绍过了，这里着重介绍一下 OpenFlow 和 Dove。
OpenFlow
OpenFlow 是完全不同于传统网络技术的新兴网络技术。
传统交换机能通过自主学习建立转发表，然后根据转发表转发。但对于 OpenFlow 交换机，它是很“笨”的，数据帧来了它并不知道往哪个端口转发，不知道怎么办呢？不懂就问呗，找 OpenFlow 控制器问。控制器通过一定算法告诉它往哪个端口转发，然后 OpenFlow 交换机照着做就行了。下图 2 显示了 OpenFlow 的结构：
图 2. OpenFlow 的结构
我并没有将 OpenFlow 归于 L2 层，因为从理论上讲，它并不严格属于 L2 层，因为它设计了 L2－L4 层的转发项进行转发。现在 OpenFlow 的 FIB（转发信息表，Forward Info Base）中至少有下列条目：
- L2 层的 MAC、VLAN 等
- L3 层的 source ip, dest ip
- L4 层的 source port, dest port
- 甚至有基于 WAN 的动态路由的转发项，如 BGP、MPLS 等
OpenFlow 进行转发的时候和传统的网络技术不一样，传统的是存储包转发（数据到了 L2 层就解析出 MAC 地址进行转发，到了 L3 层后就解析出 IP 地址进行转发）。而 OpenFlow 则根据所谓的流进行转发。它将上面的 MAC、VLAN, source ip, dest ip, source port, dest port 等视作平等的平面，直接通过某个高效的字符串匹配算法匹配到了后再做某些动作，如 accept 或者 drop 掉。
再聊聊笔者所理解的 OpenFlow 的缺点。理论上，如果 OpenFlow 通过 L3 层的 IP 进行转发的话，那它就成了一个路由器了。但实际上，目前，OpenFlow 主要还是用在 L2 层当做一个交换机来使用的。如果真要在 L3 层和路由结合的话，那么它将以怎么样的方式和现存的分布式的动态路由协议（如 RIP、OSPF、BGP、MPLS）协作呢？ 并且传统的 WAN 本来为了可靠就是以分布式来设计的，现在搞成 OpenFlow 式的集中式控制，监控什么的是方便了，但一旦控制器挂了那么整个网络也全挂了，并且 OpenFlow 控制器一旦被某方势力所掌握，那么整个 OpenFlow 网络也就全被掌握了，毕竟 WAN 是要考虑这些因素的。所以笔者不认为 OpenFlow 这种集中式控制的路由器能在 WAN 上将取代传统分布式的路由协议，顶多在 LAN 的 L2 层会有一些作为吧。
Dove/OpenDaylight
上面已经说到 SDN 需要对外提供北向 API 供第三方调用。
对于控制器与交换机之间的南向 API 的通讯标准就是由 google, facebook 这些用户主导定制的 OpenFlow 协议。
北向 API 没有标准，南向 API 也五花八门，将 tenant 和 VLAN 的概念做到 SDN 里也没有标准（虽然有 VMware 主导了一个 VXLAN 的数据封装格式），所以业界存在很多 SDN 的产品，Dove 便是由 IBM 实现的其中一种，OpenDaylight 的插件结构可以同时和众多的 SDN 控制器打交道，降低第三方应用同时和众多 SDN 控制器打交道的复杂性。
L3
L3 层的路由分静态路由和动态路由两种：
- 在 Linux 中，通过打开 ipv4 forward 特性可以让数据包从一块网卡路由到另外一块网卡上。
- 动态路由，如内部网关协议 RIP，OSPF；如外部网关协议 BGP。能够自动地学习建立路由表。
目前 Neutron 只支持静态路由，要点如下：
- 对于不同 tenant 子网通过 namespace 功能进行隔离，在 Linux 中，一个命名空间 namespace 您可以简单理解成 linux 又启动了一个新的 TCP/IP 栈的进程。多个 tenant 意味着多个 namespace，也意味着多个 TCP/IP 栈。
- 对于同一 tenant 中的不同子网的隔离通过 iptables 来做，也意味着，同一 tenant 中的相同子网的两个虚机不用走 L3 层，直接走 L2 层能通，没问题；但如果同一 tenant 中的不同子网的两个虚机要通讯的话，必须得绕道 L3-agent 网络节点，这是影响性能的。
L4-L7
LBaaS
OpenStack 最初的目标是做 x86 平台下的开源 IaaS 云，但它目前也有了类似于 LBaaS (Load Balance as a Service)这样本属于 SaaS 的特性。
LbaaS 服务可以为一个 tenant 下的多台虚机提供负载均衡服务，要点如下：
- 提供负载均衡的虚机之间组成一个服务组
- 虚机之间提供心跳检查
- 外部通过 VIP 来访问 LB 服务组提供的服务，动态地将 VIP 根据负载均衡策略绑定到具体提供服务虚机的 fixed ip 上
下图 3 显示了 LBaaS 应用的几种情形：
图 3. LBaaS 的应用场景
说明如下：
- 有两个虚机 192.168.0.3 和 192.168.0.1 组成负载均衡池，它们之间做心跳
- 如果这个 LB 服务只用在内网，可以只为虚机提供一个内部的 vip，如 192.168.0.4
- 如果这个 LB 服务也需要从外部访问，那么这个 vip 可以做成 floating ip，如 10.1.1.10
所以实现上述 LB 服务的 neutron 命令如下：
清单 1. 实现例子 LB 服务的 neutron 命令
neurton lb-pool-create --lb-method ROUND_ROBIN --name mypool --protocol HTTP --subnet-id <subnet-id> neurton lb-member-create --address 192.168.0.3 --protocol-port 80 mypool neurton lb-member-create --address 192.168.0.1 --protocol-port 80 mypool neurton lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3 --timeout 3 neurton lb-healthmonitor-associate <lb-healthomonitor-id> mypool neurton lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-id> mypool neurton lb-vip-create --name myvip --protocol-port 80 --protocol HTTP --subnet-id <subnet-id> mypool neurton floatingip-create public neurton floatingip-associate <floating-ip-id> <lb-vip-port-id>
FwaaS
目前，Neutron 已经实现了一个 Security Group 服务，FWaaS 服务正在开发中。 FwaaS 和 Security Group 的原理差不多，只不过代码重构将以前 Security Group 的代码挪到了现有的 L4/L7 层框架来了；这样，以前 Security Group 作为 nova-compute 的一个组件只能运行在计算节点上，单纯拆出来做为一个独立进程之后也可以部署在 l3-agent 的那个物理机上提供边缘防火墙特性。下图 4 显示了 Security Group 服务的原理图：
图 4. Security Group 原理图
Security Group 由一系列的 iptables rule 组成
- 这些 iptables rule 运行在计算节点上
- 可以控制从虚机出去的流量
- 可以控制进来虚机的流量
- 可以控制虚机之间的流量
实施 Security Group 的步骤如下，例如，四个虚机，可以从 80 端口访问 web 虚机，从 web 虚机上可以访问 database 虚机，ssh 跳转虚机上可以同时访问 database 和 web 虚机，可以通过端口 22 访问 ssh 虚机。
清单2. 实施Security Group 的步骤
neutron security-group-create web neutron security-group-create database neutron security-group-create ssh neutron security-group-rule-create --direction ingress --protocol TCP \ --port-range-min 80 --port-range-max 80 web neutron security-group-rule-create --direction ingress --protocol TCP \ --port-range-min 3306 --port-range-max 3306 --remote-group-id web database neutron security-group-rule-create --direction ingress --protocol TCP \ --port-range-min 22 --port-range-max 22 --remote-group-id ssh database neutron security-group-rule-create --direction ingress --protocol TCP \ --port-range-min 22 --port-range-max 22 --remote-group-id ssh web neutron security-group-rule-create --direction ingress --protocol tcp \ --port-range-min 22 --port-range-max 22 ssh
VPNaaS
我们仍然从技术的本质角度出发来解释什么是 VPN。VPN 类似于 GRE，也是一种遂道。但是不同的是 VPN 也要求不同的用户可以使用相同的子网，所以在每个建立 VPN 的两个端点所对应的边缘路由器上都会为每个用户建立它自己的 VPN 路由实例 VRF，白话一点的话，VRF 就是 Linux 里上面提到过的 namespace 的概念。
建立 GRE 遂道容易，但是 VPN 强调私密性，一个组织的 VPN 总不希望不经授权的访问吧。所以一般使用 SSL 或者 IPSec 结合 GRE 来建立 VPN。也可以通过 MPLS 来建立 VPN。Neutron 中这三类 VPN 目前均在开发之中。从下面 MPLS VPN 的 blueprint 中的图 5 可以看到将来要实现的样子：
图 5. MPLS VPN 实现原理图
目前，l3-agent 没有使用动态路由，使用的是 namespace + ipv4 forward + iptables 的静态路由技术。l3-agent 现在充当着 CE 的角色（Custum Edge)。我们设想一下，笔者认为 BGPMpls Driver 将来至少要实现下列几个方面的内容：
- 调用 PE API 在边缘路由器 PE 上通过 namespace 特性定义并配置 tenant 之间隔离的自己的 VPN 路由实例 VRF
- tenant 定义的 VRF 路由并不需要在每个 WAN 核心路由上都存在，所以可以通过配置输入和输出策略实现，即使用 router-target import/export 命令导入或导出相应的 VRF 条目
- 配置 PE 到 CE 的链路
- 将 CE 的接口关联到预先定义的 VRF
7、Neutron有什么
Neutron 就是一个定义良好的插件框架，用来调用上述 L2-L7 层不同实现，且对外提供北向 API 来提供虚拟网络服务。
它自己提供了 tenant 的概念，它只是一个 SDN 框架，和底层的 SDN 软件如 Dove 集成时可以提供 SDN 的功能，但需要将它的 tenant 和 SDN 自身的 tenant 概念之间做一个映射。
L2
在 L2 层，由虚拟交换机来实现。虚拟交换机有下列这些种：
- Linux 网桥，基于 Linux 内核的网桥。需要说明的是，网桥就是交换机，是交换机的一种常用的书面叫法。
- OpenvSwitch（OVS）：OVS 有两种模式，一种是当普通的虚拟交换机来使用，另一个是和 OpenFlow 控制器协作当作 OpenFlow 控制器来使用。
- 一些基于 Overlay 技术的 SDN 实现，如 Dove 等。
- 一些非开源的商业交换机。
目前，Neutron 已经实现的 L2 层插件如下图 6 所示，linuxbridge 实现了 Linux 网桥，openvswitch 插件实现了 openvswitch 网桥，bigswitch 插件实现了一种 SDN 控制器，ml2 是一种通用的插件（这些 L2 层的插件主要分写数据库的 plugin 部分和运行在计算节点的 agent 部分，plugin 写数据库的字段有差异但不多，所以代码重复，ml2 可以理解为一个公共的 plugin）。且每种插件基本上实现了 FLAT, VLAN, VXLAN, GRE 等四种拓扑。
图 6. Neutron 中 L2 层插件
L3
Neutron 的 L3 层由基于 namespace ipv4 forward + iptables 实现。
需要启动 l3-agent 进程，如果需要 DHCP 服务的话也需要启动 dhcp-agent 进程。
L4-L7
LBaaS 基于 Haproxy 实现；FWaaS 基于 iptables 实现；VPNaaS 有基于 IPSec 的 VPN 实现，也有基于 MPLS 的 VPN 实现，也有基于 SSL 的 VPN 实现。
截止到笔者写此文为止，目前只有 LBaaS 能用，其他的 FWaaS, VPNaaS 和 NATaaS 仍在开发中。但对于 FWaaS 有 Security Group 功能可用，区别在于前者由于作为独立服务也能部署在网络节点上提供边缘防火墙特性，后者依然能够在计算节点上使用 iptables 规则控制从虚机出去的，进来虚机的，虚机之间的流量。
参考：
- 用最精炼语言介绍OpenStack网络代码演进的前世今生： http://www.openstack/p353.html
- 漫步云中网络： http://www.ibm/developerworks/cn/cloud/library/1209_zhanghua_openstacknetwork/
- 漫步云中网络，第 2 部分： http://www.ibm/developerworks/cn/cloud/library/1311_zhanghua_openstacknetwork2/
- OpenStack 网络：Neutron 初探： http://www.ibm/developerworks/cn/cloud/library/1402_chenhy_openstacknetwork/#6.Neutron 服务网络管理的三种模式 |outline
- 探索 OpenStack: 网络组件 Neutron： http://www.ibm/developerworks/cn/cloud/library/cl-openstack-neutron/
- Neutron网络入门： http://blog.ustack/blog/neutron_intro/
- Openstack之neutron简介： http://www.sdnap/sdnap-post/4027.html
- openstack neutron学习（一） ---- neutron-server入口： http://blog.csdn/llg8212/article/details/18003217
更多推荐
OpenStack入门以及一些资料之（二、neutron网络）
发布评论