Ceph蹚坑笔记 - (4)

Ceph蹚坑笔记 - (4)

radosgw-admin bucket stats显示错误max-marker

详见http://tracker.ceph.com/issues/12232
不过，好像没人理的样子…

某些RESTful API中的内存越界问题

radosgw-agent在进行数据同步时，为了防止多进程的竞争，会对datalog相应分片加锁。datalog分片编号的取值范围是从Master Zone获取的，但加锁的API却需要发往Slave Zone，对Slave Zone中对应的分片进行加锁。所以，如果Master Zone所配置的的datalog分片数（由rgw_data_log_num_shards配置）大于Slave Zone的datalog的分片数，以下代码对数组oids（其大小由rgw_data_log_num_shards控制）的访问就会发生内存越界，使Slave Zone的RGW异常退出：

class RGWDataChangesLog {

  int lock_exclusive(int shard_id, utime_t& duration, string& zone_id, string& owner_id) {
    return store->lock_exclusive(store->zone.log_pool, oids[shard_id], duration, zone_id, owner_id);
  }
  int unlock(int shard_id, string& zone_id, string& owner_id) {
    return store->unlock(store->zone.log_pool, oids[shard_id], zone_id, owner_id);
  }

}

radosgw-agent中锁的标识问题

radosgw-agent会向RGW发出一些RESTful API进行锁操作，这些锁操作在OSD这一层面是由cls_lock.cc实现。通过走读代码可以发现，一个锁由locker和cookie唯一标识。对于radosgw-agent的场景，locker就是接收这个API的RGW的ID，cookie是由radosgw-agent根据自己的IP和进程号构造的。
如果radosgw-agent X通过RGW-A进行了加锁操作，这个锁就的标识可记为(RGW-A, cookie-X)。如果同一个radosgw-agent X改向RGW-B发出请求，要将刚才所加的锁解除，那么OSD就会试图处理(RGW-B, cookie-X)，cls_lock.cc中的remove_lock()就会返回-ENOENT错误。
使用单个RGW时，不会有这个问题。但如果在多个RGW前面挡一个用于负载均衡的反向代理，这种问题就出现了。这时，radosgw-agent就不能正常工作了。