ceph osd 由于“No space left on device” 异常down,通过扩容文件系统或者显式运行osd进程解决

首页 > ceph osd 由于“No space left on device” 异常down,通过扩容文件系统或者显式运行osd进程解决

ceph osd 由于“No space left on device” 异常down,通过扩容文件系统或者显式运行osd进程解决

文章目录

- - - - ceph版本:
      - 环境配置：
      - 异常问题：
      - 问题解决：
      - 总结

ceph版本:

ceph 12.2.1

环境配置：

tier_pool 16个分区大小800G 的osd容量 3副本

data_pool 32个4T盘 3副本

异常问题：

ps:在分布式存储中遇到任何问题都不要先去通过重设存储节点，清除磁盘数据来解决，一定要利用分布式存储系统的高可用性来先进行操作。大部分问题只需要耐心分析就可以找到高效，可靠的解决方案。

出现异常，报出如下段错误:

 0> 2019-06-18 09:18:14.340970 7f38be251700 -1 /get_rpm_compile/rpmbuild/ceph-12.2.1/BUILD/ceph-12.2.1/src/os/bluestore/KernelDevice.cc: In function 'void KernelDevice::_aio_thread()' thread 7f38be251700 time 2019-06-18 09:18:14.338169
/get_rpm_compile/rpmbuild/ceph-12.2.1/BUILD/ceph-12.2.1/src/os/bluestore/KernelDevice.cc: 372: FAILED assert(r >= 0)ceph version 12.2.1.05 (3e7492b9ada8bdc9a5cd0feafd42fbca27f9c38e) luminous (stable)1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x110) [0x7f38d1153560]2: (KernelDevice::_aio_thread()+0x4b5) [0x7f38d10f7f75]3: (KernelDevice::AioCompletionThread::entry()+0xd) [0x7f38d10fc6ed]4: (()+0x7dc5) [0x7f38cdd19dc5]5: (clone()+0x6d) [0x7f38cce0d76d]NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this.

解决方式如下：

根据源码对该异常的描述，在这里断言是因为底层bluestore在处理落盘io时使用异步写方式aio_thread，此时无法继续向磁盘写入数据导致该问题

增加osd日志级别debug_bluestore = 10和debug_udev = 10,再次尝试启动发现打印出来的断言异常错误码为-28

-5> 2019-06-18 13:37:48.192979 7fd821767d00 10 stupidalloc reserve need 0x100000 num_free 0x772900000 num_reserved 0x0
-4> 2019-06-18 13:37:48.192985 7fd821767d00 10 stupidalloc allocate_int want_size 0x100000 alloc_unit 0x100000 hint 0x0
-3> 2019-06-18 13:37:48.192999 7fd821767d00  5 bdev(0x7fd82c8eba00 /var/lib/ceph/osd/ceph-9/block) aio_write 0x60c8300000~1000 aio 0x7fd82cd7c010
-2> 2019-06-18 13:37:48.193029 7fd821767d00 10 bdev aio_wait 0x7fd82c520900 waiting for 1 aios to complete
-1> 2019-06-18 13:37:48.193034 7fd80f2ee700 10 bdev(0x7fd82c8eba00 /var/lib/ceph/osd/ceph-9/block) _aio_thread finished aio 0x7fd82cd7c010 r -28 ioc 0x7fd82c520900 with 0 aios left

因为该问题为数据写盘时报出的问题，所以为系统可识别的问题，则当前环境执行命令perror 28,则发现如下问题：OS error code 28: No space left on device

检查osd所在磁盘的占用情况

df -h

/dev/sdf1                             97M  5.4M   92M   6% /var/lib/ceph/osd/ceph-32
/dev/sdd1                             97M  5.4M   92M   6% /var/lib/ceph/osd/ceph-35
/dev/sdc1                             97M  5.4M   92M   6% /var/lib/ceph/osd/ceph-34
/dev/sdg1                             97M  5.4M   92M   6% /var/lib/ceph/osd/ceph-33
tmpfs                                 13G     0   13G   0% /run/user/0
/dev/sde1                            800G  800G  299M 100% /var/lib/ceph/osd/ceph-7
/dev/sdb1                            788G  748G     0 100% /var/lib/ceph/osd/ceph-9

