OpenStack Neutron网络概念

一、网络模型

1、Provider Network（提供商网络）🌐

• 定义: 直接映射到物理网络的虚拟网络，由管理员创建
• 隔离方式: Flat（无标签）/ VLAN（802.1Q标签）
• 特点: 依赖物理网络基础设施提供L3路由，无需虚拟路由器
• 性能: 高，无封装开销，实例直接可达
• 适用场景: 简单部署，物理网络直连，企业迁移环境

2、Self-Service Network（自助服务网络）🏗️

• 定义: 完全虚拟化的Overlay网络，非特权用户可自行创建
• 隔离方式: VXLAN（默认）/ GRE / GENEVE隧道封装
• 特点: 多租户隔离，需虚拟路由器连接外部网络
• NAT机制: SNAT（出站） + Floating IP / DNAT（入站）
• 扩展性: VXLAN支持1600万+网络段，远超VLAN的4096限制

3、路由器（Router）🔀

• 实现: 基于Linux网络命名空间（Network Namespace）的虚拟L3设备
• 管理: 由 L3 Agent（neutron-l3-agent）在网络节点上运行
• 功能:
  • 路由Self-Service网络间的流量
  • 连接Self-Service网络与外部/Provider网络
  • 执行SNAT和DNAT转换
• 高可用: 支持DVR（分布式虚拟路由）和L3 HA（VRRP主备）

4、安全组（Security Group）🛡️

• 定义: 实例端口级别的有状态虚拟防火墙
• 默认策略: 入站皆拒，出站皆允
• 实现: 基于iptables规则（或OVS流规则）在计算节点执行
• 特性:
  • 支持协议/端口/IP/安全组级别规则
  • 自动添加反欺骗规则（防MAC/IP伪造/Rogue DHCP）
  • 每个项目有默认安全组，未指定则自动应用

二、ML2（Modular Layer 2）核心插件架构

架构概览

ML2 是 Neutron 的控制面核心，将网络类型与实现机制彻底解耦：

1
2
3
4
5
6
7

ML2 Plugin
├── Type Manager（类型管理）
│   ├── Flat / Local / VLAN
│   └── VXLAN / GRE / GENEVE
└── Mechanism Manager（机制管理）
    ├── 基于代理: Linux Bridge / Open vSwitch / L2POP
    └── 基于控制器: OpenDaylight / OVN / VMware NSX

类型驱动（Type Driver）

机制驱动（Mechanism Driver）

• Linux Bridge: 基于内核原生桥接，简单稳定
• Open vSwitch: 基于OpenFlow流规则，功能丰富
• L2 Population: 优化广播流量，提升VXLAN/GRE性能
• SDN控制器: OVN / OpenDaylight / NSX 等集中控制方案

工作流程

1
2
3
4
5
6
7
8
9

用户 API 请求
    ↓
Neutron Server → ML2 Plugin
    ├── Type Driver 校验 + 存储数据库
    └── Mechanism Driver RPC 通知各节点 Agent
        ├── L2 Agent（虚拟交换机配置）
        ├── L3 Agent（路由/NAT）
        ├── DHCP Agent（dnsmasq分配IP）
        └── Metadata Agent（元数据代理）

三、Linux Bridge 代理

数据流向

1
2
3
4
5
6
7
8
9

VM
  ↓
Tap 接口（tapXXX）           ← 虚拟机虚拟网卡
  ↓
Linux 网桥（brqXXXX）        ← 充当二层交换机
  ↓
VLAN 接口（ethX.Y）或 VXLAN 接口（vxlan-Z）  ← 网络隔离/隧道
  ↓
物理网卡（ethX）

支持范围

• ✅ Local / Flat / VLAN / VXLAN
• ❌ GRE

特点

• 架构直观，基于内核原生桥接，适合学习理解
• 技术成熟稳定，性能高效
• 不依赖额外用户态进程，资源占用低

四、Open vSwitch（OVS）代理

数据流向

1
2
3
4
5
6
7
8
9
10
11
12
13
14

VM
  ↓
Tap 接口（tapXXX）           ← 虚拟网卡
  ↓
qbr（Linux网桥）              ← 安全组iptables过滤
  ↓
veth对（qvbXXX ↔ qvoXXX）    ← 连接Linux网桥与OVS
  ↓
br-int（集成网桥）            ← 核心虚拟交换机
  ↓
br-ethX（物理连接网桥）       ← Flat/VLAN网络
  或 br-tun（隧道网桥）       ← VXLAN/GRE/GENEVE网络
  ↓
物理网卡（ethX）

核心机制

• 所有虚拟机连接至同一 br-int 集成网桥
• 通过 OpenFlow 流规则 进行VLAN转换和隧道封装
• 无需VLAN子接口，流规则可动态下发

支持范围

• ✅ Local / Flat / VLAN / VXLAN / GRE / GENEVE（全支持）

五、Linux Bridge vs OVS 对比

六、Neutron SDN 思想解析

Neutron 的 SDN 思想核心：控制面与数据面分离。

传统网络 vs Neutron SDN 映射

关键技术注解

• 网络命名空间 💡: Linux内核特性，隔离网络栈（接口、路由表、iptables），Neutron用它实现路由器隔离
• VXLAN隧道 💡: MAC-in-UDP封装，将二层帧通过三层网络传输，解决VLAN数量限制和跨物理机通信问题
• OpenFlow流表 💡: OVS的核心，定义数据包匹配规则和动作（转发/丢弃/修改），实现可编程网络
• RPC消息队列 💡: Neutron Server与各Agent间的通信纽带，Agent通过监听队列获取配置指令

Nova计算服务概念

Nova 是 OpenStack 中的核心计算服务（Compute Service）☁️，负责管理虚拟机（VM）实例的完整生命周期——创建、启动、停止、删除、迁移、快照等。它采用分布式、无状态、消息驱动的架构设计，各组件通过消息队列（RabbitMQ）异步通信，通过共享数据库协调状态。状态保存在数据库中，不在服务进程中。

一、四大核心组件架构

nova-api — 前端入口 🚪

角色：REST API 端点 / 请求编排器

