Um Único Grande RAID 10 – Um Novo Padrão em Armazenamento de Servidores

No final da década de 1990, a regra prática padrão para construir um novo servidor era colocar o sistema operacional em seu próprio array RAID 1 pequeno e separar aplicações e dados em um array RAID 5 distinto. Isso era feito por várias razões, muitas das quais se dispersaram ao longo do tempo, perdidas nas areias do passado. Os principais fatores determinantes eram que a capacidade de armazenamento era extremamente cara, os discos eram pequenos, os sistemas de arquivos se corrompiam com frequência e os discos rígidos físicos falhavam a uma taxa muito elevada em comparação com outros tipos de falhas. As pessoas eram movidas pela necessidade de se proteger contra falhas físicas de discos rígidos, proteger-se contra a corrupção do sistema de arquivos e adquirir capacidade suficiente para atender às suas necessidades.

Hoje, o panorama do armazenamento mudou. Os sistemas de arquivos são incrivelmente robustos e a corrupção proveniente do próprio sistema de arquivos é praticamente inédita e, graças a tecnologias como o journaling, quase sempre pode ser corrigida de forma rápida e eficaz, protegendo os usuários finais contra a perda de dados. Quase ninguém se preocupa com a corrupção do sistema de arquivos atualmente.

Os sistemas de arquivos modernos também são capazes de lidar com muito mais capacidade do que antes. No final da década de 1990 e início dos anos 2000, não era incomum ter a possibilidade de criar facilmente um array de discos maior do que qualquer sistema de arquivos individual poderia suportar. Hoje, isso já não acontece de forma razoável, pois todos os sistemas de arquivos comuns suportam, no mínimo, muitos terabytes e, frequentemente, petabytes, exabytes ou mais de dados.

Os discos rígidos são muito mais confiáveis do que eram no final da década de 1990. As taxas de falha de um disco inteiro são muito baixas, mesmo em discos menos dispendiosos. Tão baixas, na verdade, que as falhas de array (perda de dados em todo o array RAID) estão relacionadas principalmente com a falha do próprio array, e não com a falha dos discos rígidos. Já não substituímos discos rígidos de forma indiscriminada. Não é raro que grandes arrays funcionem durante todo o seu ciclo de vida sem perder um único disco.

As capacidades aumentaram drasticamente. Em vez de discos rígidos de 4,3 GB, estamos instalando discos de 3 TB. Quase mil vezes mais capacidade em um único eixo em comparação com menos de quinze anos atrás.

Esses fatores se combinam para criar a necessidade de uma abordagem drasticamente diferente para o projeto de armazenamento de servidores e uma mudança na “regra prática” sobre por onde começar ao projetar o armazenamento.

A abordagem antiga pode ser escrita como RAID 1 + RAID 5. O espaço do RAID 1 era usado para o sistema operacional, enquanto o espaço do RAID 5, presumivelmente muito maior, era usado para dados e aplicações. Esse projeto dividia as duas preocupações de armazenamento, colocando o máximo de esforço na proteção do sistema operacional (que era muito difícil de recuperar em caso de desastre e do qual os dados dependiam para sua acessibilidade) em um RAID 1 altamente confiável. O RAID 5, de menor custo, embora um tanto mais arriscado, era escolhido, normalmente, para os dados, porque o custo de armazenar dados em RAID 1 era alto demais na maioria dos casos. Era um compromisso que fazia sentido na época.

Hoje, com nossas preocupações muito diferentes, é necessária uma nova abordagem, e essa nova abordagem é conhecida como “Um Único Grande RAID 10” – ou seja, um único e grande array RAID 10 com sistema operacional, aplicações e dados todos armazenados juntos. Claro, isso é apenas o que dizemos para simplificar; em um sistema sem necessidades de desempenho ou capacidade que excedam as de um único disco, diríamos “Um Único Grande RAID 1”, mas muitas pessoas incluem o RAID 1 no grupo do RAID 10, então é simplesmente mais fácil dizer a primeira opção.

Para ser ainda mais prático, abreviamos isso como OBR10.

Como o custo do armazenamento caiu consideravelmente e, em vez de ser escasso, costuma estar em abundância atualmente, porque os sistemas de arquivos são incrivelmente confiáveis, porque o RAID 1 e o RAID 10 compartilham características de desempenho e porque as falhas de array desencadeadas por causas não relacionadas a discos passaram de ruído de fundo a causas primárias de perda de dados, a migração para o RAID 10 e a eliminação da divisão de arrays tornaram-se a nova abordagem padrão.

