Ceph Crimson: O Fim dos Context Switches em Storage NVMe

A evolução do hardware de armazenamento nos últimos cinco anos criou um problema interessante, quase irônico, para arquitetos de infraestrutura. Durante décadas, o disco (HDD) foi o vilão da latência. O software, por sua vez, era o herói ágil que esperava pacientemente o prato girar. Com a chegada e a massificação do NVMe — e agora com a interface PCIe 5.0 entregando milhões de IOPS por dispositivo — o cenário se inverteu. O software tornou-se o gargalo.

O Ceph, padrão de fato para armazenamento definido por software (SDS) open source, foi concebido em uma era onde a latência de milissegundos era aceitável. No entanto, ao colocarmos um cluster Ceph tradicional sobre um backplane 100% NVMe, observamos um fenômeno preocupante: a CPU satura muito antes de atingirmos o limite teórico dos drives. É aqui que entra o Project Crimson. Não se trata apenas de uma otimização de código; é uma reescrita fundamental da arquitetura do Object Storage Daemon (OSD) para sobreviver em um mundo de microssegundos.

Resumo em 30 segundos

O Gargalo mudou: Em storage NVMe moderno, o custo de context switching da CPU e o bloqueio de threads (locking) no Ceph clássico impedem o uso total da performance dos discos.

Arquitetura Shared-Nothing: O Crimson utiliza o framework Seastar para fixar threads a núcleos de CPU específicos, eliminando a necessidade de locks globais e reduzindo drasticamente a latência de cauda.

Eficiência de TCO: O objetivo final não é apenas "mais velocidade", mas extrair mais IOPS por watt e por ciclo de CPU, permitindo maior densidade de armazenamento com menos servidores.

O paradoxo da latência em hardware moderno

Para entender o Crimson, precisamos dissecar o problema do Ceph clássico (baseado no ceph-osd tradicional). A arquitetura atual depende pesadamente de thread pools. Quando uma requisição de I/O chega, ela é passada entre diferentes threads para processamento: recepção de rede, processamento lógico, gravação no BlueStore, replicação, etc.

Cada passagem dessas envolve um Context Switch. O kernel do Linux precisa parar uma tarefa, salvar seu estado, carregar outra e continuar. Em um HDD que leva 5ms para buscar um dado, perder 10 microssegundos (µs) trocando de contexto é irrelevante. Mas em um drive NVMe Optane ou 3D NAND moderno, que responde em 10µs a 30µs, o overhead do software pode representar 50% ou mais do tempo total da transação.

Figura: Comparação visual entre o caos do chaveamento de contexto tradicional e a eficiência do paralelismo dedicado do Crimson.

Além disso, temos a contenção de recursos. O modelo clássico usa locks (mutexes) para garantir a consistência dos dados quando múltiplas threads acessam as mesmas estruturas de memória. À medida que adicionamos mais núcleos de CPU para tentar escalar a performance, a contenção nesses locks aumenta. O resultado não é linear; é uma curva de retornos decrescentes onde adicionar mais CPU pode, paradoxalmente, piorar a latência devido à disputa por recursos compartilhados.

Crimson e Seastar: A arquitetura shared-nothing

A resposta da comunidade Ceph para esse desafio foi adotar o Seastar, um framework C++ assíncrono de alta performance. A filosofia aqui é radicalmente diferente: Shared-Nothing (Nada Compartilhado).

No modelo do Crimson, o OSD é dividido em "shards". Cada shard é fixado (pinned) a um núcleo físico da CPU e possui sua própria região de memória e sua própria fila de eventos de rede.

Como isso elimina o gargalo?

Fim dos Locks Globais: Como cada núcleo opera apenas em seus próprios dados, não há necessidade de locks complexos para proteger a memória de outros núcleos.
Run-to-Completion: Em vez de trocar de contexto no meio de uma operação, a thread processa a requisição do início ao fim (ou até atingir um ponto de espera de I/O assíncrono).
Polling vs. Interrupções: Em cargas extremas, o custo de tratar interrupções de hardware é alto. O Seastar prefere fazer polling (verificação ativa) das filas de conclusão do NVMe, o que mantém a CPU ocupada com trabalho útil em vez de overhead de gerenciamento de interrupções.

