Openstack架构介绍

OpenStack简介

起源

• 2006年：亚马逊推出AWS，开启云计算时代。

• 2010年7月：NASA与Rackspace合作发布OpenStack，对标AWS并兼容其服务。

• OpenStack从诞生之初对标AWS，一直在向AWS学习，同时开放接口去兼容各种AWS服务

定义

• OpenStack是用于管理虚拟机、裸金属和容器的云基础设施。

• 可统一控制数据中心的计算、存储和网络资源池。

• 所有资源通过API或Web界面管理。

功能

• 提供基础设施即服务（IaaS）解决方案。

• 各服务通过API集成，支持大规模扩展、实施简单、标准统一。

工作原理概述

• 由命令脚本组成的项目软件包构建云环境。

• 依赖两类软件：
• 虚拟化软件：抽象硬件资源。
• 基础操作系统：执行OpenStack指令。

• OpenStack本身不虚拟化资源，而是协调虚拟化层构建云。

• 与虚拟化软件、操作系统协同工作。

版本演进

• 首版代号Austin，后续版本按英文字母A–Z顺序命名，通常以峰会举办地命名。

• 目前8家白金会员：AT&T、爱立信、华为、英特尔、Rackspace、红帽、SUSE、腾讯。

设计理念

• 开放
• 源码、设计与开发流程全部开放。
• 不重复造轮子，不依赖私有/商业组件。

• 灵活
• 架构可裁剪，按需选择组件。
• 广泛使用驱动与插件机制。
• 通过配置项灵活启用功能。

• 可扩展
• 松耦合架构，组件间通过RESTful API通信，组件内消息总线通信。
• 无中心节点，避免单点故障。
• 无状态设计，所有持久化数据存于数据库。

OpenStack与虚拟化

• OpenStack不是虚拟化平台，仅提供控制面。

• 核心任务：将计算、存储、网络资源抽象为池，并封装为用户服务。

• 数据面（如Hypervisor、存储设备）不属于OpenStack范畴。

• 虚拟化是底层实现手段之一，非OpenStack核心关注点。

OpenStack与云计算

• OpenStack是构建云计算的骨干组件（如内核、框架、总线）。

• 云计算 vs 虚拟化：
• 云计算：IT能力服务化、按需使用、按量计费、多租户隔离。
• 虚拟化：环境隔离、资源复用、提升效率。

• 完整云平台还需：
• Cloud BSS（Cloud Business Support System，业务支撑系统）
• Cloud OSS（Cloud Operation Support System ，运营支撑系统）

• OpenStack核心服务简介
界面管理服务 Horizon
• 提供基于Web的控制界面，用于管理OpenStack资源和服务。
• 首次出现在“Essex”版本，依赖Keystone认证服务。
认证服务 Keystone
• 提供身份验证、服务发现和多租户授权支持（如LDAP、OAuth等）。
• 首次出现在“Essex”版本，为其他服务提供认证支持。
镜像服务 Glance
• 功能包括发现、注册和检索虚拟机镜像，支持多种存储方式。
• 如本地文件系统、Swift对象存储、Cinder块存储等
• 首次出现在“Bexar”版本，依赖Keystone。
计算服务 Nova
• 提供大规模可扩展的计算资源管理，支持裸机、虚拟机和容器。
• 首次出现在“Austin”版本，依赖Keystone、Neutron和Glance。
块存储服务 Cinder
• 调用不同存储接口驱动，将存储设备转化成块存储池，使虚拟机实例获得持久化存储。
• 首次出现在“Folsom”版本，依赖Keystone。
对象存储服务 Swift
• 提供高可用性、分布式、最终一致的对象存储服务，适合存储需要弹性扩展的非结构化数据。
• 首次出现在“Austin”版本，为其他服务提供对象存储。
网络服务 Neutron
• 负责管理虚拟网络，提供网络即服务功能。
• 首次出现在“Folsom”版本，依赖Keystone。
编排服务 Heat
• 支持云应用程序编排OpenStack基础设施资源，提供REST API及CloudFormation兼容API。
• 首次出现在“Havana”版本，依赖Keystone。
计量服务 Ceilometer
• 数据收集服务，提供规范化数据处理能力，支持客户计费、资源跟踪和警报。
• 首次出现在“Havana”版本。

OpenStack 创建 VM 时各主要项目间交互示例

• 创建一个VM需要计算资源，存储资源，网络资源，镜像

Openstack Horizon 界面管理

基于 Django 的 Horizon 体系结构

• 底层通过 openstack_dashboard.api 模块封装 OpenStack 各项目的 API（仅暴露子集），供上层调用

• 面板结构分三层：Dashboard → PanelGroup → Panel
• 所有界面元素模块化，表单、表格等封装为 Python 类（如 View 模块）

• 基于 Django 框架构建，结合现代前端技术
• 遵循 Django 的业务逻辑与表现分离原则
• 视图处理业务逻辑，模板控制系统表现
• 践行 DRY 原则，强调代码复用与可扩展性，便于快速开发管理面板

Horizon 界面介绍

项目视图

• 页面由 Dashboard、PanelGroup、Panel 及单击Panel 后渲染的内容组成

• 示例：当前 Dashboard 为“项目”，PanelGroup 为“计算”，Panel 为“概况”

• 项目（租户）是云中的组织单位，用户在其中创建和管理实例

管理员视图

身份管理视图

Openstack Keystone 认证管理

Keystone 简介

认证服务 Keystone

• 提供身份验证、服务发现和多租户授权
• 支持 LDAP、OAuth、OpenID Connect、SAML 和 SQL

• 首次出现在 OpenStack “Essex” 版本

