一、OpenStack架构

1.1 OpenStack概念架构

• 中间菱形：是虚拟机，围绕 VM 的那些长方形代表 OpenStack 不同的模块或服务；
• Nova（计算服务，核心服务）：管理 管理计算资源，是 OpenStack 中最核心的服务；
• Neutron（网络服务，核心服务）：为 OpenStack 提供网络连接服务，负责创建和管理L2、L3 网络， 为 VM 提供虚拟网络和物理网络连接；
• Glance（镜像服务，核心服务）：管理 VM 的启动镜像，Nova 创建 VM 时将使用 Glance 提供的镜像；
• Cinder（块存储，核心服务）：为 VM 提供块存储服务。Cinder 提供的每一个 Volume 在 VM 看来是一块虚拟硬盘，一般用作数据盘；
• Swift（对象存储，可选服务）：提供对象存储服务。VM 可以通过 RESTful API 存放对象数据；作为可选的方案，Glance 可以将镜像存放在 Swift 中；Cinder 也可以将 Volume 备份到 Swift 中；
• Keystone（认证服务，核心服务）：为 OpenStack 的各种服务提供认证和权限管理服务。简单的说，OpenStack 上的每一个操作都必须通过 Keystone 的审核；
• Ceilometer（监控服务，可选服务）：提供 OpenStack监控和计量服务，为报警、统计或计费提供数据；
• Horizon：为 OpenStack 用户提供一个 Web操作界面；

1.2 OpenStack逻辑架构

• 在逻辑架构中，可以看到每个服务又由若干组件组成：
  
• 上图逻辑架构中，以 Neutron 服务为例，描述了各个组成部分以及各组件之间的逻辑关系。 而在实际的部署方案上，各个组件可以部署到不同的物理节点上。
• OpenStack 本身是一个分布式系统，不但各个服务可以分布部署，服务中的组件也可以分布部署。 这种分布式特性让 OpenStack 具备极大的灵活性、伸缩性和高可用性。

1.3 拓扑部署

• OpenStack 是一个分布式系统，由若干不同功能的节点（Node）组成：
  1）控制节点（Controller Node）：管理 OpenStack，其上运行的服务有 Keystone、Glance、Horizon 以及 Nova 和 Neutron 中管理相关的组件。 控制节点也运行支持 OpenStack 的服务，例如 SQL 数据库（通常是 MySQL）、消息队列（通常是 RabbitMQ）和网络时间服务 NTP。
  2）计算节点（Compute Node）：其上运行 Hypervisor（默认使用 KVM）。 同时运行 Neutron 服务的 agent，为虚拟机提供网络支持。
  3） 网络节点（Network Node）：其上运行的服务为 Neutron。 为 OpenStack 提供 L2 和 L3 网络。 包括虚拟机网络、DHCP、路由、NAT 等。
  4） 存储节点（Storage Node）：提供块存储（Cinder）或对象存储（Swift）服务。
• 这几类节点是从功能上进行的逻辑划分，在实际部署时可以根据需求灵活配置，比如：在大规模OpenStack生产环境中，每类节点都分别部署在若干台物理服务器上，各司其职并互相协作。 这样的环境具备很好的性能、伸缩性和高可用性。在最小的实验环境中，可以将 4 类节点部署到一个物理的甚至是虚拟服务器上，通常也称为 All-in-One 部署。
• 在我们的实验环境中，为了使得拓扑简洁同时功能完备，我们用两个虚拟机：
  devstack-controller： 控制节点 + 网络节点 + 块存储节点 + 计算节点
  devstack-compute： 计算节点
  
• 物理资源需求，可根据实际需求动态调整：
  
• 网络规划：
  
  网络上规划了三个网络
  1）Management Network：用于 OpenStack 内部管理用，比如各服务之间通信。 这里使用 eth0；
  2）VM（Tenant）Network：OpenStack 部署的虚拟机所使用的网络。OpenStack 支持多租户（Tenant），虚机是放在 Tenant 下的，所以叫 Tenant Network。 这里使用 eth1；
  3）External Network：一般来说，Tenant Network 是内部私有网络，只用于 VM 之间通信，与其他非 VM 网络是隔离的。这里我们规划了一个外部网络（External Network），通过 devstak-controller 的 eth2 连接。 Neutron 通过 L3 服务让 VM 能够访问到 External Network。对于公有云，External Network 一般指的是 Internet。对于企业私有云，External Network 则可以是 Intranet 中的某个网络。
