OpenStack了解和深入

初识OpenStack

对于从未接触过云计算的人员来说，OpenStack是一个很陌生的词，不知道它到底是什么，从哪里来，有什么用，和自己的工作有什么关系。

OpenStack是什么

在了解之前，需要先了解云计算的概念

云计算是基于互联网的相关服务的增加、使用和交付模式，涉及通过互联网提供动态易扩展的以及经常是虚拟化的资源。云是网络、互联网的一种比喻。

OpenStack是一个开源的云计算管理平台，是基础设施即服务（IaaS：通过互联网提供“基础的计算资源”）软件，让任何人都可以自行创建和提供云计算服务。OpenStack是美国国家航空航天局和Rackspace合作研发的云计算软件，以Apache授权条款授权，并且是自由和开放源代码软件。

OpenStack本质是一个工具。

OpenStack项目与组件

核心项目
- 控制台（Horizon）：web方式管理云平台，建云主机，分配网络，配安全组，加云盘
- 计算（Nova）：负责响应虚拟机创建请求、调度、销毁云主机
- 网络（Neutron）：实现SDN（软件定义网络），提供一整套API，用户可以基于该API实现自己定义专属网络，不同厂商可以基于此API提供自己的产品实现
共享服务项目
- 认证服务（Keystone）：为访问openstack各组件提供认证和授权功能
- 镜像服务（Glance）：为云主机安装操作系统提供不同的镜像选择
- 计费服务（Ceilometer）：收集云平台资源使用数据，用来计费或者性能监控
存储项目
- 对象存储（Swift）：REST风格的接口和扁平的数据组织结构
- 块存储（Cinder）：提供持久化块存储，即为云主机提供附加云盘
高层服务
- 编排服务（Heat）：自动化部署应用，自动化管理应用的整个生命周期

OpenStack代码质量保证体系

编码规范：代码静态检查（Flake8）、Hacking
代码评审：Gerrit-基于git的代码审核服务器
单元测试：Tox
持续集成：使用Jenkins搭建持续集成服务器，进行集成测试

OpenStack通用技术

OpenStack通用库，以及各个项目使用到的大量其他技术和第三方库进行介绍。

消息总线

OpenStack遵循设计原则为，项目之间通过RESTful API进行通信，项目内部，不同服务进程之间的通信，则必须要通过消息总线。消息总线模式，顾名思义即一些服务向总线发送消息，其他服务从总线上获取消息。

项目内部通信的两种方式（olso.messaging库实现）：

远程过程调用（RPC）：call（同步）、cast（异步）
事件通知（Event Notification）：发送至消息总线，处理的结果并不会返回给事件发送者

SQLAlchemy和数据库（Shane）

SQLAlchemy是Python编程语言下的一款开源软件，主要分成两部分：

SQLAlchemy Core（SQLAlchemy 核心）：包括SQL语言表达式、数据引擎、连接池等，主要是为了连接不同类型的后台数据库、提交查询和更新SQL请求去后台执行、定义数据库数据类型和定义Schema
SQLAlchemy ORM（SQLAlchemy对象关系映射器）：把程序语言的对象数据映射成数据库的关系数据

SQLAlchemy是一座架设在Python和各种各样后台数据库的桥梁，让开发人员可以用很容易且简便地用Python语句查询和更新数据库的数据。

RESTful API 和 WSGI

RESTful是目前流行的一种互联网软件架构，其核心概念是资源与资源上的操作，是设计风格而不是标准

WSGI（Web服务器网关接口）是Python语言中所定义的Web服务器和Web应用程序或框架之间的通用接口标准，可理解为一个桥梁，一端是服务端或网关端，另一端是应用端或框架端，将Web组件分为三类：Web服务器、Web中间件、Web应用程序。

OpenStack使用Paste的Deploy组件来完成WSGI服务器和应用的构建，使用WebOb通过对WSGI的请求与响应进行封装，来简化WSGI应用的编写。

OpenStack 通用库 Olso

Cliff：帮助构建命令行程序
olso.config：解析命令行和配置文件中的配置选项
olso.db：针对SQLAlchemy访问的抽象
olso.i18n：字符串的翻译和国际化
olso.messaging：为OpenStack各个项目使用RPC和事件通知提供了一套统一的接口
stevedore：是开发者可以更容易地在运行时发现和载入插件
TaskFlow：更容易地控制任务执行
cookiecutter：模板，可以快速新建一个符合惯例的OpenStack项目
olso.policy：负责policy的验证和rules的管理
olso.rootwrap：可以让其他OpenStack服务以root身份执行shell命令
olso.test：提供单元测试的基础框架