• 为其他 OpenStack 服务提供统一认证支持

Keystone 在 OpenStack 中的定位

• 是 OpenStack 默认的身份管理系统（Identity Service）

• 属于共享服务层，为所有其他项目提供认证与授权能力

Keystone 基本概念

• Domain：代表机构或数据中心，必须全局唯一；是 User、Group、Project 的容器

• Project：资源集合单位，在所属域内唯一即可

• Role：权限定义单元，必须全局唯一

• 其他核心概念：
• User：可访问 OpenStack 服务的个体或系统，属于某个 Domain
• Group：User 的集合，便于批量授权，也属于某个 Domain
• Service：OpenStack 提供的服务类型（如计算、网络）
• Endpoint：服务的访问地址（Public / Internal / Admin）
• Token：临时访问凭证
• Credential：用于身份验证的数据（如用户名+密码）

Domain/Project、Role 与 Group/User 的逻辑关系

• 角色分配（Role Assignment）是一个三元组：Role + Identity（Group/User）+ Resource（Domain/Project）

Keystone 在 OpenStack 中的作用

• 作为用户与服务之间的桥梁

• 用户从 Keystone 获取 Token 和服务目录，在访问服务时附带 token；服务通过 Keystone 验证 Token 合法性

Keystone 与其他服务的交互

• 所有外部请求和内部服务调用均需先通过 Keystone 获取 Token

• 类似服务总线，是 OpenStack 安全体系的核心

Keystone 架构

• 主要组件
• Keystone API：对外接收认证、鉴权及其他身份管理请求
• Keystone Middleware：嵌入其他服务，缓存并验证 Token，减轻主服务负载
• Keystone Services：实现核心认证与授权逻辑，不同服务模块负责处理特定类型的身份管理任务
• Keystone Backends：实现 Keystone 各项服务的具体逻辑
• 不同的功能（如用户管理、角色分配等）可由不同的后端驱动（如 SQL、LDAP 等）提供支持
• Keystone Plugins：扩展认证方式（如 OAuth、Federation）

Keystone 对象模型

核心对象包括：Identity、Resource、Assignment、Token、Catalog、Policy、Service

• Token 包含 User、Scope（Project/Domain/Trust）、Role 信息

• 访问控制由 Policy（policy.json）定义

Service

• Keystone 内部由多个服务（如 Identity、Token）组合形成，并通过 Endpoint 暴露

• 也管理外部 OpenStack 服务（如 Nova、Glance）的注册与端点

Identity 提供身份凭据验证以及 User 和 Group 的数据

• 提供身份凭据验证，管理 User 和 Group，均隶属于某个 Domain

• 用户名/组名仅在所属 Domain 内唯一

Resource 提供有关 Project 和 Domain 的数据

• 管理 Project 和 Domain
• Project是OpenStack资源拥有者的基本单元，OpenStack中所有资源都属于特定项目

• 所有资源归属特定 Project；未指定 Domain 的 Project 自动归入 “Default” 域

Assignment 提供有关 Role 和 Role Assignment 的数据

• 管理 Role 与 Role Assignment

• Role 可在 Domain 或 Project 级别分配给 User 或 Group

Token 提供用户访问服务的凭证

• 代表用户访问权限的临时凭证

• Token一般包含User信息、Scope信息（Project、Domain或者Trust）、Role信息

Catalog 提供用于 Endpoint 的端点注册表

• 维护服务端点注册表，以便外部访问OpenStack服务

• Endpoint 分三类：Public（外部用户）、Internal（内部用户）、Admin（管理员）

Policy 定义其资源的访问策略

• 实现基于角色的访问控制（RBAC）

• 以 JSON 文件定义访问规则
• 策略文件的路径是/etc/SERVICE_NAME/policy.json，如 /etc/keystone/policy.json

使用示例

• 普通用户：获取 Token 和服务目录

• 管理员：管理用户、项目、角色、服务与端点

• 服务自身：验证 Token、查询其他服务位置

Keystone 对象模型分配关系示例

Region，Service， Endpoint 关系

• Catalog 中包含不同Region中的不同Service（Keystone的服务），每个 Service 一般提供不同类型的Endpoint

Keystone 工作原理与流程

支持多种认证方式

• 基于令牌（UUID / PKI / PKIZ / Fernet）

• 基于外部系统（如 REMOTE_USER）

• 基于本地凭证（用户名+密码，默认方式）

UUID 令牌

• 32 字节随机 ID，无附加信息
• 发送请求时，将这个Token ID以X-Auth-Token的方式传入

• 每次请求需向 Keystone 验证，增加服务负载

• 存储于数据库

PKI 令牌

• 使用私钥签名，包含用户和目录信息

• 支持本地验证（无需每次查 Keystone）

• 体积大（KB 级），可能超出 HTTP 头限制

• 工作过程
• 用户将用户名和密码发送给Keystone
• Keystone使用私钥加密秘钥生成令牌返回给客户端
• 客户每次向OpenStack 发送调用资源和服务请求时会携带这个Token令牌
• OpenStack 服务API会使用本地公钥对令牌进行验证

PKIZ 令牌

• PKI 的压缩版本，体积约为 90%，效果有限

• 验证流程与 PKI 相同
• 唯一的差别是在Keystone生成Token并返回给客户端时进行了压缩

Fernet 令牌（当前默认）

• 对称加密（AES），携带少量的用户信息，不存储于数据库

• 体积小（约 255 字节），适合大规模或多区域部署

• 每次验证需联系 Keystone（不支持本地验证）

• 需定期轮换密钥

