一、功能划分
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 failed1.5 OSD流程概述
Recovery/scrub/peering