OpenStack 简介

openstack架构

 

 

 openstack各个组件及功能

Keystone 安全认证服务

Keystone为所有的OpenStack组件提供认证和访问策略服务，它依赖自身REST（基于Identity API）系统进行工作，主要对（但不限于）Swift、Glance、Nova等进行认证与授权。事实上，授权通过对动作消息来源者请求的合法性进行鉴定。
Keystone采用两种授权方式，一种基于用户名/密码，另一种基于令牌（Token）。
除此之外，Keystone提供以下三种服务：
    令牌服务：含有授权用户的授权信息
    目录服务：含有用户合法操作的可用服务列表
    策略服务：利用Keystone具体指定用户或群组某些访问权限

User

指使用Openstack service的用户。
Project(Tenant)

可以理解为一个人、或服务所拥有的资源集合。
Role

用于划分权限。通过给User指定Role，使User获得Role对应操作权限
Authentication

确定用户身份的过程。
Token

是一个字符串表示，作为访问资源的令牌。Token包含了在指定范围和有效时间内，可以被访问的资源。
Credentials

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

Openstack service，即Openstack中运行的组件服务。如swift、glance、neutron、cinder等。
Endpoint

一个可以通过网络来访问和定位某个Openstack service的地址，通常是一个URL。

Glance 镜像服务

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

OpenStack镜像服务器是一套虚拟机镜像发现、注册、检索系统，我们可以将镜像存储到以下任意一种存储中：
本地文件系统（默认）
S3直接存储
S3对象存储（作为S3访问的中间渠道）
OpenStack对象存储等等。

Glance构件：
Glance-API：
主要负责接收响应镜像管理命令的Restful请求，分析消息请求信息并分发其所带的命令（如新增，删除，更新等）。默认绑定端口是9292

glance-api

glance-api 是系统后台运行的服务进程，对外提供REST API,响应image查询，获取和存储的调用，glance-api不会真正处理请求。

如果是与image metadata相关的操作，glance-api会把强求转发给glance-registry;如果是与image自身存取的相关操作，glance-api会把请求转发给image的store bakend.

glance-registry

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

Database

image的metadata会保持到database中，默认是mysql

 

 

Nova 虚拟机管理系统

Nova是OpenStack计算的弹性控制器。OpenStack云实例生命期所需的各种动作都将由Nova进行处理和支撑，这就意味着Nova以管理平台的身份登场，负责管理整个云的计算资源、网络、授权及测度。虽然Nova本身并不提供任何虚拟能力，但是它将使用libvirt API与虚拟机的宿主机进行交互。Nova通过Web服务API来对外提供处理接口，而且这些接口与Amazon的Web服务接口是兼容的。

特点：
实例生命周期管理
计算资源管理
异步连续通信
基于REST的API
网络与授权管理

API

负责接收客户端请求，nova-api 作为 Nova 组件对外的唯一窗口，向客户暴露 Nova 能够提供的功能。当客户端需要执行虚机操作，客户端只能通过这些Rest API来完成，另外，这里的客户端指的是终端用户、命令行和 OpenStack 其他组件。

Nova Scheduler

当上面API的请求可以在多台实例或者节点上完成时，Scheduler可以根据当时的资源情况选择最合适的实例或者节点来执行请求。

Worker

Nova Worker其实质就是计算节点的nova-compute服务，前面Scheduler负责分发任务，而它则是负责执行任务。

Driver框架

在计算节点运行虚机，那必须要有Hypervisor来支持，而计算节点会支持多种Hypervisor（包括KVM, Hyper-V, VMWare, Xen, Docker, LXC等），nova-compute为Hypervisor定义统一接口，只要这些hypervisor实现了这些接口，就可以 以driver 的形式即插即用到 OpenStack 中，这样在技术上保持先进性，具有很强的竞争力，同时又不会造成厂商锁定（Lock-in），具有很大的灵活和开放性。

DB

通过数据库来维护Nova虚机的状态信息，比如MySQL会有Nova撞门的数据库。

MQ 

在openstack这样的分布式系统中，一般程序的调用都是采用异步调用处理的，而nova各组件间的协同工作是通过消息队列来实现的，默认采用RabbitMQ。Message Queue（Rabbit MQ Server）OpenStack 节点之间通过消息队列使用AMQP（Advanced Message Queue Protocol）完成通信。Nova 通过异步调用请求响应，使用回调函数在收到响应时触发。因为使用了异步通信，不会有用户长时间卡在等待状态。这是有效的，因为许多API调用预期的行为都非常耗时，例如加载一个实例，或者上传一个镜像。Compute Worker（nova-compute）Compute Worker处理管理实例生命周期。他们通过Message Queue接收实例生命周期管理的请求，并承担操作工作。在一个典型生产环境的云部署中有一些compute workers。一个实例部署在哪个可用的compute worker上取决于调度算法。

