OpenStack 管理：从认证、计算到存储与网络

⚠️ 注意事项：文中 IP（192.168.108.10）、密码（HUAWEI/huawei）、镜像与实例 ID 均为实验环境取值，实际操作请替换为自己环境的值；生产环境请关闭 debug、遵循最小权限原则。

一、OpenStack 基本概念

大白话：OpenStack 就是一套"云操作系统"------把一堆物理服务器、存储、网络打包成一个"资源池"，用户通过网页或命令行，像点外卖一样按需申请虚拟机、硬盘、网络。它本身不干活，而是指挥各个"小弟组件"分工干活。

核心术语

术语	大白话解释
Keystone	云平台的"门禁+身份证发放处"，管认证、鉴权、服务目录
Glance	云平台的"镜像仓库"，存放装系统用的模板
Nova	云平台的"包工头"，负责虚拟机的生老病死
Cinder	云平台的"硬盘柜"，提供云硬盘（块存储）
Swift	云平台的"大仓库"，存海量静态文件（对象存储）
Neutron	云平台的"网络管理员"，管虚拟网络、路由、防火墙
Heat	云平台的"装修队"，用模板一次性把整套环境搭好
Placement	云平台的"库存管理员"，记录每台机器还剩多少资源
Token	进门之后发的"临时通行证"，默认 24 小时有效
Endpoint	每个服务的"联系电话"（URL），分 admin/public/internal 三个入口
Project	"项目/租户"，资源的归属单位，公有云叫"租户"
Role	"角色"，一组权限的打包，全局唯一

一条主线串起所有组件

复制代码

用户 → Keystone 拿 Token → 拿着 Token 找 Nova 创建虚拟机
                              ↓
                    Nova 再去找 Glance 要镜像
                    Nova 再去找 Neutron 要网络
                    Nova 再去找 Cinder 要硬盘
                              ↓
              每个服务收到请求，都回头找 Keystone 验 Token

简单总结：Keystone 是"中枢神经"，所有跨服务调用都要经过它验票；组件之间靠 RabbitMQ 消息队列传话，互不直接绑定。

二、Keystone：认证管理

2.1 九大核心概念

大白话：Keystone 就是一套"公司门禁系统"------Domain 是公司，Project 是部门，User 是员工，Group 是小组，Role 是工牌等级，Token 是临时通行证。

概念	大白话解释
Domain（域）	"公司"，User/Group/Project 的容器，全局唯一
User（用户）	"员工"，访问云平台的个人或服务
Group（用户组）	"小组"，给组发工牌，组内成员自动继承
Project（项目）	"部门"，资源的归属单位，一个 User 可属于多个 Project
Role（角色）	"工牌等级"，权限的集合，全局唯一
Service（服务）	一种云服务，对外暴露一个或多个 Endpoint
Endpoint（端点）	服务的"联系电话"（URL），分 admin/public/internal
Token（令牌）	临时通行证，默认 24 小时
Credential（凭证）	证明身份的数据：密码、Token、API Key

关于 Project 的四个关键点：

资源所有权属于 Project，不属于 User
每个 User（包括 admin）必须挂在某个 Project 里才能访问资源
admin 相当于 Linux 的 root，拥有最高权限
"域角色"对整个域内所有项目生效，"项目角色"只对特定项目生效

2.2 认证与鉴权

Authentication（认证） ：解决"你是谁"------User 交凭证，Keystone 验证后发 Token。

Authorization（鉴权） ：解决"你能干什么"------Keystone 靠 Role 实现，每个 Service 通过自己的 policy.json 决定每个 Role 能干什么。

复制代码

policy.json 路径：
标准路径：/etc/<服务名>/policy.json（如 /etc/nova/policy.json）
packstack 安装：/etc/openstack-dashboard/<服务名>_policy.json

2.3 实操：Domain / User / Group / Role / Project

bash 复制代码

# 命令：加载管理员环境变量
[root@controller ~]# source keystonerc_admin
# 输出结果：命令行提示符变为 (keystone_admin)

Domain（域）管理：

bash 复制代码

# 命令：查看域列表
[root@controller ~(keystone_admin)]# openstack domain list

# 命令：创建域
[root@controller ~(keystone_admin)]# openstack domain create domain-test

# 命令：禁用域（删除前必须先禁用）
[root@controller ~(keystone_admin)]# openstack domain set --disable domain-test

# 命令：删除域
[root@controller ~(keystone_admin)]# openstack domain delete domain-test

开启 Horizon 多域登录界面：

bash 复制代码

# 命令：编辑配置文件
[root@controller ~(keystone_admin)]# vim /etc/openstack-dashboard/local_settings
# 第 83 行改为 True
OPENSTACK_KEYSTONE_MULTIDOMAIN_SUPPORT = True

# 命令：重启 httpd
[root@controller ~(keystone_admin)]# systemctl restart httpd

User（用户）管理：

bash 复制代码

