OpenStack Ceilometer 监控计量服务概念

Ceilometer 是 OpenStack Telemetry 项目的数据收集层，负责采集云平台中各类资源的计量（Meter）和事件（Event）数据，输出给下游的 Gnocchi（时间序列存储）、Aodh（告警）、CloudKitty（计费）等组件，为性能调优和成本分析提供数据基础📊。

一、两种数据采集方式

Polling Agent 三种角色

📝 等价关系：ceilometer-agent-compute ≡ ceilometer-polling --polling-namespaces COMPUTE，Central 和 IPMI 同理。

二、Pipeline 数据处理管道

采集的原始数据经过 Pipeline 三阶段处理⚙️：

1

Gathering（汇集） ➔ Transforming（转换） ➔ Publishing（发布）

1. Gathering（数据汇集）

从 Notification Agent 或 Polling Agent 接收原始计量数据与事件。

2. Transforming（转换计算）

支持多种转换器处理原始数据，例如：

• rate-of-change：将累计值转换为速率
• arithmetic：数学计算（CPU Time → CPU 利用率百分比）
• aggregation：聚合计算（平均值、最大值、最小值）

3. Publishing（发布输出）

处理后的数据可发布至以下目标端：

所有 Pipeleine 规则通过 pipeline.yaml 配置文件定义，支持灵活的过滤、转换和多重发布策略。

三、架构组件一览🏗️

数据流概览

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

OpenStack Services（Nova / Cinder / Neutron / Glance / Swift / Keystone / Heat）
        │
        ├─── Notification bus（AMQP）──► Notification Agent ──┐
        │                                                     │
        ├─── REST APIs ◄── Central Agent ─────────────────────┤
        │                                                     │
        └─── Hypervisor ◄── Compute Agent ────────────────────┤
                        ◄── IPMI Agent  ──────────────────────┤
                                                              │
                                                              ▼
                                                     Pipeline Manager
                                                              │
                                              ┌───────────────┴───────────────┐
                                              ▼                               ▼
                                          Gnocchi（存储）              Aodh（告警）
                                      CloudKitty（计费）          HTTP/Kafka/文件

四、架构演进🔧

早期 Ceilometer 集采集、存储、告警于一体，单体架构导致性能瓶颈。自 Ocata 版本起完成解耦：

1
2

旧版：Ceilometer（采集 + 存储 + 告警）
新版：Ceilometer（采集） ➔ Gnocchi（存储） + Aodh（告警）

关键变化：

• ceilometer-api 和 ceilometer-collector 不再使用
• 存储委托给 Gnocchi（时间序列数据库）
• 告警委托给 Aodh（独立告警服务）
• 事件存储委托给 Panko

五、生产建议⚠️

• 通知优先：Notification 机制对 API 服务无额外负载，优先使用
• 轮询间隔：通过 pipeline.yaml 配置合理的 polling 间隔，避免过度请求 API
• 存储后端：生产环境推荐 Gnocchi 替代传统数据库，性能显著提升
• 横向扩展：Ceilometer 各 Agent 支持多实例部署，按需增加 Worker 节点
• Jitter 配置：shuffle_time_before_polling_task 参数添加随机抖动，避免惊群效应

六、技术术语💡

• Telemetry — OpenStack 遥测项目组，包含 Ceilometer、Gnocchi、Aodh、Panko 四个子项目
• Meter — 计量样本，如 cpu_util、disk.read.bytes、network.incoming.bytes
• Event — 事件记录，如虚拟机创建/删除/迁移等操作
• Pipeline — 可配置的 YAML 管道，定义数据如何被转换和发布
• Gnocchi — 时间序列数据库，Ceilometer 的推荐存储后端
• Aodh — 基于 Ceilometer 数据的告警服务，支持阈值、组合等告警规则
• AMQP — 高级消息队列协议，Ceilometer 各组件间通过 RabbitMQ 实现异步通信
• Hypervisor — 虚拟机监视器（如 KVM/libvirt），Compute Agent 通过其采集 VM 数据

🔗 相关文档

OpenStack Cinder 块存储服务概念

Cinder 是 OpenStack 平台中的块存储服务组件，为虚拟机提供持久化块级存储设备，数据不随虚拟机生命周期结束而丢失🚀。其最初源自 Nova 项目中的 nova-volume，在 Folsom 版本中独立为 Cinder 项目。

