很多年以前，Sage 在写CRUSH的原始算法的时候，写了不同的Bucket类型，可以选择不同的伪随机选择算法，大部分的模型是基于RJ Honicky写的RUSH algorithms 这个算法，这个在网上可以找到资料，这里面有一个新的特性是sage很引以为豪的，straw算法，也就是我们现在常用的一些算法，这个算法有下面的特性： items 可以有任意的weight 选择一个项目的算法复杂度是O(n) 如果一个item的weight调高或者调低，只会在调整了的item直接变动，而没有调整的item是不会变动的 O(n)找到一个数组里面最大的一个数，你要把n个变量都扫描一遍，操作次数为n，那么算法复杂度是O(n)冒泡法的算法复杂度是O(n²) 这个过程的算法基本动机看起来像画画的颜料吸管，最长的一个将会获胜，每个item 基于weight有自己的随机straw长度 这些看上去都很好，但是第三个属性实际上是不成立的，这个straw 长度是基于bucket中的其他的weights来进行的一个复杂的算法的，虽然iteam的PG的计算方法是很独立的，但是一个iteam的权重变化实际上影 ...

总结了几个小技巧，用于在ceph编译过程中，能够更快一点 修改clone的地址 git clone https://github.com/ceph/ceph.git 可以修改成 git clone git://github.com/ceph/ceph.git 某些时候可能可以加快一些 根据需要下载分支假如现在想看10.2.5版本的代码 常规做法先下载整个库 1git clone git://github.com/ceph/ceph.git all 总共的下载对象数目为46万 Counting objects: 460384 这个是包含所有的分支和分支内的文件的所有版本的我们切换到分支 1234567891011[root@lab8106 mytest]#cd all[root@lab8106 all]# git branch* master[root@lab8106 all]# git checkout -b all10.2.5 v10.2.5Switched to a new branch 'all10.2.5&#x ...

前言收到一个问题如下： 一个300TB 的RBD，只有7800万的objects，如果存储小文件的话，感觉不够用 对于这个问题，我原来的理解是：对象默认设置的大小是4M一个，存储下去的数据，如果小于4M，就会占用一个小于4M的对象，如果超过4M，那么存储的数据就会进行拆分成多个4M，这个地方其实是不严谨的 对于rados接口来说，数据是多大对象put进去就是多大的对象，并没有进行拆分，进行拆分的是再上一层的应用，比如rbd，比如cephfs 那么对于rbd的image显示的对象数目和文件数目有什么关系呢？本篇将来看看这个问题，到底会不会出现上面的问题 实践过程创建一个image 123456789[root@lab8106 ~]# rbd create --image zpsize --size 100M[root@lab8106 ~]# rbd info zpsizerbd image 'zpsize': size 102400 kB in 25 objects order 22 (4096 kB objects) block_name_prefix: rb ...

前言之前有一篇文章介绍的是，在centos7的jewel下面如果自己做的分区如何处理自动挂载的问题，当时的环境对journal的地方采取的是文件的形式处理的，这样就没有了重启后journal的磁盘偏移的问题 如果采用的是ceph自带的deploy去做分区的处理的时候，是调用的sgdisk去对磁盘做了一些处理的，然后deploy能够识别一些特殊的标记，然后去做了一些其他的工作，而自己分区的时候，是没有做这些标记的这样就可能会有其他的问题 我们看下如何在部署的时候就处理好journal的uuid的问题 实践按常规流程部署OSD准备测试的自分区磁盘 12345dd if=/dev/zero of=/dev/sde bs=4M count=100;dd if=/dev/zero of=/dev/sdf bs=4M count=100; parted /dev/sde mklabel gpt;parted /dev/sdf mklabel gpt;parted /dev/sde mkpart primary 1 100%;parted /dev/sdf mkpart primary 1 100% ...

前提一套系统的最低要求是可恢复，也就是数据不丢失，但是在各种各样的原因下，整套系统都有被毁掉的可能，一直以来有个观点就是存储是需要两套的，一般情况下很难实现，但是如何把故障发生的概率降低到最低，这个是我们需要考虑的问题 最近在社区群里面又听闻一个案例，一套系统的文件系统被重置掉了，也就是fs被重建了，实际上这属于一个不应该有的操作，但是已经发生的事情，就看怎么样能在下次避免或者把损失降到最低，对于hammer版本来说，重建cephfs只是把目录树给冲掉了，实际的目录还是能创建起来，但是这其实是一个BUG，并且在最新的Jewel下已经解决掉这个问题，这就造成无法重建目录树，在Jewel下，在不修改代码的情况下，文件都可以扫描回来，但是全部塞到了一个目录下，对于某些场景来说，这个已经是最大限度的恢复了，至少文件还在，如果文件类型可知，也可以一个个去人工识别的，虽然工作量异常的大，但至少文件回来了，这种情况，如果有保留文件名和文件md5值的强制要求的话，文件是可以完全找回来的，当然，这都是一些防范措施，看有没有重视，或者提前做好了预备 本篇就是对于情况下，如何基于快照做一个防范措施，以防误 ...

