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技术的结合应用正在被加速。