openstack网络详解


文章目录



1、Flat

Flat模式和FlatDHCP模式其实区别不大,都是基于网桥网络,只是FLat模式需要管理员手动配置(包括配置网桥和外部的DHCP设备)

openstack之网络①_创建虚拟机

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地址。如下图:

openstack之网络①_外网_02
图中的虚线(两个计算节点的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的转发规则(而不是在nove-network主机).该方式把HA的任务交给更可靠的硬件设备,但nova-network仍需要负责floating_ip natting和DHCP,所以仍需要主备策略保证。

Option 4: Multi-host

该方式被认为是最佳的解决方案。即在每个计算节点上部署nova-network,这样每个计算节点为自己主机上的虚拟机负责,为每个计算节点创建网桥并为网桥指定不同的IP(从fixed_ip中取)作为虚拟机网关,在每个主机起DHCP服务,同时要求每个计算节点至少两个物理网卡,每个计算节点负责自己的虚拟机与外网的通信。如下图:

openstack之网络①_目的地址_03

在每个计算节点:

从“flat”IP池中取出一个给网桥

创建dnsmasq DHCP服务并在网桥IP监听

在该节点上创建的所有虚拟机的默认网关为网桥IP

openstack之网络①_创建虚拟机_04

FlatDHCPManager在每个计算节点上创建一个静态的租约文件记录虚拟机的私有IP,文件的数据是从DB中获取,包括MAC、IP、虚拟机名。每个dnsmasq只负责为本节点的虚拟机发放IP,所以从”instance”表的”host”字段过滤即可。如下图所示,每个计算节点的虚拟机都有一个默认网关:

openstack之网络①_目的地址_05
登录虚拟机查看验证:

oot@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

3、VLAN

openstack之网络①_创建虚拟机_06

3.1 与Flat模式的区别

在Flat模式下,管理员的工作流程应该是这样的:

1.为所有租户创建一个IP池

nova-manage network create --fixed_range_v4=10.0.0.0/16 --label=public

2.创建租户

3.租户创建虚拟机,为虚拟机分配IP池中的可用IP

数据库中的虚拟机信息可能是这样:

openstack之网络①_创建虚拟机_07

我们看到,两个虚拟机在同一个网段。

而在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
openstack之网络①_目的地址_08
一个计算节点上有多个租户虚拟机的场景如下:
openstack之网络①_创建虚拟机_09
多个计算节点上场景:

openstack之网络①_目的地址_10

所以有以下结论:在一个计算节点上有几个租户,就有几个网桥,就会创建几个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创建虚拟机:

openstack之网络①_外网_11

不同计算节点上的虚拟机有不同的网关。

场景2:VM_1访问外网(8.8.8.8),且该虚拟机只有fixed_ip

openstack之网络①_创建虚拟机_12

  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

  1. 数据返回

场景3:用户从VM_1pingVM_2
openstack之网络①_外网_13

由于两个虚拟机在同一个计算节点,且属于同一个租户,所以是简单的二层通信。

场景4:用户从VM_1pingVM_5

openstack之网络①_目的地址_14

  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
openstack之网络①_创建虚拟机_15

  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

openstack之网络①_创建虚拟机_16

  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

但是,如果是下面这个情况:
openstack之网络①_创建虚拟机_17

因为只有创建虚拟机时才会创建必要的网桥,所以在左边计算节点上没有租户2的网桥,此时从VM_1 ping VM_6时,数据包不会被路由到右边计算节点。

结论:vlan模式下,不同租户的虚拟机之间通信不能依赖于fixed_ip。

场景7:VM_1和VM_6都关联了floating_ip,VM_1 ping VM_6
openstack之网络①_创建虚拟机_18

假设虚拟机分配的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#指定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部署):

openstack之网络①_外网_19
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中:
openstack之网络①_目的地址_20

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