Network Controller（nova-network）

Network Controller 处理主机地网络配置。它包括IP地址分配、为项目配置VLAN、实现安全组、配置计算节点网络。

Volume Workers（nova-volume）

Volume Workers用来管理基于LVM（ Logical Volume Manager ）的实例卷。Volume Workers有卷的相关功能，例如新建卷、删除卷、为实例附加卷，为实例分离卷。卷为实例提供一个持久化存储，因为根分区是非持久化的，当实例终止时对它所作的任何改变都会丢失。当一个卷从实例分离或者实例终止（这个卷附加在该终止的实例上）时，这个卷保留着存储在其上的数据。当把这个卷重附加载相同实例或者附加到不同实例上时，这些数据依旧能被访问。一个实例的重要数据几乎总是要写在卷上，这样可以确保能在以后访问。这个对存储的典型应用需要数据库等服务的支持。

Scheduler（nova-scheduler）

调度器Scheduler把nova-API调用映射为OpenStack组件。调度器作为一个称为nova-schedule守护进程运行，通过恰当的调度算法从可用资源池获得一个计算服务。Scheduler会根据诸如负载、内存、可用域的物理距离、CPU构架等作出调度决定。nova scheduler实现了一个可插入式的结构。

Neutron 虚拟网络服务

Neutron仅有一个主要服务进程Neutron-server，它运行于控制节点上，对外提供openstack网络api作为访问Neutron的入口，收集请求后调用插件（plugin）进行处理，最终由计算节点和网络节点上的各种代理（agent）完成请求
网络提供者（network-provider）是指提供者openstack网络服务的虚拟机或者物理网络设备，如linux bridge、open vswitch或者其他支持neutron的物理交换机。与其他服务一样，neutron的各个组件服务之间需要相互协调通信，neutron-server、插件、代理之间通过消息队列（默认用RabbitMQ实现）进行通信和相互协调。
数据库（默认使用MariaDB）用于存放openstack的网络状态信息，包括网络、子网、端口、路由器等等。
客户端（Client）是指使用neutron服务的应用程序，可以是命令行工具（脚本）、horizon（openstack图形化操作界面）和nova计算服务等。
举例：创建一个vlan 10虚拟网络的流程
（1）neutron-server收到创建网络（network）的请求，通过消息队列（RabbitMQ）通知已注册的linux bridge插件（这里假设网络提供者为linux bridge）。
（2）该插件将要创建的网络信息（如名称、ID值、VLANID等）保存到数据库中并通过消息队列通知运行在各个节点上的代理。
（3）代理收到信息后会在节点上物理网卡创建vlan设备（比如物理接口的子接口Eth1.10），并创建一个网桥（比如brgxxx）来桥接网络设备

插件、代理与网络提供者
neutron遵循openstack的设计原则，采用开放架构，通过插件、代理与网络提供者的配合来实现各种网络功能。
插件是neutron的一种API的后端实现，目的是增强扩展性，插件按照功能可分为Core Plugin和Service Plugin两种类型，Core Plugin提供基础二层虚拟机网络支持，实现网络、子网和端口核心资源的支持，Service Plugin是指Core Plugin之外的其他插件，提供路由器、防火墙、安全组、负载均衡等服务支持，值得一提的是，直到openstack的Havana版本，neutron才开始提供一个名为 L3 Router Service Plugin的插件支持路由服务。
插件由neutron-server的Core Plugin API和Extension Plugin API调用，用于确定具体的网络功能，即需要配什么样的网络，插件处理neutron-server发来的请求，主要职责是在数据库中维护neutron网络的状态信息（更新neutron数据库），通知相应的代理实现具体的网络功能，每一个插件支持一组API资源并完成特定操作，这些操作最终由插件通过RPC调用相应的代理（agent）来完成。
代理处理插件转来的请求，负责在网络提供者上真正实现各种网络功能。代理使用物理网络设备或者虚拟化技术来完成实际的操作任务，如用于路由具体操作L3 Agent
插件和代理与网络提供者配套使用，比如网络提供者是linux bridge，就需要使用linux bridge的插件和代理，如换成open vswitch则需要改成相应的插件和代理。