核心设计理念：通过软件定义存储（SDS） 方式将存储资源抽象为可动态调度的逻辑卷，实现存储容量与计算资源的解耦。

一、核心架构

Cinder 采用微服务架构，由以下核心组件构成🏗️：

典型工作流

1
2

用户请求 ➔ cinder-api（接收+鉴权） ➔ 消息队列 ➔ cinder-scheduler（选节点）
    ➔ 消息队列 ➔ cinder-volume（执行操作） ➔ 返回结果

二、核心功能

1. 卷生命周期管理

提供完整的卷操作支持📦：

• 创建卷：从空白或指定镜像创建
• 删除卷：释放存储资源
• 扩展卷：在线扩容
• 挂载/卸载：将卷挂载到指定虚拟机
• 类型转换（retype）：在存储类型间迁移（如 HDD → SSD）

1
2
3
4
5

cinder create --display-name myvolume 10
cinder list
cinder show myvolume
cinder extend myvolume 20
cinder delete myvolume

2. 快照与克隆📸

基于写时复制（CoW）机制，秒级完成：

• 创建快照：对指定卷创建时间点副本
• 从快照创建卷：实现快速克隆
• 一致性组快照：保证多个卷的写一致性

1
2
3

cinder snapshot-create --display-name mysnapshot myvolume
cinder create --snapshot-id SNAPSHOT_ID 10
cinder snapshot-delete mysnapshot

3. 多后端存储支持

同一部署中支持启用多个存储后端，通过 Volume Type 和 volume_backend_name 指定卷创建位置💾：

4. QoS 策略⚡

通过 QoS 规格限制卷的最大 IOPS 与吞吐量，实现多租户资源隔离：

1
2

cinder qos-create high-iops consumer="front-end" read_iops_max=10000 write_iops_max=5000
cinder qos-associate QOS_ID VOLUME_TYPE_ID

5. 备份与灾备🛡️

• cinder-backup 服务支持跨区域备份
• 结合 Ceph 等后端可实现 RPO≈0 的容灾方案
• 三级数据保护：本地快照 ➔ 远程复制 ➔ 存储双活

1
2
3

cinder backup-create --display-name mybackup myvolume
cinder backup-list
cinder backup-restore BACKUP_ID

6. 卷迁移

跨主机迁移卷，支持在线迁移与离线迁移：

1
2

cinder migrate VOLUME_ID HOST_NAME
cinder migration-list

三、配置与管理

1. 创建卷类型

1
2

cinder type-create ssd
cinder type-key ssd set volume_backend_name=SSD_BACKEND

2. 挂载卷到虚拟机

1
2
3
4
5

# 挂载
nova volume-attach SERVER_ID VOLUME_ID

# 卸载
nova volume-detach SERVER_ID VOLUME_ID

3. 从镜像创建卷

1

cinder create --image-id IMAGE_ID --display-name bootable-volume 20

4. 从卷创建镜像

1

cinder upload-to-image --force True VOLUME_ID IMAGE_NAME

5. 配额管理

1
2

cinder quota-show PROJECT_ID
cinder quota-update --volumes 50 --gigabytes 500 PROJECT_ID

四、架构设计要点🔧

1. 控制-数据分离：控制平面（API/Scheduler）与数据平面（Volume）分离，支持横向扩展
2. 驱动抽象层：通过 VolumeDriver 接口标准化后端适配，厂商只需实现 create_volume、delete_volume、create_snapshot 等关键方法
3. Filter Scheduler 算法：先过滤（排除不满足条件的节点），再加权计算（基于容量、IOPS 排序），最终选择最优节点
4. 高可用设计：cinder-api 和 cinder-scheduler 可多节点部署，结合 Pacemaker 实现故障切换

五、生产环境建议⚠️

• 默认 LVM iSCSI 驱动存在性能瓶颈，仅建议用于评估和概念验证环境
• 生产环境建议使用 Ceph RBD 等企业级分布式存储后端
• 控制节点建议三节点集群 + 存储节点双活架构

六、常见问题排查

🔗 相关文档

OpenStack Glance 镜像服务概念

Glance 是 OpenStack 的核心组件之一，提供虚拟机镜像的发现、注册、存储和分发能力，为 Nova 计算服务提供启动镜像资源。

一、镜像格式

