OpenStack网络 - 使用vlan模式来剖析openstack网络相关概念及原理
OpenStack网络 - 使用vlan模式来剖析openstack网络相关概念及原理
OpenStack网络
OpenStack网络设置比较复杂，阅读了一些文档，主要是采用两种网络 flat network 和 vlan manager
综合一些文档和自己的理解，整理本文档
Dnsmasq和IP管理
在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
OpenStack网络服务，代码名称是Netron(英文解释”中子”)，提供了一个API用于定义网络连接和在云计算中定位。这个网络服务使操作者结合不同的网络技术来
加强云计算网络。同时也提供了API来配置和管理一系列网络服务，从三层转发和NAT到负载均衡，边际防火墙，以及IPSEC VPN。
网络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，来提供类似的特性。
插件可以具有不同的硬件要求的特性，性能，伸缩性或者操作工具。由于网络支持大量的插件，一个云计算管理员有大量的选项来决定部署的正确网络技术。
在OpenStack Havana发行版中，OpenStack网络提供了 Modular Layer 2(ML2) plug-in (模块化二层网络插件) 可以并行地使用在实际数据中心常用的多
种二层网络技术。当前支持Open vSwitch，Linux Bridge 和 Hypber-v L2 代理。这个ML2框架简化了支持新的二层网络技术并且比monolithic插件减轻了加入和
维护二层网络技术的影响。
网络架构
OpenStack Networking是一个独立的服务，类似其他的OpenStack服务，如Coumpute, Image service, Identity service 或 Dashboard。
OpenStack Networking服务使用 neutron-server 服务进程来输出网络API和将用户请求传递给已配置的网络插件进一步处理。典型的，插件会要求能够访问
数据库以持久化存储（类似其他OpenStack服务）。如果部署一个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 服务使用Networking API进行
通讯以插入每个VM的虚拟网卡加入到网络。
- 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 创建共享的路由器，定义公共网络，并且设置为缺省网关:
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 路由器。配置它使用物理交换机的VLAN ID 101:
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 使用VLAN ID 102用于物理交换机:
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 主机配置
TAP设备，例如 vnet0 就是KVM或者Xen这样的hypervisor实现的虚拟网络接口卡（通常称为VIF或者vNIC）。一个以太网帧发送给TAP设备由guest操作系统接收。
一个 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 接口来实现隔离这些guest
操作系统。
br-eth1 bridge提供连接到物理网卡 eth1 ，而内部网桥的连接是通过 veth pair ( int-br-eth1 , phy-br-eth1 ) 实现的。
有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 。
在这个案例中，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 的相应接口接收到标记为VLAN ID 101的数据帧，就反过来将VLAN ID修改成1。
理想情况下，TAP设备 vnet0 将直接连接到集成的bridge br-int 上。但是很不幸，这是不能这么做，因为要实现OpenStack安全组策略。OpenStack使用TAP设备
（如 vnet0 ）上的iptables规则来实现安全组策略，并且Open vSwitch不能兼容直接连接到Open vSwitch接口上的TAP设备的iptables规则。
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主机上的网络设备
在compute主机，使用一个Open vSwitch 内部bridge (br-int) 和一个Open vSwitch bridge连接数据网络(br-eth1)，并且两者通过一个veth pair连接，并且 neutron-open
vswitch-plugin-agent 配置在两个交换机的接口上做VLAN转换。
在一个附加的Open vSwitch bridge br-ex 连接到物理接口联通外部网络，这个物理接口是eth0。
在network主机上使用Open vSwitch内部端口。内部端口可以设置一个或多个IP地址给一个Open vSwitch bridge。在上面的案例中，br-int bridge有4个内部接口:
tapXXX , qr-YYY , qr-ZZZ 和 tapWWW 。每个内部接口有一个独立的IP地址。在内部接口， qg-VVV 则在 br-ex bridge 上。
默认，Networking DHCP 代理使用一个称为 dnsmasq 的进程提供DHCP服务给guest系统。Networking必须给每个请求DHCP服务的网络创建一个内部接口并附加一个
dnsmasq进程到那个接口上。
在以上案例中， tapXXX 接口就是在 net01_subnet01 上，而 tapWWW 接口就是在 net02_subnet01 上。
内部bridge和外部bridge通过一个veth pair ( int-br-ex , phy-br-ex ) 连接，这个案例中使用3层连接
来路由从内部网络到外部网络的数据包：在veth pair间没有数据包通过。
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 接口配置IP 10.64.201.254/24 。由于对于network主机的操作系统每个接口都是可见的，所以network主机可以路由这些包括，只要系统管理员激活了 IP forwarding 。
L3 agent使用iptables来实现 floating IP （浮动IP）的网络地址转换（NAT）。
使用主机来实现路由的一个问题是，一个网络子网可能和主机使用的另外一个物理网络重合。例如，如果在eth2上配置的管理网络也使用了 192.168.101.0/24 子网，
就会发生路由问题。因为主机不能决定数据包应该发送给 qr-YYY 还是 eth2。如果最终用户被允许创建自己的逻辑网络和子网，你必须设计系统避免冲突。
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 和任何其他位于network host的子网IP重合
- qrouter-bbbb 包含 qr-YYY , qr-ZZZ 和 qg-VVV 接口和相应的路由。这个namespace实现 router01
- qdhcp-cc 包含 tapWWW 接口并且dnsmasq进程监听在那个接口上，提供 net02_subnet01 的DHCP服务。这允许 net02_subnet01 和任何其他位于network host的子网IP重合
请关注原文出处 ： openstack网络