Todo ambiente virtualizado tem um calcanhar de aquiles: o armazenamento. Você pode ter dez nós de computação redundantes, mas se todos dependem de um único storage, esse storage é o ponto que derruba tudo quando falha. O Ceph resolve isso na raiz — e o Proxmox VE o traz integrado.

O que é hiperconvergência

Hiperconvergência significa juntar computação e armazenamento nos mesmos servidores, em vez de manter um storage central separado. No modelo hiperconvergente com Ceph, cada nó do cluster contribui com seus discos para um pool comum, distribuído e replicado.

O ganho é direto: sem storage central, não há ponto único de falha. E, ao crescer, você adiciona nós — que trazem, ao mesmo tempo, mais CPU, mais RAM e mais disco.

As peças do Ceph, sem jargão desnecessário

Você não precisa dominar o Ceph inteiro para decidir bem, mas conhecer quatro componentes evita mal-entendidos na operação:

• OSD: o processo que cuida de um disco. Um disco, um OSD. São eles que guardam o dado de fato.
• MON: os monitores mantêm o mapa do cluster e decidem, por maioria, quem está vivo. Assim como no cluster do Proxmox, é preciso número ímpar — três é o padrão.
• MGR: o gerente, que expõe métricas e coordena tarefas auxiliares como o balanceamento automático.
• CRUSH map: o algoritmo e o mapa que definem onde cada cópia do dado pode morar. Por padrão, o domínio de falha é o host, garantindo que duas cópias do mesmo objeto nunca fiquem no mesmo servidor.

Como o Ceph distribui o dado

O Ceph quebra o dado em objetos e os espalha pelos discos (chamados OSDs) do cluster, seguindo regras de replicação. Uma configuração comum mantém três cópias de cada objeto, em nós diferentes. Se um disco morre — ou um nó inteiro cai — as cópias em outros lugares mantêm o dado disponível, sem interrupção.

Dois parâmetros governam esse comportamento, e entender o segundo evita um susto sério:

• size = 3: o número de cópias que o cluster mantém em condições normais.
• min_size = 2: o número mínimo de cópias disponíveis para o cluster aceitar escrita. Se sobrar apenas uma cópia, o pool bloqueia I/O em vez de arriscar inconsistência.

Esse bloqueio é proteção, não defeito. Mas ele explica por que um cluster com nós insuficientes pode simplesmente parar de escrever durante uma falha: não havia onde manter duas cópias. É exatamente o cenário que o dimensionamento correto evita.

Existe também erasure coding, que entrega mais capacidade útil ao custo de mais CPU e latência maior. Faz sentido para arquivamento e volumes grandes de dado frio; para discos de VM em produção, replicação em três cópias continua sendo a escolha padrão pela previsibilidade de desempenho.

Self-healing: o cluster se conserta sozinho

Aqui está o que torna o Ceph especial em produção: quando um disco falha, o cluster percebe e recria automaticamente as cópias que faltaram, redistribuindo entre os discos saudáveis, até voltar ao número de réplicas configurado. Ninguém precisa acordar às 3h para reagir a um disco morto — a operação de recuperação já começou. Você troca o hardware quando for conveniente.

Vale saber que essa recuperação consome rede e disco enquanto acontece. Em cluster bem dimensionado, o impacto é discreto e a produção segue. Em cluster no limite, a recuperação disputa recurso com as VMs e a lentidão aparece — mais um motivo para deixar folga desde o projeto.

O que o Ceph pede de você

Ceph é poderoso, mas exige respeito ao projeto. Alguns pontos que definem se ele voa ou trava:

• Rede dedicada e rápida: o Ceph replica dados constantemente entre nós. Rede de armazenamento separada, com boa banda e baixa latência, não é luxo — é requisito. Dez gigabits é o piso realista; com NVMe, 25 gigabits ou mais deixam de ser exagero.
• Número de nós adequado: com replicação em três cópias, você precisa de nós suficientes para distribuir as cópias com folga. Três é o piso; a partir de quatro ou cinco, o cluster tem para onde recompor as réplicas quando um nó inteiro sai.
• Discos certos: misturar discos lentos e rápidos sem estratégia degrada o pool. SSD ou NVMe para os pools de VM é o que separa um Ceph responsivo de um Ceph frustrante. Se houver discos mecânicos para capacidade, colocar o banco de metadados do BlueStore (DB/WAL) em dispositivo rápido ajuda bastante.
• Ajuste do balanceamento: o autoscale de PGs e o balanceador cuidam da distribuição, mas merecem conferência em cluster que cresceu por etapas.

