Li的学习之路

 Li的学习之路

发表于 更新于 分类于 ，
全面解析OpenStack Glance镜像服务的核心概念（镜像格式/后端存储/上传下载/镜像共享）、架构设计与生产实践

OpenStack Glance镜像服务详解

Glance是OpenStack的镜像服务核心组件，提供虚拟机镜像的发现、注册、检索和交付能力。采用元数据与数据分离的架构设计，通过可插拔的 glance_store 适配层实现后端存储的灵活切换。📸

一、Glance核心架构概览

组件全景图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
                  ┌──────────┐
                  │ Keystone │
                  └────┬─────┘
                       │ AUTH
                  ┌────▼─────┐
USER ──REST API──► GLANCE-API│
                  └────┬─────┘
                       │
             ┌─────────▼──────────┐
             │    GLANCE.STORE    │ ◄── 存储抽象层
             ├────────────────────┤
             │  元数据 → SQL DB   │ ◄── MySQL（镜像元信息）
             │  镜像数据 → 后端   │ ◄── 可插拔后端存储
             └────────────────────┘
                       │
      ┌────────────────┼────────────────┐
      ▼                ▼                ▼
 FILE存储           SWIFT             CEPH RBD
(本地磁盘)       (对象存储)          (分布式存储)

核心组件一览表

组件 职责 说明
glance-api RESTful API入口 处理镜像查询/上传/删除等所有请求，对接Keystone认证
glance-registry 元数据存储服务 Newton版本后为可选组件，旧版负责镜像元数据读写
glance.db 元数据库（MySQL） 存储镜像ID、名称、格式、checksum、location等元信息
glance.store 存储后端适配层 核心抽象层，实现镜像数据与后端存储的解耦

架构设计哲学 — 元数据与数据分离

1
2
3
4
5
6
7
8
9
10
11
12
13
镜像 = 镜像元数据 (Metadata) + 镜像数据 (Data)

元数据       → 存储在 glance.db (MySQL)
               ├── id, name, disk_format, container_format
               ├── size, status, visibility
               ├── checksum (MD5), os_hash_value (SHA512)
               ├── properties (自定义属性)
               └── locations (指向后端存储的 URI)

镜像数据     → 存储在后端存储中
               ├── file:///var/lib/glance/images/<UUID>
               ├── swift://account/container/<UUID>
               └── rbd://pool/image/<UUID>

关键设计理念: Nova 启动虚拟机时根据 location 直接从后端存储读取数据，不经 glance-api 中转，避免额外网络跳转和数据拷贝。🚀

二、镜像格式详解 🗂️

Glance 支持多种镜像格式，覆盖主流虚拟化平台：

格式 扩展名 特性 适用场景
QCOW2 .qcow2 QEMU原生格式，稀疏文件（按需分配）、快照链、写时复制 最常用，KVM/QEMU 虚拟化首选
RAW .raw 无格式裸磁盘镜像，性能最优 高性能计算、数据库等I/O密集型场景
VMDK .vmdk VMware虚拟磁盘格式 VMware 虚拟机迁移到 OpenStack
VHD/VHDX .vhd Microsoft Hyper-V 格式 与 Hyper-V 平台互操作
ISO .iso 光盘归档格式 安装介质注入（如 cloud-init）
AKI/ARI/AMI - Amazon kernel/ramdisk/image AWS 镜像兼容
Ploop - Virtuozzo/Parallels 格式 容器化虚拟化场景
Docker - Docker 容器格式 (已逐步淘汰)

QCOW2 vs RAW 深度对比 ⚡

1
2
3
4
5
6
7
8
9
10
11
12
13
14
QCOW2:
  ├── 创建时仅占用实际使用的空间（稀疏文件）
  ├── 支持快照链（snapshot chain）
  ├── 支持写时复制（copy-on-write, COW）
  ├── 支持 AES 加密（不推荐生产使用）
  ├── 支持压缩（qemu-img convert -c）
  └── 有小幅性能开销（约 5-10%）

RAW:
  ├── 创建时即分配全部空间
  ├── 无格式转换开销，I/O 性能最高
  ├── QEMU/KVM 直通效率最高
  ├── 可通过 qemu-img 转换为任意格式
  └── 占用磁盘空间较大

经验建议: 日常虚拟机用 QCOW2（节省空间、支持快照），高性能数据库类用 RAW，VMware 对接用 VMDK。✅

三、镜像上传与下载 📥📤

上传镜像

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 上传 QCOW2 格式镜像（最常用）
openstack image create "cirros-0.6.2" \
  --file cirros-0.6.2-x86_64-disk.img \
  --disk-format qcow2 \
  --container-format bare \
  --public

# 通过 URL 导入（需配置 glance-api 允许外部源）
openstack image create "ubuntu-22.04" \
  --location https://cloud-images.ubuntu.com/jammy/current/jammy-server-cloudimg-amd64.img \
  --disk-format qcow2 \
  --container-format bare \
  --public

# 上传 RAW 格式
openstack image create "centos-stream-raw" \
  --file CentOS-Stream-8-x86_64.raw \
  --disk-format raw \
  --container-format bare

# 上传 ISO 格式（用于安装引导）
openstack image create "windows-server-iso" \
  --file windows-server-2022.iso \
  --disk-format iso \
  --container-format bare

create 参数详解:

参数 说明 可选值
--DISK-FORMAT 磁盘格式 qcow2 / raw / vmdk / vhd / iso
--CONTAINER-FORMAT 容器封装格式 bare / ovf / aki / ari / ami / docker
--PUBLIC 公开可见 所有项目可访问
--PRIVATE 私有镜像 仅本项目和被共享项目可见
--PROTECTED 保护模式 禁止删除（需取消保护后方可删除）
--PROPERTY 自定义属性 如 --property architecture=x86_64
--STORE 指定存储后端 多后端环境下指定目标后端（Stein+）
--MIN-DISK 最小磁盘要求 启动该镜像所需的最小磁盘 GB
--MIN-RAM 最小内存要求 启动该镜像所需的最小内存 MB
--SIGNATURE 签名文件 镜像完整性签名
--TAG Glance元数据标签 与元定义配合实现镜像分类

下载镜像

1
2
3
4
5
6
7
8
9
10
11
12
# 列出当前可用镜像
openstack image list
#                      └─ 列出所有可见镜像（可加 --PUBLIC / --PRIVATE 筛选）

# 查看镜像详细信息
openstack image show <IMAGE_ID_OR_NAME>
#                      └─ 显示镜像 ID、状态、disk_format、checksum 等完整信息

# 下载镜像到本地
openstack image save --file myimage.qcow2 <IMAGE_ID>
#                      ├─ --file 指定本地保存路径
#                      └─ 注意大镜像需要足够磁盘空间

镜像格式转换

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# qemu-img 格式转换（在本地操作，非 OpenStack 命令）
qemu-img convert -f qcow2 -O raw source.qcow2 target.raw
#                      ├─ -f 源格式（SOURCE FORMAT）
#                      ├─ -O 目标格式（OUTPUT FORMAT）
#                      └─ 支持 qcow2/raw/vmdk/vhd/qed 等

qemu-img convert -f vmdk -O qcow2 source.vmdk target.qcow2

qemu-img convert -f raw -O qcow2 -c source.raw target.qcow2
#                      └─ -c 压缩目标镜像（COMPRESS）

# 查看镜像信息
qemu-img info image.qcow2
#                      └─ 输出格式类型、虚拟大小、实际占用、快照列表

四、镜像共享 👥

4.1 项目间共享

Glance 提供细粒度的镜像共享机制，支持三种可见性级别：

级别 权限要求 行为
public admin 所有项目自动可见
private 镜像所有者 仅本项目和显式共享的项目可见
shared 镜像所有者 通过 member 机制授予特定项目访问

4.2 CLI 操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 将镜像共享给指定项目
openstack image set --share --project <TARGET_PROJECT_ID> <IMAGE_ID>
#                      ├─ --share 开启镜像共享
#                      └─ --project 指定目标项目 ID

# 使用 member 管理
openstack image add project <IMAGE_ID> <TARGET_PROJECT_ID>
#                      └─ 将项目添加为镜像的 member

# 查看镜像的共享成员列表
openstack image member list <IMAGE_ID>
#                      └─ 列出所有可访问该镜像的项目及其状态

# 接受共享的镜像（目标项目操作）
openstack image set --accept <IMAGE_ID>
#                      └─ 项目接受共享镜像后即可使用

# 移除共享
openstack image remove project <IMAGE_ID> <TARGET_PROJECT_ID>
#                      └─ 撤销指定项目的镜像访问权限

# 批量查看镜像成员
openstack image member list --image <IMAGE_ID>

4.3 社区镜像共享最佳实践

  • 基础公共镜像（如 Ubuntu Cloud、Cirros）设为 public
  • 自定义业务镜像设为 private，通过 member 精确控制
  • 使用 --PROTECTED 防止关键镜像被误删 🛡️

五、后端存储架构 💾

5.1 解耦设计 — glance.store 适配层

Glance 的核心架构优势在于 镜像存储与镜像管理解耦，通过 glance.store 实现插拔式后端：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
┌─────────────────────────────────────────────────┐
│             用户 / Nova（REST API）               │
├─────────────────────────────────────────────────┤
│                  glance-api                      │
├─────────────────────────────────────────────────┤
│                glance.store 抽象层               │
│  ┌───────────┬───────────┬───────────┬────────┐ │
│  │  FILE     │  SWIFT    │  CEPH RBD │  其它  │ │
│  │  本地文件  │  对象存储  │  分布式存储 │  NFS.. │ │
│  └───────────┴───────────┴───────────┴────────┘ │
├─────────────────────────────────────────────────┤
│               glance.db (MySQL)                 │
│           存储镜像元数据 + locations              │
└─────────────────────────────────────────────────┘

5.2 后端存储配置

配置位于 /etc/glance/glance-api.conf：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[glance_store]
# 默认存储后端
default_backend = file

# 启用的存储后端列表（多后端支持，Stein+）
enabled_backends = file:file, swift:swift, ceph:rbd

# ─── 本地文件存储 ───
[file]
filesystem_store_datadir = /var/lib/glance/images/
filesystem_store_file_perm = 1

# ─── Swift 对象存储 ───
[swift]
swift_store_container = glance
swift_store_create_container_on_put = True
swift_store_auth_address = http://controller:5000/v3
swift_store_user = service:glance
swift_store_key = <PASSWORD>
swift_store_endpoint_type = internalURL

# ─── Ceph RBD 存储 ───
[rbd]
rbd_store_pool = images
rbd_store_user = glance
rbd_store_ceph_conf = /etc/ceph/ceph.conf
rbd_store_chunk_size = 8
rados_connect_timeout = 30

5.3 各后端对比

特性 本地 File Swift Ceph RBD
高可用 ❌ 单点 ✅ 多副本 ✅ 多副本/EC
分布式 ❌ ✅ ✅
性能 ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐⭐
扩展性 单机磁盘限制 水平扩展 水平扩展
支持克隆 ❌ ❌ ✅ (RBD clone)
运维复杂度 ⭐（简单） ⭐⭐⭐ ⭐⭐⭐
典型规模 测试/小规模 中规模 大规模生产
数据路径优化 Nova本地读取 Nova从Swift拉取 Nova RBD clone零拷贝

生产推荐: ✅ Ceph RBD > Swift > 本地文件

5.4 多后端存储（Stein+）

Stein 版本开始支持多后端存储，不同镜像可选不同后端：

1
2
3
4
5
6
7
8
9
10
11
[glance_store]
enabled_backends = fast:ssd, standard:sata, archive:nfs

[ssd]
filesystem_store_datadir = /var/lib/glance/fast_images/

[sata]
filesystem_store_datadir = /var/lib/glance/standard_images/

[nfs]
filesystem_store_datadir = /mnt/nfs/glance_images/

创建镜像时指定后端：

1
2
3
4
5
openstack image create "fast-io-image" \
  --file high_perf.qcow2 \
  --store ssd \
  --disk-format qcow2 \
  --container-format bare

5.5 Location 机制 — 解耦的关键 🔑

Glance 在数据库中记录镜像数据的 存储位置 URI，Nova 根据该 URI 直接访问：

1
2
3
4
5
6
7
1. 用户上传镜像 → glance-api 接收数据流
2. glance_store 根据配置写入后端存储
3. 数据库记录 location 和 checksum
4. Nova 启动 VM 时:
   - 从 glance 获取镜像元数据（ID, location, checksum）
   - 根据 location 直接从后端存储读取数据
   - 不需要经过 glance-api 中转（直接访问）

核心优势: Glance 不参与数据路径 — 虚机启动时 Nova 直接从 Ceph/Swift 拉取镜像数据，这是大规模 OpenStack 部署的关键性能优化。⚡

六、Ceph RBD 与 Glance 深度集成 🔗

6.1 RBD 零拷贝克隆

使用 Ceph RBD 后端时，Nova 可以直接从 Ceph 克隆镜像生成虚拟机磁盘：

1
2
3
4
5
6
7
8
GLANCE: images pool (rbd)
    │
    ├── image-a (template)
    │
    └── NOVA: rbd clone ──→ vms pool (rbd)
            ├── vm-1-disk (COW snapshot of image-a)
            ├── vm-2-disk (COW snapshot of image-a)
            └── vm-3-disk (COW snapshot of image-a)

这意味着：

  • 无需实际拷贝镜像数据，创建虚机秒级完成 🚀
  • 写时复制技术，存储空间按需分配
  • 百台虚机从同一镜像启动仅占一份全量空间

6.2 Ceph 配置步骤

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 1. 创建 Ceph 池
ceph osd pool create images 128
ceph osd pool application enable images rbd

# 2. 创建 glance 用户并授权
ceph auth get-or-create client.glance \
  mon 'allow r' \
  osd 'allow class-read object_prefix rbd_children, allow rwx pool=images' \
  -o /etc/ceph/ceph.client.glance.keyring

# 3. 将密钥复制到计算节点
ceph auth get-or-create client.glance | \
  tee /etc/ceph/ceph.client.glance.keyring

# 4. 配置 glance-api.conf
# 见上方 [rbd] 配置段

6.3 Ceph 场景性能优势

指标 本地文件 Swift Ceph RBD
100台VM启动时间 ~30min ~15min ~30s
镜像存量占用 100% 100% ~1%（COW）
Nova读取路径 NFS/CIFS远程挂载 HTTP拉取 RBD kernel直接读
快照支持 ❌ ❌ ✅ RBD快照

七、镜像缓存策略 📦

7.1 glance-cache 机制

Glance 提供缓存层，将常用镜像缓存到本地磁盘，加速部署：

1
2
3
4
5
6
7
8
9
10
11
12
# 缓存管理命令
glance-cache-manage --host=controller list-cached
#                      └─ 列出当前缓存的所有镜像

glance-cache-manage --host=controller queue-image <IMAGE_ID>
#                      └─ 将指定镜像加入缓存队列

glance-cache-manage --host=controller delete-cached-images
#                      └─ 清除所有缓存镜像

glance-cache-manage --host=controller fetch-all
#                      └─ 立即拉取所有已排队的缓存镜像

7.2 缓存配置

1
2
3
4
5
6
# /etc/glance/glance-cache.conf
[ DEFAULT]
image_cache_dir = /var/lib/glance/image-cache
image_cache_driver = sqlite
image_cache_max_size = 10737418240
#                        └─ 缓存最大容量（10GB）

八、镜像签名与安全验证 🔒

8.1 镜像签名

OpenStack Mitaka 版本开始支持镜像签名验证：

1
2
3
4
5
6
7
8
9
10
11
12
# 1. 生成签名
openssl dgst -sha512 -sign private_key.pem \
  -out image.signature image.qcow2

# 2. 上传签名镜像
openstack image create "signed-image" \
  --file image.qcow2 \
  --sign-key-url http://keyserver/signing-key.pem \
  --sign-cert-url http://keyserver/certificate.pem \
  --signature image.signature \
  --disk-format qcow2 \
  --container-format bare

8.2 镜像完整性校验

1
2
3
4
5
6
# 查看镜像的 checksum 和哈希值
openstack image show <IMAGE_ID> -c checksum -c os_hash_algo -c os_hash_value

# 本地校验
sha512sum downloaded-image.qcow2
#                      └─ 对比与 glance image show 输出的 os_hash_value 是否一致

九、镜像生命周期管理 📋

vm_image 状态机

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
           ┌──────────┐
           │ queued   │ ── 镜像元数据已创建，数据未上传
           └────┬─────┘
                │
           ┌────▼─────┐
           │ saving   │ ── 正在上传镜像数据
           └────┬─────┘
                │
           ┌────▼─────┐
     ┌─────►  active  │ ── 镜像可用
     │     └────┬─────┘
     │          │
┌────▼───┐  ┌──▼──────┐
│ deactivated│  │pending_delete│── 软删除
└──────────┘  └─────────┘
                     │
                ┌────▼─────┐
                │  deleted │ ── 已删除（不可恢复）
                └──────────┘

