Engenharia do caos em storage: injetando latência de fsync no etcd para validar o Kubernetes

A falha mais perigosa em um sistema distribuído não é aquela que derruba o servidor instantaneamente. A falha mais perigosa é a degradação silenciosa, onde o hardware continua operando, mas com uma lentidão imprevisível. No ecossistema do Kubernetes, o cérebro do cluster é o etcd, um banco de dados chave-valor altamente consistente. E a sanidade do etcd depende inteiramente de uma única métrica de armazenamento: a latência da chamada de sistema fsync.

Quando projetamos infraestruturas de armazenamento para sistemas de missão crítica, frequentemente focamos em IOPS (operações de entrada e saída por segundo) e throughput. No entanto, para o control plane do Kubernetes, a métrica de ouro é a latência de cauda. Um disco que hesita por uma fração de segundo pode desencadear um efeito cascata, resultando em perda de quórum, indisponibilidade da API e falhas de agendamento de pods.

Para garantir a confiabilidade, não podemos apenas torcer para que os discos físicos ou os volumes virtuais se comportem bem. Precisamos adotar a engenharia do caos, injetando latência intencional no nível do bloco de armazenamento para observar como o sistema reage, validar nossos Service Level Indicators (SLIs) e ajustar nossos alertas antes que um incidente real ocorra em produção.

Resumo em 30 segundos

• O etcd exige que a latência de fsync permaneça consistentemente abaixo de 10 milissegundos para manter a estabilidade do cluster.
• Picos de latência de disco acima de 50 milissegundos causam perda de heartbeats, gerando tempestades de eleição de líder no Kubernetes.
• A injeção de falhas no nível do bloco (usando ferramentas como dm-delay) permite validar a resiliência da arquitetura de storage de forma controlada.

A degradação silenciosa do control plane quando o disco hesita

Em uma arquitetura de confiabilidade moderna, tratamos a infraestrutura como código e as falhas como eventos esperados. Quando um disco de estado sólido (SSD) ou um disco rígido (HDD) falha completamente, o sistema operacional marca o dispositivo como inoperante. O cluster percebe a falha do nó, isola o problema e a vida segue. O verdadeiro pesadelo do Engenheiro de Confiabilidade (SRE) é o disco "cinzento".

Um disco cinzento é aquele que responde às requisições de I/O, mas com um jitter severo. Isso geralmente ocorre devido a ciclos agressivos de garbage collection no firmware do SSD, contenção de barramento PCIe ou vizinhos barulhentos em um hypervisor de armazenamento compartilhado (Storage Area Network - SAN).

Para o Kubernetes, essa hesitação é fatal. O etcd utiliza o algoritmo de consenso Raft para manter o estado do cluster sincronizado entre os nós. O líder do cluster precisa enviar heartbeats periódicos para os seguidores. Se o disco onde o líder reside sofre um pico de latência e trava a thread de execução, o heartbeat não é enviado. Os seguidores assumem que o líder morreu e iniciam uma nova eleição, paralisando temporariamente as operações do cluster.

A anatomia do commit: por que o etcd entra em pânico após 50 milissegundos

Para entender a fragilidade do sistema, precisamos olhar para a anatomia de uma gravação. Toda vez que você altera algo no Kubernetes, o etcd precisa registrar essa mudança em seu Write-Ahead Log (WAL). O WAL é um arquivo de log sequencial que garante a durabilidade dos dados em caso de falha de energia.

A regra de ouro dos bancos de dados distribuídos é que uma transação só é considerada bem-sucedida após os dados serem fisicamente gravados na mídia não volátil. Para garantir isso, o etcd emite uma chamada de sistema fsync (file synchronize). O fsync instrui o sistema operacional a ignorar os caches de memória RAM e forçar a gravação direta nos blocos do disco.

Figura: Diagrama ilustrando o gargalo do fsync no Write-Ahead Log do etcd e o impacto da latência do disco NVMe.