Ceph mal dimensionado é lento e frustrante. Bem dimensionado, é a espinha dorsal silenciosa que sustenta o ambiente por anos.

Fazendo a conta da capacidade

A matemática do Ceph surpreende quem olha só a soma dos discos. Com três cópias, a capacidade útil é aproximadamente um terço da capacidade bruta. E não se usa o último terabyte: o cluster emite alerta de "near full" bem antes do limite, porque precisa de espaço livre para recompor réplicas quando algo falha.

Uma regra de bolso honesta para planejamento:

1. Some a capacidade bruta de todos os discos destinados ao Ceph.
2. Divida por três, pela replicação.
3. Reserve folga — planeje usar em torno de 70% desse resultado no dia a dia.
4. Garanta que o cluster continue com espaço suficiente para absorver a perda de um nó inteiro.

Parece caro, e é honesto reconhecer: você paga em disco o que ganha em disponibilidade e em ausência de storage proprietário. A comparação justa não é contra a capacidade bruta, e sim contra o custo total de um storage central com redundância equivalente — incluindo licença, suporte e o fato de ele continuar sendo um único equipamento a proteger.

Escrita triplicada: por que a rede importa tanto

Cada escrita de uma VM se transforma em três escritas no cluster, e o cliente só recebe confirmação depois que as cópias necessárias foram aceitas. É isso que faz da rede de armazenamento um componente de desempenho, não apenas de conectividade. Latência alta na rede aparece como disco lento dentro da VM — e o diagnóstico costuma demorar porque ninguém suspeita do switch.

Separar a rede pública do Ceph (o tráfego entre clientes e OSDs) da rede de cluster (a replicação entre OSDs) é a prática recomendada em ambientes de porte. Assim, uma recuperação intensa não estrangula o acesso das VMs ao dado.

Ceph + HA: a dupla que sustenta produção

Ceph combina naturalmente com a alta disponibilidade do Proxmox VE. Como o dado está distribuído e acessível de qualquer nó, uma VM pode reiniciar em outro servidor e continuar enxergando exatamente o mesmo disco. É a fundação sólida sobre a qual o HA de computação realmente funciona.

Quando o Ceph não é a resposta

Recomendação honesta vale mais que entusiasmo. Ceph tende a não se pagar quando:

• O ambiente tem dois nós, ou três nós com discos escassos e rede de um gigabit.
• A carga exige latência mínima e previsível em um único servidor — banco de dados monolítico muito sensível, por exemplo.
• O orçamento não cobre a rede adequada. Ceph com rede fraca decepciona, e a culpa vai para o software.
• A equipe não terá quem acompanhe o cluster, nem parceiro de sustentação.

Nesses cenários, ZFS local com replicação agendada entre dois nós entrega bom resultado, com custo e complexidade menores — aceitando uma janela de perda de dados na falha. Escolher a arquitetura certa para o porte do ambiente é parte do trabalho.

Operação: o que olhar toda semana

Ceph é notavelmente autônomo, mas não dispensa acompanhamento:

• Estado de saúde do cluster, com alerta que chegue a uma pessoa, não a uma caixa de e-mail esquecida.
• Ocupação por OSD, para pegar desbalanceamento antes do alerta de espaço.
• Scrub e deep-scrub em execução, verificando consistência dos objetos.
• Discos com indício de falha no SMART, trocados antes de morrerem — recuperação planejada é sempre mais tranquila que recuperação forçada.
• Latência percebida dentro das VMs, que é a métrica que o seu cliente sente.

Erros comuns

• Rede de armazenamento compartilhada com tráfego de VM e de backup.
• Cluster de três nós operando acima de 80% de ocupação, sem espaço para recuperação.
• Discos de tipos e tamanhos muito diferentes no mesmo pool, sem estratégia.
• min_size reduzido para 1 "para não travar", trocando disponibilidade por risco de inconsistência.
• Nenhum monitoramento de saúde do cluster, descobrindo o problema pela reclamação do cliente.

Onde a Solvefy/Cloud entra

Projetamos e sustentamos clusters Proxmox VE com Ceph do dimensionamento de disco e rede ao ajuste fino de desempenho. Como parceiros oficiais Proxmox, entregamos armazenamento que escala e se recupera sozinho — sem o ponto único de falha que assombra tantos ambientes. E quando o Ceph não é o caminho certo para o seu porte, dizemos isso com clareza e propomos a alternativa adequada.

Quer avaliar seu armazenamento atual? Diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.