Openstack:
一.云计算+openstack概念：
1.云计算是一种按使用量付费的模式，这种模式提供可用的，便捷的，按需的访问，通过互联网进入可配置的计算资源共享池（资源包括网络，计算，存储，应用软件，服务）；
2.OpenStack：是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。
二.Openstack组件
共享服务组件（6个）：
数据库服务（database service）:Mariadb及Mongodb
消息传输(Message Queues): RabbitMQ
缓存（cache）:Memcached
时间同步(time sync)：ntp
存储（storge provider）：ceph,GFS,LVM,ISICI等
高可用及负载均衡：pacemaker,HAproxy,keepalived,lvs
核心组件：
身份服务（Identity Service）:Keystone
计算服务（compute）:Nova
镜像服务（Image Service）:Glance
网络服务（Network）:Neutron
块存储服务（Block Storage）:Cinder
Web界面服务（Dashboard）:Horizon
对象存储（Object Storage）:Swift
测量（Metering）:Ceillrmeter
部署编排（Orchestration）:Heat
三．RabbitMQ
1.概念：属于一个流行的开源消息队列系统。属于AMQP( 高级消息队列协议 ) 标准的一个 实现。是应用层协议的一个开放标准，为面向消息的中间件设计。用于在分布式系统中存储转发消息，在 易用性、扩展性、高可用性等方面表现不俗。
2.耦合/解耦合
3.rabbitmq中的概念：
Broker：简单来说就是消息队列服务器实体。
Exchange：消息交换机，它指定消息按什么规则，路由到哪个队列。
Queue：消息队列载体，每个消息都会被投入到一个或多个队列。
Binding：绑定，它的作用就是把exchange和queue按照路由规则绑定起来。
Routing Key：路由关键字， exchange根据这个关键字进行消息投递。
vhost：虚拟主机，一个broker里可以开设多个vhost，用作不同用户的权限分离。
producer：消息生产者，就是投递消息的程序。
consumer：消息消费者，就是接受消息的程序。
channel：消息通道，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。
4.工作原理
（ 1）客户端连接到消息队列服务器，打开一个channel。
（ 2）客户端声明一个exchange，并设置相关属性。
（ 3）客户端声明一个queue，并设置相关属性。
（ 4）客户端使用routing key，在exchange和queue之间建立好绑定关系。
（ 5）客户端投递消息到exchange。
（ 6） exchange接收到消息后，就根据消息的key和已经设置的binding，进行消息路由，将消息投递到一个或多个队列里。
5.rabbitmq集群部署: 注意必须至少要有一个disk node
四.Memcache
1.概念：
Memcached 是一个开源的、高性能的分布式内存对象缓存系统。通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高网站访问速度，加速动态WEB应用、减轻数据库负载。
2.缓存流程：
(1). 检查客户端请求的数据是否在 Memcache 中，如果存在，直接将请求的数据返回，不在对数据进行任何操作。
(2).如果请求的数据不在 Memcache 中，就去数据库查询，把从数据库中获取的数据返回给客户端，同时把数据缓存一份 Memcache 中
(3).每次更新数据库的同时更新 Memcache 中的数据库。确保数据信息一致性。
(4).当分配给 Memcache 内存空间用完后，会使用LRU(least Recently Used ，最近最少使用 ) 策略加到其失效策略，失效的数据首先被替换掉，然后在替换掉最近未使用的数据
五．Keystone
1.概念：
用于为OpenStack家族中的其它组件成员提供统一的认证服务，包括身份验证、令牌的发放和校验、服务列表、用户权限的定义等。云环境中所有的服务之间的授权和认证都需要经过 keystone.
(1).管理用户及其权限；
(2).维护 OpenStack Services 的 Endpoint；
(3).Authentication（认证）和 Authorization（鉴权）
2.keystone中概念：
(1).user：指代任何使用open stack的实体，可以是真正的用户，其他系统或服务；
(2).Credentials:是user用来证明自己身份的信息，可以是1. 用户名/密码；2.Token；3. API Key；4. 其他高级方式.
(3). Authentication：是 Keystone 验证 User 身份的过程。User 访问 OpenStack时向 Keystone 提交用户名和密码形式的 Credential，Keystone 验证通过后会给 User 签发一个 Token 作为后续访问的 Credential。
(4).Token: Token 是由数字和字母组成的字符串,user成功Authentication后成Token并分配给user。Token用作访问Service的Credential;Service会通过Keystone验证Token的有限性；Token的有效期默认24小时。
(5).Project:用于将open stack的资源进行分组和隔离。根据openstack的服务对象不同，project可以是一个客户,部门或者项目组。
(6).Service：包括nova,glance,cinder,neutron等，每个service会提供若干个Endpoint,user通过Endpoint访问资源和执行操作。
(7).Endpoint:是一个网络上可访问的地址，通常是一个URL。Service通过Endpoint暴露自己的API，Keystone负责管路和维护每个service的Endpoint.
(8).Role:可以为user分配一个或多个Role,Service决定每个role能做什么事，系统基本角色有两个：管理员admin和租户_member_
3.Keystone基本框架
Token: 用来生成和管理token
Catalog: 用来存储和管理service/endpoint
Identity: 用来管理tenant/user/role和验证
Policy： 用来管理访问权限
4.通过’查询可用image’这个实际操作让大家更加清晰keystone的工作过程及原理：
第一步：登入。
用户admin拿着credential请求登入，Authentication认证通过，并给admin用户一个token;
第二步：显示操作界面。
进入操作界面后，这时admin需要访问image服务。在访问image前发生了：admin询问keystone询问到了能访问admin和demo两个project,同时可以访问instance,Volume,glance等服务。因为这时admin已经从keystone拿到了service的Endpoints.
第三步：显示image列表。
Admin要查看project admin中的image，先是把将请求发送到Glance的Endpoint,Glance向keystone询问admin身份是否有效，接下来Glance会查看/etc/glance/policy.json判断admin是否有查看image的权限。权限判定后，Glance将image列表发给admin。
5.keystone主要有两个日志：keystone.log和keystone_access.log,保存在/var/log/apache2/目录里
6.集群搭建图
六．Glance
1.glance介绍：是openstack项目中负责镜像管理的模块，其功能包括虚拟机镜像的查找，注册和检索等。Glance提供restful api可以查询虚拟机镜像的metadata及获取镜像。Glance可以将镜像保存到多种后端存储上，比如简单的文件存储或者对象存储。
2.Glance架构
Glance-api
Glance-api是系统后台运行的服务进程，对外提供REST API,响应Image查询，获取和存储的调用。Glance-api不会真正处理请求，如果操作是与image metadata相关，glance-api会把请求转发给glance-registry;如果操作是与image自身存取相关，glance-api会把请求转发给image的store backend.
Glance-registry
Glance-registry是系统后台运行的服务进程，负责处理和存取image的metadata，例如image的大小和类型。Glance支持多种格式的image，比较常用的有：Raw,vmdk,ISO,QCOW2.Image的metadata会保持到database中，默认是MySQL。
Store backend
Glance自己并不存储image，真正的image是存放在backend中。Glance支持多种backend,默认是：A directory on a local file system（Filesystem）具体使用哪种backend，实在/etc/glance/glance-api.conf 中配置。
3.创建Image
方法一：在web界面中创建（步骤见博客）
方法二：在命令行创建
1. 将image上传到控制节点的文件系统中，例如： /tmp/cirros-0.3.5-x86_64-disk.img
2. glance image-create --name cirros1 --file /tmp/cirros-0.3.5-x86_64-disk.img --disk-format qcow2 --container-format bare --progress
一般创建比较大的镜像用命令行创建会更快和方便。
Image放在/var/lib/glance/images/下
4.glance日志：glance_api.log 和glance_registry.log,保存/var/log/glance目录中
七．Nova
1.nova介绍：是openstack最核心的服务，负责维护和管理云计算计算资源。
从上图可以看出，nova处于openstack架构的中心，其他组件都为nova提供支持glance为VM提供image，cinder和swift分别为VM提供块存储和对象存储，neutron提供网络连接。
2.nova组件介绍
1.nova-api：
是整个nova的门户，所有对nova的请求都首先由nova-api处理。Nova-api向外暴露若干HTTP rest api 接口在keystone中，客户端可以将请求发送到endpoint指定的地址，向nova-api请求操作。
Nova-api对收到的HTTP api请求会做如下处理：
(1).检查客户端传入的参数是否合法；
(2).调用nova其他子服务的处理客户端HTTP请求；
(3).格式化nova其他子服务返回的结果并返回给客户端。
2.nova-conductor：
Nova-compute需要获取和更新数据库中instance的信息，但nova-compute并不会直接访问数据库，而是通过nova-conductor实现数据的访问。
使用nova-conductor的两个显著好处：
(1).更好的系统安全性：早期的openstack版本中，nova-compute可以直接访问数据库，但试想如果任意一个计算节点被黑客入侵，都会导致控制节点上的数据库面临极大的风险。为了解决这个问题，引入了nova-conductor；
(2)更好的伸缩性：nova-conductor建立后，提高了nova的伸缩性。Nova-compute与conductor是通过消息中间件交互的。这种松散的架构允许配置多个nova-conductor实例，从而应对日益增长的计算节点对数据库的访问。
3.nova-scheduler
虚拟机调度服务，负责决定在哪个计算节点上运行虚机。
如何选择计算节点——启动实例调度策略
Filter scheduler(调度器)，调度过程分两步：
(1).通过过滤器（filter）选择满足条件的计算节点（运行nova-compute）
(2).通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建instance
Filter具体有哪些:
RetryFilter
AvailabilityZoneFilter
RamFilter
DiskFilter
CoreFilter
ComputeFilter
ComputeCapabilitiesFilter
ImagePropertiesFilter
ServerGroupAntiAffinityFilter
ServerGroupAffinityFilter
Weight: 默认实现是根据计算节点空闲的内存量计算权重值： 空闲内存越多，权重越大，instance 将被部署到当前空闲内存最多的计算节点上。
4.nova-compute（装在计算节点上）
nova-compute 在计算节点上运行，负责管理节点上的 instance。OpenStack 对 instance 的操作，最后都是交给 nova-compute 来完成的。nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。
5.Console Interface
nova-console:
用户可以通过多种方式访问虚机的控制台：
nova-novncproxy，基于 Web 浏览器的 VNC 访问
nova-spicehtml5proxy，基于 HTML5 浏览器的 SPICE 访问
nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问
nova-consoleauth
负责对访问虚机控制台请求提供 Token 认证
nova-cert
提供 x509 证书支持
3.从创建虚机流程看nova子服务如何协同工作
1.客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”
2.API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”
3.Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
4.Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”
5.计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
6.在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。
在前面创建虚机的流程示意图中，我们看到 nova-* 子服务之间的调用严重依赖 Messaging。Messaging 是 nova-* 子服务交互的中枢。
以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler，或是让Scheuler 直接调用 Compute，而是非要通过 Messaging 进行中转。 这里做一些解释。程序之间的调用通常分两种：同步调用和异步调用。
同步调用
API 直接调用 Scheduler 的接口是同步调用。 其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。
异步调用
API 通过 Messaging 间接调用 Scheduler 就是异步调用。 其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。 Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是：
1.解耦各子服务。 子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用。
2.提高性能 异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量。
3.提高伸缩性 子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。
4.实现 instance 生命周期的管理
nova-compute 创建 instance 的过程可以分为 4 步：
(1).为 instance 准备资源
(2).创建 instance 的镜像文件
(3).创建 instance 的 XML 定义文件
(4).创建虚拟网络并启动虚拟机
5.Nova 创建虚拟机详细过程
1.界面或命令行通过RESTful API向keystone获取认证信息。
2、keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
3、界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
4、nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
5、keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
6、通过认证后nova-api和数据库通讯。
7、初始化新建虚拟机的数据库记录。
8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
9、nova-scheduler进程侦听消息队列，获取nova-api的请求。
10、nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
11、对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
15、nova-conductor从消息队队列中拿到nova-compute请求消息。
16、nova-conductor根据消息查询虚拟机对应的信息。
17、nova-conductor从数据库中获得虚拟机对应信息。
18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19、nova-compute从对应的消息队列中获取虚拟机信息消息。
20、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
21、glance-api向keystone认证token是否有效，并返回验证结果。
22、token验证通过，nova-compute获得虚拟机镜像信息(URL)。
23、nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24、neutron-server向keystone认证token是否有效，并返回验证结果。
25、token验证通过，nova-compute获得虚拟机网络信息。
26、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
27、cinder-api向keystone认证token是否有效，并返回验证结果。
28、token验证通过，nova-compute获得虚拟机持久化存储信息。
29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。
九．Horizon
1.区域（Region）
(1).地理上的概念，可以理解为一个独立的数据中心，每个所定义的区域有自己独立的Endpoint；
(2).区域之间是完全隔离的，但多个区域之间共享同一个Keystone和Dashboard(目前Openstack中的Dashboard还不支持多个区域)；
(3).除了提供隔离的功能，区域的设计更多侧重地理位置的概念，用户可以选择离自己更新的区域来部署自己的服务,选择不同的区域主要是考虑那个区域更靠近自己，如用户在美国，可以选择离美国更近的区域；
(4).区域的概念是由Amazon在AWS中提出,主要是解决容错能力和可靠性；
2.可用性区域（Availablilty Zone）
AZ是在Region范围内的再次切分，例如可以把一个机架上的服务器划分为一个AZ，划分AZ是为了提高容灾能力和提供廉价的隔离服务；
3.Host Aggreates
一组具有共同属性的节点集合，如以CPU作为区分类型的一个属性，以磁盘（SSD\SAS\SATA）作为区分类型的一个属性，以OS（Windows\Linux）为作区分类型的一个属性；
4.Cell
nova为了增加横向扩展以及分布式、大规模（地理位置级别）部署的能力，同时又不增加数据库和消息中间件的复杂度，引入了cell的概念，并引入了nova-cell服务。
(1).主要是用来解决OpenStack的扩展性和规模瓶颈；
(2).每个Cell都有自己独立的DB和AMQP，不与其他模块共用DB和AMQP,解决了大规模环境中DB和AMQP的瓶颈问题；
(3).Cell实现了树形结构（通过消息路由）和分级调度（过滤算法和权重算法），Cell之间通过RPC通讯，解决了扩展性问题；
十．Cinder
1.cinder架构
Cinder-api：接收 API 请求，调用 cinder-volume ；
Cinder-volume：管理 volume 的服务，与 volume provider 协调工作，管理 volume 的生命周期。运行 cinder-volume 服务的节点被称作为存储节点。
cinder-scheduler：scheduler 通过调度算法选择最合适的存储节点创建 volume。
volume provider：数据的存储设备，为 volume 提供物理存储空间。 cinder-volume 支持多种 volume provider，每种 volume provider 通过自己的 driver 与cinder-volume 协调工作。
Message Queue：Cinder 各个子服务通过消息队列实现进程间通信和相互协作。因为有了消息队列，子服务之间实现了解耦，这种松散的结构也是分布式系统的重要特征。
Database Cinder ：有一些数据需要存放到数据库中，一般使用 MySQL。数据库是安装在控制节点上。
2.从volume创建流程看cinder子服务如何协同工作：
1.客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（cinder-api）发送请求：“帮我创建一个 volume”；
2.API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个 volume”
3.Scheduler（cinder-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计存储点中选出节点 A
4.Scheduler 向 Messaging 发送了一条消息：“让存储节点 A 创建这个 volume”
5.存储节点 A 的 Volume（cinder-volume）从 Messaging 中获取到 Scheduler 发给它的消息，然后通过 driver 在 volume provider 上创建 volume。
数据持久化
如果您想创建一个使用临时存储的实例，意味着当实例被删除时数据会丢失，那么从以下启动项中选择一个：
镜像:本选项使用一个镜像启动实例。
实例快照:此选项使用一个实例快照来启动实例。
如果您想创建一个使用持久存储的实例，意味着当实例被删除时数据被保存，那么选择从以下启动项中选择一个
镜像（带有选中“创建新卷”）：此选项使用镜像来启动实例，并且创建一个新卷来持久化实例数据。您可以指定卷大小并指定在删除实例时是否删除实例。
卷：这个选项使用一个已存在的卷。它不创建新卷。您可以选择在删除实例时删除卷。注意：当选择卷时，您只能启动一个实例。
卷快照：此选项使用卷快照启动实例，并且创建一个新卷来持久化实例数据。您可以选择在删除实例时删除卷。