OpenStack网络
OpenStack网络设置比较复杂,阅读了一些文档,主要是采用两种网络 flat network 和 vlan manager
综合一些文档和自己的理解,整理本文档
Dnsmasq和IP管理
Dnsmasq [1]
Dnsmasq是一个轻量级的易于配置的DNS转发和DHCP服务器,它被设计成一个提供给小型网络使用的DNS和可选的DHCP服务。可以提供本地主机的名字解析,这样可以不必使用全局DNS。DHCP服务被集成到DNS服务器中,允许主机使用DHCP分配地址来显示在DNS名字配置中,名字配置可以使用每个主机或者集中配置文件。Dnsmasq支持静态和动态DHCP以及用于无盘主机启动的BOOTP/TFTP/PXE。
Dnsmasq目标是使用NAT并连接到因特网的家庭网络(支持1000个客户机),并且易于配置。
在OpenStack中,虚拟机的IP地址可以通过 dnsmasq 来进行管理。
注意,由于 Dnsmasq 提供了DHCP动态分配网络IP地址,务必确保网络隔离设置正确,以免影响现有网络的稳定。
dncpd-dnsmasq.pdf 一文,这篇文档描述的是外部网络采用dhcpd动态分配IP地址,同时OpenStack的vm采用Dnsmasq动态分配IP,同时共用两个DHCP服务器,采用不同的网段IP分配同时绑定不同的网卡接口。
在公司的网络中,同样也有类似的环境,每个物理服务器都启动了一个vlan的bonding接口:
# brctl show
bridge name bridge id STP enabled interfaces
bond0.129 8000.90b11c505515 no vlan129
也就是说,每个物理服务器上的虚拟网桥(网桥会和一个802.1q的vlan绑定,所以每个物理服务器实际上是在一个隔离的vlan中),都会有一个虚拟的网络接口,类似 vlan129 。这样,dnsmasq只要选择了这个vlan129接口,就可以隔离在自己的网络中(网络影响会很小,因为每个vlan可能仅包含几个物理服务器)。
OpenStack Networking [2]
OpenStack网络服务,代码名称是Netron(英文解释”中子”),提供了一个API用于定义网络连接和在云计算中定位。这个网络服务使操作者结合不同的网络技术来加强云计算网络。同时也提供了API来配置和管理一系列网络服务,从三层转发和NAT到负载均衡,边际防火墙,以及IPSEC VPN。
有关Neutron的网络API和特性,可参考 OpenStack Networking API v2.0 Reference 。
网络API
网络API使虚拟网络,子网,端口抽象来描述网络资源:
- Network - 一个隔离的L2(两层)网段,类似物理网络中的VLAN
- Subnet - 一个IPv4或v6地址块和相应的配置状态
- Port - 连接到一个单一设备的一个连接点,例如一个虚拟服务器的网卡连接到一个虚拟网络。也描述相应的网络配置,例如用于这个Port的MAC和IP地址
插件结构(Plug-in architecture)
初始的Compute网络实现假设一个通过Linux VLAN和iptables隔离的基本模式。OpenStack Networking引入一个plug-in的概念,使用插件在后端实现了网络API。一个插件可以使用一系列的技术来实现逻辑上的API请求。一些网络插件可能使用了基本的Linux VLAN和Iptables,另外一些插件则实现了更高级的技术,例如L2-in-L3 tunneling或者OpenFlow,来提供类似的特性。
Plug-in停止开发说明
从Havana版本开始Open vSwitch和Linux Bridge插件将不再发展,所有功能被迁移到ML2插件。ML2当前提供了Linux Bridge, Open vSwitch 和 Hyper-v 机制的驱动。
插件可以具有不同的硬件要求的特性,性能,伸缩性或者操作工具。由于网络支持大量的插件,一个云计算管理员有大量的选项来决定部署的正确网络技术。
在OpenStack Havana发行版中,OpenStack网络提供了 Modular Layer 2(ML2) plug-in
网络架构
OpenStack Networking是一个独立的服务,类似其他的OpenStack服务,如Coumpute, Image service, Identity service 或 Dashboard。
OpenStack Networking服务使用 neutron-server
如果部署一个controller主机来运行集中化的Compute组件,也可以将Networking服务部署在同一台主机上。然而,Networking是完全独立并且可以独立部署在自己的主机上。基于部署结构,Networking可以包含以下代理:
代理 | 描述 |
plug-in agent ( neutron-*-agent | 在每个hypervisor上运行以执行本地vSwitch配置。 这个插件是否运行取决于使用的插件,有些插件不需要代理。 |
dhcp agent ( neutron-dhcp-agent | 为tenant网络提供DHCP服务,有些插件需要这个代理。 |
l3 agent ( neutron-l3-agent | 为tenant网络中的VM提供扩展网络访问的L3/NAT转发。 有些插件需要这个代理。 |
l3 metering agent ( neutron-metering-agent | 提供tenant网络的三层网络流量测量。 |
这些代理和主neutron进程的通讯通过RPC(例如,rabbitmq 或者 qpid)或者标准的网络API。更进一步:
- Networking依赖Identity service(keystone)来进行认证和授权所有的API请求。
- Compute (Nova) 和Networking的交互是通过调用Networking的标准API。作为创建一个VM的一部分, nova-compute
- Dashboard(Horizon)集成了Networking API,这样管理员和用户通过web界面可创建和管理网络服务。
物理主机的网络连接
以下示意图是物理服务器部署 Network , Compute 和 Controller ,注意:
- 建议采用
- Network和Compute分离部署时,网络流量需要通过Network节点进行NAT才能被外部访问到(注意数据流动)
- 可以将Network和Compute部署在一个物理节点上,这样网络流量不会集中到单个Network节点
一个标准的网络设置具备以下一个或多个独立的物理数据中心网络:
网络 | 描述 |
Management network | 提供OpenStack组件之间的内部通讯。 所有位于管理网络的IP地址只能是数据中心范围内可访问。 |
Data network | 提供云计算部署的VM数据通讯。 这个网络的IP地址请求取决于使用的网络插件。 |
External network | 提供一些部署环境下的Internet访问。 任何Internet用户可以访问这个网络中的IP地址。 |
API network | 输出所有的OpenStack API,包括Networking API给tenant。 在这个网络上的IP地址需要被Internet上的任何人访问。 API网络可能类似external网络, 因为它可能创建了一个扩展子网以分配IP地址段。 |
网络方案
以下方案描述两种网络方案以及Open vSwitch plug-in 和 Linux bridging plug-in在这两种网络方案中的实现。
Open vSwitch
- 配置
以下案例使用交换机上的VLAN来隔离tenant网络,这个配置中标记物理网络分为两部分,公共网络称为 physnet1 ,物理网络用于数据的网络称为 physnet2 ,这样在ovs_neutron_plugin.ini
[ovs]
tenant_network_type = vlan
network_vlan_ranges = physnet2:100:110
integration_bridge = br-int
bridge_mappings = physnet2:br-eth1
- 方案一:一个tenant,两个网络,一个路由器
第一个网络方案有两个私有网络( net01 和 net02 ),每个私有网络各有一个子网( net01_subnet01: 192.168.101.0/24, net02_subnet01: 192.168.102.0/24 )。两个私有网络都连接到一个路由器以连接到公共网络(10.64.201.0/24)
在 service
tenant=$(keystone tenant-list | awk '/service/ {print $2}')
neutron router-create router01
neutron net-create --tenant-id $tenant public01 \
--provider:network_type flat \
--provider:physical_network physnet1 \
--router:external=True
neutron subnet-create --tenant-id $tenant --name public01_subnet01 \
--gateway 10.64.201.254 public01 10.64.201.0/24 --disable-dhcp
neutron router-gateway-set router01 public01
在 demo 用户的tenant,创建私有网络 net01 和相应的死亡,然后连接到 router01
tenant=$(keystone tenant-list|awk '/demo/ {print $2}'
neutron net-create --tenant-id $tenant net01 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 101
neutron subnet-create --tenant-id $tenant --name net01_subnet01 net01 192.168.101.0/24
neutron router-interface-add router01 net01_subnet01
类似的,对于 net02
neutron net-create --tenant-id $tenant net02 \
--provider:network_type vlan \
--provider:physical_network physnet2 \
--provider:segmentation_id 102
neutron subnet-create --tenant-id $tenant --name net02_subnet01 net02 192.168.102.0/24
neutron router-interface-add router01 net02_subnet01
- 方案一:Compute 主机配置
虚拟网络设备
有4种不同的虚拟网络设备:TAP设备,veth pair,Linux bridge 和 Open vSwitch bridge。
对于一个以太网数据帧从虚拟机 vm01 的 eth0 传输到物理网络,它必须通过主机的 9 个设备: TAP vnet0,Linux bridge qbrnnn,veth pair (qvbnnn , qvonnn ),Open vSwitch bridge br-int, veth pair ( int-br-eth1 , phy-br-eth1 ),以及,最后通过物理网卡 eth1
TAP设备,例如 vnet0
一个 veth pair 是一个直接连接到虚拟网络接口的设备对。一个发送给veth pair的一端的以太网帧将被veth pair另一端所接收。Networking服务使用veth pair作为虚拟网线来连接不同的虚拟bridge。
一个Linux bridge就类似一个hub:你可以连接多个(物理或虚拟)网络接口设备到Linux bridge。任何以太网帧从连接到bridge的一个接口进入就会传送到所有连接在这个bridge的其他设备。
一个Open vSwitch bridge特性则类似一个虚拟交换机:网络接口设备连接到Open vSwitch bridge的接口,这些接口配置类似一个物理交换机接口,包括VLAN配置。
br-int Open vSwitch bridge是一个集成bridge:所有在Compute主机上的guest虚拟机都连接这个bridge。Networking通过配置 br-int
br-eth1 bridge提供连接到物理网卡 eth1 ,而内部网桥的连接是通过 veth pair ( int-br-eth1 , phy-br-eth1
在这个案例中,net01 和 net02 分别使用 VLAN id 是 1 和 2。然而,物理网络支持VLAN ID是101到110。这里Open vSwitch agent在 br-int 和 br-eth1 上负责配置数据流规则进行VLAN转换。当 br-eth1 在 phy-br-eth1 的接口上接收到一个标记为VLAN ID 1的数据帧,它就将数据帧的VLAN ID修改成101。类似的,当 br-int 从 int-br-eth1
理想情况下,TAP设备 vnet0 将直接连接到集成的bridge br-int 上。但是很不幸,这是不能这么做,因为要实现OpenStack安全组策略。OpenStack使用TAP设备(如 vnet0
Networking使用一个额外的Linux bridge和veth pair来解决这个问题。vnet0不是连接到一个Open vSwitch bridge,而是连接到一个Linux bridge qbrXXX 设备。这个bridge通过(qvbXXX, qvoXXX) veth pair 连接集成bridge br-int
network主机运行 neutron-openvswitch-plugin-agent , neutron-dhcp-agent , neutron-l3-agent 和 neutron-metadata-agent
在network主机上,假设 eth0 连接外部网络, eth1 连接data网络,则 ovs_neutron_plugin.ini
[ovs]
tenant_network_type = vlan
network_vlan_ranges = physnet2:101:110
integration_bridge = br-int
bridge_mappings = physnet1:br-ex,physnet2:br-eth1
以下示意图显示network主机上的网络设备
内部bridge和外部bridge
内部bridge和外部bridge通过一个veth pair ( int-br-ex , phy-br-ex ) 连接,这个案例中使用3层连接来路由从内部网络到外部网络的数据包:在veth pair间没有数据包通过。
在compute主机,使用一个Open vSwitch 内部bridge (br-int) 和一个Open vSwitch bridge连接数据网络(br-eth1),并且两者通过一个veth pair连接,并且 neutron-openvswitch-plugin-agent
在一个附加的Open vSwitch bridge br-ex
在network主机上使用Open vSwitch内部端口。内部端口可以设置一个或多个IP地址给一个Open vSwitch bridge。在上面的案例中,br-int bridge有4个内部接口: tapXXX , qr-YYY , qr-ZZZ 和 tapWWW 。每个内部接口有一个独立的IP地址。在内部接口, qg-VVV 则在 br-ex
默认,Networking DHCP 代理使用一个称为 dnsmasq 的进程提供DHCP服务给guest系统。Networking必须给每个请求DHCP服务的网络创建一个内部接口并附加一个dnsmasq进程到那个接口上。在以上案例中, tapXXX 接口就是在 net01_subnet01 上,而 tapWWW 接口就是在 net02_subnet01
Networkging L3 agent使用Open vSwitch内部接口来实现路由和依靠network主机来路由接口的数据包。在这个案例中, qr-YYY 接口在 net01_subnet01 上并且配置IP 192.168.101.1/24 。 qr-ZZZ 接口在 net02_subnet01 上并且配置IP 192.168.102.1/24 。 qg-VVV
L3 agent使用iptables来实现 floating IP (浮动IP)的网络地址转换(NAT)。
使用主机来实现路由的一个问题是,一个网络子网可能和主机使用的另外一个物理网络重合。例如,如果在eth2上配置的管理网络也使用了 192.168.101.0/24 子网,就会发生路由问题。因为主机不能决定数据包应该发送给 qr-YYY
Networking使用Linux网络命名空间来避免network主机物理和虚拟主机使用的逻辑网络的网络冲突。它也通过不同的逻辑网络不能彼此路由来避免冲突。
Networking通过在network主机创建网络命名空间来避免子网冲突
一个network namespace是其网络堆栈的一个隔离环境。一个network namespace有自己的网络接口,路由,iptables规则。可以将network namespace看成一个chroot jail,只是将网络替代文件系统而已。LXC(Linux containers)使用network namespaces来实现网络虚拟化。
以上案例,有3个network namespace:
- qdhcp-aaa 包含 tapXXX 接口,并且dnsmasq进程监听在那个接口来为 net01_subnet01 提供DHCP服务。这允许 net01_subnet01
- qrouter-bbbb 包含 qr-YYY , qr-ZZZ 和 qg-VVV 接口和相应的路由。这个namespace实现 router01
- qdhcp-cc 包含 tapWWW 接口并且dnsmasq进程监听在那个接口上,提供 net02_subnet01 的DHCP服务。这允许 net02_subnet01
Scenario 2: two tenants, two networks, two routers
太长了,待续
Neutron LBaaS(负载均衡)
在 Neutron LBaaS 中列出了一些可以参考的负载均衡管理模块的一些资源信息。其中 F5 BigIP Driver 提供了有关F5负载均衡的开源项目的参考(虽然已经很久没有更新),其中LBaaS proposal 的架构可以参考。