• 验证流程
• 用户将用户名和密码发送给Keystone
• Keystone使用秘钥生成临时令牌并返回给客户端
• 客户每次向OpenStack发送调用资源和服务请求时，会携带这个Token令牌
• OpenStack服务API接收到请求后会将Token发送到Keystone进行验证，由Keystone验证其有效性和合法性。验证成功返回信息

令牌类型对比

• Region的数量影响PKI/PKIZ令牌的大小

• 从安全的角度上看，UUID无需维护密钥，PKI需要妥善保管Keystone server上的私钥，Fernet需要周期性的更换密钥

• 从安全、维护成本和成熟度上看，UUID > PKI/PKIZ > Fernet

特性	UUID	PKI	PKIZ	Fernet
大小	32 Byte	KB 级别	KB 级别	约 255 Byte
支持本地认证	不支持	支持	支持	不支持
Keystone 负载	大	小	小	大
存储于数据库	是	是	是	否
携带信息	无	User，Catalog 等	User，Catalog 等	User 等
涉及加密方式	无	非对称加密	非对称加密	对称加密 (AES)
是否压缩	否	否	是(90%)	否

令牌类型选择涉及多个因素，包括 Keystone 负载、region数量、安全因素、 维护成本以及令牌本身的成熟度

• Keystone server 负载低 → UUID

• Region < 3 且 Keystone 负载高 → PKI/PKIZ（旧版适用）

• Region ≥ 3 或 Keystone 新部署 → Fernet（推荐）

RBAC 原理

• Policy模块在检测时需要三方面的数据：
• 1、policy.json策略配置文件
• 2、auth_token添加到http头部的token数据
• 3、用户的请求数据

• 在图中实例policy.json文件中，定义了all_admin包含了 admin 和 internal_admin
• 定义了list_project针对all_admin的具体规则，create project时需要admin角色

RBAC 与 Policy

• 在 RBAC 中，权限与角色相关连，用户通过成为适当角色的成员而得到这些角色的权限

• 权限 = Who（User/Role） + What（操作/资源） + How（权限）

• policy.json 定义规则（如 “create_project 需 admin 角色”）

• 验证时结合：策略文件 + Token 信息 + 用户请求

OpenStack 认证流程（以创建 VM 为例）

• 用户 → Keystone：认证获取 Token
• 一般是用户名和密码

• 用户 → Nova：携带 Token 请求创建 VM

• Nova → Keystone：验证 Token

• Nova → Glance/Neutron：携带 Token 获取镜像/网络

• Glance/Neutron → Keystone：各自验证 Token

• 最终返回结果给用户

总结：Keystone 实现认证与权限控制

• 用户凭凭证获取 Token

• 所有服务调用均携带 Token 并由 Keystone 验证

• 具体操作权限由各服务根据 RBAC 和 policy.json 判断

Openstack Glance 镜像管理

Glance 架构

架构概览

各组件作用

• Client：如命令行工具、Horizon、Nova 等使用 Glance 的应用

• REST API：提供镜像操作接口

• Glance Domain Controller：核心调度中间件，分发请求至 Auth、Policy、DB 等模块

• Registry Layer（已废弃）：曾用于隔离元数据访问，Newton 后整合进 API，Stein 起完全移除

• Glance DB：存储配置与元数据，供内部组件共享

• Database Abstraction Layer (DAL)：统一数据库访问接口

• Glance Store：统一接口，处理与各类存储后端（如文件系统、Swift）的交互

架构简化历程

• V1 API：镜像元数据操作经 Glance-Registry
• Glance-API在接收到用户的RESTful请求后，如果该请求与元数据相关，则将其转发给Glance-Registry

• V2 API：Glance-Registry 功能并入 Glance-API，直接操作数据库

• Stein 版本起：Glance-Registry 彻底废弃，由 Glance-API + Store 模块替代

Glance 工作原理与流程

基本概念：镜像、实例和规格

• 镜像（Image）：含可引导操作系统的虚拟磁盘模板

• 实例（Instance）：运行中的虚拟机

• 规格（Flavor）：定义 CPU、内存、临时磁盘大小

镜像、实例和规格关系

• 同一镜像可启动多个实例，互不影响
• 每个启动的实例都是基于镜像的一个副本

• 启动实例必须指定规格

• 添加镜像时需指定磁盘格式和容器格式

支持的磁盘格式

• 其他镜像，可以先转换成OpenStack支持的格式，再导入使用

• raw：非结构化格式

• vhd / vhdx：VMware/Xen/Hyper-V 等使用

• vmdk：VMware 常用

• vdi：VirtualBox/QEMU 支持

• iso：光盘镜像

• qcow2：QEMU 格式，支持动态扩展与写时复制（推荐）

• aki / ari / ami：Amazon 镜像类型

• ploop：Virtuozzo 容器格式

容器格式（当前未被实际使用，建议设为 bare）

• bare：无容器封装（最常用）

• ovf / ova：OVF/OVA 格式

• docker：Docker tar 归档

• compressed：通用压缩格式

• aki / ari / ami：对应 Amazon 类型

镜像状态和转换图

• queued：仅元数据存在，未上传数据

• saving：正在上传镜像数据

• uploading / importing：通过 import 接口上传中

• active：可用状态

• deactivated：禁止非管理员访问

• killed：上传失败，不可用

• deleted / pending_delete：已删除或待清理（后者可恢复）

任务状态

• pending → processing → success / failure

镜像和实例交互流程

• 启动前：从 Glance 存储复制基础镜像到计算节点（作为 vda）

• 启动时：
• 镜像越小，启动越快
• 自动创建临时磁盘 vdb（随实例删除而清除）
• 计算节点使用 iSCSI 挂载 Cinder 卷为 vdc（通过 iSCSI）
• 如果 Cinder 卷位于单独的网络上，则存储节点配置文件中 my_block_storage_ip 选项会将镜像流量定向到计算节点
• 实例从 vda 启动并运行

