磨磨谈 ceph-users 邮件列表之Vol-1-Issue-1(完结)

关于归档方式本来开始准备采用邮件列表的vol和issue的方式,但是因为issue里面是以天为单位,而里面的问题可能是重复的,这个不好进行规整了,那么在我这里,准备以Thread的方式,每个Issue里面包含5个问题,每10个issue为一个vol,进行规整,以2016年开始为起点,前后去收集,会记录问题提问者和发起问题的时间

前言:

一个技术的邮件列表其实是个大宝藏,看你怎么去挖掘它了,里面有太多的灵光一现,太多的大牛的引导,而我等也只能在某些出现问题的时候,去搜索的时候,才发现这些问题是很多人遇到过的,最近看到一个技术人说的一句话深有同感,意思是说,很多时候我们花精力重复解决问题

  • 一流的公司在从整体上去解决一批的问题
  • 二流的公司在一次又一次解决相同的问题

与其等待别人去整理,还不如自己去做这个事情,没有压力,没有人催促,最后自己还能有所收获,何乐而不为,这个系列我会去将邮件列表的里面的内容进行整理,提出我个人的处理办法或者方式,或者总结一下里面别人的经验,这个系列将以现在的时间线往前和往后的方式进行整理,这个会是一个很长的过程,希望尽量的获取更多的东西,文档格式尽量保持一致

一、今天的 Topics:

  • journal encryption with dmcrypt (Date: Fri, 22 Jan 2016 20:35:46 +0000)
  • CephFS
  • ceph fuse closing stale session while still operable
  • inkscope version 1.3.1
  • Ceph monitors 100% full filesystem, refusing start

二、涉及问题:

  • osd分区加密
  • 文件系统加密挂载问题
  • ceph-fuse写入僵住的问题
  • inkscope发布了新版本
  • monitor的文件系统磁盘满了无法启动的问题

三、问题解析

问题一:

journal encryption with dmcrypt (Reno Rainz)

问题原文:

I’m trying to setup a cluster with encryption on osd data and journal.
To do that I use ceph-deploy with this 2 options —dmcrypt
—dmcrypt-key-dir on /dev/sdc disk.
……

分析:

问题的提出者试图在部署osd的时候使用 encryption 对 osd 进行加密,在用 ceph-deploy 的时候,部署的时候出现了失败

总结:

这个地方是因为 ceph-deploy 在进行 activate 操作的时候,把这个加密分区当做了 crypto_LUKS 分区格式进行了 mount 操作,这个肯定是不能成功的,因为这个加密盘是需要进行映射操作的,这里缺少了这个操作,不清楚是需要加其他的参数还是怎样,这个地方可以通过其他方式进行处理

在进行 ceph-deploy osd prepare 操作的时候,可以查看看到有一行这个,这个中间的 f6244401-c848-42d1-9096-9a3ee5a136e9 即为 osd 的 fsid

Running command: /usr/sbin/cryptsetup --batch-mode --key-file /root/keydir/f6244401-c848-42d1-9096-9a3ee5a136e9.luks.key luksFormat /dev/sdd1

等待osd prepare 操作做完了以后,就进行下面的操作

1、进行磁盘的映射

cryptsetup --key-file /root/keydir/f6244401-c848-42d1-9096-9a3ee5a136e9.luks.key luksOpen /dev/sdd1 f6244401-c848-42d1-9096-9a3ee5a136e9

2、进行osd的激活

ceph-deploy osd activate /dev/mapper/f6244401-c848-42d1-9096-9a3ee5a136e9

这样就可以了

另外:
取消映射的操作是

cryptsetup remove f6244401-c848-42d1-9096-9a3ee5a136e9

问题二:

ceph fuse closing stale session while still operable (Oliver Dzombic)

问题原文:

Hi,
i am testing on centos 6 x64 minimal install.
i am mounting successfully:
ceph-fuse -m 10.0.0.1:6789,10.0.0.2:6789,10.0.0.3:6789,10.0.0.4:6789
/ceph-storage/
……

分析:

问题的提出者在使用ceph-fuse去挂载集群的时候,写入一个大文件的时候出现无法写入的问题,在mds的日志当中可以看到
closing stale session client.21176728 10.0.0.91:0/1635 after 301.302291 的日志信息

