浅谈云计算19 | OpenStack管理模块（上）

在这里插入图片描述

深入研究OpenStack的各个管理模块具有多方面的重要价值。在资源利用层面，通过对计算管理、存储管理等模块的优化，可以显著提升数据中心的资源利用率。以计算管理为例，通过合理的调度算法，能够确保计算资源被精准分配到最需要的任务上，避免资源的闲置与浪费。在运维效率方面，对编排管理、故障管理等模块的深入研究与应用，能够实现自动化的资源部署与高效的故障处理。编排管理模块可依据预设的模板和策略，快速完成复杂的云环境搭建，大大节省部署时间；而故障管理模块则能够实时监测系统状态，一旦发现故障便迅速做出响应，最大程度减少故障对业务的影响。

从宏观角度看，对OpenStack管理模块的深入探究，有助于推动整个云计算行业的技术进步，为构建更加智能、高效、可靠的云平台奠定坚实基础。

在这里插入图片描述

一、操作界面管理架构

OpenStack 的操作界面管理借助 Horizon 组件，提供基于 Web 的可视化管理平台，方便管理员与租户和各项服务交互，降低了操作门槛，使非专业人员也能完成复杂云管理任务。在架构方面，Horizon 作为连接用户与后端服务的关键组件，和 Nova、Glance 等核心组件紧密协作，通过 API 接口获取信息展示给用户，并传递用户操作指令，以实现对云资源的管理与控制。

在这里插入图片描述

Horizon 包含多个紧密协作的子组件，共同实现云资源的全面管理。

仪表盘：作为核心组件，像信息中枢，汇总呈现云环境整体状态与资源使用情况。以图表形式展示计算资源（如已用 CPU 核心数、内存量及剩余资源）、存储资源（存储卷容量、已用 / 剩余空间、设备健康状态），以及网络拓扑简化图、网络流量数据，助用户了解网络运行状态。

虚拟机管理组件：是管理虚拟机的关键部分。支持用户从 Glance 镜像库选镜像创建虚拟机，确定 CPU、内存、磁盘等规格。启动后，可实时监控 CPU 使用率、内存与磁盘读写等性能指标。还能对虚拟机执行停止、重启、删除等操作，以及调整内存、增减网络接口来修改配置。

网络管理组件：功能强大灵活。创建虚拟网络时，可定义名称、IP 范围、子网掩码、网络类型。能创建多个子网，分配不同 IP 段，满足不同业务需求。在路由器管理上，可创建配置路由器，设置网关和路由规则，实现网络间互联互通。同时，可创建安全组，设置访问规则保障虚拟机网络安全。

存储管理组件：负责管理云存储资源。用户可创建存储卷，指定大小、名称、所属项目。创建后，将其挂载到虚拟机用于存储读取数据。数据量增加时可扩容，还支持对存储卷快照，便于数据备份和恢复。

用户管理组件：专注于身份认证和权限管理。支持用户名密码、令牌等多种认证方式，通过与 Keystone 服务验证确认用户身份。管理员能在此创建不同用户角色，分配相应权限，如管理员有所有云资源控制权，普通用户仅能管理自己的虚拟机，实现对用户访问云资源的精细管控，保障系统安全。

二、认证管理

2.1 定义与作用

OpenStack 的认证管理主要由 Keystone 组件负责，它是云平台默认的身份管理系统，提供身份验证、授权及服务目录管理功能。在 OpenStack 架构里，Keystone 就像门禁，只有通过身份验证的用户，才能获取权限操作计算、存储、网络等云资源。

从技术层面看，Keystone 通过多种机制保障认证安全。它支持多种认证方式，满足不同需求。常见的用户名 / 密码认证，用户输入信息后，Keystone 与数据库中的用户信息比对来确认身份。API 密钥认证适用于编程访问云资源，用户在 API 请求中携带密钥，由 Keystone 验证其有效性。此外，为满足更高安全需求，Keystone 还支持 Kerberos 这种基于票据的高级认证，能在分布式环境中提供强大的身份验证与授权，确保复杂网络环境下云平台的安全。

