Ceph vs Linstor: A Batalha pelo Storage no Proxmox

Se você já montou um cluster Proxmox, provavelmente o botão "Install Ceph" piscou para você como a solução mágica para todos os seus problemas de armazenamento. E, para ser justo, muitas vezes é. Mas no mundo do homelab e das pequenas infraestruturas (SMB), a física é implacável.

Nós adoramos a ideia de "hiperconvergência" — rodar computação e armazenamento nas mesmas máquinas para economizar espaço e energia. O problema é que o software que gerencia esse armazenamento precisa comer. E o Ceph, meus amigos, tem um apetite voraz.

É aqui que entra o Linstor. Enquanto o Ceph tenta ser o "canivete suíço" que resolve tudo (bloco, arquivo, objeto) com uma arquitetura complexa de userspace, o Linstor adota uma abordagem cirúrgica, apoiando-se em tecnologias maduras do kernel Linux, especificamente o DRBD.

Hoje vamos abrir o capô dessas duas tecnologias. Não vamos falar de marketing. Vamos falar de IOPS, latência de cauda, consumo de RAM e o que acontece quando um disco morre às 3 da manhã.

Resumo em 30 segundos

Ceph é o padrão ouro para escalabilidade massiva e integração nativa no Proxmox, mas cobra um "imposto" alto em CPU e RAM (aprox. 1GB RAM/1TB disco).

Linstor é significativamente mais leve e rápido para clusters pequenos (3-5 nós) e NVMe, pois roda no nível do kernel (DRBD), mas exige instalação via plugin.

Rede é Lei: Não importa qual você escolha, tentar rodar storage distribuído em rede de 1GbE é pedir para ter latência de disco mecânico em SSDs. 10GbE é o mínimo viável.

Figura: Comparativo visual da pilha de software: A complexidade do Ceph em userspace versus a eficiência do Linstor/DRBD no kernel.

O paradoxo da alta disponibilidade em clusters compactos

Quando falamos de Enterprise, estamos falando de racks cheios de servidores. Se o Ceph consome 10% da CPU de um servidor EPYC de 64 núcleos apenas para calcular o algoritmo CRUSH, ninguém se importa. Sobram núcleos.

Mas no nosso cenário — seja um laboratório em casa ou um cluster de borda (Edge) em uma pequena empresa — estamos lidando com hardware limitado. Talvez você tenha três nós com processadores Intel Core ou Xeons mais antigos e 64GB de RAM cada.

Se você alocar 16GB de RAM e 4 núcleos apenas para o Ceph manter seus dados vivos, você acabou de perder capacidade para rodar as VMs que motivaram a construção do cluster em primeiro lugar. Esse é o paradoxo. Queremos redundância, mas o custo da redundância via Software Defined Storage (SDS) pode inviabilizar o projeto.

A física da latência: Object Store vs replicação de bloco

Para entender a diferença de performance, precisamos descer ao nível do dado.

O jeito Ceph: O Ceph é, em sua essência, um Object Store (RADOS). Quando sua VM grava um bloco no disco virtual, o Ceph pega esse bloco, quebra em objetos, calcula hashes para saber onde colocá-los (CRUSH map), e então envia para os OSDs (discos) através da rede. É uma maravilha da engenharia, mas adiciona latência. Cada operação de escrita passa por várias camadas de software antes de tocar o silício do SSD.

O jeito Linstor: O Linstor é um orquestrador para o DRBD (Distributed Replicated Block Device). Pense no DRBD como um "RAID 1 via rede". Quando sua VM grava um bloco, o DRBD intercepta essa gravação no nível do kernel e a envia simultaneamente para o disco local e para o nó réplica via rede. Não há conversão para objetos, não há cálculo complexo de posicionamento a cada IO. É bloco entrando, bloco saindo.

💡 Dica Pro: Em testes com armazenamento NVMe, o Ceph frequentemente se torna o gargalo antes do disco ou da rede. O Linstor, por rodar no kernel, consegue entregar performance muito mais próxima da velocidade nativa do NVMe, especialmente em random 4k writes.

