自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(12)
  • 收藏
  • 关注

原创 Ceph 对象存储空间使用率异常排查流程

文章摘要: 排查Ceph对象存储集群使用率偏高问题时,发现实际使用率(74.6%)远超三副本理论值(58%)。经分析,根因是RGW小文件过多(平均100KB/对象)叠加HDD BlueStore的最小分配粒度(64KB),导致存储空间放大。例如,100KB对象可能占用128KB空间,三副本后放大1.28倍,计算结果与实际使用率吻合。建议优化方案:1)引入SSD缓存池(SSD最小粒度8KB),减少空间浪费;2)改用纠删码替代三副本以节省存储空间。问题本质是小对象场景下HDD分配粒度不足,而非副本异常或数据分布

2026-07-22 17:54:24 282

原创 2、千万别直接删 OSD!线上 Ceph 缩容的正确姿势,90% 的人都做错了

ceph osd crush rm HB1-TJ1-StoreC-004.hddpool — 从集群中移除节点HB1-TJ1-StoreC-004.hddpool。缩容后总容量:数据池 (480 - 6×43.6)/3 = 72.8 TiB,元数据池 (156 - 6×13.9)/4 = 18.15 TiB。缩容后使用量:数据池 54/72.8 ≈ 74%,元数据池 7.5/18.15 ≈ 42% ——原集群11 台节点,计划缩容 6 台,剩余 5 台, 5 > 4,——

2026-06-10 15:09:31 192

原创 一、Ceph 开局指导手册之服务器初始化配置篇

摘要: 本文详细记录了在三台新华三R4900 G3服务器上部署Ceph集群的环境配置与操作系统安装过程。硬件配置包括双路16核CPU、128GB内存、12块硬盘(2块系统盘RAID1、2块SSD缓存盘、6块8T HDD直通数据盘),网络采用千兆管理网和万兆存储业务网分离。重点描述了RAID卡配置步骤:将两块558GB系统盘配置为RAID1阵列,其余数据盘设为直通模式(expose RAW)以便Ceph直接管理。通过HDM远程挂载openEuler 22.03镜像,调整启动参数完成系统安装。该环境满足Ceph

2026-06-09 13:34:54 543

原创 二、Ceph 开局指导手册之存储集群配置篇(BuleStore data与db分离部署+Bcache)

Ceph 作为一款开源的分布式存储系统,以其高可靠性、高扩展性和高性能的特点,在云计算、大数据等领域得到了广泛应用。然而,Ceph 的部署与配置过程相对复杂,涉及操作系统配置、网络设置、硬件优化等多个环节,对于初学者和运维人员来说具有一定的挑战性。本文旨在提供一份详细的 Ceph 集群部署与操作指南,从最基础的环境准备开始,逐步讲解 Ceph 的安装、配置、优化及基本使用。

2026-06-06 22:25:24 318

原创 5、openEuler上Mellanox(迈洛思)网卡Bond无法聚合问题排查

最近在部署 Ceph 集群时,遇到一个比较典型但又容易误判的问题:openEuler 系统上,Intel 网卡做 Bond 正常,但 Mellanox 网卡做 Bond 后无法正常聚合,业务网和后端网都不通。最终通过升级 Mellanox 网卡固件并同步升级 OFED 驱动后,问题得到解决。这篇文章记录一下完整的排查和处理过程,供类似场景参考。bond0:管理网,100.69.124.26/24bond1:业务网,100.69.127.26/24bond2:后端网,10.87.31.26/24。

2026-05-22 19:19:42 310

原创 第四章 存储的基石—OSD

OSD(对象存储设备)是Ceph的核心组件,将物理存储设备抽象为智能存储单元,具备资源控制、自主管理和高性能服务能力。Ceph采用双网络平面设计:公共网络处理客户端请求,集群网络专用于OSD间通信,避免流量干扰。OSD故障检测通过自主上报、投票机制和看门狗三种方式实现,Monitor根据故障时长将OSD标记为Down或Out状态,触发数据恢复流程。当Primary OSD故障时,系统通过心跳检测、状态上报和OSDMap更新实现快速切换,确保服务连续性。这种设计实现了高可靠、自管理的分布式存储架构。

