您的位置:首页 > 运维架构

OpenStack基础原理详解

2017-03-28 00:32 176 查看
  OpenStack主要分为Nova.Glance.Swift,Cinder等,实际上是由一组离散服务组成的.尽管新组件更多的是面向业务的,但是OpenStack还是可以提供构建网络的基础设施和运行通用虚拟机的.OpenStack支持包括公有云,私有云,混合云的部署方式,但OpenStack不是虚拟化,也不是云,构建云,我们还需要很多东西.那么OpenStack是什么呢?

  OpenStack是目前最主流的开源云系统操作系统内核.

OpenStack三大组件

计算,网络,存储

Nova

主要功能:

实现实例的生命周期的管理

调动管理平台的网络、存储等资源

提供了统一风格的 RestAPI接口

支持KVM、VMware等透明的hypervisor

各个模块之间通过消息队列来进行消息传递

常用术语:

KVM:内核虚拟化,OpenStack默认的是Hypersvisor

Qemu:KVM的替补角色,没有KVM效率高,不支持全虚拟化

Flavor:新建虚拟机的配置列表,虚拟机模板

Keypair:ssh连接访问实例的密钥对

安全组:用来控制实例访问策略的容器

安全组规则:用来控制访问的具体实例

Nova框架:



Nova Api:提供统一rest-Api风格Api接口,作为Nova组件的入口,接受用户的请求

Nova scheduler :负责调度,将实例分配到具体计算节点

Nova conductor:负责Nova与数据库进行交互

Nova compute:用于虚拟机实例的创建和管理

Message Queue:Nova各个组件之间的信息传递

Nova工作原理:



Nova api接受用户的Cli命令或horizon创建实例请求,以消息队列的形式将请求发送给Nova scheduler,Nova scheduler通过Nova conductor与数据库进行交互,计算当前节点的负载及使用情况,将虚拟机实例分配到当前节点负载最小且满足启动虚拟机实例的节点上,而最终的实例还是要通过Nova compute来创建,而Nova compute将会与Nova volume、Nova network等等一些组件通过消息队列的方式实现相互的协作,最终完成虚拟机实例的创建.

Swift

主要功能:

实现高可用分布式对象存储

为Nova组件提供虚拟机镜像存储

适用于互联网应用场景下非结构化数据存储

常用术语:

Account:用户的管理存储区域

Cnotainer:存储隔间,类似于文件夹或目录

Object:包含了基本的存储实体和它本身的元数据

Ring:记录了磁盘上存储的实体名称和物理位置映射关系

用户可以创建多个Account,每个account里可以创建多个容器container,每个container下可以创建多个object.【container 之间不能相互嵌套】

Region:地域,从地理位置上划分的一个概念

Zone:可用区,按照独立的供网,供电基础设施划分

Node:节点,存储服务器

Disk:磁盘,物理服务器上的存储设备

Cluster:为冗余考虑的部署架构

不同的region代表不同的城市,然后在同一个region下,为冗余的考虑,设置了多个可用区,zone。每一个可用去可以有不同的存储节点,node;在更大的架构上,两个region可以构成一个cluster。

存储特性

Swift在物理结构上往往会存储对象的多个副本,通常按照物理位置的特点,将对象拷贝到不同哦奶粉的物理位置上,来保证数据的可靠性

Swift架构



用户提出一个对象存储服务的申请,由Swift的API接受和处理,收到之后,先去找keyStore认证节点,对用户的身份进行认证。认证通过后,将请求提交给名称为Swift Proxy的组件,Swift Proxy是Swift 的代理,由Swift Proxy来确定究竟应该将存储对象放在哪一个满足存储要求的存储节点上。最终将返回结果返回给用户。

KeyStone

主要功能:

提供身份验证、服务规则和服务令牌功能

任何服务之间相互调用,都需要经过keystone的身份验证

常用术语:

User:Openstack最基本的用户

Project:指分配给使用者的资源的集合

Role:代表一组用户可以访问组员的权限

Domain:定义管理边界,可以包含多个project/tenant、user、role等

Endpoint:服务的URL路径,暴露出来的访问点

每个Domain对应多个Project,Project对应多个用户,用户可以跨Project存在

认证原理



当用户再创建时,将通过Keystone将会创建一个访问令牌accesstoken,假设当用户提出创建虚拟机实例的请求时,首先将自己的访问令牌和访问请求提交给NOVE服务,NOVE服务为确保用户的访问令牌并没有篡改过,因此首先会将访问令牌交给keystone进行验证,验证通过后nova为了启动虚拟机的实例,还需要向Glance组件申请相关的镜像资源,Glance为保证访问令牌在传递的过程中没有被篡改过,也需要将访问令牌发送给keystone做确认,验证通过后将会发放镜像资源给nova组件,虚拟机实例的创建还需要存储、网络等资源,因此nova组件还需要给负责各种资源的模块传递申请资源的请求,资源申请的过程中都会伴随这访问令牌的验证,nova拿到启动虚拟机实例的所有资源后进行实例的启动,然后分配给相关的用户。整个过程来看组件之间资源的调用都离不开keystone的验证….