Neutron的物理部署服务
neutron与其他openstack服务组件系统工作，可以部署在多个物理主机节点上，主要涉及控制节点、网络节点和计算节点，每个节点可以部署多个，典型的主机节点部署介绍如下：
（1）控制节点和计算节点
控制节点上部署neutron-server(API)、Core Plugin和Service Plugin的代理，这些代理包括neutron-plugin-agent、neutron-metadata-agent、neutron-dhcp-agent、neutron-l3-agent、neutron-lbaas-agent等。Core Plugin和Service Plugin已经集成到neutron-server中，不需要运行代理的plugin服务。
计算节点上可以部署Core Plugin、Linux Bridge或Open vSwitch的代理，负责提供三层的网络功能。
控制节点和计算节点上都需要部署Core Plugin的代理，因为控制节点与计算节点通过该代理才能进行二层连接。
（2）控制节点和网络节点
可以通过增加网络节点承担更大的负载，该方案特别适合规模较大的openstack环境
控制节点部署neutron-server服务，只负责通过neutron-server响应的API请求。网络节点部署的服务包括Core Plugin的代理和Service Plugin的代理，将所有的代理从上述节点分离出来，部署到独立的网络节点上，由独立的网络节点实现数据的交换，路由以及负责均衡等高级网络服务。

Dashboard Web 界面

提供一个web界面操作openstack的系统，使用Django框架基于openstack API开发，支持session存储在DBmemcached 支持集群，Horizon是OpenStack的一个子项目，用于提供一个Web前端控制台（称为Dashboard），以此来展示OpenStack的功 能。通常情况下，我们都是从Horizon、Dashboard开始来了解OpenStack的。实际上，Horizon并不会为OpenStack添加 任何一个新的功能，它只是使用了OpenStack部分API功能，因此，我们可以扩展Horizon的功能，扩展Dashboard。

Cinder 块存储服务

Cinder在OpenStack中为虚拟机实例提供volume卷的块存储服务，可将卷挂载在实例上作为虚拟机实例的本地磁盘来使用，一个volume卷可以同时挂载到多个实例上，但是同时只能有一个实例可以对卷进行写操作，其他只能是只读的。

Cinder架构原理

当有用户或Nova compute提供创建卷的请求时，首先由Cinder API接收请求，然后以消息队列的形式发送给Cinder Scheduler来调用，Cinder Scheduler 侦听到来自Cinder API的消息队列后，到数据库中取查询当前存储节点的状态信息，并根据预定策略选择卷的最佳volume service节点，然后将调度的结果发布出来给volume service来调用，当volume service收到volume scheduler 的调度结果后，会去查找volume providers, 从而在特定存储节点上创建相关的卷，然后将相关结果返回给用户，同时将修改的数据写入到数据库中。

cinder-sheduler筛选机制

cinder-sheduler通过filter进行删选，允许使用第三方的filter，自定义筛选内容。

scheduler

通过名为volume_create_scheduler的Flow执行调度。

 cinder-volume

当cinder-volume接收到消息，才真正开始实际创建volume，cinder-volume通过driver来创建volume，方式类同于cinder-scheduler，也是通过Flow（名称为 volume_create_manager）的方式

挂载volume

创建完成之后,通过attach操作将此volume挂载到虚拟机上，这样虚拟机就成功获得该volume作为虚拟硬盘使用

卸载volume
detach volume相当于断开挂载状态，再删除volume这样一个逆向的过程。我们分析挂载的本质，其实是通过volume连接，让控制节点上的Iscsi initiator将计算节点上的Iscsi Target的volume识别为一个硬盘，再通过XML文件建立映射使得虚机能够使用这个volume。

所以卸载volume就是1.去掉映射  2.处理缓存中的数据  3.删除对应的SCSI设备 4.断开Iscsi Target连接 5.删除该Iscsi Target

 cinder扩容

非挂载状态的volume是可以通过extend进行扩容的（如果已经挂载上的volume可以先卸载再扩容），cinder 是不允许缩小 volume

cinder-api接收到扩容请求，通过消息队列转发给cinder-volume，cinder-volume执行 lvextend 命令进行扩容（扩多少是不是由cinder-pai带过来的参数决定？还是不用带参数通过别的方式实现，周一来试试）

 删除 volume

delete volume同样不能删除已经挂载的volume，需要先detach到Available 状态才能执行delete volume，cinder-volume 通过执行 lvremove 命令删除volume（先清除逻辑卷LV上面的数据，再删除该LV）
Snapshot Volume 操作

volume快照可以在对正在挂载状态的volume进行操作，但是有可能会数据不一致。如果需要保持数据一致，可以先detach停掉磁盘IO操作，使该volume处于Available 状态

cinder-volume 通过执行 lvcreate 创建 snapshot，volume的快照本身也是一个逻辑卷，具有逻辑卷的所有特性。但是volume的快照根据其采取的volume-provider不同，有不同方式的快照。这些快照对源volume的依赖程度是完全不同的。

