Quando Nenhuma Redundância É Mais Confiável – O Mito da Redundância

Risco é um conceito difícil e exige muito treinamento, reflexão e análise para avaliar adequadamente determinados cenários. Muitas vezes, por serem as avaliações de risco tão difíceis, substituímos a análise de risco simplesmente adicionando redundância básica e presumindo que mitigamos o risco de forma apropriada. Mas, muito frequentemente, não é esse o caso. A introdução de complexidade ou de modos de falha adicionais frequentemente acompanha a adição de redundância, e essas novas formas de falha têm o potencial de acrescentar mais risco do que a redundância adicionada remove. Os sistemas de armazenamento são especialmente propensos a esses processos de decisão, o que é lamentável, já que poucos sistemas, se é que algum, são tão suscetíveis a falhas e tão importantes de proteger.

O RAID é um ótimo exemplo de onde a falta de um pensamento holístico sobre risco pode levar a algumas decisões estranhas. Se observarmos um cenário não incomum, veremos onde o objetivo de proteger contra a falha de uma unidade pode, na verdade, levar a um aumento de risco, mesmo quando redundância adicional é aplicada. Nesse cenário, vamos comparar um array de doze unidades composto por doze discos rígidos SATA de três terabytes em um único array. Não é incomum ouvir falar de pessoas escolhendo RAID 5 para esse cenário para obter “capacidade e desempenho máximos” enquanto têm “proteção adequada contra falhas”.

A ideia aqui é que o RAID 5 protege contra a perda de uma única unidade, que pode ser substituída, e o array se reconstruirá antes que uma segunda unidade falhe. Isso é ótimo em teoria, mas os riscos reais de um array desse tamanho, trinta e seis terabytes de capacidade de unidade, não vêm de múltiplas falhas de unidade, como as pessoas geralmente suspeitam, mas da incapacidade de reconstruir o array de forma confiável após a falha de uma única unidade, ou de uma falha do próprio array sem que nenhuma unidade individual falhe. O risco de uma segunda unidade falhar é baixo, não inexistente, mas bastante baixo. As unidades hoje são altamente confiáveis. Uma vez que uma unidade falha, isso de fato aumenta a probabilidade de uma segunda unidade falhar, o que está bem documentado, mas não quero que esse risco nos desvie de olhar para os verdadeiros riscos – o risco de uma operação de resilver malsucedida.

O que acontece e nos assusta durante uma operação de resilver de RAID 5 é que um erro de leitura irrecuperável (URE) pode ocorrer. Quando isso acontece, a operação de resilver é interrompida e o array fica em um estado inútil – todos os dados do array são perdidos. Em discos SATA comuns, a taxa de URE é de 10^14, ou uma vez a cada doze terabytes de operações de leitura. Isso significa que um array de seis terabytes sendo reconstruído tem aproximadamente cinquenta por cento de chance de encontrar um URE e falhar. Cinquenta por cento de chance de falha é insanamente alto. Imagine se o seu carro tivesse cinquenta por cento de chance de as rodas caírem toda vez que você dirigisse. Então, com um pequeno (para os padrões atuais) array RAID 5 de seis terabytes usando discos SATA com URE de 10^14, se perdêssemos uma única unidade, teríamos apenas cinquenta por cento de chance de o array se recuperar, presumindo que a unidade seja substituída imediatamente. Isso não inclui o risco de uma segunda unidade falhar, apenas o risco de uma falha por URE. Também presume que a unidade esteja completamente ociosa, à exceção da operação de resilver. Se as unidades estiverem ocupadas sendo usadas para outras tarefas ao mesmo tempo, então as chances de algo ruim acontecer, seja um URE ou a falha de uma segunda unidade, começam a aumentar dramaticamente.

Com um array de doze terabytes, as chances de perda total de dados durante uma operação de resilver começam a se aproximar de cem por cento – o que significa que o RAID 5 não tem funcionalidade alguma nesse caso. Há sempre uma chance de sobrevivência, mas ela é muito baixa. Em seis terabytes, você pode comparar uma operação de resilver a um jogo de roleta russa com uma bala e seis câmaras, em que você tem que puxar o gatilho três vezes. Com doze terabytes, você tem que puxá-lo seis vezes! Essas não são boas probabilidades.

