当前位置：首页 > news >正文

OpenStack开源虚拟化平台（一）

news 文章来源：https://blog.csdn.net/Morse_Chen/article/details/140102615 2024/7/4 4:35:30

一、OpenStack背景介绍

在这里插入图片描述

（一）OpenStack是什么

在这里插入图片描述
OpenStack是一个管理计算、存储和网络资源的数据中心云计算开放平台，通过一个仪表板，为管理员提供了所有的管理控制，同时通过Web界面为其用户提供资源。

在这里插入图片描述

（二）OpenStack的主要服务

OpenStack有三个主要的服务成员：计算服务（Nova）、存储服务（Swift）、镜像服务（Glance）。

在这里插入图片描述
1. 计算服务Nova

Nova是OpenStack云计算架构的控制器，支持OpenStack云内的实例的生命周期所需的所有活动由Nova处理。Nova作为管理平台管理着OpenStack云里的计算资源、网络、授权和扩展需求。但是，Nova不能提供本身的虚拟化功能，相反，它使用Libvint的API来支持虚拟机管理程序交互。Nova通过Web服务接口开放所有功能并兼容亚马逊Web服务的EC2接口。

2. 对象存储服务Swift

Swift提供的对象存储服务，允许对文件进行存储或者检索（但不通过挂载文件服务器上目录的方式来实现）。对于大部分用户来说，Swift不是必需的，只有存储数量达到一定级别，而且是非结构化数据才有这样的需求。Swift为OpenStack提供了分布式的、最终一致的虚拟对象存储。和亚马逊的Web服务–简单存储服务(S3)类似，通过分布式的存储节点，Swift 有能力存储数士亿计的对象，Swift具有内置冗余、容错管理、存档、流媒体的功能。Swift是高度扩展的。

3. 镜像服务Glance

它提供了一个虚拟磁盘镜像的目录和存储仓库，可以提供对虚拟机镜像的存储和检索。这些磁盘镜像广泛应用于Nova组件之中。Glance能进行多个数据中心的镜像管理和租户私有镜像管理。虽然这种服务在技术上是属于可选的，但任何规模的云都可能对该服务有需求。目前Glance的镜像存储，支持本地存储、NFS、Swift、sheepdog和Ceph。OpenStack镜像服务查找和检索虚拟机的镜像系统，它可以被配置为使用以下3个存储后端的任何一个：
（1）OpenStack对象存储到存储镜像。
（2）S3存储直连。
（3）S3存储结合对象存储成为中间级的S3访问。

4. 身份认证服务keystone

它为OpenStack上的所有服务提供身份验证和授权。它还提供了在特定OpenStack云服务上运行的服务的一个目录。任何系统中，身份认证和授权其实都比较复杂，尤其是Openstack那么庞大的项目，每个组件都需要使用统一认证和授权。

5. 网络管理服务Quantum

在接口设备之间提供“网络连接即服务”的服务，而这些接口设备主要是由Open Stack的其他服务（如Nova）进行管理的。该服务允许用户创建自己的网络，然后添加网络接口设备。Quantum提供了一个可插拔的体系架构，使其能够支持很多流行的网络供应商和新的网络技术。Quantum后端可以是商业产品或者开源。开源产品支持Openvswitch和Linux bridge。网络设备厂商都在积极参与，让他们的产品支持Quantum，目前思科、锐捷已经实现支持。

6. 存储管理服务Cinder

Cinder存储管理主要是指虚拟机的存储管理，Swift主要是对象存储管理。目前支持开源和商业化产品sheepdog、Ceph等。
对于企业来说，使用分布式作为虚拟机的存储，并不能真正节省成本，维护一套分布式存储，成本还是很高的。目前虚拟机的各种高可用、备份的问题，其实都可以把问题交给商业存储厂商来解决。

7. 仪表盘Horizon

严格意义来说，Horizon不会为OpenStack增加一个功能，更多的是一个演示。对于很多用户来说，了解Open Stack基本都是从Horizon、 dashboard开始。从这个角度来看，它在OpenStack各个项目里显得非常重要。

二、计算服务Nova

Nova是OpenStack云中的计算组织控制器。Nova处理OpenStack云中实例（instances）生命周期的所有活动。这样使得Nova成为一个负责管理计算资源、网络、认证、所需可扩展性的平台。
但是，Nova并不具有虚拟化能力，相反它使用Libvirt API来与被支持的Hypervisors交互。Nova通过一个与Amazon Web Services（AWS）EC2 API兼容的Web Services API来对外提供服务。

（一）Nova组件介绍

1. API Server（Nova-Api）

API Server对外提供一个与云基础设施交互的接口，也是外部可用于管理基础设施的唯一组件。

