暂未分类
未读引言我们在进行 ceph 的 osd 的增加和减少的维护的时候，会碰到迁移数据，但是我们平时会怎么去回答关于迁移数据量的问题，一般来说，都是说很多，或者说根据环境来看，有没有精确的一个说法，到底要迁移多少数据?这个我以前也有思考过这个问题，当时想是对比前后的pg的分布，然后进行计算，正好在翻一些资料的时候，看到有alram写的一篇博客，alram是Inktank的程序员，也就是sage所在的公司，程序是一个python脚本，本篇会分析下这个对比的思路，以及运行效果
计算迁移量只需要一个修改后的crushmap就可以了，这个是离线计算的，所以不会对集群有什么影响
运行效果准备修改后的crushmap获取当前crushmap
1ceph osd getcrushmap -o crushmap
解码crushmap
1crushtool -d crushmap -o crushmap.txt
修改crushmap.txt这个根据自己需要，修改成自己想修改成的crushmap即可，可以是增加，也可以是删除
减少节点的计算假如删除一个osd.5 我们需要迁移多少数据将crushmap里面的osd ...
前言如果你有订阅一些科技新闻，应该会有看过内核在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% ...