• 删除后：
• 释放 vCPU、内存、临时磁盘
• Cinder 卷保留
• 原始镜像不受影响

Openstack Nova 计算管理

Nova 架构

Nova 系统架构

• 基于消息传递的“无共享”架构，主要组件可多节点部署，通过 RPC 监听消息
• DB：SQL 数据库存储数据
• API：接收 HTTP 请求，转换命令并通过 oslo.messaging 或 HTTP 通信
• Scheduler：为虚拟机选择合适的物理主机
• Conductor：协调复杂操作（如创建、调整规格），充当数据库代理
• Compute：执行虚拟机生命周期操作
• Placement：跟踪资源提供者库存与使用情况

• API 服务器处理 REST 请求，读写数据库，并通过 oslo.messaging 发送 RPC 消息

Nova 物理部署实例

• 无中心架构，各组件无本地持久化状态，支持水平扩展

• 通常将 nova-api、nova-scheduler、nova-conductor 部署在控制节点

• 多控制节点实现高可用与负载均衡，增加节点即可扩容

Nova 服务运行架构

• 组件可分布式部署，通过 virtDriver 对接不同虚拟化平台

Nova 资源池管理架构

• 层级结构：Region > Availability Zone > Host Aggregate

Nova 组件 - API

• 提供 REST 接口，处理请求

• 参数校验、配额检查、资源 CRUD、虚拟机生命周期入口

Nova 组件 - Conductor

• 功能：
• 解耦 nova-compute 与数据库访问
• 执行创建、迁移、规格调整、重建等复杂流程
• 支撑 nova-compute 启动依赖与心跳上报

• 优势：
• 安全：避免 compute 节点直连数据库
• 易升级：数据库变更无需更新 compute
• 性能：RPC 调用支持绿色线程并发，避免阻塞

Nova 组件 - Scheduler

• 决定虚拟机部署在哪台物理机

• 调度两步：过滤满足条件的节点 → 按权重选最优节点

Nova 组件 - Compute

• 虚拟机操作的实际执行者，调用对应 hypervisor 驱动

• 功能：
• 周期任务（资源刷新、状态同步）
• 资源统计（resource_tracker + 插件）
• 支持 KVM、VMware、Xen、LXC、QEMU 等虚拟化平台

• 架构：Manager + Driver

Nova 工作原理和流程

虚拟机状态类型及关系

• vm_state：数据库记录的状态

• task_state：当前任务状态（中间态或 None）

• power_state：从 hypervisor 获取的真实电源状态

• Status：对外展示状态，由 vm_state 和 task_state 联合生成
• 系统内部只记录 vm_state、task_state、power_state

虚拟机状态组合

• 各种命令所对应的虚拟机 ( VM ) 状态和任务状态
• https://docs.openstack.org/nova/latest/reference/vm-states.html?highlight=vm

vm_state: active

task_state	status
rebooting	REBOOT
reboot_pending	REBOOT
reboot_started	REBOOT
rebooting_hard	HARD_REBOOT
reboot_pending_hard	HARD_REBOOT
reboot_started_hard	HARD_REBOOT
rebuild_block_device_mapping	REBUILD
rebuilding	REBUILD
rebuild_spawning	REBUILD
migrating	MIGRATING
resize_prep	RESIZE
resize_migrating	RESIZE
resize_migrated	RESIZE
resize_finish	RESIZE
default	ACTIVE

vm_state: stopped

task_state	status
resize_prep	RESIZE
resize_migrating	RESIZE
resize_migrated	RESIZE
resize_finish	RESIZE
default	SHUTOFF

虚拟机状态变迁图

Nova 创建虚拟机流程

1. 用户通过 Dashboard/CLI 请求创建虚拟机，Keystone 授权并返回 token

2. nova-api 接收请求，验证 token 有效性

3. 初始化数据库记录

4. nova-scheduler 通过调度算法选出合适主机，更新数据库

5. nova-compute 从队列获取任务，通过 nova-conductor 获取实例详情

6. nova-compute 分别向 Glance、Neutron、Cinder 获取镜像、网络、存储信息（均经 Keystone 认证）

7. 调用虚拟化驱动创建虚拟机

Nova 调度过程

• 过滤器筛选 → 权重排序 → 选择最优主机

Nova 过滤调度器

• 所有权重位于 nova/scheduler/weights 目录下

• 默认使用 RAMWeigher，空闲内存越多，权重越高

Live Migration 原理

• 成功：清除源节点信息

• 失败：回滚并清除目标节点信息

Openstack Cinder & Swift 存储管理

块存储服务 Cinder

Cinder 简介

• 提供持久化块存储，支持多种后端存储驱动

• 首次出现在 “Folsom” 版本，依赖 Keystone

• 为 Nova 虚拟机、Ironic 裸机、容器提供卷服务

• 前身为 nova-volume，架构与 Nova 相似

• 本身不实现存储，仅提供统一抽象层，由厂商驱动对接实际设备

• 与 Nova 协同提供卷挂载，卷备份可存入 Swift

Cinder 架构

• Cinder Client：封装 REST 接口，提供 CLI

• Cinder API：处理卷、快照、备份、volume type、挂载等请求

• Cinder Scheduler：基于过滤器和权重选择合适后端

• Cinder Volume：多节点部署，通过驱动对接不同存储（默认 LVM）

• Cinder Backup：支持将卷备份至 Swift、Ceph、TSM 等

• SQL DB：存储元数据，支持 MySQL、PostgreSQL 等