发现osd.9所在文件系统可用容量为0

ps:

当前环境的ceph部署情况是存在tier_pool的情况，我们使用ssd做普通hdd的db/wal存放同时划分一个分区，利用该分区部署osd.所以格式化出的文件系统显示容量包括其中block写入数据的容量。此时该osd已经被写满，文件系统发我继续读写文件导致osd异常down掉

至此，osd 异常问题已经定位，按照如下两种方式可以尝试解决

问题解决：

方法一：数据重构代价大，时间成本高。修复当前分区上的osd，但是需要损坏一个副本的hdd ，总体数据不会丢

我们针对分区osd所在的分区文件系统进行扩容。如果你的节点仍然可以继续插入磁盘，则推荐直接看方法二来解决

df -T查看当前分区类型

/dev/sdb1                           ext4      825564056 783604632         0 100% /var/lib/ceph/osd/ceph-8
/dev/sde1                           ext4      825564056 783604632         0 100% /var/lib/ceph/osd/ceph-6

发现文件系统类型都为ext4

lsblk查看该osd所在磁盘分布

sde                           8:64   0 894.3G  0 disk 
├─sde1                        8:65   0   800G  0 part /var/lib/ceph/osd/ceph-6
├─sde2                        8:66   0    30G  0 part 
├─sde3                        8:67   0     1G  0 part 
├─sde4                        8:68   0    30G  0 part 
└─sde5                        8:69   0     1G  0 part

此时该osd所在磁盘一分区做的是osd，剩下的分区做其他的hdd普通盘osd的db/wal，我们想要取sde2这个分区的容量加入到sde1分区中，所以需要损坏db分区在sde2的hdd

最后通过命令ceph osd metadata osd.34发现该osd用到的db设备在sde2上

执行如下步骤:

操作osd

#设置集群的osd不进行数据重构，方便我们恢复好osd重新加回来，不会产生太多重构。当然，前提是需要暂停掉当前ceph集群的上层业务
ceph osd set norecover
ceph osd set nobackfill systemctl stop ceph-osd@34

操作磁盘

#卸载挂载的目录，不然无法操作分区
umount /var/lib/ceph/osd/ceph-6#这里需要记录此时环境中的1分区的start sector和2分区的end sector，因为我们现在做的事两个分区容量合并
[root@node5 ~]# partx /dev/sde
NR      START        END    SECTORS SIZE NAME            UUID1       2048 1677723647 1677721600 800G ceph data osd.6 2db49ebf-39a8-40bc-8d9e-c38ce50b48272 1677723648 1740638207   62914560  30G ceph block.db   357c32dc-a165-4f5b-97cd-ff2202946fc83 1740638208 1742735359    2097152   1G ceph block.wal  8e2a9f54-634f-40d1-9310-4ea2f40e61ae4 1742735360 1805649919   62914560  30G ceph block.db   356ae8cd-ed80-4afd-b67b-c07e5e00352e5 1805649920 1807747071    2097152   1G ceph block.wal  d8421c05-c2d8-4803-927d-4db99a7f6a61#这里一定要记得不能使用-z 或者 -Z 或者 -o 选项,不能清除磁盘数据，我们只是删除分区
sgdisk -d 1 /dev/sde
sgdisk -d 2 /dev/sd3#重新创建分区
sgdisk --new=1:2048:1740638207 --mbrtogpt /dev/sde#检查已存在的文件系统数据
[root@node5 ~]# e2fsck -f /dev/sde1
e2fsck 1.42.9 (28-Dec-2013)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sdl1: 25/13107200 files (4.0% non-contiguous), 871831/52428800 blocks#重新调整文件系统大小
[root@node5 ~]# resize2fs /dev/sde1
resize2fs 1.42.9 (28-Dec-2013)
Resizing the filesystem on /dev/sdl1 to 60293120 (4k) blocks.
The filesystem on /dev/sdl1 is now 60293120 blocks long.

