Hot Spare ou um Hot Mess

Uma abordagem comum para adicionar uma camada de segurança ao RAID é manter unidade(s) de reserva disponível(eis) para que o tempo de substituição de uma unidade com falha seja minimizado. A forma mais extrema disso é o que se chama de ter um “hot spare” – uma unidade de reserva efetivamente instalada no array, porém sem uso até que o array detecte uma falha de unidade, momento em que o sistema desativa automaticamente a unidade com falha e ativa o hot spare, da mesma forma como se um humano tivesse simplesmente retirado uma unidade do array e inserido a outra, permitindo que uma operação de resilver (uma reconstrução do array) comece o quanto antes. Isso pode reduzir o tempo de substituição por uma nova unidade de horas ou dias para segundos e, em teoria, pode proporcionar um aumento extremo de segurança.

Primeiro, gostaria de abordar o que pessoalmente considero um equívoco nas convenções de nomenclatura. Aquilo que chamamos de hot spare deveria, a meu ver, na verdade ser chamado de warm spare, pois está ali pronto para entrar em ação, mas não contém os dados necessários para ser usado imediatamente. Uma unidade de reserva armazenada fora do chassi, que exige que um humano intervenha e troque as unidades manualmente, seria um cold spare. Para ser verdadeiramente um hot spare, uma unidade deveria estar repleta de dados e, portanto, seria um membro participante do array RAID em alguma medida. A Red Hat tem um bom artigo sobre como essa terminologia se aplica a sites de recuperação de desastres para referência. Essa diferenciação é importante porque aquilo que chamamos de hot spare não contém dados previamente e não substitui imediatamente a unidade com falha, mas sim entra em ação para iniciar imediatamente o processo de restauração da unidade perdida – uma diferenciação crítica.

Para manter os conceitos claros, daqui em diante vou me referir àquilo que os fornecedores chamam de hot spares como “warm spares”. Isso fará sentido em breve.

Há duas preocupações principais com os warm spares. A primeira é a natureza ineficaz do warm spare na maioria dos casos de uso e a segunda é o risco de “destruição automatizada do array”.

A maioria das pessoas aborda o conceito de warm spare como um meio de mitigar o alto risco de falha de uma segunda unidade em um array RAID 5 com paridade. Arrays RAID 5 protegem apenas contra a falha de um único disco dentro do array. Uma vez que um único disco tenha falhado, o array fica sem qualquer forma de paridade e qualquer falha adicional de unidade resulta na perda total do array. O RAID 5 é escolhido por ter custo muito baixo para a capacidade oferecida e sacrifica a confiabilidade para alcançar essa relação custo-benefício. Como o RAID 5 é, portanto, arriscado em comparação com outras opções de RAID, como RAID 6 ou RAID 10, é comum implementar um warm spare a fim de minimizar o tempo em que o array fica em estado degradado, permitindo que ele comece a se reconstruir o mais rápido possível.

Assim, a conclusão mais relevante aqui é que os warm spares geralmente são usados como um amortecedor contra o uso de tipos de array RAID menos confiáveis como medida de redução de custos. Os warm spares são muito mais comuns em arrays RAID 5, seguidos pelos arrays RAID 6. Ambos são escolhidos em vez do RAID 10 por causa do custo por capacidade, e não por confiabilidade ou desempenho. Há um caso em que a ideia do warm spare realmente faz sentido para aumentar a confiabilidade, e esse é o RAID 10 com warm spare, mas chegaremos a isso. Fora desse cenário, considero que os warm spares fazem pouco sentido no mundo real.

