☰

¿Cómo puedo hacer que las configuraciones de LVM sean tolerantes al arranque con una unidad USB conectada?

tag-icon • tag-icon hard-drive lvm boot
¿Cómo puedo hacer que las configuraciones de LVM sean tolerantes al arranque con una unidad USB conectada?

Configuración: DELL PowerEdge R520, oVirt Nodo 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

Problema: Cuando el sistema se reinicia, la unidad de respaldo de 1.4T conectada con sata a usb se convierte en sda, donde lvm no encuentra las particiones necesarias para los volúmenes físicos. Luego, el sistema arranca en modo de rescate, donde tengo que iniciar sesión a través del monitor/teclado adjunto, desmontar y expulsar la unidad sata a USB, comentar su entrada desde el fstab, desconectarla y reiniciar el sistema. Luego, una vez iniciado correctamente con el dispositivo correcto como sda, tengo que deshacer todo lo que hice en modo de rescate con el dispositivo sata a usb.

Todo es que fstab ya está definido para montar mediante UUID o /dev/mapper/.

La pregunta: ¿Es posible cambiar la configuración de LVM para que obtenga el volumen físico adecuado para el sistema independientemente de qué dispositivo se convierta en sda? ¿Es posible sin recreación ni migración (tengo los datos del sistema en un RAID 1 (duplicación) con repuesto dinámico, por lo que no hay más espacio en el chasis para una disposición de unidad de reemplazo)? Estoy abierto a cualquier solución que no requiera eliminar datos o crear una nueva disposición RAID para reemplazarlos. Si eso no es posible, entonces estoy abierto a cualquier cosa, de verdad, o simplemente continuaré solucionándolo en modo de rescate cada vez que se reinicie inesperadamente.

Respuesta1

  1. LVM no almacena rutas de dispositivos. Los UUID de los componentes se almacenan en los superbloques LVM y estos UUID se utilizan exclusivamente para identificar componentes (PV, VG, LV). LVM simplemente escanea todos los dispositivos de bloque disponibles (cuáles pueden escanear se configura en /etc/lvm/lvm.conf), detecta volúmenes físicos y ensambla grupos de volúmenes a partir de ellos. Esta vez simplemente no se ve qué tipo/ruta de dispositivo tiene el volumen físico. Es muy resistente a la reindexación de dispositivos, etc. Por lo tanto, encontrará sus datos si mueve sus volúmenes a /dev/cciss/cXdYpZ (el antiguo controlador de bloque HP/Compaq SmartArray crea dichos dispositivos) o a /dev/hdXY o /dev/sdXY o /dev/mapper/... (cualquier cosa construida sobre DM coloca nodos de dispositivo allí: criptografía, rutas múltiples, etc.), /dev/md/... (Linux MD RAID), etc. Tu preocupación es errónea y tu problema está en otra parte.

  2. La causa de su problema podría ser la lentitud del USB. Tiene grandes latencias; Además, los discos duros externos tardan mucho en iniciarse (esto se hace para limitar el pico de consumo de energía durante el giro). El USB no se trata de rendimiento, sino de robustez en manos de un usuario inexperto. Por lo tanto, la inicialización es lenta. Debe configurar sus scripts de inicio (probablemente, script de inicio initramfs) para permitir grandes retrasos/tiempos de espera para que los dispositivos USB tengan tiempo suficiente para girar y estabilizarse.

  3. Otra causa típica es la mala configuración del gestor de arranque; por ejemplo, podría esperar encontrar sus datos en la "primera partición del primer disco duro", y si el "primer disco duro" resulta ser un dispositivo incorrecto, no tiene una configuración ni la imagen del kernel para arrancar y te arroja algestor de arranquecaparazón de rescate. La línea de comando del kernel o algo que se coloca en initramfs puede estar vinculado a alguna ruta de dispositivo concreta y, por lo tanto, el intercambio de dispositivos hace que no pueda encontrar / y lo arroja ainitramfscaparazón de rescate. Observe que estos sondiferenteproyectiles de rescate y la comprensión decuál¿Ves que es importante?

  4. RAID0 con repuesto es un oxímoron. RAID0 no tiene redundancia, ningún estado degradado definido, nada para recuperar la matriz al estado óptimo de una falla del dispositivo, por lo que el repuesto no podría ayudarlo. Cualquier problema de dispositivo componente generalmente resulta en mover una matriz completa directamente a un estado fallido. Cualquier otro nivel RAID tiene redundancia, pasará primero al estado degradado en caso de falla de un componente, por lo que se beneficiará de los repuestos, pero RAID0 no.

Respuesta2

Resolví el problema. Todo lo que tuve que hacer fue agregar particiones sdb al filtro en /etc/lvm/lvm.conf:

Era:

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

Cambiado a:

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

Si alguien más intenta esto, asegúrese de verificar sus cambios y regenerar el caché convgscan

mi primer intento (olvidé el |después del $):

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

mi segundo intento:

[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

La unidad sata a usb todavía aparece como sda, pero no importa: LVM salta a las particiones sdb cuando no se encuentra nada en sda. Tuve que montar la unidad sata a USB manualmente, pero como está instalada /etc/fstabcorrectamente, solo tuve que emitir mount -a. Tendré que solucionar este problema más tarde y conseguir esta victoria por ahora.

información relacionada