Openstack 笔记

一 REST

Representational State Transfer,表现状态传输,通过操作资源的表现来操作资源的状态。

二 RESTful Web API特点

1.资源地址与资源的 URI，比如：http://example.com/resources/
2.传输资源的表现形式，指的是 Web 服务接受与返回的互联网媒体类型，比如：JSON，XML 等，其中 JSON 具有轻量级的特点，移动互联网的飞速发展轻量级的协议非常受欢迎，JSON 得到了广泛的应用
3.对资源的操作，Web 服务在该资源上所支持的一系列请求方法，比如：POST,GET,PUT,DELET

三 Openstack 组件间的通讯方法

1. HTTP协议

通过各项目的 API 建立的通信关系，基本上都属于这一类，这些 API 都是 RESTful Web API，最常见的就是通过 Horizon 或者说命令行接口对各组件进行操作的时候产生的这种通信，
然后就是各组件通过 Keystone 对用户身份进行校验，进行验证的时候使用这种通信，还有比如说 Nova Compute 在获取镜像的时候和 Glance 之间，对 Glance API 的调用，
还有比方说 Swift 数据的读写，也是通过这个 HTTP 协议的 RESTful Web API 来进行的。

2. AMQP（Advanced Message Queuing Rrotocol），提供统一消息服务的应用层标准高级消息队列协议

基于 AMQP 协议进行的通信，主要是每个项目内部各个组件之间的通信，比方说 Nova 的 Nova Compute 和 Scheduler 之间，然后 Cinder 的 Scheduler 和 Cinder Volume之间。

需要说明的是，Cinder 是从 Nova Volume 演化出来的，所以 Cinder 和 Nova 之间也有通过 AMQP 协议的通信关系，由于 AMQP 协议进行通信也属于面向服务的架构，虽然大部分通过 AMQP 协议进行通信的组件属于同一个项目，但是并不要求它们安装在同一个节点上，给系统的横向扩展带来了很大的好处，可以对其中的各个组件分别按照他们负载的情况进行横向扩展，因为他们不在一个节点上，分别用不同数量的节点去承载它们的这些服务。

（ AMQP 是一种协议，OpenStack 没有规定它是用什么实现，我们经常使用的是 Private MQ，实际上用户也可以根据自身的情况选择其它的消息中间件。）

3. SQL通信

通过数据库连接实现通信，这些通信大多也属于各个项目内部，也不要求数据库和项目其它组件安装在同一个节点上，它也可以分开安装，还可以专门部署数据库服务器，把数据库服务放到上面，之间通过基于 SQL 的这些连接来进行通信。OpenStack 没有规定必须使用哪种数据库，虽然通常用的是 MySQL

4. Native API

出现在 OpenStack 各组件和第三方的软硬件之间，比如说，Cinder 和存储后端之间的通信，Neutron 的 agent 或者说插件和网络设备之间的通信，这些通信都需要调用第三方的设备或第三方软件的 API，我们称为它们为 Native API，那么这个就是我们前面说的基于第三方 API 的通信。

四 Openstack 存储

三种存储服务：Glance Swift Cinder

1 Glance

镜像存储管理服务，本身不具备存储的功能；Openstack可以使用它作为一个虚拟机启动，并且基于选择的hypervisor不同，来支持不同的镜像格式。

区别 ： Swift是一个存储系统，而Glance是一镜像注册器。
Glance是一个虚拟机镜像的跟踪和镜像源数据的关联。源数据就是那些比如内核，磁盘镜像，磁盘格式等。Glance可以使用各种各样的后端来做为存储，默认的是使用目录，但在大量的生产环境中，它常使用NFS甚至使用Swift。
Swift是一个存储系统，它是对象存储，可以用它保持数据，比如虚拟磁盘、镜像、备份归档等。

2 Cinder

Block Storage Node主要是cinder连接的存储后端，要的能力就是对虚拟机提供块级别的存储，比如虚拟机中的磁盘设备等。NFS，Ceph,GlusterFs,Postfix协议都支持。
功能：

1. 卷管理： 创建和删除卷

2. 块照管理：创建和删除卷的块照

3. 从虚拟机实例中关联或解除关联卷

4. 克隆卷

5. 创建卷的快照

6. 镜像复制到卷和卷复制到镜像

提供块存储的接口；本身也不提供数据的存储，后面也需要接一个存储的后端，像 EMC 的散设备，华为的存储设备，NetApp 的存储设备可以做它的后端。还有一个比较火的开源分布式存储叫 Ceph，Ceph 也提供块存储服务，也可以用来作为 Cinder 的后端。Cinder 的作用就是为 OpenStack 提供块存储的接口，有个很重要的功能叫卷管理功能，虚拟机并不直接去使用存储设备（并不直接去使用后端的存储系统），使用的是虚拟机上的块设备（卷 Volume），实际上 Cinder 就是创建和管理这些 Volume 并且把它挂载到虚拟机上。Cinder 是从 Nova Volume 里面独立出来的，独立出来之后很受各种存储厂商的欢迎，可以通过写 Cinder Driver 的形式把自己的存储设备纳入到 OpenStack 的生态圈里面去

