第1章
OpenStack简介

1.1 OpenStack概述

OpenStack是当今最流行的开源云平台管理项目，可以控制整个数据中心计算、存储和网络资源的大型资源池。从OpenStack的名字可以看出它大致的含义，Open顾名思义为开源软件，开放式的设计理念、开放式的开发模式、开放式的社区，Stack意为堆，可以理解为云计算是靠每一块小瓦砾堆砌而成。OpenStack并不是单独的一个软件，它由多个组件一起协作完成某些具体工作。OpenStack本身就是一个巨大的开源软件集合，集各种开源软件之大成。当你想寻找AWS EC2的替代品时，OpenStack将是一个不错的选择。

云计算的概念并不是很新。实际上，AWS EC2已经出现有7年左右。虽然OpenStack是如今最为流行的一种可用的开源云计算解决方案之一，但它不是最早的一个。它是在公共和私有领域开发的两种旧解决方案的综合。

OpenStack是一个非常年轻的开源项目，最初是由美国国家航空航天局（NASA）和Rackspace合作研发的项目，2010年7月以Apache 2.0许可证授权开源，源代码来自于NASA的Nebula云平台和Rackspace的分布式云存储（Swift）项目。NASA最初使用的是Eucalyptus云计算平台，当规模持续快速增长后，Eucalyptus已经不能满足NASA的云计算规模，而Eucalyptus是不完全开放源代码的（“开放核”模式）。NASA首席技术官Chris Kemp的研究小组为此专门建立了自己的计算引擎，新平台命名为Nova，并将其开源。在2010年NASA和Rackspace分别将Nova和Swift项目代码开源时，已经获得了25个企业和组织的支持。

OpenStack致力于一个开放式设计过程，每6个月开发社区就会举行一次设计峰会来收集需求并写入即将发布版本的规格中。设计峰会是完全对公众开放的，包括用户、开发者和上游项目。社区收集需求和制定经过批准的线路图，用于指导未来6个月的发展。

OpenStack使用Apache 2.0许可证，兼容GPLv3以及DFSG。

下面来了解一下OpenStack的优势和劣势。

OpenStack的优势：

· 解除厂商绑定。

· 具有可扩展性及很好的弹性，可定制化IaaS。

· 良好的社区氛围。

OpenStack的劣势：

· 入手难、学习曲线较高，在对整体把握不足的情况下，很难快速上手。

· 偏底层，需要根据实际应用场景进行二次开发。

· 现阶段的厂商支持较弱，商业设备的OpenStack驱动相对不够全面。

1.2 OpenStack的结构

OpenStack包含了许多组件。有些组件会首先出现在孵化项目中，待成熟以后进入下一个OpenStack发行版的核心服务中。同时也有部分项目是为了更好地支持OpenStack社区和项目开发管理，不包含在发行版代码中。

OpenStack的核心服务包括：

· Nova计算服务（Compute as a Service）

· Neutron网络服务（Networking as a Service）

· Swift对象存储服务（Object Storage as a Service）

· Cinder块存储服务（Block Storage as a Service）

OpenStack的公共服务包括：

· Glance镜像服务（Image as a Service）

· Keystone认证服务（Identity as a Service）

· Horizon仪表盘服务（Dashboard as a Service）

OpenStack的依赖库项目包括：Oslo基础设施代码共享依赖库（Common Lab as a Service）。

OpenStack的孵化项目包括：

· Ceilometer计费&监控服务

· Heat编排服务

· Ironic物理设备服务（Bare Metal as a Service）

· Marconi消息队列服务（Message Queue as a Service）

· Savanna大数据处理（MapReduce as a Service）

· Trove数据库服务（DataBase as a Service）

OpenStack的其他项目涉及：

· Infrastructure OpenStack社区建设项目

· Documentation OpenStack文档管理项目

· TripleO OpenStack部署项目

· DevStack OpenStack开发者项目

· QA OpenStack质量管理项目

· Release Cycle Management版本控制项目

这些OpenStack项目有一些共同点，比如：

· OpenStack项目组件由多个子组件组成，子组件有各自的模块。

· 每个项目都会选举PTL（Project Technical Leader）。

· 每个项目都有单独的开发人员和设计团队。

· 每个项目都有具有优良设计的公共API，API基于RESTful，同时支持JSON和XML。

· 每个项目都有单独的数据库和隔离的持久层。

· 每个项目都可以单独部署，对外提供服务，也可以在一起协同完成某项工作。

· 每个项目都有各自的后端驱动，所有的驱动都可以以plugin方式加载。

· 每个项目都有各自的client项目，如Nova有nova-client作为其命令行调用RESTful的实现。

除了以上项目，OpenStack的其他项目或多或少也会需要Database（数据库）、Message Queue（消息队列）进行数据持久化、通信。

1.3 OpenStack的功能与作用

当今的数据中心，许多服务器都遇到过同样的问题，即计算、电源、网络带宽等资源利用率不足。例如，某个项目可能会需要大量计算资源来完成计算，而一旦完成了计算任务，将不再需要那么多的计算资源。当用户想要一种灵活的、按需供给计算资源的服务，通过自动化或很少人工干预就能使用时，那么云计算就是最好的选择之一。“云计算”通常包含了一个服务责任（Service Level Agreement，SLA），表示云计算服务提供商承诺的性能、规格、可用率等。云计算服务让用户通过一个共享的计算资源、网络带宽、存储池，运行应用程序或服务来完成计算工作，并按资源的使用量来计费。

