Perfis de IO: a guerra invisível entre DB, VDI e Backup no seu storage

Você pode comprar o array All-Flash mais caro do mercado, encher de NVMe Gen5 e conectar via fibra de 32Gb. Ainda assim, seu banco de dados vai travar se você não entender a física básica de como os dados aterrissam no disco.

O maior erro que vejo em arquiteturas de armazenamento não é a falta de capacidade, é a ignorância sobre o perfil de I/O (Input/Output). Tratamos storage como um balde infinito onde jogamos bits, esquecendo que um banco de dados transacional (OLTP), uma infraestrutura de desktops virtuais (VDI) e um job de backup são inimigos mortais disputando os mesmos recursos físicos.

Quando o telefone toca às 3 da manhã e o banco está lento, a culpa raramente é do código SQL. A culpa é de quem desenhou a infraestrutura achando que IOPS é tudo igual. Não é.

Resumo em 30 segundos

• A Média Mente: Monitorar latência média esconde picos de "latência de cauda" (P99) que travam aplicações sensíveis.
• O Efeito Liquidificador: A virtualização transforma fluxos de escrita sequencial limpos em um caos de I/O aleatório, matando a performance de discos mecânicos e saturando controladoras flash.
• Segregação é Lei: Misturar logs de transação (WAL) com repositórios de backup no mesmo grupo de discos ou namespace é um erro arquitetural primário.

A ilusão da CPU ociosa e o gargalo oculto no iowait

O sintoma clássico de um subsistema de storage mal dimensionado é um servidor de banco de dados com a CPU aparentemente "tranquila", operando a 10% ou 20%, mas com a aplicação completamente travada. O administrador inexperiente olha para o top ou para o monitoramento do vCenter e diz: "Não é recurso de servidor, a CPU está sobrando".

Ele está olhando para a métrica errada.

Em sistemas Linux e Unix-like, o tempo de CPU é dividido. O que você deve buscar é o iowait. O iowait é o tempo que a CPU passa ociosa, não porque não tem trabalho, mas porque está esperando o disco responder. Se você tem 5% de uso de user e 40% de iowait, seu storage é o gargalo.

Para um banco de dados, cada milissegundo em wait é uma transação parada, um lock segurando outras dez conexões e uma cascata de lentidão que derruba o front-end. Diferente de renderização de vídeo, onde o processador trabalha pesado, em bancos de dados o processador é um despachante de luxo: ele solicita o dado e espera. Se o storage demora, o despachante para.

Figura: Legenda: O iowait alto indica que a CPU está "congelada" aguardando a resposta do subsistema de armazenamento.

O efeito liquidificador: transformando streams sequenciais em ruído aleatório

Este é o fenômeno que destrói a performance em ambientes virtualizados (VMware, Hyper-V, Proxmox). Imagine que você tem três servidores virtuais:

1. Um servidor de Logs (escrita sequencial).

2. Um servidor de Streaming (leitura sequencial).

3. Um servidor de Banco de Dados (misto).

Se cada um tivesse seu disco físico dedicado, as cabeças de leitura (em HDDs) ou os canais da NAND (em SSDs) operariam de forma otimizada. Porém, na virtualização, todos esses fluxos passam pelo Hypervisor e descem para o mesmo Datastore ou LUN.

O Hypervisor pega esses pacotes de I/O bonitos e organizados e os intercala. O resultado que chega na controladora do storage é o Efeito Liquidificador (I/O Blender Effect): um fluxo completamente aleatório (random), fragmentado e imprevisível.

💡 Dica Pro: Em arrays All-Flash, o efeito liquidificador é menos nocivo devido à ausência de partes móveis, mas ainda afeta a Write Amplification e a saturação das filas da controladora. Em discos mecânicos (HDD) ou arrays híbridos, isso é catastrófico.

Anatomia de um commit: por que o WAL do banco de dados não tolera filas

Para entender por que misturar cargas é perigoso, precisamos dissecar como um banco de dados (PostgreSQL, Oracle, SQL Server) garante a durabilidade (o 'D' do ACID).

Antes de gravar o dado na tabela (que pode ser feito de forma assíncrona e lenta), o banco grava no Write-Ahead Log (WAL) ou Redo Log. Esta operação é:

1. Sequencial: O banco escreve sempre no final do arquivo.

2. Síncrona: O commit só retorna "sucesso" para a aplicação depois que o disco confirma que o dado está fisicamente gravado (chamada fsync).

Se você coloca o volume de WAL no mesmo conjunto de discos que está recebendo um backup ou servindo desktops virtuais, você introduz latência de fila.

O WAL é uma operação pequena (poucos KBs), mas que exige latência próxima de zero. Se esse I/O pequeno ficar preso atrás de um bloco gigante de 1MB de um backup sendo gravado, o banco para. É como uma Ferrari presa atrás de um caminhão de lixo em uma estrada de pista única. A velocidade máxima da Ferrari não importa; ela está limitada pelo caminhão.

Figura: Legenda: O WAL exige latência zero. Qualquer disputa de fila neste ponto resulta em travamento da aplicação.

Tempestades de boot e a escrita suja em infraestruturas de VDI

Infraestruturas de Desktop Virtual (VDI) são os vizinhos mais barulhentos que um storage pode ter. O perfil de I/O de VDI é bipolar e extremamente agressivo.

O Boot Storm (Tempestade de Inicialização)

Às 8:00 da manhã, 500 funcionários ligam suas máquinas virtuais simultaneamente. O storage é bombardeado por milhares de requisições de leitura aleatória (Random Read) para carregar o sistema operacional. Se o seu storage não tiver um cache de leitura robusto (DRAM ou SLC Cache), a latência dispara para segundos, e o Windows dos usuários trava na tela de login.