# 命令：列出所有用户
[root@controller ~(keystone_admin)]# openstack user list

# 命令：创建用户 user1
[root@controller ~(keystone_admin)]# openstack user create --password HUAWEI user1

# 命令：查看用户详情
[root@controller ~(keystone_admin)]# openstack user show user1

Group（用户组）管理与授权：

bash 复制代码

# 命令：创建组
[root@controller ~(keystone_admin)]# openstack group create group1

# 命令：user1 加入 group1
[root@controller ~(keystone_admin)]# openstack group add user group1 user1

# 命令：验证归属
[root@controller ~(keystone_admin)]# openstack group contains user group1 user1
# 输出结果：user1 in group group1

# 命令：给 group1 在 admin 项目下赋予 admin 角色
[root@controller ~(keystone_admin)]# openstack role add --project admin --group group1 admin

# 命令：查看角色分配
[root@controller ~(keystone_admin)]# openstack role assignment list --names --group group1

Project（项目）与配额：

bash 复制代码

# 命令：创建项目 ProjectA
[root@controller ~(keystone_admin)]# openstack project create ProjectA

# 命令：将 user1 分配到 ProjectA
[root@controller ~(keystone_admin)]# openstack user set --project ProjectA user1

# 命令：给 user1 在 ProjectA 中赋予 admin 角色
[root@controller ~(keystone_admin)]# openstack role add --user user1 --project ProjectA admin

# 命令：修改项目配额（实例 3 台、vCPU 5 个、内存 5000MB）
[root@controller ~(keystone_admin)]# openstack quota set --instance 3 --cores 5 --ram 5000 ProjectA

2.4 一次访问背后的完整认证流程

以"admin 登录后查看镜像列表"为例：

复制代码

1. 登录：提交用户名密码 → Keystone 验证通过 → 签发包含 Role 信息的 Token
2. 拿目录：Keystone 同时返回各 Service 的 Endpoints
3. 访问镜像：admin 把请求（带 Token）发到 Glance Endpoint
4. 反向校验：Glance 拿 Token 向 Keystone 确认身份是否有效
5. 权限判定：Glance 查 /etc/glance/policy.json，确认 admin 有查看 image 的权限
6. 返回数据：校验通过，Glance 把镜像列表返回给 admin

创建虚拟机时的跨服务认证链：

复制代码

用户 → Keystone 拿 Token → 请求 Nova-api（请求头带 Token）
    → Nova-api 把 Token 交给 Keystone 验证
    → 验证通过后开始创建
    → Nova-compute 拿 Token 分别向 Glance 要镜像、Neutron 要网络、Cinder 要存储
    → 三个服务各自再向 Keystone 校验 Token
    → 全部通过后调用虚拟化驱动创建 VM → 返回成功

2.5 故障排查

bash 复制代码

# 命令：查看 keystone 日志
[root@controller ~]# ls /var/log/keystone/
# 输出结果：keystone.log

# 命令：需要最详细日志时打开 debug（生产环境无故障不要开）
[root@controller ~]# vim /etc/keystone/keystone.conf
# 第 94 行
debug=True

三、Glance：镜像管理

3.1 镜像的分类

大白话：镜像就是"装系统的模板"，像做蛋糕的模具------用同一个模具可以做出无数个蛋糕（实例），蛋糕上的奶油改了不影响模具本身。

类型	说明	可见性
公共镜像	平台提供的标准 OS 镜像，正版授权、高度稳定	所有用户
私有镜像	基于云主机或外部镜像文件制作，含个人应用	仅自己
共享镜像	其他用户共享过来的私有镜像	被共享者
市场镜像	预装 OS/应用的第三方镜像，一键部署	所有用户

3.2 镜像 / 实例 / 规格三者关系

复制代码

image（镜像）：模板
instance（实例）：运行中的虚拟机
flavor（规格）：资源配额（CPU/内存/磁盘）

关系：
- 同一个镜像可以启动任意数量的实例
- 每个实例都是镜像的一个副本，实例上的修改不影响镜像
- 启动实例时必须指定一个 flavor

3.3 磁盘格式与镜像状态机

常见磁盘格式：

格式	说明
qcow2	QEMU 支持，动态扩展 + 写时复制（COW），实验最常用
raw	非结构化磁盘镜像，ISO 光盘镜像通常是 raw
vmdk	VMware 常用
vdi	VirtualBox / QEMU
vhd/vhdx	Xen / Hyper-V / VirtualBox
iso	光盘存档格式
aki/ari/ami	Amazon 内核 / Ramdisk / 机器镜像

镜像状态机：

状态	含义
queued	已注册镜像 ID，但镜像数据未上传
saving	原始数据正在上传
uploading / importing	调用 import 请求 / 导入中
active	镜像创建完成，可以使用
deactivated	禁止任何非管理员访问、下载、导出
killed	上传过程出错，镜像不可读
deleted	保留信息但不可用，一段时间后自动清理