这些关于云计算服务的主要特点如下。

●按需自助服务：用户可以提供自己的需要订购所需的计算、存储和网络资源，而几乎不需要人工干预。

●网络访问：可以通过网络使用任意类型的（异构）计算能力。通过标准化的机制调用计算资源而不受限于具体的访问设备。

●资源池：多个用户可以同时访问和使用云计算提供的计算服务，服务提供商根据消费者的计算要求或实际使用量汇集和分配实际的计算资源。

●弹性：可根据需要在不停机或短暂停机后迅速垂直或横向扩展。

●计量或测量服务：按照使用的时间、传输或存储的字节数支付云计算服务，并提供消费者具体的资源消费图表。同时，它也可以根据消费者的不同需求提供定制化的计费模式。

下面了解一下当今的IaaS/Cloud与OpenStack的对比情况，从而进一步了解OpenStack的特点，见表1-1。

当今的云计算概念是由Google公司提出的，狭义的云计算是指IT基础设施的交付和使用模式，按需取用所需的IT资源；广义的云计算是指服务交付和使用模式，通过网络按需取用所需的服务，这种服务可以是IT、软件、互联网相关的，也可以是其他服务。它具有超大规模、虚拟化、可靠安全、弹性等特性。通过SaaS（Software as a Service）、PaaS（Platform as a Service）、 IaaS（Infrastructure as a Service）提供从上到下不同层面的云计算服务。

云计算（Cloud Computing）是网格计算（Grid Computing）、分布式计算（Distributed Computing）、并行计算（Parallel Computing）、效用计算（Utility Computing）、联机存储技术（Network Storage Technology）、虚拟化（Virtualization）、负载均衡（Load Balance）等一系列传统计算机技术和网络技术发展融合的产物。它旨在通过网络将多个成本低廉的计算实体整合成一个大型计算资源池，并借助SaaS、PaaS、IaaS等服务模式，将强大的计算能力分发到终端用户手中。云计算的核心理念就是通过不断提高“云”端处理能力，减轻用户负担，将一系列的IT能力以服务形式提供给用户，简化用户终端的处理负担，最终使用户成为一个单纯的输入/输出设备，享受“云”提供的强大计算处理及服务能力。

OpenStack具有建设这样资源池的能力，通过OpenStack的各种组件多种模式的排列组合，可以搭建成各种规模的“云”，这些云可以是私有云、公有云、混合云。

OpenStack具有三大核心功能，即计算、存储、网络，分别对应相应的项目Nova、Cinder。其中Neutron。其中Nova提供了计算资源的管理，可以管理跨服务器网络的VM实例。同时，Nova还提供对多种Hypervisor的支持，如KVM、QEMU、Xen、LXC、 VMware、Hyper-V、PowerVM等。Cinder提供了存储资源的管理，可以管理各个厂商提供的专业存储设备。Neutron提供了网络资源的管理，并且LBaaS、FWaaS等一系列网络相关的组件也正在逐渐发展起来。

1.4 OpenStack与CloudStack的比较

OpenStack并不是唯一的开源基础设施服务，在谈论OpenStack的时候用户一定会拿CloudStack与之相对比。对比OpenStack和CloudStack这两个云计算产品，有助于了解它们两者的本质。它们的每一个设计都具有相同的目标，即提供一套开源组件，利用各个组件的必要功能来管理云中成千上万的单台服务器，两者都旨在成为构建私有云、公有云的云资源服务提供者。

OpenStack和CloudStack具有相似的功能组件，如计算、网络、存储。计算方面，都支持将虚拟机分配到单独的服务器，管理协调计算资源的使用。网络方面，提供虚拟、物理网络管理功能，包括虚拟交换机创建和管理虚拟机网络。存储方面，分别含有对象和块存储系统、镜像管理功能和云计算管理接口这些组件。虽然这两者有共同的目标，并具有相似的基本功能，但其历史和项目的组织是不同的。

1.OpenStack历史

2010年，美国国家航空航天局联手Rackspace，在建设美国国家航空航天局的私有云过程中，创建了OpenStack项目，之后他们邀请其他供应商提供组件，建立一个完整的开源云计算解决方案。

2010年诞生的第一个版本Austin只包含Rackspace和美国国家航空航天局的组件。之后发布的版本包含了已加入该项目的供应商开发的附加组件。最初，Rackspace独立管理OpenStack项目，随着OpenStack的不断发展，在2012年创建了OpenStack基金会，该基金会由选举产生的董事会监管。OpenStack的技术委员会由每个核心的软件项目和项目领导等组成。

目前，Openstack.org有声称来自87个国家或地区的850个基金会成员。白金会员提供最高水平的支持，其次是黄金会员、赞助企业和个人会员。当前，白金会员有AT&T、HP、IBM和Rackspace等公司或组织；黄金会员有思科、戴尔、VMware等公司。开源协议是Apache 2.0。OpenStack代码可免费下载。

2.CloudStack历史

CloudStack始于Cloud.com，其目标是使服务供应商和企业创建、运营其能力类似于亚马逊公司的公有云、私有云。2010年，Cloud.com提供了基于GPLv3的社区版本，供用户免费下载，并随后发布了两个支持版本。

思杰（Citrix）公司在2011年7月收购了Cloud.com。思杰公司是OpenStack社区早期成员之一，但在2012年决定离开OpenStack社区。据媒体报道，做出这一决定是因为思杰公司认为，最初由Cloud.com提供的代码相比OpenStack更稳定，可为用户提供更多的功能。

