Ceph pg状态怎么标记为stale

问题

Ceph中的pg是合适标记为stale状态的

分析

1.做了一个实验，把osd的beacan超时这是为5s（原来是900s）

1
ceph daemon mon.a config set mon_osd_report_timeout 5

这个命令之后ceph 的osd都会标记为down状态，同时ceph 的pg（我的pg是单pool单pg，并且只在一个osd上面）状态按理来说应该是stale+active+clean,但是我ceph -s看状态一致都是active + clean,
2
其他原因如下，我们这种把超时设置小了，其实osd的进程还在，没有挂掉，osd还是会定时向mgr上报pg的状态，而osd里面记录的状态还是active+clean（这里有peering过），ceph -s看到也是从mgr获取，也就是其实是mgr在一个时刻设置了stale，但是后来被osd上报的pg状态给刷掉了，日志如下
1
那osd为什么会还是active+clean呢，其实刚开始设置超时的时候，osd被标记为 down，收到mon osdmap更新（mgr设置pg为stale也是收到mon的osdmap更新），经过peering，pg状态恢复到active+clean，后面osd状态没有变过，也就是osdmap没有变化，所以这个osd的pg状态会一直维护为active+clean

2.pg状态被标记为stale是mgr做的事情

mon在osdmap变化之后，会发送osdmap给mgr，mgr通过notify_osdmap进行处理

1
2
3
4
5
6
7
8
void ClusterState::notify_osdmap(const OSDMap &osd_map)
{
  ....
  PGMapUpdater::check_down_pgs(osd_map, pg_map, true,
			       need_check_down_pg_osds, &pending_inc);

  ...
}

在这里会调用check_down_pgs检查

1
2
3
4
5
6
7
8
9
10
11
void PGMapUpdater::check_down_pgs(
    const OSDMap &osdmap,
    const PGMap &pg_map,
    bool check_all,
    const set<int>& need_check_down_pg_osds,
    PGMap::Incremental *pending_inc)
{
  ....
	  _try_mark_pg_stale(osdmap, pgid, stat, pending_inc);
  ....
}

_try_mark_pg_stale这个函数有修改

1
2
3
4
5
6
7
8
9
10
11
static void _try_mark_pg_stale(
  const OSDMap& osdmap,
  pg_t pgid,
  const pg_stat_t& cur,
  PGMap::Incremental *pending_inc)
{
    ....
    newstat->state |= PG_STATE_STALE;
    newstat->last_unstale = ceph_clock_now();
  }
}

并在这里修改mgr内存的pg状态，然后向mon一直会报，因为我们kill调的osd已经不再像mgr会报pg状态了

展开全文 >>

数据还没有apply前进行读

问题

ceph在写完日志之后就回调commit发送ack，write操作就完成了，这个时候表示数据写完成，但是
还是不能读的，只有apply回调完成才变成可读，那这个可读是哪里的控制的呢？

分析

1. 对象上面有读写锁

  • 在写的时候会进行ondiskwritelock
    1
    2
    3
    4
    5
    6
    7
    8
    9
    void ondisk_read_lock() {
       lock.Lock();
       readers_waiting++;
       while (unstable_writes)
         cond.Wait(lock);
       readers_waiting--;
       readers++;
       lock.Unlock();
     }

unstable_writes增加，也就是对一个对象来写请求的时候会增加unstable_write在看一下读请求

  • 在execute_ctx里面有如下代码
    1
    2
    3
    4
    5
    6
    7
    8
    9
    void PrimaryLogPG::execute_ctx(OpContext *ctx)
    {
      ....
      if (op->may_read()) {
        dout(10) << " taking ondisk_read_lock" << dendl;
        obc->ondisk_read_lock();
      }
      ....
    }

如果是读请求会申请ondisk_read_lock

1
2
3
4
5
6
7
8
9
void ondisk_read_lock() {
   lock.Lock();
   readers_waiting++;
   while (unstable_writes)
     cond.Wait(lock);
   readers_waiting--;
   readers++;
   lock.Unlock();
 }

这个ondisk_read_lock会在unstable_writes不为0的时候进行条件变量的阻塞，

  • 而unstable_writes减少是在issue_repop的这个回调中
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    void PrimaryLogPG::issue_repop(RepGather *repop, OpContext *ctx)
    {
      ...
      Context *on_all_commit = new C_OSD_RepopCommit(this, repop);
     Context *on_all_applied = new C_OSD_RepopApplied(this, repop);
     Context *onapplied_sync = new C_OSD_OndiskWriteUnlock(
       ctx->obc,
       ctx->clone_obc,
       unlock_snapset_obc ? ctx->snapset_obc : ObjectContextRef());
      ...
    }

C_OSD_OndiskWriteUnlock中回调进行ondisk_write_unlock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class PrimaryLogPG::C_OSD_OndiskWriteUnlock : public Context {
  ObjectContextRef obc, obc2, obc3;
  public:
  C_OSD_OndiskWriteUnlock(
    ObjectContextRef o,
    ObjectContextRef o2 = ObjectContextRef(),
    ObjectContextRef o3 = ObjectContextRef()) : obc(o), obc2(o2), obc3(o3) {}
  void finish(int r) override {
    obc->ondisk_write_unlock();
    if (obc2)
      obc2->ondisk_write_unlock();
    if (obc3)
      obc3->ondisk_write_unlock();
  }
};

void ondisk_write_unlock() {
  lock.Lock();
  assert(unstable_writes > 0);
  unstable_writes--;
  if (!unstable_writes && readers_waiting)
    cond.Signal();
  lock.Unlock();
}

展开全文 >>

解析bluestore onode

问题

解析bluestore模式下面的Onode

方法

1. 首先通过ceph-kv-tool获取对应的元数据

1
./bin/ceph-kvstore-tool   bluestore-kv dev/osd0 get O %7f%80%00%00%00%00%00%00%02%eaE%e1F%21tangmi%21%3d%ff%ff%ff%ff%ff%ff%ff%fe%ff%ff%ff%ff%ff%ff%ff%ffo  out /home/krunerge/onode

2. 这个获取的数据不止包括Onode，我们可以通过写时候的osd日志可以看出

1
2021-02-08 14:55:21.519947 7f5b11c7d700 20 bluestore(/data/ceph/ceph-aduit-log/Ceph/build/dev/osd0)   onode #2:ea45e146:::tangmi:head# is 506 (344 bytes onode + 2 bytes spanning blobs + 160 bytes inline extents)

这个里面有344个字节是Onode结构

3. dd获取

1
dd if=/home/krunerge/onode of=/home/krunerge/onode_tmp bs=1 count=344

