OpenStack 1.7.2 & Ceph 9.2.1 运维命令

一、环境准备
二、实例管理
三、服务状态检查
四、计算节点维护
五、Keystone 项目管理
- 5.1 列出所有项目
- 5.2 检查用户与项目的关联
六、RAID 检查
- 6.1 软件 RAID（Linux mdadm）
- 6.2 硬件 RAID
七、Ceph 9.2.1 集群运维
八、Cinder 块存储操作
九、OSD 目录结构与故障处理
十、服务重启命令
- 10.1 OpenStack 服务重启
- 10.2 重启顺序（重要）
十一、日志目录
十二、配置文件目录结构

一、环境准备

加载认证文件。

source keystonerc_admin

二、实例管理

2.1 查看实例列表

查看实例列表（推荐）。

openstack server list

查看实例列表（传统命令）。

nova list

查看运行在特定计算节点上的实例。

nova list --host <计算节点名>

查找具有特定 IP 的实例（支持正则）。

nova list --ip

只显示处于“active”状态的实例。

nova list --status active

查看使用特定镜像创建的实例。

nova list --image <镜像ID或名称>

查看使用特定规格（flavor）的实例。

nova list --flavor <规格ID或名称>

管理员专用，查看所有租户的实例。

nova list --all-tenants

只显示指定的字段（如 name, host, status）。

nova list --fields name,host,status

查询所有项目下的实例，也可以简写为 --all。

openstack server list --all-projects

2.2 查看实例详细信息

openstack server show <实例ID或名称>
nova show <实例ID或名称>

2.3 重启实例

硬重启（Hard Reboot）：直接模拟“断电再上电”，不经过客户机关机流程。硬重启可能导致未保存的数据丢失，请谨慎使用。

openstack server reboot --hard <实例ID或名称>
nova reboot --hard <实例ID或名称>

软重启（Soft Reboot）：相当于在虚拟机内执行 reboot 命令。

openstack server reboot <实例>

2.4 实例恢复与强制操作

强制恢复实例（取消暂停）。

openstack server resume yun83

再次尝试强制重启。

openstack server reboot --hard yun83

强制重置任务状态，执行后，Nova 会强制标记该实例为 ACTIVE 且无任务挂起。

nova reset-state --active 9816a13a-1aeb-41c6-ada3-8d548732e230

查看虚拟机ID。

virsh list --all | grep 9816a13a-1aeb-41c6-ada3-8d548732e230

强制销毁虚拟机。

virsh destroy <对应的ID>

强制删除实例。

openstack server delete --force <实例ID>

三、服务状态检查

3.1 计算服务 (Nova)

检查 Nova 服务状态。

nova service-list
openstack compute service list

3.2 网络服务 (Neutron)

检查 Neutron 网络服务。

neutron agent-list
openstack network agent list

3.3 存储服务 (Cinder)

检查存储服务状态。

openstack volume service list

3.4 集群整体资源概况

查看集群整体资源概况，包括 memory_mb_used（已用内存）、vcpus_used（已用虚拟 CPU）和 running_vms（运行中实例数）。

nova hypervisor-stats

示例输出：

+----------------------+---------+
| Property             | Value   |
+----------------------+---------+
| count                | 7       |
| memory_mb_used       | 2226176 |
| vcpus_used           | 1032    |
| running_vms          | 101     |
+----------------------+---------+

四、计算节点维护

4.1 服务进程管理

登录节点检查服务进程。

systemctl status openstack-nova-compute.service
systemctl restart openstack-nova-compute.service
systemctl restart libvirtd.service

4.2 日志排查

查看日志定位崩溃原因。

tail -100f /var/log/nova/nova-compute.log

查看 nova-compute 的日志，重点看有没有 ERROR 级别的信息。

grep "ERROR" /var/log/nova/nova-compute.log | tail -50

4.3 RabbitMQ 连通性测试

测试与控制节点 RabbitMQ 的连通性。

rabbitmqctl status

五、Keystone 项目管理

5.1 列出所有项目

openstack project list

5.2 检查用户与项目的关联

