ceph体系架构总览

一、功能划分

Ceph的提供了一个根据RADOS无限扩展的Ceph存储集群，相关内容你可以参阅REDOS-一个可伸缩的、可靠的存储服务PB级别存储集群。存储集 群客户端和每个Ceph的OSD守护进程使用CRUSH算法有效地计算有关数据位置的信息，而不必依赖于一个查找表。Ceph的高层次功能包括Ceph的 存储集群，通过 librados提供了一个原生接口，在librados基础上建立一些服务接口。

对应的进程Monitors监视器（ceph-mon），OSDs对象存储设备（ceph-osd）,通过读取配置文件ceph.conf实现集群。

1.1 OSD功能

OSD可以被抽象为两个组成部分，即系统部分和守护进程（OSD deamon）部分。OSD的系统部分本质上就是一台安装了操作系统和文件系统的计算机，其硬件部分至少包括一个单核的处理器、一定数量的内存、一块硬盘以及一张网卡。系统部分由操作系统内核实现，为ceph提供接口。

在 RADOS 的运行过程中， cluster map 的更新完全取决于系统的状态变化，而导致这一变化的常见事件只有两种： OSD 出现故障，或者 RADOS 规模扩大。 Cluster Maps 指包含所有的 Map ： OSD map,monitor map,placement group map, metadata server map 。

1.2 OSD管理的PG

PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个 object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载 大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。

File -> object映射：其映射十分简单，本质上就是按照object的最大size对file进行切分，相当于RAID中的条带化过程。这种切分的好处有二：一是让大小不限的 file变成最大size一致、可以被RADOS高效管理的object；二是让对单一file实施的串行处理变为对多个object实施的并行化处理。

Object -> PG映射：在file被映射为一个或多个object之后，就需要将每个object独立地映射到一个PG中去。

PG -> OSD映射：第三次映射就是将作为object的逻辑组织单元的PG映射到数据的实际存储单元OSD。

注意：映射过程中使用cluster map中的placement group map，OSDmap。

在 Ceph的现有机制中，一个OSD平时需要和与其共同承载同一个PG的其他OSD交换信息，以确定各自是否工作正常，是否需要进行维护操作。由于一个 OSD上大约承载数百个PG，每个PG内通常有3个OSD，因此，一段时间内，一个OSD大约需要进行数百至数千次OSD信息交换。

1.3 OSD的状态变迁

OSD状态的描述分为两个维度：up或者down（表明OSD是否正常工作），in或者out（表明OSD是否在至少一个PG中）。因此，对于任意一个OSD，共有四种可能的状态：

A．Up且in：说明该OSD正常运行，且已经承载至少一个PG的数据。这是一个OSD的标准工作状态；

B. Up且out：说明该OSD正常运行，但并未承载任何PG，其中也没有数据。一个新的OSD刚刚被加入Ceph集群后，便会处于这一状态。而一个出现故障的OSD被修复后，重新加入Ceph集群时，也是处于这一状态；

C. Down且in：说明该OSD发生异常，但仍然承载着至少一个PG，其中仍然存储着数据。这种状态下的OSD刚刚被发现存在异常，可能仍能恢复正常，也可能会彻底无法工作；

D. Down且out：说明该OSD已经彻底发生故障，且已经不再承载任何PG。

1.4 OSD的心跳维持

心跳是用于OSD节点间检测对方是否故障的，以便及时发现故障节点进入相应的故障处理流程。故障检测需要在故障的发现时间和心跳带来的负载之间做权衡，如果心跳频率太高则过多的心跳报文会影响系统性能，如果心跳频率过低则会延长发现故障节点的时间，从而影响系统的可用性。