4. ceph-dencoder解析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
./bin/ceph-dencoder type bluestore_onode_t import  /home/krunerge/onode_tmp decode dump_json
{
    "nid": 53306,
    "size": 131072,
    "attrs": {
        "attr": {
            "name": "_",
            "len": 261
        },
        "attr": {
            "name": "snapset",
            "len": 35
        }
    },
    "flags": "",
    "extent_map_shards": [],
    "expected_object_size": 0,
    "expected_write_size": 0,
    "alloc_hint_flags": 0
}

展开全文 >>

解析Ceph pglog条目

问题

今天主要分析一下如何记下OSD的pg_log_entry, 我们只要pg_log是存在osd的radosdb里面的那如何去反序列化解析出来

方法

1. 用ceph-kvstore-tool导出pglog条目信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# ceph-kvstore-tool   rocksdb dev/osd0/current/omap/ list

.....
_USER_0000000000000041_USER_	0000000029.00000000000000000130
_USER_0000000000000041_USER_	0000000029.00000000000000000131
_USER_0000000000000041_USER_	0000000029.00000000000000000132
_USER_0000000000000041_USER_	0000000029.00000000000000000133
_USER_0000000000000041_USER_	0000000030.00000000000000000134
_USER_0000000000000041_USER_	0000000030.00000000000000000135
_USER_0000000000000041_USER_	0000000030.00000000000000000136
_USER_0000000000000041_USER_	0000000030.00000000000000000137
_USER_0000000000000041_USER_	0000000030.00000000000000000138
_USER_0000000000000041_USER_	0000000030.00000000000000000139
_USER_0000000000000041_USER_	0000000031.00000000000000000140
_USER_0000000000000041_USER_	0000000031.00000000000000000141
_USER_0000000000000041_USER_	0000000031.00000000000000000142
_USER_0000000000000041_USER_	0000000031.00000000000000000143
_USER_0000000000000041_USER_	0000000031.00000000000000000144
_USER_0000000000000041_USER_	0000000031.00000000000000000145
_USER_0000000000000041_USER_	0000000031.00000000000000000146
_USER_0000000000000041_USER_	0000000031.00000000000000000147
_USER_0000000000000041_USER_	0000000031.00000000000000000148
_USER_0000000000000041_USER_	0000000031.00000000000000000149
_USER_0000000000000041_USER_	0000000031.00000000000000000150
_USER_0000000000000041_USER_	0000000031.00000000000000000151
_USER_0000000000000041_USER_	0000000032.00000000000000000152
_USER_0000000000000041_USER_	0000000032.00000000000000000153
_USER_0000000000000041_USER_	0000000032.00000000000000000154
.....

这些每一个条目对应一个pglog条目，就是所谓的pg_log_entry，我们取一个147进行解析，先导出

1
ceph-kvstore-tool   rocksdb dev/osd0/current/omap/ get _USER_0000000000000041_USER_ 0000000031.00000000000000000147 out /home/krunerge/0000000031.00000000000000000147

2. 查看二进制内容

1
2
[root@ceph /data/ceph/ceph-aduit-log/Ceph/build]# ll /home/krunerge/0000000031.00000000000000000147
-rw-r--r-- 1 root root 167 Feb 22 21:07 /home/krunerge/0000000031.00000000000000000147

167个字节，二进制内容

1
2
3
4
5
6
7
8
9
10
11
12
13
[root@ceph /data/ceph/ceph-aduit-log/Ceph/build]# hexdump -C /home/krunerge/0000000031.00000000000000000147
00000000  9f 00 00 00 0b 04 99 00  00 00 01 00 00 00 04 03  |................|
00000010  38 00 00 00 00 00 00 00  17 00 00 00 72 62 64 5f  |8...........rbd_|
00000020  68 65 61 64 65 72 2e 31  30 65 31 36 62 38 62 34  |header.10e16b8b4|
00000030  35 36 37 fe ff ff ff ff  ff ff ff a8 fc 56 eb 00  |567..........V..|
00000040  00 00 00 00 03 00 00 00  00 00 00 00 93 00 00 00  |................|
00000050  00 00 00 00 1f 00 00 00  92 00 00 00 00 00 00 00  |................|
00000060  1f 00 00 00 02 02 15 00  00 00 08 0e 11 00 00 00  |................|
00000070  00 00 00 11 00 00 00 00  00 00 00 00 00 00 00 20  |............... |
00000080  35 32 60 8d aa da 29 00  00 00 00 93 00 00 00 00  |52`...).........|
00000090  00 00 00 01 01 06 00 00  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 d5 1a b8 29                              |......)|
000000a7

前面

3. dd截取

截掉开头4个字节

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@ceph /data/ceph/ceph-aduit-log/Ceph/build]# dd if=/home/krunerge/0000000031.00000000000000000147  of=/home/krunerge/0000000031.00000000000000000147_tmp count=163 bs=1 skip=4
163+0 records in
163+0 records out
163 bytes (163 B) copied, 0.000279881 s, 582 kB/s
[root@ceph /data/ceph/ceph-aduit-log/Ceph/build]# hexdump -C /home/krunerge/0000000031.00000000000000000147_tmp
00000000  0b 04 99 00 00 00 01 00  00 00 04 03 38 00 00 00  |............8...|
00000010  00 00 00 00 17 00 00 00  72 62 64 5f 68 65 61 64  |........rbd_head|
00000020  65 72 2e 31 30 65 31 36  62 38 62 34 35 36 37 fe  |er.10e16b8b4567.|
00000030  ff ff ff ff ff ff ff a8  fc 56 eb 00 00 00 00 00  |.........V......|
00000040  03 00 00 00 00 00 00 00  93 00 00 00 00 00 00 00  |................|
00000050  1f 00 00 00 92 00 00 00  00 00 00 00 1f 00 00 00  |................|
00000060  02 02 15 00 00 00 08 0e  11 00 00 00 00 00 00 11  |................|
00000070  00 00 00 00 00 00 00 00  00 00 00 20 35 32 60 8d  |........... 52`.|
00000080  aa da 29 00 00 00 00 93  00 00 00 00 00 00 00 01  |..).............|
00000090  01 06 00 00 00 00 00 00  00 00 00 00 00 00 00 d5  |................|
000000a0  1a b8 29                                          |..)|
000000a3

