第一章 引言
1.1 研究背景及意义
云网融合是指实现云计算与网络虚拟化的深度融合，从而实现云计算和网络虚拟化的统一联动，让网络资源在云计算平台中充分发挥潜能，从根本上保障用户业务的顺利进行[1]。云网融合也促进了基础设施的标准化和归一化、网络功能的虚拟化和软件化、IT 能力的业务化和平台化[2]。由美国国家航空航天局(NASA)和 Rackspace 共同开发的 OpenStack，是 Apache授权的开源云计算平台[3]，类似的平台还包括 Amazon 的 AWS[4]、微软的 Azure[5]、国内的阿里云[6]、腾讯云[7]。OpenStack 支持公有云和私有云两种云环境，它的基础架构即服务（IaaS）提供了一种各种互补服务的解决方案，每个服务都提供了一个便于集成和调用的应用程序编程接口（API）。OpenStack 的服务包括：Dashboard、Compute、Networking、Object Storage、Block Storage、Identity Service、Image Service、Telemetry、Orchestration、Database Service[8]。随着数据中心内云计算的广泛使用，使得支撑云的数据中心网络承受了很大的压力，除了云平台各种新应用的出现以及网络安全的高要求外，还有为了提供更好的计算与存储服务质量，使得对网络灵活性的要求更加突出。云平台服务提供者如何尽可能提供更好的网络服务，以及更及时地应对网络安全事件就成为一个严峻的问题。另外云平台的基础环境搭建复杂，网络流量可控性差、负载均衡和网络管理灵活性低，如何快速地给云平台的用户提供自动部署业务的环境和更加成熟灵活的网络服务，满足云平台管理者灵活管理网络的需求成为研究重点。
从 OpenStack 的设计看，它可以提供计算、存储和网络服务，其中 Neutron 是 OpenStack的网络组件，Neutron 设计之初基于 SDN(Software Defined Networking) 错误!未找到引用源。的思想并提供框架。相较于成熟的计算和存储服务，Neutron 二层网络服务在如今复杂的数据中心中成为一个短板，缺乏有效的实现和管理，例如可控性差、公网网络瓶颈、扩展性不好、灵活性低等，以及三层路由目前没有单独的插件（Plugin）结构，而且仅支持静态路由。虽然Neutron 基于 SDN 控制转发分离思想，但实际上 Neutron 的控制与转发并没有实现完全分离，交换机之间的数据交换都是基于动态协议自动协商，整体数据的转发可控性差，违背了Neutron 设计的原本网络虚拟化意愿。而且从目前看，Neutron 网络技术研发方面的工作量至少占到 OpenStack 研发所有工作量的一半以上，也使得该部分的研究成为热点。
............................
1.2 研究内容与创新点
本文通过 OpenStack 结合 OpenDaylight[14]的架构实现云网融合，主要包括融合架构的提出，为实现该架构进行 OpenStack 和 OpenDaylight 结合的自动部署，然后通过流量可控和租户隔离两个关键属性验证云网融合成功。并基于二者结合构建的云网融合平台，根据用户需求，用解析器解析需求来实现业务自动化部署，本文主要内容和创新点包括：
(1) 云网融合方面：设计了 OpenStack 的 Plugin 和 OpenDaylight 的融合架构，主要分析用户的网络需求，对融合关键技术分析和实现，并在 OpenDaylight 中为 OpenStack 提供网络功能需求接口，例如拓扑管理模块和交换机管理模块；OpenStack 的底层 Plugin 使用OpenDaylight 接管 OpenStack 网络，实现 OpenStack 网络管理和流规则的管理与下发。为了验证设计的融合架构的可行性，设计了两种不同的自动部署方法实现云网融合平台的自动部署。
(2) 云网融合两方面验证：首先是云网流量可控性验证，通过 OpenDaylight 对 OpenStack的二层网络的接管，实现对 OpenStack 云平台流量的管理。其次是云网融合租户隔离性验证，在实现融合后，OpenStack 的底层租户隔离网络发生改变，二层隔离网络需要重新实现OpenStack 网络的隔离方式。本文利用传统的 GRE（Generic Routing Encapsulation）通用路由封装或新型的覆盖网络 VxLan（Virtual Extensible LAN）虚拟可扩展局域网等方式实现了多租户网络的隔离，达到流量分离的目的，保障用户利益，同时方便运维人员的管理。
(3) 业务自动部署：通过总结当前的租户业务需求，设计了业务自动部署 U 模型，用户通过更直观的界面选择相应的资源选项，通过 YANG 语言进行建模验证需求正确性，然后用解析器对需求进行解析，再调用模板库实现云网的业务自动部署。本文实现了该模型中需求验证、解析器。
............................
第二章 相关研究
2.1 OpenStack 结合 OpenDaylight 的研究现状
2.1.1 OpenStack 的网络研究现状
OpenStack 的网络功能最初由 Nova-network 组件提供，云平台租户间的隔离采用VLAN(Virtual Local Area Network)技术，支持多主机，拓扑简单，报文转发流程少，但是存在多种缺陷，例如网络管理功能较少，转发效率损耗较低，不便于扩展，私有网络不支持地址重叠，不能提供高级网络服务，例如 FireWall as a service(FWaas)、LoadBalance as a service(LBass)、VPN as a service(VPNaas)，另外因为隔离方式只支持 VLAN，所以租户数最多只有 4096 个。
Nova-network 的网络结构单一，只支持二层和三层简单网络服务，已经逐渐发展为基于SDN 网络可编程思想的 Neutron 网络服务，通过 OpenStack 的命令行 CLI（Command-Line Interface）或者 Dashboard 组件的用户界面调用 Restful API 配置 OpenStack 网络功能，然后根据 API 将租户网络配置信息下发到底层网络，其中包括 Floating IP 的转换和 NAT 转换、利用OverLay 网络的 VLAN 或者 VxLan 隔离技术实现租户之间的隔离、防火墙、VPN 和负载均衡高级服务等。在 OpenStack 网络架构中，
Neutron 实质上起着网络管理平台的作用，用一种业务上的逻辑把网络功能组织起来，因此该组件本身并不提供任何实际网络连接功能，它仅为底层网络设备向上层网络服务提供接口架构。Neutron 的网络功能主要是由各种 Plugin（插件）提供，除了 DHCP（Dynamic Host Configuration Protocol）和三层 Agent 等其它功能，Neutron将网络按照三层交换机的概念分为三个部分：Network、Subnet 和 Port。
Neutron 包含三个组件：
（1）Neutron-server：用来接收 Neutron 的 REST API 调用，然后将不同的 REST API 分发到不同的 Neutron-plugin，传到不同网络功能实现的入口；
（2）网络插件（Neutron-plugin）和插件代理（Agent）：neutron-server 将具体要执行的业务操作和参数发送给 OpenStack 计算节点对应的 neutron-agent，包括创建网络和子网并直接动态地提供 IP 地址。底层的插件和代理因插件供应商和虚拟技术的不同而不同，其中OpenStack 网络的插件和代理包括主流厂商有 Cisco 虚拟和物理交换机、NEC OpenFlow 产品、Open vSwitch、Linux bridging 以及 VMware NSX 产品[16]等。
（3）消息队列： OpenStack 安装所有服务交互通信的工具，用于 neutron-server 和其它的代理进程间通信，同时也可以为某些插件存储网络状态。
.............................
2.2 OpenStack 和 OpenDaylight 自动部署研究现状
OpenStack 除了有 Rackspace 和 NASA 的大力支持外，还有包括戴尔、Citrix、Cisco、Canonical 等软硬件网络公司的贡献和支持，它们投入大量精力来实现和简化云的部署过程，并希望能给网络带来良好的可扩展性。截止目前，OpenStack 发布了 16 个版本[44]，OpenStack包括多个组件，分为单节点(All In One)和多节点(Multi-Node)。OpenStack 部署需要考虑网络规划、计算资源和存储资源的扩展以及相关的监控计费等多个组件的安装。有研究表明可以在学校部署 OpenStack 以提供更便捷的实验环境[45]，目前 OpenStack 官方的 DevStack[46]一键部署脚本，是 Openstack 最早的安装脚本，通过直接获取源码进行安装，目的是让开发者可以快速搭建一个环境，但是该环境不能作为生产环境，因为 DevStack 是 OpenStack 提供的一个调试和开发的环境，而非实际生产平台。文献[47]将虚拟机调度策略形成自动部署文件，
类似 DevStack 的自动化脚本，说明脚本执行自动部署的可行性。不少公司和组织在研究OpenStack 的部署，由 Red Hat 开发的开源的自动化部署工具 RDO[48]，该工具支持 All In One和 Multi-Node 的部署，但是它只适用于 CentOS 的操作系统，并且该部署工具并不属于OpenStack 官方社区项目，难以扩展。在 Openstack 发展之初，官方的安装文档，基本都是来自 Stackops[49]，填写相关的配置参数，通过 Chef[50][51]进行部署，但是 Chef 脚本并没有开源，以及 Stackops 通过商业定制进行收费，对 OpenStack 的新版本支持比较慢。由 Ruby 语言编写的自动化工具 Puppet[52]，是较早支持 OpenStack 自动化部署的自动化工具，当前主要由红帽、Mirantis 和 UnitedStack 等公司进行开发维护。思科就使用了 Puppet 实现 Openstack 部署，通过 Puppet 部署 Cobbler[53]，利用 Cobbler 安装 Ubuntu 系统，再利用 Puppet 安装 Opentack 的组件，并把监控集成到 Dashboard 里，但需要思科的专门交换机才行。目前包括雅虎等很多公司在做 OpenStack 自动部署，但该部署实现与各自公司的产品有较大耦合。TripleO 项目是惠普公司实现 OpenStack 的安装与部署的项目[54]，它利用 OpenStack 部署 OpenStack，即基于V2P(Virtual-to-Physical)的思想，和 P2V(Physical-to-Virtual)相反，它提前准备好 OpenStack 计算、存储、控制节点的镜像，然后使用已有 OpenStack 环境的物理机的服务和软件，用镜像制作的方法来部署物理机，最终通过 OpenStack 的 Heat 编排项目和镜像中的自动化部署工具Puppet 或 Chef 在物理机上部署 OpenStack。Mirantis 公司基于 Puppet 的 Fuel 工具通过图形界面来自动化部署 OpenStack，该工具大量使用了 Python、Ruby 和 JavaScript 等语言[55]来实现自动化，Fuel 的功能包括通过自动化的 PXE (preboot execute environment）方式安装操作系统、编排服务和自动安装相关服务等，另外还有关键业务健康检查和日志实时查看等实用的功能来记录 OpenStack 的用户操作等，Fuel 也提供了 SDN 接口，例如提供 OpenContrail 平台接口来集成 SDN 控制器，目的也是为了改善 OpenStack 的网络[56]，但是 Mirants 的 Fuel 部署工具后期维护困难，而且并非完全免费开源。Ansible 是基于 Python 开发的一个自动化部署配置管理工具，集合了其他的自动化运维工具[57]，例如 Puppet、Chef、SaltStack 等设计的优点，Ansible 包括批量系统配置、批量程序部署、批量运行命令等功能，也增加了一些别的设计，例如基于 SSH 方式工作，因此不需要在被控端额外安装客户端。
...............................
第三章 云网融合架构设计验证及业务部署设计 ................................ 153.1 云网融合的关键技术分析 ................... 15
3.2 OpenStack 结合 OpenDaylight 的架构设计 ....................... 18
第四章 云网融合自动部署实现及关键属性验证 .............. 28
4.1 云网融合自动化部署实现 ........................ 28
4.1.1 OpenStack 结合 OpenDaylight 抽象服务自动部署 ..................... 30
4.1.2 OpenStack 结合 OpenDaylight 容器脚本自动部署 ........................ 33
第五章 云网融合分析 ........................ 45
5.1 云网融合自动部署分析 .................... 45
5.2 流量可控分析 ..................... 47
第五章 云网融合分析
5.1 云网融合自动部署分析
根据本文的云网融合架构，设计了两套自动部署方案，简化了部署运维，通过 OpenStack 结合 OpenDaylight 抽象组件服务脚本部署和 Kolla 结合容器部署节约了部署时间，并降低了运维人员的出错概率，从以上的实验可以看出两个脚本的代码量。第一种抽象服务组件的方法代码约为 1200 行，而第二种容器化部署代码量约为 200 行，极大的缩减了代码量；其次对比二者的自动化执行时间，抽象组件服务脚本执行 OpenStack 自动部署时间消耗为两个小时，而利用 Kolla 安装工具部署容器化 OpenStack 时间消耗为三个小时，虽然代码量减少，但是时间并未减少。通过分析 Kolla 安装工具得知，有两个原因造成安装时间多于第一个抽象服务组件脚本：
（1）使用安装的 OpenStack 源码的源地址不同，Kolla 选择国外的安装镜像源地址，而第一种抽象服务组件方法选择的是国内的安装源，通过分析两个源地址获取源码的下载速度发现，国外的镜像源明显比国内的源慢。
（2）比较脚本安装和 Kolla 容器安装，Kolla 安装需要下载 OpenStack 一个集成的镜像，通过 source 安装 OpenStack 镜像，该镜像约为 2.5G，而第一个抽象服务组件方法安装采用源码安装。
通过表 5.1 可知，Kolla 容器部署要比抽象服务部署代码量少、时间消耗少和效率更高，因为本文 Kolla 容器部署方法将镜像包装后，并存放在本地，加快了部署速度，更快的实现云网融合部署。
........................
第六章 总结与展望
6.1 本文总结
SDN 由于提供网络控制转发分离得到更为灵活和精细管理网络的能力，它的出现可以为改善 OpenStack 的网络管理模式提供更好的选择，OpenDayLight 是开源的 SDN 控制器，相比其它控制器具备更好的扩展性，更适合改善 OpenStack 的网络灵活性。本文对 OpenStack 的网络进行研究，采用 OpenDayLight 与 OpenStack 进行结合改善 OpenStack 网络可控性，减少手工配置复杂的云网基础环境操作，降低了云环境的出错概率和管理网络的时间消耗。云网融合通过获取整个拓扑，更精准的管理网络流向，为云数据中心运维人员和企业提供更迅速、更安全的控制网络流量和数据安全的方法。本文主要完成如下工作：
(1) 提出一种 SDN 控制器 OpenDaylight 融合 OpenStack 的架构，融合架构包含三层，基于该架构实现云网融合。同时还利用两种方法实现了多节点的自动部署方法，对比分析两种部署方法并改进了容器部署，同时分析了用户的需求，为云计算业务自动部署奠定基础。
(2) 实现云网融合后，验证了云网的两个关键属性。验证了云网融合流量可控，实现OpenDaylight 对 OpenStack 的二层网络的接管，
OpenDaylight 可以通过下发规则到交换机达到对 OpenStack 流量走向的管理，实现精准化控制云网流量，并通过递归和关联查询算法改善了 OpenStack 的网络删除功能，可以直接实现对构建网络的删除。验证了云网的多租户网络隔离实现，再次实现了 OpenStack 的租户网络隔离方式，包括 GRE 和 VxLan 的隔离网络构建。实现了流量分离互不干扰，方便云网运维人员的管理。
(3) 当实现云网融合后，为加快云网中的业务迅速上线，本文通过设计的业务部署 U 模型，分析用户的业务需求，然后通过解析器把需求参数获取生成参数脚本文件，同时调用本地已有的增量式模板，从而实现业务的自动部署。
参考文献（略）