参考:
① 《OpenStack官方文档》
② 《OpenStack高可用架构与原理》
③ 《Neutron网络架构》
不论是传统数据中心还是云计算数据中心,网络都是不可或缺的核心资源。Neutron便是OpenStack云计算中的网络服务项目,其源自早期的Nova-network网络组件。
Nova-network从Nova项目中独立出来之后,社区成立了针对网络功能虚拟化的Quantum项目。
但由于商标侵权的原因,在Havana版本后,Quantum 项目更名为现在的Neutron项目。
要配置丰富的网络拓扑,您可以创建和配置网络和子网,并指示其他 OpenStack 服务(如计算)将虚拟设备附加到这些网络上的端口。OpenStack Compute是OpenStack Networking的杰出消费者,为其实例提供连接。特别是,OpenStack网络支持每个项目具有多个专用网络,并使项目能够选择自己的IP寻址方案,即使这些IP地址与其他项目使用的IP地址重叠。有两种类型的网络,项目和提供商网络。作为网络创建过程的一部分,可以在项目之间共享任何这些类型的网络。
Neutron是OpenStack的核心项目之一,也是OpenStack核心项目中成熟相对较晚的项目,但是这完全不妨碍Neutron项目在社区的热度,在最近发行的OpenStack版本中,Neutron是新增功能和问题修复最多的核心项目。
随着OpenStack Mtiaka版本的发行,Neutron 在解决网络高可用性和集群扩展带来的网络性能方面都取得了实质性进展,这为Neutron真正实现大规模生产环境高可用集群网络提供了夯实的基础,也是Neutron迈向成熟项目的标志。
接下来将对Neutron项目进行架构原理的讲解,并重点阐述实现Neutron所支持的各种网络类型以及Neutron网络服务的各种高可用方案。
OpenStack的网络服务由Neutron项目提供,Neutron 允许OpenStack用户创建和管理网络对象,如网络、子网、端口和路由等,而这些网络对象正是其他OpenStack服务正常运行所需的网络资源。Neutron项目中实现的各种插件使得用户可以选择不同的网络设备和软件,并为OpenStack的网络架构和部署提供极大的灵活性。此外,Neutron 提供了APIServer以供用户进行云计算网络的定义和配置,而Neutron灵活多样的插件使得用户可以借助各种网络技术来增强自己的云计算网络能力。Neutron还提供了用以配置、管理各种网络服务的API,如L3转发、NAT、负载均衡、防火墙和VPN等高级网络服务。在正式部署使用Neutron网络之前,应先掌握与Neutron相关的各种网络概念,这些概念是后续了解和分析Neutron网络功能的基础。
APIServer是Neutron的控制器,用户对网络资源的请求全部先交由APIServer处理。API Server接到用户的请求后,会调用后端插件进行具体的任务实现。Neutron 的APIServer不仅实现了对L2网络和IP地址管理( IPAM, IP Address Managment)的支持,还实现了对L3扩展和网关的支持,其中L3主要用于对L2网络进行路由,而网关主要用于外网访问。Neutron 包含了很多网络插件,这些插件不仅实现了各种开源虚拟网络技术,还实现了对各种商业网络设备和技术的支持,如路由器、物理交换机、虚拟交换机和软件定义网络控制器等。随着OpenStack生态圈和影响力的扩大,几乎全部的网络设备厂商都宣称支持OpenStack,因此Neutron的后端网络插件和代理也在不断增加,而API Server所提供的网络功能也在不断丰富。
Neutron提供了灵活多样的网络插件和代理供用户选用,以便用户可以部署适合自身的云环境网络。插件与代理的主要功能在于实现由APIServer转发的网络资源请求,如网络端口的插拔、路由增删、网络和子网创建以及提供IP地址等。此外,网络插件和代理的选取依赖于用户特定云环境下网络设备供应商的选用和所采用的网络实现技术。Neutron项目默认自带多个虚拟和物理网络设备插件与代理,如思科的虚拟和物理交换机、NEC的Openflow产品、OpenvSwitch、Linux bridging和VMware NSX产品等。需要指出的是,在早期的OpenStack网络部署中,不能同时使用多种网络插件,只能多中选一,因此在OpenStack网络部署中,最常见的代理和插件组合便是L3、DHCP代理和某种具体的网络插件。L3、DHCP代理和Open vSwitch插件方案是当时用户选用较多的插件代理组合方案。而为了实现对各种网络插件的支持,并可以在不同的节点上使用不同的插件实现网络功能,社区开发了ML2核心插件用以对各式各样的网络插件进行整合。
为了创建丰富的网络拓扑,Neutron 提供了两种网络类型,即租户网络( ProjectNetwork)和供应商网络( Provider Network)。在租户网络中,每个租户可以创建多个私有网络,租户可以自定义私有网络的IP地址范围,此外,不同的租户可以同时使用相同的IP地址或地址段。与租户网络不同,供应商网络由云管理员创建,并且必须与现有的物理网络匹配。
为了实现不同租户网络互相隔离,Neutron提供了几种不同的网络拓扑与隔离技术,Flat网络便是其中之一。在Flat网络中,不同计算节点上的全部实例接入同一个大二层网络内,全部实例共享此网络,不存在VLAN标记或其他网络隔离技术。接人Flat网络的全部实例通过数据中心核心路由接入Internet,相对于其他的网络类型,Flat 网络是最简单的网络类型。在Neutron的网络实现中,可以同时部署多个隔离的Flat网络,但是每个Flat网络都要独占一个物理网卡,这意味着要通过Flat网络来实现多租户的隔离,尤其是在公有云环境中,这种方法似乎不太现实。
VLAN网络允许用户使用外部物理网络中的VLANID创建多个租户或供应商网络。VLAN网络通过VLAN ID进行二层网络的隔离,相同VLAN ID内部的实例可以实现自由通信,而不同VLAN之间的实例通信则需要经过三层路由的转发。由于VLAN网络可以实现灵活多样的网络划分与隔离,故VLAN网络是生产环境中使用最为普遍的网络。而在云计算环境中,VLAN网络主要用于私有云环境中,对于大型公有云数据中心,在租户增加的情况下,VLAN ID的限制是VLAN网络的一-大弊端。
GRE和VxLAN是一种网络封装协议,基于这类封装协议可以创建重叠(overlay) 网络以实现和控制不同计算节点实例之间的通信。GRE和VxLAN的主要区别在于GRE网络通过IP包进行数据传输,而VxLAN通过UDP包进行数据传输,GRE或VxLAN数据包在流出节点之前会被打上相应的GRE或VxLAN网络ID (Segmentation ID),而在进入节点后对应的ID会被剥离,之后再进人节点内部的虚拟网络进行数据转发。GRE和VxLAN网络中的数据流要进人外部网络,必须配有路由器,而且要将租户网络与外部网络互连,路由器也是必备的。在GRE和VxLAN网络中,路由器的主要作用在于通过实例浮动IP提供外部网络对实例的直接访问。在很多公有云环境中,GRE和VxLAN网络被广泛使用,因此用户在公有云上创建实例后,通常需要向供应商购买或申请通信运营商IP和一个虛拟路由器,并将运营商IP作为实例浮动IP,才能通过Internet访问自己的公有云实例。路由器提供了使用浮动 IP 地址直接从外部网络连接到实例的功能。
端口( Port)在OpenStack网络中是一种虚拟接口设备,用于模拟物理网络接口。
在Neutron中,端口是网络设备连接到某个虚拟网络的接入点,如虚拟机的NIC只能通过端口接人虚拟网络,端口还描述与网络相关的配置,如配置到端口上的MAC和IP。Neutron网络中的端口网络和子网如图1-1所示。
子网(Subnet)代表的是一个IP段和相关的配置状态。子网IP和网络配置信息通常被 认为是网络服务为租户网络和供应商网络提供的原生IPAM。当某个网络上有新的端口被创建时,网络服务便会使用子网提供的IP段为新端口分配IP。
一般来说,终端用户可以在没有任何约束的情况下使用有效的IP创建子网,不过有时需要为admin或租户用户预先定义可用IP池,并在创建子网时从此IP池中自动分配地址。 通过子网池,便可要求每个创建的子网必须在预定义的子网池中,从而约束子网所能使用 的IP。
此外,子网池的使用还可以避免IP被重复使用和不同子网使用重叠的IP。
在Neutron中,路由(Router)是个用以在不同网络中进行数据包转发的逻辑组件,即 路由是个虚拟设备,在特定插件支持下,路由还提供了 L3和NAT功能,以使得外部网 络(不一定是Internet)与租户私有网络之间实现相互通信。在Neutron中,虚拟路由通常 位于网络节点上,而租户私有网络要实现与外部Provider物理网络(或Public网络)的通 信,则必须经过虚拟路由。
Neutron网络节点虚拟路由连接租户网络和外部网络的示意如图1-2所示。
路由通常包含内部接口和外部接口,如图1-2所示,位于租户网络中的主机
Host_A和主机Host_B通过内部接口接人路由,并通过路由公共网关(外部接口)访问外部Provider网络和Public中的主机Host_C。但是Host_C要访问租户私网中的Host_A和 Host_B主机,则必须通过路由DNAT功能才能实现,因此需要为Host_A和Host_B主机配 置Floating IP。此外,在Neutron网络高可用配置中,L3的高可用配置是整个网络髙可用的重点和难点.
安全组(Security Group)是虚拟防火墙的规则集合,这些防火墙规则对外部访问实例和实例访问外部的数据包实现了端口级别(Port Level)的控制。
安全组使用默认拒绝策略 (Default Deny Policy),其仅包含允许特定数据流通过的规则,每个端口都可以通过附加的 形式添加到一个或多个安全组中,防火墙驱动会自动将安全组规则转换为底层的数据包过 滤技术,如iptables。
在Neutron中,每个项目(Project)都包含一个名为default的默认安全组,default安全组允许实例对外的全部访问,但是拒绝全部外网对实例的访问。如果在创建实例时未指定安全组,则Neutron会自动使用默认安全组default同样,如果创建端口时没有指定安全组,则default安全组也会被默认用到此端口。要访问特定实例中某个端口的应用程序,必须在该实例的安全组中开通应用程序要访问的端口。
在云计算网络中,一个租户可以有多个租户子网,租户子网通常称为内部网络(简称内网),不同内网中通常会接人不同用途的实例。如用于开发测试环境的实例和用于生产环境 的实例通常会分开接入到不同的租户内网中,而租户不同的子网之间因数据访问的需求可能要进行彼此通信,租户内部子网之间的数据访问通常称为东西向通信。
此外,位于租户 内网中的应用要对外提供服务,则必须实现外部网络与租户网络彼此之间的通信,这包括了外网访问内网和内网访问外网两种方式,通常内外网之间的访问称为南北向通信。网络东西向通信和南北向通信的示意图如图1-3所示。
在图1-3中,子网A与子网B之间的通信称为网络的东西流向,外部网络与租户网络之间的通信称为网络的南北向流量。
由于子网A和子网B属于不同的子网,因此网络东西向通信需要Router转发,同样,外部网络与租户网络之间的南北向通信也必须经过Router转发才能实现。
在云计算网络环境中,Router的东西向转发实现了内部子网之间的通信, 而南北向转发实现了内部与外部网络之间的通信。
源地址转换(Source Network Address Transfer, SNAT)主要用于控制内网对外网的 访问,SNAT通常只需一个外部网关,而无须属于外部网络的浮动IP (Floating IP),即可实现内网全部实例对外网的访问。在内网存在大量实例的情况下,相对DNAT,SNAT可以节约大量外网IP。
在SNAT中,尽管内部私网可以访问外网,但是外网却不能访问内部私网,因而SNAT具有很好的安全防护机制。
很多企业为了防止外网人侵都会使用SNAT来实现内网对Internet的访问,而在OpenStack网络中,SNAT主要用来实现租户虚拟机实例对外网的访问。SNAT的工作原理就是,内部私网TCP/IP数据包在进人路由后,数据包中的私网源IP会被路由上的外网网关IP替换,这是源地址转换的核心步骤,即将数据包中源IP转换为外网网关地址。这里再次指出,在私有或者公有云中,虚拟机要访问外网,并不意味着必须为虚拟机分配Floating IP,而只需创建路由并为路由设置外网网关,将内网接人路由即可实现内网实例对外网的访问。由于SNAT是在数据包经过路由之后再进行的IP替换,因此SNAT又称POST-Routing, SNAT的地址转换过程如图1-4所示。
目的地址转换(Destination Network Address Transfer, DNAT)主要用于外网对内网的访问,由于外网要访问位于内网中的某个特定实例,因此必须向位于外网中的访问客户端提供具体的目的IP,而这个实例目的IP通常称为Floating IP。
Floating IP并不属于内网地址,而是外网地址。Floating IP与内网实例地址是一一绑定的关系,它们之间的地址转换便 是DNAT。一旦为实例绑定Floating IP,位于外网中的访问客户端便可通过该Floating IP直接访问内网中的实例。
目前很多公有云供应商都是通过DNAT的形式,利用电信运行商提供的公网IP段创建一个Floating IP,并将其绑定到租户的特定虚拟机上,从而允许租户基于Internet访问位于供应商数据中心的虚拟机。DNAT的工作原理就是,在外网数据包进人路由之前,将数据包中的目的地址(属于外网)替换为内部私网地址(租户内网网关地址),这也是目的地址转换的核心步骤。
经过DNAT之后,数据包目的地址被替换并进人路由,路由便将数据包转发到对应的虚拟机。DNAT过程发生在进入路由之前,即先将外网目的IP替换成为内网私有IP再进入路由进行转发(地址替换发生在路由之前),因此,DNAT又称PRE-Routing。DNAT地址转换过程如图1-5所示。
在Linux系统中,网络命名空间(Network Namespace)就是一个虚拟的网络设备,网络命名空间有独立的路由表、iptables策略和接口设备等,网络命名空间彼此之间完全隔离。
假设系统中有ethO和ethl两个网卡设备,且ethO属于命名空间namespace 1,而ethl属于命名空间namespace2,则ethl和eth2就类似于两个独立网络设备上的接口,彼此相互独立,而且只有进人各自的命名空间后,才能够对命名空间中的接口设备进行配置更改与查看。
因此,如果ethO和ethl加人各自的命名空间后,在Linux系统中,针对全局系统的网络配置命令ifconfig是不能看到这两个网卡设备的相关配置信息的,必须进人各自的命名空间使用此命令才能看到相关信息。
在Linux中,使用命令ip netns可以查看系统中的全部网络命名空间,要配置或者查看命名空间中的设备,则需要进人特定命名空间并在命名空间中执行相应命令。例如,当前系统中有一个路由命名空间qrouter-xxx,想要查看该命名空间中的接口和IP配置情况,可以执行命令:
ip netns exec qrouter-xxx ip addr show
其中,ip netns exec qrouter-xxx指明了运行ip addr show命令的命名空间。命名空间是Linux系统中使用非常广泛的技术,尤其是在网络技术领域,命名空间具有极佳的网络设备模拟能力和配置隔离性。因此在Neutron项目中,网络命名空间被大量使用,例如不同的 租户网络可以使用重叠的IP地址,就是因为不同租户具有独立的路由命名空间。
在OpenStack的模块架构中,网络是个代号为Neutron的独立社区项目,同Compute、Image和Identity等项目一样,Neutron的服务部署也需要跨越多个节点。
在OpenStack中, 网络服务使用Neutron-server进程提供服务API接口,用户通过Neutron-server提供的API可以进行网络插件的管理配置。
通常为了实现网络配置数据的永久性存储,网络插件需要访问OpenStack的中心数据库。
Neutron项目的架构如图1-6所示,其中Neutron-server不仅向云用户提供网络服务API,还向计算服务Nova和控制面板服务Horizon提供网络资源请求API,同时Neutron-server与Neutron插件需要访问Keystone服务以进行身份验证,而为了实现彼此交互,Neutron的服务代理与插件需要访问消息队列服务。
Neutron是一个由分布式组件构成的网络服务,其内部组件包括Neutron Server、插件代理(Plugin Agent). DHCP代理、L3代理和计量代理(Metering Agent)等其他SDN服务、关于Neutron服务组件的功能和作用描述如下。
Neutron内部各个组件代理与Neutron Server和Plugins之间以RPC的形式进行通信,而SDN Service以REST APIs的形式访问Neutron Server和相应的插件代理。Neutron内部组件之间的通信数据流和组件逻辑架构如图1-7所示