前言：

openstack是一个开源的云计算管理平台架构，是一系列开源的软件项目的组合。由NASA（美国国家航空航天局）和Rackspace合作研发并发起，以Apache许可证（Apache软件基金会发布的一个自由软件许可证）授权的开源代码项目。

它为私有云和公有云的建设与管理提供了开源软件项目。在传统的运维管理服务器资源的基础上，有了openstack架构之后，才可在其之上部署云平台的服务，进行运维和管理。

一、云计算概述

1.1 云计算概念

云计算管理的是网络资源、存储资源、服务器资源等物理硬件资源。可以使客户在任何时间任何地点，通过网络，获取所需要的资源或服务，并且按需分配，按用量进行收费。

1.2 云计算服务类型

1.2.1 IAAS（基础架构即服务）

提供底层IT基础设施服务，包括处理能力，存储空间、网络资源，一般面对对象是IT管理人员。

用户可获取的是硬件或虚拟硬件，包括裸机或虚拟机，可以自行安装操作系统或其他应用程序。openstack就是一种IAAS云服务。

1.2.2 PAAS（平台即服务）

把安装好开发环境的系统平台作为一种服务通过互联网提供给用户，一般面对对象是开发人员。

用户可获取的是安装了操作系统以及支撑应用程序运行所需要的资源库等软件的物理机或虚拟机，可以自行安装其他应用程序，但不能修改已经预装好的操作系统和运行环境。

1.2.3 SAAS（软件即服务）

直接通过互联网为用户提供部署好的软件和应用程序的服务，可直接使用，一般面向对象是普通用户。

用户可获取的是以租赁的方式来直接使用一些软件，而不是购买。

二、OpenStack 介绍

2.1 OpenStack的特性

OpenStack优势

• 控制性
  完全开源的平台，提供API接口，方便与第三方技术集成
• 兼容性
  OpenStack兼容其他公有云，方便用户进行数据迁移
• 可扩展性
  模块化设计，可以通过横向扩展，增加节点、添加资源
• 灵活性
  根据自己的需要建立相应基础设施、增加集群规模
  激活
• 行业标准
  众多IT领军企业已经加入到OpenStack项目

2.2 OpenStack的核心组件

整个OpenStack架构由多个子服务组成：以下是几个核心项目

三、OpenStack 架构

学习Openstack的部署和运维之前,应当熟悉其架构和运行机制，OpenStack作为开源、可扩展、富有弹性的云操作系统，其设计基本原则如下:
■按照不同的功能和通用性划分不同项目，拆分子系统
■按照逻辑计划、规范字系统之间的通信
■通过分层设计整个系统架构
■不同的功能子系统间提供统一的API接口

3.1 OpenStack 概念架构

如下图所示：

上图的核心为虚拟机，所有组件围绕虚拟机，为它提供服务。可将上图的架构分为三个部分：

①蓝色方框为全局组件：
keystone：为所有服务模块提供认证与授权
ceilometer：度量、监控所有数据资源
horizon ：UI平台管理，提供一个web管理页面，与底层交互

②红色方框为外部辅助组件：
ironic 提供裸金属环境
trove 提供管理数据库服务（控制关系型和非关系型数据库）
heat，sahara 提供对数据管理和编排

③黄色方框为内部核心组件：
glance：提供镜像服务
neutron：提供网络服务
swift：提供对象存储资源
cinder：提供快存储资源
nova：管理实例的生命周期，并负责调取以上四个资源给虚拟机使用。

具体流程：
云平台用户在经过Keystone服务认证授权后，通过Horizon或者Reset API模式创建虚拟机服务，创建过程中包括利用Nova服务创建虚拟机实例，虚拟机实例采用Glance提供镜像服务，然后使用Neutron为新建的虚拟机分配IP地址,并将其纳入虚拟网络中，之后在通过Cinder创建的卷为虚拟机挂载存储块,整个过程都在Ceilometer模块资源的监控下，Cinder产生的卷(Volume)和Glance提供的镜像(Image) 可以通过Swift的对象存储机制进行保存。

3.2 OpenStack 逻辑架构

如下图：

• 全局架构来看：OpenStack包括相互独立的服务组件。所有服务均可通过一个公共身份服务进行身份验证。除了那些需要管理权限的命令，每个服务之间均可通过公共API进行交互。所以，API即是每个服务内部和外部的交界处，隔离了内外。
• 服务之间交互过程：每个服务又由若干组件组成，包含多个进程。每个服务至少有一个API进程，用于侦听API请求，对这些请求进行预处理，（ 预处理就是将请求暴露出来的API接口，给keystone进行认证，如果认证通过，则放入队列等待被处理。） 然后将它们传送到自己服务后端的其他组件，对请求进行处理，而不是API进程去处理。也就是说除了认证服务，实际工作都是由具体的进程完成的。
• 服务内各个进程之间的通信：使用AMQP消息代理，将不同的消息格式进行转换，能够统一处理。服务的状态存储在数据库中。

消息队列：常用的三种类型，包括rabbitmq、 rocketmq、kafka，是两个独立的服务之间，消息传递的载体，解决消息在传输是请求的高并发问题，会以容器的方式，存储消息列表（包括请求、交互、报文），划分重要等级放入队列中，逐个处理，处理完的会自动删除。

OpenStack组件通信关系：

■基于AMQP协议的通信
用于每个项目内部各个组件之间的通信。
■基于SQL的通信
用于各个项目内部的数据库通信。
■基于HTTP协议进行通信
通过各项目的API建立的通信关系，API都是RESTful Web API。
■通过Native API实现通信
OpenStack各组件和第三方软硬件之间的通信。

四、OpenStack 的节点

物理架构可以从四个节点来看，包括控制节点，网络节点，计算节点，存储节点。

4.1 控制节点

定位：运维人员通过控制节点从而控制整个openstack架构。

如上图所示：控制节点包括支持服务，基础服务，扩展服务和网络接口服务，外部的裸金属服务提供物理资源支撑。