2. Message Queue（Rabbit MQ Server）

OpenStack节点之间通过消息队列使用AMQP（Advanced Message Queue Protocol）完成通信。

3. Compute Worker（Nova-Compute）

Compute Worker管理实例生命周期，通过Message Queue接收实例生命周期管理的请求，并承担操作工作。

4. Network Controller（Nova-Network）

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

5. Volume Workers（Nova-Volume）

Volume Workers用来管理基于LVM（Logical Volume Manager）的实例卷。Volume Workers有卷的相关功能，例如新建卷、删除卷、为实例附加卷、为实例分离卷。

6. Scheduler（Nova-Scheduler）

调度器Scheduler把Nova-API调用映射为OpenStack组件。调度器作为一个Nova-Schedule守护进程运行，通过恰当的调度算法从可用资源池获得一个计算服务。当前Nova-Schedule实现了一些基本的调度算法：随机算法、可用域算法和简单算法。

（二）Libvirt简介

Nova通过独立的软件管理模块实现XenServer、Hyper-V和VMWare ESX的调用与管理。同时对于其他的Hypervisor，如KVM、LXC、QEMU、UML和Xen则通过Libvirt标准接口统一实现。为了更好地理解在Nova环境下Libvirt如何管理底层的Hypervisor，先要基本了解Libvirt的体系架构与实现方法。

1. 什么是Libvirt

虚拟云实现的三部曲：虚拟化技术实现→虚拟机管理→集群资源管理（云管理）。各种不同的虚拟化技术都提供了基本的管理工具，比如启动、停用、配置、连接控制台等。这样在构建云管理的时候就存在两个问题。
（1）如果采用混合虚拟技术，上层就需要对不同的虚拟化技术调用不同管理工具，很是麻烦。
（2）可能有新的虚拟化技术更加符合现在的应用场景，需要迁移过去。这样管理平台就需要大幅改动。
Libvirt的主要目标是为各种虚拟化工具提供一套方便、可靠的编程接口，用一种单一的方式管理多种不同的虚拟化提供方式。

2. Libvirt主要支持的功能

（1）虚拟机管理：包括不同的领域生命周期操作，支持多种设备类型的热插拔操作。
（2）远程机器支持：只要机器上运行了Libvirt Daemon，所有的Libvirt功能就都可以访问和使用。
（3）存储管理：任何运行了Libvirt Daemon的主机都可以用来管理不同类型的存储,创建不同格式的文件镜像。
（4）网络接口管理：任何运行了Libvirt Daemon的主机都可以用来管理物理和逻辑的网络接口。
（5）虚拟NAT和基于路由的网络：任何运行了Libvirt Daemon的主机都可以用来管理和创建虚拟网络。

3. Libvirt体系结构

没有使用Libvirt的虚拟机管理方式：

在这里插入图片描述
Libvirt API与相关驱动程序的层次结构：

在这里插入图片描述
Libvirt的控制方式有以下两种。
（1）管理位于同一节点上的应用程序和域。管理应用程序通过Libvirt工作，以控制本地域。

在这里插入图片描述
（2）管理位于不同节点上的应用程序和域。该管理应用程序通过一种通用协议从本地Llibvirt连接到远程Libvirt。

在这里插入图片描述

（三）Nova中的RabbitMQ解析

在这里插入图片描述
1. RabbitMQ

在这里插入图片描述
RabbitMQ是一种处理消息验证、消息转换和消息路由的架构模式，它协调应用程序之间的信息通信，并使得应用程序或者软件模块之间的相互意识最小化，有效实现解耦。
RabbitMQ适合部署在一个拓扑灵活易扩展的规模化系统环境中，有效保证不同模块、不同节点、不同进程之间消息通信的时效性；RabbitMQ特有的集群HA安全保障能力可以实现信息枢纽中心的系统级备份，同时单节点具备消息恢复能力。

在这里插入图片描述
2. AMQP

AMQP是应用层协议的一个开放标准，为面向消息的中间件而设计
RabbitMQ是AMQP协议的一个开源实现
OpenStack Nova各软件模块通过AMQP协议实现信息通信
AMQP协议的设计理念可归纳为基于状态的面向无连接通信系统模式
对于AMQP来讲，消息队列的状态信息决定通信系统的转发路径
IP数据包根据路由表实现报文的本地存储与逐级转发

