标签：总结 虚拟机 Nova Heat Keystone OpenStack HCIP Neutron

目录

• 第一章 架构介绍
  • 1. OpenStack 简介
    • 1.1 OpenStack 简述
    • 1.2 OpenStack 工作原理概述
    • 1.3 开源OpenStack版本介绍
    • 1.4 设计理念
    • 1.5 OpenStack 与云计算
  • 2. OpenStack 架构
    • 2.1 OpenStack 架构简介
  • 3. OpenStack 核心服务
  • 4. OpenStack 服务交互
• 第二章 界面管理
  • 1. Horizon 简介
    • 1.1 简介
    • 1.2 核心价值
    • 1.3 与其他组件的交互关系
  • 2. Horizon 架构
  • 3. Horizon 界面介绍
• 第三章 认证管理
  • 1. Keyston 简介
    • 1.1 简介
    • 1.2 基本概念
    • 1.3 在OpenStack中的作用
    • 1.4 与其他组件的交互关系
  • 2. Keyston 架构
  • 3. Keyston 对象模型
    • 3.1 Keystone对象模型-Service
    • 3.2 Keystone对象模型-Identity
    • 3.3 Keystone对象模型-Resource
    • 3.4 Keystone对象模型-Assignment
    • 3.5 Keystone对象模型-Token
    • 3.6 Keystone对象模型-Catalog
    • 3.7 Keystone对象模型分配关系
    • 3.8 Keystone对象模型使用示例
  • 4. Keyston 工作原理和流程
    • 4.1 Keystone 认证方式
    • 4.2 令牌认证方式以及对比
    • 4.3 创建VM认证流程
    • 4.4 RBAC：基于角色的访问控制-流程
    • 4.5 RBAC：基于角色的访问控制-原理
    • 4.6 问题：Keystone如何实现认证和权限控制？
• 第四章 镜像管理
  • • 1. Glance 简介
      • 1.1 简介
      • 1.2 在OpenStack中的作用
    • 2. Glance 架构
    • 2.1 Galace各个组件作用
    • 3. Glance 工作原理和流程
    • 3.1 OpenStack中的镜像、实例和规格
    • 3.2 Glance 状态机
    • 3.3 镜像与实例交互流程
    • 4. Glance 镜像制作
    • 4.1 直接下载镜像文件
    • 4.2 制作镜像-手动
    • 4.3 镜像制作-常用工具
    • 4.4 镜像转换
• 第五章 计算管理
  • 1. Nova 简介
  • 2. Nova 架构
    • 2.1 Nova 系统架构
    • 2.2 Nova 架构
    • 2.3 Nova 组件
  • 3. Nova 工作原理和流程
    • 3.1 虚拟机状态介绍
    • 3.2 Nova创建虚拟机流程 ⭐
    • 3.3 Nova调度过程
  • 4. Nova 典型操作
    • 4.1 nova 典型操作
    • 4.2 noca 主要操作对象
• 第六章 存储管理
  • 1. OpenStack 存储服务概述
  • 2. Cinder 块存储服务
    • 2.1 简介
    • 2.2 架构
    • 2.3 工作原理 - 创建和挂载流程
    • 2.4 实验
  • 3. Swift 对象存储服务
    • 3.1 简介
    • 3.2 架构
      • 3.2.1 架构简介
      • 3.2.2 数据模型
      • 3.2.3 Swift系统架构
      • 3.2.4 Swift 组件
      • 3.2.5 Swift API
    • 3.3 工作原理
• 第七章 网络管理
  • 1. Linux 网络虚拟化基础
    • 1.1 物理网络与虚拟化网络
    • 1.2 Linux网络虚拟化实现技术
      • 1.2.1 网卡虚拟化
      • 1.2.2 交换机虚拟化
      • 1.2.3 网络隔离
  • 2. Neutron 简介
  • 3. Neutron 概念
  • 4. Neutron 架构
  • 5. Neutron 典型操作及流程
  • 6. Neutron 网络流量分析
    • 6.1 Linux Bridge + Flat/VLAN 网络
    • 6.2 Open vSwitch + VXLAN 网络
• 第八章 编排管理
  • 1. Heat 简介
  • 2. Heat 架构
    • 2.1Heat 架构
    • 2.2 Heat 组件
    • 2.3 Heat Engine 架构
    • 2.4 Heat模板
  • 3. Heat 典型编排场景
    • 3.1 Heat编排场景
    • 3.2 Heat对基础架构资源的编排
    • 3.3 Heat对软件配置和部署的编排
    • 3.4 Heat对资源自动伸缩的编排
    • 3.5 Heat负载均衡的编排
    • 3.6 Heat和配置管理工具集成
• 第九章 计量管理
  • 1. Ceilometer 简介
  • 2. Ceilometer 架构
  • 3. Ceilometer 数据管理

第一章 架构介绍

1. OpenStack 简介

1.1 OpenStack 简述

OpenStack 是什么?

• OpenStack是虚拟机、裸金属和容器的云基础架构

• OpenStack可控制整个数据中心的大型计算、存储和网络资源池

• 所有资源都通过API或Web界面进行管理

OpenStack 能做什么?

• OpenStack通过一组相互关联的服务提供基础设施即服务 （IaaS）解决方案。每个服务都提供了一个应用程序编程接口 （API）来促进这种集成

• OpenStack项目是一个适用于所有类型云的开源云计算平台，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台

1.2 OpenStack 工作原理概述

• OpenStack、虚拟化和基础操作系统，这 3 种技术协同工作服务用户

• OpenStack实际上由一系列叫作脚本的命令组成

• 创建环境使用其他类型的软件

  虚拟化软件，用于创建从硬件中抽象出来的虚拟资源层

  基础操作系统（OS），用于执行OpenStack脚本发出的命令

• OpenStack本身不会虚拟化资源，但会使用虚拟化资源来构建云

1.3 开源OpenStack版本介绍

​ 从2010年每个版本开始，版本的命名为字母A-Z

1.4 设计理念

1. 开放
2. 灵活
3. 可拓展

1.5 OpenStack 与云计算

OpenStack只是构建云计算的关键组件：

• 内核、骨干、框架、总线

构建云计算需要的东西:

2. OpenStack 架构

2.1 OpenStack 架构简介

​ 生产环境中，一般会有专门的OpenStack部署服务节点、控制节点、计算节点、网络节点和存储服务节点等。

3. OpenStack 核心服务

• 界面管理服务-Horizon

  • 提供Web端控制界面

• 认证服务-Keystone

  • 提供身份验证

• 镜像服务-GLANCE

  • 提供镜像快照服务

• 计算服务-NOVA

  • 提供计算资源，完成计算

• 块存储服务-Cider

  • 存储服务。提供持久化存储

• 对象存储服务-Swift

  • 提供分布式的对象存储服务

• 网络服务-Neutron

  • 负责管理虚拟网络

• 编排服务-Heat

  • 编排基础架构资源

• 计量服务-Ceilometer

  • 数据收集服务，提供客户计费、资源跟踪和警报功能

4. OpenStack 服务交互

创建虚拟机实例需要资源

1. 计算
2. 存储
3. 网络
4. 镜像

第二章 界面管理

1. Horizon 简介

1.1 简介

• Horizon属于全局组件之一，提供一个Web管理界面，与OpenStack其他服务交互

• 管理员与用户可以通过Horizon实现资源的管理、实例的生命周期管理以及连接插件等

Horizon是OpenStack的一个子项目，用于提供一个web前端控制台（称为Dashboard），以此来展示OpenStack的功能。

1.2 核心价值

• 核心支持：对所有核心OpenStack项目提供开箱即用的支持。

• 可扩展性：每个开发者都能增加组件。

• 易于管理：架构和代码易于管理，浏览方便。

• 视图一致：始终保持视觉和交互范式一致性。

• 易于使用：用户界面友好，提供人们想要使用的强大界面。

• 可兼容性：API强调向后兼容性。

