Ceph vs Linstor no Proxmox: O confronto definitivo de storage HCI

Se você já montou um cluster Proxmox em casa ou na pequena empresa, provavelmente seguiu o caminho dourado: instalou o Proxmox VE, clicou na aba "Ceph", seguiu o wizard e voilà. Você tem um storage hiperconvergente. É mágico, é resiliente e é o padrão da indústria.

Mas aí você começa a notar algo estranho. Suas VMs parecem "pesadas". O iowait sobe sem motivo aparente. Seus SSDs NVMe, que custaram uma fortuna, entregam performance de SATA antigo. Bem-vindo ao clube. O que ninguém te conta na primeira página do manual é que o Ceph, por mais brilhante que seja, é um monstro faminto que não foi desenhado para clusters pequenos de 3 nós.

É aqui que entra o desafiante: Linstor. Menos hype, mais performance bruta. Vamos abrir o capô dessas duas tecnologias, sujar as mãos de graxa digital e entender qual delas merece rodar nos seus discos.

Resumo em 30 segundos

Ceph é projetado para escala massiva (petabytes). Em clusters pequenos (3-5 nós), o overhead do algoritmo CRUSH mata a latência e consome muita CPU.

Linstor usa DRBD (RAID 1 via rede) no nível do kernel. O caminho dos dados é curtíssimo, entregando performance quase nativa do disco local.

A escolha: Se você tem menos de 5 nós e quer velocidade máxima, vá de Linstor. Se planeja crescer para 10+ nós e precisa de object storage (S3), fique com o Ceph.

O mistério da latência fantasma em clusters de 3 nós

A maioria dos homelabs e PMEs começa com a "trindade sagrada": 3 servidores. É o mínimo para quórum (HA). O problema é que a arquitetura do Ceph foi pensada para data centers onde falhas de disco são estatísticas diárias, não eventos catastróficos anuais.

Quando você grava um dado no Ceph, ele não vai simplesmente do ponto A para o B. Ele passa por uma camada de abstração complexa. O dado é fatiado, calculado, replicado e confirmado. Em um cluster pequeno, a latência de rede e o tempo de CPU gastos apenas para decidir onde o dado deve morar podem ser maiores que o tempo de gravação no disco em si.

Isso gera a "latência fantasma". Seus discos estão ociosos, sua rede é de 10Gbps, mas o banco de dados na VM engasga. O culpado geralmente é a latência de cauda (tail latency) introduzida pela complexidade do software.

Figura: Comparação visual do caminho de dados: O labirinto burocrático do Ceph vs a autoestrada direta do Linstor.

CRUSH Map vs DRBD: A física do caminho de dados

Para entender a diferença de performance, precisamos olhar para a física do software.

Ceph e o algoritmo CRUSH

O Ceph não usa uma tabela de alocação fixa. Ele usa o CRUSH (Controlled Replication Under Scalable Hashing). É um algoritmo pseudo-aleatório determinístico.

Vantagem: Você pode adicionar 1000 discos e o sistema se reequilibra sozinho sem um banco de dados central de metadados que gargalaria.
Custo: Cada operação de I/O exige cálculo de CPU. O dado entra no userspace, o CRUSH calcula onde ele vai, o dado é enviado aos OSDs (Object Storage Daemons), que escrevem no disco e confirmam. Esse "ping-pong" entre kernel e userspace custa caro.

Linstor e a simplicidade do DRBD

O Linstor é, essencialmente, um orquestrador para o DRBD (Distributed Replicated Block Device). O DRBD existe há décadas e é parte do kernel do Linux.

Como funciona: Pense nele como um "RAID 1 via rede". Quando sua VM escreve um bloco, o DRBD o espelha imediatamente para o disco do outro nó.
Vantagem: Tudo acontece no kernel space. Não há algoritmo complexo de posicionamento. O caminho do dado é: Filesystem da VM -> DRBD -> Rede -> Disco Remoto. É brutalmente eficiente.