2012年4月，思杰公司提交了Cloud.com的代码给Apache软件基金会，现在在Apache基金会的Apache 2.0许可证下进行代码开发，思杰公司将继续提供版本支持及解决方案支持。由于过渡到了Apache，其他厂商也纷纷加入到了开发队伍，增加功能和增强核心软件。

还有一点不同是，OpenStack的基金会中会有供应商的名单，不同于CloudStack的发布者名单。因为Apache基金会负责了大量的项目，而Apache项目成员均以个人名义被列入，而不是他们所代表的公司。

在Apache项目中，由感兴趣的公司制定独立工作人员的工作项目。当前，CloudStack项目成员中有一些思杰公司的员工和一些目前不太知名的公司，如Sungard、Schuberg Philis、TCloud Computing和EPAM Systems等。项目的发展方向由个别参与者所代表的雇主的意愿来决定。

3.OpenStack与CloudStack历史对比

Cloud.com致力于开发和发展一个更大的开源云社区。因此，大部分CloudStack的核心组件由Cloud.com开发，然后由思杰公司增强。

相比之下，OpenStack项目从最开始就发展开放社区，其直接结果是，OpenStack里聚集了比CloudStack更多的主流供应商。在大多数情况下，这些厂商开发的组件第一时间提供给OpenStack，之后才为CloudStack提供接口。

此外，思科和Nicira公司已经成为OpenStack网络组件Neutron的主要开发者。Neutron接收来自虚拟机的指令来定义虚拟机所需要的网络，然后发送指令给交换机和路由器来创建这些网络。现在，思科和Nicira公司已经写完了OpenStack的网络模块，正在为CloudStack做同样的适配。

每个交换机的供应商必须为Neutron提供插件。这个插件在Neutron中转换为特定厂商设备的特定命令语法。Extreme Networks和Brocade这两个OpenStack基金会成员同样先为OpenStack提供插件，再进行CloudStack支持。

OpenStack为分布式组件模式，可以选择性地部署需要的组件，如网络组件Neutron、块存储组件Cinder、计算组件Nova，按需部署，按需取用。相比之下，CloudStack是一个可插拔式的模型，通过可插拔模型来实现SDN、IP分配、LBaaS、防火墙、VPC、Vxlan等，而这些功能OpenStack也都支持。

OpenStack和CloudStack支持的虚拟机Hypervisor也基本类似，同样支持KVM、XenServer、VMware，不同的是，OpenStack还支持Hyper-V、PowerVM、LXC via libvirt、Baremetal、QEMU、Docker。

OpenStack也有不够完善的地方，如OpenStack相对于CloudStack来说更加复杂，对终端用户的支持不够；在安装部署上不如CloudStack便捷；在界面显示方面也不如CloudStack丰富。

要确定企业的合适部署，就必须仔细对比每一个解决方案，然后再进行选择。思杰公司向大型服务供应商、大学以及其他机构展现了CloudStack的成熟和稳定。而要关注OpenStack的稳定性可以查看IBM、戴尔和Rackspace等公司的解决方案。这两款产品一直在持续发展，提供了一系列的存储和网络的选项。随着OpenStack Icehouse的发布，OpenStack拥有了不错的3层网络支持。以前，CloudStack一直宣称有与亚马逊公司的EC3更好的兼容性，但OpenStack在这一领域的能力已明显提高。企业必须确定它们的实际要求，再仔细检查每一个解决方案是如何满足它们的需求的。虽然两者都支持一些广泛使用的虚拟机管理程序，但是企业仍然需要评估哪一个提供了最需要的虚拟机管理程序支持，以及哪个方案对现有的网络设备、存储设备和服务器设备提供了较好的支持。另外，还可以向正在使用产品的集成商或VAR询问他们的具体经验与解决方案中的一个或两个。确保考虑了上述所有这些因素，才会让客户做出最终的正确选择。

1.5 OpenStack应用现状和发展趋势

通过trends.google.com，可以整理出目前人们对一些开源云计算项目的关注趋势。Rackspace以OpenStack为基础的私有云业务每年7亿美元，增长率超过了20%。

如图1-1所示，在开源云计算项目领域，OpenStack从2010年开始就已经超过CloudStack、Eucalyptus、OpenNebula等其他云计算开源项目，是当今最热门的开源项目之一，这离不开社区管理者和社区推广者的努力。

在云计算领域，OpenStack也在逐渐追赶虚拟化商业巨头VMware的步伐。OpenStack和其他商业云项目的趋势对比如图1-2所示。我们有理由相信，在今后几年乃至相当长一段时间里，OpenStack依然会活跃在大家的视线中。OpenStack社区活跃度如图1-3所示。

相比开源项目的“前辈”，OpenStack是一个更高级且更现代化的开源项目，因为它是高度协作的产物。

OpenStack的支持者都是世界顶级的供应商，可以看出OpenStack备受青睐，可以说它是开源界的明星产品。目前，该领域世界排名前三的供应商对OpenStack都已有相应的支持，见表1-2。

目前OpenStack的实现对于完整云计算所需组件的支持情况见表1-3。

1.6 体验OpenStack

1.6.1 初探OpenStack

由于OpenStack安装过程时间较长且复杂，并且构建不同的云环境可以选择各种各样的排列组合方式，为了避免初学者在较长时间的安装过程中失去对OpenStack的探索热情，因此，我们先来认识一下OpenStack的用户界面，从感官角度来见识一下它。