前言在Centos7 下，现在采用了 systemctl来控制服务，这个刚开始用起来可能不太习惯，不过这个服务比之前的服务控制要强大的多，可以做更多的控制，本节将来介绍下关于 Ceph的 osd 磁盘挂载的问题 很多人部署以后，发现在Centos7下用Jewel的时候没有去写fstab也没有写配置文件，重启服务器一样能够挂载起来了，关于这个有另外一篇文章：「ceph在centos7下一个不容易发现的改变」 还有一些人发现自己的却启动不起来，需要写配置文件或者fstab 本篇就是来解决这个疑惑的，以及在不改变原配置方法的情况下如何加入这种自启动 实践过程首先来第一种部署的方法12ceph-deploy osd prepare lab8106:/dev/sdeceph-deploy osd activate lab8106:/dev/sde1 这个方法会把/dev/sde自动分成两个分区，一个分区给journal使用，一个分区给osd的数据使用，这种方法部署以后，是可以自动起来的，启动的挂载过程就是这个服务 1systemctl start ceph-disk@/de ...

前言现在已经是2016年收官的一个月了，之前一直想做一个calamari的集成版本，之所以有这个想法，是因为，即使在已经打好包的情况下，因为各种软件版本的原因，造成很多人无法配置成功，calamari发布以后，因为版本的更迭，经常出现软件版本引起的BUG 这里直接把需要的软件集成在一起了，按照本篇指导，一步一步是能够很简单的配置起来的，并且提供了一个视频的指导，应该能够很大程度上降低calamari的部署难度，希望能够帮助到更多的人 集成软件版本说明操作系统 Centos 7.3之所以选择这个版本是因为这个是最新发布的，centos小版本的发布能够解决一些BUG，并且不会做很大的改动，并且能够让这个集成系统保持一定的生命周期 cephceph采用的是Jewel版本的10.2.5，这个是最新发布的，因为Jewel版本是一个长期支持版本，并且小版本号已经到5了，已经在一定程度上达到了稳定 calamaricalamari采用的是1.3版本，因为calamari要做新的接口，基本上这个就是当前系统的最后的一个稳定版本，集成的版本适配Jewel版本接口名称的变化集成版本的diamond解决了无 ...

前言这个问题是不久前在ceph社区群里看到的，创建image的时候，当时的报错如下： 2016-12-13 23:13:10.266865 7efbfb7fe700 -1 librbd::image::CreateRequest: pool not configured for self-managed RBD snapshot supportrbd: create error: (22) Invalid argument 这个错我之前也没见过，并且因为很少用到快照，所以可能也就没有触发这个问题,在查看了一些资料以后，明白了原因，这里就梳理一下 Ceph实质上有两种Snapshot模式，并且两种Snapshot是不能同时应用到同一个Pool中。Pool Snapshot: 对整个Pool打一个Snapshot，该Pool中所有的对象都会受影响Self Managed Snapshot: 用户管理的Snapshot，简单的理解就是这个Pool受影响的对象是受用户控制的。这里的用户往往是应用如librbd。 上面这段话引用自 麦子迈：解析ceph-snapshot 本篇就将讲述下用 ...

前言Cephfs的快照功能在官网都很少提及，因为即使开发了很多年，但是由于cephfs的复杂性，功能一直没能达到稳定，这里，只是介绍一下这个功能，怎么使用，并且建议不要在生产中使用，因为搞不好是会丢数据的 功能介绍首先这个功能是默认关闭的，所以需要开启 123[root@lab8106 ~]# ceph fs set ceph allow_new_snaps 1Error EPERM: Warning! This feature is experimental.It may cause problems up to and including data loss.Consult the documentation at ceph.com, and if unsure, do not proceed.Add --yes-i-really-mean-it if you are certain.[root@lab8106 ~]# ceph fs set ceph allow_new_snaps 1 --yes-i-really-mean-it 从提示上可以看到，还是不要在生产上使用 开 ...