openstack user list --project pubinfo
openstack user list --project services

六、RAID 检查

6.1 软件 RAID（Linux mdadm）

检查软件 RAID。

cat /proc/mdstat

如果输出显示 md 设备（如 /dev/md0），则说明配置了软件 RAID。

6.2 硬件 RAID

硬件 RAID 通常通过 RAID 卡管理，需要安装对应的工具。使用 lspci 命令检查是否有 RAID 控制器（如 LSI、HP、Dell 等）。

lspci | grep -i raid

七、Ceph 9.2.1 集群运维

7.1 基础状态检查

查看 Ceph 版本。

ceph --version

查看集群健康摘要。

ceph status

查看健康状态详细诊断信息。

ceph health detail

7.2 OSD 性能监控

ceph osd perf 用于查看集群中每一块 OSD 磁盘的底层文件系统 IO 延迟指标，用来快速定位慢盘、存储性能瓶颈，排查集群卡顿、延迟高、slow OSD 告警等问题，统计单位为毫秒 (ms)。

fs_commit_latency(ms): 文件系统提交延迟，数据从内存提交刷写到磁盘持久化的耗时，数值越高代表磁盘刷写压力越大、磁盘越慢；健康阈值建议＜10ms
fs_apply_latency(ms)：文件系统应用延迟，底层文件系统实际执行写入/修改 IO 操作的总耗时，正常会略大于提交延迟，直接反映磁盘真实读写性能

ceph osd perf

7.3 PG（归置组）管理

修复特定的 PG（将替换为实际的值，例如 1.45）。

ceph pg repair

调整 PG 数量。

ceph osd pool set  pg_num 2048

查看 PG 统计。

ceph pg stat

列出所有处于 degraded 状态的 PG（ceph degraded 表示数据副本数量不足，冗余度降低，但数据仍可读写）。

ceph pg dump_stuck degraded

持续观察 PG 状态变化，等待所有 PG 恢复为 active+clean。

watch ceph -s

7.4 OSD 管理

查看 osd.78 所在节点和物理磁盘。

ceph osd find 78

重启特定 OSD。

systemctl restart ceph-osd@10

查看 OSD 树状图。

ceph osd tree

以树状形式展示 OSD 在主机上的分布情况，同样会显示每个 OSD 的使用率。

ceph osd df tree

查看单 OSD 使用率。

ceph osd df

OSD 使用率降序排序。

ceph osd df | sort -k7 -nr

调整 OSD 的权重。

ceph osd reweight 97 0.1
ceph osd reweight 29 0.1
ceph osd reweight 97 1
ceph osd reweight 29 1

7.5 存储池配置

降低资源池的副本数：将 volumes 和 compute 池的 min_size 临时设为 1。

ceph osd pool set volumes min_size 1
ceph osd pool set compute min_size 1

设置 volumes 存储池副本总数为 2，每份对象保存 2 份数据。

ceph osd pool set volumes size 2

设置 volumes 池正常读写所需的最小在线副本数为 2。

ceph osd pool set volumes min_size 2

标准高可用配置推荐 size=3, min_size=2，坏一台主机仍能正常读写。

7.6 存储阈值设置

设置 OSD「接近满」预警阈值为 90%，当任意一块 OSD 硬盘实际占用达到 90%，OSD 状态标记为 nearfull，集群触发告警；Ceph 停止向该 OSD 分配新数据、副本、均衡迁移数据。

ceph osd set_nearfull_ratio 0.90

设置 OSD「写满阻断」临界阈值为 95%，OSD 磁盘占用突破 95%，OSD 标记为 full；彻底阻断该 OSD 上所有写入操作（RBD 云盘、对象存储、块存储均无法写数据，只读可用）；业务直接报错阻塞，必须清理数据或扩容磁盘才能恢复写入。

ceph osd set_full_ratio 0.95

分别查询两个阈值。

ceph osd get nearfull_ratio
ceph osd get full_ratio

批量查看集群所有配置过滤水位参数。

ceph config dump | grep ratio

查看集群整体存储占用。

ceph df

7.7 OSD 状态控制