3.4 上传镜像实操

bash 复制代码

# 命令：确认文件的真实磁盘格式
[root@controller ~]# qemu-img info cirros-0.5.2-x86_64-disk.img
# 输出结果：
file format: qcow2          # 磁盘格式
virtual size: 112 MiB
disk size: 15.5 MiB

方式一：Horizon Web 界面上传（计算 → 镜像 → 创建镜像）

默认使用本地文件后端时，镜像数据落在：

bash 复制代码

# 命令：查找镜像文件
[root@controller ~]# find / -name <镜像ID>
# 输出结果：/var/lib/glance/images/<镜像ID>
# glance 数据库 image_locations 表记录：file:///var/lib/glance/images/<ID>

方式二：命令行上传大文件（推荐，带进度条）：

bash 复制代码

# 命令：上传 CentOS 镜像
[root@controller ~(keystone_admin)]# glance image-create --name image_centos \
  --file CentOS-7-x86_64-Minimal-1810.iso \
  --disk-format raw --container bare --progress

⚠️ Web 界面上传没有进度条只会转圈，大文件强烈建议用命令行，避免 Web 上传失败。

3.5 切换 Swift 作为后端存储

编辑 /etc/glance/glance-api.conf，关键配置：

ini 复制代码

[glance_store]
stores=file,http,swift
default_store=swift                       # 默认后端改为 swift
swift_store_region = RegionOne
swift_store_container = gqdglance
swift_store_large_object_size = 5120
swift_store_create_container_on_put = true
swift_store_multi_tenant = true
swift_store_admin_tenants = services
swift_store_auth_address = http://192.168.108.10:5000/v3
swift_store_user = swift
swift_store_key = <Swift密码>             # 安装时随机生成，在 answers.txt 的 CONFIG_SWIFT_HASH

bash 复制代码

# 命令：重启 glance 服务
[root@controller ~(keystone_admin)]# systemctl restart openstack-glance*

重启后再上传镜像，image_locations 中的路径会变成 swift+http://...，说明镜像已存入 Swift。

四、Nova：计算管理（核心）

4.1 Nova 的职责边界

大白话：Nova 就是云平台的"包工头"------负责虚拟机的创建、删除、重启、迁移，但不负责物理主机自身管理，也不做全面监控。

4.2 系统架构与组件

组件	职责
DB	SQL 数据库，存储状态数据
nova-api	接收 HTTP/REST 请求，转换命令
nova-scheduler	决定把虚拟机调度到哪台物理机
nova-compute	虚拟机生命周期的真正执行者，调用 Hypervisor Driver
nova-conductor	充当数据库代理，nova-compute 不直接碰 DB
Placement	跟踪资源提供者的库存和使用情况
RPC / oslo.messaging	基于 RabbitMQ 的远程过程调用，"无共享"架构

为什么要引入 nova-conductor？

原因	说明
安全	早期 nova-compute 直连数据库，一旦被攻陷就能操作整个数据库
易升级	数据库与 compute 解耦，schema 变化时 compute 无需升级
性能	直连 DB 是阻塞式的；conductor 走 RPC，绿色线程友好，不会阻塞并发

nova-compute 通过 driver 对接多种虚拟化平台：

bash 复制代码

# 命令：查看 nova 计算驱动配置
[root@compute ~]# vim /etc/nova/nova.conf
compute_driver=libvirt.LibvirtDriver
# 所有可用 driver：/usr/lib/python3.6/site-packages/nova/virt/

bash 复制代码

# 命令：查看 Nova 各组件分布在哪些节点、状态是否正常
[root@controller ~(keystone_admin)]# openstack compute service list

4.3 nova-scheduler 调度原理（重点）

大白话 ：调度分两步------Filter（过滤） 先刷掉不合格的节点，Weight（权重） 再给剩下的节点打分，选最优的。

复制代码

6 个计算节点 → 多个 filter 层层过滤刷掉 Host2、Host4 → 剩余 4 个计算权重 → Host5 得分最高入选

常用过滤器：

Filter	作用
RetryFilter	刷掉上一次调度失败的节点（重试次数默认 3），通常排第一个
AvailabilityZoneFilter	过滤掉不属于指定可用域 AZ 的节点
RamFilter	过滤内存不足的节点；允许超分，默认 1.5（10G 按 15G 算）
DiskFilter	过滤磁盘不足节点；默认不超分（比例 1）
CoreFilter	过滤 vCPU 不足节点；默认比例 16，默认未启用需手动加入
ComputeFilter	只有 nova-compute 服务正常的节点才能被调度，必选
ComputeCapabilitiesFilter	按计算节点特性筛选（如 x86_64/ARM），在 flavor 的 Metadata 中指定
ImagePropertiesFilter	按镜像属性筛选（如只跑在 kvm 上），在 image 的 Metadata 中指定
ServerGroupAntiAffinityFilter	反亲和：尽量把实例分散到不同节点
ServerGroupAffinityFilter	亲和：尽量把实例集中到同一节点