A documentação oficial do etcd é implacável neste ponto. A latência do fsync deve estar na casa dos poucos milissegundos. Se a operação de gravação no disco demorar mais de 50 milissegundos, o etcd começa a registrar avisos de lentidão. Se essa latência persistir, o nó perde o tempo limite de eleição, causando uma reconfiguração forçada do cluster.

⚠️ Perigo: Nunca coloque o diretório do WAL do etcd no mesmo disco físico utilizado pelo sistema operacional para logs (/var/log) ou swap. A contenção de I/O gerada por outras aplicações destruirá a performance do fsync, causando instabilidade crônica no Kubernetes.

A ilusão do hardware bruto: migrar para discos NVMe não resolve o jitter de I/O

Uma resposta comum (e equivocada) para problemas de latência de storage é simplesmente jogar hardware mais rápido no problema. A transição do protocolo SATA para o Non-Volatile Memory Express (NVMe) trouxe ganhos massivos de throughput, conectando o armazenamento diretamente ao barramento PCIe da placa-mãe.

No entanto, a velocidade bruta não garante consistência. Em ambientes de nuvem pública ou infraestruturas hiperconvergentes, o disco NVMe que sua máquina virtual enxerga raramente é um dispositivo físico dedicado. Ele é um volume lógico abstraído por camadas de software, hypervisors e redes de armazenamento.

Quando múltiplos locatários compartilham o mesmo pool de armazenamento físico, ocorre o fenômeno do "noisy neighbor" (vizinho barulhento). Se outra máquina virtual no mesmo host iniciar um backup massivo, as filas de I/O da controladora de storage ficarão saturadas. O seu disco NVMe virtual, que normalmente responde em 1 milissegundo, subitamente levará 100 milissegundos para completar um fsync.

Característica	Storage Compartilhado (SAN/Cloud Block)	Disco NVMe Local Dedicado
Throughput Máximo	Alto (escalável via rede)	Extremamente Alto
Consistência de Latência	Baixa (sujeita a vizinhos barulhentos)	Alta (isolamento físico)
Risco de Gargalo de fsync	Alto (depende da rede e hypervisor)	Baixo (limitado apenas pelo firmware)
Complexidade de Gestão	Centralizada (fácil de gerenciar)	Descentralizada (requer automação)
Recomendação para etcd WAL	Evitar se possível	Altamente Recomendado

Injetando o caos no armazenamento para mapear limites de tolerância

A cultura de SRE nos ensina que a esperança não é uma estratégia. Não podemos esperar que o provedor de nuvem ou a controladora de storage mantenham a latência baixa para sempre. Precisamos provar empiricamente que nosso cluster Kubernetes consegue sobreviver a degradações de disco. É aqui que entra a engenharia do caos focada em armazenamento.

O objetivo não é quebrar o sistema de forma aleatória, mas sim conduzir experimentos científicos controlados. Queremos responder a uma pergunta específica: "Se o disco que hospeda o WAL do etcd sofrer um atraso de 100 milissegundos em 20% das operações de gravação, nossos alertas dispararão antes que o cluster perca o quórum?".

Para simular isso, utilizamos ferramentas nativas do kernel Linux, como o Device Mapper Delay (dm-delay) ou o Traffic Control (tc). O dm-delay permite criar um dispositivo de bloco virtual que atua como um proxy para o disco físico, adicionando latência artificial a cada operação de leitura ou gravação no nível do setor do disco.

Figura: Representação visual da injeção de latência no nível do bloco de armazenamento usando ferramentas de engenharia do caos.

Ao iniciar o experimento, injetamos 10 milissegundos de latência. O sistema deve permanecer estável. Aumentamos para 30 milissegundos. Observamos os gráficos de monitoramento. Aumentamos para 60 milissegundos. Neste ponto, esperamos ver os logs do etcd reclamando de lentidão no fsync e, eventualmente, uma mudança na liderança do cluster.

💡 Dica Pro: Ao realizar experimentos de caos em storage, comece sempre em um ambiente de staging que espelhe a configuração de discos da produção. Nunca injete latência no disco principal de um banco de dados em produção sem antes ter validado os mecanismos de failover e recuperação automatizada.

