IOPS significa Input/Output Operations Per Second — quantas operações de leitura e escrita o storage consegue processar por segundo. Quando o workload exige mais IOPS do que o storage entrega, a fila de I/O cresce, a latência explode e as aplicações começam a travar. Entender IOPS é entender por que o sistema está lento antes que ele pare.
IOPS e latência — dois lados da mesma moeda
Imagine um caixa de supermercado. O IOPS é quantos itens ele consegue registrar por minuto. A latência é o tempo que cada item leva para ser processado. Quando chegam mais clientes do que ele consegue atender, a fila cresce — e cada cliente espera mais. O mesmo acontece com storage.
IOPS e latência são complementares: quando o storage está operando abaixo da saturação, a latência é estável e baixa. Quando o volume de operações se aproxima do limite de IOPS do storage, a latência começa a subir exponencialmente — não linearmente. Um storage que entrega 1 ms a 50% de carga pode entregar 50 ms a 95% de carga. Essa não-linearidade pega muitos sistemas de surpresa.
O tamanho do I/O importa tanto quanto o número de operações. IOPS geralmente é medido com blocos de 4 KB ou 8 KB para operações randômicas, ou 128 KB a 1 MB para operações sequenciais. Um storage que faz 1 milhão de IOPS com blocos de 512 bytes faz muito menos IOPS com blocos de 1 MB — o throughput total em MB/s é o produto do IOPS pelo tamanho do bloco, e há um teto físico de largura de banda.
IOPS por tipo de disco — os números reais
Na prática, cada tecnologia de disco tem um teto físico de IOPS que nenhum software resolve por conta própria. Esses são os números que você precisa ter internalizados para qualquer dimensionamento de storage:
Um HDD de 7.200 RPM entrega entre 80 e 150 IOPS de acesso randômico. O limitante físico é o tempo de seek (o cabeçote se movendo até a trilha certa) e o tempo de rotação (esperar o setor girar até o cabeçote). Isso leva de 5 a 10 ms por operação randômica — por isso HDDs são excelentes para leitura sequencial, onde o cabeçote não precisa pular, mas péssimos para I/O randômico de banco de dados.
Um SSD SATA de grau corporativo entrega de 50.000 a 100.000 IOPS randômicos. Não há partes mecânicas — a latência cai para 50 a 500 microssegundos. Um único SSD SATA substituiu dezenas de HDDs em termos de IOPS.
Um NVMe PCIe 4.0 entrega acima de 1.000.000 IOPS (um milhão). A latência de leitura aleatória fica abaixo de 100 microssegundos. Um único NVMe corporativo de alta performance tem mais IOPS do que um array de dezenas de HDDs.
Em um array de storage, o IOPS total é limitado tanto pelos discos individuais quanto pelos controllers, pela rede (no caso de SAN/NAS) e pelo cache. Arrays modernos usam cache NVMe de frente para o array inteiro — isso pode multiplicar o IOPS efetivo para workloads que têm boa proporção de reuso de dados no cache.
Como estimar o IOPS necessário para o seu workload
O problema real aqui é que a maioria das empresas especifica storage sem ter dados de IOPS do workload real. Resultado: ou o storage é superdimensionado (caro demais) ou subdimensionado (não aguenta o crescimento).
Para bancos de dados OLTP, a regra de estimativa é: a cada 100 usuários simultâneos ativos, conte com 500 a 2.000 IOPS dependendo da complexidade das operações. Um sistema de CRM com 500 usuários simultâneos pode precisar de 5.000 a 10.000 IOPS. Um ERP com processamento pesado pode chegar a 50.000 IOPS para o mesmo número de usuários.
Para ambientes VMware, a estimativa padrão é de 10 a 50 IOPS por VM, dependendo do tipo de workload das VMs. VMs de desktop (VDI) ficam na faixa de 10 a 30 IOPS em média, mas podem disparar para 200+ IOPS no boot storm. VMs com bancos de dados ficam na faixa de 500 a 5.000 IOPS.
A forma mais confiável de dimensionar é medir o ambiente atual antes de migrar. No Linux, o iostat com intervalo de 1 segundo captura o IOPS por dispositivo em tempo real. No Windows, o Performance Monitor com contadores de disco. Em ambientes VMware, o vCenter Performance apresenta IOPS por datastore e por VM historicamente.
Com os dados históricos, dimensione o storage novo para acomodar o pico medido com 30 a 50% de headroom — não o pico absoluto máximo, mas o pico sustentado por períodos que importam para a aplicação.
O que acontece quando você satura o IOPS
Imagine um sistema de ERP em produção no fechamento do mês. O volume de operações de banco de dados triplica. A fila de I/O começa a crescer. A latência de storage, que era de 1 ms em condições normais, vai para 20, 50, 200 ms. O banco de dados começa a ter lock waits. As transações demoram mais. Os usuários reportam lentidão. O sistema de monitoramento começa a disparar alertas de timeout.
Esse cenário é exatamente o que acontece quando o storage está operando próximo do limite de IOPS sob carga de pico. O sistema não para — degrada. E a degradação é não-linear: de 80% para 95% de saturação, a latência pode multiplicar por 10.
A solução não é sempre trocar o storage. Às vezes é ajustar o workload: separar o banco de dados OLTP (I/O intenso) do banco de reporting (leitura pesada); tirar o processo de backup da janela que coincide com o pico de transações; adicionar cache na aplicação para reduzir as consultas ao banco. Essas medidas podem reduzir o IOPS efetivo sem trocar hardware.
Como monitorar IOPS em produção
A regra é: não espere os usuários reclamarem para medir IOPS. Storage que está indo a 90% de saturação parece normal nos relatórios até o momento em que cruza o limiar e a latência explode.
No Linux, o iostat -x 1 mostra utilização, IOPS de leitura e escrita, throughput e await (latência médio de I/O em ms) por dispositivo a cada segundo. O campo await é o mais importante: valores acima de 5 ms para SSD indicam saturação.
No VMware, o vCenter apresenta latência de storage por datastore e por VM no histórico de performance. Configure alertas para latência de datastore acima de 10 ms — isso é o sinal de alerta antes da crise.
Ferramentas como Grafana com Prometheus e exporters de storage permitem dashboards históricos de IOPS e latência, indispensáveis para identificar tendências de crescimento antes de atingir o limite.
Precisa dimensionar storage com IOPS correto para o seu workload? A Adentro faz análise de perfil de I/O antes de qualquer proposta — os datacenters Tier III em Osasco, Vinhedo e Porto Alegre operam storage com IOPS garantido por SLA.