Ceph源代码主要目录和文件介绍

Ceph14.2.22源代码：https://download.ceph.com/tarballs/

ceph-14.2.22根目录

• 【admin】：管理工具，用于架设文档服务器等

• 【cmake】：Ceph对cmake的支持

• 【debian】：用于制作debian（Ubuntu）安装包的相关脚本和文件

• 【doc】：用于生成项目文档，生成结果参考https://docs.ceph.com/en/latest/

• 【examples】：librados和librbd的HelloWorld例子

• 【qa】：各个模块的功能测试脚本和代码

• 【systemd】：Ceph对于systemd的支持目录

• 【udev】：Ceph的udev规则

  KERNEL=="rbd[0-9]*", ENV{DEVTYPE}=="disk", PROGRAM="/usr/bin/ceph-rbdnamer %k", SYMLINK+="rbd/%c"
  KERNEL=="rbd[0-9]*", ENV{DEVTYPE}=="partition", PROGRAM="/usr/bin/ceph-rbdnamer %k", SYMLINK+="rbd/%c-part%n"
  
  # This is a placeholder, uncomment and edit as necessary
  #KERNEL=="rbd[0-9]*", ENV{DEVTYPE}=="disk", ACTION=="add|change", ATTR{bdi/read_ahead_kb}="128"
  

  这个文件用于定义udev规则，以自动配置Ceph RBD（块设备）的名称和符号链接。

  1. 第一行定义了一个udev规则，当内核设备名称以"rbd"开头，并且设备类型为"disk"时，将执行以下操作：
     • PROGRAM：定义了一个执行"/usr/bin/ceph-rbdnamer %k"命令的程序。其中，%k表示内核设备名称。
     • SYMLINK：定义了一个符号链接，其名称是"rbd/%c"。其中，%c表示内核设备名称。
  2. 第二行定义了一个udev规则，当内核设备名称以"rbd"开头，并且设备类型为"partition"时，将执行以下操作：
     • PROGRAM：定义了一个执行"/usr/bin/ceph-rbdnamer %k"命令的程序。其中，%k表示内核设备名称。
     • SYMLINK：定义了一个符号链接，其名称是"rbd/%c-part%n"。其中，%c表示内核设备名称，%n表示分区编号。
  3. 注释掉的一行是另一个udev规则，当内核设备名称以"rbd"开头，并且设备类型为"disk"或"partition"时，将执行以下操作：
     • ACTION：定义了当设备添加或更改时执行操作。
     • ATTR{bdi/read_ahead_kb}：定义了一个名为"bdi/read_ahead_kb"的属性，其值为"128"。

• 【src】：功能模块的源代码

• ceph.spec.in：Ceph打包的spec文件

• CMakeLists.txt：CMake工具使用的描述文件

• CodingStyle：Ceph的代码编写规范

src目录

• 【arch】：检测CPU架构和指令集特性

• 【auth】：授权模块，实现了三方认知机制。

• 【boost】：boost库，Boost库是为C++语言标准库提供扩展的一些C++程序库的总称，由Boost社区组织开发、维护。Boost库可以与C++标准库完美共同工作，并且为其提供扩展功能。

• 【ceph-volume】：

• 【client】：client模块，实现了用户态的CephFS客户端

• 【common】：通用模块，包含各类共有机制的实现，例如线程池、管理端口、节流阀等

• 【doc】：关于代码的一些说明文档

• 【global】：全局模块，主要是声明和初始化各类全局变量（全局上下文）、构建驻留进程、信号处理等。

• 【googletest】：googletest测试框架

• 【crush】：Crush模块，Ceph的数据分布算法

• 【include】：头文件，包含各种基本类型的定义，简单通用功能等

• 【json_spirit】：外部项目json_spirit

• 【kv】：四种KV store的调用接口

• 【librados】：rados库模块的代码

• 【librdb】：librbd库模块的代码

• 【log】：日志模块，主要负责记录本地log信息（默认/var/log/ceph/目录）

• 【mds】：mds模块

• 【messages】：消息模块，定义了Ceph各节点之间消息通讯中用到的消息类型。

• 【mgr】：mgr模块

• 【mon】：mon模块

• 【mount】：mount模块

• 【msg】：消息通讯模块，包括用于定义通讯功能的抽象类Messenger以及目前的实现SimpleMessager

• 【os】：对象（Object Store）模块，用于实现本地的对象存储功能，

• 【osd】：osd模块

• 【osdc】：OSD客户端（OSD Client），封装了各类访问OSD的方法。

• 【perfglue】：与性能优化相关的源代码

• 【pybind】：python的包装器

• 【rgw】：rgw模块

• 【rocksdb】：外部项目rocksdb模块

• 【script】：各种python脚本

• 【spdk】：spdk模块

• 【test】：单元测试

• 【tools】：各类工具

• 【zstd】：数据压缩模块

• ceph_fuse.cc：工具ceph_fuse

• ceph_mds.cc：驻留程序mds

• ceph_mgr.cc：驻留程序mgr

• ceph_mon.cc：驻留程序mon

• ceph_osd.cc：驻留程序osd

• ceph_syn.cc：工具ceph_syn

• krdb.cc：kernel rdb库

• libcephfs.cc：cephfs库

• sample.ceph.conf：配置文件样例

src整体可分为三层：

1. Base

   基础层包含了与业务无关的各类模块，例如对数值类型的定义、线程池、序列化等。

   • 【include】：头文件，包含各种基本类型的定义，简单通用功能等。

   • 【common】：共有模块，包含各类共有机制的实现，例如线程池、管理端口、节流阀等。

   • 【log】：日志模块，主要负责记录本地log信息（默认/var/log/ceph/目录）

   • 【global】：全局模块，主要是声明和初始化各类全局变量（全局上下文）、构建驻留进程、信号处理等。

   • 【tracing】：Ceph tracing模块，目前支持使用lttng，可以在该目录下定义lttng的tracepoint。

