上周我们聊Openshift的时候提到了国内很大一部分公有云厂商是基于Openstack来构建IaaS平台的，那就有小伙伴来询问本座Openstack究竟是怎样的架构呢，它是由NASA在2010年创建的开源项目，Openstack是构建和管理云计算平台的软件工具集，这里提到的云平台包括了私有云和公有云，目前由Openstack基金会所管理，尽管它是一家非营利机构，但已经获得了很多大公司的支持。
Openstack共有五种部署形式，分别是本地部署、公有云部署、私有云部署、Openstack-as-a-Service以及绑定Openstack的物理设备。
在本地部署的模式中，用户下载Openstack离线包并在内部网络安装，选择适合的组件，近乎DIY的安装使用模式；
在公有云模式中，云厂商基于Openstack开源项目搭建IaaS平台并对外发布服务；
私有云部署是上述两种部署模式的融合，云厂商根据客户要求在现有机房、现有硬件设施上部署Openstack软件，云厂商提供Openstack的技术服务支持。环境、硬件和数据都可由客户自己维护；
Openstack-as-a-Service，同样由云服务商提供，不过服务目录更加明细，客户可以选购单独的计算资源或存储资源；
Opensatck设备，这类厂商可以提供硬件形式，即插即用的虚拟资源服务，如Nebula，客户不需要再单独安装操作系统，将这类设备接入现有网络就自动触发Openstack部署。
接下来我们看下Openstack的架构，Openstack的架构由九大部分组成，分别是：
Horizon：提供基于Web的管理界面
Keystone：管理所有其他组件的用户验证及授权
Nova：计算资源池
Glance：用以启动服务实例
Swift：用以管理对象存储
Neutron：调配网络服务
Cinder：块存储服务
Heat：用以调度及服务编排
Ceilometer：记账模块
Heat和Ceilometer是公有云相关的模块，这边不做详述。我们先说安全验证服务Keystone，通过安装Openstack的身份API组件即完成了Keystone的部署，它提供了API客户端验证、服务发现和分布式多租户的授权。其下分管了令牌服务、目录服务、策略服务和指派服务数据库。令牌服务数据库中管理了用户会话令牌，验证用户建立连接时对端的真实性；目录服务记录内部所有已发布服务的可用性，管理服务的访问授权；策略服务中记录了一些服务使用的边界以确保安全底线不被攻破；最后一个指派服务是为已知用户定义角色和角色组，例如可以访问日志应用和审计应用的称之为安全用户角色等等。
再说Glance，我们可以把Glance看作是一个镜像仓库，为客户提供了上传、查询数据资产的服务。目前Glance中可以存储系统镜像以及元数据定义；Glance的镜像服务包括了查询、注册，调用虚拟机。
上图展示了用户调用Openstack的逻辑图，顺便说一下Openstack的这九大组件都是以API形式对外或互相调用的。用户通过前端Glance API调用到后端的各类存储、文件系统、数据库和OS镜像服务。
Nova是Openstack的计算资源池，负责所有计算任务。当我们启动了Glance中的系统镜像，Nova需要为其分配计算资源。Nova的核心组件是基于RabbitMQ的消息队列服务，通过消息队列获取其他组件的计算需求，并向向其输送对应的资源（如下图）。
Neutron管理了Openstack中的网络服务，致力于在虚拟计算环境中提供Network-as-a-Service的即插即用式服务，它的出现解决了传统网络中资源利用率过低的问题，并很好地做了云网络的拓展。
下面是Neutron网络结构图，管理员创建和管理Neutron外部网络，是租户虚拟机与互联网信息交互的桥梁。更具体的，外部网络会分出一个子网，它是一组在互联网上可寻址的IP地址。一般情况下，外部网络只有一个（neutron是支持多个外部网络的），且由管理员创建。租户虚拟机创建和管理租户网络，每个网络可以根据需要划分成多个子网。诸多子网通过路由器与Neutron外部网络连接。路由器的gateway网关端连接外部网络的子网，interfaces接口端有多个，连接租户网络的子网。路由器及interface接口端连接的网络都是由租户根据需要自助创建，管理者只创建和管理Neutron外部网络部分。
Swift为客户提供了高可用、分布式的廉价对象存储，很多国际大厂，像Comcast，时代华纳、Globo和维基百科都用了Swift来存放大量图像和视频文件，还有些云服务商，例如Rackspace, NTT, OVH和IBM也都在用Swift的对象存储。
Swift无需采用RAID（磁盘冗余阵列），也没有中心单元或主控结点。Swift通过在软件层面引入一致性哈希技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性（High Availability，简称HA）和可伸缩性，支持多租户模式、容器和对象读写操作（如下图），适合解决互联网的应用场景下非结构化数据存储问题。
Cinder是Openstack的块存储服务，相较于Swift，后者在文件上传后，客户不用去关心它存在哪里，Swift会提供一个URL供客户访问，这个URL同时可以分享给其他租户，但是当这个URL一旦发生问题，后端的文件就将无法访问；而Cinder是专项的存储服务，类似于AWS的EBS，只能由一个实例来访问，通常可用来作为系统盘或启动盘。
如上图所示，Cinder 包含如下几个组件：
1. cinder-api
接收 API 请求， 调用 cinder-volume 。是整个 Cinder 组件的门户，所有 cinder 的请求都首先由 cinder-api 处理。cinder-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们可以查询 cinder-api 的 endponits。
客户端可以将请求发送到 endponits 指定的地址，向 cinder-api 请求操作。当然，作为最终用户的我们不会直接发送 Rest API 请求。OpenStack CLI，Dashboard 和其他需要跟 Cinder 交换的组件会使用这些 API。
cinder-api 对接收到的 HTTP API 请求会做如下处理：
检查客户端传人的参数是否合法有效
调用 cinder 其他子服务的处理客户端请求
将 cinder 其他子服务返回的结果序列号并返回给客户端
2. cinder-volume
管理 volume 的服务，与 volume provider 协调工作，管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。
cinder-volume 在存储节点上运行，OpenStack 对 Volume 的操作，最后都是交给 cinder-volume 来完成的。cinder-volume 自身并不管理真正的存储设备，存储设备是由 volume provider 管理的。cinder-volume 与 volume provider 一起实现 volume 生命周期的管理。
3. cinder-scheduler
scheduler 通过调度算法选择最合适的存储节点创建 volume。 创建 Volume 时，cinder-scheduler 会基于容量、Volume Type 等条件选择出最合适的存储节点，然后让其创建 Volume
4. Message Queue
Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列，子服务之间实现了解耦，这种松散的结构也是分布式系统的重要特征。
5. Cinder Database
有一些数据需要存放到数据库中，一般使用 MySQL。数据库是安装在控制节点上的，比如在我们的实验环境中，可以访问名称为“cinder”的数据库。
最后Horizon提供了基于Web的用户图形界面可以方便用户管理Nova、Swift、Keystone、Glance等等一系列的服务。正因为基于Web的访问方式，管理员不需要安装任何客户端工具，只需一个浏览器就可进行Openstack的管理工作。
上图描述了Web界面上各个元素到后端各个服务API的映射关系，当然Keystone给不同的用户分派有不同服务的不同访问权限，因此不同用户的Horizon界面也是各不相同的。
长按，识别二维码，加关注