再截掉尾部4个字节

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[root@ceph /data/ceph/ceph-aduit-log/Ceph/build]# dd if=/home/krunerge/0000000031.00000000000000000147_tmp  of=/home/krunerge/0000000031.00000000000000000147_tmp2 count=159 bs=1
159+0 records in
159+0 records out
159 bytes (159 B) copied, 0.000279745 s, 568 kB/s
[root@ceph /data/ceph/ceph-aduit-log/Ceph/build]# ./bin/ceph-dencoder type pg_log_entry_t import /home/krunerge/0000000031.00000000000000000147_tmp2 decode dump_json
{
    "op": "modify",
    "object": "3:153f6ad7:::rbd_header.10e16b8b4567:head",
    "version": "31'147",
    "prior_version": "31'146",
    "reqid": "client.4366.0:17",
    "extra_reqids": [],
    "mtime": "2021-02-21 18:25:36.702196",
    "return_code": 0,
    "mod_desc": {
        "object_mod_desc": {
            "can_local_rollback": false,
            "rollback_info_completed": false,
            "ops": []
        }
    }
}

展开全文 >>

cephx切换

Cephx在线关闭问题

  • 1.关闭cephx需要重启啥操作
    (1) 修改配置文件
    1
    2
    3
    auth cluster required = none
    auth service required = none
    auth client required = none

(2) 重启服务
先重启mon，在重启osd

  • 2.存量问题
    2.1 新的客户端没有问题
    2.2 已经打开的客户端会有问题
    读写会卡主，现象,原因分析
    （1）客户端跟mon的conn会mark down，建立新的连接，然后auth认证返回95错误
    （2）客户端跟osd的conn不会mark down，会报address错误，因为原来osd的进程id和现在的进程id不一样，所以一直在重试
    ps：
    1.正常的情况（不切cephx）osd重启为什么没有错误，正常的osd重启也一直有osd的进程id和现在的进程id，但是osd的重启会更新osdmap，mon会给客户端发送osdmap（客户端订阅了），在客户端处理handle_osdmap的流程里面有对address改变的处理，会close_session，然后会mark down连接
    而在改了cephx之后，mon已经不能发送osdmap给客户端了

2.mon会什么conn会重建呢，因为monclient客户端有一个tick操作

1
2
3
4
5
6
7
8
9
10
void MonClient::_reopen_session(int rank)
{
  assert(monc_lock.is_locked());
  ldout(cct, 10) << __func__ << " rank " << rank << dendl;

  active_con.reset();
  pending_cons.clear();

  _start_hunting();
}

pending_cons.clear()这个会释放掉对象

1
2
3
4
5
6
7
MonConnection::~MonConnection()
{
  if (con) {
    con->mark_down();
    con.reset();
  }
}

这个会调用mark_down

展开全文 >>

Rbd快照数据一致性浅析

导语

快照一般是指数据存储的某一时刻的状态记录，类似于给数据按下快门拍了一张照片，所以也叫snapshot。而存储系统的快照在云计算中广泛使用，比如块存储的快照。很多其他高级功能基本都要依赖快照来实现，比如备份、热迁移等。而对于快照，我们经常会问的一个问题就是快照的数据是不是完整的，会不会出现快照回滚之后数据丢失。其实这也就是我们常说的快照数据一致性问题。

下面主要分以下几点进行讨论:
(1) 一致性的分类
(2) Ceph中一致性的实现

下面开始介绍

一致性分类

快照这里我们主要是讲用在虚拟机块存储上的快照，首先看一下下面张图，
1
从上面的图可以看出，我们的数据会进过应用层、文件系统层最后到达块设备层。每个层次可能会有一部分缓存，比如应用层里面的程序会有读写缓存，文件系统层会有page cache，块设备层有块设备的缓存。
根据这三层一致性主要分为以下几种：
（1）奔溃一致性快照
奔溃一致性其实没有做特殊的保障，这时候快照存储的数据就相当于虚拟机突然掉电时候块设备上存储的数据状态，对于我们云计算中的块存储可能上图中的三个层中的缓存脏数据都没有刷到块设备。

（2）文件系统一致性快照
文件系统一致性快照是在做快照前，文件系统被暂时冻结，文件系统层的缓存脏数据刷到块设备中。冻结用于拒绝用户层应用的IO请求。

（3）应用一致性快照
应用一致性快照是在做快照前，应用被暂时冻结，并把应用层缓存的脏数据刷到块存储
从上面三种快照一致性的分离中我们发现我们没有对块设备的缓存持久化进行归类，其实根据不同的存储系统有些可以归到奔溃一致性快照里面。
这里我们不细介绍应用层和文件系统层了，主要极少一下存储系统块设备层的数据快照一致性做法，下面我们来看看Ceph中的rbd块设备是如何维护着一致性的。

Rbd的快照

在做块存储快照的时候，我们最希望的就是rbd快速没有io在过来、内部飞行的io都出来回调完成、rbd缓存中的脏数据都已经刷到磁盘上，那这时候做快照，无论使用什么姿势，数据肯定是完整没问题的。我们看一下rbd快照前做了什么，如下是12.2.10 L版的代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
*            <start>
*               |
*               v
*           STATE_SUSPEND_REQUESTS
*               |
*               v
*           STATE_SUSPEND_AIO * * * * * * * * * * * * *
*               |                                     *
*               v                                     *
*           STATE_APPEND_OP_EVENT (skip if journal    *
*               |                  disabled)          *
*   (retry)     v                                     *
*   . . . > STATE_ALLOCATE_SNAP_ID                    *
*   .           |                                     *
*   .           v                                     *
*   . . . . STATE_CREATE_SNAP * * * * * * * * * *     *
*               |                               *     *
*               v                               *     *
*           STATE_CREATE_OBJECT_MAP (skip if    *     *
*               |                    disabled)  *     *
*               |                               *     *
*               |                               v     *
*               |              STATE_RELEASE_SNAP_ID  *
*               |                     |               *
*               |                     v               *
*               \----------------> <finish> < * * * * *

可以看到在做快照前做了两个动作suspend_requests和suspend_aio，其中suspend_requests就是挂住io，阻塞请求进来，那suspend_aio是什么呢？其实qemu在使用librbd读写数据的时候都是使用的异步接口进行读写，所以这里的aio就是在librbd中飞行的io，简而言之就是要把飞行的io运行完落盘而不是挂住，那这和我们上面希望的是差不多，让我们在仔细分析一下这个两个动作是怎么做到的。

1. suspend_requests阻塞请求

阻塞请求，因为librbd里面有请求队列，那简单的做法就是在出队列的时候卡主，不让io出队列运行，其实这里的io主要是对写io，读io的写法不会修改数据所以不会出现数据的不一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template <typename I>
void ImageRequestWQ<I>::block_writes(Context *on_blocked) {
  assert(m_image_ctx.owner_lock.is_locked());
  CephContext *cct = m_image_ctx.cct;

  {
    RWLock::WLocker locker(m_lock);
    ++m_write_blockers; //write blocker计数增加
    ...
    }
  }

  ...
}