1.3 与其他组件的交互关系

​ 用户可以通过浏览器使用Horizon提供的控制面板来访问云平台的计算、存储和网络资源，比如启动虚拟机实例、创建子网、分配IP地址、设置访问控制等。

2. Horizon 架构

​ 基于Django的Horizon体系结构如图，底层API模块openstack_dashboard.api将OpenStack其他项目的API封装起来以供Horizon其他模块调用。

• Horizon采用了Django框架，简单来说Horizon是一个基于Django的网站，同时Horizon采用了许多流行的前端技术来扩展其功能

  • Web开发构成三部分：业务逻辑代码，静态文件，模板

• Django的设计哲学中，业务逻辑与表现逻辑是分开的，Django视图是代表业务逻辑的，模板系统则被视为控制表现与表现逻辑相关的工具

• Horizon秉承了这种哲学，遵循DRY(不要重复开发)原则，专注于代码的高度可用，致力于支持可扩展的控制面板的框架，尽可能地重复利用已有的模板开发和管理OpenStack网站

• Horizon面板设计分为3层：Dashboard --> PanelGroup --> Panel

3. Horizon 界面介绍

1. OpenStack Horizon界面-项目

   项目是云中的组织单位，也称为租户。每个用户都是一个或多个项目的成员。在项目中，用户创建和管理实例。

   在项目界面，用户可以查看和管理选定项目中的资源，包括实例、镜像、密钥对和主机组。

2. OpenStack Horizon界面-管理员

   管理员界面提供管理员可以管理的资源，例如计算、存储、网络和系统设置等。

3. OpenStack Horizon界面-身份管理

   身份管理界面提供认证管理功能。

第三章 认证管理

1. Keyston 简介

1.1 简介

• OpenStack Identity，代号为Keystone，是OpenStack默认的身份管理系统

• 如图所示，Keystone属于共享服务层，为OpenStack其他项目提供认证

1.2 基本概念

• Domain：一个域可以对应一个大的机构、一个数据中心，并且必须全局唯一。云的终端用户可以在自己的Domain中创建多个Project、User、Group和Role。具备对多个Project进行统一管理的能力。

• User：Keystone会通过认证信息（Credential，如密码等）验证用户请求的合法性，通过验证的用户将会分配到一个特定的令牌，该令牌可以被当作后续资源访问的一个通行证，并非全局唯一，只需要在域内唯一即可。

• Group：用户组是一组User的容器，可以向Group中添加用户，并直接给Group分配角色，在这个Group中的所有用户就拥有了Group所拥有的角色权限。通过引入Group的概念，Keystone实现了对用户组的管理，达到了同时管理一组用户权限的目的。

• Project：项目是各个服务中的一些可以访问的资源集合。我们需要在创建虚拟机时指定某个项目，在Cinder创建卷时也需要指定具体的项目。用户总是被默认绑定到某些项目上，在用户访问项目的资源前，必须具有对该项目的访问权限，或者说在特定项目下被赋予了特定的角色。项目不必全局唯一，只需要在某个域下唯一即可。

• Role：一个用户所具有的角色，角色不同意味着被赋予的权限不同，只有知道用户被赋予的角色才能知道该用户是否有权限访问某资源。用户可以被赋予一个域或项目内的角色。一个用户被赋予域的角色意味着他对域内所有的项目都具有相同的角色，而特定项目的角色只具有对特定项目的访问权限。角色可以被继承，在一个项目树下，拥有父项目的访问权限也意味着同时拥有对子项目的访问权限。角色必须全局唯一。

• Service：服务，如Nova、Swift、Glance、Cinder等。一个服务可以根据User、Tenant和Role确认当前用户是否具有访问其资源的权限。服务会对外暴露一个或多个端点，用户可以通过这些端点访问资源并执行操作。

• Endpoint：端点，是指一个可以用来访问某个具体服务的网络地址，我们可以将端点理解为服务的访问点。如果我们需要访问一个服务，就必须知道它的Endpoint。一般以一个URL地址来表示一个端点。

• Token：令牌，令牌是允许访问特定资源的凭证。无论通过何种方式，Keystone的最终目的都是对外提供一个可以访问资源的令牌。

• Credential：凭证，确认用户身份的数据，如用户的用户名和密码。

1.3 在OpenStack中的作用

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

• 用户从Keystone获取令牌及服务目录；用户在访问服务时，发送自己的令牌；相关服务向Keystone求证令牌的合法性

• Identity：身份服务，提供身份验证凭证及有关用户和用户组数据。

• Token：令牌，Keystone在确认用户的身份后，会给用户提供一个核实身份且可以用于后续资源请求的令牌。

• Catalog：对外提供一个服务的查询目录，服务目录存储了OpenStack所有服务的Endpoint信息。

• Policy：安全策略或者访问控制，一个基于规则的身份验证引擎，通过配置文件来定义各种动作与用户角色的匹配关系。

• Resource：提供关于Domain和Project的数据。

• Assignment：提供关于Role和Role Assignment的数据，负责角色授权。

1.4 与其他组件的交互关系

​ 在OpenStack的整体框架结构中，Keystone的作用类似于一个服务总线，Nova、Glance、Horizon、Swift、Cinder及Neutron等其他服务都通过Keystone来注册其服务的Endpoint，针对这些服务的任何调用都需要经过Keystone的身份认证，并获得服务的Endpoint来进行访问。

2. Keyston 架构

• Keystone Middleware (中间件) 是Keystone提供的对令牌合法性进行验证的中间件。

• 对于Keystone项目本身，除了后台的数据库，主要包括一个处理RESTful请求的API服务进程。这些API涵盖了Identity、Token、Catalog和Policy等Keystone提供的各种服务，这些不同服务所能提供的功能则分别由相应的后端Driver（Backend Driver）实现。

3. Keyston 对象模型

​ Keystone的管理主要是针对Identity、Resource、Assignment、Token、Catalog、Service，这些对象具体由其他更小的对象实现。

​ 同时OpenStack各种资源和服务的访问策略由Policy定义。

3.1 Keystone对象模型-Service

• Keystone是在一个或多个端点（Endpoint）上公开的一组内部服务（Service）

• Keystone内部服务包括Identity、Resource、Assignment、Token、Catalog

• Keystone许多内部服务以组合方式使用

• Keystone还负责与OpenStack其他服务（Service）进行交互，例如计算，存储或镜像，提供一个或多个端点，用户可以通过这些端点访问资源并执行操作

3.2 Keystone对象模型-Identity

Identity服务提供身份凭据验证以及用户（User）和用户组（Group）的数据

3.3 Keystone对象模型-Resource

• Resource服务提供有关项目（Project）和域（Domain）的数据
• Project是OpenStack资源拥有者的基本单元，OpenStack中所有资源都属于特定项目
• Domain把项目、用户和组作为一个整体管理，每种资源都属于某个特定域。Keystone默认域名为“Default”

3.4 Keystone对象模型-Assignment

Assignment服务提供有关角色（Role）和角色分配（ Role Assignment）的数据

3.5 Keystone对象模型-Token

• Token服务提供用户访问服务的凭证，代表着用户的账户信息

• Token一般包含User信息、Scope信息（Project、Domain或者Trust）、Role信息

3.6 Keystone对象模型-Catalog

• Catalog服务提供用于查询端点（Endpoint）的端点注册表，以便外部访问OpenStack服务

• 访问策略规则以JSON格式指定，文件名为policy.json

3.7 Keystone对象模型分配关系

3.8 Keystone对象模型使用示例

User：

• 获取Token

• 获取Service Catalog

Admin User：

• 管理Users，Projects，Roles

• 管理特定Project中Users的Roles

• 管理Services，Services的Endpoints

Service：

• 验证Token

• 定位其他Service的位置

• 调用其他Service

4. Keyston 工作原理和流程

4.1 Keystone 认证方式