常用管理命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 列出镜像
openstack image list
#                      ├─ --PUBLIC 仅显示公共镜像
#                      ├─ --PRIVATE 仅显示私有镜像
#                      └─ --STATUS ACTIVE 按状态筛选

# 编辑镜像属性
openstack image set --name NEW_NAME \
  --property architecture=arm64 \
  --property hypervisor_type=kvm \
  <IMAGE_ID>

# 删除镜像
openstack image delete <IMAGE_ID_OR_NAME>
#                      └─ 若镜像被保护，需先去除 --PROTECTED

# 镜像去激活/重新激活（不删除但禁止使用）
openstack image deactivate <IMAGE_ID>
openstack image reactivate <IMAGE_ID>

# 查看镜像使用情况（哪些虚拟机在使用）
openstack server list --image <IMAGE_ID>

十、生产部署最佳实践 ✅

实践 说明
生产用 Ceph RBD 避免本地文件存储的单点故障，利用 COW 提升性能
上传前校验格式 qemu-img info 确认格式正确，避免启动失败
使用 SHA512 校验 镜像完整性验证，防止数据损坏
设置 protected 防止关键镜像被误删 🛡️
细粒度共享 敏感镜像设为 private + member 精确赋权
镜像签名 对关键镜像启用签名验证
清理未使用镜像 定期清理废弃镜像，释放存储空间
监控 glance 日志 /var/log/glance/api.log 关注上传/下载错误
多后端策略 高频镜像放 SSD，归档镜像放 HDD/NFS
启用镜像缓存 多计算节点场景显著加速部署

十一、版本演进趋势 🚀

版本 核心变化
Newton 引入 glance_store 架构，registry 变为可选
Ocata 新增镜像去激活功能（deactivate/reactivate）
Pike 支持多后端存储
Queens 镜像导入/导出流程标准化
Stein 多后端正式稳定，image import API 成熟
Train 镜像签名验证增强
Wallaby 支持镜像加密（使用 Barbican）
2025.1 Epoxy 强化镜像加密与签名校验
2026.1 Gazpacho 持续优化 Ceph 集成与性能提升

💡 技术解析

  • 术语: glance_store — Glance 的存储抽象层，独立的 oslo 库（glance_store），所有后端存储通过该插件化接口接入。这是实现镜像与后端存储解耦的关键架构组件。所有后端实现只需实现核心 CRUD 接口即可无缝集成。
  • 术语: QCOW2 — QEMU Copy-On-Write v2，支持稀疏文件（仅分配实际写入的块）、内部快照链（snapshot chain）、写时复制克隆（backing file）、AES 加密和 zlib 压缩。相较于 QCOW（v1），QCOW2 支持快照和更大的虚拟磁盘。
  • 术语: Copy-on-Write (COW) — 写时复制技术，克隆时不复制源数据，仅写入新数据时才按需分配空间。Glance + Ceph 场景的核心性能保障，秒级创建百台虚机。
  • 术语: RBD Clone — Ceph RBD 的快照克隆机制，基于 COW 技术从镜像快照直接创生虚拟机磁盘，无需拷贝源数据，是 Nova 与 Glance 协同优化的核心亮点。
  • 术语: Location (存储位置) — glance.db 中记录镜像数据实际存储位置的 URI 字段（如 rbd://pool/image/uuid），Nova 根据该 URI 直接从后端读取镜像数据，实现 Glance 不参与数据路径。
  • 术语: Container Format — 镜像的容器封装格式，bare 表示无封装（裸镜像），ovf 表示 OVF 标准封装；aki/ari/ami 对应 AWS 内核/ramdisk/机器镜像。
  • 术语: Multibackend (多后端) — Stein+ 版本功能，enabled_backends 配置多个存储后端，创建镜像时通过 --STORE 参数指定目标后端，实现不同存储策略（SSD 高性能 / SATA 大容量 / NFS 归档）。
  • 术语: Glance Cache — 将远端存储的热门镜像缓存到本地磁盘的加速机制，通过 glance-cache-manage 管理，适用于 Swift 后端的多计算节点场景。Yoga 版本后已标记废弃，推荐使用 Ceph RBD 替代。
  • 命令: openstack image create — 创建并上传镜像，--FILE 指定本地路径，--DISK-FORMAT 指定 qcow2/raw/vmdk/iso，--CONTAINER-FORMAT 指定 bare/ovf，--PUBLIC/--PRIVATE 控制可见性，--PROPERTY 添加自定义元数据。
  • 命令: openstack image save — 将远程镜像下载到本地，--FILE 指定保存路径。注意大镜像需确保本地磁盘空间充足，且下载路径不宜跨网络（建议在计算节点或 controller 节点直接操作）。
  • 命令: openstack image set --share — 跨项目共享镜像，--PROJECT 指定目标项目 ID，目标项目需 openstack image set --accept 接受后方可使用。
  • 命令: qemu-img convert — 磁盘镜像格式转换工具，-f 指定源格式，-O 指定目标格式，-c 启用压缩（仅目标为 qcow2 时有效）。支持的格式对：qcow2↔raw↔vmdk↔vhd↔qed。

🔗 相关文档

OpenStack Glance 镜像服务概念 | OpenStack Nova计算服务详解 | OpenStack Keystone详解 | OpenStack Cinder块存储详解

发表于 更新于 分类于
全面介绍OpenStack Heat编排服务的核心概念、HOT模板结构、Stack/Resource/Parameter管理及与AWS CloudFormation的兼容性

OpenStack Heat（编排）详解

一、核心思想 🌟

Heat 是 OpenStack 的编排服务（Orchestration Service），核心思想是**”基础设施即代码”（Infrastructure as Code）**，通过 HOT 模板定义一组云资源，实现一键式创建、更新、删除。

概念 说明
Stack（栈） 一组被统一管理的云资源的集合，是 Heat 编排的最小部署单元
Resource（资源） 栈中的单个云资源（如虚拟机、网络、磁盘），每个资源有唯一的 type
Parameter（参数） 模板的输入变量，允许用户自定义配置而不修改模板本身

二、HOT 模板结构 📄

HOT（Heat Orchestration Template）使用 YAML 格式，包含四个核心段：

1. 模板版本

1
heat_template_version: 2015-04-30
版本 对应 OpenStack 版本 主要特性
2014-10-16 Juno 初始稳定版
2015-04-30 Kilo 常用稳定版，支持条件函数
2016-10-14 Newton 增强 if 函数
2018-08-31 Rocky 新增 yaql 支持
2021-04-16 Wallaby if 两参数变体

2. 参数定义

1
2
3
4
5
6
7
8
9
10
11
12
parameters:
  key_name:
    type: string
    label: Key Name
    description: SSH 密钥对名称
    default: my_key
    hidden: false
    constraints:
      - allowed_values: [m1.small, m1.medium, m1.large]
        description: 规格必须为可选值之一
      - length: { min: 6, max: 8 }
        description: 密码长度 6-8 位

参数类型：string、number、json、comma_delimited_list、boolean

常用修饰符：

  • default — 设置默认值
  • hidden: true — 隐藏输入（如密码）
  • immutable: true — 创建后不可修改
  • constraints — 约束条件

3. 资源定义 🧱

1
2
3
4
5
6
7
8
9
resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: MyServer
      image: { get_param: image_id }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }
    depends_on: [my_volume]

常用资源类型速查：

资源类型 OpenStack 服务 说明
OS::Nova::Server Nova 计算实例
OS::Neutron::Net Neutron 网络
OS::Neutron::Subnet Neutron 子网
OS::Neutron::Port Neutron 端口
OS::Neutron::Router Neutron 路由器
OS::Cinder::Volume Cinder 云硬盘
OS::Cinder::VolumeAttachment Cinder 磁盘挂载
OS::Heat::AutoScalingGroup Heat 自动伸缩组
OS::Heat::RandomString Heat 随机字符串
OS::Keystone::User Keystone 用户
OS::Swift::Container Swift 对象存储容器

4. 输出定义

1
2
3
4
5
6
7
outputs:
  instance_ip:
    description: 实例 IP 地址
    value: { get_attr: [my_instance, first_address] }
  instance_id:
    description: 实例 UUID
    value: { get_resource: my_instance }

三、内置函数 🔧

函数 用途 类比 CloudFormation
get_param 获取参数值 Ref
get_attr 获取资源属性 Fn::GetAtt
get_resource 获取资源引用 Ref（资源本身）
get_file 嵌入外部文件 —
str_replace 字符串模板替换 Fn::Sub
str_split 字符串分割 Fn::Split
digest 哈希计算 —
repeat 循环生成值 —
list_join 列表拼接 Fn::Join
yaql YAML 查询语言（v2018+） —

条件函数示例：

1
2
3
4
5
6
7
8
conditions:
  create_volume: { equals: [{ get_param: volume_size }, "0"] }
  large_flavor: { not: { equals: [{ get_param: flavor }, "m1.small"] } }

resources:
  my_instance:
    type: OS::Nova::Server
    condition: large_flavor

四、AWS CloudFormation 兼容性 🔄

Heat 在设计上明确兼容 AWS CloudFormation 模板格式：

对比项 HOT（Heat 原生） CFN（CloudFormation 兼容）
格式 YAML（.yaml） JSON（.json）
资源类型前缀 OS::* AWS::*
函数风格 get_param, get_attr Ref, Fn::GetAtt
API 端点 heat-api heat-api-cfn
  • 通过 heat-api-cfn 组件提供 CloudFormation 兼容 API
  • 已有的 AWS CloudFormation 模板可直接提交给 Heat 执行
  • 支持资源类型映射：AWS::EC2::Instance → OS::Nova::Server

五、Stack 操作生命周期 🔄

1
2
3
4
5
6
7
创建（Create）→ 创建中 → 创建完成
  ↓
更新（Update）→ 更新中 → 更新完成
  ↓
回滚（Rollback）→ 回滚中 → 回滚完成
  ↓
删除（Delete）→ 删除中 → 删除完成

常用 CLI 命令 🖥️

1
2
3
4
5
6
7
openstack stack create -t TEMPLATE.YAML -e ENV.YAML MY_STACK
openstack stack list
openstack stack resource list MY_STACK
openstack stack resource show MY_STACK MY_INSTANCE
openstack stack update -t TEMPLATE.YAML --parameter "FLAVOR=M1.MEDIUM" MY_STACK
openstack stack event list MY_STACK
openstack stack delete MY_STACK

参数覆盖创建：

1
2
3
openstack stack create -t TEMPLATE.YAML \
  --parameter "KEY_NAME=MY_KEY;IMAGE=CIRROS;FLAVOR=M1.SMALL" \
  MY_STACK

六、环境文件（Environment File）📁

环境文件用于分离配置与模板：

1
2
3
4
5
6
7
8
resource_registry:
  "OS::Nova::Server::MyServer": myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

⚠️ parameter_defaults 应用到所有嵌套栈，parameters 仅应用到顶级栈

七、模板组合（Template Composition）🧩

将大型模板拆分为可复用的子模板：

1
2
3
4
5
resources:
  my_server:
    type: my_nova.yaml
    properties:
      key_name: { get_param: key_name }

嵌套栈属性访问：

1
2
3
outputs:
  test_out:
    value: { get_attr: [my_server, resource.server, first_address] }

八、完整编排流程图 🎯

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
用户输入 HOT 模板（YAML）
        │
        ▼
   Heat API（heat-api / heat-api-cfn）
        │
        ▼
   Heat Engine（引擎核心）
        │
        ├── 解析模板（参数绑定、条件判断）
        ├── 依赖排序（depends_on / 隐式依赖）
        ├── 逐个调用 OpenStack 服务 API
        │    ├── Nova → 创建虚拟机
        │    ├── Neutron → 创建网络/子网
        │    ├── Cinder → 创建云硬盘
        │    └── ...
        ├── 监控资源创建状态
        └── 返回结果（资源 ID、属性等）

九、完整模板示例 📝

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
heat_template_version: 2015-04-30

description: 完整的 Heat 编排模板示例

parameters:
  key_name:
    type: string
    label: Key Name
    description: 密钥对名称
    default: my_key
  image:
    type: string
    description: 镜像名称或 ID
    default: cirros
  flavor:
    type: string
    description: 实例规格
    default: m1.small
    constraints:
      - allowed_values: [m1.small, m1.medium, m1.large]

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

  my_volume:
    type: OS::Cinder::Volume
    properties:
      size: 1
      name: my_volume

  volume_attachment:
    type: OS::Cinder::VolumeAttachment
    properties:
      volume_id: { get_resource: my_volume }
      instance_uuid: { get_resource: my_instance }
      mountpoint: /dev/vdb

outputs:
  instance_name:
    description: 获取实例名称
    value: { get_attr: [my_instance, name] }
  instance_ip:
    description: 获取实例 IP 地址
    value: { get_attr: [my_instance, first_address] }

十、最佳实践 💡

  1. 使用环境文件分离配置与模板，避免硬编码参数
  2. 合理设置 depends_on 确保资源创建顺序
  3. 使用 parameter_defaults 统一管理嵌套栈参数
  4. 为栈开启回滚（Rollback）功能，防止失败时产生残留资源
  5. 利用 stack event list 排查创建失败原因
  6. 将大型模板拆分为可复用的子模板，提升维护性
  7. 使用 constraints 对参数进行校验，提前发现错误
  8. 生产环境建议使用 TOSCA 模板或结合 tripleo-heat-templates 进行大规模部署

🔗 相关文档

OpenStack Heat 编排服务概念 | OpenStack Nova计算服务详解 | OpenStack Neutron网络服务详解

发表于 更新于 分类于
全面介绍OpenStack Horizon架构、核心功能、部署配置、主题定制及面板扩展开发

OpenStack Horizon（Web控制面板）详解

Horizon是OpenStack的官方Web管理界面，基于 Python Django框架 开发，为云管理员和租户用户提供图形化的可视化管理入口。

一、Horizon架构概述

Horizon采用经典的 Django MTV架构，通过REST API与各OpenStack核心服务通信：

交互组件 说明
Nova 计算服务，管理虚拟机实例
Neutron 网络服务，管理网络与安全组
Cinder 块存储服务，管理卷与快照
Glance 镜像服务，管理虚拟机镜像
Keystone 认证服务，管理用户与项目
Swift 对象存储服务，管理文件容器

设计原则

  • Core Support：内置Project、Admin、Settings三大面板
  • Extensible：通过Dashboard+Panel注册机制支持任意扩展
  • Consistent：提供可复用的模板、表单和表格基类
  • Stable：核心API保证向后兼容

二、三大核心面板

1、Project面板（项目面板）

面向 终端租户用户 的自助服务门户：

  • 💻 实例管理：创建/启动/停止/重启/删除/快照
  • 💾 卷管理：创建/挂载/卸载/删除卷及快照
  • 🌐 网络管理：网络/子网/路由器/浮动IP/安全组
  • 🖼️ 镜像管理：上传/删除/启动镜像
  • 🔑 密钥对管理：生成/导入/删除SSH密钥
  • 📊 访问与安全：安全组规则、API访问权限

2、Admin面板（管理员面板）

面向 云平台管理员 的全局管控入口：

  • 📋 资源总览：计算/存储/网络资源的全局用量
  • 👥 项目与用户管理：创建/编辑/删除项目、用户及角色分配
  • 📏 配额管理：为各项目设置CPU/内存/存储上限
  • 🖥️ 主机聚合：管理计算节点与主机聚合（Host Aggregate）
  • 🔄 实例迁移：跨计算节点的实例调度与迁移
  • 📈 系统信息：服务状态、系统用量报告

3、Settings面板（设置面板）

面向 所有用户 的个性化配置：

  • 🌍 语言与时区设置
  • 🔐 密码修改
  • 🔔 仪表板主题切换

三、部署配置

安装方式

1
pip install openstack-dashboard

配置文件路径

1
/etc/openstack-dashboard/local_settings.py

核心配置项

配置项 说明 示例值
OPENSTACK_HOST Keystone服务地址 "192.168.1.100"
OPENSTACK_KEYSTONE_URL Keystone认证URL "http://192.168.1.100:5000/v3"
OPENSTACK_KEYSTONE_DEFAULT_ROLE 默认角色 "member"
ALLOWED_HOSTS 允许访问的主机列表 ["*"]
TIME_ZONE 时区 "Asia/Shanghai"
DEBUG 调试模式开关（生产环境需关闭） False

Web服务器部署

1
2
3
4
5
# Apache部署（mod_wsgi）
apt install apache2 libapache2-mod-wsgi-py3

# Nginx + uwsgi部署
pip install uwsgi

四、主题与品牌定制

Horizon支持完整的品牌定制，覆盖Logo、颜色、字体、页脚等视觉元素。

1、基础品牌配置（local_settings.py）

1
2
3
4
5
6
7
SITE_BRANDING = "My Cloud Platform"
SITE_BRANDING_LINK = "https://cloud.example.com"

AVAILABLE_THEMES = [
    ("default", "Default", "themes/default"),
    ("mytheme", "My Custom Theme", "themes/mytheme"),
]

2、创建自定义主题

