Ceph原生命令部署实战：从零构建可扩缩监控集群

简介：本资源是一份面向IT运维工程师与存储系统架构师的Ceph集群手动部署实战指南，聚焦AlmaLinux 8.9环境下使用Ceph原生命令（非Ansible/Cephadm）从零构建高可用分布式存储集群的完整流程。内容覆盖MON、MGR、OSD、MDS、RGW五大核心组件的逐节点部署、源配置优化（含AlmaLinux镜像源与Ceph RPM仓库定制）、GPG校验绕过等关键实操细节，并嵌入环境规划表、依赖安装清单、权限与目录初始化命令等可直接复用的工程化脚本片段。资源为单文件PDF文档，共1个文件，大小427KB，轻量便携，适合作为现场部署速查手册或教学参考资料。目前已有115人学习下载，特别适合希望深入理解Ceph底层机制、规避常见部署陷阱、掌握企业级存储系统自主可控部署能力的技术人员。

1. 不依赖 Ansible 或 Cephadm，用原生命令从零搭起一个可读写、能扩缩、有监控的 Ceph 集群

你手头只有几台裸机（物理机或 KVM 虚拟机），操作系统是 CentOS Stream 9 或 Ubuntu 22.04，网络已通、时间已同步、防火墙已放行，但没有现成的自动化工具——既没装 cephadm，也没配 Ansible 控制节点。此时想快速验证 Ceph 的底层行为、调试 OSD 故障、或在离线环境（如 PVE 离线安装场景）中构建最小可用集群，唯一可靠路径就是用ceph、ceph-volume、ceph-authtool、ceph-mon等原生命令逐组件初始化。这不是“玩具实验”，而是生产级集群部署的底层骨架：所有高级封装最终都调用这些命令；理解它们，才能在 cephadm 报错“failed to bootstrap mon”时，直接journalctl -u ceph-mon@mon0查日志定位到/var/lib/ceph/mon/ceph-mon0/keyring权限错误，而不是盲目重跑脚本。本文面向需要掌控部署链路每一环的 SRE、存储工程师和私有云运维人员，不讲抽象概念，只拆解ceph-mon启动失败的 3 种真实原因、ceph-volume lvm create必须传的 4 个参数、以及为什么ceph orch apply osd --all-available-devices在离线环境里根本不可用。

2. 用原生命令完成 Ceph 集群的四阶段初始化：MON、OSD、MGR、RGW

Ceph 原生命令部署不是“执行一条命令就完事”，而是严格遵循服务启动依赖顺序的四阶段手工编排：先让 Monitor 形成法定人数（quorum），再挂载 OSD 设备并注册到集群，接着启用 Manager 提供仪表盘与模块管理，最后按需添加对象网关。跳过任一阶段或颠倒顺序，都会导致ceph -s显示HEALTH_ERR或mon is not quorum。这与 cephadm 的“一键式”形成鲜明对比——后者把所有阶段打包进容器，而原生方式要求你亲手创建 keyring、分发密钥、校验 crush map、手动启动 systemd 服务。好处是全程可控：你能精确指定每个 MON 的 bind address，能强制 OSD 使用特定 LVM 逻辑卷而非自动扫描，能在 MGR 启动前关闭不必要模块（如prometheus）以降低资源占用。下面按阶段展开，每步均给出可直接粘贴执行的命令，并说明其不可替代性。

2.1 初始化 Monitor 并建立法定人数：从空目录到mon is quorum

Monitor 是 Ceph 集群的“大脑”，负责维护集群地图（monmap）、元数据和认证密钥。原生部署中，它必须第一个启动，且至少 3 个实例才能容忍单点故障（生产环境最低要求）。关键动作不是运行ceph-mon，而是先生成初始 monmap 和 admin keyring，再用ceph-mon加载它们启动服务。

首先，在第一台节点（假设主机名mon0）上创建基础目录并生成密钥：