虚拟化

云计算的核心思想就是在服务器端提供集中的物理计算资源，这些计算资源可以被分解成更小的单位去独立地服务于不同用户。

虚拟化概述

虚拟化是云计算的基础。简单来说，虚拟化就是在一台物理服务器上，运行多台“虚拟服务器”。这种虚拟服务器，也叫 虚拟机（VM，Virtual Machine） 。
物理机，通常称为“宿主机（Host）”。虚拟机，则称为“客户机（Guest）”。

Hypervisor，汉译过来是“超级监督者”，也叫做VMM（Virtual Machine Monitor，虚拟机监视器）。它不是一款具体的软件，而是一类软件的统称，它来完成物理资源虚拟化的工作。

Hypervisor按照实现方式分为两类：

hypervisor直接运行在物理机之上，虚拟机运行在hypervisor之上，例Xen
物理机上安装正常的操作系统（例如Linux或Windows），然后在正常操作系统上安装hypervisor，生成和管理虚拟机，例KYM和VirtualBox

image

虚拟化产品：

VMware
Microsoft
Xen
KVM：基于Linux内核的虚拟机，是目前最热门最受追捧的虚拟化方案

高层管理工具

XenAPI：用于远程或本地配置和管理Xen的虚拟机，工作在比Xen更高级的层面，比如集群、网络、存储等
Libvit：是由Redhat开发的一套开源的软件工具，目标是提供一个通用和稳定的软件库来高效、安全地管理一个节点上的虚拟机，并支持远程操作，由以下模块组成：
- 一个库文件，实现管理接口
- 一个守护进程（libvirtd）
- 一个命令行工具（virsh）

OpenStack相关实现

OpenStack中和虚拟化联系最紧密的是Nova，其使用前面所说的虚拟化管理工具来管理虚拟机，Nova提供了一个Virt Driver的框架支持各种的虚拟化实现，也使得用户可以在部署Nova时选择使用什么样的管理工具和VMM

包含两种驱动：

Libvirt驱动：提供了很好的Python绑定
XenAPI驱动

计算-Nova组件

“欢迎来到虚拟机的世界”！OpenStack的计算组件，也就是Nova项目为我们实现了这个虚拟机世界的抽象，控制着一个个虚拟机的状态变迁与生老病死，管理着它们的资源分配

Nova体系结构

image

Nova主要由API、Compute、Conductor、Scheduler四个核心服务所组成

Nova API

整个Nova组件的门户，所有对Nova的请求都首先由Nova API处理，是访问并使用Nova所提供的各种服务的唯一途径，它把客户端的请求传达给Nova，待Nova处理完请求后再将处理结果返回给客户端

Nova-API对外提供一个与云基础设施交互的接口，也是外部可用于管理基础设施的唯一组件。它负责发起相应的类似运行新虚拟机实例这样的资源调度活动，在实现层面上，nova-api是Python实现的WSGI应用

只要是跟虚拟机生命周期相关的操作，nova-api 都可以响应，大部分操作都可以在 Dashboard 上找到

nova-api 对接收到的 HTTP API 请求会做如下处理：

检查客户端传人的参数是否合法有效
调用 Nova 其他子服务的处理客户端 HTTP 请求
格式化 Nova 其他子服务返回的结果并返回给客户端

Conductor 服务

Conductor服务目的是为数据库的访问提供一层安全保障

nova-compute 需要获取和更新数据库中实例的信息。但 nova-compute 并不会直接访问数据库，而是通过 nova-conductor 实现数据的访问：

实现更高的系统安全性：从 G 版本开始，Nova 引入了一个新服务 nova-conductor，将 nova-compute 访问数据库的全部操作都放到nova-conductor 中，而且 nova-conductor 是部署在控制节点上的。这样就避免了 nova-compute 直接访问数据库，增加了系统的安全性
实现更好的系统伸缩性：nova-compute 与 nova-conductor 是通过消息中间件交互的。这种松散的架构允许配置多个 nova-conductor 实例。在一个大规模的 OpenStack 部署环境里，管理员可以通过增加 nova-conductor 的数量来应对日益增长的计算节点对数据库的访问