1. 基于令牌的认证

   ​ 最常用的Keystone认证方式，使用方式简单

   ​ 认证请求发送时添加一个“X-Auth-Token”的HTTP头，Keystone检查该HTTP头中的Token值，并与数据库中的令牌值进行比对验证

2. 基于外部的认证

   ​ 集成使用第三方认证系统，在认证请求中添加“REMOTE_USER”信息

3. 基于本地的认证

   ​ 默认认证方式，即用户名和密码认证

4.2 令牌认证方式以及对比

1. UUID
2. PKI
3. PKIZ
4. Fernet

4.3 创建VM认证流程

​ keystone只检验Token是否有效，每个服务的操作权限控制是基于角色的管理

4.4 RBAC：基于角色的访问控制-流程

​ 在OpenStack中使用RBAC进行访问控制，RBAC是基于角色访问控制（Role-Based Access Control），在RBAC中，权限与角色相关连，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理，这样管理都是层级相互依赖的，权限直接赋予给角色，而把角色又赋予给用户，这样的权限设计很清楚，管理起来也很方便

​ 首先客户发送请求，由Keystone的Token模块进行Token有效性认证，认证通过后，由Policy模块来验证Auth context，即认证上下文，实际上Policy.json文件是实现RBAC的关键机制，之前我们在介绍Policy的时候也提到过，该文件一般存于组件的配置目录下，该文件在修改后立即生效，不需要重启服务。整个验证过程如果成功，进行下一步反馈信息。如果失败直接反馈403禁止，表示权限认证失败。

4.5 RBAC：基于角色的访问控制-原理

4.6 问题：Keystone如何实现认证和权限控制？

1. 用户在OpenStack控制面板上创建一个VM，Keystone如何认证该用户，如何验证该用户具有创建VM的权限？

   Token

2. 用户在OpenStack CLI上创建一个VM，Keystone如何认证该用户，如何验证该用户具有创建VM的权限？

   RBAC 使用 policy.json 配置

3. 两种方式对Keystone有区别吗？

   ​ 只要是通过API接口进入的，内部验证没有区别。

   ​ 无论是操作界面或是CLI，Keystone的认证和权限控制原理都是一样的，发放Token，验证Token，都是通过Policy.json实现权限控制。

​ 首先用户发送基本信息给Keystone，一般是用户名和密码。Keystone经过验证后会返回一个Token给用户，用户向Nova发送创建虚拟机请求，并携带Token信息，nova接收到请求后，会拿着Token去Keystone进行验证，验证成功后开始执行创建VM操作，Nova会向Glance发送申请镜像信息并携带Token，会向Neutron发送申请网络信息也会携带Token，Glance和Neutron组件接收到请求后，都会向Keystone验证Token的有效性（图中仅用了一条线表示，请注意理解），验证通过即执行相应的操作，返回完成信息，当VM创建完成后，Nova返回创建成功信息给用户，用户即可使用虚拟机。

第四章 镜像管理

1. Glance 简介

1.1 简介

• Glance即OpenStack Image service，Glance有一个RESTful API，允许查询VM镜像元数据以及检索实际镜像

• 如下图所示，Glance属于共享服务层，用户可以在其中上传和发现能与其他服务一起使用的数据资产

1.2 在OpenStack中的作用

• 在OpenStack上创建虚拟机时，必须为其选择需要安装的操作系统，glance服务就是为该选择提供不同的操作系统镜像。

• 镜像的元数据保存在数据库中，而镜像本身是通过Glance Store Drivers存放到各种backend store中。

依赖与功能

2. Glance 架构

2.1 Galace各个组件作用

• Client：使用Glance服务的应用程序，可以是命令行工具、horizon、nova等。

• REST API：Glance是一个client-server架构，提供一个REST API，而使用者就是通过REST API来执行关于镜像的各种操作。

• Glance Domain Controller：是Glance内主要的中间件实现，就相当于一调度员，作用是将Glance内部服务的操作分发到各层（Auth认证、Notifier、Policy策略、Quota、Location及DB数据库连接）具体任务由每个层实现。

• Registry Layer：属于可选的层，用来组织安全。通过使用这个单独的服务，来控制Glance Domain Controller与Glance DB之间的通信。

• Glance DB：Glance服务Database Abstraction Layer** (DAL) -数据库抽象层。

• 使用一个核心库Glance DB，该库对Glance内部所有依赖数据库的组件来说是共享的。

• Glance Store：用来组织处理Glance和各种存储后端的交互。所有的镜像文件操作都是通过调用Glance Store库执行的，它负责与外部存储端或本地文件系统的交互。Glance Store提供了一个统一的接口来访问后端存储。

3. Glance 工作原理和流程

3.1 OpenStack中的镜像、实例和规格

创建实例时必须指定镜像和规格

1. 镜像 Image

   虚拟机镜像包含一个虚拟磁盘，其上包含可引导的操作系统，为虚拟机提供模板

2. 实例 Instance

   实例是在OpenStack上运行的虚拟机

3. 规格 Flavor

   规格定义了实例可以有多少个虚拟CPU，多大的RAM以及多大的临时磁盘

4. 镜像、实例和规格的关系

   • 用户可以从同一个镜像启动任意数量的实例

   • 每个启动的实例都是基于镜像的一个副本，实例上的任何修改都不会影响到镜像

   • 启动实例时，必须指定一个规格，实例按照规格使用资源

3.2 Glance 状态机

Glance 中有两种状态机: 镜像状态和任务状态

queued：没有上传image数据，只有db中的元数据。

saving：正在上传image data，当注册一个镜像使用POST /images并且当前携带了一个x-image-meta-location头，这个镜像将不会进入saving状态(镜像的数据已经是可以获得的，不能重传)。

active：当镜像数据上传完毕，镜像就可以被使用了(可获得的)，此时处于active状态。

deactivated：表示任何非管理员用户都无权访问镜像数据，禁止下载镜像，也禁止像镜像导出和镜像克隆之类的操作（请求镜像数据的操作）。

killed：表示上传过程中发生错误，并且镜像是不可读的。

deleted：glance已经保存了该镜像的数据，但是该镜像不再可用，处于该状态的镜像将在不久后被自动删除。

pending_delete： 与deleted相似，glance还没有清除镜像数据，只是处于该状态的镜像不可恢复。

3.3 镜像与实例交互流程

实例启动前

Glance store包含一定数量的镜像，计算节点包含可用的vCPU，内存和本地磁盘资源，Cinder-volume包含一定数量的卷。

实例从镜像启动

实例删除后

​ 实例被删除后, 除cinder-volume卷之外的其他资源都会被回收。临时磁盘无论是否加密过，都将会被清空，内存和vCPU资源将会被释放。在这个过程中镜像不会发生任何改变。

注意：

​ 如果创建实例时选择了“删除实例时删除卷”，则实例删除时，cinder-volume卷也会被删除。

4. Glance 镜像制作

4.1 直接下载镜像文件

​ 最简单的Glance镜像制作方法是下载系统供应商官方发布的OpenStack镜像文件。大多数镜像预安装了cloud-init包，支持SSH密钥对登录和用户数据注入功能。

OpenStack社区网站：

https://docs.openstack.org/image-guide/obtain-images.html

4.2 制作镜像-手动

Virt-manager是一套图形化的虚拟机管理工具，提供虚拟机管理的基本功能，如开机、挂起、重启、关机、强制关机/重启、迁移等。

示例：制作Ubuntu 18.04 示例

1. 登录虚拟机并安装cloud-init

   $ sudo apt install cloud-init 
   

2. 虚拟机内部，停止虚拟机

   $ sudo shutdown –h now 
   

3. 预清理虚拟机

   $ sudo virt-sysprep –d VM ID
   

4. 释放虚拟机定义

   $ virsh undefine VM_ID
   

5. 制作镜像

   $ qemu-img create
   

6. 上传镜像

   $ openstack image create
   

4.3 镜像制作-常用工具

Diskimage-builder

​ 自动化磁盘映像创建工具，可以制作Fedora，Red Hat, Enterprise Linux，Ubuntu，Debian，CentOS和openSUSE镜像