• 支持服务：包括数据库支持和通信支持，为整个节点提供数据存储服务和服务之间消息队列的通信服务。
• 基础服务：为虚拟机提供基础的镜像、网络、计算资源；keystone负责整个架构的认证和授权，运维人员通过horizon可视化的界面进行管理。
• 扩展服务：主要针对虚拟机的数据管理，heat进行数据的编排和管理。计量服务在此获取虚拟机的数据源，进行资源监控和计量，并记录。
• 网络接口：专门管理节点的网络服务，用于联系控制其他节点。

4.2 网络节点

网络节点：只有一个基础服务，Neutron网络服务。负责整个openstack架构的网络通信。
整个网络接口又可分为管理网络、数据网络、外部网络。管理网络负责关联其他节点的网络，让控制节点可管控其他节点的网络。数据网络负责整个架构的数据通信。外部网络负责架构与外部物理网络的连接通信。

4.3 计算节点

计算节点包括基础服务、扩展服务、网络接口。基础服务有Nova Hypervisor 和网络插件代理。扩展服务为ceilometer agent 计量代理服务。网络接口为管理网络和数据网络。

4.4 存储节点

存储节点包括cinder和swift两个基础的存储服务和网络接口。网络接口为管理网络和数据网络。

五、核心服务精讲

5.1 Keystone身份认证服务

5.1.1 Keystone概念

Keystone (OpenStack Identity Service)是OpenStack中的一个独立的提供安全认证的模块，主要负责openstack用户的身份认证、令牌管理、提供访问资源的服务目录、以及基于用户角色的访问控制。

Keystone类似一个服务总线，或者说是整 个Openstack框架的注册表,其他服务通过keystone来注册其服务的Endpoint (服务访问的URL)，任何服务之间相互的调用，需要经过Keystone的身 份验证，来获得目标服务的Endpoint来找到目标服务。

5.1.2 主要功能

• 身份认证：负责令牌的发放和校验
• 用户授权：授权用户有指定的可执行动作的范围
• 用户管理：管理用户的账户
• 服务目录：提供可用服务的API端点位置

5.1.3 Keystone的管理对象

Keystone服务贯穿整个架构，在进行身份认证服务的整个流程中，有几个重要的概念。

• 用户（user）：指的是使用openstack架构的用户。

• 证书（credentials）：用于确认用户身份的凭证，证明自己是自己，包括用户的用户名和密码，或是用户名和API密钥，或者身份管理服务提供的认证令牌。

• 认证（authentication）：确定用户身份的过程。

• 项目（project）：可以理解为一个人，或服务所拥有的资源的集合。

• 角色（role）：用于划分权限，通过给user指定role，使user获得role对应操作权限

• 服务（service）：openstack架构的组件服务，如nova、neutron、cinder、swift、glance等。

• 令牌（token）：由字符串表示，作为访问资源的凭证，是用户的身份/权限证明文件；
  token决定了用户的权限范围，在指定的权限内进行操作；也包括令牌的有效期，在指定的时间范围内用户才有这些权限。

• 端点（endpoint）：一个可以通过网络来访问和定位某个openstack service的地址，即用户创建一个项目过程中需要的各个服务资源的位置

5.1.4 Keystone工作流程

以用户想要通过openstack平台创建一个虚拟机的过程为例：

• 用户通过命令行或者horizon控制面板的方式登录openstack，凭借自己的证书（credentials）给keystone验证。
• Keystone对用户的证书验证，验证通过则会发布一个令牌（token）和用户所需服务的位置点（endpoint）给用户。
• 用户得到了位置点（endpoint）之后，携带自己的令牌，向nova发起请求，请求创建虚拟机。
• nova会拿着用户的token向keystone进行认证，看是否允许用户执行这样的操作。
• keystone认证通过之后，返回给nova，nova即开始执行创建虚拟机的请求。首先需要镜像资源，nova带着令牌（token）和所需要的镜像名向glance提出镜像资源的请求。
• glance会拿着token去向keystone进行认证，看是否允许提供镜像服务。keystone认证成功后，返回给glance。glance向nova提供镜像服务。
• 创建虚拟机还需要网络服务，nova携带token向neutron发送网络服务的请求
• neutron拿着nova给的token向keystone进行认证，看是否允许向其提供网络服务。keystone认证成功后，返回给nuetron。nuetron则给nova提供网络规划服务。
• nova获取了镜像和网络之后，开始创建虚拟机，通过hypervisior可调用底层硬件资源进行创建。创建完成返回给用户，成功执行了用户的请求。

5.2 Glance 镜像服务

在早期的openstack版本中，glance只有管理镜像的功能，并不具备镜像存储功能，现在，glance已发至成为集镜像上传、检索、管理和存储等多功能的openstack核心服务。

5.2.1 镜像

镜像通常指的是一系列文件或一个磁盘驱动的精确副本，将特定的一系列文件按照一定的格式制作成独立的文件，以方便用户的下载和使用。简单来说就是一系列资源/服务的集合，也可以作为模板创建多个同样的独立的副本。

5.2.2 镜像服务的功能

镜像服务主要是用来灌流镜像，让用户能够发现、获取和保存镜像，主要功能如下：

• 查询和获取镜像的元数据和镜像本身（元数据：镜像的概要信息和描述信息）
• 注册和上传虚拟机镜像，包括镜像的创建、.上传、 下载和管理
• 维护镜像信息，包括元数据和镜像本身。
• 支持多种方式存储镜像，包括普通的文件系统、Swift、 Amazon S3等
• 对虚拟机实例执行创建快照命令来创建新的镜像，或者备份虚拟机的状态。

5.2.3 镜像的 API 版本

Glance提供的RESTful API有两个版本：V1,V2：

• v1只提供基本的镜像和成员操作功能，包括镜像创建、删除、下载、列表、详细信息查询、 更新，以及镜像租户成员的创建、删除和列表。
• v2除了支持v1的所有功能外，主要增加了镜像位置的添加、删除、修改，元数据和名称空间操作，以及镜像标记操作。

