Medida de capacidade em sistemas de armazenamento e processamento
A maioria dos projetos que lida com infraestrutura precisa entender o que é medida de capacidade de forma prática, e não apenas na teoria dos manuais. Falo disso porque passei semanas corrigindo um problema grave num projeto de virtualização onde a medição estava errada desde o início, e isso custou tempo e dinheiro. A capacidade, no sentido técnico, é a quantidade máxima de dados, trabalho ou recursos que um sistema consegue acomodar sem degradar o desempenho. Diferente do que muita gente pensa, capacidade não é sinônimo de espaço disponível. Você pode ter terabytes livres numa estrutura e ainda assim não conseguir processar mais uma única requisição porque o gargalo está em outro lugar.
o que é medida de capacidade e por que ela é confusa
Quando você entra no campo da medição propriamente dita, encontra duas abordagens que precisam coexistir. Uma é a medição bruta, que simplesmente soma tudo o que foi alocado. A outra é a medição efetiva, que considera o overhead, a fragmentação e o espaço que o sistema operacional e os serviços de fundo consomem sem avisar. O primeiro equívoco que vejo todo mundo cometer é tratar a capacidade teórica como se fosse a capacidade real. Num servidor com 1 TB de disco, por exemplo, o sistema operacional e as partições de recuperação já consomem algo em torno de 50 a 80 GB antes de você guardar qualquer dado útil. Isso não é um erro, é a realidade da arquitetura.
No meu caso, o problema chegou num cluster de armazenamento onde estávamos medindo a capacidade apenas pelo total alocado nas LUNs. O resultado foi uma falha em cascata porque ninguém estava levando em conta o overhead dos snapshots incrementais. Cada snapshot tinha um footprint de metadados que, somado a todos os volumes, consumia mais de 12% da capacidade total de forma silenciosa. O sistema começou a falhar em operações de escrita porque não havia espaço livre suficiente para atualizar os blocos alterados, mesmo com 40% do volume aparentemente disponível. A solução foi implementar um monitoramento que separava claramente a capacidade alocada, a capacidade usada pelos dados do usuário e a capacidade consumida por snapshots, clones e metadados. Começamos a trabalhar com o conceito de capacidade líquida, que é a diferença entre o total alocado e tudo que não pode ser usado para armazenamento efetivo. Isso reduziu o tempo gasto resolvendo incidentsos de espaço em cerca de 70%, porque o problema era detectado antes de virar urgência.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Existe ainda uma diferença crucial entre medição de capacidade de armazenamento e medição de capacidade computacional. No primeiro caso, você olha para bytes, gigabytes, terabytes. No segundo, você olha para ciclos, throughput, latência e IOPS. Misturar essas duas dimensões é um erro comum em ambientes heterogêneos, onde discos parecem ter espaço mas a CPU não acompanha, ou onde a CPU sobra mas o disco não consegue manter a fila de operações. Outro detalhe que poucos levam em consideração é a fragmentação. A capacidade bruta não muda com a fragmentação, mas a capacidade efetiva sim. Um sistema com alta fragmentação pode ter 200 GB livres em teoria, mas não conseguir alocar um arquivo de 50 GB contíguos porque não há nenhum bloco livre suficientemente grande. Ferramentas de desfragmentação ajudam em discos mecânicos, mas em SSDs o problema é diferente: a-write amplification reduz a vida útil quando o espaço livre é insuficiente para distribuir as gravações.
Se você trabalha com containers, a coisa fica ainda mais interessante. O Docker, por exemplo, por padrão compartilha o espaço de disco do host inteiro. Isso significa que um container pode consumir todo o espaço disponível se não houver limites de capacidade configurados. A prática recomendada é sempre definir um tamanho máximo para cada volume montado nos containers, e usar cgroup para limitar o uso de disco por processo. Sem isso, um único serviço mal configurado pode derrubar todo o hospedeiro. Em nuvem, a medição de capacidade segue a mesma lógica, mas com uma camada extra de complexidade porque você precisa pensar em capacidade provisionada versus capacidade consumida. Um EBS volume de 500 GB na AWS te cobra pelos 500 GB, independentemente de você usar 10 GB ou 490 GB. Já um filesystem em NFS compartilhado ou um objeto S3 te cobra pelo que realmente usa. Conheço equipes que deixaram volumes EBS subutilizados por anos sem perceber, simplesmente porque a mensalidade era previsível e ninguém questionava.
Quando a conversa é sobre capacidade de rede, o termo muda completamente de significado. Aqui, capacidade se refere à largura de banda disponível, não ao volume de dados. Um link de 1 Gbps tem uma capacidade de transmissão, mas isso não diz nada sobre quanta informação você consegue mover de fato. A latência, a perda de pacotes e a conformação de tráfego podem reduzir drasticamente a capacidade efetiva. Um link contratado com 1 Gbps, por exemplo, pode entregar apenas 600 Mbps de throughput real se o equipamento de borda estiver configurado com politicas de shaping agressivas. O que posso afirmar com segurança é que nenhuma medição de capacidade funciona bem sem contexto. Declarar que um sistema tem capacidade de 1 TB é informação inútil se você não saber se isso inclui snapshots, metadados, espaço reservado para o sistema de arquivos e margem de segurança. A pergunta correta não é quantos terabytes existem, mas quantos terabytes são utilizáveis para o fim específico que você definiu.
Para quem quer começar a medir capacidade de forma mais precisa, o primeiro passo é estabelecer uma política de medição documentada. Isso significa definir o que conta como capacidade utilizada, o que conta como overhead e qual margem de segurança mínima deve ser mantida. Sem esses três elementos, qualquer número que você ver no painel é apenas entretenimento.