💡 Dica Pro: O DRBD versão 9 (usado pelo Linstor atual) suporta múltiplos peers, não apenas 2. Isso permite configurações de réplica 3 parecidas com o Ceph, mas com latência muito menor.

A armadilha do hardware: Por que NVMe não salva o Ceph

Eu vejo isso o tempo todo nos fóruns. O usuário reclama que o Ceph está lento. A comunidade responde: "Compre SSDs Enterprise com PLP (Power Loss Protection) e rede de 25Gbps". O usuário gasta milhares de reais e ganha... 15% de melhoria.

Por que isso acontece? Porque o gargalo em clusters pequenos de Ceph raramente é a mídia (o disco). O gargalo é a serialização de software e a CPU.

Se você tem um NVMe capaz de 500.000 IOPS, mas seu software de storage (Ceph) só consegue processar 30.000 IOPS por thread de CPU antes de saturar a latência, seu NVMe vai passar a maior parte do tempo dormindo. O Linstor, por ser mais leve, consegue extrair muito mais IOPS do mesmo hardware, justificando o investimento em discos rápidos.

Figura: O gargalo real: Enquanto a CPU sua a camisa calculando onde guardar os dados no Ceph, o SSD NVMe fica ocioso esperando instruções.

Engenharia de precisão: A arquitetura do Linstor no Proxmox

Integrar o Linstor no Proxmox costumava ser um pesadelo de linha de comando. Hoje, graças ao plugin da LINBIT, a experiência é muito próxima da nativa.

A arquitetura se divide em três componentes principais:

Linstor Controller: O cérebro. Decide onde os volumes são criados. Pode rodar como um container ou VM dentro do próprio Proxmox.
Linstor Satellite: O operário. Roda em cada nó do Proxmox, gerenciando os discos locais (geralmente sobre ZFS ou LVM-Thin).
DRBD: O transportador. Faz a replicação real dos bits.

Diferente do Ceph, que exige discos brutos dedicados, o Linstor é feliz rodando em cima de um Zpool existente ou de um Volume Group LVM. Isso é excelente para homelabs onde você não pode dedicar 100% dos discos apenas para o storage distribuído.

O fator "Diskless"

Uma funcionalidade matadora do Linstor é o modo diskless. Se você tem um cluster de 3 nós, mas apenas 2 têm armazenamento grande, o terceiro nó pode rodar VMs acessando os dados dos outros dois via rede (como um cliente iSCSI), sem precisar de armazenamento local para participar do cluster de computação.

Figura: Arquitetura Linstor: Replicação eficiente entre nós de armazenamento e a flexibilidade de clientes sem disco (diskless).

Prova de fogo: IOPS, latência e o teste de desconexão

Vamos aos números e cenários reais. Em testes controlados (hardware idêntico, rede 10GbE), a diferença é gritante.

Comparativo de Performance (4k Random Write)

Ceph (Réplica 3): ~4.000 - 8.000 IOPS (Latência alta)
Linstor (Réplica 3): ~30.000 - 50.000 IOPS (Latência baixa)
Linstor (Réplica 2): ~60.000+ IOPS

O Linstor brilha em random writes pequenos, que é exatamente o padrão de tráfego de bancos de dados e sistemas operacionais de VMs. O Ceph sofre aqui devido à amplificação de escrita (write amplification).

O Teste de Desconexão (Split-Brain)

Aqui o Ceph ganha pontos. Se você puxar o cabo de rede de um nó Ceph, o cluster "congela" por alguns segundos, os monitores votam, e o cluster continua. É suave.

No Linstor/DRBD, a gestão de split-brain (quando dois nós acham que são o mestre) é mais crítica. Embora o Linstor automatize muito disso, situações de falha de rede em clusters de 2 nós sem um árbitro externo podem levar a volumes em modo Read-Only para proteção. Configurar o fencing corretamente no Proxmox é obrigatório para quem usa Linstor.

⚠️ Perigo: Nunca rode um cluster Linstor/DRBD de 2 nós sem configurar um mecanismo de fencing ou um nó de quórum externo. Se a rede cair, ambos os lados podem tentar escrever no disco, corrompendo seus dados irremediavelmente.

