Opnestack学习笔记

Opnestack

openstack简介

openstack是什么

是虚拟机、裸金属、容器的云基架构。可以控制整个数据中心的大型计算、存储、网络功能，所有的资源通过具有身份验证机制的API进行管理和配置。（通过web和cli进行管理。）

openstack可以做什么

作为一个开源的云计算管理平台（主要是管理），openstack由几个主要的组件来完成具体的工作。openstack几乎支持所有类型的云环境，目标是提供实施简单、可扩展、丰富、标准统一的云计算管理平台，openstack通过各种互补的服务提供了基础设施及服务的（Iaas）的解决方案，每个服务提供API以进行集成。

openstack工作原理

1、openstack实际上由一系列脚本的命令组成。脚本会被捆绑在名为项目的软件包中，这些软件包用于创建云环境，并且还会使用虚拟化软件（用于创建从硬件抽象出来的虚拟化资源层）和基础操作系统（用于执行openstack脚本的中命令）。
2、openstack本身不会虚拟化资源，但会使用虚拟化资源构建云，openstack、虚拟化和基础操作系统这三种技术共同工作服务用户。

openstack设计理念

1、开放
开源
2、灵活
架构可裁剪，可以根据需要安装组件
大量使用插件化方式实现架构
3、可扩展
有多个互相独立的项目组成，每个项目包含多个组件。（无中心–避免单点故障，无状态–无本地化数据所有持久化数据都保存在数据库中，松耦合–组件间通过REST API通信，组件内消息总线通信）

openstack与虚拟化的区别

penStack优先关注控制面，OpenStack优先考虑如何将计算、存储、网络领域的各类资源抽象为资源池。在此基础上，对资源池内的各类逻辑对象实施控制操作，并将控制操作包装成面向用户的服务。数据面、管理面目前不是OpenStack的重点关注内容
openstack不是虚拟化，虚拟化是openstack底层的技术实现手段之一，但非核心关注点。

openstack与云计算

openstack是框架，以openstack为框架，将计算、存储、网络、管理、运营、运维等多个领域的软硬件产品整合在一起。

openstack架构

每个OpenStack服务内部是由多个进程组成。所有服务（Keystone除外）都至少有一个API进程，负责监听API请求，对请求进行预处理并将它们传递给服务的其他部分

用户可以通过Web用户界面、命令行客户端以及通过浏览器插件或curl等工具发出API请求来访问OpenStack

Horizon 界面管理服务

提供基于Web的控制界面，使云管理员和用户能够管理各种OpenStack资源和服务

依赖Keystone认证服务Horizon​可以与其他服务结合使用，例如镜像服务，计算服务和网络服务
Horizon​​还可以在有独立服务（如对象存储）的环境中使用

Horizon属于全局组件之一，提供一个Web管理界面，与OpenStack其他服务交互
管理员与用户可以通过Horizon实现资源的管理、实例的生命周期管理以及连接插件等

Horizon是OpenStack的一个子项目，用于提供一个web前端控制台（称为Dashboard），以此来展示OpenStack的功能。通常情况下，我们都是从Horizon、Dashboard开始来了解OpenStack。实际上，Horizon并不会为OpenStack添加任何一个新的功能，它只是使用了OpenStack部分API功能，因此，我们可以扩展Horizon的功能，扩展Dashboard。

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

Horizon核心价值

核心支持：对所有核心OpenStack项目提供开箱即用的支持。
可扩展性：每个开发者都能增加组件。
易于管理：架构和代码易于管理，浏览方便。
视图一致：始终保持视觉和交互范式一致性。
易于使用：用户界面友好，提供人们想要使用的强大界面。
可兼容性：API强调向后兼容性。

Horizon体系结构

计量服务Ceilometer

Ceilometer项目是一项数据收集服务，提供跨当前OpenStack核心组件规范化和转换数据的能力
Ceilometer的数据可为所有OpenStack核心组件提供客户计费、资源跟踪和警报功能
基于Django的Horizon体系结构如图，底层API模块openstack_dashboard.api将OpenStack其他项目的API封装起来以供Horizon其他模块调用。
该API模块只提供了其他项目API的一个子集。
Horizon将页面上的所有元素模块化，并将表单、表格等一些网页中的常见元素全部封装成Python类，如上图所示的View模块。每个这样的组件都有自己对应的HTML模板，在渲染整个页面时，Horizon会先找到当前页面包含多少组件，并将各个组件分别渲染成一段HTML片段，最后将它们拼接成一个完整的HTML页面返回给浏览器。
Horizon面板设计分为3层：Dashboard -> PanelGroup -> Panel

OpenStack Horizon界面-项目

如图所示，整个页面主要由各个Dashboard、PanelGroup、Panel，以及单击Panel后渲染的页面组成。
如图所示，当前的Dashboard是“项目”，PanelGroup是“项目”下的“计算”，Panel是“计算”下的“概况”。右侧区域就是单击Panel“概况”渲染的页面部分。
项目是云中的组织单位，也称为租户。每个用户都是一个或多个项目的成员。在项目中，用户创建和管理实例。
在项目界面，用户可以查看和管理选定项目中的资源，包括实例、镜像、密钥对和主机组。
身份管理界面提供认证管理功能。

认证服务Keystone

提供身份验证，服务发现和分布式多租户授权
支持LDAP、Oauth、OpenID Connect、SAML和SQL
OpenStack Identity，代号为Keystone，是OpenStack默认的身份管理系统

Keystone基本概念

Domain：一个域可以对应一个大的机构、一个数据中心，并且必须全局唯一。云的终端用户可以在自己的Domain中创建多个Project、User、Group和Role。具备对多个Project进行统一管理的能力。
User：Keystone会通过认证信息（Credential，如密码等）验证用户请求的合法性，通过验证的用户将会分配到一个特定的令牌，该令牌可以被当作后续资源访问的一个通行证，并非全局唯一，只需要在域内唯一即可。
Group：用户组是一组User的容器，可以向Group中添加用户，并直接给Group分配角色，在这个Group中的所有用户就拥有了Group所拥有的角色权限。通过引入Group的概念，Keystone实现了对用户组的管理，达到了同时管理一组用户权限的目的。
Project：项目是各个服务中的一些可以访问的资源集合。我们需要在创建虚拟机时指定某个项目，在Cinder创建卷时也需要指定具体的项目。用户总是被默认绑定到某些项目上，在用户访问项目的资源前，必须具有对该项目的访问权限，或者说在特定项目下被赋予了特定的角色。项目不必全局唯一，只需要在某个域下唯一即可。
Role：一个用户所具有的角色，角色不同意味着被赋予的权限不同，只有知道用户被赋予的角色才能知道该用户是否有权限访问某资源。用户可以被赋予一个域或项目内的角色。一个用户被赋予域的角色意味着他对域内所有的项目都具有相同的角色，而特定项目的角色只具有对特定项目的访问权限。角色可以被继承，在一个项目树下，拥有父项目的访问权限也意味着同时拥有对子项目的访问权限。角色必须全局唯一。