在 OpenStack 生态系统中，认证管理起着核心作用：安全防护上，通过严格身份验证防止非法用户恶意访问云资源，在多租户环境为各租户分配独立身份标识和权限，保障数据安全与隔离；资源访问控制方面，以 Keystone 基于用户角色和所属租户分配权限，采用 RBAC 模型实现精细化控制，规范高效管理资源访问，避免权限滥用；同时，为 Nova、Glance、Neutron 等其他组件提供统一认证服务，各组件接收到用户请求后先由 Keystone 验证，确认合法且有权限才执行，确保各组件协同工作安全有序，提升云平台运行效率与稳定性。

2.2 认证原理与流程

2.2.1 认证机制原理

OpenStack的认证机制涵盖多种方式，以满足不同场景下的安全需求。基于用户名/密码的认证方式是最为基础且常见的。在这种方式下，用户在登录界面输入预先设置的用户名和密码，系统会将这些信息发送至Keystone的身份验证模块。该模块会从存储用户信息的数据库中检索对应的记录，通常数据库中存储的是经过加密处理的密码哈希值，以增强密码的安全性。通过将用户输入的密码进行相同加密算法的处理，再与数据库中的密码哈希值进行比对，若两者一致，则确认用户身份合法，允许用户访问云资源。

在这里插入图片描述

令牌（Token）认证机制则在现代云计算环境中发挥着重要作用。当用户通过用户名/密码等方式成功进行身份验证后，Keystone的令牌管理模块会生成一个唯一的令牌。这个令牌是一个包含丰富信息的字符串，其中涵盖了用户的身份标识、所属租户信息、拥有的权限范围以及令牌的有效期等关键信息。在后续的操作中，用户无需再次输入用户名和密码，只需在每次请求访问云资源时，携带这个令牌即可。OpenStack的其他服务在接收到用户请求时，会将令牌发送回Keystone的令牌管理模块进行验证。令牌管理模块会检查令牌的有效性，包括令牌是否由自己颁发、是否在有效期内以及令牌所包含的权限是否与用户请求的操作相匹配等。若验证通过，服务则会执行用户的请求，从而实现了高效、安全的无密码访问机制。

在这里插入图片描述

在一些对安全性要求极高的场景中，OpenStack还支持Kerberos认证机制。Kerberos是一种基于票据的认证协议，它通过引入可信的第三方认证服务器（KDC，Key Distribution Center）来实现用户身份的验证和服务授权。在Kerberos认证过程中，用户首先向KDC发送身份验证请求，KDC会对用户进行身份核实。若验证通过，KDC会生成一个包含用户身份信息和会话密钥的票据（Ticket），并将其发送给用户。用户在请求访问特定服务时，会将该票据连同自己的身份信息一起发送给服务端。服务端再将这些信息转发给KDC进行验证，KDC确认无误后，向服务端返回验证成功的信息，服务端才会为用户提供相应的服务。这种认证机制在分布式环境中具有强大的安全性和可靠性，能够有效防止票据被窃取和篡改，保障云平台在复杂网络环境下的安全运行。

2.2.2 用户认证流程

当用户发起登录请求时，首先会在登录界面（如Horizon的登录页面）输入用户名和密码。这些认证信息会被封装成符合RESTful规范的HTTP请求，发送至Keystone的API端点。Keystone的API接收到请求后，会迅速将其传递给身份验证模块。身份验证模块会按照预先设定的认证策略，首先尝试从数据库中查找与用户输入用户名匹配的记录。若找到匹配记录，会对用户输入的密码进行加密处理，并与数据库中存储的密码哈希值进行比对。若密码验证通过，身份验证模块会通知令牌管理模块为用户生成一个令牌。

