人的一生，有许多事情，是需要放在心里慢慢回味的，过去的就莫要追悔，一切向前看吧 任何打击都不足以成为你堕落的借口，即使你改变不了这个世界，你却依然可以改变自己，选择条正确的路永远走下去。
返回顶部

谈谈我对OpenStack的理解

摘要

OpenStack 是当今最具影响力的云计算管理工具——通过命令或者基于 Web 的可视化控制面板来管理 IaaS 云端的资源池（服务器、存储和网络）。它最先由美国国家航空航天局（NASA）和 Rackspace 在 2010 年合作研发，现在参与的人员和组织汇集了来自 100 多个国家的超过 9500 名的个人和 850 多个世界上赫赫有名的企业，如 NASA、谷歌、惠普、Intel、IBM、微软等。

OpenStack 支持 KVM、Xen、Lvc、Docker 等虚拟机软件或容器，默认为 KVM。通过安装驱动，也支持 Hyper-V 和 VMware ESXi，不过有些功能暂时不支持。

OpenStack 采用 Python 语言开发，遵循 Apache 开源协议，因此相比 CloudStack 来说，更轻量化，效率更高。

一、云计算服务模型

1.1、基础设施及服务（Infrastructure as a Service，Iaas）

云服务提供商把IT系统的基础设施层作为服务租出去，由消费者自己安装操作系统、中间件、数据库和应用程序

面向对象一般是IT管理人员

1.2、平台即服务（Platform as a Service，Paas）

云服务提供商把IT系统中的平台软件层作为服务租出去，消费者自己开发或者安装程序，并运行程序

面向对象一般是开发人员

1.3、软件即服务（Software as a Service，SaaS）

云服务提供商把IT系统中的应用软件层作为服务租出去，消费者不用自己安装应用软件，直接使用即可，这进一步降低了云服务消费者的技术门槛

面向对象一般是普通用户

二、OpenStack服务

2.1、OpenStack核心组件、可选组件以及其他组件介绍

分类

服务

项目名称

功能

核心组件

Compute
（计算服务）

Nova

管理虚拟机的整个生命周期:创建、运行、挂起、调度、关闭、销毁等。这是真正的执行部件。接受 DashBoard 发來的命令并完成具体的动作。但是 Nova 不是虛拟机软件，所以还需要虚拟机软件（如 KVM、Xen、Hyper-v 等）配合

Network
（网络服务）

Neutron

管理网络资源，提供/一组应用编程接口(API)，用户可以调用它们来定义网络(如 VLAN )，并把定义好的网络附加给租户。Networking 是一个插件式结构，支持当前主流的网络设备和最新网铬技术

Object Storage

（对象存储服务）

Swift

是 NoSQL 数据库，类似 HBase，为虚拟机提供非结构化数据存储，它把相同的数据存储在多台计箅机上，以确保数据不会丢失。用户可通过 RESTful 和 HTTP 类型的 API 来和它通信。这是实际的存储项目，类似 Ceph，不过在 OpcnStack 具体实施时，人们更愿意采用 Ceph。

Block Storage

（块存储服务）

Cinder

管理块设备，为虚拟机管理 SAN 设备源。但是它本身不是块设备源， 需要一个存储后端来提供实际的块设备源（如 iSCSI、FC等）。

Cinder 相当于一个管家，当虚拟机需要块设备时，询问管家去哪里获取具体的块设备。它也是插件式的，安装在具体的 SAN 设备里。

Identity
（身份认证服务）

Keystone

为其他服务提供身份验证、权限管理、令牌管理及服务名册管理。要使用云计算的所有用户事先需要在 Keystone 中建立账号和密码，并定义权限（注意:这里的“用户”不是指虚拟机里的系统账户，如 Windows 7 中的 Administrator )。另外，OpenStack 服务（如 Nova、Neutron、Swift、Cinder 等）也要在里面注册，并且登记具体的 API，Keystone 本身也要注册和登记 API

Image Service
（镜像服务）

Glance

存取虚拟机磁盘镜像文件，Compute 服务在启动虚拟机时需要从这里获取镜像文件。这个组件不同于上面的 Swift 和 Cinder，这两者提供的 存储是在虚拟机里使用的

Dashboard
（控制面板服务）

Horizon

提供了一个网页界面，用户登录后可以做这些操作：管理虚拟机、配置权限、分配 IP 地址、创建租户和用户等。本质上就是通过图形化的 操作界面控制其他服务（如 Compute、Networking 等)。当然，如果你熟悉命令，也可以直接采用命令来完成相应的任务

Telemetry
（计量服务）

Ceilometer