Keystone在OpenStack中的作用

Keystone作为OpenStack中一个独立的提供安全认证的模块，主要负责OpenStack用户的身份认证、令牌管理、提供访问资源的服务目录，以及基于用户角色的访问控制。
用户访问系统的用户名和密码是否正确，令牌的发放，服务端点的注册，以及该用户是否具有访问特定资源的权限等都离不开Keystone服务的参与。
Identity：身份服务，提供身份验证凭证及有关用户和用户组数据。
Token：令牌，Keystone在确认用户的身份后，会给用户提供一个核实身份且可以用于后续资源请求的令牌。
Catalog：对外提供一个服务的查询目录，服务目录存储了OpenStack所有服务的Endpoint信息。
Policy：安全策略或者访问控制，一个基于规则的身份验证引擎，通过配置文件来定义各种动作与用户角色的匹配关系。
Resource：提供关于Domain和Project的数据。
Assignment：提供关于Role和Role Assignment的数据，负责角色授权。

Keystone与其他服务的交互关系

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

Keystone架构

Keystone Middleware是Keystone提供的对令牌合法性进行验证的中间件。
比如，在客户端访问Keystone提供的资源时提供了PKI类型的令牌，为了不必每次都通过Keystone服务的直接介入来验证令牌的合法性，通常可以在中间件上进行验证，前提是中间件上已经缓存了相关的证书与密钥以对令牌进行签名认证。
如果不是PKI类型的令牌，则需要通过keystoneauth获得一个与Keystone服务连接的session，并通过调用Keystone服务提供的API来验证令牌的合法性。
对于Keystone项目本身，除了后台的数据库，主要包括一个处理RESTful请求的API服务进程。这些API涵盖了Identity、Token、Catalog和Policy等Keystone提供的各种服务，这些不同服务所能提供的功能则分别由相应的后端Driver（Backend Driver）实现。

Keystone各组件作用

Keystone对象模型

Keystone的管理主要是针对Identity、Resource、Assignment、Token、Catalog、Service，这些对象具体由其他更小的对象实现。
同时OpenStack各种资源和服务的访问策略由Policy定义。

Keystone对象模型-Service

Keystone对象模型-Identity

Keystone对象模型-Resource

项目本身必须属于某个特定域。所有项目名不是OpenStack全局唯一的，仅在其所属域唯一。
创建项目时如果未指定域，则将其添加到默认域。

Keystone对象模型-Assignment

Keystone对象模型-Token

Keystone对象模型-Catalog

用户与OpenStack中的服务可以通过Catalog来获取其他服务的Endpoint，这些Endpoint是服务通过Keystone进行注册时由Keystone进行维护的，Catalog就是Endpoint的一个集合，提供用于查询端点（Endpoint）的端点注册表，以便外部访问OpenStack服务。
Endpoint本质上是一个URL，提供一个服务的入口，每个服务可以有一个或多个Endpoint，通过认证的外部请求，如果需要访问某个服务，只需要知道服务的Endpoint即可。如图所示，是一个catalog目录下显示的端点，服务名Keystone，类型是Identity，提供访问端点入口是Public，用户可以直接访问。
Endpoint分为Admin、Internal和Public，这些不同类型的Endpoint分别开放给不同的用户或服务。例如，对于Public URL，一般会对所有用户开放，允许用户通过外部网络进行访问，通常是在公共网络接口上使用；Admin URL会对一些用户或URL进行限定，只允许具有特定操作权限的用户访问，通常只提供给有管理权限的用户使用，是在安全的网络接口上使用的；Internal URL限定于那些安装有OpenStack的主机才可以访问，一般是内部组件互通，通常在未计量的内部网络接口上使用。

Keystone对象模型-Policy

Keystone对象模型分配关系示例（一）

Keystone对象模型分配关系示例（二）

Keystone的Catalog中包含不同Region中的不同Service（Keystone的服务），每个Service一般提供不同类型的Endpoint。
用户和Keystone中的服务，在交互过程中主要做了些什么呢，普通User主要使用Keystone来验证身份，获取相应的身份凭证Token，还可以获取需要访问使用的Service Catalog。Admin User的权限比较高，一般情况只用于管理操作。它主要可以管理Keystone中的Users、Projects、Roles，管理特定Project中用户的角色，管理不同的Services和Services中的Endpoint等。最后Keystone中的服务为用户验证Token的有效性，定位其他Service的位置并提供位置Endpoint给用户，也可以调用其他Service。

OpenStack创建VM，服务间交互示例

Keystone对象模型使用示例

Keystone认证方式概览

OpenStack认证流程-以创建VM为例

我们以创建VM为例，站在整个OpenStack角度来看一下，整个认证流程是怎样的。
首先用户需要使用OpenStack，第一步就要向Keystone提供用户名密码来获取Token。当用户获取Token后，需要向Nova发送创建虚拟机请求，Nova负责调用计算资源并管理虚拟机的生命周期，所以这个创建请求要发送到Nova。请求的Head中会携带Token，当Nova-api接收到请求后，会将Token传递到Keystone进行验证是否有效合法。当验证成功后返回信息给Nova，Nova才开始进行创建VM操作。这边不具体介绍Nova如何操作，但是我们知道创建一台虚拟机，不仅需要准备CPU、内存等计算资源，还要有相应的网络、存储等资源，这里以网络资源为例，Nova-api将token透传给Nova-compute，Nova-compute会向Neutron-server发送与网络相关操作请求，请求Head中也携带Token，Neutron收到请求后也会将Token传递到Keystone验证，验证成功才执行相应操作。
这个流程中我们可以看到，不同服务间的调用也要携带Token，并且Keystone只校验了Token的有效性，那么每个服务的操作权限控制是怎么实现的呢？

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

在OpenStack中使用RBAC进行访问控制，RBAC是基于角色访问控制（Role-Based Access Control），在RBAC中，权限与角色相关连，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理，这样管理都是层级相互依赖的，权限直接赋予给角色，而把角色又赋予给用户，这样的权限设计很清楚，管理起来也很方便。RBAC认为授权实际上是Who/What/How三元组之间的关系，Who是权限的拥有或者主体，例如User，Role。What是操作或对象，如Operation，Object。How是具体的权限，授权，Privilege。所以组合到一起就是Who对What进行了How操作。如图所示，首先客户发送请求，由Keystone的Token模块进行Token有效性认证，认证通过后，由Policy模块来验证Auth context，即认证上下文，实际上Policy.json文件是实现RBAC的关键机制，之前我们在介绍Policy的时候也提到过，该文件一般存于组件的配置目录下，该文件在修改后立即生效，不需要重启服务。整个验证过程如果成功，进行下一步反馈信息。如果失败直接反馈403禁止，表示权限认证失败。

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

