Como um único disco em uma matriz SATA RAID-10 de hardware interrompe toda a matriz?

103

Prelúdio:

Eu sou um código-macaco que está cada vez mais assumindo as funções de SysAdmin para minha pequena empresa. Meu código é nosso produto e, cada vez mais, fornecemos o mesmo aplicativo que o SaaS.

Há cerca de 18 meses, mudei nossos servidores de um fornecedor central de hospedagem premium para um empurrador de rack barebones em um data center de nível IV. (Literalmente do outro lado da rua.) Esse processo é muito mais importante - coisas como rede, armazenamento e monitoramento.

Como parte da grande mudança, para substituir nosso armazenamento conectado direto alugado da empresa de hospedagem, construí um NAS de 9 TB de dois nós baseado em chassis SuperMicro, placas RAID 3ware, Ubuntu 10.04, duas dúzias de discos SATA, DRBD e. Está tudo cuidadosamente documentado em três postagens do blog: Construindo e testando um novo NAS de 9TB SATA RAID10 NFSv4: Parte I , Parte II e Parte III .

Também configuramos um sistema de monitoramento Cacit. Recentemente, adicionamos mais e mais pontos de dados, como valores SMART.

Eu não poderia ter feito tudo isso sem os impressionantes boffins em ServerFault . Tem sido uma experiência divertida e educacional. Meu chefe está feliz (economizamos muitos US $) , nossos clientes estão felizes (os custos de armazenamento estão baixos) , estou feliz (divertido, divertido, divertido) .

Até ontem.

Interrupção e recuperação:

Algum tempo depois do almoço, começamos a obter relatórios de desempenho lento de nosso aplicativo, um CMS de mídia de streaming sob demanda. Na mesma época, nosso sistema de monitoramento Cacti enviou uma nevasca de e-mails. Um dos alertas mais reveladores foi um gráfico de iostat aguardando.

insira a descrição da imagem aqui

O desempenho ficou tão degradado que Pingdom começou a enviar notificações de "servidor inativo". A carga geral foi moderada, não houve pico de tráfego.

Depois de fazer login nos servidores de aplicativos, clientes NFS do NAS, confirmei que praticamente tudo estava passando por tempos de espera de IO altamente intermitentes e insanamente longos. E uma vez que entrei no próprio nó primário do NAS, os mesmos atrasos foram evidentes ao tentar navegar no sistema de arquivos da matriz com problemas.

Hora de falhar, tudo correu bem. Em 20 minutos, tudo foi confirmado como perfeito e funcionando perfeitamente.

Post-Mortem:

Após toda e qualquer falha no sistema, eu executo um post-mortem para determinar a causa da falha. A primeira coisa que fiz foi colocar o ssh de volta na caixa e começar a revisar os logs. Estava offline, completamente. Hora de uma viagem ao centro de dados. Reinicialização do hardware, backup e execução.

Em /var/syslogeu encontrei esta entrada assustadora:

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

Então fui verificar os gráficos do Cacti para os discos na matriz. Aqui vemos que, sim, o disco 7 está desaparecendo, como o syslog diz. Mas também vemos que os SMART Read Erros do disco 8 estão flutuando.

insira a descrição da imagem aqui

Não há mensagens sobre o disco 8 no syslog. Mais interessante é que os valores flutuantes do disco 8 se correlacionam diretamente com os altos tempos de espera de E / S! Minha interpretação é a seguinte:

  • O disco 8 está apresentando uma falha de hardware estranha que resulta em longos períodos de operação intermitentes.
  • De alguma forma, essa condição de falha no disco está bloqueando toda a matriz

Talvez exista uma descrição mais precisa ou correta, mas o resultado final foi que o único disco está afetando o desempenho de toda a matriz.

As questões)

  • Como um único disco em uma matriz SATA RAID-10 de hardware interrompe toda a matriz?
  • Estou sendo ingênuo pensar que a placa RAID deveria ter lidado com isso?
  • Como posso impedir que um único disco com comportamento inadequado cause impacto em toda a matriz?
  • Estou esquecendo de algo?
