【openstack】openstack网络详解（Essex版）

openstack网络详解

这篇文章基本是参考了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