后端存储支持

• 默认使用 LVM：将物理卷组成卷组，再划分逻辑卷

• 支持 SAN、Ceph、Sheepdog 及 EMC、华为等厂商设备

部署模式（以 SAN 后端为例）

• API、Scheduler、Volume 可合设或分离

• API 与 Scheduler 采用 AA 模式，通过 HAProxy + RabbitMQ 实现高可用与负载均衡

• Volume 多实例上报同一后端信息，协同处理请求

• RabbitMQ 与 MySQL 支持主备或集群

组件功能

• API：处理卷/快照/备份 CRUD、挂载/卸载、配额、类型管理

• Scheduler：
1. 列出所有后端
2. 用过滤器筛选（如 AZ、容量、能力、亲和性）
3. 用权重器排序（如容量、随机、自定义）
4. 返回最优后端

• Volume：调用驱动在不同的后端设备创建卷，默认驱动为 LVM

工作原理

• 创建卷流程：
1. Volume 定期上报后端容量 → Scheduler 更新内存状态
2. API 校验参数、预留配额、写 DB、发消息至 Scheduler
3. Scheduler 过滤+加权 → 选择后端 → 发消息至对应 Volume
4. Volume 调用驱动创建实际卷 → 更新 DB 记录

• 挂载卷流程：
• Nova 调用 Cinder API，传递主机信息（如 iSCSI initiator）
• Cinder Volume 通知存储授权该主机访问
• 返回连接信息（如 IQN、FC WWPN、NFS 路径）
• Nova 使用 brick 模块识别设备并通知 hypervisor 挂载到虚拟机

主要操作

• 卷（Volume）：创建、删除、扩容、挂载/卸载

• 快照（Snapshot）：创建、删除、回滚

• 备份（Backup）：备份与恢复

对象存储服务 Swift

对象存储和 Swift 服务概述

• 对象存储是具有成本效益的横向扩展存储的理想选择。它提供了一个完全分布式的、API可访问的存储平台，可以直接集成到应用程序中或用于备份、归档和数据保留

• OpenStack Object Storage（Swift）用于冗余、可扩展的数据存储，使用标准化服务器集群来存储 PB 级的可访问数据。它是一种适用于长期检索和更新大量静态数据的存储系统。

• 对象存储采用无中央控制点的分布式架构，提供更高的可扩展性、冗余性和持久性。对象被写入多个硬件设备，OpenStack 软件负责确保整个集群的数据复制和完整性。

• 存储集群通过添加新节点实现水平扩展。当一个节点发生故障时，OpenStack 会从其他活动节点复制其内容。OpenStack 使用软件逻辑确保数据在不同设备间的复制与分发

Swift 简介

• 提供高可用、分布式、最终一致的对象存储

• 适合存储镜像、图片、邮件、归档等静态非结构化数据

• 首次出现在 “Austin” 版本，依赖 Keystone

• 为 Glance、Cinder Backup 等提供后端存储

• 无中心节点，通过多副本保障数据持久性（理论可达 10 个 9）

Swift 特点

• 高持久性：多副本跨 Zone 存储

• 完全对称架构：所有节点对等，维护成本低

• 无限扩展：容量与性能线性增长，扩容自动均衡

• 无单点故障：元数据与数据同样分布存储

Swift 架构

• 采用完全对称、面向资源的分布式系统架构设计，所有组件都可扩展，避免因单点失效影响整个系统运转

• 访问层（Access Tier） ：
• Authentication：集成 Keystone，验证身份并颁发 Token
• Proxy Node：运行 Proxy Server 处理 REST 请求，转发至 Storage Node
• Cache Server：基于 Memcached 缓存 Token 和元数据存在性

• 存储层（Storage Nodes）：
• 分层结构：Region > Zone > Storage Node > Device > Partition
• Partition：指 Device 上文件系统中的目录，与传统硬盘分区概念不同

Swift 数据三层逻辑模型：Account → Container → Object

• 使用 swift stat 可查看 Swift 中 Account、Container 和 Object 的信息
• /account
• 唯一命名的逻辑存储区域，包含账户元数据及所属容器列表
• 注：此处“账户”指存储命名空间，非用户身份
• /account/container
• 用户在账户内创建的存储单元，包含容器元数据及所含对象列表
• /account/container/object
• 存储实际数据对象，由内容和关联元数据组成
• 不可嵌套到多个 Container

• 每层对应服务：Account Server、Container Server、Object Server

• 使用 Ring（环）映射 Partition 到物理设备，确保副本跨 Zone
• 通过 Zone、Device、Partition 和 Partition 的 Replica 维护该映射信息

Swift 组件

• Proxy Server：无状态 API 入口，支持横向扩展

• Authentication Server：验证身份信息并颁发 Token

• Cache Server：缓存对象访问令牌、账户和容器的存在性信息（不缓存对象数据本身）
• 基于 Memcached 集群实现，Swift 使用一致性哈希算法分配缓存地址

• Account/Container/Object Server：分别管理元数据与对象内容
• Account, Container 存储在 SQLite 数据库中，Object 内容以文件形式存储在文件系统（推荐 XFS）中，Object 元数据作为文件的扩展属性存储

• Auditor：定期校验数据完整性，修复损坏副本

• Replicator：同步副本，推式更新，清理已删对象

• Updater：异步处理高负载下的更新请求

Swift API

• 基于 HTTP 的 RESTful 接口

• 单对象默认上限 5GB（可配置），支持大对象分片上传

• 支持压缩、批量删除

• 操作总结：