$ disk-image-create ubuntu vm

Packer

​ 使用Packer制作的镜像，可以适配到不同云平台，适合使用多个云平台的用户

virt-builder

​ 快速创建新虚拟机的工具，可以在几分钟或更短的时间内创建各种用于本地或云用途的虚拟机镜像

4.4 镜像转换

命令行: qemu-img convert

示例：raw转换为qcow2

$ qemu-img convert -f raw -O qcow2 image.img image.qcow2 

命令行：VBoxManage

示例：VDI （VirtualBox）转换为RAW

$ VBoxManage clonehd image.vdi image.img -format raw 

第五章 计算管理

1. Nova 简介

nova简介

nova定位

• Nova即OpenStack Compute service，负责提供计算资源的模块，也是OpenStack中的核心模块

• Nova不包括虚拟化软件，Nova定义与底层虚拟化机制交互的驱动程序，并通过基于Web的API公开功能

Nova属于计算服务层，用户可以使用Horizon、Nova客户端、API或者CLI直接创建和管理计算实例。

依赖关系

2. Nova 架构

2.1 Nova 系统架构

• DB：用于数据存储的SQL数据库。

• API：接收 HTTP 请求、转换命令并通过oslo.messaging队列或 HTTP与其他组件通信的组件。

• Scheduler：为虚拟机选择合适的物理主机。

• Compute：虚拟机生命周期和复杂流程控制。

• Conductor：处理需要协调（构建/调整大小）的请求，充当数据库代理或处理对象转换。

• Placement：跟踪资源提供者的库存和使用情况。

• RPC：Remote Procedure Call，远程过程调用，是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。

• API服务器处理REST请求，通常涉及数据库读写，将RPC消息发送到其他Nova服务（可选），并生成对REST调用的响应。

• RPC消息传递是通过oslo.messaging库完成的，它是消息队列之上的抽象。

• Nova使用基于消息传递的“无共享”架构，大多数主要的nova组件可以在多个服务器上运行，并且有一个监听RPC消息的管理器。

2.2 Nova 架构

Nova物理部署实例

• 无中心架构

• 各组件无本地持久化状态

• 可水平扩展

• 通常将nova-api、nova-scheduler、nova-conductor组件合并部署在控制节点上

• 通过部署多个控制节点实现HA和负载均衡

• 通过增加控制节点和计算节点实现简单方便的系统扩容

Nova服务运行架构

Nova服务各组件可分布式部署，且可通过virtDriver对接不同的虚拟化平台。

Nova资源池管理架构

Region > Availability Zone > Host Aggregate。

2.3 Nova 组件

Nova-API 功能

• 对外提供REST接口，接收和处理请求

• 对传入参数进行合法性校验和约束限制

• 对请求的资源进行配额的校验和预留

• 资源的创建，更新，删除查询等

• 虚拟机生命周期管理的入口

Nova-Conductor功能

• 数据库操作，解耦其他组件(Nova-Compute)数据库访问

• Nova复杂流程控制，如创建，冷迁移，热迁移，虚拟机规格调整，虚拟机重建

• 其他组件的依赖，如nova-compute需要nova-conductor启动成功后才能启动

• 其他组件的心跳定时写入

Nova-Scheduler功能

• 筛选和确定将虚拟机实例分配到哪一台物理机

• 分配过程主要分为两步，过滤和权重：

• 通过过滤器选择满足条件的计算节点

• 通过权重选择最优的节点

Nova-Compute功能

• 虚拟机生命周期操作的真正执行者（会调用对应的hypervisor的driver）。

• 底层对接不同虚拟化的平台（KVM/VMware/XEN/Ironic等）。

• 内置周期性任务，完成资源刷新，虚拟机状态同步等功能。

• 资源管理模块（resource_tracker）配合插件机制，完成资源的统计。

3. Nova 工作原理和流程

3.1 虚拟机状态介绍

虚拟机状态类型

• vm_state：数据库中记录的虚拟机状态

• task_state：当前虚拟机的任务状态，一般是中间态或者None

• power_state：从hypervisor获取的虚拟机的真实状态

• Status：对外呈现的虚拟机状态

状态之间的关系

• 系统内部只记录vm_state和task_state，power_state

• Status是由vm_state和task_state联合生成的

举例

• vm_state为active，task_state为rebooting，则status为REBOOT

• vm_state为building，则status为BUILD

3.2 Nova创建虚拟机流程 ⭐

• Step1：用户通过Dashboard/CLI 申请创建虚拟机，并以REST API 方式来请求Keystone授权。

• Step2：keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。

• Step3：界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。

• Step4：nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。

• Step5：keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。

• Step6：通过认证后nova-api和数据库通讯。

• Step7：初始化新建虚拟机的数据库记录。

• Step8：nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源（Host ID）。

• Step9：nova-scheduler进程侦听消息队列，获取nova-api的请求。

• Step10：nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。

• Step11：对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。

• Step12：nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。

• Step13：nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。

• Step14：nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。

• Step15：nova-conductor从消息队队列中拿到nova-compute请求消息。

• Step16：nova-conductor根据消息查询虚拟机对应的信息。

• Step17：nova-conductor从数据库中获得虚拟机对应信息。

• Step18：nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。

• Step19：nova-compute从对应的消息队列中获取虚拟机信息消息。

• Step20：nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。

• Step21：glance-api向keystone认证token是否有效，并返回验证结果。

• Step22：token验证通过，nova-compute获得虚拟机镜像信息（URL）。

• Step23：nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。

• Step24：neutron-server向keystone认证token是否有效，并返回验证结果。

• Step25：token验证通过，nova-compute获得虚拟机网络信息。

• Step26：nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。

• Step27：cinder-api向keystone认证token是否有效，并返回验证结果。

• Step28：token验证通过，nova-compute获得虚拟机持久化存储信息。

• Step29：nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

3.3 Nova调度过程

4. Nova 典型操作

4.1 nova 典型操作

4.2 noca 主要操作对象

第六章 存储管理

1. OpenStack 存储服务概述

OpenStack 存储类型

​ 从数据保存时间的角度分为两类：临时存储（非持久存储）和持久存储

临时磁盘来源：

• 计算节点的本地磁盘。

• 通过NFS挂载的外部存储（使用此方式创建临时磁盘时，可以在多个计算节点之间迁移虚拟机，因为虚拟机实例的根磁盘位于可被多个物理主机访问的共享存储上）。

OpenStack 存储类型对比

OpenStack 持久存储简介

2. Cinder 块存储服务

2.1 简介

• Cinder是OpenStack 块存储服务，为Nova虚拟机、Ironic裸机、容器提供卷

• Cinder为后端不同的存储设备提供了统一的接口，不同的块设备服务厂商在Cinder中实现其驱动，使其可以被OpenStack整合管理

Cinder 作用

​ Cinder在虚拟机与具体存储设备之间引入了一层“逻辑存储卷”的抽象，Cinder本身不是一种存储技术，并没有实现对块设备的实际管理和服务

​ Cinder只是提供了一个中间的抽象层，为后端不同的存储技术，提供了统一的接口

2.2 架构

• Cinder Client封装Cinder提供的rest接口，以CLI形式供用户使用。

• Cinder API对外提供rest API，对操作需求进行解析，对API进行路由寻找相应的处理方法。包含卷的增删改查（包括从源卷、镜像、快照创建）、快照增删改查、备份、volume type管理、挂载/卸载（Nova调用）等。

• Cinder Scheduler负责收集backend上报的容量、能力信息，根据设定的算法完成卷到指定cinder-volume的调度。

• Cinder Volume多节点部署，使用不同的配置文件、接入不同的backend设备，由各存储厂商插入driver代码与设备交互完成设备容量和能力信息收集、卷操作。

• Cinder Backup实现将卷的数据备份到其他存储介质（目前SWIFT/Ceph/TSM提供了驱动）。