Começaremos examinando o RAID 1 com warm spare. O RAID 1 consiste em duas unidades, ou mais, em espelhamento. Adicionar um warm spare é interessante porque, se uma das unidades espelhadas falhar, o warm spare começará imediatamente a espelhar a unidade remanescente e você estará protegido novamente em pouco tempo. Isso é maravilhoso. Exceto por uma pequena falha: em vez de usar um warm spare, essa mesma unidade poderia ter sido adicionada ao array RAID 1 desde o início, onde funcionaria como um espelho terciário. Nessa função de espelho terciário, a unidade teria contribuído para o desempenho geral do array, proporcionando um aumento de quase cinquenta por cento no desempenho de leitura, com o desempenho de escrita mantendo-se estável, e oferecendo proteção instantânea em caso de falha de unidade, em vez da proteção do tipo “assim que terminar de reespelhar”. Basicamente, teria sido um verdadeiro “hot spare” em vez de um warm spare. Assim, sem gastar um centavo a mais, o sistema teria tido melhor desempenho do array de unidades e melhor confiabilidade simplesmente por ter a unidade extra em uma função “quente”, “dentro do array”, em vez de ficar morna e ociosa esperando o desastre acontecer.

Com o RAID 5 vemos um alerta ainda mais dramático contra o conceito de warm spare, justamente onde ele é mais comum do que em qualquer outro lugar. O RAID 5 é um RAID de paridade simples com a capacidade de reconstruir, usando a paridade, qualquer unidade do array que falhe. É aqui que os problemas reais começam. Diferentemente do RAID 1, onde uma operação de reespelhamento pode ser bastante rápida, um resilver (reconstrução) de RAID 5 tem o potencial de levar bastante tempo. O warm spare não ajudará a proteger o array até que esse processo de resilver seja concluído com sucesso – isso comumente leva muitas horas e facilmente dias, e possivelmente semanas ou meses, dependendo do tamanho do array e do quão ocupado ele esteja. Se pegássemos esse mesmo warm spare e, em vez disso, o designássemos como membro do array com uma faixa de paridade adicional, obteríamos o RAID 6. O mesmo conjunto de unidades que temos para RAID 5 mais warm spare criaria um array RAID 6 com exatamente a mesma capacidade. Novamente, como no exemplo de RAID 1 acima, isso seria muito parecido com ter um hot spare, em que a unidade participa do array com dados ativos em vez de ficar ociosa esperando outra unidade falhar antes de entrar em ação para iniciar o processo de assumir o lugar. Nessa função, o array se degrada para o equivalente a um RAID 5 em caso de falha, mas sem qualquer tempo de reconstrução, de modo que a unidade adicional é útil imediatamente, e não apenas após um processo de resilver possivelmente muito longo. Portanto, pelo mesmo dinheiro e mesma capacidade, a escolha de configurar as unidades em RAID 6 em vez de RAID 5 mais warm spare é uma vitória completa.

Podemos continuar esse exemplo com RAID 6 mais warm spare. Este é um pouco menos fácil de definir porque, na maioria dos sistemas RAID, exceto pelo um tanto incomum RAIDZ3 do ZFS, não há um sistema de paridade tripla disponível um nível acima do RAID 6 (imagine se houvesse um RAID 7, por exemplo). Se houvesse, exatamente o argumento apresentado para RAID 5 mais warm spare se aplicaria ao RAID 6 mais warm spare. Na maioria dos casos, o RAID 6 com warm spare precisa se justificar diante de um array RAID 10. O RAID 10 é mais performático e muito mais confiável do que um array RAID 6, mas o RAID 6 geralmente é escolhido para economizar dinheiro em comparação com o RAID 10. Mas, para compensar a fragilidade do RAID 6, warm spares são por vezes empregados. Em alguns casos, como um pequeno array RAID 6 de cinco discos com warm spare, isso é, dólar por dólar, equivalente a um array RAID 10 de seis discos sem warm spare. Em arrays maiores, o benefício de custo do RAID 6 de fato se torna aparente, mas quanto maior a economia de custo, maior o diferencial de risco, pois sistemas RAID de paridade aumentam o risco com o tamanho do array muito mais rapidamente do que os sistemas RAID baseados em espelhamento, como o RAID 10. Qualquer dinheiro economizado hoje é feito ao risco de indisponibilidade ou perda de dados amanhã.

Onde um warm spare entra em jogo de forma eficaz é em um array RAID 10, onde a reconstrução de um warm spare é uma reconstrução de espelho, como no RAID 1, que não carrega riscos de paridade, e onde não há um sistema RAID que seja uma extensão lógica acima do RAID 10 do qual estaríamos tentando economizar dinheiro ao optar por um sistema mais frágil. Aqui, adicionar um warm spare pode fazer sentido para arrays críticos, pois não há maneira mais econômica de obter a mesma confiabilidade adicional. Entretanto, o RAID 10 é tão confiável sem um warm spare que qualquer empresa que esteja cogitando RAID 5 ou RAID 6 com warm spare logicamente pararia no simples RAID 10, tendo já superado a confiabilidade pela qual antes se contentaria. Assim, apenas as empresas que não estão considerando esses sistemas mais frágeis e que buscam a opção mais robusta possível logicamente recorreriam ao RAID 10 mais warm spare como solução.

Apenas por precisão técnica, o RAID 10 pode ser expandido para melhor desempenho de leitura e melhoria dramática na confiabilidade (mas com um aumento de cinquenta por cento no custo) ao se adotar espelhos RAID 1 de três discos em sua faixa RAID 0, em vez dos espelhos RAID 1 padrão de dois discos, exatamente como mostramos em nosso exemplo de RAID 1. Esse é um nível de confiabilidade raramente buscado no mundo real, mas que pode existir e é uma opção. Normalmente, isso é limitado pelas restrições de quantidade de unidades nos chassis físicos de array, além de competir de forma desfavorável com a construção de um array RAID 10 secundário completamente separado em um chassi diferente e, em seguida, espelhar esses arrays em alto nível, criando efetivamente um RAID 101 – que é o resultado efetivo dos clusters de array de armazenamento comuns e de ponta de hoje.

Nossa segunda preocupação é a da “destruição automatizada do array”. Isso se aplica apenas aos cenários de RAID de paridade, RAID 5 e RAID 6 (ou os raros RAID 2, RAID 3, RAID 4 e RAIDZ3). Com o conceito de warm spare, a ideia é que, quando uma unidade falha, o warm spare é automática e instantaneamente acionado pela controladora do array e o processo de resilver do array começa imediatamente. Se o resilver fosse um processo completamente confiável, isso obviamente seria muito bem-vindo. A realidade é, infelizmente, bem diferente.

Durante um processo de resilver, um array RAID de paridade está sujeito ao surgimento de Erros de Leitura Irrecuperáveis (UREs). Se um URE ocorre em um resilver de RAID de paridade simples (ou seja, RAID 2 a 5), então o processo de resilver falha e o array é perdido completamente. Isso é crítico de entender, pois nenhuma unidade adicional falhou. Portanto, se o warm spare não estivesse presente, o resilver não teria sido iniciado e os dados ainda estariam intactos e disponíveis – apenas não tão rapidamente quanto o habitual e sob o pequeno risco de falha de uma segunda unidade. As taxas de URE são muito altas com as grandes unidades de hoje, e com arrays grandes os riscos podem se tornar tão elevados a ponto de passar de “possível” para “esperado” durante uma operação padrão de resilver.

Assim, em muitos casos, o próprio warm spare pode na verdade ser o gatilho para a perda de dados, em vez do salvador dos dados como se esperava. Um array que teria sobrevivido pode ser destruído pelo processo de resilver antes mesmo de o humano que o gerencia ser alertado sobre a falha da primeira unidade. Se um humano estivesse envolvido, ele poderia, no mínimo, ter tomado a iniciativa de fazer um novo backup do array antes de iniciar o resilver, sabendo que a cópia mais recente dos dados estaria disponível caso o processo de resilver fosse malsucedido. Isso também permitiria ao humano agendar quando o resilver deveria começar, possivelmente esperando até o fim do horário comercial ou o início do fim de semana, quando o array tem menor probabilidade de enfrentar carga pesada.

