Ceph Crimson e SeaStore: reescrevendo o storage distribuído para a era NVMe

A evolução do armazenamento de dados corporativo atingiu um ponto de inflexão crítico. Durante a última década, testemunhamos a transição dos discos rotacionais (HDD) para o flash (SSD) e, mais recentemente, para o protocolo NVMe. No entanto, enquanto o hardware de armazenamento ganhou ordens de magnitude em velocidade e redução de latência, a pilha de software que o gerencia não acompanhou o mesmo ritmo. O Ceph, padrão de facto para armazenamento definido por software (SDS) open source, enfrenta hoje o desafio de se reinventar para não se tornar o gargalo da própria infraestrutura que orquestra.

O projeto Crimson não é apenas uma atualização incremental; é uma reescrita fundamental da arquitetura do Ceph OSD (Object Storage Daemon), desenhada para eliminar o overhead legado e abraçar a realidade dos dispositivos de armazenamento de ultra-baixa latência.

Resumo em 30 segundos

O Gargalo mudou: Com NVMes modernos, a CPU e o gerenciamento de threads do software tornaram-se o limitador de performance, não mais o disco.

Arquitetura Shared-Nothing: O Crimson abandona o modelo de thread pools do Ceph clássico em favor do framework Seastar, onde cada núcleo de CPU opera de forma independente sem locks caros.

Kernel Bypass: O novo backend SeaStore utiliza SPDK para falar diretamente com o hardware NVMe, ignorando o kernel do Linux e reduzindo drasticamente a latência de cauda.

O Paradoxo do Hardware Ocioso

Em arquiteturas de storage tradicionais, a latência do disco sempre foi a "âncora" do desempenho. Um HDD mecânico com latência de 5 a 10 milissegundos mascarava qualquer ineficiência do software. Se o código demorasse 50 microssegundos para processar uma requisição, isso era irrelevante frente à lentidão física do braço do disco.

Com a chegada dos SSDs NVMe, a latência do dispositivo caiu para a casa dos 10 a 20 microssegundos. De repente, aqueles 50 microssegundos de processamento de software tornaram-se 70% ou 80% do tempo total da transação.

Isso cria um cenário frustrante para arquitetos de infraestrutura: clusters all-flash caríssimos onde os discos operam a 20% de utilização, enquanto as CPUs dos servidores de storage estão saturadas em 100%. Não estamos limitados por I/O, mas por ciclos de CPU desperdiçados em gerenciamento de concorrência.

Figura: Comparação visual do impacto da latência de software em mídias HDD versus NVMe.

A Anatomia do Gargalo: O Custo Oculto do Context Switching

O ceph-osd clássico foi construído sobre uma arquitetura baseada em threads (pthreads). Quando uma requisição de I/O chega, ela é passada entre diferentes filas e threads: uma thread para ler da rede, outra para processar a lógica, outra para escrever no disco (BlueStore), e assim por diante.

Cada vez que a CPU troca de uma thread para outra (context switching), existe um custo. O processador precisa salvar o estado atual, carregar o novo estado e, pior, o cache L1/L2 da CPU é frequentemente invalidado ("poluído"). Em sistemas com milhares de IOPS, a CPU passa mais tempo trocando de contexto e gerenciando locks (bloqueios de memória para evitar corrupção de dados) do que movendo dados efetivamente.

⚠️ Perigo: Em cargas de trabalho de alta performance, o lock contention (disputa por bloqueios) no Ceph clássico causa picos de latência imprevisíveis, conhecidos como "latência de cauda" (tail latency), que degradam a experiência de aplicações sensíveis.

Crimson e a Revolução do Modelo Shared-Nothing

Para resolver isso, a comunidade Ceph adotou o Crimson, uma nova implementação do daemon OSD baseada no framework Seastar. O Seastar introduz um modelo de programação assíncrono e reativo, fundamentalmente diferente do modelo multithread tradicional.

A filosofia central é o Shared-Nothing (Nada Compartilhado). No Crimson, o armazenamento é particionado (sharded) entre os núcleos da CPU. Cada núcleo possui sua própria fatia de memória, sua própria fila de rede e gerencia um conjunto específico de objetos ou PGs (Placement Groups).

Como o Seastar altera o jogo:

Um Core, Uma Thread: O Seastar fixa uma única thread por núcleo físico.
Sem Locks: Como cada núcleo acessa apenas sua própria memória, não há necessidade de locks complexos ou mutexes atômicos para sincronização entre cores.
Passagem de Mensagens: Se o Core 0 precisa de algo que está no Core 1, ele não acessa a memória do Core 1. Ele envia uma mensagem assíncrona solicitando a operação.
Run-to-Completion: As tarefas são executadas até a conclusão ou até um ponto de espera explícito (I/O), maximizando o uso dos ciclos de clock.

Figura: Contraste arquitetural: O caos dos Thread Pools compartilhados versus a organização isolada do modelo Shared-Nothing do Seastar.

SeaStore: O Backend Nativo para NVMe

Enquanto o Crimson é a nova "alma" do processo OSD, ele precisa de um corpo para falar com os discos. O BlueStore, atual padrão, foi um grande avanço ao remover o sistema de arquivos local (XFS/Ext4) da equação, escrevendo diretamente em dispositivos de bloco. No entanto, o BlueStore ainda depende de chamadas de sistema (syscalls) e threads de bloqueio para certas operações de metadados (RocksDB).

O SeaStore é o novo backend de armazenamento projetado nativamente para o Crimson. Ele visa resolver as limitações remanescentes através de duas tecnologias principais:

