Thin provisioning aloca espaço de storage sob demanda — a VM usa só o que precisa agora, não o que você declarou que ela poderia usar. Thick provisioning reserva todo o espaço configurado imediatamente, na criação do disco. A escolha afeta utilização de storage, performance e — se você não tiver cuidado — pode criar crises silenciosas num ambiente thin.
O problema que thin provisioning resolve
Imagine que você cria 50 VMs com discos de 100 GB cada. Num ambiente thick provisioning, você precisa de 5 TB de storage disponível antes de criar a primeira VM, porque cada disco reserva seus 100 GB imediatamente — independente de quanto a VM vai realmente usar.
Na prática, no primeiro mês de vida, essas 50 VMs provavelmente usam em média 20 GB cada. Com thick provisioning, você reservou 5 TB mas usou efetivamente 1 TB. 4 TB ficaram reservados mas vazios — e você pagou por esse storage (em hardware, licenças de SAN ou assinatura de cloud).
Thin provisioning inverte a lógica: você cria os 50 discos de 100 GB, mas o sistema só aloca espaço físico conforme as VMs realmente escrevem dados. Se cada VM usa 20 GB, você só consome 1 TB de storage físico. O storage parece ter 5 TB de capacidade para as VMs, mas o pool físico pode ter muito menos — porque a suposição é que as VMs não vão usar tudo ao mesmo tempo.
Isso é overcommit — você está prometendo mais storage do que realmente existe. É aqui que está tanto o benefício quanto o risco central do thin provisioning.
Como thin provisioning funciona na prática
Quando você cria um disco thin provisioned de 100 GB e formata com um sistema de arquivos, a VM vê um disco de 100 GB. Mas no storage físico, inicialmente quase nada foi alocado — apenas os metadados.
Conforme a VM escreve dados, o storage aloca blocos físicos para acomodar as escritas. Esses blocos crescem em incrementos (chamados de chunks ou extents, dependendo da plataforma de storage) conforme necessário. Se a VM escreve 30 GB, 30 GB de storage físico são alocados. O disco continua aparecendo como 100 GB para a VM, mas só 30 GB existem de verdade.
Se você deletar arquivos dentro da VM, isso não necessariamente libera o espaço no storage. O sistema de arquivos da VM marca os blocos como livres, mas o storage físico não sabe disso — os blocos alocados permanecem alocados. Para recuperar espaço de blocos deletados em discos thin provisioned, você precisa executar processos como TRIM (para SSDs) ou balloon drivers que comunicam ao hypervisor quais blocos estão livres.
Thick provisioning — eager zeroed vs lazy zeroed
Quando você usa thick provisioning, existe ainda uma subdivisão importante no VMware (e em sistemas similares):
Thick Lazy Zeroed (ou lazy thick): O espaço total é reservado imediatamente, mas os blocos não são zerados na criação. Quando a VM escreve num bloco pela primeira vez, o sistema precisa zerá-lo antes de escrever — o que introduz overhead de performance na primeira escrita. A criação é rápida porque não precisa zerar tudo.
Thick Eager Zeroed: O espaço é reservado E zerado completamente na criação. Demora mais para criar, mas as escritas subsequentes não têm overhead de zeroing — o bloco já está limpo e pronto. Para workloads de banco de dados e aplicações com I/O intenso onde performance previsível é crítica, eager zeroed é a escolha correta.
No KVM e em outros sistemas, a terminologia varia, mas o conceito é o mesmo: raw ou prealloc completo equivale ao eager zeroed; qcow2 com preallocation=metadata é similar ao thin.
Vantagens do thin — e quando ele ganha
O argumento do thin provisioning é mais forte em cenários onde:
A taxa de crescimento real é lenta e previsível. Se você sabe que suas VMs crescem em média 10% ao ano e você monitora o uso de perto, o thin permite extrair muito mais capacidade do mesmo pool de storage físico.
Você está criando muitas VMs parecidas a partir de templates. Em ambientes de VDI não-persistente ou desenvolvimento onde dezenas de VMs são criadas do mesmo template, thin provisioning é quase mandatório. Alocar 50 GB de storage para cada instância de uma VM que vai usar 5 GB e ser destruída em horas seria desperdício puro.
O custo de storage é o limitante principal. Quando você está numa fase de crescimento e não pode comprar mais storage agora, thin provisioning com monitoramento cuidadoso permite usar o que você tem de forma mais eficiente.
Vantagens do thick — e quando ele é a escolha certa
Thick provisioning ganha onde performance e previsibilidade são prioritárias:
Bancos de dados e aplicações transacionais. Um PostgreSQL, Oracle ou SQL Server precisa de latência de I/O consistente e previsível. Com thin provisioning, a alocação de novos blocos pode introduzir picos de latência no momento da escrita. Com thick eager zeroed, todos os blocos já estão pré-alocados e zerados — a latência de escrita é consistente.
Ambientes de compliance que exigem isolamento de storage. Em certos requisitos de segurança, a possibilidade teórica de dados de um tenant vazar para outro via blocos reutilizados de thin provisioning é um problema. Thick provisioning com eager zeroed garante que os blocos estão limpos antes do uso.
Quando você não tem monitoramento adequado. Isso parece óbvio mas precisa ser dito: se você não tem alertas configurados para o uso de storage e um time que vai agir quando eles dispararem, thin provisioning em ambiente de produção é uma aposta de risco. Thick provisioning é mais conservador para quem não tem maturidade operacional de monitoramento.
O risco real do overcommit — quando o thin vira crise
O risco do thin provisioning merece atenção especial, porque quando ele se materializa, o impacto é sério.
Na prática: você criou 50 VMs thin provisioned com 100 GB cada (capacidade declarada: 5 TB). O pool de storage físico tem 2 TB. As VMs estão usando em média 30 GB cada — total real: 1,5 TB. Tudo bem, você tem 500 GB de folga.
Mas ninguém monitorava de perto. Ao longo dos meses, as VMs foram crescendo. Hoje, a média chegou a 41 GB por VM — total real: 2,05 TB. O pool de storage físico está cheio.
O que acontece quando o storage fica 100% cheio em ambiente thin provisioned? As VMs tentam escrever e não conseguem alocar novos blocos. Sistemas de arquivos começam a dar erros. Bancos de dados podem corromper dados se uma transação for interrompida a meio pela falta de espaço. Aplicações travam.
Evitar isso exige duas coisas: monitoramento com alertas (avisos em 70%, 80% e alertas críticos em 90% de uso do pool físico) e política de overcommit prudente (nunca comprometer mais de 1,5x a capacidade física sem análise cuidadosa do perfil de crescimento).
Como monitorar um ambiente thin provisioned
As plataformas de virtualização expõem métricas de storage em dois níveis que você precisa acompanhar em paralelo:
Espaço declarado (capacity planejada): quanto as VMs acham que têm disponível. Útil para planejamento de capacidade de longo prazo, mas não indica risco imediato.
Espaço alocado real (utilização do pool físico): quanto do storage físico está realmente em uso. Este é o número que importa para evitar crises. Configure alertas nesta métrica, não na capacidade declarada.
Ferramentas como vCenter (para VMware), Proxmox UI, CloudStack, e sistemas de monitoramento como Zabbix, Grafana com Prometheus ou Datadog permitem configurar alertas por threshold de utilização real do pool de storage.
A plataforma ACS da Adentro oferece storage com thin provisioning gerenciado e monitoramento de capacidade incluído no SLA. Fale com um especialista em storage.