【云计算】OpenStack 核心组件知识总结（一）
OpenStack核心组件知识总结 OpenStack是一个开源的云计算管理平台，包含多个相互协作的服务组件。Keystone作为身份认证服务，负责用户认证、授权和服务目录管理；Glance提供虚拟机镜像管理功能；Nova负责计算资源管理；Neutron提供网络服务；Cinder和Swift分别管理块存储和对象存储；Heat实现资源编排。这些组件通过REST API和消息队列协作，采用模块化设计，
·
OpenStack 核心组件知识总结
作者：贾维斯 ⚡
日期：2026-05-20
版本：v1.0
涵盖组件：Keystone · Glance · Nova · Cinder · Swift · Neutron · Heat
目录
- 整体架构概览
- Keystone — 身份认证服务
- Glance — 镜像服务
- Nova — 计算服务
- Neutron — 网络服务
- Cinder — 块存储服务
- Swift — 对象存储服务
- Heat — 编排服务
- 组件协作流程
- 学习路线建议（剩余组件）
1. 整体架构概览
1.1 什么是 OpenStack
OpenStack 是一个开源的云计算管理平台，用于构建和管理公有云/私有云/混合云基础设施。它通过一系列相互协作的服务组件，对底层的计算、存储、网络资源进行抽象和管理，对外提供统一的 API 接口。
1.2 设计哲学
┌──────────────────────────────────────────────────────────┐
│ OpenStack 云平台 │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Horizon │ │ Heat │ │ Ceilometer││ Ironic │ │
│ │ (仪表盘) │ │ (编排) │ │ (监控) │ │ (裸金属) │ │
│ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ │
│ │ Nova │ │ Neutron │ │ Cinder │ │ Swift │ │
│ │ (计算) │ │ (网络) │ │ (块存储) │ │ (对象存储) │ │
│ └──────────┘ └──────────┘ └──────────┘ └───────────┘ │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Glance (镜像服务) │ │
│ └──────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Keystone (身份认证服务) │ │
│ └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
核心设计原则：
- 模块化：每个组件独立部署、独立升级
- API 驱动：所有操作通过 REST API 完成
- 松耦合：组件之间通过消息队列和 API 调用协作
- 分布式：天生支持水平扩展
1.3 组件分类
| 分类 | 组件 | 功能 |
|---|---|---|
| 基础服务 | Keystone | 认证、授权、服务目录 |
| 镜像服务 | Glance | 虚拟机镜像管理 |
| 计算服务 | Nova | 虚拟机/实例生命周期管理 |
| 网络服务 | Neutron | 网络、子网、路由、负载均衡 |
| 存储服务 | Cinder | 块存储卷管理 |
| 存储服务 | Swift | 对象存储（RESTful） |
| 编排服务 | Heat | 资源栈自动化编排 |
2. Keystone — 身份认证服务
2.1 核心定位
身份认证的守门人 + 服务目录的总机
Keystone 是所有 OpenStack 服务的入口。任何一个 API 请求到达任何服务之前，必须先通过 Keystone 的认证。
2.2 核心概念
2.2.1 User（用户）
- 代表一个实体（人、系统、服务）
- 拥有凭据（密码、token、AK/SK）
- 可以属于一个或多个 Project（项目）
2.2.2 Project（项目，旧称 Tenant/租户）
- 资源的隔离单元
- 每个项目内有独立的虚拟机、网络、存储
- 用户的权限范围限定在项目内
2.2.3 Role（角色）
- 定义用户在某项目下的权限
- 常见角色：
admin、member、reader - OpenStack 的 RBAC（基于角色的访问控制）核心
2.2.4 Domain（域）
- 最高层级的隔离单位
- 一个 Domain 包含多个 Project 和 User
- 多租户场景下的第一层划分
2.2.5 Service（服务）
- 注册到 Keystone 的 OpenStack 组件
- 每个服务有一个唯一的
type和name
2.2.6 Endpoint（端点）
- 服务的访问地址
- 三种类型：
public：公网访问地址internal：内部网络地址admin：管理操作地址
- 每个 Region 可以有不同的 Endpoint
2.3 认证流程
┌─────────┐ ① POST /v3/auth/tokens ┌──────────┐
│ │ ──────────────────────────────> │ │
│ Client │ (用户名+密码/AK/SK) │ Keystone │
│ │ │ │
│ │ ② 返回 Token (UUID/ Fernet) │ │
│ │ <────────────────────────────── │ │
│ │ └──────────┘
│ │ ③ GET /servers (携带 Token) ┌──────────┐
│ │ ──────────────────────────────> │ Nova │
│ │ │ │
│ │ ④ Nova 向 Keystone 验证 Token │ │
│ │ ⑤ 返回资源 │ │
│ │ <────────────────────────────── │ │
└─────────┘ └──────────┘
2.4 Token 类型
| 类型 | 说明 | 特点 |
|---|---|---|
| UUID Token | 早期类型 | 长字符串，需存数据库，查得慢 |
| PKI Token | 基于证书 | 体积大，HTTP Header 可能超长 |
| Fernet Token | 当前推荐 | 对称加密，无需持久化，推荐使用 |
| JWT Token | 新版支持 | 标准 JSON Web Token，跨平台友好 |
2.5 服务目录（Service Catalog）
Keystone 维护着一个全局服务目录，记录了所有已注册服务的 Endpoint。客户端认证后，返回的 token 中会附带服务目录，客户端据此知道该去哪里调用什么服务。
2.6 关键知识点
- V2 vs V3 API：V3 引入了 Domain 概念，废弃了 Tenant 改称 Project，推荐使用 V3
- Policy 文件：
/etc/keystone/policy.yaml定义了角色细粒度权限 - Federation：支持 LDAP、SAML、OpenID Connect 等外部认证源
- PKI 签名：可以配置让各服务本地验证 token 而无需每次都请求 Keystone
- 访问令牌（Application Credentials）：为用户提供 AK/SK 级别的长期凭证
3. Glance — 镜像服务
3.1 核心定位
虚拟机镜像的仓库 + 元数据管理
Glance 负责管理虚拟机启动所需的镜像文件及其元数据，提供镜像的注册、查询、上传、下载、删除等功能。
3.2 核心概念
3.2.1 Image（镜像）
- 虚拟机启动的模板文件
- 支持多种格式：qcow2、raw、vmdk、vhd、iso 等
- 包含操作系统和预装软件
3.2.2 Image Metadata（镜像元数据）
- 名称、格式、架构、最小磁盘/内存等属性
- 可以通过 Property 扩展自定义元数据
3.2.3 Image Visibility（可见性）
| 可见性 | 说明 |
|---|---|
public |
所有项目可见 |
private |
仅所属项目可见 |
shared |
通过成员列表共享 |
community |
所有项目可见，但不可编辑 |
3.2.4 Image Status（镜像状态）
queued → saving → active
↘ → killed
active → deactivated
active → pending_delete → deleted
| 状态 | 说明 |
|---|---|
queued |
元数据已注册，但镜像数据未上传 |
saving |
数据正在上传中 |
active |
镜像可用 |
killed |
上传过程中出错 |
deactivated |
管理员手动停用 |
pending_delete |
标记删除（可恢复） |
3.3 镜像后端存储
Glance 支持多种后端（Store Backend）：
| 后端 | 说明 | 适用场景 |
|---|---|---|
| file | 本地文件系统 | 测试环境 |
| swift | 对象存储 | 生产环境大镜像 |
| cinder | 块存储卷 | 需高性能 |
| s3 | AWS S3 兼容存储 | 混合云 |
| rbd | Ceph RADOS | 大规模生产推荐 |
| vmware | vSphere Datastore | VMware 集成 |
3.4 镜像缓存
Glance 支持在多计算节点上缓存常用镜像，加速实例启动：
- 用户请求创建实例
- Nova 检查本地是否有缓存
- 缓存命中 → 直接使用
- 缓存未命中 → 从 Glance 下载到本地 Cache
- 下次启动同一镜像时加速
3.5 关键知识点
- 多磁盘格式支持：qcow2（推荐，支持快照/压缩）、raw（性能最佳）、vmdk（VMware）
- 镜像转换：跨格式转换可用
qemu-img工具 - 镜像签名：支持 GPG/SHA 校验镜像完整性
- 镜像元数据定义：可通过
metadefsAPI 定制 - Glance 与 Nova 的关系：Nova 在创建实例时从 Glance 拉取镜像；Glance 本身不直接处理脏数据，Nova 负责镜像的写入和 COW（写时复制）
4. Nova — 计算服务
4.1 核心定位
虚拟机的生命周期管理员
Nova 是整个 OpenStack 最核心的组件，负责虚拟机（Instance）的创建、调度、启停、迁移、销毁等全生命周期管理。类比：OpenStack 的"大脑"。
4.2 架构组成
Nova 采用分布式、去中心化的架构，由多个子服务组成：
┌─────────────────┐
│ nova-api │ ← REST API 入口
│ (API Server) │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Message Queue │ ← RabbitMQ (服务间通信)
│ (消息队列) │
└──┬────┬────┬───┘
│ │ │
┌────────────┘ │ └────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ nova-conductor│ │ nova-scheduler│ │ nova-console │
│ (数据库代理) │ │ (调度器) │ │ (控制台) │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────────┐
│ nova-compute │ ← 每个计算节点一个
│ (Hypervisor) │ ← KVM / Xen / ESXi
└──────────────────┘
│
▼
┌──────────────────┐
│ libvirt / KVM │ ← 真正的虚拟化层
└──────────────────┘
4.2.1 nova-api
- 入口：接收所有 REST API 请求
- 协议：支持 OpenStack Compute API v2 / v2.1
- 功能：认证过滤、请求路由、响应封装
4.2.2 nova-scheduler
- 核心职责：决定在哪台计算节点上创建虚拟机
- 调度策略（Filters & Weights）：
- Filter：过滤出满足条件的节点（如内存足够、CPU 架构匹配）
- Weight：对符合条件的节点打分排序
常用 Filter：
| Filter | 作用 |
|---|---|
RetryFilter |
排除已尝试失败的节点 |
AvailabilityZoneFilter |
按可用区过滤 |
RamFilter |
内存容量检查 |
CoreFilter |
vCPU 配额检查 |
DiskFilter |
磁盘空间检查 |
ComputeFilter |
计算节点是否在线 |
ImagePropertiesFilter |
镜像属性匹配（如架构、Hypervisor） |
ServerGroupAntiAffinityFilter |
反亲和性调度 |
4.2.3 nova-conductor
- 数据库代理：nova-compute 不直接访问数据库，通过 conductor 间接访问
- 安全层：防止计算节点直接暴露数据库凭证
- 委托操作：处理复杂数据库查询和写操作
4.2.4 nova-compute
- 真正干活的人：运行在每个计算节点上
- 管理 Hypervisor：通过 libvirt 驱动管理虚拟机
- 职责：创建、销毁、迁移、快照虚拟机
4.2.5 nova-console / novncproxy
- 提供 VNC / SPICE / RDP 远程控制台访问
4.3 虚拟机生命周期
┌─────────┐
│ BUILD │ ← 创建中（调度 → 分配资源 → 启动）
└────┬────┘
▼
┌─────────┐
│ ACTIVE │ ← 正常运行（可 SSH / RDP / Console）
└────┬────┘
│
├─────────────────┬──────────────────┬───────────────────┐
▼ ▼ ▼ ▼
┌─────────┐ ┌──────────┐ ┌─────────────┐ ┌─────────────┐
│ PAUSED │ │ SUSPENDED│ │ RESCUE │ │ RESIZE/VERIFY│
│ (暂停) │ │ (挂起) │ │ (救援模式) │ │ (调整规格) │
└─────────┘ └──────────┘ └─────────────┘ └─────────────┘
│ │ │ │
└──────────────┴──────────────────┴───────────────────┘
│
▼
┌─────────────┐
│ SHELVED │ ← 关闭但保留磁盘
│ (搁置) │
└──────┬──────┘
▼
┌─────────────┐
│ DELETED │ ← 标记删除（可恢复）
└─────────────┘
4.4 创建实例完整流程
① 用户 → nova-api: POST /servers {image, flavor, network...}
② nova-api → Keystone: 验证 Token
③ nova-api → Glance: 检查镜像是否存在
④ nova-api → Neutron: 检查网络是否存在
⑤ nova-api → Message Queue: 发送"创建实例"请求
⑥ nova-scheduler: 收到请求，筛选计算节点
⑦ nova-scheduler: 选中最优节点 → 发送调度结果到 Queue
⑧ nova-compute: 收到调度结果
⑨ nova-compute → nova-conductor: 查询/更新数据库
⑩ nova-compute → Glance: 拉取镜像
⑪ nova-compute → Neutron: 创建端口/网络
⑫ nova-compute → Cinder: 挂载卷（如果指定了）
⑬ nova-compute → libvirt: 定义并启动虚拟机
⑭ nova-compute: 返回创建结果
4.5 Flavor（实例规格）
Flavor 定义了虚拟机的"套餐"规格：
| 属性 | 说明 | 例子 |
|---|---|---|
| vCPUs | 虚拟 CPU 核数 | 2 |
| RAM (MB) | 内存大小 | 4096 |
| Root Disk (GB) | 根磁盘大小 | 20 |
| Ephemeral (GB) | 临时磁盘 | 10 |
| Swap (MB) | 交换分区 | 1024 |
| RXTX Factor | 网络带宽因子 | 1.0 |
4.6 Hypervisor 驱动
| 驱动 | 虚拟化技术 | 适用场景 |
|---|---|---|
| libvirt/KVM | 全虚拟化 + 硬件加速 | 主流推荐（Linux） |
| XenAPI | XenServer/XCP-ng | 传统企业场景 |
| VMwareVCDriver | vSphere/ESXi | VMware 混合部署 |
| Hyper-V | Windows Hyper-V | Windows 环境 |
| Docker | 容器化 | 测试/轻量场景 |
4.7 关键知识点
- Cells（单元）：水平扩展方案，将计算节点划分为 Cell 层次结构
- Placement API：从 Queens 版本引入的资源追踪新机制，替代部分 Scheduler 功能
- 冷迁移 vs 热迁移：
- 冷迁移：关机后迁移
- 热迁移（Live Migration）：运行中迁移，需共享存储
- Evacuate（疏散）：计算节点宕机后，在其他节点上重建实例
- GPU 透传：通过 PCI Passthrough 将 GPU 直通给虚拟机
- NUMA 感知调度：针对 NUMA 架构优化内存访问性能
- 弹性伸缩：结合 Heat + Ceilometer 实现自动扩缩容
- 聚合（Host Aggregate）：将计算节点分组，实现不同硬件/可用区的逻辑分区
- User Data / cloud-init：实例首次启动时自动执行初始化脚本
5. Neutron — 网络服务
5.1 核心定位
网络的抽象和自动化
Neutron 为 OpenStack 提供"网络即服务"（Networking as a Service），管理虚拟网络、子网、路由、防火墙、负载均衡等网络资源。
5.2 核心概念
5.2.1 Network（网络）
- 隔离的二层广播域
- 三种网络类型：
| 网络类型 | 说明 | 外部访问 |
|---|---|---|
| Provider Network | 直接映射到物理网络 | ✅ 可外部访问 |
| Self-Service Network | 租户隔离的 Overlay 网络 | ❌ 默认不能出外网 |
| External Network | 代表物理外部网络的逻辑网络 | ✅ 互联网 |
5.2.2 Subnet（子网）
- 定义 IP 地址分配范围
- IPv4 / IPv6
- 包含 DHCP 配置、网关地址、DNS 等
5.2.3 Port（端口）
- 虚拟交换机上的连接点
- 绑定了 MAC / IP 地址
- 实例通过 Port 接入网络
5.2.4 Router（路由器）
- 连接不同子网的三层设备
- 实现租户网络 ↔ 外部网络的路由（SNAT）
- 为浮动 IP 提供 DNAT
5.3 网络拓扑示例
Internet
│
┌───────┴───────┐
│ External Net │
│ 172.24.4.0/24 │
└───────┬───────┘
│
┌───────┴───────┐
│ Router │ ← 连接内外网
│ (SNAT/DNAT) │
└───┬───────┬───┘
│ │
┌───────────────────┘ └────────────────────┐
│ │
┌───────┴───────┐ ┌───────┴───────┐
│ Subnet A │ │ Subnet B │
│ 192.168.1.0/24│ │ 192.168.2.0/24│
└───────┬───────┘ └───────┬───────┘
│ │
┌───────┴───────┐ ┌───────┴───────┐
│ Instance A │ │ Instance B │
│ 192.168.1.10 │ │ 192.168.2.10 │
└───────────────┘ └───────────────┘
浮动 IP: 172.24.4.100 → 映射到 Instance A 的 192.168.1.10
5.4 架构组件
┌──────────────┐
│ neutron-api │
└──────┬───────┘
│
┌──────┴───────┐
│ Message Queue│
└──────┬───────┘
│
┌───────────────┼──────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌────────────────┐ ┌──────────────────┐
│ neutron-server│ │neutron-l3-agent│ │neutron-dhcp-agent│
│ (ML2 Plugin) │ │ (路由/NAT) │ │ (DHCP 服务) │
└───────────────┘ └────────────────┘ └──────────────────┘
▼ ▼
┌───────────────────┐ ┌───────────────────┐
│neutron-openvswitch│ │neutron-linuxbridge│
│ (OVS Agent) │ │ (LB Agent) │
└───────────────────┘ └───────────────────┘
5.5 ML2 插件架构
Modular Layer 2 (ML2) 是 Neutron 的网络插件框架，将网络抽象分为两层：
- Type Driver：定义网络类型
flat、vlan、gre、vxlan、geneve
| 类型 | 封装 | 最大数量 | 适用场景 |
|---|---|---|---|
flat |
无 | 受物理端口数限制 | 简单拓扑 |
vlan |
802.1Q | 4094 | 传统数据中心 |
gre |
GRE | 2^32 | Overlay 网络 |
vxlan |
VXLAN | 2^24 | 大规模 Overlay（推荐） |
geneve |
GENEVE | 2^24 | 最新、最灵活 |
- Mechanism Driver：定义如何实现网络
openvswitch、linuxbridge、l2population
5.6 网络连通性
实例出外网流程（SNAT）
Instance A (192.168.1.10) → 外网
│
┌─────────────▼──────────────┐
│ Hypervisor Bridge (br-int) │
└─────────────┬──────────────┘
│
┌─────────────▼──────────────┐
│ Tunnel/VXLAN 封装 │
└─────────────┬──────────────┘
│
┌─────────────▼──────────────┐
│ 网络节点 Router Namespace │
│ SNAT: 192.168.1.10 → │
│ 172.24.4.100 │
└─────────────┬──────────────┘
│
┌─────────────▼──────────────┐
│ External Bridge (br-ex) │
└─────────────┬──────────────┘
▼
Internet
5.7 高级服务
| 特性 | 说明 | 对应 Agent |
|---|---|---|
| Floating IP | 外网可访问的固定 IP | l3-agent |
| Security Group | 实例级防火墙（有状态） | OVS/LB Agent |
| LBaaS | 负载均衡即服务 | octavia |
| FWaaS | 防火墙即服务 | l3-agent |
| VPNaaS | VPN 即服务 | vpn-agent |
| QoS | 带宽/流量限制 | OVS Agent |
| RBAC | 网络资源权限控制 | server |
5.8 安全组（Security Group）
- 有状态防火墙
- 默认：拒绝所有入站，允许所有出站
- Rule 规则：协议（TCP/UDP/ICMP）+ 端口范围 + 远程来源（CIDR/SG）
- 通过 iptables / OVS flow 在计算节点本地实现
5.9 关键知识点
- Open vSwitch (OVS) vs Linux Bridge：OVS 功能更强（OpenFlow/QoS/VXLAN HW Offload），LB 更轻量
- DVR（分布式虚拟路由）：避免东西向流量经过网络节点瓶颈
- DHCP Agent：每个租户网络分配一个 dnsmasq 进程
- Metadata Agent：实例通过 169.254.169.254 获取 user data
- ARP 抑制（L2 Population）：减少广播流量，提升大规模部署性能
- 网络命名空间：每个 Router / DHCP / LB 独立 namespace 隔离
6. Cinder — 块存储服务
6.1 核心定位
持久化块存储的分配和管理
Cinder 提供类似 AWS EBS 的块存储服务——卷（Volume）可以独立于实例存在，挂载到实例上作为额外磁盘使用。
6.2 核心概念
6.2.1 Volume（卷）
- 持久化的块存储设备
- 以
/dev/vdX形式呈现给虚拟机 - 可以被格式化、挂载、分区
6.2.2 Volume Type（卷类型）
- 定义卷的性能/特性模板
- 可以关联后端存储驱动和 QoS
6.2.3 Snapshot（快照）
- 卷的时间点副本
- 用于备份、恢复、创建新卷
- 支持一致性组快照
6.2.4 Backup（备份）
- 将卷备份到对象存储（Swift / Ceph RGW / S3）
- 跨地域容灾
6.3 卷生命周期
available ←→ in-use
│ │
├─ attaching ←→ detaching
├─ creating
├─ deleting
├─ extending
├─ reverting (回滚到快照)
├─ backing-up
└─ restoring (从备份恢复)
6.4 架构组件
┌──────────────┐
│ cinder-api │ ← REST API 入口
└──────┬───────┘
│
┌──────┴───────┐
│ Message Queue│
└──────┬───────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌─────────────┐ ┌─────────────┐
│cinder-scheduler │ |cinder-volume│ │cinder-backup│
│ (后端/节点调度) │ |(后端驱动) │ │ (备份到对象) │
└─────────────────┘ └──────┬──────┘ └─────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────────┐
│ LVM │ │ Ceph │ │ NetApp │ ← 后端存储
│ (本地) │ │ (RBD) │ │ (企业 SAN) │
└────────┘ └────────┘ └────────────┘
6.4.1 cinder-api
- REST API 入口
- 验证请求，路由到消息队列
6.4.2 cinder-scheduler
- 决定卷创建在哪个存储后端上
- 支持 Filter + Weight 调度（类似 Nova）
6.4.3 cinder-volume
- 实际管理卷的后端服务
- 通过 Volume Driver 对接不同存储
- 在存储节点上运行
6.5 后端存储驱动
| 后端 | 类型 | 特点 |
|---|---|---|
| LVM / iSCSI | 本地 | 测试环境，简单直接 |
| Ceph RBD | 分布式 | 生产推荐，原生支持复制/快照 |
| NFS | 网络文件系统 | 简单共享存储 |
| NetApp | 企业 SAN | 商业硬件，功能全 |
| Dell EMC | 企业 SAN | 传统存储阵列 |
| Pure Storage | 全闪存 | 高性能场景 |
| HPE 3PAR | 企业 SAN | HP 生态 |
6.6 卷的挂载流程
实例创建时指定卷:
① Nova → Cinder: 请求挂载卷 volume-xxx
② Cinder: 检查卷状态 (available)
③ Cinder: 状态改为 in-use，返回连接信息
④ Nova → Hypervisor: 在宿主机上执行 iscsiadm / rbd map
⑤ Nova → Libvirt: 将设备作为 disk 添加到虚拟机 XML
⑥ 虚拟机: 检测到新设备 /dev/vdb
6.7 关键知识点
- 多后端（Multi-Backend）：Cinder 可以同时对接多个存储后端，按策略调度
- 卷迁移：支持在线/离线迁移卷到不同后端
- 一致性组（Consistency Group）：多个卷的原子化快照
- QoS 策略：限制卷的 IOPS / 带宽
- 加密：支持卷级加密（LUKS）
- Cinder 与 Nova 的"根磁盘"区别：
- 根磁盘来自 Glance 镜像，通常存放在本地/共享存储上（ephemeral）
- Cinder 卷是额外挂载的块设备
- 也可以把根磁盘建在 Cinder 卷上（Boot from Volume）
7. Swift — 对象存储服务
7.1 核心定位
大规模、高可用的 RESTful 对象存储
Swift 提供类似 AWS S3 的对象存储服务，适合存储非结构化数据（镜像、备份、日志、多媒体文件等）。
7.2 核心概念
7.2.1 Object（对象）
- 数据 + 元数据
- 大小默认最大 5GB，通过分段上传（SLO/DLO）可达更大
7.2.2 Container（容器）
- 对象的逻辑分组
- 类似 S3 的 Bucket
- 可以有访问控制策略
7.2.3 Account（账户）
- Container 的集合
- 对应一个 Project 级别的存储空间
7.3 架构与数据模型
Account (租户/项目)
└── Container (容器)
└── Object (对象)
├── 数据 (Data)
├── 元数据 (Metadata)
└── 对象名 (Name)
7.4 数据分布：Ring 环
Swift 的核心是 Ring — 一致性哈希环，决定了数据如何分布：
Ring
┌─────────────────────────────────────────────┐
│ 一致性哈希环 (Consistent Hashing) │
│ │
│ ┌───┐ ┌───┐ ┌───┐ ┌───┐ ┌───┐ │
│ │ P1│ │ P2│ │ P3│ │ P4│ │ P5│ │
│ └───┘ └───┘ └───┘ └───┘ └───┘ │
│ ▲ ▲ ▲ ▲ ▲ │
│ │ │ │ │ │ │
│ └──────┴──────┴──────┴──────┘ │
│ 共享数据的 N 个副本 │
└─────────────────────────────────────────────┘
Ring 的层级：
| 级别 | 说明 |
|---|---|
| Region | 地理区域，跨机房 |
| Zone | 故障域（机架/电源域），副本分布在不同 Zone |
| Node | 物理存储节点 |
| Device | 磁盘设备（如 /dev/sdb） |
| Partition | 虚拟逻辑分区（Ring 的最小管理单元） |
| Replica | 副本数量（默认3） |
7.5 数据写入流程
① Client: PUT /v1/AUTH_xxx/container/object
② Proxy: 计算哈希 → 确定 3 个目标位置
③ Proxy: 并行写入 3 个副本
④ Primary Node: 写入磁盘，返回成功
⑤ Proxy: 收到多数副本确认（>= 2）→ 返回 201
7.6 架构组件
┌──────────┐
│ Client │
└─────┬────┘
│ HTTP/REST
▼
┌──────────────┐
│ swift-proxy │ ← 请求入口，路由到存储节点
│ (无状态) │
└──────┬───────┘
│
▼
┌──────────────────────────────────────────┐
│ Ring 一致性哈希 (查找数据位置) │
└──────────────────────────────────────────┘
│
▼
┌───────────────┐ ┌───────────────┐ ┌─────────────┐
│ swift-account │ │swift-container│ │swift-object │
│ (账户数据库) │ │(容器数据库) │ │(对象存储) │
└───────────────┘ └───────────────┘ └─────────────┘
│ │ │
▼ ▼ ▼
┌──────────────────────────────┐
│ rsync / ssync (数据同步) │
│ + Auditor (数据校验) │
│ + Reaper (删除清理) │
└──────────────────────────────┘
7.7 关键特性
| 特性 | 说明 |
|---|---|
| 最终一致性 | 写入后短时间内容忍副本不一致 |
| 自动修复 | Auditor 持续校验数据完整性 |
| 异地容灾 | Region 级别同步 |
| 静态网站托管 | Container 可配置为静态网站 |
| ACL 访问控制 | 容器/对象级别的读写权限 |
| 版本控制 | 对象版本管理 |
| 过期删除 | 自动过期策略（X-Delete-At / X-Delete-After） |
| 分段上传 | DLO（Dynamic Large Object）/ SLO（Static Large Object） |
| TempURL | 临时授权 URL，类似 S3 预签名 URL |
7.8 Swift vs Cinder 对比
| 特性 | Swift（对象存储） | Cinder（块存储） |
|---|---|---|
| 访问方式 | REST API (HTTP) | 块设备挂载（iSCSI/RBD） |
| 协议 | HTTP/HTTPS | iSCSI / FC / RBD |
| 数据模型 | Account → Container → Object | Volume |
| 适合场景 | 备份、归档、静态文件 | 数据库、高 IO 应用 |
| 可挂载到虚拟机 | ❌（需网关） | ✅ 直接作为磁盘 |
| 扩展方式 | 增加存储节点 | 增加后端或卷 |
| 一致性模型 | 最终一致性 | 强一致性 |
| 冗余机制 | 多副本（Ring） | 取决于后端（RAID/Ceph 副本） |
7.9 关键知识点
- Swift 的最终一致性：因为是异步多副本写入，短时间内容忍不一致，但也意味着有"脏读"窗口
- 没有中心数据库：Swift 通过 Ring 和 Gossip 协议实现去中心化，没有单点故障
- 跨 Region 部署：通过 Realm 和 Region 实现异地多活
- 性能瓶颈通常在 Proxy 节点：因为所有请求都经过 Proxy
- 与 Glance 的常见配合：Glance 后端可以用 Swift 存储镜像大文件
8. Heat — 编排服务
8.1 核心定位
基础设施即代码（IaC）的资源自动化编排
Heat 允许用户通过模板文件（类似 AWS CloudFormation）来定义和管理一组 OpenStack 资源的生命周期，实现一键部署和销毁复杂应用栈。
8.2 核心概念
8.2.1 Stack（栈）
- 一组被管理的资源集合
- 一个 Stack 由模板定义，是部署的基本单位
8.2.2 Template（模板）
- 描述资源的 YAML/JSON 文件
- 支持两种格式：
- HOT（Heat Orchestration Template）：Heat 原生格式
- CFN（CloudFormation）：兼容 AWS 格式
8.2.3 Resource（资源）
- Stack 中的具体 OpenStack 资源
- 如：Server、Volume、Network、SecurityGroup
8.2.4 Parameter（参数）
- 模板的输入变量
- 用户部署时传入，实现模板复用
8.2.5 Output（输出）
- Stack 创建后的返回值
- 如浮动 IP、访问地址等
8.3 Stack 生命周期
CREATE_IN_PROGRESS → CREATE_COMPLETE
↘ CREATE_FAILED (回滚中 → ROLLBACK_COMPLETE)
UPDATE_IN_PROGRESS → UPDATE_COMPLETE
↘ UPDATE_FAILED → ROLLBACK_COMPLETE
DELETE_IN_PROGRESS → DELETE_COMPLETE
↘ DELETE_FAILED
SUSPEND_IN_PROGRESS → SUSPEND_COMPLETE
RESUME_IN_PROGRESS → RESUME_COMPLETE
8.4 HOT 模板示例
heat_template_version: 2023-11-13
description: >
部署一台带浮动 IP 的 Web 服务器
parameters:
image:
type: string
label: 镜像
description: 使用的 Glance 镜像
default: ubuntu-22.04
flavor:
type: string
label: 实例规格
default: m1.small
resources:
web_server:
type: OS::Nova::Server
properties:
name: web-server
image: { get_param: image }
flavor: { get_param: flavor }
networks:
- network: { get_resource: private_net }
user_data: |
#!/bin/bash
apt-get update
apt-get install -y nginx
private_net:
type: OS::Neutron::Net
properties:
name: private-net
private_subnet:
type: OS::Neutron::Subnet
properties:
network: { get_resource: private_net }
cidr: 192.168.100.0/24
dns_nameservers: [8.8.8.8, 1.1.1.1]
router:
type: OS::Neutron::Router
properties:
external_gateway_info:
network: public-net
router_interface:
type: OS::Neutron::RouterInterface
properties:
router: { get_resource: router }
subnet: { get_resource: private_subnet }
floating_ip:
type: OS::Neutron::FloatingIP
properties:
floating_network: public-net
floating_ip_assoc:
type: OS::Neutron::FloatingIPAssociation
properties:
floatingip_id: { get_resource: floating_ip }
port_id: { get_attr: [web_server, ports, 0] }
outputs:
web_url:
description: Web 服务器访问地址
value:
str_replace:
template: http://%ip%
params:
"%ip%": { get_attr: [floating_ip, floating_ip_address] }
8.5 内置函数（Intrinsic Functions）
| 函数 | 说明 | 示例 |
|---|---|---|
get_param |
获取参数值 | { get_param: image } |
get_resource |
获取资源的引用 | { get_resource: private_net } |
get_attr |
获取资源的属性 | { get_attr: [server, networks] } |
str_replace |
字符串模板替换 | 见上例 |
list_join |
列表拼接 | { list_join: [",", ["a","b"]] } |
digest |
哈希计算 | { digest: ["sha256", "hello"] } |
repeat |
生成重复结构 | 用于批量资源定义 |
if / equals |
条件判断 | 模板条件分支 |
8.6 资源关系
Stack
├── OS::Nova::Server (Web)
│ └── 依赖 SecurityGroup, Network
├── OS::Neutron::Net
│ └── 依赖 Subnet
├── OS::Neutron::Subnet
│ └── 依赖 RouterInterface
├── OS::Neutron::Router
│ └── 依赖 ExternalGateway
├── OS::Cinder::Volume
│ └── 依赖 VolumeAttachment → Server
└── OS::Heat::AutoScalingGroup
└── 依赖 Nova Server (多个副本)
Heat 会分析资源间的依赖关系，按正确顺序创建/删除，支持并行创建无依赖的资源。
8.7 关键特性
| 特性 | 说明 |
|---|---|
| 自动回滚 | 创建失败时自动销毁已创建的资源 |
| 资源依赖解析 | 自动推导依赖顺序 |
| 嵌套栈（Nested Stack） | 模板可以互相嵌套调用 |
| AutoScaling | 自动伸缩组，结合 Ceilometer / Monasca |
| Software Config | 通过 cloud-init 注入配置脚本 |
| 更新热变更 | 部分资源支持修改后原地更新 |
| Stack 锁定 | 防止意外修改/删除 |
| Hook 点 | 在 Pre/Post 阶段暂停，允许人工审查 |
8.8 关键知识点
- Heat vs Terraform：Heat 是 OpenStack 原生编排，与 OpenStack API 集成更紧密；Terraform 是云无关工具，生态更广
- User Data 注入：通过
OS::Heat::CloudConfig或 inlineuser_data传递初始化脚本 - Wait Condition：资源创建后等待外部信号确认成功
- ResourceGroup：批量创建同类资源（如多个计算节点）
- Stack 嵌套：通过
OS::Heat::Stack资源实现模板组合
9. 组件协作流程
9.1 虚拟机创建全流程（完整串联）
以一个典型场景为例：创建一台有浮动 IP 的云主机，挂载一块数据卷。
┌────────┐ ┌──────────┐ ┌────────┐ ┌─────────┐ ┌────────┐ ┌─────────┐ ┌────────┐
│ Client │ │Keystone │ │Glance │ │ Nova │ │Neutron │ │ Cinder │ │ Heat │
└───┬────┘ └──────────┘ └────────┘ └────┬────┘ └────────┘ └─────────┘ └────────┘
│ │
│ ① POST /servers (请求创建) │
│──────────────────────────────────>│
│ │
│ ② 验证 Token │
│───Keystone───────────────────────>│
│ ③ 验证通过 │
│<──────────────────────────────────│
│ │
│ ④ 查询镜像信息 │
│────────────────────Glance────────>│
│ ⑤ 返回镜像元数据 │
│<────────Glance────────────────────│
│ │
│ ⑥ 创建网络 Port │
│─────────────────Neutron──────────>│
│ ⑦ 返回 Port 信息 │
│<─────────Neutron──────────────────│
│ │
│ ⑧ 创建并挂载 Volume │
│───────────────────Cinder─────────>│
│ ⑨ 返回 Volume 信息 │
│<──────────Cinder──────────────────│
│ │
│ ⑩ 调度计算节点 │
│ (nova-scheduler) │
│ ↓ 选中 compute-01 │
│ │
│ ⑪ 创建虚拟机 │
│ (nova-compute @ compute-01) │
│ ├── 从 Glance 拉取镜像 │
│ ├── 配置 Neutron 网络 │
│ ├── 挂载 Cinder 卷 │
│ └── libvirt 启动实例 │
│ │
│ ⑫ 分配浮动 IP │
│─────────────────Neutron──────────>│
│ ⑬ 返回浮动 IP 信息 │
│<─────────Neutron──────────────────│
│ │
│ ⑭ 返回创建结果 │
│<──────────────────────────────────│
9.2 组件数据流关系图
┌──────────┐
│ Keystone │ ← 所有组件的认证中心
└────┬─────┘
│
┌─────────────────┼─────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────┐ ┌────────────┐ ┌────────────────┐
│ Horizon │ │ Heat │ │ Ceilometer │
│ (UI) │───>│ (编排) │───>│ (监控/计量) │
└─────────┘ └─────┬──────┘ └────────────────┘
│
┌────────────┼────────────┬──────────────┐
▼ ▼ ▼ ▼
┌────────┐ ┌──────────┐ ┌────────┐ ┌──────────────┐
│ Nova │ │ Neutron │ │ Cinder │ │ Swift │
│(计算) │ │ (网络) │ │(块存储)│ │ (对象存储) │
└───┬────┘ └──────────┘ └────────┘ └──────┬───────┘
│ │
│ ┌─────────┐ │
└─│ Glance │<────────────────────────┘
│ (镜像) │ Swift 可作为 Glance 后端
└─────────┘
9.3 组件间依赖关系
| 组件 | 直接依赖 | 间接依赖 |
|---|---|---|
| Keystone | 无 | 无 |
| Glance | Keystone | 可选：Swift/Cinder 后端 |
| Nova | Keystone, Glance, Neutron | Cinder（挂载卷时） |
| Neutron | Keystone | 无 |
| Cinder | Keystone | 可选：Swift（备份） |
| Swift | Keystone | 无 |
| Heat | Keystone, Nova, Neutron, Cinder, Glance | 可选：Ceilometer（伸缩） |
9.4 消息队列的角色
消息队列（通常用 RabbitMQ）是整个 OpenStack 组件间通信的神经系统：
- 解耦各服务：Nova-API 和 Nova-Compute 不需要直接连接
- 异步调用：创建实例时，API 返回后依然可以继续执行
- 广播/组播：nova-scheduler 广播请求，所有 compute 节点可以接收
- 可靠传输：支持确认重试，不丢失请求
10. 学习路线建议（剩余组件）
你已经学完了前 7 个核心组件，还剩 Horizon（仪表盘）、Ceilometer（监控计量）、Ironic（裸金属管理）。以下是快速入手的建议：
10.1 Horizon（仪表盘）
- 定位：Web UI 管理界面
- 关键点：
- Django 框架开发
- 本质上就是调用其他组件的 API
- 可定制 Dashboard / Panel
- 学习重点在于：了解它的架构和插件化机制
- 推荐时间：1 天
10.2 Ceilometer / Telemetry（监控计量）
- 定位：资源使用监控和计量计费
- 关键点：
- 收集 CPU、内存、网络、存储的使用数据
- 事件总线 + 管道（Pipeline）处理数据
- 结合 Heat 实现 AutoScaling
- 数据可存入 Gnocchi（时序数据库）/ Panko（事件存储）
- 推荐时间：2-3 天
10.3 Ironic（裸金属）
- 定位：物理服务器的自动化部署和管理
- 关键点：
- 把物理机当虚拟机一样管理
- PXE + iPXE 网络引导部署
- PXE + IPMI 进行带外管理
- 支持硬件 RAID、BIOS 配置
- 与 Nova 集成：Nova 把 Ironic 当作特殊的 Hypervisor
- 推荐时间：3-5 天
10.4 推荐的进阶路线
初学者 ─→ 核心基础（K/G/N/Ne/CI/Sw） ← 你在这里 ✅
│
▼
进阶服务（H/Ce/Ho/I）
│
▼
周边生态
├── Kolla-Ansible（容器化部署）
├── OpenStack-Ansible
├── TripleO（部署工具）
├── Kuryr（容器网络）
├── Manila（共享文件系统）
├── Octavia（负载均衡）
└── Barbican（秘钥管理）
│
▼
运维进阶
├── 高可用部署
├── 性能调优
├── 排错方法论
└── 大规模部署（100+ 节点）
写在最后：
OpenStack 的学习曲线确实陡峭，但把这 7 个核心摸透了，剩下的靠"融会贯通"就能很快上手。
它们的设计都很一致：API → 消息队列 → Agent/Scheduler → Driver 驱动后端，
理解了这套模式，新组件无非是"不同的资源类型 + 不同的后端驱动"。下一步可以先搭个 All-in-One 环境（用 DevStack 或 Kolla-Ansible），
亲手部署一遍，跑几个实例，找找感觉。理论 + 实践才是真掌握 🚀— 贾维斯 ⚡
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
2
0- 0
已为社区贡献3条内容
所有评论(0)