Como posso tornar as configurações do LVM tolerantes à inicialização com a unidade USB conectada?

Question

Configuração: DELL PowerEdge R520, nó oVirt 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: Quando o sistema é reinicializado, a unidade de backup 1.4T conectada com sata para usb torna-se sda, onde o lvm não encontra as partições necessárias para os volumes físicos. O sistema então inicializa no modo de recuperação, onde tenho que fazer login através do monitor/teclado conectado, desmontar e ejetar a unidade sata para usb, comentar sua entrada no fstab, desconectá-lo e reinicializar o sistema. Então, uma vez inicializado corretamente com o dispositivo correto como sda, tenho que desfazer tudo que fiz no modo de recuperação com o dispositivo sata para usb.

Tudo é que o fstab já está definido para montar por UUID ou /dev/mapper/.

A questão: é possível alterar a configuração do LVM para obter o volume físico correto para o sistema, independentemente de qual dispositivo se torna sda? É possível sem recreação e migração (tenho os dados do sistema em um RAID 1 (espelhamento) com hot-spare, então não há mais espaço no chassi para um arranjo de unidade de substituição)? Estou aberto a qualquer solução que não exija a exclusão de dados ou a criação de um novo arranjo RAID para substituição. Se isso não for possível, estou aberto a qualquer coisa, na verdade - ou continuarei resolvendo o problema no modo de recuperação sempre que ele for reinicializado inesperadamente.

Answer 1

1. O LVM não armazena caminhos de dispositivos. Os UUIDs dos componentes são armazenados nos superblocos LVM e esses UUIDs são usados ​​exclusivamente para identificar componentes (PVs, VGs, LVs). O LVM apenas verifica todos os dispositivos de bloco disponíveis (os quais têm permissão para verificar estão configurados em /etc/lvm/lvm.conf), detecta volumes físicos e monta grupos de volumes a partir deles. Apenas não verifica que tipo/caminho de dispositivo o volume físico possui desta vez. É muito robusto para reindexação de dispositivos e assim por diante. Portanto, ele encontrará seus dados se você mover seus volumes para /dev/cciss/cXdYpZ (o antigo driver de bloco HP/Compaq SmartArray cria esses dispositivos) ou para /dev/hdXY ou /dev/sdXY ou /dev/mapper/... (qualquer coisa construída sobre DM coloca nós de dispositivos lá - criptografia, multipath, etc.), /dev/md/... (Linux MD RAID) e assim por diante. Sua preocupação está errada e seu problema está em outro lugar.

2. A causa do seu problema pode ser a lentidão do USB. Possui grandes latências; também os discos rígidos externos são muito lentos para iniciar (isso é feito para limitar o pico de uso de energia durante a inicialização). USB não é uma questão de desempenho, mas de robustez nas mãos de usuários inexperientes. Portanto, é lento para inicializar. Você precisa configurar seus scripts de inicialização (provavelmente, script de inicialização initramfs) para permitir grandes atrasos/tempos limite para que os dispositivos USB tenham tempo suficiente para girar e se estabilizar.

3. Outra causa típica é a configuração incorreta do bootloader; por exemplo, ele poderia esperar encontrar seus dados na "primeira partição do primeiro disco rígido" e, se o "primeiro disco rígido" for um dispositivo errado, ele não terá uma configuração e a imagem do kernel para inicializar e joga você nocarregador de inicializaçãoescudo de resgate. A linha de comando do kernel ou algo que é colocado no initramfs pode estar vinculado a algum caminho concreto de dispositivo e, portanto, a troca de dispositivos faz com que ele não consiga encontrar / e isso joga você eminitramfsescudo de resgate. Observe que estes sãodiferenteprojéteis de resgate e a compreensão dequal delesvocê vê que é importante.

4. RAID0 com sobressalente é um oxímoro. RAID0 não tem redundância, nenhum estado degradado definido, nada para recuperar o array para o estado ideal após uma falha de dispositivo, portanto, sobressalente não poderia ajudá-lo. Qualquer problema de dispositivo componente geralmente resulta na movimentação de uma matriz inteira diretamente para o estado de falha. Qualquer outro nível de RAID tem redundância, ele fará a transição primeiro para o estado degradado no caso de falha de um componente, portanto se beneficiará de peças sobressalentes, mas o RAID0 não.

Answer 2

Eu resolvi o problema. Tudo que tive que fazer foi adicionar partições sdb ao filtro em /etc/lvm/lvm.conf:

Era:

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

Alterado para:

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

Qualquer outra pessoa que esteja tentando fazer isso, certifique-se de verificar suas alterações e regenerar o cache comvgscan

minha primeira tentativa (esqueci |depois $):

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

minha segunda tentativa:

[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

A unidade sata para usb ainda aparece como sda, mas isso não importa - o LVM pula para as partições sdb quando nada é encontrado no sda. Eu tive que montar a unidade sata para usb manualmente, mas como ela estava /etc/fstabcorretamente, só tive que emitir o arquivo mount -a. Terei que resolver esse problema mais tarde e aceitar esta vitória por enquanto.