Policy模块在检测时需要三方面的数据，第一个是policy.json策略配置文件，保存在服务配置目录下，第二个是auth_token添加到http头部的token数据，就是前面说到的基于令牌认证中的那些令牌数据。还有用户请求数据，到底请求哪些内容。
在图中实例policy.json文件中，定义了all_admin包含了哪些角色，admin和internal_admin。定义了list_project针对all_admin的具体规则，create project时需要admin角色。
在处理的过程中，验证Token有效性，根据用户的请求信息到policy.json策略配置文件验证其用户是否有对应角色和权限。

总结： Keystone如何实现认证和权限控制？

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

镜像服务Glance

提供发现、注册和检索虚拟机镜像功能,提供的虚拟机实例镜像可以存放在不同地方，例如本地文件系统、Swift对象存储、Cinder块存储等

依赖Keystone认证服务
通过Nova模块创建虚拟机实例，Nova调用Glance模块提供的镜像服务
Glance提供的镜像可以通过Swift对象存储机制进行保存

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

Glance在OpenStack中的作用

Glance架构

Glance各组件作用（一）

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各组件作用（二）

Glance DB：Glance服务Database Abstraction Layer (DAL) -数据库抽象层。
使用一个核心库Glance DB，该库对Glance内部所有依赖数据库的组件来说是共享的。
Glance Store：用来组织处理Glance和各种存储后端的交互。所有的镜像文件操作都是通过调用Glance Store库执行的，它负责与外部存储端或本地文件系统的交互。Glance Store提供了一个统一的接口来访问后端存储。

Glance架构简化

在Newton之前的版本中，Glance支持REST API V1和V2。
在V2 API版本中，Glance-Registry的内容被整合进了Glance-API。如果Glance-API接收到与镜像元数据有关的请求，则会直接操作数据库，不需要再通过Glance-Registry。
在V1 API版本中，Glance-Registry与Glance-API一样，也是一个WSGI Server，但是Glance-Registry处理的是与镜像元数据相关的RESTful请求。Glance-API在接收到用户的RESTful请求后，如果该请求与元数据相关，则将其转发给Glance-Registry。需要注意的是，Glance-Registry提供的REST API是给Glance-API使用的 ，不对OpenStack外部用户暴露。
在Newton版本中V1已经过时，并从Stein版本开始，Glance-Registry被废弃，由Glance-API代替，然后通过Store模块的接口实现对各种不同后台存储系统的支持，包括Glance架构图中的Amazon S3、Cinder/Swift、Ceph、Sheepdog等存储后端。

WSGI：Web Server Gateway Interface，Web服务网关接口，是Python应用程序或框架和Web服务器之间的一种接口。

OpenStack中的镜像、实例和规格

Glance镜像磁盘格式

其他镜像，可以先转换成OpenStack支持的格式，再导入使用。

容器格式是指虚拟机镜像是否采用还包含有关实际虚拟机的元数据的文件格式。
需要注意的是：容器格式字符串在当前并不会被glance或其他OpenStack组件使用，所以如果你不确定，将容器格式指定为bare是安全的。

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还没有清除镜像数据，只是处于该状态的镜像不可恢复。

镜像与实例交互流程-实例从镜像启动

启动实例时，需要选择一个镜像，规格和任何可选属性。选定的规格提供一个系统盘，标记为vda，另外一个临时盘被标记为vdb，cinder-volume提供的卷被映射到第三个虚拟磁盘并将其称为vdc。
镜像服务将基本镜像从镜像存储复制到本地磁盘。vda是实例访问的第一个磁盘。如果镜像文件越小，则通过网络复制的数据越少，实例启动就会越快。
实例启动时还会创建一块空的临时磁盘vdb，删除实例时将删除此磁盘。
计算节点使用iSCSI 连接到cinder-volume提供的某个卷。该卷被映射到第三个磁盘vdc。计算节点为实例提供vCPU和内存资源后，实例将从根卷vda启动。该实例运行并更改磁盘上的数据（图中红色标示磁盘）。
如果cinder-volume位于单独的网络上，则存储节点配置文件中my_block_storage_ip选项会将镜像流量定向到计算节点。
注意：
此示例场景中的某些详细信息可能与实际环境不同。例如，可以使用不同类型的后端存储或不同的网络协议。常见的一种场景是vda，vdb存放在SAN存储，而不是本地磁盘上。
实例被删除后, 除cinder-volume卷之外的其他资源都会被回收。临时磁盘无论是否加密过，都将会被清空，内存和vCPU资源将会被释放。在这个过程中镜像不会发生任何改变。
注意：
如果创建实例时选择了“删除实例时删除卷”，则实例删除时，cinder-volume卷也会被删除。

Glance镜像制作-直接下载镜像文件

镜像的具体下载链接，请参考OpenStack社区网站：
https://docs.openstack.org/image-guide/obtain-images.html。

Glance镜像制作-手动制作镜像

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

Glance镜像制作-常用工具

Glance镜像制作-镜像转换

$ qemu-img convert -f raw -O qcow2 image.img image.qcow2 （image.img是原镜像文件名 image.qcow2是转换后的 ）

计算服务Nova

提供大规模、可扩展、按需自助服务的计算资源
支持管理裸机（裸金属 BMS），虚拟机和容器

依赖Keystone认证服务、Neutron网络服务和Glance镜像服务
通过Nova模块创建计算实例，Nova调用Glance模块提供的镜像服务
通过Nova模块创建的计算实例启动时，连接到的虚拟或物理网络由Neutron负责

Nova即OpenStack Compute service，负责提供计算资源的模块，也是OpenStack中的核心模块
Nova不包括虚拟化软件，Nova定义与底层虚拟化机制交互的驱动程序，并通过基于Web的API公开功能
Nova属于计算服务层，用户可以使用Horizon、Nova客户端、API或者CLI直接创建和管理计算实例。

Nova的使命与作用

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消息的管理器。

Nova物理部署实例

Nova服务运行架构

Nova资源池管理架构

包含关系
Region > Availability Zone > Host Aggregate。

Nova组件-API

Nova组件-Conductor

