一篇文章让你理解OpenStack网络

整体设计

首先，OpenStack是用来管理大量的VM的“上帝”。他的目的是要像掌控物理世界一样，去管理大量的VM。即：可以给VM分组，同一个组里面的VM，在同一个网络内，可以互通通信。不同组的VM，则相当于在不同的网络中，互相不能通信。

至于为什么要分组，

1、是跟物理服务器一样，那么多机器，按照不同机房的服务器，连到不同的网络。

2、是我可以把不同组的VM，卖给不同的“用户”，这样，组1的VM属于张三，组2的VM属于李四，这样他们俩互相隔离，互不感知。于是我就可以化身成为云厂商，对外提供云平台服务了。

• 当然你作为云厂商，也肯定要允许一个用户，可以拥有2个网络嘛。万一该客户人傻钱多，就是买了一堆VM，分着玩呢，是吧。

逻辑视图

现实中，2个机房的服务器，网络要想连通，是要靠路由器来帮忙的。在虚拟世界中也是类似的。

所以，逻辑上，VM世界的网络就是长这个样。

张三的VM的网络，要想和李四VM的网络 互通，或者张三自己的2个独立网络互通。就得通过一个叫做 Router 的“虚拟路由器”来完成。

物理视图

上面的逻辑视图，在物理上，则是这个样子的：

至于如何在一根网线上面，同时跑多个虚拟网络的报文。这个就是在一根网线上的报文，有不同门派的意思。具体的可以回去看VLAN/VxLAN章节。

另外，这里你可以看到，虚拟网络里面的一个“Router”，其实不是什么具体的虚拟路由器设备，而仅仅是一个“网络namespace+转发规则”就达成了，下面会细讲。

简单模型

假设现在你来设计OpenStack的网络实现。

那从我们之前学到的OVS章节，可以知道，为了达成上面提到的OpenStack的网络虚拟化目的。最简单的实现是给每个物理服务器上增加一个OVS虚拟交换机；然后每个VM都连到OVS端口上，每个端口则按照分组，打上对应的VLAN标签。就可以达成基本要求。

但是，这个初始1.0版本的实现，有个不牛批的地方，就是没法给VM设置安全组。你作为想成为云平台伟大目标，平台怎么能没有安全组这个能力呢（虽然，在VM里面，可以设置firewell或者iptables规则，但是VM里面，那是已经卖给用户的了，你跑人家房间里面，去设置规则并不合适，可能和用户自己的业务规则冲突）。

所以第2个版本，改进之。我们要在VM的外面设置安全组：

于是，我们在每个VM大门口，增加一个Bridge网桥，任何VM的流量，都会经过这个Bridge。这样，通过在Bridge上面，增加iptables规则，就可以达到给VM设置安全组的目的了。（注意，这个时候，VM的报文还没有到OVS，所以报文还是没有打VLAN标签的原始报文，所以iptables规则也好实现）。

这就是咱们的OpenStack网络2.0版本。

但是，在实践中，你发现这个独苗OVS，要设置端口转发规则有2部分：

• 上半部分。即：给VM设置Tag标签。

每增加一台VM时，就给这个端口打标签，插拔虚拟网线等配置动作。这一部分逻辑比较固定，不怎么变化。

• 下半部分。即：通过物理网线，怎么给报文打“门派”标记。

这一部分变化很大，有时候物理网络，咱得走GRE，有时候要走VLAN，有时候又得VxLAN。还有时候，得走专用的网络设备。平台得根据部署的机房网线，定制不同的规则。

这样这2类OVS的规则不好管（都放openflow的转发表里面），本着程序员的“分库分表”（或者咱们写代码时的，“抽取函数”的逻辑）的思路，咱们把1个独苗OVS，分成多个VOS。分别做不同的事情。

于是，咱们到了3.0版本，这个版本就比较通用了。基本可以和实际OpenStack的网络比较接近了。不过在网络节点部分，还得再增强一下。就是咱们的VM，除了互访之外（流量还在几台物理服务器之间转悠），还得访问外网呀（流量跑机房外部去）。 所以，还得继续增强一下VM访问外部网络的能力：

这么一来，就到了差不多4.0版本了。后面咱们介绍的OpenStack网络，就是照着这个版本来的。在OpenStack网络里面&