💡 Dica Pro: Ao planejar a infraestrutura para Crimson, a escolha da CPU muda. Frequência de clock (GHz) e tamanho de cache L3 por núcleo tornam-se mais críticos do que a contagem bruta de núcleos, pois cada núcleo precisa ser capaz de saturar sua fatia do I/O sem depender de ajuda externa.

SeaStore: Otimização nativa para o futuro do flash

O Crimson pode rodar sobre o BlueStore (o backend de armazenamento atual do Ceph) através de uma camada de compatibilidade chamada AlienStore. No entanto, isso é apenas uma medida paliativa. O verdadeiro potencial do Crimson reside no SeaStore.

O BlueStore foi uma revolução quando substituiu o FileStore, permitindo que o Ceph falasse diretamente com o disco bruto (raw block device). Mas o BlueStore ainda carrega pressupostos de design baseados em HDDs e SSDs SATA. Ele possui seu próprio sistema de gerenciamento de threads que entra em conflito com o modelo do Seastar.

O SeaStore é desenhado do zero para ser assíncrono e tirar proveito de tecnologias emergentes como ZNS (Zoned Namespaces).

O impacto do ZNS e a morte do FTL

SSDs convencionais possuem uma camada interna chamada FTL (Flash Translation Layer), que engana o sistema operacional fazendo a memória NAND parecer um disco magnético que pode ser sobrescrito em qualquer lugar. Isso gera o fenômeno de Write Amplification (amplificação de escrita) e requer Garbage Collection interno do drive, causando picos de latência imprevisíveis.

O SeaStore, trabalhando com drives ZNS, assume a responsabilidade de gerenciar onde os dados são escritos sequencialmente. Isso elimina a necessidade da FTL complexa no drive e a "dupla camada" de log (o journal do Ceph + o log interno do SSD).

Figura: Diagrama técnico ilustrando o SeaStore acessando diretamente as zonas de um SSD ZNS, eliminando a camada de tradução (FTL) intermediária.

Tabela Comparativa: Ceph Clássico vs. Ceph Crimson

Característica	Ceph Clássico (OSD Tradicional)	Ceph Crimson (Next-Gen OSD)
Modelo de Concorrência	Thread-per-request / Thread Pools	Shared-Nothing / Reactor Pattern
Gerenciamento de CPU	Preemptivo (Kernel Scheduler decide)	Cooperativo (Aplicação decide)
Custo de Context Switch	Alto (Milhares por segundo)	Mínimo (Design Run-to-completion)
Backend de Storage	BlueStore (Otimizado p/ HDD/SSD misto)	SeaStore (Nativo p/ NVMe/ZNS)
Uso de Memória	Compartilhado com Locks (Mutex)	Particionado por Núcleo (Shard)
Interface de I/O	Síncrona / Libaio	Assíncrona / io_uring
Cenário Ideal	HDDs, SSDs SATA/SAS, Arquivos Gerais	NVMe de Alta Performance, Bancos de Dados, AI/ML

Resultados preliminares e impacto no TCO

A promessa técnica é linda, mas como arquitetos, precisamos olhar para o Custo Total de Propriedade (TCO). O Crimson não serve apenas para fazer um benchmark bonito de 1 milhão de IOPS. Ele serve para reduzir o número de servidores necessários para atingir esse número.

Em testes controlados com versões recentes (pós-Reef), o Crimson demonstrou a capacidade de reduzir a latência de cauda (p99) significativamente. Em workloads de escrita aleatória 4K (o pior cenário para storage), a estabilidade da latência é superior porque não há "brigas" por locks dentro do processo do OSD.

⚠️ Perigo: O consumo de CPU no modelo Crimson pode parecer "alto" em ferramentas de monitoramento tradicionais (como top ou htop), pois o modelo de polling do Seastar tende a utilizar 100% do núcleo alocado, mesmo que esteja apenas esperando I/O. Métricas de observabilidade precisam ser adaptadas para medir "utilização do reator" e não apenas "uso de CPU do sistema".