Scheduler

nova-scheduler 解决如何选择在哪个计算节点上启动实例的问题。

OpenStack 的虚拟机调度策略主要是由 FilterScheduler 和 ChanceScheduler 实现的，其中FilterScheduler 作为默认的调度器实现了基于主机过滤(filtering)和权值计算(weighing)的调度算法，而 ChanceScheduler 则是基于随机算法来选择可用主机的简单调度器。

FilterScheduler调度过程分为两步：
1）通过过滤（filtering）选择满足条件的计算节点（运行 nova-compute）
2）通过权重计算（weighting）选择在最优（权重值最大）的计算节点上创建实例

思考：调度算法了解

Compute

nova-compute 在计算节点上运行，负责管理节点上的实例。OpenStack 对实例的操作，最后都是交给 nova-compute 来完成。nova-compute 与 Hypervisor 一起实现 OpenStack 对实例生命周期的管理。

nova-compute 的功能可以分为两类：

定时向 OpenStack 报告计算节点的状态：每隔一段时间，nova-compute 就会报告当前计算节点的资源使用情况和 nova-compute 服务状态。可以查看日志 /var/log/nova/nova-compute.log。这样OpenStack 就能得知每个计算节点的 cpu、ram、disk 等信息。nova-scheduler 的很多 Filter 才能根据计算节点的资源使用情况进行过滤，选择符合 flavor 要求的计算节点。
实现实例生命周期管理：OpenStack 对实例最主要的操作都是通过 nova-compute 实现的，包括实例的启动、关闭、重启、暂停、恢复、删除、调整实例大小、迁移、创建快照等。

虚拟机创建

image

1）客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚拟机”。
2） API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚拟机”。
3）Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A。
4）Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚拟机”。
5）计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚拟机。
6）在虚拟机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

存储-Cinder&Glance

存储是OpenStack所管理的最重要的资源之一，Swift（对象存储）与Cinder（块存储）引入了永久存储

Cinder体系结构

Cinder主要由cinder-api（http接口）、cinder-shelduler（调度服务）、cinder-volume（存储空间）、cinder-backup（备份功能）几个服务所组成

cinder-api

Cinder API对外提供REST API,对操作需求进行解析，并调用处理方法，是进入Cinder的HTTP接口

cinder-volume

cinder-volume运行在存储节点上管理具体存储设备的存储空间，每个存储节点上都会运行一个cinder-volume服务，多个这样的节点一起便构成了一个存储资源池。多节点部署，使用不同的配置文件、接入不同的后端设备，由各存储厂商插入Driver代码与设备交互，完成设备容量和能力信息收集，卷操作等。Cinder默认的后端驱动是LVM（Logical Volume Manager）

cinder-shelduler

Cinder scheduler负责收集后端上报的容量，能力信息，根据设定的算法完成卷到指定cinder-volume的调度，它通过过滤和称权，筛选出合适的后端，如果用户请求已经指定了具体的存储节点，则该节点上的cinder-volume会进行处理，并不需要cinder-shelduler的参与

cinder-backup

cinder-backup用于将Volume备份到其他存储系统上

典型工作流程

image

Glance体系结构

Glance是Openstack项目中负责镜像管理的模块，其功能包括虚拟机镜像的查找、注册和检索等。 Glance提供Restful API可以查询虚拟机镜像的metadata及获取镜像。 Glance可以将镜像保存到多种后端存储上，比如简单的文件存储或者对象存储。

image

Glance主要由glance-api与glance-registry两个服务组成，Image是Glance所管理的主要资源

glance-api

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

glance-registry

glance-registry 是系统后台运行的服务进程。负责处理和存取 image 的 metadata，例如 image 的大小和类型。

Database

Image 的 metadata 会保持到 database 中，默认是 MySQL。

Store backend

Glance 自己并不存储 image。真正的 image 是存放在 backend 中的。

网络-Neutron组件

Nova实现了OpenStack虚拟机世界的抽象，Swift与Cinder为虚拟机提供了安身之本，但没有网络，任何虚拟机都将只是这个世界中的孤岛，不知道自己的生存价值。

Neutron体系结构

OpenStack所在的整个物理网络在Neutron中也被泛化为网络资源池，通过对物理网络资源的灵活划分与管理，Neutron能够为同一物理网络上的每个租户提供独立的虚拟网络环境。
Neutron最为核心的工作是对二层物理网络network的抽象和管理（二层网络指的就是数据链路层，三层网络指的就是网络层）