引入nova-conductor的好处：
安全性上考虑。之前每个nova-compute都是直接访问数据库的。如果由于某种原因，某个计算节点被攻陷了，那攻击者就可以获取访问数据库的全部权限，肆意操作数据库。
方便升级。将数据库和nova-compute解耦，如果数据库的模式改变，nova-compute就不用升级了。
性能上考虑。之前数据库的访问在nova-compute中直接访问且数据库访问是阻塞性的，由于nova-compute只有一个os线程，所以当一个绿色线程去访问数据库的时候会阻塞其他绿色线程，导致绿色线程无法并发。但是nova-conductor是通过rpc 调用，rpc调用是绿色线程友好的，一个rpc call的执行返回前不会阻塞其他绿色线程的执行。这样就会提高了操作的并发。

Nova组件-Scheduler

Nova-Scheduler：确定将虚拟机分配到哪一台物理机，分配过程主要分为两步，过滤和权重；用户创建虚拟机时会提出资源需求，例如CPU、内存、磁盘各需要多少，OpenStack将这些需求定义在flavor中，用户只需要指定flavor就可以了。
调度过程分为两步：
通过过滤器选择满足条件的计算节点；
通过权重选择最优的节点。

Nova组件-Compute

虚拟机生命周期操作的真正执行者（会调用对应的hypervisor的driver）。
底层对接不同虚拟化的平台（KVM/VMware/XEN/Ironic等）。
内置周期性任务，完成资源刷新，虚拟机状态同步等功能。
资源管理模块（resource_tracker）配合插件机制，完成资源的统计。

虚拟机状态介绍

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的信息调用配置的虚拟化驱动来创建虚拟机。

Nova过滤调度器

其他------
迁移成功后会清除源节点的信息。
迁移失败后会回滚，清除目标节点的信息。

Nova典型操作

Nova主要操作对象（一）

OpenStack存储管理

OpenStack存储类型

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

OpenStack存储类型对比

OpenStack持久存储简介

块存储服务Cinder

提供块存储服务，为虚拟机实例提供持久化存储
调用不同存储接口驱动，将存储设备转化成块存储池，用户无需了解存储实际部署位置或设备类型

依赖Keystone认证服务
Cinder是OpenStack 块存储服务，为Nova虚拟机、Ironic裸机、容器提供卷
Cinder为后端不同的存储设备提供了统一的接口，不同的块设备服务厂商在Cinder中实现其驱动，使其可以被OpenStack整合管理

cinder的前身是nova中的nova-volume组件，后来才被单独提出来成为一个OpenStack组件，因此cinder的设计架构和nova十分相像，具体体现在它们各个子组件的功能基本都能对应。

Cinder作用

Cinder在虚拟机与具体存储设备之间引入了一层“逻辑存储卷”的抽象，Cinder本身不是一种存储技术，并没有实现对块设备的实际管理和服务
Cinder提供了一个中间的抽象层，为不同的存储技术，如DAS、NAS、SAN、对象存储及分布式文件系统等，提供了统一的接口。
不同的块设备服务厂商在Cinder中以驱动的形式实现上述接口与OpenStack进行整合

Cinder与其他服务的交互关系

通过Nova模块创建虚拟机实例，Cinder为虚拟机实例提供持久化块存储能力
Cinder创建的卷备份支持存储到Swift

Cinder架构

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默认使用LVM（Logical Volume Manager）作为后端存储（Backend Storage），而LVM通过在操作系统与物理存储资源之间引入逻辑卷（Logical Volume）的抽象来解决传统磁盘分区管理工具的问题。
LVM将众多不同的物理存储资源（物理卷、Physical Volume，如磁盘分区）组成卷组。LVM从卷组中创建一个逻辑卷，然后将ext3、ReiserFS等文件系统安装在这个逻辑卷上。
除了LVM，目前Cinder已经以驱动的形式支持众多存储技术或存储厂商的设备作为后端存储，如SAN（Storage Area Network）、Ceph、Sheepdog，以及EMC、华为等厂商的设备。

Cinder架构部署：以SAN存储为例

注意各组件的部署、访问顺序关系。

Cinder组件-API

Cinder组件-Scheduler

根据后端的能力进行筛选：
Drivers定期报告后端的能力和状态。
管理员创建的卷类型（volume type ）。
创建卷时，用户指定卷类型。

Cinder组件-Volume

Cinder创建卷流程

创建卷类型的目的是为了筛选不同的后端存储，例如SSD、SATA、高性能、低性能等，通过创建不同的自定义卷类型，创建卷时自动筛选出合适的后端存储。

Cinder挂载卷流程

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来实现虚拟机挂载磁盘。

Cinder主要操作

对象存储服务Swift

提供高度可用、分布式、最终一致的对象存储服务。可以高效、安全且廉价地存储大量数据。非常适合存储需要弹性扩展的非结构化数据，为其他OpenStack服务提供对象存储服务。

没有依赖服务

OpenStack Object Storage (swift) 用于冗余、可扩展的数据存储，使用标准化服务器集群来存储PB级的可访问数据。它是一种可长期检索和更新大量静态数据的存储系统。对象存储使用没有中央控制点的分布式架构，可提供更高的可扩展性、冗余性和持久性。对象被写入多个硬件设备，OpenStack软件负责确保整个集群的数据复制和完整性。存储集群通过添加新节点来水平扩展。如果一个节点发生故障，OpenStack会从其他活动节点复制其内容。因为OpenStack使用软件逻辑来确保跨不同设备的数据复制和分发。
对象存储是具有成本效益的横向扩展存储的理想选择。它提供了一个完全分布式的、API可访问的存储平台，可以直接集成到应用程序中或用于备份、归档和数据保留。

Swift在OpenStack中的定位

Swift是OpenStack对象存储服务，可以存储虚拟机实例创建所需的镜像
Swift作为OpenStack持久存储之一，比较适合存放静态数据

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

Swift在OpenStack中的作用

Swift经常用于存储镜像或用于存储虚拟机实例卷的备份副本。
与其他OpenStack项目一样，Swift提供了RESTful API作为访问的入口，存储的每个对象都是一个RESTful资源，并且拥有一个唯一的URL。
我们既可以发送HTTP请求将一些数据作为一个对象传递给Swift，也可以从Swift中请求一个之前存储的对象。

Swift特点

极高的数据持久性
从理论上测算过，Swift在5个Zone、5×10个存储节点的环境下，数据复制份是为3，数据持久性的SLA能达到10个9。
完全对称的系统架构
“对称”意味着Swift中各节点可以完全对等，能极大地降低系统维护成本。
无限的可扩展性
这里的扩展性分两方面，一是数据存储容量无限可扩展；二是Swift性能（如QPS、吞吐量等）可线性提升。因为Swift是完全对称的架构，扩容只需简单地新增机器，系统会自动完成数据迁移等工作，使各存储节点重新达到平衡状态。
无单点故障
在互联网业务大规模应用的场景中，存储的单点一直是个难题。例如数据库，一般的HA方法只能做主从，并且“主”一般只有一个；还有一些其他开源存储系统的实现中，元数据信息的存储一直以来是个头痛的地方，一般只能单点存储，而这个单点很容易成为瓶颈，并且一旦这个点出现差异，往往能影响到整个集群。
Swift的元数据存储是完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。整个Swift集群中，也没有一个角色是单点的，并且在架构和设计上保证无单点业务是有效的。