从日志检查过程看
ceph -s 出现了 62 requests are blocked > 32 sec
问题提出者在认证的时候,出现了语法错误 ceph auth list showed 可以检查,后经修改,还是问题一样

查看客户端的请求:
ceph daemon /var/run/ceph/ceph-client.admin.asok objecter_requests

{
"ops": [
{
"tid": 12,
"pg": "6.7230bd94",
"osd": 1,
"object_id": "10000000017.00000004",
"object_locator": "@6",
"target_object_id": "10000000017.00000004",
"target_object_locator": "@6",
"paused": 0,
"used_replica": 0,
"precalc_pgid": 0,
"last_sent": "2016-01-22 23:11:28.788800",
"attempts": 95,
"snapid": "head",
"snap_context": "1=[]",
"mtime": "2016-01-21 23:41:18.001327",
"osd_ops": [
"write 0~4194304 [5@0]"
]

其中

"attempts": 95,

这个可以说明请求了95次还没有回应,从这个分析,应该是问题提出者的环境中的某个osd出现了问题,阻塞了请求

总结:

在无法写入的时候,可以查看下客户端的sock去查看哪个请求被阻塞了,然后去排查对应的osd即可

问题三:

CephFS(James Gallagher)

问题原文

Hi,
I’m looking to implement the CephFS on my Firefly release (v0.80) with an XFS native file system, but so far I’m having some difficulties. After following the ceph/qsg and creating a storage cluster, I have the following topology
……

分析:

问题提出者在配置了 auth 后,在客户端进行cephfs 挂载的时候,报了文件系统的错误,这个原因是问题提出者没有弄清楚 auth 的格式,而用了主机名去替代了用户名称

这个地方是在server端去创建用户

ceph auth get-or-create client.zp mon 'allow *' mds 'allow *' osd 'allow *'

找到认证的key

ceph auth list

然后在客户端挂载的格式为

mount -t ceph 192.168.8.106:6789:/ /mnt -o name=zp,secret={secretkey}

这样就完成了认证模式下的挂载

总结:

在ceph的一些操作中,需要弄清楚里面的操作的格式问题,不然会出现一些很奇怪的问题

问题四:

inkscope version 1.3.1

问题原文

Hi,
We are glad to announce the version 1.3.1 of inkscope.
you have a description of this version at http://inkscope.blogspot.fr/,
the github projet: https://github.com/inkscope/inkscope-packaging
This version has been tested with Firefly, Hammer et Infernalis.
……

分析:

这个是inkscope的作者在发布了新版本后发送到了ceph的邮件列表,增加了一些新的功能,这个地方将单独用一篇文章介绍这个地方的安装
链接如下:

总结

邮件列表不光是提问题的地方,还有一些优秀的资源的发布的作者也可以发布上去

问题五:

Ceph monitors 100% full filesystem, refusing start

问题原文

I have an issue with a (not in production!) Ceph cluster which I’m
trying to resolve.

分析:

这是作者在使用多个mon的时候,数据出现了磁盘满的情况,然后重启mon进行压缩的时候,发现这个到了mon的最小空间阀值无法启动,然后就无法压缩,这个问题,还是因为对硬件的不重视,对软件的要求不清楚造成的

解决办法:

mon的磁盘空间加大,这个在PB级别的集群中更需要重视这个问题,特别是在集群频繁的读写,或者pg变化比较多,osd变化比较多的情况下,这个数据量将是很大的,因为里面是用了leveldb的数据库,并且多个mon之间是需要同步的数据的,然后各自再做compact的操作,所以建议如下:
1、mon的数据分区需要是ssd的,加快数据的读写速度
2、mon的数据分区要100G以上,建议是150G,mon数据大概在80G左右后不会再大量的增长
3、在mon的参数中加入启动压缩的参数 mon_compact_on_start = false 和 mon_compact_on_bootstrap = false
4、尽量不要做在线的compact,这个是一个锁死的过程,此时mon会停止响应,可以采取重启的方式
5、mon的分区中dd 一个4G 左右的大文件,防止真的出现写满的情况下,再去重启进程的时候,好有空间可以释放
如果能按上面的几个操作去配置集群,关于mon的磁盘满的问题基本可以避免或者解决

总结:

关键的地方不要省配置,准备的越多,出问题的概率越小


文档最后更新时间:
2016年01月28日

欢迎打赏 and tell me


pay