Perguntas[raid](server)

Um dos meus discos RAID1 falhou recentemente. Comprei um substituto, conectei-o e formatei-o como Linux RAIDusando cfdisk.

• Nova unidade é/dev/sdc
• A unidade antiga é/dev/sdd

Eles parecem ter o mesmo número de bytes e setores no geral, mas as partições formatadas diferem em tamanho...

# fdisk -l /dev/sd{c,d}
Disk /dev/sdc: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000VN0022-2EL
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 952AC4E6-20B9-408D-83CE-AC4AEFBC1075

Device     Start         End     Sectors  Size Type
/dev/sdc1   2048 15628052479 15628050432  7.3T Linux RAID


Disk /dev/sdd: 7.28 TiB, 8001563222016 bytes, 15628053168 sectors
Disk model: ST8000VN004-2M21
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 4069B8CB-4C43-304B-B872-DDB89C0E0AA1

Device     Start         End     Sectors  Size Type
/dev/sdd1   2048 15628053134 15628051087  7.3T Linux RAID

Especificamente...

/dev/sdc1   2048 15628052479 15628050432  7.3T Linux RAID
/dev/sdd1   2048 15628053134 15628051087  7.3T Linux RAID

A nova partição /dev/sdc1é menor que a partição existente. Como consequência...

# mdadm --manage /dev/md127 --add /dev/sdc1
mdadm: Value "kimura:0" cannot be set as devname. Reason: Not POSIX compatible. Value ignored.
mdadm: /dev/sdc1 not large enough to join array

Encontrei um tópico sugerindo que um ( /dev/sddque é o ST8000VN004) está usando 512E para emular 512 bytes por setor lógico, apesar de ser 4096 bytes por setor físico.

Agora estou com medo de redimensionar a partição existente /dev/sdd1para corresponder à minha, /dev/sdc1pois ela faz parte de uma matriz RAID1 com três volumes lógicos no topo.

Encontrei um tópico relacionado , mas o problema lá é diferente, pois eles têm um RAID de 3 TB e querem particionar um novo de 14 TB, então o espaço não é um problema. Aqui, minha nova partição é menor que a existente.

Qualquer ideia ou conselho sobre como proceder seria bem-vindo.

Tenho um array Raid 5 de 4 drives. Um dos drives (sdb) mostra muitos erros e meu array mostra altas latências durante o acesso.

Atualmente tenho um disco novo e outro está comandado.

Como parte da substituição, também quero aumentar o nível do ataque de 5 para 6. Identifico que pretendo atingir isso:

Ao crescer primeiro para o nível 6

mdadm --manage /dev/md0 --add /dev/sdf1 
mdadm --grow /dev/md0 --raid-devices 5 --level 6 --backup-file /<path>/mdadm-backup
mdadm --manage /dev/md0 --replace /dev/sdb1 # Set faulty but keep it for replacement until a spare drive is available
# After my second drive arrived
mdadm --manage /dev/md0 --add /dev/sdg1

Primeiro substituindo a unidade defeituosa e depois aumentando para o nível 6 do RAID

mdadm --manage /dev/md0 --add /dev/sdf1 
mdadm --manage /dev/md0 --replace /dev/sdb1 --with /dev/sdf1
# after second drive is arrived
mdadm --manage /dev/md0 --add /dev/sdg1
mdadm --grow /dev/md0 --raid-devices 5 --level 6 --backup-file /path/mdadm-backup

Existe alguma diferença entre as duas soluções? Uma é mais segura que a outra por impor menos operações em discos no array?

[Editar] adicionando resultado inteligente:

Sdb (quase com defeito)

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   082   072   006    Pre-fail  Always       -       22562487
  3 Spin_Up_Time            0x0003   093   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       124
  5 Reallocated_Sector_Ct   0x0033   077   077   010    Pre-fail  Always       -       29352
  7 Seek_Error_Rate         0x000f   087   060   030    Pre-fail  Always       -       4963671931
  9 Power_On_Hours          0x0032   026   026   000    Old_age   Always       -       65627
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       124
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       4793
188 Command_Timeout         0x0032   100   072   000    Old_age   Always       -       137445703785
189 High_Fly_Writes         0x003a   001   001   000    Old_age   Always       -       107
190 Airflow_Temperature_Cel 0x0022   073   056   045    Old_age   Always       -       27 (Min/Max 25/28)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       82
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       296
194 Temperature_Celsius     0x0022   027   044   000    Old_age   Always       -       27 (0 14 0 0 0)
197 Current_Pending_Sector  0x0012   001   001   000    Old_age   Always       -       35384
198 Offline_Uncorrectable   0x0010   001   001   000    Old_age   Offline      -       35384
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