Swift架构

如图所示，Swift从架构上可以划分为两个层次：访问层（Access Tier）与存储层（Storage Nodes）。
访问层主要包括两部分，即Proxy Node（代理服务节点）与Authentication（认证），分别负责RESTful请求与用户身份的认证。
在Proxy Node节点上运行着Proxy Server，负责处理用户的RESTful请求，在接收到用户请求时，需要对用户的身份进行认证，此时用户所提供的身份资料会被转发给认证服务进行处理。
Proxy Server可以使用Memcached（高性能的分布式内存对象缓存系统）进行数据和对象的缓存，减少数据库读取的次数，提高用户的访问速度。
Proxy Node在收到用户的访问请求时，会将其转发到相应的存储节点上。
存储层由一系列的物理存储节点组成，负责对象数据的存储。
存储层在物理上分为以下5个层次：
Region：地理上隔绝的区域，每个Swift系统默认至少有1个Region。
Zone：在每个Region的内部又划分了不同的Zone来实现硬件上的隔绝。可以简单地将其理解为一个Zone代表了一组独立的存储节点。
Storage Node：存储对象数据的物理节点。
Device：可以简单地理解为磁盘。
Partition：仅仅指在Device上的文件系统的目录，和我们通常所理解的硬盘分区是完全不同的概念。

Swift数据模型

如图所示，每个Storage Node上存储的对象在逻辑上又分为3个层次组成：Account、Container和Object。
需要注意的是：Container不能嵌套，不能包含下级的Container；对象由元数据和内容两部分组成，Swift要求一个对象必须存储在某个Container中，因此一个Account应该至少由一个Container来提供对象的存储。
与上述3层组织结构相对应，在Storage Node上运行以下3种服务：Account Server、Container Server和Object Server。（后续Swift组件详细介绍）
使用命令swift stat可以显示Swift中的帐户、容器和对象的信息。
Swift为帐户，容器和对象分别定义了Ring（环）将虚拟节点（分区）映射到一组物理存储设备上，包括Account Ring、Container Ring 、Object Ring。
Ring记录了存储对象与物理位置的映射关系，通过Zone、Device、Partition和Replica来维护映射信息。

Swift系统架构

存储位置有如下三种：
/account
帐户存储位置是唯一命名的存储区域，其中包含帐户本身的元数据（描述性信息）以及帐户中的容器列表。
请注意，在Swift中，帐户不是用户身份。当您听到帐户时，请考虑存储区域。
/account/container
容器存储位置是帐户内的用户定义的存储区域，其中包含容器本身和容器中的对象列表的元数据。
/account/container/object
对象存储位置存储了数据对象及其元数据的位置。

Swift组件

Proxy Server可以说是Swift的核心，运行着swift-proxy-server进程。它提供Swift API服务，负责Swift其余组件间的通信。对于每个客户端的请求，它在Ring中查询相应的Account、Container以及Object的位置，并且转发这些请求。

Account Reaper：帐户清理服务，移除被标记为删除的帐户，删除其所包含的所有容器和对象。

Swift工作原理概述

Swift关键技术

空间的大小通常采用2的n次幂，便于进行高效的移位操作；然后通过独特的数据结构Ring（环）再将虚拟节点映射到实际的物理存储设备上，完成寻址过程。

OpenStack网络管理

物理网络与虚拟化网络

Neutron最为核心的工作是对二层物理网络的抽象与管理，物理服务器虚拟化后，虚拟机的网络功能由虚拟网卡（vNIC）和虚拟交换机提供，各个vNIC连接在vSwitch的端口上，最后这些vSwitch通过物理服务器的物理网卡访问外部的物理网络。

Linux网络虚拟化实现技术

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

TAP/TUN提供了一台主机内用户空间的数据传输机制。它虚拟了一套网络接口，这套接口和物理的接口无任何区别，可以配置IP，可以路由流量，不同的是，它的流量只在主机内流通。
TAP/TUN有些许的不同，TUN只操作三层的IP包，而TAP操作二层的以太网帧。
Veth-Pair是成对出现的一种虚拟网络设备，一端连接着协议栈，一端连接着彼此，数据从一端出，从另一端进。它的这个特性常常用来连接不同的虚拟网络组件，构建大规模的虚拟网络拓扑，比如连接Linux Bridge、OVS、LXC容器等。一个很常见的案例就是它被用于OpenStack Neutron，构建非常复杂的网络形态。

Linux交换机虚拟化-Linux bridge

Linux Bridge结构如上图所示，Bridge设备br0绑定了实际设备eth0与虚拟设备tap0和tap1，但是对于Hypervisor的网络协议栈上层来说，只能看到br0，并不会关心桥接的细节。
当这些设备接收到数据包时，会将其提交给br0决定数据包的去向，br0会根据MAC地址与端口的映射关系进行转发。
因为Bridge工作在二层，所以绑定在br0上的从设备eth0、tap0与tap1均不需要再设置IP地址，对于上层路由器来说，它们都位于同一子网，因此只需为br0设置IP地址。因为br0具有自己的IP地址，br0可以被加入路由表，并利用它来发送数据，但是最终实际的发送过程则是由某个从设备来完成。
即使eth0原本具有自己的IP地址，但是在被绑定到br0上后，它的IP地址会失效，用户程序不能接收到这个IP地址的数据。只有目的地址为br0的IP地址的数据包才会被Linux接收。
brctl addbr BRIDGE：表示添加BRIDGE。
brctl addif BRIDGE DEVICE：表示添加接口到bridge。

Linux交换机虚拟化-Open vSwitch

Open vSwitch负责连接vNIC与物理网卡，同时桥接同一物理Server内的各个vNIC。其实Linux Bridge已经能够很好地充当这样的角色，为什么我们还需要Open vSwitch？
因为Open vSwitch的引入使得云环境中对虚拟网络的管理及对网络状态和流量的监控变得更容易。
我们可以像配置物理交换机一样，将接入Open vSwitch的各个VM分配到不同的VLAN中以实现网络的隔离。我们也可以在Open vSwitch端口上为VM配置QoS，同时Open vSwitch也支持包括NetFlow、sFlow等很多标准的管理接口和协议，我们可以通过这些接口完成流量监控等工作。
Open vSwitch在云环境中的各种虚拟化平台（如Xen与KVM）上实现了分布式的虚拟交换机（Distributed Virtual Switch），一个物理Server上的vSwitch可以透明地与另一个物理Server上的vSwitch连接在一起。

