从KVM虚拟化到Openstack云化架构综述

目录

摘要

OpenStack的虚拟化技术

OpenStack架构介绍

Nova

Swift

KeyStone

Neutron

Glance

Cinder

Ceilometer

Heat


摘要

这两年的工作中,接触到公有云和私有云的项目还不少。起初对于Openstack的了解,仅停留在其几大组件的交互上,如Nova、Neutron、Glance等,以及对各大云厂商功能点上。随着项目的深入,慢慢发觉了解组件的交互,虽然对于做项目来说基本够用,但做为一名负责人的售前同学,总觉得需要进一步理清楚,Openstack使用到的相关虚拟层技术,如KVM、QEMU、SDN等。本篇文章,已经在要总结的任务中delay了很久,今天下定决心,集网上多篇文章,整理从KVM虚拟化到Openstack的云化架构综述,希望各位同学多提建议。(下一篇文档,估计要写写AI相关的语音、视觉、NLP和知识图谱相关的了)


Openstack是一个云管平台,不是一项技术,这可能是一名非计算机专业的小白容易搞混的问题。计算、存储和网络的虚拟化,由底层hypervisor,如KVM、Qemu、Xen等提供。其实所谓的管理平台,主要是为了方便大家使用。如果没有OpenStack,同样可以通过virsh、virt-manager来创建虚拟机,只不过敲命令行的方式,就像windows之前的doc命令输入一样,需要一定的学习成本,对于普通用户的操作不是很便利。说到虚拟化,我们简单看一下虚拟化的分类,以及常见的Hypervisor,KVM和Xen的区别。

OpenStack的虚拟化技术

在OS中加入一个虚拟化层(VMM),虚拟化层可以对下层(HostOS)硬件资源(物理CPU、内存、磁盘、网卡、显卡等)进行封装、隔离,抽象为另一种形式的逻辑资源,再提供给上层(GuestOS)使用。所以你可以理解VMM其实就是联系HostOS和GuestOS的一个中间件,当然虚拟化可以将一份资源抽象为多份,也可以将多份资源抽象为一份。通过虚拟化技术实现的虚拟机一般被称之为GuestOS(客户),而作为GuestOS载体的物理主机称之为HostOS(宿主)。

现在市场上最常见的虚拟化软件有VMWare workstation(VMWare)、VirtualBox(Oracle)、Hyper-V(Microsoft)、KVM(Redhat)、Xen等,这些软件统称之为VMM(Virtual Machine Monitor),使用不同的虚拟化实现。而这些虚拟化实现的方式可以分为: 

  • 全虚拟化:也成为原始虚拟化技术,该模型使用虚拟机协调guest操作系统和原始硬件,VMM在guest操作系统和裸硬件之间用于工作协调,一些受保护指令必须由Hypervisor(VMM 虚拟机管理程序)来捕获处理。既VMM会为GuestOS抽象模拟出它所需要的包括CPU、磁盘、内存、网卡、显卡等抽象硬件资源,所以全虚拟化的GuestOS并不会知道自己其实是一台虚拟机。全虚拟化的运行速度要快于硬件模拟,但是性能方面不如裸机,因为Hypervisor需要占用一些资源。典型的全虚拟化软件有:VMWare、Hyper-V、KVM-x86(复杂指令集)。

从KVM虚拟化到Openstack云化架构综述_第1张图片

全虚拟化的两种实现方式:

 1、基于二进制翻译的全虚拟化;2、基于扫描和修补的全虚拟化。

  • 半虚拟化:是另一种类似于全虚拟化的技术,它使用Hypervisor分享存取底层的硬件,但是它的guest操作系统集成了虚拟化方面的代码。该方法无需重新编译或引起陷阱,因为操作系统自身能够与虚拟进程进行很好的协作。典型的半虚拟化软件有:Xen、KVM-PowerPC(简易指令集)半虚拟化除了修改内核外还有另外一种实现方法–在每一个GuestOS中安装半虚拟化软件:VMTools、RHEVTools。

从KVM虚拟化到Openstack云化架构综述_第2张图片

接下来,看下常见的KVM和Xen的区别,也从另外一种说法,来旁观下虚拟化技术分类。

虚拟化是通过Hypervisor程序实现的,Hypervisor的作用是将硬件虚拟化提供给多个操作系统使用,是虚拟化技术的核心。
虚拟化分为两种:1型虚拟化2型虚拟化

  1. 型虚拟化是将Hypervisor直接安装在物理机上,然后虚拟机直接运行在Hypervisor上,Xen就是属于1型虚拟化
  2. 型虚拟化是先在硬件上安装操作系统,然后将Hypervisor作为系统的一个程序运行在系统上从而实现对虚拟机的管理,KVM就是属于2型虚拟化

从KVM虚拟化到Openstack云化架构综述_第3张图片