主题目录结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
themes/mytheme/
├── manifest.py              # 品牌声明文件
├── static/
│   └── img/
│       ├── logo.png         # 导航栏Logo
│       ├── logo-splash.png  # 登录页Logo
│       └── favicon.ico      # 浏览器图标
├── templates/
│   └── auth/
│       └── login.html       # 自定义登录页
└── scss/
    ├── _variables.scss      # 颜色/字体变量
    └── _styles.scss         # 自定义样式

3、主题样式变量示例（_variables.scss）

1
2
3
4
$brand-primary: #00a1c9; // 主色调
$navbar-bg-color: #2a4e77; // 导航栏背景
$body-bg-color: #f5f5f5; // 页面背景
$font-family-base: "Microsoft YaHei", sans-serif;

4、启用主题

在配置目录下创建 _12_mytheme_theme.py：

1
2
3
AVAILABLE_THEMES = [
    ("mytheme", "My Cloud Theme", "themes/mytheme"),
]

注意：文件名中的数字前缀控制加载顺序，多个主题文件按文件名升序加载。

五、面板扩展开发

Horizon通过 Dashboard + Panel 机制实现功能扩展。

1、目录结构

1
2
3
4
5
6
7
8
9
10
my_plugin/
├── dashboard.py        # 注册新Dashboard
├── panel.py            # 注册Panel
├── urls.py             # URL路由
├── views.py            # 视图处理
├── tables.py           # 数据表格
├── forms.py            # 表单定义
└── templates/
    └── my_plugin/
        └── index.html  # 模板文件

2、注册新Panel示例

dashboard.py：

1
2
3
4
5
6
7
8
9
10
11
12
from django.conf import settings
from horizon.dashboards import Dashboard, panels
from openstack_dashboard.dashboards.project import dashboard


class MyPanel(panels.Panel):
    name = "我的插件"
    slug = "my_panel"
    permissions = ("openstack.roles.member",)


dashboard.Project.register(MyPanel)

enabled/_50_my_plugin.py：

1
2
3
4
5
6
7
8
ADD_INSTALLED_APPS = [
    "my_plugin",
]

ADD_PANEL = {
    "panel_group": "compute",
    "panel": "my_panel",
}

3、Views示例

1
2
3
4
5
6
7
8
9
10
from horizon import tables
from my_plugin import tables as my_tables


class IndexView(tables.DataTableView):
    table_class = my_tables.MyTable
    template_name = "my_plugin/index.html"

    def get_data(self):
        return self.request.user.my_data

4、启用/禁用已有面板

1
2
3
4
5
6
7
8
9
10
11
# 从Admin面板中移除卷备份面板
REMOVE_PANEL = {
    "openstack_dashboard.dashboards.admin.volumes.panel_volume_backups",
}

# 修改面板显示名称
UPDATE_PANEL = {
    "project.volumes": {
        "name": "云硬盘",
    },
}

六、常用管理命令

静态文件处理

1
2
3
4
5
# 收集静态文件
python manage.py COLLECTSTATIC

# 压缩CSS/JS（修改静态资源后需执行）
python manage.py COMPRESS

调试与排障

1
2
3
4
5
6
7
8
# 检查配置正确性
python manage.py CHECK

# 开发服务器启动（仅用于开发调试）
python manage.py RUNSERVER 0.0.0.0:8080

# 查看Horizon版本
python manage.py VERSION

七、安全最佳实践

  1. 🔒 生产环境务必关闭 DEBUG = True
  2. 🛡️ 配置 ALLOWED_HOSTS 限制可访问域名
  3. 🔐 启用HTTPS，使用SSL证书加密传输
  4. 👮 严格遵循最小权限原则分配Keystone角色
  5. ⏰ 为JWT Token设置合理过期时间
  6. 📝 定期审查安全组规则与API访问日志
  7. 🔄 保持Horizon版本与OpenStack各组件版本兼容

🔗 相关文档

OpenStack Horizon Web界面概念 | OpenStack Keystone详解 | OpenStack Nova计算服务详解

发表于 更新于 分类于 ，
深入解析OpenStack Keystone身份认证服务的核心概念（User/Project/Role/Domain/Endpoint/Token）、认证流程与最佳实践

OpenStack Keystone详解

Keystone角色定位

Keystone是OpenStack云平台的身份认证核心组件，作为整个平台的”统一门卫”🔐。用户访问任何服务（Nova计算、Glance镜像、Cinder块存储等）都必须先通过Keystone认证。Keystone一旦宕机，所有服务都将瘫痪。

六大核心概念

概念 说明 关键约束
User 访问OpenStack的个人或服务账户 用户名在所属Domain内唯一
Project 资源（计算/存储/网络）的容器（V2时代称Tenant） 项目名在所属Domain内唯一
Role 权限集合，决定User对Project资源的操作级别 全局唯一名称
Domain 顶层虚拟容器，包含Users/Groups/Projects Domain Name全局唯一
Endpoint 服务可访问的网络地址（URL） 三类接口：Public / Internal / Admin
Token 认证通过后签发的身份凭证字符串 有时效性（默认1h），可撤销

关键解读 📌：

  • User权限通过”User + Project + Role”三元组定义，缺一不可
  • Domain提供多租户隔离边界，不同部门可划分独立Domain
  • 三类Endpoint：Public面向外部用户 / Internal服务间通信 / Admin管理员专用

认证流程详解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
                ┌─────────────────────────────────────────────┐
                │               OpenStack 云平台               │
                │                                             │
┌───────┐     ① POST /v3/auth/tokens     ┌──────────┐     ⑥ Token     ┌─────────┐
│       │ ──────────────────────────────→ │          │ ←──验证请求──→ │         │
│       │     ② ← 返回 Unscoped Token     │ Keystone │                │  Nova   │
│ 用户  │                                 │  (认证)  │     ⑦ ← 返回   │ (计算)  │
│       │     ③ POST /v3/auth/tokens      │          │    用户信息    │         │
│       │ ─────────── (带 Scope) ────────→ │          │ ─────────────→ │         │
│       │                                 └──────────┘                └─────────┘
│       │     ④ ← 返回 Scoped Token +                              ┌─────────┐
│       │        Service Catalog + Roles                            │ Glance  │
│       │                                                           │ (镜像)  │
│       │     ⑤ Nova API 调用                                       │         │
│       │ ──────── X-Auth-Token: <SCOPED_TOKEN> ─────────────────→ │         │
└───────┘                                                           └─────────┘

标准V3认证流程（七步）

步骤 动作 说明
① 用户提交凭证 POST /v3/auth/tokens — 携带 username + password 或 API Key
② 返回Unscoped Token 仅证明身份，不含Service Catalog和Role，不可直接访问服务
③ 请求Scoped Token 指定Scope（project或domain），绑定到具体Project/Domain
④ 返回Scoped Token 附带完整Service Catalog（所有服务地址）+ Roles（当前Project权限）
⑤ 访问目标服务 Scoped Token放入HTTP头 X-Auth-Token 请求Nova/Glance等服务
⑥ 服务验证Token 通过keystonemiddleware中间件向Keystone校验Token有效性
⑦ 返回用户上下文 Keystone返回User ID、Project ID、Roles，服务据此执行策略鉴权

Token类型演进 🚀

类型 存储方式 验证方式 状态
UUID 持久化到数据库 每次查询数据库 ❌ 已弃用
Fernet 不持久化 本地加密验证（需Keystone在线） ✅ 生产默认
PKI / PKIZ 不持久化 本地证书签名验证 ❌ 已弃用
JWS 不持久化 非对称签名验证 ⚠️ 可选

Token作用域对比

作用域 含Service Catalog? 含Roles? 适用场景
Unscoped ❌ ❌ 仅证明身份，获取Scoped Token的前置步骤
Project-scoped ✅ ✅ 日常操作（最常用）
Domain-scoped 部分 ✅ Domain级别管理操作

Keystone内部架构

六大内部服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
┌─────────────────────────────────────────────────────────────┐
│                      Keystone 服务架构                       │
│                                                             │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐   │
│  │ Identity │  │ Resource │  │Assigment │  │  Token   │   │
│  │ Service  │  │ Service  │  │ Service  │  │ Service  │   │
│  │ (用户/组) │  │ (项目/域) │  │ (角色分配)│  │ (Token)  │   │
│  └──────────┘  └──────────┘  └──────────┘  └──────────┘   │
│                                                             │
│  ┌──────────┐  ┌──────────┐                                 │
│  │ Catalog  │  │  Policy  │                                 │
│  │ Service  │  │ Service  │                                 │
│  │(端点注册)│  │(授权引擎)│                                 │
│  └──────────┘  └──────────┘                                 │
└─────────────────────────────────────────────────────────────┘
内部服务 管理实体 职责
Identity Users、Groups 身份凭据验证（支持SQL / LDAP / AD / 联合认证）
Resource Projects、Domains 资源容器管理
Assignment Roles、Role Assignments 角色CRUD及User-Project-Role映射
Token Tokens Token签发、验证、撤销
Catalog Services、Endpoints 服务注册与端点发现
Policy Policies、Rules 基于规则的授权引擎

认证后端选项

后端 模式 适用场景
SQL 读写 默认，Keystone管理全部身份
LDAP / AD 只读（推荐） 对接企业已有目录服务
SAML 2.0 / OpenID Connect 联合 与外部IdP（Okta、Azure AD、ADFS）集成
Keystone-to-Keystone 联合 多OpenStack云联邦信任

CLI操作速查 🛠️

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
# 🔹 认证测试
openstack token issue
#                      └─ 请求并签发一个新的 Scoped Token，验证当前认证凭据是否有效

# 🔹 服务发现
openstack catalog list
#                      └─ 列出所有已注册服务的 Endpoint（Public / Internal / Admin）

# 🔹 用户管理
openstack user create --domain DEFAULT --password <PASSWORD> <USERNAME>
#                      ├─ --domain 指定用户所属的域（若不指定则使用 default 域）
#                      ├─ --password 设置用户登录密码
#                      └─ <USERNAME> 用户名，在所属域内唯一
openstack user list
#                      └─ 列出当前域下所有用户（可加 --domain 指定目标域）
openstack user show <USER_ID>
#                      └─ 查看指定用户的完整信息（含 ID、Domain、启用状态等）

# 🔹 项目管理
openstack project create --domain DEFAULT <PROJECT>
#                      ├─ --domain 指定项目所属的域
#                      └─ <PROJECT> 项目名称，在所属域内唯一
openstack project list
#                      └─ 列出所有项目及其所属域

# 🔹 角色分配（核心：User + Project + Role）
openstack role add --user <USER> --project <PROJECT> <ROLE>
#                      ├─ --user 指定目标用户
#                      ├─ --project 指定目标项目
#                      └─ <ROLE> 要分配的角色名（如 admin、member、reader）
openstack role assignment list --names --user <USER>
#                      ├─ --names 以名称而非 ID 形式显示（更易读）
#                      └─ --user 筛选指定用户的角色分配列表

# 🔹 域管理
openstack domain list
#                      └─ 列出所有域及其启用/禁用状态
openstack domain create <DOMAIN>
#                      └─ 创建一个新域（Domain Name 全局唯一）
openstack domain set --disable <DOMAIN>
#                      ├─ --disable 将域设为禁用状态（删除域的前置条件）
#                      └─ 域被禁用后，其下的 User 和 Project 也将无法使用
openstack domain delete <DOMAIN>
#                      └─ 删除指定域（必须先禁用）

# 🔹 端点管理
openstack endpoint list
#                      └─ 列出所有服务的 Endpoint（含服务类型、区域、URL）
openstack endpoint create --region <REGION> <SERVICE> <TYPE> <URL>
#                      ├─ --region 指定区域（如 RegionOne）
#                      ├─ <SERVICE>  服务名称（如 nova、glance）
#                      ├─ <TYPE>     端点类型（public / internal / admin）
#                      └─ <URL>      端点访问地址（如 https://controller:8774/v2.1）

生产安全配置 🔒

配置项 说明
KeystonePasswordRegex 密码强度正则表达式
KeystonePasswordExpiresDays 密码有效期天数
KeystoneLockoutFailureAttempts 锁定前允许的失败认证次数
KeystoneDisableUserAccountDaysInactive 不活跃自动禁用天数
KeystoneUniqueLastPasswordCount 防止重用旧密码
KeystoneChangePasswordUponFirstUse 首次登录强制改密

生产部署建议 ✅

  • Fernet密钥至少每月轮换一次（keystone-manage fernet_rotate— 重新生成 Fernet 密钥库，旧 Token 在缓存失效前仍可用）
  • 部署多控制器节点 + 负载均衡实现Keystone高可用
  • 禁用admin_token（避免无需认证的管理入口）
  • 监控日志：/var/log/keystone/keystone.log
  • 所有服务间通信建议使用Internal Endpoint，避免暴露Public API

一句话总结

Keystone是OpenStack的统一身份验证 + 服务发现中心，核心工作流为：凭据 → Token → Service Catalog → 服务访问。用户的Token就是云平台的”通行证”，服务间信任通过Keystone的Token校验来保障。🛡️

🔗 相关文档

OpenStack Keystone认证服务概念 | OpenStack Nova计算服务详解 | OpenStack Swift对象存储详解 | OpenStack Neutron网络服务详解 | INI 文件格式概述

发表于 更新于 分类于 ，
深入解析OpenStack核心网络服务Neutron的网络模型（Provider/Self-Service）、路由与安全组、ML2插件架构及SDN虚拟网络实现

OpenStack Neutron网络服务详解

Neutron是OpenStack的网络服务核心组件，采用插件化、驱动化、分布式架构设计，为虚拟机提供L2隔离网络、L3路由转发、NAT网关与安全组等虚拟网络功能。✨

一、网络核心模型

Neutron抽象了五种核心网络资源：

  • Network: L2隔离广播域，类似物理交换机+VLAN
  • Subnet: IPv4/IPv6地址段，定义IP池与网关
  • Port: 虚拟交换机端口，VM网卡的挂载点
  • Router: L3路由转发，连接不同子网与外部网络
  • Security Group: 有状态防火墙规则集

资源关系

1
2
3
4
5
NETWORK ──┬── SUBNET (10.0.0.0/24) ── PORT (10.0.0.2) ── VM-1
          │
          └── SUBNET (172.16.1.0/24) ── PORT (172.16.1.2) ── VM-2
                      │
                  ROUTER ── 连接外网PROVIDER NETWORK

关键概念对比

  • Network与Subnet: 一对多关系，一个Network可包含多个Subnet（如IPv4+IPv6）
  • Port与VM: 一对一绑定，创建VM时Neutron自动分配Port
  • Router与Network: 连接Provider Network后实现内网↔外网互通

二、Provider Network

特性: 直接映射到物理网络的L2网络段，VM直接获得物理网络IP。

  • 创建者: 仅管理员
  • 网络类型: Flat（无标签）或 VLAN（802.1Q）
  • 外部访问: L2桥接直连物理网络，无需路由
  • 性能: 原生硬件转发，无封装开销
  • VLAN上限: 4096

CLI操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 创建FLAT类型提供者网络
openstack network create --provider-network-type FLAT \
  --provider-physical-network PROVIDER \
  --EXTERNAL provider-net

# 创建VLAN类型提供者网络
openstack network create --provider-network-type VLAN \
  --provider-physical-network PROVIDER \
  --provider-segment 100 \
  provider-vlan-100

# 创建子网
openstack subnet create --network provider-vlan-100 \
  --subnet-range 192.168.100.0/24 \
  --gateway 192.168.100.1 \
  --allocation-pool START=192.168.100.10,END=192.168.100.200 \
  provider-vlan-100-subnet

适用场景: 数据中心扁平网络、高性能计算、裸金属与虚拟化混布。

三、Self-Service Network

特性: 基于Overlay隧道技术的多租户隔离虚拟网络（VPC）。

  • 创建者: 任意租户/用户
  • 网络类型: VXLAN / GRE / Geneve（默认VXLAN）
  • 外部访问: 需虚拟Router + NAT（浮动IP）
  • 隔离上限: VXLAN支持约1600万VNI（远超VLAN的4096）
  • 性能: 有封装解封装开销（VXLAN增加50B头部）

CLI操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 创建自服务网络（默认为VXLAN）
openstack network create selfservice-net

# 创建子网
openstack subnet create --network selfservice-net \
  --subnet-range 10.0.0.0/24 \
  --gateway 10.0.0.1 \
  --dns-nameserver 8.8.8.8 \
  selfservice-subnet

# 创建路由器并连接外网
openstack router create demo-router
openstack router set --external-gateway provider-net demo-router
openstack router add subnet demo-router selfservice-subnet

# 分配浮动IP实现外网访问
openstack floating ip create provider-net
openstack server add floating ip <SERVER_NAME> <FLOATING_IP>

适用场景: 多租户VPC、弹性虚拟网络环境。

三、路由器 — L3转发与NAT

路由器由 neutron-l3-agent 实现，运行在网络命名空间中，每个租户路由器独立隔离。