Ceph: O gigante gentil (e faminto)

O Ceph é incrível. A integração com o Proxmox é "clique-e-pronto". Você vai na aba "Ceph", instala, cria os OSDs e monitores, e pronto. Se um nó cair, o sistema se cura sozinho (self-healing).

Onde o Ceph brilha

Integração Nativa: A GUI do Proxmox gerencia tudo. Não precisa abrir o terminal.
Escalabilidade Infinita: Quer adicionar mais 10 nós? O Ceph adora isso. A performance melhora com mais nós.
Resiliência: O algoritmo CRUSH é genial em garantir que seus dados estejam seguros, mesmo que você não entenda onde eles estão.

O custo oculto

A regra de ouro do Ceph é: 1GB de RAM para cada 1TB de armazenamento bruto. Tem 40TB de disco no nó? Separe 40GB de RAM só para o Ceph.

Além disso, o Ceph precisa de CPU rápida. Se você usar processadores de baixo clock ou com poucos núcleos, a latência de IO vai subir drasticamente durante operações de rebalance (quando um disco falha e o sistema recria os dados).

Figura: Gráfico de consumo de recursos: O "imposto" de RAM do Ceph versus a leveza do Linstor.

Linstor: A eficiência do kernel

O Linstor não é um sistema de arquivos; é um controlador que gerencia volumes ZFS ou LVM e usa o DRBD para replicá-los. A LINBIT (empresa por trás do DRBD) criou um plugin para o Proxmox que, embora não venha instalado por padrão, oferece uma experiência muito sólida.

A arquitetura do Linstor

Diferente do Ceph, que espalha pedaços de dados por todo o cluster, o Linstor geralmente mantém uma cópia completa do volume da VM em 2 ou 3 nós específicos.

Isso significa que:

Leitura Local: Se a VM está rodando no Nó A e os dados estão no Nó A, a leitura é velocidade nativa de disco. Zero rede.
Escrita: A escrita precisa ser confirmada no Nó A e no Nó B (réplica) antes de ser dada como concluída.

Por que escolher Linstor?

Performance em Clusters Pequenos: Em setups de 3 nós, o Linstor destrói o Ceph em performance de IOPS e latência.
Economia de Hardware: O overhead de RAM é insignificante. O DRBD usa pouquíssima memória. Você pode usar aquela RAM extra para mais VMs ou cache ARC do ZFS.
Flexibilidade de Backend: Você pode usar ZFS por baixo, ganhando compressão e snapshots eficientes, enquanto o Linstor cuida da replicação.

⚠️ Perigo: O Linstor/DRBD é menos tolerante a configurações de rede ruins. Se sua rede oscila, o DRBD pode entrar em estado de "Split-Brain" (desacordo sobre quem tem o dado mais atual). Embora existam mecanismos de recuperação automática, é uma dor de cabeça que você quer evitar.

Instalação e Manutenção: O choque de realidade

Aqui é onde o "homelabber" precisa ser honesto consigo mesmo.

Ceph no Proxmox: É trivial. A documentação é vasta. Se der problema, o fórum do Proxmox tem milhares de tópicos sobre isso. É a escolha segura se você não quer mexer muito no terminal.

Linstor no Proxmox: Requer adicionar o repositório da LINBIT (ou o repositório no-subscription deles), instalar os pve-headers para compilar o módulo DRBD e configurar o plugin. A interface gráfica existe e é boa, mas não é nativa do Proxmox. Ela aparece como uma aba separada ou menus de contexto. Atualizações de kernel do Proxmox às vezes exigem que você recompile o módulo DRBD ou espere a LINBIT atualizar o pacote.

Figura: A integração no Proxmox: Ceph nativo versus o plugin do Linstor.

Comparativo Técnico: Ceph vs Linstor

Para facilitar a decisão, compilei esta tabela baseada em cenários reais de produção e laboratório.

