Настройка: 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
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) и т. д. Ваши опасения ошибочны, и ваша проблема в другом.
Причиной вашей проблемы может быть медлительность USB. Он имеет большие задержки; также внешние жесткие диски очень медленно запускаются (это делается для ограничения пика потребления энергии во время раскрутки). USB — это не производительность, а надежность в руках неопытного пользователя. Поэтому он медленно инициализируется. Вам нужно настроить свои сценарии инициализации (вероятно, сценарий инициализации initramfs), чтобы разрешить большие задержки/тайм-ауты, чтобы у USB-устройств было достаточно времени для раскрутки и стабилизации.
Другой типичной причиной является неправильная конфигурация загрузчика; например, он может ожидать, что его данные будут находиться на «первом разделе первого жесткого диска», а если «первый жесткий диск» окажется не тем устройством, у него не будет конфигурации и образа ядра для загрузки, и он перенесет вас взагрузчикспасательная оболочка. Командная строка ядра или что-то, что помещается в initramfs, может быть привязана к какому-то конкретному пути устройства, и поэтому подкачка устройств приводит к тому, что она не может найти / и это бросает вас вinitramfsспасательная оболочка. Обратите внимание, что этодругойспасательные снаряды и пониманиекоторый извидите ли, это важно.
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
. Мне придется разобраться с этой проблемой позже и пока взять эту победу.