注意：ComputeCapabilitiesFilter 和 ImagePropertiesFilter 如果没有设置对应的 Metadata，则不起作用。

服务器组（亲和/反亲和）只能通过 CLI 指定：

bash 复制代码

# 命令：创建反亲和组（inst1/2/3 会被分散到不同计算节点）
[root@controller ~]# nova server-group-create --policy anti-affinity group-1

# 命令：创建实例并指定反亲和组
[root@controller ~]# nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst1
[root@controller ~]# nova boot --image IMAGE_ID --flavor 1 --hint group=group-1 inst2

Weight 权重：通过过滤后，Scheduler 对每个候选节点打分，默认按空闲内存量计算------空闲内存越多权重越高。

用日志观察调度过程：

bash 复制代码

# 命令：打开 debug
[root@controller ~]# vim /etc/nova/nova.conf       # 694 行打开 debug
debug=True

# 命令：重启 nova 服务
[root@controller ~]# systemctl restart openstack-nova*

# 命令：实时查看调度日志
[root@controller ~]# tail -f /var/log/nova/nova-scheduler.log

# 事后分析
cat /var/log/nova/nova-scheduler.log | grep Filter    # 看每个 filter 的过滤结果
cat /var/log/nova/nova-scheduler.log | grep weight    # 看各节点权重打分
cat /var/log/nova/nova-scheduler.log | grep Select    # 看最终选中了谁

4.4 RabbitMQ 消息队列与监控

大白话：RabbitMQ 就是组件之间的"传话筒"，所有 RPC 调用都靠它。如果队列积压了，说明有组件"堵车"了。

bash 复制代码

# 命令：确认服务正常
[root@controller ~]# systemctl status rabbitmq-server.service

# 命令：开启图形管理插件
[root@controller ~]# rabbitmq-plugins enable rabbitmq_management

# 命令：建用户
[root@controller ~]# rabbitmqctl add_user user_admin passwd_admin

# 命令：设管理员标签
[root@controller ~]# rabbitmqctl set_user_tags user_admin administrator

# 命令：授权
[root@controller ~]# rabbitmqctl set_permissions -p / user_admin ".*" ".*" ".*"
# 浏览器访问 http://<控制节点IP>:15672 登录

⚠️ 重点关注 Unacked Message（尚未处理的消息）：正常应为 0；如果非 0 且持续增长，说明队列开始积压，是严重故障信号。

4.5 创建虚拟机的完整流程

简单版（6 步）：

复制代码

1. 客户向 nova-api 发送"创建 Instance"请求
2. nova-api 处理后向 RabbitMQ 发消息给 Scheduler
3. nova-scheduler 取消息，执行调度算法选出节点 A
4. Scheduler 发消息"在节点 A 上创建"
5. 节点 A 的 nova-compute 取消息，通过本节点 Hypervisor Driver 创建实例
6. 过程中如需读写数据库，compute 通过消息队列找 nova-conductor

详细版（29 步精简脉络）：

复制代码

用户向 Keystone 拿 Token
  → nova-api 校验 Token
  → 与数据库通讯、初始化 VM 记录
  → rpc.call 请求 scheduler
  → scheduler 查库计算目标主机并回写
  → rpc.cast 通知 nova-compute
  → compute 经 conductor 取 VM 信息
  → compute 分别携带 Token 向 Glance 取镜像、Neutron 取网络、Cinder 取存储
  → 三者各自校验 Token
  → 最终调用虚拟化驱动创建虚拟机

4.6 实例生命周期操作

创建一个实例最少需要三样资源：规格 flavor + 镜像 image + 网络 network。

软重启 vs 硬重启：

操作	区别
Soft Reboot（软重启）	只重启操作系统，过程中实例仍处于运行状态，相当于在 Linux 里执行 reboot
Hard Reboot（硬重启）	相当于关机之后再重新开机

暂停 Pause vs 挂起 Suspend：

对比项	Pause（暂停）	Suspend（挂起）
状态保存位置	内存	磁盘
恢复速度	快（Unpause）	慢（Resume）
恢复后状态	Paused	Shut Down
相同点	都暂停运行并保存当前状态，之后都能恢复	同左

Shelve（搁置）：Suspend 后 Hypervisor 仍在宿主机预留资源；Shelve 会把实例作为镜像保存到 Glance，然后删除宿主机上的实例，从而彻底释放资源。

Lock（锁定）防止误删除：

管理员上锁的实例：管理员可以不解锁直接删除，普通用户不能删
默认情况下普通用户（owner）可以解锁

五、Cinder：块存储管理

5.1 Cinder 的定位

大白话：Cinder 就是云平台的"硬盘柜"------把各种存储设备（LVM、Ceph、SAN、NetApp、华为等）统一包装成"云硬盘"，用户申请一块盘，Cinder 负责找后端把它变出来。