关闭降级 PG 的对象恢复同步：当 OSD 离线、副本缺失时，集群不会主动同步缺失对象修复 degraded 降级 PG。

ceph osd set norecover

关闭 PG 回填迁移：新增 OSD、权重调整后，不会把 PG 迁移到空闲 OSD 均衡数据，停止 backfill 回填 IO。

ceph osd set nobackfill

屏蔽 OSD 离线检测：OSD 心跳超时失联后，集群不会将该 OSD 标记为 down，不会触发任何数据修复流程。

ceph osd set nodown

恢复上述设置。

ceph osd unset norecover
ceph osd unset nobackfill
ceph osd unset nodown

7.8 核心排错命令

ceph osd dump：输出完整 OSD Map 全量元数据，包含集群全局 OSD 参数、所有存储池配置、每个 OSD 状态、CRUSH 存储规则、快照、配额、纠删码配置等，是排查 PG 异常、存储池参数、OSD 离线、数据分布规则最核心的排错命令。

ceph osd dump

八、Cinder 块存储操作

8.1 卷管理

列出云硬盘（卷）信息，查看硬盘ID。

cinder list --all-tenants | grep -i "5454d29b\|yun233\|yun126"

8.2 卷删除（数据库层面）

在 Cinder 数据库中删除卷的记录（逻辑删除）。

UPDATE volumes
SET deleted = 1, status = 'deleted', deleted_at = NOW(), updated_at = NOW()
WHERE id = '267b3ac7-0b88-4b18-b14f-b7161b688cf8';

删除挂载关联记录。

DELETE FROM volume_attachment WHERE volume_id = '267b3ac7-0b88-4b18-b14f-b7161b688cf8';

删除卷自定义元数据。

DELETE FROM volume_metadata WHERE volume_id = '267b3ac7-0b88-4b18-b14f-b7161b688cf8';

8.3 Ceph RBD 清理

查找该卷 ID 对应的 Ceph RBD 镜像全名。

rbd ls -p volumes | grep 267b3ac7

删除 Ceph 中的实际磁盘文件：强制删除该 rbd 镜像。

rbd rm -f volumes/<上面查到的rbd名称>

查看 RBD 状态。

rbd status volumes/<刚才删除的那个rbd名称>

九、OSD 目录结构与故障处理

9.1 OSD 目录结构

/var/lib/ceph/osd 下所有 OSD 目录列表。

drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-18
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-19
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-2
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-3
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-4
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-5
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-6
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-7
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-8
drwxr-xr-x. 3 ceph 217 Feb 10 2022 ceph-9

单 OSD 目录说明：

ls /var/lib/ceph/osd/ceph-0
total 84
drwxr-xr-x.  3 ceph 217 Feb 10 2022 .
drwxr-x---. 22 ceph 4096 Apr 27 2017 ..
-rw-r--r--.  1 root  492 May 10 2017 activate.monmap       #保存 OSD 启动时加载的 Monitor 集群拓扑映射文件，root 权限由系统初始化脚本生成。
-rw-r--r--.  1 ceph    3 May 10 2017 active              #标记文件，内容为1代表 OSD 激活正常；文件丢失 / 内容 0 代表 OSD 未激活。
-rw-r--r--.  1 ceph   37 May 10 2017 ceph_fsid
drwxr-xr-x. 690 ceph 24576 Apr 30 04:12 current           #Ceph 真实业务数据全部存放在这里，包含所有 PG（归置组）、对象文件、元数据；删除 / 损坏该目录 = 永久丢失此 OSD 上所有数据。
-rw-r--r--.  1 ceph   37 May 10 2017 fsid                 #存储集群全局唯一 UUID，集群内所有 OSD、Mon、MGR 的 fsid 完全一致；用于校验 OSD 是否属于当前集群，fsid 不匹配会拒绝加入集群。
lrwxrwxrwx.  1 ceph   58 May 10 2017 journal -> /dev/disk/by-partuuid/487e576c-dbf0-44f5-8220-97c0530fa40d
-rw-r--r--.  1 ceph   37 May 10 2017 journal_uuid           #存储 journal 日志分区的唯一 UUID，用于校验日志盘和 OSD 绑定关系。
-rw-------.  1 ceph   56 May 10 2017 keyring
-rw-r--r--.  1 ceph   21 May 10 2017 magic              #存储后端魔术标识，用于区分 FileStore / Bluestore 存储引擎。
-rw-r--r--.  1 ceph    6 May 10 2017 ready              #初始化完成标记，存在该文件代表 OSD 磁盘格式化、PG 目录创建全部完成，可以正常加入集群提供存储服务。
-rw-r--r--.  1 ceph    4 May 10 2017 store_version       #存储后端版本号，用于 Ceph 程序做版本兼容校验，版本不匹配会拒绝启动 OSD。
-rw-r--r--.  1 ceph   53 May 10 2017 superblock         #OSD 超级块，存储 OSD 底层核心元数据：磁盘容量、PG 映射、存储格式、集群配置，OSD 启动第一时间读取此文件。
-rw-r--r--.  1 root    0 Feb 10 2022 systemd            #systemd 管理 OSD 服务的标记文件，用于 systemd 识别 osd 进程数据目录。
-rw-r--r--.  1 ceph    2 May 10 2017 whoami                  #文件内仅存数字 0，标记当前目录属于 osd.0，OSD 启动时读取识别自身编号。

