Вопрос или проблема
У меня есть сервер, на котором установлен Proxmox VE 8.2 (на базе Debian 12), полностью обновленный, который использует многопутевой SAN. У нас там выделено место, десять устройств по 2Т каждое, которые видны 16 раз каждое (количество путей) и которые отображаются в 10 многопутевых виртуальных устройств и собраны в одну группу LVM, из которой выделен логический том. На этом этапе проблем нет.
Изначально оно было инициализировано “на лету” и работало нормально, до тех пор пока хост не был перезагружен. После этого я заметил, что каждый раз, когда выполняется любая команда, связанная с LVM (lvs
и т.д.) в системной оболочке, она выдает предупреждение следующего формата:
WARNING: Обнаружено несоответствие устройств для <LV>, которые обращаются к <список устройств, таких как
/dev/sdak, /dev/sdaz, /dev/sdbn, ...> вместо <списка устройств,
таких как /dev/mapper/oamdwhdg-01, /dev/mapper/oamdwhdg-02, ...>
Эти /dev/mapper/oamdwhdg-XX
на самом деле являются многопутевыми устройствами, они были названы так по производственным причинам в /etc/multipath.conf
:
multipaths {
...
multipath {
wwid 36...
alias oamdwhdg-04
}
...
}
Итак, по какой-то причине, LV отображается с использованием бэкенд-устройств вместо использования многопутевых виртуальных устройств.
Я обновил фильтр в /etc/lvm/lvm.conf
, который теперь выглядит так:
global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|.*|" ]
(Я обновил его, а не добавил, он был global_filter=["r|/dev/zd.*|","r|/dev/rbd.*|"]
раньше с комментарием добавлено pve-manager, чтобы избежать сканирования ZFS zvols и Ceph rbds
. Я считаю, что мой фильтр гораздо более строгий, чем этот.)
/dev/sda3
— это локальный диск, на котором установлена PVE, и он содержит VG pve
, который не зависит от SAN, поэтому это единственный /dev/sd...
, не использующий многопуть, и он был добавлен в белый список.
Я протестировал этот фильтр с помощью vgscan
, и он показывает, что обе группы найдены.
Затем я выполнил update-initramfs
и перезагрузил. Во время загрузки сервер попал в аварийную оболочку. Когда я нажал Ctrl+D
там, он, однако, загрузился почти нормально: многопутевой VG виден, но не активирован (как будто vgchange -an oamdwhdg
еще не был выполнен). Но потом я активировал его вручную, и все заработало без проблем.
Я подозреваю, что это связано с тем, что многопуть не правильно инициализируется перед LVM в initramfs, поэтому он пытался настроить отображения, используя устройства /dev/sdXX. Но почему он попал в аварийную оболочку, когда я добавил фильтр, я не понимаю.
Два (очень связанных) вопроса здесь: почему аварийная оболочка, т.е. что не так и как заставить это работать так, как ожидалось?
Ответ или решение
Ваша проблема связана с тем, что средство инициализации initramfs
не успевает правильно настроить multipath перед запуском LVM, что приводит к тому, что LVM пытается инициализировать логические тома с использованием устройств, которые не являются мультипутевыми. Это, в свою очередь, вызывает предупреждение о несоответствии устройств. Давайте разберемся с этим по шагам и попробуем найти решение вашей проблемы.
Почему возникает аварийная оболочка?
-
Проблема с инициализацией устройств: Когда
initramfs
загружает системы в режиме раннего загрузчика, порядок инициализации может быть критически важен. Если LVM запускается до того, как multipath драйверы инициализируют свои соответствия, LVM найдет только сетевые устройства (например,/dev/sdXX
), что приведет к несоответствиям. -
Фильтрация устройств: Установка строгих фильтров в вашем файле конфигурации LVM может помешать правильной инициализации. Если фильтры не позволяют признать необходимые устройства, система может впасть в аварийный режим при попытке запустить LVM на неправильных устройствах.
Решение проблемы
-
Изменение порядка инициализации:
- Вам нужно убедиться, что multipath инициализируется до того, как LVM попытается получить доступ к логическим томам.
- Вы можете отредактировать файл
/etc/multipath.conf
, чтобы убедиться, что он настроен правильно, и перегенерироватьinitramfs
.
-
Редактирование initramfs:
- Вы можете отредактировать скрипт инициализации
initramfs
, чтобы убедиться, чтоmultipath
инициализируется заранее. - Для этого вам нужно будет включить соответствующие команды в файл
/etc/initramfs-tools/scripts/init-top/multipath
. Убедитесь, что там корректно прописаны команды для инициализации multipath перед LVM.
- Вы можете отредактировать скрипт инициализации
-
Проверка конфигурации LVM:
- Убедитесь, что ваша конфигурация LVM правильно настроена и не блокирует обнаружение правильных устройств. Отредактируйте
/etc/lvm/lvm.conf
так, чтобы фильтры не мешали корректному обнаружению мультипутевых устройств. - Попробуйте установить изменения в фильтре так, чтобы разрешить
/dev/mapper
устройства наряду с соответствующими физическими устройствами.
Например:
global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|/dev/sd.*|" ]
- Убедитесь, что ваша конфигурация LVM правильно настроена и не блокирует обнаружение правильных устройств. Отредактируйте
-
Перегенерация initramfs:
- После всех изменений выполните команду:
update-initramfs -u
Это создаст новый образ initramfs с учетом всех ваших изменений.
- После всех изменений выполните команду:
-
Тестирование:
- Перезагрузите сервер и проверьте, запускаются ли системы должным образом без перехода в аварийный режим.
- Убедитесь, что все устройства многопутевой настройки видны.
Общие рекомендации
- Логи: Проверьте логи, такие как
/var/log/syslog
или/var/log/boot.log
, на наличие полезной информации о том, почему система попала в аварийный режим. - Обновления: Убедитесь, что ваши пакеты LVM и multipath обновлены до последней версии, чтобы избежать известных ошибок.
Следуя этим шагам, вы должны смочь решить проблему с неправильно инициализированными LVM над мультипутевыми устройствами и предотвратить возникновение аварийного режима при загрузке.