结合 Aodh、CloudKitty 两个组件，完成计费任务，如结算、消耗的 资源统计、性能监控等。OpenStack 之所以能管理公共云，一是因为 Ceilometer 的存在，二是因为引人了租户的概念

可选组件

 

Heat

如果要在成千上万个虚拟机里安装和配置同一个软件，该怎么办？采用 Orchestrates 是一个不错的主意，它向每个虚拟机里注人一个名叫 heat-cfntools 的客户端工具，然后就能同时操作很多虚拟机

 

Sahana

使用户能够在 OpenStack 平台上（利用虚拟机）一键式创建和管理 Hadoop 集群，实现类似 AWS 的 EMR（Amazon Elastic MapReduce Service）功能。用户只需要提供简单的配置参数和模板，如版本信息（CDH 版本）、集群拓扑（几个 Slave、几个 Datanode）、节点配置信息（CPU、内存）等，Sahara 服务就能够在几分钟内根据提供的模板快速 部署 Hadoop、Spark 及 Storm 集群。Sahana 是一个大数据分析项目

 

Ironic

把裸金属机器（与虚拟机相对）加人到资源池中

 

Zaqar

Zaqar 为 Web 和移动开发者提供多租户云消息和通知服务，开发人员可以通过 REST API 在其云应用的不同组件中通过不同的通信模式（如 生产者/消费者或发布者/订阅者）来传递消息

 

Barbican

是 OpenStack 的密钥管理组件，其他组件可以调用 Barbican 对外暴露的 REST API 来存储和访问密钥

 

Manila

为虚拟机提供文件共享服务，不过需要存储后端的配合

其他组件

Congress（策略服务）、Designate（DNS 服务）、Freezer（备份及还原服务）、Magnum（容器支持）、Mistral（工作流服务）、Monasca（监控服务）、Searchlight（索引和搜索）、Senlin（集群服务）、Solum（APP集成开发平台）、Tacker（网络功能 虚拟化）、Trove（数据库服务）

2.2、Openstack优势

①模块松耦合：与其他开源软件相比，OpenStack模块分明。添加独立功能的组件非常简单。有时候，不需要通读整个OpenStack的代码，只需要了解其接口规范及API使用，就可以轻松地添加一个新的模块

②组件配置较为灵活：OpenStack也需要不同的组件。但是OpenStack的组件安装异常灵活。可以全部都装在一台物理机上，也可以分散至多个物理机中，甚至可以把所有的结点都装在虚拟机中。

③二次开发容易：OpenStack发布的OpenStack API是Rest-full API。其他所有组件也是采种这种统一的规范。因此，基于OpenStack做二次开发，较为简单。而其他3个开源软件则由于耦合性太强，导致添加功能较为困难。

④兼容性：OpenStack兼容其他公有云，方便用户进行数据迁移。

⑤可扩展性：模块化设计，可以通过横向扩展，增加节点、添加资源。

三、OpenStack架构

OpenStack是由一系列具有RESTful接口的Web服务所实现的，是一系列组件服务集合。如下图为OpenStack的概念架构，我们看到的是一个标准的OpenStack项目组合的架构。这是比较典型的架构，但不代表这是OpenStack的唯一架构，我们可以选取自己需要的组件项目，来搭建适合自己的云计算平台，设计的基本原则如下：

  • 按照不同的功能和通用性来划分不同项目并拆分子系统
  • 按照逻辑计划、规格子系统之间的通信
  • 通过分层设计整个系统架构
  • 不同的功能子系统间提供统一的API接口

3.1、概念架构图

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

3.2、逻辑架构图

  • 虽然上面这幅图看上去很复杂，但是分层去看的话，就可以较为容易的去了解它，OpenStack包括若干个服务的独立组件，像之前我们提到的核心组件以及一些可选组件都是在这幅图里面的，比如nova、keystone、Horizon等，我们先去找到这些组件，然后再去分析下一层
  • 每个组件里有各自的一些服务，所有服务都需要通过keystone进行身份验证，每个服务之间又可以关联若干个组件，每个服务至少有一个API进程，通过去监听API的请求，并对这些请求进行预处理，并将它们发送到相对于该服务的其他组件，服务之间可以通过公共API进行交互
  • 服务之间的通信使用AMQP消息代理，将服务的状态信息存储在数据库中

OpenStack组件通信关系：

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

3.3、OpenStack物理架构

整个OpenStack是由控制节点，计算节点，网络节点，存储节点四大部分组成。

控制节点负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等

计算节点负责虚拟机运行

网络节点负责对外网络与内网络之间的通信

存储节点负责对虚拟机的额外存储管理等等

①控制节点