Linux网络隔离-Network Namespace

Network Namespace通常与VRF（Virtual Routing Forwarding虚拟路由和转发）一起工作，VRF是一种IP技术，允许路由表的多个实例同时在同一路由器上共存。
使用VETH可以连接两个不同网络命名空间，使用Bridge可以连接多个不同网络命名空间。

网络服务Neutron

依赖Keystone认证服务

Neutron基于软件定义网络的思想，实现了网络虚拟化下的资源管理。Neutron的设计目标是实现网络即服务（NaaS），在设计上遵循了基于SDN实现网络虚拟化的原则，在实现上充分利用了Linux系统上的各种网络相关的技术。

OpenStack Neutron是一个SDN网络项目，专注于在虚拟计算环境中提供网络即服务（NaaS）
Neutron允许用户创建由其他OpenStack服务管理的接口设备并将其连接到网络

Neutron是一个OpenStack项目，用于在由其他OpenStack服务（例如nova）管理的接口设备（例如vNIC）之间提供“网络连接即服务”。
OpenStack Networking （neutron）允许您创建由其他OpenStack服务管理的接口设备并将其连接到网络。可以实施插件以适应不同的网络设备和软件，为OpenStack架构和部署提供灵活性。

Neutron作用

实际上，Neutron仅仅是一个管理系统/控制系统，它本身并不能实现任何网络功能，它仅仅是为Linux相关功能做一个配置或者驱动而已。本质上Neutron是借助Linux来实现网络功能的。
OpenStack所在的整个物理网络在Neutron中被泛化为网络资源池，通过对物理网络资源进行灵活的划分与管理，Neutron能够为同一物理网络上的每个租户提供独立的虚拟网络环境。
如上图所示，在Neutron网络结构中，首先应该至少有一个由管理员所创建的外部网络对象，用来负责OpenStack环境与Internet的连接，然后租户可以创建自己的私有的内部网络并在其中创建虚拟机。为了使内部网络中的虚拟机能够访问互联网，必须创建一个路由器将内部网络连接到外部网络。
Network、Subnet、Router下面会详细讲解。

Neutron与其他服务的交互关系

Neutron概念

Neutron概念-Network

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

Neutron概念-Fixed IP

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

Neutron概念-Floating IP

Neutron概念-Physical Network

Neutron概念-Provider Network

Provider Network，由OpenStack管理员创建的，直接对应于数据中心现有物理网络的一个网段。Provider Network通常使用VLAN或者Flat模式，可以在多个租户之间共享。Provider Network 是基于物理网络创建的。
Provider Network，由OpenStack管理员通过Neutron创建并用来映射一个外部网络，外部网络并不在Neutron的管理范围内，因此Provider Network的作用就是将Neutron内部的虚拟机或网络通过实现的映射与外部网络联通。

Neutron概念-Self-service Network

不同Self-service Network中的网段可以相同，类似于物理环境中不同公司的内部网络。Self-service Network如果需要和外部物理网络通信，需要通过Router，类似于物理环境中公司上网需要通过路由器或防火墙。所以这里的Self-service Network类似于我们在真实网络中常常说的私网。

Neutron概念-External Network

External Network类似于物理环境中直接使用公网IP网段，不同的是，OpenStack中External Network对应的物理网络不一定能直连Internet，有可能只是数据中心的一个内部私有网络。

Neutron概念-Security Group

在安全组中可以基于不同的协议，不同的端口号，不同的目的和源地址进行策略配置。

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

从这张Neutron Server架构图中可以总结出，Neutron Server = APIs + Plugins，API定义各类网络服务（例如subnet、port等），Plugin实现各类网络服务（例如Router、LBaaS、 FWaaS、 SecurityGroups等），通过这种方式，可以自由对接不同网络后端能力。

Neutron组件-Core Plugin

ML2= Modular Layer 2。
Core plugin 提供基础的网络功能，使用不同的drivers调用不同的底层网络实现技术。
ML2 Plugin的Drivers主要分为以下两种：
Type Driver：定义了网络类型，每种网络类型对应一个Type Driver；
Mechanism Driver：对接各种二层网络技术和物理交换设备，如OVS，Linux Bridge等。Mechanism Driver从Type Driver获取相关的底层网络信息，确保对应的底层技术能够根据这些信息正确配置二层网络。

Neutron组件-Service Plugin

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

Neutron组件-Agent

Neutron操作-常用命令

neutron net-create
neutron net-list
neutron subnet-list
neutron port-create
neutron router-interface-add
neutron agent-list

Neutron操作，例如：neutron net-create，创建网络；neutron net-list，查看网络列表信息；neutron subnet-list，查看子网列表信息；neutron agent-list ，查看代理列表信息；neutron port-create，创建端口；neutron router-interface-add，添加路由器接口等。
更多命令请大家进入动手实验-Neutron操作，大家可以先使用help命令，查看Neutron命令的具体使用方法，主要包括如何管理网络、子网、端口、路由器、浮动IP、安全组及规则、以及虚拟机实例访问测试等。

Neutron网络典型场景介绍

Flat网络类似于使用网线直接连接物理网络，OpenStack不负责网络隔离。
图中interface 2不带VLAN tag。

图中interface 2需通过多个VLAN，连接的物理交换机一般需配置trunk模式，并允许这些VLAN通过。



以下步骤涉及计算节点1：
虚拟机数据包由虚拟网卡（1）通过veth pair转发到Provider Bridge上的端口（2）
Provider Bridge上的安全组规则（3）检查防火墙和记录连接跟踪
provider Bridge上的VLAN子接口（4）将数据包转发到物理网卡（5）
物理网卡（5）将数据包打上VLAN tag 101，并将其转发到物理交换机端口（6）
以下步骤涉及物理网络设备：
交换机从数据包中删除VLAN tag 101，并将其转发到路由器（7）
路由器将数据包从Provider Network 1网关（8）路由到External网络网关（9），并将数据包转发到External网络的交换机端口（10）
交换机将数据包转发到外部网络（11）
外部网络（12）接收数据包

以下步骤涉及计算节点1：
虚拟机1数据包由虚拟网卡（1）通过veth pair转发到Provider Bridge上的端口（2）
Provider Bridge上的安全组规则（3）检查防火墙和记录连接跟踪
Provider Bridge上的VLAN子接口（4）将数据包转发到物理网卡（5）
物理网卡（5）将数据包打上VLAN tag 101，并将其转发到物理交换机端口（6）
以下步骤涉及物理网络设备：
交换机将数据包转发给计算节点2所连接的交换机端口（7）
以下步骤涉及计算节点2：
计算节点2的物理网卡（8）从数据包中删除VLAN tag 101，然后转发给Provider Bridge的VLAN子接口（9）
Provider Bridge上的安全组规则（10）检查防火墙和记录连接跟踪
Provider Bridge上的虚拟网卡（11）通过veth pair将数据包转发给虚拟机2的网卡（12）