activate.monmap：保存 OSD 启动时加载的 Monitor 集群拓扑映射文件
active：标记文件，内容为 1 代表 OSD 激活正常
current：Ceph 真实业务数据全部存放在这里，包含所有 PG（归置组）、对象文件、元数据
fsid：存储集群全局唯一 UUID
journal：软链接指向一块独立磁盘分区（高速 SSD 分区）
keyring：安全认证文件（密钥），权限为 600（仅 ceph 用户可读）
ready：初始化完成标记
superblock：OSD 超级块，存储 OSD 底层核心元数据
whoami：文件内仅存数字，标记当前目录属于哪个 OSD

9.2 SSD Journal 故障处理

核心逻辑：删除损坏 SSD 的软链接，让 FileStore 直接在现有机械数据盘内部开辟日志区域，不再依赖外置 SSD，原有业务数据完整保留。

步骤 1：清理失效 SSD 日志关联文件。

cd /var/lib/ceph/osd/ceph-0
rm -f journal journal_uuid

步骤 2：重建内联 Journal（不删除业务数据，仅重构日志元数据）。

ceph-osd -i 0 --rebuild-journal --journal-inline

步骤 3：修复目录权限（关键，否则 OSD 启动失败）。

chown -R ceph:ceph /var/lib/ceph/osd/ceph-0

步骤 4：启动 OSD 并观察集群恢复。

systemctl start ceph-osd@0
ceph -w

9.3 存储引擎检查

使用 ceph osd count-metadata 查看 Ceph 集群存储引擎（FileStore/BlueStore）。

ceph osd count-metadata osd_objectstore

十、服务重启命令

10.1 OpenStack 服务重启

systemctl restart openstack-nova-api openstack-nova-scheduler openstack-nova-conductor openstack-nova-consoleauth
systemctl restart neutron-server neutron-openvswitch-agent neutron-dhcp-agent neutron-l3-agent
systemctl restart openstack-cinder-api openstack-cinder-scheduler openstack-cinder-volume
systemctl restart openstack-glance-api openstack-glance-registry

10.2 重启顺序（重要）

由于 OpenStack 和 Ceph 是强耦合的（OpenStack 依赖 Ceph 存虚拟机，Ceph 依赖 OpenStack 宿主机存活），重启顺序至关重要，否则很容易导致重启后依然卡死或脑裂。

遵循以下“先 Ceph -> 后 OpenStack”的顺序进行操作：

在 Controller 节点执行，防止重启期间有新虚拟机创建。

nova service-disable --reason "Maintenance reboot" $(nova service-list --binary nova-compute | awk 'NR>1 {print $2 " " $3}')

在所有 Ceph 节点停止 OSD 服务：

systemctl stop ceph-osd.target

验证 OSD 是否停止：