控制节点包括支持服务、基础服务、扩展服务以及管理网络

  • 因为控制节点是管理整个OpenStack进行运作的，所有需要keystone身份认证服务以及Harizon控制面板服务这样的全局组件来对OpenStack进行管控和操作
  • 为虚拟机提供一些相对应的基础资源，比如glance镜像服务为虚拟机提供磁盘镜像文件、network网络服务对网络资源进行管理，提供/一组应用编程接口(API)，用户可以调用它们来定义网络以及nova计算服务管理虚拟机的整个生命周期
  • 数据的存储以及通信支持，我们使用到的是Mysql与RabbitMQ，后续我们需要对数据进行管理需要使用Cinder、Swift以及trove服务，并且提供对物理资源以及虚拟资源的监控，并记录这些数据，对该数据进行分析，在一定条件下触发相应动作的ceilometer计量服务
  • 而且还需要基于模板来实现云环境中资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩,负载均衡等高级特性的heat服务
  • 管理私有网段与公有网段的通信，以及管理虚拟机网络之间的通信/拓扑，所以需要网络接口和外面进行连通

②网络节点

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

③计算节点

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

④存储节点

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

四、核心服务概述

4.1、Keystone身份认证服务

4.1.1、Keystone概念

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

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

4.1.2、主要功能

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

4.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的地址，即用户创建一个项目过程中需要的各个服务资源的位置

Keystone工作流程

  • 用户通过命令行或者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可调用底层硬件资源进行创建。创建完成返回给用户，成功执行了用户的请求。

4.2、Glance镜像服务

它在OpenStack中的项目名称为Glance。在早期的OpenStack版本中，Glance只有管理镜像的功能，并不具备镜像存储功能。现在，Glance已发展成为集镜像上传、检索、管理和存储等多种功能的OpenStack核心服务

4.2.1、镜像

镜像的英文名为Image，又译为映像，通常是指一系列文件或一个磁盘驱动器的精确副本。镜像文件其实和ZIP压缩包类似，它将特定的一系列文件按照一定的格式制作成单一的文件，以方便用户下载和使用

4.2.2、镜像服务

镜像服务就是用来管理镜像的，让用户能够发现、获取和保存镜像。在OpenStack中提供镜像服务的是Glance，其主要功能如下：

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

4.2.3、Image API的版本

Glance提供的RESTful API目前只有两个版本：API v1和API v2

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

两个版本对镜像存储支持相同，v1从N版开始已经过时，迁移路径使用v2进行替代

4.2.4、镜像格式

虚拟机镜像文件磁盘格式

  • raw：无结构的磁盘格式
  • vhd：改格式通用于VMware、Xen、VirtualBox以及其他虚拟机管理程序
  • vhdx：vhd格式的增强版本，支持更大的磁盘尺寸
  • vmdx：一种比较通用的虚拟机磁盘格式
  • vdl：由VirtualBox虚拟机监控程序和QEMU仿真器支持的磁盘格式
  • iso：用于光盘（CD-ROM）数据内容的档案格式
  • ploop：由Virtualzzo支持，用于运行OS容器的磁盘格式
  • qcow2：由QEMU仿真支持，可动态扩展，支持写时复制（Copy on Write）的磁盘格式
  • aki：在Glance中存储的Amazon内核格式
  • ari：在Glance中存储的Amazon虚拟内存盘（Ramdisk）格式
  • ami：在Glance中存储的Amazon机器格式

虚拟机镜像文件容器格式

  • bare：没有容器或元数据“信封”的镜像
  • ovf：开放虚拟化格式
  • ova：在Glance中存储的开放虚拟化设备格式
  • aki：在Glance中存储的Amazon内核格式
  • ari：在Glance中存储的Amazon虚拟内存盘（Ramdisk）格式
  • Docker：在Glance中存储的容器文件系统的Docker的tar档案

如果不能确定选择哪种容器格式，那么简单地容器格式指定为bare是最安全地

4.2.5、镜像状态

镜像从上传到识别的过程：

  • queued：初始化过程，镜像文件刚被创建，在Glance数据库只有其元数据，镜像数据还没有上传至数据库中
  • saving：导入数据库过程，是镜像地原始数据在上传到数据库中地一种过渡状态，表示正在上传镜像
  • uploading：提交给服务识别过程，指示已进行导入数据提交调用，此状态下不允许调用PUT/file（saving状态会执行PUT/file，这是另外一种上传的方法）
  • importing：准使用状态，指示已经完成导入调用，但是镜像还未准备好使用

镜像上载完成后的状态

  • active：表示可使用
  • deactivated：表示只对管理员开放的权限
  • killed：表示镜像上传中发生错误
  • deleted：镜像将在不久后自动删除，镜像不可用（保留数据）
  • pending_delete：与deleted类似，但是删除后无法恢复

