REDHAT 7.5beta 新推出的VDO功能


network

前言

关于VDO

VDO的技术来源于收购的Permabit公司,一个专门从事重删技术的公司,所以技术可靠性是没有问题的

VDO是一个内核模块,目的是通过重删减少磁盘的空间占用,以及减少复制带宽,VDO是基于块设备层之上的,也就是在原设备基础上映射出mapper虚拟设备,然后直接使用即可,功能的实现主要基于以下技术:

  • 零区块的排除:

    在初始化阶段,整块为0的会被元数据记录下来,这个可以用水杯里面的水和沙子混合的例子来解释,使用滤纸(零块排除),把沙子(非零空间)给过滤出来,然后就是下一个阶段的处理

  • 重复数据删除:

    在第二阶段,输入的数据会判断是不是冗余数据(在写入之前就判断),这个部分的数据通过UDS内核模块来判断(U niversal D eduplication S ervice),被判断为重复数据的部分不会被写入,然后对元数据进行更新,直接指向原始已经存储的数据块即可

  • 压缩:

    一旦消零和重删完成,LZ4压缩会对每个单独的数据块进行处理,然后压缩好的数据块会以固定大小4KB的数据块存储在介质上,由于一个物理块可以包含很多的压缩块,这个也可以加速读取的性能

上面的技术看起来很容易理解,但是实际做成产品还是相当大的难度的,技术设想和实际输出还是有很大距离,不然redhat也不会通过收购来获取技术,而不是自己去重新写一套了

CTDB使用rados object作为lock file


object

前言

服务器的服务做HA有很多种方式,其中有一种就是是用CTDB,之前这个是独立的软件来做HA的,现在已经跟着SAMBA主线里面了,也就是跟着samba发行包一起发行

之前CTDB的模式是需要有一个共享文件系统,并且在这个共享文件系统里面所有的节点都去访问同一个文件,会有一个Master会获得这个文件的锁

在cephfs的使用场景中可以用cephfs的目录作为这个锁文件的路径,这个有个问题就是一旦有一个节点down掉的时候,可能客户端也会卡住目录,这个目录访问会被卡住,文件锁在其他机器无法获取到,需要等到这个锁超时以后,其它节点才能获得到锁,这个切换的周期就会长一点了

CTDB在最近的版本当中加入了cluster mutex helper using Ceph RADOS的支持,本篇将介绍这个方式锁文件配置方式

Kernel RBD的QOS配置方案


io

前言

关于qos的讨论有很多,ceph内部也正在实现着一整套的基于dmclock的qos的方案,这个不是本篇的内容,之前在社区的邮件列表看过有研发在聊qos的相关的实现的,当时一个研发就提出了在使用kernel rbd的时候,可以直接使用linux的操作系统qos来实现,也就是cgroup来控制读取写入

cgroup之前也有接触过,主要测试了限制cpu和内存相关的,没有做io相关的测试,这个当然可以通过ceph内部来实现qos,但是有现成的解决方案的时候,可以减少很多开发周期,以及测试的成本

本篇将介绍的是kernel rbd的qos方案

Ceph对象主本损坏的修复方法


dog

前言

问题的触发是在进行一个目录的查询的时候,osd就会挂掉,开始以为是osd操作超时了,后来发现每次访问这个对象都有问题

log [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 started
heartbeat_map is_healthy ··· osd_op_tp thread ··· had timed out after 60

这个对象是元数据的一个空对象,保留数据在扩展属性当中

mds的cpu占用问题分析以及解决办法


ganesha

前言

mds是ceph里面处理文件接口的组件,一旦使用文件系统,不可避免的会出现一种场景就是目录很多,目录里面的文件很多,而mds是一个单进程的组件,现在虽然有了muti mds,但稳定的使用的大部分场景还是单acitve mds的

这就会出现一种情况,一旦一个目录里面有很多文件的时候,去查询这个目录里的文件就会在当前目录做一次遍历,这个需要一个比较长的时间,如果能比较好的缓存文件信息,也能避免一些过载情况,本篇讲述的是内核客户端正常,而export nfs后mds的负载长时间过高的情况

CentOS GRUB损坏修复方法


grub

前言

博客很久没有更新了,一个原因就是原来存放部署博客的环境坏了,硬盘使用的是SSD,只要读取到某个文件,整个磁盘就直接识别不到了,还好博客环境之前有做备份,最近一直没有把部署环境做下恢复,今天抽空把环境做下恢复并且记录一篇基础的GRUB的处理文档

这两天正好碰到GRUB损坏的事,很久前处理过,但是没留下文档,正好现在把流程梳理一下,来解决grub.cfg损坏的情况,或者无法启动的情况

推荐一本书《Ceph设计原理与实现》



前言

本篇不是一篇技术文,而是推荐的一本书,对于写书来说,在多年以前觉得是一件可望而不可及的事情,而看到几本经典书籍的作者在讲述自己写书的过程的时候,都是自己注入了大量的精力的,所以我自己目前也只能是一个个知识点的以博客的方式进行记录

对于买书来说,很多人会觉得很贵,其实一本书几百面,只要里面的书有两面是能够帮助到你的,书的价值其实已经回来了,所以对于技术书籍来说,基本不评价书的好坏,而是去看多少能提取的东西,多少未知的东西

ceph的书籍最初的起步也是国外的一个作者写的,社区进行翻译,社区自己也出了一本书,还有ZETTAKIT(泽塔云)的研发常涛也出了一本《Ceph源码分析》,这些都是很好的书籍,之前也都有推荐,这些书籍都是一线的研发在繁忙之中抽出空余的时间写下来的

本篇推荐的一篇是来自中兴的书籍,中兴也是国内ceph开发里面代码提交量很高的公司

目前没能拿到书籍,所以只能从目录来讲下本书会提供哪些相关的知识了

掉电后osdmap丢失无法启动osd的解决方案



前言

本篇讲述的是一个比较极端的故障的恢复场景,在整个集群全部服务器突然掉电的时候,osd里面的osdmap可能会出现没刷到磁盘上的情况,这个时候osdmap的最新版本为空或者为没有这个文件

还有一种情况就是机器宕机了,没有马上处理,等了一段时间以后,服务器机器启动了起来,而这个时候osdmap已经更新了,全局找不到需要的旧版本的osdmap和incmap,osd无法启动

一般情况下能找到的就直接从其他osd上面拷贝过来,然后就可以启动了,本篇讲述的是无法启动的情况

Luminous监控界面中文语言包



前言

之前有各种ceph的管理平台,在部署方面大部分都比较麻烦,现在在luminous版本当中有一个原生的dashboard,虽然目前这个只能看,但是从界面上面,从接口方面都是非常不错的一个版本

原生版本目前没有语言的选择,虽然IT方面都是推荐用英语去做,但是在数据展示方面因为毕竟是要人来看,所以这里做了一个中文的语言包,方便转换成中文的界面,这个语言包是跟着ceph版本走的,因为界面可能会调整,所以只能一一匹配,同时提供了原版语言包,可以方便的回退回去,如果版本有更新以最后一个链接为准

如果有翻译的建议,欢迎在下面留言,或者其他方式告知我