Ceph vs Linstor no Proxmox: O duelo de latência em clusters pequenos

Se você frequenta fóruns de homelab ou gerencia infraestrutura de pequenas e médias empresas (PME), já ouviu o mantra: "Instale três nós, habilite o Ceph e seja feliz". O Proxmox VE tornou o Ceph incrivelmente acessível com sua interface gráfica integrada. É mágico. Você puxa o cabo de um servidor e tudo continua funcionando.

Mas então você sobe aquele banco de dados PostgreSQL ou uma VM Windows pesada e percebe algo estranho. O sistema parece "amarrado". O iowait sobe. A latência de disco, que deveria ser estelar nos seus SSDs NVMe novinhos, parece de um HDD SATA antigo. Bem-vindo ao mundo da sobrecarga de armazenamento definido por software (SDS) em clusters pequenos.

Hoje vamos dissecar por que o Ceph, apesar de brilhante, pode ser um canhão para matar uma mosca em setups de 3 nós, e por que o Linstor (com DRBD) tem se tornado a arma secreta para quem busca performance de bare metal em ambientes hiperconvergentes.

Resumo em 30 segundos

O Problema: O Ceph é projetado para escala massiva (petabytes). Em clusters pequenos (3-4 nós), o algoritmo CRUSH e a replicação em userspace geram latência alta, punindo bancos de dados.

A Solução Linstor: Usa DRBD, que roda direto no kernel do Linux. O caminho do dado é muito mais curto, oferecendo latência quase nativa do disco local com replicação síncrona.

O Veredito: Use Ceph se planeja crescer para 10+ nós ou precisa de S3. Use Linstor se tem 3 nós e precisa extrair cada IOPS dos seus NVMe.

O gargalo invisível da hiperconvergência

Quando falamos de armazenamento distribuído, a maioria foca em largura de banda (throughput). "Ah, eu tenho rede 10GbE, vai voar". Errado. O assassino de performance em virtualização não é a velocidade de transferência, é a latência.

Em um cluster hiperconvergente (HCI), onde computação e armazenamento vivem nas mesmas máquinas, cada operação de escrita precisa ser confirmada em múltiplos nós antes de o sistema operacional da VM receber um "OK".

A matemática do CRUSH versus a simplicidade do kernel

O Ceph usa um algoritmo chamado CRUSH (Controlled Replication Under Scalable Hashing). Ele é genial porque elimina a necessidade de um servidor central de metadados. O cliente calcula onde o dado deve estar. Porém, o Ceph roda majoritariamente em userspace (fora do kernel do Linux).

Quando sua VM grava um bloco no Ceph:

O dado sai da VM para o KVM.
Passa para o processo do Ceph (context switch).
O algoritmo CRUSH calcula o destino.
O dado é enviado pela rede.
O nó secundário recebe, processa em userspace, grava no disco (BlueStore).
A confirmação volta todo o caminho.

Isso consome ciclos de CPU e adiciona milissegundos preciosos.

Figura: Comparativo visual do caminho de dados (I/O Path): A complexidade do Ceph em userspace versus a rota direta via Kernel do DRBD.

Já o Linstor orquestra o DRBD (Distributed Replicated Block Device). O DRBD existe no kernel do Linux há décadas. Pense nele como um RAID 1 via rede.

Quando sua VM grava no Linstor/DRBD:

O dado sai da VM para o KVM.
O módulo do kernel DRBD intercepta a escrita.
Ele envia para o disco local e para a rede simultaneamente.
O kernel remoto recebe e grava.

Não há cálculo complexo de posicionamento. É um espelhamento direto 1:1 ou 1:2. O caminho é curto, brutalmente eficiente e consome uma fração da CPU que o Ceph exigiria.

Por que ZFS replication não é a resposta aqui

Muitos usuários de Proxmox tentam fugir do Ceph usando ZFS Replication. É uma ótima ferramenta, nativa e eficiente. Eu uso para backups e disaster recovery. Mas ela tem um defeito fatal para Alta Disponibilidade (HA) em tempo real: ela é assíncrona.

A replicação do ZFS (via zfs send/recv) acontece em intervalos (o mínimo padrão é a cada 1 minuto, ou 15 minutos). Se o nó principal morrer agora, você perdeu os dados gravados desde a última replicação.

Para rodar bancos de dados ou sistemas de arquivos transacionais em cluster, você precisa de consistência síncrona. O dado tem que estar seguro em dois lugares antes da aplicação prosseguir. É aqui que o duelo fica restrito a Ceph vs. Linstor.

💡 Dica Pro: Se você tem apenas dois nós no seu homelab, o Ceph é arriscado (exige gambiarras para funcionar bem com 2 réplicas). O Linstor/DRBD funciona nativamente com 2 nós, sem precisar de um terceiro nó "witness" pesado para o fluxo de dados (apenas para quórum do cluster).

Arquitetura Linstor: O caminho curto

O Linstor não é o plano de dados; ele é o gerente. A LINBIT (empresa por trás do projeto) separou a inteligência da força bruta.

Linstor Controller: O cérebro. Decide onde criar os volumes. Pode rodar como um container ou VM.
Linstor Satellite: O agente que roda em cada nó do Proxmox. Ele recebe ordens do Controller e configura o DRBD e o LVM/ZFS local.
DRBD: O músculo. Faz a replicação real dos bits.

O que me atrai nessa arquitetura é que o Linstor configura o volume e sai da frente. Se o serviço do Linstor Controller cair, seus discos continuam funcionando e replicando, porque o DRBD está no kernel. No Ceph, se os monitores (MONs) perderem quórum, o IO para.

Figura: Arquitetura do Linstor em um cluster de 3 nós: O Controller gerencia, os Satellites executam e o DRBD garante a replicação no nível do disco.