# 创建 Ceph 数据目录（注意：路径必须与后续配置一致） sudo mkdir -p /var/lib/ceph/mon/ceph-mon0 sudo chown ceph:ceph /var/lib/ceph/mon/ceph-mon0 # 生成集群唯一 ID（UUID），用于 monmap 标识 CEPH_UUID=$(uuidgen) echo $CEPH_UUID # 记录此值，后续所有节点需一致 # 生成 admin 密钥环（含 client.admin 密钥） sudo ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring \ --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *' # 生成 monitor 密钥环（含 mon. 服务密钥） sudo ceph-authtool --create-keyring /var/lib/ceph/mon/ceph-mon0/keyring \ --gen-key -n mon. --cap mon 'allow *' # 将 admin 密钥注入 monitor 密钥环（否则 mon 启动后无法认证 client） sudo ceph-authtool /var/lib/ceph/mon/ceph-mon0/keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring # 创建初始 monmap：定义 mon0 的 IP 和端口（替换 192.168.10.10 为实际 IP） sudo ceph-mon --mkfs -i mon0 --monmap /tmp/monmap --keyring /var/lib/ceph/mon/ceph-mon0/keyring \ --mon-data /var/lib/ceph/mon/ceph-mon0 --fsid $CEPH_UUID

提示：--mkfs参数不是格式化磁盘，而是初始化 monitor 数据目录结构并写入 monmap。若报错monmap file /tmp/monmap does not exist，说明你漏了--monmap指定路径；若ceph-mon进程启动后立即退出，检查/var/lib/ceph/mon/ceph-mon0/下是否有keyring和monmap文件，权限是否为ceph:ceph。

接着启动 mon0 服务并验证：

# 启动 mon0（使用 systemd） sudo systemctl enable ceph-mon@mon0 sudo systemctl start ceph-mon@mon0 # 等待 5 秒，检查是否进入 quorum sudo ceph -s --connect-timeout 5 # 正常输出应包含：mon: 1 daemons, quorum mon0

2.2 手动准备并激活 OSD：绕过 ceph-volume 自动发现，精准控制设备绑定

OSD（Object Storage Daemon）是 Ceph 的数据存储单元。原生命令部署中，ceph-volume是核心工具，但它默认行为（如lvm batch）会自动扫描所有未使用磁盘，这在生产环境极危险。我们必须显式指定设备，并确保 LVM 卷组（VG）和逻辑卷（LV）已预先创建，避免误删数据盘。

假设你有一块空闲 SSD/dev/sdb，计划将其作为 OSD 数据盘：

# 1. 创建物理卷（PV）、卷组（VG）、逻辑卷（LV） sudo pvcreate /dev/sdb sudo vgcreate ceph-osd-vg /dev/sdb sudo lvcreate -l 100%FREE -n osd-data-lv ceph-osd-vg # 2. 使用 ceph-volume 初始化 OSD（关键参数详解）： # --data：指定 LV 路径（必须！） # --crush-device-class：设置设备类别（ssd/hdd，影响 CRUSH 规则） # --default-device-class：若未设 --crush-device-class，则用此默认值 # --no-systemd：不自动启动服务（我们稍后统一管理） sudo ceph-volume lvm create \ --data /dev/ceph-osd-vg/osd-data-lv \ --crush-device-class ssd \ --no-systemd # 3. 查看生成的 OSD ID（输出中会显示类似 "osd.0"） sudo ceph-volume lvm list # 4. 手动启动该 OSD（替换 0 为实际 ID） sudo systemctl enable ceph-osd@0 sudo systemctl start ceph-osd@0

注意：ceph-volume lvm create会自动创建/var/lib/ceph/osd/ceph-0/目录、写入ceph.conf片段、生成keyring，并调用ceph-osd --mkfs初始化文件系统。若报错Device /dev/sdb is already used by another LVM VG，说明该盘已被其他卷组占用，需先vgremove清理；若ceph-osd@0启动失败，检查/var/log/ceph/ceph-osd.0.log中是否出现failed to read superblock，这通常意味着 LV 未格式化或路径错误。

2.3 启用 Manager 并开启 Dashboard：用原生命令暴露 Web 界面

Manager（MGR）是 Ceph 的“管家”，提供指标收集、REST API 和 Dashboard。原生部署中，它不依赖 MON 启动，但必须在 OSD 上线后启用，否则 Dashboard 无法获取 PG 状态。

