学习
实践
活动
专区
工具
TVP
写文章

“网红架构师”解决你的Ceph 运维难题-Part2

作者介绍

哈喽大家好,“网红架构师”又来给大家分享Ceph运维难题解决方法了,没看过第一部分的,点开传送门

“网红架构师”解决你的ceph运维难题-Part1

点开先温习一下,接下来,我们继续第二部分的内容:

Q13. ceph -s 的全称以及报错原因

开开心心过了,这个时候执行,如果你恰好在monitor节点执行,那就会显示正常的信息,但是如果你在别的节点执行,很有可能会报下面的错,但是有的节点又不会,所以这里花一点篇幅介绍到底是怎么工作的。

首先,如果你要执行开头的任何指令,你当然要安装好Ceph客户端!()而的全称是:

上面两个参数很好理解,Ceph内部自身使用进行认证,和普通的认证没什么区别,同样需要用户名和密码进行认证,那么这里默认的用户名就叫做,而默认的秘钥保存位置就位于以下几个位置任一:

/etc/ceph/ceph.client.admin.keyring

/etc/ceph/ceph.keyring

/etc/ceph/keyring

/etc/ceph/keyring.bin

一般我们选择第一个,因为秘钥的命名规则采用也就是集群名加上用户名再加上keyring的后缀组成。所以在我们执行的时候,默认使用的是用户,同时会去那四个默认位置搜索该用户的秘钥,如果和集群保存的认证信息一致,那么就会显示出集群的状态。如果在那四个位置下面无法找到秘钥文件,就会报上面的这样的错误,解决方法后面再说。如果这个位置下面的秘钥文件保存了错误的秘钥值,就会报下面的错误:

翻译过来很简单,就是认证不通过,就好比你使用了错误的密码,去登陆系统不通过一样。这可能是由于这个节点保存了旧的集群的秘钥信息导致的。那么正确的秘钥信息保存在哪里呢?还记得部署目录吗,在正确通过后,就会自动收集所有的秘钥,并保存在部署目录下面,眼疾手快的把部署目录的拷贝到下面就会发现正常显示了,不过,这不是授权的正确的姿势。如果我们想要给一个节点admin权限,也就是执行所有Ceph指令的权限,我们可以前往部署目录,然后调用下面的指令:

这样就会把部署目录下的和拷贝到xxNode的目录下,并覆盖掉原先的秘钥文件,虽然实际上也就是scp了这两个文件,但是管理Ceph遵循一定的规则是一个很好的习惯。所以,想要得到的正确输出,你需要确认在目录下有和这两个文件,并且和集群认证信息相同即可。如果认证失败,可以前往部署目录授权该节点。Q14. ceph -s 卡住了

简单介绍下的流程:

每当你敲下一个Ceph指令时,相当于建立了一个Ceph的客户端进程去连接集群。

连接集群需要知道MON的IP地址,这个地址从里面的读取。

有了IP客户端就拿着自己用户名和秘钥向MON进行认证,认证通过执行指令返回输出。

如果你只有一个MON,然后这个MON挂掉了,那么执行指令会返回:

Tips: MON的端口号为6789,所以一般看到IP:6789时,就可以判断这个IP的MON可能挂了,或者MON的防火墙开开了。上面的报错还好处理, 前往MON节点,检查进程是否正常运行,正确启动MON进程就可以了。如果你有两个MON,挂了一个,指令会返回和上面一样的信息,所以,两个MON只能坏一个,一般MON个数都是奇数个。如果你有三个MON,挂了一个,那么会返回下面信息,集群还是会有输出的:

客户端会去连挂掉的MON,如果过一秒钟左右连不上,就会连接剩下的MON,剩下的还有两个在运行,就连到了运行中的MON,一切输出照旧,就是多了那个连不上的MON报错输出。而卡住有一种可能是:对于有三个MON的集群,挂掉了两个MON之后 ,手动去里面把挂掉的MON的IP给删除了, 只留下一个,这时候的指令就会一直卡在那里,查看MON的log可以发现,那个活着的MON一直处于状态,这样的MON是不会给客户端返回信息的,所以会卡在那里。有一点需要知道的是,MON的删除比较复杂,不能仅仅通过修改配置文件里面的IP值修改MON,所以,这里正确的做法就是,将删除的IP加回去,然后就会报出6789之类的错误,然后再去对应的IP的MON去启动MON服务。那么一个集群能坏多少MON呢 ,简单的计算法法就是:(mon个数 -1 )/ 2 取整数位也就是说三个能坏一个,两个和一个不能坏,四个坏一个,五个坏两个等等等。当你坏的MON个数大于可以坏的个数,那么所有的指令是不能返回的。Q15. Monitor clock skew detected