OpenStack的用户界面由两部分组成：一是Web界面，二是Shell界面。Horizon负责展现Web仪表盘，用户可以通过浏览器直接操作、管理、运维OpenStack的一些功能。由于OpenStack项目队伍不断壮大，Dashboard并不能展现所有的OpenStack功能，因此，最新的功能一般会先开发Shell命令行，也就是将CLI（Command Line Interface）提供给Linux用户操作。

通过浏览器输入仪表盘的地址，可以看到如图1-4所示的登录界面。OpenStack仪表盘可以安装在任意节点，我们通常都将其安装在Nova API的管理节点，以方便访问。Horizon和Nova-Client一样，需要Keystone的用户名及密码认证，以及Keystone的Token进行授权访问。这些都是Horizon内部实现的，普通用户只要有用户名及密码就能登录到仪表盘中进行日常操作。让我们先登录到OpenStack的仪表盘中，为了方便演示，使用admin用户。

登录到控制面板，可以发现有管理员视图（仅管理员可见）和项目视图（仅可以操作当前用户所授权的项目）。目前的仪表盘已经进行了国际化，可以使用熟悉的中文来管理“云”。管理员用户可以从整体视角来观察“云”的一举一动，可以看到整个资源池的大小状况，以及健康状况。如果资源不够使用，那么可以以人工方式进行干预。目前，因为OpenStack的Auto Scaling并不尽如人意，所以一些工作只能通过人工干预的方式进行。

OpenStack的仪表盘左侧是导航栏，如图1-5所示。在OpenStack的图标下可以看到两个维度：项目和管理员。这两个维度下面分别有各自的服务菜单。项目维度可以从概览（Overview）、实例（Instances）、卷（Volumes）、镜像和快照（Image&Snapshots）、访问和安全（Access&Security）几个方面来管理“云”。管理员维度有概览（Overview）、实例（Instances）、卷（Volumes）、套餐（Flavors）、镜像（Images）、项目（Project）、用户（Users）、系统信息（System info）。项目维度和管理员维度内容有交叉，但是这些是从不同角度去观察“云”所得到的结果。在“云”环境中，很多时候需要从不同的维度去观察。从多维角度观测，才能得到想要的全部信息。

1.6.2 创建OpenStack虚拟机实例

在Dashboard左侧导航栏中，选择“项目”→“Instances”，然后单击“Launch Instance”，可完全通过图形界面方式来创建虚拟机，如图1-6所示。

当单击“Launch Instance”时，会弹出模态窗口，在此可进行创建实例的具体配置，具体包括实例的细节（Details）、访问和安全（Access&Security）、磁盘配置（Volume Options），以及实例启动后的自定义初始化脚本（Post-Creation）。

实例细节的配置包括了实例的来源类型（镜像文件或快照文件）、镜像模板、实例名、套餐、创建实例个数。右侧还列出了更详细的信息，供管理员参考当前实例的创建对整个项目有何影响。

访问和安全包括虚拟机SSH密钥的设置及安全组的设置。磁盘配置可以让用户选择是否在卷存储上进行虚拟机的启动引导（boot）。自定义初始化脚本主要是实例在启动后，可以运行一些用户自定义的脚本。除了实例的细节设置，其他设置如果没有特殊需求，默认即可。当确认一切设置无误后，可以单击“Launch”按钮进行实例创建。

创建OpenStack虚拟机实例前有很多先决条件，如Horizon本身能正常运行并对外提供创建服务；建立在OpenStack三个核心组件之上等。这三个核心组件分别是Keystone、 Glance、Nova。Keystone负责授权认证、租户管理、项目权限和配额以及服务目录管理。Glance负责为Nova提供创建实例所需要的镜像文件，这种镜像文件可以包含很多格式，大多数都是我们常见的镜像格式，如raw、qcow2。Nova负责虚拟机生命周期的管理，以及宿主机资源调度。Nova还决定了虚拟机实例建立在哪一台Hypervisor物理机之上。由这三个核心组件协作，Horizon将用户的HTTP请求转换为RESTful请求，然后将RESTful请求分发给Nova API，进行实例创建。当创建后，虚拟机实例会进入Build状态，任务状态将是Spawning。这期间会将镜像文件从Glance中下载到Nova节点，并进行一些虚拟机的配置。当一切正常后，虚拟机将会进入Active状态，此时用户可以享受“云”带来的便捷，如图1-7所示。创建所需的时间一般由创建实例的镜像文件大小、传输镜像图带宽，以及创建的Hypervisor磁盘性能来决定。有时创建过程会持续5～10分钟。

Horizon并不是唯一可以管理虚拟机的用户界面。之前提到OpenStack还有基于Python的CLI，虚拟机创建之后可以通过Nova-Client进行管理。通过命令行输入nova list，可以看到所有OpenStack实例的运行情况，以及实例相应的信息，如图1-8所示。后续在讲解Nova组件时，将详细讲解各种命令的操作及命令之间的关联关系，以及如何实现自定义命令、命令行扩展，还有如何运用好一系列的OpenStack命令来进行日常的管理、运维。

当虚拟机创建成功后，双击虚拟机名，进入到这个虚拟机视图进行详细观察，如图1-9所示，可以看到标签页，包括概览（Overview）、日志（Log）、控制台（Console）。概览中可以看到虚拟机的一系列详细信息。日志中可以看到虚拟机当前的启动引导日志，不用登录虚拟机就可以看到虚拟机的引导情况，检查是否有错误或者异常发生。通过控制台界面，可以对虚拟机进行操作。这是一个VNC控制台，我们不必像以前使用虚拟机那样，登录到Hypervisor端配置VNC端口信息，然后再通过VNC Client登录管理虚拟机。OpenStack将这些日常操作抽象出来，进行自动化，整个过程无须用户进行任何配置，当构建好OpenStack云后，剩下的事将交给OpenStack来做。