上面的函数就是阻塞写请求，有一个m_write_blockers计数器，每block一次，计数器增加1，那这个计数器在哪里使用呢？下面这个是请求出队列的地方

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
template <typename I>
void *ImageRequestWQ<I>::_void_dequeue() {
  ...

  bool lock_required;
  bool refresh_required = m_image_ctx.state->is_refresh_required();
  {
    RWLock::RLocker locker(m_lock);
    bool write_op = peek_item->is_write_op();
    lock_required = is_lock_required(write_op);
    if (write_op) {
      if (!lock_required && m_write_blockers > 0) { // 不出队列
        // missing lock is not the write blocker
        return nullptr;
      }

      ...
    }
  }

...
}

上面出队列的时候对请求判断了一下，如果是写请求，并且m_write_blockers大于0，请求就不处理了，这样就对所有的写请求不出队列处理了。

2. suspend_aio刷飞行io

飞行io就是正在运行的io，这里我们也只需要考虑写io，这些io操作都在运行中，数据可能还没有完全落盘，看一下rbd是不是这样呢？下面还是block_write函数

1
2
3
4
5
6
void ImageRequestWQ<I>::block_writes(Context *on_blocked) {
  ...

  // ensure that all in-flight IO is flushed
  m_image_ctx.flush(on_blocked);
}

可以看到是通过image上下文的flush在加了一个on_blocked，这个on_blocked是一个条件变量

1
2
3
4
5
int ImageRequestWQ<I>::block_writes() {
  C_SaferCond cond_ctx;
  block_writes(&cond_ctx); //阻塞在这了
  return cond_ctx.wait();
}

也就是通过这个条件变量阻塞在这儿了，等待飞行io的运行完。我们看一下image上下文的flush待着这个条件变量做了啥？

1
2
3
4
5
6
7
8
9
10
11
void ImageCtx::flush(Context *on_safe) {
    // ensure no locks are held when flush is complete
    ...
    // 块设备缓存flush
    if (object_cacher != NULL) {
      // flush cache after completing all in-flight AIO ops
      on_safe = new C_FlushCache(this, on_safe);
    }
    // flush异步操作
    flush_async_operations(on_safe);
  }

可以看出这里除了等待异步飞行io的完成还根据rbd是否开启缓存进行rbd cache的脏数据下刷。rbd cache是基于多条LRU构造的，根据LRU缓存算法镜像flush，这里不多介绍，下面看一下异步操作是如何flush的。

1
2
3
4
5
6
7
8
9
10
11
12
void ImageCtx::flush_async_operations(Context *on_finish) {
    {
      Mutex::Locker l(async_ops_lock);
      if (!async_ops.empty()) {
        ldout(cct, 20) << "flush async operations: " << on_finish << " "
                       << "count=" << async_ops.size() << dendl;
        async_ops.front()->add_flush_context(on_finish);
        return;
      }
    }
    on_finish->complete(0);
  }

这里的async_ops一个异步操作的链表，关键是下面这一行

1
async_ops.front()->add_flush_context(on_finish);

在异步操作链表的第一个异步请求上面增加了一个on_finish，这个就是我们之前条件变量回调的触发，这个一回调，上面卡住的地方就可以继续往下运行。我用下图示意
2
各个异步操作完成时间各不相同，那看一下异步操作链表的操作
3
从上面示意图可以看出，on_finish一直挂在链表第一个异步操作上面，知道所有的异步操作完成，会触发回调，解除卡住，也就达到了flush异步操作的目的。

这样上面就已经介绍了block写请求、flush飞行io、flush rbd缓存。在这种状态下，我们怎么做快照都是数据完整的，但是这个完整还是只针对块设备，还没有包括应用层和文件系统层。Ceph有对这种进行处理吗？

在最近的提交中我看到了这个commit

1
librbd: API for quiesce callbacks

增加了静默的回调，什么意识？再看一下做快照的导图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
*            <start>
*               |
*               v
*           STATE_NOTIFY_QUIESCE
*               |
*               v
*           STATE_SUSPEND_REQUESTS
*               |
*               v
*           STATE_SUSPEND_AIO * * * * * * * * * * * * * * *
*               |                                         *
*               v                                         *
*           STATE_APPEND_OP_EVENT (skip if journal        *
*               |                  disabled)              *
*   (retry)     v                                         *
*   . . . > STATE_ALLOCATE_SNAP_ID                        *
*   .           |                                         *
*   .           v                                         *
*   . . . . STATE_CREATE_SNAP * * * * * * * * * * *       *
*               |                                 *       *
*               v                                 *       *
*           STATE_CREATE_OBJECT_MAP (skip if      *       *
*               |                    disabled)    *       *
*               v                                 *       *
*           STATE_CREATE_IMAGE_STATE (skip if     *       *
*               |                     not mirror  *       *
*               |                     snapshot)   *       *
*               |                                 v       *
*               |              STATE_RELEASE_SNAP_ID      *
*               |                     |                   *
*               |                     v                   *
*               \------------> STATE_NOTIFY_UNQUIESCE < * *
*                                     |
*                                     v
*                                  <finish>

可以看到增加了notify_quiesce,通知静默，看了一下代码其实就是用户可以提前注册好一个回调，在做快照的时候可以触发这个回调，嗯，这个回调做什么用呢，聪明的你想想，对啊，就是可以做应用层和文件系统层的相关一致性操作，可以通过回调触发一些命令行或者脚本来做一些在块设备上层的刷数据。Good！！！

到这里大致就介绍完了快照一致性，大家可以再花几秒钟回顾一下。

参考资料

https://blog.csdn.net/zhouxukun123/article/details/75093978

展开全文 >>

debug ceph

centos安装clion

  • 1.安装jdk

    1
    yum install java-1.8.0-openjdk

  • 2.DISPLAY

    1
    export DISPLAY=:0

  • 3.X11

1
2
3
4
5
6
7
8
9
10
11
vi /etc/ssh/sshd_config
    配置：X11Forwarding yes
    然后重启服务service sshd restart

然后确保xshell客户端配置为：
    属性-连接-SSH-隧道：
    X11转移-（选中）转发X11连接到-（选中）Xmanager

然后打开xshell会话后：
    echo $DISPLAY 查看是有值的
    此时直接运行脚本可以打开程序GUI界面

展开全文 >>

tcmu-runner编译

tcmu-runner编译

之前使用的是tcmu-runner的1.3.0版本，看了一下github上面最新的是1.5.2准备拿来更新一下，看看有没有什么性能的优化