• 接收所有用户/运维操作请求（如 POST /servers 创建VM）
• 通过 Keystone 进行身份认证 🔐
• 校验请求参数并执行策略（Policy）
• 将实例初始状态写入数据库（vm_state=BUILDING）
• 将任务派发至消息队列，由其他服务处理
• 无状态，可水平扩展

nova-scheduler — 调度决策引擎 🧠

角色：确定哪台物理计算节点运行新创建的虚拟机

采用两阶段算法：

阶段1：Filtering（过滤）——运行可配置过滤链，剔除不合格主机

阶段2：Weighting（权重打分）——对候选主机打分，最高分胜出（默认按剩余内存最多优先）

自 Newton 版本起，资源清单追踪由独立的 Placement API 服务负责。调度器向 Placement 查询分配候选节点，再应用自身的过滤器和权重。

nova-conductor — 安全代理与编排器 🛡️

角色：数据库访问代理 + 复杂工作流协调器

引入目的：解决安全隔离问题——计算节点永远不能直接访问中央数据库，防止计算节点被攻破时数据泄露。

同样无状态，可水平扩展。⚠️ 禁止部署在 nova-compute 所在节点。

nova-compute — 实际执行者 ⚙️

角色：真正的 Hypervisor 管理器——唯一直接操作虚拟机的组件

• 运行在每个计算节点（物理服务器）上
• 监听消息队列获取工作指令
• 调用 Hypervisor 驱动（如 libvirt.LibvirtDriver for KVM/QEMU）
• 管理实例全生命周期：创建、销毁、暂停、挂起、Resize、迁移、快照
• 定期向 Placement API 报告资源使用情况
• 不能直接访问数据库——所有 DB 操作经 nova-conductor

二、完整工作流：创建一台虚拟机 🔄

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

用户 → nova-api          发送 POST /servers（含 flavor、image、network）
nova-api → Keystone      认证 Token
nova-api → 数据库        创建实例记录（vm_state=BUILDING）
nova-api → 消息队列      发送 boot RPC 消息
nova-scheduler ← 队列    拾取 boot 任务
nova-scheduler → Placement  查询 /allocation_candidates（找合适主机）
Placement → nova-scheduler   返回候选主机列表及资源信息
nova-scheduler → 数据库  过滤 + 权重打分，选出最佳主机
nova-scheduler → 消息队列 发送 build_and_run_instance 到目标主机
nova-compute ← 队列      拾取构建任务
nova-compute → conductor RPC 请求完整实例详情
conductor → 数据库        读取实例数据
conductor → nova-compute 返回实例对象
nova-compute → Placement  提交 /allocations（锁定资源）
nova-compute → Libvirt    调用 spawn()——创建磁盘、启动虚拟机
nova-compute → 数据库     更新 vm_state=ACTIVE（经 conductor）

关键特性：这是异步、最终一致性架构。API 立即返回 202 Accepted，实际 VM 创建在后台进行。

三、虚拟化技术支持 💻

关键虚拟化机制

• KVM/QEMU 模式: nova-compute 通过 libvirt 库调用 KVM/QEMU，libvirt 提供统一 API 屏蔽底层差异
• Emulator Threads 策略（Pike+ 版本）: hw:cpu_emulator_threads 规格标签可设置：
  • share（默认） — 模拟器线程与 vCPU 共享物理 CPU
  • isolate — 模拟器线程固定在专用物理 CPU（适合实时性要求高的场景）
• Xen 特殊处理: 重启 Xen 虚拟机时会先后发射 STOPPED 和 STARTED 事件，Nova 延迟处理 STOPPED 事件避免误停 VM

四、调度策略详解 🎯

过滤阶段核心过滤器

权重打分

过滤后的候选主机进入权重阶段，默认策略：

• ram_weight_multiplier（默认 1.0）— 剩余内存越多权重越高
• 可自定义：cpu_weight_multiplier、disk_weight_multiplier

五、Cells v2 架构（生产部署） 🏗️

对于大规模部署（数百上千计算节点），Nova 使用 Cells v2 横向分区：

• Cell0 — 特殊 Cell，存放调度失败实例记录，避免污染主数据库
• 每个 Cell 拥有独立的消息队列和数据库，避免单点瓶颈
• 实现真正水平扩展能力

六、组件特性对比

七、使用场景

• 虚拟机全生命周期管理 🖥️：从创建、运行、迁移到销毁
• 多 Hypervisor 统一管理 🔧：同一 Nova 集群可混用 KVM、VMware、Xen 等
• 弹性伸缩 📈：水平扩展计算节点，结合调度策略优化资源利用率
• 高可用部署 🛡️：Cells v2 + Anti-Affinity 策略实现跨物理机/跨可用域部署

一句话概括

nova-api 是入口，nova-scheduler 决定在哪运行，nova-conductor 安全代理数据库，nova-compute 是真正干活的。四者通过消息队列 + Placement API 协作，支撑起 OpenStack 的计算服务能力。

OpenStack Ceilometer（监控计量）详解

一、Ceilometer 概述 📊

Ceilometer 是 OpenStack Telemetry（遥测）服务的核心组件，采用 Agent 架构，所有服务均可水平扩展。核心职责是采集云平台中所有资源的计量数据，为监控、告警、计费、性能分析提供数据基础。

Telemetry 生态组件：

二、数据采集两大机制 🔄

1. Notification Agent（通知代理）— 推荐方式 ✅

原理：OpenStack 各组件在执行操作时向消息队列发送通知，Notification Agent 监听并转换为 Samples/Events。

工作流程：

1. 各服务发通知到消息队列（topic: notifications.info、notifications.sample 等）
2. Notification Agent 加载 ceilometer.notification 命名空间的 Listener 插件
3. 根据 event_type 过滤，分发给对应 Endpoint 处理
4. 通过 Pipeline 进行转换（Transform）和发布（Publish）

Meter 配置示例（meters.yaml） 📋

1
2
3
4
5
6
7

metric:
  - name: "disk.read.bytes"
    event_type: "compute.instance.create.end"
    type: "cumulative"
    unit: "B"
    volume: "$.payload.size"
    resource_id: "$.payload.instance_id"