单击“More”，有更多的操作可以进行，可以对虚拟机实例进行一些操作，这些操作包括启动、停止、挂起、激活、快照、迁移、备份、诊断、恢复、重建、销毁等一系列虚拟机生命周期管理。这些操作都由Nova提供，部分操作会由其他组件来参与。对于OpenStack这样的一个分布式系统，完成一件事，基本上都会涉及一系列的组件。这些组件协同工作，在“云”中扮演着各种角色。之后我们将具体探讨这些组件在OpenStack中扮演什么样的角色，哪些组件必不可少，以及如何通过各种组件的排列组合来组建合适的“云”。

1.6.3 创建虚拟机流程概述

本节将介绍创建虚拟机的步骤，如下：

1）Horizon通过Keystone获取Compute组件的访问地址（URL），并获取授权令牌（Token），如图1-10所示。

2）携带授权令牌，发送创建虚拟机指令，如图1-11所示。

3）nova-compute组件通过glance-api下载虚拟机镜像，glance镜像中有缓存机制，通常将缓存文件放入名为_base的目录（下文将其称为base缓存），如图1-12所示。镜像分两个阶段，第一个阶段是如果base缓存中没有此次的虚拟机镜像文件，则从Glance下载镜像到base缓存；第二个阶段是从base缓存复制到本地镜像目录。base缓存可关闭，默认为开启。建议不要修改此默认值，因为如果每次镜像都通过Glance下载，会消耗大量的网络带宽。base缓存的存在就是为了解决虚拟机镜像文件传输消耗带宽的问题。

4）Glance检索后端镜像，Glance后端存储不一定要使用Swift，只要能存放镜像的文件系统都可以，如图1-13所示。

5）获取网络信息，决定虚拟机网络模式及建立网络连接，如图1-14所示。

6）nova-compute发送启动虚拟机指令，如图1-15所示。

至此，虚拟机创建完成。

1.6.4 创建OpenStack磁盘实例

本节将通过图形界面方式创建磁盘实例。在Dashboard左侧导航栏中，选择“项目”→“Volumes”，然后单击右侧的“Create Volume”按钮，如图1-16所示。

创建磁盘实例的过程与创建虚拟机类似，在弹出的“Create Volume”界面中，只需要进行选择，填写表单，就可以获得想要的磁盘，如图1-17所示。

填写完成后，单击“Create Volume”按钮即可进行创建。Volume创建会交由Cinder进行处理，与Nova API类似，Cinder也有Cinder API模块进行RESTful处理。这些过程与虚拟机实例创建类似，都需要经过Keystone认证，然后交由Cinder组件进行具体调度、创建工作，Horizon则将这一过程展现给用户，如图1-18所示。

创建完磁盘后，可以将这块磁盘挂载到虚拟机实例上，供虚拟机实例使用。这一挂载操作并不像传统的磁盘挂载方式，虽然原理不变，但其操作模式及服务模式发生了变化，用户只需要单击界面进行设置就可以完成这一系列操作。单击磁盘管理界面中的“Edit Attachments”按钮就可以进行挂载操作，如图1-19所示。

挂载后，磁盘管理界面将显示挂载的详细信息。通过virt-manager图形工具查看虚拟机即可看到第二块挂载的磁盘，如图1-20所示。这块磁盘是热挂载形式，不需要虚拟机实例停止运行。

1.6.5 创建块存储流程概述

现在来了解一下创建块存储的流程，如下：

1）Horizon通过Keystone获取Cinder组件的访问地址（URL），并获取授权令牌（Token），如图1-10所示。

2）携带授权令牌，发送创建块存储指令，如图1-21所示。

3）携带令牌，发送挂载块存储指令，如图1-22所示。

4）nova-compute组件发送RPC指令以通知Cinder挂载块设备，如图1-23所示。

1.7 OpenStack体系结构

1.7.1 OpenStack设计原则

在介绍OpenStack体系结构之前，需要先了解一下OpenStack的设计原则，如下：

· 可扩展性和伸缩性是设计OpenStack的主要目标。

· 任何影响可扩展性和伸缩性的特性必须是可选的。

· 一切应该是异步的（如果做不到异步，可参考第二条）。

· 所有必需的组件必须可水平扩展。

· 始终使用无共享架构或者分片架构（如果不能实现，可参考第二条）。

· 一切都是分布式的（尤其应该将业务逻辑与业务状态放在一起）。

· 接收最终一致性，并在适当条件下使用。

· 测试一切（我们需要测试已经提交的代码，如果用户需要，我们将会帮助用户测试）。

1.7.2 OpenStack架构

OpenStack是由一系列具有RESTful接口的Web服务所实现的，是一系列组件服务集合。如图1-24所示，我们看到的是一个标准的OpenStack项目组合的架构。这是比较典型的架构，但不代表这是OpenStack的唯一架构，我们可以选取自己需要的组件项目，来搭建适合自己的云计算平台。