核心功能

  • SNAT: 内网→外网出站流量自动源地址转换（VM私有IP→浮动IP）
  • DNAT: 外网→内网入站流量目的地址转换（浮动IP→VM私有IP）
  • 子网路由: 路由器自动转发同一路由器下不同子网间的流量

高级部署模式

模式 说明 优势 劣势
Legacy L3 集中式路由器在网络节点 管理简单 单点瓶颈、东西流量绕行
DVR 分布式虚拟路由 东西流量本地转发 配置复杂
L3 HA 多副本Keepalived 高可用 资源消耗翻倍

CLI操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建路由器
openstack router create demo-router

# 设置外部网关
openstack router set --external-gateway provider-net demo-router

# 添加子网接口
openstack router add subnet demo-router selfservice-subnet

# 移除子网接口
openstack router remove subnet demo-router selfservice-subnet

# 删除路由器
openstack router delete demo-router

四、安全组 — 有状态虚拟机防火墙

安全组提供Port级别的状态化L2-L4防火墙，作用于虚拟机每个虚拟网卡。

默认策略

  • 入站: 全部拒绝（必须显式允许）
  • 出站: 全部允许（可配置）
  • 状态化: 允许入站响应已建立连接的流量

后端实现

实现方式 机制 适用场景
iptables_hybrid 每个VM Port插入iptables规则链 小规模、兼容性优先
openvswitch OVS流表实现防火墙规则 大规模、高吞吐
OVN ACL OVN南向流表，Port Group管理 超大规模、分布式

CLI操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 列出安全组
openstack security group list

# 创建安全组
openstack security group create web-sg \
  --description "Web服务器安全组"

# 添加规则：允许HTTP
openstack security group rule create --proto TCP \
  --dst-port 80 --src-ip 0.0.0.0/0 web-sg

# 添加规则：允许SSH（指定远程安全组—微隔离）
openstack security group rule create --proto TCP \
  --dst-port 22 --remote-group bastion-sg web-sg

# 为服务器绑定安全组
openstack server create --security-group web-sg \
  --security-group default VM_NAME

最佳实践:

  • 最小权限原则，仅开放必要端口
  • 使用 --remote-group 实现微隔离（Microsegmentation），IP变化不影响规则
  • 安全组规则上限（quota_security_group_rule）按需调整

五、ML2插件架构

ML2（Modular Layer 2）是Neutron的核心插件框架，采用双驱动模型：

  • Type Drivers（类型驱动）: 定义网络技术的物理实现方式
  • Mechanism Drivers（机制驱动）: 定义网络访问的具体实现机制

Type Drivers对比

驱动 隔离方式 报文格式 VLAN支持 最大网络数 MTU开销
Flat 无标签 原始以太帧 ❌ 1 0
VLAN 802.1Q 以太帧+4B Tag ✅ 4094 4B
VXLAN VXLAN封装 MAC-in-UDP ❌ ~16M 50B
GRE GRE封装 MAC-in-GRE ❌ ~4G 42B
Geneve Geneve可变封装 MAC-in-UDP+TLV ❌ 理论上无限 50B+

Mechanism Drivers对比

驱动 组件 隧道支持 DPDK 复杂度
Open vSwitch OVS Agent + ovsdb VXLAN/GRE/Geneve ✅ 中
Linux Bridge LB Agent + bridge-utils VXLAN ❌ 低
SR-IOV SR-IOV Agent ❌（硬件VF直通） ✅ 中
MacVTap MacVTap Agent ❌ ✅ 低
L2 Population 辅助驱动 优化广播 N/A 辅助

配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# /etc/neutron/plugins/ml2/ml2_conf.ini
[ml2]
type_drivers = FLAT,VLAN,VXLAN
mechanism_drivers = openvswitch,l2population
tenant_network_types = VXLAN
extension_drivers = port_security

[ml2_type_flat]
flat_networks = provider

[ml2_type_vlan]
network_vlan_ranges = provider:100:200

[ml2_type_vxlan]
vni_ranges = 1:1000000

六、Open vSwitch 深度解析

OVS是Neutron最广泛使用的虚拟交换机，提供内核态高速转发 + 用户态灵活控制的双层架构。

三种核心OVS桥接

  • br-int（集成桥）: VM虚拟机的统一接入点，连接所有VM的tap设备
  • br-tun（隧道桥）: Overlay隧道（VXLAN/GRE）封装与解封装
  • br-ex（外部桥）: 连接物理网络的进出口

数据流转发路径

1
2
3
4
5
同节点VM通信: VM-1 tap → br-int流表匹配 → 直接转发 → VM-2 tap

跨节点VM通信（VXLAN）:
VM-1 tap → br-int → br-tun封装VXLAN → 物理网卡 → 物理网络
→ 目标节点物理网卡 → br-tun解封装 → br-int → VM-2 tap

OVS Agent配置

1
2
3
4
5
6
7
8
9
# /etc/neutron/plugins/ml2/openvswitch_agent.ini
[ovs]
bridge_mappings = provider:br-ex
local_ip = 10.0.0.1
tunnel_types = VXLAN
l2_population = True

[securitygroup]
firewall_driver = openvswitch

七、Linux Bridge 架构

Linux Bridge是内核原生网桥方案，架构更简单：

  • 实现: 内核桥接模块，无需用户态守护进程
  • 隧道: 支持VXLAN，不支持GRE
  • 安全组: 仅支持 iptables_hybrid
  • 管理工具: brctl / ip link
  • 复杂度: 低

LB Agent配置

1
2
3
4
5
6
7
8
9
10
11
12
# /etc/neutron/plugins/ml2/linuxbridge_agent.ini
[linux_bridge]
physical_interface_mappings = provider:ETH1

[vxlan]
enable_vxlan = True
local_ip = 10.0.0.1
l2_population = True

[securitygroup]
firewall_driver = iptables_hybrid
enable_security_group = True

OVS vs Linux Bridge 选型

  • OVS: 功能丰富（OpenFlow/QoS/DPDK/GRE），适合复杂SDN场景
  • Linux Bridge: 简单稳定，适合小规模部署或对复杂度敏感的环境
  • 趋势: OVN（基于OVS的SDN控制器）正逐步取代传统OVS Agent方案

八、SDN思想与虚拟网络实现

Neutron架构深刻体现了SDN的转控分离思想：

SDN原则 Neutron实现
控制与转发分离 Neutron Server ↔ Agent RPC通信，Server下发配置不参与数据转发
逻辑集中控制 统一API + ML2插件框架，全局网络视图统一策略
网络可编程 REST API创建/修改网络资源，OpenFlow流表动态下发

虚拟网络技术栈

1
2
3
4
5
6
7
8
9
10
11
物理层: 交换机 ── 路由器 ── 网卡
  │
隔离层: VLAN (硬件) / VXLAN (软件Overlay)
  │
虚拟交换: Open vSwitch (流表) / Linux Bridge (MAC学习)
  │
虚拟路由: L3 Agent (命名空间+NAT) / DVR (分布式路由)
  │
安全策略: Security Group (iptables / OVS流表 / OVN ACL)
  │
附加服务: DHCP (dnsmasq) / Metadata Agent / Octavia (LBaaS)

完整工作流：创建VM接入网络

1
2
3
4
用户 → NOVA-API →① NEUTRON PORT-CREATE →② 分配MAC+IP
  →③ NOVA-SCHEDULER选择计算节点 →④ RPC通知OVS AGENT
  →⑤ OVS-VSCTL ADD-PORT创建tap设备接入br-int
  →⑥ LIBVIRT启动VM插入网卡 →⑦ VM获取IP → ACTIVE

九、版本演进趋势 🚀

版本 核心变化
2025.1 Epoxy OVN成为默认ML2驱动，传统OVS Agent进入维护模式
2025.2 Flamingo OVN安全组性能增强，Port Group批量管理优化
2026.1 Gazpacho OVN稳定版，DSD-LB功能完善，8+新特性

主要趋势:

  • OVN取代传统OVS Agent: 原生分布式路由、分布式DHCP、OVN ACL安全组
  • OVN ACL取代iptables: OVS流表实现，支持万级规则规模（传统iptables约1000条即瓶颈）
  • DVR + OVN原生分布式: 东西流量完全本地转发
  • 硬件Offload: SR-IOV + OVS-DPDK加速VM网络性能逼近裸机

💡 技术解析

  • 术语: ML2 (Modular Layer 2) — Neutron核心插件框架，Type Driver定义网络技术类型，Mechanism Driver定义实现机制，双驱动支持多种L2网络技术共存。
  • 术语: VXLAN (Virtual Extensible LAN) — MAC-in-UDP隧道封装，24bit VNI支持1600万+虚拟网络，解决VLAN 4096上限问题，增加50B头部开销。
  • 术语: Network Namespace — Linux内核级隔离机制，独立网络栈。Neutron为每个路由器和DHCP服务创建独立namespace（qrouter-xxx / qdhcp-xxx），实现租户间L3隔离。
  • 术语: DVR (Distributed Virtual Router) — 分布式虚拟路由器，将L3路由分散到每个计算节点，东西流量本地转发避免绕行网络节点。
  • 术语: L2 Population — ARP/FDB表项预填充机制，替代广播泛滥，减少VXLAN/GRE网络中的BUM流量，提升大规模部署性能。
  • 术语: SNAT/DNAT — 源地址转换（SNAT）使内网VM可访问外网；目的地址转换（DNAT）使外网流量通过浮动IP到达内网VM。
  • 命令: openstack network create — 创建虚拟网络，--PROVIDER-NETWORK-TYPE 指定FLAT/VLAN/VXLAN，--PROVIDER-PHYSICAL-NETWORK 指定物理映射，--PROVIDER-SEGMENT 指定VLAN ID。
  • 命令: openstack security group rule create — 创建安全组规则，--PROTO 指定TCP/UDP/ICMP，--DST-PORT 指定端口范围，--REMOTE-GROUP 以安全组而非IP作为规则源，实现应用级微隔离。
  • 命令: openstack router set --external-gateway — 为路由器设置外部网关，结合 openstack router add subnet 将租户子网连接到路由器，实现内网与外网互通。
  • 命令: openstack floating ip create — 从外部网络分配浮动IP，openstack server add floating ip 将浮动IP绑定到VM实例，实现外网访问内网VM。

🔗 相关文档

OpenStack Neutron网络概念 | OpenStack Nova计算服务详解 | OpenStack Keystone详解

发表于 更新于 分类于 ，
全面解析OpenStack核心计算服务Nova的架构、虚拟化支持、虚拟机生命周期及调度策略

OpenStack Nova计算服务详解

一、Nova核心架构概览

Nova是OpenStack的计算编排控制器，采用 分布式、无状态、消息驱动 的设计哲学。所有核心组件通过 消息队列（RabbitMQ） 通信，状态统一存储在 SQL数据库 中。✨

架构全景图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
                       ┌──────────┐
                       │  Keystone │
                       └────┬─────┘
                            │ AUTH
                       ┌────▼─────┐
USER ──REST API──►  NOVA-API   │
                       └────┬─────┘
                            │ PUBLISH MSG
                  ┌─────────▼──────────┐
                  │   MESSAGE QUEUE     │ ◄── RABBITMQ
                  │  (OSLO.MESSAGING)  │
                  └──┬───┬──────┬───┬──┘
                     │   │      │   │
            ┌────────┘   │      │   └──────────┐
            ▼            ▼      ▼              ▼
      NOVA-SCHEDULER  NOVA-CONDUCTOR  NOVA-COMPUTE N
            │            │              │
            │            │              └──► LIBVIRT/KVM
            │            │              └──► XEN
            │            │              └──► VMWARE
            │            │
            │            └──► SQL DATABASE
            │
            └──► PLACEMENT API ──► RESOURCE INVENTORY

核心组件一览表

组件 状态类型 是否可水平扩展 职责一句话
nova-api 无状态 ✅ 是 ✅ RESTful API入口网关，对接Keystone认证
nova-scheduler 无状态 ✅ 是 ✅ 决定虚拟机跑在哪台物理机上
nova-conductor 有状态 🔶 是 ✅ 数据库安全代理层，Compute不得直连DB
nova-compute 有状态 🔶 是（每节点1个） 真实执行虚拟机操作的工作节点

二、四大核心组件深度解析 🧩

1️⃣ nova-api — 全局入口网关

职责: 接收并处理用户的RESTful API请求，是外部访问Nova的唯一途径。

1
2
3
4
5
6
7
8
9
10
┌─────────────── NOVA-API ───────────────┐
│                                         │
│  ① 接收 POST /SERVERS 请求              │
│  ② Keystone鉴权验证                     │
│  ③ Quota配额校验                        │
│  ④ DB写入初始记录（VM_STATE=BUILDING）   │
│  ⑤ 发布BOOT消息 → RabbitMQ              │
│  ⑥ 返回202 Accepted                     │
│                                         │
└─────────────────────────────────────────┘

关键特性:

  • 支持OpenStack原生API + Amazon EC2兼容API
  • 可通过keepalived + haproxy实现高可用负载均衡
  • 响应格式：创建类请求返回 202 Accepted（异步非阻塞）

2️⃣ nova-scheduler — 调度决策者 🎯

调度算法采用经典的两步走模型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
ALL COMPUTE NODES
       │
       ▼
┌──────────────────────┐
│  FILTERING 过滤阶段   │ ◄── 筛选满足条件的候选节点
│  RAMFILTER           │     内存是否充足？
│  COREFILTER          │     CPU核数是否够？
│  DISKFILTER          │     磁盘空间是否够？
│  AVAILABILITYZONEFIL │     可用区约束？
│  NUMATOPOLOGYFILTER  │     NUMA拓扑匹配？
└──────────┬───────────┘
           │
           ▼
┌──────────────────────┐
│  WEIGHTING 权重阶段   │ ◄── 对候选节点排序选最优
│  RAMWEIGHER          │     内存最大优先（默认）
│  CPUWEIGHER          │     CPU最充裕优先
│  DISKWEIGHER         │     磁盘最大优先
│  GROUPWEIGHER        │     亲和性/反亲和性
└──────────┬───────────┘
           │
           ▼
    TARGET HYPERVISOR

常用过滤器详解:

过滤器名称 过滤逻辑 典型场景
RamFilter 计算节点可用内存 ≥ 规格要求 通用场景
CoreFilter 可用CPU核数 ≥ 规格要求 通用场景
DiskFilter 可用磁盘空间 ≥ 规格要求 通用场景
AvailabilityZoneFilter 匹配用户指定的可用区 多AZ部署
NUMATopologyFilter 检查NUMA亲和性 CPU密集型工作负载
PciPassthroughFilter 检查PCI透传设备可用性 GPU/NIC透传
ImagePropertiesFilter 镜像属性匹配（架构类型等） 异构架构
AggregateInstanceExtraSpecsFilter 主机聚合标签匹配 GPU池/SSD池

调度策略组合示例:

1
2
3
4
5
6
# 调度器配置文件 /ETC/NOVA/NOVA.CONF
[DEFAULT]
scheduler_driver = task_based
scheduler_available_filters = nova.scheduler.filters.all_filters
scheduler_default_filters = RamFilter,CoreFilter,DiskFilter,AvailabilityZoneFilter,NUMATopologyFilter
scheduler_weight_classes = nova.scheduler.weights.all_weighers

3️⃣ nova-conductor — 安全代理层 🛡️

引入背景: G版本之前，nova-compute直接操作数据库带来了巨大的安全风险和升级兼容性问题。

核心价值: 禁止nova-compute直接访问数据库，所有数据库操作必须经Conductor代理。

1
2
3
4
5
6
NOVA-COMPUTE                     NOVA-CONDUCTOR                   SQL DB
    │                                  │                            │
    │── RPC CALL（请求实例信息）──────►   │                            │
    │                                  │── SQL QUERY ──────────────►│
    │                                  │◄── RETURN DATA ────────────│
    │◄── RPC RESPONSE（返回实例对象）───  │                            │

关键职责:

  • 数据库代理: Compute对数据库的所有读写必须走Conductor
  • 复杂流程协调: 负责创建、冷迁移、热迁移、resize、rebuild等长时间运行流程
  • 滚动升级兼容: 新旧版本Compute节点可通过Conductor通信
  • 依赖链: nova-compute必须依赖nova-conductor启动成功才能正常运行

4️⃣ nova-compute — 实际执行者 ⚙️

部署方式: 每台物理计算节点上运行一个实例，是Nova的核心”工人”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌────────────── NOVA-COMPUTE ──────────────┐
│                                           │
│  ┌─────────────┐  ┌──────────────────┐   │
│  │ MQ CONSUMER  │  │ RESOURCE TRACKER │   │
│  │ 消费消息队列  │  │ 资源统计&上报    │   │
│  └──────┬──────┘  └──────────────────┘   │
│         │                                  │
│  ┌──────▼──────┐  ┌──────────────────┐   │
│  │ COMPUTEDRIVER │  │ PERIODIC TASKS   │   │
│  │ 虚拟化驱动层 │  │ 周期性状态同步    │   │
│  └──────┬──────┘  └──────────────────┘   │
│         │                                  │
│  ┌──────▼──────┐                          │
│  │  HYPERVISOR  │                          │
│  │ KVM / XEN .. │                          │
│  └─────────────┘                          │
└───────────────────────────────────────────┘