以下步骤涉及计算节点1：
虚拟机1数据包由虚拟网卡（1）通过veth pair转发到Provider Bridge上的端口（2）
Provider Bridge上的安全组规则（3）检查防火墙和记录连接跟踪
Provider Bridge上的VLAN子接口（4）将数据包转发到物理网卡（5）
物理网卡（5）将数据包打上VLAN tag 101，并将其转发到物理交换机端口（6）
以下步骤涉及物理网络设备：
交换机从数据包中删除VLAN tag 101，并将其转发到路由器（7）
路由器将数据包从Provider Network 1网关（8）转发到Provider Network 2网关（9）
路由器将数据包发送到交换机端口（10）
交换机将数据包打上VLAN tag 102，然后转发给计算节点1连接的端口（11）
以下步骤涉及计算节点1：
计算节点1的物理网卡（12）从数据包中删除VLAN tag 102，然后转发给Provider Bridge的VLAN子接口（13）
Provider Bridge上的安全组规则（14）检查防火墙和记录连接跟踪
Provider Bridge上的虚拟网卡（15）通过veth pair将数据包转发给虚拟机2的网卡（16）

Open vSwitch + VXLAN网络

场景说明：
虚拟机运行在计算节点1上，使用Self-service network 1。
虚拟机将数据包发送到Internet上的主机。
以下步骤涉及计算节点1：
实例接口（1）通过veth对将数据包转发到安全组网桥实例端口（2）。
安全组网桥上的安全组规则（3）处理数据包的防火墙和连接跟踪。
安全组网桥OVS端口（4）通过veth对将数据包转发到OVS集成网桥安全组端口（5）。
OVS集成网桥为数据包添加内部VLAN标记。
OVS集成桥为内部隧道ID交换内部VLAN标记。
OVS集成桥接补丁端口（6）将数据包转发到OVS隧道桥接补丁端口（7）。
OVS隧道桥（8）使用VNI 101包裹分组。
用于覆盖网络的底层物理接口（9）经由覆盖网络（10）将分组转发到网络节点。
以下步骤涉及网络节点：
覆盖网络的底层物理接口（11）将分组转发到OVS隧道桥（12）。
OVS隧道网桥解包并为其添加内部隧道ID。
OVS隧道网桥为内部VLAN标记交换内部隧道ID。
OVS隧道桥接补丁端口（13）将分组转发到OVS集成桥接补丁端口（14）。
用于自助服务网络（15）的OVS集成桥接端口移除内部VLAN标记并将分组转发到路由器命名空间中的自助服务网络接口（16）。
路由器将数据包转发到提供商网络的OVS集成桥接端口（18）。
OVS集成网桥将内部VLAN标记添加到数据包。
OVS集成桥接int-br-provider补丁端口（19）将数据包转发到OVS提供程序桥接phy-br-provider补丁端口（20）。
OVS提供程序桥将内部VLAN标记与实际VLAN标记101交换。
OVS提供商桥接提供商网络端口（21）将分组转发到物理网络接口（22）。
物理网络接口通过物理网络基础设施将数据包转发到Internet（23）。

场景说明：
虚拟机运行在计算节点1上，使用Self-service network 1。
Internet上的主机将数据包发送到虚拟机。
以下步骤涉及网络节点：
物理网络基础设施（1）将分组转发到提供者物理网络接口（2）。
提供商物理网络接口将数据包转发到OVS提供商网桥提供商网络端口（3）。
OVS提供程序桥将实际VLAN标记101与内部VLAN标记交换。
OVS提供者桥接phy-br-provider端口（4）将数据包转发到OVS集成桥接int-br-provider端口（5）。
提供商网络（6）的OVS集成桥接端口删除内部VLAN标记，并将数据包转发到路由器命名空间中的提供商网络接口（6）。
路由器将数据包转发到自助服务网络的OVS集成网桥端口（9）。
OVS集成网桥为数据包添加内部VLAN标记。
OVS集成桥为内部隧道ID交换内部VLAN标记。
OVS集成桥接patch-tun补丁端口（10）将数据包转发到OVS隧道桥接patch-int补丁端口（11）。
OVS隧道桥（12）使用VNI 101包裹分组。
用于覆盖网络底层物理接口（13）经由覆盖网络（14）将分组转发到网络节点。
以下步骤涉及计算节点：
覆盖网络的底层物理接口（15）将分组转发到OVS隧道桥（16）。
OVS隧道网桥解包并为其添加内部隧道ID。
OVS隧道网桥为内部VLAN标记交换内部隧道ID。
OVS隧道桥接patch-int补丁端口（17）将数据包转发到OVS集成桥接patch-tun补丁端口（18）。
OVS集成桥从数据包中删除内部VLAN标记。
OVS集成桥安全组端口（19）通过veth对将数据包转发到安全组桥OVS端口（20）。
安全组网桥上的安全组规则（21）处理数据包的防火墙和连接跟踪。
安全组桥接实例端口（22）经由veth对将分组转发到实例接口（23）。

场景说明：
虚拟机1运行在计算节点1上，使用self-service network 1。
虚拟机2运行在计算节点2上，使用self-service network 1。
虚拟机1将数据包发送到虚拟机2。
以下步骤涉及计算节点1：
实例1接口（1）通过veth对将数据包转发到安全组网桥实例端口（2）。
安全组网桥上的安全组规则（3）处理数据包的防火墙和连接跟踪。
安全组网桥OVS端口（4）通过veth对将数据包转发到OVS集成网桥安全组端口（5）。
OVS集成网桥为数据包添加内部VLAN标记。
OVS集成桥为内部隧道ID交换内部VLAN标记。
OVS集成桥接补丁端口（6）将数据包转发到OVS隧道桥接补丁端口（7）。
OVS隧道桥（8）使用VNI 101包裹分组。
用于覆盖网络的底层物理接口（9）经由覆盖网络（10）将分组转发到计算节点2。
以下步骤涉及计算节点2：
覆盖网络的底层物理接口（11）将分组转发到OVS隧道桥（12）。
OVS隧道网桥解包并为其添加内部隧道ID。
OVS隧道网桥为内部VLAN标记交换内部隧道ID。
OVS隧道桥接patch-int补丁端口（13）将分组转发到OVS集成桥接patch-tun补丁端口（14）。
OVS集成桥从数据包中删除内部VLAN标记。
OVS集成桥安全组端口（15）通过veth对将数据包转发到安全组网桥OVS端口（16）。
安全组网桥上的安全组规则（17）处理数据包的防火墙和连接跟踪。
安全组桥接实例端口（18）经由veth对将分组转发到实例2接口（19）。