Stu Thompson
fonte
11
Outra pergunta bem escrita de você, +1. É sempre um prazer ler (mas, infelizmente, acima do meu quadro, tenho uma idéia).
tombull89
1
@daff: Compre o orçamento atual nesta configuração e economizamos 66% de um comparável da HP. Colocamos uma vida útil de um ano nesta caixa, ela não precisa durar mais. Lembre-se de que esta é uma caixa de armazenamento, que custa a cada ano.
Stu Thompson
2
3Ware não é ruim, por si só. Eu tive um comportamento instável de uma placa PERC em um sistema Dell, que deveria ser um hardware de servidor decente. O cartão 3Ware deve ter bateria integrada e tal, para que eu não me sentisse muito mal com a decisão. Tudo bem, você pode ser criticado pela decisão SAS vs. SATA, mas não está perdendo dados e, a partir da sua pergunta, parece que você tem backups e monitoramento, por isso está se saindo muito bem :-)
Bart Silverstrim
1
@StuThompson: é claro que é mais barato orçamentar e usar o hardware do consumidor, e na maioria das vezes ele funciona bem, especialmente quando, como no seu caso, existe um bom conceito de HA por trás dele. Mas há casos, como você mostrou, em que o hardware do consumidor simplesmente não funciona quando coisas ruins acontecem. Posso garantir a você que um único disco SAS com defeito em um bom controlador PERC (Dell) ou SmartArray (HP) não teria causado nenhum problema além de uma chamada de suporte para obter um disco de substituição. Tivemos muitos discos SAS mortos ao longo dos anos em produção, mas nunca tivemos um servidor desativado.
daff
5
A maioria dos discos SATA não suporta TLER (Time Limited Error Recovery). Quando um disco SATA típico encontra um problema físico, ele envia uma "espera enquanto eu trabalho nisso" para o subsistema de disco (que geralmente faz o que foi solicitado). O disco continuará gastando 10 a 30 segundos (geralmente) em cada erro encontrado até atingir o limite "Estou morto". Discos SAS e SATA compatíveis com TLER são configurados pelo HBA para informar ao subsistema de disco "Estou com um problema, o que devo fazer?" para que o HBA possa decidir a ação apropriada basicamente imediatamente. (Simplificado por brevidade)
Chris S

Respostas:

48

Detesto dizer "não use SATA" em ambientes críticos de produção, mas já vi essa situação com bastante frequência. As unidades SATA geralmente não são destinadas ao ciclo de trabalho que você descreve, embora você tenha especificado unidades especificamente classificadas para operação 24x7 em sua configuração. Minha experiência foi que as unidades SATA podem falhar de maneiras imprevisíveis, muitas vezes afetando toda a matriz de armazenamento, mesmo ao usar RAID 1 + 0, como você fez. Às vezes, as unidades falham de uma maneira que pode parar o barramento inteiro. Uma coisa a observar é se você está usando expansores SAS em sua configuração. Isso pode fazer a diferença na maneira como os discos restantes são afetados por uma falha na unidade.

Mas pode ter feito mais sentido ir com unidades SAS de linha média / nearline (7200 RPM) versus SATA. Há um pequeno prêmio de preço em relação à SATA, mas as unidades irão operar / falhar de forma mais previsível. A correção de erros e os relatórios na interface / protocolo SAS são mais robustos que o conjunto SATA. Portanto, mesmo com unidades cuja mecânica é a mesma , a diferença de protocolo SAS pode ter evitado a dor que você experimentou durante a falha de sua unidade.