先来看一下KVM,KVM是基于Linux内核实现的,KVM的内核模块叫做kvm.ko,实现对Linux的CPU和内存虚拟化,是Linux的一个进程,负责VCPU内存的分配,而其他设备的虚拟就交给了qemu。QEMU提供一系列的硬件模拟设备(CPU,网卡,磁盘等),客户机指令都需要QEMU翻译,因而性能较差。KVM是linux内核提供的虚拟化,可以用来进行vCPU的创建与运行,虚拟内存的地址空间分配,指令执行效率较高,但缺少IO设备的虚拟化。QEMU-KVM就是KVM与QEMU的结合,KVM负责CPU虚拟化+内存虚拟化,QEMU模拟其它IO设备。qemu运行在用户空间,KVM运行在内核,两者通过/dev/kvm进行交互。KVM仅支持全局虚拟化。

https://upload-images.jianshu.io/upload_images/3143954-cdde1444c6a86c60.jpg?imageMogr2/auto-orient/strip%7CimageView2/2

KVM加上QEMU后就是完整意义上的服务器虚拟化。综上所述,QEMU-KVM具有两大作用:

  1. 提供对cpu,内存(KVM负责),IO设备(QEMU负责)的虚拟
  2. 对各种虚拟设备的创建,调用进行管理(QEMU负责)

从KVM虚拟化到Openstack云化架构综述_第4张图片

再来看一下XenXen支持全虚拟化和半虚拟化,(全虚拟化就是运行在虚拟环境的虚拟机无法感知到自己是运行在虚拟环境之上,只会觉得自己是运行在硬件之上,半虚拟化是运行在虚拟环境的虚拟机可以感知到自己不是直接运行在硬件环境之上)这一点不同于KVM的仅支持全局虚拟化。Xen是直接运行在硬件上的,也就是上面提到的1型虚拟化,直接对硬件进行虚拟化,然后在硬件之上直接跑虚拟机,在Xen架构中的虚拟机分为两种:Domain0DoaminU.Domain0又叫做特权虚拟机,具有直接访问硬件和管理其他操作系统的权限,而DoaminU就是普通的虚拟机,DoaminU不能直接访问硬件,所有的操作都是通过驱动发送到特权虚拟机Domain0,由Domain0去和硬件交互再返回给普通用户,所以,Xen架构的虚拟化需要先运行Domain0Xen架构也是对CPU内存进行虚拟化,提供给虚拟机用,其余硬件访问是通过特权虚拟机直接与硬件进行交互再返回的。

OpenStack架构介绍

网上介绍Openstack架构的文章太多,再这就不再过多总结,引用文章From:https://blog.csdn.net/lks1139230294/article/details/67152854 。在此,简单描述一点就是Neutron的OVS和SDN,可能是有一些关系。

Neutron添加了一层虚拟的网络服务让租户(用户)构建自己的虚拟网络。Neutron是对网络的虚拟化,该网络可以从一个地方移动到另一个地方,而不会影响现有的连接。它可以进一步解释为一个网络管理服务,为创建和管理虚拟网络公开了一组可扩展的API(通过创建虚拟网络为OpenStack Compute节点上的虚拟机提供网络服务)。Neutron的插件架构为开源社区或第三方服务提供API。Neutron还允许供应商研究和添加新的插件,提供先进的网络功能。目前,Neutron的虚拟网络服务没有传统网络成熟,组成Neutron的元素如下:

Neutron-server是实现OpenStack网络功能的的主要部件。Plugin agents和Neutron插件一起管理虚拟交换机,Plugin agents依赖Neutron插件。DHCP agent是Neutron的一部分,为租户的网络提供DHCP服务。L3 agent负责3层功能和NAT转发来获得租户虚拟机的外部访问。
引入SDN主要是克服Neutron的缺陷,SDN是一种网络技术,通过集中的可编程控制平面来管理整个数据平面。这样网络运营商和供应商可以控制和管理自己的虚拟化资源和网络。SDN是一种新型的网络模式,允许硬件和操作系统之间以及物理/虚拟网元和操作系统之间通过开放API通信。

接下来看下OpenStack的架构。

OpenStack主要分为Nova.Glance.Swift,Cinder等,实际上是由一组离散服务组成的.尽管新组件更多的是面向业务的,但是OpenStack还是可以提供构建网络的基础设施和运行通用虚拟机的.OpenStack支持包括公有云,私有云,混合云的部署方式。

OpenStack三大组件:计算,网络,存储

Nova

  1. 实现实例的生命周期的管理 
  2. 调动管理平台的网络、存储等资源 
  3. 提供了统一风格的 RestAPI接口 
  4. 支持KVM、VMware等透明的hypervisor 
  5. 各个模块之间通过消息队列来进行消息传递

常用术语:
KVM:内核虚拟化,OpenStack默认的是Hypersvisor 
Qemu:KVM的替补角色,没有KVM效率高,不支持全虚拟化 
Flavor:新建虚拟机的配置列表,虚拟机模板 
Keypair:ssh连接访问实例的密钥对 
安全组:用来控制实例访问策略的容器 
安全组规则:用来控制访问的具体实例

Nova框架:

从KVM虚拟化到Openstack云化架构综述_第5张图片

