Problema grave de RAID que entra em pane no sistema

3

Sistema: Dual CPU Xeon E5-2630, 32 GB de RAM, disco primário é um SSD Crucial SATA-III 512GB OS: Xubuntu 14.04.1

Estou tendo um problema sério com o RAID nesse novo sistema e espero que alguns de vocês possam fornecer algumas dicas. Atualmente, o SSD primário com o sistema de arquivos raiz não é espelhado, embora eu planeje espelhá-lo para um segundo SSD idêntico no futuro. Estou tentando configurar um RAID em um HDD secundário e não estou disposto a atualizar o SSD primário até que este problema seja resolvido.

Eu tenho um par de unidades SATA-III Seagate ST4000DM0004TB Baracuda 4TB neste sistema que foram formatadas de forma idêntica com uma única grande partição ext4 GPT. Eu tenho tentado criar um espelho RAID 1 útil nesses discos que é montado em / x. Em um ponto eu tive algo que parecia ser estável e corri por algumas semanas até que eu tentei modificar o Array, em que ponto ele falhou. Toda vez que o espelho falha, aparentemente entra em pânico no sistema e o sistema de arquivos raiz no SSD é remontado como somente leitura conforme a configuração em / etc / fstab (errors = remount-ro). Claro que o sistema agora é inútil e requer um hard reset. O sistema é reinicializado, mas o espelho está totalmente corrompido e geralmente deve ser destruído e reconstruído. Eu executei diagnósticos de hardware e não vejo nenhum problema. Não há dicas sobre o que está errado em nenhum dos arquivos de log (dmesg, kern.log, syslog). Aqui estão alguns detalhes:

Eu crio o Array da seguinte forma:

# mdadm --create /dev/md2 --verbose --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
mdadm: /dev/sdc1 appears to contain an ext2fs file system
    size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device. If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: /dev/sdd1 appears to contain an ext2fs file system
    size=-387950592K mtime=Wed Dec 31 16:00:00 1969
mdadm: size set to 3906885440K
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md2 started.

Verifico o progresso da criação de RAID:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[1] sdc1[0]
    3906885440 blocks super 1.2 [2/2] [UU]
    [>....................] resync = 0.4% (17314560/3906885440) finish=415.6min speed=155968K/sec

unused devices: <none>

Eu continuo a monitorar periodicamente a operação de ressincronização com o comando acima e ele se move sem problemas. No entanto, em algum momento (eu tive o resync chegar a qualquer lugar de 4% a 60% sincronizado), o sistema entra em pânico e root é remontado RO. Quando o sistema é reinicializado, geralmente encontro o seguinte:

# l /dev/md*
/dev/md127 /dev/md127p1

/dev/md:
dymaxion:2@ dymaxion:2p1@

No caso em que eu consegui construir / executar / dev / md2, eu tinha / dev / md2 e / dev / md2p1 dispositivos sem nada no subdiretório / dev / md. Aqui o sistema em pânico parece tentar salvar a matriz como md127. Eu não entendo porque, mas isso aconteceu repetidamente. Possivelmente, é o resultado de algum algoritmo codificado no software mdadm.

Em algum momento, o array md127 é degradado a tal ponto que não pode ser montado no momento da inicialização (existe uma entrada para o array em / etc / fstab) e outras vezes ele é montado e tentado ressincronizar. No entanto, ele geralmente entra em pane no sistema durante essa operação, levando a uma série contínua de reinicializações.

Eu então destruo o array e tento recriá-lo. Estes são os comandos que eu uso para destruí-lo.

# mdadm --stop /dev/md127
mdadm: stopped /dev/md127

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]

dispositivos não utilizados:

# mdadm -QD /dev/md127
mdadm: cannot open /dev/md127: No such file or directory

# mdadm --zero-superblock /dev/sdc1
# mdadm --zero-superblock /dev/sdd1

Eu tentei construir o array em um sistema silencioso, sem processos de desktop rodando além de algumas janelas de terminal. Eu corri o conjunto de testes de hardware checkbox-gui e tudo corre bem. Eu tentei desconectar todos os outros discos SATA, portas USB, leitor de cartão, disco óptico, etc. e, em seguida, executar a compilação e ainda falhar.

Alguém pode identificar alguma razão pela qual a matriz está falhando ou sugerir alguma maneira de determinar melhor o que está acontecendo?

