1 Тема от Cruiser78 (28.12.2013 19:23:45 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]

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

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

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

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

+ открыть спойлер

ResourceManager(default)[14530]:    2013/12/28_15:14:21 info: Running /etc/ha.d/resource.d/drbddisk drbd start
LVM(LVM)[14606]:    2013/12/28_15:14:21 WARNING: LVM Volume vg_drbd is not available (stopped)
/usr/lib/ocf/resource.d//heartbeat/LVM(LVM)[14596]:    2013/12/28_15:14:21 INFO:  Resource is stopped
ResourceManager(default)[14530]:    2013/12/28_15:14:21 info: Running /etc/ha.d/resource.d/LVM vg_drbd start
LVM(LVM)[14656]:    2013/12/28_15:14:21 INFO: Activating volume group vg_drbd
LVM(LVM)[14656]:    2013/12/28_15:14:21 INFO: File descriptor 4 (socket:[106359]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 5 (socket:[106360]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 6 (/proc/loadavg) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 7 (socket:[106392]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 8 (socket:[106375]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 9 (socket:[106364]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 10 (socket:[106370]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 11 (socket:[106366]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 13 (socket:[106372]) leaked on vgscan invocation. Parent PID 14680: /bin/sh File descriptor 14 (socket:[106377]) leaked on vgscan invocation. Parent PID 14680: /bin/sh 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
LVM(LVM)[14656]:    2013/12/28_15:14:21 ERROR: File descriptor 4 (socket:[106359]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 5 (socket:[106360]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 6 (/proc/loadavg) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 7 (socket:[106392]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 8 (socket:[106375]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 9 (socket:[106364]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 10 (socket:[106370]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 11 (socket:[106366]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 13 (socket:[106372]) leaked on vgchange invocation. Parent PID 14690: /bin/sh File descriptor 14 (socket:[106377]) leaked on vgchange invocation. Parent PID 14690: /bin/sh 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
/usr/lib/ocf/resource.d//heartbeat/LVM(LVM)[14648]:    2013/12/28_15:14:21 ERROR:  Generic error
ERROR:  Generic error
ResourceManager(default)[14530]:    2013/12/28_15:14:21 ERROR: Return code 1 from /etc/ha.d/resource.d/LVM

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

Пытаюсь руками поднять LVM на drbd-томе. Делаю его primary. Без проблем.
Далее пытаюсь запустить system-config-lvm - сваливается напрочь. Идем чинить руками:
смотрим lvdisplay - вроде информация о lvm-томах на drbd есть. vgscan группу томов находит:

 Консоль:
# 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

lvscan говорит, что тома не активны:
 Консоль:
# 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

Запускаем руками то, что должен запустить heartbeat:
 Консоль:
# /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

То же самое мы имеем, если просто запустим vgchange:
 Консоль:
# 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

При этом lvscan говорит, что наши тома стали активными. Вот только в /dev ничего нового не появилось. Пытаемся проверить тома
 Консоль:
# 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.

Опять неудача. Пытаемся запустить руками:
 Консоль:
# 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.

В /dev нужные каталоги появляются.. Но, ни при попытке смотнировать диски оттуда:
 Консоль:
# 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 или что-то
       в этом роде

Ни по iscsi оно не раздается... Ощущение, что LVM из drbd читать отказывается напрочь.
Итак, что делать бедному админу? Это совсем крах или можно както выкрутиться?

2 Ответ от yars

  • yars
  • yars
  • Slacker
  • Неактивен
  • Откуда: Тамбовская область
  • Зарегистрирован: 23.03.2012
  • Сообщений: 10,043
  • Репутация : [ 309 | 1 ]

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

3 Ответ от Cruiser78

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
yars пишет:

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

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

4 Ответ от yars

  • yars
  • yars
  • Slacker
  • Неактивен
  • Откуда: Тамбовская область
  • Зарегистрирован: 23.03.2012
  • Сообщений: 10,043
  • Репутация : [ 309 | 1 ]

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

5 Ответ от anonymousRU

  • Зарегистрирован: 20.10.2010
  • Сообщений: 66
  • Репутация : [ 4 | 0 ]

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

6 Ответ от Cruiser78 (28.12.2013 21:01:14 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
anonymousRU пишет:

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

Вот что происходит при попытке хеартбита активировать LVM:

 Консоль:
#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
.....

Перед этим корявенький вызов vgscan, а после этого уже vgchange обламывается. Я их тексты приводил в старотовом топике.
версии ядра, device-mapper'а и LVM - наипоследнейшие:
 Консоль:
# 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

До этого было:
 Консоль:
# 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

То есть обновился как device-mapper, так и сам lvm2.
Конфиги - стандартные, по дефолту. Я туда не лазаю без особой нужды. А вот кто именно из обновленных пакетов гадить начал - не пойму. И не знаю как проверить...

И еще в копилку обсуждения:

 Консоль:
#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
.....

Тома, которые видно в таблице присутствуют (значение LIVE), а здесь - опаньки.

7 Ответ от Cruiser78

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
yars пишет:

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

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

8 Ответ от anonymousRU

  • Зарегистрирован: 20.10.2010
  • Сообщений: 66
  • Репутация : [ 4 | 0 ]

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

9 Ответ от Cruiser78 (29.12.2013 03:51:57 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
anonymousRU пишет:

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

 Консоль:
#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   ]

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

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

10 Ответ от anonymousRU

  • Зарегистрирован: 20.10.2010
  • Сообщений: 66
  • Репутация : [ 4 | 0 ]

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

11 Ответ от Macumazan

  • Зарегистрирован: 23.02.2010
  • Сообщений: 816
  • Репутация : [ 25 | 0 ]

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

Сайт Macumazan

12 Ответ от Cruiser78

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
anonymousRU пишет:

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

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

13 Ответ от anonymousRU

  • Зарегистрирован: 20.10.2010
  • Сообщений: 66
  • Репутация : [ 4 | 0 ]

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

14 Ответ от Cruiser78 (29.12.2013 21:53:20 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
anonymousRU пишет:

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

Ноды обновлялись одновремеено. vgcfgrestore накатывать пытался. Система её отвергла. Сейчас проинициализировал drbd и пытаюсь создать на нем снова группу томов LVM. Обломайтис....
Запускаю pvcreate /dev/drbd0. Проходит нормально, последующий запуск pvscan показывает, что оно создалось. Далее, по инструкции, vgcreate vg_drbd /dev/drbd0.... И вот тут - опаньки, сообщается, что:

 Консоль:
# 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"

И это честно подтверждает pvscan. Созданный  физический том LVM пропадает. Нету его.
И что делать дальше?

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

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

15 Ответ от Macumazan

  • Зарегистрирован: 23.02.2010
  • Сообщений: 816
  • Репутация : [ 25 | 0 ]
Cruiser78 пишет:

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

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

Сайт Macumazan

16 Ответ от Cruiser78 (30.12.2013 16:33:05 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
Macumazan пишет:
Cruiser78 пишет:

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

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

Там немного про другое. Там уже в полный рост 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

17 Ответ от dyasny

  • dyasny
  • Пользователь
  • Неактивен
  • Зарегистрирован: 15.05.2012
  • Сообщений: 2,163
  • Репутация : [ 67 | 1 ]
Cruiser78 пишет:

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

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

18 Ответ от Cruiser78

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
dyasny пишет:
Cruiser78 пишет:

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

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

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

19 Ответ от dyasny

  • dyasny
  • Пользователь
  • Неактивен
  • Зарегистрирован: 15.05.2012
  • Сообщений: 2,163
  • Репутация : [ 67 | 1 ]
Cruiser78 пишет:

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

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

20 Ответ от Cruiser78 (31.12.2013 09:57:46 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
dyasny пишет:
Cruiser78 пишет:

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

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

Пара простых вопросов:
- 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

21 Ответ от dyasny

  • dyasny
  • Пользователь
  • Неактивен
  • Зарегистрирован: 15.05.2012
  • Сообщений: 2,163
  • Репутация : [ 67 | 1 ]
Cruiser78 пишет:

DRBD знает, что именно с ним работает? То есть - понимает, что там LVM-тома или просто файловая система развернута?

нет, это просто блочное устройство.

Cruiser78 пишет:

Если оно не понимает, а работает как блочное зеркало, то почему LVM на нем в 6.5 гарантированно валится, а в 6.4 - работает? При этом файловая нарезка работает и там и там?

подозреваю что где то слетает оффсет в который прописана метадата

22 Ответ от Cruiser78 (01.01.2014 01:29:08 отредактировано Cruiser78)

  • Cruiser78
  • Пользователь
  • Неактивен
  • Откуда: Санкт-Петербург
  • Зарегистрирован: 22.02.2010
  • Сообщений: 2,433
  • Репутация : [ 98 | 0 ]
dyasny пишет:

подозреваю что где то слетает оффсет в который прописана метадата

Подозрение справедливое. Но... Никакого оффсета не слетает. Специально сравнил конфигурации LVM-тома. Забэкапленные и нынешние. Один в один. Здесь нет различий. А вот поражения внутри тома в полный рост имеем. У меня на drbd-томе было развернуто 6 LVM-томов. Один под файловую помойку и 5 под виртуальные машины, доступ к которым делался по iSCSI. После краха ни один том не ожил. То есть - все полностью дохлые и ничего в системе не возбуждают. С помощью R-Studio вытащил из покойника кучу файлов. Но... Отдельные спасенные "файлы" имеют совсем произвольное содержимое. То есть файловая система (файлового сервера) там накрылась полным медным тазом. Конечно, я виноват в том, что не делал регулярно fsck на эту файловую систему, полагал, что при очередной перезагрузке компа и её монтировании  она проверится. Но вот только сервер перегружался не чаще чем раз в месяц. Возможно там разрушения самонакопились. Но вот почему рухнули и другие разделы, с виртуалками (причем все одновременно)- не знаю. Для меня - вероятность такого разрушения равна нулю. Но, тем не менее оно рухнуло. Причем все 6 томов одновременно. Ввод простой - что-то их крушило единовременно. Что-то в системе колом встало и тома обрушило. Но что именно крушило - догадок нет никаких.

23 Ответ от dyasny

  • dyasny
  • Пользователь
  • Неактивен
  • Зарегистрирован: 15.05.2012
  • Сообщений: 2,163
  • Репутация : [ 67 | 1 ]
Cruiser78 пишет:

Подозрение справедливое. Но... Никакого оффсета не слетает.

Cruiser78 пишет:

Специально сравнил конфигурации LVM-тома. Забэкапленные и нынешние. Один в один. Здесь нет различий.

Cruiser78 пишет:

А вот поражения внутри тома в полный рост имеем.

ну как бы испорченная метадата, или правильная метадата, указывающая на уехавший оффсет приводят к одному результату

Cruiser78 пишет:

Что-то в системе колом встало и тома обрушило. Но что именно крушило - догадок нет никаких.

DRBD ab