在这里插入图片描述
“消息”是AMQP实现通信的基本因素，交换器和队列是AMQP的核心要素。
交换器（Exchange）：交换器由消费者应用程序创建，并且可与其他应用程序实现共享服务。接收消息之后通过路由表将消息准确且安全地转发至相应的消息队列。每个交换器通过唯一的Exchange ID进行识别。交换器主要分为三种：
（1）持久交换器：持久交换器并不会因为系统重启或者应用程序终止而消除
（2）临时交换器：驻留在内存中，随着系统的关闭而消失
（3）自动删除交换器：随着宿主应用程序的中止而自动消亡
队列（Queue）：主要用于实现存储与转发交换器发送来的消息，队列同时也具备灵活的生命周期属性配置，可实现队列的持久保存、临时驻留与自动删除。
消息、队列和交换器是构成AMQP的三个关键组件，任何一个组件的失效都会导致信息通信的中断，因此鉴于三个关键组件的重要性，系统在创建三个组件的同时会打上“Durable”标签，表明在系统重启之后立即恢复业务功能。

构成AMQP的三个关键要素的工作方式如图所示。

在这里插入图片描述
三种不同类型的交换器：广播式交换器（Fanout Exchange）、直接式交换器（Direct Exchange）和主题式交换器（Topic Exchange）。

3. Nova中的RabbitMQ应用

在这里插入图片描述
目前Nova中的各个模块通过RabbitMQ服务器以RPC（远程过程调用）的方式实现通信，而且各模块之间形成松耦合关联关系，在扩展性、安全性以及性能方面均体现优势。以下是三个比较重要的概念。
（1）交换器
接受消息并且将消息转发给队列。应用程序在它的权限范围之内可以创建、删除、使用和共享交换器实例。交换器可以是持久的、临时的或者自动删除的。
（2）队列
“消息队列”，它是一个具名缓冲区，它代表一组消费者应用程序保存消息。这些应用程序在它们的权限范围内可以创建、使用、共享消息队列。
（3）绑定
可以理解为交换器和消息队列之间的一种关系，绑定之后交换器会知道应该把消息发给哪个队列，绑定的关键字称为binding_key。

下面介绍一下RabbitMQ的三种类型的交换器。

1）广播式交换器类型（fanout）

该类交换器不分析所接收到消息中的Routing Key，默认将消息转发到所有与该交换器绑定的队列中去。广播式交换器转发效率最高，但是安全性较低，消费者应用程序可获取本不属于自己的消息。
广播交换器是最简单的一种类型，就像我们从字面上理解到的一样，它把所有接收到的消息广播到所有它所知道的队列中去，不论消息的关键字是什么，消息都会被路由到和该交换器绑定的队列中去。

在这里插入图片描述
在程序中申明一个广播式交换器的代码如下：

channel.exchange_declare（exchange='fanout',type='fanout'）

2）直接式交换器类型（direct）

直接式交换器的转发效率较高，安全性较好，但是缺乏灵活性，系统配置量较大。相对广播交换器来说，直接交换器可以给我们带来更多的灵活性。
直接交换器的路由算法很简单：一个消息的routing_key完全匹配一个队列的binding_key，就将这个消息路由到该队列。绑定的关键字将队列和交换器绑定到一起。当消息的routing_key和多个绑定关键字匹配时消息可能会被发送到多个队列中。

在这里插入图片描述
3）主题式交换器（Topic Exchange）

在这里插入图片描述
Nova基于RabbitMQ实现两种RPC调用：RPC.CALL基于请求与响应方式，RPC.CAST只是提供单向请求。
Nova的各个模块在逻辑功能上可以划分为两种：Invoker模块主要功能是向消息队列中发送系统请求消息，如Nova-API和Nova-Scheduler；Worker模块从消息队列中获取Invoker模块发送的系统请求消息以及向Invoker模块回复系统响应消息，如Nova-Compute、Nova-Volume和Nova-Network。

在这里插入图片描述

交换器和队列之间的通信关系

在这里插入图片描述

RPC.CALL的调用流程

（1）Invoker端生成一个Topic消息生产者和一个Direct消息消费者。其中，Topic消息生产者发送系统请求消息到Topic交换器，Direct消息消费者等待响应消息。
（2）Topic交换器根据消息的Routing Key转发消息，Topic消费者从相应的消息队列中接收消息，并传递给负责执行相关任务的Worker。
（3）Worker根据请求消息执行完任务之后，分配一个Direct消息生产者，Direct消息生产者将响应消息发送到Direct交换器。
（4）Direct交换器根据响应消息的Routing Key转发至相应的消息队列，Direct消费者接收并把它传递给Invoker。

RPC.CAST的远程调用流程与RPC.CALL类似，只是缺少了系统消息响应流程。

在这里插入图片描述

RPC.CAST的远程调用流程

目录

一、OpenStack背景介绍

（一）OpenStack是什么

（二）OpenStack的主要服务

二、计算服务Nova

（一）Nova组件介绍

（二）Libvirt简介

（三）Nova中的RabbitMQ解析

相关文章：