O array mdadm criado pelo CentOS 7 desaparece após a reinicialização

2

Eu criei um raid1 usando os discos abaixo e o comando:

$ ls -l /dev/disk/by-id/ata-ST3000*
lrwxrwxrwx 1 root root 9 Sep 19 07:27 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1 -> ../../sdc
lrwxrwxrwx 1 root root 9 Sep 19 07:27 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 -> ../../sda

$ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1

Eu adicionei as informações pertinentes ao mdadm.conf. Eu usei 'mdadm --detail --scan > > /etc/mdadm.conf 'para a linha ARRAY:

$ cat /etc/mdadm.conf
DEVICE /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3
DEVICE /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1
ARRAY /dev/md0 metadata=1.2 name=jaime.WORKGROUP:0 UUID=93f2cb73:2d124630:562f1dd9:bf189029
MAILADDR your@address

Eu criei e montei o sistema de arquivos:

$ mkfs -t xfs /dev/md0
$ mount -t xfs /dev/md0 /data

Após a reinicialização, o / dev / md0 não existe mais e não consigo montar o array:

$ mdadm --assemble /dev/md0 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F04NR1
mdadm: Cannot assemble mbr metadata on /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3
mdadm: /dev/disk/by-id/ata-ST3000DM001-9YN166_Z1F190E3 has no superblock - assembly aborted

Sou um iniciante completo em software RAID e provavelmente estou mexendo com algo simples aqui em cima. Alguém pode ajudar?

$ blkid
/dev/sda: PTTYPE="gpt"
/dev/sdb1: UUID="5c7d3f2b-c975-46a3-a116-e9fc156c1de5" TYPE="xfs"
/dev/sdb2: UUID="JhoqjI-N6R6-O9zt-Xumq-TnFX-OUCd-Lg9YHy" TYPE="LVM2_member"
/dev/sdc: PTTYPE="gpt"
/dev/mapper/centos-swap: UUID="3b882d4d-b900-4c59-9912-60a413699db4" TYPE="swap"
/dev/mapper/centos-root: UUID="08df953d-d4f4-4e83-bf4b-41f14a98a12e" TYPE="xfs"
/dev/mapper/centos-home: UUID="2358f723-5e7f-49ed-b207-f32fe34b1bbc" TYPE="xfs"
    
por uwsublime 19.09.2014 / 16:49

6 respostas

1

Em teoria, pode-se fazer raids a partir de "unidades vazias" (não particionadas), mas notei que seus discos estão aparecendo como discos particionados por gpt, não md. Em geral, encontrei melhor sucesso / estabilidade particionando meu disco e usando partições em meus arrays md.

Eu tentaria criar uma tabela de partição, definindo o tipo de partição como autodetecção do raid linux (fd no fdisk se bem me lembro). Então recriando sua matriz.

Além disso, descobri que, se eu não usasse um mdadm.conf, encontraria um sucesso melhor. As versões modernas das ferramentas MD obterão todas as informações necessárias das superblocos das partições envolvidas.

    
por 19.09.2014 / 21:52
1

Para todos vocês, eu encontrei uma solução que funciona para mim .. Pode ser isso pode ajudar vocês .. Aqui está:

A montagem de raid desaparece porque o sistema não está lendo o arquivo mdadm.conf durante a inicialização ou inicialização. Então, o que eu fiz foi editar o arquivo /etc/rc.d/rc.local para incluir os comandos abaixo:

sleep 10
mdadm --assemble --scan
sleep 10
mount -a

Agora, toda vez que eu reinicializo o sistema, ele lê esse arquivo, executa os comandos mencionados nele e monta a montagem do ataque.

    
por 29.11.2016 / 21:04
1

Me deparei com essa pergunta que me ajudou muito durante a solução de problemas. Mas nenhuma das respostas poderia resolver o meu problema.

Então, talvez isso ajude alguém a ter o mesmo problema. No meu caso, eu tenho duas unidades NVME em um RedHat Linux 7.2.

O SELinux tem um problema com o nvme e impede que o mdadm trabalhe com eles.

Sintomas:

Crie RAID de software conforme descrito na questão deste tópico. Após a reinicialização, o RAID desapareceu:

  • /proc/mdstat está vazio e /dev/md0 não existe
  • mdadm --assemble --scan traz o RAID para cima.

Solução:

Eu desativei o selinux no meu caso. Eu sei que isso não é possível em todos os sistemas. Mas talvez você esteja na direção certa do meu post.

    
por 27.02.2017 / 17:28
0

Advertências usuais se aplicam. Certifique-se de que seus dados foram armazenados em backup. Eu não sou responsável por qualquer perda de dados. Isso funcionou para mim. Certifique-se de testar sua matriz antes de colocar dados significativos nela. Certifique-se de que pode sobreviver a uma reinicialização e a alterações no nome do dispositivo, etc etc. etc.

Agora, para o que eu fiz.

Eu me deparei com o mesmo problema hoje. Depois de fazer algumas pesquisas, consegui consertar isso e obter um dispositivo de invasão estável.

Em dois discos que eu estava usando para minha matriz, criei uma partição usando o gdisk antes de criar o dispositivo RAID. Eu apaguei as partições usando o gdisk, mas quando eu criei o array eu recebi a mensagem informativa abaixo:

mdadm: partition table exists on /dev/disk/by-id/ata-ST4000VN000-1H4168_Z30254QX but will be lost or meaningless after creating array

Sempre que vejo esta mensagem quando reinicio, a matriz é perdida.

Imaginei usar a sugestão acima de Jim K e criar uma partição de ataque do Linux em cada unidade. Isso funcionou, mas a taxa de sincronização passou de 145 MB / s nas unidades brutas para 35 MB / s nas unidades particionadas. Eu provavelmente poderia ter jogado com parâmetros de ajuste, mas por que eu deveria fazer isso?

Eu fui em uma missão para descobrir como nuke a tabela de partição do disco.

A correção ...

Primeiro, certifique-se de que seu dispositivo de ataque esteja parado e, em seguida, neutralize a assinatura do ataque de unidade.

mdadm --stop /dev/md<number> 
mdadm --zero-superblock /dev/sd<x> (do this for all your raid disks)

Execute o blkid e veja se algum dos dispositivos de ataque aparece. Se eles fizerem.

executar:

dd if=/dev/zero of=/dev/sd<x> bs=512 count=1

Isto irá, esperançosamente, eliminar as tabelas de partições. Execute blkid novamente para certificar-se de que nenhum disco usado para o dispositivo de ataque esteja listado.

No meu caso, o gpt tinha um rótulo LVM com backup em um disco. Eu limpei isso usando lvremove, vgremove e finalmente pvremove.

Blkid correu limpo desta vez.

No entanto, quando tentei criar o array novamente, recebi um erro sobre um dispositivo de invasão existente, então fiz um dd mais uma vez. Depois disso, a matriz criada sem avisos, como eu listei acima.

Eu recriou o array como era originalmente, usei disk / by-id em vez de sd. Depois que o array foi recriado, a partição de teste que eu havia criado no array voltou intacta.

A matriz agora sobrevive a reinicializações e muda para / dev / sd de quando a matriz foi originalmente criada. Espero que isso ajude os outros ..

    
por 02.10.2014 / 01:15
0

A saída de blkid mostra seu problema - as unidades não foram limpas quando você criou o dispositivo md e as informações antigas estão confusas.

Dado que você os criou sem uma tabela de partições, o fato de blkid reportar PTTYPE="gpt" para sda e sdc é o problema.

Se você ainda não tem nenhum dado nas unidades que precisa salvar, pode apagar a tabela de partição GPT com 'dd':

$ sudo dd if = / dev / zero de = / dev / sda bs = contagem de 1M = 10

Isso zerará os primeiros 10 megabytes de /dev/sda . Repita para /dev/sdc . Recrie a matriz depois disso e, em seguida, /dev/md0 deve ser inicializado.

    
por 02.10.2014 / 01:32
0

Parece ser uma maneira melhor de formatar as partições de disco com o tipo fd (autodetect do Linux Raid), mas observe as mensagens de alinhamento no fdisk! Eu tinha esses avisos e os resolvi com a ferramenta parted para criar as partições e depois usar o fdisk para defini-las como 'fd'. Então, faça exatamente como você fez e o dispositivo RAID será formado automaticamente no momento da inicialização. Com uma entrada no / etc / fstab, ele será montado ...

Uma ressalva: Usar o /etc/mdadm.conf destruiu meu sistema RHEL7 3.10.0-514.6.1.el7.x86_6.

    
por 20.02.2017 / 17:13