运维手册

一、基础知识

本章节主要介绍云管理员整个管理平台的时候会碰到的基础工具和基础的使用，作为全文的一个入门指导。

1.1 cephadm

cephadm：是 Ceph 官方推出的新一代轻量级、容器化集群部署与运维工具，替代了传统的 ceph-deploy、ansible-ceph 等工具，是当前 Ceph 集群部署的推荐方式。

核心特点

• 容器化部署：Ceph 的所有核心组件（Mon、Mgr、OSD、RGW 等）都运行在容器（默认 podman，也支持 docker）中，无需在宿主机安装 Ceph 包，避免系统依赖冲突。
• 无外部依赖：仅依赖容器引擎（podman/docker）和 SSH（跨节点部署），部署流程极简。
• 自动化运维：自动生成配置、部署监控（Prometheus/Grafana）、集群部署升级。
• 去中心化：无需部署管理节点，任意节点都可通过 cephadm 管理整个集群。

1.1.1 Ceph 节点主要文件目录

1.2 Ceph CLI（命令行工具）

运维过程中结合使用Ceph命令行界面（CLI）工具、Ceph Dashboard 控制面板和MStore 界面进行管理。

1.2.1 安装命令行客户端

默认云平台后台是已经安装的,或者直接进入ceph-mon容器进行操作

cephadm add-repo --release reef
yum install ceph-common
# 然后将ceph.conf 和admin的key文件拷贝到/etc/ceph目录下

1.2.2 常用命令入口

ceph

# 获取帮助：
ceph --help 可以查看帮助信息

1.3 MStore界面

作为管理用户，可以使用MStore管理集群、存储池、块存储、文件存储、对象存储。
MStore界面使用手册参考：https://cloud-help.mandao.com/docs/mos/mos-operations-operations

1.4 系统总体架构

所有组件均为容器化部署

1.5 核心组件（Ceph reef）

• Monitor（Mon）：集群 “大脑” 官方API
  维护集群的集群映射（Cluster Map）：记录所有节点、OSD、池、客户端等核心元数据，是集群的 “配置中心”；
  集群状态仲裁：通过 Paxos 算法保证多 Mon 节点的数据一致性；
  认证与授权：验证所有组件（OSD/Mgr/RGW）和客户端的身份，管理密钥环（keyring）；
  集群决策：比如 OSD 上线 / 下线、副本分布策略、故障域划分等核心决策都由 Mon 主导。

• Manager（Mgr）：集群 “管家” 官方API
  集群监控与指标收集：实时采集 OSD/Mon/RGW 等组件的性能指标（CPU、内存、IOPS、延迟等），提供给 Prometheus；
  运维接口提供：内置 Dashboard（Web 管理界面）；
  插件管理：支持各类扩展插件（如 ceph-mgr-prometheus、ceph-mgr-dashboard、ceph-mgr-volumes）；

• OSD：集群的 “数据心脏”
  数据存储与读写：接收来自 RBD/RGW/CephFS 的数据请求，将数据以 “对象” 形式存储在磁盘上；
  副本 / 纠删码管理：按照 Mon 下发的策略，维护数据的副本（默认 3 副本）或纠删码分片，保证数据高可用；
  数据修复与均衡：当 OSD 故障时，自动从副本节点恢复数据；当集群新增 OSD 时，自动均衡数据分布（Reef 优化了均衡算法，减少数据迁移对性能的影响）；
  健康自检：实时检测自身磁盘状态（坏道、IO 异常），向 Mon/Mgr 上报健康状态。

• MDS（Metadata Server）：CephFS 元数据管家 官方API
  管理 CephFS（Ceph 文件系统）的元数据：包括目录树、文件名、文件大小等（实际文件数据仍存在 OSD）；
  元数据缓存：将热点元数据缓存到内存，提升 CephFS 访问速度；
  锁管理：处理多客户端对同一文件的读写锁，保证数据一致性。