ps aux | grep ceph-osd

十一、日志目录

11.1 系统核心日志（所有节点）

这些是操作系统和基础设施的日志，对排查硬件、内核及网络问题至关重要。

/var/log/messages 或 /var/log/syslog - 系统综合日志
/var/log/kern.log - 内核日志
/var/log/dmesg - 系统启动日志
/var/log/audit/audit.log - 安全审计日志（如果启用）
/var/log/rabbitmq/ - 消息队列日志（Controller 节点）

11.2 OpenStack 服务日志（按节点角色收集）

Controller 节点：

Nova: /var/log/nova/nova-api.log, /var/log/nova/nova-scheduler.log, /var/log/nova/nova-conductor.log
Neutron: /var/log/neutron/neutron-server.log, /var/log/neutron/neutron-dhcp-agent.log, /var/log/neutron/neutron-metadata-agent.log, /var/log/neutron/neutron-l3-agent.log
Glance: /var/log/glance/api.log, /var/log/glance/registry.log
Keystone: /var/log/keystone/keystone.log
Cinder: /var/log/cinder/cinder-api.log, /var/log/cinder/cinder-scheduler.log, /var/log/cinder/cinder-volume.log（如果也运行存储服务）
Horizon: /var/log/apache2/error.log 或 /var/log/httpd/error_log

Compute 节点：

Nova Compute: /var/log/nova/nova-compute.log - 最关键
Neutron Agent: /var/log/neutron/neutron-openvswitch-agent.log - 网络问题关键
Libvirt/QEMU: /var/log/libvirt/libvirtd.log, /var/log/libvirt/qemu/ - 具体虚拟机的日志

11.3 Ceph 集群日志（所有 Ceph 节点）

Ceph 日志按守护进程类型组织，是排查存储问题的核心。

/var/log/ceph/ceph.log - 集群综合日志（所有节点）
/var/log/ceph/ceph-mon..log - Monitor 守护进程日志
/var/log/ceph/ceph-osd..log - 例如 ceph-osd.0.log
/var/log/ceph/ceph-mgr..log - Manager 守护进程日志
/var/log/ceph/ceph-mds..log - 元数据服务器日志（如果启用）

十二、配置文件目录结构

12.1 OpenStack 配置文件

/etc/
├── nova/                    # Nova 计算服务
│   ├── nova.conf           # 主配置文件
│   ├── nova-compute.conf   # 计算节点专用配置
│   └── policy.json         # 策略文件
├── neutron/                # Neutron 网络服务
│   ├── neutron.conf       # 主配置文件
│   ├── plugins/ml2/       # ML2 插件配置
│   │   ├── ml2_conf.ini
│   │   └── openvswitch_agent.ini
│   ├── dhcp_agent.ini     # DHCP 代理配置
│   ├── metadata_agent.ini # 元数据代理配置
│   └── l3_agent.ini       # 三层路由代理配置
├── cinder/                 # Cinder 块存储服务
│   ├── cinder.conf
│   └── cinder-volume.conf
├── glance/                 # Glance 镜像服务
│   ├── glance-api.conf
│   └── glance-registry.conf
├── keystone/               # Keystone 身份服务
│   └── keystone.conf
├── horizon/                # Horizon 仪表板
│   └── local_settings
├── ceilometer/             # 监控服务（如安装）
│   └── ceilometer.conf
├── heat/                   # 编排服务（如安装）
│   └── heat.conf
└── swift/                  # 对象存储（如安装）
    └── swift.conf

12.2 配置文件查找命令

查找所有 OpenStack 相关配置文件。

find /etc -name "*.conf" | grep -E "(nova|neutron|cinder|glance|keystone)"

查找特定服务的配置文件。

find /etc -type f -name "*nova*" -o -name "*neutron*"

12.3 Ceph 配置文件

Ceph 的配置文件主要集中在 /etc/ceph/ 目录下：

ceph.conf - Ceph 集群的主配置文件
ceph.client.admin.keyring - 管理员密钥环文件
.conf - 如果有多个集群，可能会有以集群名命名的配置文件