Михаил
15.07.2016
10:54:47
хотя поидее оно и так уже не должно быть
Pavel
15.07.2016
10:54:51
вывожу один лежащий из кластера и на этой же ноде падает ещё один
и как итог получаю всегда два лежащих диска на каждой ноде
Михаил
15.07.2016
10:55:15
о_О
Google
Pavel
15.07.2016
10:55:29
ага
Михаил
15.07.2016
10:56:19
глупое конечно предложение, но
ребут ноды?
нельзя?
Pavel
15.07.2016
10:56:23
прод
боюсь не переживёт
Михаил
15.07.2016
10:56:38
replica_level?
2 ?
Pavel
15.07.2016
10:56:40
3
Михаил
15.07.2016
10:56:54
тогда должно пережить точно_
если не хочешь что бы перестраивалось выведи в set noout
Pavel
15.07.2016
10:57:12
у меня уже наблюдаются проблемы с доступом к данным
Михаил
15.07.2016
10:57:23
хуёва
Pavel
15.07.2016
10:58:13
есть мысли как диагностировать проблему?
Google
Михаил
15.07.2016
11:01:51
а в логах че-то интересное еще есть?
Pavel
15.07.2016
11:02:13
могу кинуть файл логов с osd которую я пытаюсь поднять
Михаил
15.07.2016
11:03:00
а давай
Pavel
15.07.2016
11:03:12
кинул в личку
Dmitry
15.07.2016
11:28:02
мне тоже
логи
Pavel
15.07.2016
11:28:22
http://dropmefiles.com/3uHpl
Dmitry
15.07.2016
11:28:25
версия ceph, система, ядро
в ядрах 4.4-4.7rc5 есть бага которая вылезает с ceph
Pavel
15.07.2016
11:29:21
[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
Dmitry
15.07.2016
11:29:21
вернее 4.2-4.7rc5
Pavel
15.07.2016
11:29:50
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
Dmitry
15.07.2016
11:32:38
ceph health detail
Pavel
15.07.2016
11:34:07
http://dropmefiles.com/5mtJ5
Dmitry
15.07.2016
11:34:21
ceph osd tree
Pavel
15.07.2016
11:35:20
http://dropmefiles.com/XevuI
крашмап выгрузить?
Dmitry
15.07.2016
11:39:37
да
Pavel
15.07.2016
11:42:33
http://dropmefiles.com/64mFg
Dmitry
15.07.2016
11:47:44
на самой машине в dmesg что-нить есть странное ?
Google
Pavel
15.07.2016
11:49:25
не вижу
http://dropmefiles.com/2asPl
но вот на всякий случай
Dmitry
15.07.2016
11:51:02
прям как у тебя баг https://access.redhat.com/solutions/1585713
selinux включен ?
Pavel
15.07.2016
11:52:51
SOLUTION UNVERIFIED
выключен
Dmitry
15.07.2016
11:53:46
карты какие - HBA
Pavel
15.07.2016
11:54:06
ты про контроллеры дисков?
Dmitry
15.07.2016
11:54:20
ага
Pavel
15.07.2016
11:54:38
dell h830
Dmitry
15.07.2016
11:56:19
он в JBOD режиме я так понимаю
cache tiering врублен ?
Pavel
15.07.2016
12:04:38
Он в hda режиме
кэши вырублены
а вообще свои вероятны из-за этого?
+ текущую ситуацию надо как-то исправлять
но особых соображений на этот счёт у меня пока нет
Dmitry
15.07.2016
12:06:45
снапшоты ?
Pavel
15.07.2016
12:06:51
пулов?
Google
Dmitry
15.07.2016
12:07:03
rbd
Pavel
15.07.2016
12:07:35
я правильно понимаю, что ты предлагаешь сделать снапшоты и пересобрать кластер?
Dmitry
15.07.2016
12:10:28
нет - спрашиваю, есть ли клоны, снэпшоты
Pavel
15.07.2016
12:10:33
нет
есть снапшоты пулов которые делались пару недель назад средствами цефа
но это не вариант
поэтому нет
Dmitry
15.07.2016
12:14:27
почитай вот тред http://tracker.ceph.com/issues/12665
есть у меня ощущение что это ваш случай
Pavel
15.07.2016
12:22:41
походу да
Dmitry
15.07.2016
12:22:42
попробуй обновиться до 0.80.11
там есть фикс
Pavel
15.07.2016
12:23:07
думаешь безопасно обновлять прод? :)
Dmitry
15.07.2016
12:23:09
ну вернее фикс есть раньше - не могу сходу найти в каком апдейте
я обновляю - раза 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.
и поглядеть - не уйдет ли
Pavel
15.07.2016
12:24:57
слушай
Google
Pavel
15.07.2016
12:25:06
хотел спросить
нормально будет сейчас убивать снап?
ceph osd pool rmsnap pool pool-snap
таким вот образом
видимо вся фигня именно из-за снапов и пошла
Dmitry
15.07.2016
12:26:32
да - скорее всего
Pavel
15.07.2016
12:26:42
Dmitry
15.07.2016
12:26:55
да
Pavel
15.07.2016
12:27:39
626 requests are blocked > 32 sec
омг
2889 requests are blocked > 32 sec
ОМГ
Dmitry
15.07.2016
12:29:13
чорт
Pavel
15.07.2016
12:29:17
12930 requests are blocked > 32 sec
24624 requests are blocked > 32 sec
пиздец
Михаил
15.07.2016
12:31:59
а я смотрю ceph профи в этом чате нашлись
Dmitry
15.07.2016
12:32:19
да если бы
тут похоже пиздец подкрался
Михаил
15.07.2016
12:32:55
это была ирония сейчас)