openstack网络详解

gdx

　　这篇文章基本是参考了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，所以仍需要主备策略保证。
　　&Oslash;  Option 4: Multi-host
　　该方式被认为是最佳的解决方案。即在每个计算节点上部署nova-network，这样每个计算节点为自己主机上的虚拟机负责，为每个计算节点创建网桥并为网桥指定不同的IP（从fixed_ip中取）作为虚拟机网关，在每个主机起DHCP服务，同时要求每个计算节点至少两个物理网卡，每个计算节点负责自己的虚拟机与外网的通信。如下图：
　　

　　在每个计算节点：
　　&laquo;  从&ldquo;flat&rdquo;IP池中取出一个给网桥
　　&laquo;  创建dnsmasq DHCP服务并在网桥IP监听
　　&laquo;  在该节点上创建的所有虚拟机的默认网关为网桥IP
　　

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

　　登录虚拟机查看验证：
　　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模式为网络增加了两个东西：
　　&laquo;  将网络与租户关联
　　&laquo;  为网络分配一个vlan号
3.2    多nova-network主机部署的VLAN模式
　　VlanManager做三件事：
　　1.     在计算节点为租户的网络创建独占的网桥
　　2.     在计算节点的物理网口eth0之上创建vlan接口（虚拟接口）
　　3.     在网桥处关联一个dnsmasq进程，为虚拟机分配IP
　　

　　一个计算节点上有多个租户虚拟机的场景如下：
　　

　　多个计算节点上场景：
　　

　　所以有以下结论：在一个计算节点上有几个租户，就有几个网桥，就会创建几个dnsmasq进程。而且不同租户的虚拟机之间不能通信。同时，依赖于系统管理员配置交换机。
　　上图中，租户&ldquo;t1&rdquo;从10.0.2.2虚拟机pingIP地址10.0.2.5的通信过程：
　　&sect;   首先数据包从10.0.2.2发往网桥br102，在该数据包打上vlan102的标签发往交换机
　　&sect;   交换机把数据包传递到第二个节点，此时会校验数据包的vlan标签
　　&sect;   如果校验成功，节点把数据包发往vlan102接口
　　&sect;   vlan102接口把vlan标签从数据包中剥离，以便可以发往虚拟机
　　&sect;   数据包通过br102，最终到达10.0.2.5
3.3    multi-host部署模式下的通信流程
　　&Oslash;  场景1：tenant1创建虚拟机：
　　

　　不同计算节点上的虚拟机有不同的网关。
　　&Oslash;  场景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.     数据返回
　　&Oslash;  场景3：用户从VM_1pingVM_2
　　

　　由于两个虚拟机在同一个计算节点，且属于同一个租户，所以是简单的二层通信。
　　&Oslash;  场景4：用户从VM_1pingVM_5
　　

　　1.     两个虚拟机在同一网段，但在不同计算节点上。VM_1发送ARP广播包查询VM_5的MAC地址
　　2.     广播包到达br100
　　3.     数据包转发到vlan100（带vlan标签）
　　4.     数据包通过物理交换机（交换机配置为&rdquo;trunk&rdquo;模式）
　　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
　　这样，两个租户的虚拟机之间就可以相互通信。
　　&Oslash;  场景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
　　&Oslash;  场景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。
　　&Oslash;  场景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
　　&Oslash;  首先，管理员先配置IP池：
　　nova-manage floating create --ip_range=PUBLICLY_ROUTABLE_IP_RANGE  --pool  POOL_NAME
　　&Oslash;  用户创建虚拟机
　　+--------------------------------------+---------+--------+--------------------------------+
　　|                  ID                         |   Name  | Status  |            Networks            |
　　+--------------------------------------+---------+--------+--------------------------------+
　　| 79935433-241a-4268-8aea-5570d74fcf42   |  inst1  | ACTIVE |  private=10.0.0.4               |
　　+--------------------------------------+---------+--------+--------------------------------+
　　&Oslash;  查询可用的floating_ip
　　nova floating-ip-pool-list
　　+------+
　　| name |
　　+------+
　　| pub  |
　　| test |
　　+------+
　　&Oslash;  从&ldquo;pub/test&rdquo;获取一个IP
　　nova floating-ip-create pub
　　
　　+---------------+-------------+----------+------+
　　|       Ip      | Instance Id | Fixed Ip | Pool |
　　+---------------+-------------+----------+------+
　　| 172.24.4.225  |     None    |   None   | pub  |
　　+---------------+-------------+----------+------+
　　&Oslash;  为虚拟机绑定IP
　　nova add-floating-ip 79935433-241a-4268-8aea-5570d74fcf42  172.24.4.225
　　&Oslash;  查看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时，两个东西发生变化：
　　&Oslash;  floating_ip作为计算节点eth1的secondary地址，可以通过&rdquo;ip addr show eth1&rdquo;命令查看：
　　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
　　&Oslash;  增加计算节点的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    通信流程
　　从外网访问虚拟机：
　　&Oslash;  首先数据包到达计算节点的eth1，DNAT规则开始处理，数据包的目的IP变为私有IP：
　　91.207.16.144 -->10.0.0.3
　　&Oslash;  计算节点通过查看路由表，将数据包发往br100，通过br100发往目标虚拟机
　　ip route show：
　　10.0.0.0/24 dev br100
　　从虚拟机访问外网（以ping 8.8.8.8为例）：
　　&Oslash;  因为目的IP不在虚拟机网段，数据包会发送到虚拟机的默认网关，也就是br100
　　&Oslash;  计算节点检查路由表，也没发现对应的路由规则，于是发往默认网关91.207.15.105
　　&Oslash;  数据包由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 &ndash;F &ndash;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