Uma VM que recebe 500 GB de disco não exige necessariamente 500 GB físicos no storage. Da mesma forma, uma base de dados com 2 TB pode demandar muito mais capacidade útil quando há cópias, snapshots, logs, retenção e crescimento projetado. Entender como calcular capacidade storage evita dois problemas caros para o data center: comprar uma solução subdimensionada ou imobilizar orçamento em capacidade que não será usada.
O dimensionamento correto não começa pela soma do espaço dos arquivos atuais. Ele começa pela identificação das cargas de trabalho, do padrão de crescimento, da tecnologia de proteção de dados e do nível de disponibilidade esperado. Em ambientes enterprise, capacidade, performance e resiliência são decisões interdependentes.
Como calcular capacidade de storage na prática
A conta inicial é simples: levante o volume de dados produtivos, aplique a projeção de crescimento e adicione os requisitos operacionais. O resultado, porém, precisa ser convertido de capacidade lógica para capacidade útil e, por fim, para capacidade bruta de discos.
Uma fórmula inicial pode ser apresentada assim:
Capacidade necessária = dados atuais x crescimento projetado + cópias operacionais + reserva técnica
Suponha um ambiente com 20 TB de dados produtivos e crescimento anual de 25%. Para um horizonte de três anos, o cálculo composto é mais apropriado que uma margem fixa:
20 TB x 1,25³ = 39,06 TB
Esse é apenas o volume produtivo previsto ao fim do período. Se o ambiente mantém uma cópia local para restauração rápida, snapshots frequentes e uma reserva de 20% para operação, os 39 TB podem ultrapassar 70 TB de capacidade útil necessária. A capacidade bruta dependerá do RAID, da tecnologia de deduplicação, compressão e do layout escolhido.
Diferencie capacidade bruta, útil e lógica
Capacidade bruta é a soma nominal de todos os discos instalados. Um shelf com doze discos de 12 TB entrega 144 TB brutos. Esse número não representa o espaço disponível para aplicações.
Capacidade útil é o espaço após a proteção RAID ou esquemas equivalentes de tolerância a falhas. Em um grupo RAID 6, por exemplo, o equivalente à capacidade de dois discos é destinado à paridade. Com doze unidades de 12 TB, a referência simplificada seria 10 x 12 TB, ou 120 TB úteis antes de outras reservas do sistema.
Já a capacidade lógica é o volume apresentado aos hosts, clusters de virtualização ou aplicativos. Thin provisioning permite apresentar, por exemplo, 100 TB lógicos mesmo quando o pool físico tem menos espaço. É eficiente, mas exige monitoramento rigoroso: a economia inicial não elimina a necessidade de expansão antes que o pool atinja níveis críticos.
Também convém padronizar as unidades. Fabricantes de discos normalmente informam TB em base decimal, enquanto sistemas operacionais podem exibir TiB em base binária. Um disco de 12 TB aparece próximo de 10,9 TiB. Em projetos com dezenas de discos, essa diferença precisa constar na memória de cálculo.
O RAID altera a capacidade disponível
RAID não é somente uma escolha de proteção. Ele define quanto da capacidade bruta será convertida em espaço utilizável e influencia diretamente a reconstrução de discos, o desempenho de escrita e a disponibilidade do conjunto.
RAID 10 usa espelhamento e distribuição de dados. Na prática, cerca de 50% da capacidade bruta fica disponível, mas o arranjo tende a oferecer boa latência e alta performance para bancos de dados transacionais, virtualização intensa e cargas com muitas gravações aleatórias.
RAID 5 consome o equivalente a um disco para paridade. Pode aproveitar melhor a capacidade em grupos menores, mas requer análise criteriosa em discos de grande capacidade, pois a reconstrução após uma falha pode ser longa e gerar pressão adicional sobre o array.
RAID 6 reserva o equivalente a dois discos para paridade e suporta a falha simultânea de duas unidades no mesmo grupo. É uma escolha recorrente quando o objetivo é equilibrar capacidade e proteção em pools com HDDs SAS ou NL-SAS de maior capacidade. O custo é maior overhead de escrita e menor capacidade útil comparada ao RAID 5.
Em storages corporativos, os mecanismos podem variar conforme o fabricante e a plataforma. Alguns arrays trabalham com proteção distribuída, erasure coding ou pools dinâmicos, sem a estrutura clássica de grupos RAID fixos. A regra permanece: use a eficiência real informada para o modelo e para a configuração pretendida, não uma estimativa genérica.
Inclua snapshots, cópias e retenção no cálculo
Snapshots não ocupam necessariamente o tamanho completo do volume no momento da criação. Eles registram blocos alterados depois do ponto de restauração. Ainda assim, em ambientes com alta taxa de mudança, seu consumo pode crescer rapidamente.
Uma VM de 2 TB com snapshot diário e retenção de sete dias não exige automaticamente 14 TB extras. Se 10% dos blocos mudam por dia, a referência inicial seria 1,4 TB adicional. Mas essa taxa muda conforme o perfil da carga: servidores de arquivo, bancos de dados, repositórios de e-mail e ambientes de desenvolvimento apresentam comportamentos muito diferentes.
O mesmo vale para cópias locais. Caso a política determine uma réplica interna ou clones para homologação, dimensione cada finalidade separadamente. Deduplicação e compressão podem reduzir o consumo, especialmente em VDI, máquinas virtuais semelhantes e sistemas com dados repetitivos. Por outro lado, dados criptografados, arquivos de mídia e backups já comprimidos costumam gerar pouca ou nenhuma redução. Não use taxas de redução otimistas como garantia de capacidade.
Capacidade sem IOPS pode ser um erro de projeto
Dois arrays com a mesma capacidade útil podem atender cenários completamente distintos. Um conjunto de discos nearline de alta capacidade é adequado para retenção, arquivos e dados com acesso menos frequente. Já um cluster de virtualização com centenas de VMs pode precisar de SSD SAS, SSD NVMe ou camadas híbridas, mesmo que o volume total seja relativamente pequeno.
Ao calcular o storage, associe o volume a métricas de performance: IOPS de leitura e escrita, tamanho médio de bloco, latência aceitável, throughput e padrão de acesso aleatório ou sequencial. Um banco de dados OLTP, por exemplo, costuma priorizar baixa latência e escrita consistente. Um repositório de vídeo depende mais de throughput sequencial.
A arquitetura também muda o resultado. Em uma SAN Fibre Channel ou iSCSI, avalie as portas disponíveis, a velocidade dos links, HBAs, switches e a redundância dos caminhos. Para NAS, considere protocolos, número de usuários, concorrência e comportamento dos arquivos. Não adianta calcular corretamente os TB se a controladora, a rede ou a camada de discos se tornar o gargalo.
Defina uma margem operacional realista
Storage não deve operar próximo de 100% de ocupação. Pools excessivamente cheios podem sofrer degradação de performance, limitações para snapshots e dificuldade para redistribuir dados durante a troca de uma unidade ou expansão.
A margem recomendada depende da plataforma e da carga, mas reservar entre 15% e 30% da capacidade útil costuma ser uma referência prudente. Arrays all-flash com mecanismos internos de garbage collection, wear leveling e proteção de dados podem exigir uma faixa ainda mais conservadora, conforme a orientação do fabricante.
Também planeje a expansão em blocos coerentes. Um storage pode aceitar discos adicionais, gavetas de expansão ou nós extras, mas cada caminho possui regras de compatibilidade, quantidade mínima de discos, versões de firmware e limites de controladora. Misturar SSDs, SAS e SATA sem observar os pools homologados pode comprometer previsibilidade e suporte do fabricante.
Exemplo de dimensionamento para virtualização
Considere uma empresa com 80 VMs que ocupam atualmente 18 TB, crescimento anual previsto de 20% e planejamento de três anos. O volume produtivo projetado será aproximadamente 31,1 TB.
A empresa mantém snapshots com consumo estimado de 15% do volume produtivo, o que adiciona 4,7 TB. Há ainda 6 TB para clones de homologação e uma margem operacional de 25% sobre o subtotal. A necessidade útil fica próxima de 52 TB:
31,1 TB + 4,7 TB + 6 TB = 41,8 TB
41,8 TB x 1,25 = 52,25 TB úteis
Se a solução usar RAID 6 com grupos de dez discos de 12 TB, cada grupo entrega aproximadamente 96 TB úteis na conta simplificada, pois oito discos ficam disponíveis para dados. Há capacidade suficiente, mas essa não é a decisão final. É preciso verificar se essa composição entrega os IOPS requeridos pelas 80 VMs. Se não entregar, pode ser necessário usar mais discos menores, SSDs ou uma arquitetura híbrida, mesmo que a capacidade total pareça excedente.
Informações que devem entrar na cotação
Uma cotação técnica consistente deve informar volume atual, crescimento esperado, período de planejamento, tipo de aplicação, requisitos de IOPS e latência, retenção de snapshots, política de cópias, protocolo de acesso e necessidade de expansão. Também é relevante informar se o ambiente usa VMware, Hyper-V, Windows Server, Linux, bancos de dados ou aplicações proprietárias, pois essas variáveis definem o perfil de leitura e gravação.
Com esses dados, é possível comparar opções com discos SAS, SATA, SSD e NVMe, além de controladoras, HBAs e conectividade Fibre Channel ou Ethernet. A I.T. Computers apoia cotações de infraestrutura enterprise com configurações alinhadas a servidores HPE ProLiant, Dell PowerEdge e Lenovo ThinkSystem, storages e componentes compatíveis.
O melhor dimensionamento não é o que entrega mais terabytes na proposta. É o que mantém espaço disponível, performance previsível e um caminho claro de expansão para que o storage acompanhe o ritmo do negócio sem transformar cada novo projeto em uma urgência.