# 1. 创建 MGR 数据目录 sudo mkdir -p /var/lib/ceph/mgr/ceph-mgr0 sudo chown ceph:ceph /var/lib/ceph/mgr/ceph-mgr0 # 2. 生成 MGR 密钥（必须！否则 mgr 无法认证） sudo ceph-authtool --create-keyring /var/lib/ceph/mgr/ceph-mgr0/keyring \ --gen-key -n mgr.mgr0 --cap mon 'allow profile mgr' --cap osd 'allow *' --cap mds 'allow *' # 3. 将 admin 密钥注入 MGR 密钥环 sudo ceph-authtool /var/lib/ceph/mgr/ceph-mgr0/keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring # 4. 启动 MGR 服务 sudo systemctl enable ceph-mgr@mgr0 sudo systemctl start ceph-mgr@mgr0 # 5. 启用 Dashboard 模块（必须手动启用，原生方式不会自动开） sudo ceph mgr module enable dashboard # 6. 配置 Dashboard 绑定地址和端口（默认 0.0.0.0:8443，生产环境建议改 8080 且限制 IP） sudo ceph dashboard set-login-credentials admin password123 sudo ceph config set mgr mgr/dashboard/server_addr 0.0.0.0 sudo ceph config set mgr mgr/dashboard/server_port 8080 # 7. 重启 MGR 生效配置 sudo systemctl restart ceph-mgr@mgr0

验证 Dashboard 是否可用：

# 检查模块状态 sudo ceph mgr services | jq .dashboard # 应返回类似：{"dashboard": "http://192.168.10.10:8080/"} # 浏览器访问该 URL，用 admin/password123 登录

2.4 添加 RGW 对象网关：为集群提供 S3 兼容接口

RGW（RADOS Gateway）将 Ceph 转化为对象存储服务，支持 S3/Swift 协议。原生部署中，它作为独立 daemon 运行，需单独配置 Apache/Nginx 反向代理（此处以内置 Civetweb 为例，适合测试）。

# 1. 创建 RGW 数据目录 sudo mkdir -p /var/lib/ceph/radosgw/ceph-rgw.mon0 sudo chown ceph:ceph /var/lib/ceph/radosgw/ceph-rgw.mon0 # 2. 生成 RGW 密钥（必须！） sudo ceph-authtool --create-keyring /var/lib/ceph/radosgw/ceph-rgw.mon0/keyring \ --gen-key -n client.rgw.mon0 --cap mon 'allow rwx' --cap osd 'allow rwx' # 3. 注入 admin 密钥 sudo ceph-authtool /var/lib/ceph/radosgw/ceph-rgw.mon0/keyring \ --import-keyring /etc/ceph/ceph.client.admin.keyring # 4. 启动 RGW（使用 Civetweb 内置服务器，端口 8080，注意避开 Dashboard 端口） sudo systemctl enable ceph-radosgw@rgw.mon0 sudo systemctl start ceph-radosgw@rgw.mon0 # 5. 创建 S3 用户（用于测试） sudo radosgw-admin user create --uid=testuser --display-name="Test User" --email=test@example.com

验证 RGW：

# 获取用户 access_key 和 secret_key（用于 s3cmd 或 boto3） sudo radosgw-admin user info --uid=testuser | jq '.keys[0]' # 使用 curl 测试（返回 200 表示 RGW 已响应） curl -I http://192.168.10.10:8080

3. 关键配置项解析与参数调优：让原生集群稳定运行的 7 个必设项

原生命令部署完成后，ceph -s显示HEALTH_OK仅表示服务进程存活，不代表集群真正可用。大量生产问题源于默认配置未适配硬件或网络环境。以下 7 个参数必须在ceph.conf中显式设置，否则会导致 OSD 频繁 down、PG 不均衡、或 Dashboard 无法加载性能图表。

3.1osd heartbeat grace与osd heartbeat interval：解决 OSD “假死”抖动

默认心跳间隔（20 秒）和宽限期（20 秒）在高延迟网络（如跨机房）下极易触发误判。当 OSD 因瞬时 IO 峰值未及时响应心跳，MON 会将其标记为down，引发 PG remap 和客户端超时。

# 编辑 /etc/ceph/ceph.conf，在 [osd] 段添加 [osd] osd heartbeat interval = 30 osd heartbeat grace = 60

逻辑说明：interval是 OSD 主动发送心跳的周期；grace是 MON 允许丢失心跳的最大秒数。设为 30/60 后，即使网络抖动 45 秒，OSD 也不会被踢出。但切勿设得过大（如 300），否则真实故障无法及时发现。

3.2osd max backfills与osd recovery max active：控制后台恢复带宽