如果你部署了多个monitor,比如三个MON,而这三个MON的时间不是严格相同的,那么就会报这个错,而Ceph需要MON节点之间的时间差在0.05秒之内,所以一般会选择配置一个内部的NTP server。剩余节点指向该Server节点。千万一定不要小看了时间对其这个问题,如果各个节点时间不对其的话,有可能会导致某些OSD无法启动,而校准后,OSD立马就启动成功了,亦或导致OSD异常挂掉等等一系列的奇怪现象,十分不利于故障排查。然而,简单的增加的时间偏移大小,是治标不治本的方法,并且OSD节点的时间偏移并不会报告在里面,所以根本的节点方法还是配置NTP,具体方法请参考我之前写的配置NTP一段,这里就不重复了。Q16. CephX是什么,以及CephX的开启与关闭

在默认生成的里面有三行包含CephX的配置:

Ceph提供认证功能,想要连接集群,是需要提供用户名和密码的,这三个配置的值只有两种:

:开启CephX,即需要提供用户名和密码才能连接集群。

: 关闭CephX,即不需要提供,任何人都可以连接集群。

注意:如果关闭了CephX,那么任何一个客户端只要拥有了MON的IP和集群的fsid,就可以连接到集群中,然后执行所有的Ceph的指令,这是相当危险的,所以对于一个非局域网的集群,是需要开启的。之所以写这一节,是因为见过好几个在部署集群时就关闭了CephX而遇到了奇怪的现象的情形,他们一般的操作步骤是:

将生成的中的三个改成了

这一步报错如下:

先介绍下这里报错的原因,在Ceph中,除了需要使用Ceph的普通用户之外,Ceph的基本组件:MON,OSD,MDS再到RGW等都可以看做一个用户,而在使用部署的时候,会默认为这些用户生成秘钥文件,在的时候,除了生成了,还生成了,顾名思义这个就是为MON用户生成的秘钥文件。查看该文件的内容可以看到如下内容:

一个秘钥文件一般由三部分组成:

:也就是用户名,在方括号里面的就是用户名,这里为,注意是有个**点号**的。

: 顾名思义,这就是用户的密码。

: 后面的就是权限,这里可以简单理解成,该用户可以对所有的MON进行所有操作。

也就是说,Ceph中的Monitor也会像一个用户一样,拥有自己的用户名和秘钥以及操作MON的权限。简单理解了CephX之后,我们再来看上面修改了之后报的错。在执行的时候,它会去读取里面的配置,当被修改为之后, 就不会在创建MON的时候,为其生成对应的,但是有一点要注意的是,尽管没有为MON生成秘钥文件,但是,MON是正确生成的,这时候执行是可以得到集群状态的,说明MON已经正确建立。但是在所有的MON建立成功之后,指令内部会执行指令,这个指令会首先去MON的目录下面查找文件,由于关闭了CephX,在创建MON的时候不会为其生成该文件,所以指令报错:。这里只要清理下MON环境然后开启CephX重新部署MON就可以通过了。所以在我们部署集群的时候,强烈建议开启CephX,这样除了可以正确通过,还可以在后续的添加OSD时,为每个OSD生成对应的秘钥。在集群部署完毕后,可以关闭CephX认证,具体方法如下:

修改部署目录内的,将配置推送到所有节点。

重启所有的MON和OSD。如果只重启MON,过一段时间(几个小时),所有的OSD就会挂掉。。。

在正确通过之后,我们可以在部署目录下面看到多出了几个文件,都是以结尾:

: 这个是超级用户的秘钥文件,查看其对应的权限,可以发现全部都是,所以有了这个秘钥之后,相当于有了Linux系统的用户,可以为所欲为了。

: 类似的还有两个和,的意思是引导,查看其权限,简单解释就是,这个用户可以用于创建OSD(or MDS or RGW)用户。也就是说,后续的OSD的用户的生成是由该用户引导生成的。

最后再说一点,对于秘钥文件,其实我们只需要提供和用户名就好了,不需要提供权限部分,因为权限已经在Ceph集群中保存了,秘钥文件说了不算的。具体权限可以通过来查看。Q17. --overwrite-conf参数

这是个经常会遇到的问题,修改配置文件内的某些参数后,再执行指令,会报如下的错误:

