基于OpenFlow交换机的OpenStack部署实践

    译注：本项目平台为美国伊利诺伊大学的OCEAN，由176台服务器+16台Pica8公司OpenFlow交换机组成，提供从底层物理网络到应用的完整环境，支撑的项目包括得到HotSDN 2012最佳论文奖的VeriFlow，Jellyfish数据中心架构以及LIME虚拟网络迁移系统。项目2011年启动时OpenStack的网络仍为Quantum，方案设计可应用于后续版本Neutron。

    摘要：SDN（软件定义网络）经过逻辑上集中的主控制器实现对底层交换机报文处理的管理，在业界也所以出现了多种SDN/OpenFlow的控制器好比RYU，OpenDaylight、Floodlight等；随着云计算技术的发展在IaaS领域涌现不少开源的云平台管理工具，可是这两个领域目前尚未很好的融合。本项目经过为OpenStack的网络实现一个可扩展的OpenFlow控制器Plugin，试图解决早期OpenFlow控制器在扩展性方面的缺陷。

1、简介

    云计算愈来愈普及，云提供的弹性和服务的动态提供日益受人瞩目。随着OpenStack项目的出现，云平台的创新也愈来愈容易。最初OpenStack项目由instance管理项目（Nova），object存储项目（Swift）和image repository项目（Glance）组成，网路部分由Nova提供flat network配置和VLAN隔离，并无受到太多关注。这种简单的网络能力使得租户很难设立多级网络（flat networking模式），同时没有扩展性可言。

从Quantum项目开始，OpenStack在接口设备（好比vNIC）间提供“网络链接即服务”。Quantum使得租户能够轻松创建虚拟网络，模块化的架构和标准的API可方便实现防火墙和ACL的Plugin。在大量涌现的Plugin中，和网络最相关的就是OpenFlow控制器RYU的plugin，可是RYU开源的Plugin缺少云计算最基本的特性：扩展性。本项目将为Quantum设计一个更具扩展性的openflow plugin，同时利用SDN的集中控制，咱们还会演示基于控制器的虚机迁移应用。

2、实现方法

    Floodlight是基于Java的OpenFlow控制器，来源于Stanford大学最先开发的Beacon控制器(另外一个最先的控制器是NOX)，本项目选择Floodlight是由于它是一款相对简单又具备较高性能的控制器，不过本项目采用的方法可一样适用于其它控制器。

    OpenFlow开源控制器RYU提供和本项目相似的Plugin，实现了逻辑上的集中控制和API，便于建立新的网络管理和控制应用。RYU进行租户的2层网络隔离不是经过VLAN，而是为VM内部通讯创建单独的流，有实验代表这种方法在数据中心网络不具备扩展性，由于它会很快耗尽交换机的内存资源。

    咱们基于Floodlight为Quantum开发一款扩展性更好的OpenFlow Plugin。最初选择Floodlight是由于它是一款高性能的企业级控制器（译注：很是遗憾Floodlight已经中止更新）。不过本项目的方法能够很容易应用于其余标准的OpenFlow控制器。

咱们的Plugin未来自Quantum API的创建/更新/删除网络资源的请求传递给底层网络。除了Plugin，每个Nova VM会加载一个Agent用来处理该VM的虚拟接口的建立，并将它们与Quantum网络对接。咱们的方案利用支持OpenFlow的OpenvSwitch（OVS）来提供Quantum所需的底层网络，并经过Floodlight控制器对OVS进行配置。

1 挑战

    为Quantum提供OpenFlow控制器Plugin的最大挑战就是扩展性。RYU开源的Plugin为全部的VM间流量建立流，当流的数目超过OpenFlow交换机TCAM支持的最大条目后扩展性就会成为问题。

本方法采用更具备扩展性的VLAN方案对租户网络进行隔离。咱们知道VLAN一样有扩展性的限制，所以，后续方案开发能够考虑新的封装协议好比VXLAN。

2 架构

    Quantum的Plugin用来处理网络创建请求，它未来自Quantum的网络ID转换为VLAN并将这个转换关系维护在数据库中。Plugin负责OVS Bridge的建立，记录逻辑网路模型。Agent和Plugin同时纪录进入网络的端口，通知Floodlight有新的流量进入网络。基于网络端口的分配状况和端口的源MAC地址，流量被控制器加上VLAN ID标签。一旦加上标签后，网络流量就基于传统的learning switch进行转发。所以，经过VLAN标签和OpenFlow的控制咱们就能够基于租户进行VM流量的隔离。

    上图所示为Plugin的架构。租户经过nova-client将指令传递给Quantum管理单元，管理单元再将这些Call传递给真正执行建立/读取/更新/删除（CRUD）功能的控制器Plugin。Plugin经过在每一个租户的网络ID和VLAN ID间创建映射关系实现上述功能。每当有新的端口加载于Quantum网络，Plugin就会相应地添加端口到OVS-bridge，保存端口和VLAN ID间的映射关系。最后，以Daemon形式运行于每一个Hypervisor之上的Quantum agent不断轮询数据库和OVS Bridge，当有变化发生时就通知Floodlight Client，Client采用RESTful API告知Floodlight控制器模块。这样控制器就获取了端口、网络ID和VLAN ID的映射关系。当到达OVS的新报文没有任何entry时，报文会送到控制器作决策。而后控制器会推送一条规则到OVS告知其采用哪一个VLAN ID来标记报文以及封装报文所用的物理主机地址。另外，控制器还会为物理交换机增长一条规则，动做为按照普通报文处理流程处理报文，因此报文的转发将会按照基本的Leaning Switch方式。经过这个方法每一个物理交换机所需的TCAM条目数与经过交换机的VLAN数目成正比。