5.2.4 镜像格式

5.2.4.1 镜像文件有多种磁盘格式：

• raw：无结构的磁盘格式，以二进制形式存储镜像，访问速度非常快，但是不支持动态扩容，前期的耗时多。
• qcow2：由QEMU仿真支持，可动态扩展，支持写时复制（copy on write）的磁盘格式。

以下不常用：
vhd:该格式通用于VMware、Xen、 VirtualBox以及其他虚拟机管理程序
vhdx:vhd格式的增强版本，支持更大的磁盘尺寸
vmdk:- 种比较通用的虚拟机磁盘格式
vdi:由VirtualBox虚拟机监控程序和QEMU仿真器支持的磁盘格式
iso:用于光盘(CD-ROM)数据内容的档案格式
ploop:由Virtuozzo支持， 用于运行OS容器的磁盘格式
aki:在Glance中存储的Amazon内核格式
ari:在Glance中存储的Amazon虚拟内存盘(Ramdisk)格式
ami:在Glance中存储的Amazon机器格式

5.2.4.2 镜像文件容器格式：

• bare：没有容器或元数据 “信封” 的镜像，原始的资源集合，所以不存在兼容性问题，不确定选择哪种容器模式时，就在指定为bare最安全。
• Docker：在glance中存储的容器文件系统的dockerd的tar档案。能够隔离磁盘存储的数据、元数据。

以下不常用：
ovf:开放虚拟化格式
ova:在Glance中存储的开放虚拟化设备格式
aki:在Glance中存储的Amazon内核格式
ari:在Glance中存储的Amazon虚拟内存盘(Ramdisk) 格式

5.2.5 镜像状态

• 镜像从上传到可识别的几个状态：
  queued：这是一种初始化状态， 镜像文件刚被创建，在Glance数据库只有其元数据，镜像数据还没有上传至数据库中
  saving:是镜像的原始数据在上传到数据库中的一种过渡状态,表示正在上传镜像
  uploading：指已进行导入数据提交调用，可以给服务识别和调用的状态
  importing：指已经完成导入调用，服务已经识别，可调用，但是镜像还未准备好给虚拟机提供服务
• 镜像在上载完成后的状态：
  active:表示当镜像数据成功上传，可使用
  deactivated:只对管理员开放权限，任何非管理员用户都无权访问镜像数据，禁止下载镜像，也禁止镜像导出和镜像克隆之类的操作
  klled:表示镜像上传过程中发生错误，镜像不可读
  deleted:镜像将在不久后被自动删除，该镜像不可再用，但是目前Glance仍然保留该镜像的相关信息和原始数据，删除后可恢复
  pending_ delete:与deleted相似， Glance还没有清除镜像数据，但处于该状态的镜像不可恢复

5.2.6 镜像访问权限

public公共的：可以被所有的项目使用
private私有的：只有被镜像所有者所在的项目使用
shared共享的：一个非共有的镜像，可以共享给其他项目，通过项目成员（member-*）操作来实现的
projected（受保护的）：这种镜像不能被删除

5.2.7 glance架构详解

glance服务的使用者即客户端，是 openstack 命令行工具，Horizon控制面板或者Nova服务。

• glance-api 是 glance服务后台运行的服务进程，是进入glance的入口，对外提供REST API ，负责接收外部客户端的服务请求，如响应镜像查询、获取和存储的调用。
• glance-registry 是服务后台远程的镜像注册服务，负责处理与镜像的元数据相关的外部请求，如镜像大小、类型等信息。glance-api 接收外部请求，若与元数据相关，则将请求转发给glance-registry，glance-registry会解析请求的内容，并与数据库交互，进行存储、处理、检索镜像的元数据，元数据所有信息即存储在后端的数据库中。
• glance的DB模块存储的是镜像的元数据，可以选用MySQL、mariaDB、SQLite等数据库。镜像的元数据是通过glance-registry存放在数据库中。镜像本身（chunk 块数据）是通过glance的存储驱动存储在后端的各种存储系统中。
• 存储后端（store backend）将镜像本身的数据存放在后端存储系统，存储系统有多种存储方式，支持本地文件系统存储、对象存储、RBD块存储、Cinder块存储、分布式文件存储等。具体使用哪种backend，可以在glance的配置文件 /etc/glance/glance-api.conf 中配置 [glance-store] 模块。

5.2.8 glance的工作流程

glance是一个C/S架构，给外部提供服务，用户通过REST API获取glance所有服务。

• 首先是对客户端的安全认证流程：openstack的操作都需要经过keystone进行身份认证，并授权，glance也不例外，授权成功再去请求glance服务，glance服务接收到外部请求后，会去keystone进行认证，此请求是否已授权，认证通过后，才会将请求传到后端处理。

• glance domain controller 是API和后端功能模块的中间件，相当于调度器，作用是将外部服务分发到下面的各个功能层去处理。
  在调度时，遵循调度算法，首先有一个预选，排除不符合要求的节点，再进行优选，通过打分机制，对都能够处理此功能的节点进行打分，考虑它们当前的负荷，处理能力和速度，选出最优的一个。
  对于一些有污点的节点，调度器是直接跳过他们的，如果其余可用节点负担都太大，无法处理外部请求，会有一个容忍机制，由运维人员控制，让调度器接受污点，对污点再进行优选。

• 调度器的子功能模块：
  auth授权：控制镜像的访问权限；
  notifier消息通知：将镜像变化信息和错误添加到 消息队列
  policy规则定义：定义镜像操作的访问权限,在policy.json中定义
  quota限额：限制上传镜像的大小
  location定位：通过glance store 与后台存储进行交互，指明镜像存储位置，还可以检查位置的URL是否正确
  DB数据库：将镜像转换为相应的格式以存储在数据库中，并将从数据库读取的信息转换为可以操作的镜像对象。