基于LVM的磁盘管理的是完全copy当前volume到一个新的LV，对源volume基本无依赖。但是对于基于Ceph这一类的分布式文件系统的volume快照，则仅仅是对于当前volume的数据状态建立一个指针，对源voluume的依赖极高。所以snapshot volume基本用来做快速回溯而不是容灾备份（问题：第二种方式的volume快照要是源volume损坏了怎么办？答：一般会备份多个快照，极大降低了源快照损坏的问题）

 backup volume操作

backup volume解决了snapshot volume对源volume的依赖问题，主要用来恢复volume，而snapshot volume更多的是用来快速回溯（针对源volume没有损坏但是需要回退某些操作的需求）
restore操作

根据backup备份进行restore恢复，创建一个空的volume，然后装载NFS读取container 目录中backup备份的meatdata，将快照数据解压写入新建的这个volume中，最后恢复meatdata，restore完成。

 Boot from Volume操作

之前我们考虑的都是怎么将volume安全的作为存储盘，事实上volume同样可以作为启动盘。之前在上一篇nova Launch学习中，所用到的是，直接从 image launch（Boot from image直接获取image ），或者从 instance 的 snapshot launch（Boot from snapshot通过快照获取image）两种方式。

Swift 存储服务

Swift 是 OpenStack 的对象存储组件，无需采用RAID（磁盘冗余阵列），也没有中心单元或主控结点。Swift通过在软件层面引入一致性哈希技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性（High Availability，简称HA）和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。

Swift特点

极高的数据持久性（Durability）。

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

无限的可扩展性：一是数据存储容量无限可扩展；二是Swift性能（如QPS、吞吐量等）可线性提升。

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

Swift主要组件

Swift-proxy server

Proyx Server 向用户提供了一套操作Swift的API接口，对于每个Swift请求，PorxyServer首先会通过Ring查找被操作实体对象的物理位置，随后会将请求发送过去，可以理解为ProxyServer是Swift对外的统一入口和出口，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务；由于采用无状态的 REST 请求协议，可以进行横向扩展来均衡负载。

另外，当某个服务器因为故障无法添加对象时，ProxyServer 会通过Ring的hash计算，重新获取一个可用的服务器，并将请求切换至该服务器。

 Swift Ring

Ring是swift中非常核心的组件，用于记录存储对象与物理位置间的映射关系。在涉及查询Account、Container、Object信息时就需要查询集群的Ring信息，为了将虚拟节点(partition，分区)均衡地映射到一组物理存储设备上，并提供一定的冗余度而设计的。

 Ring还提供一个基于一致性Hash所构建的环，它决定着数据如何在集群中分布。 Proxy Server 根据account，container 和 object 各自的 Ring 来确定各自数据的存放位置，其中 account 和 container 数据库文件也是被当作对象来处理的。

 Swift根据设置的partition_power决定集群中的分区（partition）数量（2的partition_power次方），并根据一致性哈希算法将分区分配到不同的node上，并将数据分布到对应的分区上。

 Ring使用zone来保证数据的物理隔离。 每个partition的replica都确保放在了不同的zone中，Zone只是个抽象概念，它可以是一个磁盘（disk drive），一个服务器（server），一个机架（cabinet），一个交换机（switch），甚至是一个数据中心（datacenter），以提供最高级别的冗余性。

 Weight权重参数是个相对值，可以来根据磁盘的大小来调节，权重越大表示可分配的空间越多，可部署更多的分区。

每个存储节点中有一个Account Server ，负责对处理对Account的GET，HEAD，PUT，DELETE,REPLICATION请求的服务进程，并提供账户元数据和统计信息，维护所含账户列表的服务，每个账户的信息被存储在一个 SQLite 数据库中。

 swift-container server

每个存储节点存在一个Container Server，负责处理Container的GET,HEAD,PUT,DELETE,REPLICATION请求的服务进程，并提供容器元数据和统计信息，维护所含容器列表的服务，每个容器的信息也存储在一个 SQLite 数据库中。

 swift-object server

每个存储节点存在一个Object Server，一个简单的BLOB存储服务器，提供对象元数据和 内容服务，可以存储，检索和删除保存在本节点的对象。对象以二进制的形式保存在文件系统， 元数据以XATTR的形式保存在文件的扩展属性上，所以要求底层的文件系统支持XATTR特性。 元数据会作为文件属性来存储，建议采用支持扩展属性的 XFS文件系统。

 Replicator

会检测本地分区副本和远程副本是否一致，具体是通过对比散列文件和高级水印来完成，发现不一致时会采用推式 （Push）更新远程副本，例如对象复制服务会使用远程文件拷贝工具 rsync 来同步；另外一个任务是确保被标记删除的对象从文件系统中移除。

 Updater

当对象由于高负载的原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如 成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。

 Auditor

检查对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误会被记录到日志中。

 Account Reaper

移除被标记为删除的账户，删除其所包含的所有容器和对象。