• 创建虚拟机：按照物理资源需求创建 devstack-controller 和 devstak-compute 虚拟机：
  安装操作系统
  安装 Ubuntu 14.04，并配置 eth0 的 IP，如下所示：

控制节点 devstack-controller  192.168.104.10
计算节点 devstak-compute      192.168.104.11

参考：https://www.xjimmy.com/openstack-5min-17.html

1.4 使用OpenStack CLI

1.4.1 OpenStack 服务都有自己的 CLI

• 命令很好记，就是服务的名字，比如 Glance 就是 glance，Nova 就是 nova。但 Keystone 比较特殊，现在是用 openstack 来代替老版的 keystone 命令。比如查询用户列表，如果用 keystone user-list：
  会提示 keystone 已经 deprecated 了，用 openstack user list 命令代替：
  
• 执行命令之前，需要设置环境变量：
  这些变量包含用户名、Project、密码等； 如果不设置，每次执行命令都必须设置相关的命令行参数
• 各个服务的命令都有增、删、改、查的操作，其格式是：

CMD <obj>-create [parm1] [parm2]…
CMD <obj>-delete [parm]
CMD <obj>-update [parm1] [parm2]…
CMD <obj>-list
CMD <obj>-show [parm]

• 例如 glance 管理的是 image，那么：CMD 就是 glance；obj 就是 image，对应的命令就有：

glance image-create
glance image-delete
glance image-update
glance image-list
glance image-show

• 再比如 neutron 管理的是网络和子网等，那么： CMD 就是 neutron；obj 就是 net 和 subnet ：

# 网络相关操作
neutron net-create
neutron net -delete
neutron net -update
neutron net -list
neutron net –show

# 子网相关操作
neutron subnet-create
neutron subnet -delete
neutron subnet -update
neutron subnet -list
neutron subnet–show

• 有的命令 可以省略，比如 nova，下面的操作都是针对 instance：

nova boot
nova delete
nova list
nova show

• 没个对象都有ID：delete，show 等操作都以 ID 为参数，例如：
  
• 可用 help 查看命令的用法，除了 delete，show 等操作只需要 ID 一个参数，其他操作可能需要更多的参数，用 help 查看所需的参数，格式是：

CMD help [SUB-CMD]

例如查看 glance 都有哪些 SUB-CMD：
查看 glance image-update 的用法：

二、OpenStack核心服务

2.1 认证服务Keystone

2.1.1 基本功能

• 作为 OpenStack 的基础支持服务，Keystone 做下面这几件事情：
  1）管理用户及其权限；
  2）维护 OpenStack Services 的 Endpoint；
  3）Authentication（认证）和 Authorization（鉴权）。

2.1.2 基本概念

• user：指代任何使用 OpenStack 的实体，可以是真正的用户，其他系统或者服务，当 User 请求访问 OpenStack 时，Keystone 会对其进行验证；
  Horizon 在 Identity->Users 管理 User：
  
  除了 admin 和 demo，OpenStack 也为 nova、cinder、glance、neutron 服务创建了相应的 User。 admin 也可以管理这些 User。
  
• Credentials：Credentials 是 User 用来证明自己身份的信息，可以是： 1. 用户名/密码 2. Token 3. API Key 4. 其他高级方式。
• Authentication： 是 Keystone 验证 User 身份的过程。User 访问 OpenStack 时向 Keystone 提交用户名和密码形式的 Credentials，Keystone 验证通过后会给 User 签发一个 Token 作为后续访问的 Credential。
• Token：Token 是由数字和字母组成的字符串，User 成功 Authentication 后由 Keystone 分配给 User。Token 用做访问 Service 的 Credential；Service 会通过 Keystone 验证 Token 的有效性；Token 的有效期默认是 24 小时。
• Project： 用于将 OpenStack 的资源（计算、存储和网络）进行分组和隔离。根据 OpenStack 服务的对象不同，Project 可以是一个客户（公有云，也叫租户）、部门或者项目组（私有云）。这里请注意：资源的所有权是属于 Project 的，而不是 User。在 OpenStack 的界面和文档中，Tenant / Project / Account 这几个术语是通用的，但长期看会倾向使用 Project。每个 User（包括 admin）必须挂在 Project 里才能访问该 Project 的资源。 一个User可以属于多个 Project。admin 相当于 root 用户，具有最高权限
  Horizon 在 Identity->Projects 中管理 Project：
  
  通过 Manage Members 将 User 添加到 Project 中：
  
