Benchmarking RAID: A Verdade Sobre Performance com FIO e Iometer
Pare de adivinhar sua performance de storage. Aprenda a medir IOPS, latência e throughput em RAID 5, 6 e 10 usando metodologias científicas com fio e iometer.
Se você já executou um dd if=/dev/zero e correu para o seu gerente gritando que o novo array de armazenamento faz 3 GB/s, sente-se. Precisamos conversar. Como arquiteto, já vi projetos de milhões de reais falharem não porque o hardware era ruim, mas porque a validação de desempenho foi baseada em ilusões, não em física.
Benchmarking de storage não é um concurso de quem tem o número maior. É um exercício de redução de risco e previsão de comportamento. Se você não entende como seus bits tocam o prato magnético ou a célula NAND, seus números são apenas ruído aleatório gerado pela CPU.
O que é Benchmarking de RAID? O benchmarking de RAID é o processo sistemático de submeter um subsistema de armazenamento a cargas de trabalho sintéticas controladas (IOPS, throughput e latência) para determinar seus limites físicos e lógicos, validando se a arquitetura suporta os requisitos da aplicação antes da entrada em produção, indo além das métricas de marketing do fabricante.
Por que o comando 'dd' falha no Benchmarking de Storage
Vamos começar matando a vaca sagrada dos administradores de sistemas apressados. O comando dd é uma ferramenta excelente para copiar dados, mas terrível para medir desempenho de arrays RAID modernos.
O problema reside no "modelo mental" simplista. Quando você grava zeros (/dev/zero) sequencialmente em um arquivo, você está criando o cenário mais amigável possível para o seu sistema. Controladoras RAID modernas e sistemas de arquivos (como ZFS ou arrays All-Flash com compressão inline) detectam essa sequência de zeros e sequer tocam no disco físico da maneira que você imagina. Elas comprimem, deduplicam ou simplesmente armazenam metadados dizendo "aqui tem 10GB de nada".
Além disso, o dd é single-threaded e, por padrão, usa I/O bufferizado pelo sistema operacional. O que você mede muitas vezes é a velocidade da sua memória RAM (cache do Page Cache do Linux), não a velocidade do seu array RAID 10 de SAS 15k. Para desenhar uma solução enterprise, precisamos de ferramentas que gerem entropia real, controlem a profundidade da fila (Queue Depth) e ignorem o cache do SO.
Entendendo a Penalidade de Escrita (Write Penalty) no RAID
Antes de abrir o terminal, você precisa entender a matemática cruel do RAID. Ler dados é "barato". Gravar dados em um ambiente com paridade (RAID 5, 6) é "caro".
Quando sua aplicação envia uma requisição de escrita para um volume RAID 5, o storage não apenas "grava". Ele precisa realizar quatro operações distintas (o ciclo Read-Modify-Write):
Ler o dado antigo.
Ler a paridade antiga.
Calcular a nova paridade.
Gravar o novo dado e a nova paridade.
Isso introduz uma latência mecânica e de processamento inevitável. Se você desenha uma solução para um banco de dados OLTP (muita escrita aleatória) sobre RAID 6, você está condenando a performance, independentemente de quantos discos adicione.
Figura: A Matemática da Penalidade de Escrita: Onde o RAID 5 e 6 perdem performance.
Observe a tabela abaixo para entender o impacto no TCO (Custo Total de Propriedade) e dimensionamento:
| Nível RAID | Penalidade de Escrita | Eficiência de Espaço | Custo/GB | Cenário Ideal |
|---|---|---|---|---|
| RAID 0 | 0 (1 IO = 1 Write) | 100% | Baixo | Cache temporário, Scratch (Sem redundância) |
| RAID 10 | 2 (1 IO = 2 Writes) | 50% | Alto | Banco de Dados, Alta Performance, VM Boot |
| RAID 5 | 4 (1 IO = 4 Ops) | 67% - 94% | Médio | File Server, Backup, Cargas de Leitura |
| RAID 6 | 6 (1 IO = 6 Ops) | 50% - 88% | Médio | Arquivamento, Discos Grandes (>4TB) |
Definindo Cargas de Trabalho (Workloads) para Testes Precisos
Não existe "storage rápido". Existe storage rápido para o quê? Um storage otimizado para streaming de vídeo (sequencial, blocos grandes) será terrível para hospedar máquinas virtuais (aleatório, blocos pequenos).
Para configurar seu teste, você deve definir as "Quatro Pontas do Storage":
Block Size (Tamanho do Bloco): 4k (padrão DB/VM), 64k-128k (Logs/SQL Server), 1M+ (Backup/Vídeo).
Access Pattern (Padrão de Acesso): Random (Aleatório) ou Sequential (Sequencial).
Operation (Operação): Read (Leitura) ou Write (Escrita).
Queue Depth (Profundidade da Fila): Quantas requisições simultâneas o storage deve tratar.
Figura: Definindo o perfil de teste no FIO: Qual quadrante seu servidor ocupa?
Se você testar seu RAID com blocos de 1MB sequenciais, obterá números lindos de Throughput (MB/s). Mas se sua aplicação real for um banco PostgreSQL fazendo transações de 8k aleatórias, aquele teste foi inútil. Você precisa simular o pior cenário real, não o melhor cenário teórico.
Configurando o FIO para Benchmarking de RAID Realista
O FIO (Flexible I/O Tester) é a ferramenta padrão-ouro da indústria. Criado por Jens Axboe (mantenedor do subsistema de bloco do Linux), ele permite esculpir o I/O exatamente como sua aplicação faria.
Abaixo, apresento um "Job File" comentado. Não copie e cole cegamente; entenda os parâmetros. O segredo aqui é o direct=1 (que ignora o cache do SO, testando o disco real) e o ioengine=libaio (para I/O assíncrono moderno).
[global]
ioengine=libaio # Engine de I/O assíncrono nativo do Linux
direct=1 # CRÍTICO: Ignora o cache de RAM (Page Cache)
bs=4k # Tamanho do bloco (simulando DB/VM)
rw=randwrite # Padrão: Escrita aleatória (o teste mais cruel)
iodepth=32 # Quantas requisições "em voo" simultaneamente
numjobs=4 # Número de processos/threads gerando carga
runtime=300 # Tempo de execução (5 minutos para estabilizar)
group_reporting # Agrega resultados de todos os jobs
time_based # Roda pelo tempo definido, não por tamanho de arquivo
[teste-raid10-db]
filename=/dev/md0 # Dispositivo alvo (Cuidado: isso destrói dados!)
size=10G # Tamanho da área de teste (deve ser > cache da controladora)
Nota do Arquiteto: O parâmetro size deve ser significativamente maior que o cache DRAM da sua controladora RAID (se houver). Se sua placa tem 4GB de cache e você testa com um arquivo de 1GB, você está testando a velocidade da memória da placa, não dos discos.
O Impacto do Preconditioning em SSDs Enterprise
Se você está testando SSDs (SATA, SAS ou NVMe), existe um assassino silencioso de benchmarks chamado "Estado FOB" (Fresh Out of Box).
Um SSD novo grava incrivelmente rápido porque todas as suas páginas estão vazias. Porém, em produção, o SSD estará "sujo". Para regravar uma célula, ele precisa apagar um bloco inteiro antes (ciclo Program/Erase). O firmware do SSD trabalha furiosamente em background fazendo Garbage Collection.
Se você rodar o FIO em um SSD novo por 5 minutos, verá 50.000 IOPS. Se rodar por 2 horas, verá esse número cair para 15.000 IOPS (o chamado "Steady State").
Regra de Ouro: Antes de medir performance de SSDs para produção, você deve fazer o Preconditioning. Isso envolve encher o disco inteiro com dados aleatórios duas vezes antes de começar a medir. Caso contrário, seu dimensionamento de capacidade estará errado.
Analisando Latência p99 e Queue Depth nos Resultados
Ao receber o relatório do FIO ou Iometer, a maioria olha para "Total IOPS". Isso é um erro de principiante. IOPS sem contexto de latência é irrelevante.
Imagine um storage que entrega 100.000 IOPS, mas com latência de 50ms. Sua aplicação web parecerá travada para o usuário. O que buscamos é a curva onde o IOPS sobe e a latência se mantém estável.
O ponto de quebra ocorre quando aumentamos o iodepth (Queue Depth). Em um certo ponto, o storage satura. Adicionar mais requisições na fila não aumenta o IOPS, apenas aumenta a latência exponencialmente.
Figura: A relação entre Queue Depth e Latência: Encontrando o ponto de quebra do seu storage.
Foco na Latência p99 (99th Percentile): A média mente. Se 99 requisições levam 1ms e 1 requisição leva 1 segundo, a média é boa, mas um usuário ficou furioso. O p99 (ou p99.99) mostra o comportamento dos "piores casos". Em arquitetura enterprise, desenhamos a solução para garantir que o p99 esteja dentro do SLA (ex: abaixo de 5ms).
Iometer vs FIO: Quando usar a ferramenta legacy no Windows
Embora o FIO seja superior em flexibilidade e scriptabilidade (ideal para DevOps e CI/CD), o Iometer ainda tem seu lugar. Se você opera em um ambiente puramente Windows e precisa apresentar relatórios visuais para gestores não-técnicos ("C-level"), a interface gráfica do Iometer facilita a explicação.
Contudo, cuidado: o projeto Iometer ficou estagnado por anos. Ele pode não gerar cargas de trabalho NVMe tão eficientes quanto o FIO. Use-o para validações rápidas em Windows Server, mas para a "verdade nua e crua" do hardware, prefira o FIO (que também roda em Windows via CLI).
Checklist de Validação Final
Antes de assinar o design da solução, verifique:
O teste usou
direct I/Opara evitar cache de RAM?O dataset do teste era pelo menos 2x maior que o cache da controladora RAID?
Se for SSD, foi feito Preconditioning para atingir o Steady State?
O workload simulado (Random/Seq, R/W) reflete a aplicação real?
A latência p99 está aceitável sob a carga máxima esperada?
Benchmarking é a arte de ser pessimista nos testes para poder ser otimista na produção. Teste para falhar, e seu storage sobreviverá.
Referências & Leitura Complementar
SNIA (Storage Networking Industry Association): Solid State Storage (SSS) Performance Test Specification (PTS) – A bíblia do teste de SSDs.
FIO Documentation:
man fioou documentação oficial do projeto no GitHub.Linux Kernel Documentation: I/O Schedulers e Block Layer overview.
Jens Axboe: Whitepapers e discussões sobre
io_uringvslibaio.
Sarah 'The Backup' Connor
Gerente de Recuperação de Desastres
Seus dados não estão seguros até que ela diga que estão. Especialista em estratégias de backup imutável e RPO/RTO.