OpenStack Atlanta Summit 视频解析之Neutron架构
近日,Mark McClain在OpenStack summit发表演讲,详细介绍了Neutron的架构,包括创建Neutron项目的初衷,Neutron架构设计目标,Neutron基本部署架构及Neutron各组件的详细介绍,包括neutron-server, L2 agent, DHCP agent, L3 agent, metadata agent, LBaaS, VPNaaS等。Mark还提到了一些Juno中会加入的新功能。演讲内容比较适合Neutron开发人员,或希望对Neutron有进一步了解的相关技术人员。 Mark McClain Neutron项目Core developer, Havana/Grizzly/IceHouse PTL, TC member,Yahoo 架构师。(https://www.linkedin.com/in/markmcclain) 演讲视频请点击此处 以下是对Mark演讲内容的一个回顾。 Neutron背景介绍为什么创建Neutron项目? nova-network只提供了一组静态的网络拓扑,所以创建Neutron的动机之一就是提供创建丰富的拓扑结构的能力,包括多层网络,以及重建现实世界的拓扑结构。 nova-network只提供了静态的部署选项,只有VLAN可以使用,而VxLAN, GRE等技术也是用户所需要的。 网络应提供易于扩展的能力,方便各厂商进行支持。 nova-network中提供的唯一的高级服务是cloudpipe,为tenant提供VPN服务。Neutron提供LBaaS,VPNaaS,FWaaS。 用户眼中的OpenStack对于OpenStack用户来说,看到的是一组API,计算API,网络API,存储API等,这些API背后的具体技术对用户来说是不可只的,如KVM,ML2Plugin,Ceph等。 Neutron为用户提供了一组抽象的资源(Virtual Interface, Virtual Port, L2 Virtual Network, Virtual Subnet),这些资源可以对应到物理世界中的实体,如Virtual Interface可以对应NIC,Virtual Port可以对应交换机的端口等。 Neutron架构介绍了以上背景知识,Mark开始详细介绍Neutron架构。 设计目标 Neutron希望会End User提供一组一致性的API。 对于small core,用户可以期待特定的一组资源,而且各厂商比较容易共享社区并开发自己的插件。 插件式开放架构 插件式开放架构不会限制厂商的部署方式,网络设计,不会限制社区进行创新。 可扩展性 可扩展性是创新的驱动力。 OpenStack总体架构可以点击此链接查看大图:http://docs.openstack.org/admin-guide-cloud/content/figures/2/figures/openstack-arch-havana-logical-v1.jpg 其中最右侧是Neutron的架构。 Neutron基本部署架构下图展示了Neutron基本的部署架构及包含的组件。
提供REST API服务,后端使用关系数据库。 neutron-server使用Message Queue与其他Neutron agents进行交换消息,但是这个Message Queue不会用于neutron-server与其他OpenStack组件如nova进行交换消息。 负责连接端口(ports)和设备,使他们处于共享的广播域(broadcast domain)。通常运行在Hypervisor上。 用于配置虚机主机的网络(某些情况可能不需要DHCP agent,例如使用config drive来配置虚拟主机的情况)。 负责连接tenant网络到数据中心,或连接到Internet。在真实的部署环境中,一般都需要多个L3 Agent同时运行。 Neutron各组件详细介绍neutron-server组件由REST API Service,RPC SErvice,Plugin几部分组成。 neutron-server本身是WSGi应用,提供REST API服务,使用9696端口,对用户暴露基本的逻辑资源,如network, subnet, port等,同时负责HTTP request和response的序列化。 使用AMQP, 基于oslo messaging模块,用于agents之间的双向通信 使用Python编写。同时只能使用一个plugin,plugin必须实现V2 APIs,可以提供数据库访问或者扩展支持。例如ML2 Plugin。 Plugin提供了扩展机制,这种机制可以为REST API增加更多的逻辑资源,如router,security group等。Pplugin的扩展点由neutron-server在启动的时候发现和加载。常见的扩展点如Binding,DHCP,L3,Provider,Quota, Security,其他的扩展点如Allowed Addresses, Extra Routes,Metering等。 Monolithic Plugin的特征是实现所有的Core资源。Neutron中包含两种类型Monolithic Plugin,一种是Proxy Plugin,将功能代理到其他实际管理data plane的拓扑的服务器,例如BigSwitch Plugin,另一种是Direct Control Plugin,例如Linux Bridge或Open vSwitch Plugin,实际操作虚机设备。 目前Neutron已经默认使用ML2 Plugin,ML2 Plugin使用户能够同时利用数据中心中各种L2网络技术。ML2 Plugin提供两种Drivers,一种是Typer Driver, 维护网络状态,验证provider network和分配tenant网络,目前,支持的网络类型包括local, float, vlan, gre, vxlan。另一种是Mechanism Driver, 负责使用Type Driver提供的信息,实现具体的网络机制,例如通过Open vSwitch实现VLAN网络。 L2 Agent通常运行在Hypervisor,与neutron-server通过RPC通信,监听并通知设备的变化,创建新的设备来确保网络segment的正确性,应用security groups规则等。例如,OVS Agent,使用Open vSwitch来实现VLAN, GRE,VxLAN来实现网络的隔离。 在介绍L3 Agent之前,Mark介绍了Linux network namespace,这时实现L3 agent的技术基础,特别是overlapping ip,必须依赖namespace来实现。每一个namespace是一个独立的IP Stack,namespace之间通过虚拟设备之间的link来实现。关于linux network namespace的信息可以参照这篇文章:http://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/ L3 Agent运行在网络结点,负责连接tenant网络到数据中心,或连接到Internet。如上所述使用namespaces,通过独立的IP Stacks,启用Forward,静态路由和metadata proxy来实现。 - Configuration Agents: DHCP
DHCP Agent用于配置虚拟主机的网络。基于RPC通知实现(来自neutron-server的notifications),使用dnsmasq实现IP地址分配及域名服务器的设置,通过namespace实现不同网络之间DHCP服务的隔离,支持多个DHCP Agent同时运行以支持Active-Active的HA。 - Configuration Agents: Metadata Proxy
将metadata请求代理到Nova。 除此之外,Mark亦简要介绍了LBaaS,VPNaaS,FWaaS等Neutron的Service Plugin组件。也提到Juno当中正在开发的一个新功能:在创建虚机时,Nova等待Neutron创建虚机设备,设备创建成功后通知nova继续虚机的部署。 总体来说,Mark的介绍非常详尽,不过需要具有一定的网络,OpenStack,Linux背景才能够完全吸收,尽管如此,可以从这个介绍入手去进一步熟悉Neutron的架构细节。 |