Nova Api:提供统一rest-Api风格Api接口,作为Nova组件的入口,接受用户的请求 
Nova scheduler :负责调度,将实例分配到具体计算节点 
Nova conductor:负责Nova与数据库进行交互 
Nova compute:用于虚拟机实例的创建和管理 
Message Queue:Nova各个组件之间的信息传递

Nova工作原理:

从KVM虚拟化到Openstack云化架构综述_第6张图片

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

Swift

  1. 实现高可用分布式对象存储 
  2. 为Nova组件提供虚拟机镜像存储 
  3. 适用于互联网应用场景下非结构化数据存储

常用术语:
Account:用户的管理存储区域 
Container:存储隔间,类似于文件夹或目录 
Object:包含了基本的存储实体和它本身的元数据 
Ring:记录了磁盘上存储的实体名称和物理位置映射关系 
用户可以创建多个Account,每个account里可以创建多个容器container,每个container下可以创建多个object.【container 之间不能相互嵌套】 
Region:地域,从地理位置上划分的一个概念 
Zone:可用区,按照独立的供网,供电基础设施划分 
Node:节点,存储服务器 
Disk:磁盘,物理服务器上的存储设备 
Cluster:为冗余考虑的部署架构 
不同的region代表不同的城市,然后在同一个region下,为冗余的考虑,设置了多个可用区zone。每一个可用去可以有不同的存储节点node;在更大的架构上,两个region可以构成一个cluster。

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

Swift架构

从KVM虚拟化到Openstack云化架构综述_第7张图片

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

KeyStone

  1. 提供身份验证、服务规则和服务令牌功能 
  2. 任何服务之间相互调用,都需要经过keystone的身份验证

常用术语:
User:Openstack最基本的用户 
Project:指分配给使用者的资源的集合 
Role:代表一组用户可以访问组员的权限 
Domain:定义管理边界,可以包含多个project/tenant、user、role等 
Endpoint:服务的URL路径,暴露出来的访问点 
每个Domain对应多个Project,Project对应多个用户,用户可以跨Project存在

认证原理

从KVM虚拟化到Openstack云化架构综述_第8张图片

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

Neutron

  1. 提供网络服务的核心组件 
  2. 基于软件定义网络的思想 
  3. 实现软件化的网络资源管理,在实现上,充分利用了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架构

从KVM虚拟化到Openstack云化架构综述_第9张图片

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

Glance

  1. 为Nova提供镜像服务 
  2. 通常不包括镜像的本地存储 
  3. 实现对镜像的管理

支持格式
Raw、vhd、vdi、iso、qcow2、aki ami

组件
Glance-api :负责提供镜像服务的rest api服务 
Glance-registry: 负责与glance使用的数据库交互

Glance架构

从KVM虚拟化到Openstack云化架构综述_第10张图片

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

Cinder

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

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

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

支持文件系统类型
LVM/ISCSI,NFS,NETAPP NFS,Gluster,DELL Equall Logic

常用术语
Volume备份:volume卷的备份 
volume快照:某个时间点的状态 
Cinder Api :为Cinder请求提供统一风格的Rest Api服务 
Cinder Scheduler:负责为新建卷指定块存储设备 
Cinder Volume:负责与存储的块设备交互,实现卷操作 
Cinder Backup:备份服务,负责通过后端和驱动的备份设备打交道

Cinder架构

从KVM虚拟化到Openstack云化架构综述_第11张图片

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

Ceilometer

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

Ceilometer的核心概念
Ceilometer-agent-compute:运行在计算节点上,是收集计算节点上信息的代理 
Ceilometer-agent-central:运行在控制节点上,轮询服务的非持续化数据 
Ceilometer-collector:运行在一个或者多个控制节点上,监听Message Bus【消息总线】,将收到的信息写入到数据库中 
Storage:数据存储,支持mongo DB,mysql等等。用于存储收集到的样本数据 
API server:运行在控制节点上,提供对数据库的数据的访问 
Message Bus:计量数据的消息总线,收集数据给Ceilometer-collector

Ceilometer架构

从KVM虚拟化到Openstack云化架构综述_第12张图片

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

为什么采用两种数据采集的方式?
因为在open stack 中,大部分事件都会发出notification消息,比如创建删除instance实例的时候,这些计量计费的信息时,都会发出notification消息。而作为Ceilometer组件,就是notification消息的最大的消费者。因此,第一种方式,是Ceilometer的首要的数据来源。 
但是,也有一些计量的消息,是notification获取不到的,比如一些instance的CPU的运行时间,或者是CPU的使用率等等。因此,Ceilometer增加了第二种方式,即为周期性的调用相关的API,去轮询这些消息。

Heat


OpenStack核心项目之一 ,提供基于模板的编排任务

常用术语:

从KVM虚拟化到Openstack云化架构综述_第13张图片


Heat组件

从KVM虚拟化到Openstack云化架构综述_第14张图片


Heat架构

从KVM虚拟化到Openstack云化架构综述_第15张图片

本次大概就这些内容,接下里,我想想AI方向,从哪个子方面来切入。

 

 

你可能感兴趣的:(云计算)