Aqui estão algumas informações adicionais sobre meus esforços.

O que eu tenho feito no meu Sun Server (Solaris 10) nos últimos 10 anos é conectar um terceiro disco ao array, permitir que ele seja sincronizado, desanexá-lo do array e, em seguida, levá-lo para recuperação de desastres . Isso tem funcionado muito bem e é isso que planejei fazer neste sistema Ubuntu.

Usando os procedimentos acima, eu consegui uma vez obter / dev / md2 construído adequadamente com os dois discos internos. O sistema funcionou sem problemas por algumas semanas, então eu estava pronto para conectar o terceiro disco usando uma baia de troca a quente. Eu reiniciei com o terceiro disco na baia de troca a quente. Por causa das atribuições arbitrárias de dispositivos, o novo disco apareceu como / dev / sda e o espelho estava usando / dev / sdd e / dev / sde.

# mdadm -QD /dev/md2p1 (or: # mdadm -QD /dev/md2)
/dev/md2:
        Version : 1.2
  Creation Time : Tue Sep 9 17:50:52 2014
     Raid Level : raid1
     Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Sep 19 14:02:45 2014
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : dymaxion:2 (local to host dymaxion)
           UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
         Events : 129

      Number Major Minor RaidDevice State
         3 8 65 0 active sync /dev/sde1
         2 8 49 1 active sync /dev/sdd1


# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdd1[2] sde1[3]
      3906885440 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Tudo parece bem. Vamos adicionar / dev / sda1 como reserva para / dev / md2p1:

# mdadm /dev/md2 --add /dev/sda1

# mdadm -QD /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Tue Sep 9 17:50:52 2014
     Raid Level : raid1
     Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
   Raid Devices : 2
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Oct 17 13:36:13 2014
          State : clean
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

           Name : dymaxion:2 (local to host dymaxion)
           UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
         Events : 130

      Number Major Minor RaidDevice State
         3 8 65 0 active sync /dev/sde1
         2 8 49 1 active sync /dev/sdd1

         4 8 1 - spare /dev/sda1

OK, vamos anexar o sobressalente ao array usando a opção de crescimento:

# mdadm /dev/md2 --grow -n3

# mdadm -QD /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Tue Sep 9 17:50:52 2014
     Raid Level : raid1
     Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
  Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
   Raid Devices : 3
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Fri Oct 17 14:43:08 2014
          State : clean, degraded, recovering
 Active Devices : 2
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 0% complete

           Name : dymaxion:2 (local to host dymaxion)
           UUID : 1e131e20:9c899b31:a7494bc5:1dbc253f
         Events : 134

      Number Major Minor RaidDevice State
         3 8 65 0 active sync /dev/sde1
         2 8 49 1 active sync /dev/sdd1
         4 8 1 2 spare rebuilding /dev/sda1

Parece bom! Permitir que o terceiro disco sincronize:

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sda1[4] sdd1[2] sde1[3]
      3906885440 blocks super 1.2 [3/2] [UU_]
      [>....................] recovery = 0.7% (27891328/3906885440) finish=376.2min speed=171823K/sec

unused devices: <none>

Algures depois do espelho ter sincronizado mais de 10%, o sistema entrou em pânico. Desta vez, quando o sistema foi reinicializado, o processo de inicialização não pôde reconectar o espelho a / x e solicitado a repetir ou pular a montagem. Eu pulei e quando o sistema inicializou, não havia como reativar o / dev / md2. Em última análise, tive que destruí-lo e começar de novo. Eu nunca cheguei tão perto novamente. Se isso funcionasse, o plano era marcar o terceiro disco com falha, removê-lo e aumentar o array de volta para dois dispositivos (ou dois dispositivos e um sobressalente ausente).

Você vê algo de errado em qualquer um desses procedimentos de criação?

Peço desculpas pelo longo post. Eu queria tentar fornecer o máximo de informações possível para tentar antecipar qualquer pergunta.

Todas as sugestões são muito apreciadas. Estou particularmente preocupado com o que está causando o pânico do sistema.

Tudo abaixo aqui foi adicionado sábado, 15 de novembro de 2014

Primeiro, deixe-me esclarecer um aparente mal-entendido. @psusi escreveu:

  