OpenStack项目并不是单一的服务，其含有子组件，子组件内由模块来实现各自的功能，如图1-25所示。通过消息队列和数据库，各个组件可以相互调用，互相通信。这样的消息传递方式解耦了组件、项目间的依赖关系，所以才能灵活地满足我们实际环境的需要，组合出适合我们的架构。每个项目都有各自的特性，大而全的架构并非适合每一个用户，譬如Glance在最早的A、B版本中并没有实际出现应用，Nova可以脱离镜像服务独立运行。当用户的云计算规模大到需要管理多种镜像时，才需要像Glance这样的组件。OpenStack的成长是在生产环境中不断被检验，然后再将需求反馈给社区，由社区来实现的一个过程，可以说OpenStack并非脱离实际的理想化开源社区项目，而是与生产实际紧密结合的，可以复制应用的云计算方案。

注：完整版本请参看docs.openstack.org/training-guides/content/module001-ch004-openstack-architecture.html。

1.8 OpenStack的开发资源

1.8.1 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/

（1）在线工具

· 记事本：https：//etherpad.openstack.org/

· 剪贴板：http：//paste.openstack.org/

（2）代码库

· 核心项目Git库：http：//git.openstack.org/cgit

· 项目建设工具：https：//github.com/openstack-infra

· 开发人员工具：https：//github.com/openstack-dev

（3）代码提交和审查

· 代码review系统：https：//review.openstack.org/

· 代码合并建议：http：//status.openstack.org/reviews/

· 持续集成：http：//status.openstack.org/zuul/

· 用户和管理员文档：http：//docs.openstack.org/

1.8.2 OpenStack基金会

OpenStack基金会促进OpenStack的发展、分销、建设。作为OpenStack的独立家庭，基金会已经吸引来自87个国家或地区的850个不同组织的超过5600名个人成员，获得超过1000万美元的资金，履行OpenStack的使命——成为无处不在的云计算平台。

OpenStack基金会的目标是为开发人员、用户和整个生态系统提供一套记录OpenStack成长足迹的共享资源，使得供应商和开发人员在云行业得到优秀的软件。如同OpenStack软件本身，OpenStack基金会成员资格是免费的，任何人都可以参与。OpenStack社区成员通过技术贡献或者社区建设工作可以参与其中。OpenStack基金会网址：https：//www.openstack.org/join/。

如果没有这么多参与者提供各式各样的支持，OpenStack基金会就不可能发展到今天。想要了解更多OpenStack的支持者信息，可以访问以下网址：https：//www.openstack.org/ foundation。

1.8.3 OpenStack项目资料

1.Nova

· 项目主页：http：//launchpad.net/nova

· 项目代码：https：//github.com/openstack/nova

· Bug追踪：https：//bugs.launchpad.net/nova

· 功能需求蓝本（blueprint）：https：//blueprints.launchpad.net/nova

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/page：1/query：nova/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/nova,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/nova.git;a=summary

· 团队列表：https：//launchpad.net/～nova

· 核心成员列表：https：//review.openstack.org/#/admin/groups/25,members

2.Glance

· 项目主页：http：//launchpad.net/glance

· 项目代码：https：//github.com/openstack/glance

· Bug追踪：https：//bugs.launchpad.net/glance

· 特性需求（blueprint）：https：//blueprints.launchpad.net/glance

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：glance/ page：1/query：glance/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/glance,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/glance.git;a=summary

· 团队列表：https：//launchpad.net/～glance

· 核心成员列表：https：//review.openstack.org/#/admin/groups/13,members

3.Keystone

· 项目主页：http：//launchpad.net/keystone

· 项目代码：http：//github.com/openstack/keystone

· Bug追踪：https：//bugs.launchpad.net/keystone

· 特性需求（blueprint）：https：//blueprints.launchpad.net/keystone

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：keystone/ page：1/query：keystone/

· 代码更改建议：https：//review.openstack.org/#q,status：open+project：openstack/keystone,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/keystone.git;a=summary

· 团队列表：https：//launchpad.net/～keystone

· 核心成员列表：https：//review.openstack.org/#/admin/groups/9,members

4.Horizon

· 项目主页：http：//launchpad.net/horizon

· 项目代码：http：//github.com/openstack/horizon

· Bug追踪：https：//bugs.launchpad.net/horizon

· 特性需求（blueprint）：https：//blueprints.launchpad.net/horizon

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：horizon/ page：1/query：horizon/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/horizon,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/horizon.git;a=summary

· 团队列表：https：//launchpad.net/～horizon

· 核心成员列表：https：//review.openstack.org/#/admin/groups/43,members

5.Swift

· 项目主页：https：//launchpad.net/swift

· 项目代码：https：//github.com/openstack/swift

· Bug追踪：https：//bugs.launchpad.net/swift/+bugs

· 特性需求（blueprint）：https：//blueprints.launchpad.net/swift

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：swift/page：1/ query：swift/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/swift,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/swift.git;a=summary

· 团队列表：https：//launchpad.net/～swift

· 核心成员列表：https：//review.openstack.org/#/admin/groups/24,members

6.Cinder

· 项目主页：https：//launchpad.net/cinder

· 项目代码：https：//github.com/openstack/cinder

· Bug追踪：https：//bugs.launchpad.net/cinder/+bugs

· 特性需求（blueprint）：https：//blueprints.launchpad.net/cinder

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：cinder/page：1/ query：cinder/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/cinder,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/cinder.git;a=summary

· 团队列表：https：//launchpad.net/～cinder

· 核心成员列表：https：//review.openstack.org/#/admin/groups/83,members

7.Neutron

· 项目主页：https：//launchpad.net/neutron

· 项目代码：https：//github.com/openstack/neutron