• 后端有两种服务类型：一种是处理关于元数据的请求，另一种是关于镜像数据的请求。由调度器将请求分配到对应的服务模块。
  当请求元数据时，glanceDB会与调度器进行交互提供服务，中间还可以通过 registry layer 注册层进行一个安全交互。glanceDB存储着元数据信息，并且对glance内部所有的组件都是共享的。
  当请求的是关于镜像本身服务时，glance store可以提供一个统一的接口访问后端的存储，并且有一个驱动模块可以调用整个库与外部服务进行交互。后端的存储有多种存储系统，对象存储、文件存储等。

5.3 Nova 计算服务

5.3.1 Nova 简介

• 计算服务是openstack最核心的服务之一 ， 负责维护和管理云环境的计算资源，它在openstack项目中代号是nova。
• Nova自身并没有提供任何虚拟化能力，它提供计算服务，使用不同的虚拟化驱动来与底层支持的Hypervisor (虚拟机管理器)进行交互。所有的计算实例(虚拟服务器)由Nova进行生命周期的调度管理(启动、挂起、停止、删除等)，全局来看，nova为整个架构提供虚拟化资源、技术，服务层面来看，nova本身并不具备虚拟化能力，而是通过compute组件与虚拟化管理工具交互实现虚拟资源调度。
• Nova需要keystone、glance、 neutron、 cinder和swift等其他服务的支持， 能与这些服务集成，实现如加密磁盘、裸金属计算实例等。会和其他外部组件集成，共同完成请求。

5.3.2 Nova 系统架构

整个架构可从外部服务和内部服务来看。

外部服务包括keystone，neutron，glance，cinder这些nova服务需要与之交互的服务。
内部组件：
DB：用于数据存储的sql数据库，存放各组件的工作过程信息，后盾裸金属实际的使用资源信息
API：用于接收HTTP请求、转换命令、通过消息队列或HTTP与其他组件通信
Scheduler：用于决定哪台计算节点承载计算实例，相当于nova的调度器
Network：管理IP转发，网桥或虚拟局域网，是一个网络组件
Compute：管理虚拟机管理器（VMM）与虚拟机之间通信，与hypervisor交互实现虚拟化调用底层硬件资源，计算组件
Conductor：处理需要协调的的请求（构建虚拟机或调整虚拟机大小的请求），或者处理对象转换

5.3.3 组件介绍

5.3.3.1 API：

• 它是客户端访问nova的http接口，它由nova-api服务实现，nova-api服务接收和响应来自最终用户的计算api请求（包括跟虚拟机声明周期相关的操作），作为openstack对外服务的最主要接口，nova提供了一个集中的可以查询所有api的端点，以便自己平台内部和其他云平台的调用。

• 所有对nova的请求都首先由nova-api处理，API提供REST标准调用服务，便于与第三方系统集成（其他云平台）。它是外部访问并使用nova提供的各种服务的唯一途径，也是客户端和nova之间的中间件。

• 最终用户不会直接改送RESTful API 请求，而是通过openstack命令行，horison控制面板和其他需要跟nova交换 的组件来使用这些API。

• Nova-api对接收到的HTTP API请求做以下处理：
  1、检查客户端传入的参数是否合法有效（而不止是进行认证）
  2、调用nova其他服务来处理客户端HTTP请求
  3、格式化nova其他子服务返回的结果，并返回给客户端

5.3.3.2 Scheduler：

简介

• 调度器，由nova-scheduler服务实现，主要解决的是选择在哪个计算节点上启动实例。它可以应用多种规则，考虑内存使用率、cpu负载率、CPU架构等多种因素，根据一定的算法，确定虚拟机实例能够运行在哪一台计算机服务器上。
• nova-scheduler服务会从消息队列中接收一个虚拟机实例的请求，通过读取数据库的内容，从可用资源池中选择最合适的计算节点，创建新的虚拟机实例。
• 创建虚拟机实例时，用户会提出实例的资源需求，如CPU、内存、磁盘。openstack将这些需求定义在实例类型中，有多个实例模板存储在nova的数据库中，用户可以指定使用哪个实例类型，再创建实例。

调度器的类型：

• 随机调度器：从所有正常运行nova-compute服务的节点中随机选择
• 缓存调度器：是随机调度器的一种特殊类型，在随机调度器的基础上，将主机资源信息缓存在本地内存中，然后通过后台的定时任务，定时从数据库中获取最新的主机资源信息，周期性同步而不是实时获取主机资源信息。
• 过滤器调度器：根据指定的过滤条件以及权重选择最佳的计算节点，又称为筛选器。

过滤器调度器调度过程：
主要分为两个阶段：

• 通过指定的过滤器选择满足条件的计算节点，比如内存使用率，可以使用多个过滤器依次进行过滤。（预选）
• 对过滤之后的主机列表进行权重计算并排序，选择最优的计算节点来创建虚拟机实例。（优选）
  

调度器与DB的交互过程：

• scheduler组件决定的是虚拟机实例部署在哪台计算节点上并调度，在调度之前，会先向数据库获取宿主机资源信息作为依据；
• 之后可通过过滤器和权重选择最合适的节点调度，或者指定节点直接调度；
• 计算节点的 libvirt 工具负责收集宿主机的虚拟化资源，根据已创建的实例再次统计资源，将资源信息更新到数据库中，整个更新资源信息的过程是周期性执行的，而不是实时的；
• 所以存在一个问题，当刚创建完一个实例，随即又需要创建时，数据库还未来得及更新宿主机的最新状态，那么调度器依据的信息就不正确，有可能所选的节点资源并不够用，而导致调度失败。
• 这同时也是缓存调度器的缺陷，无法实时获取租主机资源信息。我们可在调度完成时，直接将资源信息返回给数据库，更新数据库状态，解决这个问题。

过滤器

• 当过滤调度器需要执行调度操作时，会让过滤器对计算节点进行判断，返回ture或false，按照主机列表中的顺序依次过滤。
• scheduler_available_filters 选项用于配置可用过滤器，默认是所有nova自带的过滤器都可以使用。
• scheduler_default_filters 选项用于指定nova-schedule 服务真正使用的过滤器。