Com o RAID 10, agora temos o armazenamento altamente disponível e resiliente, antes reservado apenas para o sistema operacional, disponível para todos os nossos dados. Obtemos o benefício do desempenho do RAID espelhado, além do benefício de eixos adicionais para todos os nossos dados. Obtemos uma melhor utilização da capacidade dos discos e um desempenho baseado nessa utilização aprimorada.

Até mesmo a divisão tradicional de arquivos de log, normalmente feita com bancos de dados (a infame abordagem RAID 1 + RAID 5 + RAID 1), já não é necessária, pois o RAID 10 mantém características de desempenho ótimas em todos os dados. Com o RAID 10, eliminamos quase todos os fatores que antes nos levavam a dividir os arrays.

O único fator significativo, que ainda não foi mencionado, pelo qual a divisão de arrays era tradicionalmente vista como benéfica é a contenção de acesso – a necessidade de diferentes processos acessarem diferentes partes do disco ao mesmo tempo, fazendo com que a cabeça do disco se movimente em um padrão pouco ideal, reduzindo o desempenho do disco. A contenção era um grande problema no final da década de 1990, quando a antiga regra prática foi desenvolvida.

Hoje, a contenção de disco ainda existe, mas foi fortemente mitigada pelo uso de grandes caches de RAID. No final dos anos 90, os caches de disco tinham, no máximo, alguns megabytes e, muitas vezes, eram inexistentes. Hoje, 256 MB é um cache minúsculo, e servidores médios são implantados com 1 a 2 GB de cache apenas na placa RAID. Alguns sistemas estão começando a integrar caches adicionais baseados em discos de estado sólido para adicionar um cache secundário além do cache de memória no controlador. Esses podem facilmente adicionar centenas de gigabytes de cache de altíssima velocidade, capaz de armazenar em buffer praticamente qualquer operação de eixo sem que ela precise se preocupar com a contenção. Assim, a questão da contenção foi resolvida de outras maneiras ao longo dos anos, mas, como outras mudanças tecnológicas, efetivamente nos libertou das preocupações tradicionais que nos obrigavam a dividir os arrays.

Assim como a contenção de array, outra razão, muito menos comum, para dividir arrays no final da década de 1990 era melhorar o desempenho do barramento de comunicação, devido às limitações das tecnologias SCSI e ATA da época. Essas também foram eliminadas com a migração para mecanismos de comunicação serial, SAS e SATA, nos arrays modernos. Já não estamos limitados à capacidade de um único barramento para cada array e podemos crescer muito mais, com muito mais flexibilidade do que antes. A contenção de barramento foi praticamente eliminada.

Se houver necessidade de separar espaço para proteção, como o crescimento de arquivos de log, isso pode ser feito por meio de particionamento, em vez da divisão física do array. Em geral, você vai querer minimizar o particionamento, pois ele aumenta a sobrecarga e reduz a capacidade dos discos de se ajustarem por conta própria, mas há casos em que essa é a melhor abordagem. No entanto, isso não exige que o armazenamento físico subjacente seja dividido, como acontecia tradicionalmente. Ainda melhor do que o particionamento, quando disponível, é o gerenciamento de volumes lógicos, que cria separações semelhantes a partições sem as limitações das partições.

Portanto, no fim das contas, a nova regra prática para o armazenamento de servidores é “Um Único Grande RAID 10”. Nada de RAID 5, nada de divisão de arrays. Trata-se de confiabilidade, desempenho, facilidade de gerenciamento e uma boa relação custo-benefício. Como todas as regras práticas, esta não se aplica a todos os casos individualmente, mas se aplica de forma muito mais ampla do que o antigo padrão jamais se aplicou. O RAID 1 + RAID 5, como padrão, sempre foi uma tentativa de “se virar” com algo indesejável e de tirar o melhor proveito de uma situação ruim. O OBR10 não é assim. O novo padrão é um padrão desejado – é como realmente queremos operar, e não algo com que ficamos “presos”.

Ao projetar o armazenamento para um novo servidor, comece com o OBR10 e só o abandone quando ele especificamente não atender às suas necessidades tecnológicas. Você nunca deveria ter de justificar o uso do OBR10, apenas justificar o fato de não usá-lo.