☰

Как сделать так, чтобы конфигурации LVM допускали загрузку с подключенного USB-накопителя?

tag-icon • tag-icon hard-drive lvm boot
Как сделать так, чтобы конфигурации LVM допускали загрузку с подключенного USB-накопителя?

Настройка: DELL PowerEdge R520, oVirt Node 4.4.1 x86_64

# pvs
  PV         VG          Fmt  Attr PSize    PFree   
  /dev/sda2  onn_ovirt01 lvm2 a--   105.26g   20.77g
  /dev/sda3  VG_he_nfs   lvm2 a--  <100.00g  <10.00g
  /dev/sda4  VG_data_nfs lvm2 a--    <1.50t <206.00g

# lsblk
...

sdb                                                            8:16   0   1.4T  0 disk 
└─sdb1                                                         8:17   0   1.4T  0 part /exports/nfs/backups

Проблема: Когда система перезагружается, резервный диск 1.4T, подключенный с помощью sata-to-usb, становится sda, где lvm не находит необходимых разделов для физических томов. Затем система загружается в режим восстановления, где мне нужно войти в систему через подключенный монитор/клавиатуру, отмонтировать и извлечь диск sata-to-usb, закомментировать его запись в fstab, отключить его и перезагрузить систему. Затем, после правильной загрузки с правильным устройством как sda, мне нужно отменить все, что я сделал в режиме восстановления с устройством sata-to-usb.

Все, что есть в fstab, уже определено для монтирования по UUID или /dev/mapper/.

Вопрос: возможно ли изменить конфигурацию LVM так, чтобы она получала правильный физический том для системы независимо от того, какое устройство становится sda? Возможно ли это без пересоздания и миграции (у меня системные данные на RAID 1 (зеркалирование) с горячим резервированием, поэтому в шасси больше нет места для замены дисков)? Я открыт для любого решения, которое не требует удаления данных или создания новой конфигурации RAID для замены. Если это невозможно, то я открыт для чего угодно, на самом деле - или просто продолжу разбираться с этим в режиме восстановления каждый раз, когда он неожиданно перезагружается.

решение1

  1. LVM не хранит пути к устройствам. UUID компонентов хранятся в суперблоках LVM, и эти UUID используются исключительно для идентификации компонентов (PV, VG, LV). LVM просто сканирует все доступные блочные устройства (какие из них разрешено сканировать, настраивается в /etc/lvm/lvm.conf), обнаруживает физические тома и собирает из них группы томов. Он просто не смотрит, какой тип/путь к устройству имеет физический том в этот раз. Он очень устойчив к переиндексации устройств и т. д. Поэтому он найдет ваши данные, если вы переместите свои тома в /dev/cciss/cXdYpZ (старый драйвер блоков HP/Compaq SmartArray создает такие устройства) или в /dev/hdXY или /dev/sdXY или /dev/mapper/... (все, что построено на DM, помещает туда узлы устройств — crypto, multipath и т. д.), /dev/md/... (Linux MD RAID) и т. д. Ваши опасения ошибочны, и ваша проблема в другом.

  2. Причиной вашей проблемы может быть медлительность USB. Он имеет большие задержки; также внешние жесткие диски очень медленно запускаются (это делается для ограничения пика потребления энергии во время раскрутки). USB — это не производительность, а надежность в руках неопытного пользователя. Поэтому он медленно инициализируется. Вам нужно настроить свои сценарии инициализации (вероятно, сценарий инициализации initramfs), чтобы разрешить большие задержки/тайм-ауты, чтобы у USB-устройств было достаточно времени для раскрутки и стабилизации.

  3. Другой типичной причиной является неправильная конфигурация загрузчика; например, он может ожидать, что его данные будут находиться на «первом разделе первого жесткого диска», а если «первый жесткий диск» окажется не тем устройством, у него не будет конфигурации и образа ядра для загрузки, и он перенесет вас взагрузчикспасательная оболочка. Командная строка ядра или что-то, что помещается в initramfs, может быть привязана к какому-то конкретному пути устройства, и поэтому подкачка устройств приводит к тому, что она не может найти / и это бросает вас вinitramfsспасательная оболочка. Обратите внимание, что этодругойспасательные снаряды и пониманиекоторый извидите ли, это важно.

  4. RAID0 с резервом — это оксюморон. RAID0 не имеет избыточности, не имеет определенного деградированного состояния, ничего, что могло бы восстановить массив в оптимальное состояние после отказа устройства, поэтому резерв не может ему помочь. Любая проблема с компонентом устройства обычно приводит к перемещению всего массива непосредственно в состояние отказа. Любой другой уровень RAID имеет избыточность, он первым перейдет в деградированное состояние в случае отказа компонента, поэтому он выиграет от резервов, но RAID0 — нет.

решение2

Я решил проблему. Все, что мне нужно было сделать, это добавить разделы sdb в фильтр в /etc/lvm/lvm.conf:

Был:

filter = ["a|^/dev/sda2$|", "a|^/dev/sda3$|", "a|^/dev/sda4$|", "r|.*|"]

Изменился на:

filter = ["a|^/dev/sda2$|", "a|^/dev/sda3$|", "a|^/dev/sda4$|", "a|^/dev/sdb2$|", "a|^/dev/sdb3$|", "a|^/dev/sdb4$|", "r|.*|"]

Если кто-то еще попытается это сделать, обязательно проверьте свои изменения и пересоздайте кэш с помощьюvgscan

мой первый подход (забыл |после $):

[root@host lvm]# vgscan
  Invalid separator at end of regex.
  Invalid filter pattern "a|^/dev/sdb2$".
  Failed to create regex device filter

моя вторая попытка:

[root@host lvm]# vgscan
  Found volume group "VG_data_nfs" using metadata type lvm2
  Found volume group "VG_he_nfs" using metadata type lvm2
  Found volume group "onn_ovirt01" using metadata type lvm2

Диск SATA-USB по-прежнему отображается как sda, но это неважно - LVM переходит к разделам sdb, когда на sda ничего не найдено. Мне пришлось вручную монтировать диск SATA-USB, но поскольку он подключен /etc/fstabправильно, мне пришлось только выдать mount -a. Мне придется разобраться с этой проблемой позже и пока взять эту победу.

Связанный контент