Por que o comportamento do multipath muda após a reinicialização?

Question

Como eu comando multipath -ll, a saída é exibida assim.

ocr3 (149455400000000000000000001000000ca0200000d000000) dm-9 IET,VIRTUAL-DISK
[size=980M][features=0][hwhandler=0]
\_ round-robin 0 [prio=0][active]
 \_ 1:0:0:11 sdo 8:224 [active][ready]
\_ round-robin 0 [prio=0][enabled]
 \_ 1:0:0:10 sdn 8:208 [active][ready]

No entanto, o mesmo devnode do ocr3, como sdo e sdn, é alterado após a reinicialização.
Eu acho que é um problema de consistência.
Por que o devnode muda após a reinicialização?
Como tornar o devnode permanente na reinicialização?

    

Answer 1

Para permitir a reconfiguração dinâmica e a conexão automática, você não deve presumir que os nós do dispositivo /dev/sd* permanecerão os mesmos de uma inicialização para a próxima.

Em uma estação de trabalho com apenas um único controlador AHCI SATA, a ordem geralmente será estática, pois é determinada principalmente pela ordem em que os drivers do controlador de armazenamento são carregados: normalmente o driver para o disco raiz é carregado na fase initramfs do boot, antes de usb-storage . A ordem dos discos gerenciados pelo controlador AHCI é então corrigida à medida que as portas do controlador são sondadas na ordem do número da porta pelo driver.

Mas em um sistema conectado ao armazenamento SAN, as coisas não são tão simples. Pode haver vários controladores de disco (um para discos do sistema interno, um para cada SAN HBA) e no momento da inicialização, os HBAs geralmente são testados na ordem do barramento PCI, e os LUNs em cada HBA são detectados na ordem específica do driver. dependem da configuração SAN também. A ordem em um único HBA pode ser baseada em WWIDs LUN ou em alguns outros detalhes de configuração de armazenamento.

E não há intervalos pré-alocados de /dev/sd* nomes para cada HBA: uma vez que cada LUNs do HBA tiver nomes atribuídos, o sistema continuará com o próximo HBA sem deixar lacunas nos nomes /dev/sd* .

Quando um nome /dev/sd* tiver sido atribuído a um disco ou LUN, ele não poderá ser reatribuído automaticamente para apontar para outro LUN enquanto o sistema estiver em execução ou os sistemas de arquivos ou bancos de dados puderem ser corrompidos. Essa reatribuição enquanto o sistema está em execução deve sempre envolver o sysadmin. Somente no momento da inicialização, eles podem ser reatribuídos automaticamente.

Como resultado, quando o administrador da SAN apresenta um novo LUN para seu sistema, seu WWID certamente deve ser exclusivo, mas o valor WWID pode ser antes, depois ou no meio de seus LUNs existentes. Quando é adicionado a quente, cada caminho para ele receberá o próximo nome de dispositivo /dev/sd* livre, então eles irão atrás de todos os LUNs existentes. Mesmo isso praticamente garante que a ordem dos nomes /dev/sd* irá mudar na próxima vez que o sistema for inicializado.

Naturalmente, você poderia usar as regras do udev para corrigir os nomes de /dev/sda* para HBAs e WWIDs específicos se você quisesse ... mas isso é muito trabalho para ganhos muito pequenos. Todos os dispositivos /dev/sd* devem executar exatamente o mesmo que o kernel: se você achar que isso não é verdade, você encontrou um bug e deve denunciá-lo. Portanto, não há razão necessária para que a sua encomenda seja importante .

Os desenvolvedores do kernel Linux perceberam isso durante o ciclo de desenvolvimento 2.5. *, pois estavam tentando remover quaisquer limitações da configurabilidade on-line. Agora existem maneiras de tornar a configuração do seu sistema completamente independente dos nomes /dev/sd* :

• Se você usar partições tradicionais, poderá usar /dev/disk/by-* nomes de dispositivos em vez de /dev/sd* dispositivos ou usar a sintaxe UUID= ou LABEL= em /etc/fstab .

• Se você usa o LVM, ele nem armazena os nomes dos dispositivos de forma persistente, mas procura por assinaturas LVM em qualquer disco e partição que possa ver e, em seguida, constrói a configuração dinamicamente a partir daí. Isso acontece automaticamente na inicialização e toda vez que você executa vgscan . (E sim, há salvaguardas que impedem que os mapeamentos do LVM sejam alterados enquanto os discos estão em uso.)

• Se você usar multipathing, ele apresentará os LUNs com vários caminhos por meio de seus WWIDs (se friendly_names estiver desativado), por /dev/mapper/mpath* nomes atribuídos quando cada WWID for visto pela primeira vez e armazenado persistentemente em /etc/multipath/wwids (ou /var/lib/multipath/bindings no RHEL / CentOS 6 e anteriores, o que acabou sendo um erro se /var for um sistema de arquivos separado ...), ou por aliases que você mesmo pode atribuir pelo WWID.

Uma vez tive que administrar um antigo sistema RHEL 3 que tinha discos SAN conectados a ele. Inicialmente, ele tinha apenas um HBA; em seguida, outro HBA foi adicionado para redundância e migração da SAN ... mas era de um fornecedor diferente, portanto, as soluções de mulipath específicas do fornecedor não estavam disponíveis. Eu tive que usar o recurso multipath (desde então abandonado) de mdadm . É necessário manter o controle dos nomes dos dispositivos, bem como o que você está pensando. Duas palavras: Chupou . Fiquei muito feliz quando o sistema finalmente ficou obsoleto.