2. Polling Agent（轮询代理）— 补充方式 ⏱️

原理：对于通知无法覆盖的指标（如 VM CPU/内存使用率等资源使用数据），Polling Agent 定期主动轮询 获取。

三种 Polling Agent：

注意：Kilo 版本起统一为 ceilometer-polling，通过 --polling-namespaces 参数区分。

Polling 配置示例（polling.yaml） 📋

1
2
3
4
5
6
7
8
9
10
11

sources:
  - name: "compute_source"
    interval: 300 # 轮询间隔（秒）
    meters:
      - "cpu_util"
      - "memory.resident"
      - "disk.read.bytes"
    resources:
      - "list of resource urls"
    discovery:
      - "local_instances"

三、Pipeline 数据处理管道 📦

无论是 Notification 还是 Polling 采集的数据，都经过 Pipeline 统一处理：

1

采集（Agent）→ 转换（Transform）→ 发布（Publish）→ 目标存储

1. 数据转换（Transform）

支持的转换器：

2. 数据发布（Publish）— 支持多发布者

3. Pipeline 配置示例（pipeline.yaml） 🔧

1
2
3
4
5
6
7
8
9
10
11
12
13
14

sources:
  - name: "cpu_source"
    interval: 300
    meters:
      - "cpu_util"
    sinks:
      - "cpu_sink"
sinks:
  - name: "cpu_sink"
    transformers:
      - name: "rate_of_change"
    publishers:
      - "gnocchi://"
      - "notifier://"

四、Gnocchi 时序数据存储 🗄️

Gnocchi 替代了 Ceilometer 早期数据库存储后端，提供高性能时序数据存储和查询。

归档策略示例

1
2
3
4
5
6

gnocchi archive-policy create \
  --back-window 0 \
  --granularity 60:1h \
  --granularity 3600:30d \
  --granularity 86400:365d \
  name: 'low-resolution'

归档策略解释：

常用查询命令

1
2
3
4

gnocchi measures show -r RESOURCE_ID -m METRIC_NAME
gnocchi measures show --aggregation mean -r RESOURCE_ID -m cpu_util
gnocchi resource list --type instance
gnocchi status

五、Aodh 告警系统集成 🚨

Aodh 基于 Ceilometer 采集、Gnocchi 存储的数据，提供灵活的阈值告警服务。

告警类型

支持的动作

告警创建示例

1
2
3
4
5
6
7
8
9
10
11
12
13

aodh alarm create \
  --type gnocchi_aggregation_by_resources_threshold \
  --name cpu_high \
  --metric cpu_util \
  --threshold 80 \
  --comparison-operator ge \
  --evaluation-periods 3 \
  --period 300 \
  --aggregation-method avg \
  --resource-type instance \
  --query '{"=": {"id": "INSTANCE_UUID"}}' \
  --alarm-action 'webhook://https://hooks.example.com/alarm' \
  --ok-action 'webhook://https://hooks.example.com/ok'

参数说明：

六、CloudKitty 计费系统集成 💰

计量计费三步骤

CloudKitty 架构

1

Ceilometer/Gnocchi → Tenant Fetcher → Collector → Rating Engine → Storage → Dashboard/API

Rating Engine 计费模块

Dynamic Pollster 高级采集

对于自定义计费场景，Ceilometer 提供 Dynamic Pollster，可在运行时动态定义新采集指标，无需重启代理：

1
2
3
4
5
6

# polling.yaml — dynamic pollster 示例：采集卷的 IOPS
sources:
  - name: "volume_iops"
    interval: 60
    meters:
      - "volume.iops"

配合 CloudKitty 的 hashmap 规则，可实现基于标签（tag）的差异计费（如按项目、按客户级别、按操作系统类型差异化定价）。

七、整体数据流总览 🌐

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

┌──────────────────────────────────────────────────────────────────┐
│                     OpenStack 各组件                               │
│  Nova / Glance / Cinder / Neutron / Swift / Keystone / Heat      │
└───────┬────────────────────────────────────────┬─────────────────┘
        │ 发送通知                                 │ 提供 REST API
        ▼                                         ▼
┌────────────────────┐                  ┌──────────────────────────┐
│ Notification Agent  │                  │ Polling Agent             │
│ （监听消息队列）      │                  │ （compute/central/ipmi）  │
│ ↓ 转换为 samples     │                  │ ↓ 轮询生成 samples        │
└─────────┬──────────┘                  └──────────┬───────────────┘
          │                                        │
          └──────────┬──────────────────────────────┘
                     ▼
          ┌──────────────────────┐
          │   Pipeline 处理       │
          │ （Transform + Publish）│
          └──────────┬───────────┘
                     ▼
     ┌───────────────┬───────────────┬───────────────┐
     ▼               ▼               ▼               ▼
  Gnocchi         Aodh           CloudKitty       外部系统
  （时序存储）     （阈值告警）     （计费引擎）      （Kafka/HTTP）
     │               │               │
     ▼               ▼               ▼
  监控面板         告警通知         账单/报表
  （Grafana）    （邮件/Webhook）   （客户计费）

八、性能调优 🚀

Pipeline 批处理配置优化：

1
2
3
4
5
6

[notification]
batch_size = 500
batch_timeout = 5

[collector]
workers = 4

九、常用 CLI 命令 🖥️

Ceilometer 命令

1
2
3

ceilometer meter-list
ceilometer sample-list -m cpu_util
ceilometer statistics -m cpu_util -p 3600

Gnocchi 命令

1
2
3
4

gnocchi metric list
gnocchi measures show -r RESOURCE_ID -m cpu_util
gnocchi archive-policy list
gnocchi resource list --type instance

Aodh 命令

1
2
3
4

aodh alarm list
aodh alarm show ALARM_ID
aodh alarm update --name ALARM_ID --threshold 90
aodh alarm delete ALARM_ID

CloudKitty 命令

1
2
3
4
5
6

openstack rating module list
openstack rating hashmap service create --name compute
openstack rating hashmap field create --service compute \
  --key flavor --type flat
