OpenStack和OpenDaylight(ODL)的融合是一个热门话题,有大量的文档可供参考,但是这些文章主要对其使用方面进行阐述,而没有讲如何实现OpenStack和ODL的融合。该篇文章将详细说明如何实现不同组件的融合。
ODL和OpenStack完整的安装步骤如下:
1、在虚拟机或者物理机上构建和安装合适的ODL版本(取决于你的选择)。确保你有合适的bundle实现Neutron的API(OVSDB、VTN Manager、LISP等)。
2、正确配置并启动ODL。
3、部署OpenStack。最好是多节点部署:一个控制节点,一个网络节点和若干个计算节点。
4、配置OpenStack,为ODL和OpenStack的融合作准备:
- 确保核心插件在模块化的二层组件(ML2)上。
- 将ODL作为“机制驱动”部署在ML2上。
- 配置ml2_conf.ini文件的[ml2_odl]区域:
123 | 1、username = admin 2、password = admin 3、url = http://IP-Address-Of-OpenDayLight:8080/controller/nb/v2/neutron |
5、在OpenStack上创建虚拟机,构建虚拟网络。
6、验证ODL界面生成的网络拓扑是否与想要的一致。
OpenStack和OpenDaylight融合
图1总结了OpenStack和ODL融合的全过程。Neutron包含ML2机制驱动,该机制驱动(ODL)作为REST代理能够调用所有的Neutron API。ODL包含北向REST服务(Neutron API服务),能够调用这些代理API缓存数据并可用于ODL的其他服务。下图详细地描述了这两个组件,这些RESTful API可以完成OpenStack和ODL的绑定。
图1:OpenStack和OpenDaylight融合
OpenStack
Neutron的模块化的二层组件(ML2)是一个可以使用二层网络多样性技术的框架。带有ML2插件的驱动程序实现了网络类型(local、flat、VLAN, GRE和VXLAN)的扩展和访问这些网络的机制驱动。
在ML2上,当添加、删除和修改三种核心资源(网络、子网和端口)的时候,将调用两次机制驱动。首次调用(也称为预提交调用)是为了维护机制驱动的状态,属于数据库业务的一部分。就ODL机制驱动而言,没有必要做这种预提交的操作。一旦业务被提交,机制驱动可以与外部服务和控制器交互的时候,其将被二次调用(也称为提交后调用)。
图2:ML2机制驱动架构
机制驱动在端口绑定过程中也发挥了作用:确定是否相关的机制可以为网络提供连接,如果可以,就使用相应的网段和VIF驱动。
图2总结了OpenStack Neutron的ML2机制驱动架构。ODL机制驱动由“mechanism_odl.py”文件和网络ODL驱动组成。基于ODL的API手册,机制驱动被分成了两个部分(核心API和扩展API),ODL机制驱动和ODL驱动类实现了核心API,ODL的3层路由插件类只实现了扩展API。目前,ODL驱动不支持防火墙服务(FWaaS)和负载均衡服务(LBaaS)。
ODL机制驱动接收到调用消息后,就对核心资源(网络、子网和端口)进行相应的添加、删除和修改的操作,机制驱动通过调用同步函数将消息转发给ODL驱动类,该同步函数采用了‘sendjson’ API。
同样地,ODL的3层路由插件类利用3层的API添加、删除和修改路由和浮动IP。因此,核心API和扩展API都调用‘sendjson’ API向ODL控制器发送REST请求,并等待应答。
之后的章节会介绍ODL是如何处理这些REST调用的。
OpenDaylight
OpenDaylight暴露OpenStack Neutron API服务接口,给多样性的解决方案提供Neutron API操作。图3总结了OpenDaylight Neutron API的实现架构,Neutron API服务主要由三个bundle组成:北向API和南向接口(SPI)、转录器(transcriber)以及解决方案的集合。
图3:OpenDaylight Neutron API实现架构
Northbound API Bundle
OpenDaylight的北向API处理来自OpenStack插件的REST请求并作出合适的应答。该bundle的组成部分如下:
1、父类请求: IneutronRequest。
2、JAXB(Java architecture for XML Binding)带注释的request类的集合,这些类涉及到的资源有:网络、子网、端口、防火墙和负载均衡等,这些request实现了IneutronRequest接口。例如:网络request包含如下属性:class NeutronNetworkRequest implements INeutronRequest
123456 | @XmlElement(name="network") NeutronNetwork singletonNetwork; @XmlElement(name="networks") List<NeutronNetwork> bulkRequest; @XmlElement(name="networks_links") List<NeutronPageLink> links; |
3、Neutron北向类的集合:为管理资源提供REST API。例如:NeutronNetworksNorthbound 类包括如下API:listNetworks(), showNetwork(), createNetworks(), updateNetwork()和deleteNetwork()。
除非特别提及,symbol*类都表示如下资源:网络、子网、端口、路由、浮动IP、安全组、安全组规则、负载均衡、负载均衡监测、负载均衡监听器和负载均衡资源池等。
Neutron SPI Bundle
Neutron SPI是连接北向API到实现方案的重要bundle,这个bundle包括:
1、JAXB (Java architecture for XML binding)注释的基类和子类。这些类以Neutron*命名,支持v2.0版本的API文档。
2、INeutron*CRUD接口。这些接口通过转录器(transcriber)实现。
3、INeutron*Aware接口。这些接口通过特定的插件(OpenDove、OVSDB、VTN等)实现。
Transcriber Bundle
Transcriber模块包含Neutron*类,这些类通过实现INeutron*CRUD接口将Neutron对象缓存下来。其中,大部分的类都包含一个并发的HashMap。如private ConcurrentMap
Implementation Bundle
OpenDaylight的优势在于其包含Neutron网络的多种实现方式,提供多种与OpenStack结合的方法。ODL的北向服务能够提供网络虚拟化,这一功能可以作为Neutron网络的一种实现方案。ODL用于Neutron API实现的插件包括:
1、OVSDB:OpenDaylight将其北向API与Neutron结合,使用OVSDB对计算节点的虚拟交换机进行配置。所以ODL可以管理网络连接,还可以为计算节点开通GRE或者VXLAN隧道。OVSDB Integration是一个可以实现Open vSwitch数据库管理协议的bundle。该管理协议是网络虚拟化中Open vSwitch转发数据需要的重要协议。虚拟化版本中的OVSDB neutron bundle支持使用VXLAN和GRE隧道部署OpenStack和CloudStack的网络虚拟化。
2、VTN Manager(Virtual Tenant Network):VTN manager是网络虚拟化的一种解决方案,实现了一个使用AD-SAL的控制器的OSGI bundle,可以管理OpenFlow交换机。VTN manager还有一个单独的组件为OpenStack提供网络服务。VTN manager的Neutron组件能使OpenStack运行在单纯的OpenFlow环境下,因为数据平面所有的交换机都支持OpenFlow。VTN manager还可以使用OVSDB-enhanced VTN。Neutron bundle可以使用OVSDB插件进行添加端口等操作。
3、Open DOVE:Open DOVE是一个“网络虚拟化”平台,控制平面使用OpenDaylight,数据平面基于Open vSwitch。Open DOVE的目的在于供2层或3层的多租户网络建立连接,它运行在虚拟数据中心的所有IP网络上。据IBM研究,Open DOVE是基于IBM SDN虚拟环境和DOVE技术的。Open DOVE在氢版本发布之后就再没有更新过,无疑它在ODL锂版本上的扩展性受到了限制。
4、OpenContrail (plugin2oc):为OpenDaylight控制器和OpenContrail平台提供交互。开源解决方案的结合使得OpenContrail具备了一些功能,例如:OpenDaylight项目的云网络和网络功能虚拟化(NFV)。
5、LISP Flow Mapping
LISP(Locator/ID Separation Protocol)目的在于提供一个灵活的map-and-encap框架可以为overlay网络应用程序所使用,并将网络的控制平面与数据转发平面分离。LISP包含两个namespace:endpoint identifiers (EIDs — 主机的IP地址)和routing locators (RLOCs —连接主机的LISP路由的IP地址).LISP流映射提供了LISP映射系统服务来存储数据(包括路由策略和负载均衡等)。
这些解决方案实现了以下部分或全部的功能:网络、子网、端口、路由、浮动IP、防火墙、防火墙策略、防火墙规则、安全组、安全组规则、负载均衡、负载均衡监测、负载均衡监听器、负载均衡资源池和负载均衡资源池成员。这些处理程序支持对核心资源(网络、子网和端口)进行相应的添加、删除和修改的操作。例如:NeutronNetworkHandler实现了如下操作:
Shell123456 | canCreateNetwork(NeutronNetwork network) neutronNetworkCreated(NeutronNetwork network) canUpdateNetwork(NeutronNetwork delta, NeutronNetwork original) neutronNetworkUpdated(NeutronNetwork network) canDeleteNetwork(NeutronNetwork network) neutronNetworkDeleted(NeutronNetwork network) |
南向插件的使用决定了机制的选择:OpenFlow(1.0或1.3)、OVSDB、LISP、REST(OpenContrail)等。举一个VTN Manager中ManagerNeutronNetworkCreated handler的例子,参与处理程序的步骤总结如下:
1、检查是否可以通过调用canCreateNetwork再次创建网络。
2、将Neutron网络的租户ID(tenantID)和网络ID(network ID)分别转变成租户ID(tenant ID)和网桥ID(bridge ID)。
3、检查租户是否已经存在,否则就创建一个租户。
4、创建网桥并执行VLAN映射。
实际的操作流程是VTN manager的Neutron组件调用前者的核心功能,使用OpenFlow(1.0)插件逐个配置OpenFlow交换机。
使用所有的bundle创建网络
图4:在OpenDaylight上创建网络的过程
图4简要地总结了网络创建的过程和上述OpenDaylight Neutron实现方案中bundle的调用。该图帮助读者理解所有bundle中的控制流。
总之,OpenDaylight是与OpenStack融合的最优控制器之一,虽然暂不支持负载均衡和防火墙服务,但多种免费的解决方案和完整的核心API对管理员来说有巨大的优势,带来了很大的灵活性。我们期待在不久的将来OpenDaylight能够支持OpenStack的所有扩展,实现二者的完美融合。
声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。