ceph中PGLog处理流程

正文

struct pg_log_entry_t {
    ObjectModDesc mod_desc;                 //用于保存本地回滚的一些信息,用于EC模式下的回滚操作

    bufferlist snaps;                       //克隆操作,用于记录当前对象的snap列表
    hobject_t  soid;                        //操作的对象
    osd_reqid_t reqid;                      //请求唯一标识(caller + tid)


    vector > extra_reqids;


    eversion_t version;                     //本次操作的版本
    eversion_t prior_version;                //前一个操作的版本
    eversion_t reverting_to;                 //本次操作回退的版本(仅用于回滚操作)

    version_t user_version;                 //用户的版本号
    utime_t     mtime;                      //用户的本地时间
    
    __s32      op;                          //操作的类型
    bool invalid_hash;                      // only when decoding sobject_t based entries
    bool invalid_pool;                      // only when decoding pool-less hobject based entries

    ...
};
/**
 * pg_info_t - summary of PG statistics.
 *
 * some notes: 
 *  - last_complete implies we have all objects that existed as of that
 *    stamp, OR a newer object, OR have already applied a later delete.
 *  - if last_complete >= log.bottom, then we know pg contents thru log.head.
 *    otherwise, we have no idea what the pg is supposed to contain.
 */
struct pg_info_t {
    spg_t pgid;                    //对应的PG ID

    //PG内最近一次更新的对象的版本,还没有在所有OSD上完成更新。在last_update和last_complete之间的操作表示
    //该操作已在部分OSD上完成,但是还没有全部完成。
    eversion_t last_update;        
    eversion_t last_complete;      //该指针之前的版本都已经在所有的OSD上完成更新(只表示内存更新完成)

    epoch_t last_epoch_started;    //本PG在启动时候的epoch值
    
    version_t last_user_version;   //最后更新的user object的版本号
    
    eversion_t log_tail;           //用于记录日志的尾部版本
    
    //上一次backfill操作的对象指针。如果该OSD的Backfill操作没有完成,那么[last_bakfill, last_complete)之间的对象可能
    //处于missing状态
    hobject_t last_backfill;      


    bool last_backfill_bitwise;            //true if last_backfill reflects a bitwise (vs nibblewise) sort
    
    interval_set purged_snaps;   //PG要删除的snap集合
    
    pg_stat_t stats;                       //PG的统计信息
    
    pg_history_t history;                  //用于保存最近一次PG peering获取到的epoch等相关信息
    pg_hit_set_history_t hit_set;          //这是Cache Tier用的hit_set
};

下面简单画出三者之间的关系示意图:

ceph中PGLog处理流程_第1张图片

其中:

  • last_complete: 在该指针之前的版本都已经在所有的OSD上完成更新(只表示内存更新完成);

  • last_update: PG内最近一次更新的对象的版本,还没有在所有OSD上完成更新。在last_update与last_complete之间的操作表示该操作已在部分OSD上完成,但是还没有全部完成。

  • log_tail: 指向pg log最老的那条记录;

  • head: 最新的pg log记录

  • tail: 指向最老的pg log记录的前一个;

  • log: 存放实际的pglog记录的list

从上面结构可以得知,PGLog里只有对象更新操作相关的内容,没有具体的数据以及偏移大小等,所以后续以PGLog来进行恢复时都是按照整个对象来进行恢复的(默认对象大小是4MB)。

另外,这里再介绍两个概念:

  • epoch是一个单调递增序列,其序列由monitor负责维护,当集群中的配置及OSD状态(up、down、in、out)发生变更时,其数值加1。这一机制等同于时间轴,每次序列变化是时间轴上的点。这里说的epoch是针对OSD的,具体到PG时,即对于每个PG的版本eversion中的epoch的变化并不是跟随集群epoch变化的,而是当前PG所在OSD的状态变化,当前PG的epoch才会发生变化。

如下图所示:

ceph中PGLog处理流程_第2张图片

  • 根据epoch增长的概念,即引入第二个重要概念interval

因为pg的epoch在其变化的时间轴上并非是完全连续的,所以在每两个变化的pg epoch所经历的时间段我们称之为intervals。

3.1.3 Trim Log

void PrimaryLogPG::execute_ctx(OpContext *ctx)
{
    ......
      // trim log?
  if (hard_limit_pglog())
    calc_trim_to_aggressive();
  else
    calc_trim_to();
    ......
}

前面说到PGLog的记录数是有限制的,正常情况下默认是3000条(由参数osd_min_pg_log_entries控制),PG降级情况下默认增加到10000条(由参数osd_max_pg_log_entries)。当达到限制时,就会trim log进行截断。

在ReplicatedPG::execute_ctx()里调用ReplicatedPG::calc_trim_to()来进行计算。计算的时候从log的tail(tail指向最老的记录的前一个)开始,需要trim的条数为log.head - log.tail - max_entries。但是trim的时候需要考虑到min_last_complete_ondisk(这个表示各个副本上last_complete的最小版本,是主OSD在收到3个副本都完成时再进行计算的,也就是计算last_complete_ondisk和其他副本OSD上的last_complete_ondisk,即peer_last_complete_ondisk的最小值得到min_last_complete_ondisk),也就是说trim的时候不能超过min_last_complete_ondisk,因为超过了也trim掉的话就会导致没有更新到磁盘上的pg log丢失。所以说可能存在某个时刻,pglog的记录数超过max_entries。例如:

ceph中PGLog处理流程_第3张图片

你可能感兴趣的:(Ceph专栏,ceph)