SBC

  1 Raw_Read_Error_Rate     0x000f   118   099   006    Pre-fail  Always       -       194860592
  3 Spin_Up_Time            0x0003   093   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       124
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       24
  7 Seek_Error_Rate         0x000f   087   060   030    Pre-fail  Always       -       654004767
  9 Power_On_Hours          0x0032   026   026   000    Old_age   Always       -       65631
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       124
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   094   094   000    Old_age   Always       -       6
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       2
189 High_Fly_Writes         0x003a   062   062   000    Old_age   Always       -       38
190 Airflow_Temperature_Cel 0x0022   073   059   045    Old_age   Always       -       27 (Min/Max 24/27)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       82
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       295
194 Temperature_Celsius     0x0022   027   041   000    Old_age   Always       -       27 (0 14 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

sdd

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   113   094   006    Pre-fail  Always       -       51447952
  3 Spin_Up_Time            0x0003   093   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       124
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   087   060   030    Pre-fail  Always       -       665278320
  9 Power_On_Hours          0x0032   026   026   000    Old_age   Always       -       65630
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       124
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       173
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       1
189 High_Fly_Writes         0x003a   001   001   000    Old_age   Always       -       188
190 Airflow_Temperature_Cel 0x0022   073   055   045    Old_age   Always       -       27 (Min/Max 25/27)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       82
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       296
194 Temperature_Celsius     0x0022   027   045   000    Old_age   Always       -       27 (0 14 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       16
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       16
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Início do problema

Tenho um servidor dedicado no provedor de hospedagem e recentemente meu node exporter detectou alta saturação de io de disco no meu array RAID 1 /dev/md3. Eu verifiquei smartctl para meus discos rígidos e ambos os drives no meu array estavam mostrando alto número de erros de leitura:

[root@ovh-ds03 ~]# smartctl /dev/sda -a | grep Err
Error logging capability:        (0x01) Error logging supported.
     SCT Error Recovery Control supported.
  1 Raw_Read_Error_Rate     0x000b   099   099   016    Pre-fail  Always       -       65538
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0



[root@ovh-ds03 ~]# smartctl /dev/sdb -a | grep Err
Error logging capability:        (0x01) Error logging supported.
     SCT Error Recovery Control supported.
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       65536
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

Eu pedi por meio de um ticket de suporte para substituir 2 discos, mas em vez de substituir, mais 2 discos foram adicionados e o array foi reconstruído nesses 2 novos discos. Tudo estava bem, mas agora o array está em estado degradado e eu tive um alerta por causa disso chamado ️NodeRAIDDegraded, verificando no servidor sim, ele está em estado degradado:

[root@ovh-ds03 ~]# mdadm --detail /dev/md3
/dev/md3:
           Version : 1.2
     Creation Time : Sat Mar 30 18:18:26 2024
        Raid Level : raid1
        Array Size : 1951283200 (1860.89 GiB 1998.11 GB)
     Used Dev Size : 1951283200 (1860.89 GiB 1998.11 GB)
      Raid Devices : 4
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Sep 14 19:30:44 2024
             State : active, degraded
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : md3
              UUID : 939ad077:07c22e9e:ae62fbf9:4df58cf9
            Events : 55337

    Number   Major   Minor   RaidDevice State
       -       0        0        0      removed
       -       0        0        1      removed
       2       8       35        2      active sync   /dev/sdc3
       3       8       51        3      active sync   /dev/sdd3

Como faço para consertar isso?

Eu tentei testar várias soluções para reconstruir a matriz do zero e assim por diante

mdadm --assemble --scan

Conectei um antigo RAID ARRAY a um novo sistema e recebo esse erro em tudo que tento fazer com ele mdadm.

# mdadm --detail --scan 
ARRAY /dev/md/arch1:2021 metadata=1.2 UUID=c4c7cbde:5f6913a9:eb1c82ff:8fe6cd45

# mdadm --detail 
mdadm: Value "arch1:2021" cannot be set as devname. Reason: Not POSIX compatible. Value ignored.
mdadm: No devices given.

Tudo ainda funciona bem. Eu posso montar e usar o Array. E o nome "não compatível" aparece como um arquivo de dispositivo perfeitamente

 # ls -la /dev/md/
total 0
drwxr-xr-x  2 root root   60 2024-08-09 03:16 .
drwxr-xr-x 20 root root 4580 2024-08-09 03:16 ..
lrwxrwxrwx  1 root root    8 2024-08-09 03:16 arch1:2021 -> ../md127

arquivo de dispositivo que eu posso usar

 # mdadm --detail /dev/md/arch1\:2021 
/dev/md/arch1:2021:
           Version : 1.2
     Creation Time : Wed Jul  7 06:29:08 2021
        Raid Level : raid1

Qual é a melhor maneira de atualizar o nome da forma mais segura possível?

Peço desculpas pelo meu inglês.

Recentemente, um dos meus discos no Synology NAS falhou e decidi substituir todos os discos por outros de maior capacidade. Primeiro, substituí o disco defeituoso por um disco de maior capacidade (Disco 1) seguindo as instruções da Synology e tudo correu bem.

Em seguida, substituí outro disco funcional por um disco de maior capacidade (Disco 2). Durante o processo de recuperação (sincronização) do RAID, em torno de 90%, ocorreu algum erro e descobri na interface da web que ambos os meus novos discos (Disco 1 e Disco 2) estavam em status crítico. Li online que poderia substituir o último disco instalado e continuar com a recuperação RAID (sincronização), então substituí o Disco 2 por um novo disco limpo (Disco 3). Este foi provavelmente o meu erro. A interface da web do Synology NAS não ofereceu a recuperação do meu pool de armazenamento como fazia anteriormente. O novo disco (Disco 3) apareceu íntegro e foi isso.

Depois de muita leitura nos fóruns, decidi usar a CLI para tentar a recuperação do RAID, e aqui está o que tenho:

Disco 3 - sata4 Disco 1 - sata3

Não tenho certeza se esse é o caminho certo. Usando o fdisk, criei partições no sata4 baseadas no sata3.

Com os seguintes comandos:

sudo mdadm /dev/md0 --add /dev/sata4p1
sudo mdadm /dev/md1 --add /dev/sata4p2
sudo mdadm /dev/md2 --add /dev/sata4p3

Adicionei as partições correspondentes ao raid10.

Atualmente:

$ cat /proc/mdstat
Personalities : [raid1] [raid10]
md2 : active raid10 sata4p3[5](S) sata3p3[4](E) sata2p3[3] sata1p3[2]
      7792588416 blocks super 1.2 64K chunks 2 near-copies [4/3] [E_UU]

md3 : active raid1 nvme1n1p1[0] nvme0n1p1[1]
      244193984 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sata4p2[0] sata3p2[1] sata2p2[3] sata1p2[2]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sata4p1[1] sata3p1[0] sata2p1[3] sata1p1[2]
      8388544 blocks [4/4] [UUUU]

unused devices: <none>

$  sudo mdadm -D /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Tue Dec 13 14:54:17 2022
     Raid Level : raid1
     Array Size : 8388544 (8.00 GiB 8.59 GB)
  Used Dev Size : 8388544 (8.00 GiB 8.59 GB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sat Jul  6 23:37:15 2024
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

           UUID : 66c55d68:831b4099:05d949f7:b0bbaec7
         Events : 0.58225

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sata3p1
       1       8       49        1      active sync   /dev/sata4p1
       2       8        1        2      active sync   /dev/sata1p1
       3       8       17        3      active sync   /dev/sata2p1

$  sudo mdadm -D /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Tue Dec 13 14:54:20 2022
     Raid Level : raid1
     Array Size : 2097088 (2047.94 MiB 2147.42 MB)
  Used Dev Size : 2097088 (2047.94 MiB 2147.42 MB)
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Sat Jul  6 21:05:57 2024
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

           UUID : f52a567f:3734ea2b:05d949f7:b0bbaec7
         Events : 0.137

    Number   Major   Minor   RaidDevice State
       0       8       50        0      active sync   /dev/sata4p2
       1       8       34        1      active sync   /dev/sata3p2
       2       8        2        2      active sync   /dev/sata1p2
       3       8       18        3      active sync   /dev/sata2p2
$  sudo mdadm -D /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Tue Dec 13 15:16:49 2022
     Raid Level : raid10
     Array Size : 7792588416 (7431.59 GiB 7979.61 GB)
  Used Dev Size : 3896294208 (3715.80 GiB 3989.81 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sat Jul  6 23:26:24 2024
          State : clean
 Active Devices : 3
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 1

         Layout : near=2
     Chunk Size : 64K

           Name : nas:2  (local to host nas)
           UUID : 2894354f:67be6652:bbba583f:6cbe1629
         Events : 65803

    Number   Major   Minor   RaidDevice State
       4       8       35        0      faulty active sync set-A   /dev/sata3p3
       -       0        0        1      removed
       2       8        3        2      active sync set-A   /dev/sata1p3
       3       8       19        3      active sync set-B   /dev/sata2p3

       5       8       51        -      spare   /dev/sata4p3

As partições no sata4 foram adicionadas como peças sobressalentes em todos os lugares. md0 e md1 recuperados automaticamente. md2 não se recuperou automaticamente, provavelmente devido ao estado defeituoso de /dev/sata3p3.

Escolhi o caminho certo? Quais são os próximos passos que devo tomar?

Eu tenho uma matriz RAID 5 na qual um banco de dados lê e grava pequenas quantidades de dados.

Em circunstâncias normais, as operações do banco de dados, incluindo a confirmação, são executadas em um tempo aceitável. No entanto, quando uma grande quantidade de dados é carregada na matriz RAID (mas não no banco de dados), a confirmação (mas não as outras operações) torna-se inaceitavelmente lenta.

Minha suposição atual é que o commit demora muito porque as informações de paridade precisam ser calculadas e/ou gravadas no disco.

Existe uma maneira de verificar minha suposição, ou seja, existe uma ferramenta que exibe a quantidade de CPU necessária para calcular as informações de paridade e se esse é o gargalo.

Além disso, estou pensando em mudar o array para RAID 10 ou RAID 1. Mas antes de fazer isso, existe uma abordagem científica que me permita estimar se vale a pena o incômodo?

Estou executando o Debian 12 com um RAID de software ( /dev/md/).

Estou curioso para saber como o conceito de partições (e tabelas de partição) coexiste com o conceito de matrizes RAID. Aqui está meu entendimento atual (corrija-me se estiver errado em algum lugar):

Um disco rígido físico pode ser particionado em vários segmentos. Uma tabela de partição fica no início do espaço em disco para descrever como ele é particionado. Existem vários tipos de tabelas de partição (MBR, GPT, ...)

Uma matriz RAID é um único "volume físico" composto por vários discos rígidos (ou seja, uma matriz). Para o sistema operacional, isso aparece como um único dispositivo físico. Além disso, esta matriz RAID pode ser particionada como um todo.

Então, minha pergunta - se você adicionar discos físicos a um controlador RAID, esse controlador RAID sequestrará automaticamente cada disco físico e explodirá/reescreverá uma única tabela de partição de disco de forma que controle todo o dispositivo? Ou os controladores RAID estão conscientes do fato de que unidades individuais podem ser particionadas?

Atualizarei um RAID 1 com 2 HDDs para um RAID 1 com 2 SSDs em um servidor Dell T420 (PERC H310).

Mas primeiro gostaria de fazer alguns testes com a instalação de um novo sistema operacional neste novo RAID 1 com SSDs.

Posso retirar os HDDs sem excluir o disco virtual deles, criar um novo disco virtual com os novos SSDs, fazer testes, retirar os SSDs e recolocar os HDDs sem perda de funcionalidade, como se nada tivesse acontecido?

Outra pergunta, o que é melhor, retirar primeiro os HDDs e depois criar um novo disco virtual com SSDs no servidor ou colocar SSDs, criar um disco virtual e depois retirar os HDDs do servidor?

Obrigado

Além do preço, há alguma desvantagem em usar o controlador RAID de hardware para criar uma matriz RAID 1 (espelho)?

Quero dizer, por exemplo, é possível criar o array RAID 1 com a função RAID de placa de base (por causa do custo) e depois mudar para um controlador RAID de extensão PCI melhor? Ou e se a placa PCI apresentar defeito? Posso substituí-lo por um do mercado atual, talvez de um fornecedor diferente? Não tenho certeza se esses controladores gravam metadados nos próprios discos, como no caso de SW RAID, ou mantêm essas informações em seu próprio armazenamento interno.

Tenho um array MD de aproximadamente 20 TB distribuído por 5 discos rígidos de 6 TB. ontem uma das unidades falhou e o sistema parou de inicializar. Eu não sou muito bom em Linux, então sempre que isso acontecia no passado, eu simplesmente reinstalava o Debian e executava quaisquer mdadmcomandos necessários que pudessem ser necessários para fazer o array funcionar novamente (depois de pegar um HD sobressalente na minha loja local ). especificamente, eu removo a unidade antiga do sistema, executo mdadm --assemblee adiciono a nova unidade ao array para que ela seja provisionada no dia seguinte ou depois.

Desta vez, quando corro mdadm --assemble /dev/md0 /dev/sd{a,c,d,f}1 --force, ele não reclama disso No super block found on /dev/sdc1 (expected magic a92b4efc, got 00000000).

para algum contexto, essas 4 unidades (sd{a,c,d,f}) são discos rígidos novos, comprados nos últimos 3 meses. a unidade que seria a quinta (que removi e substituí por uma das novas) tem cinco anos.

embora sdc possa ser a unidade com falha (estou prestes a testar), é mais provável que seja a antiga. Meu backup também é um pouco antigo, com cerca de 2 meses. para ser sincero, nem sei por onde começar. Eu pesquisei no Google, mas tudo parece muito misterioso para este mero mortal e estou com muito medo de que um passo em falso possa me fazer perder todos os meus dados (se ainda não o fiz).

Posso fornecer registros do que estou fazendo agora. meu sistema atual é o Debian 12 rodando em um host Hyper-V. apreciaria qualquer ajuda.