前言在ceph研发群里面看到一个cepher在问关于怎么读取ceph的副本的问题，这个功能应该在2012年的时候,我们公司的研发就修改了代码去实现这个功能，只是当时的硬件条件所限，以及本身的稳定性问题，后来没有在生产当中使用 我们都知道ceph在写数据的时候，是先写主本，然后去写副本，而读取的时候，实际上只有主本能够提供服务，这对于磁盘的整体带宽来说，并没有充分的发挥其性能，所以能够读取副本当然是会有很大好处的，特别是对于读场景比较多的情况 那么在ceph当中是不是有这个功能呢？其实是有的，这个地方ceph更往上走了一层，是基于crush定义的地址去进行文件的读取，这样在读取的客户端眼里，就没有什么主副之分，他会按自己想要的区域去尽量读取，当然这个区域没有的时候就按正常读取就可以了 实践如果你看过关于ceph hadoop的相关配置文档，应该会看到这么一个配置 ceph.localize.reads Allow reading from file replica objectsDefault value: true 显示的是可以从非主本去读取对象，这个对于hadoop场景肯定是越近 ...

前言在做一个比较满的集群的扩容的时候，遇到了一些问题，在这里做下总结，一般来说很难遇到，扩容要趁早，不然出的问题都是稀奇古怪的一些问题 建议环境一般来说在70%左右就需要考虑扩容了，这个时候的扩容数据迁移的少，遇到的问题自然会少很多，所谓的参数设置并不是一个单纯的参数的设置，所以一般来说在调优参数的时候，个人觉得只有适配硬件进行调优，所以本篇的参数同样是一个组合形式的 首先罗列出本篇涉及的所有参数 mon_osd_full_ratio = 0.95sd_backfill_full_ratio = 0.85sd_max_backfills = 1 最少的OSD的PG数目 1min_pg=`ceph osd df|awk '{print $9}'|awk 'NF'|grep -v PGS|sort -n|head -n 1` 那么最好满足 (osd_max_backfills/min_pg)+osd_backfill_full_ratio < mon_osd_full_ratio ...

前言之前对于striper这个地方的功能并没研究太多，只是知道这个里面可以以条带方式并行的去写对象，从而加大并发性来提高性能，而默认的条带数目为1，也就是以对象大小去写，并没有条带，所以不是很好感觉到差别，今天就尝试下用rados命令来看下这个条带是怎么回事 实践过程最开始我的集群是用rpm包进行安装的，这个可以做一些常规的测试，如果需要改动一些代码的话，就比较麻烦了，本文后面会讲述怎么改动一点点代码，然后进行测试 我们一般来说用rados put操作就是一个完整的文件，并不会进行拆分，我们尝试下看下 1234[root@lab8106 ~]# dd if=/dev/zero of=16M bs=4M count=4[root@lab8106 ~]# rados -p rbd put 16M 16M[root@lab8106 ~]# rados -p rbd stat 16Mrbd/16M mtime 2017-04-26 15:08:14.000000, size 16777216 可以看到我们put 16M的文件，在后台就是一个16M的对象 这个rados命令还有个参数是st ...

前言在ceph里面使用rbd接口的时候，存储的数据在后台是以固定的prifix的对象存在的，这样就能根据相同的前缀对象去对image文件进行拼接或者修复 在文件系统里面这一块就要复杂一些，本篇就写的关于这个，文件和对象的对应关系是怎样的，用系统命令怎么定位，又是怎么得到这个路径的 实践根据系统命令进行文件的定位写入测试文件 1dd if=/dev/zero of=/mnt/testfile bs=4M count=10 查看文件的映射 12345678910111213[root@lab8106 mnt]# cephfs /mnt/testfile mapWARNING: This tool is deprecated. Use the layout.* xattrs to query and modify layouts. FILE OFFSET OBJECT OFFSET LENGTH OSD 0 10000001188.00000000 0 ...

