Thank you for reading this post, don't forget to subscribe!

Замена поврежденного OSD

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/2/html/troubleshooting_guide/troubleshooting-osds

 

Если у нас по каким-то при­чи­нам один из osd ушел в down - в дан­ном при­ме­ре это osd 0

ceph osd tree

ID CLASS WEIGHT  TYPE NAME               STATUS REWEIGHT PRI-AFF

-1       0.05878 root default

-3       0.01959     host tst-vsrv-ceph1

0   hdd 0.00980         osd.0             down  1.00000 1.00000

3   hdd 0.00980         osd.3               up  1.00000 1.00000

-5       0.01959     host tst-vsrv-ceph2

1   hdd 0.00980         osd.1               up  0.90002 1.00000

4   hdd 0.00980         osd.4               up  1.00000 1.00000

-7       0.01959     host tst-vsrv-ceph3

2   hdd 0.00980         osd.2               up  0.90002 1.00000

5   hdd 0.00980         osd.5               up  1.00000 1.00000

 

И при этом при пере­за­пус­ке osd.0 он через вре­мя падает

systemctl restart ceph-osd@0.service

В этом слу­чае мы можем про­сто выве­сти нера­бо­та­ю­щий osd из кла­сте­ра, пере­со­здать его и вер­нуть в кластер

ceph osd out osd.0

ceph osd crush remove osd.0

ceph auth del osd.0

ceph osd rm osd.0

ceph osd tree   здесь уви­дим что наш osd выве­ден из кластера

umount /var/lib/ceph/osd/ceph-0

lvremove /dev/vg-ceph/ceph   важ­но!!!! Необ­хо­ди­мо уда­лить logical volume, кото­рый исполь­зо­вал­ся под osd.0 толь­ко после это­го полу­чить­ся создать его и вер­нуть обрат­но в кластер

lvcreate -L14G -n ceph vg-ceph

ceph-deploy osd create --data vg-ceph/ceph tst-vsrv-ceph1  (из под сepha, из нуж­ной директории)

ceph osd tree   видим что osd 0 появился

Ждем минут 5 пока прой­дет реба­лан­си­ров­ка Ceph и он воз­вра­ща­ет­ся в состо­я­ние  HEALTH_OK

ceph health detail  узнать деталь­но какая osd забилась

ceph osd tree

ceph osd df

!!! Дан­ную про­це­ду­ру заме­ны мож­но так же при­ме­нить, если  кла­стер пере­шел в состо­я­ние HEALTH_ERROR. Так как в дан­ном состо­я­нии рас­ши­ре­ние Logical Volume нам не помо­жет, мы можем выве­сти запол­нив­ший­ся OSD (уви­дим мы ее коман­дой ceph health detail), так же уда­лить LVM и пере­со­здать ее с нуж­ным раз­ме­ром. В этот момент на кла­сте­ре про­ис­хо­дит реба­лан­си­ро­ка по OSD, !!! Дожи­да­ем­ся её окон­ча­ния и вво­дим новый OSD в кла­стер. Про­ис­хо­дит после­ду­ю­щая реба­лан­си­ров­ка и спу­стя неко­то­рое вре­мя кла­стер дол­жен вер­нуть­ся в рабо­чее состояние.

 

Удаляем RBD, если она заблокирована и не удаляется

Если мы про­ве­ри­ли вез­де, что rbd, кото­рую уда­ля­ем не при­мон­ти­ро­ва­на и не вхо­дит в map, то один из спо­со­бов уда­лить  ее следующий:

rbd rm rbd_name

2019-09-19 18:00:45.834 7f0777fff700 -1 librbd::image::RemoveRequest: 0x5600042e5ad0 check_image_watchers: image has watchers - not removing

Removing image: 0% complete…failed.

rbd: error: image still has watchers

This means the image is still open or the client using it crashed. Try again after closing/unmapping it or waiting 30s for the crashed client to timeout.

rbd status rbd_name

Watchers:

watcher=10.242.146.15:0/231140603 client.27127586 cookie=18446462598732840965

ceph osd blacklist add 10.10.10.15:0/231140603

blacklisting 10.10.10.15:0/231140603 until 2019-09-19 19:03:11.057368 (3600 sec)

rbd rm rbd_name

Removing image: 100% complete…done.

ceph osd blacklist rm 10.10.10.15:0/231140603

un-blacklisting 10.10.10.15:0/231140603