1.3　OpenStack体系结构

“云计算”中的“云”可以被简单地理解为任何可以通过互联网访问的服务，那么根据所提供服务的类型，云计算有3种落地方式。

· IaaS（基础架构即服务）：通过互联网向用户提供“基础的计算资源”，包括处理能力、存储空间、网络等。用户能从中申请到硬件或虚拟硬件，包括裸机（Bare Metal）或虚拟机，然后在上面安装操作系统或其他应用程序。

· PaaS（平台即服务）：把计算环境、开发环境等平台当作一种服务并通过互联网提供给用户。用户能从中申请到一个安装了操作系统及支撑应用程序运行所需要的运行库等软件的物理机或虚拟机，然后在上面安装其他应用程序，但不能修改已经预先安装好的操作系统和运行环境。

· SaaS（软件即服务）：通过互联网为用户提供软件及应用程序的一种服务方式。应用软件被安装在厂商或服务供应商那里，用户可以通过网络以租赁的方式来使用这些软件，而不是直接购买这些软件。比较常见的模式是提供一组账号和密码。

PaaS和SaaS并不一定需要底层有虚拟化技术的支持，但IaaS一般都是建立在虚拟化技术的基础上的。OpenStack及其一直在跟随的榜样——亚马逊的AWS都属于IaaS的范畴。

在本质上，IaaS是一个用户层的软件系统，它包含多个服务和应用程序，这些服务或程序被部署到多台被管理的物理主机上，这些物理主机通过网络连接成一个大的分布式系统。IaaS系统要解决的问题就是如何自动管理这些物理主机上虚拟出来的虚拟机，包括虚拟机的创建、迁移、关闭，虚拟存储的创建和维护，虚拟网络的管理，还包括监控计费、负载均衡、高可用性、安全等。这里不提供任何虚拟化服务的裸机（Bare Metal）也被视为虚拟机的一种特例，对它的管理也属于虚拟机管理的范畴。

在单台主机上，这些都可以通过简单的命令和操作完成，有些问题，如高可用性或负载均衡等根本不存在。但是在大规模网络上或数据中心里，将有成千上万台物理主机，仅仅依靠运维人员来完成这些管理任务是不现实的，这时就需要软件系统来自动辅助运维人员管理和维护系统的运行，给用户提供虚拟机服务。这就是IaaS系统产生的初衷，也是AWS和OpenStack，以及其他IaaS产品和开源项目要实现的功能。

1.OpenStack与AWS

无论是否情愿，我们都不得不承认，与亚马逊的AWS相比，OpenStack只是处于一个跟随者的位置。

在Bezos发布那份充满系统架构智慧的命令之后，2006年亚马逊推出了AWS产品，正式开启了云计算的新纪元。AWS由一系列服务组成，用来实现IaaS系统所需要的功能。如图1-3所示，AWS架构由5层组成，自下而上分别是AWS全球基础架构、基础服务、应用平台服务、管理和用户应用程序。

而对于服务类型本身而言，AWS提供6类主要服务：Database（数据库）、Storage &CDN（存储和内容分发）、Analytics（分析）、Compute &Networking（计算和网络）、Deployment &Management（部署管理）和App Services（应用服务），如图1-4所示。

在数据库服务里，包括NoSQL数据库服务DynamoDB、关系数据库服务RDS、缓存和数据仓库服务Redshift。

在存储和内容转发服务里，涵盖了简单存储服务S3、块存储服务EBS、Amazon云前端Cloud Front、Amazon Glacier、AWS存储网关Storage Gateway及AWS导入/导出Import Export。其中S3提供AWS永久存储服务，而EBS提供块存储服务。

在分析服务里，包括用于大数据的Elastic MapReduce（EMR）、用于大规模实时流数据处理的Kinesis和数据管道Data Pipeline。

在计算和网络服务里，涵盖了负责虚拟机调度和管理的弾性计算云EC2、保证企业在公有云上搭建安全私有云的虚拟私有云服务VPC、负载均衡服务ELB、虚拟桌面管理服务WorkSpaces、用于计算资源自动扩容缩容的Auto Scaling服务、为企业定制的专属网络连接DirectConnect，以及高可靠且可扩展的域名系统Web服务Route 53等。

在部署管理服务里，包括建立和管理AWS资源的CloudFormation、监控CloudWatch、用于轻松部署Web应用和服务的Elastic Beanstalk、验证访问管理IAM、日志管理CloudTrail、为运维人员配备的应用管理服务OpsWorks和安全服务CloudHSM。

在应用服务里，包括用于云搜索的CloudSearch、用于流媒体转码的Elastic Transcoder、简单邮件服务SES、简单消息服务SNS、简单队列服务SQS、简单工作流服务SWF，以及应用程序流AppStream。

综上所述，AWS的功能十分强大，而且目前还在不断发展之中，OpenStack从诞生之初就一直在向AWS学习，同时，OpenStack也提供开放接口去兼容各种AWS服务。