openstack rating hashmap mapping create \
  --field-id FIELD_ID --value m1.small --cost 0.5

十、最佳实践 💡

1. 优先使用 Notification 采集，减少对 OpenStack API 的额外负载
2. 合理配置 Polling 间隔，重要指标（CPU）用短间隔，次要指标（磁盘容量）用长间隔
3. 使用 Gnocchi 归档策略控制存储成本，细粒度数据短期保留，粗粒度数据长期保留
4. 开启 Pipeline 批处理，增大 batch_size 提升吞吐量
5. 引入 Kafka 缓冲层，解耦采集与存储，应对大规模集群流量峰值
6. 水平扩展 Agent，Compute Agent 随计算节点自动扩展，Central Agent 根据 API 负载调整
7. 告警策略设置连续评估周期（evaluation-periods），避免误告警
8. CloudKitty 计费规则需手动创建 hashmap 或 pyscript 规则，否则不产生计费结果
9. 利用 Dynamic Pollster 动态定义自定义采集指标，无需重启代理服务
10. 监控 Ceilometer 自身性能，关注消息队列积压和 Pipeline 处理延迟

OpenStack Cinder块存储详解

一、Cinder核心架构概览

Cinder是OpenStack的块存储核心组件，为虚拟机提供持久化、高性能的块级存储设备。通过与Nova协作，Cinder实现了计算与存储的解耦——虚拟机实例的磁盘数据独立于计算节点存在，即使虚拟机被删除，卷中的数据依然保留。🔲

架构全景图

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

                  ┌──────────┐
                  │ Keystone │
                  └────┬─────┘
                       │ AUTH
                  ┌────▼─────┐
USER ──REST API──► CINDER-API│
                  └────┬─────┘
                       │
                 ┌─────▼──────┐
                 │   Message  │
                 │    Queue   │ ◄── RabbitMQ（异步解耦）
                 └─────┬──────┘
                       │
            ┌──────────┼──────────┐
            ▼          ▼          ▼
      CINDER-     CINDER-     CINDER-
     SCHEDULER   VOLUME      BACKUP
            │          │          │
            ▼          ▼          ▼
       ┌────────┐ ┌────────┐ ┌────────┐
       │   DB   │ │ 存储   │ │ 备份   │
       │  MySQL │ │ 后端   │ │ 后端   │
       └────────┘ └────────┘ └────────┘
                       │
      ┌────────────────┼────────────────┐
      ▼                ▼                ▼
   LVM/iSCSI       Ceph RBD          NFS/FC
  (本地存储)      (分布式存储)      (网络存储)

核心组件一览表

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

1
2
3
4
5
6
7
8
9
10
11

块存储 = 控制平面 (Control Plane) + 数据平面 (Data Plane)

控制平面  → cinder-api + cinder-scheduler + 消息队列
             ├── 请求路由与调度
             ├── 权限验证与配额管理
             └── 元数据持久化 (MySQL)

数据平面  → cinder-volume + 存储后端驱动
             ├── 实际执行 I/O 操作
             ├── 通过驱动层屏蔽后端差异
             └── 数据路径不经过控制平面

关键设计理念: cinder-api 和 cinder-scheduler 仅负责请求调度，实际的 I/O 由 cinder-volume 通过后端驱动完成。当卷挂载到虚拟机后，数据传输直接在 Nova 计算节点与存储后端之间完成，不经过 cinder-volume 中转。🚀

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

1️⃣ cinder-api — 请求入口

cinder-api 是用户与 Cinder 交互的唯一入口，对外提供 RESTful API。

1
2
3
4
5
6

cinder-api 工作流程:
1. 接收 HTTP 请求 (POST/GET/PUT/DELETE)
2. Keystone 身份验证（校验 TOKEN）
3. 请求参数校验与反序列化
4. 将 API 调用转换为消息发布到消息队列
5. 异步等待执行结果并返回响应

核心 API 端点:

2️⃣ cinder-scheduler — 调度引擎

调度器负责为每个卷创建请求选择最优的存储节点，采用 Filter + Weight 两阶段机制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

创建卷请求 → cinder-scheduler
                │
        ┌───────▼────────┐
        │  Phase 1: Filter  │
        │  过滤掉不满足条件   │
        │  的存储节点       │
        └───────┬────────┘
                │
        ┌───────▼────────┐
        │  Phase 2: Weight  │
        │  对剩余节点进行    │
        │  权重计算排序     │
        └───────┬────────┘
                │
        ┌───────▼────────┐
        │   选择最优节点     │
        │    → cinder-volume │
        └────────────────┘

内置 Filter 列表:

Weighter（权重计算器）:

3️⃣ cinder-volume — 卷管理核心

cinder-volume 是真正与存储硬件交互的服务，运行在存储节点上。它通过插件化驱动架构支持多种存储后端。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

cinder-volume 内部架构:

┌────────────────────────────────────────┐
│           cinder-volume 服务             │
├────────────────────────────────────────┤
│     Manager（协调层）                    │
│  ├── RPC 消息处理                        │
│  ├── 任务队列管理                        │
│  └── 状态上报                           │
├────────────────────────────────────────┤
│     驱动抽象层（Volume Driver API）       │
│  ├── create_volume()                    │
│  ├── delete_volume()                    │
│  ├── attach_volume() / detach_volume()  │
│  ├── create_snapshot()                  │
│  ├── create_volume_from_snapshot()      │
│  └── extend_volume()                    │
├────────────────────────────────────────┤
│     具体驱动实现                         │
│  ┌──────┬──────┬──────┬──────┬──────┐  │
│  │ LVM  │ Ceph │ NFS  │ FC   │其他  │  │
│  │ iSCSI│ RBD  │      │ SAN  │厂商  │  │
│  └──────┴──────┴──────┴──────┴──────┘  │
└────────────────────────────────────────┘

4️⃣ cinder-backup — 备份服务

提供卷的跨区域备份与恢复能力，支持多种备份后端：

三、Cinder 卷生命周期管理 📋

创建卷的完整流程

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