1. 磁盘格式（Disk Format）

Glance 支持多种磁盘格式，以适应不同的虚拟化平台和使用场景：

2. 容器格式（Container Format）

与磁盘格式配合使用，描述镜像是否封装：

二、镜像生命周期状态

三、镜像操作命令

1. 上传镜像

1
2

openstack image create --disk-format QCOW2 --container-format BARE --file ./IMAGE.QCOW2 镜像名
glance image-create --disk-format QCOW2 --container-format BARE --file ./IMAGE.QCOW2 --name 镜像名

• --disk-format：指定磁盘格式（QCOW2 / RAW / VMDK / ISO）
• --container-format：指定容器格式（常用 bare）
• --file：指定本地镜像文件路径
• --public / --private：设置镜像可见性

2. 下载镜像

1
2

openstack image save --file ./OUTPUT.QCOW2 镜像ID
glance image-download --file ./OUTPUT.QCOW2 镜像ID

3. 列出与查询镜像

1
2
3

openstack image list
openstack image show 镜像ID
glance image-list

• --status ACTIVE：筛选状态
• --disk-format QCOW2：按格式筛选

4. 删除镜像

1
2

openstack image delete 镜像ID
glance image-delete 镜像ID

5. 共享镜像

1
2

openstack image set --shared 镜像ID
openstack image add project 镜像ID 租户ID

• 通过 RBAC 策略控制租户间共享，支持 member 角色授权
• 镜像所有者可将镜像共享给指定租户

四、镜像导入高级特性

Glance 支持多种导入方式以满足不同场景：

1
2
3
4
5

# Web-Download 导入（从URL直接下载到后端存储）
openstack image create --disk-format QCOW2 --container-format BARE --import --uri HTTPS://EXAMPLE.COM/IMAGE.QCOW2 镜像名

# Glance-Direct 导入（任务方式导入）
glance md-namespace-list

• Web-Download：直接从 URL 拉取镜像到后端，不经过客户端，适合大文件
• Glance-Direct：基于任务的任务型导入，支持进度追踪
• Copy-Image：在不同存储后端间复制镜像（multi‑store 场景）

五、后端存储

Glance 架构将镜像元数据与镜像实际数据分离，支持动态切换后端：

镜像与后端存储解耦

Glance 的核心设计理念是将镜像的元数据（存于 MySQL/PostgreSQL）与实际数据（存于后端存储）彻底分离，带来以下优势：

• 后端可切换：无需修改镜像元数据即可更换存储后端
• Multi‑Store 多后端：可同时挂载多个存储后端，实现异构存储管理
• 存储扩展灵活：从本地文件到 Ceph/Swift 可平滑迁移

六、架构组件

生产最佳实践

• 生产环境推荐 QCOW2 + Ceph RBD 组合
• 使用 --public 或 --shared 管理跨租户共享权限，避免镜像重复上传
• 大镜像导入优先使用 Web-Download 模式，避免客户端网络瓶颈
• 定期清理 killed / deleted 状态的镜像以释放后端存储空间
• 多存储场景下可通过 Copy-Image 实现镜像在不同后端间的迁移

🔗 相关文档

OpenStack Heat 编排服务概念

Heat 是 OpenStack 的核心编排服务（Orchestration Service）🔥，通过声明式模板定义一组云资源及其依赖关系，实现基础设施即代码（IaC），自动化完成资源的创建、更新与删除。

核心设计理念：将基础设施部署转化为代码化模板，实现可重复、可版本控制、可自动化编排的云资源管理。

一、HOT 模板语法

Heat Orchestration Template（HOT）是基于 YAML 的声明式模板格式，是 Heat 的核心编排语言📝。

模板顶层结构

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

HEAT_TEMPLATE_VERSION: 2016-10-14
DESCRIPTION: 描述模板用途

PARAMETER_GROUPS:
  - LABEL: 网络配置
    PARAMETERS:
      - NETWORK_NAME
      - SUBNET_CIDR

PARAMETERS:
  NETWORK_NAME:
    TYPE: STRING
    LABEL: 网络名称
    DEFAULT: MY-NETWORK