Cinder 在虚拟机与具体存储设备之间引入了一层"逻辑存储卷"的抽象：

Cinder 本身不是存储技术，不实现对块设备的实际管理
它只提供统一的抽象接口，各存储厂商以 driver 驱动的形式接入
配置目录 /etc/cinder，日志目录 /var/log/cinder

5.2 架构组件

组件	职责
Cinder Client	封装 REST 接口，以 CLI 形式供用户使用
Cinder API	对外提供 REST API：参数校验、配额预留/提交、写数据库、把请求发往 Scheduler
Cinder Scheduler	收集各 backend 上报的容量/能力，经 Filter + Weigher 决定卷落在哪个 cinder-volume
Cinder Volume	可多节点部署，接入不同 backend，通过厂商 driver 完成实际卷操作
Cinder Backup	把卷数据备份到其他介质（Swift / Ceph / TSM）
SQL DB	存储卷、快照、备份、service 等数据

5.3 默认后端：LVM

大白话：LVM 就是 Linux 自带的"逻辑卷管理器"------物理磁盘组成卷组（VG），再从 VG 里划出逻辑卷（LV），文件系统建在 LV 上。

ini 复制代码

# answers.txt 中决定
CONFIG_CINDER_BACKEND=lvm                 # 后端类型
CONFIG_CINDER_VOLUMES_CREATE=y
CONFIG_CINDER_VOLUME_NAME=cinder-volumes  # 卷组名
CONFIG_CINDER_VOLUMES_SIZE=20G            # 卷组大小

bash 复制代码

# 命令：查看卷组容量
[root@controller ~]# vgdisplay cinder-volumes
# 所有支持的后端 driver：/usr/lib/python3.6/site-packages/cinder/volume/drivers/

5.4 Cinder Scheduler 调度

和 Nova 类似，也是 Filter 过滤 + Weigher 权重：

类型	常用策略
Filters	AvailabilityZoneFilter（可用域）、CapacityFilter（容量不足过滤）、CapabilitiesFilter（按 Volume Type 指定的能力）、AffinityFilter（SameBackend / DifferentBackend）
Weighers	CapacityWeigher、AllocatedCapacityWeigher、ChanceWeigher、GoodnessWeigher

AZ 实验要点 （/etc/cinder/cinder.conf）：

ini 复制代码

storage_availability_zone=az1          # 本节点属于 az1
default_availability_zone=nova         # 创建卷不指定 AZ 时默认用 nova

bash 复制代码

# 不指定 AZ → 默认找 nova，但节点属于 az1 → 失败
[root@controller ~(keystone_admin)]# openstack volume create --size 1 volume1
# 输出结果：Availability zone 'nova' is invalid. (HTTP 400)

# 指定 az1 → 与节点匹配 → 创建成功
[root@controller ~(keystone_admin)]# openstack volume create --size 1 --availability-zone az1 volume1

"卷类型 iscsi 为什么对应 LVM 后端？" ------ 由卷类型（Volume Type）+ 扩展规格决定，最终匹配到 cinder.conf 中后端段的配置：

ini 复制代码

[lvm]
volume_backend_name=lvm
volume_driver=cinder.volume.drivers.lvm.LVMVolumeDriver
target_ip_address=192.168.108.10
target_helper=lioadm
volume_group=cinder-volumes
volumes_dir=/var/lib/cinder/volumes

5.5 卷挂载流程（Nova × Cinder 协作）

复制代码

1. Nova 调用 Cinder API 创建卷，传递主机信息（hostname、iSCSI initiator name、FC WWPNs）
2. Cinder API 把信息传给 Cinder Volume
3. Cinder Volume 依据 host 信息找到对应 Driver
4. Driver 通知存储允许该主机访问卷，返回连接信息（iSCSI 的 iqn/portal、FC 的 Target WWPN、NFS path 等）
5. Nova 借助 brick 模块在主机上识别出磁盘/文件设备
6. Nova 通知 Cinder 已完成挂载
7. Nova 把设备信息交给 Hypervisor，最终映射进虚拟机内部

六、Swift：对象存储

6.1 定位与适用场景

大白话：Swift 就是一个"无限大的网盘"------存图片、视频、备份、归档，不管文件多大、多少，都能存进去，而且没有中心节点，坏几台机器也不影响。

Swift 不是文件系统，也不是实时数据存储系统，而是对象存储，用于永久性静态数据的长期存储。

最适合：虚拟机镜像、图片存储、邮件存储、归档备份。

6.2 Ring（环）机制

大白话：Ring 就是一张"地图"，告诉 Swift 每个数据应该放在哪块硬盘上，以及它的副本放在哪。Account、Container、Object 各有一张 Ring。

复制代码

Account Ring / Container Ring / Object Ring
  → 把虚拟节点（Partition 分区）映射到一组物理存储设备
  → 通过 Zone、Device、Partition、Replica（副本）维护映射关系

bash 复制代码

