SDN的横向扩展对OpenStack Neutron的影响
Neutron管理着运行于Openstack之上的虚拟化网络,并且为开发高级云服务创建了一系列松耦合及其相关的项目,如果把Neutron作为软件定义网络(SDN)的一个可扩展性应用是非常方便使用的。
每项服务属于一个单独的项目,这些项目由社区驱动,或者来自很多供应商和公司的贡献。重要的是,OpenStack的Kilo版本包含了12个集成项目:
- Nova(计算):为云用户按需提供虚拟服务器/虚拟机。
- Neutron(网络):将网络作为一项服务提供(虚拟网络服务)。
- Swift(目标存储):允许API可访问的数据镜像、文件和文档的存储和调回。
- Cinder(块存储):为用户虚拟机提供永久块存储。
- Glance(映像):为计算节点提供一系列的硬盘镜像,这些镜像被虚拟机使用,
- Horizon(仪表板):为管理员或者租户(用户)管理Openstack提供基于web的图形化用户界面(GUI)。
- Keystone(验证):存储OpenStack服务认证和授权信息。
- Ceilometer(遥测):监控和测量Openstack云使用信息,为计费、基准测试和统计提供依据。
- Heat(调度):通过合适的API调用为管理云应用提供调度服务。
- Ironic(Baremetal配置):旨在配置裸机代替虚拟机,从Nova的Baremetal驱动分支出来。
- Sahara(大数据作为服务):该项目提供一个简单的方法来配置一个运行于OpenStack之上以数据为目的的应用集群(Hadoop或者Spark)。
- Trove(数据库作为服务):该项目旨在提供云数据库服务,配置相关以及无关的数据库引擎功能。
虚拟网络是由租户或者管理员创建,为OpenStack计算所管理的虚拟机之间提供网络功能。Neutron是一项网络管理服务,提供一系列可扩展的API用来创建和管理虚拟网络。
在Neutron之前,OpenStack有一个简单、扁平的网络环境,不支持三层或者防火墙。这种网络服务内嵌于Nova服务器中,使得网络发生改变时很难适应。
Neutron的引入是用来将网络作为一项单独的服务,为网络抽象提供不同的解决方案,Neutron服务器提供抽象定义和管理,网络抽象的具体实施是由组件来实现。这种支持多租户的基于组件的架构,被认为是与技术无关和模块化的。我们需要注意Neutron是一项独立的服务,也就是说,Neutron可以运行为一项自主的服务,暴露API给不同的供应商,提供解决方案或者其他合适的扩展。
Neutron所暴露的API分类与其子分类下支持的操作总结如下。那些操作可以缩写为CRUD,即创建(C)、阅读(R)、更新(U)和删除(D)。核心API涵盖了基本和必须的网络操作,而扩展和属性API的功能是用来构建多功能虚拟网络。
核心API的操作
- 网络(CRUD)
- 子网(CRUD)
- 端口(CRUD)
扩展和属性API的操作
- 配额(RUD)
- 网络提供商可扩展属性(CRUD)
- 多个网络提供商可扩展(CR)
- 绑定扩展属性的端口(CRU)
- 安全组与规则(CRD)
- 三层网络功能(CRUD)
- 计费标签和规则(CRD)
- 负载均衡作为服务(LBaaS)(CRUD)
Neutron架构
软件定义网络技术的发展与成熟,基于SDN 技术的网络虚拟化发展,使得网络虚拟化可以不再基于物理网络设备实现,使网络虚拟化成为云计算网络技术的核心之一,越来越多的厂商关注网络虚拟化,并纷纷发布他们关于网络虚拟化方面的方案。
图一描述了OpenStack Neutron架构,由以下组件构成:
Neutron服务器
python后台服务是OpenStack网络的主要进程,一般运行于控制器节点(openstack部署中的一个术语)。它暴露API来加强网络模型,并且传递请求给netron组件。
插件
插件可以是核心组件也可以是一项服务。核心插件实现“核心”的Neutron API——二层网络和IP地址管理。服务插件提供“额外”的服务,例如三层路由、负载均衡、VPN、防火墙和计费。核心组件也可以通过相关的API扩展提供这些网络服务。简而言之,组件运行在控制节点上,并且调用网络API,这些API会同Neutron服务器、数据库和代理进行交互。
图一:OpenStack Neutron 架构
插件代理
插件代理指定正在被使用的Neutron插件。他们运行于计算节点之上,并且会同Neutron插件进行交互来管理虚拟交换机。这些代理在许多部署中是可选的,而且在每个虚拟机管理程序上可执行本地虚拟交换机配置。
消息队列
OpenStack组件,包括Neutron,使用高级消息队列协议(AMQP)进行内部通信。AMQP代理,RabbitMQ,位于 Neutron的任何两个内部组件之间,允许它们通过松耦合的方式交互,例如,Neutron组件使用远程过程调用协议(RPC)与另外一个组件通信。
数据库
几乎所有组件都需要用数据库来维护一个持续的网络模型;因此,数据库的语法是由已配置的核心插件和服务插件来定义。
DHCP代理
这个代理是Neutron的一部分,给租户网络提供DHCP服务。它维护所需的DHCP配置,且在所有插件中,DHCP代理是相同的(它维护所有组件中相同的DHCP配置)。
三层代理
三层代理负责提供三层和NAT转发功能,目的是为租户网络中的虚拟机提供外网接入。
二层模块化核心插件
二层模块化(ML2)是Neutron的核心插件。ML2的引入(从OpenStack的Havana版本开始)是为了替代原有的统一插件 (如,Open vSwitch和Linux桥接-它们仅仅是插件,而不是代理)消除冗余代码,降低开发和维护成本。根据ML2作者所定义的,模块化二层组件(ML2)组件是一个允许OpenStack Neutron同时利用二层网络多样性技术的架构,该二层网络技术来源于实际的复杂数据中心。
图二:ML2 组件结构
ML2通过驱动模型实现模块化。如图二所示,它包含了两类驱动:类型驱动和机制驱动。类型驱动(比如flat、虚拟局域网、GRE和VXLAN等) 定义了一个特殊的二层类型,每个可用网络类型由对应的类型驱动管理。该驱动维护了类型驱动具体的状态信息,实现了租户网络之间的隔离,这种隔离是由供应商网络验证过的。
另一方面,机制驱动是由厂商指定的(比如说OVS,还有来自ODL、Cisco、NEC等厂家的驱动),基于功能性的类型驱动——支持创建、更新和删除网络、子网和端口资源。我们应该注意到供应商有可能执行一整套新的类似于ML2的组件,或者仅仅实现一个机制驱动组件。Salvatore Orlando和Armando Miliaccio的对话使这个决定更容易实现。
OpenStack和SDN控制器:伟大的蓝图
软件定义网络的引入不仅是为了克服Neutron的缺陷,而且是为了提供支持多网络虚拟化技术(一个集中控制平面创建分隔的租户虚拟网络)和方法(来自F5 网络的Christian Koenning所说的软件定义网络和OpenStack)。有了SDN的集成,Neutron极有可能去支持大容量、高密度和多租户云环境的动态特性。
OpenStack Neutron连同它的插件架构,提供集成SDN控制器到OpenStack的能力。这种SDN控制器使用插件集成Neutron技术提供集中式管理,并且促进OpenStack网络利用API实现可编程性。
SDN控制器,诸如OpenDaylight、Ryu和Floodlight,运用对应的机制驱动,使用指定的插件或者使用ML2插件,实现Neutron和SDN控制器之间的通信。OpenStack与SDN控制器的融合,如下图三所示。
在关于SDN控制器的文章里,网络操作系统如Open Daylight、RYU,或者其他网络操作系统,负责提供一个完整的网络(拓扑)视图,也负责管理(应用、实行和保证)对网络必要的更新,通过转换需求去配置(和监控)网络元素(物理的和虚拟的)。典型地,这些对下层网络(和网络元素)的更新来自运行于SDN控制器上的网络应用,SDN控制器通过北向 API调用。
随着OpenStack Neutron和SDN控制器的集成,对于网络和网络节点的改变也由OpenStack用户所触发,被转换成Neutron API,由Neutron插件和对应的SDN控制器上的代理来处理。例如,OpenDaylight通过Neutron网络节点上的ML2插件使用北向通信的RestAPI与Neutron交互。当一个OpenStack用户执行任何与网络有关的操作时(创建/更新/删除/阅读 关于网络、子网和端口资源),典型流程如下:
1. 在OpenStack面板(Horizon)的用户操作将会被转换成对应的网络API,并且发往Neutron服务器。
2. Neutron服务器收到请求,然后传递请求给配置好的插件(假设ML2配置了一个ODL机制驱动和一个VXLAN类型驱动)。
3. Neutron服务器/插件将会对DB做相应的改变。
4. 插件将从SDN控制器(假设是一个ODL)调用对应的RestAPI。
5. ODL,一旦收到请求,将使用任意的南向插件/协议,例如OpenFlow,OVSDB或者OF-Config,对网络节点执行必要的改变。
图三:OpenStack和SDN控制器
在SDN控制器和OpenStack之间仍然存在不同的集成选项,例如,a)SDN控制器作为唯一的控制实体管理网络,能完全消除计算节点上 Neutron服务器与代理之间的RPC通信,或者 b)SDN控制器仅仅管理物理交换机,虚拟交换机由Neutron服务器直接管理。
引人深思的是:SDN控制器部署选项与OpenStack的集成
SDN控制器部署可以采取不同的形式,如下面三个表格的总结,部署不同排列组合的下列选项是有可能的,例如,我们可以让非虚拟化的、集成的、单一/冗余的控制器在一个数据中心管理数据中心所有的网络节点。
SDN控制器虚拟化的好处是,更好的可扩展性——在现有的SDN控制器动态添加更多的资源(比如存储资源)。在一个虚拟化分布式部署中——SDN控制器由一系列协同工作的虚拟机实现-可以添加额外的虚拟机实例来增加工作负载。
考虑到SDN控制器被虚拟化和集成化/分布式的场景,SDN网络元素从虚拟到物理实体的变化。此外,数据中心环境下虚拟设施的管理应该适应目前 VIM(虚拟化基础设施管理员)如OpenStack的编配模型。为了达到这一点,我们面对克服各种各样的挑战,诸如性能和动态服务管理。并鼓励读者思考在这种场景下创建端到端的解决方案的不同选项。
作者简介:
Sridhar,2007年新加坡国立大学取得计算机科学博士学位,2000年印度苏拉卡KREC大学获得计算机科学硕士学位,1997年印度杜姆吉尔的班加罗尔大学SIT取得仪器与电子本科学位。曾在印度SRM研究院从事研发组长;在新加坡信息通信研发中心(I2R)任职研发员。他曾工作于各种部署方案和部署项目包括ZigBee、WiFi和WiMax。Sridhar目前是NEC印度技术有限公司的技术专家,研发方向主要是下一代有线和无线网络领域,诸如OpenFlow、软件定义网络、软件定义无线系统为认知网络、HotSpot 2.0和物联网。
译者简介: