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.

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.

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?

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.

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.

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.

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

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

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.

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 :-)

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.