Para o TCO, a equação é a seguinte: se hoje você precisa de 10 servidores com BlueStore para saturar a rede de 100GbE devido ao gargalo de CPU, com o Crimson maduro, você poderia teoricamente atingir a mesma vazão com 3 ou 4 servidores, limitando-se apenas pela largura de banda do barramento PCIe ou da rede, e não pela ineficiência do software. Isso reduz custos de rack, energia, refrigeração e licenciamento de softwares adjacentes.

Figura: Visualização de TCO: Um rack denso e quente rodando Ceph legado versus um rack enxuto e eficiente rodando Crimson entregando a mesma performance.

O caminho à frente: Adoção e Maturidade

O Crimson não é uma "atualização simples" que você aplica com um apt-get upgrade e esquece. É uma mudança de paradigma. Atualmente, em 2026, ainda vemos o Crimson como uma tecnologia que exige validação cuidadosa. Funcionalidades avançadas do Ceph, como Erasure Coding complexo ou certas classes de Tiering, demoraram a ser portadas com paridade de recursos para o novo modelo.

Para ambientes Greenfield (novas implantações) focados exclusivamente em NVMe, o Crimson com SeaStore é o caminho inevitável. Para clusters híbridos ou baseados em HDD, o OSD clássico continuará reinando por muitos anos, pois o ganho de performance do Crimson é diluído pela latência mecânica dos discos rotacionais.

A transição para I/O assíncrono via io_uring e arquiteturas shared-nothing não é exclusiva do Ceph; é uma tendência que vemos em bancos de dados modernos (como ScyllaDB) e proxies (como Envoy). O armazenamento está finalmente alcançando a velocidade da rede e do silício.

Se você está desenhando a próxima geração de sua nuvem privada ou infraestrutura de dados, o Crimson deve estar no seu radar de homologação. A eficiência energética e a densidade de performance que ele desbloqueia são vitais para a sustentabilidade econômica dos datacenters modernos.

Referências & Leitura Complementar

Seastar Framework: Advanced flow control for distributed systems - Whitepaper técnico sobre o modelo de reator.
Ceph Foundation: Crimson: The Next Generation Ceph OSD - Documentação oficial de arquitetura.
NVMe Express: Zoned Namespaces (ZNS) Command Set Specification - Especificação técnica da NVM Express Inc.
Linux Kernel: io_uring: Asynchronous I/O interface - Documentação do subsistema de I/O do kernel Linux.

Perguntas Frequentes (FAQ)

O Ceph Crimson já está pronto para produção em 2026?

Ainda é considerado "Tech Preview" ou "Experimental" para a maioria dos casos de uso críticos em ambientes corporativos conservadores, embora versões recentes (como a release Tentacle e posteriores) tenham estabilizado significativamente o suporte ao SeaStore. A recomendação arquitetural é validar em ambientes de staging ou para workloads de alto desempenho que não sejam de missão crítica (Tier 2), até que a paridade de recursos com o OSD clássico seja 100% atingida.

Qual a diferença principal entre BlueStore e SeaStore?

O BlueStore foi desenhado como uma camada intermediária para HDDs e SSDs convencionais, utilizando um modelo de threads que, embora eficiente, ainda sofre com bloqueios (locks). O SeaStore é nativo para o modelo assíncrono do Crimson (baseado em Seastar), desenhado especificamente para NVMe e Zoned Namespaces (ZNS). Ele elimina a necessidade de sistemas de arquivos intermediários e reduz drasticamente a amplificação de escrita.

Preciso trocar meu hardware para usar Crimson?

Não obrigatoriamente, o Crimson roda em hardware x86 padrão. No entanto, para extrair o valor real (ROI) e justificar a migração, recomenda-se o uso de CPUs modernas com suporte a instruções avançadas e, crucialmente, drives NVMe. Em clusters baseados puramente em HDDs, o ganho de performance do Crimson é marginal e muitas vezes imperceptível, pois a latência mecânica do disco (seek time) continua sendo o gargalo dominante.