作者：陆平等
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
OpenStack系统架构设计实战试读：
前言
早在20世纪90年代，云计算就已作为一种全新的技术模型被提出，但直到2007年，才因Google、亚马逊等云计算先驱将其付诸于商业实践并获得丰厚利润，从而得到业界的广泛重视。与互联网、物联网等技术一样，云计算是电子信息技术和信息社会的需求发展到一定阶段的必然产物。从2007年至今，云计算已经成为人们进行信息交互与存储的重要方式，云管理平台也成为大数据处理和深度挖掘的主要平台。
高盛研究公司在2015年的一份报告中指出，花在云计算基础建设以及云管理平台上的费用在2013~2018年的年均增长率为30%，而整个IT行业的预计增长率仅为5%。面对这个蓬勃发展的市场，许多咨询公司和研究机构都对云计算市场有着不同的预测，但是他们都一致认为，在全球范围内，云计算的发展正在加速。在巨大需求的刺激下，云计算核心得到快速发展，商业云计算与开源云计算技术在竞争中共同推进，而云计算与行业结合，也形成了形态各异、特色鲜明的电子政务云、教育云、医疗云、金融云、环保云、旅游云等云计算服务，云计算大数据的发展空间则更加广阔。
中兴通讯公司在云计算方面有多年的技术积累和应用实践。本书结合云计算最新技术趋势和中兴通讯公司的长期实践，对云计算技术提出系统性的阐述，对云计算实践提供了思路和建议。本书首先从云计算的需求和现状出发，分析目前云计算面临的问题，针对这些问题分析了IaaS云管理平台、IaaS云平台部署，并对PaaS（平台即服务）等概念进行了充分的探索和讨论。本书结构
本书由12章组成。
第1章对各主流云管理平台进行介绍及对比，并对OpenStack平台进行了重点介绍。第2章系统地介绍了Nova的各个子模块，以及Nova的基本运行原理。第3章重点介绍了OpenStack项目的存储管理（Cinder）模块，描述了Cinder的架构、API、主要功能和工作流程。第4章从网络虚拟化主要面临的问题出发，讨论了Neutron架构及其具体功能。第5章从Ceilometer的体系架构谈起，首先简单介绍了Ceilometer的起源和几个重要概念，之后介绍Ceilometer的架构及关键组件，使读者对Ceilometer有整体的了解，然后详细剖析Ceilometer的数据采集机制，包括计量数据采集、计量数据转换和发布、计量数据存储，并介绍Ceilometer的二次开发。第6章重点讲述OpenStack中编排子系统（Heat）的相关概念、架构及其实现，并分别介绍Heat模板、Heat资源类型以及Heat引擎，结合典型的场景，对基于Heat的业务弹性伸缩流程进行深入的分析与阐述。第7章从介绍裸机管理的PXE、IPMI通用技术开始，对Ironic的架构、基本运行原理和流程，以及Ironic的完全安装、简化安装等进行介绍。第8章系统地介绍OpenStack的消息总线及其基本运行原理，让读者对OpenStack的消息队列协议以及常用的消息队列方案有一个全面了解。第9章通过对Sahara使用模式、架构的介绍，及其与Amazon、VMware解决方案的对比，让读者对大数据即服务的概念建立清晰的认识。第10章对Trove总体架构、主要功能和API接口、安装和配置，以及二次开发进行全面的介绍。第11章通过对Keystone的介绍，阐明OpenStack作为云管理平台，如何应对云计算带来的包括虚拟化安全、数据安全、身份和访问管理安全等新的安全挑战。第12章分别从使用场景、逻辑架构等视角对当前OpenStack社区中比较活跃的孵化项目，例如，消息队列服务（Zaqar）、共享文件系统服务（Manila）、DNS管理服务（Designate）、密钥管理服务（Barbican）、容器管理服务（Magnum）进行介绍。
本书适合高校计算机相关专业学生、云计算研究人员、云计算开发者和工程技术人员阅读参考。由于作者水平所限，书中难免存在一些谬误和不足之处，敬请读者批评指正。本书在写作过程中得到了很多领导和同事的大力支持，在此一并表示谢意。作者2016年5月第1章 云管理平台概述
云服务的核心在于服务所运行的技术平台，云平台在计算、存储和网络等方面为云服务提供支撑，为用户提供所需要的IT资源。云管理平台允许开发者或将写好的程序放在“云”里运行，或使用“云”提供的服务，或两者皆有。至于这种平台的名称，现在可以听到不止一种，比如按需平台（on-Demand Platform）、平台即服务（Platform as a Service，PaaS）等。但无论它叫什么，这种新的支持应用的方式无疑有着巨大的潜力。云平台是云计算的重要组成部分，如图1-1所示。云平台将虚拟化的计算资源、存储资源、网络资源统一管理，并面向用户提供服务，形成了云服务。可以说没有云平台，就没有云计算和云服务。图1-1 云平台基础架构1.1 主流云管理平台对比
目前，业界中有4种有影响力的主流开源软件平台，分别是OpenStack、CloudStack、Eucalyptus、OpenNebula。同时VMware作为云的商业软件提供商，也有很大的影响力。本章节对这几个云平台做简单的对比。
如表1-1所示，对4种开源云平台从背景、架构、商业模式等方面进行了全面的对比，希望读者有更全面的认识。表1-1 4种开源云平台对比
VMware与OpenStack相比，两者在设计原则、商业模式等方面都有所不同，导致其在架构、功能、实施和维护性方面有一定的差异。VMware软件套件是以虚拟化技术为核心，自底向上的架构，下端边界为虚拟机管理器。像VMware的vSphere和vCloud director产品都依赖于免费的ESX（i）虚拟机管理器，ESX（i）虚拟机管理器能提供非常优秀的部署架构。VMware的软件套件也是经过全面测试的，并且都有单一部署框架。总的来说，VMware的产品由于其架构的健壮性，很多高规格用户在多数据中心规模的环境中都会使用。而OpenStack作为一个开源系统，没有任何一家单独的公司控制OpenStack的发展路线。OpenStack本身是年轻的，但是却具有巨大的市场动力，与此同时，很多大公司都在支持OpenStack的发展。有了如此多公司的资源投入，OpenStack的发展将是多元化的。
从具体功能来看，VMware的核心功能是VMware vMotion。它是vSphere DRS、DPM和主机维护三大功能的集合，同时VMware具有FT高容错、跨数据中心的容灾迁移等特色功能。OpenStack也支持虚拟机的动态迁移，KVM动态迁移允许一个虚拟机由一个虚拟机管理器迁移到另一个，说详细一点，你可以基于共享存储来来回回地将一台虚拟机在AMD架构主机与Intel架构主机上进行迁移。OpenStack目前并不支持FT高容错等特色功能，但OpenStack的优势在于开放的架构以及对广大的IT设备厂家硬件的支持，各个厂家可以基于OpenStack的架构，开发出很多特色功能。FT功能的实用性存在问题，也并不能保证备机状态的完整性。因此从应用角度我们可以看到，在功能的支持和功能细节方面，OpenStack相比VMware还是有差距的。但是OpenStack还是有优势的，因为与VMware昂贵的价格相比，OpenStack免费、开放的优势明显。对于VMware高投入带来的功能，OpenStack可以免费提供给客户大部分。从VMware在功能方面的领先优势可以看出，VMware还在继续研发除了vMotion、高可用、容错以外其他的新功能，以保护它们的虚拟；OpenStack一方面跟随VMware的脚步，另一方面也投入精力在支持更多的硬件厂商解决方案上。
关于OpenStack、OpenNebula、Eucalyptus、CloudStack社区的活跃度，这里借用蒋清野先生提供的一组对比数据，以对这些社区的活跃度进行分析和比较，如图1-2和图1-3所示。
图1-2和图1-3分别是上述4种开源项目的相关社区每个月所产生的讨论主题数量和帖子数量。可以看出：
1）从2012年开始，与OpenStack和CloudStack相关的主题讨论数量在同一水平上，与Eucalyptus和OpenNebula相关的主题讨论数量在同一水平上。
2）从2012年开始，与OpenStack和CloudStack相关的主题讨论数量远大于与Eucalyptus和OpenNebula相关的主题讨论数量。图1-2 4种开源云平台论坛主题数量对比图1-3 4种开源云平台论坛帖子数量对比
如图1-4所示是4种项目的社区人数、上个季度的活跃用户数量，以及过去一个月的活跃用户数量。可以看出，OpenStack的社区人数最多，然后是Eucalyptus、CloudStack、OpenNebula。图1-4 用户活跃度对比
如图1-5所示是4个项目每个月提交代码的人数。总体来看，针对OpenStack项目提交代码的人数远远超过其他3个项目，并且一直保持迅猛增长的势头。针对CloudStack项目提交代码的人数也有所增长，但是其增长速度较为缓慢。针对Eucalyptus项目和OpenNebula项目提交代码的人数相对较少，并且在一段时间内基本上没有增长。
客户希望将OpenStack作为下一代基础架构平台，并要求其有能胜任传统任务负载的特性（如灾难恢复、高可用性等）。OpenStack目前已经成熟，并能提供丰富的功能，它已经走出实验室和概念验证阶段，成为生产级任务负载的主流技术。全球著名的综合性IT巨头，如IBM、EMC、HP、Cisco纷纷加入OpenStack的行列；RedHat、SUSE、Ubuntu等操作系统厂商也推出了OpenStack发行版；Rackspace、Mirantis、中兴通讯、华为、UnitedStack分别是全球及国内著名的OpenStack系统集成商。
OpenStack目前已经在许多垂直市场得到应用，如政府、金融服务、医药、大型企业和电信行业。2014年8月，沃尔玛将其全部的电子商务业务迁移到了OpenStack上，其中包括10万条核心数据和几个PB的存储数据。到2014年年底，Walmart.com整个美国的流量都由该平台支撑。沃尔玛的下一步计划是在这个平台上构建SDN和存储系统。另外还有汽车巨头宝马、视频领域的巨头时代华纳都将自己的应用部署到了私有的OpenStack平台上。OpenStack在中国也不乏此类的成功案例，有一批互联网公司采用OpenStack，其中包括百度、携程、爱奇艺、360、京东、阿里巴巴、高德等。而在传统企业方面，著名的天河二号超级计算机就采用了OpenStack来部署其HPC云环境，涉及1.6万个节点。图1-5 提交代码的人数对比
OpenStack的成熟度、影响力、部署规模、所提供功能的丰富性都是业界主流云管理平台中最强的。所以，在IaaS云管理平台部分，本书将主要以OpenStack为例进行介绍。1.2 OpenStack简介
OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案，每个服务提供API以进行集成。
OpenStack是一个旨在为公有云及私有云的建设与管理提供软件的开源项目。它的社区拥有超过130家企业及1350位开发者，这些机构与个人都将OpenStack作为基础设施即服务资源的通用前端。OpenStack项目的首要任务是，简化云的部署过程并为其带来良好的可扩展性。本节通过提供必要的信息，帮助大家利用OpenStack前端来设置及管理自己的公有云或私有云。1.2.1 OpenStack设计原理和体系结构
在介绍OpenStack体系结构之前，需要先了解一下OpenStack的设计原则。
·可扩展性和伸缩性是设计OpenStack的主要目标。
·任何影响可扩展性和伸缩性的特性必须是可选的。
·一切应该是异步的（如果做不到异步，可参考第2条）。
·所有必需的组件必须可水平扩展。
·始终使用无共享架构或者分片架构（如果不能实现，可参考第2条）。
·一切都是分布式的（尤其应该将业务逻辑与业务状态放在一起）。
·接收最终一致性，并在适当条件下使用。
·测试一切（我们需要测试已经提交的代码，如果用户需要，我们将会帮助用户测试）。
OpenStack是由一系列具有RESTful接口的Web服务实现的，是一系列组件服务的集合。如图1-6所示是一个标准的OpenStack架构。这是比较典型的架构，但不代表这是OpenStack的唯一架构，我们可以选取自己需要的组件项目，来搭建适合自己的云计算平台。图1-6 OpenStack架构
OpenStack项目并不是单一的服务，其含有子组件，子组件内由模块来实现各自的功能。通过消息队列和数据库，各个组件可以相互调用，互相通信。这样的消息传递方式解耦了组件、项目间的依赖关系，所以才能灵活地满足用户实际环境的需要，组合出适合用户的架构。每个项目都有各自的特性，大而全的架构并非适合每一个用户，如Glance在最早的A、B版本中并没有实际出现应用，Nova可以脱离镜像服务独立运行。当用户的云计算规模大到需要管理多种镜像时，才需要像Glance这样的组件。OpenStack的成长是在生产环境中不断被检验，然后再将需求反馈给社区，由社区来实现的一个过程。可以说，OpenStack并非脱离实际的理想化开源社区项目，而是与生产实际紧密结合的，是可以复制应用的云计算方案。
OpenStack覆盖了网络、虚拟化、操作系统、服务器等各个方面。它是一个正在开发中的云计算平台项目，根据成熟及重要程度的不同，它被分解成核心项目、孵化项目，以及支持项目和相关项目。每个项目都有自己的委员会和项目技术主管，而且每个项目都不是一成不变的，孵化项目可以根据发展的成熟度和重要性转变为核心项目。下面列出了十几个核心项目（即OpenStack服务）截止到K版本。（1）计算（Compute）：Nova
一套控制器，用于为单个用户或使用群组管理虚拟机实例的整个生命周期，根据用户需求来提供虚拟服务。负责虚拟机的创建、开机、关机、挂起、暂停、调整、迁移、重启、销毁等操作，配置CPU、内存等信息规格。在K版本中，Nova做了以下优化：
1）标准化了conductor、compute与scheduler的接口，为之后的接口分离做好准备，对于部分直接访问Nova数据库的滤波器进行了优化，不再允许直接访问。
2）对scheduler做了一些优化，如scheduler对于每一个请求都会重新进行filter/weigher，为了优化这个问题，将filter/weighter的初始化从handler移到scheduler，这样，每次请求的时候都可以重新使用了。
3）更好地支持NFV功能，在NUMA（Non Uniform Memory Architecture）架构下，每个处理器都会访问“本地”的内存池，从而在CPU和存储之间有更小的延迟和更大的带宽。支持基于NUMA的调度的实现，可以将vCPU绑定在物理CPU上；并支持超大页。
4）用stackforge的EC1-API转换服务替代EC1-API的功能。（2）对象存储（Object Storage）：Swift
一套用于在大规模可扩展系统中通过内置冗余及高容错机制实现对象存储的系统，允许进行存储或者检索文件。可为Glance提供镜像存储，为Cinder提供卷备份服务。纠删码的加入应该是K版本中Swift最大的亮点，但是纠删码作为beta版本发布，并不推荐应用于生产环境。（3）镜像服务（Image Service）：Glance
一套虚拟机镜像查找及检索系统，支持多种虚拟机镜像格式（AKI、AMI、ARI、ISO、QCOW2、Raw、VDI、VHD、VMDK），有创建镜像、上传镜像、删除镜像、编辑镜像基本信息的功能。在K版本中，Glance开始提供自动进行镜像格式转化功能，例如，Ceph是使用RAW格式的，假如我们上传的是QCOW2，创建虚拟机时，就会经历一番上传下载的过程，速度异常缓慢。而且RAW格式通常都是原始大小，上传速度非常慢，完全可以通过上传小镜像将其自动转换为指定格式。（4）身份服务（Identity Service）：Keystone
为OpenStack其他服务提供身份认证、服务规则和服务令牌的功能，管理命令、项目、用户、组、角色。从J版本开始，Keystone增加了一个Keystone federation特性，有了这个特性，两个或者更多的云服务提供者就可以共享资源。在K版本中主要针对该功能进行了增强。（5）网络管理（Network）：Neutron
提供云计算的网络虚拟化技术，为OpenStack其他服务提供网络连接服务。为用户提供接口，可以定义网络、子网、路由器，配置DHCP、DNS、负载均衡、L3服务，网络支持GRE、VLAN。插件架构支持许多主流的网络厂家和技术，如OpenvSwitch。在K版本中，DVR支持OVS中的VLAN功能，新的V2版本的LBaas的API，同时支持一些高级服务（如L3、ML2、VPNaaS、LBaaS）的分离。（6）块存储（Block Storage）：Cinder
为运行实例提供稳定的数据块存储服务，它的插件驱动架构有利于块设备的创建和管理，如创建卷、删除卷，在实例上挂载和卸载卷。K版本中Cinder实现了服务逻辑代码与数据库结构之间的解耦，支持Rolling更新。在K版本中增加了一致性组（一致性组是指具备公共操作的卷，在逻辑上划为一组）的功能：可以添加、删除卷，从已经存在的快照创建新的组。（7）UI界面（Dashboard）：Horizon
Horizon OpenStack中各种服务的Web管理门户，用于简化用户对服务的操作，例如：启动实例、分配IP地址、配置访问控制等。Horizon在K版本中除了增强了对新增模块的支持，也从UE的角度带来了很多新功能，其中支持向导式的创建虚拟机，现在还处于beta版本，如果想在Horizon里激活，可以通过设置local_setting.py的配置实现；支持简单的主题，可通过修改_variables.scss和_style.scss完成对主题颜色和简单样式的修改，但是格局不能改变。（8）测量（Metering）：Ceilometer
它像一个漏斗一样，把OpenStack内部发生的几乎所有的事件都收集起来，然后为计费和监控以及其他服务提供数据支撑。在K版本中，Ceilometer支持Ceph对象存储监控，当对象存储为Ceph而不是Swfit的时候，使用Polling机制，使用Ceph的Rados Gateway的API接口获取数据。同时在K版本中支持更多的测量功能，包括Hyper-V、IPMI相关的。（9）部署编排（Orchestration）：Heat
提供了一种通过模板定义的协同部署方式，实现云基础设施软件运行环境（计算、存储和网络资源）的自动化部署。自Havana版本集成到项目中后，在K版本中变化较少。（10）数据库服务（Database Service）：Trove
为用户在OpenStack的环境提供可扩展和可靠的关系和非关系数据库引擎服务。自Icehouse版本集成到项目中后，在K版本中变化较少。（11）大数据服务BDaaS（BigData-as-a-Service）：Sahara
Sahara最初的基本定位是基于OpenStack提供简单的Hadoop集群创建方式，不过随着项目的不断演进，Sahara所涵盖的范畴也有所扩大。从服务层次的维度看，Sahara已经开始从利用OpenStack的IaaS能力，提供简单的大数据工具集群创建和管理服务，扩展到提供分析即服务（Analytic-as-a-Service）层面的大数据业务应用能力。从承载的业务类型维度看，Sahara也很有可能会迅速突破单一的Hadoop工具范畴，拓展支持其他新兴的大数据工具。（12）裸机管理：Ironic
OpenStack在虚拟化管理部分已经很成熟了，通过Nova可以创建虚拟机、虚拟磁盘，管理电源状态，快速通过镜像启动虚拟机。但是在裸机（物理机）的管理上一直没有成熟的解决方案。在这样的背景下Ironic诞生了，它可以解决物理机的添加、删除，以及电源管理和安装部署。Ironic最大的好处是提供了插件的机制，让厂商可以开发自己的驱动器，这让它支持几乎所有的硬件。在K版本中，Ironic完成了大量的优化工作：iLO的优化；使用Config Drive替代Metadata服务；全盘镜像支持，可以跳过raddisk和kernel，这样就可以部署Windows的镜像了；使用本地盘启动替代PXE方式，可以通过设置Flavor的capabilities：boot_option实现。1.2.2 OpenStack社区和项目开发流程
OpenStack是由开发商、企业、服务供应商、研究人员及用户共同组成的全球性的社区。关注OpenStack最好的方式就是访问OpenStack社区：www.openstack.org。通过社区可以第一时间了解OpenStack的动态。因此给出下面这些链接，希望可以帮助读者进一步了解OpenStack。
·OpenStack峰会：https://wiki.openstack.org/wiki/Summit
·OpenStack用户成员：https://wiki.openstack.org/wiki/OpenStackUsersGroup
·OpenStack在线会议：https://wiki.openstack.org/wiki/Meetings
·OpenStack邮件列表：https://wiki.openstack.org/wiki/MailingLists
·OpenStack IRC频道：https://wiki.openstack.org/wiki/IRC
·OpenStack维基：https://wiki.openstack.org/
·OpenStack博客：http://www.openstack.org/blog/category/newsletter/
·OpenStack资讯：http://planet.openstack.org/
·OpenStack Github：https://github.com/openstack
·OpenStack问题列表：https://ask.openstack.org/zh/questions/
相关代码库如下。
·核心项目Git库：http://git.openstack.org/cgit
·项目建设工具：https://github.com/openstack-infra
·开发人员工具：https://github.com/openstack-dev
代码提交和审查网站如下。
·代码review系统：https://review.openstack.org/
·代码合并建议：http://status.openstack.org/reviews/
·持续集成：http://status.openstack.org/zuul/
·用户和管理员文档：http://docs.openstack.org/
大家关心的还有：当对OpenStack有新的需求并且有开发意向时，如何把需求变为实实在在的OpenStack代码和项目。首先，我们得有一个想法，当一个新的想法逐渐成熟而且工作量非常大，以致无法在现有的某个OpenStack项目中承载时，就有必要成立一个独立的新项目进行开发。项目的发起者可以是一个人，但更有可能的是一群人。他们会发动开源社区，推广这个新项目，并吸引一批开发者共同开发。由这些开发者形成的团队会在OpenStack邮件列表上讨论问题，并定期召开日常例会。
在新项目成立早期，如果还没有PTL（ProgramTechnicalLead，技术领头人），团队内部会选举或指派一个领头人带领整个团队的开发，以及主持每期例会。由于该项目是开源的，就会源源不断地有新的开发者加入开发团队当中。同时，也会有人审视并吸收类似的开源项目，以避免做重复工作。逐步地，项目渐渐成熟，形成了自己的目标、计划和代码库。为了方便起见，项目发起者们一般会先将项目放在stackforge目录上。对于最初项目的版权，最好是APache2.0，这样就与OpenStack保持一致。当有一天新项目被集成到OpenStack发行版中时，也就不用重新定义和处理版权问题了。
当项目还是新项目时，它是在OpenStack项目之外开发的，这是该项目必须经历的一个阶段。在此阶段，项目发起者可以利用OpenStack项目使用的工具去管理该项目。一旦项目发起者认为该项目成熟了，就可以向技术委员会提出孵化请求，等待成为孵化项目的批转。
在一个项目被集成到OpenStack发布版之前，成为孵化项目是必经阶段。在这个阶段里，项目开发人员需要去了解OpenStack的发布节奏、发布流程，以及要成为集成项目还有哪些工作需要完成等内容。同时，也可以尽量寻求与其他项目合作或合并的机会。一般来说，这个阶段至少需要持续两个开发周期。在孵化期间，孵化项目都会被移植到OpenStack命名空间和目录中。在一个开发周期结束时，OpenStack技术委员会会对孵化项目做一个考核，理论上只有经历了两个开发周期的孵化项目才能被选为考核目标。考核的结果如果被证明是足够成熟的，并且已经准备好被集成到OpenStack发布版当中时，就会被选择从孵化期“毕业”成为OpenStack集成项目。在下一个开发周期里，该项目就正式成为集成项目，成为OpenStack家族的正式成员之一。
下面介绍一下核心项目的含义。核心项目的含义在2013年有所改变，那时OpenStack项目的管理刚被转交给OpenStack基金会。在此之前，所有被集成在OpenStack发布版中的项目都被称为核心项目，包括Nova、Swift、Glance、Cinder、Neutron、Horizon和Keystone。
此后，“核心”这个词变成了OpenStack基金会在OpenStack发布版里对某个项目进行标签的专有名词，“核心”的使用也就被限制了。可以这么说，核心项目是集成项目的一部分，是它的子集，当OpenStack基金会董事会认为某一个集成项目能达到某些要求时，就可以为该集成项目贴上“核心”这个标签。
在2013年之后，所有从孵化期毕业被集成在OpenStack发布版里的项目都统一称作集成项目，比如Cei1ometer、Heat和Trove都是集成项目，但Nova等7个项目，仍称为核心项目。1.2.3 OpenStack应用现状与发展趋势
OpenStack的潮流不可逆转。从2010年开始，OpenStack经过5年多的发展变得非常火热，由起步到成熟。2015年，IBM收购了OpenStack创业公司Bluebox，思科也收购了OpenStack创业公司Piston。更早些时候，美国领军的OpenStack公司Mirantis获得1亿美元的融资，Rackspace以OpenStack为基础的私有云业务每年盈利7亿美元，增长率超过了20%。这些都说明，作为开源开放的云平台，OpenStack在云计算时代成为了一股强大的力量，并将在未来云计算时代占据更加重要的位置。随着OpenStack的成熟和发展，越来越多的IT厂家开始关注OpenStack，并成为OpenStack的主流供应商。OpenStack目前的支持者都是世界顶级的供应商，可见OpenStack备受青睐。如表1-2所示，目前各领域知名的供应商对OpenStack都已有相应的支持。同时一些大的跨国电信运营商也开始在自己的生产环境中大规模部署OpenStack。表1-2 支持OpenStack的供应商
OpenStack目前处于高速发展阶段，从技术角度来讲，网络功能将是OpenStack未来几年的发展重点，Neutron的稳定性是OpenStack目前重点要解决的问题。Neutron以Quantum技术为基础，后者则源自Nicira的开发项目。随着Nicira被VMware收购，该公司的员工们也在新环境下继续对这项技术开展研发。Quantum项目的很多早期用户将其与Nicira的NSX插件配合使用，两者共同构建了Nicira公司的软件定义网络技术方案。一旦Neutron抛开NSX插件而独立运作，就会产生多种问题。而且Neutron的问题只在大型规模环境中才会出现，很多仅把OpenStack用于小规模生产部署环境的使用者对这一切却毫无察觉，这也导致了很多厂家对OpenStack的网络组件进行重新编写，以保证其云方案能够正常运作。目前OpenStack社区正在全力完善Neutron功能，如图1-7所示。很明显，OpenStack最早的几大核心模块（Nova、Cinder、Glance、Keystone、Horizon、Swift）的代码贡献所占比例呈明显下降趋势，如Nova从Havana版本的24%下降到Kilo的10%。这从一个侧面反映了OpenStack的核心模块日趋稳定，更多的关注集中到更高层次或者功能优化上。Neutron模块则一直处于稳中有升的状态，从Havana版本的7%上升到Kilo的10%，这说明OpenStack社区目前正处在全力完善Neutron的状态。图1-7 OpenStack各项目代码贡献量对比
OpenStack与OpenDaylight的融合是目前OpenStack的另一个发展重点。OpenDaylight是一个SDN控制器的开源项目，它与OpenStack配合紧密。OpenDaylight项目的第一批代码于2013年第三季度发布，项目包括开放控制器、虚拟覆盖网络、协议插件和交换设备改进等。很多公司和组织提出贡献自己的技术或者考虑开源化关键技术，OpenDaylight技术指导委员会（TSC）将对这些技术进行审核，再决定是否纳入该项目中。如图1-8所示是OpenDaylight的架构，是一个可插拔的控制器平台，它提供北向Neutron的API（OpenDaylight的RESTful API）。OpenDaylight已经推出Helium版本，新版Helium也与OpenStack更深度整合，包括改善了Open vSwitch程序库整合项目（Open vSwitch Database Integration Project）在网络上的管理，并也提供了多项OpenStack功能的技术预览方案，如安全群组（Security Groups）、分散式虚拟路由器（Distributed Virtual Router），以及负载平衡即服务（Load Balancing-as-a-Service）等，可弹性运用于网络管理和安全服务上。图1-8 OpenDaylight架构
高性能、高可靠的云计算架构环境是OpenStack追求的另一个方向。2014年，OpenStack推出Juno版本，开始支持NFV功能。电信行业的运营商和服务商一直在持续关注OpenStack的发展，2014年，众多电信运营商、电信设备商和IT厂商共同发起并成立了OpenNFV开源组织，旨在为NFV提供基于开源软件的、电信级的NFV参考平台。在电信高性能、5个9的高可靠性需求推动下，OpenStack与底层KVM在NUMA亲和性调度、Huge Page配置、SR-IOV等技术层面，以及与Docker技术的结合应用正在被加速。1.3 OpenStack入门体验1.3.1 初探OpenStack
由于OpenStack安装过程时间较长且复杂，并且构建不同的云环境可以选择各种各样的排列组合方式，为了避免初学者在较长时间的安装过程中失去对OpenStack探索的热情，我们先来认识一下OpenStack的用户界面，以便对它有个感性认识。
OpenStack的用户界面由两部分组成：一是Web界面，二是Shell界面。Horizon负责展现Web仪表盘，用户可以通过浏览器直接操作、管理、运维OpenStack的一些功能。由于OpenStack项目队伍不断壮大，Dashboard并不能展现所有的OpenStack功能，因此，最新的功能一般会先开发Shell命令行，也就是将CLI（Command Line Interface）提供给Linux用户操作。
通过浏览器输入仪表盘的地址，可以看到如图1-9所示的OpenStack登录界面。OpenStack仪表盘可以安装在任意节点处，通常将其安装在Nova API的管理节点处，以方便访问。Horizon与nova-client一样，需要Keystone的用户名及密码认证，以及Keystone的Token进行授权才能访问。这些都是在Horizon内部实现的，普通用户只要有用户名及密码就能登录仪表盘进行日常操作。这里，先登录OpenStack的仪表盘，为了方便演示，可使用admin用户。图1-9 OpenStack登录界面
登录控制面板，可以发现有管理员视图（仅管理员可见）和项目视图（仅可以操作当前用户被授权的项目）。目前的仪表盘已经进行了国际化，中国用户可以使用熟悉的中文来管理“云”。管理员用户可以从整体视角来观察“云”的一举一动，可以看到整个资源池的大小状况及健康状况。如果资源不够用，那么可以以人工方式进行干预。目前，因为OpenStack的Auto Scaling还不尽如人意，所以一些工作只能通过人工干预的方式进行。
OpenStack界面的左侧是导航栏，如图1-10所示。在OpenStack的图标下可以看到两个选项：项目和管理员。这两个选项下面分别有各自的服务菜单。项目选项可以从概览（Overview）、实例（Instance）、卷（Volume）、镜像和快照（Image&Snapshots）、访问和安全（Access&Security）几个方面来管理“云”。管理员选项下有概览、实例、卷、套餐（Flavor）、镜像（Image）、项目（Project）、用户（User）、系统信息（System info）。项目选项和管理员选项中的内容有交叉，但是这些是从不同角度去观察“云”所得到的结果。在“云”环境中，很多时候需要从不同的角度去观察。从多角度观测，才能得到想要的全部信息。图1-10 OpenStack界面1.3.2 创建OpenStack虚拟机实例
在Dashboard左侧导航栏中，选择“项目”→Instances，然后单击Launch Instance，便可通过图形界面方式来创建虚拟机，如图1-11所示。图1-11 创建虚拟机界面
当单击Launch Instance时，会弹出模态窗口，在此可进行创建实例的具体配置，包括实例的细节（Detail）、访问和安全（Access&Security）、磁盘配置（Volume Option），以及实例启动后的自定义初始化脚本（Post-Creation）。
实例细节的配置包括了实例的来源类型（镜像文件或快照文件）、镜像模板、实例名、套餐、创建实例个数。右侧还列出了更详细的信息，供管理员3种当前实例的创建对整个项目有何影响。
访问和安全包括虚拟机SSH密钥的设置及安全组的设置。磁盘配置可以让用户选择是否在卷存储上进行虚拟机的启动引导（Boot）。自定义初始化脚本主要是实例在启动后，可以运行一些用户自定义的脚本。除了实例的细节设置，如果没有特殊需求，其他设置默认即可。当确认一切设置无误后，可以单击Launch按钮进行实例创建。
创建OpenStack虚拟机实例前有很多先决条件，如Horizon本身能正常运行并对外提供创建服务；建立在OpenStack三个核心组件之上等。这3个核心组件是Keystone、Glance、Nova。Keystone负责授权认证、租户管理、项目权限和配额以及服务目录管理。Glance负责为Nova提供创建实例所需要的镜像文件，这种镜像文件可以包含很多格式，大多数都是常见的镜像格式，如raw、qcow2。Nova负责虚拟机生命周期的管理，以及宿主机资源调度。Nova还决定了虚拟机实例建立在哪一台Hypervisor物理机之上。由这3个核心组件协作，Horizon将用户的HTTP请求转换为RESTful请求，然后将RESTful请求分发给Nova API，进行实例创建。当创建后，虚拟机实例会进入Build状态，任务状态将是Spawning。这期间会将镜像文件从Glance下载到Nova节点，并进行一些虚拟机的配置。当一切正常后，虚拟机将会进入Active状态，此时用户可以享受“云”带来的便捷。创建所需的时间一般由创建实例的镜像文件大小、传输镜像图带宽，以及创建的Hypervisor磁盘性能来决定。有时创建过程会持续5~10min。
Horizon并不是唯一可以管理虚拟机的用户界面。OpenStack还有基于Python的CLI，虚拟机创建之后可以通过nova-client进行管理。通过命令行输入Nova list，可以看到所有OpenStack实例的运行情况，以及实例相应的信息。后面在讲解Nova组件时，将详细讲解各种命令的操作及命令之间的关联关系，以及如何实现自定义命令、命令行扩展，还有如何运用好一系列OpenStack命令来进行日常的管理、运维操作。
当虚拟机创建成功后，双击虚拟机名，进入这个虚拟机视图进行详细观察，如图1-12所示。可以看到标签页，包括概览（Overview）、日志（Log）、控制台（Console）。概览中可以看到虚拟机的一系列详细信息。日志中可以看到虚拟机当前的启动引导日志，不用登录虚拟机就可以看到虚拟机的引导情况，可检查是否有错误或者异常发生。通过控制台界面可以对虚拟机进行操作。这是一个VNC控制台，不必像以前使用虚拟机那样，登录到Hypervisor端配置VNC端口信息，然后再通过VNC Client登录管理虚拟机。OpenStack将这些日常操作抽象出来，进行自动化，整个过程无须用户进行任何配置，当构建好OpenStack云后，剩下的事就交给OpenStack来做。图1-12 虚拟状态展示
单击More按钮，可以进行更多的操作，可以对虚拟机实例进行一些操作，这些操作包括启动、停止、挂起、激活、快照、迁移、备份、诊断、恢复、重建、销毁等一系列虚拟机生命周期管理。这些操作都由Nova提供，部分操作会有其他组件参与。对于OpenStack这样的一个分布式系统，完成一件事，基本上都会涉及一系列的组件。这些组件协同工作，在“云”中扮演着各种角色。之后我们将具体探讨这些组件在OpenStack中扮演什么样的角色，哪些组件必不可少，以及如何通过各种组件的排列组合来组建合适的“云”。1.3.3 创建虚拟机的流程概述
创建虚拟机的步骤如下：
1）Horizon通过Keystone获取Compute组件的访问地址（URL），并获取授权令牌（Token）。
2）携带授权令牌，发送创建虚拟机指令，如图1-13和图1-14所示。
3）nova-compute组件通过glance-api下载虚拟机镜像，Glance镜像中有缓存机制，通常将缓存文件放入名为_base的目录中（base缓存），如图1-15所示。镜像分两个阶段，第一个阶段是：如果base缓存中没有此次的虚拟机镜像文件，则从Glance下载镜像到base缓存；第二个阶段是：从base缓存复制到本地镜像目录。base缓存可关闭，默认为开启。建议不要修改此默认值，因为如果每次镜像都通过Glance下载，会消耗大量的网络带宽。base缓存的存在就是为了解决虚拟机镜像文件传输消耗带宽的问题。图1-13 创建虚拟机的流程1图1-14 创建虚拟机的流程2图1-15 创建虚拟机的流程3
4）Glance检索后端镜像，Glance后端存储不一定要使用Swift，只要能存放镜像的文件系统就可以，如图1-16所示。
5）获取网络信息，决定虚拟机网络模式及建立网络连接，如图1-17所示。
6）nova-compute发送启动虚拟机指令，如图1-18所示。图1-16 创建虚拟机的流程4图1-17 创建虚拟机的流程5图1-18 创建虚拟机的流程6
至此，虚拟机创建完成。第2章 计算管理（Nova）2.1 概述
Nova是一套控制器，用于为单个用户或使用群组启动虚拟机实例。OpenStack Compute在公有云处理方面堪与Amazon EC2相提并论；而在私有云方面也毫不逊色于VMware的产品。在公有云中，这套管理机制将提供预制的镜像、为用户创建的镜像提供存储机制，这样用户就能够将镜像以虚拟机的形式启动。
OpenStack中实例的整个生命周期中的所有行为都由Nova处理，Nova管理计算资源的创建、销毁、挂起、迁移等各种功能。但是Nova自身并不提供任何虚拟化能力，而是使用支持Hypervisor的API来提供。Nova支持两套API接口来暴露其功能，一套是其自定义的API接口，另一套是兼容EC1-API的接口。
Nova含有多个组件，而且根据不同版本组件有不同的变化。常见的有nova-api（一个HTTP服务，用于接收外部发送的请求），nova-compute（Nova核心服务，处理实例的创建、销毁、启动、暂停等生命周期管理），nova-scheduler（Nova调度服务，决定nova-api收到的请求，往哪个nova-compute上转送），nova-conductor（G版本开始增加的服务，主要是封装了数据库操作，作为Nova组件访问数据库的中间层，解决其他组件和数据库的耦合问题），nova-cert（管理证书，用于兼容AWS），nova-console、nova-consoleauth、nova-vncproxy（这3个是负责实例控制台输出服务），nova-objectstore（模拟对象存储接口，用于在实验环境中存储镜像，在D版本中被Glance替代），nova-volume（卷管理服务，现在被Cinder替代），nova-network（Nova网络管理服务，现在被Neutron替代，但是由于Neutron过于复杂和不稳定，在一个简单的环境中，往往nova-network更有用）。
随着OpenStack的发展，Nova本身也发展得较为臃肿，但是无论怎么演进，其基本运行原理是一致的。老版本的Nova运行更简单明了，为了将Nova的运行原理描述得更清楚一些，本章的有些内容基于老版本的Nova来讲解。2.2 逻辑架构
Nova逻辑架构中，组件中的绝大多数可分为两种自定义编写的Python守护进程：
1）接收和协调API调用的WSGI应用（nova-api、glance-api等）。
2）执行部署任务的Worker守护进程（nova-compute、nova-network、nova-scheduler等）。
然而，Nova中还有两个重要的部分，既不是自定义编写的，也不是基于Python的，它们是消息队列和数据库。两者简化了复杂任务（通过消息传递和信息共享的任务）的异步部署。Nova的逻辑架构如图2-1所示。图2-1 Nova逻辑架构2.3 物理架构
Nova采用无共享、基于消息的架构，非常灵活，可将每个nova-service安装在单独的服务器上，这意味着安装Nova有多种可能的方法，可多节点部署。部署OpenStack过程中唯一的联合依赖性是Dashboard必须被安装在nova-api服务器上。Nova的几种部署架构如下。（1）单节点
一台服务器运行所有的Nova服务，同时也驱动虚拟实例。这种配置只为尝试Nova或者开发目的。（2）双节点
一个云控制器节点运行除nova-compute外的所有Nova服务，Compute节点运行nova-compute。这种配置主要用于对概念和开发环境的证明。（3）多节点
通过简单部署nova-compute在一台额外的服务器以及拷贝nova.conf文件到这个新增的节点上，可在两节点的基础上，添加更多的Compute节点，形成多节点部署。在较为复杂的多节点部署中，还能增加一个卷控制器和一个网络控制器作为额外的节点。对于运行多个虚拟机实例的环境，至少需要4个节点。
一个可能的OpenStack计算多服务器部署（集群中联网的虚拟服务器可能会改变）如图2-2和图2-3所示。图2-2 多服务器部署架构一
如果发现消息队列中大量的复制引发了性能问题，一种可选的架构是增加更多的Messaging服务器。在这种情形下，除了可以扩展数据库服务器外，还可以增加一台额外的RabbitMQ服务器。只要nova.conf中配置其指向的RabbitMQ服务器，并且这些服务器能向它发送消息。图2-3 多服务器部署架构二2.4 对主流Hypervisor的支持架构
nova-compute运行在计算节点上，通过插件形式对Hypervisor进行管理，当前的版本，对各种主流的虚拟化平台都提供了支持，典型地通过XenAPI/vCenter API/Libvirt等所提供的插件接口执行虚拟机创建、终止、迁移等生命周期管理。异构Hypervisor支持架构如图2-4所示。图2-4 异构Hypervisor支持架构2.5 与VMware的对接
Nova与VMware的对接有两种方式，一种是nova-compute直接对接ESXi，此种方式和传统方式无异。这种方式的缺点是，丧失了VMware原先具备的很多高级功能，如FT、DRS、VMotion等。
为解决此问题，VMware推出了一个新的方案，nova-compute直接对接vCenter，为此，VMware提供了一个新的插件Driver给nova-compute，以便支持接入vCenter。此种接入方式的优点是，保留了传统vSphere平台所具备的许多高级特性。
Nova与vSphere的对接架构如图2-5所示。图2-5 Nova与vSphere的对接架构
这种架构对vSphere的版本有要求，至少是vSphere 4.1版本以上。另外，这种对接方式使得Nova原来支持的某些特性也将丧失。
1）不支持临时存储，传统的Nova虚拟机会在Host上临时分配一块空间，作为系统盘，以及SWAP交换分区，VM销毁时此临时存储也销毁。
2）不支持在虚拟机中植入SSH密钥。
试读结束[说明：试读内容隐藏了图片]