Ceph这三个字做存储的人应该都听过。网上讲概念的文章一大把但真正从零把一个集群搭起来再把块存储、对象存储、文件系统三个接口挨个跑通能一次分享清楚的真不多。我前阵子恰好在一台测试服务器上把这件事儿完整做了一遍从装系统配置节点到创建RBD块设备往上面格式化文件系统再到部署RGW对象网关传文件最后挂载CephFS共享目录折腾了大半天。这篇就是Ceph入门实验笔记的第一篇记录从搭建集群到三种存储方式基本使用的完整过程踩过的坑和排查思路都会写进去。适合刚接触Ceph、想在测试环境里动动手指搞明白“这三种存储到底怎么用”的人。搞过虚拟化或云平台的朋友应该会很有共鸣——这三种接口对应的其实就是你日常用的云硬盘、对象存储桶和共享文件目录搞懂这一套云存储的基础逻辑就通了。1. 动手之前先理清Ceph这张“分布式存储大网”1.1 Ceph到底解决了什么问题先不说具体命令得搞明白Ceph是干嘛的不然你连它为什么要分这么多组件都看不懂。传统式的存储服务器一台机器一个文件系统容量有限、单点故障多扩容的时候还得停机迁移数据。Ceph做的事情就是把一堆普通服务器上的磁盘聚合起来对外统一提供一个超大容量、能够自动容错和自愈的存储池。它底层把数据切成一个个对象分散存储在不同的机器上由一套分布式算法CRUSH决定数据落在哪、副本放在哪、故障之后怎么恢复。这套东西的好处是你给集群加机器容量和性能自动扩展不用停机数据还能自动均衡。我给它打个比方Ceph就像一个大停车场的管理系统你只管把车数据开到门口管理员会帮你找车位、给车配钥匙、车被蹭了还能给你调监控找责任方。你根本不用关心车停在哪栋楼的哪个角落也不用担心车位满了怎么办因为整个停车场可以不断扩楼层加车位。h3这种“统一存储”的设计思路决定了它天生适合干三件事提供可挂载的块设备给我们平时看到的云硬盘、提供S3风格的对象存储服务给网盘、备份、大数据、提供可共享的文件系统给多台服务器共享一个大目录。这三个需求几乎是所有业务系统的基础设施标配所以Ceph才这么受欢迎。1.2 核心组件MON、MGR、OSD、MDS各管什么Ceph不是单进程而是由多个角色协同工作。我当初刚开始学的时候盯着这些缩写简直头皮发麻但它们的分工其实很清楚。MONMonitor是整个集群的“大脑”专门负责维护集群的全局状态包括有多少OSD、哪些OSD在线、数据分布在什么位置。它不存业务数据只保存关键的集群元数据通常要部署奇数个比如3个靠选举机制避免单点故障。MGRManager是后来版本加进去的“干活的秘书”提供监控页面、查看集群性能、管理故障域和放置规则。OSDObject Storage Daemon才是真正存数据的人。每一个OSD守护一个磁盘或分区负责响应客户端的读写请求、处理数据复制恢复、参与CRUSH寻址。MDSMetadata Server不是时刻必需的只有用CephFS文件系统的时候才需要部署它负责维护文件系统的目录树、文件路径到数据池的映射关系。一句话总结MON负责“看地图”MGR负责“做报表”OSD负责“搬砖”MDS负责“管档案”。1.3 RBD、RGW、CephFS三种接口与选型接口层是Ceph最精彩的设计。它底层的数据存储模型本来就是对象存储但对外能模拟出三种风格的使用方式。RBDRADOS Block Device走的是“块设备”路线客户端向Ceph要一块裸盘格式化成ext4或xfs之后直接当硬盘用。它适合跑虚拟机虚机镜像、数据库裸设备、物理机裸盘挂载。RGWRADOS Gateway走的是“对象存储”路线对外提供S3和Swift两套HTTP接口最典型的场景就是搭建对象存储桶服务、充当备份目标、放静态文件。CephFS则走的是“分布式文件系统”路线直接把一个树状目录挂载到多个服务器上适合HPC计算集群共享文件、大数据分析平台存储。选择哪个接口本质看你业务的数据模型是什么形状的是随机读写的裸设备还是桶文件的键值对还是树状的文件层级。这篇笔记打算把三种都跑一遍你可以在自己的实验环境里感受它们的使用差异。2. 从零搭建cephadm部署一个可用集群2.1 前置条件系统、时钟、网络我实验用的是某机房闲置的测试服务器配置不算高4核CPU、8G内存、一块240G系统盘加上一块300G空白数据盘。如果你想完全复刻建议最低也要2核4G内存、一个独立的空闲磁盘否则跑起来会很难受。系统我用的CentOS Stream 9其实Ubuntu 20.04以上的版本也完全没问题现在的Ceph官方安装方式对主流发行版都支持得不错。值得提前说一句话如果你的机器有防火墙得提前把6789MON端口、3300MON v2协议端口、6800-7100OSD通信端口这些放行不然集群节点之间互相连不上。我一开始图省事儿直接关了防火墙实验机无所谓生产环境千万别学我要按规则精细化放行。时钟同步也是个关键点。Ceph内部依赖时间戳做同步和故障检测节点之间时间差超过阈值默认0.05s就直接报时钟偏移告警严重时影响写入。我实验中就直接用chrony配了个NTP源确保集群所有节点时间一致。2.2 bootstrap初始化监视器和管理器现在装Ceph已经比早些年省心太多了。早先版本的部署工具零零散散现在用的是cephadm一条命令就能把MON和MGR拉起来。从Ceph官方下载脚本curl --silent --remote-name --location https://download.ceph.com/rpm-18.2.0/el9/noarch/cephadm chmod x cephadm然后执行引导命令./cephadm bootstrap --mon-ip 192.168.1.100注意这里的IP是你服务器所在局域网的实际地址。bootstrap过程会自动安装Docker或者其他容器运行时然后把MON和MGR拉起来生成一个能用的最小集群。命令跑完之后它会输出一段访问Dashboard的地址和密码我建议你记下来后面时不时能用到。执行完可以用ceph status看看ceph -s正常情况下你会看到mon和mgr都在线但OSD还是0个因为还没有添加存储设备。2.3 添加OSD并激活存储容量集群有了“大脑”接下来要给大脑配上“手脚”——也就是OSD。添加前先看看系统认出了哪些磁盘ceph orch device ls这里会列出所有可用盘和状态。我的机器上能看到/dev/sdb那块300G数据盘。注意cephadm只会把“裸盘”或未被文件系统占用的盘作为可用盘如果盘上已经格式化过ext4/xfs会被标记为unavailable需要先清掉分区或者用zap动作覆盖。这时直接应用所有available设备ceph orch apply osd --all-available等一会儿再执行ceph -sOSD数量就变成1了。整个集群的健康状态会返回HEALTH_OK不一定如果默认副本数是3而你的OSD只有1个状态会显示HEALTH_WARN数据会处于降级状态。这个后面在踩坑部分细说。2.4 验证集群健康状态搭建完成不是终点必须验证集群状态。这里有几个命令是我每次必看的ceph -s # 总体状态里面能看到mon/mgr/osd的状态和容量 ceph osd tree # 树状显示OSD的分布位置 ceph mon stat # 看MON数量、选举状态 ceph orch ps # 看cephadm管理的守护进程是否都在运行如果你看到output里出现HEALTH_OK或者只有一两个可控的警告说明集群基础算是搭稳了。我这次看到pg数量异常是因为只有一个OSD正常集群里PG会自动在多个OSD之间布局。作为入门先容忍这个警告把接口层的功能跑通更重要。3. 块存储RBD创建池、建镜像、映射挂载3.1 创建Pool与PG数量计算Ceph中所有数据都要先装进Pool存储池。Pool设置了副本数、PG数量、CRUSH规则相当于划分出一个命名空间。创建Pool前要算PG数公式是PG总数量 ≈ (OSD数量 × 100) / 副本数比如你有3个OSD、副本数3那大约需要(3*100)/3100个PG向上取整到2的幂是128。我这台实验机只有1个OSD又不想在这时候细化太多直接用32个PG就够了反正是测试。如果后期加OSD再考虑用更合理的大PG数。创建命令ceph osd pool create mypool 32 32 rbd pool init mypool第一行是创建pool这里的32是PG数第二个32是PGP数PG如何分布在OSD上的数量通常跟PG一样。第二行是我强烈建议你执行的一步给这个pool做RBD协议的初始化。如果不做创建RBD镜像时会报错“pool not initialized for RBD”。这个坑我见过不少次了很多人卡在这。3.2 创建镜像并映射为块设备Pool建好后创建一个10G大小的RBD镜像rbd create mypool/myimage --size 10G rbd ls mypoolrbd create参数中mypool是池名myimage是镜像名中间用斜杠分隔。创建完可以rbd info mypool/myimage看看属性。接下来最关键的一步把镜像映射成内核块设备也就是让Linux把它当成一个虚拟磁盘。rbd map mypool/myimage lsblk如果这个命令报错大概率是当前客户端没有ceph访问权限。你需要一个有权限的keyring文件或者执行ceph auth get-or-create client.admin把权限配置到本机。映射成功后lsblk里会多出一个/dev/rbd0设备。如果你想卸载映射用rbd unmap mypool/myimage别直接删设备。3.3 格式化、挂载、扩展测试有块设备了后面就跟操作本地硬盘一模一样了。格式化并挂载mkfs.ext4 /dev/rbd0 mkdir -p /mnt/rbd-test mount /dev/rbd0 /mnt/rbd-test df -h | grep rbd-test一切顺利的话就能看到这个10G的块设备被挂载到了系统上。你可以往里面随便写点文件echo hello ceph rbd /mnt/rbd-test/test.txt cat /mnt/rbd-test/test.txt写的时候我一直在想这其实跟给云服务器挂云硬盘没两样——只不过这块“硬盘”背后的分布式逻辑写文件的时候数据会被切成多个对象分到不同的OSD上。再试一个扩容场景如果这个块设备空间不够了可以临时扩大镜像大小rbd resize mypool/myimage --size 20G xfs_growfs /mnt/rbd-test # 若文件系统是xfsresize成功后在线扩容文件系统业务无感知。块存储最典型的优势就在这里你想扩就扩不用关机拔硬盘。生产环境中Ceph块存储是OpenStack平台最常用的后端之一创建虚拟机云硬盘的时候走的正是RBD这条路。4. 对象存储RGWS3接口的部署与使用4.1 部署RGW实例对象存储部分要借助RGWRADOS Gateway。它本质是一个HTTP网关进程把S3风格的RESTful请求翻译成底层RADOS对象操作。Cephadm部署RGW非常简单ceph orch apply rgw demo等一小会儿再查看rgw守护进程状态ceph orch ps --daemon-type rgw ceph status默认情况下RGW会监听主机的80端口如果80被占则自动换其他高位端口对外提供S3协议访问。我这次环境80端口空闲所以最终地址是http://192.168.1.100:80。如果你的环境网络受限也可以给rgw明确指定端口段和实例名但入门阶段先跑默认的完全够用了。4.2 创建S3用户并解析访问凭据RGW本身并不管安全认证的细节它使用S3的AccessKey和SecretKey体系管理用户权限。用内置的radosgw-admin命令创建用户radosgw-admin user create --uids3user --display-nameS3 Test User执行完之后命令会返回一大段JSON里面能看到access_key和secret_key这两个字段这一段就是用于HTTP请求签名的密钥对。你可以把输出保存下来也可以用jq直接截取radosgw-admin user info --uids3user | jq .keys看到这两个字段说明对象存储的“账号”已经就绪。这个SecretKey只展示一次丢了的话需要用radosgw-admin key create重新生成。换成生活理解AccessKey就是你在云厂商控制台创建的API密钥一个用户名对应一组密钥程序调用该桶的API时自动携带用来验证“你是谁”。4.3 用s3cmd体验对象上传下载在命令行里体验S3接口最常用的工具是s3cmd。装好之后先配访问凭据s3cmd --configure它会问Access Key和Secret Key以及S3 Endpoint。我填的是http://192.168.1.100:80。有一点要注意因为我们是直接测RGW不是连云厂商所以必须把Bucket Location也指到本机同时建议选“不使用HTTPS”。s3cmd配置完成后试着创建一个桶、传一个文件、再列出来s3cmd mb s3://testbucket echo object storage test /tmp/testobj.txt s3cmd put /tmp/testobj.txt s3://testbucket/testobj.txt s3cmd ls s3://testbucket/ s3cmd get s3://testbucket/testobj.txt /tmp/testobj-download.txt能看到对象被存进去又能拉回来说明对象存储服务已经通了。RGW默认是支持路径风格的桶访问和虚拟主机风格的桶访问的。对于企业内部做私有化的对象存储服务这套方案的开源性和兼容性都占优势几乎所有S3 SDK都能直接连。兼测一下Python boto3其实更好不过这篇笔记保持命令行工具为主后面可以单独写一篇SDK接入RGW的。我实际测试时反复确认过写入的对象确实可以在网页端Dashboard的“Object Gateway”里看到。如果你对“对象存储到底是存对象还是存文件”这个概念还不清晰可以把对象存储理解为没有目录层级结构的“键值大仓库”键就是对象的Key值就是文件内容加元数据。它能承载海量小文件、支持多版本、后端自动做数据生命周期管理这些是传统文件系统很难做到的。5. 文件系统CephFS创建文件系统并挂载5.1 部署MDS和创建CephFSCephFS是三种接口里最贴近传统使用习惯的一个但也是依赖组件最多的一个。它需要一个MDS守护进程单独管理元数据。Cephadm下创建文件系统和MDS是几乎一步到位的事ceph fs volume create myfs ceph fs ls正常情况下myfs这个文件系统会被创建出来并且自动生成叫myfs.meta和myfs.data的两个数据池。CephFS的所有数据都存放在这两个池里Meta池存目录树和文件名Data池存文件内容。再确认MDS已经运行ceph orch ps --daemon-type mds如果没看到运行可以用ceph orch apply mds myfs --placement1这个--placement1限定部署1个MDS副本实验环境完全够用。5.2 内核态挂载与权限配置CephFS挂载有两种主流方式内核态挂载性能和稳定性更好用户态挂载通过ceph-fuse灵活但性能偏低。我这次先试内核态挂载mkdir -p /mnt/myfs mount -t ceph 192.168.1.100:6789:/ /mnt/myfs -o nameadmin,secret$(ceph auth get-key client.admin)这里解释一下192.168.1.100:6789是MON的IP和端口冒号后面的:/表示挂载整个根目录nameadmin指定使用哪个客户端身份访问后面的secret则是对应客户端的密钥。如果密钥不对挂载会直接拒绝。若你的内核版本较老可能还需要加上secretfile的方式用文件保存密钥再来挂载echo $(ceph auth get-key client.admin) /etc/ceph/admin.keyring mount -t ceph 192.168.1.100:6789:/ /mnt/myfs -o nameadmin,secretfile/etc/ceph/admin.keyring挂载之后你就能在一个分布式共享目录里随意创建文件了。写一个文件、两个节点同时读都能即时看到这就是分布式文件系统最直观的价值。5.3 三类存储接口的特性对比与使用建议把三种接口都跑通之后我感觉它们的关系越来越清晰了。用一张表说明存储接口使用形态适合场景使用门槛RBD块存储虚拟块设备需格式化文件系统云硬盘、数据库裸盘低挂载后像本地盘RGW对象存储HTTP RESTful 接口支持S3备份归档、静态资源、大数据中需调用SDK或工具CephFS文件系统POSIX共享目录多节点共享文件、高性能计算中内核态挂载即可一句话概括就是块存储像一块大硬盘谁挂上谁用对象存储像一个无层级大仓库按Key存取文件系统像一条大走廊走廊里的每个房间都能放东西但所有房间共享同一扇门。实际业务里经常有人问“该选哪一种”答案永远是看业务怎么存取数据以及数据形态。虚机镜像和数据库块设备优先考虑RBD海量小文件归档和S3接口生态优先考虑RGW多计算节点共享读写、要POSIX语义时选CephFS。我这次实验最大的收获就是发现这三者在同一套Ceph底层上运行得相当和谐互不干扰。6. 踩坑实录与实用建议6.1 常见问题速查表下面把我这次实验遇到的和几个身边同事常遇到的问题整理成一览表问题现场排查思路解决方法ceph -s显示HEALTH_WARN且OSD数量为0先看ceph orch device ls确认磁盘是否裸盘重置磁盘分区或用--zap强制纳入OSD创建pool后RBD时提示“not initialized”没有执行rbd pool init对目标pool执行rbd pool init mypoolrbd map报backend not found内核缺少rbd模块执行modprobe rbd或改用rbd-nbdRGW部署后访问80端口超时容器端口映射失败或RGW守护进程异常检查ceph orch ps或手动指定端口ceph orch apply rgw demo --port8080单节点部署后大量PG处于degraded状态副本数为3但OSD只有1个实验环境可临时ceph osd pool set pool size 1并调整min_size挂载CephFS时permission denied证书或密钥不对重新ceph auth get-or-create生成客户端密钥时钟不同步导致MON告警节点时间偏差大统一部署chrony配置NTP源单节点的“降级告警”是初学者最容易被吓到的地方。我一开始看到degraded还以为集群坏了其实只是一个OSD无法满足3副本的需求。实验场景建议直接调小副本数验证功能但生产环境请务必保持2副本或3副本否则数据安全没保障。我调整测试池副本数的命令是ceph osd pool set mypool size 1 ceph osd pool set mypool min_size 1这两个命令的含义是“该pool保留1份数据副本允许最少1个副本在线即可写入”实验可以生产千万别这么干。6.2 给初学者的几条实操心得从零跑通Ceph这套流程之后我有几个很实在的感悟分享给想动手的读者。第一千万别在只有1个OSD的环境里追求“生产健康”你自己心里清楚它是实验机就行。如果想要一个“看起来完全健康”的集群至少得准备3台机器或3块数据盘这样副本策略才能完整生效。学习阶段一台机器一个空盘先把接口用起来最重要。第二官方文档和cephadm已经做得非常好了遇到报错先执行ceph -s和ceph orch ps再去看日志。Ceph日志集中在/var/log/ceph/目录下按组件分开存储排查的时候看对应的ceph-mon*、ceph-osd*、ceph-rgw*日志比瞎猜快得多。第三块存储、对象存储、文件系统三个接口看起来不同但你的所有知识都可以沉淀下来。学会了RBD的池和镜像概念再去理解RGW的bucket和object会发现都是同一套底层逻辑的不同抽象。我这次笔记叫做“入门实验笔记1”就是想把这个系列持续写下去。后面计划写一写集群扩容、节点故障模拟与自动恢复、Dashboard监控这些进阶内容如果你也在学Ceph可以先把这一篇的实验步骤完完整整跑一遍趁热打铁。最后再分享一个小技巧实验环境里用cephadm shell进入容器后再执行ceph命令可以省掉很多PATH配置问题而查看Dashboard地址和密码直接翻bootstrap时输出的信息或执行ceph mgr services就能找到入口。这套实验做完之后这台测试机的Ceph我到现在还留着时不时挂载一个RBD玩玩新功能。存储这东西光看不练永远理解不了分布式的精髓动手跑一遍真的比看十篇架构解析文章都管用。