Storage tiering é a prática de distribuir dados automaticamente entre camadas de armazenamento com diferentes características de custo e performance. Dados quentes ficam em NVMe de alta velocidade; dados frios migram para HDD ou object storage barato. O objetivo é ter a performance que os dados ativos precisam, ao custo que os dados inativos justificam.
A lógica econômica por trás do tiering
Imagine uma empresa com 500 TB de dados armazenados. Se você armazenar tudo em NVMe, o custo vai ser muito alto — e desnecessário, porque provavelmente 80% desses dados são acessados raramente ou nunca. Se você armazenar tudo em HDD barato, os 20% de dados quentes vão travar as aplicações com latência alta.
O tiering resolve esse dilema. Ele coloca os dados no tipo de storage mais econômico que ainda atende o requisito de performance. E faz isso automaticamente — monitorando padrões de acesso e movendo dados entre camadas sem intervenção manual.
A lógica de custo é que tiering não elimina o storage mais caro — ele reduz o volume de dados que precisa ficar nele. Se 20% dos dados precisam de NVMe e 80% toleram HDD ou object storage, você paga custo NVMe para 100 TB e custo HDD para 400 TB. A economia relativa ao all-flash pode ser de 60 a 70%.
Os tiers e suas características
Na prática, os sistemas de tiering trabalham com quatro camadas principais, cada uma com uma razão de custo e performance distinta.
O Tier 0 é NVMe — a camada mais rápida e mais cara. Latência abaixo de 100 microssegundos, mais de 1 milhão de IOPS. Reservado para dados que são acessados com altíssima frequência e onde a latência impacta a experiência do usuário ou o resultado do negócio: páginas ativas de banco de dados OLTP, índices de busca em uso, dados de sessão de aplicação.
O Tier 1 é SSD SATA ou SAS — boa performance, custo por GB menor que NVMe. Latência de 500 microssegundos a 2 ms, 50 a 100 mil IOPS. Adequado para dados frequentemente acessados mas que toleram um pouco mais de latência: logs recentes, dados de relatórios acessados com frequência, backups recentes que podem precisar de restore rápido.
O Tier 2 é HDD de alto desempenho (7.200 ou 10.000 RPM) — custo por GB muito menor que SSD, latência na faixa de 5 a 15 ms para acesso randômico. Para dados acessados com frequência baixa: arquivos de usuário com meses de inatividade, backups de semanas anteriores, logs de sistema mais antigos.
O Tier 3 é object storage ou fita — custo por GB muito baixo, latência de dezenas a centenas de milissegundos (ou mais, no caso de fita). Para dados frios: compliance, arquivos históricos, backups de longa retenção, dados que você guarda mas raramente (ou nunca) consulta.
Como o tiering automatizado funciona
O mecanismo central do tiering automatizado é a análise de padrão de acesso. O sistema de storage mantém contadores de acesso por bloco ou por objeto — quantas vezes cada dado foi lido ou escrito em um período (tipicamente dias ou semanas). Com base nesses contadores, o sistema decide onde cada dado deve ficar.
A movimentação acontece de forma transparente para as aplicações. Um bloco de banco de dados que estava no Tier 1 (SSD) e não foi acessado por 30 dias pode ser migrado para o Tier 2 (HDD). Se a aplicação fizer uma leitura desse bloco amanhã, o sistema traz o dado de volta para SSD e o acesso acontece normalmente — a aplicação não sabe que o dado estava em HDD. O tempo de promoção (HDD para SSD) é medido em milissegundos a segundos, não em minutos.
O NetApp FabricPool é um exemplo muito bem implementado disso. Ele monitora o acesso a blocos em volumes ONTAP e move blocos frios automaticamente para object storage (AWS S3, Azure Blob, ou object storage local). Quando esses blocos são acessados, são promovidos de volta ao tier quente. A configuração é por política de “temperatura” do dado — você define depois de quantos dias de inatividade um dado é frio.
O AWS S3 Intelligent-Tiering faz algo similar para object storage: monitora o padrão de acesso por objeto e move automaticamente entre tiers de S3 (Standard, Infrequent Access, Glacier) sem custo de retrieval para os dados movidos automaticamente. Para workloads com padrão de acesso imprevisível, é uma alternativa ao gerenciamento manual de ciclo de vida.
O VMware vSAN tem tiering nativo entre NVMe (como cache tier) e HDD ou SSD (como capacity tier) dentro do mesmo cluster — dados quentes ficam no cache NVMe e dados frios migram para o capacity tier automaticamente.
Quando tiering economiza de verdade — e quando adiciona complexidade desnecessária
Tiering economiza quando o volume total de dados é grande, a distribuição de temperatura é clara (maioria dos dados é realmente fria) e o custo por GB dos tiers é suficientemente diferente para justificar a complexidade. Ambientes com 100 TB ou mais, onde a análise mostra que menos de 30% dos dados são acessados regularmente, são candidatos naturais.
O problema real aqui é implementar tiering em ambientes pequenos ou onde os dados são uniformemente quentes. Se 80% dos seus dados são acessados diariamente, o sistema vai ficar tentando promover dados do tier frio constantemente — criando thrashing de tiering que consume IOPS sem benefício. Se o volume total é de 20 TB, o ganho econômico não justifica a complexidade operacional.
Tiering também não resolve o problema de performance de dados quentes — ele garante que dados quentes ficam no tier certo. Se o seu workload inteiro é I/O intenso e latência-sensível, all-flash sem tiering é mais simples e muitas vezes mais barato em TCO.
Antes de implementar tiering, faça a análise de temperatura dos seus dados. A maioria dos sistemas de storage modernos tem relatórios de calor de dados embutidos — use-os para confirmar que sua distribuição de temperatura justifica o investimento em tiering.
O storage da Adentro oferece tiering automático integrado — dados quentes em NVMe, dados frios em object storage S3, com movimentação transparente e política configurável por workload. Tudo gerenciado nos datacenters Tier III no Brasil.