前言最开始接触这个是在L版本的监控平台里面看到的,有个iscsi网关,但是没看到有类似的介绍,然后通过接口查询到了一些资料,当时由于有比较多的东西需要新内核,新版本的支持,所以并没有配置出来,由于内核已经更新迭代了几个小版本了,经过测试验证可以跑起来了,这里只是把东西跑起来,性能相关的对比需要根据去做
实践过程架构图
这个图是引用的红帽的架构图,可以理解为一个多路径的实现方式,那么这个跟之前的有什么不同
主要是有个新的tcmu-runner来处理LIO TCM后端存储的用户空间端的守护进程,这个是在内核之上多了一个用户态的驱动层,这样只需要根据tcmu的标准来对接接口就可以了,而不用去直接跟内核进行交互
需要的软件Ceph Luminous 版本的集群或者更新的版本RHEL/CentOS 7.5或者Linux kernel v4.16或者更新版本的内核其他控制软件
targetcli-2.1.fb47 or newer package python-rtslib-2.1.fb64 or newer package tcmu-runner-1.3.0 or newer pac ...
前言如果看到标题,你是不是第一眼觉得写错了,这个怎么可能,完全就是两个不相关的东西,最开始我也是这么想的,直到我发现真的是这样的时候,也是很意外,还是弄清楚下比较好,不然在某个操作下,也许就会出现意想不到的情况
定位如果你看过我的博客,正好看过这篇 <<ceph在centos7下一个不容易发现的改变>> ,那么应该还记得这个讲的是centos 7 下面通过udev来实现了osd的自动挂载,这个自动挂载就是本篇需要了解的前提
12345678910[root@lab101 ~]# df -h|grep ceph/dev/sdf1 233G 34M 233G 1% /var/lib/ceph/osd/ceph-1[root@lab101 ~]# systemctl stop ceph-osd@1[root@lab101 ~]# umount /dev/sdf1 [root@lab101 ~]# parted -l &>/dev/null[root@lab101 ~]# df -h|grep ceph/dev/sd ...
前言关于VDOVDO的技术来源于收购的Permabit公司,一个专门从事重删技术的公司,所以技术可靠性是没有问题的
VDO是一个内核模块,目的是通过重删减少磁盘的空间占用,以及减少复制带宽,VDO是基于块设备层之上的,也就是在原设备基础上映射出mapper虚拟设备,然后直接使用即可,功能的实现主要基于以下技术:
零区块的排除:
在初始化阶段,整块为0的会被元数据记录下来,这个可以用水杯里面的水和沙子混合的例子来解释,使用滤纸(零块排除),把沙子(非零空间)给过滤出来,然后就是下一个阶段的处理
重复数据删除:
在第二阶段,输入的数据会判断是不是冗余数据(在写入之前就判断),这个部分的数据通过UDS内核模块来判断(U niversal D eduplication S ervice),被判断为重复数据的部分不会被写入,然后对元数据进行更新,直接指向原始已经存储的数据块即可
压缩:
一旦消零和重删完成,LZ4压缩会对每个单独的数据块进行处理,然后压缩好的数据块会以固定大小4KB的数据块存储在介质上,由于一个物理块可以包含很多的压缩块,这个也可以加速读取的性能
上面的技术看起来很容易 ...
前言有一个ceph环境出现了异常,状态就是恢复异常的慢,但是所有数据又都在走,只是非常的慢,本篇将记录探测出问题的过程,以便以后处理类似的问题有个思路
处理过程问题的现象是恢复的很慢,但是除此以外并没有其它的异常,通过iostat监控磁盘,也没有出现异常的100%的情况,暂时排除了是osd底层慢的问题
检测整体写入的速度通过rados bench写入
1rados -p rbd bench 5 write
刚开始写入的时候没问题,但是写入了以后不久就会出现一只是0的情况,可以判断在写入某些对象的时候出现了异常
本地生成一些文件
1seq 0 30|xargs -i dd if=/dev/zero of=benchmarkzp{} bs=4M count=2
通过rados put 命令把对象put进去
1for a in `ls ./`;do time rados -p rbd put $a $a;echo $a;ceph osd map rbd $a;done
得到的结果里面会有部分是好的,部分是非常长的时间,对结果进行过滤,分为bad 和good
开始怀疑会不会 ...
前言关于qos的讨论有很多,ceph内部也正在实现着一整套的基于dmclock的qos的方案,这个不是本篇的内容,之前在社区的邮件列表看过有研发在聊qos的相关的实现的,当时一个研发就提出了在使用kernel rbd的时候,可以直接使用linux的操作系统qos来实现,也就是cgroup来控制读取写入
cgroup之前也有接触过,主要测试了限制cpu和内存相关的,没有做io相关的测试,这个当然可以通过ceph内部来实现qos,但是有现成的解决方案的时候,可以减少很多开发周期,以及测试的成本
本篇将介绍的是kernel rbd的qos方案
时间过长首先介绍下几个测试qos相关的命令,用来比较设置前后的效果验证写入IOPS命令
1fio -filename=/dev/rbd0 -direct=1 -iodepth 1 -thread -rw=write -ioengine=libaio -bs=4K -size=1G -numjobs=1 -runtime=60 -group_reporting -name=mytest
验证写入带宽的命令
1fio -filename=/dev/rbd0 ...
前言问题的触发是在进行一个目录的查询的时候,osd就会挂掉,开始以为是osd操作超时了,后来发现每次访问这个对象都有问题
12log [WRN] : slow request 60.793196 seconds old, received at osd_op(mds.0.188:728345234100006c6ddc.00000000 [o map-get-header 0-0,omap-get-vals 0~16,getxattr parent] snapc 0=[] ack+read+known_if_redirected+full_force e218901) currently startedheartbeat_map is_healthy ··· osd_op_tp thread ··· had timed out after 60
这个对象是元数据的一个空对象,保留数据在扩展属性当中
然后做了一个操作判断是对象损坏了:
直接列取omapkeys
1rados -p metadata listomapvals 100006c6ddc.00000000
发现会卡住,然后关闭 ...
前言mds是ceph里面处理文件接口的组件,一旦使用文件系统,不可避免的会出现一种场景就是目录很多,目录里面的文件很多,而mds是一个单进程的组件,现在虽然有了muti mds,但稳定的使用的大部分场景还是单acitve mds的
这就会出现一种情况,一旦一个目录里面有很多文件的时候,去查询这个目录里的文件就会在当前目录做一次遍历,这个需要一个比较长的时间,如果能比较好的缓存文件信息,也能避免一些过载情况,本篇讲述的是内核客户端正常,而export nfs后mds的负载长时间过高的情况
问题复现准备测试数据,准备好监控环境监控mds cpu占用
12pidstat -u 1 -p 27076 > /tmp/mds.cpu.logUserParameter=mds.cpu,cat /tmp/mds.cpu.log|tail -n 1|grep -v Average| awk '{print $8}'
整个测试避免屏幕的打印影响时间统计,把输出需要重定向测试一:内核客户端写入10000文件查看时间以及cpu占用
1234[root@nfsse ...
前言博客很久没有更新了,一个原因就是原来存放部署博客的环境坏了,硬盘使用的是SSD,只要读取到某个文件,整个磁盘就直接识别不到了,还好博客环境之前有做备份,最近一直没有把部署环境做下恢复,今天抽空把环境做下恢复并且记录一篇基础的GRUB的处理文档
这两天正好碰到GRUB损坏的事,很久前处理过,但是没留下文档,正好现在把流程梳理一下,来解决grub.cfg损坏的情况,或者无法启动的情况
实践步骤安装操作系统的时候会有多种可能分区的方法,一个直接的分区,一个是用了lvm,本篇将几种分区的情况分别写出来
lvm分区的情况123456789[root@localhost ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/mapper/centos-root 17G 927M 17G 6% /devtmpfs 901M 0 901M 0% /devtmpfs 912M 0 912M 0% /de ...
前言本篇讲述的是一个比较极端的故障的恢复场景,在整个集群全部服务器突然掉电的时候,osd里面的osdmap可能会出现没刷到磁盘上的情况,这个时候osdmap的最新版本为空或者为没有这个文件
还有一种情况就是机器宕机了,没有马上处理,等了一段时间以后,服务器机器启动了起来,而这个时候osdmap已经更新了,全局找不到需要的旧版本的osdmap和incmap,osd无法启动
一般情况下能找到的就直接从其他osd上面拷贝过来,然后就可以启动了,本篇讲述的是无法启动的情况
解决方案获取运行的ceph集群当前版本12[root@lab8107 ~]# ceph -vceph version 10.2.9 (2ee413f77150c0f375ff6f10edd6c8f9c7d060d0)
获取最新的osdmap
12[root@lab8107 ~]# ceph osd getmap -o /tmp/productosdmapgot osdmap epoch 142
通过osdmap可以得到crushmap,fsid,osd,存储池,pg等信息
提取crushmap
123[root@lab810 ...
前言本篇来源于群里一个人的问题,有没有办法让ceph的磁盘不自动挂载,一般人的问题都是怎样让ceph能够自动挂载,在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的,这个我之前也写过两篇文章《ceph在centos7下一个不容易发现的改变》和《Ceph数据盘怎样实现自动挂载》,来讲述这个自动挂载的
这里讲下流程:
开机后 udev 匹配 95-ceph-osd.rules 规则,触发 ceph-disk trigger,遍历磁盘,匹配到磁盘的标记后就触发了自动挂载
为什么要取消挂载?也许一般都会想:不就是停掉osd,然后umount掉,检查磁盘吗这个想法如果放在一般情况下都没有问题,但是为什么有这个需求就是有不一般的情况,这个我在很久前遇到过,所以对这个需求的场景比较清楚
在很久以前碰到过一次,机器启动都是正常的,但是只要某个磁盘一挂载,机器就直接挂掉了,所以这个是不能让它重启机器自动挂载的,也许还有其他的情况,这里总结成一个简单的需求就是不想它自动挂载
解决方法从上面的自启动后的自动挂载流程里面,我们可以知道这里可以有两个方案去解决这个问题,第一种是 ...