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.
~