Жила-была у меня машина с XenServer 6.5 на борту и несколькими массивами из SATA-дисков. В последнее время перестало хватать быстодействия SATA и было решено заменить один массив на SAS-диски. Для этих целей был найден RAID-контроллер Adaptec 3805 (знаю, что старье, зато халява).
После успешного создания RAID-массива из SAS-дисков(каюсь, использовал адаптековский raid) и добавления оного как lvm-storage, начал перенос одного из образов виртуальных машин на него. В процессе созерцания прогресса переноса закралось подозрение о неладном, так как изменился тон звучания сервера. А когда сервер ушел в самостоятельную перезагрузку, я начал понемногу седеть… И окончательно меня добило то, что после перезагрузки я не нашел переносимый образ ни в одном из хранилищ, а само новое хранилище отображается со статусом «не доступно».
После непродолжительной прогулки для успокоения нервов и чашки кофе я закатал рукава (ага, на футболке то) и начал думать как восстановить образ…
Для начала, естественно, полез в логи и увидел, что при создании хранилища из массива SAS произошла ошибка:
Ошибка означает, что хранилище не доступно. Я решил проверить физические тома lvm через pvdisplay и не увидел созданного тома на SAS-массиве. pvs тоже не обнаружил тома.
Это означало, что хранилище, на самом деле, не создалось. Точнее создался объект хранилища в XenServer, но при этом он не был связан с физическим хранилищем. Почему XenServer так себя повел, и, тем более, позволил перенести образ в это хранилище, я так и не выяснил.
Получается, что образ на SAS-массиве можно даже не искать, так как физически на него ничего не переносилось. Значит нужно пробовать восстанавливать образ с хранилища, на котором он был изначально.
Поиск в интернете на тему восстановления логических томов LVM задал начальный вектор раскопок.
LVM хранит свою текущую конфигурацию в /etc/lvm/backup/ и, в обычных условиях, архив старых конфигураций в виде бинарных файлов, в /etc/lvm/archive/. UUID хранилища XenServer соответствует имени LVM VolumeGroup. Но, оказывается, в XenServer этот самый архив отключен:
Дальнейшие поиски показали, что lvm хранит архив всех конфигураций VolumeGroup в начальных секторах этих самых VolumeGroup. Так как у меня хранилище расположено на отдельном массиве, то просматриваю начало этого массива:
Если видно что-то похожее на конфиги, то можно снять дамп этих секторов для более удобного чтения (в моем случае архив занимал 100Мб):
Так же дамп можно снять через команду lvmdump.
В дампе ищу конфиг, дата которого предшествует моменту пропажи образа:
Из этого конфига нужна только запись, соответствующая пропавшему образу (та запись, которая отсутствует в текущем конфиге в /etc/lvm/backup/<Соответствующий VG>, в моем случае VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89). Переписываю ее в текущую конфигурацию и даю LVM команду восстановить VG из бэкапа:
Проверяю, что Logical Volume подхватился:
Если сейчас сделать поиск по хранилищу (через XenCenter или xe sr-scan), то XenServer успешно затрет эту запись и все придется делать заново. Как я понял, XenServer не видит у себя VDI (образа диска) с UUID, соответствующем UUID нашему восстановленному Logical Volume.
XenServer, при использовании lvm, хранит образы дисков напрямую в Logcal Volume. Точнее Logical Volume это и есть VHD-образ. Поэтому я предположил, что можно заставить XenServer увидеть образ, скопировав его поверх другого, такого же размера.
Для копирования раздела активирую разделы в этом VG:
Теперь есть доступ к разделу LVM, значит можно скопировать этот раздел с помощью dd:
После того, как скопированный образ добавился в виртуальной машине, а так же после того, как машина стартанула с этого образа, моему счастью не было предела!
Однако не все так радужно. Нужно было еще выключить сервер, чтобы вытащить глючный контроллер. А когда я его включил образ снова пропал! Получается, что XenServer при запуске сверяет UUID образа в LVM c UUID в своей базе и, если они не совпадают, образ удаляется.
Пока ковырял LVM заметил, что при переносе образа из одного хранилища в другое так же меняется и его UUID и, исходя из этого, предположил, что можно окончательно воскресить образ, просто скопировав переписанный через dd образ в другое хранилище. Это должно обновить UUID в образе, сопоставив его в UUID в базе. Повторяем все процедуры заново, после чего переносим образ на временно созданное для этого хранилище, добавляем к виртуальной машине и пробуем ее запустить. Запуск проходит нормально.
Перезагружаем сервер, трясущимися от нетерпения и усталости руками проверяем список образов и… образ на месте! Счастью нет предела и, довольный собой, я удаляюсь в закат…
После успешного создания RAID-массива из SAS-дисков(каюсь, использовал адаптековский raid) и добавления оного как lvm-storage, начал перенос одного из образов виртуальных машин на него. В процессе созерцания прогресса переноса закралось подозрение о неладном, так как изменился тон звучания сервера. А когда сервер ушел в самостоятельную перезагрузку, я начал понемногу седеть… И окончательно меня добило то, что после перезагрузки я не нашел переносимый образ ни в одном из хранилищ, а само новое хранилище отображается со статусом «не доступно».
После непродолжительной прогулки для успокоения нервов и чашки кофе я закатал рукава (ага, на футболке то) и начал думать как восстановить образ…
Для начала, естественно, полез в логи и увидел, что при создании хранилища из массива SAS произошла ошибка:
Error code: SR_BACKEND_FAILURE_47
Ошибка означает, что хранилище не доступно. Я решил проверить физические тома lvm через pvdisplay и не увидел созданного тома на SAS-массиве. pvs тоже не обнаружил тома.
Это означало, что хранилище, на самом деле, не создалось. Точнее создался объект хранилища в XenServer, но при этом он не был связан с физическим хранилищем. Почему XenServer так себя повел, и, тем более, позволил перенести образ в это хранилище, я так и не выяснил.
Получается, что образ на SAS-массиве можно даже не искать, так как физически на него ничего не переносилось. Значит нужно пробовать восстанавливать образ с хранилища, на котором он был изначально.
Поиск в интернете на тему восстановления логических томов LVM задал начальный вектор раскопок.
LVM хранит свою текущую конфигурацию в /etc/lvm/backup/ и, в обычных условиях, архив старых конфигураций в виде бинарных файлов, в /etc/lvm/archive/. UUID хранилища XenServer соответствует имени LVM VolumeGroup. Но, оказывается, в XenServer этот самый архив отключен:
/etc/lvm/lvm.conf
# Configuration of metadata backups and archiving. In LVM2 when we
# talk about a 'backup' we mean making a copy of the metadata for the
# *current* system. The 'archive' contains old metadata configurations.
# Backups are stored in a human readeable text format.
backup {
# Should we maintain a backup of the current metadata configuration?
# Use 1 for Yes; 0 for No.
# Think very hard before turning this off!
backup = 1
# Where shall we keep it?
# Remember to back up this directory regularly!
backup_dir = "/etc/lvm/backup"
# Should we maintain an archive of old metadata configurations.
# Use 1 for Yes; 0 for No.
# On by default. Think very hard before turning this off.
archive = 0
# Where should archived files go?
# Remember to back up this directory regularly!
archive_dir = "/etc/lvm/archive"
# What is the minimum number of archive files you wish to keep?
retain_min = 10
# What is the minimum time you wish to keep an archive file for?
retain_days = 30
}
# talk about a 'backup' we mean making a copy of the metadata for the
# *current* system. The 'archive' contains old metadata configurations.
# Backups are stored in a human readeable text format.
backup {
# Should we maintain a backup of the current metadata configuration?
# Use 1 for Yes; 0 for No.
# Think very hard before turning this off!
backup = 1
# Where shall we keep it?
# Remember to back up this directory regularly!
backup_dir = "/etc/lvm/backup"
# Should we maintain an archive of old metadata configurations.
# Use 1 for Yes; 0 for No.
# On by default. Think very hard before turning this off.
archive = 0
# Where should archived files go?
# Remember to back up this directory regularly!
archive_dir = "/etc/lvm/archive"
# What is the minimum number of archive files you wish to keep?
retain_min = 10
# What is the minimum time you wish to keep an archive file for?
retain_days = 30
}
Дальнейшие поиски показали, что lvm хранит архив всех конфигураций VolumeGroup в начальных секторах этих самых VolumeGroup. Так как у меня хранилище расположено на отдельном массиве, то просматриваю начало этого массива:
# hexdump -C /dev/md1 | less
Если видно что-то похожее на конфиги, то можно снять дамп этих секторов для более удобного чтения (в моем случае архив занимал 100Мб):
# dd if=/dev/md1 of=dump.conf bs=100M count=1
Так же дамп можно снять через команду lvmdump.
В дампе ищу конфиг, дата которого предшествует моменту пропажи образа:
Конфигурация
VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 {
id = "TprMi6-z1OR-BGcz-uReP-if22-6122-tfu0zP"
seqno = 5
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "0gexgQ-urcH-GZd0-iehs-ne0y-6JYz-ZTGbna"
device = "/dev/md1" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 473571375 # 225.816 Gigabytes
pe_start = 20608
pe_count = 57806 # 225.805 Gigabytes
}
}
logical_volumes {
MGT {
id = "Znwuly-qcgx-AHbd-1qg9-Jjp8-eogk-N5ASme"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 1 # 4 Megabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 {
id = "yLMfFb-9yOk-vf1N-FTmz-5NiL-F5lx-NNmkuN"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 12827 # 50.1055 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 1
]
}
}
}
}
Из этого конфига нужна только запись, соответствующая пропавшему образу (та запись, которая отсутствует в текущем конфиге в /etc/lvm/backup/<Соответствующий VG>, в моем случае VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89). Переписываю ее в текущую конфигурацию и даю LVM команду восстановить VG из бэкапа:
vgcfgrestore -f /etc/lvm/backup/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 -v VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
Проверяю, что Logical Volume подхватился:
# lvdisplay
--- Logical volume ---
LV Name /dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/MGT
VG Name VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
LV UUID Znwuly-qcgx-AHbd-1qg9-Jjp8-eogk-N5ASme
LV Write Access read/write
LV Status available
# open 0
LV Size 4.00 MB
Current LE 1
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Logical volume ---
LV Name /dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89
VG Name VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
LV UUID yLMfFb-9yOk-vf1N-FTmz-5NiL-F5lx-NNmkuN
LV Write Access read/write
LV Status available
# open 0
LV Size 50.11 GB
Current LE 1
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
Если сейчас сделать поиск по хранилищу (через XenCenter или xe sr-scan), то XenServer успешно затрет эту запись и все придется делать заново. Как я понял, XenServer не видит у себя VDI (образа диска) с UUID, соответствующем UUID нашему восстановленному Logical Volume.
XenServer, при использовании lvm, хранит образы дисков напрямую в Logcal Volume. Точнее Logical Volume это и есть VHD-образ. Поэтому я предположил, что можно заставить XenServer увидеть образ, скопировав его поверх другого, такого же размера.
Для копирования раздела активирую разделы в этом VG:
# vgchange -ay VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
Теперь есть доступ к разделу LVM, значит можно скопировать этот раздел с помощью dd:
# dd if=/dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 of=image.vhd bs=100M
После того, как скопированный образ добавился в виртуальной машине, а так же после того, как машина стартанула с этого образа, моему счастью не было предела!
Однако не все так радужно. Нужно было еще выключить сервер, чтобы вытащить глючный контроллер. А когда я его включил образ снова пропал! Получается, что XenServer при запуске сверяет UUID образа в LVM c UUID в своей базе и, если они не совпадают, образ удаляется.
Пока ковырял LVM заметил, что при переносе образа из одного хранилища в другое так же меняется и его UUID и, исходя из этого, предположил, что можно окончательно воскресить образ, просто скопировав переписанный через dd образ в другое хранилище. Это должно обновить UUID в образе, сопоставив его в UUID в базе. Повторяем все процедуры заново, после чего переносим образ на временно созданное для этого хранилище, добавляем к виртуальной машине и пробуем ее запустить. Запуск проходит нормально.
Перезагружаем сервер, трясущимися от нетерпения и усталости руками проверяем список образов и… образ на месте! Счастью нет предела и, довольный собой, я удаляюсь в закат…
Комментарии (11)
lovecraft
24.04.2015 07:47Я как-то раз решил проверить на тестовой платформе с 3805, как работает команда arcconf modify и расширить RAID10 добавлением пары дисков. Почитал документацию, написал команду, нажал Enter… arcconf задумался секунд на 30, а потом сказал что-то вроде:
>>Controller fault, rebooting kernel
После перезагрузки контроллера RAID пропал из конфигурации контроллера совсем)
А еще была проблема — ESXi периодически ложился в розовый экран, «призывно постанывая в syslog»©. Оказалось, в ESXi тайм-аут выполнения SCSI-команды вроде бы 25 с., в 3805 — 30 c., в результате рано или поздно наступает момент, когда контроллер отваливается по тайм-ауту. Вылечилось прошивкой контроллера.
amarao
27.04.2015 21:19У LSI можно менять таймауты на операции. Сейчас не помню имя софтинки (не уверен, что megacli), но точно можно.
Greendq
27.04.2015 23:56LSI лично мне не нравились из-за проблем с поддержкой дистрибутивов, отличных от Красной Шапки. Возможно, сейчас ситуация поменялась, но «осадочек остался».
amarao
28.04.2015 00:45lsi отвратителен. Адаптек тоже. Вариантов не видно. Из всех HBA лучший, который я видел — ahci в южном мосту. К сожалению, 6 дисков на сервер и не больше, плюс не в полную полосу (на всех PCI шины не хватает). Зато никаких странных глюков и специфичных отваливаний чего-либо по поводу и без.
amarao
Угу. LVM под xenserver'ом — путь к большой-большой печали.
Greendq
При том, что просто под XEN-ом — использую в продакшене около 5 лет как с аппаратным зеркалом (кстати — от Адаптека) и с софтварным и проблем не замечал.
rrock Автор
У меня XenServer 6.5 вообще не хочет работать с этим контроллером. Ставил чистый XenServer — сервер ребутится, если в нижнем PCI-слоте и отваливается контроллер если в любом другом. А вот на Debian на этом же железе проблем вообще никаких. Пока решения не нашел. Скорее всего что-то в ядре.
Greendq
У меня Дебиан с 5 на 6 перетёк плавно и без прблем. Было страшно обновлять прошивку у контроллера удалённо в 2 часа ночи, но IPMI тут оказался как нельзя кстати.
amarao
Сколько у вас хостов в пуле? Сколько виртуалок? Если <30, <3000, там вообще не о чем говорить.
Greendq
При более чем 5-6 виртуалок, работающих под нагрузкой — это вообще не тот класс адаптеров, чтобы использовать. На двух хостах с 8 виртуалками (с 10Г линком между хостами) у адаптеров Адаптека никаких проблем не замечал. Возможно, на диких задачах при интенсивном вводе-выводе они и лажают. Но тогда надо использовать что-то другое. :)
amarao
Там проблема не а адаптеке, а в совершеннейше шизофреической организации LVM, при которой используется патченная версия lvm2 с всеми шансами просрать LV из-за ошибочной записи.
Если к этому добавить молча зависающие при ребуте доменов tapdisk'ки (в старых версиях они хотя бы CPU жрали в 100% и их легко отловить было, а в новых просто висят и держат залоченными LV), вызывающие необходимость вручную снимать блокировку с тома для продолжения работы, то получаем отличный комплект кластерных граблей с разделяющимися зубьями для хождения по ним.
На 5-6 виртуалках никаких проблем не будет, ибо вероятность словить неснимающийся лок пропорциональна частоте «параллельных ребутов» от нескольких гостей.
Подробности драмы можно почитать в /etc/xensource/scripts и тот п-ц, что в /opt/xenserver/sm/*.py. (да-да, на питоне парсить вывод команды ls для получения списка файлов...)