• SQL DB提供存储卷、快照、备份、service等数据，支持MySQL、PG、MSSQL等SQL数据库。

架构说明

Cinder架构部署

• Cinder-api，Cinder-Scheduler，Cinder-Volume可以选择部署到一个节点上，也可以分别部署

• API采用AA模式，HAproxy作为LB，分发请求到多个Cinder API

• Scheduler也采用AA模式，有rabbitmq以负载均衡模式向3个节点分发任务，并同时从rabbitmq收取Cinder volume上报的能力信息，调度时，scheduler通过在DB中预留资源从而保证数据一致性

• Cinder Volume也采用AA模式，同时上报同一个backend容量和能力信息，并同时接受请求进行处理

• RabbitMQ，支持主备或集群

• MySQL，支持主备或集群

Cinder组件-API

• Cinder API对外提供REST API，对操作需求进行解析，并调用处理方法：
  • 卷create/delete/list/show
  • 快照create/delete/list/show
  • 卷attach/detach (Nova调用)
  • 其他:
    • Volume types
    • Quotas
    • Backups

Cinder组件-Scheduler

• Cinder scheduler负责收集后端上报的容量、能力信息，根据设定的算法完成卷到指定cinder-volume的调度

• Cinder scheduler通过过滤和权重，筛选出合适的后端：

  1. 列出所有后端
  2. 根据后端的能力进行筛选
  3. 根据权重给后端排序
  4. 返回最合适的后端

Cinder组件-Volume

Cinder volume多节点部署，使用不同的配置文件、接入不同的后端设备，由各存储厂商插入Driver代码与设备交互，完成设备容量和能力信息收集、卷操作等

2.3 工作原理 - 创建和挂载流程

Cinder创建卷流程

Cinder创建卷流程-Cinder API

Cinder API

• 检查参数合法性（用户输入，权限，资源是否存在等）

• 准备创建的参数字典，预留和提交配额

• 在数据库中创建对应的数据记录

• 通过消息队列将请求和参数发送到Scheduler

Cinder创建卷流程-Cinder Scheduler

Cinder Scheduler服务

• 提取接收到的请求参数

• 通过配置的filter和输入参数对后端进行过滤

  • Availability_zone_filter
  • Capacity_filter
  • Capabilities_filter
  • Affinity_filter（SameBackendFilter/DifferentBackendFilter）
  • ……

• Weigher计算后端进行权重

  • CapacityWeigher/AllocatedCapacityWeigher
  • ChanceWeigher
  • GoodnessWeigher
  • ……

• 选取最优的Backend并通过消息队列将请求发送到指定的后端

Cinder创建卷流程-Cinder Volume

Cinder Volume服务

• 提取接收到的请求参数

• 调用对应的Driver在后端创建实际的卷

• 使用Driver返回的模型更新数据库中的记录

Cinder挂载卷流程

挂卷流程： 挂卷是通过Nova和Cinder的配合最终将远端的卷连接到虚拟机所在的Host节点上，并最终通过虚拟机管理程序映射到内部的虚拟机中

• Nova调用Cinder API创建卷，传递主机的信息，如hostname，iSCSI initiator name，FC WWPNs。

• Cinder API将该信息传递给Cinder Volume。

• Cinder Volume通过创建卷时保存的host信息找到对应的Cinder Driver。

• Cinder Driver通知存储允许该主机访问该卷，并返回该存储的连接信息（如iSCSI iqn，portal，FC Target WWPN，NFS path等）。

• Nova调用针对于不同存储类型进行主机识别磁盘的代码（ Cinder 提供了brick模块用于参考）实现识别磁盘或者文件设备。

• Nova通知Cinder已经进行了挂载。

• Nova将主机的设备信息传递给hypervisor来实现虚拟机挂载磁盘。

2.4 实验

Cinder主要操作三个资源：

Volume：

块设备卷，提供创建，删除，扩容，挂载/卸载等功能

Snapshot：

针对于块设备卷的快照创建、删除、回滚等功能

Backup：

提供对块设备卷的备份，恢复能力

3. Swift 对象存储服务

3.1 简介

对象存储是具有成本效益的横向扩展存储的理想选择。它提供了一个完全分布式的、API可访问的存储平台，可以直接集成到应用程序中或用于备份、归档和数据保留。

• Swift是OpenStack对象存储服务，可以存储虚拟机实例创建所需的镜像

• Swift作为OpenStack持久存储之一，比较适合存放静态数据

​ Swift是OpenStack最初两大项目之一，由Rackspace于2010年贡献给OpenStack，并与Nova一起开启了OpenStack元年。

​ 静态数据：是指长期不会更新或者一定时期内更新频率比较低的数据，如虚拟机的镜像、多媒体数据、备份文件等。

​ 如果需要实时地更新数据，Cinder更为合适。

​ Swift并不是文件系统或者实时的数据存储系统，它称为对象存储，用于永久类型的静态数据的长期存储，这些数据可以检索、调整，必要时进行更新

​ 最适合存储的数据类型的例子是虚拟机镜像、图片存储、邮件存储和存档备份

​ 因为没有中心单元或主控结点，Swift提供了更强的扩展性、冗余和持久性

​ Swift经常用于存储镜像或用于存储虚拟机实例卷的备份副本

Swift特点:

1. 极高的数据持久性

   从理论上测算过，Swift在5个Zone、5×10个存储节点的环境下，数据复制份是为3，数据持久性的SLA能达到10个9。

2. 完全对称的系统架构

   “对称”意味着Swift中各节点可以完全对等，能极大地降低系统维护成本。

3. 无限的可扩展性

   这里的扩展性分两方面，一是数据存储容量无限可扩展；二是Swift性能（如QPS、吞吐量等）可线性提升。因为Swift是完全对称的架构，扩容只需简单地新增机器，系统会自动完成数据迁移等工作，使各存储节点重新达到平衡状态。

4. 无单点故障

   Swift的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。整个Swift集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。

Swift与其他服务的交互关系

3.2 架构

3.2.1 架构简介

如图所示，Swift从架构上可以划分为两个层次：访问层（Access Tier）与存储层（Storage Nodes）。

3.2.2 数据模型

• Swift存储对象的逻辑结构：Account/Container/Object（即帐户/容器/对象）

• 每层节点数均没有限制，可以任意扩展

3.2.3 Swift系统架构

存储位置有如下三种：

• /account

  • 帐户存储位置是唯一命名的存储区域，其中包含帐户本身的元数据（描述性信息）以及帐户中的容器列表。
  • 请注意，在Swift中，帐户不是用户身份。当您听到帐户时，请考虑存储区域。

• /account/container

  • 容器存储位置是帐户内的用户定义的存储区域，其中包含容器本身和容器中的对象列表的元数据。

• /account/container/object

  • 对象存储位置存储了数据对象及其元数据的位置。

3.2.4 Swift 组件

3.2.5 Swift API

• Swift通过Proxy Server向外提供基于HTTP的REST服务接口，对帐户、容器和对象进行CRUD等操作

• Swift RESTful API总结

  

  Swift API主要提供了以下功能：

  • 存储对象，并没有限制对象的个数。单个对象的大小默认最大值为5 GB，这个最大值用户可以自行配置。

  • 对于超过最大值的对象，可以通过大对象中间件进行上传和存储。

  • 压缩对象。

  • 删除对象，支持批量删除。

3.3 工作原理

Swift工作原理概述

​ Proxy Server负责处理用户的对象存取请求，Authentication（认证服务）负责对用户的身份进行认证，Proxy Server在接收到用户请求后，会把请求转发给存储节点上的Account Server、Container Server与Object Server进行具体的对象操作，而对象与其各个副本之间的数据一致性则由Auditor、Updater和Replicator来负责

Swift工作原理概述

Swift 关键技术

1. Ring
2. 一致性 哈希
3. 数据一致性模型