SPDK (Storage Performance Development Kit): O SeaStore utiliza drivers em user space. Isso significa que o Ceph fala diretamente com o controlador NVMe, ignorando completamente o kernel do Linux. Isso elimina as custosas trocas de contexto entre modo usuário e modo kernel (syscalls).
Design Assíncrono Puro: Diferente do BlueStore, que usa threads síncronas para operações de metadados no RocksDB, o SeaStore é desenhado do zero para operar de forma assíncrona, alinhando-se perfeitamente ao modelo do Seastar.

💡 Dica Pro: O SeaStore também é projetado pensando em tecnologias emergentes como ZNS (Zoned Namespaces), que permitem que o software gerencie o posicionamento de dados no SSD, reduzindo a amplificação de escrita e o trabalho do Garbage Collection interno do disco.

Comparativo Técnico: Ceph Clássico vs. Crimson

Para arquitetos que precisam justificar a transição ou entender os trade-offs, a tabela abaixo resume as diferenças estruturais:

Característica	Ceph OSD Clássico (BlueStore)	Ceph Crimson OSD (SeaStore)
Modelo de Concorrência	Thread Pools (Pthreads)	Shared-Nothing (Seastar Reactor)
Uso de CPU	Alto overhead em Context Switching	Otimizado (Run-to-completion)
Acesso ao Disco	Kernel Syscalls (libaio/io_uring)	Kernel Bypass (SPDK)
Gerenciamento de Memória	Compartilhada com Locks	Particionada por Core
Latência de Cauda	Variável (suscetível a lock contention)	Determinística e Baixa
Maturidade (2024/25)	Produção (Estável)	Experimental / Tech Preview
Caso de Uso Ideal	HDD, SSD SATA/SAS, Misto	NVMe de Alta Performance, Optane

Métricas de Eficiência e TCO

A adoção do Crimson não é apenas uma questão de "mais velocidade". É uma questão de Custo Total de Propriedade (TCO). Em datacenters modernos, energia e refrigeração são custos primários.

Se um cluster Ceph clássico precisa de 24 núcleos de CPU para saturar 4 drives NVMe, e um cluster Crimson consegue saturar os mesmos drives com apenas 8 núcleos, a economia é drástica. Menos servidores, menos licenças de software (se aplicável), menos espaço em rack e menos consumo energético.

Testes preliminares indicam que o Crimson pode oferecer um aumento significativo de IOPS por núcleo de CPU, especialmente em cargas de trabalho de leitura aleatória pequena (4K random read), que é o padrão de ouro para bancos de dados e virtualização.

Figura: Gráfico ilustrativo projetando a eficiência de IOPS por núcleo de CPU entre as arquiteturas clássica e Crimson.

Desafios e O Veredito Arquitetural

Apesar da promessa, o Crimson ainda enfrenta o desafio da paridade de recursos. O Ceph clássico possui mais de uma década de desenvolvimento, com funcionalidades complexas como Erasure Coding, Snapshots, Scrubbing e recuperação de desastres robusta. Portar tudo isso para o modelo assíncrono do Seastar é uma tarefa hercúlea que a comunidade ainda está executando.

Minha recomendação: Se você está desenhando um cluster hoje para produção crítica de propósito geral, o BlueStore continua sendo a escolha segura e estável. No entanto, para novos projetos de High Performance Computing (HPC) ou Edge Computing que exigem latência determinística e utilizam hardware NVMe de ponta, o Crimson deve estar no seu radar de laboratório e testes de prova de conceito (PoC).

O futuro do storage distribuído é, sem dúvida, assíncrono e livre de locks. O Crimson não é apenas uma melhoria; é a adaptação necessária para a sobrevivência do armazenamento definido por software na era pós-rotacional.

Referências & Leitura Complementar

Seastar Framework: Advanced reactive system programming for C++. Disponível em: seastar.io
Ceph Crimson Documentation: Crimson: Next-generation OSD. Documentação oficial do projeto Ceph.
SPDK (Storage Performance Development Kit): Architecture and User Guide. Disponível em: spdk.io
SNIA (Storage Networking Industry Association): NVM Express & Zoned Namespaces Specifications.

Perguntas Frequentes (FAQ)

O que é o Ceph Crimson?

O Crimson é uma reescrita completa do daemon OSD (Object Storage Daemon) do Ceph, projetada para substituir o 'ceph-osd' clássico. Ele utiliza o framework Seastar para implementar uma arquitetura assíncrona, shared-nothing, otimizada para dispositivos de armazenamento rápidos como NVMe, minimizando o uso de CPU por operação de I/O e eliminando gargalos de threads.

Qual a diferença entre BlueStore e SeaStore?

O BlueStore é o backend de armazenamento padrão atual do Ceph, que roda em user space mas ainda depende de algumas chamadas de sistema e threads convencionais. O SeaStore é o novo backend projetado especificamente para o Crimson; ele é nativo para NVMe, utiliza SPDK para acesso direto ao hardware sem intervenção do kernel e é desenhado para operar em um modelo de 'run-to-completion', eliminando bloqueios (locks) caros.

Por que o Ceph clássico tem gargalos com NVMe?

O Ceph clássico foi desenhado na era dos HDDs, onde a latência do disco era muito maior que o tempo de processamento da CPU. Com NVMes modernos, a latência do disco é ínfima, fazendo com que o overhead de gerenciamento de threads, trocas de contexto (context switching) e bloqueios de memória da CPU se tornem o principal limitador de performance, impedindo o uso total da velocidade dos discos.