尧图网页设计 
简介一份关于CEPH块存储系统部署与应用的实战指南面向具备存储架构经验的云服务管理人员与分布式存储技术爱好者。资源为PDF格式共1个文件压缩包大小286KB已有70人学习下载。内容以Ubuntu 18.04环境为背景规划三节点Ceph集群完整演示RBD块存储的部署链路从创建存储池与块设备镜像到映射为Linux系统块设备并格式化挂载最后进行集群健康状况检查。文中附有对应操作指令示例帮助运维人员在生产环境中快速上手Ceph分布式存储作为虚拟化场景下的高效块存储方案。由于Ceph功能扩展丰富内容聚焦最基础部署读者可在此基础上根据项目规模调整参数或探索高级特性。1. Ceph块存储到底是什么先看清它和NFS、SAN的本质区别Ceph块存储RBD是你在虚拟化、数据库和容器场景里最常需要的一种分布式块存储方案。它不依赖专用硬件把一堆普通x86服务器的磁盘聚合成统一存储池对外提供和本地硬盘一样可读写、可挂载的块设备。相比NFS那种文件级共享块存储能扛得住高并发IOPS相比传统SAN它又把控制器单点和高昂的专用硬件成本去掉了。这篇指南沿着部署和应用两条线走先讲清楚架构选型和容量计算再给一条从cephadm引导到RBD映射挂载的完整命令链最后把生产环境里常见的坑逐个拆开说。2. 部署前的架构决策容量怎么算、网络怎么分、版本怎么挑Ceph部署的头号原则是「要么先把拓扑画清楚要么别开工」。我见过太多集群在扩容或故障时才发现当初的容量模型、网络带宽和PG规划全是拍脑袋定的。这一章先把部署前必须定的三个决策讲透读完你再动手后面能少走大半弯路。2.1 把三副本容量算明白OSD数、裸容量与可用容量的换算Ceph默认三副本意思是每个数据块在集群里物理存三份。很多人买硬盘时按「裸容量」算结果系统可用的容量只有裸容量的三分之一这就是最常见的第一个误判。容量计算要按实际可用的逻辑空间来看。假设你有12块4T数据盘每块盘格式化成OSD后实际可用约3.6T裸容量总计约43T。三副本下真正可用于业务的有效容量约14.3T。这还没结束OSD使用率超过70%后集群做重平衡会变得很慢故障恢复时还可能触发full状态导致写入拒绝。所以安全水位要再留一截14.3T再乘个预留系数实际建议对外承诺12T以内。带宽也是容量的一部分。三副本的写入放大是2倍每写1MB数据OSD之间要复制2MB。如果业务峰值是20Gbps的写入流量cluster网络至少得预留40Gbps的传输能力。生产环境最低配是万兆网卡我一般建议控制节点和数据节点都用25GbE起步否则磁盘再多也喂不饱。2.2 public与cluster网络规划一张网表引发的踩坑Ceph有两张逻辑网络public网络承载客户端访问、MON通信、Dashboard和RBD读写cluster网络承载OSD之间的数据复制、心跳和rebalance。这两张网必须分开而且必须是独立网段和独立VLAN。常见做法是每台物理机插两块网卡各接一个交换机。一块划给业务VLAN跑public网络另一块跑cluster网络不响应外部路由。集群内部流量再大也不会挤占客户端的业务带宽。网络角色网段示例承载流量推荐带宽public网络192.168.20.0/24客户端RBD读写、MON心跳、Dashboard25GbEcluster网络192.168.30.0/24OSD间复制、rebalance、心跳25GbE防火墙只需要放行几个端口MON的6789OSD和Manager的6800到7300区间。Ceph的集群端口范围较宽别用那种只开单个端口的策略否则OSD起来一个报错一个。2.3 版本与OS选型Quincy还是Reef内核版本为何关键Ceph的版本节奏是两年一个大版本命名按字母序。当前主流部署集中在Quincy17和Reef18更老的Octopus15和Pacific16对很多新特性支持不全新集群不建议再选。版本系列关键变化适合场景Octopus15cephadm趋于成熟老集群遗留Pacific16默认pg_autoscale兼容性过渡Quincy17稳定性打磨RBD性能提升大多数生产新集群Reef18新特性更多要求较新内核愿意吃螃蟹的场景选OSD节点操作系统时除了Ceph服务本身还要关心Linux内核版本。内核自带的RBD驱动krbd对RBD镜像特性的支持有版本门槛比如object-map和fast-diff特性在老内核上可能导致映射失败。Ubuntu 22.04 LTS搭配5.15内核是我比较常用的组合跟Quincy配合得很稳。选型上别追最新版本Ceph这种底层存储稳定性永远优先于新功能。3. 用cephadm部署生产级集群从bootstrap到RBD可用的完整命令链这一章我们把部署真正跑起来。我以Ubuntu 22.04、Ceph Quincy为例给的是可以直接照抄的最小步骤。三台节点node01做引导节点node02和node03加入集群每台机器一块系统盘加几块数据盘。3.1 安装cephadm并引导首个MON节点两个关键参数别写错先在node01上安装cephadmUbuntu的官方软件源里已经带了这个包。# node01上执行 apt update apt install -y cephadm # 检查版本 cephadm version # 设置hostname并绑定管理IP hostnamectl set-hostname node01 # 确认 /etc/hosts 里有本机IP到hostname的解析 cat /etc/hosts装好后执行bootstrap这条命令会把MON和Manager部署到当前节点同时生成集群配置和初始管理员keyring。cephadm bootstrap --mon-ip 192.168.20.11 \ --cluster-network 192.168.30.0/24 \ --allow-fqdn-hostnamebootstrap结束后终端会打印Dashboard的访问地址、用户名和初始密码同时生成/etc/ceph/ceph.conf和/etc/ceph/ceph.client.admin.keyring这两份文件是所有管理命令的凭据基础。参数说明--mon-ip填的是public网络的本机IP如果填错或该IP在/etc/hosts里没有对应解析MON进程会起不来。--cluster-network传的是cluster网络的网段注意这里写CIDR格式并且要保证所有节点的cluster网络都在这个网段内。--allow-fqdn-hostname是给带域名后缀的主机名用的如果hostname里没有小数点写不写都行但加上更稳妥。3.2 添加OSD节点先用SSH打通再用orchestrator批量上盘Ceph的编排器通过SSH管理所有节点。引导节点已经生成了SSH密钥把它分发到node02和node03上然后告诉编排器把这两台机器加进集群。# 在node01上执行 ceph cephadm get-ssh-config ~/ceph_ssh_config ssh-copy-id -f -i ~/.ssh/id_rsa.pub root192.168.20.12 ssh-copy-id -f -i ~/.ssh/id_rsa.pub root192.168.20.13 # 添加主机 ceph orch host add node02 192.168.20.12 ceph orch host add node03 192.168.20.13 # 查看主机状态 ceph orch host ls主机加进来后OSD还没创建。先用ceph orch device ls看看每台机器的磁盘是否被正确识别再执行自动部署。# 查看所有可用磁盘 ceph orch device ls # 把每台机器上的可用磁盘都创建为OSD ceph orch apply osd --all-available-devices # 确认OSD状态 ceph osd tree ceph -s这里容易出问题的地方在于系统盘也会被--all-available-devices识别为可用设备如果你不想让编排器把系统盘也做成OSD需要在ceph orch device ls的结果里确认设备路径然后用device filter排除掉。更稳妥的做法是给每台机器单独指定数据盘路径例如ceph orch daemon add osd node02:/dev/sdb:/dev/sdc但路径多时容易写错我一般会把系统盘单独挂一个raid卡或者用device filter的--filter参数限制。3.3 创建块存储池与RBD镜像pool、pg_num和认证的完整线索OSD就绪后下一步是创建用于块存储的pool和RBD镜像。pool的PG数量决定了数据分布的粒度设置太大会导致OSD压力过大太小又会造成单个PG内数据过多、重平衡不均匀。# 创建poolPG数为128 ceph osd pool create># 加载内核模块 modprobe rbd # 映射镜像指定用户和keyring rbd map>import rados import rbd # 连接集群 cluster rados.Rados(conffile/etc/ceph/ceph.conf, conf{keyring: /etc/ceph/ceph.client.rbduser.keyring}) cluster.connect() # 打开pool和镜像 ioctx cluster.open_ioctx(data-pool) rbd_inst rbd.RBD() image rbd.Image(ioctx, vmdisk1) # 写入4KB数据 data bblock-data * 512 image.write(data, 0) # 读取并校验 read_data image.read(0, len(data)) print(read_data data) # 关闭连接 image.close() ioctx.close() cluster.shutdown()这段代码展示了librbd的最小工作流连接集群、打开ioctx、打开镜像、读写数据。和内核RBD的区别在于应用直接持有镜像句柄数据不经过虚拟块设备省去一层内核上下文切换。生产环境里OpenStack的Cinder驱动、一些分布式数据库的备份组件都是走这条路径。librbd的参数有个关键点conffile里的client配置会被conf字段里的keyring覆盖所以权限控制完全取决于你传入的keyring路径。多线程场景下要注意每个线程最好打开独立的Rados连接共用连接会引入锁竞争延迟反而上升。4.3 对接QEMU/KVM把RBD镜像做成虚拟机系统盘超融合架构里虚拟机磁盘直接落在Ceph RBD上是主流做法。QEMU原生支持RBD协议虚拟机不开机时就是一个rbd镜像开机后由qemu进程直接读写不需要客户端先map再挂载。# 用qemu-img在RBD上创建虚拟磁盘 qemu-img create -f rbd \ rbd:data-pool/vmdisk2:conf/etc/ceph/ceph.conf:idrbduser:keyring/etc/ceph/ceph.client.rbduser.keyring \ 100Glibvirt的虚拟机XML里磁盘配置这样写disk typenetwork devicedisk driver nameqemu typeraw cachenone/ source protocolrbd namedata-pool/vmdisk2 host name192.168.20.11 port6789/ auth usernamerbduser secret typeceph usageclient.rbduser/ /auth /source target devvda busvirtio/ /disklibvirt需要提前定义一个含有Ceph keyring内容的secretXML中通过usage关联。常见做法是把keyring里的密钥复制到secret的定义里而不是让/etc/ceph对所有虚拟机开放权限。QEMU接入时cachenone是推荐的缓存策略配合RBD自身的写缓存可以避免虚拟机层和存储层的双重缓存导致一致性风险。QEMU的RBD驱动还支持rbd_cachetrue这个参数适合读密集的虚拟机场景但要在QEMU命令行里显式开启libvirt的写法中需要通过driver的子元素落实。实际调优时我一般先用cachenone跑基线再根据io延迟决定要不要开RBD缓存。5. 避坑手册部署Ceph块存储最常见的6个翻车现场Ceph最难的不是装起来而是装完后不出幺蛾子。下面这6个坑是我在部署和运维里反复见过的每条都按现象、原因、解决三步说清楚你照着对照检查就行。5.1 时钟不同步导致MON认证反复失败现象ceph -s里MON显示clock skew detected有时直接报authunable to authenticate客户端连接时好时坏。原因Ceph的MON节点之间通过时间戳做消息排序和认证节点间时间差超过0.05秒就开始告警超过0.2秒直接导致选举异常。我见过不少集群建完后忽略时间同步结果一跑起来就各种玄学故障。解决在所有节点上装chrony并配置统一的时间源。apt install -y chrony # 编辑 /etc/chrony/chrony.conf指定内网NTP服务器 systemctl restart chrony chronyc sources -v5.2 PG数量设置不合理引发的重平衡风暴现象新集群刚启动时一切正常跑了两三天后部分OSD使用率高出平均20%以上写入延迟骤增。原因pool创建时PG数设得太小比如6个OSD却只设8个PG导致数据分布粒度太粗热点集中在少数OSD上。解决参照(OSD总数 × 100) / 副本数估算PG数并确保取整到2的幂。如果已经建好的pool要调用下面命令动态调整但调整过程会触发数据重平衡业务低谷期做。ceph osd pool set>ceph config set osd osd_memory_target 4294967296这样单个OSD的进程内存会被控制在大约4G防止吃光宿主机内存。注意这个配置是对所有OSD生效设太小会让性能打折别盲目压。5.4 内核RBD特性不兼容map时报Operation not permitted现象rbd map>rbd feature disable>ceph osd set nearfull ratio 0.75 ceph osd set full ratio 0.92这个配置相当于把安全线提前给运维留出反应时间。数据清理方面RBD删镜像后空间不会立刻还给OSD可以手动回收rbd trash purge>rbd bench-write style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" /> 详解Ceph块存储：从cephadm集群部署到RBD挂载与生产避坑
简介一份关于CEPH块存储系统部署与应用的实战指南面向具备存储架构经验的云服务管理人员与分布式存储技术爱好者。资源为PDF格式共1个文件压缩包大小286KB已有70人学习下载。内容以Ubuntu 18.04环境为背景规划三节点Ceph集群完整演示RBD块存储的部署链路从创建存储池与块设备镜像到映射为Linux系统块设备并格式化挂载最后进行集群健康状况检查。文中附有对应操作指令示例帮助运维人员在生产环境中快速上手Ceph分布式存储作为虚拟化场景下的高效块存储方案。由于Ceph功能扩展丰富内容聚焦最基础部署读者可在此基础上根据项目规模调整参数或探索高级特性。1. Ceph块存储到底是什么先看清它和NFS、SAN的本质区别Ceph块存储RBD是你在虚拟化、数据库和容器场景里最常需要的一种分布式块存储方案。它不依赖专用硬件把一堆普通x86服务器的磁盘聚合成统一存储池对外提供和本地硬盘一样可读写、可挂载的块设备。相比NFS那种文件级共享块存储能扛得住高并发IOPS相比传统SAN它又把控制器单点和高昂的专用硬件成本去掉了。这篇指南沿着部署和应用两条线走先讲清楚架构选型和容量计算再给一条从cephadm引导到RBD映射挂载的完整命令链最后把生产环境里常见的坑逐个拆开说。2. 部署前的架构决策容量怎么算、网络怎么分、版本怎么挑Ceph部署的头号原则是「要么先把拓扑画清楚要么别开工」。我见过太多集群在扩容或故障时才发现当初的容量模型、网络带宽和PG规划全是拍脑袋定的。这一章先把部署前必须定的三个决策讲透读完你再动手后面能少走大半弯路。2.1 把三副本容量算明白OSD数、裸容量与可用容量的换算Ceph默认三副本意思是每个数据块在集群里物理存三份。很多人买硬盘时按「裸容量」算结果系统可用的容量只有裸容量的三分之一这就是最常见的第一个误判。容量计算要按实际可用的逻辑空间来看。假设你有12块4T数据盘每块盘格式化成OSD后实际可用约3.6T裸容量总计约43T。三副本下真正可用于业务的有效容量约14.3T。这还没结束OSD使用率超过70%后集群做重平衡会变得很慢故障恢复时还可能触发full状态导致写入拒绝。所以安全水位要再留一截14.3T再乘个预留系数实际建议对外承诺12T以内。带宽也是容量的一部分。三副本的写入放大是2倍每写1MB数据OSD之间要复制2MB。如果业务峰值是20Gbps的写入流量cluster网络至少得预留40Gbps的传输能力。生产环境最低配是万兆网卡我一般建议控制节点和数据节点都用25GbE起步否则磁盘再多也喂不饱。2.2 public与cluster网络规划一张网表引发的踩坑Ceph有两张逻辑网络public网络承载客户端访问、MON通信、Dashboard和RBD读写cluster网络承载OSD之间的数据复制、心跳和rebalance。这两张网必须分开而且必须是独立网段和独立VLAN。常见做法是每台物理机插两块网卡各接一个交换机。一块划给业务VLAN跑public网络另一块跑cluster网络不响应外部路由。集群内部流量再大也不会挤占客户端的业务带宽。网络角色网段示例承载流量推荐带宽public网络192.168.20.0/24客户端RBD读写、MON心跳、Dashboard25GbEcluster网络192.168.30.0/24OSD间复制、rebalance、心跳25GbE防火墙只需要放行几个端口MON的6789OSD和Manager的6800到7300区间。Ceph的集群端口范围较宽别用那种只开单个端口的策略否则OSD起来一个报错一个。2.3 版本与OS选型Quincy还是Reef内核版本为何关键Ceph的版本节奏是两年一个大版本命名按字母序。当前主流部署集中在Quincy17和Reef18更老的Octopus15和Pacific16对很多新特性支持不全新集群不建议再选。版本系列关键变化适合场景Octopus15cephadm趋于成熟老集群遗留Pacific16默认pg_autoscale兼容性过渡Quincy17稳定性打磨RBD性能提升大多数生产新集群Reef18新特性更多要求较新内核愿意吃螃蟹的场景选OSD节点操作系统时除了Ceph服务本身还要关心Linux内核版本。内核自带的RBD驱动krbd对RBD镜像特性的支持有版本门槛比如object-map和fast-diff特性在老内核上可能导致映射失败。Ubuntu 22.04 LTS搭配5.15内核是我比较常用的组合跟Quincy配合得很稳。选型上别追最新版本Ceph这种底层存储稳定性永远优先于新功能。3. 用cephadm部署生产级集群从bootstrap到RBD可用的完整命令链这一章我们把部署真正跑起来。我以Ubuntu 22.04、Ceph Quincy为例给的是可以直接照抄的最小步骤。三台节点node01做引导节点node02和node03加入集群每台机器一块系统盘加几块数据盘。3.1 安装cephadm并引导首个MON节点两个关键参数别写错先在node01上安装cephadmUbuntu的官方软件源里已经带了这个包。# node01上执行 apt update apt install -y cephadm # 检查版本 cephadm version # 设置hostname并绑定管理IP hostnamectl set-hostname node01 # 确认 /etc/hosts 里有本机IP到hostname的解析 cat /etc/hosts装好后执行bootstrap这条命令会把MON和Manager部署到当前节点同时生成集群配置和初始管理员keyring。cephadm bootstrap --mon-ip 192.168.20.11 \ --cluster-network 192.168.30.0/24 \ --allow-fqdn-hostnamebootstrap结束后终端会打印Dashboard的访问地址、用户名和初始密码同时生成/etc/ceph/ceph.conf和/etc/ceph/ceph.client.admin.keyring这两份文件是所有管理命令的凭据基础。参数说明--mon-ip填的是public网络的本机IP如果填错或该IP在/etc/hosts里没有对应解析MON进程会起不来。--cluster-network传的是cluster网络的网段注意这里写CIDR格式并且要保证所有节点的cluster网络都在这个网段内。--allow-fqdn-hostname是给带域名后缀的主机名用的如果hostname里没有小数点写不写都行但加上更稳妥。3.2 添加OSD节点先用SSH打通再用orchestrator批量上盘Ceph的编排器通过SSH管理所有节点。引导节点已经生成了SSH密钥把它分发到node02和node03上然后告诉编排器把这两台机器加进集群。# 在node01上执行 ceph cephadm get-ssh-config ~/ceph_ssh_config ssh-copy-id -f -i ~/.ssh/id_rsa.pub root192.168.20.12 ssh-copy-id -f -i ~/.ssh/id_rsa.pub root192.168.20.13 # 添加主机 ceph orch host add node02 192.168.20.12 ceph orch host add node03 192.168.20.13 # 查看主机状态 ceph orch host ls主机加进来后OSD还没创建。先用ceph orch device ls看看每台机器的磁盘是否被正确识别再执行自动部署。# 查看所有可用磁盘 ceph orch device ls # 把每台机器上的可用磁盘都创建为OSD ceph orch apply osd --all-available-devices # 确认OSD状态 ceph osd tree ceph -s这里容易出问题的地方在于系统盘也会被--all-available-devices识别为可用设备如果你不想让编排器把系统盘也做成OSD需要在ceph orch device ls的结果里确认设备路径然后用device filter排除掉。更稳妥的做法是给每台机器单独指定数据盘路径例如ceph orch daemon add osd node02:/dev/sdb:/dev/sdc但路径多时容易写错我一般会把系统盘单独挂一个raid卡或者用device filter的--filter参数限制。3.3 创建块存储池与RBD镜像pool、pg_num和认证的完整线索OSD就绪后下一步是创建用于块存储的pool和RBD镜像。pool的PG数量决定了数据分布的粒度设置太大会导致OSD压力过大太小又会造成单个PG内数据过多、重平衡不均匀。# 创建poolPG数为128 ceph osd pool create># 加载内核模块 modprobe rbd # 映射镜像指定用户和keyring rbd map>import rados import rbd # 连接集群 cluster rados.Rados(conffile/etc/ceph/ceph.conf, conf{keyring: /etc/ceph/ceph.client.rbduser.keyring}) cluster.connect() # 打开pool和镜像 ioctx cluster.open_ioctx(data-pool) rbd_inst rbd.RBD() image rbd.Image(ioctx, vmdisk1) # 写入4KB数据 data bblock-data * 512 image.write(data, 0) # 读取并校验 read_data image.read(0, len(data)) print(read_data data) # 关闭连接 image.close() ioctx.close() cluster.shutdown()这段代码展示了librbd的最小工作流连接集群、打开ioctx、打开镜像、读写数据。和内核RBD的区别在于应用直接持有镜像句柄数据不经过虚拟块设备省去一层内核上下文切换。生产环境里OpenStack的Cinder驱动、一些分布式数据库的备份组件都是走这条路径。librbd的参数有个关键点conffile里的client配置会被conf字段里的keyring覆盖所以权限控制完全取决于你传入的keyring路径。多线程场景下要注意每个线程最好打开独立的Rados连接共用连接会引入锁竞争延迟反而上升。4.3 对接QEMU/KVM把RBD镜像做成虚拟机系统盘超融合架构里虚拟机磁盘直接落在Ceph RBD上是主流做法。QEMU原生支持RBD协议虚拟机不开机时就是一个rbd镜像开机后由qemu进程直接读写不需要客户端先map再挂载。# 用qemu-img在RBD上创建虚拟磁盘 qemu-img create -f rbd \ rbd:data-pool/vmdisk2:conf/etc/ceph/ceph.conf:idrbduser:keyring/etc/ceph/ceph.client.rbduser.keyring \ 100Glibvirt的虚拟机XML里磁盘配置这样写disk typenetwork devicedisk driver nameqemu typeraw cachenone/ source protocolrbd namedata-pool/vmdisk2 host name192.168.20.11 port6789/ auth usernamerbduser secret typeceph usageclient.rbduser/ /auth /source target devvda busvirtio/ /disklibvirt需要提前定义一个含有Ceph keyring内容的secretXML中通过usage关联。常见做法是把keyring里的密钥复制到secret的定义里而不是让/etc/ceph对所有虚拟机开放权限。QEMU接入时cachenone是推荐的缓存策略配合RBD自身的写缓存可以避免虚拟机层和存储层的双重缓存导致一致性风险。QEMU的RBD驱动还支持rbd_cachetrue这个参数适合读密集的虚拟机场景但要在QEMU命令行里显式开启libvirt的写法中需要通过driver的子元素落实。实际调优时我一般先用cachenone跑基线再根据io延迟决定要不要开RBD缓存。5. 避坑手册部署Ceph块存储最常见的6个翻车现场Ceph最难的不是装起来而是装完后不出幺蛾子。下面这6个坑是我在部署和运维里反复见过的每条都按现象、原因、解决三步说清楚你照着对照检查就行。5.1 时钟不同步导致MON认证反复失败现象ceph -s里MON显示clock skew detected有时直接报authunable to authenticate客户端连接时好时坏。原因Ceph的MON节点之间通过时间戳做消息排序和认证节点间时间差超过0.05秒就开始告警超过0.2秒直接导致选举异常。我见过不少集群建完后忽略时间同步结果一跑起来就各种玄学故障。解决在所有节点上装chrony并配置统一的时间源。apt install -y chrony # 编辑 /etc/chrony/chrony.conf指定内网NTP服务器 systemctl restart chrony chronyc sources -v5.2 PG数量设置不合理引发的重平衡风暴现象新集群刚启动时一切正常跑了两三天后部分OSD使用率高出平均20%以上写入延迟骤增。原因pool创建时PG数设得太小比如6个OSD却只设8个PG导致数据分布粒度太粗热点集中在少数OSD上。解决参照(OSD总数 × 100) / 副本数估算PG数并确保取整到2的幂。如果已经建好的pool要调用下面命令动态调整但调整过程会触发数据重平衡业务低谷期做。ceph osd pool set>ceph config set osd osd_memory_target 4294967296这样单个OSD的进程内存会被控制在大约4G防止吃光宿主机内存。注意这个配置是对所有OSD生效设太小会让性能打折别盲目压。5.4 内核RBD特性不兼容map时报Operation not permitted现象rbd map>rbd feature disable>ceph osd set nearfull ratio 0.75 ceph osd set full ratio 0.92这个配置相当于把安全线提前给运维留出反应时间。数据清理方面RBD删镜像后空间不会立刻还给OSD可以手动回收rbd trash purge>rbd bench-write style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;" />