· Bug追踪：https：//bugs.launchpad.net/neutron/+bugs

· 特性需求（blueprint）：https：//blueprints.launchpad.net/neutron

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：neutron/ page：1/query：neutron/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/neutron,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/neutron.git;a=summary

· 团队列表：https：//launchpad.net/～neutron

· 核心成员列表：https：//review.openstack.org/#/admin/groups/38,members

8.Ceilometer

· 项目主页：https：//launchpad.net/ceilometer

· 项目代码：https：//github.com/openstack/ceilometer

· Bug追踪：https：//bugs.launchpad.net/ceilometer/+bugs

· 特性需求（blueprint）：https：//blueprints.launchpad.net/ceilometer

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：ceilometer/ page：1/query：ceilometer/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/ceilometer,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/ceilometer.git;a=summary

· 团队列表：暂无

· 核心成员列表：https：//review.openstack.org/#/admin/groups/107,members

9.Heat

· 项目主页：https：//launchpad.net/heat

· 项目代码：https：//github.com/openstack/heat

· Bug追踪：https：//bugs.launchpad.net/heat/+bugs

· 特性需求（blueprint）：https：//blueprints.launchpad.net/heat

· 技术问题：https：//ask.openstack.org/zh/questions/scope：all/sort：activity-desc/tags：heat/page：1/ query：heat/

· 代码更改建议：https：//review.openstack.org/#/q/status：open+project：openstack/heat,n,z

· 代码变化：https：//review.openstack.org/gitweb?p=openstack/heat.git;a=summary

· 团队列表：https：//launchpad.net/～heat

· 核心成员列表：https：//review.openstack.org/#/admin/groups/114,members

1.9 OpenStack非核心项目介绍

1.9.1 Ironic项目介绍

Ironic为OpenStack的孵化项目之一，如果说OpenStack Nova管理的是虚拟机的生命周期，那么Ironic就是为了管理物理机的生命周期。它提供了一系列管理物理机的API接口，可以对“裸”操作系统的物理机进行管理，从物理机上架安装操作系统到物理机下架维修。我们可以像管理虚拟机一样地管理物理机，创建一个nova-compute物理节点不再需要人工部署，只需告诉Ironic，然后自动化地从镜像模板中加载操作系统到nova-compute安装完成即可。OpenStack管理虚拟机已经非常成熟，通过Nova我们可以快速自动化地创建虚拟机。但是在这之前需要搭建物理环境，需要人工地管理多台设备，OpenStack并没有提供物理环境的管理，我们依然需要解决这些基础环境的搭建问题，由此Ironic应运而生，解决物理机的添加、删除、电源管理、操作系统部署等问题。Ironic让OpenStack不仅停留在软件层面解决云计算问题。供应商可以对应自己的服务器开发Ironic插件。到目前为止，Ironic还处于实验阶段，它的目标是成为物理机管理的成熟解决方案。

提到Ironic项目，就不得不说Nova项目中的baremetal驱动。baremetal是Nova中的后端驱动，它与libvirt驱动、XenAPI驱动、VMware驱动一样，只不过它用来管理没有虚拟化的硬件，主要通过PXE和IPMI进行控制管理。这是一个可插拔式的插件，有了它，配置和管理服务器的硬件就可以使用Heat或salt-cloud来完成。baremetal并不能直接使用，还需要额外的环境准备，如要预先配置IPMI、配置DHCP服务、开启PXE等。Grizzy版本中已经含有baremetal驱动，但这仍然是实验性质。

在Nova中，baremetal的概念最早是由USC/ISI和NTT-Docomo提出的。USC/ISI是研究超算的教育机构，而NTT-Docomo是一家日本公司。物理机与虚拟机管理有许多类似的地方，但又有一些差异。最早设想为通过Nova统一管理，但在开发中，物理机与虚拟机的差异导致baremetal不得不从Nova中剥离，因为：

· baremetal驱动有自己的数据库，在Nova一个项目中有两套数据库不合适。

· 物理机和虚拟机存储的数据信息不同，将两个有差异的实体放在同一个API中获取信息，在设计和使用上都比较别扭。

· 物理机和虚拟机的操作有差异，如discovery、hardware RAID configuration、firmware updates、burn-in等操作。物理机和虚拟机不能简单同质化。

社区经过讨论，决定将baremetal从Nova中剥离出来，命名为Ironic，主要用来实现对物理机的裸机管理。

下面来了解一下baremetal和Ironic在执行创建时的区别。

下面是通过PXE部署硬件物理机的步骤，如图1-26所示。

1）通过“nova boot”命令创建物理机，nova-api组件处理命令并将创建消息发送到消息队列中。

2）nova-scheduler接收到消息队列中的消息，判断是否为baremetal节点，如果是，则将调度后的主机节点信息及创建消息放入消息队列。

3）nova-compute监听消息队列发现创建消息并处理，调用baremetal驱动，通过实现spawn()方法来调用创建。

4）nova-compute查询baremetal数据库，获取节点信息。

5）Neutron负责设置网络相关信息。

6）nova-compute开始从Glance获取镜像。

7）nova-compute激活bootloader。

8）通过IPMI开启物理机电源。

9）通过PXE加载bootloader，暴露iSCSI，通过nova-baremetal-deploy-helper将镜像中的信息写入服务器。

10）重新启动服务器，加载操作系统。

11）更新数据库中物理机的信息状态。

12）更新Nova中的instance状态信息。

Ironic的部署流程与baremetal类似，如图1-27所示。