过滤器类型：

• RetryFilter（再审过滤器）
  主要作用是过滤掉之前已经调度过的节点（类比污点）。如A、B、C都通过了过滤，A权重最大被选中执行操作，由于某种原因，操作在A上失败了。Nova-filter 将重新执行过滤操作，再审过滤器直接过滤掉A，以免再次失败。
• AvailabilityZoneFilter（可用区域过滤器）
  主要作用是提供容灾性，并提供隔离服务，可以将计算节点划分到不同的可用区域中。Openstack默认有一个命名为nova的可用区域，所有计算节点一开始都在其中。用户可以根据需要创建自己的一个可用区域。创建实例时，需要指定将实例部署在那个可用区域中。通过可用区过滤器，将不属于指定可用区的计算节点过滤掉。
• RamFilter（内存过滤器）
  根据可用内存来调度虚拟机创建，将不能满足实例类型内存需求的计算节点过滤掉，但为了提高系统资源利用率, Openstack在计算节点的可用内存允许超过实际内存大小，可临时突破上限，超过的程度是通过nova.conf配置文件中ram_ allocation_ ratio参数来控制的， 默认值是1.5。（但这只是临时的）
  Vi /etc/nova/nova . conf
  Ram_ allocation_ ratio=1 .5
• DiskFilter（硬盘过滤器）
  根据磁盘空间来调度虚拟机创建，将不能满足类型磁盘需求的计算节点过滤掉。磁盘同样允许超量，超量值可修改nova.conf中disk_ allocation_ ratio参数控制，默认值是1.0，（也是临时的）
  Vi /etc/nova/nova.conf
  disk_ allocation_ ratio=1.0
• CoreFilter（核心过滤器）
  根据可用CPU核心来调度虚拟机创建，将不能满足实例类型vCPU需求的计算节点过滤掉。vCPU也允许超量，超量值是通过修改nova.conf中cpu_ allocation_ratio参数控制，默认值是16。
  Vi /etc/nova/nova. conf
  cpu_allocation_ ratio=16.0
• ComputeFilter（计算过滤器）
  保证只有nova-compute服务正常工作的计算节点才能被nova-scheduler调度，它是必选的过滤器。
• ComputeCapabilitiesFilter（计算能力过滤器）
  根据计算节点的特性来过了，如不同的架构。
• ImagePropertiesFilter（镜像属性过滤器）
  根据所选镜像的属性来筛选匹配的计算节点，通过元数据来指定其属性。如希望镜像只运行在KVM的Hypervisor上，可以通过Hypervisor Type属性来指定。
• 服务器组反亲和性过滤器
  要求尽量将实例分散部署到不同的节点上，设置一个服务器组，组内的实例会通过此过滤器部署到不同的计算节点。适用于需要分开部署的实例。
• 服务器组亲和性过滤器
  此服务器组内的实例，会通过此过滤器，被部署在同一计算节点上，适用于需要位于相同节点的实例服务。

权重：

• 在对计算节点进行过滤时，多个过滤器依次进行过滤，而不是并行，相当于一个个预选，避免重复对同一个节点进行所有过滤项检验。过滤之后的节点再通过计算权重进行排序。
• 所有权重位于nova/scheduler/weights 目录下，目前默认是RAMweighter，根据计算节点空闲的内存计算权重，内存空闲越多权重越大，计算节点按照内存空闲进行排序。

schedule组件小结：
定位：决定实例具体创建在哪个计算节点

调度流程：
有多个调度器、过滤器共同合作，一次过滤，首先筛选出符合要求的节点，接着以权重（一般是基于内存空闲）的方式，对节点打分排序，最终决定出一个节点。

子功能：
粗过滤（基础资源），例如CPU、内存、磁盘
精细化过滤，例如镜像属性，服务性能契合度
高级过滤，亲和性/反亲和性过滤

过滤之后，可以进行随机调度，会进行再筛选，即污点机制，对剩下的节点过滤，排除掉之前有故障的节点。

5.3.3.3 compute计算组件

Nova-compute在计算节点上运行，负责管理节点上的实例。通常一个主机运行一 个Nova-compute服务, 一个实例部署在哪个可用的主机上取决于调度算法。OpenStack对实例的操作最后都是提交给Nova-compute来完成。

Nova-compute可分为两类，一类是定向openstack报告计算节点的状态，另一类是实现实例生命周期的管理。

• 定期向OpenStack报告计算节点的状态
  每隔一段时间，nova-compute就会报告当前计算节点的资源使用情况和nova-compute服务状态。nova-compute是通过Hypervisor的驱动获取这些信息的。
• 实现虚拟机实例生命周期的管理
  OpenStack对虚拟机实例最主要的操作都是通过nova-compute实现的。包括创建、关闭、重启、挂起、恢复、中止、调整大小迁移、快照。
  以实例创建为例来说明nova-compute的实现过程。
  (1)为实例准备资源。
  (2)创建实例的镜像文件。
  (3)创建实例的XML定义文件。
  (4)创建虚拟网络并启动虚拟机。

通过Driver (驱动)架构支持多种Hypervisor虚拟机管理器：
面对多种Hypervisor, nova-compute为这些Hypervisor定义统一 的接口，Hypervisor只需要对接这个接口， 就可以Drive驱动的形式即插即用到OpenStack系统中，使得compute组件可以调用虚拟化的资源，创建实例。

5.3.3.4 conductor协调组件

• 为数据库的访问提供一层安全保障。Nova-conductor作为nova-compute服务与数据库之间交互的中介，避免了compute直接访问，由nova-compute服务对接数据库，compute组件位于第三方上，与架构外部进行交互。这样就可避免一些越权操作，并且为数据库分压。
• Nova-compute访问数据库的全部操作都改到nova-conductor中，nova-conductor作为对数据库操作的一个代理，而且nova-conductor是部署在控制节点上的。
• Nova-conductor有助于提高数据库的访问性能，nova-compute可以创建多个线程使用远程过程调用(RPC)访问nova-conductor。
• 在一个大规模的openstack部署环境里，管理员可以通过增加nova-conductor的数量来应对日益增长的计算节点对数据库的访问量。