• Service：OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。每个 Service 都会提供若干个 Endpoint，User 通过 Endpoint 访问资源和执行操作。
• Endpoint：Endpoint 是一个网络上可访问的地址，通常是一个 URL。Service 通过 Endpoint 暴露自己的 API。Keystone 负责管理和维护每个 Service 的 Endpoint。
  可以使用下面的命令来查看 Endpoint：

root@devstack-controller:~# source devstack/openrc admin admin //切换用户
root@devstack-controller:~# openstack catalog list //查询服务的Endpoint

• Role：安全包含两部分：Authentication（认证）和 Authorization（鉴权）。Keystone 是借助 Role 来实现 Authorization 的。
  Keystone定义Role：
  
  可以为 User 分配一个或多个 Role，Horizon 的菜单为 Identity->Project->Manage Members：
  Service 决定每个 Role 能做什么事情 Service 通过各自的 policy.json 文件对 Role 进行访问控制。下面是 Nova 服务 /etc/nova/policy.json 中的示例：
  
  上面配置的含义是：对于 create、attach_network 和 attach_volume 操作，任何Role的 User 都可以执行； 但只有 admin 这个 Role 的 User 才能执行 forced_host 操作。OpenStack 默认配置只区分 admin 和非 admin Role。 如果需要对特定的 Role 进行授权，可以修改 policy.json。

2.1.3 举例说明：admin用户查看Project中的image

• 登录：账号密码为admin/admin，点击“Connect”：
  
  此时OpenStack 内部发生了哪些事情？请看下面：Token 中包含了 User 的 Role 信息。
  
• 显示操作界面：请注意，顶部显示 admin 可访问的 Project 为 “admin” 和 “demo”。
  
  在此之前发生了什么事情：
  
  同时，admin 可以访问 Intance, Volume, Image 等服务
  
  因为 admin 已经从 Keystone 拿到了各 Service 的 Endpoints
  
• 显示image列表：点击 “Images”，会显示 image 列表；
  
  背后发生了这些事：首先，admin 将请求发送到 Glance 的 Endpoint：
  
  Glance 向 Keystone 询问 admin 身份的有效性：
  
  接下来 Glance 会查看 /etc/glance/policy.json，判断 admin 是否有查看 image 的权限：
  
  权限判定通过，Glance 将 image 列表发给 admin。
• Troubleshoot ：OpenStack 排查问题的方法主要是通过日志，每个 Service 都有自己的日志文件。Keystone 主要有两个日志：keystone.log 和 keystone_access.log，保存在 /var/log/apache2/ 目录里。
  devstack 的 screen 窗口已经帮我们打开了这两个日志。可以直接查看：
  
  如果需要得到最详细的日志信息，可以在 /etc/keystone/keystone.conf 中打开 debug 选项：
  
  在非 devstack 安装中，日志可能在 /var/log/keystone/ 目录里。

2.2 镜像服务Image

2.2.1 基本概念

• 在传统 IT 环境下，安装一个系统是要么从安装 CD 从头安装，要么用 Ghost 等克隆工具恢复，这两种方式有如下几个问题：
  1）如果要安装的系统多了效率就很低；
  2）时间长，工作量大；
  3）安装完还要进行手工配置，比如安装其他的软件，设置 IP 等；
  4）备份和恢复系统不灵活。
• 云环境下需要更高效的解决方案，这就是 Image：
  Image 是一个模板，里面包含了基本的操作系统和其他的软件。 举例来说，有家公司需要为每位员工配置一套办公用的系统，一般需要一个 Win7 系统再加 MS office 软件。
  OpenStack 是这么玩的，先手工安装好这么一个虚机；然后对虚机执行 snapshot，这样就得到了一个 image；当有新员工入职需要办公环境时，立马启动一个或多个该 image 的 instance（虚机）就可以了。