2. Component

   组件层是为实现各项业务提供的功能组件，例如消息通讯、认证授权、数据分布算法等。

   • 【crush】：Crush模块，Ceph的数据分布算法 。其中CrushCompiler.cc主要负责对crushtool命令传入的crushmap.txt进行compile和parse(parse_tunable、parse_device、parse_bucket_type、parse_bucket、parse_rule），拿parse rule来说，解析后会通过CrushWrapper.h中的add_rule调用builder.cc的crush_add_rule实现rule的添加。总的来说crush.h 中定义了crush_map的结构和四种bucket类型，builder.c文件定义了crushmap中关于rule、bucket的增删改查操作。mapper定义了crushmap中的step、choose操作，而hash.c中定义了crush中使用的rjenkins算法。

   • 【os】：对象存储（Object Store）模块，用于实现本地的对象存储功能，目前包括：bluestore、filestore、kstore、memstore；其中*store的基类为ObjectStore，定义在ObjectStore.h中。常用的是FileStore，定义在filestore目录，而Ceph为了解决性能问题，目前正在全力开发bluestore。这里先主要关注一下FileStore，在FileStore.h中主要定义了FileStore和FileStoreBackend两个类，其中FileStore中定义了Op的操作模型（OpWQ、OpSequencer）和transaction的操作模型，它继承自JournalingObjectStore类。而FileStoreBackend类定义了FileStore获取后端具体文件系统的一些操作。

   • 【auth】：授权模块，实现了三方认知机制。

   • 【msg】：消息通讯模块， OSD使用msg模块进行网络通讯，包括监听客户端的IO，与其它osd收发消息，以及与mon进行通讯等。该目录下包括用于定义通讯功能的抽象类Messenger以及目前的实现SimpleMessager、AsyncMessenger、XIO。

   • 【messages】：消息模块，定义了Ceph各节点之间消息通讯中用到的消息类型。

   • 【osdc】：OSD客户端（OSD Client），主要包括Objecter、ObjectCacher、Striper、Filer和Journaler。Objecter主要是将request封装成对应的Ops、计算出request需要发送的OSD并且以message的方式将Op发送出去。ObjectCacher是client端的Cache层。Stripper是将一个块设备映射成object，而Filer是把file的range映射成object。Journaler主要是用于MDS的

   • 【kv】：定义了keyvaluestore的后端存储实现。

   • 【cls】：针对第三方插件的支持。

3. SubSystem

   子系统层即Ceph中各个功能节点，包括:

   • 【mon】：Monitor作为Ceph集群状态管理者管理MonMap、PGMap和OSDMap，其主要由各种Monitor组件组成，并使用Paxos协议实现Mon之间数据同步来保证数据一致性，通过quorum协议来保证Mon之间的高可用。

     • AuthMonitor、LogMonitor、MDSMonitor、MonmapMonitor、OSDMonitor、PGMonitor、HealthMonitor
     • MonMap、PGMap、OSDMap
     • MonClient、MonCommands
     • Paxos、PaxosService、QuorumService
     • ConfigKeyService
     • MonitorDBStore

   • 【osd】：定义了后端OSD、PG相关的类和处理逻辑。 在OSD模块中，最核心、也是实际处理IO请求和故障恢复的模块类是PG。 PG是一个对象的集合，包含对象名称的哈希值与PG的ID相符的所有对象。而在Ceph的软件设计中，PG是osd中处理IO的类，即属于某一个PG的对象的请求，全部由该对象对应的PG类的实例进行处理。 相对于PG，OSD实际扮演了一个服务者的角色，即为PG提供了以下服务：1）通过调用os模块提供本地存储服务；2）通过调用msg模块提供消息通讯服务；3）通过提供线程池提供计算服务。 可以将OSD理解为PG的运行环境。PG“生活”在某一个OSD中，也可能由于系统的变化，而迁移到另一个OSD中，这一过程实际也就是数据迁移的过程。

     • OSD、OSDService、OSDMap
     • PG、PGBackend、ReplicatedBackend、PGLog
     • ECBackend、ECTransaction
     • HitSet

   • 【mds】：MDS定义了维护了CephFS中的元数据，包括文件系统的树形结构、文件的属性、访问控制信息等，这些数据都是存在MDS节点的内存中，而真正的数据是存储在Rados里的。

     • MDSDaemon、MDSRank、MDSMap、Beacon、MDCache、MDBalancer
     • CDir、CDentry、CInode
     • MDSTable、InoTable

   • 【client】：Client主要定义了CephFS client端的代码。

   • 【rbd】：实现包括两部分：krbd（kernel版的rbd，源码在drivers/block/rbd.c）和librbd。

   • 【rgw】：实现了rgw的功能，rgw的主要作用是协议转换，即把HTTP协议的请求转化为RGW Object再转换为Rados Object，交由Rados处理。

   • 【tools】：Ceph中的各种工具的实现：cephfs、rados、rbd、rbd-nbd、ceph-authtool、ceph-conf、ceph-kvstore-tool、ceph-monstore-tool、ceph-objectstore-tool、crushtool、monmaptool、osdmaptool

   • 【librados】：librados实现了rados层的接口，其中几个重要的数据结构有Rados、RadosClient、IoCtx、IoCtxImpl。IoCtx（include/rados/librados.hpp）是Rados I/O的一个上下文，其定义了大部分的I/O接口如read、write等

参考

• https://www.cnblogs.com/wangbin/p/10689169.html

• https://blog.csdn.net/don_chiang709/article/details/99289441