3 Swift

Swift （对象存储）提供的是对象存储服务，对象存储处理数据是当成对象来处理的和检索的。基于对象的存储就是把数据分成多个块，然后把它们进行分开放在不同的容器中，该容器可以复制到不同的节点，提供一个冗余、高可靠性、自动恢复和水平扩容的能力。
优点：

1. 无中心大脑，表明不存在单点故障（Single Point Of Failure）

2. 遇见错误时，可以自动恢复。

3. 具有很高的可伸缩性，可以扩容至PB级别的存储。

4. 通过把负载分离到不同的存储节点上，可以获得很好的性能。

5. 通过非常便宜的硬件就可以实现数据群集的冗余。

具有像亚马逊 IWSS3 的特点，提供通过RESTful API 的方式去访问数据，这样做是为了解决两个问题：第一个，我们可以直接去访问一个存储，而不需要在通过自己开发的 Web 服务器去做一次数据的转发，否则对服务器的负载来说是一种压力。第二个，在我们的大数据时代，当数据量特别大的时候，如果我们用文件系统就会出现问题：文件的数量激增以后，存储的性能会急剧下降，而对象存储实际上则是解决这个问题的，对象存储抛弃了那种目录树的结构，用一种扁平化的结构去管理数据。Swift 实际上只有三层结构，即 Account、Container、Object。Object 就是最终的那个数据了，就是文件，前面有两级管理，一级是 Container 容器，它把 Object 放到容器里面，然后再上面一级是 Account，是和账户去关联的，Container 相当于是把这些 Object 做了分类，用 Account 去跟账户关联起来。

五 文件存储、块存储、对象存储

1. 有 POSIX 接口或者 POSIX 兼容的接口，就可认为它是一个文件系统，比较典型的分布式文件系统有像 Glance 的 FS，Hadoop 里的 HDFS
2. 电脑上的一个盘格式化之后是一个文件系统，那么在格式化之前是一个块设备，也就是块存储，实际上我们在数据中心里面，像 EMC 的很多设备，像华为的一些叫作 SAN 的设备，像 NetApp 的一些设备，如果是散存储一般来说就是提供块存储的
3. 对象存储的典型代表是亚马逊的 AWS S3，它的接口不是 POSIX，也不是像一块硬盘那样作为一个块存储的接口，是通过 RESTful Web API 去访问的，对于应用开发者来说优势在于可以很方便的去访问存储里面存的数据，对象存储里存的数据通常叫做 Object，实际上它就是 File，但是对象存储里面为了和文件系统做一个区别，便被叫作对象 Object。

六 Openstack 运作

1. 登录界面（hrizon）或者命令行通过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拿到认证的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的信息调用配置的虚拟化驱动来创建虚拟机。

七 Keystone

提供了认证和授权的服务，openstack不同的组件通信都要经过授权，确保正确的用户和服务是经过认证的。并且它集成了大量的认证机制，比如用户名/密码和令牌/基于系统的。并和LDAP和PAM能够进行集成。

1. User：指使用Openstack service的用户，可以是人、服务、系统，但凡使用了Openstack service的对象都可以称为User。

2. Project(Tenant)：可以理解为一个人或服务所拥有的资源集合 。在一个Project(Tenant)中可以包含多个User，每一个User都会根据权限的划分来使用Project(Tenant)中的资源。比如通过Nova创建虚拟机时要指定到某个Project中，在Cinder创建卷也要指定到某个Project中。User访问Project的资源前，必须要与该Project关联，并且指定User在Project下的Role。

3. Role：用于划分权限。可以通过给User指定Role，使User获得Role对应的操作权限。Keystone返回给User的Token包含了Role列表，被访问的Services会判断访问它的User和User提供的Token中所包含的Role。系统默认使用管理Role admin和成员Role member 。

4. Policy：OpenStack对User的验证除了OpenStack的身份验证以外，还需要鉴别User对某个Service是否有访问权限。Policy机制就是用来控制User对Tenant中资源(包括Services)的操作权限。对于Keystone service来说，Policy就是一个JSON文件，默认是/etc/keystone/policy.json。通过配置这个文件，Keystone Service实现了对User基于Role的权限管理。

5. Token：是一个字符串表示，作为访问资源的令牌。Token包含了在 指定范围和有效时间内 可以被访问的资源。EG. 在Nova中一个tenant可以是一些虚拟机，在Swift和Glance中一个tenant可以是一些镜像存储，在Network中一个tenant可以是一些网络资源。Token一般被User持有。