前言在很久以前在研究一套文件系统的时候，当时发现一个比较奇怪的现象，没有文件存在，磁盘容量还在增加，在研究了一段时间后，发现这里面有一种比较奇特的处理逻辑 这套文件系统在处理一个文件的时候放入的是一个临时目录，最开始在发送第一个写请求后，在操作系统层面马上进行了一个delete操作，而写还在继续，并且需要处理这个数据的进程一直占着的，一旦使用完这个文件，不需要做处理，这个文件就会自动释放掉，而无需担心临时文件占用空间的问题 在Ceph集群当中，有人碰到了去后台的OSD直接rm一个对象后，在前端通过rados还能get到这个删除的对象，而不能rados ls到，我猜测就是这个原因，我们来看下怎么验证这个问题 验证步骤准备测试数据，并且put进去集群12345[root@lab8106 ~]# cat zp1 sdasdasd[root@lab8106 ~]# rados -p rbd put zp1 zp1[root@lab8106 ~]# rados -p rbd lszp1 找到测试数据并且直接 rm 删除12345[root@lab8106 ~]# ceph osd map rb ...

前言ceph里面的数据是以对象的形式存储在OSD当中的，有的时候因为磁盘的损坏或者其它的一些特殊情况，会引起集群当中的某一个对象的异常，那么我们需要对这个对象进行处理 在对象损坏的情况下，启动OSD有的时候都会有问题，那么通过rados rm的方式是没法发送到这个无法启动的OSD的，也就无法删除，所以需要用其他的办法来处理这个情况 处理步骤查找对象的路径12[root@lab8106 ~]# ceph osd map rbd rbd_data.857e6b8b4567.00000000000000baosdmap e53 pool 'rbd' (0) object 'rbd_data.857e6b8b4567.00000000000000ba' -> pg 0.2daee1ba (0.3a) -> up ([1], p1) acting ([1], p1) 先找到这个对象所在的OSD以及PG 设置集群的noout1[root@lab8106 ~]#ceph osd set noout 这个是为了防止osd的停止产生不必要的删除 停 ...

前言我们在使用集群的时候，一般来说比较关注的是后台的集群的状态，但是在做一些更人性化的管理功能的时候，就需要考虑到更多的细节 本篇就是其中的一个点，查询ceph被哪些客户端连接了 实践从接口上来说，ceph提供了文件，块，和对象的接口，所以不同的接口需要不同的查询方式，因为我接触文件和块比较多，并且文件和块存储属于长连接类型，对象属于请求类型，所以主要关注文件和块存储的连接信息查询 我的集群状态如下 12345678910111213[root@lab8106 ~]# ceph -s cluster 3daaf51a-eeba-43a6-9f58-c26c5796f928 health HEALTH_WARN mon.lab8106 low disk space monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0} election epoch 6, quorum 0 lab8106 fsmap e20: 1/1/1 up {0=l ...

前言在跟一个朋友聊天的时候，聊到一个技术问题，他们的一个环境上面小文件巨多，是我目前知道的集群里面规模算非常大的了，但是目前有个问题，一方面会进行一倍的硬件的扩容，而文件的数量也在剧烈的增长着，所以有没有什么办法来 缓解这个增长的压力 当时也没想到太多的办法,只是觉得这么用下去风险太大 后来在思考了一段时间后，大概有了一个想法，这个就要看是否能把方案做下去，如果是我自己在用的集群，而非客户，我会这么去用的 方案介绍方案一也就是默认的方案，一般来说就是一个主MDS，然后几个备用MDS，整个一个挂载点，全局混用的空间 存在问题： 扩容以后，有大量的数据迁移 所有的元数据请求，只有一个MDS服务，到了巨型数据的时候，可能出现卡顿或MDS卡掉的问题 优点： 全局统一命名空间 方案二：采用分存储池的结构，也就是将集群内的目录树分配到整个集群的多个相互独立的空间里面 存在问题： 同样是所有的元数据请求，只有一个MDS服务，到了巨型数据的时候，可能出现卡顿或MDS卡掉的问题 优点： 全局统一命名空间下面对应目录到不同的存储池当中，在进行扩容的时候，不会影响原有的数据，基本是没有迁移数据 ...

前言在看一个Linux Vault 2017的资料的时候，看到红帽分享的一个测试的过程，里面关于小文件元数据性能测试的，环境准备的还比较好,可以作为一种测试模型 测试用例测试用例一： 使用find -name 测试 find -size 测试 测试用例二： 使用find -name 测试 find -size 测试 测试用例三： 使用rmdir进行测试 总结本篇就是记录一个测试模型 变更记录 Why Who When 创建 武汉-运维-磨渣 2017-03-24