5.3.3.5 Placement API

• 以前对资源的管理全部由计算节点承担，在统计资源使用情况时，只是简单的将所有计算节点的资源情况累加起来，但是系统中还存在外部资源，这些资源由外部系统提供。如ceph、nfs等提供的存储资源等。
  面对多种多样的资源提供者，管理员需要统一的、简单的管理接口来统计系统中资源使用情况，这个接口就是Placement API。
• PlacementAPI由nova-placement-api服务来实现， 旨在追踪记录资源提供者的目录和资源使用情况。被消费的资源类型是按类进行跟踪的。 如计算节点类、共享存储池类、IP地址类等。

5.3.4 虚拟机实例化流程

• 用户访问控制台
  可以通过多种方式访问虚拟机的控制台：
  ■ Nova-novncproxy守护进程: 通过vnc连接访问正在运行的实例提供一个代理，支持浏览器novnc客户端。（最常用的）
  ■ Nova-spicehtml5proxy守护进程: 通过spice连接访问正在运行的实例提供一个代理，支持基于html5浏览器的客户端。
  ■ Nova-xvpvncproxy守护进程: 通过vnc连接访问正在运行的实例提供一个代理，支持openstack专用的java客户端。
  ■ Nova-consoleauth守护进程: 负责对访问虚拟机控制台提供用户令牌认证。这个服务必须与控制台代理程序共同使用，即上面三种代理方式。

如果无法通过控制台/URL连接到内部实例：
1、实验场景中，虚拟机资源不足
2、实验场景中，镜像问题（公共镜像，作为测试用的镜像）
3、生产环境中，路由配置问题，路由网关配置到了其他实例地址，内部有多个实例项目。

• 首先用户（openstack最终用户或其他程序）执行nova client提供的用于创建虚拟机的命令。
• nova-api服务监听到来自客户端的http请求，会将请求转换为AMQP消息之后上传到消息队列。
• 通过消息队列调用conductor服务
• conductor服务从消息队列中接收到虚拟机的实例化请求后，进行准备工作
• conductor通过消息队列告诉scheduler服务去选择一个合适的计算节点创建虚拟机，此时scheduler会读取数据库的内容
• conductor服务从nova-schedule服务得到了计算节点的信息后，通过消息队列通知compute服务实现虚拟机的创建。

5.3.5 Nova部署架构

经典部署架构：

负载均衡部署架构：

5.3.6 Nova的Cell架构

5.3.6.1 使用此架构原因

为了解决openstack nova集群的规模变大时,数据库和消息队列服务就会出现瓶颈问题。Nova为提高水平扩展及分布式、大规模的部署能力，同时又不想增加数据库和消息中间件的复杂度，从而引入了Cell概念。

5.3.6.2 cell概念

Cell可译为单元。为支持更大规模的部署,openstack将大的nova集群分成小的单元，每个单元都有自己的消息队列和数据库，可以解决规模增大时引起的瓶颈问题。在Cell中，Keystone、Neutron、 Cinder、Glance等资源是共享的。

5.3.6.3 cell架构的数据库

• nova-api数据库：存放全局信息，这些全局数据表是从nova库迁移过来的，包括实例模型信息，实例组，配额信息。
• nova-cell0数据ku：当实例调度失败时，实例的信息不属于任何一个cell，所以存放到cell0数据库中。

单cell部署：

多cell部署：

多cell部署的架构，可以从分层的角度来看：
为了应付集群规模的扩大，对数据库、消息队列进行扩容，实现nova规模的扩展。通过划分多个小的cell单元，多个单元同时处理业务，每个cell单元都有各自的数据库和消息队列。为了管理这些小的单元，需要一个集中化管理组件 super conductor，主conductor来管理cell单元，同时完成自身的工作。

蓝色方框：是对消息队列的划分。划分为API消息队列，和cell单元中的消息队列。API消息队列中是外部对nova的请求，以及nova内部子服务之间的通信请求，作为它们之间通信的载体。cell消息队列中是cell单元需要处理的业务请求。
红色方框：是对conductor的划分，super-conductor用于集中管理cell单元，同时负责通知 nova-scheduler 调度计算节点，调度失败直接写入cell0，成功则控制任务具体下发给哪个cell单元处理，将所有数据写入数据库。cell中的conductor，通过消息队列收到本cell需要创建实例的请求后，会通知nova-compute创建实例，进行具体的处理和协调。
粉色方框：是对数据库的划分。API数据库存放全局的交互数据，总的资源统计。cell0数据库存放实例创建失败的信息，cell1/2存放各自单元成功创建实例的信息，对应处理的请求数据。
nova-api：每个创建实例的请求都有编号，创建成功与否的结果会存储在cell数据库中，nova-api会根据编号，从cell数据库中调取到请求的最终结果，格式化后返回给用户。

5.4 Neutron 网络服务

简介：
网络是openstack最重要的资源之一， 没有网络，虚拟机将被隔离。Openstack的网络服务最主要的功能就是为虚拟机实例提供网络连接，最初由nova的一-个单独模块nova-compute实现，但是nova-compute支持的网络服务有限，无法适应大规模、高密度和多项目的云计算，现已被专门的网络服务项目Neutron所取代。
Neutron为整个openstack环境提供软件定义网络支持，主要功能包括二层交换、三层路由、防火墙、VPN, 以及负载均衡等。Neutron在由其他openstack服务 (如nova)管理的网络接口设备 (如虚拟网卡)之间提供网络连接即服务。

5.4.1 linux网络虚拟化

linux网络虚拟化：
传统的物理网络：

需要对二层物理网络进行抽象和管理：