Desde que você não mencionou a criação de um sistema de arquivos no array RAID e   montá-lo depois de criar a matriz, e mdadm avisou que   / dev / sdc1 já tem um sistema de arquivos ext2, eu estou supondo que você quer dizer   você já tem um sistema de arquivos em / dev / sdc1, e é isso que está sendo   somente leitura remontada.

Não. O sistema de arquivos raiz está em sua própria unidade SATA-III de estado sólido (sda1) enquanto eu estou tentando construir o espelho md2 usando dois outros discos de 4 TB (sdc e sdd). É enquanto esse espelho está sincronizando que algo dá errado, todo o sistema entra em pânico, e é o sistema de arquivos raiz, não o espelho, que é remontado somente para leitura, tornando todo o SO não operativo e requerendo uma reinicialização total. Na reinicialização, aparentemente, o espelho foi tentado a ser reconstruído, mas agora é chamado tipicamente de / dev / md127.

Sim, eu estava tentando criar o espelho usando dois discos que tinham sido particionados anteriormente com uma tabela de partição GPT e formatados com um grande sistema de arquivos ext4. De tudo o que li, isso deve ser aceitável.

  

[NOTA: Quando o mdadm diz que "/ dev / sdd1 parece conter um arquivo ext2fs   sistema ", está identificando erroneamente o ext4fs - provavelmente devido a um   mensagem de erro codificada que nunca foi atualizada corretamente. Tão longe quanto   os tipos de partição, o GParted não permite que sejam formatados como   digite fd diretamente, mas eu acredito que o mdadm os marca como tal quando   monta-os no array.]

Com base nos comentários abaixo, é isso que tentei:

1: Eu executei um S.M.A.R.T. teste de superfície em todos os quatro drives de 4 TB (2 para espelho, 2 como futuros sobressalentes). Cada teste durou 8,5 horas e todos os discos foram reportados sem erros. O exercício desses discos individualmente nunca causou pânico no sistema.

2: Usando o GParted, apaguei as partições ext4 dos discos sdc e sdd.

3: para ter certeza de que as tabelas de partição originais da GPT foram eliminadas, eu corri:

# sgdisk -Z /dev/sdc
# sgdisk -Z /dev/sdd

4: recriou o array usando os dois discos não formatados.

# mdadm --create /dev/md2 --verbose --level=1 --metadata 1.2 --raid-devices=2 /dev/sdc /dev/sdd
mdadm: size set to 3906887360K
mdadm: array /dev/md2 started

5: Eu comecei a monitorar a sincronização usando "cat / proc / mdstat" e vi que ela avançava muito bem.

Após alguns minutos, o sistema entrou em pânico, como de costume, e o sistema de arquivos raiz (sda1) foi remontado como RO e exigiu uma reinicialização a frio. Na reinicialização, a matriz foi renomeada para / dev / md127 e, nesse caso, ela está em um estado "resync = PENDING" e não está tentando sincronizar automaticamente. A intenção era criar a tabela de partições GPT e a partição ext4 no espelho assim que terminasse a sincronização. (Eu sei que provavelmente poderia ter feito isso durante a sincronização, mas estou tentando isolar as etapas desse processo para ver onde está o problema.)

Aqui estão algumas informações novas que eu encontrei duplicadas nos arquivos syslog e kern.log. Essas mensagens foram registradas logo antes da operação remount-ro.

Nov 15 14:31:15 dymaxion kernel: [58171.002154] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 15 14:31:15 dymaxion kernel: [58171.002163] ata8.00: failed command: IDENTIFY DEVICE
Nov 15 14:31:15 dymaxion kernel: [58171.002167] ata8.00: cmd ec/00:01:00:00:00/00:00:00:00:00/00 tag 16 pio 512 in
Nov 15 14:31:15 dymaxion kernel: [58171.002167]          res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Nov 15 14:31:15 dymaxion kernel: [58171.002169] ata8.00: status: { DRDY }
Nov 15 14:31:15 dymaxion kernel: [58171.002175] ata8: hard resetting link
Nov 15 14:31:15 dymaxion kernel: [58171.329795] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Nov 15 14:31:15 dymaxion kernel: [58171.330336] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.334346] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.339116] ata8.00: supports DRM functions and may not be fully accessible
Nov 15 14:31:15 dymaxion kernel: [58171.343149] ata8.00: disabling queued TRIM support
Nov 15 14:31:15 dymaxion kernel: [58171.347557] ata8.00: configured for UDMA/133
Nov 15 14:31:15 dymaxion kernel: [58171.347625] ata8: EH complete