6. Credentials：用于确认用户身份的凭证

7. Authentication：确定用户身份的过程

8. Service：Openstack service，即Openstack中运行的组件服务。

9. Endpoint：一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。比如，当Nova需要访问Glance服务去获取image 时，Nova通过访问Keystone拿到Glance的endpoint，然后通过访问该endpoint去获取Glance服务。我们可以通过Endpoint的region属性去定义多个region。Endpoint 该使用对象分为三类：

   1. admin url –> 给admin用户使用，Post：35357
   2. internal url –> OpenStack内部服务使用来跟别的服务通信，Port：5000
   3. public url –> 其它用户可以访问的地址，Post：5000

   创建完service后创建API EndPoint. 在openstack中，每一个service都有三种end points. Admin, public, internal。 Admin是用作管理用途的，如它能够修改user/tenant(project)。 public 是让客户调用的，比如可以部署在外网上让客户可以管理自己的云。internal是openstack内部调用的。三种endpoints 在网络上开放的权限一般也不同。Admin通常只能对内网开放，public通常可以对外网开放internal通常只能对安装有openstack对服务的机器开放。

   例子：

   1. 用户alice登录keystone系统（password或者token的方式），获取一个临时的token和catalog服务目录（v3版本登录时，如果没有指定scope，project或者domain，获取的临时token没有任何权限，不能查询project或者catalog）。
   2. alice通过临时token获取自己的所有的project列表。
   3. alice选定一个project，然后指定project重新登录，获取一个正式的token，同时获得服务列表的endpoint，用户选定一个endpoint，在HTTP消息头中携带token，然后发送请求（如果用户知道project name或者project id可以直接第3步登录）。
   4. 消息到达endpoint之后，由服务端（nova）的keystone中间件（pipeline中的filter：authtoken）向keystone发送一个验证token的请求。（token类型：uuid需要在keystone验证token，pki类型的token本身是包含用户详细信息的加密串，可以在服务端完成验证）
   5. keystone验证token成功之后，将token对应用户的详细信息，例如：role，username，userid等，返回给服务端（nova）。
   6. 服务端（nova）完成请求，例如：创建虚拟机。
   7. 服务端返回请求结果给alice。

八 Nova

运行虚拟机的节点：供计算服务和响应OPenstack用户请求的虚拟机管理响应服务

主要组成

nova-api：接受和响应终端用户和计算API调用。 比如通过 Openstack API或EC2 API和Nova-api进行，去创建实例

nova-scheduler：调度服务，比如当接受到创建实例的请求后，决定应该把创建的实例放在哪个计算节点上去运行。

nova-compute：守护进程，通过Hypervisor’s API(XenAPI for XenServer, LibvirtKVM， 和 VMware API for VMware)去创建和结束 VM的实例。

nova-conductor：对计算节点提供数据库的访问，而不是直接访问数据库，因此它增强了数据库的安全。

nova-network： 对网络做一些网络方面的操作和管理（比如设置网桥接口和改变IP table规则）

九 Cinder

1 主要组成

cinder-api

cinder-scheduler

cinder-volume

2 主要功能

1. Cinder-api 是 cinder 服务的 endpoint，提供 rest 接口，负责处理 client 请求，并将 RPC 请求发送至 cinder-scheduler 组件。

2. Cinder-scheduler 负责 cinder 请求调度，其核心部分就是 scheduler_driver, 作为 scheduler manager 的 driver，负责 cinder-volume 具体的调度处理，发送 cinder RPC 请求到选择的 cinder-volume。

3. Cinder-volume 负责具体的 volume 请求处理，由不同后端存储提供 volume 存储空间。

十 Neutron

Network Node 通常是具有路由等一些网关功能的节点

1 组成

neutron-server：接受API请求和路由它们到适当的Neutron插件并执行动作。

neutron-plugin：执行实际的工作，比如创建网络和子网，和IP地址等。

neutron-agent：运行在计算和网络节点，其实就是相当于代理一样，接受别人命令，执行相应的动作。

2 功能

1. Neutron-server可以理解为一个专门用来接收Neutron REST API调用的服务器，然后负责将不同的rest api分发到不同的neutron-plugin上。

2. Neutron-plugin可以理解为不同网络功能实现的入口，各个厂商可以开发自己的plugin。Neutron-plugin接收neutron-server分发过来的REST API，向neutron database完成一些信息的注册，然后将具体要执行的业务操作和参数通知给自身对应的neutron agent。

3. Neutron-agent可以直观地理解为neutron-plugin在设备上的代理，接收相应的neutron-plugin通知的业务操作和参数，并转换为具体的设备级操作，以指导设备的动作。当设备本地发生问题时，neutron-agent会将情况通知给neutron-plugin。