源码编译

  • 1.下载源码包
    这个可以直接在github上面下载
  • 2.编译有问题
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    [root@master ~/tcmu-runner/tcmu-runner-1.5.2]# make
    [  2%] Building C object CMakeFiles/tcmu.dir/libtcmu.c.o
    /root/tcmu-runner/tcmu-runner-1.5.2/libtcmu.c:38:37: error: 'NLA_S32' undeclared here (not in a function)
      [TCMU_ATTR_CMD_STATUS] = { .type = NLA_S32 },
                                         ^
    /root/tcmu-runner/tcmu-runner-1.5.2/libtcmu.c: In function 'send_netlink_reply':
    /root/tcmu-runner/tcmu-runner-1.5.2/libtcmu.c:100:2: error: implicit declaration of function 'nla_put_s32' [-Werror=implicit-function-declaration]
      ret = nla_put_s32(msg, TCMU_ATTR_CMD_STATUS, status);
      ^
    cc1: all warnings being treated as errors
    make[2]: *** [CMakeFiles/tcmu.dir/libtcmu.c.o] Error 1
    make[1]: *** [CMakeFiles/tcmu.dir/all] Error 2
    make: *** [all] Error 2

说没有NLA_S32和nla_put_s32定义，看了一下代码，有头文件导入

1
2
3
#include <libnl3/netlink/genl/genl.h>
#include <libnl3/netlink/genl/mngt.h>
#include <libnl3/netlink/genl/ctrl.h>

在系统头文件/usr/include进行搜索，发现应该在这个文件中

1
/usr/include/libnl3/netlink/attr.h

但是没有，该开始以为是内核的头文件，后来看一下是

1
2
[root@master ~/tcmu-runner/tcmu-runner-1.5.2]# rpm -qf  /usr/include/libnl3/netlink/attr.h
libnl3-devel-3.2.28-4.el7.x86_64