1. 用户执行:
   openstack volume create --SIZE 100 --TYPE ssd my-volume

2. cinder-api:
   ├── 校验用户 TOKEN（调用 Keystone）
   ├── 校验请求参数（SIZE、TYPE 等）
   ├── 创建数据库中初始记录（STATUS=CREATING）
   └── 发送 "volume.create" 消息到消息队列

3. cinder-scheduler:
   ├── 消费消息队列中的创建请求
   ├── Filter 阶段:
   │   ├── CapacityFilter → 检查可用容量
   │   ├── CapabilitiesFilter → 匹配 volume type
   │   └── AvailabilityZoneFilter → 可用域匹配
   ├── Weight 阶段:
   │   └── CapacityWeigher → 按剩余容量排序
   └── 发送 "volume.create_on_backend" 到选定节点

4. cinder-volume (选定节点):
   ├── 接收消息
   ├── 调用对应驱动的 create_volume() 方法
   ├── LVM: lvcreate / Ceph: rbd create
   ├── 更新数据库状态为 available
   └── 返回成功响应

挂载卷到虚拟机（Nova 协调）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

卷挂载流程（Cinder ↔ Nova 协作）:

1. 用户请求挂载:
   openstack server add volume <SERVER> <VOLUME>

2. Nova 调用 Cinder 的 os-attach API:
   ├── Cinder 将卷状态置为 attaching
   └── Cinder 返回连接信息（connector）

3. Nova 根据 connector 信息连接存储后端:
   ├── iSCSI: 发现 iSCSI target → 登录 → 挂载本地设备
   ├── Ceph: 通过 RBD map 或 librbd 直接访问
   └── NFS: mount NFS 共享目录

4. Nova 将设备附加到虚拟机:
   ├── libvirt 定义 disk 设备
   └── 卷以 /dev/vdb, /dev/vdc 等出现在 VM 内

5. Cinder 更新状态为 in-use

卷状态机

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

                ┌──────────┐
                │ creating │ ── 正在创建
                └────┬─────┘
                     │
                ┌────▼─────┐
     ┌──────────► available│ ── 可用，等待挂载
     │          └────┬─────┘
     │               │
┌────┴─────┐  ┌──────▼──────┐
│ attaching│  │   in-use    │ ── 已挂载到虚拟机
└────┬─────┘  └──────┬──────┘
     │               │
┌────▼─────┐  ┌──────▼──────┐
│detaching │  │  deleting   │ ── 正在删除
└────┬─────┘  └──────┬──────┘
     │               │
     │          ┌────▼─────┐
     │          │  deleted │ ── 已删除
     │          └──────────┘
     │
┌────┴───────────┐
│ error /        │
│ error_deleting │
└────────────────┘

其他中间状态:

常用管理命令

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
58
59
60
61

# ─── 卷管理 ───

# 创建卷
openstack volume create --SIZE 100 --TYPE ssd my-volume
#                      ├── --SIZE 卷容量（GB）
#                      ├── --TYPE 卷类型（关联后端存储）
#                      ├── --AVAILABILITY-ZONE 指定可用域
#                      ├── --BOOTABLE 标记为可启动卷
#                      └── --PROPERTY 自定义元数据

# 列出卷
openstack volume list
#                      ├── --ALL-PROJECTS（管理员）查看所有项目
#                      ├── --NAME 按名称筛选
#                      └── --STATUS 按状态筛选（available/in-use）

# 查看卷详情
openstack volume show <VOLUME_ID_OR_NAME>
#                      └── 显示 ID、大小、状态、挂载点、卷类型等

# 删除卷
openstack volume delete <VOLUME_ID_OR_NAME>
#                      └── 仅 available 状态的卷可删除

# 扩展卷
openstack volume set --SIZE <NEW_SIZE> <VOLUME_ID_OR_NAME>
#                      └── 支持在线扩展（in-use 状态也可）

# 重命名/更新卷属性
openstack volume set --NAME new-name --property key=value <VOLUME_ID>

# ─── 挂载与卸载 ───

# 挂载卷到虚拟机
openstack server add volume <SERVER> <VOLUME>
#                      └── Nova 自动完成 iSCSI/Ceph 连接和 libvirt 配置

# 从虚拟机卸载卷
openstack server remove volume <SERVER> <VOLUME>
#                      └── 先卸载卷，再断开后端连接

# ─── 快照管理 ───

# 创建快照
openstack volume snapshot create --VOLUME <VOLUME> <SNAPSHOT_NAME>
#                      ├── --NAME 快照名称
#                      └── --FORCE 强制创建（in-use 状态）

# 从快照创建新卷
openstack volume create --SNAPSHOT <SNAPSHOT> --SIZE <SIZE> <VOLUME_NAME>
#                      └── 快照的写时复制机制，秒级创建

# ─── 备份管理 ───

# 创建备份
openstack volume backup create --VOLUME <VOLUME_ID> --NAME <BACKUP_NAME>
#                      └── 支持增量备份

# 从备份恢复
openstack volume backup restore <BACKUP_ID> <VOLUME_ID>
#                      └── 恢复到已有卷或创建新卷

四、卷类型与多后端存储 🔌

Volume Type 体系

Cinder 通过**卷类型（Volume Type）**实现存储策略的抽象，用户创建卷时选择类型，Cinder 自动路由到对应后端。

1
2
3
4
5
6
7
8
9
10
11
12

Volume Type = 名称 + 元数据（key-value）

内置元数据:
  ├── volume_backend_name  → 关联存储后端（核心关联字段）
  ├── capabilities:SSD     → 性能标签
  └── capabilities:replication  → 复制能力

可扩展元数据（Extra Specs）:
  ├── qos:total_iops_sec   → QoS IOPS 上限
  ├── qos:total_bytes_sec  → QoS 带宽上限
  ├── compression:gzip     → 压缩策略
  └── replication_type:sync → 同步复制

多后端配置与管理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 创建卷类型
openstack volume type create --property volume_backend_name=LVM lvm-type
#                      └── lvm-type 将自动路由到 LVM 后端