• 实现虚拟化后，多个物理服务器可以被虚拟机取代，部署在同一台物理服务器，上。虚拟机由虚拟机管理器(Hypervisor)实现，在Linux系统中Hypervisor通常采用kvm。在对服务器进行虚拟化的同时，也对网络进行虚拟化。
• Hypervisor为虚拟机创建一个或多个虚拟网卡(vNIC)，虚拟网卡等同于虚拟机的物理网卡。物理交换机在虚拟网络中被虚拟为虚拟交换机(vSwitch)，虚拟机的虚拟网卡连接到虚拟交换机上，虚拟机交换机再通过物理主机的物理网卡连接到外部网络。
• 对于物理网络来说，虚拟化的主要工作是对网卡和交换设备的虚拟化。

linux虚拟网桥：

• 与物理机不同，虚拟机并没有硬件设备，但是也要与物理机和其他虚拟机进行通信。LinuxKVM的解决方案是提供虚拟网桥设备，像物理交换机具有若干网络接口(网卡) 一样，在网桥上创建多个虚拟的网络接口，每个网络接口再与KVM虚拟机的网卡相连。
• 在Linux的KVM虚拟系统中，为支持虚拟机的网络通信，网桥接口的名称通常以vnet开头，加上从0开始顺序编号，如vnet0、vnet1, 在创建虚拟机时会自动创建这些接口。虚拟网桥br1和br2分别连接到物理主机的物理网卡1和物理网卡2。

虚拟局域网：

• 一个网桥可以桥接若干虚拟机，当多个虚拟机连接在同一网桥时，每个虚拟机发出的广播包会引发广播风暴，影响虚拟机的网络性能。通常使用虚拟局域网(VLAN)将部分虚拟机的广播包限制在特定范围内，不影响其他虚拟机的网络通信。
• 通常使用VLAN将部分虚拟机的广播包限制在特定范围内，不影响其他虚拟机的网络通信。
• 将多个虚拟机划分到不同的VLAN中，同一VL AN的虚拟机相当于连接同一网桥上。
• 在Linux虚拟化环境中，通常会将网桥与VLAN对应起来，也就是将网桥划分到不同的VLAN中
• VLAN协议为802.1Q，VLAN是具有802.1Q标签的网络。

开放虚拟交换机

• 开放虚拟交换机 (Open vSwitch) 是与硬件交换机具备相同特性，可在不同虚拟平台之间移植（保持自己的功能特性，同时具有兼容性），具有产品级质量的虚拟交换机，适合在生产环境中部署。
• 交换设备的虚拟化对虚拟网络来说至关重要。在传统的数据中心，管理员可以对物理交换机进行配置，控制服务器的网络接入，实现网络隔离、流量监控、QoS配置、流量优化等目标。在云环境中，采用Open vSwitch技术的虚拟交换机可使虚拟网络的管理、网络状态和流量的监控得以轻松实现。
• Open Switch在云环境中的虚拟化平台上实现分布式虚拟交换机，可以将不同主机上的OpenvSwitch交换机连接起来，形成一个大规模的虚拟网络。

OpenStack网络服务提供一个API让用户在云中建立和定义网络连接。该网络服务的项目名称是Neutron。OpenStack网络负责创建和管理 虚拟网络基础架构，包括网络、交换机、子网和路由器，这些设备由OpenStack计算服务Nova管理。同时，网络服务还提供防火墙和VPN这样的高级服务。可以将网络服务部署到特定主机.上。OpenStack网络组件与身份服务、计算服务和仪表板等多个OpenStack组件进行整合

5.4.2 Neutron网络结构

• 一个简化的典型的Neutron网络结构如图所示，包括一个外部网络、一个内部网络和一个路由器。
• 外部网络负责连接OpenStack项目之外的网络环境，又称公共网络。与其他网络不同，它不仅仅是-一个虚拟网络，更重要的是，它表示OpenStack网络能被外部物理网络接入并访问。外部网络可能是企业的局域网(Intranet) ，也可能是互联网(Internet) ，这类网络并不是由Neutron直接管理。
• 内部网络完全由软件定义，又称私有网络。它是虚拟机实例所在的网络，能够直接连接到虚拟机。项目用户可以创建自己的内部网络。默认情况下，项目之间的内部网络是相互隔离的，不能共享。该网络由Neutron直接配置与管理。
• 路由器用于将内部网络与外部网络连接起来，因此，要使虚拟机访问外部网络，必须创建一个路由器。
• Neutron需要实现的主要是内部网络和路由器。内部网络是对二层(L 2)网络的抽象，模拟物理网络的二层局域网，对于项目来说，它是私有的。路由器则是对三层(L3) 网络的抽象，模拟物理路由器，为用户提供路由、NAT等服务。
  

网络子网与端口

• 网络：一个隔离的二二层广 播域，类似交换机中的VLAN。Neutron支持多种类型的网络， 如FLAT、VLAN、VXLAN等。
• 子网：一个IPV4或者IPV6的地址段及其相关配置状态。虚拟机实例的IP地址从子网中分配。每个子网需要定义IP地址的范围和掩码(这个有点像DHCP中定义的作用域的概念)。
• 端口：连接设备的连接点，类似虚拟交换机上的一个网络端口。端口定义了MAC地址和IP地址，当虚拟机的虚拟网卡绑定到端口时，端口会将MAC和IP分配给该虚拟网卡。
• 通常可以创建和配置网络、子网和端口来为项目搭建虚拟网络。网络必须属于某个项目，一个项目中可以创建多个网络。一个子网只能属于某个网络，一个网络可以有多个子网。一个端口必须属于某个子网，一个子网可以有多个端口。

网络拓扑类型

• Local
  Local网络与其他网络和节点隔离。该网络中的虚拟机实例只能与位于同-节点上同- -网络的虚拟机实例通信，实际意义不大，主要用于测试环境。位于同一Local网络的实例之间可以通信，位于不同Local网络的示例之间无法通信。一个Local网络只能位于同一个物理节点上，无法跨节点部署。