令牌管理模块在生成令牌时，会将用户的身份信息、所属租户信息、用户角色以及令牌的有效期等信息编码到令牌中。生成的令牌会通过HTTP响应返回给用户，同时，用户的会话信息也会被创建和管理，通常会话信息中会包含令牌以及用户的相关身份标识等。用户在后续访问OpenStack的其他服务（如Nova、Glance、Neutron等）时，会在每个请求的头部或其他指定位置携带这个令牌。

在这里插入图片描述

以用户通过Nova服务创建虚拟机为例，当用户在Horizon界面发起创建虚拟机的请求时，Horizon会将请求连同用户的令牌一起发送给Nova服务。Nova接收到请求后，会立即将令牌转发给Keystone进行验证。Keystone的令牌管理模块会对令牌进行全面检查，包括令牌的格式是否正确、是否由自己颁发、是否在有效期内以及令牌所赋予的用户权限是否包含创建虚拟机的权限等。若令牌验证通过，Keystone会向Nova返回验证成功的信息以及用户的相关权限信息。Nova在接收到验证成功的信息后，会继续执行用户创建虚拟机的请求，与Glance服务交互获取所需镜像，与Neutron服务协作配置网络等，最终完成虚拟机的创建操作。若在任何一个环节中，令牌验证失败，如令牌过期或权限不足，Keystone会返回相应的错误信息，告知用户认证失败，服务也会拒绝执行用户的请求。

三、镜像管理

3.1 定义与功能

在 OpenStack 体系架构里，镜像管理至关重要，核心功能由 Glance 组件承担。它负责虚拟机镜像的存储、查询与检索，为虚拟机创建提供基础支持。虚拟机镜像包含可启动操作系统和预装软件，如同模板，助力用户快速创建特定配置的虚拟机实例。

技术实现上，Glance 提供 RESTful API 接口用于镜像操作。支持多种镜像格式，如 qcow2 有空间动态扩展、写时复制特性；raw 格式适用于对性能要求高的场景，虽读写性能好但空间分配不灵活；VMDK 格式方便不同虚拟化环境间镜像迁移。其操作功能丰富，涵盖上传、查询、下载、更新、删除以及共享，满足用户在镜像管理各环节的需求，提升资源利用效率与操作便捷性。

3.2 镜像服务架构

Glance的架构设计精巧且复杂，它主要由Glance API、Glance Registry以及存储后端等核心组件构成。Glance API作为对外提供服务的接口，承担着接收和处理用户请求的重任。无论是用户发起的镜像上传、下载、查询等操作请求，还是其他OpenStack组件（如Nova在创建虚拟机时对镜像的请求），都会首先抵达Glance API 。Glance API在接收到请求后，会依据请求的类型和内容，将其合理地分发给后续的处理模块。

在这里插入图片描述

Glance Registry则专注于镜像元数据的管理，这些元数据包含了镜像的名称、大小、格式、操作系统类型、创建时间等关键信息。它会将这些元数据存储到数据库中，通常采用MySQL等关系型数据库，以便于高效地查询和检索。当用户查询镜像时，Glance API会向Glance Registry发送查询请求，Glance Registry从数据库中检索出符合条件的镜像元数据，并将其返回给Glance API，再由Glance API将结果返回给用户。

在与存储服务的连接架构方面，Glance支持多种存储后端，以满足不同用户和场景的需求。其中，Swift对象存储是一种常用的存储后端选择。当使用Swift作为存储后端时，Glance与Swift之间通过特定的接口进行通信。在镜像上传过程中，Glance API会将接收到的镜像数据转发给Swift，Swift会按照其自身的存储机制，将镜像数据存储为对象，并返回给Glance一个存储位置的标识。在镜像下载时，Glance API会依据存储位置标识，从Swift中获取镜像数据，并返回给请求的用户或组件。

除了Swift，Glance还支持本地文件系统存储。在这种方式下，镜像文件直接存储在Glance节点的本地文件系统中。虽然这种存储方式相对简单直接，但在可扩展性和数据冗余方面存在一定的局限性。对于大规模的云平台，通常会优先选择具有高可靠性和扩展性的Swift对象存储或其他分布式存储方案。

3.3 工作原理与流程

3.3.1 镜像存储原理

当用户上传镜像到Glance时，其存储过程涉及多个组件的协同工作。以Swift对象存储作为后端存储为例，用户通过Glance API发起镜像上传请求，该请求会携带镜像的相关数据和元数据。Glance API接收到请求后，首先对元数据进行解析和验证，确保元数据的完整性和正确性。例如，检查镜像的名称是否符合规范，磁盘格式和容器格式是否被支持等。

验证通过后，Glance API会将镜像数据转发给Swift存储服务。Swift会依据自身的分布式存储架构，将镜像数据分割成多个对象，并计算每个对象的哈希值，以确保数据的完整性和一致性。这些对象会被分散存储到多个存储节点上，通过冗余存储机制，通常会在不同的存储节点上创建多个副本，如三个副本，以提高数据的可靠性和容错性。

在存储过程中，Swift会为每个存储的镜像对象分配一个唯一的标识符，这个标识符包含了对象的存储位置信息等关键内容。Glance Registry会将镜像的元数据（如镜像名称、大小、格式、创建时间、存储位置标识符等）存储到MySQL等关系型数据库中。这样，当需要查询或检索镜像时，Glance API可以通过查询Glance Registry获取镜像的元数据，进而根据元数据中的存储位置信息，从Swift存储服务中准确地获取镜像数据。

3.3.2 镜像检索流程

当用户或其他OpenStack组件（如Nova在创建虚拟机时）请求检索镜像时，首先会向Glance API发送包含查询条件的请求。这些查询条件可以是镜像的名称、ID、状态，或者特定的元数据属性等。例如，Nova在创建虚拟机时，会根据用户指定的镜像名称或ID，向Glance API发送检索请求。

Glance API接收到请求后，会对请求进行解析，并将查询请求转发给Glance Registry 。Glance Registry会在其管理的数据库中，依据查询条件进行精确的检索。若查询条件为镜像名称，Glance Registry会在数据库的镜像元数据记录表中，查找名称匹配的记录。如果查询条件涉及多个属性，如查找所有处于“active”状态且操作系统为Ubuntu的镜像，Glance Registry会执行相应的SQL查询语句，从数据库中筛选出符合条件的镜像元数据记录。

找到匹配的镜像元数据后，Glance Registry会将这些元数据返回给Glance API 。Glance API再根据元数据中的存储位置信息，与相应的存储后端（如Swift）进行交互。若存储后端为Swift，Glance API会依据存储位置标识符，从Swift中获取镜像数据。Swift会从其存储节点中读取镜像对象的数据，并将这些数据返回给Glance API 。

最终，Glance API会将检索到的镜像数据返回给请求的用户或组件。在这个过程中，如果检索过程中出现任何错误，如镜像不存在、存储后端无法访问等，Glance API会返回相应的错误信息，告知请求方检索失败的原因。

四、计算管理

4.1 定义与目标

在 OpenStack 生态体系中，计算管理由 Nova 组件负责，它是计算资源管理的核心模块。其职责是对虚拟机实例全生命周期进行管理，包括创建、启动、监控、调整、停止和删除等操作，同时合理分配与调度计算节点资源。技术实现上，Nova 构建了强大灵活的 API 体系，兼容 OpenStack 原生 Compute API 与 Amazon EC2 API，方便用户通过命令行或 Web 管理界面与之交互，处理各类虚拟机操作请求。

计算管理的目标一是实现计算资源高效利用，通过智能调度算法，依据计算节点负载、虚拟机需求和用户优先级等因素，将虚拟机精准分配到合适节点，避免资源浪费。二是保障虚拟机性能稳定，实时监控运行状态，一旦性能异常波动，如 CPU 使用率过高或内存不足，就迅速采取资源调整或迁移等措施。三是致力于弹性扩展与收缩，业务高峰期快速创建新虚拟机实例满足需求，业务量下降时回收闲置资源，降低运营成本，以电商促销活动期间云平台的资源调整为例，就能很好体现这一目标。

4.2 架构分析

4.2.1 Nova计算服务架构

Nova架构精妙复杂，由多个紧密协作的子组件构成，共同实现强大的计算资源管理功能。

在这里插入图片描述

nova - api：作为对外唯一接口，接收处理用户和其他组件的API请求，兼容OpenStack原生Compute API与Amazon EC2 API，降低用户迁移成本。会对请求进行合法性检查，通过后转发给后续组件。
nova - scheduler：负责资源调度，依据计算节点负载、虚拟机需求、用户优先级等因素，用预设算法挑选最合适的节点运行虚拟机。
nova - compute：是管理虚拟机的核心服务，运行在计算节点上，与Hypervisor交互，实现虚拟机全生命周期管理，为其提供稳定运行环境。
nova - conductor：充当数据访问代理，nova - compute通过它查询和更新数据库中的虚拟机信息，在大规模集群中可水平扩展，提升性能和可靠性。
nova - console等组件：共同提供虚拟机控制台访问功能。nova - consoleauth负责Token认证，nova - cert提供x509证书支持，用户可通过nova - novncproxy等方式连接控制台。

4.2.2 资源调度架构

在计算资源调度方面，Nova通常采用基于消息队列的架构模式，其中RabbitMQ是常用的消息队列系统。这种架构模式的工作原理是，当用户发起创建虚拟机等涉及资源调度的请求时，nova-api首先接收请求，并对其进行初步处理和验证。若请求合法，nova-api会将请求消息发送到RabbitMQ消息队列中。

nova-scheduler作为消息的消费者，会持续监听RabbitMQ消息队列。一旦它接收到来自nova-api的请求消息，便会启动调度算法。调度算法首先通过一系列过滤器对计算节点进行筛选。例如，RetryFilter用于处理调度失败后的重试逻辑，确保请求不会因为一时的故障而被丢弃；AvailabilityZoneFilter根据可用区域的设置，筛选出符合条件的计算节点；RAMFilter、DiskFilter、CoreFilter等则分别从内存、磁盘、CPU核心数等资源维度进行过滤，筛选出资源满足虚拟机需求的计算节点。

在通过过滤器筛选出一批候选计算节点后，nova-scheduler会采用权重计算的方式，对这些候选节点进行进一步评估。根据计算节点的资源剩余量、负载情况、与虚拟机需求的匹配程度等因素，为每个候选节点计算一个权重值。例如，资源剩余量多、负载低的计算节点会被赋予较高的权重值。最终，nova-scheduler会选择权重值最高的计算节点作为目标节点，并将调度结果通过RabbitMQ消息队列发送给nova-compute 。

nova-compute在接收到来自nova-scheduler的调度结果消息后，会在指定的计算节点上，调用Hypervisor的API来创建和启动虚拟机实例。在这个过程中，若nova-compute需要查询或更新数据库中的虚拟机相关信息，它会通过RabbitMQ消息队列与nova-conductor进行通信，由nova-conductor完成对数据库的操作。

这种基于消息队列的资源调度架构，具有良好的解耦性和扩展性。不同组件之间通过消息队列进行通信，避免了直接的耦合，使得各个组件可以独立发展和升级。消息队列还能够有效地缓冲请求，在高并发情况下，保证系统的稳定性和可靠性。随着计算节点数量的增加和业务规模的扩大，通过增加nova-scheduler和nova-compute的实例数量，就可以轻松实现资源调度系统的水平扩展。

4.3 原理与流程

4.3.1 虚拟机创建原理

在OpenStack中，虚拟机的创建涉及多个组件的紧密协作，其核心原理是将用户的请求转化为对物理计算资源的合理分配与配置。当用户发起创建虚拟机的请求时，首先会通过Horizon界面或命令行工具将请求发送至nova-api组件。nova-api在接收到请求后，会对请求进行严格的合法性检查，包括验证请求参数是否完整、格式是否正确等。若请求通过验证，nova-api会将请求信息转发给nova-scheduler组件。

在这里插入图片描述

nova-scheduler会根据一系列复杂的调度算法，从众多计算节点中筛选出最适合运行该虚拟机的节点。这些调度算法综合考虑了多个因素，如计算节点的资源负载情况，包括CPU使用率、内存剩余量、磁盘空间等；虚拟机的资源需求，如指定的CPU核心数、内存大小、磁盘容量等；以及用户的优先级等。在某企业的云平台中，若有一个对计算性能要求较高的虚拟机创建请求，nova-scheduler会优先选择那些CPU性能强劲且当前负载较低的计算节点。

一旦确定了目标计算节点，nova-scheduler会将调度结果发送给该节点上的nova-compute组件。nova-compute在接收到创建虚拟机的指令后，会与该节点上的Hypervisor进行交互。以KVM虚拟化技术为例，nova-compute会调用KVM的API来创建虚拟机实例。在这个过程中，nova-compute会根据用户指定的镜像信息，从Glance镜像服务中获取相应的虚拟机镜像。Glance会将镜像数据传输给nova-compute，nova-compute再将镜像数据加载到目标计算节点的存储设备中，为虚拟机的启动做好准备。

nova-compute还会为虚拟机配置网络和存储资源。它会与Neutron网络服务进行交互，为虚拟机分配IP地址、设置网络接口等，确保虚拟机能够接入网络。在存储方面，若用户为虚拟机指定了额外的存储卷，nova-compute会与Cinder块存储服务协作，将存储卷挂载到虚拟机上，满足用户的数据存储需求。

4.3.2 计算资源调度流程

计算资源调度流程是一个复杂而有序的过程，旨在确保计算资源能够被高效、合理地分配给虚拟机。用户通过OpenStack的客户端（如Horizon或命令行工具）向nova-api发送创建虚拟机或调整虚拟机资源的请求。nova-api在接收到请求后，会对请求进行初步处理，包括验证请求的合法性、解析请求参数等。若请求不合法，nova-api会返回相应的错误信息给用户。

nova-api将处理后的请求消息发送到RabbitMQ消息队列中。RabbitMQ作为消息的中转站，负责将请求消息可靠地传递给nova-scheduler。nova-scheduler持续监听RabbitMQ消息队列，一旦接收到请求消息，便会启动调度算法。

调度算法首先通过一系列过滤器对计算节点进行筛选。RetryFilter用于处理调度失败后的重试逻辑，确保请求不会因为一时的故障而被丢弃。AvailabilityZoneFilter根据可用区域的设置，筛选出符合条件的计算节点，例如，用户可能指定虚拟机要创建在某个特定的可用区域内，该过滤器会根据这一条件筛选出该区域内的计算节点。RAMFilter、DiskFilter、CoreFilter等则分别从内存、磁盘、CPU核心数等资源维度进行过滤，筛选出资源满足虚拟机需求的计算节点。例如，若虚拟机需要8GB内存、100GB磁盘空间和4个CPU核心，这些过滤器会筛选出内存大于8GB、磁盘空间大于100GB且CPU核心数不少于4个的计算节点。

在通过过滤器筛选出一批候选计算节点后，nova-scheduler会采用权重计算的方式，对这些候选节点进行进一步评估。根据计算节点的资源剩余量、负载情况、与虚拟机需求的匹配程度等因素，为每个候选节点计算一个权重值。例如，资源剩余量多、负载低的计算节点会被赋予较高的权重值；与虚拟机需求匹配度高的节点，如CPU架构与虚拟机所需的计算类型更适配的节点，也会获得较高的权重值。最终，nova-scheduler会选择权重值最高的计算节点作为目标节点，并将调度结果通过RabbitMQ消息队列发送给nova-compute 。