是这个包libnl3-devel版本有点低，代码中没有定义NLA_S32，这个是一个无符号32位，所以升级，上面的3.2.28便是我升级后的版本

  • 3.编译
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    [root@master ~/tcmu-runner/tcmu-runner-1.5.2]# make
    [  2%] Generating tcmuhandler-generated.c, tcmuhandler-generated.h
    Scanning dependencies of target tcmu
    [  5%] Building C object CMakeFiles/tcmu.dir/strlcpy.c.o
    [  7%] Building C object CMakeFiles/tcmu.dir/configfs.c.o
    [ 10%] Building C object CMakeFiles/tcmu.dir/api.c.o
    [ 12%] Building C object CMakeFiles/tcmu.dir/libtcmu.c.o
    [ 15%] Building C object CMakeFiles/tcmu.dir/libtcmu-register.c.o
    [ 17%] Building C object CMakeFiles/tcmu.dir/tcmuhandler-generated.c.o
    [ 20%] Building C object CMakeFiles/tcmu.dir/libtcmu_log.c.o
    [ 23%] Building C object CMakeFiles/tcmu.dir/libtcmu_config.c.o
    [ 25%] Building C object CMakeFiles/tcmu.dir/libtcmu_time.c.o
    Linking C shared library libtcmu.so
    [ 25%] Built target tcmu
    [ 28%] Building C object CMakeFiles/consumer.dir/scsi.c.o
    [ 30%] Building C object CMakeFiles/consumer.dir/consumer.c.o
    Linking C executable consumer
    [ 30%] Built target consumer
    [ 33%] Building C object CMakeFiles/handler_file.dir/file_example.c.o
    Linking C shared library handler_file.so
    [ 33%] Built target handler_file
    [ 35%] Building C object CMakeFiles/handler_file_optical.dir/scsi.c.o
    [ 38%] Building C object CMakeFiles/handler_file_optical.dir/file_optical.c.o
    Linking C shared library handler_file_optical.so
    [ 38%] Built target handler_file_optical
    [ 41%] Building C object CMakeFiles/handler_file_zbc.dir/scsi.c.o
    [ 43%] Building C object CMakeFiles/handler_file_zbc.dir/file_zbc.c.o
    Linking C shared library handler_file_zbc.so
    [ 43%] Built target handler_file_zbc
    [ 46%] Building C object CMakeFiles/handler_rbd.dir/rbd.c.o
    Linking C shared library handler_rbd.so
    [ 46%] Built target handler_rbd
    Scanning dependencies of target tcmu-runner
    [ 48%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_cmd_handler.c.o
    [ 51%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_aio.c.o
    [ 53%] Building C object CMakeFiles/tcmu-runner.dir/tcmur_device.c.o
    [ 56%] Building C object CMakeFiles/tcmu-runner.dir/target.c.o
    [ 58%] Building C object CMakeFiles/tcmu-runner.dir/alua.c.o
    [ 61%] Building C object CMakeFiles/tcmu-runner.dir/scsi.c.o
    [ 64%] Building C object CMakeFiles/tcmu-runner.dir/main.c.o
    [ 66%] Building C object CMakeFiles/tcmu-runner.dir/tcmuhandler-generated.c.o
    Linking C executable tcmu-runner
    [ 69%] Built target tcmu-runner
    [ 71%] Building C object CMakeFiles/tcmu-synthesizer.dir/scsi.c.o
    [ 74%] Building C object CMakeFiles/tcmu-synthesizer.dir/tcmu-synthesizer.c.o
    Linking C executable tcmu-synthesizer
    [ 74%] Built target tcmu-synthesizer
    Scanning dependencies of target tcmu_static
    [ 76%] Building C object CMakeFiles/tcmu_static.dir/strlcpy.c.o
    [ 79%] Building C object CMakeFiles/tcmu_static.dir/configfs.c.o
    [ 82%] Building C object CMakeFiles/tcmu_static.dir/api.c.o
    [ 84%] Building C object CMakeFiles/tcmu_static.dir/libtcmu.c.o
    [ 87%] Building C object CMakeFiles/tcmu_static.dir/libtcmu-register.c.o
    [ 89%] Building C object CMakeFiles/tcmu_static.dir/tcmuhandler-generated.c.o
    [ 92%] Building C object CMakeFiles/tcmu_static.dir/libtcmu_log.c.o
    [ 94%] Building C object CMakeFiles/tcmu_static.dir/libtcmu_config.c.o
    [ 97%] Building C object CMakeFiles/tcmu_static.dir/libtcmu_time.c.o
    Linking C static library libtcmu_static.a
    [100%] Built target tcmu_static

make一下编译完成

更新二进制

ldd和pldd看一下tcmu-runner二进制和进程依赖哪些动态库，发现有libtcmu.so和handler_rbd.so，所以替换这两个动态库加上tcmu-runner二进制就可以

展开全文 >>

频繁的创建删除快照导致OSD启动很慢

一.问题

最近有一个环境出现OSD启动很慢，要40多分钟，很奇怪，看一下osd的日志发现一直在刷类似下面的日志

1
2020-04-05 19:52:59.925 7fa86b863700 20 PGPool::update cached_removed_snaps [1~f5,f7~1,f9~7,101~1,103~12d,233~ea,31e~1,320~64,385~1e,3a4~16b,510~7e,58f~4e,5de~49,629~8,632~28,65b~31,68e~a,699~c,6a6~6,6ae~38,6e8~27,711~2a,73c~1d,75a~34,790~4,795~17,7ad~22,7d1~10,7e2~41,824~28,84d~23,871~53,8c5~17,8de~18,8fa~42,93d~a,949~10,95a~a,965~32,999~1e,9b8~6,9bf~32,9f3~e,a02~40,a46~d,a54~9,a62~279,cdc~12b,e09~26,e30~2,e33~d,e42~e,e51~a,e5d~8,e67~4,e6c~1e,e8d~1b,ea9~1,eab~3,eaf~24,ed4~aa,f7f~35,fb6~4,fbc~c,fc9~c1,108b~5c,10e8~8,10f4~59,114f~4,1154~27,117c~1,117e~2,1181~2a,11ac~26,11d4~4,11d9~22,11fd~4,1202~58,125c~8,1265~2,1268~16,127f~40] newly_removed_snaps [] snapc 12be=[] (no change)

这个只是一个小环境上面的，真实环境上面上面的一条日志记录占了显示屏的两页，这是什么？我是谁，我在哪里，我要干什么？好吧，出现了关键字snap，感觉跟快照有点关系。下面分析一下

二.实验

分析这个问题，首先我们要知道上面的一坨类似1-f5的是什么，我们先来做个试验，在我的一个开发环境模拟一下创建快照和删除快照到底发生了什么，Let go

  • 1.创建一个池test

    1
    ceph osd pool create test 16 16

  • 2.创建两个卷test1和test2

    1
    2
    [root@openstack-ceph01 ~]# rbd create test/test1 --size 1G
    [root@openstack-ceph01 ~]# rbd create test/test2 --size 1G

  • 3.创建快照前观察一下OSDMap版本

    1
    2
    3
    [root@openstack-ceph01 ~]# ceph osd dump
    epoch 23303
    ...

osdmap的版本是23303,下面我们给test1创建一个快照snap4,至于为什么叫snap4，等话就知道

  • 4.test1创建快照snap4
    1
    [root@openstack-ceph01 ~]# rbd snap create test/test1@snap4

查看一下快照信息

1
2
3
[root@openstack-ceph01 ~]# rbd snap ls test/test1
SNAPID NAME  SIZE  PROTECTED TIMESTAMP                
     4 snap4 1 GiB           Sun Apr  5 20:29:12 2020

快照id是4，不是从1或者0开始，这就是为什么我们创建快照的时候取名叫snap4，再看一下osdmap版本

1
2
3
[root@openstack-con01 ceph(keystone_admin)]# ceph osd dump
epoch 23304
...

版本变成了23304，也就是说创建快照osdmap版本会变化，为什么创建快照osdmap版本会变化呢，我等话解释，既然osdmap变化了，那我们看看osdmap到底变化了什么，对，你跟我想的一眼，查看一下osdmap的增量变化以及全量变化，我们知道osdmap变化之后会mon通知给osd，那我们去osd的数据目录下面meta目录看一下osdmap

1
2
3
[root@openstack-ceph01 meta]# find . -name *osdmap.23304*
./DIR_9/DIR_A/osdmap.23304__0_4EBB24A9__none
./DIR_E/DIR_0/inc\uosdmap.23304__0_46AAFD0E__none

由于分目录保存，所以使用上面查找，找到之后使用ceph-dencoder反序列化一下，因为这个里面存储的OSDMap或者OSDMap::Incremental类实例的序列化结果,让我们先看一下osdmap增量

  • 4.1 osdmap增量
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    [root@openstack-ceph01 meta]# ceph-dencoder type OSDMap::Incremental import ./DIR_E/DIR_0/inc\\uosdmap.23304__0_46AAFD0E__none decode dump_json
    {
        "epoch": 23304,
        ...
        "new_pools": [
            {
                ....
                "pool": 30,
                "snap_mode": "selfmanaged",
                "snap_seq": 4,
                "snap_epoch": 23304,
                "pool_snaps": [],
                "removed_snaps": "[1~3]",
                ...
            }
        ...
    }

我们只关注快照相关的信息，可以看到，主要有上面的5个字段，快照seq是4，快照模式是selfmanaged，removed_snaps

  • 4.2 快照模式
    我们知道ceph的快照有两种模式，一种是对池对快照，一种就是这里的selfmanaged，也就是我们常用的对rbd卷的快照，ceph为了代码兼容处理这两种快照,把快照属性放在了pool池上面，快照作为池的一个特性，而pool的变化是要记录在osdmap里面的，因为客户端端在通过crush进行osd计算的时候需要通过找到池的相应信息，所以这里就解释了为什么创建快照osdmap版本会变化，因为pool变化了，上面是osdmap的增量数据，我们再看一下osdmap的全量数据，

  • 4.3 osdmap全量

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    [root@openstack-ceph01 meta]# ceph-dencoder type OSDMap import ./DIR_9/DIR_A/osdmap.23304__0_4EBB24A9__none decode dump_json
    {
        "epoch": 23304,
        ...
        "pools": [
            ...
            {
                "pool": 30,
                ...
                "snap_mode": "selfmanaged",
                "snap_seq": 4,
                "snap_epoch": 23304,
                "pool_snaps": [],
                "removed_snaps": "[1~3]",
                ...
            }
        ...
    }

可以看到快照部分增量和全量是一样的

  • 4.4 快照id在pool内部全局唯一
    我们继续给test2创建快照snap5，在给test1创建快照snap6，看这名字聪明的你就知道我要做什么了，看一下操作结果
    1
    2
    3
    4
    5
    6
    7
    8
    9
    [root@openstack-ceph01 meta]# rbd snap create  test/test2@snap5
    [root@openstack-ceph01 meta]# rbd snap ls test/test2
    SNAPID NAME  SIZE  PROTECTED TIMESTAMP                
         5 snap5 1 GiB           Sun Apr  5 20:50:44 2020
    [root@openstack-ceph01 meta]# rbd snap create  test/test1@snap6
    [root@openstack-ceph01 meta]# rbd snap ls test/test1
    SNAPID NAME  SIZE  PROTECTED TIMESTAMP                
         4 snap4 1 GiB           Sun Apr  5 20:29:12 2020
         6 snap6 1 GiB           Sun Apr  5 20:51:16 2020

可以从结果看到，看这id是从4开始，1、2、3快照id好像被预留了，而且一个池内所有卷的快照的id是单调递增的。这是我们再看一下osdmap

1
2
3
[root@openstack-ceph01 meta]# ceph osd dump
epoch 23306
...

osdmap已经是23306，版本增加了2，因为创建了两次快照，再看一下osdmap增量信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@openstack-ceph01 meta]# ceph-dencoder type OSDMap::Incremental import ./DIR_E/DIR_6/inc\\uosdmap.23306__0_46AAF26E__none decode dump_json
{
    "epoch": 23306,
    ...
    "new_pools": [
        {
            "pool": 30,
            ...
            "snap_mode": "selfmanaged",
            "snap_seq": 6,
            "snap_epoch": 23306,
            "pool_snaps": [],
            "removed_snaps": "[1~3]",
            ...
       }
    ...
}

从上面看出好像就只修改了snap_seq，和snap_epoch，其他都没变，尤其是removed_snaps，这个到底是什么呢?

  • 4.5 removed_snaps是个啥
    我们前面已经知道一个池的快照id是从4开始的，1、2、3快照id是保留，或者已经删除（从这个字段的名字可以看出），那为什么要这个呢，小甲大胆猜测一下，是为了知道我现在还存在的快照的id，你看我们通过snap_seq知道最新的快照id为6，而我们通过removed_snaps知道已经删除了1-3快照id的快照，那就是说我们还有4、5、6id的快照，也就是通过排除已经删除的快照，得到还存在的快照，这个逻辑我想开发者是这么认为快照会经常打，但是删除比较少，所以通过记录删除的id反推存在的快照，这样记录的数据成本比较少，通过查看代码我发现removed_snap是一个间断集合
    1
    2
    3
    4
    5
    6
    struct PGPool {

      ...
      interval_set<snapid_t> cached_removed_snaps;
      ...
    }

学过数据集合的你看到这个会有什么反应，既然叫间断集合，那removed_snaps字段的1~3表示的应该是（start，len）也就是从id为1开始，后面连续三个id已经被删除，也就是1、2、3快照id被删除。这里还要提一下，这里的start和len是16进制显示的，比如108b~5c。

那是不是真的是这样呢，我们在给test1创建几个快照然后删除一个快照试试

    1. test1删除快照
  • 5.1 test1有创建了快照snap7，snap8，snap9三个快照
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    [root@openstack-ceph01 meta]# rbd snap create test/test1@snap7
    [root@openstack-ceph01 meta]# rbd snap create test/test1@snap8
    [root@openstack-ceph01 meta]# rbd snap create test/test1@snap9
    [root@openstack-ceph01 meta]# rbd snap ls test/test1
    SNAPID NAME  SIZE  PROTECTED TIMESTAMP                
         4 snap4 1 GiB           Sun Apr  5 20:29:12 2020
         6 snap6 1 GiB           Sun Apr  5 20:51:16 2020
         7 snap7 1 GiB           Sun Apr  5 21:14:22 2020
         8 snap8 1 GiB           Sun Apr  5 21:14:25 2020
         9 snap9 1 GiB           Sun Apr  5 21:14:36 2020

可以看到最新的快照id是9，看一下osdmap增量信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@openstack-ceph01 meta]# ceph-dencoder type OSDMap::Incremental import ./DIR_E/DIR_9/inc\\uosdmap.23309__0_46AAF19E__none decode dump_json
{
    "epoch": 23309,
    ...
    "new_pools": [
        {
            "pool": 30,
            ...
            "snap_mode": "selfmanaged",
            "snap_seq": 9,
            "snap_epoch": 23309,
            "pool_snaps": [],
            "removed_snaps": "[1~3]",
            ...
        }
    ...
}

看到removed_snaps没有变化

  • 5.2 删除test1的快照snap8
    1
    2
    3
    4
    5
    6
    7
    8
    [root@openstack-ceph01 meta]# rbd snap rm test/test1@snap8
    Removing snap: 100% complete...done.
    [root@openstack-ceph01 meta]# rbd snap ls test/test1
    SNAPID NAME  SIZE  PROTECTED TIMESTAMP                
         4 snap4 1 GiB           Sun Apr  5 20:29:12 2020
         6 snap6 1 GiB           Sun Apr  5 20:51:16 2020
         7 snap7 1 GiB           Sun Apr  5 21:14:22 2020
         9 snap9 1 GiB           Sun Apr  5 21:14:36 2020

test1的snap8快照已经删除，也就是id为8的快照删除了，在我们看osdmap增量之前，我们大胆的猜测一下removed_snaps会变成什么，我赌10块钱会变成[1~3, 8~1], 好，我们看一下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@openstack-ceph01 meta]# ceph-dencoder type OSDMap::Incremental import ./DIR_E/DIR_F/inc\\uosdmap.23310__0_46AAF6FE__none decode dump_json
{
    "epoch": 23310,
    ...
    "new_pools": [
        {
            "pool": 30,
            ...
            "snap_mode": "selfmanaged",
            "snap_seq": 10,
            "snap_epoch": 23310,
            "pool_snaps": [],
            "removed_snaps": "[1~3,8~1,a~1]",
            ...
       }
    ...
}

removed_snaps既然变成了[1~3,8~1,a~1]，其中8~1是情理之中，而a~1这个意料之外是个啥，我们知道这个是16进制，变成10进制就是10~1，也就是删除了快照id 10，快照10哪里来的，我们只创建到了快照9，咦，snap_seq竟然变成了10，嗯。。。待我冷静一下，删除快照，快照的seq变成10，增加了1，为什么？我们在品一品这个字段的名字snap_seq，seq序号，他不是id，小甲大胆猜一下，这个应该是快照的版本，创建快照和删除快照都会修改版本，而快照id只是通过版本值演变而来，这样一来就说的通了，也就是删除快照，快照版本增加，但是在removed_snaps中会把这个版本去掉，因为确实是没有这个id的快照的，既然这么说，你猜猜下面再创建一个快照，快照的id会是多少，我觉得会是11，试一下

1
2
3
4
5
6
7
8
[root@openstack-ceph01 meta]# rbd snap create test/test1@snap11
[root@openstack-ceph01 meta]# rbd snap ls test/test1
SNAPID NAME   SIZE  PROTECTED TIMESTAMP                
     4 snap4  1 GiB           Sun Apr  5 20:29:12 2020
     6 snap6  1 GiB           Sun Apr  5 20:51:16 2020
     7 snap7  1 GiB           Sun Apr  5 21:14:22 2020
     9 snap9  1 GiB           Sun Apr  5 21:14:36 2020
    11 snap11 1 GiB           Sun Apr  5 21:30:38 2020

果然如此。

通过上面的实验分析我们知道了快照的一些基本知识，也知道osd启动慢时，一直刷的那一坨是个啥，那为什么为一直刷导致osd启动慢呢？

三.分析

osd启动的时候会加载osdmap，pool、osd、快照的变化都记录在了osdmap里面，通过加载osdmap来在osd内存中构造相关的数据，大致是这个逻辑，通过代码找到打印这个日志的地方

1
2020-04-05 19:52:59.925 7fa86b863700 20 PGPool::update cached_removed_snaps [1~f5,f7~1,f9~7,101~1,103~12d,233~ea,31e~1,320~64,385~1e,3a4~16b,510~7e,58f~4e,5de~49,629~8,632~28,65b~31,68e~a,699~c,6a6~6,6ae~38,6e8~27,711~2a,73c~1d,75a~34,790~4,795~17,7ad~22,7d1~10,7e2~41,824~28,84d~23,871~53,8c5~17,8de~18,8fa~42,93d~a,949~10,95a~a,965~32,999~1e,9b8~6,9bf~32,9f3~e,a02~40,a46~d,a54~9,a62~279,cdc~12b,e09~26,e30~2,e33~d,e42~e,e51~a,e5d~8,e67~4,e6c~1e,e8d~1b,ea9~1,eab~3,eaf~24,ed4~aa,f7f~35,fb6~4,fbc~c,fc9~c1,108b~5c,10e8~8,10f4~59,114f~4,1154~27,117c~1,117e~2,1181~2a,11ac~26,11d4~4,11d9~22,11fd~4,1202~58,125c~8,1265~2,1268~16,127f~40] newly_removed_snaps [] snapc 12be=[] (no change)

代码是这个函数打印的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
void PGPool::update(OSDMapRef map)
{
  ...
  if ((map->get_epoch() != cached_epoch + 1) ||
      (pi->get_snap_epoch() == map->get_epoch())) {
    updated = true;
    pi->build_removed_snaps(newly_removed_snaps);
    interval_set<snapid_t> intersection;
    intersection.intersection_of(newly_removed_snaps, cached_removed_snaps);
    if (intersection == cached_removed_snaps) {
        newly_removed_snaps.subtract(cached_removed_snaps);
        cached_removed_snaps.union_of(newly_removed_snaps);
    } else {
        lgeneric_subdout(g_ceph_context, osd, 0) << __func__
          << " cached_removed_snaps shrank from " << cached_removed_snaps
          << " to " << newly_removed_snaps << dendl;
        cached_removed_snaps = newly_removed_snaps;
        newly_removed_snaps.clear();
    }
    snapc = pi->get_snap_context();
  } else {
    ...
    newly_removed_snaps.clear();
  }
  cached_epoch = map->get_epoch();
  lgeneric_subdout(g_ceph_context, osd, 20)
    << "PGPool::update cached_removed_snaps "
    << cached_removed_snaps
    << " newly_removed_snaps "
    << newly_removed_snaps
    << " snapc " << snapc
    << (updated ? " (updated)":" (no change)")
    << dendl;
}

上面是ceph 10.2.7版本的代码，这个函数是通过osdmap更新pool信息，在最后打印输出的上面，可以看到对removed_snaps这个间断结合做合并等操作，也就是对集合进行类似交集的操作，我之前也说启动慢的环境，removed_snaps输出的集合两页屏幕都没打印完，这是由于频繁打快照删除快照导致removed_snaps集合很大，这样集合做操作耗时会比较慢，这还只是单个osdmap操作。
我们之前启动慢的环境由于其他原因导致osd集群不断的在up和down，而我们知道这都是要修改osdmap的，这样导致我们的osdmap版本很大，这样就导致我们osd启动慢，两个原因

1
2
原因1：osdmap版本很大，要加载的osdmap很多
原因2：removed_snaps集合很大，加载一次osdmap时间很长

四.有没有什么改进方法

其实通过上面的实验发现，我们看到在创建快照的时候，其实osdmap只是修改了snap_seq,removed_snaps没有变化，只有在删除的时候removed_snaps才会改变，是不是可以去掉removed_snaps没变时osdmap的加载，嗯，好像很有道理，其实社区已经做了修改,看一下代码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
void PGPool::update(OSDMapRef map)
{
  ...
  if ((map->get_epoch() != cached_epoch + 1) ||
      (pi->get_snap_epoch() == map->get_epoch())) {
    updated = true;
    if (pi->maybe_updated_removed_snaps(cached_removed_snaps)) {  // 加了判断removed_snaps集合是否变化，没变化不做集合操作
      pi->build_removed_snaps(newly_removed_snaps);
      interval_set<snapid_t> intersection;
      intersection.intersection_of(newly_removed_snaps, cached_removed_snaps);
      if (intersection == cached_removed_snaps) {
          cached_removed_snaps.swap(newly_removed_snaps);
          newly_removed_snaps = cached_removed_snaps;
          newly_removed_snaps.subtract(intersection);
      } else {
          lgeneric_subdout(cct, osd, 0) << __func__
            << " cached_removed_snaps shrank from " << cached_removed_snaps
            << " to " << newly_removed_snaps << dendl;
          cached_removed_snaps.swap(newly_removed_snaps);
          newly_removed_snaps.clear();
      }
    } else
      newly_removed_snaps.clear();
    snapc = pi->get_snap_context();
  } else {
    ....
    newly_removed_snaps.clear();
  }
  cached_epoch = map->get_epoch();
  lgeneric_subdout(cct, osd, 20)
    << "PGPool::update cached_removed_snaps "
    << cached_removed_snaps
    << " newly_removed_snaps "
    << newly_removed_snaps
    << " snapc " << snapc
    << (updated ? " (updated)":" (no change)")
    << dendl;
}

maybe_updated_removed_snaps这个判断removed_snaps集合是否变化

1
2
3
4
5
6
7
8
9
bool pg_pool_t::maybe_updated_removed_snaps(const interval_set<snapid_t>& cached) const
{
  if (is_unmanaged_snaps_mode()) { // remove_unmanaged_snap increments range_end
    if (removed_snaps.empty() || cached.empty()) // range_end is undefined
      return removed_snaps.empty() != cached.empty();
    return removed_snaps.range_end() != cached.range_end();
  }
  return true;
}

上面是ceph 12.2.10版本加了判断removed_snaps集合是否变化，没变化不做集合操作

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

鹅厂小猿一枚<br> 记录成长点滴 <br>