这篇文章基本是参考了http://www.mirantis.com/blog/的几篇英文blog，进过翻译和整理，详细介绍了openstack Essex版的网络模型，虽然在Folsom版启动了Quantum，但并不成熟，如果是部署中没有用到网络高级特性，建议大家还是使用nova-network。
1 Flat
Flat模式和FlatDHCP模式其实区别不大，都是基于网桥网络，只是FLat模式需要管理员手动配置（包括配置网桥和外部的DHCP设备）.
2 FlatDHCP
这种模式下与Flat模式不同的地方在于有一个DHCP进程，每一个运行nova-network进程的节点（网络控制节点/nove-network主机）就是一个单独的网络。Nova会在nove-network主机建立网桥（默认名称br100，配置项flat_network_bridge=br100），并给该网桥指定该网络的网关IP，同时Nova在网桥处起一个DHCP进程，最后，会建立iptables规则（SNAT/DNAT）使虚拟机能够与外界通信，同时与一个metadata服务器通信以取得cloud内的信息。
计算节点负责创建对应节点的网桥，此时的计算节点网卡可以不需要IP地址，因为网桥把虚拟机与nove-network主机连接在一个逻辑网络内。虚拟机启动时会发送dhcpdiscover以获取IP地址。如下图：
图中的虚线（两个计算节点的eth0）表示节点之间的网络，可选。虚拟机通往外界的数据都要通过nove-network主机，DHCP在网桥处监听，分配fixed_range指定的IP段。
2.1 Drawback
这种部署方式的缺点之前说过—-单节点故障、无二层隔离（即所有的虚拟机都在一个广播域）。
2.2 HA方案
为了解决单节点故障问题，有如下几个方案可供选择：
Ø Option 1: Failover
NTT实验室的工作人员通过配置网络控制节点使用主备模式实现HA，但宕机需要4秒的时间恢复，不能用于实时应用
Ø Option 2: Multi-nic
这种模式使虚拟机桥接到不同的网络，每个网络中为虚拟机创建网卡、指定IP，每个网络可以有自己的nove-network主机作为网关。虚拟机可能会有多个路由，如果一个失败，可以选择使用另一个，该方式的缺点是对于用户来说，需要感知多个网络，同时指定切换策略。同时，必须为每一个网卡关联floating_ip。
Ø Option 3: HW Gateway
可以配置dnsmasq使用外部硬件网关作为虚拟机网关。可以配置dhcpoption=3,<ip of gateway>。这需要人工干预，即需要在外部网关设备上设置IP的转发规则（而不是在nove-network主机）.该方式把HA的任务交给更可靠的硬件设备，但nova-network仍需要负责floating_ip natting和DHCP，所以仍需要主备策略保证。
Ø Option 4: Multi-host
该方式被认为是最佳的解决方案。即在每个计算节点上部署nova-network，这样每个计算节点为自己主机上的虚拟机负责，为每个计算节点创建网桥并为网桥指定不同的IP（从fixed_ip中取）作为虚拟机网关，在每个主机起DHCP服务，同时要求每个计算节点至少两个物理网卡，每个计算节点负责自己的虚拟机与外网的通信。如下图：
在每个计算节点：
« 从“flat”IP池中取出一个给网桥
« 创建dnsmasq DHCP服务并在网桥IP监听
« 在该节点上创建的所有虚拟机的默认网关为网桥IP
FlatDHCPManager在每个计算节点上创建一个静态的租约文件记录虚拟机的私有IP，文件的数据是从DB中获取，包括MAC、IP、虚拟机名。每个dnsmasq只负责为本节点的虚拟机发放IP，所以从”instance”表的”host”字段过滤即可。如下图所示，每个计算节点的虚拟机都有一个默认网关：
登录虚拟机查看验证：
root@vm_1:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.1 0.0.0.0 UG 0 0 0 eth0
root@vm_3:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.4 0.0.0.0 UG 0 0 0 eth0
默认情况下，一个域中的所有虚拟机都可以看到彼此，而不管虚拟机属于哪个租户，但可以通过配置来强制虚拟机间的隔离：
allow_same_net_traffic=False
该配置通过iptables规则来阻止虚拟机间的通信（即便是同一个租户的虚拟机），除非使用安全组策略实现通信。
2.3 配置
相关的配置项看起来应该是这样：
# 使用的网络模式
network_manager=nova.network.manager.FlatDHCPManager
# 连接虚拟机的网桥名称
flat_network_bridge=br100
# 网桥绑定的网卡
flat_interface=eth0
# 在flat模式，下面的配置允许在虚拟机启动前将IP地址注入到镜像的/etc/network/interfaces
flat_injected=True
# 私有IP池
fixed_range=YOUR_IP_RANGE_FOR_FIXED_IP_NETWORK
2.4 一个单nova-network节点部署示例
见另一篇blog
3 VLAN
3.1 与Flat模式的区别
在Flat模式下，管理员的工作流程应该是这样的：
1. 为所有租户创建一个IP池
nova-manage network create –fixed_range_v4=10.0.0.0/16 –label=public
2. 创建租户
3. 租户创建虚拟机，为虚拟机分配IP池中的可用IP
数据库中的虚拟机信息可能是这样：
我们看到，两个虚拟机在同一个网段。
而在Vlan模式下，流程变成如下：
1. 创建新的租户，并记下租户的标识
2. 为该租户创建独占的fixed_ip段
nova-manage network create –fixed_range_v4=10.0.1.0/24 –vlan=102 –project_id=”tenantID”
3. 租户创建虚拟机，从租户的私有IP段内分配IP给虚拟机
所以，与Flat模式相比，Vlan模式为网络增加了两个东西：
« 将网络与租户关联
« 为网络分配一个vlan号
3.2 多nova-network主机部署的VLAN模式
VlanManager做三件事：
1. 在计算节点为租户的网络创建独占的网桥
2. 在计算节点的物理网口eth0之上创建vlan接口（虚拟接口）
3. 在网桥处关联一个dnsmasq进程，为虚拟机分配IP
一个计算节点上有多个租户虚拟机的场景如下：
多个计算节点上场景：
所以有以下结论：在一个计算节点上有几个租户，就有几个网桥，就会创建几个dnsmasq进程。而且不同租户的虚拟机之间不能通信。同时，依赖于系统管理员配置交换机。
上图中，租户“t1”从10.0.2.2虚拟机pingIP地址10.0.2.5的通信过程：
§ 首先数据包从10.0.2.2发往网桥br102，在该数据包打上vlan102的标签发往交换机
§ 交换机把数据包传递到第二个节点，此时会校验数据包的vlan标签
§ 如果校验成功，节点把数据包发往vlan102接口
§ vlan102接口把vlan标签从数据包中剥离，以便可以发往虚拟机
§ 数据包通过br102，最终到达10.0.2.5
3.3 multi-host部署模式下的通信流程
Ø 场景1：tenant1创建虚拟机：
不同计算节点上的虚拟机有不同的网关。
Ø 场景2：VM_1访问外网（8.8.8.8），且该虚拟机只有fixed_ip
1. VM_1发送ping数据包
2. 目的地址不在本网段，于是数据包发往虚拟机的网关（10.0.0.1）
3. 计算节点查看路由表，没有发现对应的路由规则，于是发送到计算节点默认网关（91.207.15.105）
4. iptables的SNAT规则处理：
nova-network-snat -s 10.0.0.0/24 -j SNAT –to-source 91.207.15.105
该规则是根据配置文件中的routing_source_ip=91.207.15.105
5. 数据返回
Ø 场景3：用户从VM_1pingVM_2
由于两个虚拟机在同一个计算节点，且属于同一个租户，所以是简单的二层通信。
Ø 场景4：用户从VM_1pingVM_5
1. 两个虚拟机在同一网段，但在不同计算节点上。VM_1发送ARP广播包查询VM_5的MAC地址
2. 广播包到达br100
3. 数据包转发到vlan100（带vlan标签）
4. 数据包通过物理交换机（交换机配置为”trunk”模式）
5. 数据包到达第二个计算节点，因为带有vlan100标签，所以只有vlan100接口能接收
6. 通过br100
7. VM_5收到广播并返回响应
有这样的需求，可能不同的租户是来自同一个公司的不同开发者或部门，所以他们之间需要相互通信，此时就需要设置安全组规则：
tenant1: nova secgroup-add-rule default tcp 1 65535 10.1.0.0/24
tenant2: nova secgroup-add-rule default tcp 1 65535 10.0.0.0/24
这样，两个租户的虚拟机之间就可以相互通信。
Ø 场景5：配置了安全组规则，VM_1pingVM_3
1. 两个虚拟机属于不同的租户，不同的网段，但在同一个计算节点。于是来自VM_1的包发送到默认网关10.0.0.1
2. 包到达br100
3. 计算节点根据路由表将包路由到br102
4. 包到达br102，根据ARP广播找到VM_3的MAC地址
5. VM_3返回MAC地址。因为两个虚拟机不再同一个网段，VM_3会把数据包发到默认网关10.1.0.1，数据包随后会被路由到租户1的网络。
看一下两个计算节点的相关路由：
10.0.0.0/24 dev br100 proto kernel scope link
10.1.0.0/24 dev br102 proto kernel scope link
Ø 场景6：VM_1pingVM_6
1. 两个虚拟机属于不同的租户，不同的网段，在不同的计算节点上。VM_1的包发送到默认网关
2. 包到达br100
3. 计算节点看到目的地址（10.1.0.0/24）的路由是br102，于是包被路由到br102
4. 现在数据包在租户2的二层网络内
5. 获取一个vlan标签
6. 数据包通过交换机
7. 包到达其他计算节点，因为带有vlan102的标签，于是通过vlan102接口，标签被剔除
8. 包通过br102到达VM_6
9. VM_6向VM_1回响应（目的地址10.0.0.3），包发送到默认网关10.1.0.5
10. 包被路由到br100
11. 现在数据包在租户1的二层网络内
12. 打vlan100标签
13. 通过交换机
14. 到达左边计算节点的物理网络接口，因为属于vlan100，所以被转发到vlan100接口，剔除vlan标签
15. 数据包通过br100到达VM_1
但是，如果是下面这个情况：
因为只有创建虚拟机时才会创建必要的网桥，所以在左边计算节点上没有租户2的网桥，此时从VM_1 ping VM_6时，数据包不会被路由到右边计算节点。
结论：vlan模式下，不同租户的虚拟机之间通信不能依赖于fixed_ip。
Ø 场景7：VM_1和VM_6都关联了floating_ip，VM_1 ping VM_6
假设虚拟机分配的floating_ip如下：
tenant1: VM_1: 91.208.23.11
tenant2: VM_6: 91.208.23.16
1. 从VM_1ping 91.208.23.16，数据包源地址10.0.0.3，目的地址91.208.23.16
2. 数据包被发送到默认网关10.0.0.1
3. 计算节点的路由允许其被发送到eth1
4. iptables的SNAT规则处理，源地址改为91.208.23.11
5. 数据包到达另一个计算节点，由该计算节点上的iptables的DNAT规则处理，目的地址改为10.1.0.4
6. 根据目的地址，数据包被路由到br102
7. 到达目标虚拟机VM_6
ICMP的响应走的路径类似，但注意的是，ICMP响应被认为与ICMP请求关联，所以在左边计算节点上没有显式的DNAT的处理，由系统内部处理。
3.4 配置
#指定network manager
network_manager=nova.network.manager.VlanManager
#使用哪个接口创建vlan
vlan_interface=eth0
#起始vlan号。这种情况下，小于100的vlan号可以用于内部通信
vlan_start=100
3.5 Drawback
1. vlan模式下，不同租户使用的IP地址不能重复（在AmazonVPC中是可以重复的）
2. 由于vlan标签的标志位是12bit，所以vlan号的范围是1-4096，也就是系统中最多只能有4096个租户，不适用于公有云（Nicira NVP作为Quantum的插件解决了这个问题）
4 关于floating_ip
floating_ip是需要用户主动申请并绑定到用户虚拟机，并且可以从虚拟机解绑定，然后绑定到另一个虚拟机，一旦虚拟机被删除，floating_ip仍然属于用户，不会被删掉。目前，floating_ip不支持一个IP绑定多个虚拟机实例以实现负载均衡（Amazon ELB）。
而fixed_ip是虚拟机创建时自动分配，而且，如果虚拟机被意外删除，但又通过虚拟机快照恢复后，fixed_ip会发生变化。
管理员可以配置多个floating_ip池，用户可以从不同的池中获取IP，这里配置多个IP池的目的是从不同的ISP提供商获取IP池，保证链接，这样即使一个ISP挂掉，不影响其他IP池的使用。
4.1 分配floating_ip
Ø 首先，管理员先配置IP池：
nova-manage floating create –ip_range=PUBLICLY_ROUTABLE_IP_RANGE –pool POOL_NAME
Ø 用户创建虚拟机
+————————————–+———+——–+——————————–+
| ID | Name | Status | Networks |
+————————————–+———+——–+——————————–+
| 79935433-241a-4268-8aea-5570d74fcf42 | inst1 | ACTIVE | private=10.0.0.4 |
+————————————–+———+——–+——————————–+
Ø 查询可用的floating_ip
nova floating-ip-pool-list
+——+
| name |
+——+
| pub |
| test |
+——+
Ø 从“pub/test”获取一个IP
nova floating-ip-create pub
+—————+————-+———-+——+
| Ip | Instance Id | Fixed Ip | Pool |
+—————+————-+———-+——+
| 172.24.4.225 | None | None | pub |
+—————+————-+———-+——+
Ø 为虚拟机绑定IP
nova add-floating-ip 79935433-241a-4268-8aea-5570d74fcf42 172.24.4.225
Ø 查看floating_ip的分配情况
nova floating-ip-list
+————–+————————————–+———-+——+
| Ip | Instance Id | Fixed Ip | Pool |
+————–+————————————–+———-+——+
| 172.24.4.225 | 79935433-241a-4268-8aea-5570d74fcf42 | 10.0.0.4 | pub |
+————–+————————————–+———-+——+
到此为止，虚拟机就能通过外网访问。
4.2 引起哪些变化
虚拟机在绑定floating_ip后，内部的网路配置并没有变化，所有的配置都由nova-network完成.先看下图示（vlanmanager模式的multi-host部署）：
eth1连接外网（IP：91.207.15.105，该IP也是该计算节点的默认网关），eth0连接内网（没有指定IP），当虚拟机关联floating_ip时，两个东西发生变化：
Ø floating_ip作为计算节点eth1的secondary地址，可以通过”ip addr show eth1”命令查看：
inet 91.207.15.105/24 scope global eth1 # primary eth1 ip
inet 91.207.16.144/32 scope global eth1 # floating ip of VM_1
Ø 增加计算节点的iptables中NAT表的规则
# 这条规则保证了在计算节点上可以访问虚拟机私有IP
-A nova-network-OUTPUT -d 91.207.16.144/32 -j DNAT –to-destination 10.0.0.3
# 这条规则保证从外网发向91.207.16.144的数据包能转发的10.0.0.3
-A nova-network-PREROUTING -d 91.207.16.144/32 -j DNAT –to-destination 10.0.0.3
# 这条规则保证从虚拟机发往外网的数据包的源IP为其flaoting_IP
-A nova-network-float-snat -s 10.0.0.3/32 -j SNAT –to-source 91.207.16.144
相关的nova-network代码在nova/network/linux_net.py中：
4.3 通信流程
从外网访问虚拟机：
Ø 首先数据包到达计算节点的eth1，DNAT规则开始处理，数据包的目的IP变为私有IP：
91.207.16.144 –>10.0.0.3
Ø 计算节点通过查看路由表，将数据包发往br100，通过br100发往目标虚拟机
ip route show：
10.0.0.0/24 dev br100
从虚拟机访问外网（以ping 8.8.8.8为例）：
Ø 因为目的IP不在虚拟机网段，数据包会发送到虚拟机的默认网关，也就是br100
Ø 计算节点检查路由表，也没发现对应的路由规则，于是发往默认网关91.207.15.105
Ø 数据包由iptables的SNAT规则处理，源IP被修改为虚拟机的floating_ip（91.207.16.144）
4.4 需要注意的点
因为openstack有对网络设置的完全的控制权限，因此网络设置很容易被人为操作破坏。如果需要修改iptables的行为，最好的方式是修改代码（linux_net.py）。
这从另一个方面也说明，openstack没有对iptables规则的监控策略，如果人为修改了规则，则需要nova-network重启才能恢复。举个例子：
比如当前的计算节点有如下规则：
-A nova-network-PREROUTING -d 91.207.16.144/32 -j DNAT –to-destination 10.0.0.3
如果管理员不慎使用了：iptables –F –t nat
这样上述的NAT规则被清掉，但eth1仍然有secondary地址91.207.16.144，当一个发往虚拟机的数据包到达计算节点时，因为没有了DNAT规则，所以数据包会直接到达计算节点。直到下次nova-network重启才能解决该问题。
4.5 相关的配置
# floating_ip绑定到哪个网络接口，作为该网络接口的secondary IP
public_interface=”eth1″
# 默认的floating_ip池
default_floating_pool=”pub”
# 是否在创建虚拟机时自动分配floating_ip
auto_assign_floating_ip=false
转载请注明：爱开源 » openstack网络详解