Neutron

主要功能:

提供网络服务的核心组件

基于软件定义网络的思想

实现软件化的网络资源管理,在实现上,充分利用了linux系统中各种与网络相关的技术,支持第三方插件

Neutron中常用的术语

Bridge-int:综合网桥,常用于实现内部网路通讯功能的网桥

Br-ex:外部网桥,通常用于跟外部网络通讯的网桥。

Neutron-server:提供了API接口,将配置好的API接口,提供给相关的插件,进行后续处理

Neutron-L2-agent:二层代理,用于实现二层网络通讯的代理,用于管理VLAN的插件,接受Neutron-server的指令来创建VLAN。

Neutron-DHCP-agent:为子网自动分发IP地址

Neutron-L3-agent:负责租户网络和floating IP之间的地址转换,通过linux iptables 中的NAT功能来实现IP转换

Neutron-metadata-agent:运行在网络节点上,用来响应nova中的metadata请求

LBaaS agent:为堕胎实例和open vswitch agent提供负载均衡服务

Neutron架构



当Neutron通过API接口,接受来自用户或者其他组件的网络请求时,以消息队列的方式提交给2、3层代理,其中Neutron-DHCP-agent实现子网的创建和IP地址的自动分发。而Neutron-L2-agent实现相同VLAN下,网络的通信,Neutron-L3-agent实现同一个租户网络下不同子网间的通信

Glance

主要功能:

为Nova提供镜像服务

通常不包括镜像的本地存储

实现对镜像的管理

支持格式

Raw、vhd、vdi、iso、qcow2、aki ami

组件

Glance-api :负责提供镜像服务的rest api服务

Glance-registry: 负责与glance使用的数据库交互

Glance架构



当有来自Cli命令或horizon发送过来的镜像请求,由Glance-api进行处理,传递给组件Glance-registry,然后到数据库中查询镜像信息,将查询到的结果返回给用户。接下来将会调用组件Glance-registry进行查询,用来查询后端的存储,最终获取镜像返回给用户。

Cinder

主要功能:

为虚拟机实例提供volume卷的块存储服务

一个volume可以同时挂载到多个实例上

共享的卷同时只能被一个实例进行写操作

支持文件系统类型

LVM/ISCSI,NFS,NETAPP NFS,Gluster,DELL Equall Logic

常用术语

Volume备份:volume卷的备份

volume快照:某个时间点的状态

Cinder Api :为Cinder请求提供统一风格的Rest Api服务

Cinder Scheduler:负责为新建卷指定块存储设备

Cinder Volume:负责与存储的块设备交互,实现卷操作

Cinder Backup:备份服务,负责通过后端和驱动的备份设备打交道

Cinder架构



用户或者Nova提出请求,Cinder Api接收请求并通过消息队列的方式将请求提交给Cinder Scheduler来调用,Cinder Scheduler到数据库中查询,并通过相应策略选择最佳Volume节点,将结果反馈给Scheduler Service调用,Service 通过Volume Providers创建相关的卷,并把结果反馈给用户,同时,也会更新数据库.

Ceilometer

主要功能:

为计费、监控等其他的服务提供数据支撑。

Ceilometer的核心概念

Ceilometer-agent-compute:运行在计算节点上,是收集计算节点上信息的代理

Ceilometer-agent-central:运行在控制节点上,轮询服务的非持续化数据

Ceilometer-collector:运行在一个或者多个控制节点上,监听Message Bus【消息总线】,将收到的信息写入到数据库中

Storage:数据存储,支持mongo DB,mysql等等。用于存储收集到的样本数据

API server:运行在控制节点上,提供对数据库的数据的访问

Message Bus:计量数据的消息总线,收集数据给Ceilometer-collector

Ceilometer架构



Ceilometer采用了两种数据采集的方式,其中一种是消费了open stack内各个服务自动发出的notification消息,【图中的蓝色箭头】,另外一种是调用各个服务的API,去主动轮询获取数据。【图中的黑色箭头】

为什么采用两种数据采集的方式?

因为在open stack 中,大部分事件都会发出notification消息,比如创建删除instance实例的时候,这些计量计费的信息时,都会发出notification消息。而作为Ceilometer组件,就是notification消息的最大的消费者。因此,第一种方式,是Ceilometer的首要的数据来源。

但是,也有一些计量的消息,是notification获取不到的,比如一些instance的CPU的运行时间,或者是CPU的使用率等等。因此,Ceilometer增加了第二种方式,即为周期性的调用相关的API,去轮询这些消息。

Heat

主要功能

OpenStack核心项目之一

提供基于模板的编排任务

常用术语:



Heat组件



Heat架构



内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: