OpenStack 核心组件原理与架构深度剖析

引言

OpenStack 是一个开源的云计算管理平台项目，通过一系列相互协作的组件，为公有云和私有云提供可扩展、高可用的基础设施即服务（IaaS）。它并非一个单一的软件，而是由多个独立开发的组件（计算、存储、网络、身份认证等）协同工作的生态系统。这些组件通过标准化的 REST API 进行通信，并通过消息队列（如 RabbitMQ）实现内部解耦。本文将从理论层面，深入剖析 OpenStack 各核心组件的内部架构、数据模型、调度算法、配置机制以及它们之间的交互流程，帮助读者构建起完整的云计算理论体系。

第一章：身份认证服务 Keystone ------ 云平台的"安全大门"

1.1 Keystone 的定位与核心职责

Keystone 是 OpenStack 的"门卫"，负责统一管理身份认证（Authentication）和访问授权（Authorization）。所有 OpenStack 服务的 API 请求都必须在通过 Keystone 的验证后，才能访问实际资源。它提供多租户环境下的用户、项目、角色和令牌管理功能。

1.2 Keystone 分层数据模型（核心概念）

Keystone 采用分层的数据模型，从最高级到最低级依次为 Domain、Project、User、Group、Role。理解这些概念是掌握 OpenStack 权限模型的基础。

1.2.1 Domain（域）

定义：Keystone 中最高级的容器，一个域对应一个大型机构、一个数据中心或一个独立的安全边界。
特性：域必须全局唯一。云终端用户可以在自己的域内创建多个 Project、User、Group 和 Role。域实现了多租户的隔离，确保不同机构之间的资源互不可见。

1.2.2 User（用户）

定义：通过 OpenStack 访问服务的个人、系统或服务实例。
标识：用户由凭证（Credential，如用户名密码）标识。Keystone 通过验证用户的凭证来确认其身份。
特性：用户并非全局唯一，只需在域内唯一即可。验证通过后，Keystone 会分配一个令牌（Token）作为后续访问的凭证。

1.2.3 Group（用户组）

定义：一组 User 的集合。
作用：通过向组分配角色（Role），可以一次性为组内所有用户授权，实现了对用户组权限的统一管理。这简化了大规模用户权限分配的复杂度，避免了为每个用户单独授权的繁琐操作。

1.2.4 Project（项目 / 租户）

定义：资源的集合容器，是 OpenStack 中最核心的隔离单位。
归属：计算（Nova）、网络（Neutron）、存储（Cinder）等资源都必须归属于某个项目。资源的所有权属于项目而非用户。
特性：一个用户可以被分配到多个项目中，但必须在特定项目下被赋予特定角色才能访问该项目资源。在公有云中，Project 通常被称为"租户（Tenant）"，多个术语通用。

1.2.5 Role（角色）

定义：一组权限的集合，定义了执行特定操作的特权。
分配：角色可以赋予在域级别或项目级别。域级角色对整个域内的所有项目生效，项目级角色仅对特定项目生效。
默认角色 ：
- admin：管理员，具备最高权限。
- member：项目成员，可创建和管理项目内资源。
- _member_：兼容旧版的成员角色，与 member 权限相同。
角色继承：角色可以被继承，拥有父项目的访问权限意味着同时拥有对子项目的访问权限。

1.3 认证与鉴权机制（Authentication & Authorization）

OpenStack 的安全机制分为两个层面：

认证（Authentication）解决"你是谁？"：用户向 Keystone 提交用户名和密码，Keystone 验证通过后签发 Token。Token 是一串字符，包含用户身份、项目、角色等信息，作为访问其他服务的"通行证"。
鉴权（Authorization）解决"你能干什么？" ：当用户访问 Nova 等服务时，请求头携带 Token。Nova 收到请求后向 Keystone 验证 Token 的有效性，同时通过自身的 policy.json 配置文件，结合 Token 中的角色信息，判断用户是否有权执行具体操作。

1.4 令牌（Token）机制

类型：UUID Token（简单但无状态，需频繁查库）、PKI Token（自包含但体积大）、Fernet Token（当前推荐，轻量、加密、无状态）。
有效期：默认 24 小时，可通过配置调整。
用途：用于访问各服务，作为后续 API 调用的凭证。

1.5 完整认证流程（以创建虚拟机为例）

用户请求 Token：用户向 Keystone 提交用户名和密码。
Keystone 签发 Token：Keystone 验证凭证后，生成包含身份、项目、角色信息的 Token 并返回。
用户发起请求：用户向 Nova-API 发送创建虚拟机请求，携带 Token。
Nova 验证 Token：Nova-API 向 Keystone 验证 Token，并判断权限。
服务间调用：Nova 调用 Glance（镜像）、Neutron（网络）、Cinder（存储）时，各服务分别向 Keystone 验证 Token，形成完整的安全信任链。

第二章：镜像服务 Glance ------ 虚拟机模板的"仓库"

2.1 Glance 的定位与职责

Glance 是 OpenStack 的镜像服务，负责镜像的注册、发现、上传、下载和管理。它本身不存储镜像数据，而是通过 Driver 机制将镜像数据存储到文件系统、Swift、Ceph、S3 等后端存储。

2.2 镜像与实例、规格的关系

镜像（Image）：包含操作系统及必要配置的虚拟机模板，可重复使用。
实例（Instance）：基于镜像启动的虚拟机，是镜像的一个运行副本。实例的修改不影响镜像。
规格（Flavor）：定义实例的 CPU、内存、磁盘大小，用户启动实例时必须指定。

2.3 镜像格式（Disk Format）

qcow2：QEMU 支持的磁盘格式，支持动态扩展和写时复制（Copy-on-Write），节省存储空间，是 OpenStack 中最常用的格式。
raw：非结构化镜像，性能最好，但占用空间大，不支持快照。
vmdk：VMware 常见格式。
vhd / vhdx：Microsoft、Xen、VirtualBox 等使用。
iso：光盘镜像，用于安装操作系统。
aki / ari / ami：Amazon 系列格式。

2.4 容器格式（Container Format）

bare：裸格式，镜像文件中没有外部封装，最常用。
ovf：镜像中包含 OVF 元数据。

2.5 镜像状态机（核心）

Glance 中的镜像数据遵循严格的状态机模型：

queued：镜像元数据已注册，但数据尚未上传。
saving：镜像数据正在上传中。
active：镜像数据上传完毕，可以正常使用。
deactivated：禁止非管理员访问镜像数据。
killed：上传过程中发生错误，镜像不可读。
deleted：镜像信息已删除，数据将被自动清理。
pending_delete：镜像数据尚未完全删除，处于该状态的镜像可恢复。

2.6 Glance 架构演进

V1 API：Glance-API 和 Glance-Registry 是分离的 WSGI Server。Registry 处理元数据，API 处理数据。
V2 API：Glance-Registry 的内容被整合进 Glance-API，直接操作数据库。通过 Store 模块接口支持多种后端存储。

第三章：计算服务 Nova ------ 云平台的"发动机"

3.1 Nova 的职责边界

Nova 负责：虚拟机生命周期管理（创建、删除、迁移、调整大小）、其他计算资源（如 vCPU、内存、磁盘）的管理。
Nova 不负责：承载虚拟机的物理主机自身的管理、全面的系统状态监控。

3.2 Nova 组件架构

Nova 采用"无共享"架构，各组件通过消息队列（RabbitMQ）通信，实现高可用和水平扩展。

组件	职责
Nova-API	对外提供 REST 接口，接收并校验用户请求，处理配额预留，是虚拟机生命周期管理的入口。
Nova-Scheduler	虚拟机调度器，根据资源需求，从所有计算节点中筛选最合适的节点。
Nova-Conductor	数据库访问代理。处理需要协调的请求（如构建、调整大小），充当 Nova-Compute 与数据库之间的代理，解耦了 Nova-Compute 对数据库的直接访问。
Nova-Compute	真正执行虚拟机操作，通过 Driver 对接不同 Hypervisor（KVM、Xen、VMware），管理虚拟机生命周期。
Nova-Placement	跟踪资源提供者的库存和使用情况，为调度器提供资源视图。

3.3 Nova-API 架构

Nova-API 基于 WSGI 框架实现，接收 REST 请求，进行参数校验，处理配额预留，并在数据库中创建记录。它通过 oslo.messaging 库将 RPC 消息发送到其他 Nova 组件。

3.4 Nova-Scheduler 调度原理（Filter Scheduler）

调度过程分为两步：

3.4.1 过滤（Filter）

Scheduler 按顺序应用过滤器，过滤掉不满足条件的节点：

RetryFilter：刷掉之前调度失败的节点。
AvailabilityZoneFilter：按可用域筛选。
ComputeFilter：只选择 nova-compute 状态正常的节点。
RamFilter / DiskFilter / CoreFilter：按资源需求筛选，支持超配。
ComputeCapabilitiesFilter：根据节点特性（如 CPU 架构）筛选。
ImagePropertiesFilter：根据镜像属性（如 Hypervisor Type）筛选。
ServerGroupAntiAffinityFilter：反亲和性，把实例分散到不同节点。
ServerGroupAffinityFilter：亲和性，把实例集中到同一节点。

3.4.2 权重（Weight）

通过过滤的节点，Scheduler 计算权重值，权重最高者被选中。默认基于空闲内存量计算：空闲内存越多，权重越高。

3.5 超配（Overcommit）

为提高资源利用率，OpenStack 允许超配：

cpu_allocation_ratio：默认 16.0，即 1 个物理核心可分配 16 个 vCPU。
ram_allocation_ratio：默认 1.5，即 1GB 物理内存可分配 1.5GB 虚拟内存。
disk_allocation_ratio：默认 1.0，磁盘通常不允许超配。

3.6 实例生命周期管理

软重启（Soft Reboot）：只重启操作系统。
硬重启（Hard Reboot）：断电后再开机。
暂停（Pause）：状态保存到内存，恢复快。
挂起（Suspend）：状态保存到磁盘，恢复慢，状态为 Shut Down。
搁置（Shelve）：保存为镜像，从宿主机删除，释放资源。
锁定（Lock）：防止意外删除。普通用户可以解锁。