RESOURCES:
  MY_NETWORK:
    TYPE: OS::NEUTRON::NET
    PROPERTIES:
      NAME: { GET_PARAM: NETWORK_NAME }

  MY_SERVER:
    TYPE: OS::NOVA::SERVER
    DEPENDS_ON: MY_NETWORK
    PROPERTIES:
      NAME: MY-INSTANCE
      FLAVOR: M1.SMALL
      IMAGE: CIRROS-0.6.2
      NETWORKS:
        - NETWORK: { GET_RESOURCE: MY_NETWORK }

OUTPUTS:
  INSTANCE_IP:
    DESCRIPTION: 实例IP地址
    VALUE: { GET_ATTR: [MY_SERVER, FIRST_ADDRESS] }

模板版本

二、三大核心概念

1. Stack（栈）📦

Stack 是 Heat 的基本部署单元，一次模板部署即产生一个 Stack。

Stack 生命周期：

1
2
3
4

CREATE_IN_PROGRESS → CREATE_COMPLETE
                      ↘ (回滚) → ROLLBACK_COMPLETE
UPDATE_IN_PROGRESS → UPDATE_COMPLETE
DELETE_IN_PROGRESS → DELETE_COMPLETE

嵌套 Stack（Nested Stack）：通过 OS::HEAT::STACK 类型引用子模板，实现模块化编排。

2. Resource（资源）📋

Resource 是 Stack 内被管理的具体 OpenStack 云资源。资源类型命名格式：OS::<服务>::<类型>。

资源间关系建立方式：

• DEPENDS_ON — 显式声明依赖
• GET_RESOURCE — 引用同 Stack 内其他资源的 ID
• GET_ATTR — 获取资源的运行时属性
• 自动推理 — Heat 引擎根据 PROPERTIES 引用自动推断隐式依赖

3. Parameter（参数）🔧

Parameter 是模板的输入变量，让模板在不同环境间复用：

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

PARAMETERS:
  INSTANCE_TYPE:
    TYPE: STRING
    LABEL: 实例规格
    DEFAULT: M1.SMALL
    CONSTRAINTS:
      - ALLOWED_VALUES: [M1.SMALL, M1.MEDIUM, M1.LARGE]
  ADMIN_PASSWORD:
    TYPE: STRING
    LABEL: 管理员密码
    HIDDEN: TRUE
    NO_ECHO: TRUE

环境文件（Environment File）：将参数值与模板分离，独立存储：

1
2
3
4
5

# ENVIRONMENT.YAML
PARAMETERS:
  INSTANCE_TYPE: M1.LARGE
RESOURCE_REGISTRY:
  "OS::NOVA::SERVER": "CUSTOM_SERVER.YAML"

三、架构组件

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

用户 (CLI / Horizon / API)
        │
        ▼
  ┌──────────┐   ┌──────────────────┐
  │ HEAT-API │──▶│   HEAT-API-CFN   │── AWS CloudFormation 兼容 API
  └────┬─────┘   └────────┬─────────┘
       │                  │
       ▼                  ▼
  ┌──────────────────────────────┐
  │        HEAT-ENGINE           │ ← 核心编排引擎
  │  (依赖解析 + 任务编排 + 回滚) │
  └──────┬───────┬───────┬───────┘
         │       │       │
         ▼       ▼       ▼
    OpenStack 服务 (Nova / Neutron / Cinder / ...)

heat-api — REST API 入口 🚪

• 暴露原生 Heat REST API（端口 8004）
• 接收模板提交与 Stack 操作请求
• 与 Keystone 集成进行认证鉴权

heat-api-cfn — CloudFormation 兼容 API 🔄

• 暴露 AWS CloudFormation 兼容的 Query API（端口 8000）
• 允许 AWS CloudFormation 工具/脚本直接对接 OpenStack
• 提供从 AWS 迁移到 OpenStack 的便捷路径

heat-engine — 核心编排引擎 ⚙️

四、与 AWS CloudFormation 兼容性

Heat 在设计上兼容 AWS CloudFormation 的模板语法和 API 风格，便于混合云或从 AWS 迁移的场景🔄。

五、常用操作命令

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

# 创建 Stack
openstack stack create -T TEMPLATE.YAML -E ENVIRONMENT.YAML MY-STACK

# 列出 Stack
openstack stack list

# 查看 Stack 详情
openstack stack show MY-STACK

# 查看 Stack 资源列表
openstack stack resource list MY-STACK

# 更新 Stack
openstack stack update -T TEMPLATE.YAML -E ENVIRONMENT.YAML MY-STACK