openstack volume type create --property volume_backend_name=RBD ceph-type
openstack volume type create --property volume_backend_name=FC_SAN fc-type

# 创建 QoS 规格
openstack volume qos create --consumer front-end high-iops \
  --property total_iops_sec=5000

# 将 QoS 关联到卷类型
openstack volume type set --qos high-iops ceph-type

# 使用指定类型创建卷
openstack volume create --TYPE ceph-type --SIZE 100 my-db-volume

cinder.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
29
30
31
32
33
34
35
36

[DEFAULT]
# 启用多个后端（用逗号分隔）
enabled_backends = lvm,ceph,nfs,fc

# ─── LVM 后端（开发测试） ───
[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
volume_backend_name = LVM
target_protocol = iscsi
target_helper = lioadm

# ─── Ceph RBD 后端（生产推荐） ───
[ceph]
volume_driver = cinder.volume.drivers.rbd.RBDDriver
rbd_pool = volumes
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_user = cinder
rbd_secret_uuid = 457eb76a-9e0d-4a8a-9b0d-9d3a8c9e1b2f
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
volume_backend_name = RBD

# ─── NFS 后端 ───
[nfs]
volume_driver = cinder.volume.drivers.nfs.NfsDriver
nfs_shares_config = /etc/cinder/nfs_shares
nfs_qcow2_volumes = true
nfs_mount_options = rw,sync,noatime,nolock
volume_backend_name = NFS

# ─── FC SAN 后端 ───
[fc]
volume_driver = cinder.volume.drivers.fibrechan.FibreChannelDriver
volume_backend_name = FC_SAN
use_multipath_for_image_xfer = true

五、后端存储深度对比 💾

总览对比表

LVM (iSCSI) — 参考实现

1
2
3
4
5

[lvm]
volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
volume_group = cinder-volumes
target_protocol = iscsi
target_helper = lioadm

准备:

1
2

pvcreate /dev/sdb /dev/sdc
vgcreate cinder-volumes /dev/sdb /dev/sdc

命令行操作:

1
2
3
4
5
6

# 查看卷组
vgs
# 查看逻辑卷
lvs
# 手动创建 LVM 卷（Cinder 自动化此操作）
lvcreate -L 100G -N volume-<UUID> cinder-volumes

⚠️ 生产警告: LVMVolumeDriver 是官方参考实现，不推荐用于生产。LVM 为单机解决方案，无高可用。服务器不可用时所有托管卷不可用。内核/iSCSI 升级会导致存储连接中断。

Ceph RBD — 生产首选

1
2
3
4
5
6
7
8
9
10

[ceph]
volume_driver = cinder.volume.drivers.rbd.RBDDriver
rbd_pool = volumes
rbd_ceph_conf = /etc/ceph/ceph.conf
rbd_user = cinder
rbd_secret_uuid = 457eb76a-9e0d-4a8a-9b0d-9d3a8c9e1b2f
rbd_flatten_volume_from_snapshot = false
rbd_max_clone_depth = 5
rbd_store_chunk_size = 4
rados_connect_timeout = -1

Ceph 端准备:

1
2
3
4
5
6
7
8
9
10
11
12

# 1. 创建存储池
ceph osd pool create volumes 128
ceph osd pool application enable volumes rbd

# 2. 创建 Cinder 用户并授权
ceph auth get-or-create client.cinder \
  mon 'profile rbd' \
  osd 'profile rbd pool=volumes, profile rbd pool=vms' \
  -o /etc/ceph/ceph.client.cinder.keyring

# 3. 获取 secret UUID（用于 Nova 配置）
ceph auth get-key client.cinder

核心优势:

• 弹性扩展: 支持 PB 级存储池，单集群承载数千虚拟机
• 数据冗余: CRUSH 算法跨节点复制（默认 3 副本）
• 写时复制: RBD 克隆秒级创建新卷
• 零额外路径: Nova 通过 librbd 直接读写 Ceph 集群

NFS — 共享场景

1
2
3
4
5
6
7

[nfs]
volume_driver = cinder.volume.drivers.nfs.NfsDriver
nfs_shares_config = /etc/cinder/nfs_shares
nfs_qcow2_volumes = true
nfs_mount_options = rw,sync,noatime,nolock
nfs_snapshot_support = true
nas_secure_file_operations = false

NFS 共享文件 (/etc/cinder/nfs_shares):

1
2

192.168.1.100:/export/cinder
192.168.1.101:/export/cinder

注意: 必须使用 NFS v4 及以上版本，不要使用 NFS v3。需注意 SELinux 上下文配置。

iSCSI (外部 SAN) — 企业集成

1
2
3
4
5
6
7
8
9
10

[iscsi]
volume_driver = cinder.volume.drivers.lvm.LVMISCSIDriver
# 或对应厂商驱动（NetApp/Dell EMC/HPE 等）
volume_backend_name = ISCSI_BACKEND
target_protocol = iscsi
target_helper = lioadm
san_ip = 192.168.1.100
san_login = admin
san_password = password
use_multipath_for_image_xfer = true

多路径配置（生产必需）:

1
2
3
4
5
6
7
8
9
10
11

# 安装 multipath-tools
apt-get install multipath-tools

# 配置 multipath.conf
echo 'defaults {
    user_friendly_names yes
    find_multipaths yes
}' > /etc/multipath.conf

systemctl enable multipathd
systemctl start multipathd

六、快照与克隆 📸

快照机制

Cinder 快照基于**写时复制（Copy-on-Write）**技术，创建时间恒定在秒级：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

快照创建前:
  ┌─────────────────────────────────┐
  │         原始卷 (Volume)           │
  │  ┌───┬───┬───┬───┬───┬───┬───┐  │
  │  │ A │ B │ C │ D │ E │ F │ G │  │
  │  └───┴───┴───┴───┴───┴───┴───┘  │
  └─────────────────────────────────┘

快照创建后（COW）:
  ┌─────────────────────────────────┐
  │ 原始卷: 新写入 → 新分配块        │
  └─────────────────────────────────┘

  ┌─────────────────────────────────┐
  │ 快照: 冻结在某个时间点的数据状态    │
  │  ┌───┬───┬───┬───┬───┬───┬───┐  │
  │  │ A │ B │ C │ D │ E │ F │ G │  │ ← 原始数据不变
  │  └───┴───┴───┴───┴───┴───┴───┘  │
  └─────────────────────────────────┘