三、虚拟化支持详解 🖥️

Nova通过 ComputeDriver驱动模式 屏蔽底层异构硬件的差异，所有Hypervisor对上层透明：

1
2
3
4
5
6
7
8
9
NOVA-COMPUTE
     │
     └── COMPUTEDRIVER（驱动抽象基类）
           ├── LibvirtDriver    → KVM / QEMU（主力生产驱动）
           ├── XenAPIDriver     → Xen XCP
           ├── VMwareVCDriver   → VMware vSphere ESXi
           ├── HyperVDriver     → Microsoft Hyper-V
           ├── IronicDriver     → 裸金属（无虚拟化层）
           └── LXCDriver        → Linux容器

KVM — 主力生产Hypervisor 🏆

1
2
3
4
5
6
7
USER REQUEST ──► NOVA-COMPUTE ──► LIBVIRT ──► KVM KERNEL MODULE
                           │                  └── INTEL VT-X / AMD-V
                           │
                           └── QEMU（DEVICE EMULATION）
                                ├── VIRTIO-NET（网卡）
                                ├── VIRTIO-BLK（磁盘）
                                └── UEFI / BIOS（固件）

性能关键配置:

1
2
3
4
5
6
7
8
# /ETC/NOVA/NOVA.CONF 虚拟化配置
[libvirt]
virt_type = kvm
cpu_mode = host-passthrough
cpu_model_extra_flags = pcid,ssbd,mds=on
images_type = qcow2
live_migration_permit_post_copy = true
live_migration_permit_auto_converge = true

技术优势:

  • 利用 Intel VT-x / AMD-V 硬件虚拟化扩展，性能接近裸机
  • 支持 NUMA 亲和性、CPU pinning、大页内存（Huge Pages）
  • 通过 libvirt 统一管理（virsh命令行或API）

QEMU — 设备模拟器 🛠️

  • 与KVM的关系: QEMU提供设备模拟+用户态接口，KVM提供硬件加速，二者常组合使用（qemu-kvm）
  • 纯模拟模式: 无KVM加速时可纯软件模拟（性能较低，常用于开发测试）
  • 2026.1 Gazpacho亮点:
    • live_migration_parallel_connections 并行热迁移
    • IOThread默认启用，磁盘I/O从vCPU线程卸载
    • UEFI固件自动选择（支持Secure Boot / AMD SEV）
    • QEMU AIO模式可配置（支持NFS/FC/iSCSI卷）

Xen — 裸机型Hypervisor 🛡️

  • 架构: Type-1（裸机型），直接运行在硬件上
  • 组成: Domain 0（管理域）+ Domain U（用户虚拟机）
  • 驱动: 通过 XenAPIDriver 或 LibvirtDriver（Xen模式）集成
  • 特点: 安全性极高，半虚拟化性能优越，市场份额较少

其他虚拟化平台

平台 集成方式 适用场景
VMware vSphere VMwareVCDriver → vCenter API 企业VMware存量迁移
Hyper-V HyperVDriver → WMI / PowerShell Windows生态整合
Ironic（裸金属） IronicDriver → PXE + IPMI 高性能计算、DB裸机部署
LXC LXCDriver → LinuxContainers 轻量容器化场景

四、虚拟机完整生命周期 📋

创建流程详解（核心链路）

以 POST /servers 创建虚拟机为例，展示全链路15步交互：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
STEP 1: 用户发起请求
  POST /SERVERS
  └── NOVA-API 接收
       ├── KEYSTONE 鉴权
       ├── QUOTA 校验
       ├── DB写入: VM_STATE=BUILDING
       └── BOOT消息 → RABBITMQ（RPC CAST）

STEP 2: 调度决策
  NOVA-SCHEDULER 消费消息
       ├── PLACEMENT API 查询可用资源
       ├── FILTER + WEIGHT 选最优节点
       └── BUILD_AND_RUN_INSTANCE → 目标节点（RPC CAST）

STEP 3: 实例化执行
  NOVA-COMPUTE 接收消息
       ├── RPC CALL → NOVA-CONDUCTOR 获取数据
       ├── PLACEMENT API 资源预留
       ├── GLANCE 下载镜像 → 创建磁盘
       ├── NEUTRON 配置网络（创建PORT、分配IP）
       ├── CINDER 对接云硬盘（若有）
       └── HYPERVISOR SPAWN() → 启动VM

STEP 4: 同步状态
  NOVA-COMPUTE → DB更新
       ├── VM_STATE = ACTIVE
       └── TASK_STATE = NONE

生命周期状态机 🔄

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
                ┌──────────┐
                │ BUILDING │
                └────┬─────┘
                     │
                ┌────▼─────┐
     ┌──────────► ACTIVE   ◄──────────┐
     │          └────┬─────┘          │
     │               │                │
┌────▼───┐    ┌──────▼──────┐   ┌─────▼─────┐
│ PAUSED │    │ RESIZED     │   │  STOPPED  │
└────┬───┘    └──────┬──────┘   └─────┬─────┘
     │               │                │
     │          ┌────▼─────┐    ┌─────▼─────┐
     │          │ VERIFY   │    │  SHELVED  │
     │          └──────────┘    └─────┬─────┘
     │                               │
     │                          ┌────▼─────┐
     └──────────────────────────►  DELETED │
                                 └──────────┘
vm_state 含义 触发操作
BUILDING 正在构建 nova boot
ACTIVE 正常运行中 创建成功
PAUSED 已暂停（内存保留） nova pause
STOPPED 已关机（磁盘保留） nova stop
RESIZED 规格调整中 nova resize
SHELVED 已搁置（释放计算资源） nova shelve
ERROR 出错状态 操作失败
DELETED 已删除 nova delete

常用管理命令:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 创建并启动虚拟机
openstack server create --flavor FLAVOR_ID --image IMAGE_ID --network NET_ID VM_NAME

# 查看虚拟机列表
openstack server list

# 暂停/恢复
openstack server pause VM_NAME
openstack server unpause VM_NAME

# 关机/开机
openstack server stop VM_NAME
openstack server start VM_NAME

# 搁置/取消搁置（释放资源保留磁盘）
openstack server shelve VM_NAME
openstack server unshelve VM_NAME

# 删除
openstack server delete VM_NAME

# 查看控制台日志
openstack console log show VM_NAME

# 获取VNC控制台URL
openstack console url show VM_NAME

五、Placement API — 资源管理独立服务 🗂️

引入版本: Newton版本从nova-scheduler中剥离

核心功能:

1
2
3
4
5
6
PLACEMENT API
     │
     ├── RESOURCE PROVIDER  （资源提供者）→ 物理计算节点
     ├── INVENTORY          （库存）       → CPU/RAM/DISK总量
     ├── ALLOCATION         （分配）       → 已分配给哪些实例
     └── TRAIT              （特征标签）    → GPU/NUMA/加密等标记
  • 统一资源管理: 不仅服务于Nova，也服务于Cyborg（加速器）、Magnum（容器）等
  • 资源类型: CPU、内存、磁盘、GPU、FPGA、NUMA节点、PCI设备
  • Trait标签: 支持自定义硬件特征标签，实现trait-based调度

六、Cells v2 — 大规模部署架构 🌐

解决痛点: 单点RabbitMQ和MySQL在高并发场景下成为瓶颈。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
       ┌────────────────────────────────┐
       │       API CELL（全局控制面）      │
       │  NOVA-API + PLACEMENT API       │
       │  全局CELL映射表 DB                │
       └──────┬──────────────┬───────────┘
              │              │
┌─────────────▼──┐    ┌─────▼─────────────┐
│  CELL 1 DC-A   │    │  CELL 2 DC-B      │
│  CELL DATABASE  │    │  CELL DATABASE     │
│  CELL MQ        │    │  CELL MQ           │
│  NOVA-SCHEDULER │    │  NOVA-SCHEDULER    │
│  NOVA-CONDUCTOR │    │  NOVA-CONDUCTOR    │
│  NOVA-COMPUTE N │    │  NOVA-COMPUTE N    │
└────────────────┘    └────────────────────┘

核心优势:

  • Cell0: 特殊Cell，记录失败或未调度实例，保护主数据库
  • 隔离性: 每个Cell独立MQ+DB，单点故障不扩散
  • 水平扩展: 新增Cell即可扩展集群规模
  • 跨数据中心: 适用于多地域部署

七、RabbitMQ通信模型详解 📨

Nova的RPC通信基于 oslo.messaging 库，支持三种交换模式：

Exchange类型 路由模式 用途
nova Topic 主体通信：指向特定组件队列
reply.<UUID> Direct 同步RPC call的结果返回
compute.fanout Fanout 广播消息（如调度器缓存刷新）

路由Key示例:

1
2
3
4
5
6
7
8
# 路由到特定计算节点
ROUTING_KEY: COMPUTE.HOSTNAME01  →  HOST01的NOVA-COMPUTE队列

# 路由到调度器
ROUTING_KEY: SCHEDULER           →  NOVA-SCHEDULER队列

# 路由到控制器
ROUTING_KEY: CONDUCTOR           →  NOVA-CONDUCTOR队列

八、2025-2026 版本演进 🚀

版本 发布日期 类型 核心亮点
2025.1 Epoxy 2025.04 SLURP ✅ 支持跳跃升级，打好基础
2025.2 Flamingo 2025.10 常规 机密计算、一次性设备透传
2026.1 Gazpacho 2026.04 SLURP ✅ 9大新特性，重点对标VMware替换

2026.1 Gazpacho 亮点 🌟

高频重点功能:

1
2
3
4
5
# 并行热迁移配置
[libvirt]
live_migration_permit_post_copy = true
live_migration_permit_auto_converge = true
live_migration_parallel_connections = 3
特性 影响 技术要点
🔄 并行热迁移 大幅提升迁移速度 QEMU multifd多连接传输，需QEMU≥10.1.0
🔐 vTPM热迁移 Windows 11迁移支持 Barbican托管TPM密钥，RPC传输
⚡ IOThread默认启用 磁盘I/O性能提升 每个VM独立IOThread，RT实例CPU绑定
⏳ 异步挂载卷 API响应速度提升 microversion 2.101，HTTP 202非阻塞
🧵 原生线程化 服务性能与稳定性 scheduler/api默认原生线程，eventlet逐步退役
🛑 优雅关闭 零中断升级 SIGTERM处理，二次RPC Server保障
🔧 UEFI自动选择 简化固件配置 libvirt自动选型，支持Secure Boot/AMD SEV
📜 OpenAPI全覆盖 API可观测性提升 JSON Schema覆盖所有端点
🏷️ Trait调度 精准匹配硬件特征 自定义标签匹配GPU、FPGA、加密加速器

九、架构设计哲学总结 🎯

设计原则 具体实现
无状态与水平扩展 nova-api/scheduler无状态，状态全部存储在MySQL
异步通信与最终一致性 大量使用RPC cast而非call，高吞吐量优先
驱动化架构 ComputeDriver抽象层，屏蔽底层Hypervisor差异
资源供应分离 Placement API独立管理资源，调度与资源解耦
安全代理模式 nova-conductor作为DB代理，防线前移
分片隔离 Cells v2分片部署，故障域隔离
滚动升级兼容 conductor屏蔽DB差异，支持混合版本部署

💡 技术解析

  • 术语: RPC Cast vs Call — Cast是单向异步（fire-and-forget），发送后立即返回；Call是双向同步，等待响应。Nova内部默认用Cast保证吞吐量，Compute查询数据时用Call同步等待。
  • 术语: Placement API — Newton版本从Scheduler剥离的独立资源追踪服务，统一管理CPU/内存/磁盘/GPU/NUMA的分配与释放。
  • 术语: Resource Tracker — nova-compute内部资源统计模块，周期性刷新本节点可用资源并上报Placement API。
  • 术语: Cells v2 — 大规模部署的分片架构，每个Cell独立MQ + DB，Cell0记录失败实例，API Cell负责全局路由。
  • 术语: NUMA — 非统一内存访问架构，CPU访问本地内存vs远端内存延迟不同。NUMA感知调度确保vCPU和内存分配到同一NUMA节点。
  • 术语: vTPM — 虚拟可信平台模块，为虚拟机提供硬件级安全能力。Windows 11强制要求TPM 2.0。
  • 术语: Trait-based Scheduling — 通过自定义特征标签匹配工作负载与硬件特性的调度策略，如标记计算节点是否包含GPU、FPGA、加密加速器。
  • 命令: openstack server create — 创建虚拟机实例，常用参数：--FLAVOR 指定规格，--IMAGE 指定镜像，--NETWORK 指定网络，--KEY-NAME 指定密钥对，--AVAILABILITY-ZONE 指定可用区。
  • 命令: openstack server shelve — 搁置虚拟机，释放计算资源但保留磁盘和内存快照，节省资源的同时可随时恢复。

🔗 相关文档

OpenStack Nova计算服务概念 | OpenStack Keystone详解 | OpenStack Neutron网络服务详解 | OpenStack Cinder块存储详解

发表于 更新于 分类于 ，
全面解析OpenStack Swift对象存储的Account/Container/Object三层数据模型、一致性哈希Ring、数据冗余机制、核心组件及生产应用场景

OpenStack Swift对象存储详解

一、Swift核心架构概览

Swift是OpenStack的分布式对象存储核心组件，为云平台提供高可用、可扩展、低成本的非结构化数据存储。由 Rackspace 开发并于 2010 年贡献给 OpenStack 社区，使用普通硬件即可构建 PB 级存储集群，无需 RAID，通过软件层面的一致性哈希与多副本机制保障数据安全。🗄️

架构全景图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
                     ┌──────────┐
                     │ Keystone │
                     └────┬─────┘
                          │ AUTH
                     ┌────▼─────┐
USER ──HTTP REST────►  PROXY   │
（PUT/GET/DELETE）    │ SERVER  │
                     └────┬─────┘
                          │ Ring Lookup
                          │
            ┌─────────────┼─────────────┐
            ▼             ▼             ▼
      ┌──────────┐ ┌──────────┐ ┌──────────┐
      │ACCOUNT   │ │CONTAINER │ │ OBJECT   │
      │ SERVER   │ │ SERVER   │ │ SERVER   │
      └────┬─────┘ └────┬─────┘ └────┬─────┘
           │            │            │
      ┌────▼────┐ ┌────▼────┐ ┌────▼────┐
      │ SQLite  │ │ SQLite  │ │  XFS    │
      │ Account │ │Container│ │Object   │
      │   DB    │ │   DB    │ │  File   │
      └─────────┘ └─────────┘ └─────────┘
                           │
            ┌──────────────┼──────────────┐
            ▼              ▼              ▼
       Replicator      Updater        Auditor
        (rsync)      (异步更新)      (完整性审计)

核心组件一览表

组件 职责 说明
Proxy Server RESTful API 入口网关 校验令牌、查询 Ring 路由请求，无状态可横向扩展
Account Server 账户元数据服务 管理账户内容器列表，存储在 SQLite 数据库中
Container Server 容器元数据服务 管理容器内对象列表，跟踪对象计数与字节总量
Object Server 对象存储服务 对象数据的存储/检索/删除，文件 + xattr 元数据
Replicator 副本同步守护进程 采用 Push 模式，通过 rsync 检测并校正副本不一致
Updater 异步更新守护进程 处理高负载下失败的容器/账户更新（最终一致性的来源）
Auditor 完整性审计守护进程 扫描对象/容器/账户完整性，隔离损坏数据并触发修复
Account Reaper 账户回收守护进程 异步删除标记为删除的账户及其所有容器和对象

架构设计哲学 — 完全对称 + 最终一致性

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
对象存储设计理念:

┌─────────────────────────────────────────────────────┐
│  控制路径 (Control Path)                              │
│  ├── Proxy Server → Ring 查询 → 路由请求               │
│  ├── Token 鉴权（Keystone 对接）                       │
│  └── 无状态设计，所有节点对等                           │
├─────────────────────────────────────────────────────┤
│  数据路径 (Data Path)                                 │
│  ├── 对象数据直接写入 Object Server                    │
│  ├── Replicator 后台异步同步副本                       │
│  ├── Updater 异步更新容器/账户列表                      │
│  └── Auditor 定期扫描修复                              │
├─────────────────────────────────────────────────────┤
│  CAP 理论定位: AP + 最终一致性                         │
│  ├── 可用性 (Availability): ✅ 高可用                  │
│  ├── 分区容忍 (Partition Tolerance): ✅ 支持            │
│  └── 一致性 (Consistency): 最终一致（R+W > N 保证）    │
└─────────────────────────────────────────────────────┘

关键设计理念: Swift 不追求强一致性，而是通过 Quorum 仲裁 + 后台守护进程实现最终一致性。副本写入不要求全部成功即可返回，不一致状态由 Replicator/Updater 从后台修复。这种设计使得 Swift 在普通硬件上支持无限水平扩展和高可用性。🚀