• Swift是基于一致性哈希技术，通过计算将对象均匀分布到虚拟空间的虚拟节点上，在增加或删除节点时可大大减少需移动的数据量
• Swift放弃严格一致性，而采用最终一致性模型（Eventual Consistency），来达到高可用和无限水平扩展能力；如果数据出现了不一致，后台服务进程会在一定的时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性
• Ring将虚拟节点（partition）均衡地映射到一组物理设备上，Swift中Ring使用zone来保证数据的物理隔离，每个partition的replica都确保放在不同的zone中

第七章 网络管理

1. Linux 网络虚拟化基础

1.1 物理网络与虚拟化网络

Server 服务 VM 虚拟机

​ NIC 网卡 vNIC 虚拟网卡

​ Switch 交换机 vSwitch 虚拟交换机

1.2 Linux网络虚拟化实现技术

1.2.1 网卡虚拟化

Linux网卡虚拟化-TAP/TUN/VETH

TAP设备：模拟一个二层的网络设备，可以接收和发送二层网包

TUN设备：模拟一个三层的网络设备，可以接收和发送三层网包

VETH：虚拟ethernet接口，通常以pair的方式出现，一端发出的网包，会被另一端接收，可以形成两个网桥之间的通道

1.2.2 交换机虚拟化

Linux交换机虚拟化-Linux bridge

• Linux bridge：工作于二层的网络设备，功能类似于物理交换机

• Bridge可以绑定Linux上的其他网络设备，并将这些设备虚拟化为端口

• 当一个设备被绑定到bridge时，就相当于物理交换机端口插入了一条连接着终端的网线

• 使用brctl命令配置Linux bridge：

  • brctl addbr BRIDGE

  • brctl addif BRIDGE DEVICE

Linux交换机虚拟化-Open vSwitch

Open vSwitch是产品级的虚拟交换机

• Linux bridge更适用于小规模，主机内部间通信场景

• Open vSwitch更适合于大规模、多主机间通信场景

Open vSwitch常用的命令：

• ovs-vsctl add-br BRIDGE

• ovs-vsctl add-port PORT

• ovs-vsctl show BRIDGE

• ovs-vsctl dump-ports-desc BRIDGE

• ovs-vsctl dump-flows BRIDGE

1.2.3 网络隔离

Linux网络隔离-Network Namespace

​ Network namespace能创建多个隔离的网络空间，它们有独自的网络配置信息，例如网络设备、路由表、iptables等

​ 不同网络空间中的虚拟机运行的时候仿佛自己就在独立的网络中

$ ip netns help 
Usage:  ip netns list
		ip netns add NAME 
		ip netns delete NAME 
		ip netns identify PID
		ip netns pids NAME 
		ip netns exec NAME cmd … 
		ip netns monitor

问题: OpenStack 节点上有哪些Linux虚拟网卡？

enp0s3：主机物理网卡；

tapxxxx: tap设备；

brqxxxx：bridge设备；

vxlan：vxlan子接口。

2. Neutron 简介

Neutron 本身是不依赖任何组件的

• OpenStack Neutron是一个SDN网络项目，专注于在虚拟计算环境中提供网络即服务（NaaS）

• Neutron允许用户创建由其他OpenStack服务管理的接口设备并将其连接到网络

Neutron作用

​ Neutron管理OpenStack环境中虚拟网络基础设施（VNI）和物理网络基础设施（PNI）的访问层面的所有网络方面

​ Neutron提供Network、Subnet、Router作为抽象对象，每个抽象对象都具有模仿其物理对应物的功能：Network包含Subnet，Router在不同Subnet和Network之间路由流量

​ 其中：Internet通过外部网络 --> Router（路由） --> Network（网络）==> Subnet（子网）

Network 包括 Subnet

Neutron与其他服务的交互关系

Neutron 本身是不依赖任何组件的，但是Neutron 调用Nova模块的时候 需要 Keystone 认证服务

3. Neutron 概念

• Neutron是一种虚拟网络服务，为OpenStack计算提供网络连通和寻址服务

• 为了便于操作管理，Neutron对网络进行了抽象，有如下基本管理对象：

  • Network
  • Subnet
  • Port
  • Router
  • Floating IP

Neutron概念-Network

Network：网络

​ 一个隔离的、虚拟二层广播域，也可看成一个Virtual Switch，或者Logical Switch

​ Neutron支持多种类型的Network，包括 Local、Flat、 VLAN、 VXLAN 和 GRE

• Local：与其他网络和节点隔离。Local网络中的虚拟机只能与位于同一节点上同一网络的虚拟机通信，Local网络主要用于单机测试。

• Flat：无VLAN tagging的网络。Flat网络中虚拟机能与位于同一网络的虚拟机通信，并可以跨多个节点。

• VLAN：802.1q tagging网络。VLAN是一个二层的广播域，同一VLAN中的虚拟机可以通信，不同VLAN只能通过Router通信。VLAN网络可跨节点，是应用最广泛的网络类型。

• VXLAN：基于隧道技术的overlay网络。VXLAN网络通过唯一的segmentation ID（也叫 VNI）与其他VXLAN网络区分。VXLAN中数据包会通过VNI封装成UDP包进行传输。因为二层的包通过封装在三层传输，能够克服VLAN和物理网络基础设施的限制。

• GRE：与VXLAN类似的一种overlay网络，主要区别在于使用IP包而非UDP进行封装。

• 生产环境中，一般使用的是VLAN、VXLAN或GRE网络。

Neutron概念-Subnet

Subnet：子网

​ 一个IPv4或者IPv6地址段。虚拟机的IP从Subnet中分配。每个Subnet需要定义IP地址的范围和掩码

​ Subnet必须与Network关联

​ Subnet可选属性：DNS，网关IP，静态路由

Neutron概念-Port

Port：端口

​ 逻辑网络交换机上的虚拟交换端口

​ 虚拟机通过Port附着到Network上

​ Port可以分配IP地址和Mac地址

Neutron概念-Router

Router：路由器

​ 连接租户内同一Network或不同Network之间的子网，以及连接内外网

Neutron概念-Fixed IP

类似于网关-固定的网关

Fixed IP：固定IP

​ 分配到每个端口上的IP，类似于物理环境中配置到网卡上的IP

Neutron概念-Floating IP

Floating IP：浮动IP

​ Floating IP是从External Network创建的一种特殊Port，可以将Floating IP绑定到任意Network中的Port上，底层会做NAT转发，将发送给Floating IP的流量转发到该Port对应的Fixed IP上

​ 外界可以通过Floating IP访问虚拟机，虚拟机也可以通过Floating IP访问外界

Neutron概念-Physical Network

Physical Network：物理网络

​ 在物理网络环境中连接OpenStack不同节点的网络，每个物理网络可以支持Neutron中的一个或多个虚拟网络

Neutron概念-Provider Network

Provider Network：

​ 由OpenStack管理员创建的，直接对应于数据中心现有物理网络的一个网段

​ Provider Network通常使用VLAN或者Flat模式，可以在多个租户之间共享

Neutron概念-Self-service Network

Self-service Network：自助服务网络，也叫租户网络或项目网络

​ 由OpenStack租户创建的，完全虚拟的，只在本网络内部连通，不能在租户间共享

​ Self-service Network通常使用VXLAN或者GRE模式，可以通过Virtual Router的SNAT与Provider Network 通信

Neutron概念-External Network

External Network：外部网络，也叫公共网络

​ 一种特殊的Provider Network，连接的物理网络与数据中心或Internet相通，网络中的Port可以访问外网

​ 一般将租户的Virtual Router连接到该网络，并创建Floating IP绑定虚拟机，实现虚拟机与外网通信

Neutron概念-Security Group

Security Group：安全组

​ 安全组是作用在neutron port上的一组策略，规定了虚拟机入口和出口流量的规则

​ 安全组基于Linux iptables实现

​ 安全组默认拒绝所有流量，只有添加了放行规则的流量才允许通过

​ 每个OpenStack项目中都有一个default默认安全组，默认包含如下规则：