• Flat
  Flat是一种简单的扁平网络拓扑，所有的虚拟机实例都连接在同一网络中，能与位于同一网络的实例进行通信，并且可以跨多个节点。这种网络不使用VLAN,没有对数据包打VLAN标签，无法进行网络隔离。Flat是基于不使用VLAN的物理网络实施的虚拟网络。每个物理网络最多只能实现- -个虚拟网络。
• VLAN
  VLAN是支持802.1q协议的虚拟局域网，使用VLAN标签标记数据包，实现网络隔离。同一VLAN网络中的实例可以通信，不同VLAN网络中的实例只能通过路由器来通信。VLAN网络可以跨节点。
• VXLAN
  VXLAN (虚拟扩展局域网)可以看作是VLAN的一种扩展，相比于VLAN,它有更大的扩展性和灵活性，是目前支持大规模多租房网络环境的解决方案。由于VLAN包头部限长是12位， 导致VLAN的数量限制是4096 (2^12) 个，不能满足网络空间日益增长的需求。目前VXLAN的封包头部有24位用作VXLAN标识符(VNID)来区分VXLAN网段，最多可以支持16777216 (2^24) 个网段。
  VXLAN使用STP防止环路，导致- -半的网络路径被阻断。VXLAN的数据包是封装到UDP通过三层传输和转发的，可以完整地利用三层路由，能克服VLAN和物理网络基础设施的限制，更好地利用已有的网络路径。
• GRE
  GRE (通用路由封装)是用一种网络层协议去封装另一种网络层协议的隧道技术。GRE的隧道由两端的源IP地址和目的IP地址定义，它允许用户使用IP封装IP等协议，并支持全部的路由协议。在OpenStack环境中使用GRE意味着"IP over IP”,GRE与VXLAN的主要区别在于，它是使用IP包而非UDP进行封装的。
• GENEVE
  GENEVE(通用网络虚拟封装)的目标宣称是仅定义封装数据格式，尽可能实现数据格式的弹性和扩展性。GENEVE封装的包通过标准的网络设备传送，即通过单播或多播寻址，包从一个隧道端点传送到另一个或多个隧道端点。GENEVE帧格式由- -个封装在IPV4或IPV6的UDP里的简化的隧道头部组成。GENEVE推出的主要目的是为了解决封装时添加的元数据信息问题(到底多少位, 怎么用GENEVE自动识别与调整) ，以适应各种虚拟化场景。
• 总结
  随着云计算、大数据、移动互联网等新技术的普及，网络虚拟化技术的趋势在传统单层网络基础上叠加一层逻辑网络。这将网络分为两个层次，传统单层网络称为Underlay (承载网络)，叠加其上的逻辑网络称为Overlay (叠加网络或覆盖网络)。Overlay网络的节点通过虚拟的或逻辑的连接进行通信，每一个虚拟的或逻辑的连接对应于Underlay网络的一条路径，由多个前后衔接的连接组成。Overlay网络无须对基础网络进行大规模修改，不用关心这些底层实现，是实现云网融合的关键。

VXLAN、GRE、GENEVE都是基于隧道技术的overlay网络。

VLAN和VXLAN：vlan是虚拟局域网，通过不同的vlan标签进行网络隔离；vxlan是vlan的扩展，能充分利用三层路由，解决传统vlan和物理设备的环境限制问题，并且比vlan支持更多的网段，基于udp协议。

简单理解：随着目前互联网技术的发展，对于网络部分，使用虚拟化的方案，实现对传统网络的扩展，利用叠加的方式，常用的叠加网络VXLAN、GRE。

5.4.3 openstack中的网络基本架构

• Neutron仅有一个主要服务进程neutron-server。它是运行在控制节点上的，对外提供Openstack网络API作为访问Neutron的入口，收到请求后调用插件进行处理，最终由计算节点和网络节点上的各种代理完成请求。
• 网络提供者是指提供OpenStack网络服务的虚拟或物理网络设备，如Linux Bridge、Open vSwitch,或者其他支持Neutron的物理交换机。
• 与其他服务一样，Neutron的各组件服务之间需要相互协调和通信，neutron-server. 插件和代理之间通过消息队列进行通信和相互调用。
• 数据库用于存放OpenStack的网络状态信息，包括网络、子网、端口、路由器等。
• 客户端是指使用Neutron服务的应用程序，可以是命令行工具、Horizon和Nova计算服务等。

实例：以一个创建VLAN 100虚拟网络的流程为例说明这些组件如何协同工作。

• neutron-server收到创建网络的请求，通过消息队列通知已注册的Linux Bridge插件。(插件可以有很多，这里举例创建虚拟网络的插件是Linux Bridge插件)
• 该插件将要创建的网络信息(如名称、VLAN ID等)保存到数据库中，并通过消息队列通知运行在各节点上的代理
• 代理收到消息后会在节点上的物理网卡上创建VLAN设备(比如eth1.100)，并创建一个网桥(比如brqxxx)来桥接VLAN设备。

neutron-server详解：
结构：

• RESTful API:直接对客户端提供API服务，属于最前端的API，包括Core API和Extension API两种类型。Core API提供管理网络、子网和端口核心资源的RESTful API; Extension API则提供管理路由器、防火墙、负载均衡、安全组等扩展资源的RESTful API。
• Common Service:通用服务，负责对API请求进行检验、认证，并授权。
• Neutron Core:核心处理程序，调用相应的插件API来处理API请求。
• Plugin API:定义插件的抽象功能集合，提供调用插件的API接口，包括Core Plugin API 和 ExtensionPlugin API两种类型。Neutron Core通过Core Plugin API调用相应的Core Plugin，

最后

以上就是受伤路人为你收集整理的干货满满！OpenStack的探索之路——基础理论精讲前言：一、云计算概述二、OpenStack 介绍三、OpenStack 架构四、OpenStack 的节点五、核心服务精讲的全部内容，希望文章能够帮你解决干货满满！OpenStack的探索之路——基础理论精讲前言：一、云计算概述二、OpenStack 介绍三、OpenStack 架构四、OpenStack 的节点五、核心服务精讲所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。