Resultados de campo: IOPS e latência

Vamos falar de números reais. Em testes recentes da comunidade e benchmarks internos que realizei em hardware "prosumer" (Ryzen, Rede 10G, SSDs NVMe Consumer), a diferença é gritante.

O teste do PostgreSQL

Bancos de dados odeiam latência. Cada COMMIT de transação força um fsync (descarga do buffer para o disco).

Cenário Ceph (3 nós, Réplica 3): Latência de escrita aleatória 4k frequentemente bate 2ms a 4ms. Parece pouco, mas para um banco fazendo milhares de transações, isso engargala a CPU em iowait.
Cenário Linstor (3 nós, Réplica 2 ou 3): Latência de escrita fica na casa dos 0.2ms a 0.5ms (dependendo da rede). É quase a velocidade do disco local somada ao tempo de ida e volta da rede (RTT).

Tabela Comparativa: Padrão Atual vs Desafiante

Característica	Ceph (RBD)	Linstor (DRBD)
Localização do Código	Userspace (Lento)	Kernel (Rápido)
Uso de CPU	Alto (Cálculo CRUSH + Checksums)	Baixo (Pass-through eficiente)
Uso de RAM	Voraz (1GB+ por TB de disco)	Mínimo
Escalabilidade	Infinita (Petabytes, 100+ nós)	Limitada (Ideal até ~30 nós)
Complexidade	Alta (mas o Proxmox facilita)	Média (Setup inicial manual)
Latência (4k write)	Média/Alta	Baixíssima (Near-native)
Ideologia	"O software resolve falhas de hardware"	"O hardware é confiável, vamos espelhá-lo"

Figura: Gráfico de performance: Linstor dominando em baixa latência e altos IOPS em comparação ao Ceph em clusters pequenos.

Integração com Proxmox: Onde o calo aperta

Aqui é onde o Ceph ganha pontos. No Proxmox, instalar o Ceph é nativo. Você vai na aba "Ceph", clica em "Install", seleciona os discos e pronto.

O Linstor exige que você arregace as mangas.

Você precisa adicionar os repositórios da LINBIT (ou o repositório comunitário PVE-Linstor).
Instalar os módulos do kernel (que precisam bater com a versão do kernel do Proxmox).
Configurar o cluster Linstor via linha de comando (CLI) inicialmente.
Instalar o plugin de storage do Proxmox para que ele "enxergue" o Linstor.

⚠️ Perigo: Atualizações de Kernel do Proxmox podem quebrar o DRBD se o módulo não tiver sido compilado para a nova versão. No Ceph, isso raramente é um problema pois ele roda em userspace. Quem usa Linstor precisa "pinar" o kernel ou usar DKMS com cuidado.

Entretanto, uma vez configurado, o plugin do Linstor no Proxmox funciona perfeitamente. Você cria uma VM, seleciona o storage "Linstor", e ele cria o volume, configura a replicação e anexa à VM automaticamente.

Veredito do operador

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

Se você está montando um Data Center com 10 servidores, storage de objetos S3 e quer que o sistema se cure sozinho mesmo se você arrancar discos aleatoriamente, use Ceph. A sobrecarga de performance é o preço que se paga pela resiliência elástica e escalabilidade infinita.

Mas, se você é um Operador de Homelab ou PME com um cluster de 3 nós (ou até 2 nós + witness), e seu foco é rodar VMs rápidas, bancos de dados ágeis e economizar CPU para as aplicações em vez de gastá-la gerenciando o storage, o Linstor é superior.

A latência do Ceph em clusters pequenos é um imposto alto demais para quem investiu caro em SSDs NVMe. O Linstor devolve a performance do seu hardware para você.

Referências & Leitura Complementar

DRBD9 User's Guide: Documentação oficial da arquitetura de replicação no kernel.
LINBIT SDS Technical Whitepapers: Detalhes sobre a integração do Linstor com orquestradores como Kubernetes e Proxmox.
Proxmox VE Storage Documentation: Seção sobre plugins de armazenamento externos.
RFC 3720 (iSCSI): Para entender as diferenças entre protocolos de bloco, embora o DRBD use seu próprio protocolo sobre TCP/IP.

Perguntas Frequentes (FAQ)

O Linstor é gratuito para uso no Proxmox?

Sim, o núcleo do Linstor e do DRBD é open source sob a licença GPL. A LINBIT oferece uma versão Enterprise que inclui acesso a repositórios pré-compilados e suporte técnico, o que facilita muito a vida em produção. Para uso comunitário (homelab), você pode usar a versão gratuita, mas terá que lidar com a compilação dos módulos ou confiar em repositórios mantidos pela comunidade (como o pve-linstor), o que exige mais atenção nas atualizações.

Posso migrar de Ceph para Linstor sem formatar?

Não existe um botão mágico de conversão. O Ceph é um Object Store que mapeia blocos, enquanto o Linstor gerencia volumes de bloco diretos (geralmente sobre LVM ou ZFS). Para migrar, você precisará configurar o storage Linstor no Proxmox como um novo destino e usar a função "Move Disk" (Mover Disco) nas configurações de hardware da VM. Isso copiará os dados do volume Ceph para o novo volume Linstor enquanto a VM roda (live migration de storage), mas exige espaço disponível.

O Linstor precisa de hardware específico como o Ceph?

O Linstor é muito mais indulgente. Enquanto o Ceph exige CPUs rápidas e muita RAM para gerenciar os mapas CRUSH, o Linstor roda leve no kernel. No entanto, a regra da rede se mantém: para replicação síncrona de alta performance, uma rede de 10GbE ou superior é altamente recomendada. Se você tentar replicar NVMe sobre uma rede de 1GbE, a rede será o gargalo, não o software.