Ceph é um sistema de storage distribuído open source que entrega block, file e object storage num único cluster, sem ponto único de falha. Ele distribui os dados automaticamente entre os nós, detecta falhas e se recupera sem intervenção humana — o que o tornou a base de boa parte da infraestrutura de nuvem privada do mundo.
O problema que o Ceph resolve
Imagine que você tem um storage centralizado — um appliance NAS ou SAN. Toda a sua infraestrutura depende daquele equipamento. Ele falha, tudo para. Você pode colocar um segundo em standby, mas ainda há um momento de interrupção para o failover. E quando o volume de dados cresce além do que o appliance suporta, você troca por um maior — o que significa janela de manutenção, migração de dados e investimento em hardware específico do fabricante.
O Ceph nasceu para atacar exatamente esse problema. Em vez de um servidor central de storage, você tem um cluster de nós comuns — servidores com discos — e o Ceph distribui os dados entre todos eles de forma inteligente. Não há um controlador central que pode falhar. Não há um metadata server que vira gargalo. Cada nó sabe o que fazer independentemente.
O algoritmo que torna isso possível chama CRUSH — Controlled Replication Under Scalable Hashing. Em vez de manter uma tabela centralizada de “onde está cada dado”, o CRUSH usa uma função matemática determinística: dado o identificador do objeto e o mapa do cluster, qualquer nó calcula diretamente em quais OSDs (Object Storage Daemons) o dado está. Sem consulta central, sem gargalo de metadata.
Os três tipos de storage que o Ceph oferece
Na prática, o Ceph não é só um tipo de storage — é uma plataforma que expõe três interfaces diferentes sobre o mesmo cluster de dados.
O primeiro é block storage via RBD (RADOS Block Device). O Ceph apresenta volumes de bloco que você monta em servidores ou em hipervisores. É o modo usado pelo OpenStack (Cinder + Ceph), pelo Proxmox e pelo CloudStack. Uma VM no Proxmox com disco em Ceph não perde o dado se o host físico morrer — o disco existe no cluster e pode ser montado em outro nó em segundos.
O segundo é file storage via CephFS — um sistema de arquivos POSIX distribuído sobre o cluster Ceph. Múltiplos clientes montam o CephFS simultaneamente via protocolo nativo ou NFS. É a alternativa ao NAS tradicional para casos de uso que precisam de namespace compartilhado com escala horizontal.
O terceiro é object storage via RGW (RADOS Gateway), que expõe uma API compatível com S3 e Swift. O mesmo cluster Ceph que serve volumes de bloco para as VMs pode servir um endpoint S3 para backup e arquivamento. É isso que muitos provedores de nuvem privada usam como base do seu serviço de object storage.
Por que Ceph é usado em produção no mundo inteiro
O que convence os arquitetos não é o marketing — é o modelo de falha. Em um cluster Ceph, você define quantas réplicas de cada dado quer manter (tipicamente 3). O Ceph garante que essas réplicas nunca ficam no mesmo host, nem no mesmo rack, nem no mesmo datacenter, se você configurar corretamente os domínios de falha.
Quando um disco falha, o Ceph detecta automaticamente, marca o OSD como down e começa a rebuildar as réplicas perdidas usando os dados nos outros nós. Quando um servidor inteiro falha, o mesmo processo acontece, só em escala maior. O cluster continua atendendo leituras e escritas durante todo o processo de recuperação — com performance reduzida enquanto o rebalanceamento acontece, mas sem interrupção de serviço.
Quem usa Ceph em produção? Red Hat construiu o Red Hat Ceph Storage como produto comercial com suporte. OpenStack tem integração nativa com Ceph em praticamente todas as distribuições. Proxmox tem suporte a cluster Ceph embutido na interface. CERN usa Ceph para armazenar dados de física de partículas. Empresas de telecomunicações usam para VNF storage em redes 5G.
Quando Ceph compensa — e quando é complexidade desnecessária
O problema real aqui é que Ceph tem uma curva de aprendizado real. Não é algo que você instala, aperta um botão e funciona. Você precisa entender o CRUSH map, as regras de placement, o tunning de parâmetros de rede, o dimensionamento de OSD por capacidade e IOPS, o comportamento de recovery e backfill.
Para começar com Ceph, você precisa de no mínimo 3 nós — e 5 é o recomendado para ter quórum de monitor sem comprometer a disponibilidade durante manutenção. Abaixo disso, o custo de aprender e operar Ceph não se justifica.
Ceph compensa quando você tem volume de dados que cresce continuamente e precisa escalar horizontalmente adicionando nós, quando precisa de block + object storage no mesmo cluster sem pagar por dois sistemas separados, quando a disponibilidade é crítica e o modelo de falha com SPOF não é aceitável, e quando a equipe tem (ou está disposta a desenvolver) expertise em operação de sistemas distribuídos.
Ceph provavelmente não é a resposta certa quando você tem uma equipe pequena sem experiência em storage distribuído, quando o volume de dados cabe confortavelmente num NAS ou SAN convencional, ou quando você precisa de algo funcional agora — sem um projeto de implantação de 2 a 3 meses.
Para esses casos, um NAS gerenciado, um storage S3-compatible como serviço ou um array SAN de um fabricante estabelecido entrega o que você precisa sem o overhead operacional do Ceph.
Como o Ceph aparece na sua infraestrutura sem você saber
Pense assim: se você usa OpenStack, Proxmox com cluster, ou contratar cloud privada num provedor sério, provavelmente tem Ceph embaixo, gerenciado pela plataforma. O operador do ambiente configura e opera o Ceph; você consome block volumes, object storage e file systems sem precisar conhecer os detalhes.
Essa é a forma mais saudável de usar Ceph para a maioria das empresas — como camada de storage gerenciada pela plataforma de nuvem privada, não como projeto separado que a sua equipe precisa operar.
A nuvem privada da Adentro usa Ceph como camada de storage distribuído nos datacenters Tier III — você consome block volumes, object storage S3 e file storage sem precisar operar o cluster. Infraestrutura enterprise, sem complexidade operacional.