在大规模部署的场景中，如果任意两个OSD节点间都建立心跳连接将带来巨大的负担。尤其，当新加入一个OSD节点时这个负担就会几倍地增加。Ceph中每个OSD只和以下两类节点建立心跳连接： 一类是同个PG下的OSD节点之间，因为属于同个PG的OSD节点会保存同份数据的副本，如若出现故障则会直接影响数据的可用性。另一类是OSD的左右两 个相邻的节点，这两个节点同自己物理上存在比较紧密的联系，例如可能连接在同台交换机。另外，如果建立心跳的Peer数目少于 osd_heartbeat_min_peers，那么OSD会继续同离他较近的几个OSD建立心跳连接。

OSD节点会监听public、cluster、front和back四个端口，其中front和back两个端口都是用于心跳的，cluster 端口用来监听来自OSD Peer的连接，public用来监听来自Monitor和Client的连接。如果启动OSD时没有提供back的IP地址，则back使用 cluster的IP地址；而front不单独提供IP地址，直接使用public的IP地址。另外，OSD单独创建了一个名为hbclient的 Messenger，作为心跳的客户端，单独用来建立连接发送心跳报文。心跳报文优先发送给back连接。

代码注释

// ceph-osd.cc 启动osd时创建Messengers

OSD::maybe_update_heartbeat_peers() 确定同哪些peer建立心跳连接，剔除已经down掉的节点的心跳连接

OSD::_add_heartbeat_peer()  同给定的peer建立心跳连接

OSDServeice::get_con_osd_hb()  获取peer的front和back连接

配置

OPTION(public_network, OPT_STR, "")

OPTION(cluster_network, OPT_STR, "")

OPTION(osd_heartbeat_min_peers, OPT_INT, 10)     // minimum number of peers

检测故障

OSD使用T_Heartbeat线程定时向Peer OSDs发送心跳报文，发送报文的时间间隔在0.5~6.5之间，由osd_heartbeat_interval配置选项决定。心跳报文会同时向 Peer OSD的front和back端口发送。心跳报文分两种类型一种是Ping类型，另一种是Reply类型。Ping类型的报文是OSD主动发送给Peer OSD的报文，而Reply是Peer OSD回应给自己的报文。两种类型的心跳报文都携带时间戳，但它们的时间戳代表的含义不一样。Ping类型报文的时间戳是发送报文时的时间，而Reply 类型报文的时间戳是从Ping报文中读取出来的，不是代表它自己的发送时间而是代表它对应的Ping报文的发送时间。OSD接收到Reply报文时将记录 报文的时间戳，并以此来判断是否超时。

对每个Peer节点，如果其最近的应答的时间(最近的Reply报文的时间戳)位于cutoff之前(即超时grace秒)，则将其加入到 failure_queue队列。OSD会定时向Monitor汇报自己的状态，在汇报状态时将failure_queue队列中Peer发送给 Monitor，由Monitor将其标记为down状态。Monitor在接收到OSD对Peer的故障报告后，通过PAXOS算法决定是否将Peer OSD标记为Down状态。如果将Peer OSD标记为Down状态，那么将更新OSD MAP，OSD接收到OSD Map更新的消息后，断开和Peer OSD的心跳连接。

如果在向Monitor报告故障之后但在接收到OSD Down消息之前，再次接收到Peer OSD对心跳报文的回应，则将Peer OSD从failure_queue队列中移除，并通知Monitor该节点依旧存活着。

代码注释

void OSD::heartbeat_entry() // T_Heartbeat线程入口函数，定时向心跳Peers发送心跳报文

void OSD::heartbeat()

map<int,utime_t> failure_queue; // 检测到peer长时间没心跳时，将peer加入到failure_queue队列

map<int,entity_inst_t> failure_pending; // 故障报告给Monitor的Peer OSD

void send_failures();

void send_still_alive(epoch_t epoch, const entity_inst_t &i);

void OSD::note_down_osd(int peer)

void OSD::handle_osd_ping(MOSDPing *m) // 处理MOSDPing消息

配置

OPTION(osd_heartbeat_interval, OPT_INT, 6)       // (seconds) how often we ping peers

OPTION(osd_heartbeat_grace, OPT_INT, 20)         // (seconds) how long before we decide a peer has failed

1.5 OSD流程概述

Recovery/scrub/peering