Reparando RAID6 com dois problemas de unidade mdadm

1

Eu tive duas falhas de disco no meu array RAID6. Eu adicionei dois novos discos e fiz o seguinte:

  • eu corri mdadm / dev / md1 --remove nos dois discos
  • Configurei meu RAID na primeira partição de cada disco (por motivos de alinhamento). Como os discos de substituição estão alinhados da mesma forma, eu fiz um dd if = / dev / sdg (disco de trabalho) de = / dev / sde (novo disco) bs = 512 count = 1 para copiar o layout da partição. Não tenho certeza se essa é a coisa certa a fazer, pois provavelmente copiei os dados do superbloco do mdadm.
  • Eu executei o mdadm / dev / md1 --add e os dois discos.

Agora tenho isso quando executo o mdadm --detail / dev / md1:

Number   Major   Minor   RaidDevice State
   0       8        1        0      active sync   /dev/sda1
   1       8       17        1      active sync   /dev/sdb1
   6       8       65        2      spare rebuilding   /dev/sde1
   3       0        0        3      removed
   4       8       97        4      active sync   /dev/sdg1
   5       8      113        5      active sync   /dev/sdh1

   7       8       81        -      spare   /dev/sdf1

/ proc / mdstat mostra um disco como reconstrução, mas não o outro. Eu não acho que isso é certo, já que acho que um disco é 'removido' e não foi substituído corretamente. As letras da unidade são exatamente iguais aos dois últimos discos. Aqui está o mdstat.

root@precise:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md0 : active raid1 sdc1[0] sdd1[1]
  1953379136 blocks super 1.2 [2/2] [UU]

md1 : active raid6 sdf1[7](S) sde1[6] sdb1[1] sdh1[5] sda1[0] sdg1[4]
  11720521728 blocks super 1.2 level 6, 512k chunk, algorithm 2 [6/4] [UU__UU]
  [>....................]  recovery =  2.2% (65163484/2930130432) finish=361.0min   speed=132257K/sec

unused devices: <none>'

Eu gostaria de saber (se isso parece certo), e o que eu preciso fazer para corrigir a entrada do número 3 e obter / dev / sdf1 para tomar o seu lugar? Suponho então que terei um array adequado novamente. O que eu acho estranho é adicionar / dev / sde1 parece ter permitido uma sincronização, mas / dev / sdf1 não ocupou o lugar de Number 3 Major 0 (RaidDevice 3)

Toda ajuda apreciada

Felicidades

    
por user3526827 09.02.2015 / 17:49

1 resposta

4

Primeiro, deixe-me tranquilizá-lo: se suas unidades mdadm forem baseadas em partição (por exemplo: sda1, etc), o primeiro "dd" foi OK e não causou nenhuma cópia de metadados mdadm (os metadados estão a própria partição, não dentro do MBR).

O que você está observando é o comportamento normal do MDRAID. Você adicionou novamente as novas unidades usando dois comandos mdadm -a separados, certo? Neste caso, o mdadm irá primeiro ressincronizar o primeiro drive (colocando o segundo no modo "spare") e então ele fará a transição do segundo drive para o status "recriando spare" . Se você adicionar novamente as duas unidades com um único comando (por exemplo: mdadm / dev / mdX -a / dev / sdX1 / dev / sdY1), a reconstrução será executada simultaneamente.

Vamos dar uma olhada no meu (teste) RAID6 com falha:

[root@kvm-black test]# mdadm --detail /dev/md200
/dev/md200:
        Version : 1.2
  Creation Time : Mon Feb  9 18:40:59 2015
     Raid Level : raid6
     Array Size : 129024 (126.02 MiB 132.12 MB)
  Used Dev Size : 32256 (31.51 MiB 33.03 MB)
   Raid Devices : 6
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Mon Feb  9 18:51:03 2015
          State : clean, degraded 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : localhost:md200  (local to host localhost)
           UUID : 80ed5f2d:86e764d5:bd6979ed:01c7997e
         Events : 105

    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1
       2       7        2        2      active sync   /dev/loop2
       3       7        3        3      active sync   /dev/loop3
       4       0        0        4      removed
       5       0        0        5      removed

Adicionar novamente as unidades usando dois comandos separados (mdadm / dev / md200 -a / dev / loop6; dormir 1; mdadm / dev / md200 -a / dev / loop7) causou o seguinte relatório detalhado:

[root@kvm-black test]# mdadm --detail /dev/md200
/dev/md200:
        Version : 1.2
  Creation Time : Mon Feb  9 18:40:59 2015
     Raid Level : raid6
     Array Size : 129024 (126.02 MiB 132.12 MB)
  Used Dev Size : 32256 (31.51 MiB 33.03 MB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Mon Feb  9 18:56:40 2015
          State : clean, degraded, recovering 
 Active Devices : 4
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 2

         Layout : left-symmetric
     Chunk Size : 512K

 Rebuild Status : 9% complete

           Name : localhost:md200  (local to host localhost)
           UUID : 80ed5f2d:86e764d5:bd6979ed:01c7997e
         Events : 134

    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1
       2       7        2        2      active sync   /dev/loop2
       3       7        3        3      active sync   /dev/loop3
       6       7        6        4      spare rebuilding   /dev/loop6
       5       0        0        5      removed

       7       7        7        -      spare   /dev/loop7

Depois de algum tempo:

[root@kvm-black test]# mdadm --detail /dev/md200
/dev/md200:
        Version : 1.2
  Creation Time : Mon Feb  9 18:40:59 2015
     Raid Level : raid6
     Array Size : 129024 (126.02 MiB 132.12 MB)
  Used Dev Size : 32256 (31.51 MiB 33.03 MB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Mon Feb  9 18:57:43 2015
          State : clean 
 Active Devices : 6
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : localhost:md200  (local to host localhost)
           UUID : 80ed5f2d:86e764d5:bd6979ed:01c7997e
         Events : 168

    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1
       2       7        2        2      active sync   /dev/loop2
       3       7        3        3      active sync   /dev/loop3
       6       7        6        4      active sync   /dev/loop6
       7       7        7        5      active sync   /dev/loop7

Adicionar as duas unidades em um único comando (mdadm / dev / md200 -a / dev / loop6 / dev / loop7) leva ao relatório:

[root@kvm-black test]# mdadm --detail /dev/md200
/dev/md200:
        Version : 1.2
  Creation Time : Mon Feb  9 18:40:59 2015
     Raid Level : raid6
     Array Size : 129024 (126.02 MiB 132.12 MB)
  Used Dev Size : 32256 (31.51 MiB 33.03 MB)
   Raid Devices : 6
  Total Devices : 6
    Persistence : Superblock is persistent

    Update Time : Mon Feb  9 18:55:44 2015
          State : clean, degraded, recovering 
 Active Devices : 4
Working Devices : 6
 Failed Devices : 0
  Spare Devices : 2

         Layout : left-symmetric
     Chunk Size : 512K

 Rebuild Status : 90% complete

           Name : localhost:md200  (local to host localhost)
           UUID : 80ed5f2d:86e764d5:bd6979ed:01c7997e
         Events : 122

    Number   Major   Minor   RaidDevice State
       0       7        0        0      active sync   /dev/loop0
       1       7        1        1      active sync   /dev/loop1
       2       7        2        2      active sync   /dev/loop2
       3       7        3        3      active sync   /dev/loop3
       7       7        7        4      spare rebuilding   /dev/loop7
       6       7        6        5      spare rebuilding   /dev/loop6

Então, no final: deixe o mdadm fazer sua mágica, então verifique se todas as unidades estão marcadas como "ativas".

    
por 09.02.2015 / 19:05