O RAID de paridade dupla e tripla (RAID 6 e RAIDZ3, respectivamente) compartilham os riscos de URE, pois também são baseados em paridade. Eles mitigam esse risco por meio dos níveis adicionais de paridade e o fazem com sucesso na maior parte das vezes. O risco ainda existe, especialmente em arrays RAID 6 muito grandes, mas, nos próximos vários anos, os riscos permanecem geralmente bastante baixos para a maioria dos arrays de armazenamento, até que mídias de armazenamento baseadas em discos muito maiores estejam disponíveis no mercado.

O maior problema com o RAID de paridade e o risco de URE é que o fator que leva ao RAID de paridade (disposição a enfrentar riscos adicionais à integridade dos dados a fim de reduzir custos) é o mesmo fator que introduz o risco elevado de URE (a compra de discos rígidos SATA de menor custo e não corporativos). Empresas que recorrem ao RAID de paridade geralmente o fazem com discos SATA grandes e de baixo custo, reunindo dois fatores muito perigosos em uma combinação explosiva. Usar RAID 1 ou RAID 10 sem paridade eliminará completamente o problema, e usar discos SAS corporativos altamente confiáveis reduzirá drasticamente o fator de risco em uma ordem de grandeza (não como figura de linguagem, é de fato uma mudança de uma ordem de grandeza).

Além disso, durante operações de resilver, é possível que o desempenho dos sistemas de paridade se degrade tão drasticamente a ponto de equivaler a uma indisponibilidade prolongada. O processo de resilver, especialmente em arrays grandes, pode ser tão intensivo que os usuários finais não conseguem diferenciar entre um array completamente falho e um array em resilver. Na verdade, o resilver, em seu extremo, pode levar tanto tempo e ser tão disruptivo que o custo para o negócio pode ser maior do que se o array simplesmente tivesse falhado por completo e uma restauração a partir de backup tivesse sido feita em seu lugar. Esse problema de resilver não afeta o RAID 1 e o RAID 10, novamente, porque eles são sistemas RAID espelhados, e não de paridade, e seu processo de resilver é trivial, sendo a degradação de desempenho do sistema mínima e de curta duração. Em seu extremo, um resilver de paridade poderia levar semanas ou meses, durante os quais os sistemas se comportam como se estivessem fora do ar – e em qualquer momento durante esse processo há o potencial de surgirem os erros de URE mencionados acima, o que encerraria o resilver e forçaria a restauração a partir de backup de qualquer forma. (Resilvers típicos não levam semanas, mas levam muitas horas, e levar dias não é nada incomum.)

Nossa síntese final pode ser resumida no seguinte (usando novamente o termo convencional “hot spare”): RAID 10 sem um “hot spare” é quase sempre uma escolha melhor do que RAID 6 com um “hot spare”. RAID 6 sem um “hot spare” é sempre melhor do que RAID 5 com um “hot spare”. RAID 1 com um membro de espelho adicional é sempre melhor do que RAID 1 com um “hot spare”. Portanto, qualquer que seja o nível de RAID com hot spare que você decida adotar, simplesmente suba um nível na confiabilidade do RAID e descarte o “hot spare” para maximizar tanto o desempenho quanto a confiabilidade por um custo igual ou quase igual.

Os warm spares, assim como o RAID de paridade, tiveram seu momento de glória. De fato, foi quando o RAID de paridade ainda fazia sentido para uso generalizado – quando os erros de URE eram improváveis e os custos de disco eram altos – que as unidades warm spare também faziam sentido. Eles formavam um bom par: quando um fazia sentido, o outro frequentemente também fazia. O que costuma passar despercebido é que, à medida que o RAID de paridade, especialmente o RAID 5, perdeu eficácia, ele arrastou o warm spare consigo de maneiras inesperadas.