ewwhite
fonte
Enquanto escrevia a pergunta, sabia que minha escolha do SAS iria surgir. : / O IOPS e a taxa de transferência estão dentro dos recursos da minha instalação. Mas não percebi completamente algumas das diferenças mais sutis. Colocamos uma vida útil de três anos nesta caixa. Não se esqueça de usar o SAS na próxima vez.
Stu Thompson
1
Sim, é algo a considerar na próxima vez. As unidades SAS nearline que eu mencionei não necessariamente têm um desempenho melhor que o SATA, mas são como recuperação de erros e falhas de unidade em que o SAS é mais gerenciável. Eu tenho um sistema de armazenamento Sun Fire x4540 de 48 unidades SATA com 6 controladores, e as falhas de unidades individuais tendem a bloquear o servidor. Lição difícil.
ewwhite
10
Um bom amigo meu está no mundo do armazenamento corporativo. Ele leu tudo isso e disse "esse cara está certo. O que acontece é que o SATA é projetado para indicar uma falha completa e um intermitente solicita o barramento sem a ativação de failover. Normalmente isso nunca é visto, pois a maioria das configurações SATA é uma unidade "
Stu Thompson
@StuThompson Desde então, você construiu uma nova caixa com SAS próximo da linha? Eu adoraria ler sobre suas experiências. Sua pergunta já me ajudou muito, provavelmente estarei construindo uma caixa semelhante no futuro próximo.
precisa
1
@chrishiestand Não, eu não tenho. Saí da empresa em 13 de janeiro; se eu tivesse ficado, teríamos construído a caixa de reposição com linha próxima. Infelizmente, a existência do NAS estava intimamente ligada à minha e os dados foram movidos para a SAN de um provedor de serviços.
precisa saber é o seguinte
17

Como um único disco pode derrubar a matriz? A resposta é que não deveria, mas depende do que está causando a interrupção. Se o disco morresse de uma maneira que se comportasse, não o derrubaria. Mas é possível que esteja falhando de uma maneira "superficial" que o controlador não pode lidar.

Você é ingênuo em pensar que isso não deveria acontecer? Não, eu não penso assim. Uma placa RAID de hardware como essa deveria ter resolvido a maioria dos problemas.

Como evitá-lo? Você não pode prever casos extremos estranhos como esse. Isso faz parte de ser um administrador de sistemas ... mas você pode trabalhar nos procedimentos de recuperação para impedir que isso afete seus negócios. A única maneira de tentar corrigir isso agora é tentar outra placa de hardware (provavelmente não o que você gostaria de fazer) ou alterar suas unidades para unidades SAS em vez de SATA para ver se o SAS é mais robusto. Você também pode entrar em contato com o fornecedor da placa RAID e contar o que aconteceu e ver o que eles dizem; eles são, afinal, uma empresa que deveria se especializar em conhecer os meandros da eletrônica de acionamento instável. Eles podem ter mais conselhos técnicos sobre como as unidades funcionam, além de confiabilidade ... se você puder encontrar as pessoas certas para conversar.

Você perdeu alguma coisa? Se você deseja verificar se a unidade está com uma falha de borda, puxe-a da matriz. A matriz será degradada, mas você não deve ter mais lentidões e erros estranhos (além do status da matriz degradada). Você está dizendo que, no momento, parece estar funcionando bem, mas se houver erros de leitura de disco, substitua a unidade enquanto puder. Às vezes, unidades com alta capacidade podem ter erros de URE (melhor motivo para não executar o RAID 5, observação lateral) que não aparecem até que outra unidade falhe. E se você estiver enfrentando um comportamento de ponta nessa unidade, não deseja que dados corrompidos sejam migrados para as outras unidades da matriz.

Bart Silverstrim
fonte
1
Sim ... já adotamos uma nova política de substituição como "se os erros de leitura flutuarem, então puxe-a" . Agora que penso nisso, tivemos uma taxa bastante alta de falhas nessas unidades. 4 de 22 em 18 meses. Hmmm ....
Stu Thompson
2
4 unidades em 18 meses? essa é uma taxa bastante alta ... embora as unidades não estejam na especificação, pode haver também um problema de refrigeração / fluxo de ar. Ou possivelmente algo estranho com o controlador. Apenas alguns pensamentos ... fique de olho nos logs. Se você puder entrar em contato com alguém no 3Ware com trabalho real nos cartões e não apenas com um script, convém executá-lo e ver o que eles dizem.
22411 Bart
1
Dependendo do conjunto em que você está vendo os erros, você também pode verificar se não há algo estranho ou marginal nos cabos. Se os erros parecerem concentrados na mesma porta, você poderá ter menos de um conjunto coincidente de falhas.
22611 Bart
4
Acabei de ver que os valores SMART para este drive bum estavam funcionando a ~ 31 ° C, ou uns bons 4 ° C mais altos que todos os outros drives. Coisas que o fazem ir hmmmm ....
Stu Thompson
2
@ DanNeely: de 14 unidades (11 dados, 3 sistemas), foi a única com uma temperatura mais alta. Tenho quase certeza de que o fluxo de ar estava bom, mas verificará explicitamente amanhã.
Stu Thompson
10