# 命令：查看账户/容器/对象信息
[root@controller ~]# swift stat

6.3 实操：双副本 Swift 存储

① 准备磁盘：控制节点新增一块 20GB 磁盘，分两个区 sdb1/sdb2，格式化为 xfs。

bash 复制代码

# 命令：卸载安装时默认的 swift 虚拟回环设备
[root@controller ~]# umount /srv/node/swiftloopback

# 命令：删除默认回环设备目录
[root@controller ~]# cd /srv/node
[root@controller node]# rm -rf swiftloopback/

# 命令：创建两个存储目录
[root@controller node]# mkdir obs1 obs2

# 命令：配置开机自动挂载
[root@controller node]# vim /etc/fstab
#/srv/loopback-device/swiftloopback  /srv/node/swiftloopback ext4 noatime,... 0 0
/dev/sdb1 /srv/node/obs1 xfs defaults 0 0
/dev/sdb2 /srv/node/obs2 xfs defaults 0 0

# 命令：挂载
[root@controller node]# mount -a

# 命令：修改属主
[root@controller node]# chown swift:swift obs1 obs2

② 创建三个 Ring（参数：分区数 2^12、副本数 2、最少 1 小时后才能再次改动 ring）：

bash 复制代码

# 命令：创建 account/container/object 三个 Ring
[root@controller ~]# cd /etc/swift/
[root@controller swift]# swift-ring-builder account.builder create 12 2 1
[root@controller swift]# swift-ring-builder container.builder create 12 2 1
[root@controller swift]# swift-ring-builder object.builder create 12 2 1

③ 建立 Ring 映射（先记下各服务端口：object 6000、container 6001、account 6002；z1/z2 代表两个 Zone）：

bash 复制代码

# 命令：account 服务映射
[root@controller swift]# swift-ring-builder account.builder add z1-192.168.108.10:6002/obs1 100
[root@controller swift]# swift-ring-builder account.builder add z2-192.168.108.10:6002/obs2 100
# container 用 6001、object 用 6000，同样各 add z1/obs1、z2/obs2

④ 再平衡（rebalance）并验证：

bash 复制代码

# 命令：rebalance 三个 Ring
[root@controller swift]# swift-ring-builder account.builder rebalance
[root@controller swift]# swift-ring-builder container.builder rebalance
[root@controller swift]# swift-ring-builder object.builder rebalance

上传一个文件后，由于设置了 2 副本，会在 obs1、obs2 目录下各存一份：

bash 复制代码

# 命令：查找上传的文件
[root@controller obs1]# find /srv/node -name *data
# 输出结果：
/srv/node/obs1/objects/317/0fe/.../xxx.data
/srv/node/obs2/objects/317/0fe/.../xxx.data

七、Heat：编排管理

7.1 Heat 是什么

大白话：Heat 就是云平台的"装修队"------你把想要的环境写成一张"装修清单"（模板），Heat 就按顺序把网络、路由、安全组、虚拟机全给你装好，不用一样一样手动创建。

Heat 通过 OpenStack 原生 REST API，使用声明式模板编排复合云应用：

模板以文本文件描述云应用的基础设施，可读可写，支持 Git 管理
模板指定资源之间的依赖关系，Heat 据此按正确顺序自动调用各服务 API 创建整套架构
Heat 位于 Nova、Neutron 等服务之上，充当对外统一接口

7.2 架构与组件

组件	职责
heat-api	提供原生 REST API，是交互入口，接收请求后转给 engine
heat-api-cfn	提供兼容 AWS CloudFormation 的 API
heat-engine	核心：任务调度、资源生命周期管理；自身不创建资源，只负责编排后交由其他组件执行

模板中可编排的资源集合：虚拟机、网络、存储、告警、浮动 IP、安全组、伸缩组、嵌套 stack 等。

7.3 HOT 模板（YAML）

大白话：HOT 模板就是一张"装修清单"，用 YAML 语法写清楚要什么资源、什么规格、什么关系。

yaml 复制代码

heat_template_version: 2018-08-31          # 模板版本
description: Simple template ...           # 描述

parameters:                                # 输入参数（镜像ID、网络ID等）
  image_name_1:
    type: string
    default: <image-id>
  public_net:
    type: string
    default: <外网ID>

resources:                                 # 资源定义（核心）
  mykey:                                   # 密钥对
    type: OS::Nova::KeyPair
  web_secgroup:                            # 安全组（放行22、icmp）
    type: OS::Neutron::SecurityGroup
  private_net / private_subnet:            # 私有网络与子网
    type: OS::Neutron::Net / OS::Neutron::Subnet
  vrouter / vrouter_interface:             # 路由器及接口
    type: OS::Neutron::Router / RouterInterface
  instance_port / floating_ip / association:  # 端口、浮动IP及绑定
    type: OS::Neutron::Port / FloatingIP / FloatingIPAssociation
  instance1:                               # 虚拟机
    type: OS::Nova::Server
    properties:
      image: { get_param: image_name_1 }
      flavor: Flavor_web
      networks:
        - port: { get_resource: instance_port }

