Ceph手工搭建中osd degrade状态的解决

在毫无目的的看了几天分布式存储相关的资料之后,终于确定让我在部门实验机房里测试搭建Ceph环境,作为另一个场景的后端存储。感谢Ceph中国社区在完善的文档翻译,减少了我很多的工作量。在此记录下自己搭建部署过程中的一个重大的坑。。。也算记录自己做过了

首先,部门实验机房的机器并不连通外网,在官网推荐的ceph-deploy的方式无法实现(因为需要各主机能够连接网络,下载对应的rpm包和依赖)。本着不折腾的原则,选择通过二进制包的方式而不是编译源码。主要参考手动部署部分内容。

在进行部署前,需要对系统做预检,使系统的外部条件满足Ceph的运行需求,总结起来主要有以下几部分,具体的步骤不再赘述,在文档中都有详尽的解释:

  • 创建无密sudo权限的用户
  • 配置ssh免密登录
  • 通过ntp进行时间同步
  • 开放防火墙相关端口
  • 关闭SELinux

手动部署主要包括两方面:

  • monitor的自举引导
  • 添加对应的osd

大体包括:

  • 配置文件的填写
  • 生成密钥环并拷贝到各Ceph集群机器中
  • 添加监控器视图/CRUSH视图
  • 对应主机创建数据目录

今天主要来聊聊当时我遇到的最大的一个坑——因为ext4文件系统限制导致的osd degrade状态,如果不想看我悲催的经历的话,直接拉到文章最底部。

在搭建完成后,通过

可以看到monitor和osd的节点以及对应的挂载情况,类似文档中描述的那样:

虽然两个osd都是up的状态,而且在配置文件中已经表明了只需要2个副本即可,但是!!!

这两个命令的结果显示,所有pg 都处于 degrade+unclean 的状态,处于不可用的状态。

经过多方搜索,我学习了pg recreate(url1),pg stat相关状态的含义(url2),并且反复重新创建osd(包括删除,重新添加等 url3 url4),以及pg相关的一些文档(url5url6)。然而并不能解决问题。。。当然,反复的尝试也让我排除了一些问题,当然也强化了自己对Ceph的了解。

最终,终于强大的Google终于给我找到了Github上的一个issues链接,总结起来就是:

如果你在OSD的文件系统,选择了ext4的格式,那么请在ceph.conf中添加两行配置

osd_max_object_name_len = 256
osd_max_object_namespace_len = 64

问题解决。。。然而对于模仿官方文档中方式进行操作的新手,并不能把 OSD 的 degrade 定位为因为文件系统的限制而导致的(不过似乎好像可以通过相关的问题日志来获取此问题发生的原因(filename too long)进而定位问题)。当然,也可以怪我并没有完全读官方文档,在硬盘和文件系统推荐这一页中,明确描述了:

OSD 守护进程有赖于底层文件系统的扩展属性( XATTR )存储各种内部对象状态和元数据。底层文件系统必须能为 XATTR 提供足够容量, btrfs 没有限制随文件的 xattr 元数据总量; xfs 的限制相对大( 64KB ),多数部署都不会有瓶颈; ext4 的则太小而不可用。

使用 ext4 文件系统时,一定要把下面的配置放于 ceph.conf 配置文件的 [osd] 段下;用 btrfsxfs 时可以选填。

不知道为什么在配置中使用上述一行并没有生效,只有添加了对name_len相关配置后,才会生效。

发表评论

电子邮件地址不会被公开。 必填项已用*标注