二、Account / Container / Object 三层数据模型 🧱

Swift 采用完全对称、面向资源的分层架构，数据模型共设三层逻辑隔离：

1
2
3
Account (账户/租户)
   └── Container (容器)
          └── Object (对象)
层级 含义 存储形式 存储引擎
Account 账户/租户，顶层多租户隔离机制 元数据 + 容器列表 SQLite 数据库
Container 容器，用户自定义的”桶”，类似文件夹概念 元数据 + 对象列表 SQLite 数据库
Object 对象，数据体 + 自定义元数据 二进制文件 + xattr XFS 文件系统

数据模型关键特性 🔑

1
2
3
4
5
6
7
8
9
10
对象名称 Flat Namespace:
  ┌─────────────────────────────────────┐
  │  /v1/AUTH_project/container/obj     │
  │      ↕          ↕        ↕          │
  │    Account    Container  Object     │
  │                                     │
  │  对象名称中的 '/' 仅是名字的一部分：    │
  │  container/photos/2026/01/photo.jpg │
  │          ↕ 无真实目录层级 ↕           │
  └─────────────────────────────────────┘
  • Flat Namespace: 对象名支持 / 字符模拟目录层级，但无真正目录树结构
  • 单对象限制: 最大 5GB，超出需使用 SLO（静态大对象）/ DLO（动态大对象）分段上传
  • 元数据存储: 对象元数据存储在文件系统的 **xattr（扩展属性）**中，最大 4KB
  • 多租户隔离: 每个账户独立 namespace，AUTH_<project_id> 为默认账户前缀

三种实体各自拥有独立 Ring 映射

1
2
3
account.ring.gz    →  Account Server 集群映射
container.ring.gz  →  Container Server 集群映射
object.ring.gz     →  Object Server 集群映射

三、核心组件深度解析 🧩

1️⃣ Proxy Server — 请求入口网关

Proxy Server 是 Swift 对外的唯一入口，所有客户端请求必经此处。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Proxy Server 请求处理流水线:

1. 接收 HTTP 请求 (PUT / GET / DELETE / HEAD)
2. Keystone Token 鉴权验证
3. 解析路径 → Account/Container/Object
4. 查询对应 Ring 获取目标节点列表
5. 并发转发请求到所有副本节点
6. 等待 Quorum（W 个写成功 / R 个读成功）
7. 聚合响应返回客户端

特性:
  ├── 流式传输：对象数据流式通过，不缓冲到磁盘
  ├── 无状态：无本地状态，可任意横向扩展
  ├── Handoff 支持：主节点失败自动路由到 Handoff 节点
  └── 存储策略感知：2.x+ 支持多 Ring 策略路由

Proxy Server 中间件链:

1
2
3
4
5
6
7
8
WSGI Pipeline 中的中间件（按顺序执行）:
  ├── healthcheck        → 健康检查端点
  ├── keystoneauth       → Token 鉴权
  ├── proxy-logging      → 访问日志
  ├── bulk              → 批量操作
  ├── tempurl            → 临时 URL
  ├── ratelimit          → 请求限速
  └── proxy-server       → 核心代理服务

2️⃣ Account / Container / Object Server — 存储节点三驾马车

Account Server:

1
2
3
4
5
职责:
  └── 管理账户元数据（容器列表 + 统计信息）
       ├── 使用 SQLite 存储
       ├── 记录各容器对象数量和总字节数
       └── 响应 HEAD 请求返回统计信息

Container Server:

1
2
3
4
5
6
职责:
  └── 管理容器元数据（对象列表 + 统计信息）
       ├── 使用 SQLite 存储
       ├── 维护对象列表（按名称排序）
       ├── 记录对象计数和总字节数
       └── 支持容器 ACL 访问控制

Object Server:

1
2
3
4
5
6
7
8
9
10
11
12
职责:
  └── 对象数据存储与检索
       ├── 以文件形式存储在 XFS 文件系统
       ├── 元数据存储在文件 xattr（扩展属性）
       ├── 基于时间戳的版本管理（Last-Write-Wins）
       ├── 墓碑文件（.ts）标记删除
       └── 支持对象分段上传的合并与读取

时间戳文件:
  ├── {TIMESTAMP}.DATA  → 对象数据文件
  ├── {TIMESTAMP}.META  → 元数据更新文件
  └── {TIMESTAMP}.TS    → 墓碑（0字节删除标记）

3️⃣ Replicator — 副本一致性守护者 🔄

Replicator 负责检测并修复副本不一致，采用 Push 推送模式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Replicator 工作循环:

  ┌─────────────────────────────────────┐
  │ 周期扫描本地所有分区文件              │
  │                                      │
  │ 对每个文件：                          │
  │  1. 查询 Ring 获取该分区的所有副本节点  │
  │  2. 通过 rsync 与远端节点比对          │
  │  3. 若本地文件更新 → push 到远端       │
  │  4. 若远端文件更新 → 本地会被覆盖       │
  │  5. 若本地有墓碑 → push 墓碑到远端      │
  │                                      │
  │ 同步对象：
  │  ├── rsync + hash 比对（对象文件）     │
  │  └── HTTP 或 rsync（SQLite 数据库）    │
  └─────────────────────────────────────┘

关键特性:

  • Push 模式的理由: Object Server 只读写入的文件，不主动拉取，Replicator 作为 Push 端主动同步
  • 数据库同步: 记录差异小于 1% 时使用 SQLite 差量同步，否则全量传输
  • 同步范围: 对象文件、容器数据库、账户数据库

4️⃣ Updater — 异步更新队列 ⏰

当高负载或节点故障导致容器/账户更新失败时，Updater 将更新任务序列化到本地队列异步处理：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
处理流程:
  PUT 对象 → Proxy Server
       │
       ├── Object Server 写入成功 ✅
       │
       └── Container Server 更新失败 ❌（高负载/temporary unavailable）
                │
                ▼
          写入本地 async_pending 队列
                │
                ▼
           Updater 周期性重试
                │
                ▼
          容器列表最终更新 ✅

这就是最终一致性的主要来源：容器对象列表可能短暂滞后，Updater 保证最终收敛。

5️⃣ Auditor — 完整性审计 🔍

1
2
3
4
5
6
7
8
9
10
周期性扫描:
  ├── 对象审计: 读取文件内容，校验 xattr 元数据一致性
  ├── 容器审计: 校验 SQLite 数据库完整性
  └── 账户审计: 校验 SQLite 数据库完整性

发现问题:
  └── 将损坏文件移动到 /srv/node/{DEVICE}/quarantined/
       ├── 隔离文件不自动删除
       ├── Replicator 检测到缺失后从副本同步恢复
       └── 运维人员可分析隔离区的损坏文件

四、一致性哈希与 Ring 🎯

Ring — 最核心的数据结构

Ring 是 Swift 的灵魂，记录逻辑路径 → 物理位置的映射关系。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Ring 数据结构:

┌─────────────────────────────────────────┐
│              Ring 对象                   │
├─────────────────────────────────────────┤
│  devs: [                                 │
│    {id:0, zone:1, weight:100,           │
│     ip:"10.0.0.1", port:6200,           │
│     device:"sdb1"},                     │
│    {id:1, zone:2, weight:200, ...},     │
│    ...                                   │
│  ]                                       │
├─────────────────────────────────────────┤
│  _replica2part2dev_id: [                 │
│    [dev_id_A, dev_id_B, dev_id_C],  ← Partition 0 的 3 个副本
│    [dev_id_D, dev_id_E, dev_id_F],  ← Partition 1 的 3 个副本
│    ...                                   │
│  ]                                       │
├─────────────────────────────────────────┤
│  part_shift: 4           ← 分区移位位数  │
│  replica_count: 3        ← 副本数       │
│  part_power: 10          ← 总分区数 2^10│
└─────────────────────────────────────────┘

物理隔离层级（故障域）

1
2
3
4
5
6
7
8
Region (地理区域: 数据中心)
   └── Zone (硬件隔离: 机架/交换机)
        └── Node (服务器节点)
             └── Device (磁盘设备)

Swift 原则:
  同一 Partition 的 Replica 必须分布在不同 Zone 内
  确保任意 Zone 故障不影响所有副本

数据路由流程 🧭

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
对象路径: /v1/AUTH_acc/container/object
                  │
             计算 MD5 哈希
                  │
             取前 4 字节
                  │
        右移 part_shift 位
                  │
   ┌──────────────┴──────────────┐
   │     得到分区编号 Partition   │
   └──────────────┬──────────────┘
                  │
     _replica2part2dev_id[Partition]
                  │
   ┌──────────────┼──────────────┐
   ▼              ▼              ▼
 设备 A (Zone 1) 设备 B (Zone 2) 设备 C (Zone 3)
  ── 主副本 ──  ── 副本 ──  ── 副本 ──
                  │
   Proxy Server 将请求同时发往所有副本节点

虚拟节点（Partition）机制

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
物理节点与虚拟节点的关系:

   ┌─────────────────────────────────────────┐
   │  总分区数 = 2^part_power               │
   │                                        │
   │  每个物理节点包含 N 个虚拟分区:           │
   │    分区数 ≈ (节点权重 / 总权重) × 总分区数 │
   │                                        │
   │  增减节点的影响:                         │
   │    仅重新分配受影响的分区                │
   │    移动比例 ≈ 1 / 总节点数              │
   │    100 节点集群中仅移动 1% 数据          │
   └─────────────────────────────────────────┘

优势:
  ├── 数据自动均匀分布
  ├── 节点增减仅影响少数分区
  └── 权重支持异构磁盘（如 2TB 权重=100, 4TB 权重=200）

Ring 构建与维护命令 🔧

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# 1. 创建 Ring
swift-ring-builder OBJECT_BUILDER create PART_POWER REPLICAS MIN_PART_HOURS

# 参数:
#   PART_POWER     分区幂次，总分区数 = 2^PART_POWER（推荐 10~15）
#   REPLICAS       副本数（默认 3）
#   MIN_PART_HOURS 分区最小移动间隔（小时），防止 Rebalance 抖动


# 2. 添加设备
swift-ring-builder OBJECT_BUILDER add Z{ZONE}-{IP}:{PORT}/{DEVICE} WEIGHT

# 参数:
#   Z{ZONE}    故障域编号（如 z1, z2, z3）
#   {IP}       存储节点 IP
#   {PORT}     Object Server 端口（默认 6200）
#   {DEVICE}   磁盘设备名称（如 sdb1）
#   WEIGHT     设备权重（按磁盘容量比例）


# 3. 重新平衡（自动最小化数据移动）
swift-ring-builder OBJECT_BUILDER rebalance

# 4. 查看 Ring 信息
swift-ring-builder OBJECT_BUILDER


# 完整示例（3 节点，3 Zone，每节点 2 块磁盘）:
swift-ring-builder object.builder create 12 3 1
swift-ring-builder object.builder add z1-10.0.0.1:6200/sdb1 100
swift-ring-builder object.builder add z1-10.0.0.1:6200/sdc1 100
swift-ring-builder object.builder add z2-10.0.0.2:6200/sdb1 100
swift-ring-builder object.builder add z2-10.0.0.2:6200/sdc1 100
swift-ring-builder object.builder add z3-10.0.0.3:6200/sdb1 100
swift-ring-builder object.builder add z3-10.0.0.3:6200/sdc1 100
swift-ring-builder object.builder rebalance

五、数据冗余与一致性模型 🛡️

Quorum 仲裁协议

Swift 采用 Quorum 仲裁实现最终一致性：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
写入流程:
  PUT /v1/AUTH_acc/container/object
       │
       ├── 查询 Object Ring → 3 个目标节点（Zone 1, 2, 3）
       │
       ├── Proxy 并发向 3 个 Object Server 发送数据
       │
       ├── 等待至少 W 个成功响应（W=2）
       │
       └── 返回 201 Created 给客户端
                │
         ┌──────┴──────┐
         │             │
      ✅ 成功        ❌ < 2 个成功
                   └── 写入失败，返回 503

读取流程:
  GET /v1/AUTH_acc/container/object
       │
       ├── 查询 Object Ring → 3 个目标节点
       │
       ├── 向 3 个节点发送 GET 请求
       │
       ├── 默认: 等待 1 个成功即返回（R=1，弱一致性）
       │
       │  或使用 X-Newest: true:
       │  └── 对比多个副本的时间戳，返回最新版本（R=2，强一致性）
       │
       └── 返回对象数据 + 元数据
参数 Swift 默认值 说明
N 3 每个对象存储 3 个副本
W 2 写操作需 ≥2 个副本确认才算成功
R 1（可调至 2） 读操作 1 个副本成功即返回

一致性保证: R + W > N（保证读写副本集有交集，避免读取到过期数据）

模式 R W 一致性强度 性能影响
弱一致性（默认） 1 2 最终一致 最高性能
强一致读 2 2 接近强一致 读性能下降
强一致写 1 3 写后即可读 写性能下降

数据冗余保障机制 🏗️

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
多副本冗余分布:

  ┌── Region 1 ──────────────────────┐
  │  ┌── Zone 1 ──┐ ┌── Zone 2 ──┐  │
  │  │  Node 1     │ │  Node 2     │  │
  │  │  ┌──┐ ┌──┐│ │ ┌──┐ ┌──┐│  │
  │  │  │R1│ │D1││ │ │R2│ │D2││  │
  │  │  └──┘ └──┘│ │ └──┘ └──┘│  │
  │  └───────────┘ └───────────┘  │
  └───────────────────────────────┘
         │
  ┌── Region 2 ──────────────────────┐
  │  ┌── Zone 3 ──┐                  │
  │  │  Node 3     │                  │
  │  │  ┌──┐ ┌──┐│                  │
  │  │  │R3│ │D3││                  │
  │  │  └──┘ └──┘│                  │
  │  └───────────┘                   │
  └──────────────────────────────────┘

  R = 副本 (Replica), D = 非副本数据
  N=3, 跨 Region 分布: Region 1 放 2 副本, Region 2 放 1 副本

数据冗余措施一览:

机制 工作方式 触发条件
多副本冗余 默认 3 副本，跨 Zone 分布 数据写入时自动创建
Handoff 节点 主节点不可用时写入临时 Handoff 节点 主节点故障/离线
Replicator Push 模式 rsync 同步副本差异 周期性后台运行
Updater 序列化失败更新至 async_pending 队列 容器/账户更新失败
Auditor 扫描完整性，隔离损坏文件 周期性后台运行
Tombstone 创建 .ts 空文件标记删除 DELETE 请求触发
跨 Region 副本分布在不同数据中心 Ring 配置多个 Region

Handoff 节点故障转移流程:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
主节点 A 不可用
     │
     ▼
Proxy 尝试写入 → 超时/连接失败
     │
     ▼
查询 Ring 中的 Handoff 节点列表
     │
     ▼
写入 Handoff 节点 H 成功 ✅
     │
     ▼
主节点 A 恢复
     │
     ▼
Replicator 检测到 H 上有 A 的数据
     │
     ▼
Replicator 将数据从 H 复制回 A
     │
     ▼
从 H 删除临时数据，恢复正常拓扑

六、数据存储结构详解 📁

磁盘目录结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
/srv/node/{DEVICE}/
├── accounts/                    账户数据库
│   └── {PARTITION}/
│       └── {SUFFIX}/
│           └── {HASH}/
│               └── {ACCOUNT}.db  ← SQLite 数据库文件
│
├── containers/                  容器数据库
│   └── {PARTITION}/
│       └── {SUFFIX}/
│           └── {HASH}/
│               └── {CONTAINER}.db  ← SQLite 数据库文件
│
├── objects/                     对象数据
│   └── {PARTITION}/
│       └── {SUFFIX}/
│           └── {HASH}/
│               ├── {TIMESTAMP}.DATA   对象数据文件
│               ├── {TIMESTAMP}.META   元数据更新文件
│               └── {TIMESTAMP}.TS     墓碑文件（0字节）
│
├── async_pending/               异步待更新队列
│
├── quarantined/                 隔离目录（损坏数据）
│
└── tmp/                         临时写入目录

说明:
  {PARTITION}:   Ring 计算出的分区号
  {SUFFIX}:      Hash 值的后 3 位（目录散列，避免单目录文件过多）
  {HASH}:        MD5 哈希值
  {TIMESTAMP}:   Unix 时间戳（精确到微秒）

文件系统要求

属性 要求
类型 XFS（推荐，支持 xattr）
atime 关闭（noatime 挂载）
inode 足够大（每个对象至少 1 个 inode）
xattr 必须支持（存储对象元数据，默认 4KB 上限）

xattr 存储内容:

1
2
3
4
5
6
7
user.swift.metadata:
  ├── name              对象名称
  ├── content-length    对象大小
  ├── content-type      MIME 类型
  ├── etag              MD5 校验值
  ├── x-object-meta-*   自定义元数据
  └── timestamp         写入时间戳

七、存储策略（Storage Policies, Swift 2.0+）🎯

Swift 2.x 版本引入存储策略机制，支持在 Container 级别指定不同策略：