​ 拒绝所有入口流量、允许所有出口流量

4. Neutron 架构

Neutron 架构图

• Neutron 架构原则

  • 统一API
  • 核心部分最小化
  • 可插入式的开放架构
  • 可扩展

• Message Queue

  • Neutron-server使用Message Queue与其他Neutron agents进行交换消息，但是这个Message Queue不会用于Neutron-server与其他OpenStack组件（如nova ）进行交换消息。

• L2 Agent

  • 负责连接端口（ports）和设备，使他们处于共享的广播域（broadcast domain）。通常运行在Hypervisor上。

• L3 Agent

  • 负责连接tenant网络到数据中心，或连接到Internet。在真实的部署环境中，一般都需要多个L3 Agent同时运行。

• DHCP agent

  • 用于自动配置虚拟机网络。

• Advanced Service

  • 提供LB、Firewall和VPN等服务。

Neutron 架构说明

​ Neutron的架构是基于插件的，不同的插件提供不同的网络服务，主要包含如下组件：

Neutron Server

Core Plugin

Service Plugin

• L3 Service Plugin

• LB Service Plugin

• Firewall Service Plugin

• VPN Service Plugin

各种Agent

• L2 （ovs-agent）

• L3 Agent

• DHCP Agent

• MetaData Agent

Neutron组件-Neutron Server

Neutron Server = APIs + Plugins

• API定义各类网络服务

• Plugin实现各类网络服务

Neutron组件-Core Plugin

Core Plugin，主要是指ML2 Plugin（Modular Layer 2。），是一个开放性框架，提供基础的网络功能，使用不同的drivers调用不同的底层网络实现技术。

• ML2 Plugin的Drivers主要分为以下两种：

  • Type Driver：定义了网络类型，每种网络类型对应一个Type Driver；
  • Mechanism Driver：对接各种二层网络技术和物理交换设备，如OVS，Linux Bridge等。Mechanism Driver从Type Driver获取相关的底层网络信息，确保对应的底层技术能够根据这些信息正确配置二层网络。

• 通过Type Driver和Mechanism Driver调用不同的底层网络技术，实现二层互通

Neutron组件-Service Plugin

​ Service Plugin用于实现高阶网络服务，例如路由、负载均衡、防火墙和VPN服务等

​ L3 Service Plugin主要提供路由，浮动IP服务等。

Neutron组件-Agent

​ Neutron Agent向虚拟机提供二层和三层的网络连接、完成虚拟网络和物理网络之间的转换、提供扩展服务等

5. Neutron 典型操作及流程

Neutron操作——常用命令，

例如：

• neutron net-create，创建网络；
• neutron net-list，查看网络列表信息；
• neutron subnet-list，查看子网列表信息
• neutron agent-list ，查看代理列表信息
• neutron port-create，创建端口；
• neutron router-interface-add，添加路由器接口等。

6. Neutron 网络流量分析

6.1 Linux Bridge + Flat/VLAN 网络

Neutron网络典型场景介绍

• Neutron支持多种多样的网络技术和类型，可以自由组合各种网络模型

• 如下两种网络模型是OpenStack生产环境中常用的：

  • Linux Bridge + Flat/VLAN网络
    • 仅提供简单的网络互通，虚拟网络、路由、负载均衡等由物理设备提供
    • 网络简单、高效，适合中小企业私有云网络场景
  • Open vSwitch + VXLAN网络
    • 提供多租户、大规模网络隔离能力，适合大规模私有云和公有云网络场景

Linux Bridge + Flat网络

Linux Bridge + VLAN网络

6.2 Open vSwitch + VXLAN 网络

第八章 编排管理

1. Heat 简介

Heat编排服务，使OpenStack智能化

Heat在OpenStack中的定位

Heat是OpenStack编排服务之一，负责云应用程序基础设施资源的编排

Heat提供一个OpenStack原生的REST API与一个与AWS CloudFormation兼容的查询API

Heat作用

​ Heat是一种通过OpenStack原生REST API使用声明性模板格式编排复合云应用程序的服务，提供与其他OpenStack核心项目的紧密集成

​ Heat模板以文本文件的形式描述了云应用程序的基础架构，文本文件可供用户读写，并且支持通过版本控制工具进行管理

​ Heat模板指定资源之间的关系，使得Heat能够调用OpenStack API以正确的顺序创建用户所需的基础架构，从而完全启动用户的应用程序

Heat与其他服务的交互关系

​ Heat是位于Nova、Neutron等服务之上的一个组件，它充当了OpenStack对外接口的角色，用户不需要直接接触OpenStack其他服务，只需把对各种资源的需求写在Heat模版里，Heat就会自动调用相关服务的接口来配置资源，从而满足用户的需求。

2. Heat 架构

2.1Heat 架构

• 用户在Horizon中或者命令行中提交包含模板和参数输入的请求，Horizon或者命令行工具会把请求转化为REST格式的API调用，然后调用Heat-api或者是Heat-api-cfn。Heat-api 和Heat-api-cfn会验证模板的正确性，然后通过消息队列传递给Heat Engine来处理请求。

• Heat中的模板是OpenStack资源的集合（虚拟机、网络、存储、告警、浮动IP、安全组、伸缩组、嵌套stack等），通过定义模板，可以将需要创建的资源在模板中描述，用此模板可以多次创建需要的资源。

2.2 Heat 组件

• Heat-api：提供REST API服务，是其他组件与Heat交互的入口，接收API请求并传送给heat-engine。

• Heat-api-cfn：提供兼容AWS CloudFormation的API，接收API请求并转发给heat-engine。

• Heat-engine：Heat的核心，主要实现任务调度、资源生命周期管理等作用，自身并不提供资源创建功能，只负责编排资源后交由其他组件去处理。

2.3 Heat Engine 架构

• Heat Engine在这里的作用分为三层：
  • 第一层处理Heat层面的请求，就是根据模板和输入参数来创建Stack（包含各种资源的集合）。
  • 第二层解析Stack里各种资源的依赖关系，Stack和嵌套Stack的关系。
  • 第三层客户端就是根据解析出来的关系，依次调用各种服务客户段来创建各种资源。

2.4 Heat模板

​ Template：模板是OpenStack资源的集合（虚拟机、网络、存储、告警、浮动IP、安全组、伸缩组、嵌套stack等），通过定义模板，在模板中描述需要创建的资源，使用模板可以多次创建需要的资源。

Heat模板默认编写语言-YAML

YAML Ain't Markup Language

​ 使用缩进（一个或多个空格）排版

​ 序列项用短划线表示

​ MAP中的key-value对用冒号表示

HOT模板-结构

HOT模板-Resource

resource ID

• 资源ID，在模板的resources部分中必须是唯一的。

type

• 资源类型，例如OS::Nova::Server或OS::Neutron::Port，必选属性。

properties

• 特定于资源的属性列表。可以在适当的位置或通过函数提供属性值，可选属性。

metadata

• 特定于资源的元数据。此部分是可选的。

depends_on

• 资源依赖模板中的一个或多个资源上，可选属性。

update_policy

• 以嵌套字典的形式更新资源的策略，可选属性。

deletion_policy

• 删除资源的策略。允许的删除策略是Delete，Retain和Snapshot。该属性是可选的，默认策略是从Stack中删除资源时删除物理资源。

external_id

• 允许为现有外部（到堆栈）资源指定resource_id，可选属性。

Condition

• 资源的条件，决定是否创建资源，可选属性。

• Newton版本开始支持。

HOT模板-查询Resource Type

​ Heat中支持的资源非常多，当进行资源定义时，可以使用命令查询资源所需的参数及类型

• 查找需要创建的资源

  $ openstack orchestration resource type list
  

• 列出资源详情

  $ openstack orchestration resource type show NAME(OS::Nova::Server)
  

Heat Stack

​ Stack：资源的集合，管理一组资源的基本单位， 用户操作的最小单位

​ 通过对Stack的生命周期管理，进而完成应用的部署和对资源的管理

