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/sde3ceph-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的高可用性，只要是冗余內，我們就可以安心恢復集群，定位問題。即使是冗余外，我們也要嘗試盡可能降低數據丟失的體量，不能一味得嘗試重建，刪除集群來規避問題。
總結
以上是生活随笔為你收集整理的ceph osd 由于“No space left on device” 异常down,通过扩容文件系统或者显式运行osd进程解决的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 编译ceph源码：cython modu
- 下一篇： centos下将vim配置为强大的源码阅