报错信息提示得很明确,部署目录内的和集群的配置文件内容不一致,使用参数来覆盖集群的配置文件,也就是用部署目录的覆盖之。使用来达到这一效果,当然,你也可以直接覆盖之。但是这不是一个好习惯。正确的修改集群配置文件的姿势应该是:

修改**部署目录下的**。

将部署目录下的配置文件推送到各个节点。

强烈建议使用上面的方法

有的朋友可能喜欢直接去某个节点下的去改配置文件,这样有很多坏处:

过了一周你可能忘了你改过这个节点的配置文件。

这个节点的配置和集群其他节点的配置不一样,会带来一些安全隐患。

如果再来一个不知情的同事,他使用了正确的姿势推送配置文件,你改过的参数很容易被覆盖掉。

所以,从一开始,大家都使用同样的方式去修改集群的配置,是一个很好的习惯,对集群对同事有利无害。如果你觉得可以接受这种推送配置的方式,但是又不喜欢每次都敲这么长的参数,你可以修改这个文件,增加一行:

打开文件你就会发现,这个是的配置文件,里面的配置项是对生效的,在加了那一行之后,我们再去执行的任何指令,都会默认带上了参数,这样就可以不打这个参数还能覆盖节点的配置文件。好处是少打了一些参数,坏处是你可能会不知不觉就覆盖了配置文件,各中利弊自行取舍。这个文件的用处是很大的,可以为不同的添加参数,刚刚添加在下的参数对全局都会生效,如果你希望只对比如,,指定对应的参数,可以添加域,同时在对应的域下添加对应的参数。比如给,可以在中添加:

Q18. PG卡在creating状态

这时候,Monitor已经建好了,可以执行的指令了,然而我们看到集群的健康状态却是:。之所以是ERROR状态,是因为目前还没有建立OSD,PG处于creating状态,在建好了OSD之后,自然会解决这一问题。然而我要说的重点是这个状态的几个产生原因。字面意思很好理解,正在创建,那么怎么理解PG正在创建呢? 用最简单的方式解释PG就是:PG等于目录。如果我们使用磁盘做OSD的话,那么这个OSD上的PG就相当于,在这个磁盘上建立的目录。那么现在的问题就可以简化成,我们尚未添加任何磁盘,那么需要落盘的目录无处可建,所以就会长时间处于状态。在添加了一些OSD后,PG就可以建立了。还有一种可能的原因是,刚入门的同学在配置文件中加了参数,这个参数的具体意义会有专门的小节介绍,这个参数的默认值是,在使用这个参数后不论创建多少OSD,PG都依旧卡在状态。原因是所添加的OSD均不在默认的根节点下。CRUSH在下无法找到OSD,所以效果就和没有创建OSD一样,再解释就过于深入了,这里只简单介绍下解决方法:

将部署目录里的的去掉,或者将false改为true。

将配置文件推送到各个节点。

重启所有的OSD。

这样OSD在启动时,就会自动加到对应的主机名下的host下方,并将主机名加到下方。这样CRUSH就可以找到OSD了。当然,对于新入门的同学,一点建议就是,不知道意义的参数都不用加上,Ceph有自己一套默认参数,而这些参数不用修改就可以正常运行集群。如果添加了某些参数,最好知道其作用再使用。Q19. osd_crush_update_on_start 参数的使用和注意点

这是一个很有趣的参数,使用得当会省去很多事情,使用不当可能会造成灾难(亲身体验)。这个参数在中并不能查询到,所以这并不是Ceph进程的一个配置项。实际上,这个配置相当于一个启动配置项。也就是说在OSD启动的时候会加载这个参数。由于Jewel将OSD的启动方式做了修改,所以针对Hammer及其之前和Jewel两种启动方式,分别在下面的两个文件使用到了这个参数,实际上,加载的方式还是一样的,只是启动文件有所变化:

Hammer 及其之前 :

Jewel :

在OSD启动的时候,都会去配置文件中读取。然后启动脚本根据是否存在以及配置值来决定是否将该OSD按照一定的方式(CRUSH位置,OSD的ID,OSD的weight)将这个OSD添加到CRUSH中。简单点说,如果这个值为false,那么OSD在启动的时候不会去修改你的CRUSH树,也就是说OSD不会自动填加到对应的主机名下再自己添加到下。如果这个值为true,或者不添加该配置项(也就是说,默认为true),OSD在启动时(任何一次启动)都会将自己添加到CRUSH树下。默认的位置为:。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180726G188H700?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

关注

腾讯云开发者公众号
10元无门槛代金券
洞察腾讯核心技术
剖析业界实践案例
腾讯云开发者公众号二维码

扫码关注腾讯云开发者

领取腾讯云代金券