原文：THERE’S REAL MAGIC BEHIND OPENSTACK NEUTRON
译注：这篇博文基于 OpenStack IceHouse 版本写成。看完原文，直感到醍醐灌顶，也因此产生了翻译此文的冲动。说实话，本文的图画的很好，但有些地方逻辑却是很乱或者过于啰嗦。所以本文在必要的时候会进行一定意译，以使逻辑更为通顺。作为个人第一次科技博文翻译，定会存在各种瑕疵，敬请多多指出。
在任何博客网站上创建博文是相当容易的事。通过在笔记本电脑、手机或者平板电脑上几下鼠标点击，或者通过转发别人的博客就能够做到，最困难的在于对博文内容的思考。类比到 OpenStack，同样通过几下鼠标点击就可以创建虚拟机、路由器、子网、防火墙、VPN、负载均衡器（Load Balancer）。不过，首先，需要规划并想好为什么需要创建它们，而不仅仅因为能够创建而创建它们。基于这些虚拟设备所要支持的应用，还需要定义虚拟 IT 架构。
在我之前有关 Neutron 的博文中，提到 Neutron 所具备的 L3 功能，且对其的创建和管理也很容易。现在，我将在本文中描述着背后的魔法。我确信你将会跟我一样喜爱它。OpenStack Neutron 充分应用了 SDN（Software Defined Network），其中最常用的第三方插件是 OpenVSwitch。
首先，我想要提下，OpenStack 赞助商和社区贡献者已经提供了很多信息：
- 来自 RedHat 的 Networking in too much detail 博文
- OpenStack 官方文档 Networking Docs
Nova 计算节点
让我们从部署有 Neutron 和 OpenVSwitch 的 Nova 计算节点开始谈起。在这里，我们拥有一些虚拟机，网络流量从它们开始也最终结束于它们。这些虚拟机都依附有一个以太网虚拟网卡接口 tap 设备。这些 tap 设备在虚拟中被定义为逻辑网络接口 eth0。这些 tap 设备直接连接到 Linux 网桥（Linux Bridge）。在这些网桥上，通过 IPTables 定义了 OpenStack 的安全组（Security Group）。对每一个虚拟机而言，Linux 网桥是透明的，并且每一个安全组只能关联到一个虚拟机上。一个 Linux 网桥就是运行在 Linux 网络栈（Linux Network Stack）中的包含 IPTables 的进程，而一个网络栈包含了通过第 2 或 3 网络协议层连接到其他系统的最少网络资源。
译注：
- 按照博文 Linux 中的虚拟网络的说法，TAP 是一个虚拟网络内核驱动，该驱动实现 Ethernet 设备，并在 Ethernet 框架级别操作。TAP 驱动提供了 Ethernet “tap”，访客 Ethernet 框架能够通过它进行通信。也就是说，实际上，
tap 设备就是一个软件定义出来网卡设备，在虚拟机中被定义为逻辑接口 eth0。 - 对于为什么要额外增加一个 Linux 网桥，博文 OpenStack Neutron运行机制解析概要有一个比较不错的解释：Ideally, the TAP device vnet0 would be connected directly to the integration bridge, br-int. Unfortunately, this isn’t possible because of how OpenStack security groups are currently implemented. OpenStack uses iptables rules on the TAP devices such as vnet0 to implement security groups, and Open vSwitch is not compatible with iptables rules that are applied directly on TAP devices that are connected to an Open vSwitch port. 其实就是说，
OpenvSwitch 不支持现在的 OpenStack 的实现方式，因为 OpenStack 是把 IPTables 规则丢在 TAP 设备中，以此实现了安全组功能。没办法，所以用了一个折衷的方式，在中间加一层，用 Linux Bridge 来实现吧，这样，就莫名其妙了多了一个 qbr 网桥。
OpenVSwitch 网桥跟 Linux 网桥并不兼容，那就在我们的架构中定义一对接口，叫做 qbr 和 qvo。qbr 直接连接到 Linux 网桥，qvo 连接到集成网桥（Integration Bridge）。集成网桥是 OpenVSwitch 解决方案的一部分，负责对进出该网桥的报文添加 VLAN 标签（tag） 或者去除 Vlan 标签。它同时也负责连接属于同一个租户的所有虚拟机，或者转发报文到隧道网桥（Tunnel Bridge）以最终转发到外部设备。
隧道网桥（br-tun）通过 patch-in 接口连接到集成网桥（br-int）。OpenFlow 定义了通过该网桥中的隧道的报文处理规则。隧道是通过 GRE 定义。每一个 GRE 隧道 ID 都会关联到一个 Vlan ID。
译注：patch-in 指的是 OpenVSwitch 中用于连接两个网桥的接口
架顶式（Top of Rack, TOR）和核心云交换机
所有的节点（控制、计算、网络节点等等）通过高性能交换机连接在一起。这个架构在控制虚拟资源之间的数据流通的好处在于这些交换机只提供了第 2 层的数据运输，仅仅需要一个主 VLAN 来分隔内部和外部报文——可能都不需要 2 个。
我们也不需要提供高级的路由、GRE、安全这些组件，它们都由 Neutron 和 OpenVSwitch 来提供。另外，我们不受供应商的束缚——至少我们能够开始使用一些专门插件，以管理硬件或其他电气设备。那么，我们就可以使用来自不同供应商的数据管理平台，以处理大数据和达到低延迟。
Neutron 网络节点
Neutron 节点是单独的主机，在该主机上运行了更高级的网络服务或模块（如路由器、DHCP、防火墙）。所有通过 GRE 隧道从 Nova 主机到达外部网络（或者互联网）的流量都结束于 Neutron 节点定义的 br-tun 网桥。br-tun 上实施了 OpenFlow 规则，这些规则定义了 VLAN ID 和 GRE 隧道 ID 之间的匹配，并且 VLAN 和 GRE 之间的转换也发生在此网桥上。这个网桥在 Neutron 节点中通过 patch-in 接口连接到集成网桥（br-int）上。
在 Neutron 节点上，br-int 网桥对来往路由器和 DNSMasq 的报文打标签或去除标签。路由器和 DNSMasq 都有自己独立的命名空间和 Linux 网络栈。命名空间允许关联到不同租户的存在重叠地址空间的路由器之间的流量交互。路由器则在租户的子网之间转发流量和接收或发送外部网络的流量。同样，这些路由器也使用 Linux IPTables 来过滤流量和实现浮动 IP 与 虚拟机之间的 NAT（Network Address Translation）功能。DNSMasq 同样工作在 Linux 网络栈，提供的 DHCP 和 DNS 进程只专门服务于关联的租户。
译注：博文 OpenStack Neutron运行机制解析概要对虚拟网桥 br-ex 有一个简要说明：br-ex 实际上是混杂模式加载在物理网卡上，实时接收着网络上的数据包。至此，我们的计算节点上的 VM 就可以与外部的网络进行自由的通信了。当然，前提是我们要给这个 VM 已经分配了float-ip。
设计 Neutron+OVS 架构的关键点
Neutron 包含了路由器、基础/高级网络和安全服务，并且几乎所有的数据都会经过 Neutron 节点，所以尽最大可能给这些节点增加内存。内存是最常用的资源。同时考虑至少配置两个拥有一样配置的主机，利用其中一个作为另外一个的备份。
采用高性能的交换机同样很重要，因为 OpenStack 节点之间存在大规模数据交互；为云数据交换设计至少两层协议栈；尝试将同一租户的虚拟机之间的流量限制在同一空间内——几乎所有的流量都会在架顶式交换机（TOR）之间流通。
就这样，下次见！