4. Neutron database，顾名思义就是Neutron的数据库，一些业务相关的参数都存在这里。

5. Network provider，即为实际执行功能的网络设备，一般为虚拟交换机（OVS或者Linux Bridge）

十一 虚拟机创建的四个阶段

scheduling
networking
block_ device_mapping
spawing

十二 几种通信关系的体现

1. 各个组件 API 之间的调用，这就属于 HTTP 通信；
2. Nova 和 Neutron 内部各个组件的通信属于通过 AMQP 协议的通信；
3. 中间频繁的读写数据库的操作属于数据库连接进行通信的；
4. Nova 与 Hypervisor 或者说 Libvirt 交互属于通过 Native API 即第三方接口去进行通信的，还有一个就是在给虚拟机准备 Volume 的过程中 Cinder 还需要和存储设备进行交互，这中间也需要用到 Native API 或者是第三方接口；

十三 Openstack 部署

主要分为单节点部署 / 多节点部署

1 简单部署

三种网络和四种节点：
（1）绿色的管理网络 + 蓝色的存储网络 + 黄色的服务网络：
1. 管理网络 是 OpenStack 的管理节点或者说是它的管理服务对其它的节点去进行管理的这样一个网络，他们之间有 “不同组件之间的 API 调用，虚拟机之间的迁移” 等等；
2. 存储网络 是计算节点访问存储服务的网络，包括向存储设备里面读写数据的流量基本上都需要从存储网络走，还有另外一种是服务网络；
3. 服务网络 是由 OpenStack 去管理的虚拟机对外提供服务的网络，服务器上通常都是一台服务器上带好几块网卡，好几块网口，我们可以给各个网络做隔离。隔离的好处是，它们的流量不会交叉，比方说我们在读写存储设备的时候，可能在存储网络上的流量特别大，但是它不会影响到我们这些节点对外提供服务，同样，在我们做虚拟机迁移的时候可能在管理网络上它的数据流量会非常大，但是它同样不会影响到我们这些计算节点对存储设备的读写性能。
（2）四种节点：
1. 控制节点（OpenStack 的管理节点，OpenStack 的大部分服务都是运行在控制节点上的，比如说 Keystone 的认证服务，虚拟机镜像管理服务 Glance 等等）
2. 计算节点（计算节点指的是实际运行虚拟机的节点）
3. 存储节点（提供对象存储服务，提供对象存储的 Swift 的节点或者是 Swift 集群的 Proxy 节点，也可以是其它服务的存储后端）
4. 网络节点（实现网关和路由的功能）

有些服务可以直接部署在 Controller 节点上，但是特别需要说明的一点是： Nova 和 Neutron 这两个组件必须采用分布式部署。
Nova：Nova-Compute 是控制虚拟机的，是控制和管理虚拟机的，所以必须部署在计算节点上，而 Nova 的其它几个服务则应该部署在控制节点上，特别需要强调一点，Nova-Compute 和 Nova-Conducter 一定不能部署在同一个节点上，把这两个分开就是为了解耦。
Neutron：Neutron 的一些插件或 Agent 需要部署在网络节点和计算节点上，而其他的部分，比如说 Neutron Server 可以部署在控制节点上

2 复杂部署

1. 规模较大的情况下，把各种管理服务部署到不同的服务器上。把这些 服务拆开部署 到不同的节点上，甚至要把同 一个服务的不同组件也拆开部署，比如说可以把 Nova 的数据库给独立拧出来部署成一个 MySQL 数据库集群，还有 Cinder 里面的 Scheduler 和 Volume 可以部署到不同的节点上，实际上因为 Swift 项目具有一定的独立性，所以 Swift 本身就有跨地域部署的生产环境，规模非常之大，跨地域部署，所以它的服务的可用性极高，自然有这种栽培的特性，可以提供极高可用性和数据持久性 的对象存储服务。于是乎，很容易的对 OpenStack 的这些服务进行横向扩展，对 OpenStack 整个系统做横向扩展，这些让 OpenStack 具有比较高的负载能力，可以达到一个比较大的规模。所有的这些都得益于 OpenStack 设计的时候采用了 SO 吻合的面向服务的架构，就是 SOA 架构，具体到每个组件如何进行分布式的部署，如何进行横向扩展。
2. 出于高可用的考虑，生产环境中我们会把 OpenStack 的同一个服务部署到不同的节点上，形成双机热备或者多机热备的高可用集群。（或者用负载均衡集群）。
3. 在复杂的数据中心环境中，还有很多第三方服务，比方说 LDAP 服务、DNS 服务等等，考虑如何与第三方服务进行对接和集成。比如说，我们可能需要使用 OPEN LDAP 服务器来作为 Keystone 的认证和健全的后端，这些一般是在管理网络中去完成的。