Mas não estamos falando de um array de doze terabytes. Estamos falando de um array de trinta e seis terabytes – o que parece grande, mas é um tamanho que alguém poderia facilmente ter em casa hoje, quanto mais em uma empresa. Todos os principais fabricantes de servidores, assim como quase todos os fornecedores de armazenamento de baixo custo, fabricam hoje sistemas de armazenamento de menos de US$ 10.000 nessa faixa de capacidade. Reconstruir um array RAID 5 com a falha de uma única unidade em um array de trinta e seis terabytes é como jogar roleta russa, uma bala, seis câmaras e puxar o gatilho dezoito vezes! Seus dados não têm muita chance. Acrescente a isso a quantidade incrível de tempo necessária para reconstruir um array desse tamanho e o risco de um segundo disco falhar durante essa janela de resilver começa a se tornar uma ameaça bastante significativa. Já vi estimativas de tempos de resilver chegando a semanas ou meses em alguns sistemas. Isso é muito tempo para operar sem poder perder outra unidade. Quando estamos falando de horas ou dias, os riscos são bem baixos, mas ainda presentes. Quando estamos falando de semanas ou meses de abuso contínuo, já que as operações de resilver são extremamente intensivas para as unidades, as taxas de falha aumentam dramaticamente.

Com um array desse tamanho, podemos efetivamente presumir que a perda de uma única unidade significa a perda do array completo, deixando-nos sem qualquer proteção contra falha de unidade. Agora, se observarmos uma unidade de desempenho igual ou melhor com capacidade igual ou melhor sob RAID 0, que também não tem proteção contra a perda de unidade, precisamos usar apenas onze das mesmas unidades das quais precisávamos de doze para o nosso array RAID 5. O que isso significa é que, em vez de doze discos rígidos, cada um com cerca de três por cento de chance de falha anual, temos apenas onze. Isso por si só torna o nosso array RAID 0 mais confiável, pois há menos unidades para falhar. Não só temos menos unidades, como também não há necessidade de escrever o bloco de paridade nem de pular blocos de paridade durante a leitura, reduzindo, ainda que muito ligeiramente, o desgaste mecânico do array RAID 0 para a mesma utilização, conferindo-lhe uma vantagem adicional muito pequena em confiabilidade. O array RAID 0 de onze unidades será idêntico em capacidade ao array RAID 5 de doze unidades, mas terá throughput e latência ligeiramente melhores. Uma vitória em todos os aspectos. Além da economia de custo por não precisar de uma unidade adicional.

Então, o que vemos aqui é que em arrays grandes (grandes em capacidade, não em número de discos) o RAID 0 na verdade supera o RAID 5 em certos cenários. Ao usar discos SATA comuns, isso acontece em capacidades vivenciadas até mesmo por usuários avançados em casa e por muitas pequenas empresas. Se passarmos para discos SATA corporativos ou discos SAS, então o número de capacidade em que isso ocorre se torna muito alto e não é uma preocupação hoje, mas será daqui a apenas alguns anos, quando as capacidades das unidades ficarem ainda maiores. Mas isso evidencia o quão perigoso é o RAID 5 nos tamanhos que vemos hoje. Todos entendem os riscos incríveis do RAID 0, mas pode ser difícil colocar em perspectiva que os problemas do RAID 5 são tão extremos que ele pode, na verdade, ser menos confiável do que o RAID 0.

O fato de o RAID 5 poder ser menos confiável do que o RAID 0 em um array desse tamanho, com base apenas nas operações de resilver, é apenas o começo. Em um array massivo como este, o tempo de resilver pode ser tão longo e exigir tanto das unidades que a falha de uma segunda unidade começa a se tornar também um risco mensurável. E então há riscos adicionais causados por erros da controladora do array que podem usar algoritmos de resilver para destruir um array inteiro, mesmo quando nenhuma falha de unidade ocorreu. Como o RAID 0 (ou RAID 1 ou RAID 10) não têm algoritmos de resilver, eles não sofrem desse risco adicional. Esses são riscos difíceis de quantificar, mas o que importa é que são riscos adicionais que se acumulam ao usar um sistema mais complexo quando um sistema mais simples, sem a redundância, era mais confiável desde o início.

Agora que estabelecemos que o RAID 5 pode ser menos confiável do que o RAID 0, vou apontar os perigos óbvios do RAID 0. O RAID em geral é usado para mitigar o risco da falha de um único e solitário disco rígido. Todos tememos um único disco simplesmente falhar e todos os dados serem perdidos. O RAID 0, sendo uma grande faixa de unidades sem qualquer forma de redundância, pega o risco de perda de dados da falha de uma única unidade e o multiplica por um número de unidades, em que a falha de qualquer unidade causa a perda total dos dados de todas as unidades. Então, em nosso exemplo de onze discos acima, se qualquer um dos onze discos falhar, tudo é perdido. É evidente perceber o quão dramaticamente mais perigoso isso é do que simplesmente usar um único disco, sozinho.

O que estou tentando apontar aqui é que redundância não significa confiabilidade. Só porque algo é redundante, como o RAID 5, não há garantia alguma de que será sempre mais confiável do que algo que não é redundante.

Minha analogia favorita aqui é olhar para casas em um tornado. Em um cenário, construímos uma casa de tijolo e argamassa. No segundo cenário, construímos duas casas redundantes, feitas de palha (nossos construtores são porcos, aparentemente). Quando o tornado (ou o lobo mau) chega, qual tem maior probabilidade de nos deixar com uma casa de pé? Evidentemente, uma casa de tijolo e argamassa tem algumas vantagens significativas de confiabilidade sobre casas de palha redundantes. A redundância não importou; a confiabilidade é que importou no fim.

A redundância é muitas vezes enganosa porque é fácil de quantificar, mas difícil de qualificar. Redundância é uma questão de preto ou branco: É redundante? Sim ou não. Simples. Confiabilidade não é tão simples. Confiabilidade tem a ver com taxas de falha e probabilidades. Tem a ver com estatística e análise. Como é difícil quantificar a confiabilidade de forma significativa, especialmente ao vender um projeto para o pessoal do negócio, a redundância frequentemente se torna um substituto simples para esse conceito complexo.

O conceito de usar a redundância para desviar questões de confiabilidade também acaba se aplicando a subsistemas de maneiras muito enroladas. Em vez de tornar um “sistema” redundante, tornou-se comum tornar um subsistema altamente confiável e de baixo custo redundante e tratar a redundância do subsistema como se aplicasse ao sistema inteiro. O exemplo mais comum disso são as controladoras RAID em produtos SAN. Em vez de ter um SAN redundante (ou seja, dois SANs), os fabricantes frequentemente tornam redundante aquele componente que não costuma ser redundante em servidores normais e então chamam o SAN de redundante – ou seja, um SAN que contém redundância, o que não é de modo algum a mesma coisa.

Uma boa analogia aqui seria comparar ter carros redundantes, ou seja, dois carros completos e funcionando, com ter um único carro com uma bomba d’água reserva no porta-malas, caso a principal falhe. Claramente, uma bomba d’água reserva não é algo ruim. Mas também é uma quantidade trivial de proteção contra a falha do carro comparada a ter um segundo carro pronto para uso. Em um caso, o sistema inteiro é redundante, incluindo o chassi. No outro, estamos tornando redundante apenas um componente altamente confiável dentro do chassi. Não é nem comparável a ter um pneu reserva que, ao menos, é um componente do carro com maior probabilidade de falha.

Assim como o mito da confiabilidade do RAID 5 e da confiabilidade de sistema/subsistema, as tecnologias de armazenamento compartilhado, como SANs e NAS, frequentemente recebem o mesmo tratamento, especialmente no que diz respeito à virtualização. Há um cenário comum em que um projeto de virtualização é empreendido e as pessoas instintivamente entram em pânico porque um único host de virtualização representa um ponto único de falha onde, se ele falhar, muitos sistemas falharão de uma só vez.

Usar o termo “ponto único de falha” provoca uma sensação de pânico e é um ótimo meio de conduzir uma conversa. Mas um SPOF, como gostamos de chamar, embora seja algo que gostamos de remover quando possível, pode não ser o fim do mundo. Pense em nossa casa de tijolos. Ela é um SPOF. Nossas duas casas de palha não são. No entanto, uma única brisa derruba nossas soluções redundantes mais rápido do que o nosso SPOF confiável. Procurar por SPOFs é uma ótima maneira de encontrar pontos de fragilidade em um sistema, mas não sinta que todo SPOF deva ser tornado redundante em todos os cenários. A maioria das empresas encontrará seu melhor custo-benefício tendo muitos SPOFs em uso. Nosso verdadeiro objetivo é confiabilidade a um custo apropriado; a redundância, como vimos, não é substituta para a confiabilidade, é simplesmente uma ferramenta que podemos usar para alcançar a confiabilidade.