2026-05-08 11:50:09 564

原创 4、 一次 Ceph OSD 高时延排查复盘:BlueStore db/wal 介质选择不当引发的小 IO 时延问题

本文复盘一例 Ceph OSD 高时延问题:在集群健康、主机资源和网络正常的情况下,通过 `ceph osd perf`、`iostat`、`blktrace` 逐步定位到 BlueStore `db/wal` 直通机械盘的小块同步写确认过慢;改造成单盘 RAID0 并启用 RAID 缓存后,时延显著下降,验证了问题根因在介质与写入模型不匹配。

2026-05-07 18:02:29 476

原创 3、通过acme.sh工具自动化获取和更新免费 SSL/TLS 证书

本文介绍了使用acme.sh工具自动化获取和更新SSL/TLS证书的完整流程。首先需要在可访问公网的Linux机器上安装acme.sh,注册ZeroSSL账户并设为默认CA颁发机构。然后通过DNS TXT记录方式进行域名验证,生成TXT记录后由DNS管理员添加。验证通过后,acme.sh会自动签发证书,证书文件保存在/root/.acme.sh/目录下。最后可手动重命名证书文件,并支持证书自动更新功能。整个过程实现了SSL证书的自动化申请和更新,适用于需要定期更新证书的场景。

2026-04-13 12:33:52 520

原创 1、记录一次由硬盘坏道引起的Slow Ops告警

文章记录了3月28日一次硬盘故障的排查过程。当收到/dev/sde盘读写延迟高达4.3秒和2秒的告警后,作者首先介绍了机械硬盘的结构原理,包括盘片、磁头、扇区等关键部件及其工作机制。随后通过分析系统日志,详细还原了硬盘从SMART预警到完全失效的过程,包括读请求失败、I/O错误、设备被标记为dead device等关键时间点。最后还检查了Ceph集群日志中的OSD异常记录。整个过程展示了硬盘故障的典型表现和专业的排查方法。

2026-03-31 00:33:32 463

原创 第三章 集群的大脑 — Monitor

Ceph Monitor是Ceph集群的管理核心,负责维护集群状态信息(Cluster Map)并确保各组件间的一致性。它基于Paxos算法实现多Monitor节点间的数据同步,通过Leader选举机制,保证高可用性。Monitor包含多种类型:AuthMonitor负责认证授权、HealthMonitor监控自身状态、MDSMonitor管理元数据服务器、OSDMonitor维护OSD状态、PGMonitor处理PG统计。当主Monitor故障时,集群会触发选举流程,在半数节点存活时仍可正常运行。

2026-03-06 18:04:00 705

原创 第二章 计算寻址之美与数据平衡之殇 — CRUSH

本文系统介绍了Ceph分布式存储系统中的CRUSH算法及其核心组件。CRUSH通过智能数据分布算法解决设备增减时的数据均衡问题,支持多副本策略确保高可靠性。文章详细解析了Cluster Map的组成(MON Map、OSD Map、Crush Map、PG Map)及其协同工作机制,阐述了Gossip协议实现最终一致性的原理,并深入探讨了权重机制(weight)与抽签算法(straw2.0)如何影响数据分布。

2026-02-27 16:47:51 710

原创 第一章 一生万物 — RADOS导论

Ceph是由Sage Weil于2006年开发的分布式统一存储系统,其核心RADOS提供可靠的自洽分布式存储服务。Ceph支持块存储(RBD)、文件存储(CephFS)和对象存储(RADOSGW)三种协议,分别适用于高性能、共享访问和海量非结构化数据场景。存储池作为虚拟资源管理单元,支持副本和纠删码两种数据冗余策略,通过CRUSH算法实现数据自动分布。Ceph的模块化架构和开源特性使其成为软件定义存储领域的领先解决方案。

2026-02-27 16:13:56 943

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除