Storage all-flash elimina completamente os discos mecânicos — 100% SSD ou NVMe, sem partes móveis, sem latência de seek. Para os workloads certos, é a única arquitetura que entrega o desempenho exigido. Para os workloads errados, é dinheiro desperdiçado. Este artigo explica como separar um caso do outro.
O que mudou no cálculo de custo dos últimos cinco anos
Há dez anos, all-flash era sinônimo de orçamento estratosférico. Um array all-flash da Pure Storage ou da EMC XtremIO custava o dobro ou triplo de um array híbrido equivalente em capacidade. Era justificável apenas para workloads absolutamente críticos.
Esse cálculo mudou. O preço por GB de SSD SATA caiu de forma expressiva — em 2019, um SSD de 1,92 TB custava o equivalente a hoje custar menos da metade em termos reais. A popularização do NAND TLC e QLC para uso corporativo e o aumento de escala de produção tornaram o SSD acessível para uma faixa muito mais ampla de workloads. Hoje, a pergunta já não é “all-flash é viável?” mas sim “para quais workloads all-flash tem melhor TCO que híbrido?”
Na prática, para muitos cenários de banco de dados e virtualização de médio porte, o all-flash tem TCO comparável ou até inferior ao híbrido quando você considera: menor footprint físico (mais capacidade por U de rack), menor consumo elétrico (sem motores girando), menor custo de resfriamento, e — o ponto que geralmente é ignorado — redução de incidentes de performance que consomem horas de trabalho de equipe técnica.
Os casos de uso onde all-flash é necessário, não opcional
Bancos de dados OLTP de alta transação são o caso mais claro. Imagine um sistema de processamento de pagamentos que precisa registrar milhares de transações por segundo, com consistência garantida (ACID) e tempo de resposta abaixo de 5 ms do ponto de vista da aplicação. Um array híbrido pode lidar com a média de carga, mas no pico de transações — fim de mês, promoções, eventos — os discos mecânicos saturam. A latência explode. As filas de I/O crescem. O sistema trava ou degrada.
All-flash entrega IOPS consistentes no pico e fora do pico — não há latência variável causada por seek de disco mecânico. Um Oracle RAC, SQL Server Always On ou PostgreSQL de produção crítica em all-flash tem comportamento muito mais previsível que em híbrido.
VDI é o segundo caso clássico. Um ambiente de 500 desktops virtuais no boot storm matutino — 400 usuários logando entre 8h e 9h — gera um I/O randômico intenso e simultâneo que um array híbrido não consegue absorver sem degradação perceptível. All-flash resolve o boot storm com IOPS suficientes para todos os usuários.
Analytics em tempo real — dashboards de BI sobre dados recentes, detecção de fraudes, sistemas de recomendação em produção — precisa de respostas em milissegundos. Cada camada do stack que adiciona latência tem impacto no tempo de resposta da aplicação. All-flash no storage elimina a camada mais variável.
Híbrido ainda faz sentido — para os workloads certos
O storage híbrido combina SSDs (como tier de cache ou tier de alta performance) com HDDs (como tier de capacidade). O controller do array move dados frequentemente acessados para SSD e dados frios para HDD de forma automática.
Imagine um sistema de arquivo com 200 TB de dados, sendo que apenas 10% são acessados regularmente. All-flash aqui seria armazenar 200 TB em SSD, pagando o custo full SSD por 180 TB de dados frios que nunca são lidos. O híbrido certo coloca esses 10% ativos em SSD e os 90% frios em HDD — você paga custo SSD para 20 TB e custo HDD para 180 TB.
Backup e replicação primária têm padrão de acesso sequencial e não são latência-sensíveis. HDD entrega o throughput necessário para um backup de 10 TB/hora. All-flash aqui não adiciona valor perceptível ao usuário final ou ao SLA.
Arquivamento de longo prazo — compliance, dados históricos, laudos médicos antigos — é o caso mais extremo para capacidade barata. HDD de alta densidade, ou mesmo fita, entrega o custo por GB mais baixo possível para dados que são raramente acessados.
Como avaliar um storage all-flash — as métricas que importam
O problema real aqui é que a maioria dos fabricantes apresenta os números de pico — o máximo teórico atingido em condições ideais num laboratório. Esses números não são o que você vai ver em produção com seu mix de workload.
Quando você avalia um array all-flash, as perguntas certas são: qual é a latência de leitura no percentil 99 (p99) sob carga real — não a média? IOPS garantido no SLA do contrato de suporte, não o pico do datasheet? Qual é a degradação de performance durante rebuild de disco (quando um SSD falha e o array está reconstruindo)?
Latência p99 é a métrica mais honesta. Média de latência pode ser baixa mesmo com picos ruins que afetam usuários. Se o array anuncia “latência média de 200 µs” mas o p99 é 5 ms, 1% das operações leva 25x mais — o suficiente para causar timeouts em aplicações sensíveis.
Densidade também importa para TCO. Um all-flash com maior capacidade por U de rack reduz o espaço no datacenter, o consumo elétrico e o custo de refrigeração. Arrays com maior densidade NVMe por U tendem a ter TCO melhor em espaços limitados.
Por fim, verifique a política de software de valor agregado. Deduplicação, compressão, snapshots, replicação e tiering automático — esses recursos costumam ser incluídos nos arrays modernos, mas em alguns fabricantes são licenciamentos adicionais. O preço do array sem essas funcionalidades pode parecer atraente e esconder o custo real.
Precisa avaliar se all-flash é o caminho certo para o seu ambiente? Os arquitetos da Adentro fazem análise de workload com base nos dados reais do seu ambiente — IOPS, latência e padrão de acesso — antes de qualquer recomendação.