хотя поидее оно и так уже не должно быть

вывожу один лежащий из кластера и на этой же ноде падает ещё один

и как итог получаю всегда два лежащих диска на каждой ноде

о_О

ага

глупое конечно предложение, но ребут ноды?

нельзя?

прод

боюсь не переживёт

replica_level?

2 ?

3

тогда должно пережить точно_

если не хочешь что бы перестраивалось выведи в set noout

у меня уже наблюдаются проблемы с доступом к данным

хуёва

есть мысли как диагностировать проблему?

а в логах че-то интересное еще есть?

могу кинуть файл логов с osd которую я пытаюсь поднять

а давай

кинул в личку

мне тоже

логи

http://dropmefiles.com/3uHpl

версия ceph, система, ядро

в ядрах 4.4-4.7rc5 есть бага которая вылезает с ceph

[root@cephosd3 ~]# ceph -v ceph version 0.80.7 (6c0127fcb58008793d3c8b62d925bc91963672a3) [root@cephosd3 ~]# uname -a Linux cephosd3 3.10.0-327.10.1.el7.x86_64 #1 SMP Tue Feb 16 17:03:50 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux centos 7

вернее 4.2-4.7rc5

cluster 3ee239a5-f8a1-49e8-8abf-d22bf81a8ab3 health HEALTH_WARN 150 pgs degraded; 178 pgs stuck unclean; recovery 85103/5078536 objects degraded (1.676%) monmap e5: 3 mons at {cephmon1=192.168.2.200:6789/0,cephmon2=192.168.2.201:6789/0,cephmon3=192.168.2.202:6789/0}, election epoch 78, quorum 0,1,2 cephmon1,cephmon2,cephmon3 osdmap e62089: 97 osds: 91 up, 91 in pgmap v10784800: 2700 pgs, 2 pools, 7109 GB data, 1819 kobjects 19940 GB used, 282 TB / 301 TB avail 85103/5078536 objects degraded (1.676%) 13 active+degraded+remapped 2522 active+clean 137 active+degraded 28 active+remapped client io 22724 kB/s rd, 7712 kB/s wr, 1387 op/s

ceph health detail

http://dropmefiles.com/5mtJ5

ceph osd tree

http://dropmefiles.com/XevuI

крашмап выгрузить?

да

http://dropmefiles.com/64mFg

на самой машине в dmesg что-нить есть странное ?

не вижу

http://dropmefiles.com/2asPl

но вот на всякий случай

прям как у тебя баг https://access.redhat.com/solutions/1585713

selinux включен ?

SOLUTION UNVERIFIED

выключен

карты какие - HBA

ты про контроллеры дисков?

ага

dell h830

он в JBOD режиме я так понимаю

cache tiering врублен ?

Он в hda режиме

кэши вырублены

а вообще свои вероятны из-за этого?

+ текущую ситуацию надо как-то исправлять

но особых соображений на этот счёт у меня пока нет

снапшоты ?

пулов?

rbd

я правильно понимаю, что ты предлагаешь сделать снапшоты и пересобрать кластер?

нет - спрашиваю, есть ли клоны, снэпшоты

нет

есть снапшоты пулов которые делались пару недель назад средствами цефа

но это не вариант

поэтому нет

почитай вот тред http://tracker.ceph.com/issues/12665

есть у меня ощущение что это ваш случай

походу да

попробуй обновиться до 0.80.11

там есть фикс

думаешь безопасно обновлять прод? :)

ну вернее фикс есть раньше - не могу сходу найти в каком апдейте

я обновляю - раза 2 уже обновлял

но внутри одной мажорной

можно попробовать то что чуваки пишут

By setting osd pg max concurrent snap trims = 0 and noscrub and nodeep-scrub, the cluster was able to finish replicating and we have then re-added all down osd's again. But these 3 parameters/flags need to remain set to prevent "random" OSD's to go down.

и поглядеть - не уйдет ли

слушай

хотел спросить

нормально будет сейчас убивать снап?

ceph osd pool rmsnap pool pool-snap

таким вот образом

видимо вся фигня именно из-за снапов и пошла

да - скорее всего

да - скорее всего

это к безопасности?

да

626 requests are blocked > 32 sec

омг

2889 requests are blocked > 32 sec

ОМГ

чорт

12930 requests are blocked > 32 sec

24624 requests are blocked > 32 sec

пиздец

а я смотрю ceph профи в этом чате нашлись

да если бы

тут похоже пиздец подкрался

это была ирония сейчас)