1）通过nova boot命令创建物理机，nova-api组件处理命令，并将创建消息发送到消息队列中。

2）nova-scheduler接收到消息队列中的消息，判断是否为baremetal节点，如果是，则将调度后的主机节点信息及创建消息放入消息队列。

3）nova-compute监听消息队列发现创建消息并处理，调用baremetal驱动，通过实现spawn()方法来调用创建。

4）nova-compute通过Ironic API获取硬件注册信息。

5）Neutron负责设置网络相关信息。

6）nova-compute开始从Glance获取镜像。

7）nova-compute通过Ironic API发送部署请求。

8）Ironic API与Ironic Conductor组件交互并激活bootloader。

9）通过IPMI开启物理机电源。

10）通过PXE加载bootloader，暴露iSCSI，通过nova-baremetal-deploy-helper将镜像中的信息写入服务器。

11）重新启动服务器，加载操作系统。

可以看到，Ironic对于硬件的异构问题主要是通过多个后端驱动的结合来解决的，如图1-28所示。

图1-28中的接口介绍如下。

· Deploy Interface：实现把镜像部署到物理机中。

· Power Interface：实现对物理机电源的管理。

· Console Interface：实现通过硬件直接得到物理机Console（控制台）。

· Vendor Interface：厂商自定义行为。

因为Ironic项目结构与大部分的OpenStack结构类似，所以是标准的OpenStack项目。目前，由于项目时间较短，因此并不是很成熟，但是从Ironic想解决的问题以及社区的支持来看，Ironic有希望在未来的几个版本内成为核心项目。

Ironic的安装

下面介绍一下Ironic的安装流程。

1）通过git clone获取最新的DevStack。获取链接地址为：

git：//github.com/openstack-dev/devstack.git

2）进入devstack目录修改localrc文件，添加如下内容：

# Enable Ironic API and Ironic Conductor
enable_service ir-api
enable_service ir-cond
# 使用Neutron代替nova-network，Ironic只支持Neutron
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service neutron
enable_service q-lbaas
#按需要替换password
ADMIN_PASSWORD=password
MYSQL_PASSWORD=password
RABBIT_PASSWORD=password
SERVICE_PASSWORD=password

3）运行stack.sh脚本。命令如下：

./stack.sh

接下来就是等待Ironic安装完成了。Ironic API地址为http：//<ip>：6385。

1.9.2 Tempest项目介绍

Tempest为OpenStack的功能测试、集成测试项目，它被设计为可在各种不同项目中使用。在OpenStack核心项目中的单元测试代码中经常可以看到它的身影，在一些孵化项目中也会使用Tempest去测试。它可以验证代码的正确性，已经成为OpenStack项目中不可或缺的组成部分。

Tempest框架主要基于unittest2和nose来实现，它通过调用OpenStack API来测试功能，响应验证。测试的主要风格是按照pyunit来确定的，同时使用了testtools和testresources等多个测试工具库，可以说相当强大。

使用Tempest测试一个OpenStack环境，先要在各个OpenStack项目的配置文件中设置Tempest，在etc/文件夹下有一个tempest.conf.sample供参考使用。设置完成后，就可以直接通过“nosetests tempest”命令运行所有测试案例，也可以指定执行某个测试类库中的测试用例。

Tempest主要用于以下几个测试：

· API测试

· 命令行测试

· 复杂场景测试

· 压力测试

· 第三方API测试

每一项都对应Tempest中的一个目录，每个目录中包含不同类型的测试。README.rst中记录着每个目录的作用，以及良好的测试示例及测试规则。

Tempest目录结构如下：

1）api：API的测试集。

2）cli：OpenStack的命令行工具测试集。

3）common：一些公共的工具类和函数。

4）scenario：对OpenStack的常用场景进行测试，包括基本的启动虚拟机、挂载volume和网络配置等。

5）services：Tempest实现的OpenStack API Client，主要是避免官方Client中含有Bug。

6）stress：压力测试集，利用多进程（multiprocessing）同时对OpenStack发起请求进行测试。

7）thirdparty：EC2等第三方兼容API测试集。

8）whitebox：白盒测试集。

1.API测试

API测试是验证OpenStack的API。它不应该利用现有的OpenStack Python客户端实现，而是应该使用Tempest组件来实现。同时测试XML和JSON格式的请求。脱离官方客户端，可以让我们传递无效或非法的JSON和XML请求来查看这些请求结果，以验证API的健壮性。API测试应由项目开发者自己来完成，比如对项目进行功能性测试，或者使用某些单元测试框架。

2.命令行测试

命令行测试使用OpenStack的命令行与OpenStack中的项目组件进行交互。命令行测试中，单元测试是有点困难的，因为不像服务器测试，它没有实现访问服务器的代码。Tempest运行于一个部署好的OpenStack环境，这样就合乎逻辑了，可以在服务器上直接执行命令行。

3.复杂场景测试

复杂场景测试是通过各种复杂的OpenStack调用流程来测试OpenStack功能。它由一系列经典场景组成，需要多个OpenStack项目支持来完成这一系列测试。场景测试可以使用OpenStack Python客户端。

4.压力测试

压力测试主要设计为测试OpenStack在高工作负载中运行时会出现什么问题。多种工具可以帮助检测OpenStack在高负载时出现的问题，如追溯日志。

5.第三方API测试

许多OpenStack项目支持第三方API，如Nova支持EC2的API。Tempest验证第三方API，必须独立于OpenStack正常的测试流程。第三方API测试应该独立于OpenStack本身的逻辑。