OSD 故障替换或扩容时，Ceph 会自动迁移 PG 数据（backfill/recovery）。默认值（max backfills = 10,recovery max active = 3）在万兆网络下严重低估带宽，导致恢复耗时数天。

# 在 [osd] 段添加（根据网络带宽调整） osd max backfills = 32 osd recovery max active = 16 osd recovery op priority = 63

参数说明：max backfills限制单个 OSD 同时处理的 backfill 请求数；recovery max active限制单个 OSD 的恢复操作并发数；op priority设置恢复操作的调度优先级（0~63，越高越优先）。对 10Gbps 网络，32/16 是安全起点；若观察到ceph -s中recovery io持续为 0，说明值设得太小。

3.3mgr modules：禁用非必要模块降低内存占用

MGR 默认启用prometheus、restful、zabbix等模块，每个模块常驻内存 100MB+。在资源受限节点（如 4GB RAM 的边缘服务器），必须精简。

# 在 [mgr] 段添加（仅保留 dashboard 和 telegraf） [mgr] mgr modules = dashboard,telegraf

验证方法：sudo ceph mgr dump | jq '.modules'应只返回["dashboard","telegraf"]。若仍看到prometheus，执行sudo ceph mgr module disable prometheus。

3.4rbd_default_features：规避 Windows 客户端兼容性问题

RBD 镜像默认启用layering、striping等高级特性，但部分旧版 Windows iSCSI Initiator 无法识别，导致rbd map失败或蓝屏。

# 在 [client] 段添加（禁用 layering，强制基础特性） [client] rbd default features = 1

数值含义：1=layering（仅启用最基础特性）；3=layering+deep-flatten；61= 全部启用。生产环境 RBD 镜像建议始终设为1，除非明确需要快照克隆。

3.5mon clock drift allowed：防止时间不同步导致 MON 脱离 quorum

MON 节点间时间差超过默认 0.05 秒（50ms）即拒绝加入 quorum。物理机 BIOS 时间漂移或 NTP 配置不当极易触发。

# 在 [mon] 段添加（放宽至 1 秒，配合 chrony 精确同步） [mon] mon clock drift allowed = 1.0

配套操作：所有节点必须运行chronyd并指向同一 NTP 源，chronyc tracking输出System clock wrong by应小于 10ms。

3.6osd crush chooseleaf type：修正 CRUSH 层级映射错误

默认chooseleaf type = 1（对应 host），但在自定义 CRUSH map 中若定义了rack或row层级，此值必须匹配，否则 PG 分布严重倾斜。

# 查看当前 CRUSH map 层级 sudo ceph osd tree | head -10 # 若输出含 "rack" 且层级编号为 3，则设： [osd] osd crush chooseleaf type = 3

验证：sudo ceph osd getcrushmap -o /tmp/crush.map && crushtool -d /tmp/crush.map -o /tmp/crush.txt查看types部分，确认目标层级编号。

3.7rgw frontends：为 RGW 配置生产级 HTTP 服务

Civetweb 仅适合测试。生产环境必须用 Nginx/Apache 反向代理，并启用 SSL。

# 在 [client.rgw] 段添加（Nginx 示例） [client.rgw] rgw frontends = "civetweb port=8000" # 实际部署时，注释掉上行，改用： # rgw frontends = "beast port=8000"

Nginx 配置片段（/etc/nginx/conf.d/ceph-rgw.conf）：