Tabela Comparativa: O Veredito Técnico

Característica	Ceph (RBD)	Linstor (DRBD)
Complexidade de Setup	Baixa (Nativo no Proxmox)	Média (Plugin externo)
Uso de CPU/RAM	Alto (Faminto)	Baixo (Eficiente)
Latência (Small Cluster)	Alta (Gargalo de software)	Baixa (Velocidade de fio)
Escalabilidade	Infinita (Petabytes+)	Limitada (Melhor até ~30 nós)
Resiliência a Falhas	Excelente (Self-healing auto)	Boa (Requer fencing correto)
Ideologia	Object Store (S3 first)	Block Storage (Performance first)

Figura: Eficiência de recursos: O custo computacional do Ceph vs a leveza do Linstor.

Veredito do Lab: Qual escolher?

Não existe bala de prata, mas existe a ferramenta certa para o trabalho.

Se você é um provedor de nuvem, tem 50 servidores, precisa oferecer S3 para clientes e não quer saber em qual disco o dado está: Use Ceph. A complexidade se paga pela escala e pela capacidade de dormir tranquilo enquanto o cluster se cura sozinho.

Se você é um entusiasta, tem um homelab, uma pequena empresa com 3 a 5 servidores e quer que suas VMs voem baixo sem gastar uma fortuna em CPUs Threadripper apenas para gerenciar storage: Use Linstor. A performance por watt e por dólar é imbatível em pequena escala.

O Linstor traz de volta a sensação de "metal nu" para a virtualização hiperconvergente. Ele remove as camadas de gordura e deixa apenas o músculo. Para a maioria de nós, operando fora de data centers hyperscale, isso é exatamente o que precisamos.

Referências & Leitura Complementar

DRBD9 User's Guide: Documentação oficial da LINBIT sobre a mecânica de replicação.
The CRUSH Algorithm (2006): O paper original de Sage A. Weil que define a matemática do Ceph.
Proxmox VE Storage Documentation: Capítulos oficiais sobre integração RBD e plugins externos.
RFC 3720 (iSCSI): Para entender as alternativas de transporte de bloco sobre IP, caso decida não usar HCI.

Perguntas Frequentes (FAQ)

O Linstor é gratuito para uso no Proxmox?

Sim, o núcleo do Linstor é Open Source sob licença GPL. A LINBIT disponibiliza um repositório "community" que é gratuito. No entanto, ele pode exigir compilação manual dos módulos do kernel ou configuração mais artesanal. A versão Enterprise (paga) oferece repositórios com binários pré-compilados, testados e suporte oficial, o que é recomendado para produção crítica.

Posso migrar de Ceph para Linstor sem formatar?

Não existe um botão de "converter". São tecnologias com paradigmas opostos (Object Store vs Block Replication). O processo exige criar um novo storage pool no Linstor e mover os discos virtuais (vDisks) das VMs um a um. O Proxmox facilita isso com a função "Move Disk", que permite a migração a quente (live storage migration) em muitos casos.

O Linstor suporta High Availability (HA) em 2 nós?

Suporta, mas é um terreno perigoso. Diferente do Ceph que exige 3 nós para funcionar bem, o DRBD opera bem em 2. Porém, para evitar o "split-brain" (onde ambos os nós acham que são donos do dado numa falha de rede), você **precisa** de um mecanismo de desempate. Isso pode ser um terceiro nó "witness" (que não armazena dados, apenas vota) ou uma configuração robusta de fencing via hardware (IPMI/iDRAC).

Por que o Ceph consome tanta CPU?

A culpa (e a genialidade) é do CRUSH. Ao contrário de uma tabela estática que diz "o dado X está no disco Y", o Ceph calcula a localização de cada pedaço de dado em tempo real usando hashing consistente. Isso garante distribuição perfeita e rebalanceamento automático, mas gera um custo computacional (overhead) significativo para cada operação de leitura e escrita, pesando na CPU.