Isto parece indicar algum tipo de erro SATA, embora, no momento, eu não possa interpretá-lo.

Então, isso fornece alguma pista adicional sobre o que pode estar errado? Eu realmente aprecio a ajuda até agora. Isso me fez pensar em algumas novas direções. Espero que alguém possa fornecer mais informações ou sugestões. Obrigado.

Tudo abaixo aqui foi adicionado sábado, 20 de dezembro de 2014

Como entrada final nesta saga, estou fornecendo as seguintes informações, na esperança de que isso ajude outras pessoas no futuro.

Consegui entrar em contato com o suporte da ASUS nos EUA em relação a esse problema. Recebi uma placa-mãe Z9PE-D8 WS de substituição que instalei e configurei. Quando executei meus testes de RAID, acabei observando exatamente os mesmos resultados que com a placa-mãe original. Com a unidade de sistema de arquivos raiz conectada ao controlador da Marvel:

  • Se os discos RAID 1 adicionais estivessem no controlador da Marvel, qualquer tentativa de executar uma operação significativa do mdadm (8) no array geraria a exceção do kernel e os erros mencionados acima e o sistema operacional inteiro entraria em pane.

  • Se os discos RAID forem removidos do controlador da Marvel, as operações do mdadm (8) poderão ser executadas sem problemas e o sistema funcionará sem problemas.

Como eu pretendia espelhar a partição raiz, fiquei ansioso para ver o que aconteceria se o sistema de arquivos raiz fosse removido do controlador da Marvel e o RAID fosse movido de volta para ele. Infelizmente, não consegui encontrar uma maneira de inicializar o sistema operacional se o sistema de arquivos raiz foi movido para o chipset Intel C602 integrado. Este foi o caso de ambas as placas-mãe.

[NOTA: Se alguém tiver a menor idéia de por que isso não pôde ser feito, eu gostaria de ouvir o motivo. Por exemplo, o GRUB2 armazena algumas informações específicas no momento da instalação que são específicas do controlador?]

Portanto, eu morri o marcador e decidi reinstalar completamente a versão mais recente do Ubuntu Server 14.10 e espelhar o sistema de arquivos raiz como parte do processo de instalação. Mudei os SSDs para o par de portas SATA-III controladas pelo controlador Intel e executei uma nova instalação. Tudo funcionou bem.

Agora, com um sistema em execução com uma raiz espelhada, eu anexei as duas unidades de 4TB ao controlador da Marvel e tentei construir uma nova matriz RAID 1. A matriz logo falhou. Assim, podemos concluir conclusivamente que o controlador da Marvel está fazendo algo que é incompatível com o gerenciamento de software RAID.

Mudei as unidades de 4 TB para portas SATA-II controladas pela Intel C602 e tudo funcionou e continua a funcionar sem problemas. A engenharia da ASUS está investigando o problema enquanto eu tenho uma máquina onde quatro das seis portas SATA-III originais não podem ser usadas.

A lição é que qualquer um que considere usar uma máquina Linux que use o controlador Marvel PCIe 9230 deve se preocupar com a compatibilidade com RAID.

Espero que esta informação seja útil. Se alguém descobrir problemas semelhantes com o controlador da Marvel e puder esclarecer mais sobre o assunto, entre em contato comigo. Obrigado. ~

    
por Jeffery Small 11.11.2014 / 19:40

3 respostas

0

Procurando por amor em todos os lugares errados ....

Obrigado psusi e ppetraki pelas suas respostas úteis. Cada um de vocês me deu informações adicionais sobre como o RAID funciona no Linux.

Acontece que não havia nada de errado com os discos ou com os comandos mdadm que eu estava usando para criar e manipular os arrays RAID. Depois que descobri as mensagens do kernel ata8 , eu procurei na internet usando-as como uma chave e encontrei outras pessoas relatando mensagens semelhantes que estavam associadas a um controlador Marvel SATA. Eu tenho uma placa-mãe ASUS Z9PE-D8 WS com um controlador Marvel PCIe 9230 integrado que aciona quatro portas SATA-III que estavam sendo usadas para esses discos. Eu desconectei as unidades dessas portas, conectei-as a outras portas SATA na placa que estavam sendo conduzidas por um chipset Intel C602 e reiniciei. Neste ponto, consegui construir vários arrays, reconfigurá-los, etc., sem nenhum problema!