资源	URL	GET	PUT	POST	DELETE	HEAD
Account	/account/	容器列表	—	—	—	获取元数据
Container	/account/container	对象列表	创建	更新元数据	删除	获取元数据
Object	/account/container/object	获取内容+元数据	创建/覆盖	更新元数据	删除	获取元数据

Swift 工作原理

• 用户请求 → Proxy Server → 认证 → 转发至对应存储服务

• 基于 一致性哈希 分布对象，减少扩容迁移量

• 采用 最终一致性 模型，牺牲强一致换取高可用与扩展性
• 对象及其副本之间的数据一致性由 Auditor、Updater、Replicator 共同保障

• Ring 将虚拟 Partition 均匀映射到物理设备，并强制 Partition 副本位于不同 Zone，实现容灾隔离

Openstack Neutron 网络管理

Linux 网络虚拟化基础

物理网络与虚拟化网络

• Neutron 的核心功能是对二层物理网络进行抽象和管理。

• 虚拟机网络由虚拟网卡（vNIC）和虚拟交换机（vSwitch）实现：vNIC 连接到 vSwitch 端口，vSwitch 最终通过物理网卡接入外部网络。

网卡虚拟化：TAP / TUN / VETH

• TAP：模拟二层设备，收发以太帧

• TUN：模拟三层设备，收发 IP 包
• TAP/TUN 在用户空间创建虚拟接口，可配置 IP 和路由，但流量仅限主机内流通

• VETH（Virtual Ethernet）：成对虚拟接口，一端发包，另一端收包。
• 常用于连接 Linux Bridge、OVS、容器等组件，构建虚拟网络拓扑。

交换机虚拟化：Linux Bridge、Open vSwitch

Linux Bridge

• 二层虚拟交换机，绑定其他网络设备作为桥接端口。

• 对上层协议栈透明，仅暴露 br0 接口。

• 绑定设备 ≈ 物理交换机插网线。

• 配置命令（brctl）：
• brctl addbr BRIDGE：创建网桥
• brctl addif BRIDGE DEVICE：添加端口

Open vSwitch (OVS)

• 产品级虚拟交换机，连接 vNIC 与物理网卡，支持跨 VM 桥接

• 相比 Linux Bridge，更适合大规模、多租户场景

• 常用命令（ovs-vsctl）：
• ovs-vsctl add-br BRIDGE：创建网桥
• ovs-vsctl add-port BRIDGE PORT：添加端口
• ovs-vsctl show：查看整体配置
• ovs-vsctl dump-ports-desc BRIDGE：端口详情
• ovs-vsctl dump-flows BRIDGE：流表条目

网络隔离：Network Namespace

• 创建隔离的网络空间，每个拥有独立设备、路由表、iptables 规则等

• 不同命名空间中的 VM 如同在独立物理网络中

• 常与 VRF（Virtual Routing Forwarding, 虚拟路由转发）配合使用

Neutron 核心概念

基本对象概览：Network、Subnet、Port、Router、Floating IP

Network：虚拟二层广播域（逻辑交换机）

• 类型：
• Local：单节点隔离，用于测试
• Flat：无 VLAN，同一 Flat 网络跨节点互通，单广播域
• VLAN：基于 802.1Q，生产常用
• VXLAN：UDP 封装 Overlay，突破 VLAN 二层限制
• GRE：IP 封装 Overlay

• 生产环境常用 VLAN、VXLAN、GRE。

Subnet：IPv4/IPv6 地址段，分配 VM IP

• 必须关联 Network。

• 可分配网关、DNS、静态路由等。

Port：虚拟交换机端口，VM 通过 Port 接入 Network。

• 可分配 MAC 和 IP

Router：连接 Subnet 或内外网

Fixed IP 与 Floating IP

• Fixed IP：Port 的固定 IP，类似物理网卡 IP。

• Floating IP：从 External Network 分配的可绑定 IP，通过 NAT 映射到 Fixed IP，实现外网访问。

Physical Network：连接 OpenStack 节点的真实网络

• 可承载多个虚拟网络

Provider Network：直接映射 Physical Network

• 由管理员创建，通常采用 VLAN 或 Flat 模式，可在多个租户之间共享

• 可跨租户共享，用于连通外部网络。

External Network：特殊 Provider Network，直连 Internet

• Router 接入此网络，绑定 Floating IP 实现双向通信。

Self-service Network（租户网络）

• 租户自行创建，通常采用 VXLAN 或 GRE 模式，仅本租户内可见和连通

• 可通过 Router 的 SNAT 访问 Provider Network。

• 不同租户可使用相同网段

Security Group

• 基于 iptables 的 Port 级防火墙策略
• 可以基于不同的协议，不同的端口号，不同的目的和源地址进行策略配置

• 每个项目含 default 安全组
• 默认拒绝所有入站，允许所有出站

Neutron 架构

• 设计原则：统一 API、核心最小化、可插拔、可扩展。

主要组件：Neutron Server、Message Queue、L2 Agent、L3 Agent、DHCP Agent

• Neutron Server：提供 API，维护网络资源状态，调用 Plugin 处理请求
• Advanced Services：LB、Firewall、VPN

• Message Queue：Server 与各 Agent 通信的通道（不用于 Nova 等外部服务）

• L2 Agent：实现二层连接（如 ovs-agent）
• 通常运行在 Hypervisor 节点上

• L3 Agent：处理路由、SNAT/DNAT、Floating IP
• 负责将租户网络（Self-service Network）连接到数据中心网络或 Internet
• 在实际生产环境中，通常部署多个 L3 Agent 以实现高可用和负载分担

• DHCP Agent：自动配置虚拟机网络

Neutron Server 提供 API，维护网络资源（如 Network、Subnet、Port 等）的状态，调用 Plugin 处理请求

