前阵子帮客户搭一套私有化部署环境机房跟互联网之间是物理隔离的偏偏业务层需要一套Ceph做存储底座。当时团队里几个人第一反应都是“先配个yum源”结果发现根本连不上公网。后来折腾了两天把RPM本地源和容器镜像两条路都走了一遍Ceph集群才稳定跑起来。这篇文章就专门聊聊离线场景下怎么部署Ceph流程、命令、踩坑记录都在里面适合做私有云、公司内网基础架构的运维和开发参考。其实“离线安装”这件事本身是相通的换个服务也差不多离线装Node、离线装Docker、离线装各种中间件核心思路都是先把依赖收集完整再在目标环境把依赖还原。这次拿Ceph这种组件多、角色复杂、依赖链特别长的分布式存储来说最能把问题暴露全。1. 离线部署的整体思路与路线选型1.1 为什么离线安装的难点不在Ceph本身Ceph本身是一套分布式存储系统核心角色有MON监控、MGR管理、OSD对象存储守护进程、MDS文件系统元数据、RGW对象存储网关。看起来装起来不难真正麻烦的是它的依赖链条特别长boost、librbd、librados、leveldb、rocksdb、libaio、gperftools、python3基础包……这些底层库之间有严格的版本匹配关系少一个或者版本不对服务起来就是各种诡异报错。在线环境下yum/apt一条命令就能把依赖自动拉齐离线之后整个依赖链条断了所有包只能靠人工搬运。打个比方在线安装就像在大型超市逛缺什么拿什么离线就是只给你一张购物清单和一个箱子清单没列全或者货架上同一件商品只有不匹配的规格就得停工。Ceph本身反而没有太多“装不装得上”的问题难点都集中在“依赖是否完整、版本是否匹配、仓库配置是否正确”这三件事上。1.2 三条主流离线路线怎么选我实际用过三种方式各有各的适用场景。方式适用场景优点缺点RPM/DEB本地源CentOS/Ubuntu节点Ceph 15及更早版本依赖关系由包管理器处理生态成熟包数量多收集麻烦版本匹配容易出问题cephadm 容器镜像Ceph 15官方推荐方式镜像自带运行环境依赖隔离彻底扩展方便目标节点需要装容器运行时镜像传输体积大源码编译特殊CPU架构、定制内核、研究学习完全可控耗时长依赖手工处理生产环境不推荐如果是在2020年以前的旧环境里RPM本地源几乎是唯一选择新版Ceph基本都用cephadm管理了它把复杂的依赖关系都封印在容器镜像里离线部署的容错率高很多。我个人的建议是新项目优先走cephadm加容器镜像老环境或者对容器方案抵触的生产系统再考虑RPM源。1.3 环境与工具清单我在实际项目里用过一个比较典型的组合后面所有命令都基于这一组环境三台目标节点CentOS 8IP分别为192.168.1.10、192.168.1.11、192.168.1.12系统盘sda每台另有一块空盘/dev/sdb用于OSD。一台跳板机CentOS 8可以访问公网用于下载依赖和打包镜像。Ceph版本16.2.10Pacific这是cephadm比较成熟的一个版本。工具方面主要用到repotrack、yumdownloader、createrepo、docker或podman、rsync/scp。后面每一步会说明具体作用。2. RPM本地仓库方式适合传统节点的离线安装2.1 在有网机器上收集全部依赖包RPM方式的第一步是把Ceph本体和它所有依赖从公网拉下来。这里我建议用repotrack而不是单纯的yumdownloader。repotrack会把指定软件包和所有运行时依赖一起下载而yumdownloader --resolve虽然也能解析依赖但在处理多层次间接依赖时经常漏包。在有网的跳板机上执行yum install -y yum-utils createrepo mkdir -p /data/ceph-repo repotrack ceph ceph-mon ceph-osd ceph-mgr ceph-radosgw --downloaddir/data/ceph-repo这个命令会把所有相关RPM包按依赖树逐层下载到/data/ceph-repo目录下。我实际跑下来最终包数量通常在300到500个之间总大小好几个GB。这里有个容易忽略的细节跳板机的系统版本和目标节点必须保持一致。比如目标节点是CentOS 8跳板机就不要拿CentOS 7去下载否则拿到的依赖包可能版本不兼容拷贝过去之后根本装不上。如果发现某些包没有自动拉下来可以用下载模式补充。比如发现缺librados2yum install librados2 --downloadonly --downloaddir/data/ceph-repo下载完以后先看一眼目录里有没有破损或空文件有些公网镜像源偶尔会给错误数据。这一步虽然简单但能省掉后面目标机上半天排查时间。2.2 制作并发布本地Yum仓库包收集齐了接下来把目录变成标准的Yum仓库。在有网跳板机上执行createrepo /data/ceph-repocreaterepo会根据目录下的RPM包生成repodata元数据也就是依赖解析的索引。生成完成后整个目录就可以当成离线源来用了。接下来两种做法一种是把整个目录用scp或rsync同步到目标节点本地rsync -av /data/ceph-repo 192.168.1.10:/data/另一种是在局域网内配置一台源服务器用nginx或httpd把/data/ceph-repo发布为HTTP目录。这样做的好处是后续几十台节点都能共用这一个源不用每台机器都拷贝一遍大目录。目标节点上新建/etc/yum.repos.d/ceph-local.repo[ceph-local] nameceph-local baseurlfile:///data/ceph-repo gpgcheck0 enabled1注意baseurl的写法。本地路径用file://开头的四层路径如果走的是HTTP源则写成http://源服务器IP/ceph-repo。这里我把gpgcheck直接设为0因为离线环境导入GPG key也是一堆麻烦事内网可信节点之间可以接受这个折中。2.3 在目标机器上安装Ceph组件源配置好了以后在目标节点上执行yum clean all yum makecache yum install -y ceph ceph-radosgw如果前面依赖收集得完整这里应该一路顺利装完。安装完成后可以顺手验证一下版本ceph --version如果这一步报缺包别急着用yum search去找大概率是跳板机下载依赖时漏了一部分。回到有网环境用repotrack补对应的依赖包重新createrepo后复制过来就行。装完之后传统方式还要手动配置MON、OSD和MGR。我早期用过ceph-deploy后来版本更新以后这套工具废弃了工作量比较大。所以如果是新环境我强烈建议直接看下面这个容器化方案。3. 基于cephadm的离线容器化部署更现代也更省心3.1 离线准备容器镜像和cephadm脚本cephadm是Ceph官方推荐的部署工具它本身是一个Python脚本部署思路很优雅Ceph的所有组件全部跑在容器里宿主机只需要提供容器运行时即可。这样依赖关系直接被镜像隔离了离线部署瞬间简单一大截。在有网跳板机上拉取镜像和脚本docker pull quay.io/ceph/ceph:v16.2.10 docker save -o ceph-v16.2.10.tar quay.io/ceph/ceph:v16.2.10 curl -L -o cephadm https://github.com/ceph/ceph/raw/v16.2.10/src/cephadm/cephadm chmod x cephadmdocker save会把镜像导出成一个tar包这个包就是后续离线部署的核心资产。接下来把cephadm脚本和镜像tar包同步到三台目标节点scp ceph-v16.2.10.tar cephadm 192.168.1.10:/root/ scp ceph-v16.2.10.tar cephadm 192.168.1.11:/root/ scp ceph-v16.2.10.tar cephadm 192.168.1.12:/root/然后在每个目标节点上导入镜像docker load -i ceph-v16.2.10.tar这里有个前提条件目标节点必须已经装好docker或者podman。离线环境下装docker同样需要RPM依赖可以走第2章的本地源方案把docker-ce和它的一系列依赖提前准备好。cephadm的bootstrap命令虽然能自动装容器运行时但那是基于在线下载的前提离线场景必须手动提前装好。另外目标节点还得有python3。cephadm脚本本身是Python写的虽然大部分逻辑跑在容器里但脚本自身执行还是需要宿主机Python环境的。3.2 初始化Mon节点并引导集群镜像都导入完成后在第一台节点上执行bootstrap./cephadm bootstrap --mon-ip 192.168.1.10 --image quay.io/ceph/ceph:v16.2.10这个命令会做几件事创建第一个MON启动一个MGR生成/etc/ceph/ceph.conf和client.admin的keyring同时把cephadm管理用的SSH key也配置好。bootstrap之后检查集群状态ceph -s正常情况下应该能看到一个MON和一个MGR处于active状态。如果卡在这里不动先别急着重启看看容器是否起来了docker ps常见的情况是cephadm发现本地没有镜像又跑到外网去拉结果一直超时。正因为这种默认行为前面那句“先在每台目标节点上load镜像”才特别重要。3.3 扩展OSD与RGW对象存储节点单节点不适合跑存储我们把第二、第三台节点加进集群。cephadm加节点依赖SSH免密登录先把公钥复制过去ssh-copy-id -f -i /etc/ceph/ceph.pub root192.168.1.11 ssh-copy-id -f -i /etc/ceph/ceph.pub root192.168.1.12然后把节点加入集群ceph orch host add node2 ceph orch host add node3这里有一个我踩过的坑很多新版Ceph要求hostname必须能解析建议提前在/etc/hosts里写好三台机器的映射不然ceph orch host add虽然成功后续放置OSD时还是会出现通信问题。加入节点后批量创建OSDceph orch apply osd --all-available-devices这条命令会把所有可用空盘自动创建为OSD。如果磁盘上还有旧分区表可以先清理ceph orch device zap node2 /dev/sdb --force ceph orch daemon add osd node2:/dev/sdb对象存储网关RGW的部署也很简单ceph orch apply rgw demo --realmdefault --zonedefault这样Ceph不仅能提供块存储还能对外提供S3兼容的对象存储服务。整个容器化方案核心的离线操作其实就三步save镜像、load镜像、bootstrap后面所有扩展操作都能靠Orchestrator自动完成比第2章的RPM方式省心太多。4. 离线安装中的高频问题和排错实录4.1 环境层问题时钟、防火墙、DNS与主机名Ceph对时间同步要求很苛刻MON之间时间偏差超了阈值集群直接报clock skew。离线环境经常忽略NTP服务装完Ceph以后ceph -s一直出现HEALTH_WARN查下来却是时间不同步。解决办法是在所有节点上统一配置chrony并指向同一台内网时间服务器或者手工date调整后等待同步。防火墙配置也是个高频问题。Ceph各组件用到的端口有MON的3300和6789MGR的6800到7300OSD和MDS也在这个区间内。测试环境图省事可以直接放行或关闭firewalld生产环境则要精确放行这些端口firewall-cmd --permanent --add-port6789/tcp firewall-cmd --permanent --add-port3300/tcp firewall-cmd --reload还有一个容易踩的坑是主机名。bootstrap完成之后再去改hostname会导致MON的地址和ceph.conf中的记录对不上集群起不来。所以正式部署前先把主机名定好不要中途改。4.2 依赖与包管理问题RPM方式的报错集中在依赖缺失和包冲突上。比如我在一次部署中遇到过librados2和ceph-selinux版本不一致安装时yum提示冲突。这种问题的根源往往是有网机器下载依赖时没有锁定统一版本repotrack虽然能拉全依赖但不同仓库提供的同名包版本可能不同。解决办法是下载时固定版本号比如repotrack ceph-16.2.10-1.el8 --downloaddir/data/ceph-repo或者把所有包统一从同一个源拉避免多个源版本交错。另外离线环境很多人图省事把gpgcheck0但公网下载的RPM包还是建议验一下SHA256确保文件没被破坏。我遇到过一次下载包字节缺失导致目标机安装时报“rpm: not an rpm package”白耗了半天才发现是文件损坏。4.3 集群初始化和OSD扩容问题cephadm环境下最常见的报错是容器拉取超时。发生这种问题不要浪费时间调网络先确认镜像包是否已经在所有节点上load完成。排查命令docker images | grep ceph如果没有对应镜像重新load一次。OSD起不来也是老熟人。常见原因是磁盘上没有清空分区表或者磁盘已经被系统占用。创建OSD前用lsblk确认盘符没有被挂载再执行zap清盘。MON无法启动时第一时间去看日志tail -100 /var/log/ceph/ceph-mon.$(hostname).log日志里如果出现clock skew字样基本就是时间问题出现corrupt db或version mismatch则是Ceph内部数据库版本不匹配需要考虑备份后重建MON。我把高频问题整理成速查表方便你直接对照现象可能原因排查思路处理方式clock skew节点时间不同步ceph -s date对比配置chrony统一时间OSD down磁盘未格式化/存在分区表lsblk检查ceph orch device zap后重建容器拉取超时镜像未导入docker imagesdocker load -i 镜像taryum安装缺依赖repotrack漏包/版本不一致yum报错信息定位具体包补下载并重新createrepoMON无法启动时间偏差/db损坏查看mon日志同步时间或重建MON节点通信失败hostname无法解析ping主机名配置/etc/hosts映射5. 离线项目里我反复强调的几件事5.1 把安装包清单当资产管理离线部署最容易出现的情况是当时装上去了三个月后另一套环境又要一模一样的集群结果之前下载的包找不到了。我现在做离线项目会专门维护一份DEPENDENCIES.md记录每个包的版本号、来源仓库、下载地址和校验值。这份清单本身就是资产它保证你随时能复现同一套环境。对于镜像方案镜像的完整Digest也要记录。不同版本的Ceph镜像差异很大我们这次用的是quay.io/ceph/ceph:v16.2.10后续扩容节点时镜像版本必须一致否则可能出现兼容性警告。5.2 优先打通局域网源通道单独给一两台节点拷贝文件没问题节点多了以后这个操作就变成灾难。我建议无论RPM包还是容器镜像都在局域网里部署一个源服务RPM用nginx发布repodata目录镜像用registry搭建私有镜像仓库。这样一来目标节点在离线环境下仍然能像在线一样执行yum install和docker pull只是流量全部走了内网。局域网源服务器的做法本质上是把“离线”转换成“受限在线”集群扩展时不需要再一台台拷文件体验和在线几乎一致。5.3 把安装流程脚本化连续做过几个离线项目以后我会把下面三件事固化成脚本第一步在跳板机收集依赖和镜像第二步在目标节点配置本地源和加载镜像第三步执行bootstrap并添加OSD。下次再遇到不能访问公网的项目直接跑脚本能节省大量重复沟通和排错时间。我个人做了几次离线部署之后最大的体会是离线并不等于不能装而是要把“联网时顺理成章的事”提前变成“可搬运的资源”。你提前准备的细致程度直接决定了现场折腾的时间。如果后续要在现有集群上继续做S3对象存储或者扩容OSD节点前面搭建好的本地源和镜像仓库能让你少走很多弯路。