比如，在AWS中最为核心的EC2模块，负责计算资源的管理，以及虚拟机的调度和管理，在OpenStack中对应的就是Nova项目；在AWS中的简单存储服务S3，在OpenStack中有Swift项目与其功能相近；AWS的块存储服务EBS对应OpenStack的Cinder项目；AWS的验证访问管理IAM对应OpenStack的Keystone项目；AWS的监控CloudWatch对应OpenStack的Ceilometer项目；AWS有CloudFormation，OpenStack则有Heat项目；AWS支持关系数据库服务RDS和NoSQL数据库服务DynamoDB，OpenStack也支持MySQL、PostgreSQL和NoSQL数据库MongoDB。

目前来看，OpenStack远没有AWS完善，但是相比来说，OpenStack是一个开源项目，并不收取版权费用，这一点吸引了众多的企业IT人员、开源爱好者和开发人员、学术界人士、云服务提供商、运维人员等加入OpenStack社区，并贡献代码和分享经验。

2.OpenStack架构视图

作为一个IaaS范畴的云平台，完整的OpenStack架构首先要具有如图1-5所示的基本视图，它向我们传递了这样的信息——OpenStack通过网络将用户和网络背后丰富的硬件资源分离。

OpenStack一方面负责与运行在物理节点上的Hypervisor进行交互，实现对各种硬件资源的管理与控制；另一方面为用户提供一个满足要求的虚拟机。

至于OpenStack内部，作为AWS的一个跟随者，它的体系结构里不可避免地体现着前面所介绍的AWS各个组件的痕迹。OpenStack架构标准视图如图1-6所示。

图1-6涵盖了OpenStack曾经的7个核心组件，分别是Compute（计算）、Object Storage（对象存储）、Identity（认证）、Dashboard（用户界面）、Block Storage（块存储）、Network（网络）和Image（镜像服务）。在这7个核心组件中，除用户界面以外，其余6个仍是目前的核心组件。每个组件都是多个服务的集合，一个服务意味着运行着的一个进程。根据OpenStack的部署规模，可以决定用户是选择将所有服务运行在同一台机器上还是多台机器上。

1）Compute（Nova）

Compute的项目代号是Nova，它根据需求提供虚拟机服务，如创建虚拟机或对虚拟机进行热迁移等。从概念上看，它对应于AWS的EC2服务，而且它实现了对EC2 API兼容。如今，Rackspace和惠普提供的商业计算服务正是建立在Nova之上的，NASA内部使用的也是Nova。

Nova组件包括nova-api、nova-compute、nova-scheduler、nova-conductor、nova-db、nova-console、nova-consoleauth、nova-cert和nova-objectstore等。

· nova-api是Nova对外提供服务的窗口，它接收并响应来自用户的Compute API调用。nova-api同时兼容亚马逊AWS EC2 API，也提供一套与管理员操作相关的管理API。

· nova-compute是安装到每台物理主机上的服务进程，这个服务在接收请求之后会执行一批与虚拟机相关的操作，这些操作需要调用底层的Hypervisor API完成，如支持XenServer/XCP的XenAPI、支持KVM和QEMU的Libvirt或支持VMware的VMwareAPI等。

· nova-scheduler用于接收创建虚拟机的请求，并决定在哪台物理主机上启动该虚拟机的调度器。

· nova-conductor是处于nova-compute与nova-db之间的一个组件。nova-conductor建立的初衷是基于安全的考虑而避免nova-compute直接访问nova-db。也就是说，nova-compute对nova-db的访问请求，比如，让nova-compute查询一台虚拟机的状态，或者更新一条记录，都由nova-conductor代为转交。而nova-scheduler对nova-db的请求，却没有这种顾虑，也就是说nova-scheduler可以直接访问nova-db。

· nova-db包含大量数据库表，该数据库用于记录虚拟机状态、虚拟机与物理机的对应关系、租户信息等数据内容。

· nova-console和nova-consoleauth是Nova提供的控制台服务，允许最终用户通过代理服务器访问其虚拟机的控制台。

· nova-cert和nova-objectstore分别提供了X509验证管理服务和在Glance中注册镜像的S3接口服务。

2）Object Storage（Swift）

Object Storage的项目代号是Swift，它允许存储或检索对象，也可以认为它允许存储或检索文件，它能以低成本的方式通过RESTful API管理大量无结构数据，对应于AWS的S3服务。目前，KT、Rackspace和Internap都提供基于Swift的商业存储服务，许多公司的内部也使用Swift来存储数据。

Swift由proxy-server、account-server、container-server和object-server等一系列进程或服务组成。

· proxy-server处于Swift系统内部与外部之间，它负责接收API请求或HTTP请求，这些请求包括上传文件、修改元数据、创建容器等。有时为了提高系统性能，proxy-server也会与Memcached在一起部署。

· account-server仅用于账号管理。

· container-server用于管理容器或文件夹的映射关系。

· object-server用于管理在存储节点上的实际对象，如文件等。

除此之外，还有一些定期执行的进程，如Replication、Auditor、Updater和Reaper等。

3）Identity（Keystone）

Identity的项目代号是Keystone，为所有OpenStack服务提供身份验证和授权，跟踪用户及他们的权限，提供一个可用服务及API的列表。