• Core Plugin（ML2, Modular Layer 2）
• 通过 Type Driver 和 Mechanism Driver 支持多后端二层技术
• Type Driver：定义网络类型（VLAN/VXLAN 等），管理 ID 分配。
• Mechanism Driver：对接具体实现（OVS/Linux Bridge 等）
• 从 Type Driver 获取底层网络信息（如 segmentation ID、网络类型），并据此在计算或网络节点上正确配置二层网络连接

• Service Plugin 提供高阶服务：
• L3（路由/Floating IP）
• LB（负载均衡）
• Firewall（FWaaS）
• 运行在三层
• VPN

Agent 通过调用底层的虚拟或物理网络设备执行 Plugin 下发的任务

• L2 Agent：管理虚拟交换机和端口

• L3 Agent：三层路由/NAT/Floating IP

• DHCP Agent：提供 DHCP 服务

• Metadata Agent：提供实例 Neutron Metadata 服务访问
• 如 instance metadata、user data 等

Neutron 网络流量分析

• 典型场景
• Linux Bridge + Flat/VLAN：架构简单，依赖物理设备，适合中小私有云。
• OVS + VXLAN：支持多租户、大规模隔离，适合公有云/大型私有云。

Linux Bridge + Flat 网络概览

• Flat 网络类似于使用网线直接连接物理网络，OpenStack不负责网络隔离

Linux Bridge + VLAN 实现

• ML2 Type Driver：VLAN

• Mechanism Driver：Linux Bridge

• L2 Agent：Linux Bridge Agent

Linux Bridge + VLAN 流量分类

• 南北向：VM ↔ 外网

• 东西向：VM ↔ VM

• Provider ↔ 外网：由物理设备处理

Linux Bridge + VLAN 示例网络

• Provider Net 1：VLAN 101, 203.0.113.0/24, 网关在物理设备

• Provider Net 2：VLAN 102, 192.0.2.0/24, 网关在 vRouter

南北向流量（Fixed IP）

• VM → veth → Bridge → 安全组 → VLAN 子接口 → 物理网卡（打 VLAN tag）→ 物理交换机（剥 tag）→ 路由器 → 外网

东西向流量（同网络）

• VM1 → veth → Bridge → 安全组 → VLAN 子接口 → 计算节点 1 物理网卡（打 VLAN tag） → 交换机（按 MAC 转发）→ 计算节点2 物理网卡（剥 tag）→ VLAN 子接口 → 安全组 → Bridge → veth → VM2

东西向流量（不同 Provider 网络）

• VM1 → VLAN 101 → 路由器（剥 tag → 路由 → 打 VLAN 102）→ VM2

OVS 核心组件

• br-int（集成网桥）：连接 VM（tap/veth）
• 打/剥内部 VLAN 标签（local VLAN）实现租户隔离

• br-tun（隧道网桥）：跨节点通信，VXLAN/GRE 封装
• VLAN ↔ Tunnel ID 映射
• Tunnel ID: VNI / TUN_ID
• 示例流程：VM → br-int（VLAN 100）→ br-tun（映射 VNI 5000）→ VXLAN → 目标节点解封装 → br-int（VLAN 100）→ VM

• 路由器命名空间：实现三层路由
• 东西向：子网间转发
• 南北向：SNAT 出外网

OVS + VXLAN 实现

• ML2 Type Driver：VXLAN

• Mechanism Driver：Open vSwitch

• L2 Agent：OVS Agent

OVS + VXLAN 流量分类

• 南北向：VM ↔ 外网

• 东西向：VM ↔ VM
• 包括同一或不同 Self-service 网络内

• Provider ↔ 外网：由物理设备处理

OVS + VXLAN 示例拓扑

• Provider Net：VLAN 101

• Self-service Net 1：VXLAN VNI 101

• Self-service Net 2：VXLAN VNI 102

• Self-service Router：外接 VLAN 101，内接两个 VXLAN 网络

南北向流量（Self-service + Fixed IP）

• 计算节点：
1. 虚拟机流量经安全组网桥进行安全规则检查。
2. 进入 OVS 集成网桥（br-int），打上内部 VLAN 标签。
3. 映射为 VXLAN 隧道 ID（VNI=101）。
4. 经 OVS 隧道网桥（br-tun）进行 VXLAN 封装。
5. 通过物理网卡发往网络节点。

• 网络节点：
1. 解封装 VXLAN，还原内部 VLAN 标签。
2. 流量进入路由器命名空间，进行三层路由。
3. 从 Self-service 网络侧路由到 Provider 网络侧。
4. 流量进入 OVS Provider 网桥（br-provider），内部 VLAN 转为物理 VLAN 101。
5. 经物理网卡发送至外网。

外网访问 Floating IP

• 网络节点：
1. 外网流量经物理网卡进入，带物理 VLAN 101 标签。
2. OVS Provider 网桥将物理 VLAN 转为内部 VLAN 标签。
3. 流量进入路由器命名空间，进行 DNAT（将 Floating IP 转为 Fixed IP）。
4. 从 Provider 网络侧路由到 Self-service 网络侧。
5. 流量被打上对应网络的内部 VLAN 标签，并映射为 VXLAN VNI。
6. 经隧道网桥封装为 VXLAN，发往计算节点。

• 计算节点：
1. 解封装 VXLAN，还原内部 VLAN 标签。
2. 流量经集成网桥转发至安全组网桥进行安全规则检查。
3. 最终送达目标虚拟机。

东西向流量（同 Self-service 网络）

