商会网站建设网络营销外包网络推广
Ceph版本：14.2.22
Linux版本：ubuntu-server 18.04
第一部分 下载Ceph源码
1.1 配置Ceph源码镜像源
Ceph源码是托管在Github上，由于某些原因，国内访问Github网站很慢，所以需要从其他途径加速获取源码。Github官方给出了几个Github的镜像网站：
- https://github.com.cnpmjs.org/
- https://hub.fastgit.org/
本地需要修改~/.gitconfig文件，才可以从上面镜像网站获取源码，相关配置如下：
#Github镜像源
[url "https://hub.fastgit.org/"]insteadOf = https://github.com/
注：国内也有Ceph源码的镜像，比如Gitee、Gitcode，但不建议从这些网站上获取。因为Ceph源码中使用了大量的第三方源码作为自己的子模块，而Gitee、Gitcode不一定将这些子模块全部同步过来。相反，上面的两个镜像网站和Github完全是同步的，所以可以放心使用。
1.2 克隆ceph源码
Ceph源码很大，可根据需要，选择性下载哪个版本或哪个分支。本案例拉取v14.2.22版本的源码。版本和分支的区别：版本的代码不会随时间改变，被定格在打标签的那一刻；分支的代码会随时间不断开发改变。
# 根据自己需要更换 v14.2.22 为自己需要的版本
git clone -b v14.2.22 --depth=1 https://github.com/ceph/ceph.git
1.3 同步子模块源码
Ceph源码中使用大量的子模块，在 ceph/.gitmodules 文件中罗列出所有的子模块。在后面执行do_cmake.sh 脚本生成 build 目录时，do_cmake.sh 首先同步子模块源码到指定目录。根据经验，在同步子模块源码时很容易出现同步不全，或同步失败，这直接会导致构建 build 目录失败。为了防止此状况发生，建议提前手动去同步子模块源码。
git submodule update --init --recursive
注：如果发现同步子模块源码失败，重复执行上面命令即可。如果中断同步子模块源码，此时必须要到相应目录下删除该子模块所有文件，尤其是 .git 文件。如果不删除 .git，重复执行上面命令时，则会直接跳过同步该子模块，导致子模块源码缺失。这个问题无法被检测到，因为执行完上面命令后，依然会显示同步成功，而不会提示哪个子模块没有被同步。
第二部分 源码编译
2.1 安装依赖
Ceph源码安装依赖很简单，直接执行源码根目录下install-deps.sh脚本，根据经验发现，该脚本存在一些问题，需要稍微修改一下。
2.1.1 修改launchpad源
脚本会安装gcc环境，安装包源url只需要保留一个即可，修改install-deps.sh脚本中的函数ensure_decent_gcc_on_ubuntu
deb [lang=none] http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu $codename main
#deb [arch=amd64 lang=none] http://mirror.cs.uchicago.edu/ubuntu-toolchain-r $codename main
#deb [arch=amd64,i386 lang=none] http://mirror.yandex.ru/mirrors/launchpad/ubuntu-toolchain-r $codename main
2.1.2 屏蔽调用安装libboost的部分
脚本会安装 libboost 库，编译源码过程会再次下载 boost 源码包，因此脚本中不应该再安装 libboost，屏蔽install-deps.sh以下2个地方
*Bionic*)#install_boost_on_ubuntu bionic;;
2.1.3 设置pypi镜像源
脚本会安装pypi库，默认url下载很慢，需要设置pypi库镜像源。创建 ~/.pip/pip.conf 文件，并追加以下内容
[global]
index-url = https://mirrors.aliyun.com/pypi/simple/
[install]
trusted-host=mirrors.aliyun.com
2.1.4 安装其他依赖
编译源码过程中会遇到很多函数用到zstd库，默认情况下ubuntu18.04只安装了libzstd1，但没有用，需要安装 libzstd1-dev
sudo apt install libzstd1-dev
2.1.5 执行脚本
./install-deps.sh
2.2 编译Ceph源码
2.2.1 开启debug模式
如果想要调试Ceph源码，需要设置编译源码模式为debug模式，默认编译模式为release模式，该模式是不能调试源码。向 ceph/CMakeList 文件的 set(VERSION 14.2.22) 后追加以下内容
set(CMAKE_BUILD_TYPE "Debug")
set(CMAKE_CXX_FLAGS_DEBUG "-O0 -Wall -g")
set(CMAKE_CXX_FLAGS "-O0 -Wall -g")
set(CMAKE_C_FLAGS "-O0 -Wall -g ")
2.2.2 构建build目录
直接执行do_cmake脚本，该脚本会进行一系列检测，包括源码是不是完整，依赖是不是都安装了等等。如果出现问题，构建出的build目录是不完整的，最直接的影响是无法生成makefile文件，导致无法编译。
./do_cmake.sh
2.2.3 下载boost源码包
在执行make编译的时候，脚本会自动下载 boost_1_72_0.tar.bz2，由于下载地址和网络问题，下载很慢，为了节省时间，提前手动下载，下载地址：https://download.ceph.com/qa/boost_1_72_0.tar.bz2，将下载的好的包放在ceph/build/boost/src即可。
2.2.4 编译
使用make编译必须要到ceph/build目录下执行，ceph源码可以单独编译某一个模块，也可以全部编译。使用make可以指定多线程编译，提高编译速度，但要合理分配线程数，建议使用4线程编译即可。
#方式1：全部编译
make all -j4
#方式2：单独编译osd某块
make ceph-osd -j4
#查看所有模块
make help
注：源码编译会生成很多库文件和二进制文件，分别放在ceph/build/lib和ceph/build/bin目录下
第三部分 部署Debug版本的集群
3.1 集群部署
Cpeh源码提供了一个部署开发集群的脚本：vstart.sh，该脚本会利用本地IP和不同端口来配置MON、MGR、OSD等。切换到切换到build目录下，执行以下命令，部署一个新的集群
MON=1 OSD=6 MDS=0 MGR=1 RGW=0 ../src/vstart.sh -d -n -x --without-dashboard
参数解释：
- MON、 OSD、 MDS、 MGR是配置相应的个数
- -d：debug，开启debug模式
- -n：new，新建一个集群
- -x：cephx，cephx认证
- --without-dashboard，mgr的一个配置，自测发现如果这个不关闭，部署会报错
3.2 查看集群状态
切换到build目录下，执行以下命令，查看集群状态
./bin/ceph -s
结果如下
cluster:id: 88b11a21-7dd1-49d8-bb24-c18821ff09aehealth: HEALTH_OKservices:mon: 1 daemons, quorum a (age 5m)mgr: x(active, since 5m)osd: 6 osds: 6 up (since 4m), 6 in (since 4m)data:pools: 0 pools, 0 pgsobjects: 0 objects, 0 Busage: 12 GiB used, 594 GiB / 606 GiB availpgs:
注：ceph 14.2.22版本的vstart.sh脚本并没有将ceph可执行文件添加到系统环境变量中，所有的ceph命令都必须在build目录下执行
3.3 部署ceph分级存储结构
本案例需要调试ceph分级存储功能，因此简单的搭建一个分层存储结构。为集群分配6个OSD，创建2个pool，cache pool和ec pool，每个pool分配了3个osd。
详细部署请参考(文章还在编写中)
第四部分 代码调试
4.1 查看PG-OSD映射关系
如果仔细阅读源码，会发现ceph分级存储主要是由主OSD进程来负责。如果不是主OSD，是无法调试到代码中的。所以需要查看分级存储中缓存池的PG映射关系。
#切换到build目录下，执行以下命令
./bin/ceph pg ls-by-pool cache_poolPG OBJECTS DEGRADED MISPLACED UNFOUND BYTES OMAP_BYTES* OMAP_KEYS* LOG STATE SINCE VERSION REPORTED UP ACTING SCRUB_STAMP DEEP_SCRUB_STAMP
5.0 0 0 0 0 0 0 0 18 active+clean 22h 323'18 323:76 [2,4,0]p2 [2,4,0]p2 2021-09-25 16:55:28.572062 2021-09-24 11:30:14.717641
从结果可以看到PG5.0对应的主OSD为OSD 2
4.2 查看主OSD进程
执行以下命令
ps -ef | grep ceph
结果如下
admins 10961 19680 0 15:12 pts/0 00:00:00 grep --color=auto ceph
admins 18474 1 1 Sep24 ? 01:02:09 /home/admins/code/ceph/build/bin/ceph-mon -i a -c /home/admins/code/ceph/build/ceph.conf
admins 18582 1 1 Sep24 ? 00:33:41 /home/admins/code/ceph/build/bin/ceph-mgr -i x -c /home/admins/code/ceph/build/ceph.conf
admins 18806 1 1 Sep24 ? 00:41:15 /home/admins/code/ceph/build/bin/ceph-osd -i 1 -c /home/admins/code/ceph/build/ceph.conf
admins 19096 1 1 Sep24 ? 00:41:06 /home/admins/code/ceph/build/bin/ceph-osd -i 3 -c /home/admins/code/ceph/build/ceph.conf
admins 19242 1 1 Sep24 ? 00:40:37 /home/admins/code/ceph/build/bin/ceph-osd -i 4 -c /home/admins/code/ceph/build/ceph.conf
admins 19415 1 1 Sep24 ? 00:41:00 /home/admins/code/ceph/build/bin/ceph-osd -i 5 -c /home/admins/code/ceph/build/ceph.conf
admins 20385 1 1 Sep24 ? 00:39:47 /home/admins/code/ceph/build/bin/ceph-osd -i 0 -c /home/admins/code/ceph/build/ceph.conf
admins 22235 1 1 Sep24 ? 00:40:24 /home/admins/code/ceph/build/bin/ceph-osd -i 2 -c /home/admins/code/ceph/build/ceph.conf
从结果可以看到，主OSD进程号为 22235
4.3 GDB多线程调试
关于linux gdb多线程调试具体用法这里就不多介绍，需要学习了解的，请百度。以下仅为本案例调试步骤
4.3.1 进入gdb模式
gdb调试需要以管理员权限，执行以下命令，进入gdb模式
sudo gdb
结果如下
[sudo] password for admins:
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb)
4.3.2 attach osd2 进程
(gdb) attach 22235
Attaching to process 22235
[New LWP 22237]
[New LWP 22238]
[New LWP 22239]
[New LWP 22248]
[New LWP 22249]
[New LWP 22250]
[New LWP 22251]
[New LWP 22254]
[New LWP 22255]
[New LWP 22256]
[New LWP 22257]
[New LWP 22258]
[New LWP 22259]
[New LWP 22260]
[New LWP 22269]
[New LWP 22270]
[New LWP 22271]
........
........
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fd026a7dad3 in futex_wait_cancelable (private=<optimized out>, expected=0, futex_word=0x55b3123d8910) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
88 ../sysdeps/unix/sysv/linux/futex-internal.h: No such file or directory.
(gdb)
4.3.3 设置断点
#本例断电设置在PrimaryLogPG::do_op函数开始
(gdb) b PrimaryLogPG.cc:1952
Breakpoint 1 at 0x55b305d28af2: file /home/admins/code/ceph/src/osd/PrimaryLogPG.cc, line 1952.#设置完断电之，执行continue
(gdb) c
Continuing.
4.3.4 测试
向存储池中写入数据，测试结果如下
[Switching to Thread 0x7fd0034cb700 (LWP 22364)]
Thread 57 "tp_osd_tp" hit Breakpoint 1, PrimaryLogPG::do_op (this=0x55b312519400, op=...)
at /home/admins/code/ceph/src/osd/PrimaryLogPG.cc:1952
1952 {
从上面结果可以看到，当写入数据时，函数停在代码的1952行，现在就可以使用gdb命令进行代码调试，和正常调试代码一样。但需要值得注意的一点是，由于ceph osd存在心跳机制，当调试某一个osd时，如果长时间没有走完该走的流程，该osd会被标记为down，就无法再继续调试。需要重新进入gdb模式！