Отказывается подниматься файловое хранилище

Итак, случилось страшное...

1. Обновил действующие под OS Centos 6.4 сервера. Оно обновилось... но :(
Все что мого заработать - заработало. А вот само файловое хранилище подниматься отказывается принципиально. А именно:

Оно сделано так - на двух серверах развернут drbd-том. На этом drbd-томе средставами LVM нарезано несколько логических томов. Часть из них отдано под iSCSI, один - под файловую помойку. До обновления все работало как часы под управлением heartbeat'a.

Сейчас, после обновления - сервис drdb стартует и на этом всё приятное кончается.

То есть сам drbd стартует нормально, а вот LVM проинициализироваться на нём не может никак. А дальше - валится всё напрочь... При этом появились сообщения, что параметры activation/thin_check_executable и ctivation/thin_check_options неизвестны... Чего раньше не было...

Пытаюсь руками поднять LVM на drbd-томе. Делаю его primary. Без проблем.
Далее пытаюсь запустить system-config-lvm - сваливается напрочь. Идем чинить руками:
смотрим lvdisplay - вроде информация о lvm-томах на drbd есть. vgscan группу томов находит:
[console]# vgscan
File descriptor 7 (pipe:[85320]) leaked on vgscan invocation. Parent PID 3497: bash
Configuration setting "activation/thin_check_executable" unknown.
Configuration setting "activation/thin_check_options" unknown.
Reading all physical volumes. This may take a while...
Found volume group "vg_drbd" using metadata type lvm2
[/console]
lvscan говорит, что тома не активны:
[console]# lvscan
File descriptor 7 (pipe:[85320]) leaked on lvscan invocation. Parent PID 3497: bash
Configuration setting "activation/thin_check_executable" unknown.
Configuration setting "activation/thin_check_options" unknown.
inactive '/dev/vg_drbd/LV_LUN1' [12,00 GiB] inherit
inactive '/dev/vg_drbd/LV_LUN2' [10,00 GiB] inherit
inactive '/dev/vg_drbd/LV_LUN3' [10,00 GiB] inherit
inactive '/dev/vg_drbd/LV_LUN4' [10,00 GiB] inherit
inactive '/dev/vg_drbd/LV_LUN6' [260,00 GiB] inherit
inactive '/dev/vg_drbd/LV_LUN5' [29,99 GiB] inherit
[/console]
Запускаем руками то, что должен запустить heartbeat:
[console]# /etc/ha.d/resource.d/LVM vg_drbd start
INFO: Activating volume group vg_drbd
INFO: Configuration setting "activation/thin_check_executable" unknown. Configuration setting "activation/thin_check_options" unknown. Reading all physical volumes. This may take a while... Found volume group "vg_drbd" using metadata type lvm2 Found volume group "vg_jerry" using metadata type lvm2
ERROR: Configuration setting "activation/thin_check_executable" unknown. Configuration setting "activation/thin_check_options" unknown. device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument device-mapper: reload ioctl on failed: Invalid argument 6 logical volume(s) in volume group "vg_drbd" now active
ERROR: Generic error
ERROR: Generic error
[/console]
То же самое мы имеем, если просто запустим vgchange:
[console]# vgchange -ay vg_drbd
File descriptor 7 (pipe:[85320]) leaked on vgchange invocation. Parent PID 3497: bash
Configuration setting "activation/thin_check_executable" unknown.
Configuration setting "activation/thin_check_options" unknown.
device-mapper: reload ioctl on failed: Недопустимый аргумент
device-mapper: reload ioctl on failed: Недопустимый аргумент
device-mapper: reload ioctl on failed: Недопустимый аргумент
device-mapper: reload ioctl on failed: Недопустимый аргумент
device-mapper: reload ioctl on failed: Недопустимый аргумент
device-mapper: reload ioctl on failed: Недопустимый аргумент
6 logical volume(s) in volume group "vg_drbd" now active
[/console]
При этом lvscan говорит, что наши тома стали активными. Вот только в /dev ничего нового не появилось. Пытаемся проверить тома
[console]# vgck vg_drbd
File descriptor 7 (pipe:[85320]) leaked on vgck invocation. Parent PID 3497: bash
Configuration setting "activation/thin_check_executable" unknown.
Configuration setting "activation/thin_check_options" unknown.
[/console]
Опять неудача. Пытаемся запустить руками:
[console]# vgmknodes -d vg_drbd
File descriptor 7 (pipe:[85320]) leaked on vgmknodes invocation. Parent PID 3497: bash
Configuration setting "activation/thin_check_executable" unknown.
Configuration setting "activation/thin_check_options" unknown.
The link /dev/vg_drbd/LV_LUN1 should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/vg_drbd/LV_LUN2 should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/vg_drbd/LV_LUN3 should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/vg_drbd/LV_LUN4 should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/vg_drbd/LV_LUN6 should have been created by udev but it was not found. Falling back to direct link creation.
The link /dev/vg_drbd/LV_LUN5 should have been created by udev but it was not found. Falling back to direct link creation.
[/console]
В /dev нужные каталоги появляются.. Но, ни при попытке смотнировать диски оттуда:
[console]# mount /dev/vg_drbd/LV_LUN6 FileServer/
mount: вы должны указать тип файловой системы
[root@jerry drbd]# mount -t ext3 /dev/vg_drbd/LV_LUN6 FileServer/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg_drbd-LV_LUN6,
missing codepage or helper program, or other error
(возможно, это IDE-устройство, а вы на самом деле
используете ide-scsi, и поэтому нужен sr0, sda или
что-нибудь подобное?)
В некоторых случаях полезная информация может быть
найдена в syslog - попробуйте dmesg | tail или что-то
в этом роде
[/console]
Ни по iscsi оно не раздается... Ощущение, что LVM из drbd читать отказывается напрочь.
Итак, что делать бедному админу? Это совсем крах или можно както выкрутиться?

Я в этом не разбираюсь, поскольку дела иметь не доводилось, но обновлялось ли ядро? Если да, я бы попробовал со старым ядром все поднять...

yars написал:

Я в этом не разбираюсь, поскольку дела иметь не доводилось, но обновлялось ли ядро? Если да, я бы попробовал со старым ядром все поднять...

Ядро обновлялось. Но оно обновлялось не раз. И проблем не было никаких. Просто добавлял после перезагрузки соответствующий новому ядру drbd_km и делов... Всё всегда работало и засады с этой позиции я не ждал никаких. А здесь - полный облом. На предыдущее ядро я откатывался. Эффект тот же. Я уже и версию drbd приподнял с 8.4.3 на 8.4.4. Не помогло. Нет никаких идей как выкрутиться. Сейчас сливаю дамп (по dd) drbd-тома. Содержимое там вроде как осмысленное идет.

А почему udev ноды для LUN'ов не создает? Может, что-то изменилось в его правилах по сравнению с состоянием до обновления? Это возможно проверить?

Покажите lvm.conf
какая была версия lvm до обновления и какая стала после?
lvm.conf остался старый или приехал новый?
Чем отличается, от того что есть в .dpkg новой версии?

anonymousRU написал:

Покажите lvm.conf
какая была версия lvm до обновления и какая стала после?
lvm.conf остался старый или приехал новый?
Чем отличается, от того что есть в .dpkg новой версии?

Вот что происходит при попытке хеартбита активировать LVM:
[console]#less /var/log/messages
.......
Dec 28 15:23:10 tom kernel: device-mapper: table: 253:7: linear: dm-linear: Device lookup failed
Dec 28 15:23:10 tom kernel: device-mapper: ioctl: error adding target to table
Dec 28 15:23:10 tom kernel: device-mapper: table: 253:8: linear: dm-linear: Device lookup failed
Dec 28 15:23:10 tom kernel: device-mapper: ioctl: error adding target to table
Dec 28 15:23:10 tom kernel: device-mapper: table: 253:9: linear: dm-linear: Device lookup failed
Dec 28 15:23:10 tom kernel: device-mapper: ioctl: error adding target to table
Dec 28 15:23:10 tom kernel: device-mapper: table: 253:10: linear: dm-linear: Device lookup failed
Dec 28 15:23:10 tom kernel: device-mapper: ioctl: error adding target to table
Dec 28 15:23:10 tom kernel: device-mapper: table: 253:11: linear: dm-linear: Device lookup failed
Dec 28 15:23:10 tom kernel: device-mapper: ioctl: error adding target to table
Dec 28 15:23:10 tom kernel: device-mapper: table: 253:12: linear: dm-linear: Device lookup failed
Dec 28 15:23:10 tom kernel: device-mapper: ioctl: error adding target to table
..... [/console]
Перед этим корявенький вызов vgscan, а после этого уже vgchange обламывается. Я их тексты приводил в старотовом топике.
версии ядра, device-mapper'а и LVM - наипоследнейшие:
[console]# uname -r
2.6.32-431.1.2.0.1.el6.x86_64
# rpm -qa | grep kernel
kernel-devel-2.6.32-431.1.2.0.1.el6.x86_64
kernel-headers-2.6.32-431.1.2.0.1.el6.x86_64
kernel-firmware-2.6.32-431.1.2.0.1.el6.noarch
[root@tom log]# rpm -qa | grep lvm2
lvm2-2.02.100-8.el6.x86_64
lvm2-libs-2.02.100-8.el6.x86_64
[root@tom log]# rpm -qa | grep device-map
device-mapper-1.02.79-8.el6.x86_64
device-mapper-multipath-libs-0.4.9-72.el6.x86_64
device-mapper-event-libs-1.02.79-8.el6.x86_64
device-mapper-persistent-data-0.2.8-2.el6.x86_64
device-mapper-multipath-0.4.9-72.el6.x86_64
device-mapper-event-1.02.79-8.el6.x86_64
device-mapper-libs-1.02.79-8.el6.x86_64
[/console]
До этого было:
[console]# uname -r
2.6.32-358.23.2.el6.x86_64
# rpm -qa | grep kernel
kernel-devel-2.6.32-358.23.2.el6.x86_64
kernel-headers-2.6.32-358.23.2.el6.x86_64
kernel-firmware-2.6.32-358.23.2.el6.noarch
kernel-2.6.32-358.23.2.el6.x86_64
# rpm -qa | grep mapper
device-mapper-multipath-libs-0.4.9-64.el6_4.2.x86_64
device-mapper-event-1.02.77-9.el6_4.3.x86_64
device-mapper-multipath-0.4.9-64.el6_4.2.x86_64
device-mapper-1.02.77-9.el6_4.3.x86_64
device-mapper-libs-1.02.77-9.el6_4.3.x86_64
device-mapper-persistent-data-0.1.4-1.el6.x86_64
device-mapper-event-libs-1.02.77-9.el6_4.3.x86_64
# rpm -qa | grep lvm2
lvm2-2.02.98-9.el6_4.3.x86_64
lvm2-libs-2.02.98-9.el6_4.3.x86_64
[/console]
То есть обновился как device-mapper, так и сам lvm2.
Конфиги - стандартные, по дефолту. Я туда не лазаю без особой нужды. А вот кто именно из обновленных пакетов гадить начал - не пойму. И не знаю как проверить...

И еще в копилку обсуждения:
[console]#dmsetup -v status
....
Name: vg_drbd-LV_LUN6
State: ACTIVE
Read Ahead: 256
Tables present: None
Open count: 1
Event number: 0
Major, minor: 253, 11
Number of targets: 0
UUID: LVM-Mv51lV5e0Be33n2WPY3CbUHs12sw9w1rzL9rFyZktowqThf09fzhLK53sucVHdAd
.....[/console]
Тома, которые видно в таблице присутствуют (значение LIVE), а здесь - опаньки.

yars написал:

А почему udev ноды для LUN'ов не создает? Может, что-то изменилось в его правилах по сравнению с состоянием до обновления? Это возможно проверить?

А он их и не должен создавать ни разу. Этими нодами управляет не udev, а hearbeat через вызовы vg*.

Покажите еще fdisk -l и pvscan

anonymousRU написал:

Покажите еще fdisk -l и pvscan

[console]#fdisk -l
.......
Диск /dev/mapper/vg_jerry-LV_DRBD: 356.5 ГБ, 356482285568 байт
255 heads, 63 sectors/track, 43339 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

# pvscan
Configuration setting "activation/thin_check_executable" unknown.
Configuration setting "activation/thin_check_options" unknown.
PV /dev/vg_jerry/LV_DRBD VG vg_drbd lvm2 [331,99 GiB / 0 free]
PV /dev/mapper/ddf1_4c5349202020202080862925000000004711471100000a28p2 VG vg_jerry lvm2 [464,24 GiB / 0 free]
Total: 2 [796,23 GiB] / in use: 2 [796,23 GiB] / in no VG: 0 [0 ]

[/console]

То есть, сам большой drbd-том виден. И, скорее всего, LVM-информация с него какая-то читается. То есть lvscan LVM-нарезку показывает. А вот дальше - облом. Не хочет воспринимать, как я понимаю, device-mapper какой-то параметр, что ему дает LVM, а именно - lvchange -ay... А вот что это за параметр и почему он не нравится device-mapper'у - для меня есть тайна.

И, самое интересное - отключил drbd (чтобы не попортить том) выполнил команду vgremove vg_drbd. Нарезка убралась, pvscan говорит, что том LV_DRBD без каких либо подтомов. Включаю снова drbd...pvscan содержимого тома не видит и состояние не обновляет. Переключаю primary на другую ноду, там pvscan показывает разделы на томе. Ощущение, что LVM работает вообще с каким-то кэшем, а к drbd-диску не обращается.

Может стоить по чистить /etc/lvm/cache/.cache ?

Интересен вывод dmesg

anonymousRU написал:

Может стоить по чистить /etc/lvm/cache/.cache ?

Нечего там чистить. Пусто.
Вывод dmesg - что именно показывать?
Чем дальше я кувыркаюсь, тем более стойкое у меня ощущение, что СХД превратилось в кирпич...
Что было сделано - вместо одной ноды в drbd подключил новый комп. Данные по drbd на него залились за пару часов. Но и новый комп ничего видеть не захотел.
Как раньше было - поставил drbd-том в primary-режим, настроил на нём LVM-группы, переключился на резервную ноду. Там system-config-lvm прекрасно всё видит и подхватывает настройки. А здесь - полный облом, глухо как в танке.

Можно конечно накатить vgcfgrestore
Но боюсь это только усугубит ситуацию.
Ты одновременно обе ноды обновил?

anonymousRU написал:

Можно конечно накатить vgcfgrestore
Но боюсь это только усугубит ситуацию.
Ты одновременно обе ноды обновил?

Ноды обновлялись одновремеено. vgcfgrestore накатывать пытался. Система её отвергла. Сейчас проинициализировал drbd и пытаюсь создать на нем снова группу томов LVM. Обломайтис....
Запускаю pvcreate /dev/drbd0. Проходит нормально, последующий запуск pvscan показывает, что оно создалось. Далее, по инструкции, vgcreate vg_drbd /dev/drbd0.... И вот тут - опаньки, сообщается, что:
[console]# vgcreate -d vg_drbd /dev/drbd0
File descriptor 7 (pipe:[193300]) leaked on vgcreate invocation. Parent PID 4349: bash
No physical volume label read from /dev/drbd0
Physical volume /dev/drbd0 not found
Failed to write physical volume "/dev/drbd0"
[/console]
И это честно подтверждает pvscan. Созданный физический том LVM пропадает. Нету его.
И что делать дальше?

А вот просто создать файловую систему на этом томе и подвигать её между хостами - это завсегда пожалуйста... Без проблем.
Похоже, придется создать несколько LVM-томов на "базе" и на каждом в отдельности поднимать мелкие (под виртуальные машины) drbd-тома. Которые и раздавать через iSCSI серверам.

Похоже, что что-то разработчики LVM поломали в своем продукте. Гады...
Хотя... Кто знает, что именно поломато. С утра сделал простую операцию - распаковал прямо поверх установленных device-mapper и lvm2 из CentOS 6.4. Не помогло. Эффект был тот же.
Так что есть вариант снова поставить CentOS 6.4 на сервера и влить в него сохраненный образ drbd-тома. Вдруг оживет...

"Cruiser78" написал:

Вывод dmesg - что именно показывать?

Пока не знаю, навеяно этим https://bugzilla.redhat.com/show_bug.cgi?id=956387#c10

Macumazan написал:

[quote="Cruiser78"]Вывод dmesg - что именно показывать?

Пока не знаю, навеяно этим https://bugzilla.redhat.com/show_bug.cgi?id=956387#c10[/quote]

Там немного про другое. Там уже в полный рост lvcreate некорректно себя ведет. А у меня, как я выяснил путем проб и ошибок, до этой стадии не добраться. А именно, на CentOS 6.5 c 431-м ядром:
- Делай раз. То есть создаем DRBD-том. ОК.
- Делай два. Создаем физический LVM-том. То есть pvcreate /dev/drbd0. Проверяем pvscan'ом. OK.
- Делай три. Создаем группу LVM-томов. То есть vgcreate vg_drbd /dev/drbd0. Как учили. Вывод показан выше. Проверяем pvscan'ом. Oops...
И так можно бесконечно повторять второй и третий пункты. Я боюсь, что программы уровня vg* что-то корячат на томе. И как глубоко эта раскоряка проникает я не знаю. То есть, не уверен, что смогу реанимировать из дампа свой том и достать из него данные.
====================================
Собрал на виртуалках следующий стенд:
1. Ноды - одна на CentOS 6.4 (ядро 358), вторая - на СентОС 6.5 (со всеми последними обновлениями).
2. DRBD версии 8.4.4
Результат - если поднимать LVM-тома на ноде CentOS 6.4, то все работает как доктор прописал. Критерий истины - работа system-config-lvm. Работает, тома показывает, нарезает...
Однако, если сделать primary-нодой узел на CentOS 6.5, то всё абсолютно повторяется, как я описывал выше. pvcreate физический том создает, а vgcreate его крушит, system-config-lvm не запускается и вываливается с кучей мне непонятных ошибок....

Так что имеем серьезную системную багу в CentOS 6.5

"Cruiser78" написал:

Так что имеем серьезную системную багу в CentOS 6.5

у меня все на LVM и апдейты RHEL ничего не ломали. А вот вставший раком drbd вообще не редкость. Так что или дело в связке, или в центосе чего то наворотили, что тоже не впервой.

dyasny написал:

[quote="Cruiser78"]Так что имеем серьезную системную багу в CentOS 6.5

у меня все на LVM и апдейты RHEL ничего не ломали. А вот вставший раком drbd вообще не редкость. Так что или дело в связке, или в центосе чего то наворотили, что тоже не впервой.[/quote]

Мне квалификации не хватает понять, где именно собака зарылась. Связка же сделана прямо по учебнику. А именно:
Собственно CentOS, на нем - LVM, на котором выделен отдельный раздел, который отдан под DRBD. Далее, на этом DRBD-томе поднята группа LVM-томов, которые предназначены уже для разных нужд, для файло-помойки или под образы виртуальных машин. Все очень удобно настраивается. И до последнего дня проблем при апдейтах не было. А вот переход с CentOS 6.4 на CentOS 6.5 эту стройную систему поставил раком. Причем, я уверен - раком стоит не drbd. Сейчас я его тривиально развернул (без последующей LVM-нарезки) и накатил на него данные с архива. И оно работает... А вот LVM на него уже не накатить. А вот что именно мешает - не знаю.

"Cruiser78" написал:

Связка же сделана прямо по учебнику

она от этого не станет менее глючной. DRBD падает и ломается, это надо принять и с этим жить. Или перейти на другую систему, о чем я говорил с самого начала

dyasny написал:

[quote="Cruiser78"]Связка же сделана прямо по учебнику

она от этого не станет менее глючной. DRBD падает и ломается, это надо принять и с этим жить. Или перейти на другую систему, о чем я говорил с самого начала[/quote]
Пара простых вопросов:
- DRBD знает, что именно с ним работает? То есть - понимает, что там LVM-тома или просто файловая система развернута?
- Если оно не понимает, а работает как блочное зеркало, то почему LVM на нем в 6.5 гарантированно валится, а в 6.4 - работает? При этом файловая нарезка работает и там и там?

И еще. У меня есть подтвержденное проверкой соображение, что DRBD весьма долго "спасал" положение. А именно - system-config-lvm ведет себя совершенно по разному в зависимости от того, есть drbd или его нет.
Описание опыта на CentOS 6.4:
1. DRBD запущен и работу ведем на его primary-ноде.
1.1 создаем физический том (pvcreate);
1.2. создаем группу томов (vgcreate);
1.3. Запускаем system-config-lvm и видим созданную группу томов.
2. удаляем эти настройки.
3. отключаем DRBD напрочь.
4.1 Создаем физический том LVM на LVM-разделе, на котором раньше жил DRBD;
4.2 Создаем там группу томов (lvcreate);
5. Запускаем system-config-lvm и он сваливается напрочь, не может просканировать LVM на машине.
6. Но... руками (lvcreate) мы тома создать можем, можем создать на них файловые системы и смонтировать в нужное место.
На CentOS6.5 поведение несколько иное. А именно - руками на LVM-томе всё создается. И точно так же как в 6.4 system-config-lvm валится напрочь. Но,если мы пытаемся разместить наши новые тома на drbd-томе, то до lvcreate мы дойти не можем. vgcreate не отрабатывает должным образом и, в отличие от 6.4 system-config-lvm не может запуститься уже после pvcreate.


Как-то так...

Вывод - ошибка появилась сильно ранее, но размещение DRBD