• RGW（RADOS Gateway）：对象存储网关 官方API
  提供兼容 S3/Swift 的对象存储接口：对接云原生应用、备份系统、对象存储业务；
  多租户管理：支持租户隔离、权限控制；
  数据生命周期管理：支持对象过期删除、归档存储（对接 Ceph 的分层存储）。

• RBD（RADOS Block Device）：块存储 官方API
  提供块设备接口：模拟裸磁盘，可挂载到虚拟机（KVM/VMware）、物理机；
  高级特性：支持快照、克隆、加密；
  集群化管理：RBD 卷的数据分布在多个 OSD 上，具备高可用和横向扩展能力。

• 其他辅助网关组件
  NFS Ganesha：Ceph Reef 内置 NFS 网关，将 CephFS/RBD 暴露为 NFS 协议，兼容传统 NFS 客户端；
  iSCSI Gateway：将 RBD 卷暴露为 iSCSI 协议，对接传统存储设备。

1.6 MStore 平台高可用

控制平面：3 个 Mon + 2 个 Mgr 部署在 NVMe 节点，保证仲裁与主备切换；
存储平面：存储池 3 副本，故障域按主机划分；
业务组件：MDS/RGW 多实例主备 / 多活，cephadm 容器化自愈；

1.7 MStore 界面入口

二、MStore命令行基本操作

MStore后台接入Ceph Reef,全兼容Ceph Reef版命令

2.1 集群基础管理命令

这类是日常最基础的集群状态查看、全局配置命令.

2.2 cephadm 容器化运维命令

2.3 存储池（Pool）管理命令

2.4 OSD 管理命令

2.5 控制平面（Mon/Mgr）管理命令

Mon/Mgr 是集群“大脑”，这类命令用于控制平面的高可用管理。

2.6 RBD 块存储命令

2.7 CephFS 文件系统命令

2.8 RGW 对象存储命令（

三、日常运维

3.1 集群状态查看

3.1.1 快速了解Ceph集群概况

通过如下命令，可以快速了解Ceph集群的clusterID、健康状况以及monitor、OSD、PG的map概况

ceph -s

3.1.2 检查集群健康状况

检查Ceph集群状态，进入docker的ceph mon容器执行：

ceph health

如果集群处于健康状态，会输出HEALTH_OK，如果输出HEALTH_WARN甚至HEALTH_ERR，表明Ceph处于一个不正常状态 ，可以加上”detail”选项帮助排查问题。

ceph health detail

3.1.3 实时观察Ceph集群状态变化

ceph -w

3.1.4 检查集群容量使用情况

ceph df

输出的GLOBAL段显示了数据所占用集群存储空间概况。包括：
• SIZE: 集群的总容量
• AVAIL: 集群的总空闲容量
• RAW USED: 已用存储空间总量
• %RAW USED: 已用存储空间百分比
输出的POOLS段展示了存储池列表及各存储池的大致使用率。本段没有展示副本、克隆和快照的占用情况。例如，把1MB的数据存储为对象，理论使用量将是1MB，但考虑到副本数、克隆数、和快照数，实际使用量可能是2MB或更多。
POOLS段信息说明如下：
• NAME: 存储池名
• ID: 存储池唯一标识符
• USED: 使用量，单位可为KB、MB或GB，以输出结果为准
• %USED: 存储池的使用率
• MAX AVAIL: 存储池的最大可用空间
• OBJECTS: 存储池内的object个数
注:POOLS段内的数字是理论值，它们不包含副本、快照或克隆。因此，它与USED和%USED数量之和不会达到GLOBAL段中的RAW USED和 %RAW USED数量。

3.2 PG管理操作

PG(归置组)是多个object的逻辑存储集合，每个PG会根据副本级别而被复制多份。一个POOL的PG个数可以 在创建时指定，也可以在之后进行扩大，但是需要注意的是Ceph不支持减少POOL中的PG个数。