3 分析对比

本节分析对比上述方法与RYU方法在流表数目上对交换机的需求。假定每一个服务器有20个VM，每一个VM有10条并发流（出入各5条）。在这样的设定下，若是采用RYU的方法VM-VM间的流不具备扩展性。上图所示为两种方法的对比图。假定RYU的匹配规则基于VM的源和目的地址，所以ToR交换机须要在TCAM中存储20 servers/rack x 20 VMs/server x 10并发流/VM = 4000条流表。然而在咱们的方案中基于每一个报文的VLAN标签可对流表进行聚合，即便在物理交换机上每一个VM都有一条匹配规则（这里假定最坏状况即服务器上的每一个VM都属于不一样的租户），须要存储在交换机TCAM中的流表条目数也只有400条，能够降低十倍以上。

4 管理应用示例：VM迁移

    OpenFlow和咱们的OpenStack Plugin实现网络的全局视角以及对转发行为的直接控制，于是能够简化操做管理。接下来咱们提供一个应用案例：VM迁移。

高速无缝的VM迁移是数据中心实现负载均衡、配置管理、能耗节约等提高资源利用率的重要手段。可是VM迁移须要更新网络状态，可能致使冲突、业务中断、环路以及SLA不达标等一系列问题，所以VM迁移对服务提供商来说始终是一个挑战。SDN为解决这些棘手问题提供一个强有力的手段：在逻辑上集中的控制器位置运行算法和可精确控制交换机转发层面的能力有助于在两个状态间切换网络。

    本方法特别解决如下问题：对于分别由带有特定转发规则的交换机组成的起始网络和目标网络，咱们是否能够设计出一套OpenFlow指令将起始网络状态转换到目标网络，同时保持某些状态好比路径无环以及保证带宽。这个问题能够分解为两个小问题：肯定VM迁移的顺序或者规划排序；对于每个要迁移的VM，肯定要执行或者丢弃的OpenFlow指令的顺序。

    为了在有正确性保证的状况下进行迁移，咱们测试了最佳算法（用来从全部可能的迁移顺序组合中肯定致使最少冲突的排序）的性能。算法能够计算出VM迁移的排序以及一系列的转发状态改变。 算法运行在SDN控制器之上因此能够编排整个网络的改变。为了评估设计的性能，咱们在真实的数据中心用虚拟的网络拓扑仿真性能。对于各类负载状况，算法能够大幅提升迁移的随机排序性能（80%以上）。

    在共享的物理数据中心分配虚拟网络已经有不少研究，本项目借用这些工做中物理底层网络和VN的拓扑和设置。另外，对于底层拓扑，咱们测试了用于随机图、树、胖树、D-Cell和B-Cube的算法。对于VN，咱们采用Web服务应用常见的星形、树和3-tier图。在迁移前最初分配VN时，咱们使用了SecondNet的算法。

    咱们随机选择虚拟节点来进行迁移，从有空余资源的底层节点任意选择目的网络。在其余场景下当须要不一样的节点或目标选取策略时或许会影响算法的性能，基于本算法能够继续进行研究。

    迁移平台基于Intel的Core i7-2600K，16GB内存。图3实验为200个节点的树，连接带宽为500MB，VN为9节点树，链路带宽为10MB。如图所示，采用最佳算法后冲突比例保持在30%如下，而某些随机排序下则接近100%。

3、扩展工做：VXLAN

    随着VXLAN等新的协议出现，扩展多租户云网络的其余方法也能够被应用于Plugin的通讯底层机制。

    VLAN（IEEE802.1q）传统上常被用于为云中的不一样租户和组织提供隔离机制。虽然VLAN经过将网络分隔为独立的广播域解决了2层网络的问题，可是它没法提供敏捷的服务，可支持的host数目有限。所以，服务须要扩展时不得不适配不一样的VLAN，致使服务的分隔。另外，在手工配置的状况下，VLAN配置很容易出错，难于管理。虽然能够借助于VLAN管理策略服务器（VMPS）和VLAN trunking协议（VTP）自动化地配置access端口和trunk端口，可是网络管理员不多采用VTP，由于在这种状况下，管理员必须将交换机分为不一样VTP域，域中的每个交换机必须加入域中全部的VLAN，形成没必要要的负担。再加上VLAN头只提供12位的VLAN ID，网络中最多有4096个VLAN。考虑到VLAN普遍的用途，这个数目难堪重任。数据中心虚拟化后进一步增大对VLAN的需求。虚拟可扩展VLAN（VXLAN）是IETF推出的标准，试图经过引入24位的VLAN网络标识符（VNI）来消除VLAN的限制，也就是说VXLAN可在网络中建立16M个VLAN。VXLAN主要利用hypervisor中软交换（或者硬件接入交换机）的虚拟隧道端点（VTEP）并将与VM相关的VNI和报文进行封装。VTEP基于IGMP协议加入多播组，这有助于消除未知的单播flood。

限制：VXLAN中16M个VLAN将超过多播组的最大数目，因此属于不一样VNI的多个VLAN可能共享同一多播组。这可能致使安全和性能的问题。

4、总结

基于OpenFlow交换机部署OpenStack可充分体现SDN的优点。本项目实现了可扩展的Quantum/Neutron网络Plugin，同时为后续进一步基于VXLAN等新封装协议优化改善Plugin提供了设计方向。

本文来源于SDNLAB，可点击此阅读原文。若是您对本文感兴趣，可参与如下互动方式与做者近距离交流。

（1） 微博（http://weibo.com/sdnlab/）

（2） 微信(帐号：SDNLAB)

（3） QQ群

SDN研究群（214146842）

OpenDaylight研究群（194240432）