• 在这个过程中，第 1 步跟传统方式类似，需要手工操作和一定时间。但第 2、3 步非常快，全自动化，一般都是秒级别。而且 2、3 步可以循环做。比如公司新上了一套 OA 系统，每个员工的 PC 上都得有客户端软件。 那么可以在某个员工的虚机中手工安装好 OA 客户端，然后执行snapshot ，得到新的 image，以后就直接使用新 image 创建虚机就可以了。
• 另外，snapshot 还有备份的作用，能够非常方便的恢复系统。
• Image Service 的功能是管理 Image，让用户能够发现、获取和保存 Image。在 OpenStack 中，提供 Image Service 的是 Glance，其具体功能如下：
  1）提供 REST API 让用户能够查询和获取 image 的元数据和 image 本身；
  2）支持多种方式存储 image，包括普通的文件系统、Swift、Amazon S3 等；
  3）对 Instance 执行 Snapshot 创建新的 image。

2.2.2 Glance架构

2.2.2.1 glance-api

• glance-api 是系统后台运行的服务进程。 对外提供 REST API，响应 image 查询、获取和存储的调用。
• glance-api 不会真正处理请求。
• 如果是与 image metadata（元数据）相关的操作，glance-api 会把请求转发给 glance-registry；
• 如果是与 image 自身存取相关的操作，glance-api 会把请求转发给该 image 的 store backend。
• 在控制节点上可以查看 glance-api 进程：
  

2.2.2.2 glance-registry

• glance-registry 是系统后台运行的服务进程。负责处理和存取 image 的 metadata，例如 image 的大小和类型。在控制节点上可以查看 glance-registry 进程：
  
• Glance 支持多种格式的 image，包括：
  

2.2.2.3 Database

• Image 的 metadata 会保存到 database 中，默认是 MySQL。在控制节点上可以查看 glance 的 database 信息：
  

2.2.2.4 Store backend

• Glance 自己并不存储 image。 真正的 image 是存放在 backend 中的。 Glance 支持多种 backend，包括：
  1）A directory on a local file system（这是默认配置）；
  2）GridFS；
  3）Ceph RBD；
  4）Amazon S3；
  5）Sheepdog；
  6）OpenStack Block Storage (Cinder)；
  7）OpenStack Object Storage (Swift)；
  8）VMware ESX。
  具体使用哪种 backend，是在 /etc/glance/glance-api.conf 中配置的，在我们的 devstack 环境中，image 存放在控制节点本地目录 /opt/stack/data/glance/images/ 中：
  
  其他 backend 的配置可参考：https://docs.openstack.org/liberty/config-reference/content/configuring-image-service-backends.html
• 查看目前已经存在的 image使用glance image-list：
  
• 查看保存目录：每个 image 在目录下都对应有一个文件，文件以 image 的 ID 命名。
  

2.2.3 Glance操作

• OpenStack 为终端用户提供了 Web UI（Horizon）和命令行 CLI 两种方式创建Image。

2.2.3.1 Web UI操作

2.2.3.1.1 Web UI 创建 image

• admin 登录后，Project -> Compute -> Images:
  

• 点击右上角“Create Image”按钮，为新 image 命名:
  这里我们上传一个 image。 点击“浏览”，选择镜像文件 cirros-0.3.4-x86_64-disk.img。cirros 是一个很小的 linux 镜像，非常适合测试用。 可以到http://download.cirros-cloud.net/下载。

• 格式选择 QCOW2：
  如果勾选“Public”，该 image 可以被其他 Project 使用；如果勾选“Protected”，该 image 不允许被删除。

• 点击“Create Image”，文件上传到 OpenStack 并创建新的 image：
  

• 点击 image 的“cirros链接”：
  显示详细信息
  

2.2.3.1.2 Web UI 删除 image

• admin 登录后，Project -> Compute -> Images：
  点击“Delete Images”确认删除，操作成功：
  

2.2.3.2 CLI操作

2.2.3.2.1 CLI 创建 image

• cirros 这个 linux 镜像很小，通过 Web UI 上传很快，操作会很顺畅。 但如果我们要上传的镜像比较大（比如好几个 G ），那么操作会长时间停留在上传的 Web 界面，我们也不知道目前到底处于什么状态。对于这样的操作，CLI 是更好的选择。
• 将 image 上传到控制节点的文件系统中，例如 /tmp/cirros-0.3.4-x86_64-disk.img：
• 设置环境变量：
  Devstack 的安装目录下有个 openrc 文件。source 该文件就可以配置 CLI 的环境变量。这里我们传入了两个参数，第一个参数是 OpenStack 用户名 admin；第二个参数是 Project 名 admin。