outputs:                                    # 输出（如私钥）
  private_key:
    value: { get_attr: [ mykey, private_key ] }

模板中常用内置函数：

函数	作用
get_param	取参数
get_resource	引用同模板资源
get_attr	取资源属性

实操流程：先创建网络和镜像并记录 ID → 编写 heat.txt 模板 → Horizon「编排→堆栈→创建堆栈」选择模板文件 → Heat 自动一次性创建出网络、路由、安全组、浮动 IP 和虚拟机。

八、Neutron：网络管理（最难也最重要）

8.1 物理网络 vs 虚拟网络

物理	虚拟
Switch 物理交换机（思科、华为）	vSwitch 虚拟交换机（linuxbridge、OVS、OVN）
NIC 网卡	vNIC 虚拟网卡

Neutron 最核心的工作是对二层物理网络的抽象与管理：虚拟机的网络功能由 vNIC 和虚拟交换机提供，vNIC 连接到 vSwitch 端口，vSwitch 再通过宿主机物理网卡访问外部网络。

Linux 网络虚拟化三大块技术：

复制代码

网卡虚拟化：TAP / TUN / VETH Pair
交换机虚拟化：Linux Bridge / Open vSwitch
网络隔离：Network Namespace

8.2 网卡虚拟化：TAP / TUN / VETH

设备	工作层级	说明
TAP	二层	模拟二层网络设备，收发以太网帧
TUN	三层	模拟三层网络设备，收发 IP 包
VETH Pair	---	虚拟以太网接口，成对出现，一端发出的包从另一端接收，常用于连接不同虚拟组件

TAP/TUN 在主机内虚拟出一套与物理接口无异的网卡（可配 IP、可路由），但流量只在主机内部流通。

8.3 Linux Bridge 与 Open vSwitch

Linux Bridge：工作在二层，功能类似物理交换机。

可以把其他网络设备绑定上来，虚拟成自己的端口
br0 绑定 eth0、tap0、tap1 后，上层协议栈只看到 br0
从设备不需要 IP，只需给 br0 配 IP；eth0 绑定后原有 IP 会失效

bash 复制代码

# 命令：添加网桥
brctl addbr BRIDGE

# 命令：把设备加入网桥
brctl addif BRIDGE DEVICE

Open vSwitch（OVS）：产品级虚拟交换机。

对比项	Linux Bridge	OVS
适用场景	小规模、主机内部通信	大规模、跨主机场景
VLAN 隔离	支持	支持
端口 QoS	不支持	支持
流量监控	不支持	支持 NetFlow/sFlow
分布式虚拟交换机	不支持	支持（DVS）

bash 复制代码

# 命令：OVS 常用操作
ovs-vsctl add-br BRIDGE
ovs-vsctl add-port BRIDGE PORT
ovs-vsctl show BRIDGE
ovs-vsctl dump-ports-desc BRIDGE
ovs-vsctl dump-flows BRIDGE

8.4 Neutron 的功能（网络即服务 NaaS）

Neutron 基于 SDN（软件定义网络）实现网络虚拟化：

功能	说明
二层交换 Switching	通过 Linux Bridge / OVS 连接实例，支持 VLAN 和隧道 Overlay 网络（VxLAN、GRE）
三层路由 Routing	虚拟路由器 router 借助 IP forwarding、iptables 实现跨网段通信与 NAT
负载均衡 LBaaS	把流量分发到多个实例，默认插件是 HAProxy
防火墙	Security Group（安全组）：限制进出实例的网络包；FWaaS：限制进出虚拟路由器的网络包

8.5 三大网络资源：Network / Subnet / Port

Network（网络）：一个隔离的二层广播域，必须属于某个 Project。

类型	特点
local	与其他网络和节点隔离，实例只能与同节点同网络实例通信，用于单机测试
flat	无 VLAN Tag，可跨节点
vlan	带 802.1q Tag，不同 VLAN 需经 router 通信，应用最广泛，可跨节点
vxlan	Overlay 隧道网络，用 VNI 区分，封装成 UDP 包传输
gre	类似 vxlan，但用 IP 包封装

Subnet（子网）：一个 IPv4/IPv6 地址段，实例 IP 从中分配。

一个 Network 可含多个 Subnet，但同一 Network 内 Subnet 的 CIDR 不能重叠
不同 Network 之间 CIDR 可以重叠（router 基于 Network Namespace，有独立路由表）

Port（端口）：虚拟交换机上的端口，定义 MAC 和 IP；实例的虚拟网卡 VIF 绑定到 Port 时，Port 把 MAC/IP 分配给它。

资源关系链：

复制代码

Project 1:m Network 1:m Subnet 1:m Port 1:1 VIF m:1 Instance

8.6 Neutron 分布式架构