Validando a resiliência através de métricas de eleição de líder

A execução do experimento de caos perde o sentido se não tivermos observabilidade adequada. Durante a injeção de latência no disco, a equipe de SRE deve monitorar de perto os Service Level Indicators (SLIs) do armazenamento.

A métrica mais crítica a ser observada no Prometheus é a etcd_disk_wal_fsync_duration_seconds. Esta métrica expõe um histograma do tempo gasto nas chamadas de sincronização de disco. O nosso Service Level Objective (SLO) interno deve ditar que o percentil 99 (p99) dessa métrica permaneça abaixo de 10 milissegundos.

Simultaneamente, monitoramos a métrica etcd_server_leader_changes_seen_total. Se a injeção de latência no disco causar um aumento nesta métrica, sabemos exatamente qual é o ponto de ruptura da nossa infraestrutura. Se o cluster cair, a culpa não é do engenheiro que executou o teste, nem do disco que ficou lento. A culpa é do design do sistema que não foi tolerante à falha. Este é o princípio fundamental de um post-mortem sem culpa (blameless).

O futuro da resiliência em arquiteturas de armazenamento

A dependência crítica de sistemas distribuídos em relação à latência de armazenamento está forçando a indústria a repensar a arquitetura de hardware. A adoção de tecnologias emergentes como o Compute Express Link (CXL) promete mudar esse cenário. O CXL é um padrão de interconexão que permite que dispositivos de armazenamento e aceleradores compartilhem a mesma memória do processador com latência ultrabaixa, contornando os gargalos tradicionais das controladoras de disco.

Até que essas inovações se tornem o padrão nos datacenters, a recomendação arquitetural permanece clara. Isole o tráfego de I/O crítico. Forneça discos NVMe dedicados exclusivamente para o Write-Ahead Log de bancos de dados de consenso. E, acima de tudo, teste continuamente a degradação do seu armazenamento.

A latência de disco é uma força da natureza na infraestrutura de TI. Ela vai acontecer, seja por falha de hardware, bugs de firmware ou saturação de rede. A engenharia do caos garante que, quando o disco inevitavelmente hesitar, o seu sistema responderá com resiliência previsível, e não com um colapso catastrófico.

Referências e leitura complementar

• Documentação Oficial do etcd: Recomendações de hardware e tuning de disco para clusters de produção.

• Google SRE Book: Capítulo 17 sobre Testes de Confiabilidade e Capítulo 28 sobre Aceleração de Recuperação de Falhas.

• SNIA (Storage Networking Industry Association): Especificações sobre Solid State Storage Performance Test Specification (PTS) e estados de transição de latência.

• RFC 761: Especificações originais sobre controle de transmissão e a importância de confirmações síncronas em sistemas de rede e armazenamento.

Qual é a latência máxima de fsync recomendada para o etcd?

A documentação oficial do etcd recomenda que a latência de fsync (monitorada pela métrica wal_fsync_duration_seconds) permaneça consistentemente abaixo de 10 milissegundos. Picos que ultrapassam a marca de 50 milissegundos frequentemente disparam novas eleições de líder, desestabilizando o control plane do Kubernetes.

Como a engenharia do caos ajuda na confiabilidade do storage?

Ao injetar falhas controladas, como atrasos artificiais de I/O diretamente no bloco do disco, as equipes de SRE conseguem observar empiricamente como o sistema reage sob estresse. Isso permite ajustar timeouts, configurar políticas de QoS no storage e validar a eficácia dos alertas antes que uma degradação real de hardware ocorra em produção.

Por que separar o WAL do etcd em um disco dedicado?

O Write-Ahead Log (WAL) exige gravações sequenciais extremamente rápidas e estritamente síncronas. Compartilhar o mesmo disco físico com o banco de dados principal (boltdb) ou com os logs do sistema operacional introduz contenção severa de I/O. Essa disputa por recursos aumenta drasticamente a latência do fsync, causando instabilidade crônica no cluster.