快照操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 创建快照
openstack volume snapshot create --VOLUME my-volume my-snap
#                      └── 秒级完成，不中断 I/O

# 强制快照（in-use 状态）
openstack volume snapshot create --VOLUME my-volume --FORCE my-snap
#                      ⚠️ --FORCE 可能产生不一致快照
#                      建议配合应用层面的一致性检查

# 列出快照
openstack volume snapshot list

# 查看快照详情
openstack volume snapshot show <SNAPSHOT_ID>

# 从快照创建新卷
openstack volume create --SNAPSHOT my-snap --SIZE 100 restored-volume
#                      └── RBD 后端利用 COW，不拷贝数据

# 删除快照
openstack volume snapshot delete <SNAPSHOT_ID>

一致性组 (Consistency Group)

保证多个卷的原子性快照，适用于数据库等跨多卷的一致性敏感场景：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 创建一致性组
openstack volume group create --NAME db-consistency-group \
  --VOLUME-TYPE ceph-type

# 添加卷到组
openstack volume group add volume <GROUP_ID> <VOLUME1> <VOLUME2>

# 创建一致性组快照（原子操作）
openstack volume group snapshot create --GROUP <GROUP_ID> cg-snap
#                      └── 所有卷在同一个时间点被快照

# 从一致性组快照批量恢复
openstack volume group create --NAME restored-group \
  --GROUP-SNAPSHOT <CG_SNAPSHOT_ID>

Ceph RBD 克隆深度

1
2
3
4
5
6
7
8
9
10
11

Template Volume (golden image)
    │
    ├── Snapshot (base snap)
    │       │
    │       ├── Clone VM-1 (COW from snapshot)
    │       ├── Clone VM-2 (COW from snapshot)
    │       └── Clone VM-3 (COW from snapshot)
    │               │
    │               └── Snapshot of VM-3 → Clone VM-3-1 (嵌套克隆)
    │
    └── rbd_max_clone_depth = 5（默认最大嵌套深度）

配置控制:

1
2
3
4
5
6

rbd_flatten_volume_from_snapshot = false
# false: COW 模式，创建快照体积小但性能略降
# true:  创建时 flatten（解除依赖），性能恢复但占用全量空间

rbd_max_clone_depth = 5
# 限制克隆嵌套深度，避免过长的 COW 链降低性能

七、备份与恢复 💾

快照 vs 备份

备份操作

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# 创建备份（默认增量）
openstack volume backup create --NAME db-backup --VOLUME my-volume
#                      ├── --INCREMENTAL 增量备份（仅传变更数据）
#                      └── --FORCE 强制备份（in-use 状态）

# 列出备份
openstack volume backup list

# 查看备份详情
openstack volume backup show <BACKUP_ID>

# 从备份恢复到已有卷
openstack volume backup restore <BACKUP_ID> <VOLUME_ID>

# 删除备份
openstack volume backup delete <BACKUP_ID>

# 导出备份信息（用于跨区域迁移）
openstack volume backup record export <BACKUP_ID>

增量备份策略

1
2
3
4
5
6
7
8
9

备份策略示例（每周循环）:

周一 22:00: 全量备份 (full)      → 10GB
周二 22:00: 增量备份 (incr-1)    → 200MB（仅当日变更）
周三 22:00: 增量备份 (incr-2)    → 150MB
周四 22:00: 增量备份 (incr-3)    → 300MB
周五 22:00: 增量备份 (incr-4)    → 100MB
─────────────────────────────────────
总占用: ~10.75GB  (vs 全量×4=40GB)

恢复时 Cinder 自动按时间线回放增量链。

八、Cinder 与 Nova 的深度协作 🔗

启动卷（Boot from Volume）

Nova 支持从 Cinder 卷直接启动虚拟机，实现计算与状态完全分离：

1
2
3
4
5
6
7
8
9
10

# 从镜像创建可启动卷
openstack volume create --IMAGE ubuntu-22.04 --SIZE 50 --BOOTABLE boot-volume

# 从可启动卷创建虚拟机
openstack server create --VOLUME boot-volume --FLAVOR m1.medium my-server
#                      └── VM 状态完全保存在 Cinder 卷中

# 一步到位：从镜像创建 VM + 自动创建可启动卷
openstack server create --IMAGE ubuntu-22.04 --FLAVOR m1.medium \
  --BOOT-FROM-VOLUME 50 my-server

启动卷优势:

• 计算节点故障时，卷可立即挂载到其他 VM
• 支持实时迁移（Live Migration）无需共享存储
• VM 删除后数据保留

临时盘 vs 持久卷

卷迁移

1
2
3
4
5
6
7
8
9
10
11

# 在线迁移卷（不同后端之间）
openstack volume migrate --HOST <TARGET_HOST@BACKEND> <VOLUME_ID>
#                      └── 在 cinder-volume 之间迁移数据

# Nova 冷迁移（迁移到不同计算节点）
openstack server migrate <SERVER_ID>
#                      └── 卷作为独立资源自动跟随，无需重新挂载

# Nova 实时迁移
openstack server live-migration <SERVER_ID>
#                      └── 需使用共享存储或 Ceph RBD

九、加密卷 🔒

Cinder 加密支持

Cinder 支持卷级别的数据加密，确保静态数据安全：

1
2
3
4
5
6
7
8
9

# 创建加密卷类型
openstack volume type create encrypted-type \
  --encryption-provider luks \
  --encryption-cipher aes-xts-plain64 \
  --encryption-key-size 256 \
  --encryption-control-location front-end

# 使用加密类型创建卷（数据自动加密）
openstack volume create --TYPE encrypted-type --SIZE 100 secure-volume

加密方式对比:

十、QoS 质量保障 ⚡

QoS 规格管理

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

# 创建 QoS 规格
openstack volume qos create --consumer front-end high-iops \
  --property total_iops_sec=5000 \
  --property total_bytes_sec=104857600