# 删除 Stack
openstack stack delete MY-STACK

# 查看 Stack 事件（排错用）
openstack stack event list MY-STACK

# 查看模板输出
openstack stack output show MY-STACK OUTPUT_NAME

六、Heat vs Terraform 对比 ⚖️

一句话概括

Heat 是 OpenStack 的 IaC 编排引擎——通过 HOT 模板定义 Stack（部署单元），Stack 包含 Resource（云资源）和 Parameter（输入参数），heat-engine 解析依赖 DAG 自动按序创建/更新/删除，实现基础设施部署的自动化与可重复。

🔗 相关文档

OpenStack Horizon Web界面概念 🖥️

Horizon 是 OpenStack 平台的官方 Web 管理界面组件（Dashboard），基于 Django 框架构建，为管理员和租户用户提供图形化的云资源管理入口，无需记忆命令行即可完成绝大部分日常操作🚀。

核心设计理念：将底层各 OpenStack 组件的 API 调用封装为直观的 Web 操作界面，降低使用门槛，提升运维效率。

一、核心架构

Horizon 采用 Django MTV（Model-Template-View）架构模式🏗️：

通信架构

1
2
3

浏览器（用户） ➔ Apache/nginx（WSGI） ➔ Horizon（Django App）
    ➔ REST API ➔ Keystone（认证） / Nova（计算） / Neutron（网络）
    ➔ Cinder（存储） / Glance（镜像） / Swift（对象存储）

二、界面结构

1. Dashboard（仪表板）与 Panel（面板）

Horizon 的界面按用户角色划分为两大 Dashboard📊：

2. UI 核心组件

Horizon 提供多种标准 UI 组件，确保界面一致性与可扩展性🎨：

• DataTables（数据表）：展示资源列表，支持排序、过滤、分页、批量操作
• Tabs & TabGroups（标签页）：将关联数据分组展示（如实例详情/控制台/日志）
• Workflows（工作流）：多步骤导向型操作，如创建实例（选择镜像 ➔ 选择规格 ➔ 网络配置 ➔ 确认）
• Forms（表单）：参数填写与配置提交
• Wizards（向导）：复杂操作的引导式流程

3. 用户设置

用户可在设置面板中个性化配置⚙️：

• 时区选择（Timezone）：控制时间显示
• 语言偏好（Language）：支持多语言切换
• 页面大小（Items Per Page）：列表每页显示条目数
• HTTP 日志（Logs）：查看 API 调用历史

三、核心功能

1. 计算管理（Nova）💻

2. 网络管理（Neutron）🌐

3. 存储管理（Cinder/Glance/Swift）💾

4. 项目与用户管理（Keystone）👥

四、扩展与定制 🔧

Horizon 支持丰富的定制与扩展能力：

1. Dashboard 注册机制

开发者的自定义功能通过 Django dashboard.py 文件注册到 Horizon：

1
2

# 将自定义面板注册到 Dashboard
dashboard.default_panels.append('MyCustomPanel')

2. 主题与品牌定制

• 修改 openstack_dashboard/settings.py 中的 AVAILABLE_THEMES 切换主题
• 支持自定义 Logo、品牌色、页脚、样式表
• 内置 Bootstrap 主题引擎，支持响应式布局

3. 功能模块扩展

• 采用 Django App 机制，各功能独立模块化
• Panel（面板）是基本功能单元，可自由增删
• 支持第三方插件（如 Heat / Mistral / Sahara 等扩展组件）

4. 常见扩展方式

五、部署模式

生产环境部署建议⚠️

1
2
3
4
5
6
7
8
9

# 安装 Horizon
apt install openstack-dashboard

# 配置 Apache
a2ensite 000-default
systemctl restart apache2

# HTTPS 配置（签发有效期检查）
openstack-config --set /etc/openstack-dashboard/local_settings.py DEFAULT_ENABLE_HTTPS True

六、监控与排查

七、Horizon SDN 管理思想

Horizon 的核心设计哲学：通过抽象化资源视图，屏蔽底层组件差异。

关键技术注解 💡

