Planet Ceph

Aggregated news from external sources

  • February 24, 2019
    Ceph nano is getting better and better

    Long time no blog, I know, I know… Soon, I will do another blog entry to “explain” a little why I am not blogging as much I used too but if you’re still around and reading this then thank you! For the past few months, cn has grown in functionality so let’s explore what’s new …Read more

  • February 23, 2019
    FOSDEM'19 Brussels

    FOSDEM'19 Brussels Banner Saturday FOSDEM'19 Brussels – Snow on Saturday FOSDEM'19 Brussels – ULB FOSDEM middle 'street' with food trucks FOSDEM'19 Brussels – FOSDEM'19 Brussels – FOSDEM'19 Brussels – Sunday FOSDEM'19 Brussels – FOSDEM'19 Brussels – FOSDEM'19 Brussels – FOSDEM'19 Brussels – FOSDEM'19 Brussels – FOSDEM'19 Brussels – FOSDEM'19 Brussels – Monday Shout out to …Read more

  • February 14, 2019
    RGW/S3 Archive Zone goes upstream in Ceph

    One of my recent contributions, the new Ceph RGW/S3 archive zone, was merged upstream a few days ago and will finally be available in Ceph Nautilus. The feature covers the need to provide archiving zones at the S3 object level in multi-zone RGW configurations. This blog post describes the feature in detail together with some …Read more

  • February 5, 2019
    Comparing two Ceph CRUSH maps

    Sometimes you want to test if changes you are about to make to a CRUSH map will cause data to move or not. In this case I wanted to change a rule in CRUSH where it would use device classes, but I didn’t want any of the ~1PB of data in that cluster to move. …Read more

  • January 29, 2019
    Distributed Storage is Easier Now: Usability from Ceph Luminous to Nautilus

    On January 21, 2019 I presented Distributed Storage is Easier Now: Usability from Ceph Luminous to Nautilus at the linux.conf.au 2019 Systems Administration Miniconf. Thanks to the incredible Next Day Video crew, the video was online the next day, and you can watch it here: If you’d rather read than watch, the meat of the …Read more

  • January 24, 2019
    Infrastructure monitoring as a service

    a SAAS solution to monitor your Ceph storage infrastructure With Ilan Rabinovitch (Datadog)  Monitoring a Distributed System Red Hat Ceph Storage is a highly scalable, fault-tolerant platform for object, block, and file storage that delivers tremendous data resiliency (we default to keeping three copies of a customer’s data at all times), with service availability capable …Read more

  • January 14, 2019
    HAProxy in front of Ceph Manager dashboard

    The Ceph Mgr dashboard plugin allows for a easy dashboard which can show you how your Ceph cluster is performing. In certain situations you can’t contact the Mgr daemons directly and you have to place a Proxy server between your computer and the Mgr daemons. This can be done easily with HAProxy and the following …Read more

  • January 3, 2019
    BlueStore Unleashed

    Red Hat Ceph Storage 3.2 brings a new round of enhancements We are pleased to announce today’s immediate availability of Red Hat Ceph Storage 3.2, our fifteenth RHCS release. There are several highlights with this version, the most notable of which is the introduction of full support for BlueStore. As you definitely already know, BlueStore …Read more

  • January 3, 2019
    vdbench测试实时可视化显示

    前言 前一段时间碰到一个系统,用rados bench 去跑都还比较正常,但是一跑数据库就非常慢,测试工具会抛出延时过大的提示,经过排查发现,云平台中有一台虚拟机还运行着备份数据库的服务,而这个备份软件是需要反复写一个标记文件的,因为这个标记文件只对应了一个对象,一个对象对应了一个pg,一个pg对应到固定的ssd上面,那个ssd的io几乎被这一个操作给打满了,然后全局的请求到了这个osd上面的时候,都会变得慢和卡顿 出现这种情况,在业务层面可能需要做好分离,我们在面对这种情况的时候该如何提前就做好测试,对自己的性能的剩余性能做一个更好的评估,什么时候需要分离,什么时候不需要分离,这个都是需要用数据来说话的 性能测试的时候,经常面临的这些问题,你告诉我这个环境能跑多少iops,带宽能多大,我的数据库能不能跑,这个我也没法回答,一般来说我都是说需要根据环境进行测试,这个测试也只能根据自己设计的模型进行测试,而越接近用户使用场景的业务模型,就越能反应真实的业务能力,最好的测试就是直接拿对接的软件进行测试,接什么业务就用什么业务压 我们可以自己先问自己几个问题 1、如果集群里面有一台虚拟机在跑大带宽的业务,你去测试iops,性能能到多少,这个对应的是真实场景里面一个备份业务和一个数据库业务混用的情况 2、单机iops能到多少,如果几十台服务器都同时在跑的时候,单机的iops还能到多少? 3、多机并发的时候,单个机器上面的io会不会受到其他的机器的io的影响 4、性能在遇到scrub的时候,或者迁移的时候,能够还保留多少的性能,这个保留性能是否可控 5、集群写入到70%的时候,性能是多少,是初始的百分之多少,还够覆盖业务IO不? 如果你的业务需求是远低于机器能提供性能的时候,上面的这些都不是问题,但是如果跑的业务是敏感型的时候,那么业务很可能收到较大的影响,这个时候我们只有对自己的环境有很精确的掌握才不至于在业务出现性能问题的时候去救火了 上面的这些是为了引出今天我需要讲的一个测试工具,在之前的文章当中比较多的讲的是故障的处理,后续的文章里面可能会讲一些偏向于控制和监控类的 性能测试工具 本篇讲的一个工具是vdbench,这个工具跟fio类似,很多测试里面会用到这个工具,这个比fio强大的是,既能够测试块接口也能测试文件接口,文件接口是去模拟写入文件,这个又和mdtest类似,但是mdtest主要是去测试元数据能力,vdbench则比较综合,这个工具在没有使用之前觉得很复杂,总觉得写个配置文件很麻烦,但是用了几次就会发现其实逻辑上面还是很清楚了,这里给个测试文件的模板,本篇主要写块接口的测试,所以模板也以块接口作为例子 *example workload: Single run, 10 raw disk*HD: HOST Define*SD: Storage Definition*WD: Workload Definition*RD: Run Definition*hd=default,vdbench=/root/vdbench,user=root,shell=sshhd=hd1,system=192.168.129.40hd=hd2,system=192.168.129.41sd=sd1,lun=/dev/sdb,host=hd1,openflags=o_direct,hitarea=0,range=(0,100),threads=2sd=sd2,lun=/dev/sdb,host=hd2,openflags=o_direct,hitarea=0,range=(0,100),threads=2wd=wd1,sd=(sd1,sd2),xfersize=(4096,100),rdpct=0,seekpct=100rd=run1,wd=wd1,iorate=max,elapsed=600,warmup=300* 2 rbd disks, 100% random, 0% read of 4k blocks at unlimited rate 上面的例子是测试两台机器的磁盘,每个磁盘两个线程写,4K的块大小,100%的写,100%随机,热身写300s,然后测试600s 这样一个配置后,就可以同时对两台机器按上面的写入模型写入了,我们看下系统开始测试的时候的显示 就是类似这样的显示,然后最后的测试结果会在output里面生成一些html文件 这个工具有以下优点: 1、能够每秒显示整个测试的io叠加,这样测试整个集群的io的时候,可以把所有虚机启动起来,然后进行io的压测,而不是去压单个rbd的iops,那个没有太大的意义,只能是一个数值,真正的环境大多也不是给一个业务使用的,也可以跑起一个业务以后,再看剩余的机器还能跑多少性能 2、在测试输出报告里面会根据主机统计一次io,这个面向的业务场景就是,比如某台主机上面可能挂载多块云盘,那么可以根据主机进行统计 3、在报告里面还会根据设备显示io个延时的信息,也就是只要是测试设备,每一个的性能指标都能查到,这个的好处就是检测集群里面的io是不是均匀的,如果做了qos,设备的测试性能值是不是跟设置限制一样 既然有上面的优点,那有没有缺点呢?这个我个人认为还是有优化的空间的,下面就是我根据自己的需求做的一点点优化工作,并且把工具投入到了自己的测试工作当中去了 一些需求 1、比如一个测试在一个小时,测试过程中碰上了scrub对性能的影响,我想知道这个影响到底有多大,如果按现在这个,我得等测试完了,再导出测试结果,再自己用excel图表工具做分析,这样一轮轮的进行测试 2、如果我需要对某个参数进行调整,进行调优测试,一般来说,都是测试一轮,然后再去调整参数,再重头再来一轮,反复测试,是不是有比较明显的显示让我能够实时的看到这个变化 …Read more

  • December 28, 2018
    中兴Clove团队新书-Ceph之RADOS设计原理与实现

    这本书,可以节约你阅读20W行代码的时间! 了解Ceph的人都知道,RADOS是整个Ceph的基础,也是整个Ceph的核心,但越是核心,越难掌握,想想看,单单RADOS的代码就有将近20W行之多,不经历好几年的摸爬滚打,怕是难以掌握其中的来龙去脉。而这个困境,因为一本新书出现了转机,这本书就是中兴通讯CLOVE团队全新创作的《Ceph之RADOS设计原理与实现》。粗略从目录上看就已经很有料了:RADOS导论、CRUSH解析(包括Balancer、upmap的使用)、MON/OSD的拆解、BlueStore、PG、Backfill/Recovery/Scrub、QoS、EC… 这些内容都很容易勾起Cepher们的好奇心: 到底如何使用Balancer来解决集群数据分布不均? Ceph中的Monitor到底保存了些什么东西? 到底要不要Scrub,Scrub到底做了一些什么事? BlueStore到底是如何取代FileStore的? 怎么理解增量和异步Recovery? … 能把Ceph吃透的人并不多,就国内来说,中兴的CLOVE团队算是比较强的队伍了,相信这样一本书,应该能给你在研究Ceph打怪的路上,提供很多参考和帮助! 现在京东、当当、淘宝都已经同步发售了,听说第一批书并不多,想要搞定RADOS的Cepher们可要抓紧时间下单啦,有个好消息是,这次还提供了正版的电子书可供购买,比如掌阅、当当都有,再也不怕书被翻烂啦! 京东购买地址:http://item.jd.com/12474941.html 现抽奖一名同学,中奖后会从京东快递这本书给你(微信扫一扫) Source: zphj1987@gmail (中兴Clove团队新书-Ceph之RADOS设计原理与实现)

  • December 18, 2018
    处理ceph incompelete的经验

    前言 最近已经见到几个环境出现过incompelete了,这个在很久以前Jewel正在合入mark-complete工具的时候就有做过类似的处理,但是随着处理的环境越来越多,这个地方还是有些需要注意的,本篇是写一些需要注意的点 一般来说是环境有多个机器同时坏盘或者掉电,或者掉主机引起的 处理流程 拿到环境第一时间是对环境标记noout,这个操作是为了防止集群的环境反复震荡,标记noout没有osd标记为out的情况下,只是pg状态变化,实际数据并不进行迁移 把能够启动的osd都启动起来,直到没有能启动的osd了,如果有能力处理的话,尽量把osd拉起来,如果是硬盘损坏掉了,确定无法修复了,那么就当这个osd无法救回来了,这个步骤里面是要尽最大努力把osd拉起来 这里面还有一部分情况是osd启动不起来,但是数据目录是可以访问的,这个地方就把这种盘先保留好,一定不要推掉了,很多运维上去看盘坏了就重新创建osd,这种推掉osd的操作建议只在active+clean的时候才做,否则的话,pg状态不对,又把osd推掉了,数据有比较大的概率丢失 在以上操作做完以后,开始处理异常的pg,处理的时候,首先把异常的pg的info全部倒好备份一下,还把pg分布保存下 ceph pg 1.4 query > 1.4queryceph pg dump|grep incom > pgincom.info 全部保留一份,通过这个信息能够分析出数据的完整性和数据在哪里,这个一定要保留好原始版本,这个是有可能在后面做一些操作后就变更了,造成你不知道去哪里找数据 一部分情况下,根据query的信息提示,会告诉你 lost掉某个盘,可能让它恢复,这个操作的时候也是需要检查下,这个pg的数据是不是在当前环境下面有地方有完整的数据,确定有的话再根据提示进行lost的操作,如果还不放心,或者更稳妥的话,这个时候就需要备份pg数据了,这里就有个问题了,在做系统规划的时候,系统盘要尽量大点,这个时候就可以用来保存pg导出的数据了,如果是filestore,容量不够还可以拿osd的目录做临时存储,如果是bluestore,就只能拿本地盘做临时存储了 做完上面的标记和备份的操作后,有一部分的pg可能恢复正常了,然后还有一部分恢复不了正常,这个时候就需要根据上面保存好的query的信息里面拿到pg的数据在哪个osd上面,注意这个时候当前的query是可能查不到数据在哪里的,这个时候会出现提示数据在osd.1,osd.2,osd.3实际数据在osd.8的情况,并且可能完全没地方知道是在osd.8的,这个信息是存储在最开始版本的query里面的,所以在处理前,一定备份好信息,备份好数据 这个时候就开始把pg的数据导入到主osd,导入以后就可以标记mark-complete了,然后拉起osd,然后看下处理的这个pg的状态 总结 在处理故障过程中,首先要保证能把能够拉起来的osd尽量全部拉起来,这个操作做好了可以省掉很多工作,pg是交叉映射的,有的时候正好交叉的osd全down了,所以能拉起来一个,这个pg也是可以状态恢复的 在所有操作前都是要进行数据备份的,这样即使出了问题,数据在都可以导入,导出的数据是需要检查下对象数目的,这个在导出前可以用ceph-object-tool做list操作检查pg对象的个数是否跟pg dump里面的一致的,通过大小也可以大致判断,这个在L版本的ceph做rm pg操作的时候,是有一个export-remove的命令的,这个把rm变成了mv操作,安全性比以前要好很多,防止手抖删错了,可以再导入 总之在数据处理过程中要小心,操作前备份好,操作过程每一步进行命令反馈确认,也就是你执行了命令应该是什么结果,这个要提前有分析,一旦产生偏差的时候,就要去分析了 本篇是操作上的建议,并没有具体命令,这个需要自己在实际操作过程中体会了,当然生产环境没那么多练手的机会,那么就尝试下对测试环境多进行破坏后进行恢复了,尽量不要直接推掉测试环境,每一次的问题处理都是为生产的处理做好储备工作 变更记录 Why Who When 创建 武汉-运维-磨渣 2018-12-19 Source: zphj1987@gmail (处理ceph incompelete的经验)

  • November 21, 2018
    The Mustang Rides Again

    Revisiting Applied Micro’s Mustang two years later, we learned that a few things have changed, and use three of them to build a test storage cluster to try Ceph on ARM — doing a little benchmarking while we are at it.  A New Breed A newer revision of the Mustang EVK X-Gene 1 development board …Read more

Careers