• 执行 image 创建命令：

glance image-create --name cirros --file /tmp/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --progress

在创建 image 的 CLI 参数中我们用 –progress 让其显示文件上传的百分比 %。在 /opt/stack/data/glance/images/ 下查看新的 Image：

2.2.3.2.2 CLI 删除 image

• 设置环境变量：
  
• 查询现有image：
  
• 删除image采用glance image-delete 镜像ID：
  

2.2.4 如何 Troubleshooting

• OpenStack 排查问题的方法主要是通过日志，Service 都有自己单独的日志。Glance 主要有两个日志，glance_api.log 和 glance_registry.log，保存在 /opt/stack/logs/ 目录里。devstack 的 screen 窗口已经帮我们打开了这两个日志，可以直接查看：
  
• g-api 窗口显示 glance-api 日志，记录 REST API 调用情况；g-reg 窗口显示 glance-registry 日志，记录 Glance 服务处理请求的过程以及数据库操作。如果需要得到最详细的日志信息，可以在 /etc/glance/*.conf 中打开 debug 选项。devstack 默认已经打开了 debug。
  
• 在非 devstack 安装中，日志在 /var/log/glance/ 目录里。

2.3 计算服务Nova

• Compute Service Nova 是 OpenStack 最核心的服务，负责维护和管理云环境的计算资源。OpenStack 作为 IaaS 的云操作系统，虚拟机生命周期管理也就是通过 Nova 来实现的。
  
  在上图中可以看到，Nova 处于 Openstak 架构的中心，其他组件都为 Nova 提供支持。Glance 为 VM 提供 image；Cinder 和 Swift 分别为 VM 提供块存储和对象存储 ；Neutron 为 VM 提供网络连接。

2.3.1 Nova架构

2.3.1.1 API

• nova-api：接收和响应客户的 API 调用。
  除了提供 OpenStack 自己的API，nova-api 还支持 Amazon EC2 API。也就是说，如果客户以前使用 Amazon EC2，并且用 EC2 的 API 开发工具来管理虚机，那么如果现在要换成 OpenStack，这些工具可以无缝迁移到OpenStack，因为 nova-api 兼容 EC2 API，无需做任何修改。

2.3.1.2 Compute Core

• nova-scheduler：虚机调度服务，负责决定在哪个计算节点上运行虚机；
• nova-compute：管理虚机的核心服务，通过调用 Hypervisor API 实现虚机生命周期管理；
• Hypervisor：计算节点上跑的虚拟化管理程序，虚机管理最底层的程序。 不同虚拟化技术提供自己的 Hypervisor。 常用的 Hypervisor 有 KVM，Xen，VMWare 等；
• nova-conductor：nova-compute 经常需要更新数据库，比如更新虚机的状态。出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。

2.3.1.3 Console Interface

• nova-console：用户可以通过多种方式访问虚机的控制台：
  1）nova-novncproxy，基于 Web 浏览器的VNC 访问；
  2）nova-spicehtml5proxy，基于HTML5 浏览器的 SPICE 访问；
  3）nova-xvpnvncproxy，基于 Java 客户端的 VNC 访问；
• nova-consoleauth：负责对访问虚机控制台请求提供 Token 认证；
• nova-cert：提供 x509 证书支持。

2.3.1.4 Database

• Nova 会有一些数据需要存放到数据库中，一般使用 MySQL。数据库安装在控制节点上。 Nova 使用命名为 “nova” 的数据库。
  

2.3.1.5 Message Queue

• 在前面我们了解到 Nova 包含众多的子服务，这些子服务之间需要相互协调和通信。 为解耦各个子服务，Nova 通过 Message Queue 作为子服务的信息中转站。 所以在架构图上我们看到了子服务之间没有直接的连线，它们都通过 Message Queue 联系。
  
  OpenStack 默认是用 RabbitMQ 作为 Message Queue。MQ 是 OpenStack 的核心基础组件。

2.3.2 Nova 物理部署方案

• 对于 Nova，这些服务会部署在两类节点上：计算节点和控制节点。计算节点上安装了 Hypervisor，上面运行虚拟机，由此可知：只有 nova-compute 需要放在计算节点上。其他子服务则是放在控制节点上的。
• 实验环境的具体部署情况 ：
  通过在计算节点和控制节点上运行 ps -elf|grep nova 来查看运行的 nova 子服务：
  1）计算节点上只运行了nova-compute自服务：
  
  2）控制节点上运行了若干 nova-* 子服务，RabbitMQ 和 MySQL 也是放在控制节点上的，我们发现的控制节点上也运行了 nova-compute：这实际上也就意味着controller 既是一个控制节点，同时也是一个计算节点，也可以在上面运行虚机。
  
  
  这也向我们展示了 OpenStack 这种分布式架构部署上的灵活性： 可以将所有服务都放在一台物理机上，作为一个 All-in-One 的测试环境； 也可以将服务部署在多台物理机上，获得更好的性能和高可用。
  另外，可以用 nova service-list 查看 nova-* 子服务都分布在哪些节点上：
  

2.3.3 从虚机创建流程看 nova-* 子服务如何协同工作

• 从学习 Nova 的角度看，虚机创建是一个非常好的场景，涉及的 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 上启动虚机；
  5）在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

2.3.4 OpenStack 通用设计思路

2.3.4.1 API 前端服务

• 每个 OpenStack 组件可能包含若干子服务，其中必定有一个 API 服务负责接收客户请求。以 Nova 为例，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。当客户需要执行虚机相关的操作，能且只能向 nova-api 发送 REST 请求。这里的客户包括终端用户、命令行和 OpenStack 其他组件。
• 设计 API 前端服务的好处在于：对外提供统一接口，隐藏实现细节；API 提供 REST 标准调用服务，便于与第三方系统集成；可以通过运行多个 API 服务实例轻松实现 API 的高可用，比如运行多个 nova-api 进程。

2.3.4.2 Scheduler 调度服务

• 对于某项操作，如果有多个实体都能够完成任务，那么通常会有一个scheduler 负责从这些实体中挑选出一个最合适的来执行操作。在前面的例子中，Nova 有多个计算节点。当需要创建虚机时，nova-scheduler 会根据计算节点当时的资源使用情况选择一个最合适的计算节点来运行虚机。除了 Nova，块服务组件 Cinder 也有 scheduler 子服务，后面我们会详细讨论。

2.3.4.3 Worker工作服务

• 调度服务只管分配任务，真正执行任务的是 Worker 工作服务。在 Nova 中，这个 Worker 就是 nova-compute 了。 将 Scheduler 和 Worker 从职能上进行划分使得OpenStack 非常容易扩展：1）当计算资源不够了无法创建虚机时，可以增加计算节点（增加 Worker）；2）当客户的请求量太大调度不过来时，可以增加 Scheduler。

2.3.4.4 Driver 框架

• OpenStack 作为开放的 Infrastracture as a Service 云操作系统，支持业界各种优秀的技术。
• 那 OpenStack 的这种开放性体现在哪里呢：一个重要的方面就是采用基于 Driver 的框架。以 Nova 为例，OpenStack 的计算节点支持多种 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。Nova-compute 为这些 Hypervisor 定义了统一的接口，hypervisor 只需要实现这些接口，就可以 driver 的形式即插即用到 OpenStack 中。
• 下面是 nova driver 的架构示意图：
  
  在 nova-compute 的配置文件 /etc/nova/nova.conf 中由 compute_driver 配置项指定该计算节点使用哪种 Hypervisor 的 driver。
  
  在我们的环境中因为是 KVM，所以配置的是 Libvirt 的 driver。不知大家是否还记得我们在学习 Glance 时谈到： OpenStack 支持多种 backend 来存放 image。可以是本地文件系统，Cinder，Ceph，Swift 等。其实这也是一个 driver 架构。 只要符合 Glance 定义的规范，新的存储方式可以很方便的加入到 backend 支持列表中。再后面 Cinder 和 Neutron 中我们还会看到 driver 框架的应用。

2.3.4.5 Messaging 服务

• 在前面创建虚机的流程示意图中，我们看到 nova-* 子服务之间的调用严重依赖 Messaging。Messaging 是 nova-* 子服务交互的中枢。
  
• 以前没接触过分布式系统的同学可能会不太理解为什么不让 API 直接调用Scheduler，或是让Scheuler 直接调用 Compute，而是非要通过 Messaging 进行中转。
• 程序之间的调用通常分两种：同步调用和异步调用：
  1）同步调用： API 直接调用 Scheduler 的接口就是同步调用。 其特点是 API 发出请求后需要一直等待，直到 Scheduler 完成对 Compute 的调度，将结果返回给 API 后 API 才能够继续做后面的工作。
  2）异步调用： API 通过 Messaging 间接调用 Scheduler 就是异步调用。 其特点是 API 发出请求后不需要等待，直接返回，继续做后面的工作。Scheduler 从 Messaging 接收到请求后执行调度操作，完成后将结果也通过 Messaging 发送给 API。
• 在 OpenStack 这类分布式系统中，通常采用异步调用的方式，其好处是：解耦各子服务：子服务不需要知道其他服务在哪里运行，只需要发送消息给 Messaging 就能完成调用；提高性能：异步调用使得调用者无需等待结果返回。这样可以继续执行更多的工作，提高系统总的吞吐量；提高伸缩性：子服务可以根据需要进行扩展，启动更多的实例处理更多的请求，在提高可用性的同时也提高了整个系统的伸缩性。而且这种变化不会影响到其他子服务，也就是说变化对别人是透明的。

2.3.4.6 Database

• OpenStack 各组件都需要维护自己的状态信息。比如 Nova 中有虚机的规格、状态，这些信息都是在数据库中维护的。每个 OpenStack 组件在 MySQL 中有自己的数据库。
  

2.3.5 Nova 组件详解

2.3.5.1 nova-api

• Nova-api 是整个 Nova 组件的门户，所有对 Nova 的请求都首先由 nova-api 处理。
  Nova-api 向外界暴露若干 HTTP REST API 接口。在 keystone 中我们采用openstack endpoint show nova命令查询 nova-api 的 endponits。客户端就可以将请求发送到 endponits 指定的地址，向 nova-api 请求操作。
  
  当然，作为最终用户的我们不会直接发送 Rest AP I请求。OpenStack CLI，Dashboard 和其他需要跟 Nova 交换的组件会使用这些 API。

• Nova-api 对接收到的 HTTP API 请求会做如下处理：
  1）检查客户端传入的参数是否合法有效 ；
  2）调用 Nova 其他子服务的处理客户端 HTTP 请求 ；
  3）格式化 Nova 其他子服务返回的结果并返回给客户端。

• nova-api 接收哪些请求？
  简单的说，只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应。大部分操作都可以在 Dashboard 上找到。打开Instance管理界面：
  
  点击下拉箭头，列表中就是 nova-api 可执行的操作。
  
  OpenStack 用术语 “Instance” 来表示虚拟机。

2.3.5.2 nova-conductor

• nova-compute 需要获取和更新数据库中 instance 的信息。但 nova-compute 并不会直接访问数据库，而是通过 nova-conductor 实现数据的访问。
  
• 这样做有两个显著好处：更高的系统安全性；更好的系统伸缩性 。
• 更高的安全性：
  在 OpenStack 的早期版本中，nova-compute 可以直接访问数据库，但这样存在非常大的安全隐患。因为 nova-compute 这个服务是部署在计算节点上的，为了能够访问控制节点上的数据库，就必须在计算节点的 /etc/nova/nova.conf 中配置访问数据库的连接信息，比如：
  
  试想任意一个计算节点被黑客入侵，都会导致部署在控制节点上的数据库面临极大风险。为了解决这个问题，从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性。
• 更好的伸缩性：
  nova-conductor 将 nova-compute 与数据库解耦之后还带来另一个好处：提高了 nova 的伸缩性。nova-compute 与 conductor 是通过消息中间件交互的。这种松散的架构允许配置多个 nova-conductor 实例。在一个大规模的 OpenStack 部署环境里，管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问。

2.3.5.3 nova-scheduler

• 重点介绍 nova-scheduler 的调度机制和实现方法：即解决如何选择在哪个计算节点上启动 instance 的问题。

• 创建 Instance 时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor（配额） 中，用户只需要指定用哪个 flavor 就可以了。
  

• 可用的 flavor 在 System->Flavors 中管理：
  
  Flavor 主要定义了 VCPU，RAM，DISK 和 Metadata 这四类。 nova-scheduler 会按照 flavor 去选择合适的计算节点。VCPU，RAM，DISK 比较好理解，而 Metatdata 比较有意思，我们后面会具体讨论。下面介绍 nova-scheduler 是如何实现调度的
  在 /etc/nova/nova.conf 中，nova 通过 scheduler_driver，scheduler_available_filters 和 scheduler_default_filters这三个参数来配置 nova-scheduler。

• Filter scheduler： Filter scheduler 是 nova-scheduler 默认的调度器，调度过程分为两步。1）通过过滤器（filter）选择满足条件的计算节点（运行 nova-compute）；2）通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建 Instance。
  
  Nova 允许使用第三方 scheduler，配置 scheduler_driver 即可。这又一次体现了OpenStack的开放性。Scheduler 可以使用多个 filter 依次进行过滤，过滤之后的节点再通过计算权重选出最适合的节点。
  
  上图是调度过程的一个示例：最开始有 6 个计算节点 Host1-Host6；通过多个 filter 层层过滤，Host2 和 Host4 没有通过，被刷掉了；Host1，Host3，Host5，Host6 计算权重，结果 Host5 得分最高，最终入选。

• Filter： 当 Filter scheduler 需要执行调度操作时，会让 filter 对计算节点进行判断，filter 返回 True 或 False。Nova.conf 中的 scheduler_available_filters 选项用于配置 scheduler 可用的 filter，默认是所有 nova 自带的 filter 都可以用于过滤操作。
  
  另外还有一个选项 scheduler_default_filters，用于指定 scheduler 真正使用的 filter，默认值如下 ：
  
  Filter scheduler 将按照列表中的顺序依次过滤。 下面依次介绍每个 filter。
  1）RetryFilter：
  RetryFilter 的作用是刷掉之前已经调度过的节点。举个例子方便大家理解： 假设 A,B,C 三个节点都通过了过滤，最终 A 因为权重值最大被选中执行操作。但由于某个原因，操作在 A 上失败了。 默认情况下，nova-scheduler 会重新执行过滤操作（重复次数由 scheduler_max_attempts 选项指定，默认是 3）。那么这时候 RetryFilter 就会将 A 直接刷掉，避免操作再次失败。RetryFilter 通常作为第一个 filter。
  2）AvailabilityZoneFilter：
  为提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中。例如把一个机架上的机器划分在一个 Availability Zone 中。OpenStack 默认有一个命名为 “Nova” 的 Availability Zone，所有的计算节点初始都是放在 “Nova” 中。用户可以根据需要创建自己的 Availability Zone。
  
  创建 Instance 时，需要指定将 Instance 部署到在哪个 Availability Zone中。
  
  nova-scheduler 在做 filtering 时，会使用 AvailabilityZoneFilter 将不属于指定 Availability Zone 的计算节点过滤掉。
  3）RamFilter：
  RamFilter 将不能满足 flavor 内存需求的计算节点过滤掉。对于内存有一点需要注意： 为了提高系统的资源使用率，OpenStack 在计算节点可用内存时允许 overcommit（超配），也就是可以超过实际内存大小。 超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5。
  
  其含义是：如果计算节点的内存有 10GB，OpenStack 则会认为它有 15GB（10*1.5）的内存。
  4）DiskFilter：
  DiskFilter 将不能满足 flavor 磁盘需求的计算节点过滤掉。Disk 同样允许 overcommit，通过 nova.conf 中 disk_allocation_ratio 控制，默认值为 1。
  
  5）CoreFilter：
  CoreFilter 将不能满足 flavor vCPU 需求的计算节点过滤掉。vCPU 同样允许 overcommit，通过 nova.conf 中 cpu_allocation_ratio 控制，默认值为 16。
  
  这意味着一个 8 vCPU 的计算节点，nova-scheduler 在调度时认为它有 128 个 vCPU。需要提醒的是： nova-scheduler 默认使用的 filter 并没有包含 CoreFilter。 如果要用，可以将 CoreFilter 添加到 nova.conf 的 scheduler_default_filters 配置选项中。
  6）ComputeFilter：
  ComputeFilter 保证只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。ComputeFilter 显然是必选的 filter。
  7）ComputeCapabilitiesFilter：ComputeCapabilitiesFilter 根据计算节点的特性来筛选。这个比较高级，我们举例说明。例如我们的节点有 x86_64 和 ARM 架构的，如果想将 Instance 指定部署到 x86_64 架构的节点上，就