Nuetron 架构

image

Neutron Server

对外提供 OpenStack 网络 API，接收请求，并调用 Plugin 处理请求

Plugin

处理 Neutron Server 发来的请求，维护 OpenStack 逻辑网络状态，并调用 Agent 处理请求

Agent

处理 Plugin 的请求，负责在 network provider 上真正实现各种网络功能

network provider

提供网络服务的虚拟或物理网络设备，例如 Linux Bridge，Open vSwitch 或者其他支持 Neutron 的物理交换机

Queue

Neutron Server，Plugin 和 Agent 之间通过 Messaging Queue 通信和调用

Database

存放 OpenStack 的网络状态信息，包括 Network, Subnet, Port, Router 等

安全-Keystone组件

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

Keystone体系结构

image

Keystone 类似一个服务总线，或者说是整个 Openstack 框架的注册表，OpenStack 服务通过 Keystone 来注册其 Endpoint（服务访问的URL），任何服务之间的相互调用，都需要先经过 Keystone 的身份验证，获得目标服务的 Endpoint ，然后再调用。

user

User 指代任何使用 OpenStack 的实体，可以是真正的用户，其他系统或者服务。当 User 请求访问 OpenStack 时，Keystone 会对其进行验证。

Tenant

租户，我们可以把租户理解成一个组织或一个项目，租户是各个服务中的一些可以访问的资源集合。

Role

角色，一个用户所拥有的角色，角色不同，权限不同

Service

OpenStack 的 Service 包括 Compute (Nova)、Block Storage (Cinder)、Object Storage (Swift)、Image Service (Glance) 、Networking Service (Neutron) 等。每个 Service 都会提供若干个 Endpoint，User 通过 Endpoint 访问资源和执行操作

Endpoint应用

端点，一个可以用来访问某个具体服务的网络地址

Token

令牌，用户通过Credential获取在某个租户下的令牌，以及令牌的颁发时间和有效时间

Credebtitals

凭证，用户的用户名和密码，或者是用户名和API密钥，或者是身份管理服务提供的认证令牌

Keystone服务

Keystone主要提供了Identity（认证）、Token（令牌）、Catalog（目录）和Policy（安全策略）四个方面的服务

控制面板-Horizon组件

Horizon 为 Openstack 提供一个 WEB 前端的管理界面 (UI 服务 )通过 Horizone 所提供的 DashBoard 服务 , 管理员可以使用通过 WEB UI 对 Openstack 整体云环境进行管理 , 并可直观看到各种操作结果与运行状态。

Horizon 体系结构

Horizon采用了Django框架

部署

对于OpenStack来说，首先是NEC创建了一个用户管理物理裸机的工具Ironic,后来惠普又在Ironic的基础上创建了一个独立的OpenStack项目TripleO，用于完成OpenStack的安装与部署。

TripleO体系结构

TripleO最为重要的一个特点是V2P（虚拟机的镜像迁移到物理机上）

TripleO全称OpenStack On OpenStack，顾名思义“云上云”，可以简单理解为利用OpenStack来部署OpenStack，即首先基于上述V2P的理念准备一个OpenStack节点的镜像，然后利用已有OpenStack环境的裸机服务（即Ironic项目）去部署裸机，最后通过Heat项目再在裸机上配置运行OpenStack

toDo：TripleO部署范例

各组件逻辑流程

image

云主机流程图

image

处理流程

界面或命令行通过RESTful API向keystone获取认证信息。
keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
界面或命令行通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
通过认证后nova-api和数据库通讯。
初始化新建虚拟机的数据库记录。
nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
nova-scheduler进程侦听消息队列，获取nova-api的请求。
nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
nova-conductor从消息队队列中拿到nova-compute请求消息。
nova-conductor根据消息查询虚拟机对应的信息。
nova-conductor从数据库中获得虚拟机对应信息。
nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
nova-compute从对应的消息队列中获取虚拟机信息消息。
nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
glance-api向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机镜像信息(URL)。
nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
neutron-server向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机网络信息。
nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
cinder-api向keystone认证token是否有效，并返回验证结果。
token验证通过，nova-compute获得虚拟机持久化存储信息。
nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

问题思考

前端项目如何结合实践，概念如何转变为应用
OpenStack部署和安装

OpenStack了解和深入