upstream rgw { server 127.0.0.1:8000; } server { listen 443 ssl; server_name rgw.example.com; ssl_certificate /etc/ssl/certs/rgw.crt; ssl_certificate_key /etc/ssl/private/rgw.key; location / { proxy_pass http://rgw; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

4. 排查原生命令部署的 5 类高频故障：从日志定位到根因修复

原生命令部署最大的优势是透明，最大挑战是故障点分散。当ceph -s显示异常时，不能只看 summary，必须按服务类型分层排查。以下是 5 类最高频问题及其精准诊断路径，每类均给出journalctl+ceph命令组合，无需猜测。

4.1 MON 无法形成 quorum：检查 monmap 一致性与网络连通性

现象：ceph -s显示mon: 3 daemons, quorum mon0,mon1,mon2但实际只有 mon0 在运行，或quorum后为空。

诊断步骤：

# 1. 在 mon0 上查看 monmap 是否包含所有节点 sudo ceph mon dump # 2. 在 mon1 上检查其 monmap 是否与 mon0 一致（输出应完全相同） sudo ceph-mon -i mon1 --print-monmap > /tmp/monmap1.bin sudo ceph-mon -i mon0 --print-monmap > /tmp/monmap0.bin diff /tmp/monmap0.bin /tmp/monmap1.bin || echo "monmap 不一致！" # 3. 检查 mon1 是否监听正确端口（默认 6789） sudo ss -tlnp | grep :6789 # 4. 从 mon0 ping mon1 的 mon 地址（非 hostname） ping -c 3 192.168.10.11 telnet 192.168.10.11 6789 # 应连接成功

根因修复：若 monmap 不一致，用ceph mon add mon1 192.168.10.11:6789在 mon0 上添加；若 telnet 失败，检查防火墙sudo ufw status或sudo iptables -L -n。

4.2 OSD 启动失败并反复重启：聚焦ceph-osd日志中的superblock错误

现象：systemctl status ceph-osd@0显示active (exited)或failed，journalctl -u ceph-osd@0出现failed to read superblock。

诊断步骤：

# 1. 确认 OSD 数据目录是否存在且权限正确 ls -ld /var/lib/ceph/osd/ceph-0/ # 应为：drwxr-xr-x 3 ceph ceph ... # 2. 检查 LV 是否被正确识别 sudo pvs; sudo vgs; sudo lvs # 确认 /dev/ceph-osd-vg/osd-data-lv 存在且状态为 "wi-a" # 3. 手动运行 OSD 初始化（模拟启动过程） sudo -u ceph ceph-osd -i 0 --mkfs --monmap /var/lib/ceph/osd/ceph-0/activate.monmap --keyring /var/lib/ceph/osd/ceph-0/keyring

根因修复：若--mkfs报错device is busy，说明 LV 被其他进程挂载，sudo umount /dev/ceph-osd-vg/osd-data-lv；若报错invalid argument，检查ceph-volume lvm list输出的data字段是否指向正确 LV 路径。

4.3 Dashboard 打不开或显示空白：验证 MGR 模块状态与证书路径

现象：浏览器访问http://ip:8080返回 502 或空白页，ceph mgr services不返回 dashboard URL。

诊断步骤：

# 1. 检查 dashboard 模块是否启用 sudo ceph mgr module ls | jq '.enabled_modules' # 2. 查看 MGR 日志中 dashboard 初始化错误 sudo journalctl -u ceph-mgr@mgr0 | grep -i dashboard # 3. 检查证书路径（Dashboard 默认使用 /var/lib/ceph/mgr/ceph-mgr0/dashboard.pem） ls -l /var/lib/ceph/mgr/ceph-mgr0/dashboard.pem # 若不存在，生成：sudo ceph dashboard create-self-signed-cert

根因修复：若模块未启用，sudo ceph mgr module enable dashboard；若证书缺失，执行create-self-signed-cert后重启ceph-mgr@mgr0。

4.4 RGW 返回 500 错误：检查 RGW 用户与 zone 配置

现象：curl http://rgw-ip:8080返回500 Internal Server Error，journalctl -u ceph-radosgw@rgw.mon0出现failed to initialize zone。

诊断步骤：

# 1. 检查 RGW 是否注册到集群 sudo ceph health detail | grep rgw # 2. 查看 RGW zone 配置 sudo radosgw-admin zone get --name default # 3. 确认 default realm 和 zone 存在 sudo radosgw-admin realm list sudo radosgw-admin zone list

根因修复：若 zone 为空，需初始化 realm/zone（radosgw-admin realm create --default等），但更常见的是 RGW 启动时未指定--realm参数，需修改/lib/systemd/system/ceph-radosgw@.service中ExecStart行，添加--realm=default --zone=default。

4.5ceph -s显示HEALTH_WARN但无具体信息：启用详细健康检查

现象：ceph -s显示HEALTH_WARN，但ceph health无输出，无法定位问题。

诊断步骤：

# 1. 启用详细健康报告 sudo ceph health detail # 2. 检查 OSD map 版本是否一致（不一致会导致 PG stale） sudo ceph osd dump | grep epoch # 3. 查看所有 OSD 状态（排除个别 down 的 OSD） sudo ceph osd stat sudo ceph osd tree

根因修复：若health detail显示too few PGs per OSD，执行sudo ceph osd pool set rbd pg_num 256（按 OSD 数量×128 计算）；若osd tree中某 OSD 为down，检查其systemctl status ceph-osd@X及日志。

5. 验证集群功能完整性的 4 个实操测试：从基础读写到多租户隔离

部署完成不等于可用。必须执行 4 类真实负载测试，覆盖 Ceph 最核心能力：块设备（RBD）、对象存储（RGW）、文件系统（CephFS）和多租户资源隔离。每个测试均给出可复现的命令序列和预期结果，避免“看起来正常”的假象。

5.1 RBD 镜像创建、映射与 I/O 压力测试：验证块存储链路

# 1. 创建 10GB RBD 镜像（启用最简特性） sudo rbd create test-img --size 10G --image-feature layering # 2. 映射为本地块设备 sudo rbd map test-img # 3. 格式化并挂载（使用 ext4，避免 xfs 的 barrier 问题） sudo mkfs.ext4 /dev/rbd0 sudo mkdir /mnt/rbd-test sudo mount /dev/rbd0 /mnt/rbd-test # 4. 写入 1GB 文件并校验 sudo dd if=/dev/zero of=/mnt/rbd-test/testfile bs=1M count=1000 oflag=direct sudo md5sum /mnt/rbd-test/testfile # 5. 卸载并取消映射 sudo umount /mnt/rbd-test sudo rbd unmap test-img

预期结果：dd命令无报错，md5sum输出唯一哈希值；sudo rbd ls应列出test-img；sudo rbd info test-img显示size: 10 GiB。

5.2 RGW S3 接口上传/下载测试：使用 aws-cli 验证对象存储

# 1. 安装 aws-cli（Ubuntu） sudo apt install awscli # 2. 配置 S3 凭据（使用之前创建的 testuser） aws configure --profile ceph-rgw # Access Key: [从 radosgw-admin user info 获取] # Secret Key: [同上] # Default region: [留空] # Default output format: json # 3. 创建存储桶并上传文件 aws --profile ceph-rgw --endpoint-url http://192.168.10.10:8080 s3 mb s3://test-bucket aws --profile ceph-rgw --endpoint-url http://192.168.10.10:8080 s3 cp /tmp/testfile s3://test-bucket/ # 4. 列出对象并下载 aws --profile ceph-rgw --endpoint-url http://192.168.10.10:8080 s3 ls s3://test-bucket/ aws --profile ceph-rgw --endpoint-url http://192.168.10.10:8080 s3 cp s3://test-bucket/testfile /tmp/downloaded

预期结果：s3 mb返回make_bucket: test-bucket；s3 cp无报错；s3 ls显示testfile；/tmp/downloaded与原文件md5sum一致。

5.3 CephFS 文件系统挂载与 POSIX 测试：验证元数据服务

# 1. 创建 CephFS（需先启用 MDS） sudo ceph fs new cephfs cephfs-metadata cephfs-data # 2. 启动 MDS（在 mon0 上） sudo systemctl enable ceph-mds@mon0 sudo systemctl start ceph-mds@mon0 # 3. 创建挂载点并挂载（使用 kernel driver） sudo mkdir /mnt/cephfs sudo mount -t ceph mon0:6789:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/ceph.client.admin.keyring # 4. 创建文件并测试硬链接（POSIX 关键特性） sudo touch /mnt/cephfs/testfile sudo ln /mnt/cephfs/testfile /mnt/cephfs/testlink sudo ls -li /mnt/cephfs/ # 两文件 inode 号应相同

预期结果：mount无报错；ceph fs status显示cephfs: up {0=up:active}；ls -li输出中testfile和testlink的第一列数字（inode）相同。

5.4 多租户资源配额测试：用 ceph-quota 限制 RBD 镜像空间

# 1. 为 testuser 创建专用 pool（避免影响 rbd pool） sudo ceph osd pool create testpool 64 # 2. 设置 pool 配额（10GB） sudo ceph osd pool set-quota testpool max_bytes 10737418240 # 3. 创建镜像到 testpool sudo rbd create testpool/test-img --size 5G # 4. 尝试创建超限镜像（应失败） sudo rbd create testpool/oversize --size 15G 2>&1 | grep "error"

预期结果：rbd create testpool/oversize返回error: error creating image: Operation not permitted；sudo ceph osd pool get-quota testpool显示max_bytes: 10737418240。

本文还有配套的精品资源，点击获取