• 源计算节点：
1. 虚拟机流量经安全组检查。
2. 进入集成网桥，打上内部 VLAN 标签。
3. 映射为 VXLAN VNI（如 101）。
4. 经隧道网桥封装后，直接通过 overlay 网络发往目标计算节点。

• 目标计算节点：
1. 解封装 VXLAN，还原内部 VLAN 标签。
2. 流量经集成网桥转发至安全组进行检查。
3. 送达目标虚拟机。

东西向流量（不同 Self-service 网络）

• 源计算节点：
1. 流量经安全组检查后进入集成网桥，打上源网络的内部 VLAN 标签。
2. 映射为 VNI（如 101），经 VXLAN 封装发往网络节点。

• 网络节点：
1. 解封装 VXLAN，还原 VLAN 标签。
2. 流量进入路由器命名空间，在不同 Self-service 网络接口间路由。
3. 从目标网络接口流出，被打上目标网络的内部 VLAN 标签。
4. 映射为新 VNI（如 102），重新封装为 VXLAN。
5. 通过 overlay 网络发往目标计算节点。

• 目标计算节点：
1. 解封装 VXLAN，还原内部 VLAN 标签。
2. 经安全组检查后送达目标虚拟机。

Openstack Heat 编排管理

Heat 架构

架构概览

• 用户提交模板和参数请求 → Heat-api/Heat-api-cfn验证 → Heat-engine处理

• Heat模板描述资源集合（虚拟机、网络、存储等），可多次创建相同资源

核心组件

• Heat-api：提供OpenStack原生REST API
• 通过 RPC 将请求转发给 Heat-engine 进行处理

• Heat-api-cfn：提供AWS CloudFormation 兼容 Query API

• Heat-engine：核心组件，负责模板解析、资源调度、调用其他 OpenStack 服务API

Heat Engine工作流程

• 第一层：接收请求，创建Stack（资源集合）

• 第二层：解析资源依赖关系，生成DAG（有向无环图）

• 第三层：按依赖顺序调用OpenStack服务API，执行资源操作

Heat 模板

• 默认使用YAML格式

• 必需字段：heat_template_version 和 resources
heat_template_version 可选项
• https://docs.openstack.org/heat/latest/template_guide/hot_spec.html
• 2013-05-23
• 2014-10-16
• 2015-04-30
• 2015-10-15
• 2016-04-08
• 2016-10-14（对应 OpenStack Newton）
• 2017-02-24（对应 OpenStack Ocata）
• 2017-09-01（对应 OpenStack Pike）
• 2018-03-02（对应 OpenStack Queens）
• 2018-08-31（对应 OpenStack Rocky）

• 可选字段：description、parameters、outputs、conditions

Heat 模板示例-“Hello World”

• 每个HOT模板必须包含带有有效HOT版本的heat_template_version键
• 上图由于QA要求未呈现

Heat 模板 Resource 字段定义

• openstack orchestration resource type list
• 查找需要创建的资源

• openstack orchestration resource type show <typename>
• 列出资源详情

Stack：资源的集合，Heat 管理资源的基本单位

• 从模板创建 Stack
• openstack stack create --template server_console.yaml --parameter "image=ubuntu" STACK_NAME

• Heat Stack常用命令
• stack list
• stack create
• stack show
• stack delete
• stack output list
• stack resource list
• stack event show

Heat 典型编排场景

Heat 从多方位支持对资源进行设计和编排

• 基础架构资源编排：对计算、存储和网络等基础资源进行编排，支持用户自定义脚本配置虚拟机

• 应用资源编排：实现对虚拟机的复杂配置，例如安装软件、配置软件

• 高级功能编排：例如应用的负载均衡和自动伸缩

• 第三方工具集成编排：例如复用用户环境中现有的 Ansible Playbook 配置，节省配置时间

基础架构资源编排

• 使用资源类型如OS::Nova::Server、OS::Neutron::Port

• 示例：openstack stack create -template server.yaml --parameter image=ubuntu

应用资源编排：软件配置和部署

• 提供了多种资源类型来支持软件配置和部署的编排，例如：
• OS::Heat::CloudConfig：VM 引导程序启动时的配置，由 OS::Nova::Server 引用。
• OS::Heat::SoftwareConfig：描述软件配置。
• OS::Heat::SoftwareDeployment：执行软件部署。
• OS::Heat::SoftwareDeploymentGroup：对一组 VM 执行软件部署。
• OS::Heat::SoftwareComponent：针对软件的不同生命周期部分，对应描述软件配置
• OS::Heat::StructuredConfig：与 OS::Heat::SoftwareConfig 类似，但使用 Map 来表述配置
• OS::Heat::StructuredDeployment：执行 OS::Heat::StructuredConfig 对应的配置
• OS::Heat::StructuredDeploymentGroup：对一组 VM 执行 OS::Heat::StructuredConfig 对应的配置

高级功能编排：自动伸缩

• 使用Heat自动伸缩组和策略，结合Ceilometer实现负载自动伸缩

高级功能编排：负载均衡

• 使用资源类型：
• OS::Neutron::Pool：定义资源池
• OS::Neutron::PoolMember：定义资源池成员
• OS::Neutron::HealthMonitor：定义健康检查
• OS::Neutron::LoadBalancer：定义负载均衡配置

配置管理工具集成

• 支持与Chef、Puppet和Ansible等配置管理工具集成

• 通过OS::Heat::SoftwareConfig和OS::Heat::SoftwareDeployment协同工作

Openstack Ceilometer 计量管理

Ceilometer 告警处理 Aodh 服务

• Aodh 服务构成：
• API：提供RESTful接口
• Alarm Evaluator：检查非事件类型告警
• Alarm Listener：监听事件消息检查告警
• Alarm Notifier：执行用户定义动作