A teoria que muitas pessoas seguem ao virtualizar é que elas pegam seu host de virtualização e dizem “Este host é um SPOF, então preciso ter dois deles e usar recursos de Alta Disponibilidade para permitir failover transparente!” Isso é estimulado pelo principal fornecedor de virtualização, que ganha seu dinheiro, em primeiro lugar, vendendo caros produtos adicionais de HA e, em segundo lugar, por pertencer a um grande fornecedor de armazenamento – de modo que vender armazenamento compartilhado adicional desnecessário ou até perigoso é uma grande vitória monetária para eles e poderia facilmente ser a razão pela qual têm defendido o espaço da virtualização desde o início. Hosts de virtualização redundantes com armazenamento compartilhado parecem ótimos, mas podem ser extremamente equivocados por várias razões.

A primeira razão é que a remoção do SPOF inicial, o host de virtualização, é substituída por um novo SPOF, o armazenamento compartilhado. Isso não realiza nada. Presumindo que estamos usando servidores e armazenamento compartilhado de qualidade comparável, tudo o que fizemos foi mudar onde o risco está, não mudar o tamanho dele. A probabilidade de o sistema de armazenamento falhar é aproximadamente igual à probabilidade de o servidor original falhar. Mas, além de embaralhar o SPOF de um lado para o outro como em um jogo de copos, também fizemos algo muito, muito pior – introduzimos dependências de falha encadeadas ou em cascata.

Em nosso cenário original, tínhamos um único servidor. Se o servidor continuasse funcionando, estávamos bem; se falhasse, não estávamos. Simples. Agora temos dois hosts de virtualização, um único servidor de armazenamento (SAN, NAS, seja o que for) e uma rede conectando-os. Já determinamos que o risco de o armazenamento compartilhado falhar é aproximadamente igual ao nosso risco total de sistema no cenário original. Mas agora temos as dependências adicionais da rede e dos dois nós de virtualização de front-end. Cada um desses componentes é mais confiável do que o frágil armazenamento compartilhado (qualquer coisa com discos mecânicos será frágil), mas o fato de eles serem de menor risco não é a questão; a questão é que os riscos são combinatórios.

Se qualquer um desses três componentes (armazenamento, rede ou os nós de front-end) falhar, então tudo falha. A solução para isso é tornar o armazenamento compartilhado redundante por conta própria e tornar a rede redundante por conta própria. Com trabalho suficiente, podemos superar a fragilidade e o risco que introduzimos ao adicionar armazenamento compartilhado, mas o armazenamento compartilhado por si só não é uma forma de mitigação de risco, e sim um risco em si que precisa ser mitigado. A espiral de complexidade começa, e o custo associado a trazer esse novo sistema ao mesmo patamar de confiabilidade do sistema original, de servidor único, pode ser astronômico.

Agora que temos toda essa redundância, temos mais um risco com que nos preocupar. Gerenciar toda essa redundância, todas essas partes móveis, exige muito mais conhecimento, habilidade e preparação do que gerenciar um servidor único e simples. Passamos de uma solução simples para uma muito complexa. Em minha própria experiência anedótica, os verdadeiros perigos de soluções como esta vêm não da falha do hardware, mas do erro humano. Não só pouco foi feito para evitar que o erro humano faça esse novo sistema falhar, como ainda adicionamos incontáveis pontos onde um humano poderia acidentalmente derrubar o sistema inteiro, redundância e tudo. Eu vi isso em primeira mão; ouvi as histórias de terror. Quanto mais complexo o sistema, mais provável é que um humano quebre acidentalmente tudo.

É fundamental que, como profissionais de TI, demos um passo atrás e olhemos para os sistemas completos e consideremos confiabilidade e risco, e pensemos na redundância simplesmente como uma ferramenta a ser usada na busca pela confiabilidade. A redundância em si não é uma panaceia. Nem a simplicidade. A confiabilidade é um problema complexo de enfrentar. Evitar substituições simplistas é um primeiro passo importante para deixar de encobrir problemas de confiabilidade e passar a enfrentá-los e resolvê-los.