# 参数说明:
#      ├── total_iops_sec  → IOPS 上限（每秒 I/O 次数）
#      ├── read_iops_sec   → 读 IOPS 上限
#      ├── write_iops_sec  → 写 IOPS 上限
#      ├── total_bytes_sec → 带宽上限（字节/秒）
#      ├── read_bytes_sec  → 读带宽上限
#      └── write_bytes_sec → 写带宽上限

# consumer 类型:
#      ├── front-end  → Nova/libvirt 层限速（推荐）
#      ├── back-end   → 存储后端驱动限速
#      └── both       → 两端同时限速

# 关联 QoS 到卷类型
openstack volume type set --qos high-iops premium-storage

# 查看 QoS
openstack volume qos show high-iops

# 解除关联
openstack volume type unset --qos premium-storage

十一、生产部署最佳实践 ✅

配额管理

1
2
3
4
5
6
7
8
9
10
11
12

# 查看项目配额
openstack quota show <PROJECT_ID>

# 设置项目配额（管理员）
openstack quota set --volumes 100 --gigabytes 1000 --snapshots 50 <PROJECT_ID>
#                      ├── --VOLUMES 最大卷数量
#                      ├── --GIGABYTES 最大总容量（GB）
#                      ├── --SNAPSHOTS 最大快照数量
#                      └── --BACKUPS 最大备份数量

# 查看 Cinder 后端当前的容量使用
cinder get-pools --detail

十二、版本演进趋势 🚀

💡 技术解析

• 术语: Filter Scheduler — Cinder 的调度算法，分为两阶段：Filter（过滤阶段）排除不满足条件的后端，Weighter（权重阶段）对剩余后端打分排序。通过可插拔的 Filter/Weighter 链实现灵活调度策略，如 CapacityFilter 排除容量不足节点、CapabilitiesFilter 匹配卷类型特性、AvailabilityZoneFilter 确保可用域亲和性。

• 术语: Volume Type — Cinder 的存储策略抽象机制，通过 Extra Specs（键值对元数据）关联 QoS 策略、后端名称、复制策略等。用户创建卷时指定类型，Cinder 自动调度到对应的存储后端。核心关联字段为 volume_backend_name。

• 术语: Copy-on-Write (COW) — 写时复制技术，Cinder 快照和 RBD 克隆的基础。创建快照时不拷贝数据，仅当原始卷有数据写入时，才将旧数据复制到快照预留区域。秒级创建快照，显著节省存储空间。

• 术语: RBD Clone — Ceph RBD 的快照克隆技术，基于 COW 从快照直接创生新卷。支持嵌套克隆，受 rbd_max_clone_depth 限制（默认5层）。可选项 rbd_flatten_volume_from_snapshot=true 解除 COW 依赖以恢复全性能。

• 术语: Consistency Group（一致性组） — 将多个卷组织为一个逻辑组，保证组内所有卷快照的原子性。解决数据库等多卷应用的时间点一致性问题，确保恢复时所有卷处于同一个一致的业务状态。

• 术语: Multipath I/O — 多路径 I/O 技术，通过多条物理路径访问同一存储设备，提供路径冗余和负载均衡。在 Cinder 中通过 device-mapper-multipath 实现，生产环境 iSCSI/FC 后端的必选项。

• 术语: Cinder Driver — Cinder 的存储后端插件化驱动接口，核心抽象包括 create_volume()、delete_volume()、extend_volume()、create_snapshot()、create_volume_from_snapshot() 等方法。OpenStack 社区维护 30+ 种驱动，商业存储厂商提供各自的认证驱动。

• 术语: Boot from Volume — Nova 从 Cinder 卷启动虚拟机的模式，根磁盘位于 Cinder 卷而非计算节点的临时盘上。实现计算与状态完全分离，支持在线迁移、卷快照备份、故障恢复。

• 命令: openstack volume create — 创建 Cinder 卷，--SIZE 指定容量（GB），--TYPE 指定卷类型关联后端，--IMAGE 从镜像创建可启动卷，--SNAPSHOT 从快照创建，--BOOTABLE 标记为可启动，--AVAILABILITY-ZONE 指定可用域，--PROPERTY 添加自定义元数据。

• 命令: openstack server add volume — 将 Cinder 卷挂载到 Nova 虚拟机，内部流程涉及 Nova 调用 Cinder os-attach API → Cinder 返回连接信息 → Nova 执行 iSCSI 登录/RBD map/NFS mount → libvirt 定义 disk 设备。挂载后卷以 /dev/vdX 出现在虚拟机内部。

• 命令: openstack volume snapshot create — 创建卷快照，--VOLUME 指定源卷，--FORCE 允许 in-use 状态强制快照（谨慎使用，可能数据不一致）。快照基于 COW 技术秒级完成。

• 命令: openstack volume qos create — 创建 QoS 规格，--CONSUMER 指定限速层级（front-end Nova 层/back-end 存储层/both），--PROPERTY 设置 total_iops_sec、total_bytes_sec、read_iops_sec、write_iops_sec 等限速参数。通过 Volume Type 关联到具体卷。

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
(本地磁盘)       (对象存储)          (分布式存储)

核心组件一览表

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

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 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 参数详解:

下载镜像

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 提供细粒度的镜像共享机制，支持三种可见性级别：

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 各后端对比

生产推荐: ✅ 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 场景性能优势

七、镜像缓存策略 📦

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>

十、生产部署最佳实践 ✅

十一、版本演进趋势 🚀

💡 技术解析

• 术语: 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 Heat（编排）详解

一、核心思想 🌟

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

二、HOT 模板结构 📄

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

1. 模板版本

1

heat_template_version: 2015-04-30

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]

常用资源类型速查：

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 }

三、内置函数 🔧

条件函数示例：

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 模板格式：

• 通过 heat-api-cfn 组件提供 CloudFormation 兼容 API
• 已有的 AWS CloudFormation 模板可直接提交给 Heat 执行
• 支持资源类型映射：AWS::EC2::Instance → OS::Nova::Server