Não sou especialista, mas vou dar um tiro no escuro com base na minha experiência com controladores RAID e matrizes de armazenamento.

Os discos falham de várias maneiras diferentes. Infelizmente, os discos podem falhar ou apresentar falhas, de maneiras que seu desempenho é seriamente afetado, mas o controlador RAID não vê como uma falha.

Se um disco falhar de uma maneira óbvia, qualquer software de controlador RAID deve ser muito bom em detectar falta de resposta do disco, removê-lo do pool e acionar notificações. No entanto, meu palpite sobre o que está acontecendo aqui é que o disco está sofrendo uma falha incomum que, por algum motivo, não está causando uma falha no lado do controlador. Portanto, quando o controlador está realizando uma descarga de gravação ou uma leitura do disco afetado, está demorando muito tempo para voltar e, por sua vez, está paralisando todo o IO operacional e, portanto, a matriz. Por qualquer motivo, isso não é suficiente para o controlador RAID ficar "ah, disco com falha", provavelmente porque os dados acabam voltando eventualmente.

Meu conselho seria substituir imediatamente o disco com falha. Depois disso, eu daria uma olhada na configuração da sua placa RAID (é 3ware, achei muito boa) e descobriria o que considera um disco com falha.

PS boa idéia importar SMART para cactos.

crescer
fonte
Depois de conectar os pontos, o primeiro pensamento que fiz foi remover o disco da matriz; a reposição quente foi preenchida. Isso foi ontem à noite. Hoje eu peguei o disco e fiz RMA. A unidade de ofensa: geekomatic.ch/images/wd-re4-flux-read-error.jpg
Stu Thompson
Uma das razões pelas quais acho que todo sistema de missão crítica precisa ter um cartão que faz a limpeza de dados. Eu já vi isso muitas vezes para contar, especialmente em matrizes SATA, no entanto, sabe-se que discos SAS de extremidade superior ainda falham sem acionar o controlador.
Jens Ehrich
7

Você precisa dos recursos de dispositivos de armazenamento de classe corporativa. Especificamente, as unidades corporativas WD RE 4 têm dois recursos necessários para evitar esse comportamento nas matrizes RAID. A primeira tecnologia listada abaixo evita que a vibração harmônica rotacional cause desgaste desnecessário nos componentes mecânicos do disco rígido. A segunda tecnologia foi o que causou o seu problema, o protocolo SATA não possui esse recurso. Para obter esses recursos, você precisa do SAS e, se insistir em unidades SATA, poderá adquirir cartões SAS para SATA Interposer, como o LSISS9252.

Tecnologia RAFF aprimorada Os eletrônicos sofisticados monitoram o inversor e corrigem as vibrações linear e rotacional em tempo real. O resultado é uma melhoria significativa de desempenho em ambientes de alta vibração em relação à geração anterior de inversores.

Recuperação de erro por tempo limitado (TLER) específica para RAID Evita a queda da unidade causada pelos processos estendidos de recuperação de erro do disco rígido comuns às unidades de desktop.

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

Consulte também o link abaixo:

http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

Consulte também: Documento TLER da Western Digital que explica detalhadamente o processo de recuperação de erros. Prevenção de precipitação de recuperação de erro nos discos rígidos WD Caviar RAID Edition Serial ATA:

http://www.3dfxzone.it/public/files/2579-001098.pdf

Canhão solto
fonte
6

Apenas um palpite: os discos rígidos são configurados para tentar novamente os erros de leitura em vez de relatar um erro. Embora esse seja um comportamento desejável em uma configuração de área de trabalho, é contraproducente em um RAID (onde o controlador deve reescrever qualquer setor que falhe na leitura dos outros discos, para que a unidade possa remapear).

Simon Richter
fonte
Muito possivel. Nesse caso, isso não é legal, pois eles são especificados como unidades "edição RAID". : |
Stu Thompson
Absolutamente não é legal, porque essa configuração é a própria definição de "edição RAID" :)
Simon Richter
6

meu tiro no escuro:

  • a unidade 7 está falhando. possui algumas janelas de falha onde não está disponível.

  • a unidade 8 também possui alguns erros 'mais leves'; corrigido ao tentar novamente.

  • RAID10 é geralmente "um RAID0 de vários pares RAID1", as unidades 7 e 8 são membros do mesmo par?

nesse caso, parece que você atingiu o caso "não deveria acontecer" de falha de dois discos no mesmo par. quase a única coisa que pode matar um RAID10. infelizmente, isso pode acontecer se todas as suas unidades pertencerem ao mesmo lote de remessa e, portanto, é mais provável que elas morram simultaneamente.

Eu acho que durante uma falha na unidade 7, o controlador redirecionou todas as leituras para a unidade 8, portanto, qualquer tentativa de erro causava grandes atrasos que causavam uma avalanche de tarefas congeladas, prejudicando o desempenho por um tempo.

você tem sorte de a unidade 8 ainda não estar morta, então você deve poder consertar sem o dataloss.

Eu começaria alterando as duas unidades e não se esqueça de verificar os cabos. uma conexão frouxa pode causar isso e, se não for roteada com firmeza, é mais provável que isso ocorra em unidades adjacentes. Além disso, algumas placas de várias portas possuem vários conectores de duas portas; se as unidades 7 e 8 estiverem na mesma, pode ser a fonte do seu problema.

Javier
fonte
3
A unidade 8 é o que causa a interrupção do serviço, eu já a retirei. A unidade 7, apesar de ter perdido alguns sektors, está nesse estado há um tempo e ainda geralmente apresenta um bom desempenho. Não, eles dirigem em pares diferentes. (Foi algo que eu considerei, juntamente com um possível desalinhamento das minhas consultas Cacti / SNMP.) A placa possui 16 portas, 4 cabos, 4 portas por cabo em um painel traseiro. Se o problema for o cartão, o cabo ou o painel traseiro, saberei em breve quando inserir a substituição da unidade 8.
Stu Thompson
3

Cartões SATA Interposer são outra solução.

Recentemente, experimentei exatamente o mesmo destino e encontrei esse tópico. O teor geral é que o protocolo SAS é mais adequado para RAID do que SATA, porque faltam recursos no SATA. É por isso que as mesmas unidades físicas são equipadas com controladores SAS e depois vendidas como Nearline SAS.

Pesquisando mais, encontrei:

http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx

Estou investigando a atualização de um dos meus armazenamentos com um lote deles. No momento, a diferença de preço entre 3 TB SATA e SAS é de 400% (preço de baunilha, mesma marca, especificações e loja, Alemanha). Obviamente, não sei dizer se essa estratégia funciona bem, mas vale a pena tentar.

Comentários muito bem-vindos :-)

korkman
fonte
1
Bem, boa teoria. Após coletar algumas informações, apenas os fabricantes de bandejas de armazenamento podem integrar essas placas e adicioná-las não significa necessariamente melhor tratamento de erros.
Korkman
2

Eu vi um disco SATA com componentes eletrônicos quebrados travar o firmware init de um Areca 12 algo sólido, não havia maneira de acessar o BIOS e muito menos inicializar a máquina a partir de qualquer meio até que o disco rígido ofensivo fosse encontrado puxando os discos em um binário pesquisa de moda.

rackandboneman
fonte