O único SSD com o sistema de arquivos raiz ainda está conectado ao controlador da Marvel e não exibiu nenhum problema em execução. No entanto, agora não tenho planos de tentar espelhar esta unidade até que ela também seja removida do controlador da Marvel.

Estou tentando obter algumas informações da ASUS sobre esse problema. Eu não sei isso poderia indicar um problema de hardware ou BIOS. Até agora, o suporte técnico da ASUS tem sido lento para responder aos meus pedidos. Eu não estou impressionado com o serviço deles.

Se alguém tivesse informações adicionais relacionadas aos problemas do controlador da Marvel, eu certamente apreciaria ouvir sobre isso.

Então, estou de volta aos negócios, por enquanto, quatro portas SATA-III têm um sistema funcionando corretamente. Obrigado novamente pela ajuda.

    
por Jeffery Small 19.11.2014 / 07:50
0

O maior problema que vejo é isso

mdadm: /dev/sdd1 appears to contain an ext2fs file system

Além disso, essas partições devem ser marcadas como membros RAID (tipo fd) , e não em sistemas de arquivos Linux.

O que significa que existem superblocos que as ferramentas extfs podem usar, como fsck, e bagunçar o seu mundo de maneira ruim. Eu recomendaria strongmente que você limpe completamente as unidades antes de adicioná-las a elas usando o dd da mesma forma.

dd if=/dev/zero of=/dev/bye-bye-entire-sd-device

Verifique se você está formatando o dispositivo MD com seu sistema de arquivos, não com os membros.

Se tudo isso funcionar e você ainda estiver vendo a corrupção aleatória, provavelmente terá alguma memória marginal que está gravando lixo de vez em quando e destruindo seus discos.

Para referência futura: link

    
por ppetraki 11.11.2014 / 19:53
0

Como você não mencionou a criação de um sistema de arquivos na matriz RAID e a montagem após a criação da matriz, e mdadm avisou que / dev / sdc1 já possui um sistema de arquivos ext2, estou supondo que você esteja falando sério já tem um sistema de arquivos em / dev / sdc1, e é isso que está sendo remontado somente para leitura. Isso ocorre porque a criação de um array de raid a partir de um disco ou partição é geralmente uma operação destrutiva, daí porque mdadm avisou você. Ao gravar os metadados do ataque na partição, você danificou o sistema de arquivos existente.

Neste ponto, você precisa tentar desfazer o dano que você fez se quiser recuperar os dados existentes em / dev / sdc1. Comece por desmontar o sistema de arquivos antigo, depois explodir os superblocos de raid que você criou e, em seguida, fsck o sistema de arquivos antigo e espere que ele possa ser reparado:

umount /dev/sdc1
mdadm --zero-superblocks /dev/sdc1 /dev/sdd1
e2fsck -fy /dev/sdc1

Para atualizar um sistema de arquivos existente para um raid1, você primeiro precisa criar o array raid usando apenas o novo disco, então copie manualmente todos os seus arquivos do antigo FS para o novo:

mdadm --create --level 1 -n 2 /dev/sdd1 missing
mkfs.ext4 /dev/md0
mkdir /mnt/new
mkdir /mnt/old
mount /dev/md0 /mnt/new
mount /dev/sdc1 /mnt/old
cp -ax /mnt/old/* /mnt/new/
umount /mnt/old
umount /mnt/new
rmdir /mnt/old
rmdir /mnt/new

Agora edite seu / etc / fstab para montar o novo volume em / dev / md0 ao invés do antigo em / dev / sdc1, e finalmente você pode entregar / dev / sdc1 sobre para md para espelhar tudo em / dev / sdd1 em:

mdadm /dev/md0 --add /dev/sdc1

Você pode usar blkid para procurar o UUID do novo sistema de arquivos na matriz de ataque e usá-lo para substituir o antigo UUID em / etc / fstab. Além disso, todos esses comandos devem ser executados como root, portanto, você vai querer sudo -s primeiro para se tornar root.

Finalmente, FYI, você pode querer usar o raid10 ao invés do raid1. Com o layout de deslocamento ( -p o2 to mdadm ) e um tamanho de tamanho de pedaço maior (-c 1024 a 4096), você pode obter a redundância de raid1 mais a taxa de transferência de leitura sequencial de raid0.

    
por psusi 12.11.2014 / 00:31