场景说明：
虚拟机1运行在计算节点1上，使用self-service network 1。
虚拟机2运行在计算节点1上，使用self-service network 2。
虚拟机1将数据包发送到虚拟机2。
以下步骤涉及计算节点1：
实例1接口（1）通过veth对将数据包转发到安全组网桥实例端口（2）。
安全组网桥上的安全组规则（3）处理数据包的防火墙和连接跟踪。
安全组网桥OVS端口（4）通过veth对将数据包转发到OVS集成网桥安全组端口（5）。
OVS集成网桥为数据包添加内部VLAN标记。
OVS集成桥为内部隧道ID交换内部VLAN标记。
OVS集成桥接补丁端口（6）将数据包转发到OVS隧道桥接补丁端口（7）。
OVS隧道桥（8）使用VNI 101包裹分组。
用于覆盖网络的底层物理接口（9）经由覆盖网络（10）将分组转发到网络节点。
以下步骤涉及网络节点：
覆盖网络的底层物理接口 (11) 将数据包转发到 OVS 隧道桥 (12)。
OVS 隧道网桥解包数据包并向其添加内部隧道 ID。
OVS 隧道网桥将内部隧道 ID 交换为内部 VLAN 标记。
OVS 隧道桥接patch-int补丁端口 (13) 将数据包转发到 OVS 集成桥接patch-tun补丁端口 (14)。
自助服务网络 1 (15) 的 OVS 集成网桥端口删除内部 VLAN 标记并将数据包转发到路由器命名空间中的自助服务网络 1 接口 (16)。
路由器通过自助服务网络 2 接口 (17) 将数据包发送到下一跳 IP 地址，通常是自助服务网络 2 上的网关 IP 地址。
路由器将数据包转发到自助服务网络 2 (18) 的 OVS 集成网桥端口。
OVS 集成网桥将内部 VLAN 标记添加到数据包。
OVS 集成网桥将内部 VLAN 标记交换为内部隧道 ID。
OVS 集成桥接patch-tun补丁端口 (19) 将数据包转发到 OVS 隧道桥接patch-int补丁端口 (20)。
OVS 隧道桥 (21) 使用 VNI 102 包装数据包。
覆盖网络的底层物理接口 (22) 通过覆盖网络 (23) 将数据包转发到计算节点。
以下步骤涉及计算节点：
覆盖网络的底层物理接口 (24) 将数据包转发到 OVS 隧道桥 (25)。
OVS 隧道网桥解包数据包并向其添加内部隧道 ID。
OVS 隧道网桥将内部隧道 ID 交换为内部 VLAN 标记。
OVS 隧道桥接patch-int补丁端口 (26) 将数据包转发到 OVS 集成桥接patch-tun补丁端口 (27)。
OVS 集成网桥从数据包中删除内部 VLAN 标记。
vethOVS集成网桥安全组端口（28）通过pair将数据包转发到安全组网桥OVS端口（29）。
安全组网桥上的安全组规则 (30) 处理数据包的防火墙和连接跟踪。
veth安全组网桥实例端口（31）通过pair将数据包转发到实例接口（32）。

网络思考题

Linux有哪些网络虚拟化技术？
Neutron有哪些组件，各组件的作用是什么？
Neutron网络流量模型有哪些？

1、Linux中主要主要包括3类网络虚拟化技术：网卡虚拟化（TUN、TAP、VETH）、交换机虚拟化（Linux Bridge、Open vSwitch）、网络隔离（Network Namespace）。
2、Neutron主要包含Neutron server、Plugin和Agent等组件。Neutron server对外提供 OpenStack网络 API，接收请求，并调用Plugin处理请求；Plugin处理 Neutron Server发来的请求，维护OpenStack逻辑网络的状态， 并调用 Agent 处理请求；Agent处理Plugin的请求，负责在network provider上真正实现各种网络功能；此外还有database，用来存放OpenStack的网络状态信息，包括Network、Subnet、Port、Router等。
3、Linux Bridge + Flat/VLAN网络、Open vSwitch + VXLAN网络。

计量服务Ceilometer

Ceilometer项目是一项数据收集服务，提供跨当前OpenStack核心组件规范化和转换数据的能力
Ceilometer的数据可为所有OpenStack核心组件提供客户计费、资源跟踪和警报功能

不依赖任何服务

Ceilometer是OpenStack监控服务之一，负责计量与监控
Ceilometer项目提供一个基础设施来收集有关OpenStack项目所需的任何信息

Ceilometer发展与衍生

其实OpenStack由Telemetry项目来提供计量与监控的功能。其目标是针对各种组成云的虚拟与物理资源，收集各类使用数据并保存，以便对这些数据进行后续分析，并在相关条件满足时触发对应的动作和报警。
Telemetry项目包含以下子项目：
Aodh：是从Ceilometer中剥离而来的，是一种警报服务，可以在用户定义的规则被破坏时发送警报。
Panko：是从Ceilometer中剥离而来的，是一个事件存储项目，用来保存事件Event信息。
Ceilometer：Telemetry项目的源头，提供一个获取和保存各类使用数据的统一框架。
Gnocchi：为了解决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 和移动开发人员的多租户云消息传递和通知服务）；
存储到一个文件中。

Ceilometer-数据收集

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

Ceilometer-数据存储/访问

由于Ceilometer产生的数据量特别大，普通的数据库不能满足存储的需求而变成性能瓶颈。Telemetry社区建议使用Gnocchi来保存采样数据。
Gnocchi是一个开源时间序列库。Gnocchi解决的问题是大规模的时间序列数据和资源的存储和索引。这在现代云平台中非常有用，这些平台不仅庞大而且是动态的并且可能是多租户的。Gnocchi将所有这些都考虑在内。
Gnocchi在处理大量存储的聚合的同时具有高性能、可扩展性和容错性。
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服务来调用相应的报警动作。

ceilometer思考题

Ceilometer的作用是什么？
Ceilometer的数据收集方式有哪些？

1、Ceilometer是OpenStack监控服务之一，负责计量与监控 ，Ceilometer项目提供一个基础设施来收集有关OpenStack项目所需的任何信息，Ceilometer的数据可为所有OpenStack核心组件提供客户计费、资源跟踪和警报功能。
2、Ceilometer有2中数据收集方式，一种是通过Polling Agent根据配置定期、主动地通过各种API或其他通信协议去远端或本地的不同服务实体中获取所需要的测量数据；另一种是，第三方的数据发送者把数据以通知消息（Notification Message）的形式发送到消息总线（Notification Bus）上，Notification Agent会获取这些通知事件，并从中提取测量数据。