第四章：块存储服务 Cinder ------ 虚拟机的"外接硬盘"

4.1 持久化存储分类

临时存储（Ephemeral Storage）：虚拟机终止后数据丢失，是本地磁盘。
持久存储（Persistent Storage）：生命周期独立于虚拟机，包括块存储（Cinder）、对象存储（Swift）、文件存储（Manila）。

4.2 Cinder 的定位与架构

Cinder 本身不是存储技术，而是中间抽象层，通过 Driver 对接不同后端。

Cinder-API：对外提供 REST API，解析请求。
Cinder-Scheduler：收集后端容量和能力信息，根据算法调度卷到指定后端。
Cinder-Volume：执行卷操作，通过 Driver 与后端交互。
Cinder-Backup：将卷数据备份到 Swift 或 Ceph。

4.3 Cinder 后端存储（默认 LVM）

Cinder 通过 LVM（逻辑卷管理）作为默认后端，构建在物理卷（PV）之上，形成卷组（VG），并从中创建逻辑卷（LV）。逻辑卷即提供给虚拟机的"卷"。

4.4 Cinder 调度器

AvailabilityZoneFilter：按 AZ 筛选。
CapacityFilter：按容量筛选。
CapabilitiesFilter：按卷类型能力筛选。

4.5 Cinder 挂载流程（Nova 与 Cinder 协同）

Nova 调用 Cinder-API 创建卷，传递主机名、iSCSI Initiator Name 等。
Cinder-Volume 通过 Driver 通知存储后端允许该主机访问，返回连接信息（如 iSCSI IQN、Portal）。
Nova 识别磁盘设备，调用 Hypervisor 将卷挂载给虚拟机。

第五章：对象存储服务 Swift ------ 海量静态数据的"仓库"

5.1 Swift 特性

Swift 是无中心节点的分布式对象存储，没有单点故障，具有极强的扩展性、冗余和持久性。它用于永久存储静态数据（如虚拟机镜像、图片、备份）。

5.2 Swift 数据模型

Account（账户）：顶层容器。
Container（容器）：账户下的存储容器，类似文件夹。
Object（对象）：实际存储的数据对象。

5.3 Ring（环）------ 核心数据结构

Ring 是 Swift 的关键，将虚拟节点（分区）映射到物理存储设备上。

三种 Ring：Account Ring、Container Ring、Object Ring。
构成要素：Zone（故障域）、Device（物理设备）、Partition（分区）、Replica（副本）。
数据分布：数据默认保存多个副本（如 2 或 3），分布在不同 Zone 上，保证高可用。

第六章：编排服务 Heat ------ 云环境的"自动化指挥官"

6.1 Heat 的定位

Heat 提供自动部署复合云应用的能力，使用声明性模板（HOT）编排资源。它位于 Nova、Neutron 等组件之上，是 OpenStack 的对外接口之一。

6.2 Heat 组件

Heat-API：提供 OpenStack 原生 REST API。
Heat-API-CFN：提供兼容 AWS CloudFormation 的 API。
Heat-Engine：核心，协调模板启动，调用底层 API 创建资源。

6.3 Heat 模板结构（HOT）

yaml 复制代码

heat_template_version: 2018-08-31
description: 模板描述
parameters:  # 输入参数
  image_name:
    type: string
    default: cirros-0.5.2
resources:  # 资源定义（必选）
  my_instance:
    type: OS::Nova::Server
    properties:
      image: { get_param: image_name }
      flavor: m1.tiny
outputs:  # 输出参数
  instance_ip:
    value: { get_attr: [my_instance, first_address] }

第七章：网络服务 Neutron ------ SDN 的"虚拟交换机"

7.1 网络虚拟化基础技术

TAP：模拟二层设备（以太网帧），用于虚拟机的虚拟网卡。
TUN：模拟三层设备（IP 包）。
VETH PAIR：成对出现的虚拟网卡，一端进、一端出，连接不同网络组件。
Linux Bridge：二层虚拟交换机，类似物理交换机。
Open vSwitch（OVS）：产品级虚拟交换机，支持大规模分布式，支持 QoS、NetFlow。

7.2 Neutron 核心模型

Network：隔离的二层广播域（local、flat、vlan、vxlan、gre）。
Subnet：IPv4/IPv6 地址段。
Port：虚拟交换机端口，绑定 MAC/IP。

7.3 Neutron 架构

Neutron Server：对外提供 API。
Plugin：维护逻辑网络状态。
Agent：在节点上实现网络功能（如 OVS Agent、DHCP Agent、L3 Agent）。
Network Provider：底层虚拟或物理交换机。

结语

OpenStack 的核心组件构成了一个庞大而精密的云计算基础架构。理解各组件的数据模型、调度算法和交互机制，是掌握 OpenStack 运维、排错和架构设计的基础。本文详细剖析了 Keystone、Glance、Nova、Cinder、Swift、Heat 和 Neutron 的理论原理，希望为读者搭建起坚实的云计算知识体系。在实际运维中，深入理解这些理论模型能够帮助我们做出更合理的设计决策，构建稳定、高效、可扩展的云环境。