当Ceph 15.2.17遇上Kylin V10：一个系统工程师的编译实战日记

Ceph 15.2.17在Kylin V10上的编译实战系统工程师的深度踩坑指南作为一名常年与开源存储系统打交道的工程师最近接手了一个将Ceph集群迁移到国产化平台的任务。当Ceph 15.2.17遇上Kylin V10这场看似普通的编译部署竟演变成了一场持续72小时的技术探险。本文将用第一视角还原整个过程中的关键决策点和技术突破特别适合那些正在或将要在国产化环境中部署分布式存储的同仁参考。1. 环境准备国产化平台的独特挑战1.1 软件源配置的艺术在Kylin V10上默认的软件源往往无法满足Ceph编译的需求。我创建了自定义repo文件/etc/yum.repos.d/kylin_x86_64.repo但很快发现需要额外添加EPEL源才能获取部分依赖包。这里有个小技巧Kylin系统对某些包的命名做了修改例如[ks10-adv-os] name Kylin Linux Advanced Server 10 - os baseurl http://archive.kylinos.cn/yum/ks10-adv/os/x86_64/ gpgcheck 0 enabled 1 [ks10-adv-updates] name Kylin Linux Advanced Server 10 - updates baseurl http://archive.kylinos.cn/yum/ks10-adv/updates/x86_64/ gpgcheck 0 enabled 1提示Kylin的软件源结构与其他Linux发行版不同建议先通过yum repolist验证源是否生效。1.2 依赖包安装的陷阱执行yum install时遇到了几个典型问题包名差异redhat-rpm-config在Kylin上被重命名为kylin-rpm-config版本冲突系统预装的Python 3.6与Ceph要求的3.7不兼容隐藏依赖需要手动安装的额外包包括wget http://mirror.centos.org/centos/7/os/x86_64/Packages/redhat-lsb-core-4.1-27.el7.centos.1.x86_64.rpm rpm -ivh redhat-lsb-core-4.1-27.el7.centos.1.x86_64.rpm --nodeps下表总结了主要依赖问题的解决方案问题类型典型表现解决方案包名差异No package available使用yum search查找Kylin特有包名版本冲突编译时链接错误建立Python版本软链接ln -sf /usr/bin/python3.7 /usr/bin/python依赖缺失编译中途报错提前安装liboath-devel等扩展包2. GCC版本管理的实战技巧2.1 升级GCC的血泪史Ceph 15.2.17要求GCC 8.3而Kylin V10默认安装的是7.3。通过ISO镜像中的Packages-gcc目录升级时我踩了三个坑依赖顺序必须按序安装gmp-devel、libmpc-devel、mpfr-devel强制覆盖使用rpm -ivh *.rpm --force避免版本冲突环境变量升级后需执行source /etc/profile使新版本生效验证GCC版本的正确方式# 检查动态库链接 ldd $(which gcc) # 验证C17支持 echo #include filesystem | g -x c -stdc17 -c -2.2 那个深夜的CMake错误最棘手的错误出现在凌晨2点CMake Error at cmake/modules/BuildBoost.cmake:278 (_add_executable): Target ceph-mon links to target StdFilesystem::filesystem but the target was not found.根本原因是GCC 7.3的libstdc不完整支持C17文件系统库。通过以下步骤解决确认GCC版本gcc --version检查动态库路径strings /usr/lib64/libstdc.so.6 | grep GLIBCXX完全卸载旧版本rpm -e --nodeps gcc-7.3.1注意在国产化平台上直接yum remove可能无法彻底清除旧版GCC需要手动检查/usr/local/bin等目录。3. RPM构建的定制化实战3.1 目录结构的正确姿势创建rpmbuild环境时Kylin对目录权限有特殊要求mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,BUILDROOT} chmod 755 ~/rpmbuild3.2 spec文件的关键修改点Ceph官方spec文件需要多处调整源码包格式将.tar.bz2改为.tar.gz系统标识替换redhat-rpm-config为kylin-rpm-config宏定义修改/usr/lib/rpm/macros中的构建终止策略# 原值 %_unpackaged_files_terminate_build 1 # 修改为 %_unpackaged_files_terminate_build 03.3 编译参数的优化策略针对国产化平台的硬件特点我采用了这些优化# 增加并行编译线程 export MAKEFLAGS-j$(nproc) # 限制内存使用针对小内存机器 ulimit -Sv 4000000 # 关键编译命令 rpmbuild -ba --target$(uname -m) \ --define _topdir $(pwd)/rpmbuild \ --define _smp_mflags -j4 \ ceph.spec4. 部署后的调优经验4.1 服务启动的隐藏关卡安装完成后直接启动服务会遇到权限问题需要手动创建/var/lib/ceph目录并设置权限SELinux冲突在Kylin上执行semanage fcontext -a -t ceph_var_lib_t /var/lib/ceph(/.*)? restorecon -Rv /var/lib/ceph4.2 性能调优参数对比根据实测数据Kylin平台上的最佳参数与x86平台有显著差异参数项常规值Kylin优化值效果提升osd_memory_target4GB3GB减少OOM概率filestore_queue_max_ops500300降低IO延迟ms_async_op_threads42更稳定网络吞吐4.3 监控方案的特殊处理由于Kylin的包差异Prometheus exporter需要手动编译git clone --branch v15.2.17 https://github.com/ceph/ceph.git cd ceph/src/prometheus/ make cp ceph-mgr-prometheus /usr/lib64/ceph/mgr/整个项目最深的体会是国产化平台的适配不仅是技术活更是一场耐心与细心的考验。那些看似普通的编译错误背后往往隐藏着对操作系统底层机制的深刻理解需求。记得在解决最后一个依赖问题时通过strace -f rpmbuild命令最终追踪到一个隐蔽的动态库加载路径差异——这种侦探式的调试过程或许正是系统工程师工作的独特魅力所在。