PVE: LVM инициализируется с использованием неправильных бэкенд-устройств (не-мультипаточные компоненты мультипаточного устройства)

Вопрос или проблема

У меня есть сервер, на котором установлен 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 пытается инициализировать логические тома с использованием устройств, которые не являются мультипутевыми. Это, в свою очередь, вызывает предупреждение о несоответствии устройств. Давайте разберемся с этим по шагам и попробуем найти решение вашей проблемы.

Почему возникает аварийная оболочка?

  1. Проблема с инициализацией устройств: Когда initramfs загружает системы в режиме раннего загрузчика, порядок инициализации может быть критически важен. Если LVM запускается до того, как multipath драйверы инициализируют свои соответствия, LVM найдет только сетевые устройства (например, /dev/sdXX), что приведет к несоответствиям.

  2. Фильтрация устройств: Установка строгих фильтров в вашем файле конфигурации LVM может помешать правильной инициализации. Если фильтры не позволяют признать необходимые устройства, система может впасть в аварийный режим при попытке запустить LVM на неправильных устройствах.

Решение проблемы

  1. Изменение порядка инициализации:

    • Вам нужно убедиться, что multipath инициализируется до того, как LVM попытается получить доступ к логическим томам.
    • Вы можете отредактировать файл /etc/multipath.conf, чтобы убедиться, что он настроен правильно, и перегенерировать initramfs.
  2. Редактирование initramfs:

    • Вы можете отредактировать скрипт инициализации initramfs, чтобы убедиться, что multipath инициализируется заранее.
    • Для этого вам нужно будет включить соответствующие команды в файл /etc/initramfs-tools/scripts/init-top/multipath. Убедитесь, что там корректно прописаны команды для инициализации multipath перед LVM.
  3. Проверка конфигурации LVM:

    • Убедитесь, что ваша конфигурация LVM правильно настроена и не блокирует обнаружение правильных устройств. Отредактируйте /etc/lvm/lvm.conf так, чтобы фильтры не мешали корректному обнаружению мультипутевых устройств.
    • Попробуйте установить изменения в фильтре так, чтобы разрешить /dev/mapper устройства наряду с соответствующими физическими устройствами.

    Например:

    global_filter=[ "a|/dev/sda3|", "a|/dev/mapper/oamdwhdg|", "r|/dev/sd.*|" ]
  4. Перегенерация initramfs:

    • После всех изменений выполните команду:
      update-initramfs -u

      Это создаст новый образ initramfs с учетом всех ваших изменений.

  5. Тестирование:

    • Перезагрузите сервер и проверьте, запускаются ли системы должным образом без перехода в аварийный режим.
    • Убедитесь, что все устройства многопутевой настройки видны.

Общие рекомендации

  • Логи: Проверьте логи, такие как /var/log/syslog или /var/log/boot.log, на наличие полезной информации о том, почему система попала в аварийный режим.
  • Обновления: Убедитесь, что ваши пакеты LVM и multipath обновлены до последней версии, чтобы избежать известных ошибок.

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

Оцените материал
Добавить комментарий

Капча загружается...