记最近一次ceph故障修复



前言

所谓吃一堑长一智,每次面对问题才是最好的学习机会,在面对问题的时候,尽量是能够自己去解决,或者去尝试能够最接近答案,确实无法解决再去寻求他人帮助,这样成长的会更快一些,在学校读书做题的时候,老师也是经常告诉我们要忍住,不要去直接翻答案,在当今的互联网飞速的发展下,在google的帮助下,基本上90%的问题都能找到正确的答案,而我们其实真正需要锻炼的是实践能力和甄别的能力

根据一段话判断情绪


emotion

引言

看到一个好玩的项目,女朋友的微博情绪监控,这个是根据一段话来判断情绪的,记得之前有在哪里看到过,未来的一切都是API,也就是很多东西会被封装好,你只需要去用就可以了,这个就是一个很好的例子,你可以不懂语意分析,不懂分词,这些都不要紧,只要你给出你的素材,后面就交给api去处理

预估ceph的迁移数据量


cal

引言

我们在进行 ceph 的 osd 的增加和减少的维护的时候,会碰到迁移数据,但是我们平时会怎么去回答关于迁移数据量的问题,一般来说,都是说很多,或者说根据环境来看,有没有精确的一个说法,到底要迁移多少数据?这个我以前也有思考过这个问题,当时想是对比前后的pg的分布,然后进行计算,正好在翻一些资料的时候,看到有alram写的一篇博客,alram是Inktank的程序员,也就是sage所在的公司,程序是一个python脚本,本篇会分析下这个对比的思路,以及运行效果

计算迁移量只需要一个修改后的crushmap就可以了,这个是离线计算的,所以不会对集群有什么影响

Linux 升级内核开启 TCP BBR 有多大好处



如果你有订阅一些科技新闻,应该会有看过内核在4.9当中加入了一个新的算法,来解决在有一定的丢包率的情况下的带宽稳定的问题,这个是谷歌为我们带来的干货,新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT),谷歌一向的做法是,先上生产,然后发论文,然后有可能开源,所以这个已经合并到了内核4.9分支当中,算法带来的改变在出的测试报告当中有很详细的数据展示,这个看多了可能反而不知道到底会有什么明显改变,特别是对于我们自己的场景

那么本篇就是来做一个实践的,开看看在通用的一些场景下,这个改变有多大,先说下结果,是真的非常大

rbd-mirror配置指南-单向备份



RBD 的 mirroring 功能将在Jewel中实现的,这个Jewel版本已经发布了很久了,这个功能已经在这个发布的版本中实现了,本来之前写过一篇文章,但是有几个朋友根据文档配置后,发现还是有问题,自己在进行再次配置的时候也发现有些地方没讲清楚,容易造成误解,这里对文档进行再一次的梳理

一、基本原理
我们试图解决的或者至少需要克服的问题是,ceph在内部是强一致性的,这个对于跨区域的情况数据同步是无法接受的,一个请求需要异地返回再确认完成,这个在性能上肯定是无法接受的,这就是为什么基本上无法部署跨区域的ceph集群

因此我们需要有一种机制能够让我们在不同区域的集群之间复制块设备。这个能够帮助我们实现两个功能:

  • 灾难恢复
  • 全球块设备分布(跨地理位置)

二、内部的实现

画图.png-34.8kB

从上图所示是进行的主备模式的备份,其实这个只是看怎么应用了,在里面是自动实现的主主的模式,双向同步的,只是在应用中需要注意不要去同时操作同一个image,这个功能是作为主备去使用的,以备真正有问题的时候去实现故障恢复,这个同步是异步的

ceph的rbd备份软件ceph-backup



teralytics是一家国外的大数据公司,这个是他们开源的ceph的备份的工具,在twitter上搜索相关信息的时候看到,觉得不错就拿来试用一番

这是个什么软件

一个用来备份 ceph 的 rbd 的image的开源软件,提供了两种模式
增量:在给定备份时间窗口内基于 rbd 快照的增量备份
完全:完整镜像导出时不包含快照

注意一致性:此工具可以生成 rbd 镜像的快照,而不会感知到它们的文件系统的状态,注意下 rbd 快照的一致性限制(官网文档) 由于“完全”模式不使用快照,“完全”模式下的实时映像备份不一致(“增量”模式始终使用快照)

超过时间窗口以后,会进行一次全量备份,并且把之前的快照删除掉,重新进行一次全量备份,并且基于这个时间窗口计算是否需要删除备份的文件

软件包含以下功能:

  • 支持存储池和多image的指定
  • 支持自定义备份目标路径
  • 配置文件支持
  • 支持备份窗口设置
  • 支持压缩选项
  • 支持增量和全量备份的配置

'sortbitwise'是什么意思



问题

flag sortbitwise 在ceph中是什么意思,在Jewel版本下可以看到多了这个flags

[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 / 2226 GB avail
201 active+clean

解决calamari无法获取节点信息的bug


salt-stack

前言

一直在做calamari的相关的一些打包和安装的工作,都是业余弄的东西,所以并没有仔细的进行功能点的验证测试,正好ceph社区群里面有人问了个问题

calamari上是不是能看到ceph的version?

对于这个问题,好像确实没有见到过,而之前正好有个页面看到是空的,当时还不清楚这个是什么用的

origin

而另外一位群友贴出了这个地方的是有值的,这个地方是有BUG的,在咨询了相关的问题描述以后,我们来看下,可以如何解决这个问题

ceph 的crush算法 straw



很多年以前,Sage 在写CRUSH的原始算法的时候,写了不同的Bucket类型,可以选择不同的伪随机选择算法,大部分的模型是基于RJ Honicky写的RUSH algorithms 这个算法,这个在网上可以找到资料,这里面有一个新的特性是sage很引以为豪的,straw算法,也就是我们现在常用的一些算法,这个算法有下面的特性:

  • items 可以有任意的weight
  • 选择一个项目的算法复杂度是O(n)
  • 如果一个item的weight调高或者调低,只会在调整了的item直接变动,而没有调整的item是不会变动的