Keystone的构成组件并不复杂，只包括接收前台请求的Keystone API和后台的keystone-db。

4）Dashboard（Horizon）

Dashboard的项目代号是Horizon，它为所有OpenStack服务提供一个模块化的基于Django的界面。通过这个界面，无论是最终用户还是运维人员都可以完成大多数的操作，如启动虚拟机、分配IP地址、动态迁移等。

5）Block Storage（Cinder）

Block Storage的项目代号是Cinder，用来提供块存储服务。Cinder最早是由nova-volume演化而来的，由于当时Nova已经变得非常庞大并拥有众多功能，同时Volume服务的需求会进一步增加nova-volume的复杂度，比如，增加Volume调度，允许多个Volume Driver同时工作，并且需要nova-volume与其他OpenStack项目交互；将Glance中的镜像模板转换成可启动的Volume，因此OpenStack新成立了一个项目Cinder来扩展nova-volume的功能。Cinder对应AWS的块存储服务EBS。

Cinder由cinder-api、cinder-volume、cinder-db、volumeprovider和cinder-scheduler组成。

· cinder-api用于接收来自外部的API请求，并把请求交给cinder-volume执行。

· cinder-volume负责与底层的块存储服务打交道，它响应读、写块设备请求，并把这个请求交给块存储服务，底层的不同存储服务提供商都通过Driver的方式实现了volumeprovider，所以具体的读、写请求交给底层volumeprovider来完成。

· cinder-db用于记录和维护块设备的信息。

· cinder-scheduler与nova-scheduler类似，由于底层提供存储的节点很多，cinder-scheduler会试图寻找一个最佳的节点创建Volume。

6）Network（Neutron）

Network的项目代号是Neutron，用于提供网络连接服务，允许用户创建自己的虚拟网络并连接各种网络设备接口。

Neutron通过插件（Plugin）的方式对众多的网络设备提供商进行支持，如Cisco、Juniper等，同时支持很多流行的技术，如Open vSwitch、OpenDaylight和SDN等。与Cinder类似，Neutron也来源于Nova，即nova-network，它最初的项目代号是Quantum，但由于商标版权冲突问题，后来经过提名投票更名为Neutron。

Neutron包含的组件有neutron-server、neutron-agent、network-provider、neutron-plugin，以及用于保存网络配置等相关信息的neutron-db等。

neutron-server用于接收来自外部的API请求，并将该请求交给合适的Neutron插件处理。

在Neutron中，有众多的插件和代理（Agent），它们负责插拔端口、建立网络和子网、提供IP地址等。插件从功能上来说用于存储当前逻辑网络的配置信息，判断和存储逻辑网络与物理网络之间的对应关系，以及与一种或多种交换机通信来实现这种对应关系，它需要访问neutron-db。

而实现这种对应关系，一般需要通过物理机上的代理来完成，代理可以分为Plugin Agent、DHCP Agent和L3 Agent。虚拟网络上数据包的处理都是由Plugin Agent完成的，一般选择了什么插件，就需要选择相应的Plugin Agent，Plugin Agent会调用相应的network-provider完成与该网络设备对应的功能；DHCP Agent会为租户网络提供DHCP服务，每个插件都使用这个代理；L3 Agent会为虚拟机访问外部网络提供3层转发服务。

7）Image Service（Glance）

Image Service的项目代号是Glance，它是OpenStack的镜像服务组件，相对于其他组件来说，Glance功能比较单一，代码量也比较少，而且由于新功能的开发数量越来越少，近来社区的活跃度也没有其他组件那么高，但它仍是OpenStack核心项目之一。

Glance主要提供一个虚拟机镜像的存储、查询和检索服务，通过提供一个虚拟磁盘镜像的目录和存储库，为Nova的虚拟机提供镜像服务。它与AWS中的Amazon AMI Catalog功能相似。

Glance由glance-api、glance-registry和glance-db等组件组成。

· glance-api用于接收来自外部的API镜像请求，这些请求包括镜像发现、获取及存储。

· glance-registry用于存储、处理和获取镜像元数据。对于v2版本的API，glance-registry的功能已经被整合到glance-api中。

· glance-db里存储的就是元数据。

现在以创建虚拟机为例来介绍这些核心组件是如何通过相互配合完成工作的。用户首先接触到的是界面，即Horizon。通过Horizon上的简单界面操作，一个创建虚拟机的请求被发送到OpenStack系统后端。

既然要启动一个虚拟机，就必须指定虚拟机的操作系统的类型，同时下载启动镜像以供虚拟机启动使用。这件事情就是由Glance来完成的，而此时Glance所管理的镜像有可能存储在Swift上，所以需要与Swift进行交互以得到需要的镜像文件。

在创建虚拟机时，自然需要Cinder提供块服务和Neutron提供网络服务，以便该虚拟机有Volume可以使用，能被分配到IP地址以与外界网络连接，而且之后访问该虚拟机的资源要经过Keystone的认证之后才可以继续。至此，OpenStack的所有核心组件都参与了创建虚拟机的操作过程。