• Stack示例：

• $ openstack stack create --template server_console.yaml  --parameter "image=ubuntu" STACK_NAME 
  

Heat Stack常用命令

stack list

stack create

stack show

stack delete

stack output list

stack resource list

stack event show

3. Heat 典型编排场景

3.1 Heat编排场景

Heat从多方位支持对资源进行设计和编排：

​ 基础架构资源编排：对计算、存储和网络等基础资源进行编排，支持用户自定义脚本配置虚拟机

​ 应用资源编排：实现对虚拟机的复杂配置，例如安装软件、配置软件

​ 高级功能编排：例如应用的负载均衡和自动伸缩

​ 第三方工具集成编排：例如复用用户环境中现有的Ansible Playbook配置，节省配置时间

3.2 Heat对基础架构资源的编排

对于不同的OpenStack资源，Heat提供了不同的资源类型

• 例如虚拟机，Heat提供了OS::Nova::Server，并提供一些参数（key、image、flavor等），参数可以直接在模板中直接指定，也可以在创建Stack时提供

使用模板创建资源

• $ openstack stack create -template server_console.yaml  --parameter “image=ubuntu” STACK_NAME
  

3.3 Heat对软件配置和部署的编排

​ Heat 提供了多种资源类型来支持对于软件配置和部署的编排，其中最常用的是

OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment

Heat提供了多种资源类型来支持对于软件配置和部署的编排，例如：

• OS::Heat::CloudConfig： VM引导程序启动时的配置，由OS::Nova::Server引用。

• OS::Heat::SoftwareConfig：描述软件配置。

• OS::Heat::SoftwareDeployment：执行软件部署。

• OS::Heat::SoftwareDeploymentGroup：对一组VM执行软件部署。

• OS::Heat::SoftwareComponent：针对软件的不同生命周期部分，对应描述软件配置。

• OS::Heat::StructuredConfig：和OS::Heat::SoftwareConfig类似，但是用Map来表述配置。

• OS::Heat::StructuredDeployment：执行OS::Heat::StructuredConfig对应的配置。

• OS::Heat::StructuredDeploymentsGroup：对一组VM执行OS::Heat::StructuredConfig对应的配置。

3.4 Heat对资源自动伸缩的编排

​ Heat提供自动伸缩组和伸缩策略，结合Ceilometer可以实现根据各种条件，比如负载，进行资源自动伸缩的功能

3.5 Heat负载均衡的编排

Heat提供自动负载均衡编排，由一组不同的资源类型来实现

负载均衡也是一个很高级应用，它也是由一组不同的资源类型来实现的。资源类型包括：

• OS::Neutron::Pool：定义资源池，一般可以由VM组成。

• OS::Neutron::PoolMember：定义资源池的成员。

• OS::Neutron::HealthMonitor：定义健康监视器，根据自定的协议，比如TCP来监控资源的状态，并提供给OS::Neutron::Pool来调整请求分发。

• OS::Neutron::LoadBalancer：关联资源池以定义整个负载均衡。

3.6 Heat和配置管理工具集成

​ Heat在基于OS::Heat::SoftwareConfig 和 OS::Heat::SoftwareDeployment 的协同使用上，提供了对Chef、Puppet和 Ansible等流行配置管理工具的支持

第九章 计量管理

1. Ceilometer 简介

计量服务Ceilometer

Ceilometer在OpenStack中的定位

​ Ceilometer是OpenStack监控服务之一，负责计量与监控

​ Ceilometer项目提供一个基础设施来收集有关OpenStack项目所需的任何信息

Ceilometer发展与衍生

• 如图所示，Ceilometer处于Telemetry项目中的核心位置，Telemetry项目的源头就是Ceilometer

• 其他项目的功能是从Ceilometer中剥离出来或者为了改进Ceilometer的不足而后续开发的

• Telemetry项目包含以下子项目：

  • Aodh：是从Ceilometer中剥离而来的，是一种警报服务，可以在用户定义的规则被破坏时发送警报。
  • Panko：是从Ceilometer中剥离而来的，是一个事件存储项目，用来保存事件Event信息。
  • Ceilometer：Telemetry项目的源头，提供一个获取和保存各类使用数据的统一框架。
  • Gnocchi：为了解决Ceilometer项目原先在数据存储端的一些设计上的性能弊病，用来保存基于时间序列的数据，并对其提供索引服务。

2. Ceilometer 架构

Ceilometer整体架构

• Ceilometer采用了高度可扩展的设计思想，开发者可以按需开发扩展组件来扩展其功能。

• Ceilometer提供Polling Agent和Notification Agent两项核心服务，支持水平扩展。

  • Polling Agent：用于轮询OpenStack服务和构建Meters的守护进程。
  • Notification Agent：用于监听消息队列上的通知，将它们转换为事件和样本，并应用管道操作的守护进程。

Ceilometer工作流程

• 方式一：第三方的数据发送者把数据以通知消息（Notification Message）的形式发送到消息总线（Notification Bus）上，Notification Agent会获取这些通知事件，并从中提取测量数据。

• 方式二：Polling Agent会根据配置定期、主动地通过各种API或其他通信协议去远端或本地的不同服务实体中获取所需要的测量数据。

• Ceilometer支持发布到多个目的地：

  • 通过Gnocchi API发送给Gnocchi，实现数据保存；
  • 发布通知到消息队列以供外部系统使用；
  • 发送到Prometheus；
  • 发送到Zaqar（一种面向 Web 和移动开发人员的多租户云消息传递和通知服务）；
  • 存储到一个文件中。

3. Ceilometer 数据管理

Ceilometer-数据收集

Ceilometer项目创建了2种收集数据的方法：

• 第三方的数据发送者把数据以通知消息（Notification Message）的形式发送到消息总线（Notification Bus）上，Notification Agent会获取这些通知事件，并从中提取测量数据。
• 轮询代理（Polling Agent）会根据配置定期、主动地通过各种API或其他通信协议去远端或本地的不同服务实体中获取所需要的测量数据。

数据收集-轮询代理：请求数据

​ 轮询代理（Polling Agent），根据配置定期、主动地通过各种API或者其他通信协议去OpenStack本地服务中或者远端获取所需要的测量数据，然后发送至Notification bus。再由通知代理（Notification Agent）接收总线上生成的消息，并将它们转换为Ceilometer样本或事件。

数据收集-通知代理：监听数据

• 通知代理（Notification Agent）：监听数据，通知守护进程（agent-notification），由它监视消息队列中其他OpenStack组件（如Nova、Glance、Cinder、Neutron、Swift、Keystone和Heat）发送的数据，以及Ceilometer内部通信。

• 通知守护进程使用命名空间加载一个或多个侦听器插件（ceilometer.notification）。每个插件都可以收听任何主题，侦听器从配置的主题中获取消息，并将它们重新分发到适当的插件以处理成事件和样本。

Ceilometer-数据处理

Ceilometer-数据存储/访问

Ceilometer-告警数据处理

• Aodh主要由以下几种服务构成，每种服务都支持水平扩展。

  • API：主要提供面向用户的RESTful API接口服务。
  • Alarm Evaluator：用来周期性地检查除event类型之外的其他警告器（Alarm）的相关报警条件是否满足。
  • Alarm Listener：根据消息总线（Notification Bus）上面的event事件消息，检查相应的event类型的警告器（Alarm）的报警条件是否满足。
  • Alarm Notifier：当警告器的报警条件满足时，执行用户定义的动作。

• 用户在新建或者修改警告器时，都可以为其设置不同的报警动作。当Alarm Evaluator周期性地检查警告器状态时，或者当Alarm Listener接收到相关的Event事件并进行检查后，如果发现当前警告器状态有对应的报警动作，它就会通过Alarm Notifier服务来调用相应的报警动作。

标签：总结,虚拟机,Nova,Heat,Keystone,OpenStack,HCIP,Neutron
From： https://www.cnblogs.com/acodemonkey/p/17654430.html