• Django MTV 架构: Horizon 的基础框架，Model（数据模型）→ Template（模板渲染）→ View（业务逻辑处理）
• REST API 封装: Horizon 内部通过 python-openstackclient 和各组件 SDK 与后端服务通信，用户操作最终转化为 API 调用
• Workflows 工作流: Horizon 独创的多步骤操作模式，将创建实例等复杂操作分解为有引导的步骤，每步可独立验证
• Panel 面板机制: 最细粒度的功能单元，支持按角色/权限动态加载显示，实现功能级 RBAC 控制

🔗 相关文档

Keystone认证服务概念

Keystone 是 OpenStack 中的身份认证服务（Identity Service）👤，负责用户认证、授权和服务目录管理。所有 OpenStack 服务之间的交互都必须经过 Keystone，它是整个云平台的安全中枢。

什么是 Keystone

Keystone 提供三大核心功能：

• 认证（Authentication） 🔐：验证用户身份的真实性
• 授权（Authorization） 🛡️：确定用户是否有权限执行特定操作
• 服务目录（Service Catalog） 📖：提供服务注册与发现能力，让各组件相互找到对方

User（用户）

操作主体，可以是人、服务或系统。

• 用户是执行操作的最小实体，本身不拥有资源
• 用户名在所属 Domain 内唯一，不同 Domain 可以有同名用户
• 用户必须加入特定 Project 并分配 Role 后才能访问资源
• 典型服务用户：nova、glance、cinder、neutron 等（用于服务间通信）

Project（项目）

资源归属的基本单元和隔离边界（V2 中称为 Tenant/租户）。

• 所有 OpenStack 资源（虚拟机、卷、镜像、网络等）都必须归属于某个 Project
• 一个 Project 可包含多个 User，每个 User 可分配不同 Role
• Project 名称在所属 Domain 内唯一
• 支持按 Project 设置配额（Quota）限制资源使用

Role（角色）

定义用户在 Project 或 Domain 中的操作权限级别。

• 角色存在隐式继承关系：admin ⊃ member ⊃ reader
• 授权机制 = Role + Policy（通过 policy.json 定义具体可执行的 API）

Domain（域）

V3 API 引入的高层容器和命名空间，是 Project、User、Group 的顶层隔离单元。

• Domain 名称全局唯一（其他资源只需域内唯一）
• 系统预设 Default 域
• 不同 Domain 支持不同的认证后端（如一个用 SQL，一个用 LDAP）
• 实现**真正多租户（Multi-tenancy）**架构，客户可在自己域内独立管理资源

Endpoint（端点）

服务的网络访问 URL，存储在服务目录（Service Catalog）中。

Token（令牌）

认证通过后 Keystone 颁发的字符串通行凭证。

Token 格式演进：

• UUID Token — 简单但需持久化到数据库，性能较差
• PKI Token — 包含大量信息，体积大，传输效率低
• Fernet Token ✅ — 当前默认，AES256 加密 + SHA256 签名，无需持久化，轻量安全

Group（组）

用户的集合容器（V3 新增）。

• 给 Group 分配 Role，组内所有用户自动继承该角色
• 避免逐一对每个用户分配角色的繁琐操作
• 类比 Linux 操作系统中的用户组

数据模型关系

1
2
3
4
5
6

Domain（域）[全局唯一]
├── Project（项目）[域内唯一] ← 资源归属
│   └── User + Role → 用户在项目中的权限
├── User（用户）[域内唯一] ← 认证主体
├── Group（组）[域内唯一] ← 用户集合
└── Role（角色）[域内唯一] ← 权限定义

典型认证流程

1
2
3
4
5
6

User → 提交凭证（用户名/密码）
     → Keystone 验证身份（Authentication）
     → 返回 Token + 服务目录（Endpoint 列表）
     → 携带 Token 调用 Nova/Glance 等服务
     → 目标服务用 authtoken 中间件向 Keystone 验证 Token
     → 验证通过，执行操作

使用场景

• 多租户云平台 ☁️：通过 Domain 隔离不同租户，Project 隔离租户内资源
• 服务间通信 🔄：Nova 调用 Glance 创建云主机时，使用服务用户 Token 进行认证
• 权限分级管理 🛡️：admin 管理平台、member 使用资源、reader 只读审计

一句话概括

Domain 是顶层容器，Project 是资源隔离单元，User 是操作主体，Role 是权限级别，Token 是通行凭证，Endpoint 是服务入口。六者协同构成 OpenStack 完整的身份认证与授权体系。

🔗 相关文档

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