1
2
3
4
5
6
7
8
# 查看可用策略
swift --os-storage-url <URL> stat

# 创建带策略的容器
openstack container create --STORAGE-POLICY gold-container gold-bucket

# 列出存储策略
swift-list-policies

策略类型

策略 副本数 适用场景
3 副本（默认） 3 关键数据、生产环境
2 副本 2 非关键数据、成本敏感场景
EC（纠删码） 数据分片 + 校验 大容量归档，同一冗余度下存储效率更高

EC vs 副本对比:

1
2
3
4
5
6
3 副本方案:
  数据量: 100GB  实际占用: 300GB  可用率: 33%

EC (6+3) 方案:
  数据量: 100GB  实际占用: 150GB  可用率: 66%
  承受故障: 任意 3 块磁盘

多 Ring 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# /etc/swift/swift.conf
[storage-policy:0]
name = gold
policy_type = replication
default = yes
aliases = gold,3x

[storage-policy:1]
name = silver
policy_type = replication
aliases = silver,2x

[storage-policy:2]
name = archive
policy_type = erasure_coding
ec_type = liberasurecode_rs_vand
ec_num_data_fragments = 6
ec_num_parity_fragments = 3
ec_object_segment_size = 1048576

八、数据流详解 🌊

PUT 写入完整流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
客户端:
  PUT /v1/AUTH_acc/container/object
  └── Content-Length, Content-Type, ETag, X-Auth-Token

Proxy Server:
  ① 验证 Token（Keystone）
  ② 解析路径 → Account=acc, Container=container, Object=object
  ③ 查询 Object.Ring → 分区 1324 → [设备A Zone1, 设备B Zone2, 设备C Zone3]
  ④ 并发流式写入 3 个 Object Server（不缓冲）

Object Server (3 个节点并行):
  ① 接收数据流
  ② 写入 tmp/ 临时目录
  ③ 校验 ETag（MD5）一致性
  ④ 写入 XFS 持久化
  ⑤ 将元数据写入 xattr
  ⑥ 重命名到 objects/{PARTITION}/{SUFFIX}/{HASH}/{TIMESTAMP}.DATA

Proxy Server:
  ⑦ 等待 W=2 个节点成功 ✅
  ⑧ 返回 201 Created

后台 (异步):
  ⑨ 异步更新 Container 对象列表（若失败则 Updater 排队重试）

GET 读取完整流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
客户端:
  GET /v1/AUTH_acc/container/object
  └── X-Auth-Token

Proxy Server:
  ① 验证 Token（Keystone）
  ② 查询 Object.Ring → 分区 1324 → [设备A Zone1, 设备B Zone2, 设备C Zone3]
  ③ 并发向 3 个 Object Server 发起 GET

Object Server (3 个节点):
  ④ 查找 {PARTITION}/{SUFFIX}/{HASH}/{TIMESTAMP}.DATA
  ⑤ 验证 xattr 元数据完整性
  ⑥ 流式返回数据

Proxy Server:
  ⑦ 默认: 取最快返回的一个（R=1）
     或 X-Newest: 取时间戳最新的一个（R=2）
  ⑧ 流式传输给客户端（不缓冲到磁盘）

DELETE 删除流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
客户端:
  DELETE /v1/AUTH_acc/container/object

Proxy Server:
  ① 验证 Token → 查询 Ring → 路由到 3 个副本节点
  ② 并发发送 DELETE 请求

Object Server (3 个节点):
  ③ 不直接删除 .data 文件
  ④ 创建 {TIMESTAMP}.TS 墓碑文件（0字节）
  ⑤ 墓碑的 .ts 时间戳 > .data 文件时间戳

后续:
  ⑥ Replicator 将墓碑传播到所有副本
  ⑦ Auditor 日后扫描时清理旧 .data 文件
  ⑧ Container 对象列表中移除该对象

九、API 与常用操作 📋

RESTful API 端点

方法 URL 功能
GET /v1/{ACCOUNT} 获取账户信息、容器列表
GET /v1/{ACCOUNT}/{CONTAINER} 获取容器内对象列表
PUT /v1/{ACCOUNT}/{CONTAINER}/{OBJECT} 上传对象
GET /v1/{ACCOUNT}/{CONTAINER}/{OBJECT} 下载对象
DELETE /v1/{ACCOUNT}/{CONTAINER}/{OBJECT} 删除对象
HEAD /v1/{ACCOUNT}/{CONTAINER}/{OBJECT} 获取对象元数据
POST /v1/{ACCOUNT}/{CONTAINER}/{OBJECT} 更新对象元数据

常用 Swift CLI 命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
# ─── 账户操作 ───

# 查看账户信息
openstack container list
swift list

# ─── 容器操作 ───

# 创建容器
openstack container create <CONTAINER_NAME>
swift post <CONTAINER_NAME>

# 列出容器内容
openstack container show <CONTAINER_NAME>
swift list <CONTAINER_NAME>

# 删除容器（需先清空对象）
openstack container delete <CONTAINER_NAME>

# ─── 对象操作 ───

# 上传对象
openstack object create <CONTAINER_NAME> <LOCAL_FILE>
swift upload <CONTAINER_NAME> <LOCAL_FILE>
#                      ├── --OBJECT-NAME 指定远程对象名
#                      ├── --SEGMENT-SIZE 大对象分段大小（字节）
#                      ├── --SEGMENT-CONTAINER 分段存储容器
#                      └── --CHANGE-DIR 保持目录结构

# 下载对象
openstack object save <CONTAINER_NAME> <OBJECT_NAME>
swift download <CONTAINER_NAME> <OBJECT_NAME>

# 列出对象
openstack object list <CONTAINER_NAME>
swift list <CONTAINER_NAME>

# 删除对象
openstack object delete <CONTAINER_NAME> <OBJECT_NAME>
swift delete <CONTAINER_NAME> <OBJECT_NAME>

# 查看对象详情
openstack object show <CONTAINER_NAME> <OBJECT_NAME>

# 获取临时 URL（限时访问）
swift tempurl GET 3600 /v1/AUTH_acc/container/object <SECRET_KEY>

# ─── 大对象分段上传 ───

# 动态大对象 (DLO): 自动分段
swift upload --SEGMENT-SIZE 1073741824 --SEGMENT-CONTAINER seg-container \
  <CONTAINER_NAME> <LARGE_FILE>
#                      └── --SEGMENT-SIZE 分段大小（本例 1GB）

# 静态大对象 (SLO): 手动分段 + manifest
swift upload --USE-SLO --SEGMENT-SIZE 1073741824 \
  --SEGMENT-CONTAINER seg-container <CONTAINER_NAME> <LARGE_FILE>

TempURL（临时 URL 访问）

1
2
3
4
5
6
7
8
9
10
11
12
13
# 1. 设置密钥
swift post -m temp-url-key:SECRET_KEY

# 2. 生成临时 URL
swift tempurl GET 3600 /v1/AUTH_acc/container/object SECRET_KEY
#                      ├── GET/PUT  HTTP 方法
#                      ├── 3600    有效期（秒）
#                      └── 返回完整 URL（含签名参数）

# 3. 直接通过 URL 访问（无需 Token）
curl -X GET "<TEMP_URL>"

# 用途: CDN 回源、文件分享、第三方下载

ACL（访问控制列表）

1
2
3
4
5
6
7
8
9
10
11
12
# 设置容器 ACL 允许特定用户读
swift post <CONTAINER> -r <USER_ID>
#                      ├── -r 读权限
#                      └── -w 写权限

# 允许所有用户读（公开容器）
swift post <CONTAINER> -r ".r:*,.rlistings"
#                      ├── .r:* 允许所有 Referer 读取对象
#                      └── .rlistings 允许列出容器内容

# 移除 ACL
swift post <CONTAINER> -r ""

十、生产部署最佳实践 ✅

实践 说明
最小 3 Zone 部署 每个 Zone 独立机架/电源/交换机，防止单机架故障导致数据丢失
XFS 文件系统 XFS 的 xattr 支持是 Swift 元数据存储的基石，挂载时用 noatime,nodiratime
权重平衡 按磁盘实际容量设置 WEIGHT，确保数据均匀分布
Part Power 选择 推荐 1015（总分区数 102432768），节点越多值越大
专用存储网络 使用独立 VLAN/网卡承载 Replicator 同步流量，不与公共网络争用
Memcached 集群 至少 2 节点 Memcached 缓存 Token 和查询结果，不缓存对象数据
Proxy 水平扩展 Proxy Server 无状态，前置负载均衡器（HAProxy）即可无限扩展
Replicator 并发控制 据节点数调整并发数，防止 rsync 风暴导致 IO 过载
定期审计巡检 监控 quarantined 目录的隔离文件量，早期发现磁盘故障
监控关键指标 对象计数、成功/失败请求比、异步队列深度、Replicator 队列长度

规模建议

规模 节点数 Zone 数 Part Power 副本
测试/开发 3 3 8 2
中小生产 6~20 3~4 10~12 3
大规模生产 20~100+ 4~8 12~15 3 或 EC
跨 Region 灾备 50+ 多 Region 14~15 3（跨 Region 分布）

十一、应用场景 🎯

场景 典型负载 Swift 优势
备份与归档 📋 数据库备份、日志存档、合规文件 普通硬件低成本、PB 级线性扩展、跨 Zone 冗余安全
图片/视频存储 🖼️ 静态资源托管、CDN 源站、监控录像 RESTful API 流式直读、CDN 回源（TempURL）、分段上传支持
虚拟机镜像 🖥️ Glance 后端镜像存储 无限容量、大对象支持、高并发读取
非结构化数据 📄 文档存储、邮件归档、日志分析 Flat Namespace 无层级限制、多租户 ACL 隔离
云存储服务 ☁️ 企业网盘、文件共享（Drogon/DavGate） S3 兼容网关、Token 认证、Quota 管理

与其他存储方案对比:

特性 Swift（对象） Ceph RBD（块） NFS（文件）
访问协议 HTTP REST iSCSI / librbd NFS v3/v4
挂载方式 HTTP API 块设备挂载 文件系统挂载
典型延迟 毫秒级（HTTP） 微秒级（本地） 微秒级
伸缩性 ✅ PB 级水平扩展 ✅ PB 级 ⚠️ 有限
随机读写 ❌ 不适合 ✅ 块级随机访问 ⚠️ 中等
适用场景 静态内容、备份 数据库、云硬盘 共享目录、代码
数据冗余 多副本/EC 多副本/EC 依赖底层存储

十二、版本演进趋势 🚀

版本 核心变化
2010 Rackspace 贡献给 OpenStack
Grizzly Swift 成为 OpenStack 正式核心组件
Havana 引入 Region 支持，跨数据中心复制
Icehouse 存储策略（Storage Policies）预览
Juno 存储策略正式发布，支持多 Ring
Kilo EC（纠删码）策略引入
Liberty EC 策略稳定，性能优化
Mitaka 全局集群扩展，跨 Region 复制增强
Newton 对象版本化支持
Pike SLO（静态大对象）优化
Queens 性能与稳定性持续提升
Stein EC 重建优化
Train 加密与安全增强
Wallaby 磁盘使用效率优化
Xena 弃用旧版特性
2024.2 Dalmatian 增强的 EC 策略与运维工具
2025.1 Epoxy Python 3.x 兼容性加固
2026.1 Gazpacho 性能持续优化，磁盘利用率提升

💡 技术解析

  • 术语: Consistent Hashing（一致性哈希） — 分布式系统中控制数据分布的核心算法。增删节点时仅需重新映射 1/N 的数据（N 为节点数），而非全量重新哈希。Swift 通过引入虚拟节点（Partition）进一步提高了平衡性和单调性。

  • 术语: Ring — Swift 最核心的数据结构，存储逻辑路径（Account/Container/Object 名）到物理设备（磁盘 IP+端口）的映射。各实体类型有独立 Ring，通过 _replica2part2dev_id 二维数组和 part_shift 实现 O(1) 查找性能。

  • 术语: Quorum（仲裁） — 分布式系统中通过多数派投票确保数据一致性的协议。Swift 的 N=3, W=2, R=1 配置下，读写副本集必然存在交集，保证至少有一个副本包含最新数据。条件 R+W > N 是 Quorum 的核心约束。

  • 术语: Partition（虚拟节点） — 一致性哈希中引入的虚拟节点概念，是哈希空间中的固定粒度分区。每个物理设备承载多个 Partition，通过增加 Partition 数量（默认物理节点数 × 100）使数据分布更均匀，节点变动时仅影响 1% 的数据项。

  • 术语: Handoff（故障转移节点） — 当主副本节点不可用时，Proxy Server 将数据写入临时 Handoff 节点的机制。Handoff 节点是 Ring 中的次优选择，待主节点恢复后由 Replicator 将数据同步回主节点。

  • 术语: Tombstone（墓碑） — Swift 的删除标记文件（.ts），0 字节。删除对象时不直接删除数据文件，而是创建时间戳更新的墓碑文件。Replicator 将墓碑传播到所有副本，Auditor 后续清理旧数据文件。这种设计确保删除操作在最终一致性模型下被可靠传播。

  • 术语: xattr（扩展属性） — Linux 文件系统的扩展属性机制（Extended Attributes），Swift 用它存储对象的元数据（名称、大小、ETag、Content-Type、自定义元数据等）。要求文件系统支持 xattr（XFS 原生支持，ext4 需 user_xattr 挂载选项）。

  • 术语: Zone（故障域） — Swift 中最小物理隔离单元，一般对应一个独立机架。同 Zone 内可有一台或多台服务器。Ring 构建时保证同一 Partition 的 Replica 分布在不同的 Zone 中，确保任意单个机架故障不影响数据完整性。

  • 术语: SLO/DLO（静态/动态大对象） — 支持超 5GB 对象的分段上传机制。DLO（动态大对象）使用 manifest 文件动态拼接分段，分段可独立管理。SLO（静态大对象）在 manifest 中固化分段列表（含 ETag），完整性校验更严格。

  • 命令: swift-ring-builder — Swift 的 Ring 构建与管理工具。create 指定分区幂次/副本数/最小移动间隔；add 添加存储设备并指定 Zone/权重；rebalance 根据当前设备列表自动计算分区分配方案并最小化数据移动量。生成的 .ring.gz 文件需要分发到所有集群节点。

  • 命令: swift upload — 上传对象到 Swift 容器，--OBJECT-NAME 自定义远程对象名，--SEGMENT-SIZE 设置分段大小（大对象自动分段），--CHANGE-DIR 上传时保持本地目录结构。自动基于文件内容计算 ETag（MD5）供完整性校验。

  • 命令: swift tempurl — 生成带签名的临时 URL，允许限时免认证访问。GET/PUT 指定 HTTP 方法，`` 指定有效期（秒）。用于 CDN 回源、文件分享、第三方下载等场景。安全性依赖密钥保密性。

🔗 相关文档

OpenStack Swift 对象存储服务概念 | OpenStack Keystone详解

发表于 更新于 分类于
深入解析OpenStack控制节点、计算节点、网络节点、存储节点的核心职责分工，以及多节点集群的消息协作与网络平面隔离机制

OpenStack架构详解：四大节点分工与多节点协同

OpenStack 是一个开源的云计算平台，采用分布式松耦合架构，由四大核心节点各司其职，通过消息总线与 API 协同工作。

一、四大节点核心分工

1. 控制节点（Controller Node）— 🧠 云大脑

集群的管理中枢，承载所有控制平面服务：

服务 组件 职责
身份认证 Keystone 统一认证、服务目录注册与 Token 管理
镜像管理 Glance 虚拟机镜像的存储、检索与转换
计算调度 Nova-API / Nova-Scheduler 接收 API 请求，通过过滤+权重算法选择最佳计算节点
网络控制 Neutron-Server 网络资源的 API 管理与控制平面
管理界面 Horizon Web 可视化仪表板
基础设施 MySQL / RabbitMQ / Memcached 数据库持久化、异步消息总线、分布式缓存

生产环境部署 3 个控制节点 组成 HA 集群，通过 Pacemaker + HAProxy 提供 VIP 与负载均衡。

2. 计算节点（Compute Node）— ❤️ 云心脏

虚拟机实例的实际运行场所：

  • Nova-Compute：与底层 Hypervisor（KVM/libvirt）交互，管理实例的创建、迁移与终止
  • Neutron-Agent：本地虚拟交换（Open vSwitch 网桥、iptables 规则）
  • 跨主机 VM 通信通过 VXLAN/GRE 隧道 实现东西向流量直达

3. 网络节点（Network Node）— 🌐 云神经系统

负责南北向流量（外部网络访问）与网络服务：

  • L3 Agent：虚拟路由、SNAT/DNAT、浮动 IP
  • DHCP Agent：为租户子网动态分配 IP 地址
  • Metadata Agent：实例元数据注入

演进趋势：OVN 集成 + DVR（分布式虚拟路由）正取代传统独立网络节点，将网络功能下沉到计算节点，消除单点瓶颈。

4. 存储节点（Storage Node）— 💾 云骨架