组件	职责
Neutron Server	对外提供网络 API，接收请求并调用 Plugin
Plugin	处理请求、维护逻辑网络状态，再调用 Agent
Agent	在 network provider 上真正实现各种网络功能
network provider	提供网络服务的虚拟/物理设备（Linux Bridge、OVS、物理交换机）
Queue	Server / Plugin / Agent 之间经消息队列通信
Database	存放 Network、Subnet、Port、Router 等网络状态（neutron 库，171 张表）

8.7 OVN 网络综合实验

本实验环境使用 OVN 作为机制驱动（OVS 的新一代控制平面），租户网络类型为 Geneve。

核心配置 /etc/neutron/plugins/ml2/ml2_conf.ini：

ini 复制代码

[ml2]
type_drivers=geneve,flat
tenant_network_types=geneve
mechanism_drivers=ovn
extension_drivers=port_security,qos

[ml2_type_geneve]
vni_ranges=10:100

[ovn]
ovn_nb_connection=tcp:192.168.108.10:6641     # 北向数据库
ovn_sb_connection=tcp:192.168.108.10:6642     # 南向数据库
ovn_metadata_enabled=True

实验步骤与 OVN 观察：

bash 复制代码

# 1. 查看 OVN 相关 agent（controller/compute 上各有 OVN Controller、Metadata agent）
[root@controller ~(keystone_admin)]# openstack network agent list

# 2. 创建外部网络 waiwang（flat）、内网 neiwang-1（192.168.11.0/24）
# 3. 创建路由器 router1 连接内外网
# 4. 创建两台实例绑定到 neiwang-1 → VM1 能 ping 通 VM2

# 全程用 ovn-nbctl show 观察逻辑网络的变化
[root@controller ~]# ovn-nbctl show
# 可看到：逻辑交换机 switch（waiwang/neiwang-1）、localport、
# 路由器 router1 的两个 router-port（内网 192.168.11.1/24、外网网关）、
# 以及 SNAT 规则：external ip 192.168.108.185 → logical ip 192.168.11.0/24

实例创建后，逻辑交换机上会出现对应端口（带 MAC 和 192.168.11.x 地址），直观展示了"Neutron 逻辑网络 → OVN 逻辑交换机/路由器"的落地过程。

九、OpenStack 七大组件速查表

组件	一句话职责	关键命令/文件	高频考点
Keystone	认证鉴权 + 服务目录	`openstack domain/user/group/role/project/service/endpoint`	Domain→Project→User→Role 关系；Token 24h；三端点；认证流程
Glance	镜像注册与存储	`glance image-create --progress`；`/etc/glance/glance-api.conf`	image/instance/flavor 关系；qcow2；状态机；后端可换 Swift
Nova	虚拟机生命周期	`openstack compute service list`；`nova-scheduler.log`	Filter+Weight 两步调度；超分比例；conductor 作用；Pause/Suspend/Shelve 区别
Cinder	块存储卷抽象	`openstack volume create`；`/etc/cinder/cinder.conf`	默认 LVM 后端；卷类型决定 backend；Nova×Cinder 挂卷流程
Swift	对象存储（无中心）	`swift-ring-builder ... create/add/rebalance`	Account/Container/Object 三 Ring；Zone/Partition/Replica
Heat	模板编排	HOT 模板（YAML）；`OS::Nova::Server` 等	heat-api / api-cfn / engine；resources 依赖顺序
Neutron	网络即服务	`ovn-nbctl show`；`ml2_conf.ini`	TAP/TUN/VETH；Bridge vs OVS；五种网络类型；Network/Subnet/Port 关系

十、实验总结

步骤	大白话操作
1. 全局理解	OpenStack = 云操作系统，组件各管一摊，靠 Token 认证 + RabbitMQ 通信
2. Keystone	建域 → 建项目 → 建用户 → 分配角色 → 验证 Token
3. Glance	上传镜像（推荐命令行带进度条）→ 确认格式 → 可选切换 Swift 后端
4. Nova	看服务列表 → 理解调度（Filter+Weight）→ 创建实例（flavor+image+network）
5. Cinder	默认 LVM 后端 → 卷类型决定 backend → 挂载到实例
6. Swift	准备磁盘 → 建三个 Ring → add 设备 → rebalance → 验证双副本
7. Heat	写 YAML 模板 → 一键创建整套环境
8. Neutron	理解 TAP/TUN/VETH → Bridge vs OVS → Network/Subnet/Port → OVN 观察

三条贯穿全局的主线：

主线	说明
认证主线	任何跨服务调用都带 Token，被调方都要回 Keystone 校验，操作权限由各服务 policy.json 决定
消息主线	组件之间高度解耦，靠 RabbitMQ（oslo.messaging）做 RPC 通信，排障要会看队列积压和各服务日志
调度主线	Nova 和 Cinder 都采用"Filter 过滤 + Weigher 权重"的调度思想，先筛掉不合格的，再选最优的