4.2.6、访问权限

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

4.2.7、架构图

  • 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] 模块。

4.2.8、流程解析

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

  • Auth(授权)：用来控制镜像的访问权限，决定镜像信息是否可以修改

②黄色方框的glance domain controller 是主用的中间件，相当于调度器，作用是将glance 内部服务的操作分发到下面的各个功能层

  • Policy（规则定义）：定义镜像操作的访问规则
  • Quota（配额限制）：管理员对用户定义了镜像大小的镜像上传上限
  • Location（定位）：通过glance_store与后台进行交互，在该层新位置添加进行时检查位置URI是否正确，防止镜像位置重复

③蓝色方框里镜像的元数据是通过glance-registry存放在数据库中。镜像本身（chunk 块数据）是通过glance的存储驱动存储在后端的各种存储系统中。

  • Registry Layer（注册层）：通过使用单独的服务控制Glance Controller与Glance DB之间的安全交互
  • Glance DB：存储镜像的元数据信息
  • Glance Store：用来处理Glance和各种存储后端的交互，提供了一个统一接口来访问后端的存储

④绿色方框是存储后端（store backend）将镜像本身的数据存放在后端存储系统

  • DB（数据库）：实现与数据库进行交互的API，将镜像转换为响应的格式存储在数据库中

4.3、Nova计算服务

4.3.1、Nova计算服务

  • nova计算服务是openstack最核心的服务之一，负责维护和管理云环境的计算资源
  • nova本身并不提供虚拟化的能力，他通过计算服务使用不同的虚拟化驱动来与底层的Hypervisor进行交互，nova对所有的计算实例进行生命周期的管理
  • nova需要其他服务组件的支持，比如Glance、Keystone、Neutron以及Cinder等，通过与这些服务的支持实现实例的管理

4.3.2、Nova系统架构

 

 

Nova由多个服务器进程构成，每个进程执行不同的功能，下面介绍各个组件的功能

①DB：用于数据存储的sql数据库

②API：用于接收HTTP请求、通过消息队列或HTTP与其他组件通信

  • API是访问nova的接口，nova-api服务接收和处理来自用户的所有计算api请求，它是openstack对外服务最主要的接口并且提供了可以查询所有api的端点，也是外部访问并使用nova提供的各种服务的唯一途径，nova-api对接收到的api请求有以下几个步骤，首先检查客户端传过来的参数是否合法，如果合法则调用其他服务来处理客户端的HTTP请求，最后格式化nova其他子服务返回结果并返回给客户端
  • API提供REST标准调用服务，便于与第三方系统集成，只要与虚拟机生命周期相关的操作，nova-api都会响应
  • 用户不会直接发送RESTful API请求，而是通过命令行、控制台和其他需要跟nova交换的组件来使用这些API

③Scheduler：用于决定那台计算节点承载计算实例的nova调度器

简介

  • 调度器，它主要由nova-scheduler服务实现，它可以解决如何选择在哪个节点上启动实例，并通过调度算法来确定虚拟机具体创建在哪一个计算服务器上，nova-scheduler服务会通过读取数据库的内容，从可用的资源中选择最合适的计算节点来吃新的虚拟机实例
  • 创建虚拟机的过程中，用户会提出各种各样的资源要求，比如Cpu、内存以及磁盘各需要多少，openstack会根据用户的需求，来确定具体使用哪个实例

调度器的类型

  • 随机调度器：从所有正常运行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，根据计算节点空闲的内存计算权重，内存空闲越多权重越大，实例将被部署到内存空闲最大的计算节点。

④Network：管理IP转发、网桥或虚拟局域网的nova网络组件

⑤Compute：管理Hypervisor与虚拟机之间通信的nova计算组件

⑥Conductor：处理需要协调的虚拟处理对象转换

schedule组件小结：

定位：决定实例具体创建在哪个计算节点

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

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

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

4.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组件可以调用虚拟化的资源，创建实例。

 

 

 

4.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的数量来应对日益增长的计算节点对数据库的访问量。

4.3.5、 Placement API

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

4.3.6、虚拟机实例化流程

  • 用户访问控制台
    可以通过多种方式访问虚拟机的控制台：
    ■ 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服务实现虚拟机的创建。

4.3.7、Nova部署架构

经典部署架构：

负载均衡部署架构：

4.3.8、Nova的Cell架构

 

使用此架构原因

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

cell概念

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

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数据库中调取到请求的最终结果，格式化后返回给用户。

4.4、Neutron 网络服务

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

4.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组件进行整合

4.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。

4.4.4、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

 

posted @ 2020-12-09 15:07  yy1299050947  阅读(1509)  评论(0)  编辑  收藏  举报