存储类型 组件 说明
块存储 Cinder 持久化虚拟硬盘，后端支持 LVM/Ceph/NFS/商业存储阵列
对象存储 Swift 非结构化数据（镜像、备份），三副本或 EC 纠删码
共享文件系统 Manila NFS/CIFS 共享，支持多实例同时挂载

二、多节点协同工作流

以 创建一台虚拟机 为例展示完整协作链路：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
用户请求 (Horizon CLI)
    │
    ▼
┌──────────────────────────────────┐
│ ① Keystone (控制节点)           │
│    身份验证 + 权限校验           │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ② Nova-API (控制节点)           │
│    接收请求，查询服务目录         │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ③ Nova-Scheduler (控制节点)     │
│    过滤+权重算法选择最优计算节点  │
│    → 消息发布至 RabbitMQ         │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ④ Glance (控制节点)             │
│    提供镜像元数据                 │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ⑤ Neutron-Server (控制节点)     │
│    分配网络端口与 IP              │
│    → 通知网络节点 L3/DHCP Agent  │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ⑥ Cinder (存储节点)             │
│    创建卷并映射给计算节点（可选） │
└──────────────────────────────────┘
    │
    ▼
┌──────────────────────────────────┐
│ ⑦ Nova-Compute (计算节点)       │
│    从 Glance 下载镜像             │
│    调用 KVM 创建虚拟机             │
│    OVS 接入租户网络               │
│    挂载 Cinder 卷                 │
└──────────────────────────────────┘

三大通信总线：

  • RabbitMQ 🐇 — 各组件间的异步消息通信（Nova ↔ Neutron ↔ Cinder 等）
  • MySQL（Galera Cluster） 🗄️ — 各组件状态数据的多主同步
  • RESTful API 🌍 — 组件间的同步调用，Keystone 提供统一服务目录

三、多网络平面隔离

1
openstack server create --flavor M1.SMALL --image CIRROS --network DEMO-NET --nic NET-ID=XXXXXXXX VM1

多节点协作依赖相互隔离的物理或逻辑网络：

网络平面 用途 连接的节点
Management 服务间 API 调用、DB 同步、消息队列 全部节点
Data/Tenant VM 间通信（VXLAN/GRE 隧道） 计算节点 + 网络节点
External/Public VM 访问公网、API 对外暴露 网络节点 + 控制节点
Storage 后端存储流量（Ceph 复制、镜像传输） 计算节点 + 存储节点

生产规范要求 Management 与 Data 网络物理分离，避免 VXLAN 隧道流量冲击控制平面的消息队列性能。

四、典型部署架构对比

架构模式 适用场景 说明
传统 4 节点分离 学习或测试环境 控制+计算+网络+存储独立部署，功能清晰但有单点
控制+网络合并 中小型生产（推荐） Neutron Server 与 Nova 同节点，减少机器数量
DVR 全分布式 大规模或高性能场景 网络功能下沉到计算节点，消除集中式网络瓶颈
容器化部署（Kolla） 2025-2026 新项目 所有服务容器化，升级回滚秒级，资源占用降 40%
DCN 分布式计算节点 边缘计算 Hub-and-Spoke 架构，中心控制 + 边缘计算与存储

五、技术解析

  • 术语: DVR — 分布式虚拟路由技术，每个计算节点独立处理南北向流量，避免传统 L3 Agent 单点瓶颈
  • 术语: OVN — Open Virtual Network，Neutron 的下一代后端，原生支持 L2/L3/NAT/ACL，消除 Neutron Agent 运维复杂度
  • 术语: Galera Cluster — MySQL 多主同步集群，所有节点可读写，自动处理节点故障，防脑裂
  • 术语: Kolla-Ansible — 基于 Docker 容器化部署 OpenStack 的工具，服务启动时间从 15 分钟缩短至 90 秒

六、最佳实践

  1. 控制节点至少部署 3 台形成 HA 集群，避免单点故障
  2. 生产环境优先使用 OVN + DVR 网络方案，提升网络吞吐与可靠性
  3. 存储节点启用 Ceph EC（纠删码）实现数据容错，兼顾空间利用率
  4. 使用 Kolla-Ansible 容器化部署，解决传统部署的依赖冲突问题
  5. 监控体系采用 Prometheus + Grafana 采集基础设施指标，Ceilometer 记录业务层资源用量

🔗 相关文档

OpenStack 概述 | OpenStack Keystone详解 | OpenStack Nova计算服务详解 | OpenStack Neutron网络服务详解

发表于 更新于 分类于
全面介绍 OpenStack 的起源、版本演进及核心价值，涵盖 NASA 与 Rackspace 的合作背景、版本历史与开源生态

OpenStack 概述

OpenStack 是一个开源的云计算管理平台项目，提供基础设施即服务（IaaS）解决方案，支持公有云、私有云和混合云的建设与管理。

一、起源

OpenStack 于 2010 年 7 月由 NASA 和 Rackspace 合作发起。

1. 背景

  • NASA 贡献了其 Nebula 平台的代码，发展成为 Nova（计算组件），负责虚拟服务器部署和业务计算模块
  • Rackspace 贡献了其 Cloud Files 平台的代码，发展成为 Swift（对象存储组件），负责分布式云存储模块

2. 发展里程碑

1
2
3
4
2010.07  NASA 与 Rackspace 联合宣布 OpenStack 项目
2010.10  发布首个版本 Austin（Nova + Swift）
2012.09  成立 OpenStack 基金会（非营利组织）
2020     宣布更名为 Open Infrastructure Foundation
  • 项目以 Apache 许可证 2.0 授权发布
  • 核心代码超过 1000 万行，由 8000+ 开发者贡献了 50 万+ 变更

二、版本演进

OpenStack 采用字母序单词作为版本代号，每半年发布一个新版本。2023 年起改为年份.序号命名格式。

早期版本（2010–2015）

版本 时间 核心新增
Austin 2010.10 首个版本，核心：Nova + Swift
Bexar 2011.02 Glance（镜像服务）、IPv6、Hyper-V
Essex 2012.04 Horizon（仪表板）、Keystone（身份服务）
Folsom 2012.09 Neutron（网络）、Cinder（块存储）
Grizzly 2013.04 230+ 新功能，Cells 分布式集群
Havana 2013.10 Ceilometer（计量）、Heat（编排）
Icehouse 2014.04 Trove（数据库服务）
Kilo 2015.04 Ironic（裸金属部署）

近期版本（2023–至今）

版本 时间 备注
2023.1 Antelope 2023.03 启用新命名规则
2024.1 Caracal 2024.04 33 个核心服务
2024.2 Dalmatian 2024.10 33 个核心服务
2025.1 Epoxy 2025.04 35 个核心服务

三、核心价值

1. 开源

  • 采用 Apache 2.0 许可证，代码完全免费开放
  • 社区拥有来自 100+ 国家的数万名开发者和 500+ 企业（Intel、IBM、华为、Red Hat、Cisco 等）

2. 可扩展

  • 采用水平扩展架构，无需专有硬件
  • 支持从小型单节点到大规模数据中心的各种规模
  • 支持 KVM、Xen、Hyper-V、Docker/LXC 等多种虚拟化技术

3. API 驱动

  • 各服务之间通过统一 RESTful API 调用，实现系统松耦合
  • 组件内部服务之间通过 AMQP（消息队列）交互
  • 用户可通过 Web 界面（Horizon）、命令行工具或 RESTful API 管理云资源
  • 插件架构：Neutron 支持多种网络后端，Cinder 支持多种存储后端

4. 核心组件一览

类别 组件 功能
计算 Nova 虚拟机实例生命周期管理
对象存储 Swift 大规模分布式对象存储
镜像服务 Glance 虚拟机镜像查找与检索
身份服务 Keystone 身份验证与服务令牌管理
网络服务 Neutron 网络虚拟化，支持 SDN
块存储 Cinder 持久化块存储设备管理
仪表板 Horizon Web 管理门户
编排服务 Heat 云基础设施自动化部署
裸金属 Ironic 物理裸机服务器管理

架构交互流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
用户 / Horizon / CLI / API 客户端
          ↕  RESTful API
     ┌──────────────────┐
     │   Keystone       │
     │  (身份认证)       │
     └──────────────────┘
          ↕  RESTful API
     ┌────┬────┬────┬────┐
     │Nova│Swift│Glance│Cinder│
     └─┬──┴─┬──┴─┬──┴─┬──┘
       │    │    │    │
     ┌─┴────┴────┴────┴─┐
     │  Neutron          │
     │  (网络服务)        │
     └───────────────────┘
          ↕  AMQP 消息队列
        服务内部通信

总结

OpenStack 始于 2010 年 NASA 与 Rackspace 的合作，历经 15 年发展为全球领先的开源 IaaS 平台，核心价值在于开源生态、水平可扩展、API 驱动的松耦合架构。

🔗 相关文档

OpenStack架构详解：四大节点分工与多节点协同 | OpenStack Nova计算服务概念 | OpenStack Swift 对象存储服务概念 | OpenStack Cinder 块存储服务概念 | OpenStack Neutron网络概念 | OpenStack Keystone认证服务概念 | OpenStack Glance 镜像服务概念 | 私有云 OpenStack 学习路径 | JSON 文档格式概述

发表于 更新于 分类于 ，
全面介绍OpenStack Swift对象存储的核心概念、三层数据模型、一致性哈希Ring机制、数据冗余策略及典型应用场景

OpenStack Swift 对象存储服务概念

Swift 是 OpenStack 平台中的对象存储服务组件，提供高可用、分布式、最终一致性的非结构化数据存储能力，适合存储图片、视频、备份归档等海量数据🗄️。

一、三层数据模型

Swift 采用 Account → Container → Object 三层分层存储结构：

1
Account（账户/项目） → Container（容器） → Object（对象）
层级 类比文件系统 说明
Account 根分区/用户 顶层命名空间，对应 OpenStack 的 Project（租户/项目）
Container 文件夹/目录 对象的逻辑分组单元，支持 ACL 和存储策略配置
Object 文件 实际存储的数据实体（内容 + 自定义元数据） 
1
2
# RESTful API 访问路径格式
GET /V1/{ACCOUNT}/{CONTAINER}/{OBJECT}

⚠️ Swift 不是 POSIX 文件系统，不支持目录嵌套和原地重命名。路径中的 / 只是对象名称中的字符，用于伪目录模拟。

二、核心命令操作

1. 账户操作

1
2
3
4
5
# 查询账户信息
swift stat

# 列出账户下所有容器
swift list

2. 容器操作

1
2
3
4
5
6
7
8
9
10
11
# 创建容器
swift post CONTAINER_NAME

# 列出容器内容
swift list CONTAINER_NAME

# 设置容器读权限（公开访问）
swift post CONTAINER_NAME --read-acl ".R:*"

# 删除容器（需先清空内部对象）
swift delete CONTAINER_NAME
  • --read-acl：设置读取权限，.r:* 表示允许所有用户读取
  • --write-acl：设置写入权限

3. 对象操作

1
2
3
4
5
6
7
8
9
10
11
# 上传对象
swift upload CONTAINER_NAME LOCAL_FILE_PATH

# 下载对象
swift download CONTAINER_NAME OBJECT_NAME

# 下载到指定文件
swift download CONTAINER_NAME OBJECT_NAME --output LOCAL_PATH

# 删除对象
swift delete CONTAINER_NAME OBJECT_NAME

4. 分段上传（大文件）

1
2
3
4
5
# Swift 自动分段（大于 5GB 必须使用）
swift upload CONTAINER_NAME LARGE_FILE --segment-size 1073741824

# 手动指定分段大小（单位：字节）
swift upload CONTAINER_NAME LARGE_FILE --segment-size 536870912
  • --segment-size：分段大小，单位为字节（如 536870912 = 512MB）
  • Swift 自动创建 <container>_segments 容器存放分段数据

5. 对象版本控制

1
2
3
4
5
6
7
8
# 开启版本控制（设置历史版本存储容器）
swift post CONTAINER_NAME --history-location HISTORY_CONTAINER

# 上传新版本后，旧版本自动移至 HISTORY_CONTAINER
swift upload CONTAINER_NAME FILE

# 列出版本历史
swift list HISTORY_CONTAINER
  • --history-location：指定存储旧版本的容器
  • 每次上传同名对象，旧版本自动归档到历史容器

6. 临时 URL 访问

1
2
3
4
5
# 设置账户临时 URL 密钥
swift post --temp-url-key MY_SECRET_KEY

# 生成临时访问 URL（有效期 3600 秒）
swift tempurl GET 3600 /V1/AUTH_PROJECT_ID/CONTAINER/OBJECT MY_SECRET_KEY
  • 适用于生成带时效的共享链接，无需暴露账户凭证
  • 支持 GET / PUT / DELETE 操作

三、Ring 与一致性哈希

Swift 不依赖中心元数据服务器，通过 Ring（环） 数据结构实现数据路由🗺️：

1
Object名称 → MD5哈希 → Partition索引 → Ring映射 → 物理设备
组件 说明
Ring 将逻辑名称映射到物理设备的数据结构，三个 Ring 分别对应 Account/Container/Object
Partition（分区） 哈希空间被划分为固定数量的虚拟分区，如 2¹⁰ = 1024 个
Zone（区域） 故障隔离域，确保副本分布在不同的物理机架/服务器上
Weight（权重） 设备权重值，控制数据在节点间的分布比例

一致性哈希优势：

  • 新增/移除节点时仅需迁移约 1/N 的数据（N=设备总数）
  • 去中心化设计，无单点瓶颈
  • Proxy 节点通过 Ring 直接定位数据，无需查表

四、数据冗余与复制

副本与 Quorum 协议

参数 默认值 说明
N（副本数） 3 每个对象默认保存 3 个副本
W（写确认） 2 写入成功 2 份即向客户端返回确认
R（读确认） 1 读取至少从 1 个副本返回

Quorum 规则：W + R > N，确保读操作总能读到最新写入的副本。

副本分布策略

副本跨 Zone / Region 分布，确保物理隔离：

1
2
3
Region 1 ─── Zone A ─── Device 1 （副本 1）
          └── Zone B ─── Device 2 （副本 2）
Region 2 ─── Zone C ─── Device 3 （副本 3）

后台一致性守护进程🛡️

守护进程 功能 执行频率
Replicator 基于 rsync 的推模式复制，自动修复过期副本 默认每 30s
Updater 异步重试失败的更新操作（如未更新的容器列表） 持续排队重试
Auditor 扫描磁盘检测静默数据损坏（bit rot），隔离坏数据 周期性扫描
Account Reaper 清理已删除账户的残留数据 后台持续运行

五、架构组件

组件 功能说明
Proxy Server RESTful API 入口，根据 Ring 路由请求到正确的存储节点🚪
Account Server 管理 Account 元数据，存储 Container 列表
Container Server 管理 Container 元数据，存储 Object 列表
Object Server 处理实际对象的存储、检索和删除操作💾
Ring 数据映射表，维护 Partition → Device 的映射关系
一致性哈希 数据分布算法，最小化节点变更时的数据迁移
Replicator 后台同步服务，确保数据副本的一致性

请求处理流程

1
2
客户端请求 ➔ Proxy Server（鉴权 + 路由） ➔ Ring 查找设备
    ➔ 目标存储节点（Object/Container/Account Server） ➔ 返回结果

六、一致性模型与 CAP

Swift 遵循 AP（可用性 + 分区容忍性） 优先策略：

  • 最终一致性：写操作在返回确认后，数据会异步传播到所有副本
  • 强一致性读：可通过请求头 x-newest: true 强制读取最新副本
  • 在 CAP 理论中，Swift 优先保障可用性和分区容忍性，牺牲强一致性

七、性能与限制

指标 默认值 说明
单对象最大大小 5 GB 超过需使用分段上传
分段上传大小 无限制 通过 SLO/DLO 支持 PB 级文件
Container 数量 无硬限制 受存储容量和性能约束
Object 数量 无硬限制 可存储百亿级对象
网络协议 HTTP/HTTPS 基于 RESTful API

八、典型应用场景📂

场景 说明
备份与归档 持久化存储数据库备份、日志文件、合规归档数据
图片/视频存储 结合 CDN 分发静态资源，支持大文件分段上传
非结构化数据 文档、邮件、IoT 传感器数据等无固定模式的数据
Glance 镜像后端 作为 Glance 镜像服务的后端存储
Cinder 备份目标 Cinder 卷的备份存储后端

生产最佳实践⚠️

  • 生产环境建议 3 副本跨 3 个以上 Zone 部署，确保故障隔离
  • 大文件（> 5GB）务必使用 分段上传，避免单点失败
  • 定期监控 Auditor 日志，及时发现和处理静默数据损坏
  • 使用 临时 URL 功能分发文件，避免暴露账户凭证
  • 通过 ACL 控制 Container 访问权限，不支持单 Object ACL
  • 合理设置 Partition 数量，过多增加复制开销，过少影响平衡性
  • 关注 Replicator 执行周期，确保复制速度满足数据写入速率

🔗 相关文档

OpenStack Swift对象存储详解 | OpenStack Keystone认证服务概念
0%