至此我们已经为激活做了准备，接下来直接对合并后的1分区执行

ceph-disk -v activate /dev/sde1即可激活

使用df -h查看文件系统容量已经变更为830G,当前osd拥有可以用空间
激活后我们需要重新恢复刚才损坏的db分区所在的osd

那就是使用sde磁盘剩余容量匀出30G 用作db的分区

sgdisk -n 2:+0:+30G /dev/sde

设置分区typecode,因为手动做分区，ceph不会为分区创建链接至uuid的链接文件

sgdisk --typecode=2:30cd0809-c2b2-499c-8879-2d6b78529876 -- /dev/sdb

再次重新部署osd.34,osd.34所在磁盘为sdb ,因为存储池是三副本，我们重建不会丢失集群数据

ceph-disk -v prepare /dev/sdb --block.db /dev/sde2 --block.wal /dev/sde3

ceph-disk -v activate /dev/sdb1

恢复集群的重构

ceph osd unset norecover
ceph osd unset nobackfill

方法二：数据重构代价小，时间成本低。如果存储设备可以再次插入磁盘，即可选择该方案

该解决办法是通过重新制定down掉的问题osd的/var/lib/ceph/osd/ceph-6目录下的配置文件为其他还有剩余空间的配置，即可显示运行起来down掉的问题osd

在当前存储节点重新插入一块和down掉的osd所在磁盘容量接近的磁盘，做出分区，然后格式化足够容量的文件系统
```
sgdisk -n 1:+2G:+1T /dev/sdg
mkfs.xfs -t /dev/sdg1
mkdir /ceph-6
mount /dev/sdg1 /ceph-6
```
接下来我们需要将osd.6的配置文件拷贝到我们挂载的目录下

cp /var/lib/ceph/osd/ceph-6/* /ceph-6
拷贝完成之后修改目录权限

chown -R ceph:ceph /ceph-6/

显示执行osd进程，并制定进程加载的配置文件路径，这里使用 --osd-data参数指定路径

[root@node5 /]# /usr/bin/ceph-osd -f --cluster ceph --id 6 --setuser ceph --setgroup ceph --osd-data /ceph-6 
starting osd.6 at - osd_data /ceph-6 /var/lib/ceph/osd/ceph-6/journal
2019-06-19 12:42:29.216032 7f73d1ec8d00 -1 osd.6 19889 log_to_monitors { default=true}

此时osd进程已经起来了，按照此方式将集群其他的类似问题的osd都做如上操作，等集群数据均衡完全之后设置

#这里我们要做的操作是为了一个一个停掉用上述方法拉起啦的osd，修改osd的bluestore_block_size参数配置，降低block_size大小，就可以降低分区文件系统占用情况了。此时停掉osd，为了保证数据不丢失，需要减少重构
ceph osd set norecover
ceph osd set nobackfill#停掉上述进程之后编辑/etc/ceph/ceph.conf，修改block容量大小，降低5个G，即由原来的800G 变为795G
[osd.6]
bluestore_block_size = 853624750080#重新创建该osd
ceph osd rm osd.6 
ceph auth rm osd.6
umount /var/lib/ceph/osd/ceph-6
sgdisk -z /dev/sde1
ceph-disk -v prepare /dev/sde1;ceph-disk -v activate /dev/sde1#再恢复重构 ，这里是为了让重建后的osd能够获取所在资源池其他osd的副本数据
ceph osd unset norecover
ceph osd unset nobackfill#等恢复完成之后，pg状态都变为active+clean之后再对其他osd做以上类似操作，保证我们操作过程中pg数据不会丢失

总结

ceph分布式存储有较强的高可用性以及可扩展性，当集群异常时候一定要紧抓住ceph的高可用性，只要是冗余内，我们就可以安心恢复集群，定位问题。即使是冗余外，我们也要尝试尽可能降低数据丢失的体量，不能一味得尝试重建，删除集群来规避问题。