Planet Ceph

Aggregated news from external sources

  • February 24, 2017
    记最近一次ceph故障修复

    前言 所谓吃一堑长一智,每次面对问题才是最好的学习机会,在面对问题的时候,尽量是能够自己去解决,或者去尝试能够最接近答案,确实无法解决再去寻求他人帮助,这样成长的会更快一些,在学校读书做题的时候,老师也是经常告诉我们要忍住,不要去直接翻答案,在当今的互联网飞速的发展下,在google的帮助下,基本上90%的问题都能找到正确的答案,而我们其实真正需要锻炼的是实践能力和甄别的能力去年一年给不少的生产环境解决过问题,在相互交流几次以后,解决问题的过程,基本也熟悉了,一般解决问题的大致流程都是: 告之我环境的当前状况,需要实现的情况 准备好远程的环境 告之对方可能出现的情况,是否可操作,然后解决问题 交流问题的出现原因以及解决的办法 目前来看,基本都解决了,对于我来说是一次处理故障经验的累积,对对方来说是环境的恢复,以及下次在出现相同故障的时候,自己能够处理好类似问题 本次恢复对于我来说也是刷新了的认识,进展只到了解决问题的地方,就结束了,那么我就记录下这次解决问题当中的收获 处理过程 故障的发生应该是在一次掉电后触发的,整个集群在重新启动以后,出现了多块磁盘故障的问题,也有主机无法启动的情况,整个集群的PG状态处于一个混乱的状态,stale和incomplete以及peering状态的都很多 告之对方,需要把相关的osd节点全部都启动起来,然后再看是否有恢复的可能,常规来说,如果三台机器同时出现磁盘损坏,那么这个集群的数据必然会丢失,并且丢失的数据基本将是覆盖所有数据 在将近一周的时间以后,集群环境磁盘都能挂载,环境可以进行处理了 出现pg状态一直是peering状态的情况 用ceph -s 检查集群的状态,集群的状态所有的osd都是正常的up in状态,但是pg状态就是peering状态无法恢复,然后查看都是来自其中的某一个osd,登陆上机器后查看osd的日志,显示无法获取心跳,但是网络明明是好的,并且还能登陆到其他机器上,这就奇怪了,这里先讲下这个地方对方环境埋下的一个坑 hosts文件里面是这种组合 10.10.10.101 node1192.168.10.1 node110.10.10.102 node2192.168.10.2 node210.10.10.103 node3192.168.10.3 node3 也就是一个主机名映射了两个IP,这个对方说没问题,我也就不多说了,只是我的环境是不会允许这么配置,正是因为这个配置,也就间接隐藏了一个错误的配置,这个错误就是居然在环境当中配置两台主机相同的IP,这也就是为什么出现相同的IP我还能登陆机器 环境配置成了 10.10.10.102 node3192.168.10.3 node3 也就是node3和node2的集群IP冲突了,所以我在ssh node3的时候能正确登陆node3 ssh node2也能正确登陆node2,只是集群用的IP冲突了,而两台机器之间网络又可以通过其他的网段通信,集群的osd状态是正常,只是pg异常了 IP冲突在生产环境中是大忌,可能会毁掉整个集群的状态,这个有多大影响?你可以试下配置好一个集群,然后把两个节点的IP配置成一样,然后检查集群的状态和你的上面运行的存储的状态,这个环境因为是在不提供服务状态下,所以带来的影响没有那么大 在排查到这个错误的时候,已经是晚上快11点了,对方也要回家了,作为运维比较苦逼的就是很多时候,需要待在公司到晚上很晚才能离开,所以问了下是否能留远程给我,得到了许可,可以继续操作,因为这个环境状态来看我觉得还在我的可控范围内,所以想继续尝试,对方也是问过几次,这个环境是否可恢复,我给出的回答也是尽量,IP冲突的问题解决后,重新启动OSD,集群基本快正常了,还是有一些异常的PG需要处理 出现osd无法启动 verify_reply couldn’t decrypt with error: error decoding block for decryption 这个错误之前有处理经验,时间偏移过大引起认证不通过,登陆上osd对应的机器,检查发现时间偏移了几个小时,引起错误,检查发现ntp配置文件使用的是默认配置文件,至少这台没配置ntp,调整好时间,重启osd解决无法启动问题 出现PG incomplete的状态 这个状态一般是环境出现过特别的异常状况,PG无法完成状态的更新,这个只要没有OSD被踢出去或者损坏掉,就好办,这个环境的多个PG的数据是一致的,只是状态不对,这个就把PG对应的OSD全部停掉,然后用ceph-object-tool 进行mark complete,然后重启osd,一般来说这个都是能解决了,没出意外,这个环境用工具进行了修复,当然8个这样的PG操作起来还是要比较长的时间,一个个的确认状态,还好都解决了,这个工具是jewel上面集成的,所以在老版本出现这个问题,可以通过升级后进行处理,之前有个别人的生产环境这么处理过这个问题 出现PG inconsistent状态的 …Read more

  • February 23, 2017
    Catastrophe Hits Your Datacenter – But Users Don’t Notice

    Many large, network-dependent organizations are deploying OpenStack together with Red Hat Ceph Storage because they are inherently highly available solutions. What if you lost your datacenter completely in a catastrophe, but your users hardly noticed? Sounds like a mirage, but it’s absolutely possible, and major datacenters with high demand for full availability are already accomplishing …Read more

  • February 20, 2017
    No more privileged containers for Ceph OSDs

    I’m really sorry for being so quiet lately, I know I promised to release articles more regularly and I clearly failed… Many things are going on and where motivation is key to write articles, I’ve been having a hard time to find the right motivation to write :/ However, I am not giving up and …Read more

  • February 16, 2017
    Importing an existing Ceph RBD image into Glance

    The normal process of uploading an image into Glance is straightforward: you use glance image-create or openstack image create, or the Horizon dashboard. Whichever process you choose, you select a local file, which you upload into the Glance image store. This process can be unpleasantly time-consuming when your Glance service is backed with Ceph RBD, …Read more

  • February 16, 2017
    Ceph and RBD mirroring, upcoming enhancements

    I’ve been getting a lot of questions about the RBD mirroring daemon so I thought I will do a blog post similar to a FAQ. Most of the features described in this article will likely be released for Ceph Luminous. Luminous should land this fall, so be patient :). HA support A crucial part of …Read more

  • February 13, 2017
    Do not use SMR disks with Ceph

    Many new disks like the Seagate He8 disks are using a technique called Shingled Magnetic Recording to increase capacity. As these disks offer a very low price per Gigabyte they seem interesting to use in a Ceph cluster. Performance Due to the nature of SMR these disks are very, very, very bad when it comes …Read more

  • February 10, 2017
    根据一段话判断情绪

    引言 看到一个好玩的项目,女朋友的微博情绪监控,这个是根据一段话来判断情绪的,记得之前有在哪里看到过,未来的一切都是API,也就是很多东西会被封装好,你只需要去用就可以了,这个就是一个很好的例子,你可以不懂语意分析,不懂分词,这些都不要紧,只要你给出你的素材,后面就交给api去处理 代码 #!/usr/bin/env python# -*- coding: UTF-8 -*-import sysimport jsonimport requestsdef main(): if len(sys.argv) != 2: help() else: printpromotion(sys.argv[1])def help(): print “””Usage : qingxu.py [-h] [word] 情绪鉴定 – 判断一段话的情绪 OPTIONS ======== sample: [root@host ~]# python qingxu.py 开心 说的话: word 正面情绪: 98.3% 负面情绪: 1.7% ======== “””def printpromotion(word): weburl=’https://api.prprpr.me/emotion/wenzhi?password=DIYgod&text=’+word r = requests.get(‘%s’ %weburl) json_str = json.loads(r.text) …Read more

  • February 8, 2017
    预估ceph的迁移数据量

    引言 我们在进行 ceph 的 osd 的增加和减少的维护的时候,会碰到迁移数据,但是我们平时会怎么去回答关于迁移数据量的问题,一般来说,都是说很多,或者说根据环境来看,有没有精确的一个说法,到底要迁移多少数据?这个我以前也有思考过这个问题,当时想是对比前后的pg的分布,然后进行计算,正好在翻一些资料的时候,看到有alram写的一篇博客,alram是Inktank的程序员,也就是sage所在的公司,程序是一个python脚本,本篇会分析下这个对比的思路,以及运行效果 计算迁移量只需要一个修改后的crushmap就可以了,这个是离线计算的,所以不会对集群有什么影响 运行效果 准备修改后的crushmap 获取当前crushmap ceph osd getcrushmap -o crushmap 解码crushmap crushtool -d crushmap -o crushmap.txt 修改crushmap.txt这个根据自己需要,修改成自己想修改成的crushmap即可,可以是增加,也可以是删除 减少节点的计算 假如删除一个osd.5 我们需要迁移多少数据将crushmap里面的osd.5的weight改成0 crushtool -c crushmap.txt -o crushmapnew 运行计算脚本 [root@lab8106 ceph]# python jisuan.py –crushmap-file crushmapnewPOOL REMAPPED OSDs BYTES REBALANCE OBJECTS REBALANCE rbd 59 6157238296 1469 data 54 5918162968 1412 metadata 53 5825888280 1390 …Read more

  • January 29, 2017
    Edit the Ceph CRUSHmap

    The CRUSHmap, as suggested by the name, is a map of your storage cluster. This map is necessary for the CRUSH algorithm to determine data placements. But Ceph’s CRUSHmap is stored in binary form. So how to easily change it? Native tools Ceph comes with a couple of native commands to do basic customizations to …Read more

  • January 24, 2017
    Testing Ceph BlueStore with the Kraken release

    Ceph version Kraken (11.2.0) has been released and the Release Notes tell us that the new BlueStore backend for the OSDs is now available. BlueStore The current backend for the OSDs is the FileStore which mainly uses the XFS filesystem to store it’s data. To overcome several limitations of XFS and POSIX in general the …Read more

  • January 24, 2017
    Linux 升级内核开启 TCP BBR 有多大好处

    如果你有订阅一些科技新闻,应该会有看过内核在4.9当中加入了一个新的算法,来解决在有一定的丢包率的情况下的带宽稳定的问题,这个是谷歌为我们带来的干货,新的 TCP 拥塞控制算法 BBR (Bottleneck Bandwidth and RTT),谷歌一向的做法是,先上生产,然后发论文,然后有可能开源,所以这个已经合并到了内核4.9分支当中,算法带来的改变在出的测试报告当中有很详细的数据展示,这个看多了可能反而不知道到底会有什么明显改变,特别是对于我们自己的场景 那么本篇就是来做一个实践的,开看看在通用的一些场景下,这个改变有多大,先说下结果,是真的非常大 实践 还是我的两台机器lab8106和lab8107,lab8106做一个webserver,lab8107模拟客户端,用简单的wget来进行测试,环境为同一个交换机上的万兆网卡服务器 我们本次测试只测试一种丢包率的情况就是1%,有兴趣的情况下,可以自己去做些其他丢包率的测试,大多数写在丢包率20%以上的时候,效果可能没那么好,这个高丢包率不是我们探讨的情况,毕竟不是常用的场景 安装新内核 内核可以自己选择4.9或者以上的进行安装,也可以用yum安装,这里只是测试,就yum直接安装 yum –enablerepo=elrepo-kernel install kernel-ml 修改启动项 grub2-editenv listgrub2-set-default ‘CentOS Linux (4.9.5-1.el7.elrepo.x86_64) 7 (Core)’grub2-editenv list 准备下载数据 准备一个web服务器然后把一个iso丢到根目录下,用于客户端的wget 设置丢包率 这里用tc进行控制的,也就是一条命令就可以了,这个还可以做其他很多控制,可以自行研究 tc qdisc add dev enp2s0f0 root netem loss 1% 如果需要取消限制 tc qdisc del root dev enp2s0f0 设置新的算法 讲下面的两个配置文件添加到/etc/sysctl.conf net.ipv4.tcp_congestion_control=bbrnet.core.default_qdisc=fq 然后执行sysctl -p让它生效 检查是参数是否生效 [root@lab8106 rpmbuild]# …Read more

  • January 22, 2017
    rbd-mirror配置指南-单向备份

    RBD 的 mirroring 功能将在Jewel中实现的,这个Jewel版本已经发布了很久了,这个功能已经在这个发布的版本中实现了,本来之前写过一篇文章,但是有几个朋友根据文档配置后,发现还是有问题,自己在进行再次配置的时候也发现有些地方没讲清楚,容易造成误解,这里对文档进行再一次的梳理 一、基本原理我们试图解决的或者至少需要克服的问题是,ceph在内部是强一致性的,这个对于跨区域的情况数据同步是无法接受的,一个请求需要异地返回再确认完成,这个在性能上肯定是无法接受的,这就是为什么基本上无法部署跨区域的ceph集群 因此我们需要有一种机制能够让我们在不同区域的集群之间复制块设备。这个能够帮助我们实现两个功能: 灾难恢复 全球块设备分布(跨地理位置) 二、内部的实现 从上图所示是进行的主备模式的备份,其实这个只是看怎么应用了,在里面是自动实现的主主的模式,双向同步的,只是在应用中需要注意不要去同时操作同一个image,这个功能是作为主备去使用的,以备真正有问题的时候去实现故障恢复,这个同步是异步的 二、一个新的进程一个新的守护程序:rbd-mirror 将会负责将一个镜像从一个集群同步到另一个,rbd-mirror需要在两个集群上都配置,它会同时连接本地和远程的集群。在jewel版本中还是一对一的方式,在以后的版本中会实现一对多的,所以在以后的版本可以配置一对多的备份 作为起点,这个功能讲使用配置文件连接集群,使用用户和密钥。使用admin用户就可以了,使用的验证方式就是默认的cephx的方式 为了相互识别,两个集群都需要相互注册使用 rbd mirror pool peer add命令, 这个在下面会实践 二、镜像The RBD mirroring 依赖两个新的rbd的属性 journaling: 启动后会记录image的事件 mirroring: 明确告诉rbd-mirror需要复制这个镜像 也有命令可以禁用单独的某个镜像。journaling可以看做是另一个rbd的image(一些rados对象),一般情况下,先写日志,然后返回客户端,然后被写入底层的rbd的image,出于性能考虑,这个journal可以跟它的镜像不在一个存储池当中,目前是一个image一个journal,最近应该会沿用这个策略,直到ceph引入一致性组。关于一致性组的概念就是一组卷,然后用的是一个RBD image。可以在所有的组中执行快照操作,有了一致性的保证,所有的卷就都在一致的状态。当一致性组实现的时候,我们就可以用一个journal来管理所有的RBD的镜像 可以给一个已经存在image开启journal么,可以的,ceph将会将你的镜像做一个快照,然后对快照做一个复制,然后开启journal,这都是后台执行的一个任务 可以启用和关闭单个镜像或者存储池的mirror功能,如果启用了journal功能,那么每个镜像将会被复制 可以使用 rbd mirror pool enable启用它 三、灾难恢复交叉同步复制是可以的,默认的就是这个方式,这意味着两个地方的存储池名称需要相同的这个会带来两个问题 使用相同的存储做备份做使用会影响性能的 相同的池名称在进行恢复的时候也更容易。openstack里面只需要记录卷ID即可 每个image都有 mirroring_directory 记录当前active的地方。在本地镜像提示为 primary的时候,是可写的并且远程的站点上就会有锁,这个image就是不可写的。只有在primary镜像降级,备份的点升级就可以了,demoted 和 promoted来控制这里,这就是为什么引入了等级制度,一旦备份的地方升级了,那么主的就自动降级了,这就意味着同步的方向就会发生变化了 如果出现脑裂的情况,那么rbd-mirror将会停止同步,你自己需要判断哪个是最新的image,然后手动强制去同步rbd mirror image resync 上面基本参照的是sebastien翻译的,原文只是做了简短的说明,下面是我的实践部分 配置实践部分 先介绍下一些简单的概念 rbd-mirror 进程 …Read more

Careers