O Login Storm e a Escrita Suja

Após o boot, o perfil inverte. O Windows e os aplicativos começam a gerar arquivos temporários, logs e paginação. Isso gera uma carga massiva de escrita aleatória.

O erro comum é dimensionar o storage de VDI apenas para a capacidade (TB) e esquecer os IOPS de escrita. VDI é tipicamente 80% escrita durante o dia. Colocar VDI no mesmo array que um banco de dados OLTP é pedir para ter lentidão no ERP toda vez que o turno da empresa inicia.

O erro de tratar storage de backup como repositório de arquivos frios

Existe um mito de que "storage de backup pode ser lento". Isso é uma meia-verdade perigosa.

Sim, o armazenamento de retenção (archive) pode ser lento. Mas o armazenamento de ingestão (onde o backup pousa primeiro) precisa de performance.

1. Janela de Backup: Se o seu storage de destino é lento, o job de backup demora mais. Enquanto o backup roda, o servidor de produção sofre com snapshots abertos, causando penalidade de performance (o famoso "stun" de VM).

2. Deduplicação: Softwares modernos (Veeam, Commvault) fazem deduplicação e verificação de integridade. Isso exige leitura aleatória dos blocos já gravados para comparar hash. Storage lento transforma a deduplicação em um pesadelo de dias.

3. Instant Recovery: A funcionalidade de "ligar a VM direto do backup" exige que o storage de backup consiga entregar IOPS suficientes para rodar o sistema operacional. Se for disco SATA de 7.2k RPM sem cache, a VM liga mas fica inusável.

⚠️ Perigo: Nunca aponte o destino de um backup de alta frequência para o mesmo pool de discos da produção. Além do risco de segurança (perder tudo de uma vez), a concorrência de I/O durante a janela de backup vai derrubar sua produção.

Segregação física e lógica: namespaces NVMe e alinhamento de blocos

Como resolvemos essa guerra? Com segregação. E não estou falando apenas de comprar mais caixas.

O Poder dos Namespaces NVMe

No mundo antigo do SAS/SATA, criávamos LUNs e RAID Groups. No mundo moderno do NVMe, usamos Namespaces. O protocolo NVMe permite criar filas de submissão e conclusão dedicadas para cada Namespace.

• Crie um Namespace para o Banco de Dados.

• Crie outro para o Sistema Operacional. Isso permite que o controlador NVMe gerencie as filas de forma mais eficiente, aplicando QoS (Quality of Service) e garantindo que uma leitura massiva não bloqueie uma escrita crítica.

Alinhamento de Blocos (Block Alignment)

De nada adianta segregar se você formatar errado.

• Bancos de dados geralmente escrevem em páginas de 8KB ou 16KB.

• O sistema de arquivos (XFS/EXT4/NTFS) tem um tamanho de cluster (geralmente 4KB).

• O array de storage tem um tamanho de bloco nativo (ex: 4KB ou 8KB).

Se o banco gravar um bloco de 8KB e o sistema de arquivos estiver desalinhado, o storage precisará ler dois blocos, modificar e gravar dois blocos (Read-Modify-Write). Isso dobra o trabalho do storage. Alinhe suas partições. Garanta que o start sector da partição seja múltiplo do tamanho do bloco físico do storage.

Figura: Legenda: O desalinhamento de blocos causa o "Read-Modify-Write", penalizando a performance de escrita em até 50%.

Além da média: usando histogramas de latência para validar o SLA

Pare de reportar "latência média de 5ms". A média esconde os crimes. Se 99 requisições levam 1ms e 1 requisição leva 1 segundo (1000ms), a média será ~11ms. Parece aceitável, certo? Errado. Aquela requisição de 1 segundo foi um timeout na aplicação, um carrinho de compras abandonado ou uma transação falha.

Como DBA ou Arquiteto de Storage, você deve exigir métricas de Percentil (P95, P99) e Histogramas.

• P99: Significa que 99% das suas operações foram mais rápidas que X. É aqui que vive a verdade sobre a experiência do usuário.

• Histogramas: Mostram a distribuição. Você quer uma curva alta e estreita à esquerda (baixa latência). Se a curva for achatada e longa para a direita ("long tail"), você tem problemas de contenção de disco, provavelmente causados por mistura de workloads (DB + Backup + VDI).

O Veredito do DBA

Não existe "storage rápido" para arquiteturas ruins. Você pode ter o hardware mais avançado do planeta, mas se colocar o WAL do seu Oracle no mesmo RAID 5 de discos mecânicos que recebe o backup do File Server, você terá problemas.

A batalha entre DB, VDI e Backup é vencida na prancheta de desenho, não no painel de compras. Isole fisicamente o que for crítico (WAL/Redo Logs). Use Flash para o que exige IOPS aleatório (VDI/Data Files). E deixe os discos rotacionais (se ainda os tiver) para o repositório final de backup — e apenas para isso.

Seu banco de dados não é um arquivo de vídeo. Trate-o com o respeito que a aleatoriedade exige.

Referências & Leitura Complementar

Para aprofundamento técnico real, ignore blogs de marketing e vá direto às fontes de engenharia:

1. SNIA (Storage Networking Industry Association): "Solid State Storage Performance Test Specification (PTS)" – A bíblia de como testar SSDs corretamente, abordando pre-conditioning e steady state.

2. PostgreSQL Documentation - Chapter 30. Reliability and the Write-Ahead Log: Explicação definitiva sobre a importância do fsync e a física da escrita de logs.

3. NVM Express Base Specification (Revision 2.0+): Detalhes sobre NVMe Namespaces, Queues e Arbitration mechanisms.

4. VMware KB 2150483: "Understanding VM I/O Blending" – Documentação técnica sobre como o hypervisor gerencia filas de I/O.