3.2.1 计算PG数

Ceph对于集群内PG总数（默认开启pg自动调整）的计算有如下公式：
总PGs =（OSD个数*200）/ 副本数
池PGs = 总PGs * 预估池数据百分比

3.2.2 查看PG信息

若要获取集群里PG的统计信息，可以使用如下命令，并指定输出格式：
# 不指定输出格式的情况下，会输出纯文本内容，可指定格式为json
ceph pg dump [--format json]
# 若要获取状态不正常的PG的状态，可以使用如下命令:
# ceph pg dump_stuck inactive|unclean|stale|undersized|degraded [--format <format>]

3.2.3 PG状态概述

一个PG在它的生命周期的不同时刻可能会处于以下几种状态中:

• Creating(创建中)
  在创建POOL时，需要指定PG的数量，此时PG的状态便处于creating，意思是Ceph正在创建PG。
• Peering(互联中)
  peering的作用主要是在PG及其副本所在的OSD之间建立互联，并使得OSD之间就这些PG中的object及其元数据达成一致。
• Active(活跃的)
  处于该状态意味着数据已经完好的保存到了主PG及副本PG中，并且Ceph已经完成了peering工作。
• Clean(整洁的)
  当某个PG处于clean状态时，则说明对应的主OSD及副本OSD已经成功互联，并且没有偏离的PG。也意味着Ceph已经将该PG中的对象按照规定的副本数进行了复制操作。
• Degraded(降级的)
  当某个PG的副本数未达到规定个数时，该PG便处于degraded状态，例如: 在客户端向主OSD写入object的过程，object的副本是由主OSD负责向副本OSD写入的，直到副本OSD创建object副本完成，并向主OSD发出完成信息前，该PG的状态都会一直处于degraded状态。 又或者是某个OSD的状态变成了down，那么该OSD上的所有PG都会被标记为degraded。 当Ceph因为某些原因无法找到某个PG内的一个或多个object时，该PG也会被标记为degraded状态。 此时客户端不能读写找不到的对象，但是仍然能访问位于该PG内的其他object。
• Recovering(恢复中)
  当某个OSD因为某些原因down了，该OSD内PG的object会落后于它所对应的PG副本。而在该OSD重新up之后，该OSD中的内容必须更新到当前状态，处于此过程中的PG状态便是recovering。
• Backfilling(回填)
  当有新的OSD加入集群时，CRUSH会把现有集群内的部分PG分配给它。这些被重新分配到新OSD的PG状态便处于backfilling。
• Remapped(重映射)
  当负责维护某个PG的acting set变更时，PG需要从原来的acting set迁移至新的acting set。这个过程需要一段时间， 所以在此期间，相关PG的状态便会标记为remapped。
• Stale(陈旧的)
  默认情况下，OSD守护进程每半秒钟便会向Monitor报告其PG等相关状态，如果某个PG的主OSD所在acting set没能向Monitor 发送报告，或者其他的Monitor已经报告该OSD为down时，该PG便会被标记为stale。

3.3 Monitor管理操作

3.3.1 检查集群内Monitor状态

如果你有多个监视器(很可能)，你启动集群后、读写数据前应该检查监视器法定人数状态。运行着多个监视器时必须形成法定人数，最好周期性地检查监视器状态来确定它们在运行。
要查看monmap，可以执行如下命令:

ceph mon stat

通过以上信息可以了解到集群内monmap副本为3，共有3个Monitor守护进程，分别处于哪些主机(主机名、IP地址、端口号) 上，当前的Monitor选举版本为48710， Monitor集群内的法定监视器共有3个(显示的qourumID个数总和)，以及它们的MonitorID。
如果希望进一步了解monmap，可以通过如下命令查看:

ceph mon dump

通过以上信息可以额外了解到monmap创建时间及最近一次修改时间。 要获知Ceph集群内Monitor集群法定监视器的情况，可以使用如下命令查看:

ceph quorum_status

通过以上信息，可以了解到Monitor集群法定监视器的个数，以及监视器leader。

3.4 OSD管理操作

3.4.1 OSD状态概述

单个OSD有两组状态需要关注，其中一组使用in/out标记该OSD是否在集群内，另一组使用up/down标记该OSD是否处于运行中状态。 两组状态之间并不互斥，换句话说，当一个OSD处于“in”状态时，它仍然可以处于up或down的状态。

• OSD状态为in且up
  这是一个OSD正常的状态，说明该OSD处于集群内，并且运行正常。
• OSD状态为in且down
  此时该OSD尚处于集群中，但是守护进程状态已经不正常，默认在300秒后会被踢出集群，状态进而变为out且down，之后处于该OSD上的PG会迁移至其它OSD。
• OSD状态为out且up
  这种状态一般会出现在新增OSD时，意味着该OSD守护进程正常，但是尚未加入集群。
• OSD状态为out且down
  在该状态下的OSD不在集群内，并且守护进程运行不正常，CRUSH不会再分配PG到该OSD上。

  3.4.2 检查OSD状态

  在执行ceph health、ceph -s或ceph -w等命令时，也许会发现集群并未处于HEALTH状态，就OSD而言，应该关注它是否处于集群内，以及是否处于运行中状态。我们可以通过以下命令查看集群内所有OSD的状态:

  ceph osd stat

  

命令的结果显示，当前osdmap的版本号为e6716，集群内共有8个OSD，其中处于“up”状态的OSD为8个，处于“in”状态的OSD也为8个。这说明集群中OSD的状态处于正常情况。

3.4.3 查看集群OSD配置

要了解集群OSD的配置情况，可以使用下列命令进行查看。

• 查看OSD容量的使用情况

ceph osd df

从输出结果可以看到每个OSD的总容量、当前使用量以及可用容量等信息。

3.4.4 查看OSD crush 拓扑

ceph osd tree

从输出结果可以看到每个OSD的位置分布情况。默认在CRUSHMAP中，OSD按照所在的主机节点分布，可以通过修改CRUSHMAP进行定制化的分布设计。同时可以看到每个OSD的WEIGHT值。

3.4.5 查看OSD的dump概况

ceph osd dump

OSD dump输出的条目较多，基本可以分为三个部分:

• 输出OSDmap信息，包括版本号、集群ID以及map相关的时间
• POOL的相关信息，包括POOL ID、POOL名称、副本数、最小副本数、ruleset ID等信息
• 列出所有OSD的状态等信息，包括OSD ID、状态、状态版本记录以及被监听的IP地址及端口等信息。

3.5 集群计划性停机维护

3.5.1 整体停机

1. 通知客户停机操作前禁止读写

2. 检查prmetheus，尽量确保无告警

3. ceph设置标签

   docker exec -i -u root ceph_mon ceph osd set norebalance
   docker exec -i -u root ceph_mon ceph osd set nobackfill
   docker exec -i -u root ceph_mon ceph osd set noin
   docker exec -i -u root ceph_mon ceph osd set norecover
   docker exec -i -u root ceph_mon ceph osd set noout

4. 依次关闭osd节点和mon节点。

3.5.2 开机顺序

与停机步骤相反

1. 依次开启mon节点和osd节点。

2. 确认集群状态并打开维护标签

   # 存储节点开启后，在控制节点上执行以下命令查看osd数量：
   docker exec -i -u root ceph_mon ceph -s
   # 然后使用以下命令取消之前设置的标签：
   docker exec -i -u root ceph_mon ceph osd set rebalance
   docker exec -i -u root ceph_mon ceph osd set backfill
   docker exec -i -u root ceph_mon ceph osd set in
   docker exec -i -u root ceph_mon ceph osd set recover
   docker exec -i -u root ceph_mon ceph osd set out

3. 检查prometheus，无告警，有则修复