简介
Openstack是一个通过数据中心（datacenter）控制大量的计算（compute）、存储(storage)和网络(networking)资源的云操作系统；
所有的资源都可以通过面板（dashboard）被系统管理员管理，同时也可授权用户自由分配所需使用的资源。
OpenStack is a cloud operating system that controls large pools of compute, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface.
版本历史
| Revision Date | Summary of Changes |
|---|---|
|
Oct 17, 2013 |
Havana release |
|
Apr 4, 2013 |
Grizzly release |
|
Sep 27, 2012 |
Folsom release |
|
Apr 5, 2012 |
Essex release |
|
Sep 22, 2011 |
Diablo release |
| Apr 15, 2011 | Cactus release |
| Feb 3, 2011 | Bexar release |
| Oct 21, 2010 | Austin release |
架构
主要服务
| 服务 | 项目名称 | 描述 |
|---|---|---|
| Dashboard | Horizon | 用户和管理员仪表盘 |
| Compute | Nova | 控制器 |
| Networking | Neutron | 安全虚拟网络 |
| Storage | ||
| Object Storage | Swift | 对象存储 |
| Block Storage | Cinder | 块存储 |
| Shared services | ||
| Identify Service | Keystone | 身份验证服务 |
| Image Service | Glance | 虚拟机镜像服务 |
| Telemetry Service | Ceilometer | 监控及计费服务 |
| Higher-level services | ||
| Orchestration Service | Heat | 自动化部署服务 |
概念架构
逻辑架构
简单架构
Identity Service
介绍：
Keystone（OpenStack Identity Service）是OpenStack框架中，负责身份验证、服务规则和服务令牌的功能， 它实现了OpenStack的Identity API。Keystone类似一个服务总线， 或者说是整个Openstack框架的注册表， 其他服务通过keystone来注册其服务的Endpoint（服务访问的URL），任何服务之间相互的调用， 需要经过Keystone的身份验证， 来获得目标服务的Endpoint来找到目标服务。
功能：
用户管理：跟踪用户及其权限；
服务目录：提供带API地址的可用服务的目录
相关概念：
User：用户，代表可以通过keystone进行访问的人或程序。Users通过认证信息（credentials，如密码、API Keys等）进行验证；
Tenant：租户，它是各个服务中的一些可以访问的资源集合。例如，在Nova中一个tenant可以是一些机器，在Swift和Glance中一个tenant可以是一些镜像存储，在Neutron中一个tenant可以是一些网络资源。User默认的总是绑定到某些tenant上；
Role：角色，代表一组用户可以访问的资源权限。（例如Nova中的虚拟机、Glance中的镜像）Users可以被添加到任意一个全局的或租户内的角色中。在全局的role中，用户的role权限作用于所有的租户，即可以对所有的租户执行role规定的权限；在租户内的role中，用户仅能在当前租户内执行role规定的权限；
Credentials：证书，证明用户身份的一段数据（Data）（如用户名/密码，用户名/API key等）；
Authentication：认证，验证用户身份的动作。
Token：令牌，类似于证书，但描述的是可访问资源的权限；
Service：服务，如Nova、Glance、Swift等；
Endpoint：“端点”，可以理解它是一个服务暴露出来的访问点，如果需要访问一个服务，则必须知道他的endpoint。
形象对比：
| User | 住宾馆的人 |
|---|---|
| Tenant | 宾馆 |
| Role | VIP 等级，VIP越高，享有越高的权限 |
| Credentials | 开启房间的钥匙 |
| Authentication | 宾馆为了拒绝不必要的人进出宾馆，专门设置的机制，只有拥有钥匙的人才能进出 |
| Token | 也是一种钥匙，有点特别 |
| Service | 宾馆可以提供的服务类别，比如，饮食类，娱乐类 |
| Endpoint | 具体的一种服务，比如吃烧烤，打羽毛球 |
服务处理流程：
Image Service
包含的组件:
glance-api：接受Image API调用，用以镜像发现、检索和存储；
glance-registry：存储、处理和检索镜像的元数据，包括大小（size）、类型（type）等；
Database：存储镜像元数据，大多部署使用MYSQL或SQLite；
Storage repository for image files：镜像的存储仓库，支持普通文件系统、RADOS块设备、Amazon S3、和HTTP等
处理流程：
接受来自终端用户（end users）或计算组件（Compute components）对于镜像或者镜像元数据的API请求，并将镜像文件存储在Object Storage Service（Swift）中。
Compute Service
包含的组件：
| Service | Description |
|---|---|
| API | |
| nova-api | 接受和响应终端用户的compute API调用，也支持Amazon EC2 API、Admin API等；同时初始化大部分部署活动，如运行实例、执行规则等 |
| nova-api-metadata | 接受来自实例（Instance）的元数据请求，只在多主机（multi-host）并运行nova-network下运行 |
| Compute core | |
| nova-compute | 一个worker dameon，通过hypervisor API创建或终止虚拟机实例，如XenAPI对应XenServer/XCP，libvirt对应KVM或QEMU，VMwareAPI对应VMware等 |
| nova-scheduler | 调度器，从消息队列中获取虚拟机实例任务（Task），并分发至compute server主机运行 |
| nova-conductor | 引导器，居中调解nova-compute和database间的交互，防止nova-compute直接访问数据库 |
| Networking for VMs | |
| nova-network | 一个worker daemon，从消息队列中接受网络任务（task），并执行任务以配置网络，如建立网桥接口，改变iptables规则等； 此服务已独立成为了Openstack Networking（Neutron）服务 |
| nova-dhcpbridge | 一个脚本，追踪IP地址的租约期限（leases），并将其记录在数据库中； 此功能已迁移至Openstack Networking（Neutron）服务中 |
| Console interface | |
| nova-consoleauth | 验证VNC客户端用户的token |
| nova-novncproxy | 一个proxy，可通过VNC连接访问运行中的实例，支持基于浏览器的novnc客户端 |
| nova-console | 在Grizzly版本中移除，以nova-xvpnvncproxy代替 |
| nova-xvpnvncproxy | 一个proxy，可通过VNC连接访问运行中的实例，支持特定的Java客户端 |
| nova-cert | 管理x509证书 |
| Image management(EC2 scenario) | |
| nova-objectstore | 提供用以在Image Service中注册镜像的S3接口，主要用于支持euca2ools的安装 |
| euca2ools | 管理云资源（cloud resources）的一组解释命令的集合 |
| Command-line clients and other interfaces | |
| nova client | 允许用户作为Tenant管理员或终端用户提交命令 |
| nova-manage | 允许云管理员（cloud Administrators）提交命令 |
| Other components | |
| The queue | 在各daemon间传输消息的中心hub，如RabbitMQ、Apache Qpid或ZeroMQ等 |
| SQL database | 存储云架构中大部分建立时（build-time）和运行时（runtime）的状态，包括可用的实例类型、使用中的实例、可用的网络和项目（projects）等； 如sqlite3 databases、MySQL和PostgreSQL等 |
处理流程：
作为IaaS系统中主要的组成部分，Compute Service与Identity Service交互实现身份验证，与Image Service 交互实现镜像存取，与Dashboard交互实现用户和管理员的界面访问。
逻辑架构：
Block Storage Service
功能：
Block Storage Service用以管理卷（volume），卷快照（volume snapshots）和卷类型（volume types）。
包含的组件：
cinder-api：接受API请求，并将请求路由（route）至cinder-volume中；
cinder-volume：运行在存储节点上，管理存储空间；可通过驱动的形式（driver architecture）与多样的存储提供者交互，如本地存储、EMC、Netapp等；
cinder-scheduler： 类似于nova-scheduler，以选择需创建卷的最优的块存储提供者节点；
Messageing queue：在各程序间路由消息
逻辑架构：
Object Storage Service
功能：
Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），
通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，
支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。
包含的组件：
swift-proxy-server：代理器，接受Object Service API和原生的HTTP请求，以上传文件、修改元数据和创建容器等；
swift-account-server：管理账户（accounts）
swift-container-server：管理容器（containers）的映射(mapping)
swift-object-server：管理存储节点上的实际对象，如文件（files）
A number of periodic process：在大型数据存储上执行一些事务任务，如复制（replication）、审计（auditor）、更新（updater）、（账户清理reaper）等
数据模型：
Swift 采用层次数据模型，共设三层逻辑结构：Account/Container/Object（即账户/容器/对象)，每层节点数均没有限制，可以任意扩展。
这里的账户和个人账户不是一个概念，可理解为租户，用来做顶层的隔离机制，可以被多个个人账户所共同使用；
容器代表封装一组对象，类似文件夹或目录；叶子节点代表对象，由元数据和内容两部分组成
系统架构：
Orchestration Service
功能：
提供了一种通过模版定义的协同部署方式，实现云基础设施软件运行环境的自动化部署
Heat对于虚拟机内部操作的控制是需要利用heat-cfntools这个工具。其实质是，通过向实例镜像中注入heat-cfntools，
然后实例利用heat-cfntools同heat交互，进而实现相关的对于实例内部的相关操作（如安装和配置mysql数据库等）。
包含的组件：
heat command-line：与heat-api通信以运行AWS CloudFormatiom APIs，终端用户也可直接使用Orchestration REST API；
heat-api：提供Openstack原生的 REST API，并将API请求通过RPC传递给heat-engine；
heat-api-cfn：提供与AWS CloudFormation兼容的AWS 查询API，并将API请求通过RPC传递给heat-engine；
heat-engine：执行模板（templates）的部署，并返回事件（event）
Telemetry Service
功能：
Ceilometer是OpenStack里数据采集（监控数据、计费数据）的唯一基础设施，采集到的数据提供给监控、计费、面板等项目使用。
包含的组件：
ceilometer-agent-compute ：用来收集计算节点上的信息，该Agent通过Stevedore管理了一组pollster插件， 分别用来获取虚拟机的CPU, Disk IO, Network IO, Instance这些信息；
ceilometer-agent-central ：运行在控制节点上，主要收集其它服务(Image, Volume, Objects, Network)等的信息；
ceilometer-collector ：主要作用是监听Message Bus，将收到的消息以及相应的数据写入到数据库中；另一个作用是对收到的其它服务发来的notification消息做本地化处理，然后再重新发送到 Message Bus中去，随后再被其收集；
ceilometer-alarm-notifier ：运行在控制节点上，允许设置报警；
data store：处理并发的来自多个collector的写操作和来自API server的读操作；
API server（ceilometer-api） ：运行在控制节点上，提供对data store中数据的访问；只有collector和API server有权限访问data store。
架构：
Ceilometer项目主要由Agent，Collector，DataStore，API和消息队列组成。