Característica	Ceph (RBD)	Linstor (DRBD)
Nível de Integração	Nativo (Out-of-the-box)	Plugin (Requer setup)
Consumo de RAM	Alto (~1GB/1TB)	Mínimo (Kernel overhead)
Consumo de CPU	Médio/Alto (Cálculo CRUSH)	Baixo (Replicação simples)
Latência (NVMe)	Média (Overhead de software)	Baixa (Próxima do nativo)
Escalabilidade	Excelente (50+ nós)	Boa (Melhor em clusters menores)
Mínimo de Nós	3 (Recomendado 5+)	2 + Quórum (Diskless)
Complexidade	Média (Oculta pela GUI)	Média/Alta (Conceitos de DRBD)
Recuperação	Automática (Rebalance)	Requer atenção em Split-Brain

Veredito do laboratório: Qual escolher?

A escolha não é sobre qual é "melhor", mas qual se adapta à sua restrição física e orçamentária.

Vá de Ceph se:

Você tem 3 ou mais nós idênticos.
Você tem RAM de sobra e CPU decente.
Você quer a experiência "Apple" de storage: funciona, é integrado e você não quer saber como a salsicha é feita.
Você planeja expandir o cluster adicionando nós individuais no futuro.

Vá de Linstor se:

Você tem um cluster pequeno (2 ou 3 nós).
Seu hardware é limitado (pouca RAM, CPUs mais antigas).
Você precisa extrair cada gota de IOPS dos seus SSDs NVMe.
Você se sente confortável em lidar com módulos de kernel e diagnósticos via CLI se algo der errado.

No meu laboratório pessoal, migrei de Ceph para Linstor em um cluster de 3 nós com processadores Xeon E5 v4. A diferença foi brutal: recuperei quase 40GB de RAM no total e a latência das minhas VMs de banco de dados caiu pela metade. Mas, aviso: a curva de aprendizado do DRBD existe.

Figura: Representação artística: A densidade do Ceph versus a velocidade cirúrgica do Linstor.

Referências & Leitura Complementar

Para quem quer auditar os dados ou se aprofundar na implementação, recomendo fortemente as fontes abaixo. Não confie apenas em blog posts; leia a documentação oficial.

LINBIT - Linstor User's Guide: Documentação oficial cobrindo a arquitetura do controlador e satélites.
Ceph Docs - Hardware Recommendations: A fonte real sobre o requisito de 1GB RAM/1TB OSD.
Proxmox Wiki - Ceph Server: Guia de implementação e best practices para PVE.
DRBD9 User Guide: Entenda os estados de conexão e como resolver split-brains manualmente.

Perguntas Frequentes (FAQ)

Qual o mínimo de nós para rodar Ceph e Linstor com segurança?

Para o Ceph, o mínimo recomendado para produção é 3 nós (idealmente 5+ para performance e quórum robusto). O Linstor consegue operar de forma segura com 2 nós de armazenamento + 1 nó sem disco (diskless/tiebreaker) apenas para manter o quórum, sendo muito mais flexível para setups compactos ou de baixo custo.

O Linstor consome menos memória RAM que o Ceph?

Sim, drasticamente menos. O Ceph requer cerca de 1GB de RAM para cada 1TB de armazenamento bruto (OSD), além de consumir ciclos de CPU intensivos para o algoritmo de posicionamento CRUSH. O Linstor roda no nível do kernel (via DRBD) e tem um overhead de memória insignificante em comparação, liberando recursos para suas VMs.

Posso usar rede de 1GbE para storage distribuído?

Tecnicamente sim, mas você vai se arrepender. Tanto Ceph quanto Linstor saturam 1GbE instantaneamente durante a replicação de escrita ou recuperação (rebalance), derrubando a performance de todo o cluster. A latência dispara e as VMs parecem travar. Recomenda-se no mínimo 10GbE dedicado exclusivamente para o tráfego de storage (backend).

O Linstor tem integração nativa na interface do Proxmox?

Não nativa "out-of-the-box" como o Ceph (que já vem no instalador). No entanto, existe um plugin oficial da LINBIT que adiciona menus e funcionalidades à interface do Proxmox. A instalação inicial requer alguns passos via linha de comando (CLI) para configurar repositórios e pacotes, mas a gestão do dia a dia pode ser feita majoritariamente pela GUI.