Planet Ceph

Aggregated news from external sources

  • September 15, 2017
    openATTIC 3.5.0 has been released

    We are happy to announce version 3.5.0 of openATTIC. With this release we continued integrating Ceph Luminous features. One of those features is the possibility to edit Ceph pools – the size of PGs can be changed and pool applications can be enabled or disabled. Furthermore we integrated the functionality to manage OSD properties (for …Read more

  • September 13, 2017
    Luminous监控界面中文语言包

    前言 之前有各种ceph的管理平台,在部署方面大部分都比较麻烦,现在在luminous版本当中有一个原生的dashboard,虽然目前这个只能看,但是从界面上面,从接口方面都是非常不错的一个版本 原生版本目前没有语言的选择,虽然IT方面都是推荐用英语去做,但是在数据展示方面因为毕竟是要人来看,所以这里做了一个中文的语言包,方便转换成中文的界面,这个语言包是跟着ceph版本走的,因为界面可能会调整,所以只能一一匹配,同时提供了原版语言包,可以方便的回退回去,如果版本有更新以最后一个链接为准 如果有翻译的建议,欢迎在下面留言,或者其他方式告知我 语言包 ceph版本(ceph version 12.2.0 (32ce2a3ae5239ee33d6150705cdb24d43bab910c) luminous (rc) 中文包: http://7xweck.com1.z0.glb.clouddn.com/dashboard/luminous-dashboard-chinese-12.2.0-1.0-1.x86_64.rpm 英文原版包:http://7xweck.com1.z0.glb.clouddn.com/dashboard/luminous-dashboard-english-12.2.0-1.0-1.x86_64.rpm 安装方法 rpm -Uvh http://xxxxx.rpm –force 在线预览 为了方便看到效果,专门在本篇博客内放了一个预览,可以看看效果,数据是离线的,但是可以点击 <embed src="http://ow7obg32z.bkt.clouddn.com" 总结 一直有这个想法,花了点时间去实现,慢慢优化 变更记录 Why Who When 创建 武汉-运维-磨渣 2017-09-13 Source: zphj1987@gmail (Luminous监控界面中文语言包)

  • September 13, 2017
    Speaking about openATTIC 3.x at the Ceph Days in Ede (NL) on 2017-09-20

    After having been heads down with the development of openATTIC 3.x in the past few months, it’s time to get back to the surface and start talking about our latest achievements! In addition to speaking about openATTIC 3.x at SUSECON in Prague later this month, I’ll be traveling to the Netherlands next week, to attend …Read more

  • September 6, 2017
    怎样禁止Ceph OSD的自动挂载

    前言 本篇来源于群里一个人的问题,有没有办法让ceph的磁盘不自动挂载,一般人的问题都是怎样让ceph能够自动挂载,在centos 7 平台下 ceph jewel版本以后都是有自动挂载的处理的,这个我之前也写过两篇文章 ceph在centos7下一个不容易发现的改变和Ceph数据盘怎样实现自动挂载,来讲述这个自动挂载的这里讲下流程: 开机后udev匹配95-ceph-osd.rules规则,触发ceph-disk trigger,遍历磁盘,匹配到磁盘的标记后就触发了自动挂载 为什么要取消挂载?也许一般都会想:不就是停掉osd,然后umount掉,检查磁盘吗这个想法如果放在一般情况下都没有问题,但是为什么有这个需求就是有不一般的情况,这个我在很久前遇到过,所以对这个需求的场景比较清楚 在很久以前碰到过一次,机器启动都是正常的,但是只要某个磁盘一挂载,机器就直接挂掉了,所以这个是不能让它重启机器自动挂载的,也许还有其他的情况,这里总结成一个简单的需求就是不想它自动挂载 解决方法 从上面的自启动后的自动挂载流程里面,我们可以知道这里可以有两个方案去解决这个问题,第一种是改变磁盘的标记,第二种就是改变udev的rule的规则匹配,这里两个方法都行,一个是完全不动磁盘,一个是动了磁盘的标记 修改udev规则的方式 这个因为曾经有一段时间看过udev相关的一些东西,所以处理起来还是比较简单的,这里顺便把调试过程也记录下来/lib/udev/rules.d/95-ceph-osd.rules这个文件里面就是集群自动挂载的触发规则,所以在这里我们在最开始匹配上我们需要屏蔽的盘,然后绕过内部的所有匹配规则,具体办法就是在这个文件里面第一行加上 KERNEL==”sdb1|sdb2”, GOTO=”not_auto_mount” 在最后一行加上 LABEL=”not_auto_mount” 验证规则是否正确 udevadm test /sys/block/sdb/sdb1 我们先看下正常的可以挂载的盘符的触发测试显示再看下屏蔽了后的规则是怎样的可以看到在加入屏蔽条件以后,就没有触发挂载了,这里要注意,做屏蔽规则的时候需要把这个osd相关的盘都屏蔽,不然在触发相关分区的时候可能顺带挂载起来了,上面的sdb1就是数据盘,sdb2就是bluestore的block盘 测试没问题后就执行下 udevadm control –reload-rules 重启后验证是否自动挂载了 修改磁盘标记的方式 查询磁盘的标记typecode,也就是ID_PART_ENTRY_TYPE这个属性 [root@lab8106 ~]# blkid -o udev -p /dev/sdb1ID_FS_UUID=7a852eec-b32d-4c0a-8b8e-1e056a67ee35ID_FS_UUID_ENC=7a852eec-b32d-4c0a-8b8e-1e056a67ee35ID_FS_TYPE=xfsID_FS_USAGE=filesystemID_PART_ENTRY_SCHEME=gptID_PART_ENTRY_NAME=cephx20dataID_PART_ENTRY_UUID=7b321ca3-402c-4557-b121-887266a1e1b8ID_PART_ENTRY_TYPE=4fbd7e29-9d25-41b8-afd0-062c0ceff05dID_PART_ENTRY_NUMBER=1ID_PART_ENTRY_OFFSET=2048ID_PART_ENTRY_SIZE=204800ID_PART_ENTRY_DISK=8:16 匹配到这个属性就认为是集群的节点,可以挂载的,那么我们先改变这个 [root@lab8106 ~]# /usr/sbin/sgdisk –typecode=1:4fbd7e29-9d25-41b8-afd0-062c0ceff0f9 — /dev/sdb[root@lab8106 ~]# blkid -o udev -p /dev/sdb1ID_FS_UUID=7a852eec-b32d-4c0a-8b8e-1e056a67ee35ID_FS_UUID_ENC=7a852eec-b32d-4c0a-8b8e-1e056a67ee35ID_FS_TYPE=xfsID_FS_USAGE=filesystemID_PART_ENTRY_SCHEME=gptID_PART_ENTRY_NAME=cephx20dataID_PART_ENTRY_UUID=7b321ca3-402c-4557-b121-887266a1e1b8ID_PART_ENTRY_TYPE=4fbd7e29-9d25-41b8-afd0-062c0ceff0f9ID_PART_ENTRY_NUMBER=1ID_PART_ENTRY_OFFSET=2048ID_PART_ENTRY_SIZE=204800ID_PART_ENTRY_DISK=8:16 可以看到type的属性已经被修改了再次测试,可以看到已经不匹配了 如果需要恢复就执行 [root@lab8106 ~]# …Read more

  • September 6, 2017
    Ceph OSD服务失效自动启动控制

    前言 服务器上面的服务会因为各种各样的原因失败,磁盘故障,权限问题,或者是服务过载引起超时,这些都可能引起 这个在ceph里面systemctl unit 默认有个on-fail restart,默认的可能并不适合所有的场景,所以自动化的服务应该是尽量去适配你手动处理的过程,手动怎么处理的,就怎么去设置 启动分析 如果有osd失败了,一般上去会先启动一次,尽快让服务启动,然后去检查是否有故障,如果失败了,就开启调试日志,再次重启,在问题解决之前,是不会再启动了,所以这里我们的自动启动设置也这么设置 参数配置 ceph的osd的启动配置在这个配置文件 /usr/lib/systemd/system/ceph-osd@.service 默认参数: Restart=on-failureStartLimitInterval=30minStartLimitBurst=30RestartSec=20s 默认的参数意思是在30min的周期内,如果没启动成功,那么在失败后20s进行启动,这样的启动尝试30次 这个在启动机器的时候,是尽量在osd启动失败的情况下,能够在30min分钟内尽量把服务都启动起来,这个对于关机启动后的控制是没问题的 参数解释:StartLimitInterval不能设置太小,在osd崩溃的情况里面有一种是对象异常了,这个在启动了后,内部会加载一段时间的数据以后才会崩溃,所以RestartSec*StartLimitBurst 必须小于StartLimitInterval,否则可能出现无限重启的情况 restart的触发条件 Restart settings/Exit causes always on-success on-failure on-abnormal on-abort on-watchdog Clean exit code or signal X X Unclean exit code X X Unclean signal X X X X Timeout X X X Watchdog X X X X 可调整项目Restart=always就是只要非正常的退出了,就满足重启的条件,kill …Read more

  • September 4, 2017
    osd磁盘空间足够无法写入数据的分析与解决

    前言 这个问题的来源是ceph社区里面一个群友的环境出现在85%左右的时候,启动osd报错,然后在本地文件系统当中进行touch文件的时候也是报错,df -i查询inode也是没用多少,使用的也是inode64挂载的,开始的时候排除了配置原因引起的,在ceph的邮件列表里面有一个相同问题,也是没有得到解决 看到这个问题比较感兴趣,就花了点时间来解决来定位和解决这个问题,现在分享出来,如果有类似的生产环境,可以提前做好检查预防工作 现象描述 ceph版本 [root@lab8107 mnt]# ceph -vceph version 10.2.9 (2ee413f77150c0f375ff6f10edd6c8f9c7d060d0)我复现的环境为这个版本查询使用空间 可以看到空间才使用了54%可以看到,inode剩余比例很多,而文件确实无法创建 这个时候把一个文件mv出来,然后又可以创建了,并且可以写入比mv出来的文件更大的文件,写完一个无法再写入更多文件了 这里有个初步判断,不是容量写完了,而是文件的个数限制住了 那么来查询下文件系统的inode还剩余多少,xfs文件系统的inode是动态分配的,我们先检查无法写入的文件系统的 xfs_db -r -c “sb 0” -c “p” -c “freesp -s” /dev/sdb1|grep ifree 可以看到剩余的inode确实为0,这里确实是没有剩余inode了,所以通过df -i来判断inode是否用完并不准确,那个是已经使用值与理论值的相除的结果 查询xfs碎片,也是比例很低 定位问题 首先查看xfs上面的数据结构 xfs_db -r -c “sb 0” -c “p” -c “freesp -s ” /dev/sdb1 上面的输出结果这里简单解释一下,这里我也是反复比对和查看资料才理解这里的意思,这里有篇novell的资料有提到这个,这里我再拿一个刚刚格式化完的分区结果来看下 这里用我自己的理解来描述下,这个extents的剩余数目是动态变化的,刚分完区的那个,有4个1048576-1220608左右的逻辑区间,而上面的无法写入数据的数据结构,剩下的extent的平均大小为22个block,而这样的blocks总数有1138886个,占总体的99.85,也就是剩余的空间的的extents所覆盖的区域全部是16个block到31个block的这种空洞,相当于蛋糕被切成很多小块了,大的都拿走了,剩下的总量还很多,但是都是很小的碎蛋糕,所以也没法取了 解决办法 下个段落会讲下为什么会出现上面的情况,现在先说解决办法,把文件mv出来,然后mv进去,这个是在其他场景下的一个解决方法,这个操作要小心,因为有扩展属性,操作不小心会弄掉了,这里建议用另外一个办法xfs_dump的方法 我的环境比较小,20G的盘,如果盘大就准备大盘,这里是验证是否可行 xfsdump -L osd0 -M …Read more

  • September 4, 2017
    Understanding BlueStore, Ceph’s New Storage Backend

    On June 1, 2017 I presented Understanding BlueStore, Ceph’s New Storage Backend at OpenStack Australia Day Melbourne. As the video is up (and Luminous is out!), I thought I’d take the opportunity to share it, and write up the questions I was asked at the end. First, here’s the video: The bit at the start …Read more

  • September 1, 2017
    Finding UX in the Trash

    I usually resist sharing at large my opinions on how to make software, out of some impostor syndrome nonsense modesty thing. But this was too much fun not to write it up and share with you all. User experience is key to the success of any software product today. Yet I find that too many …Read more

  • September 1, 2017
    openATTIC 3.4.4 has been released

    We are happy to announce version 3.4.4 of openATTIC. Starting with Ceph “Luminous”, all pools need to be associated to the application using the pool. With this release, we have introduced the possibility to manage these associations in our frontend and enable you to use Cephs’ own pre-defined applications as well as creating your own …Read more

  • August 31, 2017
    Get cracking with Ceph 12.2 Luminous!

    I’ve repeatedly blogged about our Ceph Distributed Storage Fundamentals (HX212) course, which enables you to learn the fundamentals of the Ceph distributed storage platform, and apply your new knowledge in a fully distributed learning environment where you build your own Ceph cluster. Like all of our courses on hastexo Academy, HX212 is refreshed monthly, and …Read more

  • August 22, 2017
    Recovering data from a RBD image

    Recovering data from a RBD image First lets go ahead and make a snap of our image, then lets export it to local disk. 12 root> rbd snap create volumes/openstackRBD_disk@recovery.snaproot> rbd export volumes/openstackRBD_disk@recovery.snap /tmp/recovery.img Next, we need to run fdisk -l on our exported image to find 2 important things. Sector size Units = sectors …Read more

  • August 21, 2017
    为什么关不掉所有的OSD

    前言 碰到一个cepher问了一个问题: 为什么我的OSD关闭到最后有92个OSD无法关闭,总共的OSD有300个左右 想起来在很久以前帮人处理过一次问题,当时环境是遇上了一个BUG,需要升级到新版本进行解决,然后当时我来做操作,升级以后,发现osd无法启动,进程在,状态无法更新,当时又回滚回去,就可以了,当时好像是K版本升级到J版本,想起来之前看过这个版本里面有数据结构的变化,需要把osd全部停掉以后才能升级,然后就stop掉所有osd,当时发现有的osd还是无法stop,然后就手动去标记了,然后顺利升级今天这个现象应该跟当时是一个问题,然后搜索了一番参数以后,最后定位在确实是参数进行了控制 实践 我的一个8个osd的单机环境,对所有OSD进行stop以后就是这个状态,还有2个状态无法改变 [root@lab8106 ~]# ceph -s cluster 49ee8a7f-fb7c-4239-a4b7-acf0bc37430d health HEALTH_ERR 295 pgs are stuck inactive for more than 300 seconds 295 pgs stale 295 pgs stuck stale too many PGs per OSD (400 > max 300) monmap e1: 1 mons at {lab8106=192.168.8.106:6789/0} election epoch 3, quorum 0 lab8106 osdmap e77: 8 …Read more

Careers