前言如果你有订阅一些科技新闻，应该会有看过内核在4.9当中加入了一个新的算法，来解决在有一定的丢包率的情况下的带宽稳定的问题，这个是谷歌为我们带来的干货，新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT)，谷歌一向的做法是，先上生产，然后发论文，然后有可能开源，所以这个已经合并到了内核4.9分支当中，算法带来的改变在出的测试报告当中有很详细的数据展示，这个看多了可能反而不知道到底会有什么明显改变，特别是对于我们自己的场景
那么本篇就是来做一个实践的，开看看在通用的一些场景下，这个改变有多大，先说下结果，是真的非常大
实践还是我的两台机器lab8106和lab8107,lab8106做一个webserver，lab8107模拟客户端，用简单的wget来进行测试，环境为同一个交换机上的万兆网卡服务器
我们本次测试只测试一种丢包率的情况就是1%，有兴趣的情况下，可以自己去做些其他丢包率的测试，大多数写在丢包率20%以上的时候，效果可能没那么好，这个高丢包率不是我们探讨的情况，毕竟不是常用的场景###安装新内核内核可以自己选择4.9或者以上的进行安 ...
前言RBD 的 mirroring 功能将在Jewel中实现的，这个Jewel版本已经发布了很久了,这个功能已经在这个发布的版本中实现了，本来之前写过一篇文章，但是有几个朋友根据文档配置后，发现还是有问题，自己在进行再次配置的时候也发现有些地方没讲清楚，容易造成误解，这里对文档进行再一次的梳理
基本原理我们试图解决的或者至少需要克服的问题是，ceph在内部是强一致性的，这个对于跨区域的情况数据同步是无法接受的，一个请求需要异地返回再确认完成，这个在性能上肯定是无法接受的，这就是为什么基本上无法部署跨区域的ceph集群
因此我们需要有一种机制能够让我们在不同区域的集群之间复制块设备。这个能够帮助我们实现两个功能：
灾难恢复
全球块设备分布（跨地理位置）
内部的实现
从上图所示是进行的主备模式的备份，其实这个只是看怎么应用了，在里面是自动实现的主主的模式，双向同步的，只是在应用中需要注意不要去同时操作同一个image，这个功能是作为主备去使用的，以备真正有问题的时候去实现故障恢复，这个同步是异步的
一个新的进程一个新的守护程序：rbd-mirror 将会负责将一个镜像从一个集群同步到另 ...
teralytics是一家国外的大数据公司，这个是他们开源的ceph的备份的工具，在twitter上搜索相关信息的时候看到，觉得不错就拿来试用一番
这是个什么软件一个用来备份 ceph 的 rbd 的image的开源软件，提供了两种模式增量：在给定备份时间窗口内基于 rbd 快照的增量备份完全：完整镜像导出时不包含快照
注意一致性：此工具可以生成 rbd 镜像的快照，而不会感知到它们的文件系统的状态，注意下 rbd 快照的一致性限制（官网文档） 由于“完全”模式不使用快照，“完全”模式下的实时映像备份不一致（“增量”模式始终使用快照）
超过时间窗口以后，会进行一次全量备份，并且把之前的快照删除掉，重新进行一次全量备份，并且基于这个时间窗口计算是否需要删除备份的文件
软件包含以下功能：
支持存储池和多image的指定
支持自定义备份目标路径
配置文件支持
支持备份窗口设置
支持压缩选项
支持增量和全量备份的配置
编译安装123[root@lab8106 ~]#git clone https://github.com/teralytics/ceph-backup.git[root@ ...
问题flag sortbitwise 在ceph中是什么意思,在Jewel版本下可以看到多了这个flags
1234567891011[root@lab8106 current]# ceph -s cluster ffe7a8db-c671-4b45-a784-ddb41e633905 health HEALTH_OK monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0} election epoch 4, quorum 0 lab8106 fsmap e4: 1/1/1 up {0=lab8106=up:active} osdmap e132: 8 osds: 8 up, 8 in flags sortbitwise pgmap v206294: 201 pgs, 5 pools, 4684 MB data, 1214 objects 9669 MB used, 2216 GB / ...
前言一直在做calamari的相关的一些打包和安装的工作，都是业余弄的东西，所以并没有仔细的进行功能点的验证测试，正好ceph社区群里面有人问了个问题
calamari上是不是能看到ceph的version?
对于这个问题，好像确实没有见到过，而之前正好有个页面看到是空的，当时还不清楚这个是什么用的
而另外一位群友贴出了这个地方的是有值的，这个地方是有BUG的，在咨询了相关的问题描述以后，我们来看下，可以如何解决这个问题
问题解决过程salt的软件版本：
salt-master-2015.8.1-1.el7.noarch
salt-2015.8.1-1.el7.noarch
salt-minion-2015.8.1-1.el7.noarch
问题描述calamari的salt-master节点在读取
/var/cache/salt/master/minions/{minion-hostname}/data.p
的时候有权限问题，在修改权限以后，可以读取到了，但是在重启了salt-minion以后，这个 ...
很多年以前，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值的强制要求的话，文件是可以完全找回来的，当然，这都是一些防范措施，看有没有重视，或者提前做好了预备
本篇就是对于情况下，如何基于快照做一个防范措施，以防误 ...
