前言ceph的s3数据的同步可以通过radosgw-agent进行同步，同region可以同步data和metadata，不同region只能同步metadata，这个地方可以参考下秦牧羊梳理的 ceph radosgw 多集群同步部署流程，本篇讲述的方案与radosgw-agent的复制方案不同在于,这个属于前端复制，后端相当于透明的两个相同集群，在入口层面就将数据进行了复制分流 在某些场景下，

前言这个问题在很久以前就有一篇文章进行过讨论 remove-big-rbd,这个文章写的比较清楚了，并且对不同的方法做了分析，这里先把结论说下 rbd类型 rbd rm 方法 rados -p rm方法 未填充很多 慢 快 已填充很多 快 慢 在rbd进行删除的时候，即使内部没有对象数据，也一样需要一个个对象去发请求，即使对象不存在，这个可以开日志看到 实验过程开启日志的方

前言之前有个想法，是不是有办法找到rbd中的文件与对象的关系，想了很久但是一直觉得文件系统比较复杂，在fs 层的东西对ceph来说是透明的，并且对象大小是4M，而文件很小，可能在fs层进行了合并，应该很难找到对应关系，最近看到小胖有提出这个问题，那么就再次尝试了，现在就是把这个实现方法记录下来 这个提取的作用个人觉得最大的好处就是一个rbd设备，在文件系统层被破坏以后，还能够从rbd提取出文件，

前言性能优化大神Brendan Gregg发明了火焰图来定位性能问题，通过图表就可以发现问题出在哪里，通过svg矢量图来查看性能卡在哪个点，哪个操作占用的资源最多 在查看了原始数据后，这个分析的原理是按层级来对调用进行一个计数，然后以层级去做比对，来看横向的占用的比例情况 基于这个原理，把osd tree的数据和pg数据可以做一个层级的组合，从而可以很方便的看出pg的分布情况，主机的分布情况，还可

前言文件系统当中如果某些文件不见了，有什么办法判断是删除了还是自己不见了，这个就需要去日志里面定位了，通常情况下是去翻日志，而日志是会进行压缩的，并且查找起来非常的不方便,还有可能并没有开启 这个时候就需要日志系统了，最近正好看到一篇最佳日志实践（v2.0），一篇非常好的文章，本篇日志属于文章里面所提到的统计日志，统计客户端做了什么操作 对于日志系统来说，很重要的一点，能够很方便的进行查询，这就需

前言本篇是luminous一个新功能介绍，关于磁盘智能分组的，这个在ceph里面叫crush class，这个我自己起名叫磁盘智能分组，因为这个实现的功能就是根据磁盘类型进行属性关联，然后进行分类，减少了很多的人为操作 以前我们需要对ssd和hdd进行分组的时候，需要大量的修改crush map，然后绑定不同的存储池到不同的 crush 树上面，现在这个逻辑简化了很多 ceph crush cl

前言ceph luminous版本新增加了很多有意思的功能，这个也是一个长期支持版本，所以这些新功能的特性还是很值得期待的，从底层的存储改造，消息方式的改变，以及一些之前未实现的功能的完成，都让ceph变得更强，这里面有很多核心模块来自中国的开发者，在这里准备用一系列的文章对这些新功能进行一个简单的介绍，也是自己的一个学习的过程 相关配置配置ceph国内源修改 /etc/yum

前言这个问题来源于我们研发的一个问题，在进行pg调整的时候，是一次调整到位好，还是分多次调整比较好，分多次调整的时候会不会出现某个pg反复挪动的问题，造成整体迁移量大于一次调整的 最近自己的项目上也有pg调整的需求，这个需求一般来源于pg规划好了，后期出现节点扩容的情况，需要对pg进行增加的调整 本篇用具体的数据来分析两种方式的差别 因为本篇的篇幅较长，直接先把结论拿出来 数据结论 调整pg

前言在看集群的配置文件的时候看到ceph里面有一个graylog的输出选择，目前看到的是可以收集mon日志和clog，osd单个的日志没有看到，Elasticsearch有整套的日志收集系统，可以很方便的将所有日志汇总到一起，这个graylog的收集采用的是自有的udp协议，从配置上来说可以很快的完成，这里只做一个最基本的实践 系统实践graylog日志系统主要由三个组件组成的 MongoDB

前言最近在群里两次看到出现mon地址不对的问题，都是显示0.0.0.0:0地址，如下所示： 12345[root@lab8106 ceph]# ceph -s cluster 3137d009-e41e-41f0-b8f8-5cb574502572 health HEALTH_ERR 1 mons down, quorum 0,1,2 lab8106,node8